From xen-devel-bounces@lists.xenproject.org Thu Oct 01 07:15:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 07:15:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1437975.1656859 (Exim 4.92) (envelope-from ) id 1xCB04-0007du-5t; Thu, 01 Oct 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 1437975.1656859; Thu, 01 Oct 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 1xCB04-0007dn-32; Thu, 01 Oct 2026 07:14:40 +0000 Received: by outflank-mailman (input) for mailman id 1437975; Thu, 01 Oct 2026 07:14:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCB02-0007dh-GL for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 07:14:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCB01-008kxM-Pt for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:14:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe084f-8faa-0a2a0a5109dd-0a2a4508e28c-32 for ; Thu, 01 Oct 2026 09:14:37 +0200 Received: from [74.125.225.99] (helo=mail-wr2-f35.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe085d-f659-0a2a45080019-4a7de163963f-3 for ; Thu, 01 Oct 2026 09:14:37 +0200 Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-48b0f4efe31so61202f8f.2 for ; Thu, 01 Oct 2026 00:14: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-48b06778c3fsm4816891f8f.0.2026.10.01.00.14.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 00:14: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=1790838877; x=1791443677; 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=Z8rH22Er45wWWjpv0r5L3KNPoam+oZEAngrcd1iyQ00=; b=domQUpMQx+S18wCItGbHvPKwXKfB/aa/WwUeZBiMannibNSOalikGCNV3baWdFIFy7 ZKbNvwa+qY1r1fYdhlhMrgIrqIXVi/cGPXkGnpMxwxDyVjrmNtkDHpWE4YtLidqa7x8I uTT4W52GKXZMB7ct8fAo62xIS4Pbbk/QDIwoaFTqAiEJFp2t3MkLEwUU3h5H4B15EvaM OH+BCT3YB12jOiHKgU90/xJTHM3OrFMxt20vJJ759B7+bJ2gW1/Iio4H5+KnLngWCjsd 0kpl0UW6gTXvABxHMmOCfiIRkoJ2KyFOnen+/4J/ofX7m1wTKOAWrBLoPCP28BE1QwhB 6qWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790838877; x=1791443677; 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=Z8rH22Er45wWWjpv0r5L3KNPoam+oZEAngrcd1iyQ00=; b=oCyi61U+kExVCu4C0MR+dPcmlGigTashhEu5EXwD3BIbaXU6fipg72d1TOUw9r7IBT W2RJvtwujPBUWmkeLBq1kfQe1nLeaG87ma5MM9tHU9sTy59moZ2KSclZRXmnNPJP5EcO PgG60JgHuWlqSMRq7U6neAWIFgztFwKcbGsgeBYDFhml+YCU8RbJFkSSq1z4QqIKm3gL FSDx7ypMWB4HvQqDvD3EKlJE2/eM9xaVcHSZvLLbbqtDTOz6b72RJHWfwyLHilJ3rNPm P7YpSdZ5eqP3MeHe+jqgzoT3kCwP1wqKeiNh3e+eUovJb+p3oLPY7Pyx95VrAMHlaZ6W ZrrA== X-Forwarded-Encrypted: i=1; AKwUvBxQRiSobDEOznaKM3WCoKL4ebPJDByrvelVRoCzrAOrCYp6IWp1JzrfQNDduiy7whakdwvCV0W2n/E=@lists.xenproject.org X-Gm-Message-State: AFq9FYIsNdVFqBHaR58IFhSJQPWHefKwgIyOB5Qp08uigVHii40oOmqw oTtDfDqzdEXmYwUi2sEf3sIj22H3KamIX7Fg6wvSn4Fhg/qkdKoJQ9vcbrasFM5nZQ== X-Gm-Gg: AYBFou2fF8PuDpxVbrl0Duv+XkDt7tlxetgA2rMm4+/8jspvt/039IOBk/0Xq6h5bwh CEwrtoSQxOF89ON8Buf3ZlPGReFHaILyo/UCrdK43Wy7AaHzNK5OdvW6cRBlBs16flHX9eITX1u vQDvbpf8J9qCVr+HnG332tKDA5QGE0G8u+xKhEgN3hOYSdBBC3FT/NxPL8sauLYle4tZpR/jR8B HOokr4kGabbGE/j3pFps9BsLhUN2YQX+YAMNBwi74z5Ju8OudFzkxzw3BvMDZiA//as/miPWQsJ sXpjAkbJxSroCa8vonWWJeAoPi5zwGjLAFYUjI644EdSkqkfmXtcMttPWbZEqxq54DBi/oPCanW WWa30oCMlp7tcEqGwDPLHcsfAxmFNIcqYd6KZwD0FRuJkRV15ED+bkE3xRDJQaLs980WMvXkTn9 Sp/0rxV2+id5lt4y7DUv+3x0NP9e17ECGmWHpo0Ue6PzHaLMJv/QpOrBwvCqQNAB0FUeBePti5j XaJInyA2w65lRWA0LcKGA5mbXNCB57TOkbCnSINiKLtmXoqkKA+Q3B47vmx3rJk/1ycBlam X-Received: by 2002:a05:6000:26d1:b0:48a:f318:ac02 with SMTP id ffacd0b85a97d-48b024dc638mr7303226f8f.19.1790838876710; Thu, 01 Oct 2026 00:14:36 -0700 (PDT) Message-ID: <332fec64-31f0-48b5-8c86-163e81899310@suse.com> Date: Thu, 1 Oct 2026 09:14:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] x86/ACPI: optimise C3 entry on AMD CPUs To: Olivier Lambert Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , xen-devel@lists.xenproject.org References: <1790796643.8631fc262581453bbf619ec5b2062170.1a0f3cc3da00003f66@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: <1790796643.8631fc262581453bbf619ec5b2062170.1a0f3cc3da00003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1790838877-CDB4987B-1C25A00F/10/78276251493 X-purgate-type: spam X-purgate-size: 3926 On 30.09.2026 21:30, Olivier Lambert wrote: > All Zen or newer CPU which support C3 shares cache. Its not necessary to > flush the caches in software before entering C3. This will cause drop in > performance for the cores which share some caches. ARB_DIS is not used > with current AMD C state implementation. So set related flags correctly. > > Signed-off-by: Deepak Sharma Shouldn't this be mirrored in a From: tag? (I'll try to remember to attribute the patch that way when committing.) > Acked-by: Thomas Gleixner > Signed-off-by: Rafael J. Wysocki > Origin: https://git.kernel.org/torvalds/p/a8fb40966f19 > [Port to Xen. Include Hygon.] > Assisted-by: Claude-Code:claude-opus-5-5 > Signed-off-by: Olivier Lambert > Reviewed-by: Jason Andryuk Acked-by: Jan Beulich Why the RFC, btw? > --- > > Notes: > Changes in v2: > - Resend with git send-email: my mail client stripped the whitespace from > v1, so its diff could not be applied. No code change. > - Picked up Jason's Reviewed-by. > > Found on XCP-ng 8.3 (Xen 4.17.6) on a Ryzen 5 7600 (Zen 4, family 0x19) > whose _CST lists C1 (HLT) plus C2 and C3 as SYSIO states (C3 exit > latency 350us). With bm_check == 0, every C3 entry executes WBINVD. > > Measured under a VM-to-VM network load, in 25s windows: > - ~140 WBINVD/s, 65-69us each on average, 300us at worst. > - Spinning on each CPU in turn with IRQs off and reading the TSC shows > gaps of up to 222us; none with this change. The SMI count (PMC event > 0x2b, validated by counting cycles on the same counter) stayed at 0, > and NMIs didn't line up with the gaps. > - credit1's do_schedule() occasionally took up to 262us, with IRQs > off; at most 4.4us with this change. > - xenpm set-max-cstate 1 removes the stalls too, which points at C3 > entry. > > This change was booted and measured as a backport on 4.17.6 only. On > staging it is build-tested. It also covers Hygon, as Linux does today > through X86_FEATURE_ZEN; the original Linux commit was AMD-only. > > This will conflict trivially with Alejandro's pending "x86/acpi: Migrate > vendor checks to cpu_vendor()"; happy to rebase on top of it. > > Possibly a backport candidate. Perhaps, yes. > --- a/xen/arch/x86/acpi/cpu_idle.c > +++ b/xen/arch/x86/acpi/cpu_idle.c > @@ -1065,6 +1065,24 @@ static void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flag > */ > if ( c->vendor == X86_VENDOR_INTEL ) > flags->bm_control = 0; > + > + if ( (c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) && > + c->family >= 0x17 ) > + { > + /* > + * For all AMD Zen or newer CPUs that support C3, caches > + * should not be flushed by software while entering C3 > + * type state. Set bm_check to 1 so that Xen doesn't > + * need to execute cache flush operation. > + */ > + flags->bm_check = 1; > + /* > + * In current AMD C state implementation ARB_DIS is no longer > + * used. So set bm_control to zero to indicate ARB_DIS is not > + * required while entering C3 type state. > + */ > + flags->bm_control = 0; > + } > } Linux also deals with modern Centaur (VIA) and Zhaoxin (Shanghai) CPUs. We will want to mirror that too, provided we want to continue this mirroring. Alternatively we could have Linux'es xen-acpi-processor driver invoke acpi_processor_power_init_bm_check() before passing up C-state info. That would imo be better overall, with one downside: Non- Linux Dom0-s would then need to follow suit. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 07:34:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 07:34:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1437987.1656868 (Exim 4.92) (envelope-from ) id 1xCBJP-0002JA-Lb; Thu, 01 Oct 2026 07:34:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1437987.1656868; Thu, 01 Oct 2026 07: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 1xCBJP-0002J3-IW; Thu, 01 Oct 2026 07:34:39 +0000 Received: by outflank-mailman (input) for mailman id 1437987; Thu, 01 Oct 2026 07:34:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCBJO-0002Iv-7b for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 07:34:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCBJN-000pwd-Gm for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:34:37 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe0d0c-2eae-0a2a0a5409dd-0a2a45029532-2 for ; Thu, 01 Oct 2026 09:34:37 +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 6abe0d0d-6ca4-0a2a45020019-4a7de18cd0c0-3 for ; Thu, 01 Oct 2026 09:34:37 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d8239so49787225e9.0 for ; Thu, 01 Oct 2026 00:34: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-4a01f99b113sm55016935e9.14.2026.10.01.00.34.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 00:34: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=1790840077; x=1791444877; 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=xxEOhvYbGWasqHNN4kSw+sfo3fhK1ol662qvyK0BRIg=; b=bII2L9uOfU1PprB65DG5ODpEozQG76/+aN8Ng3RtyaSPSuk0dFia5Z1hnr0Qr8SFVc HcyAC7Is36CxP5bZh5AjB3xWPFXxzvcX5sZ8ZyelAIGV3AGehk348QxhXvSw+jBvEh+C ZYK3VNwYVEqm+4pz8kPQ3fUEh2fburbYRjU7C9T9/gI/A/Xi76rq9ywE20lHOenp+792 fN3Rki+xVOw212ps7nT9IsygzMSJIrHou+hothvWtc8YkGDONEOSVsbfbWEdhCUE3sA8 1ygvVuP6VNyi7QJIC4unXxUxf7LSMuAvpYl2asALZd0Kj56SygM7Boa2R7al54iLddtM aq+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790840077; x=1791444877; 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=xxEOhvYbGWasqHNN4kSw+sfo3fhK1ol662qvyK0BRIg=; b=DuLoJs/lDUyi37Qwh596fYiZfdhGrZ5EKevLeyQmW2touUsq7Bidf9uhbQb7RirROY oipK8AlLU4Po/yBj6gzyMG5qKkGeIXfqtAWarYh+vAH//wFsY1mOkx3NDp8eB5FDd2Di nRcnpht/MHQFLweHACyBIafG9h/7cnwC+L//SbjUlqV5li6q3GngcXU7QuktLboFmLH3 njKNd09eAgZy3BrRR4U9YzmaTeFbqp8NenJntudroUxjcd+5KlsvW0kkwwk4f4GGCYgr hNhVYPr7f6Qhcdb8wjCimIbmaJDXnJy9iubLUPplXj/sVDOV0AxssCugjq5n9D8Vb1Yn rHmA== X-Forwarded-Encrypted: i=1; AKwUvBxeCV1tkGHh9nvgRYc8qChq0bY4bfkUpval8GiqtJQVyNzmF1+HbjrFED51Erfs6u34qgww5ddhz54=@lists.xenproject.org X-Gm-Message-State: AFuF++kiEQHB3SC4dO/WKx5h4GGS5eY1Fcj+DCM8JAPOR29Mwf5z3l+J YJgBKY1tnyk7pdHIlGzAFDfaYf5NDdsIC2vrr60g/pHRC8E14GiLKnXHkzSlvDqpog== X-Gm-Gg: AYBFou0OiEkd9xYDo4h3dcMPENKSZeWT5nlTQ2+HHYNTE6gz7yVh28vMuJHQi+y5PQd h9ySL1xy+4s41mCkjYC4E1FlMjDR4hHxCYrPAJW990at8ONBLUZxwDMSyzAX6sbIZrkK1+Z7LLR DqqnsHBHNPFkOuMRk5P7TttHAJ8FoTnWxZ1RbdZ/l2uBCPzvRhElx1bawjncPM/ScHqe6y1E80+ uAcXZZcMef5KU+QkoJS378NsgHtGbMevOKkvD7Ryz+1zt/VUb+vVv0W2IZ2rHDSsSxWLIyQbz7t m0MTpCi+F4A7uNdHREji+YxOY9gNTUSG23oOLvoFMdMM1uZQByFdZ0wS2vqhM756KhVZChYi+Do ER/0miexkKzR+enA8Sgh6AM7uA+xYRYnAVkByV40ZA73zkDDqTABiUzuI4j+EZdaNFsTV8Cwn+J f8F03eurASB+0e37Mj5ssS2N/gVpk+DPT059Mg1Bbq2PBs0m4kiTDgL6LjdyP0IA1X7qSNyOfbd uwhVF7hK1PTUt39ei4ZHoJAtWsvdcPiVBP3OxlbH8nrxbhwYSk18vfRVms6/lQ= X-Received: by 2002:a05:600c:8b88:b0:4a0:62d:4424 with SMTP id 5b1f17b1804b1-4a01addebd5mr56197735e9.8.1790840075908; Thu, 01 Oct 2026 00:34:35 -0700 (PDT) Message-ID: Date: Thu, 1 Oct 2026 09:34:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260930191104.78141-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: <20260930191104.78141-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790840077-317CA2AC-6949FF58/10/78276251493 X-purgate-type: spam X-purgate-size: 1269 On 30.09.2026 21:11, Roger Pau Monne wrote: > @@ -692,7 +690,9 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > if ( is_pv_domain(d) ) > fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) | > (1U << XENFEAT_highmem_assist) | > - (1U << XENFEAT_gnttab_map_avail_bits); > + (1U << XENFEAT_gnttab_map_avail_bits) | > + (VM_ASSIST(d, pae_extended_cr3) ? > + (1U << XENFEAT_pae_pgdir_above_4gb) : 0); Nit: Unlike binary operators, which we want to have placed at the end of wrapped lines, we generally prefer the ternary operator to be wrapped differently. E.g. (VM_ASSIST(d, pae_extended_cr3) ? (1U << XENFEAT_pae_pgdir_above_4gb) : 0); or (VM_ASSIST(d, pae_extended_cr3) ? (1U << XENFEAT_pae_pgdir_above_4gb) : 0); This isn't written down anywhere, so I'm not going to insist. Furthermore, wouldn't it be plausible to also add IS_ENABLED(CONFIG_PV32) (or, imo less desirably, opt_pv32)? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 07:41:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 07:41:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1437993.1656878 (Exim 4.92) (envelope-from ) id 1xCBPg-0003xl-A2; Thu, 01 Oct 2026 07:41:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1437993.1656878; Thu, 01 Oct 2026 07: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 1xCBPg-0003xe-6X; Thu, 01 Oct 2026 07:41:08 +0000 Received: by outflank-mailman (input) for mailman id 1437993; Thu, 01 Oct 2026 07:41:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCBPe-0003xY-DA for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 07:41:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCBPd-00DRPc-JQ for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:41:05 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe0e87-e002-0a2a0a5209dd-0a2a4504be6c-16 for ; Thu, 01 Oct 2026 09:41:05 +0200 Received: from [74.125.225.106] (helo=mail-wr2-f42.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe0e91-b57f-0a2a45040019-4a7de16a8144-3 for ; Thu, 01 Oct 2026 09:41:05 +0200 Received: by mail-wr2-f42.google.com with SMTP id ffacd0b85a97d-48b0622cc90so388183f8f.1 for ; Thu, 01 Oct 2026 00:41: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-4a01ff0cd17sm42938975e9.9.2026.10.01.00.41.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 00:41: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=1790840465; x=1791445265; 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=lITFgfzjfsByQ6k+Lmt1KlvLk2Xf1eVIo0/bN64sKHQ=; b=Qg2oJdCRSee0ZOXmb/GDkPfUGmQT55mF9UCZCkYjW+FDMd8az4ZyknxNnw7vGLkQna N4p189ScVW1hI3alxf7+HqiNm/qYmv71lhz1s8VTiHcc1VwV81tjcmy3cCkfggsV4Pye Ph40TMhhVjL0v+BnTtVB0d1+vSRigupKwhu2U07HMSdljCYR9S0oHKARPhehA9Y+k4cO Umv8WA/AdfQcYD1jOJsoY9TvNCfyJ45LgiVEnEYrC7dqpmssz5kdS69pBzSIz4gMtdFK oT8DjHd+8pS288LNJSY7L3agB3zgXYoQnBn5zJzCQSBlQX/lod6vxm7xAE2mT/DIqAHL 0Jsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790840465; x=1791445265; 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=lITFgfzjfsByQ6k+Lmt1KlvLk2Xf1eVIo0/bN64sKHQ=; b=CvkIzO3K2RdF4yBrrmSDP8sbZcPt4z9t5j2zQfksL6oTc6stsZTVPmFWedNjr5ePUx 52UJr9a7v6ThA/NTe16ptpA5k/z2zIWH0q3zhjFp+TdzDyKqJw+0cBx2xpPNbusg/nVF 93IBob4S8DXkj3ZbccV5OGsq5BU1PYHXnZb4jDrdnpNpuxPavyDIfMyjxKhuK/3jWOhg LLl7rPMPB9vZppANx3WiuTh4yZcVM5OfHp86O1aNzNslSFdjVreIITO1DBchdgi9hp3A 3kIJeRFnZl1EYfxxx18uVDIvSNZbAic8WLp2WBYjvZtyRCqsVoAAFsa1E9LLcpUHcpdI aQag== X-Forwarded-Encrypted: i=1; AKwUvBwR54uyxy1ZIAajxw+zT4TpSyeCslCJyYfd7k7G9hSy+Hi4xTc/st0OCnjsSlgNDFW3RVPWcyfAK2Y=@lists.xenproject.org X-Gm-Message-State: AFuF++luz3W4dYRF4N1i63K/9A50LdVGNkRqDttFj9igZBlEtTTfWd7E YUSU0VjfJkgjhZ3UzOw7GcfHm+sIhnBcuvLI2jfb5yUUmZGMvPBkKazDXONtbeLjWQ== X-Gm-Gg: AYBFou2/ldeWlVHpLcXDIeKx6FFExWy8VoTEPuHD6rYnOXZHd2VonEejYMrDaZ8bkUH VA65OkdgFzjtERxJrnqF8MmSnZ77oJnl5ou/RyPPCZPaXU8CVDSXB3TjPyz865LGXJvWJ8y89Da aMvI5F/9xyPt5izgndrooTLyuR9jzAecsusV7Jlir7R1GGEa0A/Eeyt1IBp+C8AIhQ5g4mtXmEt Qs8L44gXp8x5AIe50M4bYmAH+8Hdgi/K8dMUVKxFUuOsvS9oO0FRSqZQZCNk/ZJ7Yp5HhtMTY9U Plh0cmVZ+mSLTAxXXHoL2QsNG0k9zF2FfzTKwM0nG8q1BvdKOQwGrgFVUAAxq7oA7YA+d+0YsX4 2bxF2RQLjZp3MhafqSEeXozN3iFDY9hoANx+cnmRb6/oSoiY+qGq78ca+0jCVzZmU03vjoh0lv7 7aedhJoqlFCzSCbykexSEh8TJwlW1zk+cKBvAr+yLqXZHNMAsaa0vXvduwLgO85vhdLwJSmtz8t mUQOPHmWC1sAMHe+ItGpdHxLdTg/aKVSIRs+mQMuZ5J0RcSeuuwJXriunGU4tY= X-Received: by 2002:a05:600c:6815:b0:49f:cbf3:551c with SMTP id 5b1f17b1804b1-4a01b004e5bmr65470095e9.12.1790840464704; Thu, 01 Oct 2026 00:41:04 -0700 (PDT) Message-ID: <48532706-23bc-4204-8ad4-8e67c53a2ba5@suse.com> Date: Thu, 1 Oct 2026 09:41:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/6] xen/riscv: rename PTE "permissions" to "pte_flags" To: Oleksii Kurochko , Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , xen-devel@lists.xenproject.org References: <1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech> <1790699585.8631fc262581453bbf619ec5b2062170.1a0ee033eb9000b504@vates.tech> <9f94af4b-f122-46e0-bbc4-7fecd51d4348@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: <9f94af4b-f122-46e0-bbc4-7fecd51d4348@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1790840465-C36C2B50-A35A8D52/10/78276251493 X-purgate-type: spam X-purgate-size: 647 On 30.09.2026 15:42, Oleksii Kurochko wrote: > On 9/29/26 6:32 PM, Baptiste Le Duc wrote: >> @@ -149,13 +149,13 @@ static void __init setup_initial_mapping(struct mmu_desc *mmu_desc, >> >> if ( is_kernel_text(addr) || >> is_kernel_inittext(addr) ) >> - permissions = >> + pte_flags = >> PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; > > Nit: it could be one line now. I'll do not just that, but also correct indentation at the same time. With correct indentation it could have been one line already before. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 07:44:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 07:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1437999.1656885 (Exim 4.92) (envelope-from ) id 1xCBT8-0004Tq-Mw; Thu, 01 Oct 2026 07:44:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1437999.1656885; Thu, 01 Oct 2026 07: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 1xCBT8-0004Tj-KJ; Thu, 01 Oct 2026 07:44:42 +0000 Received: by outflank-mailman (input) for mailman id 1437999; Thu, 01 Oct 2026 07:44:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCBT7-0004Td-BU for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 07:44:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCBT6-00DS7B-8B for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:44:40 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe0f63-bab6-0a2a0a5309dd-0a2a4507e784-4 for ; Thu, 01 Oct 2026 09:44:35 +0200 Received: from [74.125.225.100] (helo=mail-wr2-f36.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe0f63-b4ea-0a2a45070019-4a7de164802b-3 for ; Thu, 01 Oct 2026 09:44:35 +0200 Received: by mail-wr2-f36.google.com with SMTP id ffacd0b85a97d-48b0fc598f8so42380f8f.2 for ; Thu, 01 Oct 2026 00:44: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-4a023ebe694sm18188195e9.10.2026.10.01.00.44.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 00:44: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=1790840675; x=1791445475; 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=k4n2RxWwCoh6PnTESTZx/CIsuf6yjka1yL2L+4ZsDN4=; b=B6gNhddzyOoiBATemoPNKfgZhevevrvkG3Id+xp5HsSqGd/+1WEUxiTiBBY8ht7748 VUbW82Z9CCFXJCNe673bslLU5vgBUXf8C2bb1HDPkCLMaGb4lNT9BCgZUaT98Gc4Q+Dz LiKlzlghWtekTAlc7mJxdg7VXzO8TsK3OiPdyTLk0Y1rP/d9i9qAtQ5/l/0a+uZLTAzu is3N7EXSpj/84MWBXVVv0Unr64sfLCgMD+LKhlj4E34EYGI/fVJYIY54wzNXzR4MMv60 81rpjzaLjNVIMRZPWCKF8P5mMAP/8l/YEwRpmOrEsBNb2D/b9RRWpsExUmEu/q8wArP1 NY8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790840675; x=1791445475; 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=k4n2RxWwCoh6PnTESTZx/CIsuf6yjka1yL2L+4ZsDN4=; b=z3OBylCQOTZFixCT140vE3jOlftEqs3VVNST6TT3aQnuxIEY8G5+sXvEkpIR1sXrWl ORUqM5vdFcFReidJ1mYNsrDwKpamMiK7s0/P3q/Prv2w5EsQfSt8nOH/RLclcnB2Khm6 cudflNtvnFz8QkHJVIj1iwL7KzoPAtcLc/RKeEzQDQhNC+OzwM3fxzF3oqjtlV+OpqqA Yoq5uULQLY9rArJB7oplkUI8VRuZgGI1j6nUb3WLQolG1axwOzAsIlh/XP6vrWieb0jk k8x3QN4ZMOLYgLJxpvudCCwknWJ8os/WaDe6cyE08JDJD5mced/7pJDk3vFb3PQRM4UR rZpA== X-Forwarded-Encrypted: i=1; AKwUvBxX5epGElAdLx9ffKP9oOFfQfLWgmZpgrWJQg4IQfqPB1UkMvdsWN0EJUejWWFk2Cal8S7R7M4K21s=@lists.xenproject.org X-Gm-Message-State: AFuF++n3bP3o7x7apOfUKGRb3YuXw1JQQsB5Z9gQd5+0tc762TN9EsTc fLDpIAvQc6Bt6CO65/+LaD6+1jM9nCUzm9yJobCBkXGjizVCMoGtBuV+VbhqcGqMQQ== X-Gm-Gg: AYBFou0/3jSp1t/QkwTrP7z28h+qipl5tA/rC5U2dGr6SY+3umpv1s64VNGtxm58+zl D/JQPgpi+n5zNvG3LLQHgRYod4UXb+aFbIE+LZ9fH1CRSJseFcYDLz5EsfaT81RDJEZdRwxajZx 3/8Bw+kTA/+eMe0207eOkC2v2o6HEmn0dDsEL+7zfnYVGPTZ4sT/7zLl0TFU6+o5jwgP2irHeR9 +/EvAfdor0Qddw5rHWz/6AL04tYAMGGxtRk4uIQkzFf0KFjonbLH8LBPitPoeIf2WsiO1JkFOVa HyHueL2MwkfRki1OFmwjzW09AtJa3qBeYkLO1UResRTTGyrl3Qv+xyxPqLJgQQwAcZOS6yo1nLs rc/pWjZ2AQXICU0c6aXgwUS6rh3k7fPitNBGuH9J7CTsdRi1XBESB3GZ74Vjy8/zxJhorkIuy+z wxKcZlpz7dNGTUcMb7Em63IKEw+4SSxOyadP8nWwl06ZsLfpZumt/xRZhWrVXXqLeeZcC7qj+/M y5jA7B2nv4RXNih53C12eP2iAc3cmfJH3l8ZjwkgBVznrQkeFOyzRZ8NkqBNJuFD/v4FDjS X-Received: by 2002:a05:600c:45d3:b0:4a0:53e:b7d6 with SMTP id 5b1f17b1804b1-4a01aff8082mr56251885e9.16.1790840675251; Thu, 01 Oct 2026 00:44:35 -0700 (PDT) Message-ID: Date: Thu, 1 Oct 2026 09:44:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/ioreq: drop the emulator reference when range set allocation fails To: "Edgar E. Iglesias" Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260929170835.964609-1-edgar.iglesias@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: <20260929170835.964609-1-edgar.iglesias@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790840675-A6AD8AE4-CC0E7CCF/10/78276251493 X-purgate-type: spam X-purgate-size: 570 On 29.09.2026 19:08, Edgar E. Iglesias wrote: > ioreq_server_init() takes a reference on the emulating domain before > allocating the server's range sets, but does not release it when that > allocation fails. The leaked reference prevents the emulating domain > from ever being fully destroyed. > > Route this failure through the existing put_domain() cleanup. > > Fixes: ccb42e0ca661 ("x86/hvm: take a reference on ioreq server emulating domain") > Signed-off-by: Edgar E. Iglesias Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 01 08:29:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 08:29:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438029.1656895 (Exim 4.92) (envelope-from ) id 1xCCAW-0002iV-D1; Thu, 01 Oct 2026 08:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438029.1656895; Thu, 01 Oct 2026 08: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 1xCCAW-0002iO-9L; Thu, 01 Oct 2026 08:29:32 +0000 Received: by outflank-mailman (input) for mailman id 1438029; Thu, 01 Oct 2026 08:29:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCCAU-0002iI-V3 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 08:29:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCCAR-009L3t-05; Thu, 01 Oct 2026 08:29: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 1xCCAQ-001qM0-2u; Thu, 01 Oct 2026 08:29: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=ERCkGy06F6WaYlQs1OJpg1kfBZNvGF0EFHPqMlyYbZw=; b=WHzvazPuYkujEX6olOCjuiM2ib d6hRd2lY5ZQn+kK9IlJM0H9X3N4DjYpaC3SGDfDex8aHSJQM/0UkaTwvo5yM8jA4Aztk1vfVArkH9 rjmQv+9cA1+qwo8PzBldO5NwY1ooHgeVI/be8LtsrwpLQFCn/svM+yJf8YY+FP5R0Z4Q=; Date: Thu, 1 Oct 2026 10:29:20 +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] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests Message-ID: References: <20260930191104.78141-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Oct 01, 2026 at 09:34:34AM +0200, Jan Beulich wrote: > On 30.09.2026 21:11, Roger Pau Monne wrote: > > @@ -692,7 +690,9 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > > if ( is_pv_domain(d) ) > > fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) | > > (1U << XENFEAT_highmem_assist) | > > - (1U << XENFEAT_gnttab_map_avail_bits); > > + (1U << XENFEAT_gnttab_map_avail_bits) | > > + (VM_ASSIST(d, pae_extended_cr3) ? > > + (1U << XENFEAT_pae_pgdir_above_4gb) : 0); > > Nit: Unlike binary operators, which we want to have placed at the end of > wrapped lines, we generally prefer the ternary operator to be wrapped > differently. E.g. > > (VM_ASSIST(d, pae_extended_cr3) > ? (1U << XENFEAT_pae_pgdir_above_4gb) : 0); > > or > > (VM_ASSIST(d, pae_extended_cr3) > ? (1U << XENFEAT_pae_pgdir_above_4gb) > : 0); > > This isn't written down anywhere, so I'm not going to insist. I had it written as your first proposal, but then moved the ternary operator at the end of the line as I've assumed it would be prefer to match the position of the binary ones. > Furthermore, wouldn't it be plausible to also add IS_ENABLED(CONFIG_PV32) > (or, imo less desirably, opt_pv32)? I could do: if ( IS_ENABLED(CONFIG_PV32) && VM_ASSIST(d, pae_extended_cr3) ) fi.submap |= 1U << XENFEAT_pae_pgdir_above_4gb As I think adding the IS_ENABLED(CONFIG_PV32) check to the previous expression is too much. Let me know your preference. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:04:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:04:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438047.1656924 (Exim 4.92) (envelope-from ) id 1xCCiS-0008Lo-36; Thu, 01 Oct 2026 09:04:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438047.1656924; Thu, 01 Oct 2026 09:04: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 1xCCiR-0008Lh-WA; Thu, 01 Oct 2026 09:04:35 +0000 Received: by outflank-mailman (input) for mailman id 1438047; Thu, 01 Oct 2026 09:04:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCCiP-0008Lb-NX for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:04:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCCiO-00DlBv-M9 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:04:32 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe221d-8faa-0a2a0a5109dd-0a2a4503dabe-24 for ; Thu, 01 Oct 2026 11:04:32 +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 6abe221f-fae8-0a2a45030019-b9ff1c129739-3 for ; Thu, 01 Oct 2026 11:04: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 1a0f6b5397a0003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Oct 2026 09:04:27 +0000 Received: from leducb.home (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 ECD7482991; Thu, 1 Oct 2026 11:04:25 +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=+8QBoOIKOWfF9rnN5stnQrG/hubBCM2JvyP2H7Td2yY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=nqrKHxssMdhd7GAORWMs0Tvyc+o0ZWeko4ceHwC9M7FR6mvvLZ97NPW3jFuihpFTGcFhsdbii 3kSMJ/QzFAmwX5l+hnQs3sFVL+szOgck1PdUxANxSKAOHgpmWP9ZYBQ8geGIiMaR9yFsNmTyPHw O/ii2wgondyi/RAxG2wYrbpmDt9Nf6veHmSvDyxvqsK5kmMJfkofL4fS/eZCEsBzleEGBTUPvj7 ouYaLlK1sm7RSSyxPvR9MJPEK1ICkSZ1yAPWlD8IgNB8m/EO7aiVz9DEdwVpN2LqOwXahhevs6P 0ef1IjQVXW2sSuLyxQdnTMiILCgexcmUmIzPJlb1RR4g== X-Zone-Loop: 076be8fcac45071a0968a546e370431a92c87ffad0eb x-campaign-type: default x-transaction-id: d326a497-6f29-48f0-b832-bb067ebfdf75 x-swg-uid: 01-37574318-7091-46b3-b068-3a4851b3a831 X-Mailer: Sweego Message-ID: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> x-swg-bid: 1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v4 0/4] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Thu, 1 Oct 2026 11:04:15 +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=1790845141; l=3999; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=e2CqMJBv1Bm2wnQbRMy0Yn2dXx+BC5kTAZ1V7P6Uj+I=; b=sMBDyUgr16GLJd04ICfFhZTil8DmWZT2Be6hVA3DoTygSSMqYYijSh2u2FV6QIJ29ivY1FjuC N8DMGt8NFdmClLNDJsgGSqgUStmiYCkULZDdl1I+P9gCtepYnqrt3EZ 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: 1790845466176 X-purgate-ID: tlsNG-33051d/1790845472-6E0D14E9-AF9C9876/10/78276251493 X-purgate-type: spam X-purgate-size: 4001 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: Rename PTE "permissions" to "pte_flags" 2: Always preset A/D bits in G-stage PTEs 3: Fix A/D bit handling in Xen's page-table mappings 4: Use pte_is_valid() in pte_is_mapping() CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2900391526 --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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: xen-devel@lists.xenproject.org Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: Roger Pau Monné Cc: Stefano Stabellini Cc: Alistair Francis Cc: Connor Davis Cc: Oleksii Kurochko Cc: Zheng Zhang --- Baptiste Le Duc (4): xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: always preset A/D bits in G-stage PTEs xen/riscv: fix A/D bits in Xen's page-table mappings xen/riscv: use pte_is_valid() in pte_is_mapping() xen/arch/riscv/cpufeature.c | 1 - xen/arch/riscv/include/asm/mm.h | 5 +++-- xen/arch/riscv/include/asm/page.h | 35 ++++++++++++++++---------------- xen/arch/riscv/mm.c | 14 ++++++------- xen/arch/riscv/p2m.c | 42 ++++++++++----------------------------- 5 files changed, 37 insertions(+), 60 deletions(-) --- base-commit: 4c1aba82cff95ab11f7fe4af8965a06703537288 change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:07:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:07:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438053.1656933 (Exim 4.92) (envelope-from ) id 1xCClK-0000RY-Fd; Thu, 01 Oct 2026 09:07:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438053.1656933; Thu, 01 Oct 2026 09:07: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 1xCClK-0000RR-CV; Thu, 01 Oct 2026 09:07:34 +0000 Received: by outflank-mailman (input) for mailman id 1438053; Thu, 01 Oct 2026 09:07:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCClJ-0000RL-8P for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:07:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCClI-007rtg-L8 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:07:32 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe22d4-e002-0a2a0a5209dd-0a2a450b9688-0 for ; Thu, 01 Oct 2026 11:07:32 +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 6abe22d4-b7e8-0a2a450b0019-b9ff1c22802d-3 for ; Thu, 01 Oct 2026 11:07: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0f6b801920003f66.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Oct 2026 09:07:29 +0000 Received: from leducb.home (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 7AEC782407; Thu, 1 Oct 2026 11:07: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: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=hIXBqLlDxx0K/kQnZq8JWDabTK1TpS/NxsX703pn8ic=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=H3+O53pYPeRZ9qrUglXRshbWWs397qeocUlaJUObrmfCZ8sfVX9ZgGQqIqBTIs06KI4b3YkH7 aQN0O1JEdDdpUxBpwUF5oTLVs7Qf0OGvRUO5SUdRN2dGE3DOBsJqzaHkNvXDdAfwTiroF03mtVf vlc+IlBj7OwWBn1o02I0t3xqArX1FbcFYx0UOGiez5WO+asR7SZQpC0cRfLevCU5969iFAv3Xt5 gO/DBvU/nwP7FiE0L/JAR3rfCI4F01UGyiOnspQE98frIeAEp1Xy8MJhsu1Od23WHmsF40Swmgc La5VN/qDHT5J/62Om+bSICbRwQ1702FkTPp04DEP7h1Q== X-Zone-Loop: 2004158124ce4150e84e21f7f2c5d74ccb3b91e1583f x-campaign-type: default x-transaction-id: 0f6fabbf-ea14-4bbe-8d6c-5c8504b73a66 x-swg-uid: 01-4623a960-a353-4396-94b7-ca4492c5c873 X-Mailer: Sweego Message-ID: <1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b801920003f66@vates.tech> x-swg-bid: 1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b801920003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko Subject: [PATCH v4 1/4] xen/riscv: rename PTE "permissions" to "pte_flags" Date: Thu, 1 Oct 2026 11:07:20 +0200 In-Reply-To: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1790845141; l=3824; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=XdiiczWFyM/LIOzMORFXdmlnH1HzIt2R6VuUNrV2b20=; b=zSkFUNXea73u4ALYVErAA0YFHJ6H5j9PC7kfm/v/aFUM/NiaZducfZe4uz43GsxUbm1YyQnsn NqcNyHeILROCMkDkEwnEXSBfcxbozateW2s8FIrLeoGbQ7JztEFGtzX 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: 1790845648690 X-purgate-ID: tlsNG-42698a/1790845652-1BAD09EA-4C94B252/10/78276251493 X-purgate-type: spam X-purgate-size: 3826 paddr_to_pte()'s "permissions" parameter, the matching local in setup_initial_mapping() and p2m_set_permission() don't only deal with permission bits: they also handle PTE_VALID, PTE_USER, PTE_ACCESSED and PTE_DIRTY. Rename them to "pte_flags" and p2m_set_pte_flags() respectively. No functional change. Requested-by: Jan Beulich Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Acked-by: Jan Beulich Reviewed-by: Oleksii Kurochko --- Changes since v3: - apply nits: fix indention and line length --- Changes since v2: - new patch --- xen/arch/riscv/include/asm/mm.h | 5 +++-- xen/arch/riscv/mm.c | 12 +++++------- xen/arch/riscv/p2m.c | 4 ++-- 3 files changed, 10 insertions(+), 11 deletions(-) diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h index 9e28c24954..1ac66283ec 100644 --- a/xen/arch/riscv/include/asm/mm.h +++ b/xen/arch/riscv/include/asm/mm.h @@ -22,9 +22,10 @@ extern vaddr_t directmap_virt_start; #define paddr_to_pfn(pa) ((unsigned long)((pa) >> PAGE_SHIFT)) static inline pte_t paddr_to_pte(paddr_t paddr, - unsigned int permissions) + unsigned int pte_flags) { - return (pte_t) { .pte = (paddr_to_pfn(paddr) << PTE_PPN_SHIFT) | permissions }; + return (pte_t) { .pte = (paddr_to_pfn(paddr) << PTE_PPN_SHIFT) | + pte_flags }; } static inline paddr_t pte_to_paddr(pte_t pte) diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c index 610d111945..a9bce48f4a 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -140,22 +140,20 @@ 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 pte_flags = PTE_LEAF_DEFAULT; unsigned long addr = is_identity_mapping ? page_addr : virt_to_maddr(page_addr); pte_t pte_to_be_written; index = pt_index(0, page_addr); - if ( is_kernel_text(addr) || - is_kernel_inittext(addr) ) - permissions = - PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) + pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; if ( is_kernel_rodata(addr) ) - permissions = PTE_READABLE | PTE_VALID; + pte_flags = PTE_READABLE | PTE_VALID; - pte_to_be_written = paddr_to_pte(paddr, permissions); + pte_to_be_written = paddr_to_pte(paddr, pte_flags); if ( !pte_is_valid(pgtbl[index]) ) pgtbl[index] = pte_to_be_written; diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 1cea86512c..f7b380b90a 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -584,7 +584,7 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_cache) p2m_write_pte(p, pte, clean_cache); } -static void p2m_set_permission(pte_t *e, p2m_type_t t) +static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) { e->pte &= ~PTE_ACCESS_MASK; @@ -676,7 +676,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, break; } - p2m_set_permission(&e, t); + p2m_set_pte_flags(&e, t); p2m_set_type(&e, t, ctx); } else -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:07:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:07:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438054.1656941 (Exim 4.92) (envelope-from ) id 1xCClM-0000fw-LF; Thu, 01 Oct 2026 09:07:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438054.1656941; Thu, 01 Oct 2026 09:07: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 1xCClM-0000fp-IP; Thu, 01 Oct 2026 09:07:36 +0000 Received: by outflank-mailman (input) for mailman id 1438054; Thu, 01 Oct 2026 09:07:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCClL-0000e4-Sj for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:07:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCClL-007rtg-9E for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:07:35 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe22cc-e002-0a2a0a5209dd-0a2a45089f36-40 for ; Thu, 01 Oct 2026 11:07:35 +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 6abe22d6-f659-0a2a45080019-b9ff1c12aacb-3 for ; Thu, 01 Oct 2026 11:07: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0f6b802ba0003f66.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Oct 2026 09:07:29 +0000 Received: from leducb.home (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 F228B82822; Thu, 1 Oct 2026 11:07: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: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=3Nu2EZlD98K/MXSzGeXg5tJpAaR1zvomAjzcgvpDzY4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=eHTw04akdVol0XAR6wGUTjek7i6ktEPyMdZidWij/c+XOH69qDV1oUQkQWRh/CsNYyL/m492M UqNurShKqyGZw2CqLn8a65Sf6WHzakClQF6+QFUa+Nxje6iGJ6Hx3HEqQ+wXqfnIc6vTbOQaZvR YbS6vvFK3TxLsFAox5iuhK3uJzgg8LuOyLwRIZP8PSmS22zXf2ylqP1iWySs4O2HebDwh/zzNNV WzfkdWHCCVC+68x6PRfmkWLofVasdWztYhvM3yHifcuK4IDmUydiBFQHVMpRyMNr9JS4x7ev/A3 ga/Va24Rfp88rW2hVPLjpgwW/nq/hTsQZ4rOOVpl6M/A== X-Zone-Loop: 2ce5b88c6c5600f5606676ab701878a08f6c75fa748c x-campaign-type: default x-transaction-id: d907646b-f0ef-45ae-a839-1062d9b67e84 x-swg-uid: 01-b9dbe8a3-e26e-4dd3-8703-f68304a03e2e X-Mailer: Sweego Message-ID: <1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b802ba0003f66@vates.tech> x-swg-bid: 1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b802ba0003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko Subject: [PATCH v4 2/4] xen/riscv: always preset A/D bits in G-stage PTEs Date: Thu, 1 Oct 2026 11:07:21 +0200 In-Reply-To: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1790845141; l=5658; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=PoPk/QVFnUoQZeUjxpShJhErKRSH6TrnENPhLu0P/bs=; b=IFSNIfvThy14TSkfMCyitW62vTTvi+Da75QiD9IOIAH6EbRluogl3jupFz+MNHNRCCfOLJv5J mSN2TilZOhTAT72YWtxXjake4w8s++yjR+QHEiwDCBqvxQAOXlJkHrX 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: 1790845649169 X-purgate-ID: tlsNG-c1860d/1790845655-CE94287B-0F4A9DD1/0/0 X-purgate-type: clean X-purgate-size: 5660 A RISC-V implementation can manage the PTE A/D bits in one of two ways: 1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). 2) Generate a page fault when 'A' and/or 'D' is clear, so that software can set them (ratified as Svade). p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device tree advertises Svade. Platforms that use scheme (2) without advertising Svade, such as the HiFive Premier P550, then hit guest-page faults that Xen does not handle. Always preset A/D in G-stage PTEs so scheme (2) never faults. This is harmless with (1): software just does what hardware would have done on first access. Drop the now-unused svade entry from riscv_isa_ext[], and the TODO about handling A/D faults, since nothing uses that information yet. 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 v3: - always preset A/D bits in G-stage mappings instead of keying off the DT: it may not reflect what the hardware actually does. - change commit title/message. - drop svade as it is now-unused. --- Changes since v2: - change commit title. - preset A/D bits in p2m_set_pte_flags() if (!svadu || svade), instead of setting RISCV_ISA_EXT_svade in the riscv_isa bitmap for cases 1, 2 and 4. - riscv_resolve_ad_scheme() now only warns when both Svade and Svadu are present and SBI FWFT is missing; drop the dead 'svadu && svade' operand. - repeat XENLOG_WARNING on each line of the warning. - drop ASSERT(svade != svadu) from p2m_set_pte_flags(). - only add the sbi_probe_extension() declaration to sbi.h. - rework the comment in p2m_set_pte_flags(). --- 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 | 1 - xen/arch/riscv/p2m.c | 38 ++++++++------------------------------ 2 files changed, 8 insertions(+), 31 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index aaf544d13f..6d3c15a37f 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -199,7 +199,6 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { 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), }; diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index f7b380b90a..14cae7dcd7 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -591,38 +591,16 @@ static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) 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. + * A RISC-V implementation can either: + * 1) Update the 'A' and 'D' PTE bits in hardware. + * 2) Generate a page fault when 'A' and/or 'D' is clear, so that + * software can set them. * - * 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. - * - * 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. + * Xen supports both, so set 'A' and 'D' up front to avoid the faults + * of (2). This is harmless with (1): software just does what hardware + * would have done on first access. */ - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) - e->pte |= PTE_ACCESSED | PTE_DIRTY; + e->pte |= PTE_ACCESSED | PTE_DIRTY; switch ( t ) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:07:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:07:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438055.1656951 (Exim 4.92) (envelope-from ) id 1xCClQ-0000xc-0F; Thu, 01 Oct 2026 09:07:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438055.1656951; Thu, 01 Oct 2026 09: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 1xCClP-0000xQ-Sm; Thu, 01 Oct 2026 09:07:39 +0000 Received: by outflank-mailman (input) for mailman id 1438055; Thu, 01 Oct 2026 09:07:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCClO-0000vR-TB for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:07:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCClO-007rz7-9c for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:07:38 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe22d4-e002-0a2a0a5209dd-0a2a450b9688-36 for ; Thu, 01 Oct 2026 11:07:38 +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 6abe22d4-b7e8-0a2a450b0019-b9ff1c22802d-4 for ; Thu, 01 Oct 2026 11:07: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 1a0f6b803f90003f66.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Oct 2026 09:07:29 +0000 Received: from leducb.home (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 46CF98283A; Thu, 1 Oct 2026 11:07:29 +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=aqjSWKhom+EllHagP7vIaGwtm55nQ/Lm4ovQZLM51hU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=sFzw3HmUKxu3SaK84FES6cylk9sab5nVFur1n2ci7fIz2G8gXwHcsej7//FAVzNDMWQ0W9UwH ngAmjy1VhwquRslpmDM0HVzPH1u/0/QTlUwndElOzeSdEpu6VCsemDnrd18TmzCfX3+GaZ4gmLa pkisLawPLikdaVKz3jfQbuIREGST/HPYOdjn4VAg4rfODoPIGezWJpdhhuYpTVx7ebv90pH9gC2 xw2OUtObgfuFvbDr4HRnjWqt0mjXI+VImynTDNzTyLEEAE8oC1EiNLhfc9DgIbN02cov1iR9LEg 6JeaB9MBZ3Yz8N/CVm02p0qCkrIKdPE4BgWHcTEIvJhw== X-Zone-Loop: 8f542c57e0fcbcb0ae8429d1c1c66e312814cdbfebb0 x-campaign-type: default x-transaction-id: 982a716b-17eb-4606-a09e-094b31cb8b7a x-swg-uid: 01-34b648bd-5b7d-4fca-8880-4fbc668365be X-Mailer: Sweego Message-ID: <1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b803f90003f66@vates.tech> x-swg-bid: 1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b803f90003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko Subject: [PATCH v4 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings Date: Thu, 1 Oct 2026 11:07:22 +0200 In-Reply-To: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1790845141; l=7385; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=dwsW0rW2RXWzTl0I0RDM6CrL2fok5jqVeN/cSdcD6mc=; b=NImNhHyOZvEnef7AUZniCiif1O8wmWuC7RcJfWGY1oz6sNaQ/pdpZzymOku4WRqNnftWlkZWE hjPhDlxl7xpCOdbVcCiiLg31XRM5Tr5ecugFSfyU5JO7GTiNEQTLHSm 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: 1790845649469 X-purgate-ID: tlsNG-42698a/1790845657-A92CC9EA-3C85C45A/0/0 X-purgate-type: clean X-purgate-size: 7387 Xen does not handle page faults caused by clear A/D bits, so it presets them when creating PTEs. pt_update_entry() does so, but three places build leaf PTEs directly without going through it: setup_initial_mapping() (the boot page tables), check_pgtbl_mode_support() (the temporary root entry used to probe SATP mode support) and arch_pmap_map() (the fixmap). Without Svadu, all three fault on first access. For check_pgtbl_mode_support(), the fault is raised by the instruction fetch right after the SATP write, before any trap handler is set. Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in all cases for consistency with pt_update_entry() which sets it at runtime. 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 check_pgtbl_mode_support() to use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also carries A and D, a reserved PTE with A or D set would no longer be caught. Mask with the V, R and W bits explicitly instead, and factor the check out into pte_has_reserved_rwx(). Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v3: - rebase patch 2/6 which modified wrong indentation. - change commit message to address review comments. --- Changes since v2: - add fixes commit ref. - add A/D bits to PAGE_HYPERVISOR_RO and derive PAGE_HYPERVISOR_RW/RX from it for consistency with runtime. - introduce pte_is_reserved() to factor out the reserved-encoding assert shared by pte_is_table() and pte_is_mapping(). - reword commit title --- 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 | 33 +++++++++++++++++---------------- xen/arch/riscv/mm.c | 8 ++++---- 2 files changed, 21 insertions(+), 20 deletions(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index b465a90325..8a3e3e1e66 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -46,12 +46,12 @@ #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 | PTE_DIRTY) +#define PAGE_HYPERVISOR_RW (PAGE_HYPERVISOR_RO | PTE_WRITABLE) +#define PAGE_HYPERVISOR_RX (PAGE_HYPERVISOR_RO | PTE_EXECUTABLE) #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW /* @@ -161,31 +161,32 @@ static inline bool pte_is_valid(pte_t p) * X W R Meaning * 0 0 0 Pointer to next level of page table. * 0 0 1 Read-only page. - * 0 1 0 Reserved for future use. + * 0 1 0 Reserved for future use. [1] * 0 1 1 Read-write page. * 1 0 0 Execute-only page. * 1 0 1 Read-execute page. - * 1 1 0 Reserved for future use. + * 1 1 0 Reserved for future use. [2] * 1 1 1 Read-write-execute page. + * + * So if V=1 and W=1 then R also needs to be 1 as R = 0 is reserved for + * future use ([1], [2]). */ +static inline bool pte_has_reserved_rwx(pte_t p) +{ + return (p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) == + (PTE_VALID | PTE_WRITABLE); +} + 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(!pte_has_reserved_rwx(p)); return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID); } static inline bool pte_is_mapping(pte_t p) { - /* See pte_is_table() */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); + ASSERT(!pte_has_reserved_rwx(p)); 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 a9bce48f4a..6f7dcd10b2 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 pte_flags = PTE_LEAF_DEFAULT; + unsigned int pte_flags = PAGE_HYPERVISOR_RW; unsigned long addr = is_identity_mapping ? page_addr : virt_to_maddr(page_addr); pte_t pte_to_be_written; @@ -148,10 +148,10 @@ static void __init setup_initial_mapping(struct mmu_desc *mmu_desc, index = pt_index(0, page_addr); if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) - pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + pte_flags = PAGE_HYPERVISOR_RX; if ( is_kernel_rodata(addr) ) - pte_flags = PTE_READABLE | PTE_VALID; + pte_flags = PAGE_HYPERVISOR_RO; pte_to_be_written = paddr_to_pte(paddr, pte_flags); @@ -196,7 +196,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 Oct 01 09:07:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:07:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438056.1656959 (Exim 4.92) (envelope-from ) id 1xCClR-0001BA-5W; Thu, 01 Oct 2026 09:07:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438056.1656959; Thu, 01 Oct 2026 09:07: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 1xCClR-0001B3-2W; Thu, 01 Oct 2026 09:07:41 +0000 Received: by outflank-mailman (input) for mailman id 1438056; Thu, 01 Oct 2026 09:07:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCClP-0000x7-Hi for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:07:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCClO-007rva-UA for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:07:38 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe22d4-e002-0a2a0a5209dd-0a2a450b9688-46 for ; Thu, 01 Oct 2026 11:07:38 +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 6abe22d4-b7e8-0a2a450b0019-b9ff1c22802d-5 for ; Thu, 01 Oct 2026 11:07: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 1a0f6b805100003f66.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Oct 2026 09:07:30 +0000 Received: from leducb.home (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 8F6A082407; Thu, 1 Oct 2026 11:07:29 +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=JWn/eI0mKHCbdbf7soqSHQzjnaq/nAVioq6WQKxzwjM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Y4n3WwzicjQunhpiFzvVN+Nb8ldKHuzwyzaxzmzkMGodtb7I/5OJXk9QooF0p0R39/nmS/79/ iSfkMxTc+g2k82eighvZx6poAoSXUVjWkLlSE9lZbEvAlHWT2A6aqKpgMM9J1NLAwrKw4cl3sWF jjspaQHsnpOeOXBq8UUNP5x43mjllXCXhA6ig6/KXxHaFPmAChnEpw6TwY8DDi8dtG14WeFlgPD Xoaedt1tvxXpRkvEnuwdpFG/CRAhquBhvQImCIKgkQstEa4v7f+Dlz0Ex7gVBB9w4Ja5F0b//EE gYad1JLxiu4nCQNnbzGhx++OL49Vo2cXUIDQAW4yNn9g== X-Zone-Loop: f1dcd7c325d7974f7226a3cda92dff5c73f17ae59e86 x-campaign-type: default x-transaction-id: 5baec977-908e-43d4-8d8a-e01c6b7f93b9 x-swg-uid: 01-19e111d5-7538-48b1-8894-fb956a6b61d7 X-Mailer: Sweego Message-ID: <1790845650.8631fc262581453bbf619ec5b2062170.1a0f6b805100003f66@vates.tech> x-swg-bid: 1790845650.8631fc262581453bbf619ec5b2062170.1a0f6b805100003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko Subject: [PATCH v4 4/4] xen/riscv: use pte_is_valid() in pte_is_mapping() Date: Thu, 1 Oct 2026 11:07:23 +0200 In-Reply-To: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1790845141; l=848; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=6mGtsTHc3Gt+40Y5dU6N3fqFHHuArI6qKHg38xPBObY=; b=Xyi3ZzsPtbUEyQL676/mjJOg6U/YvdlPjuKfDZpPJL60i2OeejYfNmgUJK4IAHyyvv8Ohn+4v y6NDHp+Ai93DFzJ/ogZYo07UFOuVD9ht3wJIaQL1hSxZZAKxZMBGQoK 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: 1790845649771 X-purgate-ID: tlsNG-42698a/1790845658-186CA9EA-E78F5941/0/0 X-purgate-type: clean X-purgate-size: 850 Use pte_is_valid() instead of open-coding the PTE_VALID check. No functional change. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v2: - new patch. --- xen/arch/riscv/include/asm/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index 8a3e3e1e66..f9e59e61de 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -188,7 +188,7 @@ static inline bool pte_is_mapping(pte_t p) { ASSERT(!pte_has_reserved_rwx(p)); - return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); + return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); } static inline bool pte_is_superpage(pte_t p, unsigned int level) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:09:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:09:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438076.1656968 (Exim 4.92) (envelope-from ) id 1xCCnO-0002Uu-IJ; Thu, 01 Oct 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 1438076.1656968; Thu, 01 Oct 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 1xCCnO-0002Un-FX; Thu, 01 Oct 2026 09:09:42 +0000 Received: by outflank-mailman (input) for mailman id 1438076; Thu, 01 Oct 2026 09:09:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCCnM-0002Uh-JM for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:09:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCCnM-002Cur-02 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:09:40 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe234b-e002-0a2a0a5209dd-0a2a4502a95a-26 for ; Thu, 01 Oct 2026 11:09:39 +0200 Received: from [52.101.193.24] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe2352-6ca4-0a2a45020019-3465c118c298-3 for ; Thu, 01 Oct 2026 11:09:39 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5829.namprd03.prod.outlook.com (2603:10b6:510:35::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.15; Thu, 1 Oct 2026 09:09:36 +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.026; Thu, 1 Oct 2026 09:09: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=oViETWztlD4suz7dFROb77/Pm34+2GZ7F6axld7UNiJoRucTxLfVB7y8SNmQc4y8XzkGMeXBjyhGydTqky4a1uEU5yP+dw7qVbAEIA+p4opoLjnFL2eULJFjIeRxxFKRAf/4Cyf0R7hQfb5+PCVtjuUxp6fiv4ZWSriDGaANHwYYSpk0YBOqXEwHwD3B4CE0PWEMMkuNYuO/60rPWE356ufcCwvdiHjZRWZowznrPJaKDwyuzXtjDpeODpQVSgd9asiS97aurxiCnTWku7QvfWPr5jY0U13SHXZKtOw959QVzXCHVcd4OI4oiErl4az1bSZDR5fRTgntq8doIwQtXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zQMjaMOgafB7AEJcxnhpWBxHpfRZ5edNXFagzd889gw=; b=Ot4Y9j0WCZB4TbthV4Z1zTDqaRTGn2p6GhBRfZ4WqqOPVcgk9HGp+Bkw8KzAWozYQVo0hPJIrYixX+YcEuoB902hoCTBI7oTxwErpD/II3OBNZNtm8BWw1CuP1sUeBxlJ7UVyH9Cg6qhmwx6RNRDjmNAx7Q1+K5J9EKVrOPVkxMAlDci66nj51Pe7kEkN5uvhue0mADAOH/oTiBJV1DNEqhTnZXtmUpzKBGxeoflh60c/IGehFzTvB66xn9YyayQHPQ7Td3iMZLRZhnXjUq7+c+rgFM5m9aNShvDKDBKpctjvKhBG+QDjFyCbqR9E70q1SfUQKd+9ZdjAyjwc2AYnw== 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=zQMjaMOgafB7AEJcxnhpWBxHpfRZ5edNXFagzd889gw=; b=MqVdZ+q9cGaSd5HuLqp/9Fs3DyGhHVn/oVNMxYvriSt78p1diNLICq/RMhTTsWvKJ7cmWtOH7++WQIMrePf2R0Q1PZWdhQ/WYO9FUM8VIY1KULWLF9C3MTgN+3AJapxVAjonCypWWtvqShUcJYpHS7n37oD4FHQn3lDU34Ds/+c= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <08292fa6-de51-4456-b64a-9949e009d6ee@citrix.com> Date: Thu, 1 Oct 2026 10:09:32 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich References: <20260930191104.78141-1-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0460.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1aa::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_|PH0PR03MB5829:EE_ X-MS-Office365-Filtering-Correlation-Id: cf13aa3f-83d2-4bc5-e2d2-08df1f9bb706 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|22082099003|18002099003|4143699003|11063799006|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: KnjCaRe9UHq64YaURDz7u1SxnQJ8AxD0Rl6BivjsqiVJoQqxI/TzkHIvq4xXYQWoBJlF46YVTrlFs5j0IWTm4/UuXr43i3w6I5CKzRAF5rgu8bLb5DMP4oRryFxh99AKJJo/rnjDfmkXbzvT/sGH0P5Q4kjbWYKBI7EZ5WPv3QbDfrNnFxNsg2C/jMNaWfKb2SaBQk1yNUt9OSFXLF0Jh/dXUNycm4GSGgeb0YlJhnlu8KjyBx6VpZwcUtHLV0iTgdCrByh7s3xzmgcniwCByr2hMgJoJSI/u/Q/ht5Ai06yo55NCWfGOhh8ydbo9ZWXjR0iKZ1m9x8amWol0p/6hvhtkF7xcFCpLmYLtiMgyH6SV596yPB8JeZdlpen7HwzrZPiMGDWZK71b/nL8gz+V0vUBIotzfPYwiDr3tREQS5A4Toe5lkxj5fqHJkQo9aYKdlwW1ciptU7th5D3WVBf/ta4QG+inwwnylQ/aVCFQ7azdTU7YM1tMAARg86JDTPJ2OkHZbvUcDpkj2j2IZDayIT8EzMxtJlv8BzOdY6+6Cajt3ylJDgeVhOJNnxkxCZoeKhb5lq3Weq7/S4A6hWz7Fy6d47q/jVe3lBtmmsRZYJszsLYak97JEo1SXEPfwvJ1UggmqrC4qni1/N2EVTcdWggPYFp0Qukf2Jx3A6vn0= 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)(366016)(1800799024)(22082099003)(18002099003)(4143699003)(11063799006)(10067099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y0dtNk1MVkxKWDlCQjBkVHRsVTQ3Mk9iZk8wNHFQYVpFQStTNmR1TG5pOCth?= =?utf-8?B?dGp6bmtmMUEvc3k0c1dSVkM3SktOSkdJZmN0SFc2YmpiZmtSNnR3dkVGeE1Y?= =?utf-8?B?TW1Yd3gwcEFNeS83RWNQbHVVcGMzd1BoVEtJZExuRjBJeTJUWmo1UVpWMEdK?= =?utf-8?B?TktVYVFHdGQ2Q21TalFpMEloVHlPNFIyeEJuYTBIclRqWi9KaTU5dXFGUnZK?= =?utf-8?B?WVhoS2RFV1RUNHgrZGRtNlk1MmR2dGxaelUrN05xNkpUYVBlY3oxaGMrNm0y?= =?utf-8?B?cUpFVXdUVk43RnJ3OVU5dEdIa0Q1dmR4N2pRcitqa3ozaGJmUUZkVDdyY3dN?= =?utf-8?B?OFZ6bmIzUUJYSFJvRU13Z2VabXVzaEs1bTJ6S1VwRFUySjVRdXVHQ0JnZlph?= =?utf-8?B?SlNSZHkwTWJVdWo3UllHbXZHNmxXZEJuR1p6RzZwdm8zMjMwenppQXc2SG9n?= =?utf-8?B?NTREd1FPUXcyOFpkOVAvN1RlRzZGYXQ2WHd3TWZQYVpENHZxcDk3N3BaVmNB?= =?utf-8?B?cWZ0cUpOSU1qUk5taGd6anA0L2xObFZIa1ZrWDRrc2ZFdCtCZEtyNHBvZml2?= =?utf-8?B?YytmRXM3ZHZPbVZOWkRoVXAxMUlnSW5FSW5XYno4cForbDF6QTZic3AyR1Vk?= =?utf-8?B?WWhERnFSNnZWYzZYZXN6cE5rUitMN095eEJPaW5CTTdrNWdvWi8yNXYvZjZv?= =?utf-8?B?aTJJdXg5enpFbmJSL2xDbm9laW9CUlVMOS9lek1hWWlqb0gwQjk0SmhqM3JC?= =?utf-8?B?ejlUSWZZT0dCTyt1amVmTUFnNStQb0lZMm0yYXE3VVY4SXhJcTRIblpZd2N6?= =?utf-8?B?WHR6N2hKbzBPT0pUc2haaFMySGJQVUYyODRwaVJ0OE02bmY5UHVLQnNKSkNR?= =?utf-8?B?UVFqblpHYlpmVERtRk1IYlpsa1dMRDZZNVVWeDJHaG1qYWhBeFdydU8wUTM5?= =?utf-8?B?VUMycEFJb1VRTWdoRGpxNUtKTW1mK0tJaGJ1a0xtSFlJTytBK3Vqd2xqV2JR?= =?utf-8?B?cTdvMjR6S0JoaUV1RmhCNUdXQkdiOWJRSWVjdTVvSGNJYnNsNW1sQ3dkM3E1?= =?utf-8?B?M3lPbDBzQkI3WmRrRGNvUGswTVloWFZlUitpS0J2UVJVY3dvTHZVbEI3Y0lB?= =?utf-8?B?SlAxVUJNYmxrNFRHWVNpNkgrUXZVVE9uMjNlQytDTGF1d2dNS2JwTUVNd3Rv?= =?utf-8?B?TVlOOXlHSUpDNG1ZcWVQUCtycUhvRi93NWpURkg3cEMrUlNtVTV4WjAxcWNC?= =?utf-8?B?a0pZVTdKRXR2a3ZjVGVBTzltem5KeE5OcjNxNGs0eXNneU5ZQmlsV0kvbTE1?= =?utf-8?B?OXVyTUJuWi84SW5ldm1NRmRyUmVaVXRGM0REZFRHbmwwQk4zSEpLckN3NTJC?= =?utf-8?B?cnFrT1VQalRZSkpYSkNCV2g2cUhMbGdpOUJxS0dzRUQxUU5vNDNBWk9Jc2Rq?= =?utf-8?B?QWc1c3J0cFN2UDJGR3FqK0Z2Y2dCZFY3K3NtcFAxOW4wV0pMMFo3K2dzRWQz?= =?utf-8?B?WCtDaVZOSUNNTmlBNXBQNVB6NC92djFkRVBIb2JQc1AyMXZSK3h1SWpSZ2p1?= =?utf-8?B?L3NISUEya2ErQjlsd2ZUemxyZi9wUWVlY0JvMEY3aVJpV08vMmFQdVNLRUxT?= =?utf-8?B?Smx6YlN6TVNiSVdOUFJmUmlWUzBFTG02RmJOM2hsaXVoNnFrcHRCLzJLSno3?= =?utf-8?B?TEFlcG1tVVorOTRTWXAzb1RiNGVUTUVnYzBXSWhwbmdYOWVqbTRTNlIzU0ZL?= =?utf-8?B?ZTRUZUpPN3lXTVNZMUxvdVJIcWZBbE1lRzRUOVRJdFplQlR3TXRvTkEzUndo?= =?utf-8?B?RHVSOFdPZ093U2FNZnVJa0MxWEIxYU1WbWV1aFFTbFZKUnp3VWFDdmdmTmFY?= =?utf-8?B?S2xvdlRRV2VROFFVUEJBY2psVVBPalI4TFVDZllSK2Z3czJMRzgrRGFMZlRa?= =?utf-8?B?NnFTc0pKK1dZUHZpa2VkV1Z6TytRVm54MzVzcGorVy9WdDFDS2xEM0prNEx6?= =?utf-8?B?d1FvNk52UmxKWWRSdFN2MDlPSkI4ZWJYYk5HYi9OamNoZGp1aWhEeWxTTGxJ?= =?utf-8?B?cWNHeTVRT0ppalRCYWFPSUp4QW8vTGpGaERWZUlDTUU1UTJEZzczVWs3cjVv?= =?utf-8?B?N1phUHF5a2xVb2JVYTVLa0tFK0szVFRiK0xUR2M0bmpIckdsSWxzZi9VYTV1?= =?utf-8?B?a0JXTTlESzVGZktHN0Y3WDRPeWxFbEVyd0orM0RsWmlwZTQ2dzFGWEIrd3Ez?= =?utf-8?B?aFlyMjQyNDFFR2NsSUdod21oMUN6d0Q1RmtmYjdIdk9OWitodkl1VU9aeS9Z?= =?utf-8?B?ZTl4Zys3MmlJdEd5ZEJCSkoxQWlTcmp3TFV1dE1qZXdYRVQ4UzFmUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf13aa3f-83d2-4bc5-e2d2-08df1f9bb706 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 09:09:36.1784 (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: QJqEKgegvHoE1hueCJ5cjGp6ZuWbUX8Ll4GN7boN7frdb+MNs/1aCEWoWs5DxffA+VS17pfE+RfpXhxW0FQSKeot8RliBtpg+8SNOaI3/H0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5829 X-purgate-ID: tlsNG-720697/1790845779-F1EAB2AC-8C07FBD9/0/0 X-purgate-type: clean X-purgate-size: 3569 On 01/10/2026 9:29 am, Roger Pau Monné wrote: > On Thu, Oct 01, 2026 at 09:34:34AM +0200, Jan Beulich wrote: >> On 30.09.2026 21:11, Roger Pau Monne wrote: >>> @@ -692,7 +690,9 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) >>> if ( is_pv_domain(d) ) >>> fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) | >>> (1U << XENFEAT_highmem_assist) | >>> - (1U << XENFEAT_gnttab_map_avail_bits); >>> + (1U << XENFEAT_gnttab_map_avail_bits) | >>> + (VM_ASSIST(d, pae_extended_cr3) ? >>> + (1U << XENFEAT_pae_pgdir_above_4gb) : 0); >> Nit: Unlike binary operators, which we want to have placed at the end of >> wrapped lines, we generally prefer the ternary operator to be wrapped >> differently. E.g. >> >> (VM_ASSIST(d, pae_extended_cr3) >> ? (1U << XENFEAT_pae_pgdir_above_4gb) : 0); >> >> or >> >> (VM_ASSIST(d, pae_extended_cr3) >> ? (1U << XENFEAT_pae_pgdir_above_4gb) >> : 0); >> >> This isn't written down anywhere, so I'm not going to insist. > I had it written as your first proposal, but then moved the ternary > operator at the end of the line as I've assumed it would be prefer to > match the position of the binary ones. > >> Furthermore, wouldn't it be plausible to also add IS_ENABLED(CONFIG_PV32) >> (or, imo less desirably, opt_pv32)? > I could do: > > if ( IS_ENABLED(CONFIG_PV32) && VM_ASSIST(d, pae_extended_cr3) ) > fi.submap |= 1U << XENFEAT_pae_pgdir_above_4gb > > As I think adding the IS_ENABLED(CONFIG_PV32) check to the previous > expression is too much. > > Let me know your preference. diff --git a/xen/common/kernel.c b/xen/common/kernel.c index f4bbd8818fa8..6811599f95fd 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -677,8 +677,6 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)                          (1U << XENFEAT_vcpu_time_phys_area) |  #endif                          (1U << XENFEAT_runstate_phys_area); -            if ( VM_ASSIST(d, pae_extended_cr3) ) -                fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb);              if ( paging_mode_translate(d) )                  fi.submap |=                      (1U << XENFEAT_writable_page_tables) | @@ -690,9 +688,13 @@ 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) |                               (1U << XENFEAT_highmem_assist) |                               (1U << XENFEAT_gnttab_map_avail_bits); +                if ( VM_ASSIST(d, pae_extended_cr3) ) +                    fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb); +            }              else                  fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |                               (1U << XENFEAT_hvm_callback_vector) | Please don't try to be clever trying to fold this logic.   All that does is require someone to revert it later when it inevitably gets too complicated follow sensibly. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:15:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:15:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438090.1656978 (Exim 4.92) (envelope-from ) id 1xCCsy-0004KM-8n; Thu, 01 Oct 2026 09:15:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438090.1656978; Thu, 01 Oct 2026 09:15: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 1xCCsy-0004KF-5W; Thu, 01 Oct 2026 09:15:28 +0000 Received: by outflank-mailman (input) for mailman id 1438090; Thu, 01 Oct 2026 09:15:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCCsx-0004K9-2m for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:15:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCCsv-009BF9-Mr for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:15:25 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe24ab-8faa-0a2a0a5109dd-0a2a4502aaec-10 for ; Thu, 01 Oct 2026 11:15:25 +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 6abe24ad-6ca4-0a2a45020019-b9ff1c228385-3 for ; Thu, 01 Oct 2026 11:15: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0f6bf34f40003f66.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Oct 2026 09:15: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 73427829A4; Thu, 1 Oct 2026 11:15: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=Puu+v1oWKd5ltvGYhCTQkeAG+pZRzbTVhmKwZAU+2HI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Dok65jaF6fowEM2kHaSLYrRlkUWlaCnFw1tzAJA4Gx9FXuqgYWUPAwhOPat1QgR3YXpkzzvaf CaGUzhbGaPkJ/9Z4Bngo6aPssqwhJJ5uX91JlvdAd6sOS3zTIIzb/1ECJ2g8Z3v92NUGx1ib4j9 L4Bx8cduAtMtWQSKHLfpVBKV51uBltcomiI1WOI6q8rXUx4XQCHkgmbyEAJdEN3FqqNl+NcSWqT 0Rx+/SKqls33xqwIxowVd5JLrRkcs/dM8Ui45hlfihx8DtlpnvJ45b07LUBkzOXD4SD9KVYnkvK rKPx8gXkNxja034Fp8ky4/RrSC8LH8gJi/vSUlemQ0TA== X-Zone-Loop: c4e09f5122f9deec2c7b7cddef2209c3f6da0946a357 x-campaign-type: default x-transaction-id: e5f2cc07-3215-49e2-bee3-93dedbe52244 x-swg-uid: 01-035086dd-67d6-4945-b532-067c8812168e X-Mailer: Sweego Message-ID: <1790846121.8631fc262581453bbf619ec5b2062170.1a0f6bf34f40003f66@vates.tech> x-swg-bid: 1790846121.8631fc262581453bbf619ec5b2062170.1a0f6bf34f40003f66 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 v4 4/4] xen/riscv: use pte_is_valid() in pte_is_mapping() From: Baptiste Le Duc To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko In-Reply-To: <1790845650.8631fc262581453bbf619ec5b2062170.1a0f6b805100003f66@vates.tech> References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> <1790845650.8631fc262581453bbf619ec5b2062170.1a0f6b805100003f66@vates.tech> Date: Thu, 01 Oct 2026 11:15:15 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790846115; l=586; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=fTnS0RbXjWlLzX4aLpPH9MdsHkhk21TfQXh3ItDGweg=; b=okyiSxM769sioHAgKUmoPPEbBL8Ke4fLivSYyVyOWrRjHPCk+I8Pzo9YJ/6F6sPnZiGtBvM9K cJan5yw12G5BsyE4Tv3Cy/VlCXCmwpOAQvg4IsTZUd3E0a8FPHR8Y30 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: 1790846120663 X-purgate-ID: tlsNG-720697/1790846125-31DC92AC-B405113D/0/0 X-purgate-type: clean X-purgate-size: 586 On 2026-10-01 11:07 +0200, Baptiste Le Duc wrote: > Use pte_is_valid() instead of open-coding the PTE_VALID check. > > No functional change. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc I forgot the changelog for this patch: Changes since v3: - Rebase on the pte_is_reserved() -> pte_has_reserved_rwx() rename in patch 3, only the context line changes. Sorry for the noise, I didn't know if the reviewed-by Oleksii gave applied here as I rebased the patch. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:19:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:19:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438096.1656986 (Exim 4.92) (envelope-from ) id 1xCCwq-0005EJ-NN; Thu, 01 Oct 2026 09:19:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438096.1656986; Thu, 01 Oct 2026 09:19: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 1xCCwq-0005EC-KI; Thu, 01 Oct 2026 09:19:28 +0000 Received: by outflank-mailman (input) for mailman id 1438096; Thu, 01 Oct 2026 09:19:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCCwp-0005E6-L8 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:19:27 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCCwn-009MBP-2k; Thu, 01 Oct 2026 09:19: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 1xCCwn-0028hK-2R; Thu, 01 Oct 2026 09:19: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:Message-ID:Date:Subject:Cc:To:From; bh=eWuRD7GAnUTDVqVn/Np8AQGIp5fI3wXhz1oTFtVC0ac=; b=qA4DiN8Eqiuq8ljqK0A3iCI9ac ijv7n3+T6tJMa5uBC8wrtwbJ6ZjrCNowRTo+7rieQBdEJfUU0TeIVby5rFbXs2zOoL3p6ZGfQb+m9 9ge54dU8Uudu5UziUt/Tm+PC9ppb5ofI6YNxVlE4az/G41ZuT/LyWiOxExqbJO1/AO+U=; 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] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests Date: Thu, 1 Oct 2026 11:19:21 +0200 Message-ID: <20261001091921.94138-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 XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit its setting in XENVER_get_features to the is_pv_domain() guarded section, with the rest of the PV specific features. No functional change intended. Signed-off-by: Roger Pau Monné --- Changes since v1: - Just move the conditional but don't merge it. --- xen/common/kernel.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/common/kernel.c b/xen/common/kernel.c index f4bbd8818fa8..6811599f95fd 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -677,8 +677,6 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) (1U << XENFEAT_vcpu_time_phys_area) | #endif (1U << XENFEAT_runstate_phys_area); - if ( VM_ASSIST(d, pae_extended_cr3) ) - fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb); if ( paging_mode_translate(d) ) fi.submap |= (1U << XENFEAT_writable_page_tables) | @@ -690,9 +688,13 @@ 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) | (1U << XENFEAT_highmem_assist) | (1U << XENFEAT_gnttab_map_avail_bits); + if ( VM_ASSIST(d, pae_extended_cr3) ) + fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb); + } else fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) | (1U << XENFEAT_hvm_callback_vector) | -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:49:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:49:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438110.1656997 (Exim 4.92) (envelope-from ) id 1xCDPi-0001pI-Vb; Thu, 01 Oct 2026 09:49:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438110.1656997; Thu, 01 Oct 2026 09:49: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 1xCDPi-0001pB-RE; Thu, 01 Oct 2026 09:49:18 +0000 Received: by outflank-mailman (input) for mailman id 1438110; Thu, 01 Oct 2026 09:49:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCDPh-0001p5-7t for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:49:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCDPg-002Jhf-1C for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:49:16 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe2c93-e002-0a2a0a5209dd-0a2a450ce6ee-24 for ; Thu, 01 Oct 2026 11:49:15 +0200 Received: from [40.93.195.34] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe2c9a-f479-0a2a450c0019-285dc3226cd9-3 for ; Thu, 01 Oct 2026 11:49:15 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by IA5PR03MB989652.namprd03.prod.outlook.com (2603:10b6:208:607::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.26; Thu, 1 Oct 2026 09:49: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.0451.026; Thu, 1 Oct 2026 09:49: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=EtVA8vkESfONQh9rO/pAtCYpxz2r0WLDYT97vdUNgvcJ7V6v03eH4JqO9lhuRt3AxU957x+HvT7Y71pJy2HFyhfkcUsrKikZkinOMDYLHwAkQ2iad2k4WH5CHVhE5u3aUJ/U7DAyRXnYDxe7qTSXviD1HY1LplQAOn56z079r2ds6JWPeInXipKYcMvUWZl8iH8rsUvim/4B0bo38dz1jysbaTmC5Vou8xsXrT4PVoVLpbovE8iUaVK27yNxn1XT47s0w/VDNaqBfQL9c6G0+C7ZErwv6prQbawkSah32Ps+z+5jooKB71Hlmpf/wwVJedCG/heG3fAI89+/CmDEqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=alW3KgWMIZx8AhQamkVaM+EsAL+i7cUwno5EnsQVWjs=; b=MUK4V33bC26l7o7XTfciVg9/SR5Zy3hxtAJoRN2znFLIvITYvhKHOdRFLwkUCrxMIqkccQAIruOuU/+91+1Lm0A/CrFmibv4/msZhHPHC/yf20OWsQ5lEbDcFf814Pri2WmdcHjHjzGot0QAyigLBwHxrIoJTICExnxImLM2lOgQpznmS6EIDjFRMppQQsPNY/X1cDcS3Ad4gwkvcLGY1wMqPpo2/C8BigZoxbHL1fGsoCKDg1dk/Z8pfaFVcVM7vBlmQHDUyTBIopZWelNGgPhartt7YJn14AeuA2P5QCS3QwKLW27ZT3CuXyx12MUDiq9bId/Ml3bdGaunRn4QqQ== 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=alW3KgWMIZx8AhQamkVaM+EsAL+i7cUwno5EnsQVWjs=; b=eTkFpL5KiCeqNxmyx5SsU431rakbeDg5NJcuvTEtqiwGC/RlMTRez5PXZEoXGRkymOCNleVGTzpc7j+5eUqPmh+6b+Gu22PSTQ02oPv1L5nF9TcfbP+oLzRgf7TLVsqNr7LDon1C3ycMO5rQ/cvm+xtuWaKFzeZqS7VoBmIdHaM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <6fa85b18-acba-47d1-9493-ead2f09ef127@citrix.com> Date: Thu, 1 Oct 2026 10:49:08 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v2] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20261001091921.94138-1-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: <20261001091921.94138-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0611.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:314::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_|IA5PR03MB989652:EE_ X-MS-Office365-Filtering-Correlation-Id: 22c0660d-3655-4469-057c-08df1fa13f1e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|10067099003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: kdfkzXnrywQHY64c9jrCVezuVqCDpB2OVxQ9sR09n+9YWb6kRnA6U8TDdC613zz8SW+1WZK1acLIoap6gM8or7dWB4bPuwkpJfexgEpNKmc4N5TSoxqClrhIZTypEB/L3121utJSyy9gZpwjxBN+05/blu70AmkS/8yKnWFKfaBAEx74ltiLrSpgnXgZzEodWJxc+8ttt1dOzqXkOPKCeMF5rCgRmGCtLKqIW0NRVFszU8rqD6i6R8+IpDmXdwgnhHfY8hkPmiUYgTWspAjBaT9ejWuEUwxCSXinutXDsYuKK2q5DWio2snX4t3/TQmyDA2e3tZxu0x/5+jVJvvIXXatQEqSzs8SmvOYIZp333UfCX9bTXxsstCEHpJV2KgQgwqMJs8LEcBezBGVJUNFWFemK247iVMp75shc3Kw6icyxZkSOb3AzWVdOr1uMrgJKkXCBmlq1VITyV4sBM30rZwtqkdPTo/JzNedgx/6i4MLlGB43wLF78LeGlla/FNhLc/ENQIXHVmSFFedfYNEjDyiyxmkGTx/mxCOlH97e01hM2Lu5GJZe3s69u53yTDVvVfVUNKMFkKuAQxrwZg12MWktP6I9kMJeYPCLR98k43+mNw+ko7k+d4T3hkIG907+N9dIhLLdfi5Plm6cbVoNxXNWU/FGWlxsx10I3pi5Wg= 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)(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?MWtLdHhMWWZscXkvRHZNR2Rlc3JRSkUxN0FhbDg4RXBtNWJIMCt6a3hzNkxs?= =?utf-8?B?MVRhM0l4c3g2dkpVTnRMV09aNTJoUEtaM24vVm94UHR3RFl4UUFySUgyekhN?= =?utf-8?B?ckloU2Z5R1dGR3gxeGFwMnpvakNaUHo3MHJsNktiSzBVQ3MvWnVKWFowNkZ4?= =?utf-8?B?dmYvNzZsNmNoeGljRE9ITGIyNUdCQzNTbEFjdWhQN0JNTzkwNUVZazkzK3N2?= =?utf-8?B?dVRmUGdicXMzZUtvaHZ5RG5TSWc3dGJOdU0ycVlDRzJWOXpOb1kwbDl6WEhx?= =?utf-8?B?RnBqZTV4ekNXZnFkWmxxUXF2RjNqWHg3VlVRNVdDempIRWVLMUljRFpxRjN3?= =?utf-8?B?T0gyLzhnTmNmQVE3dmJQRHVQUWV3cFRFUjZ6a1FqekNBeWFKZ1QyMDZRMXVK?= =?utf-8?B?SGl6WXJuU0JuTmJZRnN4dmNmdE1OQ2YxRHBiQmpxK1hvY3I2czkwbVdHdXlE?= =?utf-8?B?NFh1MUpRb3ByckQveTJCSXR4QnN0V1l3MEdudzRtWEY2NFF6Ums5SXJFSnRn?= =?utf-8?B?Mi9td0hjVTZlYW96bHlXVEZUOGpEWUlDQkZVK1luUlNBMUNQKytubUt3YlZ0?= =?utf-8?B?d2dPL2lKV1lDSnNKQjRNcWQ1MEkxZGwzQXY1bjlNN3BtdnV2T3VVdTAzMytl?= =?utf-8?B?cnBTSzc2a3gxMnlBZUZaakNrTVk5aGl0Q2JjTlZmVkRKQWVSZDNiYnlZWDFp?= =?utf-8?B?WXJjeTZZVWZ2L2svcmNIZFN5NDM3WC9UQ1dQSk5JczRVZ2VDOFo0a1hBdG0v?= =?utf-8?B?UjA3cjQxWHE1cStESndGcnR4aDU5U2FveUNPeHl0VWhPdFVSQ3lvbFgvOWt4?= =?utf-8?B?R1BBT1BvckU2dFZxL3l5REdQTFdZbkxJZGwycWtycHZ0OXo1NGFoQnpKYUZC?= =?utf-8?B?d0cxK1lWVkdndDA3YjN6VHY1WndGeG9yaXF0YUxWWGZYWTFHNVMwMCtzSFJp?= =?utf-8?B?YVYwNFV0eFNkWm4rNTM3NE84WnpkOHZ6NTdEU0NCRjRxZFFESkN4RFZUUnhl?= =?utf-8?B?d0xZNVlraDBnV3NxUWEwMjk4aEJFSFQvKzIrTmdJUjQ3MmI4bWZEZy82OFk0?= =?utf-8?B?OUU2R200QjNWUmNRUFJnVlEwT3h2aEpJa2M5dE1JaWtOWWJOZ2M4Z1h3ay9t?= =?utf-8?B?a2pqTXlNek1XMnhJUCtkeXByYUZuT0FKNkt0b1ZsdjdVQTF4c1VUMmpIZ2cy?= =?utf-8?B?eFJJUkVaMWc5VzlRSUxWaU1IcWpDTnV3YW5TYk50S1h2aEhzYWU1c0RiSlJV?= =?utf-8?B?M0pPSWRuY1NLK0M3MzQrelczNHoyWTlzRXNxc1NqOHdIWmR5Y3pZb1pJYzlZ?= =?utf-8?B?ek9EaWwvVTBndDhNVkFzRHlQZGVUdkNTcWlRems4RExzM1RXcFc1c0doSDQ2?= =?utf-8?B?eC9ycis2Wk0rWG1jQXErWldSQVBaNmhkQ2R4MzJ1SkprYmNEV0xRdUtJOGh6?= =?utf-8?B?R29adXRpeUR4cHdGM1ljNXMwSDlVSnZrNXIzckUyNDl5SHI3WU5VWXk3NzVK?= =?utf-8?B?QXdrR3VxM0ZyQ2F6eDBVM1ZucURmSUtJcVFmdk9HUkw1WUxVUXVoZU9xbzcw?= =?utf-8?B?dFMrY2x0NGg0V0N4amhKek8zUHBmSkVsRHZQUEVNVmJ5TjRaUzV1VThwVzdx?= =?utf-8?B?MXE4S3JvZ1I3ZjFFSUt2REZsOUdSZWJZeTJZNmRvaHVQQmEvY3ArMnhGRlpl?= =?utf-8?B?aDBMRGJPY3IwS3E5VUdJekFLTGVHbHF3eTFCM3pRK2x3UVpCd2xpTk5yT0FZ?= =?utf-8?B?QkVNTzFiVDFoZFZUQVFXWGJsYzJLK0ZEcE9VMzlXSjlackxyQjVNTmtQZ2R0?= =?utf-8?B?UHpFTGUwU2VxSGQ1MmE2RUJrZEpyVmprdTFrUzVENjR1WlFMMlIvVU5kcStR?= =?utf-8?B?UzlLZGpIZnQvRWZHMEhNTWhRajNKSFkrY1pscFh3R1hVSGd1czlSMDJtbnhE?= =?utf-8?B?ZjRhQXdaMEdjU2N5aDJNRlBlaHAyaUFHUTdJTUx0THJHb253bXpKa3NHb2s4?= =?utf-8?B?dU93dEVibGl5UStvWVNWOHRGYTFlNTMvQ3ZadUw1ZUZVRnVRTFVDZWtLQkg4?= =?utf-8?B?UCtFZThJS1JyQ0Iydkp1OUUyTk4yQmZ6V012RkFZY0dWS01mWFFFVjQrczMr?= =?utf-8?B?dUxvSmk0U0lHNzhvY0lZQ2lzRThTS2JERkcxdnZiS3lQWWN1a2tOSysrdyt6?= =?utf-8?B?SzJxdktUSGlaQjhJczE5a2RiNUdxUk9UUy9EdW5GNHVMRERxaGtyWXhOcVd6?= =?utf-8?B?aGlkaEZZb2xQZU84ZmtDWXk0U21zTWZiUUw1cnM4RnRRUkcxc3VPK3htcjlG?= =?utf-8?B?YTlORnVhS2hzNjJkVzFwREhaZHBjWEwza0pJVVBuNjVHWTVSdEcvZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22c0660d-3655-4469-057c-08df1fa13f1e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 09:49:11.9794 (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: 7ByGW/aNr0YvU4++dI7NHvZWQZvpcioln0kS087oPeWmny5LNns1/S7eIh2KSCitNHLzAtYkcCmoxdm1METtsMYKBYIYlVh0H/40lzRzvTw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA5PR03MB989652 X-purgate-ID: tlsNG-d25034/1790848155-03AD4A5B-2451742D/0/0 X-purgate-type: clean X-purgate-size: 400 On 01/10/2026 10:19 am, Roger Pau Monne wrote: > XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit > its setting in XENVER_get_features to the is_pv_domain() guarded section, > with the rest of the PV specific features. > > No functional change intended. > > Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Thu Oct 01 09:56:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 09:56:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438119.1657004 (Exim 4.92) (envelope-from ) id 1xCDX2-0003Yq-MC; Thu, 01 Oct 2026 09:56:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438119.1657004; Thu, 01 Oct 2026 09:56: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 1xCDX2-0003Yj-JR; Thu, 01 Oct 2026 09:56:52 +0000 Received: by outflank-mailman (input) for mailman id 1438119; Thu, 01 Oct 2026 09:56:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCDX0-0003Yd-Qr for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 09:56:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCDWz-00DwDv-Va for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:56:49 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe2e43-2eae-0a2a0a5409dd-0a2a4507875a-46 for ; Thu, 01 Oct 2026 11:56:49 +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 6abe2e61-b4ea-0a2a45070019-b9ff1c22a2c5-3 for ; Thu, 01 Oct 2026 11:56: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0f6e5295a0003f66.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 01 Oct 2026 09:56:48 +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 9551B829A3; Thu, 1 Oct 2026 11:56: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=UN4JVgQy2aXXU1eEkzbdYD4BaaRvS3bghOXt+D3e4cs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=cnHnsW8ukwXU3F2k3D1moH2fE2uWojTusEwfbWGpe2+Yt+jiUk3/5/4Abef0LBohwh1p8dEcX iZPQBU4XZOG/rjGnLddvkBWV37IimuPYAnSEgr8AyfdC7hUo5v0Aal1WqdBm33GK2Wctu1A2ash By9VT7S+2Wdl058Nyhx+wILHP7ZZAnmrY9I1mNJcMW8MNNC+xy1zR7I1pFocb/Ms4t3n8DWMKvS ZvKRHoUI2jCols1OFrPhUOHIlikDfh+z9CMCEl9tTNphqsr1jwHEWo6X1eYXRB802ed9eBAte2b F55EljpMpOPAsqBMt+ICjISUx8LmVwBW0cQEHyVyzR6Q== X-Zone-Loop: d141315132cb4b60a9e835950a95d84fe73edf09db84 x-campaign-type: default x-transaction-id: 41292387-da57-4c2b-be8b-ee69add188e1 x-swg-uid: 01-092db945-32bd-48cc-b0cd-c4974e26f224 X-Mailer: Sweego Message-ID: <1790848608.8631fc262581453bbf619ec5b2062170.1a0f6e5295a0003f66@vates.tech> x-swg-bid: 1790848608.8631fc262581453bbf619ec5b2062170.1a0f6e5295a0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 1 Oct 2026 11:56:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini References: <20261001091921.94138-1-roger@xenproject.org> 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: <20261001091921.94138-1-roger@xenproject.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------xZKH7EXP8kjIIK4wAVKnfauy" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790848607776 X-purgate-ID: tlsNG-ef75cf/1790848609-A4AC8AE4-CE4DC037/0/0 X-purgate-type: clean X-purgate-size: 7281 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xZKH7EXP8kjIIK4wAVKnfauy Content-Type: multipart/mixed; boundary="------------y6m6bWfKa76eLfmrTTpWJpKl"; protected-headers="v1"; hp="clear" Message-ID: Date: Thu, 1 Oct 2026 11:56:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini References: <20261001091921.94138-1-roger@xenproject.org> 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: <20261001091921.94138-1-roger@xenproject.org> --------------y6m6bWfKa76eLfmrTTpWJpKl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDEvMTAvMjAyNiDDoCAxMToyMSwgUm9nZXIgUGF1IE1vbm5lIGEgw6ljcml0wqA6DQo+ IFhFTkZFQVRfcGFlX3BnZGlyX2Fib3ZlXzRnYiBpcyBvbmx5IHVzZWQgYnkgMzJiaXQgUFYg Z3Vlc3RzLCBoZW5jZSBsaW1pdA0KPiBpdHMgc2V0dGluZyBpbiBYRU5WRVJfZ2V0X2ZlYXR1 cmVzIHRvIHRoZSBpc19wdl9kb21haW4oKSBndWFyZGVkIHNlY3Rpb24sDQo+IHdpdGggdGhl IHJlc3Qgb2YgdGhlIFBWIHNwZWNpZmljIGZlYXR1cmVzLg0KPiANCj4gTm8gZnVuY3Rpb25h bCBjaGFuZ2UgaW50ZW5kZWQuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u bsOpIDxyb2dlckB4ZW5wcm9qZWN0Lm9yZz4NCj4gLS0tDQo+IENoYW5nZXMgc2luY2UgdjE6 DQo+ICAgLSBKdXN0IG1vdmUgdGhlIGNvbmRpdGlvbmFsIGJ1dCBkb24ndCBtZXJnZSBpdC4N Cj4gLS0tDQo+ICAgeGVuL2NvbW1vbi9rZXJuZWwuYyB8IDYgKysrKy0tDQo+ICAgMSBmaWxl IGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYg LS1naXQgYS94ZW4vY29tbW9uL2tlcm5lbC5jIGIveGVuL2NvbW1vbi9rZXJuZWwuYw0KPiBp bmRleCBmNGJiZDg4MThmYTguLjY4MTE1OTlmOTVmZCAxMDA2NDQNCj4gLS0tIGEveGVuL2Nv bW1vbi9rZXJuZWwuYw0KPiArKysgYi94ZW4vY29tbW9uL2tlcm5lbC5jDQo+IEBAIC02Nzcs OCArNjc3LDYgQEAgbG9uZyBkb194ZW5fdmVyc2lvbihpbnQgY21kLCBYRU5fR1VFU1RfSEFO RExFX1BBUkFNKHZvaWQpIGFyZykNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAoMVUg PDwgWEVORkVBVF92Y3B1X3RpbWVfcGh5c19hcmVhKSB8DQo+ICAgI2VuZGlmDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgKDFVIDw8IFhFTkZFQVRfcnVuc3RhdGVfcGh5c19hcmVh KTsNCj4gLSAgICAgICAgICAgIGlmICggVk1fQVNTSVNUKGQsIHBhZV9leHRlbmRlZF9jcjMp ICkNCj4gLSAgICAgICAgICAgICAgICBmaS5zdWJtYXAgfD0gKDFVIDw8IFhFTkZFQVRfcGFl X3BnZGlyX2Fib3ZlXzRnYik7DQo+ICAgICAgICAgICAgICAgaWYgKCBwYWdpbmdfbW9kZV90 cmFuc2xhdGUoZCkgKQ0KPiAgICAgICAgICAgICAgICAgICBmaS5zdWJtYXAgfD0NCj4gICAg ICAgICAgICAgICAgICAgICAgICgxVSA8PCBYRU5GRUFUX3dyaXRhYmxlX3BhZ2VfdGFibGVz KSB8DQo+IEBAIC02OTAsOSArNjg4LDEzIEBAIGxvbmcgZG9feGVuX3ZlcnNpb24oaW50IGNt ZCwgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh2b2lkKSBhcmcpDQo+ICAgI2VuZGlmDQo+ICAg I2lmZGVmIENPTkZJR19YODYNCj4gICAgICAgICAgICAgICBpZiAoIGlzX3B2X2RvbWFpbihk KSApDQo+ICsgICAgICAgICAgICB7DQo+ICAgICAgICAgICAgICAgICAgIGZpLnN1Ym1hcCB8 PSAoMVUgPDwgWEVORkVBVF9tbXVfcHRfdXBkYXRlX3ByZXNlcnZlX2FkKSB8DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAoMVUgPDwgWEVORkVBVF9oaWdobWVtX2Fzc2lz dCkgfA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKDFVIDw8IFhFTkZFQVRf Z250dGFiX21hcF9hdmFpbF9iaXRzKTsNCj4gKyAgICAgICAgICAgICAgICBpZiAoIFZNX0FT U0lTVChkLCBwYWVfZXh0ZW5kZWRfY3IzKSApDQo+ICsgICAgICAgICAgICAgICAgICAgIGZp LnN1Ym1hcCB8PSAoMVUgPDwgWEVORkVBVF9wYWVfcGdkaXJfYWJvdmVfNGdiKTsNCj4gKyAg ICAgICAgICAgIH0NCj4gICAgICAgICAgICAgICBlbHNlDQo+ICAgICAgICAgICAgICAgICAg IGZpLnN1Ym1hcCB8PSAoMVUgPDwgWEVORkVBVF9odm1fc2FmZV9wdmNsb2NrKSB8DQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoMVUgPDwgWEVORkVBVF9odm1fY2FsbGJh Y2tfdmVjdG9yKSB8DQoNClJldmlld2VkLWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVA dmF0ZXMudGVjaD4NCg0KVGVkZHkNCg== --------------y6m6bWfKa76eLfmrTTpWJpKl-- --------------xZKH7EXP8kjIIK4wAVKnfauy 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+p0QLLz9AFAmq+Ll8FAwAAAAAACgkQZg+p0QLLz9Dz 3AwAhBYtuA3NQSuElrOTQ00cN7A5vR1fleJKL65Fao6PlojYdDf3nzessSZXebK/L6Kd5w+gQkn0 JGr94guRlSKld/35ExG0Ib9xGnHjbSw9ki+UwvqEQZ7vanjBprp7/0SrZAkX69MonV3/rrQe13i+ j5a40ZZ3/N9nRSJjP1xcK0iRQa0AXeBPAuhAruVQrHQp7GHgk/C7Lby9JFw8z3h1JpHvB0aJLyYY nqn/cEGmP/r6RTHxfUEqwqRIoKoM9s2kjb53ETEimeY2Lxw3KnUUEQGH+INBtEQT0mvBJusDInop Hl2GCG4PfXM57PlUQfELqpERcxdWXpfOG4/aVlXY9Omxurxu324a0TwMMpoU5BkhPSGe6ylH7f+Y rJzNsRAWBAh5SrmjvFIOQIZRKHOudEQHnnk8fzNBye5hlF9P84QDA/eJQKajKx3S279xcRiec2Rs pA7ivtaPHZMKHZ0k7GFrQIs/I8Dj4WKuCbvY0y3lLIaP9pm9m0jkSXvZdwTo =+g7Q -----END PGP SIGNATURE----- --------------xZKH7EXP8kjIIK4wAVKnfauy-- From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:01:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:01:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438150.1657013 (Exim 4.92) (envelope-from ) id 1xCEWq-0005RA-8B; Thu, 01 Oct 2026 11:00:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438150.1657013; Thu, 01 Oct 2026 11: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 1xCEWq-0005R3-5f; Thu, 01 Oct 2026 11:00:44 +0000 Received: by outflank-mailman (input) for mailman id 1438150; Thu, 01 Oct 2026 11:00:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCEWp-0005Qx-7x for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:00:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEWo-009VKa-L3 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:00:42 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe3d54-e002-0a2a0a5209dd-0a2a4509b9be-36 for ; Thu, 01 Oct 2026 13:00:42 +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 6abe3d5a-be1a-0a2a45090019-4a7de18c8f4a-3 for ; Thu, 01 Oct 2026 13:00:42 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ffb83bf7aso42218495e9.2 for ; Thu, 01 Oct 2026 04:00: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-4a01f6c5059sm53713695e9.0.2026.10.01.04.00.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 04:00: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=1790852442; x=1791457242; 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=FTJcU4w8z31zwCiwkKqD2MuLanrlejydS1dMYPugYlc=; b=WDLpRFT+Mmegv8xQb0x/xkZqfUiaOmo2/KVxZFT+xWonHOoEl4T5fxvXIKaM6k28BP P3EKUPBVNZYxmmimIqZkNhmY435tJTKuYYqZlsX+gfdhIwGtkLd4t8nZ4vryUq472/Tr 3l3+dxdxxDLtuoQ9WTeHmZuWlIWc4R0SJY7siroMZSeFFwe0EEKN8kLFHwm+gi2D/5XZ UCefqGMsVuqAQHH3g26VSkVlcGTeofYwXuspC5f1B0KuU4Op13ZrxpkYozWUWaU36g4V gt8btg7M/MBcgkcU4vY9tEgdrXtGNCSGQuSQRbWdlgopXgoALeoOpF1SVcD82jNFWTHX b24g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790852442; x=1791457242; 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=FTJcU4w8z31zwCiwkKqD2MuLanrlejydS1dMYPugYlc=; b=XUoD7cA02mqItHrtZBfVcM9eIbDBDBm/vKt5VJAv/bVIlVU5+7zM5gn5rFxiDcyZSA chKN976aJOHzOllRBLiuL2gKuuWqzciiXLmQsA5q4klehBEbvDWmAoUDMPIL0hVqADOq 1c2ZEbAPJGuqnDnZTZHWIjI3QXk4hJkQztMKWlFC5Je8nGAAnsu5+LKj3Any1A3GFRHJ un84OTqjkWD2O0kyoZsL6MqF2bJTsHR7Pbw/vPdlHIwHR3EGFy1f52pDPyAFtfVUjKoF HDzCCsHOT7HOywW5MjQ4k77UAEyLn0J17hXMSn/hSEsQrYSA0rTt1lvMJOQcx6KJLbaL PNRw== X-Forwarded-Encrypted: i=1; AKwUvByfdZtKV+kqBawSPhQu2hwtT5XlhXzRPUtBByha0EMIiuq5glQ5/BYqGnsW2XrpgxeQ2qbuYE9bN2k=@lists.xenproject.org X-Gm-Message-State: AFuF++kHapvnlyrM6uO6S6TjKHBPURmhQ1nsv/yMbA0yqrKWy5AR6I8E ykEKKd5wFUfVjYD/E+/2wXLVWpaJONFjFnoP+J6ezdGE6P+mnCsNBhvyhaMGX3S5MQ== X-Gm-Gg: AYBFou2aMib4/XBBRJc+hap4mVmmk05980BH2uTp+j5qc74j7y0xlOBIaS2DHnfHnb4 hnlqkX84/zwfI2vKMYKP8faaygDuAVD+tus6XEa9p73lHNZbLMBkTP9xM3COeiqH+mXsjUIvZl7 21uo/PSTDI5iTU0m1AVE2EnGptlvZk10/D6kYVAo0CoZTI+2/h2nDbuN5sCFCBZKYtdQYm35PPb LypAGcXv2h6cPIkkv/AhTxgV/RgtBBUpjUqDCbcpnBWU/XuQPR8nb7UoXu0u/e6ASh+sgwosjko bOeZW9VrDYxFO9qYBwlVLgcIsH70SgogoimnX5DrBTinI5iaWksZcSCjTHS9y6edEfxUt5aFR3k lpWRwlG+MrBN2N62XvX3szyLZQ1napEuC87jvy7uIwPotFXaRkpUQvn8He/pXl7KhtuPoLhw4Pv lW2TWmXG0q3taBb+bdS/Cj2QIT8P3RU3x28IDmZoFERScGv+MoTqHPzkQRYWM2lc85NWb2kYqO+ aqfZj3K5KhrOSd1ezo3hpUTcYUhBUU7R3WJcj2/TUUqrOQbEnYVml1+0evVVICBa4RwOekUzg== X-Received: by 2002:a05:600c:3145:b0:49f:bd3c:bc1a with SMTP id 5b1f17b1804b1-4a01b00d9bamr70945215e9.21.1790852441696; Thu, 01 Oct 2026 04:00:41 -0700 (PDT) Message-ID: <07e9f4c5-0e5a-4420-b926-9598f79b4d1e@suse.com> Date: Thu, 1 Oct 2026 13:00:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests 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: <20260930191104.78141-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1790852442-BC8C9034-67D80536/10/78276251493 X-purgate-type: spam X-purgate-size: 2024 On 01.10.2026 10:29, Roger Pau Monné wrote: > On Thu, Oct 01, 2026 at 09:34:34AM +0200, Jan Beulich wrote: >> On 30.09.2026 21:11, Roger Pau Monne wrote: >>> @@ -692,7 +690,9 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) >>> if ( is_pv_domain(d) ) >>> fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) | >>> (1U << XENFEAT_highmem_assist) | >>> - (1U << XENFEAT_gnttab_map_avail_bits); >>> + (1U << XENFEAT_gnttab_map_avail_bits) | >>> + (VM_ASSIST(d, pae_extended_cr3) ? >>> + (1U << XENFEAT_pae_pgdir_above_4gb) : 0); >> >> Nit: Unlike binary operators, which we want to have placed at the end of >> wrapped lines, we generally prefer the ternary operator to be wrapped >> differently. E.g. >> >> (VM_ASSIST(d, pae_extended_cr3) >> ? (1U << XENFEAT_pae_pgdir_above_4gb) : 0); >> >> or >> >> (VM_ASSIST(d, pae_extended_cr3) >> ? (1U << XENFEAT_pae_pgdir_above_4gb) >> : 0); >> >> This isn't written down anywhere, so I'm not going to insist. > > I had it written as your first proposal, but then moved the ternary > operator at the end of the line as I've assumed it would be prefer to > match the position of the binary ones. > >> Furthermore, wouldn't it be plausible to also add IS_ENABLED(CONFIG_PV32) >> (or, imo less desirably, opt_pv32)? > > I could do: > > if ( IS_ENABLED(CONFIG_PV32) && VM_ASSIST(d, pae_extended_cr3) ) > fi.submap |= 1U << XENFEAT_pae_pgdir_above_4gb > > As I think adding the IS_ENABLED(CONFIG_PV32) check to the previous > expression is too much. > > Let me know your preference. I'm okay with the if() variant, but as you know I'm also not afraid of long-ish ternary expressions. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:05:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:05:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438158.1657023 (Exim 4.92) (envelope-from ) id 1xCEbf-00067K-PH; Thu, 01 Oct 2026 11:05:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438158.1657023; Thu, 01 Oct 2026 11: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 1xCEbf-00067D-M4; Thu, 01 Oct 2026 11:05:43 +0000 Received: by outflank-mailman (input) for mailman id 1438158; Thu, 01 Oct 2026 11:05:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCEbe-000676-Hj for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:05:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEbd-008KP8-UW for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:05:41 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe3e75-e002-0a2a0a5209dd-0a2a4504d9a8-32 for ; Thu, 01 Oct 2026 13:05:41 +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 6abe3e84-b57f-0a2a45040019-4a7de18dd3ec-3 for ; Thu, 01 Oct 2026 13:05:40 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912e4b11so38146395e9.3 for ; Thu, 01 Oct 2026 04:05: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-4a01f96d01csm43801495e9.2.2026.10.01.04.05.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 04: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=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=1790852740; x=1791457540; 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=BdY+cB2fNcNO2e6k4oQvAntu10bBGWQCjhFtQXa2zTw=; b=ZtHEGURR2gptICOVn/Rga27c5czwFMTjhQh6kczXChqqz9uecY9nxEGRJl9b+gUGBo 8WVixVUAeRxVCqREHqOd/XKWA3c5xLX2a3LBXkYDOImTnm4d0ecHOYbgI4eo/XUFLLK+ 4nkXOU06LoiW1Gnk9fXUn57/BRWehSj9z78T+wGsZOxC/Y0fxrD3vwwvJoMH72Z0B2wV P6NDxRTpR2ge4oE7TiBpnbwUnoNyeemPZafERW7d4S42WmXaBgtnEB+Y2olnEYiupRk3 eoOtVrwBi1xsb7RnDIvr5Q2D8ZUZkfyoFFCZypfG+RksNxaVrpYoK42y6wTczYylgLaD eKIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790852740; x=1791457540; 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=BdY+cB2fNcNO2e6k4oQvAntu10bBGWQCjhFtQXa2zTw=; b=s9J1H8veP0hNc/uCRDCJhpWfSpPOKj4dmf8bZoZJuV+hOLGryoNDSshvpC78GnRIlF OzCzkPTB7GRgq39KJgAAqfUyZrK1i0JUlAUPAWCwuDCmAi0KuZRjCP3pNrJ/x98nTeYc +QoWkGUFEPSSwUsqlCZuyBpPNzDmdwQTCMIIGeNYr03025zwWKC79CPPyXN1gj5m4kWa Dko0bVzf9VVg9jpBq0fBc6SipPatHbVhU1SJvvd9qTfhwvPB34a7hbdLwi28goJFCvGh 81NOHZDIfZ2OFUL3MpzcAMpr6qMj+fcWvfwgG2ihiGOqgnOhZZdB9RnCVoDoE8iaao5P KumA== X-Forwarded-Encrypted: i=1; AKwUvBxzvVaRcio2NdAljCs0ak5ByNmhUFfkbmWcJX2aYuDGpCDTMDgRzlDYqheIGDeAPfypcYQ4SCX3HMk=@lists.xenproject.org X-Gm-Message-State: AFuF++kButDAUrJo/M+nhq57W/H72O0glqzh+GnPfke2A9ClCAjhcgkE +fB8YqE15tjxGQJeHbjn2sPzk5xtB6TkjACWZo2iQaohCDy4NKRSTUCCS4I6n2KS1g== X-Gm-Gg: AYBFou21fidoAUuu8sXidGkw0jGtOwIkIYFxAFN+Ny80xptUWPCFg6KD26wPDY/4xQ2 aohZbd5tZw9zH/8LPcaFWN/fEbqKLih01rA6eMUDrqo6nIMi6Q0370ynIna3tVHlUWlrpCn86s5 V88Gg0iCI4oI250+80tGJawRtGVpmjkBrPXgRDGLRvV9sPFX8ujlo1hIqtUXWdQCtEY8762NSR6 sswH4xTz8ZB+NtgIQpxyzM6HaI3aQLWOFgK0XXBgWiEBE4RL7JNgmJxVrPqBmeSOSvEgP96Fo2a WnZNDFWaB4eeb8mAw+Yh5ssH7nQ45Gjq2uqSekx8vOWpspZMrw+jZoxavE7Z32U5AE4WC46aEor wbXmbashd39+Vm4v+VYXAnwEKRZ3JTqMWw2F/EjvS/W/AqjECWFINTHiIM7Y8hm5AhoElUP8O6J mmgnKtWQRfnvRj80kpfysaxblSocqJSjWYGI9fu3AZ/2ZiIxZ4fT/tZPsQmgc69/sk4PDxKDqIO JbsoFSKxd4GYY/GzyRGcsx0V5Gfzk7NQQ5J1t8PgmgFLmD59yVK443rrE9p2g== X-Received: by 2002:a05:600c:474f:b0:49e:6e7c:d895 with SMTP id 5b1f17b1804b1-4a01aff4fa9mr71566825e9.26.1790852740082; Thu, 01 Oct 2026 04:05:40 -0700 (PDT) Message-ID: <5ff32e79-76c4-4f05-8290-14c248a79afb@suse.com> Date: Thu, 1 Oct 2026 13:05:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261001091921.94138-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: <20261001091921.94138-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790852740-52ECEB50-336A07F7/10/78276251493 X-purgate-type: spam X-purgate-size: 471 On 01.10.2026 11:19, Roger Pau Monne wrote: > XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit > its setting in XENVER_get_features to the is_pv_domain() guarded section, > with the rest of the PV specific features. > > No functional change intended. > > Signed-off-by: Roger Pau Monné > --- > Changes since v1: > - Just move the conditional but don't merge it. And still no CONFIG_PV32 dependency? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:08:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:08:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438164.1657031 (Exim 4.92) (envelope-from ) id 1xCEeh-0006kl-5Q; Thu, 01 Oct 2026 11:08:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438164.1657031; Thu, 01 Oct 2026 11:08: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 1xCEeh-0006ke-2T; Thu, 01 Oct 2026 11:08:51 +0000 Received: by outflank-mailman (input) for mailman id 1438164; Thu, 01 Oct 2026 11:08:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCEef-0006kR-EP for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:08:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEee-00FTyt-Hf for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:08:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe3f36-e002-0a2a0a5209dd-0a2a4505a24c-40 for ; Thu, 01 Oct 2026 13:08:48 +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 6abe3f40-4cb1-0a2a45050019-4a7de18ca40e-3 for ; Thu, 01 Oct 2026 13:08:48 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d391aso48960195e9.2 for ; Thu, 01 Oct 2026 04:08: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-4a01f6db98fsm51406635e9.0.2026.10.01.04.08.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 04: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=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=1790852928; x=1791457728; 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=pfOHFJUM1kARODcyi40nJaFMEVGuV9H/jMBu2s8f/z0=; b=N/BH+q29NsJVHaaJFUmDKCP1svrO7iHnwCuM6kz1BrIsR7KtfGY9EUysR9QdfT6wfq w0Ag5yQtkP5klIWild1+z+VgNMFSZeF+WD5CcrP4YLISeawLC9Rk+EY5pd8+BoMUI6jg HLUxSEr25+kyni+sspmTtlKkScYPfrUbXULz1U1FoK2z8DVxkNcxmpylFw7zBFDlUeDL qWy23pg9EV5UCpyZVUhsZ8roVvjdNhwrMS+faG60oXHPlsfumM1lDQT1BNFpq1SgmyJ2 ECpgQFpaQH8cU3LpwqGjd8Z6F1Vi/3L5wl6Qg4mSfqbFzukY0+PPQ/2ammXk56witdJD 5oyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790852928; x=1791457728; 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=pfOHFJUM1kARODcyi40nJaFMEVGuV9H/jMBu2s8f/z0=; b=TWdqan2w1wrOgpBG+q1GTHljsNajRd1cB2xOoAa8nW6sHcMXWViQ6swSW0J/6q71tw Kk7uFgGAUwMNNPHh4OfWJwYmuGb4WLYgFfDKY3AKoBkUUcfxqeU7uZcsOODXe4Bnxw92 hzyDl9KUdH3u+bTtOBQEyULcr4A82cH0IAgHplD/N2kfsBFEKryverxu02X/x94h0ouz Jfdco51IuFKUFlLKNbJkCUoiUoqStc4NL+AIqSmVG1rScloBQU83Q7X3/S1g2Rac/wPx 99XJLiUOwZd3AQVXjTyH8yBK96G17VshqKpFB76cO0Ie0LukuAciFnuuKCySge+pe0Bl Su/A== X-Gm-Message-State: AFuF++kpWBRCU70MPRzLlNeHzmXYzi8FyExGmtGBRdEso2T6ieuFHO65 O/PRUnf6LcN5fczkbaoyyq3/rIydqiUWqcph5GgF/LapjJq8ar9G2CKUtwPl+djBZQ== X-Gm-Gg: AYBFou2LADzeh6KrVuZStLAAzWs2enw5rOzOADA8JPIbZX4xE/VGJdG0I1MYkxq47J/ l2IzGTUSBuC3v3KUyfKdFYOrNIntLkFDL//IOTMYewHFwAvmzs1UpjYBSSrB8h7BCSSn4DYEGPO PEenOjimIcTO5FNCnUqRtfqkxsWoOc/jx4P361/gFiwI75N14N/lhMySTmBk0MgGn2TUqOe0x+Z ulj54bR4VzxWVHf6xLuWsW9YPxErLTn+WeNw3vXtZ4vK1rYX0K46ejrlobawqJ3zWmN1GPUe9l2 8vLBIv4RNdd/bvUP7ZDibSu2Fb/SkA3/mDG9V2kDxrtqgMo5WQkownusFs2FHqHfyrGwqBEQMD/ 2xFRaDvp53yHsM7uLWfB14z9V8B1K9weutNEEfthF3ygyXWkbHWEOTkxH9FPlb3fMQ/gUIy87yE y5H80tr0Aj9yc8ihaYc4geHadC0wlwlgWyjKtscx+DlUiyPfqpuFANh4sjyh3Vz2CXv46DIO396 MLzXlRNrCV1j8B01r7BAJBG2gvpw4HjAXPzhXI9PycB3Ls/EZc+YhDfMzjxHes= X-Received: by 2002:a05:600c:5020:b0:4a0:1efa:c746 with SMTP id 5b1f17b1804b1-4a01efad733mr36150775e9.21.1790852927874; Thu, 01 Oct 2026 04:08:47 -0700 (PDT) Message-ID: <2a9c133f-004b-4360-af53-2c8127f9a0bf@suse.com> Date: Thu, 1 Oct 2026 13:08:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] xen/riscv: use pte_is_valid() in pte_is_mapping() To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> <1790845650.8631fc262581453bbf619ec5b2062170.1a0f6b805100003f66@vates.tech> <1790846121.8631fc262581453bbf619ec5b2062170.1a0f6bf34f40003f66@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: <1790846121.8631fc262581453bbf619ec5b2062170.1a0f6bf34f40003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790852928-F5EA92A1-4475EA17/10/78276251493 X-purgate-type: spam X-purgate-size: 728 On 01.10.2026 11:15, Baptiste Le Duc wrote: > On 2026-10-01 11:07 +0200, Baptiste Le Duc wrote: >> Use pte_is_valid() instead of open-coding the PTE_VALID check. >> >> No functional change. >> >> Assisted-by: Claude:claude-opus-5 >> Signed-off-by: Baptiste Le Duc > > I forgot the changelog for this patch: > > Changes since v3: > - Rebase on the pte_is_reserved() -> pte_has_reserved_rwx() rename in > patch 3, only the context line changes. > > Sorry for the noise, I didn't know if the reviewed-by > Oleksii gave applied here as I rebased the patch. If it's a re-base which doesn't affect or alter the code change you're doing, I don't think an R-b needs dropping. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:16:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:16:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438174.1657050 (Exim 4.92) (envelope-from ) id 1xCEmJ-0000Ew-8u; Thu, 01 Oct 2026 11:16:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438174.1657050; Thu, 01 Oct 2026 11:16: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 1xCEmJ-0000Ep-3r; Thu, 01 Oct 2026 11:16:43 +0000 Received: by outflank-mailman (input) for mailman id 1438174; Thu, 01 Oct 2026 11:16:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCEmH-0008T1-HB for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:16:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEmG-002bSU-AJ for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:16:40 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe4115-e002-0a2a0a5209dd-0a2a4505aa14-8 for ; Thu, 01 Oct 2026 13:16:40 +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 6abe4117-4cb1-0a2a45050019-4a7de18d9870-3 for ; Thu, 01 Oct 2026 13:16:40 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e721b5503so60140115e9.0 for ; Thu, 01 Oct 2026 04:16:40 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b068ff994sm5610427f8f.6.2026.10.01.04.16.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Oct 2026 04: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=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=1790853399; x=1791458199; 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=6moSCjWJjNEFzqSKa0SKXJwMyyg6GCB49Pw7Ja5Krs8=; b=tLnF5bFYyg4Vb+k89UHScL8W2sP1reieWzP5+H1wXSAgEGAVVlAy+uvmcDIfRo15nH gB61uHzG5c0GNZLqmY2R1nRVXfKKaVnON6k+Xi8UM61OiGnsy+/UlCJE3ML1LsIlWIsw gApd39kJr6UQCrIbKGEAW//4G4UTroDlSzbrQkEVyJif9bO6xz189VDTylmJSpVgvn4l PqTZ8gteUaU2geHiT18ZR2y4NzP84uhSSxbofY8s2Lbh4XXcsC2Nr7GO1n25ajsAITTL BL/gfIGAao1vPnoK7hctLArhv6B5kWO9Kb+p1/JnTknbZJBQE927xIAFXIHq3crr+qm5 pkrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790853399; x=1791458199; 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=6moSCjWJjNEFzqSKa0SKXJwMyyg6GCB49Pw7Ja5Krs8=; b=Izyc5/weUXNYPZh2oz/Y0B4vSRzdQ88XaJCZZTvcsMuw7fId6WzIIvggAJnSMXi48D ATfAdlZCQcYzb5hw9TUrdIpsQPn7GGx0nXhOWEYqlYMdN1rPYdgmklW/hyXAhCeQa+70 S1SSJ0g4/PmXRZ5uNftFCMSH8BluGo0PF/VOYnqQ04FiWBryPyDMWWjsjIV0SLy7Dkbq fBSJsP1xuz6MvSDieqRiF1tEIIVXfMNfObBt1IsfMIrVzOBGh7LLZB2t6CNq+3aPRrxs 2Zzexp+efEbfHcm7nelhootUpccLKeuxgcoNl7XZzpnRmOLpuNTRFWKIVrdXG27hwAi3 EnIw== X-Gm-Message-State: AFuF++kiBjNPu5NEcvzin5+omYYY43+d6vudKAmuuzGjLGeULEFQe4go n1kOhD32uMvkBTPSLHDcjfLngbHX0zilAQYd/j9L5tBd1kz81whyqkW+Nf/lww== X-Gm-Gg: AYBFou1UGonglzZhqcPl68NqrWM85iSdDd/E0vb53SXK6hEfcOZrDX8j7yHkuMnorG6 vtnNOhWyQ3wqenHbh9QXIw975obDRErEaiL7shVU6jgQ1o91+VVv1f4ea2qb5wbnuxrxx7TqtIy 5/8Okdzo3PKjpmBmWOj1t763bJ91W8hgQMlAjZby7tfsTZQ4/ZPiiFJ+odymnsT8GihwcH/n+PE 0b2+mrs4BQu2V8+Nkx7rrXSlUcxEOTDMYR28h/qQVU1GFmfX/3VvPSL+Ho+n8nUix6811ta8ixG Q0F6Y5iD+lhmUaZRF+6GdUX6fCjsil/fU/IB4ADCWD4c4SxJPF1rgGIXJAhW635bUSsYROptWR8 ejhAdYscZkSGKduMpDvDhNyCgXFuDo+CsQLw+m+xwUyZDIgfJ/nBvy3kqcOE8MgroHfnRi6ByOs 4dVOBO5EpF9sWRpxem8cFYS/s6GSXiP89Br3xeSszqb0wyHrxlO2DSygikRT0RUReTdBXpGQ/HK Yg4fJBeyvD/jFgZA8EIjfz22kNj793sgcD/bVGj X-Received: by 2002:a05:600c:3144:b0:4a0:1c0e:b136 with SMTP id 5b1f17b1804b1-4a01c0ec65fmr64496175e9.29.1790853399202; Thu, 01 Oct 2026 04:16:39 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis Subject: [PATCH 1/2] xen/device-tree: add a helper to dump an FDT in DTS-like format Date: Thu, 1 Oct 2026 13:16:29 +0200 Message-ID: <20261001111630.112472-2-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261001111630.112472-1-oleksii.kurochko@gmail.com> References: <20261001111630.112472-1-oleksii.kurochko@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790853400-243112A1-97988D2D/10/73395122804 X-purgate-type: spam X-purgate-size: 9391 The device tree Xen builds for a dom0less domain is only ever consumed by the guest, so a mistake in it surfaces as an obscure failure inside the domain, far away from the code which produced the tree. Add device_tree_dump(). The output follows dtc's format so that a dump can be diffed against the source DTS or fed back to dtc; the value formatting heuristics are ported from dtc's utilfdt_print_data() for that reason. The walk itself goes through libfdt rather than decoding the tag stream by hand as dtc's fdtdump does. Dumping a whole tree is only useful while debugging and costs both code size and a lot of console output, hence CONFIG_DEVICE_TREE_DEBUG. Mention the dump in the help text of the option. Signed-off-by: Oleksii Kurochko --- xen/Kconfig.debug | 3 +- xen/common/device-tree/Makefile | 1 + xen/common/device-tree/dom0less-build.c | 4 + xen/common/device-tree/fdt-dump.c | 180 ++++++++++++++++++++++++ xen/include/xen/bootfdt.h | 13 ++ 5 files changed, 200 insertions(+), 1 deletion(-) create mode 100644 xen/common/device-tree/fdt-dump.c diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug index d900d926c555..664f50bf8a96 100644 --- a/xen/Kconfig.debug +++ b/xen/Kconfig.debug @@ -95,7 +95,8 @@ config DEVICE_TREE_DEBUG depends on DEVICE_TREE_PARSE help Device tree parsing and DOM0 device tree building messages are - logged in the Xen ring buffer. + logged in the Xen ring buffer. The device tree generated for each + dom0less domU is dumped there as well, in a DTS-like format. If unsure, say N here. config SCRUB_DEBUG diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile index 9036e455d66a..959dd2a9fd30 100644 --- a/xen/common/device-tree/Makefile +++ b/xen/common/device-tree/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-bindings.init.o obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o +obj-$(CONFIG_DEVICE_TREE_DEBUG) += fdt-dump.init.o obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index fcbeb8adbd73..182201384faf 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include #include @@ -587,6 +588,9 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret < 0 ) goto err; + dt_dprintk("Device tree for %pd:\n", d); + device_tree_dump(kinfo->fdt); + return 0; err: diff --git a/xen/common/device-tree/fdt-dump.c b/xen/common/device-tree/fdt-dump.c new file mode 100644 index 000000000000..fc3d9eca5891 --- /dev/null +++ b/xen/common/device-tree/fdt-dump.c @@ -0,0 +1,180 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Dump a flattened device tree blob in a DTS-like format. + * + * is_printable_string() and print_value() are derived from + * util_is_printable_string() and utilfdt_print_data() in the device tree + * compiler (dtc). + * + * Copyright 2011 The Chromium Authors, All Rights Reserved. + * Copyright 2008 Jon Loeliger, Freescale Semiconductor, Inc. + * util_is_printable_string contributed by + * Pantelis Antoniou + */ + +#include +#include +#include +#include +#include +#include + +/* Deeper nodes are still printed, but not indented any further. */ +#define DUMP_MAX_INDENT_DEPTH 32 + +/* Indentation, in characters, of a node at depth @depth. */ +static int __init indent_of(int depth) +{ + return 2 * min(depth, DUMP_MAX_INDENT_DEPTH); +} + +static bool __init is_printable_string(const void *data, unsigned int len) +{ + const char *s = data; + const char *se = s + len; + + /* A zero length property, or one which isn't NUL terminated, isn't one. */ + if ( (len == 0) || (s[len - 1] != '\0') ) + return false; + + while ( s < se ) + { + const char *ss = s; + + while ( (s < se) && *s && isprint(*s) ) + s++; + + /* Stopped on a non printable character, or the string is empty. */ + if ( (*s != '\0') || (s == ss) ) + return false; + + s++; + } + + return true; +} + +/* + * Print the value of a property, using the same heuristics as dtc: a list of + * NUL terminated printable strings is printed as such, a value which is a + * multiple of 4 bytes as a list of cells, anything else as a byte string. + * + * The caller has already started the line (and with it selected the log + * level), so no XENLOG_* prefix may be used here. + */ +static void __init print_value(const void *data, unsigned int len) +{ + unsigned int i; + + /* Empty property, nothing to print. */ + if ( len == 0 ) + return; + + if ( is_printable_string(data, len) ) + { + const char *s = data; + const char *end = data + len; + + printk(" = "); + while ( s < end ) + { + printk("\"%s\"", s); + s += strlen(s) + 1; + if ( s < end ) + printk(", "); + } + } + else if ( IS_ALIGNED(len, sizeof(fdt32_t)) ) + { + const fdt32_t *cell = data; + + printk(" = <"); + for ( i = 0; i < len / sizeof(*cell); i++ ) + printk("%s0x%08x", i ? " " : "", fdt32_ld(&cell[i])); + printk(">"); + } + else + { + const uint8_t *byte = data; + + printk(" = ["); + for ( i = 0; i < len; i++ ) + printk("%s%02x", i ? " " : "", byte[i]); + printk("]"); + } +} + +static void __init print_properties(const void *fdt, int node, int indent) +{ + int prop; + + fdt_for_each_property_offset ( prop, fdt, node ) + { + const char *name; + const void *data; + int len; + + data = fdt_getprop_by_offset(fdt, prop, &name, &len); + if ( !data ) + { + printk(XENLOG_DEBUG "%*scouldn't read property at offset %d: %s\n", + indent, "", prop, fdt_strerror(len)); + return; + } + + printk(XENLOG_DEBUG "%*s%s", indent, "", name); + print_value(data, len); + printk(";\n"); + } + + if ( (prop < 0) && (prop != -FDT_ERR_NOTFOUND) ) + printk(XENLOG_DEBUG "%*scouldn't walk the properties: %s\n", + indent, "", fdt_strerror(prop)); +} + +void __init device_tree_dump(const void *fdt) +{ + int node, depth = 0; + /* Depth up to which nodes are open and still have to be closed. */ + int open_depth = 0; + + printk(XENLOG_DEBUG "/dts-v1/;\n"); + + /* + * fdt_next_node() signals the end of the subtree it was started on by + * making the depth negative, and only returns an error when the blob + * itself is malformed. + */ + for ( node = 0; (node >= 0) && (depth >= 0); + node = fdt_next_node(fdt, node, &depth) ) + { + const char *name = fdt_get_name(fdt, node, NULL); + + /* Close the nodes which aren't a parent of the current one. */ + while ( open_depth > depth ) + printk(XENLOG_DEBUG "%*s};\n", indent_of(--open_depth), ""); + + printk(XENLOG_DEBUG "%*s%s {\n", indent_of(depth), "", + (depth == 0) ? "/" : (name ?: "")); + print_properties(fdt, node, indent_of(depth) + 2); + + open_depth = depth + 1; + } + + while ( open_depth > 0 ) + printk(XENLOG_DEBUG "%*s};\n", indent_of(--open_depth), ""); + + if ( node < 0 ) + printk(XENLOG_DEBUG "The device tree dump is incomplete: %s\n", + fdt_strerror(node)); +} + +/* + * 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/bootfdt.h b/xen/include/xen/bootfdt.h index 0e82ccea2f84..08983375209b 100644 --- a/xen/include/xen/bootfdt.h +++ b/xen/include/xen/bootfdt.h @@ -99,6 +99,19 @@ int device_tree_for_each_node(const void *fdt, int node, device_tree_node_func func, void *data); +/* + * device_tree_dump - print a device tree blob in a DTS-like format + * @fdt: flat device tree. + * + * The tree is printed at debug log level and is only meant to be used for + * debugging, so it is a no-op unless CONFIG_DEVICE_TREE_DEBUG is enabled. + */ +#ifdef CONFIG_DEVICE_TREE_DEBUG +void device_tree_dump(const void *fdt); +#else +static inline void device_tree_dump(const void *fdt) {} +#endif + typedef enum { BOOTMOD_XEN, BOOTMOD_FDT, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:16:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:16:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438173.1657041 (Exim 4.92) (envelope-from ) id 1xCEmH-0008TF-TZ; Thu, 01 Oct 2026 11:16:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438173.1657041; Thu, 01 Oct 2026 11:16: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 1xCEmH-0008T8-QH; Thu, 01 Oct 2026 11:16:41 +0000 Received: by outflank-mailman (input) for mailman id 1438173; Thu, 01 Oct 2026 11:16:40 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCEmF-0008S9-RQ for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:16:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEmE-001fY2-MJ for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:16:38 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe410d-2eae-0a2a0a5409dd-0a2a4508b10a-30 for ; Thu, 01 Oct 2026 13:16:38 +0200 Received: from [74.125.225.99] (helo=mail-wr2-f35.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe4116-f659-0a2a45080019-4a7de163bdf5-3 for ; Thu, 01 Oct 2026 13:16:38 +0200 Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-48b05fdb2f9so881654f8f.0 for ; Thu, 01 Oct 2026 04:16:38 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b068ff994sm5610427f8f.6.2026.10.01.04.16.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Oct 2026 04:16: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: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=1790853398; x=1791458198; 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=GnYzFbS1hSrt6OOinoAyibvEI4DxtFMfxt2gfSKVtJ8=; b=ZF5nyIP6EH55B9YTBtOn0GHYPo7sCa3SdI+j3qfa0PKKHTt4/VZ5Igy9bTlYVyaO4L B53PF7x5HJFgOcT+wa80cXhuIlI0vaPP6wIqd0XHyLDsng366arIebn++Ax5ZTLc6Vm3 HGEZvocMKMWGcZHrm4l1r8NNJi7V82D2k9eX6zuP5s6S61kHVS5m4Yfp+rmm+vnxxaB/ sqBP3zsybscu7liyzdJQGMXYrOP98SsyMjbRqsqJUxuOK2bSbKm72Nwv0yKOzeWUXIO0 P0KwNRPZoJiGy/S/5ozbXGfLTwkW7DE5E2zVYXPKkd42flLRrNxMmrRf5YRVFgWyspSv UjVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790853398; x=1791458198; 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=GnYzFbS1hSrt6OOinoAyibvEI4DxtFMfxt2gfSKVtJ8=; b=C6dIXtc5ubjcLzYr7dijuNCqXwZeClkAeYglQlpCUEdL4ElEPT3xNtZ3OvJ4BdXeoV d4OObqMC4V+XlbxwPjyxPFn63eZpoCl83O/Vk89r5MxdlYABHjlCcu14Oaypu0drmNxL x0Z8Xt0rTOBk+rpy539AOMAuDAc1BSqXbPYv+Fg/0zjlSgpdHxkd9YIm4ZfIVzkJ5iPf ycNUqOpi98Zv0FipqfLSfRg5Wq+5QRsG5GVWY1DaySoBMUCJ0YixFjndwkeoHZhrJVj4 Cd43OQBYWwyAeJqlDD+NtScCbXdaPl2VsL0/tTv2ZnQaJ1qE1kgutmwMnHn6XVIMijDK bGhQ== X-Gm-Message-State: AFq9FYIUy2gj6sboDPb5lU1tedkl/GJJfT3EVrKAwboyErzTysOndn/T VdCmtJwJ4AIiyUSZHhkffFdRj8zZR6qmmWVN7b64y23lzjqw9Licf7BuJU7IrQ== X-Gm-Gg: AYBFou1gxZWUblXokkjrl/0qJ+IYhFp+IGE/U66ZOgmjMmbOXIY1lMfsssX/e+Nwdy3 sUJC2AesWq45oD13wNFz71J/Jl8RBXb4tIGea+uwXwo37Ej0hxAaocxxOaz+Ko099Rgii0kECuH Sax5Y5nlxVxaq9xT3zspCuXRxTPa4n19b37vdjFiybxiLw2gvC2PeRbCv9O/H0si/sl4s6StAiT 0QPjc4jP7iM9IRS6YMX+5st9qNj3JiehlExvQNwXXPbeGfmQiY1oic4v/0oZviOQi3K1O/geOIf 5Hw3n3tdM+u4TV8l3pmK+m3fguicKIMcqCpgwDEYvZgtIYkMma8zTFvH1Xmj5c1s1rXVE0vV4mn q5tipsOGyhscHOD2B9bGNQ60DwcXveN6th8HYBmXVeQ2s/cdpj/j3GhkxcI1eboDjSvduEIFYjZ /eMN3v66m6i/+bja8MYkGZlOES+1ESQq+ZEDupJxpsUF+DkrOZjeL/he3Tp73mIHCvb0990QlOb WVtSE9/a6OH7C6rMdAKwrMvsc+pI254qGYEu4NE X-Received: by 2002:adf:e19d:0:b0:48b:4a2:8175 with SMTP id ffacd0b85a97d-48b04a2819bmr6160815f8f.43.1790853397836; Thu, 01 Oct 2026 04:16:37 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH 0/2] xen/device-tree: FDT dump helper and common discard_initial_modules() Date: Thu, 1 Oct 2026 13:16:28 +0200 Message-ID: <20261001111630.112472-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/1790853398-DFAD487B-A230D8A0/10/73395122804 X-purgate-type: spam X-purgate-size: 1475 Two small, independent device-tree changes. Arm is the only user of both at the moment; RISC-V is going to use them as well. Patch 1 adds device_tree_dump(), which prints an FDT in a DTS-like format under CONFIG_DEVICE_TREE_DEBUG, to make it possible to inspect the device tree Xen generates for a dom0less domain. Patch 2 moves discard_initial_modules() from Arm to common device-tree code, as everything it uses is already common, so that other device-tree based architectures can reuse it. No functional change. Build-tested on arm64 and arm32. CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2900841778 Oleksii Kurochko (2): xen/device-tree: add a helper to dump an FDT in DTS-like format xen/device-tree: move discard_initial_modules() to common code xen/Kconfig.debug | 3 +- xen/arch/arm/include/asm/setup.h | 2 - xen/arch/arm/setup.c | 35 +---- xen/common/device-tree/Makefile | 1 + xen/common/device-tree/bootinfo.c | 30 ++++ xen/common/device-tree/dom0less-build.c | 4 + xen/common/device-tree/fdt-dump.c | 180 ++++++++++++++++++++++++ xen/include/xen/bootfdt.h | 13 ++ xen/include/xen/bootinfo.h | 8 ++ 9 files changed, 240 insertions(+), 36 deletions(-) create mode 100644 xen/common/device-tree/fdt-dump.c base-commit: f9b72572c8d5b6d312fd0b5014f65bed20efac40 -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:16:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:16:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438175.1657056 (Exim 4.92) (envelope-from ) id 1xCEmJ-0000Gi-K6; Thu, 01 Oct 2026 11:16:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438175.1657056; Thu, 01 Oct 2026 11:16: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 1xCEmJ-0000GG-Bu; Thu, 01 Oct 2026 11:16:43 +0000 Received: by outflank-mailman (input) for mailman id 1438175; Thu, 01 Oct 2026 11:16:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCEmI-0008T2-02 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:16:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEmG-00Ha1J-Ti for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:16:40 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe4111-8faa-0a2a0a5109dd-0a2a45079d0c-22 for ; Thu, 01 Oct 2026 13:16:40 +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 6abe4118-b4ea-0a2a45070019-4a7de18c93e1-3 for ; Thu, 01 Oct 2026 13:16:40 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-4a003bd18e5so24167325e9.0 for ; Thu, 01 Oct 2026 04:16:40 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b068ff994sm5610427f8f.6.2026.10.01.04.16.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Oct 2026 04:16: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=1790853400; x=1791458200; 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=kbE4+gPC0KovURIfC+5IoRX/rbVyUI3fgwu1ICNzI/c=; b=cguSkl/aUkY3mzj0CR7s9c4XPcJ/zwky962U6mF1PLoewmjit9Mt6mCUFkTOZGe76r 53EThSmC9DwaahT7AfX6Fou2/zV0bRJsxJTQ/+X4G3KLQhpxRdLdgdvVUHnJpevuOchJ l3j+eFAdil/qdgY+1qI5oNWZ3yWRr3AJqbdBWHd47YQ99FeIEOi1ZE4h9j9jDWTB1fy5 L01R3z4YT3rmy3VCD8ulTnwpef8MAnXjGgGUN99FLkRkyDSYvai/InznDKB7rn+n6DVu gcCBhCOqZmbhG4v5NCV26o63F2uBX1B5OrJURBHAtuA5HnlUpVI2UGsjnY2ga8hrZ0T9 vB3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790853400; x=1791458200; 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=kbE4+gPC0KovURIfC+5IoRX/rbVyUI3fgwu1ICNzI/c=; b=Qc7i70ZTZxqWA9SdSPYZqghnqBNLPBbIrpDHYYTkUq/Vg5BALjzD+sPg1wL6IKqwSI pnFtiXBldU2Um0drAmGhfi0MfK0e78qtn1WmQuxLAg4yMjp9enQ24hBKDvrFD1Oua5CY Sw//a4PQkkdVMzrZpP68zpSw1wt0RiZjrxl7hrta7yoXdJpZWpql8Yyz5/id+f8d0Zii YZkDcuG+u/+xD1uVdSaPP0vl6TaGRZ0WYjtMqXj2Xp10yWU43sguU2q0X3NoaS/wR+KT 6tNOLC2w2qtuiJKspq6NfYw8IrWwaSQZ2CXmcOXdjNTPnMmUnqaoB/5C5f1Zdbh2wQIn GtVA== X-Gm-Message-State: AFuF++m6miZt9P7BhVI8ETQbiupi31V23h40LbbSnDsBhMZSXx6ZLVWn x7uWGSi5AxI+NhoNpfK1duJ3jdbYrgrYirQwSV2KLldwoF3UEk0kmC8539eyrA== X-Gm-Gg: AYBFou22/6nLOUyNwvVqdR5LOCgNvqoi7WowxDU61cY6cZa0gVfiY5O/6QKh/DL3yz5 riPncbkdiHCIeJUHaI6sOxW2K38HM7em50yxLEevqAQubsyukpMMPzvhSJQHbcc9wDaaOhPJfyG DDHvvmYmVS3ODTugObJknU3XBk/fmy0chhgjcaRZvbNrR9alArxiJhCn8uTumqMBLUaJT2tsqpr alS+hCOewjV3aswnVHl9ucOCr978VjJGwqLyNDn1MS4EUxStI2ytwzmZ6hbL4up82L0Y3tRfMFO Q0p44Q4Y3F23KJKoim3L36DJkKsjqS86DZ0bmUhTCr8KNIJyStd2QxOgxVQZxlEAD6ecuY9cRc8 XkZo8gyP92JPTtd6XZsVR0iuhH/QWd1+a/EdQ46N3wnn5wTBhPb2SOktQKwmdskZEdTM0Bfdhme 2rbJp6I6t4pKfmqAsODExRo2Agsyra8SBCjdUsnTfHNsvx8AErRolh+CBM41Qz1g27NbcnHhM3l 9LxbOM2EHQVx/hsshCrLczW9p8UkOcFOF0tB63wmiSkqXDCw+M= X-Received: by 2002:a05:600c:c1c8:20b0:4a0:2488:71cc with SMTP id 5b1f17b1804b1-4a0248872a5mr11942715e9.32.1790853400220; Thu, 01 Oct 2026 04:16:40 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: 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?= Subject: [PATCH 2/2] xen/device-tree: move discard_initial_modules() to common code Date: Thu, 1 Oct 2026 13:16:30 +0200 Message-ID: <20261001111630.112472-3-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261001111630.112472-1-oleksii.kurochko@gmail.com> References: <20261001111630.112472-1-oleksii.kurochko@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790853400-36EDEAE4-BB1535DB/10/73395122804 X-purgate-type: spam X-purgate-size: 4822 Everything discard_initial_modules() touches is already common code: bootinfo.modules, using_static_heap and fw_unreserved_regions(). Move it out of Arm into common/device-tree/bootinfo.c, next to the boot allocator handling of the same memory, and declare it in xen/bootinfo.h, so that other device-tree based architectures can reuse it instead of growing a copy of their own. The arch-specific remove_early_mappings() is not moved along with it: how the early FDT mapping is torn down is up to the architecture. As the DTB is one of the boot modules being released, the mapping has to go once they are discarded, so call it from start_xen() right after discard_initial_modules(), which keeps the common function free of any arch dependency. While moving it, use unsigned int for the loop counter and replace the "goto out" by a plain return, as there is nothing left to do at the label. No functional change. Signed-off-by: Oleksii Kurochko --- xen/arch/arm/include/asm/setup.h | 2 -- xen/arch/arm/setup.c | 35 ++----------------------------- xen/common/device-tree/bootinfo.c | 30 ++++++++++++++++++++++++++ xen/include/xen/bootinfo.h | 8 +++++++ 4 files changed, 40 insertions(+), 35 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index c491c567298f..02fdf2b56c9c 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -40,8 +40,6 @@ int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]); void create_dom0(void); -void discard_initial_modules(void); - void init_pdx(void); void setup_mm(void); diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 16f899dff57b..a65c3d2a655e 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -210,39 +210,6 @@ static void __init processor_id(void) processor_setup(); } -void __init discard_initial_modules(void) -{ - struct boot_modules *mi = &bootinfo.modules; - int i; - - /* - * When using static heap feature, don't give boot_modules memory back to - * the heap allocator - */ - if ( using_static_heap ) - goto out; - - for ( i = 0; i < mi->nr_mods; i++ ) - { - paddr_t s = mi->module[i].start; - paddr_t e = s + PAGE_ALIGN(mi->module[i].size); - - if ( mi->module[i].kind == BOOTMOD_XEN ) - continue; - - if ( !mfn_valid(maddr_to_mfn(s)) || - !mfn_valid(maddr_to_mfn(e)) ) - continue; - - fw_unreserved_regions(s, e, init_domheap_pages, 0); - } - - mi->nr_mods = 0; - - out: - remove_early_mappings(); -} - /* Relocate the FDT in Xen heap */ static void __init relocate_fdt(const void **dtb_vaddr, size_t dtb_size) { @@ -509,6 +476,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) */ discard_initial_modules(); + remove_early_mappings(); + heap_init_late(); init_constructors(); diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c index c637c45ad594..6772bf2df002 100644 --- a/xen/common/device-tree/bootinfo.c +++ b/xen/common/device-tree/bootinfo.c @@ -471,6 +471,36 @@ void __init populate_boot_allocator(void) } } +void __init discard_initial_modules(void) +{ + struct boot_modules *mi = &bootinfo.modules; + unsigned int i; + + /* + * When using static heap feature, don't give boot_modules memory back to + * the heap allocator + */ + if ( using_static_heap ) + return; + + for ( i = 0; i < mi->nr_mods; i++ ) + { + paddr_t s = mi->module[i].start; + paddr_t e = s + PAGE_ALIGN(mi->module[i].size); + + if ( mi->module[i].kind == BOOTMOD_XEN ) + continue; + + if ( !mfn_valid(maddr_to_mfn(s)) || + !mfn_valid(maddr_to_mfn(e)) ) + continue; + + fw_unreserved_regions(s, e, init_domheap_pages, 0); + } + + mi->nr_mods = 0; +} + /* * Local variables: * mode: C diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h index dbf492c2e36e..60ef25f3cf83 100644 --- a/xen/include/xen/bootinfo.h +++ b/xen/include/xen/bootinfo.h @@ -214,4 +214,12 @@ void fw_unreserved_regions(paddr_t s, paddr_t e, void (*cb)(paddr_t ps, paddr_t pe), unsigned int first); +/* + * Return the memory occupied by the boot modules to the heap allocator. + * + * It needs to be called **before** heap_init_late() so that the released + * modules are scrubbed (unless suppressed). + */ +void discard_initial_modules(void); + #endif /* XEN_BOOTINFO_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438194.1657068 (Exim 4.92) (envelope-from ) id 1xCF1r-0004fR-91; Thu, 01 Oct 2026 11:32:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438194.1657068; Thu, 01 Oct 2026 11: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 1xCF1r-0004fK-6H; Thu, 01 Oct 2026 11:32:47 +0000 Received: by outflank-mailman (input) for mailman id 1438194; Thu, 01 Oct 2026 11:19:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEpK-0001oH-5e for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:19:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEpJ-001gBA-F8 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:19:49 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe41bb-8faa-0a2a0a5109dd-0a2a4502acfa-42 for ; Thu, 01 Oct 2026 13:19:49 +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 6abe41d3-6ca4-0a2a45020019-aceafc1f81d4-3 for ; Thu, 01 Oct 2026 13:19:48 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id A6BA243E25; Thu, 1 Oct 2026 11:19:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E3D31F000FF; Thu, 1 Oct 2026 11:19: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:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790853586; bh=QFQFkWDnC7jLqttKnpyOh/RzATFY2MNc7SamlM3r9CY=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=nMbvvVKzbLfiBDmwx5000bOF+s2wwI5IUpFYTI/iQmTRFaqEIRPkxAnIgPgtRkbJ0 aqsar7aBQQWF17j7qm7re98QK2MXp/SjTXPj6Jaave3l2lYP+m0Pz8NwLOPWtJii3d +/JslHjvapBJl1QgKIGa/tDOAtKuTUTa7pAFOFLGVfS4bA6CsFZeBwjmyDK95aJdS1 9ukUJ793Yc9KrIfWLnhz27LyPhzI15LRk/k7ivImSysTbIiVyAS0KMu7lJbra/Pesz pWFxc9zKJFzMFMEYqdxKzyhJGBS5wy0U/BzhIpkvR+1jEWvnD3SfLtCnn4oQTcUb0z 8MuItJ69xgTaw== Message-ID: Date: Thu, 1 Oct 2026 13:17:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/9] mm: convert PTE table entry to pte To: Muhammad Usama Anjum , Andrew Morton , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-5-5670b8cb9059@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: <20260922-pte0-v3-5-5670b8cb9059@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790853589-309C32AC-39732091/0/0 X-purgate-type: clean X-purgate-size: 2377 On 9/22/26 19:12, Muhammad Usama Anjum wrote: > 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 > } > > Okay, that looks quite odd. No NOMMU code should ever be calling this helper. I can understand that some NOMMU code might, for some odd reason, end up including hguetlb.h where we have !CONFIG_HUGETLB_PAGE. But let's see who actually calls huge_ptep_clear_flush(): arch/arm64/mm/hugetlbpage.c: only with CONFIG_HUGETLB_PAGE mm/hugetlb.c: only with CONFIG_HUGETLB_PAGE mm/rmap.c: only after checking folio_test_hugetlb(). I suspect we can simply do: diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 80a5a03e9cee..8642c863c1b7 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -1268,15 +1268,8 @@ 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); 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) -{ -#ifdef CONFIG_MMU - return ptep_get(ptep); -#else - return *ptep; -#endif -} +pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, unsigned long addr, + pte_t *ptep); static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte, unsigned long sz) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438200.1657080 (Exim 4.92) (envelope-from ) id 1xCF1r-0004nZ-Ri; Thu, 01 Oct 2026 11:32:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438200.1657080; Thu, 01 Oct 2026 11: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 1xCF1r-0004n0-KR; Thu, 01 Oct 2026 11:32:47 +0000 Received: by outflank-mailman (input) for mailman id 1438200; Thu, 01 Oct 2026 11:23:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEtE-00030e-Q3 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:23:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEtE-00CrPB-6n for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:23:52 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe42c8-2eae-0a2a0a5409dd-0a2a4505cd4c-0 for ; Thu, 01 Oct 2026 13:23:52 +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 6abe42c6-4cb1-0a2a45050019-ac6904fe8580-3 for ; Thu, 01 Oct 2026 13: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 3B5B760A57; Thu, 1 Oct 2026 11:23:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEA3E1F000FF; Thu, 1 Oct 2026 11:23: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="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=1790853829; bh=kf6DGNVTAfNJlmV6n1mnXsg4ktNEvr3LbpOB3nxPaDE=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=h4CPFsltJBUoB1HezA4bvarNWaCYFqBa9hBNxc+xCNO9nmfmhUT/wWKO5h1TlPXIc GDcAHYvPrvXUUAdbanMCx0eH+gZVlMuBMNeu1sx6Mkedl4IpqYJoXRAvrhcsyv+r6m RMOwLgwZt2tR6GpLFOAQOaF+G9JYEPfVrthsR+29KjdXDX9BD0jIpGaVMsh4wshd8/ 1V9HgLQZNdCr5wRgqJ8ZKr2TgosbMOG52qE9tjBdGDKvkUBI6BT95ilyElZCxT2gq2 sTZn6z41rW5NtndnGGja5mbMNd0FQbRt4rsUAYkIglECZ5nHiJQcrjE0Gm51PZvf3T wzXZdyJs8fI4A== Message-ID: Date: Thu, 1 Oct 2026 13:20:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 7/9] mm/kasan: use hw_pte_t for the early shadow PTE table To: Muhammad Usama Anjum , Andrew Morton , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-7-5670b8cb9059@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: <20260922-pte0-v3-7-5670b8cb9059@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790853832-F4CA02A1-2F0249CE/0/0 X-purgate-type: clean X-purgate-size: 718 On 9/22/26 19:12, Muhammad Usama Anjum wrote: > 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 Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438206.1657100 (Exim 4.92) (envelope-from ) id 1xCF1s-0005CF-Rx; Thu, 01 Oct 2026 11:32:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438206.1657100; Thu, 01 Oct 2026 11:32: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 1xCF1s-00058d-KA; Thu, 01 Oct 2026 11:32:48 +0000 Received: by outflank-mailman (input) for mailman id 1438206; Thu, 01 Oct 2026 11:26:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEvh-0003DA-OP for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:26:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEvh-0000kk-58 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:26:25 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe4358-e002-0a2a0a5209dd-0a2a4502d4ac-22 for ; Thu, 01 Oct 2026 13:26:25 +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 6abe435f-6ca4-0a2a45020019-ac6904fec094-3 for ; Thu, 01 Oct 2026 13:26:24 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 5EC12601E4; Thu, 1 Oct 2026 11:26:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CD141F000FF; Thu, 1 Oct 2026 11:25:51 +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=1790853983; bh=Gpkw0FkXm2sEcS5oXM/km9M95p6Lr/sv8WQxRY54vDc=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=NVCLDxeTK413A0ZVScuOliWCL/BeACZG41ga59YonpVi33x8PdZhsMtn/8oq+ygOX ZKav51j3DB5hvxSALe8T+A85q01eQsw34pLNny1jJJ57fF2idAnltjr0LE9PQl0VtO 2EgWIzgB/LmAzc1XT/UYRxAbbgoVPexalg8KVzcWsDnpuRLWtkfE2p7YRoWrQHp6d6 Kpr9E/bjHpPeAud/sdVZeQRfNhP7XdrgducvsrOUBbVhR6XxxcX0rYUJMUmE+ipY0X +8tC+AQSxR9a/ZEWQqt9Y7lkR9+EqYVsu+deESVKbABTftQ15M+EZ1nyBJoEfAoSbU mz8vJo6ciRt9w== Message-ID: Date: Thu, 1 Oct 2026 13:25:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/9] mm: use hw_pte_t for generic PTE table storage To: Muhammad Usama Anjum , Anshuman Khandual Cc: Andrew Morton , 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 , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-3-5670b8cb9059@arm.com> <63db3469-82d0-4997-9bcf-31bb3aa59deb@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: <63db3469-82d0-4997-9bcf-31bb3aa59deb@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790853985-313CC2AC-0D452CF3/0/0 X-purgate-type: clean X-purgate-size: 1786 On 9/30/26 19:40, Muhammad Usama Anjum wrote: > On 30/09/2026 5:35 am, Anshuman Khandual wrote: >> On Tue, Sep 22, 2026 at 06:12:31PM +0100, 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 * >> >> Just wondering - should this Coccinelle script that converted all these >> instances be saved inside ./scripts/coccinelle/ for future referene. > > Thanks for the suggestion. This script was written for this one-time conversion > and requires manual review to distinguish HW PTE table pointers from SW PTE > pointers. After the conversion, it would not be useful. > (Maybe other arch can use it to do their conversion. But they can always > copy script from the series) Agreed, the script is not expected to be reused once merged. Which is different to other conversions where the old way of doing it can silently sneak in again. -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438202.1657087 (Exim 4.92) (envelope-from ) id 1xCF1s-0004ud-5P; Thu, 01 Oct 2026 11:32:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438202.1657087; Thu, 01 Oct 2026 11:32: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 1xCF1r-0004sv-U2; Thu, 01 Oct 2026 11:32:47 +0000 Received: by outflank-mailman (input) for mailman id 1438202; Thu, 01 Oct 2026 11:24:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEtl-00033d-50 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:24:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEtk-009ZRi-IB for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:24:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe42da-bab6-0a2a0a5309dd-0a2a4508bf68-46 for ; Thu, 01 Oct 2026 13:24:24 +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 6abe42e6-f659-0a2a45080019-aceafc1fdafc-3 for ; Thu, 01 Oct 2026 13:24:24 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 6B58D4062D; Thu, 1 Oct 2026 11:24:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A9C91F000FF; Thu, 1 Oct 2026 11:23:51 +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=1790853862; bh=E2dd2FaoT8IGI/PmgsNFfX51uTun/lYmybhUFgOLuQg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=iSG5PXXsSQzGXjfn20lgjsoWKzQYmPp7ZZXFI6SGrx91yr02VUHV298N5BBJlMHaP M9ZYf/JJLZ9V8qfBwvqO39KJ8+pNUBetBcscChkH+0df5TkZ2sUcFBudzEgRioe8yb SSkRXj8/C/QKoSKPE6PW6Q2KDh9nZ+k4kuF1lqoDkQ0AIPD3Wb5f0fv4N/DCMAQq4z R7kwBsOJxrzykRLowKMFHGd4yy52IjUUPzYvPJjS5LMo0p5dAUpW9qrXPHDQCcdIJT g69Nx3deHliOYXzfa8TMAC4jPCvHeac6QoZcwkh6WGoSh+fwx0mvq3d2tEJx9NgDLq bPMwFw16qyx8Q== Message-ID: <28b5590b-e2e2-4eee-ac7b-c5c402822a24@kernel.org> Date: Thu, 1 Oct 2026 13:21:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 8/9] drm/i915: use hw_pte_t for PTE range callbacks To: Muhammad Usama Anjum , Andrew Morton , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-8-5670b8cb9059@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: <20260922-pte0-v3-8-5670b8cb9059@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1790853864-CCF4F87B-B2113664/0/0 X-purgate-type: clean X-purgate-size: 2823 On 9/22/26 19:12, Muhammad Usama Anjum wrote: > 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; > > We really have to get rid of apply_to_page_range(). A horrible interface for drivers to hack around stuff. For the time being Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438198.1657074 (Exim 4.92) (envelope-from ) id 1xCF1r-0004hs-Ht; Thu, 01 Oct 2026 11:32:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438198.1657074; Thu, 01 Oct 2026 11: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 1xCF1r-0004gz-D1; Thu, 01 Oct 2026 11:32:47 +0000 Received: by outflank-mailman (input) for mailman id 1438198; Thu, 01 Oct 2026 11:23:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEsi-0002xp-3y for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:23:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEsh-002cuD-HN for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:23:19 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe42a5-2eae-0a2a0a5409dd-0a2a4505e8ca-10 for ; Thu, 01 Oct 2026 13:23:19 +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 6abe42a5-4cb1-0a2a45050019-aceafc1f8286-3 for ; Thu, 01 Oct 2026 13:23:19 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id CB11E43CDE; Thu, 1 Oct 2026 11:23:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09C481F000FF; Thu, 1 Oct 2026 11:22: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:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790853796; bh=e65AJN+dizDpNgTUq4a0Cxwv8xeFTHb03ml1zIvkCoQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=hq1jxQGWzfify63ZgZEC2/fTTtnkxCsb0bizh56Uwcr6HWZKYoDtzLAFE/he9Pr/3 OBvyMZtgVbRz0AtkC8gljG+lq9UL50oTsGKJDPGHK8jZJIpT5dYB8hyBjZJXNOxLRz S1g4fJkhFx4OhWbRxwbh5UP/VmxG+SgV7NC4wNLWdSvJKJsZSB2wPLKQlnN6Pd/MOU AyvCel6IqNdq6bPj/vEEPmH4T2cCnmdvEGZQUWWySwrQ1KwV4DDeKV0/oxJqkb4dkM SU0m4lXhUuDVnTU/1yFOTftTVkqDtBxeH3Z1k8kBGVDEVovf+RLA3zW5xQqJ4ct+O6 UbDMDSXAUlYtA== Message-ID: <2dcd9dbc-99ca-4f5e-8e25-f42977763c84@kernel.org> Date: Thu, 1 Oct 2026 13:19:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 6/9] mm: add hw_pte_val for HW PTE storage To: Muhammad Usama Anjum , Andrew Morton , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-6-5670b8cb9059@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: <20260922-pte0-v3-6-5670b8cb9059@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790853799-726B52A1-EBB95A23/0/0 X-purgate-type: clean X-purgate-size: 1651 On 9/22/26 19:12, Muhammad Usama Anjum wrote: > 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 I was just about to say: this series doesn't add any users. You should add that detail to the patch description: "prepare for usage in arch code" or sth like that. With that Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438210.1657113 (Exim 4.92) (envelope-from ) id 1xCF1t-0005Ov-NH; Thu, 01 Oct 2026 11:32:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438210.1657113; Thu, 01 Oct 2026 11:32: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 1xCF1t-0005LC-BO; Thu, 01 Oct 2026 11:32:49 +0000 Received: by outflank-mailman (input) for mailman id 1438210; Thu, 01 Oct 2026 11:27:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEwt-0003HZ-EV for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:27:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEws-002dQG-CH for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:27:38 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe43aa-e002-0a2a0a5209dd-0a2a450a9328-0 for ; Thu, 01 Oct 2026 13:27: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 6abe43a9-f2d2-0a2a450a0019-ac6904fecc7c-3 for ; Thu, 01 Oct 2026 13:27:38 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id A0C48601E4; Thu, 1 Oct 2026 11:27:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F5491F00898; Thu, 1 Oct 2026 11:27: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="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=1790854056; bh=HRinFgClxsjCxzXrcM5ZxOKZ/5JIquj5jbimxGiUTO8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Ky6X3yIyUjjGya5AZ2z0J7ES0PO1SfluuP77TdLK4cH/5tB7JmDxOx5JmHguHbTS/ /b53SZAJrduEMNol+itQc4hUm3oYIqiOIaUDFLDveSfCnkYT0toHIyq63iOl1Bcr0E LFrUwvyQRwIW6C5fp8PbruCBz0hBOSrd465V01o47SLY4K58h3wExxBgZh69KYO5ZH Wu118EUYFVgD1s1YuYtEhU8Vy5dw/GT2t4WKgiJR1s7vPjJz3t/3IedQszccKYRhy2 so7DKhpsR4s+A5udrWW8RI/AbcWyEkjbKrIsp9SorRGRzmZoNzvimOYRr+/vcF4jm5 3ubv4o7hB0KTg== Message-ID: Date: Thu, 1 Oct 2026 13:27:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/9] mm: convert PTE table entries in ptep_get() To: Muhammad Usama Anjum , Andrew Morton , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-4-5670b8cb9059@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: <20260922-pte0-v3-4-5670b8cb9059@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1790854058-514C7CFC-6E30D7BF/0/0 X-purgate-type: clean X-purgate-size: 439 On 9/22/26 19:12, Muhammad Usama Anjum wrote: > 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 Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438204.1657091 (Exim 4.92) (envelope-from ) id 1xCF1s-000524-CS; Thu, 01 Oct 2026 11:32:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438204.1657091; Thu, 01 Oct 2026 11:32: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 1xCF1s-0004yt-6e; Thu, 01 Oct 2026 11:32:48 +0000 Received: by outflank-mailman (input) for mailman id 1438204; Thu, 01 Oct 2026 11:24:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEuI-00037W-QF for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:24:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEuI-00FWqd-6s for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:24:58 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe42f0-2eae-0a2a0a5409dd-0a2a4501beee-36 for ; Thu, 01 Oct 2026 13:24:58 +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 6abe4308-5984-0a2a45010019-ac6904fed124-3 for ; Thu, 01 Oct 2026 13:24:57 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 7C18D601E4; Thu, 1 Oct 2026 11:24:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC6BE1F000FF; Thu, 1 Oct 2026 11:24: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=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=1790853896; bh=OEsjZu9pCpcCr8EB0aUturWNWuV7FWxewuwQYtNdc3Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=HLd6ZytaONgcOlSzOhFnlQrczv91JhiZybTmAY3u05iS4ayseO+5Yx2VI45gfH68f mXtnRYNGaqZLs733sKIWSmsT/TbTok+iiekr8NPLYf79nh6ARU02xgvH/ohonwP3eo fETOL6iAjIxGEgoSPQobLYfo/Pzi78di1CBooBn4V2h2MI7S5tztfoznGBKtNplWg4 eE+r5b2np7RtR7+yCaYzoZA4Lnf38OWea5/zFEHAYkRHQkMtrW1jiFt5EvED5gS914 LqZITTH/DuzuhMUXkjsJtLA+anz87SER33y0MFu+awJN5mNP2XIoerPKjoK2r13Kqz aX2KDjXmrqxoA== Message-ID: <48123600-5843-4c71-9ca3-1a9f3062af67@kernel.org> Date: Thu, 1 Oct 2026 13:22:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 9/9] xen: use hw_pte_t for PTE range callbacks To: Muhammad Usama Anjum , Andrew Morton , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-9-5670b8cb9059@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: <20260922-pte0-v3-9-5670b8cb9059@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1790853898-BF46D757-767D5534/0/0 X-purgate-type: clean X-purgate-size: 601 On 9/22/26 19:12, Muhammad Usama Anjum wrote: > 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 Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:32:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:32:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438208.1657107 (Exim 4.92) (envelope-from ) id 1xCF1t-0005IO-AL; Thu, 01 Oct 2026 11:32:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438208.1657107; Thu, 01 Oct 2026 11:32: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 1xCF1s-0005GV-VZ; Thu, 01 Oct 2026 11:32:48 +0000 Received: by outflank-mailman (input) for mailman id 1438208; Thu, 01 Oct 2026 11:27:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCEwF-0003GK-U2 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:27:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCEwE-00EDXV-OC for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:26:58 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe437c-bab6-0a2a0a5309dd-0a2a450be7d4-28 for ; Thu, 01 Oct 2026 13:26:58 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe4381-b7e8-0a2a450b0019-ac6904fee5c6-3 for ; Thu, 01 Oct 2026 13:26:58 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 38FCD60A59; Thu, 1 Oct 2026 11:26:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5706D1F00899; Thu, 1 Oct 2026 11:26: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:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790854016; bh=IzfEyFhJfYK+uB46vBwebUVJX9+hiREC1XF3fSfGZUA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=S+MQtz7zuMo19rFCKE3ytIWk7CFynaGBS50YcTRINWTK/69FE8EU5WXwU4YLcDdeI s9Do6bZlpvwiEVwgtaj9tIS7N18dxNolZ/ZEY2StJqCPVzklnEXLteF1u8hE+6KYAs 76CrhAdicKoK7qFzSQ6inMlZtqgwGpP4vuGgEKL0Y9/HGMa27vAhF4L10zPhtXLPmP at8McMfify9jFinUv+Sdadf2Usvs5QzzGKfUxkmoykUDM3RjU/7T2ETtc60aAVnyot kxZGI1ar8zfZG4KRQbayNjm74RVS+RYzqvFsjwaotkhltxiPBfCZ6WHXWFzh5Tiq2g 9ag/B8Tf96Twg== Message-ID: Date: Thu, 1 Oct 2026 13:26:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/9] mm: use hw_pte_t for generic PTE table storage To: Muhammad Usama Anjum , Andrew Morton , 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 References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-3-5670b8cb9059@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: <20260922-pte0-v3-3-5670b8cb9059@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1790854018-A9EC69EA-4DBB3424/0/0 X-purgate-type: clean X-purgate-size: 1265 On 9/22/26 19:12, 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 Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Thu Oct 01 11:52:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 11:52:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438263.1657140 (Exim 4.92) (envelope-from ) id 1xCFKx-0003Yj-Vi; Thu, 01 Oct 2026 11:52:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438263.1657140; Thu, 01 Oct 2026 11:52: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 1xCFKx-0003Yc-Sw; Thu, 01 Oct 2026 11:52:31 +0000 Received: by outflank-mailman (input) for mailman id 1438263; Thu, 01 Oct 2026 11:52:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCFKw-0003YW-6h for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 11:52:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCFKv-0006tl-E5 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:52:29 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe4963-bab6-0a2a0a5309dd-0a2a4508b992-38 for ; Thu, 01 Oct 2026 13:52:29 +0200 Received: from [74.125.228.171] (helo=mail-ej2-f43.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe497d-f659-0a2a45080019-4a7de4aba3a5-3 for ; Thu, 01 Oct 2026 13:52:29 +0200 Received: by mail-ej2-f43.google.com with SMTP id a640c23a62f3a-c2e20bb4583so257267866b.3 for ; Thu, 01 Oct 2026 04:52:29 -0700 (PDT) Received: from dragon.home ([2a02:a03f:63ab:dc01:1291:d1ff:fe92:3b5a]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2e31c944aesm142248666b.17.2026.10.01.04.52.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Oct 2026 04:52: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=mind.be header.i="@mind.be" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mind.be; s=google; t=1790855549; x=1791460349; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1LuPQtkjuq/IETZZ3B87abIAFWuwNq0Qb7879Nam4zY=; b=PZmpNHpr1cCI56Y3/LR+u/PcAK0LZsuIoBpGiFyY4Ee0bZeXrdlhj929AWeDd7+tsa WPLoKMbW5pEcQdmnNl62DGJwO6i+prI2jxcuk3O0F0mZiXaYlTRax2dufn1a7P8ElWRr pTbde5KzZTerkDzeT4f+nHKTpi5EmR8DUo0b6ETJ0hOJRvW1xuBJ3iekvCz+HDP13m9R sII1X5neOER9ti69RlMJv4NjVJ6ce2furgbCPTU6rU4PsDzUWTeOLe2KWGOGTvIqGT8r fFJInkrxWSmiXvD6s2lGewPHweMKkW743a2K4YOx81trZD+2jKjswTf9Gd+opfstvUdS 3xIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790855549; x=1791460349; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=1LuPQtkjuq/IETZZ3B87abIAFWuwNq0Qb7879Nam4zY=; b=ff7ZK+XkZ9f1tHXgpDlOktK2zjjB+LzU8WMqxzmnMgULypavyrT0vsVspwrpO2En7U 1S6Ub0Vka8tMCWRjuYkTCXeN2luD9ioJQr94wgZB/ZOZFWMhYhKyrRppPl+nNQ+lsLSg iC6qCr8XQTP7HmxEM8jWwW6bbkeIg6eoFqmgDsyMU0ySmSsD4XD+KDIautXduTWtGZ7z MF4t2z/V9iEgcLp3N4xhxUM24KAwlcgVmzJ2+BZcAig0y3BVtyyl7Fih1xWjjUgXPtvw /tV4MHK23jV+7F62gG5ZqHUKJPY6M/kvQ/6+7HJppTiqWsj/dCbVxGaGakpUBm9/1aMY arGg== X-Gm-Message-State: AFuF++nPjABLeUizEpyVm2joAlVgk1A77SsNBsxi3XI7GJ2llTtG6IYV v3DPVqIimER3dA/JLiXvWRHRK8oLzKMVR5O5ue8fwmnOKsMm3KfSerk4rsZMRfKKo/sAnoN5YJl VI9Y/ X-Gm-Gg: AYBFou3AXRn+nVDgIZhYjcA0Zd9kLQ1ThNsYxF6ZVOUqLGbrpNEVF871scdWRNsh/dA wyx6J1+/axRyJpUm7bjEFF/lWZ/7e5vCivDHj+A04kNXAls6eAkh5zaDdVs7L8290Y7HOx1Gfx8 z00lHRkcyfIJfRqZacSC+AYrju6zWhMj/PtiQA/2OGNRgC2yN0PBuM6bwVkWBnvLHi6DyCSRev2 vCuqd7PcASVYQFGAcgjusdBuWUCFkoAfhBU4aT2tnR7XkU2DKn24p/p+EGhWIBOkEuPjyO3nqN3 buA9NqfSxm8Gij1KFZnGwu6Li09x5tAwoghwQ5z2cFu9o4+g+Sl1Or16/om8GS0dTQ9rrhp77lZ 06S7fW92buMQNgWboqg2sQR/9d0JDaQm8hkadBSHQmlVVNLZD0zMj+GYRqXoCYeAkN84MzTj0Ua InnEeaiY1bBySzmGg3lwxDtfaGFuh6rU8FLhXyMmDHuBf1HVWTjHW1Oo7Zs8SJ4jkyPVwz4pAxw mvUNobcSlA= X-Received: by 2002:a17:907:c15:b0:c2d:ca78:ea83 with SMTP id a640c23a62f3a-c2e23df5c63mr394338266b.38.1790855548583; Thu, 01 Oct 2026 04:52:28 -0700 (PDT) From: Titouan Christophe To: xen-devel@lists.xenproject.org Subject: [PATCH test-artifacts] Build minimal images with Buildroot Date: Thu, 1 Oct 2026 13:52:25 +0200 Message-ID: <20261001115226.471814-1-titouan.christophe@mind.be> 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-c1860d/1790855549-D4D7087B-0E3D8B95/0/0 X-purgate-type: clean X-purgate-size: 12760 Add a way to build minimal Xen + Linux dom0 images, and their corresponding cross-compilation toolchains with Buildroot [1]. This effectively provides a consistent cross-architecture development environment. Buildroot is a project that makes it easy to build embedded system images, including Linux, Xen or bootloaders. Leverage that build system to build minimal images for use in the CI environment of Xen sub-projects, namely Unikraft. This approach is based on a Buildroot External tree [2] which currently only provides 2 target defconfigs (arm64 and x86_64, both running on qemu). It uses a recent development version of Buildroot that integrates changes to build Xen on x86_64 [3], on its latest official version 4.22.0 [4]. It also includes the latest kernel (linux-7.2.7 at the time of writing). As a byproduct, aside xen+kernel+rootfs, we also get a cross-compilation toolchain (that runs on x86_64 hosts). This makes it easy to cross-compile domUs for arm64, and it alleviates dynamic libraries mismatches when adding userspace programs to the dom0 Linux image. As an example, one such problem: Alpine linux is based on musl while your regular development computer is probably based on glibc, which causes issues if you are recompiling `xl` and try to use it in the Alpine image. [1] https://buildroot.org/ [2] https://buildroot.org/downloads/manual/manual.html#outside-br-custom [3] https://gitlab.com/buildroot.org/buildroot/-/commit/0bf8b2ecee6b1b41746e8863b57c2c5ba3a623b1 [4] https://gitlab.com/buildroot.org/buildroot/-/commit/a962be2eea146e06661712159698bc7cbf3305f2 This work is derived from this original series: https://gitlab.com/xen-project/fusa/unikraft/-/merge_requests/1 Signed-off-by: Titouan Christophe --- .gitlab-ci.yml | 20 ++++++++++ br2-xendevel-external/.gitignore | 2 + br2-xendevel-external/Config.in | 9 +++++ .../board/xendevel/common/rootfs-prune.sh | 21 ++++++++++ .../xendevel/x86_64/linux-xen-dom0.fragment | 40 +++++++++++++++++++ .../configs/xendevel_dom0_arm64_defconfig | 34 ++++++++++++++++ .../configs/xendevel_dom0_x86_64_defconfig | 38 ++++++++++++++++++ br2-xendevel-external/external.desc | 2 + br2-xendevel-external/external.mk | 9 +++++ scripts/build-buildroot.sh | 35 ++++++++++++++++ 10 files changed, 210 insertions(+) create mode 100644 br2-xendevel-external/.gitignore create mode 100644 br2-xendevel-external/Config.in create mode 100755 br2-xendevel-external/board/xendevel/common/rootfs-prune.sh create mode 100644 br2-xendevel-external/board/xendevel/x86_64/linux-xen-dom0.fragment create mode 100644 br2-xendevel-external/configs/xendevel_dom0_arm64_defconfig create mode 100644 br2-xendevel-external/configs/xendevel_dom0_x86_64_defconfig create mode 100644 br2-xendevel-external/external.desc create mode 100644 br2-xendevel-external/external.mk create mode 100755 scripts/build-buildroot.sh diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index d04822f..8db3a0b 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -81,3 +81,23 @@ linux-6.6.56-x86_64: microcode-x86: extends: .x86_64-artifacts script: ./scripts/x86-microcode.sh + + +# +# Buildroot based artifacts +# +buildroot: + extends: .artifacts + image: + name: registry.gitlab.com/buildroot.org/buildroot/base:20250218.2110 + parallel: + matrix: + - VARIANT: [arm64, x86_64] + cache: + key: buildroot-dl-${VARIANT} + paths: + - br2-xendevel-external/dl/ + script: + - ./scripts/build-buildroot.sh "${VARIANT}" + - mkdir -p binaries + - cp br2-xendevel-external/xen-${VARIANT}/images/* binaries/ diff --git a/br2-xendevel-external/.gitignore b/br2-xendevel-external/.gitignore new file mode 100644 index 0000000..424351b --- /dev/null +++ b/br2-xendevel-external/.gitignore @@ -0,0 +1,2 @@ +xen-arm64 +xen-x86_64 diff --git a/br2-xendevel-external/Config.in b/br2-xendevel-external/Config.in new file mode 100644 index 0000000..3c8e444 --- /dev/null +++ b/br2-xendevel-external/Config.in @@ -0,0 +1,9 @@ +# SPDX-License-Identifier: BSD-3-Clause +# +# Kconfig entry point for the XENDEVEL external tree. Entries appear under +# "External options -> Xen dom0 + Unikraft domU development environment" in +# `make menuconfig`. +# +# No XENDEVEL packages are defined yet; add +# source "$BR2_EXTERNAL_XENDEVEL_PATH/package//Config.in" +# lines here as they are introduced. diff --git a/br2-xendevel-external/board/xendevel/common/rootfs-prune.sh b/br2-xendevel-external/board/xendevel/common/rootfs-prune.sh new file mode 100755 index 0000000..7e3a661 --- /dev/null +++ b/br2-xendevel-external/board/xendevel/common/rootfs-prune.sh @@ -0,0 +1,21 @@ +#!/bin/sh +# SPDX-License-Identifier: BSD-3-Clause +# +# Buildroot post-build script: shrink the dom0 target filesystem so the cpio +# initramfs unpacks inside the dom0 memory window. $1 is the target directory. +set -e +T="$1" + +# qemu-xen BIOS/ROM/keymap blobs (~283MB) — unused by PV/PVH guests. +rm -rf "$T/usr/share/qemu-xen" + +# Docs / man / info — not needed at runtime. +rm -rf "$T/usr/share/doc" "$T/usr/share/man" "$T/usr/share/info" + +# The arch default kernel config is monolithic enough to boot dom0 without +# loadable modules for the smoke test. Keep the xen-related modules if present, +# drop the rest to shrink the initramfs. +if [ -d "$T/lib/modules" ]; then + find "$T/lib/modules" -type f -name '*.ko' \ + ! -path '*xen*' -delete 2>/dev/null || true +fi diff --git a/br2-xendevel-external/board/xendevel/x86_64/linux-xen-dom0.fragment b/br2-xendevel-external/board/xendevel/x86_64/linux-xen-dom0.fragment new file mode 100644 index 0000000..a999333 --- /dev/null +++ b/br2-xendevel-external/board/xendevel/x86_64/linux-xen-dom0.fragment @@ -0,0 +1,40 @@ +# Linux kernel config fragment: x86_64 Xen dom0. +# +# The stock x86_64 kernel defconfig does NOT enable Xen (CONFIG_XEN is not set), +# so the resulting bzImage carries no Xen PV ELF notes / PVH entry and Xen +# refuses to build dom0 ("Will only load images built for the generic loader or +# Linux images ... or with PHYS32_ENTRY set" / "Could not construct d0"). Turn on +# Xen PV+PVH dom0, the hvc console, and the backend/toolstack devices (evtchn, +# gntdev, gntalloc, xenfs, blk/net back) so the xl toolstack can drive the domU. +CONFIG_HYPERVISOR_GUEST=y +CONFIG_PARAVIRT=y +CONFIG_XEN=y +CONFIG_XEN_PV=y +CONFIG_XEN_PV_SMP=y +CONFIG_XEN_DOM0=y +CONFIG_XEN_PV_DOM0=y +CONFIG_XEN_PVH=y +CONFIG_XEN_PVHVM=y +CONFIG_XEN_SAVE_RESTORE=y +CONFIG_XEN_BACKEND=y +CONFIG_XENFS=y +CONFIG_XEN_COMPAT_XENFS=y +CONFIG_XEN_SYS_HYPERVISOR=y +CONFIG_XEN_XENBUS_FRONTEND=y +CONFIG_XEN_GNTDEV=y +CONFIG_XEN_GRANT_DEV_ALLOC=y +CONFIG_XEN_DEV_EVTCHN=y +CONFIG_XEN_PRIVCMD=y +CONFIG_XEN_BLKDEV_FRONTEND=y +CONFIG_XEN_BLKDEV_BACKEND=y +CONFIG_XEN_NETDEV_FRONTEND=y +CONFIG_XEN_NETDEV_BACKEND=y +CONFIG_HVC_XEN=y +CONFIG_HVC_XEN_FRONTEND=y +CONFIG_TTY=y +# Monolithic kernel: build everything in, no loadable modules. This drops the +# whole udev/libkmod module-loading path at boot (no .ko files to insert), so +# the rootfs can also drop kmod + eudev. Every driver this QEMU dom0 needs +# (ata_piix, e1000, virtio, 9p, xen blk/net back) is already =y in the x86_64 +# arch default config, so nothing required is lost. +# CONFIG_MODULES is not set diff --git a/br2-xendevel-external/configs/xendevel_dom0_arm64_defconfig b/br2-xendevel-external/configs/xendevel_dom0_arm64_defconfig new file mode 100644 index 0000000..cb802a8 --- /dev/null +++ b/br2-xendevel-external/configs/xendevel_dom0_arm64_defconfig @@ -0,0 +1,34 @@ +# aarch64 Xen dom0: hypervisor + xl toolstack + Linux + +BR2_aarch64=y +BR2_cortex_a72=y + +BR2_TOOLCHAIN_EXTERNAL=y +BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y +BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y + +BR2_TARGET_GENERIC_HOSTNAME="xen-dom0" +BR2_TARGET_GENERIC_ISSUE="Xen dom0 (br2-xendevel-external)" +BR2_TARGET_GENERIC_GETTY_PORT="console" + +# devtmpfs mounted by init + eudev, so /dev/null and the Xen +# gnttab/evtchn/privcmd device nodes exist at runtime. +BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y + +BR2_LINUX_KERNEL=y +BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y +BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y + +BR2_PACKAGE_XEN=y +BR2_PACKAGE_XEN_HYPERVISOR=y +BR2_PACKAGE_XEN_TOOLS=y + +BR2_PACKAGE_KMOD=y +BR2_PACKAGE_UTIL_LINUX_BINARIES=y + +BR2_TARGET_ROOTFS_CPIO=y +BR2_TARGET_ROOTFS_CPIO_GZIP=y +# BR2_TARGET_ROOTFS_TAR is not set +BR2_ROOTFS_POST_BUILD_SCRIPT="$(BR2_EXTERNAL_XENDEVEL_PATH)/board/xendevel/common/rootfs-prune.sh" + +BR2_PACKAGE_HOST_ENVIRONMENT_SETUP=y diff --git a/br2-xendevel-external/configs/xendevel_dom0_x86_64_defconfig b/br2-xendevel-external/configs/xendevel_dom0_x86_64_defconfig new file mode 100644 index 0000000..7e0d894 --- /dev/null +++ b/br2-xendevel-external/configs/xendevel_dom0_x86_64_defconfig @@ -0,0 +1,38 @@ +# x86_64 Xen dom0: hypervisor + xl toolstack + Linux + +BR2_x86_64=y + +BR2_TOOLCHAIN_EXTERNAL=y +BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y +BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_X86_64_GLIBC_STABLE=y + +BR2_TARGET_GENERIC_HOSTNAME="xen-dom0" +BR2_TARGET_GENERIC_ISSUE="Xen dom0 (br2-xendevel-external)" +BR2_TARGET_GENERIC_GETTY_PORT="console" + +# The monolithic kernel has CONFIG_DEVTMPFS_MOUNT=y, so it creates every dev +# (including the Xen control nodes /dev/xen/{evtchn,gntdev,privcmd,...} that +# xenstored/xenconsoled need) at driver registration. That removes the need for +# a userspace device manager and the libkmod/udev boot noise entirely. +BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS=y + +BR2_LINUX_KERNEL=y +BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y +BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="$(BR2_EXTERNAL_XENDEVEL_PATH)/board/xendevel/x86_64/linux-xen-dom0.fragment" +BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y +BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y + +BR2_PACKAGE_XEN=y +BR2_PACKAGE_XEN_HYPERVISOR=y +BR2_PACKAGE_XEN_TOOLS=y + +# No kmod: the kernel is monolithic (CONFIG_MODULES=n), so there are no modules +# to insert and nothing links against libkmod. Dropping it (and eudev, above) +# removes the only consumer that was failing on the missing libkmod.so.2. + +BR2_TARGET_ROOTFS_CPIO=y +BR2_TARGET_ROOTFS_CPIO_GZIP=y +# BR2_TARGET_ROOTFS_TAR is not set +BR2_ROOTFS_POST_BUILD_SCRIPT="$(BR2_EXTERNAL_XENDEVEL_PATH)/board/xendevel/common/rootfs-prune.sh" + +BR2_PACKAGE_HOST_ENVIRONMENT_SETUP=y diff --git a/br2-xendevel-external/external.desc b/br2-xendevel-external/external.desc new file mode 100644 index 0000000..232eb0e --- /dev/null +++ b/br2-xendevel-external/external.desc @@ -0,0 +1,2 @@ +name: XENDEVEL +desc: Xen development environment diff --git a/br2-xendevel-external/external.mk b/br2-xendevel-external/external.mk new file mode 100644 index 0000000..37cd1d8 --- /dev/null +++ b/br2-xendevel-external/external.mk @@ -0,0 +1,9 @@ +# SPDX-License-Identifier: BSD-3-Clause +# +# Buildroot external tree makefile fragment. +# +# Every package/*/*.mk under this tree is included by Buildroot. There are no +# XENDEVEL-specific packages yet: the tree currently provides the dom0 +# defconfigs and board support files only. + +include $(sort $(wildcard $(BR2_EXTERNAL_XENDEVEL_PATH)/package/*/*.mk)) diff --git a/scripts/build-buildroot.sh b/scripts/build-buildroot.sh new file mode 100755 index 0000000..73ab123 --- /dev/null +++ b/scripts/build-buildroot.sh @@ -0,0 +1,35 @@ +#!/usr/bin/env bash + +set -e -o pipefail + +BR2_EXT_DIR=$(realpath $(dirname $0)/../br2-xendevel-external) + +BR_REPO=https://gitlab.com/buildroot.org/buildroot +# First Buildroot version (2026.08-345-ga962be2eea) with Xen 4.22 on x86_64 +BR_COMMIT=a962be2eea146e06661712159698bc7cbf3305f2 +BR_DIR=${BR2_EXT_DIR}/buildroot +export BR2_DL_DIR=${BR2_EXT_DIR}/dl + +# Not using `git clone --revision` as it requires git >= 2.49 +if [ "$(git -C ${BR_DIR} rev-parse HEAD 2>/dev/null)" != "${BR_COMMIT}" ]; then + git init -q ${BR_DIR} + git -C ${BR_DIR} fetch --depth=1 ${BR_REPO} ${BR_COMMIT} + git -C ${BR_DIR} checkout -q FETCH_HEAD +fi + +do_build() { + build_dir=${BR2_EXT_DIR}/xen-${1} + make BR2_EXTERNAL=${BR2_EXT_DIR} O=${build_dir} -C ${BR_DIR} xendevel_dom0_${1}_defconfig + make -C ${build_dir} source all sdk | grep '>>>' +} + +for arg in $*; do + case "$arg" in + arm64|x86_64) + do_build $arg + ;; + *) + echo "Unknown target $arg" >&2 + exit 1 + esac +done -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 12:33:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 12:33:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438296.1657169 (Exim 4.92) (envelope-from ) id 1xCFyJ-00028Q-6M; Thu, 01 Oct 2026 12:33:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438296.1657169; Thu, 01 Oct 2026 12: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 1xCFyJ-00028J-2l; Thu, 01 Oct 2026 12:33:11 +0000 Received: by outflank-mailman (input) for mailman id 1438296; Thu, 01 Oct 2026 12:33:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCFyH-00028D-Q4 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 12:33:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCFyD-000Fwl-QP for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 14:33:05 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe52fb-2eae-0a2a0a5409dd-0a2a450795e6-32 for ; Thu, 01 Oct 2026 14:33:05 +0200 Received: from [52.101.46.45] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe52ff-b4ea-0a2a45070019-34652e2de2df-3 for ; Thu, 01 Oct 2026 14:33:05 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH9PR03MB731891.namprd03.prod.outlook.com (2603:10b6:610:315::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 12:33:02 +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.026; Thu, 1 Oct 2026 12:33: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=MQPvZtxlIoUuqBMAuyBG4VQFQQGpAkamF9+FGDTP6wBWowKU34pVnPIWBNoL6ZPcjt+RpcxC/h5g38sOjnjZ6rXM1bBc2gC01F0WXN+GTKhxdN9AXaaws5mj6Cv6qxT3E716feslrxkiMED0LAe+XYBoNyoh7gdwQTRfuvX3hyIlIGIDvocXicZ2X8TfNge4KWagzkyrIOTEOb1KXimMPPuUPfGHcVqKNgL9P9o/+OXBgJT1mOpMiXS66GBLPswPMCdryDUwizVTS7njlBLSYvKjjYPXC3gBOABu9hc5jHXLCToVF4WC308epn4yg30NPOEJPzE637Eh8KXwztnjxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iJ7udDsAE5YbltXcZPjf9RWVrFjR+37WTwSyC9Vm7js=; b=aYKb7l4dkmem8juIHbR53dscIrYBNyCb6GwaMpl5q8u2kSMpzFh3/u0RA/EorcAqbZbTxV2M8Jy6XyTGTUBFUAk9gv8N12+/09cRDfnzpA5xoC9hEQPqDXerwJUFmW7IeNVgKldLlp3JLb6YrMSP0sxsq7vyTKDz6Sd13WJ3kRJd80wW/wdQ9UPQjjA8uY53etFxkzU/GJegJB2/bKNAtVbuNXibRnZZWfnTj8MR4wE863uOrP+E4v9WogyIxWD+1FGFKwilZ070Ihj2rYCHHd4kwCa2oLK+9AlTbJWHQKlPwnY7KhznerVg5/uAigxKUvIWm36PhwnOa9HuwdnUFQ== 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=iJ7udDsAE5YbltXcZPjf9RWVrFjR+37WTwSyC9Vm7js=; b=q+xNTMsMEsLcb20rcqHtkvJYIqTI1WQ93HGZudPNG7+EuxvG2eXBBg9s7uFLV1LlNxqgxTY9CLP1IJelfT7irCUZMZdd1+ttFN4/FTTPKcRlG/E67w+FJm46TUSGm982gOcuuWy6zqHtxsegsOE+jgBDruJNMLQQiBkj6HJk7mg= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3b206b17-d1e5-4c63-9e75-1e10c68bf226@citrix.com> Date: Thu, 1 Oct 2026 13:32:58 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper Subject: Re: [PATCH test-artifacts] Build minimal images with Buildroot To: Titouan Christophe , xen-devel@lists.xenproject.org References: <20261001115226.471814-1-titouan.christophe@mind.be> 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: <20261001115226.471814-1-titouan.christophe@mind.be> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0421.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:37d::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_|CH9PR03MB731891:EE_ X-MS-Office365-Filtering-Correlation-Id: 33e543b8-4640-4613-1609-08df1fb82291 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|22082099003|18002099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: VXH06qOeydCdF4hlgm2dGw/n2n/eTEO4tAOZbhP1fwD85z61VQvoZKe4iLQyChenJHHCUqveJrcPy3hBVwYlx0ZBbXonz7fTsXZ6hFJY3D1IIjsg1GF/18RrYqavthQ67+CODYIhSfYsBQYpCmz8LQ8Fwbh3cjJzC7+ELFyXrMP3lUYMVBEcFGvCTLdIeT6dTvzpiyDEL6b+cIE9f1lGuuuUhR/ViIFWGfQmuygj08I4bdNCjmEf84YXqAMkgSLEVYlSGMFIaG20U9uBb2+t/1k5me+d08bsU3dPfg8K83pCzrB+yCd25aRhAA9oSXE1h9Vq4JOrFOcbZzACD3wfUdC1tKm7PcRpsKu0H0X9Lo5WKiCLF8XEVCW6EhMgyKJhliJZ/VZKbQ9kXLXLfgqE4CpEqUZ12xZBtpUVCaAnGhNuTuHZANfufCQCjwbHOFHNWbOtiDY5E6igM+haIU4QYv+aNY+3s2pomoCdfIYb99pLKS523SZHQDYhrqCBfM2AZ/2GXlsGnOAfkFOFuqN+bb5TsbrN+qZFbMLuuH0D4KV9//PTZ1bZcoqYl/4U9dftkz9yAp8/aHM/WYIj1r4dEHkDNIU+np0+EO6BxS/YTNo= 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)(22082099003)(18002099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WXBENmRpd0pQRjhtM1FqS21scE9yL2o0dzNBM1A2UFVWMGY3Ky9aUVl4bTdH?= =?utf-8?B?WTJ3ZlJldWhaWFFRVFZNU1FqUWRQRUhHRE9ETWQ3U1oxZmNrOTMxUGt1UXpy?= =?utf-8?B?RGZTNGpmVittcVRqZThEZk1oS1FodmZvdEYzY3R3T0R2SmdQbStPQ2Z6UHV2?= =?utf-8?B?Mzh5WG5PazN4ZU55WUd3WkZONk1yTUdkWnNSYjUyRUhDU1h1czFKOHF3S0ta?= =?utf-8?B?a1o0SGY3N3ZOTlIxdHl3ZzkrUnRLZWtpNnAveE8xQ0F2enpJcTBwdDh3MExC?= =?utf-8?B?M1VXOFFxNlA0OUFSM2ZwYUlhc1lMQ0lsOHlZam1tWVJGWU1MTm54b2tPNzNF?= =?utf-8?B?NTFzUTRzS0d1QnhYaEc1elpJR2lWdEx3OSthWXRKaUJVcFVtdjg5Smpjc29F?= =?utf-8?B?REJQWHNOeUhhNkMwaENOSmxaOWhMR1Y4Wm51QzMvOTI1dk9JeEM1S2xnZjZa?= =?utf-8?B?ZkJWMU1pdHVYOEVCRVl4ZDZDckc3bWlMZEtwMTd4ZVBrb2FsM0NRODloMFdO?= =?utf-8?B?ZXVFL3Bpd0RxRHJtYjNNd01BSFRvRjB0OXRYYkdIQ3lYRFlFa01PZ2lZVVFB?= =?utf-8?B?aGp1dkxUNzlzRHFGWWFvbWNjVDZzbnZRUzBZMTVnRDUwT0VVUG5wZjMvRVJt?= =?utf-8?B?Sk1sMDNYb3FzR3NkTVJUSnpvcFBxYWtvK1RNRW5pYUhMRGVtcmY0YlkxV3dO?= =?utf-8?B?cWRCaWFFcjRwL01HcG8ycHhTcHF3MGpZdWZrdXpTeS9OY2pPajVsVHZ3Tjl4?= =?utf-8?B?SkFlMDhtUDNHWksvckgwZ3dWemJERUVZZElKNUR0U0RLbURXOFhPcXp3U2Nk?= =?utf-8?B?QU9WNldLalBGREZjT3I1VlpoeStkYmdiVUNxR3VtYi9xbzMyM1U1UkFHYnA3?= =?utf-8?B?dENGVjFmVlhUd2tPS0haMTB6SEJ1MVBGaDJvV1lBS0FDbDZ2WTZadlVjZFFL?= =?utf-8?B?NDJYYmdEbm5vWk0zcVgvMFRabE4yeTJaMTFLa25RdVYrSFVrbzhWN3ZuTjdJ?= =?utf-8?B?YkRzYXdKT2ZRVWxUelVpUlB1TjhqN3dkZHQrN3pibDhnNjEyaXRFMHFxYnQv?= =?utf-8?B?Zy91SU5nV3dReDMwZjVtUmcwUnpJZmtMaGNra0RhVjMxQzhnbzNVaXhUZDhT?= =?utf-8?B?Z2h3VjFkbmdsWUFJdU94d01WM1VLSEZMY0lnTkNxRTFDenpVYWg4WndSeDBr?= =?utf-8?B?Q1dmL0crK3B1MVVhZG9aTXVpNFNrTTRRWmVTa1VKVUxlc2ZOSWRWT0xjUUxE?= =?utf-8?B?RmNoa1hhUlRuRi8rTjg2SlFnQW5kUlpwMlZzM2MvTnd0SlUzbWpvZmhxd0dI?= =?utf-8?B?bVJuRzhpa2tlelJLTGE2eDhZeWEzSytXczFIejRSeW9jNS9tUm9tV0FKQzl3?= =?utf-8?B?WHlqVUY3TlpuRFhVNUdVcklqSVBXYmdoYktrMkcra2gza09WK296THVRRS8r?= =?utf-8?B?M080STJUVHdHT3B2WEFydm5wT3BUam9IRjlUbGxIOStkUVZ0NGIxR0dCSGQ1?= =?utf-8?B?dkFoN25BdEcrSkFSUTAwL0FyZTh0N0E0MUtwL1NtTWNQK1ZGSTQ2Tm5jVFlI?= =?utf-8?B?K3g2OW90cG9VaXZ2TCtJRllGck9ZdVByYU84UXVGUlZpUDljTnB3TmFTY2xY?= =?utf-8?B?Y2xxSnBwcUhrekhyYzdGdXNNdis0dEdxZWQ0N2RqbW5zaDJqZjNWMTJhYklk?= =?utf-8?B?SzQrRys0K2N6cFNFTm9UaFplUE4ySmloaUJRTFVocDUrNGNaUDNUSmswZGtP?= =?utf-8?B?RkVRV2J4MllvZW5XRWNnR1BkT1NMZGFHZUo5STFLYlpKelNFMHVVWnBzZWFl?= =?utf-8?B?a0xLai9QWC9YK3hpRE1taDJocGdoOGpBWVNKbzBMZFdDWTMxaUc5WFY5QXVO?= =?utf-8?B?cXRSa215SC8zV05FblFxNjd1Q1c2R0txLzlBamg0cnVlM2lkZzltK1hjT0gz?= =?utf-8?B?TDBDVWY5MXZuSjRsZzJtY0JiNDNVQ3ZrS1FaajZzQnk2WFlDT3ZNUzljQmpk?= =?utf-8?B?QVVVUFN5cjJWU0U4cUFSNERMTW5oNnFyejBiVjVPSG1ZVjc1TFJJSFBwK2dr?= =?utf-8?B?OVA2ZzE0blNvcG9iQjExYXI5MmhQQjlkOXYxN25IVkRpVkpZcGo0aUtCczg2?= =?utf-8?B?b1BFbStMTVQ5WmUvV0lKd21RbmVBVm9VcFIxdjNqbjJINDhZTzRoVUxJVG81?= =?utf-8?B?SVc0czNZaUxNRURFbXh5b1pQMEZmUVd0ZXBaRHIyaFBLeTdWenMxYWxqdCtE?= =?utf-8?B?c3U0MDlSaW5tZGU5aTFqK2FCNUx0VkxPNnlOeVM0M0FKZmphVGRaOUdPNVNU?= =?utf-8?B?eEhqWlFtazlndEYrRVVnKzgxd0ROb0IrOVhVN1Y4ZVBIS0Y5aTIxdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 33e543b8-4640-4613-1609-08df1fb82291 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 12:33:02.5011 (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: 69brDaPq1Bc9ldiYQb/zVsGLcvA8dDOQYnHflFev1Ycpi8RZqBO0xl96eOf5xsXkUd8rUY4zUEiW9J4Q+3Mf+GmseKXPWjog8Cu59FRwNOw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH9PR03MB731891 X-purgate-ID: tlsNG-ef75cf/1790857985-3C212AE4-54BE517C/0/0 X-purgate-type: clean X-purgate-size: 2404 On 01/10/2026 12:52 pm, Titouan Christophe wrote: > Add a way to build minimal Xen + Linux dom0 images, and their corresponding > cross-compilation toolchains with Buildroot [1]. This effectively provides > a consistent cross-architecture development environment. > > Buildroot is a project that makes it easy to build embedded system images, > including Linux, Xen or bootloaders. Leverage that build system to build > minimal images for use in the CI environment of Xen sub-projects, namely > Unikraft. > > This approach is based on a Buildroot External tree [2] which currently only > provides 2 target defconfigs (arm64 and x86_64, both running on qemu). > It uses a recent development version of Buildroot that integrates changes > to build Xen on x86_64 [3], on its latest official version 4.22.0 [4]. > It also includes the latest kernel (linux-7.2.7 at the time of writing). > > As a byproduct, aside xen+kernel+rootfs, we also get a cross-compilation > toolchain (that runs on x86_64 hosts). This makes it easy to cross-compile > domUs for arm64, and it alleviates dynamic libraries mismatches when > adding userspace programs to the dom0 Linux image. As an example, one such > problem: Alpine linux is based on musl while your regular development > computer is probably based on glibc, which causes issues if you are > recompiling `xl` and try to use it in the Alpine image. > > [1] https://buildroot.org/ > [2] https://buildroot.org/downloads/manual/manual.html#outside-br-custom > [3] https://gitlab.com/buildroot.org/buildroot/-/commit/0bf8b2ecee6b1b41746e8863b57c2c5ba3a623b1 > [4] https://gitlab.com/buildroot.org/buildroot/-/commit/a962be2eea146e06661712159698bc7cbf3305f2 > > This work is derived from this original series: > https://gitlab.com/xen-project/fusa/unikraft/-/merge_requests/1 > > Signed-off-by: Titouan Christophe Thankyou for your submission. How are you intending to use this image?  There's no consumer shown, so it's hard to judge the patch. One thing I see is that it intentionally embeds a fixed kernel and (commented but not actually added yet) Xen, and I'm not sure that's a route we want to go down. As for compiling the binary somewhere and copying it to a different environment, we have build containers for that, and I don't see how using buildroot changes the problem. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 01 12:40:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 12:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438304.1657178 (Exim 4.92) (envelope-from ) id 1xCG5I-0003kN-PF; Thu, 01 Oct 2026 12:40:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438304.1657178; Thu, 01 Oct 2026 12: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 1xCG5I-0003kG-MW; Thu, 01 Oct 2026 12:40:24 +0000 Received: by outflank-mailman (input) for mailman id 1438304; Thu, 01 Oct 2026 12:40:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCG5H-0003kA-9U for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 12:40:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCG5G-001ulF-7s for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 14:40:22 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe54b3-bab6-0a2a0a5309dd-0a2a450587c8-16 for ; Thu, 01 Oct 2026 14:40:22 +0200 Received: from [52.101.193.28] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe54b4-4cb1-0a2a45050019-3465c11c4959-3 for ; Thu, 01 Oct 2026 14:40:21 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB5843.namprd03.prod.outlook.com (2603:10b6:303:6c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 12:40: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.0451.026; Thu, 1 Oct 2026 12:40: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=vs1PxZq7JZ8/813m9RWEjXX7iGjAHWkLX7wL7GUC11Po7GyIvMRn8+zdMtct+48THgn+XbkhtHOHvm27WDvElm8se5cwMpUdg3koT8OfqFgyhj69V4crWIFx/44FikDFUQ7OQpFVmZN1JPcRxauLxqFvdZxFAus0YOk5PyD4xaWn2f78z3pDh4RbfHJ5Kj0RSDlE4k3akSv/Y0UpRyzWBoJMY2+ugqOjJK2VJQb5o3TxtIFvCaZEr6UQa7xJV3/4mYR1BR5yIPlqeJ48tXT1g93Qw57wSiFR6vG/BzcuQ8EECPC3BHq0RVmZafBiv7dDg50hKLtrbkDoQKv8cOwg5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Y4cere2LRtLINpQR31Xmx3gH2C2G6SLtbMgX1aAABLM=; b=Kq/2UmYH6UCLx7juY5VJNBxuMxn5qoaS1Zqzs6DN/7vATyRrhDQSvElImm0y1d1dCa3SSos23AHtZPO85DsVeMFn9AmxbHz1TuRBZlzD0bIm5uMHQ4+dMAVgBq7zp8ibAWwifvvJuCgRWmRq+ZYgNnwzsWc6kTwCeihJSjsDZ+zVBk8FAVQH4zf27hgpVpkwDqdtxjORYowmnBHCQi1ntxC9Nf14PB334VvAH+YKz1S1f+3gkkoLhTPVXIIuOl/3hrseTonc56waFB2CBORF009EXxfJkmcnXkeoqwH/7N6JMT8wxCowckPE7f2qr0JyeRU0yI/gTa93aO3Xgb720Q== 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=Y4cere2LRtLINpQR31Xmx3gH2C2G6SLtbMgX1aAABLM=; b=MzN0pLcZyv1yDjp3bI6fRBvP4vseWoPfYdMKeIRF8K5VeUV8j2Z57NSZCtJpowrm40eDKlxXdmSQOMMiSiZWH09DQtMqg0HjJVfLthuDuRzAbaTIjDlxRXRGdQoKUirHABOG7QTnxgRqDZxSqtLwD5DtGIK7JnpjRTHubFK0Csw= 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, 1 Oct 2026 13:39:55 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Dmytro Prokopchuk1 , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8 To: Nicola Vetrini , Jan Beulich References: <4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro_prokopchuk1@epam.com> <0a286fe9-2133-4f28-8fab-59f4e51d1484@suse.com> <446354d93ae04a07b86d7293705d7e46@bugseng.com> <0373fcc0-5bc9-4140-a2c9-52a31c7e42b5@suse.com> <2a8557d7ba88e95ec75148ff180ae0a0@bugseng.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: <2a8557d7ba88e95ec75148ff180ae0a0@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0348.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18d::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_|CO1PR03MB5843:EE_ X-MS-Office365-Filtering-Correlation-Id: 7cfd2e86-a659-4289-a58f-08df1fb9263d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|7416014|376014|18002099003|22082099003|4143699003|6133799003|3023799007|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: Yn2tUuNQMNDsb6nShzVFyuRBZHjVzMZ6AKaxiYOt+nip+JFx0JDs4clYbvRhRLm4UqXZgswK+ejU4vw6G/G+mCSda9EN+YU951kXIOF3KH5RzLetI24qVeZuOY7i1TI3tiMyHY6rjPcj9j0lMtYlNjo/OXXKoTW+zYKcNDh+Zj9EUpe9UTySa+XQx4M9a4bFXdhHbPGnIy3aGoOotwOW3zrtgvT8ATzkqlDdvXEYuLpP9o7lo+0ETV+B4qRiz73YDkuQ02YNOQ5O5SLzi2p1UJ0PB3u6Bo9f3uRQNA3pYwlwY9diDUE6qZe2i1NBAnCjUdj4BGGxFmIzN+i4whQmu4gtA4cKoGgJZdohm3un+TwJFgHE1QPn5lbKi0ULPaEfW4UbKmriccfp86XpdxWVmyeW4CtABlq/QGkk8XC4bFlSR3TD9iWeBasTkTtJm6bTJuX7i7tasK5uyx9TO7a7FcV+yEeb1oStrrBuDoPpQ9xmsPmRupMVs26FpOyQ/+KFjVGxkoi1JAORpBHzI8NIgLp3RYWuopw2PNvOcvoI/a2oMUtJxC2Hf2SnRrLj6VuZ6e+Ra9mj+WoO50UIpLyMT4uRxc5Y8MU1V9r+XPOytAAchOn9PCmJpp6mZltMy3F5LsqafSkY9Cxh/8ujWwcLz/pB7u5uSN4K9ThIYjCMg3Q= 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)(7416014)(376014)(18002099003)(22082099003)(4143699003)(6133799003)(3023799007)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dEpCR09KYTV4WHY5UDBhYWYvKzJLUzUzOHVZUU9DU2hRT0xyNi8wTUZ5SG5Z?= =?utf-8?B?Mm5wVHJTU2dsS1EvM3E2eUljUkxnWnB6cG14VGw0cnlXbi9CQjdBcFZLM014?= =?utf-8?B?eVg0T3pVRDlDa0tZb0JTTHBuVTk3a2ppbkJHcmFrcDQ0RzZvam9jTjI3Mkh5?= =?utf-8?B?UVIvYVRlclBSR0xnQlFSUVpkVGQ1SS9xeUVpR1hkcFg0WEtXcHJIR0RjWkQ1?= =?utf-8?B?WS8ySnlqb3RveFFFS1VMejc1V2lWWnNBdVVjZ1M3dGdZWmlpeXU0dW9kT2cr?= =?utf-8?B?WkFocXBvYlVpeUh3S1pESm1tWnNncUdaclp6N0VmNVlKVXNJREkzSzU1WjRV?= =?utf-8?B?Z0FobUgzb3RXd2JMbWJTdU9PRWppSDBwbzgxUVlyOWlaL1FLVWN2UWozZlVR?= =?utf-8?B?YmlORWFlMThiZUk3blpLTk9ndHRiSmdIMGhsbDNNZjNOK1YzWXJ0bHN2SHNC?= =?utf-8?B?N1NGeTZhY0JVWGxhaUJaQlZHOC9SUnJNTGtiUWg3M2NBdjRFOXcxQ3RjVjds?= =?utf-8?B?c2dCSUZIdW12STFJb1N0RkVHY0NmUHdIRW5FRGtwVDJzalVnSzhDTk0vcnhn?= =?utf-8?B?bEpQbmVMSk91U2ZhNlpWRTNBaklQUTR2TGNYV2Q3c1dFeElnRjQxQXRXU1gy?= =?utf-8?B?S1czdGRFRjVLd0ZjQWg5aDdjVFVvQThvbEFoOXNIdkxxQ3E3OUhkQlI5azVD?= =?utf-8?B?RTVPa25IUFJCNUE3bkRyN21pa25WZ1ExUWFLZCtnTlZvN3ZhanppK1p6RDB6?= =?utf-8?B?SEdXOVNXSFpEMGk3cDdCbERYOUxrbXFvWmpBWG1vNjkzazF5WUtnVWZyeCtP?= =?utf-8?B?TTd3ZlF6MG5hejYvWXh6TVNsTVhlY1FENGF0YXErNHMyTHhLeXJ3ZHBua0lY?= =?utf-8?B?cWZ5K3JtRkRtNnhSYVg0dlN3ZGNlU3VSaE5wMkxIYkloczRncUpLaEgzdkxk?= =?utf-8?B?Q0JSNHpXWVZLb0QrL3U4VTBlR2N4bENOdElvSDJBcVoydlJpWkd3dDN2QkQz?= =?utf-8?B?VHZvYWo1TjNuR056ZUNlWldST2p0cjAzb0cvaFd5L2tqeG5CUjJGeUtkeWJB?= =?utf-8?B?M3o0bkZoUHVOcVRkSzl2Ykt4OWhNRnFkM2U5L1owOHluT0VkN2o4WTFVSGhT?= =?utf-8?B?OVJUQ05MSG8yMVR5VWRUN3pDMWZrd3N3Zmt5cTRHVG9uTlNBQTROSGt1RHFw?= =?utf-8?B?WjNQV2FUOEUxL3kvaGxGM3RzaG9QdnBSNkExeGxacmFOelpNYmIrY2dvSjla?= =?utf-8?B?OGk5THpacVBRdUl5L2pwejJBTmV1K3VnZExkQ0UzQ0dXMnV4M2lHaTUxbG5y?= =?utf-8?B?OFpYNTlxOGNHSklVTHF4Y29sVTRXcklWSXRQVWVLSzVoZEc5c0JFUGszcG5B?= =?utf-8?B?QjN1S0hpUXo2K3MvbzdDUXJzZW9UdjgvZnJ0SkNRUzZqRmtnMEgrMkNQb3Fs?= =?utf-8?B?WGpXd3hia3BEandWSFZ1eG1DSVJFQTdPZ3JtZDI3MWlpUEx5L2ZqSW4rLzVP?= =?utf-8?B?TnZlck4rbnNxN0gzdE5mSUVKUWtTbWVaOVpLR094Q3hDb05TWjNIMEkwajRy?= =?utf-8?B?UitBcVNHRWh3TFVKRno2TEVPK2txd2lHZUorai9RTk9pclc3c1FBOW94RE5Z?= =?utf-8?B?TVlsK3d3VVVTeFZ0ckdQUjAwYzRFcmsraEtaNHRJSytDejUrMVYrZ21EN2h6?= =?utf-8?B?TVEyY0RXczVObFMrRWRLYmVCalM1OThKck0zVTc3cndZN3Z4YWwwK3B1MlRM?= =?utf-8?B?cm5KRGwwZkQrWS9vbmhMeTZVWFJRZ2xzWEJiclNVdyswL0g4RjZBdXQyQWV1?= =?utf-8?B?REZlYUtsdlFUamJkL2E4WFZ0Uzk4ZFhFUk1CWXhRMW05MWlqZC9RTEsyeFVY?= =?utf-8?B?dDUvWTRtS1hqK2g1Q3VNWE5ibStoNGpxMFkrZFFqTnhYakJHR2dMOXJncnZy?= =?utf-8?B?eHYwNWdUc0x0ZWY2TjRBTzc2V1Ywd05aYlltVVE4UkFwcU5yWkJPU2dvVjk0?= =?utf-8?B?eUpFL3h3WmJOQXRFaDRsSkpWT05WV3pNV2FkWE54VTEwZWhtQUR1Q09OTU5L?= =?utf-8?B?eDVlR0NvSWZabC9HMWd3UlZUbi80VlFYMGU4VlZURkkwM1dyK0FoU214UmZs?= =?utf-8?B?aWxycHVuYXJDMjNLQlJzNXdrZ1cwU3BkN2ptSW9XaWRhVTBEd1ZDM2pCb0hD?= =?utf-8?B?UG1Fa3RYT2djWURINXUxOXgxSk9Tdkh6aEhXNTA2NVlUMFlObTFWTEpXSXpU?= =?utf-8?B?dUZtZVQ4K2tYMThwVDRHZ1Y1S2huUVBKTkRxQnRzNlp2dEplVTZTNXRTWjhM?= =?utf-8?B?OVdBdHZpTjk3N0FqT1hoY3ZmODFaaWdMSEVLcHJoRURQY2l2ZHU0UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7cfd2e86-a659-4289-a58f-08df1fb9263d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 12:40:18.1657 (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: QwY++0w5wPwqARvTbN8LxTZKiOA4CTAP2RvKphzFlNeHM85JX4f00JMc1bzp628vTi5YO2DcslE0KMDV8JI/PfLpFim8FsF6Y2CkUaAkwxU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5843 X-purgate-ID: tlsNG-c201ff/1790858422-724B42A1-A60B3083/0/0 X-purgate-type: clean X-purgate-size: 3790 On 29/09/2026 6:52 pm, Nicola Vetrini wrote: > On 2026-09-29 17:11, Jan Beulich wrote: >> On 29.09.2026 16:56, Nicola Vetrini wrote: >>> On 2026-09-29 15:40, Jan Beulich wrote: >>>> On 29.09.2026 11:03, Dmytro Prokopchuk1 wrote: >>>>> bsearch(), memchr(), memchr_inv(), strchr(), strpbrk(), strrchr() and >>>>> strstr() all accept a const pointer/object but return a non-const >>>>> pointer >>>>> to the matched element or byte, matching their standard C library >>>>> interfaces. The const qualifier is deliberately stripped so that >>>>> callers >>>>> searching a non-const object get back a mutable pointer to it. Fixing >>>>> this would require changing the public API, so document these uses as >>>>> deviations instead. >>>>> >>>>> Update docs/misra/rules.rst to note that this class of double-use >>>>> library functions is deviated on a per-function basis. >>>>> >>>>> Signed-off-by: Dmytro Prokopchuk >>>> >>>> When I prepared my 11.8 series [1], I was wondering whether we need to >>>> go >>>> as far as deviating these. Since we now uniformly take gcc5 as minimum >>>> baseline, there is (at least in theory) the option of using >>>> _Generic to >>>> cover the dual-use. One question there is whether Eclair would >>>> recognize >>>> such - Nicola? After all, looking at e.g. glibc's implementation, the >>>> functions themselves remain "unsafe" there; it's a macro wrapping them >>>> which puts the lost qualifier back. >>> >>> Could you provide a concrete example? >> >> From glibc 2.43: >> >> # define __glibc_const_generic(PTR, CTYPE, CALL)    \ >>   _Generic (0 ? (PTR) : (void *) 1,            \ >>         const void *: (CTYPE) (CALL),        \ >>         default: CALL) >> >> while the declarations still are e.g. >> >> extern void *memchr (const void *__s, int __c, size_t __n) >>       __THROW __attribute_pure__ __nonnull ((1)); >> >> (and hence the implementation still - necessarily - casts away >> const-ness). >> > > Ok, will look into that We are going to have to deviate the implementation, even if we are using _Generic() to force const-correct behaviour from the callers. We could duplicate the functions, but there's a different rule about that.  We can't use ELF aliasing tricks because that breaks software type-hashing techniques for control-flow integrity. > >>> In passing, for stronger >>> guarantees w.r.t. _Generic it would be better to switch to MISRA C:2012 >>> Amendment 3, which has specific support for that feature. Keeping AMD2 >>> and using _Generic weakens a bit the safety argument (though one can do >>> an analysis himself, of course). >> >> As this keeps coming up, we surely want to discuss / progress this move. >> >> Jan > > That makes a lot of sense. We could add to the next community call or > maintainers/committers call to present the problem and propose a way > forward so that all stakeholders are aware. From my side, I can > explain what moving from one to the other can entail in terms of > static analysis, while others (e.g. Andrew Cooper) may expand a bit on > specific C11/C18 features is desirable aside from safety. > What I've got for now is all in https://gitlab.com/xen-project/xen/-/work_items/201 We want _Generic() for const-correctness reasons only.  (And possibly API transition work - this has mixed results but can substantially reduce churn in a series if done well). This depends on moving to C11, which we need to at some point anyway even if weren't for _Generic(). The other area was the use of auto, but that's sorted now and will continue to be an implementation extension until we get to the point of considering C23. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 01 12:44:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 12:44:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438312.1657187 (Exim 4.92) (envelope-from ) id 1xCG8p-0004Lp-9z; Thu, 01 Oct 2026 12:44:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438312.1657187; Thu, 01 Oct 2026 12:44: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 1xCG8p-0004Lh-76; Thu, 01 Oct 2026 12:44:03 +0000 Received: by outflank-mailman (input) for mailman id 1438312; Thu, 01 Oct 2026 12:44:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCG8o-0004Lb-Cy for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 12:44:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCG8n-001vOp-MJ for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 14:44:01 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe558a-bab6-0a2a0a5309dd-0a2a450bc348-24 for ; Thu, 01 Oct 2026 14:44:01 +0200 Received: from [74.125.225.98] (helo=mail-wr2-f34.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe5591-b7e8-0a2a450b0019-4a7de16283d7-3 for ; Thu, 01 Oct 2026 14:44:01 +0200 Received: by mail-wr2-f34.google.com with SMTP id ffacd0b85a97d-48aef5d66c1so1808199f8f.3 for ; Thu, 01 Oct 2026 05:44: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-48b0db63f03sm3024040f8f.39.2026.10.01.05.44.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 05:44: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=1790858641; x=1791463441; 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=8Q04+ExD9gBrPchUkbqpfjrElnaAfEp3+k3QkvpOUok=; b=Ky8fYAicJNM0QQA97AqX4q0AT45IDWa1ecOR/mqAebvBBxV5CBkTAq8QwBhilE8Zia t0qnNCGnr1UrLfzaZJ45kMgUy8eieEiifvWouqzdNErVkDQCg5BzJ9+NeKuAHBFvprnm NhQjOlSUWHTZ2Vmb6ONn24g3I7585/hN9418jb/yZ7q+zOv+RquzTp+MVP4CkFZwF50x cQ8qbHMlMYWbJpYca29nG9RopBE/twXzB8xlQ4Y3LzNCWAUQ/PN13M61LjYsRfpUHbR5 BvqszIJrIXN93LFeJIcHu++jGX6cvOMBap8tgYyRbDtQcrrTYETbqsjWTPJ39SbpomYO 5CWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790858641; x=1791463441; 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=8Q04+ExD9gBrPchUkbqpfjrElnaAfEp3+k3QkvpOUok=; b=gat0ZYh7Qn6XdGLG12F3XzuEo+4BYWU0i/59xr4njo1OUT/A4u4ubZXmQxBV7TN0oZ gPpem1aaUFDpV5eCQD3i6CvSy15NyBKM0rwUPiBOnzwnzoqlsIizjCGL1qPrTkOSnyc6 yaOkwDLd9N1fA+WAcHJJmcYbjIFWbYBo6lGlMPsl29CKLKYyapgHZMiHS+qOGWuNd+fq gDSw5oLZRiiGoucT91W9lCybEPU2GqouQol3yd3v2LBkGS436yQZZHsQngshzoZ0wyld D6irqTCwtDwWw0dw6VffOj6Jb03ain84zb+HWOHPZmhJ/p2amaQyo+wDUUMfZtwAk2Us /ioQ== X-Forwarded-Encrypted: i=1; AKwUvBxPa+E429z4AUmplgeaJo/1ixS99rKTpZ6g4m95g+v8e/usKnQwxZb/jo/63nIBRLuBgKiHLn1aObw=@lists.xenproject.org X-Gm-Message-State: AFq9FYKZLTg3A9yyrjsOe1ppr+atvMjA95jZpujfsFJdsRDPvfaRkFBz quJMgLBlQQQ2lrrJbn3xjPvDfp+pPiEA4Thl0tBWDYm1AmPeILlDVIliewTv/4h2sA== X-Gm-Gg: AYBFou2g21+jV5grAPFefH2ivnQGYAaecLoaKZEB++AzCQfjcfLm5Z51LDlmlYlpV+m 4nqTDqrryp3j/hnP0w05qVJ6JKilW8KTgSj0x9R/abD6lg4w6AnDZYZRrJxPjwY+kIkXTx96cUn OS93yMxkZvNi1nN5jooURL2syJ+dBkuGtQfHT9615Qn5kapuz/HdoTTQqdp5ql36yASvBthiZkN BSsHUe/8JdateRrGHekYx8Xd86gsw8k142/TvsmqH/lFU+ylw1rJ4N4jkPiSBsgGq03zZ2oWW4W H3mdK+AHBKSqTWEN0lxQ9XIrVWAo63sOF8ZoUmgucxEnVMXspjOTyNayLbZ7ISJlGhGy++klYUx YcJwSmV2HC7ABL5/60J6OKFyj8z7ypqslHeXRp1ghVhifo84Cc7MtZxrhv/bugGiD/YPZvGV0xL 6eHlhiM3w13Dfy2f7O1b5d46G+bCk6OrM96uiBWqHzjNHx+D5ijsgO5RMzYVOAi5129/Q2M3rlQ PJ6PxAgOh2dkPlZ/nIh14luKW0KOpD65m34UV9VivLch7bR6D6mkwHnDP1G5Q== X-Received: by 2002:adf:e007:0:10b0:48b:437:8fce with SMTP id ffacd0b85a97d-48b043790bemr5136035f8f.29.1790858640963; Thu, 01 Oct 2026 05:44:00 -0700 (PDT) Message-ID: Date: Thu, 1 Oct 2026 14:43:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8 To: Andrew Cooper Cc: Dmytro Prokopchuk1 , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Nicola Vetrini References: <4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro_prokopchuk1@epam.com> <0a286fe9-2133-4f28-8fab-59f4e51d1484@suse.com> <446354d93ae04a07b86d7293705d7e46@bugseng.com> <0373fcc0-5bc9-4140-a2c9-52a31c7e42b5@suse.com> <2a8557d7ba88e95ec75148ff180ae0a0@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790858641-1B0DD9EA-D74236D6/10/78276251493 X-purgate-type: spam X-purgate-size: 447 On 01.10.2026 14:39, Andrew Cooper wrote: > We want _Generic() for const-correctness reasons only.  (And possibly > API transition work - this has mixed results but can substantially > reduce churn in a series if done well). > > This depends on moving to C11, which we need to at some point anyway > even if weren't for _Generic(). Why is this? Can't we use _Generic() as a compiler extension, i.e. without fully going to C11? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 13:17:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 13:17:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438332.1657196 (Exim 4.92) (envelope-from ) id 1xCGep-0000Tz-ND; Thu, 01 Oct 2026 13:17:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438332.1657196; Thu, 01 Oct 2026 13: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 1xCGep-0000Ts-JQ; Thu, 01 Oct 2026 13:17:07 +0000 Received: by outflank-mailman (input) for mailman id 1438332; Thu, 01 Oct 2026 13:17:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCGeo-0000Tm-Op for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:17:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCGeo-000OQ0-5l for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 15:17:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe5d48-bab6-0a2a0a5309dd-0a2a4502e42c-24 for ; Thu, 01 Oct 2026 15:17:06 +0200 Received: from [52.101.85.50] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe5d50-6ca4-0a2a45020019-3465553213da-3 for ; Thu, 01 Oct 2026 15:17:05 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5847.namprd03.prod.outlook.com (2603:10b6:510:35::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.26; Thu, 1 Oct 2026 13:17:02 +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.026; Thu, 1 Oct 2026 13:17: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=q35i35cXKkZCIu0Z8zKo/TrsaQfUppRlH+IdbaDxeuNc8VjKUI5+RAZRU9jXeedFthzEvvxDnPdo8NhnhpBeDt2TZUfkGTpNxdIkR/6nMp1giRQqwG2CEKfM2EvSkze2jJGPh61GhVlFyNaJsSyPcVvuZr0shkjyhDyXGaaugrRRNCttluRuSuu+vlRd4+OmsVz6CZe9EQAN6EJ5GdvkZY3uwk80+cQ1VBXEAhE7yYMD7kUtHzkwuncLwcP9mGrtnfwz8509oL0DV/aXi4+HjUJ968jACimdEpY5d56+/wj0oAbCcvXGeawX1gEPPDoKzQ9j2dY7cr0RoRlPSv6s2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pyP/jQ+ZhCjRF5zBitK2wtGaCPOBactiBs6oTJjvKgo=; b=U5bKfZSnUEEcs1BqD77LbzQb1unX+R3SeIlgrWjXvOqJfDlLZq3uGjjpnL7Jjz35AEjWAfK1DHYKZZ6DGaytyxgI2hlSP/Xwx7c2vScvhRfX2yu+exB4yOPD8WwrUH6MwVs1ddXLh3eEbzoQuBpVQdtFwbnMP43iqoJW+QjyMO/UjCrIYkvrcW8x4kF5D/ObJ0r4DOl0Ol8NmmS9YcK1UKgAwqc5Gm/voxQrS+cxfYOWNtLXoYGi6oKW8MWkaMsz8w+P1ibCQDp8fCrCsj++OYUJgHGCbNUKlnwzTJ1CRPyXR+pvDN+vELnnqXgHrptJtUCntzw0qIN/r4edq5gbwg== 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=pyP/jQ+ZhCjRF5zBitK2wtGaCPOBactiBs6oTJjvKgo=; b=Do7aMrJkWg5qh1GDHHfCisRfCqbb2MJluDxtwZ8RV+ySn3DT+lDnyR18LheyzhnXlBbjrkVUHkaRb7BISujhslncGSjCMi5AxuzPfMX/OENRdpCGIIsPW7MNrKggUzX2CoXKGNoXZLp4rwCgiZqFn+G22kF0Fvlcwkcx1vapelo= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3cb25b4c-6470-44a4-bc46-55776317ea67@citrix.com> Date: Thu, 1 Oct 2026 14:16:57 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Dmytro Prokopchuk1 , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Nicola Vetrini Subject: Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8 To: Jan Beulich References: <4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro_prokopchuk1@epam.com> <0a286fe9-2133-4f28-8fab-59f4e51d1484@suse.com> <446354d93ae04a07b86d7293705d7e46@bugseng.com> <0373fcc0-5bc9-4140-a2c9-52a31c7e42b5@suse.com> <2a8557d7ba88e95ec75148ff180ae0a0@bugseng.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: LO4P123CA0551.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:319::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_|PH0PR03MB5847:EE_ X-MS-Office365-Filtering-Correlation-Id: 5906b5c8-ec6d-4b8a-e536-08df1fbe47ba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016|23010399003|4143699003|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: R+PzlEJloZdr2RfoWtvMAAtOu7vnfz1n8HWh6gDkifXzeC+1Nx4LyihHg8I/VeK8a1wJc92NJz66glE1AW7Ycaw4fPnXzvbQgaFwnj8cSpiaL7rYi0MgQl7vWVxUEyfCJg+Yk7DJNvA+0G6VkC8AcRcDWsQ32j2VG0C+mvJ8mvKk1JSvzapXFrZBYRVUplXUdvSXUCUAVCqq4JGsP93MK3gGyUJM+EQjy1H/Konk1jpMwrgPvYVpJxC0elKWhhVLu5Ye2wbUreNwqDeWVpS11mz5ixjsxmzxXa7ugtjGR65dGcT+mz4j9e3XyC29ILq+PE9geyeTx7y9b3wMND+YLI0gPq3vC0tt+3EZWS2LtetuN8/JUF4apfDtLrjqmGy8jDaHD0jqjfcwoUtrJzl4GqtsbbKrWAoIjBw/7zSADaJZyqmkESgFEIgyxphqLQK2Ym9ow8BDwL0bLD31ClT88I61oGxfCC+SUnjeH6W4UFA5h6s93ml0w/oOC2kEOpEBz/dyYNRdM2GMLTySHmTftXZPogQ5j4DtnjgbUkfd3XMhESL3m+4rbEnqrXsS87pLzFhEPpEiQQVV8K5VgDv0pox/H5b2gOOUfmGiiHI/N8e47mvyLaY1X4b/QYePoEhPuM6T4vUlmeyxocDtil711rUQdu8DJk0GWjes1NBe+9U= 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)(7416014)(1800799024)(366016)(23010399003)(4143699003)(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?KzVaZ0dMa01TLzJwSWJ1Sk0yLzc5Y3FXQ3N6T1diQXZIc2xCbmxnWkpiVDdN?= =?utf-8?B?djhhL3BDSUdPTHRQR1A2SURndXFuUWxwVGdtbTQ5V2ZZRERQNzZ6SXhWclRm?= =?utf-8?B?SDIwRk5ZdGhpMVFuSTBibGNkbjg2UGo5N0JHbXZqZU83TzVockhyalRJOU0v?= =?utf-8?B?TjZzQTBGbW5xQ2N1SnBoTUhCT3VoNHpVNzhialV4L3NGaStTOXk1MDRaN0sr?= =?utf-8?B?MkpHNzQ5QVFvYlh1eXRleVNoS3dDQXRRakNoQVVkUFF6dWtyaWUzVndTZTdZ?= =?utf-8?B?SEZ0eGdBNW9IaCs3UkpwbGVVNFY3akE4eVBKeDd1dUdSQmpiSlhEcDVSUEg5?= =?utf-8?B?eThkZ3pjRFF3djkvOTZlNFhmczhXdzI1NGYyLzl4WGx1ZjF3WVVWSVNUak5X?= =?utf-8?B?QjRqMjdoSG8yTlA0dk9sWndIYk1HdHFtbzN6S2tFS0lTZkhLeUhOc2lXNVBF?= =?utf-8?B?NjRGU1hNYWY4MHd2R3M2THYxUEhJLzNwYS9QbU1mdGpGSEw1ak5qYW1YVnBp?= =?utf-8?B?NHFiWjdRVU9rUFVRSjZBejJOZUNCN3lyUTl6RWJseCtwbEczbUVsNEJXeE1C?= =?utf-8?B?KzlONzMrZ0VmSVJuQ0NWSTV2Znk4azEva0JwM0c1L0s4RzhLenFUT0lvR2ZH?= =?utf-8?B?MksxeWUrMzlIUUJlSzcxWTF2c0hMUnpsbWtrQittM05MN0pPR0NuNks3aUlK?= =?utf-8?B?RnZ0b2hVNUdhMWZucXlMdDV0QytiVW14N0pDSWxXanhkWDByR05VZ0VOb0FL?= =?utf-8?B?bytXemVBKzdoVExKWHAxV3NzVm5CZ21TU2FoaDBDWndVVUtJYmE0TTY3TS9o?= =?utf-8?B?cTlMNEZUVm1lSUk5UXpodmlvTnBPRXJiSzB6YkdmdkxMdUVwa2ZzUXp3WXNP?= =?utf-8?B?aUxrU3hxYUZnUDBkbUc0NDN0VG5VRzhpcXZFT21pSUk5OUdXTWxxQkNSZHdX?= =?utf-8?B?MmhqUXRHOFFNR01hMzJNR1lrbnlpZmd5S0pSd3ZkZmVjd0dEZEFlSGIwbEpP?= =?utf-8?B?VXdPaXBRa2kxV0R2b05IMWhRVXlHU295SnVENWFyL2o2bW9QbFNpT2FPWjIr?= =?utf-8?B?MmU5eE9Za3ZJZHo4ditnS2sxZWFzM1V4Y1psSGZZRHZtc2ZhdjJZM1RYTVBD?= =?utf-8?B?TUU0ZWV3U2NnSlo2cG1HZWVublR5KzdqL05lc1p2U2NWY3MvN3hCclRFK3Bj?= =?utf-8?B?dGFRMXF6ck9jUEdSbGRDTnVFM3Jld0R4Z3lsTVZKOStxbmRwZG9TcVNsZzYw?= =?utf-8?B?VXpBVzYyYUEwU2dKRjYzMzV6VUJHT2R3R2JEcTBlbzZJMFM2b1lFSGN2bFBi?= =?utf-8?B?SitqTUp0em5LaXJtcm81WmVGTDUrZlVDK20rOS9LVEY3NERtYW5wMlYvbXVx?= =?utf-8?B?MUtIQTZrU25zTDlCQW5nRzgveWNENDMzcC80SUxGeTZpSUsyczFPa1dtc25S?= =?utf-8?B?OEl5cTVMbkFKSXpnbjdlMDBuV2NrL3JOVzdpTW1GZXN5dEphck4rQU9tSzVR?= =?utf-8?B?eVVjZVRnYWcyRzM5bzhEdFREc2tTUFpFSDh5eGxmUlJVbjhsR2JSajh6MDVK?= =?utf-8?B?SUcvL3JWTjIveGFYU3JhVjhwZmVoRzlEUXYwbWVDS2Z0dmFFcU1qTi9OZEwr?= =?utf-8?B?RjhBV0xoQ2JRYjg2VUprQnd4clBvdXByKzl2WVhBSzRRV3hjYWdPTGFZbXNE?= =?utf-8?B?Yy9iV2xnaGtSSEx0UnB3RWV2eml1UTQ4d3ZkSDlDWUZMNUJIM1RMZlZ3R2cx?= =?utf-8?B?NmQ4bDlFblhMV2pjZ1kwS2tFWjkxVTdYRFdzN0lsQk0rbEN3aTZPVkYrZUt3?= =?utf-8?B?TmhTRytoc0dVSmFDRUpuMFNDaGVlYU1NTVFPSWJ0UmJqbTExdnFEQmRrVDdO?= =?utf-8?B?cm9FOFQ2RmZPdWczQTNmY3dCWjB1UVRGRFM5Q2FYNXpXTUlRUEc5Wjk0L1hp?= =?utf-8?B?MXkvelZkeE8rY3hkNk0yK2VJQi80aWJDSXFCOG0xSWtka1h2OS96aFJXWGVK?= =?utf-8?B?Vi8zWDZTUnNBbGZXVEMybGdQdkpyWlNDVFAvYkdHL0RlRklDcUZyWnI5UEpU?= =?utf-8?B?N1JJYWFJT092ejlLL2FvT2xsMDc3SXZ4Mkk1ZTdiL3JZQmYwM0dCR0JDc2NF?= =?utf-8?B?bXo3b1dnMWFrL0lhQXVwNGtHSXBYRUYrcnhjTjNJeXkzN255dGpXRndaOThZ?= =?utf-8?B?RlIzdTY5MFIwSnluUWJITmhTVDZ2WGc1WGNGRWJUQmxxS2d5ODlpekxacng0?= =?utf-8?B?L2d5MnQ3OXlrM2pzZEp0T2kvQ2RCQ0VabGNuSHlXdHlQbWJQeEdDR1FzeGZB?= =?utf-8?B?eG1SQ2NucDV6Ri96UTNjeXIrdGNwdzFxSFczbHZXWGxDQkdsaTE4UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5906b5c8-ec6d-4b8a-e536-08df1fbe47ba X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 13:17:01.9638 (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: dN/+7a1QMi1v4DVRNzs8kZ/DPRl/ZNhGjmQG99SU2w/eYTNG9UfcLH6UNYccpWAwZr2CVUbiDAgGERhHrint94InTMIJrI/mXyYf2yQpjnQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5847 X-purgate-ID: tlsNG-720697/1790860625-662A92AC-61CF9459/0/0 X-purgate-type: clean X-purgate-size: 648 On 01/10/2026 1:43 pm, Jan Beulich wrote: > On 01.10.2026 14:39, Andrew Cooper wrote: >> We want _Generic() for const-correctness reasons only.  (And possibly >> API transition work - this has mixed results but can substantially >> reduce churn in a series if done well). >> >> This depends on moving to C11, which we need to at some point anyway >> even if weren't for _Generic(). > Why is this? Can't we use _Generic() as a compiler extension, i.e. without > fully going to C11? AIUI, the parsing rules had to change in C11 to support _Generic()'s syntax, and IIRC Eclair can't parse it without specifying C11 or later. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 01 13:20:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 13:20:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438341.1657205 (Exim 4.92) (envelope-from ) id 1xCGhx-00026Q-4I; Thu, 01 Oct 2026 13:20:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438341.1657205; Thu, 01 Oct 2026 13:20: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 1xCGhx-00026J-1H; Thu, 01 Oct 2026 13:20:21 +0000 Received: by outflank-mailman (input) for mailman id 1438341; Thu, 01 Oct 2026 13:20:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCGhw-00026B-3E for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:20:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCGhv-000PFk-GB for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 15:20:19 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe5e03-bab6-0a2a0a5309dd-0a2a45058628-40 for ; Thu, 01 Oct 2026 15:20:19 +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 6abe5e13-4cb1-0a2a45050019-c387df83b2f0-3 for ; Thu, 01 Oct 2026 15:20: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 BC52E1F891; Thu, 1 Oct 2026 13:20: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 6A8EF134B3; Thu, 1 Oct 2026 13:20:10 +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 BQdsEApevmp1JwAAD6G6ig (envelope-from ); Thu, 01 Oct 2026 13: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=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=1790860814; 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=W3wx/JYdxaFYE/GNhkO+TB+PZjlOIA7Cto4QnX6PjS4=; b=hnz1WM0ZlpcI5AcAjZ9tdEiQ/B0k7aisk6eBnP9YJs6ansgS5QjB3hSveUqBIg7IDUg9E7 yS50L+FUezTyV6bDjm5P/qud00lEWHLF4P7o5DJTbVQaMsdAh5Mu8iVYTdRj+ubaAw8cJI SOVtfGkEsZuseGs90JX5hIneUDKKAZA= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=YrxDM27C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790860810; 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=W3wx/JYdxaFYE/GNhkO+TB+PZjlOIA7Cto4QnX6PjS4=; b=YrxDM27CDzaYUXj3nUBEdXsNdAs1A2P5dqF8c1yE7s0VKworwRAkFe9DjlV2tI6uuG+Jx4 MCoOhnTlOOkoPWGNvQKV/79Nzp0/hePqOpDB892YKhNtqcKxyy5s1sFV4QnG0elCFDr0UM KjBSFjSEmlmIM1bZfFWl9UZIx6vw+NY= Message-ID: <873855f4-5ba2-4254-a315-d29822f64447@suse.com> Date: Thu, 1 Oct 2026 15:20:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/sched: fix scheduler callback verification on init To: Ruslan Ruslichenko , xen-devel@lists.xenproject.org Cc: dfaggioli@suse.com, gwd@xenproject.org, Ruslan_Ruslichenko@epam.com, Jan Beulich , Mykyta Poturai References: <20260925213022.799625-1-ruslichenko.r@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: <20260925213022.799625-1-ruslichenko.r@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------lbgGJ35cy8TT8LthX0IOxenk" X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: BC52E1F891 X-Rspamd-Action: no action X-Spamd-Result: default: False [-3.91 / 50.00]; BAYES_HAM(-3.00)[99.99%]; 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)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCVD_COUNT_TWO(0.00)[2]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; DKIM_TRACE(0.00)[suse.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,suse.com:dkim,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,epam.com:email] X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-purgate-ID: tlsNG-c201ff/1790860819-F70B22A1-A1F9DA78/35/110847 X-purgate-type: clean X-purgate-size: 9093 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------lbgGJ35cy8TT8LthX0IOxenk Content-Type: multipart/mixed; boundary="------------STjRnUG2ZGXT4uKr5LB09e9V"; protected-headers="v1" From: Juergen Gross To: Ruslan Ruslichenko , xen-devel@lists.xenproject.org Cc: dfaggioli@suse.com, gwd@xenproject.org, Ruslan_Ruslichenko@epam.com, Jan Beulich , Mykyta Poturai Message-ID: <873855f4-5ba2-4254-a315-d29822f64447@suse.com> Subject: Re: [PATCH v2] xen/sched: fix scheduler callback verification on init References: <20260925213022.799625-1-ruslichenko.r@gmail.com> In-Reply-To: <20260925213022.799625-1-ruslichenko.r@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= --------------STjRnUG2ZGXT4uKr5LB09e9V Content-Type: multipart/mixed; boundary="------------3PQFN2GMY50fLsjg2ij7b03q" --------------3PQFN2GMY50fLsjg2ij7b03q Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjUuMDkuMjYgMjM6MzAsIFJ1c2xhbiBSdXNsaWNoZW5rbyB3cm90ZToNCj4gRnJvbTog UnVzbGFuIFJ1c2xpY2hlbmtvIDxSdXNsYW5fUnVzbGljaGVua29AZXBhbS5jb20+DQo+IA0K PiBEdXJpbmcgY29yZSBzY2hlZHVsZXIgaW5pdGlhbGl6YXRpb24sIGVhY2ggcmVnaXN0ZXJl ZCBzY2hlZHVsZXINCj4gaXMgc2FuaXR5IHRlc3RlZCBpbiB0d28gc3RlcHM6DQo+IA0KPiAt IGl0IG11c3QgcHJvdmlkZSByZXF1aXJlZCBjYWxsYmFja3MgKGUuZy4gaW5pdCwgZG9fc2No ZWR1bGUpLg0KPiAtIGlmIGdsb2JhbF9pbml0IGNhbGxiYWNrIGlzIHByZXNlbnQsIGl0IG11 c3Qgc3VjY2VlZC4NCj4gDQo+IElmIGFueSBvZiB0aGUgc3RlcHMgZmFpbCwgc2NoZWR1bGVy IGVudHJ5IGlzIGNsZWFyZWQgaW4gZ2xvYmFsDQo+ICdzY2hlZHVsZXJzJyBhcnJheS4NCj4g DQo+IEhvd2V2ZXIsIGluIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uLCBpZiB2ZXJpZmlj YXRpb24gZmFpbHMgZHVyaW5nDQo+IHRoZSBmaXJzdCBzdGVwLCB0aGUgc2NoZWR1bGVyIGVu dHJ5IGlzIGNsZWFyZWQgYnV0IHZlcmlmaWNhdGlvbg0KPiBzZXF1ZW5jZSBpcyBub3QgaW50 ZXJydXB0ZWQuIFRoaXMgbGVhZCB0byBOVUxMIHBvaW50ZXIgZGVyZWZlcmVuY2UNCj4gd2hl biBzdWJzZXF1ZW50IHJlcXVpcmVkIGNhbGxiYWNrcyB2ZXJpZmllZCwgYW5kIHBvc3NpYmxl IGR1cmluZw0KPiB0aGUgc2Vjb25kIHN0ZXAuDQo+IA0KPiBUaGUgcGF0Y2ggZml4ZXMgdGhl IGNyYXNoZXMgYnkgc2tpcHBpbmcgY29uc2VxdWVudCBjaGVja3MgaWYgb25lIG9mDQo+IHRo ZSByZXF1aXJlZCBjYWxsYmFja3MgYXJlIG5vdCBwcmVzZW50IGZvciB0aGUgc2NoZWR1bGVy Lg0KPiANCj4gRml4ZXM6IGVjMjViM2MwMjYxYyAoInhlbi9zY2hlZDogb25seSBhbGxvdyBz Y2hlZHVsZXJzIHdpdGggYWxsIG1hbmRhdG9yeSBmdW5jdGlvbnMgYXZhaWxhYmxlIikNCj4g U2lnbmVkLW9mZi1ieTogUnVzbGFuIFJ1c2xpY2hlbmtvIDxSdXNsYW5fUnVzbGljaGVua29A ZXBhbS5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5j b20+DQoNCg0KSnVlcmdlbg0K --------------3PQFN2GMY50fLsjg2ij7b03q 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----- --------------3PQFN2GMY50fLsjg2ij7b03q-- --------------STjRnUG2ZGXT4uKr5LB09e9V-- --------------lbgGJ35cy8TT8LthX0IOxenk 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/Ey8FAmq+XgkFAwAAAAAACgkQsN6d1ii/Ey8v pAf/QPs6PQKKjEGTZ97uhtRpyZSSKlrw4tM/y4Sk8whjVmwS325OxN7cvs403Lh9ECSHEUYWdoAB 92MEs8wPWSF5f+YikzS0lXcYICi9DvfKOXjDQxQAh+Kmr97xWrEEbGK2D8xn+tjJQcFf12m+7aU4 Qar1vnrsD5jbzfHV0G8OxW6QckKDpIgFprXvmjuakQF/IGqbTF9mNgMLz+d/LOM4H8THTj7WUEUk KZS0a/PGC+owBXdPXPyc7nI0gf/ER0VYWUob1bT6Iz/k/5507h2xaqd3MkdMg9kssinQXqJigQXb H4/0fL2T/DbjtbTJCzOBp9lwxswIdA2JZHmPVUQjAg== =ESc4 -----END PGP SIGNATURE----- --------------lbgGJ35cy8TT8LthX0IOxenk-- From xen-devel-bounces@lists.xenproject.org Thu Oct 01 13:22:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 13:22:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438351.1657215 (Exim 4.92) (envelope-from ) id 1xCGjc-0002f9-IK; Thu, 01 Oct 2026 13:22:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438351.1657215; Thu, 01 Oct 2026 13:22: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 1xCGjc-0002f2-Eb; Thu, 01 Oct 2026 13:22:04 +0000 Received: by outflank-mailman (input) for mailman id 1438351; Thu, 01 Oct 2026 13:22:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCGjb-0002eu-A5 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:22:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCGja-00FwAi-03 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 15:22:02 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe5e79-bab6-0a2a0a5309dd-0a2a450ca28e-6 for ; Thu, 01 Oct 2026 15:22:01 +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 6abe5e79-f479-0a2a450c0019-c387df82c37a-3 for ; Thu, 01 Oct 2026 15:22:01 +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 1699121E3E; Thu, 1 Oct 2026 13:21:53 +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 BCA07134B3; Thu, 1 Oct 2026 13:21:52 +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 5JqMJHBevmq0KQAAD6G6ig (envelope-from ); Thu, 01 Oct 2026 13:21: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=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=1790860917; 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=wvvEWp0wzAHT7rH61Wwn2W06YZIqTHZICq2fnDAh5tk=; b=SKtadyPDMIG0hOL3KH5csM75E4r5t+APHOQ4yh//+jtcZgn9tqJVyF51/+szCT10rK+mz0 VgA/+24Rw4EPISZH1J8CtNM/R2zc8eA6XTKfQmhmDpdtl3dDMji35QxxRX6Xdn8UDgjQ7Z pgkCBt+INvNJVXSWiLsv4xBgAHnaY/Y= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790860913; 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=wvvEWp0wzAHT7rH61Wwn2W06YZIqTHZICq2fnDAh5tk=; b=fddfWRGqnsgCqb4G9KXJJTs7JbRr08t4+GElu2JXghTElK2RUxzt4mDr9uQrv+Qdk7DSPg zxaCBHWECfuEbo6qvnyBPgEA2ZKN5U77Wc6GrKv9JFdJunAd+EMkLzm01YUkI5FXrNTCZR qjoEN2Y0QKCqxn/BYvJNSPC2muixEt8= Message-ID: Date: Thu, 1 Oct 2026 15:21:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] xen/credit2: let the tickled pCPU pick up the unit it was tickled for To: Jiaqing Zhao , xen-devel@lists.xenproject.org Cc: Dario Faggioli , George Dunlap , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260930175747.274967-1-Zhao.Jiaqing@amd.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: <20260930175747.274967-1-Zhao.Jiaqing@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Hz02mGXsVV7KTIAcdNao9MFg" X-Spamd-Result: default: False [-5.14 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-0.94)[-0.938]; 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)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; 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]; HAS_ATTACHMENT(0.00)[] X-Spam-Score: -5.14 X-Spam-Level: X-Spam-Flag: NO X-purgate-ID: tlsNG-d25034/1790860921-034D7A5B-9818FF2F/35/110847 X-purgate-type: clean X-purgate-size: 7254 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Hz02mGXsVV7KTIAcdNao9MFg Content-Type: multipart/mixed; boundary="------------w0kP0ElnIMMcDWvn7TeeIujJ"; protected-headers="v1" From: Juergen Gross To: Jiaqing Zhao , xen-devel@lists.xenproject.org Cc: Dario Faggioli , George Dunlap , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: Subject: Re: [XEN PATCH v2] xen/credit2: let the tickled pCPU pick up the unit it was tickled for References: <20260930175747.274967-1-Zhao.Jiaqing@amd.com> In-Reply-To: <20260930175747.274967-1-Zhao.Jiaqing@amd.com> --------------w0kP0ElnIMMcDWvn7TeeIujJ Content-Type: multipart/mixed; boundary="------------KVJWDLG7Wl8MrKVrG6r9xeky" --------------KVJWDLG7Wl8MrKVrG6r9xeky Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMzAuMDkuMjYgMTk6NTcsIEppYXFpbmcgWmhhbyB3cm90ZToNCj4gcnVucV90aWNrbGUo KSBwaWNrcyBhbiBpZGxlIHBDUFUgd2l0aG91dCB0YWtpbmcgQ1NDSEVEMl9NSUdSQVRFX1JF U0lTVA0KPiBpbnRvIGFjY291bnQsIGJ1dCBydW5xX2NhbmRpZGF0ZSgpIG9uIHRoYXQgcENQ VSBzdGlsbCBhcHBsaWVzIGl0LiBXaXRoDQo+IHRoZSB1bml0J3MgY3JlZGl0IHdpdGhpbiBD U0NIRUQyX01JR1JBVEVfUkVTSVNUIG9mIENTQ0hFRDJfQ1JFRElUX01JTiwNCj4gdGhlIHRp Y2tsZWQgcENQVSBkZWNsaW5lcyB0aGUgdW5pdCBiZWNhdXNlIGl0IGlzIG5vdCBpdHMgbWFz dGVyLCB3aGlsZQ0KPiB0aGUgbWFzdGVyIGhhcyBhbHJlYWR5IHNraXBwZWQgaXQgYXMgZGVm ZXJyZWQgdG8gdGhlIHRpY2tsZWQgcENQVS4gQm90aA0KPiBnbyBpZGxlIGFuZCB0aGUgdW5p dCBzdGF5cyBydW5uYWJsZSBvbiB0aGUgcnVucXVldWUgd2l0aCBub2JvZHkgdG8gcnVuDQo+ IGl0Lg0KPiANCj4gU2VlbiBhcyBhIHBlcm1hbmVudCBQVkggZG9tMCBzdGFsbCB1bmRlciBu ZXN0ZWQgdmlydHVhbGl6YXRpb24sIHdoZXJlDQo+IGRvbTAgb3ZlcnJ1bnMgaXRzIHNsaWNl IGZhciBlbm91Z2ggdG8gYmUgY2xhbXBlZCBhdCBDU0NIRUQyX0NSRURJVF9NSU4uDQo+IA0K PiBEb24ndCByZXNpc3QgbWlncmF0aW9uIHRvIHRoZSBwQ1BVIHRoYXQgd2FzIHRpY2tsZWQg Zm9yIHRoZSB1bml0Lg0KPiANCj4gRml4ZXM6IDA2OWNmMzlmYjE3MSAoInhlbjogY3JlZGl0 MjogbWFrZSB0aWNrbGluZyBtb3JlIGRldGVybWluaXN0aWMiKQ0KPiBTaWduZWQtb2ZmLWJ5 OiBKaWFxaW5nIFpoYW8gPFpoYW8uSmlhcWluZ0BhbWQuY29tPg0KPiBSZXZpZXdlZC1ieTog R2VvcmdlIER1bmxhcCA8Z3dkQHhlbnByb2plY3Qub3JnPg0KDQpSZXZpZXdlZC1ieTogSnVl cmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg== --------------KVJWDLG7Wl8MrKVrG6r9xeky 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----- --------------KVJWDLG7Wl8MrKVrG6r9xeky-- --------------w0kP0ElnIMMcDWvn7TeeIujJ-- --------------Hz02mGXsVV7KTIAcdNao9MFg 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/Ey8FAmq+XnAFAwAAAAAACgkQsN6d1ii/Ey9Q vggAm3amya1lG71koqR4bXPsRkw/8l/siNGk2kyAYbxAnNdVncg2CR8w980tdddy2wca1qsAFfXW XEmqLzzbcizGk9DuOuz4Ekadn5IvhXp/Vzf59bElJSVXFiG3gWC9ECP6A9kv+8fXuT7joW5B0r93 D6FA+aOF+d+oW6EdMaOdqJBkaUGdF2lkYVsc81RDu5iYjV8zCgZ4cBBiMfxX3KrgxPMV2aL92Akh HYdf5pjdS0XHuakvElzsAbsq7LiA8DGVapodbcxg9EAjHGtOM74OYwFLX2lGzp2V8cd228UoV3X4 7dRXka4sjkVrD8I8fDTtQX5jANiPnY+JmKo1uhliEg== =SCG0 -----END PGP SIGNATURE----- --------------Hz02mGXsVV7KTIAcdNao9MFg-- From xen-devel-bounces@lists.xenproject.org Thu Oct 01 13:35:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 13:35:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438365.1657224 (Exim 4.92) (envelope-from ) id 1xCGwe-0004Uh-LD; Thu, 01 Oct 2026 13:35:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438365.1657224; Thu, 01 Oct 2026 13: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 1xCGwe-0004UW-HH; Thu, 01 Oct 2026 13:35:32 +0000 Received: by outflank-mailman (input) for mailman id 1438365; Thu, 01 Oct 2026 13:35:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCGwd-0004UQ-31 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:35:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCGwc-00FzYm-G0 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 15:35:30 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe61a0-8faa-0a2a0a5109dd-0a2a450c93f0-6 for ; Thu, 01 Oct 2026 15:35:30 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe61a1-f479-0a2a450c0019-a237832fc208-3 for ; Thu, 01 Oct 2026 15:35:29 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 9980E4EE00D0; Thu, 1 Oct 2026 15:35: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; 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=1790861729; b=oBIhli+vQv07pXOwc11LZxAsDidCojCCSpg9deL0HIRCQQtnVsHM0LTwdHNxmwwS2jhw vy9iw/1aojmGGlxkHEb0JI3gzjXfvXa6VDQCStkaQ3CwUcI497gQXY6XX/Dz/PV3I/gqz 8n4Ry111rDF1LH63R0H3PDNgPbvLe/QLiwsvAqua6vfpGRSllTLBAECbPvTapeZQm3dC8 jlel1GXC6l4Xb5g2T4bIeJTDt/ZR7n/AuyIYdkUSri8k5XkdT2e8JLt0kFGmhSpRbzpQB 4D8lyEqr+euUTurPfyKh9x9pYEgnasJtUr4yGKLVfvMFc1Ai6LFakOUDghbJwdbbtnMKA uLtcGWX6OLy6zaQ2ElVIh78Fxuh/uWQ0qqzrbiDvFrL0UjOggxKOOc8DY4wOd9EpwUo2u ekZeXdi5q+EEo78aa4XFA/yHwDAZMIQxBElGxcrW05G1I5E15QCRoAN68qAhgvvKuWdSJ oAEnhIGBPDEsLjW+VQqmVDpIQqitjeQkBbEH1axTz9X9bS1qeGDZx5aU4WiCO7Fu2CWar my3JpAdpM6jqwGOqz2smH0KPDWziSx6HQSMmmJcAlkQ7mCUgi0BJbwtyhKVuqYjOIzOBN hSMH6tM/h8znHXBCs9PBNA2OWri3LU2Mi2QbHJIBd5dsOXc8+fs9Ou0It8wmiJU= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1790861729; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=PsgLv0+JVFkZZR//5DOG/cSKwYlJbO9mVstpnbJOOns=; b=n4m/SA5w/S0TBm36bPuWQuSg+32KCA0E2OaGjPPgvE6SVgq1dGjGX4aBTYPpFhAwmM// DPJZL/6J0T1TdZzoOxGCixYkPNeIHHkOQow1n9VmFqRCWn0ZqqRTDEsbITokAB9C8BWUa UuWsrgpF7QFqSqdc+so5pvE1U2cCXoBBiu1QkLu8nHTIldZNGb8/UnvAq9Z3Erb6RkJWJ f8sqMeL+6t3lhzNXEckY5LhQFE+jY1XQ27ylU0tQBM5kTh6AalCMPP1Z+AIemTdEYwppk LmYs1sBokEO6vKo+Ruohdgxy4m31euRM7Zb+VvFajew6BtpqyDy/wOZZzMzkO4y/Bzh4z t98oSCfhIm0ddfxY+l/14E2Yoo4ANhT1KS6FHIkY+5FzwBUnJcHkLomLiN4rJ5VOyC2U0 lHNLDJRiH+xfLlsDsO1tyEo6OcLVbauBio4Spj4vZbc0YCriZ/iiDeeis5jQBAcC8U0sD jUoBkIL/PeXLNp/PJU3nrE6kwolLDKvYkTiIszcibunkZ6ZlBTe8WttABgEukJRe4lQHo JOT/zmPofM9ZL68XgyytTKaXDCMTi77xNI6/HD2gjg6UPu1WS2p5FQlvKnZUaxhKvADaF MmdSmGYn7Ze6G8OgPbhNvii888HRwHmrpDh6eA292dIHA0DdNUXTT8od5a011dQ= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Thu, 01 Oct 2026 15:35:28 +0200 From: Nicola Vetrini To: Andrew Cooper Cc: Jan Beulich , Dmytro Prokopchuk1 , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8 In-Reply-To: <3cb25b4c-6470-44a4-bc46-55776317ea67@citrix.com> References: <4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro_prokopchuk1@epam.com> <0a286fe9-2133-4f28-8fab-59f4e51d1484@suse.com> <446354d93ae04a07b86d7293705d7e46@bugseng.com> <0373fcc0-5bc9-4140-a2c9-52a31c7e42b5@suse.com> <2a8557d7ba88e95ec75148ff180ae0a0@bugseng.com> <3cb25b4c-6470-44a4-bc46-55776317ea67@citrix.com> Message-ID: 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-d25034/1790861729-01AC4A5B-9EC37A87/0/0 X-purgate-type: clean X-purgate-size: 1073 On 2026-10-01 15:16, Andrew Cooper wrote: > On 01/10/2026 1:43 pm, Jan Beulich wrote: >> On 01.10.2026 14:39, Andrew Cooper wrote: >>> We want _Generic() for const-correctness reasons only.  (And possibly >>> API transition work - this has mixed results but can substantially >>> reduce churn in a series if done well). >>> >>> This depends on moving to C11, which we need to at some point anyway >>> even if weren't for _Generic(). >> Why is this? Can't we use _Generic() as a compiler extension, i.e. >> without >> fully going to C11? > > AIUI, the parsing rules had to change in C11 to support _Generic()'s > syntax, and IIRC Eclair can't parse it without specifying C11 or later. > That's not true, ECLAIR copes just fine with _Generic regardless of the -std: 0|$ cat p.c void f(void) { int x; _Generic(x, int: 0, unsigned: 1); } nicola@nico:~ 0|$ eclair_env -- gcc -std=c99 -c p.c -- 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 Oct 01 13:54:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 13:54:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438376.1657231 (Exim 4.92) (envelope-from ) id 1xCHEa-0007Jq-1F; Thu, 01 Oct 2026 13:54:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438376.1657231; Thu, 01 Oct 2026 13: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 1xCHEZ-0007Jj-Ui; Thu, 01 Oct 2026 13:54:03 +0000 Received: by outflank-mailman (input) for mailman id 1438376; Thu, 01 Oct 2026 13:54:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCHEY-0007Jd-Vd for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 13:54:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCHEX-00Ej1T-Vp for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 15:54:01 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe65f4-2eae-0a2a0a5409dd-0a2a4508ea10-14 for ; Thu, 01 Oct 2026 15:54:01 +0200 Received: from [74.125.228.171] (helo=mail-ej2-f43.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe65f9-f659-0a2a45080019-4a7de4aba150-3 for ; Thu, 01 Oct 2026 15:54:01 +0200 Received: by mail-ej2-f43.google.com with SMTP id a640c23a62f3a-c2a8b9acbc6so1010600066b.0 for ; Thu, 01 Oct 2026 06:54:01 -0700 (PDT) Received: from ?IPV6:2a02:a03f:63ab:dc01:1291:d1ff:fe92:3b5a? ([2a02:a03f:63ab:dc01:1291:d1ff:fe92:3b5a]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2e31a3e50dsm167794166b.8.2026.10.01.06.54.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 06:54: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=mind.be header.i="@mind.be" 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=mind.be; s=google; t=1790862841; x=1791467641; 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=S4MbgcEsjubIC2iCQCMddW6AjL4DRlCofl7UhRJBcPQ=; b=QG9USQu5LxWpoXHU6tAdiH8Y02FTvADcFjwQWSlUnzmJoukqWdnfU2to8zD/bqqNev arvElSGgf1V1geJaCxYP66PSvGPgybkVyF4Zlya0Pn7d83BVCHbIfodWXOWRd5lDA6JL etK6DWfpSJ5MQYE3Z7UE1Y1a5/fynr1X+f4myw74lFcTLlx5eod1m54Qlv8kwyIPOxvw lTEleroVWAbdhwrfKBV1HHm+wcSmiE6mUqkEpWP+YQONZE3AOfStig9Epnpq4qhAEM/k /0ySO1jaGzYLML7YcSIBJV7aBmHXHgfb8wXkm+hWpxbhuVLYfe9NXss9mNKkgHhDYCBR VI5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790862841; x=1791467641; 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=S4MbgcEsjubIC2iCQCMddW6AjL4DRlCofl7UhRJBcPQ=; b=InWMrlEJOLlvh4NrvV1PakKHfqUt4MGkfR7HirIjkwWd3gknwrC8/o23DmQVX/aV2R D2F8rnCGLkqbxC+QMOX12DqlVDUGal6uKr9Ny3vg1zOXn/BY8amn9ToGBQ0zY5mp5+gm elGJN81fbL5c+/IQzNCzjNcQaAY7w1KISul4ykd1tVll2xfipvTE4MVBSQ/3KCBpJmcP Vb1koG9Wq689Vr+VAPw3xRt3lYqZQEk9YlVgUyQOpLRrcIGTQVff5+tTyObl0AV1yjn6 oCS0MUOWCdM541OEARuKHojwE3OKkUA1jbk9VhpRvctRJQpxP7ZnoimtlMnQq1MUrcZr 9HxA== X-Forwarded-Encrypted: i=1; AKwUvBy6x5f7VgoNDJHXU6zSkxy8uaTCkvLM/Syc8IP9kdZi5/IsOIoep+FTQxEmuC/2xi/mGdt6m8RIip8=@lists.xenproject.org X-Gm-Message-State: AFq9FYJE7FS49fHEPyi4tdbeBxiOxW7//yq8uFE31ZDAafCajiEGtXWx ZU5dhbr9L/8J/EePFSLBo9YygPvLlzK+CHre0YQPvmDBh1GFfMoqWQEkJ/ED8azAXgIqLxorJmn RAvYr X-Gm-Gg: AYBFou2o2IJfUH0x5pVnxjJeJ4RC8iZvF9LKBxCtZ4v+j268f2h4YVOzgUUb2TMPUky i6IUIUWUXUNJYdD868uc38+tKH4KhJnRgT2xTjfJMJKnNQ2wxRIX2IeLbTA8/SuxIpub3AHP5dF vcJ2NnrQPl9aexaNbuvSJhlj+GmbDBjwQ61AVi8N34gpt0dGHD0EuQ5yH5lG3w/iq2C2qCwY0D1 OseNxkBiCtN940TxDmIqiHosJ9bRRxeNVaZTQmlEWVhqu+nrhhJqgTtcUL6JGGwy6CdHQMjnZoi xHeaDCBjwYICUYjAutx23eWLAvZ4Nhl2p9cX9PHKOMwxH25Jsl6rrBzZSr1mMw20NUymJw/Fw1M WZlqWfubOhW+ytfWLsFEym8JjG/X9b+MNcj0J9asy6ZBWofiHvJXSfLmg+W7psSIfo5i4jtKe8m ul65P2wXkp6O8eWa0K6GcTwDaujqQWAWPg4W3rLxtKDVvS7O0fOd1lium2hsaGXglI9y/d0CN2j yfMmyA3QVD4IzL0TwDP4VWhcWxom+L96odVIc5MxkmhtTJMS/Ayqnk4AA== X-Received: by 2002:a17:907:e1c9:20b0:c2e:378c:8cee with SMTP id a640c23a62f3a-c2e378cadf5mr151820966b.34.1790862841251; Thu, 01 Oct 2026 06:54:01 -0700 (PDT) Message-ID: Date: Thu, 1 Oct 2026 15:54:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH test-artifacts] Build minimal images with Buildroot To: Andrew Cooper , xen-devel@lists.xenproject.org References: <20261001115226.471814-1-titouan.christophe@mind.be> <3b206b17-d1e5-4c63-9e75-1e10c68bf226@citrix.com> Content-Language: en-US From: Titouan Christophe In-Reply-To: <3b206b17-d1e5-4c63-9e75-1e10c68bf226@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790862841-DF6D687B-DFF4763A/0/0 X-purgate-type: clean X-purgate-size: 3996 On 1/10/26 14:32, Andrew Cooper wrote: > On 01/10/2026 12:52 pm, Titouan Christophe wrote: >> Add a way to build minimal Xen + Linux dom0 images, and their corresponding >> cross-compilation toolchains with Buildroot [1]. This effectively provides >> a consistent cross-architecture development environment. >> >> Buildroot is a project that makes it easy to build embedded system images, >> including Linux, Xen or bootloaders. Leverage that build system to build >> minimal images for use in the CI environment of Xen sub-projects, namely >> Unikraft. >> >> This approach is based on a Buildroot External tree [2] which currently only >> provides 2 target defconfigs (arm64 and x86_64, both running on qemu). >> It uses a recent development version of Buildroot that integrates changes >> to build Xen on x86_64 [3], on its latest official version 4.22.0 [4]. >> It also includes the latest kernel (linux-7.2.7 at the time of writing). >> >> As a byproduct, aside xen+kernel+rootfs, we also get a cross-compilation >> toolchain (that runs on x86_64 hosts). This makes it easy to cross-compile >> domUs for arm64, and it alleviates dynamic libraries mismatches when >> adding userspace programs to the dom0 Linux image. As an example, one such >> problem: Alpine linux is based on musl while your regular development >> computer is probably based on glibc, which causes issues if you are >> recompiling `xl` and try to use it in the Alpine image. >> >> [1] https://buildroot.org/ >> [2] https://buildroot.org/downloads/manual/manual.html#outside-br-custom >> [3] https://gitlab.com/buildroot.org/buildroot/-/commit/0bf8b2ecee6b1b41746e8863b57c2c5ba3a623b1 >> [4] https://gitlab.com/buildroot.org/buildroot/-/commit/a962be2eea146e06661712159698bc7cbf3305f2 >> >> This work is derived from this original series: >> https://gitlab.com/xen-project/fusa/unikraft/-/merge_requests/1 >> >> Signed-off-by: Titouan Christophe > Thankyou for your submission. Hi Andrew, and thank you for having looked so quickly into this patch. > > How are you intending to use this image?  There's no consumer shown, so > it's hard to judge the patch. The goal is to obtain a `binaries` directory containing xen, linux and its rootfs; as well as the corresponding cross-compilation toolchain (either additional linux applications, or "bare" domUs to run with Xen). Concretely, my next step would be to use that in Unikraft's CI in the following manner: 1. Download the latest binaries from test-artifacts (that should provide the latest Xen and a suitable linux) 2. Cross-compile a Unikraft application 3. Launch it on Xen, and assert expected output (similarly to the smoke tests in https://gitlab.com/xen-project/xen/-/tree/staging/automation/scripts) Therefore, Xen serves as a base platform for the above, and it feels like a stretch to have to recompile it from scratch in Unikraft's CI. Perhaps there are other projects that could benefit from this ? As far as I understand, all Xen tests are currently run on their native architecture (ie. arm64 runs on arm64 hosts etc...), and I had some trouble adding programs to the alpine images due to dynamic libraries mismatches (musl vs. glibc for example). > One thing I see is that it intentionally embeds a fixed kernel and > (commented but not actually added yet) Xen, and I'm not sure that's a > route we want to go down. Nit: Xen IS actually included, not sure to which commented section you are referring ? > > As for compiling the binary somewhere and copying it to a different > environment, we have build containers for that, and I don't see how > using buildroot changes the problem. As you might guess, I'm quite new to the Xen Project :) Are these "build containers" the ones obtained in the test-artifacts repository ? If not, where are they coming from, and how are they created ? > > ~Andrew Kind regards, Titouan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 14:05:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 14:05:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438388.1657241 (Exim 4.92) (envelope-from ) id 1xCHQ0-0000ld-0l; Thu, 01 Oct 2026 14:05:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438388.1657241; Thu, 01 Oct 2026 14:05: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 1xCHPz-0000lW-U5; Thu, 01 Oct 2026 14:05:51 +0000 Received: by outflank-mailman (input) for mailman id 1438388; Thu, 01 Oct 2026 14:05:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCHPy-0000lQ-LU for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 14:05:50 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCHPt-009SA7-1P; Thu, 01 Oct 2026 14:05: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 1xCHPt-003ih4-18; Thu, 01 Oct 2026 14:05: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=4wW+sqw3Z6RB+R5HcbIudEgrjB3VkTT7fJMK6tIEZtk=; b=hkaQSbQ/kJNQ/QJPBdGhbV4iFR hfSgLZXbKIE5MudWQw5lwC6iO3PeoYmRtJmu2Xgj4RnwYX1V3BJJqSDTNJeAk9PBaT90G4MMPnUhZ kRBq3B22qq1hELZJqQ424+F0056/vlS1wR7ZnR6S0sw5HFmpg6rimUkZFVN+tAJIqek0=; Date: Thu, 1 Oct 2026 16:05:37 +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] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests Message-ID: References: <20261001091921.94138-1-roger@xenproject.org> <5ff32e79-76c4-4f05-8290-14c248a79afb@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5ff32e79-76c4-4f05-8290-14c248a79afb@suse.com> On Thu, Oct 01, 2026 at 01:05:39PM +0200, Jan Beulich wrote: > On 01.10.2026 11:19, Roger Pau Monne wrote: > > XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit > > its setting in XENVER_get_features to the is_pv_domain() guarded section, > > with the rest of the PV specific features. > > > > No functional change intended. > > > > Signed-off-by: Roger Pau Monné > > --- > > Changes since v1: > > - Just move the conditional but don't merge it. > > And still no CONFIG_PV32 dependency? Andrew specifically asked for this form, or at least that was my understanding. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 01 14:28:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 14:28:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438411.1657249 (Exim 4.92) (envelope-from ) id 1xCHla-0003vA-Of; Thu, 01 Oct 2026 14:28:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438411.1657249; Thu, 01 Oct 2026 14:28: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 1xCHla-0003v3-M1; Thu, 01 Oct 2026 14:28:10 +0000 Received: by outflank-mailman (input) for mailman id 1438411; Thu, 01 Oct 2026 14:28:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCHlZ-0003uw-I3 for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 14:28:09 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCHlY-009ShJ-24; Thu, 01 Oct 2026 14:28: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 1xCHlY-003pfC-1q; Thu, 01 Oct 2026 14: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" 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=1QxjtvUklegWRfBANHigZ/YREbPg51Bp8Po4VD0WCg0=; b=WbTKhTcywiEDiH2oNhMrI/XtQ1 Gr0QQQDY1OYw+Y5Otd66+i+7pO7SyDck3684YanG6x7CL4oOLLk0/5lmnsQisLIswvu5J6PLGcR8W uI/zEPHR41Yof3WhsaSG9n9kpeFH7KKgyN0Y8Pqsh0a728wc2759gcchPeQxpMHbzwgo=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Grygorii Strashko , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/domain: restrict context switch hooks for the idle domain Date: Thu, 1 Oct 2026 16:27:57 +0200 Message-ID: <20261001142757.98255-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 From: Grygorii Strashko The arch_init_idle_domain() initializes struct arch_csw idle_csw as: static const struct arch_csw idle_csw = { .from = paravirt_ctxt_switch_from, .to = paravirt_ctxt_switch_to, .tail = idle_loop, }; but only place where d->arch.ctxt_switch->{to,from}() are used is __context_switch() where they are both guarded by !is_idle_domain(pd) which makes the callbacks in idle_csw unreachable. Drop to/from() callbacks initialization in idle_csw. Signed-off-by: Grygorii Strashko Signed-off-by: Roger Pau Monné --- I don't think there's a suitable Fixes candidate here. The idle domain hooks used to piggyback on the PV ones, and commit ab914e04a6272 split those out into it's own structure. At that point the to/from hooks could have been left zeroed, but that wasn't the point of that commit anyway. --- xen/arch/x86/domain.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 996b50af7a17..464ca6f39026 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) void __init arch_init_idle_domain(struct domain *d) { static const struct arch_csw idle_csw = { - .from = paravirt_ctxt_switch_from, - .to = paravirt_ctxt_switch_to, .tail = idle_loop, }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 15:05:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 15:05:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438443.1657259 (Exim 4.92) (envelope-from ) id 1xCILd-0000dB-F3; Thu, 01 Oct 2026 15:05:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438443.1657259; Thu, 01 Oct 2026 15:05: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 1xCILd-0000d4-C6; Thu, 01 Oct 2026 15:05:25 +0000 Received: by outflank-mailman (input) for mailman id 1438443; Thu, 01 Oct 2026 15:05:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCILc-0000cy-9B for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 15:05:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCILb-003IsU-4Z for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:05:23 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe76af-8faa-0a2a0a5109dd-0a2a450b9c22-14 for ; Thu, 01 Oct 2026 17:05:23 +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 6abe76b2-b7e8-0a2a450b0019-4a7de18db74c-3 for ; Thu, 01 Oct 2026 17:05:23 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e83a388f8so48951255e9.1 for ; Thu, 01 Oct 2026 08:05: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-4a01feb7198sm61663485e9.1.2026.10.01.08.05.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 08:05: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=1790867122; x=1791471922; 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=e6VyNNF/Qdyql9K0L71RGDdE6XU/KdnakNIsk0JXPh4=; b=eiJsJpgBDppyUCTbpRatK8Wq3sdIAbSXhyccf4OMbwEX+KRQjf9x7fDh3I7Zzpf4pv nsd9cVhAhRJl96pKniNC0YjnIoIajWSnfVcAuBytQEvTYpTygw4yEci9l334ZgAtlspR oJ2ZBrm7xl+ppW27Ysny6ETOsEPdatDdrTM8QH+UFdZpjyOjNalEPLfCScxngL54CCYR eGOOLboiQjlot1YsSD5l/cPSr7EkLybpCMAoA97XRj+Utu36PVwnU8lqPDw/gDBZnqs7 VXcaFHdC3ga78E3w12q/fDhuxWvqbyZ4U7YoRLzf+eXdBooJUEMMfhJc2ZXqwnQkBAX1 X5qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790867122; x=1791471922; 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=e6VyNNF/Qdyql9K0L71RGDdE6XU/KdnakNIsk0JXPh4=; b=AfdIQEjY+YdGr/B3bE+JdJIaZ93mOQf7tPjhQfRMEWu/WLYbTLl5ZlWz4YsCR5NeD1 OYnvYQBCyYW45cMeg6wuiH0lZU2OpSks4GaQQ6L25YNzff8XG30YutsXnINkXQjn76FO fGv1r9tB4vIl28rGV9nVULwKsAseYxa8FnwblFlsx0TJz44Y1Umle/iwFqQgFuILjbHL ukoIUf0ZjnxfXGgvM/CLOn+GPfp32ZKcaZ+qnMx9Qq9Ypl4LcIila9hIYExAtJ2K/oVT 64qS+zp5xF0F0r6oKX7Em/OUdchI4qrVeZJ57WKeyI9VyBbpTV954zi7O/Bwox5KEJuZ Spng== X-Forwarded-Encrypted: i=1; AKwUvBw2AN/PwwvikHPGhl3A0DsEOJgmOP4eNxiDwN9ZrQvEz2o7GoAbOc8jZ6Ei/DB9xGgrBmEwbJUngTw=@lists.xenproject.org X-Gm-Message-State: AFuF++llny5tconzWtT0vQ67PBftane1rgWbTd3ByhezPhRTKA6wMxnm 9wSywhg5jmEtjCJcTZVzjwcYHsWGFXkko5RCgLY8iznQGJb0qWQjUuQK5vyi5EL7hw== X-Gm-Gg: AYBFou1WspH9JuyWH+YKHJHPzrb6qu4wzr5fRNPr5cRmG2ibGiMWNZvoMEQkmLTfV7l 3Fiqv5Qf2O0D+6FtjBS68gkXpGNNBwKNxR07KYVO4MnsmJfT87fdTPqm+bcWHZ4pPFt/qe5eCJW tY0u1A/XZqfgrUVytzjJxiOis4Tah/+Chsak+IV64ePG/dJEp68LpM1gZCyXB8vQaIjNHpww3XS D4oXqeqL21SlXJuWrnJwrAzBs1VXr0kMxRlHDWtUFqRmxLK31Z8fz5U68tDaPuKwiMbT8BjBUAg /9A5WN6vsZmRZ/6eFaIxvOp0ZadGJnOTJVEbAR6UtYYPFscNziWjqLKby2rQU7bJItteuYXjGpQ LEHwq5VYaxj8o0r4Y5Yo5iFMzhm05AcoXRuP1LVi3cja1mt0xbXiYAPaa2XFL1UaLl8gmJzPTVN wlrCaD3Sd7ul4WcM6HTFkrksDPyUs4XDZo4wHyZc98+Z2O47S8+OaTLSB0HZFSgxfo/Btcwbjn1 2SBnnoMrFJ6NMWzAhVcU5Vndrhc3+Wl4lW4A71Kr4r5Ge528j4gqAPSoOWCGs4= X-Received: by 2002:a05:600c:1f86:b0:4a0:1ea2:10c6 with SMTP id 5b1f17b1804b1-4a01ea211bamr56662115e9.17.1790867122095; Thu, 01 Oct 2026 08:05:22 -0700 (PDT) Message-ID: <69439dc8-95a4-4de0-a158-959731dc86d9@suse.com> Date: Thu, 1 Oct 2026 17:05:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests 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: <20261001091921.94138-1-roger@xenproject.org> <5ff32e79-76c4-4f05-8290-14c248a79afb@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-42698a/1790867123-186CA9EA-7761A23F/10/78276251493 X-purgate-type: spam X-purgate-size: 757 On 01.10.2026 16:05, Roger Pau Monné wrote: > On Thu, Oct 01, 2026 at 01:05:39PM +0200, Jan Beulich wrote: >> On 01.10.2026 11:19, Roger Pau Monne wrote: >>> XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit >>> its setting in XENVER_get_features to the is_pv_domain() guarded section, >>> with the rest of the PV specific features. >>> >>> No functional change intended. >>> >>> Signed-off-by: Roger Pau Monné >>> --- >>> Changes since v1: >>> - Just move the conditional but don't merge it. >> >> And still no CONFIG_PV32 dependency? > > Andrew specifically asked for this form, or at least that was my > understanding. Well, Misra-wise you've added unreachable code this way. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 01 15:17:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 15:17:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438456.1657268 (Exim 4.92) (envelope-from ) id 1xCIX4-0002MW-F1; Thu, 01 Oct 2026 15:17:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438456.1657268; Thu, 01 Oct 2026 15: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 1xCIX4-0002MP-Bd; Thu, 01 Oct 2026 15:17:14 +0000 Received: by outflank-mailman (input) for mailman id 1438456; Thu, 01 Oct 2026 15:17:13 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCIX3-0002MJ-1v for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 15:17:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCIX2-009ii8-5p for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:17:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe7969-e002-0a2a0a5209dd-0a2a4503ee2c-48 for ; Thu, 01 Oct 2026 17:17:11 +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 6abe7977-fae8-0a2a45030019-c387df82e10a-3 for ; Thu, 01 Oct 2026 17:17:11 +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 3AE7821DEC; Thu, 1 Oct 2026 15:17:03 +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 DA35813B80; Thu, 1 Oct 2026 15:17:02 +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 AJEIKW55vmrUJgAAD6G6ig (envelope-from ); Thu, 01 Oct 2026 15:17: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=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=1790867827; 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=ofZkDXN9t2YIbQZjUrgnQ8P142gagd8IQKeFJMqNFiY=; b=k7RA4NIJk/mgVoVHz2fQP/AyqTimSPli50Ao6d7eOb9zrmuQvd0FSklmgSvtpnbgPhpSmv AnV6E2WaUeZHqaaij0dUG6aTyHIhPEAR+eUMv69f2N/XZA4ZCRcb1jXkEbk43dA55IPVSF f8veC7w8RopC3grwe1LdYMtpqAIgCRA= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b="KMyiMf/d" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790867823; 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=ofZkDXN9t2YIbQZjUrgnQ8P142gagd8IQKeFJMqNFiY=; b=KMyiMf/dIgxFDO06f0tIhCjKVLTVwM7OYHPnI2WHl2yBeF6hv4VFCv2P7dJJh6jxIfDnHt pyeNcQaha7ta2a9ifQaEk49ydHrPN5Bt7kyDu/U1PKA9YJAS1XArBzT6h1CLJZXRRu7V66 /sh61+xGlK1LAjtOOjBJN8UiY8b27G0= Message-ID: Date: Thu, 1 Oct 2026 17:17:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Grygorii Strashko , Jan Beulich , Andrew Cooper , Teddy Astie References: <20261001142757.98255-1-roger@xenproject.org> 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: <20261001142757.98255-1-roger@xenproject.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------aSJIaIKDpRDwWdjSRJht35zL" X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 3AE7821DEC X-Rspamd-Action: no action X-Spamd-Result: default: False [-6.41 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.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)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[epam.com:email,suse.com:mid,suse.com:email,suse.com:dkim,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns] X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-purgate-ID: tlsNG-33051d/1790867831-77AC44E9-25095A78/35/110847 X-purgate-type: clean X-purgate-size: 8713 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------aSJIaIKDpRDwWdjSRJht35zL Content-Type: multipart/mixed; boundary="------------zpxhBFsObi5Ugz9mUhaq01cZ"; protected-headers="v1" From: Juergen Gross To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Grygorii Strashko , Jan Beulich , Andrew Cooper , Teddy Astie Message-ID: Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain References: <20261001142757.98255-1-roger@xenproject.org> In-Reply-To: <20261001142757.98255-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= --------------zpxhBFsObi5Ugz9mUhaq01cZ Content-Type: multipart/mixed; boundary="------------5zc8FM6JHUzt8yjK0Xqn95Tm" --------------5zc8FM6JHUzt8yjK0Xqn95Tm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMTAuMjYgMTY6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gRnJvbTogR3J5 Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KPiANCj4gVGhl IGFyY2hfaW5pdF9pZGxlX2RvbWFpbigpIGluaXRpYWxpemVzIHN0cnVjdCBhcmNoX2NzdyBp ZGxlX2NzdyBhczoNCj4gDQo+ICAgICAgc3RhdGljIGNvbnN0IHN0cnVjdCBhcmNoX2NzdyBp ZGxlX2NzdyA9IHsNCj4gICAgICAgICAgLmZyb20gPSBwYXJhdmlydF9jdHh0X3N3aXRjaF9m cm9tLA0KPiAgICAgICAgICAudG8gICA9IHBhcmF2aXJ0X2N0eHRfc3dpdGNoX3RvLA0KPiAg ICAgICAgICAudGFpbCA9IGlkbGVfbG9vcCwNCj4gICAgICB9Ow0KPiANCj4gYnV0IG9ubHkg cGxhY2Ugd2hlcmUgZC0+YXJjaC5jdHh0X3N3aXRjaC0+e3RvLGZyb219KCkgYXJlIHVzZWQg aXMNCj4gX19jb250ZXh0X3N3aXRjaCgpIHdoZXJlIHRoZXkgYXJlIGJvdGggZ3VhcmRlZCBi eSAhaXNfaWRsZV9kb21haW4ocGQpDQo+IHdoaWNoIG1ha2VzIHRoZSBjYWxsYmFja3MgaW4g aWRsZV9jc3cgdW5yZWFjaGFibGUuDQo+IA0KPiBEcm9wIHRvL2Zyb20oKSBjYWxsYmFja3Mg aW5pdGlhbGl6YXRpb24gaW4gaWRsZV9jc3cuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBHcnln b3JpaSBTdHJhc2hrbyA8Z3J5Z29yaWlfc3RyYXNoa29AZXBhbS5jb20+DQo+IFNpZ25lZC1v ZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyQHhlbnByb2plY3Qub3JnPg0KDQpSZXZp ZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4N Cg== --------------5zc8FM6JHUzt8yjK0Xqn95Tm 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----- --------------5zc8FM6JHUzt8yjK0Xqn95Tm-- --------------zpxhBFsObi5Ugz9mUhaq01cZ-- --------------aSJIaIKDpRDwWdjSRJht35zL 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/Ey8FAmq+eW4FAwAAAAAACgkQsN6d1ii/Ey9M ZAf/Ziu4TI0GjgIItLHWMYV1gvZ35+UCnN0LXC7vLV0KWvogceyrymYZc4IK4+wXoEPMnqdfWcAS OTYs2sqnVsZIRaJ2MZKOoeo6b2O0B1FQ2ekRtoRztb1IIrw7diHsxvWnl3K0xVfrYXBFKH2g+GUk D8Er5KilckLeuG86p84UZ8cXXBoC9LsGvVYjMspyiB6REzc1K169a6UI21vtPOr28U897YmaNJaP hFtV+9ELutm6Avt0NAHo9BRDE1OheTfvy52+hpEDV2dF0HR4ETtM87RuPWh/QVaOnk6FUrQXRdBM QpCSL48gc6aerREhSAhZe4jzVvfhFm/Vn3JhL5RrGQ== =KOjX -----END PGP SIGNATURE----- --------------aSJIaIKDpRDwWdjSRJht35zL-- From xen-devel-bounces@lists.xenproject.org Thu Oct 01 17:23:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:23:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438550.1657277 (Exim 4.92) (envelope-from ) id 1xCKV3-0001dh-0G; Thu, 01 Oct 2026 17:23:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438550.1657277; Thu, 01 Oct 2026 17:23: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 1xCKV2-0001dZ-RZ; Thu, 01 Oct 2026 17:23:16 +0000 Received: by outflank-mailman (input) for mailman id 1438550; Thu, 01 Oct 2026 17:23:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKV2-0001dT-3S for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:23:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKV1-002dZ5-Ge for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:23:15 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe96de-e002-0a2a0a5209dd-0a2a4502b058-44 for ; Thu, 01 Oct 2026 19:23:15 +0200 Received: from [52.101.57.26] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9702-6ca4-0a2a45020019-3465391a5c87-3 for ; Thu, 01 Oct 2026 19:23:15 +0200 Received: from BN0PR04CA0067.namprd04.prod.outlook.com (2603:10b6:408:ea::12) by BN7PPF521FFE181.namprd12.prod.outlook.com (2603:10b6:40f:fc02::6d0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.27; Thu, 1 Oct 2026 17:23:09 +0000 Received: from BN3PEPF00022BD9.namprd03.prod.outlook.com (2603:10b6:408:ea:cafe::d) by BN0PR04CA0067.outlook.office365.com (2603:10b6:408:ea::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.18 via Frontend Transport; Thu, 1 Oct 2026 17:23:09 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF00022BD9.mail.protection.outlook.com (10.167.248.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Thu, 1 Oct 2026 17:23:07 +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; Thu, 1 Oct 2026 12:23:07 -0500 Received: from [192.168.19.2] (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, 1 Oct 2026 12:23:06 -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=uGxO4J4BeAP+6ahVNK0dMHKA2PSHQ78M81I0RSTAQ8MbdK4iZFrSxgYOT3JkgFAg2uP4x4ruJevMAv+yF5/yaJxUYMWyTwcZpIiiFLjPv4vlPkQ/jrwHaTJwC6xfql80v32JPrBaHdHmG/kRTLwkjfVG/rNoQUI9XXSDdw8v9sIUlROhf1mnR7XA8yvK1IEpVd6jKqvMdLxN7CCHOMvbmR7hnuJUxzcU/5mifWcCvtWBABjxVVhuFZJRhWTTdWEMPa/XFUVTH5YilbhPos0MkBkW1wSs+K2kzBYNLmeWOpPBH5oUhlBtGJP/aAuthEUvpwTOXR5Jw45otqonqxrBZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=byujvlaxq/XJAD/4iY30AUAoGZuJg1GXVhswLT+FXfs=; b=Ke+xk6A/E66d6+ev/lYcp6aR0TQC5KK+EL+Ea0LpZthe6ZsA6oG9YWRRL6N5DHhQ6+w86fg8j7sg7g2UaeM8OM2wdFQiuM5lXZaNP7uzPSBxbmsKbLC6qtpoT+9Z/VluraIUNVQO9eS18rfgK72T5Dz+x1mQ0ZuYFDbOw1WPYNCOPf0HXrSzGE5vvIWN4R6iRHtl1rMD8VV2OmofPcKa1kM8kVuq6kudWFS5SL4apRDtDJsv1C45mpM+hzhhDvhkadRDUpC2Km72URX58qMFYexnvUkKBmwWjYAM6e8LD/cJHTfgWqiksMZ6CBSUWzCGO6ZG6Y27swXZcBjPSv9dnQ== 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=byujvlaxq/XJAD/4iY30AUAoGZuJg1GXVhswLT+FXfs=; b=3GOPl/xRQC2rL1e/6zAOD1CnHr3D4jPJenSELJsv4YhqTAU+2qxIwphhnaagEK1/LbKTIXkpjUJdcNw++TSJgKNSA5A/RfUpPZuzgNuTBEuwkSTR9hwr1wDH1H7Mq9RrkmQJ+QCn3uaurUTJrK19v7dAv24I9NSDju9C5bDGulU= 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: Thu, 1 Oct 2026 13:23:01 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain To: Roger Pau Monne , CC: Grygorii Strashko , Jan Beulich , Andrew Cooper , Teddy Astie References: <20261001142757.98255-1-roger@xenproject.org> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20261001142757.98255-1-roger@xenproject.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BD9:EE_|BN7PPF521FFE181:EE_ X-MS-Office365-Filtering-Correlation-Id: 43b77616-b383-4764-7483-08df1fe0a901 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|376014|82310400026|1800799024|23010399003|6133799003|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: oN1/xVblj9X6dE5Di7+51NxrF9S2VHUZyJiYvKkxb9YYar3bjPfr7l0vZfWTwyRohzlCLWpvHfV+wloHTyzN2gHOCjV1+O6oi03aiDcqT1wpYOjvQY3OP44wURuL+y41zzpRl/FV4kWLgqYHpwzhQtpNFGZ87irylgZiayxB+ZVYOrtGDMAbWC5OP1u9CO5wh/iF7QpDKPQL7Z0GWZ9NBHtBPXRm+cRmXAQRMtSr9ob0e6B6wGLLFv8ox4pSX0Pik0MLpSygpfT8qFpO2uGMaSa45f5nLm11ogHYp11xFxaMWIyio5gmh4JPzsu30h3T6iFeChilXipFESgcDg05TRqMEzp5f7l/2VJKykL+uFq4PylKxOQPtm+ck/+j6vSp1OTsX6UzstiZnIXLlz0D0Igh7vfeY1gK+HaxKPkHS61XMF9SnOALldXrrG6SOKTdpzhZY3N0P3oiEfWmeORTD+JcBMKoEOQ1RsYd6JOnhSpn0GaadrnReGcfKeSic22FNCkMRyoUGZS5W5FgI6phfjcLYonlpU1qp+c7O7+XHIdSkzh9lf+BXLfOFulK9zutjY8sCQO3ZrIFQmye40vUTnmRTcmPPitGZEo/HDGSmzxomA0/9Qm+iLjYSuNpjZwUufmPq0VITUAc2NP2rJ2DGH6EERTCm2o/UtN47X2PLSxK2uXZqDjlsE36EHlfUHPsHYsygCTkjALStSIgtheQUA== 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)(82310400026)(1800799024)(23010399003)(6133799003)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: PVhWbEjxY+/CHd3SXxcLwt8c3Yy8uyb2M7coZ2NeVgpP7zwTat6q17QIJJZQc9HDraQwar6XEAN+2yl2wIEZYo5E4kK5K5EtIdSrsbyRn/Hz9AnSDxwtpubfFueeX9FdCUtugsjSxqccWdJ+uySyEN4ETfOANSAJWKc156OI4JcOkhnLMFWDpzJ4eqnfSvF+5O7QYEs/yn5tr7Eo6ohmXhXbxdyRmRU00MDNQW+l1OXiHurcdgw5GeknZB+ASDKYddTs2VbNO3xXnQc2MrjxMShCe52cVqSu6T3X8aya2CNIgTQlA977HLevE3WE75mtnjgu4G6Kx+zEHQCBMDeOlJX8UhzHYHELBtX4dHMjqPeTWjftU3ZHSwy86wnP8qSJ8677MqK8mt5p9qALDQqwWSmAfdeP+RadhXm9qGvrJSZZ92+4DrCqNuCbtuhkW6VO X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:23:07.8013 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 43b77616-b383-4764-7483-08df1fe0a901 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: BN3PEPF00022BD9.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF521FFE181 X-purgate-ID: tlsNG-720697/1790875395-664B62AC-DED1FB9B/0/0 X-purgate-type: clean X-purgate-size: 822 On 2026-10-01 10:27, Roger Pau Monne wrote: > From: Grygorii Strashko > > The arch_init_idle_domain() initializes struct arch_csw idle_csw as: > > static const struct arch_csw idle_csw = { > .from = paravirt_ctxt_switch_from, > .to = paravirt_ctxt_switch_to, > .tail = idle_loop, > }; > > but only place where d->arch.ctxt_switch->{to,from}() are used is > __context_switch() where they are both guarded by !is_idle_domain(pd) > which makes the callbacks in idle_csw unreachable. > > Drop to/from() callbacks initialization in idle_csw. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Roger Pau Monné Reviewed-by: Jason Andryuk Thanks, Jason From xen-devel-bounces@lists.xenproject.org Thu Oct 01 17:46:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:46:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438578.1657286 (Exim 4.92) (envelope-from ) id 1xCKrC-0004eX-Nt; Thu, 01 Oct 2026 17:46:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438578.1657286; Thu, 01 Oct 2026 17: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 1xCKrC-0004eQ-L6; Thu, 01 Oct 2026 17:46:10 +0000 Received: by outflank-mailman (input) for mailman id 1438578; Thu, 01 Oct 2026 17:46:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKrB-0004eK-IQ for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:46:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKrA-002g9X-VQ for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:46:08 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe9c33-2eae-0a2a0a5409dd-0a2a4507ddcc-34 for ; Thu, 01 Oct 2026 19:46:08 +0200 Received: from [40.107.200.26] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9c5d-b4ea-0a2a45070019-286bc81a16b3-3 for ; Thu, 01 Oct 2026 19:46:08 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV8PR03MB7518.namprd03.prod.outlook.com (2603:10b6:408:190::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 17:46:02 +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.0451.026; Thu, 1 Oct 2026 17:46: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=MH+CSoYzPrJyCfvoCgbuT0z1KY38FDEP9Cq3/BwZZR1XPVHSBp9EUuEjR33eYWGzVa1JHahL4SNSqdCSx2fnN9kwfDyrixYGXIy3WfziZceUaNZUjNd3+bI3kN7LOrQOExe8pwDih76PjHxz7aAOMMiFREIybynw3SBJ2rAVdObLnOjNl9JeForvlPOUsj3YRDYWnbph9N6WhAqASv+XMoPq7dZotgxaCEBbN20ICgdYIN6IobFD9ElCpJ3WiYheUUyUyGVUOuMHb/1urXWZD8PIbwNgviqdx6EbjxycJcqOp/JX0tuG+dBN0DSPAKFR0cNxt+r+0b4d8WcMjG8Rzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9yukoTJTvfx2/TW/Z+5HPZvKVMIqRm9iNuXR7qMg8Uk=; b=Zz5lxKZIHVIC0Zfo9eIn9kAAXY8xDgQ3omLk0dsDHjHEOXRLxe9PpLDHp8TfA+aoYnHCYjgeD6lJYcuPZwBjwfzBXnm32FzZq967MXH22DsmZdlLQlscOgN1QTOBREaypTikt6TTEn53zz3LNaaAPhswwWfTWG3FvkHvYBE41x56VeRUX7/ith+NPxVB2nZ1eDTRvnW+QekVX6KFwRq1x9AVtW6xxIv+2UUW0sZczXeyKIgN+k0NGTiTGQtzzzuX7mSfdLfYbo6AJ0QRoge2XO6sNRYPmsebMiGXFsL7npiRsqIHhm06YFGZ7WSSaydeLYWeE+Lmlw9iad862fjIwg== 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=9yukoTJTvfx2/TW/Z+5HPZvKVMIqRm9iNuXR7qMg8Uk=; b=E7y4n8//Sg1viuAHHWhjNywv8d/0KJq7OBTHvU2X6RbEBhKC1G5EdvgyKlv02dMr/ha4NEVPqQFh4ThnDPLk4+VCerKBxIuNP/7txFbLY1Wyx6M+PwxXHd1iv3s9oZYT1ySSTe4ram48vx5uXfSDBB7AbKBaIWgj5vNX0d0BUl0= Authentication-Results: mx.microsoft.com 1; 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 v3 4/6] x86: extend do_mmu_update() to support returning the old PTE value Date: Thu, 1 Oct 2026 18:47:47 +0100 Message-ID: <20261001174749.2275245-5-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261001174749.2275245-1-kevin.lampis@citrix.com> References: <20261001174749.2275245-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0095.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:191::10) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV8PR03MB7518:EE_ X-MS-Office365-Filtering-Correlation-Id: c8b8dcb9-ec96-49c3-d835-08df1fe3dbbd 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|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: c8Bj9LZOdXwBUWI+lE3BDQBJBz3pURh/KBXjgvhGXA5jSWNERVMD3iN5VPRXJ9oaputSfp86tHXquNPoV8bX/+0b2NQ+8Xklse1guqhE0ACDbHZTL3buhiXC5NB9rRjOwVKDV10yu68VoWidXCSRug4NiWWC2LiR4lT43Evdjrj1NLdoEJWJ5CwAuunHhCG94v159Rb6doLpGyCNzTugdGUAUffuEKvLp0L1lUzAGfnGAOyCqeyhWN/5a7OJvzK5pQmLNdpge9GAz3arHopxBKYED/IanFQHxlQiRidokSsL/0VaCd8Fk8debnjeRCnJ6JHd1S5htvUNTsiN82Lyyt71QQjc07NoNOSED0ydAI+sF+xGpUPqhLoU8fr+4J/3vdCDueoqwfZDPJ5ufNp1yOTi4qMG+nqhC4pFCz4Vd3Fpy1Wa9BCJWMs03x8wxbnHC3cLXe9cT83cCWb4Mff54pdxJZf/epgBWmOpie+lvugbQlHlrlLlXgq0WfkFRjLm3r6N57rMkl16YuOfTBHZnDdYS1wu4HUIxiKK/nKlyIA81XQ7RmLP/5Lxkr67EVcdNZOWJdWNfE/a11MGCtzhxZ2yFcFpJ2RA23A8+qyKk1++3dkkODyCWkioBgCsXEHRgveEf2mLPsccEqRr0lMKS3O3SIclCWwu1QBgrRN8dE4= 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)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Qp60arT+AZfbvrt/f/AZhqaJTEXFC5QEdzlZqkc4Y3yy+4+AWh7zwjCIoAMf?= =?us-ascii?Q?3+UYbAVQDyYjxYBpS0a3KBBnISROc4C9KOkldjHClr/afXxtk0gJaAU0MuxH?= =?us-ascii?Q?pC7IeDeeFUk/0XSBy6owMsnVntL/KoM1EnzrxSQlB7MrZln2W827EWvImxoq?= =?us-ascii?Q?AE5uBcm6ojuuQLIpFA1WsxGxd1lubRQQ2PSARtA+LocpcMVoMsgzuX/44pFm?= =?us-ascii?Q?YzlsaakVEXsW7HvStZ+oXIAXCyOrD1r2Lmy7BvEY+XGCl+iJOxmG/J5FWH7V?= =?us-ascii?Q?hD/KItaLJdQSQG3gXHvpHzik66t4+XK+EVieGvKJFt9QNsaCaAn0XF4bgYB+?= =?us-ascii?Q?eX/THTBueO7TQhtOr18V2gQTRsqv6QncLET8JDvzHzaX5+S1O5Iumu393mNe?= =?us-ascii?Q?U/7Et9bhfPH/TtGek8+58qQWSu/CR5dYfMY7eSSTqvLOvzbzzpKjDDeqRwBR?= =?us-ascii?Q?7l9MCieDS2c2JSNtgih4tCiytl7XYQLEcITNH7dFgWNjH/89zR/tasGRrgHK?= =?us-ascii?Q?9aceRdmlVlf6X+vWdY6qvdB8vyqUJ3MqRvWT0uoZVMX+K4W9JSEjjLxqhe+n?= =?us-ascii?Q?60Nfhi0aylUgmfrP8WUH78o9y1XWSpw2E1p0HRJKE4c0METzCER5hJnvHjKU?= =?us-ascii?Q?hUhjw7nLQaAGh8GRl86eilbh2L3dgKon8PHmNNdE87/kwIezyTEhEAFQ+/Ni?= =?us-ascii?Q?Qh2arc7afUMFGgtfO+0DhhBwDeqVHt8P9cmRAGF0Y3jErRb7l2uPlR4RGodQ?= =?us-ascii?Q?6IsEUZwElCNv60ipv1GXplXLs6Dj7rSI3KUBd1bIlRa3xKNfmPPzGljcgNBg?= =?us-ascii?Q?mQIQS6zuNVPcQTfy8lmXyEqAXPD3KH/v+rgV9ivUu0OveVbOaDTKcOPVR3D+?= =?us-ascii?Q?cUgg+pRllUkNxoiMiPHmgcTuNAPT7j6CEbu+7/zk29Vun6OWkfzlGDstnmMf?= =?us-ascii?Q?XsIiBvL5kXgZ1U6sboczOPvBV4hMvxv//u/eOEbahkoM3vUiaRyEy9PvVen+?= =?us-ascii?Q?ZsInHBIL++t6l0I8DJvrXgcF+nfSmdWngo/zFZew+wMbwt+9XBa/Ll+fuQH2?= =?us-ascii?Q?4gbt7ahzlPk7cMAx+kUOJ+u0YUwYIkph2ACnbiNNV/Xhek84lFtI7L70VBC6?= =?us-ascii?Q?W2GcVSBxfLV3csvGxzx/NDw2/bwqscJ+u+C6b2J2wS4v9Drumpjn+dy1JKRN?= =?us-ascii?Q?/QyOCZl5kX1Rg2O4SPONVOK1kJUW06Laph1KIilkCesqrYJYv8omxIAjOZ8r?= =?us-ascii?Q?cFKgr1GU/6DBAriAuzpgYe9jWRUzx3GUf8geN1/XuUHrGgtEzqLmUmB60Qbq?= =?us-ascii?Q?xubv1Fr1tHzj3yX41KsJN/XXwJOG0af2JmtrmhF+C7oqPPQiGi3l4KccruUY?= =?us-ascii?Q?91khTpzb6rTd8bZAlLdsdpxAlkgIaz968v38zEZzDfrm2uoWMVuNNI48WBmO?= =?us-ascii?Q?NV+MgiBX1XWfqd2cViKB9esWtpitQI+zovI1OWMhBmHtmRho0mgcToMaUr3/?= =?us-ascii?Q?8ODwNyBVEV7SFonUueA8GYSPifI9CbixBip93sk1/tvxxZORuzCRPbWPrajL?= =?us-ascii?Q?p5CHDjrDk/EQ+OhvH5xG5iLhLrYiWvs0X9eLiJzOSqNR+lg5u8ji2fn2ebAY?= =?us-ascii?Q?v7SvQEq3sJRLf8QmeuCRI0pOVrGaP4cWbLWHKHUZQQxR9KP8fXIHjDhxeabA?= =?us-ascii?Q?G4Cit2OKDguuQt3oZr1DKxZn+CBM6ghxK67sXuRqAehBEy6xt/a19FrP+EVO?= =?us-ascii?Q?EHGEG4F54w=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8b8dcb9-ec96-49c3-d835-08df1fe3dbbd X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:46:01.5924 (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: 7TJGUp97vsCUyybuOUwxvF1fpbC3QIgMPtMWVPruvgE4Dq0GcPP6nHIfjFvqRVlo93j6VGlD1iZqbqMjFPG/Qg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7518 X-purgate-ID: tlsNG-ef75cf/1790876768-A4AC8AE4-64939F3E/0/0 X-purgate-type: clean X-purgate-size: 7883 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 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_l*_entry -> UPDATE_ENTRY -> paging_write_guest_entry The new MMU_PT_UPDATE_SWAP call chain looks like this do_mmu_update -> mod_l*_entry -> UPDATE_ENTRY -> paging_cmpxchg_guest_entry Signed-off-by: Kevin Lampis --- Changes in v3: - Do swap for l2, l3, l4 - Allow all values not just 0 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 --- xen/arch/x86/mm.c | 80 ++++++++++++++++++++++++++++++++++++---- xen/include/public/xen.h | 1 + 2 files changed, 74 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 535a62139cad..a2d05d6c7113 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4111,6 +4111,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; @@ -4172,10 +4173,27 @@ long do_mmu_update( update_flags = PTE_UPDATE_PRESERVE_AD; else if ( cmd == MMU_PT_UPDATE_NO_TRANSLATE ) update_flags = PTE_UPDATE_NO_TRANSLATE; + else if ( cmd == MMU_PT_UPDATE_SWAP ) + update_flags = PTE_UPDATE_SWAP; switch ( page->u.inuse.type_info & PGT_type_mask ) { case PGT_l1_page_table: + if ( cmd == MMU_PT_UPDATE_SWAP ) + { + l1_pgentry_t ol1e; + 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; @@ -4183,8 +4201,22 @@ long do_mmu_update( case PGT_l2_page_table: if ( unlikely(pg_owner != pt_owner) ) break; - rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, - update_flags, v, NULL); + if ( cmd == MMU_PT_UPDATE_SWAP ) + { + l2_pgentry_t ol2e; + rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, + update_flags, v, &ol2e); + + if ( !rc ) + { + req.val = ol2e.l2; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } + } + else + rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; break; @@ -4192,8 +4224,22 @@ long do_mmu_update( case PGT_l3_page_table: if ( unlikely(pg_owner != pt_owner) ) break; - rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, - update_flags, v, NULL); + if ( cmd == MMU_PT_UPDATE_SWAP ) + { + l3_pgentry_t ol3e; + rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, + update_flags, v, &ol3e); + + if ( !rc ) + { + req.val = ol3e.l3; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } + } + else + rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; break; @@ -4201,8 +4247,22 @@ long do_mmu_update( case PGT_l4_page_table: if ( unlikely(pg_owner != pt_owner) ) break; - rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, - update_flags, v, NULL); + if ( cmd == MMU_PT_UPDATE_SWAP ) + { + l4_pgentry_t ol4e; + rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, + update_flags, v, &ol4e); + + if ( !rc ) + { + req.val = ol4e.l4; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } + } + else + rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; if ( !rc && pt_owner->arch.pv.xpti ) @@ -4230,6 +4290,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; @@ -4239,7 +4304,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..2c403ca47ed6 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 /* Update and return the old value. */ /* * MMU EXTENDED OPERATIONS -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 17:46:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:46:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438579.1657296 (Exim 4.92) (envelope-from ) id 1xCKrN-0004tc-0p; Thu, 01 Oct 2026 17:46:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438579.1657296; Thu, 01 Oct 2026 17:46: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 1xCKrM-0004tV-SQ; Thu, 01 Oct 2026 17:46:20 +0000 Received: by outflank-mailman (input) for mailman id 1438579; Thu, 01 Oct 2026 17:46:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKrL-0004sS-7Y for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:46:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKrK-009PVE-Kc for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:46:18 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe9c4d-8faa-0a2a0a5109dd-0a2a4508d8ea-38 for ; Thu, 01 Oct 2026 19:46:18 +0200 Received: from [52.101.56.34] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9c68-f659-0a2a45080019-34653822a43d-3 for ; Thu, 01 Oct 2026 19:46:18 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV3PR03MB7658.namprd03.prod.outlook.com (2603:10b6:408:28d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 17:45: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%3]) with mapi id 15.21.0451.026; Thu, 1 Oct 2026 17:45: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=q8by02G+UCdBylnn+ydknUyzzkgW+FK3e26F5jeg2iXyIvqv5goncWog5RsVHamkXBGidH11mYvCt57kwKF2QUc2rnXO3VWGNcaTGbnom/EXTba1hLjF+Tet5mmew+SeWI8INXR2neBMa8bqgzkMOGL7yEax5G/8LZmsogBDQNzS7of2iGCSEMrwSPNAj/0uBy2VvdztKe1jjDKpAE9HieIZVvcd7slvpB2g6P1oLtNI0k476Pssw7CC3+0y5c20RrtjLZyPL+8NmVE1pEbfasnvz1tFxhpx3DpILfs97flvSBpHAtoWA1eQsz9JA3N7K8J42M39wCjdpH7Kkl81fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=o6J5mtRqMkkYJgCnuFbTlfm0vxzMbd7IsBhqGcPmZ0U=; b=rNGAx8nVzkfpVbC7Fv2fr5oeYdG6RSpYzWcvzygiZb/0ZmbbONRngn89DbkhwZ31vRnKv3JljuJ2x1WvuLJmKi6cYGoqyQV73vqRTOI0F6eXMrxlssTMQuUJlENGJdV7fEl9oZFUtJtjJWzoaGk6Lncc3QeNrxB+YrBCDbfyAdGL3DohfsgNQkJ9f8X2+8zS6KMKXTaxyWL5BXtdSTYDoST3oyJnRtuVqpDsgViZPAOKgGUP8LJmfFOl6ez+icmegyEsWO6Cp4XvlEM3E5Sn5DsUeS1XvT2LSvgjSBKcKRk28514iI10GZaZ9+hfbpsNMxXk8a9EUufN7uJdJD3ACw== 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=o6J5mtRqMkkYJgCnuFbTlfm0vxzMbd7IsBhqGcPmZ0U=; b=x5s3zieBZq3UwMuym8X4oG746w+cJHpQUd9XZgjWeBWONZ7zcGYMUrPUWqjs4VPa6w0Gue4bvrqWJrXkIIg2jlSegA9Wy04XqMJKWrFMY5QYY65JrYu5ESELx0ieYCK3SFw29UiMSmwOrHObKvGf8fF7qeVKbRzEUH+XcjE4oRI= Authentication-Results: mx.microsoft.com 1; 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 v3 1/6] x86: Remove return value from UPDATE_ENTRY Date: Thu, 1 Oct 2026 18:47:44 +0100 Message-ID: <20261001174749.2275245-2-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261001174749.2275245-1-kevin.lampis@citrix.com> References: <20261001174749.2275245-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO0P265CA0013.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:355::8) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV3PR03MB7658:EE_ X-MS-Office365-Filtering-Correlation-Id: a9372c10-5c13-4cee-e5d4-08df1fe3d2ee 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|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: 7m2xm3kjFwBVdSh5aHc8e+Z295PbqMKJ6lCYSSnVDCKkjVtcKLJZffFClJXb+rv4ClpEXga94449ykQHPG4UoouadIwlq3Vj4Go2Dd3G70scqzSq3elVv1g8exVJGUuIMG8fNDs37D52BRq7eW+rdMcpYOH30T593/J9umDZmO79w3E8STLYYYDd+xFkETyCTs6XTO3GKFUp66y0zwoiqah0+S1//sPIQaxH6XhxVx8/YGuw4HyD7MriYVoKSRHRFDNKxL9VIfYgFb8A7eKies0B/Nuc4j84SvkiI/9uAvYTEHmQ4GThGiBu+K3f9HcCGPgxivizntIOE615HnMHNKmjVcBFYC073+U5DMH54+qmk14tvoImVliCTtNV6GakM4x3o0N+i69C4C3AxT2vafFN1Ml3IcYRpChd0ke4fJkX7Z5CR+3gacLebTi9maRMKGvrzDBe03uBgeYe0pI+uIjaqeD8vdkexZ65ON3tP83AYt59a/bGHTgsaGAGd2+CR/PH7AQhNhUu7Bas6Yp+L01vO33TgjBHy911KrxLsv9gWf3mc2soNay8S0yJT4pFdupolvyiy8EgSEOJTWu6eHhWdcEWLTOU/D1UJ1/1vpIRX/jJz6KLQSi8cf7Yf6pUyhV+B1PRTt7USH4wMxqqyYac1XEfbU256rLZjBT9V3w= 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)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OKFsOJIS6ry7+pwPWpnNhElPA6IGl6zy0lnn9mHwQPiLC6RxLyul/1QolwLg?= =?us-ascii?Q?xOiwD7bbjkpy2LovLWe1zqCMuDhZqRQwvEN0Dnn9y8u/rkryhTuZHxqVKVfA?= =?us-ascii?Q?wDwONJflWnnQsWqTzJI2654WpYbafgFTm7t4IjZdr/Q60+cRTLHnu4/z1tY/?= =?us-ascii?Q?t7Om2U7Sk3mHuydwDn14k/f9PvZwpU2QqSs1yLfqnmD0COGc5w9hzHhSuuMN?= =?us-ascii?Q?ywOfUE2ymQhyAiB+ditxRgMzOywU8FKhWyRcf0qDf5W97oeZJwg6ebiSmj5L?= =?us-ascii?Q?UmGlE2cPoglo2GNlZkLUZNXF4TjRno88KE3NPt3eTzb4dfeEvNx15VHICj9T?= =?us-ascii?Q?zbuABWbQI1QjGrkP1ZRpxURkjHzd4A3T4ak3eNl1OUVnX3+v32zcj7Yucbr1?= =?us-ascii?Q?zA6dDzfbbtAAhpoG4xaxvLBB3FX80OiuSWFqEWBwoLw8AcOsZG7AZ51w2Gq8?= =?us-ascii?Q?yfNJAWC4xE00KTQK54lTmfm/T8URaKOsj3Ma/g7fkHCNe3OrnjxSBbUhNfnO?= =?us-ascii?Q?RBe6xFeoSl0v02WUMctr5miYFpk91e6Jb3Oczzwt02OWAWA7OLw9b0YCcB9J?= =?us-ascii?Q?L+hUCv6imwyBumMOunqVqtJCYUQkVYDgC5I5CuEs4xp684gZ1APcDJeF5slL?= =?us-ascii?Q?i1p00IWJACs4pEpiIfvH4GUAjpluq+/A1/rjqrEaRJFnb+aw5pBDdIPed594?= =?us-ascii?Q?B+tl8//d1xaWKkjSnVD4vhsONSGl2Te/BD21XrcZEX618ahhbnErGmeF73e1?= =?us-ascii?Q?yWrME0uk37Xe4Is5sAnSNOEdX+Vd7LlQLFr2+/EQ0k92sts5QlaXtKZBN4aO?= =?us-ascii?Q?tykrNytW5ZdBKn+IkCFysC9VGc/0v6JiWtPfepZ5ZAAY4+tIXCBOr6zqu7jC?= =?us-ascii?Q?uLmlH3vpSs7E0Dmh8CmxqjIQVtNgYwIxjLBS4Ax3SyP1Ch4ziVCt5sNaVkKD?= =?us-ascii?Q?9+4+4zpi2979bWqLXyHsskaFMubbi1uGbI8QemwHdgBPhnmU45r9qdfzz47Y?= =?us-ascii?Q?tyVRaJcIQX/ix3QRU8JHhv35LuSyPnbGGrsE7p0qjDVMngl/O6HnVHnBgbZk?= =?us-ascii?Q?jEj1y9mFKfe1kzFSIkDUhVZFgSlDrsH0vZKNqqpJbivaq2teThNBq/759HhS?= =?us-ascii?Q?02U9QNzLNgBSec7ydQnVWexv57GPnYs+TOar/OgqbjzVYrUsfWh0Qa2iVYQZ?= =?us-ascii?Q?ni2OpsfVnHrtyWRmWZ2CtbvRFWHGMZgC98PuNSKWkOpKXcAfwlEQL1xrgEb6?= =?us-ascii?Q?dSLkhL7Vs2zZtG9XuJ7IPFsncAxQSU2JpIZoPw5gVMcxTWBxV2teB7ulVmif?= =?us-ascii?Q?P1gAWmkx46eR1iOkp2xg1JYkSnci4gjiXFQ8VH0t9C5mQ451avUhbHhHBHRH?= =?us-ascii?Q?G/VUzb6eyKcqPuVtu6h6PZEGNrOj85T5yjRfUWqgPI6wBfFLxh7SyRGscKd8?= =?us-ascii?Q?Egm/r6pCXqTy8xcykstPTGM6ZObFMbAbBJlRyQwfSHB/PwT6j4TOJuUV+N+m?= =?us-ascii?Q?nGNw5ofMBVeyqJJ7iaa2QWcq3BDO+AoF0hLmhCfskxIZx+JukAHR97jg3Xu/?= =?us-ascii?Q?9lDw0JiWrGzz7LFqgtO302b/bWgxb7C1fq+/dA7ntcLQRka8q2wciq7rsECq?= =?us-ascii?Q?mdgH7+pDYzJObePSf2TsGamwcSnNzQJSf9ynnj038KDf+q45DyaFQQGP5/5Q?= =?us-ascii?Q?MmOQNLODYPbh/U13HcBRfzqudAFD3gJ4iTUpUJDW1Zm6dOhwN0xaew2mdepA?= =?us-ascii?Q?roBsQOk2iw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a9372c10-5c13-4cee-e5d4-08df1fe3d2ee X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:45:46.8252 (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: uXWfbcaGOuJApmsuCkEo6X/eld0BzPnIUTzKQguaI9va7WurVtwfXCuEls2sAomRBYNCsImP0ZeMrt9BlT5iZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7658 X-purgate-ID: tlsNG-c1860d/1790876778-D6D4087B-5CE6C553/0/0 X-purgate-type: clean X-purgate-size: 10413 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 v3: - None 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 b1bbecc7d7f7..1ddb8b71469a 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2215,11 +2215,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) ) @@ -2239,20 +2238,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; @@ -2295,28 +2286,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); @@ -2357,8 +2339,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); @@ -2366,20 +2348,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; @@ -2419,8 +2393,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); @@ -2428,20 +2402,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 34349e9437eb..f6baf371926b 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 Oct 01 17:46:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:46:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438580.1657299 (Exim 4.92) (envelope-from ) id 1xCKrN-0004wB-8O; Thu, 01 Oct 2026 17:46:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438580.1657299; Thu, 01 Oct 2026 17:46: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 1xCKrN-0004vp-4C; Thu, 01 Oct 2026 17:46:21 +0000 Received: by outflank-mailman (input) for mailman id 1438580; Thu, 01 Oct 2026 17:46:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKrL-0004sh-Op for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:46:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKrL-009PVE-5h for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:46:19 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe9c4d-8faa-0a2a0a5109dd-0a2a4508d8ea-40 for ; Thu, 01 Oct 2026 19:46:19 +0200 Received: from [52.101.56.34] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9c68-f659-0a2a45080019-34653822a43d-4 for ; Thu, 01 Oct 2026 19:46:18 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV3PR03MB7658.namprd03.prod.outlook.com (2603:10b6:408:28d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 17:45:52 +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.0451.026; Thu, 1 Oct 2026 17: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=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=bCdrN+1icuEEUNxB/NlzkCfdm4CSTQeIMaxzvAUtaFkvdFl8jlvrMIXpWDIkP6rDZi4P9ADl0yzaBt+W/s0Fh8NjfH6rr4vaxpzNVp36BSujn7gowCNvd3RShBUAaNiczsDO5M4+TVFoPH261PmBx0Ew87hmKw2+0DJSk7FTuaOtWKsGdVG5u/Vm+R9oRC24FNCjQhkxnCwpbbAn+KLHPE6VC+NArBUVJxvXIOg5D1iYQt9ZUwYA9eKqlDaPQburikIixFyINF5JXPKG+8UjdW7FI4G+4iSiKNB3yyy1kx4BJehkGnhPOX0rdAY7KiwhEgd6fFPQwzErpC5M37ue9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vZP1qWvcBKGy+An2YvUS92jnRpESFXMLGTu4MwG7Q+E=; b=gtoCOM2E/zp8S/llem+ko8SZDq48rhY012FVQDTT4hT25xvH02hyAnXiy/q7R/f/U3W5hLfgEkUusGr2EtWWf+vNU7fGr8+kEaOaKBYikylz4Y+3TP4UfkRPyNXwuXy9B/FkYid1AfO58+Kj30l+yQuoJH6ZroKID20pHeAxXEOtuTN7PuVlNy1nDhA5ptxDYmsv1msx2lKf+KBT/C8BkslS8OkXENyU10a6M/6DiRUOnefsUyo/rkTVE+weK6mNVlbN0DqsYiOwa0qu/dqzPiAQiWsiol9mRhubhk7prlASi4N++D9C8wdTH6E6j7Pu9CLrnPHezjiN/D9fDzARog== 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=vZP1qWvcBKGy+An2YvUS92jnRpESFXMLGTu4MwG7Q+E=; b=gpBFyQ7FMvK3Nq72Y6o09Q8U8e79H+GznPiDJXHH6WljfSn9IeaVQsfhLcTUGGErJ/xAUsHhIYmCCVND2N2Tpyl43w03crIG0rid5CvsDSaVyUvBcxUv6i4hVquWIHt7EYw8jaKt85V9O4AVKSOwdGCdNtk4iY25Cx9UVqyXpBU= Authentication-Results: mx.microsoft.com 1; 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 v3 2/6] x86: extend update_intpte() to support atomic get-and-update Date: Thu, 1 Oct 2026 18:47:45 +0100 Message-ID: <20261001174749.2275245-3-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261001174749.2275245-1-kevin.lampis@citrix.com> References: <20261001174749.2275245-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0395.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18f::22) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV3PR03MB7658:EE_ X-MS-Office365-Filtering-Correlation-Id: 4b8cfe6c-f47c-46d3-4c9e-08df1fe3d615 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|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: Rm/ob5e5sARmqFN3HzBGAqygO/EUMSdNxhmV/e4PomMZlUqI4U7HDeNid1WEn6ICos6fHfb9ECDWE8soyIT92pQnu5flZYYC05r2l53ZIc5qO1y9C+rTVgg5t503pFVEQjcXfF0RaFrw1iJu6QIx6Jlen88WrlyFkSFVIj8UftWB8+Z0RFnYdK8kOmJQHjpIfOO6H6sl1IJ/ydQGIdx9w7ekSFHkPLW99QNjiM330SnizTOgr+inp4gcGwGYf6jz1hrNIVeuNXeqxKPbHkWSiiEJVPTwQX2osPerAw+SVIZUlWWbeXrk3LnNaucduxI+rD6fZ+YdoJzQTQ/rwFRHIqYsIzXDYNKFsY/7s9gIETa3LI/IMgMBoissgdxpa9Abd7tCw7lF0+PgeqhCvhsviX7Ur8cZ47pXLlPea8QdtGyKTH81HP7ihPekZm0CtROiHz30811HeoLelBfqxjGmOfnRJX0JPugIr2dXcy4loyJkQDPZDN5CjdTPeSEFmQaqUkJwCU42eBX+pniF7cAWYRQI4JNPaQCkCoM4ihsHhcI5rOUXXYsw/IvNVVd+fSVzs84/8z9HHnwUyrFWHZ47frjxicKjN4qGrLVI2g3X7hh5i5IZS7blxYD5V5fpZFRAYXGMKwcRSZ3sVh4zRJRpCUB/s3thvpQqJYUMOq8MYXs= 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)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?n/L5DH/FbgISSNlzRQRGWAriYThALBO2HDNWJ9z6/138ub2YiXnryftoHP5j?= =?us-ascii?Q?rlTt6v6HXoWVJmX5204L4Et19Y8nQ5ESz5mKtmtp0hCuGj8GahgKjepN+Eab?= =?us-ascii?Q?MMYkYL59DmQjeNOKXkuHNtkxymqHSvnJ5fFJpP0myntkg/G/qzzUHcYEjMDg?= =?us-ascii?Q?hMksXdHklq5K43pYKNZxmgQDcmdPnQOYnE+9OBA8+lA1LPfwDivmWjjxqjQI?= =?us-ascii?Q?RRjmx3D226ZdqJ5IvzQQ0sZkVChvJ95xLKKbU6+A3imI+g3VhTAUn/aG35t6?= =?us-ascii?Q?HyS1KBRYHtNlJrOVMtiQOemm56BiT6xPUppwCjwHfyxOcxEqRkIpnhfteJGy?= =?us-ascii?Q?Ivx8OnMgKvrizMHk/isq2I7CCfOWXirISG9izbQxn+YmqoQhoNB+nRXCCRf7?= =?us-ascii?Q?2ac9NZtCgAptGkBNZiXpWxG5zSG0/F6HRT18grWAzyouVnfuwGr5q5ki1sOD?= =?us-ascii?Q?JYdHIpg4rygPjP5EfJ5D9cYc9bC/+8xAfJfDKuQNcD65p8q8cVN09VmkK/Gl?= =?us-ascii?Q?r+wAVAK8Sc0GNbcO33f9Dc5ms28liDTDBRkwXWDTwcS1DXo6pgyr0VA/m3tv?= =?us-ascii?Q?4e0HLvYh/7M+QpWrZny/pP59Ln+biOUB9YaZ1D2+DB6dB2p1qUFlW79+AKob?= =?us-ascii?Q?UajJAj06E9/iKoVWbCt/zJ4sgXMv2vCuko8QXsyZcB8oc9DEm7BHWXVzJogF?= =?us-ascii?Q?Hm8gYnnqnVJFfSIG5mhnTJaZ9dNww2xoIF/QM5iZn8RprttC4B4+eKJ6uYT0?= =?us-ascii?Q?3nD42M94NR32JjImzekLXG3/xcKJlPjcrwFvdSki6hOzcqHiTfkX6BxRHDuG?= =?us-ascii?Q?3vvmJp6UKNJBVF1qT1QZy6TENZ9VR2IS/6D7VD0Mj/A6ukD8+jnpA2rmRbz2?= =?us-ascii?Q?yQah9JGL4sbgYpvdgIhA7+ojl7IS5sOEWa/tdL6rHDNCu4fVZkBSIl38DN+c?= =?us-ascii?Q?0JcG96F9bfLHp9nW8zqyHizQLvjJIjpXsTSUdsPNyGGeTn3zhflOzmeKftn8?= =?us-ascii?Q?yCcnaQ4lYsUdOS2pt3nlFH1xp2FCXvW8Pc45z6nCobkRIq3Ue9XdYvJeMFrb?= =?us-ascii?Q?yK1X3hD4UgzIi0NYM1J9bDTNCejmbQR88oliAZRg+Yzi9A3vnCbD7OLW+ZYm?= =?us-ascii?Q?NNppYJVNAgRO8rBsUxKrwOBX9ohGEjoT3pyIu32al1ZMNmUJmZ7CmzhYz4l8?= =?us-ascii?Q?pzTfr8pOWVDhSbDw8lqf8t576zJyY0ZUIK/1pYZiEmMxdl8EFCF9fKXeFNgK?= =?us-ascii?Q?bM/E1AKItCho5Sj2fgGmESj8kVaXOAxP33ZGXmnUTfN6Lyc5HiaH7dPZmBrt?= =?us-ascii?Q?vPtiU/Y3uPy9nxjO15lqq8KLwHN9RG5YAf9r4r3bMqlxgxeyGlcZtYohWxVR?= =?us-ascii?Q?OC9eqD+gFQBv+FogQCkjGLcSnJrVHDP+bcYaSqFJyQVsIUdLs5A1hGC3KoCf?= =?us-ascii?Q?5iMr1Tyk+hqubfbWd/Aeeu15mG0zLFS0xd6OMqsBgQifoXX8ODDFHtLA7ObH?= =?us-ascii?Q?yi+mEVPs6IUaSIdr2dCJNRtLXFUodLyCX4PIUebXPoL+3JYhJ65QnHuv0wc1?= =?us-ascii?Q?GarC7qAO5gCeQpBeYJi1fCWmCBAuGMKAKMBCqyxlir59FNEvH78KrTtog8V4?= =?us-ascii?Q?CyPJZuReZEM3TYUr+VKTw7+R5DKVnXnYKezmpmX+O1TW7fAHnilpQgEjwDJh?= =?us-ascii?Q?Hn3Xnc981rl7PbkdlYNjNg6sMLVeFliRKopqd5qR3r/rzC2DKPde5OKK/ron?= =?us-ascii?Q?/jfu+TgYDQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b8cfe6c-f47c-46d3-4c9e-08df1fe3d615 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:45:52.0245 (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: 9xx4sn3GdeptJYEWuYBO1Ld2GratQnC/I+6Kj5Naw6nhgLTg0Hzja1UVroPo2autyYKTX3dR7Sye5w0zDYTilA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7658 X-purgate-ID: tlsNG-c1860d/1790876779-D795A87B-0B713DCE/0/0 X-purgate-type: clean X-purgate-size: 3025 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 v3: - Return 0 in the paging_write_guest_entry() case (update_intpte) - Add UPDATE_ENTRY_SWAP to convert return value to correct type 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 | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/pv/mm.h b/xen/arch/x86/pv/mm.h index bfee0feb7b21..363db35b5fe3 100644 --- a/xen/arch/x86/pv/mm.h +++ b/xen/arch/x86/pv/mm.h @@ -64,16 +64,23 @@ 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. + * If the SWAP flag is set then does an atomic swap and returns the old PTE + * value, otherwise returns 0. */ -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); + return 0; + } else #endif { @@ -95,17 +102,26 @@ 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) +/* + * Macro that wraps UPDATE_ENTRY. + * This version converts the return type to l{1,2,3,4}_pgentry_t + * The return value must be used because of compiler flags. + */ +#define UPDATE_ENTRY_SWAP(_t ,_p ,_o ,_n ,_m ,_v , fl) \ + _t ## e_from_intpte(UPDATE_ENTRY(_t, _p, _o, _n, _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 Oct 01 17:46:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:46:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438581.1657307 (Exim 4.92) (envelope-from ) id 1xCKrN-00053O-R7; Thu, 01 Oct 2026 17:46:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438581.1657307; Thu, 01 Oct 2026 17:46: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 1xCKrN-00052Z-K3; Thu, 01 Oct 2026 17:46:21 +0000 Received: by outflank-mailman (input) for mailman id 1438581; Thu, 01 Oct 2026 17:46:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKrM-0004tN-Md for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:46:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKrM-009PVE-3L for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:46:20 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe9c4d-8faa-0a2a0a5109dd-0a2a4508d8ea-44 for ; Thu, 01 Oct 2026 19:46:19 +0200 Received: from [52.101.56.34] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9c68-f659-0a2a45080019-34653822a43d-5 for ; Thu, 01 Oct 2026 19:46:19 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV3PR03MB7658.namprd03.prod.outlook.com (2603:10b6:408:28d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 17:45: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%3]) with mapi id 15.21.0451.026; Thu, 1 Oct 2026 17: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=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=XGHpgIzMzfDZSQzPJnE++QRrzIaLi0BdGN/7DYH8rjVFnVZVSKMrwhQjzbvoID5s50ahPRffp8WWvPNNJ65XY5LBwk9ur/0++oJcX35FIFnITi1g7Id4U3/O5+UpJuhWn0NIK0wzUcubWIV18J9ijMoztg60AiZue24eqQkSClcN+uJvnMCXVfZis7CXTRK9BkjhOpFmhlkuhcQzeqnoyon0bOaYzI8ZOXED6l0A9Et5Sht3jySiSzwUz+q4GxM282uFeAzdJarqAqon+hOMLnPBCQowY4d3wBbXx70gXF0wxLLOcRkQR7uJZUvisG8Be2CPWeTHExcRj2t3xE6RvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pQ+J3wc2JXd52VnbMqfcY5c0kIzjo5Lek38sZL8Kkbo=; b=pfywxmhFDceI9qd7CH2gUdQilTwyipyc6qnT9rzC1iSr0cUUgLUmK4+6930yJEVfdAMVUqH6eqqGQQpVGX+bBfyQn2TPhPsIXrxFEYhtmvTodHTD4tLFJ5Kohrmge33G2Tmebwcn5IQspmNXRGfd1BufuIyQrx7LvPiYCl826pwzNUvoA14ui6isIpShZpj55lRjWVJQSoa7lO7j/DZ4zRvKHjp6xZte2zUJbC3jQqYqY7A4Tf+lgorgJ+nIka0QVLLFr8KgBexwXOsMR4WxgKqF1xh+ZSy95lWRbpmm7xs62jBe7WakY0ooWEDCUejXqmnuVEupsG/YPjzgoDXqwQ== 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=pQ+J3wc2JXd52VnbMqfcY5c0kIzjo5Lek38sZL8Kkbo=; b=jkJFFZRd9Yw/yrHPCKK8Bljeiv1uOFQO/4iqkt5RzIEEMMI/aSjV+ke/YBe+sYj/0Vj3PTcUiIEIN3CS0EfNwBCw9mr8xn6swQGr51WAnrOekVQn/3663oGcW8Bo7NJ+26NOmISsZSzySvQcXKX+X+QO2aZXKwoS25iUN4Kya/4= Authentication-Results: mx.microsoft.com 1; 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 v3 3/6] x86: extend mod_l*_entry() to optionally return the old PTE value Date: Thu, 1 Oct 2026 18:47:46 +0100 Message-ID: <20261001174749.2275245-4-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261001174749.2275245-1-kevin.lampis@citrix.com> References: <20261001174749.2275245-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0394.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18f::21) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV3PR03MB7658:EE_ X-MS-Office365-Filtering-Correlation-Id: 42232dd2-dacb-4723-7d1c-08df1fe3d8e7 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|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: +ipdoYBCVO54ysnyVuFUzzc4f3h4k6JhZAD2ys/8STdplHwIWeuavrRVFjVBCzA9rmGNX8IC+pK2lk41wMHBTyFljcFHfhhRgbcz3iGaqDu0qn5sshh5dWBScLtZerxh1FK2ZcdztyvYEpfi7FbIm3bP8i1qJn1bS14a7/dlEM+WGZF5H8fBGhBU9GN7vnpmaQ+9rGWQx3TyhbkhN1m4o7y75EKp6OwiuXmTTLCJB/csc/bLjhm7+yLEvBovONj//5qNEHI24HO00kSAVaokGxxOFohIngC/8y5tBXRiznBa+NkV3OwWpzvkKBF3F1llydol0SGo+BPMCbKR4bfxPK45fbVrRsBrxWBL9Jgx5JiQKKtF9ainGdMN5m1qTfWlzlz3PXAfTG0nEtg0U/+3TtsnCCo5Q6cNTuM/KFNPW+8dO803xNuEOt/4dwdHhzzfDFr7LMZKtugLs02TnJOslCEmdyiPM6ruePQIMPDxMLYiGTgKTUDKGLvnY5ZLE0c3JEpR7132DGYWxkjcpGPyhwXIz6vqcv77aSTk/126F92wV743oH2gH2Qb82BjtArDIxDabUvEdfi8Z61IdPBwo5F26ilfZ7XUkRHHwSkgnnt2cXA8fP2eyt+x+XjmkrBv/4fF9WyI4GAomUxl1yjv4181W8h7/1iy7MwXmx1zI6I= 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)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?iuvux4zOZAkMGpWGR9v/5EN8zDSDrzbTkShmi4kJyOAZcMCeQGZdsv8ptNeU?= =?us-ascii?Q?PkELX/pjWxA82YCr8vHVHxe2f2O2yxLlSO8VoQTWrVzkJAKOmKAouMdW+ISb?= =?us-ascii?Q?zEfLrUEFq+tcTDqMXRLURwuNwxxzP1JC4QoGpm62l3TNI1LCFTY2dKlrWPs+?= =?us-ascii?Q?nS6Er/IvGvXF+aQMaVec8/dD8cl9DI3AfaUtRFl5Oe4HJMQxw3cisxM4Ln4L?= =?us-ascii?Q?ylpoyiDPrMKWap5maZJtmAIVruhkg7yaebFoc1gnF/ap2Vr88tC89SVIGA6L?= =?us-ascii?Q?JzBNjdTNlVQoLh7lL7/nj7V3UsIQhommp9SXPak66iP70PC0TGAHn9C38wLH?= =?us-ascii?Q?h8x5V0OfcLdGXHxwd4ZtcIHaCgtz+p5nSSLBVJQmIEFWgsbVsyEId2A96d0l?= =?us-ascii?Q?ge+Gof6gEKu3B6ey2QERYCu2Iuelv26Rk3VAtJ1jG/5i5Oa58vguS7uvefGF?= =?us-ascii?Q?GTNcwtJR+hVMt1FUIY7+g67bej4m5IlytYqMhkzlJo5iLVTrw9n6wgqtBD1L?= =?us-ascii?Q?dOxl0Q7z/JMa+H07ey7UEbvLGkkZY730I5YafBvcSSwUhV2r+GG27T4JyYOG?= =?us-ascii?Q?7zaIX7nim/nbT6/IhGKokb8G/CaeyI8SspM8D/mEKk08ifRM/ZQCDs0FO0Em?= =?us-ascii?Q?5nu5hSvYQbTuL3Wt4FrFyxzXzHoOQ5fK6fbSz53v+rcXDfto/AAeNZjpCR9Q?= =?us-ascii?Q?u00/D45sbTu1rTJ/lPONbtN+tLpi2atYAQsHDMFME5hYnM4IQbx5i6UyDHZ7?= =?us-ascii?Q?w1lr/mVgPBLyd26nefnidiEYxPz+LGVhkByK7ilxzww2PDxLh8XjmmLMuGUa?= =?us-ascii?Q?uO7FCuvX00jvecFFlF5EjA4vMs2yjlaqLUTHWnEPr/ewtMRDZ73KEJeRWN/m?= =?us-ascii?Q?3fLtxS6t30RvwgmzKAXhhYBFOGWmvqnuuZg2gl7CQRtoex6EQZ41B3VPtEhL?= =?us-ascii?Q?vQhEYo/cGBXg7hjm2XQyp5kVhmmpZ6zVtkQGK53voPs9ncfNcPg10aDtwUXQ?= =?us-ascii?Q?QbaTe3F0Zuh8LPDLT/asJm1upALpMV65IbvR9Eyfehe0Omd83wTvsCMAuFxF?= =?us-ascii?Q?g7dVoLNzX9h+aeSMfJSNzgVSr8cNGvUed909tsssS22ua6FmYzhXKZQNPfyb?= =?us-ascii?Q?t6AOdOmQZLbGD5Us9AoOqiYPDmSlzhAjssEhKVx4S2nDPoEv2jsSVIwyHsBv?= =?us-ascii?Q?IjpFJOJWfknUICMrrJjwcL07CaCW4O2l5quAPKPQ3ZKmU/7tkpBxHKCTbh2Y?= =?us-ascii?Q?263LL3XpEny7YKUrhcHYI+LdljkPNq+PMt8fpn8lotBxr6eP1DzIsbX20Ys2?= =?us-ascii?Q?cx4EzbR33+hGE5IVsa8cn7TOVMpyuZE7KH//tC2vvVB6o7N0YddI2Vd4UmXq?= =?us-ascii?Q?IW0q805+BuzlI2KXFNLeB0Nqn7AD1L6Kd/g9+3FuBOxtAaJUzwenmX0yycHl?= =?us-ascii?Q?kcrBPScqi8hg1xgvbq3fzUl3bZHzRwnzVz71S5uiVcP777xn3JEhkY72pGJ2?= =?us-ascii?Q?e4a9mf+DqzgTjXOAziLOgs+H0p2xdaywyGdwiKSsRwvU0p7BHzGzGFi7Z6ZH?= =?us-ascii?Q?me3aPCww90mC9A8O3aw/mLOI2STWdOgfWuZATUa9ng49y8+SZpSxxen3K+v9?= =?us-ascii?Q?ZGrbeHCdbawbuNbnuzceb4E+2JdzU0jOjtWJjtyRdi8gt/fpHaJ47tR/wfI0?= =?us-ascii?Q?jCHWUwufEsY4MqdE3voF3XZX0Jt/N8wGOsQ/0+wVB97z5ozbYjvkd4oezY2I?= =?us-ascii?Q?I7xZLzPsTQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42232dd2-dacb-4723-7d1c-08df1fe3d8e7 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:45:56.7997 (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: yMJDKPX9BA3iDYyoJjWkSzWns5y2DWtJ0eqPzfPiwr2EOS2DMMNidZRfcAxPLcDyTlIkJPNINO5IZDMVWDAnoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7658 X-purgate-ID: tlsNG-c1860d/1790876779-D634587B-209EA177/0/0 X-purgate-type: clean X-purgate-size: 11242 Calling mod_l*_entry() with a valid ol*e_out pointer will do an atomic xchg to set the new pte value and return the old pte value through the ol*e_out pointer. If the ol*e_out pointer is NULL then old behavior is preserved. Signed-off-by: Kevin Lampis --- Changes in v3: - Add swap to mod_l{2,3,4}_entry() Changes in v2: - UPDATE_ENTRY now returns the old pte value instead of using an out pointer --- xen/arch/x86/mm.c | 107 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 85 insertions(+), 22 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 1ddb8b71469a..535a62139cad 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2154,7 +2154,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; @@ -2215,7 +2216,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); + if ( ol1e_out ) + *ol1e_out = UPDATE_ENTRY_SWAP(l1, pl1e, ol1e, nl1e, gl1mfn, + pt_vcpu, update_flags); + else + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); + if ( page ) put_page(page); return 0; @@ -2238,14 +2244,25 @@ 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); + if ( ol1e_out ) + *ol1e_out = UPDATE_ENTRY_SWAP(l1, pl1e, ol1e, nl1e, gl1mfn, + pt_vcpu, update_flags); + else + 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); + { + if ( ol1e_out ) + *ol1e_out = UPDATE_ENTRY_SWAP(l1, pl1e, ol1e, nl1e, gl1mfn, + pt_vcpu, update_flags); + else + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); + } put_page_from_l1e(ol1e, pt_dom); + return rc; } @@ -2255,7 +2272,8 @@ static int mod_l2_entry(l2_pgentry_t *pl2e, l2_pgentry_t nl2e, mfn_t mfn, unsigned int update_flags, - struct vcpu *vcpu) + struct vcpu *vcpu, + l2_pgentry_t *ol2e_out) { l2_pgentry_t ol2e; struct domain *d = vcpu->domain; @@ -2286,19 +2304,33 @@ 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) ) { - UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + if ( ol2e_out ) + *ol2e_out = UPDATE_ENTRY_SWAP(l2, pl2e, ol2e, nl2e, mfn, + vcpu, update_flags); + else + 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; - UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + if ( ol2e_out ) + *ol2e_out = UPDATE_ENTRY_SWAP(l2, pl2e, ol2e, nl2e, mfn, + vcpu, update_flags); + else + UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); } else if ( pv_l1tf_check_l2e(d, nl2e) ) return -ERESTART; else - UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + { + if ( ol2e_out ) + *ol2e_out = UPDATE_ENTRY_SWAP(l2, pl2e, ol2e, nl2e, mfn, + vcpu, update_flags); + else + UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + } put_page_from_l2e(ol2e, mfn, PTF_defer); @@ -2310,7 +2342,8 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, l3_pgentry_t nl3e, mfn_t mfn, unsigned int update_flags, - struct vcpu *vcpu) + struct vcpu *vcpu, + l3_pgentry_t *ol3e_out) { l3_pgentry_t ol3e; struct domain *d = vcpu->domain; @@ -2339,7 +2372,11 @@ 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) ) { - UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + if ( ol3e_out ) + *ol3e_out = UPDATE_ENTRY_SWAP(l3, pl3e, ol3e, nl3e, mfn, vcpu, + update_flags); + else + UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); return 0; } @@ -2348,12 +2385,22 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, return rc; rc = 0; - UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + if ( ol3e_out ) + *ol3e_out = UPDATE_ENTRY_SWAP(l3, pl3e, ol3e, nl3e, mfn, vcpu, + update_flags); + else + UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); } else if ( pv_l1tf_check_l3e(d, nl3e) ) return -ERESTART; else - UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + { + if ( ol3e_out ) + *ol3e_out = UPDATE_ENTRY_SWAP(l3, pl3e, ol3e, nl3e, mfn, vcpu, + update_flags); + else + UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + } put_page_from_l3e(ol3e, mfn, PTF_defer); return rc; @@ -2364,7 +2411,8 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, l4_pgentry_t nl4e, mfn_t mfn, unsigned int update_flags, - struct vcpu *vcpu) + struct vcpu *vcpu, + l4_pgentry_t *ol4e_out) { struct domain *d = vcpu->domain; l4_pgentry_t ol4e; @@ -2393,7 +2441,11 @@ 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) ) { - UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + if ( ol4e_out ) + *ol4e_out = UPDATE_ENTRY_SWAP(l4, pl4e, ol4e, nl4e, mfn, vcpu, + update_flags); + else + UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); return 0; } @@ -2402,12 +2454,22 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, return rc; rc = 0; - UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + if ( ol4e_out ) + *ol4e_out = UPDATE_ENTRY_SWAP(l4, pl4e, ol4e, nl4e, mfn, vcpu, + update_flags); + else + UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); } else if ( pv_l1tf_check_l4e(d, nl4e) ) return -ERESTART; else - UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + { + if ( ol4e_out ) + *ol4e_out = UPDATE_ENTRY_SWAP(l4, pl4e, ol4e, nl4e, mfn, vcpu, + update_flags); + else + UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + } put_page_from_l4e(ol4e, mfn, PTF_defer); return rc; @@ -3277,7 +3339,7 @@ int new_guest_cr3(mfn_t mfn) l4e_from_mfn(mfn, (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED)), - gt_mfn, 0, curr); + gt_mfn, 0, curr, NULL); unmap_domain_page(pl4e); switch ( rc ) { @@ -4115,14 +4177,14 @@ 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: if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, - update_flags, v); + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; break; @@ -4131,7 +4193,7 @@ long do_mmu_update( if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, - update_flags, v); + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; break; @@ -4140,7 +4202,7 @@ long do_mmu_update( if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, - update_flags, v); + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; if ( !rc && pt_owner->arch.pv.xpti ) @@ -4480,7 +4542,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 Oct 01 17:46:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:46:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438582.1657322 (Exim 4.92) (envelope-from ) id 1xCKrP-0005WE-3p; Thu, 01 Oct 2026 17:46:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438582.1657322; Thu, 01 Oct 2026 17:46: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 1xCKrO-0005Vx-WE; Thu, 01 Oct 2026 17:46:23 +0000 Received: by outflank-mailman (input) for mailman id 1438582; Thu, 01 Oct 2026 17:46:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKrN-0004u3-7p for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:46:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKrM-009PVE-Ik for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:46:20 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe9c4d-8faa-0a2a0a5109dd-0a2a4508d8ea-46 for ; Thu, 01 Oct 2026 19:46:20 +0200 Received: from [52.101.56.34] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9c68-f659-0a2a45080019-34653822a43d-6 for ; Thu, 01 Oct 2026 19:46:20 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV3PR03MB7658.namprd03.prod.outlook.com (2603:10b6:408:28d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 17:46:06 +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.0451.026; Thu, 1 Oct 2026 17:46: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=w4aumFDwIkBPPPVsU0E3l55BwelA5MMTeQVUw2sjjt8Q9y7WN/iygbUKQtmMJukAY6WU3ftSc/MV7Mu+OEN2kzL99bo2Cu16F9FiXZvZsKeQS14biEDg/nLTR1zp7BfyqclAVsw+OmHypdyajZ+xzIB70pIxwz/mHg+EgAYGTsNIDUSkjn5tp5N2byH1v+tUaPSvYtUTWNK4GlAFBN/VXnRM5j3yq0sNGtydC/zSw1X5kZ5jHki1vnnI5VCU+VFIHhwpRvCDvXzW9sCzXgH/jG+MCcCWafEnozHs1Rjffd4Mfup6yLZ2b7/85KJOh4L7IhVPp+tHY+t2ZNWb6awZ6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qbe4wM1dK5RGYKvhg1OVSDgiavw9HA7GO7PeMS2rtwY=; b=TlxIC4KeNrSTnmGkH6oJL3hd/iSv3fJVxMjkXMeJFaB7vX1GGABkgeHsFyOGvwts4HCVy7CTBRYcXokOpqJ22URwCq0Eh/C+jgT+8x/QwvKHYjKFtIS73JfnFidVWTYk3NpB9G5EfKO83xIjD3CXxuOLPS8ZbwwG2gub3NQadtWhZmpJ4lQEjslDgzLvFTNWFpt4HP3nr6welVbMdoscIoERdjXjvHuMkNYswqe35vsZy8WnAg91/uBchx5Ib8o3xxLTDjHI4kDT0TodEo320wfeiG6DCyNIOS9GibZzRLI1UKNyyz1g2Sp1g7HI7apzjFzE3fFV1Ct2T2b6HGN3yQ== 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=Qbe4wM1dK5RGYKvhg1OVSDgiavw9HA7GO7PeMS2rtwY=; b=EV1iYSVvtk6So6CYsVOQ+KWAcqS4njbmuVZgO1DpBHkI/NeVGq4FZoM6Lu7jaPDPXMGYei+YUdhvLvZ+ezA0equnywAQrCMD2IToofYkNCfU78h1etybqW2QIV3Fj/8t1yM0E034P7oObKZMBO0JpP+o+kk5ZfYEfTTSomaAnLs= Authentication-Results: mx.microsoft.com 1; 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 v3 5/6] x86: New feature flag XENFEAT_mmu_pt_update_swap. Date: Thu, 1 Oct 2026 18:47:48 +0100 Message-ID: <20261001174749.2275245-6-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261001174749.2275245-1-kevin.lampis@citrix.com> References: <20261001174749.2275245-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0102.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:191::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_|LV3PR03MB7658:EE_ X-MS-Office365-Filtering-Correlation-Id: 8bd97cd2-afea-4fed-da6b-08df1fe3de7e 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|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: lG3DN/oHmstrlGPSFwsxOIaY5pTuDLVyhLq+Y7EyAG4Tu55V8LJ0rZO4QO23RwNGKrBDCuDmEi1kc7HKqnqhjGUZUSopUP2zNSavmWHvGQ4vHHLlt2U5FB2g234H3PuhnepVvou02sD0xOCELjqhOrupylnJqspq+T+R8CKyBdUiVSdRQMtXpRDnwVakra9kAArsh7zzqL40MHIMJ7tqatLHadof+KBX6f4GHf68Bq6U9C50nwBOrEdekYIGozlpYCegiC2ds7aMp/YPziqOJr4fSiv9Gh+KnDsybSGxQuyBTXG+O/SNCuGbXZkRNNkWDAGZfF47wazDXCYT3vcjjEkTBo2SCPzy5UITFq2t1jo8WrtG2JfvlowGkXHT4Gl7/6tVJiUq7g1Z/ePSa0sEkbEGwMKbYHcRx0rT6j9VYGHeV4nA+WpjdWCpxOPHHPARiudkXdZgXFZCV5y/tsqLsq8Lo+kY7uAW37tj4ghcJ59kqbdYmNwTi7P7EWFmk2uz7DzuVIo0SSKaZN/v5CzJvt91otHs7bOn8rZO6yIax47AXk/4O5aGdzgN0Rp8V5I9HO70UOkZN6eS7Bd2KvnTYBVwuM6qYOaloOUwCbwfjKirOR0PnTRFxsAyguFA1D9TXomttnQ3ovHnYZAS3/0jpM3JIDbKYdyz73Sfs10JEOM= 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)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?3Humsww7slK0KOi5pZhBYem8ZJLr1eCIIdQqM8iwNgePOQ55AXqES254azrn?= =?us-ascii?Q?k59aNQRm6s8DNhX2PUxggQGu/3E2z/yjnmBxzWaQujelEgQD2hOreZcZvwT8?= =?us-ascii?Q?li0ylu7jPfa52VCAGR1ePogyMcXmxb3gxqVQFlUtvfcXGAwtmcWaEVq5ICBW?= =?us-ascii?Q?tZTuAuZLr3R7AMSoR6Ncok093xqxQEO/zbo/BgPyzQlclsQozK96GFnn5UxO?= =?us-ascii?Q?4U2MXat0VfbUOTUaEeezJh07fbwghC3YrdAlOwFiPw1cYXlkdmqKLeCu6aTh?= =?us-ascii?Q?EzBp1IRzNnY+GjnJVu85Iu4l8Je6vO2WehtLRKWkaAOgmsbiBZPsu5711v75?= =?us-ascii?Q?z7ndPvdQUU0y+4kvy9NUAVstSCjpdDBe/0gIFQUZnOCij7sdke4LNdiiuXDR?= =?us-ascii?Q?oomGM6G/rBBH5OcsPdNXy3xCXTqUpxcEDTlhjuWoe6FrUYzK6CEAPe7bGTAq?= =?us-ascii?Q?UgOFj4/jvpVZh/7EE5Hsc1YoslYLo+H+LTIpcg7EFWzJueGu3SpDb8j/Rbdn?= =?us-ascii?Q?wSLZlyq/PuuIWUjdKOWSWAIs3TbE/Kl8xqdoEFGyhh7do8uuZm0fZeVRjADv?= =?us-ascii?Q?cU1PcPsbRDeQHgR8dEFXtHGFRn0btRRMIbnQwNeZ/Be0lLpnoUq3YgrT7cAq?= =?us-ascii?Q?ONA8u7BTUHSSY207bGqaWmRiCghoAJwzXV7dEjA3EYpviqgjMb1YjnKCFSzi?= =?us-ascii?Q?4tY2DC3va1leM83Qks0k2Bgu48jDrADJ6y9CA4n78bZPrvlIZrNzxYzgT/nC?= =?us-ascii?Q?wolrCSIctc5lu5wT7NKeeTfW1PQ0yCknp/soMXSuWs0EZbIWce7p5DqUX6kf?= =?us-ascii?Q?VmeEHSf+8nLfVKEjDqUthja7BUlBqvaYxFU/HUYoDbM5sFhZ+1N4qCRlzpaT?= =?us-ascii?Q?UfBB9lltxxsg+Ye7rrfn4wghmMLrpXy+cseQa3UFDTNvRRUgqzYCkXJlwot6?= =?us-ascii?Q?1DGrX0NredDuPWVr9sXROf3TN3b1W9Bsx5VxpICfKbpwar8NvPixwEPiGp3v?= =?us-ascii?Q?DjNh2zsxGWwy2eazFWmseTtYfXH24TeqU4Ix7AYPflSufE0vqdtx15+EG+eH?= =?us-ascii?Q?3llyfQwjOjNvBgVeFtrs8wrbaUjgMRP2wBD1XEKlkiXQoscsxUjSihZZyuCt?= =?us-ascii?Q?4asknbBlaBHt1tn7QFcsz8B7XqtcrzxkIyUHMtJamX9aWhbtR/krPaARLEGS?= =?us-ascii?Q?u+6qppnS4qAzGlNDJu94X7uqINyZp31TRPGMoYBmCo+OqH3xq6mbBh9y+Tfs?= =?us-ascii?Q?yUaIKc0FTnDJb97po0y6tXEJPmYWbAJ8YTYiqt5tofPnCSE0JQjObHwRFvMX?= =?us-ascii?Q?dEgC4YzeVXwf66iaPvq3NcoxKgu5pXRvhLZWK7ENdL82sxNZNJYwWWEo+/p1?= =?us-ascii?Q?4+V0VtwIKTyin/JDrAnXAppSLkbDeCLESiZYMupHam4wFF+r8U8KpRGhhJlg?= =?us-ascii?Q?3zfrdcr/UyKlVLXbW8BX48z6ver+gOn8+O5zE+JgVQcNuVE4V0QixRb2IZSj?= =?us-ascii?Q?YrKlpAdx8XsUq9fxAvxoKOwpTiXLwmsahCHp9GKFmsaJltEd6u7N/xFi+iCK?= =?us-ascii?Q?pwa7NwWw/cpGrlKgHJwqBEFilFmgYfcHeEYiEEYk4Xqli6Ys0aLJcAogLtso?= =?us-ascii?Q?D8Q7dXDS0rcTSOlKxnm81H12HViIqpPT6d2IqRRvJo0gjvzCqg67Vinaa71d?= =?us-ascii?Q?4XgMSavCsIGyXripzjlCOqVDmI9lmoTXW8dWkDj1r4fi/qIj/WFze+hZq7R4?= =?us-ascii?Q?kDhOjxJpjQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bd97cd2-afea-4fed-da6b-08df1fe3de7e X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:46:06.2479 (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: UmYQQvDPWka8iXJYOVstTVF8frjE5wfdWOu0fPDJMUzahtoKVw6EmAFZi8/u2n4qL0ykF28TdfL3jUYcw9afsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7658 X-purgate-ID: tlsNG-c1860d/1790876780-CDB4987B-B25B594E/0/0 X-purgate-type: clean X-purgate-size: 1317 Signed-off-by: Kevin Lampis --- Changes in v3: - Reduce diff size Changes in v2: - New patch --- xen/common/kernel.c | 1 + xen/include/public/features.h | 3 +++ 2 files changed, 4 insertions(+) diff --git a/xen/common/kernel.c b/xen/common/kernel.c index f4bbd8818fa8..67b56ba302cf 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -691,6 +691,7 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) #ifdef CONFIG_X86 if ( is_pv_domain(d) ) fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) | + (1U << XENFEAT_mmu_pt_update_swap) | (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 Oct 01 17:46:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:46:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438583.1657326 (Exim 4.92) (envelope-from ) id 1xCKrP-0005ar-GV; Thu, 01 Oct 2026 17:46:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438583.1657326; Thu, 01 Oct 2026 17:46: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 1xCKrP-0005a0-AN; Thu, 01 Oct 2026 17:46:23 +0000 Received: by outflank-mailman (input) for mailman id 1438583; Thu, 01 Oct 2026 17:46:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKrN-00052k-QP for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:46:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKrN-009PVE-6q for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:46:21 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe9c4d-8faa-0a2a0a5109dd-0a2a4508d8ea-48 for ; Thu, 01 Oct 2026 19:46:21 +0200 Received: from [52.101.56.34] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9c68-f659-0a2a45080019-34653822a43d-7 for ; Thu, 01 Oct 2026 19:46:20 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV3PR03MB7658.namprd03.prod.outlook.com (2603:10b6:408:28d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 17:46:11 +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.0451.026; Thu, 1 Oct 2026 17:46: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=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=pNANjimBmCqjVR2ymmRZtHfOIIrU7lWU4TKr9LwkMffbfWymlh5QCY85j4xwdiWltiFgyA2uAlwHn34461xc042ue/KE8FF9FzjcaW0Ea7TuCcBvjJQdeEJYt+MZgYTIAJY3l1SGVGlKyTxfSqTB4JjjI0Sb3yfe0fquVXxkRmQCf4zsAiObqhUspIX3CPX9/l9EZGQHx0lugXji1Jo3zej02KO8xwpUD0DCtRx9tFX2/355SpGa/5AWZ4fEx0ienw4ts5fkwdtpuLHp9nUFw3iJankxg+/fnLN6tVNdjgbQjaLA6f1Y2ibZpXJS7r9frHD3z4ud/rekPwaeNaUJHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nikBxQbmFT/YhbgKKDRdnJ8hkPNwNqLqVDmA4JG0VDY=; b=uE0qOL4EYNEKl+2fcAF2rfJPNTt6WiP/NS+ySjIZhW3h5afy05rEk5rVrzxtI34kCeKd1TBOtV5dJHv55S1VA5hxeNsECl51d2+bQJp3JwGOF321Bu5jn6efSD4Ic5OlWLZQboH2WbczybXWfBkWhtXWNdMfOPzE3qT/Z1E084IET1d8i1dT0aVIO626i0Cx/xEVYCHbUoFK8WNVbdQPXAPM9EFtqiYUvK7OYB9B4ef/wV1QiPy8YgEi3Fkp/cULAtM0875aScOeAnBNi9U1b0cpQjVRqJkv+/HtIvTOFCuDoQIJtwMTwImlsRiuey241Ci7pboXhr0ggtPxkK/8SA== 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=nikBxQbmFT/YhbgKKDRdnJ8hkPNwNqLqVDmA4JG0VDY=; b=q6dBWKBmGOgaFmPb/5SG1ocTN6Lp/HAB8IlfupwadHWY//jx8S+eI++DvT/Icrz8Vjczx5r4ruMlByOxnbbqiKOYLMamPe8SFlcfKVryc5XVrWmaAnvmaWIvdrH6qQMDgiNpcNeUZH/AFiHuJzNKLaNewBZ+SgAQ4/eVfqBuLPs= Authentication-Results: mx.microsoft.com 1; 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 , jgross@suse.com Subject: [PATCH Linux v3 6/6] xen: Add new Xen pv-op pte_get_and_clear. Date: Thu, 1 Oct 2026 18:47:49 +0100 Message-ID: <20261001174749.2275245-7-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261001174749.2275245-1-kevin.lampis@citrix.com> References: <20261001174749.2275245-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0163.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18a::6) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV3PR03MB7658:EE_ X-MS-Office365-Filtering-Correlation-Id: 0a63f44e-03c6-4b51-f8e0-08df1fe3e1ba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|18002099003|22082099003|6133799003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: 044Kf+VW+GD9VNBsLwU29tz6oR9PKXQSt5oPd6wYhWEIn4QDDiqSJaUbzEUhw9Ze1PSzkpcKTvs+gdS/GGT59bW/mO6glg61ihfOTNJKhlmd5fSLNdk3VhnnVxLLEduIusm4uzpQ8IpY+b1dSxaxzhcvT3ORlQLH+s0thO+Fs2J4jSaXSSsMYY14AHrQSWvhH7Tw+CucOX5fOwx/8pisCdlQHPxH5gny5etA+xKdQF9Kmda+EZkSyMPlGIYDLnbKhr9QLFwbdedgPzVZC8kSrqrW/9PakZ7/6Vlv6i5YESsyfbeamMCuQhoAIzXnJ0re73V4c1KqfnmFayyZX/dmOeeErj6e8QELjLmMv6oOfz+PJ/1hU+7sjm7AzHCHGofpixQFeU/z3ptIk6wBEFpSvhX+tQj4JFs+QKZBLwlb81XGSfohui7h6a40aPIt0ydilfrk8vtDjsfXYzeOf/CT70WQoztd41KtvQjeruBqbAkXxikEM1T4SPG0aaw0bIOxzb8/KV8fEqweEajvr0xHXfQw3mpFVDrsDZHDVTl4Y8I/FvhI29LDSWaFicuYreynWUjgkb7GTMd49mT0lQX1uwkDy7A2oBcfTZbABDJe0a0psaFdV5dY4yCDKjiY6z15bNqWZGKXANQ2HBoJn8Hi6byzEvGycUc9KZ+6HZA8FAM= 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)(6133799003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bBKgxkVrQqrItj/TywxRE2DB4sw/ztjUmioH5QDEo+yZRuDRqSOIORpEdS+/?= =?us-ascii?Q?2MN2LxmzEOMBsAeE9Qbxze37DCwbMkUVbvyhrJNfHn48/aYMuvpDE7+INsiU?= =?us-ascii?Q?aC7cd7+Gs4VMopW3NLHI1xE/3LaidSjZHM5iTwVL+D2MRFzc9tBU5uTATJNA?= =?us-ascii?Q?1G8ERnDyR+Dfpzye4TqgkohvXFYomJCzD+KsjqZV1Dqp0EgxpTbS5dZhkAjS?= =?us-ascii?Q?3NVKJxPYbLSlSwuyaOmQCW8LlnpgDPxZza+10Ztwkp/z51J8PbJ3LUnFb8d7?= =?us-ascii?Q?AKa7suEuNSNxlSthypDYioQQrFbRmimVNTnPlP/IuN+uk85ZBJMcbyzpwIq5?= =?us-ascii?Q?cbkl0dOqVOZA4uKfm9w/q5TJDIxTk4aSa9G/+NLII1RI1JdW32I6DIcq0yLR?= =?us-ascii?Q?a50TP7jLzh/89X+MZSL1RWDL17tWBny6PGyNEtj59KKs/rieff8iia0Udcbi?= =?us-ascii?Q?fTm3dxzUi/4PLr52M+6W4EjUCSEHcBsZJ7oj1PU7qoJl4A2vaGUMSbrC4UDi?= =?us-ascii?Q?9RyT0Ewa+iNYw4o0GRBLvX4gwideWY0I99Bqz24Ao5fS0tVRXidKkF1jDvwA?= =?us-ascii?Q?Q71L6PFJ3VfPA92vgi0RvWpPRGX57kSQVHwDUBix1eAUWtler4S9hRpxKzjY?= =?us-ascii?Q?px3cStumWiprgS6fAHJPAB/lT04JFW6OungLHKrUlFhHzyrGTZNn05hXoV7F?= =?us-ascii?Q?9czuHivKJZi97fS4OsggUYT0uPqPTVAPqqdTDiNsI/3LZ9gsOZMlSFlgymRx?= =?us-ascii?Q?7gOneoatwisOCPYXQvLxFjkq9lM0ZVz6KPeZoIDZnrTzfJLhhR6YAhslQFVw?= =?us-ascii?Q?8xCSzCmBnr9o/fF/3McDQ57ypQIqERZER0Upcpir2U5XtzbLJoU2mwHMBt0I?= =?us-ascii?Q?tJf9WIiVDildR2IJXnup8JY738yTNKAdGrtnNx5Xv9MBiOHW8ECdiQGMvRtv?= =?us-ascii?Q?b5ExfpuzEZup3TkC04n33TZoI4CAzIlPZsTo6ogWNCx9CWcPgQZKuoO2BZwd?= =?us-ascii?Q?HlyJO3Snkz3dbDsuqLPS7fAFZeeD1T5bMiboMAuTgVA4/gAhWl8qMvMknr2N?= =?us-ascii?Q?vi92QJ/mqDL/DP+aEV3sXSm/wOZ9txbnEgjX4qSm83K7+zzYBcWf5crVjqiF?= =?us-ascii?Q?pSnYHz7H/Kr0sVtpA9d1mBMlmc6DxZGCa+WWmLfdJ3ZB1tHH0fy5cIN1UhVy?= =?us-ascii?Q?jfGKnoPx4WltxTbKd7kv3uRgmGenglikn/DgFJadYGqWH6UuBNiy6IRv8pJS?= =?us-ascii?Q?aWfmVGdnxQeY8SpIyPVK7hbjyxy9c5tKTgp1DGIonDJwhiWBaOIAt9u7P4Ky?= =?us-ascii?Q?4oMswnABNxIo7FkLqS7b/5NZwP1Wg+5vNwfSdoQ8bKn5lQpfAeyTpw2ww5mD?= =?us-ascii?Q?LR9yxIcFY2MtvjhCtsnDTiae6aJyNRAE6KWsBkq86gn101qlZ20zGrft4T7k?= =?us-ascii?Q?4Tq/OMKi2+SkI0t3+391/V1r0Dno05glXIjdDzsXir9Qc63x2KJyAz1hvzNm?= =?us-ascii?Q?+prr++JG5GzEArPYKzF89rUOdHJmItfTFK7nwJIBp+UKNEIOD4OmGoukM9dA?= =?us-ascii?Q?bSxo4gb4NH3YYXdWk6Gt7pXg8OgcZVmP+SR62rVcEDEyeCA27Q096Qv+o/k5?= =?us-ascii?Q?QFBRI7M2ZO2zhL1I4L2sA0uXB0tvPKI8fN2wFBz713IgzIrFPFCEfC5B5Pui?= =?us-ascii?Q?R78ZaUKDnvhbVdaFLBa8q+YacrDrZQVLcq1r5ONW4pWRWgCjAvFbdDj5Hw07?= =?us-ascii?Q?+0Ps9/VuhQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a63f44e-03c6-4b51-f8e0-08df1fe3e1ba X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:46:11.5824 (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: V8jMIeS9VDPLN2mw5Puy9p25TsP2+khe0VFFdsO8RRxY8pE+ah2B8ev2XUkL5a/l7AYI5yYsbaBarfaMnIbRlA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7658 X-purgate-ID: tlsNG-c1860d/1790876781-CF55C87B-D124DC65/0/0 X-purgate-type: clean X-purgate-size: 5495 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 v3: - Add spacing to xen_pte_get_and_clear - BUG_ON if hypercall fails - Remove extra blank line - Add documentation for MMU_PT_UPDATE_SWAP 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 | 17 +++++++++++++++++ include/xen/interface/features.h | 2 ++ include/xen/interface/xen.h | 1 + 7 files changed, 29 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..c2a7035b4848 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..a1e79672a408 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -359,6 +359,18 @@ 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 = { + .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) != 0); + + 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 +2177,11 @@ 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..64c120d8a100 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 /* Update and return the old value. */ /* * MMU EXTENDED OPERATIONS -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 17:47:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 17:47:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438614.1657339 (Exim 4.92) (envelope-from ) id 1xCKst-0007mC-Rm; Thu, 01 Oct 2026 17:47:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438614.1657339; Thu, 01 Oct 2026 17:47: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 1xCKst-0007m5-P4; Thu, 01 Oct 2026 17:47:55 +0000 Received: by outflank-mailman (input) for mailman id 1438614; Thu, 01 Oct 2026 17:47:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCKss-0007ki-GT for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 17:47:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCKsr-00Dr47-To for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:47:53 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abe9cc9-2eae-0a2a0a5409dd-0a2a450ab482-0 for ; Thu, 01 Oct 2026 19:47:53 +0200 Received: from [52.101.62.40] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abe9cc8-f2d2-0a2a450a0019-34653e28f4d3-3 for ; Thu, 01 Oct 2026 19:47:53 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV3PR03MB7658.namprd03.prod.outlook.com (2603:10b6:408:28d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 17:45: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%3]) with mapi id 15.21.0451.026; Thu, 1 Oct 2026 17: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=Y+Azn+hAkH4ayZAHeO3uOEKce67cW90te23kRF3QbRp1MUda0x9AHeizewMKQep/jZFDpJkyLa18WHKSOp+fkRhRAh67t9vj1f5j4Q3D+eOFcUDR0Asaspl6/EfwaZfKeCWoOlZcmWwn1ZFtcVe+pY9FHDhfd4uxVitwQWDSc7C7/GGnMcIlkgWGCySirjy/7yCcRcBuGFVpMdqH+QgJVkzr9qQEvVm9rrQDChNVnz/QO8yZQ171jgaBDD+Vqg8fuEGnsJ5NHmnj0yKCYB370f6qqqYu2+/T1f7/hssWzWZYJmm/USl7O6mC/gagAcXeddtqGU0AWLU5LxxXvPtCEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NkdwiKtK+tR0FPw7NQxvOIvKgkeU+OyZ3OFk30VN4lo=; b=ZCCkDLlHOGrHvismthtu1t55c//IbBX4VEWOI29u3+A7IaxRs1X7TGl6Gl0e3UUyESvtrxWUeRt9uwfScUxP5OEX2U6zOprxgwtgKwQGxNZiHlN5N7O8zQIeKrvI6n+uVdx+cCWYFxQK/TZ0H5zUeorR6xCT1gFEX+yZbFFpNec1hEoju33wUgCH1SlmgDnVi8KlTTG+NiAWOJ5E5S3uVWRXh1t1E2WCwyJB4Buo6R1IUjLxlusoDmr7l/9blWwKq3OBbCVqgXGyoPrIdv/ChdGO8V4e/vQeX7AZY6/uqpaZm4K3hZ+mR/dKtrolc1NP0p/++/OAQb36D3arAmwZKQ== 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=NkdwiKtK+tR0FPw7NQxvOIvKgkeU+OyZ3OFk30VN4lo=; b=QmjBanjFylaAyUXOK3s9roscbrH7xmrpkjYoh5nqkNsWpwwZyQbuMCsGzgHWFjiNYDqb430XvuXb3ZWNcxgD7Ggtk/jsCudOGrNiJ+xjYOu75X0XC1TpSAwmEiAoFQ33/c/NyvhTO1Yaw2OYmoGuLD2NvfdlBE7zCJNtTw7MLjs= Authentication-Results: mx.microsoft.com 1; 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 v3 0/6] unmap_page_range optimisation Date: Thu, 1 Oct 2026 18:47:43 +0100 Message-ID: <20261001174749.2275245-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO0P265CA0001.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:355::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_|LV3PR03MB7658:EE_ X-MS-Office365-Filtering-Correlation-Id: c68c9d13-0e0c-407d-a838-08df1fe3cfed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|18002099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: uNQRm6aKWGUkwPz7pSsKZALEjaEJ982+lw3sjbgS75XSbg3a9ZQvzz2lc0uy414ARJuaqasfTVqHjxqIAyMq73PwTVv7c4fcNyI00M7uk6YZuOamVyTLGOE5FrvzaVwTn4wqyLDxzvQWTj4dnpVdLx+32R9prJ7LcutfJ+/TEeqqSC2wR1Ih/ycJlIANd9N+HZ3vK84EdO7Ywix+4YXheoW1Yl1NiiF/NyxgLIJFxlwE+JRAcV8YIzc0SIO4gEL+69kv68kBlWePfPGBUUFT0svHc+RdgMTYqvGNMe9JJNIHbQlvm/rjy0qnjvx2VZXa2FVNpSsk1kCbEoFgeIrrcEsqVOVI5iGB77Q/SpXoytyhvPcl55U1JqIGOcLEiRlQeLvhozznzqTwtk+Dc4hOO2bDgFEDj1vDdOZAwZjB0ljcCS71VqCSGvKBkdQI97Ociad5KQ6gDjV9aO0x8R+UshWclww0AYAbhn+uIaVTiqcB1dzWAiT51s9Rxr9Ysmlo++jOqrIRYlRiIZSgKVlJOP6yVJerhh4qau9e8tqBl73q22NC7at2MFSd5aqpR97kihW0aaL+0Z0wFQeb08/2uwNx6CCzy8bWeX8x0xk7K6QhEur9WhXvpPHBYxDjn3t3FU6/HigaBDs+MfCJCu8IP8AnhOzaSBTgU+kkHmAVALk= 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)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?mpja5antczOlYbEEHtLNGON1+MTXUyQ4BFYsNbZxxiNHCCWGsjj7lnr/7N/x?= =?us-ascii?Q?ZC+jLiDPUfBhDAZ/Hzqla3QdeA9QlC5nT2MTWPy8WxGOyFEf4zJHpQt4xJ9k?= =?us-ascii?Q?Vdgyc3kscGS6fpfVrzBv9xi2R8OymPyhazFwPUatwNfbF+IBC1LVMaxf9AXr?= =?us-ascii?Q?/NqD1Rb14jCg+YZgTYhF2/3rn6OBZSteY7lCfWEN4bbSUst3n7jIR+wdNrpQ?= =?us-ascii?Q?7ZRUBpgC0XWxqH2uDBq2KCzyFp1ny+OAPPkk9iN8laZI+TdQGbMti0/bz1+T?= =?us-ascii?Q?owrg10q7GtDTxbDTIWre31dVNRUVsFeD2GnckwTN5/RZ3TI3baT8UGKfIiZv?= =?us-ascii?Q?ZWGHrdhuQ4g4bYT6Rshl06Bxg0mMtKlUGPQ3y9WzK2OESgWdVYn1CQUi7QNG?= =?us-ascii?Q?vdkBVV7pySmqOxVLPPxMqiiIOuNOHu3nsLr8LvnfcrC42XNzdD7bddUS+o6Q?= =?us-ascii?Q?hHahGJ4xEhqSEdBzntpLBkP9Ym9wBaQKC9QoFAuZ0Bp1iLoEAUZ7DwHu2/Nu?= =?us-ascii?Q?IMkjvSayd0nbk+J/qJO0YhdBqS+rfrNCBuUbFqBoVq685qtcZfUHoly3Gw8f?= =?us-ascii?Q?Xf9UuSslSRtbJihReYhDIb/YEcPTN0AfYBYnXsODVjIlWFy8ymxpHXADKGFy?= =?us-ascii?Q?vo5FQCaZQukfdhPkh6Nh1huiVU9gUdKRQ1LV0sV1ObrNKS6pFLKy/Qx+5yo8?= =?us-ascii?Q?vLQeWywCEkX5LNWKHxyJ0WJ9DsCUQmaYstBDNCUIwCjR3f6xd+VurJYe1FU/?= =?us-ascii?Q?3XPobDUlqNZ3KRve9ebvA+Wn13J2w7M31Gp4w9QuvcU0X24y22mjQRhzCKBR?= =?us-ascii?Q?orCUlQZpHb9otyEimWIm0M+Nv9Br4gtUGpxPY4088GrrJKaF80K4+ZfjwoxC?= =?us-ascii?Q?5jps0tMaMeTm6+jDYd3IXAjaxJ6MfebJA+yWwrw5PDv99LLuWKUjDTQDVKWA?= =?us-ascii?Q?haAR1eHHZUUZZDtKLKrtc/NNWaRHyWyRL1Jy3b39AGnMBsTLutZNDidYoZyL?= =?us-ascii?Q?+iCStcfTU6gO2dcwZnktV02E6DMeP/gejfxNPWCxp9jGccEtO02JiphjWJNN?= =?us-ascii?Q?JROWaecSjI6ygH3BRnVP78NlAwah7P+J1Gv6PcUPvW8vJuwvB9Q0DlEIKNrW?= =?us-ascii?Q?IylzBgdD2EQnMdqOiuFH+/w8CfeawweNDrPFBDIz5JR3kIFj9nqav6gdKBdw?= =?us-ascii?Q?CIvnne28kClmVKRUMAWgNpQj0g4zuPJVSZHVenqdZylKc0p5kfkSqjUugsnV?= =?us-ascii?Q?HU3fMDyp3XmCH4UOV7mdCeU8dm4ZOHZWL9MzWVv0M/KdnFfHYEmKoxC9A1jo?= =?us-ascii?Q?p8DysHTP7z7pd18Ide/rwQl8+1T/oo3f6+oANPbQbxVg5JRAfJMMJ40yCD+U?= =?us-ascii?Q?SlyW0gFy2QKEZDVikxD03PkT6s+HHkakDYdF9tb1HQ+ISxy3XsiAwj1T9ORy?= =?us-ascii?Q?12T0N73WX0UIEZ8K/0MarCyiZqv+kO0jMYk8LY2vw22lKFQ3oHCnz0Dyq1co?= =?us-ascii?Q?EQiMt+6wQxouxp7NyA/F5SMEVC03STQ7VHVxMzsNDM6UYFCUgrmp4KXLL8X3?= =?us-ascii?Q?J/zbt0OLPDKSO+aLA+MhBOrgQFJPsh5VnVHluy623aPih+ENTkekC4hlObDB?= =?us-ascii?Q?mb42vRAuRpA30ZjhnKu+pxHLpnohWZtNcanIkHsKDiny22TDPXj3kRmG3eMz?= =?us-ascii?Q?1fXpC1H42qqEKRYhUH9D0ZgP9wGYKFvPSB95pyA5J3vF9F+pHOQMqCK7FGG6?= =?us-ascii?Q?Cr0Lwt9KTA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c68c9d13-0e0c-407d-a838-08df1fe3cfed X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 17:45:41.7376 (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: eJR9IeU3Oz7SBhpqi1thNexUNIVUIFq4hncnw2ZR6L++IigYuV6fVQx4/yEFJXEEjFxbGA+vAGycixoMQY767Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7658 X-purgate-ID: tlsNG-4011c0/1790876873-50ACCCFC-646298FF/0/0 X-purgate-type: clean X-purgate-size: 3276 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 v3: - Extend swap to work with l2/l3/l4 PTEs and any value not just 0 - Other review comments 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(); }' Kevin Lampis (5): x86: Remove return value from UPDATE_ENTRY x86: extend update_intpte() to support atomic get-and-update x86: extend mod_l*_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/arch/x86/mm.c | 215 +++++++++++++++++++++++--------- xen/arch/x86/pv/grant_table.c | 53 ++++---- xen/arch/x86/pv/mm.h | 32 +++-- 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, 208 insertions(+), 102 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 19:05:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 19:05:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438699.1657356 (Exim 4.92) (envelope-from ) id 1xCM5w-00023Q-F3; Thu, 01 Oct 2026 19:05:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438699.1657356; Thu, 01 Oct 2026 19:05: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 1xCM5w-00023J-Bv; Thu, 01 Oct 2026 19:05:28 +0000 Received: by outflank-mailman (input) for mailman id 1438699; Thu, 01 Oct 2026 19:05:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCM5v-00023D-BA for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 19:05:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCM5u-00FPDP-OM for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 21:05:26 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abeaeda-2eae-0a2a0a5409dd-0a2a4503b20e-48 for ; Thu, 01 Oct 2026 21:05:26 +0200 Received: from [74.125.225.99] (helo=mail-wr2-f35.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abeaef1-fae8-0a2a45030019-4a7de1638482-3 for ; Thu, 01 Oct 2026 21:05:21 +0200 Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-482f63546c5so6094238f8f.2 for ; Thu, 01 Oct 2026 12:05:21 -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-48b38306dd4sm204087f8f.43.2026.10.01.12.05.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Oct 2026 12: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=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=1790881521; x=1791486321; 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=FIVa2PiOVK72PchuP6HMQQz39IJEJGCAfEAUandj3qM=; b=eJr5z3JFWqGCG7oVn8qXNLsmU399LxlcSbrrnMggrGXziJrZOsqYV9EA9wWILl/rof R2TLKHQBxEU6tgWhR6TvmTa0L7top14acDfU+DZP6K3/jPEjvoGvnt7g7HMhlAqwsOPM fDM8dtjA6mSuE92D3AAy9rtLsS3eU3aJNATIo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790881521; x=1791486321; 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=FIVa2PiOVK72PchuP6HMQQz39IJEJGCAfEAUandj3qM=; b=cbi45I/7tmBVPoOrfD+9HS+jUwd21viT6bM85rFTx+amJ4jk+9kkcPy53+Cqh1swnz a/Tzz6Wsun0xmLSMmmZH56aCuDU3amgZg724NZtxT0JfhGi8jXfFkzBr5DmEl4k1pzp5 utaUO8EBOQs7Dd0WhsP+9MrHZCEzC+rfZeXOBaK+oiq7jJsa5VDPNj4/KF4Jr6nHLkl5 cNdj9DHDRXKPXWrFHRkCiNCEKuiWFqT/C7eumFEWbdzN/FUzKgrvmnGCUAxvswldv4gC ONQf5PLqyZ9kO89T7ShAUZD+xDfJgAyV+4lBoY0d2nhFFs0XJPuRNHW/fqRSAF4IafeJ 6Cmw== X-Gm-Message-State: AFq9FYLmFhd19xZ0K30CBVP4cJGSrQo/PlNLQUNRMTsIxff1vJIjNCGz 9wQGTxi9MSddr12la1q3qagb+wJsm4saozNu7GNtffspFi40dctrKXL9wwiK9PiiPnTnH/p8MwE vjKRbW1I= X-Gm-Gg: AYBFou2qbRo9K+sL526jNYJnS1qs0akVIEp0fghABZhYDZmJ3XynLDnsr4jYPtOtW06 OlLCPh1tQlOv5vmBPt/uIfsVCM0KpmKRNhuDZH+0GOyfIot1qcpWVaBJkRX6MmavrJDcPHjXHo+ Xl06ISmbl++BSO3VZ74tL2P7W29d078P6fK5UcndGbiBQeYLXC0rmheF9yCZgs/jAFr706NGvUD Z403486qJTuJ1aUDJ70K5XdVb96BHFDTm6HAfQpj0soQDpEP3p/U8Pjj677/HdfNzw5vFRXI43C iqHYo+qcXlgq7ed95zcmaTyDlv/1mhURZzsHEOZPfsX6LMVw5XRIkT8TJqNEMOfEdqJvjkXr/ux Q/H3c1ZhoScfT/5to277RmHNirBmD8C+uUJ5ImNYBxVLQVxLTL0kpr0G57OmZp1AQ556WoWwa23 f+zyEUqVDKxciki+sbdCtHapN51sGpPfBh1wqUdUIh/h7bDM4qDP1LpYutXdke4yLRg9CFbMSRp Jjvd/7JeJfMaYnshPKyXzE+1Su73hjGK4VchnjsSKMAFgot X-Received: by 2002:a05:6000:4694:b0:48a:fbcf:6f43 with SMTP id ffacd0b85a97d-48b1276e0d5mr554389f8f.54.1790881520893; Thu, 01 Oct 2026 12:05:20 -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 , Doug Covelli , Sean Christopherson , Paolo Bonzini , Borislav Petkov , David Kaplan , David Woodhouse , Shivansh Dhiman , Nikunj Dadhania , Santosh Shukla Subject: [PATCH] x86/svm: Work around VMRUN's corruption of VMCB.INTR_SHADOW Date: Thu, 1 Oct 2026 20:05:18 +0100 Message-Id: <20261001190518.438643-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/1790881526-76CF84E9-72E7AA16/10/78276251493 X-purgate-type: spam X-purgate-size: 5580 I was asked me to explain the comment beside STI in the svm_asm_do_resume(), and, in trying to do so, things unravelled. The original fix inherited from KVM prevented the guests INTR_SHADOW being changed from 0 to 1. This prevents undue delay to interrupts, but it caused the value to get changed from 1 to 0 if the guest was in an INTR_SHADOW. Whether this matters for IDT guests is unknown; it depends on what else VMRUN can do beside event injection and still write back the wrong value. This does matter for FRED guests, as INTR_SHADOW is exposed architecturally in the FRED frame via the STB field. Fixes: c989ff614f6b ("x86/svm: Separate STI and VMRUN instructions in svm_asm_do_resume()") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Jason Andryuk CC: Ross Lagerwall CC: Doug Covelli CC: Sean Christopherson CC: Paolo Bonzini CC: Borislav Petkov CC: David Kaplan CC: David Woodhouse CC: Shivansh Dhiman CC: Nikunj Dadhania CC: Santosh Shukla AMD have confirmed this is broken back to at least Zen1. Hopefully an erratum will be issued. Slightly RFC. I don't currently have a Venice system to demonstrate the FRED part of this. CC-ing the KVM folk and AMD FRED folk too, as someone will presumably want to adapt this fix. Concerning encrypted VMs, there is no fix; INTR_SHADOW is encrypted state which the VMM can't access. --- xen/arch/x86/hvm/svm/entry.S | 40 ++++++++++++++++++++++++------- xen/arch/x86/x86_64/asm-offsets.c | 9 +++++++ 2 files changed, 41 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S index d9613a2a8fed..99a98050793f 100644 --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -57,6 +57,37 @@ __UNLIKELY_END(nsvm_hap) clgi + /* + * Interrupts need enabling prior to VMRUN. Anywhere after CLGI is + * safe. + * + * On all Zen CPUs to date, VMRUN has a bug and mixes up the host and + * guest INTR_SHADOW state. If there is a VMExit during VMRUN + * (e.g. taking NPT_FAULT during event injection), then the host's + * INTR_SHADOW gets written back into the VMCB, corrupting guest + * state. + * + * This is believed to go unnoticed for pre-FRED guests (injecting + * events cancels INTR_SHADOW), but FRED changes this behaviour to be + * able to observe and restore the shadow via the STB field in a FRED + * frame. + * + * In order to fix, arrange for Xen's INTR_SHADOW at the point of + * VMRUN to match the guest's INTR_SHADOW. This way, if a VMExit + * occurs, the VMCB is corrupted with the "correct" value. + * + * Commonly the guest will not be in an INTR_SHADOW. In this case, + * execute STI early to get Xen's INTR_SHADOW over and done with; the + * second STI does nothing as INTR_SHADOW only occurs when IF changes + * from 0 to 1. If the guest is in an INTR_SHADOW, skip the early STI + * so the late STI does trigger INTR_SHADOW and cover VMRUN. + */ + mov VCPU_svm_vmcb(%rbx), %rax + testb $1, VMCB_int_stat(%rax) + jnz 1f + sti +1: + /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ /* SPEC_CTRL_EXIT_TO_SVM Req: b=curr %rsp=regs/cpuinfo, Clob: acd */ .macro svm_vmentry_spec_ctrl @@ -74,19 +105,12 @@ __UNLIKELY_END(nsvm_hap) ALTERNATIVE "", svm_vmentry_spec_ctrl, X86_FEATURE_SC_MSR_HVM ALTERNATIVE "", DO_SPEC_CTRL_DIV, X86_FEATURE_SC_DIV - /* - * Set EFLAGS.IF after CLGI covers us from real interrupts, but not - * immediately prior to VMRUN. The VMRUN instruction leaks it's - * INTR_SHADOW into guest state if a VMExit occurs before VMRUN - * completes (e.g. taking #NPF during event injecting.) - */ - sti - mov VCPU_svm_vmcb_pa(%rbx),%rax POP_GPRS skip_rax=1 /* %rax restored by VMRUN. */ SPEC_CTRL_COND_VERW /* Req: %rsp=eframe Clob: efl */ + sti vmrun PUSH_AND_CLEAR_GPRS diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c index baf266ab8013..4872ef89b0df 100644 --- a/xen/arch/x86/x86_64/asm-offsets.c +++ b/xen/arch/x86/x86_64/asm-offsets.c @@ -21,6 +21,10 @@ # include "../boot/video.h" #endif +#ifdef CONFIG_AMD_SVM +# include "../hvm/svm/vmcb.h" +#endif + #define DEFINE(_sym, _val) \ asm volatile ( "\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\""\ :: "i" (_val) ) @@ -133,6 +137,11 @@ void __dummy__(void) BLANK(); #endif +#ifdef CONFIG_AMD_SVM + OFFSET(VMCB_int_stat, struct vmcb_struct, int_stat); + BLANK(); +#endif + #ifdef CONFIG_PV32 OFFSET(DOMAIN_is_32bit_pv, struct domain, arch.pv.is_32bit); BLANK(); base-commit: f9b72572c8d5b6d312fd0b5014f65bed20efac40 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Oct 01 20:59:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Oct 2026 20:59:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438755.1657375 (Exim 4.92) (envelope-from ) id 1xCNsA-0008Mu-Ax; Thu, 01 Oct 2026 20:59:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438755.1657375; Thu, 01 Oct 2026 20: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 1xCNsA-0008Mn-6z; Thu, 01 Oct 2026 20:59:22 +0000 Received: by outflank-mailman (input) for mailman id 1438755; Thu, 01 Oct 2026 20:59:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCNs7-0008MO-Ow for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 20:59:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCNs6-003yEJ-Ur for xen-devel@lists.xenproject.org; Thu, 01 Oct 2026 22:59:18 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abec945-bab6-0a2a0a5309dd-0a2a4509be3c-48 for ; Thu, 01 Oct 2026 22:59:18 +0200 Received: from [52.101.46.5] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abec9a4-be1a-0a2a45090019-34652e0556e3-3 for ; Thu, 01 Oct 2026 22:59:18 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5911.namprd03.prod.outlook.com (2603:10b6:510:37::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Thu, 1 Oct 2026 20:59:14 +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.026; Thu, 1 Oct 2026 20:59: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=HyJ/jCsLF6lYLLgT+vSQOZvlc4+PPDzAxr3KIxSHTHm/gD+yh2QVSrgjXCybwEcdGgHek4KEOfGWPMuz+Z0cd/FxKOThOaB7hzDKfHSgRxLFW3CnrZoxKXb/mu2D5ConzrQCBxMmG1HLy1SG/Voafk9BODQSRG3O7urxKB/TKoD6gCZCzBFEzc6cyIsCeXs9aJb7q9wwf3cdDEAMj5bz6tVxoFSQDXeKfY1pqiE0ZRyMMMDYFa/hQv/GaO5L46GnNnPZOU0xJx9r/7tVJxmQljDCbwlbZCIxBss+r9qfU/qVIvSxNkAQIFFP/Yt9ZsVeTmPILnPzHlTP/j0ACy7Hcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JPJ7t+yR5ONQMQZP8Fh/cTjH2eMlapzttNVyCJnt/pI=; b=VhWqc7S0npbuREXHyhlov+mkqQebmiqkdJWaA5J+JO6VK4zGS31xBUTzhEkSdxOgM+CUyU5b+GVoMEu4czAzvhiTrkHwNACOx8cvxQhpdt4u4XXoTdj3oQJ0oet6zu0BT0xsjr0kgM0GLk0rxt/YVN+vD8rn17IZfkFjLX8k+C8xsDPVMDJZjhNbdjfvxiRcCe4HBkKNAATkKOPgpZaNJjQq1uO7Kw6dSPU/qBMCc5UjHxEhChad3Rdl+WQgHtFRqHW5FzpxpHlUtGvmyM7BjtDL3vcvWM4HaA8WSTPjAaxfse4RFeOK4krUuDyIqEkUiIhDEMEBS9L094kP2QEuBg== 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=JPJ7t+yR5ONQMQZP8Fh/cTjH2eMlapzttNVyCJnt/pI=; b=D4B0NR+5oGt/DCZEy/D2MgHOLLeJcxO2J5WT7/lHnJXXEYWYz+phK0jFAJyPTCkgVSv8r5qp4mGtAIh+Ng6IT5Q+jWqUzfiiCvvCmjA5x0L3us7xfcvdwoRsJppde965OospKTt3iDqKMdZe+zIiy9VK/HPoRu+Rza5VVl6QIjA= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <466c7fc5-521b-4f09-9ebb-0fdaa1f39a5c@citrix.com> Date: Thu, 1 Oct 2026 21:59:10 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Ross Lagerwall , Doug Covelli , Paolo Bonzini , Borislav Petkov , David Kaplan , David Woodhouse , Shivansh Dhiman , Nikunj Dadhania , Santosh Shukla Subject: Re: [PATCH] x86/svm: Work around VMRUN's corruption of VMCB.INTR_SHADOW To: Sean Christopherson References: <20261001190518.438643-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: LO4P123CA0262.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:194::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_|PH0PR03MB5911:EE_ X-MS-Office365-Filtering-Correlation-Id: 59c9f77c-39ff-40bc-20e7-08df1ffed9c7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|23010399003|6133799003|10063799003|18002099003|22082099003|10067099003|3023799007|4143699003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: feO7cpERaWBRjBGuyCkborMi6x/ph3kIKRwOVTf2TYVNvkL5dW0pqQmWuBboPIffeLrKH4QYr/RofD0usRDyhi8HFrWOkqEPhkznY49QP9fR8sOOmwmOAdpm9vm1oHU2Dp9cChPVEg2i+jg4OSh+wnHr2n/+naT+rZSfykbAefLDduzQxLr9GpHn8uVlgeENz6dRHPzJFeGx6kiDGs0Jr7mezq4VTGnCzliDdmZTFtWhdxrkV6OqQbEvmllcq0lvcIGsAp1ZGNV/Ic5cDMt3wjwPmTkRcdW/eZ4A26RoGafcR97lxZl4ga/EMROEhx7OV0un2q/IBZWbFkODkquDmyXle+w1bD6AVCRTXO7YK+EqfV00OIt6Dvd/F6vX3TeBNg8SHuq87AHnMFvJX23yzaiv9MhxQ0YfQKjrsMRxLIrE5Gs5jQyyXsrAaBxEriA2zvuugjJ69/btj7WG4tYZ8R+3fexmDYncqu5xPgqH+HHG1c48FOFI5m04Dtq6kjX/rPJAVND0zWO/aBlxZ6Icm4xh/z6K06evsnx/82ooQw4Btavuh6Mms00600mDB3feHpMyw3idKexQlfLYVSyXZ8ghG0eMx7LAoXXHrVyQNhsKvaAiFDVJ6PVskDje91dxC560AMSOj75PmDwZTAs6njsuRnYh9SJH23TVI7Q0HR8= 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)(7416014)(376014)(23010399003)(6133799003)(10063799003)(18002099003)(22082099003)(10067099003)(3023799007)(4143699003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UGg0UFczZUJqUWlZU2pTbFFFd1p6ZmxPeXRYWkhUWDlZSzMzQTlBUC9qVDQ4?= =?utf-8?B?ampZZUhsY1BIWGMyUlFqS01hcjYwL0hqT2VqZFFOWUduREkvQ3Ntdk9KNU5x?= =?utf-8?B?d3RTVktMY0xPYzlyWnorVnpwbUlSdWdzbnRXRXVpUU8zV2RmQTBXV3k4ZFFF?= =?utf-8?B?SHIrTWZYNTZNaGFlUnN0Q1JPSGZFbFo0NXgwVzg4Q2pGZDBuaTdEWHVpcVRt?= =?utf-8?B?VEhQZDVUSHRzOS96ejdVeGI5VlA2K0pCZklnM2lhdURWZ0l0UVNtalpXMW5O?= =?utf-8?B?djE5MXdVaUZzWUhRWTBCSHVQQzlQaDN2eWQraUJ6dVdCRngrK1BDeUhTWHho?= =?utf-8?B?aTM1MHlhckhOZ0I1dkdLMDA0RkhpdnJFMEdnRW1hY1BBM1JQTTFvNlRoclBY?= =?utf-8?B?Ly9rdDQ5Znl1T1U0Y1g1OGJtUHBEL25UMzArazhsbGVIbUVMQzBZa09JanhD?= =?utf-8?B?WjJYVllMT2VvbE4ySldRNnZXcGZQRVFLYkJoUFQ3M25sa3pSU0NzQms5dERM?= =?utf-8?B?R2tLREVaZy85Vmx0OGJRTktwQ1dweDU3Y2IwTm1PL3dBaFQ4VnVoSy9yTDZT?= =?utf-8?B?ZU5xNjRXOXUwS25ENW8vdzZ2Z2JuSCtoQ2JzRGpST21uNjUvaStVSm5QS2cw?= =?utf-8?B?MXBHWFdBWXcrS3UwT1NibDRoTlNxWFNNOVFoVmJQVzNSR2x6MkJJaEd3Nnl4?= =?utf-8?B?c0JyMVhZYzNlamdBQkZqL0FUM29KS0lWeTVhRlk4clVlODdvRW9Kam9JVVJP?= =?utf-8?B?dmpZekJLakdQTEx6WERjbzIzdEsxaHVhTmNBaEdSNkpJR3Q4S1RzUUpXUk1K?= =?utf-8?B?SGpSZ2ZDc0ZheUlUUVA5VmtqUVBjOGNiUS9wMjFJbWhUWWV6eExadnRCUTAx?= =?utf-8?B?RC9aWEJlUDZKeTNCU1dyL09SamozOFY3QlYrN1UxV21wcU1uUUdNT3preXpU?= =?utf-8?B?dzdXNWdaQmpRLzVSSUJ6Tkx3ZlJVK1huUSthNVcwNFlNTmpuL2lmS0R6NWY5?= =?utf-8?B?UlEvYlNnZlNLWmFFanhQNm45RFBlK21FMEtnOGRuaGh1eTc4L3ozVzc1SHE3?= =?utf-8?B?bDZ4djJJczNIRFhiVTEyWkVhRlZBZG9pdHg1VG9DNzlSLzRaT1RPS08rMGNm?= =?utf-8?B?TjNHU0QzU0FMUU01UjVFSERxL2ZWNVJUV3BUdGltaXp3eEJwZWFpejBETGt4?= =?utf-8?B?YnRWc0RweW1OT24yc3RMV2VKOVgyajB6bDFqZm05MUVnZHc3b0JQVHpOTUE1?= =?utf-8?B?THJGL1MxaHVKL0JObzBMQVJlMStHUktqOGtzNnZId2svYXlab3JqYkJmOU1G?= =?utf-8?B?R1lIZjNsQ3hXR1VpNUpRa0ZhdzlVQlJyMDZ4TTRNMkZvamdvZXhvd284L25Z?= =?utf-8?B?SVE5a1JMeGIvblI2dGlNN2d0enpsclFPelIxWWdxWWRjUFZBRG95VEJiQ1ND?= =?utf-8?B?MUtocDg2dFRqTStkSXNDek4rT0pOTXVmdUJaTWZNVlBFdnhUM01xWXZ6QWpq?= =?utf-8?B?Q05aTHE5eTFEZlMwdGN0bzlIQVFLa3VzVGhsRXprUFhCckpBbnNIS0ZFa3Vq?= =?utf-8?B?Y2Fkb25ZQU9SLzkxWHE3M01GekRGdFpMSXBJdks1dS9seUFHajhYOWZFNGM3?= =?utf-8?B?TWdNNGRhMDZQeTAwbkdWL3I5MzlENmIwcFpha0xOKy9qVlpOeHAxM3REMTM5?= =?utf-8?B?YjVFajBlaEtpVWVNZVFTWjVlV1hRVi95dGZZM2tKK2E3VFIvN1RCN202SjJZ?= =?utf-8?B?U2NSd2dJS0QraVFXenIxTWdXeHpFL0Q4MWQ5OUE1Ry9uVHdhRE8wRmFaeUp1?= =?utf-8?B?WDQ5YTJxbk9WOUFUekNzUTJaZUh4K3F1SEt6YUFtMitQVzY4cHRwODhGMHM0?= =?utf-8?B?SlJpQkg0Z3ZuYmszUjZxeERJbUlkcWF3UmFtV1QybXRwc0FTR1RhcFdMeVVt?= =?utf-8?B?c2ZCekVySXd5VHMzR0p0MmppbVY0YWE2ak5wVjVFUGxYRmprTEpVVEhzb0VY?= =?utf-8?B?eGxGS1U5RFRqcUd2R1RWLzFnSzkxWDc3NHZnTnhaTTd4SVIyYWlSY3ppbmkz?= =?utf-8?B?VHlMVW1OdGpmQ0cxa1B5dzhvUElEY0N5Mmd6UVJlcHB4dStCSmdLMnZrbExM?= =?utf-8?B?Q2liK1M2bDM3L2FpdVdONnRXOXpyeXJVSjlkNVdla21EWUsxbGZyeUlwTFkr?= =?utf-8?B?R3RGUk5ka3RHVGlhTnc0QUhWZGpBT1ZQTElUZ1BvZ055cDhvQzFReGtBZlJ6?= =?utf-8?B?bFg0ZWZoMFBuZFpEZTladmVMUmZKei9tbjBBOVNjTm1DT3BJa0ZLVlEvUWNl?= =?utf-8?B?VHRzRHQycGNGa2QzWXptaGhTQjdQOUJGT2JHcEM0RHNndGp3QUNDUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59c9f77c-39ff-40bc-20e7-08df1ffed9c7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2026 20:59:14.7340 (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: HlldLRJ5aOBJJPawaMS9Ue4o28FQgIgLzDKuZixR+ZeH7MH6sCl0AzD+pujSqDgIc7k2VCntyNhQEKKAKhWuGhPwoxaHsVKy2SJaS9z6zA0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5911 X-purgate-ID: tlsNG-bad1c0/1790888358-BC2F4034-C0779814/10/78276251493 X-purgate-type: spam X-purgate-size: 3272 On 01/10/2026 8:49 pm, Sean Christopherson wrote: > On Thu, Oct 01, 2026, Andrew Cooper wrote: >> I was asked me to explain the comment beside STI in the svm_asm_do_resume(), >> and, in trying to do so, things unravelled. >> >> The original fix inherited from KVM prevented the guests INTR_SHADOW being >> changed from 0 to 1. This prevents undue delay to interrupts, but it caused >> the value to get changed from 1 to 0 if the guest was in an INTR_SHADOW. >> >> Whether this matters for IDT guests is unknown; it depends on what else VMRUN >> can do beside event injection and still write back the wrong value. This does >> matter for FRED guests, as INTR_SHADOW is exposed architecturally in the FRED >> frame via the STB field. >> >> Fixes: c989ff614f6b ("x86/svm: Separate STI and VMRUN instructions in svm_asm_do_resume()") >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Teddy Astie >> CC: Jason Andryuk >> CC: Ross Lagerwall >> CC: Doug Covelli >> CC: Sean Christopherson >> CC: Paolo Bonzini >> CC: Borislav Petkov >> CC: David Kaplan >> CC: David Woodhouse >> CC: Shivansh Dhiman >> CC: Nikunj Dadhania >> CC: Santosh Shukla >> >> AMD have confirmed this is broken back to at least Zen1. Hopefully an erratum >> will be issued. >> >> Slightly RFC. I don't currently have a Venice system to demonstrate the FRED >> part of this. CC-ing the KVM folk and AMD FRED folk too, as someone will >> presumably want to adapt this fix. > I wouldn't say I "want" to adapt this. :-) > > Thanks for the heads up, and for the suggested fix! You're welcome.  After all, I did stea^W borrow the fix from you last time around. >> + * events cancels INTR_SHADOW), but FRED changes this behaviour to be >> + * able to observe and restore the shadow via the STB field in a FRED >> + * frame. > Hmm, does that even matter in practice? IIUC, hitting this would require taking > an exception in an STI shadow, which would break pretty much any software flow I > can think of that relies on the STI shadow. > > E.g. IIUC, STI->HLT with a #PF on the HLT code fetch would break pre-FRED because > HLT would execute without the STI shadow. Unless software quite deliberately does > things that only work for FRED, I assume the entire thing is benign? STI; HLT vs #PF was fixed very intentionally in FRED.  In other news, Windows pages out kernel code, and uses the STI; HLT pattern extensively. It's not just the #PF case being fixed by this.  e.g. Instruction breakpoints now don't need special casing in FRED either.  Even if we don't see a need today, it won't be long until OSes will be expecting to use the niceties that FRED offers. The unknown here is what besides event injection also triggers this bug in the VMRUN microflow.  I've not had an answer to this question. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 02 05:38:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 05:38:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438845.1657383 (Exim 4.92) (envelope-from ) id 1xCVyh-0001RU-I7; Fri, 02 Oct 2026 05:38:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438845.1657383; Fri, 02 Oct 2026 05: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 1xCVyh-0001RJ-D9; Fri, 02 Oct 2026 05:38:39 +0000 Received: by outflank-mailman (input) for mailman id 1438845; Fri, 02 Oct 2026 05:38:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCVyg-0001RD-GX for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 05:38:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCVye-00Big9-5I for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 07:38:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf4353-bab6-0a2a0a5309dd-0a2a4505ecdc-10 for ; Fri, 02 Oct 2026 07:38:35 +0200 Received: from [74.125.225.98] (helo=mail-wr2-f34.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf4358-4cb1-0a2a45050019-4a7de162b60d-3 for ; Fri, 02 Oct 2026 07:38:32 +0200 Received: by mail-wr2-f34.google.com with SMTP id ffacd0b85a97d-48b017a3be3so2119687f8f.2 for ; Thu, 01 Oct 2026 22:38:32 -0700 (PDT) Received: from ?IPV6:2003:ca:b707:3710:a919:1c08:7b2a:ed1? (p200300cab7073710a9191c087b2a0ed1.dip0.t-ipconnect.de. [2003:ca:b707:3710:a919:1c08:7b2a:ed1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b82253e6bsm2630409f8f.6.2026.10.01.22.38.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 22:38: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=1790919511; x=1791524311; 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=/+yErKg9Mk45ysFIhZ+syuHKl3mM6aXAzL7ppjwokwY=; b=RYP6lUysdiAlvTxeosbLHm+bWbgOv9Q3g2vWQTWMAV/ESsGl3rDiuaM6GlDXh6GLZS Zp1MwfgSNxNMbOeu25Vh2oEmy6D58wnDnIsriwDt14KvsKidrL9AV5hOOgu56xtAaDJX lXPtREhQI6NiuA7zVEUnLWK7EVEbbpjtBQLC1QTvadEO/jv2mVJn9AtnTQ4HjwQjmABF 8UonN7NnpxR8AZluyrSkVMClGRvOMMWxLZgoU9pI0cLPqbRjCPr1gChoFSTUkRyNpiVc zLhBnc6sjuv4y1WC86nOOv49DjElPdzz7o27xaKl9JZyoe2G9lh3y7qRVr9dBck5Anig SNZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790919511; x=1791524311; 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=/+yErKg9Mk45ysFIhZ+syuHKl3mM6aXAzL7ppjwokwY=; b=FOs4flf82zq7xLzY62uekLZ2wtUO9g6+TIM2IHlC3QDZw7/TKH4zkV6Igo2tOJknQp NaCALlRrT6ErYbJzgLXMeYgdAbqeGv6DtTfKB6UPGfW1jsZSQSByQM+3A5/87GoUORl1 ddPvwR6wFXwh14dZupZ8V4GGE096liP3ZcM2mSNZYK8dmN6FOWDh6XEODYfbdWSf1349 amk5JQ/18IXn+m9Xv62PJNbXiwO60zSk4S62QWWFMI0Ax/BV/2znL17FYclram/drmC5 iTmbrX+2ZSUC2yCgixKR1DHit+XFsZdnFbVIIfLo2erhA5gOjed2P32qBoC6fhSlxN2w Oy0Q== X-Forwarded-Encrypted: i=1; AKwUvByTH1ZeDLJCKdc17rCDtlXDyzuHZ0YUnpvRtTHAjHRXpS2s1XX1rpdrE5bZJU0+QTkN982CiwsKtuA=@lists.xenproject.org X-Gm-Message-State: AFq9FYLP1I++oUU0o1tlGYpZN02Ao4m41nWtN1C/4+lMZEBAtB1Wjz7P mjgEuPooRiDIEuykHciLhQIB+C0LZoFobm/iKkHwPKdebR2shiWcKqO41DNkxLeUng== X-Gm-Gg: AYBFou2VtJEcWM9mC8aeYiRrk3V3FlbxrCbDDAmidKyMLWLTUsam03Jbi09e4YjPoh+ /9t1F6/E6055VkjEzDyDYaW94NFtQtIhphHjkb+ScCgdhDdjFcOAUCMP5+9o6pGA+6g8DRk1gx/ Ywh1homYjr3ktjVejWSqZdl43XuMXl6s7X7rHJY2XcqeVSnUAhSY3LT6nMncz5CoGBHs2tpaif/ 7lNPJShfo9WZ1QGi+MeS1tHjhG9A/pmH1eEBU442w/Su2NzQ/0smjbbpJEq4jbK6kwLZRDL7H8f dfScfMMlUfw2VVC26TOzv35NtDekTblJ/zeU7YOh7f07XxEiJCAXJSUl45bAeHZ2abwQG0dxrD5 eotw24CSMy4qIfL5fxjDbPb/6hSxilP6nnaA6yVKdv4v51L3YRlAYrI82aNHDByQ3FsT1Trsrm8 nqcfwOLr+7E9EFWnIzEbie0uj4WVseqfnLzNFYUuJVeCV4HBCd24vvW2qvzD0F2KzL+4PozI8EG yaH6ASalQfgSXLDx8nx2a1wuNqQLOh2CUR3LCA8TmjJAZig3ZCW2tbkaqzYyVp4RyFMJu1R7sNw g3+GEg+rs8Tae54mfmln/QBogJIJ X-Received: by 2002:a5d:588d:0:b0:487:489:7af0 with SMTP id ffacd0b85a97d-48b1273b085mr2873912f8f.17.1790919511614; Thu, 01 Oct 2026 22:38:31 -0700 (PDT) Message-ID: Date: Fri, 2 Oct 2026 07:38:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/6] x86: Remove return value from UPDATE_ENTRY To: Kevin Lampis Cc: andrew.cooper3@citrix.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-2-kevin.lampis@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: <20261001174749.2275245-2-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790919512-F44A42A1-CD2FEF13/10/78276251493 X-purgate-type: spam X-purgate-size: 291 On 01.10.2026 19:47, 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 This was already committed, wasn't it? Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 05:41:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 05:41:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438851.1657392 (Exim 4.92) (envelope-from ) id 1xCW18-0002wt-Vb; Fri, 02 Oct 2026 05:41:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438851.1657392; Fri, 02 Oct 2026 05:41: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 1xCW18-0002wm-SO; Fri, 02 Oct 2026 05:41:10 +0000 Received: by outflank-mailman (input) for mailman id 1438851; Fri, 02 Oct 2026 05:41:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCW17-0002wg-Q1 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 05:41:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCW17-00Bj9U-6y for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 07:41:09 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf43e6-8faa-0a2a0a5109dd-0a2a4502c4da-30 for ; Fri, 02 Oct 2026 07:41: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 6abf43f4-6ca4-0a2a45020019-4a7de18cf4f7-3 for ; Fri, 02 Oct 2026 07:41:08 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-4a01ff8c098so9657835e9.3 for ; Thu, 01 Oct 2026 22:41:08 -0700 (PDT) Received: from ?IPV6:2003:ca:b707:3710:a919:1c08:7b2a:ed1? (p200300cab7073710a9191c087b2a0ed1.dip0.t-ipconnect.de. [2003:ca:b707:3710:a919:1c08:7b2a:ed1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a03feed16bsm31670505e9.4.2026.10.01.22.41.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 22:41: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=1790919668; x=1791524468; 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=3UDuurVu1kGvinm9tGR3rninp0ic8BEwVGideZiO2f8=; b=ZK7BxZpTwKfQIG8V91x/sX2a1GwRU7+71w+uSfY97llYFqDUOjYi+xWX/r+mcSuQKI kcte+q6lruyC5kN1VtLBg207+DZZp9f42GUwOo4Ow02SKr+PRP5nrowEFKRLCF30Uxo4 hkqPLNcxBUapUfVUXmLfjEBhUYL0ZI6P4cVntwoGeTs8VBbnzgCP7AimuGEdQQhr3+tF ulKf24kwodp138ioQK0Aj3w/pZeVXGlmONWPANnSbIFbrZIB6ZGLuJvda33fBhcCjP8X ehDsucqedNhqiIWsr1xVV7M2H6eSAPrr1+hZjYK4P85hqBJpTtDrfK+DtFADxFmh9kxa Hcdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790919668; x=1791524468; 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=3UDuurVu1kGvinm9tGR3rninp0ic8BEwVGideZiO2f8=; b=XsxVDc6W4N4CxuFBPF/inWE52ihyCkkrZFV33XW7D/yoGvzv1spugboH/f5WF1RLKN EKPG7pdtv7Wbu/uea4nrBKuqaKJik+3tv6LAt8OPOw2mE7l6vF+Uog64+fHTCMUQsq5u NDNBT8gknIHi4voQl87cz9qS8FiaeYwBLhE9KndPmEPeKkVQe1HeqFGLrGdRk394oEcD Tpa4vIT5psVrN8W83TIvivFKyZ3IETveB4mPE6A4rOVRqU2ESYr6X4vwyu+5qvHgmvvF jo/oQp2rDIs5kyibta4LBdrLj2Ri//Mb0lryvg1FHwB/rRS+YyHOBJlUsZ1v3qJ+YpzI axIg== X-Forwarded-Encrypted: i=1; AKwUvBxY5aDAIeTCOpXy3vpIDVhT+/glBpxKMP3/8uGHcBZsG9PoN9KhDuBj5ZKKKdrLU8Zd6S8cjay4vF0=@lists.xenproject.org X-Gm-Message-State: AFuF++kBcsPFKvnOb4HVataibk+HcFdIWFApSRByRIgOZjQQHshLvpbH MBG/EzsepQiD7+a8Le9IWEH2sRcFiA2gnVRqwRivIaIh7QfLBuTBWsdITx1IplJGmbO/UU6yqrj DVXMabxx6 X-Gm-Gg: AYBFou0GYjqBm/GSkdSgxY9LhGAKtCSqZLhvVyeOWHD8nYT/cpqoWC5GpRTmJuohtc9 hFTnolF/5srmzxUtDl7BGv1rb98/e3gyS43QpwVVL1Xo1nRwaeor2Umj6S7A+8zcuw7hMpSZVMj 5ZNMA0Tg23KRY1VI3Qho/ISEsB99CCBwRpQbiNhxfkTGW0oMUKLJX7LNkShnl3ZeJZ7H4vM7KQh FXMHBxH5YqEBqET9cSpM0qV/11mUmRFpg8yL3J6gqqNNt6vtk83sWUF0h5Dfu1DFdRgXXJyLXeN GTHc27SY5KZvGSrPL4yF5P5rscKqLxCwd/zkX0982nSPL+5KWBbClAVOgJDr7i/R6B3ZqYRczWS tP0fRVffwaorYrWsaQdldpc8+zWQ8pZfeJg3gdNhoUM42QeLmQL/hrJUt5tpE9/BoOu8xzgAw1o 7I1c4NwSy82IBmQc8dylM+QJwh0s0egTfu58pdKfyhYI7SIgcnMgIkF13Qup0oEt5wuRbk24qhh Y8SDOV8uhK0swZDz6IVMXp0h5rDAacS15kuhWtNVH7xf0Ws/oEN9eQtbnUEo813sDqE+pGaJmoY IlmhQjJtuRhAEwg3BXuizuFcGHkA X-Received: by 2002:a05:600c:c162:b0:4a0:1b77:db0 with SMTP id 5b1f17b1804b1-4a0276b86b5mr29649085e9.35.1790919668468; Thu, 01 Oct 2026 22:41:08 -0700 (PDT) Message-ID: <23f1d834-44fb-4949-ac2f-8d639e8378dd@suse.com> Date: Fri, 2 Oct 2026 07:41:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/svm: Work around VMRUN's corruption of VMCB.INTR_SHADOW To: Andrew Cooper , Xen-devel Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Ross Lagerwall , Doug Covelli , Sean Christopherson , Paolo Bonzini , Borislav Petkov , David Kaplan , David Woodhouse , Shivansh Dhiman , Nikunj Dadhania , Santosh Shukla References: <20261001190518.438643-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: <20261001190518.438643-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790919668-31FD62AC-39476CCE/10/78276251493 X-purgate-type: spam X-purgate-size: 890 On 01.10.2026 21:05, Andrew Cooper wrote: > I was asked me to explain the comment beside STI in the svm_asm_do_resume(), > and, in trying to do so, things unravelled. > > The original fix inherited from KVM prevented the guests INTR_SHADOW being > changed from 0 to 1. This prevents undue delay to interrupts, but it caused > the value to get changed from 1 to 0 if the guest was in an INTR_SHADOW. > > Whether this matters for IDT guests is unknown; it depends on what else VMRUN > can do beside event injection and still write back the wrong value. This does > matter for FRED guests, as INTR_SHADOW is exposed architecturally in the FRED > frame via the STB field. > > Fixes: c989ff614f6b ("x86/svm: Separate STI and VMRUN instructions in svm_asm_do_resume()") > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Fri Oct 02 05:45:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 05:45:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438859.1657400 (Exim 4.92) (envelope-from ) id 1xCW51-0003dY-EA; Fri, 02 Oct 2026 05:45:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438859.1657400; Fri, 02 Oct 2026 05: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 1xCW51-0003dR-BR; Fri, 02 Oct 2026 05:45:11 +0000 Received: by outflank-mailman (input) for mailman id 1438859; Fri, 02 Oct 2026 05:45:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCW50-0003dK-7R for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 05:45:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCW4z-00EzNl-1k for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 07:45:09 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf44c5-8faa-0a2a0a5109dd-0a2a4507a8dc-44 for ; Fri, 02 Oct 2026 07:45:09 +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 6abf44e4-b4ea-0a2a45070019-4a7de18c929c-3 for ; Fri, 02 Oct 2026 07:45:08 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-4a01ff8c098so9671355e9.3 for ; Thu, 01 Oct 2026 22:45:08 -0700 (PDT) Received: from ?IPV6:2003:ca:b707:3710:a919:1c08:7b2a:ed1? (p200300cab7073710a9191c087b2a0ed1.dip0.t-ipconnect.de. [2003:ca:b707:3710:a919:1c08:7b2a:ed1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a0276fa954sm53651635e9.3.2026.10.01.22.45.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 22:45: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=1790919908; x=1791524708; 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=ACn9r8HxyG8IJLG/IYuoHYoHgQIbgGFD/y8nXUSn5Ls=; b=H5LBFYJ8Gl630Q5V3XyoskkiZE4Wv3M2IjHENVzgKkislhpJfuJ991cHeLYasQE6zF CI8bLVvOs9oPKq6hhRIWRz3dSzi2UTZ/dDuUd8Ggsjp4Vi3EHKestPBHJmf6gcCrbD8o 8vLrBvErKrdNINK/H3j8wFZ+l3nCkSAO26jvkz9n3MkyE9MscjDMR49TEqIoQLUhbyzw jDhRXfZ4sAtccDR8E+LswEDheOPnP7cbNWti6ZppZnCe70BXluhKPN864gDO1HHKUneT /ckQqIP7m4jc1/9wFtYjekrbN2W8dZzp/vCoDkfYOl8zrBX9QTEvgNdgz5SXhqAYAvcs hwtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790919908; x=1791524708; 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=ACn9r8HxyG8IJLG/IYuoHYoHgQIbgGFD/y8nXUSn5Ls=; b=CrKnmRJG5TA5hw/RDGe2Hxdf0ejTtx9DZwOxs638/voDsgqhBKieu5IUEdKXfolPea HRPYvT1paJeYf9ZIroAC07wctYBAbHo0qb0JmYuR4juNfAeTTKIyziS/Zbd0XjTDjTrd 94K7EYt1i9SkZWAmNm43JQOUGAi2eVKn3XpIEe4IfPkRCqC1LP7DlWB5qUOhyvq1nSJ4 XUWmE7xJFbaING8AOwTT5xDOX/VC4epyRVW5tP/f414PJ41Sc97/1YYalbcZ0XLEAAwD 6Tn0vAHiQhACTmuh/JYHdzC/9ediU6wS1XzCFrX+3D6J+SNyiXNlG/fOKQDrvgdr1CiB DT3Q== X-Forwarded-Encrypted: i=1; AKwUvByBi5opzku6eZyQFVinhiO6htEF2sLgrnYhY4Dii8n87DQkDSTiZPP1nJFNMuntJrbkUqk9ZiLOnaQ=@lists.xenproject.org X-Gm-Message-State: AFuF++mW9Pua0fEwpwqSVY6lY9hMR2EOxF8cqOga6vnOEnJ9HMhwliQR bsOeB81Uyf1AVYfmVa4fwZzmCrHzoVTbbmzBGFlUVSMZ3y+qPGQyt+V9bY4JRmkjOA== X-Gm-Gg: AYBFou047qsyan5unp7xkl8urpNfO1/H0EiyVK5vioj836yJvVpGdIrbfqUCUNjczen zlYkeuQWCEEiCl/nWN68Spyk76glLfhhHNQ/TAJ3aesR+5R/XRO1I1G2MKR7udFHg/VzOQaYZWG YYZYxZmsd9u+SPbmdYWLqrtd7BPHq+1Tw5D8owCqZxItbgEN0sDyjJDheulSP7e3HVv9XDkr1gB 4pAFXBUuROEsQLI8n3AKLKZ10aQyAEwKrRKLuiB0NROGcFwLERoNqkaneMmTFvofjwu904XHVtq gurVap8bz9DFKNAhUD+9SfOhRmh1aTYhKwTXmhmL5HfrPqAsxGN55Qfh9A03YqvHn9EpU/gYLe9 MbqL3xLwauu7MDOARQ9uentzYYuEbAMF3LBSH+MvVUq97C94TRv+p7PacX5dRTCLUQUSWLmmqRU Z/MRUy/c7pd1EGN8ztai0EcSwYUpI9W7Q0VMAYFZjGaYjx22+2o4nNQE01os2i84pTlZUQj0Y/h p9gl4jRGdZwOSg6Mu3zWzrlqGWhGpZgBhoiPYTKUwWCeyE1GKtM+OMNTZrwvyYQ/3B6hprOR7FM YnvyG57dOmrBm5MxprGiWXtMEDgPBCBNcuJOxNfp X-Received: by 2002:a05:600c:8b6c:b0:49f:ec98:f030 with SMTP id 5b1f17b1804b1-4a0276b3e15mr29462505e9.33.1790919908521; Thu, 01 Oct 2026 22:45:08 -0700 (PDT) Message-ID: Date: Fri, 2 Oct 2026 07:45:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain To: Roger Pau Monne Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org References: <20261001142757.98255-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: <20261001142757.98255-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790919909-A78D1AE4-229265AA/10/78276251493 X-purgate-type: spam X-purgate-size: 569 On 01.10.2026 16:27, Roger Pau Monne wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) > void __init arch_init_idle_domain(struct domain *d) > { > static const struct arch_csw idle_csw = { > - .from = paravirt_ctxt_switch_from, > - .to = paravirt_ctxt_switch_to, > .tail = idle_loop, > }; Leaving NULL pointers around isn't a good thing, though. May I suggest to at least poison the pointers then? Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 07:48:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 07:48:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438884.1657410 (Exim 4.92) (envelope-from ) id 1xCY07-0002PM-Tm; Fri, 02 Oct 2026 07:48:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438884.1657410; Fri, 02 Oct 2026 07:48: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 1xCY07-0002PD-QO; Fri, 02 Oct 2026 07:48:15 +0000 Received: by outflank-mailman (input) for mailman id 1438884; Fri, 02 Oct 2026 07:48:14 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCY06-0002P7-Re for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 07:48:14 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCY03-00B1kv-1X; Fri, 02 Oct 2026 07:48:11 +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 1xCY03-009l9C-1D; Fri, 02 Oct 2026 07:48: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" 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=ZKMrWblqCNTqAMqI7s3TgNneWN7bB3BC9o4ufRC4cd4=; b=6QbxP3xnAoubI9HwQm/ky6Dwpj az/DErBko368GGQJrdNvZBtkq57zdsYc4dQUwaarhUqlv42EXoNDz+jVN3dUXlmtEo5agJIuNYCou GE2N3RUrbzM0/KDodYZlZ77s6HmYoS5P9xrSV/RYf/FXGT7jh0lIN/dqZwiY82GdARcg=; Date: Fri, 2 Oct 2026 09:48:05 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain Message-ID: References: <20261001142757.98255-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: > On 01.10.2026 16:27, Roger Pau Monne wrote: > > --- a/xen/arch/x86/domain.c > > +++ b/xen/arch/x86/domain.c > > @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) > > void __init arch_init_idle_domain(struct domain *d) > > { > > static const struct arch_csw idle_csw = { > > - .from = paravirt_ctxt_switch_from, > > - .to = paravirt_ctxt_switch_to, > > .tail = idle_loop, > > }; > > Leaving NULL pointers around isn't a good thing, though. May I suggest to > at least poison the pointers then? I don't mind doing so, but I don't think we usually do that for other hook structures, ie: hvm_function_table for example doesn't poison unset hooks (and it possibly can't, because there are .hook != NULL checks). TBH I'm missing a benefit of the poisoning here. Using NULL or a poisoned value will both trigger a page-fault, and NULL has the benefit of callers easily checking whether the hook is set. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 02 07:55:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 07:55:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438890.1657418 (Exim 4.92) (envelope-from ) id 1xCY6r-0003xc-IK; Fri, 02 Oct 2026 07:55:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438890.1657418; Fri, 02 Oct 2026 07:55: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 1xCY6r-0003xV-Fk; Fri, 02 Oct 2026 07:55:13 +0000 Received: by outflank-mailman (input) for mailman id 1438890; Fri, 02 Oct 2026 07:55:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCY6q-0003xP-5f for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 07:55:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCY6p-004E79-69 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 09:55:11 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf634f-8faa-0a2a0a5109dd-0a2a450bc5f6-46 for ; Fri, 02 Oct 2026 09:55:11 +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 6abf635e-b7e8-0a2a450b0019-4a7de18c8358-3 for ; Fri, 02 Oct 2026 09:55:11 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ffe281cb1so39042225e9.1 for ; Fri, 02 Oct 2026 00:55: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-4a03ff2280csm33320675e9.4.2026.10.02.00.55.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2026 00:55: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=1790927710; x=1791532510; 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=rnKaHBPZaXwRCbMo9jpqNWs0SPqXXv30JCnFfVvGJiY=; b=IsU/ATKnhz1tx7lr1KYkJw12/GWcj7gCH9zAZd34NuXXg2NPfoUjIdBzDgjxRFKObB YhHPYYrReR4sQVxwho0zzIw7WdE1XF7D41t15HcWDoP07gkI6bFh9D11l2B6PU3dtyIM hk28VTvnuDU/1aKGs7mPseATLhFn93i5nWCvyUOYjcMAjtm+JMvrNzulLeiVWM3NSiLF vOGLcIWQs9d+oUKUH2E1xhhbh4Uh4PR5WMGiWsJNaA0pVUWFBDbIGAPR9NUjpWE7uknF NXzMA+EbTAOKWHkr3cODXwVwudELg2SPEhr4OG0MlrnHVAcya/6q4P62vUt1SRc2INK+ QHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790927710; x=1791532510; 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=rnKaHBPZaXwRCbMo9jpqNWs0SPqXXv30JCnFfVvGJiY=; b=NzN8B3ZwMcc2c9PE7ULhu1+mfkX0PPYmMHPlA8X1dMKpfG5zBuDJ9SaIYYQXDdZO5h 6YGt56DFDbOpPVIvJoQLjGfN4kJzE3G/X0rLw3uYApNssZhmR/1CzF18uCCiLLiOae4n zITNIOqa6AnYZlqxbZru/Abrymi7jmu+uZN0GkYmfhgDwj/2+MJLIjnHUHn28pB5raZ+ T8CxkxuynbFLm58N8S2u805kB3x6SoBmDX8CGu7xjJwap7lGgumlHJa7IhUkLLW3+YPC TlyKMjOCrvAdKolpclshMZlqnboFvve0ARdzFYBxClFGjhu06Zh04KxEi+QC566uS55w nyww== X-Forwarded-Encrypted: i=1; AKwUvBzO98gO/rebuMuhnJAQ/bHVhLFHlne5VlSfhfZrfBT6E1IOXr+Nhiseik5avY550XQG0Wjlkilp5zM=@lists.xenproject.org X-Gm-Message-State: AFuF++lrH6D8g4lJpK9J3iv23VIWRyujmvgzI3hHCzu8lrXMciCAYmQf fY+EUYAirNqHEFtH2vjj6vAkUI2SZuAyJ5kS6tc8ZmB393y+7eYJrB48fl7ZNhzqLw== X-Gm-Gg: AYBFou2+kEdZpRm6muZNlGuEnUk5j/PXvcIfBePaYRdupDQhkWgcz+wHM+ZTuVbUCOC Ft1gWgu+zS+cIJ3Js+cI8gDpTtWPwZH8UODjknb0NQxX52rRB1xOYYpCO3blaOx8Ge40avrMWTd 5ZqvvrqUj7v0eM465CMxux4KeYDJWxavpsgbGzEvNCXfdLq4MAzv+jbA1tgG50laWKpqZCVjeKl jeTN7T3yzURc3L52zgFp9zHeWZdX5bi0bqwAtHmcaDJ2aE7CEuzl/Yvf5PG3+9CnoJ7znn0RhnK rDqu1QwsngcGa+9w6ezreBuUpLBLHCCmsEKiXJCopNGvOQyQFvPJCjdL3KgBk7YMvlmzTYysmXy zgFa5Ld1UpO1/QKOklCDb9rC2hrS5pnqzjYRSEFgoq1kUO/0QkON6NF5wU4Z/1J6YjEZ2YWb3ur tVS04sERYxhvfI3egwMn9vD27lCeaKy2qllf+cwVIeNJtB6ZoC/oTV7Hrow75HBeVdg+oRzULUL 5/gVgNoru3ZvKrJJbpRuQ0MOxoq7B/C9BAx4A0tpUswGTS1KZyhrG9pFtAVuA== X-Received: by 2002:a05:600c:6d1:b0:4a0:1b14:ce81 with SMTP id 5b1f17b1804b1-4a0274e9a8cmr22981905e9.3.1790927710440; Fri, 02 Oct 2026 00:55:10 -0700 (PDT) Message-ID: <4eb32155-1b04-4f04-ab9b-f30e584cb033@suse.com> Date: Fri, 2 Oct 2026 09:55:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org References: <20261001142757.98255-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790927711-AA6DA9EA-9BAC2290/10/78276251493 X-purgate-type: spam X-purgate-size: 1280 On 02.10.2026 09:48, Roger Pau Monné wrote: > On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: >> On 01.10.2026 16:27, Roger Pau Monne wrote: >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) >>> void __init arch_init_idle_domain(struct domain *d) >>> { >>> static const struct arch_csw idle_csw = { >>> - .from = paravirt_ctxt_switch_from, >>> - .to = paravirt_ctxt_switch_to, >>> .tail = idle_loop, >>> }; >> >> Leaving NULL pointers around isn't a good thing, though. May I suggest to >> at least poison the pointers then? > > I don't mind doing so, but I don't think we usually do that for other > hook structures, ie: hvm_function_table for example doesn't poison > unset hooks (and it possibly can't, because there are .hook != NULL > checks). > > TBH I'm missing a benefit of the poisoning here. Using NULL or a > poisoned value will both trigger a page-fault, and NULL has the > benefit of callers easily checking whether the hook is set. NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV one may not, depending on what the guest may have put there. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 08:06:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 08:06:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438906.1657429 (Exim 4.92) (envelope-from ) id 1xCYHD-0006Fn-UN; Fri, 02 Oct 2026 08:05:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438906.1657429; Fri, 02 Oct 2026 08:05: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 1xCYHD-0006Fg-QC; Fri, 02 Oct 2026 08:05:55 +0000 Received: by outflank-mailman (input) for mailman id 1438906; Fri, 02 Oct 2026 08:05:54 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCYHC-0006FY-By for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 08:05:54 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCYH8-00B2ct-1H; Fri, 02 Oct 2026 08:05:50 +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 1xCYH8-009rtf-11; Fri, 02 Oct 2026 08:05: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" 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=XjP3S9sCRbit7vbPBcr7VXpFftowtgeo2CVPeq1A6lE=; b=x6CSNC7IBL5VAXIoNnDkxpvP04 vGNgCFR+0EgISxNG91kEA8CJk0QZIsk18fEQn9/MKxGJSWIgNgi0JVS+aObkKfIQgmBsry/tz+Lt1 DoL6Qo/a/8CaJlipQv2u0YGYaFAZyADb7f1rvPqmp+YSbkWSQKdGx7QOdWJENgAuVcgk=; Date: Fri, 2 Oct 2026 10:05:48 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain Message-ID: References: <20261001142757.98255-1-roger@xenproject.org> <4eb32155-1b04-4f04-ab9b-f30e584cb033@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4eb32155-1b04-4f04-ab9b-f30e584cb033@suse.com> On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote: > On 02.10.2026 09:48, Roger Pau Monné wrote: > > On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: > >> On 01.10.2026 16:27, Roger Pau Monne wrote: > >>> --- a/xen/arch/x86/domain.c > >>> +++ b/xen/arch/x86/domain.c > >>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) > >>> void __init arch_init_idle_domain(struct domain *d) > >>> { > >>> static const struct arch_csw idle_csw = { > >>> - .from = paravirt_ctxt_switch_from, > >>> - .to = paravirt_ctxt_switch_to, > >>> .tail = idle_loop, > >>> }; > >> > >> Leaving NULL pointers around isn't a good thing, though. May I suggest to > >> at least poison the pointers then? > > > > I don't mind doing so, but I don't think we usually do that for other > > hook structures, ie: hvm_function_table for example doesn't poison > > unset hooks (and it possibly can't, because there are .hook != NULL > > checks). > > > > TBH I'm missing a benefit of the poisoning here. Using NULL or a > > poisoned value will both trigger a page-fault, and NULL has the > > benefit of callers easily checking whether the hook is set. > > NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV > one may not, depending on what the guest may have put there. It still feels a bit arbitrary to do here but not in other places, but never mind, I will adjust and send v2. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 02 08:09:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 08:09:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438914.1657437 (Exim 4.92) (envelope-from ) id 1xCYKI-0006rt-Ea; Fri, 02 Oct 2026 08:09:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438914.1657437; Fri, 02 Oct 2026 08: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 1xCYKI-0006rm-Bg; Fri, 02 Oct 2026 08:09:06 +0000 Received: by outflank-mailman (input) for mailman id 1438914; Fri, 02 Oct 2026 08:09:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCYKH-0006rg-0A for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 08:09:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCYKG-00FQHM-DG for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:09:04 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf6699-2eae-0a2a0a5409dd-0a2a4509cd42-42 for ; Fri, 02 Oct 2026 10:09:04 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf66a0-be1a-0a2a45090019-4a7de18da4de-3 for ; Fri, 02 Oct 2026 10:09:04 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7bcb94d3so55825805e9.2 for ; Fri, 02 Oct 2026 01:09: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-4a027734b49sm64020455e9.10.2026.10.02.01.09.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2026 01: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=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=1790928544; x=1791533344; 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=MwvkEj/TS31JfS5RSjKTLCVJrQdmgPv68p4D/s3l3eo=; b=Js8+8xcVRToXZR7X4uitsukzOLx/t7QMs/KQXM+F8gxSydCGBwcci1FfMoOk39L8EG 6DiaHkM7JrNdXOXxYDUwM0GEa7bWxXvx9ciCWsA7sRhc8SvIUn8CzkXvuXrcSalfdzuR SPGGtwvBt2BenKFTnUossy+yswEODU+MTGHowSQd6nbSqvq5rdTxGAL5u6kDzlaMIhYv X0YvPNt2DUxTo2CvBTGB1+fDusJWDerVrjxc/eQLRO+nBmQ59r8AkaD4XC9etRblEh54 QrEOCfFgfrtofqSfw5d0whj8pROPGoWHBM7IE6b5zuxtgxg2OjLhVeEO22Pg7efOdwfH QH5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790928544; x=1791533344; 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=MwvkEj/TS31JfS5RSjKTLCVJrQdmgPv68p4D/s3l3eo=; b=mKPFYOIPhHmPcTUpt81DmjGYmuOeriWauGV6yOY5yWlxEJbsVmpZFPZOZ11rnKEwlF 1swJgkMDl1Mtffrll8h0w0Rts0iHZuRfXDTRX20wS8btwAfJRpHewfGtmCd5JNwsm+68 8e6xtdRigsaeBX+ZrRFrTfpekNijf+lUAhhcmHd0ko6vkGWo4OVpenr39X2C5/BVW3bo jKSQJv36ouzod7C9Ka9PiOp9R5rw+4iUTYOGe6MmeycBvP3sERz8RMEWLogqTkxvEnD/ M6+D0dr8V+QawL+k1FnGCvuZ6ormnJWo29RdqQ4GPQmHY6InMLu2wTwRROpHlREVU9UH ktqQ== X-Forwarded-Encrypted: i=1; AKwUvBxtEkNOa96L59ci3SfZSdUvhMArhwmIdgFnrrfDsiWYCTJsmdIKXSn2tewcQH79qZkpWTsPXpbDAXo=@lists.xenproject.org X-Gm-Message-State: AFuF++nHchXwivMh6PZpfXDom2KOsVbY4MmYAjT57l4wXeyjgKTWqGBZ 1Ygf3ytFhaOxH489BAJ7C6ItelFFD0IsLwBbq7j7X6Ti2G8P6EaKiknI0E5DgOJ5Qc9ukVZwtjp w+ipbBg== X-Gm-Gg: AYBFou2ijFXTvL9a8o1wq7zwYh1Eax06AWpD3c+a4NWztPXlhmU+Tm29ngbIoAR+HZq A8HWmrm+E6GSZoArIaaR1GjYkq4y4HqNrdk24UD2glrczjTXkafdpk0fzyTXyHz5enW1mizRzvB VC4Ok3jSfYLHvcvBWkeT7HYqNkXihtfA/YfR+XHKpQf+xO7zUAkOr2gGrR8tVaHILcpBej+FUa1 FbiwOH9W+K2SRdEVkk/ZA3FlSMYRHa3hm1mtoMuad4noZD4zqwfpTDBRYRwAW6bZb4c66V+qnka JDYcWqNjwUA+qTqCn8y4KZzL0ZoDCFqFBeQSuwc2e/4dKnqem/cusx7p9Bt7cu+8PFwqf0OFg5x rD9PQIiZbjggXtxzNhL9W9u3HCpJTsXW6kU2uGhjYM3UgU7y0EK6OWdLqzH+9SeZyz8BBwtjVgZ q7anIP8IyY29/oA3DwjlZV0UUIEjEJRDt65zFizjQ9tNdNYiOZdCRuu+aFRw6FP+baKFCTVNduO UWEaHOUOBe1VZ3CIrWQ2sUjaOKrKaacLyp68BfoheEyuAltsabf85OBcvQ0xQ== X-Received: by 2002:a05:600c:34cb:b0:4a0:1fe2:d4c8 with SMTP id 5b1f17b1804b1-4a02754224amr36092125e9.5.1790928543491; Fri, 02 Oct 2026 01:09:03 -0700 (PDT) Message-ID: <1226702d-5bb4-4e7a-8e6a-6534002cfd8c@suse.com> Date: Fri, 2 Oct 2026 10:09:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org References: <20261001142757.98255-1-roger@xenproject.org> <4eb32155-1b04-4f04-ab9b-f30e584cb033@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/1790928544-BFCD7034-2B9CC734/10/78276251493 X-purgate-type: spam X-purgate-size: 1793 On 02.10.2026 10:05, Roger Pau Monné wrote: > On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote: >> On 02.10.2026 09:48, Roger Pau Monné wrote: >>> On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: >>>> On 01.10.2026 16:27, Roger Pau Monne wrote: >>>>> --- a/xen/arch/x86/domain.c >>>>> +++ b/xen/arch/x86/domain.c >>>>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) >>>>> void __init arch_init_idle_domain(struct domain *d) >>>>> { >>>>> static const struct arch_csw idle_csw = { >>>>> - .from = paravirt_ctxt_switch_from, >>>>> - .to = paravirt_ctxt_switch_to, >>>>> .tail = idle_loop, >>>>> }; >>>> >>>> Leaving NULL pointers around isn't a good thing, though. May I suggest to >>>> at least poison the pointers then? >>> >>> I don't mind doing so, but I don't think we usually do that for other >>> hook structures, ie: hvm_function_table for example doesn't poison >>> unset hooks (and it possibly can't, because there are .hook != NULL >>> checks). >>> >>> TBH I'm missing a benefit of the poisoning here. Using NULL or a >>> poisoned value will both trigger a page-fault, and NULL has the >>> benefit of callers easily checking whether the hook is set. >> >> NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV >> one may not, depending on what the guest may have put there. > > It still feels a bit arbitrary to do here but not in other places, We should imo resolve this by replacing NULLs wherever hooks could, due to other issues, end up "in sight" on paths reachable for PV guests. This would then also cover potential speculation along such paths. > but never mind, I will adjust and send v2. Thanks. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 08:31:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 08:31:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438923.1657445 (Exim 4.92) (envelope-from ) id 1xCYg0-0002RB-1r; Fri, 02 Oct 2026 08:31:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438923.1657445; Fri, 02 Oct 2026 08:31: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 1xCYfz-0002R4-VT; Fri, 02 Oct 2026 08:31:31 +0000 Received: by outflank-mailman (input) for mailman id 1438923; Fri, 02 Oct 2026 08:31:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCYfy-0002Qy-32 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 08:31:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCYfx-004MGb-Fv for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:31:29 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf6be0-2eae-0a2a0a5409dd-0a2a450999b0-2 for ; Fri, 02 Oct 2026 10:31:29 +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 6abf6be0-be1a-0a2a45090019-b9ff1c22b5df-3 for ; Fri, 02 Oct 2026 10:31: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0fbbd5a1c0003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 02 Oct 2026 08:31:25 +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 ECB4081E20 for ; Fri, 2 Oct 2026 10:31: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: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=twKilgUD4v/y+COTK4YKEPJ7GAm3QgTdy1ysTdL3a6w=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=WFjjX7zPhiFrRieWpggPU761KIdgie2gCIea/8Jwwca76mE3I5OIGtxRXmslYDbL+alKig2EE vomBdYvURHBwyMyeTSSGhS3cFQBeZK+izAveg0m0u+LyxNq8ncz5kRZ0cb1OhohEAc9ZLLTolMq FdAB4j1kKj60E2d+MH3HJc6fLwrcHSg9wfX1DXERkOJpcU3Dwm3fiMCes1eLClbOiSvvLEg2Hf4 ejsxnfA85HqQJaX7J7l/Er374B5IyGRww2SMNCv5NsKvxUkYSYNSEF0i0MrdNZbUvYrl048WVjW G+AJFST2zpU2OwUmGyNq/+KAZfsh67YvTl8knDacC5ng== X-Zone-Loop: 827b38d0d8f3aad8936923eb5ab7fa9c5f36a6ff0203 x-campaign-type: default x-transaction-id: d4523994-7390-4549-876a-f962665297b1 x-swg-uid: 01-519338c7-ce9e-4b8d-a203-454f2357a0db X-Mailer: Sweego Message-ID: <1790929885.8631fc262581453bbf619ec5b2062170.1a0fbbd5a1c0003f66@vates.tech> x-swg-bid: 1790929885.8631fc262581453bbf619ec5b2062170.1a0fbbd5a1c0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 2 Oct 2026 10:31:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] xen/riscv: use pte_is_valid() in pte_is_mapping() To: xen-devel@lists.xenproject.org References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> <1790845650.8631fc262581453bbf619ec5b2062170.1a0f6b805100003f66@vates.tech> <1790846121.8631fc262581453bbf619ec5b2062170.1a0f6bf34f40003f66@vates.tech> <2a9c133f-004b-4360-af53-2c8127f9a0bf@suse.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: <2a9c133f-004b-4360-af53-2c8127f9a0bf@suse.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: 1790929885017 X-purgate-ID: tlsNG-bad1c0/1790929889-BCCCF034-CAD344BC/10/73395122804 X-purgate-type: spam X-purgate-size: 865 Ok so: Reviewed-by: Oleksii Kurochko On 10/1/26 1:11 PM, Jan Beulich wrote: > On 01.10.2026 11:15, Baptiste Le Duc wrote: >> On 2026-10-01 11:07 +0200, Baptiste Le Duc wrote: >>> Use pte_is_valid() instead of open-coding the PTE_VALID check. >>> >>> No functional change. >>> >>> Assisted-by: Claude:claude-opus-5 >>> Signed-off-by: Baptiste Le Duc >> >> I forgot the changelog for this patch: >> >> Changes since v3: >> - Rebase on the pte_is_reserved() -> pte_has_reserved_rwx() rename in >> patch 3, only the context line changes. >> >> Sorry for the noise, I didn't know if the reviewed-by >> Oleksii gave applied here as I rebased the patch. > > If it's a re-base which doesn't affect or alter the code change you're > doing, I don't think an R-b needs dropping. > > Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 08:34:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 08:34:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438929.1657455 (Exim 4.92) (envelope-from ) id 1xCYjK-00032I-FR; Fri, 02 Oct 2026 08:34:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438929.1657455; Fri, 02 Oct 2026 08: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 1xCYjK-00032B-CO; Fri, 02 Oct 2026 08:34:58 +0000 Received: by outflank-mailman (input) for mailman id 1438929; Fri, 02 Oct 2026 08:34:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCYjI-000325-D1 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 08:34:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCYjH-00Bgmw-5h for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:34:55 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf6ca3-e002-0a2a0a5209dd-0a2a45098314-32 for ; Fri, 02 Oct 2026 10:34:55 +0200 Received: from [52.101.43.23] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf6cad-be1a-0a2a45090019-34652b17c1b0-3 for ; Fri, 02 Oct 2026 10:34:54 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by CH8PR03MB8324.namprd03.prod.outlook.com (2603:10b6:610:2ba::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.19; Fri, 2 Oct 2026 08:34:50 +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.0472.016; Fri, 2 Oct 2026 08:34: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=TWNTq6p9kVVdEK8yWl1qRTC0fu5zI0FSt2Xd5vCT48KkB4LU2u539fVdRRlhi5rQh5I+anzGgkeMPKIOBs8eyMhebVurX7piTJYZXFxXOPiXE1IB0UFYRKdq2JrI4HQmr4hjEzQDljMCEPWIObk/yGSYFMQRBgO5ar4j1nMDpZ/dDDVaSJEV6JbZCfEmnS6joX148A/mpkgu3+PLo71MbKoP+Hjg/OO4JzZlDyB+xufKcvooLzk+VSTHmNkbGzh/I7YChvFiio9qTmBqS/9m/PN1ujSVPcGh3m4NiNq9mbZEVqK8lW+f/92XirjYDCy16AmRERXfek7m6aZWY8cHpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0ApjGMxKHWmTzuJfSdG8JwyGkpWEDkH7xvVBXJRDgdM=; b=P6o1a+PkNTUQGqUrIUIDLuVpb0+qtavYitXFfV1AJEZe7pkJCC2EeUHp5L61hUcgtqBNSNfEqVmBnaVJxgkmvdHIQo6czM4DRnNcpUnzCsJGo3kFA1AxwwmgQSC9m2jb1K8lXsI6qt3/7tztbq5qaj6ST7DfCty53GhmtM4wtDZA2lNTd0UpNYG8eDMlQba21fEEncYwkKnoSgGdUElBcwj42ljYiMp+RheqMUKotzGOBEfbFQDS7utAuyWSKkxEGxkUHivNhF16nG2gKxBIkw4erQXCqIUrhra2Nw8rQ6tLd+NZ7om5UwdrR7vQuXg/p5bvOHC95yUY08cvejSgUw== 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=0ApjGMxKHWmTzuJfSdG8JwyGkpWEDkH7xvVBXJRDgdM=; b=vmsBPFHupQtqAim4svydhkSKN6rptqIrIbFZ79eo9Q/2db+9MFTIix0zK3su2xCkm3zH13KCIw3cvl9Q/dNLL1xkJjOVvfCTLsvmCiw4+R2VQRINHu7H0U8F9UMjVd9uFH9DuWoHnTYGNCYpFE1bWVu9ZeQjrg2cm7ZHO68mOVk= From: Kevin Lampis To: Jan Beulich CC: Andrew Cooper , "teddy.astie@vates.tech" , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v3 1/6] x86: Remove return value from UPDATE_ENTRY Thread-Topic: [PATCH v3 1/6] x86: Remove return value from UPDATE_ENTRY Thread-Index: AQHdUcyw+vB+FMChKUya9aL6N17n2rbpvOkAgAAvJJs= Date: Fri, 2 Oct 2026 08:34:49 +0000 Message-ID: References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-2-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: 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: BY1PR03MB7996:EE_|CH8PR03MB8324:EE_ x-ms-office365-filtering-correlation-id: 00abe321-cb19-4f42-b929-08df2060060c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|18002099003|22082099003|38070700021|4143699003|10067099003|56012099006|11063799006; x-microsoft-antispam-message-info: yl2CK6c1Ih21lfGj4XOoC3Rn+pbX+k8286e2IIiyeKNLXn9NwYmT4xAQDAcifUEwa7Vn+kXEJpp0gFV8Zyi8cJ3O/W7nK75DWs6Gg+C3Wud0QayzkXg2VOaLMlXp/XVxEd/8k+q1zINbl2XNYC4S2ZjIKH96msObFaf8sjtb3WMQnb9kD0Vfz34QMzASZymeytQdQAWP5tEdEneCxA6HMIbfHrKInqKC0wiztcpNZiMTl4sQG68rycdl9R1onZjkG5iPfjOjgff15l/rKucDXZVNN0Is56mgyJC6IXDhYheJLlYiHZYaGl0XnkhJ28hdfDpPNZ92U2CNl7hTHy3iY/EqthAxyN1Bh+fCd5QurhpVSuWQ4GAgov/FNwjSwONKTw4gKONEl2gt5JDGizJ0zgRBHD01j/D8XnXfcj8rwPj5sYEOZxBMnq1Hp9grimj6JO6QE/UL7EORNINvEOyIS2l3B2d+tc1n6S2xbaeZEDWELzGLlIF2Td0d3VptGc7YcRS0VmL8jgujVTeqIBJGFMzLhbZuCKdu8Z+ShuHJeIRtb5ESraqhNLTcIGrmheh2MY0iFlgt9CQlWfPqHi0PPRk7wb2GUPni1mDy/c2py2RRPQe+naKSTlCqtsJfJ/XmJRQySIsuUFitGBMe5knIicDSMPTpTz6KFoKciV6U5diBZz2K6LGzjvwbMvBknaenlnjYAF5N3lkRD5J7NVmorA== 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)(18002099003)(22082099003)(38070700021)(4143699003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?n7Bww2F4V/4JB4iJAQl4OoIc7Sth+1b9JQX6F3d/pU5cHvxdl8Xu/ejN9F?= =?iso-8859-1?Q?W/k6KLHaYTxPNcRWIFwEAPFkpj59izRRhcDS0TvvtC36cCtzEiQHYQU8l0?= =?iso-8859-1?Q?kqlYQBKMv93nptuP3kWmfdeI3GNda+VRib9RooCRJ168DSfRNddwqNF/b3?= =?iso-8859-1?Q?CAT5nUtR2EU6PV4OU+dCqpJgrY7YQx4GkJ984XjuHZatkvAGSA19sbwY6E?= =?iso-8859-1?Q?xZri3kdBDhWaLVIPx8Si83o6B0+z10bd+G9Xb/JiT7VzMjf3hjpRlp3010?= =?iso-8859-1?Q?na32sxEIwMQLsoJAz9QXbfqRrdm0Py5MBPz8oZV1BCHyA0RaCBKTvVp9+F?= =?iso-8859-1?Q?1BLakcXvuttr07QFnUc5BgtywKvmxhkzsFk6C0esm9zBsQPyTC1fJG+Vpd?= =?iso-8859-1?Q?3V8GULo84ov9KkG8lIts1Dio5qwdmkt+qUqKohFqUJB7ZXybrG7I7aP6dP?= =?iso-8859-1?Q?j8RhxL6HHGNjzki6UtMZDMqOTTwwkbfnfeCLQjn8714Bw7VzvwNH4hgCAG?= =?iso-8859-1?Q?T2wbfR5YI63L01zxDeG55Hj8VBbvyRKeFbVTtLw00c0CNlSqHmyxMNa0BO?= =?iso-8859-1?Q?iDx2mFcGcOw2pzqDyKTIgo4GkEJFYq4hm7Q0cQ10t09046fFqB5Z/+YfE9?= =?iso-8859-1?Q?cADkOV89JxjHTHE1orgqepVuaZBABL2JF4ugWRx4AAY+D5+PvttpifU6gm?= =?iso-8859-1?Q?F4zlyoQCWnr5tT2+uRIHOlDx5MPKk1kWxgSj8498B64rSW/wjd/Vao3+Ni?= =?iso-8859-1?Q?jJ9o651q+2my4rvQT44f7+hjkXP4mt2riDR4EnlGABKSdxb3ez8nJtlDzX?= =?iso-8859-1?Q?wePLdmQdhyFaQmeMdarnmvsv+LtOithutiY9+FlpGMc7LHHVPkvbotfAkT?= =?iso-8859-1?Q?qgQeJyz7/79zENI1UTaq9htBld9Nr+qOYT2DSRMooeeJvLHuPavNaIBuz6?= =?iso-8859-1?Q?VS60Shd5H6c6kgA6wllVEON4pPEC/hBXAOyTVVTfTYRD9lvG2FxgNS9Toj?= =?iso-8859-1?Q?pF99ZvuIASyywwVv3AT53ZjXNFbmRA74gcaW2wC/dlQCrWBh6GaCiYlAa9?= =?iso-8859-1?Q?sjgc76DhUgZ6EJDkqVNrWrRNtEJQ0NJN/Sph+M1lXVuzHlXToArWb7oWIw?= =?iso-8859-1?Q?fzyuFRs2anDMXPQ+7Sjx2DxBIVMedbTWz/b3k4yIyqkU2578tLd/k8ux4B?= =?iso-8859-1?Q?JSDpiI8Xb5BCq14YV0dAOoS1NGb1oo4n7nJT9+kuYl7n8OXMHxtWtbr7D7?= =?iso-8859-1?Q?nvInviuf2nOLlf85wwpnUX8jd4xLXE1YcnThdpW5GE8jde3YhAcMWxtXWI?= =?iso-8859-1?Q?voTApe8PBxARLDOuwLX8nVJdBi9Mp/sJwcNClI8SkcnaVIGys4fXqQh3Oa?= =?iso-8859-1?Q?AlUtG9zOKYMLwXnE2ihAgydpN6Lc+UlJcADwS09hsfLKam7cDV6jft57yg?= =?iso-8859-1?Q?0S6krzwz3E0XsYChWB+2H/Vgubsi7mN7CggO/zc1FXDYwam8gP3JvvQ2PD?= =?iso-8859-1?Q?h8ClzQ6pz8+RDnBZLfoBWH4hiN/nG1/jd4broinVhC+e6CR9hP07JAh6Uy?= =?iso-8859-1?Q?3B2bgKbnru+BUj8sWG5ADNwvuHuHdwdd3iMYeHNrlNYPnndsbKbd0CwUDn?= =?iso-8859-1?Q?VKhfUI0cdC7ptiDSHYkw7o3F3XW1IkSxibRX6ZF/tF1E027z8mQ3HPn32U?= =?iso-8859-1?Q?XSVaSCx5W/WkXDuKaQ8Uhz2JTFfI1d9ymlyRfAuUte56QKuz4vj77sPqSf?= =?iso-8859-1?Q?fBWklAyxhrhpQwyjwtAxQwMIQCjLy0qOc18AxUrJSrXDCA?= 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: 00abe321-cb19-4f42-b929-08df2060060c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2026 08:34:50.0045 (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: EB9tg4T7Iw08P9A7VA54f58M9TYKX04XM2lmfTRXyXiCb+tAObLIDjU/noF3SjspIWFrcx5TKHUm5PvTAI8YwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR03MB8324 X-purgate-ID: tlsNG-bad1c0/1790930095-BC8C9034-2C8DE437/0/0 X-purgate-type: clean X-purgate-size: 201 >This was already committed, wasn't it?=0A= =0A= I'm aware of only one patch that was committed since last time=0A= `[PATCH v2 1/7] x86: make UPDATE_ENTRY() allow for multiple operation flags= `= From xen-devel-bounces@lists.xenproject.org Fri Oct 02 08:56:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 08:56:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438937.1657465 (Exim 4.92) (envelope-from ) id 1xCZ3Q-000604-4Z; Fri, 02 Oct 2026 08:55:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438937.1657465; Fri, 02 Oct 2026 08:55: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 1xCZ3Q-0005zx-0K; Fri, 02 Oct 2026 08:55:44 +0000 Received: by outflank-mailman (input) for mailman id 1438937; Fri, 02 Oct 2026 08:55:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCZ3O-0005zr-Rv for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 08:55:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCZ3N-00Bkmo-OS for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:55:41 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf7176-bab6-0a2a0a5309dd-0a2a4508c91e-44 for ; Fri, 02 Oct 2026 10:55:41 +0200 Received: from [74.125.225.98] (helo=mail-wr2-f34.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf718d-f659-0a2a45080019-4a7de162a239-3 for ; Fri, 02 Oct 2026 10:55:41 +0200 Received: by mail-wr2-f34.google.com with SMTP id ffacd0b85a97d-48afe3b2383so2190357f8f.1 for ; Fri, 02 Oct 2026 01:55: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-48b38103856sm4553380f8f.25.2026.10.02.01.55.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2026 01:55: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=1790931341; x=1791536141; 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=NaMS63VrhleTkQdWL+Yfq1D3V3AkSLt4qhvz1jh+oFA=; b=g3tCkSIpr8buvXE2Msj/25+7rfIllUht5Ynrov9sGueTpaw+IF2B67rLPyrYmP7Bei OmXyoJvdE+7S73V6OEMfgSmJ9KD+DN7hgwSvz1s5hEyIcm76aAMBW8PejfdFcjerHRX3 1uoCzBQEf/HW4XbvLESClPuK33jLBoewwzyymfeDXJ5F5s2curLvnXcfCmHfoS/eZPpE Tyjxc1eF62YDsWvKu2R/NZ9PTcoDtjZHUmf9ges7hIoyv9jQoQw7IjtWBI3Owi4/+v7S Yk8pv1ErC9xEXQ21mtFBx321Gbldt2fXWUMhhTbf1w2OSeLWmDQ2SzhLwzYvBJ64Bxgg 94cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790931341; x=1791536141; 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=NaMS63VrhleTkQdWL+Yfq1D3V3AkSLt4qhvz1jh+oFA=; b=swIQL7kUQPkwnudViMy4xYGztRP6juSLHrQy/i5HAhNJz3XuYK5j47Wj6BoTXz9VPK XHTWp0niHASDNCLs81tf0Ml+bbsiEsSoM46qLf7iPxCG1OG0ebjS8abf73sjFDGI9Efx 6bBqFW4VutuKOC82VCIzGYptxdxi/AleW2xqnjzr4Xu8/feI6EHYcABeQHt6yu6xf0+2 zE1Regpgl31ZzRD0n7HWnNj7ERLtOXtTpo/wnHiKA9qX6k5KeazzPpC7oYhsOO83OHRw VyE0tWh5/KEtiEqIYY+vaoeeeG2qJONMV4c1tV6pj8laD0jI6M4bmkcsGKXwkghl4SbW O6hg== X-Forwarded-Encrypted: i=1; AKwUvBwjTcKkox918C+jpFIbu8qBj874/B9mBgf+EhvncbuyhvVlr298Ck/j7W6A4h0BOw8TYeEUWuIKWGQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYLJ1M5Ei3MXuOgFfBJAUY/TxAFu2sM772hYeInGEP6vbyY7UtVh +PNyfySWOB1P2ug16w90bkO75OXlbkqJ7A2l6rbVf+pG1xrWDpRNLRwgPGBdf9/vqQ== X-Gm-Gg: AYBFou1k8zSG6E6UZEZs13g9IejpVHkzAOzrMigfeoLpg+ax7mnLwFaQrgyxJYt0Z17 Les/4dVA22mXnF7OG9E7NTYjOAzBYnYCxpaNVkteepyAvuATtAJDH8Li8f7HfmhAGF5rm4FRwJT l3REHk7CQMHEEBiZZsPkZzZlLXxgDR0uf7VbHxezb7zy3y6SQuej68RBqiZLkJ7c189TJGpEN+H fL+AlE15/CaUUOILQOYZpAxH2VJnZAGNBz9ZKKQeEVJ69jq07BFHoiJDZrVHgN3mcobgUUg82qV 18/FEme0k+j0y+quzDb0qdWLGZWu0bKVRVK+rYwBWraqMy8izqIee5pDtxdEcC/7OQ2u4L2+MFA +E/xDf9+8eGtPD6sC4TIBoYlsUBXxUMe+3Lb1GvtS0uHJXDvrt4l4UcR3wbRWZtxvqP1i0HB3a+ gB7NYt/SoNSaq6v0hAAExZGQQdxdPo5PmOHqXvsnszMcpRLgPgTzVzXfi5AmH4Gn9frkb8jqzSV Rn3q1+EKPyd1ywZkd1VIV/pU7GgR943amVdp69uCuk2vcU+mIg2I8uRWrqV8Iw= X-Received: by 2002:a05:6000:605:b0:48b:910:35c3 with SMTP id ffacd0b85a97d-48b1274c85emr3901407f8f.35.1790931341004; Fri, 02 Oct 2026 01:55:41 -0700 (PDT) Message-ID: <2db46bf6-87e7-4f1f-b440-b73be1f86b55@suse.com> Date: Fri, 2 Oct 2026 10:55:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/6] x86: Remove return value from UPDATE_ENTRY To: Kevin Lampis Cc: Andrew Cooper , "teddy.astie@vates.tech" , "xen-devel@lists.xenproject.org" References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-2-kevin.lampis@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-c1860d/1790931341-CF55C87B-47AC66AF/10/78276251493 X-purgate-type: spam X-purgate-size: 518 On 02.10.2026 10:34, Kevin Lampis wrote: >> This was already committed, wasn't it? > > I'm aware of only one patch that was committed since last time > `[PATCH v2 1/7] x86: make UPDATE_ENTRY() allow for multiple operation flags` https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=5ec86c22b4b3f26eab0fe9af4cbd0f90d315d820 I really failed to include it in the batch I did (as I had somehow lost Andrew's R-b, hence it didn't look ready to commit), but Andrew then kindly covered for my oversight. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 09:23:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 09:23:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438956.1657474 (Exim 4.92) (envelope-from ) id 1xCZUB-0001lf-9V; Fri, 02 Oct 2026 09:23:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438956.1657474; Fri, 02 Oct 2026 09: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 1xCZUB-0001lY-3n; Fri, 02 Oct 2026 09:23:23 +0000 Received: by outflank-mailman (input) for mailman id 1438956; Fri, 02 Oct 2026 09:23:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCZUA-0001lS-Bo for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 09:23:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCZU7-00B42k-1H; Fri, 02 Oct 2026 09:23: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 1xCZU7-00AJlw-1R; Fri, 02 Oct 2026 09:23: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=eipSa4x1K942SwgiW09+SktOn4l3xvv8FkVi/tMDXFA=; b=At7G13rCZ2eBk8Dtkuih3wtrRa h4+yEa5GFdA3yYegYvj+HQGvEW3P7AesbbAqf2G8XrjTNKVjSXBimf240ewt4NGUkdShYienxIieu b5VP5kSs/S5jgjAduMrilyqlINfPLTltYMNQmqOZvW+cY1kG68ibH07lOPmRGJw/vUZY=; Date: Fri, 2 Oct 2026 11:23:17 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain Message-ID: References: <20261001142757.98255-1-roger@xenproject.org> <4eb32155-1b04-4f04-ab9b-f30e584cb033@suse.com> <1226702d-5bb4-4e7a-8e6a-6534002cfd8c@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1226702d-5bb4-4e7a-8e6a-6534002cfd8c@suse.com> On Fri, Oct 02, 2026 at 10:09:02AM +0200, Jan Beulich wrote: > On 02.10.2026 10:05, Roger Pau Monné wrote: > > On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote: > >> On 02.10.2026 09:48, Roger Pau Monné wrote: > >>> On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: > >>>> On 01.10.2026 16:27, Roger Pau Monne wrote: > >>>>> --- a/xen/arch/x86/domain.c > >>>>> +++ b/xen/arch/x86/domain.c > >>>>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) > >>>>> void __init arch_init_idle_domain(struct domain *d) > >>>>> { > >>>>> static const struct arch_csw idle_csw = { > >>>>> - .from = paravirt_ctxt_switch_from, > >>>>> - .to = paravirt_ctxt_switch_to, > >>>>> .tail = idle_loop, > >>>>> }; > >>>> > >>>> Leaving NULL pointers around isn't a good thing, though. May I suggest to > >>>> at least poison the pointers then? > >>> > >>> I don't mind doing so, but I don't think we usually do that for other > >>> hook structures, ie: hvm_function_table for example doesn't poison > >>> unset hooks (and it possibly can't, because there are .hook != NULL > >>> checks). > >>> > >>> TBH I'm missing a benefit of the poisoning here. Using NULL or a > >>> poisoned value will both trigger a page-fault, and NULL has the > >>> benefit of callers easily checking whether the hook is set. > >> > >> NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV > >> one may not, depending on what the guest may have put there. > > > > It still feels a bit arbitrary to do here but not in other places, > > We should imo resolve this by replacing NULLs wherever hooks could, due > to other issues, end up "in sight" on paths reachable for PV guests. This > would then also cover potential speculation along such paths. FTAOD, I plan to introduce a poison value using a non-canonical address, ie: #define POINTER_POISON ((void *)0xDEAD0000DEAD0000UL) in asm/config.h. Would that be acceptable? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 02 09:26:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 09:26:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438965.1657482 (Exim 4.92) (envelope-from ) id 1xCZX4-0002EV-Jf; Fri, 02 Oct 2026 09:26:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438965.1657482; Fri, 02 Oct 2026 09:26: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 1xCZX4-0002EO-GM; Fri, 02 Oct 2026 09:26:22 +0000 Received: by outflank-mailman (input) for mailman id 1438965; Fri, 02 Oct 2026 09:26:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCZX3-0002EI-QC for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 09:26:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCZX3-00Ffmt-5M for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 11:26:21 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf78b7-2eae-0a2a0a5409dd-0a2a4506ddfe-18 for ; Fri, 02 Oct 2026 11:26:21 +0200 Received: from [52.101.84.126] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf78bc-195a-0a2a45060019-3465547e60f8-3 for ; Fri, 02 Oct 2026 11:26:20 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by VI0PR03MB10878.eurprd03.prod.outlook.com (2603:10a6:800:262::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Fri, 2 Oct 2026 09:26:18 +0000 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292%6]) with mapi id 15.21.0451.022; Fri, 2 Oct 2026 09: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=MUsGhvAguR8F/Ll81hLaK4IyT00ep3gD+TIhJh6AQLSJ6QvJK7G0cAW6jQZIUPtsHooG1s8V3GVrtigqLMROwNAEpRK4Ni8MZYmIlM22D02uj7CQPjBjwgTl7ApdIFGSlbzfHqnnj0AuF2E31yYQYSeTA0W26QrCTsfqiynUZABuUgnRH4ERQrCEH/2MKhPU3iigr+FGBHbm6nxiDGrJ/c+N7mjKJzEmjZl0Uedg53GsDAg5zaQNnFcS3L+bIOYmyG8MqOpMh17Qk60oINPtiCRCdGomyw5seLyler0Q99uZgwAvMWDWkcZ+A8IxuWvDEbIzsf10DlEjgD6z+Nq01g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=d7s6X6WnuV0kG9p5KD1YOj8CZuFMb3B7X9fzXZUv7PQ=; b=OQxGeSm/Xi/g4EreMc6bnL9rr118W2N/WRDWGJ2EniwoYZi7vliuw7wnvQSiAeM3ZulNmjbV3tD4/mHaA7H+wSZAYE6S7QOeneho3H31L/cuDGgpTn4hpXPRpBlfu8b/8tFMbRRtJ3Y/j7yy/A339pP3uV2BG6qdnIG74qGo90FrSbWNMU5vFmOqawwUNHQbMEbS23w5hrgvqkXqYCT3cERaWkDlHn8IePHgmeVqa4j0aEHShYj30dZ8eUZdtEe5VNnGobrxGmgntFWRutozZe+HhOMD9yYhrADYrbnw382KQEoZNWPKjEPHsvBWDvFn6k6cRK00Apq+0BDG4sMQmw== 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=d7s6X6WnuV0kG9p5KD1YOj8CZuFMb3B7X9fzXZUv7PQ=; b=vVBZRTv4IXff5YPkPAt3JCtmVCqJl31fprWgNeBCD1coYkZlrAma5yYJQXcuftoLojmjYF4yHxdH+EokqTiKuMah6UAvOuPjgtFVVlw0M67hNTnBM47brtkI5G5E2DkXYO6k/2L1Bm+SOP5/Np8ryvFLwJPRlMDMCl6NvP/k+JbfKRLDBE3ISUcOkx9yH4QLGFMQ6YgJFLQkeLySqtJ2+h7R8kMrN5qFgvKTBOugc+9P71XwcxIy1oL2NCrIJmZkgIr1cQUXiJ4XrW7X3ZxfrAVOJ0xMQhcrlYpSEmY62mqLiFI6pv5oZT3kIDqYu22sLjK6y6qePS8b8IDZDEtZYg== From: Sergiy Kibrik To: "xen-devel@lists.xenproject.org" CC: Sergiy Kibrik , "Daniel P. Smith" Subject: [RESEND PATCH v1] xen/xsm: flask: restore sidtab state on policy load failure Thread-Topic: [RESEND PATCH v1] xen/xsm: flask: restore sidtab state on policy load failure Thread-Index: AQHdUlATCy0sfywDV06Ga65AkQTQHA== Date: Fri, 2 Oct 2026 09:26:17 +0000 Message-ID: <20261002092556.542986-1-Sergiy_Kibrik@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: AS8PR03MB9192:EE_|VI0PR03MB10878:EE_ x-ms-office365-filtering-correlation-id: 1c9abf11-d142-41e0-652e-08df2067366f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|38070700021|10067099003|56012099006|11063799006|18002099003; x-microsoft-antispam-message-info: Fw8wjwhjatM1nKU4b8z9Q6ZVhQJC6lNHF+VYbXI4zzvHjgqhFZoRLV1u9ykAYJVW9XVGEfkhYoRP3lqA5w4wLCy+75hBvfkjg2HxX4n93P5LYViWl2VFAYxEdoIeLGyROARy+5pXFc3FXRE3juQOCRCJRgR6ophmO2whNy7u75tHOtKTwLo3uZaG4H2ghbeJEuklwdAmZkNvRae/Y6JrVMraSXkVNXFSIWTdgwIQ5vNA65TYMdOCXR72jkRZBJgFGqYM0PJopw/+SkbUiDCi3oZFI14yHFbhTcmbq+fepAq97NvBbkxNrfKJs2utJoTZHnLFV9QhWmwsotN37DdFHTT+F9viacPz5PVDcDFD0tTgwR+zBtD7ys5hU2DXevtTCkZ8PzR27gmcjFHlMfFjdNUGtFwfxQoEVmDYAydD3qAzXsdSzWAbniwveTP1gDId8O9Z2hFHJXXbDP65BwCTc+Iav44zpJpt2za365JLC6QYD4ecu5LOEY7/KTwf89KfruC/rgUQ/8Z7nK52Fbk7BMsqTeIW1NeMywPRe1yvVjzojeisr3LlMkJHoC9ef22wqdZO22iNiGozxVB5Z4mO+amsSfWO3MV20HcmwOLv+Qnn2ta8gI6IeXrxEL7V33GRAKK+KuhA4PLQ8u1XCCL9V0Q8OYNNzdjcwn3+2+0sYX0+nK4tuQT/3m4Y5I3oGH/LEwa6apRLDCCq9hTWwfEW2VsEjQAScPktkuvfMzhK7y0= 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)(23010399003)(366016)(376014)(38070700021)(10067099003)(56012099006)(11063799006)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eVdTaUYvT1NNak9JbWNxWGtmR3lOaWdDenR0S2Fwdm1HUDVsSzNMT1IycnlJ?= =?utf-8?B?YVB5YjEyOEpNelJ5bHFUWUdXY0Z5NzNXQzc0V1A4ejBUT21ndmsvK2JFUGpn?= =?utf-8?B?ZjRiN3J4cCtVR0FXQ0xMRGU1RXczc05FQzZFNUdmODhhNWVFY0w4TmdQdG9i?= =?utf-8?B?RDArcmIwQkhUN2svcnl6RFJmUXQxSGtHbFhjRkJiZHY5b2JGelBzeUIvOW1u?= =?utf-8?B?NGV5aytldGdOa3dOYi9VRDVONysyQWJzL3NhcFluSnl1S29YT0R0UC92c3pK?= =?utf-8?B?TGloQkpFQndSSkc4NUlGMWhJY1JVMWZqa0pmZjljNHZzcS9HbFUwRXIxcDlN?= =?utf-8?B?MEdaUjNmOVZaVFA1M2ExUjJDVmxCMjN6SzBWdGlEU0xwQVE0RVljSEkrMXl6?= =?utf-8?B?b2xqc2FabVZHM1pBbHF6amhleGRublpsUThWeXAvMWJZQVVaWVpSTW9wTktK?= =?utf-8?B?SFo5MjFwc0JHQ3hlTGxiY3Nnc1pxc3ZlN05BMTdERzFCREovSHZYazQxVkRY?= =?utf-8?B?cUU0ZmxmNWpTVUZSdFF2WHU0VHVIWXBUVU9NUGc5ektjWElMMjZBNlF0TWtV?= =?utf-8?B?VWdzY1djY2V1UW9MNzgzeXNWVGh0bTRUenB3MHpqVWxsemFEbWw4VTBoTWxX?= =?utf-8?B?Zzd3T3RlUnJjTUY3aW14SWNWQVhReGVCazZIY2xsWjR2M0d5KzBIb1lKTFQy?= =?utf-8?B?ejJMbWFzbCtPVHFmSi8wdnFFdUI4SWdTTzRJdFJEWnZZVCtRV2xsRDVmamxW?= =?utf-8?B?RjAzQyt2dWE3bElqTS94Mk9QL1ZuK0d0cDJoNHowR05aN1l5L3Exc2tPRlAr?= =?utf-8?B?WXFVb3NFakM5cUFxTXVqNDNxOVJqZjV6aXl0SGNIOEF5UDczYTNmRHVHOTRV?= =?utf-8?B?anlIOUo0UWRLOVk2dHlSclozeXVRY3dBOFJsdDh5ZENPZm1pN2dkdFREUHRM?= =?utf-8?B?VGRybW14b214YmRZWWVPQjV2N1BOdHZLNEdQdi9nT0s5MzV0NENnYU9URndS?= =?utf-8?B?OG9WTldYbGNMT0s1dUZ2OCtvTExMMUx1OC9zUnJSQ1pqSWZ0cldyT1NzNGJJ?= =?utf-8?B?dW5JcDlrR0xldDk4cGhhOVhLcXNXVm1OK1NwQ0RrVVJPTjQvOXY3QWY5RlRx?= =?utf-8?B?dmUvMlkzOExOU3ByN2tzd3NWVk5UZ3BFL012amtOSE5JT3J4MkpwSU1OSnd1?= =?utf-8?B?UEl6YmFzZ2ZGZFRRVG5ZTVVWOUxUaXRyNlJJMkFIUDZqS216aUNYai96cmZM?= =?utf-8?B?L3Fua04yR1RpR293MklramlFMW9wdXhSOGxsY0xrbkp3WUZxOCtiSG5yTmU0?= =?utf-8?B?Z1ZqSnFLcy9CaGZIVkRHaWkvejd4NjhFVWVlcXNvem90cjhFL3lCT2p6VXBn?= =?utf-8?B?eXRkaU1rMmlKd1dpbFdDdVJ3K3dvdGFPbVRPb0JNalU2c1MzRjM4N1dDK1lQ?= =?utf-8?B?NUpGaDJSSGVpVnZMTWo0UHhwUFdDMVplSHhzMFZhbFAzTDhwdkdBM0Q4cWE0?= =?utf-8?B?eGFVczlYaFZ2L1lXeDZkSS8vczB4RW13M2F1OGtHN2tFOC9FcWFRT1c4YXV5?= =?utf-8?B?VnNOelBaVGh0UW5PVWJCNWJHY24zRnY2N1hNTFB5TlNsZ1MzZThRSVdsS2pE?= =?utf-8?B?TytxYWJ4TVhpSUR6cmZubTAxZmJvcnFNcktsUTZva200UVVlS3AzbUZaMHlv?= =?utf-8?B?MW1OaTI2YmVrZmFoQmVTRThPV282bTVwa0dkZEhPVzczRVlpbXFWZU5IdzBW?= =?utf-8?B?VE1yZUorMWlRclBhMTJoZzN5ZkdhZHRvNGZrNVpFc00xYW54YXlrbUthQU5G?= =?utf-8?B?ZDdRV1I1V2l3NHNWcHUzY3hwcVlINkpWbUIvWElJK2djM3dCbklickhXUFVw?= =?utf-8?B?bFZoWUYrYXVxOEIrK3lxNzJNTnMvRnhXaXd1RFh1N2IrN0Z3ZTh6WngvdEVR?= =?utf-8?B?U3N1YWZUQXdsOVhyTGRGczM2YXAxdlN3T0NTSFgyYkg0WEhkUGdJRFBNNW9D?= =?utf-8?B?NnJnOGlFbWRmeG84Z2pRU2UxUmdGSnJCa0lnZmNEVGtRdER3YTAwNGFLaC9Q?= =?utf-8?B?UWFlOXhKc0hRd29COUN1SEFxUFQ2OWJHK3RhUEVybkJIWnNLS3Bvc1dicStQ?= =?utf-8?B?OUhvYVFMY0FUVTFjd2NZNzlEem5tK2lRb0hnVmllMUNYaTI4VzVnODBML2k3?= =?utf-8?B?THJHKzB3QUpLbS94Q05SeEltZ2NmVFhkbVJ1Q3craXNoQkRXamNRc1ptVEc2?= =?utf-8?B?dUkyQi9sa3dZaklhUGdTOE1USFNyTmRubkZuV0R1Y1EwSWQzSGJMMzkrYmEy?= =?utf-8?B?TWFZajZ1L2IzWlI3Y0VpS1I3MTRFN2R2UFEyRWN6MWswdDhsRlNVYWZaK1Ni?= =?utf-8?Q?xzwXLyuTtGApOTEk=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: AS8PR03MB9192.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c9abf11-d142-41e0-652e-08df2067366f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2026 09:26:17.6698 (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: leaxsULZFJc3fdx4YDgoCvRcbspRRPY20auA//xIo887V2kwT4xjVUHvbOboTBvyYKubxXhO7IW9N3OpiU4MYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10878 X-purgate-ID: tlsNG-16d1c6/1790933181-F520877B-1E578FC7/0/0 X-purgate-type: clean X-purgate-size: 2932 RXJyb3IgcGF0aCBvZiBmYWlsZWQgc2lkdGFiX21hcCgpIGxlYXZlcyBnbG9iYWwgc2lkdGFiIGlu IHNodXRkb3duIHN0YXRlIGFuZA0KZnJvbSB0aGF0IHBvaW50IHN5c3RlbSBpcyB1bmFibGUgdG8g YWxsb2NhdGUgbmV3IFNJRHMgaW4gc2lkdGFiX2NvbnRleHRfdG9fc2lkKCkuDQpUbyByZXN0b3Jl IHNpZHRhYiBzdGF0ZSBuZXcgZnVuY3Rpb24gc2lkdGFiX2FjdGl2YXRlKCkgaXMgaW50cm9kdWNl ZCwgd2hpY2ggb25seQ0KcmVzZXRzIHNodXRkb3duIGZsYWcsIHJld2luZGluZyBlZmZlY3Qgb2Yg c2lkdGFiX3NodXRkb3duKCkuDQoNClNpZ25lZC1vZmYtYnk6IFNlcmdpeSBLaWJyaWsgPFNlcmdp eV9LaWJyaWtAZXBhbS5jb20+DQotLS0NCk5ldyBmdW5jdGlvbiBpcyBub3Qgc3RyaWN0bHkgcmVx dWlyZWQsIHRoaXMgYWxzbyBjYW4gYmUgYWNoaWV2ZWQganVzdCBieQ0KZG9pbmcgc2lkdGFiX3Nl dCgmc2lkdGFiLCAmc2lkdGFiKSwgYnV0IHRoaXMgd2F5IHdlIHdvdWxkIHJlbHkgb24gaXRzDQp1 bmRvY3VtZW50ZWQgaW50ZXJuYWwgYmVoYXZpb3VyLg0KLS0tDQogeGVuL3hzbS9mbGFzay9zcy9z ZXJ2aWNlcy5jIHwgMSArDQogeGVuL3hzbS9mbGFzay9zcy9zaWR0YWIuYyAgIHwgNyArKysrKysr DQogeGVuL3hzbS9mbGFzay9zcy9zaWR0YWIuaCAgIHwgMSArDQogMyBmaWxlcyBjaGFuZ2VkLCA5 IGluc2VydGlvbnMoKykNCg0KZGlmZiAtLWdpdCBhL3hlbi94c20vZmxhc2svc3Mvc2VydmljZXMu YyBiL3hlbi94c20vZmxhc2svc3Mvc2VydmljZXMuYw0KaW5kZXggMzVhZDEwMzRjYS4uZjVjZWUx ZTBiMCAxMDA2NDQNCi0tLSBhL3hlbi94c20vZmxhc2svc3Mvc2VydmljZXMuYw0KKysrIGIveGVu L3hzbS9mbGFzay9zcy9zZXJ2aWNlcy5jDQpAQCAtMTQyNyw2ICsxNDI3LDcgQEAgaW50IHNlY3Vy aXR5X2xvYWRfcG9saWN5KGNvbnN0IHZvaWQgKmRhdGEsIHNpemVfdCBsZW4pDQogICAgIGlmICgg c2lkdGFiX21hcCgmc2lkdGFiLCBjbG9uZV9zaWQsICZuZXdzaWR0YWIpICkNCiAgICAgew0KICAg ICAgICAgcmMgPSAtRU5PTUVNOw0KKyAgICAgICAgc2lkdGFiX2FjdGl2YXRlKCZzaWR0YWIpOw0K ICAgICAgICAgZ290byBlcnI7DQogICAgIH0NCiANCmRpZmYgLS1naXQgYS94ZW4veHNtL2ZsYXNr L3NzL3NpZHRhYi5jIGIveGVuL3hzbS9mbGFzay9zcy9zaWR0YWIuYw0KaW5kZXggNjlmYzMzODli My4uNWQxNjUzY2QwMiAxMDA2NDQNCi0tLSBhL3hlbi94c20vZmxhc2svc3Mvc2lkdGFiLmMNCisr KyBiL3hlbi94c20vZmxhc2svc3Mvc2lkdGFiLmMNCkBAIC0zMTQsNiArMzE0LDEzIEBAIHZvaWQg c2lkdGFiX3NldChzdHJ1Y3Qgc2lkdGFiICpkc3QsIHN0cnVjdCBzaWR0YWIgKnNyYykNCiAgICAg U0lEVEFCX1VOTE9DSyhzcmMpOw0KIH0NCiANCit2b2lkIHNpZHRhYl9hY3RpdmF0ZShzdHJ1Y3Qg c2lkdGFiICpzKQ0KK3sNCisgICAgU0lEVEFCX0xPQ0socyk7DQorICAgIHMtPnNodXRkb3duID0g MDsNCisgICAgU0lEVEFCX1VOTE9DSyhzKTsNCit9DQorDQogdm9pZCBzaWR0YWJfc2h1dGRvd24o c3RydWN0IHNpZHRhYiAqcykNCiB7DQogICAgIFNJRFRBQl9MT0NLKHMpOw0KZGlmZiAtLWdpdCBh L3hlbi94c20vZmxhc2svc3Mvc2lkdGFiLmggYi94ZW4veHNtL2ZsYXNrL3NzL3NpZHRhYi5oDQpp bmRleCAwZTQ4ZWM2ZWFlLi41ZDJkYzljN2UxIDEwMDY0NA0KLS0tIGEveGVuL3hzbS9mbGFzay9z cy9zaWR0YWIuaA0KKysrIGIveGVuL3hzbS9mbGFzay9zcy9zaWR0YWIuaA0KQEAgLTQ4LDYgKzQ4 LDcgQEAgaW50IHNpZHRhYl9jb250ZXh0X3RvX3NpZChzdHJ1Y3Qgc2lkdGFiICpzLCBzdHJ1Y3Qg Y29udGV4dCAqY29udGV4dCwgdTMyICpzaWQpOw0KIHZvaWQgc2lkdGFiX2hhc2hfZXZhbChzdHJ1 Y3Qgc2lkdGFiICpoLCBjaGFyICp0YWcpOw0KIHZvaWQgc2lkdGFiX2Rlc3Ryb3koc3RydWN0IHNp ZHRhYiAqcyk7DQogdm9pZCBzaWR0YWJfc2V0KHN0cnVjdCBzaWR0YWIgKmRzdCwgc3RydWN0IHNp ZHRhYiAqc3JjKTsNCit2b2lkIHNpZHRhYl9hY3RpdmF0ZShzdHJ1Y3Qgc2lkdGFiICpzKTsNCiB2 b2lkIHNpZHRhYl9zaHV0ZG93bihzdHJ1Y3Qgc2lkdGFiICpzKTsNCiANCiAjZW5kaWYgICAgLyog X1NTX1NJRFRBQl9IXyAqLw0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Fri Oct 02 09:29:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 09:29:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438970.1657491 (Exim 4.92) (envelope-from ) id 1xCZa4-0002pn-07; Fri, 02 Oct 2026 09:29:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438970.1657491; Fri, 02 Oct 2026 09:29: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 1xCZa3-0002pg-T0; Fri, 02 Oct 2026 09:29:27 +0000 Received: by outflank-mailman (input) for mailman id 1438970; Fri, 02 Oct 2026 09:29:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCZa3-0002pa-9P for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 09:29:27 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCZa0-00B49v-0w; Fri, 02 Oct 2026 09:29: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 1xCZa0-00ALzJ-0d; Fri, 02 Oct 2026 09:29: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=HQTkvW4crQrLD5QsKVOBIYliSOuz7b2d8MPIBDXnBTE=; b=ECd6g9PhWw0UAR5q2ZMx9CRbZe PN/DvIEecEXY2J1n1Cv40YNi3gZk9k07hLwtkmlBDIv5d2+V7bbN3D0Vzfhg/nnE3R+jxRtqdoiVx ShDXR1RrhVqf8tmRe280BfHRvGJgUTC8pjXuMNRSq5B/AtLS44TrI3j1CCWXmm3gkDyQ=; Date: Fri, 2 Oct 2026 11:29:22 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain Message-ID: References: <20261001142757.98255-1-roger@xenproject.org> <4eb32155-1b04-4f04-ab9b-f30e584cb033@suse.com> <1226702d-5bb4-4e7a-8e6a-6534002cfd8c@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, Oct 02, 2026 at 11:23:17AM +0200, Roger Pau Monné wrote: > On Fri, Oct 02, 2026 at 10:09:02AM +0200, Jan Beulich wrote: > > On 02.10.2026 10:05, Roger Pau Monné wrote: > > > On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote: > > >> On 02.10.2026 09:48, Roger Pau Monné wrote: > > >>> On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: > > >>>> On 01.10.2026 16:27, Roger Pau Monne wrote: > > >>>>> --- a/xen/arch/x86/domain.c > > >>>>> +++ b/xen/arch/x86/domain.c > > >>>>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) > > >>>>> void __init arch_init_idle_domain(struct domain *d) > > >>>>> { > > >>>>> static const struct arch_csw idle_csw = { > > >>>>> - .from = paravirt_ctxt_switch_from, > > >>>>> - .to = paravirt_ctxt_switch_to, > > >>>>> .tail = idle_loop, > > >>>>> }; > > >>>> > > >>>> Leaving NULL pointers around isn't a good thing, though. May I suggest to > > >>>> at least poison the pointers then? > > >>> > > >>> I don't mind doing so, but I don't think we usually do that for other > > >>> hook structures, ie: hvm_function_table for example doesn't poison > > >>> unset hooks (and it possibly can't, because there are .hook != NULL > > >>> checks). > > >>> > > >>> TBH I'm missing a benefit of the poisoning here. Using NULL or a > > >>> poisoned value will both trigger a page-fault, and NULL has the > > >>> benefit of callers easily checking whether the hook is set. > > >> > > >> NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV > > >> one may not, depending on what the guest may have put there. > > > > > > It still feels a bit arbitrary to do here but not in other places, > > > > We should imo resolve this by replacing NULLs wherever hooks could, due > > to other issues, end up "in sight" on paths reachable for PV guests. This > > would then also cover potential speculation along such paths. > > FTAOD, I plan to introduce a poison value using a non-canonical > address, ie: > > #define POINTER_POISON ((void *)0xDEAD0000DEAD0000UL) s/POINTER_POISON/FUNCTION_POISON/ From xen-devel-bounces@lists.xenproject.org Fri Oct 02 09:34:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 09:34:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438978.1657500 (Exim 4.92) (envelope-from ) id 1xCZei-0004OU-GR; Fri, 02 Oct 2026 09:34:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438978.1657500; Fri, 02 Oct 2026 09:34: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 1xCZei-0004ON-DG; Fri, 02 Oct 2026 09:34:16 +0000 Received: by outflank-mailman (input) for mailman id 1438978; Fri, 02 Oct 2026 09:34:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCZeg-0004OH-Ql for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 09:34:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCZeg-000ulI-7e for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 11:34:14 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf7a95-2eae-0a2a0a5409dd-0a2a45019d24-4 for ; Fri, 02 Oct 2026 11:34:14 +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 6abf7a95-5984-0a2a45010019-4a7de18c8cd3-3 for ; Fri, 02 Oct 2026 11:34:14 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-4a006bb267eso30125695e9.0 for ; Fri, 02 Oct 2026 02:34: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-4a0280ceaf0sm70460885e9.12.2026.10.02.02.34.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2026 02: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=1790933653; x=1791538453; 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=x8seD/btZiuLzI3+E4vrqlkh3gz/VjinHO1PlyRwkls=; b=MFAshPhRX9g+qbMRDpYidwcyqMS90fhWeEO2AGIDdGabxIMUaaTGBMyd2UVsgZPkC7 btW1obm394LV5Ye6rdzfK1o4ekRXwI+xrPRdx3HlU9Y5s9Ov+CqK68pgV8sTAj7YBXVN 4O0D7ExOv/to/4C32Eighq40nL8nK/0iPo8bmUvsIqVmVKszthAyIquKMR1R88OGMoZ3 v1JG1e0KWXOj16thRxH8lk3JBluegw41ruBdDQCV24f2eplLfmZxiumuLLs099xJMwqX dcAK42yI+5n03mHa5x483EUv/BAMkNs1txAoPGOoNW1QkflVcj7vSCfRJF4wVyncCAfZ WZHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790933653; x=1791538453; 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=x8seD/btZiuLzI3+E4vrqlkh3gz/VjinHO1PlyRwkls=; b=ByKP5zu7OzkA3xQwY7eVKIFYqaWDgPzz/HcETISKruirU+TBszi0mCeh61iIHKV6Ct BtMFRKH2SqQkaOHLNArAMYS1MhSyyAmzMESvnwTTP8gbcyuv7BPQ5rb5BhYdxsht8c/x jJiGFuOhT7zdhWTEaWN2TrWrsnE+Yg4mNJdpHmp/XOaKFTtr3TFXXjdSGeAqTidmLbgK BWllWGmqoHtoc0unLHTJB5NlfZwxEdq+FR02URUxRFhusy9FofAb09khR0nftUOrJvyU LALl/GtymD+IBzqyP6kqeHEnfN/RF/sC+qq7R9zVkmqK33eRDG7zIq0cV72syGlKfKRw F3/Q== X-Forwarded-Encrypted: i=1; AKwUvBwsqcNGii066p6AtL5VgUS0wEjNuBRyCuBd8w7pXiyofa1osqzWmv/m4hFGvHi6RNTMRwn1L2tJpeM=@lists.xenproject.org X-Gm-Message-State: AFuF++k8vB1nIzOr38nXqSJpabzHT0EjjbZxzlsPqS2pdMLYSiAJ8ZJE 1+7TlNIwiSTWfAZtMcOI7bpX/FeNuyjJUMBZ8nONVv46MqrxEnteCI/bZXFqac+3nw== X-Gm-Gg: AYBFou1zQ+S7HWrJFU93KHlsqo9xbmIfNed9y1jWD+Nxklw+jo1mXv6buSWnzBn0DCS DGbhyJfoPZ3rUk2loJHgOhUtkFjogGOfii8mXbq/cOG14d6eBZYn1sxreHpv2ih2z1wDNVpkYuP YU0AAXmdvBuj4p9xYOMySe1NXnPlf9D85xVkuULrcAHUqG6mgqJE3MMykYSGPtsU0kh+ZnW5Iuy t2/eF7M2+qKZSFT0+4tBUNzrEigSHt1KriZl1vAT757Zu5cRRUbOygC1cElxuy3Ma0vIvRtFtvx 29s9eEy7xPCLqTDwaKUI5ArH6745F3xOipYuRP4BY8FQV96YgzLmbrO3oBZAFS+XodtpiU5ZHX2 D8hsVYPlJvHmZCJ5WM5L/eEwGT8mvnn2+Vv1IUAJVu4Pa2eotMZ1iQ1uxezF2oIpkJ9q2kmLhVb RbwoiuzgnfO61GZZX7QCRcDB+2aTs960YIazzOGS8+eL8/gRvUobiKNpFAvrxM6qfDqcsMLmvak FPqfXVa+3Hlk5ZTkOM/zwiIsj2ulbdXwk+74mEd6/cGZrOx9SJga/8CpQTpQSc= X-Received: by 2002:a05:600c:1908:b0:49f:fc13:18a5 with SMTP id 5b1f17b1804b1-4a0276a1f07mr35309715e9.6.1790933653192; Fri, 02 Oct 2026 02:34:13 -0700 (PDT) Message-ID: <0787063a-ca04-437b-9bd9-307fa084007e@suse.com> Date: Fri, 2 Oct 2026 11:34:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v1] xen/xsm: flask: restore sidtab state on policy load failure To: Sergiy Kibrik Cc: "Daniel P. Smith" , "xen-devel@lists.xenproject.org" References: <20261002092556.542986-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: <20261002092556.542986-1-Sergiy_Kibrik@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1790933654-BEC61757-3D985E22/10/78276251493 X-purgate-type: spam X-purgate-size: 876 On 02.10.2026 11:26, Sergiy Kibrik wrote: > Error path of failed sidtab_map() leaves global sidtab in shutdown state and > from that point system is unable to allocate new SIDs in sidtab_context_to_sid(). > To restore sidtab state new function sidtab_activate() is introduced, which only > resets shutdown flag, rewinding effect of sidtab_shutdown(). > > Signed-off-by: Sergiy Kibrik > --- > New function is not strictly required, this also can be achieved just by > doing sidtab_set(&sidtab, &sidtab), but this way we would rely on its > undocumented internal behaviour. > --- > xen/xsm/flask/ss/services.c | 1 + > xen/xsm/flask/ss/sidtab.c | 7 +++++++ > xen/xsm/flask/ss/sidtab.h | 1 + > 3 files changed, 9 insertions(+) Nothing is being said as to the reason of this resend. Was this perhaps meant to be a ping? Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 09:35:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 09:35:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438984.1657509 (Exim 4.92) (envelope-from ) id 1xCZg9-0004uW-U9; Fri, 02 Oct 2026 09:35:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438984.1657509; Fri, 02 Oct 2026 09:35: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 1xCZg9-0004uO-Qf; Fri, 02 Oct 2026 09:35:45 +0000 Received: by outflank-mailman (input) for mailman id 1438984; Fri, 02 Oct 2026 09:35:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCZg8-0004uG-CN for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 09:35:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCZg7-00BsMu-PU for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 11:35:43 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf7aee-e002-0a2a0a5209dd-0a2a450ba39e-8 for ; Fri, 02 Oct 2026 11:35:43 +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 6abf7aef-b7e8-0a2a450b0019-4a7de18d9d2e-3 for ; Fri, 02 Oct 2026 11:35:43 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7d2bb404so15689655e9.1 for ; Fri, 02 Oct 2026 02:35: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 5b1f17b1804b1-4a0276f92d9sm68484375e9.4.2026.10.02.02.35.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2026 02:35: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=1790933743; x=1791538543; 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=ALf/05Xs/WcvJ/weuu2xekTsOp4EceD5pur5DkQi6Rc=; b=bP6sGTIvGrXcLWBSG/ZaDcgYyov4mgrfs+Kj3l29V+Dnd67iXkDVRORuNcaHbUhnSA NHKzBICj3XBvsKAU8kNTaGgtio9Gp/arrRgPxDIeqZ7FcEWeh+iQkRkpSTdIL8rr/GoV nMgsDZ7JWyfMPwIO1aig1cMb21rcKINhrXfYkGhsERIjHcOhMhtmGuHA29rJfFzg/+3q JbfU9Ln0ovSbKBZVgiX8RRkduVzdhG46VdXG28RAew1au1iCoOjgUDf2+KyKRhU6J85n oLkA965TmIJxaJIGWg3U12R6VZYodQ2uozWYu9j1qEWq9CuPrcAAC/aTvn/wf2Q/1E1d nxzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790933743; x=1791538543; 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=ALf/05Xs/WcvJ/weuu2xekTsOp4EceD5pur5DkQi6Rc=; b=nR6Ma53h3TC0OboUJNGEBYJd0I/aijXApkRLdLie2lo6m59czQIIx6Tj9SWJSURtFe Nx8TBM+KxVYLmrqFh40vY5i8xu+TZUTNcc1RGrzvbKzPV+DBREnYcWEJs2Yo1daI87my kqGfJgBYyQlDc1DbiXGNC5eXa7Z41667qpYybtLDwUSsKBoFmjg13QDMFJY/sH1LDqLH Fam6AmAsfluVQGlgAiNDPw4e26EapkQJkaxhMU6ZlXU4eaWm2OJC2VpU0rIl2Gfnd8oh tIVuknMY277JpxyPNFx1eNBVG5I3+DVmeLamvllMssEeubqpEKMtQOS+kvPEn+XQJ1i4 PWkg== X-Forwarded-Encrypted: i=1; AKwUvBwdSsvhwhcUaoaRLnyp25ZJShvg7r+HqmsNhE8caeigy3EiJ/t0cQxni8PdLiYEfq2osnBedtiMowg=@lists.xenproject.org X-Gm-Message-State: AFuF++lKhJTOzKgOAwkc9bKrrSCN1Zqz3beavDeOVpcXQWrmoOLGvDuu Q5U/xas09cfRMfAp1KU/dW5xIm0m5nP0sa6pZU++bH97s55bagOzoCHjIJkGxUPMAztnBELBArO dM2wLCA== X-Gm-Gg: AYBFou0SfmsSmSO63IwnF8w4XMDeeADpwbl2KDYy5i1fXMw9rbckTpPcmCodoQTw7GW wqVYn21bfxrdeeSw+P+7q0mxj3Jydy+WrFHnAOZQUaVMGauLI44QZQisiy+HpNETTBQHLV0ZoWQ PeNWxASgTtvOZFccQcQZzzI0kuqB9IXetEmcbNndx4IYWa2iCthmfuN+XBmCrKi2k7wlBJeN3bQ TMbNPONWud4tnoO1I1hHasS5702ukDd845s++ZlBI2gLJTkZBFXfscT/1I3Qnm55aqY8YZcR5yo XrrVlxplMI+oTFca8ky+0Qk++sEY91kfvVHcFSUjy3d10Y0kB8oEI1jQ0e+xUfD0lqUFqCyqi2n lSOv+TwTASCLi87RuX/GEbGkEwGo2rK+gOWKaKZSQhT9afZyqr8WsdMgwWFp2abryuEPI6Q2jXt +wMFoirkBtNzyee9WiuQDKbquym/q7D+UGEO9SHmOrMngyViFe3Y7yB2rGaNy7KFoN0EBLP/nb1 XmRNOvdNJJcDHFDGwL+kKNWfIKKQhQVDdlUInZfGyRLNz9ECFB5CyI8FqW+mD4= X-Received: by 2002:a05:600c:a10b:b0:49e:6865:904e with SMTP id 5b1f17b1804b1-4a02754fcddmr29772325e9.12.1790933741969; Fri, 02 Oct 2026 02:35:41 -0700 (PDT) Message-ID: Date: Fri, 2 Oct 2026 11:35:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org References: <20261001142757.98255-1-roger@xenproject.org> <4eb32155-1b04-4f04-ab9b-f30e584cb033@suse.com> <1226702d-5bb4-4e7a-8e6a-6534002cfd8c@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-42698a/1790933743-1BED69EA-A4747CE4/10/78276251493 X-purgate-type: spam X-purgate-size: 2308 On 02.10.2026 11:29, Roger Pau Monné wrote: > On Fri, Oct 02, 2026 at 11:23:17AM +0200, Roger Pau Monné wrote: >> On Fri, Oct 02, 2026 at 10:09:02AM +0200, Jan Beulich wrote: >>> On 02.10.2026 10:05, Roger Pau Monné wrote: >>>> On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote: >>>>> On 02.10.2026 09:48, Roger Pau Monné wrote: >>>>>> On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: >>>>>>> On 01.10.2026 16:27, Roger Pau Monne wrote: >>>>>>>> --- a/xen/arch/x86/domain.c >>>>>>>> +++ b/xen/arch/x86/domain.c >>>>>>>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) >>>>>>>> void __init arch_init_idle_domain(struct domain *d) >>>>>>>> { >>>>>>>> static const struct arch_csw idle_csw = { >>>>>>>> - .from = paravirt_ctxt_switch_from, >>>>>>>> - .to = paravirt_ctxt_switch_to, >>>>>>>> .tail = idle_loop, >>>>>>>> }; >>>>>>> >>>>>>> Leaving NULL pointers around isn't a good thing, though. May I suggest to >>>>>>> at least poison the pointers then? >>>>>> >>>>>> I don't mind doing so, but I don't think we usually do that for other >>>>>> hook structures, ie: hvm_function_table for example doesn't poison >>>>>> unset hooks (and it possibly can't, because there are .hook != NULL >>>>>> checks). >>>>>> >>>>>> TBH I'm missing a benefit of the poisoning here. Using NULL or a >>>>>> poisoned value will both trigger a page-fault, and NULL has the >>>>>> benefit of callers easily checking whether the hook is set. >>>>> >>>>> NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV >>>>> one may not, depending on what the guest may have put there. >>>> >>>> It still feels a bit arbitrary to do here but not in other places, >>> >>> We should imo resolve this by replacing NULLs wherever hooks could, due >>> to other issues, end up "in sight" on paths reachable for PV guests. This >>> would then also cover potential speculation along such paths. >> >> FTAOD, I plan to introduce a poison value using a non-canonical >> address, ie: >> >> #define POINTER_POISON ((void *)0xDEAD0000DEAD0000UL) > > s/POINTER_POISON/FUNCTION_POISON/ Sure, if you think none of the present poisoning values we have is good to reuse here. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 09:49:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 09:49:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1438995.1657518 (Exim 4.92) (envelope-from ) id 1xCZtj-0006fr-2A; Fri, 02 Oct 2026 09:49:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1438995.1657518; Fri, 02 Oct 2026 09:49: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 1xCZti-0006fg-Ux; Fri, 02 Oct 2026 09:49:46 +0000 Received: by outflank-mailman (input) for mailman id 1438995; Fri, 02 Oct 2026 09:49:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCZtg-0006fa-PR for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 09:49:44 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCZtd-00B4aq-0Y; Fri, 02 Oct 2026 09:49: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 1xCZtd-00ATs4-0L; Fri, 02 Oct 2026 09:49: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" 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=g3AevK3NjJApXLc9lNvG8st2ygKRpA0rHjwXXRWiKuQ=; b=2yoBsCI0GazLjvPtPsxZxxAZ6W p8lJbDFBYuAE0PaKWF7L7uEUHogmUrWPiYPe2VqpGOO0bbhkChfpjie088Qcfpjf8iElAS+LIiYh+ kJNIz4nRk3hba3ezAQogQJ6Pfzy37RFDOsq4sFORV3v7SJKwANHC6AWvPNUG6QHVdSxM=; Date: Fri, 2 Oct 2026 11:49:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain Message-ID: References: <20261001142757.98255-1-roger@xenproject.org> <4eb32155-1b04-4f04-ab9b-f30e584cb033@suse.com> <1226702d-5bb4-4e7a-8e6a-6534002cfd8c@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, Oct 02, 2026 at 11:35:40AM +0200, Jan Beulich wrote: > On 02.10.2026 11:29, Roger Pau Monné wrote: > > On Fri, Oct 02, 2026 at 11:23:17AM +0200, Roger Pau Monné wrote: > >> On Fri, Oct 02, 2026 at 10:09:02AM +0200, Jan Beulich wrote: > >>> On 02.10.2026 10:05, Roger Pau Monné wrote: > >>>> On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote: > >>>>> On 02.10.2026 09:48, Roger Pau Monné wrote: > >>>>>> On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote: > >>>>>>> On 01.10.2026 16:27, Roger Pau Monne wrote: > >>>>>>>> --- a/xen/arch/x86/domain.c > >>>>>>>> +++ b/xen/arch/x86/domain.c > >>>>>>>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) > >>>>>>>> void __init arch_init_idle_domain(struct domain *d) > >>>>>>>> { > >>>>>>>> static const struct arch_csw idle_csw = { > >>>>>>>> - .from = paravirt_ctxt_switch_from, > >>>>>>>> - .to = paravirt_ctxt_switch_to, > >>>>>>>> .tail = idle_loop, > >>>>>>>> }; > >>>>>>> > >>>>>>> Leaving NULL pointers around isn't a good thing, though. May I suggest to > >>>>>>> at least poison the pointers then? > >>>>>> > >>>>>> I don't mind doing so, but I don't think we usually do that for other > >>>>>> hook structures, ie: hvm_function_table for example doesn't poison > >>>>>> unset hooks (and it possibly can't, because there are .hook != NULL > >>>>>> checks). > >>>>>> > >>>>>> TBH I'm missing a benefit of the poisoning here. Using NULL or a > >>>>>> poisoned value will both trigger a page-fault, and NULL has the > >>>>>> benefit of callers easily checking whether the hook is set. > >>>>> > >>>>> NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV > >>>>> one may not, depending on what the guest may have put there. > >>>> > >>>> It still feels a bit arbitrary to do here but not in other places, > >>> > >>> We should imo resolve this by replacing NULLs wherever hooks could, due > >>> to other issues, end up "in sight" on paths reachable for PV guests. This > >>> would then also cover potential speculation along such paths. > >> > >> FTAOD, I plan to introduce a poison value using a non-canonical > >> address, ie: > >> > >> #define POINTER_POISON ((void *)0xDEAD0000DEAD0000UL) > > > > s/POINTER_POISON/FUNCTION_POISON/ > > Sure, if you think none of the present poisoning values we have is good to > reuse here. They maybe could, but I assumed we wanted differentiation between this usage and ZERO_BLOCK_PTR for example. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 02 10:03:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 10:03:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439005.1657526 (Exim 4.92) (envelope-from ) id 1xCa6Y-0000wh-4N; Fri, 02 Oct 2026 10:03:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439005.1657526; Fri, 02 Oct 2026 10:03: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 1xCa6Y-0000wa-1m; Fri, 02 Oct 2026 10:03:02 +0000 Received: by outflank-mailman (input) for mailman id 1439005; Fri, 02 Oct 2026 10:03:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCa6W-0000wP-T0 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:03:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCa6W-00HCGf-5u for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 12:03:00 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf814b-bab6-0a2a0a5309dd-0a2a4508959e-36 for ; Fri, 02 Oct 2026 12:02:59 +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 6abf8153-f659-0a2a45080019-4a7de44c99c0-3 for ; Fri, 02 Oct 2026 12:02:59 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a996c8adf3so12001024a12.1 for ; Fri, 02 Oct 2026 03:02: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:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790935379; cv=none; d=google.com; s=arc-20260327; b=NBrNJT3SNylVyPmgyyFf7sNZ2XEo+2r9h+BlGsA9xcJ5grxNOI12n2u1yj4WfnFDIa FbqLWlBORIvAsvHEsfLA8l5STTP1WuVfFg3AqTcX7eHWM85FYmyiYxl+HsHoozDONZOI qNTvE+6OGHnOmXWy2xP+FPqbzVCV4E7kv5/FB8vdf+dq+r/4olOs97MH/2Tn6EBf9L3o Yzxt+UFxVSZ9GF1IKDPquQsycoFulK5G+gMP9/Cpj29zS5+L/+cxxqhklF5NoQacm+2n DOdz2lVv7RmnI/gY6DMK+Mv8e9gW8E0XCJ9rSev+U+d0bgEUGhOse1oiaE5a2ybLufnx P45g== 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=4ZPz+Sdy14wB6XVIc9+haG6Un5+fqxeMpVNAIkEEEwo=; fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=; b=JLC1ryh1Dot0h8SCir2/eqol4HIufTyG1vJRPlEW/CatpSQX7BbWofYB2Eab87gZ2i B0Wp3YgXd1+mxcWiADq7dj8inEb35GGK8PSDPuQA1vtwoBK7r9ZqhK6QiYQKZFMfehSz wCFB1gmgWtYl5RpKrwS+g00UQuWYT41G8INjBNJdxiNR9ciIUvfBVgRucS6WXXJ/2Y2F WbwIWLV3pOGQFg9twY0b0PZT49/Z7ev9YXau5ZNi6Cw2Xo0k5pnu8r9QoGlX97HQHVv9 zVdFrUFo6O6Tw1veyuEK2f4y6QPyapgTs+gXKP0tM4SlTKnuBuJ3dJYdFTzMIWzE9ZCk 9p8Q==; 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=1790935379; x=1791540179; 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=4ZPz+Sdy14wB6XVIc9+haG6Un5+fqxeMpVNAIkEEEwo=; b=iK72REeDqaI1pVxwqaire/HXf2KaxLu1Txkia7vpINgs8bXL4zi3vvIc+IlFSsVCab aO1Yu2U5UpZ5eOQrK8yGxbD9QUus0+IMedKewmucns/UuDalC6XKgyYz6/E4TXfbL2lW MaEw9owKm5S3BiH+oBTSgXTVt36yKf5NezGlGBbOVvDFKMggQ59fGA/xOha8fIYHV+o2 aPfw//6Y+yP6WQurMDxWJIw2ZQs4pQ+CVfeP0wKv+uKvqkORVGUi9ZgaWOAGr/iJDNIG 7j1dPgyzTR382JVLG4NQGIUwP/di3AlLC8X3RAZKlm83eC5Jpw3659B+7pStd1tgSMFm rFkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790935379; x=1791540179; 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=4ZPz+Sdy14wB6XVIc9+haG6Un5+fqxeMpVNAIkEEEwo=; b=I1FToL8PyDoNcrBxkFtY7+S4r3I8OjKvDAND+O+MfVkBzdj+p7hzN8hZqOHGnUc8jB BlvsQOdaJRxBVIGNFXnci+YuPvFDcVGV/F60e8sjwKL9GYsKLdAleRvwNF8ThPBp4AzD p9NSkeHDI9g/H3kTyynD+na+qT50WGb5AlzS97krTSvNYqo1fNzHMIVPflKpvtdQ5eQJ hWsiNU1XLgLGndeQDdxNw7bPEOpJC1KHyPlpPeUFe7/IvsI311J5Oss1Wd108S1dX5SC FALoC1TOoOCJplQWPluntXV6T7h0gLEtNL3Rw/TONrPYTjAyJBveO+byTuuhLodHbP7u b1Pg== X-Gm-Message-State: AFq9FYKPKQB0qL11YP3ZwyteHVq6jnmlt7Eu6kwEcR+KF7hT6z2YZvbE 1JWahK0zbo03Ln20tBXkVbgeBNRBKS79nnayIs5vqaAeP3+yHMn4tTe5kI7Bt6vAnwJqMNvkI7Y +Rx65siuwt82gU93bpXGQ06uQ0LGsCbVYLIq0 X-Gm-Gg: AYBFou1IT/XLEul1dvYLZbBTssg8da1NeJ7aYXGJOz2Gh5adbvNmF1N2P9zF21Nss/c TdSmzkWjPhZamN989wa7z2UdULbobn21bpCZe5M5l4SoMIR1eJ5X73oFYHWo43tju9So22muR9q xkfgW4xKzexOuGKXWqF5NW43CgioWRmSyAmitMObK8/OlAXFdFXAGhg6EfE8axZ+Rthm8VnMVrW qnqofcoP1KvT53q2JsrA8OkG1KutFmzA29z3GLAxkOIp/G2X5S2rlKL+Vgm04aICAgjBQcD09mZ pGuUsW0GKgz/+5Z9NZc3O5rNVWqWrsK+qYZ1WFElkcigVM8uj2zGPPtR X-Received: by 2002:a05:6402:27c9:b0:6ab:6f77:c4eb with SMTP id 4fb4d7f45d1cf-6af9e362590mr1285805a12.37.1790935378838; Fri, 02 Oct 2026 03:02:58 -0700 (PDT) MIME-Version: 1.0 From: r4ahim Date: Fri, 2 Oct 2026 11:02:47 +0100 X-Gm-Features: AclHuK8HG6fcKIeNFISIhkcGtsb6H2SFfm7QtoC5Fc56lgVcIh8avYnH1fD8S5o Message-ID: Subject: Newcomer looking for a small first task To: xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c1860d/1790935379-CD34D87B-D1021705/0/0 X-purgate-type: clean X-purgate-size: 331 Hi, I'm new to Xen, running it under QEMU (Xen builds and Dom0 boots). I'm preparing my first patch and I'm most interested in PCI passthrough, vPCI and the IOMMU, but I'm happy to start anywhere. Is there a small unclaimed item (a MISRA violation, docs fix or XTF test) that I could take? Thanks, Abderrahim Meriah From xen-devel-bounces@lists.xenproject.org Fri Oct 02 10:25:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 10:25:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439019.1657536 (Exim 4.92) (envelope-from ) id 1xCaSH-0003hS-Qg; Fri, 02 Oct 2026 10:25:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439019.1657536; Fri, 02 Oct 2026 10: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 1xCaSH-0003hL-Nx; Fri, 02 Oct 2026 10:25:29 +0000 Received: by outflank-mailman (input) for mailman id 1439019; Fri, 02 Oct 2026 10:25:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCaSG-0003hF-3y for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:25:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCaSF-00HG7f-H1 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 12:25:27 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf8697-e002-0a2a0a5209dd-0a2a4506ad9c-2 for ; Fri, 02 Oct 2026 12:25:27 +0200 Received: from [52.101.65.138] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf8696-195a-0a2a45060019-3465418afdff-3 for ; Fri, 02 Oct 2026 12:25:27 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by AS2PR03MB9670.eurprd03.prod.outlook.com (2603:10a6:20b:5e9::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.15; Fri, 2 Oct 2026 10:25:22 +0000 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292%6]) with mapi id 15.21.0451.022; Fri, 2 Oct 2026 10:25: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=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/obR++SAI1xc5NlNsLB2VfzH2CEVbQIao07mNT2X+byhF7TTOnNrBiqTajJHgrOYt1MpZaF6r6PX/axUmPEmFZZLq/6bzjRG4a0VQOa5UVxfUTLO5pDytc3wRYQ9QKumY3r39xNnlFsWjR0gHQcAa00NUTr6S3d9diY+4NHJZ5beOXbtQMu6yRqT+6SiE8v++ikFpOzOMP8QaQAx0lsp2jdWlISzr4rz3OS+hEPZtJWLqOOjXoEDKA8gKYrV8On10EGFTN/1MkqaX/LnXcbW5yxEb1qmBCtT0r8MhutAdZ9o5BQMh7hVj4a186FujlVVRbAUFePe+wFdY4pAUclUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=91sCiVVbEEgxdXzk1w+Mjs8LUZDR9Ye82bW536CrQmU=; b=xgURX4r7QbQolIlv9sM8jS/KvGwvGa7jtHQ85uFfLeLAvKPOHaZgIAa426ORO9znQ+oDrMycja8KoEljpORDQDoBVsKLPLcoMUYJ9z3CebO4nFxpm2TjybwKyHy0sX3pGS2emdbstCXVhACLqol4DefepeMrge7EXe+R8k1pz8jnSzgkhvFaFxmvtm+Z19VGV0DYs8aCGJv044pCwV1Kyr47K3wb/sAn20XVZckIgGuz7KUuOPdmhG5E96/em9tQiwSc3bryMsZwbZSjJItFgmR8UfGtnmvzJFwqSBYBSJG9rvrldHpkJm6cqwNf4jxYgdrQD2bJzNmn4vTNArlMVA== 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=91sCiVVbEEgxdXzk1w+Mjs8LUZDR9Ye82bW536CrQmU=; b=Kf4z/KnrGfNk9YId1cgxJdSkSBkeQF/UbjVb9qHeBWTLiPs2qOMq6pHTJ0kl8ZbVGG04Z0WsXfi9s4A3ZiZhAZ63He6WlL6T7JJoketa6n/4EaEeRJTG/2aM7N7FALRVASOT9XkHS/sirCdJpwqlZl59X7VepGImBN3FzknHuyjecbytePzcXdT24R5GeDil2z1fgT2fQVgMYVoFoDOEDz2fFJDqAb+vs76kg77Ua6JYu5erVFsiJfqXFp2JY0JPc9lSvxLyRzMgBcXrQBfRVtbnUJATlUYAOGNSZb1KI8JOLP9uB0xVX9BLRayF/4v2VbyFzZIJ5aPwTI9E3Phteg== From: Sergiy Kibrik To: "xen-devel@lists.xenproject.org" CC: Sergiy Kibrik , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" , Andrew Cooper , Michal Orzel , Jan Beulich Subject: [PATCH v3] common: dom0less-bindings: introduce XSM labels Thread-Topic: [PATCH v3] common: dom0less-bindings: introduce XSM labels Thread-Index: AQHdUlhUefJfBgwqL0GtZVNifM+Gfg== Date: Fri, 2 Oct 2026 10:25:21 +0000 Message-ID: <20261002102521.565675-1-Sergiy_Kibrik@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: AS8PR03MB9192:EE_|AS2PR03MB9670:EE_ x-ms-office365-filtering-correlation-id: 7a2bf557-9668-4bce-be5a-08df206f7705 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|11063799006|6133799003|56012099006|18002099003|38070700021; x-microsoft-antispam-message-info: V62oylpxvflCdYhXuDg/gJVhWoFekR4bFNuLGXgJWb/AupmHC1qYXzSqpVi5/Tc3eCTcagTN979AFh0muCxUknAAdL7KfklyUC9IS5teCmdScShn4J21Tk4ZLvAwoZ3A0lpUIbkFiAZaE6sZuIAm/9pNjmE910riyE4okQeztB6TmUXSD28mas1tSUYHCl2TR8MtZgQcF7u3MMCFon+4FKnhQ42jQEta0R3HeSEPtn5QxTzfPZSAHRBYB4JknNUpsCxV1WMhTV5rWBJuCgV1ns9ybbs4K8nAygYxpvgPDDEPTGorvzuhencKwPP7vVV292q0TmE6PJrEAUsof7aza6LHlw0zxsrcJsBEWhHfYjLPgjUYtv3lxzDeMxKsUiR74zBYBXltcvvq9C6hNRpSTr/4hY2mTyDA/h8Es71349TTfbFaeKBa5vudoCxeSoy5MI3R4+MQMhAuWw5CDOgiwBe/e7nn/VLbrWKJeg/JJImGBABbkzTSqxbvXdAvjb/FkfgvGEv/KitDQ0ALY8Kfb7TA42+HEdD8mE0h+1C38BmuyzhYB4MXHGWQ0F4Pk0amKch2KjOWjc0Nw8dPP7QeR8Av1PaUn7t5A0v8zLvNIs4LpknDqOhl3X0fnUKgogxu06RABjYVxuTb3nA+ZHy5RmZetlwYCgXfIpeU8KfW67HkdgCRiwpyxlLEVF/eENyYremoKVgSY6nau7VNibisUCQmh43vzzZsVb2y1GXuz60= 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)(366016)(376014)(1800799024)(10067099003)(11063799006)(6133799003)(56012099006)(18002099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SndzWFdtbDdCU3REL3NoTzdtbDZxaWczeEZLYjJVZTBvTit5dm1YTEVic0Mv?= =?utf-8?B?QU9ncE82TG9SLzV4eXYvc0hHNmZlZ0FtUnpnZWtBeGNsL1VYd0dVdDZjY2Nq?= =?utf-8?B?Q0NDZ1FVV0tWWk5BV2dDY3dOaFZKZ3ZqLzFCRGEyWU42dFRvclRsQ0FJdjlj?= =?utf-8?B?di9uWlJkbmE0d0pqaDVPZkxPNTlDY2E4Q2ZhUXlIUy84K1NHZWNFNmRnbjZF?= =?utf-8?B?RGFNR29VRmVxV2lGMm1Ldjk2a3Q0Y0NuSTBjL0NTQ3pOZld4RFkxUHRYSGRV?= =?utf-8?B?ckQ4RENFY3BjbzhTeUlNT2N5SkM3WnFldHVDdTJ6bGVGTGtZZ0Q2dTUrYXY2?= =?utf-8?B?SEVmdkpua2IyNEF6QnFjWEpjdy93REZ4bFFOanFkZ2lFVjAyRTdjVnJ4ak56?= =?utf-8?B?amc4ZDJuajNMNXhaTnBGSXJvOHpzRVdjQ016bDUwUXgwdWVqeXg0R3RTWmNB?= =?utf-8?B?QlAwbm1xNWMxZHVEZkZ1bU1ydXR1VTdFNmI4ZWs5d0gzRTdHQjl5clFIWDNB?= =?utf-8?B?UEpRU0I4bnVlRWlmWXpjR1g2U1Vua01SWEl6cnlGcGVUUjVNeVF0SjI0M0ts?= =?utf-8?B?dnRJbjBuRWp5RGJ4OHM0R0Q0c1hVNHlzTnBwdE5OcDF5OStqVElrdzRCRGta?= =?utf-8?B?NEs0UFRkRmsrMysyeUFkRnE1eUtHd1NuS3cxQVFNbS8zRzNMK2c1RE9pbE13?= =?utf-8?B?ZEZ2dHp2VG9MaTh5cFRuZ0dqNVpXeVpqMCtwa045YzlFeGhuVTU0bzVlWEkz?= =?utf-8?B?TWtmN2VST2lmUHVtUjFBVlB2MTkwR1BQL3FtVFJiQWVYRG04UVpXaXp2NW5G?= =?utf-8?B?QTduRVJ5QXJ4YUdzd0U3RytQZFRZR2F0RFNPQWxtMGowaFhjOXE3ZWJqZUJq?= =?utf-8?B?Y0xCQnJyVXRtV09EcmpFRlBYTW14Z1Y5T05aNW9XeGVZOWZSSEU1VktlTW1u?= =?utf-8?B?SU40M1NqUGFqYk5xcTVoQTVzNmo0NERZZEgyaEY3S3VIZFNPd000ZUJjMXpT?= =?utf-8?B?eGVWSXR3UUxHOEFuc0Z4MnpERHNSakEvL1NpVUFRc1ZOVjRjenA4T0ZnSTJa?= =?utf-8?B?QTJjZ1lkTjA1VlZZbzhXNlIrdkpwcHF6MTFiUVk0SGpGY0NyZkQrMTJVS0ZJ?= =?utf-8?B?NGdUNi9jU1ZIRmdlYnNhK2gxUXJWRm9sSEc3SnBpVFd2OVRhNWtmQStOYkQz?= =?utf-8?B?dVpnUDhURUFyU2hDKytYTnZKcmxub29IelJJMTBiMVMySGdURGZIRDd3Y2ZR?= =?utf-8?B?LzVoWGt3eDRTYTI1ZmFZVTdablpraDgyZGY4eTd3UVlrRVE0U2xFM2Ird1VO?= =?utf-8?B?clVkSjdQV0RTNlF3MDBueFBVNDhhYmM3Y255ZzlEaUQvcEY4QjVTbzlwNFll?= =?utf-8?B?M3JETG9DcUl4b1FjbHJGeGVKWWJmUjlmdC9EKzRxMHVLMWlMN214SFlmVW1a?= =?utf-8?B?Z0pxZEY0QmtmUTdsK0cvaDF2UUNlUzlKYWxBcE9aU0Q0WW5UMGVnbUE0NW9H?= =?utf-8?B?TDdUcWl2bzhNNTRkeUx5VHhraENFNUNkYkVDdjJEdXl6cDdxdm1nUFUySEUw?= =?utf-8?B?UzlVaDRVT2t0YUN5WkJNMUZuMmgwZ0lVSnRXYVZZYlFkRHhEK2U0aXJmSHVP?= =?utf-8?B?OWdxTnk4WldiR29lM1JDeW80cVNkcEVVYkwwVEhITGIwbTVqOWRqd0l3QjNB?= =?utf-8?B?UUE2bHN0ZThVK1lLR0x2QllsUVhGRjVWVWRSVVRxSUhZTmpjMDRZM0liZjJq?= =?utf-8?B?eWpTWXZtckNXTFdwVGI0TmFNS2pFRVdnWE04SU5hbi9rTnFmTjZoYnhIeGhH?= =?utf-8?B?eWl0c0JJaVVqZmlOTjJrTVB1QktYYm1nNE8rdDVQNGg0d0pac0F5SStTc1BT?= =?utf-8?B?b3BsWFpUdFpYMmtIMzdzMDJkVTBsMkNOVHRVTk5BR0RZcnFFOXY3UzB1VTNz?= =?utf-8?B?eG1sWW4zSkdrYkhGSmtBMm91bFBCOHhJNjVSQzRXSUJ3Yjd1WFl1bWpVaTk1?= =?utf-8?B?VnQ4UWdLRlRmdENJV2VnMk56a254WlZ5Nm9ZdjJWdDYvdGI1aGxmeXFRZytq?= =?utf-8?B?ZkFrcU16VEl5QVhpUUlHbEVWU3dnbi9Id2orVFZ4SU1yakxWQXNRalNzeHho?= =?utf-8?B?blZ5Qm9yT1VBRnphVEVFMzN2bzFNQ2U5cFBaMWp5VzQ5aE9oczJkVGVjbFdF?= =?utf-8?B?SDlLQlgyUXBrb1NtZmFwREgwWDBBZ2E5WGthcEhFMWdHYWxHNzNlL0lpc3lD?= =?utf-8?B?ZldFdjhKNFFrRGdPb2h5UFNCbHBKdXlMZGQrYkRxbmhnckpFQWxDVld3RmI5?= =?utf-8?B?U0RHWi9zd0QvdFFsUnpxZ1AxY1dmM0ZDcUttdHZqdEt6UzZuaWc4UT09?= 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: 7a2bf557-9668-4bce-be5a-08df206f7705 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2026 10:25:21.9714 (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: CMShoVkosyFLR1gJ9hVe0+pbZ7z3G4RUF7TnvYBSY8owN2a+57fHkHsoYxMGjXC0SsRRJsHFsLShVitXgSTR9A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9670 X-purgate-ID: tlsNG-16d1c6/1790936727-1F8CB77B-264D8219/10/78276251493 X-purgate-type: spam X-purgate-size: 6438 QWRkICJzZWNsYWJlbCIgcHJvcGVydHkgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHNlY3VyaXR5IGxh YmVsIGZvciBhIGRvbWFpbg0Kd2hlbiBYU00gRmxhc2sgaXMgZW5hYmxlZCwgc2ltaWxhciB0byB4 bCBjb25maWd1cmF0aW9uIGZpbGVzLg0KDQpDdXJyZW50bHkgZ3Vlc3QgZG9tYWluIGNhbid0IGJl IGNyZWF0ZWQgYnkgWGVuIGluIGRvbTBsZXNzIGNvbmZpZ3VyYXRpb24gd2hlbg0KRmxhc2sgaXMg ZW5hYmxlZCwgYXMgZG9tYWluIGlzIGFzc2lnbmVkICJzeXN0ZW1fdTpzeXN0ZW1fcjp1bmxhYmVs ZWRfdCIgbGFiZWwNCmJ5IGRlZmF1bHQsIHdoaWNoIEZsYXNrIGRlbmllcyB0byBjcmVhdGUgYWNj b3JkaW5nIHRvIGN1cnJlbnQgcG9saWN5Lg0KDQpCZWNhdXNlIGNvZGUgZnJvbSBvdXRzaWRlIG9m IGZsYXNrIGNhbid0IGRpcmVjdGx5IGV4ZWN1dGUgaXRzIGludGVybmFsIEFQSQ0KYSBuZXcgcm91 dGluZSBmbGFza19jb250ZXh0X3RvX3NpZCgpIGludHJvZHVjZWQgYXMgcGFydCBvZiBYU00gQVBJ IGV4cG9zZWQNCnRvIHJlc3Qgb2YgWGVuLCB3aGljaCBpcyBhIGRpcmVjdCB3cmFwcGVyIGZvciBz ZWN1cml0eV9jb250ZXh0X3RvX3NpZCgpLg0KDQpTaWduZWQtb2ZmLWJ5OiBTZXJnaXkgS2licmlr IDxTZXJnaXlfS2licmlrQGVwYW0uY29tPg0KQ0M6IERhbmllbCBQLiBTbWl0aCA8ZHBzbWl0aEBh cGVydHVzc29sdXRpb25zLmNvbT4NCkNDOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0Bj aXRyaXguY29tPg0KQ0M6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQpDQzog SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KLS0tDQpjaGFuZ2VzIGluIHYzOg0KIC0g cGFuaWMgaWYgYHNlY2xhYmVsYCBwcm9wZXJ0eSBmb3VuZCBidXQgRkxBU0sgaXMgZGlzYWJsZWQN CmNoYW5nZXMgaW4gdjI6DQogLSBhZGQgJiB1c2UgZmxhc2tfY29udGV4dF90b19zaWQoKSB3cmFw cGVyDQotLS0NCiBkb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0ICAgICAgfCAg NyArKysrKysrDQogeGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1iaW5kaW5ncy5jIHwg MTMgKysrKysrKysrKysrKw0KIHhlbi9pbmNsdWRlL3hzbS94c20uaCAgICAgICAgICAgICAgICAg ICAgICB8ICAzICsrKw0KIHhlbi94c20vZmxhc2svaG9va3MuYyAgICAgICAgICAgICAgICAgICAg ICB8ICA1ICsrKysrDQogNCBmaWxlcyBjaGFuZ2VkLCAyOCBpbnNlcnRpb25zKCspDQoNCmRpZmYg LS1naXQgYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0IGIvZG9jcy9taXNj L2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KaW5kZXggYmNiMDZiYzc5Ni4uZDA0NDU1Yjc0 NCAxMDA2NDQNCi0tLSBhL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQNCisr KyBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQNCkBAIC0zNDUsNiArMzQ1 LDExIEBAIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0KICAgICBub3QgcGFzc2VkLiBU aGlzIGNvbmZpZ3VyYXRpb24gcmVxdWlyZXMgc3RhdGljIGFsbG9jYXRpb24gKHhlbixzdGF0aWMt bWVtKQ0KICAgICBhbmQgZGlyZWN0IG1hcHBpbmcgKGRpcmVjdC1tYXApLg0KIA0KKy0gc2VjbGFi ZWwNCisNCisgICAgQSBzdHJpbmcgcHJvcGVydHkgc3BlY2lmeWluZyBhbiBYU00gc2VjdXJpdHkg bGFiZWwgdG8gdGhpcyBkb21haW4uIERvbWFpbnMNCisgICAgd2lsbCBiZSBjbGFzc2lmaWVkIOKA nHVubGFiZWxlZOKAnSBpZiB0aGlzIHByb3BlcnR5IG5vdCBzcGVjaWZpZWQuDQorDQogVW5kZXIg dGhlICJ4ZW4sZG9tYWluIiBjb21wYXRpYmxlIG5vZGUsIG9uZSBvciBtb3JlIHN1Yi1ub2RlcyBh cmUgcHJlc2VudA0KIGZvciB0aGUgRG9tVSBrZXJuZWwgYW5kIHJhbWRpc2suDQogDQpAQCAtNDIy LDYgKzQyNyw3IEBAIGNob3NlbiB7DQogICAgICAgICBtZW1vcnkgPSA8MCAxMzEwNzI+Ow0KICAg ICAgICAgY3B1cyA9IDwyPjsNCiAgICAgICAgIHZwbDAxMTsNCisgICAgICAgIHNlY2xhYmVsID0g InN5c3RlbV91OnN5c3RlbV9yOmRvbVVfdCI7DQogDQogICAgICAgICB2Y3B1MCB7DQogICAgICAg ICAgICAgY29tcGF0aWJsZSA9ICJ4ZW4sdmNwdSI7DQpAQCAtNDUzLDYgKzQ1OSw3IEBAIGNob3Nl biB7DQogICAgICAgICAjc2l6ZS1jZWxscyA9IDwweDE+Ow0KICAgICAgICAgbWVtb3J5ID0gPDAg NjU1MzY+Ow0KICAgICAgICAgY3B1cyA9IDwxPjsNCisgICAgICAgIHNlY2xhYmVsID0gInN5c3Rl bV91OnN5c3RlbV9yOmRvbVVfdCI7DQogDQogICAgICAgICBtb2R1bGVAMHg0YzAwMDAwMCB7DQog ICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJtdWx0aWJvb3Qsa2VybmVsIiwgIm11bHRpYm9vdCxt b2R1bGUiOw0KZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZGV2aWNlLXRyZWUvZG9tMGxlc3MtYmlu ZGluZ3MuYyBiL3hlbi9jb21tb24vZGV2aWNlLXRyZWUvZG9tMGxlc3MtYmluZGluZ3MuYw0KaW5k ZXggNDFkNzJkMGQ1OC4uMDFkNWNjMWJjOSAxMDA2NDQNCi0tLSBhL3hlbi9jb21tb24vZGV2aWNl LXRyZWUvZG9tMGxlc3MtYmluZGluZ3MuYw0KKysrIGIveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9k b20wbGVzcy1iaW5kaW5ncy5jDQpAQCAtMTEsNiArMTEsOCBAQA0KICNpbmNsdWRlIDxwdWJsaWMv Ym9vdGZkdC5oPg0KICNpbmNsdWRlIDxwdWJsaWMvZG9tY3RsLmg+DQogDQorI2luY2x1ZGUgPHhz bS94c20uaD4NCisNCiBpbnQgX19pbml0IHBhcnNlX2RvbTBsZXNzX25vZGUoc3RydWN0IGR0X2Rl dmljZV9ub2RlICpub2RlLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qg Ym9vdF9kb21haW4gKmJkKQ0KIHsNCkBAIC0yMSw2ICsyMyw3IEBAIGludCBfX2luaXQgcGFyc2Vf ZG9tMGxlc3Nfbm9kZShzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUsDQogICAgIGJvb2wgaGFz X2R0YiA9IGZhbHNlOw0KICAgICBib29sIGlvbW11ID0gZmFsc2U7DQogICAgIGNvbnN0IGNoYXIg KmRvbTBsZXNzX2lvbW11ID0gTlVMTDsNCisgICAgY29uc3QgY2hhciAqeHNtX3NlY2xhYmVsID0g TlVMTDsNCiANCiAgICAgaWYgKCAhZHRfZGV2aWNlX2lzX2NvbXBhdGlibGUobm9kZSwgInhlbixk b21haW4iKSApDQogICAgICAgICByZXR1cm4gLUVOT0VOVDsNCkBAIC0xNDEsNSArMTQ0LDE1IEBA IGludCBfX2luaXQgcGFyc2VfZG9tMGxlc3Nfbm9kZShzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5v ZGUsDQogICAgICAgICBwYW5pYygiJ2xsYy1jb2xvcnMnIGZvdW5kLCBidXQgTExDIGNvbG9yaW5n IGlzIGRpc2FibGVkXG4iKTsNCiAjZW5kaWYNCiANCisgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVh ZF9zdHJpbmcobm9kZSwgInNlY2xhYmVsIiwgJnhzbV9zZWNsYWJlbCkgKQ0KKyAgICB7DQorICAg ICAgICBpZiAoICFJU19FTkFCTEVEKENPTkZJR19YU01fRkxBU0spICkNCisgICAgICAgICAgICBw YW5pYygiJ3NlY2xhYmVsJyBmb3VuZCwgYnV0IEZMQVNLIGlzIGRpc2FibGVkXG4iKTsNCisgICAg ICAgIGVsc2UgaWYgKCBmbGFza19jb250ZXh0X3RvX3NpZCh4c21fc2VjbGFiZWwsIHN0cmxlbih4 c21fc2VjbGFiZWwpLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZF9j ZmctPnNzaWRyZWYpICkNCisgICAgICAgICAgICAgICAgcGFuaWMoIkludmFsaWQgc2VjdXJpdHkg Y29udGV4dCBmb3IgZG9tYWluOiAlc1xuIiwNCisgICAgICAgICAgICAgICAgICAgICAgeHNtX3Nl Y2xhYmVsKTsNCisgICAgfQ0KKw0KICAgICByZXR1cm4gYXJjaF9wYXJzZV9kb20wbGVzc19ub2Rl KG5vZGUsIGJkKTsNCiB9DQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveHNtL3hzbS5oIGIveGVu L2luY2x1ZGUveHNtL3hzbS5oDQppbmRleCA5ODA5ZTAwNWUwLi43M2QwNThhOGIyIDEwMDY0NA0K LS0tIGEveGVuL2luY2x1ZGUveHNtL3hzbS5oDQorKysgYi94ZW4vaW5jbHVkZS94c20veHNtLmgN CkBAIC0yNjEsNCArMjYxLDcgQEAgc3RhdGljIGlubGluZSBib29sIGhhc194c21fbWFnaWMocGFk ZHJfdCBzdGFydCkNCiANCiAjZW5kaWYgLyogQ09ORklHX1hTTSAqLw0KIA0KK2ludCBmbGFza19j b250ZXh0X3RvX3NpZChjb25zdCBjaGFyICpzY29udGV4dCwNCisgICAgICAgICAgICAgICAgICAg ICAgICAgdWludDMyX3Qgc2NvbnRleHRfbGVuLCB1aW50MzJfdCAqc2lkKTsNCisNCiAjZW5kaWYg LyogX19YU01fSCAqLw0KZGlmZiAtLWdpdCBhL3hlbi94c20vZmxhc2svaG9va3MuYyBiL3hlbi94 c20vZmxhc2svaG9va3MuYw0KaW5kZXggZDY1YmEwYWVhZS4uMGI0NGEyYTNkOSAxMDA2NDQNCi0t LSBhL3hlbi94c20vZmxhc2svaG9va3MuYw0KKysrIGIveGVuL3hzbS9mbGFzay9ob29rcy5jDQpA QCAtMjAxNiw2ICsyMDE2LDExIEBAIGNvbnN0IHN0cnVjdCB4c21fb3BzICpfX2luaXQgZmxhc2tf aW5pdCgNCiAgICAgcmV0dXJuICZmbGFza19vcHM7DQogfQ0KIA0KK2ludCBmbGFza19jb250ZXh0 X3RvX3NpZChjb25zdCBjaGFyICpzY29udGV4dCwgdWludDMyX3Qgc2NvbnRleHRfbGVuLCB1aW50 MzJfdCAqc2lkKQ0KK3sNCisgICAgcmV0dXJuIHNlY3VyaXR5X2NvbnRleHRfdG9fc2lkKHNjb250 ZXh0LCBzY29udGV4dF9sZW4sIHNpZCk7DQorfQ0KKw0KIC8qDQogICogTG9jYWwgdmFyaWFibGVz Og0KICAqIG1vZGU6IEMNCi0tIA0KMi40My4wDQo= From xen-devel-bounces@lists.xenproject.org Fri Oct 02 10:30:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 10:30:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439028.1657545 (Exim 4.92) (envelope-from ) id 1xCaWk-0005P9-Ek; Fri, 02 Oct 2026 10:30:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439028.1657545; Fri, 02 Oct 2026 10:30: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 1xCaWk-0005P2-C5; Fri, 02 Oct 2026 10:30:06 +0000 Received: by outflank-mailman (input) for mailman id 1439028; Fri, 02 Oct 2026 10:30:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCaWi-00055D-QF for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:30:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCaWi-00FrfH-3X for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 12:30:04 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf8799-8faa-0a2a0a5109dd-0a2a450ad31c-32 for ; Fri, 02 Oct 2026 12:30:04 +0200 Received: from [52.101.83.75] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf87ab-f2d2-0a2a450a0019-3465534b944e-3 for ; Fri, 02 Oct 2026 12:30:03 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by DBAPR03MB6408.eurprd03.prod.outlook.com (2603:10a6:10:194::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.15; Fri, 2 Oct 2026 10:29: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%6]) with mapi id 15.21.0451.022; Fri, 2 Oct 2026 10: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=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=rjXTNa4tmxUUGyvJnVmzH6ENDCfx2NyQ43RTQJLSJnVcaW342Z26cThwv+3HDNVJLMmJ1QLU30nVwBP4bRU/QEudNzblMyWkH7KxCjwClsAcVB2SGXzZKedB3poLfsMOoTDklmNjsRnGe0COMwrCSU4SiNz9/JljHbEvzppcFqSAC5Vm9wGHA/CZebkqbtR5nGQzgXR0A44bLhlPT6VzfQRMgzatox8lK23IQF4CVOaud+nQX3Y7pO55/pmk93mCjnBJkk9aVyM/J9fU794y1iwEIVVjrOo7VhCeao3cuiAHHDdOIgV6/1GksG7l8/uhYoM+PG4zFXtq7zko9OeKbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tLrSnB8SPF/okncHWoV+okSYAdNqsGAHwI46xiRzM7w=; b=OYCMUUDjy/w4/J7ApYj+wb4i0ft9Vdk8x50Q1d8Rm9Ew9dN3lY98dEHQaA2gqsHwBN9NINNZYATF6S0G/RGZuL5LSz4faNk7beFsDAabyQRUUPfPHXfxuILpKFkNHi71sWJKgHfuZxXpkM0PnXtU0AhbAMJ8SSrk5jSfZAUD/1wJ2aNPXj+VTAnD0QY8ZL+W4stWo2r4e5H3ZjIbFuzW9VBwV2YsG7a/Kcj9ovb2QMAAlqPQTG8u0eJPq9Mn5GDvqXAzF+avSC1lGIasnInFC+SdmL/SJgxGB5AqPRJPEJeHpXqMz2oMKxvh0y6eSEgsQH76yolF/yGVFQQPdH8aTg== 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=tLrSnB8SPF/okncHWoV+okSYAdNqsGAHwI46xiRzM7w=; b=dtvLy8zkdhON6o10yOLoaaERdUjDewXySKotFDO7EMabnSkbd3DZFWx6mjfV/hT8LWFAHLrjDmqlgUYBa7dTwuIeDjfDRwZ23UtaIXi8mUTUDReUJ6PoFkKw+JiLR1mrtYYrTKz76jv8l2DQv+Bogp+llCd6PrFJE52VXcQc2cNOx2HXGigMLS4rfr9DUsaEpqKDUFgnmsr/5gdPoTuNEf6nt0Ycm0Nsa7f4aqRItA3TmsLKJoBeJ9CNidE9elmeHzZMCNYhXMge9RZp6CN/gWhj7fR6BvvXroyQ8oQ+13mG2FNtwoEt8H5fD84BphTTqnP/ERR77yphASU4T4m47w== From: Sergiy Kibrik To: Jan Beulich CC: "Daniel P. Smith" , "xen-devel@lists.xenproject.org" Subject: Re: [RESEND PATCH v1] xen/xsm: flask: restore sidtab state on policy load failure Thread-Topic: [RESEND PATCH v1] xen/xsm: flask: restore sidtab state on policy load failure Thread-Index: AQHdUlATCy0sfywDV06Ga65AkQTQHLbp/b0AgAAPk4A= Date: Fri, 2 Oct 2026 10:29:58 +0000 Message-ID: <8349bf11-930b-4431-8d77-51f273827446@epam.com> References: <20261002092556.542986-1-Sergiy_Kibrik@epam.com> <0787063a-ca04-437b-9bd9-307fa084007e@suse.com> In-Reply-To: <0787063a-ca04-437b-9bd9-307fa084007e@suse.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: AS8PR03MB9192:EE_|DBAPR03MB6408:EE_ x-ms-office365-filtering-correlation-id: 5ba8c523-f998-4c41-0087-08df20701bd0 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|38070700021|56012099006|5023799004|11063799006|10067099003|4143699003|22082099003|18002099003; x-microsoft-antispam-message-info: qhiFTWBkIaTXSCmIa5FLDharxLUVRpZxxg03kFjwXQGPKystCD4JfYDMFjJA6UfkTKqTQoQiPJbXhnFKZzXnfXxDPlwtOtzlJgz9PCuL5j77GFwAp0inda0eL8xb4IC5ylGmurdiN+Xub803RDnpMKZ5TAG/9aWAT3azrBrrkoSenhOPfWe8z+IvmFA7GL5un2wJ0N5d0G5n1deY8eiZ896Bzpy0pj0VySkHD4xq0h6cn5xBf+IJFHkhWjCFdEY50R/SqrY8U8LU6FFK/gpb8nDFgzYgjxDTk48dpljUsqMgnaw4vMsiOBjm7Mbb/G38kK7s2LtJusNeIlay45+5mWaOfEHuuDJ5ClNip6JwQcw/mPGMgwIkUn1ZhLC1oilgqfiIChRcvYFTuI0dRIrfyMTPYvpqiNmKOl7HjEmldZKnOWuXgynw+wclywppvI3i/LiSTAGDypFqmc55Pl2Oy4wtzpjUC4DOxANkIlXnbIzsKbw6AwUSIcHmyHTieaImtBqUwk+M+hVcFY747ER3y4nUgjQuYIRYHTRni2kXNwM64v7ap0j6MsfCwFaASaycbsIz8CNsz8bABR9BVeVEkr56LB5855kvrVWCHvktrzvNq568GCcXkFJmTHUqnkC5FeLS7ls/l7c4MEY2Pv+LsO+mXpKD01i4Ab9fvmh9Kz+/fpXNS6f2tZmVMPAtmytJpLtHeP/T1LSQPnBDJ9RLj334SpPgJyySKskNkhkhtAY= 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)(376014)(23010399003)(1800799024)(366016)(38070700021)(56012099006)(5023799004)(11063799006)(10067099003)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UXdnSE1DMTdac213QUE2ZytScFBpMUNVQ1B3TkFPZmpMV0NKNnI1OWs0Q3lx?= =?utf-8?B?S3krVEhPQXhrUlZTYlVOOU43V3l1WXlBeVFTYkVwTWF2TWxnZnYyM0ZiNm1l?= =?utf-8?B?SzIrbG05bzh0eWZXVnMxYWZScGhwVk16dDdUSU53VnU0RHNiYlJRSDN5ZUcw?= =?utf-8?B?RUZTMWNIajc1YXdTVEV5QnZiRmt2NlpZYnZrbVZKSzIxdEhQc3o4cjM0WW1O?= =?utf-8?B?b016SlV4L2lYSjZKMEd3Y29ueHRodHh6bndkSFVsSE90biszamhOWGhjWm81?= =?utf-8?B?aTNOUGI1UGc5VmZBa0lZQm1RSVdlbTVWMTRNVS9vQURnUVFpS0E1Z1k2eklC?= =?utf-8?B?RUhKT0FpTm1YWjc4K0s3QzRPSEhKaFR0c0JRUXpvbm10cVYvbXJEV1lXU1BQ?= =?utf-8?B?S1orUWkrSGtUNy9hNjRzOTlvRmJCeFlCLzBBdG9MZ0pzVEVqY2VEOUpUYTBu?= =?utf-8?B?cTZucXQxZTBvUFlvMEY2MVd0M3BPK2M3NDFHa3diNy9EbkhMdE9LcXpYNTI5?= =?utf-8?B?Tm11QytodmdCYVlObjNIOHFzdFNVRGhOcUFtRVVyeEdTYW9JaU9saEI5Y0Jn?= =?utf-8?B?eXhzaTRab3RINThhc1k5WTF0OERabVp3aDBUbC9SaGEzQUJhY0JsV1VkZ0Vu?= =?utf-8?B?eE1DNHpEcnQva0N2aFFFNWNUZTgwUDVWR2tkZjJIeEVPcEVtcEV5NExmbkdF?= =?utf-8?B?Sk0xZjlhTkZVOW9BcjZGUmlKTjhLektodlBJRFMwOU1qSTZOTnFxUHBBTkJM?= =?utf-8?B?cjVscmhyYmlWdkFxSkY2UTA5ZGxnSzVJS25UNGFhWHVxZ0lZWEVzWGVuZG5H?= =?utf-8?B?Sy9FaEVvalhxR0JxRmx2WUhqd3hmc0FUZktTTzJWQXlBM0wzMklQc29LcHNK?= =?utf-8?B?Y0NVcmxBM1l4R1p4NjlJUWNBNnZUa1V5WlFMZmdBK0JaM2RLNmpZZlZMWkFy?= =?utf-8?B?cUlpTTZ2c2J2dy90WVVQcEtVdHFmRHlvYmpRNTdHUExrUE5tNlBBMTZBOUc3?= =?utf-8?B?SVV4OHp2dDdJODRPZ3VaaWJzU2JQanlKK3Vsa25JVzZjeFhLTkJEU2U1Q29h?= =?utf-8?B?SHVUdVlScVV2VHNjczYzY0RiRXM4NjllUGZ3NUd3MlJ6VlhIYzJkUFVnTE03?= =?utf-8?B?R3dKeTRVK2ZwZVFWYUlUMzVCb29tTjA1MDBnK2d0Ulp4R2taZ2dGUEZVaHU4?= =?utf-8?B?Ymo0dkw0eXhxS1hBOC84amRkcEptZFBGWjlZUDEraDUrYXFGU3BFWGFIM1FR?= =?utf-8?B?Ny9NN3Z1V2J5NkVpdmcrZmk3cndXcElRQmVUQUJRbU9HOFJuNE1HMmN6S2Zr?= =?utf-8?B?Qm82V2VqdHlqYjA3TXlpcEJKMXJzUFpUalZTeTJQeVVndUJjOHJla0JsZFpJ?= =?utf-8?B?RjZ2S2ZFYmVoNGRMY2E4QkhNdklvdnV6OHk5ek5Lck5KT1ZHVWFTNUZZcnBp?= =?utf-8?B?VWFyc2kyWkZ0UXJibmIybnNqbFZiZGlxbm1yaGh5bHJMSW9JVG5pbGVnbFlr?= =?utf-8?B?MUo4UHl4VE9wZEZXbGh2dnp5blovZnlUczZhcmdqY0k4NE96KzJwNEZJd0Fu?= =?utf-8?B?bTlaNmVoS3JyNnkvZ05JaTBvWExROGJ5R2M2aXNGcHh6WSs2eDVJV1BhOUtu?= =?utf-8?B?SksyQWgvak5HdlpkWXFYSmVYaTdGZjVua05ib0RDU09heUR0NUtZTmxNYXFy?= =?utf-8?B?MS90ekgrWnY0UEhLTXdhdnM2dk43WUo5YWFRR3dkWFJxMjhpdXg3Ynh6eDBp?= =?utf-8?B?WXZkLzhxQnd6S0hRcmhNcnFYcHN2ZkFPZzQvOWdUTlIwQ1lFQUwwemF3MDlT?= =?utf-8?B?S25tNDFodHd2K005Z1dtUkdFMWVLWFZ0Sm5JZnNvcWNQcFJjckxPbFk2SG00?= =?utf-8?B?UVFQUXo0ZS9sZUo3akgrY0tIc0x2QktCQSs1TnFDT05lVG1hUjNZRWFleDZn?= =?utf-8?B?QTN2YzhWNG1PYjlLaVVyODdad0ljYTF6NkkyMGFlTXkvbW91dEx6K1VRdmFR?= =?utf-8?B?QTYvRzRmOWJETzhqVHB6SFRBQ1hzRGI3dHBrR2ROQ3pLWXRRT0tZVjRTblc3?= =?utf-8?B?VkJzdndsK1lmbEd3SktRTU81dWpIMzdYcmUxeVY2ZWl4M0tRajlNSHFZd09E?= =?utf-8?B?dGt0UTZWVGF1VFE3Wm1WVkxQNkNSM1FJcjhreDkybG0wcE5QUk5TZWFIVTc4?= =?utf-8?B?bVM0RHNCT1hsZ1lIYnpCVkZaT3FGUWIzM0c5T0N6QWJuazIwaUFJRzhqSjdE?= =?utf-8?B?NGh5cnpSUTlXZHhUK01kYnE3ZlYwUTd2ZWxRUk5NcUdDSzVxS01qVlhYaEY3?= =?utf-8?B?ajRtRHZNQnIwSmE3aXMrQXBHMkNYWHJoSlBjbWhneWowMndyc0tUUT09?= Content-Type: text/plain; charset="utf-8" Content-ID: <607C4A13531F054EA551A4C6D6C849C6@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: 5ba8c523-f998-4c41-0087-08df20701bd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2026 10:29:58.4550 (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: 1khJJIxo6ZalFY2MkJ+m4WBhg4U5/tUM9Fs4fIaM9y4td+9qQqThHzSPaWe0b4PQrSquvFCcyPO7gV7OiMl4tA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6408 X-purgate-ID: tlsNG-4011c0/1790937004-4BED2CFC-19A1DB50/0/0 X-purgate-type: clean X-purgate-size: 1442 T24gMTAvMi8yNiAxMjozNCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDAyLjEwLjIwMjYgMTE6 MjYsIFNlcmdpeSBLaWJyaWsgd3JvdGU6DQo+PiBFcnJvciBwYXRoIG9mIGZhaWxlZCBzaWR0YWJf bWFwKCkgbGVhdmVzIGdsb2JhbCBzaWR0YWIgaW4gc2h1dGRvd24gc3RhdGUgYW5kDQo+PiBmcm9t IHRoYXQgcG9pbnQgc3lzdGVtIGlzIHVuYWJsZSB0byBhbGxvY2F0ZSBuZXcgU0lEcyBpbiBzaWR0 YWJfY29udGV4dF90b19zaWQoKS4NCj4+IFRvIHJlc3RvcmUgc2lkdGFiIHN0YXRlIG5ldyBmdW5j dGlvbiBzaWR0YWJfYWN0aXZhdGUoKSBpcyBpbnRyb2R1Y2VkLCB3aGljaCBvbmx5DQo+PiByZXNl dHMgc2h1dGRvd24gZmxhZywgcmV3aW5kaW5nIGVmZmVjdCBvZiBzaWR0YWJfc2h1dGRvd24oKS4N Cj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBTZXJnaXkgS2licmlrIDxTZXJnaXlfS2licmlrQGVwYW0u Y29tPg0KPj4gLS0tDQo+PiBOZXcgZnVuY3Rpb24gaXMgbm90IHN0cmljdGx5IHJlcXVpcmVkLCB0 aGlzIGFsc28gY2FuIGJlIGFjaGlldmVkIGp1c3QgYnkNCj4+IGRvaW5nIHNpZHRhYl9zZXQoJnNp ZHRhYiwgJnNpZHRhYiksIGJ1dCB0aGlzIHdheSB3ZSB3b3VsZCByZWx5IG9uIGl0cw0KPj4gdW5k b2N1bWVudGVkIGludGVybmFsIGJlaGF2aW91ci4NCj4+IC0tLQ0KPj4gICB4ZW4veHNtL2ZsYXNr L3NzL3NlcnZpY2VzLmMgfCAxICsNCj4+ICAgeGVuL3hzbS9mbGFzay9zcy9zaWR0YWIuYyAgIHwg NyArKysrKysrDQo+PiAgIHhlbi94c20vZmxhc2svc3Mvc2lkdGFiLmggICB8IDEgKw0KPj4gICAz IGZpbGVzIGNoYW5nZWQsIDkgaW5zZXJ0aW9ucygrKQ0KPiANCj4gTm90aGluZyBpcyBiZWluZyBz YWlkIGFzIHRvIHRoZSByZWFzb24gb2YgdGhpcyByZXNlbmQuIFdhcyB0aGlzIHBlcmhhcHMgbWVh bnQNCj4gdG8gYmUgYSBwaW5nPw0KPiANCnllcywgaXQncyBraW5kIG9mIGEgcGluZy4gTm8gY29t bWVudHMgZm9yIHByZXYgcGF0Y2gsIHNvIEknbSBzZW5kaW5nIA0Kb25jZSBtb3JlLCBpbiBjYXNl IGl0IHdhcyBsb3N0Lg0KDQogICAtU2VyZ2l5 From xen-devel-bounces@lists.xenproject.org Fri Oct 02 10:53:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 10:53:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439041.1657555 (Exim 4.92) (envelope-from ) id 1xCasx-0000AO-6n; Fri, 02 Oct 2026 10:53:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439041.1657555; Fri, 02 Oct 2026 10: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 1xCasx-0000AA-38; Fri, 02 Oct 2026 10:53:03 +0000 Received: by outflank-mailman (input) for mailman id 1439041; Fri, 02 Oct 2026 10:53:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCasv-00009u-J4 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 10:53:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCasu-005hfj-On for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 12:53:01 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf8d04-2eae-0a2a0a5409dd-0a2a4506e49e-16 for ; Fri, 02 Oct 2026 12:53:00 +0200 Received: from [52.101.62.33] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abf8d0a-195a-0a2a45060019-34653e214168-3 for ; Fri, 02 Oct 2026 12:53:00 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by CO1PR03MB7841.namprd03.prod.outlook.com (2603:10b6:303:270::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.19; Fri, 2 Oct 2026 10:52: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%3]) with mapi id 15.21.0472.016; Fri, 2 Oct 2026 10:52: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=x2u0YT+b1LlafBRiXHNn34WVomRt9NmpaIpMILwpS3R1i2G5ewPV+VxsXlKBBRi0roQd/F8GmUQU0tFdI0xgfKny5WdG5goq/0eDL2/japaLzMuklEEfgMjXaMyorYasjiJaf/MWSZ5Fe+qBgD6oRUwUpFZOXabMUXqu1VLclvKgLKMJvZc1jfGVf0ewvpVAzxUhQ9pY6dmyHRi+H6QX6coxDMIpJae+kK/c2VRFs8uGrEaFRk71i9iogw93mG7l1EGekwRDw2CP7RMXmgXalk3Uu90H7EOmnKIhvKzGBQl1RAo+jF9E/b5FeM9Q2rHMLApQzaGYpA1QqMdFPYldow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uBU9T5Y54MpT8dNsA/CG6j7zmFFrb6B19NlexK0HmDk=; b=DZzIbVd1rzue8hWWm2Fyl72S6kTuTHLwkmI0FSoVIaSosX5JLYSXjTzBAt+avMeQ3gVciiIrmLfn/5iYTeW5pYZ+fakHabQqEYdQFE+fKPJwW4a14Er1LiSwzbGTUh32rOh7Lw5XY4GH3Px8x/RGlXQoDIHZAhxNObKGYuDRGEn3DaAgVXBiAQXKqOb6x66A+txvC9wW4Zd5ky2OIMcgBX4d7HWG9sDorEIBE92/TkUKGyLLA8hnhlohFRwC2kRQbVcTBMNY/FtnrXkGg42ogLTR1sfOWexrx58B7oUiCtHHDxPXxIqxzwHLwWHh7YSGpDp5tQpFbbzwMDnw3GZTkg== 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=uBU9T5Y54MpT8dNsA/CG6j7zmFFrb6B19NlexK0HmDk=; b=L1mFwtJTspj3OdpCrz35fEiGkT4WUjMyMM+jk84DnSIAQk4qqIlg4TCLryGONQUdZ+RKQXf31pl5Kxq/PImKKPKIZIK2SOPF7iv95kTX6n05bqNgWm3mOuOdYwZaPUiU1SUrSrybGat2+GkAWoE5JJtGAASOvz+zo0ski8DrZm8= From: Kevin Lampis To: Jan Beulich CC: Andrew Cooper , "teddy.astie@vates.tech" , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v3 1/6] x86: Remove return value from UPDATE_ENTRY Thread-Topic: [PATCH v3 1/6] x86: Remove return value from UPDATE_ENTRY Thread-Index: AQHdUcyw+vB+FMChKUya9aL6N17n2rbpvOkAgAAvJJuAAAfxgIAAIBbp Date: Fri, 2 Oct 2026 10:52:31 +0000 Message-ID: References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-2-kevin.lampis@citrix.com> <2db46bf6-87e7-4f1f-b440-b73be1f86b55@suse.com> In-Reply-To: <2db46bf6-87e7-4f1f-b440-b73be1f86b55@suse.com> 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: BY1PR03MB7996:EE_|CO1PR03MB7841:EE_ x-ms-office365-filtering-correlation-id: 110f3550-5ba4-4aae-4e23-08df2073420a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|18002099003|22082099003|38070700021|4143699003|10067099003|56012099006|11063799006; x-microsoft-antispam-message-info: sVzPx8WRaLryM4/WsJHyBbmcve1f0L53LliMl8dg4oNmSxylBWXxUwHVs3CnuKUSp1vrpFm82OWTYt6uYOYzKxZMHQlaUH5GXpT+ahweidZPXBiyqruuJZKggpXjaTDB9QI5Mk/S6iokNmNH6a4AL2qc1BtbW3CQtoZ8Oe36pCqYh4IyELxbyluID/RGtB6a7e4Uct0fIZbxo5PnfhwmGl00iW1O/aUX0cKoRp8DIhXS3oYjmyY3NERP8r1ASqhw5DBFd2rt6SsnOtv63BL7biH7Eu53N+J8Y9PKRvuUy3SiRzjNpApWMWp2BmqIZE12Fu8M1bO81en5V92Lsbpu/R1uVmBYOB8dS7bpPl7p8HLevOfSxjtMsKz3rK5wg6VkWLGa6nNOSzVWTrOT4rFHDHv0rLl90mb6BqIJ6Kij0do03fDZ2IjLEhc7H2XCsF1v/38XwsDtbqarzD6ntCUuBsLWER2r9o6ll+8CY4flK5uUC8Oj7RzTOBS22HHnYvnjFvTN2ALP2e8zUM2OyOIMsU6hEuqzACiz5PyH7HLfacS63E1Xph4OxFWoSIn3pocOTmW6Z+JYVzzVYoTYwxJWKKTZVis4KwA7dTo6f5BjPrHZJP4aPcHV5w6muvxEkXt0FBF2+4T2t5p48e8sKcmDQkJT70cvdVmLJDkFqyzObHI= 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)(18002099003)(22082099003)(38070700021)(4143699003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TSPA14YqH48z4+K1PLhz3NHVhSb4hyopwtG79Tj7fzdeamIV5n4M8CJPc2?= =?iso-8859-1?Q?YzaSifhWRP57UXWbQ2i0otlXtgC6aKHFXE9ldUlzZQkboi5YWHauDB06y8?= =?iso-8859-1?Q?bxEwZFTP+No8Z4LfJpDgAo8mTIqBKhDQBSuug+dppDVa6y4/6E0yS45J96?= =?iso-8859-1?Q?1osgLt0ANrz+WtsAqM/HyQXeVRYiA+OIW2ZAN/y40iAHuOmv5//eDUsCB0?= =?iso-8859-1?Q?qhcNz5bAAaKvfVpt/opmzlBoSh7L5T35uIAONQlah3XpP53wx7T4OYgy21?= =?iso-8859-1?Q?BqOiRyDopeF7qXqBllLd/Bu814rXiNZXLWHhVsa08rnL7suo1rm2PhITqD?= =?iso-8859-1?Q?aBOeGq8rqkqNwW+9dBQtrjB1fAeqRjJ4S903gPr0JMoJz++HnE7STgN8+C?= =?iso-8859-1?Q?8Gtbh3ftj25lXOBl8lLNnMFqgaHWYtmQmiE+nFH/7P6X+XOlTWf1QmJFzt?= =?iso-8859-1?Q?j4lOIzjh+X96egML5n6nGrGe38azW1I0ChTM5eWwbyFd2okh9PFWfvDU+h?= =?iso-8859-1?Q?zd7lf3vaHR8pDqL8E22VQNFpCWGH9bjoRgwqj268VCdAVwO+FV2XRVBiyz?= =?iso-8859-1?Q?XgxqtELoHV+2nqcnd8vEl+VD/axYCI/XhzHceILNuEDd7mw2Bs5NYOXYgj?= =?iso-8859-1?Q?KcTZ2NjxYoLazAz47wCD/Sl6Al7w3gQ0nhOLFSiginCorSvQAU7dz5bPs2?= =?iso-8859-1?Q?ylBP6+b8IC5ZEEd9qXpam6eIsXYEXG6Bd5iNAo6cTFaczec1tPsHCdfB0E?= =?iso-8859-1?Q?Zi3oEycgmPcON9sqX0L/SLYvkojfDWxqUB1lDt0Wn2IatiX1E1aJmGLnmg?= =?iso-8859-1?Q?i+V+cpVOIVXHumjgOeX4E+9W2is501Du+S9vke6/7qwReCqV80+Dzlw9/x?= =?iso-8859-1?Q?5//jZeXzS8huP+ITD9q7iL/b3pEClO3p+FdZo0xwUwQNFWzSXSBD4kNc4s?= =?iso-8859-1?Q?KL1Zs6XWw2p7o9cpmJCr55m5jh6FLONV5iCElD+FhEeN7gzE1XVo+wqXlb?= =?iso-8859-1?Q?0coJrQ1u6/vJCKvaWh2SL/Lla3VY1VjWaHTsOrbpS29cEdDKao1J4WSagJ?= =?iso-8859-1?Q?F9EaypCKcJTnl5NLXJO1ZuVtNhHoY3fdQgi5uTzD0r+J9KuH6FepgTUkjP?= =?iso-8859-1?Q?BI6CF7s3HmQude3MhacSeUP7Ynw6hu0LkdNzQhoJgnHRv8CUPgSstPHv/x?= =?iso-8859-1?Q?xQ+4J/1m6uRAXfyVw3TqGBZdmygXFaCbr7ec/z/G4fkyfgsmtALsJKnxxd?= =?iso-8859-1?Q?uctEi7xyaaXv3twMy+yVYhnh+yEwXTVYhyMbQPxpfD2DnaCTM+QU2qoc3E?= =?iso-8859-1?Q?GbwxJKKXJj9UtSBz1ok6zx46UMGXwwioSgGN3cwSGbZc/2WRDPM2xKToXw?= =?iso-8859-1?Q?JcyGw9LOJo/Pv4l8cFByKyAL5O29jTzeQ17WGo1hA5rL9hNkkRISIDH9G4?= =?iso-8859-1?Q?h9sOOurNaRCJFVhPYRaFrbxQAOXk3YtNtnUY2v6kWZ75RtrpzxycU3BoV1?= =?iso-8859-1?Q?olpn6DCy7zJdXQsxXZDPTmZU7SMn7Q4tYgBEWT6XumA0m3FrnTGUpNbDH6?= =?iso-8859-1?Q?UiAYFISUlNI1Sg4IRo/tCapg+1QdcnUgBmy+De+ESP1C1Q04TLMyE9PJOJ?= =?iso-8859-1?Q?YEykL1TmiyLaL13h+cdI0xGAcqsZFViOQSnohdhSWEXtHrnMbW2OdIA5py?= =?iso-8859-1?Q?XoEv6PfN89DEJ0XS/jQbutxKmBRfDtsTXN8E1hU+QF844uHJs19DXbWaRd?= =?iso-8859-1?Q?ETYTP/uTfDvl1TDU6dktBv4qnijLnFxe58EhJoGKq5d1K/ZO2N6rSegh6j?= =?iso-8859-1?Q?zEWTV3AwSw=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: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 110f3550-5ba4-4aae-4e23-08df2073420a X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2026 10:52:31.1018 (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: VMl17Clcy0u6cNZnVxFZdF7EHNUwf37GiFalt42q5hZHqP/PaVDP8t40pv3F0NVLm30husxF/FPaJgAQeUURjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7841 X-purgate-ID: tlsNG-16d1c6/1790938380-F480577B-B45943F0/0/0 X-purgate-type: clean X-purgate-size: 168 >https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommit;h=3D5ec86c22b4b3f26= eab0fe9af4cbd0f90d315d820=0A= =0A= I'm sorry for missing that, I should have rebased.= From xen-devel-bounces@lists.xenproject.org Fri Oct 02 11:20:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 11:20:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439054.1657562 (Exim 4.92) (envelope-from ) id 1xCbJL-0004JO-4z; Fri, 02 Oct 2026 11:20:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439054.1657562; Fri, 02 Oct 2026 11: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 1xCbJL-0004JH-2P; Fri, 02 Oct 2026 11:20:19 +0000 Received: by outflank-mailman (input) for mailman id 1439054; Fri, 02 Oct 2026 11:20:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCbJJ-0004JB-GL for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 11:20:17 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCbJI-00B6IU-1Z; Fri, 02 Oct 2026 11:20: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 1xCbJI-00AxNy-1E; Fri, 02 Oct 2026 11:20: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:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=UqlocLvpi/8FAA19/MNga9Pe2S0YGE5N86Jze2jUass=; b=Mw4YDfa2tDDstgIiVzMpa0MrDj +Ox629DkH69V9Ms/AGPLAIlA/yJAlCgt6j7Heq7EaFdhm6jU3IoYy4qv+OJh9dOfisugBZ3qgR1JZ 6+mAjKFsBhKf0sF/h+IQ2KPE+7Nx92nb6dBI9q2ghiVQZHC4NooM7SAT7jj/3AKpCoX0=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Grygorii Strashko , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v2] x86/domain: restrict context switch hooks for the idle domain Date: Fri, 2 Oct 2026 13:20:05 +0200 Message-ID: <20261002112005.20656-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 From: Grygorii Strashko The arch_init_idle_domain() initializes struct arch_csw idle_csw as: static const struct arch_csw idle_csw = { .from = paravirt_ctxt_switch_from, .to = paravirt_ctxt_switch_to, .tail = idle_loop, }; but only place where d->arch.ctxt_switch->{to,from}() are used is __context_switch() where they are both guarded by !is_idle_domain(pd) which makes the callbacks in idle_csw unreachable. Introduce a new poison value to be used in unreachable function hooks, and set the from/to fields of idle_csw to it. Use a different value from the currently defined ones for easy differentiation. Signed-off-by: Grygorii Strashko Signed-off-by: Roger Pau Monné --- Changes since v1: - Introduce and use a poison value instead of the implicit NULL. --- xen/arch/x86/domain.c | 4 ++-- xen/arch/x86/include/asm/config.h | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 996b50af7a17..6ebe6c5052b3 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -813,8 +813,8 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) void __init arch_init_idle_domain(struct domain *d) { static const struct arch_csw idle_csw = { - .from = paravirt_ctxt_switch_from, - .to = paravirt_ctxt_switch_to, + .from = FUNCTION_POISON, + .to = FUNCTION_POISON, .tail = idle_loop, }; diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index 1b28349a427b..bf82cd082a59 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -56,6 +56,9 @@ #define LIST_POISON1 ((void *)0x0100100100100100UL) #define LIST_POISON2 ((void *)0x0200200200200200UL) +/* Poison unreachable function hooks with a non-canonical value. */ +#define FUNCTION_POISON ((void *)0xDEAD0000DEAD0000UL) + #include #define PML4_ENTRY_BITS 39 -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 02 11:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 11:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439064.1657572 (Exim 4.92) (envelope-from ) id 1xCbWN-0006Gr-87; Fri, 02 Oct 2026 11:33:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439064.1657572; Fri, 02 Oct 2026 11:33: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 1xCbWN-0006Gk-4Z; Fri, 02 Oct 2026 11:33:47 +0000 Received: by outflank-mailman (input) for mailman id 1439064; Fri, 02 Oct 2026 11:33:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCbWM-0006Ge-E1 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 11:33:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCbWL-005niw-No for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 13:33:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abf9684-e002-0a2a0a5209dd-0a2a4505a02a-24 for ; Fri, 02 Oct 2026 13:33:45 +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 6abf9698-4cb1-0a2a45050019-4a7de1639c35-3 for ; Fri, 02 Oct 2026 13:33:44 +0200 Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-4887840c529so2588683f8f.1 for ; Fri, 02 Oct 2026 04:33: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-4a0280c84a9sm66076845e9.10.2026.10.02.04.33.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2026 04:33: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=1790940824; x=1791545624; 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=PDojIWkbTG7AeBUmA+WcXOG+4O+hb7+PsQogC6F3kz8=; b=MVrzQAy+vtTRlDo/hezOFzPeK9ZVC2M92Zr8KDDBHUFAM9B2AEWGBpWwdZMEGce1Kd unjsc3RCp3APyT5uQ37V0NFNX86wDlKr4Joo8+F9cHNIXZmtCNl8TbZ935oTmiRo+Xyf nsRJiIThLXd8h4QSLJt2MPQju/nu84oVfZtvmXNvxJN75RMcs8vfktDRvGwGJSAsOpic flp81krlBIBcqnlEXpw22kwN5CQYJRw06o113eoUonvwgVSNUKUjHIAoamSVUbWGZnQe 0Gp9rUI0I6H9tRbXZEnQaKY9ZtL66Dvjw14lUeJN8gpcvnmm4klBgkg0/xruqxU5tySY ayzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790940824; x=1791545624; 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=PDojIWkbTG7AeBUmA+WcXOG+4O+hb7+PsQogC6F3kz8=; b=pc1PUuSwuJ0TM0oPX96QPlq2W3T4X/c8KiXrpn6y/sAZu6Kt7jITtaP9fqiMfx2FgN na1O41DVSUSx59edPPlHrQ9CmM+TT4KHU58RFzDHwbC26HgrIojoVz4IY6MlNJtDE2/D 6L6SDvC6PeF7bSoR7ZHA3AR4+V5fFxFtM+c4UuaB1fZSq0GTLvvE9L0yjmCBjhfxo0J1 3bf7TPV/NmiNhRxIzdM+YIXDmK9I+i3Btu41ONrvr0wFdCMri3gv12mgcaDyTNpIfD/j 9vYeLjM3w2lq9AYE427rBMBsPvH3uJ3V4tTKXbKkBpnEQlqTykca/LryoWilmgCNiJ7n 5pug== X-Forwarded-Encrypted: i=1; AKwUvBwsfqDOs9eNshE9yZdKApKTYQcK0ozHNYuGJ7pxRjNVNd9yxmPYhsJst8ngQ+0bETMfEamGeLhbkDI=@lists.xenproject.org X-Gm-Message-State: AFuF++mG4QIkMN4K/4+gHgLkegHHQ83PknN+zF94mR3yy83YEsHC23zY rjNr2wyNRIV7SbTzSXumeO8y9WTODOfX0R7N3wh/qU/tgdAD6dhifQvHRPo0FyTYig== X-Gm-Gg: AYBFou2NskjoXLnFzHqKapC64mITIwJq9aiZJ0m5YOAfTBIUdYKnkRXfHQmgrfjCu7L pgSrwGIQ9KJjanKng0NYoKBj1zwC2nzrp8F7vU8lkMlZyBtwFp+h08ToseK0dRYzGO6xpTo5h6n uilDGVL01ok6O8BpaD1jlcSmbzVqPEX9cfOwji2jPmhHnPC/koZ1rDaRFaqgDJhEuvZNQztYYrO rZn43HsQHpZeiMFNlIsIhe/NHoBzO30Qt9REY9DKthNLN+cPuYgdfFvJlpM8qg6pU50Q4x+9jBX 0UUzuwCVcFkuFFg5li/KsT9lu5q01JgTUd12prirX6HyiTCxGj2kgEmYjSXsiKYMBW8B+tX1pFm EyX0U9RldfXT2lMPas7+l1x7KrYEcRx0UGgq8/44AVlLtTvHSJfPz6DySeitB6zbwiSRah1KB12 3HucUMdHWUY7nk2xUS3Y51VeabelBSHDYGRUMaWD6z1W0ANDleWyIrx3enTCZwepdO5jIXmkGFr HTqRBU7nZWPEGjktPgcZrCH/vh/V4ONgyaJfI0u6XIxrhd07nruHCnbXpfx4g== X-Received: by 2002:a05:600c:3e19:b0:49b:8f5e:51fb with SMTP id 5b1f17b1804b1-4a027534b98mr43334665e9.3.1790940823925; Fri, 02 Oct 2026 04:33:43 -0700 (PDT) Message-ID: <8e26f887-453b-47cc-aaea-6c6675d9f9a5@suse.com> Date: Fri, 2 Oct 2026 13:33:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/domain: restrict context switch hooks for the idle domain To: Roger Pau Monne Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org References: <20261002112005.20656-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: <20261002112005.20656-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790940824-F64B42A1-D441D108/10/78276251493 X-purgate-type: spam X-purgate-size: 1098 On 02.10.2026 13:20, Roger Pau Monne wrote: > From: Grygorii Strashko > > The arch_init_idle_domain() initializes struct arch_csw idle_csw as: > > static const struct arch_csw idle_csw = { > .from = paravirt_ctxt_switch_from, > .to = paravirt_ctxt_switch_to, > .tail = idle_loop, > }; > > but only place where d->arch.ctxt_switch->{to,from}() are used is > __context_switch() where they are both guarded by !is_idle_domain(pd) > which makes the callbacks in idle_csw unreachable. > > Introduce a new poison value to be used in unreachable function hooks, and > set the from/to fields of idle_csw to it. Use a different value from the > currently defined ones for easy differentiation. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich provided this doesn't raise new Misra violations, including for rules which aren't entirely clean yet, but which are actively being worked on. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 02 13:26:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 13:26:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439131.1657581 (Exim 4.92) (envelope-from ) id 1xCdHN-0004yz-16; Fri, 02 Oct 2026 13:26:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439131.1657581; Fri, 02 Oct 2026 13: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 1xCdHM-0004ys-Ti; Fri, 02 Oct 2026 13:26:24 +0000 Received: by outflank-mailman (input) for mailman id 1439131; Fri, 02 Oct 2026 13:26:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xCdHL-0004ym-Sg for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 13:26:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCdHJ-0066BS-Sd for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 15:26:21 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfb0f5-2eae-0a2a0a5409dd-0a2a4507e020-18 for ; Fri, 02 Oct 2026 15:26:21 +0200 Received: from [52.101.69.104] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfb0fd-b4ea-0a2a45070019-346545686b5a-3 for ; Fri, 02 Oct 2026 15:26:21 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by AMZPR03MB226666.eurprd03.prod.outlook.com (2603:10a6:20b:7c2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Fri, 2 Oct 2026 13:26:20 +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.0472.016; Fri, 2 Oct 2026 13: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=ITu4IDdcYK3yKt/luxPc3qhQJ6hVPwCdhvgB35rIasS5FpCOLaN0WzvGa1jnSZKe8EjxtTLF2ye7iKnPIjU0WSw4wQi6AjLTQcgFbcDLvSsH0ZTSWNYLcBXnGQa9S94wz3s+LqxNa6uf+z+lNofeDPjR9ylJI0y7ii3d8bsfytPQVas9sURKFOT4s1rb8Miq4sF6q41kZfOZpootCe+dmOMiT0qYrbdesT289Rp+jHwifDzoI/Mo0oOctToJ+aXTT/4TcP6DIKlj98vezBk0XAqhdMt5Mz9QLFwQq9ELBBVBUPicRHrSJW2vvjM6fXyrOeOgJWZt5Z/b7vs/MZ+sVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=a2laLx1Ie/O+JEml8lhJVzRv5X21gnulo7eaZ+DeMNg=; b=lBH7J5gJEZ6klJ+2gVbBiZ96HPGEKry3LzW3iD7vf8d4FR8IvZZdmU/bldX9cWDwL6dUxG0jsMW2UYXd08lvqWQoRB5n/WzaygkSNx9xMQB3gTSxYWJhlTqq3LvW87HRDbOANbAk1jtj03LBTLA1s179nq1a5oM4Mi7C5NyWezpdm3uqNVYQDfLaa39NUlahsXgX8FduQnPwlxWbRzdZcHdjAfyoVMpNJQMVD3wqKJjkRDawSqFeHFwdc/RGOW4WtwR5ATEh5a3n04eGaf3JyFMCFfpyvjDwMzZKSJD9AjVN2lASklSCPciYOMRn8Isz8gkn5K0O+W/RCpOWwmwu0w== 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=a2laLx1Ie/O+JEml8lhJVzRv5X21gnulo7eaZ+DeMNg=; b=LZx6X9hy0FZ5R1NPhadXDF4Gge+mzQuDWDw5bAaGjXzMxi+zOzzzV/IvwW0ckrOsjmXUhtMclmijC+gGbpjC5cnKjJRI9viBlncvBVbMjk0Mdax24GK5fuUo7HKzL1dJexk5XMk4DwE9fqKy0YOZCUedyE527WkTPnkrc6zhrr4c4TQejClUduHDk6izQyF9CL9LnL7BQz8Kx6t40DmWeUl0LD6zXyySbvRzZFNbeuwcFvF0upCGVQI72UHmdBsdc2Te4yLKLWGC9r3dX1VSiSnDvSbO+d/a6zxw1jTxR4H1RdRm3fCcHEgK6g3HsrB2P+EKQAj9Cv/TXPhZVQnjZA== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Teddy Astie , Volodymyr Babchuk , Oleksii Moisieiev Subject: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Topic: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Index: AQHdUnGcfnmLH64VckKy7OjAkXrKMA== Date: Fri, 2 Oct 2026 13:26:19 +0000 Message-ID: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.git.oleksii_moisieiev@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_|AMZPR03MB226666:EE_ x-ms-office365-filtering-correlation-id: 041ce903-eacb-497b-97cd-08df2088bedd x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|23010399003|38070700021|11063799006|6133799003|10067099003|56012099006|18002099003; x-microsoft-antispam-message-info: 4MoLBBH7OeVyU7JjtLfMuo61/bim6BWSXO48tbkcU5lUsgJUD2UUhD9WnEtC9vhgXMjXNoaoykl3mtS4RxV4QNzEHBJ7lC4q6lb8FRdwXJs3eLdh1qDMp76TQ7THKanwfhltvPLj2MN0n/sz77gN96hn2L4yc+5SnCbSW6j9/qQ75TwwBO+C/0JEzt5eSNryXP3Y18JyFkjYgddujReNjGSoAdjiOACblhH5A0Z6/fTh8dpd5/FUv3Omw7/O/0yw6pu5u6rnwuKHogQdl0YlvHW5lIFXmkCLN1NnIPdVXJGUhjxf/pAskw0TE/CgoAuqkph3NVevXWSnimi6pi+WNjRW/xIjUppZotDCVAX8BRJwM2GQjntVbqKGxXt1vaIrMP6Y+5ZctIB0bLXCBlS1KZMmu/VaZub4x/iPkGJljx6i7EV2JnaAcH6qdY0GzAmYFGRy5SyWKnxtnLTMBQZ31OJTE3wOmfR7WgywvM2wK1+3bzsqW25y3bTsDExt0zcSmak/Bhb66ZoR6n7eloowm8H+xEBY0iNLUSJjtPH8LC60mzGH0fEBfHWj5PUDs2ZsbQl5N/WH55CItwzcEWz1iv6JYDb7GM5DY3sN7zQeEptD2yRuOt5uJA8GO3MFJjY+RE21SZJlqZWlkz97MBJAmJ12WogKW+g4Fgw6eNL6YeaUd87dlRL50wxUW15rbzJVV4xYcnO+XKqQSPccF33ZFFjtogzYHOTEq8rkHMS/VNU= 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)(1800799024)(7416014)(376014)(366016)(23010399003)(38070700021)(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?M3hYY05ZekdWcE5zcmhxNWRxWDdRUUJ6eHFxMVQxMVQwekg0WnhLOXpld04v?= =?utf-8?B?eUFRekF4N3dYb3o3eHBzU1A5T2RmNDBKdzFEVGp5Q3plNE5XUFhPOWRHRWRZ?= =?utf-8?B?ZnJFclBvbW1Rc3hXQlhKZWRGVDFNdTdaaFJMQlZhQmt1TGNReHZjenJzWHZY?= =?utf-8?B?RWVmNkVWNjFhNFNXT2tkSHVtWUt1QlNBY2dwb0dpaVY1d1lPMkZadC9weXo2?= =?utf-8?B?N1pWSllVQVNybStvMTJzQk1QNWxDRkNuRzEwcXZiUVZXZm0ybVhKV3Q5TEdo?= =?utf-8?B?S2FPYW51ei9zS3dlcVhBTVlBTjNJa1NCbFh4aWhPVGZWZThGY21yVUwyVkFX?= =?utf-8?B?ZHNIVnEzUng5dVV2cWNObmpQMkhNWWtIZ1pHdGhDbWFHTnVFNHlvQUpnSDB6?= =?utf-8?B?UWdvczBpeUpGa0tDSGdDMnk5R1dreXRrQW10Vm9udUUzSkJ2TUoyS29oZTM5?= =?utf-8?B?aWhoa2tza0g1b3RSV05FRDdUcFk3OC9xbHVXbS85NkRXNjQzVjA3bmM4TFZh?= =?utf-8?B?Z3UyRkJCV3ZKWWU1V1ZCalVQME5HVGg2TkJqYXFlNUJ4V1VjTTJzcC9nYnly?= =?utf-8?B?TVFEdVlGaFJ5MCtORHJQYTJNT2IwTENFeWZhaXNwOTlBZ3ByU2RhLytsMjFj?= =?utf-8?B?ZHFtNWZWNDRINVlnRGhycE9aRnJWNDFkdnZ6c0hGVUhqM3FxUE50ZTg4WHp2?= =?utf-8?B?VE1URnRhUFNXVEwrUmlHdHkwd0I4a0E3ZGFKdXFpZWxIVVZ4RTI4NW8wL1di?= =?utf-8?B?OG1XTlZ1UUxGczd5ZDlhaW8xbWxxSitoYTcyUU52WG81NFJsZXNQek5Ba28v?= =?utf-8?B?bTlnV2xQR1h3eEVTSmkwbzFzb3p2cjM1N0hoTE5Tb1pxM0VGdzFTeUJNNU9L?= =?utf-8?B?b2NGSVRzNndMYXgzOTB6UkZtV1lYVVREMmcyYUtaYmpGS1V0aVVuQTRnZmJu?= =?utf-8?B?dFgvR3pNcmszZVl2YkkyVmtyR0VCQnNmS0ljWWZHNDcvRi9XLzhKQTIvV0Za?= =?utf-8?B?cW9KSTFZNW1qVUpFb2NJVDZmZ1ZGekttMUw3Q2c0Q3Z4YkJFczdQTVp5dkkz?= =?utf-8?B?U0s1RXVYYnN0amVyM3ZOTXlQclF5ZzRwTmltTWM0YzZXOXkvczdRN3h5L1ZE?= =?utf-8?B?NGVCeHZ2RktlUjcvSFhGNXZFWjhidjJpUjJkY2RBOVpiN1hGQXpISGZvUGVu?= =?utf-8?B?WEthRW1JKzVVMnVsYzkyQmg4RnZKVmdWL2kwcnlaS1YwV3MzOGdublAvOWF1?= =?utf-8?B?VUlQbVZNUVJhenNWV1MyWnFDWmlkQVFPRnRPNm1PQllDdTNrWjY1MTBHQkQr?= =?utf-8?B?OFR3enUvcGF1bzhGazlvSXlRdEJyd2xNQzA3ZjV5WkRpcEd2R1lRb3hlbk5J?= =?utf-8?B?Y1ArZTErUjhSMUtxS3hTTlhuYmFMNzdLVFlJbWFqUlVOTkVyR215SHVERnpv?= =?utf-8?B?dkxPS0Jub3hVRFE3MFJCeDlvVFJFc0RhQXVhK2JSTE9kRWFtSTVIR0RjRnBi?= =?utf-8?B?b0dZNHBla1JUcWtidTZwZ1FFcVBZUjlHYXYvMjBMbmNoL044UEVTSVdhTHN1?= =?utf-8?B?a2RGcDRSUEgvNEZ2U2FzbW9yTVJ6N1JJWGtzRmJXTGtNNG1EZkNZaDltQVBK?= =?utf-8?B?V0duWFI2WGRjdzJQT2pnTEkvOXZjY1JrdnpjelptOEdwc0EzWHlsUFV2eU5U?= =?utf-8?B?VzEyNGlxSm5pNzZQVE1QZCtQSzYydmVSZUk5bFA2dFZvVFRsQmxMbURkRnVK?= =?utf-8?B?QjJSbERjdURDY1BYTnIxb2UxN29VRzd1a204UUVtQk90RUx5TzFOQWpCN29t?= =?utf-8?B?bENJeGNYamdFc2RZWFA1NkUzME5BU3ZDZkgxZFNWbm16UG53ZXVHM1JMRXU3?= =?utf-8?B?TWhJT1hpdUZxV2pnVFhJZmZKeVJ3UXJrQXNpbTFtQWYzcjQwMTgzaWRyTkhI?= =?utf-8?B?K0YyY0ZkSHJ5cnNyNGtvSnZHc3lXYjh5YUh0T25ubjVLVnhySHpGa1ZVc0FO?= =?utf-8?B?eGN0cFdIMXhjSDhsTTFWNndrTTBtWEtVYVRDaFhnNkZla000TUJhS1BOdkx4?= =?utf-8?B?cVBvUlloNk9YVnZRalRqQklsYkw4dktLdXZPUndPVVB1V2wxeFhJZjFGSEdD?= =?utf-8?B?ZW1tdFlySER6bFVPRXJERnFkRnVQNnI2L2FjQ1ZxZW5pM2dDRC9SdkI1RlEz?= =?utf-8?B?UlMrNCtIM1M4Ni80R1FXbnJxakYvZHRtVE1ETmhERVBGN3V5T3ZWRlpkajhO?= =?utf-8?B?OHU4ZVFaNStwSzdDVy9XS1hiblZENlI3NTE0Z3hray94ZWFEV2hRTUlMMzJh?= =?utf-8?B?S0pyQlQwejkybTZ3aDhoZWttSXZwdlc4UWZvYU9YY3E4ZzdNRXhuQ3h2TXFz?= =?utf-8?Q?B3hzxKxkbheBi5JU=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: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 041ce903-eacb-497b-97cd-08df2088bedd X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2026 13:26:19.9467 (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: MtPbHSEoLueEc3BW+39loZ67i6+ttFlpevRvmgxGOqAwGUs+DL1SaTHDJmS+IH+qw1zbmt2B1nz2fqq8By7inq9x2so/zrmS1wa/LP8n9kg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMZPR03MB226666 X-purgate-ID: tlsNG-ef75cf/1790947581-A44CBAE4-51EFA3BE/10/78276251493 X-purgate-type: spam X-purgate-size: 10396 VGhpcyBjb21taXQgaW50cm9kdWNlcyBhIG5ldyBLY29uZmlnIG9wdGlvbiwgYENPTkZJR19ET00w X0JPT1RgLCB0bw0KYWxsb3cgZm9yIGJ1aWxkaW5nIFhlbiB3aXRob3V0IHN1cHBvcnQgZm9yIGJv b3RpbmcgYSByZWd1bGFyIGRvbWFpbiAoRG9tMCkuDQpUaGlzIGZ1bmN0aW9uYWxpdHkgaXMgcHJp bWFyaWx5IGludGVuZGVkIGZvciB0aGUgQVJNIGFyY2hpdGVjdHVyZS4NCg0KQSBuZXcgS2NvbmZp ZyBzeW1ib2wsIGBIQVNfRE9NMGAsIGhhcyBiZWVuIGFkZGVkIGFuZCBpcyBzZWxlY3RlZCBieQ0K ZGVmYXVsdCBmb3IgQVJNIGFuZCBYODYgYXJjaGl0ZWN0dXJlLiBUaGlzIHN5bWJvbCBzaWduaWZp ZXMgdGhhdCBhbg0KYXJjaGl0ZWN0dXJlIGhhcyB0aGUgY2FwYWJpbGl0eSB0byBzdXBwb3J0IGEg RG9tMC4NCg0KVGhlIGBET00wX0JPT1RgIG9wdGlvbiBkZXBlbmRzIG9uIGBIQVNfRE9NMGAgYW5k IGRlZmF1bHRzIHRvICd5Jy4gRm9yDQpleHBlcnQgdXNlcnMsIHRoaXMgb3B0aW9uIGNhbiBiZSBk aXNhYmxlZCAoYENPTkZJR19FWFBFUlQ9eWAgYW5kIG5vDQpgQ09ORklHX0RPTTBfQk9PVGAgaW4g dGhlIGNvbmZpZyksIHdoaWNoIHdpbGwgY29tcGlsZSBvdXQgdGhlIERvbTANCmNyZWF0aW9uIGNv ZGUgb24gQVJNLiBUaGlzIGlzIHVzZWZ1bCBmb3IgZW1iZWRkZWQgb3IgZG9tMGxlc3Mtb25seQ0K c2NlbmFyaW9zIHRvIHJlZHVjZSBiaW5hcnkgc2l6ZSBhbmQgY29tcGxleGl0eS4NCg0KVGhlIEFS TSBib290IHBhdGggaGFzIGJlZW4gdXBkYXRlZCB0byBwYW5pYyBpZiBpdCBkZXRlY3RzIGEgbm9u LWRvbTBsZXNzDQpjb25maWd1cmF0aW9uIHdoaWxlIGBDT05GSUdfRE9NMF9CT09UYCBpcyBkaXNh YmxlZCwgcHJldmVudGluZyBhbiBpbnZhbGlkDQpib290Lg0KDQpTaWduZWQtb2ZmLWJ5OiBPbGVr c2lpIE1vaXNpZWlldiA8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQpBY2tlZC1ieTogSmFu IEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KDQotLS0NCg0KQ2hhbmdlcyBpbiB2NToNCi0g cmViYXNlZCBvbiB0b3Agb2YgdGhlIGxhdGVzdCBzdGFnaW5nLg0KLSBhZGQgQWNrDQoNCkNoYW5n ZXMgaW4gdjQ6DQotIGNoYW5nZSBNaXNyYSBydWxlIHRvIDIuMSBmcm9tIDIuMiBpbiBkZXNjcmlw dGlvbg0KLSByZW1vdmUgZXh0cmEgZGVwZW5kZW5jaWVzIGZvciBBUk0gYXJjaGl0ZWN0dXJlIGZy b20gRE9NMF9CT09UDQotIHJlcGhyYXNlIERPTTBfQk9PVCBoZWxwIGJ5IGFkZGluZyBoeXBlcmxh dW5jaA0KLSBET00wX0JPT1QgaXMgbWFuZGF0b3J5IGZvciB4ODYgYXJjaGl0ZWN0dXJlDQoNCkNo YW5nZXMgaW4gdjM6DQotIHJlcGhyYXNlIGVycm9yIG1lc3NhZ2Ugd2hlbiBkb20wbGVzcyBtb2Rl IHdhc24ndCBkZXRlY3RlZCB3aGlsZSBkb20wDQppcyBkaXNhYmxlZC4NCi0gcmVwaHJhc2UgaGVs cCBtZXNzYWdlIGZvciBET00wX0JPT1QgY29uZmlnIG9wdGlvbg0KLSB1cGRhdGUgRE9NMF9CT09U IGRlcGVuZGVuY2llcyBmb3IgWDg2DQoNCkNoYW5nZXMgaW4gdjI6DQotIGRlY2lkZWQgbm90IHRv IHJlbmFtZSBIQVNfRE9NMCAoSEFTX09QVElPTkFMX0RPTTAgd2FzIGFub3RoZXIgb3B0aW9uDQpz dWdnZXN0ZWQgaW4gTUwpIGJlY2F1c2UgaW4gdGhpcyBjYXNlIEhBU19ET00wTEVTUyBzaG91bGQg YmUgcmVuYW1lZA0KZWl0aGVyLg0KLSBmaXggb3JkZXIgb2YgSEFTX0RPTTAgY29uZmlnIHBhcmFt ZXRlcg0KLSBhZGQgSEFTX0RPTTAgb3B0aW9uIHRvIHg4NiBhcmNoaXRlY3R1cmUuDQoNCkNPTkZJ R19ET00wX0JPT1QgS2NvbmZpZyBvcHRpb24gd2FzIGludHJvZHVjZWQgdG8gbWFrZSB0aGUgRG9t MA0KcmVndWxhciAobGVnYWN5KSBkb21haW4gYW4gb3B0aW9uYWwgZmVhdHVyZSB0aGF0IGNhbiBi ZSBjb21waWxlZCBvdXQNCmZyb20gdGhlIFhlbiBoeXBlcnZpc29yIGJ1aWxkLg0KDQpUaGUgcHJp bWFyeSBtb3RpdmF0aW9uIGZvciB0aGlzIGNoYW5nZSBpcyB0byBlbmhhbmNlIG1vZHVsYXJpdHkg YW5kDQpwcm9kdWNlIGEgY2xlYW5lciwgbW9yZSBzcGVjaWFsaXplZCBoeXBlcnZpc29yIGJpbmFy eSB3aGVuIGEgY29udHJvbA0KZG9tYWluIGlzIG5vdCBuZWVkZWQuIEluIG1hbnkgZW1iZWRkZWQg b3IgZGVkaWNhdGVkIHN5c3RlbXMsIFhlbiBpcw0KdXNlZCBpbiBhICJkb20wbGVzcyIgY29uZmln dXJhdGlvbiB3aGVyZSBndWVzdHMgYXJlIHByZS1jb25maWd1cmVkIGFuZA0KbGF1bmNoZWQgZGly ZWN0bHkgYnkgdGhlIGh5cGVydmlzb3IuIEluIHRoZXNlIHNjZW5hcmlvcywgdGhlIGVudGlyZQ0K c3Vic3lzdGVtIGZvciBib290aW5nIGFuZCBtYW5hZ2luZyBEb20wIGlzIHVubmVjZXNzYXJ5Lg0K DQpUaGlzIGFwcHJvYWNoIGFsaWducyB3aXRoIHNvZnR3YXJlIHF1YWxpdHkgc3RhbmRhcmRzIGxp a2UgTUlTUkEgQywNCndoaWNoIGFkdm9jYXRlIGZvciB0aGUgcmVtb3ZhbCBvZiB1bnJlYWNoYWJs ZSBvciB1bm5lY2Vzc2FyeSBjb2RlIHRvDQppbXByb3ZlIHNhZmV0eSBhbmQgbWFpbnRhaW5hYmls aXR5LiBTcGVjaWZpY2FsbHksIHRoaXMgY2hhbmdlIGhlbHBzIGFkaGVyZSB0bzoNCg0KTUlTUkEg QzoyMDEyICBSdWxlIDIuMTogIkEgcHJvamVjdCBzaGFsbCBub3QgY29udGFpbiB1bnJlYWNoYWJs ZSBjb2RlIg0KDQpJbiBhIGJ1aWxkIGNvbmZpZ3VyZWQgZm9yIGEgZG9tMGxlc3MgZW52aXJvbm1l bnQsIHRoZSBjb2RlIHJlc3BvbnNpYmxlDQpmb3IgY3JlYXRpbmcgRG9tMCB3b3VsZCBiZSBjb25z aWRlcmVkICJkZWFkIGNvZGUiIGFzIGl0IHdvdWxkIG5ldmVyIGJlDQpleGVjdXRlZC4gQnkgdXNp bmcgdGhlIHByZXByb2Nlc3NvciB0byByZW1vdmUgaXQgYmVmb3JlIGNvbXBpbGF0aW9uLA0Kd2Ug ZW5zdXJlIHRoYXQgdGhlIGZpbmFsIGV4ZWN1dGFibGUgaXMgZnJlZSBmcm9tIHRoaXMgdW5yZWFj aGFibGUNCmNvZGUuIFRoaXMgc2ltcGxpZmllcyBzdGF0aWMgYW5hbHlzaXMsIHJlZHVjZXMgdGhl IGF0dGFjayBzdXJmYWNlLA0KYW5kIG1ha2VzIHRoZSBjb2RlYmFzZSBlYXNpZXIgdG8gdmVyaWZ5 LCB3aGljaCBpcyBjcml0aWNhbCBmb3INCnN5c3RlbXMgcmVxdWlyaW5nIGhpZ2ggbGV2ZWxzIG9m IHNhZmV0eSBhbmQgc2VjdXJpdHkuDQoNCi0tLQ0KIHhlbi9hcmNoL2FybS9LY29uZmlnICAgICAg ICB8ICAxICsNCiB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgfCAgOCArKysrKysrKw0KIHhl bi9hcmNoL2FybS9zZXR1cC5jICAgICAgICB8IDEzICsrKysrKysrKystLS0NCiB4ZW4vYXJjaC94 ODYvS2NvbmZpZyAgICAgICAgfCAgMSArDQogeGVuL2NvbW1vbi9LY29uZmlnICAgICAgICAgIHwg MTIgKysrKysrKysrKysrDQogNSBmaWxlcyBjaGFuZ2VkLCAzMiBpbnNlcnRpb25zKCspLCAzIGRl bGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL0tjb25maWcgYi94ZW4vYXJj aC9hcm0vS2NvbmZpZw0KaW5kZXggMDYyODkwMDVmNC4uNmQwOTM2YjM1MyAxMDA2NDQNCi0tLSBh L3hlbi9hcmNoL2FybS9LY29uZmlnDQorKysgYi94ZW4vYXJjaC9hcm0vS2NvbmZpZw0KQEAgLTE4 LDYgKzE4LDcgQEAgY29uZmlnIEFSTQ0KIAlzZWxlY3QgR0VORVJJQ19VQVJUX0lOSVQNCiAJc2Vs ZWN0IEhBU19BTFRFUk5BVElWRSBpZiBIQVNfVk1BUA0KIAlzZWxlY3QgSEFTX0RFVklDRV9UUkVF X0RJU0NPVkVSWQ0KKwlzZWxlY3QgSEFTX0RPTTANCiAJc2VsZWN0IEhBU19ET00wTEVTUw0KIAlz ZWxlY3QgSEFTX0dSQU5UX0NBQ0hFX0ZMVVNIIGlmIEdSQU5UX1RBQkxFDQogCXNlbGVjdCBIQVNf U0hBUkVEX0lORk8NCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgYi94 ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCmluZGV4IDcyZDUzMTYxODAuLmNjOTMyZDc2ODYg MTAwNjQ0DQotLS0gYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCisrKyBiL3hlbi9hcmNo L2FybS9kb21haW5fYnVpbGQuYw0KQEAgLTQzLDggKzQzLDEwIEBADQogI2luY2x1ZGUgPGFzbS9n cmFudF90YWJsZS5oPg0KICNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+DQogDQorI2lmZGVmIENPTkZJ R19ET00wX0JPT1QNCiBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5pdGRhdGEgb3B0X2RvbTBfbWF4 X3ZjcHVzOw0KIGludGVnZXJfcGFyYW0oImRvbTBfbWF4X3ZjcHVzIiwgb3B0X2RvbTBfbWF4X3Zj cHVzKTsNCisjZW5kaWYNCiANCiAvKg0KICAqIElmIHRydWUsIHRoZSBleHRlbmRlZCByZWdpb25z IHN1cHBvcnQgaXMgZW5hYmxlZCBmb3IgZG9tMCBhbmQNCkBAIC0xMjMsNiArMTI1LDcgQEAgcGFk ZHJfdCBfX2luaXQgaHdkb21fZ2V0X2ZkdF9hbGxvY19zaXplKHZvaWQpDQogICAgIHJldHVybiBB Q1BJX0RPTTBfRkRUX01JTl9TSVpFOw0KIH0NCiANCisjaWZkZWYgQ09ORklHX0RPTTBfQk9PVA0K IHVuc2lnbmVkIGludCBfX2luaXQgZG9tMF9tYXhfdmNwdXModm9pZCkNCiB7DQogICAgIGlmICgg b3B0X2RvbTBfbWF4X3ZjcHVzID09IDAgKQ0KQEAgLTEzNSw2ICsxMzgsNyBAQCB1bnNpZ25lZCBp bnQgX19pbml0IGRvbTBfbWF4X3ZjcHVzKHZvaWQpDQogDQogICAgIHJldHVybiBvcHRfZG9tMF9t YXhfdmNwdXM7DQogfQ0KKyNlbmRpZg0KIA0KIC8qDQogICogSW5zZXJ0IHRoZSBnaXZlbiBwYWdl cyBpbnRvIGEgbWVtb3J5IGJhbmssIGJhbmtzIGFyZSBvcmRlcmVkIGJ5IGFkZHJlc3MuDQpAQCAt MTg2Miw2ICsxODY2LDcgQEAgaW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tYWluKHN0cnVjdCBkb21h aW4gKmQsIHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8pDQogICAgIHJldHVybiAwOw0KIH0NCiAN CisjaWZkZWYgQ09ORklHX0RPTTBfQk9PVA0KIHN0YXRpYyBpbnQgX19pbml0IGNvbnN0cnVjdF9k b20wKHN0cnVjdCBkb21haW4gKmQpDQogew0KICAgICBzdHJ1Y3Qga2VybmVsX2luZm8ga2luZm8g PSBLRVJORUxfSU5GT19JTklUOw0KQEAgLTE4OTMsNiArMTg5OCw3IEBAIHN0YXRpYyBpbnQgX19p bml0IGNvbnN0cnVjdF9kb20wKHN0cnVjdCBkb21haW4gKmQpDQogDQogICAgIHJldHVybiBjb25z dHJ1Y3RfaHdkb20oJmtpbmZvLCBOVUxMKTsNCiB9DQorI2VuZGlmDQogDQogaW50IF9faW5pdCBj b25zdHJ1Y3RfaHdkb20oc3RydWN0IGtlcm5lbF9pbmZvICpraW5mbywNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUpDQpAQCAtMTk0 NCw2ICsxOTUwLDcgQEAgaW50IF9faW5pdCBjb25zdHJ1Y3RfaHdkb20oc3RydWN0IGtlcm5lbF9p bmZvICpraW5mbywNCiAgICAgcmV0dXJuIGNvbnN0cnVjdF9kb21haW4oZCwga2luZm8pOw0KIH0N CiANCisjaWZkZWYgQ09ORklHX0RPTTBfQk9PVA0KIHZvaWQgX19pbml0IGNyZWF0ZV9kb20wKHZv aWQpDQogew0KICAgICBzdHJ1Y3QgZG9tYWluICpkb20wOw0KQEAgLTIwMDEsNiArMjAwOCw3IEBA IHZvaWQgX19pbml0IGNyZWF0ZV9kb20wKHZvaWQpDQogDQogICAgIHNldF94c19kb21haW4oZG9t MCk7DQogfQ0KKyNlbmRpZiAvKiBDT05GSUdfRE9NMF9CT09UICovDQogDQogLyoNCiAgKiBMb2Nh bCB2YXJpYWJsZXM6DQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3NldHVwLmMgYi94ZW4vYXJj aC9hcm0vc2V0dXAuYw0KaW5kZXggMTZmODk5ZGZmNS4uZWE5YzAzN2ZiYSAxMDA2NDQNCi0tLSBh L3hlbi9hcmNoL2FybS9zZXR1cC5jDQorKysgYi94ZW4vYXJjaC9hcm0vc2V0dXAuYw0KQEAgLTQ5 MSwxMSArNDkxLDE4IEBAIHZvaWQgYXNtbGlua2FnZSBfX2luaXQgbm9yZXR1cm4gc3RhcnRfeGVu KHVuc2lnbmVkIGxvbmcgZmR0X3BhZGRyKQ0KIA0KICAgICBkb19pbml0X2Jvb3R0ZXN0cygpOw0K IA0KLSAgICAvKiBDcmVhdGUgaW5pdGlhbCBkb21haW4gMC4gKi8NCi0gICAgaWYgKCAhaXNfZG9t MGxlc3NfbW9kZSgpICkNCisgICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19ET00wX0JPT1QpICYm ICFpc19kb20wbGVzc19tb2RlKCkgKQ0KKyAgICB7DQorICAgICAgICAvKiBDcmVhdGUgaW5pdGlh bCBkb21haW4gMC4gKi8NCiAgICAgICAgIGNyZWF0ZV9kb20wKCk7DQorICAgIH0NCiAgICAgZWxz ZQ0KLSAgICAgICAgcHJpbnRrKFhFTkxPR19JTkZPICJYZW4gZG9tMGxlc3MgbW9kZSBkZXRlY3Rl ZFxuIik7DQorICAgIHsNCisgICAgICAgIGlmICggaXNfZG9tMGxlc3NfbW9kZSgpKQ0KKyAgICAg ICAgICAgIHByaW50ayhYRU5MT0dfSU5GTyAiWGVuIGRvbTBsZXNzIG1vZGUgZGV0ZWN0ZWRcbiIp Ow0KKyAgICAgICAgZWxzZQ0KKyAgICAgICAgICAgIHBhbmljKCJOZWl0aGVyIGRvbTAgbm9yIGRv bTBsZXNzIG1vZGUgd2FzIGRldGVjdGVkLCBhYm9ydGluZ1xuIik7DQorICAgIH0NCiANCiAgICAg aWYgKCBhY3BpX2Rpc2FibGVkICkNCiAgICAgew0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9L Y29uZmlnIGIveGVuL2FyY2gveDg2L0tjb25maWcNCmluZGV4IGU1NTM1YWM0ODQuLjM5MTgyZjZj ZTQgMTAwNjQ0DQotLS0gYS94ZW4vYXJjaC94ODYvS2NvbmZpZw0KKysrIGIveGVuL2FyY2gveDg2 L0tjb25maWcNCkBAIC0xOCw2ICsxOCw3IEBAIGNvbmZpZyBYODYNCiAJc2VsZWN0IEhBU19DT01Q QVQNCiAJc2VsZWN0IEhBU19DUFVGUkVRDQogCXNlbGVjdCBIQVNfRElUDQorCXNlbGVjdCBIQVNf RE9NMA0KIAlzZWxlY3QgSEFTX0VIQ0kNCiAJc2VsZWN0IEhBU19FWF9UQUJMRQ0KIAlzZWxlY3Qg SEFTX0ZBU1RfTVVMVElQTFkNCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4v Y29tbW9uL0tjb25maWcNCmluZGV4IDViMjg5ZTQ0NGYuLmNhMTZmN2Q2ZjkgMTAwNjQ0DQotLS0g YS94ZW4vY29tbW9uL0tjb25maWcNCisrKyBiL3hlbi9jb21tb24vS2NvbmZpZw0KQEAgLTI2LDYg KzI2LDE1IEBAIGNvbmZpZyBET00wTEVTU19CT09UDQogCSAgWGVuIGJvb3Qgd2l0aG91dCB0aGUg bmVlZCBvZiBhIGNvbnRyb2wgZG9tYWluIChEb20wKSwgd2hpY2ggY291bGQgYmUNCiAJICBwcmVz ZW50IGFueXdheS4NCiANCitjb25maWcgRE9NMF9CT09UDQorCWJvb2wgIkRvbTAgYm9vdCBzdXBw b3J0IiBpZiBFWFBFUlQgJiYgIVg4Ng0KKwlkZWZhdWx0IHkNCisJZGVwZW5kcyBvbiBIQVNfRE9N MA0KKwloZWxwDQorCSAgRG9tMCBib290IHN1cHBvcnQgZW5hYmxlcyBYZW4gdG8gYm9vdCB0byB0 aGUgYWxsLXBvd2VyZnVsIGRvbWFpbiAoRG9tMCkuDQorCSAgSWYgdGhpcyBpc24ndCBlbmFibGVk IFhlbiBpcyBleHBlY3RlZCB0byBib290IGluIGRvbTBsZXNzL2h5cGVybGF1bmNoDQorCSAgbW9k ZSBvbmx5LiBOb3RlOiBUaGlzIG9wdGlvbiBpcyBtYW5kYXRvcnkgZm9yIFg4NiBhcmNoaXRlY3R1 cmUuDQorDQogY29uZmlnIERPTUFJTl9CVUlMRF9IRUxQRVJTDQogCWJvb2wNCiANCkBAIC0xMjUs NiArMTM0LDkgQEAgY29uZmlnIEhBU19ERVZJQ0VfVFJFRV9ESVNDT1ZFUlkNCiAJYm9vbA0KIAlz ZWxlY3QgREVWSUNFX1RSRUVfUEFSU0UNCiANCitjb25maWcgSEFTX0RPTTANCisJYm9vbA0KKw0K IGNvbmZpZyBIQVNfRE9NMExFU1MNCiAJYm9vbA0KIA0KLS0gDQoyLjQzLjANCg0KYmFzZS1jb21t aXQ6IGU0ZGExODI5NzM3ZmI1NzUxMzNkMWY3OWQ5YWQ5ODcwMDA4OTE2NDkNCmJyYW5jaDogYW1v aV9kb20wX3JlbW92ZTU= From xen-devel-bounces@lists.xenproject.org Fri Oct 02 13:30:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 13:30:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439136.1657589 (Exim 4.92) (envelope-from ) id 1xCdL9-0006V0-G1; Fri, 02 Oct 2026 13:30:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439136.1657589; Fri, 02 Oct 2026 13:30: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 1xCdL9-0006Ut-DD; Fri, 02 Oct 2026 13:30:19 +0000 Received: by outflank-mailman (input) for mailman id 1439136; Fri, 02 Oct 2026 13:30:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCdL7-0006Un-O1 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 13:30:17 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xCdL3-00B8dt-0Z; Fri, 02 Oct 2026 13:30: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 1xCdL2-00BgHY-2C; Fri, 02 Oct 2026 13:30: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=B+ryK4cNzLrxJOPKW+kaF8YUKQUNuiDy7z0zKhxK+V4=; b=b+VhN9NxHWK3tskMdVI3bHIhJQ U2iCc6hpmd7uDLBqAVcQxWbSCGFvRuty+s0F46CMLXQDxoezfD12falIunEvIhLefgicJWjr8A7RI e+kNcr/xRV5eJZzelzvNINBHxD2WKtAbELuCMJvXC0FgSlcuJynZcLlvS2PniZiXKL/4=; Date: Fri, 2 Oct 2026 15:30:02 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Grygorii Strashko , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] x86/domain: restrict context switch hooks for the idle domain Message-ID: References: <20261002112005.20656-1-roger@xenproject.org> <8e26f887-453b-47cc-aaea-6c6675d9f9a5@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8e26f887-453b-47cc-aaea-6c6675d9f9a5@suse.com> On Fri, Oct 02, 2026 at 01:33:42PM +0200, Jan Beulich wrote: > On 02.10.2026 13:20, Roger Pau Monne wrote: > > From: Grygorii Strashko > > > > The arch_init_idle_domain() initializes struct arch_csw idle_csw as: > > > > static const struct arch_csw idle_csw = { > > .from = paravirt_ctxt_switch_from, > > .to = paravirt_ctxt_switch_to, > > .tail = idle_loop, > > }; > > > > but only place where d->arch.ctxt_switch->{to,from}() are used is > > __context_switch() where they are both guarded by !is_idle_domain(pd) > > which makes the callbacks in idle_csw unreachable. > > > > Introduce a new poison value to be used in unreachable function hooks, and > > set the from/to fields of idle_csw to it. Use a different value from the > > currently defined ones for easy differentiation. > > > > Signed-off-by: Grygorii Strashko > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich > provided this doesn't raise new Misra violations, including for rules which > aren't entirely clean yet, but which are actively being worked on. I've wondered the same, but since your recent change in: 68c3f7fb3a84 Eclair: relax long <-> function-pointer conversion deviation I think it should be fine? I will run a CI loop first anyway. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 02 14:09:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 14:09:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439162.1657599 (Exim 4.92) (envelope-from ) id 1xCdx8-0003EO-69; Fri, 02 Oct 2026 14:09:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439162.1657599; Fri, 02 Oct 2026 14: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 1xCdx8-0003EH-2v; Fri, 02 Oct 2026 14:09:34 +0000 Received: by outflank-mailman (input) for mailman id 1439162; Fri, 02 Oct 2026 14:09:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCdx6-0003Ds-EH for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 14:09:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCdx3-000GjU-MX for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 16:09:29 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfbb06-8faa-0a2a0a5109dd-0a2a45058058-46 for ; Fri, 02 Oct 2026 16:09:29 +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 6abfbb14-4cb1-0a2a45050019-b9ff1c229e9f-3 for ; Fri, 02 Oct 2026 16:09: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 1a0fcf2b6fe0003f66.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 02 Oct 2026 14:09:20 +0000 Received: from l14 (unknown [82.67.99.167]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 1993381CB5; Fri, 2 Oct 2026 16:09: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=fz0dclBg1ihwgNdSF2tokzF/Dcm7q2siJV46BNlZolI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Xepqx59RxaiRxLTfmMm6tuQFwp5cPj3Rmlyl7JNvyW/pFxG0IEFq41oDxH6YwU5Z1QIPU7Woy zG5zNPrshkDb21jX+z67+M5oSeIzxppLe+H/kZjMmAfiQ0VQn11puoYdLhXG0oAQTG0K5NF6qbI RRApbAfSJZJrbY2cwxohRzmc/jBltj9FF/77MSL5JubNWdGbxgXDqY6LsQvNmNBMEwrMHooU8Xn YgTiQb+/R5KbzfIQiqTt1E85LOb1JO6+QkWU8SqIDqIGLeTLcgWMfQoxh/4FpKy/HhhEDF01KN2 yyONWn3MI/1Ja/KiR3Cf7CPrRTDbAAHX7CnzeAxHKuTA== X-Zone-Loop: 7bf564b4b60eec917129e7060e22840c8b369bfa21a9 x-campaign-type: default x-transaction-id: 6d788f86-8b6a-4853-91d5-7130ad62aaf8 x-swg-uid: 01-9ae8b784-7bcc-44e8-bc65-26385bcd2abf X-Mailer: Sweego Message-ID: <1790950160.8631fc262581453bbf619ec5b2062170.1a0fcf2b6fe0003f66@vates.tech> x-swg-bid: 1790950160.8631fc262581453bbf619ec5b2062170.1a0fcf2b6fe0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 2 Oct 2026 16:09:18 +0200 From: Anthony PERARD To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= Cc: Furkan Caliskan , xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.5e0.4308b0e41f85da4f.1a0fcf2b3a8.6088f755c90867c3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790950159273 X-purgate-ID: tlsNG-c201ff/1790950165-71AAF2A1-BF70E853/0/0 X-purgate-type: clean X-purgate-size: 960 ---=Part.5e0.4308b0e41f85da4f.1a0fcf2b3a8.6088f755c90867c3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 18, 2026 at 12:45:28PM +0200, J=C3=BCrgen Gro=C3=9F wrote: > On 18=2E09=2E26 12:41, Furkan Caliskan wrote: > > Wire the per-cpupool admission-control switch through libxl > > to xl sched-rtds, and document it=2E > >=20 > > 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")=2E > >=20 > > Signed-off-by: Furkan Caliskan >=20 > Reviewed-by: Juergen Gross Acked-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.5e0.4308b0e41f85da4f.1a0fcf2b3a8.6088f755c90867c3=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 02 15:15:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 15:15:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439218.1657607 (Exim 4.92) (envelope-from ) id 1xCez0-00050H-4Y; Fri, 02 Oct 2026 15:15:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439218.1657607; Fri, 02 Oct 2026 15: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 1xCez0-00050A-1b; Fri, 02 Oct 2026 15:15:34 +0000 Received: by outflank-mailman (input) for mailman id 1439218; Fri, 02 Oct 2026 15:15:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCeyy-000504-5R for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 15:15:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCeyx-001s9N-EB for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:15:31 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfca82-bab6-0a2a0a5309dd-0a2a4505d3d0-42 for ; Fri, 02 Oct 2026 17:15:31 +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 6abfca93-4cb1-0a2a45050019-b9ff1c229f75-3 for ; Fri, 02 Oct 2026 17:15: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0fd2f3d240003f66.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 02 Oct 2026 15:15:26 +0000 Received: from l14 (82-67-99-167.subs.proxad.net [82.67.99.167]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id A7090800DA; Fri, 2 Oct 2026 17:15:25 +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=Ix+MWG1aDMJSNlcBNQc8Ob9p/qkmAqwKoNoWhltSI90=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=EcdjyHRjBVyNbbTQHjkJg+bjYlrTKMmfb+tSZY7Z8ya1q3qfdfFHNuljeCWjlnuZ0Pi958cnJ lIlv/4P+JoEcSah6b10deUZ4NREBcIZmgNDwBk/FlmSPp4SNumUchqR3srE1q1YyRWDhOPsROp7 RbPDHyaklctO6I+3PkiYfL29zymjeOoTHB2oVfFdRG8N05hufoLX0qskajYMgUr5gWMuD/IlY3C id5own45OUD0y0D7APYDwLRz+c/iGuNMQG3ujWfYn+X8e9SapUaP5kWMXuf7ryiyKD/cdaYMQhU 7DRJVM14biNTLdYhSsm99oYJXnpVi1BZTjXOlXi0vupA== X-Zone-Loop: d164275f075c4fe1def57c8c376b2a7d359520024f60 x-campaign-type: default x-transaction-id: 3e22ccde-0949-4339-9412-027892f6d3eb x-swg-uid: 01-a3a025ba-f88c-4c59-837e-e1576fe84a57 X-Mailer: Sweego Message-ID: <1790954126.8631fc262581453bbf619ec5b2062170.1a0fd2f3d240003f66@vates.tech> x-swg-bid: 1790954126.8631fc262581453bbf619ec5b2062170.1a0fd2f3d240003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 2 Oct 2026 17:15:25 +0200 From: Anthony PERARD To: Ross Lagerwall Cc: xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: [PATCH v3 3/3] tools/libxl: Add support for Viridian stimer direct mode References: <20260911091244.1165516-1-ross.lagerwall@citrix.com> <20260911091244.1165516-4-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260911091244.1165516-4-ross.lagerwall@citrix.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.5e8.844263e0f7d64ae4.1a0fd2f3a0a.53defecdf44d7939=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790954125834 X-purgate-ID: tlsNG-c201ff/1790954131-720AA2A1-75E528B9/0/0 X-purgate-type: clean X-purgate-size: 628 ---=Part.5e8.844263e0f7d64ae4.1a0fd2f3a0a.53defecdf44d7939=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2026 at 10:12:44AM +0100, Ross Lagerwall wrote: > Add support to libxl for using the stimer enlightenments in direct mode= =2E >=20 > Signed-off-by: Ross Lagerwall Acked-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.5e8.844263e0f7d64ae4.1a0fd2f3a0a.53defecdf44d7939=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 02 15:25:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 15:25:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439227.1657618 (Exim 4.92) (envelope-from ) id 1xCf8y-0006fs-27; Fri, 02 Oct 2026 15:25:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439227.1657618; Fri, 02 Oct 2026 15:25: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 1xCf8x-0006fl-Tc; Fri, 02 Oct 2026 15:25:51 +0000 Received: by outflank-mailman (input) for mailman id 1439227; Fri, 02 Oct 2026 15:25:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCf8w-0006ff-S5 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 15:25:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCf8v-00CE8K-R8 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:25:49 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfcce5-2eae-0a2a0a5409dd-0a2a45098d08-38 for ; Fri, 02 Oct 2026 17:25:49 +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 6abfccfd-be1a-0a2a45090019-b9ff1c2294f7-3 for ; Fri, 02 Oct 2026 17:25: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0fd38b9b90003f66.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 02 Oct 2026 15:25:48 +0000 Received: from l14 (82-67-99-167.subs.proxad.net [82.67.99.167]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 9005D8229D; Fri, 2 Oct 2026 17:25: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=xMRGVFoWsIF6udNRmRcfQY2eHJeK51vcukcVIkpw8D0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=eB1nA1cB4bdeFGot3prYx9fbG3rA+qdeJtXzZOghYnvRVkFPqkkibSMJTyDDnQ+H/T8KKQcMl a1RlKBEhrldU0QNDjUtwtTrqfkhi2xNoAC8uT9QK+VZDfbm82zyt5Y0LBSOvLdsR95UwJ/XkphR UtQ5Q9zPdiVT9DCfbZA/eMQT1vuYiIycNOWS5R8D1osf8nJDVonFDdpwTIcqd+Fo7dZpGXWGUNb +MCjz20CEgUhygzW9Kozefb+ncV2V+d7OQqbziqCDKxdjXhJKroTWUZIcvDbVqWhdawFf4n6pNA Bllmx6yy9ceLpjUhZwLnBTIvhVoZ0kIfPyoJ6pJUvSrA== X-Zone-Loop: 0d05f3949fea57c6d1c89a63ba1c42dd8fab6079a57b x-campaign-type: default x-transaction-id: b3b93cce-ef05-425a-95d7-a7cf93909917 x-swg-uid: 01-7c06bb1f-fa6a-4798-9682-d72d7b19ad2c X-Mailer: Sweego Message-ID: <1790954748.8631fc262581453bbf619ec5b2062170.1a0fd38b9b90003f66@vates.tech> x-swg-bid: 1790954748.8631fc262581453bbf619ec5b2062170.1a0fd38b9b90003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 2 Oct 2026 17:25:47 +0200 From: Anthony PERARD To: James Dingwall Cc: xen-devel@lists.xenproject.org, James Dingwall Subject: Re: [PATCH 1/2] tools/hotplug: fix invalid frontend path for set_mtu References: <20260814060441.923061-1-james-xen@dingwall.me.uk> <20260814060441.923061-2-james-xen@dingwall.me.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260814060441.923061-2-james-xen@dingwall.me.uk> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.5ea.bb9c48ae452a9775.1a0fd38b732.6d117db070233a58=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790954747699 X-purgate-ID: tlsNG-bad1c0/1790954749-3AEDE034-D406BE36/0/0 X-purgate-type: clean X-purgate-size: 1378 ---=Part.5ea.bb9c48ae452a9775.1a0fd38b732.6d117db070233a58=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 14, 2026 at 07:03:50AM +0100, James Dingwall wrote: > From: James Dingwall >=20 > The set_mtu() function of xen-network-common=2Esh currently has this cod= e: >=20 > if [ ${type_if} =3D vif ] > then > local dev_=3D${dev#vif} > local domid=3D${dev_%=2E*} > local devid=3D${dev_#*=2E} >=20 > local FRONTEND_PATH=3D"/local/domain/$domid/device/vif/$devi= d" >=20 > xenstore_write "$FRONTEND_PATH/mtu" ${mtu} > fi >=20 > This works fine if the device has its default name but if the xen config > defines the vifname parameter the FRONTEND_PATH is incorrectly construct= ed=2E > Learn the frontend path by reading the appropriate value from the backen= d=2E >=20 > Also change use of `=2E=2E=2E` to $(=2E=2E=2E) for a consistent style in= the script=2E >=20 > Signed-off-by: James Dingwall Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.5ea.bb9c48ae452a9775.1a0fd38b732.6d117db070233a58=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 02 15:27:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 15:27:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439231.1657627 (Exim 4.92) (envelope-from ) id 1xCfAm-0007IM-Bb; Fri, 02 Oct 2026 15:27:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439231.1657627; Fri, 02 Oct 2026 15: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 1xCfAm-0007IF-7m; Fri, 02 Oct 2026 15:27:44 +0000 Received: by outflank-mailman (input) for mailman id 1439231; Fri, 02 Oct 2026 15:27:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCfAk-0007I3-Rh for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 15:27:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCfAf-000RSx-8Q for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:27:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfcd5c-8faa-0a2a0a5109dd-0a2a4501c8ae-18 for ; Fri, 02 Oct 2026 17:27:37 +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 6abfcd68-5984-0a2a45010019-b9ff1c129db3-3 for ; Fri, 02 Oct 2026 17:27: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0fd3a548c0003f66.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 02 Oct 2026 15:27:33 +0000 Received: from l14 (82-67-99-167.subs.proxad.net [82.67.99.167]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id B5D66809C6; Fri, 2 Oct 2026 17:27: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: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=2k2CxDwV8XUNeG+VQjpahB/T6ktUfINrt+l/Gepot4s=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=DRd5ra/pGQP6CHB/OaSTO/2a39jyDfPC4qz9/K20qhD7rwB7qkYu98rW61f+lxACKm0pNokH9 9WmugjOGhl+/LR4Q69MNKbEiFBgphkODECeClAi+D3mYZRqkZs+icCZEi5q1UvDOQhJixJs8DB2 hSGoqblgkticvOuc5iUjdK7LtPYQHeoYGpsPIyU1PyHDWK0TgkpSURQefkQUaVXqyxYiLYr78Ya AhkGfC9Z6qSgTySgAwUaLdbxbT6lPo0vsn42nd3Djx06L4bEbCqBAMgd4d720WDJ44TBZJLIZkZ WLFcG1rrnzxJytE8ls77l7FlRxAYYyOXvyjn6MgGBcUw== X-Zone-Loop: b76e80e7d30525a47f22f36fcd7c2a3e8cbe5bc5bfa9 x-campaign-type: default x-transaction-id: 13cc0e9a-0031-462d-b6f0-f1d5554a8803 x-swg-uid: 01-1f51c301-c5a2-46ed-b2ef-08ff477a4ffc X-Mailer: Sweego Message-ID: <1790954853.8631fc262581453bbf619ec5b2062170.1a0fd3a548c0003f66@vates.tech> x-swg-bid: 1790954853.8631fc262581453bbf619ec5b2062170.1a0fd3a548c0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 2 Oct 2026 17:27:32 +0200 From: Anthony PERARD To: James Dingwall Cc: xen-devel@lists.xenproject.org, James Dingwall Subject: Re: [PATCH 2/2] tools/hotplug: validate mtu read from xenstore against RFC 791 minimum References: <20260814060441.923061-1-james-xen@dingwall.me.uk> <20260814060441.923061-3-james-xen@dingwall.me.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260814060441.923061-3-james-xen@dingwall.me.uk> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.5eb.10b6ee2fe678b154.1a0fd3a51ed.9f1557c3373a6e0e=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790954852846 X-purgate-ID: tlsNG-d62444/1790954857-BF46D757-A9AA61C5/0/0 X-purgate-type: clean X-purgate-size: 1181 ---=Part.5eb.10b6ee2fe678b154.1a0fd3a51ed.9f1557c3373a6e0e=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 14, 2026 at 07:03:51AM +0100, James Dingwall wrote: > From: James Dingwall >=20 > RFC 791 sets the minimum acceptable mtu to 68: >=20 > Every internet module must be able to forward a datagram of 68 > octets without further fragmentation=2E This is because an internet > header may be up to 60 octets, and the minimum fragment is 8 octets= =2E >=20 > In the Linux kernel source: >=20 > include/net/ip=2Eh:#define IPV4_MIN_MTU 68 /* RFC= 791 */ >=20 > While there is no reason to expect a value <68 to be read from xenstore = or > from the bridge make the value test require a number >=3D this minimum= =2E >=20 > Signed-off-by: James Dingwall Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.5eb.10b6ee2fe678b154.1a0fd3a51ed.9f1557c3373a6e0e=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 02 15:33:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 15:33:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439201.1657641 (Exim 4.92) (envelope-from ) id 1xCfGM-0000YZ-6Q; Fri, 02 Oct 2026 15:33:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439201.1657641; Fri, 02 Oct 2026 15: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 1xCfGM-0000YD-23; Fri, 02 Oct 2026 15:33:30 +0000 Received: by outflank-mailman (input) for mailman id 1439201; Fri, 02 Oct 2026 15:00:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCekA-0003Sp-ST for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 15:00:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCek9-00CpLJ-Vm for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:00:13 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfc6f8-e002-0a2a0a5209dd-0a2a450989e2-12 for ; Fri, 02 Oct 2026 17:00:13 +0200 Received: from [52.101.66.22] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfc6fd-be1a-0a2a45090019-346542161757-3 for ; Fri, 02 Oct 2026 17:00:13 +0200 Received: from AS4P190CA0028.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:5d0::17) by DB3PR08MB9897.eurprd08.prod.outlook.com (2603:10a6:10:436::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.13; Fri, 2 Oct 2026 15:00:06 +0000 Received: from AMS1EPF0000009C.eurprd02.prod.outlook.com (2603:10a6:20b:5d0:cafe::9d) by AS4P190CA0028.outlook.office365.com (2603:10a6:20b:5d0::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.19 via Frontend Transport; Fri, 2 Oct 2026 15:00:06 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS1EPF0000009C.mail.protection.outlook.com (10.167.242.73) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Fri, 2 Oct 2026 15:00:06 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) by MI9PR08MB641028.eurprd08.prod.outlook.com (2603:10a6:290:b6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.12; Fri, 2 Oct 2026 14:59:28 +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.0472.016; Fri, 2 Oct 2026 14:59: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=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=uAQfV3EUJW62CcM0EELXc3JHfIPV2TVgJ5yHWJTdeA4Q4X6MP/f5xbw2g+jHORKQe94uYwgaeN7FuwqkYsLBfzI0lLzODSmRjs13GkZLAPbcffhDra13NKdD2o9kRr8Hpy37vGXf0i7Yjtd1sirIHnnO0KUkBbtTQSUdLje3PhXE3wuBCyxb6XXKpoNM7VPzD0z51N+rPSXSLnFop0h2pLUalALVfCHaaPWi7y6mZ+A79PLLvuLdhg2+bjF/Sgh8nXji/DnCGHN/1tY+Ho8Uf06Sjta+lBb+F6a6wrO8J5dS/rY3Q0jRJi5m8O0m/mD5qjs7SWBXTJ9/I+iLXrWNGQ== 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=Ti/5xvbZ1AAv74C2/nfdQE1m+h+p3/QI+PEVwvH6dc4=; b=Rh7EIoy39F3hpUwlXpL9Lj2nD74UB7MygNQ1r8sQsMqV3zRK0PKBRQ0n4Vik08I94PG6O84vZ56XKOWa6eVPyu4lj62hC47uieSefGZ2m02BL0Ee1j+z8d8znVU8pNgIpfxIwlB7X4VVnHISWNDyh+mcPqqNkJw5fT4HKc/i34eWu64FLHXZFZHNV1n4ogynNJHEjhvPt1gl9D63wt+GoerJGKRHQRgs2a0B4cv48Saej4SljRtl2GJHSv8uLYiRgi4AhNpx5Zq8dazC2wTYawv9rmTc3COr4UzIM+HOsXqlglO5QVQtQi45d6yJj4oHcUvjysD4isQZ25D6rD6PcA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=intel.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=Ti/5xvbZ1AAv74C2/nfdQE1m+h+p3/QI+PEVwvH6dc4=; b=Mo2nDH6eiiPGh7acExyLyD+Jj4WqZLPMkj5+IQJPLowJkHahm3omPF9SasuBLbFHb28M0ZAl0V6NkAsy1KXrrgZQeaXFhpkRCokyjEoOH3JIRVWGzZED5fJ2hndCjXKqF+P40X3gZ6SHd074yuEpTLDkLLIrwKQGrc3ghWf3N9Y= 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=l3VEqmKvuZAU0+agmoZzr+8hppPqTJFFjvc4xTWXU7zI0brox9y2VNY0kZVvIu0zzCRwzXjfbOjAKCiBJMsA6BBszQ6ffq1eXuqvdGPo2eMZAXS/WHss44krBPSAGZSY77dO2KIOU8LnF0mTtNiBafcZp2GFVFB80DipFgiLK2R9CBLv94wyyz9Rb3tDTqQFFngoc+JsQV6z/aL5viDSQmIeMif8Ta6JnjNqel+cUuXWxLwcFyjGWoV6sxib1D41Ff3v/P27rUiS2vbzCTkzedgDkhjW6cuMcERqBodwlJm3fFa9e1++PL5XX/b18SxdSKWHD32aOwUuqxu4MeQKDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ti/5xvbZ1AAv74C2/nfdQE1m+h+p3/QI+PEVwvH6dc4=; b=ct2u76lGXznHnGAjkKWIvF/QheO8nIZ68MLyiN+rmPU6QfrHfFOfmG5tISyqlCdZKb7bEFIvXMYnOTje6TSEL0GIIAuLIHDZXQax3NVHDvI9ueJDGw3pMFZ83K87pZ7QLqfS6pt7c248vcvHR73N4mQyGe4TSd7w/SXqJ9WHsXmJeF0JcmJcubJG+aOCZ0BmCL9JEpPcCp9YBuzcGCs9s5MGRoOJSBGNNbwXJsdUFbWfBaVVvhPiDVZsFFWzhfsSiLJpRwafrTjgGQ1LvrSnVMuiyEIrXGftQt7U533VnnfVKXIvlqaXGVnHroKkRh+reVZ4xHULl9F3NqgzmSPsrw== 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=Ti/5xvbZ1AAv74C2/nfdQE1m+h+p3/QI+PEVwvH6dc4=; b=Mo2nDH6eiiPGh7acExyLyD+Jj4WqZLPMkj5+IQJPLowJkHahm3omPF9SasuBLbFHb28M0ZAl0V6NkAsy1KXrrgZQeaXFhpkRCokyjEoOH3JIRVWGzZED5fJ2hndCjXKqF+P40X3gZ6SHd074yuEpTLDkLLIrwKQGrc3ghWf3N9Y= Authentication-Results-Original: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Message-ID: Date: Fri, 2 Oct 2026 15:59:23 +0100 User-Agent: Mozilla Thunderbird Cc: usama.anjum@arm.com, 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, "David Hildenbrand (Arm)" , Andrew Morton , 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 Subject: Re: [PATCH v3 6/9] mm: add hw_pte_val for HW PTE storage To: David Hildenbrand References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-6-5670b8cb9059@arm.com> <2dcd9dbc-99ca-4f5e-8e25-f42977763c84@kernel.org> From: Muhammad Usama Anjum Content-Language: en-US In-Reply-To: <2dcd9dbc-99ca-4f5e-8e25-f42977763c84@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0506.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::13) To VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3421:EE_|MI9PR08MB641028:EE_|AMS1EPF0000009C:EE_|DB3PR08MB9897:EE_ X-MS-Office365-Filtering-Correlation-Id: a034d3be-d90e-477f-407f-08df2095d84f 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|7416014|376014|1800799024|10067099003|56012099006|11063799006|4143699003|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info-Original: awZGmDrP+n8iLBKvmVXHTttSmqRxMeSGungA92N+sXf6yE3oI65JXMYjoyoqZU4z92EjLnPwdA3swFEzepXI34dKn43yBmeVvLqIUe/aBv08SgXGzrmAxS717gejGWy8U4rPYkvOIDdyiBxd2MBpfzCJlWMuJUzzr/Wp+j3suycL5rjxd/v30SmewNFgPgNQgQfr10cfje9l+9HvcpHE8UaxFi2m98g/Oi1yFh1Uv7p83MBhZzn3LxcBIRczyIMvxVclUNwFTHfOSqMknRfYtrchbmqunIu6Mb0NweYLrvUPqE6ht4UxNYMe9LubbLj0Z2CDA/bRAHha1WPyDPpEeMgLlZ7ttBS8IhHCFiIstMQ66XUeWBLvVis9enTtmnqK/jdaFIplCGIsd76kNk+meVo8W38oNZdpqw8ADA77Z0k5L3wSocvuaE/Jv02VD4+Yu/fdyYpMGa9TY4CDAu33JydBOUkVs9q39XNddxpJgbW4r+th+qCEhwCOzFeVMy3aAVkJ64e9rj5Db+h19TKi6I1q66jeb6gu8PyGYzRJRxwM8+Ze7MsHhx3jpuXiau+zNi20djXGuN/50xIlRPUpcpXdIeivXUrEcm3rd/dUuKz3a6g4TuBdUDqyIM6I6Rnz3ylxUov8Yd87TbRsm/QMEJl0iwp4KFdC2hGLxcMxCi4= 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)(366016)(7416014)(376014)(1800799024)(10067099003)(56012099006)(11063799006)(4143699003)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-Exchange-RoutingPolicyChecked: O/ShE+MLm7IKbo9g36eL3X0mvPd8jlMxid/HVeiYr6CQ/77qfCa3N/b4vIwk1i1PLKqJlVUWlqDgRxqtKEPjtwupepE/KVG1qbX766JDmNnClOViKhwOGw2odERsg9V2MjPMqfmYMVgxuz4t93xa4jorFwnbmORgOPy4FhhUFe0nYkv1xqlrkn9VHF3vW5h65bao/GxIP1gmv+LW0ignAeRy6AzaqIhaREPatPNVFTOpKJfRCCBw+9xErF4dn+NC6XkhhsqIS5cKm3zOB/HmOtHh5S8/5xktPWw6L8Ata4pti5pA2V19xSSvyXK97GtzwJMmr8bgS0R/wczjrkICXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MI9PR08MB641028 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS1EPF0000009C.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 8e3e908f-f49f-42a7-a5e9-08df2095c16e X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|7416014|35042699022|1800799024|36860700016|82310400026|14060799003|56012099006|11063799006|4143699003|10067099003|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: e3PVHNV6Atu4PUVDGTRp8g81vqrcCMJA/whGHwuBhmxf3Bo5KxOpwZ7/t/Dtp55WWTPpJn0EfGRVWhw0dbOxPDtIqsiLjPBUO5SoavPEuHHIj62gBfPg8JelhvQRTTynrhyLfEsO0GQiHAnXOd+chyflqWvmjo7MMw5ZR7npBKEUG23i5lScAFhbAIcJkyu2eFUM6dV2ue8YLiy74oQTnEilKcsLb/7rAfWbEzqWvkVJdJNPoZflu8rEZ++XcI0T0S7stdOKDxNbY9P79NLrB2A+iFbvT3uGhoAXRg5JwgHfe/iTKRIxMzNm8y33mdMwe+MYZbt5WCwfcazjfy427YYThdoFFaME59/Bu6xv6TCthRyipjx9H92z5fIdp7uZc9ffkSGADyyN3St6p0hxoBrGXok/z9hnbPb4/2/MTm0AAr3hpyBtOVreV2zS0X7hmzMapU8GBksu9QFZQN3tdA8f7kHHUu3K1+74WrDSAyrpWEsOzFlEhQ8evkzD6XV0pt6+/rEZCuDr+H8/AkX36t4A+plgvjWc9ev6dDptVq9YGC399Mu1kBXJUCrYR5WqZ31/R7uLa9MInAdfZeK8vRGom+3XMiBfQFGmUcXbA91wDTFed36qS0G4Qg0DBia9gx4+7pW7jQpYL32DjPf6pvOpEHtpYpjyv703KcgQsY6WDSm6N/zAgWD7hdBG1TfU202RzLBYlbX29fmnz5nyjw== 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)(376014)(7416014)(35042699022)(1800799024)(36860700016)(82310400026)(14060799003)(56012099006)(11063799006)(4143699003)(10067099003)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: nHkjJVNJiDScHS7JCHIRkUZQWOdQ/QJve4xVDinlyoCcIfKtj5o7oAzp92if3AokVhSRa7cY4lXMqEqipvOmJjJwamYgB64kjr4PjseTzYLppgjBVAu35cRVnzCnsVxS4cTzFCng0dStiAaXZrgH0US0jysiQsOCI2idInD1S1/FcT9U2PufYfGi65Bx19hJzZlaw1nZR23T7S2Q3p0bWKV+Yk4/nUIm7Lra0OB/unZOJ8LSVR3SrjXptH+l7zPjbQ7PV9EtFm1Z9kmpSfBoMq4GOgDP+fusWnFi7NnXOxyQAaaS4GLeHj1sdf53NqxUJIEM+BlmGRiaF5WscIVNY1Re6LyzVWVRSYRjL3zvRaxmXAMfEIhLVORgvyISUrYOP/pzMfMQUEMGoIy0PcaxoIphhassmN5iLZEoGI4YY8g0m21Vkz8O/znrRuBmA0iw X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Oct 2026 15:00:06.0457 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a034d3be-d90e-477f-407f-08df2095d84f 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: AMS1EPF0000009C.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB9897 X-purgate-ID: tlsNG-bad1c0/1790953213-FC411034-1FD972BD/0/0 X-purgate-type: clean X-purgate-size: 1807 On 01/10/2026 12:19 pm, David Hildenbrand (Arm) wrote: > On 9/22/26 19:12, Muhammad Usama Anjum wrote: >> 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 > > I was just about to say: this series doesn't add any users. You should add that > detail to the patch description: "prepare for usage in arch code" or sth like that. > > With that > > Acked-by: David Hildenbrand (Arm) I'll add to the description. Thanks for reviewing. -- Thanks, Usama From xen-devel-bounces@lists.xenproject.org Fri Oct 02 15:33:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 15:33:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439198.1657636 (Exim 4.92) (envelope-from ) id 1xCfGL-0000Vv-VA; Fri, 02 Oct 2026 15:33:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439198.1657636; Fri, 02 Oct 2026 15:33: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 1xCfGL-0000Vo-RC; Fri, 02 Oct 2026 15:33:29 +0000 Received: by outflank-mailman (input) for mailman id 1439198; Fri, 02 Oct 2026 14:58:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCein-0002Q2-Uk for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 14:58:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCeim-005PUt-FY for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 16:58:48 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfc67d-8faa-0a2a0a5109dd-0a2a4504bda4-26 for ; Fri, 02 Oct 2026 16:58:47 +0200 Received: from [52.101.83.63] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfc6a7-b57f-0a2a45040019-3465533f9f99-4 for ; Fri, 02 Oct 2026 16:58:47 +0200 Received: from ZR1PEPF000077BA.CHEP278.PROD.OUTLOOK.COM (2603:10a6:918::474) by VI0PR08MB11501.eurprd08.prod.outlook.com (2603:10a6:800:2ff::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Fri, 2 Oct 2026 14:58:42 +0000 Received: from ZR1PEPF0000E6B0.eurprd05.prod.outlook.com (2603:10a6:918::157) by ZR1PEPF000077BA.outlook.office365.com (2603:10a6:918::474) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.15 via Frontend Transport; Fri, 2 Oct 2026 14:58:42 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by ZR1PEPF0000E6B0.mail.protection.outlook.com (10.167.241.87) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Fri, 2 Oct 2026 14:58:41 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) by GV1PR08MB10856.eurprd08.prod.outlook.com (2603:10a6:150:161::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Fri, 2 Oct 2026 14:57:59 +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.0472.016; Fri, 2 Oct 2026 14:57: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=YPvQ0a+7By6XQcEb8hlq+PrcGIxgwJB2znE1fMq4EOM3BkGN5jHzQfynTR1ygeg1QAa0gAzG8zxWPigEcBuVr9awwmmU7k2tB/ZAWF5HP6FSgJB2uachJBJu9G8YhnqakvUlQ4rr+Y2BdOH5kZDeiKWgSZl9i5ZOi8QerpW14Bi1Ps2O0WS3mI6dg0xt85fd2f+E9/M4tYwA+xF9cs4lasA6EBNC7y5ztYMrOkJ/6nrlD8hIMRh6zw2TrUMYqn0lIw6AObAJr5GssHNM1hMhlMbNX8YGzfomzk/XojuaX/VrQbl4DEeBHbxalwbth9zFwXkgozhtptj7fuVYVnbdWg== 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=b3Ah6swvMtWzeWq4SM6XIIUNRxfAhr9a8O2D5gmTT3s=; b=SJkj2wwVG1eZxAbGxGaoOnULq5H0zUO5cZEi6UUAnHwRxQUm9tSidjatutWzcT01MCoFKDv0LZeD70JgVEz06FNAQfMBAcuytqowro9+pE90fjHAUeE/nxDfb1Lu4ssqyST0A9WHGAstNe09+lMTTchaqwhOpGa62nIZ/blfMCfO38/cYPWOFDG90em1q9haR0FGn6MWDKFSLAncgrw5E6Jx540B5nWFZK6kq9HZIeD3l2vmgzziMNy8rZRvcqHR0mYy5A7g+F6eNeeG7rJt/h/ZV/cFs4888JgbvGJkSBKlHERT5cx4Mpkpz0X7kJbyG7DWus0/LWo5TnQTump44g== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=intel.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=b3Ah6swvMtWzeWq4SM6XIIUNRxfAhr9a8O2D5gmTT3s=; b=UJcWlmHQHD1z6UzAsf0AsXyWIx/n+YuOAR8uwm4lC4UsM/1VWXYStnqfg9poduspEls8OzGsiySlaYVY4oB/MorRmaNyIUCPBYKvmdCg1HJJnA6z9kcFuEy2+Bcb0H0JeQMlbUZK8KivhGoCbOw4ao+1HjGBB/BvBK2I1xV7EEU= 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=qf1ioclt6CZLsZI5sbHKKNFSAw7r3xz4tB6DNEdFGmiWnjOu4Kz4KF+DzZeXzE5HJpiiXiCP6cwF4g3zJGcExLuEFgfePTraNXmMR1pzCXtJmUHpOwPmrQAm+xjKTQxdlPsr63yZOIVYgPrIp+NsWOYn2YTFQ60InG0yTZG6A4lUgPwjg5O+O+b1XpX0MMu9w5zvTTsIgMbeRlWzrAKUkNoa5M+hRFB4VhS6U+h0hDS+AC+S/qFszAb/1OMd47g2tdM2zzR4k5nl6dIKwEj6gXb3kjV/dn6j7D/JTjLbsFRCXECWq7fhORVbvwWdee0fUlbZqXGM1uCj2/n6q30rfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b3Ah6swvMtWzeWq4SM6XIIUNRxfAhr9a8O2D5gmTT3s=; b=mm5FZi7KiBf/IpnKgskI5Q8S4CYFgRFxXU6qHkW1QRE2f/adMulUNbzu58a7+D0WjlxHVTy5AD1wqskKJmJgT/PUuAJ73Vxc7VP4YQW2xYVzY3IjG3/LZ8NJhFSnF6Hc9YSR4Nvx08SL0aYa2GonfzXPlB4w9sXdtZm1ZDk0okUiaB9SkjKtbnBb2pr4x6XANDziWk1KJCTBDZd5JJB/LR+EgHza5b9XtxD8NX/QLrd9j1x++hHIQqeU+WEKUV4hvepEFdD+ujiQ3dROlfvA28nevX2u3BfGBOU+yvijUYCPmfgzoh8WUR5RVCNDE62BrmJvcSz2tzapYtJkAa/uKA== 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=b3Ah6swvMtWzeWq4SM6XIIUNRxfAhr9a8O2D5gmTT3s=; b=UJcWlmHQHD1z6UzAsf0AsXyWIx/n+YuOAR8uwm4lC4UsM/1VWXYStnqfg9poduspEls8OzGsiySlaYVY4oB/MorRmaNyIUCPBYKvmdCg1HJJnA6z9kcFuEy2+Bcb0H0JeQMlbUZK8KivhGoCbOw4ao+1HjGBB/BvBK2I1xV7EEU= Authentication-Results-Original: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Message-ID: <72ef1c9b-9712-4e08-8f92-3984de7df54d@arm.com> Date: Fri, 2 Oct 2026 15:57:54 +0100 User-Agent: Mozilla Thunderbird Cc: usama.anjum@arm.com, 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, Andrew Morton , 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 Subject: Re: [PATCH v3 5/9] mm: convert PTE table entry to pte To: "David Hildenbrand (Arm)" References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> <20260922-pte0-v3-5-5670b8cb9059@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: LO2P265CA0501.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::8) To VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3421:EE_|GV1PR08MB10856:EE_|ZR1PEPF0000E6B0:EE_|VI0PR08MB11501:EE_ X-MS-Office365-Filtering-Correlation-Id: 9de1d168-82ca-46bb-9fd9-08df2095a5fc 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|23010399003|1800799024|366016|11063799006|4143699003|10067099003|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info-Original: 0dhx1+S2wgcHNIZ4qGb6jCMd5Ad4vFWeOzSxNAuAiD0L95N8XDyuGx6rLwOXJL7u2B3bOGcN89zRKgMuyPe0q6si0B+kude0c+MDcBEnHlA/q073+A9lvG65InILmDoD1YcAqKXz95iVytxna3n1/AVgcSL///yDu/oDy/LD2A3/oeuYF3RLd+KcomCEIDOJ+U20NsbWQ38nb8/1FF5nSorWji1cdy76fj6UJHxl2HtLS5GuGbCZmCeiZ0IBTVXvP7t7613u8/cbaiSstnBCLA7cdi6E3oHaiueEllKmVyhwyqhgKCNR3JnZife+YMG/wgvj4CRGbbFWaSAfx8FF/LUa4BdGC+nlj/TwhYk7sL2ppHk+0kWDxZrB00TJIAqU8RXwj+XQD6LGoCVHyumk4NPvVsAvFFClaErEmd3KpYu9cCHUyiXEb0JCgcnUjE+yFrle3no3zw5uust6hdCiJR5vXYo+VRlN8gPOaFEuycTP9F43C7N129xCbhOnRZ9ffOnIqw0K8+azdr5GDhQ3nN0Gg8xgBlhGYfqgHWJvyox2eRpy8pO+Scq4qgPzsgWxQ0AciYsd47Q6mrpVrNwrScBMOCu1p275K37EQEsJUxo6XQST2AWF2YkEhteHB+GDgIPdIp1vEjJX9pvUNyirTQ== 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)(23010399003)(1800799024)(366016)(11063799006)(4143699003)(10067099003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-Exchange-RoutingPolicyChecked: 0/bqb1pcygz+orArl2yLvdFr2+CAcusy52mCrAntYx/z75bRz4YGBpeFBJL8hevynK/I35PHi6CiCOo37zbLgE/f/8sDnEada73834TrXRDGWJwPLh16iquDV58pf/xECOVta/qXB5sKLJ12//Iw7Ii4nna+UmtTsAOfm1kJOZWY6FlnPXNZG/LZcW+/ZQTChENDFBhvMyX8Tzm34fTJ2nYi78qbDfS1u+wzyt9EZmdN812OEhJwP3Ijvn9TXiIfZqheZvrMMxs3TlqyiMwWNlknrXvgZmCVyphpy5Ez84SDkEixbQuHGbg+RbATsUJx86/OPFCl60YmuyZuk/8KOQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB10856 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: ZR1PEPF0000E6B0.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 8e313be2-c88d-40c6-d962-08df20958cb9 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|35042699022|14060799003|23010399003|376014|7416014|82310400026|22082099003|18002099003|10067099003|56012099006|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: yVl1M4jNnGHFJkmLJcS9RYzE5SBcH0bc1tsVO99GTgm8SJGcX8jJbp8lyZpPj4rEhRtfy6ad9WLGH69HDj8Lt0AN3WdNz3tRyg3zxfxoOgm40auR8NIO59cgoqGGcTxKh6W7LYTaiZjB1s6x4bgcLhrAB6QZgtsjxg5nAbLl9P2vR1WSttretgKO93YBKrGg9lawSPhVo1pP+myujRSVOOZh0tvOMApvXGAQ/8a2T4IigB8tcwc6sBasqbEPjWlUnlCwUgOkhS7Ny15UnN+HEwMZM8eVYzax2hR5lP6kmQQIBrhhPCCYEJ/qZGQwJiEoLkXG117P3qN1oW1sgIxcUcimy8YMt+RC3KoIF88e+ZLICYjpuMYIO0EN+YnIbdmqbBnC8tlCT9B6xaLdR6atBHLcJKpsiSZC1meuLBU8nVlIekETyAC/+EiE+h+Tgg7B+4oQNWvntbg2hwRfBVoObyHJIPuFo7BBnUM2vomlo93t4DXeAmUSvGbCvga79rkPQW9m7k2i3F0Ixr5x/a/wYhqOoVHhO9TBySB37UnsONp78Xj7wnKgreJpi+FwTfiUGiu0LvMBlAvHOspXaR+GA31b/7rWpvskGToG/nhWtOmMRVCjWVEe+W3ToIHnR4tYBjjYK/3GJzVCrn5hUQbBzeqGl/reYDt46TffoR7ORnNoT7ynPzfebkZb4VWAm3Ex 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)(36860700016)(1800799024)(35042699022)(14060799003)(23010399003)(376014)(7416014)(82310400026)(22082099003)(18002099003)(10067099003)(56012099006)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4choth8Ewo2VDdr/aMZR1RmHIkPrJdtW4soA+TmIYNPe8QMhJpaETjcZXbUMT0o8uT5VLeA5A2vX0i+eQlCLeX1fZGy5YdpjYxTbKTtxFy2DCSSqe/RiCaf3KPaYYUAcAQ5Z9gl9eRoQ4E1vk+ISGUN6Umyz6GAIkpczPF74L20HzEZTTlD98i6BWKx6rIV/vVTEARoDaCHhd2YfsC2qzAIz3FXQuPpX7Jf9itiWKg2inLb8kDOE11ucrZTWlRjtTHuNoijofc7hrXlyoZvzLc6WNxcfOyqCy+ybRPgijzkA6zbYu6NPKMv4Rl8wq7Q++UaTyMzCDHJiQGbjlsDSijSLvFyPfkCbmaB50CDo0tzCvqEXXzY6IOoGPtB46WuE/PIv/R/5y/dy4joMav8HxmbF6ZidtAZGxlm/dOZO22mdYHrjBKssfpmOnBh2uU/M X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Oct 2026 14:58:41.5564 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9de1d168-82ca-46bb-9fd9-08df2095a5fc 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: ZR1PEPF0000E6B0.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB11501 X-purgate-ID: tlsNG-ebf023/1790953127-C38C1B50-FCB348F8/0/0 X-purgate-type: clean X-purgate-size: 2642 On 01/10/2026 12:17 pm, David Hildenbrand (Arm) wrote: > On 9/22/26 19:12, Muhammad Usama Anjum wrote: >> 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 >> } >> >> > > Okay, that looks quite odd. No NOMMU code should ever be calling this helper. I > can understand that some NOMMU code might, for some odd reason, end up including > hguetlb.h where we have !CONFIG_HUGETLB_PAGE. > > But let's see who actually calls huge_ptep_clear_flush(): > > arch/arm64/mm/hugetlbpage.c: only with CONFIG_HUGETLB_PAGE > mm/hugetlb.c: only with CONFIG_HUGETLB_PAGE > mm/rmap.c: only after checking folio_test_hugetlb(). > > I suspect we can simply do: > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > index 80a5a03e9cee..8642c863c1b7 100644 > --- a/include/linux/hugetlb.h > +++ b/include/linux/hugetlb.h > @@ -1268,15 +1268,8 @@ 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); > 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) > -{ > -#ifdef CONFIG_MMU > - return ptep_get(ptep); > -#else > - return *ptep; > -#endif > -} > +pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, unsigned long addr, > + pte_t *ptep); > > static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, > pte_t *ptep, pte_t pte, unsigned long sz) Thank you for digging into the code to sort this out. I'll confirm and update this patch in the next version. -- Thanks, Usama From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439333.1657679 (Exim 4.92) (envelope-from ) id 1xCgwr-0000OP-B8; Fri, 02 Oct 2026 17:21:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439333.1657679; Fri, 02 Oct 2026 17: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 1xCgwr-0000OI-82; Fri, 02 Oct 2026 17:21:29 +0000 Received: by outflank-mailman (input) for mailman id 1439333; Fri, 02 Oct 2026 17:21:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgwq-0000A3-7Z for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgwp-005hbq-Kl for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:27 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe80f-2eae-0a2a0a5409dd-0a2a4506ad7c-8 for ; Fri, 02 Oct 2026 19:21:27 +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 6abfe816-195a-0a2a45060019-aa0a817c9975-3 for ; Fri, 02 Oct 2026 19:21:27 +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-387-RsuvaWbCNU6Fy0yWVSacOQ-1; Fri, 02 Oct 2026 13:21:22 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5D97F1806D3D; Fri, 2 Oct 2026 17:21:21 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 91C321800576; Fri, 2 Oct 2026 17:21: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=1790961686; 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=e9nvmUr2zbUVTbvHTbhwfcDg5wbAhEW73Shs3YiPq8I=; b=dFrKbNlzEDiMa2jN/lHQbyvgwOv+rmLEiGGNRcKIY7/kob8o6s/nTYo9egg7+mwvOmbfTV jDvLL/n0A6oY1w+dFPpM3uYGiKmWkWoED2O7FVf1PAhK5Jci1CC7GR8wWYsBCy4jAxpAQz QPaLHd24InRVxWNJ7gnjiWMcYwfHeWg= X-MC-Unique: RsuvaWbCNU6Fy0yWVSacOQ-1 X-Mimecast-MFC-AGG-ID: RsuvaWbCNU6Fy0yWVSacOQ_1790961681 MIME-Version: 1.0 Subject: Re: [PATCH 03/28] hw: mark all virtio PCI devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-4-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-4-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166110.3025252.6768256984831473183.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=3371; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=GospWORxvPtPg6gnBQ7dvqsk9jcJVQRH3jLXkM10C5c=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBUwkiX50cyBdHiy6yEWHewc/R0CgJqBOM7 rnWyAd8pw2JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5QgFEACmrMfF16N8JIcF1CCPQH4SbV7IsoMLIKEYYTYkokijSr1WOk2XRGGRxsoc8S5e8iPXunM +kDqRcSYef2u4k0/yv/Nk2YPSDxYzOvDkXfO80/OFcbK4NG64GKsqYyTKNLBgeGLiGNNaull6Sv TWrBjTrice0kyAVB9yMsUNqXWphqvVqBJeK2x7Si0YLVolSt5yk4oay7Qgo4w94mTm9onRrf/5o 71tKe3RU+pF/CsiqdxwXfx7nNjAOQEhkFmKhFMv20/AmaYH3203J4DZhw0YquGilXgW4+JccPD6 E5rbwKdRXwqH4dYMvB19MSYn4MmhM2/rObmsRLClWQOwZArQ+SNDhw0rhCR1h2+X8B6HRRHEtoe jlTGaC7ZG/L+3xP4dozO4rJSCcg60xItlqpBotEZydHaXKXv+9JvhgDYsGNBh62t7XJcXu7T1vL X/6E0wAJWOC6dF77VNbc+0Y3vVqDZHoqxK9jovQQngVT8xFkKQYQC7SI245ndEfhrx8h/wT4rjY Tx+c6lbb8SLxcnv4LUYAI/Du9VUVh6oLF20+kqDucW6Quog7CsHu8Bw6eJgoUan4OLH7nocby2S GfiCSXNpC5utmgVKGmye8Qqi27E6A4Fs/7AGsbQcZqlng3CBylAClMtVGNdOZ7QQ9rozmQFnIyJ Ha9UE9XGAHZcJSA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: j_GwrVrERRdgyvmQ6Tq6KbxxJabQkp4d5ghx1dNePeM_1790961681 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790961687-F76C877B-520C6121/0/0 X-purgate-type: clean X-purgate-size: 3373 > 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é > Message-ID: <20260911143627.2743803-4-berrange@redhat.com> > > diff --git a/hw/display/virtio-gpu-pci-rutabaga.c b/hw/display/virtio-gpu-pci-rutabaga.c > index 4db77cb868db..a8e5e1d96cf3 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, This is unusual, I wonder why it's not using the VirtioPCIDeviceTypeInfo > .interfaces = (const InterfaceInfo[]) { > { INTERFACE_CONVENTIONAL_PCI_DEVICE }, > { }, > diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c > index 22659ca196b5..0b0d926a5b95 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, This is a base class, probably doesn't need marking. > }; > 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 6f5db5fc42b7..cd5fe8f1d8d8 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 otherwise lgtm -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439330.1657653 (Exim 4.92) (envelope-from ) id 1xCgwi-0008AI-LC; Fri, 02 Oct 2026 17:21:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439330.1657653; Fri, 02 Oct 2026 17:21: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 1xCgwi-0008AB-IG; Fri, 02 Oct 2026 17:21:20 +0000 Received: by outflank-mailman (input) for mailman id 1439330; Fri, 02 Oct 2026 17:21:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgwg-0008A4-IA for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgwf-00D6da-RC for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:17 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe7f6-8faa-0a2a0a5109dd-0a2a450aecbe-28 for ; Fri, 02 Oct 2026 19:21: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 6abfe80c-f2d2-0a2a450a0019-aa0a817ce721-3 for ; Fri, 02 Oct 2026 19:21:17 +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-653-FwYqFj8lNVWmLLoy_-Qt3Q-1; Fri, 02 Oct 2026 13:21: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 0287518001DE; Fri, 2 Oct 2026 17:21:11 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C3B0530000E4; Fri, 2 Oct 2026 17:21:09 +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=1790961675; 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=gGAIR2t0O5HHwmTRw018ra0wGrgXergyCbLtGIvnx7I=; b=OL3H64ZZxAB5jEbsTOMA4xmBn6lrRXOKWq98F/0UL3YwhAgUzj8mXqEsA04cM9YGeDErNd WYrrndSV9p1oH0J+gvObRiskVr9y6IW86YXMWRgek5Aw2K5MiJ5q6/1WCAaiQP6bd1nr9y EuMN6N0CY/TptcGoSX6LeBCf0+QDQoQ= X-MC-Unique: FwYqFj8lNVWmLLoy_-Qt3Q-1 X-Mimecast-MFC-AGG-ID: FwYqFj8lNVWmLLoy_-Qt3Q_1790961671 MIME-Version: 1.0 Subject: Re: [PATCH 00/28] Mark user creatable devices for secure for virt use case From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166106.3025252.1502698274281787496.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=2739; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=9UigYWA3AeEOar5r4FVoYgjPYIBd8nDgpAVGgELgbPo=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gAiYbf1ighCveAS/XFN5qtMN3YrSCDqiC+s 6AbYArhMrCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAAAKCRDa6OEJdZac 5YvMEACh2sblDWOQAqlgggCd2b3Jn0kRgQmpdiAdyYVe9wvGIOTXjEpfjT9WAnzjyMIqjIPHtAZ 1N5DsMRpp3kvG43h6/6ubd+LmIS757Z0suP4X65JhrX68IdZbdwJbjDoxU8BomKVJfPIw3Ds9sh V7vP3RAoADrSYbCScHR6Xqti95WU39oMtODx4HjAAzAgtV52T/8roaBZBo1uPFi4jzo6xXqiFVS wKr2XNSlNalbFFm0Tu7/qPjxtaVZwMffG/M8xT56Y7t5iMCG/dM9R/1Jzvq1dUQggpt0GEmKqDW J8FXDRvaUp6J3Z2IVzgnfBChRHxB6f+Sk0IdIMtgmTaaIWh9UVg+UKVu/G41YeBSk2GUW3mL4U6 2TlxgH/ETONGU/7ycNgk9kjlsMxvrdGzY1WZTPVaBjxg9TgZX62n8Y1UG9kWxUY/+Wkkwci105/ M+zm/+CB+RHLHf74lowv0zI6MNMFGZFD0FmJzVo391QT5Dnx9YjGCzXz6WK0H++EFBeGuU1JgfH C47WCAtv5SB1ikc3IJWXJqaGzVk6PhO/NU/JPFJIAKZhaQSSgLhO7b5G9f4wg47OC/IO0VjRZX4 TWI3ktLAc8BTqQXl8TXUX+gCJYHScdKaN0wBK1vQOj0hF/p0bVW+xhF0mugPWdzxdCk6ALBTeNu w7J4SdoqilNouGQ== 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: YuO2ZyCbmx-oz-YsYitAw03K36_nFwjmxg2ivXuqApU_1790961671 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790961677-585CBCFC-DD6554BE/0/0 X-purgate-type: clean X-purgate-size: 2741 Hi > 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. I don't see many maintainers against your proposal. I guess we can assume they agree? I think this will really help us deal with bug triaging and priorities, so I wish it would land already.. > 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. Right, and I also figured out while reviewing this that CLI -vga/-nic/-drive creation paths are not being checked yet. I can look at it if it helps -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439332.1657671 (Exim 4.92) (envelope-from ) id 1xCgwq-0000AC-4e; Fri, 02 Oct 2026 17:21:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439332.1657671; Fri, 02 Oct 2026 17:21: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 1xCgwq-0000A1-1A; Fri, 02 Oct 2026 17:21:28 +0000 Received: by outflank-mailman (input) for mailman id 1439332; Fri, 02 Oct 2026 17:21:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgwo-00009B-UH for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgwo-006d13-BK for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:26 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe7e7-e002-0a2a0a5209dd-0a2a450788fe-18 for ; Fri, 02 Oct 2026 19:21:26 +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 6abfe815-b4ea-0a2a45070019-aa0a857cb57b-3 for ; Fri, 02 Oct 2026 19:21:26 +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-196-az_NJf-kOyu3aex70inJ2A-1; Fri, 02 Oct 2026 13:21:19 -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 402651806D3D; Fri, 2 Oct 2026 17:21:18 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6A1BC180049F; Fri, 2 Oct 2026 17:21: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=1790961685; 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=oH+EjKBOvZNxaxHtrr0XaL3d72ADKzkKMiSpKNfR0uA=; b=OniEfsV61ynFSgAGsQeEIggieis39oA9y5UO5fbsuDGN98Lt1qSe0eaJF3xTbGG3GA/7hU ks0YOWIDgfNWWPmsZmuh8hyl2Vt8QCH40IBTJCXwMrHmGCJRd3OVzVF5IO/9c6DdrWXQbi f1fHZX0NoLTMxgdSI3oEVQGGRY+5Oj8= X-MC-Unique: az_NJf-kOyu3aex70inJ2A-1 X-Mimecast-MFC-AGG-ID: az_NJf-kOyu3aex70inJ2A_1790961678 MIME-Version: 1.0 Subject: Re: [PATCH 02/28] accel: mark kvm and xen accelerators as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-3-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-3-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166110.3025252.11073058761964969846.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=525; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=yz+AxESUJKfoqLf9T6OMvfiNfNPqI2ffYywuPWoFITA=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBL/4DdV1bzfqvy1Lc0bKI3IgDZ3n1OxYVe PnKzvMU5pmJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5ST0EACA7qPlq4uLz4A2t+3VSo1TE1nKGiHl2ypJyBuBXQbagr4O1+xM8ICqd5gXhNYVfUK+NPu P4qqWqZRCXyDlpawmpOYFOPHBCB7xi4fC1A07wdZXmxSqoJq3X3RYgjUGzBUECqBXhqCCzcb0iH oXPHxHF8LFkQmzEfHkuIzHaGDO3mEQou2chNp3BzCxmu9aNxNS7CeaTjdEQqu/CGKBhHBqFvbBs bq2cJmj5eaPEeBJiO1KdMRBnZ+YvceJPKyzxcYR6wsG+PAeyO+VFfdLPNO9AtxTdgmHHKS2/spH h3kQyh3BPPGQjjGJoOfgTWlBY8v2ehj7ONk5dKnqb6xLprMYoQdadWVL1hZhGbp4xctsHlHU3ar ykhAslxBt0HDv32FzisCsNNrgHuWnoOSaGYhmzYo7cqDoIFtuWwnWghugfFRWPe2RE4NN8KR1jZ 5+5/Tj7NvAeTdGypid/9pN9Zmsgahyvi21TJYVaUVkhsXf5RCliwYJ1ptLKYKvBuo8VUSR5w7Ag yvx2rfKlDXAx5NpfOhMfedwS9Cn6SCRzkS9bzeAraPlA7mt7jDLkxHd+DoRVkzVpHOOJ0d2PBSr 56KQeH/2ltCikTn2GhfE/4fQCYd9qMcAjC3F+I7iUnxxjTCUVAGKMI2xd31P85YrE+iLwD40qZc BK7SswdL2a3g+PQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: lnbF-DEw_NfpVHk4bXV87DaqU62TMsURRMnpSagUcj4_1790961678 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790961686-34CCFAE4-EFEC620C/0/0 X-purgate-type: clean X-purgate-size: 527 On Fri, 11 Sep 2026 15:36:01 +0100, Daniel P. Berrangé wrote: > 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. > > [...] Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439331.1657662 (Exim 4.92) (envelope-from ) id 1xCgwl-0008Mt-Qt; Fri, 02 Oct 2026 17:21:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439331.1657662; Fri, 02 Oct 2026 17:21: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 1xCgwl-0008Mm-OE; Fri, 02 Oct 2026 17:21:23 +0000 Received: by outflank-mailman (input) for mailman id 1439331; Fri, 02 Oct 2026 17:21:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgwk-0008MW-KD for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgwk-00D6da-0v for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:22 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe7f6-8faa-0a2a0a5109dd-0a2a450aecbe-34 for ; Fri, 02 Oct 2026 19:21:21 +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 6abfe810-f2d2-0a2a450a0019-aa0a817ce257-3 for ; Fri, 02 Oct 2026 19:21:21 +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-673-6G5WWYj4Pwavoq5nivgnag-1; Fri, 02 Oct 2026 13:21:16 -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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A11E118005AA; Fri, 2 Oct 2026 17:21:14 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6C8A31800581; Fri, 2 Oct 2026 17:21: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=1790961680; 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=jrylDJpuZsoIFUUXahyTqE70K91jDraMOMDJ9U5h74g=; b=Qqq6sv3Op1iB+6c+xc/LFPErDps9mnoc1PI9qq40HksTB9g/hf+2Z79cz8708t0AC8+dAR VrV0JFrs7LljkOo054+ccilUEUpMengq9L/M9PD+xHPZQE0/1b0v04bhZFxxRSMxoUoSfR eGr0OZUY+8cLCUsjz397DdAe+YUYg/Y= X-MC-Unique: 6G5WWYj4Pwavoq5nivgnag-1 X-Mimecast-MFC-AGG-ID: 6G5WWYj4Pwavoq5nivgnag_1790961674 MIME-Version: 1.0 Subject: Re: [PATCH 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-2-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-2-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166108.3025252.9718549338852340036.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=597; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=ca+dBKOXV8eblTF1UKIxDCLCnqb1+6+PKPCp8E4obQ4=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBgNVED7Ge4a3FZfVyeJ38C0I9ULQ5WCY2b YIjlAH9jsSJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5bd4EAC2ao/4YK3V1u4GjHkazn/6ZsYoSxnIEqPJWp1T7/d2J5MPCGyBHlyIaBQnTyWumHZzE4e YuaketbXl3iETQW0apS2w87kTX1duwp1IVO8IwY+Swe4svc833Za0oQnKfYUO267Y8xZQp/9BpU 8hF37E8FJ+kqiRSBtO2+b6hb5keM9sFGZjDiwBth4dA/95vEw6PsjVKH5bxRoh0/FXeIe66nfZv lr2WChCZVhwaV2BgsIvIHvKrGrQMGgAseXPd1ps2X/OGBsIvAaFoXQ1Svi6mBVDCxWCb+tdFPGv 13+65LJDDOy8/2ZrMOsKnb3YkGocX+wp7L06YuJMb6tU6Md2Ok48cOMeDyFBJTxSboYWoQfMtCZ 1DSLqzx858E+YAtEZ7tSRPBOWOmijAhPrZBP0l11ayLXOH/LAVcSirS+xqVJEf9gUSTWRWl5ZR5 ZzexT/7u+r1yWJAfUPygKAbuTRuntENaYWEwbud23gQKW8LxpVXZcf0xgPhBpteXMkfJBj++VvW KdbGkEumADdwxp/9/LWlUg+Ei1eEb1IAjO+nEpMhcodOBB7Q3dc8X/e6NnpCIKkR8RzG5tgsiEQ AqL0XjQchX2rYKoGYCEF440qzS4CcM3DkY+PBBTDf0bbrV2YI77tpmeSrooACeiRuGCHPKqGH2m L226vTermADFMvA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: SFPwkmTljoqSd7Jn0M-Smb9k11dqULQfceAZJmxF6Lw_1790961674 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790961681-4B8D5CFC-B5442D01/0/0 X-purgate-type: clean X-purgate-size: 599 On Fri, 11 Sep 2026 15:36:00 +0100, Daniel P. Berrangé wrote: > 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. > > [...] Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439335.1657690 (Exim 4.92) (envelope-from ) id 1xCgwv-0000fs-Ky; Fri, 02 Oct 2026 17:21:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439335.1657690; Fri, 02 Oct 2026 17: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 1xCgwv-0000fd-Ff; Fri, 02 Oct 2026 17:21:33 +0000 Received: by outflank-mailman (input) for mailman id 1439335; Fri, 02 Oct 2026 17:21:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgwt-0000dO-M9 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgwt-00D6da-34 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:31 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe7f6-8faa-0a2a0a5109dd-0a2a450aecbe-42 for ; Fri, 02 Oct 2026 19:21:30 +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 6abfe819-f2d2-0a2a450a0019-aa0a817c9ecf-3 for ; Fri, 02 Oct 2026 19:21:30 +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-479-fWtsDnO_NtCHrdxiJGM9zQ-1; Fri, 02 Oct 2026 13:21: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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CF881180214A; Fri, 2 Oct 2026 17:21:24 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0EBE730000E4; Fri, 2 Oct 2026 17:21:23 +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=1790961689; 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=l9atV6F91Np3AJSP8EvR9BlLmhXqze/BVTWs/nALyZU=; b=c4gMq0K68zqPsWljQdnSONnrhN4yII1eqRzEDJeQE9sgN9CZ1LBhPWJXFccfnl1YqfaNWy lOBeiXdc9KLgrlXo04RJOmrMPF8uQ4i0HoRGTycqIfwwrdM2mOPKY4i186EXt3Yws66Xoq MnVwBnMPuLVw69BS3Z0HlJn2RFerL3s= X-MC-Unique: fWtsDnO_NtCHrdxiJGM9zQ-1 X-Mimecast-MFC-AGG-ID: fWtsDnO_NtCHrdxiJGM9zQ_1790961685 MIME-Version: 1.0 Subject: Re: [PATCH 04/28] hw: mark all virtio CCW devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-5-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-5-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166111.3025252.12203965466791871761.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=309; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=PSekII06o7zCWPWy2CIE3EZ+vXhRl/0UxFggYHWlhX4=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gB2ziSadzcbnREqwHWphh15NhfRLxCk9+vE SuLWNZ0Mf6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5Ve0EACSyl/3CG+IloIAgLWy3FSQZfjdogFSHHxqk8man2cyhdeL096tEALwnJzEnLKE5qo3Kbs zPuaLS3sr7Y/T7ucAtlrcy9a4wBH8NIUQvCx/Hb+MeO8dfUMkmcGNHPkiULa0oPpZH5OcrQ9TB2 7PkzrFpE1aaR0fyMPVxHkjuRZMi3OOAOegVRWUYhxXSLN4/HuIxb3s5A9qcv3fHKMaYmJJzhKfb BbGt66SR9vP15051I0Jli+FVqrqdC6BC/ikUvdVWWHDg7rXcsYm6P5UeiKn0vfoHYyTIEZDlhOz gF87qL2Bg1V2xkWIaQL5fPgH+qS+k+WPrN5MKA2JbUQrQ0WKF96DpjBDm1Vnf3TsJ920a3hKqM1 28wsvdlc7HCCtpU1Vyy6TFQ3o8jGdYpv6fWX7CuJeh8AkyN658Nk7qvhaJpxPw8j4+DSgX/OxGO qhFj5usmW3RnsRl/wire5q7CUpb7EQh+ZOWvEMAooWGoZeAc10WddMrI6yKH6J6tQPvUvagYR3Y cV46JF9vWI6eC17Hxl5EjlusaiIOHPYhrA7nW7mPjfWeZ2Rz8/ZjYJzM4BDTRets7skDfN5fjQN RjPTmxeF1jexsrBb26XNA1rnR8SjXOTM9rzMk9oRicwRbuXQLMLbjN8VzWtrJHa4c/xo4nHSxaA xMDuq2tMdOy6tfQ== 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: zmuRWTYL2VI51iJvNcL9PcT4p5WDTNId-zzIoq5Raio_1790961685 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790961690-50CCBCFC-89BA5502/0/0 X-purgate-type: clean X-purgate-size: 311 On Fri, 11 Sep 2026 15:36:03 +0100, Daniel P. Berrangé wrote: > These are all intended for use in a virtualization scenario and must > provide a security boundary. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439336.1657698 (Exim 4.92) (envelope-from ) id 1xCgwx-0000xF-Rr; Fri, 02 Oct 2026 17:21:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439336.1657698; Fri, 02 Oct 2026 17: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 1xCgwx-0000x1-O2; Fri, 02 Oct 2026 17:21:35 +0000 Received: by outflank-mailman (input) for mailman id 1439336; Fri, 02 Oct 2026 17:21:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgww-0000r8-Kb for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgww-006d54-1W for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:34 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe804-bab6-0a2a0a5309dd-0a2a4504dac6-42 for ; Fri, 02 Oct 2026 19:21:34 +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 6abfe81c-b57f-0a2a45040019-aa0a817cd86f-3 for ; Fri, 02 Oct 2026 19:21:33 +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-283-3tjG17T4MX2N__8DFzBoiQ-1; Fri, 02 Oct 2026 13:21:29 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id ED7A919560B9; Fri, 2 Oct 2026 17:21:27 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2D3031956086; Fri, 2 Oct 2026 17:21: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=1790961692; 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=aoXXZDLvNvgKaFqa8YpP9dQLUt2vapGLok6gxunIT68=; b=Yz/TDqFIEfhHovOEkVradoNKy/YSBjSuFF/xI4GNlkZxQpZs9pEImN7TncWVz2+n7O5Ojl lJNuzHbLAXYrn/j2GSeLkYf5WGY6cutWF80Nbyj2CgCrrOSNukJhFAsAJRudLbMii5Uxyg RYDTkMFFuu3+Up1+QjTH0XziXi6ZYpA= X-MC-Unique: 3tjG17T4MX2N__8DFzBoiQ-1 X-Mimecast-MFC-AGG-ID: 3tjG17T4MX2N__8DFzBoiQ_1790961688 MIME-Version: 1.0 Subject: Re: [PATCH 05/28] hw: mark all vhost devices a secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-6-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-6-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166113.3025252.10241920330836566113.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=309; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=36U2hwFalyBi2NiZOYsSioy4ZmS63nVhD5J9V8lUoug=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gB7tWh3txU4HBTMWIxNhGppWUHsWS45EzUN tUvdmqOz4CJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5SRKD/99P4YvNE9rpA4OcfaRex2f2wHKtECYpahgvxE9Pbxa/ag+IBOa63cJTnft2kdhu9JR51T nSTYsFlPBUK3dP3jU6UNr3T4bWIZaqXwzRqhGBxDxN4QqIBQzOgw6RauS7F6FaWBpezk/5nsIF5 yKsrBd4zavLJVVJKf4MoFn+EvfWZS0wvTD1Y81s9azDWrbi/jB+Vy82ofVLSMXa6/Jmktsi7qyO GHUlYnJVq9PFr1iGD9MDfL+q6YwBNYtdbUkcRACeaoP7+y0ZcuTsP3Ye+FX5twjpoDPCBobzSDV 8QK8xdsZA0n8D+8a4jcOu/mf5g7dHc15xpYKT6ncXiAGYVvveEsAjbTkV9K99iVYFqp7qOdUwvA 1qen7dnFn2pTgmrXwHvMp4/LACNoQAGVeYRmjD1+rgDj8aHypR9GGkswCXrifEEFhJKcEovtQfU VdXd+9a3SCaeGmTHESrCBPeO4JEEXCaTrxENMS94ksUxf+6D4iBhHECK2eVWRD4wJv/U3NmlKtY 0O3rO970BxTef4C+m6tAMEziyPiAeoE2BgMxJyeBHseZKjNYUcuJEhwqvco2/X0G9iBfpfjjHcP +CjLkIlsulVIQ5Yg09LPPSPMHaltomlpYAv+jIrI3w/iPmze51jcDHX/phR4MdnFv6biAUi2iPT PT1/NZ/4TddhPew== 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: RUHGNbJXPXblFrDWYkL47JfOky1i_oF2fiE5rY2Q65w_1790961688 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790961693-C06DAB50-2DC6FE4C/0/0 X-purgate-type: clean X-purgate-size: 311 On Fri, 11 Sep 2026 15:36:04 +0100, Daniel P. Berrangé wrote: > These are all intended for use in a virtualization scenario and must > provide a security boundary. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439339.1657707 (Exim 4.92) (envelope-from ) id 1xCgx2-0001MT-2y; Fri, 02 Oct 2026 17:21:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439339.1657707; Fri, 02 Oct 2026 17:21: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 1xCgx1-0001MJ-Ua; Fri, 02 Oct 2026 17:21:39 +0000 Received: by outflank-mailman (input) for mailman id 1439339; Fri, 02 Oct 2026 17:21:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgx0-0001Dr-1P for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgwz-006d9A-Ef for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:37 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe821-e002-0a2a0a5209dd-0a2a4504c23a-0 for ; Fri, 02 Oct 2026 19:21:37 +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 6abfe81f-b57f-0a2a45040019-aa0a817cb82f-3 for ; Fri, 02 Oct 2026 19:21:37 +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-401-6sk8FPqCPEWpIN_3l9tEDQ-1; Fri, 02 Oct 2026 13:21:32 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 70F1A197838F; Fri, 2 Oct 2026 17:21:31 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A3AFA1956086; Fri, 2 Oct 2026 17:21: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=1790961695; 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=DQzmbhzGyk0iOML82lQWr2IfcBKcOLgEId1IHR9dGqw=; b=KU/DD20dxXYKGoWZ/YS5G9bdThPGXW1KC2ID+nCzm7ga+L6wu2pxqNI05ro2cGA9MmM30e Tdb3jbmTlg8nuKzRppg7kT+HjSnX8MVjEm93CvzsQ6X3d8Dvy4pRblPZ/jjdOv7PX3ek2E 1UJoUNtIhdGqLE1viuZbLhBfGMHrk40= X-MC-Unique: 6sk8FPqCPEWpIN_3l9tEDQ-1 X-Mimecast-MFC-AGG-ID: 6sk8FPqCPEWpIN_3l9tEDQ_1790961691 MIME-Version: 1.0 Subject: Re: [PATCH 06/28] hw: mark all remaining virtio object types as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-7-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-7-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166114.3025252.16977253754744941880.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=309; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=sxCkKp/ZMUyqes3eitE1tZzksOwuJ5PON2jVXe0dusE=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBjW/Atw0+zWBXIkienYKY3LmqFlBm9Dx8y dyfJ48xnZuJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5S9tD/sEWlPdG00zqA/z/61RRB3Sn1bjGpyDXIwPxKPbcvpU/kaWDhYR81SloAp2WBOiV0PYMmS xavQ10ku81T00U7EmG3WIZO3T1tBMxOFrpvhUE2fhWQ0pRmMreNX8/ujG4SQfs22Sk+UHXNBt/Z hMQgXljQ+GeMJ9L1NDKnw2a4uRtB08Mt2Q6tPztTvQQYh2/dqDiF9jVnmgYSBTTBENtQ2sFFWSO 7MbQVI3zdMXPqy62Hg/h6X9U2Lt2zHSpO/TYy9EcEQB8bE8z8otFED4VljZkNHaNBeZ5sa8Xysd sTYPYvM5pLDlxVL8HmxUQqD6/eHm8AJ86K0iSZkc0y0BkGEHijkBNGkiRRT6bQFMRQTN1n7NEy8 If7oWMNI3jfoTSFmsv8bfDWcLdZxKGp5Sd1RL8z6dSByd8/ljY36coZ/QdFEPvVK0nahj+Zglsk 4gvdRXS1WTDw+fGXrhxfmG1btfoyDaAGcPDR2A9eNy29AYTbzfCor+sc3/uE43peUhqdxWlfL51 gPlZ/OjNoEU99NhbeF2L5nP6mQPjFj7H055zgFfb+xxeyNIafKLXweW60MlOR/Lqe/fZJFE17DY VhwqhppvR2yv64Cd91I2St6IQ18UEZDAOhzWS6lmHigsMOoDVsm5w7PkxtHvd+H7Ga9lYUIscFz ULpbpv9yzMo80GA== 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: 3gaZ4kG36vge-8wXDiME_a_oWCNs6WwXpo14ibzghKk_1790961691 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790961697-C28C9B50-36D96DF0/0/0 X-purgate-type: clean X-purgate-size: 311 On Fri, 11 Sep 2026 15:36:05 +0100, Daniel P. Berrangé wrote: > These are all intended for use in a virtualization scenario and must > provide a security boundary. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439342.1657716 (Exim 4.92) (envelope-from ) id 1xCgx4-0001fW-HA; Fri, 02 Oct 2026 17:21:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439342.1657716; Fri, 02 Oct 2026 17:21: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 1xCgx4-0001fO-Cr; Fri, 02 Oct 2026 17:21:42 +0000 Received: by outflank-mailman (input) for mailman id 1439342; Fri, 02 Oct 2026 17:21:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgx3-0001bB-AQ for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgx2-005hbq-NT for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:40 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe803-2eae-0a2a0a5409dd-0a2a4501875e-22 for ; Fri, 02 Oct 2026 19:21:40 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfe823-5984-0a2a45010019-aa0a857ca1bb-3 for ; Fri, 02 Oct 2026 19:21:40 +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-484-c9FSi01UO8OHIvlJX4rXGw-1; Fri, 02 Oct 2026 13:21:36 -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 C47871806D3D; Fri, 2 Oct 2026 17:21:34 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DE74E180056E; Fri, 2 Oct 2026 17:21: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=1790961699; 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=kKANUuPqXGdyJ1zgQ9RAlHchse6y4uMbZE/AFJwSoN0=; b=jWeTdBeP9xyZNP8+SDvGe+ZkTpfcCyXTOL+fZ3SwE0lKzscTzFbREOKjLbm4JmGbo6OfyI dhqyw+90WXGojq4kWDqjQDQKjGZvvVKlR3oQOlO0PXmiwl84odDzTmq9qk06tJXrtxeP1t CXFFSq4fpmoUyLTblDXGPqg+R+8GR1w= X-MC-Unique: c9FSi01UO8OHIvlJX4rXGw-1 X-Mimecast-MFC-AGG-ID: c9FSi01UO8OHIvlJX4rXGw_1790961694 MIME-Version: 1.0 Subject: Re: [PATCH 07/28] hw/vfio: mark all VFIO object classes as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-8-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-8-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166115.3025252.14588124024101266556.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=362; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=F52lk1x+TAHOSo9Af3NnIftRKijvVx1MgwN5APgv7h8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBTrvDpLkiA+l6PqvvMZvyr1QT25Ecvxflc 3hAoLc93A2JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5Z1SEACY83RJqp+DMc6RoQSvuqwl1D94oUskXQZsLAuoDF/VCxS2hLN7Y0m3b1V2F8ada7Zk2gd czQwpvGFz3kCAUdr32GT7LktXmDRIwYuh92KdMUxdgd4G2mBRuaVAHGkw/xbwJyk461eFd7Df0t WnxbPJmkoTTnE4TbF2In3/rWYGfge1YoTo4NFfcQ+yLD4Crtlj4/O9QAwGdaJwqzzrskFGMRW2g riY1YEYm/1xFJ5Fzav1WIfGd5kzR4EfbrzVGBBRMS7Y9evvohGgaptm+shqPeQibnA13/4jPIdV 6pNpioOWX86xir7RI6dpNXob9Ejq7UMegoz48DWRYllZt4nMVUA/PTgCT60ZseZ7rcBYkY8wTpT 4BXPSbHkl6XrgMVlEOAWUWDzydzs9wrwO3A25y5vScjlhpCDoS5/DT1gNVKq6On6EDd5UACkfnx 7jLUAYtIgw1gtuqUGeXxplI6pt6slh56J3dOWVf7qy2376USQII8Nn1aFBNIfz8cmbnrLa9jwUa YPgUvybZLiUnQbqV0BUWeSQM4ruP4XVQLn7rXOts1/bEDkNQSn5ruu9aofpPJs5w/70Momw6cfK 6ce6hJyoQ4eWV0P6RRLVEyOTBvKN+IXKuq0shkosKtsWW+X6VeDReYEifA1oxiqRuQRICGstVGC wjHpvCrPaMu6wlA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: 57buNmmLhxqbei48E-wx35-fz4_5zsjuGaDyDPZn05s_1790961694 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790961700-BCF47757-755E5E23/0/0 X-purgate-type: clean X-purgate-size: 364 On Fri, 11 Sep 2026 15:36:06 +0100, Daniel P. Berrangé wrote: > 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. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439345.1657726 (Exim 4.92) (envelope-from ) id 1xCgx8-00020b-Qi; Fri, 02 Oct 2026 17:21:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439345.1657726; Fri, 02 Oct 2026 17: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 1xCgx8-00020Q-MO; Fri, 02 Oct 2026 17:21:46 +0000 Received: by outflank-mailman (input) for mailman id 1439345; Fri, 02 Oct 2026 17:21:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgx7-0001ww-65 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgx6-006d54-I2 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:44 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe7f3-bab6-0a2a0a5309dd-0a2a4508aee6-46 for ; Fri, 02 Oct 2026 19:21:44 +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 6abfe827-f659-0a2a45080019-aa0a817ca7f1-3 for ; Fri, 02 Oct 2026 19:21:44 +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-453-zFRBNzENMlSchus4DwaXww-1; Fri, 02 Oct 2026 13:21:39 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 511EC1809CAD; Fri, 2 Oct 2026 17:21:38 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7A772195604B; Fri, 2 Oct 2026 17:21: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=1790961702; 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=gECulURY/oZLI9VNqz+HsEt2goE7of/WCgXwCZCLckM=; b=h44U1fig+5ZZBe4Pb5Xn+WGfpd/dhEGKYUTvQs85Gna9P2P6m7ze8dzMhVrorFF6uOY7oA Yn82sHGKJJ3kxWzEVa1Sut+mQWQtcysoUtb2R66y7u9QA6A5slhZhoIXLaZJ9UDIFoz8Sc ThwfDrOnn/Lk/6/OCxyjYjE6vIP5e9s= X-MC-Unique: zFRBNzENMlSchus4DwaXww-1 X-Mimecast-MFC-AGG-ID: zFRBNzENMlSchus4DwaXww_1790961698 MIME-Version: 1.0 Subject: Re: [PATCH 08/28] hw/xen: mark all Xen related object types as being secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-9-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-9-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166116.3025252.12679898543529528318.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=339; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=7Vh5I2mhOnROAfcJUHuBXxYpyiWOJEXNCmbxX6t9bCY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBlYEWUugjEw6F6RwUrtgnjToRRUxqe8oo2 Q/lqXVuxcWJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5TSxEACo+euuTcDsNdOhlOuR3cJnM5my1i4aCmSDh7lQJC/ynM5fFU9cvMkrJYZXwuxJotzfTGn j6F/MeecnSWsV5TEDRogTUiiaEzjz0tqrslPESywfke4fGNjoR0QqZxPw1p+7UutESlyLUnxqm6 oHuaSh2dkq+zlmbeTPlmrupj9aR5I28x7Ee9rE8AITrGi34FcmraSX9YpugU+aFTVunrMAPQ064 WRaxTzZlwl5qQExuKoHME+eAeP+6NX9BJYC494ELwsA2UXxwaCnrGCpsONM7S5pFXuZsBNrf0gi 3Yx+iOaZ0nKx3FkRCHujrIBmKYF4e2wE29QgI5TCmij8tH5utnBBtI9ZpLWnnXX8tLIMsR1Qv+D fxnS+3DaCMEGPduPx90ddj4tEwdnTnUIGlQHloSM4o9oj2ejOPlRr9/nxytuKazl1am8qXOYsQ6 ljDOvfH5oGRqTIOTbhA5Gq8AKTSw8P/sjM0YHpMplHCXPRJvx65KGW2w3sW80SDsOdxRkbdMbYZ tlWoiauNcXYZHw2KXghWw3xOIXatzxw4t/nUIdhSFdaTeeFp2lpo6O/dYu+Q1xcMcoNdyNVBGpV 3xAKjczkE4s+jhoQtxsfbeZ5dZk4RwLy86IuI5T/aGL6ZXJw28LkC9tkYYYl6/piLx8bzcC/IgP cDB1t40DWiIRptQ== 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-MFC-PROC-ID: k321QZ6BVn3rEvqrBV5sULFqeGWGKD7cd7yU_RGPOKM_1790961698 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790961704-D4B7187B-2CD2A28E/0/0 X-purgate-type: clean X-purgate-size: 341 On Fri, 11 Sep 2026 15:36:07 +0100, Daniel P. Berrangé wrote: > All Xen paravirtualized devices are intended to provide a host / > guest security barrier, so mark all Xen object types as scure. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439348.1657734 (Exim 4.92) (envelope-from ) id 1xCgxD-0002TW-2p; Fri, 02 Oct 2026 17:21:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439348.1657734; Fri, 02 Oct 2026 17:21: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 1xCgxC-0002TH-U8; Fri, 02 Oct 2026 17:21:50 +0000 Received: by outflank-mailman (input) for mailman id 1439348; Fri, 02 Oct 2026 17:21:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxB-0002LY-18 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxA-006d9A-EG for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:48 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe7f5-e002-0a2a0a5209dd-0a2a4502c86e-48 for ; Fri, 02 Oct 2026 19:21:48 +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 6abfe82b-6ca4-0a2a45020019-aa0a857c5ae5-3 for ; Fri, 02 Oct 2026 19:21:48 +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-552-y1zeXxcEMaePaVYyLaVHJg-1; Fri, 02 Oct 2026 13:21:43 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9080F1801354; Fri, 2 Oct 2026 17:21:41 +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 B9CF1433; Fri, 2 Oct 2026 17:21: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=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=1790961707; 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=9w4jIAPaUQybA3EsxmBsJb1p/fnbPpxufD6dm+ex3Jo=; b=NpEGgLbyAHJVroTOFAc1/Q8AFkTuTbC+h8vS7ZYbDS0dd8MC9KAs+baR/qf7NJJbjS2cM7 yY6c5Zzjlm5KZqu3Kn4Z7YA3nWvzRlTWHVIgE2d7Ghmi3bhExvLzPMnCArtu5zxMfOl3ci RJw/czHeJYQf3Qc8RrT3M7I68lSMdYc= X-MC-Unique: y1zeXxcEMaePaVYyLaVHJg-1 X-Mimecast-MFC-AGG-ID: y1zeXxcEMaePaVYyLaVHJg_1790961701 MIME-Version: 1.0 Subject: Re: [PATCH 09/28] hw/net: mark e1000, e1000e, IGB, rtl8139 & sPAPR VLAN as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-10-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-10-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166117.3025252.3399554700496925383.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=3195; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=+tdgjJRXFosxAEmGsg3dsoMhhj4DzUSDUOZcS2OqB2Y=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBMjIspCHTznfNZU7JF57wkV8PBkHXjvof1 p5wZaOADoWJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5WtfD/0Zj1WkqtuXuTJ8VTcQzQYbxbvIz9VU6P+lif52L+QHHdQ21YYM6Sy8FIrUBWUZco8vgDK GwEyfj1drJm3qZ8xlUa7VxVPXpkFQ1RcllwAykU0HVrC5MatPWUwU/ZxNIMf2jtux6fIYe7RQIq rkZTMkiztkzhBwXsDk8VnJzlfj6m4EwVJchW8Nd3dP8se1dzq9mfkz9cvSLSt+IfZOXxyadmXlc wak8ZD1CC3wEDs72d/7pBnQA7v7LD3nCRsyh5o1JKQz31ssNG1YKocOfEt7lKYv1TR5FGzTeZCQ oQ/9vH/WJVfB1aqDLL7RLAiuh7LuNhZJ5ANELS7kDQXHRpQPPGu6Xxv2GP5MR/oeV3c/WLSzmaa AuBMpBeUUzUar7Fta1LCk4unWf0aOIjsA2YSgh2NyDiDQodDH5cgAGNayQRgoBhA26pGXypUttf RwpbO9IfMp8a12IkbUYNsom156/YhTldVv2bTk70XIWgATx0H4654n/xWR5a2ZIx2LRmvej9qYV dchyuXHAxg1JeV3OuV2z3j7SyJoS+UOfMR9TQD1llwIs1wKsfnAix3TC+dPKLbQoJ6g7e7bbCHu ammVmErv9BT/w16BB1+sVuMWupFu/vDGJnFADgnXWXPVPOXdlVagcUO8K+xKEmtgh3VumGbSwAJ pMxuon8+bGqjDWQ== 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: uRU5KhNKurPQrKLbFv_VoJjiZ6GgmN6Lj_xG7wn6Adk_1790961701 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790961708-31BC82AC-D033AA52/0/0 X-purgate-type: clean X-purgate-size: 3197 > 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. Virtual > > Signed-off-by: Daniel P. Berrangé > Message-ID: <20260911143627.2743803-10-berrange@redhat.com> > > diff --git a/hw/net/e1000.c b/hw/net/e1000.c > index 202ad404013a..da0667c40ec0 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_info.secure = true; > > type_register_static(&type_info); > } > diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c > index 9faf0c74c3d4..96737ddb51ac 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 c076807e7110..0bd03efea0cd 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 16479284eea9..38bc16f312fb 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 550848307d16..c7ac58273c6f 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) Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439357.1657743 (Exim 4.92) (envelope-from ) id 1xCgxH-00033B-CS; Fri, 02 Oct 2026 17:21:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439357.1657743; Fri, 02 Oct 2026 17: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 1xCgxH-00032L-7q; Fri, 02 Oct 2026 17:21:55 +0000 Received: by outflank-mailman (input) for mailman id 1439357; Fri, 02 Oct 2026 17:21:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxG-0002xC-1O for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxF-006d9A-EV for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:53 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe831-e002-0a2a0a5209dd-0a2a450bbab2-0 for ; Fri, 02 Oct 2026 19:21:53 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfe830-b7e8-0a2a450b0019-aa0a817c4eb5-3 for ; Fri, 02 Oct 2026 19:21:53 +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-629-q6IY5ZZoOkKxB3WaFwfOkQ-1; Fri, 02 Oct 2026 13:21:46 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0CD171955F08; Fri, 2 Oct 2026 17:21:45 +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 416A6433; Fri, 2 Oct 2026 17:21: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=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=1790961711; 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=UB4QvQO4Fa/SavRC9wKbY5DEWv7c5j74YZ2riQQtR4A=; b=hNGfQBL/OiHzrEUyyuo/XE1Jsy/QvvgZvl6C7hXeyEQnYju8KcRlX/4c9j8XtXBkuFZAef JH8GdG634Gj3d5yBZ5NUG8285w7Mt0raobAdMZ7/yZCpVXwSjQkz84AgJt41AXZZWrCDhw Hrxne77iZg755EIaJWwxAyfJq9oS85o= X-MC-Unique: q6IY5ZZoOkKxB3WaFwfOkQ-1 X-Mimecast-MFC-AGG-ID: q6IY5ZZoOkKxB3WaFwfOkQ_1790961705 MIME-Version: 1.0 Subject: Re: [PATCH 10/28] hw/usb: mark commonly used USB devices/hosts as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-11-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-11-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166117.3025252.2297105460212965387.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=549; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=NumlpaDMemOKFITCo+2qMeic3H03s2RpTFl/9eImaGw=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBYFDletPJUFlFEMVyQfAv+JKnuN9ifwXme 8M4uuhy76aJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5UapD/0QcDniEQk9YvFzuhhhLF7o4WA4mDmjNvWEkEvP65tXbCx2nKGLYLYo0sGBlM6ijnFXZzq 5ClvORJ50fSj/5pYrZ70jUS4LLdSm8qbtLPTXtFgKVwRni0wMUan0NPFoYeETk3hG1NgL0kEZ4H Ytx4SZ5aEYH7zMDCLebotk63cqvDdipqtFo+qjhNvvU6yXAa4DubFOxERVjA3WmMcCm0mUtVk1p Romcn3bHXBsH4fzvlEKRsl1trmASogHppILSaXTzZsB1Bo7UDHJTNpWopuwP+QNsr/168gPqS3p Q/JSPE0aFD18nkBGsrYp3/3L20ckc7feRz0r/qUeyD23wT1759WcGT2Ol1S7iV3pdDUGVTwWV3G 4HkVfHe5GGck+U1FDMg0KONlmmfiZBK/fpQPSN0yg5fWEtPpcr7VI9QRclU/D07SI8jzWfgyYUo KkXRhz5A8Jy3qFAB0XPzWx4EpMg0/3yaAjDzCroLTnkoz3zRcyPLIgCXDnvUxWOFCVPQdNdVC+G z7FEEWW9/KZpRLa6ICR+kEKTNI6EfhIk0pr8EhC8KT34W5PYCBku0qdh+mZSSNU+sWIdwbpPDlZ 2BMLjeozufvANd0M7tdDWIOVEjUuAtb2A5V0gDvh/5HAx1JOPB1mpp5hawjsv8SHJTHDVNdkf7K uw5oq/h3PnAaCTg== 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: ObQsjfMTyJORNX-izUi0RHLNd42N0N12OadhnTO_9QE_1790961705 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790961713-182F49EA-382B944E/0/0 X-purgate-type: clean X-purgate-size: 551 > 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. Can't we exclude uhci/ehci nowadays? -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:21:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:21:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439358.1657746 (Exim 4.92) (envelope-from ) id 1xCgxH-00036y-Ny; Fri, 02 Oct 2026 17:21:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439358.1657746; Fri, 02 Oct 2026 17: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 1xCgxH-00036k-Im; Fri, 02 Oct 2026 17:21:55 +0000 Received: by outflank-mailman (input) for mailman id 1439358; Fri, 02 Oct 2026 17:21:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxG-0002zS-Ld for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:21:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxG-005hbq-2T for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:21:54 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe82b-2eae-0a2a0a5409dd-0a2a45089242-2 for ; Fri, 02 Oct 2026 19:21:54 +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 6abfe830-f659-0a2a45080019-aa0a817c9377-3 for ; Fri, 02 Oct 2026 19:21:53 +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-449-z4Du8iPnOfuwp-zbMAcwmQ-1; Fri, 02 Oct 2026 13:21:49 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3F6211955E90; Fri, 2 Oct 2026 17:21:48 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7389E1800351; Fri, 2 Oct 2026 17:21: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=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=1790961712; 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=Hue97jH25PL9Fu7HwzO2FuDAiS35DDowtfLLJwWj3E4=; b=cVU3FJlWcetouO4P7f8A8X7fZeB6chQL0Hhae63hGAKG1vlOy+UtsDJ07JRMsiOKhiSy1i ezpBB9xxc9W0ftjmY5AQ0+JYsc4v9r7EkMJY4U0Dj6+nUY2Ln0rnpA8KlD8i/OJYK3S96L 9Vyyyvnttkd+sERVg56oFt1U+ClFbdM= X-MC-Unique: z4Du8iPnOfuwp-zbMAcwmQ-1 X-Mimecast-MFC-AGG-ID: z4Du8iPnOfuwp-zbMAcwmQ_1790961708 MIME-Version: 1.0 Subject: Re: [PATCH 11/28] hw/watchdog: mark some watchdog devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-12-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-12-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166119.3025252.2496453573519063960.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=492; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=KNbJ1woWSzxxfZwd7GZw+aqcvsmuZGYhsDdISMTGzjI=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBvrET4+5dsYi7lFkC//cHNBhosHJu0lBRN ggAr3rPqauJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5UPFD/sH9PB9QicrrlwiihP8UOYHRt3rotgC4OeBD8agVZ/Tx5Bv3TEeH8R0sTWKWsdSpMvl9ZP y3p18Xwk0PXnMVCnQ91gD7Jf10O0m8R5RwHtWwaGalfpk/HIneYBEUPAHt1UKrtMZaixmMrvler tYU7qNeKNDlEv0G0y/gMt6/7g/gWtBz9O4QUtT7vyHy0lGSaI8FcFujlxsGdefqNTNh1kr4jiiy 6SXRdbKcFdjbeZxGaJglhoBimunIpbXzc8vCj03r8GMNuKVRyEbCF9jCljJFvK6qWdgXKDopGoR JE6IHrDlwhY0ADqZPvphJsylKUiff9ZLflN19GYC9fAKgma32ADNeY8dKX/1t42OV1ZevIzajF/ M0VL3YJWuvMKvXJwOlM6Rc489O64fXuANNgAlec/WFDz1jfEjZTbFGHuPpwpraEFqXZ5u90NORo M1nAYRpJtdK2pfU++QvAj6qNSkXjLZt4TLrkQN+qQXuT84krTr1TqrlqRC3Bsg7TD77Avy9d34n fYRpYDLlr4p3ngtqwK6JNrh4FcbSs99KDHwM2A7M+SdQYaW4XVBaa9g1rVfdf39/a298zFKpmh7 ZQXh17l4KZ7SUCRfJoXSlDz7JIqYGpYW2B6mtOgbNUIREoHz6ertwswBq9hL4uvOZyi7Nat7Ls8 6+c/7s2ywX8vPrA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: E89eLAe0hGV37I79P1L8wUdZ2Qh4pYTe7ZeHog1r1YA_1790961708 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790961714-D554C87B-DF82359B/0/0 X-purgate-type: clean X-purgate-size: 494 On Fri, 11 Sep 2026 15:36:10 +0100, Daniel P. Berrangé wrote: > 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. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439371.1657762 (Exim 4.92) (envelope-from ) id 1xCgxU-0004Im-Ay; Fri, 02 Oct 2026 17:22:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439371.1657762; Fri, 02 Oct 2026 17:22: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 1xCgxU-0004IV-6G; Fri, 02 Oct 2026 17:22:08 +0000 Received: by outflank-mailman (input) for mailman id 1439371; Fri, 02 Oct 2026 17:22:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxS-0004AR-2k for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxR-00D6hg-Fe for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:05 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe823-8faa-0a2a0a5109dd-0a2a450a9dfe-32 for ; Fri, 02 Oct 2026 19:22:05 +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 6abfe83c-f2d2-0a2a450a0019-aa0a817c8225-3 for ; Fri, 02 Oct 2026 19:22:05 +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-483-EaRmABzaMOWtSEBiUtjpPQ-1; Fri, 02 Oct 2026 13:21:59 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3CD8C1955F11; Fri, 2 Oct 2026 17:21:58 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6CF991800351; Fri, 2 Oct 2026 17:21: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=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=1790961723; 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=J/uj6QtTGbG8wlVOQwgZObmAkOhqUVZBsFUfwWSlAvg=; b=SFL2MLqZHAXbwmUwpW8J9Ru9W5QvgOq29iDq9UFlSHyUnc2+sUAJKQEfYt5x8EYfESo6EG AIsqPQu6F3KSlMI/bFq12xEe4ZEMKNHoNNQhL8zNVvfirTyorSBz6glivWOmeC65iHxY4/ 4vDw9g0DvdzKDP2nvfyq7aUqiYf8VgA= X-MC-Unique: EaRmABzaMOWtSEBiUtjpPQ-1 X-Mimecast-MFC-AGG-ID: EaRmABzaMOWtSEBiUtjpPQ_1790961718 MIME-Version: 1.0 Subject: Re: [PATCH 14/28] hw/ide: mark ICH9 and ide-hd/ide-cd as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-15-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-15-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166122.3025252.10335557019299370237.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=374; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=kUpbm6Ni0vdDYzpLnvqSHByQqKV0BEAQE3Hpa670dzw=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCTW6VD+8g/Vv93u/oC4SiZb6u98W752kHJ He+BhxwBquJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5WLZD/9tGW+SDAa1j6P1JeoqOEPRqErAuWYA+JTAgh/zALUXnfIIV+ZPo3qA74IqW/ZtzqvyYZk 3Qrtqg8uixnHJ+VSiT9CKt43uQNFMcr3XAcvU1FUvLNrP9pr6pzP899V2TnKj3U9sq1D/QnpIjg qohw7Hi9qQLefaxYXOIdRqfItSmiZsqFNFsHWE17P8qINAPkp1kwZ7kbxdMTS9pjQWFsb4v6Un8 nSASS12yJlw3auSjTqs9S7MkqzBiTr20HnMHOi+lfD0j9wP5QX3SRo+LuDOskVJQOS8+aqYv+C2 NtuqHZUW/dFH+QFoOv3oznkNC3n+UUXeHXYZGxEsEED3XuG0XHh6+rjYSRQ5KPPpK3l9dE+ralB vZ9Zji3fkGlpm+DdfvTF7bj7V3sKLdw6eyZPB0WZbJrgdV9CBXXB8+XN2wy77HzNPv19BjXzr70 UzVEETkJhXuXYfh/waCY/xWN2gzlXIihfr+tbjNQ40rLwY/8ctc0WuRU8NZy4X9S9iaSbYz3ofs dworsje8jTh1IkB1bSKyFCS6Asq8pJxZj1rYx3l/UB4O+h8nB5j1cNI5nROjbzhLlHplvOsUytj 2uvMZhuuusknc7eGPUKK/Kz3QYQy4Il1cvznzOLlHyGIYd56qOr5KX555Taqg6HYhRg8Mud83cN onjAFgUIMMJXwzA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: EReo8kCQU3KkrEdCc1Bsoq2ffW8JU-IPi3OEBOvFIdo_1790961718 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790961725-520C1CFC-AB0A2176/0/0 X-purgate-type: clean X-purgate-size: 376 On Fri, 11 Sep 2026 15:36:13 +0100, Daniel P. Berrangé wrote: > 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. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439377.1657770 (Exim 4.92) (envelope-from ) id 1xCgxa-0004r1-HS; Fri, 02 Oct 2026 17:22:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439377.1657770; Fri, 02 Oct 2026 17:22: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 1xCgxa-0004qn-Dy; Fri, 02 Oct 2026 17:22:14 +0000 Received: by outflank-mailman (input) for mailman id 1439377; Fri, 02 Oct 2026 17:22:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxZ-0004oc-CN for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxY-006dFI-Ph for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:12 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe831-e002-0a2a0a5209dd-0a2a450bbab2-24 for ; Fri, 02 Oct 2026 19:22:12 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfe843-b7e8-0a2a450b0019-aa0a817ce6ef-3 for ; Fri, 02 Oct 2026 19:22:12 +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-653-3fHADws5NEKkG64FdeYlCw-1; Fri, 02 Oct 2026 13:22:06 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DFB711955BC6; Fri, 2 Oct 2026 17:22:04 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1FAB81956086; Fri, 2 Oct 2026 17:22: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=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=1790961731; 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=57WwPXiri8ItGsFv7myBZwLi/3rudhXRfRGMr5PeG68=; b=FEaSZt20r4ZilZK/5r3U4CPUHOpbtjzRw8vqSWdhgjkq5GtNrPJ7dXVAjwT9rMOgNA92ui ozFDbcVo0VQzm0Sa1IGfk6I/Yqh2q7jck3AH1rcUDwRXFKJL3VTtYZP0l6SHe23is8sa/M bOYw/IOxfTlyP+85Q2QzLLxcLVHF1d8= X-MC-Unique: 3fHADws5NEKkG64FdeYlCw-1 X-Mimecast-MFC-AGG-ID: 3fHADws5NEKkG64FdeYlCw_1790961725 MIME-Version: 1.0 Subject: Re: [PATCH 16/28] hw/pci-host: mark common x86, ppc, arm and s390 PCI hosts as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-17-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-17-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166125.3025252.6382515951011639582.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=434; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=a6PS2bf06cWqaNRA9LviE1UK4mmPhD6vsHBc0nvPGR8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gC2lhKiGV5+4pem5Y08Jr42+7fML77Zq8ZY D+UpTlNwgeJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5TFOD/4r782ffdw/HJtRv2KNyjAQEKod4DsYtlXrtjK2X24h+3XLRvAP0USENWkPc95obEsvg0D Lz5cw7OBRfkJVrjU22t7tRXUqCwN826lTe0GpYPPoohID/MZqyJVzgAd/C/+SN0EGLQRGbq/nZ+ v20D8swUtXr6LOhzBxNfD+6HyeiElB2xbSLsEXlaWDKV0x0RFtY6lcPgbVAuzyERTN+luacFywS wNT6higrjGwTaz9ay9xh/dnvaga7aL66mRkK1XKSQeG85XXuT6aI67Qy/b3JIqeLvsCEIyA1s/u 8Yclm0DBI3dBtmzxOulYMS6xkDuGke3fDBOEL+fNyyTW9OzoEJRXOCMuml4dab7/7kNi6uGvdDI /C4oy0387rRrOY7IU/LdlKhXmbJKfXQul4NpPgs55fyB/26WpbCZIPEDQtmpV+ixw2VslXROqS5 RF/479K4hsxLe2IcjutMY9xCbWePyFK8kShyDI/gOsNUFNh614mHdO0LtG0Ed0XUSEV4ZJJy9gw n0FeVjlLa/wNZW/mwGTXgWgvitFWepS2RYs3SrV9jJZBzzK+LSJOIh/soeo62h/y9WL9D/DgRNF mZQ/Kp7jfQMEjFWxSSrmqcotEq0Gq+9J/ZYivJ9m2h+hK7fafg6aoKgnHp0HSno6BnOfQYNWAfn CT65tKa/jeamHiQ== 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: kDnN5pRKJtS5JywXrHlb8q83KNZR5qG0kbRmTyc6RUE_1790961725 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790961732-2C39B9EA-C275E4CF/0/0 X-purgate-type: clean X-purgate-size: 436 On Fri, 11 Sep 2026 15:36:15 +0100, Daniel P. Berrangé wrote: > 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. > > > [...] Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439378.1657776 (Exim 4.92) (envelope-from ) id 1xCgxa-0004uQ-Qy; Fri, 02 Oct 2026 17:22:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439378.1657776; Fri, 02 Oct 2026 17:22: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 1xCgxa-0004tB-Ji; Fri, 02 Oct 2026 17:22:14 +0000 Received: by outflank-mailman (input) for mailman id 1439378; Fri, 02 Oct 2026 17:22:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxZ-0004pw-VB for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxZ-00D6hg-Bw for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe823-8faa-0a2a0a5109dd-0a2a450a9dfe-44 for ; Fri, 02 Oct 2026 19:22:13 +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 6abfe844-f2d2-0a2a450a0019-aa0a817c7779-3 for ; Fri, 02 Oct 2026 19:22:13 +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-669-T9bDLC4vMrmbaFc3F_DJpQ-1; Fri, 02 Oct 2026 13:22:09 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 368601955DDA; Fri, 2 Oct 2026 17:22:08 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 534DA1956042; Fri, 2 Oct 2026 17:22: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=1790961731; 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=SbqqAHFykwJDNLT95Vrv3Sql/bIC0QmQk8beXY8uxl4=; b=gKpxAhtXEzWFs8LgECFny2VijeZLnmUFM7mmlcw2v90ymRMgSs1fZicMzx1cEok57hMvKk bHMybN8yDRUEW0RulnGNobHZsQESM3cyNJxdt9eNwNW99GnBGe5hP6czHDxkzM2jN17US/ 7NUfP/d+6l+JPKTIju0qi56cQKzwhIY= X-MC-Unique: T9bDLC4vMrmbaFc3F_DJpQ-1 X-Mimecast-MFC-AGG-ID: T9bDLC4vMrmbaFc3F_DJpQ_1790961728 MIME-Version: 1.0 Subject: Re: [PATCH 17/28] hw/display: mark bochs, cirrus, qxl, VGA, ramfb as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-18-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-18-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166126.3025252.2006364005625327282.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=649; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=k9KrD0sN9JLFH9k9W9tr1Ywdw74on+tstjIdDpisM14=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCaBu8sx78wBWfS4O6GESt5JDegukF9FyFw xgJB0pJB3iJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5S6nD/9O1ZbDcqP53KzgX78tT16EGV8Wl3jc3tyrAR6T3SSz6snvMD9TrCYrKnJte0PUOKHpxLG DCvqNo5Mb78Mu6Vnu0AKjWybPlUqS9qN9TVE6jAPRjVW88ckgMZmC2z9qzMUvKQ07vzuws9jbjY 3SxwHmqoNcBMwuHs+YIfxrGJmHFWka7cHV3T5e+hzwKe7yQ3rIYSWO9cxUfvrsRQb20sZ8DDEPf ZSwNHIhXJ5n+ke79kUgDPiHaA0bQCx7yKFw92uocfW91jEuPxRjOmvyLfJYG7eA6/bN/B5QLqUn aI2skgQAmgHYUSccJL7eP8OUwluKHthDp8KqRpDFeSW/YkMtUNnetBL1cQgP9oV75ijenD+C4Bc P+rqn7yIxda0AP28mzHKkTC1WUUoMpoWURSK4b5cqBTzLUsSQ80g4+G4lDTzjOwwG1lVaP6hXGf Kz4itDPLD0MJXYt+Rvmx2Arh6Oywbmmv7Sscnrf9iupuem/ROkI56N5P959za8nYtXBnMaDHaOx meYaXH5CMU7QF2BS5PMG1Q+wJHcjAYds8q9UaPb70tjJ1D25B8BFT1upPE3U9iTNAw2g0VLLrpR fKz+hy5+tstw8jTN4sFA5+i/W6mJZC85XsYIIiGS6lIWKv/4Zbn9/HBaVYqJjKrlFGnVFpwtWxQ vgWXYY94Dqa6dAA== 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-MFC-PROC-ID: 0hqrR3MwUAX-HkPnpKixWagmvSEvWXNl2lFCSbqqxuQ_1790961728 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790961733-50ACCCFC-B6DC73C7/0/0 X-purgate-type: clean X-purgate-size: 651 > 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. I don't think we should support all those display devices as security boundaries. I would shorten the list to: bochs, ramfb, vga, and virtio-gpu* (excluding virgl & rutabaga). Anything else has been known to have various risks and is much higher complexity.. Gerd, based on your expertize, I think your opinion matters here. -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439382.1657788 (Exim 4.92) (envelope-from ) id 1xCgxf-0005Zo-Tj; Fri, 02 Oct 2026 17:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439382.1657788; Fri, 02 Oct 2026 17: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 1xCgxf-0005Zd-Px; Fri, 02 Oct 2026 17:22:19 +0000 Received: by outflank-mailman (input) for mailman id 1439382; Fri, 02 Oct 2026 17:22:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxe-0005Wc-Nd for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxe-00Dbhx-4T for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:18 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe803-2eae-0a2a0a5409dd-0a2a4501875e-48 for ; Fri, 02 Oct 2026 19:22:17 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfe848-5984-0a2a45010019-aa0a857c866f-3 for ; Fri, 02 Oct 2026 19:22:17 +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-196-tB0D-qP7One0EVL5uzWu0Q-1; Fri, 02 Oct 2026 13:22:13 -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 033DD1955DDC; Fri, 2 Oct 2026 17:22:12 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3792330000E4; Fri, 2 Oct 2026 17:22:10 +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=1790961736; 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=odsg6seDL1A3x8nMCICjbWM1bqx8pH3GiORy5lEZxIs=; b=KbCBoJuXtSL2OWdINgYUef0c8GsOKvh+IloSEpz3SZqizah7rfnzkAHQhVqnuxhPWS04c+ LqYZq4luw28Z+FCmN/8MqEG0kUVUxywPK64N5Kqv6MVYQBvy3Rf5eipfhJHMeYSy4KNrVP 7b1tkcfYblCpL6qKzxEs27sONHdoceY= X-MC-Unique: tB0D-qP7One0EVL5uzWu0Q-1 X-Mimecast-MFC-AGG-ID: tB0D-qP7One0EVL5uzWu0Q_1790961732 MIME-Version: 1.0 Subject: Re: [PATCH 18/28] hw/tpm: mark all TPM implementations as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-19-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-19-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166127.3025252.52837397415486624.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=311; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=5ib7kbnvMQLEGT4quBiHZZ2xblFgOBBV7yGe0Fw3Eh8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCa0cJy16Wm8FxYIqcRoer4PF17CoBL3y11 1AUOS+zCLCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5SmxD/9UFyXaFIeiqXGMM2zVmi7AkR5hpeBWSCU9yDDbATqMKXA3Ey7hKwxCx8t+KRLdwudNtxI o1ziuFYsn+WWmZwAU4gWuv12PiKjkGx401ZKI0DLyFTZU18MUCa+Y2xCEMcCcFLP9djc/KB2hSE ZIbUiUqzF5lPVBnmXzlbw9ktpxstl9ycinv5Kw/XWdlWMFJRuZVFQY68XQo5PBxYkwZQt60DnQ1 XOsvz1xDFUBFu/DFqASYR6yq48vaSlatcqiUhowGgmY+/BO8enodwLO/wyXLz/p1f5lkEzcuSIW DBqFweDnbPqE9yUcykSiyS1UCvCBEVhuggqZjumDA2fFpH8qoorePuvUPVrsUMBHzmQhvwCP7lg 53YiP1Z25rgudsIFFGAJI8wyLUu69bKO0ht88tyzcp+61+XDOYP8ooQUBQZ8MDKp09FP1Yb1CZB Bb1Yr74cG/YrRhBDRFhgP4vxjqig7E5o3zJIFGHRY+kZEfE3m3FUI1KodddfGrwPZGvjHR264PM eWX0Vx1J+m2Nma7ID9ZyPzoJvu9quUz3c65NkYnz/m+2sN0ryJUj/QAev/pveFbdmVA8HtQ4BTE eLM1VCaZkbZqNL0cLkjJOnyb8phNbf6Wjfa2nGu2mWEBgNMxTeDhHfsBK3OQxUZIlVqGMrwRcj9 G+W6tP5K0QlWstQ== 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: p9umoHIoYCCclHIxfj3BulkkKLkBp6xvWhcHIqVlzik_1790961732 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790961737-BD67C757-8A41CD69/0/0 X-purgate-type: clean X-purgate-size: 313 On Fri, 11 Sep 2026 15:36:17 +0100, Daniel P. Berrangé wrote: > All of the TPM implementations are in scope of virtualization > usage, so mark them all as secure. Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439387.1657797 (Exim 4.92) (envelope-from ) id 1xCgxj-0005xo-55; Fri, 02 Oct 2026 17:22:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439387.1657797; Fri, 02 Oct 2026 17: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 1xCgxj-0005xf-24; Fri, 02 Oct 2026 17:22:23 +0000 Received: by outflank-mailman (input) for mailman id 1439387; Fri, 02 Oct 2026 17:22:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxi-0005uL-2n for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxh-00Dbhx-EX for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:21 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe839-2eae-0a2a0a5409dd-0a2a4507a19a-20 for ; Fri, 02 Oct 2026 19:22:21 +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 6abfe84c-b4ea-0a2a45070019-aa0a817ceaaf-3 for ; Fri, 02 Oct 2026 19:22:21 +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-459-v8ouDKR6NlSSUtDTyP2BdQ-1; Fri, 02 Oct 2026 13:22:16 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0C7E21954B20; Fri, 2 Oct 2026 17:22:15 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4027B1956086; Fri, 2 Oct 2026 17:22: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=1790961740; 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=RMimm96Yzckh6J/xjCo++Izm66UFIO5I4/eH3KrRSmI=; b=AU0QyGo5+iX7lyvnZnx4LWs5QkHzXYZXHCJqNoFC8SJmGNT7C4wpOGnQ/kqSTsTy4zwvzn 3OaVgf2RnBjzJD9b1FsY320NXASHoAwRqq1TRuMVKCT0qLm+jHJKwXRM7c8aSsLe+5888/ rEkghNLbb/HfzUYp0AM/vERIqXnWgys= X-MC-Unique: v8ouDKR6NlSSUtDTyP2BdQ-1 X-Mimecast-MFC-AGG-ID: v8ouDKR6NlSSUtDTyP2BdQ_1790961735 MIME-Version: 1.0 Subject: Re: [PATCH 19/28] hw/misc: mark pvpanic, vmcoreinfo as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-20-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-20-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166128.3025252.2520972277677656810.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=307; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=gLEzL6V1J5mLj97slKrKoYt9+Fjt2KNc7dTNIJXcKgY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCM0uqO+eCD5hgODJho/LKl0+Oc8OdiGqnu tZeQE1P18eJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5WOqEACHrLMPQxduSunRW/Ocbo4XsahQZMtVTSyghHJLKVbcCv1NrLJOPp6p/SfsYRmPdP1UMIR P1d9PbPfd9ZnmFNlrnqwBDNb/MwJXBh6aARpgS3yi3YNdsLjAyMkD4JVm+kjAJ1/TiiqEjBD3bd rypRrS7Z0OLaUyRicvtdUWOmMkiPxF18nZDj6bvTZRved55YurKk9R/KvfIIS/tPcxSSZ+2qF9/ 1giVeuRBGETVMTrykedEcO3m4kwp4xNJU1uCrvFiDmibOk3LU2Sk9gaWkANtP58RDnf7JkorGJY ZOwWX4VfmdLgBz4/07vb7uoBBIXD6a/FEk22DDFMPvFh0B690dzudNsQwNE/sdLjtP8NSmjBBbf kxixKYZcymykF7VXzRggGlm7ot5+rPTB5/fT277irwXB85698Y/3MyvFrb3c5I5z1c5jEe0WObG GpaI6VLTQLZPWZT3hCAwFYgi3Fkq5Ex+YbGaYthHUpctoQRGl1J7U51jidCDP5J1dbudeDNGCWW Pnwi/ktgXgxO6prMX7CxXxyNN1YUFOG7e0Ri13BVlkHYUyvTNq7SYRFZWiY8iLuvCdbH7yv6Mhs pRhpIWX/OSKOt8XcrczRLyQkxDCop2VPvXxDuNmE2omoxNSdtpXKChvm/Vo9Iaol20ZwUWCHNH7 kphu3iVgT6cwL+g== 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: zIkLMCj51WM9vVNqUs2PVnr_OV4tvqPqb5xcTXYawEo_1790961735 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790961741-368D9AE4-65F96969/0/0 X-purgate-type: clean X-purgate-size: 309 On Fri, 11 Sep 2026 15:36:18 +0100, Daniel P. Berrangé wrote: > The first two devices are common debug aids for virtualized > guests so must be marked secure. Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439390.1657806 (Exim 4.92) (envelope-from ) id 1xCgxm-0006KD-Dp; Fri, 02 Oct 2026 17:22:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439390.1657806; Fri, 02 Oct 2026 17: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 1xCgxm-0006K2-9h; Fri, 02 Oct 2026 17:22:26 +0000 Received: by outflank-mailman (input) for mailman id 1439390; Fri, 02 Oct 2026 17:22:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxl-0006FQ-72 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxk-00DbnD-Ia for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:24 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe80f-2eae-0a2a0a5409dd-0a2a4506ad7c-34 for ; Fri, 02 Oct 2026 19:22:24 +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 6abfe84f-195a-0a2a45060019-aa0a817cc067-3 for ; Fri, 02 Oct 2026 19:22:24 +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-399-st-InwMuM0WT_i0imwlKng-1; Fri, 02 Oct 2026 13:22:19 -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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7C9CD1801319; Fri, 2 Oct 2026 17:22:18 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B1FC918002B6; Fri, 2 Oct 2026 17:22: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=1790961743; 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=BkbZwo6BKqdN9FyfW6CZ9LI53lQSA5aNUof+lObrH1I=; b=HtIaOyP+8AEpBlHVkrfKSp+Z+eHmzZKB7I4m+7EOVkGdIy3v1RRV6cYD/zv9IlrBsV1dUZ bPHerd87zYb4/D4A2r/zPq1LLOzMezD8HrFLuJoDyhlkW6SN69oeB3xLqwcPPt6cZdFI0C t+YUGlU8y6iFITSkr64aIj9seqqIFkU= X-MC-Unique: st-InwMuM0WT_i0imwlKng-1 X-Mimecast-MFC-AGG-ID: st-InwMuM0WT_i0imwlKng_1790961738 MIME-Version: 1.0 Subject: Re: [PATCH 20/28] hw/audio: mark Intel HDA devices & codecs as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-21-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-21-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166130.3025252.17906816628479360291.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=315; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=4AJECLAYQLdgX3cfz3V5wucj9qzYfJl063dVaeFkVRg=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCihf7o+jVJw4FOs+7k77hi3gXkxkUTPCXj nqZ2JbIdGuJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5cA/D/4o6z31dUWgzSCY1uFrrInvlur+c4OhgQSpNVWKjQ/+LHxJlxKP7WybTbfxkJzGw3dxsbB bKNpOwhxbFYZ3pN+b6h7cv2FwPU+qzvdt95KLO5mVJ94o+uorUU8S14ZMEi4qTdfkXkoHjcK/p2 X55+ybKj6uM8zYcJEq89UBwe9RkQQwXKOgsr8B48NlsUJXk0r4cmXAJB+ha/tqaJ3lxgqI/pJ0Z +BM2oxbTynSDvXmzjN8ndgWT9BWymmKU8WeGrxHpMqq4yv1Q8cCXrXmBDc4Z+8w9hYNkuHF0sYL UOVJC5YvyNqVVCWJ9MRhBwlADOGaSsuc+kqf+y/k5vAaomuLTk3ZYncpT3hjy4Php2fnHTkDzuW eSlIa+01PeOb6QamgbzySbtl8ygkuajhqtVoPjuKYzuzsjEdAp/yp1jGzwiX3EMdtzZDmgyJCpz DtLg8WCgG/C7qrJ4LVn6HclCCCL/FihCyp/h8TT7+L4uPnJTkAhjgBZAtzRvE2rnSMDcB1OHMaD nJcL1U9UqsJMSa5nLgU41BGQ5klET3e4CjOHzms07F6q8N5b1+zLAM1v3gx5vI+L4rtE5KQOsKs KrDwRFhS/NmHiZTRYCbBFZfrM9vc0HUsq2tEKTqSneIHsoybi2SF302bMW06Pr9iMV1MV7axrQQ aLxlCMZEl61+5OQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: IKXCHJ5vCqgZ3d8Ose5FC_4gzRMgrz3bB0igjPacq-A_1790961738 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790961744-FE07177B-6962630A/0/0 X-purgate-type: clean X-purgate-size: 317 On Fri, 11 Sep 2026 15:36:19 +0100, Daniel P. Berrangé wrote: > This is traditionally the primary audio backend for x86 as > virtio-snd is a relatively new invention. Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439394.1657815 (Exim 4.92) (envelope-from ) id 1xCgxp-0006ib-U0; Fri, 02 Oct 2026 17:22:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439394.1657815; Fri, 02 Oct 2026 17:22: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 1xCgxp-0006iH-Oe; Fri, 02 Oct 2026 17:22:29 +0000 Received: by outflank-mailman (input) for mailman id 1439394; Fri, 02 Oct 2026 17:22:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxo-0006e4-NT for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxo-006dFI-2z for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:28 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe831-e002-0a2a0a5209dd-0a2a450bbab2-38 for ; Fri, 02 Oct 2026 19:22:28 +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 6abfe852-b7e8-0a2a450b0019-aa0a857c5f25-3 for ; Fri, 02 Oct 2026 19:22:27 +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-610-vs1CX2kXMLiBxPQbEb8Dtw-1; Fri, 02 Oct 2026 13:22: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 B72991955F2B; Fri, 2 Oct 2026 17:22:21 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D057130000E4; Fri, 2 Oct 2026 17:22: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=1790961746; 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=TZ9t2YOOebL6cB98bzzlqu70Uno91Rp50azC77ksw0k=; b=XuiT0jsM5xF0yElERUIMP9kU/kFgodaTX6VirNZAjOYlyJO9mxduFbHw9qRHtVG1uESlko a8HlhFVS0Pm+7MFjUQuNp77lHGE578K4j0dQlK1+gybvfm7Hy5qh0Mv9G/fUlchyi0oPJO okNIsSFQfjO8S5QTwB4nNrrTBKpLPUU= X-MC-Unique: vs1CX2kXMLiBxPQbEb8Dtw-1 X-Mimecast-MFC-AGG-ID: vs1CX2kXMLiBxPQbEb8Dtw_1790961741 MIME-Version: 1.0 Subject: Re: [PATCH 21/28] hw/char: mark common serial / console devicess a secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-22-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-22-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166131.3025252.15804110579226789174.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=309; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=3i625zs0zRqrDOwzUvcSLrcAcxtVCD3LCYZXUCFhaWI=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCZ083AgK4//+Yw4uwWOXwBw2gUcDMAUlT2 AOhv5khVMiJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5eQ5EACPW0m2YqQZqCJiSd0Plfmrpe16ta6hZ6NP+BOqb+MMUPZ+nvN2BMw82h/ygGFCpACXqYl /0JhvhMFriK+eVh4k1hFjrRyfc4iMor6JhMpAhGdE+AKHjGXSR+Qq+oW/kABKKuNy1nDT84U16l 94pUSmKIdsN/FE5cEB1c+LCz5TU1ST9kkdmjcurECOTl/Ncl6L7uuLtE80NLjkBQEek1/+AZGO7 5UXgzrIztDpJkGEtQNcgRhwBXC2e/wYSv0G7XFHvnHA/unl8VjGReVBmQvFblzkae8erW/KEhkj Hp9/vcFQVMooRpo9zJc6D4fk4kXIzik4b/UT7UxvTuDcht4BrpYDkZaFeoOW08qOMgmtwX+VGyy J5vRyI6/Nwn5fDOyyQLbc5d4OzStMa/G66w9fOI7vfCsC+EEjI3mB86/mMi3+U4lbb1Tl0yDyca j6l4mRaJvK33tWPhtHQQqsKXHxVOHw1Fum49uk6eZr8BPKgJgFly6aLPjXy0Oel7V5YtCKMLLkl ou2ALD2sikLZLHp0X99JxkCyHhyMaGQkHqt8wedbW+Ad3c4DqjNfDKVU3beEwHSUAtuEMFw65cT Q8iIIcNPUo59m6dCEe6B0tYPA25oRhLodevLhlYdQM3AZECgLHchSn2R63yAzZFQWNEDcf4NdX7 xCmFqJkto4MX9FA== 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: InLFylsbss-SpUuOa58xNJkbG_co5UQBdJq_9RPUZ9o_1790961741 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790961748-192CC9EA-356CE436/0/0 X-purgate-type: clean X-purgate-size: 311 On Fri, 11 Sep 2026 15:36:20 +0100, Daniel P. Berrangé wrote: > These are needed as a baseline feature for many virtualization use > cases on x86, PPC64 and s390x. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439401.1657824 (Exim 4.92) (envelope-from ) id 1xCgxv-0007Ii-4c; Fri, 02 Oct 2026 17:22:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439401.1657824; Fri, 02 Oct 2026 17: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 1xCgxv-0007IU-0s; Fri, 02 Oct 2026 17:22:35 +0000 Received: by outflank-mailman (input) for mailman id 1439401; Fri, 02 Oct 2026 17:22:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxt-0007Cx-QK for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxt-004A3N-6v for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:33 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe859-bab6-0a2a0a5309dd-0a2a4504d576-0 for ; Fri, 02 Oct 2026 19:22:33 +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 6abfe857-b57f-0a2a45040019-aa0a817c5991-3 for ; Fri, 02 Oct 2026 19:22:32 +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-161-LC704IdPMLqkiaegcC1f5g-1; Fri, 02 Oct 2026 13:22:26 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 064DE1954121; Fri, 2 Oct 2026 17:22:25 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 39B3F1800351; Fri, 2 Oct 2026 17:22:23 +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=1790961751; 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=fak4bGxidLKDm8+4zf2stLqtEk3iS7PCah1litKSQk0=; b=NIEXQDIb6GzYRl/xP13FzeyJ7vSJ9acMfC1v0IAsh4M3f3+vzmAtBsy4d73TIHVdqJlYVN 769YqIIdazj0+HpPs9bb7uqGrVhQbvcRh8Be5YvBzDgk/A5PbOVCksK+AuuXmXPnYTEIWA b8s/qWRXgPwA95OGlLx9O1cvMFdHrV8= X-MC-Unique: LC704IdPMLqkiaegcC1f5g-1 X-Mimecast-MFC-AGG-ID: LC704IdPMLqkiaegcC1f5g_1790961745 MIME-Version: 1.0 Subject: Re: [PATCH 22/28] hw/mem: mark nvdimm, pc-dimm & spapr-nvdimm devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-23-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-23-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166132.3025252.8374840789569151236.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=310; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=+hBolatsDZQIj/Z0rZnIsFgzxbSxAAfLtca3N0SKnL8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCTxVY/NfEOmxEI5DosbXgWeTaDwYFNy5pJ JpMRccDkcCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5Y4RD/90mrXaHjotyW/NycDhxtaRk30LLlthREYNx5Jr1HC5CDTTPW+Z3mU4AXOB8MpD1nllw/a 6HxtrcjZExMg4B47l/yLIV8kBUiPH3oCfVor07tirbl8CRQ4xVx9NMbArqYJX+/PE8wXp2ljdto xDn/uw/804gJhFQ5aBKHx5qOIVgYCXWCX5jqHRkp4crJIq+N75NB4eWQ9dDN1eKSUn0ElqrIR/S b9tVv+FNphFso+vxbZQdytykHGA/tu22KGueOTGHnxX9zqkfELsjsfxykF21dtGQGPCz0G0Xd4I 5j9cOEfIzMUH5vDutkcLYT1WrsS2PSBlUIMl0yTbvYH/Z3zHHVsg0ozvyO32qHPdKBg96yl8cHD ia6b1RQhC5M0bJ/5l9tzmqlDp93m0st3160yd4LndN4eVOAlFxCAO7wyZJ+qOuH2cP+F3rtbyvo 81qylevm4jxouDm29zISR6vj78IcU0krAmhgqaui2iEUIavvUcahORbN+brJ2qxuYNP7w4bA4rM 64OIyI25+61AfDpXXvnckQ0+udHRSLmNPXQa4mTRSseJUI3Lq+uff3YDhtJ9K2gGEihB4v8FD2j gtWWpYgSDfmCWVDuGo2QsyCtMtaSzoVqJk3pK6KrRkSwDbtG2EEdMN3QX5mStbaZpL7dTmTL8SS K0NstiiLHtfkyHg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: ETjgmQ49oXynxUmSDvvDwzuPtQcgnfs4mVOrmW6BLyU_1790961745 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790961753-53EC6B50-4288F360/0/0 X-purgate-type: clean X-purgate-size: 312 On Fri, 11 Sep 2026 15:36:21 +0100, Daniel P. Berrangé wrote: > These devices are used in virutalization scenarios to support memory > hotplug and other uses cases. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439402.1657833 (Exim 4.92) (envelope-from ) id 1xCgxw-0007YK-Ct; Fri, 02 Oct 2026 17:22:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439402.1657833; Fri, 02 Oct 2026 17:22: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 1xCgxw-0007Y5-99; Fri, 02 Oct 2026 17:22:36 +0000 Received: by outflank-mailman (input) for mailman id 1439402; Fri, 02 Oct 2026 17:22:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxu-0007Gv-No for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxu-00DbnD-4e for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:34 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe80f-2eae-0a2a0a5409dd-0a2a4506ad7c-46 for ; Fri, 02 Oct 2026 19:22:34 +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 6abfe859-195a-0a2a45060019-aa0a857cc925-3 for ; Fri, 02 Oct 2026 19:22:34 +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-134-S7z4tXkPNrmfa_jO6cqFpg-1; Fri, 02 Oct 2026 13:22:29 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0EAAB1955EAB; Fri, 2 Oct 2026 17:22:28 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4375B180049F; Fri, 2 Oct 2026 17:22: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=1790961752; 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=eOriw+LghHj9+vMG1cT3+MK/B4WqYAF6qOuDOKE7MfI=; b=aKoZJjEIGtjQU1m+WQA9slQ8ibTL7CUOcbxSRdilRVkgg0AM2ZEQvO8/Xscq9qmMI7mzzS 8K8UYeDcLPudrp70ww6WbW+n9lZFKJEHs6DucS0BfPQkZqjKCouCEy4qwp6Nmz7kzRiom4 wUiRGvS3EHDEXfvTjhvvnCaAPchn80Y= X-MC-Unique: S7z4tXkPNrmfa_jO6cqFpg-1 X-Mimecast-MFC-AGG-ID: S7z4tXkPNrmfa_jO6cqFpg_1790961748 MIME-Version: 1.0 Subject: Re: [PATCH 23/28] hw/uefi: mark the EFI vars service as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-24-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-24-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166134.3025252.936615391375619409.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=293; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=M37xF/NbMOdOpLB4jOwsy1nFVdoOjkEEGL3m01AKXQM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCiEK0jUwP3HNtqom6v+0KbBo/5lzpS2K3m G5wgXBxj7+JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5f8dEACLQMHp121WvdYZRzZAYUqu/4KkuUD3HC9jtzTBEZgO+bBgV73vMY2KYCFE9Elvfdq508C NJt5HCLiXMvWtkUw6ZAjVr+nC9qNuWkgCYLsHNVHw6pIvSEKTH8RKcEouv7IRt2uEeN/A1pZChB TEPmNiYUEbf0VSYZclwdUZvfE91Bz3FuhjefZJjIgdPev3hkNyefq7PB6oD5GKLElm9gbsk0e78 hdQ1Ye3C5sYMN9hDBT1QPmewH34x4+uRV8q/UTfzB4bJ1Tf9xWd2iRhKSaoxB4hXfocWtjxGGnw y+CqT9va0jaV2h8g3MYQETz5xQeUgmWCs9InMpHkzTQXW5XCjJZV2sz6w4ezQVrrrNJK9keUZdm NJ13a4PN2VQyen15XCiSs9aNtUaHuhmmtCp1ZZTllFeo1bfB5Vxwm5Ta0ws5iflDlJTkXmJ/Goz RT+qXnNYnEU4S2H4q0LMrcdO1jFq5eiBIOEjdaGHci47P/jpP6yZqTDsK4z8zlhvV1jljs695zS zaIlUoHOL9n+LZODwU+j6wXPceWZ8OIyExYzZafsoa6gK4rQ9dBe24N846ewMeBVaP8+vFJ2/PB rUEnroF+q1uqP34MpXhws02i6JcALcCNoF/FomRJgoyDFQOGLZwI7AhkDdnYCVZjU6WDzjpOwZ/ SbTbn/tVwmvy4nw== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: iTOlOFcl1WAFyCKwA4VJBTZsD2GBv7wUDqAj6a7iHlc_1790961748 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790961754-FCE0677B-20AA946B/0/0 X-purgate-type: clean X-purgate-size: 295 On Fri, 11 Sep 2026 15:36:22 +0100, Daniel P. Berrangé wrote: > This is used to persist EFI variables when NVRAM is not available > or undesirable. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439403.1657841 (Exim 4.92) (envelope-from ) id 1xCgy0-0007zZ-P7; Fri, 02 Oct 2026 17:22:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439403.1657841; Fri, 02 Oct 2026 17: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 1xCgy0-0007zN-Lo; Fri, 02 Oct 2026 17:22:40 +0000 Received: by outflank-mailman (input) for mailman id 1439403; Fri, 02 Oct 2026 17:22:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgxz-0007tI-13 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxy-00DbnD-E6 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:38 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe82b-2eae-0a2a0a5409dd-0a2a45089242-44 for ; Fri, 02 Oct 2026 19:22:38 +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 6abfe85d-f659-0a2a45080019-aa0a857ca1d1-3 for ; Fri, 02 Oct 2026 19:22:38 +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-644-Nuf6dyyKM0SdfCEFBrS6Zw-1; Fri, 02 Oct 2026 13:22:36 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A459118F4BEE; Fri, 2 Oct 2026 17:22:34 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D8A071956086; Fri, 2 Oct 2026 17:22: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=1790961757; 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=sZbreQQHhvp91loUpdeP4aZ/RKrcLPZbF/PAGSeQWno=; b=OOaMQ/va3MHy6eXrLCpHQVMMv5/EjZ478F65LIbrcPT33mX0ku2kDFigQcvsQ2uWB1XlhV /reyT35LGAEsJJrjuzY4a8VMvrhgyMssWc+oMTbxv3RUiGIFRjbztEqN4/d/lCpLfD6YiU MHRv1Fga6vFOYiWN3z1gvy5bD9AZeEI= X-MC-Unique: Nuf6dyyKM0SdfCEFBrS6Zw-1 X-Mimecast-MFC-AGG-ID: Nuf6dyyKM0SdfCEFBrS6Zw_1790961754 MIME-Version: 1.0 Subject: Re: [PATCH 25/28] hw: mark KVM clock and RTC devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-26-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-26-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166135.3025252.15042445966657484711.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=302; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=RgriddRIoJ5Fdcu+Zvv88tHI9dTC0oc9vQqbXoJtYoM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gC2A0XRcSs7EOe5/RnSBZGhpsE+XBGBXq2F 6yA7zcaGCeJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5SVSD/4is/H8riITQOd0QCjoRhVdRECSA7+r++NfQE/FpZ5QM4k+wdqKqmrvd8oj66rN9yRaqUE jr9I57OwAhPxYQHSc1OBlC9BMU19ogNbLLUesBeQjly+oo72m76m9/vt6mOCOnlWvuSUEeppaDx FsQZhEmPXXdpGgY8EfygrNjIkMjjjA7n9UP9/rto6MuNzj4iTONGPmIKGhU9990itaUSaAH5su9 JoXFAy+N05CEEaEIMud3pCHNtUwPxRUjIIRET3nWMIXyxHRUCAnhShDhoRSksNPNqwPSX892DLG XPhpVMdtl2PTZUZUCEE8SnsdVCepw5THrVPwfrI188MjlbBszrfreYYcmjNYIBS++X9aPIrjvti qwdd5zRoIBUL2qZpHcBrZirMTB6s3y+RAzTPuph8nx34k0jRVywAZc+XReB5JWNFlLWrS8tFtX5 W/MmD6Ck2AwnNnfYKskA++WQq7e9aBihxrIpc7nzvG9BBufI4P6x3+So3DcFxYeaRiPRzHj91A4 UT50+dPZsvYlHJnSq3S8Lu7jDCHuLBLFaAzoySfIUYRz12lVC5wukW0Rw/ZpjmjNN1fHEB2+xrt hLfs6JS1XBvt48y9VCdWOT6v6uJGlE3BeoNo1bfF4KzOu22yFu+kfmDaDncuPoeLTkqzEVQhhPz w4BUd0J2Zn8ojhg== 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: 4yuqDN4N9bxUlB0I4BQPr_EoRKc5WNTJ1rM0GAheniU_1790961754 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790961758-D694287B-AC6FC528/0/0 X-purgate-type: clean X-purgate-size: 304 On Fri, 11 Sep 2026 15:36:24 +0100, Daniel P. Berrangé wrote: > These are core infrastructure in virtualization cases so must > provide a security boundary. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439405.1657847 (Exim 4.92) (envelope-from ) id 1xCgy1-00083b-7u; Fri, 02 Oct 2026 17:22:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439405.1657847; Fri, 02 Oct 2026 17:22: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 1xCgy1-00082a-16; Fri, 02 Oct 2026 17:22:41 +0000 Received: by outflank-mailman (input) for mailman id 1439405; Fri, 02 Oct 2026 17:22:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgy0-0007xh-2r for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgxz-00D6mJ-Fs for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:39 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe84c-8faa-0a2a0a5109dd-0a2a4501bb9a-16 for ; Fri, 02 Oct 2026 19:22:39 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6abfe85e-5984-0a2a45010019-aa0a857cd671-3 for ; Fri, 02 Oct 2026 19:22:39 +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-558-p1TWn7s_PYW4Ecdwm5PBsw-1; Fri, 02 Oct 2026 13:22:33 -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 8A0511933B54; Fri, 2 Oct 2026 17:22:31 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9F4E930000E4; Fri, 2 Oct 2026 17:22: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=1790961758; 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=EEhqnm3EOmM9eVr8GLVonlTQqlbVQbBXp3m1BlQx9GY=; b=aZ8xaEQYrEFSpZohm2ObDIiMN4HpUNLOf2w1l3dlVUqZLsZs072dDqbpAGEABqe+vTOIbB 54UxBKYSAhcn/lvj5LXjBTyWGHO+C7xWZkBg2pC8MDZ1PrKdN2DZHOE45JpOPZtk1eOrSO +FSQ2RqxeFd3a3rUkSvHT2VIQnvDl/4= X-MC-Unique: p1TWn7s_PYW4Ecdwm5PBsw-1 X-Mimecast-MFC-AGG-ID: p1TWn7s_PYW4Ecdwm5PBsw_1790961751 MIME-Version: 1.0 Subject: Re: [PATCH 24/28] hw/acpi: mark erst, vmclock and vmgenid devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-25-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-25-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166135.3025252.5276440234709859311.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=311; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=Fc4JGWriNlh1aGVhw+L3RaNahMSkAov3VpkIEc3qsrs=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCFZNQTLJcghDdZduMRhYInrKRZN96owzBZ NuUAnHSWY+JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5RzhD/9IzWE0cq3SuUd3EvzJ9eyA4wNfZNMJWR3MfNxrIVYKPWMzF3n5Ozxwp7as/uktUWP7keG 27P6I3tMsqrwpKUqAyq8CUsLW6XpA3bmM8Psp6KqQuiarvkJsYwwF5P7lC3I6SUlLvQql97plz4 pQYiSAVmOUbewFfE0CfSkUCBwSJ0zN4qDliK+Uh0DIBs37h3zk4Sylpi2vFHo/MTrARoRyvoUT2 NFyqRHrua1vj8NEaJtm8c4TLSUjDmFmcFuQ7aylb/0y/qz+VLIiYjzXiQ0dqESzSEj9ppZBG+XP 8QjRjm3JNpKLhB8T4Aya+tNsqp7nhSvBbEAFKPh2n5iRAFYDKxWWEQTPV9BhbSjJ0UmXvILoVer fP2ML12qnHwidx9UELRuyMyIYVBabAVK5yvs5e9BcYjDlLTw0WY6rCoynLw6gJjck/7/nJB9Apn Dqfftm/va4YSeTAgiZlteU4D+u6Hg+Z3+0BAvSP18gRKHUhQijkpDBSh/zTc+OR3+mC27ltQHV5 F9hhTzu0MzGpnJ45tkqI6vzH9O322zY6uSoMM+7kI5Z9R8ISBolwOC3q/fa/OZl38TKe+qtFkVp qwSBKQ8TWddFtAhUuwcgwb1eFI+wU48t79BwshaZMo+AfGPlrcFJ9xIFpiWUsynnnK7w2o6lFfL o2HeHPy3X+P8Icg== 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: wnJxtcdxtnxzJVM8MyaSSsgBL8MIdBv7i4bHxjhfqAs_1790961751 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790961759-1E465757-532F5F9E/0/0 X-purgate-type: clean X-purgate-size: 313 On Fri, 11 Sep 2026 15:36:23 +0100, Daniel P. Berrangé wrote: > These are all used in virtualization scenarios so must be > declare to provide a security boundary Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439408.1657860 (Exim 4.92) (envelope-from ) id 1xCgy3-00006r-I3; Fri, 02 Oct 2026 17:22:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439408.1657860; Fri, 02 Oct 2026 17:22: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 1xCgy3-00006D-ED; Fri, 02 Oct 2026 17:22:43 +0000 Received: by outflank-mailman (input) for mailman id 1439408; Fri, 02 Oct 2026 17:22:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgy2-0008Rm-Ly for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgy2-00D6mJ-2j for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:42 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe832-8faa-0a2a0a5109dd-0a2a45028480-42 for ; Fri, 02 Oct 2026 19:22:42 +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 6abfe860-6ca4-0a2a45020019-aa0a857c56a3-3 for ; Fri, 02 Oct 2026 19:22:41 +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-686-9QrLD9LIMqGfKHUCbjL-1g-1; Fri, 02 Oct 2026 13:22:39 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 38F7C1954121; Fri, 2 Oct 2026 17:22:38 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6CE321800351; Fri, 2 Oct 2026 17:22: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=1790961760; 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=WGXglyin6o1YnCJq2kD2rscpcytOiPmgHEZgX3OWp/4=; b=HZ4OupWgokjmbCdyFGk9OioA0o5vmm+zKE58I0gWzSo8AM3tJYsgNpfnFymtWUfRt8eNfc LSbV5U7NN/seQapKtX4CVpFGJLXMpS/EIa67j2a7ZFfUZ33FQxiMMamhnKl96DtXojOPNN A11US86qg4jqZFQjcIWNpMZ7576+Q1M= X-MC-Unique: 9QrLD9LIMqGfKHUCbjL-1g-1 X-Mimecast-MFC-AGG-ID: 9QrLD9LIMqGfKHUCbjL-1g_1790961758 MIME-Version: 1.0 Subject: Re: [PATCH 26/28] hw: device AMD, Intel and ARM IOMMUs as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-27-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-27-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166136.3025252.292036806890302152.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=336; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=2w47OdY8X64cy6/RH7KGYjLAQjIW5+wbMAeD8NQNfd0=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCGnd+3y0WJKj+OVcxuNWalsPpltzlw8Ly7 LD1wvDwz5yJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5SCED/sG8OtKpP2uG4CPl9svS/RoUQ+uIVmWcP1bOuuqWnuuATHdZ3yt06+9qgQLzqx3LG5S7Tn c3D/0yUpkLQJpLN/LzPfvVqPDdMPTFnEsefZ4oA+8VhBEE0kcyRhps1+E7uWF7GtOZoK7YZ6VPA PjUXDMLZFZf5v5O6/jEBCinlHKn73oIrgO+iCTGEWpMzZEkmEZHXHFOwMd0x+zyA5lPWX5W8tnE /x2wXAwufP57iXtPtd8sSuEjBgo1QA/nXSRSUH0ZE69B4BegRm7t5bfF+dhM9cl7ljHr4Sz+J1X fXWHCamFfajkPiFrejzV3pXuWP+N0xvfFraaTzACqXAnjj5MJQ+Sx7eYNn8uTHfrhdlJ58qeT9d HSzzYalFie75frQMdbaKOAVSOntH0ATLeyLHKgo54Xt7Q4Cpp0rR8KKPRUMsQ+nQwaGXlvmT+0K vyOqA+RA6M7SSM7Vl34lMlFVOfQpx+o7o5She3uI535o/qo5AQ+eWu678uEyTWN/PTr5vwOQred WRi5q/Uf95+3y0lRd2gi5QGNwrr0iBoNiIhKuq29YQgAONM1XFp5VoWy5966Qx7rxYMMdmOgdVj HxtrjoYwBwFcG6aYdy7lwbvUk2SGBybIWIfB7fUfHW3BlIoxZbMiXvRZtELA6l4tAgfk5b4kW38 XH5VeP5KWbf9MrA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: zSiqib6RXyf6d1vDQw5t9PW-7I3OU8_4zuo5Epk50hg_1790961758 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790961762-F0CA22AC-465E87C0/0/0 X-purgate-type: clean X-purgate-size: 338 On Fri, 11 Sep 2026 15:36:25 +0100, Daniel P. Berrangé wrote: > These are needed in virtualization use cases to support PCI device > assignment use cases so must provide a security boundary. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439415.1657869 (Exim 4.92) (envelope-from ) id 1xCgyA-0000pd-5Y; Fri, 02 Oct 2026 17:22:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439415.1657869; Fri, 02 Oct 2026 17:22: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 1xCgyA-0000pJ-0T; Fri, 02 Oct 2026 17:22:50 +0000 Received: by outflank-mailman (input) for mailman id 1439415; Fri, 02 Oct 2026 17:22:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgy8-0000ig-Nj for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgy8-00DbnD-4g for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:48 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe84e-2eae-0a2a0a5409dd-0a2a45039dc8-26 for ; Fri, 02 Oct 2026 19:22:48 +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 6abfe866-fae8-0a2a45030019-aa0a817c5715-3 for ; Fri, 02 Oct 2026 19:22:47 +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-115-PkVk7RhaOhCkLiKssukuCw-1; Fri, 02 Oct 2026 13:22:42 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8969A1978387; Fri, 2 Oct 2026 17:22:41 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A4FAE1956042; Fri, 2 Oct 2026 17:22: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=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=1790961766; 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=3Po2nSWSoSayh0ZmQrKbOsEezNV+hebfVDCbY0uFMRw=; b=M3nJqK+tQ0dow8gPCv2cnq+X4FE3kBzA8DNLAzLvPjd6+D3fK4LpwyQXuI+/5bJYdFoPYb Ism+pTOg23h77QA3mAY7sD5QqZZMVDDD6xiEhIdgJipHilei49hU2vdsuhPv/ZoMrM7VDO CEZs9idiXzUhyLUOVQwsQbMqq3UPQsQ= X-MC-Unique: PkVk7RhaOhCkLiKssukuCw-1 X-Mimecast-MFC-AGG-ID: PkVk7RhaOhCkLiKssukuCw_1790961761 MIME-Version: 1.0 Subject: Re: [PATCH 27/28] hw/input: mark PS/2 and PC Keyboard devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-28-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-28-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166137.3025252.556263905170599031.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=302; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=tTtlzWMBLVL6WKPHRL13fizlkZpuTmnkOPP5LOIVXqw=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gCCkdjQH4kX6PW5FdNo32FTnqzwmd0E2m+2 jaQ7RkhhrqJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5VQgD/9rcFRVxD/6+8UOsDu9lz2b4VreQs5EVRH9m1SendqEq/V3fy0YFHVoQrPqiT3LSuH/xSz QP5u9BcFdttl/KHkw1dKNY0kAVVLtpmtlAOTDibUKSyEHzvqxPQA7vnE29Eeq9N0Q84REnObo6u V4fpp+b+D9/fY7gt1whCiWP1NBCrCmduex2TE/8FHZtQ8a5RY8ekxaQ1JillX/uyUdhNuUJwLTt Omhmpo3ftIuplNexoYcnxBKL1+ehp9VxdR3PlHGtkahCYZr2R91fWg7Ua00Ny+8b55aQLdU5vtd 9NSMyp4rVBsi82YdTGq2NZuiav9r4g/OHnePW8dtTf0RuLVxt52rhdWMV8gXQ/8MPkFdErXK3XM mDgb8iQxRYx8UUXoOCwzEyuqJd0N+25HeOlEpW8VgVJy4RH+JV50sqobkqDZenwRu7nQhf4WvH6 JPTig+2MFEEQkcnLLtem53bsLO8+fc0LeqWa8jJH3VWQKA6/IsVoq6jbjXHPZnoh6+pZ1NT9CJK MMneVAr+WiDHrYGv3BSGR4Vz/IMMYUxwVBlByHWKsn66ozOW0DQ6eiqpBnPx7BgMBopplIx70lV MsG1dPgu80yrUb33BkYtw2RXCmxhe65oNOBaqFx6oWpAiOQGoJUlS1AHGOlM9TMqodJlrraVgPV nFmtm6Z5xJhkkTg== 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-MFC-PROC-ID: 2p79VLAduhI3AC5GgRhIhGOseU6KZfe4RlVj4CHgl44_1790961761 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1790961767-774F44E9-E57A6F96/0/0 X-purgate-type: clean X-purgate-size: 304 On Fri, 11 Sep 2026 15:36:26 +0100, Daniel P. Berrangé wrote: > These are part of the baseline x86 featureset so required for > virtualization use cases. Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:22:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:22:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439423.1657878 (Exim 4.92) (envelope-from ) id 1xCgyC-0001Eh-GQ; Fri, 02 Oct 2026 17:22:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439423.1657878; Fri, 02 Oct 2026 17:22: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 1xCgyC-0001EU-C6; Fri, 02 Oct 2026 17:22:52 +0000 Received: by outflank-mailman (input) for mailman id 1439423; Fri, 02 Oct 2026 17:22:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgyB-00019A-Qw for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgyB-00DbnD-7x for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:51 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe84e-2eae-0a2a0a5409dd-0a2a45039dc8-30 for ; Fri, 02 Oct 2026 19:22:51 +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 6abfe86a-fae8-0a2a45030019-aa0a857c9c13-3 for ; Fri, 02 Oct 2026 19:22:51 +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-522-pVw1YFsrN_m9NTnhgaUrkg-1; Fri, 02 Oct 2026 13:22:46 -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 1F670195605C; Fri, 2 Oct 2026 17:22:45 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3C94030000E4; Fri, 2 Oct 2026 17:22: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=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=1790961769; 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=E5LovObXsd+x7ixIR+7zkcVTunrEyBe7qrnijmlqipI=; b=GBYFGY0dq0tgXg53I4XiauuBIfvbEKVdgKXeHFZ4J+O0Oz81cnXVYrNVAP60/bGA+4DPce kHwiU0h1ic8EHG9B4szZ0XWa17CX7hXq64GgX7YwHVhNGFawFpx6dIaygqU1C6fqOwfbY/ UWhOWnzkNChTc2/DSX+ledJY/nxWOJg= X-MC-Unique: pVw1YFsrN_m9NTnhgaUrkg-1 X-Mimecast-MFC-AGG-ID: pVw1YFsrN_m9NTnhgaUrkg_1790961765 MIME-Version: 1.0 Subject: Re: [PATCH 28/28] hw/i386: mark vmmouse / vmport as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-29-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-29-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166138.3025252.12907499938719842280.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=286; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=gvK2RfkpNRKRYHzZLHhj68AoUv43xpfc5/CBZLJ5Ho4=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gDJJv1uMI2ckvrQpbIefSwt02nXW6atmAJx MNeM2aZzbeJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAwAKCRDa6OEJdZac 5cswEACebQq55wsDKd4ZCgpU86spmUmqDHyF+e5ksThpDW2qRAaFtDx4VkQvUwBigiFW7f8+7q7 VM07EPYeSLS9zLpe6s9NYsaMuzvjr5dQ+agbd+gDFl4RXQPpFkA0BGxW3FHOSdRGnPczMBq6Bb0 1padhlVaZl9iAqmg8uoBN3oNXaPzSneP/6j0pLr7me7jpqUgmHa2NVADBjnVdXtcvfASoxf3Qm0 rBQULnJDG9wJ351JriC/eXQEtSVWtqvn6fqwoTWkAbZ8Kn5W3PbRNeZu3ujrWk2uxRYnLcI6WSn qgZi2JVHCKqU8b57reNcHUcO8J1lFUnn/RevdiVJdoQcxVp24XL00pdU8nYKdrIl1jjA3khNjye 8Qz3AVfyOGoMEBPakdbbwPhJ2DxmcEEksJHGXKMN/CJzGGK479u0mjfffNEaHxA2nbJ/eedh744 VMth4+3S0URK2X/kWwYNLuppfqMUwDIGQoPpOAns6vF6H+kTloLUlw0Y6E8eZk9a8TqkQbhuBZ2 BuFxeDYhiFk0VTjIrWhMVwKo7Rp8rmKqB17ZV6Bbwx7ZN5H98qbEbYAf7alz8vl6Qmm66bwH5bV W1qDmRmckVynolgpLyckiIct9PgBFsbalh83pXucf2j0a9WsO1h+K/Vik3UlR9mnvEBpONkjxdD b2oUoBDj1Q0RWSg== 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: xSsekcDceSYWHZv_uDjC5yqGvoQ-v_Fu3z02FCXuCaM_1790961765 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1790961771-6D8D54E9-CB7FD559/0/0 X-purgate-type: clean X-purgate-size: 288 On Fri, 11 Sep 2026 15:36:27 +0100, Daniel P. Berrangé wrote: > These paravirtualized devices are relevant to virtualization > use cases. Reviewed-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:23:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:23:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439429.1657888 (Exim 4.92) (envelope-from ) id 1xCgyK-0001yt-1e; Fri, 02 Oct 2026 17:23:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439429.1657888; Fri, 02 Oct 2026 17:22: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 1xCgyJ-0001xc-PT; Fri, 02 Oct 2026 17:22:59 +0000 Received: by outflank-mailman (input) for mailman id 1439429; Fri, 02 Oct 2026 17:22:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgyI-0001tX-JK for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:22:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgyH-00GrM4-VD for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:22:58 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe85c-e002-0a2a0a5209dd-0a2a4505e088-18 for ; Fri, 02 Oct 2026 19:22:57 +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 6abfe834-4cb1-0a2a45050019-aa0a817c8f7f-3 for ; Fri, 02 Oct 2026 19:21:57 +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-527-op3WwH2ZNA2u0Cg8MOEiXQ-1; Fri, 02 Oct 2026 13:21:53 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CA7FC1955EAB; Fri, 2 Oct 2026 17:21:51 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E63161956086; Fri, 2 Oct 2026 17:21: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=1790961716; 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=9nIRzmOZNrJ9s+xcf4J8MYpSLOxpzXpuBIwo4NigH5A=; b=aY4Q5zgUAWGjJVQoU47vj49LXfxz43nlN8posKU86Ved9S1Rq5P8ux8IIM0wIinEdHx3FV A7WbgY3jGzzrkUml6o29cRDvFFm91WHIDDzW8nxMt1zj25yxa9okip6WvtVWZ0oQRLbOka EeEQqzrlYe/9RUHOfzJxpFsrlkrwmJo= X-MC-Unique: op3WwH2ZNA2u0Cg8MOEiXQ-1 X-Mimecast-MFC-AGG-ID: op3WwH2ZNA2u0Cg8MOEiXQ_1790961711 MIME-Version: 1.0 Subject: Re: [PATCH 12/28] hw/scsi: mark spapr and vmware SCSI controllers as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-13-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-13-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166120.3025252.9810140897534239421.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=373; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=bJJ3aIFsZ99ktF+Pq5lKTPnYoOPh8mqQDX2p00a8g08=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBaL7aPZEvnSAKIzO8UKS9uB5CuA5E9XGSZ n9yRIT/2ciJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5eNOEACCc2b2xlEhPjvdMWpeR8ZDcVVNGeP2txruwI553hlMp1/aJMpBohXCClMaLrnmLEp8HNt bFnHLcWB52W1+OG7AqqEoUAD+yBvSPlsDKLx7sdqxjMPnYMzMRNKEHkUwJ5sF0X23HNOPYpu3Pb gRSRYuiNijD4rYRxBfx2yF5sohNNV4O60QJWOLtpiKRkmiHiazE/+7W+rHt2Jvde6EPYyYUb33s P9lADxG9ryRqiOcFYbBLNdRre2PQr9x+OT14+vMhkRMpLrQ4l6G/YX2+ZAqgrtJUqddlWlyFsRc INAw2MPGIusoQ409eyJWo8e1D45xhU7SVLDG1DcLeykobHsLcpb8VCyDwBgQ8DCzSUhY+mdypUz 1A/oa/aovg+uSMOMNYFgviMxsh3QUaUJdfbzxC4TAyLlCzQxGNJcEHy6RXHnUTnaYil6yn9bGp5 kXYA2CVnZLbKNNQxHMQXBr8nzkPG6xfBoPpkecsB3c6nhBvQHFsQ9+F8oBN9iYPbD+l8fpi9MYY dORMvi2PUJ/Wp0KiBgMvoBnle648wr5EGqONsULUjk2fbiZmcy0/+YZl69HXtUdvJnzFmBaHqtj /zrZQsoSKDbIevferN3SLV8bKDPXOjlFBF1SF6FDUz6iU+anGOKbRWs3Y9g3efVtoKiA803JDS1 Ihl9jai5EMa1uoA== 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: c5aupW-PeKzvgtpsRwLkxboGPtJWWS3MK238aX7pOZE_1790961711 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790961717-736BD2A1-04F022A4/13/0 X-purgate-type: bulk X-purgate-size: 375 On Fri, 11 Sep 2026 15:36:11 +0100, Daniel P. Berrangé wrote: > 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. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:23:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:23:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439434.1657896 (Exim 4.92) (envelope-from ) id 1xCgyN-0002R6-7F; Fri, 02 Oct 2026 17:23:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439434.1657896; Fri, 02 Oct 2026 17:23: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 1xCgyN-0002Qr-3B; Fri, 02 Oct 2026 17:23:03 +0000 Received: by outflank-mailman (input) for mailman id 1439434; Fri, 02 Oct 2026 17:23:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgyL-0002Fj-GD for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:23:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgyK-00Dbr6-SA for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:23:00 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe839-2eae-0a2a0a5409dd-0a2a4507a19a-44 for ; Fri, 02 Oct 2026 19:23:00 +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 6abfe837-b4ea-0a2a45070019-aa0a857cd583-3 for ; Fri, 02 Oct 2026 19:22:00 +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-632-usuXcry6OqG5LrfvNwEreQ-1; Fri, 02 Oct 2026 13:21:56 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BAAE61954208; Fri, 2 Oct 2026 17:21:54 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id EE7B61800576; Fri, 2 Oct 2026 17:21: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=1790961719; 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=TH6G+K8UPoFw1AoYcty2EfdD2DLwTEBKK+pZWhxRZRE=; b=hG1FsY714rn06nt901CwfqqwDr8X2GLkFyzU2o0J9p8UjdtuDFQh7B10Bui5VxWKPhu6T7 90wNfQ3KeqRysDNC16RnpE2n9TE0oFqJBRFG5zPEYQastRZ82up+ciNElAnUBqmLiJO88N 6P3pjMQOCMDmjLmBo9RRZy10co8tJj8= X-MC-Unique: usuXcry6OqG5LrfvNwEreQ-1 X-Mimecast-MFC-AGG-ID: usuXcry6OqG5LrfvNwEreQ_1790961714 MIME-Version: 1.0 Subject: Re: [PATCH 13/28] hw/scsi: mark SCSI disk endpoint devices as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-14-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-14-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166121.3025252.17283916103111838508.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=342; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=CBX3rJrWsHrUC9wTg2DbZ/CA+ASB943BIbzUVX09LbQ=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gBuhkKlfH72B/SBYDXFmLPxwtygBpo9Lp8x a23S+v1kx+JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAQAKCRDa6OEJdZac 5aiFD/9o8bxclc+ql+a6Jus10ffIHZXap/Zoa9f183f4V9hoGTlZJjVdDGZ3Hc7jUvdbqCQGd8+ OtjHct1b3YGygsV+1Uc6d1G/eStSR5tM0Uh8Rsz7S3Z2pUXh7JBW5NPC4Ulks35vSrLT2TGBgnL xuESHM0d54klNY5ELuVU/Hmf6k33Qs7LIFppMnuIudLgJ5sfw4QBo5kuwluilflTkFeGkQ7vUuo y4XRCWZ9yo+VMG8BOt2tCS2zPkukOegIJPtghaQpiAZDxG0FfwseBd7Cd5lPoie0r0MXPk1DkHN 3dMmbhYWzrhfzXzcJ5T15KNHGu1OIAU47dVoZI6QTbaOIscmhCTfTagwfk5Mhy2I4BYRvnYbD0I hZtYmb9CHUjzCHa9Is3fB/U0SAuWJqTvSazgRKsLB+VKlLPF1CoUzG2JNZ4x/atL41awtFg9KZ4 nJJRp/BRUyCRoEBlCNnn0ysqm3MT8y+BkvWt9NK7OhLe3z6tvDwsCQ4GjBOn54kYhg1xRyrkY1R dWnt0VXTEbnKmPTbgPTQ8AFeJCQD+8YHfj2O/vl2IA7vGy/AhGAps9ZKtVOvv8PnN5Ym/K8S1CA CbIyDDWwTPccn/Cyr5vwabNSsWH0vGQ6p8QZFvJSH7LSvI3B6n/ZiEQF8Qo1eeooHwoyL+44hMj ckojHEWQalXWF8g== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: kkA3mVVIxoKWD9hdyLhNo-CRDrruKXoc0PgRSwEkJSo_1790961714 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790961720-A5AC0AE4-F6F8B93D/13/0 X-purgate-type: bulk X-purgate-size: 344 On Fri, 11 Sep 2026 15:36:12 +0100, Daniel P. Berrangé wrote: > All these devices can be used together with supported SCSI controllers > in a virtualization use case, so must be treated as secure. Acked-by: Marc-André Lureau -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 17:23:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 17:23:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439440.1657906 (Exim 4.92) (envelope-from ) id 1xCgyW-0003J9-ID; Fri, 02 Oct 2026 17:23:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439440.1657906; Fri, 02 Oct 2026 17:23: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 1xCgyW-0003Hj-Bk; Fri, 02 Oct 2026 17:23:12 +0000 Received: by outflank-mailman (input) for mailman id 1439440; Fri, 02 Oct 2026 17:23:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCgyV-00037y-4x for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 17:23:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCgyT-00D6mJ-G0 for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:23:09 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6abfe86a-8faa-0a2a0a5109dd-0a2a4508a864-4 for ; Fri, 02 Oct 2026 19:23:09 +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 6abfe840-f659-0a2a45080019-aa0a857c827d-3 for ; Fri, 02 Oct 2026 19:22:09 +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-8-lVaX_vJSOX6-g8URbd2QEA-1; Fri, 02 Oct 2026 13:22:02 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 851721954B20; Fri, 2 Oct 2026 17:22:01 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A41B01800351; Fri, 2 Oct 2026 17:22: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=1790961728; 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=1nTk5h441BlUCx/NZYxRViDuR1MPXYhtJViIj4n3aPc=; b=E8vhUd5fPa9P7pmD8DliruU77E2m4Ee8mdDri6zvrh91DTb3MXI/0UvYkCiz9ttoNjZpkH AHU08nL7AiBFaIPnsq8TI4KQxoqjNnMzcsraaxk9/X0Nmjn0VvlMVRU559ml/FMr6dvl7c xpAONUXoYNidfMvp1A5yqSLjhq27eVo= X-MC-Unique: lVaX_vJSOX6-g8URbd2QEA-1 X-Mimecast-MFC-AGG-ID: lVaX_vJSOX6-g8URbd2QEA_1790961721 MIME-Version: 1.0 Subject: Re: [PATCH 15/28] hw: define most common PCI types as secure From: marcandre.lureau@redhat.com To: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 In-Reply-To: <20260911143627.2743803-16-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-16-berrange@redhat.com> Date: Fri, 02 Oct 2026 21:21:01 +0400 Message-Id: <179096166122.3025252.2345560702508398440.b4-review@b4> X-Developer-Signature: v=1; a=openpgp-sha256; l=305; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=S5LgpxEbmDgv4nz2+w3MAekw+e8ZUjn4pTaaJOhl7I4=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqv+gClYQc6x9HdvVuTz3orxL5k19B0JWDKbBeO 2UgDlZ3atSJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCar/oAgAKCRDa6OEJdZac 5QCGD/4v3MxlW9xcT2gilvuqgxjpT1DxHwa00sDRs5T+gRudU6o1ntWoLU1qAc7JZwaJ/aqChOd IKsduJD+1Yalyd+onaPKwClZFmIj9njmtkFoJwrqiK0G5YZJDw5Lru0MvY97a1t2EuSQMVZfjim z2F+s4CJm7MsgLBZV4Uvcv7ON+jwC3kLFiMH1rl89BmM/FmVWCPE175WC2mdtLoj5xq6bt3+FY3 ZLEMvjIn0YLigHAmkKeWitG8N8SZuCCP8GK4EVxHTj3+b1sTbexIng7XhmDleJlUtMeHJf6gck2 BrknT+6fYa9FNDyuoI5kOPwGONw3mbBxpLSTcFWBsAKyAJZyaVjVVAzIk4B6Amki3NFeFde8ZFl 1bnaSYcMCZh7UAnNJDTvWTWWNJZkAJWG+uZVVoHI9YdB1hhkpI4qrz61UNvUy0vgvAz8BgIbSL2 fUgE1s76avvtH6uGlnp+tK68m/7haS/kJsSrQNw/03rkPBLsTNEdBVBGX1oF4d2NOOX7eLRkRBT S4kLfXZ/jIK232Bg2hpMqUEWvIxPbemtrDq/ofdByqfw1RiUvhLLH5UKUHjJWgUU7UkbN7taxj3 xYthEKHzY5c0A8E0thzpO8xoGF91S61FwW5b+VrOIDC9CycnIJWAuTzg8Ggx0/c70BXc7hzd34R 1AGq6NK7FV7PPiQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: usW13rGZnBexJtBakL0IxxVgNWC17CyNbxfvVhMGDhE_1790961721 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790961729-D6D4087B-9496FDFB/13/0 X-purgate-type: bulk X-purgate-size: 307 > Essentially all PCI infrastructure is in scope for the virtualization > use case, aside from the niche simba bridge. > You should exclude the CXL bits though, as stated on cover letter. Also questionable perhaps: xio3130, pcie_pci, pxb -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Fri Oct 02 19:15:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Oct 2026 19:15:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439557.1657913 (Exim 4.92) (envelope-from ) id 1xCij3-0000fa-2v; Fri, 02 Oct 2026 19:15:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439557.1657913; Fri, 02 Oct 2026 19:15: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 1xCij2-0000fT-WE; Fri, 02 Oct 2026 19:15:21 +0000 Received: by outflank-mailman (input) for mailman id 1439557; Fri, 02 Oct 2026 19:15:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCij1-0000fN-VN for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 19:15:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCij0-00H36G-Sf for xen-devel@lists.xenproject.org; Fri, 02 Oct 2026 21:15:18 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac002ab-2eae-0a2a0a5409dd-0a2a4502b584-18 for ; Fri, 02 Oct 2026 21:15:18 +0200 Received: from [74.125.225.98] (helo=mail-wr2-f34.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac002c6-6ca4-0a2a45020019-4a7de1628bb7-3 for ; Fri, 02 Oct 2026 21:15:18 +0200 Received: by mail-wr2-f34.google.com with SMTP id ffacd0b85a97d-48af9f88c95so76653f8f.0 for ; Fri, 02 Oct 2026 12:15:18 -0700 (PDT) Received: from ws-fedora.tail006fee.ts.net (cm-93-156-216-249.telecable.es. [93.156.216.249]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a166bfaf73sm14012525e9.4.2026.10.02.12.15.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2026 12:15: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: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=1790968518; x=1791573318; 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=7hzVLCLqTCo6ZZjXX7PS4ZOVN+xMW/Fn8WqC339I+g8=; b=eNtO3ZeIDQiQlmfQB8PdwqhJ1G3SYafc0Gf1kuy1Wva3m2zqExXGonywpj6xEQZuez f89O75Q98mJjSb7nsDZLHnlHgZA8VJayGECR1qpXtIii2ju4EilaqVzH+C0eaMb/Him3 7PHpta+APgRZ8nAJOPTxY6deuablVIblaOL+lfAAREM8RBhBfQe2kQKoXEB9L5jmB7c6 +w7s4Zsf7Iz3ypFk96yQnhjyKhDEQn+u27u0JiWFWSf0UIfXEY7mlnVWd151LBchs8N8 ca6w830YoLQyDPtoo/cP0x0Umw+3nO9gojAWd37PO1pYAqncA3nCoMAlw2k4afIRPEGf giWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790968518; x=1791573318; 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=7hzVLCLqTCo6ZZjXX7PS4ZOVN+xMW/Fn8WqC339I+g8=; b=u09I04SKK+LuwxGfGewQa1LxVHuzlor2IJJbetZ1oOqJ2/0MaXrSksBckMcFf/zW/q QJYhxYcoJnm3i2Wjry5IHqFRPNo3pOauiPV9mpl2/GdZOkAdbLlqfK1H8xsEK0oYRCk+ eRXn8BV53RUMhMKeKI0wjTGBncWNdO530klJ282jRm328e/NsM0mFwhUvlZ479TfOlmI K2b0Q+nIFzE/n+n6sNKJqD6o3pgmnzuFDLZzZBhLxgmYTGOQNS7hHLCh/c266sJlQxMb vrPduCQebnE8y5K2yUC5YOq3YpPC60YFwM22Z3JwvlJM5IeSsISEWI6Icn/989jsIbRG CaYA== X-Gm-Message-State: AFuF++m3tUymhiRFvG/5dEKPZNFLsnfmBAA3sawWgCwKhFHOh8O7Wymn NA5ghga/a8kLzIBOdwIIbGpFomMr81On3tfK3ihXNRR/jI53Nk4MLo7k3LbK6QDIrGM= X-Gm-Gg: AYBFou15HMUMHqZB0KYhlbwHaZUQFIw55goFjXC+4CWgQUNeyJZLTlQUqXdxS0pKh31 6cZfktyuFINXTIyIgb+mbU4OTq91LQRpRL9XPwewyfQbMCaDxBkqsfhMCoexpneFHR1vtM8NUkR NR5MR/zO6k7IUoUVP2pYgjsR5cNNBSef6G3gHYExnpKqBL5NaWuKVnMz3P3Z0gXnd2sH5E6uRQg 0HxSJ7JxM582M6xj7EPrIMddWmuWXu7kgfByaNurJoi2a33XzlGiz9oVSHwB4hISIGB3gtEXArv qTRd02ruObJD932yuWWILirs8YLh8kTuMRtKRUYxcJ1fms9eQtrDkxcPj9LC8Xo5+R/VQzAnqOx x7uA8uUwMFIEWHYvme2cgDBC0Z1N9wvtzgT6Gr8pYvJb+5At37bNSg2K4MTXckCrGgSjEpqTVyv EjOUNu9p/ckGTlnWns7G7iTnSJ9IBoomJqdS/D9q39kzPBT6f6/CLaebM7i1vg38faNuiTeeU1z xXwv7bjVOChjXtHZg3oKyXppH+AOXoo7PMA2JsuJ0ZhOD7pt+L544k= X-Received: by 2002:a05:600c:3b05:b0:49e:715d:95ca with SMTP id 5b1f17b1804b1-4a027561e0fmr62509815e9.13.1790968518152; Fri, 02 Oct 2026 12:15:18 -0700 (PDT) From: =?UTF-8?q?Gabriel=20Quint=C3=A1ns=20Souto?= To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, julien@xen.org, bertrand.marquis@arm.com, sstabellini@kernel.org, =?UTF-8?q?Gabriel=20Quint=C3=A1ns=20Souto?= Subject: [PATCH v1] xen/arm: validate non-common page-table ranges Date: Fri, 2 Oct 2026 21:14:18 +0200 Message-ID: <20261002191418.287819-1-gabi.qs.mail@gmail.com> X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790968518-F2AB52AC-BB20AB6C/0/0 X-purgate-type: clean X-purgate-size: 2497 On arm32, page-tables are different on each CPUs, although they share some common mappings. The xen_pt_update function assumed that only said mappings would be modified, but did not check this assumption. Add a range check to reject modifications to non-common mappings. Signed-off-by: Gabriel Quintáns Souto --- xen/arch/arm/mmu/pt.c | 36 +++++++++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 7 deletions(-) diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c index 621b47d..ad0d1e6 100644 --- a/xen/arch/arm/mmu/pt.c +++ b/xen/arch/arm/mmu/pt.c @@ -13,6 +13,7 @@ #include #include +#include #ifdef NDEBUG static inline void @@ -589,6 +590,29 @@ static unsigned int xen_pt_check_contig(unsigned long vfn, mfn_t mfn, return XEN_PT_4K_NR_CONTIG; } +#ifdef CONFIG_ARM_32 +static bool ranges_overlap(unsigned long start1, unsigned long size1, + unsigned long start2, unsigned long size2) +{ + if ( start1 < start2 ) + return start2 - start1 < size1; + + return start1 - start2 < size2; +} + +static bool xen_pt_range_is_non_common(unsigned long virt, + unsigned long size) +{ + unsigned long temporary_start = TEMPORARY_AREA_ADDR(0); + unsigned long temporary_size = XEN_PT_LEVEL_SIZE(1); + + return ranges_overlap(virt, size, + DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) || + ranges_overlap(virt, size, + temporary_start, temporary_size); +} +#endif + static DEFINE_SPINLOCK(xen_pt_lock); static int xen_pt_update(unsigned long virt, @@ -601,15 +625,13 @@ static int xen_pt_update(unsigned long virt, unsigned long vfn = virt >> PAGE_SHIFT; unsigned long left = nr_mfns; - /* - * For arm32, page-tables are different on each CPUs. Yet, they share - * some common mappings. It is assumed that only common mappings - * will be modified with this function. - * - * XXX: Add a check. - */ const mfn_t root = maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); + #ifdef CONFIG_ARM_32 + if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) ) + return -EINVAL; + #endif + if ( flags_has_rwx(flags) ) { mm_printk("Mappings should not be both Writeable and Executable.\n"); -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Sat Oct 03 07:18:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 Oct 2026 07:18:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1439698.1657922 (Exim 4.92) (envelope-from ) id 1xCu0b-0000wh-D2; Sat, 03 Oct 2026 07:18:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1439698.1657922; Sat, 03 Oct 2026 07: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 1xCu0b-0000wa-A4; Sat, 03 Oct 2026 07:18:13 +0000 Received: by outflank-mailman (input) for mailman id 1439698; Sat, 03 Oct 2026 07:18:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xCu0Z-0000wU-L4 for xen-devel@lists.xenproject.org; Sat, 03 Oct 2026 07:18:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xCu0Y-006vYJ-Iw for xen-devel@lists.xenproject.org; Sat, 03 Oct 2026 09:18:10 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac0abd6-8faa-0a2a0a5109dd-0a2a450a8582-46 for ; Sat, 03 Oct 2026 09:18: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 6ac0ac31-f2d2-0a2a450a0019-b9ff1c228be9-3 for ; Sat, 03 Oct 2026 09:18: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 1a100a0936a0003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 03 Oct 2026 07:18:05 +0000 Received: from Skynet-1 (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 80A7581DB5; Sat, 3 Oct 2026 09:18: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=kuhMXlzLQhzBkqyeUZIQiDM9y+82KwWx/ujm11Nry/8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=UNNRGC+/ZZWlHVpKtJBPEpIMlgw9tYXAeRReER31ZUYd9wgZ39gSush1Sk06Zb9twLuVcwXVd fyN9MbnPQuVaJipwfjBf+t3HuGSYSf4DHvL4DYBlvD50lKFBNodGqMbE7rGTqUnCexNC6yk0zoI lUIgwUm6Go1suvXmPyX2J7zPoXwj2u6ryxN3QyieubuRr/MH9JxVgooLZZkTlZg8WgJL+Hl5Oug eNbEUBsNTVjj1hvCM+xJL2y/tE2Kq6dv0a/fCA9gTgemhDbNZPjCx7HG/LZtMOt/S94Qa4uwMIG hTHfk/5Nx/SrVicqiAyZNt0WHEq7SD9A6AMzkPAq6/Dg== X-Zone-Loop: ca38c5e183fd368921df6943f3ad47bbde0e5e836044 x-campaign-type: default x-transaction-id: c06c0669-3c46-4e5f-bf3b-c9b2f401764b x-swg-uid: 01-c9b4bd64-35ea-48d0-9d6d-542ce6be78d8 X-Mailer: Sweego Message-ID: <1791011886.8631fc262581453bbf619ec5b2062170.1a100a0936a0003f66@vates.tech> x-swg-bid: 1791011886.8631fc262581453bbf619ec5b2062170.1a100a0936a0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross Subject: [PATCH] tools/libxenstat: don't lose all VIFs when dom0 has no Linux bridge Date: Sat, 3 Oct 2026 07:17:43 +0000 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.600.859a17acc0054a89.1a100a08e37.e03ae745e3f7e19f=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791011884603 X-purgate-ID: tlsNG-4011c0/1791011890-593C4CFC-0C8114A7/0/0 X-purgate-type: clean X-purgate-size: 2191 ---=Part.600.859a17acc0054a89.1a100a08e37.e03ae745e3f7e19f=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable xenstat_collect_networks() looks for a Linux bridge (a /sys/class/net/*/bridge directory) so that, with bonding, dom0 can be given the bridge's counters=2E When there is none, as on hosts using Open vSwitch (the XCP-ng default), routed networking or only libvirt's virbr0 (which is excluded on purpose), getBridge() leaves devBridge empty=2E strstr(iface, "") then matches every interface, and devNoBridge is just "p", so every VIF with a standard name (vifN=2EM, vifN=2EM-emu) takes the bridge branch instead of being attached to its domain=2E Every domain ends up with zero networks, and xentop shows NETS 0=2E Only take the bridge branch when a bridge was actually found=2E Fixes: 1fd93d4f8cb8 ("xenstat: Linux dom0 statistics for case we use netwo= rk bonding") Assisted-by: Claude-Code:claude-opus-5-5 Signed-off-by: Olivier Lambert --- tools/libs/stat/xenstat_linux=2Ec | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libs/stat/xenstat_linux=2Ec b/tools/libs/stat/xenstat_l= inux=2Ec index b60e3fdcab=2E=2E2a7d2f1a96 100644 --- a/tools/libs/stat/xenstat_linux=2Ec +++ b/tools/libs/stat/xenstat_linux=2Ec @@ -322,7 +322,8 @@ int xenstat_collect_networks(xenstat_node * node) =20 /* If the device parsed is network bridge and both tx & rx packets are = zero, we are most */ /* likely using bonding so we alter the configuration for dom0 to have = bridge stats */ - if ((strstr(iface, devBridge) !=3D NULL) && + if ((devBridge[0] !=3D '\0') && + (strstr(iface, devBridge) !=3D NULL) && (strstr(iface, devNoBridge) =3D=3D NULL) && ((domain =3D xenstat_node_domain(node, 0)) !=3D NULL)) { for (i =3D 0; i < domain->num_networks; i++) { --=20 2=2E53=2E0 -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.600.859a17acc0054a89.1a100a08e37.e03ae745e3f7e19f=--- From xen-devel-bounces@lists.xenproject.org Sat Oct 03 19:53:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 Oct 2026 19:53:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440094.1657932 (Exim 4.92) (envelope-from ) id 1xD5nT-0003RZ-2Q; Sat, 03 Oct 2026 19:53:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440094.1657932; Sat, 03 Oct 2026 19:53: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 1xD5nS-0003RR-Tf; Sat, 03 Oct 2026 19:53:26 +0000 Received: by outflank-mailman (input) for mailman id 1440094; Sat, 03 Oct 2026 19:53:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xD5nQ-0003RL-Bi for xen-devel@lists.xenproject.org; Sat, 03 Oct 2026 19:53:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xD5nP-00FZ18-MI for xen-devel@lists.xenproject.org; Sat, 03 Oct 2026 21:53:23 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac15d08-8faa-0a2a0a5109dd-0a2a4509deb4-26 for ; Sat, 03 Oct 2026 21:53:23 +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 6ac15d32-be1a-0a2a45090019-b9ff1c129015-3 for ; Sat, 03 Oct 2026 21:53: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a10353f83e0003f66.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 03 Oct 2026 19:53:17 +0000 Received: from ryzen.vates.team (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id F096981BA6; Sat, 3 Oct 2026 21:53: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=j+KXb/x5R1/0Pmx6JE5T/X5srzKoVU/jEE1dTUsXjVg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=r4KqyV57t/V5biU4fwUDhZxM/AcSGiJDUnXfjEoWnmb3gk8Pfuwi0EbWCg7evdIXMS8P96IG3 ngnd7emf0VPcvBjhxKh70rjNI+e4Z6gvovU8Ze9AANEwVWpq1s6MWquBBOxZpi6T0aPNGvseStL uO61DYDHjjrDvL1NLVI/jd5N4ZM00EMo26bDFyrDjMBovRt+QQcq+iDaqj9yh2c2Uu8/wqLzAyJ w4iZ1JeGrgjaG5Drcou+2yBPF3YTgMidWw6j/3CH1+QlKEyZObLA+4pGtthHlq8rSDuphRn4oa9 n2WP7KkCyEfGxOFSXxYlHi7m0GBaDEr1zhyNmR9jHfiA== X-Zone-Loop: 17c664dcae6a30fd6070a267adbd5e1c2be8deeab11c x-campaign-type: default x-transaction-id: 95aa0caa-db28-424c-9eaf-1b370694e48b x-swg-uid: 01-4ef930ad-ced0-4674-a76c-5868f902795e X-Mailer: Sweego Message-ID: <1791057197.8631fc262581453bbf619ec5b2062170.1a10353f83e0003f66@vates.tech> x-swg-bid: 1791057197.8631fc262581453bbf619ec5b2062170.1a10353f83e0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: jbeulich@suse.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, jason.andryuk@amd.com, xen-devel@lists.xenproject.org Subject: Re: [RFC PATCH v2] x86/ACPI: optimise C3 entry on AMD CPUs Date: Sat, 3 Oct 2026 21:53:10 +0200 In-Reply-To: <332fec64-31f0-48b5-8c86-163e81899310@suse.com> References: <1790796643.8631fc262581453bbf619ec5b2062170.1a0f3cc3da00003f66@vates.tech> <332fec64-31f0-48b5-8c86-163e81899310@suse.com> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.602.166c55b5ce43ba07.1a10353f46b.1238d118b573c425=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791057196143 X-purgate-ID: tlsNG-bad1c0/1791057203-3A4DB034-368E43BE/0/0 X-purgate-type: clean X-purgate-size: 1228 ---=Part.602.166c55b5ce43ba07.1a10353f46b.1238d118b573c425=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01=2E10=2E2026 09:14, Jan Beulich wrote: > Why the RFC, btw? It's my first Xen patch, and on staging it was only build-tested: I booted and measured it on the 4=2E17 backport only=2E I should have droppe= d the tag for v2=2E > Linux also deals with modern Centaur (VIA) and Zhaoxin (Shanghai) CPUs= =2E > We will want to mirror that too, provided we want to continue this > mirroring=2E Alternatively we could have Linux'es xen-acpi-processor > driver invoke acpi_processor_power_init_bm_check() before passing up > C-state info=2E That would imo be better overall, with one downside: Non= - > Linux Dom0-s would then need to follow suit=2E Noted=2E I'll leave the choice between the two to you and the other x86 maintainers=2E Thanks for committing it, and for fixing the attribution=2E Olivier -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.602.166c55b5ce43ba07.1a10353f46b.1238d118b573c425=--- From xen-devel-bounces@lists.xenproject.org Sat Oct 03 20:32:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 Oct 2026 20:32:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440123.1657940 (Exim 4.92) (envelope-from ) id 1xD6PB-0000k2-OJ; Sat, 03 Oct 2026 20:32:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440123.1657940; Sat, 03 Oct 2026 20:32: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 1xD6PB-0000jv-L4; Sat, 03 Oct 2026 20:32:25 +0000 Received: by outflank-mailman (input) for mailman id 1440123; Sat, 03 Oct 2026 20:32:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xD6P9-0000jo-B1 for xen-devel@lists.xenproject.org; Sat, 03 Oct 2026 20:32:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xD6P8-00G0g1-IJ for xen-devel@lists.xenproject.org; Sat, 03 Oct 2026 22:32:22 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac165d8-2eae-0a2a0a5409dd-0a2a4501d150-32 for ; Sat, 03 Oct 2026 22:32:20 +0200 Received: from [165.173.180.50] (helo=sender6-of-o50.zoho.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac16652-5984-0a2a45010019-a5adb432c02c-3 for ; Sat, 03 Oct 2026 22:32:20 +0200 Received: by smtp.zohomail.com with SMTPS id 1791059534769407.4085393419613; Sat, 3 Oct 2026 13:32: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=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding" ARC-Seal: i=1; a=rsa-sha256; t=1791059536; cv=none; d=zohomail.com; s=zohoarc; b=WsPDt3BSh7Cbx0ZKgUSSaKFRs4dR01oEWCoBPyp1fgOkZsAcpQBXt7OVeaNU3v30hoF6/jW1J7ziydf8OABRFEG7auBVL0ufBoDZgtQ0SEOAAnruHp3n8w5WzLfgb/KR7rpb1WmsYi/RLLhRjw9uQUrmfmSUR/8H4MOEkstQlP8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1791059536; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=QxLauvXIkEfQdv0YGMb5jRArVzzhaW9TyHftDpWOvbg=; b=hr3FFakmlYSvynPbXRS/lIIpPEXUXUyDp9otSrtWlzzFGZubN3sUi4iMlE7RrVeh0BqAk4KFy7fhjh6hhCL/QDKGwlh4otxpDZQ5YkNfYH/zWcpiSnYPF473aQngdr6oJ5ys3ay83qJc9fFWb8FWpha4eXWdJ9J34CXlADjIa0U= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@apertussolutions.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1791059536; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=QxLauvXIkEfQdv0YGMb5jRArVzzhaW9TyHftDpWOvbg=; b=KlBEfaWFG6+fvY3pL66i+LqEXkmMXqFggWYY7hI9bgjnhbSjajUHrXn0ysXy9k2b V42VVuUcnoiSAgUUGNhwQyvmCCeQTcAJk25QtQ8tQF2Axur/EfPuTUoLb3casdpfAu9 jW8NNTBtVWKL4TZSAlfsrzUOQT5CMhZ8UtGscGYw= Message-ID: Date: Sat, 3 Oct 2026 16:32:15 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v1] xen/xsm: flask: restore sidtab state on policy load failure To: Sergiy Kibrik , "xen-devel@lists.xenproject.org" References: <20261002092556.542986-1-Sergiy_Kibrik@epam.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: <20261002092556.542986-1-Sergiy_Kibrik@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-purgate-ID: tlsNG-d62444/1791059540-1F86F757-C59E1D8F/0/0 X-purgate-type: clean X-purgate-size: 2073 Hey Sergiy, Apologies for not getting a response on the first send, been a bit preoccupied with preparing customer delivery. On 10/2/26 5:26 AM, Sergiy Kibrik wrote: > Error path of failed sidtab_map() leaves global sidtab in shutdown state and > from that point system is unable to allocate new SIDs in sidtab_context_to_sid(). > To restore sidtab state new function sidtab_activate() is introduced, which only > resets shutdown flag, rewinding effect of sidtab_shutdown(). > > Signed-off-by: Sergiy Kibrik > --- > New function is not strictly required, this also can be achieved just by > doing sidtab_set(&sidtab, &sidtab), but this way we would rely on its > undocumented internal behaviour. > --- > xen/xsm/flask/ss/services.c | 1 + > xen/xsm/flask/ss/sidtab.c | 7 +++++++ > xen/xsm/flask/ss/sidtab.h | 1 + > 3 files changed, 9 insertions(+) > > diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c > index 35ad1034ca..f5cee1e0b0 100644 > --- a/xen/xsm/flask/ss/services.c > +++ b/xen/xsm/flask/ss/services.c > @@ -1427,6 +1427,7 @@ int security_load_policy(const void *data, size_t len) > if ( sidtab_map(&sidtab, clone_sid, &newsidtab) ) > { > rc = -ENOMEM; > + sidtab_activate(&sidtab); > goto err; > } > > diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c > index 69fc3389b3..5d1653cd02 100644 > --- a/xen/xsm/flask/ss/sidtab.c > +++ b/xen/xsm/flask/ss/sidtab.c > @@ -314,6 +314,13 @@ void sidtab_set(struct sidtab *dst, struct sidtab *src) > SIDTAB_UNLOCK(src); > } > > +void sidtab_activate(struct sidtab *s) > +{ > + SIDTAB_LOCK(s); > + s->shutdown = 0; > + SIDTAB_UNLOCK(s); > +} > + I think calling this sidtab_activate is a bit misleading, as activation is really the success path of security_load_policy. Perhaps sidtab_cancel_shutdown? If you're not opposed to the rename, then on respin, Acked-by: Daniel P. Smith From xen-devel-bounces@lists.xenproject.org Sun Oct 04 10:26:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 Oct 2026 10:26:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440282.1657951 (Exim 4.92) (envelope-from ) id 1xDJQO-0007vS-Hg; Sun, 04 Oct 2026 10:26:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440282.1657951; Sun, 04 Oct 2026 10: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 1xDJQO-0007vG-C6; Sun, 04 Oct 2026 10:26:32 +0000 Received: by outflank-mailman (input) for mailman id 1440282; Sun, 04 Oct 2026 10:26:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDJQO-0007vA-0b for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 10:26:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDJQN-004Ezj-Dw for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 12:26:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac22953-bab6-0a2a0a5309dd-0a2a4503d802-40 for ; Sun, 04 Oct 2026 12:26:31 +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 6ac229d5-fae8-0a2a45030019-aa0a857cdff3-3 for ; Sun, 04 Oct 2026 12:26:30 +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-442-TlmWfE4SMRG4aIAdNINZ6Q-1; Sun, 04 Oct 2026 06:26: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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1C571195FCD0; Sun, 4 Oct 2026 10:26:25 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 10A8630000E5; Sun, 4 Oct 2026 10:26:23 +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=1791109589; 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=gXJO7banlPNaWvQpKTCq/gTnTWMwrS/tryCeQOKlZyU=; b=XDIaAWc+7qsS7peUCW4sbYWoYtY/ND8znTYuLNiRi1W1L8I3VijoUVM5zmszA6hQaUMDuD dwmq6uRiDEfphjG6ukG4bX0ZZSIu601OXTQjQeHvz6cDmS22DTa/opP2y8GzYgA6cgOZpa Tcpm3YIOTlng+eP6KtrdwTXry261wSU= X-MC-Unique: TlmWfE4SMRG4aIAdNINZ6Q-1 X-Mimecast-MFC-AGG-ID: TlmWfE4SMRG4aIAdNINZ6Q_1791109585 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Sun, 04 Oct 2026 14:24:01 +0400 Subject: [PATCH 47/63] hw/display/xenfb: fix 24-bit pixel read in BLT macro MIME-Version: 1.0 Message-Id: <20261004-issue-4560-v1-47-ccbef537cbeb@redhat.com> References: <20261004-issue-4560-v1-0-ccbef537cbeb@redhat.com> In-Reply-To: <20261004-issue-4560-v1-0-ccbef537cbeb@redhat.com> To: qemu-devel@nongnu.org Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Pavee Hui , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org X-Developer-Signature: v=1; a=openpgp-sha256; l=3382; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=zPjYLwlhuI6ZQ9yvZpvzI4AvCIHAUk5mFH0I3g1TZjg=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqwikk7HNFX7afDB5DABXPRs5rbBsffV7svWPPq UApayLs6IyJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCasIpJAAKCRDa6OEJdZac 5VqYEACkAao9kDJ5SI46eSyZjrxK9IdIbft6+yD34ZFDLvDEv+vce2KlbA2KR6V6FdnBWVkpani y+AmaJlYRP26Wq7AzshR6YcwhrH0xyiIkMlYWM7UQfdTloxhYB7dHwunCUO55ipjfCgaDsTq0QX MpoScVV8xMOfWXYcaAnCatguc7lHg8+/Ztd7VWVfPETHFUbTT7hFLgD3zHayjDaIFJofKLLQvDS Y9w1XQWd4mHmPQknUbjivURRm76xk3DTsxydFtVCOTU7cwTOayfxZkfAZr29yUc+wHigK+y2znA 2nJZGiAbEXGjEfxhvn0+1MKdVDc4NI3qT9rqyF8qGZ6jDtzLkZbrGFgZWuRuuJU8DsA7bfHH1en MFS1orVH17BL0/taT4k/t7FeMb0ZBQefvm63AkNvlDN09C67AO3q+arVNSe+SFsLqOJ6JFSiVej GrfYmZNFvGoNJ+Ze2bZ5ReS5tVhgIAyDR/+futNGDV/lTc+ObDtkfaA/m5TPWJ146IP1q7hvk+Q xVPQOKwNdXnPlWCB0xSh3ILGyNUeqOjgHAc+RZEketKHRQqy3Xz+l8/5P2q14MM1ungyK2bn8Bb 8P4WoFNg24hImRnQLlsBe2a98IAWdxkuMImDHLTjD+0DXDFqQlu+ZLkA8IzntM5xWATdS7hhfQ8 AdjVZ3y2eGM5VZw== 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: ttdl83Wqw9cPQ74srvhpgQj5-vIN0sj_aD6lTkhcI7U_1791109585 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1791109591-6C2E04E9-E3F0B58F/0/0 X-purgate-type: clean X-purgate-size: 3384 For depth == 24, each pixel is 3 bytes, but the BLT macro was using uint32_t as the source type, reading 4 bytes per pixel. The last pixel on the last row would read 1 byte past the framebuffer. Read 24-bit pixels byte-by-byte instead, so the access stays within the 3-byte pixel boundary. Reported-by: Pavee Hui Signed-off-by: Marc-André Lureau --- hw/display/xenfb.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c index ae302b217fe9..10785e6843ae 100644 --- a/hw/display/xenfb.c +++ b/hw/display/xenfb.c @@ -560,8 +560,13 @@ static int xenfb_configure_fb(struct XenFB *xenfb, size_t fb_len_lim, return 0; } +static inline uint32_t read_pixel24(const uint8_t *p) +{ + return p[0] | (p[1] << 8) | (p[2] << 16); +} + /* A convenient function for munging pixels between different depths */ -#define BLT(SRC_T,DST_T,RSB,GSB,BSB,RDB,GDB,BDB) \ +#define BLT(SRC_T,DST_T,READ_PIX,RSB,GSB,BSB,RDB,GDB,BDB) \ for (line = y ; line < (y+h) ; line++) { \ SRC_T *src = (SRC_T *)(xenfb->pixels \ + xenfb->offset \ @@ -584,7 +589,7 @@ static int xenfb_configure_fb(struct XenFB *xenfb, size_t fb_len_lim, const uint32_t GDM = (~0U) << (32 - GDB); \ const uint32_t BDM = (~0U) << (32 - BDB); \ for (col = x ; col < (x+w) ; col++) { \ - uint32_t spix = *src; \ + uint32_t spix = READ_PIX(src); \ *dst = (((spix << RSS) & RSM & RDM) >> RDS) | \ (((spix << GSS) & GSM & GDM) >> GDS) | \ (((spix << BSS) & BSM & BDM) >> BDS); \ @@ -593,6 +598,8 @@ static int xenfb_configure_fb(struct XenFB *xenfb, size_t fb_len_lim, } \ } +#define READ_DEREF(p) (*(p)) + /* * This copies data from the guest framebuffer region, into QEMU's @@ -612,18 +619,18 @@ static void xenfb_guest_copy(struct XenFB *xenfb, int x, int y, int w, int h) switch (xenfb->depth) { case 8: if (bpp == 16) { - BLT(uint8_t, uint16_t, 3, 3, 2, 5, 6, 5); + BLT(uint8_t, uint16_t, READ_DEREF, 3, 3, 2, 5, 6, 5); } else if (bpp == 32) { - BLT(uint8_t, uint32_t, 3, 3, 2, 8, 8, 8); + BLT(uint8_t, uint32_t, READ_DEREF, 3, 3, 2, 8, 8, 8); } else { oops = 1; } break; case 24: if (bpp == 16) { - BLT(uint32_t, uint16_t, 8, 8, 8, 5, 6, 5); + BLT(uint8_t, uint16_t, read_pixel24, 8, 8, 8, 5, 6, 5); } else if (bpp == 32) { - BLT(uint32_t, uint32_t, 8, 8, 8, 8, 8, 8); + BLT(uint8_t, uint32_t, read_pixel24, 8, 8, 8, 8, 8, 8); } else { oops = 1; } -- 2.56.0.rc0.29.g47ce80527c56 From xen-devel-bounces@lists.xenproject.org Sun Oct 04 21:06:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 Oct 2026 21:06:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440519.1657959 (Exim 4.92) (envelope-from ) id 1xDTOu-0003BS-9m; Sun, 04 Oct 2026 21:05:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440519.1657959; Sun, 04 Oct 2026 21:05: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 1xDTOu-0003BK-4Z; Sun, 04 Oct 2026 21:05:40 +0000 Received: by outflank-mailman (input) for mailman id 1440519; Sun, 04 Oct 2026 21:05:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDTOs-0003BE-Oh for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 21:05:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDTOr-000cZF-N6 for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 23:05:37 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac2bf73-e002-0a2a0a5209dd-0a2a450bc472-24 for ; Sun, 04 Oct 2026 23:05:37 +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 6ac2bfa1-b7e8-0a2a450b0019-a237832f84e6-3 for ; Sun, 04 Oct 2026 23:05:37 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 389754EE0056; Sun, 4 Oct 2026 23:05:37 +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=1791147937; b=5VsbfVqh1MMxnAS/zbCXjv3s4V5hzs4Ulj+5qUgjBjp6DQNOl+TZqEB0+DvZI6xc+hQ5 2b4dhHL7j54XoWwj7rtJpS1u6Xb/cfXwOEmZ9RCn+rN2SaJgypSbaxlpX8I7mJo6Jvsvy Q4MmMPJ4lpYSIDPPasyrx0LLT1QlsknA7ELxMIH3rL5w8wLW+N7ilWoMPB+N1Y7YMl+PR VtymFPZ11rLW/liw5SWgr3MN77dy0dUhinGJ9V4V9QbCSnBB7rbrK/u9htQIxWbsR2/Ap z1KXHMUsrp5gRxTDK/2jYPNuAORo6M+DQHMpd4BsywZ+8tbMlFAxEqM0n27k1f5dT9zD5 QoHnmIEXbjXuTYcBYOfAcDG6Qyg0aSAbEZO+UhIECi9fIqee35yVqU6xcqPCYxTacgnfh J/hmqGYckRgFBUZ13OWFxLayoEAEzsFnW+jSm40bFINGSFJN4Gm2VufcNSHaolrmdkEuG UZNmiuqV1jeAFOg3hQxBcgVjdpvbp6/v1PAOsZ4gxAVeu0g3EnDBvQ74gjsZnwsNUBDha U/ksD6m+Rao+frqQyi0DXNpftgsZ1joloQI2TOOBxe6FXh45W3LCMIADC7ju33j1BeSK1 0bx4nCVFDh962bqT0XGGfA1LVqsnjl5m8D3w2SXLDy6vyQdIYqfMT+60Osyf9gw= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1791147937; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=pIXzNPGV2mEcYZM8LYJWcaxfMFv2rTyU1Gv2VXgAUSc=; b=pmXSezW1aqtxmQK9toKOxacDRQiv/x4TofRswArvKmxHFaf853svXyWDFxrvBnna+Sc0 wxQq1hRZ7Dj6OUgwyyrMIrOjhpE54MTeqjBAcwPnPYh++jEfzzblH2AqCgtaLTKubrXgQ o2AvK4PdAO6mpnKrF9VDQIDWr9VeS15V4Z9BX7YosEXkZq7IcLLPZtJbDSSRdsBW3i68q JE9g1A//feghByP1jt0eHrnUe7iM7lwsSwJ+NMxAF9CzZH9T+a84e7LP8HG5sq4LpPCo4 OsnX2J9/j5sLVTZURl0ejM3lQ2s4IUkYNBph+IAaEMTKM7PiGJvXtS/+74Y/5E2iLMHWA /7fv2G+0xVbjLhbcaTrrvSG7z6E8hpNznHFSt63b7LLB6Ix61/YHuQjT4RIvjCUyrix0o BYjIgv95nvxbQfPgiu7Go5hSUrfWL03Fz/grpKMrf/4Mls01Bs5eVz/e899wWQWy/XNto ETiILTwiwQ/OWJ4m7haZHQlLmRMVuthASNrudZ40oGo9+LTOihSNS4jQiFUH1Uu1jt5rb WgOUTvGHzEkCMRjOfI4IQxkJ43395MhuqJiNNsFgY9HrzaqF+r1jomUSnuRcP+JvMAgoh 6q6bN3vkBbd/zYazuG4X3hsvt0eeh1usEndE51Phf3glBl7XvzBkeWBNGy296t0= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Sun, 04 Oct 2026 23:05:37 +0200 From: Nicola Vetrini To: Andrew Cooper , Jbeulich Cc: Dmytro Prokopchuk1 , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8 In-Reply-To: References: <4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro_prokopchuk1@epam.com> <0a286fe9-2133-4f28-8fab-59f4e51d1484@suse.com> <446354d93ae04a07b86d7293705d7e46@bugseng.com> <0373fcc0-5bc9-4140-a2c9-52a31c7e42b5@suse.com> <2a8557d7ba88e95ec75148ff180ae0a0@bugseng.com> Message-ID: 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-42698a/1791147937-AACDF9EA-46789270/0/0 X-purgate-type: clean X-purgate-size: 3558 On 2026-10-01 14:39, Andrew Cooper wrote: > On 29/09/2026 6:52 pm, Nicola Vetrini wrote: >> On 2026-09-29 17:11, Jan Beulich wrote: >>> On 29.09.2026 16:56, Nicola Vetrini wrote: >>>> On 2026-09-29 15:40, Jan Beulich wrote: >>>>> On 29.09.2026 11:03, Dmytro Prokopchuk1 wrote: >>>>>> bsearch(), memchr(), memchr_inv(), strchr(), strpbrk(), strrchr() >>>>>> and >>>>>> strstr() all accept a const pointer/object but return a non-const >>>>>> pointer >>>>>> to the matched element or byte, matching their standard C library >>>>>> interfaces. The const qualifier is deliberately stripped so that >>>>>> callers >>>>>> searching a non-const object get back a mutable pointer to it. >>>>>> Fixing >>>>>> this would require changing the public API, so document these uses >>>>>> as >>>>>> deviations instead. >>>>>> >>>>>> Update docs/misra/rules.rst to note that this class of double-use >>>>>> library functions is deviated on a per-function basis. >>>>>> >>>>>> Signed-off-by: Dmytro Prokopchuk >>>>> >>>>> When I prepared my 11.8 series [1], I was wondering whether we need >>>>> to >>>>> go >>>>> as far as deviating these. Since we now uniformly take gcc5 as >>>>> minimum >>>>> baseline, there is (at least in theory) the option of using >>>>> _Generic to >>>>> cover the dual-use. One question there is whether Eclair would >>>>> recognize >>>>> such - Nicola? After all, looking at e.g. glibc's implementation, >>>>> the >>>>> functions themselves remain "unsafe" there; it's a macro wrapping >>>>> them >>>>> which puts the lost qualifier back. >>>> >>>> Could you provide a concrete example? >>> >>> From glibc 2.43: >>> >>> # define __glibc_const_generic(PTR, CTYPE, CALL)    \ >>>   _Generic (0 ? (PTR) : (void *) 1,            \ >>>         const void *: (CTYPE) (CALL),        \ >>>         default: CALL) >>> >>> while the declarations still are e.g. >>> >>> extern void *memchr (const void *__s, int __c, size_t __n) >>>       __THROW __attribute_pure__ __nonnull ((1)); >>> >>> (and hence the implementation still - necessarily - casts away >>> const-ness). >>> >> >> Ok, will look into that > > We are going to have to deviate the implementation, even if we are > using > _Generic() to force const-correct behaviour from the callers. > > We could duplicate the functions, but there's a different rule about > that.  We can't use ELF aliasing tricks because that breaks software > type-hashing techniques for control-flow integrity. > Yeah. The internal cast is clearly still signaled by ECLAIR, regardless of the surrounding context. That being said, the trick is quite nice and it would actually be a stronger argument for a deviation in my opinion: it mitigates the risk pointed out by the MISRA rule at the callsites. It is also true that the C23 signature is a lot nicer in terms of typing [1]. There's a slight friction with MISRA C Rule 23.5 ("A generic selection should not depend on implicit pointer type conversion") from MISRA C:2012 Amendment 3 for the non-const input case, because the type of the controlling expression could match either alternative depending on the context, but that's not a strong concern (Advisory rule, no associated UB). [1] https://en.cppreference.com/c/string/byte/memchr -- 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 Oct 05 05:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 05:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440469.1657968 (Exim 4.92) (envelope-from ) id 1xDb4L-0002VH-M9; Mon, 05 Oct 2026 05:16:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440469.1657968; Mon, 05 Oct 2026 05:16: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 1xDb4L-0002V9-HJ; Mon, 05 Oct 2026 05:16:57 +0000 Received: by outflank-mailman (input) for mailman id 1440469; Sun, 04 Oct 2026 19:04:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDRVK-0003qW-Dq for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 19:04:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDRVJ-006aRJ-RA for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 21:04:09 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac2a2ef-bab6-0a2a0a5309dd-0a2a4507986e-28 for ; Sun, 04 Oct 2026 21:04:09 +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 6ac2a329-b4ea-0a2a45070019-4a7de18cc727-3 for ; Sun, 04 Oct 2026 21:04:09 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-4a1722c37c9so1326335e9.3 for ; Sun, 04 Oct 2026 12:04:09 -0700 (PDT) Received: from LukeW.mynet ([143.58.214.168]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a0280c8bb0sm306875715e9.11.2026.10.04.12.04.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Oct 2026 12:04: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:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791140649; x=1791745449; 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=Ugn7qb3Ihe6pRVSsU144ndfnHVeChYDf+vJI65Hlci4=; b=R6HhQnqYfNXnJxKJW5Ke2+vewNkdwK5fDP0ELwaxVUQ/k4XSL0+ox7ldqhMao7SF+a OSJC3qIikK0oJqsMl6UxIbaIPIaa+BOYflDRogg7lgFifF0ojIoMtHxCvBFFKT5zK++H TVeWhO+NoGlWOkyBvcp4AHRZlLiKwYpK5GgjQLjWlAha78byU0rL2XtENvVeGctwmjJR +ODoiK2L/s8b68e11WicZEuWOb4cz4DH1qRaK3MDacmgI5Qb4VQOmpe+NrAqFoGu7P9O aLLuXX2ozIWLQ7mt0FxFTISZ0afDEtjEPd2fUUL1VVIQOJsSvGqwmzOPmJnbjX33FfEN wc3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791140649; x=1791745449; 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=Ugn7qb3Ihe6pRVSsU144ndfnHVeChYDf+vJI65Hlci4=; b=zIH93/FF43V6aX15+62dBxxmj/WtRIHhm6CFaj7uwQvnegS95t6rBVXqpgoXfSocBC fT7xKxUNMKEZVAjM7pYXz7jTHfD30S7DBrEi7fwJi1lTeWbFJ6JlnCQLAzJNmHioNY+V UVLCMR81vZEiIt0n8LPHlkBHcSmpgr4OlQsg+6zOt5G5rjAzmcjspaFrALm6YlHEJ4Nk dU4vH4PARU7Ud1zCnEIdWIe5OHNydzGo2ocw5jeDE6pIJPYwYTBdqz/jODk4JQUB+48X BKNfIxwpkX2za4B22hc7z/hEhX/574Y+ZUl2X+kHeJca4APGniNAMb6/CQ6Ff7vIJmaa PVqw== X-Gm-Message-State: AFuF++lWZpsBLebOoeGdC0V2uQIPEaN+3nDa0nXr4WUC/WPt5ZMolQac hM8tClebZzPaAweY1MmR7uSW15eUMxbA2ws6UbcA37048MGX1KS+S+Ge7N0WBdM6KxonXQ== X-Gm-Gg: AYBFou27fldMp7eTbQu/kQ/uRE1636fpXKylfu+eqrgX+O5YxE9EyJrwHbttNSNVxYQ cBg1UYMj3utVE10KSfEpgxriOZsc6F7L7sBf8whqTnqPwDJE+NfL9q1Q7OQtU/+Dn4qeQ42my9R TYt97SpN4qfhvaacYdsBDuXF7yDVSQfIHbAJbMe/NY+ZJ18IblbQUP+h2I260d8nfdBEEhLsnTg QNoRFWQtT5YkVHkuO2twpUBLkzTGlU2V5xed9HlnrJQ1RG4QzhW8+tQbzxQ6Zxmo+E5nq6AltkV SClmtctur8btIaF+cxzV+OOfE+EU61RdsJt2nH4s/h8a4T28HPPKqM83aWUJFPNkbOdinOxuu+r 7NhsI4YOKgB5dRbM/AgPvawR9lfiXOaXOrpXnXb1cVAO7v8G22MZocdWaVUr39YJLUuEarxDVof suc2Y/F0gLr1AA/sC1YXrWAyvPzalayOBbCbHbOsTQ9zG5e/VQXntFdTyr3pdKjDJkW39ZZg== X-Received: by 2002:a05:600c:46d0:b0:49c:fa21:1c84 with SMTP id 5b1f17b1804b1-4a0275a28d5mr154397295e9.25.1791140649040; Sun, 04 Oct 2026 12:04:09 -0700 (PDT) From: Weiqi Wang To: xen-devel@lists.xenproject.org Cc: roger@xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang Subject: [PATCH] xen/pdx: fix merging of a range contained in the previous one Date: Sun, 4 Oct 2026 20:03:57 +0100 Message-Id: <20261004190357.29254-1-coolhaoyt@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1791140649-364DBAE4-8B95E713/0/0 X-purgate-type: clean X-purgate-size: 4185 From: Weiqi Wang When sorting and merging overlapping ranges in pfn_pdx_compression_setup(), the merged range is set to end where the second range ends. If the second range is fully contained in the first, this truncates the first range, and the tail of it is then neither compressible nor translated correctly. Keep the end of the merged range as the maximum of both ends. On x86 the ranges come from the SRAT memory affinity entries, and overlapping entries for the same node are tolerated with a warning by the NUMA code. The caller's subsequent coverage check catches the truncated range, so the effect is that PDX compression is disabled with a "RAM region ... not covered" message rather than memory being mistranslated. Add a test case that fails without this change. Found with the ESBMC bounded model checker. The counterexample was confirmed by running it natively against the unmodified code. Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation Signed-off-by: Weiqi Wang --- Notes: Also seen in a real boot: the hypervisor alone under QEMU (pc, 8 GiB), built from defconfig, with no -numa and a hand-built SRAT passed with -acpitable. Memory affinity entries, all PXM 0: [0, 3G) [4G, 9G) [5G, 6G) [1T, 1T+1G) The third entry lies inside the second. The NUMA code prints "overlaps with itself" for it and accepts it. Without this patch: (XEN) PFN compression using lookup table shift 23 and region size 0x200000 (XEN) range 0 [0000000000000, 000000017ffff] PFN IDX 0 : 0000000000000 (XEN) range 1 [0000010000000, 000001003ffff] PFN IDX 32 : 000000fe00000 (XEN) PFN compression disabled, RAM region [0x100000000, 0x23fffffff] not covered With it, the same output as without the third entry: (XEN) PFN compression using lookup table shift 28 and region size 0x400000 (XEN) range 0 [0000000000000, 000000023ffff] PFN IDX 0 : 0000000000000 (XEN) range 1 [0000010000000, 000001003ffff] PFN IDX 1 : 000000fc00000 tools/tests/pdx/test-pdx.c | 12 ++++++++++++ xen/common/pdx.c | 5 +++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c index 4de8d43d86..2b5bea07a0 100644 --- a/tools/tests/pdx/test-pdx.c +++ b/tools/tests/pdx/test-pdx.c @@ -87,6 +87,18 @@ int main(int argc, char **argv) }, .compress = true, }, + /* Range contained in a previous one. */ + { + .ranges = { + { .start = 0, + .end = (1UL << MAX_ORDER) * 1 }, + { .start = (1UL << (MAX_ORDER * 2)) | 0, + .end = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 4 }, + { .start = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 1, + .end = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 2 }, + }, + .compress = true, + }, #endif /* PDX compression, 2 ranges covered by the lower mask. */ { diff --git a/xen/common/pdx.c b/xen/common/pdx.c index e7e16e193e..23655ef3bd 100644 --- a/xen/common/pdx.c +++ b/xen/common/pdx.c @@ -393,8 +393,9 @@ bool __init pfn_pdx_compression_setup(paddr_t base) (ranges[i - 1].base_pfn + ranges[i - 1].pages) ) continue; - ranges[i - 1].pages = ranges[i].base_pfn + ranges[i].pages - - ranges[i - 1].base_pfn; + ranges[i - 1].pages = max(ranges[i - 1].pages, + ranges[i].base_pfn + ranges[i].pages - + ranges[i - 1].base_pfn); if ( i + 1 < nr_ranges ) memmove(&ranges[i], &ranges[i + 1], -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 05:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 05:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440471.1657970 (Exim 4.92) (envelope-from ) id 1xDb4L-0002XZ-SK; Mon, 05 Oct 2026 05:16:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440471.1657970; Mon, 05 Oct 2026 05:16: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 1xDb4L-0002Wn-PH; Mon, 05 Oct 2026 05:16:57 +0000 Received: by outflank-mailman (input) for mailman id 1440471; Sun, 04 Oct 2026 19:04:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDRVR-0003rA-J7 for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 19:04:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDRVQ-0006n3-C8 for xen-devel@lists.xenproject.org; Sun, 04 Oct 2026 21:04:16 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac2a30c-e002-0a2a0a5209dd-0a2a450bcf20-22 for ; Sun, 04 Oct 2026 21:04:16 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac2a32f-b7e8-0a2a450b0019-d155dd34dc02-3 for ; Sun, 04 Oct 2026 21:04:16 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48c5358fc28so385639f8f.0 for ; Sun, 04 Oct 2026 12:04:16 -0700 (PDT) Received: from LukeW.mynet ([143.58.214.168]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b38104602sm20231561f8f.26.2026.10.04.12.04.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Oct 2026 12:04: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:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791140655; x=1791745455; 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=+0EkOyBSqfwlelDGlGE8QtC8Dmz3E2dIr4FDjMU3FTk=; b=VKR6VVZ4/itmp97djkEo4DJToRyL2VHzvm3V4zouQzCVVGP2F5CvqE5NOppd+glN47 /SwKuy1M2QvLgzjr/geSrSFCwh8g09a7NQKKVrh6HDEiYFawNHOZa1y/Ewh+NVPvbLaE kGfxo5MHDfubc8c3NFKMRmDmJ3prmEk99/lMlyjqCm4eE3jgGfErGKGq3JmzxH0rJBfK VDtFcQO0vHbg1dfKuLL4n1OCiDH+TvFuU9usNH0mrlEvkUqM4hwbCP4HQXgAeoMmGxeZ /oTRjZeUE0QfgSWgC9xizqpJ2/CiM4N5Z+UwOPiHUfGaoyr1saiO7LC1Sd6mMiyVUlXi PqJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791140655; x=1791745455; 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=+0EkOyBSqfwlelDGlGE8QtC8Dmz3E2dIr4FDjMU3FTk=; b=0AiTL02xN+uJjV+ZGPIyjILXOd6NHWSLTt43GMy5APosBta3/DUozN6Geswc0LkUMy zHZFw0ufl6u99FLOpTs0/hkfs1qToAaPrhXFIg8Fnc8SsGPismzFOmtSyw6oxraR5F2M dgz6n7dGhnWzjuIRXVMM1SEL40h5r+yLe8mg+caEuC6g8wwbIQ3PRafXYEzsczeztSxP hAfzUyreBy4ujsjOt7DY79z6ruqzdxJD2ai5UFXghwTU5ajLprw7GPZWE3occv9p7/5c qHyI9kMMxjBEeAZELot5wQx728E8JHXlXe8px4Q9L9cRESAoC3U7VV8/BZ+7hclMqewh s7gQ== X-Gm-Message-State: AFq9FYJklwDgHu46po+1dqXHTFdqlPBqAPoUOX/XCX6jQIJ5D1hp9suX LNKZ8Sycw3Gg5jVvbz5HCSrQdI+jwCp8iHf6QViVk8ceCals1J2oIFrzpU7j+5P5tcHC/A== X-Gm-Gg: AYBFou0Y7Zrv6bePazViqj7DNWaIAPEoWhda03R26yueoAomCtc1ls367Oz6aipJKj6 Vzp1IVw5wemL62t4LlguJm2GyrjURsgZA+NCjMVuowEYxiNwN3AvyN6NF1pCt8lVrfnWujNC78Z O6FmLcM5XnzpYlM/A0K4JHMTIt0JOaRaNWKt5oJdiMW42KIuwLUzIHFszY8B5G4Pk7yPYAz7mCK 0u4Q1Tr79y0L07/XhputC92aHoux0bopKbET5ensNUnZHaPUcAr3o00b0MM8EYUP5rLUI6YwrCi P4UN8R9UZ3Sm8hhHE3eKQhQBfV6nU9SMjLZGn/bY6SXb0TtB3wyoATxSWUzpi4FiehMrFfhtZyO Eie00Od1v3pRYAFpL2KafHImYnbwVpKq59gHxZN9XonH28EtS3TNkYzYtUSqIosgIU0y64V1bGX zakbqJHXrzWkyXJeUIqyy0sc5Ssv8HHAxQ4umWBr7FWTZ8y9ybglID2Ttb1XtMu+3hUxBKXg== X-Received: by 2002:a5d:5d0d:0:b0:487:b4a:3f54 with SMTP id ffacd0b85a97d-48c4800336amr9297340f8f.29.1791140655281; Sun, 04 Oct 2026 12:04:15 -0700 (PDT) From: Weiqi Wang To: xen-devel@lists.xenproject.org Cc: roger@xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang Subject: [RFC PATCH] xen/pdx: reject regions crossing a lookup table index Date: Sun, 4 Oct 2026 20:04:09 +0100 Message-Id: <20261004190409.29276-1-coolhaoyt@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1791140656-AA4DB9EA-42CBB4B2/0/0 X-purgate-type: clean X-purgate-size: 5725 From: Weiqi Wang pdx_is_region_compressible() only looks up the table entry of the first page, and checks the region against [pfn_base, pfn_base + pdx_region_size). pfn_base need not be aligned to the table index granularity, so that window can extend into the next index, which belongs to a different range with a different offset. A region whose tail lies there is reported compressible, yet its last page on its own is not, and translates through the wrong offset. Also require the first and last page of the region to use the same table index. This can be reached from the coverage check in srat_parse_regions() when an e820 RAM range is not covered by the SRAT ranges, which is the case that check is meant to catch. Found with the ESBMC bounded model checker. The counterexample was confirmed by running it natively against the unmodified code. Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation Signed-off-by: Weiqi Wang --- Notes: RFC because this was discussed when the offset compression was reviewed. In the v2 thread [1] Jan asked whether pdx_is_region_compressible() is correct when a region crosses a lookup table slot boundary. The thread concluded it was not an issue, on the basis that pages contiguous in MFN space are also contiguous in PDX space. The reproducer below is a case where that does not hold for the code as merged: the region is reported compressible, its last page on its own is not, and that page round-trips to a different PFN. The ranges are as srat_parse_regions() would see them. The RAM range is not covered by either SRAT range, which is the situation the coverage check in srat_parse_regions() is meant to detect. Built from tools/tests/pdx like test-pdx-offset, on staging (e4da182973) plus patch "xen/pdx: fix merging of a range contained in the previous one": region [0x75757ffef9, 0x8122007e00) compressible: 1 last page compressible: 0 last page: pfn 0x8122007dff -> pdx 0x2122047dff -> pfn 0x2d7ee07dff With this patch the region is reported not compressible, and srat_parse_regions() disables compression. 8<---------------------------------------------------------------------- /* Build like test-pdx-offset, e.g. from tools/tests/pdx: * gcc -D__XEN_TOOLS__ -DCONFIG_PDX_OFFSET_COMPRESSION \ * -I../../include -o repro-window repro-window.c * (after generating pdx.h as the Makefile does). */ #include "harness.h" #include "../../xen/common/pdx.c" int main(void) { /* Two SRAT-like ranges, in PFNs. */ pfn_pdx_add_region(pfn_to_paddr(0xdffffe0000UL), pfn_to_paddr(0xe000000000UL - 0xdffffe0000UL)); pfn_pdx_add_region(pfn_to_paddr(0xc5cde0000UL), pfn_to_paddr(0x4cd7000000UL - 0xc5cde0000UL)); if ( !pfn_pdx_compression_setup(0) ) return puts("compression not enabled"), EXIT_FAILURE; /* A RAM range not covered by either, as srat_parse_regions() checks. */ unsigned long s = 0x75757ffef9UL, e = 0x8122007e00UL; printf("region [%#lx, %#lx) compressible: %d\n", s, e, pdx_is_region_compressible(pfn_to_paddr(s), e - s)); printf("last page compressible: %d\n", pdx_is_region_compressible(pfn_to_paddr(e - 1), 1)); printf("last page: pfn %#lx -> pdx %#lx -> pfn %#lx\n", e - 1, pfn_to_pdx(e - 1), pdx_to_pfn(pfn_to_pdx(e - 1))); return pdx_is_region_compressible(pfn_to_paddr(s), e - s) && pdx_to_pfn(pfn_to_pdx(e - 1)) != e - 1 ? EXIT_FAILURE : EXIT_SUCCESS; } 8<---------------------------------------------------------------------- Other callers that rely on the same answer are mem_hotadd_check() and the EFI ram_range_valid() check. I have not run those paths. One behavioural change to check: with npages == 0 the new condition compares against pfn - 1. The callers I looked at never pass 0. Model checking (ESBMC, 2 SRAT ranges and 2 e820 RAM ranges, all free below 2^40 PFNs, the srat_parse_regions() coverage check modelled) finds no accepted RAM page that fails to round-trip with both patches applied. It also finds no layout where the coverage check now rejects what setup accepted, with RAM equal to the SRAT ranges. This is bounded to 2 ranges. The existing tests in tools/tests/pdx pass in both mask and offset mode. I have not reproduced this in a boot: the layout needs RAM near 2^51 bytes, which I could not set up under QEMU. [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg194095.html xen/common/pdx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/common/pdx.c b/xen/common/pdx.c index 23655ef3bd..52928faa15 100644 --- a/xen/common/pdx.c +++ b/xen/common/pdx.c @@ -324,7 +324,8 @@ bool pdx_is_region_compressible(paddr_t base, unsigned long npages) unsigned long pfn_base = pfn_bases[PFN_TBL_IDX(pfn)]; return pfn >= pfn_base && - pfn + npages <= pfn_base + pdx_region_size; + pfn + npages <= pfn_base + pdx_region_size && + PFN_TBL_IDX(pfn) == PFN_TBL_IDX(pfn + npages - 1); } static int __init cf_check cmp_node(const void *a, const void *b) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 05:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 05:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440564.1657977 (Exim 4.92) (envelope-from ) id 1xDb4M-0002bB-6O; Mon, 05 Oct 2026 05:16:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440564.1657977; Mon, 05 Oct 2026 05:16: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 1xDb4M-0002ar-1Q; Mon, 05 Oct 2026 05:16:58 +0000 Received: by outflank-mailman (input) for mailman id 1440564; Mon, 05 Oct 2026 02:15:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDYEu-0001vP-2h for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 02:15:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDYEs-007D9q-Qp for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 04:15:38 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac30849-e002-0a2a0a5209dd-0a2a450ba642-0 for ; Mon, 05 Oct 2026 04:15:37 +0200 Received: from [74.125.227.140] (helo=mail-pj2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac30793-b7e8-0a2a450b0019-4a7de38cca69-3 for ; Mon, 05 Oct 2026 04:12:37 +0200 Received: by mail-pj2-f12.google.com with SMTP id 98e67ed59e1d1-398beb616f5so443174a91.1 for ; Sun, 04 Oct 2026 19:12:36 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:7020:baaa:df0e:eada]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3a78e61386csm9241660a91.17.2026.10.04.19.12.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Oct 2026 19: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=20251104 header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i="@isslab-korea-ac-kr.20251104.gappssmtp.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=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1791166355; x=1791771155; 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=F8BtH1wOi3R0dL1LEJcbfIDWWZE0ydiC1A3fSU2odtA=; b=pKUoOnUsO9YtHu7NdYNrRck9SIdOSJWPeN7WzH48x9njEf6/Qpczhel7v67NjAYv5+ YsiY73BWWOk5w9/iUwjFSe6EQokqXC/Bwti/IgY2pPXHwNiPmQZhLJLoqI+eitoDCOpZ NGYwo1Mgg757XB6ih4u/FMoTOAAY9gYBX5viYh1QwT6e/8oe0CoOAmOy44Soc3Lm6dNQ j9V7ZZHxHZvcsrmEL4AWFKZTlO47oUtkX9mcmZy+EREcMl6t//TXYLxW1AUhvUb2o+5L rKQlyXVm397RJrU0e6Ha5rPhF/e5v7EGYyfuF4JUkd5gxqqJj+INdScRdj3BnVVdoUGT oH5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791166355; x=1791771155; 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=F8BtH1wOi3R0dL1LEJcbfIDWWZE0ydiC1A3fSU2odtA=; b=sX15l8UbvJ5eFObakA/EkscYl4PsG/eDiluXr758D/oBe/pmss1Yli+t0BDbaQK4gG keweqnsVBAIFmTmM+bqqbhaUrCaDpz9AadtovhixIE/NRXjOmnuDtJ4zM/tkbV9nZKEB uLjtjpYpa7BzEeNDgIXt+M0lre3UPF/PtVcsLpAgBnu7uuLmgAjC2kQtGIUOAsR+3KYN bhMtXj0+Hp4rSosF2Rsev/KQ9SdjvoehSlp2WL6y3y63ocnDNOjlPdpB3Lw3RcFT4iVF lXL23LJ/tDI2hzMWUlalk7PCi8YLiK1XSyhOvm6sq/lrBfzW29wZ48b8AgUerVIBNbML v2fA== X-Gm-Message-State: AFq9FYIohrlLLga4+ESOy76CnldpjwnJ5zNCIG1Om06BuYEbQGf2LUl+ N0R07z3+BIIy3Vq6n+0gFIMQmaHGGrQU3baTPrT70pxOOlAXlFrQd+SzHyCcHBxZ6W4= X-Gm-Gg: AYBFou3j6LoCEmDRgWrt53277uJWsOAcreoJKed5Nwmobn1Bvv6HG1EHisFPdWkE9Lb zBVz4dxPn/NIVp27qJYV93sWeytWpuNIqLJ/R4/ur2td3YpuH71DFEVe3n/ZHWL+3fOCLJAhJHX aCNsybc8sXmOHogmBI9PqqjSp4LEOabKrGs9vSAr7ovrabD3LCktFG63ZerWPCEofaqiDvyLSfJ +5c8pjO9ECg2IL3NRTvu+nryhsI68djuK96CmxB2KxFo1foRQ46JfOjd/218rA83FrBtCs4bMDb zoc/yxTEN8rN8SCIUISfoDzd+qzgBHaXjrSy5bAsu1Rpc2oIm8l9ukY37N7STXblH2ho7G/abcL qLSrYnypgnglBTCg4YyUHgsBe64P0mE7VVSLKjaxAWVM6zcDpOmQHIKA+18sLnncZnl9k91Hp68 yMtY3Z+r4L2+a5j8UCSyxPHfFreuFgoyABP2vYUg5mEFQtsQOyRNbQ67CNmCSqMwVaUNKohMysI TkItM09O0NwfXBcjkYBig== X-Received: by 2002:a17:90a:701:b0:3a6:d2ac:74ce with SMTP id 98e67ed59e1d1-3a6d2ac75d9mr3440094a91.19.1791166355134; Sun, 04 Oct 2026 19:12:35 -0700 (PDT) From: Yehyeong Lee To: Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , v9fs@lists.linux.dev, linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org, stable@vger.kernel.org Subject: [PATCH] 9p/xen: validate the response size from the backend Date: Mon, 5 Oct 2026 11:11:55 +0900 Message-ID: <20261005021157.207947-1-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1791166357-190CD9EA-E4BD49AA/13/0 X-purgate-type: clean.bounce X-purgate-size: 3213 p9_xen_response() takes the length of an incoming response from the ring -- the first field of the 9p header, which the Xen transport reuses as its framing header -- and uses it to advance the consumer index, but never checks that it is at least the header size or no larger than the number of bytes the backend has actually produced. A malicious or buggy backend can post a response whose size is smaller than the header (for example 0). The consumer index then never advances, so the response work re-reads the same ring contents instead of making progress. In testing this raced with the teardown that the malformed reply triggers and dereferenced a freed p9_client: 9pfs 9pfs-0: Wrong req tag=ffff BUG: kernel NULL pointer dereference, address: 0000000000000060 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5 #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: events p9_xen_response RIP: 0010:idr_find+0x4/0x10 RSP: 0018:ffffbf5d80063de8 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa229c21195a0 RCX: ffffa229c2400000 RDX: ffffa229c11c2200 RSI: 000000000000ffff RDI: 0000000000000050 RBP: 000000000000ffff R08: 3fffffffffffdfff R09: ffffffffffffffff R10: 3fffffffffffdfff R11: ffffffff87a60e80 R12: 0000000000000050 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000100000 FS: 0000000000000000(0000) GS:ffffa22a7661c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 000000003ac34002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: p9_tag_lookup+0x2b/0x90 p9_xen_response+0x17c/0x2e0 process_one_work+0x16a/0x3a0 worker_thread+0x172/0x2e0 kthread+0xdd/0x110 ret_from_fork+0x18b/0x240 ret_from_fork_asm+0x1a/0x30 Modules linked in: CR2: 0000000000000060 ---[ end trace 0000000000000000 ]--- Reject a response whose size is outside [sizeof(header), queued] before using it, matching the validation the backend already applies to incoming requests. Fixes: f66c72bea129 ("xen/9pfs: receive responses") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- net/9p/trans_xen.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index f9fb2db7a0663..685523be16f0a 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -200,6 +200,14 @@ static void p9_xen_response(struct work_struct *work) masked_prod, &masked_cons, XEN_9PFS_RING_SIZE(ring)); + if (h.size < sizeof(h) || + h.size > xen_9pfs_queued(prod, cons, + XEN_9PFS_RING_SIZE(ring))) { + dev_warn(&priv->dev->dev, + "bad response size %u from backend\n", h.size); + break; + } + req = p9_tag_lookup(priv->client, h.tag); if (!req || req->status != REQ_STATUS_SENT) { dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 07:05:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 07:05:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440588.1657994 (Exim 4.92) (envelope-from ) id 1xDclS-0002pl-HY; Mon, 05 Oct 2026 07:05:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440588.1657994; Mon, 05 Oct 2026 07:05: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 1xDclS-0002pe-Ee; Mon, 05 Oct 2026 07:05:34 +0000 Received: by outflank-mailman (input) for mailman id 1440588; Mon, 05 Oct 2026 07:05:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDclQ-0002pY-6h for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 07:05:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDclO-00BLBw-Ve for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:05:30 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac34c30-bab6-0a2a0a5309dd-0a2a4501ab56-46 for ; Mon, 05 Oct 2026 09:05:30 +0200 Received: from [210.118.77.12] (helo=mailout2.w1.samsung.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac34c39-5984-0a2a45010019-d2764d0cf7d6-3 for ; Mon, 05 Oct 2026 09:05:29 +0200 Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20261005070529euoutp02459e45710f21251dc7cb1ff0e4225fd8~bkEshCAH_2592325923euoutp02N for ; Mon, 5 Oct 2026 07:05:29 +0000 (GMT) Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20261005070528eucas1p18d16ec6ecc4e879d0adc66538122132c~bkEsU7ZkM1887318873eucas1p1T; Mon, 5 Oct 2026 07:05:28 +0000 (GMT) Received: from AMDC4653.digital.local (unknown [106.120.51.32]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20261005070528eusmtip1b88e4c060af8fd0102f58eef95fae4dd~bkErlAe2r2672226722eusmtip1G; Mon, 5 Oct 2026 07:05: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=mail20170921 header.d=samsung.com header.i="@samsung.com" header.h="From:To:Cc:Subject:Date:References" DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20261005070529euoutp02459e45710f21251dc7cb1ff0e4225fd8~bkEshCAH_2592325923euoutp02N DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1791183929; bh=LI1PY/lp2Uaq3ccGVqctwJ7GhEhUeqzl4hfjynZeaG8=; h=From:To:Cc:Subject:Date:References:From; b=IUkx1HNDA0Ce0WVEr0ao5DI7gy0CMBPsbPTzPoH85+3oggsJMvxhJOxmMxm36/r28 Js3UdcmTu5NNN2QVFUR7zJwIdhN9iflz37cpmw4aOb55MYN4sZJqCGFLJwdqHBP8bV dBD4t3FwZKIO32AV80IxRIAyj0Zx1bC2v7SJR89E= From: Marek Szyprowski To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: Marek Szyprowski , Robin Murphy , Christoph Hellwig , Petr Tesarik , Andreas Greve , James Dingwall Subject: [PATCH] swiotlb: fix default_swiotlb_limit() for non-growable default pool Date: Mon, 5 Oct 2026 09:05:17 +0200 Message-ID: <20261005070518.1590097-1-m.szyprowski@samsung.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CMS-MailID: 20261005070528eucas1p18d16ec6ecc4e879d0adc66538122132c X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20261005070528eucas1p18d16ec6ecc4e879d0adc66538122132c X-EPHeader: CA X-CMS-RootMailID: 20261005070528eucas1p18d16ec6ecc4e879d0adc66538122132c References: X-purgate-ID: tlsNG-d62444/1791183930-1FC69757-A942B5BE/0/0 X-purgate-type: clean X-purgate-size: 2041 Commit ad96ce3252db ("swiotlb: determine potential physical address limit") changed default_swiotlb_limit() to return the maximum physical address that could ever be used by dynamically allocated pools, so that the value stays constant when CONFIG_SWIOTLB_DYNAMIC=y. However, io_tlb_default_mem.phys_limit is returned even when the default pool cannot grow, e.g. when swiotlb_init_remap() is called with a remap callback. This breaks Xen dom0 on x86: pci_xen_swiotlb_init() passes SWIOTLB_ANY and xen_swiotlb_fixup(), so phys_limit is set to the top of dom0 memory, although xen_swiotlb_fixup() makes the default pool below the 32-bit boundary. xen_swiotlb_dma_supported() then rejects 32-bit DMA masks, even though the bounce buffer is perfectly usable by such devices. Return phys_limit only if the default pool can actually grow, otherwise report the real end of the default pool, like in the !CONFIG_SWIOTLB_DYNAMIC case. Reported-by: Andreas Greve Reported-by: James Dingwall Fixes: ad96ce3252db ("swiotlb: determine potential physical address limit") Closes: https://lore.kernel.org/xen-devel/f74668db-52fd-4575-8372-7bfdf10d62ac@a-greve.de/ Cc: stable@vger.kernel.org Assisted-by: Claude Opus 5.5 (1M context) Signed-off-by: Marek Szyprowski --- kernel/dma/swiotlb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index aa2f1c4588b9..5edea93ec635 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -1844,10 +1844,10 @@ 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; -#else - return io_tlb_default_mem.defpool.end - 1; + 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 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 08:17:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 08:17:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440606.1658003 (Exim 4.92) (envelope-from ) id 1xDdt5-0005hS-SP; Mon, 05 Oct 2026 08:17:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440606.1658003; Mon, 05 Oct 2026 08:17: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 1xDdt5-0005hL-PY; Mon, 05 Oct 2026 08:17:31 +0000 Received: by outflank-mailman (input) for mailman id 1440606; Mon, 05 Oct 2026 08:17:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDdt4-0005hF-Sx for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 08:17:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDdt2-0081Na-Ew for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:17:28 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac35d12-bab6-0a2a0a5309dd-0a2a4501e802-2 for ; Mon, 05 Oct 2026 10:17:27 +0200 Received: from [40.93.194.5] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac35d12-5984-0a2a45010019-285dc2058e5a-3 for ; Mon, 05 Oct 2026 10:17:23 +0200 Received: from PH7PR12MB7113.namprd12.prod.outlook.com (2603:10b6:510:1ec::8) by SJ2PR12MB7964.namprd12.prod.outlook.com (2603:10b6:a03:4cf::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 08:17:18 +0000 Received: from PH7PR12MB7113.namprd12.prod.outlook.com ([fe80::2104:fa11:f054:7dc]) by PH7PR12MB7113.namprd12.prod.outlook.com ([fe80::2104:fa11:f054:7dc%5]) with mapi id 15.21.0451.022; Mon, 5 Oct 2026 08:17: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=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=shcHRq3HcW3Euw9ZvIgPvUQ8VRd7faWLxLVBn7LoieXG61p0+iNs+r02xn8hy00yk3h+SUnJm7JJxXUzeZrIqzmB76PeB62ziFfKb7pHT+tXAGGktEWFQRW6SkLTua05HpkM3Li9TZHQC3XESHizseVLMRBsEeRUhjFCI1H0FA4bAgeHFqbBLDGSsNS1458Lk+1ZGGLyFjc+R27rZ7ToqCA8URodWjaQs8usp/qmkHbcbN8Uugau04sQ+YltO+jIJQlKPfvs6nb5xDSwrfXYeCppnnwXpLXBPCMPeF3foMcKRotuHTP0dUNWBJunyQg/D9hyHZmM9KVaNTZVIe07qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NwoWrD37V+KAFa1vAt3giR6sOXXiADq5chZq4oMWEMg=; b=QLstHEqH3biL/5wu/x0NCLHDa0efUtuXsYDBm2HK8EQg8p8HKE64bWofNGeJLH+9GNB2UkODdRKm7Tn9CcU8qZSE/Kpxai1Mzo0ZjVZnx2g1JLSFF4jUZv95HqZHiHE4ket8dSYn1Hex4HPyfsGACia7k7JDE/+3Fm9bLuv8vwfGCqZowl4/VSlgbnwqBGfAFI4tkaAqW98nUc1LO5IDa4pIupuG2lnNmSSgJgtHhITWK8BRrkUYwzOVciE3Y5XOCbccMdpDUxjQquzDCjM8CikihGnX1mNyT8Tv2L0CjFOtS6GeyZA2MdQt1X9fmVJhGPe7PF+e06d4/Scba58HtA== 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=NwoWrD37V+KAFa1vAt3giR6sOXXiADq5chZq4oMWEMg=; b=UofhNG36yLlaEqXGHHzKPTtNI4OZ7jvXuV7MASULRcFUQMgjCUU2CZz8j7xjo7jqqlCBdIYnzGGKRwxZydzSL8RKQQLf6eTdBf48YS/egeKt2h4E1aNK6eI8EIT2txtWVrXoZBS7183qRoEGs1XdSUX5gOl/nJGZUxIJJXtbH6M= From: "Miccio, Luca" To: Xen-devel Subject: OOO Luca Thread-Topic: OOO Luca Thread-Index: Ad1UoczsW00ZEttDeU6QxqgKziCZ7Q== Date: Mon, 5 Oct 2026 08:17:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAA6q8bMoVTdAQAAAAAAAAAAEAAAABCos0a2ZTFLnbz85VmOR9s= x-ms-traffictypediagnostic: PH7PR12MB7113:EE_MeetingMessage|SJ2PR12MB7964:EE_MeetingMessage x-ms-office365-filtering-correlation-id: 81d48bda-736f-45ff-b697-08df22b91267 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|38070700021|11063799006|56012099006|10067099003|18002099003|8096899003; x-microsoft-antispam-message-info: lXvSerABzbzFsj+hMOy1M4RL2wfivIRDbsga4FRveWqEgU+dyMbzgzuE/i5pe36ujDZNuTqW4w1KTzJAHsXQ8dQdT34TntnwdeX0xqpn9CWABMtUBkXn2Lxh7uNlrw01iqkmSIeCbPqgj1p2LCTRVlFywXAP1EjWtDWElPvBhdo36IuJKsXckx8vJbnFKrEKYX7SvGyRHzFJgGMxc1agEGu9BMpiQsHT/Uc0ARD6Z4lMhFxU3OYFqwQF/YhApFHgIqDNot4fbj/woytbtI6GPXqAhDO64uke0wx9ptwlrWNLxnXKRb6nRKxsS8cq7jN43TSTAi/8tW3EG0yAp1wfhxtr6LuMx5vXeeyPxkz7wSJjg0pmIEbWVsqkG6Ltd2vXe5JVEmrWhAvfcBnO0jabwuy8P2x98Kf4c0uXDXFjy88BGApnbd11Leh4QdtPnPynwK+aXadAARg27ZHSu5Nlew== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:ro;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB7113.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(38070700021)(11063799006)(56012099006)(10067099003)(18002099003)(8096899003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?EPoN6mHdrMc7oTjkyqaIsmWti9eWNW6+8KVXgHoOt0bKk4veq9mOVYYway?= =?iso-8859-1?Q?CJ8o7vvsXkX88m1nIVLP885f0fHxBPXl4q4ixwGV3RYiF6jjeW7DeT2YLX?= =?iso-8859-1?Q?BeVQz3hCUJpY4Xz5Q9OFAoyooah+pZrAJ7fXaihYFnJ4ztpB/co3hSUxij?= =?iso-8859-1?Q?UkFGnsBLdlHVEt0yjqFWSPDiCGHhg8hsCZqhYQd2I4ktLuo2V/84/FZkQ9?= =?iso-8859-1?Q?Fhj63H5HoFMwruBp7w/pp8kGLfxel2kDkoF38vpB7GaXZx3GU3QDGS8dV1?= =?iso-8859-1?Q?+LrSN2rnRTvkcjusWIZUQR4WtkUWh2VrObnNNYN8wuhhQ5kcCvw/JTsUCe?= =?iso-8859-1?Q?6waCr7gN/e+nfmSP+v4sPgo+zMKHIZZV3pslC4f8q/3ZC+/VOl4y9+qeeW?= =?iso-8859-1?Q?7PAu004tevqWv64ygc9wIRUl2v90unrN3zHK6CbpQiLd38Q8n8bFK35PqN?= =?iso-8859-1?Q?/QIpvPuyIwWWRouqKw4yfQMgaRHYkm+I6akHOJ87AiFAEmaBuwBPvJI7zd?= =?iso-8859-1?Q?FqAFeP2xMYat8VeMvAfIXDICfMGYH1ODlITxwtvsjuOLx8S7Y+bnMvELX7?= =?iso-8859-1?Q?AAskr+oQKjoqC/zj/SCaOvDKnehqhM7J5AVM0rQdAQaNYJde+KLumY9pfA?= =?iso-8859-1?Q?O0+SGcUXaZYyQxMa3ueQYqdjj2afGQsF1GdEF+eVNcaJyzfTzgZH+kg+K/?= =?iso-8859-1?Q?B/NRXDfqLqstY+Yo6R0vafEMECA/mCTEoCHqxOFXGT0WgQKrtKKXUbmlnt?= =?iso-8859-1?Q?zVVh1XtbStTrX0OqwhHFm6WaDtugWzxMefulebrWcBBXUm/L1RbyEw4hLp?= =?iso-8859-1?Q?JEpDORCsY2mSHQ+rZyIBZYRJAkW2QhIdArVI3ZbtCwdl0XdC5Rxc0aTgLD?= =?iso-8859-1?Q?viYcw6kC6isvDE+k8TFNN4K7+rronJLMOen8wBUghahDumKkSAQO4Kc2A1?= =?iso-8859-1?Q?gWDnvH6OCxTsMPhBtXFsjTnmk19b9zfeeF4aHTlpVGcK4GbrsNS5zMJ1T9?= =?iso-8859-1?Q?BMZRCAM0Pxf9ZOwVfNZFrVzYrSGScPYcqVLoQ+g+I/UbLxyJ8r+ctp6EAL?= =?iso-8859-1?Q?kYdazKrfW0sENpDGfrHd+rSNjj6AXwD8dImA4UZQWibiDeCAcPwVN1iQef?= =?iso-8859-1?Q?2w1LnbyyqFTyJQBCA+6kioyZ17FYKivgdIKUWGMpkN36MKHrT7yCP7IdqR?= =?iso-8859-1?Q?sg1L+2XD2wj/H5qY8AIe7Sw8lxwWMLqrD3GWk9xgVbnm/y3CRhOnAsDjkF?= =?iso-8859-1?Q?TzYFHvu35cvStMZeasJ77XfkmpKc+KSOSYvVBX2GfhsBgFUX4ykF4l62Rw?= =?iso-8859-1?Q?6mh9FdDqGMin+twAQ2u3IuD6W21URU0v9MzkcZnw16Avln+ABPgCgebdPp?= =?iso-8859-1?Q?0m+h2XesuH2e0cgAg4SjO1Ew1fbx5fhmwGprQ8dWmpQ19W06cZDkL7fIm+?= =?iso-8859-1?Q?tqAn6r+M+RnvnNCM+KmtMoVDlHrkaiZ3WSDCBhOhYlTMBdNd75KrjaZVxa?= =?iso-8859-1?Q?Gr6F2uSlUVl4qn3BQbMEzCZrkY9wEAXoutje2QdZFV4c1riQh9gIjZZJrm?= =?iso-8859-1?Q?ZH0jHde2f3gFqPJr18EpWkq+5Og+N3g8nzqB14+mvyrQ7SMVIRJ569HvaH?= =?iso-8859-1?Q?YpmoeU9My+3G5TVjYYl58kPZg6/g3a5AtUJTLwwgcHlxL23DC6Q1+cB+OM?= =?iso-8859-1?Q?Pfj0KAitxGPKtEJPRZUmsIEYm5CLoGVqiNJ2nRt2Mr+DXCZbb0QiirfePT?= =?iso-8859-1?Q?gN/c0UPEn2YybP+Sd51H38RCF7tZZlXJo0XMkfNK06vwqa?= Content-Type: multipart/alternative; boundary="_000_PH7PR12MB7113449E03644C735BDB77ADEA962PH7PR12MB7113namp_" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB7113.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81d48bda-736f-45ff-b697-08df22b91267 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2026 08:17:18.2907 (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: O0K3q4av+lIK1IVXJgknrHl3NtgaSMqvsPRI2Ad29yfT4aLSLhim7LEAdHOcR5iJADjJMVisXCApd4JhZT8lUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7964 X-purgate-ID: tlsNG-d62444/1791188243-BE867757-3A361196/0/0 X-purgate-type: clean X-purgate-size: 2582 --_000_PH7PR12MB7113449E03644C735BDB77ADEA962PH7PR12MB7113namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_PH7PR12MB7113449E03644C735BDB77ADEA962PH7PR12MB7113namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_PH7PR12MB7113449E03644C735BDB77ADEA962PH7PR12MB7113namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpXLiBFdXJv cGUgU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAw DQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZ O0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9G RlNFVFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN T05USD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5J WkVSO0NOPSJNaWNjaW8sIEx1Y2EiOm1haWx0bzpMdWNhLk1pY2Npb0BhbWQuY29tDQpBVFRFTkRF RTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NO PVhlbi1kZXZlbDoNCiBtYWlsdG86eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQpERVND UklQVElPTjtMQU5HVUFHRT1lbi1VUzpcbg0KVUlEOjA0MDAwMDAwODIwMEUwMDA3NEM1QjcxMDFB ODJFMDA4MDAwMDAwMDAzQUFCQzZDQ0ExNTRERDAxMDAwMDAwMDAwMDAwMDAwDQogMDEwMDAwMDAw MTBBOEIzNDZCNjY1MzE0QjlEQkNGQ0U1NTk4RTQ3REINClNVTU1BUlk7TEFOR1VBR0U9ZW4tVVM6 T09PIEx1Y2ENCkRUU1RBUlQ7VkFMVUU9REFURToyMDI2MTAxNQ0KRFRFTkQ7VkFMVUU9REFURToy MDI2MTAxNw0KQ0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1QOjIwMjYxMDA1VDA4MTcx OFoNClRSQU5TUDpUUkFOU1BBUkVOVA0KU1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6MA0KWC1N SUNST1NPRlQtQ0RPLUFQUFQtU0VRVUVOQ0U6MA0KWC1NSUNST1NPRlQtQ0RPLU9XTkVSQVBQVElE OjIxMjUwODIxNDUNClgtTUlDUk9TT0ZULUNETy1CVVNZU1RBVFVTOkZSRUUNClgtTUlDUk9TT0ZU LUNETy1JTlRFTkRFRFNUQVRVUzpGUkVFDQpYLU1JQ1JPU09GVC1DRE8tQUxMREFZRVZFTlQ6VFJV RQ0KWC1NSUNST1NPRlQtQ0RPLUlNUE9SVEFOQ0U6MQ0KWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBF OjANClgtTUlDUk9TT0ZULURPTk9URk9SV0FSRE1FRVRJTkc6RkFMU0UNClgtTUlDUk9TT0ZULURJ U0FMTE9XLUNPVU5URVI6RkFMU0UNClgtTUlDUk9TT0ZULVJFUVVFU1RFREFUVEVOREFOQ0VNT0RF OkRFRkFVTFQNClgtTUlDUk9TT0ZULUlTUkVTUE9OU0VSRVFVRVNURUQ6VFJVRQ0KQkVHSU46VkFM QVJNDQpERVNDUklQVElPTjpSRU1JTkRFUg0KVFJJR0dFUjtSRUxBVEVEPVNUQVJUOi1QVDdIDQpB Q1RJT046RElTUExBWQ0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --_000_PH7PR12MB7113449E03644C735BDB77ADEA962PH7PR12MB7113namp_-- From xen-devel-bounces@lists.xenproject.org Mon Oct 05 08:49:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 08:49:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440613.1658014 (Exim 4.92) (envelope-from ) id 1xDeOM-0002JW-7w; Mon, 05 Oct 2026 08:49:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440613.1658014; Mon, 05 Oct 2026 08: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 1xDeOM-0002JP-3U; Mon, 05 Oct 2026 08:49:50 +0000 Received: by outflank-mailman (input) for mailman id 1440613; Mon, 05 Oct 2026 08:49:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDeOK-0002JJ-Qp for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 08:49:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDeOJ-000pt1-TZ for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:49:47 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac364a7-8faa-0a2a0a5109dd-0a2a4507ad78-2 for ; Mon, 05 Oct 2026 10:49:47 +0200 Received: from [52.101.57.16] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac364aa-b4ea-0a2a45070019-346539102ad5-3 for ; Mon, 05 Oct 2026 10:49:47 +0200 Received: from PH7PR12MB7113.namprd12.prod.outlook.com (2603:10b6:510:1ec::8) by MW3PR12MB4441.namprd12.prod.outlook.com (2603:10b6:303:59::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 08:49:44 +0000 Received: from PH7PR12MB7113.namprd12.prod.outlook.com ([fe80::2104:fa11:f054:7dc]) by PH7PR12MB7113.namprd12.prod.outlook.com ([fe80::2104:fa11:f054:7dc%5]) with mapi id 15.21.0451.022; Mon, 5 Oct 2026 08:49: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=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=yZzfx7PLx8y6+49PjSCFAwIBe0KGXE6Xf6anT/vUc3WfzgR+S2UF/LP31YFYDamDr7W1w2Fgxm5pazubN2ezN/N4Mxk9tm9PnKYd1vMVnkR6jUfUKEBB2Da2QwBolJbHRX1ZdGnyspE6UOEg+IwiLxhqZ6pxdAdxO21zCSL3lsXTVjjfJjt1yDyQspCxzRKFGN2aZQHwXlf+FjNbkd5PrdgkSwJCVtY59nbIuOBSSx3Vk7mOX4JJ0e56vO9EyCA/2mdn8ZF7g5Szn7KSSFX+rlwD001unFkRDRdyucWb7ViwiFl30N5lW+SIcfsDpHuHD2W0TIEKvh+XaVzE/Sze7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mcUEXBoaP+7nw7lc1wyIUvZTFfcRbUfKFrTeRFvIcqA=; b=MaKZhvRCsczwV1XkZ5zUNMQQgZmS00b6ZVWrXfcxHmfYDRn+KUG6BN+RIHtEBfo389GKQGAJmzzKqmKJwMXMx+tw2yUCT4vM1HT6CgLhYamcG4bkfEnO6LIrIcLexhvoaEGLBp23cLijLRud/6QjE7LEjLYJogMIUdwCdeInqeeoe8b95xo59F0xKaxgA4esWVWthBuqp4eNHW2oCHl+CIN1H32JTg2ll7WAKMsoGM1w5D0DIvKjKEGQVCT5gv+M71mptFbo0cOgi0oNDdcGYHDF3CG1VvpZWcYOJ7qcaCwLCwauhO0HHVp/7p9YFAOXGMd/jewjbWXFGNMBQ3tkQA== 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=mcUEXBoaP+7nw7lc1wyIUvZTFfcRbUfKFrTeRFvIcqA=; b=TaUCwaEmvXGi2LwZlHXIQU/R2gUQdPE0/LgrLSmgjFI1d8zU9+a0gfbasdwAdWoFM7O9N5skSkY2DJtGzU+g2RlG5DXaWcIcB/7hD22JGn+VJlwv/JE04JfglfzE9OQ4C8XOFf4l+qg6olycLzzxdw8GpKu+eTVYXmQ2upEeXwA= From: "Miccio, Luca" To: Xen-devel CC: "Nowshadi, Saeed" , Seb Hinderer Subject: Canceled: OOO Luca Thread-Topic: OOO Luca Thread-Index: Ad1UoczsW00ZEttDeU6QxqgKziCZ7Q== Importance: high X-Priority: 1 Date: Mon, 5 Oct 2026 08:49:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAA6q8bMoVTdAQAAAAAAAAAAEAAAABCos0a2ZTFLnbz85VmOR9s= x-ms-traffictypediagnostic: PH7PR12MB7113:EE_MeetingMessage|MW3PR12MB4441:EE_MeetingMessage x-ms-office365-filtering-correlation-id: 394c2a20-2978-46a4-b3ff-08df22bd99fc 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|18002099003|38070700021; x-microsoft-antispam-message-info: uv+4R4nU5GVRIhvBp/ilBDDqw/JjqcNpVmFYAk8GvarBJfPVG+Az4IOKg2JdyB60ugvokUUcqYMBOGNkqAWKt3R/XiUFqzm7/EA7MgBmA4mfQsU4oyuqGAvcyj5Mdax5bvOooCcJqBWy1xwbBK6D0UAaqAb0Cb35un4uPawytl/G8Jz0cJT5ZqCp5KmyBBVJokj41AF6NMZ7By90Npvs4YGA7S0dCR/FSrY+A7QWgJukyBnBBCerbpkI4fLG164POQ/769pCSRzk7vM/xgDtEn+MripwTbHm5LnZFwOda0JxjZsxzVKrNTanSb2XVul52pYLKbLOi7dtYzH8Z4D2rVhIjabvShSGIikB1lJBAgee+SKb4Ms+gUumQDOHpIi4mzV029jgb9meYmLbxcxOXZxF89eFfxzNAqiuhcihz4GUafEGT09kSXGVUWaGbUMYHrW22YxQY7+bwdUSiREqtQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB7113.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(10067099003)(56012099006)(11063799006)(18002099003)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?GI5LjFqaoLrVguD/MuYp5o7VFlErViNAr1sYKA0dGb45bljHgjFZXtJtJI?= =?iso-8859-1?Q?b49Bfm+OoJtzwYAPsQB5dF/R/kacv1fQUb+HMTMCSxsBCtqmgcfoj/csvq?= =?iso-8859-1?Q?bU+zUBeYq8y3KZiv9uFfNalkm2mHodSmUXKs57T8aq9UEyzYEGDiRUD8Lg?= =?iso-8859-1?Q?hSLGGUgPKLHa3YNpVis7jY0W2/1lTRh6WIKx1z/R2fFKjpM+Wy1u+Y1Kiy?= =?iso-8859-1?Q?eW7ay2PMvRcoPyxrzGRjuycxXLla7I5tYS6CDut+3L0sb+9cF2wlsMB+61?= =?iso-8859-1?Q?fZ7IOttssKWuz4bbiF05Juuub6+sUbWwzRwgaW6RbyJl68U7hjwtKZuDCy?= =?iso-8859-1?Q?5jA15f2lQIsPfvEpdJkw497zAOMBTP2sMqxbKuRwqm1cEBOtg9ROdh+5/t?= =?iso-8859-1?Q?5u8i7IxtWRF5hnCsAhrDGguNWNlZ0gHfBP5JM7hdSTYrcqllndrlaDi6in?= =?iso-8859-1?Q?6BFc11vmpCenKFi6XIdkVR0e0cBJ691EufsArvUEL6XNnUKf/h5onUmgxm?= =?iso-8859-1?Q?MAHs6BWvWCyh0r6/HT2b3cUmoR4v+isSTMc24Fz2hURSOadlQH3dFi7uVA?= =?iso-8859-1?Q?iqkJ59TtOTK7Wp+CAnJGH/7RidfId520ARHghfC5s9aiwlQ9s4EC1bjuV+?= =?iso-8859-1?Q?FkNfbcmO5y43cv3kVHfZ+nb0HaPIziWAtclYVKmJKK2ojHnV5EO7xHSXgz?= =?iso-8859-1?Q?OLHHhLOKFSbK9voL/rULVPkOGx2OBIA0TdGwjjGsQmbHL6QXPSJua5Cvkm?= =?iso-8859-1?Q?V1sDPv6xa+CZzqodivetfVDe6ym/2bSR92tgTf533oMnQSLxpoZfQr3zTE?= =?iso-8859-1?Q?UDGI/MmbSxFQWAaB0gLIK2qkk0K+WqFl66eJpfQ3VZ5U19M6vjWvc+N/YZ?= =?iso-8859-1?Q?Ij3kAuiO4BGlP9sCMayfULUR7K6fgG3boI+y0JFflBOKChRwfl3kCKynf1?= =?iso-8859-1?Q?GvHZ3Z+k4TR3EtUjAxpqUvs0S6uXsWEKaWkczrJcnXcAZD4cntfVYNbS19?= =?iso-8859-1?Q?Q77McTkY/R+dLOYg+IZmDuhAnDhcMl31yg814jigu/GjOHmBxhjoyg2gJO?= =?iso-8859-1?Q?6aecO3vBUk0isZLI2Pg1G3uVfJ6Uzvqeq2F7nS4ROQv/YIARRuNUDz5nix?= =?iso-8859-1?Q?n3unut073AE6ymMdodSvLtYaOfasvSTBL2WR0rn6BUJFJm906v1OZShnhT?= =?iso-8859-1?Q?lPSE7cRkT47XFHLCovkufaclgNf8CtTX/1KvV+IfHZMz2pzDOkvY4tAYf8?= =?iso-8859-1?Q?Szwxzmrm25udTLh1MnPQf2gP/IDtpGQSqF3+mhBj8wU8u/ZxqSWS1FSBnH?= =?iso-8859-1?Q?wwSxnmlpbgDCB5je7ApS5yBDAfw8Qx/QLpjsxK4FDa03orwQh2HiwoLz3R?= =?iso-8859-1?Q?Mh1WxsePRhLtg3ulQcGip58vsoZz1ruUNaqiyF3XNERgb5t3SvzOwsK3NN?= =?iso-8859-1?Q?dY/GcjgydPWcp0EMV/mwbGvSdksEipGplD9QH3X4dU4s4ulqPjHGFQXjYl?= =?iso-8859-1?Q?j1ku9UOxqEpig85tMzoW+Em4fRIaH/j3NrF3goKx0CYac+zHdx71ghOXL3?= =?iso-8859-1?Q?QN/djul9YH0S4GPumBDtefgSa1L9AMhkpeBGq7VlMGWY/phfnXkYPVcTVM?= =?iso-8859-1?Q?2Rv/16acfCamzcHf0SuYQAVzrUk4S+a8VkHAkm7iDqdQWT1A2oymr6mPXa?= =?iso-8859-1?Q?WU4UpkCud2x/+oCZEag5jUevpbUkk/+pFUBWWcPOCEUQKGd5XjaloC1wxK?= =?iso-8859-1?Q?7y9//OExr1qqADEmp4oOJiSmPBeXaSIm10QP0rUu88AHZK?= Content-Type: multipart/alternative; boundary="_002_PH7PR12MB7113604C1C0285E5A658BB11EA962PH7PR12MB7113namp_" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB7113.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 394c2a20-2978-46a4-b3ff-08df22bd99fc X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2026 08:49:43.7329 (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: tTMz3oXbzGuin9XzAgs9Vo2mF0RMKaydYnLNZ8tt+O2+/RElY4+RJdDvpQ9rnadHL7s5rvIpyRHuykrTuCoYKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4441 X-purgate-ID: tlsNG-ef75cf/1791190187-A76D2AE4-DAC9D032/0/0 X-purgate-type: clean X-purgate-size: 2588 --_002_PH7PR12MB7113604C1C0285E5A658BB11EA962PH7PR12MB7113namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_002_PH7PR12MB7113604C1C0285E5A658BB11EA962PH7PR12MB7113namp_ Content-Type: text/calendar; charset="utf-8"; method=CANCEL Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6Q0FOQ0VMDQpQUk9ESUQ6TWljcm9zb2Z0IEV4Y2hhbmdl IFNlcnZlciAyMDEwDQpWRVJTSU9OOjIuMA0KQkVHSU46VlRJTUVaT05FDQpUWklEOlcuIEV1cm9w ZSBTdGFuZGFyZCBUaW1lDQpCRUdJTjpTVEFOREFSRA0KRFRTVEFSVDoxNjAxMDEwMVQwMzAwMDAN ClRaT0ZGU0VURlJPTTorMDIwMA0KVFpPRkZTRVRUTzorMDEwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7 SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MTANCkVORDpTVEFOREFSRA0KQkVHSU46REFZ TElHSFQNCkRUU1RBUlQ6MTYwMTAxMDFUMDIwMDAwDQpUWk9GRlNFVEZST006KzAxMDANClRaT0ZG U0VUVE86KzAyMDANClJSVUxFOkZSRVE9WUVBUkxZO0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1P TlRIPTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTkla RVI7Q049Ik1pY2NpbywgTHVjYSI6bWFpbHRvOkx1Y2EuTWljY2lvQGFtZC5jb20NCkFUVEVOREVF O1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049 WGVuLWRldmVsOg0KIG1haWx0bzp4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCkFUVEVO REVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7 Q049Ik5vd3NoYWRpLCANCiBTYWVlZCI6bWFpbHRvOnNhZWVkLm5vd3NoYWRpQGFtZC5jb20NCkFU VEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049U2ViIEhpbmRlcg0KIGVyOm1haWx0bzpzZWJhc3RpZW4uaGluZGVyZXJAdmF0ZXMudGVj aA0KVUlEOjA0MDAwMDAwODIwMEUwMDA3NEM1QjcxMDFBODJFMDA4MDAwMDAwMDAzQUFCQzZDQ0Ex NTRERDAxMDAwMDAwMDAwMDAwMDAwDQogMDEwMDAwMDAwMTBBOEIzNDZCNjY1MzE0QjlEQkNGQ0U1 NTk4RTQ3REINClNVTU1BUlk7TEFOR1VBR0U9ZW4tVVM6Q2FuY2VsZWQ6IE9PTyBMdWNhDQpEVFNU QVJUO1ZBTFVFPURBVEU6MjAyNjEwMTUNCkRURU5EO1ZBTFVFPURBVEU6MjAyNjEwMTcNCkNMQVNT OlBVQkxJQw0KUFJJT1JJVFk6MQ0KRFRTVEFNUDoyMDI2MTAwNVQwODQ5NDJaDQpUUkFOU1A6VFJB TlNQQVJFTlQNClNUQVRVUzpDQU5DRUxMRUQNClNFUVVFTkNFOjENClgtTUlDUk9TT0ZULUNETy1B UFBULVNFUVVFTkNFOjENClgtTUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDoyMTI1MDgyMTQ1DQpY LU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpGUkVFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURT VEFUVVM6RlJFRQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOlRSVUUNClgtTUlDUk9TT0ZU LUNETy1JTVBPUlRBTkNFOjINClgtTUlDUk9TT0ZULUNETy1JTlNUVFlQRTowDQpYLU1JQ1JPU09G VC1ET05PVEZPUldBUkRNRUVUSU5HOkZBTFNFDQpYLU1JQ1JPU09GVC1ESVNBTExPVy1DT1VOVEVS OkZBTFNFDQpYLU1JQ1JPU09GVC1SRVFVRVNURURBVFRFTkRBTkNFTU9ERTpERUZBVUxUDQpYLU1J Q1JPU09GVC1JU1JFU1BPTlNFUkVRVUVTVEVEOlRSVUUNCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5E QVINCg== --_002_PH7PR12MB7113604C1C0285E5A658BB11EA962PH7PR12MB7113namp_-- From xen-devel-bounces@lists.xenproject.org Mon Oct 05 08:52:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 08:52:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440617.1658021 (Exim 4.92) (envelope-from ) id 1xDeR6-0003v6-IM; Mon, 05 Oct 2026 08:52:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440617.1658021; Mon, 05 Oct 2026 08:52: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 1xDeR6-0003uz-FH; Mon, 05 Oct 2026 08:52:40 +0000 Received: by outflank-mailman (input) for mailman id 1440617; Mon, 05 Oct 2026 08:52:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDeR4-0003ut-LI for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 08:52:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDeR4-006cYv-2B for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:52:38 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac36542-8faa-0a2a0a5109dd-0a2a4507df6a-46 for ; Mon, 05 Oct 2026 10:52:37 +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 6ac36550-b4ea-0a2a45070019-4a7de18ddf5f-3 for ; Mon, 05 Oct 2026 10:52:32 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-4a169d33ef6so8106395e9.1 for ; Mon, 05 Oct 2026 01:52: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-48c622b4685sm2024732f8f.41.2026.10.05.01.52.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 01:52: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=1791190352; x=1791795152; 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=OXgn4LN+fUFt+j3H44lAfs5EywG2H9SYDThHvTcTME8=; b=AMI0qfRVf8wDFqVxuXh424MxAZjO2QQdkMWlDxYbL1d0PUAp1qvbDwHoz4LJvfQJpd A3Bh1CDyGFb9D1XrDXHlRlh6FHKrvk3t3hVIUm4YaVOqwcLaL6oNFgxfodFSl9ksFx6i yQ7V7ZIjzX2LHWTDMK67LbUVQp8+QZNvCy8gUJtZLhNrQJfh0nPPVQzAOywEyg2wYEyt XOuYc3l83wwnRMmQanRrs+ywujoLet0PDk77tUrK3h9hd1FAwT0wc4IM+kdjLphKMDZs nBda9Ll3xT6phEQdREiMY1ksrDojef1NGIdleRD53xG1111i4UqM+UoLIHvLKR4ZHt4W C0lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791190352; x=1791795152; 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=OXgn4LN+fUFt+j3H44lAfs5EywG2H9SYDThHvTcTME8=; b=rN8n6zNWq9LMBIrhNy/Q2x6TEaL+IAch8Gf+pzjVD8lTb1SR0N0bY/oa9TUe+Lh8Zk O/R3TvjRk6QLCY/DmvBIApsnHm6vM6oJxDDqlavTXsBgMurbjizkvazy2JpMOscFvU5A xHMkMLJrr5pi7TuZPpTpHFTE7M+BRyEjPqrcdrhdJoTq026sPv5P0BC7A4jmyShDUZoO cMB5mcZEQD0lghFtVk7A8tdfF+GofWKJl0Gmcb7fIl0ljjfDX+b8RcqJIfi7lrrfQKkg fY9IcBztSUNaiikyldWuBgbeGBmlm5aLo3huluMZZeEe19rGjAUOmQF7EEWD8IIFbpF0 BeFg== X-Forwarded-Encrypted: i=1; AKwUvBy/Tvi4Bj5k4hLXzEmmBS1/ljsnljehFe48SlVa9QA5/xLAnavfONd3QiO1J9fhFJd3hFln9hpW1sc=@lists.xenproject.org X-Gm-Message-State: AFuF++kjc62wO7kXK+lkmMBYa8YlDe94h+VgI5k/iROE4xXryWjoI/p4 pp19X3+bkT3e9QNgctqUCPxQDW+SyDewAKW5PeqQFnzzYtfAakXs7JjGg5IzLodaCA== X-Gm-Gg: AYBFou00iE9hq0A+IcBc2kAasl7kyVwvd1M/UXxZejJzN2Nh3DVX5rdCCCeWGumjUqQ pZjkh6TaCFRSb1bWxe/fmHm6fg3QBx/PwOTTP2tQlU36TFqvjS0b03eJzpH+pJ8mrivmDN5Yp++ kxfWUDJT0WT16lGD3zu+W69mE9BcNlKqs+KteekK0MxK4vFw8sNDHat6wl3s/cIltQpABpfnvom rjVUsLDAd/AMIHSS8GuQ5uvfc+uOjNAncOvYqwJQG/EHKpF2LLqiM3sSQGHnfh94UmkTUTGAIMj yhNnFJ+7UlY4bm15llTvC+V99WQxAWFVkaxnhp+T1RR5vqMY5wt5bDrK9oj07R104g9oPuMqOYn /waTLU6a0kzs/ZbW+Mxz4BpT2bfXi+SpmasOf1KHEvSr++oEvHYxeAzrHRt1iwZ87UXgkVt5zv8 m8f+pZuFSLwrs6EUsSmW67xybIU7pQ05WnGXdME2lQjfsYvu9NGv5tJ9Pd4skDOV29YdJs+cbXi O2z1fSNBdsWxyfFRhEE5w8VxQmOLC/6LDwX0kqMnQBiEdGfvhyhUckpGwazmro= X-Received: by 2002:a05:600c:6089:b0:49e:6c27:d093 with SMTP id 5b1f17b1804b1-4a02757a74dmr149635695e9.15.1791190352187; Mon, 05 Oct 2026 01:52:32 -0700 (PDT) Message-ID: Date: Mon, 5 Oct 2026 10:52:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot To: Oleksii Moisieiev , Oleksii Kurochko Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Teddy Astie , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.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: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.git.oleksii_moisieiev@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791190357-A78D1AE4-C4E9903D/10/78276251493 X-purgate-type: spam X-purgate-size: 5201 On 02.10.2026 15:26, Oleksii Moisieiev wrote: > This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to > allow for building Xen without support for booting a regular domain (Dom0). > This functionality is primarily intended for the ARM architecture. I (still) wonder why this would be, but well ... > A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by > default for ARM and X86 architecture. This symbol signifies that an > architecture has the capability to support a Dom0. Oleksii - what's your take towards RISC-V here? Should it select the new symbol right away as well? > The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For > expert users, this option can be disabled (`CONFIG_EXPERT=y` and no > `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0 > creation code on ARM. This is useful for embedded or dom0less-only > scenarios to reduce binary size and complexity. > > The ARM boot path has been updated to panic if it detects a non-dom0less > configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an invalid > boot. > > Signed-off-by: Oleksii Moisieiev > Acked-by: Jan Beulich Notwithstanding the ack, a few further comments. > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -43,8 +43,10 @@ > #include > #include > > +#ifdef CONFIG_DOM0_BOOT > static unsigned int __initdata opt_dom0_max_vcpus; > integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); > +#endif > > /* > * If true, the extended regions support is enabled for dom0 and > @@ -123,6 +125,7 @@ paddr_t __init hwdom_get_fdt_alloc_size(void) > return ACPI_DOM0_FDT_MIN_SIZE; > } > > +#ifdef CONFIG_DOM0_BOOT > unsigned int __init dom0_max_vcpus(void) > { > if ( opt_dom0_max_vcpus == 0 ) > @@ -135,6 +138,7 @@ unsigned int __init dom0_max_vcpus(void) > > return opt_dom0_max_vcpus; > } > +#endif > > /* > * Insert the given pages into a memory bank, banks are ordered by address. > @@ -1862,6 +1866,7 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) > return 0; > } > > +#ifdef CONFIG_DOM0_BOOT > static int __init construct_dom0(struct domain *d) > { > struct kernel_info kinfo = KERNEL_INFO_INIT; > @@ -1893,6 +1898,7 @@ static int __init construct_dom0(struct domain *d) > > return construct_hwdom(&kinfo, NULL); > } > +#endif > > int __init construct_hwdom(struct kernel_info *kinfo, > const struct dt_device_node *node) > @@ -1944,6 +1950,7 @@ int __init construct_hwdom(struct kernel_info *kinfo, > return construct_domain(d, kinfo); > } > > +#ifdef CONFIG_DOM0_BOOT > void __init create_dom0(void) > { > struct domain *dom0; > @@ -2001,6 +2008,7 @@ void __init create_dom0(void) > > set_xs_domain(dom0); > } > +#endif /* CONFIG_DOM0_BOOT */ It's not really a lot of code which is being removed, which may suggest this is getting too fine-grained. (Primarily, for now) Arm maintainers will need to judge. I further wonder how much unreachable code is newly introduced by this, when the new option is enabled. set_xs_domain() (visible in patch context above) is possibly only the first example. > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -491,11 +491,18 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) > > do_init_boottests(); > > - /* Create initial domain 0. */ > - if ( !is_dom0less_mode() ) > + if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() ) > + { > + /* Create initial domain 0. */ > create_dom0(); > + } > else > - printk(XENLOG_INFO "Xen dom0less mode detected\n"); > + { > + if ( is_dom0less_mode()) > + printk(XENLOG_INFO "Xen dom0less mode detected\n"); > + else > + panic("Neither dom0 nor dom0less mode was detected, aborting\n"); > + } If I was maintainer of this code, I would ask for the figure braces to be omitted - the inner if() can easily be "else if". > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -26,6 +26,15 @@ config DOM0LESS_BOOT > Xen boot without the need of a control domain (Dom0), which could be > present anyway. > > +config DOM0_BOOT > + bool "Dom0 boot support" if EXPERT && !X86 Like already indicated in reply to v3 I'm irritated by this: What use is the select of HAS_DOM0 on x86 when then you exclude x86 here? I think it needs to be clarified whether, as the commit message says, this is going to be Arm-only or of broader use. In the latter case the !X86 here would want leaving out; the description then would want to clarify that making x86 respect the option is a TODO item (possibly part of the hyperlaunch effort). In the former case more questions arise, like why this wants to be a common option in the first place. (But since from an abstract pov this is a common choice, this case likely doesn't want pursuing anyway.) Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 05 09:08:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:08:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440629.1658030 (Exim 4.92) (envelope-from ) id 1xDegH-0006Im-To; Mon, 05 Oct 2026 09:08:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440629.1658030; Mon, 05 Oct 2026 09:08: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 1xDegH-0006If-QY; Mon, 05 Oct 2026 09:08:21 +0000 Received: by outflank-mailman (input) for mailman id 1440629; Mon, 05 Oct 2026 09:08:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDegF-0006IZ-Lg for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:08:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDegE-00AQ1w-EJ for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:08:18 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac368f3-8faa-0a2a0a5109dd-0a2a450ac492-32 for ; Mon, 05 Oct 2026 11:08:18 +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 6ac36902-f2d2-0a2a450a0019-4a7de18cc659-3 for ; Mon, 05 Oct 2026 11:08:18 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-4a1722c37c9so5197655e9.3 for ; Mon, 05 Oct 2026 02:08: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-4a03ff56136sm127262875e9.3.2026.10.05.02.08.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 02:08: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=1791191298; x=1791796098; 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=vz5RxzHZkbj/P4LeJtNZ5BCMlbA0wuc5OUSU/fF6dIE=; b=VUgHBKgN+QvzA2Qgc1nsjitqIHlvia5yi/rfOVDqeKRvhoHnlguezJXDBTSZz3N5Ay jwhfXAMl8kdFCEDF07GpaxrJembl/pfW1vZc/bEYNv81bnuUrI1K2aI1HRzvS3r85hXr hb7K+FgHnPFd3+lZqr0t8ZB2dcTFsqMANIprnsvGVcWvhE/obL6oiPxwY/cv0W7xCETU JInN7LpbRs/X0ItL/zeyGC8WrrOxRvJxgqXdE+ku07TKBJJlnpDgtoG8NzDbhLx+cqwf tGE5CUa46z/YSIzgQ9z5InzLW+p+VdSFqKzlXoNXle386o08Qrjxpismuul51nM2qHn7 hG+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791191298; x=1791796098; 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=vz5RxzHZkbj/P4LeJtNZ5BCMlbA0wuc5OUSU/fF6dIE=; b=UQb9zaqm7KzTabB3l9hiFchGY2v8xzzIzRzdPE6HxYA2AzEz1FWpIHEHELea9u7AE5 7+G+ZkBedN4OdgJ/qnsg8zkj34uG7obfCFl+4ca/P/ytgNV/yqf9iAQp7e4sBTDQdL1F VMoGRGezVDNWelVxg4PYg1dxzDmce5HK+ULn/K+gXYe6PTDqypKzjPb5e+Jhb4oWREth Te6EADQ/UItxTYL+GKQHStJtdBGDWwppm4TpxEb64CIwtWTSEaqHojVZx1mQ7uOtOVM9 5yR/nQmueTECc0b5j38Hykjb9kwnXoibWKsf+bb1r2nkwj71bztDS4KjGDKMtFKc6bKS OSTA== X-Forwarded-Encrypted: i=1; AKwUvBxyT8Og9TDSGiI1lUAiO8Lf2IY5FryuOfD606RPB70BUHEGvdS0SQKz2wcOEg478q4a1s2uubJ2Lc4=@lists.xenproject.org X-Gm-Message-State: AFuF++nLJRhLfKpeCe0xjl9OIvrRdbzauNe5xkQbXSqb3CEJgidazEGD +llawG+CArqhUbUqpUTScDg7K9MGmmULoyxo0+uzEFVFd3Yq0tWtqs8PHNcX4FmJhQ== X-Gm-Gg: AYBFou23IANgei+Gf3XkzpU5KbgMNtQVZ5Afsuir8FupoRsaiKQTHvKLMRQEr6kXHJN oHCKyS00ueHUexmJlrL2YvgiM0FhyHEiuW+1h4eN7xkK7pFGHfSC5BiW+9cuqymnxHQQ10EsR1K qtMqG6WHfgyhANFlSaHHsIlPAP4+mzJTbF1NkQsB/0nvsBE3W1vg2va3sZ1VArnzfJT/Hp3tsvH PLbmCq1tU9LBPc2JeA6OK/RpsxHj41+FmnIWLO4ft6HJXBF59N/Br3ePo0WoKfYkChOTnbYZyCQ ngdzXOs8Zqy3kkHEE+S21qNf7aQlVNUm2Uv0w3BBpudv0Y5SVq/D5hXDxS6DayT5C4EORnLfGwd AL0UcnDhRnfQxZBUK0cbNzQNrYLQwdZnksflEzoAOSPKoeIh7aUMPPxCnHVzQVT24XBzLYtfP71 tygR5dHVA98wGRF42S1I7iPqFU8l7AhKLH7O8afTZQByIx9hdOK+X5Pz+Dc9tTy097/UDMcWlmi BqQ0VwlYTs71Q+J6R7jHqB0emdNrMd8kSKrBxSfIofz8t87LGVjnGRTdwNY64Y= X-Received: by 2002:a05:600c:19c9:b0:4a1:6c0c:ab93 with SMTP id 5b1f17b1804b1-4a16c0cabc6mr88448515e9.28.1791191297629; Mon, 05 Oct 2026 02:08:17 -0700 (PDT) Message-ID: Date: Mon, 5 Oct 2026 11:06:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] xen/pdx: reject regions crossing a lookup table index To: Weiqi Wang , roger@xenproject.org Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang , xen-devel@lists.xenproject.org References: <20261004190409.29276-1-coolhaoyt@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: <20261004190409.29276-1-coolhaoyt@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791191298-4B4D7CFC-16FFBD56/10/78276251493 X-purgate-type: spam X-purgate-size: 6036 On 04.10.2026 21:04, Weiqi Wang wrote: > From: Weiqi Wang > > pdx_is_region_compressible() only looks up the table entry of the first > page, and checks the region against [pfn_base, pfn_base + > pdx_region_size). pfn_base need not be aligned to the table index > granularity, so that window can extend into the next index, which belongs > to a different range with a different offset. A region whose tail lies > there is reported compressible, yet its last page on its own is not, and > translates through the wrong offset. > > Also require the first and last page of the region to use the same table > index. > > This can be reached from the coverage check in srat_parse_regions() when an > e820 RAM range is not covered by the SRAT ranges, which is the case that > check is meant to catch. > > Found with the ESBMC bounded model checker. The counterexample was > confirmed by running it natively against the unmodified code. > > Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") > Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation > Signed-off-by: Weiqi Wang > --- > > Notes: > RFC because this was discussed when the offset compression was reviewed. > In the v2 thread [1] Jan asked whether pdx_is_region_compressible() is > correct when a region crosses a lookup table slot boundary. The thread > concluded it was not an issue, on the basis that pages contiguous in MFN > space are also contiguous in PDX space. The reproducer below is a case > where that does not hold for the code as merged: the region is reported > compressible, its last page on its own is not, and that page round-trips > to a different PFN. > > The ranges are as srat_parse_regions() would see them. The RAM range is > not covered by either SRAT range, which is the situation the coverage > check in srat_parse_regions() is meant to detect. Built from > tools/tests/pdx like test-pdx-offset, on staging (e4da182973) plus patch > "xen/pdx: fix merging of a range contained in the previous one": > > region [0x75757ffef9, 0x8122007e00) compressible: 1 > last page compressible: 0 > last page: pfn 0x8122007dff -> pdx 0x2122047dff -> pfn 0x2d7ee07dff > > With this patch the region is reported not compressible, and > srat_parse_regions() disables compression. > > 8<---------------------------------------------------------------------- > /* Build like test-pdx-offset, e.g. from tools/tests/pdx: > * gcc -D__XEN_TOOLS__ -DCONFIG_PDX_OFFSET_COMPRESSION \ > * -I../../include -o repro-window repro-window.c > * (after generating pdx.h as the Makefile does). */ > #include "harness.h" > #include "../../xen/common/pdx.c" > > int main(void) > { > /* Two SRAT-like ranges, in PFNs. */ > pfn_pdx_add_region(pfn_to_paddr(0xdffffe0000UL), > pfn_to_paddr(0xe000000000UL - 0xdffffe0000UL)); > pfn_pdx_add_region(pfn_to_paddr(0xc5cde0000UL), > pfn_to_paddr(0x4cd7000000UL - 0xc5cde0000UL)); > if ( !pfn_pdx_compression_setup(0) ) > return puts("compression not enabled"), EXIT_FAILURE; > > /* A RAM range not covered by either, as srat_parse_regions() checks. */ > unsigned long s = 0x75757ffef9UL, e = 0x8122007e00UL; > > printf("region [%#lx, %#lx) compressible: %d\n", s, e, > pdx_is_region_compressible(pfn_to_paddr(s), e - s)); > printf("last page compressible: %d\n", > pdx_is_region_compressible(pfn_to_paddr(e - 1), 1)); > printf("last page: pfn %#lx -> pdx %#lx -> pfn %#lx\n", > e - 1, pfn_to_pdx(e - 1), pdx_to_pfn(pfn_to_pdx(e - 1))); > > return pdx_is_region_compressible(pfn_to_paddr(s), e - s) && > pdx_to_pfn(pfn_to_pdx(e - 1)) != e - 1 ? EXIT_FAILURE : EXIT_SUCCESS; > } > 8<---------------------------------------------------------------------- > > Other callers that rely on the same answer are mem_hotadd_check() and > the EFI ram_range_valid() check. I have not run those paths. > > One behavioural change to check: with npages == 0 the new condition > compares against pfn - 1. The callers I looked at never pass 0. > > Model checking (ESBMC, 2 SRAT ranges and 2 e820 RAM ranges, all free > below 2^40 PFNs, the srat_parse_regions() coverage check modelled) finds > no accepted RAM page that fails to round-trip with both patches applied. > It also finds no layout where the coverage check now rejects what setup > accepted, with RAM equal to the SRAT ranges. This is bounded to 2 ranges. > > The existing tests in tools/tests/pdx pass in both mask and offset mode. > > I have not reproduced this in a boot: the layout needs RAM near 2^51 > bytes, which I could not set up under QEMU. I don't quite understand this part: SRAT not covering all E820 regions isn't tied to huge addresses, is it? > [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg194095.html Hmm, indeed you now provide an example of the concern raised there. I think we indeed ... > --- a/xen/common/pdx.c > +++ b/xen/common/pdx.c > @@ -324,7 +324,8 @@ bool pdx_is_region_compressible(paddr_t base, unsigned long npages) > unsigned long pfn_base = pfn_bases[PFN_TBL_IDX(pfn)]; > > return pfn >= pfn_base && > - pfn + npages <= pfn_base + pdx_region_size; > + pfn + npages <= pfn_base + pdx_region_size && > + PFN_TBL_IDX(pfn) == PFN_TBL_IDX(pfn + npages - 1); > } ... need this extra check (as we want to cope with SRAT and E820 not fully agreeing). Roger? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 05 09:26:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:26:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440641.1658040 (Exim 4.92) (envelope-from ) id 1xDexx-00011Q-B5; Mon, 05 Oct 2026 09:26:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440641.1658040; Mon, 05 Oct 2026 09:26: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 1xDexx-00011J-7W; Mon, 05 Oct 2026 09:26:37 +0000 Received: by outflank-mailman (input) for mailman id 1440641; Mon, 05 Oct 2026 09:26:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDexv-00010N-T7 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:26:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDexv-00BvIv-9j for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:26:35 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac36d40-bab6-0a2a0a5309dd-0a2a4501c15c-36 for ; Mon, 05 Oct 2026 11:26:34 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac36d49-5984-0a2a45010019-aa0a857c7b95-3 for ; Mon, 05 Oct 2026 11:26:34 +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-578-N6hTJVhvPH-NDifGdYGF_A-1; Mon, 05 Oct 2026 05:26:29 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AB15419236B0; Mon, 5 Oct 2026 09:26:27 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 631281956044; Mon, 5 Oct 2026 09:26: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=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To: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=1791192393; 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:in-reply-to:in-reply-to: references:references; bh=cCc57hc9JUT01LxypoVVFPFOwLInLi3iRPdYV2t4GiQ=; b=QBnnyVp+byChjWJWxeOp6l19z1cg9t9bT46vK/1hcMz6IT5Ya8vUjjJCR+TEOKOVkNY8jH pR/W1NFN378x6WXjxSt/o4Mvf1jqCM1IWL+ollYuAoAoQcLx7gyxdUNSK2rMBZ7d8GodzY CrpDNodv3AzZp6zvrKF8tA/tBxD3wag= X-MC-Unique: N6hTJVhvPH-NDifGdYGF_A-1 X-Mimecast-MFC-AGG-ID: N6hTJVhvPH-NDifGdYGF_A_1791192388 Date: Mon, 5 Oct 2026 10:26:22 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: marcandre.lureau@redhat.com Cc: qemu-devel@nongnu.org, 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> <179096166122.3025252.2345560702508398440.b4-review@b4> MIME-Version: 1.0 In-Reply-To: <179096166122.3025252.2345560702508398440.b4-review@b4> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: Fi64AEVRSU2nhdG0qqxlmkdklR6Fo4Nj26zBC9LE-bQ_1791192388 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-purgate-ID: tlsNG-d62444/1791192394-BCB45757-B4D9F5C1/0/0 X-purgate-type: clean X-purgate-size: 870 On Fri, Oct 02, 2026 at 09:21:01PM +0400, marcandre.lureau@redhat.com wrote: > > Essentially all PCI infrastructure is in scope for the virtualization > > use case, aside from the niche simba bridge. > > > > You should exclude the CXL bits though, as stated on cover letter. Yes. > Also questionable perhaps: xio3130, pcie_pci, pxb The latter two are both reasonable as long as i440fx is around, and xio3130 is a core documented part of QEMU's PCI-Express support, though I've never understood why one would want it over pcie-pxb. Overall, I think all the generic PCI/PCI-E infra is in scope. 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 Mon Oct 05 09:29:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:29:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440645.1658048 (Exim 4.92) (envelope-from ) id 1xDf0a-0001bY-Mm; Mon, 05 Oct 2026 09:29:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440645.1658048; Mon, 05 Oct 2026 09: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 1xDf0a-0001bR-K7; Mon, 05 Oct 2026 09:29:20 +0000 Received: by outflank-mailman (input) for mailman id 1440645; Mon, 05 Oct 2026 09:29:19 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDf0Z-0001bF-J4 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:29:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDf0Y-006jog-S9 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:29:19 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac36de6-2eae-0a2a0a5409dd-0a2a4504e6a8-14 for ; Mon, 05 Oct 2026 11:29:18 +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 6ac36ded-b57f-0a2a45040019-aa0a817cc7c7-3 for ; Mon, 05 Oct 2026 11:29:18 +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-453-1ZELo3cIMrCOlbnw_6lU1Q-1; Mon, 05 Oct 2026 05:29:13 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 605A818007E7; Mon, 5 Oct 2026 09:29:12 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7F7051956087; Mon, 5 Oct 2026 09:29:10 +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=1791192557; 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=VWEaBtZdiYhiKz5AQwLJW7nAdhFU5R4j3oWNHV/QcxM=; b=EwNL0HLoFKFd3iLhXWMx8jhihS68BGr3kvf5pngTUSQO+3aQba47mPwTmwALuVWcIT0aBE I5N1wISrv9J/0soL7YDUeKZfbAg4GDM0qQt2jZccSBd7FkupTMd8WotPR+jywFYnb6alhw mzcxSP/4kOAzLeC+WYi4NFy9gnSLQ/g= X-MC-Unique: 1ZELo3cIMrCOlbnw_6lU1Q-1 X-Mimecast-MFC-AGG-ID: 1ZELo3cIMrCOlbnw_6lU1Q_1791192552 Date: Mon, 5 Oct 2026 10:29:07 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: marcandre.lureau@redhat.com Cc: qemu-devel@nongnu.org, 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 03/28] hw: mark all virtio PCI devices as secure Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-4-berrange@redhat.com> <179096166110.3025252.6768256984831473183.b4-review@b4> MIME-Version: 1.0 In-Reply-To: <179096166110.3025252.6768256984831473183.b4-review@b4> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: HEfXvylwsgBW1mCJkWKesFV_DSsI5BJUj6R79zJNEm4_1791192552 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791192558-C1ED6B50-CEEBF26C/0/0 X-purgate-type: clean X-purgate-size: 2415 On Fri, Oct 02, 2026 at 09:21:01PM +0400, marcandre.lureau@redhat.com wrote: > > 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é > > Message-ID: <20260911143627.2743803-4-berrange@redhat.com> > > > > diff --git a/hw/display/virtio-gpu-pci-rutabaga.c b/hw/display/virtio-gpu-pci-rutabaga.c > > index 4db77cb868db..a8e5e1d96cf3 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, > > This is unusual, I wonder why it's not using the VirtioPCIDeviceTypeInfo Yeah, I don't know the reason for that choice. > > > .interfaces = (const InterfaceInfo[]) { > > { INTERFACE_CONVENTIONAL_PCI_DEVICE }, > > { }, > > diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c > > index 22659ca196b5..0b0d926a5b95 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, > > This is a base class, probably doesn't need marking. Not /yet/. I have a follow on series to this, not yet posted, which will enforce that all parent classes are marked secure, when any leaf is marked secure. There will be many more base classes to add besides this one, which crept in here. 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 Mon Oct 05 09:37:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:37:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440651.1658059 (Exim 4.92) (envelope-from ) id 1xDf83-0003Lr-DU; Mon, 05 Oct 2026 09:37:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440651.1658059; Mon, 05 Oct 2026 09:37: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 1xDf83-0003Lk-9x; Mon, 05 Oct 2026 09:37:03 +0000 Received: by outflank-mailman (input) for mailman id 1440651; Mon, 05 Oct 2026 09:37:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDf82-0003Le-D7 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:37:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDf81-005VN3-1U for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:37:01 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac36fba-8faa-0a2a0a5109dd-0a2a4508d974-16 for ; Mon, 05 Oct 2026 11:37:00 +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 6ac36fbb-f659-0a2a45080019-aa0a857c8863-3 for ; Mon, 05 Oct 2026 11:37:00 +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-664-NDcwWLWuP2eiW956REEg6Q-1; Mon, 05 Oct 2026 05: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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 961E61802140; Mon, 5 Oct 2026 09:36:54 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2144930000E4; Mon, 5 Oct 2026 09:36:51 +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:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1791193019; 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:in-reply-to:in-reply-to: references:references; bh=unMt6qLPTr1avyGPe2yQEJ/PPmJh/DMbiX+AetxVrf4=; b=AtzXtctx3CAPe/WWHzIol7bx8G/XR3EtlJkt/p5rAZNx3FUx1xOzlrsm0fdGRZjTMMLO1B aigV1QBnlz4zECrsx4WuDqk3OV3EWuFwnzIfX/ZkNWXzxbL8Ms4gc5BG4zO/YNYQmHqwDl C55B/s+FSbLo5JmCQ5EwNDmZVtD7pxc= X-MC-Unique: NDcwWLWuP2eiW956REEg6Q-1 X-Mimecast-MFC-AGG-ID: NDcwWLWuP2eiW956REEg6Q_1791193014 Date: Mon, 5 Oct 2026 10:36:49 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: marcandre.lureau@redhat.com Cc: qemu-devel@nongnu.org, 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 17/28] hw/display: mark bochs, cirrus, qxl, VGA, ramfb as secure Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-18-berrange@redhat.com> <179096166126.3025252.2006364005625327282.b4-review@b4> MIME-Version: 1.0 In-Reply-To: <179096166126.3025252.2006364005625327282.b4-review@b4> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: -RxoKNRGurLtlK2cij4mfaie1Lz9qCQrBEQEYPA8w4A_1791193014 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-purgate-ID: tlsNG-c1860d/1791193020-DFCD387B-9869C12A/0/0 X-purgate-type: clean X-purgate-size: 1309 On Fri, Oct 02, 2026 at 09:21:01PM +0400, marcandre.lureau@redhat.com wrote: > > 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. > > I don't think we should support all those display devices as security boundaries. Opps, this bit of the commit message was not quite right, as I did NOT in fact include VMWare VGA. The Cirrus & QXL is an area where my downstream wishlist conflicts with my upstream wishlist, because both were widely used for a long time in virt scenarios, and they still exist in supported RHEL versions, even if gone from the latest releases. > I would shorten the list to: bochs, ramfb, vga, and virtio-gpu* > (excluding virgl & rutabaga). Anything else has been known to > have various risks and is much higher complexity.. NB, anything virtio related is handled elsewhere in this series.a 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 Mon Oct 05 09:39:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:39:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440657.1658066 (Exim 4.92) (envelope-from ) id 1xDfA8-00044e-QG; Mon, 05 Oct 2026 09:39:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440657.1658066; Mon, 05 Oct 2026 09:39: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 1xDfA8-00044X-NT; Mon, 05 Oct 2026 09:39:12 +0000 Received: by outflank-mailman (input) for mailman id 1440657; Mon, 05 Oct 2026 09:39:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDfA7-00044M-CD for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:39:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfA6-006m8r-7B for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:39:10 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3703b-8faa-0a2a0a5109dd-0a2a4507c638-6 for ; Mon, 05 Oct 2026 11:39:09 +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 6ac3703c-b4ea-0a2a45070019-aa0a857cd47b-3 for ; Mon, 05 Oct 2026 11:39:09 +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-574-eIPyz1uXNNe0JUYtKo6Ylw-1; Mon, 05 Oct 2026 05:39:07 -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 BFAF519539BA; Mon, 5 Oct 2026 09:39:05 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CA95C30000E4; Mon, 5 Oct 2026 09:39: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=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To: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=1791193148; 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:in-reply-to:in-reply-to: references:references; bh=XTD33Ze437RIyD1HN/Z7Ka/Uk5oV0YYG4eEC0r6aeQc=; b=NmD8RtJjATHT8up/yn6n6Hclh72gqQalC60Fis1TT0R/aZXIjvrUxKzEi9zCR9mfUuroMk KqDJScO2Ad7woEZGH+E1HTavaf4XlPamunIiZkI+0Q33kx1RnIwv9tz69TsCeZVIPLW1wh XXd8i4xEGU3rJRdj0ZW7nvFqM3HsZtA= X-MC-Unique: eIPyz1uXNNe0JUYtKo6Ylw-1 X-Mimecast-MFC-AGG-ID: eIPyz1uXNNe0JUYtKo6Ylw_1791193146 Date: Mon, 5 Oct 2026 10:39:00 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: marcandre.lureau@redhat.com Cc: qemu-devel@nongnu.org, 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 10/28] hw/usb: mark commonly used USB devices/hosts as secure Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-11-berrange@redhat.com> <179096166117.3025252.2297105460212965387.b4-review@b4> MIME-Version: 1.0 In-Reply-To: <179096166117.3025252.2297105460212965387.b4-review@b4> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: kQ0pJsUGUiOpfTZlIsMdvg0saiG40zMLq3gpUmMoy4k_1791193146 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-purgate-ID: tlsNG-ef75cf/1791193149-376D2AE4-310E3B9B/0/0 X-purgate-type: clean X-purgate-size: 1045 On Fri, Oct 02, 2026 at 09:21:01PM +0400, marcandre.lureau@redhat.com wrote: > > 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. > > Can't we exclude uhci/ehci nowadays? RHEL-10 still ships both, so there's still a demand from a downstream POV, but USB is in an awkward place with its lack of maintainership, and arguably these should be considered obsolete. 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 Mon Oct 05 09:43:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:43:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440663.1658076 (Exim 4.92) (envelope-from ) id 1xDfEI-0005hJ-9Q; Mon, 05 Oct 2026 09:43:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440663.1658076; Mon, 05 Oct 2026 09:43: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 1xDfEI-0005hC-67; Mon, 05 Oct 2026 09:43:30 +0000 Received: by outflank-mailman (input) for mailman id 1440663; Mon, 05 Oct 2026 09:43:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDfEG-0005h6-Ou for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:43:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfEG-006mz0-1I for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:43:28 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac37134-8faa-0a2a0a5109dd-0a2a4501bf7a-20 for ; Mon, 05 Oct 2026 11:43:27 +0200 Received: from [74.125.229.42] (helo=mail-dy2-f42.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3713e-5984-0a2a45010019-4a7de52a8925-3 for ; Mon, 05 Oct 2026 11:43:27 +0200 Received: by mail-dy2-f42.google.com with SMTP id 5a478bee46e88-3511f5f79e0so455658eec.1 for ; Mon, 05 Oct 2026 02:43: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-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1791193406; cv=none; d=google.com; s=arc-20260327; b=oG94yUMeYtM1nn4SL3UKA8T/WlM8SefYoeCcT0f7piWFKROfTqB1gD+hWVzkOnDGWg egiE1Kyw+haA2aQSDqWR7lthFjH/0PuJukt22hc3VTkP0wqQZpQ0wfT6ZJcnhZXydfUb 00U/RrYnuQZrVbZiuZUjyVuY0I+rno4iWhyoO9QFTRl6BgzMX320UCZCfuY85JrFSxT/ CHmExjsv8Q18e5lwgJ07aXk9BafXp93xQs1H85IrPkIew+u1Kn0d0wyuwxtuCy/pzZp4 u60XY6T3E/vfxYusdZBoecyuIsWzt+E1KSoKxnAyEemZAIqMkGJEeIhBoBYRNahAi58D WUGg== 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=quhIV9GdtVDmTI8LUlH7i1DV+qV5VNc2ufrP6HZ3T1o=; fh=qQgayo031e06I1GDNrttdYn1vRpwjnfh4+F1VTvCGjg=; b=pN+pASFSLJtZ8a405ghQQG9wbB9v5jPrIcAzxAcBxFRMgEJTGC6vJsLBqU4EGP0Sb7 dW166leazqQHqTNT8KudBuKVXLTxj1pw62SGSWY5bZC3Jf69gTv1D7qaHmhvrpzHd1ha +uPdTpdevPVEInP+rQg0ltk26pgKtjoa9cSSy58wAFhJ4icGPFKgPuDGDsw8m1+Kz6jA wPdvJqRYLUYaFUeYka8apbraetBcyi19Go8X6Wklba4IuG0N3A1HygTUF6UK7ohyZQqp tKDEohtY2vKH6FyLdi6Wnqd1OSY3AOZtl+BYBx6tRIprwomMD3GEF06ag44hOPpkhYfK ziXg==; 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=1791193406; x=1791798206; 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=quhIV9GdtVDmTI8LUlH7i1DV+qV5VNc2ufrP6HZ3T1o=; b=R28mEZ7R52ENOes9OvfR3TuA2bA0bqg4ma0iFdl0qjhr3UPwZPziBo1XwJJ56ePJBH cQZgxNHj3RtLnw6s55wjvBkz5VX+3PBJDOX6FQxie8f/K5Bw1atIditG/w/44dCSEw0d VEXDczZi3B4e5jvzQ7fjIQV8vj8SLCS3sr1n8Fp9tb1zgUwdhX+rqOLZgyZ3UT/zxrbh pcA9+QmCgFDN12c1bdYBWnP8sEsY3tngKGWS2eVAROkoLVzUWZLRPDi9wReeE6O156Lp aF34kUPgIuZuklhBhM2UMkE18oped8SyVRm+pBzQwayn30x3C3luGejKK7woggOl7R4c YK1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791193406; x=1791798206; 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=quhIV9GdtVDmTI8LUlH7i1DV+qV5VNc2ufrP6HZ3T1o=; b=Jbes9yofGeWKE2heCr/8KXOj4ewIXX0z1hVlJkBJ02IUHl5hWyqKf0wG1wADPNQZPl xkWlJmsq9b8/CdmJwtuAjXZ2y0WJdB+/78jBPlDpaP+oW2YjBjJmtSW+eSyuXt2jW9hX wJAcEOlxIuH2YKPB6MzKoqqnzBdfF7Vcp9BUBmwl3O8FaVJoQFt097gUx16BjVpDGbtP CN6+13aVA73fEg17yzr3kaMGT5/ncgrCdJgnlMjMYbb2AsK8ZozjWsDgRIqn2y2z4Ueo 6INyrCjS/DZNgfqhYoUi0X7AdN8q3lX0ltVRW6nHGsNw3by15zxIep1m8l46BfI+VkFx B9nA== X-Gm-Message-State: AFuF++niNYcBKc4CHb6vj9Qt5C9JS5bgDNqFUoJbPctKdLR0+mUasEf9 vkon4oXLZmn5VaNo0ygehG4hwSf24qpDbwnWuB60x7ZjHKOESgJdxNA3XgVF7h6sXzDy2ZQTqQ1 tk2SFXGweSgYQ5OIZb4vm4HwNK8qnsD+t/jwI X-Gm-Gg: AYBFou3/tCP4D0DzgEu0Nub38XbNxvU9kqhmQ1AkFw1jlns5mxZ+s16rjRyFsJCZafN H6pBKytFOVp00m/yJTm0p/iQlFTaqu37iEcDFZiedK7uf5PAte/cksc26tjV6AIJ5PowE9oSkEC VSFKc/F3XoTtU09wxcg6N+9JygcQVnVSh5ctNNaTr7OydTHBAcabGPkuD1Ym2DjNvEG4Z/b8fa9 uPYaUTg4vu6bymBFcEZtvX0MoVo+sGgcJ2KDKnZkyk6oJGLGJ7mBs8oeCJ1nmv/dJvrmiPF0gcs sU/B6ksqOgv/BNceepdl3ELkvmq5L9VHQqBlLfqgfjcSN+Z4Mzy5QOg= X-Received: by 2002:a05:7022:f905:b0:14c:b520:7db with SMTP id a92af1059eb24-14f5af2666emr10623485c88.7.1791193405328; Mon, 05 Oct 2026 02:43:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Precious Date: Mon, 5 Oct 2026 12:43:12 +0300 X-Gm-Features: AclHuK_hO4lE2Gyp_iU3_ojXAJTEub0t_yvG9410xc6ZonwOcW9qHN4L0gk9Nzc Message-ID: Subject: Re: Newcomer looking for a small first task To: r4ahim Cc: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000a64476065d14b628" X-purgate-ID: tlsNG-d62444/1791193407-1E465757-26E3B009/0/0 X-purgate-type: clean X-purgate-size: 3376 --000000000000a64476065d14b628 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One of the ways I find what to work on is search through the code comments by doing a grep scan(example that searches the tools/ & excludes qemu/) - $ grep -rnI --exclude-dir=3Dqemu* "TODO" tools/ For misra rules violation as per(docs/misra/xen-static-analysis.rst) - $ xen/xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra --cppcheck-html -- -j$(nproc) A html report then gets generated in the directory(/xen/xen/cppcheck-htmlreport) As for documentation updates there is on-going work to convert relevant pages from the Wiki to .rst format for the new Xen handbook - Contributor handbook - https://handbook.xenproject.org/contribution-guidelines.html - Gitlab handbook - https://gitlab.com/xen-project/websites/handbook - Once youve made relevant changes you can submit a merge request. On Fri, Oct 2, 2026 at 1:27=E2=80=AFPM r4ahim wrote: > Hi, > > I'm new to Xen, running it under QEMU (Xen builds and Dom0 > boots). I'm preparing my first patch and I'm most interested in > PCI passthrough, vPCI and the IOMMU, but I'm happy to start > anywhere. > > Is there a small unclaimed item (a MISRA violation, docs fix or > XTF test) that I could take? > > Thanks, > Abderrahim Meriah > > --000000000000a64476065d14b628 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the ways I find what to work on is search through t= he code comments by doing a grep scan(example that searches the tools/ &= ; excludes qemu/) - $ grep -rnI --exclude-dir=3Dqemu* "TODO" tool= s/

For misra rules violation as per(docs/misra/xen-static-analysis.r= st) - $ xen/xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra --c= ppcheck-html -- -j$(nproc)

A html report then gets generated in the = directory(/xen/xen/cppcheck-htmlreport)

As for documentation updates= there is on-going work to convert relevant pages from the Wiki to .rst for= mat for the new Xen handbook
- Contributor handbook - https://handbook.xen= project.org/contribution-guidelines.html
- Gitlab handbook - https://gitlab.com/xe= n-project/websites/handbook=C2=A0- Once youve made relevant changes you= can submit a merge request.

On Fri, Oct 2, 2026 a= t 1:27=E2=80=AFPM r4ahim <mer.r4h= im@gmail.com> wrote:
Hi,

I'm new to Xen, running it under QEMU (Xen builds and Dom0
boots). I'm preparing my first patch and I'm most interested in
PCI passthrough, vPCI and the IOMMU, but I'm happy to start
anywhere.

Is there a small unclaimed item (a MISRA violation, docs fix or
XTF test) that I could take?

Thanks,
Abderrahim Meriah

--000000000000a64476065d14b628-- From xen-devel-bounces@lists.xenproject.org Mon Oct 05 09:44:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:44:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440667.1658084 (Exim 4.92) (envelope-from ) id 1xDfFQ-0006AR-H9; Mon, 05 Oct 2026 09:44:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440667.1658084; Mon, 05 Oct 2026 09: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 1xDfFQ-0006AK-Eb; Mon, 05 Oct 2026 09:44:40 +0000 Received: by outflank-mailman (input) for mailman id 1440667; Mon, 05 Oct 2026 09:44:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDfFO-0006AC-93 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:44:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfFN-00105k-KC for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:44:37 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac37181-8faa-0a2a0a5109dd-0a2a450ae1e0-28 for ; Mon, 05 Oct 2026 11:44:37 +0200 Received: from [52.101.84.99] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac37185-f2d2-0a2a450a0019-34655463ba60-3 for ; Mon, 05 Oct 2026 11:44:37 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by DU5PR03MB10390.eurprd03.prod.outlook.com (2603:10a6:10:516::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 09:44:35 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0472.016; Mon, 5 Oct 2026 09:44: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=Tgx0loYsbJKfssRlkv7vkrDtV8QVvjeKkRQ0z2TvxLYP6sCYRxc1JOWZX5YMzYgdHHTDxcOKkDnD0x5i8N6UgHZ6Nkmrii6eJgbhxGcMJbzWu1d/yRHia3KVnEUHdZCS2z/gWf4zk482TAbhzfZE62Hn0M+JCE016H5rpnfx+W/FcUBm1Gj3kI8bYkhNCPyycJDn6x0PCFV5zE05uHLhP5w5C/F+Qv//hA4JRLjdgPWMF69vG0mx7Arqp2Toscxd3qZNLGZBgCFDshpG2zO3WSVH/fpGUN/DizWQ3ljAOLCHr/epH3ctWsMy075riMkrWl5vCvwz6AHcms98zXwIaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9pnCXQKrzQrfUUdy+YjIJvH6HSIvNs9n2WNml8n6OrI=; b=AeCMiFglRr1kP7owyHLNW7UCtVgoRLpD8wV3xxMm6SqsaTahGIrqnioDAF2AoWBOnoyxWjNc6Jpu6X2+FbsQuB9pNAjuhbPkLk5vZyLk+z/PzYs82H6BMzecDi54KsrOPzcCFMKMlULHMqK674hZQkmu4ma+GY8+vmtKNmTBNAnOyqJqSHD9ij/RF2h1N5siFVYgIQl+XfFi+zhJMTcSDdtPtAqzo/wjWdpLNFXMkVBuI1eIK34hsgGdOcmKf4y/1IpcZfSfS+PwloKUg5AACdEuoBiQ8u3VHyfTjAm63kSyir/P0p4pKF7eVbm3LcThKwnLzZJ52cphyWR4e8Xpww== 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=9pnCXQKrzQrfUUdy+YjIJvH6HSIvNs9n2WNml8n6OrI=; b=jd6rCHHAzk+3WTx3aYAAjGA65ve2JA4W+MmT9RVSIcsKiJkKZ8SuJAzYmjX4yLgQlaeUPjYyRn4jmXEpokV5xYPMAz8+ev4ecOdaG9yGx2uKBsGNl3JFHenwiAXStnRKeDH4uv7td6CXwMuotKEhh9Uq0x3UVz+bqg187eiCX2wP3FbawECGq/sDUnT6HePJBkHaMHmlSGmcq70MzH9ErXRHRpkKCcZwo6pSJw8SXwdgCsWXSKy7SMOcm0bIp/4wYpl5VljMF/5u1OijHh1OlHd0v+av8aB+tac3gCqik1UzmhFUzHyUpjlG9wLDa/qQFQTCoi8zznKGG4z5YL3+nw== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation Thread-Topic: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation Thread-Index: AQHdNrs5d+cYyXDbRECyxJjufAxZUrbHhHsAgAANlgCAAA5igIAABi4AgAAr2oCAAf2rgIAD60EAgCEzPIA= Date: Mon, 5 Oct 2026 09:44:35 +0000 Message-ID: <0b7ba176-cec3-435f-9b2b-793a68e0e153@epam.com> References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> <46dcfb81294d6f644a4d3f3c11b1f47e@bugseng.com> In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|DU5PR03MB10390:EE_ x-ms-office365-filtering-correlation-id: bdaff581-691a-4da4-5466-08df22c543cf x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|23010399003|42112799006|1800799024|22082099003|18002099003|38070700021|4143699003|11063799006|6133799003|10067099003|56012099006; x-microsoft-antispam-message-info: 5Fsq912XgsI3ZvlK/Y+LBlEfyCSWz/BRsUvclmbnOD5x/7UTVtc2WvqWWkwVvkRIAucRzR7y9WCaEtTNy2hUuJmEqjOo1tTGtQbYvT7f3L9xkJt7+D+oHzSBAWUbTRWaDcJ428fZgaRNfse6rL3HDRCbIARkq1kG0JzYB0XwcSZksAmHpJqRQDmlWdB5zoiop9K+8VzNVcnIy3GjuR8uZagzpNMbJrN4Wfi1xm+6qYamtDuJX5Q+7wzehS1I/hoWnIrQ5EXG9ev6V5nhG42/fFiMRDJFYL3uUGf3K3m1xr8X6AthmKP1KZXkHHSB9hnsSN+KenH4+01Yx1HASSnYdDA66+3STVFwbeKdPPAdBjOGIt0d5meE+tGfcIptgYNl0NSm8S6DgCtDCISvi2N4uUyVOiRcXwS8OwWcvtlFJwcXZhdL2GganeaXyjUiK6OF2To3Ujygv4QxfCEjGH3DGXXc5tFVVb2op6iF/obu0UicpsL5lMiKTwbaBgpZpiY1VQ6pvX+RUM3dSWm1MVegmpce3UaC/EN3D4xfcP6IQkDRbducq+Sowc0AO6DAOsH6WrgDerxZe84X/z5QxuH4qmsrUhpGRgB81ujdAZHXfw2/RV2mM7jVS/3a42fV7KcZu8dXxiGuauKb53Moh3FIOAW5KxZNQv7jAB7kdBx/mgYjbhy9YmJHBMQqh2LLKuEp+kV+gDfu5l3ywqhLC/jb6HkrArn42/iOXhyi7PR5448= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(42112799006)(1800799024)(22082099003)(18002099003)(38070700021)(4143699003)(11063799006)(6133799003)(10067099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dzR5UDVvRkhWM2dWOEhjQm44UWNtLzBiUDRseHYwMlAyeEZDSFN4ck80S0ho?= =?utf-8?B?c25TM0lqWWprQ0hhU2V0V29hNStsSlNUWFVGeWdhY2NLdi9McXhLeUZ4V1Qv?= =?utf-8?B?Z08wWm8vY0x0clU1NjZWdVU3UjQ4VHU5aVM3TlZld3l1aG9mNEVkVm9jakJ4?= =?utf-8?B?eHRETlRZTVZCVVpLQk9lLzloajNGTVh4NW5aOVlSTWcyempEYW9KaU41L2Nu?= =?utf-8?B?UWR3eGxxSVVDUUlWc08vMmJweWFEL29lNWNrZHVtVjZiYS9lUHNpMmFFc1Y1?= =?utf-8?B?SFA0Z2VNelVoZEFSLzhPdVhBZ1R5N0FlTFdwN2VaRk5DbXkzQUMyN21EcDV6?= =?utf-8?B?YmVIK0VIL05NMDhpZ1lJTmhRMytRanNJenV5SUthdlhFSW5ralBXK2pkUWFX?= =?utf-8?B?QVgxbU1DSlN0K0R2TnV2WGVKZzBHTk9JSjJCQ0VFazVCVnRWZGloM3d0M04v?= =?utf-8?B?UExBY0tXUjNjQVhnOVFPZElWRDVROFc2WDRxMXN5cFBFcXhQL2o3UUtyWGhH?= =?utf-8?B?Z1M2MFB6ZU1wR0pBSXA2Y1FGTUd1VkRjOWRvWkJVdzhQNWsvalh2Z1dLUVdL?= =?utf-8?B?a3JZZ2FCbElqTG54Vlh1cldkd29OU2tJakJTK2x6MXJ3RXFZUWtqeE1jaDRo?= =?utf-8?B?SVcxN2hMdEszSXp4NVlCMVZndXBLaGc1MzZBazRadTZDbTVvajUxTEM4MlBu?= =?utf-8?B?NjdTV2ZNbEJWR1RHcGRaVzN2ZXRGNTZNMFpab1hZMUxWTndwWlhXV2pvOU1W?= =?utf-8?B?aHFmd29ZVUswL3hkQ3IraWFMZkl5bGFlaEw2cGNiZEhudTFXS1E2MUZxZGQ5?= =?utf-8?B?S2UrL1JzQTJ0WUZ6YXNZdjZWZU41ZTRjbmpPdS95ekxIMTg5bFY2YWN0QVZE?= =?utf-8?B?UG9DRmtZVDhsbzVaUFZ2cXpOSVdlSTI2TXYyb1VVTG9mdGFZQXJyUmpKdHFk?= =?utf-8?B?Q0hTUEQ0VnlYZkljZ3JyTVc2VVhmZ1k4R2VjL2ZlRytmS3lTUTA2RzRVajJ4?= =?utf-8?B?QlNVcnFNY1MyYXFpQkpuc2pGSHdTN0hZWmNGbWVLMnVvSTUvR0FUS3JUajc0?= =?utf-8?B?dWhCbkh4eG9paGtRbEFBTkQ5NWtSQ0pnSmh0YXRza2JGVFB0VnFtU0NWQUk3?= =?utf-8?B?RDZuVXVqL3BRMnNnZlFqbVo1NmZmQnRFU2ZaRW8xTiswc016K2d2aUE4YmdK?= =?utf-8?B?Mno0MHJCRWtkKzhCZEp3UmVreDNVeGVCZy9MajNnZFo3V2pxdDgrZUNRR3hn?= =?utf-8?B?cUhiTVd0emNQQ2p1QVJLcDVUekgzUElkczJXeVpVLzVQVWNSQkc0Y0xXWHpa?= =?utf-8?B?Q2RJc3JRZUdXbmNyZ3hBczlDMGtUU0o2cEhYZHJZN0dhYVBCOUl5T1lPS09M?= =?utf-8?B?RHd0UnFkRERBQ3R6N3ZNaGI1aW9XQ1hPV2R1dStsQTF4R0NVL0dldUVDSzUy?= =?utf-8?B?TUhsbFRpcEllSER0MURiM0U3K081bjJTRFBWN0I3R3JvaW92Y2VaYURGcUln?= =?utf-8?B?NTRZNldWaTNZWjIvQ0U3YnNOU09saDlWempyQjd1aHBOSUx4OUpHd3hDVy90?= =?utf-8?B?enpLT3lnOVloRXhkdi9BK0cwL0ZET25KeEg0bXJWaGRSOS9UYmRHLzFKV3Nh?= =?utf-8?B?S2pJZDMxTDBlMXhkWS84a2NZdmxQajgvLzVVQXl4ZGNBaE1IeWpZcDRjU2dp?= =?utf-8?B?cTcwT0ROZ2V0NXdWcFVWU29uYVdrVVRHMVpOMWJhQm9KMlIyaTBRY291UUVw?= =?utf-8?B?VEl1SGNTU2VqNWtrRGxOMFY0ZUZRQlJkVkNZcjlCazFyTXhFZjdxUTBYUXBu?= =?utf-8?B?a3NEZzZhbjhDVDg0UUxyanFkaXJKSy9zZW15V28xWnZENTZKNTBMMmVXU2xL?= =?utf-8?B?N0lGTThZTVpKN2lLUjVYOHRsQytZREVNUEttbmdLRjl1ay91M1Zxd0VRRC9R?= =?utf-8?B?WDJBMDJDN1RCQmZBM1B1c0hweURtZkZYQ3lYQXhvVXpMejh3ME5pNWg4bkR6?= =?utf-8?B?WDgyeWxJNlFhZ1NOOS9iZ1QxWHY0VnE4bXM2QXp0cHp5ZmJ3RzlKZFB4R3VI?= =?utf-8?B?ZHF0L1Q3Z09jT3Q5ZS9mcVQ0d3h2T3ptcTF5aFFsRUZpTDJKNlZwRmNoc3Nn?= =?utf-8?B?MjhQa0FQUGIrbVlFdG9nTEhXZWJQcDU2ZmdlZVVTZ0Iwczg4aldXcWIvdGE2?= =?utf-8?B?TnRGbHkwMEJ0TG9Wajk1VnJWYndwa05UTG5OcTZDVE0wRlo0bE1Qek12dndQ?= =?utf-8?B?THd0TjZKOHY2RFcrUjVYb1g2cUd6TXpFWFZmVVJnS0J5N2JYUmxDRnowcWNV?= =?utf-8?B?MjEvdHlkNElVc2hjazFBWDRvUnF5K2M2Yll5MzIxV3A0MzFCVmF2Tjltcjdm?= =?utf-8?Q?5TiRo7QJvbRgyqz4=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <0F40A71840CF2D4ABCB20080D30E64A7@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bdaff581-691a-4da4-5466-08df22c543cf X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2026 09:44:35.1425 (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: 8TqnJzXWcvz3fYoYVfhJDpAZNVmZ6FIJ6hMWIbg70o6AMmq5JKmF0QRIf3GFDYwr3+Xi1sAvvvR1CaGnrcPX9mIWz8mlD/J60exIZYKu9/g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10390 X-purgate-ID: tlsNG-4011c0/1791193477-4BED2CFC-1F313C99/0/0 X-purgate-type: clean X-purgate-size: 5050 DQoNCk9uIDkvMTQvMjYgMDk6NDQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMS4wOS4yMDI2 IDIwOjUzLCBOaWNvbGEgVmV0cmluaSB3cm90ZToNCj4+IE9uIDIwMjYtMDktMTAgMTQ6MjksIFJv Z2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4gT24gVGh1LCBTZXAgMTAsIDIwMjYgYXQgMTE6NTI6 MTBBTSArMDIwMCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+IE9uIDEwLjA5LjIwMjYgMTE6MzAs IFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+PiBPbiBUaHUsIFNlcCAxMCwgMjAyNiBhdCAx MDozODozNEFNICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+PiBPbiAxMC4wOS4yMDI2 IDA5OjQ5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+Pj4+PiBPbiBGcmksIEF1ZyAyOCwg MjAyNiBhdCAwOTowMjoxOEFNICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4+IFRo ZSB1c2Ugb2YgdW5yZWFjaGFibGUoKSwgd2hlbiB1bnJlYWNoYWJpbGl0eSBpcyB2aXNpYmxlIHRv IEVjbGFpciAoYW5kDQo+Pj4+Pj4+PiBjb21waWxlcnMpLCBpcyBkZWVtZWQgYSB2aW9sYXRpb24u IERyb3AgdGhlIHJlZHVuZGFudCBzdGF0ZW1lbnQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFVyZywgaXNu J3QgdGhhdCBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgZml4ZWQgaW4gRWNsYWlyIHRoZW4/DQo+ Pj4+Pj4+IE90aGVyd2lzZSBhbGwgdGhlIHVucmVhY2hhYmxlKCkgY2FsbHMgaW4gb3VyIGNvZGVi YXNlIGFyZSBsaWtlbHkgdG8gYmUNCj4+Pj4+Pj4gZm91bmQgYnkgRWNsYWlyIHNvb25lciBvciBs YXRlciwgYW5kIHdpbGwgbmVlZCB0byBiZSByZW1vdmVkLg0KPj4+Pj4+DQo+Pj4+Pj4gTm8sIGFp dWkgbW9zdCBhcmUgY292ZXJlZCBieSBkZXZpYXRpb25zLiBJbiBwYXJ0aWN1bGFyIG9uZXMgaW4g QlVHKCkgYW5kDQo+Pj4+Pj4gQVNTRVJUX1VOUkVBQ0hBQkxFKCkuDQo+Pj4+Pg0KPj4+Pj4gU2hv dWxkbid0IHRoaXMgYmUgYSBkZXZpYXRpb24gdGhlbiBhbHNvPw0KPj4+Pg0KPj4+PiBNYXliZSwg anVzdCB0aGF0IEkgaGFkIG5vIGdvb2QgaWRlYSBob3cgdG8gZXhwcmVzcyBzdWNoIGEgZGV2aWF0 aW9uIChwcmVmZXJhYmx5DQo+Pj4+IHdpdGhvdXQgYSBTQUYgY29tbWVudCkuDQo+Pj4+DQo+Pj4+ PiAgwqAgTWF5YmUgaXQgd291bGQgYmUgaGVscGZ1bCBpZg0KPj4+Pj4gdGhlIGNvbW1pdCBtZXNz YWdlIHN0YXRlcyB3aHkgdGhpcyBpcyBoYW5kbGVkIGRpZmZlcmVudGx5IGZyb20gb3RoZXINCj4+ Pj4+IHVucmVhY2hhYmxlKCkgaW5zdGFuY2VzIHRoZW4uDQo+Pj4+DQo+Pj4+IEkndmUgYWRkZWQg Ii4uLiwgLCBhbmQgdGhlIG9uZSBoZXJlIGlzbid0IGNvdmVyZWQgYnkgYSBkZXZpYXRpb24iIHRv IHRoZSBmaXJzdA0KPj4+PiBzZW50ZW5jZS4gV2lsbCB0aGF0IHN1ZmZpY2U/DQo+Pj4NCj4+PiBU QkgsIHRoZSBoYW5kbGluZyBvZiB1bnJlYWNoYWJsZSgpIGZlZWxzIGluY29uc2lzdGVudCB0byBt ZS7CoCBJIGRvbid0DQo+Pj4gYmxhbWUgeW91IGZvciB0aGlzLCBJIGtub3cgeW91IGFyZSBqdXN0 IHRyeWluZyB0byBmaXggdGhlIHJlbWFpbmluZw0KPj4+IGlzc3Vlcy4NCj4+Pg0KPj4+IEkgZ3Vl c3MgSSB3aWxsIGRlZmVyIHRoZSBjaGFuZ2UgdG8gc29tZW9uZSBtb3JlIGZhbWlsaWFyIHdpdGgg TUlTUkENCj4+PiBhbmQgd2h5IHNvbWUgdW5yZWFjaGFibGUoKSB1c2FnZXMgYXJlIGNvdmVyZWQg YnkgZGV2aWF0aW9ucyB3aGlsZQ0KPj4+IG90aGVycyBhcmVuJ3QuDQo+Pj4NCj4+PiBJIHRoaW5r IHRoZSBwb2ludCBvZiBhZGRpbmcgc29tZXRoaW5nIHRvIHRoZSBjb21taXQgbWVzc2FnZSBpcyB0 bw0KPj4+IGp1c3RpZnkgd2h5IHRoaXMgaXMgcmVtb3ZlZCB2cyBhIGRldmlhdGlvbiBiZWluZyBh ZGRlZC4NCj4+DQo+PiBBY3R1YWxseSB0aGlzIHNob3VsZCBiZSBkb25lIHdpdGggYSBkZXZpYXRp b24sIGFuZCBJIHRob3VnaHQgaXQgd2FzIGFscmVhZHkgdGFrZW4gY2FyZSBvZiBieQ0KPj4NCj4+ IC1jb25maWc9TUMzQTIuUjIuMSxzdGF0ZW1lbnRzKz17ZGVsaWJlcmF0ZSwgImNhbGwoZGVjbChu YW1lKF9fYnVpbHRpbl91bnJlYWNoYWJsZXx8cGFuaWN8fGRvX3VuZXhwZWN0ZWRfdHJhcHx8bWFj aGluZV9oYWx0fHxtYWNoaW5lX3Jlc3RhcnR8fHJlYm9vdF9vcl9oYWx0KSkpIn0NCj4+DQo+PiBu YW1lbHkgYmVjYXVzZSB1bnJlYWNoYWJsZSgpIGV4cGFuZHMgdG8gYSBjYWxsIHRvIF9fYnVpbHRp bl91bnJlYWNoYWJsZSgpLiBJdCBtaWdodCBiZSB3b3J0aCBjaGVja2luZyB3aHkgdGhhdCBpcyBu b3QgdGhlIGNhc2UuIFByb2JhYmx5IHRoZSBjb25maWd1cmF0aW9uIG5lZWRzIGEgc2xpZ2h0IHR3 ZWFraW5nLg0KPiANCj4gUXVlc3Rpb24gKG9uIG15IHNpZGUgYXQgbGVhc3QpIGlzOiBIb3cgd291 bGQgc3VjaCAiY2hlY2tpbmciIGxvb2sgbGlrZT8NCj4gQXMgc2FpZCBlbHNld2hlcmUsIHRoZSBz eW50YXggdXNlZCBpbiBhbmQgdGhlIHNlbWFudGljcyBvZiBhbGwgdGhlc2UNCj4gZGV2aWF0aW9u cyBhcmUgY2xvc2UgdG8gaW1wb3NzaWJsZSB0byBmdWxseSB1bmRlcnN0YW5kICh3aGljaCBpcyB2 ZXJ5DQo+IGNlcnRhaW5seSBkaWZmZXJlbnQgZm9yIHlvdSkuIFlldCB3aXRob3V0IGZ1bGx5IHVu ZGVyc3RhbmRpbmcgd2hhdCdzDQo+IHdyaXR0ZW4gYXQgcHJlc2VudCwgaG93IHdvdWxkIG9uZSAi Y2hlY2siIHRoYXQgdGhpcyBpcyBhY3R1YWxseSB3aGF0IGlzDQo+IHdhbnRlZC9uZWVkZWQ/DQo+ IA0KPiBKYW4NCg0KSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UgdGhlIHZpb2xhdGlvbiBpcyBjYXVz ZWQgYnkgdGhlIA0KX19idWlsdGluX3VucmVhY2hhYmxlKCkgaXRzZWxmLCBiZWNhdXNlIGl0IGlz IGxvY2F0ZWQgYWZ0ZXIgZm9yKDs7KSwgDQphY2NvcmRpbmcgdG8gdGhlIEVjbGFpcidzIHJlcG9y dDoNCg0KeGVuL2FyY2gveDg2L2NyYXNoLmM6MTE5LjUtMTE5Ljc6IGBmb3InIHN0YXRlbWVudCBp cyBvbmUgY2F1c2Ugb2YgDQp1bnJlYWNoYWJpbGl0eSBvZiB0aGUgbmV4dCBzdGF0ZW1lbnQNCnhl bi9hcmNoL3g4Ni9jcmFzaC5jOjEyMi41LTEyMi4xNzogcmVmZXJlbmNlIHRvIGZ1bmN0aW9uIA0K YF9fYnVpbHRpbl91bnJlYWNoYWJsZSh2b2lkKScgaXMgdW5yZWFjaGFibGUNCjxwcmVwcm9jZXNz ZWQgeGVuL2FyY2gveDg2L2NyYXNoLmM+OjE2MDA3LjUtMTYwMDcuMjU6IHByZXByb2Nlc3NlZCB0 b2tlbnMNCnhlbi9pbmNsdWRlL3hlbi9jb21waWxlci5oOjUwLjIzLTUwLjQzOiBleHBhbmRlZCBm cm9tIG1hY3JvIGB1bnJlYWNoYWJsZScNCg0KVGhhdCBkZXZpYXRpb24gIi1jb25maWc9TUMzQTIu UjIuMSxzdGF0ZW1lbnRzKz17ZGVsaWJlcmF0ZSwgDQoiY2FsbChkZWNsKG5hbWUoX19idWlsdGlu X3VucmVhY2hhYmxlIC4uLiIgaXMgYWJvdXQgY29kZSBwbGFjZWQgYWZ0ZXIgDQpfX2J1aWx0aW5f dW5yZWFjaGFibGUoKSAoSSBob3BlIEknbSByaWdodCkuDQoNCkFjdHVhbGx5LCBFY2xhaXIgc2F5 cyB1cyB0aGF0IHdlIGRvIG5vdCBuZWVkIHRvIHBsYWNlICh1bm5lY2Vzc2FyeSkgDQpfX2J1aWx0 aW5fdW5yZWFjaGFibGUoKSBhZnRlciBmb3IoOzspLg0KDQogRnJvbSBteSBwb2ludCBvZiB2aWV3 LCBKYW4ncyBwYXRjaCBpcyBPSy4gTWF5YmUganVzdCBuZWVkIHRvIG1lbnRpb24gDQp0aGlzIGxv b3AgZm9yKDs7KSBpbiBjb21taXQgbWVzc2FnZS4NCg0KRG15dHJvLg== From xen-devel-bounces@lists.xenproject.org Mon Oct 05 09:53:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 09:53:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440677.1658093 (Exim 4.92) (envelope-from ) id 1xDfNS-0008E5-Ds; Mon, 05 Oct 2026 09:52:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440677.1658093; Mon, 05 Oct 2026 09:52: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 1xDfNS-0008Dy-At; Mon, 05 Oct 2026 09:52:58 +0000 Received: by outflank-mailman (input) for mailman id 1440677; Mon, 05 Oct 2026 09:52:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDfNR-0008Ds-QF for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 09:52:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfNQ-00CqqS-8G for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:52:56 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac37369-8faa-0a2a0a5109dd-0a2a4505c14e-46 for ; Mon, 05 Oct 2026 11:52:56 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac37377-4cb1-0a2a45050019-d1558031ddf0-3 for ; Mon, 05 Oct 2026 11:52:56 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a1728d8dfcso6324225e9.1 for ; Mon, 05 Oct 2026 02:52: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 ffacd0b85a97d-48c62270751sm2495205f8f.13.2026.10.05.02.52.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 02:52: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=1791193975; x=1791798775; 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=yLSxE39zfGWs2/80XvybgFNsxV7lAuWIpT6PZOwBWwQ=; b=Q/cn+izEE/IH5TjBNVy60gN69vSouHnYViRjcZ7NlOC0p3+oZAa8j7R1vuKeyC14LM t5HEuUYyKGEN5q7u7U/n8SIcO+TqoYzKMFyGVkpR74oiNoTfVcWKdsrNiJDd1C2NWbzr RNYLtbK72K9tv4RXjFJAhPyaaFLyld19gOfUz9OWWl6m9Ez1Br1XtypnuCrtbBqVCijq YIOOr1UWFTGVbOBgr3zmBB7Mw5CA54L3oE1QFUktV2CnpQgT9EtKKZC4hJSUy/R5f+mj QHBzvRPCRgMDNonFXaAaoeJojG0ZjWQbrZZEsXO0ouK9xRE9x1YIwI+uNdsZdmSvBmW+ dmnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791193975; x=1791798775; 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=yLSxE39zfGWs2/80XvybgFNsxV7lAuWIpT6PZOwBWwQ=; b=ldEG1UC8ghtHwQh3LjrLJXkrqDa/cZiz0DWO81nHaxhcBZnItWc7YHfrcttFwGtKSw nzYTGi1kEwo85yHfd7wARi5kTMDBWNvAiVAjgZ7MFLPVjVIJDtCSRpvB0RVbbg8JZiNF R8RmJ7W5UMlj3NOR8J3ZbXGY1Vv754kXePRwrMjYYX/S9CJ0N3HM2gpi5hpbDyM5JPZ/ sSTcnNLV2ylOm8BtmMQXWFVtEhpT7FwWHjygxO7BWOejakiwHsn9nCI6JX6HKsj5AC9D q68px7QG8yZct6fycMCJYTgXfsyjj68T/yVuhqA3v9AV6/ggP5BZLNeSYVTZY6k4AWaI VyMQ== X-Forwarded-Encrypted: i=1; AKwUvBwT8PDfrQ52DPQ669/UcLiMsLI/h+pDC8XqEkbqRE3pqygVZNY4k+tg1wFXevji3bXFby/1cgZTxI8=@lists.xenproject.org X-Gm-Message-State: AFuF++meIFnXXJ4oiohn7f/+aInn0ym+34uNWV8F5Ilhb4DqgxUFGMx+ ujHL4+oaBCC4r6Efh/PfPKHWO/Ft/NghcNYZiMboU6CKNlO51lIefKQhUio5jVaqeg== X-Gm-Gg: AYBFou2CHIBcOx6Ji6UhbBoNEu7NAf62UCybQdYmgYpS1YcIuaZ/q+efxtkm42fPNwS 37n+CqRitEg5wP1qH+0zuC0PtcyESLYHco9J+NSJy4KqYwX+63+uhihugE/JD2YzZKedFw9kCnc uydlFdrJFpqHGDX8N2xsBmqrGCNHVCJ7a/iBblLLM7lv7F7yNKw57j71MXu10edB/PE+0+klldP aXK7xTFZka9TwJGDVw8cKx9Q0bJtJq1PIdzN2wXymfoeITPAreLKc1rAflYZeChlf5uP2mptrdk AkqgoIQCK50pbIhVe9Xbh2IRyWEXRHII/TP/y/BjjFvcw4sHaemlaj2V/szKecJzztf539/P9AG OREIbpxbXAQU+PtoHYFTUIdXfC8PNwwf4bunsIK7oZ43nTNk1JP+pk9bVpe+/LxmsL7jG9IBFry +c42ghLCk4v3Ggzj6vAU8DahqYU82lCzFzcElM108wL83GT8dlddJCGaZVXXfkIx3yGA4FH7bfS sd3l8LavmyBH6pi3GNNrai8pud/rLMhIr3ugWwY2iTaZqRrExSUK1Z1hF/pWA== X-Received: by 2002:a05:600c:c091:b0:49f:cbf1:e77b with SMTP id 5b1f17b1804b1-4a1680dd2c0mr75955775e9.10.1791193975538; Mon, 05 Oct 2026 02:52:55 -0700 (PDT) Message-ID: <95274f9b-985e-4f3e-801c-971558e5d8f1@suse.com> Date: Mon, 5 Oct 2026 11:52:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/pdx: fix merging of a range contained in the previous one To: Weiqi Wang Cc: roger@xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang , xen-devel@lists.xenproject.org References: <20261004190357.29254-1-coolhaoyt@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: <20261004190357.29254-1-coolhaoyt@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791193976-251182A1-A693845F/10/78276251493 X-purgate-type: spam X-purgate-size: 1207 On 04.10.2026 21:03, Weiqi Wang wrote: > From: Weiqi Wang > > When sorting and merging overlapping ranges in > pfn_pdx_compression_setup(), As we have two distinct instances of this function, at least one of title or description want to clarify that it's the offset-compression one. > --- a/tools/tests/pdx/test-pdx.c > +++ b/tools/tests/pdx/test-pdx.c > @@ -87,6 +87,18 @@ int main(int argc, char **argv) > }, > .compress = true, > }, > + /* Range contained in a previous one. */ > + { > + .ranges = { > + { .start = 0, > + .end = (1UL << MAX_ORDER) * 1 }, > + { .start = (1UL << (MAX_ORDER * 2)) | 0, > + .end = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 4 }, > + { .start = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 1, > + .end = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 2 }, Nit: The multiplications also want parenthesizing against the binary ORs. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:02:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:02:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440682.1658102 (Exim 4.92) (envelope-from ) id 1xDfWT-0001yY-8D; Mon, 05 Oct 2026 10:02:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440682.1658102; Mon, 05 Oct 2026 10: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 1xDfWT-0001yR-5Z; Mon, 05 Oct 2026 10:02:17 +0000 Received: by outflank-mailman (input) for mailman id 1440682; Mon, 05 Oct 2026 10:02:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDfWR-0001yL-4E for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:02:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfWP-002GHJ-Tc for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:02:13 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3759c-e002-0a2a0a5209dd-0a2a450ceb36-40 for ; Mon, 05 Oct 2026 12:02:13 +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 6ac375a5-f479-0a2a450c0019-b9ff1c22b207-3 for ; Mon, 05 Oct 2026 12:02: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 1a10b837ff10003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 10:02: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 54EE88229F; Mon, 5 Oct 2026 12:02: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=dzKwTJHgZhQq/BxCj2Ch5XAbAk/yxL8Vev/V87WiPss=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=QGpbZ4kgaNbPifbWbXVMe1g263J/0qwB8GVVZbC0Dtpe94S/vaY9OvrosA51qEvrPmIJmJByJ waoAjFkhKUXgr8pNqGRgLMr3VhkjlezLCtEKXMHl+vGXjCaflMPHplMI2jFfWucXa2kOQOkksZo LrMtQrfi0kO56Cj7aWWSaBkigA7wkJFmuJDHm5gVrOLApx2u/pSwqkDZa7vIyma1IH39xn7tekg Y/mCb8v13yI0WtLWLfjJARUM9fpQdqBMhNKzpfTs32T/tHj+UiFy2FrOcNs9rPOP/78kTXDPa98 q9K2cZYtwviS4x3p/7mHjk8omZ9qpGGCxdn2tnQn7QmQ== X-Zone-Loop: 5900a23c0f74a3b87b5a2a4278e11bf185031eeee765 x-campaign-type: default x-transaction-id: 540bbe92-4212-431f-bfd8-1537fd12dc6b x-swg-uid: 01-a2512732-6d35-4606-838f-093dad696ad5 X-Mailer: Sweego Message-ID: <1791194529.8631fc262581453bbf619ec5b2062170.1a10b837ff10003f66@vates.tech> x-swg-bid: 1791194529.8631fc262581453bbf619ec5b2062170.1a10b837ff10003f66 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 v3 01/39] xen/riscv: drop INSN_{16,32}BIT_MASK and report unknown instruction lengths 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: Mon, 05 Oct 2026 12:01:55 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791194522; l=780; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Zy50qDdvgBxA615NzC8TUXxN0sx3/zqTlwskflTilTc=; b=avADzk2a5am31h7sntL9qx9PQTucIGhuddIjE5lZC4Nozu2yX7cP6bTU7gY+8apv2yU06hYl/ uSlyiEt1HAFCO4ydiVgo9sqtXmpCmVYcZDPwrfzpWEo+IXOfos2YbP6 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: 1791194527553 X-purgate-ID: tlsNG-d25034/1791194533-778D5A5B-F0B75FB3/10/73395122804 X-purgate-type: spam X-purgate-size: 780 On Wed, 30 Sep 2026 18:18:43 +0200, Oleksii Kurochko wrote: > Both constants were inherited from OpenSBI and their names are misleading. > The length of an instruction is encoded in its low bits: bits[1:0] != 11 > means 16 bits, otherwise bits[4:2] != 111 means 32 bits, and anything else > is 48 bits or wider. 0x3 and 0x1c are the patterns compared against in > these two tests, not masks selecting a 16-bit or a 32-bit instruction. As > each constant is needed in one place only, once INSN_IS_16BIT() and > INSN_IS_32BIT() encapsulate the tests, drop them and spell the values out > in those two macros instead. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:02:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:02:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440683.1658112 (Exim 4.92) (envelope-from ) id 1xDfWZ-0002CT-FX; Mon, 05 Oct 2026 10:02:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440683.1658112; Mon, 05 Oct 2026 10: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 1xDfWZ-0002CM-BI; Mon, 05 Oct 2026 10:02:23 +0000 Received: by outflank-mailman (input) for mailman id 1440683; Mon, 05 Oct 2026 10:02:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDfWY-0002Bk-53 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:02:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfWX-00AbD4-5G for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:02:21 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac375a6-2eae-0a2a0a5409dd-0a2a4501e08c-34 for ; Mon, 05 Oct 2026 12:02:20 +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 6ac375ac-5984-0a2a45010019-b9ff1c22b5ed-3 for ; Mon, 05 Oct 2026 12:02: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a10b8381180003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 10:02:10 +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 70C2A82233; Mon, 5 Oct 2026 12:02:09 +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=PclicpCZjscwTzXE6nCMlYTvo4ShwnwW18JN2L7uXQw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=fSaXi0CXEeCVxV4diXERZoz3dfnuPHe/7wwx9SGdhAB8HYa6gcGEWEXQgfhmYilfg5Rb2Xz38 WuLFR2tqX1oP0UKypx80YyBHqSL3KjkUa34g8LwgF4XbsCa2ewlqM+pq/3LFX+7RfjUFhN0lHLM 7Bdhp+Mxt7jSymX2fuOjJum9B1Pb+ZNvCat5NQfv51eWlC071SHRhvx29Ny009L1weArZ9wEEtO 7xyMiJzM6APWX1mMRdk1X+fxxhG7baXkL1+tH2hGCFC7WD8gd80wH/k9Q0cWoqR+6Zwwy9MP4Ab ECs/iZvniNkKPTjxnckrqdaz0ZddPCiNKtWZgGDmzqwg== X-Zone-Loop: 73ade1bd51104a55599d4ce7c75989cb73dd92849334 x-campaign-type: default x-transaction-id: 8a1bdc34-aac2-4516-92ea-614ce030dc35 x-swg-uid: 01-0ee402d8-f9d3-4af8-a25a-9ce6de92d5d9 X-Mailer: Sweego Message-ID: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b8381180003f66@vates.tech> x-swg-bid: 1791194530.8631fc262581453bbf619ec5b2062170.1a10b8381180003f66 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 v3 02/39] xen/riscv: set the domain type for 64-bit kernel images 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: Mon, 05 Oct 2026 12:01:55 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791194522; l=529; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=YESupS+55RhfXssnfA68l9gJ9FU4CPCDX4/mBfXxfBc=; b=Ng+eFM3Wom0IRbLHF+V1c3Wd0NkqshQ+5TZNVO6TFNu3HalID2b07kMh7DiLrhCEjhMsL1A5b MOVD/7v9FKsAC2PgN67OLo9925QTVclIEaKbjFjD9xCw67j8jhpXR2P 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: 1791194529651 X-purgate-ID: tlsNG-d62444/1791194540-BF66C757-866C61F2/10/73395122804 X-purgate-type: spam X-purgate-size: 529 On Wed, 30 Sep 2026 18:18:44 +0200, Oleksii Kurochko wrote: > kernel_image64_probe() never set info->type, so every domain kept the > DOMAIN_32BIT value a zeroed KERNEL_INFO_INIT leaves behind, even though > Xen on RISC-V is only built for RV64 and accepts nothing but a 64-bit > Image. > > Nothing consumes d->type on RISC-V yet, so there is no functional change. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:02:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:02:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440684.1658122 (Exim 4.92) (envelope-from ) id 1xDfWf-0002Rg-ML; Mon, 05 Oct 2026 10:02:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440684.1658122; Mon, 05 Oct 2026 10: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 1xDfWf-0002RZ-I6; Mon, 05 Oct 2026 10:02:29 +0000 Received: by outflank-mailman (input) for mailman id 1440684; Mon, 05 Oct 2026 10:02:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDfWe-0002Qd-4T for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:02:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfWc-006qrC-VR for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:02:26 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac375b0-bab6-0a2a0a5309dd-0a2a450894b0-8 for ; Mon, 05 Oct 2026 12:02: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 6ac375b2-f659-0a2a45080019-b9ff1c12a5cb-3 for ; Mon, 05 Oct 2026 12:02: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 1a10b8382510003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 10:02:10 +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 BB6AA8231E; Mon, 5 Oct 2026 12:02:09 +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=5b+J475whSHXFa//6QTRvxLMmn5pluxKNzz5AOcA4eg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Whp4UsOn5mhPiKf0dO3/JJjc6jbOxEdaCfyo+v0Y2ioYgZJChFoDuS4DFENk98yeQI6Z+VZVY Cv+ja7gasipBqQVRNuIBG14wIoM79ru9LKpPUQF02MDoGBhfBW5rtA9njg1ezPO9ppt/kZcbLCE i8+f4Yz1nu8A9z2w93VvFqbqZHtCcKoTs0NBA/kJLM30NP0iUK9wA7LzqT339DW4YyT9iHgfhHj O/Z96uy1dhCm0UjxyM86PjKay1qlSDeq2fPTh/H/B8g3VNVdCntV970RmhcPZUsvsXaDzZ18VFz BO+dkTKI/DB69h7nAcAu3AJfmYKjnA9USA2xwzFltnBw== X-Zone-Loop: f417f44e4cdc619123655405721afc9163423f9bce13 x-campaign-type: default x-transaction-id: eb21f8eb-b7d6-4c76-8d71-65755a816dd0 x-swg-uid: 01-8331f927-06b6-4e65-b66f-044e7c6c35ce X-Mailer: Sweego Message-ID: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b8382510003f66@vates.tech> x-swg-bid: 1791194530.8631fc262581453bbf619ec5b2062170.1a10b8382510003f66 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 v3 03/39] xen/riscv: introduce csr_volatile_read64() 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: Mon, 05 Oct 2026 12:01:55 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791194522; l=348; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Xe+CSjx8UvYIPgtjrP4jHaCG1P9iAS3wBJUHnAhiUQ8=; b=5/g43PJN55eR6y+DkvtMlf2VhaFIqhxQan2LyRWTCFV/+nz0xbQgE2Jyf0iyH/zXnR1HifetU WQNfqnfS3NvBvSPR7gPO/jkqDn70+GuHxwI59bm33GJ+zHEbMKG/BZQ 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: 1791194529963 X-purgate-ID: tlsNG-c1860d/1791194546-CE34587B-9A264490/0/0 X-purgate-type: clean X-purgate-size: 348 > On RV32 a 64-bit CSR is accessed as two halves, and H. Reading As far as I can tell RV32 can't currently be selected (RISCV_64 is def_bool y, no RISCV_32 in Kconfig), so this path can't even be build-tested. Is the retry loop really needed now, or a least in this patch series? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:02:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:02:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440685.1658130 (Exim 4.92) (envelope-from ) id 1xDfWi-0002hA-S9; Mon, 05 Oct 2026 10:02:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440685.1658130; Mon, 05 Oct 2026 10:02: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 1xDfWi-0002h3-Ol; Mon, 05 Oct 2026 10:02:32 +0000 Received: by outflank-mailman (input) for mailman id 1440685; Mon, 05 Oct 2026 10:02:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDfWg-0002eG-Q0 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:02:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfWg-006qu4-6t for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:02:30 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac375b0-bab6-0a2a0a5309dd-0a2a450894b0-20 for ; Mon, 05 Oct 2026 12:02:30 +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 6ac375b2-f659-0a2a45080019-b9ff1c12a5cb-4 for ; Mon, 05 Oct 2026 12:02: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a10b83837a0003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 10:02:10 +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 12C018229F; Mon, 5 Oct 2026 12:02: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=+wwEDoIAPeisaQz6R6kuZnDSc6AQthUH+5/MlpxTDOY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=C0/iJ4AmUg4JZGVT9DjVnlymyqzr2eZtH1553Dv9RwZfErv7Y0bn0xrr1lFgvggQwY9PLL1O7 0OppzSqxMHDuKuuJAUanYsVn5OBDMFfLGai5Uc0b25iflIP+INk8kTT7myKaznD3eM8GfbhyYTZ 1ZWJIGJ9VTc+hw8ACh+kRF+5KB0mbbQMEb9iXmizLmZWOqb4VFf3lyA2jxFEpOzmtXkaQZPLfgK h4Rg0O5gg2+L3dke0OZ9aF6r8Jt4E+jzvQyRUWrEXVHA5rw7W2pdE9OKO15VCvUAAT5GgVq1qMY 8hQOBdh6wgYmZBEMj47T32LirfPEURT+nJD/euAI7ZnA== X-Zone-Loop: ec14c0ec98299dd303fa0c78afaaca0e4768805229fe x-campaign-type: default x-transaction-id: 10ca19c4-91d6-4192-927a-13c9561eba9f x-swg-uid: 01-ef4fc4e0-8e54-40b3-8c22-21187e2b315a X-Mailer: Sweego Message-ID: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b83837a0003f66@vates.tech> x-swg-bid: 1791194530.8631fc262581453bbf619ec5b2062170.1a10b83837a0003f66 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 v3 04/39] xen/riscv: request a G-stage flush on vmenter when VMIDs are disabled 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: <7b3e9a486b348470b3c3b371b6a8d3f7afe0e53f.1790779209.git.oleksii.kurochko@gmail.com> References: <7b3e9a486b348470b3c3b371b6a8d3f7afe0e53f.1790779209.git.oleksii.kurochko@gmail.com> Date: Mon, 05 Oct 2026 12:01:55 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791194522; l=655; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=j4JgF0xGEkESNg6kK43vyD+FWXZ8iz9SM5nOegSQeL8=; b=UG5OksGOHuNT/4R9c6hGku80T6pnhb/flDHeGb4S4Kd4O9Tehh5HyxKX5Vza1Y7jqhAi0q277 XISBOSok25jBK8olyaVTU4dXSZwfAJXyZC5CZYmbZteYPG8b0NjgE1q 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: 1791194530267 X-purgate-ID: tlsNG-c1860d/1791194550-CDB4987B-BBDA8ACA/10/73395122804 X-purgate-type: spam X-purgate-size: 655 On Wed, 30 Sep 2026 18:18:46 +0200, Oleksii Kurochko wrote: > vmid_handle_vmenter() reports that no flush is needed when VMIDs are > unavailable (e.g. 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. > > Report that a flush is needed on every entry instead. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:02:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:02:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440686.1658139 (Exim 4.92) (envelope-from ) id 1xDfWk-0002vu-8Q; Mon, 05 Oct 2026 10:02:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440686.1658139; Mon, 05 Oct 2026 10: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 1xDfWk-0002vj-4d; Mon, 05 Oct 2026 10:02:34 +0000 Received: by outflank-mailman (input) for mailman id 1440686; Mon, 05 Oct 2026 10:02:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDfWj-0002jg-7q for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:02:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfWi-00C22F-Kc for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:02:32 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac375b2-2eae-0a2a0a5409dd-0a2a4507bfb6-18 for ; Mon, 05 Oct 2026 12:02:32 +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 6ac375b8-b4ea-0a2a45070019-b9ff1c22b187-3 for ; Mon, 05 Oct 2026 12:02: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a10b8384c50003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 10:02: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 5CE7782233; Mon, 5 Oct 2026 12:02: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=jYgBYO2+/pVSYOaFH86+bomzi3sUUgzqL/IMu7ODsKs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=jG9XRpt/li9GdxGfcsD4oRF/j1Dpv6wGlXn/V7lAQYh/L5iNG3WBq7MtSAS3gordPO5ML/iyZ BRFd9yVoFsS4dAYH+sJOp6ZDYizA1mBAAFZWALdWs4Oi7QauFrF9h2FgPxjHkPZWpjetFb4GaZC arJjfaFaYbdGP8WDiV0AZJTSpSIZNRxn8WBifQWTW3xKawGMOkXuac/X52YAfZmq9VFQyABlkP2 +KYF22XlDiDmVxxjM1H+zJFVs0asCDrr8aLLcoZj0BEr0MXgnyO4qehVSuuYwbeXFBfSUV+0+pq KHSoR3t4/mRtkAiDXUjGASnPkk1uslUIuZHChg9Qg0DA== X-Zone-Loop: 092ea1dffb59ccfa57fca626cad2b7a01157a8ec0909 x-campaign-type: default x-transaction-id: a35cbfd6-00bd-462e-89b0-959ae06bd3b9 x-swg-uid: 01-94ed7337-9093-4faa-a79e-bdd141f90b69 X-Mailer: Sweego Message-ID: <1791194531.8631fc262581453bbf619ec5b2062170.1a10b8384c50003f66@vates.tech> x-swg-bid: 1791194531.8631fc262581453bbf619ec5b2062170.1a10b8384c50003f66 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 v3 06/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: Mon, 05 Oct 2026 12:01:55 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791194522; l=10702; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ah3KiSHFmBcrh/7SpADjFfm0QKjZcmYlujruQnPhoVQ=; b=3OPCgs+Ns3SdqXXQc5hgFOUPnLbf/OzN1l3as362seZRauBR+OULMciQvIBamo4xnRfA4QM1t fm5ac7ZBLEZBP+OnF2P3CbsvsRHIHFHB9WTCk1ST+FWGZy4E7cDauAU 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: 1791194530573 X-purgate-ID: tlsNG-ef75cf/1791194552-342F4AE4-73CF6F90/10/73395122804 X-purgate-type: spam X-purgate-size: 10702 > 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. > > 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 do_mmio() > entry point and remains agnostic of which device owns a particular > address. > > Nothing registers a handler and do_mmio() has no callers yet, so this > patch is a no-op; the trap handler is left untouched. > > Signed-off-by: Oleksii Kurochko > --- > do_mmio() gets its first caller in "xen/riscv: add guest load emulation > for trapped MMIO accesses" in this series. > --- > Changes in v3: > - Update the commit message. > - Capitalize the comments inside mmio_info_t and drop the list of access > widths from the one on len, as it could go stale. > - Drop the parentheses around the typedef names. > - Reject an access width which isn't a power of 2 in do_mmio(). > - Fold the !size check of register_mmio_handler() into end <= addr. > - Return -EADDRINUSE instead of -EEXIST for an overlapping region. > - Drop setting d->arch.vmmio.num_entries to 0, as struct domain starts > out zero-filled. > --- > Changes in v2: > - Drop copyright from mmio.c as it will go stale anyway as code moves > around. > - Drop the max_count parameter of domain_io_init() (MAX_IO_HANDLER is a > global boundary) and embed the handler array directly in struct vmmio > as struct mmio_handler handlers[MAX_IO_HANDLER]. This removes the > xvzalloc_array() allocation, the max_num_entries field and > domain_io_free() altogether; domain_io_init() consequently cannot fail > any longer and now returns void. Note this goes slightly beyond the > suggested variant in that max_num_entries is dropped as well, since > ARRAY_SIZE(vmmio->handlers) serves the same purpose. > - Drop the separate register_t argument of mmio_read_t/mmio_write_t; > handlers now produce and consume the value through info->data. > handle_read()/handle_write() are gone as a result, with > try_handle_mmio() invoking ops->read()/ops->write() directly. > - Turn mmio_read_t/mmio_write_t into function types rather than > pointer-to-function types, so that pointer-ness is visible at the use > sites in struct mmio_handler_ops. Constify the mmio_info_t * of the > write callback, which has no reason to modify it any more. > - register_mmio_handler() returns int instead of BUG_ON()ing on a full > table: -ENOSPC now lets the caller fail domain creation. It also > validates its inputs, rejecting a NULL ops (or one with a missing > read/write callback) as well as zero-sized and address-wrapping > regions with -EINVAL. > - Guarantee the non-overlap property that cmp_mmio_handler() relies on: > register_mmio_handler() checks the new region against both neighbours > of its insertion slot and returns -EEXIST on overlap. > - Replace the sort() call per registration with an insertion into the > already sorted array: locate the slot and memmove() the tail up by > one. sort(), swap_mmio_handler() and are gone. > - Extend cmp_mmio_handler()'s comment to state that it is a bsearch() > comparator and to explain the key/elem asymmetry; document why the > neighbours' addr + size cannot overflow. > - Fix over-long lines and a mis-indented label. > --- > --- > xen/arch/riscv/Makefile | 1 + > xen/arch/riscv/domain.c | 3 + > xen/arch/riscv/include/asm/domain.h | 3 + > xen/arch/riscv/include/asm/mmio.h | 63 ++++++++++ > xen/arch/riscv/mmio.c | 175 ++++++++++++++++++++++++++++ > 5 files changed, 245 insertions(+) > create mode 100644 xen/arch/riscv/include/asm/mmio.h > create mode 100644 xen/arch/riscv/mmio.c > > diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile > index 665ec26933..5454517724 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 d94652809e..fd62296356 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -310,6 +311,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..1bf48571a9 > --- /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 Should be ASM__RISCV_MMIO_H instead to be consistant with other header files in riscv/include/asm. > +#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 */ > + bool is_write; > + /* Store: value to write; load: value read (set by handler) */ > + register_t data; > +} mmio_info_t; > + > +enum io_state > +{ Style: should be directly after 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..cf739a790a > --- /dev/null > +++ b/xen/arch/riscv/mmio.c > @@ -0,0 +1,175 @@ > +/* 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 The else is not necessary here, misra would call that "dead code". Here are two suggestions: if ( info->is_write ) return handler.ops->write(v, info); return handler.ops->read(v, info); or: return info->is_write ? handler.ops->write(v, info) : handler.ops->read(v, info); -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:27:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:27:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440716.1658156 (Exim 4.92) (envelope-from ) id 1xDfuj-0008VD-A7; Mon, 05 Oct 2026 10:27:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440716.1658156; Mon, 05 Oct 2026 10:27: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 1xDfuj-0008V6-6Y; Mon, 05 Oct 2026 10:27:21 +0000 Received: by outflank-mailman (input) for mailman id 1440716; Mon, 05 Oct 2026 10:27:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDfui-0008Uu-81 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:27:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfug-00Ag0X-Hl for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:27:18 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac37b71-bab6-0a2a0a5309dd-0a2a4502a0f2-42 for ; Mon, 05 Oct 2026 12:27:18 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac37b86-6ca4-0a2a45020019-d155802be803-3 for ; Mon, 05 Oct 2026 12:27:18 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49d05d51553so11053535e9.2 for ; Mon, 05 Oct 2026 03:27:18 -0700 (PDT) Received: from LukeW.mynet ([143.58.214.168]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a0280b2e3csm384732015e9.5.2026.10.05.03.27.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2026 03:27: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:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791196038; x=1791800838; 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=kYmAFEk+9DyfFKrorv/uXWuca7Y+Cy0LJB7RP8dB/zM=; b=nB/xryQkI2FUZ+jpFe60U5k5su9dT74Puu4/jZo6W3xGVM+y2tAOGLWB4zJzC397Ve 8NaTWZEkdwQGDsrAhO2c3gvPxZ935yCxI1hIReuh4rz7rHg+6B7Pjf7f6J5oqYtp81Sq agjaSbmrR9s/Uwv8a4U0dYi+y59ITj+/WWSzgKasLqKZvioeLLZKgNUP7IjbyY3DuBaS NUU8Z0Rbw7QL84HBu48G5Tuklqnw78RWZYEbgbsUsCdEH+px0Hl/pBC2/c0uQwAKJrqE sRMTT7Qp0cd9mGUV3790vNoofGWNaABzuA8hzi51hjmUImNdLhSMvmhVV2jeciDhCvLR 7WmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791196038; x=1791800838; 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=kYmAFEk+9DyfFKrorv/uXWuca7Y+Cy0LJB7RP8dB/zM=; b=PTm3eLc4yzjZXSh72/s0WAon98l/gIE8pIEo6w0VoLkM/CCFBKv12OYjmb6DjJSIA4 Z6K1lbl7t58mvljBjfHVtoyZDZoaWXvncRKz61b3c97Hfnm/j8OPBL5nskdvyDatrNg6 u4dBKORn9P7BwiEGPKfoqYZjmrtvn4XD7F+WS4q6iMDNxEFrfLTmTAGbQ+MONzqczfz6 tnklX8dksI4Pk+PX8fwNPlQdXvo5sR0dI45qbWrzM4tLlUBg4cONNNPWJs9qIn0IgBHE UPzjQ22WFuXKNDwG9RNWf2judj2pCiRuvCXhSX0mPBSn35HGtV0jyxGyrqPmgpqMPkFN dLRg== X-Gm-Message-State: AFuF++lDvz57CBCajkgjBKBk4cAWu3OoAWqkl/jWBurCF+K9NpuIHA3D Fh4SkV+LzOQNbx7Wc42mh1MFMYh7QR+eHQv2urgY2pRyc2WRDDRzCJOyeSJHpu50FdVTEg== X-Gm-Gg: AYBFou3r0apvbhYzgsFZtOIIXVmbWMsIOurKP6HLgVqN4TaOLEnSPPb6uV/N2KJx+IQ 4WRXqBuqpjFZnAtgCYajPXcr7bd0tTWHCc3g71E0JoRX4ekYyZ8Tlx86GbhxSjnty7l+GH80sRz FxE5eWyvLG+JS1bqgxBfuCJtKYSdNVSyks+qdjalGumOvQFwcoWZGqmknXviLojsL46QVVW+fgN p7lYexjDh5p1Dx40YrUAdWtR5UtxHeupVmMkTqhXW7ni8vPcwE/J4hpJqF6RS/XrfLtJGkIafwi pxCw212ILLAHcYSiDV41NwFThyuYh2Gdyye/qTP9S39G3NcgdVeynjzUwH3spJDyVdZjRuqMgZ/ MVK34fS0MSNMyiiO3/4/GLl+lH8BESQuFRjmRG3T+kSb6Tfbg8MVIvoaYNmhByo0RALP7GP8i5N NWfwEOHaPzoQ0bpeHR6BO86US9c2KtFwnuJjxJVEg0d/Om2272ef3TcjjX45aa3nwoM54S+rg= X-Received: by 2002:a05:600c:314f:b0:49c:fc6e:a3e1 with SMTP id 5b1f17b1804b1-4a168106a95mr101986325e9.32.1791196037601; Mon, 05 Oct 2026 03:27:17 -0700 (PDT) From: Weiqi Wang To: xen-devel@lists.xenproject.org Cc: roger@xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang Subject: [PATCH v2] xen/pdx: reject regions crossing a lookup table index Date: Mon, 5 Oct 2026 11:27:16 +0100 Message-Id: <20261005102716.94054-1-coolhaoyt@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1791196038-F1AAD2AC-8B9ECB51/0/0 X-purgate-type: clean X-purgate-size: 5679 From: Weiqi Wang pdx_is_region_compressible() only looks up the table entry of the first page, and checks the region against [pfn_base, pfn_base + pdx_region_size). pfn_base need not be aligned to the table index granularity, so that window can extend into the next index, which belongs to a different range with a different offset. A region whose tail lies there is reported compressible, yet its last page on its own is not, and translates through the wrong offset. Also require the first and last page of the region to use the same table index. This can be reached from the coverage check in srat_parse_regions() when an e820 RAM range is not covered by the SRAT ranges, which is the case that check is meant to catch. Found with the ESBMC bounded model checker. The counterexample was confirmed by running it natively against the unmodified code. Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation Signed-off-by: Weiqi Wang --- Notes: Changes in v2: - the issue is not tied to huge addresses (Jan): replaced the example with a ~5 GB reproduction and dropped the 2^51 remark RFC because this was discussed when the offset compression was reviewed. In the v2 thread [1] Jan asked whether pdx_is_region_compressible() is correct when a region crosses a lookup table slot boundary. The thread concluded it was not an issue, on the basis that pages contiguous in MFN space are also contiguous in PDX space. The reproducer below is a case where that does not hold for the code as merged: the region is reported compressible, its last page on its own is not, and that page round-trips to a different PFN. The ranges are as srat_parse_regions() would see them. The RAM range is not covered by either SRAT range, which is the situation the coverage check in srat_parse_regions() is meant to detect. Built from tools/tests/pdx like test-pdx-offset, on staging (e4da182973) plus patch "xen/pdx: fix merging of a range contained in the previous one": region [0x4ca9b, 0x12982e) compressible: 1 last page: pfn 0x12982d -> pdx 0xa982d -> pfn 0xe982d The region is reported compressible, yet its last page round-trips to a different PFN. With this patch the region is reported not compressible, and srat_parse_regions() disables compression. 8<---------------------------------------------------------------------- /* Build like test-pdx-offset, from tools/tests/pdx: * gcc -D__XEN_TOOLS__ -DCONFIG_PDX_OFFSET_COMPRESSION \ * -I../../include -o repro-window repro-window.c * (after generating pdx.h as the Makefile does). */ #include "harness.h" #include "../../xen/common/pdx.c" int main(void) { /* Two SRAT-like ranges, in PFNs, on a ~5 GB machine. */ pfn_pdx_add_region(pfn_to_paddr(0x5bbd3UL), pfn_to_paddr(0xf18f2UL - 0x5bbd3UL)); pfn_pdx_add_region(pfn_to_paddr(0x1869bdUL), pfn_to_paddr(0x189f58UL - 0x1869bdUL)); if ( !pfn_pdx_compression_setup(0) ) return puts("compression not enabled"), EXIT_FAILURE; /* A RAM range not covered by either, as srat_parse_regions() checks. */ unsigned long s = 0x4ca9bUL, e = 0x12982eUL; printf("region [%#lx, %#lx) compressible: %d\n", s, e, pdx_is_region_compressible(pfn_to_paddr(s), e - s)); printf("last page: pfn %#lx -> pdx %#lx -> pfn %#lx\n", e - 1, pfn_to_pdx(e - 1), pdx_to_pfn(pfn_to_pdx(e - 1))); return pdx_is_region_compressible(pfn_to_paddr(s), e - s) && pdx_to_pfn(pfn_to_pdx(e - 1)) != e - 1 ? EXIT_FAILURE : EXIT_SUCCESS; } 8<---------------------------------------------------------------------- Other callers that rely on the same answer are mem_hotadd_check() and the EFI ram_range_valid() check. I have not run those paths. One behavioural change to check: with npages == 0 the new condition compares against pfn - 1. The callers I looked at never pass 0. Model checking (ESBMC, 2 SRAT ranges and 2 e820 RAM ranges, all free within a bounded address range, the srat_parse_regions() coverage check modelled) finds no accepted RAM page that fails to round-trip with both patches applied. It also finds no layout where the coverage check now rejects what setup accepted, with RAM equal to the SRAT ranges. This is bounded to 2 ranges. The existing tests in tools/tests/pdx pass in both mask and offset mode. [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg194095.html xen/common/pdx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/common/pdx.c b/xen/common/pdx.c index 23655ef3bd..52928faa15 100644 --- a/xen/common/pdx.c +++ b/xen/common/pdx.c @@ -324,7 +324,8 @@ bool pdx_is_region_compressible(paddr_t base, unsigned long npages) unsigned long pfn_base = pfn_bases[PFN_TBL_IDX(pfn)]; return pfn >= pfn_base && - pfn + npages <= pfn_base + pdx_region_size; + pfn + npages <= pfn_base + pdx_region_size && + PFN_TBL_IDX(pfn) == PFN_TBL_IDX(pfn + npages - 1); } static int __init cf_check cmp_node(const void *a, const void *b) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:27:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:27:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440715.1658149 (Exim 4.92) (envelope-from ) id 1xDfug-0008If-4O; Mon, 05 Oct 2026 10:27:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440715.1658149; Mon, 05 Oct 2026 10:27: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 1xDfug-0008IY-0u; Mon, 05 Oct 2026 10:27:18 +0000 Received: by outflank-mailman (input) for mailman id 1440715; Mon, 05 Oct 2026 10:27:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDfuf-0008IC-0I for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:27:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDfue-00C6Jd-DA for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:27:16 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac37b61-8faa-0a2a0a5109dd-0a2a45079a54-48 for ; Mon, 05 Oct 2026 12:27:16 +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 6ac37b84-b4ea-0a2a45070019-4a7de18cb153-3 for ; Mon, 05 Oct 2026 12:27:16 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49fff72474fso10940375e9.3 for ; Mon, 05 Oct 2026 03:27:16 -0700 (PDT) Received: from LukeW.mynet ([143.58.214.168]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a0394e6c5asm254502245e9.2.2026.10.05.03.27.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2026 03:27: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:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791196036; x=1791800836; 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=Pu7co6k1rQENL36cIepR1Ob3aaheC8u3llxMRwyghek=; b=XL0bE49RO/WfFy2YoEc49H1lpz3moR9N49c9WGSriJBFQKAN3sXjsb/KrUQTMHhU4C qbDDLZVtdzaQLTofLrS0GXk7atsTaeBqoByum1vTsXUrvlAA153FTmMaG9NnL09mq8db G5gkTs3yGVwXgLkZ0Yce7yw8xj/V5nqXP6ILNN0FA2PjUxCQoIC0G+OxrDyXRzW6W9dI uBPomR0UDKrUoSV6u0RS9v3fiNyZvxFqidtQapc04Ge6ICUdATACdzqqF+GSqKZlbZaI A8kp2/C2OaMA8tO0KLpOpMc8IKOowlJUgSlkx+2Sj6zGLKVOKwY15k8c0yhtc9ZSNoy+ TwEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791196036; x=1791800836; 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=Pu7co6k1rQENL36cIepR1Ob3aaheC8u3llxMRwyghek=; b=R/By/e4fCRE5hllBiP61IQ+8O+VRnTOU2xq1jgTdmR08DXKfElbdxBXd8K5bkWie9Q ZNZAgFztw0QutnNIN2MoA+ryYqYrU7raG7BHgRYYS4rf1DkVkxcqinSzkUgPrrEgSXMB 2pjHxohy7lZhpT8FCi9DuIdhl6KRdrjlXsGhB670CegcuP95/3phLnjwzFTlj0NFBsll +yQebOcjK93Lci7Cu8MMXn9BQbrTgOwHgwPuBAiVemXtN8qBzm7C4ii5rC3L1N0C3S4h Oin0Ql4sG1XdWkARe15so4jV63rjqslR3zdRkEhndb6lrixohl+RU+CxObARZxZN8hq/ IbhA== X-Gm-Message-State: AFuF++mBCIv3577rxEn0K4yYit62Mc7o/plBvDcRHAHTMXe8IFEQVq24 nJYoi9BPMYyrzLWU9X6mq+JTVvPzOmrxrQ7OdXb9/RI2A1jgCjcP9eZv5I6G+yFu5Ps3Xg== X-Gm-Gg: AYBFou2F6r85dCkzWk27skzgme0Xh4OzsCUMSPOfqUf0Ht9aFxKU9l7o+EfmtjqCJED mL3PmzVOueFrcvsbLjZeaf+pE/IuPHUE6urJeMuDMLmx8JiB5LXUXw/dlUaGMN5L4snE/hSf3R1 mdv8HoWV6ThV5ufIhPCrDsLAexxdytxS2t1OtDRsoFQ+p7QMn7r5Eiu2wmFltY/K8w98zI9qTmg xFJfVWXv9xZoYbF5EIOuPgpTotBZJM3lHCrkaSw9bdhdBvzfnqjeCJtgH/2sVRvekEvgEWLqMzK PsKbCNs54GtHYBlO+9nWTAA0dfrFUhDo0Ke3jnX7HPWPmwJZwWCffemlmJZU50mkYeLxkHKGxSh UIXPi+dfLFad3z/WCpzP0X2SZX6i6gFgShHe7Qm4Tu2vSzfzK6jAPK/OzvYVE2JrdvZmb89VRLy KuUKIkJ4a7mCf/+h+KTYVmSI4moumNSxS84gTF3MamziniK/V7YbWfQS3F8W3nlPyVIM74mw== X-Received: by 2002:a05:600c:638e:b0:49e:6c11:c4fc with SMTP id 5b1f17b1804b1-4a176581e87mr8450775e9.7.1791196035568; Mon, 05 Oct 2026 03:27:15 -0700 (PDT) From: Weiqi Wang To: xen-devel@lists.xenproject.org Cc: roger@xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang Subject: [PATCH v2] xen/pdx: fix offset-compression merge of a contained range Date: Mon, 5 Oct 2026 11:27:13 +0100 Message-Id: <20261005102713.94033-1-coolhaoyt@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1791196036-374D3AE4-CA8F57B6/0/0 X-purgate-type: clean X-purgate-size: 4370 From: Weiqi Wang When sorting and merging overlapping ranges in pfn_pdx_compression_setup(), the merged range is set to end where the second range ends. If the second range is fully contained in the first, this truncates the first range, and the tail of it is then neither compressible nor translated correctly. Keep the end of the merged range as the maximum of both ends. On x86 the ranges come from the SRAT memory affinity entries, and overlapping entries for the same node are tolerated with a warning by the NUMA code. The caller's subsequent coverage check catches the truncated range, so the effect is that PDX compression is disabled with a "RAM region ... not covered" message rather than memory being mistranslated. Add a test case that fails without this change. Found with the ESBMC bounded model checker. The counterexample was confirmed by running it natively against the unmodified code. Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation Signed-off-by: Weiqi Wang --- Notes: Changes in v2: - clarify in the title that this is the offset-compression instance (Jan) - parenthesise the test multiplications against the binary ORs (Jan) Also seen in a real boot: the hypervisor alone under QEMU (pc, 8 GiB), built from defconfig, with no -numa and a hand-built SRAT passed with -acpitable. Memory affinity entries, all PXM 0: [0, 3G) [4G, 9G) [5G, 6G) [1T, 1T+1G) The third entry lies inside the second. The NUMA code prints "overlaps with itself" for it and accepts it. Without this patch: (XEN) PFN compression using lookup table shift 23 and region size 0x200000 (XEN) range 0 [0000000000000, 000000017ffff] PFN IDX 0 : 0000000000000 (XEN) range 1 [0000010000000, 000001003ffff] PFN IDX 32 : 000000fe00000 (XEN) PFN compression disabled, RAM region [0x100000000, 0x23fffffff] not covered With it, the same output as without the third entry: (XEN) PFN compression using lookup table shift 28 and region size 0x400000 (XEN) range 0 [0000000000000, 000000023ffff] PFN IDX 0 : 0000000000000 (XEN) range 1 [0000010000000, 000001003ffff] PFN IDX 1 : 000000fc00000 tools/tests/pdx/test-pdx.c | 12 ++++++++++++ xen/common/pdx.c | 5 +++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c index 4de8d43d86..8d271a488f 100644 --- a/tools/tests/pdx/test-pdx.c +++ b/tools/tests/pdx/test-pdx.c @@ -87,6 +87,18 @@ int main(int argc, char **argv) }, .compress = true, }, + /* Range contained in a previous one. */ + { + .ranges = { + { .start = 0, + .end = ((1UL << MAX_ORDER) * 1) }, + { .start = (1UL << (MAX_ORDER * 2)) | 0, + .end = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 4) }, + { .start = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 1), + .end = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 2) }, + }, + .compress = true, + }, #endif /* PDX compression, 2 ranges covered by the lower mask. */ { diff --git a/xen/common/pdx.c b/xen/common/pdx.c index e7e16e193e..23655ef3bd 100644 --- a/xen/common/pdx.c +++ b/xen/common/pdx.c @@ -393,8 +393,9 @@ bool __init pfn_pdx_compression_setup(paddr_t base) (ranges[i - 1].base_pfn + ranges[i - 1].pages) ) continue; - ranges[i - 1].pages = ranges[i].base_pfn + ranges[i].pages - - ranges[i - 1].base_pfn; + ranges[i - 1].pages = max(ranges[i - 1].pages, + ranges[i].base_pfn + ranges[i].pages - + ranges[i - 1].base_pfn); if ( i + 1 < nr_ranges ) memmove(&ranges[i], &ranges[i + 1], -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:38:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:38:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440728.1658166 (Exim 4.92) (envelope-from ) id 1xDg5K-0002mR-CH; Mon, 05 Oct 2026 10:38:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440728.1658166; Mon, 05 Oct 2026 10:38: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 1xDg5K-0002mK-92; Mon, 05 Oct 2026 10:38:18 +0000 Received: by outflank-mailman (input) for mailman id 1440728; Mon, 05 Oct 2026 10:38:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDg5I-0002lE-Uo for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:38:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDg5H-0024Cw-Hz for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:38:15 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac37e03-8faa-0a2a0a5109dd-0a2a4506c76a-38 for ; Mon, 05 Oct 2026 12:38:15 +0200 Received: from [40.107.130.142] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac37e17-195a-0a2a45060019-286b828e89cd-3 for ; Mon, 05 Oct 2026 12:38:15 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by DU6PR03MB10967.eurprd03.prod.outlook.com (2603:10a6:10:5c3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 10:38:12 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0472.016; Mon, 5 Oct 2026 10:38: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=CmIG3S9C4uubAXDt71hfImYoYbgsrEwkf8VUa8KIatATuBRpEBe2Ft+EvLfMGUjXklQt6vw/KFXsLOXYQp5mKMzCMQvBIj4z4pZa84JFwmsBM9xEGj54f1RINGwzZi1GxqvT7PehtyntcMoX0A4um0TJBccwLYh53tiJl4PtdO3U0k5wkSDtfbQgQERE0tpr2DW6lmwQGj6rMHyWzVLSNd3lQiKjRNdNmzI1iVuXGQc3pwu8/1yQLovOf3/m2ZyC35QSBBxEVmZwp2QdI+ibXTfS388gsOhmdi9nkPTuiik5b9cYr+7/8v2/sUiPmP+ntiPKqsd0/EMw87mX/w8/4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TJhOiI1D5xUBlpAiqrtu3EP57Qh8aYWsgMZ5he6gzp8=; b=o+MkHa52zY1pjP3wMzvkbVVdPGL361c07ezJPbKpN7mPtlEvNXptZNh47Qp9CyFoKayy6eM7+yRS+ZG+cxvwoWoDSlyjRw+S6J8LRInI94xcGpQr++SQtidjEGApGVvBuZBE6R68Yps2XxHBW1uvNKvsXuE8PHivTQbf+5jgQbCnRny/4MOBplM3Mvum8hefhl9B1x9q/lDc8leD/t+RT9odtcWu0ksEBC+ptlRfUb09iGMCSZRUL4XKI99kDyijUNOJdHQ7SsWkSDIlj/8DnBoY9g9F+Oz4X4PGOgyPfIEQIXXDykevwbyuvyhal7DfDKKNxf8HkTvmfqqFYMdGKA== 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=TJhOiI1D5xUBlpAiqrtu3EP57Qh8aYWsgMZ5he6gzp8=; b=Ii3uKOT/cBmUObg6AxRCrQFD4z+Qh8BETnSjSWTUnhfNSlWyoti8SGrw1N4UnSP0L4kMyzVJF2qeXm3IEr5M/zzYz3bNo/eFWl60YDXEUpmPDzt0XTg3+cxFNunF+BvJ1NRcQi6J5flWNN8l1dH/aw9v+wc3OA2ARm6MLTPxLzQnB1cHVSlSwlNxrbjs4AquYKBX00CP7yHk4BOPAEMZcHO9BLMWD014IC5oJkPmIN2dfuROMUQaYEetAw9cZdX4exttUHV+ynW21z8i+/fPb3EN4M6Y54klXkgZcLHDHgiH6LuNjn9jM+zFuzRilKz8bJpuhuXKju/kaz3U32bjgw== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 06/12] kexec: machine_reboot_kexec() doesn't return Thread-Topic: [PATCH 06/12] kexec: machine_reboot_kexec() doesn't return Thread-Index: AQHdNrtNnuxIk3AqN0yIVRN5rIwRg7azOR0AgDvEqIA= Date: Mon, 5 Oct 2026 10:38:11 +0000 Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <26fe76ce-db8f-4641-aeea-667fb6ee3932@suse.com> In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|DU6PR03MB10967:EE_ x-ms-office365-filtering-correlation-id: 3d316d82-1367-4593-99e2-08df22ccc146 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|42112799006|376014|22082099003|18002099003|38070700021|4143699003|6133799003|10067099003|56012099006|11063799006; x-microsoft-antispam-message-info: XW3BadbHnis7JChwrgrGgHK/KqMAN506FXnoQ5a5+cBI/JAubLIiID01RKQrXTT6sHJc7QChTNaY1aKanEJAVPvWbMaL+GInO0X7SjKRofugvwDeiXngopyOKcMKmduVxsrGuSHl6Mv90QLG7niwV3e9EK3X9wd8yG+1zU8iygn1AeFqqwR6nlmBinD7s0mwLNV9EP30zow+u/Qcxj93wXEDGtR2oMZNp8oTLvlPe0Ab6t5Bxc3BJclQKkyZ7CTwQcoYYVm1dzS8s8Yd+GHUCavosAcqe4Q2uVATitaJ6pToKIPE2Fd7b10TO1YWFTOJwv6U9dJRPY9AzgLYBgsBznL4FQoC7m9YdPZFVttNp53gKK8vp51SPleQZ1x0kuWqELNMCGrtvaYqjyCjbjsiHQt99HQuvp+fP+jZysS+upEMfI4pCu/9j0FyUu0QYnsLNpLphhRZvSvxhNuWhByboXAbfx3WfDueO2A604McUM3weO/VNtwtEYTjK7MGJM2fLffRVMCqKGypG7muWv9JyOzd79wVu50qhbz5kiZv7hiTmbQEhLW68I67Fba+b1rdcWfbiG/IsOrX6uZoRxT1xpN1cZT1HER8yDOLKBqaJhqGHjgFctq+2k9D7PNRYjTc06LlpbqhFJxM6N4A3Wt9tOCIm1WSlS+jeB5v9k+xxPl0deW1ZAKLtmtIFDk/fvYCdXC1ZnPa1WnLHwbp97UvQB4WVGoEm8uw99dyxeTopOU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(42112799006)(376014)(22082099003)(18002099003)(38070700021)(4143699003)(6133799003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MkhPRVdjbEtaeW84NFAzQzZ5d1FjYjdGOGRTT1pBajdzcWdMTERxWDRCYWVq?= =?utf-8?B?R0t1TGdRZ3ZSUnQ0bC9jZ25PK2xuT1Q4eWNVNTJIdEVaQXpTN0prL3FYRGFX?= =?utf-8?B?ZmR0dGZKUmd3elM4ZVhRbkhxeU1mTnNMQlh6a210NjRvTEdEMWdiclNHSTRi?= =?utf-8?B?YTJNZjQrV0plejYxOHFySFpZWVdKZ0VmL3M1WktsRVVMVERnYjJ5MlIxdzlY?= =?utf-8?B?dUtnSjJwZmdEZk53bVVyTFBNYlY4ZVdMVEtPYkRzbE55ZzBCOGtsaHhaSWRN?= =?utf-8?B?L2gyYVhHd1R4dW0vcHZ2N2V3TEZIRHFWYVFGNUpwbFFkVlJPMVZuRjZaS1J5?= =?utf-8?B?MzBxYXArWmJJbTcwZW0zb09BTllEbS96RXhkQXpNc2p0emZ5TmM0Y0IzaG9E?= =?utf-8?B?NTR5c0pKN0lCd3lhTWRqNUZUVWhiUzlTSWJWL3RCNDRFeTNBNFgwMTA5eUxH?= =?utf-8?B?K1VGUnZHTUFYVXliWFFMcXh1RndQWFFjdlR2SU9Ic2dhQktma1pvZHRwbC9j?= =?utf-8?B?Lzd5TkJnOHJSNTV6VzNFNFJyTjZWcWNic0t0eENoZUxvNWdsaDhvZHlEeWJR?= =?utf-8?B?REkzd24xYk9FVWlmZmJDUzUyU3ZhZk9XMFhONHVYamVxT3NIZXU1RFFEVUtM?= =?utf-8?B?OGVRaFViZkM0MWxrbW1jWUtBUHhkMmsxQjJoUUcxODdBZnI4MlJKNTFQZ2JB?= =?utf-8?B?VUtUOEI0eEx1ZmttWkNRdnREVUkra1VxQnZ4Szd1a1g3RExVYzJ0TVJQeXRs?= =?utf-8?B?MllFUUp0d0d5aysxbVBCUDdtblplT1l0T1EySld3a2FySmtSL0Y0Z2Z4ZTJW?= =?utf-8?B?RGh3YWdvRHR2a3JrOWJXWFdLRzVORjBuUnV2b0ZKL0N2TjJKcmRSUnQwS3h6?= =?utf-8?B?MHJNV3NMclhJcTBPY0pXRkwyRjVwemc1Skh0WXRvaS9pMWNJL2ExY3NqblNj?= =?utf-8?B?QjlYT1UvalIvOHA0b21UNHd5Ry91NTFkazV1cnRKZkIxUWxtOXpGWHM1Qysz?= =?utf-8?B?blp6L2VsV0dMRVNzWVhqcTdpeHRoWHdqZUhkMXkwcWNPbHJFNXVWVTZrRHBY?= =?utf-8?B?RkNwMzc0OWsyQURnY2Q3ODU3RUJhbFdvdVEvcmgxUmViTjVTd1JsYTVEYXpj?= =?utf-8?B?MGZrYm9XMmVUNHJtSEJhRUdsUDd5d3N3c1BDYkYvVzhkRWRFM0JLNkZRVnhs?= =?utf-8?B?N1BldXl3VmhPcFlGUW5BRFJ1cVk4V21WSHFtZmpiMkRjdVZueHpabUdwM0tR?= =?utf-8?B?NUdqVW1rWVlZSndMUFJDOWhwN3Z6YVhLako3bEoyWmZyQWRJUk1JemhGM2NZ?= =?utf-8?B?TmJjY083OXZ5SVpSMklnd0VScDFtMFhlemtITXRNMnRqS2xvOGJWNFExc3VI?= =?utf-8?B?WUJVRFJGamRSL2lSU0lValpTZkU4dFZoZzU4RHpEdUduQUE3cW1keXQzVGhW?= =?utf-8?B?Z3M5cUlZNEFUREYxaUl1a0N4YWwzb1NXNkltVnpVZWxDL2dpYVpmTW53R1Y2?= =?utf-8?B?aEJjQ2xtQm54THNXdTF1SVo4c0JtdXIyNE9RYWhqdGVxZktReVJCYjdmcW9l?= =?utf-8?B?akhUL2lSb2M3RGpPcTN2aDdIVjQ0MlZHNzUwUWloa3pJVnJVd0lCWEw4MGx6?= =?utf-8?B?WmtKdVFkQWN0UldZeThoL3RpQVBMcHlaTXdwSU9xY1p4QmdGWVRPZXBJVjly?= =?utf-8?B?TXhGSGVJV1FYTEJnbTFKeTdCWTJVZUdKU3htVkNmN3JhRlZ1SFJWT3BldVBq?= =?utf-8?B?dGExWGl6K0Y4NnBYYXkxajRDZDFCblFnL2l5WGY4ci9nT0tWcVArNTNuOFBB?= =?utf-8?B?U21BL3FqVnllb2N5SGc0WDBPeE9Da3pSSVBZbXpQTDdNekNwK20rUkp4a3Rt?= =?utf-8?B?K3k1VlhjOG50RlVneG40b2p2UXFHbzN1T2prNVZLMlJ0a3VKUFpScGNBbWpo?= =?utf-8?B?eWJJd2I3YVdwc2tTSzdTOHcvQUxwTVZGaTJxb1NOVXdseG80T05nbm10OEFt?= =?utf-8?B?TUZ5MVFsc3VmQXk3MXVOb05GcjVGd2ZSTVVKb1J6ZmVuYWU0WjhsMml4bWor?= =?utf-8?B?SmpxMFNJRjJFNlovcmdkcVFMNWljNG5tMCtSb1lYTFB2UUN4RUladTV2OWg1?= =?utf-8?B?dUh4SXVHWTRST3Z6K0xzSXBnU0RMNlZ1andlcUpnY0VDeGVudG5td1VUYjJ5?= =?utf-8?B?ajB2QWNrYUx0YTVKNUhQd0NzUHRHeUIvNHlGdmRoQmVqT1VIUHdaNmFEZHE2?= =?utf-8?B?S1doODIwUGREcHdBcjFoVjdsa2syTEVoQ25MNjBFMWJ6VytvdTBsV1hhSXR4?= =?utf-8?B?SS9RU3JGUHpHYUpiQ2tLSHdYa09sbnRwUFNvQjRZV2FkeURWakdFSnI0UVZw?= =?utf-8?Q?Bqkf1s8cV4EgmtMY=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d316d82-1367-4593-99e2-08df22ccc146 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2026 10:38:12.0387 (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: K/iT6DTopB5x7/J9lccV8IkqahtksuXZUDs58wLjkCKXjJaosCho70Z0YoyNL86teTUObfkuVhXBtimGy7p8Gs7OIVxQYoRIlg91mC3Gv78= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU6PR03MB10967 X-purgate-ID: tlsNG-16d1c6/1791196695-F580D77B-24FF2F9B/10/78276251493 X-purgate-type: spam X-purgate-size: 2258 DQoNCk9uIDgvMjgvMjYgMTI6NTUsIE5pY29sYSBWZXRyaW5pIHdyb3RlOg0KPiBPbiAyMDI2LTA4 LTI4IDA5OjAyLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+IE1hcmsgaXQgYXMgc3VjaCwgYW5kIHRo ZW4gcmVtb3ZlIHRoZSBjb2RlIGZvbGxvd2luZyBhdCBpdHMgc29sZSBjYWxsIA0KPj4gc2l0ZSwN Cj4+IGZvciBFY2xhaXIgZmxhZ2dpbmcgdGhhdCBhcyBhIE1pc3JhIHJ1bGUgMi4xICh1bnJlYWNo YWJsZSBjb2RlKSANCj4+IHZpb2xhdGlvbi4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+Pg0KPiANCj4gUmV2aWV3ZWQtYnk6IE5pY29sYSBW ZXRyaW5pIDxuaWNvbGEudmV0cmluaUBidWdzZW5nLmNvbT4NCj4gDQo+PiAtLS0gYS94ZW4vY29t bW9uL2tleGVjLmMNCj4+ICsrKyBiL3hlbi9jb21tb24va2V4ZWMuYw0KPj4gQEAgLTQwMSw3ICs0 MDEsNyBAQCB2b2lkIGtleGVjX2NyYXNoKGVudW0gY3Jhc2hfcmVhc29uIHJlYXNvDQo+PiDCoMKg wqDCoCBCVUcoKTsNCj4+IMKgfQ0KPj4NCj4+IC1zdGF0aWMgbG9uZyBjZl9jaGVjayBrZXhlY19y ZWJvb3Qodm9pZCAqX2ltYWdlKQ0KPj4gK3N0YXRpYyBsb25nIG5vcmV0dXJuIGNmX2NoZWNrIGtl eGVjX3JlYm9vdCh2b2lkICpfaW1hZ2UpDQo+PiDCoHsNCj4+IMKgwqDCoMKgIHN0cnVjdCBrZXhl Y19pbWFnZSAqaW1hZ2UgPSBfaW1hZ2U7DQo+Pg0KPj4gQEAgLTQwOSw5ICs0MDksNiBAQCBzdGF0 aWMgbG9uZyBjZl9jaGVjayBrZXhlY19yZWJvb3Qodm9pZCAqDQo+Pg0KPj4gwqDCoMKgwqAga2V4 ZWNfY29tbW9uX3NodXRkb3duKCk7DQo+PiDCoMKgwqDCoCBtYWNoaW5lX3JlYm9vdF9rZXhlYyhp bWFnZSk7DQo+PiAtDQo+PiAtwqDCoMKgIEJVRygpOw0KPj4gLcKgwqDCoCByZXR1cm4gMDsNCj4+ IMKgfQ0KPj4NCj4+IMKgc3RhdGljIHZvaWQgY2ZfY2hlY2sgZG9fY3Jhc2hkdW1wX3RyaWdnZXIo dW5zaWduZWQgY2hhciBrZXkpDQo+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4va2V4ZWMuaA0KPj4g KysrIGIveGVuL2luY2x1ZGUveGVuL2tleGVjLmgNCj4+IEBAIC00OCw3ICs0OCw3IEBAIGludCBt YWNoaW5lX2tleGVjX2FkZF9wYWdlKHN0cnVjdCBrZXhlY18NCj4+IMKgaW50IG1hY2hpbmVfa2V4 ZWNfbG9hZChzdHJ1Y3Qga2V4ZWNfaW1hZ2UgKmltYWdlKTsNCj4+IMKgdm9pZCBtYWNoaW5lX2tl eGVjX3VubG9hZChzdHJ1Y3Qga2V4ZWNfaW1hZ2UgKmltYWdlKTsNCj4+IMKgdm9pZCBtYWNoaW5l X2tleGVjX3Jlc2VydmVkKHhlbl9rZXhlY19yZXNlcnZlX3QgKnJlc2VydmF0aW9uKTsNCj4+IC12 b2lkIG1hY2hpbmVfcmVib290X2tleGVjKHN0cnVjdCBrZXhlY19pbWFnZSAqaW1hZ2UpOw0KPj4g K3ZvaWQgbm9yZXR1cm4gbWFjaGluZV9yZWJvb3Rfa2V4ZWMoc3RydWN0IGtleGVjX2ltYWdlICpp bWFnZSk7DQo+PiDCoHZvaWQgbWFjaGluZV9rZXhlYyhzdHJ1Y3Qga2V4ZWNfaW1hZ2UgKmltYWdl KTsNCj4+IMKgdm9pZCBrZXhlY19jcmFzaChlbnVtIGNyYXNoX3JlYXNvbiByZWFzb24pOw0KPj4g wqB2b2lkIGtleGVjX2NyYXNoX3NhdmVfY3B1KHZvaWQpOw0KPiANCg0KTEdUTS4NCg0KUmV2aWV3 ZWQtYnk6IERteXRybyBQcm9rb3BjaHVrIDxkbXl0cm9fcHJva29wY2h1azFAZXBhbS5jb20+ From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:47:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:47:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440735.1658175 (Exim 4.92) (envelope-from ) id 1xDgEZ-0004hb-6r; Mon, 05 Oct 2026 10:47:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440735.1658175; Mon, 05 Oct 2026 10: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 1xDgEZ-0004hU-42; Mon, 05 Oct 2026 10:47:51 +0000 Received: by outflank-mailman (input) for mailman id 1440735; Mon, 05 Oct 2026 10:47:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDgEY-0004hO-0X for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:47:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDgEX-00AjU3-DY for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:47:49 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3804f-2eae-0a2a0a5409dd-0a2a4501d35c-10 for ; Mon, 05 Oct 2026 12:47:49 +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 6ac38055-5984-0a2a45010019-4a7de18cb1e1-3 for ; Mon, 05 Oct 2026 12:47:49 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49fff72474fso11086225e9.3 for ; Mon, 05 Oct 2026 03:47:49 -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-48c62837a29sm2609218f8f.4.2026.10.05.03.47.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 03:47: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=1791197269; x=1791802069; 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=+rslWrr5eeSrUMe8piPow0KdmVtIv5sLIU0fuFyEfm8=; b=gK6/UvMN/q2ULeVN+zNGaoGS6qPaTnfyzCcdLWZqoRjMrPq8GJzMse5olObm8FqHWI Zjo22hPhgJMfpHcWGTbaHkbndmP3kZlDj/4mtmkVBow25bGP7DPtg+2vZd6E9WP+IlTY Y0ph03RWAdFa34phbnfdspd56HTjyKwZC0bfG5pgRriXsFs6P9bJPxPpyMWSmKMtsyh5 42LtK8eprmZaAEoAMQ2PORIVp9duO5mqx/bUJCkmj02AIPAaCleiYqKj5/rRZ4GRnlji yohSFXy/C5pd3J00DXTPCyCc4rWh+tHDk3sYnLQCrMI3yBLC5HjjjRPolO7Bk0U2I5PA MfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791197269; x=1791802069; 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=+rslWrr5eeSrUMe8piPow0KdmVtIv5sLIU0fuFyEfm8=; b=xSTk7J8WNyF2zETVHDrGH1xyZdQULuRgPA7CFy/zI+6oeuasQvFz61KrzrpMwOBln1 6oJTUm6uoS1U2RQCilc9wM7S/E6YaYzuh1xknR8fbmHoM8972hmX0mQU40Zj0eBvnjUa EKT3nEgjRbpqhBTqDkpTIvL81icjXw046i3lD54OyuOOjK3nwg6JnY98ZBC3l5R9/+8V uD0H6r6+20Ys79W+Yhk4I5dkai4jqZBQYz6K73zDzmP8PEymffaEo9P0Cf1kJ59flMJ3 ahV+4/gllpu8dukgtq6qSXgEuLOuKBLUU9oLA5+5vrXWBMmATQJvG+V9KvSEFGcyfQJr SMpA== X-Gm-Message-State: AFuF++mJ/NF5ZcJtAUxop5t4vnoEhu/6/wVQyXyr+UGuhvcBawC5zV7q ZAlk7d6cmEub0Ivr5rt0tp+llMR1t6kSrRysrclkd6iZMcbyK2KMtMgC X-Gm-Gg: AYBFou2LiW5eRPRbOHIRsW+0o40jaKIqUcU4I/oqnkqmkfzhzE63vp7DZcFb3eZrAbX KO3WKx4uG2wOS/HyVb/DlMjpyzjW8jVQGR9Ak+rTYhjPK69JLWH19Fk78qhCkgGPqcU9MBCvnP8 TNLYKtVVL/j7zKwVllSptGa3yUwgWRxfQH4egzAghOkxwRnK38MDE0AKbhL3wS8b/C6eFcXlE3Q q7+dZA+Eb1apCaDmHrX/AyyVdIKsDwDk4ge32aHN4I/HV6ULD8KAH2REQrSnpaQ8CkFY3FCIgEq lWtYYJ6N9rjxsSQmtiyqRYJTEQ3ADtqg8X9Bw19hgiauMvJbqhkg7dCP6zZ7FXZAnmwzN+AR1Ed /zdZ3UQkLW1xXRQWZU314OuRcOoEGpMUNdDZYfXAJQPLF0Xyj88wm2MLHU7e4klw/IovSuUrC0M j4GNFDFUJt2Jc3SMkEGFDwD5mOO3DKgDDMToFvatbtSheaR7RQIAw4itxqW/eYXQ6900NBPycO3 0t5razybG4qGcKAfMVmD86yLFHFYaJ18OVAfo0k3W+e6f35+A== X-Received: by 2002:a05:600c:4e8e:b0:49f:ce78:3561 with SMTP id 5b1f17b1804b1-4a02759b360mr189029705e9.18.1791197268546; Mon, 05 Oct 2026 03:47:48 -0700 (PDT) Message-ID: <1eedf751-5d4f-46ec-b3fd-1149b35d92ec@gmail.com> Date: Mon, 5 Oct 2026 12:47:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] xen/riscv: use pte_is_valid() in pte_is_mapping() To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> <1790845650.8631fc262581453bbf619ec5b2062170.1a0f6b805100003f66@vates.tech> <1790846121.8631fc262581453bbf619ec5b2062170.1a0f6bf34f40003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790846121.8631fc262581453bbf619ec5b2062170.1a0f6bf34f40003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1791197269-BFA6E757-39BCAA3B/10/73395122804 X-purgate-type: spam X-purgate-size: 1211 On 10/1/26 11:15 AM, Baptiste Le Duc wrote: > On 2026-10-01 11:07 +0200, Baptiste Le Duc wrote: >> Use pte_is_valid() instead of open-coding the PTE_VALID check. >> >> No functional change. >> >> Assisted-by: Claude:claude-opus-5 >> Signed-off-by: Baptiste Le Duc > > I forgot the changelog for this patch: > > Changes since v3: > - Rebase on the pte_is_reserved() -> pte_has_reserved_rwx() rename in > patch 3, only the context line changes. I’m sorry, but I’m not sure the changelog entry is expected to apply to this patch. I don’t see these changes in the patch itself. Am I missing something? It looks like this renaming may have been done in one of the previous patches, since there is no + or - next to the ASSERT line: @@ -188,7 +188,7 @@ static inline bool pte_is_mapping(pte_t p) { ASSERT(!pte_has_reserved_rwx(p)); Anyway ... > > Sorry for the noise, I didn't know if the reviewed-by > Oleksii gave applied here as I rebased the patch. > ... I think that you could keep R-by but anyway the changes look good to me so: Reviewed-by: Oleksii Kurochko Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 05 10:57:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 10:57:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440743.1658184 (Exim 4.92) (envelope-from ) id 1xDgNy-0006Rh-1S; Mon, 05 Oct 2026 10:57:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440743.1658184; Mon, 05 Oct 2026 10: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 1xDgNx-0006Ra-VC; Mon, 05 Oct 2026 10:57:33 +0000 Received: by outflank-mailman (input) for mailman id 1440743; Mon, 05 Oct 2026 10:57:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDgNw-0006RT-FW for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 10:57:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDgNv-0027G4-LO for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:57:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3829a-bab6-0a2a0a5309dd-0a2a4504cdb8-8 for ; Mon, 05 Oct 2026 12:57:31 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3829b-b57f-0a2a45040019-d155802de509-3 for ; Mon, 05 Oct 2026 12:57:31 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a1682bff3cso8242085e9.1 for ; Mon, 05 Oct 2026 03:57: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-4a027734b49sm334709605e9.10.2026.10.05.03.57.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 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=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=1791197851; x=1791802651; 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=HTY8bzu+cDTyCDUClH21Sly/rB51hRSymRuDrk9f9/k=; b=kqXfu4bGLtwhteJVEiF8eiBjldYcouhxROQpTTK2ETLTmJWop5eivuaX2eyPvbcBIK 6ZhG49xIy6xd9tfEvtz9CLa/Vciu9jUaKLHrceF6U9hV/W35U/z8Wi+rBFA5n9N4C1ks irFVhp7LIJLqiSvlPFkLlPE/cuWkPGnCC06EVsEBlHAavgA5tS5GF8T3di4aQ4ZIfWdT 5M+0y+dVrMMhkef6THRdTvzaWGSwEruuA8lQGubOdvAVKlUMFjyVHquTwTBkJVmvpJsK PW1CSEz3L8tTT3sr4LBfRstfPLof2UlxA/fTE9RWG5Pk20E0ojbtdPdJn4+O7HgTKaJI kCIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791197851; x=1791802651; 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=HTY8bzu+cDTyCDUClH21Sly/rB51hRSymRuDrk9f9/k=; b=R8p/A70yQezumtOz985VUfMK6qn0/p/AMk1TRrpnJ6pGwhEISn4zqryTWdtl2XkQfH qT4pz5+tY9gnvj/JrzU2k+w872YxOlW+PktCIlrjuxGJKEuRbkfwSs4X5kSJVligez0p N0UYnxUfwKGpr8zY9cKzkpL8iMUan4HYlss5iOITkjQpxzBKKt/vv2O62sIt08dRKQH+ QtdvL5LUzt19obtd9yFD3EzN/sO6OL3dPG81cwZv5Ki4+/aD21drLV4Hilywq9wYV9UF Le9wda6x+CgPF5aKn7AYBoMHsyjVliUYtw8LpZ58hFwRkWtBGMazmsvvPd+vEJwvDq5Y N4FQ== X-Forwarded-Encrypted: i=1; AKwUvBwCWPvMoRwZqlAGpT4om8M2acmzzwYBFtSDm0GQqHYcSVsoBCJk2Nv3XLcoS2nHRoGSorsk9c/pDNI=@lists.xenproject.org X-Gm-Message-State: AFuF++kkjVEwM+EhIZwUsxn5PkfIKCKWxitprhQ+u4LoMQEiLp8Uu29X chOB7C5Ibm4BeG5cemhCMSwtLEGPgeZKZTVvvwygtvGm0htVlukv3oz6 X-Gm-Gg: AYBFou26ITjTjOUCV75lWi+srPjGqWZyi4GcUm+GD7kM4QW4RU4H1ApJJ2mjgdccDhU AeEYI92weCvtMCfXZns1L/Mv+KUEZE1IhDrVrCLMxHC6SyPNdANlyvOyshIpbf/Iv/nLwXvrHGH dSavVRRPfur/314P01AKMtguPd7+lkT62Va5oq+o/KQwjTtvDepTJ5cDq5jVRiwJeLdVIn6CRLC W9KQihvo5TN7LhwKs2ZJouTrBxaxh5WshEtOEytoqjlKiFQ9RkOqExike+gImtqi6IrVrNEDoVZ /jotbKSd9UU7FmJZR0q4btfXtQBnE8bLySgmFgYTZNCvAkvtyadoQv/EQ/yN68Fxx1YomPCk35t aigs7a1ikvHCelKBtrLAyhrES8eYbSVzfk+z1oAcunNF8Qa6GZryFn7My7pqUlMx2S0jBVg4xJz 6EMuwS/fHN6s/vzR88c0b2wog3d8fw6SI6fSre/d30OtLfyqX79goZz52kkd1sHblkCJo7OzdEO SEMvx2L/CXxHB2CHHPcFDVL1SdNE5GdByFA8Josto+zmF71HUE= X-Received: by 2002:a05:600c:4453:b0:4a0:2423:946 with SMTP id 5b1f17b1804b1-4a1680f109emr119833595e9.15.1791197850898; Mon, 05 Oct 2026 03:57:30 -0700 (PDT) Message-ID: <81c01b14-e998-443a-a7ee-722acb86dce8@gmail.com> Date: Mon, 5 Oct 2026 12:57:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] xen/riscv: always preset A/D bits in G-stage PTEs To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> <1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b802ba0003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b802ba0003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791197851-C3AC0B50-7E096694/10/73395122804 X-purgate-type: spam X-purgate-size: 3711 On 10/1/26 11:07 AM, Baptiste Le Duc wrote: > A RISC-V implementation can manage the PTE A/D bits in one of two ways: > 1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). > 2) Generate a page fault when 'A' and/or 'D' is clear, so that software > can set them (ratified as Svade). > > p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device tree > advertises Svade. Platforms that use scheme (2) without advertising Svade, > such as the HiFive Premier P550, then hit guest-page faults that Xen does > not handle. > > Always preset A/D in G-stage PTEs so scheme (2) never faults. This is > harmless with (1): software just does what hardware would have done on > first access. > > Drop the now-unused svade entry from riscv_isa_ext[], and the TODO about > handling A/D faults, since nothing uses that information yet. > > Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration") > Assisted-by: Claude:claude-opus-5 Out of curiosity, what kind of assistance did Claude provide for this patch? > Signed-off-by: Baptiste Le Duc > --- > Changes since v3: > - always preset A/D bits in G-stage mappings instead of keying off the DT: > it may not reflect what the hardware actually does. > - change commit title/message. > - drop svade as it is now-unused. > --- > Changes since v2: > - change commit title. > - preset A/D bits in p2m_set_pte_flags() if (!svadu || svade), instead of > setting RISCV_ISA_EXT_svade in the riscv_isa bitmap for cases 1, 2 and 4. > - riscv_resolve_ad_scheme() now only warns when both Svade and Svadu are > present and SBI FWFT is missing; drop the dead 'svadu && svade' operand. > - repeat XENLOG_WARNING on each line of the warning. > - drop ASSERT(svade != svadu) from p2m_set_pte_flags(). > - only add the sbi_probe_extension() declaration to sbi.h. > - rework the comment in p2m_set_pte_flags(). > --- > 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 | 1 - > xen/arch/riscv/p2m.c | 38 ++++++++------------------------------ > 2 files changed, 8 insertions(+), 31 deletions(-) > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > index aaf544d13f..6d3c15a37f 100644 > --- a/xen/arch/riscv/cpufeature.c > +++ b/xen/arch/riscv/cpufeature.c > @@ -199,7 +199,6 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { > RISCV_ISA_EXT_ENTRY(smstateen, ANY), > RISCV_ISA_EXT_ENTRY(ssaia, ANY), > RISCV_ISA_EXT_ENTRY(sstc, NONE), > - RISCV_ISA_EXT_ENTRY(svade, NONE), I’m not sure we should drop this from riscv_isa_ext[]. I agree that we currently don’t have any users in the code that check whether Svade is supported, but such users may appear in the future. Since this line already existed before this patch, keeping it would also make the changes in this patch smaller. I also don’t see much harm in having the Svade extension listed in this array. If Svade is present in the riscv,isa string, it seems reasonable to set the corresponding bit in the bitmap for potential future use. Other changes looks good to me so I just cut them. [...] ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 05 11:18:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 11:18:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440751.1658193 (Exim 4.92) (envelope-from ) id 1xDgiH-0001wY-K3; Mon, 05 Oct 2026 11:18:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440751.1658193; Mon, 05 Oct 2026 11: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 1xDgiH-0001wR-Go; Mon, 05 Oct 2026 11:18:33 +0000 Received: by outflank-mailman (input) for mailman id 1440751; Mon, 05 Oct 2026 11:18:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDgiF-0001wK-TM for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:18:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDgiE-00CFYe-M6 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:18:30 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac38773-8faa-0a2a0a5109dd-0a2a4507c1d4-20 for ; Mon, 05 Oct 2026 13:18:30 +0200 Received: from [40.107.209.58] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac38784-b4ea-0a2a45070019-286bd13a2532-3 for ; Mon, 05 Oct 2026 13:18:29 +0200 Received: from BN0PR04CA0069.namprd04.prod.outlook.com (2603:10b6:408:ea::14) by SN7PR12MB7955.namprd12.prod.outlook.com (2603:10b6:806:34d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.16; Mon, 5 Oct 2026 11:18:23 +0000 Received: from BN3PEPF0000B072.namprd04.prod.outlook.com (2603:10b6:408:ea:cafe::29) by BN0PR04CA0069.outlook.office365.com (2603:10b6:408:ea::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Mon, 5 Oct 2026 11:18:23 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF0000B072.mail.protection.outlook.com (10.167.243.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Mon, 5 Oct 2026 11:18:23 +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, 5 Oct 2026 06:18:22 -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, 5 Oct 2026 06:18: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=IcJwrJavRaMXGsF7AN+HbqM6K6J04CPb4tk8TJtXx11WBehWEBuLWLht3kb8+os99e+1sHG7YHO6tlsFXJHj9SMQQs7Ny32pINBaZELPKZTKaUhVf5/pD/eVwDH6RZgz2BrFJ3xfd3bLi3Q3jiprhlxqezMRYTDv24vktcp2r2OBmdbLO+1eX54vHru5z7ZBzYpwDfS0yyK515HW/rzXq2/1Q7jBNnGLcN9n6gOXX7Xb2Yo/ONlPIMJl88KCKMzrH6dxpehA49H5yAHce0IuHPv+Y1gzHYg7EmUkvppvyf5v6avJTlh6vdSpS5sCYwP1BMg/U8AMrC1QG6MCiapQWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pO0A2nt1kh4fhy/HQuaKlMRaisCjegx2Wo6tPOv36cU=; b=bKEeuDNQt1ZoZINmi2uZS6ephep0Nyp46mD4nKaFT+SlqSvhE0A2ryR57/5h9k/LaZ1g18sqfI5y5zvX0ZvV+QEYezGJO4t+Xm1undchFyP2tftzQ7NHxOd3LI+TJH/OSkcJsfTfWdfBkH8EKtMY1NE19Do4sa8Kdyb3SBrN6O09XLcXy8NyKN3tu+xL5KaDfd44OHpSuodio+rMP4xixjVxXJkz/RonB37ZRaK+hAaxOzkjGHcoHnaSJHQLxjKsWazOoYjTrTlF+CNIXZyo2oMf6qVW1dfg2DPFEi+5NlltPIROf2borIdBdDjovQamZAlhXCfC7Mq69yMMo79eJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=apertussolutions.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=pO0A2nt1kh4fhy/HQuaKlMRaisCjegx2Wo6tPOv36cU=; b=Kpzbv3vHCa+NbFBKPAS2aKP7MB1fPPMFKdSZ12FA/BI22xQAMdMf+5fTtmOh+Zb44iQ4C1ULHH42pbqRx3IEXja2OXYjfHBrun5+UOEtGuanB82RgrgQorS58gQY0WF8uwhIJo+swYS+MdUsxOwj7w71kFcryIqx4T3dXbbXvdI= 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: <593c8714-44d5-43d7-88d9-f5438112e467@amd.com> Date: Mon, 5 Oct 2026 13:18:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] common: dom0less-bindings: introduce XSM labels To: "Daniel P. Smith" , Sergiy Kibrik , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Jan Beulich References: <20261002102521.565675-1-Sergiy_Kibrik@epam.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: BN3PEPF0000B072:EE_|SN7PR12MB7955:EE_ X-MS-Office365-Filtering-Correlation-Id: a28b79be-361c-462d-d923-08df22d25e85 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|82310400026|23010399003|36860700016|56012099006|11063799006|10067099003|6133799003|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: TF91zb3u053jQ95ghk7zsLlMMabqEWcUS8cmEjsBJV/iTFDbpQlQyxnMVNc8iGE+19HMW8ASK4dwT9TZUx+skt+ubEe/81TjgMGJtR8jqxUTnH1hcKq7mjjzvRFZePBjLw7Z3ywElZk/f+HUrWXHL/RgjI9ScKpZxQM3ZYX8wGqqoNfaeLZlI37ZrycTq9qSe/9nFhtg6ccI5q69iZrD+fX/phAPRNabRoGL1DcJ6TrLC+5ZjDMvpfNTxJ0QTE1sHoMuC2aUY5WCtfaav9MNb0B1tshw9X883B1kbKLipnrDu4GorXyd8VvEOD32+yh1WRoFkGvLJmWcenXTYmQnPzuuICGg87ydMANXXJibtJzukUSa7wT0bkHoMFGQeZcUx73yy70kn60lpPjTY95P0U6ubaYrHjy5+AX29e6hem/OHhhKxziLi2aSuiVbAnqSrg+9DXqDFSG9KavSLNkhUy+VAb71SEbqf10sVf2NC05RiXXUOLlYv1juuVXGrpbyTodXMKUNxGp6TF7OnGAXm6zOdOGLgERJBQXmiIDB5K2niJcWqRh+Am3bp5wHnyvM3bf4M1jzuSsKP3quP5eU8UxWulso+BvciV2kgzXKzA4TAFk+KMT4NnGl+rOgFkkQ+JBlnovh2pwGbJKHAIpa8KsIyBE7HqBw2ru7DYRMuuDFs7FZ4S09ScatAQRs8yd1/UbX+bguz8KIbQlRME+FhA== 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)(56012099006)(11063799006)(10067099003)(6133799003)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: YeZxgSRB2dyICOEjvMCNAkXN0beNzCYze6eZ7tLhVMQB7M7rBFWqhJQezoomZOgjg4vFELbL6jkabzufPz7kvTjsNdMa0hbBmgUm/aBcKWF5vEXi/62bqcW3NGqtjSUy4FbGfIMSeVpxA21dReisv+ANVY5U7DI26Kx6ZRE7JTXp/FfuqKVpA7xZi4GvZ+V5MTmsi4Yo+DzXehpdNU1RE8NZikKn1AVwsJNcqv3WsLgZnfP0is/d0wAnY2F+DMwOUzsAgtQ2rFF25KrcKev6Eld5A/dyia4ywfkrpqaEgd+N4uBCI3bz9iBmFU02gWGxSwDvvUgZe/aacURLs71D6tvXOUA1s3chiEq2JZ/B8yxhiI3WPsOpG8r/4hSbWFcAXvPAUCvXKpA3433cBRcIkTpqqxBCx5qqkT0wkswc8pkJqiynksKxIbvJgQtfkKP+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 11:18:23.3773 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a28b79be-361c-462d-d923-08df22d25e85 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: BN3PEPF0000B072.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7955 X-purgate-ID: tlsNG-ef75cf/1791199110-A78D1AE4-0B7FA80E/10/78276251493 X-purgate-type: spam X-purgate-size: 2747 On 03-Oct-26 23:34, Daniel P. Smith wrote: > On 10/2/26 6:25 AM, 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 >> CC: Michal Orzel >> CC: Jan Beulich >> --- >> changes in v3: >> - panic if `seclabel` property found but FLASK is disabled >> changes in v2: >> - add & use flask_context_to_sid() wrapper >> --- > > > >> diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/device-tree/dom0less-bindings.c >> index 41d72d0d58..01d5cc1bc9 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,15 @@ int __init parse_dom0less_node(struct dt_device_node *node, >> panic("'llc-colors' found, but LLC coloring is disabled\n"); >> #endif >> >> + if ( !dt_property_read_string(node, "seclabel", &xsm_seclabel) ) >> + { >> + if ( !IS_ENABLED(CONFIG_XSM_FLASK) ) >> + panic("'seclabel' found, but FLASK is disabled\n"); > > Ultimately it's up to you, but I'm not sure you really will want to > panic here. I personally would warn it was set but ignored because FLASK > is not enabled. I explicitly requested this in v2 to match the user/Xen contract we want on Arm (we want to panic on unsatisfied user requests to prevent silent degradation of functionality). ~Michal From xen-devel-bounces@lists.xenproject.org Mon Oct 05 11:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 11:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440760.1658202 (Exim 4.92) (envelope-from ) id 1xDh2S-0005Zv-BL; Mon, 05 Oct 2026 11:39:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440760.1658202; Mon, 05 Oct 2026 11: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 1xDh2S-0005Zo-7I; Mon, 05 Oct 2026 11:39:24 +0000 Received: by outflank-mailman (input) for mailman id 1440760; Mon, 05 Oct 2026 11:39:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDh2Q-0005Zi-QE for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:39:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDh2P-002YqE-Kx for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:39:21 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac38c52-8faa-0a2a0a5109dd-0a2a45098662-32 for ; Mon, 05 Oct 2026 13:39:21 +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 6ac38c69-be1a-0a2a45090019-4a7de14ce892-3 for ; Mon, 05 Oct 2026 13:39:21 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4834977ae75so874475f8f.3 for ; Mon, 05 Oct 2026 04:39: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 ffacd0b85a97d-48c622b4685sm2842188f8f.41.2026.10.05.04.39.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 04:39: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=1791200361; x=1791805161; 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=Vmv5cV9J45IzrEmzzApVCv0BACGbAAMXyB5sX0/0UOU=; b=OI33iDzjtIi+HyHHEh08iLP3TxuvguwwupbNj3bSPbgYerK5FCzSnqkH6HjR3pB9eY XbY6IwX7Du3aAEgSAJ7ABqlgzhKgJ6tqzILXkZBMzzjxUPXJhKNGsdvgrrfOvNwbDByw CxyDKrCxK7U7/fFRvRFWUeTtIaZpzX1LsGZ9nL+FZBa+STk8WTlnKFEVNm8UgcVzbEWf ivULD4W4dCT2nOz9Wj6TKxL/4tuJ/60NA/SxjjDOgr8oHrdoHgrQRz5dXOP/J/RX9wjB iZ+aw0R468NRFAdqQYacUYrm6UWzUZGYw0weNC/bBiCusTtInEo143Rap+BB4JGcVZ9k /bUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791200361; x=1791805161; 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=Vmv5cV9J45IzrEmzzApVCv0BACGbAAMXyB5sX0/0UOU=; b=dLceVScsn8ZrRZLNMUGMCp5A+TSKytxpqcgGHuXACxWBTv3vhJB3HFSrDK2E7Uh4wW RH3fsvYZxb/vSFSuuz/cf6Ad+UGTPvy017gCdK3YLQsBXBG1FCyUSevYt6b63hgzney9 aZOcEIetK85+AdLla27a1ZRFgwRWdC2inCtXLEJDSJ7ev3X95vlFn59XnlGHLizuYMw5 j17nXU+TeOdjEBlOv9A+k4PvkaAIXL9ycWbRof5k92W2jiBd5XIqj+c1wuKbdv5ArXz0 QJVC58mnSHKHAHNhNrXjWDxWcdy1Qzs4Yfhfx3jtuA7L67aWEyXJcInhqET79KSwzCoU PK8w== X-Forwarded-Encrypted: i=1; AKwUvBxd8s3VWMJHZ7ZnNVSykrFaRaxUxkX65Q4ykP3WIXe0FukUioaPIhA059kVAEciPBn2UJims4Nxy+8=@lists.xenproject.org X-Gm-Message-State: AFq9FYLsyzzS+JQU8Ptdv0SxPjeNx28TatU6VMd5sH3Z683XlKywo5it bDJuCcQJeVZnscS076oLtFW7VQl3jm+imlBwl2AVWdYWI97o5Vc0kmEp X-Gm-Gg: AYBFou0wNvp+ikUmDHu5+chG5Z0gnpInj/GASJitC1oN1y1eLCk9RbM+vpj61dCiTIY gw8MubebKmXYQWc0MJjttxjrySjsKogqiDHHV0gsiHBc3tcmXc5fRTl+fQCly3uzghKn6oBRy4+ weHGMbg2Pl4aHWhpnSQNsazPDrHgB4r1WZ/NcYk63yMIQcA14rDGBRYuevIvkayqg2aejIsDcjs R6Bg5ct7oFGXxE/TO9yW3FOKam5Ms8kVV8d7wzNonYr5rcB+75Qz8o+uwusDG9iclGQG0EH+4R+ HZ46gLG3TE1wihY7idsPGM+LnpjNNKMix50XJACjzP5RMJnB9qNVpfqg/9VJpAbL7XqrkV5gfqP xQ4BJk6dgiOHmLf+sgNSqaKto8RLtRSbviB98K3P/Gvi62fhaM+NL2+BQXisWBvYxDpMfnc02R3 pjd6FnM69KlLGplwmol4G6utclgxds6/rVGEze5Mz25V1EPrao7Pr/4jzaNA2hL41dGql+FciRG C5GDri8m/vuBOi6wBsdXcc2k1rhvvlhO2uqpNomY2jcbhZEMQ== X-Received: by 2002:a05:6000:2c0b:b0:487:27f6:a4e5 with SMTP id ffacd0b85a97d-48b1275d69fmr19087354f8f.53.1791200361007; Mon, 05 Oct 2026 04:39:21 -0700 (PDT) Message-ID: <6f23075f-7a75-41e5-b34f-2cbbb3bc66a3@gmail.com> Date: Mon, 5 Oct 2026 13:39:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/4] xen/riscv: fix boot on missing extensions and MMU setup bugs To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791200361-39EC6034-B6A7ED15/10/73395122804 X-purgate-type: spam X-purgate-size: 1243 On 10/1/26 11:04 AM, Baptiste Le Duc wrote: [...] > --- > Baptiste Le Duc (4): > xen/riscv: rename PTE "permissions" to "pte_flags" I think because of this patch is already in upstream/staging (and it is small difference in how if()-check is formatted) this patch series can't be applied as it is. But it is easy to resolve by just doing git am --skip. And as a result ... > xen/riscv: always preset A/D bits in G-stage PTEs > xen/riscv: fix A/D bits in Xen's page-table mappings ... doesn't apply on top of the current staging. Hunk #2 for xen/arch/riscv/mm.c expects: if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; while the tree has: if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; It is to resolve but it seems like this patch series needs to be re-rebased on top of current staging. > xen/riscv: use pte_is_valid() in pte_is_mapping() After fixing the things in the prev patch I was able to apply the full patch series. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 05 11:39:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 11:39:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440762.1658211 (Exim 4.92) (envelope-from ) id 1xDh2u-0005t9-Hf; Mon, 05 Oct 2026 11:39:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440762.1658211; Mon, 05 Oct 2026 11:39: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 1xDh2u-0005t1-EC; Mon, 05 Oct 2026 11:39:52 +0000 Received: by outflank-mailman (input) for mailman id 1440762; Mon, 05 Oct 2026 11:39:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDh2t-0005sc-5l for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:39:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDh2s-001NTx-GV for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:39:50 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac38c6f-e002-0a2a0a5209dd-0a2a4509e270-38 for ; Mon, 05 Oct 2026 13:39:50 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac38c86-be1a-0a2a45090019-d155dd2ef05b-3 for ; Mon, 05 Oct 2026 13:39:50 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48afe75f055so1384707f8f.2 for ; Mon, 05 Oct 2026 04:39:50 -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-48c622704a5sm6904741f8f.15.2026.10.05.04.39.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 04:39: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=1791200390; x=1791805190; 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=8NLUMBlP6wab4z/GNt5qFu6BIEKo0a9Kb+izkdV6F9o=; b=Zwi4Dm9i+abg+LHgZDyxTjiXuP/+fJXncbhSiTNp4ha9KWGj7rX1C2Zd67PJfDN5rf O+z8GOmL0IhP9fLbxmr4CkE70OfJPWOtHTlwy3xXKFPQiqeraxMuXMUjHFhD1iN2+rpU WiJEtsNcPDsM++Nj9I3ECo+CkuzAXQSKjDI7CjCiT0x/5A2t6Wqx71tqYtgCRmTiCPzc keMg2Z6dY5CBkimlb0NybeIfUQHy7cnhgdGayj+mL5IlUaMyNSTGyPvTA6hSMwmtYhyT NxJsnyZBox4aCTK+XgAUPLq04g6fEWju0Fgoq+9YIuxk0cdW1NBwb9uFaczuHJyaR8ug Ilmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791200390; x=1791805190; 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=8NLUMBlP6wab4z/GNt5qFu6BIEKo0a9Kb+izkdV6F9o=; b=z+lzZMJDSS2/VbbfSrBcwN9IFNi1UUtkolIbLkVUsEQJfKveFyZCKFoOznN0DArgrB kTMAZGHaeCCtB7qZtfSHpO+zvfdXTq/wq7AO1LY93tNRLxX9SoPprub2kW3Ko0xDyN0J IancWonFgmMWQ6hEzGEtFj0C+s/NWJWiwVglnvNg9GLArc6DG2fD+9Wo+JN/qWaaE8Ya ls8wcFkT57ySLeRkWgG1IUnRupIWljJeSNT9F54SSMkjPkIBZWhIIjDlb43CmAoRJTuE 1gccXtxcNnO7SLdHAYiHeYjB0TlP6tcgag0mLIm9bqWruH316TsJhnR/5TH3CtOuw7HP YjBg== X-Forwarded-Encrypted: i=1; AKwUvByWDIHEgkk7HBUBQTtRLQUImTkTokz90ScT2myySj0DbiHNLy4DViMHxSMoQMRFD0lL6rEL+nW1N8M=@lists.xenproject.org X-Gm-Message-State: AFq9FYIuTTZPaeMNy4eDWtoB+EcdRNFKPvSl/dIp8R+cS6e3kwyl4aVP XUz611u5RyawKV3l1UFSwYzS8RzefIdfd3XBWYyK/EtTPQ9YcUgQXRjD X-Gm-Gg: AYBFou3KAquWScciyz9HXordZPEUf8WJ2HbcUiLNCLgWEmyar6Jhl8IFw31Vn4c3KMi SLdAKHueHB89dd0EYujKU9FtRUKEDKm79MZaJEeuQD0/ZHKWEmMYy61qfLc1MdIlcn01QvpeJTn qGy6JCTHWuItK8kSuLnLSj2kurqgiwRgCzvtMqdSAbYUlXx6ULM+cXDxW1vFCNju1krAXNSw+HW SEHaSSte16uMypRhjfJUSzVLxxvVcsupTE3st5EpeJw3PZcFt3mbS5X7rOkwwdxZsCrDSBYKeUn 6rvQf7fuN+Mtt+8WziP16YyCvOpwyAJcR+J2diETxbXb+q7qVsg/CWo4zDiWV04BQfSi0W66GJw xDYccKwTwf42Ww++MrckqCTQgh7IGrPJkoTFxkVw6V3kg21+TKt4Sz58hyVuwyCp1lksnyFmmsj MVMUmHzwLt5gyc5WzvgyEk1wUG6yD/rZDBCvNjDvCvU//W9QzTeDNFgarDRDfKsjuzXZoer523y 0YiCCG64VZFXfQhNisRXzbXnE943AJjdCxzpHV6WwfR8aTdd8LyZFKoqDo3 X-Received: by 2002:a05:6000:25fe:b0:48b:f08:8159 with SMTP id ffacd0b85a97d-48c47ff6187mr10348227f8f.40.1791200389742; Mon, 05 Oct 2026 04:39:49 -0700 (PDT) Message-ID: Date: Mon, 5 Oct 2026 13:39:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis References: <1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech> <1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b803f90003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790845649.8631fc262581453bbf619ec5b2062170.1a0f6b803f90003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791200390-3A0C5034-E29C96EF/10/73395122804 X-purgate-type: spam X-purgate-size: 2721 On 10/1/26 11:07 AM, Baptiste Le Duc wrote: > Xen does not handle page faults caused by clear A/D bits, so it presets > them when creating PTEs. pt_update_entry() does so, but three places build > leaf PTEs directly without going through it: setup_initial_mapping() (the > boot page tables), check_pgtbl_mode_support() (the temporary root entry > used to probe SATP mode support) and arch_pmap_map() (the fixmap). > > Without Svadu, all three fault on first access. For > check_pgtbl_mode_support(), the fault is raised by the instruction fetch > right after the SATP write, before any trap handler is set. > > Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build > PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in > all cases for consistency with pt_update_entry() which sets it at runtime. > > 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 check_pgtbl_mode_support() to > use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. > > pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one > of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by > masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also > carries A and D, a reserved PTE with A or D set would no longer be caught. > Mask with the V, R and W bits explicitly instead, and factor the check out > into pte_has_reserved_rwx(). > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v3: > - rebase patch 2/6 which modified wrong indentation. > - change commit message to address review comments. Nit: a rename to pte_has_reserved_rwx should be mentioned here. Changes itself looks good to me so: Reviewed-by: Oleksii Kurochko Note: As I mentioned in the reply to the cover letter, this patch is not applicable (at least I failed to do that by using git am ...) on top of the current staging tree. The conflict is easy to resolve, but it looks like a proper rebase and resending of the patch series will be needed. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 05 11:54:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 11:54:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440771.1658220 (Exim 4.92) (envelope-from ) id 1xDhGs-0000hQ-Mc; Mon, 05 Oct 2026 11:54:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440771.1658220; Mon, 05 Oct 2026 11:54: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 1xDhGs-0000hJ-JX; Mon, 05 Oct 2026 11:54:18 +0000 Received: by outflank-mailman (input) for mailman id 1440771; Mon, 05 Oct 2026 11:54:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDhGr-0000hC-Rx for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 11:54:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDhGr-001QSf-8W for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:54:17 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac38fe6-8faa-0a2a0a5109dd-0a2a450bb85c-28 for ; Mon, 05 Oct 2026 13:54:17 +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 6ac38fe8-b7e8-0a2a450b0019-4a7de18cc1e7-3 for ; Mon, 05 Oct 2026 13:54:17 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ffde3cec6so10923675e9.3 for ; Mon, 05 Oct 2026 04:54: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-4a16bcb9a21sm309258525e9.10.2026.10.05.04.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 04:54: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=1791201256; x=1791806056; 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=n8gcPZMNK/kYqEshazKTqD1jOk9Nm5uLCDmpta+uW1A=; b=Z+EDPqjNxK7LK4NdZXU7j84DDHvKOhOIbIrVHCfcr+qJs760jz+k0lykZskyqp0dgE K4+Z0IYcB0ky8/JwJqByfmT31nvPTNRMbdNqTe5WwcM2txae2caU7RXqW1P+983D+ish 8Yf8vpo/84C/Cae/todHtbF3MGCb/xitei33iFI949vxcKL/vSsiPKyh3duFasdEZaxG Fhc8tHIqcYFx26hq22PHe3DAXPB33aANOANJfgfIFayzwvoThQy5m5+JPWCcGfhSBSkZ aTw0DmnzwYA90e+PblR5IXymQQqAHmjiumUmKIZDOrq3stYb2+2oCR5bEoIYUkVOW+v1 MxXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791201256; x=1791806056; 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=n8gcPZMNK/kYqEshazKTqD1jOk9Nm5uLCDmpta+uW1A=; b=a8QnV8VIf72sIqofKeATtAETrcuhgTpzFkzidG1Y8005dhOrH/jNZ2DN9h+cHsesEI 6u7BUAsU5LCSpVOaTqqItHNMqLoRkJvg1YjO5cRZ0fnECLvi3cuRogzGz17cDK0JHPy1 RN+CvAHFxI/uVNZPkK6YWhdaclDWizQhWr4/a63YpOYF3QzLYwdEDQ+q2om9ozD5z6tz ni29LpL+NU3rZAhDOF6J/Ljh1YWKagYaK3DPwYHC0SUe4oeHcYxE8wsyLgvkRbzjXiV0 YmeZWg38UGAiGaRHxDv1K9BzF7DKkp5Ri0sbZs4NYYwsrgE25kZnFDtQbaq+zzwQfAMU 7BMQ== X-Forwarded-Encrypted: i=1; AKwUvBxbB0zpZb8rOYYfhzEM5GzX/mREwItbgu1VBxA4uavsCf37zHf7t+t2dD7fMw/KvFq8uc6Dp0Vbk2c=@lists.xenproject.org X-Gm-Message-State: AFuF++l/UQQesMH+e7Y89Vg5rm9SVOLTDALqBKO8ZP2hw/oknA6EN5RX 3u5IFcU7URr+EiBkie/y/Z9pSa4q4/LH1oDUx2+De+ji8ac1cNU5Ms1SKVU8QbHaJQ== X-Gm-Gg: AYBFou2TDhWjK8LOdv9jL69RltbH4J6cxPMmMskoFdo6Sx7cUO4/L1Vfa8yiYnQ42IF x62kHBPeEdxBFMwXFeeV43WKJazguIOBAU7/WkaU9TjOQbsGbVTsttC2DCfRuRgSLHxxy7UFFch OdK9yp0MFhhrY3oOsy09+gPu/VT+3erKZXGMngz0af0/P9BhrR98uCnzOijQ9Z8LRBLn6G1EapJ dsNAbGu1nKjaItxUXtyh4QnMdfhlA2zb/Wnxuq5odaRLyeNSeRNIeU4qEDOmyuDEJn0emmc36rX MwpiOnjxKrFIecaFVCY/CQ7oP8uaLWahGkjEksPlZveSSusxb3xWe/4WDxWADg6PxQ3gAs2pYbj NI28zN7mtTODs/hyv3nw3/40Ex+fRV6IwupWo80sqjOA8ChAASqlrbjQHsA0IacGuK00oHKzKdu vdyakkfGhUkdJ11SLR8uhh+9HhNxypHDexofEDtm07rCy8w0wfLg8jYujF6EEUHO8SCAopjNW8o HWy6kP2OeRTG4xha66XRX3yY2CRrC79ANS5wm2WKNOxYWA2WlEHwya/E3h3ZA== X-Received: by 2002:a05:600c:3493:b0:49e:817a:ca7 with SMTP id 5b1f17b1804b1-4a02754310cmr182417995e9.8.1791201256535; Mon, 05 Oct 2026 04:54:16 -0700 (PDT) Message-ID: <44c2b3db-4958-4ade-9503-737f0f986cf9@suse.com> Date: Mon, 5 Oct 2026 13:54:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/pdx: fix offset-compression merge of a contained range To: Weiqi Wang Cc: roger@xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang , xen-devel@lists.xenproject.org References: <20261005102713.94033-1-coolhaoyt@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: <20261005102713.94033-1-coolhaoyt@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791201257-A8CCF9EA-4498D493/10/78276251493 X-purgate-type: spam X-purgate-size: 2361 On 05.10.2026 12:27, Weiqi Wang wrote: > From: Weiqi Wang > > When sorting and merging overlapping ranges in > pfn_pdx_compression_setup(), the merged range is set to end where the > second range ends. If the second range is fully contained in the first, > this truncates the first range, and the tail of it is then neither > compressible nor translated correctly. > > Keep the end of the merged range as the maximum of both ends. > > On x86 the ranges come from the SRAT memory affinity entries, and > overlapping entries for the same node are tolerated with a warning by the > NUMA code. The caller's subsequent coverage check catches the truncated > range, so the effect is that PDX compression is disabled with a "RAM > region ... not covered" message rather than memory being mistranslated. > > Add a test case that fails without this change. > > Found with the ESBMC bounded model checker. The counterexample was > confirmed by running it natively against the unmodified code. > > Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") > Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation > Signed-off-by: Weiqi Wang Reviewed-by: Jan Beulich I think though that ... > --- a/tools/tests/pdx/test-pdx.c > +++ b/tools/tests/pdx/test-pdx.c > @@ -87,6 +87,18 @@ int main(int argc, char **argv) > }, > .compress = true, > }, > + /* Range contained in a previous one. */ > + { > + .ranges = { > + { .start = 0, > + .end = ((1UL << MAX_ORDER) * 1) }, > + { .start = (1UL << (MAX_ORDER * 2)) | 0, ... these lines now want padding with two more inner spaces, so that in particular the multiplication aligns with ... > + .end = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 4) }, > + { .start = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 1), > + .end = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 2) }, ... these. Happy to adjust while committing. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 05 12:49:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 12:49:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440796.1658268 (Exim 4.92) (envelope-from ) id 1xDi7k-0000X7-T7; Mon, 05 Oct 2026 12:48:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440796.1658268; Mon, 05 Oct 2026 12:48: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 1xDi7k-0000X0-Q0; Mon, 05 Oct 2026 12:48:56 +0000 Received: by outflank-mailman (input) for mailman id 1440796; Mon, 05 Oct 2026 12:48:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDi7j-0000Wt-Pp for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:48:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDi7i-0067O3-EW for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:48:54 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac39c92-8faa-0a2a0a5109dd-0a2a450bcc58-48 for ; Mon, 05 Oct 2026 14:48:54 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac39cb6-b7e8-0a2a450b0019-b9ff1c23b103-3 for ; Mon, 05 Oct 2026 14:48: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 1a10c1c21670003f66.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 12:48:52 +0000 Received: from [192.168.0.158] (cpc92322-cmbg19-2-0-cust1759.5-4.cable.virginm.net [86.26.38.224]) (Authenticated sender: andriy.sultanov) by mail2.vates.fr (Postfix) with ESMTPSA id BDC6382361; Mon, 5 Oct 2026 14:48: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=71dbmMeUgqc5uPvC5ClI7fThCtsLuV9OZ4alcvFzdzY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ltiX4L0au1KJSnaOICMCECBYYkgVgPOMbGQzodEBvR9hkudchGIzBvxKvI3nMxRICIIO5SJPk QjtfxL5VO+MbrDX3xV8A38xRzRqcysQixJnp68RKN84ZoQRZxM6uqZihIkF9IGxn5h8Q4esRgWH hqlbqIxuLRPWl1FPkmesQuux/IZ5t2kWZQ/SE+t22mufMxfyyc08/1/ez7dZVOYg14fjdXzkpJl RpBymsrbCeaqNmlovqXlvS+7GjkjkyArAKrmrYUDExSYn2a24sWzgR7O3DiRbu1myo64jB23zSC lpRasjc4e+GPVxDPb2Vh727GRYwl1LiG/6CSMJ05LlpA== X-Zone-Loop: 49974e3cd8709e334bdab1f2887ad30f5e4e97864b28 x-campaign-type: default x-transaction-id: 354cbd42-ea76-4b73-8d2e-b5b62eb716af x-swg-uid: 01-0e8e8b8e-ada2-49c6-8bd7-6d305264d3ec X-Mailer: Sweego Message-ID: <1791204532.8631fc262581453bbf619ec5b2062170.1a10c1c21670003f66@vates.tech> x-swg-bid: 1791204532.8631fc262581453bbf619ec5b2062170.1a10c1c21670003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 5 Oct 2026 13:48:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tools/oxenstored: preserve socket fds across exec live-update, document SIGTERM limit To: Andrew Mbugua , xen-devel@lists.xenproject.org Cc: andrew.cooper3@citrix.com, guillaume.thouvenin@vates.tech, anthony.perard@vates.tech References: <20261005124654.4070674-1-andrewprecious388@gmail.com> Content-Language: en-US From: Andrii Sultanov In-Reply-To: <20261005124654.4070674-1-andrewprecious388@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: 1791204531996 X-purgate-ID: tlsNG-42698a/1791204534-2C59A9EA-A5F544DA/10/77776452383 X-purgate-type: spam X-purgate-size: 3776 Please stop re-sending this email - I've just received four copies of it. On 10/5/26 13:47, Andrew Mbugua wrote: > The TODO comment at connection.ml: has_extra_connection_data dates back to > commit 42f0581a91 ("tools/oxenstored: Implement live update for socket > connections"), which started dumping anonymous (dom0 toolstack) socket > connections as "socket,fd" plus watches, but left the SIGTERM / > file-based restart case unsolved: > > (* TODO: what about SIGTERM, should use systemd to store FDS > || has_socket (* dom0 sockets not * dumped yet *) *) > > An fd number is only meaningful for an exec-based live-update where the > fd is inherited. It cannot survive a SIGTERM/file-based restart > where fd numbers from the old process are meaningless. That would > require stashing the fds in systemd. > > Additionally, Connection.dump never cleared CLOEXEC on the socket fd > (unlike DB.to_channel which does so for the listening socket), so even > an exec live-update including a forced one with `live-update -F` > which bypasses prevents_quit, loses the connection and restore hits > "Ignoring invalid socket FD". > > Resolve the TODO without regressing commit 42f0581a91: > - keep allowing idle sockets for exec live-update; pending partial > I/O still blocks via has_in/has_out and SIGTERM clients > simply reconnect. > - clear CLOEXEC in Connection.dump so the dumped fd actually survives > exec. > - replace the TODO with a comment explaining the remaining systemd fd > store future work for SIGTERM. > > Ive verified that make builds oxenstored cleanly > > Signed-off-by: Andrew Mbugua > --- > tools/ocaml/xenstored/connection.ml | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/tools/ocaml/xenstored/connection.ml b/tools/ocaml/xenstored/connection.ml > index 37eb2444b9..e535e7cea6 100644 > --- a/tools/ocaml/xenstored/connection.ml > +++ b/tools/ocaml/xenstored/connection.ml > @@ -435,9 +435,15 @@ let has_extra_connection_data con = > let has_in = has_partial_input con in > let has_out = has_output con in > let has_nondefault_perms = make_perm con.dom <> con.perm in > + (* Socket (dom0 toolstack) connections are dumped as "socket,fd" plus > + watches by Connection.dump below. The fd number only survives an > + exec-based live-update when the fd is preserved across exec (see > + dump); it cannot survive a SIGTERM / file-based restart, where fd > + numbers are meaningless. That case would require stashing the fds > + in systemd (fd store / socket activation). Pending input/output > + already blocks above, so idle sockets are safe for exec live-update > + and SIGTERM clients simply reconnect. *) > has_in || has_out > - (* TODO: what about SIGTERM, should use systemd to store FDS > - || has_socket (* dom0 sockets not * dumped yet *) *) > || has_nondefault_perms (* set_target not dumped yet *) > > let has_transaction_data con = > @@ -464,9 +470,13 @@ let dump con chan = > Domain.dump dom chan; > domid > | None -> > - let fd = con |> get_fd |> Utils.FD.to_int in > - Printf.fprintf chan "socket,%d\n" fd; > - -fd > + let fd = con |> get_fd in > + (* Keep the fd across exec so an (exec-based, possibly forced) > + live-update can restore it via "socket,%d". File-based > + SIGTERM/restart cannot restore fds; that needs systemd fd store. *) > + Unix.clear_close_on_exec fd; > + Printf.fprintf chan "socket,%d\n" (Utils.FD.to_int fd); > + -(Utils.FD.to_int fd) > in > (* dump watches *) > List.iter (fun (path, token) -> From xen-devel-bounces@lists.xenproject.org Mon Oct 05 12:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 12:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440801.1658277 (Exim 4.92) (envelope-from ) id 1xDiDp-00023U-FD; Mon, 05 Oct 2026 12:55:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440801.1658277; Mon, 05 Oct 2026 12:55: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 1xDiDp-00023N-Cd; Mon, 05 Oct 2026 12:55:13 +0000 Received: by outflank-mailman (input) for mailman id 1440801; Mon, 05 Oct 2026 12:55:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiDn-00023E-RW for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:55:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDiDl-007NZE-S0 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:55:09 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac39e19-8faa-0a2a0a5109dd-0a2a450ac042-40 for ; Mon, 05 Oct 2026 14:55:08 +0200 Received: from [74.125.227.169] (helo=mail-pj2-f41.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac399b6-f2d2-0a2a450a0019-4a7de3a98f00-3 for ; Mon, 05 Oct 2026 14:36:07 +0200 Received: by mail-pj2-f41.google.com with SMTP id d9443c01a7336-2e4ba8555fdso5333875ad.2 for ; Mon, 05 Oct 2026 05:36:07 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:5364:bba9:2adf:d611]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2e5a5caea48sm6542495ad.14.2026.10.05.05.36.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2026 05:36: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=isslab-korea-ac-kr.20251104.gappssmtp.com header.i="@isslab-korea-ac-kr.20251104.gappssmtp.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=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1791203765; x=1791808565; 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=4jU8vbkoMdpm/iDka5HS8l6OLmahdMWqgTkrbnwvknU=; b=bEUPx5wMGg0RBJMJTEEUQsbTOTMHz6eyoti8mRXatBFu8OqHK59r5hORbSHdN6cNGq 9AI+mah4WMHxinLr0F8VtekM+gPQG98wGo+RPRAbwvaTv0r8GD3trrH/CnXHuOwqL0pl +v238Yk/+6hUqTiFLr4jotmiFh28KyCej2KXzuQDCn2cD3/PmTdi0WJNkU62jzucm6Ij DFNya7xz7k6TZAI5AMulN3H0Gli9YjbrL/M/9tX0ayRGmTVrHT3wXfQ6iBAlbEdexNMU 8bbPX6gK6RjBgHZRq26gY4cVj+M8S61IsY05+AiwGJfSOk9/OyPsuFbnQYq0gflEdbm+ jBVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791203765; x=1791808565; 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=4jU8vbkoMdpm/iDka5HS8l6OLmahdMWqgTkrbnwvknU=; b=p6Lnoyh8SV1UNhWfuKRZEbQ0AL9VM560TQdXa4hjgO3+ummRd3JTABkOBzVdvyB/PF afxA9uU8jMMsGkxF9cexu06p3kTJj1xTIBwgnVx4Dcr5r1mtHGkj2lSKtF1G25HC1iq7 EKJ+BjHPtzCrPVJ9uxFezwsUx5QzUpoMxR4/Wgr9I3iMtIdgT1S1W8yAROaZBQvoUiwe D/zPyU/JzFGE4B6YFkpHt9+MGnIgMbQm/GTrHr0svvTt4J/irUEQnnWoS9uca/sBCNL9 ymCNoJQ0GO6fhp6ghYHtssUd2WRgmMnOHau3javz/j3FZ7IM35yOXSvlljWW8LxW3MGx AH4g== X-Forwarded-Encrypted: i=1; AKwUvByo24+rJUoDglTS8n/yNFx2kDl4dxj6bsclqO/iEGH3Rk8di+YCR13sAH0ftyX8UDbuyaGUmBmnbug=@lists.xenproject.org X-Gm-Message-State: AFq9FYJcH9zVKhkwXCNBbFW2YKO3vnsQtGzwjRVzSbQZMR01dIYSc8DQ yqXyFiTg4gxVe/1C6Z4sIkLzeo7Hd8OPRUnJWaE80xQvi2gZVl2cka0uDa+D7IsRVSs= X-Gm-Gg: AYBFou1m5S3akD/FnhfjJXYZRl2fS/k3wYmfWEWS+xp49aj6hCI94PAobWsjaST8EHv XqY87tIBluA/Km/a16ThQx4KHs1Wf3VHeuPOaRPM2SqJj0/vCXSkYl9DGOoDOPqWHRCq44yuNpO w01ZS6/e8/BMujjfx+x6pKCqSwbQoEIJsEb1LOGhlmZI1/ZE8RJOtrA5ljuJjS+bUFskUXBxDtY VXxOh7Oo8lOodcG9HE/WsbnL/n2IKGctB3vYsjj/S2ValrD1gRSmcK6+NiguQSQwKmT7yfdJYjZ JiSGQqCBDdGsv/z0CEV+by7ULY0NS6KsfShEUMEGCoLH+k91rnlSKgFNHSWZrNFKxm/tvUJHCcC gotrD5Tl8AxAvKxTtjWq6VsbmQOij3DJRz7SNfFsXEsqY4ICELzw8UPxaUJYROAYZSqDTlUrEu5 x7/HZJxUNMGHIOgJpxdxiThYQf9fYI2xdWVh01CQ7plPhxthv8E9DmgqR3ETNVq9xoRZrUejIt1 YeTq9muluxgn5N/PcI5MA== X-Received: by 2002:a17:903:186:b0:2dd:c053:c209 with SMTP id d9443c01a7336-2e49b6df076mr106567665ad.37.1791203765331; Mon, 05 Oct 2026 05:36:05 -0700 (PDT) From: Yehyeong Lee To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "James E.J. Bottomley" , "Martin K. Petersen" , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Subject: [PATCH] xen/scsifront: check for a NULL shadow entry on a backend response Date: Mon, 5 Oct 2026 21:35:54 +0900 Message-ID: <20261005123555.253995-1-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1791203767-53CD3CFC-FEF97E3F/10/78177266408 X-purgate-type: clean X-purgate-size: 1724 scsifront_do_response() validates the rqid in a backend response against VSCSIIF_MAX_REQS before using it to index info->shadow[], but then dereferences the entry to test ->inflight without checking that the slot is populated. Shadow slots are NULL before a command is submitted (the host private area is zeroed at allocation) and are reset to NULL in _scsifront_put_rqid() once a request completes, so an in-range rqid that does not correspond to an outstanding request makes the frontend dereference a NULL pointer. A malicious or buggy backend can thus crash the guest by returning a response whose rqid is in range but not in flight -- for example a spurious response before any command has been issued, or a duplicate of one already completed. The ring has only VSCSIIF_MAX_REQS (16) slots, so before the first command every in-range rqid selects a NULL slot. Reject a response whose shadow slot is not populated. Fixes: 6d1c2f48f3fc ("xen/scsifront: harden driver against malicious backend") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- drivers/scsi/xen-scsifront.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c index 989bcaee42caf..aa44a233eac8d 100644 --- a/drivers/scsi/xen-scsifront.c +++ b/drivers/scsi/xen-scsifront.c @@ -367,6 +367,7 @@ static void scsifront_do_response(struct vscsifrnt_info *info, struct vscsifrnt_shadow *shadow; if (ring_rsp->rqid >= VSCSIIF_MAX_REQS || + !info->shadow[ring_rsp->rqid] || !info->shadow[ring_rsp->rqid]->inflight) { scsifront_set_error(info, "illegal rqid returned by backend!"); return; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 12:55:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 12:55:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440803.1658287 (Exim 4.92) (envelope-from ) id 1xDiED-0002N8-OI; Mon, 05 Oct 2026 12:55:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440803.1658287; Mon, 05 Oct 2026 12:55: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 1xDiED-0002Mz-LH; Mon, 05 Oct 2026 12:55:37 +0000 Received: by outflank-mailman (input) for mailman id 1440803; Mon, 05 Oct 2026 12:55:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiEB-0002LQ-JK for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 12:55:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDiEA-008uI1-Lj for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:55:34 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac39e3f-2eae-0a2a0a5409dd-0a2a4509a0c4-22 for ; Mon, 05 Oct 2026 14:55:34 +0200 Received: from [52.101.46.56] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac39e44-be1a-0a2a45090019-34652e38f332-3 for ; Mon, 05 Oct 2026 14:55:34 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5606.namprd03.prod.outlook.com (2603:10b6:5:2c2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 12:55: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.0472.016; Mon, 5 Oct 2026 12:55: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=RIfVusZKSi7uwFQdmfi2dVkIh8mReXIAKjiP4XjPnKrnyMs+yim6M/gw/rz+2a2kDly39AIqDrjQuAE62iQnyGRFTpfCiuialOG3APDWm3LcVdNFXc2BzBEvDzfrIfc3kTz4fhcPY3enkyMtyTnNA/GbpOY7OQB+aQY2yhrZMmOD9PVgM1hy5BQUMhZVmtpQ4jzbTjmCeT88ZWNeUtkFOSisfloY/ItjiAY/rwtbsvDVS0yU+kC97m3SM5ivhf8Giq1yZzC1MGyf/ciUapteBSDax+6ZtnjQfS7hUfUmlmM4DBjrQqazskEoGK3TKvryXSL560PrFj2PCL5y3BKfqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nJJxIiACYqjn5PvqtTYrvBX1lsWtT4q0zkVAoUxqe8k=; b=OKnVy59Hdfec6xicPij4UO62w7JH+8bba13hsDtLpAHbgAbwTnj2KHcpNkd/I4ZFGh3gld3yr+etaqjNMb5cHl+MHK6Ynh8DMCK6AwXkR6caLY520iALhHASWenH+gSiXvSM4Erpw7Wot4uWnDkDKdcd9QicLC2SbHf/Rzx57tMXFPP+vy+mgHE7YTGE/vYlkXoFuZY4l/dXMOdrxde8jbXsnZyw7bX+snGOhMSR7P2GpXBn1KW6qGEQ7AYuD4pGVB3ydzOTqpBGW+PbS6vCzLRuAzMHYlGrcmqjukN8BdotrqDjiVxk38hC6tGiNTnp4KVvNXj7g20vAsVYntGXUg== 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=nJJxIiACYqjn5PvqtTYrvBX1lsWtT4q0zkVAoUxqe8k=; b=gt90cOx0C9SIBbv9ITVXqRAU+pAGjAVZpy/DSkFZ8Mpb1tlx6olDEijIm98jvqDTQdQtLOXyO5inW0a1XV5cVdZleQH6QW7iPz7SaViHLpSAEIgU7AkSj/pFsaQxWoMVD1UYzWNiKXQJuN0LbiLUTfNyByNFy2M1BV0XoC/6/FY= 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: Mon, 5 Oct 2026 13:55:26 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, guillaume.thouvenin@vates.tech, anthony.perard@vates.tech Subject: Re: [PATCH] tools/oxenstored: preserve socket fds across exec live-update, document SIGTERM limit To: Andrew Precious , Andrii Sultanov References: <20261005124654.4070674-1-andrewprecious388@gmail.com> <1791204532.8631fc262581453bbf619ec5b2062170.1a10c1c21670003f66@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0147.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:188::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_|DS7PR03MB5606:EE_ X-MS-Office365-Filtering-Correlation-Id: 51a3a405-7b82-44f8-7afd-08df22dfef8c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|18002099003|22082099003|10067099003|4143699003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: guVuixuiFtVOj2DLwHrZSff164Tfk42gZSPFgU1KI54CTsJW735RdqRzh/k0q6ksy6zxFL11S7X541JtFf68/sdCZEEs7QzmdU7b22rJbvlsPZRfTdsF2O3SysyHGUqoMggTvPKTncgMBtnFyePbhgxJxE+vOyzUR47Q79U30dYnJrLx09OLjU0yo5qUjRkLyjVMaX0ziuMXxY5huIgfne0GV2MJBdyk/SRpXps1laTfSAjVeI2sA9hm4cbOcQdBys6yno7teGMJ23NWLwG0fGnT1KY/1V9NoWpnVrpQPbM7UhOe8pnxMbsNTBNTVwTd8qrAE1Zt2TGPobYwnKboZ/Cbh8V/MZ0gHM2Vp3usGwC2YTQgebxIa6XkbpjM+k5Irz44lGg9DMUslm2fvgwre/mjWIl4EI4wQnm69aO8y/8OMz/jclxeAM95CR3EbcEjQosiK2WHPDhAD2w/koC4VQYk/ukycRZ0rnqGwsBi8D1+7OqLcvgXkEsxpF+rn9CdcF5HO6AN6E2nR6v7IWp11oJ5IWyaMfWXRd63A4zrABSNbGtmCPNoesdVuhu+2bfJh7uuwf9niuCXTbyDsz8Cku3oppmX0mSQ9BCnLxU+aVnG3CsdwaHFWI97WmYTzgcf3OqYGtdotKQfntASjO594yhAL4JGPxNXYksR2qj1xjs= 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)(366016)(1800799024)(18002099003)(22082099003)(10067099003)(4143699003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OU9saytNTjVaN0F2a3V5WDFJTWNCNVJ5TXBJeSsySVRNVW56ZFlkblhNdENy?= =?utf-8?B?L2t3YTlvQldoS3NmQXd0WUZObWRwS1RiZUVxOEI5V091NkhhWDZQR1phaXVo?= =?utf-8?B?RWxQc2RWUEJ6bGZXSXhVZTBmSjJyZDV2bHVibWdXUU1jU08weUd3bXFlMEpG?= =?utf-8?B?Nkd4NkozVG5mbzhXdHBLZ1FUa1UyQnZ5T29DOXJQSUtTNGYwUlJQNUZyRCsv?= =?utf-8?B?RGRJdE5SdmdZb0JUdjNvTWl4ZmVrTktLSzNGUVo3Rm1BbzY0WlZZYTFJVVU0?= =?utf-8?B?YnM1UlUwVm5ZYmZKN0FlR0FDM1RDR29WN2JXbm9MdWk4K1B5Z1FwUDZLK2VS?= =?utf-8?B?ai9vTlFWTW54cTZDWE8xR3JXT3FOcDhJTGVWZGxLQXA4YW9JLzh3SHVZN3I5?= =?utf-8?B?Q0dBakNpTzl2VVlZbHlTR282OXUyOG94MThPdnkxNnZXZE9QWjA4NFYrZmlJ?= =?utf-8?B?ajZWaGZ3RWJyODhyQTZwZjRoUWJvKzhWZ2VZVkhXWWt3U3pCU1BOQ3V3ZFgr?= =?utf-8?B?cEJ4QXNicHpkbVlUZE5OWE11QTlSR1l3R2kxVFlqVGwrSlNQN2dod1NxL0FB?= =?utf-8?B?ZjhjcThKUm5QWlJWRE5DMHNiYVNMRWxHQjJVNmZFUUl0ZXJPMkJXUlBWeG53?= =?utf-8?B?QUkyN2ZlT0dIU28weTlhemMzcTJ3SmViWER3Q2E0ekxrVC9rc0o0cXY0aXBX?= =?utf-8?B?TExDK3ZsS1dYZzUxcndJVmo3cWNtN1BhaHB4ZXpnbHJ5V0tNdzVPQzNrTEhT?= =?utf-8?B?Rm1UdE5uWWZmVlZIYWRXaFBFekdyY2dWUVhHZnVzd2lYOXgvMlN4SEk2bWhL?= =?utf-8?B?SVJ3VjloWkRpOStGVUs3NlVoTUlzeHowNjJiREJQS29yOXplTy9DTDFpRkh5?= =?utf-8?B?V1hzbUtYNFV3VzRDMDBOb2RJb0RRR2poRkt3aGJVQTNFMG1QS3NFUExpQXdG?= =?utf-8?B?S240TlhwZDFRUlZvMG5aeVlBdTNLa2NoekIxekJhOTJFbDVweVc4Ny8wZnhF?= =?utf-8?B?TndhVUFSVitqc3RVTzlRMEUxUkRNMFNiL01DeHI3MHRkSlBoWUdyaFhDbDJh?= =?utf-8?B?WS9ZWVFtVXBoQ2pDdFI0eDlEbUxoanp1N1hOcDhvMnkxQzZDM0dZam5uL0hX?= =?utf-8?B?STVZdW1aL1VRNXB4N2ZydGpERWQ2bVB5eUVwckhoTFlyNmxGQmFDL3FtU053?= =?utf-8?B?Rjk1WFBBMlgzYzI4NnVqNVdKRSt2UVpKQUs4K0kxK05rd2VvUXNRWFl6bW9N?= =?utf-8?B?KzY5dEd0dktIejVTNDJRT2tPbnBnYzF1bXl0SFpvSFlJT2tLUEtIOFYyZnhI?= =?utf-8?B?T1Z0c1JpMnZZNU4vUWtxNUU5YzFQc1lmbGYvQkZpK0RLN2hyS01VSDhQTll1?= =?utf-8?B?MGQ0eVRXTG9pSEU3NTFIT3NBbks5OUtaZUxqcUVDU0VrZHozN2VuQklma0Fz?= =?utf-8?B?M1VuVi9BQzNSQ0Iyd3NicTZmUHkwYmFIbitHeCtpRGd4OVI0ZXNtT2NkTFJs?= =?utf-8?B?cHhwSkx3NFJKTDBIdFFUT3Q1MlkyRkxDWlQ5SFJlR29UL05mdWR6WWIvTDM1?= =?utf-8?B?VHpXVnQ0dVVWeWFHOUpGQUs2RGlJMlJ0QUNUaXJUNFZISmVsQ3hIMHM4U051?= =?utf-8?B?MzUzSzVDL0ZKVTJEdDFFZ2twMkVJWC8yTEJvOFJBN1UwY09WSHlScjJvV0hs?= =?utf-8?B?SFVqY1ZXZzh2Z2trNU1YRmx6ZExKVnhROS9XMU9wNW9rRjhVbjNqQjF5YzZk?= =?utf-8?B?S0tIbytYd0UvNFdXUGU4bnFTWlIzdlNLcWVnSlFtU0pxcTlycXVCQ3BFZkEr?= =?utf-8?B?VUhDQU4wR1VsNkxuWmVuSHdyOWwwdWRVcm5Odld4OWhXRVNLMCt4VTV5TXdD?= =?utf-8?B?elEvQVJVRVZKZlBkdTZxdEp5WlZzSi9FSUJvWG9wbVhVckViQ2p5ZUhFNmk0?= =?utf-8?B?K2dxaUVSMkcxa0theE9DSFZRTVhIUzcyYVdUUTY1UERCRUJxOVBEeWFJT1lI?= =?utf-8?B?bmlWNHcwNVI5VWY4dWJCOUh1eC9FeHovM3BjU2s3Sk1lYWJjdkZKcGN6aCtG?= =?utf-8?B?NkMrVFlMRzhJeGtqM0JHS2w3NDRDN3FIY2J6Rm1uL1NNbXl2TTU5WitxUmI2?= =?utf-8?B?eSs2eWxidUpiMzIzR0VrWlZ2U25xbGFGTG9qdVVjeDY2M2V4L3Fxb2lwaEdG?= =?utf-8?B?NW1seDlnM0Y4RktSZk1HNEVCQnFVRXpleVNHbE80dEpjeDhRRnlGY3d0SVlh?= =?utf-8?B?ZmVnNThKRWl2Mkh0czY1by9yeDNPaHpJWXFQc2pzdk81ODBWOGMwWkM4a1pw?= =?utf-8?B?R2pva0VtSDI3UGh6ZlhQcytYOGVpZkUrTHpDcFJsdlROR01xSmR6QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51a3a405-7b82-44f8-7afd-08df22dfef8c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 12:55:30.3661 (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: 99lN3BdsPFB1hmL7WVgxGDyRnbDUvqwO9M7MDLxKP8tUvVIujQhZF4KGChmUM1O6SftWVMGjsg9wD4PQzWTRv7z9XLgnNgMsM76tppl51X8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5606 X-purgate-ID: tlsNG-bad1c0/1791204934-FCA16034-119F3C2B/0/0 X-purgate-type: clean X-purgate-size: 583 On 05/10/2026 1:50 pm, Andrew Precious wrote: > Apologies for that everyone, gmail keeps giving me "The response from > the remote server was: 550 REJECT" > > On Mon, Oct 5, 2026 at 3:48 PM Andrii Sultanov > wrote: > > Please stop re-sending this email - I've just received four copies > of it. > Please don't top-post. It looks like it's being rejected from the mailing list, so it's only the direct CC's who are receiving every copy you send.  Either way, you need to fix that and stop sending out new copies. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:06:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:06:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440814.1658296 (Exim 4.92) (envelope-from ) id 1xDiOZ-0004H9-Mc; Mon, 05 Oct 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 1440814.1658296; Mon, 05 Oct 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 1xDiOZ-0004Gt-Jf; Mon, 05 Oct 2026 13:06:19 +0000 Received: by outflank-mailman (input) for mailman id 1440814; Mon, 05 Oct 2026 13:06:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiOY-0004Gn-0s for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:06:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDiOW-007PfM-U7 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:06:16 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a0c0-8faa-0a2a0a5109dd-0a2a45098030-30 for ; Mon, 05 Oct 2026 15:06:16 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a0c7-be1a-0a2a45090019-cddcb483a49a-3 for ; Mon, 05 Oct 2026 15:06:16 +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 695CFUFj2366423 for ; Mon, 5 Oct 2026 13:06:14 GMT Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4h49tvrh3y-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 05 Oct 2026 13:06:14 +0000 (GMT) Received: by mail-vs1-f70.google.com with SMTP id ada2fe7eead31-7bf634a101fso1539218137.3 for ; Mon, 05 Oct 2026 06:06:14 -0700 (PDT) Received: from [192.168.69.225] (pmd666.hd.free.fr. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48c6229ce17sm3389247f8f.29.2026.10.05.06.06.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 06:06: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=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:References:Cc:To:Content-Language: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= 68/MEj2aCnTszQcG+42MXKwOQtnPqyWZO3EspYwBapY=; b=dpawgZD59/svzDvA 5eyEAYiHv2bphtiWRdbm98p0zG4ASH7l9aodoZmPfNdd9tJZXy1OgTlyU/IBuDZI HMoU5QtoRKm4WWYYjGkRVIu1onMT3aNaKjFdeORaxQ9KGGWvk7g8jZ5eG9bQcg6l Gf3TSvWV7AFgw+CAeYalbTi18XoYO/gSdKTdMkfUR2S0/S8AGWtKTTWzthENpTrd LqOcWwW73dMW5+BZ2mOf3MWnIBjri23EfBFOfeg9ZkxvyelGJkDLQekPerJpZoBv v7glvw/Dat37P7uQkZJALSWGl7jvLJKVjZetBltp5/j/4JRQq2KXoeQ15N3aX1xq ar9oeg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1791205573; x=1791810373; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=68/MEj2aCnTszQcG+42MXKwOQtnPqyWZO3EspYwBapY=; b=cmET0Lto1Zye2oggOJEYM7MrorBL4rN4uU4GW+oDaZNEj+JGfbOprwI0MYkFBsXJzc qvPMEShKkaQUI+hWhFeZk2hTi7UaG80ygrUvoFj9XCk1jWlvildsR5mr6La7Hco2j4JO JYJY+tfFN/ZWHCFYounnwhgbLCb5u6o31hlv78QJKoKShs0Cmi65vv4bS0BNej1hPWNQ mdHT7QeMnxltJsSkfQ1UyazytEtbJI6e6QazSCnH/f1ad+Fy+0n8DaD6W5WoAWI/Ki6q y1Bvy01xSka8dW8iaQhzjrhBX/0PDDoPj4BqAv4L7cSiAkYhK5vaSxyX6BTDZzuaN0vg EEsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791205573; x=1791810373; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=68/MEj2aCnTszQcG+42MXKwOQtnPqyWZO3EspYwBapY=; b=s5+5cZbwAnOho3T4w3ymIzpJ4T0/BOO9DEmP+E0+Gu3dFrjlCcJgCeZxCXTa7kUaEw zma3gH4vyQtXC/tRzJPu90+DlQ6OeaRxN0YMKGd6A9dqWAymP4cNbyVqFtiuHx5nhHbx pCbFghu4YzpjShI6S2l00dEj95GNc1jj7d+nS17zlymlJ35RLbybzpEcN1M011PqGbcx EazWL+dCJ7UKEzdUc1XtbMyXUTX31oQp+tWQurFCRHXPKGpzpPI596bieJ2PMgktZnyT w2gowbhMGqPVj5sN3V2h/u3pVYp4Qdm7Z8+3PlRiH8LCIVvCRcb6aTheqIWxeFdRQ2dx KU3Q== X-Gm-Message-State: AFq9FYLrlkVuN7y2BB2+2AiDTHsUkAgIzd8dyeNxQmEy17vcOoLOqG0j 31pDtkZf+ow4OplO4iFE7X58eQfQqkSEFntafYy20mMhhZZlFFmq0WnCcdpGtZ+qzTbxtFaczdE N3mnQGz8ZcQOxORg4rF41qek/dOp5zUQmzuKijm/e/47X1zGcS1BhG0AeeSe+9O1By0BoxA== X-Gm-Gg: AYBFou1vpZeitFVZ2SJDR38DKsZAZvrDRO5xZ3y4BjNVSHnsCkY2gue1CjeJmOLpW48 SQD41uzPdMYQcjPlQYvmb1AmYKNgz8789cUZ53FGloEioK01wkgeq6K71s4JUEFjf0n43hVZjJv QR8sTgZYjtSduOgkHS+ceT0Vo+qrVADls3qwtEP1rVsl/aGDkW/PU3S65VB3WyhsRlCciKSzqtb O1xfiQz9ADs/5o4KRdtNLilCJtoC2/IOIl/fif2+b4G/YWzKPjmJmMwoOQwMO1Hk+e54tMdNuQU pDQ9Ej3KZfCtiTgaN24fILOc/AApJEM0gd2pIJ26i+y2JTJ757cw9JwmReZAeMP3+aljDtBhDSh DPn67QRoH2OCCNFlIjbGVc0LN1aGmHz6ahA== X-Received: by 2002:a05:6102:148c:b0:7bc:696f:a5fb with SMTP id ada2fe7eead31-7c0f5baadd7mr2929698137.29.1791205572734; Mon, 05 Oct 2026 06:06:12 -0700 (PDT) X-Received: by 2002:a05:6102:148c:b0:7bc:696f:a5fb with SMTP id ada2fe7eead31-7c0f5baadd7mr2929564137.29.1791205570734; Mon, 05 Oct 2026 06:06:10 -0700 (PDT) Message-ID: Date: Mon, 5 Oct 2026 15:06:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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 References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-2-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20260911143627.2743803-2-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=aN9lOr9m c=1 sm=1 tr=0 ts=6ac3a0c6 cx=c_pps a=N1BjEkVkxJi3uNfLdpvX3g==:117 a=4s3hRJSeHn4rkQlkrse1kQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=20KFwNOVAAAA:8 a=tVdpVsJRxwjYG60tULUA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=crWF4MFLhNY0qMRaF8an:22 X-Proofpoint-GUID: SVPfH-1JGxmdFt9ZARadIm75pUNQ4Jo8 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDA1MDA1MSBTYWx0ZWRfX387B4Avl60BS 9h4Qya0tOI+QOY/XtqDIvR8o5h6FX2J47k0SdCz3PP+i6kBDrzKZPRKFpJGgq2aiNbniginY/E9 10kYuKFcdRmf4FOLjM2jjR+OSH6KiFzaGxe7mgmXF0BhNvStKzcNnnqYeGb6Nj8BUSryEnR/DAR 7GHQM/t81oHoZxUWofPe5BAEAnnSnhL4ot1Q8LpbkxvtxC2sfq5eVR/+Igj7/37nFeVplFpexJd eWYyA3zZrRiHO2WWoRk8LyEP2tSzV1dcoN7MVKEryfbLm9kyYxalvMoi2owVSIep+PF3g3hv5Jc qgk+Cd352LbtyPsvHMNcj4iAwZuqSnoLiNAQCaqjtWTQDjjJUqR9Bh0t/Lx4aOMompZ6G0zMuCn WkCzYa6wxmnP44hz1Y1Z3Dz9vrUsF5byY8QAS/ptPJB2HfxM1zUdYIVsKHoKqS6hhTs6UEv4rYn jHhjEYWcxJaDpMEcp0A== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDA1MDA1MSBTYWx0ZWRfX0tmN8eUip+1V QXAjUg0badUcBrkmLlkAvvnYQETEBtSl9uq1IP/OVBGjanbsUg/ufbephUWdECv1ZMNBlUkdM86 0+nb2z548dgoVZbSzrrOw7gF2beECj8= X-Proofpoint-ORIG-GUID: SVPfH-1JGxmdFt9ZARadIm75pUNQ4Jo8 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-10-05_03,2026-10-05_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 suspectscore=0 clxscore=1015 spamscore=0 phishscore=0 malwarescore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2610050051 X-purgate-ID: tlsNG-bad1c0/1791205576-FC610034-EBAA9B3A/0/0 X-purgate-type: clean X-purgate-size: 1361 Hi, On 11/9/26 16:36, Daniel P. Berrangé wrote: > 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(-) This patch should be split per machine / area of maintenance, so maintainers can officially Ack their commitment to security boundary for their machine. I'm not sure LoongArch / RISCV / PPC are. If this was previously discussed, then pointer to the public discussions should be listed in the patch description. Regards, Phil. From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:15:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:15:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440821.1658305 (Exim 4.92) (envelope-from ) id 1xDiXh-0006DL-K9; Mon, 05 Oct 2026 13:15:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440821.1658305; Mon, 05 Oct 2026 13:15: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 1xDiXh-0006DE-HP; Mon, 05 Oct 2026 13:15:45 +0000 Received: by outflank-mailman (input) for mailman id 1440821; Mon, 05 Oct 2026 13:15:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiXg-0006D4-8x for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:15:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDiXf-001gNN-Di for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:15:43 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a2fa-e002-0a2a0a5209dd-0a2a4508ca70-24 for ; Mon, 05 Oct 2026 15:15:43 +0200 Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a2fd-f659-0a2a45080019-94a39c01ccea-3 for ; Mon, 05 Oct 2026 15:15:42 +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 695CZaVd632447; Mon, 5 Oct 2026 13:15:40 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 4h2se5abpn-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 05 Oct 2026 13:15:40 +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 695CHrxN1637701; Mon, 5 Oct 2026 13:15:39 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4h3e8g5cwr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Oct 2026 13:15:39 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 695DFdjB8716960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 5 Oct 2026 13:15:39 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E681558103; Mon, 5 Oct 2026 13:15:38 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EC404580FC; Mon, 5 Oct 2026 13:15:37 +0000 (GMT) Received: from [9.61.5.156] (unknown [9.61.5.156]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Mon, 5 Oct 2026 13:15:37 +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=1NqLZ5 dwWZAj9RWdXNVN6BhrXdnLPqLMnyjw9/4Hui8=; b=jvt2a2OvWwv/WXwoWJ5t8z pDO7LkSa07W/ARpepjURvqPDHWsp+nUTSupx/AklCyBVpFuchajk02k7J1HOPSp7 rFgWY6p4bRWBwojnIADpOu1lYCzMsQ7yjruMka6qvJPqsJ5CWSF8z2DhJZrfaSB3 8oDVk1VtWODbIZKa9MZjTYeFZHPareDI8QRUBc60W9dumzST4AyFiavj7I7bNvST 3jJbZZjyu2Z8axlBnK/z+Syx40fPBaT78sALlTSc4PfsWozdFPkiQ1uKyLVjjkfc GCehSG9HDhXP6OCMs3ZKmDUseX1ayqaF4s6euVomf8XQGnR5XVL71GPR1tP9qF+A == Message-ID: <8ce35da3-3be6-4164-8ab5-ff606a5affc2@linux.ibm.com> Date: Mon, 5 Oct 2026 09:15:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/28] hw: mark all virtio CCW devices as secure To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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 References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-5-berrange@redhat.com> Content-Language: en-US From: Eric Farman Autocrypt: addr=farman@linux.ibm.com; keydata= xsFNBF7EiEwBEADGG0EtNKnjp+kQfEVqlqxXoBHjnaQptFpMgxNlz2GtqOujY6nzEWnybIXY 63XUTmMS/tWUf2DTbNCNoWwumGM/I2Gj1uGyMnc4Q477BQlL/e2/9MRaut11rwHsi4zmWylc jO0eFTSLFA8yFBj9osT3uZzk5TwWkD8sf+rD916fFVk0G39uYEd5sjEzjeOf9/dwXyZpjJY6 api1pUHEw7weRvOnllJAfIKFz+KoR6d7ezvMF9zOYHF73FGeSVIYoIEUhA5Cdg60rSlTtHb2 cftex3/cEapvY5bK3CKJ33BVVK10Bht9XfVaA/AOcg/3o5ZbhSIwz4xScGsEVf/Yr368YMdr 3VkCZrmN2ppmVRz/RvAmCyItnmzoVDlSREA6Faw6S0x8Oi7lN0cKh2hy9VPcVupraXJZrdAh GtdU+jrJvSbpdsrX8F7K3RwynbiqGrqC0izGla04hhtei/uwthatglukuxep4PknDGbzijg8 Ef7A8t3qEVklUDrsnNPN5HbR9QQdeF0HuWsDTfILbZv1MICfOK3BCDeT5mJWaJCoQ2rbuljM e1hFSt+mr7GV4h6NcBE+uGIqDSzQORtyTo0uBV4et3cSE84JxOfXBMrj0TlL1855JaIoPWEN uhDRB/dHW8+Fumq2du5hLcaXPka+MO26cNVKVLF0/JjwMTZ9bQARAQABzSJFcmljIEZhcm1h biA8ZmFybWFuQGxpbnV4LmlibS5jb20+wsGuBBMBCABYAhsDBwsJCAcDAgEGFQgCCQoLBBYC AwECHgECF4AdGGh0dHBzOi8va2V5c2VydmVyLnVidW50dS5jb20WIQTSxgUEyej1aM/lh7U4 J7IScb+VYgUCYel8TgAKCRA4J7IScb+VYsHAD/9BSQj7HeJf90PttOmVh35Bb4QyHLZ4g+9x waM59JCKGbiURuNRIGnoRarYXHk6vfy19v8v56Dy1IOlKWaRnizp5Mw9zXBBTCs4fgNbOzY/ SggFY2UzcziXDG29X9zznq5LgY1Jf/cwm1O+rn89GKCZWZhLEB2wKzBj7hum7NBdW+lxfVwp 2qONGDerttWDwAHxJ995k9aDJahq9kIKEMEZbrTQ8JI8KZGoox6+HA04EhoNzxvbV0J+/gLJ 2DkvxN5/xmcD3z+s8B5ev3NarOF17AIA9oCdfu8CPAupcNqJW86m19P5q6AyRB2ZLyAIAAhr HCXrnlh/8HJW1yCOVXxprFdpg1SX1fuArjbFAh53vVVDfkZlwHeTeE7+3y1rtDLfy830pqdD ymv94yey2y1+iZBdbaW0fSC/JkjkOCy8oZawkH3geM4MXV4ze4gbBH6BhxW/0gbEYjnLm3FA 53JcXwhHQFPWIYEYYPvATJi0JUiMY1Znkm3QBWDOCXSrG0tHpAclBa9L40zLRwA1h9YOMFEs qvKijUdvcDf4sTdJ+A6YL66grzul5vNt06NlqsI8HUDHE6vghqyWxupCav2+9b1BuLie++er b8OCo5n3TUHsVMjYJEePU1EkcCa84dCm+CXqPthgRv0sbe4UQEd/qUoVMdWj7Q7FL96mBn0G zM7BTQRexIhMARAAp+k1sC4y7Wtwjqtfu9wIihvY/Vot0v/sKg8CRGRIIRGLiCeA9o+2ZlxC jYztT3Leri5Vo5z09OmRMvoFLJjcHMCG5sYeZwOWNAbeuAxGkIMDSB4pLl3t2c+1PQuMBCd7 +mRZFaMEJfT3nhdUKxy2rp1+YucnA67xGXUJCiD5l9UmhPqa7SAYlpMAqDz7cmBo25c/UNm1 Tpwjrh70jq/4guV5gnprawH8nkRjdKH1JvKWvkuaB7FNZ9IuSHlWclcQX4IQMsaxsU2emAbP VYv7l4YNlKfdlJd8tuEodjuMLOBnr7e9H0hVNUWGFN9bkBNRu3zi/jvhyu15Iu4euR/WdVNu 2K2iYxIfiGMnv0F/a6R1bm10lCJrjyf23J8DYIeH4YmHvOOqYFkq3DWOctlXbb3+aABqjYt3 mkiOLXeplqbo/m3rWcGNd8Q/d1aVA0wm5+Nt3RdSuXG2FHOFdVUQKPLpf1NUH/LInBhS/9Ys ajm6tWXKv7hxwWmyz0u/th6gUra3KpARB1ypebWHULLNzKGwVS81XNs76QhXwX04cyiwLqKb WqLqJKThz+rLa09Ap+eO/UzPfFXvWYWfTeFRIQ/tKF332ZzRR8Xrh/fk//YXyRfpoE/7i5uz ve0HZWp5jXg9Yb+S6g0+XUKznnN9B8WLLCcuRIuSa722070v7KsAEQEAAcLBdgQYAQgAIAIb DBYhBNLGBQTJ6PVoz+WHtTgnshJxv5ViBQJh6XwwAAoJEDgnshJxv5Vib28P/1BYT5gvjuEB A80AXo/IqycicXxDJtrfmyw4COP7bi7AuiDcKyA1wRzC51paKwPFB8Unk2GvG4DV6aDmGTJY +GeCYgthQ+znW461S8B6GqDCAQt2VDNNFVU+gTuh7vYQOgt/OjtiiAvMIJBVRbXoNSRokKOF tpTiXf3ZOsAkot5ZmxE0TV94v18sp/bC84YvFyaxpw5bilT7bmpcq8B8/3yb0kmy6gXLcQAp OnomV3sQBmm050amiO3tvxMNv8J71AvNdTG/rojTDKUl2Nw4f+aw4nVw874m2XpEe9JGRw54 5d2dN8k3GpzcTBe9fCQPOFHOGkQ1CgptDkQuQVD3DIeNzQjXf6xehEymIKnLOkukT2smV0zh fj08z7eiv+dsmnBsbhdM6DKU8qIgkTu77TfHUKjjOY/Mj0YHPuH/J4b1AZFxBhGP0BTKiB2W CR6/49XVKvY1jHxgadSSNCD+f7tEqUNBlVl+P0emMJaYpK1+gy88ma4g3nvyOVe/VzDPjGDC 4HX/6RAR4Dbzry6/epWTTji+7ApzePzmJzPcuzD31ICsgT2dJ6ydxyxxXikBFJqx6BPOF+u+ 1BtKcTz1ek3I2sWvBM1V5CKaFw7iNXxS6HgS2scuAT2awKq+BQlt778/GfBWpXonfqixMvit y8m0x6unNti2MZIUMy0m2gcE In-Reply-To: <20260911143627.2743803-5-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDA1MDA1MSBTYWx0ZWRfX71xG4ZJBIVbr +2BJq9/Qn9Z7Eq3jKV4se9A1DquK6oFxYeSSznhCfLL4lNZ7SdKpX8EyVfq14ZYtsd8Me+4B7Bh r5jQYtM1FkjBu+6RUsQl/8MqlLQnz8s= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDA1MDA1MSBTYWx0ZWRfX5MXI1orFUyP1 s7xx6dob93b6AtdPNjuowZAwHwnfwyhH6yrirtu2ms/2spr975AipTN/bEpfTWWUiOv6U2ROi6G iqaefh14WqsNYiqtWuHX2JV/DNUqUtrPulrwRtLEb3w0edx7WjNr6i5giGH1XYO8dknG4kt+EuU hHi8wj4sHUif5HagsKZQlqIhVnCt3xlB+8FJLEofS7FgNcJYlWL3cDp25/BVYvHB8C4f/GP//ip Alq3cBjt33uFWgYoZYXMU+wEbiXxtHQgv2tnwb/T/x8z0I2P5gZYN1uUmrRp0YqplspljQpXqRi RhaP4MD5qksh3omadGC2Kvw0eL3e2AHTqucWdItzaZrloOfOl9iYcOvXVKcQbqK63J4lM6D7LpQ mpn6RahyjeKFA3CuSFow4QPH1LhSvFIoxVJDMRp+dW+sC3UThCWBQL8pBBCfrZORlys1jLScygq fypf+zwdy08HutoDqqQ== X-Proofpoint-GUID: bSLXlWEkHqj7ZeiybnpzrhM2MnErRwWi X-Authority-Analysis: v=2.4 cv=UNRIjyfy c=1 sm=1 tr=0 ts=6ac3a2fc cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=20KFwNOVAAAA:8 a=VnNF1IyMAAAA:8 a=Us0OraqUOvBpldwEjHIA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=ZXulRonScM0A:10 X-Proofpoint-ORIG-GUID: bSLXlWEkHqj7ZeiybnpzrhM2MnErRwWi 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-10-05_03,2026-10-05_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 impostorscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0 phishscore=0 clxscore=1011 priorityscore=1501 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-2610050051 X-purgate-ID: tlsNG-c1860d/1791206143-CD94A87B-06F42918/0/0 X-purgate-type: clean X-purgate-size: 976 On 9/11/26 10:36 AM, Daniel P. Berrangé wrote: > 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(+) Acked-by: Eric Farman From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:24:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:24:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440827.1658313 (Exim 4.92) (envelope-from ) id 1xDifq-0008Di-C5; Mon, 05 Oct 2026 13:24:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440827.1658313; Mon, 05 Oct 2026 13:24: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 1xDifq-0008Db-9L; Mon, 05 Oct 2026 13:24:10 +0000 Received: by outflank-mailman (input) for mailman id 1440827; Mon, 05 Oct 2026 13:24:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDifo-0008DV-Pf for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:24:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDifn-00CdJz-Ht for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:24:07 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a4f3-e002-0a2a0a5209dd-0a2a4509e6b2-22 for ; Mon, 05 Oct 2026 15:24:07 +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 6ac3a4f6-be1a-0a2a45090019-aa0a817ca4dd-3 for ; Mon, 05 Oct 2026 15:24:07 +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-63-obwuuQIhOZGiBRqBapSW4A-1; Mon, 05 Oct 2026 09:24:02 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B00DE18345B8; Mon, 5 Oct 2026 13:24:00 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B0D4F1800446; Mon, 5 Oct 2026 13:23: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=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=1791206645; 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=KV90x+3zFHk7cNPd+HxS6xQi8Qt1QYZt5hhvtroAleM=; b=ivTG/lEMHhYMVj2bZKpzKAOX+U2IonxUdUzUmVKIBRwagu0i9vse+z+QRso24+EosHZxp4 b4yTgnb+P0V2OdGDKKEX6e0OYPecC+ESbBR3oCtPaEe2knleRHcW0ScXHzI5FWvocgMIZ2 bgVjw3SnmUhqlqzEeY4hb7eQAJRKUDQ= X-MC-Unique: obwuuQIhOZGiBRqBapSW4A-1 X-Mimecast-MFC-AGG-ID: obwuuQIhOZGiBRqBapSW4A_1791206641 Date: Mon, 5 Oct 2026 14:23:54 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, 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 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-2-berrange@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: WoMkaC7mblLDCGgvFO_a5kt-6g9kgWo091E37P6ttUA_1791206641 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1791206647-39AC0034-D518AF42/0/0 X-purgate-type: clean X-purgate-size: 1926 On Mon, Oct 05, 2026 at 03:06:08PM +0200, Philippe Mathieu-Daudé wrote: > Hi, > > On 11/9/26 16:36, Daniel P. Berrangé wrote: > > 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(-) > > This patch should be split per machine / area of maintenance, > so maintainers can officially Ack their commitment to security > boundary for their machine. > > I'm not sure LoongArch / RISCV / PPC are. If this was previously > discussed, then pointer to the public discussions should be listed > in the patch description. Those are explicitly documented here: https://www.qemu.org/docs/master/system/security.html#virtualization-use-case so this patch is just encoding what has already been defined. 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 Mon Oct 05 13:26:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:26:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440833.1658322 (Exim 4.92) (envelope-from ) id 1xDiiD-0000M4-Nt; Mon, 05 Oct 2026 13:26:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440833.1658322; Mon, 05 Oct 2026 13:26: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 1xDiiD-0000Lx-LG; Mon, 05 Oct 2026 13:26:37 +0000 Received: by outflank-mailman (input) for mailman id 1440833; Mon, 05 Oct 2026 13:26:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiiC-0000KI-7I for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:26:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDiiB-00Cdqv-GT for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:26:35 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a586-2eae-0a2a0a5409dd-0a2a450287c6-4 for ; Mon, 05 Oct 2026 15:26:35 +0200 Received: from [205.220.168.131] (helo=mx0a-0031df01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a588-6ca4-0a2a45020019-cddca8833614-3 for ; Mon, 05 Oct 2026 15:26:34 +0200 Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 695CFNAE2849519 for ; Mon, 5 Oct 2026 13:26:32 GMT Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4h49u40pmp-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 05 Oct 2026 13:26:32 +0000 (GMT) Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-93e834ff4d0so33477385a.3 for ; Mon, 05 Oct 2026 06:26:32 -0700 (PDT) Received: from [192.168.69.225] (pmd666.hd.free.fr. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48c62270751sm3609856f8f.13.2026.10.05.06.26.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 06: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=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:References:Cc:To:Content-Language: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= UVgGfElQqq72YJB4eDFJMKlG7GcShx6WHC77Em6o9hY=; b=ZC1fHKHV/qsoDmPj FDfEtTM1kmRRdSaeBGnLzA4meN1RJ8E2t9PCpmuXWrsF0YZ8A8XK0Pb3cIegUwc8 OIUPAs6axekii+F2WtJvHLCihGAbNUuLvzsXQ4vTJhgKA1NfGuIfkF25mZRF/PcW wmyTMqR4bxOe1lNa1FA1DaDeHLw2ad2EMSxZjfrF9QI8mBWttvQPxICfcJ/MDI8c fJj0o5IemJXEcP+R84/ouKMskWPiIdJmOLuR8bCYs/5SAjR9F+CvElb5JNZ4Koqw 4ho2FY/s8yFn2TE6go/hlxpZsyOK6GuzlQnexSTC+GO+8marjcIkhl28Tnuu9Aqx oNrVOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1791206791; x=1791811591; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=UVgGfElQqq72YJB4eDFJMKlG7GcShx6WHC77Em6o9hY=; b=Be2pi5JKbSYmRuRBNSM0AnpAdI8BRP7E+mqPEElWG9Mu76raA0RwyavHuNO0uAwrn0 YoUtxyUf8cgoXmOV3I4MSbELmG6L06EhKEe7KVcFuOHQ8biTphT1Xg8ZFE0VrDgEIrKk TV9J2WXXk9z23yZ+CnxepLVVqDcQEAM4cgA+T0vPBckdysm/goJSGpFrPui7nFo6I+Qu 3t1sJbx2Fv6HMQAAHpHCqJ0ZQzez6UQGp2yUTmvamlbANobiptMZnmtmTSaSaDpqGSHC hCIs/TVkfaznDHhCJf47OK7GqZ6QpPr6mnbw/oZ7csxCLv96u/eCdY+xiBh+3mXQdo+k GbwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791206791; x=1791811591; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=UVgGfElQqq72YJB4eDFJMKlG7GcShx6WHC77Em6o9hY=; b=PE/Gnjmj8TDurlgJTjpGOibmDCmbI0XzZIuLxo8jcqi3svse4cziwYQlu/ryRRxDhv 8mXD8N+AI91NtmLvfnhBdkq6JptiH+9VquXWm9n5d8ZGyn181MXPRbzeEBWlaGtHq4lH 9feh+SBTzSZeRkGQP/0pIGkfGPQwLv4GyZfH6YAf/e5XWAdh0wgKDhMFCUYcXyRnhLd6 S5wcPp5q61/Tt4EUQqnozto6VE87RHJYKQO0gj85uEPOjD7UftfhORfB+33iL5B6qnxV F+2gHI9pYZbyx5hYXV2jk3Pe6cwDEQpHjMDvOgKJefjHnLffHUhyreUDpKSb+DOGYYTc EubA== X-Gm-Message-State: AFuF++kUDJhZoTjZyVz3AGnbbHeauac7sbcbEZYtADAWwgRKqxMqdc12 Z810wj5+ePOMvrvBDr2iXe1k3kcuEUjJifXCnabJANIiwFOVEgmtSRB+o8uR9P3CacYA85TJuvq MECiJjVgAQBAWx25ljTvjlQ0PAdwEbpzzh+nobyVIe2sKxIPnfZKVlEUtyltSp7frVJmN4b1F3c 56Jd+u X-Gm-Gg: AYBFou1KiJSvsAt+wQlCJfNPCVGmnHUQYNLuo/OAGounZowHdT2NxZuQOHbg705B+sr DQdTcM9uEytCWosrMey0MBY+lFCDm+bzP/uo/VhyxEsDK6DbxduSfWkN9/vXZeBSgGsHftHPOO9 OCizgGXDVF4nIjJB2ZYa7zJIJGRDRFFe4xj0G3mzkikfWd/YtenuzoeLsPklhzh6vhiO7Dhm4dW SuwRaFiyzrZ5OtlGhnf7yoIGvNb247rP3pGy5NG90yI72mKrx2jKCPEyM0y2uI4sZ3hblXYqMZF V8nM1RvSMYe+go1sQaj6M4LIV1gx24Kktl6wBPMkVD9M+U0fVQrPzDcySwC5rwaM7lOGDb1Fdnc XnLhqd08lichGkfurVeNpmipXkBUcDCKBtg== X-Received: by 2002:a05:620a:90ca:10b0:937:d6e8:59b0 with SMTP id af79cd13be357-93ce7c145d0mr1342533585a.10.1791206791322; Mon, 05 Oct 2026 06:26:31 -0700 (PDT) X-Received: by 2002:a05:620a:90ca:10b0:937:d6e8:59b0 with SMTP id af79cd13be357-93ce7c145d0mr1342528885a.10.1791206790784; Mon, 05 Oct 2026 06:26:30 -0700 (PDT) Message-ID: <67742103-9b40-4c02-b297-e5d46d80482b@oss.qualcomm.com> Date: Mon, 5 Oct 2026 15:26:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 02/28] accel: mark kvm and xen accelerators as secure Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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 References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-3-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20260911143627.2743803-3-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: c3xTJ_Qbxzoq3sBxTpiLO6H0fzXwfP1P X-Proofpoint-GUID: c3xTJ_Qbxzoq3sBxTpiLO6H0fzXwfP1P X-Proofpoint-Spam-Info: AW1haW4tMjYxMDA1MDA1MiBTYWx0ZWRfX8Hd0CVC/vmrY Ai3bB7EJBxuZzHcL5X1xsN/X+P33mIeeLphik1R5JTNMDr9J/D8ogWEukNM83i/9fhXxQWx+Yi4 B8lGmxu54YFy7+dNLpUGwbWVaL4YSw4= X-Authority-Analysis: v=2.4 cv=LuEHWXdc c=1 sm=1 tr=0 ts=6ac3a588 cx=c_pps a=qKBjSQ1v91RyAK45QCPf5w==:117 a=4s3hRJSeHn4rkQlkrse1kQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=20KFwNOVAAAA:8 a=ft2qPWJe3-GeceLKO5gA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=ZXulRonScM0A:10 a=NFOGd7dJGGMPyQGDc5-O:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDA1MDA1MiBTYWx0ZWRfX4Gv6jx3wJOQL q0w2LdW0HuLZI5Ar78pxadcMKH28ekGJ7zVP2S+Xk41NHHwzopQNTirY50KOQO+iL6LnlZzLAom +dcc2pKEQ5ZnCTq3B06sUBBXirWNtfpp6/lSl3Xq2ZRyA86Emvj4+jz5U2hsEK/HYcHLTL/YEwT EfWFjrNpiT3oIxNx3eY1V8O/suenMr6j130WIBLvILWH7RV+vdfAhkxqWQJkhJQQ5OnJLx7Slp6 +TBjFTGqd/wANRnM+AVVicV02P/B7Nt3Gr9GnuWFEJ1UBcuFx6wmB2xNC+kXCbjeYRKxjq+rsBK HvXLo1eWd62yuAgtf1MgHI61I7yGOc9Gq4V2R5fll5ZSmAR59OQ1JrTJW1CUIvGbzw2ujzkhLqG 6W2AYM/9nxtApebHlQGiu9S1yTDoE7gukEqjRCfC/N3w3VDsO4jGJFFrv9gulVj4POdb/omjXhv iB//WBrEyfhFOgN3TKA== 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-10-05_03,2026-10-05_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 phishscore=0 malwarescore=0 clxscore=1015 spamscore=0 bulkscore=0 priorityscore=1501 suspectscore=0 adultscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2610050052 X-purgate-ID: tlsNG-720697/1791206795-F32B12AC-0BC2C3F3/0/0 X-purgate-type: clean X-purgate-size: 947 On 11/9/26 16:36, Daniel P. Berrangé wrote: > 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 + Maybe split so maintainers can Ack separately? > accel/xen/xen-all.c | 2 ++ > 5 files changed, 7 insertions(+) I think accel/nitro/ is also meant to be secure (in patch 6 you mark hw/virtio/virtio-nsm.c as secure). From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:30:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:30:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440840.1658332 (Exim 4.92) (envelope-from ) id 1xDilm-000219-6e; Mon, 05 Oct 2026 13:30:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440840.1658332; Mon, 05 Oct 2026 13:30: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 1xDilm-000212-3z; Mon, 05 Oct 2026 13:30:18 +0000 Received: by outflank-mailman (input) for mailman id 1440840; Mon, 05 Oct 2026 13:30:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDilk-00020w-Hq for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:30:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDilj-00BEjA-9G for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:30:15 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a660-8faa-0a2a0a5109dd-0a2a450ac9d2-40 for ; Mon, 05 Oct 2026 15:30:14 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a665-f2d2-0a2a450a0019-cddcb4833af0-3 for ; Mon, 05 Oct 2026 15:30:14 +0200 Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 695CFXF3914119 for ; Mon, 5 Oct 2026 13:30:13 GMT Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4h3chfkwj9-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 05 Oct 2026 13:30:12 +0000 (GMT) Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-939c30aa9a0so184299885a.0 for ; Mon, 05 Oct 2026 06:30:12 -0700 (PDT) Received: from [192.168.69.225] (pmd666.hd.free.fr. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48c622bb17esm3500119f8f.45.2026.10.05.06.30.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 06:30: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=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:References:Cc:To:Content-Language: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= /iCgxSwi3RoPvij3TTorlI9rkpxXQmuhLqHpTg4Dmx8=; b=mWC55rueulo0cyec 4DHpszLix4/EbA2Z0EiF4sqEFype7emqWTYRQylDT/227otnYQiXxSeKo8vhh4/n pBVA2/zSDvKYkZ6HI1TD+m5HHQCF1SdD25Z5Rv61xMFW5vVr0oxH8nODXq7wotUP 8kAHBJhjMqrd8hG+Wliekw6YFsw8r2LAsYw8QKQ3dqpsZ8o5D9jYkn/MDVJK08PA 5zoWWRSubhPyFCziXILClpx9wnt5/vMFGLD/eeYki2ZezcLzItmzcB3cyTN2izRA oHCYIDEu/pe3jPOH3rdC6TRgALil+PLrtHfOC49ERP0RvUGb0B4umAj58UfDA1gy xHe7zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1791207012; x=1791811812; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=/iCgxSwi3RoPvij3TTorlI9rkpxXQmuhLqHpTg4Dmx8=; b=Yht02DgQJgVsoG9xzpy/nw+ghB1WfZorAsOmTE0YjVnhDYl99b8enYi/4bop5iVuf0 1wRC5y39sLk9woV3nVN50HZ29T+XkXlQvI64m7pZ4ucFCj+sJCqb8d663JIhjiWlZ1ow K547h3K0Li+Yf9Wc0hFtTTTe4E1Gv0hMODSwe9qAcQAKx1CcycDSA9MJcH+Ml469T25K JBhw40wwXJYvdnxFkzyazOC8F/7vhBYk0QU5LDfweKVZgz/gVwYUgoM6JYS36oARoKTd +bxL4irSKrST1euVnNjp0wpeW1sPW8bpFG+zSfgm/qsoeFbefnm/x8sDy4x81gty35QL p6UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791207012; x=1791811812; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/iCgxSwi3RoPvij3TTorlI9rkpxXQmuhLqHpTg4Dmx8=; b=NnyWtntRAklhlpm3s4IjtCH+a5OgOme1oVX148QDMVy7gAYRcNp44mkG5eet+9RQS2 Etpr5KRNpq562I7p+vgsZyti+TX8zGXYslrNT74xybmxUws4kXxZ3idugJbWq7wuydd8 bgzJfyn5aUEvTvL43y7k/DHNBjAXL94sIzJg8S36Vshi8j6FZB8EbE26jds7XbAlpIoN aX2tJmHn2aoKK3ZJ3XgdA4hNA3r7vwO3krXEe/lBnxWTvrcvVPR6j+FKeQRrwlUePWLj c67LJmwau3vBevzg76dwj5moz5kMSsZuAFBoGyCaxkf93nxgIAqMuKEoYXoCughe+D4k x83A== X-Gm-Message-State: AFuF++mLytASUMFHU48uq3j3nObTnMV1WiubYW7k7joCzHv8OQfydrSS jkl/e3J4OOdzYvd/o1cw+dgoO6Gs9Wp92d12Pg6uC4QTWQxLLfVWjUSgRNGm36LoUBYZpc2dJ+n 0q0yzGyGNofdpyMpKQ/0kiC1aMPQhDydioaSv9fdY9do7H8aMuPokWyz+YkFoItpPY3LKlw== X-Gm-Gg: AYBFou0Nj1pJQLXm/EuSP4PAvrKUCdKE6SICSZzyy1ixah7Ur+4M1uY9DmrYzMfyHYi yWEG26+5zKBE9g1e4gWGXn4PJCZ1wbkOw4YeSv9u1Q2WWpviZfUJVcS36jwxPC6F8taBUUvpwYm BcK5qoFux367nsqKq/5CmFgqrgWAl7H4BykT0e1ST4GCZSEGBKIOqBeCzI8aIdnfuyJsn/owW9N 8zQp8ZOH7pdvhmIoV9cPF4/ULlFYdyU0YHdhkucG0Qax/tA94IkoNrPSmlCKwMTELZ9V3yGgYlm 4AVYc+N7aDwQXuJDncFyFTfElkkscl1jS2gRy8P7DgMUreSurERWxb083YUk+K0yi6mzAMecmap XaPXyRlfk8+O8g4hDxA0mzMxiexDkTHnNYA== X-Received: by 2002:a05:620a:6f93:20b0:93e:78b7:fa4e with SMTP id af79cd13be357-93e78b808d5mr219631385a.37.1791207011812; Mon, 05 Oct 2026 06:30:11 -0700 (PDT) X-Received: by 2002:a05:620a:6f93:20b0:93e:78b7:fa4e with SMTP id af79cd13be357-93e78b808d5mr219626385a.37.1791207011240; Mon, 05 Oct 2026 06:30:11 -0700 (PDT) Message-ID: <63427797-e8ed-4345-b8c7-469d20865165@oss.qualcomm.com> Date: Mon, 5 Oct 2026 15:30:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 14/28] hw/ide: mark ICH9 and ide-hd/ide-cd as secure Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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 References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-15-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20260911143627.2743803-15-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: 6AwE9SMuN-idRV8NalRm4Un3_785EgPK X-Proofpoint-Spam-Info: AW1haW4tMjYxMDA1MDA1MiBTYWx0ZWRfX2lDSZULMT9bG y/rqoleAkABp1bvJH8PCBcNZ+0rOnphbR3+lTWfD9OKDhHDRwBEWCvvgVCEMR7jmPYSzrj8qj5k nPBbAXoJMNmi5f7vEErHwvP/X1R38lc= X-Authority-Analysis: v=2.4 cv=eZSo7LEH c=1 sm=1 tr=0 ts=6ac3a664 cx=c_pps a=50t2pK5VMbmlHzFWWp8p/g==:117 a=4s3hRJSeHn4rkQlkrse1kQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=20KFwNOVAAAA:8 a=6wYS7wvJjY0OpNKrp4sA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=IoWCM6iH3mJn3m4BftBB:22 X-Proofpoint-GUID: 6AwE9SMuN-idRV8NalRm4Un3_785EgPK X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDA1MDA1MiBTYWx0ZWRfX985dc7M+0zju PwTmHsk5OylfnhzXnO/k+7LCiKajBwH7AiIftc5teAd5qZr3Yu8IXSWXCSR/k6biOf+GUYlKkPH +NEmAhNPlk1d1Oxbq97cJAMu4QJfAmD07599ktoWvzJmhpk4JdrWcG9ZyfWiJR9L2RHIBFv2oJS 6TGh8UQrC3j5OuuUETR7m2FwCNplLCb/VZJb17xhejztR1TOKhV6WtNDoUVv8B4lezgQaQz3vCX jeBRlXsAlmbLP9YCl7lC99qskSufmZaczV9mrhCG11J9kaAWVIq1+KlcEWMfzVn4eoOz5sf1D8v A33izCju6JAcsO3Wu60pL93aPXOL9tGjgE6GWTzAqiiq4E9veeRjud2bV+Nh/ychsCkRO9nxWN7 bP2cJS4jCQslOMSr1cXvpGAnKGyBIn1xj1hk0J04CHBn2O+Mp8kmPZftnpF8cfRw+Ai8QVM/PzF oHcjbpXeKhIEKwNvbXA== 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-10-05_03,2026-10-05_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 impostorscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2610050052 X-purgate-ID: tlsNG-4011c0/1791207014-4ACDBCFC-A5112552/0/0 X-purgate-type: clean X-purgate-size: 984 On 11/9/26 16:36, Daniel P. Berrangé wrote: > 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(+) > @@ -252,6 +254,7 @@ static const TypeInfo ide_device_type_info = { > .parent = TYPE_DEVICE, > .instance_size = sizeof(IDEDevice), > .abstract = true, > + .secure = true, We shouldn't accept abstract secure device class IMO because it will be to easy to merge new devices that ended secure and we do not want to consider them. I'd go a step further and assert both can not be set together. > .class_size = sizeof(IDEDeviceClass), > .class_init = ide_device_class_init, > .instance_init = ide_dev_instance_init, From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:31:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:31:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440846.1658341 (Exim 4.92) (envelope-from ) id 1xDin1-0002Z8-IQ; Mon, 05 Oct 2026 13:31:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440846.1658341; Mon, 05 Oct 2026 13: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 1xDin1-0002Z1-FQ; Mon, 05 Oct 2026 13:31:35 +0000 Received: by outflank-mailman (input) for mailman id 1440846; Mon, 05 Oct 2026 13:31:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDimz-0002Yt-WA for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:31:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDimz-0090xp-AU for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:31:33 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a6ad-e002-0a2a0a5209dd-0a2a4502e05c-34 for ; Mon, 05 Oct 2026 15:31:33 +0200 Received: from [40.93.198.50] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a6b3-6ca4-0a2a45020019-285dc6322559-3 for ; Mon, 05 Oct 2026 15:31:33 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV3PR03MB7503.namprd03.prod.outlook.com (2603:10b6:408:196::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 13:31:29 +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.0472.016; Mon, 5 Oct 2026 13:31: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=WLuj9PQa4n2xeNVtuSzhIMyMsveZlt9Fh/9ljCfAuzL82cQ4ITU93rH26BATPn5/vdjjfgzhPTVCWezgVAU81EnalwiMxLjVWlXRYrbGsqxcU4jTPYtOXBXYa55IFhLaADCXhzrJnVWBW8ms5E6koB0p2VUbiL/jlJQW8Hw64cSAgO97OGbFEmhGx1sO2MpJvIRFKL/vBPkXDrnAO6t3naMaJt4jJ34wYbRYGf2MnjXnVCXkLj0lxTtjUm+OMXk7g5kHgChXjRrMGsmIxKA1kP85Sxy8u2rXqpZPvb5tkM1lnKm6VMZBchLWb42tPDxgdRwtKWkRV35+hlc1tAzLqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=j4m7g2htVqhurKMSya+Sem3hwmY/Ah9yJMVIyOGqAHE=; b=CN447TX4BtBtEe6xQlQ2B/I6xyZoUgxua1qiTZ5uI9AZLGq38CgQViyHPIMgUEJiEKI9bHAfI+2wErQ8ST9loW2zU+kkmKieZhwKL4tMVfcArg7aSGZ198JAqJurPeeDFjKr1JjAyyBmbcOMj4U4V//T1jIH50aPF+JwtmktpjqEOMkOLnjRE4ePWF0FwNhYtCVAqMNaYy3uJoiMcijOrXZksqVKrWwFhD4ra8g4JgkLCyRk0rkmSY7BF8U3pco3g/fSqO9NPJs0GaLQtS2+FHJGJnVEBnz9ROuz34+ylssAsyOL3X/XFk49E4pVVz9+RtYmYi0K1q8GVTMg/2unAQ== 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=j4m7g2htVqhurKMSya+Sem3hwmY/Ah9yJMVIyOGqAHE=; b=oKA4qN9QFv1hdYuTryczlwvLzFxDB63spMEyaKamqSw5YXakZkSyCquA9I8LyB0hb992J1F8CmUH2VTQUVJcXDELeX61LvwtR1T0E9ac0F2nd61Lv0eZYHdKV0L0N8VRCllAxl6CEQ8Zuqk6B71C9USvqnh8GAhHl8/4LBSC09o= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <73781201-dea9-4008-8568-06a7d5ac3f20@citrix.com> Date: Mon, 5 Oct 2026 14:31:25 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Nicola Vetrini Subject: Re: [PATCH 06/12] kexec: machine_reboot_kexec() doesn't return To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <26fe76ce-db8f-4641-aeea-667fb6ee3932@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: <26fe76ce-db8f-4641-aeea-667fb6ee3932@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0466.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1aa::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_|LV3PR03MB7503:EE_ X-MS-Office365-Filtering-Correlation-Id: 1852a8b9-00e2-4c2e-c256-08df22e4f61f 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|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: jb0kuX9xV7XxYCXpIuxOsLuitBQq94d1eDLZpSfR+WIYyFQ3hAHwUaq1M9kzoa9rSHQtn2F7YNx3vdaClfAXgVJ3iBnTxDn3+/jMSvPz0C92svLdVP8JR5Nt8VUaWL3zeDwzFgiz1Oh/1Vcz50Dy0o3OljF18MhiK86ym+QlSfiunte/4XXzCrHNegeBZCx7QPrJeeJsMOPj+dGtsONQ7g/z0MX/HptmX63923Z0KDDtER1uX8OTd4gCSI8KbE+3f0YQeMZQYFz6i4JwWf1dlEZSISsXlpWQYnJka4VlBI4PCLwa6UyiyZLvwRusE4Y0VsWxo6QqXxwJYuu/kLLWT0GdaaM8OJ7vtVWzidJFdq4+vmtdtA/1nLPZbV1aCkinsDteKohN3Y6Kl4cvZ+tS20Qlg2tGo+ZgohDBXgD4Wn9g9qh3Rii9jg9t3uubqV+0XYy8qmP3pz0aO/FWWiW1T0L9txXPvY9FBdvODqDiJ4MJvmeraSu8XZiArI9YXifstTULWbak06vFHZS6G4x8ybZjQ9cyStYlynaEhA3rQ01w8L5456jnBPNMPw7bPTZoA/hd96NG4hl1PyN38+CitHwwmUV3w9Xb+UXYK17EIb9oBdOhcyFXzk1/m/WUukepthrpXrN+4Zjb7Q7SuokAVn4y5Z8qaCFgqsHcg6rEUh4= 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)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VnBXWkVTakdxdUNYRGhsbk13bG5HNFhvZ1VJU0l0MTI3NW9pNFNZRkJSRWJ4?= =?utf-8?B?azZlaU9pNmFXYVI4dGExOVMwQXFab3pwZFIrdHVZaHdBRzNZb2JqMWhURlFr?= =?utf-8?B?VzVVNGkyS1B1WkF6T0dmRVo2R1lHeVlrT0dVMDUxQVNZZSs0ckJDUmZDTS8v?= =?utf-8?B?WTY3TmlBSW9NWFlha3ZHUW1DOWF4VVBrR2J2bG5oY1ZYUEhKRUExNG56MENG?= =?utf-8?B?MTZma1hKRHpGdFFuWU1VdlN2K21ia3gvZFN4S053Zi96VmR2ZldSNzRjUGZi?= =?utf-8?B?K0hCRWp1MUw0NlQ3cER4L2JLQyswZ0FhRVJ4aDZNcUhsWHFKbnQvRTZGQnI0?= =?utf-8?B?UE1ic0cyWERlMXZKQld5UVRtRHBxSjhxQ29naG1QaWlGcEthME9EaHQ0TCt0?= =?utf-8?B?OUlYK1JVVDZuY2IrY2F0ME9mRnRsaERJa2JqS1RwVTZRamRmNlM1WW5PT2Jy?= =?utf-8?B?U3lEY1BHWmo2dnU3MlJnUlRDeE5xVVRkNmxNM0ZZdjRINElZMUFwVHpXQ2FJ?= =?utf-8?B?SGp0V3h6T0xwTXovK1JUMlBpY1EvT3pKZFV6NkJaU2E1SUgrUjFPM0g4cEx2?= =?utf-8?B?eC90eW1GWXdTdWlDbE9vemo2d0VJczJWa2Joc1hYRkozQTU5aWRVZXp3U1lE?= =?utf-8?B?SjF5T1hkUkVYYUsrUHh0cWplNXpmU2crQk1QbmN5Y3owZmZybFhJWGp1THZ1?= =?utf-8?B?RmkwU2JNcFJJbmdzR0FYV2JERnRWK00zaVJvazhsTGNqRGFnWHROeTBmaXNT?= =?utf-8?B?dk1Ta29xajdaN1E5TmUxNjRjNDBsd01WOGFkcWd1MEFVbW9aZGVaUzdhNG1I?= =?utf-8?B?QmpZdjYxMXlBREFlSGtEckFnQzNDRGU4T20zb3d2MGhxSWJ1NW8vM0xNQ2x3?= =?utf-8?B?T3p1WWE0cGJKZEFCQklyWGlud0ltcTVKTkMxWTc1aHIwK1lmQmVvdXk2VUhr?= =?utf-8?B?ZzdNcVNCajhzOEdLZHk4QjdBdzJwRmJvSm4wMnlEZ1hDdzZLSEFMWWNIcjVV?= =?utf-8?B?Y2RVOWR4NkRpOTVmMlNMWVN2eUl2VWc3WGU4LzA3QTdWcTNqVUFhUjYzQkpY?= =?utf-8?B?MUYxblVaYnRNR0ZXYmgvVXRacnBCVTl1Tk11OVdhdXlDQXU5UFlza1hqeldn?= =?utf-8?B?LzM0VHh3K3RiSDZ4Y2pQaytWQ3NwRDJiVHE1dXdYMzViZ3ZlUDVrZkgxbkww?= =?utf-8?B?SDY2ck5MRjdOaTZnMytQVmU3MzhjMzlnbCt3cTJDbUpaazBDTWxrNG9kMFh5?= =?utf-8?B?SHBGU2VVRjkwc25Od0NGTnd0L01rTEJBUWJndWJ5NWJuWHNaL3pGMUh6Vk4r?= =?utf-8?B?VzZlKzBnNlNRMmJiRjkyZHJ1VTNjYlpPVTJjdXlXekUxQW1jN3U0UXRTNW9s?= =?utf-8?B?b1lDNjVsbngwaEViOHdGYkZOM3FmYXhUWEhaVWY4blloclNiZnRBZ3V5R3RF?= =?utf-8?B?UU1TbkNQRGhyYTdyTFg5ampTMzdCZjkyenZmbVFoR21qSHVYTURMUGF4eThP?= =?utf-8?B?VVpZTENKUTVWRFJoVVZZMkZlaFdjV211S0NoOG45UDZXektxOWZoUHhwMVlq?= =?utf-8?B?a1l0blQzdDNDeWNJSWFhbDhBbFV0NHRYUFdVOWxtWnhrTkpHd0UvL21EUGRT?= =?utf-8?B?SWsrSTQ5OUFOMy9KMzNPbVdHODdqS0xRWFlKUUgvYTliT3ZnOHgxbTdZU0hS?= =?utf-8?B?NlhEaHNRaWFZNUtUVUx1UjZwRFNhNlg1ZjJhNVhwcVRvTDkwR1I5N2NWaWRX?= =?utf-8?B?UnNQUko2Q1MxOThDNi9ReG9kNll2aklBVHZnSFFNOWhTRWVQUUtrZjlBdEJU?= =?utf-8?B?Nk1LbFNzenkxNWpxalZsVXkxUG5JcDdndExTOGpDNjN1S0FVYkpldlRySUNl?= =?utf-8?B?QnpXU01JZjBCaGVLSHlXVWRnbVZaMnU4VUtLa1ZDYUdoSGZveXlud1ppL3Rr?= =?utf-8?B?UDZzM2VLWnA2WGhac1dYVzFsWWxoZzQ4d0tBZ0tFU1diSE0rQzFoanJObjZa?= =?utf-8?B?ZFJSbUxWUHdXWHl4UkkvS1lvTE41SHNNTnpad0FQQXk0NFJ1TDRJWGRTR1Zt?= =?utf-8?B?RWhpSTFuMEJjL2ZiYlRJWjkzWC91eGdLSVNGTUx1SlJmWG5udi9KVDBkQ1B5?= =?utf-8?B?ZmdJSUJzT1hWUkVkK3gwSkZzSkdGdkgyb3E4enJNTHQ4V2ZpMnpCUllpYi9C?= =?utf-8?B?S1JVWEFnb2Z0TGp1VFFwS3MrTEd6aWNEMGFJTk9CNkFXRzBhMGtHYUF2RVNX?= =?utf-8?B?QXBuNWE2RkZKd1UvVjU5SU9QZ28xOUlkU0w3NkZYUDB1OUpMcjJTVWRaYzFS?= =?utf-8?B?ZDkyOWdsNlB4QWNNTVJyZkFsb1czSElFWS9Bd2RCM3JmMGQvbmRkZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1852a8b9-00e2-4c2e-c256-08df22e4f61f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 13:31:28.8923 (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: AUz43XiLixP1xzOEageAv+mhg56g/DBG+klYqBuzMrsLyviqJxy0OJk4FDg62xF26Zl3mZ2G6o1p5yl3r0qBfb17mkqlwfrOBKVSlLy7Vyk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7503 X-purgate-ID: tlsNG-720697/1791207093-303C42AC-07650CAF/10/78276251493 X-purgate-type: spam X-purgate-size: 307 On 28/08/2026 8:02 am, Jan Beulich wrote: > Mark it as such, and then remove the code following at its sole call site, > for Eclair flagging that as a Misra rule 2.1 (unreachable code) violation. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:35:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:35:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440852.1658351 (Exim 4.92) (envelope-from ) id 1xDiqK-0003DT-1V; Mon, 05 Oct 2026 13:35:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440852.1658351; Mon, 05 Oct 2026 13:35: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 1xDiqJ-0003DM-Tk; Mon, 05 Oct 2026 13:34:59 +0000 Received: by outflank-mailman (input) for mailman id 1440852; Mon, 05 Oct 2026 13:34:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiqI-0003DG-TX for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:34:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDiqI-002cuw-A7 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:34:58 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a780-2eae-0a2a0a5409dd-0a2a4505975e-12 for ; Mon, 05 Oct 2026 15:34:58 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a780-4cb1-0a2a45050019-cddcb483bc36-3 for ; Mon, 05 Oct 2026 15:34:58 +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 695CFUJZ2366423 for ; Mon, 5 Oct 2026 13:34:56 GMT Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4h49tvrmwy-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 05 Oct 2026 13:34:55 +0000 (GMT) Received: by mail-vs1-f70.google.com with SMTP id ada2fe7eead31-7c07f9547d9so401795137.3 for ; Mon, 05 Oct 2026 06:34:55 -0700 (PDT) Received: from [192.168.69.225] (pmd666.hd.free.fr. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48c6773663dsm76912f8f.4.2026.10.05.06.34.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 06:34: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=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:References:Cc:To:Content-Language: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= LZ4EJ7lmFpUwukMRrcGizDRsY8ibjTYc8PvBHvmSrfw=; b=CWQVOJdDOTDPbH1O NfS9xAxzkpQCdSPPWEAKqjJ+nmQuGnkVpn5Bsynp24goBkSvPYxdVo/R+VFxnxn3 aCj0S9Z1pgbzBwyAo9eKwPSSP9pnb1vcS2TssOYQOeqor1PFgl9QQxQFIWFI+3xl lfe79WT/XIu8gZ8Bl0E/xoWedZMtuBnaXxeaCKjkvZEmebGQJWVmrC1lvMPxgOvY QP3M4CZVcyN3HhF6UTwTuXxMxxqdlpKPUyg2IwaJStcRb695yBuKn+yjAHqgAZOA j+DOAHHxJZxn03PWrRi3qpJ+KvvHAEFfYSztq9B5k6KKngyanNW8KRoWT+KQYzOz x3epNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1791207295; x=1791812095; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=LZ4EJ7lmFpUwukMRrcGizDRsY8ibjTYc8PvBHvmSrfw=; b=cgrL202gNmDO2l9BCncsrxxQYBvtT2hLY7o+VYnF/M7/xR8Rl33xLY4KdVwG3rKlEw FBTPDY0TxSB/oZaJAIgwoiEjQ/RRdgmtvI9l39pwNpJTtHMK0Id7hnmWWNPZZs3YA/Ko ASxZs+uyz90vE987J4FgKDz7SB7xDsT/6ltSXeuUqzoUQW1UWSnpyk/zQrw1oDYRMecu 9Kb+72b6PLjON2SqIlPBobSIl8iDkoVtiJkepBSox8avtjET/n71j8KRsFvVuIu2697i ARdhMjNmoJJ8ZefkG2G30hOiQ0qDLWTBVO9TW62hiHa9KqUB+Xx9iXnjGMBcvpQvk0lT AsmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791207295; x=1791812095; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LZ4EJ7lmFpUwukMRrcGizDRsY8ibjTYc8PvBHvmSrfw=; b=Sw21Ryv7N96GRa8MACMjGrMkYmKZcI5hbWggpnKzi6VEUsKIL6UCIqKtL1Hiu3i7Dt yt8NeQW+mQBX02JaOpsfs7HQuOxhMfZotNvlP0PmoboIpxXPbTYycPIdsOekAmQjyjSw lCaJAzrRwxT9wCFsj9oS1LhPdiZ3A9YmKfpEHA+i2NY0vZn/Q1gHmSnJ1fXpEWNQ9lEB lyfdITgHkbwGPcjJ4P5PKyuuHy+IYO8cLvwN+19dzg+hRc9hfADSEDBqAcUHaKt2fgAf +xG5xwmIa7+alCG0QUTfKXtwIJCBlC89onhQTvJlf50RcBzY1afxx0m+vr6tUQIDinIu oKWA== X-Forwarded-Encrypted: i=1; AKwUvBxlLgs6ZnSFxkc68T/W6E8+XjhDEQKB3YkKaCJMvywDOZO1MWo5yZZw6oBrxaSpo3cSCJfW+8uo2VQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYKBxePF3/jh1ES1bjuTxOJ5rIWK/XAtplWFJ4vyUbMTHB932e6j nEfrbqm7CHk7pnNp23H8QeCeF0f0I86M7aYZtIstL0ZmV+3pSbZcBUshm74W/W4QkIM5fHWwC4j C+B2cuR644tkjS4IyO9W7RkvsLzELZ+P31K8HBq2dtqTW+bPd+TlzY4/Kmz5ZbmsdSNLr7EB4n0 wxot12 X-Gm-Gg: AYBFou0UVvtSDe/1tg7/Oo+28WPAgLVzCS5ZwjT5rJlTkb7hWTMEgfWce18tD8eXxd+ T+aROhcHCC9qU69vNAa+NqTgRquF/GrBzs03O3ehnSVfzDNzaoCwrDyuTXVT2yw0o7Tm8VIYsDO +dbX9RS2Cz7K2sT3QIxuz90t6kkfxyzyP9jVj3TFNe5hoVMVLbVGmnO0uyTvVbB/aiCrjoXmDd2 M9fc9r9/RkoZYwHBjo701FkuIRrPJr+dOUj6ZH9Ze2OxHcOJl2gri1w3Y4PsInsryqTAohq0H16 Tj9HFev/HS1xgGl5ktdom6QU/QDkKbZ4skLb/7BcRTj/CZruObkKzEdFxNFjmme/uY6XJiqOp2x ELJf/gvZEYCThrnnhcvOBHLni73wvHRAEpQ== X-Received: by 2002:a05:6102:91b:b0:7c3:881f:b620 with SMTP id ada2fe7eead31-7c3881ff813mr919263137.21.1791207294828; Mon, 05 Oct 2026 06:34:54 -0700 (PDT) X-Received: by 2002:a05:6102:91b:b0:7c3:881f:b620 with SMTP id ada2fe7eead31-7c3881ff813mr919248137.21.1791207294089; Mon, 05 Oct 2026 06:34:54 -0700 (PDT) Message-ID: <5e64e1e0-d733-4f8e-98b4-8e6b554101b2@oss.qualcomm.com> Date: Mon, 5 Oct 2026 15:34:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-2-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=aN9lOr9m c=1 sm=1 tr=0 ts=6ac3a77f cx=c_pps a=N1BjEkVkxJi3uNfLdpvX3g==:117 a=4s3hRJSeHn4rkQlkrse1kQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=ID6ng7r3AAAA:8 a=20KFwNOVAAAA:8 a=CtHk5BvZtinuqIhR7bsA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=crWF4MFLhNY0qMRaF8an:22 a=AkheI1RvQwOzcTXhi5f4:22 X-Proofpoint-GUID: wJNUQA_ZuX9-U-eRvN4Gh0FWOJMFy4v1 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDA1MDA1MyBTYWx0ZWRfX1rXnyRWVqVMq FRLRTD38rJln3dFPLf4f1O+VzI/5TlJVmLvlORM135ig7Rz55XdPPN35/rFZzR/RJFyX/JFLaN8 jQp829KplJjSi059+ZEPMCVQLlJaiS8PiEmQwVaiXjKnEtU9Qdnbet3BElivPhuwYUdbv+YCoUp kETZdlhc4oux16hEVeBOMjVIkt1sxUXA0Vguw0YwjfFzGW0p/J2aER+0QveG+wZkCtkVxUqf3Of Wh2a7Ozrz9msTktOOKag7wJxUy/Dm8CJjUmjKnE69GM5COko8G9bbTiyr0KU+L8uQdQR4ef2eBE qExiFJJT+P4n/HeAPKBw2JXHm0D0yxlPfqumJLjKSdTYKMK+YTehWtT/iEMeVHl+9xaylJZm32f 8qNqoj67Nh0+pDaBnaUKqzrQFtZ7wCGIqgGPm7Tbu6kOh3W/F8TxDJbaXu9/xOFlmVr7enkMKTT NsZIlKY/0pyte3OB4dA== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDA1MDA1MyBTYWx0ZWRfX6iq0zio3q/Yt IGjjMOSdB09iM9wGbbrQXfgsK+ImRLXamGolkGPk1wKbneOOFctBV91Lbd5+C+0XjiNeZi8Ieky HK7mLf688O0Ji+2Q+eoZelzJ+gF/WI4= X-Proofpoint-ORIG-GUID: wJNUQA_ZuX9-U-eRvN4Gh0FWOJMFy4v1 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-10-05_03,2026-10-05_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 suspectscore=0 clxscore=1015 spamscore=0 phishscore=0 malwarescore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2610050053 X-purgate-ID: tlsNG-c201ff/1791207298-F7CB82A1-EEE0E594/0/0 X-purgate-type: clean X-purgate-size: 2184 On 5/10/26 15:23, Daniel P. Berrangé wrote: > On Mon, Oct 05, 2026 at 03:06:08PM +0200, Philippe Mathieu-Daudé wrote: >> Hi, >> >> On 11/9/26 16:36, Daniel P. Berrangé wrote: >>> 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(-) >> >> This patch should be split per machine / area of maintenance, >> so maintainers can officially Ack their commitment to security >> boundary for their machine. >> >> I'm not sure LoongArch / RISCV / PPC are. If this was previously >> discussed, then pointer to the public discussions should be listed >> in the patch description. > > Those are explicitly documented here: > > https://www.qemu.org/docs/master/system/security.html#virtualization-use-case > > so this patch is just encoding what has already been defined. I probably missed when this was accepted, we are good then! That said, 1/ Nitro Enclave are missing and 2/ this series organization is not easy to follow to me: I'd rather a per-machine approach, with a 'info qom-tree' output justifying the devices, then finish the series with busses-based devices expected to be secure. I dont quite follow this approach. I'm not asking to redo the series since it is already reviewed. From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:35:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:35:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440853.1658359 (Exim 4.92) (envelope-from ) id 1xDiqQ-0003RQ-7s; Mon, 05 Oct 2026 13:35:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440853.1658359; Mon, 05 Oct 2026 13: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 1xDiqQ-0003RH-3w; Mon, 05 Oct 2026 13:35:06 +0000 Received: by outflank-mailman (input) for mailman id 1440853; Mon, 05 Oct 2026 13:35:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiqP-0003Ql-97 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:35:05 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xDiqN-00G3Yd-1L; Mon, 05 Oct 2026 13:35:03 +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 1xDiqM-001Zp3-0K; Mon, 05 Oct 2026 13:35: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=96lMZoBXp+xh8wi96UjJ9BDjNr6V4uDkQTBLpJYFA3k=; b=ZDQVg+LuB4CWxxeDIBxu54oT22 sbKQM3HnoYc9m6LivnlwnY7jRWApvyKIb5+n61BDZ6DI93OQ2GwoUlH1yJsDx0vZE+vDt38jadh9U rgETE3XAZDtmIsANpBv4LFc5Qg8O7Hmr3nwWv2oqz0oMviORMuJ8S6dJ7+htaY1+mOYs=; Date: Mon, 5 Oct 2026 15:34:55 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Weiqi Wang Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang Subject: Re: [RFC PATCH] xen/pdx: reject regions crossing a lookup table index Message-ID: References: <20261004190409.29276-1-coolhaoyt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261004190409.29276-1-coolhaoyt@gmail.com> On Sun, Oct 04, 2026 at 08:04:09PM +0100, Weiqi Wang wrote: > From: Weiqi Wang > > pdx_is_region_compressible() only looks up the table entry of the first > page, and checks the region against [pfn_base, pfn_base + > pdx_region_size). pfn_base need not be aligned to the table index > granularity, so that window can extend into the next index, which belongs > to a different range with a different offset. A region whose tail lies > there is reported compressible, yet its last page on its own is not, and can there be multiple pages that overlap into the next region? Using "its last page on its own is not" makes it look it's only a single page whose translation is wrong. > translates through the wrong offset. > > Also require the first and last page of the region to use the same table > index. The "Also" at the start of the sentence seems misplaced to me, I would rather start the sentence with "Require ..." > This can be reached from the coverage check in srat_parse_regions() when an > e820 RAM range is not covered by the SRAT ranges, which is the case that > check is meant to catch. > > Found with the ESBMC bounded model checker. The counterexample was > confirmed by running it natively against the unmodified code. "The counterexample" is not part of the commit log, so it feel odd to name it here, as people going through the commit history won't see it. > > Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") > Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation > Signed-off-by: Weiqi Wang > --- > > Notes: > RFC because this was discussed when the offset compression was reviewed. > In the v2 thread [1] Jan asked whether pdx_is_region_compressible() is > correct when a region crosses a lookup table slot boundary. The thread > concluded it was not an issue, on the basis that pages contiguous in MFN > space are also contiguous in PDX space. The reproducer below is a case > where that does not hold for the code as merged: the region is reported > compressible, its last page on its own is not, and that page round-trips > to a different PFN. > > The ranges are as srat_parse_regions() would see them. The RAM range is > not covered by either SRAT range, which is the situation the coverage > check in srat_parse_regions() is meant to detect. Built from > tools/tests/pdx like test-pdx-offset, on staging (e4da182973) plus patch > "xen/pdx: fix merging of a range contained in the previous one": > > region [0x75757ffef9, 0x8122007e00) compressible: 1 > last page compressible: 0 > last page: pfn 0x8122007dff -> pdx 0x2122047dff -> pfn 0x2d7ee07dff > > With this patch the region is reported not compressible, and > srat_parse_regions() disables compression. > > 8<---------------------------------------------------------------------- > /* Build like test-pdx-offset, e.g. from tools/tests/pdx: > * gcc -D__XEN_TOOLS__ -DCONFIG_PDX_OFFSET_COMPRESSION \ > * -I../../include -o repro-window repro-window.c > * (after generating pdx.h as the Makefile does). */ > #include "harness.h" > #include "../../xen/common/pdx.c" > > int main(void) > { > /* Two SRAT-like ranges, in PFNs. */ > pfn_pdx_add_region(pfn_to_paddr(0xdffffe0000UL), > pfn_to_paddr(0xe000000000UL - 0xdffffe0000UL)); > pfn_pdx_add_region(pfn_to_paddr(0xc5cde0000UL), > pfn_to_paddr(0x4cd7000000UL - 0xc5cde0000UL)); > if ( !pfn_pdx_compression_setup(0) ) > return puts("compression not enabled"), EXIT_FAILURE; > > /* A RAM range not covered by either, as srat_parse_regions() checks. */ > unsigned long s = 0x75757ffef9UL, e = 0x8122007e00UL; > > printf("region [%#lx, %#lx) compressible: %d\n", s, e, > pdx_is_region_compressible(pfn_to_paddr(s), e - s)); > printf("last page compressible: %d\n", > pdx_is_region_compressible(pfn_to_paddr(e - 1), 1)); > printf("last page: pfn %#lx -> pdx %#lx -> pfn %#lx\n", > e - 1, pfn_to_pdx(e - 1), pdx_to_pfn(pfn_to_pdx(e - 1))); > > return pdx_is_region_compressible(pfn_to_paddr(s), e - s) && > pdx_to_pfn(pfn_to_pdx(e - 1)) != e - 1 ? EXIT_FAILURE : EXIT_SUCCESS; I think we want this testing added to test-pdx.c, however it will require some expansion so that test cases can also provide an array of memory regions to use with pdx_is_region_compressible() different from the regions to be compressed. > } > 8<---------------------------------------------------------------------- > > Other callers that rely on the same answer are mem_hotadd_check() and > the EFI ram_range_valid() check. I have not run those paths. > > One behavioural change to check: with npages == 0 the new condition > compares against pfn - 1. The callers I looked at never pass 0. > > Model checking (ESBMC, 2 SRAT ranges and 2 e820 RAM ranges, all free > below 2^40 PFNs, the srat_parse_regions() coverage check modelled) finds > no accepted RAM page that fails to round-trip with both patches applied. > It also finds no layout where the coverage check now rejects what setup > accepted, with RAM equal to the SRAT ranges. This is bounded to 2 ranges. > > The existing tests in tools/tests/pdx pass in both mask and offset mode. > > I have not reproduced this in a boot: the layout needs RAM near 2^51 > bytes, which I could not set up under QEMU. > > [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg194095.html > > xen/common/pdx.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/xen/common/pdx.c b/xen/common/pdx.c > index 23655ef3bd..52928faa15 100644 > --- a/xen/common/pdx.c > +++ b/xen/common/pdx.c > @@ -324,7 +324,8 @@ bool pdx_is_region_compressible(paddr_t base, unsigned long npages) > unsigned long pfn_base = pfn_bases[PFN_TBL_IDX(pfn)]; > > return pfn >= pfn_base && > - pfn + npages <= pfn_base + pdx_region_size; > + pfn + npages <= pfn_base + pdx_region_size && > + PFN_TBL_IDX(pfn) == PFN_TBL_IDX(pfn + npages - 1); The fix itself LGTM. Thanks for chasing this. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:35:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:35:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440862.1658369 (Exim 4.92) (envelope-from ) id 1xDir3-000481-Iy; Mon, 05 Oct 2026 13:35:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440862.1658369; Mon, 05 Oct 2026 13:35: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 1xDir3-00047u-Eq; Mon, 05 Oct 2026 13:35:45 +0000 Received: by outflank-mailman (input) for mailman id 1440862; Mon, 05 Oct 2026 13:35:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDir1-00047a-NT for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:35:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDir1-006GCn-4D for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:35:43 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a7ad-8faa-0a2a0a5109dd-0a2a450aa2ee-2 for ; Mon, 05 Oct 2026 15:35:42 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a7ad-f2d2-0a2a450a0019-aa0a857c6cd7-3 for ; Mon, 05 Oct 2026 15:35:42 +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-yYWFsrshO_qvQ2caxQ9Wuw-1; Mon, 05 Oct 2026 09:35:36 -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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E20CD18088B8; Mon, 5 Oct 2026 13:35:33 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 93F431800446; Mon, 5 Oct 2026 13:35: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: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=1791207341; 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=edsWgcTvJSh2xQnmTdTIDoWg/t2feMO6k0rNtRTjdUU=; b=Ex/4p4MS0Ya+Yljj2+uExBSF0yixVzyfO6be/EAoHVH/se6I6nceAGNeMWBg+oTkYW3RD3 JcXx1F9lQYkHM22aYMTxwsRkcTYyNcQ3aVoJVUP6nSLOYheQQEds56zJFlJqA2t+CmR3+7 TQW+jgGRlvVDC2u3Uatxqb23NMxMfB4= X-MC-Unique: yYWFsrshO_qvQ2caxQ9Wuw-1 X-Mimecast-MFC-AGG-ID: yYWFsrshO_qvQ2caxQ9Wuw_1791207334 Date: Mon, 5 Oct 2026 14:35:28 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, 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 14/28] hw/ide: mark ICH9 and ide-hd/ide-cd as secure Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-15-berrange@redhat.com> <63427797-e8ed-4345-b8c7-469d20865165@oss.qualcomm.com> MIME-Version: 1.0 In-Reply-To: <63427797-e8ed-4345-b8c7-469d20865165@oss.qualcomm.com> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: k9GDF-P78jnHusmzDIiouAy6jsYCQmnElpe997TZyVc_1791207334 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1791207342-50ACCCFC-D46AB456/0/0 X-purgate-type: clean X-purgate-size: 2025 On Mon, Oct 05, 2026 at 03:30:09PM +0200, Philippe Mathieu-Daudé wrote: > On 11/9/26 16:36, Daniel P. Berrangé wrote: > > 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(+) > > > > @@ -252,6 +254,7 @@ static const TypeInfo ide_device_type_info = { > > .parent = TYPE_DEVICE, > > .instance_size = sizeof(IDEDevice), > > .abstract = true, > > + .secure = true, > > We shouldn't accept abstract secure device class IMO because it > will be to easy to merge new devices that ended secure and we do > not want to consider them. I'd go a step further and assert both > can not be set together. Setting 'secure' in a parent device does NOT imply that all children have the same, only the reverse. ie, if a leaf device is secure, then by definition all its parents must be secure. This series only intended to mark leaf devices as secure, but a followup series will explicitly mark the whole parent chain as secure too, and also validate that chain in tests. Another followup is to require non-user creatable implied devices as secure. ie if a machine creates devices X, Y & Z, then if that machine is secure, then X, Y & Z must be considered secure too. Note, this would be just for those implied when "-nodefaults" is given. > > > .class_size = sizeof(IDEDeviceClass), > > .class_init = ide_device_class_init, > > .instance_init = ide_dev_instance_init, > 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 Mon Oct 05 13:37:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:37:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440865.1658376 (Exim 4.92) (envelope-from ) id 1xDisI-0004fZ-Rd; Mon, 05 Oct 2026 13:37:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440865.1658376; Mon, 05 Oct 2026 13:37: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 1xDisI-0004fS-Oi; Mon, 05 Oct 2026 13:37:02 +0000 Received: by outflank-mailman (input) for mailman id 1440865; Mon, 05 Oct 2026 13:37:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDisH-0004fI-Ip for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:37:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDisG-006Gl3-SC for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:37:00 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a7f5-8faa-0a2a0a5109dd-0a2a4501cff4-12 for ; Mon, 05 Oct 2026 15:37:00 +0200 Received: from [40.93.194.39] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a7fa-5984-0a2a45010019-285dc227cea9-3 for ; Mon, 05 Oct 2026 15:37:00 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by CH3PR12MB9342.namprd12.prod.outlook.com (2603:10b6:610:1cb::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.19; Mon, 5 Oct 2026 13:35:22 +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.0472.016; Mon, 5 Oct 2026 13:35: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=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=KAe0uWBXWIt2dBMt+eRXoaX12QlhsN6H/gVU0mkL7Lgx60hiRqvVog6fAdUYwXVE2/IhRJqzGWcCrQySRBc1DKYC9AgNRphewO2tvKZr4g1zvN4p6VO07yirDMre7aOBrtUw1W78MPNfJjOS5jVonWhi3MpNHC712iFvyFHHZ/+yTAsBez2Eq33nxkaC56EFcdwYD8pt37sjqeeLNJQ45NGbSHf8Bnj6tZ1/xI8RuVF4SThK1oQ+oyBnqiUIO6QnycjxccFlIm8iNB5qUs7hCwxATcKkO4PVOrasJdRulzEYiqs3IvuAQr0QBRCkfY8yef5msb55NgrmUCcj0a4y3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ED5LdYnpf0elcnvO8paeZu7OmqB67hI5teJUGQ0NAjc=; b=qHsHKm1vVtuIbfWTBI7mnO7gikGxQvB+0bIWmXf9GaJ2XY85Vj+S/BrPECKLCkZddAFnSuALYDN5mjUqAxBkAGDjmJEuhJ4Y8T5D4f5TilRutK9iqgmuUFIDoL91upaZ9/BlgU16mwv65g87z6rmcgZd3CfqXcNGSUe1QNpyJePpAPcQ1ZQkIPq7pqYpK+tT/9qSUIFT03YCDt24cxBLB3TG9TY3KB2bUoX5hriqv9rV25ljz/I+qT6DIrJBDkET7KS/qSSKU1t8cBhEOGZ8ElvaiJf+F298blzCWT3zn7mNI0Xvut1o9b8A1bLroYp07eV3tiEGcTmPaFHu5oDJFg== 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=ED5LdYnpf0elcnvO8paeZu7OmqB67hI5teJUGQ0NAjc=; b=jrUT504I6Fr5/4vB6QsPAHScaYjvQbJQsFhe06DE1m3mxqcZEHzZdREAFBBo2K2ucVatJjO7WuSLCxVjAiE5DIwq7c+TMqM0EPxZ/FUzyVUbYqNVj7yuefeAya7Z8CW1HSzdGsgZmBsPe7ms0PvVWSFoQRkknkQAzSoVrfv4lpQ= 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, 05 Oct 2026 15:35:19 +0200 Message-Id: To: =?utf-8?q?Gabriel_Quint=C3=A1ns_Souto?= , Cc: , , , Subject: Re: [PATCH v1] xen/arm: validate non-common page-table ranges From: "Alejandro Vallejo" X-Mailer: aerc 0.17.0 References: <20261002191418.287819-1-gabi.qs.mail@gmail.com> In-Reply-To: <20261002191418.287819-1-gabi.qs.mail@gmail.com> X-ClientProxiedBy: MA2P292CA0003.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:1::20) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|CH3PR12MB9342:EE_ X-MS-Office365-Filtering-Correlation-Id: c940b15a-1695-40f3-30e5-08df22e5812c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|10067099003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: KnRd7mfwuEztIcqlgVG1NBqFYztHeU7CJSeTe3HBdLq5RJ4D7S20I3DhAxoSoHMb2CtZ1aaOo4brb3CyR3ZAglmfHXDmsoVaQ1puO3fb3p5vfEsUlh4SWnESdGPAKCcWYrHlWZDnJhoRZg/YM3hjDQ7aPhkrgiJ5K13lrI9Xf0LF8auLeydMKwAWVfnpD0g6aIbulb2aGGZTz8mQevOEdShyhe8MNSXFyFS2eDd6+OpuEUv6ybcT0YROBwZftjMIFlerS4Lo/3hz/OafI/p7ilerHxFPx9+MHO3ab+peajO7qjrMLcqnM7OCAB6KPwOiFon+ax6IOUleDEUSQH/vU1EBRQorNCADpuarXLHPGSl4Uk4Q2cPuNB/+ph4/2RGQq0dQOtXOah6bXyBxdjM3cYL8Um8CmEtkghChXAXHVjhYS3lafNX4AotqbFvSbN+tadx0J14BhvIPUPubQZp76X9eA3Qhg+kOvWyLF1Gmb733nRPj1xie8wQU32ZhcLbRXGuu0cL1BIgcPC7QqOqkU7NXuB/8ps4rLURSMP7UzAhtQlyecl/47RpARBYsTxmV8fmFLeB62fzUjS3EFOTihYkGm0iEmyVgQZz36NcXwI9AJMejCM3OFqIFJzotw4OV41egor9TiQqKkEg1tMt7/gsGpzL9nfBZRwSNUrFgqWo= 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)(23010399003)(366016)(1800799024)(376014)(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?VytMeHZEdlNHOHRCLytpemZ5aGlNUEdLWDlnVnNkVnJCcVBlZlJKZTNBdlda?= =?utf-8?B?bXZSMU9SaytPWWtWaXdEQ3Q4VDZhMEVLajZPNEtyNXptaVdNTDVhL2xHSDJP?= =?utf-8?B?bGhxWDUzZlI1Y0NhamE0aGFMZ0JrZHo1amxtLzlsR0JpZDYvaW5MdFBiSkJL?= =?utf-8?B?OSt4bHlSK0tGcjJBTXV1TGErNlBQZVQ5WnBVb0hOTkllTEticXYyeXVOSWxu?= =?utf-8?B?K2NBMVI1VVpIMTNpVDNTVDdnVVFUd3hPeEtJV3p1UG9pR2c0T2tHS0cvU1d3?= =?utf-8?B?cE5aRkNOcmlxZlRXSWIzYTB1YmNtd1ljbGhxT2xWaE1jeURZaUdRbjZlc3B4?= =?utf-8?B?WU5qMWNKUXA4WUdoaVBLU1p0OU10VW5NTzZjYTlnK1BGcDFsNEF4SkJxTzNJ?= =?utf-8?B?T0x6Y2NoajdwU094NWdhNGNZdDRVcmFabEk5ajFyZ2V3YWFZTC9WbFJyTzRh?= =?utf-8?B?TWdGTHcySzhMSWFDL3lFakdWOHNOdERnNytKSUdST2hUcjRGcWpDRk1zTXNR?= =?utf-8?B?WTc2ZytEMG1VZm5FNk5BTDhOdzZIbkxkYjBxOFN3ZmhGTzc1YnY1VzRWUS9n?= =?utf-8?B?RENzalJuWTNwTDhtMkFRd21oOEg0RERlSUdWc1Juazczdk9QVmFtVEJyTUs0?= =?utf-8?B?akp4YjJac0I2WHVtUjkvL09vSmIwMnFPTllScSszbmZtZWRiYmVXOHdrU3Bz?= =?utf-8?B?UENNUW1mUDRqUFc5UEpmRHJUVW9abXlrVEhiejk1V0xOd2laVEZoUEVJMHAv?= =?utf-8?B?NGFUQzYxZzR0U1ZxZ0wxeDF2OGFMOWZablhRT2VKTk9NNnhhMC9zY3ZwcjdP?= =?utf-8?B?T3hHQThiZ0VheFdnYkRLdmR0ampBd21kMFp0V3JSdHlCOW9Dc0JLbVBQOEox?= =?utf-8?B?M0FybFFOa1pDc0xrTkVqbWFKbVNWY1BMMXZLVWtpNzNxNGFBc3dzR3U2Z2Fw?= =?utf-8?B?SlZvL3BDeUl3aWN0U2E0VEI4TWUrU2dkbmhSZEJDWmJLUGJQVVJsZmFzNzcr?= =?utf-8?B?UjZYK2ZLOS84UDd2VGo5bVRldVF1NUhTS2tiLzV0QS8wbkpod1FENkwzRUNi?= =?utf-8?B?cWlUZW9oWXUyYmlVVlU3NUdDc0lSSEY1Uk9lcW1MSHBPQjhUVzUwT294MERz?= =?utf-8?B?d05Ub2pCTm1GSnB1bVVvMHZBWFk5M2RRYXJGdG94ajZtUDBjQ1JGcFBhcWVp?= =?utf-8?B?c3JkVUVrdUtiRHp1U0p1bS8xZUdjTzJmMTFuTnkveVVTMVZkYUZPM3ljeENL?= =?utf-8?B?RHNTRzR6ak1GSWUzd040cEpLR3hHN203cnd5bXphcytacEJpWFh0a3VNYi82?= =?utf-8?B?eHZOd1ExSEgxNzBNenBtdmh0VzVKV3lpQWpJYzEwSWlwVVZ2RlVZdnhuS095?= =?utf-8?B?UmdNMFlNMWlINCs1Zk1EekxtZFc3eDRhdjNOblhvcWJBOUhJZkg0WE52UmJv?= =?utf-8?B?M0RiamFoSWdhSDZ5My8vMmZ3REZwbk1NeWxZT3lZWVVteks5eTF1cU4xM1Qx?= =?utf-8?B?aC9TS3JYeTZ6MldQRlhrSUVkK3BVUnZ6NlZhdmI3bldXeEY3ZWJCVDBoMGNI?= =?utf-8?B?Mm5WeFRNeTlFai9CWVJtZ0xuUzF4eUhyVThOamxXejcwSS90dXNoOXdyWHVG?= =?utf-8?B?cDVqSXg4Vm1NTEF3M2hUdVRkMDJ2M3ozNCs2ZFpJN3prQnNjSXluQ3Fvcm9U?= =?utf-8?B?emVrKzZKdEQrMjVZelJWVWNDUXBwWGtjeE0zYTBoelBkK21jUHNiN2Rwa1do?= =?utf-8?B?ekNEVmpXdU84dTYzMHFSbXB1ejQ2dlJpem1MaHFLQ2dtRXV3SlNGOVVGKzNQ?= =?utf-8?B?WGhpMGtsb0dOeVg4bVVLK1d0c05PRVFsVWpLNU1ScGlZZE1kaVF3ejVHZno2?= =?utf-8?B?ZUovbnJXYndpYmY3dXppM2NWa0lJSXhwTW9zTlM2cHlGb1VaanRhUUl2Z1l2?= =?utf-8?B?UVU1eS9ueE9CUlNCYi9ZQ2FTSndPNjJPUzFrNEFaSGFNdWFMYkhUU3JGaGhL?= =?utf-8?B?RFkwRlJRYUlvQ0xsSC9DTi9ncWlEdnR4cWNUUXZ1c2R4UExWSEUvZ1BFTTJ2?= =?utf-8?B?UEJobU9qR2pmVk9VeHRxTGtEZisvYklHcjExR3dCRDIrL1ZmOUk3SXR5aU1u?= =?utf-8?B?cTdUZWM5M2Q2cFlZYWxXVG1ETmpPRitUVlZvbjViZjdKdFJnZ0tuSkQvK3Rm?= =?utf-8?B?MmVrejJucjljclZhQmUxK2tWNm04NkxMRkhiUDg1cG5zOEhOcjlnS0lOR3hr?= =?utf-8?B?eGxDbEk1akRZak10OThMQjU5WlI2R01zWHNqQ1NENUp1QmdlWUJjWHdsL09h?= =?utf-8?B?MHhvd0hhTFRYTkhVYjJxdGtFbHJkNUZGWlNFMXNoZ29UdC95RWROZz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: c940b15a-1695-40f3-30e5-08df22e5812c X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 13:35:22.2203 (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: jd7zJhpiJKeBLgHnXQB/IY2axZL6fMWbaxz4nVtkbqi4q/ycC9dlVrK9wZm/FCqgCUU8PetQGaAFbqAr3Y0xrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9342 X-purgate-ID: tlsNG-d62444/1791207420-1EA66757-34CBC6BE/0/0 X-purgate-type: clean X-purgate-size: 3384 On Fri Oct 2, 2026 at 9:14 PM CEST, Gabriel Quint=C3=A1ns Souto wrote: > On arm32, page-tables are different on each CPUs, although they share som= e > common mappings. > > The xen_pt_update function assumed that only said mappings would be > modified, but did not check this assumption. > > Add a range check to reject modifications to non-common mappings. > > Signed-off-by: Gabriel Quint=C3=A1ns Souto I'm not an arm person, so take this with a serious pinch of salt. > --- > xen/arch/arm/mmu/pt.c | 36 +++++++++++++++++++++++++++++------- > 1 file changed, 29 insertions(+), 7 deletions(-) > > diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c > index 621b47d..ad0d1e6 100644 > --- a/xen/arch/arm/mmu/pt.c > +++ b/xen/arch/arm/mmu/pt.c > @@ -13,6 +13,7 @@ > =20 > #include > #include > +#include > =20 > #ifdef NDEBUG > static inline void > @@ -589,6 +590,29 @@ static unsigned int xen_pt_check_contig(unsigned lon= g vfn, mfn_t mfn, > return XEN_PT_4K_NR_CONTIG; > } > =20 > +#ifdef CONFIG_ARM_32 > +static bool ranges_overlap(unsigned long start1, unsigned long size1, > + unsigned long start2, unsigned long size2) > +{ > + if ( start1 < start2 ) > + return start2 - start1 < size1; > + > + return start1 - start2 < size2; > +} > + > +static bool xen_pt_range_is_non_common(unsigned long virt, We typically prefer positive helpers so you never end up with !xen_pt_range_is_non_common(), which is awkward to read. IMO, this should be xen_pt_range_is_common() with the reverse polarity in the code elsewhere. > + unsigned long size) > +{ > + unsigned long temporary_start =3D TEMPORARY_AREA_ADDR(0); > + unsigned long temporary_size =3D XEN_PT_LEVEL_SIZE(1); > + All ifdefs can go away if you do: if ( !IS_ENABLED(CONFIG_ARM_32) ) return 0; ... here. Everything else drops with DCE when compiling with ARM_32=3Dn both with DEBUG=3Dy and DEBUG=3Dn. And codegen would be identical. > + return ranges_overlap(virt, size, > + DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) || > + ranges_overlap(virt, size, > + temporary_start, temporary_size); > +} > +#endif > + > static DEFINE_SPINLOCK(xen_pt_lock); > =20 > static int xen_pt_update(unsigned long virt, > @@ -601,15 +625,13 @@ static int xen_pt_update(unsigned long virt, > unsigned long vfn =3D virt >> PAGE_SHIFT; > unsigned long left =3D nr_mfns; > =20 > - /* > - * For arm32, page-tables are different on each CPUs. Yet, they shar= e > - * some common mappings. It is assumed that only common mappings > - * will be modified with this function. > - * > - * XXX: Add a check. > - */ > const mfn_t root =3D maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); > =20 > + #ifdef CONFIG_ARM_32 > + if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) ) nit: Perhaps ASSERT_UNREACHABLE() here? Presumably this path is a logical error. > + return -EINVAL; > + #endif > + > if ( flags_has_rwx(flags) ) > { > mm_printk("Mappings should not be both Writeable and Executable.= \n"); Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:38:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:38:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440871.1658385 (Exim 4.92) (envelope-from ) id 1xDitJ-0005Br-3g; Mon, 05 Oct 2026 13:38:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440871.1658385; Mon, 05 Oct 2026 13:38: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 1xDitJ-0005Bk-19; Mon, 05 Oct 2026 13:38:05 +0000 Received: by outflank-mailman (input) for mailman id 1440871; Mon, 05 Oct 2026 13:38:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDitH-0005Bb-EG for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:38:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDitG-0092P8-Ob for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:38:02 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a82d-bab6-0a2a0a5309dd-0a2a450684a4-20 for ; Mon, 05 Oct 2026 15:38:01 +0200 Received: from [74.125.228.37] (helo=mail-pz2-f37.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a694-195a-0a2a45060019-4a7de425b1a4-3 for ; Mon, 05 Oct 2026 15:31:01 +0200 Received: by mail-pz2-f37.google.com with SMTP id d2e1a72fcca58-8873070bcd0so590803b3a.0 for ; Mon, 05 Oct 2026 06:31:00 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:5364:bba9:2adf:d611]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-88b0b8f21e2sm3535988b3a.12.2026.10.05.06.30.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2026 06:30: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=isslab-korea-ac-kr.20251104.gappssmtp.com header.i="@isslab-korea-ac-kr.20251104.gappssmtp.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=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1791207059; x=1791811859; 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=ZLBHWc5heFG+SpSm8h2sc4e0OVYT+vhm1QY+Gsi3sRw=; b=DoPTTwJMejKSOG5xMH7snikaE3OyHHke365U6WkUsU2EyPTyDUl3A3vHSrxqw7cXT7 Kh43D5w8NSRuAbwPDaUZJIbCL3aXs52FB0CZs5E1KFIlipvjsMVSC0bbUgkglqd0aSWE 6L4OZKnp2L8KIpnJRx69+xtvLmnZNgcWrayMf3ShUHByNanF7Vlxh60NBwB1Lq4I0PU9 LgZxJk3uD//IQ9PppFrGFqzLIVIQRyojJoYqaOAWYjnHEtHauA/o6Ho7Vgrf+BKZajdZ mwY2bUdnrRJi/zimEL3Cj40BAVfoJwNc/PKxjTek6AAcXRmhdiOCkHPuvve5ubXrrZA3 wTlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791207059; x=1791811859; 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=ZLBHWc5heFG+SpSm8h2sc4e0OVYT+vhm1QY+Gsi3sRw=; b=imp9q9lVEoelphdPpzjGfrkN9TElHFhSMSgtG5lUFa5UMFVtXYpLlAwBEfQyag7nsP xrRGpdk9s8C5+RMOzGvIuxJ26jpOLz6+jWsIs9rQraPNCurCgAdNXjlcmpRoXH/iSugH pVKT+5qKEEC0hL4vAGRlvEFItvv80e8jG5mZ/rZQLz5q1BmKHFYt/1+rNVdJTj865eSy DkNiTFKgLl6V+b+GHetq7dVN6zybxeDCpXxw+E7udzD1+q7U2YXnvJhV7S1XMxk0ajwu jScZQ6hWBA/F6hSHeCQNlscBx8XSGYlyTUM7+Znv7SDLz7WTzzlP+BTRF7wiYWQbGvLp lIng== X-Forwarded-Encrypted: i=1; AKwUvBwYcmh7RXVv23l+IE37MglofmfRuagvYvEm3rPzEO4YBq528mJSi2p851CrMoRRci08P4cPFA2CPvo=@lists.xenproject.org X-Gm-Message-State: AFuF++l4Mvf9td7ydnDLr3Swj0Wugn65DIBhwrC5lGYRA9buShV7esVG eRH8GSCGr8Vzs+0pUWHDQoy5FXTU0SK8yNO4WLz6NsDwje4n2Hb67mM+rThf7qznuKg= X-Gm-Gg: AYBFou35KGimlc+kPaAOPdGdyUtXLg8RmuqdbPotIinVlNY46uvD9EabUICOcAvHfWa LtfNU6RiVkcJi/wcYF73o+h6iIrgCtbAuNNmtbEeLbVX2rPC1SJRziuZdcgm/1hDo1M2XNYvey4 CXR24AOdgwSMfhGhhTEYFqApOfDz8fpyj3RQQwfBkft98hNFIVcffHIkfWRij9jMrKQQoNl8K4f H2OrkTpGJ+jMlFRuUO1FaPLt5Ef6bcxr7tgq4+lDLZGlj5Y6OXeh0PX4tJaGlyB3Kv7jxbtppL+ AQdwlJXZwUYQx20qQFjwL+PEWKaUIdXZL6CLVUH9gUtGCDg8R3XSgXsjsuCwllVFWx8tsui2km0 1uzlcKGgLti6aob9OIcnfd0PyGMv0ixlTohcLNe0ptzVsp4IqKPSbvpCLFMmnzduEfbm2ol2Zvu 8e8u42lXEhoe+vZ6voy/JvzwQ3g6SeFjuqo9EZzeMHSqpQyBkxlGpu5dzT+7nzcT8UyPOQP3oKN O3EOXdHbOuLzukg6qXsYA== X-Received: by 2002:a05:6a00:1595:b0:88d:20ff:15c0 with SMTP id d2e1a72fcca58-88d20ff2cacmr5378745b3a.11.1791207059207; Mon, 05 Oct 2026 06:30:59 -0700 (PDT) From: Yehyeong Lee To: jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, bhelgaas@google.com, jbeulich@suse.com, konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org, Yehyeong Lee , Jan Beulich Subject: [PATCH] xen/pcifront: check that an AER callback exists before calling it Date: Mon, 5 Oct 2026 22:30:18 +0900 Message-ID: <20261005133019.284053-1-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1791207061-F440377B-7E978946/13/0 X-purgate-type: clean X-purgate-size: 2413 pcifront_common_process() handles an AER request from the backend by dispatching on aer_op.cmd to the bound driver's PCI error handler. It only checks that err_handler and err_handler->error_detected are present, then for the mmio_enabled, slot_reset and resume commands it calls the corresponding callback unconditionally. Those three callbacks are optional -- the PCI core NULL-checks each of them individually before use -- and many drivers (for example igb, igc, ice and ixgbevf) install error_detected without all of them. aer_op.cmd comes from the shared ring, so a malicious or buggy backend can send XEN_PCI_OP_aer_mmio (or _slotreset/_resume) for a device whose driver leaves that callback NULL and make the frontend call through a NULL pointer, crashing the guest. Check each callback before calling it, as the PCI core already does, and fall through to PCI_ERS_RESULT_NONE when it is absent. Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- There is an in-flight fix for a refcount leak in this same function ("xen/pcifront: Fix PCI device reference leak in AER handling"); this change is orthogonal and applies in either order. drivers/pci/xen-pcifront.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c index cffc32d660327..490913676f244 100644 --- a/drivers/pci/xen-pcifront.c +++ b/drivers/pci/xen-pcifront.c @@ -599,12 +599,17 @@ static pci_ers_result_t pcifront_common_process(int cmd, case XEN_PCI_OP_aer_detected: return pdrv->err_handler->error_detected(pcidev, state); case XEN_PCI_OP_aer_mmio: - return pdrv->err_handler->mmio_enabled(pcidev); + if (pdrv->err_handler->mmio_enabled) + return pdrv->err_handler->mmio_enabled(pcidev); + break; case XEN_PCI_OP_aer_slotreset: - return pdrv->err_handler->slot_reset(pcidev); + if (pdrv->err_handler->slot_reset) + return pdrv->err_handler->slot_reset(pcidev); + break; case XEN_PCI_OP_aer_resume: - pdrv->err_handler->resume(pcidev); - return PCI_ERS_RESULT_NONE; + if (pdrv->err_handler->resume) + pdrv->err_handler->resume(pcidev); + break; default: dev_err(&pdev->xdev->dev, "bad request in aer recovery operation!\n"); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:39:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:39:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440877.1658395 (Exim 4.92) (envelope-from ) id 1xDiuV-0005vn-EU; Mon, 05 Oct 2026 13:39:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440877.1658395; Mon, 05 Oct 2026 13:39: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 1xDiuV-0005vg-BA; Mon, 05 Oct 2026 13:39:19 +0000 Received: by outflank-mailman (input) for mailman id 1440877; Mon, 05 Oct 2026 13:39:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDiuU-0005vY-UA for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:39:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDiuU-006HIJ-B1 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:39:18 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a877-bab6-0a2a0a5309dd-0a2a4509cb50-48 for ; Mon, 05 Oct 2026 15:39:18 +0200 Received: from [52.101.43.17] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3a884-be1a-0a2a45090019-34652b117a46-4 for ; Mon, 05 Oct 2026 15:39:18 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB7962.namprd03.prod.outlook.com (2603:10b6:303:273::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 13:39:14 +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.0472.016; Mon, 5 Oct 2026 13:39: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=Nn/WAThzRYdZwJx5GBw5tKTCiw8KsyCxoiX3WBGJSQ1cimgxipMhHdlQUdVg/+F3iHN7yM19HWQzM31G6IzWuOiRXMEzjWQYlUR1Foh0h9L2/NJnPYmy+P1XaRkSEoxcAHc8AYZ6jpEVKE436Pa49FDbWFT1k4mx4tD5kwy/EOEi8urPINmv3thSX6PDtebpxBwk1n0RYoC3eXc9eb7EYNy3NNwrN/wqnVqup8kQaeJUsWKizaJihMksk8t7DoVEwTVULJ3QlLrgJLXzNBY8bRdt28g7cAOTM8+ZZ5gNy3PGkRASFaK91S3iLV6JsCl5Ccc331cgX+bPsqwV+9SQSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dmNsEdOjgKwjzyt+d3HSQI7dYPcctUGco0Q1rEmrgZw=; b=hrV41l/XVo/WEuN2yyUChfKaUA/XIT40eoym6sfdJ62zt0KiJzrpUBUX/oLrWVjT5YszPhfDUjT5rT8wHZZPzGMpWcCtFbio+i+QtzeMzyOprhOvQrpBFzDS6CFwpD4fPPn9C31bWecXt9fAEeDC7T87FWm2QN6lY0fPEGcrsikprRGHK2o9cvoHsahXk+GPrRAWIxx5nJ5YjeXWOVeXmUTnvi+V21TaMxvCeHcSabuAlZdi2aH0T7Bjawe9LoJ0m3JTGzL2jX1AAwpTZJw2G9XRLGK8glZ7sZHuVgKzBETq0Lgw+AysVRPGwhz106pw67RDQPiqfm8yTbRxso82Wg== 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=dmNsEdOjgKwjzyt+d3HSQI7dYPcctUGco0Q1rEmrgZw=; b=ZiK+MeNVVJGwUjuJ7rD/UD4axE2RJX/fKs+ut7WgxTOlwKO7YcaZYiY04GhLkqbmr6Umuwz6YlSkQWFcsk5AuH50H00HoYzEmpJs8/XwUQmYRzrRI9LzUJtutYQ52CKc6iEP42788UGsJGfw/sRzy5lqV5hpnrH8rgxKYUAG6IY= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <277f7edf-bc9c-45c4-9769-6aafcbc5547d@citrix.com> Date: Mon, 5 Oct 2026 14:39:11 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Nicola Vetrini , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@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: <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P123CA0001.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:338::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_|CO1PR03MB7962:EE_ X-MS-Office365-Filtering-Correlation-Id: dc60b715-5b5e-4b5d-3b5a-08df22e60b9a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|11063799006|56012099006|4143699003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: bfVJSsAZCAVfhkjjuwFkegffIzSVvzvUTSpHZgfV3q5lRe9zJv85buqgEvqkgg82oMxmHRNMsrYhr43UBqAxbngIk5Jkcx/ZUaHT0wPkpNkodTcnJdgmf5lj27yOaCplSI1ul6LvlSyV615p/g+dCk5wUmvcZ3Ma9/BnfY2QzzxcGXDGytoGBy9KCDctZksBxY4AkBsBllDpOb7GToMFbn3VQvvypmy2KEl+PolKy+ULCXAyjqcQCG9vDZiutMc0fijYU/g43EWSsdoNTp0RqXk69gX7jGYk7XwC2cafQaZJ1UzRg3QcmMX9RnGh/2YHAozU2vkM7x8DXUVtwCh4WomRD2sNbhMfc5/leOw5zLyebb3ex5ju7pIzMy8ScLRYzVg+iADd4EHnYkYI/Tg3yd3Z0vG7+G7OBjhFgUQa2cCPJaSC3lf/Q90IznZZ5qLkXhj+1/PfL9QkUjOfclb+kgWD87CLbKlMijmeaFt8joXO9QwO21mliB1h6GvGG+kLJAb/EZ9BCPwdLyFvXIoUxn+ytViBnuPQmdB0S7qoknNZ1YbocbmrBdZTwVC2+nn/Zog2n6+KSldV7/GWnTvyd0SFNzAWy6peRxlTeFBfxnmRWObDQPb0aZZqdIRQ5Rld2C15T8J1uOLDLTyW4xynhg1RXzJem9N0FzTu21sTKM8= 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)(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?SW03OEFpNis3M1dlYU40Ny9uMUdvNjZ0UWpheDIzSjJLL3YxYlNjWUFIaE9T?= =?utf-8?B?NVRUSCtlNEdYdG1LUlk1eXlweEFNYmpjaXpaRzBsZ1FpeDNJcUVNU1JIcnBy?= =?utf-8?B?cmxWWlRjd1AvR0laVmZDNDdXRmJ5K3gzVUVRNFY0c3hoZjhmTitVc3diTUhD?= =?utf-8?B?d0NnM0xYRUxrVkJBTUtGc254bS9nQTRUUGNhN1oyZ28vT1oyTGxFaEhjNjZR?= =?utf-8?B?Z1h6bkFveThta25CdDVNSUFOS2FzRnF1RG1wUzNKTlJDZ0pBbnQxRlloRkp1?= =?utf-8?B?WnhzUkhZbkNqa1JJSVpGakVsYThuajZ2MzdZd0pSWUJtZGYyRjkzRUpKRU93?= =?utf-8?B?ZDkzQjBOcTEzR25Qa3dlcDczMEY5RlAwSkFNbzlmU2xKWjRXSlpVVmhEazBx?= =?utf-8?B?SHozL3hrTFBLUkxiZXd6L1ArREUrZkVxanRnTnRXSkIzNWVqVlg5aWwxOU9j?= =?utf-8?B?Y0ZxeWExQXgzbFQ3ZlJtZ2E1N3owUnA2MzE4NnliU2pSak05VVJyQUJOUEZF?= =?utf-8?B?MnhlOXpjeFdLZGxzTXl3QmNkbU9mNlVDN3UydHcvRDhtYW5lbGVUb2liQmpj?= =?utf-8?B?OXhuKy9pN1h1bUVNUjEyYXE3V2RHTEFXMXdScERDQ3FuUHhyaDc4QnBJRHlm?= =?utf-8?B?VjlaUjBtQkZndjEvcEhmdXBYSzRhNTB0ampOdjU3b09DdHNOeDhwUEFGVGd5?= =?utf-8?B?MG9BNFg1RWFhNUZuVXJaVExuSEFyT3VLajR1NTZ3azRQbkF0TTBENGhDUk0x?= =?utf-8?B?VjRYQ1VmNHhSM3VGMEJkSGxlY2NNODNabE8vcWxab1VlcG9nOHlrVnpsYU9l?= =?utf-8?B?dE1PbEZuNzM0Q3hLMmhvWmJSZi9XREgzTldDVUFsWmZ1djlWMWM0TEpWeWNv?= =?utf-8?B?bXVPcVIvL3lYV3FzSkZaZHB0UGd3N1V0bUpkSHZJc2FTb3lKbFp2bUpMdmlK?= =?utf-8?B?cWlqZTUyUHNqdjJqbjFCeVF6aGFKT2J3c3FpajZkVUlKRFh2WTAxR2RzT2Ex?= =?utf-8?B?TXFPbEdpTjZBNm9IRUk5Z2ZJU2xIMU1raHFpeWhqdXBDdU1rdVRuczFVUk83?= =?utf-8?B?UGF0WU5FMU9SQjZoMCtnYmpXY3FiQ3pWdXBuVnFUSFpWVDVVZnh4bVhvNkpF?= =?utf-8?B?dXo5dUMyVERURGNQRjg0eElPemJmNUd2NmZMbU5DYUxXMGcxd25wb0FEdWhu?= =?utf-8?B?OTZUYUxIeXZOdlJRcElZbFFiakpvNEhhV084bEk4NTZDYWRTdW5JSEZ6bjBT?= =?utf-8?B?YUszVHFJWURtUWVkMGorQUx0b0sva1Z0UmZ6cFQ0QnVZOTh2bGlYaFNCR1cy?= =?utf-8?B?NDRCRkV2Qmd5a2I3QmJNcFgxTnVDQjRFWU5kejFFclF3d2lmVUhPcVhVdzRw?= =?utf-8?B?NUF6Qmk4czNaNU0rNnlRMldjTDRENC9yZXFqdk1BK01paHBWUEY1bExHOXdC?= =?utf-8?B?LzgrcnY0bDM1NldVMzVjbEdCdllmWjMzOHhUclltdzVqKzU5QnBVTUQwL2Ju?= =?utf-8?B?QWhuS3Qxdi8yQmdscHN5SXBySEtFOEtnZ0NiSUdCSGxnMjFDMFV5K1Y0ekhU?= =?utf-8?B?dVZQS0lMV3pIRVh3YWQvaDdkK3RPU1M1UFIxVkNYZDIvTnovUzVoTFNyZzFo?= =?utf-8?B?a2ZKY1E3UGg1ODlHV1FpelNCNzZCU1lISDgyNWJaaEFRMit2UnJFcU1mNVlQ?= =?utf-8?B?NXg0eE5QSkxPSzVRbGJBckJVTE5pQnNEeHd3aUhRSzVXZCsrUldHa3k5aDhR?= =?utf-8?B?NEg4U3lRam9wZ2JUbUh6TFBmTi95THBCUEFxQWtzWTNLREs3R2VMNDFSUWtK?= =?utf-8?B?WXZhOWJ5alQ2UEhOSHVGRkNTN2JTTGI3cWd4MXEzQTBKbGcwbHlHbENTM1BE?= =?utf-8?B?TElZWGh1VzJoRDFoanlFeFRHbUwvcVZ4RW93ZkIrWitjNFAweU5SeFhaeDZj?= =?utf-8?B?c1l5M1ZsWU9vUUQ4b2FjdG9KZTZVUG1CdlNPaFgwUXFJT0pMZTA4UHRpSGdo?= =?utf-8?B?Y09EcUJ4ZGcyODV4UThTMW1tRXI5L1p3SHpKUUpyeFYyaisrdVRPMzFuNFdz?= =?utf-8?B?dkhvb1NvMGRxVmRicThpaEgwT1JLWkl3RlpDTTYrelhldXJTQmR4TnEydURr?= =?utf-8?B?Nm02UUpkMkJzeHVLVzRqdWFtZmVXempBQ3FRaGduNTIxcGVvZk1zWFVrOWl0?= =?utf-8?B?eFduV1NRcGdzTVQ3alM0TFNPYndSb0FFdWI1Y3BLS093bUxPTVFWS0NzZTBX?= =?utf-8?B?RjZoUkMyaFpZRGhqc3dvdG1lYXlnaC94WXJuSm1UR0l6T0YvaVA3Y29CVXZN?= =?utf-8?B?c1NzNnBjNThyVytoZi83aGtZRU5YQ1lDY1g2MlUzNVUyMmdJOVh2dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc60b715-5b5e-4b5d-3b5a-08df22e60b9a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 13:39:14.4013 (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: XkVeuDk835zUrZIpQe0TbJyWzTLIp17OR5UmWZn/LcdpyOiacdwckypDjZXP6zldoVcSPj7ochLZylccBUHo9ijLI4B1OOKoe4ifdHcKeJk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7962 X-purgate-ID: tlsNG-bad1c0/1791207558-3A2C4034-F5C3DD95/10/78276251493 X-purgate-type: spam X-purgate-size: 322 On 28/08/2026 8:02 am, Jan Beulich wrote: > The use of unreachable(), when unreachability is visible to Eclair (and > compilers), is deemed a violation. Drop the redundant statement. > > No functional change. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Oct 05 13:39:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 13:39:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440880.1658404 (Exim 4.92) (envelope-from ) id 1xDiuu-0006MI-PT; Mon, 05 Oct 2026 13:39:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440880.1658404; Mon, 05 Oct 2026 13:39: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 1xDiuu-0006MA-MN; Mon, 05 Oct 2026 13:39:44 +0000 Received: by outflank-mailman (input) for mailman id 1440880; Mon, 05 Oct 2026 13:39:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDiut-0006Lk-9n for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 13:39:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDius-002yCn-Mw for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:39:42 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3a89e-e002-0a2a0a5209dd-0a2a45058f66-0 for ; Mon, 05 Oct 2026 15:39:42 +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 6ac3a89d-4cb1-0a2a45050019-aa0a817cd765-3 for ; Mon, 05 Oct 2026 15:39: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-319-r6z15yOkNo2bxv0SFns8Qg-1; Mon, 05 Oct 2026 09:39:39 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1562B196C428; Mon, 5 Oct 2026 13:39:38 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 355761800446; Mon, 5 Oct 2026 13:39: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=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=1791207581; 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=n6vF1KMKYttXS817LHuQhd6SNLkTLI+56sGMUZLzBHc=; b=fo7/WrdE20CuJAhHNpn8ES3ZrUwhEtE1461iRu7XMpKPaUjRydKY7pAoLwEZahIdNeCJ3s 4HGynQuUqMiN9ImWxpaT0DX4yrwKYU19djiU59zBCu1dM6pLwHb3gHvKg73yD2iYtA38yl sCATmpb23580sKjBi5V3nDbSP0nz/eM= X-MC-Unique: r6z15yOkNo2bxv0SFns8Qg-1 X-Mimecast-MFC-AGG-ID: r6z15yOkNo2bxv0SFns8Qg_1791207578 Date: Mon, 5 Oct 2026 14:39:33 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, 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 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-2-berrange@redhat.com> <5e64e1e0-d733-4f8e-98b4-8e6b554101b2@oss.qualcomm.com> MIME-Version: 1.0 In-Reply-To: <5e64e1e0-d733-4f8e-98b4-8e6b554101b2@oss.qualcomm.com> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: y3KS_CNFpAXzqN1fRQ7rEiF9cYLXzmBVIoHbyVt82kQ_1791207578 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1791207582-71EA92A1-0B09E821/0/0 X-purgate-type: clean X-purgate-size: 2988 On Mon, Oct 05, 2026 at 03:34:52PM +0200, Philippe Mathieu-Daudé wrote: > On 5/10/26 15:23, Daniel P. Berrangé wrote: > > On Mon, Oct 05, 2026 at 03:06:08PM +0200, Philippe Mathieu-Daudé wrote: > > > Hi, > > > > > > On 11/9/26 16:36, Daniel P. Berrangé wrote: > > > > 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(-) > > > > > > This patch should be split per machine / area of maintenance, > > > so maintainers can officially Ack their commitment to security > > > boundary for their machine. > > > > > > I'm not sure LoongArch / RISCV / PPC are. If this was previously > > > discussed, then pointer to the public discussions should be listed > > > in the patch description. > > > > Those are explicitly documented here: > > > > https://www.qemu.org/docs/master/system/security.html#virtualization-use-case > > > > so this patch is just encoding what has already been defined. > > I probably missed when this was accepted, we are good then! > > That said, 1/ Nitro Enclave are missing and 2/ this series organization > is not easy to follow to me: I'd rather a per-machine approach, with a > 'info qom-tree' output justifying the devices, then finish the series > with busses-based devices expected to be secure. I dont quite follow > this approach. I'm not asking to redo the series since it is already > reviewed. The structure is essentially, the machines listed in the docs, the hardware accelerators, the paravirtualized devices, and then per subsystem devices for the rest. A per-machine approach would end up with 90% of the series added in the first patch, as most devices are common to all machines or targets. 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 Mon Oct 05 14:09:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 14:09:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440896.1658413 (Exim 4.92) (envelope-from ) id 1xDjNT-0003y9-VH; Mon, 05 Oct 2026 14:09:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440896.1658413; Mon, 05 Oct 2026 14: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 1xDjNT-0003y2-S3; Mon, 05 Oct 2026 14:09:15 +0000 Received: by outflank-mailman (input) for mailman id 1440896; Mon, 05 Oct 2026 14:09:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDjNS-0003xq-JV for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:09:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDjNR-0098s8-SD for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:09:13 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3af84-e002-0a2a0a5209dd-0a2a450187ba-14 for ; Mon, 05 Oct 2026 16:09:13 +0200 Received: from [40.107.208.2] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3af88-5984-0a2a45010019-286bd0021ad2-4 for ; Mon, 05 Oct 2026 16:09:13 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA1PR03MB612249.namprd03.prod.outlook.com (2603:10b6:806:5a1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 14:09: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.0472.016; Mon, 5 Oct 2026 14: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" 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=jb46OOhEUApwtHX1eNBiYXa7UWq0kVT7LX5jqIrsBN72838pkGa3Zq+hu6z5dChj7rO7nW4HSr9o2uK2c4TLYHjPRmFsOaFQ54BPjFyShc4F/ewzdM+qsb5NFjJWT3GI4mViiu9CjBkW1nFDx/3FAjk9Ip8OdifnGYSlqGnjCkjIiOUQNYUAs9BUJlra/yfj8gjSMoLxoJsFtJAL6Cu7MVmHWqFs6y91npYWxqQ6zMjDFmk5S/BMnNQgUi8oICdHIaqw8friPLSc9pxlcojKI8Tn2Yfl8nHeq0xGFnkpf5vtZ+josnO9IPLisDjDRrYX+xpbGSw9F25HreSrmaKGWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/BYmbbGBGNk9LoFC7PO4PfZzPCIpccYFQDxDngO75ro=; b=AmkKdpA66nR4teOWmX+lzez3tujem0YnxHRS76USIQQ7IRZPInbZc3my9qDXBcfQbb0iR49QRWTj9jJ88eS8H6sQRgvMXeSzah21LxEFWJ6VIQCAa6sw73B0EulkKetYx1n2nV7siZbDYgQAco7vIfgQ4vFZl9tViizVVFCjbK3dfZWmKCVS65lpTlw5RZ+o70Vh05ZqKpdPX/V2rcZPE/Bju2+XiCp9IhYlPpTJZGUYI6VKrrlleDv6pnEp65UfH+lz8pNSEruoIAdvaO3cCdb1LdJo+KzYBfb59KEqO3yu3GVtrdOxKONFBlz776PplK+hpmaU3M5FycXASJK9+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=/BYmbbGBGNk9LoFC7PO4PfZzPCIpccYFQDxDngO75ro=; b=dR8SK9lNL6CbNy4uUXJ9gHfWYj0m1wM7ZMvFISnFk3lJQIRvFcsD9kXvPPDBMdm6DPzv6Bt/wJ9gZsn5AYuV9u+IsUCt9loSN/i5YoHrHIEQL4MdnmxtquX0qridMFYNjvdZ2wD3YX0G7lI9gdMecVYprrdMlwDfjvc8yVW1RhY= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <51c31589-5b82-44fb-8756-d98cacb9c685@citrix.com> Date: Mon, 5 Oct 2026 15:09:04 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Nicola Vetrini , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 03/14] x86: have cmpxchg16b() obey to Misra rule 11.8 To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <8ae3cc08-2011-4689-8530-f3b962ed4d72@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: <8ae3cc08-2011-4689-8530-f3b962ed4d72@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PA7P264CA0140.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:377::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_|SA1PR03MB612249:EE_ X-MS-Office365-Filtering-Correlation-Id: 96cebcdf-2725-4cd7-2bb6-08df22ea38bf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|56012099006|4143699003|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: S7Ldos/6vs1zheQYLvCOZ9nPLx6A4CB8i4pDMbuSuiA966eQUop602bHlZRqTdJ5XMxNfSNT0JCaEcAsJvIHSzcUmjHb2W6IWe3gra1gAPVYHKzXU+mt+4ms1f9UdYlq9EcP19DVVzxLB0juZ1KnkpsTUq9lFvDBXhgYhZxRWO5zckC0VgHnDeYcwZdmftKqeqPj8w4+XfME9QCFm0HkJmE4WfXRCXXGegGq4TeKchblaKdoiEV8ceTzGBDc9jqWQy2zSQuUZSo8NEe0wDEKJtalZQMfjR2zvHJZJZeq03QQyyqYOIBiSWkW98RUSYzbtweHo/MNMc9FpIslDfxlJAHSRfNeJTE4iVYkpEd7YDaSNUEXLSUh5tVMnEn4TPWRZrTdO7gVS0muWeI6QN6UbIVCkz6S0Gkl/nEu71LBF4OrD+tjcJqv/XJmoeouluFpsq6d5N4GtNf1bhEMveYEYdluEp1tnkdcvTXoR7fn8xDZAmI6KIuIupIQRTeodoYFrUV6R9RTjB0DC7swd0ATijrLQTOxcO/tp5hv1JY4MahnxSg4jYLjiQgyCAPoTBqUUIA6f/b1x1Hmlw3637+sWEk6pRqWPRtDIcNcDDYnHZcTdKx6rjRM5rnRaFDHdlsAE0Nsz7YzlJqNT2ri85gZ3o8uAFpaUle2ps157NOixkQ= 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)(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?TXJDckhhckRZZDN3Mk5YR3JnRHVBUHlhMmYvWGNtcG9kV2VtRWRsQmtXTWw3?= =?utf-8?B?SytFOEdJSWEwRE5vb1JIZWJQV1hRMkJnb0hKN3ErbW8xeVBLekdueW11bzFm?= =?utf-8?B?ZHNHamhmVmIvYTE4cm9XK01wZ3ZtWnlveUZwMWRyRzJncHlhenM3MHJnZmJS?= =?utf-8?B?bXJzZDRSRVFILzkwZlRsTnB2TUduZmliMGJ3WEFXWjhCQ0Rnbis3QnlVU082?= =?utf-8?B?SjdTd0V1WFJPRHRKcE9oYmxOTGROK0FycllpOG94Y3VOK1E5bGRYMkd2M0VQ?= =?utf-8?B?dUdaTmRMd2F2b2drWlh6UlRyWXZiVnBwcm5VeDN0Y0NwTlJ3Z2c4M2ZrdnlT?= =?utf-8?B?Y01ucFZpaitVaDQwZ1lITmtCa1haV2Fka0d2SFJ4Mmo4Z21ZK2FtQUY4anFY?= =?utf-8?B?RkFwQUw1RVJBMzg1RXJ0WHBQWktON21pWUNIN0xiT09nNDdoTEphaUNEaks3?= =?utf-8?B?bEZVckpuL1ptS21yditFUVl6N2h0SXlPUWZKeXhUNnU3UUFwVnk5SmJJRU1G?= =?utf-8?B?eVY0NHZ4VEZDRE1xV2FZVDVwSkpKUWEydEdxaWZWRFlvend2YkxkUk1QSzBn?= =?utf-8?B?UEtpblRkVjE0Q3hBdG9WVzZFbkRKREF4Tll1bDJsWTFiK1VoMUF5Y1FFZUtn?= =?utf-8?B?bFh4UE9pdEFBdXFobkVIMm1zQkg1aTNQRk40OW9QTFUwUEtqdU1FeWZhSEJ5?= =?utf-8?B?R0RtZGgzTitqdFh6SEYxSWZPeTA4MkoweFZ3R0E2YWtjYURXZENHd3o0SXNL?= =?utf-8?B?ZDBGOFBocXpWdFI4V0l0bnkwZlpXN0hJMVk3Z01uTXNIOFk1dkhlOWFtWXhN?= =?utf-8?B?TlcvaHFVcmtvaFpLd1hiaG1kbk5oRTVlMFpyZEhISFdjWHpJZGd0QzI0M2d6?= =?utf-8?B?QS9DZFlBVVJwVDBrUFBMZ2g3V1F6eGR3MW1hQjdsQnpIMkJNdUNIemppTkNn?= =?utf-8?B?YTBCMmQ2Q29sQm95Z012UG9nZUNOZExZV1lsMFFlVTVCb3NWN2duVmxpN1Yz?= =?utf-8?B?dDRIR3VBanUrVG5TZ1IxaHB3WHpxWGZLaFhmZUZKOFMyeWZ6SUlDRHd1TEtU?= =?utf-8?B?a085c0pmU1FsUUVhZEVqTUEwbXg4QTA0WjB6Y3lKa3RNMGJsUzJOcnVSZnJN?= =?utf-8?B?Q25zdFJ4RmVpNktUNTIzS01zUUh5TDEzR1hzN1hLVWZ0cXpLZkZHT1k5Ym9G?= =?utf-8?B?MkFoVlRjSldmeVdjNld6Yy91Y3Bya2N2Wjk1MXZjUk9scHpybGdrR3hsZzdm?= =?utf-8?B?bTZzYXJSZGtnOFhPRGdNR3l0ODVuZE1ETW94S0ZPNlRpb0U4bWRVVnpKVE9z?= =?utf-8?B?dUNvMU1DU00wcDF5YnArMGprWGtZNVNidDFBZlc5YmQrTkRGNkh5S3FFRXNX?= =?utf-8?B?a0lRUWFqcUl4Sk15TUJINTEyV056eFFoa284T0FYaUE1Y1lLaUIxNnlMNnFu?= =?utf-8?B?MU5NRmdYR3NiNDRGUzd3SXRGU1U1WHJQVmRFeUk5bkM3UUV1Z3RVLzFLRjFl?= =?utf-8?B?R2ZMNVQxSXo3czgrQU1hTEIzbm1TTWljY1Q0YSsrR2pGdWdiWmNlMGdXbFhy?= =?utf-8?B?RFBtaVRqMEkvVVFNbk9DU2pHNFZ6Nk5YaWZBb3hUZnBMaGZaVC81MnNqTkxz?= =?utf-8?B?R21lUkk3dDc3eUg3VG4vMXhHTFpsbnpJNExNeXlVaVpCQklMeVlLc0E1Vnd6?= =?utf-8?B?b041K0o3TFl6V2o1Z1gwSitnQ0gyejVYZGRRTnVXdGovc21WWWJGWW1MUk9L?= =?utf-8?B?T1laMGF5L1JManlRQ2dHK0VYdGRhVnVlNjhzZnZIWVk5RXlPa1VHM3lmamVm?= =?utf-8?B?cTZRaWhTeUM4Kzd1aWVpc0NsU0lxZzB5alpCZ1pQQnNQWGRidkt3TDd1dFdB?= =?utf-8?B?Q2ZvcFo3Qy84MEIvSzFuTnJyTm9nZFJNY1V2VWVXaTdaT0grYy9LVTBwQ05y?= =?utf-8?B?ZW9VYlhrV1ZzemF5cVlrcTJLcnZ3Z2NCZVh3U2QvaExKU1NLZ3JtNWxaek9u?= =?utf-8?B?TlVreHVHUmtpbkRtVEhIeTdFWXBMZUVMVTVlai8yb0JyK1FhUjJNQ1oxeUhE?= =?utf-8?B?UlloQURGR2lYd0FMa25BN1NGWFhLVVlkcWJZazZ1UzFVdnZkT1JRc2p5TEdz?= =?utf-8?B?TXBxS2pacDNoSGZqOE1HczZkNlRmRVRoVVNuNUVIYUpWbU00cjFGNzNKNy96?= =?utf-8?B?SVZUYlltU0RMeXJNZ3FqeFZrai9rSzZzMVZwYVQvUmFhSmRxUks5bW5UeURy?= =?utf-8?B?NUZHNGRtTk1FVENxajF6VUxBNXY4L0N3b2xlMDNFZE5oYTZCMWJ3NEhGQU1s?= =?utf-8?B?L3R0OFUxZjlnR3BKc1pUYTR0c1lHUkpjRCtMWllGMUx4YllBL0R1UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96cebcdf-2725-4cd7-2bb6-08df22ea38bf X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 14:09:08.0266 (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: TAj+TAvg1Zi6sTOU7yfADLtfl5m+ukcANlrqr7k4ID7iuTiWSUHcv8g0g7wAeeykIuNsidAqFk29PFCdxrvmOUqEYuszwokhbtTfmWEVmNA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB612249 X-purgate-ID: tlsNG-d62444/1791209353-BC359757-C819C7A8/10/78276251493 X-purgate-type: spam X-purgate-size: 354 On 02/09/2026 7:31 am, Jan Beulich wrote: > 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 Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Oct 05 14:20:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 14:20:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440902.1658423 (Exim 4.92) (envelope-from ) id 1xDjYQ-0007Ka-UV; Mon, 05 Oct 2026 14:20:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440902.1658423; Mon, 05 Oct 2026 14:20: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 1xDjYQ-0007Jh-Qk; Mon, 05 Oct 2026 14:20:34 +0000 Received: by outflank-mailman (input) for mailman id 1440902; Mon, 05 Oct 2026 14:20:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDjYP-0007JH-BS for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:20:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDjYO-001sgZ-3k for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:20:32 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3b223-bab6-0a2a0a5309dd-0a2a4504a952-26 for ; Mon, 05 Oct 2026 16:20:27 +0200 Received: from [40.107.209.36] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3b229-b57f-0a2a45040019-286bd124311a-3 for ; Mon, 05 Oct 2026 16:20:26 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by CH1PR12MB9599.namprd12.prod.outlook.com (2603:10b6:610:2ae::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 14:20:19 +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.0472.016; Mon, 5 Oct 2026 14:20: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=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=AbORgdSLavhhKbtCoYIXW+rVSiyaZEe0Q7wNs23J++T74zHPu/2ICt9diLOj1/W2ulkYSpbKTVhpukowLmB2VhPHCsRa/BtJPgca3JGGZCRpzX4I+gISRLHetGq648J83/aSRZCOCjZ7ZgnzTICxIXJYxs6+HHne/Mw0osiAcRLDsaIC0FBCOmGqpbUL+UE2gB0Q88hvTUZFD3N+Xy9MSzL5BEG9Rqh/vWSVA8uOCCUKOTlu9KckYU+li4/QLen/oNqfKXB2L29HQGDpR4dw17ZZLBAIJtbh4abVebQvl5W7bhdpoxxlgsYtm5G0xWTydPd0tbsBvkT7+mkyK3KH4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DdkQ090/RIKRtGEm0ll0/tOCZWXQzYWVSGBNfJ/gW/o=; b=OFoGPfrDIkIT6ICi4cjet6f3724OukIcpu1ksIy2sqnhO+smf18lIYGoMzgFKaGVdbNwBAqAdBFrXC8oAJU98l4/ZGqJzmaG/dxuSoJmHbn96pebtCZEFO3mFRHXqZgX3CYP5FL53J0EAVlUg/vUqQNPhVKjFBFzdp6y5mYh37v7Wj3ojWWJPqHqcgkGTFFVqIYwe8ulbBOAlkvL9QICZ+h4ZhOdkQUA7moHFWXxCretngWcIOVhfimKtLfWK7/Ivm3YE9VDEf1M1BXWB0M8SePkqGOuu+ngRtrqVGh5PBX8UOXcDn3zjiOd0nzP39LFeSn2HAmH96n9SA/jL00Dlw== 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=DdkQ090/RIKRtGEm0ll0/tOCZWXQzYWVSGBNfJ/gW/o=; b=mMva0xf7V2RzqdRi+n1WbrvDrpJkWnaIG6QKd1xqS9Wt8bH+Y639SkLtmRBPB/eoGRjWn0Y5NpH+MyVBTI9MkG71tHOgVlhdUcuPsWvRRPpk7Tx27KlxsUR5iJprbmILjBriJMTpW6eNRkvA1gHWLJm/LURv/jdBPHePSZhmneI= 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, 05 Oct 2026 16:20:13 +0200 Message-Id: Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" , "Daniel P. Smith" , "Andrew Cooper" , "Michal Orzel" , "Jan Beulich" Subject: Re: [PATCH v3] common: dom0less-bindings: introduce XSM labels From: "Alejandro Vallejo" To: "Sergiy Kibrik" , "xen-devel@lists.xenproject.org" X-Mailer: aerc 0.17.0 References: <20261002102521.565675-1-Sergiy_Kibrik@epam.com> In-Reply-To: <20261002102521.565675-1-Sergiy_Kibrik@epam.com> X-ClientProxiedBy: MA3P292CA0056.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:48::14) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|CH1PR12MB9599:EE_ X-MS-Office365-Filtering-Correlation-Id: 128c1e92-71c1-456f-7919-08df22ebc759 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|18002099003|22082099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: 5Y1rPGA1VWpBw5F6odOcpJY0u7o/TirI/5lXyojq2XOhMx3h3TbJqPTFrLqD4OAkHB0ZdmOd727DKOOA42HJ3/n6WU/Tl1UoCYg1LiMnLwUy2TuNBWTYSudYVtCUEsZak9E9iqsaFTh1PVxumZdhywF6mBdC+2wlkg87Nx8plQfPTRS6nmbIq2hL7xpa2BP1EgRCzh1Gj0N4YeFWAiTyDOQLVLfiffpNm2IsVikMhPJvTKWt7TheqgSSTwnwyLQiGZOkUCf4LxwslnbiYL9G3i2lid0G7PGZ9dhK+EP2qq7UH+W0qqYZzjzZgFYewSw+MncjlLZ6Umrl0sVByuamydC7wiXWheY+YUj/GWzn2YpenTfm98CuTO1edzXEfcOIP51pmnT4AZgGUe3rboH2CHTIiJUJzn090GqDss9dV1FNggQAclc6RkM0VNBErxFSD3OOsfDSFH6T7oWvnkQyUhSpm9OmwMGoG49d2H8BJCNqi/dfUyEvgk7swwm7z0f8b6AiprwYIvbDXZT90CwzypDBYShiaH7Jh5oyYxJ9iU9oaFg98ugqKl/4skRHAYxM/blWmPqPqyqxUk64hGUiUEtQ6mZYHxXG+pNtV8iYTyq3q0sm+R2TLTpgpg6xOJgP3BgQZ5LyIpRi5f/84bXHiVwkpy53yJOI3aVJkuRTGrg= 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)(23010399003)(1800799024)(366016)(6133799003)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QUcxV1BnZGxnakVFT21obU1uMDR2eTBYTmZOeUJpVk5RWS9XMGVqazhGWVZS?= =?utf-8?B?d2lneUNGSktDcWluNSthMjNubG1hRThpVjlBaGMwTDltRE4yNEN4YlJpdng2?= =?utf-8?B?d28rK1BkK2R0QVdkcWFlVmdqUm9GNGt4UmV5a2w0TG9MUmxhNUJkVWFEdW9L?= =?utf-8?B?dy9NWTZFL3dOT2Fhb2RkYndKcENiTHlFYUZybTBpSVpFTXh3aHRuVCtKVlBs?= =?utf-8?B?UlpDajd0QS9kOG9sdWJ6cC9pbUZFelFsT09TSElWMGpya1FLdThodmljOG1x?= =?utf-8?B?S0RIcG85cXZUa2pVRklHL2NpUEw4NyszUkl2MlRKYmMzMmJ5MVFhUFhVaC9M?= =?utf-8?B?cWtNVXZ2eVc4ejVldmoyWlBtQWpUT2tjNERhS1VQekNoaTVWd0RqK0t5NUVP?= =?utf-8?B?UEJRWGh3MlhGUW1nZU1tVlVYRkU5QkVXOWtvOUU3L1dWODJZbm1NNDlrT0c3?= =?utf-8?B?NmNYUzhBdUQyZ2ltOVZYNlhLdmRmTWlDRzhMMWV6K3ljL3dhd0krR0lldXBP?= =?utf-8?B?cU9neUkxemxQaE1BRnFhZDZKa1R2R003R0c2cFMvc0hzK3pCaWF6TEwvVFEw?= =?utf-8?B?S3c1c3BmanlqeDR5b2tSYUxqN29lbU5XeWNKY0FxVHlNNDlmU0VTVUxsYk52?= =?utf-8?B?Y1NETmJCWU1TSXEyUUkxOXZ2WUVZYVJBK3NOWEc4NlZaY3FLbGlsK3pZTUww?= =?utf-8?B?Tk5HVUtGWTRnRk9GcjgydThvQUJKNnRNcmZHc00wQlZXT2RmbURmVXNjS2RL?= =?utf-8?B?MXZLd3VoK01HMXJIbGhnMmplVXpnUFZ0SnBRSHFpU3QzSnovQndwRjVzMHd3?= =?utf-8?B?RUdtNFV6eHBxTmRicmRYZUlQaFFkc0t4N3U3b3kyRFAxTUVsY2lRM2NNaDNZ?= =?utf-8?B?NXRKUFlacFVBZ2NIQ3JXZEdRZUZoY010TVpsT1o4RUprbVZIeTMwY0lTQm9L?= =?utf-8?B?MmdmV2lXM2d5Nm1Cdi9BajFRUjNZNFozd2ZqYmtPbXhrZ2tjL3l5R3pIbVNF?= =?utf-8?B?ZXpOMkhUMWNPQkpaekhndHM2b2ZqWE1zQjZTb2xjZkpuZXlQTXlCYUxtTkFT?= =?utf-8?B?NjJGaHdTYjNHL0NEbTdrOEJENHRvZ2RyS0U4cXpPbUFEODNSc2JCQ082ZndB?= =?utf-8?B?aGwrYTVZR0NuUmVWSEpnOFVlYnM4L2NxazRyd1BBSEMwSWtGcmZSYTVJbUgw?= =?utf-8?B?MGlnMWhKT1VLSWFXVXo5K2swbkxZTnk3TXVVYm9hL1FoYUMvcDZEanQzYzJM?= =?utf-8?B?bkcvOWxWQTJsZ2tWMHpGZWdzejZmYnJUMGgzNzJ0SEtzQndDRDljd3k3SmRi?= =?utf-8?B?WEtQTWQ1YnhCcG9PT0lxSzVscFQ0QjEwd0t1VHlOZVlYTmtqcjRucGZvOHNz?= =?utf-8?B?Z2g0YmNOdi84TUZWbnJCZ2ZYbkFaUmdtZWQvRmMzTDZYeU5qOGUvOTJMWEFz?= =?utf-8?B?STJwT1FzR3NTbTR3a1E2ZEhRZ1lSSXk4N0czK1VwZ1FmZHBadndqS1lJQVhH?= =?utf-8?B?bUg1bDdiWTVkZzBmQUl1QVhTTHFMbGFtQ21GQ3ZLcTI0UkJCR1BlT0I2ODlr?= =?utf-8?B?NHViK1RLY1N0Tmx3Tm5ZZENxaDRlcExaWnQ3a1huNlVySzMzUzUrQmpjeXZv?= =?utf-8?B?ZXA5d2ZEQTZXcm9pWTY1LzF1M3ozN0xBN1NzZVRpNUhMeG52UjY4a0NHTHVw?= =?utf-8?B?ZjdDZmVHblcwbjVzakI3M0FVdEMxR090RWpjZ1htVEp2Um1GcTJhT0lZS1Rv?= =?utf-8?B?TFhNcGtRYWdGYytTdDhua3RMZ1psUEtzT2ZSMDgwaUwvK2c1QjJLcWpjZkY1?= =?utf-8?B?Y1JEU0hjMmV1dGQxSW1Yd3FtWGJCN1F2bGVOa0IzNVJJRWFTTUdEbDMrbDFO?= =?utf-8?B?b0pCeDVYUUljOXBMc3FwNTBSLy9PMVhyNkQ3NmFhczNrTE40TnBFMXlMcmFR?= =?utf-8?B?c3ZUQmNGMis2S0NmZFI0cEZyQklFMDF0Sm5udXZ4TjFOTlpTaTl3c1BjMHc4?= =?utf-8?B?YlEyeHZwOEVwQ2lxd094TStpRzY3S1JvclllY0k2UWFDakp1aGdZdVlNQXJV?= =?utf-8?B?TWZJZFJWZDdwaDZ6cDBrK1dqRlFLM3pyaVV3S0hZZ20xUWtSTy8rRWRaS2ww?= =?utf-8?B?M3Q0b0JRbDdCUUkyK1YxQXlBWlRiQ3VLMGY1L08xR0ZUbmwvT0J3ZUFwamtl?= =?utf-8?B?NHRlRzJEUk1hQWp1T0hWZUhrU2szUmJpY2YxeUZGOEVxQnJTSXFFQXRsVjhG?= =?utf-8?B?aGhxcnpwZVpqRktLWFFMWS84Tk8ySzY4VmdUVjYwY0c4ZnNxTmU4Rzh4TStu?= =?utf-8?B?T1c3TzQ1aUlVMzRYekpVWUZiUmFTYlp5OEdUakRmZEFsM2k5YldSZz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 128c1e92-71c1-456f-7919-08df22ebc759 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 14:20:18.9155 (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: U10y2JKJAD50vA0f0KL72kG4rHw3tu0Bn6TOBHn94LH3Sjjzt4FCCPftf+AgbOjRvRNfFEsYVgiSxoN06iyM7Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9599 X-purgate-ID: tlsNG-ebf023/1791210027-C04DBB50-2CD332C1/10/78276251493 X-purgate-type: spam X-purgate-size: 5667 On Fri Oct 2, 2026 at 12:25 PM CEST, 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" l= abel > by default, which Flask denies to create according to current policy. > > Because code from outside of flask can't directly execute its internal AP= I > a new routine flask_context_to_sid() introduced as part of XSM API expose= d > 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 > CC: Michal Orzel > CC: Jan Beulich > --- > changes in v3: > - panic if `seclabel` property found but FLASK is disabled > changes in v2: > - add & use flask_context_to_sid() wrapper > --- > docs/misc/arm/device-tree/booting.txt | 7 +++++++ > xen/common/device-tree/dom0less-bindings.c | 13 +++++++++++++ > xen/include/xsm/xsm.h | 3 +++ > xen/xsm/flask/hooks.c | 5 +++++ > 4 files changed, 28 insertions(+) > > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device= -tree/booting.txt > index bcb06bc796..d04455b744 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -345,6 +345,11 @@ with the following properties: > not passed. This configuration requires static allocation (xen,stati= c-mem) > and direct mapping (direct-map). > =20 > +- seclabel > + > + A string property specifying an XSM security label to this domain. D= omains > + will be classified =E2=80=9Cunlabeled=E2=80=9D if this property not = specified. This paragraph assumes FLASK=3Dy, but many configurations of Xen do not shi= p it. Perhaps it would be prudent to state what happens (kaboom) when you load a DTB with this prop on a FLASK=3Dn hypervisor. > + > Under the "xen,domain" compatible node, one or more sub-nodes are presen= t > for the DomU kernel and ramdisk. > =20 > @@ -422,6 +427,7 @@ chosen { > memory =3D <0 131072>; > cpus =3D <2>; > vpl011; > + seclabel =3D "system_u:system_r:domU_t"; > =20 > vcpu0 { > compatible =3D "xen,vcpu"; > @@ -453,6 +459,7 @@ chosen { > #size-cells =3D <0x1>; > memory =3D <0 65536>; > cpus =3D <1>; > + seclabel =3D "system_u:system_r:domU_t"; > =20 > module@0x4c000000 { > compatible =3D "multiboot,kernel", "multiboot,module"; > diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/devi= ce-tree/dom0less-bindings.c > index 41d72d0d58..01d5cc1bc9 100644 > --- a/xen/common/device-tree/dom0less-bindings.c > +++ b/xen/common/device-tree/dom0less-bindings.c > @@ -11,6 +11,8 @@ > #include > #include > =20 > +#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 *n= ode, > bool has_dtb =3D false; > bool iommu =3D false; > const char *dom0less_iommu =3D NULL; > + const char *xsm_seclabel =3D NULL; > =20 > if ( !dt_device_is_compatible(node, "xen,domain") ) > return -ENOENT; > @@ -141,5 +144,15 @@ int __init parse_dom0less_node(struct dt_device_node= *node, > panic("'llc-colors' found, but LLC coloring is disabled\n"); > #endif > =20 > + if ( !dt_property_read_string(node, "seclabel", &xsm_seclabel) ) > + { > + if ( !IS_ENABLED(CONFIG_XSM_FLASK) ) > + panic("'seclabel' found, but FLASK is disabled\n"); > + else if ( flask_context_to_sid(xsm_seclabel, strlen(xsm_seclabel= ), nit: else if could be plain if > + &d_cfg->ssidref) ) > + panic("Invalid security context for domain: %s\n", > + xsm_seclabel); bad indentation of the panic statement. At the proper 4 blanks from the conditional branch, panic() fits in 80 lines. Fewer with s/Invalid/Bad/. > + } > + > return arch_parse_dom0less_node(node, bd); > } > diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h > index 9809e005e0..73d058a8b2 100644 > --- a/xen/include/xsm/xsm.h > +++ b/xen/include/xsm/xsm.h > @@ -261,4 +261,7 @@ static inline bool has_xsm_magic(paddr_t start) > =20 > #endif /* CONFIG_XSM */ > =20 > +int flask_context_to_sid(const char *scontext, > + uint32_t scontext_len, uint32_t *sid); nit: with s/context/ctxt/ this fits in a single line, otherwise... > + > #endif /* __XSM_H */ > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c > index d65ba0aeae..0b44a2a3d9 100644 > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -2016,6 +2016,11 @@ const struct xsm_ops *__init flask_init( > return &flask_ops; > } > =20 > +int flask_context_to_sid(const char *scontext, uint32_t scontext_len, ui= nt32_t *sid) ... this one needs to be split as it crosses the 80 columns boundary. > +{ > + return security_context_to_sid(scontext, scontext_len, sid); > +} > + > /* > * Local variables: > * mode: C Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Oct 05 14:43:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 14:43:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440912.1658436 (Exim 4.92) (envelope-from ) id 1xDjuS-0002WV-Q8; Mon, 05 Oct 2026 14:43:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440912.1658436; Mon, 05 Oct 2026 14:43: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 1xDjuS-0002WN-L7; Mon, 05 Oct 2026 14:43:20 +0000 Received: by outflank-mailman (input) for mailman id 1440912; Mon, 05 Oct 2026 14:43:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDjuR-0002WH-BI for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:43:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDjuQ-00Dl8Q-IX for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:43:18 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3b777-bab6-0a2a0a5309dd-0a2a4505bc78-4 for ; Mon, 05 Oct 2026 16:43:18 +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 6ac3b774-4cb1-0a2a45050019-b9ff1c129f6f-3 for ; Mon, 05 Oct 2026 16:43: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 1a10c848c9a0003f66.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 14:42:55 +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 E219581E07; Mon, 5 Oct 2026 16:42: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=Pe2+7r91QrtpgDUxoSoT90ds+FEVHjziNdH/cGFvhgo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=pC+XoJUmBNxyZY1zG2GHO6aZxs9D9KfZ0BfcuAtp9SEptZK1TB2u5lZ7HuGyXezXf9kXGZmMZ 1o5LyWXyAsFAmGs7LE1Wp7yVTOUXIAoBa9CDX7njM0XMgjVmNGhl9xrOSLsHJ32wL3LVugS8Ubz o252nHhaubeweYP61aMcMCuzdSBt+PWzkkaQr3qYFMpcSiwf5dYqycOaksmgpNwSFxCWzu4Y/2m uYeH1qMLexnNJU1qdVhkMyNMRp9coGcyclCqEhLKTp/fwjIN3e2sI75SEutcDLqQXRhnpfvgPnv qpKyq/DWNCpeaGNpYDQjkY7YwRbQ4mcd+W/tZ3FDqO7Q== X-Zone-Loop: 2091a6b1e30a6d80082ae2bd718e9e3ce783ddf2c512 x-campaign-type: default x-transaction-id: e12f5733-9902-43cb-aae4-10f3186c0f48 x-swg-uid: 01-a332c3f7-31fc-4ff1-ab1d-730fe7b53b10 X-Mailer: Sweego Message-ID: <1791211375.8631fc262581453bbf619ec5b2062170.1a10c848c9a0003f66@vates.tech> x-swg-bid: 1791211375.8631fc262581453bbf619ec5b2062170.1a10c848c9a0003f66 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] x86/shim: Report -ENOSYS instead of -EOPNOTSUPP Date: Mon, 5 Oct 2026 16:41:51 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.659.b22e3bd23c97d1dd.1a10c8489d6.edc8bb0d479e5fb4=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791211375062 X-purgate-ID: tlsNG-c201ff/1791211381-F4EA12A1-D83DF337/0/0 X-purgate-type: clean X-purgate-size: 1691 ---=Part.659.b22e3bd23c97d1dd.1a10c8489d6.edc8bb0d479e5fb4=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Main Xen reported -ENOSYS if the operation is not implemented, however, shim errorneously reported it as -EOPNOTSUPP, potentially confusing the guest=2E Make shim more consistent with Xen by reporting -ENOSYS instead=2E Fixes: 49f79fe03dfe ("xen/pvshim: add grant table operations") Fixes: 368ae9a05fee ("xen/pvshim: forward evtchn ops between L0 Xen and L2= DomU") Reported-by: Teddy Astie Suggested-by: Andrew Cooper Signed-off-by: Teddy Astie --- Found while running XTF tests using pv-shim with a modified xtf-runner=2E xen/arch/x86/pv/shim=2Ec | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/pv/shim=2Ec b/xen/arch/x86/pv/shim=2Ec index 41000b0523=2E=2E024c49c1b3 100644 --- a/xen/arch/x86/pv/shim=2Ec +++ b/xen/arch/x86/pv/shim=2Ec @@ -632,7 +632,7 @@ long pv_shim_event_channel_op(int cmd, XEN_GUEST_HANDL= E_PARAM(void) arg) =20 default: /* No FIFO or PIRQ support for now */ - rc =3D -EOPNOTSUPP; + rc =3D -ENOSYS; break; } =20 @@ -816,7 +816,7 @@ long pv_shim_grant_table_op(unsigned int cmd, break; =20 default: - rc =3D -EOPNOTSUPP; + rc =3D -ENOSYS; break; } =20 --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.659.b22e3bd23c97d1dd.1a10c8489d6.edc8bb0d479e5fb4=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 05 14:44:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 14:44:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440915.1658444 (Exim 4.92) (envelope-from ) id 1xDjvd-0002y7-1q; Mon, 05 Oct 2026 14:44:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440915.1658444; Mon, 05 Oct 2026 14: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 1xDjvc-0002y0-VB; Mon, 05 Oct 2026 14:44:32 +0000 Received: by outflank-mailman (input) for mailman id 1440915; Mon, 05 Oct 2026 14:44:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDjvb-0002xs-LW for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:44:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xDjva-00G52c-1O; Mon, 05 Oct 2026 14: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 1xDjvZ-002FTa-0r; Mon, 05 Oct 2026 14:44: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" 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=ncLUmgvO1QczMpEGUZAL50RUgZSjTQmdpcjCnPP3SAw=; b=unqtJ3LtKlyaM85jnJcWO7e1Dh 6WKlXhTXajrY036gHoHavBXdxquDZh2tMaefjfdqSUIuEV686fJgVFJvP7aVsrWVxZ113h9zozSSs eazjFD9VpJJYM/GcP8zqWmA6sF/n3EopyrpEmTGG9eWjU15IRS5ywvDv5oVPhwGLDQDU=; 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 v3] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests Date: Mon, 5 Oct 2026 16:43:17 +0200 Message-ID: <20261005144317.2887-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 XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit its setting in XENVER_get_features to the is_pv_domain() guarded section, with the rest of the PV specific features. Add an additional build time guard to short-circuit the setting of XENFEAT_pae_pgdir_above_4gb if the hypervisor has no PV 32bit support. Signed-off-by: Roger Pau Monné --- Changes since v2: - Add IS_ENABLED(CONFIG_PV32). --- xen/common/kernel.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/common/kernel.c b/xen/common/kernel.c index f4bbd8818fa8..499023fae6fd 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -677,8 +677,6 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) (1U << XENFEAT_vcpu_time_phys_area) | #endif (1U << XENFEAT_runstate_phys_area); - if ( VM_ASSIST(d, pae_extended_cr3) ) - fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb); if ( paging_mode_translate(d) ) fi.submap |= (1U << XENFEAT_writable_page_tables) | @@ -690,9 +688,13 @@ 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) | (1U << XENFEAT_highmem_assist) | (1U << XENFEAT_gnttab_map_avail_bits); + if ( IS_ENABLED(CONFIG_PV32) && VM_ASSIST(d, pae_extended_cr3) ) + fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb); + } else fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) | (1U << XENFEAT_hvm_callback_vector) | -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 14:53:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 14:53:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440925.1658453 (Exim 4.92) (envelope-from ) id 1xDk4T-0004ks-SA; Mon, 05 Oct 2026 14:53:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440925.1658453; Mon, 05 Oct 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 1xDk4T-0004kl-P7; Mon, 05 Oct 2026 14:53:41 +0000 Received: by outflank-mailman (input) for mailman id 1440925; Mon, 05 Oct 2026 14:53:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDk4T-0004kf-4u for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:53:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDk4S-003Alk-Hk for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:53:40 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3b9d8-bab6-0a2a0a5309dd-0a2a450a8776-30 for ; Mon, 05 Oct 2026 16:53:40 +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 6ac3b9f3-f2d2-0a2a450a0019-b9ff1c22a9f9-3 for ; Mon, 05 Oct 2026 16:53: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 1a10c8e56370003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 14:53: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 7A57D822C6; Mon, 5 Oct 2026 16:53: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=ZwjpMuD3dD57MrlsOKy3LAP82RZWtZIixknLFQvmnO4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Wqt3emVQGB3UCaKt0xR8NzSmyCP8EmcpqfiBvnVOUHOU9cqMoLE6x4w5Avr1AIg567uONPIIV 3UPPkr9IzCDE6LsaiYyxWp078JhoP/qj4YDD5nFTh8cO4xTGDid9PBf5FPAC9psNwrK6AoWxLKr bhEfNa7kzxYc9CunW258p+8k1PHu31XfoMANZHIpQn7ygJwIrN8bwWmnxrfjNZKL6b7AapxF2e6 Ku3fOliwvnZAodk0d0bvctGdQLpUSFhe4jmhMKVyhyRvb4M988u24oaZ72d6AQ78z5UmDY8q/7x 4vvp/aCi174GTzcLjhFfg2ThJ5/dD4f3mdq2pfeZPheA== X-Zone-Loop: 8ec3ef9587124b76650f64ab85364d5103f65fda136d x-campaign-type: default x-transaction-id: ed6863e1-72bb-48e2-8aac-b25f129ca312 x-swg-uid: 01-d6ec714d-384c-44c4-9271-3a2a9bda3ebf X-Mailer: Sweego Message-ID: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e56370003f66@vates.tech> x-swg-bid: 1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e56370003f66 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 v3 07/39] xen/riscv: introduce CPU_NONE 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: Mon, 05 Oct 2026 16:53:30 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791212011; l=1408; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=DVpF4XmuD3vIbw0CPe5ayj74ZGG/78GS69wrRuKHW4k=; b=P/ifraCcbY4/ZNMZkC0mTIGFfw3ULzOsZ4HRISpQMkaAreWiOYGvQ/Kx4xxufSQcXPko2n4/M hNevP9cDIxQCFBnXibg/y34aOymsKKDBgtVq6miPYbDDLU1EbQauz6o 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: 1791212016707 X-purgate-ID: tlsNG-4011c0/1791212020-599C1CFC-DC7C58C2/0/0 X-purgate-type: clean X-purgate-size: 1408 > Introduce CPU_NONE, a CPU number which doesn't identify any physical > CPU, to be used wherever a pCPU has to be recorded but there may be > none. > > Its first user is vsfile_cpu in struct vimsic_state, which records the > pCPU whose h/w guest interrupt file backs the vCPU's IMSIC VS-file. > NR_CPUS has been used there as the value meaning that there is no such > pCPU, i.e. that the s/w VS-file is in use. NR_CPUS is however an upper Nit: It's hard to understand when reading the message why s/w is mentioning. I'd reword it to: ``` NR_CPUS has been used there to mean that no h/w guest interrupt file is attached (i.e. the vCPU uses the s/w VS-file), so there is no pCPU to record. ``` > bound rather than a "no CPU" marker, and it already carries other > meanings: hartid_to_cpuid() returns it for a hart Xen doesn't know, and > pcpu_info[] uses it for an entry whose processor_id isn't valid yet. > Use CPU_NONE for vsfile_cpu instead, so that the s/w VS-file case can't > be mistaken for any of those. Nit: Same as above, I'd prefer something like: ``` Use CPU_NONE for vsfile_cpu instead, so that "no h/w guest interrupt file attached" can't be mistaken for an unknown hart or a not-yet-valid pcpu_info[] entry. ``` Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 14:53:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 14:53:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440926.1658461 (Exim 4.92) (envelope-from ) id 1xDk4b-0004ys-2j; Mon, 05 Oct 2026 14:53:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440926.1658461; Mon, 05 Oct 2026 14:53: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 1xDk4a-0004yl-Vc; Mon, 05 Oct 2026 14:53:48 +0000 Received: by outflank-mailman (input) for mailman id 1440926; Mon, 05 Oct 2026 14:53:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDk4Z-0004y0-JO for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:53:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDk4Y-002r38-H5 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:53:46 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3b9ee-2eae-0a2a0a5409dd-0a2a4508b0d2-30 for ; Mon, 05 Oct 2026 16:53:46 +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 6ac3b9fa-f659-0a2a45080019-4a7de18cb17a-3 for ; Mon, 05 Oct 2026 16:53:46 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49fff72474fso13188385e9.3 for ; Mon, 05 Oct 2026 07:53: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-4a02854073csm318301535e9.3.2026.10.05.07.53.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 07:53: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=1791212026; x=1791816826; 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=/zg5WP4q4WzOI6ts6VftupUgXE26i4tuaBfvOcS8VNQ=; b=ZnelNsBb12QhWRSiUdSwbDUbsT4fAAn+HbhrMRYdlgdOpffbnPWOIZUNItPLjmM8Ra BMWexOxYZ4b6P/RqF5Nyax6+Tg6IpBcD0tuRUzkpY3m/rfKlhYno+JTLc+WHl8ci3H7x i0a5oPkNS5ZiJNtxvYs+gdWKvw7umBd370GniyGiovCXhjgyMfTeoyIvNqydWeAy8gFh BInSgfFKnucKJTUL0cOBVbRLqUpIaTk2q2HPfGnQzI7HBfCerqzX0TaZNYn62KvbE3IN kTOtTiJwmEgYxR3r7sP27cabsnCm6Ltynpo6S7snci5+csfiI73/oWPMW60AHyVwxk+v ax8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791212026; x=1791816826; 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=/zg5WP4q4WzOI6ts6VftupUgXE26i4tuaBfvOcS8VNQ=; b=E+BaJ2UkTBrHXXG3ZdwaIZUhR3S8pr4or4eYmbRaRXwtzL0IPJ88KACTtJZNZQNG/Q Cd0YM8Ynbg85iME8ttJZnjFcSd8z4EaPgLZ5XFxyl//4su9P+jBRsLHO5DjxBv3G891X jxF1DEUw3hvDK8NtSVS081yNbA7pYWksYkWkPr4q60b9pEZwrkGhSYwupvgL27xmncRi 5vuxo/bBI78D+rreje+QpC++S3aOcqrIi0gQKjbfKJkiBhx/rs4EV55SNPdOVQyVt0ma mAjn/oJJqeY68rUjbfMv3Ovb4RRTOVyPUooxD/2NdYAWnXKa/Kd8JZ7DRiRprnwPbrw7 cMGA== X-Gm-Message-State: AFuF++kEBHOHqxIOoM+wlBhoP3UVVLpXrrzrVf6U+lhntojp8WUz4s8U s2OtG7kUvSeo2D847LLX1XV20JUjjvBKbinuAdfEPME2cA24AaTZO4pxI1OoDFb30w== X-Gm-Gg: AYBFou29dtg8PoBHa3C1j/2nhpD+uYB9LPmRKsi23K6+p+6qTsY6RTUjaL8BZ9f4qb1 zHmUo46Y7v3O0oO6hYif/jLZmvkvO2xTIFbsApDMlp+QbLHCf05OnJrKtyF1y59+MaqPH9KFLGZ qdzv9B5Qte2oQM2wg6riY8Tk6i/jfczuk6A5uxqisGmSzRM6f4+esSxDQVWXoYCMeopA6w4hUjz HQ3HTJphWnkaAfkodJqEiXINqngH59af73uq8nP2mHaQi06UhgEd7W9pQLNWdFYDEKv9aYEB9P3 Z//dgP6lYj2++P83rxxoG5bAt7GuX7/z0g7iINrwK1qftJBXKTUwwbYZw8Y8pw+kakwS3YDxpFh +hu0eESwxWl//B3gw7VeFVvISJEeCj8MoSWc2X9BneMn5Utu8OBi7+ruYwWLNY0aGD45T0bR3v8 dj56xc0xYwx/20JqJo0OBQq6yTEn+kZ5gppmfPlEtdAmdf0Bb0rrn0PfFOyxVIfcBFh7VPgxZWh 1tnQ2dKc8R5bU4yCGB1QdtVtBilBj8A0F4yA5kW3B2X35KwQUBCbOwrbN5wD1EPmPi352i216w= X-Received: by 2002:a05:600c:a011:b0:49f:ce78:356f with SMTP id 5b1f17b1804b1-4a0276b869fmr165154345e9.32.1791212025604; Mon, 05 Oct 2026 07:53:45 -0700 (PDT) Message-ID: Date: Mon, 5 Oct 2026 16:53:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] EFI: refine cfgfile buffer allocation From: Jan Beulich To: Marek Marczykowski , Daniel Smith Cc: "xen-devel@lists.xenproject.org" References: <7e332eec-5c5c-4c1b-aeeb-c65e046b1318@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: <7e332eec-5c5c-4c1b-aeeb-c65e046b1318@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1791212026-D4F4F87B-505D3613/10/78276251493 X-purgate-type: spam X-purgate-size: 2273 On 21.09.2026 11:09, 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 May I please ask for maintainer feedback regarding this patch? If this small variant is acceptable, I'd like to get it in. If the larger form Ross suggested is going to be a requirement, I'd like to know so I can plan the re-work accordingly. Thanks, Jan > --- 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 Oct 05 14:53:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 14:53:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440927.1658467 (Exim 4.92) (envelope-from ) id 1xDk4b-000512-BR; Mon, 05 Oct 2026 14:53:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440927.1658467; Mon, 05 Oct 2026 14:53: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 1xDk4b-00050J-6f; Mon, 05 Oct 2026 14:53:49 +0000 Received: by outflank-mailman (input) for mailman id 1440927; Mon, 05 Oct 2026 14:53:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDk4Z-0004xs-JM for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 14:53:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDk4Y-002r38-Cb for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:53:46 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3b9ce-2eae-0a2a0a5409dd-0a2a4505eae2-40 for ; Mon, 05 Oct 2026 16:53:46 +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 6ac3b9f9-4cb1-0a2a45050019-b9ff1c23a875-3 for ; Mon, 05 Oct 2026 16:53: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a10c8e58370003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 14:53: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 DCC66822E7; Mon, 5 Oct 2026 16:53: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=dEs1DO6iBwGLd3lKy4Jju50N+3ZaDo1LeTi18JrvneQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=RcHh0dOkVaC2ux7YZ9LcKopfyim0ju1U8Q/8Y+/TGDhrYHYx2xSK2DF0aCPv61VJ63cYJJRhn 4cnXq8bxDYRNhMwOOUqS1+z/frlZVHoBPPfscC6haW/d8czUcJWmywM7zOhQBqNIwvngORlAG/Y nGb7aERo20mZRytrZKbC6Odqg1a5t7jJVdYUkNoWNod70jaC56KlJMPYj6S+mutMqHPRHRy37Kl Y/Q5AboFZ8H8p/di7GwD0Ym3Hxg3/Vjl9rtVSDRxeQOF/WMqSWGHwZwNC2hK1F7TLQq+STmydq/ tZD+M1E7L87H7vuLclck+lF7PYvx4Z8olxILkT+4CdFg== X-Zone-Loop: 332918cd9e293d554ec36147713fc3f3ffbb25712c7d x-campaign-type: default x-transaction-id: 51d1a542-347d-449a-b184-643bb46f61b2 x-swg-uid: 01-d4e27ef3-bf9c-4f2a-a84f-22f329ad3e4a X-Mailer: Sweego Message-ID: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e58370003f66@vates.tech> x-swg-bid: 1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e58370003f66 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 v3 08/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: References: Date: Mon, 05 Oct 2026 16:53:30 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791212011; l=38668; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=6ar0c/wvBKgkYrmU92rBAEwOb7qWr+QofQeydvv8nrA=; b=aiN50mULOSFR7MhIX0VB3qUaj0w52RA73NhhEbAk1pScHS8quyr0Eqv3rhfhxF/QWYt6Kcv53 z684Fun4zPsDO9ckJUXw1hxg5q0/ncfjwCRL/KH8YdpSKV7KeCV0t+I 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: 1791212017107 X-purgate-ID: tlsNG-c201ff/1791212026-736BD2A1-5C2A79C0/10/73395122804 X-purgate-type: spam X-purgate-size: 38668 > 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. > > Register the vAPLIC range with the MMIO dispatch and emulate the accesses: > - reads and writes are masked with the domain's authorised interrupt > bitmap, so that a guest can neither observe nor affect interrupts it > does not own; > - target registers are shadowed per source, so that a guest reads back > what it wrote. The h/w register instead gets the hart index and guest > interrupt file of the pCPU the target vCPU's interrupt file lives on, > as the APLIC uses these fields directly to compute the MSI address. As > long as the target vCPU has no h/w guest interrupt file, only the > shadow copy is updated; > - only MSI delivery mode is emulated: target writes made while the > guest's domaincfg.DM is clear are ignored. > > Delegation (APLIC_SOURCECFG_D) is not yet supported. > > Co-developed-by: Romain Caritey > Signed-off-by: Oleksii Kurochko Co-developed-by: needs a matching Signed-off-by: from Romain right after it. > --- > Changes in v3: > - sourcecfg store emulation: mask the guest value with the new > APLIC_SOURCECFG_WMASK (D and SM are the only implemented fields, all the > other bits are reserved and read as zero) instead of rejecting the write > when the value is above APLIC_SOURCECFG_SM_LEVEL_LOW. The dropped check > compared the whole value against 7 rather than the SM field, so a legal > SM with anything set in the reserved bits 9:3 was rejected. SM is WARL > and vAPLIC keeps no shadow copy of sourcecfg[], so a reserved SM value > is left to the h/w to normalize; add a TODO covering what will have to be > emulated here once sourcecfg[] is shadowed. > - Introduce APLIC_SOURCECFG_WMASK in asm/aplic.h. > - target store emulation: reword the comment about a non-zero guest index > to say that such a write is illegal and is therefore ignored as a whole, > that the shadow copy keeps the zero it was allocated with, and that > aplic_msi_target_gen() overwrites the field with vcpu_guest_file_id() > anyway. Drop the now-redundant "Ignore such writes ..." comment. > - s/aplic_hart_field/aplic_hart_index/ (and the local variable with it): > the value is the APLIC "Hart Index", not a field of it. > - Clarify the MSI target address documentation above aplic_hart_index(): > name the Guest Index in the address formula, say that the APLIC computes > the MSI target address itself in MSI delivery mode, and label the two > parts of the 14-bit Hart Index field as g and h to match the surrounding > text. > - Don't add the MSI target address scheme diagram to asm/imsic.h: it > would duplicate the one documented above aplic_hart_index(). > - Fix the comment on APLIC_TARGET_IPRIO: the field exists when the target > is in direct delivery mode (domaincfg.DM = 0), not "in DM mode". > - Rearrange the case blocks of vaplic_emulate_load() and > vaplic_emulate_store() primarily by register offset: APLIC_DOMAINCFG > comes first and APLIC_SOURCECFG handling directly follows it; the > set/clr-num registers are also listed in offset order. No functional > change. > - Rename the first parameter of aplic_msi_target_gen() from target_vcpu > to v. > - Use a const-qualified pointer in aplic_hw_read_reg()'s cast to match > readl()'s prototype. > - Put APLIC_xMSICFGADDR_PPN_HHX_MASK(), APLIC_xMSICFGADDR_PPN_LHX_MASK() > and APLIC_xMSICFGADDR_PPN_LHX_SHIFT() on a single line each. > - Use gdprintk() instead of dprintk() for guest-triggered messages in > vaplic.c and drop the redundant "is passed" from the word_idx message. > - Call domain_vaplic_deinit() in both failure paths of > domain_vaplic_init() instead of open-coding the clean-up. > - aplic_msi_target_gen() takes the hart index from the pCPU the vCPU's > interrupt file lives on (vsfile_cpu) instead of v->processor, which may > already name the new pCPU while the vCPU is being migrated. Callers > have to hold vsfile_lock until the value is written to the h/w, which > the vAPLIC target write path now does. > - A target register write for a vCPU which has no h/w guest interrupt file > yet (its vsfile_cpu is CPU_NONE) only updates the stored copy; the h/w > register isn't programmed, as there is neither a hart nor a guest > interrupt file to point it at. Add a TODO about s/w guest interrupt > files, for which the h/w register will have to be written too. > - Turn vaplic_regs.target[] into vaplic_regs.sources[], an array of > struct vaplic_source holding the guest's view of the target register > together with a per-source lock which keeps the stored copy and the h/w > target register updated as a pair. Document how many elements it holds > and why index 0 is unused. > - Drop the emulation of target register writes in direct delivery mode: > such writes are ignored with a one-time warning. Resolve the target > vCPU only in the MSI delivery mode path, where it is used. > --- > Changes in v2: > - Shadow the guest-written target registers in a per-domain array and > serve reads of APLIC_TARGET_* from it: the hardware register holds the > value produced by aplic_msi_target_gen() (physical hart field, VS-file > id), so reading it back would expose the host layout and return > something the guest never wrote. A non-zero guest index is dropped with > a one-time warning instead of being echoed back. > - aplic_hart_field(): take a CPU id instead of a hartid and derive both > the group and the hart index from msi->base_addr + msi->offset - the > hart index bits are a part of that offset, so the hartid can't be used > as the hart index. Add APLIC_xMSICFGADDR_PPN_LHX_{MASK,SHIFT} for that. > - Document the IMSIC MSI target address layout and the APLIC hart index > packing above aplic_hart_field(), and correct the corresponding diagram > in asm/imsic.h. > - Drop the mask parameter of aplic_hw_read_reg() and apply the > authorization mask in vaplic_emulate_load() instead. > - vaplic_emulate_{load,store}(): return bool instead of int, rename v/d to > curr/currd and add ASSERT(curr == current). > - Use domain_vcpu() instead of open-coded d->vcpu[] indexing when > resolving the target hart index. > - s/APLIC_REG_OFFSET_MASK/APLIC_CTRL_REGION_OFFSET_MASK/. > - Update store emulation handling for target register to be able to deal > with target format in both cases (MSI and Direct). > - Update store emulation handling of domaincfg. There is no need to force > DM/IE mode here (it will be forced/checked on Xen irq handler side). > - Rename APLIC_DEFAULT_PRIORITY and move to aplic.h as default prioity > value is used in vaplic code too now. > --- > --- > xen/arch/riscv/aplic-priv.h | 2 + > xen/arch/riscv/aplic.c | 138 +++++++++- > xen/arch/riscv/include/asm/aplic.h | 37 +++ > xen/arch/riscv/include/asm/vaplic.h | 19 ++ > xen/arch/riscv/vaplic.c | 384 +++++++++++++++++++++++++++- > 5 files changed, 575 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h > index 35100d3a64..2245029b10 100644 > --- a/xen/arch/riscv/aplic-priv.h > +++ b/xen/arch/riscv/aplic-priv.h > @@ -47,4 +47,6 @@ struct aplic_priv { > */ > extern unsigned int guest_aplic_num_sources; > > +uint32_t aplic_msi_target_gen(const struct vcpu *v, 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 17c96177a3..febc451760 100644 > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include Nit: sorts before . > #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,137 @@ 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: Sorry but as I already mentioned before, Hart Index is equal to (g << lhxw) | h I think it is a miss as you explained this later correctly .... I would propose this: ``` * The physical address of an outgoing MSI is calculated by bitwise ORing a * Base Physical Page Number (Base PPN) with the group number (g), the * hart number relative to the group (h) and, for a supervisor-level * interrupt domain, the Guest Index: ``` > + * > + * ( 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. ... here > + * - 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 > + * 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_index(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; > +} > + > +/* > + * v->processor can't be used here: during a migration it names the new pCPU > + * before the interrupt file is moved there. The caller has to hold > + * vsfile_lock until the result is written to the h/w. > + */ > +uint32_t aplic_msi_target_gen(const struct vcpu *v, uint32_t base_val) > +{ > + const struct vimsic_state *vimsic_state = v->arch.vimsic_state; > + unsigned int guest_id = vcpu_guest_file_id(v); > + unsigned long hart_index; My v2 remark about making hart_index const can be dropped: as Jan said (<02cb695f-c827-4623-8f65-530bd7b740d6@suse.com>), const is wanted on pointer targets, not on plain variables. > + > + ASSERT(rw_is_locked(&vimsic_state->vsfile_lock)); > + ASSERT(vimsic_state->vsfile_cpu < NR_CPUS); > + > + hart_index = aplic_hart_index(vimsic_state->vsfile_cpu); > + > + base_val &= APLIC_TARGET_EIID; > + base_val |= MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX); > + base_val |= MASK_INSR(hart_index, 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))); Nit: the parentheses around offset < aplic.size aren't needed: ASSERT(offset < aplic.size && IS_ALIGNED(offset, sizeof(uint32_t))); > + > + spin_lock_irqsave(&aplic.lock, flags); > + val = readl((const 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))); Same here. > + > + 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 +183,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..664bda2cb7 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 > @@ -58,6 +65,12 @@ > #define APLIC_SOURCECFG_SM_EDGE_FALL 0x5 > #define APLIC_SOURCECFG_SM_LEVEL_HIGH 0x6 > #define APLIC_SOURCECFG_SM_LEVEL_LOW 0x7 > +/* > + * 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) > > #define APLIC_SMSICFGADDR 0x1bc8 > #define APLIC_SMSICFGADDRH 0x1bcc > @@ -89,6 +102,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 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 +114,24 @@ > #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 +175,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/vaplic.h b/xen/arch/riscv/include/asm/vaplic.h > index 96080bfbc2..3a555742bb 100644 > --- a/xen/arch/riscv/include/asm/vaplic.h > +++ b/xen/arch/riscv/include/asm/vaplic.h > @@ -11,6 +11,7 @@ > #define ASM__RISCV__VAPLIC_H > > #include > +#include > #include > > #include > @@ -19,13 +20,31 @@ struct domain; > > #define to_vaplic(d) container_of((d)->arch.vintc, struct vaplic, vintc) > > +/* State of one vAPLIC interrupt source. */ > +struct vaplic_source { > + /* Protects target together with the h/w target register of the source. */ > + spinlock_t lock; > + > + /* Guest's view of the APLIC target register. */ > + uint32_t target; > +}; > + > struct vaplic_regs { > uint32_t domaincfg; > + > + /* > + * Indexed by source number. The array holds d->arch.vintc->nr_virqs > + * elements; sources[0] is unused as APLIC interrupt sources start from 1. > + */ > + struct vaplic_source *sources; > }; > > 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 6fbdc07805..ea4b0dc889 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,313 @@ 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.sources[irqn].target); > +} > + > +static inline uint32_t generate_auth_mask(const struct domain *currd, Nit: inline in a .c file isn't needed, the compiler decides anyway. > + 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)\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; With that, every access with addr >= APLIC_CTRL_REGION_OFFSET_MASK aliases onto the same control region: e.g. an access to GUEST_APLIC_S_BASE + 0x4000 (idelivery of IDC 0) ends up in the APLIC_DOMAINCFG case, and a store there rewrites domaincfg. It also silently relies on GUEST_APLIC_S_BASE being 16 KiB aligned. The AIA spec ("Memory-mapped control region for an interrupt domain") says IDC structures start at 0x4000 and are only needed for direct delivery mode, and that all other bytes of the control region are reserved and read-only zero, writes to them being ignored. So I'd expect something like: const paddr_t offset = addr - vaplic->regs_start; Then read/write out of control region would go to "default:" case. and APLIC_CTRL_REGION_OFFSET_MASK could go away. > + uint32_t auth_mask; > + unsigned int i; > + > + ASSERT(curr == current); > + > + switch ( offset ) > + { > + case APLIC_DOMAINCFG: > + *out = vaplic->regs.domaincfg; > + > + 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_SETIPNUM: > + case APLIC_CLRIPNUM: > + case APLIC_SETIENUM: > + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: > + case APLIC_CLRIENUM: > + case APLIC_SETIPNUM_LE: > + /* > + * Based on the RISC-V AIA spec a read of these registers > + * always returns zero > + */ > + *out = 0; > + > + return true; > + > + 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; genmsi (0x3000) isn't covered by any case, so an access to it ends up in default: and faults while in MSI delivery mode it isn't read-only zero: Hart Index and EIID behave as in a target register, and Busy is read-only. I would suggest to add a dedicated switch case: ``` case APLIC_GENMSI: *out = vaplic_is_msi_mode(currd) ? vaplic->regs.genmsi : 0; return true; ``` With a new helper vaplic_is_msi_mode -> bool that could also be used in write counterpart and a new genmsi field in vaplic->regs. If we assume the guest will never try to read genmsi then it is okay but it might worth to at least mention it somewhere. > + 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; Same aliasing issue as in vaplic_emulate_load(), here with the write going to the aliased register. > + > + ASSERT(curr == current); > + > + switch ( offset ) > + { > + case APLIC_DOMAINCFG: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + > + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | > + (value & APLIC_DOMAINCFG_WMASK); APLIC_DOMAINCFG_WMASK includes DM, so a guest writing DM=0 reads 0 back and assumes direct delivery mode is in effect. However, only MSI delivery is emulated: there are no IDC structures, and with DM=0 the target handling below drops the write, so the guest just stops getting interrupts. DM is WARL, so an MSI-only APLIC is expected to keep it at 1 whatever is written, which is how software figures out that direct mode isn't available. Can't we do the same here, as is already done for BE? I.e. drop DM from APLIC_DOMAINCFG_WMASK, and OR APLIC_DOMAINCFG_DM in here and in domain_vaplic_init(). That would also justify sizing the region at APLIC_MIN_SIZE (see my comment on regs_size at the end). > + > + return true; > + } > + > + 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 ) > + { > + gdprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); > + > + 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 > + * 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; > + > + break; > + > + 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_SETIPNUM: > + case APLIC_CLRIPNUM: > + case APLIC_SETIENUM: > + case APLIC_CLRIENUM: > + case APLIC_SETIPNUM_LE: > + if ( !value || !AUTH_IRQ_BIT(currd, value) ) > + return true; > + > + break; > + > + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + /* > + * 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; > + > + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) > + { > + struct vaplic_source *src = &vaplic->regs.sources[srcn]; > + struct vcpu *target_vcpu; target_vcpu is only read, so this can be const struct vcpu *. > + unsigned int guest_hart_idx = > + MASK_EXTR(value, APLIC_TARGET_HART_IDX); > + unsigned long flags; > + struct vimsic_state *vimsic_state; > + > + 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; > + } > + > + vimsic_state = target_vcpu->arch.vimsic_state; > + > + /* > + * 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. > + */ > + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) > + { > + printk_once(XENLOG_WARNING > + "%pd: vAPLIC target guest index != 0 is unsupported\n", > + currd); > + > + return true; > + } > + > + /* > + * src->lock keeps the stored copy and the h/w register updated > + * as a pair. > + */ > + spin_lock_irqsave(&src->lock, flags); > + > + write_atomic(&src->target, value); > + > + /* IRQs are already off under src->lock. */ > + read_lock(&vimsic_state->vsfile_lock); > + > + /* > + * The h/w register names the hart and the guest interrupt file > + * MSIs are sent to, and there is none of either until the target > + * vCPU is given a h/w guest interrupt file. The stored copy > + * reaches the h/w at that point. > + * > + * TODO: once s/w guest interrupt files are supported, a vCPU using > + * one still needs its MSIs, so the h/w register will have to be > + * written for it too, pointing at an interrupt file Xen receives > + * them in on the vCPU's behalf. > + */ > + if ( vimsic_state->vsfile_cpu != CPU_NONE ) > + aplic_hw_write_reg(offset, > + aplic_msi_target_gen(target_vcpu, value)); The comment above says the stored copy reaches the h/w once the vCPU gets a h/w guest interrupt file, but nothing in this patch does that: it only happens with vaplic_reconfigure_target(), added by "xen/riscv: introduce vaplic_reconfigure_target()" and called from imsic_vsfile_move() by "xen/riscv: remap interrupts to new IMSIC VS-file". At this commit a target written before the first attach never reaches the h/w. > + > + read_unlock(&vimsic_state->vsfile_lock); > + > + spin_unlock_irqrestore(&src->lock, flags); > + > + return true; > + } > + > + /* printk_once(), as a guest could otherwise flood the log. */ > + printk_once(XENLOG_WARNING > + "%pd: vAPLIC direct delivery mode isn't supported\n", > + currd); > + > + return true; > + } > + > + default: > + fail: > + gdprintk(XENLOG_WARNING, > + "Unhandled APLIC write at offset %#x (value %#x)\n", offset, > + value); Nit: now that the arguments wrap, put offset on its own line as well. > + > + return false; So in this function you are assuming the guest will never try to write genmsi. Is it expected? so a guest accessing it faults. Linux doesn't use it today, but the spec defines it in MSI delivery mode. Could it at least get an explicit case (reads as zero, writes ignored, with a TODO about extempore MSI injection) rather than relying on guests never touching it? > + } > + > + aplic_hw_write_reg(offset, value); > + > + return true; > +} > + > static int __init cf_check vaplic_make_domu_dt_node(struct kernel_info *kinfo) > { > struct domain *d = kinfo->bd.d; > @@ -95,6 +403,56 @@ static const struct vintc_init_ops __initconstrel init_ops = { > .make_domu_dt_node = vaplic_make_domu_dt_node, > }; > > +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, > + mmio_info_t *info) Jan asked in v1 to rename the parameter to curr once ASSERT(v == current) is added. Same for vaplic_mmio_write(). > +{ > + uint32_t val; > + > + ASSERT(v == current); > + > + if ( info->len != sizeof(uint32_t) || > + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) > + { > + gdprintk(XENLOG_DEBUG, > + "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n", > + info->gpa, info->len); > + return IO_ABORT; Please drop the "VAPLIC:" prefix, gdprintk() already says where the message comes from. Also a blank line before the return, as you do elsewhere in the file. > + } > + > + if ( !vaplic_emulate_load(v, info->gpa, &val) ) > + return IO_ABORT; > + > + /* APLIC registers are 32-bit; zero-extend to the guest register width. */ > + info->data = val; > + > + return IO_HANDLED; > +} > + > +static enum io_state cf_check vaplic_mmio_write(struct vcpu *v, > + const mmio_info_t *info) > +{ > + ASSERT(v == current); > + > + if ( info->len != sizeof(uint32_t) || > + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) > + { > + gdprintk(XENLOG_DEBUG, > + "VAPLIC: unaligned/wrong-width write gpa=%"PRIpaddr" len=%u\n", > + info->gpa, info->len); > + return IO_ABORT; Same here. > + } > + > + if ( !vaplic_emulate_store(v, info->gpa, info->data) ) > + return IO_ABORT; > + > + return IO_HANDLED; > +} > + > +static const struct mmio_handler_ops vaplic_mmio_ops = { > + .read = vaplic_mmio_read, > + .write = vaplic_mmio_write, > +}; > + > static const struct vintc_ops vintc_ops = { > .vcpu_init = vcpu_imsic_init, > .vcpu_deinit = vcpu_imsic_deinit, > @@ -103,6 +461,8 @@ static const struct vintc_ops vintc_ops = { > int domain_vaplic_init(struct domain *d) > { > struct vaplic *vaplic = xvzalloc(struct vaplic); > + unsigned int i; > + int rc; > > if ( !vaplic ) > return -ENOMEM; > @@ -123,7 +483,28 @@ 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.sources = xvzalloc_array(struct vaplic_source, > + d->arch.vintc->nr_virqs); > + if ( !vaplic->regs.sources ) > + { > + domain_vaplic_deinit(d); > + > + return -ENOMEM; > + } > + > + for ( i = 0; i < d->arch.vintc->nr_virqs; i++ ) > + spin_lock_init(&vaplic->regs.sources[i].lock); > + > + vaplic->regs_start = GUEST_APLIC_S_BASE; > + vaplic->regs_size = APLIC_SIZE(d->max_vcpus); The vAPLIC only supports MSI delivery (msi-parent → vIMSIC, no direct mode emulated), so no IDC structures are needed and APLIC_MIN_SIZE is enough. To make that explicit I'll also hardwire domaincfg.DM to 1 (WARL), so the guest can't select a mode the region doesn't back. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 15:05:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 15:05:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440946.1658479 (Exim 4.92) (envelope-from ) id 1xDkFe-0007mY-D0; Mon, 05 Oct 2026 15:05:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440946.1658479; Mon, 05 Oct 2026 15: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 1xDkFe-0007mR-AK; Mon, 05 Oct 2026 15:05:14 +0000 Received: by outflank-mailman (input) for mailman id 1440946; Mon, 05 Oct 2026 15:05:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDkFd-0007mL-PJ for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:05:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDkFd-0020tX-61 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 17:05:13 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3bc9f-e002-0a2a0a5209dd-0a2a4504d6ce-12 for ; Mon, 05 Oct 2026 17:05:08 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3bca4-b57f-0a2a45040019-d155dd32dda3-3 for ; Mon, 05 Oct 2026 17:05:08 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48b03f23305so1663063f8f.1 for ; Mon, 05 Oct 2026 08:05: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-48c62270751sm4130112f8f.13.2026.10.05.08.05.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 08:05: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=1791212708; x=1791817508; 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=l1WwakrSeNK7CtSZLjDPd9Zm+HQjR666BEiZawESMAY=; b=BiuOOUBTMpTnJM05UKf09UJSt11XM4BHWJoIvqkgAP15sHrCdiSTlWsWlH1BRwNb8o p7BXB5R8G1a76FztmtR/tSddF/2TakXfpbLktvhD+J35u8OS6BoMzEIpwoEVVDqJwc1D AsMYRD4Ofw0sY/oWYEHjymzeLX0alrdDXUK9pwX8tHdNV/NOjPg8hNJ7lB6lQgOAxzRu vnv7jJy7zA3BuD/VyUvvNns96qxIHgc2FsKZOwDTYkwIr8SYfUEie3RrwSnEWAHwNqjf c2BfE4/kUcxMz8KyTHWtLJz0pkOpHaKvxbpg1bbaA8uHZ8/zORJlbSCUiXLPm+ufpaVy G1AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791212708; x=1791817508; 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=l1WwakrSeNK7CtSZLjDPd9Zm+HQjR666BEiZawESMAY=; b=vN/4ATY2tUZdh0A9xXgcRfZLyg89lEMdVGHdiXz4UkyVvYeRAW0Q3OGuD3TIvk9Him V1+Z9ZNM9BqNIyiHpMtr+XKBsJrumWR4nKFkr+X/8e1n8GQSi6AHHL6OqU8ac4ueZzlS CWgvSg8LoQijGaOJxFnPlnAiQXq3ERUGqnDuL5bNGwMjvDmZWiioW0XFkflR8BANtebJ ikC4r9RYC3JOV8E1N6WJDMzvyQXWtjk+WPvpHbPeXnbcVnMyTSIBIXFMGkGPgpNSg3dI af3I8oimJiL/SIlDUi2tpI/zQj6bJ/9b338aUovNkRTMCK8GMt1wrO5qvxj8YRysJRBU 7htw== X-Forwarded-Encrypted: i=1; AKwUvBwctFIXxlgHnJsr6k9Rpf/s57Q9R8KAQq4N/qbONYNncT0TMjH3DaedOvuWLV6Z6WwkaWuMEWsPmJI=@lists.xenproject.org X-Gm-Message-State: AFq9FYLtCmvnmqo6HOcnGsPYpYAtWNr9f4hXXOZlTEQ6GVAxeSGAVCW9 qyULE3E4M5RVuJdL1U6FndCdmBjbdnBCrJ81WmfaYaqtUqM1XRDAPCrxVu91adYgkQ== X-Gm-Gg: AYBFou2QcfuaFs0QF/6eqn/KAvqTckL2TBP1VzuKxcYMtsO6FYew/vlXw2cxEz7fRgp IDVkT4qnh9RULbhn5zmcaVTVeggInrzekjxUzgP92nUkhWIgzet9dZ/4qvrbH+XzWK0CnRKX7TO yiciKsH5WgeFT2AY7sBHw5CE4zpr/aKILpH4xDVyB9enox7UfLd5hQh3nh01HxDV53+sLFMn+rI SEwBZgt6FU32ZuevlHkQVbDbniNNVX508RT0jEXLor3CQoRSsKIzjjm/LW0VtWCEiJS3Buq78pB aSelSY5aMHGdwFnloC2Cp+Mqo77dNdfTnVBY+xeqvvRW9o3VPtzy/DVTlyCS11A1bTjdnp5dQpP P0YHWmj2uYqMvE/clx9E8plaCEl8S7k3w/crH+xetLU4F4sfQgWhZat/Zz1Y8KPgGpcqnqEIl/S +JTmc3o/uzN/2HUvpZcOMfDPYlw6uYOtut6TM7Nvt6FgBE2xA3wRFMZ/LQAjtuKqwFdpkdKIfK6 6KW3wp4Aa0WemTBt3TQiM+8lKNKV5/RiAF0v+3wRsXcqzqfxJQlgyN0SrwPCYIe5AkxRSmm X-Received: by 2002:a05:6000:490b:b0:488:7da0:fedb with SMTP id ffacd0b85a97d-48c4801353cmr12447128f8f.40.1791212707610; Mon, 05 Oct 2026 08:05:07 -0700 (PDT) Message-ID: Date: Mon, 5 Oct 2026 17:05:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/x86: restrict XENFEAT_pae_pgdir_above_4gb setting to PV guests To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261005144317.2887-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: <20261005144317.2887-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791212708-538C1B50-43E1AA55/10/78276251493 X-purgate-type: spam X-purgate-size: 501 On 05.10.2026 16:43, Roger Pau Monne wrote: > XENFEAT_pae_pgdir_above_4gb is only used by 32bit PV guests, hence limit > its setting in XENVER_get_features to the is_pv_domain() guarded section, > with the rest of the PV specific features. Add an additional build time > guard to short-circuit the setting of XENFEAT_pae_pgdir_above_4gb if the > hypervisor has no PV 32bit support. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Oct 05 15:11:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 15:11:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440951.1658489 (Exim 4.92) (envelope-from ) id 1xDkLN-0001EH-0R; Mon, 05 Oct 2026 15:11:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440951.1658489; Mon, 05 Oct 2026 15:11: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 1xDkLM-0001EA-Ti; Mon, 05 Oct 2026 15:11:08 +0000 Received: by outflank-mailman (input) for mailman id 1440951; Mon, 05 Oct 2026 15:11:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDkLL-0001E4-HR for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:11:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDkLK-00CvyS-8B for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 17:11:06 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3be0a-2eae-0a2a0a5409dd-0a2a450793e0-0 for ; Mon, 05 Oct 2026 17:11:06 +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 6ac3be0a-b4ea-0a2a45070019-4a7de18dd294-3 for ; Mon, 05 Oct 2026 17:11:06 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49cd5462b69so12216035e9.1 for ; Mon, 05 Oct 2026 08:11: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-48c62270739sm4294765f8f.11.2026.10.05.08.11.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 08:11: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=1791213065; x=1791817865; 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=ZNMYef8VKjw2gIAPgxNBQ5UA4NVBwCa0myjmxKu3q/E=; b=N+5pVJSQecCZDzSHl3eycH7tQG6Qr7SLyweArg/pQsrPA7vz5A18ncNtlgcRIK1w04 re2nIBj6Cdrk9IgibUVdnEtTPSC+gPIaF8IDaxutQoVrZpYkraylcTGDEL0pXDmeiObJ GMMxiZn0buMSb/C+Z5Nsg2smFwhyghf7PWMujCJ8EI044sZf9A+P3KZiTQh5WXlAOaQ2 3JOmUuWpDXKfuuxlslyRRWmvlzocNCqMQJVLbFBWHQd+PdgW9B/aCiT0stsgC3nThCCW 70h+F2nOA1CN00y/mCRYCbbkLW5mavVuvvv5JFQ1GZuBuX9EAitVLQUOyPPjnPt4dj/E ok8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791213065; x=1791817865; 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=ZNMYef8VKjw2gIAPgxNBQ5UA4NVBwCa0myjmxKu3q/E=; b=1CuSe/KwZ5E+JIpZo/XO2fQ3Fi2fvEYtmf9aqcaZOilKCyIJJyk1pwnBhSoes5edY7 OtYgkJYuVuUC6LUOGWI/F3Iez7X1fulqK56ss14ZcMFYg3HgZtl63McnhQw5go1p5clb lfTecLPttcLmQTA4biXlD6yrGNDiH6or8w7jgA8PdYH2sYZQCAo+PtmwKfh2uOe4vUF3 YDlUY7XHyHeay+FJiTCKxi5pjfLnCIsrj4WE7GsgbyqNVOMCRAP82X9UyhOGw1KadGe4 nEnNEDzA5Rqk0PAIAyKb6hivyQKPJp7V2rRzDRAYJKYGaj4Fr0JmnHvshIvOxZ7jg4JA 7JcQ== X-Forwarded-Encrypted: i=1; AKwUvByQokiabW2H9gTDdOE4cTo8oEYwjBJFvfUUtIrNSu9PJRDS2p4QXweoK2kSlu33bWSANGTbqzr/cOM=@lists.xenproject.org X-Gm-Message-State: AFuF++n4K5jwefxNicwQ2rBfF0Tbevgaawrvh+XXanLOOtnrSnLOpNEu 270jepQdLzxEKAaApU+BVbi1hZfnrpxAeY2sFzE5xZMTf53xy1q1FNFgdZT20198DA== X-Gm-Gg: AYBFou3IqgNRk917hwtU73UBCWfin5H3vFGj+DV1EFcpvhx6MNhrQbME9VjNn67e+jX TqD6u6Vm8Q0ncO8DFfD/K+vlPXA0X8rWdwc285fqNI2QNN9xI2bIYI+2dMXKUULHyOSnKWkMi2y TsM8Ld28f8QO7tAjSjMFH99T8XkSNC18DmyV5o/8ls4pCSXISzctfAt3o9zcUk5AfFSs3TH2hHT mO948AOyo4Lwi7LV2bG2N2fWqGLyMhbcyqutnjUDJHds4ovFfjE+Heav1mxrsxeBa/fIbU9vlgb 5LbLOY4nuj+zehSYwYUHtCN0WpfzvmnkQjggIUmdSnmi1xFIStC8ZLCuHFW16jn2OrA7FG/0Li3 ej1mFXM/Uquj5ZmeD5hiTwkhRE2yvVFSQdCmBeIzGy5NHb/kqOUtB6xmpCNtUgQwOYzJcbc4X4H tSgRPdLPAr7Bd972O6PWwCyuqvQHxQnjEWb7mge5tqqhmgwqp451i22+103dXI0ZZzb/cumwOAc 1O1DS67vvzWUbyhnhknNQz5X0vF/8ZgcNd0wKu9RVogUrMsRA== X-Received: by 2002:a05:600d:6444:20b0:4a0:c01:1902 with SMTP id 5b1f17b1804b1-4a1773def4cmr12153435e9.2.1791213065240; Mon, 05 Oct 2026 08:11:05 -0700 (PDT) Message-ID: <5058c588-662b-4435-b205-52ee3ab01ab8@suse.com> Date: Mon, 5 Oct 2026 17:11:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/shim: Report -ENOSYS instead of -EOPNOTSUPP To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1791211375.8631fc262581453bbf619ec5b2062170.1a10c848c9a0003f66@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: <1791211375.8631fc262581453bbf619ec5b2062170.1a10c848c9a0003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791213066-A76D2AE4-5024137B/10/78276251493 X-purgate-type: spam X-purgate-size: 1143 On 05.10.2026 16:41, Teddy Astie wrote: > Main Xen reported -ENOSYS if the operation is not implemented, however, > shim errorneously reported it as -EOPNOTSUPP, potentially confusing the > guest. I question "erroneously". -ENOSYS has, according to my understanding, exactly one valid use case: A top-level hypercall (normally: syscall) function which is not implemented. Unknown sub-ops etc shouldn't be using that error indicator, or else callers can't tell one from the other. That said, it may still be legitimate to make the change here, as making the change in do_grant_table_op() and do_event_channel_op() can be viewed as an ABI change, which then we cannot easily do. > Make shim more consistent with Xen by reporting -ENOSYS instead. > > Fixes: 49f79fe03dfe ("xen/pvshim: add grant table operations") > Fixes: 368ae9a05fee ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU") > Reported-by: Teddy Astie > Suggested-by: Andrew Cooper > Signed-off-by: Teddy Astie Reported-by for yourself is pretty unusual, btw. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 05 15:59:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 15:59:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440963.1658505 (Exim 4.92) (envelope-from ) id 1xDl5Z-00077V-E7; Mon, 05 Oct 2026 15:58:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440963.1658505; Mon, 05 Oct 2026 15: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 1xDl5Z-00077O-BC; Mon, 05 Oct 2026 15:58:53 +0000 Received: by outflank-mailman (input) for mailman id 1440963; Mon, 05 Oct 2026 15:58:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDl5X-00077I-Ri for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 15:58:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDl5X-003Jlh-8Y for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 17:58:51 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3c938-8faa-0a2a0a5109dd-0a2a450cd4cc-10 for ; Mon, 05 Oct 2026 17:58:51 +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 6ac3c93a-f479-0a2a450c0019-b9ff1c12b307-3 for ; Mon, 05 Oct 2026 17:58: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 1a10cc9f7c20003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 15:58:45 +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 297CA822A9; Mon, 5 Oct 2026 17:58: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:Content-Transfer-Encoding:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=P+y8Uky1ULNQ8eUEjKyL1X8FAua0NmxyTivjeFsUWc0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=MuLurpkYmKGEu/qchUr13luzCeDRPRtA+j/wZb6hhTsOT8nDpkgOrZ0dZPdkimScongPmyTUj 68cnoUlFVxyS7FVinDrEku/TMC2tboTp/9hJA+LYYyILhzUKmHuRS5Y7+i6qNBT8YikvY29MJnQ 8GPLsx3fOTbAQX/Hc4wegI/ZuK44lfV2HUjN+d8lKgbC+ofoxMHyUX1rlTAda090EDDtbh3/Hqi knIi800Gv4lNwKUvcGjxhjxsxqrHwlZVaCB2aOXkefKK1C8MsHzegu4XtBMqRM3j2cqgJ1vpa6P aQHB6cfdwM8Jz4L2zWkqibo0gcZcDW13CNInYPC0a6mw== X-Zone-Loop: 2f53d3597f560924b1374965a34df0977b3465d0505b x-campaign-type: default x-transaction-id: e419bbea-dc3d-45c5-8151-f1063ca243fc x-swg-uid: 01-d4f30aad-a590-43b9-988f-bd1200dc09e6 X-Mailer: Sweego Message-ID: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> x-swg-bid: 1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v5 0/3] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Mon, 5 Oct 2026 17:58:40 +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=1791215868; l=4092; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=gVX+Clx4s6m8EAocf35NeMpaQCBmbKQ2GC5detAm5Yo=; b=dAZJkhq0FP7vQbGDVw0kDituzjaNEM4zrHsNYLnyk1wwBXnq3qdxbLqcPBcCTERseLrkmczSD KEsfdP/90rtD+NbTAmx7pJgxWjo52iZdQgb+J5Q7o7dWGV51TFyj4v2 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: 1791215924375 X-purgate-ID: tlsNG-d25034/1791215931-77CD3A5B-9B5DAA7C/10/78276251493 X-purgate-type: spam X-purgate-size: 4094 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: Always preset A/D bits in G-stage PTEs 2: Fix A/D bit handling in Xen's page-table mappings 3: Use pte_is_valid() in pte_is_mapping() CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2914284702 --- Changes since v4: - Drop patches merged upstream: ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"") - Collect trailers. - Rebase patches on top of staging. - Link to v4: https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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: xen-devel@lists.xenproject.org Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: Roger Pau Monné Cc: Stefano Stabellini Cc: Alistair Francis Cc: Connor Davis Cc: Oleksii Kurochko Cc: Zheng Zhang --- Baptiste Le Duc (3): xen/riscv: always preset A/D bits in G-stage PTEs xen/riscv: fix A/D bits in Xen's page-table mappings xen/riscv: use pte_is_valid() in pte_is_mapping() xen/arch/riscv/include/asm/page.h | 35 ++++++++++++++++++----------------- xen/arch/riscv/mm.c | 11 +++++------ xen/arch/riscv/p2m.c | 38 ++++++++------------------------------ 3 files changed, 31 insertions(+), 53 deletions(-) --- base-commit: e4da1829737fb575133d1f79d9ad987000891649 change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:00:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:00:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440975.1658546 (Exim 4.92) (envelope-from ) id 1xDl71-0000xE-Gc; Mon, 05 Oct 2026 16:00:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440975.1658546; Mon, 05 Oct 2026 16:00: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 1xDl71-0000x7-Dw; Mon, 05 Oct 2026 16:00:23 +0000 Received: by outflank-mailman (input) for mailman id 1440975; Mon, 05 Oct 2026 16:00:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDl70-0000wz-6G for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:00:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDl6z-00Bdwr-Fe for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:00:21 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3c994-2eae-0a2a0a5409dd-0a2a45029a4c-4 for ; Mon, 05 Oct 2026 18:00:21 +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 6ac3c995-6ca4-0a2a45020019-b9ff1c239615-3 for ; Mon, 05 Oct 2026 18:00: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a10ccb5ec20003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 16:00:17 +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 20D948280B; Mon, 5 Oct 2026 18:00: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: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=43pCL2Pcw0Ag1BgM2PoJ0XDwKsUsxAQ7FbkpNgPFfic=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ZI6C75HUSSRnTF9uf2Ats45SPpXvsi9FaVgamtmTIJNSiR2+iVFbxL7I8NzSneP5ueFPkkA9B sUc7XBytAOLS/gS6BBYzspMo2S9ZVvp4j1vNWSr3V4W7F9G5eibOpmcWq4s49uRTPSNcGwvFWtV Bp7iadkBRPZwXn00dCiNohee6t261Yrc9tmOo/3P1ZQx3KeXhxDLTu0zDgDPSJplLXqlPPXgoxp 6yZQvGClcDWc9DBS9j4xJ6R/zMbnYpqZgeSP+HGot+4L4CIeCHt/1ium+tYwL4J0nQ3ZATzD3LY sD18gkji6YNdEvOaw4v4H0/ZL1HmZXXj0t4LD2aJM1PA== X-Zone-Loop: b6c0c72d052383083a30c635c4d132fdd0fd1d8f279c x-campaign-type: default x-transaction-id: 2fa68973-88e9-4adc-bd3b-e53ad72b4158 x-swg-uid: 01-f1eee119-2f8d-4f27-8568-14b990a7b00c X-Mailer: Sweego Message-ID: <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> x-swg-bid: 1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs Date: Mon, 5 Oct 2026 18:00:14 +0200 In-Reply-To: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1791215868; l=5258; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=+7RuCsiQXUwfROF9vIBU6i/pk2whnmvYv855VhRuUz8=; b=DmXvMoAw7Td79BJHKaVHegoLOBhKrRziema3PB5qGxeEpCHjdbr0lnJHftMAL2Lk5sh0GeSkm poHiQBofggUBrjmdZJ+TAbGfXOxVQ0S73zKn7sdYmgO1lDgkNQZ8ODs 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: 1791216016324 X-purgate-ID: tlsNG-720697/1791216021-F06A72AC-D89A7C4B/0/0 X-purgate-type: clean X-purgate-size: 5260 A RISC-V implementation can manage the PTE A/D bits in one of two ways: 1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). 2) Generate a page fault when 'A' and/or 'D' is clear, so that software can set them (ratified as Svade). p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device tree advertises Svade. Platforms that use scheme (2) without advertising Svade, such as the HiFive Premier P550, then hit guest-page faults that Xen does not handle. Always preset A/D in G-stage PTEs so scheme (2) never faults. This is harmless with (1): software just does what hardware would have done on first access. Drop the TODO suggesting to handle A/D faults: only Svade raises them, so it would not work on Svadu. Dirty/access tracking can restrict the RWX permissions of p2m entries, as x86 and Arm do. 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 v4: - restore svade and update the commit message accordingly. - rebase on top of staging. --- Changes since v3: - always preset A/D bits in G-stage mappings instead of keying off the DT: it may not reflect what the hardware actually does. - change commit title/message. - drop svade as it is now-unused. --- Changes since v2: - change commit title. - preset A/D bits in p2m_set_pte_flags() if (!svadu || svade), instead of setting RISCV_ISA_EXT_svade in the riscv_isa bitmap for cases 1, 2 and 4. - riscv_resolve_ad_scheme() now only warns when both Svade and Svadu are present and SBI FWFT is missing; drop the dead 'svadu && svade' operand. - repeat XENLOG_WARNING on each line of the warning. - drop ASSERT(svade != svadu) from p2m_set_pte_flags(). - only add the sbi_probe_extension() declaration to sbi.h. - rework the comment in p2m_set_pte_flags(). --- 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/p2m.c | 38 ++++++++------------------------------ 1 file changed, 8 insertions(+), 30 deletions(-) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index f7b380b90a..14cae7dcd7 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -591,38 +591,16 @@ static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) 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. + * A RISC-V implementation can either: + * 1) Update the 'A' and 'D' PTE bits in hardware. + * 2) Generate a page fault when 'A' and/or 'D' is clear, so that + * software can set them. * - * 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. - * - * 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. + * Xen supports both, so set 'A' and 'D' up front to avoid the faults + * of (2). This is harmless with (1): software just does what hardware + * would have done on first access. */ - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) - e->pte |= PTE_ACCESSED | PTE_DIRTY; + e->pte |= PTE_ACCESSED | PTE_DIRTY; switch ( t ) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:00:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:00:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440976.1658556 (Exim 4.92) (envelope-from ) id 1xDl74-0001Au-Qr; Mon, 05 Oct 2026 16:00:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440976.1658556; Mon, 05 Oct 2026 16:00: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 1xDl74-0001An-Nl; Mon, 05 Oct 2026 16:00:26 +0000 Received: by outflank-mailman (input) for mailman id 1440976; Mon, 05 Oct 2026 16:00:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDl73-0001AI-Ie for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:00:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDl72-00Be0m-Vn for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:00:24 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3c994-2eae-0a2a0a5409dd-0a2a45029a4c-10 for ; Mon, 05 Oct 2026 18:00:24 +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 6ac3c995-6ca4-0a2a45020019-b9ff1c239615-4 for ; Mon, 05 Oct 2026 18:00: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 1a10ccb607c0003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 16:00:17 +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 BA94182822; Mon, 5 Oct 2026 18:00: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: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=LygNV66k49sU5OSBS6k4t4kuUiQHmg4R5XKF6wuLvDE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=tl1XGXpcDNp1zH8l7oPUQWPyl9dYw+Tf6p6aHDvP2x56gDRsILCIPxi19RY4WTE1EN5WvTkVf BOw/ydNeMrMsnU+zaQAaFpyuZFoe2Q1Qwgr41DoRBMF2W/rBR7aNCqAqfTC8lF9j10DexvZNLai ImGb5lNHo5KJvzypn1TK6+oQc2Sja3EfFtKZ93vJY+s1CuFWnISkbphMAPOODxUhh6k+QtOnK1z N4z2myGFRKtJ4nZu6ZNh5R77KRpVRXaUrNvbKvN7lCYkAyqQp7RlFzjLfT3kM3UpjvyywD77OfE mxjCxpD7NfLKqdDYMkSxIygopR+LRHcZwWRvQ5+4A+Uw== X-Zone-Loop: 371e535f7d45790bd739b573911ea159a906fbc1954d x-campaign-type: default x-transaction-id: 28c20229-448e-44d6-8db1-09ebb2a37db4 x-swg-uid: 01-e625f7cc-2d9a-47bd-93c6-afe036deee50 X-Mailer: Sweego Message-ID: <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb607c0003f66@vates.tech> x-swg-bid: 1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb607c0003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v5 2/3] xen/riscv: fix A/D bits in Xen's page-table mappings Date: Mon, 5 Oct 2026 18:00:15 +0200 In-Reply-To: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1791215868; l=7619; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=VSEkK1zF5QeYTsfWAsxXKEDM+CtdWZX+AIJltvq6cZQ=; b=OCZmAm5JzG5Jw2QiJq9kiRIcGvZff6kKULX0zY/lm2yDhtdBg55ilO24dUh0Nc3Rxo3M8HM3B 2xLWlTf6J1AA4qULsBHw2VLchGAuL8+TTX3ksjsr/N0G9A8thOUj5rR 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: 1791216016960 X-purgate-ID: tlsNG-720697/1791216024-305C52AC-254B5BD6/10/73395122804 X-purgate-type: spam X-purgate-size: 7621 Xen does not handle page faults caused by clear A/D bits, so it presets them when creating PTEs. pt_update_entry() does so, but three places build leaf PTEs directly without going through it: setup_initial_mapping() (the boot page tables), check_pgtbl_mode_support() (the temporary root entry used to probe SATP mode support) and arch_pmap_map() (the fixmap). Without Svadu, all three fault on first access. For check_pgtbl_mode_support(), the fault is raised by the instruction fetch right after the SATP write, before any trap handler is set. Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in all cases for consistency with pt_update_entry() which sets it at runtime. 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 check_pgtbl_mode_support() to use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also carries A and D, a reserved PTE with A or D set would no longer be caught. Mask with the V, R and W bits explicitly instead, and factor the check out into pte_has_reserved_rwx(). Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko --- Changes since v4: - rebase on top of staging. - add a missing changes line in "Changes since v3". --- Changes since v3: - rebase patch 2/6 which modified wrong indentation. - change commit message to address review comments. - rename pte_is_reserved() to pte_has_reserved_rwx() --- Changes since v2: - add fixes commit ref. - add A/D bits to PAGE_HYPERVISOR_RO and derive PAGE_HYPERVISOR_RW/RX from it for consistency with runtime. - introduce pte_is_reserved() to factor out the reserved-encoding assert shared by pte_is_table() and pte_is_mapping(). - reword commit title --- 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 | 33 +++++++++++++++++---------------- xen/arch/riscv/mm.c | 11 +++++------ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index b465a90325..8a3e3e1e66 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -46,12 +46,12 @@ #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 | PTE_DIRTY) +#define PAGE_HYPERVISOR_RW (PAGE_HYPERVISOR_RO | PTE_WRITABLE) +#define PAGE_HYPERVISOR_RX (PAGE_HYPERVISOR_RO | PTE_EXECUTABLE) #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW /* @@ -161,31 +161,32 @@ static inline bool pte_is_valid(pte_t p) * X W R Meaning * 0 0 0 Pointer to next level of page table. * 0 0 1 Read-only page. - * 0 1 0 Reserved for future use. + * 0 1 0 Reserved for future use. [1] * 0 1 1 Read-write page. * 1 0 0 Execute-only page. * 1 0 1 Read-execute page. - * 1 1 0 Reserved for future use. + * 1 1 0 Reserved for future use. [2] * 1 1 1 Read-write-execute page. + * + * So if V=1 and W=1 then R also needs to be 1 as R = 0 is reserved for + * future use ([1], [2]). */ +static inline bool pte_has_reserved_rwx(pte_t p) +{ + return (p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) == + (PTE_VALID | PTE_WRITABLE); +} + 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(!pte_has_reserved_rwx(p)); return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID); } static inline bool pte_is_mapping(pte_t p) { - /* See pte_is_table() */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); + ASSERT(!pte_has_reserved_rwx(p)); 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 06f0406781..6f7dcd10b2 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -140,19 +140,18 @@ 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 pte_flags = PTE_LEAF_DEFAULT; + unsigned int pte_flags = PAGE_HYPERVISOR_RW; unsigned long addr = is_identity_mapping ? page_addr : virt_to_maddr(page_addr); pte_t pte_to_be_written; index = pt_index(0, page_addr); - if ( is_kernel_text(addr) || - is_kernel_inittext(addr) ) - pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) + pte_flags = PAGE_HYPERVISOR_RX; if ( is_kernel_rodata(addr) ) - pte_flags = PTE_READABLE | PTE_VALID; + pte_flags = PAGE_HYPERVISOR_RO; pte_to_be_written = paddr_to_pte(paddr, pte_flags); @@ -197,7 +196,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 Mon Oct 05 16:00:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:00:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440978.1658565 (Exim 4.92) (envelope-from ) id 1xDl7B-0001VN-1s; Mon, 05 Oct 2026 16:00:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440978.1658565; Mon, 05 Oct 2026 16:00: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 1xDl7A-0001VB-Ud; Mon, 05 Oct 2026 16:00:32 +0000 Received: by outflank-mailman (input) for mailman id 1440978; Mon, 05 Oct 2026 16:00:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDl79-0001UP-Ux for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:00:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDl79-002951-AT for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:00:31 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3c994-8faa-0a2a0a5109dd-0a2a450b9ed4-48 for ; Mon, 05 Oct 2026 18:00:31 +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 6ac3c99e-b7e8-0a2a450b0019-b9ff1c12a051-3 for ; Mon, 05 Oct 2026 18:00: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 1a10ccb619c0003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 05 Oct 2026 16:00:17 +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 35CC48280B; Mon, 5 Oct 2026 18:00: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=io7ydM6wQjnb7pc+CL6LBvwBURlY1aKhFGpyl/SFLdM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=mkI+6kqvbHLRucn5PL5/eIQ4AnrUtMuRbe/nTSEWurvx/uW6NnBHrghbHL/wTcK0xuaohzXy4 so+z2ETiVCzpDIsGmMtEa/JJv7glb4FRziZWWbnBZO7uLPZEIASGAA6ZcZ1GY2sRm+pMeax+f2W oJBbbyKZqEi7VgIjLyxj6/ubPqEwwVfkqdXGJf464Xc8lmQFlc/BxYC8siGwaUzmjPxPqgfFnHf zxzAU3mcgitCS1M1qjYI2/gE4kIKFzAgIeMt6QJY0+apIiccXrYwAgL4DLiv4YpOS5bZLAf+VBp y9bo4L9qQeUphdFJCL7NSOqFAi+UEN7oeYzMNbAVYMGQ== X-Zone-Loop: 09b5500678aca61bee225ee4584e653f9bee47db4396 x-campaign-type: default x-transaction-id: ee3a49bf-b669-4c54-ac39-caed46c55572 x-swg-uid: 01-8449e5a7-ca9f-4e5a-8ba3-dc873b6bf920 X-Mailer: Sweego Message-ID: <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb619c0003f66@vates.tech> x-swg-bid: 1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb619c0003f66 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v5 3/3] xen/riscv: use pte_is_valid() in pte_is_mapping() Date: Mon, 5 Oct 2026 18:00:16 +0200 In-Reply-To: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1791215868; l=1017; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=mfATwIkml8XPxYLNKsPDuCuta+Y9echIFDKTb+/YvRE=; b=udBmv3YNcYm7Alk+b+2JN7o8WJ/iGv3UZs0K728bPBE4ntdExZntIv/uxnHRjuJgd0CAA2sNM 8DDrkaCdP4bCUnhuiAIKkMKCuVtTHFywlS2tyBJN05AZajuxcotYjpq 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: 1791216017415 X-purgate-ID: tlsNG-42698a/1791216031-A9EC69EA-B54B7DDF/10/73395122804 X-purgate-type: spam X-purgate-size: 1019 Use pte_is_valid() instead of open-coding the PTE_VALID check. No functional change. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko --- Changes since v4: - rebase on top of staging. --- Changes since v3: - no changes. - add trailers. --- Changes since v2: - new patch. --- xen/arch/riscv/include/asm/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index 8a3e3e1e66..f9e59e61de 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -188,7 +188,7 @@ static inline bool pte_is_mapping(pte_t p) { ASSERT(!pte_has_reserved_rwx(p)); - return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); + return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); } static inline bool pte_is_superpage(pte_t p, unsigned int level) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:01:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:01:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1440988.1658575 (Exim 4.92) (envelope-from ) id 1xDl8F-0002Yb-C2; Mon, 05 Oct 2026 16:01:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1440988.1658575; Mon, 05 Oct 2026 16:01: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 1xDl8F-0002YT-7g; Mon, 05 Oct 2026 16:01:39 +0000 Received: by outflank-mailman (input) for mailman id 1440988; Mon, 05 Oct 2026 16:01:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDl8D-0002Y1-LB for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:01:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDl8D-00BeVb-22 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:01:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3c9d4-2eae-0a2a0a5409dd-0a2a45019572-28 for ; Mon, 05 Oct 2026 18:01:36 +0200 Received: from [74.125.225.99] (helo=mail-wr2-f35.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3c9e0-5984-0a2a45010019-4a7de163b039-3 for ; Mon, 05 Oct 2026 18:01:36 +0200 Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-488811c9ebaso1028502f8f.2 for ; Mon, 05 Oct 2026 09:01: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 ffacd0b85a97d-48c62299461sm4484324f8f.28.2026.10.05.09.01.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 09:01: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=1791216096; x=1791820896; 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=UtXZ2NV3vzpMO+ieuRVth/JV/i6CrKS8slzAzlmRl/s=; b=WZq+YMfT6Gw1pt8xRWKUBat/yGRvlEwN982GKMxVauo2QWTIcmt0GuEgz1fP+lVRbw BRJuyVpote4K8L7ywAJLtsB2Zj/mVSxfuQjvfkju54OABBKDdDd4IWeuYwNYOeeiXANY dZa/zd+SHVhyhcjldxxzr024P57Mf63+pv/ATWXrXyAwtEB84GhCbPXCGPY3t76Q7IVY R5JxyH0mZQBKRZibVJB8cjUY4ek1uuDqFfQM870q6H69pKH7IvJF+e/qkmS1yKZBqL2b Iyio0BBJiAQHeOESraz/qqJ8S4QusAxDgo4OYgm0V+9SdKr6UvdDHL6DG93+upVGI+2b VUNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791216096; x=1791820896; 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=UtXZ2NV3vzpMO+ieuRVth/JV/i6CrKS8slzAzlmRl/s=; b=Vu6251J+FkV6UYSyaMn3xni7Vgvg5reG+8ZnTwm7F1ynN57fCqowvYT/tKcfmGmjtV Y2UFQYmBlWhskhH/hnbwnrbVEP0WO0UKCyeYhlSHvRakdxRB1R7wkJY3oV/o4eqWaBt6 qREqMmy7BDeHCJztuROmrBthq9MAHFVZcQ5UOPa7a4BrZqzENFIzVvI783KO3biXJ0VY en5CLUdP3ORJc9zTTAEyoj2IyCCmwsp5ZGg13Snkzpc1u0/Q/UPdQBzxpZ+B2km2zKJx akaMbxJ5PQb1O6aeNEreGunY7uXbdPRjtERnROrZJQW5F5oMe0fEOBCgiNLbWebjBUdB MppA== X-Gm-Message-State: AFq9FYL0DIYiUb+j9l0OpdE89eJRww5cTnv7Nd8mcIss+Wh8Ssi0bSGn ieWTeO6jlY8rnlGmUqxb3X3vmbHMfMEYveanIClwkC0AJ9btGhvkKoCraB5CsXg8LUztiVtVj6I 1p06WjQ== X-Gm-Gg: AYBFou0U++JV0PUrLdnfSWr0eSA0pKDSzi4g+JTT/Z9EOsTs2WfuRlrdQsEzC7yjG/i GotW0UkwGQVoQplwNtefw29Dxo+/WsAIhZ7hL46drCvhyXC1tpYUbOETFTg/IeVjuW7IBaGZWbK awe+zb1VXQxD9qpYyQVxH5jITlBz++N8PUOP+gmGwf3QhQvqkEfL9+VKFGNryT2hLsXvp/14LIB xyLPUM3bmd9Oy7JOKMCLjKjkX3SQNQpeQ/wK8l6dGxvnPgEvIZUHw7JUYNWtHsaRbjmOB4T51VW rrVL4pnDihxG1nYwu12o2dJM70w0BHG4bGBj400PQxHvmQJVFdqi9SGEXtn4hrgQb4Z2IqXZdGy AmqHyvkptJHtdODDjk7LXu9JMXCaHvxn/gCuZjhYjIlMI4CuWV0fP+BlfqJe0cQDY3G74Wx65M7 O4q1rOK/izxDpR75aePykiZNsAyNL/xfVih7OsvWvajVKb4QCGUagO9MhSfb0DA5Zyn5R/B66CD HcXSfTWCQToSw67YhiBW/MWRG71M7voD4xwGalQesAwa7j3m7MB1xJsiCrWWuM= X-Received: by 2002:a05:6000:4208:b0:48b:efb:4a66 with SMTP id ffacd0b85a97d-48b126f1580mr19272290f8f.6.1791216095116; Mon, 05 Oct 2026 09:01:35 -0700 (PDT) Message-ID: <012de89f-000c-45b3-a600-544114346e5b@suse.com> Date: Mon, 5 Oct 2026 18:01: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] x86/PVH: correct PVH Dom0 E820 region merge Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1791216096-1FC69757-ED904CF5/10/78276251493 X-purgate-type: spam X-purgate-size: 607 Folding with an immediately successive region can't be done by merely lowering the start of the region. The size of the region needs increasing as well. Fixes: 5427134eae81 ("x86: populate PVHv2 Dom0 physical memory map") Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -229,6 +229,7 @@ static int __init pvh_add_mem_range(stru if ( rs == e && d->arch.e820[i].type == type ) { d->arch.e820[i].addr = s; + d->arch.e820[i].size += e - s; return 0; } From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:12:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:12:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441006.1658607 (Exim 4.92) (envelope-from ) id 1xDlIq-0004rB-Pc; Mon, 05 Oct 2026 16:12:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441006.1658607; Mon, 05 Oct 2026 16: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 1xDlIq-0004r4-Mc; Mon, 05 Oct 2026 16:12:36 +0000 Received: by outflank-mailman (input) for mailman id 1441006; Mon, 05 Oct 2026 16:12:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDlIp-0004qy-OS for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:12:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDlIo-006gLH-CQ for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:12:34 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3cc6b-e002-0a2a0a5209dd-0a2a450be156-12 for ; Mon, 05 Oct 2026 18:12:33 +0200 Received: from [40.93.196.21] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3cc70-b7e8-0a2a450b0019-285dc4150d18-3 for ; Mon, 05 Oct 2026 18:12:33 +0200 Received: from BY1P220CA0018.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::8) by EAYPR12MB999157.namprd12.prod.outlook.com (2603:10b6:303:2bf::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 16:12:30 +0000 Received: from SJ1PEPF000037B7.namprd05.prod.outlook.com (2603:10b6:a03:5c3:cafe::68) by BY1P220CA0018.outlook.office365.com (2603:10b6:a03:5c3::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Mon, 5 Oct 2026 16:12:30 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ1PEPF000037B7.mail.protection.outlook.com (10.167.244.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Mon, 5 Oct 2026 16:12:29 +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, 5 Oct 2026 11:12:29 -0500 Received: from [192.168.19.2] (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, 5 Oct 2026 11:12: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=TVP31y+YaEn4gRiKZYIhTM/h3y3SMXtdXahoQxdnWovoi2/SLMlb/iQ0YQ3Qva4H8sG9ItOCecn04Nyp6uh4tzIJdJv9H2HL7eLlGW8opg2VJaDLAE6N2j1Q0gD4eVRrCJccJ8pfOsJMvsSxwSx0DsUyPH45hcY+bCo0yXuKXaoRPn8qTukpmwP8H/HcCZv/ZVZ7qUiDxifnH4HUotgV9qS5WDcY4hOpO1SYb5FptbP/QYfdHatm/DVioAEyWdu5+NGI45GOVSpp4vmHdUmZCd4p3bKcRRjmG2C7wGRDTYoZFvuJeN55061tlWroKuBH/ENyp4rFah2OulD/kybpqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tGv4IG7K24ZePJBTtc9k/uQ44iY3l43QCGxrjY5+koM=; b=xPMRt1dzfDVBND4WqqhtU6Ryvx0BFMJ0mO8gEhmbPVtdY+EwwTXC6UM5og4hzKdorhiZa3cy2kMYkkk/y1obhJDwhr/LdbNgJMOu6ZmFcAcly3h1gJVGZZf0jCGqqk+k4bNCZHsZJQUithW3LDTrIp9e71owF+YPy6kjdlGvLOlXLh/ejaCfdPZEp719op6EjairLCFWnD7TIjttKWW0EnXAli3xpWIEDjt19UoSvyv+8bY023H3o+2v+BkENggswpnP7iU/hUaEp+geqvn/wFNPIxLgtAoIBintcfAznONtPdlnFtXQvX8AeaVWuv388npzcpIKIFkw+wi04rLmxA== 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=tGv4IG7K24ZePJBTtc9k/uQ44iY3l43QCGxrjY5+koM=; b=UShpqv0Qko6KV9AxDnN+H8PvLFPfXl9oKyYXJpbbi4ZwnzRrZFXnSdVrvMhayUwrr5NkVsHYOcLqm65te0nfzWQFPTTX5/+6x9tYGymVKHK9623pBbaKzYnzL+UCIt+SNB6OizSmXU/0KYL/+aGL/K4c5HCHTwVhtj7uHKSNgfk= 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, 5 Oct 2026 12:12:23 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/PVH: correct PVH Dom0 E820 region merge To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <012de89f-000c-45b3-a600-544114346e5b@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <012de89f-000c-45b3-a600-544114346e5b@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000037B7:EE_|EAYPR12MB999157:EE_ X-MS-Office365-Filtering-Correlation-Id: f94d5ca6-9cf4-4460-3879-08df22fb74ab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|36860700016|376014|1800799024|18002099003|22082099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: IzZq62YXTrTiDQtGQ8aXofxmgTtTLAVMxwj35G/dmAY1Nsipnx+WV0ar/+TyWU9R3pSmiBtadp3jsBPSJaWH6WA8FF2S/fCmn1frzY9xvs25WUVXMBzHDqxTlVsJuzkAI86JZ0Jd7/NsTm2WTnUILH651238yIgywHxzfw3WDY2p8dhzpO8yf0hF00wuPrMqspIY1OZ3HRml2dqv75eyYsq7cexjigBfyXkAD4baL82Ui6kRO/19/HDRKoDFCKefZb57vAgihTy5jyRFJywnDuMTlam0zq447tkJcDY1wgU6UAiLCXjik5ZGSTfB1lYBrDPGMM6RzZ0gQJZnGQOKSwvkceXYeDiM0hektV4GXsKs41OTKjf5LVz7hOYMkpssvvaR8v/6RR3HJfd//xXpGsLQ0WDvFsQIEXXnTrdECAm73p7SKBJ3RVg0HVYDWaaI9oPIZynqNZhVjIdr1QXnTKoP2d167uCwiAHENpeV/IQZAzlAexV7gX9kMPmsLE6B5Dib79vjf23cYQgpP31RBzHWvo9khpZjj+v2Of9R1g/rkCDh8cLFbeYfRu+7gIuhN/De+hYv9mJloZv8suuNOHyZghtSr7H5qALb0Ss7aDzdp3LZbkEQc8S7FsPIdRjF+yGYUpadqbPibilEvU9HRzfTsGN/dhb3pK0XVW0j9bRVaJEQjDvpSSKVufKvO25BaLIQtOPkwh32IUKfiO3VyQ== 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)(23010399003)(36860700016)(376014)(1800799024)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: B4E/usIn2QsXRPL2GdXvWxJbMUKm4dxwNASPAWDfOAxO6ye3vfUrpIcLc6RKmZOP8Unxa2mc5iKfgk10xZKJTlFkJcShK+Uia5gFtzjhYbu55edKJZnggFfqnQOSMVcb5L5CD4Vdl3X5VuJqbAZZLrUf5Y1rn215mI7onkIII9KZ0PJqv7uLT9Y3Nq7FRDCJMdgmT9slE3EWg9DkXKQIIEgM7/MGkqdRz8CqTUkP5QHdb1tZE3L84gb4T1jvw4FjSDlSTzAG8n+Pftdjg8lBYneKn4BEYzBGjUrLY9nPr7esSmhr2OH/S+ejKdQy4BIVQBe80HLcyA5kVOC92dGk79aV26FPWqI0M/TF7oSkt9ufuB8zKUx1Ou/k5j/64dKlmbRuszutUIeqfTbd4Lbn2QEsGLv5IFOVS9Y69el4jJvFnLL5mucKornda0riMkRX X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 16:12:29.8134 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f94d5ca6-9cf4-4460-3879-08df22fb74ab 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: SJ1PEPF000037B7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: EAYPR12MB999157 X-purgate-ID: tlsNG-42698a/1791216753-1B8D19EA-71A6A82A/10/78276251493 X-purgate-type: spam X-purgate-size: 381 On 2026-10-05 12:01, Jan Beulich wrote: > Folding with an immediately successive region can't be done by merely > lowering the start of the region. The size of the region needs increasing > as well. > > Fixes: 5427134eae81 ("x86: populate PVHv2 Dom0 physical memory map") > Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:13:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:13:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441011.1658616 (Exim 4.92) (envelope-from ) id 1xDlJb-0005JP-4P; Mon, 05 Oct 2026 16:13:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441011.1658616; Mon, 05 Oct 2026 16:13: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 1xDlJb-0005JI-18; Mon, 05 Oct 2026 16:13:23 +0000 Received: by outflank-mailman (input) for mailman id 1441011; Mon, 05 Oct 2026 16:13:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDlJZ-0005Iq-JU for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:13:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xDlJX-00G7u8-2j; Mon, 05 Oct 2026 16:13: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 1xDlJX-0036w0-10; Mon, 05 Oct 2026 16:13: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=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=NqECvEkxeA24ZJ3cXmcqerUDz0GeBRnX3XtWfCxlQ84=; b=gVNTAwLpHIDhnzRoWfCWUsh7z6 lLZh1hFT6P0+RJ68U+Mmz8Ciabs2MY4YQFaR6Ns5nZKBc+z5jJ0JI+pA97VpZSlvyCse4iCNQ2EJV W95kLMZl4uhooZKnEqMeIWldp5iIrie3B5C0Ek0Skorbi6uZVjbiDPLkoVUSdhxrAB60=; Date: Mon, 5 Oct 2026 18:13:13 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Weiqi Wang Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang Subject: Re: [PATCH v2] xen/pdx: fix offset-compression merge of a contained range Message-ID: References: <20261005102713.94033-1-coolhaoyt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261005102713.94033-1-coolhaoyt@gmail.com> On Mon, Oct 05, 2026 at 11:27:13AM +0100, Weiqi Wang wrote: > From: Weiqi Wang > > When sorting and merging overlapping ranges in > pfn_pdx_compression_setup(), the merged range is set to end where the > second range ends. If the second range is fully contained in the first, > this truncates the first range, and the tail of it is then neither > compressible nor translated correctly. > > Keep the end of the merged range as the maximum of both ends. > > On x86 the ranges come from the SRAT memory affinity entries, and > overlapping entries for the same node are tolerated with a warning by the > NUMA code. The caller's subsequent coverage check catches the truncated > range, so the effect is that PDX compression is disabled with a "RAM > region ... not covered" message rather than memory being mistranslated. > > Add a test case that fails without this change. > > Found with the ESBMC bounded model checker. The counterexample was > confirmed by running it natively against the unmodified code. > > Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") > Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation > Signed-off-by: Weiqi Wang > --- > > Notes: > Changes in v2: > - clarify in the title that this is the offset-compression instance (Jan) > - parenthesise the test multiplications against the binary ORs (Jan) > > Also seen in a real boot: the hypervisor alone under QEMU (pc, 8 GiB), > built from defconfig, with no -numa and a hand-built SRAT passed with > -acpitable. Memory affinity entries, all PXM 0: > > [0, 3G) [4G, 9G) [5G, 6G) [1T, 1T+1G) > > The third entry lies inside the second. The NUMA code prints "overlaps > with itself" for it and accepts it. Without this patch: > > (XEN) PFN compression using lookup table shift 23 and region size 0x200000 > (XEN) range 0 [0000000000000, 000000017ffff] PFN IDX 0 : 0000000000000 > (XEN) range 1 [0000010000000, 000001003ffff] PFN IDX 32 : 000000fe00000 > (XEN) PFN compression disabled, RAM region [0x100000000, 0x23fffffff] not covered > > With it, the same output as without the third entry: > > (XEN) PFN compression using lookup table shift 28 and region size 0x400000 > (XEN) range 0 [0000000000000, 000000023ffff] PFN IDX 0 : 0000000000000 > (XEN) range 1 [0000010000000, 000001003ffff] PFN IDX 1 : 000000fc00000 > > tools/tests/pdx/test-pdx.c | 12 ++++++++++++ > xen/common/pdx.c | 5 +++-- > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c > index 4de8d43d86..8d271a488f 100644 > --- a/tools/tests/pdx/test-pdx.c > +++ b/tools/tests/pdx/test-pdx.c > @@ -87,6 +87,18 @@ int main(int argc, char **argv) > }, > .compress = true, > }, > + /* Range contained in a previous one. */ > + { > + .ranges = { > + { .start = 0, > + .end = ((1UL << MAX_ORDER) * 1) }, > + { .start = (1UL << (MAX_ORDER * 2)) | 0, > + .end = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 4) }, > + { .start = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 1), > + .end = (1UL << (MAX_ORDER * 2)) | ((1UL << MAX_ORDER) * 2) }, > + }, > + .compress = true, > + }, You place this in the __LP64__ protected section, but AFAICT this is not needed? Those values all fit in a 32bit integer. Also, I think the example could be simpler: /* Range contained in a previous one. */ { .ranges = { /* Overlapping ranges. */ { .start = 0, .end = (1UL << MAX_ORDER) * 2 }, { .start = 0, .end = (1UL << MAX_ORDER) * 1 }, /* Extra range to force offset compression to be engaged. */ { .start = (1UL << MAX_ORDER) * 3, .end = (1UL << MAX_ORDER) * 4 }, }, #ifdef CONFIG_PDX_OFFSET_COMPRESSION .compress = true, #else .compress = false, #endif }, FWIW, we could also make the fully contained range not start at 0, to avoid the sorting from reordering those, but I think that's not possible given the (current) compare function cmp_node(). > #endif > /* PDX compression, 2 ranges covered by the lower mask. */ > { > diff --git a/xen/common/pdx.c b/xen/common/pdx.c > index e7e16e193e..23655ef3bd 100644 > --- a/xen/common/pdx.c > +++ b/xen/common/pdx.c > @@ -393,8 +393,9 @@ bool __init pfn_pdx_compression_setup(paddr_t base) > (ranges[i - 1].base_pfn + ranges[i - 1].pages) ) > continue; > > - ranges[i - 1].pages = ranges[i].base_pfn + ranges[i].pages - > - ranges[i - 1].base_pfn; > + ranges[i - 1].pages = max(ranges[i - 1].pages, > + ranges[i].base_pfn + ranges[i].pages - > + ranges[i - 1].base_pfn); The fix LGTM, thanks. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:19:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:19:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441017.1658625 (Exim 4.92) (envelope-from ) id 1xDlPm-0006G8-NS; Mon, 05 Oct 2026 16:19:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441017.1658625; Mon, 05 Oct 2026 16:19: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 1xDlPm-0006G1-KW; Mon, 05 Oct 2026 16:19:46 +0000 Received: by outflank-mailman (input) for mailman id 1441017; Mon, 05 Oct 2026 16:19:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDlPl-0006Fv-P2 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:19:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xDlPl-00G80U-1J; Mon, 05 Oct 2026 16:19: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 1xDlPl-0038pV-0H; Mon, 05 Oct 2026 16:19: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=fdhhM+wVyT+RoEGbvryO9XRtui5cNWCzJ0UIki8brNs=; b=QJSDA41CbxySq2vi4Y6IwXhZp2 ayjy/4YtpUyHmfNaUI6L2YoqCjizGxQvH4xIAYs3pToeE16bk0QjzsYjj4acxbtkzU1Fn/Xv7xFNr OSuO+FkZO/Y7UWJcz/lTNyuS/GsqY87r6DHng9Y4MYsCQOpaW+P8EmIx+qtcqR/wsK5g=; Date: Mon, 5 Oct 2026 18:19:43 +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/PVH: correct PVH Dom0 E820 region merge Message-ID: References: <012de89f-000c-45b3-a600-544114346e5b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <012de89f-000c-45b3-a600-544114346e5b@suse.com> On Mon, Oct 05, 2026 at 06:01:34PM +0200, Jan Beulich wrote: > Folding with an immediately successive region can't be done by merely > lowering the start of the region. The size of the region needs increasing > as well. > > Fixes: 5427134eae81 ("x86: populate PVHv2 Dom0 physical memory map") > Signed-off-by: Jan Beulich My bad... Reviewed-by: Roger Pau Monné > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -229,6 +229,7 @@ static int __init pvh_add_mem_range(stru > if ( rs == e && d->arch.e820[i].type == type ) > { > d->arch.e820[i].addr = s; > + d->arch.e820[i].size += e - s; I think it would be simpler as: d->arch.e820[i].size = re - s; Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:41:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:41:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441025.1658634 (Exim 4.92) (envelope-from ) id 1xDll3-0002Ee-CO; Mon, 05 Oct 2026 16:41:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441025.1658634; Mon, 05 Oct 2026 16:41: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 1xDll3-0002EX-9m; Mon, 05 Oct 2026 16:41:45 +0000 Received: by outflank-mailman (input) for mailman id 1441025; Mon, 05 Oct 2026 16:41:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDll1-0002ER-UR for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:41:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDll0-006jWg-NT for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:41:42 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3d31e-8faa-0a2a0a5109dd-0a2a450aee36-42 for ; Mon, 05 Oct 2026 18:41:42 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3d345-f2d2-0a2a450a0019-aa0a857cce01-3 for ; Mon, 05 Oct 2026 18:41:42 +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-78-a7WJijS0OcSgjgrqhC8cFw-1; Mon, 05 Oct 2026 12:41:35 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 904E51977002; Mon, 5 Oct 2026 16:41:33 +0000 (UTC) Received: from localhost (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 3A47B1800446; Mon, 5 Oct 2026 16:41: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=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=1791218501; 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=rZB2mw8kdpwzfGr186lNQ1zojLkfVBrmJO82y15WJF8=; b=VPBidAeP7EC7kcL8NhHlzLPLtLKDsrhfeDruRk7X5b8kTh/v3Tq6SkBlj87slva00YusC2 eaqbHIC9JI8r1ejrGwVn2XvElHq8gLD+Ql+IG57+AT5jSFTSB1KmGhGYYuUV0RPE0B+0F+ jPrG5i9cIgXuQsm6y9rnPif938BLW6c= X-MC-Unique: a7WJijS0OcSgjgrqhC8cFw-1 X-Mimecast-MFC-AGG-ID: a7WJijS0OcSgjgrqhC8cFw_1791218494 From: Cornelia Huck To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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_P=2E_Berrang=C3=A9?= Subject: Re: [PATCH 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv In-Reply-To: <20260911143627.2743803-2-berrange@redhat.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty" References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-2-berrange@redhat.com> User-Agent: Notmuch/0.40 (https://notmuchmail.org) Date: Mon, 05 Oct 2026 18:41:29 +0200 Message-ID: <87zewsje12.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: LBdK1dWZafFwqF-0TIM4q9R9SgkYen6WDCUNHLdQ31M_1791218494 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1791218502-58FC6CFC-B9724F31/0/0 X-purgate-type: clean X-purgate-size: 1086 On Fri, Sep 11 2026, Daniel P. Berrang=C3=A9 wrote: > 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=C3=A9 > --- > 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(-) Acked-by: Cornelia Huck #s390 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:43:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:43:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441030.1658644 (Exim 4.92) (envelope-from ) id 1xDlmY-0002gp-Nt; Mon, 05 Oct 2026 16:43:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441030.1658644; Mon, 05 Oct 2026 16:43: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 1xDlmY-0002gi-JB; Mon, 05 Oct 2026 16:43:18 +0000 Received: by outflank-mailman (input) for mailman id 1441030; Mon, 05 Oct 2026 16:43:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDlmW-0002ga-NS for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:43:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDlmW-00E2lE-0u for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:43:16 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3d378-2eae-0a2a0a5409dd-0a2a4504edcc-44 for ; Mon, 05 Oct 2026 18:43:15 +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 6ac3d3a2-b57f-0a2a45040019-aa0a817cab6b-3 for ; Mon, 05 Oct 2026 18:43:15 +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-511-mCLtMEfGN2O4RnS1sIZrZg-1; Mon, 05 Oct 2026 12:43:12 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E6C6C1955F0D; Mon, 5 Oct 2026 16:43:10 +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 ESMTPS id 45FEB471; Mon, 5 Oct 2026 16:43:10 +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=1791218594; 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=qh49U003KLBLBhYbnCnOLFLAvwjn1I14DaZ3+ke48lY=; b=LKULJpYRlj1jftqifBEJZbXyKq51J0PPnAzxIcDwJYgfWBEN5jL0/4QulVivYVgn+1Jny0 sGcUs0+ZLtEa7wT7K5bwu2QIVv/lZYAnVKT4oTJhjJHczt2OAwUo30+QzXi6NWoRi22sep AX7LW8NoauFgyaF3sBk15NOnvonE1gw= X-MC-Unique: mCLtMEfGN2O4RnS1sIZrZg-1 X-Mimecast-MFC-AGG-ID: mCLtMEfGN2O4RnS1sIZrZg_1791218591 From: Cornelia Huck To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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_P=2E_Berrang=C3=A9?= Subject: Re: [PATCH 04/28] hw: mark all virtio CCW devices as secure In-Reply-To: <20260911143627.2743803-5-berrange@redhat.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty" References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-5-berrange@redhat.com> User-Agent: Notmuch/0.40 (https://notmuchmail.org) Date: Mon, 05 Oct 2026 18:43:07 +0200 Message-ID: <87wlrwjdyc.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 X-Mimecast-MFC-PROC-ID: ufB3wGeLK1uUOD__V48ZCdw8LOn6e9YjWLUGay2aNIw_1791218591 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1791218595-583C0B50-405CA57D/0/0 X-purgate-type: clean X-purgate-size: 987 On Fri, Sep 11 2026, Daniel P. Berrang=C3=A9 wrote: > These are all intended for use in a virtualization scenario and must > provide a security boundary. > > Signed-off-by: Daniel P. Berrang=C3=A9 > --- > 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(+) Acked-by: Cornelia Huck From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:44:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:44:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441035.1658651 (Exim 4.92) (envelope-from ) id 1xDlnu-0003Al-Up; Mon, 05 Oct 2026 16:44:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441035.1658651; Mon, 05 Oct 2026 16: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 1xDlnu-0003Ae-SK; Mon, 05 Oct 2026 16:44:42 +0000 Received: by outflank-mailman (input) for mailman id 1441035; Mon, 05 Oct 2026 16:44:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDlnu-0003AY-AP for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:44:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDlnt-003PWq-Nd for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:44:41 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3d3f7-e002-0a2a0a5209dd-0a2a45098efc-4 for ; Mon, 05 Oct 2026 18:44:41 +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 6ac3d3f8-be1a-0a2a45090019-aa0a817c7943-3 for ; Mon, 05 Oct 2026 18:44:41 +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-Y2AVDQIvMEyt9ypAIuHz1g-1; Mon, 05 Oct 2026 12:44:35 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 366FD195608F; Mon, 5 Oct 2026 16:44:33 +0000 (UTC) Received: from localhost (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 ESMTPS id 8916018004D4; Mon, 5 Oct 2026 16:44: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=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=1791218679; 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=a9BoSnEDgCJTNGC3lt5JXO3kHI9tlec5yV/ZrOKotUM=; b=AdsY/czO3CILJxngWwSToyHOdiH1z4YDMuja7MONeWvmGHwE24SRaQBUEpDWacZXru3fEk ZR5zb6kYLZJ8Fw4nNteiVe2LXg7yZTD3hjxDXGdYwKKiHPDT2KCr7O0adok154pB0MtblH 7MquZZ0ubv/tTtrU2f0IZfIGBPrU5uk= X-MC-Unique: Y2AVDQIvMEyt9ypAIuHz1g-1 X-Mimecast-MFC-AGG-ID: Y2AVDQIvMEyt9ypAIuHz1g_1791218673 From: Cornelia Huck To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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_P=2E_Berrang=C3=A9?= Subject: Re: [PATCH 07/28] hw/vfio: mark all VFIO object classes as secure In-Reply-To: <20260911143627.2743803-8-berrange@redhat.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty" References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-8-berrange@redhat.com> User-Agent: Notmuch/0.40 (https://notmuchmail.org) Date: Mon, 05 Oct 2026 18:44:30 +0200 Message-ID: <87tsn0jdw1.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: lZw_dNzykVxLJh8OibAx1BsGqctNbtS3Wo5YTVzKG9c_1791218673 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1791218681-BE6DA034-9DA0472C/0/0 X-purgate-type: clean X-purgate-size: 653 On Fri, Sep 11 2026, Daniel P. Berrang=C3=A9 wrote: > 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=C3=A9 > --- > 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(+) > Acked-by: Cornelia Huck #s390 types From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:47:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:47:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441041.1658661 (Exim 4.92) (envelope-from ) id 1xDlqM-0003gw-AI; Mon, 05 Oct 2026 16:47:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441041.1658661; Mon, 05 Oct 2026 16: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 1xDlqM-0003gp-7N; Mon, 05 Oct 2026 16:47:14 +0000 Received: by outflank-mailman (input) for mailman id 1441041; Mon, 05 Oct 2026 16:47:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDlqK-0003gj-QI for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:47:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDlqJ-00Bjqk-Nt for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:47:11 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3d46d-8faa-0a2a0a5109dd-0a2a450386c2-38 for ; Mon, 05 Oct 2026 18:47:11 +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 6ac3d48e-fae8-0a2a45030019-aa0a857c6837-3 for ; Mon, 05 Oct 2026 18:47:11 +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-354-G_wea8NIOxmqaYJPF5ieKw-1; Mon, 05 Oct 2026 12:47: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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0BF0C190FFA4; Mon, 5 Oct 2026 16:47:01 +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 ESMTPS id 617C43003EFB; Mon, 5 Oct 2026 16:45:45 +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=1791218830; 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=mfE4jn8R5CeMJqVd+Sml4oHZnPiAjulZz6wtCK0m3zk=; b=BjhWk091tapyyXnU2Ezz1dkksTIEMm9SH9wP1nzhBvIvxjMQ+hCZ1lSnN85VQ5pZFOyRG3 vtI5+EqQlPOGFhFXsXHdIHnf8BgJmmO1GRrOJ4YTeHsvP3/AxUP0eYgizn/WKruvqF6JB0 TWWbhFfiD7JzR8bTItv2bsBzlB/E4yo= X-MC-Unique: G_wea8NIOxmqaYJPF5ieKw-1 X-Mimecast-MFC-AGG-ID: G_wea8NIOxmqaYJPF5ieKw_1791218826 From: Cornelia Huck To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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_P=2E_Berrang=C3=A9?= Subject: Re: [PATCH 11/28] hw/watchdog: mark some watchdog devices as secure In-Reply-To: <20260911143627.2743803-12-berrange@redhat.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty" References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-12-berrange@redhat.com> User-Agent: Notmuch/0.40 (https://notmuchmail.org) Date: Mon, 05 Oct 2026 18:45:43 +0200 Message-ID: <87qzi4jdu0.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: XS7Q-_8f1RBLIvpB0PHQruNrlsaMWpT1J1DQrwdefS0_1791218826 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1791218831-762FD4E9-133B60A9/0/0 X-purgate-type: clean X-purgate-size: 728 On Fri, Sep 11 2026, Daniel P. Berrang=C3=A9 wrote: > 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=C3=A9 > --- > 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(+) Acked-by: Cornelia Huck #diag288 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:50:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:50:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441052.1658669 (Exim 4.92) (envelope-from ) id 1xDltS-0005Xr-QP; Mon, 05 Oct 2026 16:50:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441052.1658669; Mon, 05 Oct 2026 16:50: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 1xDltS-0005Xk-No; Mon, 05 Oct 2026 16:50:26 +0000 Received: by outflank-mailman (input) for mailman id 1441052; Mon, 05 Oct 2026 16:50:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDltR-0005Xe-Rs for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:50:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDltQ-009Xv5-SQ for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:50:24 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3d53a-8faa-0a2a0a5109dd-0a2a4506df88-18 for ; Mon, 05 Oct 2026 18:50:24 +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 6ac3d54e-195a-0a2a45060019-aa0a857cb3c1-3 for ; Mon, 05 Oct 2026 18:50:23 +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-180-h9WCb5LYNwy5fV-4unEZ5A-1; Mon, 05 Oct 2026 12:50:20 -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 91B0C190A0B5; Mon, 5 Oct 2026 16:49:22 +0000 (UTC) Received: from localhost (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 D89AF1800446; Mon, 5 Oct 2026 16:49: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=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=1791219022; 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=gRXaaB6TgFoC+NdH0TFCz50Ponj3MuleqX92hryoqx0=; b=h/rt+M8bnKb22E14bqGTD5di62w7sEVfRZqTiULYEe1b+lgAN8+iG5NRy/Z9rOlzImidYr P3XObvvGwq8FgRtnPmy8nsCN8f7yME8fOfzaTt50GfpxmVbVn8U8QAXVcJTY6GkX27/lew +iyHWP2v4tDGoOXWUtyU78fuilIZHRs= X-MC-Unique: h9WCb5LYNwy5fV-4unEZ5A-1 X-Mimecast-MFC-AGG-ID: h9WCb5LYNwy5fV-4unEZ5A_1791219019 From: Cornelia Huck To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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_P=2E_Berrang=C3=A9?= Subject: Re: [PATCH 16/28] hw/pci-host: mark common x86, ppc, arm and s390 PCI hosts as secure In-Reply-To: <20260911143627.2743803-17-berrange@redhat.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty" References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-17-berrange@redhat.com> User-Agent: Notmuch/0.40 (https://notmuchmail.org) Date: Mon, 05 Oct 2026 18:49:19 +0200 Message-ID: <87o6d8jdo0.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: SV76-CISmH8UIvZ0hPVsCoOuM_P16Qa2XTEQl2u2f9E_1791219019 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1791219023-FC80577B-D0A8A65D/0/0 X-purgate-type: clean X-purgate-size: 977 On Fri, Sep 11 2026, Daniel P. Berrang=C3=A9 wrote: > 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=C3=A9 > --- > 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(-) Acked-by: Cornelia Huck #s390 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:51:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:51:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441057.1658680 (Exim 4.92) (envelope-from ) id 1xDlu8-0005yL-3u; Mon, 05 Oct 2026 16:51:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441057.1658680; Mon, 05 Oct 2026 16:51: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 1xDlu7-0005yE-Vh; Mon, 05 Oct 2026 16:51:07 +0000 Received: by outflank-mailman (input) for mailman id 1441057; Mon, 05 Oct 2026 16:51:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDlu6-0005y6-Fs for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:51:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDlu5-00E3dm-Rp for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:51:05 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3d56d-bab6-0a2a0a5309dd-0a2a4501e1b6-16 for ; Mon, 05 Oct 2026 18:51:05 +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 6ac3d578-5984-0a2a45010019-aa0a817cc09d-3 for ; Mon, 05 Oct 2026 18:51:05 +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-255-wuhQB0g1MHuS6cH6pXWXJQ-1; Mon, 05 Oct 2026 12:50:59 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CB68619772E8; Mon, 5 Oct 2026 16:50:53 +0000 (UTC) Received: from localhost (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 1F2C41800351; Mon, 5 Oct 2026 16:50:52 +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=1791219064; 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=FVRiiNI9OtZut6St/CTJkkT2CHeTQ7+YeWbIgaKxiqM=; b=VJClNQEN1ca0trcfBa6ArbBK79bkFNJHz2+xPMlFna7Ts8X2obDC4HVnSvzhMl6g1ht6db 1JRAsiKtq2QOba6n5YC4oyOoiiNmJDH+TA04WtyulQta81IaiFDER79tVQqyQDRw+bXQJt be3FRE0cpvF/OJlmN6Bom16o6iMEUdU= X-MC-Unique: wuhQB0g1MHuS6cH6pXWXJQ-1 X-Mimecast-MFC-AGG-ID: wuhQB0g1MHuS6cH6pXWXJQ_1791219057 From: Cornelia Huck To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= , 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_P=2E_Berrang=C3=A9?= Subject: Re: [PATCH 21/28] hw/char: mark common serial / console devicess a secure In-Reply-To: <20260911143627.2743803-22-berrange@redhat.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty" References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-22-berrange@redhat.com> User-Agent: Notmuch/0.40 (https://notmuchmail.org) Date: Mon, 05 Oct 2026 18:50:50 +0200 Message-ID: <87ld8cjdlh.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: Si6ptBHNDGEwL2UL7Tn5qrvO3mPcOIYAycHiwzVB4NM_1791219057 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1791219065-1EA66757-2C7351CF/0/0 X-purgate-type: clean X-purgate-size: 604 On Fri, Sep 11 2026, Daniel P. Berrang=C3=A9 wrote: > These are needed as a baseline feature for many virtualization use > cases on x86, PPC64 and s390x. > > Signed-off-by: Daniel P. Berrang=C3=A9 > --- > 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(+) Acked-by: Cornelia Huck #sclpconsole(-lm) From xen-devel-bounces@lists.xenproject.org Mon Oct 05 16:59:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 16:59:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441064.1658688 (Exim 4.92) (envelope-from ) id 1xDm1w-0006yA-QP; Mon, 05 Oct 2026 16:59:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441064.1658688; Mon, 05 Oct 2026 16: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 1xDm1w-0006y2-Nf; Mon, 05 Oct 2026 16:59:12 +0000 Received: by outflank-mailman (input) for mailman id 1441064; Mon, 05 Oct 2026 16:59:10 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDm1u-0006xw-R7 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 16:59:10 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xDm1t-00G8ic-0a; Mon, 05 Oct 2026 16:59: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 1xDm1s-003T9H-2R; Mon, 05 Oct 2026 16:59: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=R0vJhkLZq8xTAT6foTBi2Yg2LFhzLDe5AyaqSOrHIWU=; b=YCvD8pMDM4QDTu5D7PivY0JSI7 CeBg2e0q7W/kJdXAVXaHHl+x1Xp22jxopGhMP9TZGxcT2rr1bzFBpA6hb6FIWFokHXVrNs5kdxOXI XqHSOWz3N6GS7RZjG/4iL5/ta46T5+kGO6ooOal9sZ7WegA4ThST+36Vwrpuus05SU0I=; Date: Mon, 5 Oct 2026 18:59:06 +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 12/14] gnttab: don't cast away constness Message-ID: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <1f55b457-c8cc-4ef9-ba5a-96e52b95fbbe@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1f55b457-c8cc-4ef9-ba5a-96e52b95fbbe@suse.com> On Wed, Sep 02, 2026 at 08:35:47AM +0200, Jan Beulich wrote: > 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 Acked-by: Roger Pau Monné Could we also use a union in the functions themselves to avoid the cast? union { const grant_entry_header_t *shah; uint32_t *raw; } grant = { .shah = shah }; > --- > 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. Possibly - I would be fine with that, which kinds of render my previous suggestion to use a union not very useful, if we can get rid of those variables in the first place. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 05 17:54:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 17:54:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441084.1658696 (Exim 4.92) (envelope-from ) id 1xDmtU-0007jW-La; Mon, 05 Oct 2026 17:54:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441084.1658696; Mon, 05 Oct 2026 17:54: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 1xDmtU-0007jP-J0; Mon, 05 Oct 2026 17:54:32 +0000 Received: by outflank-mailman (input) for mailman id 1441084; Mon, 05 Oct 2026 17:54:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDmtT-0007jJ-5v for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 17:54:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDmtS-00DGz4-It for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 19:54:30 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3e452-2eae-0a2a0a5409dd-0a2a4506a83c-4 for ; Mon, 05 Oct 2026 19:54:30 +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 6ac3e456-195a-0a2a45060019-d155802bdde5-3 for ; Mon, 05 Oct 2026 19:54:30 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a1728d8dfcso11379545e9.1 for ; Mon, 05 Oct 2026 10:54:30 -0700 (PDT) Received: from ws-fedora.tail006fee.ts.net (cm-93-156-216-249.telecable.es. [93.156.216.249]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1794a1af9sm2122515e9.5.2026.10.05.10.54.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2026 10:54: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: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=1791222870; x=1791827670; 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=xwNDRvPWE8TgwU0etaLOayu72eOFBBKFcNRGWmPN8AM=; b=lZV3dTGg3qmvevt3t8BIpIyTTRQKVAsHSI/ySzn1gBHid+h2SPHFKjfx45O6N43RyP VU/EIQQ8xjfdyFrSG2Dgrvyarl5RGF9G7p4UFC6ceqVo+QLx3cgZ/GkLpxb/YPLb6bXB jxhzJFBDN6ly+uCZAn9edWuUu7TE4MHybvB48EaUCW4I+ZZERiJJEUWERuB7Ga3TfJvw y4XrWAgjO/MWrcJAlQOxBsyn6RNfvtm8lmCgythev+X5Q7UbydPKhcIANWaIxZzwIC5G unCQjPHG2GVXLBKxyw2Fv313zNzzi0JX8y4UWCI0IFyi9h2+jQk+3Ouw/GC2Xq9cQnyt jIgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791222870; x=1791827670; 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=xwNDRvPWE8TgwU0etaLOayu72eOFBBKFcNRGWmPN8AM=; b=fDfbiG+WhgN1/igEJr3QSFse8KOOAnqGpDRKYDNi6SRfI1a/TvXNIP6CC1seL5XWQs bFdusePdEkjyBepQbmDWf6y42qnDt3GwvBTKo2m3D1lF0bkSc/p5DV223mD6adEOhmYM 5f+1Z6lniiq119/0LYxcMig6z6J6xFr+H6BRhIcChhaySYDkFfnBt6Em2KL11MF5RMgC 78eqjdgjUgrAlIQMFSl8k1F8WVv1yUtH/Oy2drVKWl3kIQpMK2bE/IqhfEisdLX2wk6B pL9gkzspAGgl/P1O03Jv3/yj5vrafVoCOOFBU7bAImE623IzmiFnkeH97WFKpdibeF4v nxOQ== X-Gm-Message-State: AFuF++lSvMLBZMh77ZC1d8gD+CI3XCsEEtyM9ZhTUmLEW1MfNsAQxPLq Y7s/dd9kr5Z6rTA4lEH6sT6vxjBfcU560eQu7fU7xYc2Q1fPJ0M73tYIpGKntTtr0pM= X-Gm-Gg: AYBFou1sQ4YoF/JfXKFSg7Lq7QoVO8NtnM/rQpGnh85tDqtdLaAGVIiUt3+t8GMX/Ph tPaqkjQOoGSxbvwKDqEmeXKCqjpV1cC0g+gAyL/PvbziWBZK7FvxKcI0zMOwr6bHvrWLsO23qF9 H5Cfd+k/IxiPljoSlUUEEMJji1pA94cQZ28luf10MrP8CAwsRZ400W4zEbsqJ8RQs6m9KRGK6O5 ApFV907+KTF4DVyq1mHoHsTNgYAzVPhvI7OgiWywjEJmflWfCItfi04io0Ik6p63DiukE+BYzRC hqVkI8ZVDjTWCqulHnC4HP3Mmza6jTqRx6qN0ONF4jMMK8A2ix/FhzaW3XDKJc5EXuUTgEqTk77 VuRuuxYTMJppFF8VV+qhKAVQTQeCiBjS3ahQZcTTSfcOcMAD+Y2enC6aEM7JQDvzXJaGntNy8sq WQB3m7/gGWE6P2F0/YeguDLnYduTm4g1DVWZfu4u7JJsErDJspuRjqV9KeGfY1VWtTEm/eHTj/N TE2749bbaGytYVDjSLJ/z9eBnHHjsSxQMryeEsYE1MLQqN7hzy1WDM= X-Received: by 2002:a05:600c:3110:b0:4a0:b6:4619 with SMTP id 5b1f17b1804b1-4a168069b91mr149082325e9.0.1791222869694; Mon, 05 Oct 2026 10:54:29 -0700 (PDT) From: =?UTF-8?q?Gabriel=20Quint=C3=A1ns=20Souto?= To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, julien@xen.org, bertrand.marquis@arm.com, sstabellini@kernel.org, =?UTF-8?q?Gabriel=20Quint=C3=A1ns=20Souto?= Subject: [PATCH v2] xen/arm: validate non-common page-table ranges Date: Mon, 5 Oct 2026 19:52:58 +0200 Message-ID: <20261005175258.101303-1-gabi.qs.mail@gmail.com> X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1791222870-F70C777B-7E953AC2/0/0 X-purgate-type: clean X-purgate-size: 7894 On arm32, page-tables are different on each CPUs, although they share some common mappings. The xen_pt_update function assumed that only said mappings would be modified, but did not check this assumption. Add a range check to reject modifications to non-common mappings. Signed-off-by: Gabriel Quintáns Souto --- v2: - Inverted polarity of xen_pt_range_is_non_common() as suggested. - Moved xen_pt_range_is_common() implementation to arch-specific headers (arm32 vs arm64) instead of keeping #ifdef CONFIG_ARM_32 in pt.c (tried IS_ENABLED() for DCE, but ARM64 lacks definitions for DOMHEAP_VIRT_START/TEMPORARY_AREA_ADDR, breaking the build). - Added ASSERT_UNREACHABLE() on failure path in xen_pt_update(). --- ...alidate-non-common-page-table-ranges.patch | 87 +++++++++++++++++++ xen/arch/arm/include/asm/arm32/mm.h | 24 +++++ xen/arch/arm/include/asm/arm64/mm.h | 10 +++ xen/arch/arm/mmu/pt.c | 30 +------ 4 files changed, 125 insertions(+), 26 deletions(-) create mode 100644 v1-0001-xen-arm-validate-non-common-page-table-ranges.patch diff --git a/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch b/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch new file mode 100644 index 0000000..9f04107 --- /dev/null +++ b/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch @@ -0,0 +1,87 @@ +From 21cd59798dafea289feeecd94f39890e99497525 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Gabriel=20Quint=C3=A1ns=20Souto?= +Date: Fri, 2 Oct 2026 20:17:05 +0200 +Subject: [PATCH v1] xen/arm: validate non-common page-table ranges +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +On arm32, page-tables are different on each CPUs, although they share some +common mappings. + +The xen_pt_update function assumed that only said mappings would be +modified, but did not check this assumption. + +Add a range check to reject modifications to non-common mappings. + +Signed-off-by: Gabriel Quintáns Souto +--- + xen/arch/arm/mmu/pt.c | 36 +++++++++++++++++++++++++++++------- + 1 file changed, 29 insertions(+), 7 deletions(-) + +diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c +index 621b47d..ad0d1e6 100644 +--- a/xen/arch/arm/mmu/pt.c ++++ b/xen/arch/arm/mmu/pt.c +@@ -13,6 +13,7 @@ + + #include + #include ++#include + + #ifdef NDEBUG + static inline void +@@ -589,6 +590,29 @@ static unsigned int xen_pt_check_contig(unsigned long vfn, mfn_t mfn, + return XEN_PT_4K_NR_CONTIG; + } + ++#ifdef CONFIG_ARM_32 ++static bool ranges_overlap(unsigned long start1, unsigned long size1, ++ unsigned long start2, unsigned long size2) ++{ ++ if ( start1 < start2 ) ++ return start2 - start1 < size1; ++ ++ return start1 - start2 < size2; ++} ++ ++static bool xen_pt_range_is_non_common(unsigned long virt, ++ unsigned long size) ++{ ++ unsigned long temporary_start = TEMPORARY_AREA_ADDR(0); ++ unsigned long temporary_size = XEN_PT_LEVEL_SIZE(1); ++ ++ return ranges_overlap(virt, size, ++ DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) || ++ ranges_overlap(virt, size, ++ temporary_start, temporary_size); ++} ++#endif ++ + static DEFINE_SPINLOCK(xen_pt_lock); + + static int xen_pt_update(unsigned long virt, +@@ -601,15 +625,13 @@ static int xen_pt_update(unsigned long virt, + unsigned long vfn = virt >> PAGE_SHIFT; + unsigned long left = nr_mfns; + +- /* +- * For arm32, page-tables are different on each CPUs. Yet, they share +- * some common mappings. It is assumed that only common mappings +- * will be modified with this function. +- * +- * XXX: Add a check. +- */ + const mfn_t root = maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); + ++ #ifdef CONFIG_ARM_32 ++ if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) ) ++ return -EINVAL; ++ #endif ++ + if ( flags_has_rwx(flags) ) + { + mm_printk("Mappings should not be both Writeable and Executable.\n"); +-- +2.54.0 + diff --git a/xen/arch/arm/include/asm/arm32/mm.h b/xen/arch/arm/include/asm/arm32/mm.h index 856f2db..c7d09d3 100644 --- a/xen/arch/arm/include/asm/arm32/mm.h +++ b/xen/arch/arm/include/asm/arm32/mm.h @@ -16,6 +16,30 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) return false; } +static inline bool ranges_overlap(unsigned long start1, unsigned long size1, + unsigned long start2, unsigned long size2) +{ + if ( start1 < start2 ) + return start2 - start1 < size1; + + return start1 - start2 < size2; +} + +/* + * On ARM32, page-tables differ between CPUs, so not all mappings are common. + */ +static inline bool xen_pt_range_is_common(unsigned long virt, + unsigned long size) +{ + unsigned long temporary_start = TEMPORARY_AREA_ADDR(0); + unsigned long temporary_size = XEN_PT_LEVEL_SIZE(1); + + return !ranges_overlap(virt, size, + DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) && + !ranges_overlap(virt, size, + temporary_start, temporary_size); +} + bool init_domheap_mappings(unsigned int cpu); static inline void arch_setup_page_tables(void) diff --git a/xen/arch/arm/include/asm/arm64/mm.h b/xen/arch/arm/include/asm/arm64/mm.h index b4f7545..a3cb56d 100644 --- a/xen/arch/arm/include/asm/arm64/mm.h +++ b/xen/arch/arm/include/asm/arm64/mm.h @@ -12,6 +12,16 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) return true; } +/* + * On ARM64, the Xen page-tables are shared by all the CPUs, + * any range is therefore common. + */ +static inline bool xen_pt_range_is_common(unsigned long virt, + unsigned long size) +{ + return true; +} + void arch_setup_page_tables(void); void update_boot_mapping(bool enable); diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c index ad0d1e6..5e1b427 100644 --- a/xen/arch/arm/mmu/pt.c +++ b/xen/arch/arm/mmu/pt.c @@ -590,29 +590,6 @@ static unsigned int xen_pt_check_contig(unsigned long vfn, mfn_t mfn, return XEN_PT_4K_NR_CONTIG; } -#ifdef CONFIG_ARM_32 -static bool ranges_overlap(unsigned long start1, unsigned long size1, - unsigned long start2, unsigned long size2) -{ - if ( start1 < start2 ) - return start2 - start1 < size1; - - return start1 - start2 < size2; -} - -static bool xen_pt_range_is_non_common(unsigned long virt, - unsigned long size) -{ - unsigned long temporary_start = TEMPORARY_AREA_ADDR(0); - unsigned long temporary_size = XEN_PT_LEVEL_SIZE(1); - - return ranges_overlap(virt, size, - DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) || - ranges_overlap(virt, size, - temporary_start, temporary_size); -} -#endif - static DEFINE_SPINLOCK(xen_pt_lock); static int xen_pt_update(unsigned long virt, @@ -627,10 +604,11 @@ static int xen_pt_update(unsigned long virt, const mfn_t root = maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); - #ifdef CONFIG_ARM_32 - if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) ) + if ( !xen_pt_range_is_common(virt, nr_mfns * PAGE_SIZE) ) + { + ASSERT_UNREACHABLE(); return -EINVAL; - #endif + } if ( flags_has_rwx(flags) ) { -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 18:00:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 18:00:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441090.1658706 (Exim 4.92) (envelope-from ) id 1xDmz3-00014G-8Q; Mon, 05 Oct 2026 18:00:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441090.1658706; Mon, 05 Oct 2026 18:00: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 1xDmz3-000149-5G; Mon, 05 Oct 2026 18:00:17 +0000 Received: by outflank-mailman (input) for mailman id 1441090; Mon, 05 Oct 2026 18:00:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDmz1-000143-MI for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:00:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDmz0-006t1w-SS for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 20:00:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3e573-2eae-0a2a0a5409dd-0a2a4505cc12-38 for ; Mon, 05 Oct 2026 20:00:14 +0200 Received: from [74.125.225.98] (helo=mail-wr2-f34.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3e5ae-4cb1-0a2a45050019-4a7de1629ca8-3 for ; Mon, 05 Oct 2026 20:00:14 +0200 Received: by mail-wr2-f34.google.com with SMTP id ffacd0b85a97d-48af5ae31d8so1558353f8f.2 for ; Mon, 05 Oct 2026 11:00:14 -0700 (PDT) Received: from ws-fedora.tail006fee.ts.net (cm-93-156-216-249.telecable.es. [93.156.216.249]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48c622907fesm5312951f8f.26.2026.10.05.11.00.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2026 11:00: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: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=1791223214; x=1791828014; 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=lg//XOkHoxzTHuefAMSiqaJqd/+zKvdBQBqoUAddV/4=; b=iOHgSazzwKUwuXJT8q+IqrXO96D8NcA2xLJHsE7dpO0gLx3gOYQyhJFgh6X1Q9Ees1 r18jTedTTwCBKlrZKpH1X3FilCTTct337othNcYSubkaRg5OkupAjAHconq10eySbIzL rFXQCMoFTfNG05xX54Ek6cIGvl+eg3KYcAp7on/NhmNGwn3KLeDE+QZ8yhIb4xfmHgv0 ohRrC0Bu+GsHM7wBZEaAtJbqTbqTD2pK49x2/UAx6fsYPCIPpw79CzCXQ24tonzjdaCm tmGzDQKAahWJ5KBa9JvXghvwfDiRNyO+fMOTyA4paDuN5TtgtaUNd/oiaiMPTytrJGha ATxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791223214; x=1791828014; 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=lg//XOkHoxzTHuefAMSiqaJqd/+zKvdBQBqoUAddV/4=; b=M9r9vjJ0CC2ctSoGfjzeFbZoMX1ziVzhLG0alCOljeg/lzEiqsLIEEajqY1c25r9Vc 1Md0/0Pkak4vd47CCLeSz2X2wPeOTRoHI4gN/a3uY8BumY9bngASBnyAWCwzDbfvpLUC BhSYgcQ64uTZOiBD9FTQ4og02goGwmJPCCGN48CHqauAyRZeKkCXnrSmFus3VbkYCOnI vB81Gd67eIczavRTqNrGOGHRbMVzpaYaujlGUrcSdwnvDYZ3bsep/P+4zL1sbJQtLr5t NlKPsWOph6OUAC/AfZ8/keSxlfh4XxssJ96E4DwzK4geGB+z1wBP1VpYzL2jnQqQE0Dd kBJQ== X-Gm-Message-State: AFq9FYLqOlMGM36qliBjpQviS5o10EtT+yYJ5ByPkB0syXQxFP9Zec+S 2I9PpxLS0jXDvL0hWNrX412Ce0pQqTnOKSdh8hVI7ANfi/ObqXzKlV4ez4qwvvAW X-Gm-Gg: AYBFou1jqVVIOla64ODhaPKBu42h7+5T40ynxZ3tb9uqhzQeOCpW3nj9EmXyUskEdJR 0mMcTqk7X0lhiqf/NR85EcX0oqL3MEqiOi9rnnaJFXJCuCwWGIXO0e8WtN07qu3UPYHf/wfsOJK 774m6f+vLUhQn/tXcU3G+Bh8vJItOVuNr+eGv6PgCrEzoq1gJqJrKzvinGwZ7WYa+VVEu5e0AgX yPgmtMATODtHvwiStF1ptg812n+8fo8HhE9iSDY93alIP+ra+KMIQdsfbiUu3dwJ4yO+cJgAnQR ZWTVM9BtWtfQcMTV/Vp5+6idM9XSXCVkTcP51kR0wX3qSOH23WBkQ5V2qW4T8JmbvubSUBEe9in jJl4nhSJ63TSQkP68wQ7I/oXlMMpwO4q5NJjUi+POfWCtO0k+16dva9MPEvk3zvAdplmuCIG6B5 axIIaV6nmDMfellWMm7Qn1gonc8GAy1YY2CQ93TjWcbzGF+agEiprlzdgJiXrXOgbdnpDxvvJKG CYw1bruPkvUO0Vilqhxy0PiwCx32g7s5HZAqjeDrlxLssMN/Js9j5c= X-Received: by 2002:a05:6000:178f:b0:488:8436:b343 with SMTP id ffacd0b85a97d-48b1271aa6fmr20188534f8f.37.1791223213942; Mon, 05 Oct 2026 11:00:13 -0700 (PDT) From: =?UTF-8?q?Gabriel=20Quint=C3=A1ns=20Souto?= To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, julien@xen.org, bertrand.marquis@arm.com, sstabellini@kernel.org, =?UTF-8?q?Gabriel=20Quint=C3=A1ns=20Souto?= Subject: [PATCH v3] xen/arm: validate non-common page-table ranges Date: Mon, 5 Oct 2026 19:59:40 +0200 Message-ID: <20261005175940.103249-1-gabi.qs.mail@gmail.com> X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1791223214-F70B22A1-F9D967F2/0/0 X-purgate-type: clean X-purgate-size: 4605 On arm32, page-tables are different on each CPUs, although they share some common mappings. The xen_pt_update function assumed that only said mappings would be modified, but did not check this assumption. Add a range check to reject modifications to non-common mappings. Signed-off-by: Gabriel Quintáns Souto --- v3: - Dropped accidentally tracked patch file from commit. v2: - Inverted polarity of xen_pt_range_is_non_common() as suggested. - Moved xen_pt_range_is_common() implementation to arch-specific headers (arm32 vs arm64) instead of keeping #ifdef CONFIG_ARM_32 in pt.c (tried IS_ENABLED() for DCE, but ARM64 lacks definitions for DOMHEAP_VIRT_START/TEMPORARY_AREA_ADDR, breaking the build). - Added ASSERT_UNREACHABLE() on failure path in xen_pt_update(). --- xen/arch/arm/include/asm/arm32/mm.h | 24 +++++++++++++++++++++++ xen/arch/arm/include/asm/arm64/mm.h | 10 ++++++++++ xen/arch/arm/mmu/pt.c | 30 ++++------------------------- 3 files changed, 38 insertions(+), 26 deletions(-) diff --git a/xen/arch/arm/include/asm/arm32/mm.h b/xen/arch/arm/include/asm/arm32/mm.h index 856f2db..c7d09d3 100644 --- a/xen/arch/arm/include/asm/arm32/mm.h +++ b/xen/arch/arm/include/asm/arm32/mm.h @@ -16,6 +16,30 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) return false; } +static inline bool ranges_overlap(unsigned long start1, unsigned long size1, + unsigned long start2, unsigned long size2) +{ + if ( start1 < start2 ) + return start2 - start1 < size1; + + return start1 - start2 < size2; +} + +/* + * On ARM32, page-tables differ between CPUs, so not all mappings are common. + */ +static inline bool xen_pt_range_is_common(unsigned long virt, + unsigned long size) +{ + unsigned long temporary_start = TEMPORARY_AREA_ADDR(0); + unsigned long temporary_size = XEN_PT_LEVEL_SIZE(1); + + return !ranges_overlap(virt, size, + DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) && + !ranges_overlap(virt, size, + temporary_start, temporary_size); +} + bool init_domheap_mappings(unsigned int cpu); static inline void arch_setup_page_tables(void) diff --git a/xen/arch/arm/include/asm/arm64/mm.h b/xen/arch/arm/include/asm/arm64/mm.h index b4f7545..a3cb56d 100644 --- a/xen/arch/arm/include/asm/arm64/mm.h +++ b/xen/arch/arm/include/asm/arm64/mm.h @@ -12,6 +12,16 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) return true; } +/* + * On ARM64, the Xen page-tables are shared by all the CPUs, + * any range is therefore common. + */ +static inline bool xen_pt_range_is_common(unsigned long virt, + unsigned long size) +{ + return true; +} + void arch_setup_page_tables(void); void update_boot_mapping(bool enable); diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c index ad0d1e6..5e1b427 100644 --- a/xen/arch/arm/mmu/pt.c +++ b/xen/arch/arm/mmu/pt.c @@ -590,29 +590,6 @@ static unsigned int xen_pt_check_contig(unsigned long vfn, mfn_t mfn, return XEN_PT_4K_NR_CONTIG; } -#ifdef CONFIG_ARM_32 -static bool ranges_overlap(unsigned long start1, unsigned long size1, - unsigned long start2, unsigned long size2) -{ - if ( start1 < start2 ) - return start2 - start1 < size1; - - return start1 - start2 < size2; -} - -static bool xen_pt_range_is_non_common(unsigned long virt, - unsigned long size) -{ - unsigned long temporary_start = TEMPORARY_AREA_ADDR(0); - unsigned long temporary_size = XEN_PT_LEVEL_SIZE(1); - - return ranges_overlap(virt, size, - DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) || - ranges_overlap(virt, size, - temporary_start, temporary_size); -} -#endif - static DEFINE_SPINLOCK(xen_pt_lock); static int xen_pt_update(unsigned long virt, @@ -627,10 +604,11 @@ static int xen_pt_update(unsigned long virt, const mfn_t root = maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); - #ifdef CONFIG_ARM_32 - if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) ) + if ( !xen_pt_range_is_common(virt, nr_mfns * PAGE_SIZE) ) + { + ASSERT_UNREACHABLE(); return -EINVAL; - #endif + } if ( flags_has_rwx(flags) ) { -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 18:09:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 18:09:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441100.1658715 (Exim 4.92) (envelope-from ) id 1xDn82-0001yM-5S; Mon, 05 Oct 2026 18:09:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441100.1658715; Mon, 05 Oct 2026 18: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 1xDn82-0001yF-27; Mon, 05 Oct 2026 18:09:34 +0000 Received: by outflank-mailman (input) for mailman id 1441100; Mon, 05 Oct 2026 18:09:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDn80-0001y9-T0 for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:09:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDn80-003GEL-9W for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 20:09:32 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3e7da-8faa-0a2a0a5109dd-0a2a4507b226-2 for ; Mon, 05 Oct 2026 20:09:32 +0200 Received: from [74.125.228.96] (helo=mail-ed2-f32.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3e7dc-b4ea-0a2a45070019-4a7de460b510-3 for ; Mon, 05 Oct 2026 20:09:32 +0200 Received: by mail-ed2-f32.google.com with SMTP id 4fb4d7f45d1cf-6af7d702c76so2753256a12.1 for ; Mon, 05 Oct 2026 11:09: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-Type:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1791223772; cv=none; d=google.com; s=arc-20260327; b=K848G0vjF9SSILmLk1/4FwPDccCK+MPo4a3vRWSRoJsTeBNK8sw7EQSGoRJ1lbZoL8 toxwR8XuvStwDeU8eNxPD57Y3naIDtRuFn0zwPCpoaeYqfRH2Zv0Qsuqi1c+E3581Jvk ES3SRFsiIDDmDtNEOb9D5+Nm8o7wsEJD1auvipa1H/IOCwLUwZYci2Cl6Cd9O6oIFLUy 94dRU3M/kRaUbuL0jUOfv25EyaHyvTb143F5TRX25CdZzC8vN9HuCRXNXAEKq0PnxykO KZvkP/UieZI3HNpUEY7BzDzcqIkj5iahnkWZoj28Z9yZxgCRF3l5U53+9JJ08yKWnd0E unkA== 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=+E3n7efndYsIolQFRyzLYwCoF9ey9KM05X/9TVoD4+w=; fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=; b=THdt/8DqALbGVDfnUcbD6zVwMK7JFZ61VcyeTGx+n7r7jI7lk7v7rpwXLuVk/dlCcU 4SnE3J0rq02QIEjXqQBglxBM2/WLI2X8H3xy7yMf2i6Jv9yHYsL7TpVbXkgGoXjwVRY3 j2kaCcVN2S7dM/eHUmQLF7ccHO19KhZjT5UZyCAx/6qs/2/4MQ+GDU7u62X0DAczD930 eTKpZabwCpXV7aJAM1kv8DvVep/sm9T8Sg9usBcFt9Uu/Qz5PtPwIPvB+25VouY0K547 VImBT6OpcCZMlKu7A3osFKNsJO0e+3TczVdft66vMFOv/Z/wnB1yEJvX8iYPZ9vxrx8C hK4w==; 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=1791223772; x=1791828572; 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=+E3n7efndYsIolQFRyzLYwCoF9ey9KM05X/9TVoD4+w=; b=lo1KVYtqLlbdsC9nKWg9vUF+l0Fo51zlenJNbRnmQn0QwUp7rsrAMOxzqGDlioadqE V7UG8Hv4oFYHxmpGvCh3kGldgJnqdke37GimOcjGfp3Tzq48Omut612cPpfmSAuykhal 9WspXqYfLkIyhOonoZB4jjNOZayrdVVHxi0dpVZJikOYOZ8TYhBRqZ+mkxKfpjBJvh0Z IcIIKb8jF1gDmwBKYE8awIQtx49+Hg9LJOrmFpdZb+2vgPPWRUwxWxqXkLkdNUYG2jAC YivY74/dNL5FEeavw621TSvT3TiyTObv2DOvCJScOpPATymFNlKa77MwF1z/CQUf49fu kAoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791223772; x=1791828572; 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=+E3n7efndYsIolQFRyzLYwCoF9ey9KM05X/9TVoD4+w=; b=VtOD97qmh5VibD1SQw7Wc/ikQA94gmZa5PDj2BN6WYJPVyclBDA5A4lQ04rC53Inc+ Vjz4lXJzy02b5awFflWoyYS7sP3E0W3l/eEIKVEV5+E9gZl55bqHpjikaM+4GskWCiFB rTfJa43iqHUNfmmWiYuES70YzwnlpF954OVkNb4HjRpq+surBkb5FVN3k7UTwNEffySS Z68cMfB5pP5yyw3E/EEVPxzBpVE1GGobAbSKvDEL2B38jei7EHK4avgxiUa6FUbCz3Z0 p3fM0rktjUL1p8qraA5P7kBftBi6dPyELaaRmRQ17Lq3RRjou/Qv4cXf2om7xqIPO5nL Uqfw== X-Gm-Message-State: AFuF++llgGXDKJCBvhcSbKu7/mbi/Rq2me9plaQolBp3SpDdFGdGu/vn uqGOe1QIC49xMqLhZJ7a2lwnUAs1lKRatcNw86ToNO8m1t8PwzNaaiCu5CKE6hrc9AsDI5mFpeO RP9ngnfUU/i0feKFPY74Qx6P/RFGBgrcDDsfcR+M= X-Gm-Gg: AYBFou2uw6ZYW1AJ0ZfwEMuvhCJ/xGC6IDlGx1QLykP39QaQvbeaorWljf3dVPitD/8 c2VNk2l3dJcFZsRRh6ocOkz2o2tqTvDjkiZRgEvIB3v0lNdDIgDm2RMFQFcAsVM72RxaxD/BMaa xwuNEDO5xSAP8Rdv8izR2vTczKWtSeVUDnbuqoSGxNgML3ZNeaSuhc3m1wkEgtmoehYhD9ngogZ M8wJEf8FdBsM06C23UNPbjngQ823gfvNjO4XaidleRbxTRkNE4f6Ji4GfW5UD0X3dXI725IPOio M+1uZwrp13xv7m8zfZOxPo6fCkblAFNOTS7szwe6R/LsKlfTVxhMCh06pLNp4EmeXPY= X-Received: by 2002:a17:907:94cd:b0:c2e:3d17:5265 with SMTP id a640c23a62f3a-c2e4acecd07mr1083234166b.21.1791223771669; Mon, 05 Oct 2026 11:09:31 -0700 (PDT) MIME-Version: 1.0 References: <20261005175258.101303-1-gabi.qs.mail@gmail.com> In-Reply-To: <20261005175258.101303-1-gabi.qs.mail@gmail.com> From: =?UTF-8?Q?Gabriel_Quint=C3=A1ns_Souto?= Date: Mon, 5 Oct 2026 20:09:19 +0200 X-Gm-Features: AclHuK8HMkStYxsM4d3TcEYemmfvYUdqUMwaSgDPdZwkYNi2p2cffqUAliw-tlk Message-ID: Subject: Re: [PATCH v2] xen/arm: validate non-common page-table ranges To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000009fab4f065d1bc823" X-purgate-ID: tlsNG-ef75cf/1791223772-A4ECEAE4-31F06840/0/0 X-purgate-type: clean X-purgate-size: 20727 --0000000000009fab4f065d1bc823 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the noise, please ignore v2, accidentally committed a local file. Just sent v3. Best regards, Gabriel On Mon, Oct 5, 2026 at 7:54=E2=80=AFPM Gabriel Quint=C3=A1ns Souto < gabi.qs.mail@gmail.com> wrote: > On arm32, page-tables are different on each CPUs, although they share som= e > common mappings. > > The xen_pt_update function assumed that only said mappings would be > modified, but did not check this assumption. > > Add a range check to reject modifications to non-common mappings. > > Signed-off-by: Gabriel Quint=C3=A1ns Souto > --- > v2: > - Inverted polarity of xen_pt_range_is_non_common() as suggested. > - Moved xen_pt_range_is_common() implementation to arch-specific headers > (arm32 vs arm64) instead of keeping #ifdef CONFIG_ARM_32 in pt.c (tried > IS_ENABLED() for DCE, but ARM64 lacks definitions for > DOMHEAP_VIRT_START/TEMPORARY_AREA_ADDR, breaking the build). > - Added ASSERT_UNREACHABLE() on failure path in xen_pt_update(). > --- > ...alidate-non-common-page-table-ranges.patch | 87 +++++++++++++++++++ > xen/arch/arm/include/asm/arm32/mm.h | 24 +++++ > xen/arch/arm/include/asm/arm64/mm.h | 10 +++ > xen/arch/arm/mmu/pt.c | 30 +------ > 4 files changed, 125 insertions(+), 26 deletions(-) > create mode 100644 > v1-0001-xen-arm-validate-non-common-page-table-ranges.patch > > diff --git a/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch > b/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch > new file mode 100644 > index 0000000..9f04107 > --- /dev/null > +++ b/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch > @@ -0,0 +1,87 @@ > +From 21cd59798dafea289feeecd94f39890e99497525 Mon Sep 17 00:00:00 2001 > +From: =3D?UTF-8?q?Gabriel=3D20Quint=3DC3=3DA1ns=3D20Souto?=3D > > +Date: Fri, 2 Oct 2026 20:17:05 +0200 > +Subject: [PATCH v1] xen/arm: validate non-common page-table ranges > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=3DUTF-8 > +Content-Transfer-Encoding: 8bit > + > +On arm32, page-tables are different on each CPUs, although they share so= me > +common mappings. > + > +The xen_pt_update function assumed that only said mappings would be > +modified, but did not check this assumption. > + > +Add a range check to reject modifications to non-common mappings. > + > +Signed-off-by: Gabriel Quint=C3=A1ns Souto > +--- > + xen/arch/arm/mmu/pt.c | 36 +++++++++++++++++++++++++++++------- > + 1 file changed, 29 insertions(+), 7 deletions(-) > + > +diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c > +index 621b47d..ad0d1e6 100644 > +--- a/xen/arch/arm/mmu/pt.c > ++++ b/xen/arch/arm/mmu/pt.c > +@@ -13,6 +13,7 @@ > + > + #include > + #include > ++#include > + > + #ifdef NDEBUG > + static inline void > +@@ -589,6 +590,29 @@ static unsigned int xen_pt_check_contig(unsigned > long vfn, mfn_t mfn, > + return XEN_PT_4K_NR_CONTIG; > + } > + > ++#ifdef CONFIG_ARM_32 > ++static bool ranges_overlap(unsigned long start1, unsigned long size1, > ++ unsigned long start2, unsigned long size2) > ++{ > ++ if ( start1 < start2 ) > ++ return start2 - start1 < size1; > ++ > ++ return start1 - start2 < size2; > ++} > ++ > ++static bool xen_pt_range_is_non_common(unsigned long virt, > ++ unsigned long size) > ++{ > ++ unsigned long temporary_start =3D TEMPORARY_AREA_ADDR(0); > ++ unsigned long temporary_size =3D XEN_PT_LEVEL_SIZE(1); > ++ > ++ return ranges_overlap(virt, size, > ++ DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) || > ++ ranges_overlap(virt, size, > ++ temporary_start, temporary_size); > ++} > ++#endif > ++ > + static DEFINE_SPINLOCK(xen_pt_lock); > + > + static int xen_pt_update(unsigned long virt, > +@@ -601,15 +625,13 @@ static int xen_pt_update(unsigned long virt, > + unsigned long vfn =3D virt >> PAGE_SHIFT; > + unsigned long left =3D nr_mfns; > + > +- /* > +- * For arm32, page-tables are different on each CPUs. Yet, they sha= re > +- * some common mappings. It is assumed that only common mappings > +- * will be modified with this function. > +- * > +- * XXX: Add a check. > +- */ > + const mfn_t root =3D maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); > + > ++ #ifdef CONFIG_ARM_32 > ++ if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) ) > ++ return -EINVAL; > ++ #endif > ++ > + if ( flags_has_rwx(flags) ) > + { > + mm_printk("Mappings should not be both Writeable and > Executable.\n"); > +-- > +2.54.0 > + > diff --git a/xen/arch/arm/include/asm/arm32/mm.h > b/xen/arch/arm/include/asm/arm32/mm.h > index 856f2db..c7d09d3 100644 > --- a/xen/arch/arm/include/asm/arm32/mm.h > +++ b/xen/arch/arm/include/asm/arm32/mm.h > @@ -16,6 +16,30 @@ static inline bool arch_mfns_in_directmap(unsigned lon= g > mfn, unsigned long nr) > return false; > } > > +static inline bool ranges_overlap(unsigned long start1, unsigned long > size1, > + unsigned long start2, unsigned long size2) > +{ > + if ( start1 < start2 ) > + return start2 - start1 < size1; > + > + return start1 - start2 < size2; > +} > + > +/* > + * On ARM32, page-tables differ between CPUs, so not all mappings are > common. > + */ > +static inline bool xen_pt_range_is_common(unsigned long virt, > + unsigned long size) > +{ > + unsigned long temporary_start =3D TEMPORARY_AREA_ADDR(0); > + unsigned long temporary_size =3D XEN_PT_LEVEL_SIZE(1); > + > + return !ranges_overlap(virt, size, > + DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) && > + !ranges_overlap(virt, size, > + temporary_start, temporary_size); > +} > + > bool init_domheap_mappings(unsigned int cpu); > > static inline void arch_setup_page_tables(void) > diff --git a/xen/arch/arm/include/asm/arm64/mm.h > b/xen/arch/arm/include/asm/arm64/mm.h > index b4f7545..a3cb56d 100644 > --- a/xen/arch/arm/include/asm/arm64/mm.h > +++ b/xen/arch/arm/include/asm/arm64/mm.h > @@ -12,6 +12,16 @@ static inline bool arch_mfns_in_directmap(unsigned lon= g > mfn, unsigned long nr) > return true; > } > > +/* > + * On ARM64, the Xen page-tables are shared by all the CPUs, > + * any range is therefore common. > + */ > +static inline bool xen_pt_range_is_common(unsigned long virt, > + unsigned long size) > +{ > + return true; > +} > + > void arch_setup_page_tables(void); > > void update_boot_mapping(bool enable); > diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c > index ad0d1e6..5e1b427 100644 > --- a/xen/arch/arm/mmu/pt.c > +++ b/xen/arch/arm/mmu/pt.c > @@ -590,29 +590,6 @@ static unsigned int xen_pt_check_contig(unsigned lon= g > vfn, mfn_t mfn, > return XEN_PT_4K_NR_CONTIG; > } > > -#ifdef CONFIG_ARM_32 > -static bool ranges_overlap(unsigned long start1, unsigned long size1, > - unsigned long start2, unsigned long size2) > -{ > - if ( start1 < start2 ) > - return start2 - start1 < size1; > - > - return start1 - start2 < size2; > -} > - > -static bool xen_pt_range_is_non_common(unsigned long virt, > - unsigned long size) > -{ > - unsigned long temporary_start =3D TEMPORARY_AREA_ADDR(0); > - unsigned long temporary_size =3D XEN_PT_LEVEL_SIZE(1); > - > - return ranges_overlap(virt, size, > - DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) || > - ranges_overlap(virt, size, > - temporary_start, temporary_size); > -} > -#endif > - > static DEFINE_SPINLOCK(xen_pt_lock); > > static int xen_pt_update(unsigned long virt, > @@ -627,10 +604,11 @@ static int xen_pt_update(unsigned long virt, > > const mfn_t root =3D maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); > > - #ifdef CONFIG_ARM_32 > - if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) ) > + if ( !xen_pt_range_is_common(virt, nr_mfns * PAGE_SIZE) ) > + { > + ASSERT_UNREACHABLE(); > return -EINVAL; > - #endif > + } > > if ( flags_has_rwx(flags) ) > { > -- > 2.54.0 > > --0000000000009fab4f065d1bc823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the noise, please ignore v2, accidentally c= ommitted a local file. Just sent v3.

Best regards,
Gabriel

On Mon, Oct 5, 2026 at = 7:54=E2=80=AFPM Gabriel Quint=C3=A1ns Souto <gabi.qs.mail@gmail.com> wrote:
On arm32, page-tables are different on= each CPUs, although they share some
common mappings.

The xen_pt_update function assumed that only said mappings would be
modified, but did not check this assumption.

Add a range check to reject modifications to non-common mappings.

Signed-off-by: Gabriel Quint=C3=A1ns Souto <gabi.qs.mail@gmail.com>
---
v2:
- Inverted polarity of xen_pt_range_is_non_common() as suggested.
- Moved xen_pt_range_is_common() implementation to arch-specific headers (arm32 vs arm64) instead of keeping #ifdef CONFIG_ARM_32 in pt.c (tried
IS_ENABLED() for DCE, but ARM64 lacks definitions for
DOMHEAP_VIRT_START/TEMPORARY_AREA_ADDR, breaking the build).
- Added ASSERT_UNREACHABLE() on failure path in xen_pt_update().
---
=C2=A0...alidate-non-common-page-table-ranges.patch | 87 ++++++++++++++++++= +
=C2=A0xen/arch/arm/include/asm/arm32/mm.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| 24 +++++
=C2=A0xen/arch/arm/include/asm/arm64/mm.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| 10 +++
=C2=A0xen/arch/arm/mmu/pt.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 30 +------
=C2=A04 files changed, 125 insertions(+), 26 deletions(-)
=C2=A0create mode 100644 v1-0001-xen-arm-validate-non-common-page-table-ran= ges.patch

diff --git a/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch b/= v1-0001-xen-arm-validate-non-common-page-table-ranges.patch
new file mode 100644
index 0000000..9f04107
--- /dev/null
+++ b/v1-0001-xen-arm-validate-non-common-page-table-ranges.patch
@@ -0,0 +1,87 @@
+From 21cd59798dafea289feeecd94f39890e99497525 Mon Sep 17 00:00:00 2001
+From: =3D?UTF-8?q?Gabriel=3D20Quint=3DC3=3DA1ns=3D20Souto?=3D <gabi.qs.mail@gmail.com= >
+Date: Fri, 2 Oct 2026 20:17:05 +0200
+Subject: [PATCH v1] xen/arm: validate non-common page-table ranges
+MIME-Version: 1.0
+Content-Type: text/plain; charset=3DUTF-8
+Content-Transfer-Encoding: 8bit
+
+On arm32, page-tables are different on each CPUs, although they share some=
+common mappings.
+
+The xen_pt_update function assumed that only said mappings would be
+modified, but did not check this assumption.
+
+Add a range check to reject modifications to non-common mappings.
+
+Signed-off-by: Gabriel Quint=C3=A1ns Souto <gabi.qs.mail@gmail.com>
+---
+ xen/arch/arm/mmu/pt.c | 36 +++++++++++++++++++++++++++++-------
+ 1 file changed, 29 insertions(+), 7 deletions(-)
+
+diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c
+index 621b47d..ad0d1e6 100644
+--- a/xen/arch/arm/mmu/pt.c
++++ b/xen/arch/arm/mmu/pt.c
+@@ -13,6 +13,7 @@
+
+ #include <asm/current.h>
+ #include <asm/fixmap.h>
++#include <asm/mmu/layout.h>
+
+ #ifdef NDEBUG
+ static inline void
+@@ -589,6 +590,29 @@ static unsigned int xen_pt_check_contig(unsigned long= vfn, mfn_t mfn,
+=C2=A0 =C2=A0 =C2=A0return XEN_PT_4K_NR_CONTIG;
+ }
+
++#ifdef CONFIG_ARM_32
++static bool ranges_overlap(unsigned long start1, unsigned long size1,
++=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0unsigned long start2, unsigned long size2)
++{
++=C2=A0 =C2=A0 if ( start1 < start2 )
++=C2=A0 =C2=A0 =C2=A0 =C2=A0 return start2 - start1 < size1;
++
++=C2=A0 =C2=A0 return start1 - start2 < size2;
++}
++
++static bool xen_pt_range_is_non_common(unsigned long virt,
++=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned = long size)
++{
++=C2=A0 =C2=A0 unsigned long temporary_start =3D TEMPORARY_AREA_ADDR(0); ++=C2=A0 =C2=A0 unsigned long temporary_size =3D XEN_PT_LEVEL_SIZE(1);
++
++=C2=A0 =C2=A0 return ranges_overlap(virt, size,
++=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) ||
++=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ranges_overlap(virt, size,
++=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 temporary_start, temporary_size);
++}
++#endif
++
+ static DEFINE_SPINLOCK(xen_pt_lock);
+
+ static int xen_pt_update(unsigned long virt,
+@@ -601,15 +625,13 @@ static int xen_pt_update(unsigned long virt,
+=C2=A0 =C2=A0 =C2=A0unsigned long vfn =3D virt >> PAGE_SHIFT;
+=C2=A0 =C2=A0 =C2=A0unsigned long left =3D nr_mfns;
+
+-=C2=A0 =C2=A0 /*
+-=C2=A0 =C2=A0 =C2=A0* For arm32, page-tables are different on each CPUs. = Yet, they share
+-=C2=A0 =C2=A0 =C2=A0* some common mappings. It is assumed that only commo= n mappings
+-=C2=A0 =C2=A0 =C2=A0* will be modified with this function.
+-=C2=A0 =C2=A0 =C2=A0*
+-=C2=A0 =C2=A0 =C2=A0* XXX: Add a check.
+-=C2=A0 =C2=A0 =C2=A0*/
+=C2=A0 =C2=A0 =C2=A0const mfn_t root =3D maddr_to_mfn(READ_SYSREG64(TTBR0_= EL2));
+
++=C2=A0 =C2=A0 #ifdef CONFIG_ARM_32
++=C2=A0 =C2=A0 if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) = )
++=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EINVAL;
++=C2=A0 =C2=A0 #endif
++
+=C2=A0 =C2=A0 =C2=A0if ( flags_has_rwx(flags) )
+=C2=A0 =C2=A0 =C2=A0{
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mm_printk("Mappings should not be b= oth Writeable and Executable.\n");
+--
+2.54.0
+
diff --git a/xen/arch/arm/include/asm/arm32/mm.h b/xen/arch/arm/include/asm= /arm32/mm.h
index 856f2db..c7d09d3 100644
--- a/xen/arch/arm/include/asm/arm32/mm.h
+++ b/xen/arch/arm/include/asm/arm32/mm.h
@@ -16,6 +16,30 @@ static inline bool arch_mfns_in_directmap(unsigned long = mfn, unsigned long nr)
=C2=A0 =C2=A0 =C2=A0return false;
=C2=A0}

+static inline bool ranges_overlap(unsigned long start1, unsigned long size= 1,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0unsigned long start2, unsigned long size2)
+{
+=C2=A0 =C2=A0 if ( start1 < start2 )
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return start2 - start1 < size1;
+
+=C2=A0 =C2=A0 return start1 - start2 < size2;
+}
+
+/*
+ * On ARM32, page-tables differ between CPUs, so not all mappings are comm= on.
+ */
+static inline bool xen_pt_range_is_common(unsigned long virt,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned = long size)
+{
+=C2=A0 =C2=A0 unsigned long temporary_start =3D TEMPORARY_AREA_ADDR(0); +=C2=A0 =C2=A0 unsigned long temporary_size =3D XEN_PT_LEVEL_SIZE(1);
+
+=C2=A0 =C2=A0 return !ranges_overlap(virt, size,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) &&
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!ranges_overlap(virt, size,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 temporary_start, temporary_size);
+}
+
=C2=A0bool init_domheap_mappings(unsigned int cpu);

=C2=A0static inline void arch_setup_page_tables(void)
diff --git a/xen/arch/arm/include/asm/arm64/mm.h b/xen/arch/arm/include/asm= /arm64/mm.h
index b4f7545..a3cb56d 100644
--- a/xen/arch/arm/include/asm/arm64/mm.h
+++ b/xen/arch/arm/include/asm/arm64/mm.h
@@ -12,6 +12,16 @@ static inline bool arch_mfns_in_directmap(unsigned long = mfn, unsigned long nr)
=C2=A0 =C2=A0 =C2=A0return true;
=C2=A0}

+/*
+ * On ARM64, the Xen page-tables are shared by all the CPUs,
+ * any range is therefore common.
+ */
+static inline bool xen_pt_range_is_common(unsigned long virt,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u= nsigned long size)
+{
+=C2=A0 =C2=A0 return true;
+}
+
=C2=A0void arch_setup_page_tables(void);

=C2=A0void update_boot_mapping(bool enable);
diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c
index ad0d1e6..5e1b427 100644
--- a/xen/arch/arm/mmu/pt.c
+++ b/xen/arch/arm/mmu/pt.c
@@ -590,29 +590,6 @@ static unsigned int xen_pt_check_contig(unsigned long = vfn, mfn_t mfn,
=C2=A0 =C2=A0 =C2=A0return XEN_PT_4K_NR_CONTIG;
=C2=A0}

-#ifdef CONFIG_ARM_32
-static bool ranges_overlap(unsigned long start1, unsigned long size1,
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0unsigned long start2, unsigned long size2)
-{
-=C2=A0 =C2=A0 if ( start1 < start2 )
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 return start2 - start1 < size1;
-
-=C2=A0 =C2=A0 return start1 - start2 < size2;
-}
-
-static bool xen_pt_range_is_non_common(unsigned long virt,
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned = long size)
-{
-=C2=A0 =C2=A0 unsigned long temporary_start =3D TEMPORARY_AREA_ADDR(0); -=C2=A0 =C2=A0 unsigned long temporary_size =3D XEN_PT_LEVEL_SIZE(1);
-
-=C2=A0 =C2=A0 return ranges_overlap(virt, size,
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 DOMHEAP_VIRT_START, DOMHEAP_VIRT_SIZE) ||
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ranges_overlap(virt, size,
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 temporary_start, temporary_size);
-}
-#endif
-
=C2=A0static DEFINE_SPINLOCK(xen_pt_lock);

=C2=A0static int xen_pt_update(unsigned long virt,
@@ -627,10 +604,11 @@ static int xen_pt_update(unsigned long virt,

=C2=A0 =C2=A0 =C2=A0const mfn_t root =3D maddr_to_mfn(READ_SYSREG64(TTBR0_E= L2));

-=C2=A0 =C2=A0 #ifdef CONFIG_ARM_32
-=C2=A0 =C2=A0 if ( xen_pt_range_is_non_common(virt, nr_mfns * PAGE_SIZE) )=
+=C2=A0 =C2=A0 if ( !xen_pt_range_is_common(virt, nr_mfns * PAGE_SIZE) ) +=C2=A0 =C2=A0 {
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 ASSERT_UNREACHABLE();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EINVAL;
-=C2=A0 =C2=A0 #endif
+=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0if ( flags_has_rwx(flags) )
=C2=A0 =C2=A0 =C2=A0{
--
2.54.0

--0000000000009fab4f065d1bc823-- From xen-devel-bounces@lists.xenproject.org Mon Oct 05 18:56:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 18:56:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441119.1658724 (Exim 4.92) (envelope-from ) id 1xDnrR-0000aF-Cb; Mon, 05 Oct 2026 18:56:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441119.1658724; Mon, 05 Oct 2026 18:56: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 1xDnrR-0000a8-9n; Mon, 05 Oct 2026 18:56:29 +0000 Received: by outflank-mailman (input) for mailman id 1441119; Mon, 05 Oct 2026 18:56:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDnrQ-0000a2-5O for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 18:56:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDnrP-003dqx-IU for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 20:56:27 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3f2d1-8faa-0a2a0a5109dd-0a2a4505ddca-6 for ; Mon, 05 Oct 2026 20:56:27 +0200 Received: from [52.101.66.72] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3f2da-4cb1-0a2a45050019-346542486dd2-3 for ; Mon, 05 Oct 2026 20:56:27 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by VI2PR03MB10810.eurprd03.prod.outlook.com (2603:10a6:800:27a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 18:56:23 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0472.016; Mon, 5 Oct 2026 18: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=GqmCEllBiFRyH6NQarpH73fcSgQaBnf6oTS8dvT9365ggspaQHar8QZtzSSK1JGNo6UqILIhuJkXfSC90nsITLtFKzx+22KlG7gOCjMvlHATnqqdMB5206tma81vCkac9wW/ADeenpEjmT9bSu0+sLjS+Cbe7MkPd8wxBQMF9hq+oIEiXJztuQV5vmXGMe/HWl7r2HAcSSt0lHidAmtn1K2AT2nrczEYxnTE9+Ox7fvBUeucamfNEhiAgiw8DPGlEjpSS3uWEtsN2/35dl8R7ZbHSnpAgmeMBHxAFuR+/3kX+UGgDKK8Xyv5eYIJl+J96UambM1S86mOUU9Jlx6ZsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gjpIctBI4RmCZYIcG2V/Hs4Wow7IW5zTz4571QN429E=; b=EN0ZxzhzcxOsqSmvGth5y18KReVPtYvaLIY3yZxnBwZM0q7LkZhlQX08aL/R+7yB6eZIpN8PaHlRhOJnLrzNhEtWLvgLACRv9IRbgLsdWb+Sku6DT6VOMcWx/587ng7IBAkaozIo3hqrDsItIMQCjLgwfS5TXyo7oyItgy0+U8yTBkbEAqQUSAYWNn9hJeTKmzUNpray64vWiAJydBTg5Squxj3nR8G4c6bATRvpQDRb0vuU4TscTU5UNgB4q5ldrZudVCFvUQPdCuniTOnmfEk+Lo9516awPZKTcgXqNfaCAG0/uvTMu77HZF0YgXrQ14TgEpgShl7uxnyLVgUDAg== 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=gjpIctBI4RmCZYIcG2V/Hs4Wow7IW5zTz4571QN429E=; b=eV2VbOdRxoLdPgcyZfeieltTe5Olfh0MmKjAanyQvMWnZ/CcqWtmQsYZ4TxcryjGVh53ImMO7ev6zWYiGpmwoAJSbdWjvXu5s0CDTl1LnEqJ+uV60QZV4daGlQoWoKE0tetx7SXdVqKpZfybt00aAEm/C0l+DkhcDodfTVcIwIuTR0GyKwQk2aIO2G++90Ljf6vq5nznKgCWQh0CwAS4e8t0CJagO3bG8FqVY7xbdHSh2swLtFKDcymAsFNdvgl/SmM1lgWUI3DumndtgLuEPj8NfCT6GVd7SLQR+f15CqZJPsn3V16peKzlwWICON+lCUiseAVhDK2/5U1Q3xE3GA== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation Thread-Topic: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation Thread-Index: AQHdVPs3la7Yb/mPXkSleujSDB++zQ== Date: Mon, 5 Oct 2026 18:56:23 +0000 Message-ID: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|VI2PR03MB10810:EE_ x-ms-office365-filtering-correlation-id: 9098d65e-c6de-4302-f656-08df231259ad x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|23010399003|42112799006|1800799024|366016|18002099003|10067099003|3023799007|38070700021|260925021311599003|260925022911599003|260925021911599003|56012099006|11063799006; x-microsoft-antispam-message-info: EqQEn/k6Hm1kFI+9LCQZLYMhSY3Kqb7Zmw0HdNmbLIizsBjIptEbzjjbTQyFIrxS7ovgO01unClb1533VL/qicsPNTFzCFMUsR1IvDvky2K/atIEToTO1lrtstfMvNhAy2AablyP3jCaZqjGmlBW+WcwmNyLip/IoRHRElx8nsuImLIA9mqxomEKRiaieuNGYw851lF7NY0PthBJlTxUskqTG3/6DMSBiqDeni9lRe0x4X/6npzsF5/052Zx689T7savBwVHyGx7i3azBKkozz0/Yg3NRXvAx6Z05/6mRIJbly41zsTbXoelWMIZVsUJU+lGSQPHMqwjdhzkvEjWWc0/1aPHD0VniCkRSSOqcsiMr1/c3DlRXvXokRoYt/SZdGMQPHzFgTgUws68aIayuByDPpFsg9W/sOdHs1VZlOvRnCAz+MGf2dbMkUtQi3oi/vOS/b1UPLcK6GFOPJGzitqim3pDB6ej3QJ9KbK4vvwxTI7hvZh5HjqaUcPqr11o98b6/nPNXXsjSimLlnbXhpF+6hlQeYPifv8eFsk13Y+IaI2ry5IFDlKtSn4DCIE+NkwvOBO4f+p82VjsATFybFSZXseCpTdFEiWUalIlO1RvNarNMHcB6htulgkRqG1j02eYYsV/pqrIvF7gzylw2aa2zmMFD3vMXLYxvHuaPlQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(42112799006)(1800799024)(366016)(18002099003)(10067099003)(3023799007)(38070700021)(260925021311599003)(260925022911599003)(260925021911599003)(56012099006)(11063799006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?sI1fsRXNqGOrmdV4pMfpUb7hM1bSyvH++IWKxMdGIAUHmx2jTpy5Xfia8h?= =?iso-8859-1?Q?7sjJiJQbeqbtyjFUnfVwRPtzBlRFPb82zMtdyQ68t5NaFm6YzhTqyiN+Zy?= =?iso-8859-1?Q?1kyC4oQBJdhiswDTzQCo/OICmW/GUVJ9FL6v4IaiBuWQvR8WBpqKVOjaGa?= =?iso-8859-1?Q?5eyJOeAknpc9zZNOtqj9oDgEBOzJkJ1JnTBJAwDN5BynCmwMyfeYn7I6OW?= =?iso-8859-1?Q?kD32p/7U+tXltaOzEUViXrt7FQC6acV5OGWSFH+Px9MvKKsOAmLLL94jW8?= =?iso-8859-1?Q?wjtqvKiHkdG4T+JH+T1kqOiv0n7M4UMODUtF/Kca0vWAhip80OYN1oZkwr?= =?iso-8859-1?Q?+6OUTYYhs/wT7R9h3ecVqaaVe7GJIxYiKVGrn9W4Hdm+pn5zTywf6DSvDy?= =?iso-8859-1?Q?zEkpPQ+wiriInV8X3bKonmHD6yGp2F56jGpxE9Q+p8TSab94bBf+HUzHP5?= =?iso-8859-1?Q?GpokRVp12yhoAdbbXWUINC/khHpkZt71XZvlb0aN62gemxl10D+6Qqlaey?= =?iso-8859-1?Q?KLCfyV82Qk1k4jrcYQN6ZF6myqAZQCTwU559NfeIqJpenTbdYeWBFdpOu+?= =?iso-8859-1?Q?0l8DppsB2M1nxQVM2GWAX7O7us/67iSYj/QfbZVGfoNRUtAbPnYTgqVCHt?= =?iso-8859-1?Q?MdUtMt5fHr0hJVd1idVq5swfVIDfPKnufC/k/8oo1JIyqnm8E1JSfNxIqO?= =?iso-8859-1?Q?VOVvgEqTBEmP/k4ojDXAwfgYfs82Fx1M4FBklFas4OuB1lYy30tdyPrhw8?= =?iso-8859-1?Q?DVRY70ephh1/Lh4NsvRAUoIlzWuWFAU6dp92qqEI/D96cluQIridI7Tedh?= =?iso-8859-1?Q?ihDTwfW/zAbkDn9XKU0SXdSidNSXYJTCNcuscWBgTrMWuF55Hd0Xaj40hH?= =?iso-8859-1?Q?LXE5MEhJUtDoR/fENAPANgQ3JasRzs4GynW/EvgxfSyLv0K6v9en6rHeYv?= =?iso-8859-1?Q?xAaCoBleJIrAONch55v3R3ct6oL0mHVcI0SReDmMnjAqIj6/0mR8Q7iI8z?= =?iso-8859-1?Q?8WLO/DhvaDTYZfNDCQlbfDCkUiPqabsuuUcbPL6l6eRoMoh0PY3QrM1Mum?= =?iso-8859-1?Q?gSc+jQF5pzIOuMgTueaWD2zE0m/lst1sgqb9ULIfcq3qaP6Q8VmkKG1/RC?= =?iso-8859-1?Q?28hN3meFcsPS6lNwIX2c2G62SZ5f3EZcM3FuDRLY6IDvhjy8QvEet3C7kX?= =?iso-8859-1?Q?M+KbD+PvPK1zpYTkhYZpyxQaKw7l5kJrfkHhdABiwBW5Evx3nHImRgy7xD?= =?iso-8859-1?Q?GNiaJ4MBsrel4tal/rtiqx5QfmSWq34ASVIxP0A3Q/DPhkGwTGctiOD+cm?= =?iso-8859-1?Q?f5TIFeKgMAxH7r/M+XNvq7I5D5fbdyVsZh1E7Cr0l3nrW9APzyOlDto9Ug?= =?iso-8859-1?Q?oUJrG+qfAnqqbNb/UZTSWa+Q0s93lOfdcbWobnJ4ftbZ80i8nOeDa0BI5O?= =?iso-8859-1?Q?qCje2yGYbwcIzt9gzCz1xApV4dqG83qWH9zIiVn16zBjQQjAJ2PZnb6QgO?= =?iso-8859-1?Q?HDdpG1WO/ytiks4ynLosWp2gLO2JHCX7woaoczIdJPILnMoAKZGf1MF038?= =?iso-8859-1?Q?tgaST6VlWUEfAzAq7nXoGbnTeUfCpaAnc4JOrnVSjcHR48q9rUJQNGjF+Z?= =?iso-8859-1?Q?CHht2vCmoEU26l/lPubl/Y9v2rOQfBg7P++42MibFV4OrG6wXY/St5UoAz?= =?iso-8859-1?Q?dzynAIrQcqq2KNL1qJyU7mq9cq6NBQXzqQrwRhaqOImXKhF+DaxiHOMcN2?= =?iso-8859-1?Q?Vb3L3Irc/NBusfdfsKtB+LHMyQLyBVSZG808iuCwIJYmkObDebB4E+8S4T?= =?iso-8859-1?Q?8fFnCnFZJz/Ykxa9EA7c05bjOLF5ECs=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9098d65e-c6de-4302-f656-08df231259ad X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2026 18:56:23.0589 (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: 9Vk99inkUEKw63l4CEYpE6xoKGD85aqhfAhDcP7BPiKzgchcJ6HSgHqGw1QU10h44prpd1egVXYXeIQHOs9sbZxZPBQ74LJhsuNGzgu+ijg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR03MB10810 X-purgate-ID: tlsNG-c201ff/1791226587-F46A52A1-54BD38C3/0/0 X-purgate-type: clean X-purgate-size: 4534 The R11.1 safe cast only matched void noreturn (*)(void *). Accept any noreturn function pointer converted to a compatible function pointer. canonical() covers typeof destinations, and compatible_deep_unqualified keeps the parameter and return types aligned. Signed-off-by: Dmytro Prokopchuk --- This patch tries to cover both of these: 1. eclair: widen R11.1 noreturn cast deviation https://patchew.org/Xen/c6632dd805a119aca54b9d1ae2eea68ef9c1334c.1790674358= .git.dmytro._5Fprokopchuk1@epam.com/ 2. Eclair: relax "noreturn" function-pointer conversion deviation https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com/4cca5= 8b6-b555-4064-aa26-5204dc4b99cc@suse.com/ Test CI pipeline: https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2914802667 The only one Rule11.1 violation remains, which is covered by this Jan's pat= ch: x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() --- automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +++++---- docs/misra/deviations.rst | 8 ++++---- docs/misra/rules.rst | 7 ++++--- 3 files changed, 13 insertions(+), 11 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/= eclair_analysis/ECLAIR/deviations.ecl index 6cdb10a129..d89976a894 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -394,11 +394,12 @@ constant expressions are required.\"" } -doc_end =20 --doc_begin=3D"The conversion from 'void noreturn (*)(void *)' to 'void (*)= (void *)' is safe -because the semantics of the 'noreturn' attribute do not alter the calling= convention or behavior of the resulting code." +-doc_begin=3D"The conversion from a noreturn function pointer to a functio= n pointer +with a compatible signature is safe because the semantics of the 'noreturn= ' +attribute do not alter the calling convention or behavior of the resulting= code." -config=3DMC3A2.R11.1,casts+=3D{safe, - "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1= , pointer(builtin(void)))))))&&from(expr(skip(!syntactic(), - ref(property(noreturn)))))"}=20 + "kind(bitcast)&&to(type(canonical(__function_pointer_types)))&&from(expr= (skip(!syntactic(), + ref(property(noreturn)))))&&relation(compatible_deep_unqualified)"} -doc_end =20 -doc_begin=3D"The conversion from a pointer to an incomplete type to unsig= ned long does not lose any information, provided that the target type has e= nough bits to store it." diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 6bcc2adf95..ed7129b8dc 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -392,10 +392,10 @@ Deviations related to MISRA C:2012 Rules: - Tagged as `safe` for ECLAIR. =20 * - R11.1 - - 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, parameters handling r= emain - consistent. + - The conversion from a noreturn function pointer to a function point= er + with a compatible signature is safe because the semantics of the + 'noreturn' attribute do not alter the calling convention or behavio= r + of the resulting code. - Tagged as `safe` for ECLAIR. =20 * - R11.2 diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index a59cf1782e..bd288bba29 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -435,9 +435,10 @@ maintainers if you want to suggest a change. and any other type - 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. + and void* are permitted. Conversions from a noreturn function point= er + to a function pointer with a compatible signature are permitted. + Conversions from [unsigned] long or '(void *)' to a function pointe= r + are permitted. Example:: =20 unsigned long func_addr =3D (unsigned long)&some_function; --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 05 19:05:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 19:05:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441128.1658733 (Exim 4.92) (envelope-from ) id 1xDo01-0002OX-B1; Mon, 05 Oct 2026 19:05:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441128.1658733; Mon, 05 Oct 2026 19:05: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 1xDo01-0002OQ-8B; Mon, 05 Oct 2026 19:05:21 +0000 Received: by outflank-mailman (input) for mailman id 1441128; Mon, 05 Oct 2026 19:05:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDo00-0002OK-8U for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 19:05:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDnzz-003fAn-LT for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 21:05:19 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3f4b4-2eae-0a2a0a5409dd-0a2a4508904a-42 for ; Mon, 05 Oct 2026 21:05:19 +0200 Received: from [52.101.65.99] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac3f4ef-f659-0a2a45080019-346541636e2d-3 for ; Mon, 05 Oct 2026 21:05:19 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by GV2PR03MB11718.eurprd03.prod.outlook.com (2603:10a6:150:341::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 19:05:16 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0472.016; Mon, 5 Oct 2026 19:05: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=k/twDXtT6X6GyaGSo9PBPdtNe6ThlpBTGdE2Kynjp+i2ORTlbInVykAgfR9t7QnuQXKdwhJ9FiQlXGB4tpsVPIu0edikeFh5PbCeCrVAgVwTGyXYTk5WAOUlB05Z+pdkexJAUxRmcV5MLwzltzG4TgoDkDN7g8GcKTqWZc5q72Inl4m58NQ4391hDPgWvNpo+UfVlLKYCZqik3SiTVIH63PpVj9s4bWMMKlWILiZnDHlLwlMFU0PCbggDjOOHpnt4dfDnXSD8k3zzKa8WKNQMGOyJSiV0kIqe/lPM4ZQqJj5fQ0qxMUgyC44ULqWGGvyTptepmoBBXGeTejnVW44ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5YMSbsnAf6Alhpa8q8KSshh4NsEukXWDr4BlgcRFka8=; b=IVjUCJtQSwzFsXd35CrWVeOwS1Fv1TVgc/O7NtEqMFmctiR7+MqtTRq8dsmANhNN6BDzjIZdDFIYrit4B/yLZwTVUrGBrZER9oXtdzlCpTjCdCI+NU3Cdrx6dHq9bAs2OuyZnp+PQ9/s/fltBkV6IR0z8SMWALZPnl5svOm+WJTL2BNaGU56sT18zajbueNp6T506dI36WsYMrQn6Q1DDI8Wgv/mBWlLkt+8ZWU1hOUCPp5YbpSZ/duVMn5DC0D4sguwycgXIuiE2jTV5WLCDGJjB/dBHsHBcpQKtsXn1F1JBHvO4rtUFL95D/WMuFKWk6ekPJvxEJ82CuHq9h747g== 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=5YMSbsnAf6Alhpa8q8KSshh4NsEukXWDr4BlgcRFka8=; b=KVnlYRBfVDkMHsISK+XHSHJ6KzEMSyuV9hThJsNr/sgJSCS6r0YbBAjTqo6T8i9dYKidcOAa0rNS5I0yain0E0wJwhDoQw6mZZotzYy306E09SWDjSAr5IV4ujq3Pqpre1s06hRI8fA5B4rMU/g08UEwv3XNfr7TeTelN5W9Cl1bpGseRZtfcbXETzEIBhzO4/9LEBaNZLr9dxvMlYNrIB0RE6khlFyNs+zlhq/NzkzjN5RMjfca/XNUwEWZu+l2Vw3Cip+5IyrVg8U3i1IXWpc47CE0KfaC3AoK+Mwb6T5U5ou3X7RoffDrRLNm7SXkBueS/rHC/Z5YvGnnF+lNeA== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation Thread-Topic: [PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation Thread-Index: AQHdO5mTAmdSCFyTpUW6NFs3gqbHSrbLKaWAgAKDb4CAIdShgA== Date: Mon, 5 Oct 2026 19:05:16 +0000 Message-ID: <338151bb-4c3f-48c9-bf98-8acd9ea1bbbd@epam.com> References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> <4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com> <3d473b8a85331856ea2b95f9448f2d6c@bugseng.com> In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|GV2PR03MB11718:EE_ x-ms-office365-filtering-correlation-id: 186d064f-e8f9-4ca8-6925-08df231397af x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|42112799006|1800799024|10067099003|56012099006|260925021911599003|260925021311599003|260925022911599003|4143699003|11063799006|18002099003|22082099003|38070700021; x-microsoft-antispam-message-info: wnYlfECts27Bq6DNckHn5WF3XeEVYtBS4Kl2P2rNgeNSZMXidytirAmxlfmCm3WzoIH+XNohFMhSTpwUVGPwsJBWImxQqX9eL1mmpRtOIp5Yn1XLoAFJ9bUZ1T/9av4yAsH9744Aum8PrwLOMQkj0iEGCrgnLzbAljQ2doPsQubhB9rpTgOE2ETfH8W5JIdM2Q9NF1aD+uTO+6u+fMO8zfMcj8fmMST4YgB7bvt+iKz1pI4RT6cR6Kd7Oukiy/uh1l76nz96hn93IvNeSyv4ECUd3Khiqa+gvhvrJ0MFmqmO5VTeaPnT3HIkcMTzoyJiJ4tlAzzUiD+d2x87eVU/sQXv5RhRR2fyCt3i3aPfw+BhRmtdftCBm/E8my0wQctV7i2HljfxY9B9yO2W945WSleUCCgT+98dh1u4GyzzpZEopIYMKAj2+uWKuvSC1WeqMwezOJnNBTXCs7+G1ixFZhRCCNE8kOaNB0q35iIywfBGxLRJHCaGeucnyJxmrxbePKeHYjrI5lw2/+9fDstEnOKz7CnRunseFekgjFe5UPWvIEjSUzw3IHKg2ke4i1vMJyMs8gZaG3CF7bvKei2WAUcSnxpD5949tSBZnA/M6qKha/yZliBpT5a6Y+YsaplG6lL2SHZPfrbvF3u0YW0PEz35p6tNITPco0H4zeGq8eE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(42112799006)(1800799024)(10067099003)(56012099006)(260925021911599003)(260925021311599003)(260925022911599003)(4143699003)(11063799006)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?M3RZbndPVmhXdmNoTGs1TmlNUXJtK1pWY3cvTWJGeGZSZDY5Skw0VDM0RzhL?= =?utf-8?B?SWN5WmRiNEJKcXdKMmJ4dXNUQW1DYmtSQ2d6bzFtR20zOGoyakFJakJVbUhq?= =?utf-8?B?b2JKSWpUSEtGb1IxVUZQZU5vbkJ0ejVpK29NcTROd2ZqZHFOdU1qMERNaTlE?= =?utf-8?B?amlWTTVvY2x3eFpEb1dKQWo4ekNJYUJXZ1oyeXNKOUZ5SVR5dkxUME5KOGpr?= =?utf-8?B?K0dHRXBjY0J4QzczSWdwM1F1d2FjWUpRVkd3K25FZWhBVCtxZHJqNnBNWVZh?= =?utf-8?B?dHVjVlZrYlVZTmcwb3BObVlBbmx5NjV0dFpzTWF5SG4yQm5TUCttdU8xeHNj?= =?utf-8?B?TTQ0cTJQN0J2RzlZZkh0STV2VWE4bmlNNWp1T0FwbDNVMkxiaFBNaTNYTmk4?= =?utf-8?B?aHJDMmppdEJzSFZTUVd3Y3hqTnRXUkhrMVhCNWFvMEZaL3pkQmxGK3BoTFhN?= =?utf-8?B?dDUweU5ORUVrOGtrMXRmNnlQd0FkM2kwb1hIQm1yNnlNOTdDZThuS01TNElT?= =?utf-8?B?d0hjdFpZUDRrdnRQQTY4Ym56bGxMRW0yYUJFbVVxZUhudTRIZENEUDF6Z3Q0?= =?utf-8?B?bTVQc0FTek8vVHZ5L2RzSXZZK2R2V0c0dUtPZ0pmTWMvLzIxckZZeGRENGJP?= =?utf-8?B?MTVYcEtyODBtRFRMWXFORWRBajZsNWVlVEovTVoybHcyeGV1QUVIMCsyT3RR?= =?utf-8?B?dnFwc1JjYzY4UWdwTnIzaVlabGVqd2FlemsvcTloWDBjQzFmZVZDQ05RbEJG?= =?utf-8?B?UVhib0lCL1pDSXBHV25ZVUZkbXZmYmZnRk55dE04QVAwVnUrVXEzZTdaSTFV?= =?utf-8?B?cVhVVDBQbUJIbEl1RTZsQzFiNUFMOGpYUFhpbG14MzZwVms1ZHk2UGI5SmlW?= =?utf-8?B?UHFleEhpZElmZUJDL2NINWRPaEQ0TEEvcEJSYysvL0kyRitxUVVSdEFlWXMw?= =?utf-8?B?cXNMZmlldEVqTi9RQjFRZTU2dHBoYXhZbW9PRWhwV0J6RnluNWpsZ2tIb3VH?= =?utf-8?B?aFBzUTZSMkhHUnY0TWJmNGlEWnF2WHRzQlVuM3BabmpuV3FLRXZyQjRsdlFm?= =?utf-8?B?dzRhSEx0ekk1UmRrWkJBVnhMTG5XSWR3c2c5ZERZOGpWOXpDckMwUVdlazND?= =?utf-8?B?YjBVNmdDR21LRmZvWGkrVWlJWXA5T2pGT3IvS3FlN0NzckYrNG1kTnpMeWor?= =?utf-8?B?eXAvcEsvWkJ6VVlxSWlYaXlvZS92TmU3aHpOYkIrd054QmR5bWYzaXdReml3?= =?utf-8?B?QzhtS2hQYUNoT0REaUI0TndSUXlsUGh1WFZmQ3RwY1JTQi80a1ZJcmdDVEov?= =?utf-8?B?YWRDK1ovc3ZCWU1oTHNpcjNyNUlYR21BZFlGTTI0bkZHTTN1ZmRJNnBQdHJx?= =?utf-8?B?YTYvQm1TVGpsbUxnTDNrRVRZMmh4bDEySCtRZVYrbW9WaUozUHF2L29jc2o4?= =?utf-8?B?L3lTcVFPMnZKd2c3ZFN4TGJNZGs3QWw1clJ6YU5CeDhtSG1BOC9IMHF0SWVS?= =?utf-8?B?U1ZPRkJMSklDRGVrOUlPMlQwR3hZNUprNUJZb0ZndFpGb3Zqc29DYkV3OHlk?= =?utf-8?B?VllsV3dVY2dUWEc0M1JUT0pmUFBIVGhNeGplcXdKM205bk41VGV1a1VnY1Jo?= =?utf-8?B?THY3TTByTHJsYmY4UzlERTl1OW1xenloQmlERVFQdjRSYTBua2dkV3UwNG4x?= =?utf-8?B?MU1uTzNZUG1hNi96YkFkQXNWbmVEaGRqZnFrOWxTK2t4cVl2UWlWZldJalNh?= =?utf-8?B?K3RsU2Z4MmJLSmQ4bVlrVkJtcHE3N203bTN6V21UMno0U0hTUWwyYVhybHph?= =?utf-8?B?N1VkRHpWdmd5RVNVMVNFMmRjU1RkbWc1U1V2WDZidW9PSkM4UG54c1QwSXN2?= =?utf-8?B?TWZLNCszK28weUxTMWRkNS9KdTJBeklxVDV3TmIzV2hhMU1kMmNjaWNUVHRP?= =?utf-8?B?TVdsNVpudTdlQkJjeUw0L04vSGhTQWJ6dTFXckNtVmNEcDNtNnIwdWZyeXZ5?= =?utf-8?B?aEpMa3Y5d2VDUmhvQnpLdUQ5ZncwZm05WGpuTDVoaWgvT2FHdUlzeU9LcEtM?= =?utf-8?B?NzB6YzNvZVk2aWVQNzd2OEMydDV6T0p5Rjg4WEUybVZkUjF0QlpaaElZQjVh?= =?utf-8?B?RWw3UzhqTmVXQVFQQm9LTXlYekJpei9tMW1hT0w3NlQ5SFRTZFk3WGVPM05l?= =?utf-8?B?TS9qaTF0OEtYWTRUN3ZTN3ZwcXVwMGEvSmVuT0NMaTFIc29BS2FnZUFTcVdV?= =?utf-8?B?TzAxZ2JUL25aSjZPWGlNMjBQM1lGQVI4d0htbmJySXg0MVhEczk2bk42Rjlq?= =?utf-8?B?S3FBZW1OVGlKbUlWVmVxU0NpcUM1MVl0RkQzSi92VDdnQWtRWFBRSVFxbVZm?= =?utf-8?Q?UkpVwYsoEOv4/35g=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <3B0D97B5D79DEC42803873BE4D69B0B0@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 186d064f-e8f9-4ca8-6925-08df231397af X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2026 19:05:16.5596 (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: 67y526BaTjU9UGUC1leKUjzBAoGoX91xBccbME/zdB8Xhy0tNtfhpRKKAl+XVRCS+ZCJXVZ2v6VUSqye0Sc66SvxBdajG0qzzWxzzjEBhs0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11718 X-purgate-ID: tlsNG-c1860d/1791227119-DF8D587B-262897D4/10/78276251493 X-purgate-type: spam X-purgate-size: 4780 DQoNCk9uIDkvMTQvMjYgMDk6MjcsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMi4wOS4yMDI2 IDE4OjA0LCBOaWNvbGEgVmV0cmluaSB3cm90ZToNCj4+IE9uIDIwMjYtMDktMDMgMTM6NDQsIEph biBCZXVsaWNoIHdyb3RlOg0KPj4+IExpa2UgbWlzcmEvcnVsZXMucnN0IHNheXMsIGZ1bmN0aW9u IGFyZ3VtZW50cyBvdGhlciB0aGFuICJ2b2lkICoiIGFyZSBva2F5DQo+Pj4gYXMgd2VsbC4NCj4+ Pg0KPj4+IFNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4+ PiAtLS0NCj4+PiBJIGNhbid0IGV4cGxhaW4gd2h5IHRoaXMgY292ZXJzIHRoZSB2aW9sYXRpb24g aW4gbWNlLmM6bWNlX2NhbGxiYWNrcydlcw0KPj4+IGluaXRpYWxpemVyLCBidXQgbm90IHRoZSBv bmUgaW4gbWNlLmM6ZGVmYXVsdF9oYW5kbGVyJ3MuDQo+Pg0KPj4gUG9zc2libHkgZGlmZmVyaW5n IGF0dHJpYnV0ZXMgKGUuZy4gY2ZfY2hlY2sgdnMgc2VjdGlvbiBhdHRyaWJ1dGVzKT8gSnVzdCBh IGd1ZXNzIHRoYXQgd291bGQgbmVlZCB0byBiZSB0ZXN0ZWQsIHRob3VnaC4NCj4gDQo+IEFzIGxv bmcgYXMgaXRzIGd1ZXNzd29yaywgaXQgY291bGQgZW5kIHVwIGJlaW5nIG1hbnkgKGV4cGVuc2l2 ZSkgdHJpZXMuDQo+IA0KPj4+IEFzIGEgcmVzdWx0IG9mIDY4NTIzMzRmODQxNiAoIkFybS9HSUM6 IGFkZCBub3JldHVybiBpbiBhIGZldyBtb3JlDQo+Pj4gcGxhY2VzIiksIHZnaWNfdjJfbHBpX3Rv X3BlbmRpbmcoKSBhbmQgdmdpY192Ml9scGlfZ2V0X3ByaW9yaXR5KCkgKGJvdGgNCj4+PiByZXR1 cm5pbmcgbm9uLXZvaWQpIHdvdWxkIGFsc28gbmVlZCBjb3ZlcmluZy4gKEFzIHNhaWQgaW4gYSBy ZW1hcmsgdGhlcmUsDQo+Pj4gbm9uLXZvaWQgdG9nZXRoZXIgd2l0aCBub3JldHVybiBpcyBzb21l d2hhdCBvZGQuKQ0KPj4NCj4+IEluZGVlZA0KPj4NCj4+PiBSZWFsbHkgYmVmb3JlIGFuZCBhZnRl ciB0aGlzIGNoYW5nZSB0aGVyZSdzIG5vIGNoZWNraW5nIHRoYXQgcGFyYW1ldGVyIGFuZA0KPj4+ IHJldHVybiB0eXBlcyBhY3R1YWxseSBtYXRjaC4gSSBoYXZlIG5vIGNsdWUgaG93IG9uZSB3b3Vs ZCBleHByZXNzIHN1Y2gNCj4+PiBjaGVja3MuDQo+IA0KPiBXaXRoIHRoaXMgbGFzdCBzZW50ZW5j ZSBpbiBtaW5kIC4uLg0KPiANCj4+IFRoZSBwcmVzZW5jZSBvZiBhIGJpdGNhc3QgaW5kaWNhdGVz IHRoYXQgdGhlIHR3byB0eXBlcyBkbyBub3QgbWF0Y2ggZXhhY3RseS4gVHlwaWNhbGx5IGZ1bmN0 aW9uIGF0dHJpYnV0ZXMgYXJlIG5vdCByZWxldmFudCB0b3dhcmRzIGRldGVybWluaW5nIGEgdHlw ZSBkaWZmZXJlbmNlLCBidXQgZGlmZmVyZW50IGNvbXBpbGVycyBtYXkgbW9kZWwgbm9uLXN0YW5k YXJkIGZlYXR1cmVzIGRpZmZlcmVudGx5IChyaWdodGx5IHNvKSwgaW4gc3VjaCBhIHdheSB0aGF0 IHNvbWUgbWFrZSBhIGRpZmZlcmVuY2UgaW4gdGhlIEFTVCwgYW5kIG90aGVycyBkbyBub3QuDQo+ Pg0KPj4gVG8gY2hlY2sgZm9yIGNvbXBhdGliaWxpdHkgb2YgZnVuY3Rpb24gcG9pbnRlcnMgSSB3 b3VsZCB0cnkgYWN0aXZhdGluZyBzZXJ2aWNlIFNURC5mdW5wdHJjdiwgd2hpY2ggZXNzZW50aWFs bHkgbWlycm9ycyAtV2luY29tcGF0aWJsZS1wb2ludGVyLXR5cGVzOg0KPj4NCj4+IGNhdXRpb24g Zm9yIHJ1bGUgU1RELmZ1bnB0cmN2OiAocnVsZSkgQSBwb2ludGVyIGlzIHVzZWQgdG8gY2FsbCBh IGZ1bmN0aW9uIHdob3NlIHR5cGUgaXMgbm90IGNvbXBhdGlibGUgd2l0aCB0aGUgcG9pbnRlZC10 byB0eXBlLiAodW50YWdnZWQpDQo+PiBwLmM6OC44LTguODogTG9jICMxIFtjdWxwcml0OiBpbXBs aWNpdCBjYXN0IGNvbnZlcnRzIGZyb20gYHZvaWQoKikoaW50KScgdG8gYF9fdHlwZW9mX18oQEVY UFJAKSonICh0aGF0IGlzIGB2b2lkKCopKHZvaWQpJyldDQo+PiAgwqAgcXEgPSBtOw0KPj4gIMKg wqDCoMKgwqDCoCBeDQo+PiBwLmM6IEluIGZ1bmN0aW9uIOKAmGjigJk6DQo+PiBwLmM6ODo2OiBl cnJvcjogYXNzaWdubWVudCB0byDigJh2b2lkICgqKSh2b2lkKeKAmSBmcm9tIGluY29tcGF0aWJs ZSBwb2ludGVyIHR5cGUg4oCYdm9pZCAoKikoaW50KeKAmSBbLVdpbmNvbXBhdGlibGUtcG9pbnRl ci10eXBlc10NCj4+ICDCoMKgwqAgOCB8wqDCoCBxcSA9IG07DQo+PiAgwqDCoMKgwqDCoCB8wqDC oMKgwqDCoCBeDQo+PiBwLmM6Mzo2OiBub3RlOiDigJht4oCZIGRlY2xhcmVkIGhlcmUNCj4+ICDC oMKgwqAgMyB8IHZvaWQgbShpbnQgeCk7DQo+PiAgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoCBeDQo+ IA0KPiAuLi4gLSB3ZWxsLCBmaW5lLCBidXQgLi4uDQo+IA0KPj4+IC0tLSBhL2F1dG9tYXRpb24v ZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9kZXZpYXRpb25zLmVjbA0KPj4+ICsrKyBiL2F1dG9tYXRp b24vZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9kZXZpYXRpb25zLmVjbA0KPj4+IEBAIC0zOTEsMTEg KzM5MSwxMSBAQCBjb25zdGFudCBleHByZXNzaW9ucyBhcmUgcmVxdWlyZWQuXCIiDQo+Pj4gIMKg fQ0KPj4+ICDCoC1kb2NfZW5kDQo+Pj4NCj4+PiAtLWRvY19iZWdpbj0iVGhlIGNvbnZlcnNpb24g ZnJvbSAndm9pZCBub3JldHVybiAoKikodm9pZCAqKScgdG8gJ3ZvaWQgKCopKHZvaWQgKiknIGlz IHNhZmUNCj4+PiArLWRvY19iZWdpbj0iVGhlIGNvbnZlcnNpb24gZnJvbSAndm9pZCBub3JldHVy biAoKikoLi4uKScgdG8gJ3ZvaWQgKCopKC4uLiknIGlzIHNhZmUNCj4+PiAgwqBiZWNhdXNlIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlICdub3JldHVybicgYXR0cmlidXRlIGRvIG5vdCBhbHRlciB0aGUg Y2FsbGluZyBjb252ZW50aW9uIG9yIGJlaGF2aW9yIG9mIHRoZSByZXN1bHRpbmcgY29kZS4iDQo+ Pj4gIMKgLWNvbmZpZz1NQzNBMi5SMTEuMSxjYXN0cys9e3NhZmUsDQo+Pj4gLcKgICJraW5kKGJp dGNhc3QpJiZ0byh0eXBlKHBvaW50ZXIoaW5uZXIocmV0dXJuKGJ1aWx0aW4odm9pZCkpJiZhbGxf cGFyYW0oMSwgcG9pbnRlcihidWlsdGluKHZvaWQpKSkpKSkpJiZmcm9tKGV4cHIoc2tpcCghc3lu dGFjdGljKCksDQo+Pj4gLcKgwqAgcmVmKHByb3BlcnR5KG5vcmV0dXJuKSkpKSkifQ0KPj4+ICvC oCAia2luZChiaXRjYXN0KSYmdG8odHlwZShwb2ludGVyKGlubmVyKHJldHVybihidWlsdGluKHZv aWQpKSkpKSkmJmZyb20oZXhwcihza2lwKCFzeW50YWN0aWMoKSxyZWYocHJvcGVydHkobm9yZXR1 cm4pKSkpKSINCj4+PiArfQ0KPj4+ICDCoC1kb2NfZW5kDQo+IA0KPiAuLi4gaG93IHdvdWxkIHRo aXMgYmUgZXhwcmVzc2VkIGhlcmU/IFBlcmhhcHMgYmVzdCBpZiB5b3Ugd291bGQgbWFrZSBhbg0K PiBhbHRlcm5hdGl2ZSBwYXRjaD8NCj4gDQo+IEphbg0KDQpQbGVhc2UsIHRha2UgYSBsb29rOg0K aHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vZDY4YzU2NjA3NzgxYmZhODI5NzY2YWVkMzZlZWIzMWYw NjA4MGZiYy4xNzkxMjI0NjM4LmdpdC5kbXl0cm8uXzVGcHJva29wY2h1azFAZXBhbS5jb20vDQoN CkJSLCBEbXl0cm8uDQo= From xen-devel-bounces@lists.xenproject.org Mon Oct 05 19:08:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 19:08:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441134.1658742 (Exim 4.92) (envelope-from ) id 1xDo2g-0002zv-Ng; Mon, 05 Oct 2026 19:08:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441134.1658742; Mon, 05 Oct 2026 19:08: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 1xDo2g-0002zo-K9; Mon, 05 Oct 2026 19:08:06 +0000 Received: by outflank-mailman (input) for mailman id 1441134; Mon, 05 Oct 2026 19:08:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDo2f-0002zi-Ej for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 19:08:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDo2d-00C0AE-GP for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 21:08:03 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac3f581-bab6-0a2a0a5309dd-0a2a4509bf56-24 for ; Mon, 05 Oct 2026 21:08:03 +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 6ac3f51a-be1a-0a2a45090019-ac6904feb3d8-3 for ; Mon, 05 Oct 2026 21:06:03 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 28D59601FB; Mon, 5 Oct 2026 19:06:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0F0E1F000FF; Mon, 5 Oct 2026 19:06: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:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791227160; bh=SNODs5FbLpBfmraE85X0V3Oi5UUM7z6D6PE8VhoZEoo=; h=Date:From:To:Cc:Subject:In-Reply-To; b=nHHkwOPuimd70cQZVRVzcCQ1MH+35tAUZ/tpFxE2p8QJbR9YZG5YKTOa5xAN5GzjV 4tW9WcKuG/a90atgTnVKXYmXqT6iZcc9gcEAUYBJHF4gsGCXqsqPvXsO9rLgIz7joC 8xVGt0EtEVvsk8p1zgFVzhPcUuDm8Zqg+v57EFVGzfmfosV6HXHBqa1qR1f5KoXU9Y QQbhJGBwEWa63xjLl8gUhPPU+KKT9yu6UambZmUAFCJ2wu+Nribtw4AQr5s2ljSy1P daMYHhqYhSFt1dQckdGBR1I6J2fTYEEA+brz22UvLqQyLW6qeiMjB3gLkd3kyxw8T9 xg77jhZ2FI9ZQ== Date: Mon, 5 Oct 2026 14:05:59 -0500 From: Bjorn Helgaas To: Yehyeong Lee Cc: jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, bhelgaas@google.com, jbeulich@suse.com, konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Jan Beulich Subject: Re: [PATCH] xen/pcifront: check that an AER callback exists before calling it Message-ID: <20261005190559.GA601702@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261005133019.284053-1-yhlee@isslab.korea.ac.kr> X-purgate-ID: tlsNG-bad1c0/1791227163-BE0C5034-9D4168EA/13/0 X-purgate-type: bulk X-purgate-size: 2709 On Mon, Oct 05, 2026 at 10:30:18PM +0900, Yehyeong Lee wrote: > pcifront_common_process() handles an AER request from the backend by > dispatching on aer_op.cmd to the bound driver's PCI error handler. It > only checks that err_handler and err_handler->error_detected are present, > then for the mmio_enabled, slot_reset and resume commands it calls the > corresponding callback unconditionally. Those three callbacks are > optional -- the PCI core NULL-checks each of them individually before > use -- and many drivers (for example igb, igc, ice and ixgbevf) install > error_detected without all of them. > > aer_op.cmd comes from the shared ring, so a malicious or buggy backend > can send XEN_PCI_OP_aer_mmio (or _slotreset/_resume) for a device whose > driver leaves that callback NULL and make the frontend call through a > NULL pointer, crashing the guest. > > Check each callback before calling it, as the PCI core already does, and > fall through to PCI_ERS_RESULT_NONE when it is absent. > > Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.") > Cc: stable@vger.kernel.org > Signed-off-by: Yehyeong Lee Seems right to me, but I assume the Xen folks will pick this up. Acked-by: Bjorn Helgaas > --- > There is an in-flight fix for a refcount leak in this same function > ("xen/pcifront: Fix PCI device reference leak in AER handling"); this > change is orthogonal and applies in either order. > > drivers/pci/xen-pcifront.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c > index cffc32d660327..490913676f244 100644 > --- a/drivers/pci/xen-pcifront.c > +++ b/drivers/pci/xen-pcifront.c > @@ -599,12 +599,17 @@ static pci_ers_result_t pcifront_common_process(int cmd, > case XEN_PCI_OP_aer_detected: > return pdrv->err_handler->error_detected(pcidev, state); > case XEN_PCI_OP_aer_mmio: > - return pdrv->err_handler->mmio_enabled(pcidev); > + if (pdrv->err_handler->mmio_enabled) > + return pdrv->err_handler->mmio_enabled(pcidev); > + break; > case XEN_PCI_OP_aer_slotreset: > - return pdrv->err_handler->slot_reset(pcidev); > + if (pdrv->err_handler->slot_reset) > + return pdrv->err_handler->slot_reset(pcidev); > + break; > case XEN_PCI_OP_aer_resume: > - pdrv->err_handler->resume(pcidev); > - return PCI_ERS_RESULT_NONE; > + if (pdrv->err_handler->resume) > + pdrv->err_handler->resume(pcidev); > + break; > default: > dev_err(&pdev->xdev->dev, > "bad request in aer recovery operation!\n"); > -- > 2.43.0 > From xen-devel-bounces@lists.xenproject.org Mon Oct 05 20:05:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 20:05:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441150.1658750 (Exim 4.92) (envelope-from ) id 1xDowJ-0003GK-N2; Mon, 05 Oct 2026 20:05:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441150.1658750; Mon, 05 Oct 2026 20: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 1xDowJ-0003GD-KQ; Mon, 05 Oct 2026 20:05:35 +0000 Received: by outflank-mailman (input) for mailman id 1441150; Mon, 05 Oct 2026 20:05:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDowI-0003G7-Ej for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 20:05:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDowH-009sB9-Nb for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 22:05:33 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac402f8-bab6-0a2a0a5309dd-0a2a4503d116-30 for ; Mon, 05 Oct 2026 22:05:33 +0200 Received: from [52.101.69.119] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4030d-fae8-0a2a45030019-34654577a9d9-3 for ; Mon, 05 Oct 2026 22:05:33 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by PAVPR03MB9140.eurprd03.prod.outlook.com (2603:10a6:102:32f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.19; Mon, 5 Oct 2026 20:05:31 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0472.016; Mon, 5 Oct 2026 20:05: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=sTC4PuHp7OjbWfSoigK/8YHbIwUQ6XULiGOiL0U9fAJRhhOSkAJ2UaNz/acajxIiLxRglzoRPwo3Wn/ZS3QjwPIGbR9M/1QoS07N5ePQK7ZgWteBoLtLoNyLXISt8t8neIuASRdWqC/CJnhpopZ801TPt9/Okibn1t3uJCtTgsi60hhpZ1EHbHXkufPeA5FW5siqiupl/7sKvjPzrLrdtbtaLH6UyqrWWMcJ0SLfrYTCW4hNs/9MDEB83iA0kvlP2Xct5XK/q15Hd4AXqf6KjWb/HzwEW8nMksSfo8FMhIxywsS4f5Lw88aoFNjDzn4sHTb7tSaJOG/0h/jE0tW0Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WNfr8oWxnmynHo8sSb62Z4SD4mE4QOwGJ0QSVd6ndr8=; b=gN0zceRL0brh0WmWIe2X0PSY4h2gZaO8kVHTYlM33g/z7Lpxqmd/p0hrtZo6rTKaQFimphcVIdutEsGTlCtmUL9cAAX+51n2EYG+vUMK0BTFfIbrv7Wpb3IxFE3Dhy7z0+uiGSnsLat4qH+OUxLl/XSqw+mBEFLA7UORNm1dSkhVzrql0rPjiNwJIWr2G3FQ17yFOtdxImIUdfHH2n6NgZrYZOc2MP+qtDPwTjFwTRpC1aEkOcHuSA78RtGkAMTXtGQl8Iwfbtp/4/LXkd+SEj77sbOBoCScHSbzl0/DnD7dvUyBoS7gI8MpaD+rhGXSohkYF3BKGhI1MB2bK4DWhA== 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=WNfr8oWxnmynHo8sSb62Z4SD4mE4QOwGJ0QSVd6ndr8=; b=J41ztSI45dtfvdscp4n4XkH1lfWwKjk8iFCodT56dEVXtYGH7wbIkPEQpEkgSXG08heeD/UBYI4ipnTeYesH+ZWKR9cEizDc2ygqliZFuIcWsHj1aelbSiJ4Nk0ZPPCosvSNLtSAlUiwVaiwwx2CHqmVljd4byCGj7+R9Tw/5cTnai0mVOp9ETtJQLtK65tevGcEWCj3r2S45O39/G0ZBsEx3FX/CIxMiWK5TkrTM1K65TloHNKzD1v6gya2pZhOF3XSmNmNle94phBHnSOJQxjONcx3LEQdDrib48hcClhy3Shgiz9M00v3uf965qD4JEUuVLJZodMoGOZl2C8vag== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() Thread-Topic: [PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() Thread-Index: AQHdO5mkZaB4SEWRjUSJMpU0C1g6K7bvkooA Date: Mon, 5 Oct 2026 20:05:31 +0000 Message-ID: <6e8c4670-b614-40d6-9948-75abbba621e8@epam.com> References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|PAVPR03MB9140:EE_ x-ms-office365-filtering-correlation-id: ee4c987f-8b8e-4a73-0648-08df231c023c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|42112799006|1800799024|10067099003|56012099006|4143699003|11063799006|18002099003|22082099003|38070700021; x-microsoft-antispam-message-info: UQ7MdWW/hmFxf1ZwBuwuVKp48idRV/EOe/lNLhtaG3l4bqLRYrR0t+kF7Tyc/jNr5GbR2cb1INlWh/Dr+sqmmsQdVrGuPFgnsUAPYV2FdIM116WElRUi+ahetRBK2Sjd0BdQsy0/gtbkr7KgCapiIuAek5vHCpHmmDKuA6Rp8jLHIJIGuNfz92faxQCJDG9B+j3ZKat3hUBGFbdhrTabGs9JcaRcwwekJ1VTN82suGCJxmks2w/uSKyXd72BocmEjvIy5e36unbNgZMZZdPKr6dD5UadFksdrbelkItNkcBwimnu1G9okK2n1IXHyDjAecnyyrON8ZnRbEeUiRVeJ9dy9iw6nlDWZjU75DCQi7uWMYR7YjmjNdeDj9cJu8w7TQqr7YqQHIe/g8K1RalcwtIoBIXtCOag4rIHraqkRu5odVc1CSN/V4pmhvjQV8pHMP3bW7fwtRFq9VKjUG8puSeVs2tsTVTxIfLWgW4D10x9EQvsNo4vZIfdSNwURtXKCmE9DSJ284H0bGIkZhz6+clq39tzv+vRsb7fuHBZl8nrCHV3wgOAyfEzS/MdxnO2NKSca0v44BkjjaZvZk5v1XssfOG0ecaEzMM8UyN2umx3V/aqjlbuVYv38FS7Y5Hco9GREjNScUMj6T4XtJSrqAlGwzhvU/ssBjqgAoyDNE5VPJp3JhZSHVLsv5KkeA2NNC0AFTzmA/dosP97Cznexw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(42112799006)(1800799024)(10067099003)(56012099006)(4143699003)(11063799006)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RHdGTDcwQzY1RkF4MDkweGVrVlRKQ3phWkl0UFh1WnJ3ZDVYZGJaVU5ranQ3?= =?utf-8?B?OTZtdW9xK0ZGMjhEdGxhSUI5YUk2Z3VNT0p5ekxNVWRQUEpDUUFxY1RhZUkx?= =?utf-8?B?eklqT09XMFEyY09teU5tSWFCTnpBWnFKelNGZDdNdUNKR2dCQmM3dSthZlhK?= =?utf-8?B?NWJ2bGE1SFlMNHM1VFdneWUrWHMvQjVseXpGRXNBNGVSWmxZZ3lxL0h4OEox?= =?utf-8?B?eWJxVXhTOU1RME1MMFBPNzlEejVKanJTYnQ3TkVHSDJsWGVUK1drbnNUTDNK?= =?utf-8?B?RjRYNDQ5OGpEWWdENHh0VEpwa3BmZ1VHNDRCeVc0bVN0S0Rvd1J3S0lkWkVI?= =?utf-8?B?dlljWFBPV0FKaU5wQ1lVU0ViTXNsZDBDTFlsa3ZUMnNEd1QxYkMrdi9nbmsy?= =?utf-8?B?NzM2VHFZdVhyUDBzeWFTK2JqS2dLRDFucHJGUmNTM2dhWUozb3RSWTdCUk9l?= =?utf-8?B?aUM0dW1BeVBoUzVyVzRRWkNBNThJL2t3dXorOHo2TU9QaDk3dHNqbEVEN00w?= =?utf-8?B?WlRJUnBtalR0dDlQL0lqQk9EUXVla1F5blBYZ3JMSmtwVm1KdEN6YXp0V2Nt?= =?utf-8?B?Tjdoa3BKZktuSW0zclBJZzZobElIMU1OODFsWExYM3BJNWNmVGw0dlVXK1pS?= =?utf-8?B?eGwyeFVRM2JyU0NHZmYzb1N1c211TzNCTGRNbG9Kei82RnRVVCt0VGtoOFp0?= =?utf-8?B?UVhGSHJiSzZWV3lXWXZQM1hVeFdSMDNwSm4zY3R5Q2szb1h3UTg4bWg1Zng0?= =?utf-8?B?OUF2MjFmKzh6RVRiNXpHQU9TdWNqS3RqMC9PdVpuRS81OEVwdHIybXdmR0FP?= =?utf-8?B?blRHZllhaGYvbVpYbnJJeThnSW1kREdhaVY4aEhiTzFqQzZYTTZ6bzJUZjJO?= =?utf-8?B?eUdvVStQeFY3UDFHMnlTNjVacGFKc1FsbTNOWC84VC9EUzU4L1RZSC91QUxn?= =?utf-8?B?dmZ1UllJamNSdVNOWTZkNkZnUzdTZTdFd3FHcGdCbWdIS3lmanErd2JQNWJG?= =?utf-8?B?clJjWEg2VzBXN24rbGxUKzNua0dnbC9aY3VobkdDSjFMY3JJeGN1c1RiZlpj?= =?utf-8?B?ZCtNUHZYcEdJSXBkY0F2ODAwdTNVQnl6a3R2c09jT1RZRHRHSlhZOXNMa0VQ?= =?utf-8?B?dUl0eW0zTTRBbXYyK1F6eVU4V1p0WS84VVVFWjN1OHpaL2ROR2t4M0xxaVlv?= =?utf-8?B?b1NJREFnTlUzc1h5VThSQi9oSk5XOTZQalFZNmE2dGI0b0VrVGNLbFFmRE0v?= =?utf-8?B?UVFabE93cXZOSlptVG9xNmpHSW1MMlZlaE1vU1k4SXBMb0N4dGZGN0FISXda?= =?utf-8?B?T3BGSGR5WHpEdk9YQkw0V3lSdU9DaVlGQnRXZTVIQmJOazVEaTZHS25oaEpr?= =?utf-8?B?OWlhM1J6bHY0a254V3FSSUMwMXY2Z2ZCNjZ3K2Fla0hNNzh5Vi9tSlFTdGZn?= =?utf-8?B?QlRYbGluRC92NXBtN1M5RDNjNHZPQ1BxdHcvcjR0VUw1Qy80Ykl3MjlpRVI5?= =?utf-8?B?OElqOTBPRStJemRRR1JaWThvZUdyUktia2FsWE9VS1orNzR6dHJHUlZXTVpT?= =?utf-8?B?UDJnR3kxYThvdExxWnNxN2NCVlpYUEZqajZqcFczclNHVEdBU1JZRHgxc2l5?= =?utf-8?B?NTIwVVJ3R0ZBdWtyWXc5aXZxTFhKYWNIQll5T1VnSTVleDR1Y0k1UUtFZ3RP?= =?utf-8?B?L3JSK1JnY1YvdXliTEluRTZnZHMvbzJQMlI1cllxOE8rOVl6MzJxZ2pDdnZI?= =?utf-8?B?NjZMZmtFVmlRRVpOSmpzb3Z0SW5VUk52MWdXQ3VPMWZ5STZRT001cVBjTGxB?= =?utf-8?B?VWNmcm1DK1pVWmRkSHJob0JiaGdzY2pKZTJGdnNzbjZHWmtkUTB5ZjAwV0Jj?= =?utf-8?B?SGlQUkxEMzZDOFlENFBtVWVIKy91M3k2cWczQngxenNlVWxkOGQrNmw3d0VD?= =?utf-8?B?c0pmcFJ5Z3pUcmZ4VGVENWJ1cG5aYkxCQi80WXJyb25LTkVKaUJZNVBsdGJp?= =?utf-8?B?NHlJa1FBajBSQ2M5NVVZd3MzN29RdnJHMTlJaTFRdXBra0JzeFpaZkN6UERR?= =?utf-8?B?UUhaV0ROMzZLQjBmb0VZNXQza05TQmthM0ozRERSV0pFT1k1YTJ0WXJPa3JG?= =?utf-8?B?YTJLV3VGKzUwQWk1S3JEQ1NkSEdYRFYxekRuQm1HL2h0TG9LL2NkV1BXZ0Rw?= =?utf-8?B?bzM5Y1BmMnc5NXJXRjVWeDBCWEw4V3R3MVUvN3JUZmdDR0ZYeTFMdWdpcjZK?= =?utf-8?B?cDlZRWgzdktQenJEdFZldktCb1h1dElWbjBEYWtrZEQxUFBNeDgrdU9TZm51?= =?utf-8?B?bEVJYjVhTUVkUFMvaDVuQUtIOTNtendrYk10bU1iWllDMDJDdnI1LzVhb3ZO?= =?utf-8?Q?gjZ1RhMdx9oUj55w=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <40C922CE53624B43B3611EF15ADBD237@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee4c987f-8b8e-4a73-0648-08df231c023c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2026 20:05:31.2827 (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: pOiq/pI3PSPFfnbRYAji3RXvEvqzIOHWeEKcebvA9n+hxPY6AvFGQIQspvCq3fwfRM7W57oQaRtWsyHUyu77bUyfqSl2tJnB8NjaaA6fDy4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9140 X-purgate-ID: tlsNG-33051d/1791230733-752854E9-3F0DA092/10/78276251493 X-purgate-type: spam X-purgate-size: 1180 DQoNCk9uIDkvMy8yNiAxNDo0NCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE1pc3JhIHJ1bGUgMTEu MSBkZW1hbmRzIG5vIGNvbnZlcnNpb24gdG8gZGlmZmVyZW50IHR5cGVzIGF0IGFsbC4gV2UNCj4g ZGV2aWF0ZSBjb252ZXJzaW9ucyB0byBsb25nLCB1bnNpZ25lZCBsb25nLCBhbmQgdm9pZCAqLCB0 aG91Z2ggLSBsZXZlcmFnZQ0KPiB0aGF0IGRldmlhdGlvbiBoZXJlLg0KPiANCj4gTm8gZnVuY3Rp b25hbCBjaGFuZ2UgaW50ZW5kZWQuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8 amJldWxpY2hAc3VzZS5jb20+DQo+IA0KPiAtLS0gYS94ZW4vYXJjaC94ODYvbWFjaGluZV9rZXhl Yy5jDQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9tYWNoaW5lX2tleGVjLmMNCj4gQEAgLTEyMSw3ICsx MjEsOCBAQCBpbnQgbWFjaGluZV9rZXhlY19sb2FkKHN0cnVjdCBrZXhlY19pbWFnDQo+ICAgICAg IH0NCj4gICANCj4gICAgICAgY29kZV9wYWdlID0gX19tYXBfZG9tYWluX3BhZ2UoaW1hZ2UtPmNv bnRyb2xfY29kZV9wYWdlKTsNCj4gLSAgICBtZW1jcHkoY29kZV9wYWdlLCBrZXhlY19yZWxvYywg a2V4ZWNfcmVsb2NfZW5kIC0gKGNoYXIgKilrZXhlY19yZWxvYyk7DQo+ICsgICAgbWVtY3B5KGNv ZGVfcGFnZSwga2V4ZWNfcmVsb2MsDQo+ICsgICAgICAgICAgIGtleGVjX3JlbG9jX2VuZCAtIChj b25zdCBjaGFyICopKHVuc2lnbmVkIGxvbmcpa2V4ZWNfcmVsb2MpOw0KPiAgICAgICB1bm1hcF9k b21haW5fcGFnZShjb2RlX3BhZ2UpOw0KPiAgIA0KPiAgICAgICAvKg0KDQpSZXZpZXdlZC1ieTog RG15dHJvIFByb2tvcGNodWsgPGRteXRyb19wcm9rb3BjaHVrMUBlcGFtLmNvbT4NCg0KQlIsIERt eXRyby4= From xen-devel-bounces@lists.xenproject.org Mon Oct 05 20:50:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Oct 2026 20:50:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441169.1658760 (Exim 4.92) (envelope-from ) id 1xDpdG-0000jH-UK; Mon, 05 Oct 2026 20:49:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441169.1658760; Mon, 05 Oct 2026 20:49: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 1xDpdG-0000jA-Qv; Mon, 05 Oct 2026 20:49:58 +0000 Received: by outflank-mailman (input) for mailman id 1441169; Mon, 05 Oct 2026 20:49:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDpdE-0000j4-PE for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 20:49:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDpdD-003q6h-Ui for xen-devel@lists.xenproject.org; Mon, 05 Oct 2026 22:49:55 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac40d60-e002-0a2a0a5209dd-0a2a450b89ec-16 for ; Mon, 05 Oct 2026 22:49:55 +0200 Received: from [52.101.85.53] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac40d71-b7e8-0a2a450b0019-34655535cd90-3 for ; Mon, 05 Oct 2026 22:49:55 +0200 Received: from DS7PR03CA0111.namprd03.prod.outlook.com (2603:10b6:5:3b7::26) by CH3PR12MB9098.namprd12.prod.outlook.com (2603:10b6:610:19e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Mon, 5 Oct 2026 20:49:48 +0000 Received: from CY5PEPF00000E78.namprd02.prod.outlook.com (2603:10b6:5:3b7:cafe::ac) by DS7PR03CA0111.outlook.office365.com (2603:10b6:5:3b7::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Mon, 5 Oct 2026 20:49:47 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY5PEPF00000E78.mail.protection.outlook.com (10.167.247.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Mon, 5 Oct 2026 20:49:46 +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, 5 Oct 2026 15:49:45 -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; Mon, 5 Oct 2026 15:49: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=lO4it2AeDYd395LjRRcoHqOhuC/iZzKEsQ8mrQWG2Bt3s+3LcBLuwWqLuVz9tMrTedHyRh0N2+pp37E/mF5wQDB5rHE4WdBSfhOGJb2PzNmu7ZZmM7xdHhyNiQo1xAPIkgoDYBreo2OPEt90tnO1zTBmzF4Qy8SMCcjF2LJThS1InlsKBi5ZhfHkaelOlFHqwod+6tBWYEuUdWpPlvdZOrjWj969yp3zyAo2jcgh+7XdQSab7WuTaridSJewMUFNvTrHhttJnzyCkfnwMbjjxXr1/AUs9RwPTEDQnWTPG2UNP0EpLiyon82SisuO9aefg6MYvu9pCgaWccxwCl4PkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0w6jWtdINVHVmzdvgqip4QyD9f4egVMf1ySpBZhIwew=; b=e8x20l53JG+82wcibhoaTZZVeNf/Pl71yuDNYIonHAAZcpBZtyx29C0pW4LsvTQ87BF0OSBO54OrD1vT6D1qb5aoknBAJiFeCssCdr9CfkBJX4Ot5mTJ2zv9F0MjuG/FiJiIk6RKewHEFnArnHP6HJEP5ICAMikyqdG5y6p4PBftW9/UOCVgOnX1gv6E8gyGa8mimPDrAH8zFAvxmnNpP07DAAHUEG5vEanS+ad3d3z8e06dIso86QjPksdyEOg8egplib9NRrnm7cSe6PfElo7lBEcbwddoWkiWsiGK8zJGjncieRfDRU3anOiJnoEohVuaH1YWbzbum/jlYoWLnA== 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=0w6jWtdINVHVmzdvgqip4QyD9f4egVMf1ySpBZhIwew=; b=FbPLkEheSWnoIO2xFk+TYYIEenLGw89RCkG4WapeCVcwQldraEY3Lf/aYnsWf7jNAfJfdXP7/xZYetN4UHUuVxqCsD6crZXvkTMvWgjy1lAmpKsYE4uZ11V4kd8PeOz7l92/k2Xp2yvLMvHeepa3n0rhk5jdAoNnzLWmIz4mo90= 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, 5 Oct 2026 16:49:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tools/libxenstat: don't lose all VIFs when dom0 has no Linux bridge To: Olivier Lambert , CC: Anthony PERARD , Juergen Gross References: <1791011886.8631fc262581453bbf619ec5b2062170.1a100a0936a0003f66@vates.tech> Content-Language: en-US From: Jason Andryuk In-Reply-To: <1791011886.8631fc262581453bbf619ec5b2062170.1a100a0936a0003f66@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: CY5PEPF00000E78:EE_|CH3PR12MB9098:EE_ X-MS-Office365-Filtering-Correlation-Id: 81595711-af40-4391-ac9c-08df23223114 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|376014|36860700016|1800799024|6133799003|18002099003|22082099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: UC0rchkfklUgGyLDx2Eh3z9KwwvyKU+Cmt9P+K6gKZ9loMnXmhs9/QO9v3H1yP2kL9KX/mawuw9/VWtdOFfbMBvDQ87QIUauiw6+44MrPKQ4h+h6Z9T+5AWkV9+ivY2Z+sw2+5519VhLHVtrEzWLT92YOsdc21Lb7UoVBin3XHv2zZsLKZE+m1z+WY3Z+zu/9aDPPtlLbEi2hSV/hlvkDDBM6TMQ+2RPR7rpdypWLZfo3XJo4HLVQAXIp/S+1C6VNdJlgeD/VzdtZIybiHRNBYNrcQu1NaIY6PJ6by2JPwsR5wdr1ayh3jkGUudda9FxWD6b9MVLvHmjbWLcBkjLb0/NqjqZSV6AqBk+LPfdj+B0WWKv8gWUdIwd6WsxzfNrqhuFJ9oUk1PoF43mBQp+5I9c4LghhChl2vBRQennRfMl9eoumQDRU0dGPB1su+YLhYANgTRqvkOHgDEFcXE2rWMdVTm+s+fU5+d+d63B77OktcM48lJr4XE/zSlCcv08RBNfzEz6uMJbhqV7J4ks+YALvAyv4n1kLq15XH/dWR4+VRWv66HWpI8Mm35FVpwQo/Ufr0Yo0VVr/jeCgCVnAy4zOSfIGS0gWRMJR9LvkNMHNWCxM175U5z1fCyiMW6BZhzQwMR/qwEzTdjBkXdBMbXaTCiDNR0Z2xhic9izGTtL4Ox3LsxkTGdkIXJf4/D9hh/4Ig5QYlfRkqL5QdOjfw== 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)(23010399003)(376014)(36860700016)(1800799024)(6133799003)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: BEQdeC3KJXDIW/JAy2ABu9AcH28QbJL+6rNFxa7i8OOhfYsTvSUNHbk4vL68UgX5jUQrYDc5z105HINUrE+ijjdaA0zv5qLgargwp+6LmaxwGcQPFgnFeAfutKDgo2zSNmhZt5zMRteUc7L3YR+MxT/dHvw+bUk664fqKuYHL8EYj43B67GVe2aDfNBe/XTyl+tvjTkX7PKkBmECemjlhX5/o4MoTRkNsW0FDp1qzeXql2J2Dz4QMCYdgqjhiGZBbjqfnn4LZAX1oKSTe87ZCRxHWwVGSxLcVuEudVqb10iWiYLcsO8askJgZhlGKmH2sUC3GIDrp0p5nN+4TJeE1Ts4mX03pxKf2vX1MYnAou2Kr1pKfI4qfwF0wMsOdmMe0HHGxZ9y78YSTh3B0PoooQi5bjoqGYQXirjLCRaw9urW3jegVhFDrN86Jb9flWJ0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2026 20:49:46.8307 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 81595711-af40-4391-ac9c-08df23223114 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: CY5PEPF00000E78.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9098 X-purgate-ID: tlsNG-42698a/1791233395-AAEDE9EA-02639D54/0/0 X-purgate-type: clean X-purgate-size: 1934 On 2026-10-03 03:17, Olivier Lambert wrote: > xenstat_collect_networks() looks for a Linux bridge (a > /sys/class/net/*/bridge directory) so that, with bonding, dom0 can be > given the bridge's counters. When there is none, as on hosts using Open > vSwitch (the XCP-ng default), routed networking or only libvirt's > virbr0 (which is excluded on purpose), getBridge() leaves devBridge > empty. strstr(iface, "") then matches every interface, and devNoBridge > is just "p", so every VIF with a standard name (vifN.M, vifN.M-emu) > takes the bridge branch instead of being attached to its domain. Every > domain ends up with zero networks, and xentop shows NETS 0. > > Only take the bridge branch when a bridge was actually found. > > Fixes: 1fd93d4f8cb8 ("xenstat: Linux dom0 statistics for case we use network bonding") > Assisted-by: Claude-Code:claude-opus-5-5 > Signed-off-by: Olivier Lambert Tested-by: Jason Andryuk Reviewed-by: Jason Andryuk > --- > tools/libs/stat/xenstat_linux.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tools/libs/stat/xenstat_linux.c b/tools/libs/stat/xenstat_linux.c > index b60e3fdcab..2a7d2f1a96 100644 > --- a/tools/libs/stat/xenstat_linux.c > +++ b/tools/libs/stat/xenstat_linux.c > @@ -322,7 +322,8 @@ int xenstat_collect_networks(xenstat_node * node) > > /* If the device parsed is network bridge and both tx & rx packets are zero, we are most */ > /* likely using bonding so we alter the configuration for dom0 to have bridge stats */ > - if ((strstr(iface, devBridge) != NULL) && > + if ((devBridge[0] != '\0') && > + (strstr(iface, devBridge) != NULL) && > (strstr(iface, devNoBridge) == NULL) && > ((domain = xenstat_node_domain(node, 0)) != NULL)) { > for (i = 0; i < domain->num_networks; i++) { From xen-devel-bounces@lists.xenproject.org Tue Oct 06 02:38:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 02:38:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441211.1658769 (Exim 4.92) (envelope-from ) id 1xDv3i-0005ls-1T; Tue, 06 Oct 2026 02:37:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441211.1658769; Tue, 06 Oct 2026 02: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 1xDv3h-0005lh-SO; Tue, 06 Oct 2026 02:37:37 +0000 Received: by outflank-mailman (input) for mailman id 1441211; Tue, 06 Oct 2026 02:37:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xDv3f-0005lY-Hg for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 02:37:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDv3d-00ATbR-Gq for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 04:37:33 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac45eec-2eae-0a2a0a5409dd-0a2a4502a4d8-0 for ; Tue, 06 Oct 2026 04:37:32 +0200 Received: from [74.125.227.171] (helo=mail-pj2-f43.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac45e72-6ca4-0a2a45020019-4a7de3ab8054-3 for ; Tue, 06 Oct 2026 04:35:32 +0200 Received: by mail-pj2-f43.google.com with SMTP id 98e67ed59e1d1-3a4c8262465so1896449a91.2 for ; Mon, 05 Oct 2026 19:35:31 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:5364:bba9:2adf:d611]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2e5a5ef5b60sm15092255ad.73.2026.10.05.19.35.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2026 19:35: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=isslab-korea-ac-kr.20251104.gappssmtp.com header.i="@isslab-korea-ac-kr.20251104.gappssmtp.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=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1791254130; x=1791858930; 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=FP6Cnv3Px2FrRBwEywG/gOFyPcxASJp/FvTXDyrwt5A=; b=w0kOzD0zHhfipQlw+VYUE310KQIVnZ9o90JvjMR1DNO19cclH0+Lj8S+4ETRYiHUqi r9l/rnjhrIwPfHBuJDfKqLyoYr0ugyKdYVXo3taKFPxkcrMk48dYXnqdgcTCeBhCBLDq kQdQMRGxi1/wtJahuRWRlkvV7uFwvJBNDyHPnyfIf/2SGBVvvNdR57AFur7VBeamvaUY BEHT6vYyvvIxp1eAQ8LSnrm7HBMO2vbT81Wi1gFHZ+satSJ41k8ehyinsbIiEuQJ+tfV dsvdrBcpk/PtNmQStMW5zbkHNjxfnMLiR487Q5byDOORa2iJFE6xNBbHcCOotDvW8fOR Jadw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791254130; x=1791858930; 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=FP6Cnv3Px2FrRBwEywG/gOFyPcxASJp/FvTXDyrwt5A=; b=Oi9D0KQ0RVTrWgSEo/ZKk4cFKBnmH215lT1GsrnT2wdzD2ID/5D1M///IsZzaUL3t7 cQCTPwYPzJDYQXmxawFDnU39oz1kWV/WekO+wGvDZj/vWZNhCRCwcofnQ9XWjmBVpj9U sRO7ESlWcDy0kxcr3hMUQx/Z6wDIgS4FkjMkFyG7Pyakm1qKQOp1+AkPfgrYYKjj9bTH dLJazNEc2FuUs3TKXyNQgl8T9jZA8I6cXR9J7ucx7HvhVAWy+uS0JybMPYwwH4qTY1Zd 1y5t+d+qK0LFo2cPtnVqNEKarsKsutLIrASg/mVquc2mtRzPf+93LX9/jVkEhkn2g4mF dhfg== X-Forwarded-Encrypted: i=1; AKwUvBykssyqkWWhd9BtghHek9BcoU9PgWfOu77tpxDxoFTa/XIlDUsKA3VbX5h2XmvjgofRAkWWmppZV2s=@lists.xenproject.org X-Gm-Message-State: AFq9FYLwahBnOR/W8hgQgTKoaxdwAvkXmfe3kH2EF84iSa5PKBotr5H2 6nh1G661ULDRlrpiurayXB+i3dSrg+i8uimCvNyLMfHdeBqyd8vfYViIRFGAPMyA0ic= X-Gm-Gg: AYBFou0JDrw0ET74Qo4O1Yd4Qr6qbaREaBZWZskx9jXb7JkX0vO8LRAwyjPlBt/mYGo ZDsBS1ixKavQhoQX6gxi4zNyucK79ZdFSO3S157I6mpX0k86kB1HoWNieptKQ48vsDNPIGcllhq Khiy3OlpwMnz7ihIvghttLDzbYXE7KSCt+4cvSLTzFoSclQTa0c9FZK5/WSGN5vgz3h+yfdJHZH ll7nt6kWiKU6b87r8lrAwycmkZ2kZktyjw/joMxph8CYrIbUhLpWVkpVopcrNJtYOoqwELioXwc AH8hS3BLBIAxKoVVml1WzHcvBqfsmw6rUKLF4CtM/mIjG3Ekf/uack5QcZq/J8yQbrKv98vPRtm mcuGTAuH/Gro37hTNmMILjB12WfaJULjlu+2QMqLz17d2XS74l/zYy1+F5ka/gqPo1arBQl9Eur lNhrEsrsxQmiZWBnTdo14oo5fnhEmGp1OY38RkLKNCfeqqPCJIKBOI+rs37UxO2kgw5/31azBAh uI/3z2ZS049lyyZoCvbYohxNz/1BPgh X-Received: by 2002:a17:90b:4fc8:b0:3a7:f7e7:df09 with SMTP id 98e67ed59e1d1-3a7f7e7e431mr4874845a91.55.1791254129975; Mon, 05 Oct 2026 19:35:29 -0700 (PDT) From: Yehyeong Lee To: jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, bhelgaas@google.com, jbeulich@suse.com, konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org, Yehyeong Lee Subject: [PATCH v2] xen/pcifront: check that an AER callback exists before calling it Date: Tue, 6 Oct 2026 11:34:43 +0900 Message-ID: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1791254132-67EBB2AC-16CEBD4E/13/0 X-purgate-type: clean X-purgate-size: 2925 pcifront_common_process() handles an AER request from the backend by dispatching on aer_op.cmd to the bound driver's PCI error handler. It only checks that err_handler and err_handler->error_detected are present, then for the mmio_enabled, slot_reset and resume commands it calls the corresponding callback unconditionally. Those three callbacks are optional -- the PCI core NULL-checks each of them individually before use -- and many drivers (for example igb, igc, ice and ixgbevf) install error_detected without all of them. aer_op.cmd comes from the shared ring, so a malicious or buggy backend can send XEN_PCI_OP_aer_mmio (or _slotreset/_resume) for a device whose driver leaves that callback NULL and make the frontend call through a NULL pointer, crashing the guest. Check each callback before calling it. When mmio_enabled or slot_reset is absent, return PCI_ERS_RESULT_RECOVERED so recovery proceeds, as the PCI core does for a missing callback; returning PCI_ERS_RESULT_NONE would instead make xen-pciback tear the guest domain down. Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- v2: return PCI_ERS_RESULT_RECOVERED for an absent mmio_enabled/slot_reset instead of PCI_ERS_RESULT_NONE, which xen-pciback treats as fatal and uses to tear the domain down. (Bjorn acked v1; the ack is dropped here because v2 changes the value returned for an absent callback.) v1: https://lore.kernel.org/all/20261005133019.284053-1-yhlee@isslab.korea.ac.kr/ There is an in-flight fix for a refcount leak in this same function ("xen/pcifront: Fix PCI device reference leak in AER handling"); this change is orthogonal and applies in either order. drivers/pci/xen-pcifront.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c index cffc32d660327..5c6f7796d204a 100644 --- a/drivers/pci/xen-pcifront.c +++ b/drivers/pci/xen-pcifront.c @@ -599,11 +599,16 @@ static pci_ers_result_t pcifront_common_process(int cmd, case XEN_PCI_OP_aer_detected: return pdrv->err_handler->error_detected(pcidev, state); case XEN_PCI_OP_aer_mmio: - return pdrv->err_handler->mmio_enabled(pcidev); + if (pdrv->err_handler->mmio_enabled) + return pdrv->err_handler->mmio_enabled(pcidev); + return PCI_ERS_RESULT_RECOVERED; case XEN_PCI_OP_aer_slotreset: - return pdrv->err_handler->slot_reset(pcidev); + if (pdrv->err_handler->slot_reset) + return pdrv->err_handler->slot_reset(pcidev); + return PCI_ERS_RESULT_RECOVERED; case XEN_PCI_OP_aer_resume: - pdrv->err_handler->resume(pcidev); + if (pdrv->err_handler->resume) + pdrv->err_handler->resume(pcidev); return PCI_ERS_RESULT_NONE; default: dev_err(&pdev->xdev->dev, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 05:56:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 05:56:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441224.1658779 (Exim 4.92) (envelope-from ) id 1xDy9n-0000ev-Cy; Tue, 06 Oct 2026 05:56:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441224.1658779; Tue, 06 Oct 2026 05:56: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 1xDy9n-0000en-7s; Tue, 06 Oct 2026 05:56:07 +0000 Received: by outflank-mailman (input) for mailman id 1441224; Tue, 06 Oct 2026 05:56:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDy9l-0000eh-Qp for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 05:56:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDy9k-00Ap3c-GP for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 07:56:04 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac48d72-2eae-0a2a0a5409dd-0a2a4509ebd4-4 for ; Tue, 06 Oct 2026 07:56:04 +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 6ac48d73-be1a-0a2a45090019-d1558029d1ad-3 for ; Tue, 06 Oct 2026 07:56:04 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4995b0343c1so7839075e9.3 for ; Mon, 05 Oct 2026 22:56: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-4a03fef5950sm257815415e9.2.2026.10.05.22.56.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 22:56: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=1791266163; x=1791870963; 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=GYWr8LUjX7sHqSBoQ3PHPB1NX62Vz51QOO188a9KB1U=; b=ZV3lacdDBkGHEy9PnQM4sVk6NdtxPoKsqzbPiscqVtkMnLO0r/9mMtPAJW8ZfQirpi UvikTl8TjU+CrgJFrmiGj7s9Hf92PACO7XiU/ihxDAEnMQcmfAh31wnYWh7l1GtXhf/v X+FIzV5yeOFiePG4ScHB3VdI+rz3zjT3Y5fbymEhBjKMjr0p+0LnaQ3+ecyH0gBQ+R1z EIXdHU0h9k3CJXx3ISjjkiYWXzqw5pToWEqboVUuP25ekRgr/YMSi9inWghp2UjjVYmx YlQXERGOLqnwLCsPXN0PCCjWHl45JbDgFesrHODoVkb+beb7yczB7YiQ/txh8QFG/UnN +N5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791266163; x=1791870963; 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=GYWr8LUjX7sHqSBoQ3PHPB1NX62Vz51QOO188a9KB1U=; b=HOV7h/DlYUmhtEn0rolYZc/5nh6Cn3/0CG/LGc1lp6Q2FmyH1mReMbKPykFYYD1MJR 1Q1hXknpwnIlq3lrXCRv2DS3e5Z6bPD4pqAT58bVdRIVNKTufB9lxT7LS9RIfxGUAaqF /jkHCx0shsxX8fA8iSUSCsXC7BKsFO9EJRCJVcZlab6xIvYNLmBktpranEW/VXj2k8u1 aIX3Qli1WUt7u8FNXKK8IiNkarKHfN8zAS3cBG8OttX67kBxOPQUkjbZC0ICD+fKtkTY XkUWXK0xBxdbsp0utfKU2CPraCY3AvbZgrd4hCjaCTk74ZngCXNHWC+feYTvMLns64GF M6Aw== X-Gm-Message-State: AFuF++mRxBHyww9WFz5IAjqzAmNGZ1iw0B2vi3nBNUz2Uz7i1gvOzDe6 lt9RRbzs7PEMH16fmj8YMmOnRmhxTBEL5kY2+LmDFdyjo/F9iUhiShaxAThPqBhbzw== X-Gm-Gg: AYBFou3LtgKh/Wh7p6lfUG5GkkrdODEmyxfaCMlpk/LF6mr1N+uGWWFKkZGozGmm6IS 8sRO4oYhF5txCjXnxxLn6QuxDAu+tTHFgSHghtztt7fbUDGqtkM61ndXPfJoiic2HQhGMN+zGX0 cDDZJphwLt86GIplYAmzHxHGO4V2WaljGpXBQ4apBGPo/nvrmI75RR1LuKZU9n9IBeoB7q+KXR5 IV8P5Xk6y52yBDaTKBmiR/xNSmMlbODDZRjjub2VLQMCInSL/TxATezyfTk9f0Oimb6KYOXSm0L Ky6/6Om+piTcgExoORDX+ls1pNxCk7+zIGlL0E3BWZqxDdkaLWB4iPM0qPLTHt7pNQlaYw1yTzY lQpkULwhAZ62XkJNcWT1LAzvTwzhxZN4kQhbm+vrqWS9TIToFZ40cvatFCA9agUNhs4tCcekUzV cPPj2yH/jzJzMOKLBWTNWLuZ9Tp6WO6x16dqHySGLDrEhRKRV5eFUj6q8ishhZs0qkpoVLAgh5r PIWpqveiUgK+IEKnE6rlXWGIUGCkSpLxnjyFMM2dJbhT1ejLJ84EsZrv3JPBjY= X-Received: by 2002:a05:600c:b8d:b0:49d:2562:d670 with SMTP id 5b1f17b1804b1-4a17b548f86mr4946235e9.14.1791266163542; Mon, 05 Oct 2026 22:56:03 -0700 (PDT) Message-ID: <8dcf88f1-a5c9-495d-9110-45a14dfd573e@suse.com> Date: Tue, 6 Oct 2026 07:56:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/PVH: correct PVH Dom0 E820 region merge To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <012de89f-000c-45b3-a600-544114346e5b@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/1791266164-BC6CA034-9ED3FD9C/10/78276251493 X-purgate-type: spam X-purgate-size: 1013 On 05.10.2026 18:19, Roger Pau Monné wrote: > On Mon, Oct 05, 2026 at 06:01:34PM +0200, Jan Beulich wrote: >> Folding with an immediately successive region can't be done by merely >> lowering the start of the region. The size of the region needs increasing >> as well. >> >> Fixes: 5427134eae81 ("x86: populate PVHv2 Dom0 physical memory map") >> Signed-off-by: Jan Beulich > > My bad... > > Reviewed-by: Roger Pau Monné Thanks. >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -229,6 +229,7 @@ static int __init pvh_add_mem_range(stru >> if ( rs == e && d->arch.e820[i].type == type ) >> { >> d->arch.e820[i].addr = s; >> + d->arch.e820[i].size += e - s; > > I think it would be simpler as: > > d->arch.e820[i].size = re - s; Perhaps, but the way I have it the compiler may figure that it can fold the tail of this path with the next if()'s body. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 06:00:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 06:00:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441229.1658787 (Exim 4.92) (envelope-from ) id 1xDyDX-0001Jr-Pg; Tue, 06 Oct 2026 05:59:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441229.1658787; Tue, 06 Oct 2026 05:59: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 1xDyDX-0001Jk-Mn; Tue, 06 Oct 2026 05:59:59 +0000 Received: by outflank-mailman (input) for mailman id 1441229; Tue, 06 Oct 2026 05:59:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDyDW-0001Je-IF for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 05:59:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDyDV-00Aq1q-VB for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 07:59:57 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac48e50-bab6-0a2a0a5309dd-0a2a4509d8b8-18 for ; Tue, 06 Oct 2026 07:59:57 +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 6ac48e5d-be1a-0a2a45090019-d1558033d839-3 for ; Tue, 06 Oct 2026 07:59:57 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a020e65269so2530025e9.2 for ; Mon, 05 Oct 2026 22:59: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-4a178db04edsm50214495e9.11.2026.10.05.22.59.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 22:59: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=1791266397; x=1791871197; 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=+CCHim4EnGv5ISJNtzeANfBYoH+J0BefRMjb9Cnm0c0=; b=GauytJkFBLIrcD9mNj8QW5bdfpYLEc+NtU7q5SvJlGttm3Uuy4SnugtzXSLnWnHS1P 7OURL1nalxvkBnoWaoWRKSNIcTl9btlOSqlivptewSMB6hHfN2TAsZbXfN1f5MXxCX4l ssPHhuPZpXE4ryBcPiPpa3ldEX2FD53VpD2Jp53TndGi1zrnLety4JkdIUxSKqcg3ob9 enWJzQ8dHyCsZBV+RA/tkxc9/NDuInZbdhHAMleJ1d5dOc4B6NW2sIuWcoRNMFbivqdN n464QGOUwPRfVF6rPpzziGeHwvJs8ij0hSYpE59k+qCXRBEXzvv3LpYWW3vWOpZKmsO7 sSLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791266397; x=1791871197; 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=+CCHim4EnGv5ISJNtzeANfBYoH+J0BefRMjb9Cnm0c0=; b=PN44XJ5qoXpLJR9Wp9MAlnyTniTza/4K5M8iHexdi4EHzlHAtRS/UlEhRzUxFDGZ9Z h/L62xzQD3aqWayVTIrg6wTX2ohykWiTH50d2JuyIPtjacDWV7muDDujeYuo+pYx3k4w XW3j9wD/cf473ZqlRLUiuj9GcV6kp0QRLRMsg2N2ZXw+yxZiLwtjRn1BU3nNCI5TIDKs VBLO2NoDnANBHOFeFYMNuN0aNvTZeEgMERFiRuHCdZ8Xz09f6RWXH2WD3vEPxZYTK3qC yupsLcNTwRfLtdRMv96RkBMXPWHA4c+oiT0UT/LDvy4mXHXsCnLB7yKnvMK/XqQF4fpv 0JqA== X-Gm-Message-State: AFuF++kF636czieM6pSZMecI/l0aGVNXGWU2GnqIdEpWmwnxA7B4XtBV EQXpdDA3uo4KyDlEUP1yjlzas7LtyielOXiyMQ9KCsOYlzeaifdiTsBMqaEE8SN4fQ== X-Gm-Gg: AYBFou33+kpQR52MvM8+drR4yNjMswkWuCMmtQh2XbNp5v6+KR6sgugjO3l8ofFh5nV yG0i5rE8xLsuUTeV6zj/oOV269lwb/yTiHHNVEgiQ/zIO5F9sMchJYJpAiW/PQzHkseJmcXef7r b2P/IJumPV6OF3Ag2C+/ho4xSrbhsRg397u/gazpmrdvlw4D5A1pTi5PzWhUDBiaO2/fkZdEYpV 9Vfua4P4MfscvUYh+2klSp3DBuoY45FgAO6TKm70eNH/yeUmLYR1F4mlC04QwEE1IVW9bFHbxGI PDgFUGk3Znh5PwmUu51+phxeheKO2wpOyyxhnmxxKhnkHgnuS+87lYaOsiVUPqHcI4/8MK6b727 HRnjozwuJhjRnCy9EVTT7wwSe7O9M4eInOoXAB68eWJAEvi+KqzxrsK+ToEBes5JKKLy01V0m07 AHdyZuQNiMGalwt9/cVDlt1y/A1nwwrlrcKMDoJyK7YPWgynAJ/KOlQiBofKUK3S/ky7ZtgHIHa ZBObqBxAQ835+c7I7gSFT/sWm2hoWzQ/Y2D6TH8t/GueT6ZUnsWgbIXH0QiLvhOTeIND7HD X-Received: by 2002:a05:600c:4ed0:b0:49f:bc43:9e96 with SMTP id 5b1f17b1804b1-4a17b526f07mr5669245e9.8.1791266397339; Mon, 05 Oct 2026 22:59:57 -0700 (PDT) Message-ID: <46943494-89be-4d72-943a-dfc28b96cbf9@suse.com> Date: Tue, 6 Oct 2026 07:59:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 12/14] gnttab: don't cast away constness 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> <1f55b457-c8cc-4ef9-ba5a-96e52b95fbbe@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/1791266397-3A4DB034-B2368457/10/78276251493 X-purgate-type: spam X-purgate-size: 1482 On 05.10.2026 18:59, Roger Pau Monné wrote: > On Wed, Sep 02, 2026 at 08:35:47AM +0200, Jan Beulich wrote: >> 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 > > Acked-by: Roger Pau Monné Thanks. > Could we also use a union in the functions themselves to avoid the cast? > > union { > const grant_entry_header_t *shah; > uint32_t *raw; > } grant = { .shah = shah }; Possibly. However, irrespective of us using such all over the place, it still is - strictly speaking - UB. >> --- >> 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. > > Possibly - I would be fine with that, which kinds of render my > previous suggestion to use a union not very useful, if we can get rid > of those variables in the first place. I'll add a todo item to my list to give this a try. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 06:09:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 06:09:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441240.1658797 (Exim 4.92) (envelope-from ) id 1xDyN1-0003Qm-Or; Tue, 06 Oct 2026 06:09:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441240.1658797; Tue, 06 Oct 2026 06: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 1xDyN1-0003Qf-LG; Tue, 06 Oct 2026 06:09:47 +0000 Received: by outflank-mailman (input) for mailman id 1441240; Tue, 06 Oct 2026 06:09:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDyN0-0003QZ-GW for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 06:09:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDyMz-00ETM8-TZ for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 08:09:45 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac490a7-2eae-0a2a0a5409dd-0a2a450c83fa-10 for ; Tue, 06 Oct 2026 08:09:45 +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 6ac490a9-f479-0a2a450c0019-d155dd36bd42-3 for ; Tue, 06 Oct 2026 08:09:45 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-486e8faff03so109086f8f.1 for ; Mon, 05 Oct 2026 23:09: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-48c62289e77sm8668228f8f.21.2026.10.05.23.09.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 23: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=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=1791266985; x=1791871785; 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=xDZ5krBY/B/gZUZ9vRTcjQsf5Svtc8MM0KNRqjFAAXE=; b=MviPh6WazkiBl2hcgZJeFVhqfOvgb46N53KriGAVH2SE9/giQ63pAA2hBL2AedzDt8 lyWRabj65FMPFIF1D22b9+piMvKgkIQUfhojBgTwGYV+c9IjFek2JZvoCpaJTCglyBBE 54O6/eN5hEU3TZy3VmOSdejlWr+rTZa/s+iRHuOtP7nPD/mmIpFZATUVGfDVWR1b40J+ idr1U4BmU/MaJjQn9KkarroRKA+zy4LY+m1x3SJqYW+5ms+u47oZSOdDuHKcZvRvuveY a7HM+X89/Z3NQqfRQscz93sk5XlazARLHlC9svd0DgMnUBITkCGrP6pG3DT1bMyJ2Uod IOxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791266985; x=1791871785; 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=xDZ5krBY/B/gZUZ9vRTcjQsf5Svtc8MM0KNRqjFAAXE=; b=qpwRdlfcNynaqE/RYHhfT6goXe5VO59/BniaqHbg9l7ySIBQgvlHH/bEKYl9U/botx QiqidC118M72e19H4/zaINuXqcs0Xh6PFeaIiIzCLk1Mnh4lzMz59A9XB4NFsFR257xg pVSIW6SqXvkLcXHZjrb2BAKgU27h3LhuYk/N0SVMsfXNAtPoLcREBR9JxABv1G0dItVi 2Y+lfqZDfeKgOS4cf3SyZkvbWvwHBi3ngGF3qcuWy60gJIXypvVwjmKZDsfkwDVJdeV0 KDprplezkY2BnmM00noIsOaj8tkxuRkunRSUaTQhEuMLV7TRI+gJSPjxaJDSWRrVPOeU dizA== X-Forwarded-Encrypted: i=1; AKwUvBzfrlyufbKp3kAsmW5fPss+1gMgV5Lo1XzzHLNSbI4KSxyNBYW5ARc9Vby2a4QgQxfsyhNtuYb790o=@lists.xenproject.org X-Gm-Message-State: AFq9FYLMAP8FakVpFp9eI/og/ZR58+jgc/unHuiSHvgDsBcGLKYZJOEw FSTkZROhFdhFBpXQMtZXBIDdetFERPzzlzWjiEsuy6ETAwg7haUPCm66RQhLI6W2wA== X-Gm-Gg: AYBFou2jLgRfrvqSS7PXcxIUXXIQ1xwmubZ1vfYIwv+YUubjnJr5FBFwdZMOgMkHRC8 K97H0yoKtdy8NmQoFnvbegzkOA/MtQF2i3B0AvuLRtVNgsmSbGgfGYRWL5Exvg5vlLf9TALo+pu cspBJwkPz+pGaQHczceius85MmDJ6JCDNOunS2uCQrfx9Yx/HV882OnQXOFwG/KHn1GZe6HY4pG PjxKqYB99vKNbJ+IuaUZtpt7wdZLe+FkDXP2F8A3Z1+j0SVlZLuh7apc9k3Jr65Fn8OUZRh64hi pD56rz0gkDdFO3QASUI/VLcrzML8stv8y4uyNon+cE4jtQIx/J+n7VfJRGVluccGKr1yx5BlaBL gouZntPJEclTEgv2ZLicqN+eMjPoXYxGxUkmuUMfumTFSB9OdjQ6ZQ4Q0tJRFeNRvJ0VihoqFXb 9sgr2CiODscf/JpKdzvzw9lgakwogoHiOAefpA0xrwyLi/noXa2s4SJG1lt5WWQUU8bgxmSVDFJ Td3t6cJvmaqJkl+oZxrV/rtTjFmPt1ufMEEwGZLQybPZ1NpAbvITQrnJLBZImw= X-Received: by 2002:a05:6000:2209:b0:48a:f929:e140 with SMTP id ffacd0b85a97d-48c6d1588c3mr691194f8f.10.1791266985318; Mon, 05 Oct 2026 23:09:45 -0700 (PDT) Message-ID: <12b19ff7-f471-4286-8d23-672426a39c53@suse.com> Date: Tue, 6 Oct 2026 08:09:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "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/1791266985-036D6A5B-C3E1AA4D/10/78276251493 X-purgate-type: spam X-purgate-size: 623 On 05.10.2026 20:56, Dmytro Prokopchuk1 wrote: > The R11.1 safe cast only matched void noreturn (*)(void *). Accept any > noreturn function pointer converted to a compatible function pointer. > canonical() covers typeof destinations, and compatible_deep_unqualified > keeps the parameter and return types aligned. > > Signed-off-by: Dmytro Prokopchuk Acked-by: Jan Beulich # docs (or perhaps rather Requested-by: or some such) Nevertheless, this definitely will want Nicola's feedback. It's only then that I would remove the constraint from the A-b. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 06:28:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 06:28:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441247.1658805 (Exim 4.92) (envelope-from ) id 1xDyfR-0006wg-53; Tue, 06 Oct 2026 06:28:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441247.1658805; Tue, 06 Oct 2026 06:28: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 1xDyfR-0006wZ-1g; Tue, 06 Oct 2026 06:28:49 +0000 Received: by outflank-mailman (input) for mailman id 1441247; Tue, 06 Oct 2026 06:28:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xDyfP-0006wT-NF for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 06:28:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xDyfN-00FSwg-1d for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 08:28:45 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac49513-bab6-0a2a0a5309dd-0a2a4503d59e-24 for ; Tue, 06 Oct 2026 08:28:44 +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 6ac4951c-fae8-0a2a45030019-d1558031e15b-3 for ; Tue, 06 Oct 2026 08:28:44 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49d0da752ffso21012375e9.3 for ; Mon, 05 Oct 2026 23:28: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-4a03ff3cab2sm155172255e9.2.2026.10.05.23.28.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2026 23:28: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=1791268124; x=1791872924; 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=F+iustYzRPuMgMSqd8JF+omEDt/F392IeN1bSYlGH+o=; b=apN48vuH4RhKWBVZ3hpiebjUoS1QqC7BXpYzyEM2Kfc/KRiPELrfKwTbjpbVTClHB4 mhjbB+/dYUzZ4U1WwzuUvPiTdPXto0cU16dgd3MqhjorEryCK/ZyDPrIIAHVzpZZnwbJ UMQThR+WxBhWLA4KMx9c61SVxabVLeoVfNJvAkSN3iyeejgh5/qwo5w8hLX5gpm3q61C HJsgXg+lV/ftHQzNT2u7KVpvo8ClntoI0q2mZxF5h1dfeNmEQxD5TEwAIizUgIRDLder arrGiuGBYqKU30LyKXelbvxSpNlNziGTpSYd0vRRYJ9gUMNTb1ngWTVY6ZoS9pscGE4h KBjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791268124; x=1791872924; 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=F+iustYzRPuMgMSqd8JF+omEDt/F392IeN1bSYlGH+o=; b=IAxSEgDGRl8dkruc7ydxf0PXbyRy94QeheMvdhHyoBCVCcQf0+O1UzwqIwLV6m7Bt9 FKSHb/cXDXCr6l9y+6ALGNoCoBFAm3otYJU5FRWvbD8ReFI4zopVezmiCyhwZW+nZRf0 8cpNZxARBd6XkZMKCgSZQ9cqOlfUNvQ/K+a+k2SZUenUckhdnouDo37IshfFSzZEVc8+ 5TeNswWzbUVWbUZOEkyr6iTHN1vX0RAm61RHqQycjho4/h8bR7+utjrNMi3tW77ZNUMU bFogLlPCgPE0c1H4/+r8Tm76c/1yVw/plfIbI72cZL3mc2ZuN18qxcK7s7BQOc+i1Sth cRCA== X-Gm-Message-State: AFuF++mgBNeTuequSyzxuNwtWXE3ZH+zpGEWIGOknz8dtzEt5VZ1rZ71 BP61moQaC6WkC5DXf9EOhJ/ZJe62P7CfiTBwbmbfk9yqbb10w+V5BcseMDRXDKXoJA== X-Gm-Gg: AYBFou3698bmakCKYBv/bSAapG5zkNk6Q/qY7izuLkrdRhWL6KG3lImML5u1ADTBpPx 905Iqfi0VqpbrWLRMn4yElvHKvv9bFZXRikYbs6ATDHtgrxHhGjbkB0w8YLry+/kn9VtmpvcT2Q 791MS2Z3mi31KAX1MD/hKHi6Zm7wC0iPwvKCOpx9JexTrri57K7tLw33LQo8zCipg2AR1I1wJV7 TaQPbaGOqB9RCXCKX970k47uKwSJ3UFTQNlNxjYJdUGFNzQuJebJni8TduRTdz7+U2A6t7SjvEh otA6L+YR5m0MNMeo6FJtPeTeTuYh0ShSgTIPgnKymQvpi50k3bePu+tB0gfNJrcp75F2+2J/v0K vixBoXrSRXHr957vInKb1JM6grua/YuGNnQ5Prsjm7+rLLPRnHFqm0IagQJkQyEIAGEqV9B4p6+ 0PGGUutzqmxj7dBEd8bT5m0FAA4QzXkkKgd7jbi3BP4VmYI5NRUd196WKtoUapx+QCPptZPmpMp 9aF6B0EKg5jE3zmfNOxFCN5/hrK91vfHTZbAuERscZjJ3wPiGxMmqE7SLi0AQ== X-Received: by 2002:a05:600c:b8a:b0:49f:fe90:de63 with SMTP id 5b1f17b1804b1-4a1680f4052mr147330935e9.28.1791268124150; Mon, 05 Oct 2026 23:28:44 -0700 (PDT) Message-ID: Date: Tue, 6 Oct 2026 08:28:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 12/14] gnttab: don't cast away constness From: Jan Beulich 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> <1f55b457-c8cc-4ef9-ba5a-96e52b95fbbe@suse.com> <46943494-89be-4d72-943a-dfc28b96cbf9@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: <46943494-89be-4d72-943a-dfc28b96cbf9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1791268124-6DED24E9-9068E2F8/10/78276251493 X-purgate-type: spam X-purgate-size: 1008 On 06.10.2026 07:59, Jan Beulich wrote: > On 05.10.2026 18:59, Roger Pau Monné wrote: >> On Wed, Sep 02, 2026 at 08:35:47AM +0200, Jan Beulich wrote: >>> 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 >> >> Acked-by: Roger Pau Monné > > Thanks. > >> Could we also use a union in the functions themselves to avoid the cast? >> >> union { >> const grant_entry_header_t *shah; >> uint32_t *raw; >> } grant = { .shah = shah }; > > Possibly. However, irrespective of us using such all over the place, it > still is - strictly speaking - UB. Then again we already have union grant_combo, which may want leveraging here. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 08:12:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 08:12:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441273.1658837 (Exim 4.92) (envelope-from ) id 1xE0Hl-0005JI-NK; Tue, 06 Oct 2026 08:12:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441273.1658837; Tue, 06 Oct 2026 08:12: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 1xE0Hl-0005JA-K4; Tue, 06 Oct 2026 08:12:29 +0000 Received: by outflank-mailman (input) for mailman id 1441273; Tue, 06 Oct 2026 08:12:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE0Hk-0005J4-LG for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 08:12:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE0Hj-00FmWW-E5 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:12:27 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4ad6a-bab6-0a2a0a5309dd-0a2a450bcbb8-2 for ; Tue, 06 Oct 2026 10:12:27 +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 6ac4ad6b-b7e8-0a2a450b0019-c387df82a55e-3 for ; Tue, 06 Oct 2026 10:12:27 +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 9DAED21D42; Tue, 6 Oct 2026 08:12:18 +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 4C977136F5; Tue, 6 Oct 2026 08:12:18 +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 dbvkCGKtxGoTBQAAD6G6ig (envelope-from ); Tue, 06 Oct 2026 08:12: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=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=1791274342; 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=1tgCwhLFPPglUXIkSM7MP92QdFqwJxiFVoFGuwCwMm8=; b=ZGGHGQKzaeKfsKxSWPYdaSM0HmnZQMS58Zh4e08o+HW2yCtElOtc4Yh/A9le5dYWSf246t zd3dY8jZwgvdZ7wPxqyu0Q4oUFffxSe0iWk3bKXvuRg3gYUFZQxFk7BYTSLKCSOeDK9Vak iydkYsQFJxPSxW+9JyaDLw84FdpiQn4= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1791274338; 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=1tgCwhLFPPglUXIkSM7MP92QdFqwJxiFVoFGuwCwMm8=; b=LbLnWkDp+RUiU7C0Zkl8z6aaHydpFHZafJvSZqdsUebunrv/XL+QoKFxDAAl+SEm7WjAvQ Vm2OOBmXmbQ+ttx1w67IpoZKkTX8zNjpWBk5Ss1kFwL1NfOMwcS1m2yyQ+Un0xDktKmVy1 ZW8WO4rI8e7Mz051ulcF+KHPvF6skbY= Message-ID: Date: Tue, 6 Oct 2026 10:12:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Xen/gnttab: improve error handling in gnttab_dma_{alloc,free}_pages() To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Oleksandr Tyshchenko , Oleksandr Andrushchenko References: <00493037-e77e-4631-8594-64ad4e46fa40@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: <00493037-e77e-4631-8594-64ad4e46fa40@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------SNDHwEID9JsPSbkN03ONjbIy" X-Spamd-Result: default: False [-3.64 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_SPAM_LONG(0.50)[0.143]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.14)[-0.707]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; 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)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; 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]; HAS_ATTACHMENT(0.00)[] X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Flag: NO X-purgate-ID: tlsNG-42698a/1791274347-182F49EA-AD413C76/35/110847 X-purgate-type: clean X-purgate-size: 11090 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------SNDHwEID9JsPSbkN03ONjbIy Content-Type: multipart/mixed; boundary="------------2iZBOgmCxDwcjC0ICN5BTKoV"; protected-headers="v1" From: Juergen Gross To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Oleksandr Tyshchenko , Oleksandr Andrushchenko Message-ID: Subject: Re: [PATCH] Xen/gnttab: improve error handling in gnttab_dma_{alloc,free}_pages() References: <00493037-e77e-4631-8594-64ad4e46fa40@suse.com> In-Reply-To: <00493037-e77e-4631-8594-64ad4e46fa40@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= --------------2iZBOgmCxDwcjC0ICN5BTKoV Content-Type: multipart/mixed; boundary="------------8wGmc1NztDxQwWIwKYK1bAZ6" --------------8wGmc1NztDxQwWIwKYK1bAZ6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTYuMDIuMjYgMDk6NTUsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBCb3RoIGRlY3JlYXNl LXJlc2VydmF0aW9uIGFuZCBwb3B1bGF0ZS1waHlzbWFwIGNhbiBzdWNjZWVkIHBhcnRpYWxs eS4gRm9yDQo+IHRoZSBmb3JtZXIgdGhpcyBtYXkgYmUgcHJldHR5IHVubGlrZWx5LCBidXQg Y2xlYXJseSB0aGUgbGF0dGVyIGNhbiBoaXQNCj4gYm90aCBvdXQtb2YtbWVtb3J5IGNvbmRp dGlvbnMgaW4gdGhlIGh5cGVydmlzb3Igb3IgZGVuaWFsIGJlY2F1c2Ugb2YgdGhlDQo+IGFs bG9jYXRpb24gZXhjZWVkaW5nIHRoZSBkb21haW4ncyBhbGxvd2FuY2UgKHRoZXJlJ3Mgbm8g aW50ZXJhY3Rpb24gd2l0aA0KPiB0aGUgYmFsbG9vbiBkcml2ZXIgaGVyZSBlaXRoZXIpLg0K PiANCj4gSW4gZ250dGFiX2RtYV9mcmVlX3BhZ2VzKCkgd2Ugc2ltcGx5IGNhbid0IGdpdmUg YmFjayB0byB0aGUgc3lzdGVtIHdoYXQNCj4gaGFzbid0IGJlZW4gcmUtZmlsbGVkIHdpdGgg YmFja2luZyBtZW1vcnkuIEZvciBnbnR0YWJfZG1hX2FsbG9jX3BhZ2VzKCkNCj4gYm90aCBw YXJ0cyBvZiB0aGUgb3ZlcmFsbCByZWdpb24gbmVlZCBkZWFsaW5nIHdpdGggZGlmZmVyZW50 bHkuDQo+IA0KPiBXaGlsZSBubyBwcmVzZW50IGNhbGxlciBvZiBnbnR0YWJfZG1hX2ZyZWVf cGFnZXMoKSBjaGVja3MgaXRzIHJldHVybg0KPiB2YWx1ZSwgYWxzbyBkb24ndCB1c2UgLUVG QVVMVCB0aGVyZTogSXQgcmVhbGx5IGlzIGFuIG91dC1vZi1tZW1vcnkNCj4gY29uZGl0aW9u LiAoSW4gZ250dGFiX2RtYV9hbGxvY19wYWdlcygpIC1FRkFVTFQgZG9lc24ndCBsb29rIHF1 aXRlIHJpZ2h0DQo+IGVpdGhlciwgYnV0IEkgY291bGRuJ3QgdGhpbmsgb2YgYSBjbGVhcmx5 IGJldHRlciBlcnJvciBjb2RlIHRoZXJlLikNCj4gDQo+IEZpeGVzOiA5YmRjNzMwNGY1MzYg KCJ4ZW4vZ3JhbnQtdGFibGU6IEFsbG93IGFsbG9jYXRpbmcgYnVmZmVycyBzdWl0YWJsZSBm b3IgRE1BIikNCj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2Uu Y29tPg0KPiAtLS0NCj4gSSdtIGxpa2VseSBzY3Jld2luZyB0aGluZ3MgdXAsIGFzIEkgY2Fu J3QgdW5kZXJzdGFuZCBob3cgdGhpcyBpcyBpbnRlbmRlZA0KPiB0byB3b3JrOiBhcmdzLT5k ZXZfYnVzX2FkZHIgc2hvdWxkbid0IHJlYWxseSBiZSBpbiBwc2V1ZG8tcGh5c2ljYWwgYWRk cmVzcw0KPiBzcGFjZSwgb3IgZWxzZSB0aGUgYWRkcmVzcyBpc24ndCBzdWl0YWJsZSBmb3Ig aGFuZGluZyB0byBhIGRldmljZSBpbiBvcmRlcg0KPiB0byBETUEgdG8vZnJvbSBpdC4gSGVu Y2UgdXNpbmcgX19waHlzX3RvX3BmbigpIG9uIGl0IHRvIHRoZW4gaGFuZCB0aGUNCj4gcmVz dWx0IHRvIHBmbl90b19wYWdlKCkgZmVlbHMgYm9ndXMuIFdhcyBhbGwgb2YgdGhpcyBwZXJo YXBzIG9ubHkgZXZlcg0KPiBpbnRlbmRlZCBmb3IgKHRlc3RlZCB3aXRoKSB0cmFuc2xhdGVk IGRvbWFpbnM/IFdpdGggdGhlIHVzZXMgb2YNCj4geGVubWVtX3Jlc2VydmF0aW9uX3ZhX21h cHBpbmdfKigpIG9ubHkgYmVpbmcgbWFzcXVlcmFkZT8NCg0KSSBmaW5hbGx5IGZvcmNlZCBt eXNlbGYgdG8gbG9vayBpbnRvIHRoaXMgbWF6ZS4NCg0KZ250dGFiX2RtYV9hbGxvY19wYWdl cygpIHdpbGwgb25seSBiZSBjYWxsZWQgdmlhDQpnbnRkZXZfaW9jdGxfZG1hYnVmX2V4cF9m cm9tX3JlZnMoKSwgd2hpY2ggaGFzOg0KDQoJaWYgKHhlbl9wdl9kb21haW4oKSkgew0KCQlw cl9kZWJ1ZygiQ2Fubm90IHByb3ZpZGUgZG1hLWJ1ZiBpbiBhIFBWIGRvbWFpblxuIik7DQoJ CXJldHVybiAtRUlOVkFMOw0KCX0NCg0KYXQgaXRzIHRvcC4NCg0KSSdsbCBzZXR1cCBhIHBh dGNoIG1ha2luZyB0aGlzIGNsZWFyLg0KDQpBcmUgeW91IGZpbmUgd2l0aCBtZSB0YWtpbmcg eW91ciBwYXRjaCBhbmQgY2xlYW5pbmcgaXQgdXAgcmVnYXJkaW5nIHRoZQ0KdXNlIG9mIHhl bm1lbV9yZXNlcnZhdGlvbl92YV9tYXBwaW5nX3VwZGF0ZSgpPw0KDQo+IEZ1cnRoZXJtb3Jl IHRoZSBhbGxvY2F0ZWQgYnVmZmVyIG91Z2h0IHRvIGhhdmUgYmVlbiBjb250aWd1b3VzIGlu DQo+IG1hY2hpbmUgLyBETUEgc3BhY2UuIFlldCB0aGUgd2F5IGl0J3MgcmUtcG9wdWxhdGVk IHVwb24gZnJlZWluZyBvZiB0aGUNCj4gYXJlYSBkb2Vzbid0IGd1YXJhbnRlZSB0aGF0IGF0 IGFsbC4NCj4gDQo+IEFsbCBvZiB3aGF0IGlzIGRvbmUgYXNzdW1lcyBkbWFfZnJlZV97Y29o ZXJlbnQsd2MsYXR0cn0oKSBpcyBjYXBhYmxlIG9mDQo+IGZyZWVpbmcgcGllY2VtZWFsLiBJ IG9ubHkgY2hlY2tlZCBkbWFfcmVsZWFzZV9mcm9tX2Rldl9jb2hlcmVudCgpIHRvDQo+IGZ1 bGZpbGwgdGhpcyByZXF1aXJlbWVudC4gSWYgdGhpcyBjYW4ndCBiZSByZWxpZWQgdXBvbiwg cGxlYXNlIGNvbnNpZGVyDQo+IHRoaXMgc3VibWlzc2lvbiBhcyBtZXJlbHkgYSBidWcgcmVw b3J0IChmb3Igc29tZW9uZSBlbHNlIHRvIGZpeCkuDQoNClNvbWV0aGluZyBJJ2xsIGxvb2sg aW50byBhdCBzb21lIHRpbWUuLi4NCg0KDQpKdWVyZ2VuDQo= --------------8wGmc1NztDxQwWIwKYK1bAZ6 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----- --------------8wGmc1NztDxQwWIwKYK1bAZ6-- --------------2iZBOgmCxDwcjC0ICN5BTKoV-- --------------SNDHwEID9JsPSbkN03ONjbIy 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/Ey8FAmrErWEFAwAAAAAACgkQsN6d1ii/Ey9u eggAhTzJk32FGHFlHLczBZFpoHodzt1p4e0BpvGmQbLpQWikFem0sRJvz3fcMjWfhzAdeSSqP5fG c2CX9toEXMx0rJ9w1Wq9L8fepiFpCpb0OO6CyFo9u1ldy5ZWOaff8pXEyQE2MIrqj0OdxPoiw4z1 wHbQm1IJ/OuSz2ovTgKvT50ewguH7VF65l2NiKQ2dIMEDkw/hhYLIX5cgT4OzXqKicglLdcz3Im1 njA1K7We5RZ8nD2k55j3TV73kzqsF1NB1C2lQH5qySme1ilXSf8f1a9Wz1iBMOfbDC1sDxIFg8Xs V9qGwVmbhdmdUFSJ8NEcDVYktnobSr0/MqqbCeX02w== =IaKV -----END PGP SIGNATURE----- --------------SNDHwEID9JsPSbkN03ONjbIy-- From xen-devel-bounces@lists.xenproject.org Tue Oct 06 08:28:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 08:28:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441281.1658847 (Exim 4.92) (envelope-from ) id 1xE0XO-0007G3-4F; Tue, 06 Oct 2026 08:28:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441281.1658847; Tue, 06 Oct 2026 08: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 1xE0XO-0007Fw-0x; Tue, 06 Oct 2026 08:28:38 +0000 Received: by outflank-mailman (input) for mailman id 1441281; Tue, 06 Oct 2026 08:28:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE0XL-0007Fp-Vw for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 08:28:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE0XK-00FqyS-Kr for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:28:34 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4b127-bab6-0a2a0a5309dd-0a2a4504c3ac-30 for ; Tue, 06 Oct 2026 10:28:34 +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 6ac4b132-b57f-0a2a45040019-d155dd30b48f-3 for ; Tue, 06 Oct 2026 10:28:34 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48af27fe287so249789f8f.0 for ; Tue, 06 Oct 2026 01:28: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-48c6cd7c278sm1834890f8f.51.2026.10.06.01.28.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 01:28: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=1791275314; x=1791880114; 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=NkYJhGZ5qN/ObooWiXFFFWdX+Ohl2lqI1lje36V1iJ4=; b=b9K6AoAM0XBcPLNnwTEYcobyBZ5efY74NxGZZndgJiQOJl8nyqx8avVklN+2IFOQs7 KWBmQgqdEhgwZODnrO4Vip6pZTeMR985vUHiEKa51cCS2LNluoLJMonCUAwHIqDN5Zsv FHHGWbaNS+Hf3no9JDM9FK+bKuE2pgXWkk7ABMQuLfVvOvP2h3KW2smrW73E+VbLHpN1 zwYlwwKNLxE0AGx48axugEnVVCOBPKhQfvnp4VBlSitd4OB/lSFQTIGKTbzq6U0kLTyv TatmgUJTkpoDy3dIQq/1eAXP26KtzNPr+aZ3FvquUKoIgknLRMoinioiajKvd5YzoAM6 B94g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791275314; x=1791880114; 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=NkYJhGZ5qN/ObooWiXFFFWdX+Ohl2lqI1lje36V1iJ4=; b=tbXnclndVTBChqTMY58txEcVnHdhX+BtZ4fWaq6owFzs1yP59ad9OcpYfhDBMAOi0s LscvngCkLtBBfKr3FhAqwfBmlygtKlZaEuU7BYWQotVxuKI4H329/cpAWRq17EPsY5In c8o8ULvN1AVcrkQV1lB/ph7fnIdqRk5J415xYtfS5XtwAC5ihzJwjYYnD7RS7O/OVmXy Ln4WBspjvM5n68DnmYhEyxxs5CMNLdQgeBFBRYHWQf+RX0zMSF0z8zP4m7lWZNEZeLZh ePxqGxIpx66vbApqlsRBjYHYNb2Qt6qQ/NX7a8Xqcwn0xhXxyUsgsxhK1ENUzy8BtOjC TunQ== X-Forwarded-Encrypted: i=1; AKwUvBw2jzW95JVhK5K7wltNGV9OrpjbXs2GnVJ9UuGmoJ0kUnLTgO+6U8oHyoLpkkDjh15mXj6w64W8VFs=@lists.xenproject.org X-Gm-Message-State: AFq9FYJNTOSIJc0g0FX5UGqzcwrDjFaXzFDEyAnILVx2ETH8iUPvZIb8 weXTUM1TZunQxYoarzElwFhngvYl/GMT66WjenLlI8UM1eRgpctIOS/hSoblFnIT7A== X-Gm-Gg: AYBFou3dBPSHXJp7sZqjY75wDs+ffvjw393dDGN7vPosz1PqA+hyTrtzbHOxCGhclk8 Yp1EKykuTtd66NPKd3+E+iNX0gTsFFMzT7J04svIkTyq3PLs6ROWLV0qViJbmZtZ3mokZ4W97Ul CSgBsHH3c67pBaQTwN/eQng3+FNBnz/4LOLAise1XrzUWPHwX9B6LAbYzl5JSKKgkItkrnvcQ/a f+1OjjnIqcdsHwvdGxM0sI8faQD3k/Jsw/2j84p4l3GW5l98nxJ+B23J/gmJ5QU+uv5lHrPnmQ7 ec2Sjx59QH4IdTKu49GfFnVfl2EsQxM9Ab2J3oSMyg+Y5UgCPIhWA//9wVjP3SCJd/Z0J5mqKWI ds5SHbiQn1dqe9ogHAV59TY0vIWDiu3M6Ow7Rq1A3AdTX6TKniPwlti04hPDEUv4ubdnl64YCgp YSnItzcrQTNQ70Fzj3YlrQLWyZbz0MQ8VQmFANrqwFtnYNXhKfOpoBhR3GVXXv4Wj/A05kzOy3h +608NDaZga1vNvt8KSnKK4CdtRvQn+eUjJXFTo9MhvQheH5+dYBl2nvh6voF6U= X-Received: by 2002:a05:6000:2912:b0:487:f31:8037 with SMTP id ffacd0b85a97d-48c6d16d27amr1072662f8f.14.1791275313685; Tue, 06 Oct 2026 01:28:33 -0700 (PDT) Message-ID: <4a0b9a82-c142-4c12-81df-4e0ab2191721@suse.com> Date: Tue, 6 Oct 2026 10:28:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Xen/gnttab: improve error handling in gnttab_dma_{alloc,free}_pages() To: Juergen Gross Cc: Stefano Stabellini , Oleksandr Tyshchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" References: <00493037-e77e-4631-8594-64ad4e46fa40@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/1791275314-50AD8B50-18138989/10/78276251493 X-purgate-type: spam X-purgate-size: 2256 On 06.10.2026 10:12, Juergen Gross wrote: > On 16.02.26 09:55, Jan Beulich wrote: >> Both decrease-reservation and populate-physmap can succeed partially. For >> the former this may be pretty unlikely, but clearly the latter can hit >> both out-of-memory conditions in the hypervisor or denial because of the >> allocation exceeding the domain's allowance (there's no interaction with >> the balloon driver here either). >> >> In gnttab_dma_free_pages() we simply can't give back to the system what >> hasn't been re-filled with backing memory. For gnttab_dma_alloc_pages() >> both parts of the overall region need dealing with differently. >> >> While no present caller of gnttab_dma_free_pages() checks its return >> value, also don't use -EFAULT there: It really is an out-of-memory >> condition. (In gnttab_dma_alloc_pages() -EFAULT doesn't look quite right >> either, but I couldn't think of a clearly better error code there.) >> >> Fixes: 9bdc7304f536 ("xen/grant-table: Allow allocating buffers suitable for DMA") >> Signed-off-by: Jan Beulich >> --- >> I'm likely screwing things up, as I can't understand how this is intended >> to work: args->dev_bus_addr shouldn't really be in pseudo-physical address >> space, or else the address isn't suitable for handing to a device in order >> to DMA to/from it. Hence using __phys_to_pfn() on it to then hand the >> result to pfn_to_page() feels bogus. Was all of this perhaps only ever >> intended for (tested with) translated domains? With the uses of >> xenmem_reservation_va_mapping_*() only being masquerade? > > I finally forced myself to look into this maze. Thanks much. > gnttab_dma_alloc_pages() will only be called via > gntdev_ioctl_dmabuf_exp_from_refs(), which has: > > if (xen_pv_domain()) { > pr_debug("Cannot provide dma-buf in a PV domain\n"); > return -EINVAL; > } > > at its top. Well, gnttab_dma_alloc_pages() is an exported function, so it can in principle be called from anywhere, including out-of-tree modules. > I'll setup a patch making this clear. > > Are you fine with me taking your patch and cleaning it up regarding the > use of xenmem_reservation_va_mapping_update()? Yes, sure. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 08:30:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 08:30:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441286.1658857 (Exim 4.92) (envelope-from ) id 1xE0Z2-0000G7-Fi; Tue, 06 Oct 2026 08:30:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441286.1658857; Tue, 06 Oct 2026 08:30: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 1xE0Z2-0000Fz-BZ; Tue, 06 Oct 2026 08:30:20 +0000 Received: by outflank-mailman (input) for mailman id 1441286; Tue, 06 Oct 2026 08:30:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE0Z0-0000Ft-LC for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 08:30:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE0Z0-0041Dy-20 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:30:18 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4b193-bab6-0a2a0a5309dd-0a2a450be962-34 for ; Tue, 06 Oct 2026 10:30:17 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4b199-b7e8-0a2a450b0019-d1558036a922-3 for ; Tue, 06 Oct 2026 10:30:17 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49e73611928so2597385e9.1 for ; Tue, 06 Oct 2026 01:30:17 -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-4a1787e7792sm53561025e9.0.2026.10.06.01.30.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 01:30: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=1791275417; x=1791880217; 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=Ng7gvqS9bLC1jpGuf8no+ogtM6aWKSMOCcwS42u/RdY=; b=NqfqVPfGkUzYp4xdJIOoiI1sTWv09JDSMCB3g3sQLzw1QZ8eaZGVz9epbFVmYfTU1M BvYKjyWLCy8IgkxDRLII5HJz4fpKjNZWFD3DwzH4xAlomgSDkUOqu5ux2BTyg/ji8UVr bEllYR2vUs6eROBpQEJDCHY6i2jxDTnS1fMElSKnIEr8+yBYfVDelbgTZeJMysXIXD/i mvdPk7wfcsJpubUGWsUKbv5xQlU8SFtU3cO1EQlJnwFoX6A9K5O0ehzYThXdvJTGXQW+ xjT+xdIzOq+Yz1/mxN/oGcXFO5sLbQf3sagb8Zgp5kcvXsEx3NU5ecNNfMUt9JMR4s/9 UEvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791275417; x=1791880217; 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=Ng7gvqS9bLC1jpGuf8no+ogtM6aWKSMOCcwS42u/RdY=; b=lBys98sLdha9kYCvZckn56MQlNs/suMfZWMzRXAiODOV37rkN+3V3AfiNqhnRj+s5I ueL2cp84xogbm7JmfZsYhyOMuKqV2fF3eIm30MMb6+p7S1tP2TAd1Hea+JEkF7ZG+AKl s1UM6khJFUBRjZ0SDtgDLcN4YGmp9NPn+BFvDBxRBppFIwuLV8BJQYZUqFhjLC1t4KkB Dilyl0/Dlvyb6TYUW3kxMuDs5WLUOmNOIGQ2hFE0gXJ4zvsCZwNCQxcxy6SOUj/7aB1V esEh/1e+8kolzW05bYuK3zqH3uVP2Ve7eknb+rMukYi9d5FePm3k2RxDzmXUpAECwIGQ 1ivQ== X-Forwarded-Encrypted: i=1; AKwUvBzQYy6RnviUb2913De3kME30smuA5E+rKa5KjqJchEC6swauA5XnLl8tIfgC117a5JMyhnr0u2dcrY=@lists.xenproject.org X-Gm-Message-State: AFuF++ncslKprFcml72WqesEdjwpKvzcgB9HPrGTFwUzJjKI66anf8zC m+9j57R9XakNAb/Nq/RdhdgntiNsqxn584wMIgtMZWLps9lx3/aNWweMXwzz2MfML54= X-Gm-Gg: AYBFou2d0Pp6a8lG21DLxRAt6z3/ywWAMPkQA9+gkc2UhimFXcwPof0t6bw4Z3nQxrE qH2LoonUeQLkd1kegdvSjpB6OG9NTb1B18hylz+7+ODkaEU9x93g4FpmI0Vnx9pjseHWyojwvRy egJWi1BDqmUThvDgr98BhiTOnVkhvhUOEhmvLHAaRKpzyhfT2G+/+sQysBZfHPWBAmt2BkkF6sL Nys6CqIdC3LTz7lPnQxIOJrEYaARWRns4vGOwoCh6d2yy/ajKriIUdV6NTI1tgYT9hbSRFJhzHu yEcT7G02pjXisR0ovUHoxHdJoBBqPK/KGQ38zxAWO40xK+pLbYiNU51V1xmlvi2WeVyG4klq2eP 0RW/bUBQSF1+exMBaDvaHiomeafz4v0onKwcV1vWuYTyLLXtwOsV63pkjInRq6Jw8yNhiQWCkKu oqvWPhxXOoMLkXTkc8FJMZKuZa2f4emrKY5ivJraxNsjqTgb/R4LC2tRzDMzATUivIa2w3+Vx64 tHxfIJb1XZoRgGTDPXXgkHxAIMzz1EJ4LyO/Dv7gk6duUBhufk91iL6onKWQrJgctfUOzRX3fm9 1Jb9MTCVfQ== X-Received: by 2002:a05:600c:a08:b0:4a1:6d2d:d8bb with SMTP id 5b1f17b1804b1-4a17b542787mr13743965e9.12.1791275414617; Tue, 06 Oct 2026 01:30:14 -0700 (PDT) Message-ID: Date: Tue, 6 Oct 2026 10:30:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Xen/gnttab: improve error handling in gnttab_dma_{alloc,free}_pages() To: Jan Beulich Cc: Stefano Stabellini , Oleksandr Tyshchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" References: <00493037-e77e-4631-8594-64ad4e46fa40@suse.com> <4a0b9a82-c142-4c12-81df-4e0ab2191721@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: <4a0b9a82-c142-4c12-81df-4e0ab2191721@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------M8ZlGvQc27y80QLSuze0cSGQ" X-purgate-ID: tlsNG-42698a/1791275417-A8ECE9EA-9C6D5308/35/110847 X-purgate-type: clean X-purgate-size: 11155 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------M8ZlGvQc27y80QLSuze0cSGQ Content-Type: multipart/mixed; boundary="------------LpALfOBwhbKEu9FfmtCKf6IO"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich Cc: Stefano Stabellini , Oleksandr Tyshchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" Message-ID: Subject: Re: [PATCH] Xen/gnttab: improve error handling in gnttab_dma_{alloc,free}_pages() References: <00493037-e77e-4631-8594-64ad4e46fa40@suse.com> <4a0b9a82-c142-4c12-81df-4e0ab2191721@suse.com> In-Reply-To: <4a0b9a82-c142-4c12-81df-4e0ab2191721@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= --------------LpALfOBwhbKEu9FfmtCKf6IO Content-Type: multipart/mixed; boundary="------------Q0jLntdxmoI5JFt6v4gIJZkX" --------------Q0jLntdxmoI5JFt6v4gIJZkX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYuMTAuMjYgMTA6MjgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNi4xMC4yMDI2 IDEwOjEyLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMTYuMDIuMjYgMDk6NTUsIEph biBCZXVsaWNoIHdyb3RlOg0KPj4+IEJvdGggZGVjcmVhc2UtcmVzZXJ2YXRpb24gYW5kIHBv cHVsYXRlLXBoeXNtYXAgY2FuIHN1Y2NlZWQgcGFydGlhbGx5LiBGb3INCj4+PiB0aGUgZm9y bWVyIHRoaXMgbWF5IGJlIHByZXR0eSB1bmxpa2VseSwgYnV0IGNsZWFybHkgdGhlIGxhdHRl ciBjYW4gaGl0DQo+Pj4gYm90aCBvdXQtb2YtbWVtb3J5IGNvbmRpdGlvbnMgaW4gdGhlIGh5 cGVydmlzb3Igb3IgZGVuaWFsIGJlY2F1c2Ugb2YgdGhlDQo+Pj4gYWxsb2NhdGlvbiBleGNl ZWRpbmcgdGhlIGRvbWFpbidzIGFsbG93YW5jZSAodGhlcmUncyBubyBpbnRlcmFjdGlvbiB3 aXRoDQo+Pj4gdGhlIGJhbGxvb24gZHJpdmVyIGhlcmUgZWl0aGVyKS4NCj4+Pg0KPj4+IElu IGdudHRhYl9kbWFfZnJlZV9wYWdlcygpIHdlIHNpbXBseSBjYW4ndCBnaXZlIGJhY2sgdG8g dGhlIHN5c3RlbSB3aGF0DQo+Pj4gaGFzbid0IGJlZW4gcmUtZmlsbGVkIHdpdGggYmFja2lu ZyBtZW1vcnkuIEZvciBnbnR0YWJfZG1hX2FsbG9jX3BhZ2VzKCkNCj4+PiBib3RoIHBhcnRz IG9mIHRoZSBvdmVyYWxsIHJlZ2lvbiBuZWVkIGRlYWxpbmcgd2l0aCBkaWZmZXJlbnRseS4N Cj4+Pg0KPj4+IFdoaWxlIG5vIHByZXNlbnQgY2FsbGVyIG9mIGdudHRhYl9kbWFfZnJlZV9w YWdlcygpIGNoZWNrcyBpdHMgcmV0dXJuDQo+Pj4gdmFsdWUsIGFsc28gZG9uJ3QgdXNlIC1F RkFVTFQgdGhlcmU6IEl0IHJlYWxseSBpcyBhbiBvdXQtb2YtbWVtb3J5DQo+Pj4gY29uZGl0 aW9uLiAoSW4gZ250dGFiX2RtYV9hbGxvY19wYWdlcygpIC1FRkFVTFQgZG9lc24ndCBsb29r IHF1aXRlIHJpZ2h0DQo+Pj4gZWl0aGVyLCBidXQgSSBjb3VsZG4ndCB0aGluayBvZiBhIGNs ZWFybHkgYmV0dGVyIGVycm9yIGNvZGUgdGhlcmUuKQ0KPj4+DQo+Pj4gRml4ZXM6IDliZGM3 MzA0ZjUzNiAoInhlbi9ncmFudC10YWJsZTogQWxsb3cgYWxsb2NhdGluZyBidWZmZXJzIHN1 aXRhYmxlIGZvciBETUEiKQ0KPj4+IFNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1 bGljaEBzdXNlLmNvbT4NCj4+PiAtLS0NCj4+PiBJJ20gbGlrZWx5IHNjcmV3aW5nIHRoaW5n cyB1cCwgYXMgSSBjYW4ndCB1bmRlcnN0YW5kIGhvdyB0aGlzIGlzIGludGVuZGVkDQo+Pj4g dG8gd29yazogYXJncy0+ZGV2X2J1c19hZGRyIHNob3VsZG4ndCByZWFsbHkgYmUgaW4gcHNl dWRvLXBoeXNpY2FsIGFkZHJlc3MNCj4+PiBzcGFjZSwgb3IgZWxzZSB0aGUgYWRkcmVzcyBp c24ndCBzdWl0YWJsZSBmb3IgaGFuZGluZyB0byBhIGRldmljZSBpbiBvcmRlcg0KPj4+IHRv IERNQSB0by9mcm9tIGl0LiBIZW5jZSB1c2luZyBfX3BoeXNfdG9fcGZuKCkgb24gaXQgdG8g dGhlbiBoYW5kIHRoZQ0KPj4+IHJlc3VsdCB0byBwZm5fdG9fcGFnZSgpIGZlZWxzIGJvZ3Vz LiBXYXMgYWxsIG9mIHRoaXMgcGVyaGFwcyBvbmx5IGV2ZXINCj4+PiBpbnRlbmRlZCBmb3Ig KHRlc3RlZCB3aXRoKSB0cmFuc2xhdGVkIGRvbWFpbnM/IFdpdGggdGhlIHVzZXMgb2YNCj4+ PiB4ZW5tZW1fcmVzZXJ2YXRpb25fdmFfbWFwcGluZ18qKCkgb25seSBiZWluZyBtYXNxdWVy YWRlPw0KPj4NCj4+IEkgZmluYWxseSBmb3JjZWQgbXlzZWxmIHRvIGxvb2sgaW50byB0aGlz IG1hemUuDQo+IA0KPiBUaGFua3MgbXVjaC4NCj4gDQo+PiBnbnR0YWJfZG1hX2FsbG9jX3Bh Z2VzKCkgd2lsbCBvbmx5IGJlIGNhbGxlZCB2aWENCj4+IGdudGRldl9pb2N0bF9kbWFidWZf ZXhwX2Zyb21fcmVmcygpLCB3aGljaCBoYXM6DQo+Pg0KPj4gCWlmICh4ZW5fcHZfZG9tYWlu KCkpIHsNCj4+IAkJcHJfZGVidWcoIkNhbm5vdCBwcm92aWRlIGRtYS1idWYgaW4gYSBQViBk b21haW5cbiIpOw0KPj4gCQlyZXR1cm4gLUVJTlZBTDsNCj4+IAl9DQo+Pg0KPj4gYXQgaXRz IHRvcC4NCj4gDQo+IFdlbGwsIGdudHRhYl9kbWFfYWxsb2NfcGFnZXMoKSBpcyBhbiBleHBv cnRlZCBmdW5jdGlvbiwgc28gaXQgY2FuIGluDQo+IHByaW5jaXBsZSBiZSBjYWxsZWQgZnJv bSBhbnl3aGVyZSwgaW5jbHVkaW5nIG91dC1vZi10cmVlIG1vZHVsZXMuDQoNClJpZ2h0LCB0 aGF0IGlzIHdoeSBJIHdhbnQgdG8gd3JpdGUgcGF0Y2ggcmVqZWN0aW5nIGFueSBjYWxscyBv Zg0KZ250dGFiX2RtYV9hbGxvY19wYWdlcygpIGluIFBWIGd1ZXN0cy4NCg0KPiANCj4+IEkn bGwgc2V0dXAgYSBwYXRjaCBtYWtpbmcgdGhpcyBjbGVhci4NCj4+DQo+PiBBcmUgeW91IGZp bmUgd2l0aCBtZSB0YWtpbmcgeW91ciBwYXRjaCBhbmQgY2xlYW5pbmcgaXQgdXAgcmVnYXJk aW5nIHRoZQ0KPj4gdXNlIG9mIHhlbm1lbV9yZXNlcnZhdGlvbl92YV9tYXBwaW5nX3VwZGF0 ZSgpPw0KPiANCj4gWWVzLCBzdXJlLg0KDQpUaGFua3MsDQoNCg0KSnVlcmdlbg0KDQo= --------------Q0jLntdxmoI5JFt6v4gIJZkX 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----- --------------Q0jLntdxmoI5JFt6v4gIJZkX-- --------------LpALfOBwhbKEu9FfmtCKf6IO-- --------------M8ZlGvQc27y80QLSuze0cSGQ 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/Ey8FAmrEsZUFAwAAAAAACgkQsN6d1ii/Ey+H BQf7BzUJizRfd+oYQLFYzyOF7evcy5IjSFciH7tRW77SFGRjMgeKwLGiH7RfD6iKAFamjB+sBLwo zjUp/l5A014g5qY+L/mfSWa2arzIUB/67D5xRWpTV8sba9SbcDGV53pEsk5pN0aSmAwLAojiZd6W m/01BNdIM/FN0p6+B8e1eiWUtgxBld4GDRWf6s9ijCFsI5ghTzr3PA1fXl6A3XDV9Yy2u1RTFCVZ 8WiSJUzPIGCRQROgqAPcreOZCWZo8bVeR9XrqdgaNffv+AQRbQPbODc5Y3KyVzCSU1s2Nbv409DN K+eU/RsmF+kttMUPI9QQeWtGSE9eSz6Z2qTu3z0Vjw== =+HqZ -----END PGP SIGNATURE----- --------------M8ZlGvQc27y80QLSuze0cSGQ-- From xen-devel-bounces@lists.xenproject.org Tue Oct 06 09:02:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 09:02:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441305.1658889 (Exim 4.92) (envelope-from ) id 1xE140-00059i-Uh; Tue, 06 Oct 2026 09:02:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441305.1658889; Tue, 06 Oct 2026 09: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 1xE140-00059b-Rs; Tue, 06 Oct 2026 09:02:20 +0000 Received: by outflank-mailman (input) for mailman id 1441305; Tue, 06 Oct 2026 09:02:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE13z-00059V-F6 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 09:02:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE13y-00F6ps-4m for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 11:02:18 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4b913-bab6-0a2a0a5309dd-0a2a4505b2a0-32 for ; Tue, 06 Oct 2026 11:02:17 +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 6ac4b918-4cb1-0a2a45050019-b9ff1c12ac2b-3 for ; Tue, 06 Oct 2026 11:02: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 1a11072f6480003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 06 Oct 2026 09:02: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 ED6BA8224B; Tue, 6 Oct 2026 11:02: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=ScTG0hoPu5b923bw3Z6Hfhc4fJ7rIEZ+GS5P0X03y1w=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=AeTv3n5bMEBjq5dlCnZs+wvQ10/WsiVYqhyQ8yr0n2H5o3CLKZitkx7IlYNWdMZQv8nxq0+FW u9gluygW7zcOygyoglV8JR4BBaoSCNwhKXOXQmrK6tOAs5qyogN+SIYnTFrvjmeBEFSAON04FvN 80WJ0wydsliwbECfa0UoNnGnk2JWDzkUAxyYC8zEeTaMXEJU2+3GNUof+afHt3d/wF97BFZTbsx htXUywT1wpc+TpxEXBlZfrh/c9n87xj61emp0eP7nTGZgRIV94aOh7PT+dvGI2XrT3yrXR7EW5i ooX4lXJc1WKaB9evTIIs/96HA1RpdTCTzPv5TVK8qBFA== X-Zone-Loop: 895ed95f7bd589920a1f2627f87d0489c82eababb627 x-campaign-type: default x-transaction-id: 23f87be5-0668-4473-bc5a-7a550e45a0e4 x-swg-uid: 01-80278138-664a-4fd2-a1e6-71692f0028b8 X-Mailer: Sweego Message-ID: <1791277332.8631fc262581453bbf619ec5b2062170.1a11072f6480003f66@vates.tech> x-swg-bid: 1791277332.8631fc262581453bbf619ec5b2062170.1a11072f6480003f66 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 v3 09/39] xen/riscv: build the target hart index via aplic_hart_index() 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, 06 Oct 2026 11:02:00 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791277322; l=6674; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=MzfEkg1wiZPKhC5DxX3t1NBoZMdFK9U99h6hc9urFes=; b=KS6dfqxQX3da1hQgFf6Q9MGsXtF2so417JmbchIMLGaNXjGTaj2OBPzIIimgTwiT8O4RauKOz OyB5FX7x4zZBRUkmT+PcIV5mxCMam4LUqrOVh3qcwRL+XBJYe5HgeAW 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: 1791277328184 X-purgate-ID: tlsNG-c201ff/1791277337-F76BD2A1-52C81980/10/73395122804 X-purgate-type: spam X-purgate-size: 6674 > 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; > > - the same hart id was then used verbatim as the low hart index, and > the group index was derived from msi[].base_addr alone. The hart > index bits live in msi[].offset, the base address only covers the > MMIO regset, which may hold the files of several harts. Both indices > have to come out of base_addr + offset. > > aplic_hart_index() already extracts them that way, and is what the vAPLIC > target path uses, so call it here as well and insert the result with > MASK_INSR(APLIC_TARGET_HART_IDX) instead of a bare shift, which keeps the > value from spilling out of the 14-bit field. This drops the last in-tree > duplicate of the AIA hart index formula, and with it the last user of > APLIC_TARGET_HART_IDX_SHIFT, which is removed. > > desc->irq is used as the EIID as is. Assert that it is a valid APLIC > source, which also guarantees that it fits the EIID field. > > No functional change on a single-group platform whose hart ids match > their CPU ids and whose IMSIC regset holds one file per hart. > Nit: The message is hard to follow because it describes the old code and its bugs in the same sentences, so you never see a plain picture of what the code did before. I would propose this: ``` aplic_set_irq_affinity() computes the target register value by hand: cpu = cpuid_to_hartid(); group_index = ; hart_index = cpu; This is wrong in three ways: - msi[] is indexed by logical CPU id, not by hart id. When the two differ, the wrong CPU's interrupt file is used, or msi[] is read out of bounds. - The hart id is used as the low hart index. The AIA spec defines the low hart index as bits of the IMSIC interrupt file address, and the two are not guaranteed to be equal. - The group index is taken from msi[].base_addr only. base_addr is the start of the IMSIC MMIO region, which may hold the interrupt files of several harts; the file of this CPU is at base_addr + msi[].offset, and both indexes must be extracted from that address. aplic_hart_index() already does this correctly and is used by the vAPLIC target path. Use it here as well, and insert the result with MASK_INSR(APLIC_TARGET_HART_IDX) rather than a plain shift, so it cannot overflow the 14-bit field. APLIC_TARGET_HART_IDX_SHIFT has no users left and is removed. desc->irq is written as the EIID unchanged. Assert that it is a valid APLIC source number, which also ensures it fits in the EIID field. No functional change on platforms with a single group, hart ids equal to CPU ids, and one interrupt file per IMSIC MMIO region. ``` > Fixes: d4676a1398bc ("xen/riscv: implementation of aplic and imsic operations") > Signed-off-by: Oleksii Kurochko > --- > Changes in v3: > - s/aplic_hart_field/aplic_hart_index/ (in the subject too) following the > rename of the helper in "xen/riscv: implement virtual APLIC MMIO > emulation". > - Don't mask desc->irq with APLIC_TARGET_EIID. Instead, bound it by > the APLIC source range rather than NR_IRQS, which will also have to > cover device MSIs: add a BUILD_BUG_ON() that ARRAY_SIZE(target) fits > the EIID field and an ASSERT() that desc->irq is a valid APLIC source > (1..num_irqs), which also covers the target[desc->irq - 1] index. > --- > Changes in v2: > - New patch. > --- > --- > xen/arch/riscv/aplic.c | 33 ++++++++++-------------------- > xen/arch/riscv/include/asm/aplic.h | 1 - > 2 files changed, 11 insertions(+), 23 deletions(-) > > diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > index febc451760..62bbcc9afa 100644 > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -335,9 +335,7 @@ static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask) > static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask) > { > unsigned int cpu; > - uint64_t group_index, base_ppn; > - uint32_t hhxw, lhxw, hhxs, value; > - const struct imsic_config *imsic = aplic.imsic_cfg; > + uint32_t value; > > /* > * TODO: Currently, APLIC is supported only with MSI interrupts. > @@ -350,27 +348,18 @@ 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; > + cpu = aplic_get_cpu_from_mask(mask); > + > /* > - * 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. > + * desc->irq is used as the EIID as-is, which is only valid for APLIC > + * sources: they are numbered 1..num_irqs, with at most ARRAY_SIZE(target). > */ > - 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; > - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; > - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); > + BUILD_BUG_ON(ARRAY_SIZE(aplic.regs->target) > > + MASK_EXTR(~0U, APLIC_TARGET_EIID)); Shouldn't this function belong to aplic_init() or at least in a __init function? Moreover, this check is only relevant in case of MSI delivery mode but I agree it worth checking as we couldn't know at build time in which delivery we would be. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 06 09:53:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 09:53:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441322.1658906 (Exim 4.92) (envelope-from ) id 1xE1rQ-0004Ro-Nt; Tue, 06 Oct 2026 09:53:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441322.1658906; Tue, 06 Oct 2026 09:53: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 1xE1rQ-0004Rg-Ku; Tue, 06 Oct 2026 09:53:24 +0000 Received: by outflank-mailman (input) for mailman id 1441322; Tue, 06 Oct 2026 09:53:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE1rP-0004Ra-FE for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 09:53:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE1rO-005Hci-S5 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 11:53:22 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4c50a-bab6-0a2a0a5309dd-0a2a4507a10e-22 for ; Tue, 06 Oct 2026 11:53:22 +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 6ac4c511-b4ea-0a2a45070019-286bc925ca12-3 for ; Tue, 06 Oct 2026 11:53:22 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DM6PR03MB5114.namprd03.prod.outlook.com (2603:10b6:5:1ef::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 09:53:14 +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.0496.010; Tue, 6 Oct 2026 09:53: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=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=s43iHrtebMfPHlmmIRmahRL0rhVA4J+3SE1zDCz4WdVi5CHsuoWlZ9rxL/eeV4zpwheo3wUWvokJSr9HmtzqzPmuipaJe96DCoeNZLggFarWSBdKVjUbvtK4VY9tqlT3kYhQACGlZWCd/UL1gn1rXGfoQRKev8QzuxaPThwHlHh4LoDijnF9MR2rBKmqwsByb9hg5FWICxteqphIGVtYXpkQobYOeht5T5UV8ppzqdArRLXXLkHB+0HrBs6slXvz6AUEeseKmgCaKk3/Rbx7/NKX5+sFF6/Cxu38rRQfx7XvpGCtY2Gxat8Grspu8ahACbyXJin92jShsnLnIAfNAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FBKbnSwT38Ox90wLcSxenGv+kipT2bjKYVcjPp2CxFQ=; b=dCq4+2W1mWOloVJkeTjCnCieQggrODgdV11odAqK3xXnB/shA01JAp+oY1Z0xIwHAulUciz6k84hqpmf7MkjgfX7d2EvYIuX/X60bO6LQa0F9vvCb7RlDBkdxP8B8/A3rEcQI7yP35mT3S4Uh/2hSKJOTWdudGYcrxhP4E/gwzKI1pLEghyIAwDVrLJnnXNUBObHy/fiJ1yEl+zm/MBPle/l5us193Ik+SAjRfYE7ITXr+DzJ3dzTnGFJQMbEyOr2ccY4HmoTVdyUJh7deV+Lu1PdSGu3nMoZcvSZe46d4HyNGfmK3O/+5l1SR0rNHxWQCX3GZyrjwRwLHlfe7EDEA== 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=FBKbnSwT38Ox90wLcSxenGv+kipT2bjKYVcjPp2CxFQ=; b=UIDMCDv8PiecTD1rR9NSCzHksp5IrKvUqcHWNdtQVM9YxI9I8Nfyp0dcIdEQMojWEwrraToogtRrG+PQOb3/3Fd2mhYgBFvYMC0X7JkAg2MNkDO3u3hDhwekmcenjFRcbI5WBW981gvJK/c9oHQCYXPdOCvwPidTm5wxXqaTyBs= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3f9dfbc2-888d-4065-ab86-319910545d97@citrix.com> Date: Tue, 6 Oct 2026 10:53:08 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/shim: Report -ENOSYS instead of -EOPNOTSUPP To: Jan Beulich , Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1791211375.8631fc262581453bbf619ec5b2062170.1a10c848c9a0003f66@vates.tech> <5058c588-662b-4435-b205-52ee3ab01ab8@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <5058c588-662b-4435-b205-52ee3ab01ab8@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0512.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::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_|DM6PR03MB5114:EE_ X-MS-Office365-Filtering-Correlation-Id: d7860dd8-a9cd-431c-c311-08df238fa331 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|11063799006|4143699003|10067099003|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: EOo1F+ROKsXembdryQ+TNe9NKfLMlnVOza21ziYywRCj1cCqeEbOLnYDzSzfGcFzMjhpTV4G/O5yHDtJ+TMqECO/6rZfF243Lb9/hsFD30Q3vfH/LTy3vNHqDSuTJlTBMviMbvLSxYDPt6+yiYq1bP7Am/39crTIcWHVpX4TaPTpGsCEnVJ4/eAn0enDJAzC27T/Zq438Ctiz0DlJgAcuq48kt2YFB4Gjh0Z5/C0qPNpRm8QRpT7SG8Ci7Ykh3xRPBMVp081yTICsIS4lh1D7kiECD/fAt45FBkJIJ6pMnjK00/z23c7bpGUvTpqdFtgTdwWTF/Nq661tuh0ROJdYogp6+c3ZQpqGgTrmIjDqy6fpEAcK5Sli0+5buvfAdU3Pe4fGSgPdBHi2Utx2jVc84MJffg7MiHpyuiffvKZEZT3FtmapsZo2F8/s44t8beDkmyj3+213uQkuy6mpTtRF76nIhCdyFDhceKSveaWP81qub0gttS6B+WWLD+349lw0iiN44ipZFX9wtQ30HnEr/VTDIXnXeLrTNzsHWw9niIp8VMO4ByQiZiOWBcxqjfDdHfmKN/d5724jGOAqGR9M8FNjjh6SVkyuIu/jfgzNrryKf48WP8GxX5nW1eAHO43ngi9ITTbMOWM0BAC+OwfbwvEBmiyoHG1kxYLGPeN/xA= 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)(11063799006)(4143699003)(10067099003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S2xPUzVLQnptNURjeWhkWmdTNzZCQ1Nza1MvSDNvc3kyRW96QmhZVlhWVDhO?= =?utf-8?B?dTRBWDlSbi9SaXA1NW4wTmcxeTdBTGcrSXQvQlQ0Y2ZmVU1XeDFlNVl5RjNm?= =?utf-8?B?NWtPOFc3QXN1UTBXRG1JaXF3Tms3bUluU0tNS293ai9idmkwd0tmckltQmw0?= =?utf-8?B?WlQreDZibjRLalRGNjhkNURrMEU0eTNDa1NVODFkR3J4bTdVTEpoR3lMeWMy?= =?utf-8?B?dVA5bFBPOVR1aG53RnQrazQzeG1teVBJUC9vNklyY29xaXl5V1NzRzlwdytK?= =?utf-8?B?a2s4cVdVQVpwR2xlRGV0MVdvZStDWG9wbmlpNWF5R3c5MDRPUlRNYXVvRGx1?= =?utf-8?B?dERENkNoVHlsWmU5ZnFIWjFGcCtSdFgxc3BQejVwWkxubG9ldUNBN25uci9s?= =?utf-8?B?S1dpT21KaE9INWVsOTVFUWE5Sko5SkNDeXZtZjMvdzZES0JlZ3RZdWZZdDBN?= =?utf-8?B?VFlNbjJMNjBvNFpmUTQralRhTFI0aWZlRGUwemVkSzQ2OUNxN0FxT1g4ZmR2?= =?utf-8?B?SkIzSUpxZGc0T2FiOFRBRllOSjNFRU1WWVk0eUw2NkZDZDhjTDZkK0RGaGwr?= =?utf-8?B?NE1WQ1JmNit1YWJ6YngrR0l6UjVEZ3hsbzhJaGlvOXlZdzBxdkxCMVdJU2k2?= =?utf-8?B?RWdvVXR2QTZISERnL2N1REpnQVNkN2h3b010cVBMUjl5Zng5Q09vMmRWT1Q0?= =?utf-8?B?clZLR1RadlZicUpPVmZQc3o3UDRpYU9DbDM4UDdjdWtvS1QyS2pRR0pGWlR5?= =?utf-8?B?eTZieWZiZUhQclN5TDc4RzYwbmZtTHhiV0J3Um1NYlpoeGVpcDg2ZmVYNlh6?= =?utf-8?B?ZUtwRmJIUCttTDBud2hFMEdwbFNLcFBDcDdSU1c0b1FlQ01KemV5NWlETXpw?= =?utf-8?B?M1dWbWRrR2M1THo4MEhWamdVeXFRNnVzT0NQZ2xyTnM4ZXF3ZHh2eU91d2hG?= =?utf-8?B?SWpqd2FPMHJSNjdEakgvVlJ1VUVVdGlPcjJ6T2UvMXI3dUE0SksvK2VKUDdL?= =?utf-8?B?ODBhMXNzMndxTm5rOXArajdNam13cHZNd0Vyd1VnTnYwWDlDSTE4UVpOYU45?= =?utf-8?B?TFZEZ0xPL1JyZi9ETXFCbW5uQmdYbnBRSXMyOXpwbEtleUdGd1QrNG1OTlRQ?= =?utf-8?B?WjE4OWZGK09CK3lma3VjWG1aTzdzZXhjZjhoZDZ4RUowbUtRYkJoQ1djVzlG?= =?utf-8?B?R2dMem5PdVFWQzlXNzl6S3Z3UVNTZ1dJb1pWdlV1L3RUTjN0UTlMN0hSUEIx?= =?utf-8?B?VzBiU2pTbHRMQW5RKzZRTTRhc2tEeVZMeWdyUURrRk5IQjRBaldUWFJmcGJp?= =?utf-8?B?N2xRdFhod0M1c2lPQ2V1b2ZnWk8wSEh2WVVrMUw1UTk5RGhkTDJtQUtIb0RH?= =?utf-8?B?eXEzR0dhZFZtQzZnRGtBZk9UTW9JdUhyYmZpdk92S2U5bThnZUcveWRBZnVJ?= =?utf-8?B?ZjlQVDlNQU9MMTAzT3pPZlBhOE9NK2tvUlE5dzhpazlKVmpoMGhid2NXL0U1?= =?utf-8?B?V01XUkFnUE5qQXRyY0V0S2N3TnF1Q0RlbmpNcFpvaXFxSWlOVzVaTEJzajlK?= =?utf-8?B?ZXNkZlJkQlB5ZllsSkJ1cW5LUjFPQnFKTkRVend6KzJqMFlSaXlZcElwTnlX?= =?utf-8?B?ZE9GYkxQWHRELzUwcUxxWGpNcWxVV1hQQTV5ZlJXajYyVXR4NmZzM0xFek5K?= =?utf-8?B?UDN4dTU5TFhTTllYOTk1QUMyWjdjS3F2MmxFOHRUTkZTZzhJUm9jMHlDOGJU?= =?utf-8?B?Y1hqK0JBZkI2ZnQ4Q0tTN1VTOWluLzFsWVF0c2QrZTR6cXNRM2FqRFZlazRv?= =?utf-8?B?MCtFOXMwb2d5YzFvOC8yYS9XYnMwNGhxbWJFeVBXQlkxOHZYbHkvVUdzN2hM?= =?utf-8?B?bmE3Yys3cGFBaUVpNStIcU82bE1DV3BIOUlIMms4TUxGV1RKbzNTdXc1bUdC?= =?utf-8?B?dXhhUytZaXFpVjhmZmVudk96L08vZSs5czFYcGRla1NyQzk5akQ1cWJyNXF4?= =?utf-8?B?OUFLM29PWXVpZk5aUVl6S2xnRm94Yzl4bnhodVZXbFRYM2V0d21ONTRvUmgy?= =?utf-8?B?M01va0pwL1l3K0IxdGR1OFRTMGdZeEE4REFrQmR3YU11RzBaY1BWd0xDdHdn?= =?utf-8?B?ZEZYNGQwYU5HdVcyalF1NU0vaUJGZVlWRSsyWUkvRm5VdDdGOVhCOUZ4Y1ZD?= =?utf-8?B?ZHF1MDJDL3NWR2JwdHl5UEhLMXdWNkVRWFhEekNmU2VmREJrU3dEZkxxSlBL?= =?utf-8?B?OWg1MVlsL1didDgyWXprbjRaUUkyTTJBZEJiaVF4cUZVYlgzOEFXRDVQS0l5?= =?utf-8?B?OW5jZGM2bVQzWTFMdHg3R0R2MjYxVkN2WnQ3d2ZCaVJBRXpsSEhUblV3R1VE?= =?utf-8?Q?Io2+uXYaTaCSG4mc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7860dd8-a9cd-431c-c311-08df238fa331 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 09:53:13.6977 (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: J6eC/WcmX7beENaAar8YkVowWta2lu4oUuUfI96vHp2LFyBYP8EIi5RcfOWEBUa8qepjpcSNnacvK0a5LklxtFgB9UlxLcd2pA1WTPgpIOA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5114 X-purgate-ID: tlsNG-ef75cf/1791280402-3C411AE4-3BC5D93B/0/0 X-purgate-type: clean X-purgate-size: 1503 On 10/5/26 4:11 PM, Jan Beulich wrote: > On 05.10.2026 16:41, Teddy Astie wrote: >> Main Xen reported -ENOSYS if the operation is not implemented, however, >> shim errorneously reported it as -EOPNOTSUPP, potentially confusing the >> guest. > > I question "erroneously". -ENOSYS has, according to my understanding, exactly > one valid use case: A top-level hypercall (normally: syscall) function which > is not implemented. Unknown sub-ops etc shouldn't be using that error > indicator, or else callers can't tell one from the other. Maybe they shouldn't be using -ENOSYS but AFAICT the majority of hypercalls with subops do return -ENOSYS for unknown subops (with the exception of kexec_op). This is something we tripped over when implementing the hypercall filter for XenServer's Secure Boot. Ross > > That said, it may still be legitimate to make the change here, as making the > change in do_grant_table_op() and do_event_channel_op() can be viewed as an > ABI change, which then we cannot easily do. > >> Make shim more consistent with Xen by reporting -ENOSYS instead. >> >> Fixes: 49f79fe03dfe ("xen/pvshim: add grant table operations") >> Fixes: 368ae9a05fee ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU") >> Reported-by: Teddy Astie >> Suggested-by: Andrew Cooper >> Signed-off-by: Teddy Astie > > Reported-by for yourself is pretty unusual, btw. > > Jan > From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:22:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:22:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441335.1658915 (Exim 4.92) (envelope-from ) id 1xE2JP-0000cv-TE; Tue, 06 Oct 2026 10:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441335.1658915; Tue, 06 Oct 2026 10: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 1xE2JP-0000co-QY; Tue, 06 Oct 2026 10:22:19 +0000 Received: by outflank-mailman (input) for mailman id 1441335; Tue, 06 Oct 2026 10:22:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE2JN-0000ci-Qj for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:22:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE2JL-00E0Vp-QU for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:22:15 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4cbd2-e002-0a2a0a5209dd-0a2a45079fb6-18 for ; Tue, 06 Oct 2026 12:22:15 +0200 Received: from [40.93.195.23] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4cbd4-b4ea-0a2a45070019-285dc317fb8a-3 for ; Tue, 06 Oct 2026 12:22:13 +0200 Received: from BN1PR12CA0002.namprd12.prod.outlook.com (2603:10b6:408:e1::7) by MN0PR12MB6103.namprd12.prod.outlook.com (2603:10b6:208:3c9::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Tue, 6 Oct 2026 10:22:07 +0000 Received: from BN2PEPF000044A3.namprd02.prod.outlook.com (2603:10b6:408:e1:cafe::27) by BN1PR12CA0002.outlook.office365.com (2603:10b6:408:e1::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 6 Oct 2026 10:22:06 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF000044A3.mail.protection.outlook.com (10.167.243.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 10:22:06 +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, 6 Oct 2026 05:22:04 -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, 6 Oct 2026 05:22:04 -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, 6 Oct 2026 05:22: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=YkaOzxq7qwhIgz8YAmNiyj+fcCJIg0FZAK66CufypMsqEU14imOC8In+pnWPkt1ySsVk99yfDBoLt80b5cdSA0qg9HYkL94QFuoH0im94PgsGevY2tFQXtQl0CRmdF5lXyzGry2uGm5mBjp9WzRRRwqCufjsHfXhButDD+QFXckeeexp/qdY93Z7pBBdc6B6zhKHgjVx5tmeTqhkCkJ7DQtNkgefQf+wOZinWpc1pkW2pVzyckLVaXX0JR2gFAmPfN1bGYuA0WvJs4QDXmfSERvkW4bESdQi7aAHFvMAXYFnBd51q3o94UlA2CwxZBJgZQzVB0C0SRJ2OVWQ9mPdmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ySFOSfm4QWV6mZA+7DMYS6OCfeRFgu2gtuH5FW9VWEM=; b=Qlx0KeLNevmMfRX4TNpoVuxp16hJzqWgq5Wse91F3h4vkV+RPGQ+1vRlAMxy5F2S6pQ1utUQIp6ks8S5pHnso2T3Zn+FiumkGAXOEwvQ22mYGRL9Xj9RemrpqfmZuj1taOHhPl6f4uS8SGg8RF60VqyNekJsl806gDRoz7QF8mhJmmsLebx3v31eby2Ddp0L2R8l4HQD4NgdHgwkcx8Bt7ew003TgUbnzsV8vBq3f8X+ieUgSfz4O64gcIRwyFjViBBrqs4X+gNMygqWQzHzKOQUBYo+K+/tXE3Qkc7YzBx79Bf0HmV63J9muGRP8EocqVyY6hpBdldgsu0XT79F3w== 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=ySFOSfm4QWV6mZA+7DMYS6OCfeRFgu2gtuH5FW9VWEM=; b=gHeEysgXyGb+80ACvYr3epGWUxjIQGcgPBSxjUktMbhi0n2Lh7q0Y3MxfJspEPUDOzfwKf1epnQ9vSwFtS653YAGDkORwuAIzNUJs8nx1QwCjyd6YhW+PC/irF9qUtI239rTrTnsXadMC9Q0Oa8oLz11xlT0Tx4NiGcC2WDHb+4= 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: Tue, 6 Oct 2026 12:22:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/arm: gicv3: initialize eSPI unconditionally To: Mykola Kvach , Leonid Komarianskyi CC: "xen-devel@lists.xenproject.org" , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk , Julien Grall References: <13181424f9be3f5e31977fbd505209cd0508571b.1790102501.git.leonid_komarianskyi@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A3:EE_|MN0PR12MB6103:EE_ X-MS-Office365-Filtering-Correlation-Id: 49a8f3b3-1b80-41db-b25e-08df2393ac5b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|23010399003|1800799024|36860700016|56012099006|6133799003|5023799004|10067099003|11063799006|22082099003|4143699003|18002099003; X-Microsoft-Antispam-Message-Info: UMZayClMkBKA7dRxICcVk/IL4sYXGQJkROJRGvz41f+mOChVMjBOvzuWvuIFRgpZAlHdIyDyzjpEKdLFJSMEaOGZFzIw2FrNNEc/FTXrmjIOcnuF4nTlryDyjiGADXFgaeQC8wx8TCxH4fVovxf6lh+iTptjR/d6Iy+eeQ/qH4LxA5zpbO2PL4lGG4qQpDLp6npigCAe1uJ4c6EpL9fW2fkqmcFv/iC1ynWNPPzyMpa7X8ud9nPbUZrCBpN6OZQWmsE+1ojZ5LtnyA5ya4Gm8ruwZ+A+Nla3c+72xj0d3V0SDSQM/cMR0v965scyh4oTdfJqR5TXg2pl+qU8WLTm5soJvpIbLJoT+938OfLD6+JM4zQAA20kYftKba4mPC2tBeMfr7SEN3BOR/+qIYKzWk+NORzYLu2rWR1b7vu6uHdLiq+qSmN3u9Zo4KwywoXrn5PKZH1Bu5iPLStqR+lnO/8x2MvucUq9onT7/ZmN7AyRUQdexFPbWKBbGTUHfeCVbuJLFd8iTNT3IcgYhya6W4zODfPHfXApkdLY0tWxKa+426YWtIwBYYSXmlq3OYIXHI51StxsdlFiz8vbaZLnMuTCk4cC0rMcrb/hIm0AReUFWxUL148exQxhqjj2vv0JCy6H3d2o1YHlkntelE038oDirFbDpH7Eff/aOOr6hUo= 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)(376014)(23010399003)(1800799024)(36860700016)(56012099006)(6133799003)(5023799004)(10067099003)(11063799006)(22082099003)(4143699003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 3ptDOUpHUVcZiXqUDhczz5KgZRvyNb7HPnllGCsBJgWKAQIXLwe9fvCVYutzfsGV3Uc9JAYeemX0D8SB5FPUmk2OcANtZPff0mFdZOETQGRCmmK/S88KGCoxW37moz+ascdluhROvXoFLa/qM7NwqI2u9ulYVo/ZEbK2JjYcT+9ciK75mXx6EP0g9bqIhrrmV27Ttf/nRZTqOCQkOD+VgjzK6icWr0e0TM0dQOZjuzX5RSqWC5L4orJvLdhCoBSZzY6LRLzUemzXySGm70d7aoFk93c6SmRP4tEFR/7sbOn+Zs9q7bBdtepkl59d5qTbG2ktTPhPcGAG4is4if1oQUVGyQxu50BNe8zHlO8x0PfjtFgwtKRJniC/UlVZCPVNNP00dek5n5Q4hCm4bIjOAMK0hyVjxjtKtNbF6ZdEyAzXBDszdMz4qCUddoS8wjaq X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 10:22:06.8314 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 49a8f3b3-1b80-41db-b25e-08df2393ac5b 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: BN2PEPF000044A3.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6103 X-purgate-ID: tlsNG-ef75cf/1791282133-A6EDEAE4-399F55C6/0/0 X-purgate-type: clean X-purgate-size: 4937 On 29-Sep-26 17:14, Mykola Kvach wrote: > Hi Leonid, > > On Wed, Sep 23, 2026 at 8:55 PM Leonid Komarianskyi > wrote: >> >> Hello Mykola, >> >> Thank you for your review. >> >> On 9/23/26 11:04, Mykola Kvach wrote: >>> Hi Leonid, >>> >>> Thank you for the patch. >>> >>> On Tue, Sep 22, 2026 at 9:59 PM 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 eSPI >>>> 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=y. >>>> >>>> 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@xen.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 = 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=n. >>> >>> 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). >>> >> >> Section 12.9.9 describes GICD_ICFGR, i.e. the regular SPI range, and >> it indeed contains this requirement. However, the code in >> gicv3_dist_espi_common_init() programs GICD_ICFGRE, which is >> described in 12.9.10, and I could not find an equivalent requirement there. > > Thanks for checking. You're right, the eSPI section does not state > the same requirement. Sorry for the confusion. > >> >> The only related rule I found that also covers the extended SPI range is >> in Arm IHI 0069H.b section 4.5: >> >> "Changing the configuration of an interrupt from level-sensitive to >> edge-triggered, or from edge-triggered to level-sensitive, when there is >> a pending interrupt, leaves the interrupt in an UNKNOWN state." >> >> That rule is about the pending state rather than the enable state, though. >> >> Also, the current eSPI initialization sequence mirrors the one used for >> regular SPIs in gicv3_dist_init(), where the requirement from 12.9.9 >> does apply. So if we decide to reorder the initialization, I think it >> should be done for regular SPIs as well, ideally in a separate >> preparatory patch. > > For regular SPIs, let's wait for the maintainers' feedback. I think > any fix there should be a separate patch and should not block this > one. I agree. That's the pre-existing issue and can be fixed in a follow-up patch. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:23:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:23:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441340.1658925 (Exim 4.92) (envelope-from ) id 1xE2KJ-00015t-6V; Tue, 06 Oct 2026 10:23:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441340.1658925; Tue, 06 Oct 2026 10:23: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 1xE2KJ-00015i-32; Tue, 06 Oct 2026 10:23:15 +0000 Received: by outflank-mailman (input) for mailman id 1441340; Tue, 06 Oct 2026 10:23:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE2KH-00014V-N4 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:23:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE2KG-00GD4T-JN for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:23:12 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4cc07-2eae-0a2a0a5409dd-0a2a4507b9c6-32 for ; Tue, 06 Oct 2026 12:23:12 +0200 Received: from [40.107.208.16] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4cc0e-b4ea-0a2a45070019-286bd0107d4a-3 for ; Tue, 06 Oct 2026 12:23:12 +0200 Received: from CH0PR03CA0427.namprd03.prod.outlook.com (2603:10b6:610:10e::30) by SA1PR12MB7037.namprd12.prod.outlook.com (2603:10b6:806:24c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 10:23:06 +0000 Received: from BL02EPF00029927.namprd02.prod.outlook.com (2603:10b6:610:10e:cafe::5f) by CH0PR03CA0427.outlook.office365.com (2603:10b6:610:10e::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 6 Oct 2026 10:23:05 +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.496.14 via Frontend Transport; Tue, 6 Oct 2026 10:23:05 +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; Tue, 6 Oct 2026 05:23:04 -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; Tue, 6 Oct 2026 05:23:03 -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, 6 Oct 2026 05:23: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=kHBoaaWfMBP1gqFg7pWv8yV8/piN0nzJBWhiLE+z1AceNVy8Oc3l5iZMy6AEiYXzBefEUB+yOcNt2UMBgDUKWQ8L7vumc8KeYbo9YClbPxeVHxK1j381vjKxKLcFkz4TVfUwEGNOg3UpU4GYA4Fv48tWeV8oTa4NYPSefGLb5gMgPa4Cz+FYOqb5Hg1qA4Em36JF9Ep2CgLc1VSOGIYMm7h8ity02s+ygHuISMF2DW4z2i4o//9+PJlS4AG0yUFMpvhPUNiZlBbrnBXxgqIZQYiTuJz6V6fZjwbacjaHqxiC9DzbxGrmDmPWMUPmfUSoaiyZEESiL5JmLSz/ynI5qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lfNd1lVOmWIcKJtfAvE5HZDVpRKAV40UT90Eetbqppk=; b=hM32WG3VeqSnklFoynkr3CPKlOmeZIrGh5qIh5lN8TsDla8NTCgJRiFfmpUEQCTnLetY9PNbRuMNhaIp7WCHpBycyyPQRCOn/RBIqyFW55HHiBOKhhXzJDaV6gBbs7I2ltkQkjoGfmyMVjQw+RnUd9DSDbcZQEJcfZNwvaUVFKjEIuZLNILJALPjjynmUyebt0nQgs48acElRb5WwwPU9+4VW9vN1tul2utZUmzFXRcCFl8m9dCXfr5K3VzZ1gR27gPOsQ9QK9NQFEy4GBO3+SiC62Vjdz9MZiYWHRixHXvoAtatoCvc1tFkKj/z3Gn9DMcZmBpXru3mUqyMVu6krw== 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=lfNd1lVOmWIcKJtfAvE5HZDVpRKAV40UT90Eetbqppk=; b=rK9voV+8sosNw2up0NGojkpsi5iAQgWf4hgUbAZn4OeTAyuFBflXw7PaNIkvOf4lo8MppYgT0yvnxX7VfU5fWE+PH3bTA7nnkALREqvexAlTJrv7fXjUBlUropKKVA8lt9HQ5W9Zshkmb68JpU+HE/tOc63AQy58WtO20D5up8U= 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: <2c5da778-2e5e-42ed-9e12-930043316b8d@amd.com> Date: Tue, 6 Oct 2026 12:22:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/arm: gicv3: initialize eSPI unconditionally To: Leonid Komarianskyi , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Julien Grall References: <13181424f9be3f5e31977fbd505209cd0508571b.1790102501.git.leonid_komarianskyi@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <13181424f9be3f5e31977fbd505209cd0508571b.1790102501.git.leonid_komarianskyi@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF00029927:EE_|SA1PR12MB7037:EE_ X-MS-Office365-Filtering-Correlation-Id: 37ac1213-b73c-4070-e359-08df2393cf40 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|23010399003|36860700016|1800799024|6133799003|22082099003|18002099003|10067099003|56012099006|11063799006|5023799004; X-Microsoft-Antispam-Message-Info: JPDIWpFaTVL72sS/MC/BXaZX9lmaos1Wuj7SzDcqpz9ZjVRrS6ykm1ubn3idSJxL+vIPOmuGU87N2xTJoUGlnNq4SZp9Y6DvOMHvRPMMKSPMAPONSANuUx6fo0IQ7WxyUlfmMihOy/DQbNOMkRP8Ye/QTZB6SpQip8xKMX4Eu0KFbG7EhRBRw99wygHDhG5t3qfORxWKQye+qDiuATCjtnh3Ww1IJTfctnONz2eiKRWTOBux3DhI7LiBYmXtVFW9ZCfTb0qqr9SwKPvzLWrMDRZie/xVBc43aGgKHgAcyl8HSEocwBAiPYkdwoysiH80hfeWAk8OF3QgxIYQQqnj7bqbQKizTnXfI33X8eMrmJSZOeu1e+NmZ7/Cc/JMB3BGduD/R0rzr5u02dV0rfdBqeVcnIO8hR6ZXmoKXyJPC4H1d7RszxJIyaWJIHZZcfYjyi03NDSU2ifexz0TCjpD1Y5efXRP/veGjpukY9P6+eMP+4/UUsZGwottu7EF01bDH2cfrWEV/yyIPR5uyJzhAb9NzjhLU6ERr8l/SWmk62O5xDGvALp4/IYwU8BsWLhXbpelmGqAA2jI1LVE7SEBfvu2vTJtwoG/USV0XMrY7e6lt5GFxFp0zABXZHGMK/cKVV2lhomwLOdUiw0RI2OsoQ== 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)(376014)(23010399003)(36860700016)(1800799024)(6133799003)(22082099003)(18002099003)(10067099003)(56012099006)(11063799006)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 1YQ6i7uP27BcRhh4XKqp8/96kENj0i4NThNwsJZgNyDsOPZQWNNQOOm4hiLyeTjOZsYCSYuLfRvpe6JaLpJPq1l39Fo3TSqZrUqDmQsn0LftsDxKaZr8LqxSq2icEADFlolo3qGoNJTF8gZTOAsOlqB9r8r/MynL/wg0RTFQ7rCOXZrM5UktaVGMhQ32EzKIQp6T5Zc08RXn49SYhpBe/GNSVOzp3xWrzGFYOICWK4CQyZIkICBN26VmvelsMdY4ap25RbBddW6PJ5h9VQV7dPlje5qua0s7cqctpitorJxHyiEH7J+9bAu8LzrpN8mOgAjiHgJz2GltiFXQkkupYSf/e9QJ9MkvDa7aX5CM6V6oafXpPNR2xzT/y8mQjEsdn6r2KIXthLj7S3YMCFTZfawPaWHGRME3MXWZ5Av7IoESPTnDX6dJDATGOrO25uC2 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 10:23:05.3719 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 37ac1213-b73c-4070-e359-08df2393cf40 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: SA1PR12MB7037 X-purgate-ID: tlsNG-ef75cf/1791282192-360C5AE4-D52F64C1/0/0 X-purgate-type: clean X-purgate-size: 2372 On 22-Sep-26 20:58, 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 eSPI > 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=y. > > 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@xen.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 = 0; i < gicv3_info.nr_espi; i++ ) > + writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTERnE + i * 8); > +} > +#else > + NIT: no blank line here. I'll remove on commit. Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:24:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:24:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441346.1658934 (Exim 4.92) (envelope-from ) id 1xE2Lp-0001hY-JX; Tue, 06 Oct 2026 10:24:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441346.1658934; Tue, 06 Oct 2026 10:24: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 1xE2Lp-0001hR-G5; Tue, 06 Oct 2026 10:24:49 +0000 Received: by outflank-mailman (input) for mailman id 1441346; Tue, 06 Oct 2026 10:24:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE2Lo-0001hJ-KJ for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:24:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE2Lo-00Bgz2-0h for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:24:48 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4cc60-bab6-0a2a0a5309dd-0a2a4504a8ac-36 for ; Tue, 06 Oct 2026 12:24:47 +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 6ac4cc6f-b57f-0a2a45040019-d1558035ccc3-3 for ; Tue, 06 Oct 2026 12:24:47 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a168355946so5425095e9.0 for ; Tue, 06 Oct 2026 03:24: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-4a17c7b7f00sm13803035e9.13.2026.10.06.03.24.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 03:24: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=1791282287; x=1791887087; 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=3whEvDDGudRFBdQmtdVS8fdNXFeYB7xx89+j7BgZ5Lk=; b=Tw+ppuiycfn2E7gT+WLsgoB2D9tVBpqtKWk8ztjx+HWwPM1fj7k4D5DteER3AbqIfC EiWp5DIv9GIMkVDzcHoqK8hqrkCGUkBuo2f7KpY/fGniyk57FJKhr6X9RyG0SxG+t7SW 5BcXZ8EeCEedJuT87HtmIrhnC6yb/n+3FyKGqISBbw3/UojOG1QGG1iFwnrB4ppBgf+a Eo7A1WxE6EytsQEOaJignkwSz7aT7rEKAWW8bMnWeyeslU7ocW94s35ArMh2yenwH1eJ RSfBYrBrCpVcUyw98z8vDNG86hJ5SaDajTCjbe7B3wlcpJgdBjagdAKxKqn1bnX7WZ+2 fCrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791282287; x=1791887087; 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=3whEvDDGudRFBdQmtdVS8fdNXFeYB7xx89+j7BgZ5Lk=; b=R+8gEYCrWkgAUNSDabh1u3vo0O4Ck9fG2HilvCwg90PmVk5JJwL/ePPrfqA3kEqU8z YFtbb2/xdGpYvMeSkfcqcAWbioALXKCVNqTbwgbgSycmqiHZT+wo0JkZcmHSCVwY2K8k 7S3lSOQjkSpPz+BKUCTo19tPG1tr+ZAaLAvVVh0ymQ8WmOvqQ8QIYFdnMfWWC7vJURPt ezKhmvTxAqdLcgCb3NkYSSR8O7vIqDZGWrANt/JPj8+D0PtGYjIXPVulFDRpgI05So85 kFnaj6KDdWCB33j03TKaYBj/ldtpcFHmUGPSaqDoTsJrGrG7Tt2QiQPq5+k4gSSYaFOH F2nA== X-Gm-Message-State: AFuF++n70nveKciTxgUtPdYiaOpaAxa1XL9j90iSlttq87OIavjLLX4/ Q6ZyOuS1pYmwaV8mNK5kMHiDLCk1rKiHRMiNHB5K7vvlulQVaeTsEr0DBtuV0REzHeMisrZlvlA 7acyZIA== X-Gm-Gg: AYBFou3HewtIuCzHZ2ayFamL+1QKwznoe20kDadUc+rPXE3tJ2GXpLatZ+aoyKjkGdA LzbwAcZHTmpwSrKBzshjeWZFRgoZmDKZmRuOORBbKA0pFnRrAQzQDiltze4c9tJYppHtjRatthD afVxXHZ2oOxkKSmsZ4sKviSApVy0bhqqP8ko/B8uFhsnFfsCzT1izJHBjF7I5R10TVQyGLx/OZV WGS6k3Viq02SojYbJwzkw+xD9I7BarHHeja8A7IhuorcjgWRoLL9jWsr118vx59M+atNqeJzeON +HiKeCMW7YDj8VviC7O6jtYAF5hjRkHBSsgaqDTRscXH3gH77djC7j5biBJNVdSEcxU+NGr7kB2 laRvRVhlQ2JlLZt4fNGqk4TCvCXYx5joM+Tp23Ax2m5cM6x82inhIzBJvj4ukDTreH3hsjfu+mC 4QLMjerGxdpmGyIPctQDbam/mM+aw6PbPNBq4jc6pjEzDAGtEh/9X4KinYIbXqBxk+Bscvpn0RJ N7ojJORzRJgM5ylaKE9N4sPgxE3HilccdeO1Cb9rtwdRqXGTvgVwM36hT8ldhvLa6OvcIgn5w== X-Received: by 2002:a05:600c:c491:b0:49e:69ff:c6b1 with SMTP id 5b1f17b1804b1-4a17b562d60mr16865665e9.31.1791282287291; Tue, 06 Oct 2026 03:24:47 -0700 (PDT) Message-ID: <29e67a54-119d-4991-a301-5f0351b125d7@suse.com> Date: Tue, 6 Oct 2026 12:24: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 v2] x86: add noreturn in a few more places Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1791282287-52ECEB50-99D6B3A7/10/78276251493 X-purgate-type: spam X-purgate-size: 3545 start_secondary(), do_double_fault(), play_dead(), and tboot_s3_error() never return, so would better be annotated anyway. 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). Note that adding "noreturn" to do_double_fault() causes new violations of the same rule (2.1) at the two call sites in entry_from_{pv,xen}(). Signed-off-by: Jan Beulich Reviewed-by: Nicola Vetrini --- https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2916849077 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)? Perhaps need to deviate it? --- v2: Drop entry_from_{pv,xen}() changes, for being controversial. --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2163,7 +2163,7 @@ static void __context_switch(void) per_cpu(curr_vcpu, cpu) = n; } -void context_switch(struct vcpu *prev, struct vcpu *next) +void noreturn context_switch(struct vcpu *prev, struct vcpu *next) { unsigned int cpu = smp_processor_id(); struct cpu_info *info = get_cpu_info(); @@ -2240,7 +2240,7 @@ void context_switch(struct vcpu *prev, s reset_stack_and_call_ind(nextd->arch.ctxt_switch->tail); } -void continue_running(struct vcpu *same) +void noreturn continue_running(struct vcpu *same) { reset_stack_and_call_ind(same->domain->arch.ctxt_switch->tail); } --- a/xen/arch/x86/include/asm/cpuidle.h +++ b/xen/arch/x86/include/asm/cpuidle.h @@ -26,7 +26,7 @@ static inline int mwait_idle_init(struct int cpuidle_init_cpu(unsigned int cpu); void cf_check default_dead_idle(void); void cf_check acpi_dead_idle(void); -void play_dead(void); +void noreturn play_dead(void); void trace_exit_reason(u32 *irq_traced); void update_idle_stats(struct acpi_processor_power *power, struct acpi_processor_cx *cx, --- a/xen/arch/x86/include/asm/tboot.h +++ b/xen/arch/x86/include/asm/tboot.h @@ -126,7 +126,7 @@ int tboot_in_measured_env(void); int tboot_protect_mem_regions(void); int cf_check tboot_parse_dmar_table(acpi_table_handler dmar_handler); int tboot_s3_resume(void); -void tboot_s3_error(int error); +void noreturn tboot_s3_error(int error); int tboot_wake_ap(int apicid, unsigned long sipi_vec); #else static inline void tboot_probe(void) {} --- a/xen/arch/x86/smpboot.c +++ b/xen/arch/x86/smpboot.c @@ -326,7 +326,7 @@ static void set_cpu_sibling_map(unsigned } } -void asmlinkage start_secondary(void) +void asmlinkage noreturn start_secondary(void) { struct cpu_info *info = get_cpu_info(); unsigned int cpu = smp_processor_id(); --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1080,7 +1080,7 @@ const char *vector_name(unsigned int vec return (vec < ARRAY_SIZE(names) && names[vec][0]) ? names[vec] : "???"; } -void asmlinkage do_double_fault(struct cpu_user_regs *regs) +void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs) { unsigned int cpu; struct extra_state state; From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:32:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:32:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441360.1658941 (Exim 4.92) (envelope-from ) id 1xE2Sq-0003f9-8z; Tue, 06 Oct 2026 10:32:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441360.1658941; Tue, 06 Oct 2026 10: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 1xE2Sq-0003f2-67; Tue, 06 Oct 2026 10:32:04 +0000 Received: by outflank-mailman (input) for mailman id 1441360; Tue, 06 Oct 2026 10:32:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE2Sp-0003ew-61 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:32:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE2So-005dbB-Iy for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:32:02 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4ce1a-8faa-0a2a0a5109dd-0a2a4501b568-24 for ; Tue, 06 Oct 2026 12:32:02 +0200 Received: from [40.93.201.40] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4ce20-5984-0a2a45010019-285dc928d3e4-3 for ; Tue, 06 Oct 2026 12:32:02 +0200 Received: from SJ0PR03CA0284.namprd03.prod.outlook.com (2603:10b6:a03:39e::19) by LV8PR12MB9641.namprd12.prod.outlook.com (2603:10b6:408:295::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 10:31:57 +0000 Received: from SJ5PEPF000001F7.namprd05.prod.outlook.com (2603:10b6:a03:39e:cafe::72) by SJ0PR03CA0284.outlook.office365.com (2603:10b6:a03:39e::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 6 Oct 2026 10:31:56 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001F7.mail.protection.outlook.com (10.167.242.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 10:31:56 +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; Tue, 6 Oct 2026 05:31: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=unPSKZ6MGr3AahWjc6PsOAUBbrlVjS3QN6rOfJg6jHRujg/+VppCgXybRmRw222lgFAkItypSlz1jpn8+QVuz+CBUmX7dgsM5TcPA/eOLupFKn2tXehAY5NZxHdP6C9QHKGmn/iorZHBTG6pmJpJZRd62rYISNqqPPvDF03OBFnx7rm1OAbD6rli2xTvm34sKAUV6IZWvNvLjjSwq0RBMks9LyKHJN74oXPT5jKWha2DMBuDw74TF/cZiqB9TsNG5aMeoAiM9JJ/990fnq6SR078cxWgVoi3BHvFmsBtCpPXs4PdfhdTKi3wA7rC5NEAm1jqSv8/BnOO801iRrpoKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SaWkWhr8Df7fn3pAXC2CTiSVEyMc+gf6VWML+h9pGoA=; b=sPYn1j1iMylT9WfpjNC/AXxyJ+aixZ1IgjAfeYokJh598Tvg40KMVNoegzLGA1Qfy4j+Z6rSI9N64UY38Q8fuUu1ZltXwI2fFQY19Djfp83/Dtsl7cHtTRTsRJ2glgyOBRE11d+gHumXBGqzCTwww707fZE0zgHRQZnQdzyQYGDrwtpbHUASaVQomvw8IgSqnHlZz2jeX/UdAIY0KX7eqAIVR9uu47hf7yxzSefeg4tIj2OTuPhrrRYKZBelEAARHBhlC8+DxNon+Q+/Rr/oLLBNyf+B38L3Y52ZuqqCLM4SXyZUjne3HhsBXgI4XPWaO6Uu651whjLsV2qZIHlI8g== 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=SaWkWhr8Df7fn3pAXC2CTiSVEyMc+gf6VWML+h9pGoA=; b=I0If4aCVxG35hWcUfIWhRDsYFGhW/bJ1u6MmTpQtHU8ub5XSCbw0OJEIm0BBnZ2w6sgu4PCJxKpwq2jC7fW30q+aR3peez2KDB6buggcKqjAH7Ab43B06f5IBIarkUaM9O8qc0E2z2FYz0L9LO2giat6ffSE6Aa5Jns+p6plZFw= 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 From: Alejandro Vallejo To: CC: Alejandro Vallejo , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Michal Orzel Subject: [PATCH] arm/nospec: Make nospec helpers always_inline Date: Tue, 6 Oct 2026 12:31:40 +0200 Message-ID: <20261006103142.139422-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: SJ5PEPF000001F7:EE_|LV8PR12MB9641:EE_ X-MS-Office365-Filtering-Correlation-Id: f6df2be3-bd37-46eb-cf52-08df23950bb9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|376014|1800799024|36860700016|18002099003|10067099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: T7aWvoM75eC09qK3ykCWPDgUr0GldBgcODPJqlf8vT+9jtpJCv8JOAzc11I/gHCU9bB1uoEfz/1vggPiXFp+FyOBWCSBm8yECyU6nHPu6bqN7jd/F89D3T87zhEkesvz1sCLrLo4snm7KD6xnQeZOs71gRer5q9eyHm1lVXtCoPrn5yYh20loVqG3eLvDHC4CqJ8drk1EnhBdlJIPZ16L5Mxi0xEVhpUdA/duiSKn+lmwz4QUknItUWMHWOk4gcg8Jdk1aDRDy9RzCxf6lUJ4Sqo8dA2RMl40cDSdexAgk9w4Sadoc1nZ110XGkh5hNFWmZWUeeOXyybLJtn+VJ+thpplY9E8Cvd4dZP9gMdE+aMGNmoczf+nxjMpOydMkwm08SZartlxOfC+A1cKsFvOXzStx+VWgppG6e9JBls/ASgE4LO9CSoOp+vlx1ResZjWLvbcD3ZQQnlDZZtfOuN5udPgUUOL/LOulPhbg3RXgB7dq+0s5Pg2wDN+e3XXu8RxoArZX1Mn99ulxMcfzMUCAOspy1BqIvSasfVz6b0+YQIihlbeRIfbxOduLvHyZArtboCEfmX189hvVlq9ZYAbEz3Z7MC/r6LvW7RNXzXokKUlVLM9YqVxEyLA57AyFWYHhVi7YPSGx/N3SHNhsGRvCPpEH9K5sY+uowyk3hgCbogXCmsyD7L5SgrGNtl9miW/n78y+lol4+UT4CeyxwKDA== 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)(23010399003)(376014)(1800799024)(36860700016)(18002099003)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: pgctTiA6ADwzG9XOqc0ioXMj7mXNcUYIYfLVcCebcGasIcu0QsF/zh/HPYiaK5D1h4fv9O3c4Mc4K7eCUJwIYoUOW8o3qxT2HeOV2uXVC86C3xDfqRgyb5t9c+dQRRk1mLtxIuya56J9QOShKwZlzON0MsoeLjFc1QoJAqoY0KoiK3opLhn8R7U5NbY8DcXbgZlas72iMNvLHOcon9hox0l/M2kS52Sgh2i/1jNp6XhE5U2rZsJx1pONwmErSs4C+d2tOj8tXsGIVkMeqvaurTutSgQLwqljpUUOdMiljXN5NWE/Nv4XvK005ap5QYgLVJa4gCyc3LadMyDxEPAsbFWPlVotmrejp4Z0pVYdUf9R9a+Jlxtb/HlItRyQetC6fCimC2Wh91MpLwGnXBjPfbqCbkyUeQnyCaud5zqlkzLgmhEOO55RKZetrXqssCPr X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 10:31:56.3051 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f6df2be3-bd37-46eb-cf52-08df23950bb9 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: SJ5PEPF000001F7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9641 X-purgate-ID: tlsNG-d62444/1791282722-1D87F757-8270B616/0/0 X-purgate-type: clean X-purgate-size: 974 While today they don't implement fencing in a way that would block speculation, once/if they do they'll absolutely need to be inlined, even if -fno-inline or -fno-early-inlining are passed. Signed-off-by: Alejandro Vallejo --- xen/arch/arm/include/asm/nospec.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/include/asm/nospec.h b/xen/arch/arm/include/asm/nospec.h index 51c7aea4f4..b84f8dff45 100644 --- a/xen/arch/arm/include/asm/nospec.h +++ b/xen/arch/arm/include/asm/nospec.h @@ -4,12 +4,12 @@ #ifndef _ASM_ARM_NOSPEC_H #define _ASM_ARM_NOSPEC_H -static inline bool evaluate_nospec(bool condition) +static always_inline bool evaluate_nospec(bool condition) { return condition; } -static inline void block_speculation(void) +static always_inline void block_speculation(void) { } base-commit: 290959692726bed9a9404fbb151767dba9928c5b -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:37:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:37:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441368.1658950 (Exim 4.92) (envelope-from ) id 1xE2Xk-0004QH-Pi; Tue, 06 Oct 2026 10:37:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441368.1658950; Tue, 06 Oct 2026 10: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 1xE2Xk-0004QA-Mo; Tue, 06 Oct 2026 10:37:08 +0000 Received: by outflank-mailman (input) for mailman id 1441368; Tue, 06 Oct 2026 10:37:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE2Xj-0004Q1-1L for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:37:07 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xE2Xi-00Hb1P-1D; Tue, 06 Oct 2026 10:37:06 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xE2Xi-00AYEe-0F; Tue, 06 Oct 2026 10:37: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: Message-ID:Date:Subject:Cc:To:From; bh=Fddexj0qF+CV/q7hZq0askrBKEoYQXsJn4bqOqq+0zs=; b=1qdx7cANRdyNj3MwZ7VDqZu/1B INygTAjR4BGhgryHY+YLwJRPEH4Jrju5dWoOX+dsCzsRPsck5/7eN/rbiGweT/6KbHgyXj3Po9R0X 2FtiiNH9do7gFzpWNadxL/Og37HNo1Vaz5RqHMuyHkDhOy8M4FeWz7S2w5ejPuv3uGuY=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/pv: drop the old GDT frames only after their translations are flushed Date: Tue, 6 Oct 2026 11:37:01 +0100 Message-ID: <20261006103702.55276-1-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit pv_set_gdt() tears down the old GDT before installing the new one, and the teardown, pv_destroy_gdt(), puts each old frame's reference before it rewrites the slot's entry; the flush of the slot's translation is left to the hypercall wrappers, after pv_set_gdt() returns. If a put drops the last reference, the frame can be freed and reused while this pCPU's TLB still translates the slot to it. This is safe today only by inspection. The only consumers of a vCPU's GDT slots are descriptor fetches by that vCPU and Xen's trap-handling paths on its behalf, none of which run between the put and the flush; and every other caller of pv_destroy_gdt() acts on a vCPU that no pCPU has loaded, which holds no translations at all. pv_destroy_ldt() is in the same position: it unmaps and puts, and returns whether its callers need to flush, so there too the put precedes the flush, and the arrangement holds only because nothing fetches through the slots in between. Restructure pv_set_gdt() so that the flush sits between the two: take the references on the new frames, install them (and the zero page over the unused slots) over the old mappings, flush if the vCPU is the current one, and only then put the old frames. The flush moves out of do_set_gdt() and compat_set_gdt() to sit next to what it protects. pv_destroy_gdt() is then only reached for vCPUs that are not loaded anywhere, so it asserts that directly (!vcpu_cpu_dirty()), which also covers the lazy switched-out state that a plain v != current test would let through. Like pv_destroy_ldt(), it does no flush of its own and is safe because the mappings it tears down are not live; it unmaps before it puts all the same, so that a flush has its natural place should one ever become necessary there. No change to what guests observe: a slot always holds the old frame, the new frame, or the zero page; there is never an unmapped slot. Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- This is a candidate for backport. This was originally requested to be packaged as a backport-able fix during review of v2 of my version of the ASI series; I've taken a slightly different direction, so posting this separately. --- xen/arch/x86/pv/descriptor-tables.c | 57 +++++++++++++++++++++-------- 1 file changed, 41 insertions(+), 16 deletions(-) diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c index 8a32b9ae5c..7a97ae753c 100644 --- a/xen/arch/x86/pv/descriptor-tables.c +++ b/xen/arch/x86/pv/descriptor-tables.c @@ -54,19 +54,27 @@ void pv_destroy_gdt(struct vcpu *v) l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO); unsigned int i; - ASSERT(v == current || !vcpu_cpu_dirty(v)); + /* + * Only reached for a vCPU that no pCPU has loaded (paused and synced, + * or never run), so no TLB holds a translation of its GDT slots and + * no flush is needed between unmapping and putting the frames. Keep + * that order all the same, so a flush has its place should one ever + * become necessary here. Replacing a running vCPU's own GDT is + * pv_set_gdt()'s job. + */ + ASSERT(!vcpu_cpu_dirty(v)); v->arch.pv.gdt_ents = 0; for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ ) { - mfn_t mfn = l1e_get_mfn(pl1e[i]); - - if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) && - !mfn_eq(mfn, zero_mfn) ) - put_page_and_type(mfn_to_page(mfn)); + l1_pgentry_t l1e = pl1e[i]; l1e_write(&pl1e[i], zero_l1e); v->arch.pv.gdt_frames[i] = 0; + + if ( (l1e_get_flags(l1e) & _PAGE_PRESENT) && + !mfn_eq(l1e_get_mfn(l1e), zero_mfn) ) + put_page_and_type(l1e_get_page(l1e)); } } @@ -75,6 +83,9 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[], { struct domain *d = v->domain; l1_pgentry_t *pl1e; + l1_pgentry_t zero_l1e = l1e_from_mfn(_mfn(virt_to_mfn(zero_page)), + __PAGE_HYPERVISOR_RO); + unsigned long old_frames[ARRAY_SIZE(v->arch.pv.gdt_frames)]; unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512); ASSERT(v == current || !vcpu_cpu_dirty(v)); @@ -92,18 +103,34 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[], goto fail; } - /* Tear down the old GDT. */ - pv_destroy_gdt(v); + /* + * Install the new GDT over the old one, flush, and only then drop the + * old frames: a translation of an old frame must be gone from this + * pCPU's TLB before the reference keeping the frame allocated is put. + * A vCPU that is not current is not loaded on any pCPU (see the + * assertion above), so nothing holds a translation and no flush is + * needed. + */ + memcpy(old_frames, v->arch.pv.gdt_frames, sizeof(old_frames)); - /* Install the new GDT. */ v->arch.pv.gdt_ents = entries; pl1e = pv_gdt_ptes(v); - for ( i = 0; i < nr_frames; i++ ) + for ( i = 0; i < ARRAY_SIZE(v->arch.pv.gdt_frames); i++ ) { - v->arch.pv.gdt_frames[i] = frames[i]; - l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW)); + v->arch.pv.gdt_frames[i] = i < nr_frames ? frames[i] : 0; + l1e_write(&pl1e[i], + i < nr_frames ? l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW) + : zero_l1e); } + if ( v == current ) + flush_tlb_local(); + + /* MFN 0 can never pass get_page_and_type(), so 0 marks unused slots. */ + for ( i = 0; i < ARRAY_SIZE(old_frames); i++ ) + if ( old_frames[i] ) + put_page_and_type(mfn_to_page(_mfn(old_frames[i]))); + return 0; fail: @@ -130,8 +157,7 @@ long do_set_gdt( domain_lock(curr->domain); - if ( (ret = pv_set_gdt(curr, frames, entries)) == 0 ) - flush_tlb_local(); + ret = pv_set_gdt(curr, frames, entries); domain_unlock(curr->domain); @@ -168,8 +194,7 @@ int compat_set_gdt( domain_lock(curr->domain); - if ( (ret = pv_set_gdt(curr, frames, entries)) == 0 ) - flush_tlb_local(); + ret = pv_set_gdt(curr, frames, entries); domain_unlock(curr->domain); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:45:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:45:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441378.1658959 (Exim 4.92) (envelope-from ) id 1xE2fv-0006Vg-HZ; Tue, 06 Oct 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 1441378.1658959; Tue, 06 Oct 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 1xE2fv-0006VZ-Ex; Tue, 06 Oct 2026 10:45:35 +0000 Received: by outflank-mailman (input) for mailman id 1441378; Tue, 06 Oct 2026 10:45:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE2ft-0006VD-MK for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:45:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE2fs-00E4O2-Kv for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:45:32 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4d141-8faa-0a2a0a5109dd-0a2a4509d548-32 for ; Tue, 06 Oct 2026 12:45:32 +0200 Received: from [52.101.53.68] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4d14b-be1a-0a2a45090019-34653544ffbb-3 for ; Tue, 06 Oct 2026 12:45:32 +0200 Received: from BN0PR02CA0013.namprd02.prod.outlook.com (2603:10b6:408:e4::18) by SJ2PR12MB7961.namprd12.prod.outlook.com (2603:10b6:a03:4c0::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 10:45:27 +0000 Received: from BN2PEPF00004FBB.namprd04.prod.outlook.com (2603:10b6:408:e4:cafe::7c) by BN0PR02CA0013.outlook.office365.com (2603:10b6:408:e4::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 6 Oct 2026 10:45:27 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF00004FBB.mail.protection.outlook.com (10.167.243.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 10:45:27 +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; Tue, 6 Oct 2026 05:45:25 -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, 6 Oct 2026 05:45: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=ksItfQmw72TGK3qGgY2kV95i5ykgyWMJRC8YysFotZfKSOYSVdWKzb0jl2bzhxhVHuJ/34lKEW6vZxn4QJUPSiW5zH+gFiRHWSXu9Yt6JFlHkEpV3QTgiBdqIG6XYhBObNgZFtC1CaxCzP7OBRliIw1GsTUCZoCS/5nWqY6G8+eh7fXqcsc4znDEEfm+xWfb1IsQUbrF/d5/3Jd7t44SuP58UITouyPDpgVrlaKl3LtghUyTG2sbHqwDNiVcg5C4ct9faH4qfbSZQYauTifiv4kcG5rgtqrowzpM9LveY/b8UPHuRmB7dVldkCOmqUtiOKvp+moJ8atIyNNhEL19aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O+Gue58WhydqS9oPe9T3U2QhGrFn9zlVd9joxzISyC4=; b=ii74mQ4m/9JcoFemckFpS8ZvGTk0e/ljoB0EXWz4n5nGhmcCk4ZMyBsTzEzN6V5vWl9QcvOoS9q1YlIKUi9+vEMvCBFDHm4cf82+fwswyjsRmiuhzjYvVehqm71gI9QUdOGMFEUwLV+3X/wOFHeOuiC92kSPqI8u9mQBOD0RaJZLmCtvnh0VrKl0+CG+TxqwSyzRaFX7cXxUBe8NRip+sgn9f8uzPH4baTm9BKVAyAw9iJC457t3gZVkES6uYr5SUB6wMnw8J3+G3uQY4Y53XdHNBP5a/tPquMPps+0qTiaNcxsBOkxhxekRObBbYd2ZrVgLyt9EH3tM6nMMKJg5Yw== 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=O+Gue58WhydqS9oPe9T3U2QhGrFn9zlVd9joxzISyC4=; b=JlRiJOJ3+/CncQ0ApMiCwbBbYbcWfKLFH8LdPoXjM5wLOQhLru703WFigw/2TRyaXja6nnkuvtyL/FFwHfd9TTCYSW7h5LrSqsRUWU2TSp06/sNVqziIfmcoA8qGeSO3keLNEpNDsVcQPS0c28uaiMaWeO/DWiv3DcGssHr+Iqs= 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: Tue, 6 Oct 2026 12:45:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm/nospec: Make nospec helpers always_inline To: Alejandro Vallejo , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <20261006103142.139422-1-alejandro.garciavallejo@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261006103142.139422-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF00004FBB:EE_|SJ2PR12MB7961:EE_ X-MS-Office365-Filtering-Correlation-Id: bc2cd641-3510-42ea-8ce2-08df2396eef3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|376014|82310400026|23010399003|1800799024|11063799006|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: slGKS2YXYYoZ3foXviefUdUlrD6Gu/a+ATDOS82P8L5d2Zefe4NmvAJjhOea7ztPGrwIMvGUb1Sat+IMyXgF+367yZk+uk+c9QUpq6nPduqVyR/WcnxYAq8PmYWVqH1fmXNRHf/TnVGQqhKDNHeiXhBmXmp+eUAOVRovqt6qPnZowmiZymCPdHVs6ScJ1CyfZWatc00SYFr13sizsYGVYkeSQ0u/V2d9vakvEFpHD4W/2XLLy9Rg+SnzQ65uueEqXNDOdLmn7JTbBLfTaIGxmGcyWiOeDx20Un1Ad4Wdl0H+58tqcDXK8SnMrNjxrSGWaEt5eBfuurxyfwBqlV2saKN6yX5YTC17ivn5DC65CM3L6IYY9lqCYbEmNZEa1iycIpDpEsZJOtEPfEDMy/jNpXhEhSTFuvkoCB73JaIwBg7yXC0VSKw1pmSPN6LAEqjvDCyv7PAretphRIcyK4hr2651tcE3IkzVdCVgpoYl5HFUHue1gHZahsCPPgLpyRz5Sp/TN2+rkCThEhR9OTgXSXzgE+BIpi1IGIv197k9bpcf/nz9zEQpmWH6NAu8okX8JEluiWnAp3QEjR9zX0I8J+qHTlezo00c6CA5QBAJuOr62BOC7QZAHWXDbp5ZHAVh/jvDWISjNoqjH031jxFN1Ioci4sQJsze8XXVmCsUW/nNN6adGi5+2NRH25I8DnsfiQIzu3pUaUtuz5WQtLPcSw== 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)(376014)(82310400026)(23010399003)(1800799024)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 9Po0CTlQ7ORqPnfGaGsNjs7yACZFmJ/aS3SngatqnNaLFxJnqcTWD5QeubzoVpF6ARaBWFyMWZlAXgq/yTb1PVrN+Lc97SSGrcXhkzP/gkw3OUMXQo+S2U0vdGUhX6qLEdxRaJPx2JP4EJwxRyt/S4IGZaEEMVDo3OI4HkYOLoHhEV2wnraDYvWDZ7A3KFpc3A3Ly7wuJBrsSo7KP91ARg+ix8Rpbe0OHvb+vlSEkcw/AnApd0MLhJQ86GHvEFFW2m6/CcoGL1e2PKD7r2xvzAi2DGKbae2SMn+B6atElxWxnaGClXySppbpEXJR/B0z0pa8s1qpPiB//gZyERDTzFGVHXWjsN5dPMVzHL1TnrSwMFq5AJzdHoxqGFIiihFlpsWPVTv8KUjUWSYTtkxJR0RRRVeD+iHovdcj3WL6ko0wRzMNW5g/EhWa7vG78Xvj X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 10:45:27.0438 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bc2cd641-3510-42ea-8ce2-08df2396eef3 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: BN2PEPF00004FBB.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7961 X-purgate-ID: tlsNG-bad1c0/1791283532-FC817034-A40E5320/0/0 X-purgate-type: clean X-purgate-size: 497 On 06-Oct-26 12:31, Alejandro Vallejo wrote: > While today they don't implement fencing in a way that would block > speculation, once/if they do they'll absolutely need to be inlined, even > if -fno-inline or -fno-early-inlining are passed. > > Signed-off-by: Alejandro Vallejo Reviewed-by: Michal Orzel but this should be done for Arm, RISCV and PPC at once in which case you can keep my tag for v2 # for Arm. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:51:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:51:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441387.1658969 (Exim 4.92) (envelope-from ) id 1xE2lf-0008Vi-7b; Tue, 06 Oct 2026 10:51:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441387.1658969; Tue, 06 Oct 2026 10:51: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 1xE2lf-0008Vb-4q; Tue, 06 Oct 2026 10:51:31 +0000 Received: by outflank-mailman (input) for mailman id 1441387; Tue, 06 Oct 2026 10:51:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE2le-0008VV-LC for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:51:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE2le-00GI5k-1i for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:51:30 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4d2b1-bab6-0a2a0a5309dd-0a2a450ab894-4 for ; Tue, 06 Oct 2026 12:51:29 +0200 Received: from [52.101.43.69] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4d2af-f2d2-0a2a450a0019-34652b454cb2-3 for ; Tue, 06 Oct 2026 12:51:29 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV8PR03MB447892.namprd03.prod.outlook.com (2603:10b6:408:3d3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Tue, 6 Oct 2026 10:51:25 +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.0472.020; Tue, 6 Oct 2026 10:51: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=Jt/chI7Xiq788PcGimyU3Vt8CNk+ZxMfTk9GVjHDxCv0kUKAiVA9hKZD9MMzs2Ory1vyZwJ5r+2eD+VRWrRon7qXY8wBbbIPE5foyI1lu1rzqlqwqtD9LKKMHlvJxp7FVEr6McFprvWTl1SpG/jvaKiYWC0HLucyGDp+/E5CK1p1vf2ioLydt95tFwMcnG0bJtcSQBJbTXBoTHFf/2RPinQ6nLrDFUJ1eZOWVoTYi/n0rJ1ekJ6RnLfBLzYj1oxPOcRfVo7oBMSVZvqMzLBameLTwN6/v2RSNju4839okB3wn1k7EQuEaJmyH5vuW3b84IYDmiV75JD4tTcX9JRmDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0dWqNSma8FZJKABlRBBfTjCLx5mnlYL8ohScDbOQCio=; b=A/jOZAXSmnoghDuGcSSTcEmE3tNJQrP9CYb1vMsANqTUleLJFzHx3MPH7M19tLsa4MeMAwD/v2FVRdu7nyQkX3OBoO+AuFV+XzKl2SU0SY3Xv0lNjBRipaTCyV5Pjok9T+NWZ3Ll0Zn7RlVn4Xm/ccO6wnvzuWEUHFzQLgMFPNrA6ZkbxCRGKSHcniuhm3zyBKppEkdle0RNhDqypzHPwGTRRNQPEH4HSaG0iBLe4MA/aSvN4E0CA6EdnTg+aF2R9hiQuQqv6FKwLHkovLSt1TZy9D/0dn9x+RYf9wIDqpTSXYag/B2sQ+3HA1KwFQHlb0gaA5eHghRO5+qasXAtjg== 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=0dWqNSma8FZJKABlRBBfTjCLx5mnlYL8ohScDbOQCio=; b=lHsjMbqBaSsZhU02PzqH2UP8V5mY4ksrVeA7Ak+EXp+yKEeqZkhpYKbhhrzZlq+N9ceKN5xBKDPW0Jmg7Ofi/KCCefaKURAuPa6yu98LgP3yZQflhc/7CcEe8+XDX5Xdt58lwsYRz4xoWQeXzGBrdbWjhQprPJvebfZANo0MPcY= 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: Tue, 6 Oct 2026 11:51:21 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH] arm/nospec: Make nospec helpers always_inline To: "Orzel, Michal" , Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20261006103142.139422-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P123CA0026.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:313::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_|LV8PR03MB447892:EE_ X-MS-Office365-Filtering-Correlation-Id: b0acc403-7f63-4fc0-43a2-08df2397c445 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|11063799006|4143699003|10067099003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Kn0an8mVWgKrbyGXaB/gHIsJGdAhPUPhGTubG7UrfMx+93WxBj2bxq50vGdRH5lzJbIL+myLOSXUqK2ZVC8Q1CJJKSD5c8EzYLJFFT9QSyvuH1ONJyu8Hrc53YZlybZruT0kqed4r3xR0gXq4DLjnqU8a9ycAry3AoBUBOYbzwX7kba6UgPnK8rp6cJe+DtDe+6CWwJnIyV7Cl7ZjK2vSDitq1pDUT26Lnd8EvhSmWfES6BjOZo9m21UX3lsd9Z/Eb4l+Y8ybu9UJZJqkajZAxV1Gtnh9wN2UWkVr6wbZWFGtbGRKCiTGGbQaDeKT/zyj/H4yncDs2vWOzDgrfKiai0bLR24QGZxKYH1brmXt6UUiC7WdkK6CZnYsV9L7S3+Pp+zvyj/8WrczAi5IBwTN5sLwyxKdUnbEvg03PC3hR0gRkRkJrLypZLK1IF9erLJ1UKUICokYHjfzOCXKVRpKty89qubJMeXjMyGYWYBh51j4MkXszziRBUKigrKISHFadlguNjDg0XJM0TbKeMQPslCYff9lBQklBhq1XMnzeWD+A7WcFYWrsp7zcNAAdP8Q0L+5Q0sqTvAxG3p0CfCteQR4UEcQlpSgGvms+IsC6Xuj1OT2i9GVmFQC2QtVvSdvCz0rMAdQiwAe3PDlWNP59rRkGPjJdrREfx3ExZt2HI= 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)(11063799006)(4143699003)(10067099003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T1dOUXFpRFM0U0ptZkRScDVPTnQzQzJHUDExWGJNMVY0WGk5SHAyanhicEFS?= =?utf-8?B?Rm9XNmZqZmVyVGczdElmb0x5ck9zYTVQaDZTRWdaZnF2Q2RadE1yVlh6TzF3?= =?utf-8?B?TnpDM0dMaDJVNzZHQm5CdGJJRGltaklKQ0tUY0Yvby9iOUluVGQrcWFVK1l6?= =?utf-8?B?a1BUTTBsV2ZMU0dSS2F6a3VwTDA1ZWx1d2pBK2kwWVpqYlpqVHZaU3JkTGFC?= =?utf-8?B?YjJlOGhKV2lJaUxwT1MrYy9BOTdUa0VZb29YeG5QR2tVYzRnWFJLWDR3YlBj?= =?utf-8?B?Um0ydlNJNWVoK0RTbjdRSmJhbUpJK2JrWEhxN0tHd0dySVhhaSt5aWFvN2k5?= =?utf-8?B?YjFSam45UmhLdGpQTHBibGZkYW9LS3Y4YWRMOVA5QzYrblBVRWM2dkt5UVlH?= =?utf-8?B?Q2toUHB4dm00NkEvVGZYSFJUK0VCR1pmbmJyZjRhaitBK3RwUnpNc3Jhb1Z3?= =?utf-8?B?ZXg4ZTdhV29hUVA4Q3daSUU3TmRjTlZ6Q0ZvWTNxc0p2RnRZcWRTU1grQ3lC?= =?utf-8?B?ZVJldVRuZEQ2OWQ4T21lVkkxdnRyaWdnUFQrVTNjU3BUUFVwL1RPS0Zac29X?= =?utf-8?B?TE5CNDNyOUlEWW9UMU92OFRuRFBsbmthKzhsVnYraElsK1d5YkUyMUpzSnB0?= =?utf-8?B?OU5DU0tsTmhmMGRaaXVpWC9NSGtYNEQ5ZGl0U3ovN2J4REtMZmozejB1b1VK?= =?utf-8?B?M1lrY2s4NzRML0RLcDFaV1I0SEFrZHQ3SExHTjRSVmdFa0s3eW8xOXlEQStT?= =?utf-8?B?Zk5pSXhpejM2WUtLZzVTdldNV3JoR29PU05MdDNCTFZSWXhMcEI1NXU5TXBo?= =?utf-8?B?RlJOVnZVMkNHcGRmdWxsRHgvUXI4WWhEdi9HV0JmWE5RNlRVdDhPNEUwRSs4?= =?utf-8?B?UFF3RTNjK0lTQkZmTm1pdTV0dGtQeFA3bmJrcnY0dmwyYVBSVG04Rk10Y1Rt?= =?utf-8?B?YXUydGdIN2c3ZlR0U3pIVmo4RkVrRlcybWk3aHVKbms1WC80Uk5hQjFRVjdn?= =?utf-8?B?SnordEpuQUlocWJLUE1KalRpU1hvZmh0MkFWSVRZRzBvOEx3WEwyekRoNEpV?= =?utf-8?B?bGNiSTNLSWl0UmxTWUdycXlRdGNIUDY0NWY4OFBKWkpSdUNtanJjclR1NEJ6?= =?utf-8?B?WTFYa1pGTmlJa1drVVFqU2d6Kzgxa0tXMHdBQzF1Y3VlNkxYWVVSbVo5M0Nv?= =?utf-8?B?TkFndjh4eWpvRng3UVZjVDRsYUVPM0tTbGU2ckcrUGlYNDZXQWlIQUxwUlpN?= =?utf-8?B?NUhRWmpjSC9yL1VNNSttNWlKZ0N3VlAxYXR6cHN6bzZpbTZaMm5oSVdhbUdv?= =?utf-8?B?aEUzWlFQRG5NVnNJeXdXV2F4eXR3bThDSGdxMUVkU2RSWFI1N1I0Z21TNG8x?= =?utf-8?B?WUxORlFzbXFwVW5pTzVnazViWC9MV0Y1N1JKTFd4VDVSRjFKdmxIZ3Y3MDRy?= =?utf-8?B?VVJjRndiaG9nTnd5Q0hUQ25wWUloTkRlanYxbUFMVEZPY1E2b0ZGREwrSWJI?= =?utf-8?B?N1RNVk03UTh4aXpjY0ZzMktQb1dhUDlwNC9wYzFXbXk3UDhxdDI0N3lkcTMw?= =?utf-8?B?QytHQm1UQTdjaHFPQ2QrdjBqSFJ2Yy9sNXNSdDk5aTgxenRVeHdpUnlpNXhy?= =?utf-8?B?TmxIKzlPRzVUNmVLbnhKSENNbXZwZzV6dnROOEJwME1jMisrK2x1S25sNzU1?= =?utf-8?B?d2tod3B0ZWs2WS9ES0ltcWw1cnkxa1dWVWJaTFQreG9iZCtNSzJsOUdWWXlm?= =?utf-8?B?UFkyV2pIZFF4SmVndGY5d2kwMEFjZHJmOXhKbHlBQ3BmWkZKdGpyVWFqdGVC?= =?utf-8?B?ODdtSXptQVpSUGZmdDJVNmhia3hldTAvcXRzeE9OS05PV1l0VTVyOUhuazNj?= =?utf-8?B?RGoxUEpUYWIrSUord1ErRk1QYVIxRW1sdFAvcGxCUVUxRjA1VzFjU1RtNWo0?= =?utf-8?B?M2JBajZIelVNa2Qya0IxUERrYTFXQ0JBSTlPM1BQSkRMbnVVSVVDWXV5NnBF?= =?utf-8?B?SzZPTHBEWjhBdWVucnAwZ2JKK1h5WW5PYWZSWGs0SVZDaWZkcExQS0FhbjM4?= =?utf-8?B?MGQ3SS9ZMXlCd05pbG1MbDdJM2NEMkJRVFJ4Y2ZNNzNlUlNtcTA5bnpiakJQ?= =?utf-8?B?Nnh4NXFRNmpjYjhsZXRJNS8rNzNsVEJMYmpaWkI1OCtTWFJYaHRoWXE0b0p4?= =?utf-8?B?ZVJJdnk2WWNaeDZ6ZElwTGNxb2lpRWs0SXNjTjFOY0JwV3RyM1R5K0FhRkZz?= =?utf-8?B?Qkw0cTZTdmNmZUIrVG9rMkJHTjFaemhqV3p3VGtaQVpLMmxJNWZodjl4akll?= =?utf-8?B?am1hMWVPdVZUNERxQ1kvZjhLeDVjVmlXZ3VYRFhtQUJmdWhDZFdYQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0acc403-7f63-4fc0-43a2-08df2397c445 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 10:51:25.1927 (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: Y29CTK/VEx8+gQXyzQsVIGgxgCprefZODdxSYB8z1wfO0d9y59wqw82wvQuaw5gXzrMN7T46mSTBUxbmG6FP+eKRqUX+7Q1sWdX6v8KhR3Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB447892 X-purgate-ID: tlsNG-4011c0/1791283889-587CACFC-88AE1868/0/0 X-purgate-type: clean X-purgate-size: 745 On 06/10/2026 11:45 am, Orzel, Michal wrote: > > On 06-Oct-26 12:31, Alejandro Vallejo wrote: >> While today they don't implement fencing in a way that would block >> speculation, once/if they do they'll absolutely need to be inlined, even >> if -fno-inline or -fno-early-inlining are passed. >> >> Signed-off-by: Alejandro Vallejo > Reviewed-by: Michal Orzel > > but this should be done for Arm, RISCV and PPC at once in which case you can > keep my tag for v2 # for Arm. I previously had a patch series which made this all common, for these kinds of reasons. I think I'd prefer to kick that over the line, than to keep on taking micro-bugfixes like this. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Oct 06 10:54:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 10:54:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441393.1658978 (Exim 4.92) (envelope-from ) id 1xE2os-0000fq-Ls; Tue, 06 Oct 2026 10:54:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441393.1658978; Tue, 06 Oct 2026 10:54: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 1xE2os-0000fj-I9; Tue, 06 Oct 2026 10:54:50 +0000 Received: by outflank-mailman (input) for mailman id 1441393; Tue, 06 Oct 2026 10:54:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE2or-0000fd-MA for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 10:54:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE2oq-00E64q-Vd for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:54:48 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4d371-bab6-0a2a0a5309dd-0a2a450699c8-30 for ; Tue, 06 Oct 2026 12:54:48 +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 6ac4d378-195a-0a2a45060019-d1558031b8cc-3 for ; Tue, 06 Oct 2026 12:54:48 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a16c399641so6193775e9.2 for ; Tue, 06 Oct 2026 03:54: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 5b1f17b1804b1-4a178c5df75sm55568145e9.15.2026.10.06.03.54.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 03:54: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=1791284088; x=1791888888; 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=JIkl9Uhf46HX5xVgAjNfSAx5apL+1t1WrMzeTv2NZDE=; b=JSRfHGqqgkH5VF73L2BtF/ZoG6A58uDjhfp5OIWSlwlJntfXId4aXklfMKSvwrxHwz JIZyJ73k9+HCroJh7ZNgQ7yw0YjXumGvvGG/dHgrlx3jeVW3JWk/HlQymtprrEAR5LsE mGsDTSNWo+T5U+WnAS0l8L+CX3UcgfAXWu2ZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791284088; x=1791888888; 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=JIkl9Uhf46HX5xVgAjNfSAx5apL+1t1WrMzeTv2NZDE=; b=RF9F30tA+hs7wXCrhSvro7CHUEp1yJbJ+TmelgpD2QQ80uqdv7MJYdkbRXy3EVPoTE RoFBW4VAq0kP4RnCjpNUk+hZ6dEKxMROIrttt2uJA7UhllUKBLvlJb3wgXG7OqSOFQ4H +97ZKp++nTp29VA9PRHBFLbkexZDIFf0fkAweE84Q2tu/dFm/MTbGYCxxjZnMZfmT6mN F/cZelcTV8KtxHoJfTbJL+0fkQ4aFVsHLjJYCEFmvIJfgqhCjxKaoU4uNELJQeN+Z/rg HvWT6IxayqDp7B2MNDt6cCDfvt9ET1YNS1GsaGbKQN2EIjAvFPA82y25eyihxbXTZ7+/ FlZA== X-Gm-Message-State: AFuF++nnmvKHFB/2WD2a19NTixjMYAcCJiBewHmhCoCRtw8GqmfnD0Yy 4cvWmbPXfyI/u2q37JJSk70VGLS7UIimW31rD1ZqDZ/53uP4WSAw6RUIKHq5e3ooO4mdq6kLQLL Xq4WYYBk= X-Gm-Gg: AYBFou1xMbdC1aTKseYwOooZIGdKS8m+DIPMAFydIcdeZ7DrjywTefQMEcHSh+im3NE 5G8fq54NNJObEGuwrPvczuz9ergcUUAp5qFjn4lrrGEmtCEuGZha5jsrIBKukXSRGt1zKJy55FB 8UH321382edicaKUXy+Mo4j3EFaqb1SYpRby8QdX3+yNyZYplZTP+SVWrKXgsjvbQJzgcw2Be8k mueG83V1pLSZqz9x8nAEupz5W0u0Mc2OXGfIkE/Dkm64u76pZE1PPsRFNlaja9+m1aEqpza51EV TV+XDHQEVS37r4o0u5sa7fOW3mo/kIgcGPFhFy2TDysnZWdxWUOoWtDDzwjjIXWBLMZdXUO4BV3 ylsM+lsfSQXJcyHCyNk1A455kz55sDEFPIrCcj4+gFd4aafxUTtI+sgQi9G8anTsiID+Ti2qMDY WhTKIlRoKMOHXFWqauLo61aMKjnOljI5LS6N/6ZdVSeMvV/qFgG4pHD3IGvC8i5oO9407BF9+xS OTNc1sBeY8zHhlTAbe7Umid+/ms0DbPg9tqMmlIwOPOwxfw X-Received: by 2002:a05:600c:4fc2:b0:4a1:70da:3350 with SMTP id 5b1f17b1804b1-4a17b555cb7mr16939935e9.32.1791284088051; Tue, 06 Oct 2026 03:54:48 -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/kexec: Annotate more noreturns Date: Tue, 6 Oct 2026 11:54:45 +0100 Message-Id: <20261006105445.511099-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-16d1c6/1791284088-F5E0E77B-F26F6570/10/78276251493 X-purgate-type: spam X-purgate-size: 3227 kexec_reloc() does not return. Plumbing this property upwards lets us mark machine_kexec() and machine_reboot_kexec() noreturn too. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie Rebase forward many years. --- xen/arch/x86/include/asm/machine_kexec.h | 7 ++++--- xen/arch/x86/machine_kexec.c | 5 ++--- xen/common/kexec.c | 2 -- xen/include/xen/kexec.h | 2 +- 4 files changed, 7 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/include/asm/machine_kexec.h b/xen/arch/x86/include/asm/machine_kexec.h index 3e189acf2464..f0bdc2f44109 100644 --- a/xen/arch/x86/include/asm/machine_kexec.h +++ b/xen/arch/x86/include/asm/machine_kexec.h @@ -4,10 +4,11 @@ #define KEXEC_RELOC_FLAG_COMPAT 0x1 /* 32-bit image */ #ifndef __ASSEMBLER__ +#include -extern void kexec_reloc(unsigned long reloc_code, unsigned long reloc_pt, - unsigned long ind_maddr, unsigned long entry_maddr, - unsigned long flags); +extern void noreturn kexec_reloc( + unsigned long reloc_code, unsigned long reloc_pt, unsigned long ind_maddr, + unsigned long entry_maddr, unsigned long flags); extern const char kexec_reloc_end[]; diff --git a/xen/arch/x86/machine_kexec.c b/xen/arch/x86/machine_kexec.c index 038670922d47..0fb9ed50e780 100644 --- a/xen/arch/x86/machine_kexec.c +++ b/xen/arch/x86/machine_kexec.c @@ -142,15 +142,14 @@ void machine_kexec_unload(struct kexec_image *image) /* no-op. kimage_free() frees all control pages. */ } -void machine_reboot_kexec(struct kexec_image *image) +void noreturn machine_reboot_kexec(struct kexec_image *image) { BUG_ON(smp_processor_id() != 0); smp_send_stop(); machine_kexec(image); - BUG(); } -void machine_kexec(struct kexec_image *image) +void noreturn machine_kexec(struct kexec_image *image) { int i; unsigned long reloc_flags = 0; diff --git a/xen/common/kexec.c b/xen/common/kexec.c index 8ccaef1e0258..da3bb95d0852 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -397,8 +397,6 @@ void kexec_crash(enum crash_reason reason) kexec_crash_save_cpu(); machine_crash_shutdown(); machine_kexec(kexec_image[KEXEC_IMAGE_CRASH_BASE + pos]); - - BUG(); } static long noreturn cf_check kexec_reboot(void *_image) diff --git a/xen/include/xen/kexec.h b/xen/include/xen/kexec.h index e0d793b04316..6bb3fde629a6 100644 --- a/xen/include/xen/kexec.h +++ b/xen/include/xen/kexec.h @@ -49,7 +49,7 @@ int machine_kexec_load(struct kexec_image *image); void machine_kexec_unload(struct kexec_image *image); void machine_kexec_reserved(xen_kexec_reserve_t *reservation); void noreturn machine_reboot_kexec(struct kexec_image *image); -void machine_kexec(struct kexec_image *image); +void noreturn machine_kexec(struct kexec_image *image); void kexec_crash(enum crash_reason reason); void kexec_crash_save_cpu(void); struct crash_xen_info *kexec_crash_save_info(void); -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 11:13:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 11:13:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441411.1659010 (Exim 4.92) (envelope-from ) id 1xE36u-0004ZO-BZ; Tue, 06 Oct 2026 11:13:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441411.1659010; Tue, 06 Oct 2026 11: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 1xE36u-0004ZH-8v; Tue, 06 Oct 2026 11:13:28 +0000 Received: by outflank-mailman (input) for mailman id 1441411; Tue, 06 Oct 2026 11:13:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE36s-0004ZB-Jk for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 11:13:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE36r-005lHH-DT for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:13:25 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4d7d4-8faa-0a2a0a5109dd-0a2a45068f3c-4 for ; Tue, 06 Oct 2026 13:13:25 +0200 Received: from [52.101.48.41] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4d7d3-195a-0a2a45060019-34653029ce92-3 for ; Tue, 06 Oct 2026 13:13:24 +0200 Received: from BN0PR04CA0167.namprd04.prod.outlook.com (2603:10b6:408:eb::22) by CH3PR12MB9195.namprd12.prod.outlook.com (2603:10b6:610:1a3::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Tue, 6 Oct 2026 11:13:18 +0000 Received: from BL6PEPF0006C3DE.namprd02.prod.outlook.com (2603:10b6:408:eb:cafe::46) by BN0PR04CA0167.outlook.office365.com (2603:10b6:408:eb::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.21 via Frontend Transport; Tue, 6 Oct 2026 11:13:18 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL6PEPF0006C3DE.mail.protection.outlook.com (10.167.249.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 11:13:18 +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, 6 Oct 2026 06:13: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.49; Tue, 6 Oct 2026 06:13: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.49 via Frontend Transport; Tue, 6 Oct 2026 06:13: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=AMbRYF7qoG90OmTvTIZXaSqWuRTaP/UGTMzFdWP+58wMH2G3JtEcxUKICbnu8qf4qSQNtcpq25SsMLtzfB3rvoStU78jYnBGdei2KeFc0w0PnA/6U86icY+ai7/TsAFoT1pDmw+BMpQ7UB5IetErANKXC5DbCoiHxvDmzUGm+eNEQtOeTGJ7m/+DCeCPeNP1zrIqSx2TwMJjYrDYNcum7KJXGN2OT/F7PFF20g9lmiy2LibevzbInqZE1n3KDPdASpUDkX9GsZMYlNvIaono3gSlBAsRIffA5Ybqp/co4zFKOt7/J1DewEp18wMqrGehjdMqDsFzVe7cV4mOh2neuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NKmu5PKnjodKGkcEl00POImHpnu655yNZv7H13pskz4=; b=VxFWeBQxCvMRd+K4y4xL5mJOlhX4GhURbyzzcva/74I8QLCjpL++MJluD9MhHxWyu3ubSC2d2AwpERwlp1yyJ7mrW6wCk6Lj2oowkwrORC33b9AAYWYHeRbYoreDTf9THTirhB/vu3rHAbb31nrdp75SpNM3voI/tmue0ck4YonLBt63zlFLGNRCvUyMToGjP16U8kDyTzQDybUCQV/hai3RYZNQjT950zUMrFqP3hSpdbhB5fmHyV0fdZEkb6uKsmTz18JO4NXmvUfEdD7y/HqMh8RU9m/W76LOqzFcqSNmav12fAzyd8ymojwtNgmGAduRBsoGPzdPoHUt8O8VMw== 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=NKmu5PKnjodKGkcEl00POImHpnu655yNZv7H13pskz4=; b=Nh/IowYV2CyOvzV/vJ4ub5QkReza7QhQKCKcjWeQ8OEMPOgcUHOBVQOAQCqUTZvF1MSg2zRrB1TItCJlFdcRgjCZDFNYQ/g9hoxIfF0SwaNfVbh2z0jGEhMw4yR4NC5CQxPvOKwriu82tRMa1Yn4vFABLowiI4CNXYwiN/N1m/w= 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: <6f02b2d3-5a6d-4fa6-b74f-9d32cf1ec70d@amd.com> Date: Tue, 6 Oct 2026 13:13:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 3/5] 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: <1790597845.8631fc262581453bbf619ec5b2062170.1a0e7f2cff3000b504@vates.tech> <1790598010.8631fc262581453bbf619ec5b2062170.1a0e7f5564e000b504@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1790598010.8631fc262581453bbf619ec5b2062170.1a0e7f5564e000b504@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0006C3DE:EE_|CH3PR12MB9195:EE_ X-MS-Office365-Filtering-Correlation-Id: eb279a40-3b43-4b43-b5eb-08df239ad30f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|82310400026|36860700016|1800799024|7416014|376014|10067099003|56012099006|4143699003|11063799006|5023799004|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: qIQotguJGshOQRKG109IQhET/3a8pylhGe9ZRJDTORT4/2VmYX+T0hchKmjr/9T4HgMMStTWEFhAG6/iV0aDabAi8LeS6TVCx8MWb4gfZ4VnKZ8gVwR9SYyTAQ544YLm80NSle+qWNGMWfxd8//uspK1NCQT/UxJeIDtqf4/64ytjp/tuR/USqSpN8gosSWFBEnvUnnyk/Z3PgBSJlkfVBcl0nSswe/QRMvMX+5K1np1YkHjvzwTjl7fENEzxrcQZP3SWQlqNuED2N7ghyTvdVHlZFkEEnK/0wve+E1v00sy8LmlLQc3/TBiUXJ9tz1mKJ9kgVJIri1rMgdsA7he/1teqc6Fa3z4apSzYw62qRKgFn0uggmZfAZdwDAvdWektnEihtQZIAzc+ARuQJWkKPNaVR7rv7j3xqLn/vvyy7obMWCrUlX8U6HkqJwSJbtd0Yw4LY8oA/R724AyDyu2lucaQknjqp/D5Wr3kwtE8UAN17LOgsiH6EPkfoBqvOJ4sE9B9Dljxpq+6vF8j/gcnAKEafSpCTxhuUdIrw/r2WR9C2jH958l+fPCeW5B3mNmkFDJDrAPDYXb4c+nVqH9my2IOAqhmXt4QI3HVaFJzZY3O9A29jzj7s/PGhFiL81hH/qfJ7sndNf84DafIgyw5sVzjpzX8hPQY6NY+O9c8u93hRc4PjQ/u/XNWpRjiCAW7LWv22EZvYkz+m7kGxrn3g== 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)(82310400026)(36860700016)(1800799024)(7416014)(376014)(10067099003)(56012099006)(4143699003)(11063799006)(5023799004)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: nJrEie3cq464RH64NicsqCzE6b8e+YqSaP1ZyEOQSfSp+dUoABOtiKhHpXu3mTNjrD8Y90nPfhUzuNMf2LKDFj+fLPkhe9Xf1PE8MvFFGXqNWP/0fG32t8nqOSWIDXG0JJY8rQsILBnaXs3KIpvLJ8kV71Wbo3yZouLVdu3gQgxEYK9eV4rJlLiIlemVAZNMMqNVFEuQ9/18iF0HjVOqsObKQXYsZhvaGYd4kZFQA12+qwHva3kEQpFFBjB4xsmrPrBuGWcwfFI7it5Q7mivscASaTLpw/aEjs66lJ8nYoYuYTwkCRirYgvjbLoMwhh7SIjpI/8nEuUcI4FrY50//0qxj01mjtow+Y1HooAzgAuI73qY7Rh+TIoJHqFu7MAvxyXSzlb85+YUzOsVXBrd63q4NoJLY6bX02UlX2cXLL6OkjzlJWTh1GAyt+Gvnp56 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 11:13:18.2424 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: eb279a40-3b43-4b43-b5eb-08df239ad30f 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: BL6PEPF0006C3DE.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9195 X-purgate-ID: tlsNG-16d1c6/1791285205-F460277B-348369A8/0/0 X-purgate-type: clean X-purgate-size: 1496 On 28-Sep-26 14:19, 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 Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 06 11:21:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 11:21:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441421.1659020 (Exim 4.92) (envelope-from ) id 1xE3EE-0006OF-4p; Tue, 06 Oct 2026 11:21:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441421.1659020; Tue, 06 Oct 2026 11:21: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 1xE3EE-0006O8-1r; Tue, 06 Oct 2026 11:21:02 +0000 Received: by outflank-mailman (input) for mailman id 1441421; Tue, 06 Oct 2026 11:21:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE3EC-0006O2-5Q for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 11:21:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE3EA-00AGxz-Td for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:20:58 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4d98d-bab6-0a2a0a5309dd-0a2a45099836-40 for ; Tue, 06 Oct 2026 13:20:58 +0200 Received: from [40.93.194.45] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4d998-be1a-0a2a45090019-285dc22d66b3-3 for ; Tue, 06 Oct 2026 13:20:58 +0200 Received: from SJ0PR03CA0126.namprd03.prod.outlook.com (2603:10b6:a03:33c::11) by IA4PR12MB9809.namprd12.prod.outlook.com (2603:10b6:208:54f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Tue, 6 Oct 2026 11:20:52 +0000 Received: from SJ1PEPF000037A6.namprd04.prod.outlook.com (2603:10b6:a03:33c:cafe::7f) by SJ0PR03CA0126.outlook.office365.com (2603:10b6:a03:33c::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.14 via Frontend Transport; Tue, 6 Oct 2026 11:20:52 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ1PEPF000037A6.mail.protection.outlook.com (10.167.244.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 11:20:51 +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, 6 Oct 2026 06:20:50 -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, 6 Oct 2026 06:20:50 -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, 6 Oct 2026 06:20: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=NCxKSE7s3LHDhN6n709tffizEHNJ1h3F5eaGRuSFsqskT1ACgier6wDxlQ/Zo/QZNIrmJ1E+ZWzU/n1vYxpEuGuGQN30cEp2oSCWNEpPv0aIztunfUDQmgBpNQbj7Tsp80qcL5AK5uGhqwCMTvH0V13OVu4WSldQ4CBmj0UPnHzjlNrUxc/ic5/ixqzjMc47AKkZzXhwil2Rh1SqvbYMBOi8MmuEm8gzx6WxELvGSIbSk4FChSJzqlQObWxNdIuJxS5tfhL4mrZjz4Sh8u3llv+NGHhxv9xG/XZplUPrc+TMTtwmMUgYi1v26HkbnpS9ev67z9c1B/TPUvGrCj9Ijw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ARhi/DKp03clPOoGAW6gfbn4YX8ymk8xB5K86K7+Xik=; b=A4qOZ7CItDQrAE5I5cGIzDKGbeqECnHhzQ6easeIyZhtLG2OYYPyNFE7ACGt6al1HzGLpdNNpkKe9fcRzNQG+HrmE09Y9vvF5Q7uusrR1op4Oq3+DeQWhnRF0BuRWRcLxRQbmwPXf+pOvOvFMgjvvC9GYmTztqgy7zxDRsvUbtKkb6KDVK0IgesJ9hpys00n0vAYySzP7eyO7G0W+CgB2D1ljsIQ6SWYCXkWVbvFm4NSS4qkXfJxZTm5h3b9L/rNuqd+3dcg7J8QcazJqm4J1oQtC3qT5TCF0zDe7lpJaIEG2d+hKsFSsKPCMCkqnv1PQSzRGqh7u5aGMZEnXzfrsw== 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=ARhi/DKp03clPOoGAW6gfbn4YX8ymk8xB5K86K7+Xik=; b=cIhMxBL9y2ahNKJoiMrSB1wMUdaxsdn9M54eFREkd2aXPbi788aFJOo2j/6Wuntr3iGYdigU8wjNJJzKgh/7f+sve9uorJBQQmnbkgRsuBCpbKucyROsA2pm1rJZkYdUQeHxnMX+gtvxQqxxxbMTLXzqvrEM2whayL6OI0HV520= 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: Tue, 6 Oct 2026 13:20:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/5] 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: <1790597845.8631fc262581453bbf619ec5b2062170.1a0e7f2cff3000b504@vates.tech> <1790598010.8631fc262581453bbf619ec5b2062170.1a0e7f55818000b504@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1790598010.8631fc262581453bbf619ec5b2062170.1a0e7f55818000b504@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000037A6:EE_|IA4PR12MB9809:EE_ X-MS-Office365-Filtering-Correlation-Id: 618c252e-d683-41e2-9995-08df239be16b 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|5023799004|11063799006|4143699003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: iL1s4VpC5SBy1dm2jAyloEnRK6qOxT85YIKAlJR6Msqr8vC9/3CVa6+XO5hyC2OfOOBgtgnSG7Xx7MrvX3vxz/6RC2dW9DmL/LP8VHwmDOZhwldFUKMoi1W9I8VS0j6ReQdeYNHDiYpi4YyqNzbui1jdK8RBOOUPBYFRsMB2NMHLIh/zwgw1KzraKRJvMNC3DwlXznKNqCYXpsookksZwNa7UJ0HaYGrJA/mkO8y/yfT6F1Bx4+HuFbDaKT4Y4jw6gPBsgM/PZXzLrGnYXKqHnahXDOuWTwU7xi0VY66v/tykKiJ65Rj9ALbsKVJdEkgkSjFd9lNDhUU+fnk7dpZRnPI3RadD2OUcAfE9KwzNgEpb1ENEOR4L+0yZpKcQWSVAwBQn0kiG4rDe2mpz3QVEnUlyj1AnB+hNOeKMcMDg69+pgQOdwvKl8SXfUrkaVz2h9tTb4uxYOc+phzllMyjP5bW6caYH3aM/Ng9cBrYBpuK7F5q/iRdKqWIZvMGBkJAL4Jr7nYgV+4XEVOGrgjfJfdGBt5F8NAtxdzLUL4Ba1yunLNkZg5Kb/sDPFIG/biNSZM8F+fkHltBqvrxviK7jXqq3yi/rVenwrzP/iCQlbjOo4+iYDSb+fB+2bJjDc+H6salST1ndAUw5KtSwAsIMdWMPnYZABH8iRR5JesHsjnGbcMt3j3PE3DY9NUk+ZYo8/uaH5tg6Jz5K4v3S+aYqQ== 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)(1800799024)(23010399003)(7416014)(376014)(82310400026)(56012099006)(5023799004)(11063799006)(4143699003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 2MwrNIAo2NNuXatzNOLnU8y8pFkQRv+shhBF/WwgnhqNvOyFlP5OGTBV42LsO+Mx7NHGlLrD/RHOcCHNumttjRe0MgS6Qa3/4FWm56uYBpUsGa/7CaJpO+F8ZSBLjG2BdEj//9vDE2iTilqR69OFWepe0AsuHqbUx9FmR8coAb9QhAbCtkQjlDxAIdiqjOHLeAgxc7KwxDv1D5+2YUUQN3nRY6xRK5wgSrkliZlTKJR4t0n/rb3WYaQ4I/CSHZUreDpqn8LGh1IYPyv/Yk2FSzDGS6JPWzDw/pF2eVvbbI5crZ+BQ6J56sU64c21aD3c+f2/t9Rl1yDno0yfQU0svA3BIsBgREe0iiVxtYBqhOS2lTQoT1MwIDgw7X66UPDKrEYIpZ8GAl9//lvVjISAqTMfnWDPBESM1D1f+m7upUErFUgeEaWcLyD95Q1VDwu+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 11:20:51.7430 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 618c252e-d683-41e2-9995-08df239be16b 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: SJ1PEPF000037A6.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR12MB9809 X-purgate-ID: tlsNG-bad1c0/1791285658-FC817034-97AB6EBE/0/0 X-purgate-type: clean X-purgate-size: 8693 On 28-Sep-26 14:20, 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 arm_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 > arm_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 > Reviewed-by: Michal Orzel This can stay (you still need here and in patch 2 acks from others) provided you fix the below remarks. > --- > Changes in v6: > - Rename arch_clock_frequency_hz to arm_clock_frequency_hz > - Drop now-redundant "# ARM only" comment on the libxl IDL entry > - Rework libxl__arch_domain_save_config() to a single exit point: fetch > physinfo up front and use "goto out" on every error path > - Move the gic_version IN/OUT -> IN comment update to the GIC_NATIVE > removal patch > - Added Reviewed-by > --- > .../include/xen-tools/arm-arch-capabilities.h | 10 +++++++ > tools/libs/light/libxl.c | 1 + > tools/libs/light/libxl_arm.c | 29 +++++++++++++++++-- > tools/libs/light/libxl_types.idl | 1 + > tools/ocaml/libs/xc/xenctrl.ml | 1 - > tools/ocaml/libs/xc/xenctrl.mli | 1 - > xen/arch/arm/domain.c | 2 +- > xen/arch/arm/include/asm/time.h | 7 +++-- > xen/arch/arm/include/asm/vtimer.h | 3 +- > xen/arch/arm/sysctl.c | 5 ++++ > xen/arch/arm/time.c | 9 ++++-- > xen/arch/arm/vtimer.c | 4 +-- > xen/include/public/arch-arm.h | 14 --------- > xen/include/public/domctl.h | 4 +-- > xen/include/public/sysctl.h | 20 ++++++++++++- > 15 files changed, 77 insertions(+), 34 deletions(-) > > diff --git a/tools/include/xen-tools/arm-arch-capabilities.h b/tools/include/xen-tools/arm-arch-capabilities.h > index 21e3c73bd1..a927bc4703 100644 > --- a/tools/include/xen-tools/arm-arch-capabilities.h > +++ b/tools/include/xen-tools/arm-arch-capabilities.h > @@ -46,4 +46,14 @@ bool arch_capabilities_arm_gic_v3(unsigned int arch_capabilities) > #endif > } > > +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_FREQ); > +#else > + return false; > +#endif > +} > + > #endif /* ARM_ARCH_CAPABILITIES_H */ > diff --git a/tools/libs/light/libxl.c b/tools/libs/light/libxl.c > index a1fe16274d..98c7f0fdb3 100644 > --- a/tools/libs/light/libxl.c > +++ b/tools/libs/light/libxl.c > @@ -410,6 +410,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo) > physinfo->cap_gnttab_v2 = > !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_gnttab_v2); > physinfo->arch_capabilities = xcphysinfo.arch_capabilities; > + physinfo->arm_clock_frequency_hz = xcphysinfo.arm_clock_frequency_hz; > > GC_FREE; > return 0; > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c > index b9c0c820d6..47b662ea5c 100644 > --- a/tools/libs/light/libxl_arm.c > +++ b/tools/libs/light/libxl_arm.c > @@ -252,6 +252,16 @@ 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; > + > + libxl_physinfo_init(&info); > + rc = libxl_get_physinfo(CTX, &info); > + if (rc) { > + LOG(ERROR, "failed to get physinfo"); > + goto out; > + } > + > switch (config->arch.gic_version) { > case XEN_DOMCTL_CONFIG_GIC_V2: > d_config->b_info.arch_arm.gic_version = LIBXL_GIC_VERSION_V2; > @@ -261,12 +271,25 @@ int libxl__arch_domain_save_config(libxl__gc *gc, > break; > default: > LOG(ERROR, "Unexpected gic version %u", config->arch.gic_version); > - return ERROR_FAIL; > + rc = ERROR_FAIL; > + goto out; > } > > - state->clock_frequency = config->arch.clock_frequency; > + /* > + * 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). Otherwise the guest > + * gets the right value from CNTFRQ_EL0. > + */ > + if (arch_capabilities_arm_timer_dt_freq(info.arch_capabilities)) > + state->clock_frequency = info.arm_clock_frequency_hz; > + else > + state->clock_frequency = 0; > > - return 0; > + rc = 0; > +out: > + libxl_physinfo_dispose(&info); > + > + return rc; > } > > int libxl__arch_domain_create(libxl__gc *gc, > diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl > index a7893460f0..4284a4f577 100644 > --- a/tools/libs/light/libxl_types.idl > +++ b/tools/libs/light/libxl_types.idl > @@ -1201,6 +1201,7 @@ libxl_physinfo = Struct("physinfo", [ > ("cap_gnttab_v1", bool), > ("cap_gnttab_v2", bool), > ("arch_capabilities", uint32), > + ("arm_clock_frequency_hz", uint32), The golang bindings need regenerating I think. > ], dir=DIR_OUT) > > libxl_connectorinfo = Struct("connectorinfo", [ > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml > index 147afa62c2..582897af6d 100644 > --- a/tools/ocaml/libs/xc/xenctrl.ml > +++ b/tools/ocaml/libs/xc/xenctrl.ml > @@ -32,7 +32,6 @@ type xen_arm_arch_domainconfig = > { > gic_version: int; > nr_spis: int; > - clock_frequency: int32; > } > > type x86_arch_emulation_flags = > diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli > index 9fccb2c2c2..9414b87164 100644 > --- a/tools/ocaml/libs/xc/xenctrl.mli > +++ b/tools/ocaml/libs/xc/xenctrl.mli > @@ -26,7 +26,6 @@ type vcpuinfo = { > type xen_arm_arch_domainconfig = { > gic_version: int; > nr_spis: int; > - clock_frequency: int32; > } OCaml stubs fail to build on Arm because you haven't updated the C side (alloc_domaininfo() in xenctlr_stubs.c). ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 06 11:26:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 11:26:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441427.1659029 (Exim 4.92) (envelope-from ) id 1xE3JG-0006zF-Ls; Tue, 06 Oct 2026 11:26:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441427.1659029; Tue, 06 Oct 2026 11:26: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 1xE3JG-0006z8-Iw; Tue, 06 Oct 2026 11:26:14 +0000 Received: by outflank-mailman (input) for mailman id 1441427; Tue, 06 Oct 2026 11:26:13 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE3JF-0006z2-KZ for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 11:26:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE3JD-005bC7-6p for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:26:11 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4dac9-e002-0a2a0a5209dd-0a2a450a974e-30 for ; Tue, 06 Oct 2026 13:26:10 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4dad2-f2d2-0a2a450a0019-d1558034c193-3 for ; Tue, 06 Oct 2026 13:26:10 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a02753c04fso3599845e9.3 for ; Tue, 06 Oct 2026 04:26: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-4a178c53997sm100215505e9.12.2026.10.06.04.26.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 04:26: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=1791285970; x=1791890770; 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=8Z95tJ6WLbM1DPP+yQ8pzflSDnL9xaj0PQek9EAn+SM=; b=d7h3DPStgDZN0chLFD+WfvC1x+4OSGqc7qDTtr/NKNuqf1EG4/m/RdXP/IfOIF4LXu aRaPzI6hfBunzV99evKsoMttd0CtBBX46E1cp2CEypGE3AXhmz3poNRFc29FNU5ShsZY 2ULBpFcs+rizJnTZUeYSeQ1j/eEg5acvi4k4t0zrwH/lvZ5ZMwDEmPFiKlgc6F9j6m2L YdYKgivqM5M3RrIB1Ql4ulqeBIceoMaZFJQ34q9nTYY7CeIhHjjnlMNqcnMzxZMD0U4v Uin1QAqXuNIseJBuamxm6lZ8jvQBynvZmccJT+YCkCh6kEcuE8GohGH92Oz7CEamBoOO z8dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791285970; x=1791890770; 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=8Z95tJ6WLbM1DPP+yQ8pzflSDnL9xaj0PQek9EAn+SM=; b=gCGyR2ypvyc24ueqlzJ74s/lSJhKkni2cfV0JIOyrX2aG2waKanVrw/J563K/XEHRz khjn6mMsCpyjNoyBd1lZgjOCuU1lthIXil8uBFzsBgbwkxPk07w0+fQQkKxrneZMugOu 4Z9OnaGESkmlmUVmW+FJ8MLr4mjqOIkdGJoaum7J57/wctL846zKklXiTpFwUVAB9jRt fi8v8ZEV+fpAjl7/6zaI/uwj1TfhewNMZmCIOPYxDBnCYUJl2Ln52zQiCCGWi5PKEKAn XGZ35b1yuWMmXmBXUkgl3X4bDhjlGkkR08X/pYWqVMgr/XxfW2GyxfUU2Kg3NgpoO1jT 8HGg== X-Forwarded-Encrypted: i=1; AKwUvBzP/bVfAc6Ckjju06pzG3+d1XucWWg8ZIGBTLbZbiO/eXIarWhnKbSbZf9i2hq5eCRTi9Q8DcXXf2w=@lists.xenproject.org X-Gm-Message-State: AFuF++kSKrI/CP9GEaEC7Vpil1lbmpsdWx2uaaMmNb/0juX7VxsF74Nz 55i4aH0ACHctl7H2ui+uU25FARvrW0Jr/9BpkNVy201X3ORVZOOrhJxPx8pDvb1yxg== X-Gm-Gg: AYBFou0ilBhOsl7R9FxNeU1csiXBr+hUnkTM+CSVUh7hYACcgTu8x0pcmBbxjH28oPh NxsTUeh7WEtieR/TlnjbmfQRLPx6jFHt8AdHGbb/qHt3yqbJHJzuNw5VJ3xjEImcnity3hGC3m1 BD6CLkG1PW/vXl7raTjeRnwsrv6r/cJEc+DlpINqxLVJTXu/EzK2TisBtHtqVa0qRLOIHtFbG80 NxVOeqdzL+Ij9nEPHba6O/M/8ahLawgti9cdLLmoFwniHVMnH7nT2VjqPWRUHPwyukU0r/I2Tu9 4ZRgFHpCU4gUxsjhGCFnj43zHsMQYsArOT8snB7b9YS+XZrBbOA37SBMOI40LvNxa+MxjkKUNpD BvIiRfgLzCuNyBdT9r18YflPHOaZccqsrs5uT5rZiryLGnzwdgEj2ugNZO/qXdHsybqDEp+IcyH dXe97Vd7xZBaUCI+HEkLo+lewf4HngXdVy2gX0sMGxanK7oRBnNRToKqKTvrpznbxSbWPR8PDEj Hnksy0CbKYknTY/kCJ3Iy65CPKdqt9pdEyzLPmFP3/qJBg3HHL9Igg2z8lxHsA= X-Received: by 2002:a05:600c:1f83:b0:4a0:1b15:8852 with SMTP id 5b1f17b1804b1-4a17b5359c9mr18418825e9.16.1791285970251; Tue, 06 Oct 2026 04:26:10 -0700 (PDT) Message-ID: <3bade5ec-e91d-4181-89d9-de35bd42ce62@suse.com> Date: Tue, 6 Oct 2026 13:26:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/kexec: Annotate more noreturns To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20261006105445.511099-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: <20261006105445.511099-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791285970-52EDACFC-CD2B200A/10/78276251493 X-purgate-type: spam X-purgate-size: 1797 On 06.10.2026 12:54, Andrew Cooper wrote: > kexec_reloc() does not return. Plumbing this property upwards lets us mark > machine_kexec() and machine_reboot_kexec() noreturn too. The latter already is annotated such (see also next remark) as of 4d2ed2f88a0c. > --- a/xen/arch/x86/machine_kexec.c > +++ b/xen/arch/x86/machine_kexec.c > @@ -142,15 +142,14 @@ void machine_kexec_unload(struct kexec_image *image) > /* no-op. kimage_free() frees all control pages. */ > } > > -void machine_reboot_kexec(struct kexec_image *image) > +void noreturn machine_reboot_kexec(struct kexec_image *image) > { > BUG_ON(smp_processor_id() != 0); > smp_send_stop(); > machine_kexec(image); > - BUG(); > } > > -void machine_kexec(struct kexec_image *image) > +void noreturn machine_kexec(struct kexec_image *image) > { > int i; > unsigned long reloc_flags = 0; The annotations here aren't needed, are they? I.e. this hunk can shrink to just the removal of the BUG() invocation. > --- a/xen/include/xen/kexec.h > +++ b/xen/include/xen/kexec.h > @@ -49,7 +49,7 @@ int machine_kexec_load(struct kexec_image *image); > void machine_kexec_unload(struct kexec_image *image); > void machine_kexec_reserved(xen_kexec_reserve_t *reservation); > void noreturn machine_reboot_kexec(struct kexec_image *image); > -void machine_kexec(struct kexec_image *image); > +void noreturn machine_kexec(struct kexec_image *image); The annotations on the declarations are sufficient, with another Misra rule making sure we don't omit the inclusion of the header in the CU having the definitions. Preferably with the redundant annotations omitted, and with the description slightly adjusted: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 11:33:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 11:33:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441434.1659037 (Exim 4.92) (envelope-from ) id 1xE3QP-0000ey-Bz; Tue, 06 Oct 2026 11:33:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441434.1659037; Tue, 06 Oct 2026 11:33: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 1xE3QP-0000er-9Q; Tue, 06 Oct 2026 11:33:37 +0000 Received: by outflank-mailman (input) for mailman id 1441434; Tue, 06 Oct 2026 11:33:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE3QO-0000dg-D5 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 11:33:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE3QM-00Fbco-Ut for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:33:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4dc8e-8faa-0a2a0a5109dd-0a2a4501ad7e-0 for ; Tue, 06 Oct 2026 13:33:34 +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 6ac4dc8e-5984-0a2a45010019-d1558033d8ed-3 for ; Tue, 06 Oct 2026 13:33:34 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a020e65269so5002915e9.2 for ; Tue, 06 Oct 2026 04:33: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-48c622ad2f9sm9315557f8f.38.2026.10.06.04.33.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 04:33: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=1791286414; x=1791891214; 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=zhRxXI2vG3Bec2VYbHNPL4htDvm2A0FKca1uSEAeYbI=; b=MLguG7wfAR3GXt7KjPIQ5fBuWTTE9wSLvFIHlHlQqyFjOoJSOG1vaKRk/QYcBqGBun EWU3umavTV81+TuXyuZsoSjxD0oYPe/bjY91ms/I4ivg8E47MtRh2HD4oBtN+zXrPihY sDRs9HkwymRFJMlt66wBkuIeyk3FyBK85CPO86XpYFJgbZz70oDzVJiwAU/r1bpTAbQK NUWiszjzPGcnxgAdpGXYpmBgLGRIh5JYetfzREMWZz4E9IK4S9MAj6YvkQmygdEeaVvC xs7+557xi0EpD4cdVYO9NccJjAheQmjT+GxQd6kloWtLLaTkWq8wv6N5fwzXQzSKb6wi IAtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791286414; x=1791891214; 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=zhRxXI2vG3Bec2VYbHNPL4htDvm2A0FKca1uSEAeYbI=; b=wT3T5OBNa3mDq3VT/4VylmrLEBcgNRpMSHqtLdpzgvRoSY2e0EuIumglVMW2ScMDts 302WrDN6ZDQhLzOYgn0A2l5R1iDiRzEE6UlMLcXPQM4uFPg8mLaimcE5Ps+/XNEDLpsm kX2KohjEr4Bd23BsI/bgtMrwjy36lk8SooxEsoPaJ1aAZtdvpVdUOTgwranadb1yShgi ZQs2YJpzlK5RE+IUkRcyRuMlRBxXAHLRcjqI9trum9D5RwDrBC9vVsCeZQVSq7Xnzn6w ldIaU34KJbxSqT3O8JJRD53huNt3XMGsCcjVRNaLW57ZE2+ZInY9INfEHtCQDXLLf5ob 79Zw== X-Forwarded-Encrypted: i=1; AKwUvBztUn5seUnQpWhvt1NWtsT2BDR1clFZdrSgyi6a7I5vXlo2vCI5oR9mAlmQkfTcwRp7ZCcGhuRrrs0=@lists.xenproject.org X-Gm-Message-State: AFuF++lZoALWxYxS+7j4S7ju1WBZYbUuXXNp259I9iARlAhdHAc5BWpd xIo6Ub+mmOKZxkJlr5f+hLcJI3SnFzGR3Qv68bt1/F4s61aOFyNRyfSCme/nEbjC8Q== X-Gm-Gg: AYBFou38FEJEWDeDqdwQiwqUpCLO7LVkkMIwxxBg+tKS8iVTVPK1ZZVcwe9qoopmZSV MTCjEhodqiHQncnXox1fskIhhODaMAfZmtVEe+Hn0sll/14hbSG0S6f+K6LG7681eomuDCEl7LC znHbtaVEY8yQ3jTSDRQO+H0NlaiIQtIsiSJemyJwZYlqpQFXmgry99vnI/VUdL1Gs95N59Q4f33 PfaNus/ZGGVdtvd/o/Ul3cvYZ4McyIrkHYJzssYJNiW6t/Rw6PZlcbj4AOA1Y0R5UQnlm4v/+U4 JKHBFMowt4875OxSchWQjPgVpnpeI/dnIyt7XmRlvUEyLxJpkyijtN3QJ7snKRmw0lcuxG3ByLk ywDGJJBrU4DYYYU0a+GjMMif9IFuxdEoqiV6WgEd7TNTfmh7KjMwzjiyJfs7w6IWml2g+e6qKDz VD2557n0RFYzS0oNqBeCEteqpbXTcixMBwJkHcbhTxlLzsTUJgwgFjjEtXrZJOdX/mQtqyqYxVn /qbfEJr5wnb2MJZ/3v5LkaPDqOh16ukggoaTsJgDbcTt8zMHPRSKGboBQ0hQQ0= X-Received: by 2002:a05:600c:1d0a:b0:4a0:1e53:e51f with SMTP id 5b1f17b1804b1-4a17b52f03fmr16676595e9.14.1791286414213; Tue, 06 Oct 2026 04:33:34 -0700 (PDT) Message-ID: <015d6541-b8cb-4994-ba67-0683a8b99bd5@suse.com> Date: Tue, 6 Oct 2026 13:33:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/pv: drop the old GDT frames only after their translations are flushed To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261006103702.55276-1-gwd@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: <20261006103702.55276-1-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1791286414-C475B757-4AB327B5/10/78276251493 X-purgate-type: spam X-purgate-size: 2187 On 06.10.2026 12:37, George Dunlap wrote: > pv_set_gdt() tears down the old GDT before installing the new one, and > the teardown, pv_destroy_gdt(), puts each old frame's reference before > it rewrites the slot's entry; the flush of the slot's translation is > left to the hypercall wrappers, after pv_set_gdt() returns. If a put > drops the last reference, the frame can be freed and reused while this > pCPU's TLB still translates the slot to it. > > This is safe today only by inspection. The only consumers of a vCPU's > GDT slots are descriptor fetches by that vCPU and Xen's trap-handling > paths on its behalf, none of which run between the put and the flush; > and every other caller of pv_destroy_gdt() acts on a vCPU that no pCPU > has loaded, which holds no translations at all. pv_destroy_ldt() is > in the same position: it unmaps and puts, and returns whether its > callers need to flush, so there too the put precedes the flush, and > the arrangement holds only because nothing fetches through the slots > in between. > > Restructure pv_set_gdt() so that the flush sits between the two: take > the references on the new frames, install them (and the zero page over > the unused slots) over the old mappings, flush if the vCPU is the > current one, and only then put the old frames. The flush moves out of > do_set_gdt() and compat_set_gdt() to sit next to what it protects. > pv_destroy_gdt() is then only reached for vCPUs that are not loaded > anywhere, so it asserts that directly (!vcpu_cpu_dirty()), which also > covers the lazy switched-out state that a plain v != current test > would let through. Like pv_destroy_ldt(), it does no flush of its own > and is safe because the mappings it tears down are not live; it > unmaps before it puts all the same, so that a flush has its natural > place should one ever become necessary there. > > No change to what guests observe: a slot always holds the old frame, > the new frame, or the zero page; there is never an unmapped slot. > > Assisted-by: Claude Code:claude-fable-5 > Signed-off-by: George Dunlap Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Oct 06 11:46:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 11:46:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441444.1659047 (Exim 4.92) (envelope-from ) id 1xE3dB-0002ox-IA; Tue, 06 Oct 2026 11:46:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441444.1659047; Tue, 06 Oct 2026 11: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 1xE3dB-0002oq-FS; Tue, 06 Oct 2026 11:46:49 +0000 Received: by outflank-mailman (input) for mailman id 1441444; Tue, 06 Oct 2026 11:46:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE3dA-0002ok-02 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 11:46:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE3d8-004ieN-P2 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:46:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4dfa5-2eae-0a2a0a5409dd-0a2a4501c6b2-2 for ; Tue, 06 Oct 2026 13:46:46 +0200 Received: from [52.101.46.40] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4dfa1-5984-0a2a45010019-34652e289af9-4 for ; Tue, 06 Oct 2026 13:46:43 +0200 Received: from CH5P222CA0005.NAMP222.PROD.OUTLOOK.COM (2603:10b6:610:1ee::16) by DS2PR12MB101350.namprd12.prod.outlook.com (2603:10b6:8:70c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Tue, 6 Oct 2026 11:44:56 +0000 Received: from CH01EPF000BE942.namprd02.prod.outlook.com (2603:10b6:610:1ee:cafe::14) by CH5P222CA0005.outlook.office365.com (2603:10b6:610:1ee::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 6 Oct 2026 11:44:56 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CH01EPF000BE942.mail.protection.outlook.com (10.167.244.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Tue, 6 Oct 2026 11:44:55 +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, 6 Oct 2026 06:44:54 -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; Tue, 6 Oct 2026 06:44:54 -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, 6 Oct 2026 06:44: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=nO1Y/Hdx4UpOybCEnuO6PrJ3GgR1nrOn8elbz7utEV+qOgk0c8PAcS9ngncIr+qClCqGRAsFzOjaRb4R80b6fH+Nj3fZXRZMj2xjH2+TvoTIB2BwZz5iLxHOOI0qEJcys2nCop1HwzPN+P4Ymk91lihQ4KA7Xk8J6F+M7vsN9Oob87Oy9vxpntcB7XaYotEhLBrKwciET3CUYXYr5anEVi4uLdLHHQvV7dxiPukRPjy2X1mhwf9ZmqtipkNNbNv/cqBLU+Z1bsZHKLq8SjGdwB34r+q4KCauW2SAhJ9TYIypX/hqhjg0dzEpfbemPyWqO+vqG74tb1M6wzQKlQ8JFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PoIyXDHzmHyxkVK7AU6CkW5eKjdahmgD6PSzYSvP+zA=; b=pxtAIpjUoc7S1/cncWZtucJOgk0FXG5FlvPnWolhWyZJOTFQ1mZcgqqd58oBUZ4VfPJvLN551DWCu/Gr72L9UM1smp7S54ZaZauNP7yt3oTDzKFx+UMdN1gs/6gj84p2agDbE0QhTeoP1bjLSv/c+gxccoLQFMSQHt9xu18T13x0NQDDIjzQ5XQZJXNakTs6GIJa6y3dSrGCRod3QoMacg0AI0jhCkWem4C1J0Vb9m0lSxgO1hIP2arbbby7/v8XtWvcDJzNJ+LEw3g3/ylcT2PaDdFevIZKhqhtgfPiwmEwXjky4DshD6LtAwZyRaaZ4Dz88uEOSOJ0NHibSepZcQ== 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=PoIyXDHzmHyxkVK7AU6CkW5eKjdahmgD6PSzYSvP+zA=; b=h0ScYJdTaIzAhJklVvrbEyq3JhMlcu6sWdkF/smy99AxCDB9r13pwuEs+q3bSFfd7rOVDNK7rmu3W/CcbHJqgZDiJFdip09pdaeKzkf7j4z0dOPO/9Ph8qooM6Cy6DejaDMiqIuHET/b6iyPuQw2sGurl57zo0j5tErBV2nWrlE= 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: <3aa383cb-5850-4975-8054-cade5afd38ea@amd.com> Date: Tue, 6 Oct 2026 13:44:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot To: Oleksii Moisieiev , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , "Jan Beulich" , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Teddy Astie , "Volodymyr Babchuk" References: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.git.oleksii_moisieiev@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.git.oleksii_moisieiev@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH01EPF000BE942:EE_|DS2PR12MB101350:EE_ X-MS-Office365-Filtering-Correlation-Id: 230a51f4-81ed-4cae-5193-08df239f3e2b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|36860700016|82310400026|23010399003|1800799024|18002099003|22082099003|11063799006|6133799003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: VUaHVD45Nhdg8P+xspFc6am7rVgxgmExcRR7eR5NTRdLnM9ID8lmunW0Fa189h7VEqI4Yb1q+N838uuTGoxWtgDJItdsG4Emzo76Uc5VVF+8Ki03iZLrcBPwBk1kgfdVukJxIagD3it7sozCkh0iA6izsF3Xe8Y/bPyGjgbhW/n9CXJUJYUwGfNK2nfxkeoGMKV9pXsi+vIEPurCv1Y/V4cn+1w68h8amqScMXImkPzYz+NjtEOggRk/qWLrZkQNsOjMM1phQo5wMlj3aPcGXLybtd7+iF2EOSmQB34VjJrRlNH1t32bHUjCFYZjoZ7uIoa/9XHJdAoLLS6tmtHgQIjrMi2YRR32p22leDMb4xAnk96CMnZNS48aI/Qi6cuVwQ2bBpC9Ui0d/ZPctHCb55T7cW3j9FozQn7dGVKgTxqZXt+zzq5o0IdGFcc0ur0+LJpTSyC2KvxmPBoUzZEEaRJA9SlMox4STNNV3C0CJ+M3enWx5Fy0CK0GJmkQ7AiQLk51I0GTJvzZDbHbXBiAtfDuI0xYZ3mJW4fT+nkKX8gYL7er+v2I8kSlJwf5mgKkjY3p1IPSVa1EgFrFGvxv0uYCNVgf0AJqMfbqI4/TIzLlXrg0e1v7U2FiX/btd7TBYuGWSiKOI3oo8mhp3i88EkMdBTVXL/q1HhvmUMMbd/tThtai41Xlpui+Wzoy0Xq/mnYmxu9uexi/bcBIaTdSmQ== 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)(36860700016)(82310400026)(23010399003)(1800799024)(18002099003)(22082099003)(11063799006)(6133799003)(10067099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: e8VlQVuumN09BJus78YsRwP92Z/s3MJfE0QcgzNnV6WJk6DFTz/LHravl8w00PXO4mSYpqmnmZ/D7pl5PSLNIpvpcYxzujZXjT0mpBTPy2cl7gZkndzUHtr4Ov9Xr1azaVheC0TMGb+B1JshYJegCK8yfr2idebWBLhjBdFm7esYlIOinMIs39NE/1y/zevhiwAYe8k9mOVk3LL3U1inRGF4GVwsbuOPjqZmavFP0jZG+0wd+ZZrGxHSw/OIfCTuyNTVCEJDoa7m0z3RsyLHcBKNr3aiFsSabSWXoKDU8LP2DdWPSs5BPn935aUqIIABpgmUUkaN6txxHixFvpP895R/B24uz8M1Aa+lEvzrgMv2XTYyGr2Au3aLIW0YHPs7h+d7Rp7F0V76LmM6uMlhnCxuXZQ7J0wPueyleeHhb9XK422uAxBQSzoWHuhAKO9d X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 11:44:55.9370 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 230a51f4-81ed-4cae-5193-08df239f3e2b 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: CH01EPF000BE942.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB101350 X-purgate-ID: tlsNG-d62444/1791287203-C5540757-905ACC69/10/78276251493 X-purgate-type: spam X-purgate-size: 7425 On 02-Oct-26 15:26, Oleksii Moisieiev wrote: > This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to > allow for building Xen without support for booting a regular domain (Dom0). > This functionality is primarily intended for the ARM architecture. > > A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by > default for ARM and X86 architecture. This symbol signifies that an > architecture has the capability to support a Dom0. > > The `DOM0_BOOT` option depends on `HAS_DOM0` and defaults to 'y'. For > expert users, this option can be disabled (`CONFIG_EXPERT=y` and no > `CONFIG_DOM0_BOOT` in the config), which will compile out the Dom0 > creation code on ARM. This is useful for embedded or dom0less-only > scenarios to reduce binary size and complexity. > > The ARM boot path has been updated to panic if it detects a non-dom0less > configuration while `CONFIG_DOM0_BOOT` is disabled, preventing an invalid > boot. > > Signed-off-by: Oleksii Moisieiev > Acked-by: Jan Beulich > > --- > > Changes in v5: > - rebased on top of the latest staging. > - add Ack > > Changes in v4: > - change Misra rule to 2.1 from 2.2 in description > - remove extra dependencies for ARM architecture from DOM0_BOOT > - rephrase DOM0_BOOT help by adding hyperlaunch > - DOM0_BOOT is mandatory for x86 architecture > > Changes in v3: > - rephrase error message when dom0less mode wasn't detected while dom0 > is disabled. > - rephrase help message for DOM0_BOOT config option > - update DOM0_BOOT dependencies for X86 > > Changes in v2: > - decided not to rename HAS_DOM0 (HAS_OPTIONAL_DOM0 was another option > suggested in ML) because in this case HAS_DOM0LESS should be renamed > either. > - fix order of HAS_DOM0 config parameter > - add HAS_DOM0 option to x86 architecture. > > CONFIG_DOM0_BOOT Kconfig option was introduced to make the Dom0 > regular (legacy) domain an optional feature that can be compiled out > from the Xen hypervisor build. > > The primary motivation for this change is to enhance modularity and > produce a cleaner, more specialized hypervisor binary when a control > domain is not needed. In many embedded or dedicated systems, Xen is > used in a "dom0less" configuration where guests are pre-configured and > launched directly by the hypervisor. In these scenarios, the entire > subsystem for booting and managing Dom0 is unnecessary. > > This approach aligns with software quality standards like MISRA C, > which advocate for the removal of unreachable or unnecessary code to > improve safety and maintainability. Specifically, this change helps adhere to: > > MISRA C:2012 Rule 2.1: "A project shall not contain unreachable code" But with this patch you will introduce a lot of unreachable code anyway. > > In a build configured for a dom0less environment, the code responsible > for creating Dom0 would be considered "dead code" as it would never be > executed. By using the preprocessor to remove it before compilation, > we ensure that the final executable is free from this unreachable > code. This simplifies static analysis, reduces the attack surface, > and makes the codebase easier to verify, which is critical for > systems requiring high levels of safety and security. > > --- > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/domain_build.c | 8 ++++++++ > xen/arch/arm/setup.c | 13 ++++++++++--- > xen/arch/x86/Kconfig | 1 + > xen/common/Kconfig | 12 ++++++++++++ > 5 files changed, 32 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 06289005f4..6d0936b353 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -18,6 +18,7 @@ config ARM > select GENERIC_UART_INIT > select HAS_ALTERNATIVE if HAS_VMAP > select HAS_DEVICE_TREE_DISCOVERY > + select HAS_DOM0 > select HAS_DOM0LESS > select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE > select HAS_SHARED_INFO > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 72d5316180..cc932d7686 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -43,8 +43,10 @@ > #include > #include > > +#ifdef CONFIG_DOM0_BOOT > static unsigned int __initdata opt_dom0_max_vcpus; > integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); > +#endif What about the other dom0-only options: dom0_mem (and CONFIG_DOM0_MEM), dom0-llc-colors and dom0=sve? > > /* > * If true, the extended regions support is enabled for dom0 and > @@ -123,6 +125,7 @@ paddr_t __init hwdom_get_fdt_alloc_size(void) > return ACPI_DOM0_FDT_MIN_SIZE; > } > > +#ifdef CONFIG_DOM0_BOOT > unsigned int __init dom0_max_vcpus(void) > { > if ( opt_dom0_max_vcpus == 0 ) > @@ -135,6 +138,7 @@ unsigned int __init dom0_max_vcpus(void) > > return opt_dom0_max_vcpus; > } > +#endif > > /* > * Insert the given pages into a memory bank, banks are ordered by address. > @@ -1862,6 +1866,7 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) > return 0; > } > > +#ifdef CONFIG_DOM0_BOOT > static int __init construct_dom0(struct domain *d) This makes dom0_set_llc_colors() unreachable. The same goes for prepare_acpi() with ACPI=y, as dom0less is DT only. ACPI should be prevented when DOM0_BOOT=n. > { > struct kernel_info kinfo = KERNEL_INFO_INIT; > @@ -1893,6 +1898,7 @@ static int __init construct_dom0(struct domain *d) > > return construct_hwdom(&kinfo, NULL); > } > +#endif > > int __init construct_hwdom(struct kernel_info *kinfo, > const struct dt_device_node *node) > @@ -1944,6 +1950,7 @@ int __init construct_hwdom(struct kernel_info *kinfo, > return construct_domain(d, kinfo); > } > > +#ifdef CONFIG_DOM0_BOOT > void __init create_dom0(void) > { > struct domain *dom0; > @@ -2001,6 +2008,7 @@ void __init create_dom0(void) > > set_xs_domain(dom0); > } > +#endif /* CONFIG_DOM0_BOOT */ > > /* > * Local variables: > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 16f899dff5..ea9c037fba 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -491,11 +491,18 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) > > do_init_boottests(); > > - /* Create initial domain 0. */ > - if ( !is_dom0less_mode() ) > + if ( IS_ENABLED(CONFIG_DOM0_BOOT) && !is_dom0less_mode() ) > + { > + /* Create initial domain 0. */ > create_dom0(); > + } > else > - printk(XENLOG_INFO "Xen dom0less mode detected\n"); > + { > + if ( is_dom0less_mode()) Missing space after () and before ) > + printk(XENLOG_INFO "Xen dom0less mode detected\n"); > + else > + panic("Neither dom0 nor dom0less mode was detected, aborting\n"); > + } To avoid calling is_dom0less_mode() twice, how about: if ( is_dom0less_mode() ) printk(XENLOG_INFO "Xen dom0less mode detected\n"); else if ( IS_ENABLED(CONFIG_DOM0_BOOT) ) create_dom0(); else panic("Neither dom0 nor dom0less mode was detected, aborting\n"); ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 06 12:21:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 12:21:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441467.1659080 (Exim 4.92) (envelope-from ) id 1xE4Az-00017t-FK; Tue, 06 Oct 2026 12:21:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441467.1659080; Tue, 06 Oct 2026 12: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 1xE4Az-00017m-CW; Tue, 06 Oct 2026 12:21:45 +0000 Received: by outflank-mailman (input) for mailman id 1441467; Tue, 06 Oct 2026 12:21:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE4Ay-00017g-GN for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:21:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE4Ax-00C1u1-8C for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:21:43 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4e7ce-8faa-0a2a0a5109dd-0a2a4508cae0-10 for ; Tue, 06 Oct 2026 14:21:42 +0200 Received: from [40.107.208.57] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4e7d5-f659-0a2a45080019-286bd03977fe-3 for ; Tue, 06 Oct 2026 14:21:42 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by DM4PR12MB6208.namprd12.prod.outlook.com (2603:10b6:8:a5::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 12:21: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.0496.010; Tue, 6 Oct 2026 12:21: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=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=O+xmDdBpY4l+ybgD2Qu+1HolYym40xVO+8cT4+8S2aTamSI/fUW1RMyY8wcq40yOUOUxZQuFFS220Xv3nKyu+9/GR+xyNBxDg/AgFSjwERKtacdnXDhAuuTxc1iYoU3oBCctG8VrrcYXdI4UKvXmkyIssFI89IyUXfZ50sMy0Kzj3P0p5Nf59FYdMHYmoKglKZnzfct39rx+W7Ax9A2q5U0YcWmEUkpTe0JKJGqNXLDy8T7bpsWnkdP4s5q5lQ3nU6hu+ajrRTYYJ75G7b9AeL/JBUUZpPrS+1sJlqrcDhTAwVAyUOSlRlHWVprA9EwKyP2kydVjBdlhHH0l+5+VuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0L0TIWnnKQVHg5t9SZCiwB1zz6+si0noHsKHjoNk8iw=; b=aAZ+AK0pO6mkTArqQ/XT8HuEhymaxRiwHumdfGDfrgN7a7xxfCluJvWBWQ2Jtb0qPwsQHDb3MqN0BFv5HD8WV9Em1ZWSYyuJso3+SfFRdzwAJfks7jNH649XUhoo7pEBFX4i71HIiTbkDtCdObZ0lwiAY5/VL1yLxSBjw5RXkAMl2zRREJgrIi43mK4o0BG1cM9LKtRMOY8+6s0dKnJdaUDaXFydMGK3Sh0kY34cNIrzphcU0xwTQwxTllQj4vlbskwkTsvnq3elL1jiNZzRImtpr4pMTdCaomfTKKnyMj8zP4kUDWOLtCDy/31B/FyyA6j7kgmvlUTEdCpR6yanQw== 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=0L0TIWnnKQVHg5t9SZCiwB1zz6+si0noHsKHjoNk8iw=; b=WJjjMVvFrq+gaTdn+ylKZM9PfdUd8myU4T5y29Vz7UJDRnqsEhj79ir8vGls/PEUx1oSUCtnNSbmRcyW1N8ikpTFu5R7LDofxH4+nVBsWsFJjkkAmBPaQ7ZOQjo+43Tua6djv0hc0arwGJo17Z22uBc0BLzpa89LOSrzQtXUpE0= 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, 06 Oct 2026 14:21:28 +0200 Message-Id: Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" Subject: Re: [PATCH] arm/nospec: Make nospec helpers always_inline From: "Alejandro Vallejo" To: "Andrew Cooper" , "Orzel, Michal" , X-Mailer: aerc 0.17.0 References: <20261006103142.139422-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-ClientProxiedBy: MA3P292CA0066.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::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_|DM4PR12MB6208:EE_ X-MS-Office365-Filtering-Correlation-Id: 39ce28b0-6008-4461-db8d-08df23a45aed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|11063799006|56012099006|4143699003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: qwchgW8qu3K5x9TN4+zq7njqZTLiLHAsddDzhciXMjrAMfRLvUSofQ6j2LDJ9IFFuC71OzGxofIvqjhjar6e1sycmyRdb7B6Dv9mRMwLXbXntnT+9hg3AQkoryU7nChdRFSr6wWzcy4n9p6dkWJxjqVgEXbU+4Wf6NIf2VS1/7y5msxDpZ0rPkCKTe7H6SXbW1x0y6uJMJYmBYXCZ7YRa+1DZ5pndDJ/Ith1Eb/UlXQO5yEACOkJvs1XmUyVShdN7ohQSKiSe873k9cAZBWxHAoFISZULaNk36kAeHQnnlSmwGPWf13S0lQqDjjrD7gy3qcxrneaSZiUB/EuuC5uxtCR3nNg0t3qn7bNFIKjY8a4I53GDqYTM5UkDxG/YEhA4brkchaLDdJ9Cf8+P42uiq3mpkd/zjswiLdefySah1N21LEhjNBOPjMEs3FJKv+gLKMCGHtspA9MIEGbreE3UNpAktU079YgPGdohPcM3LYYhW59qaX/P2/yYZ1q91suiVy5zlp3wYBYvkr5wvAPjgJqC9SwyYBnWP1qGbjfJVN9tUpzPAjsPkmyXyTjyh+5/yPEKsz4ZA0ubgzJzdsSBDcLTjDEtGBjhA6XYRayvJtG5ifbyHxQ4jzXW336Ryhpv9Roi2R3F+IKzuH7XT55wpAFPXIxJBs6wRbaWc7lH5g= 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)(23010399003)(376014)(366016)(1800799024)(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?VWUvd3Z1eGZyZ3ZqUVo2ckZVWHNwKzVOL0Y2S0FFWDlOU1ZETFoxeUtlM3Jq?= =?utf-8?B?Zm1UczYxV1hTa2I1MDBabTBKdGI4UURXeDR6bHlJaDRXTm9hR2g5QXRWNUlI?= =?utf-8?B?VVM1QldBV3FXRDRGQzJ3ME9NZXFzalFpb0pVOTV2RUJHTFdTVUhWTlRZdWVy?= =?utf-8?B?RGlwOGIxTkljVEtER0lRWHZZQzVzRi9ONE0xZjMwbkNhcUUvMmNkYlFIMWVj?= =?utf-8?B?ZVhZcm9EWWJiYktubDA5eXl6MFQ2QnFta2FNdVI0R3dJTy9wMmtBeDExQzBH?= =?utf-8?B?ejdFVVMzZ0tDR3RLOGhmby8xWmtMaE9mNnpxcW5PRVF5Z1FBb0d4TVF4QU9y?= =?utf-8?B?bG1WMll1c3IxUGhNRHpGcWd4dnJRVER0NE5yMkdlcWk0M3NENG11YjZ6ODJu?= =?utf-8?B?WUJ2bjBCYjBnQ1FoMThtZ3RpMFN0ajloYzFJOHVYWEhvY1VPQnhsaEdCc0li?= =?utf-8?B?MUozcGdPUHAwWnJVd3R5am9hQTRId3hUU2tPQzdEbUVZbzRWWGVrRnpOMmov?= =?utf-8?B?MXl0WDFiMjltS0hMYm5wb2NPZXl6TEdlc2xpU25TQmI3WWhYWGdjOGZrbSs4?= =?utf-8?B?ZEtwUVQ5WGpmSUZJWmd2UmZrd1lxbHpwcmtlTnZ2M2dWU1pEbTVNN01zRlp1?= =?utf-8?B?U2pYN3lmQ2xRd1RVKzk5S0hpbXJpbFZMdUdhUDVCWHhOY1JtNnplTnhuYTlK?= =?utf-8?B?Q1ZibnpMUGU4V0dmSEJ5aTRpUlFrL2lCNU5YakNVVTRWWkhxTVQxaVZCRHhM?= =?utf-8?B?R1lBWmRGMmhLcHk5OWN6R0ZJU0JrUVVHQXh2c1Jta05VUWc4OTFIZHVKUDAv?= =?utf-8?B?WE02NERhS0Uxa3JGSGhTMVNkYVgxNU1lYUEwb0Y5dUtyWlZkSENmOVdhYWhW?= =?utf-8?B?VmdTeFVabVdNQ1F2NWlXV2NHWXV5RTZKRjY5djZUZFVxMUNQSE93RkVJRmVG?= =?utf-8?B?ZWhKQWN6UGRVSk1UMC9vR3labHVMWDAzamhrRjdZaGxMWjRyOGNjRk83Y01G?= =?utf-8?B?UVczdG9MT3U1Vmo4R1FpQnlBVnNWZk5OaXRFZjUxZ0Nya3BFanlwL3ZTUHEr?= =?utf-8?B?UTc2NCswdUh2MjMyZXE3My9aOHJvSTkyT2RUOUd5L0pNTzc3ak1VK2F4RDV6?= =?utf-8?B?S1MzM1RQWCtybUlYbyt5bnhqV0NSUnVhcG12R2xWVUNRb0Z6OFpJdUJWQjVl?= =?utf-8?B?N2ZsOHhQNjlwNGEzTlovZThOV29aVExxWlVjYW4wWFNpTzNOSVBUYllHb1NH?= =?utf-8?B?V2t6YmsxR0ZQUk9PcnlzUFpSa3paUmRvbUllVEs5UEFsQnNUalVkc0xsNEtq?= =?utf-8?B?ZGdZRHAwRC9wVWk1RjdxditQNkdCSDgwdnJGRTdDVHUwdEtGcnh2OGdBVW4v?= =?utf-8?B?Wi9FdnZ4SVQ0czNjbi9kdkhoRGZYTFR1ZldYNmJ4RVNHc2U1NGdLZVNrVUtn?= =?utf-8?B?dGQvVW5lcVIrbDN0SnBGQWFUYVlTUGNEak5HYUJScVJuQTg1cEJMOU90OHpG?= =?utf-8?B?VlJ1ZjZCV2pPdXhqNTdYOURpbEFRYzRQYjZlNFFCL1RkZ0Z4UTFrWWYwUVNk?= =?utf-8?B?Z3c3RVV4TjNoWTBYQURDZHR1SmFTZGFmMjdBZFdpODQxT3VhZlNuNDZNZGpx?= =?utf-8?B?a0Qwa2wwWkl4T3pTNWhkKzdBSitFTXM4a1IycEhTTTNDQVJncmtCbGFDaE5N?= =?utf-8?B?aHUxaVBXd1dNOGp1Rlkweklmd1Rjd3MrMmNYK1psekp1NjZKVTZ4ajZwOUxN?= =?utf-8?B?QThhOTY3Q0FOM3BPNXZCKzdmM3d4dkxPMHQyM2ZzWFhHRWNUY0NMaERoak1p?= =?utf-8?B?STVrbEhqTW5acm0xVDUvZHhXWFdmeENZcVN3U0ZydmdOdVBMWXgxaU5qYzNx?= =?utf-8?B?N1ZraHZzdXhPM0xrNVErMHZaN09TdW1aNU9kaGJFN0VFMjg0QmFFaVNJMUxK?= =?utf-8?B?RERsLytFanVNYktjbnA3OEhXU2kraWRmQndXQWYvRHNJUFdNQjZnOUl0UUlI?= =?utf-8?B?ZitsK3ZVeTRHUFozVVZJM0hUTXIvNEtUNVk2N0ZNdStOZXNnL0tUNVM3S0NF?= =?utf-8?B?NStDRHZnNlpKRTBUdm0wN0RTTnR0ckRxMVoyb3FBTFJHSEo5THdZYkVyelBS?= =?utf-8?B?OWpXMHRoUWZwM2NVN2YzV2RvdFFLdEl3MVVnaEMvNmZBS1kvM1FwaUFiMk8w?= =?utf-8?B?L0VLbGhxVnZKcWlVM2hBaVo4RHFkaEFPY3haM29TSWkvRm1VYzU5VEg4eENs?= =?utf-8?B?LzE0TVNkc2huQWo0blB4TEp2ZWRlMzFyS2RGSTlDcVc3VTFjY2w5T1o5eWtz?= =?utf-8?B?N2htVTdOMzZFZGJUQXNxRko2T2FRYjlaQmtVY2NuVXJNWWdUenlyQT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39ce28b0-6008-4461-db8d-08df23a45aed X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 12:21:31.8932 (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: eKUp03HGXrqv6UugvKf4UXaNOcUoqmn95+HD3OvdVouj4IngfCRN8vQ6F0jWD9U8b2vkPU4M9NNckG+YmlhAtA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6208 X-purgate-ID: tlsNG-c1860d/1791289302-D574B87B-6C542CF2/0/0 X-purgate-type: clean X-purgate-size: 1158 On Tue Oct 6, 2026 at 12:51 PM CEST, Andrew Cooper wrote: > On 06/10/2026 11:45 am, Orzel, Michal wrote: > > > > On 06-Oct-26 12:31, Alejandro Vallejo wrote: > >> While today they don't implement fencing in a way that would block > >> speculation, once/if they do they'll absolutely need to be inlined, ev= en > >> if -fno-inline or -fno-early-inlining are passed. > >> > >> Signed-off-by: Alejandro Vallejo > > Reviewed-by: Michal Orzel > > > > but this should be done for Arm, RISCV and PPC at once in which case yo= u can > > keep my tag for v2 # for Arm. > > I previously had a patch series which made this all common, for these > kinds of reasons. > > I think I'd prefer to kick that over the line, than to keep on taking > micro-bugfixes like this. for reference: https://lore.kernel.org/all/20240304161041.3465897-1-andrew.cooper3@cit= rix.com/ I wouldn't mind that, I can R-by it if you resend it. I'll still send a v2 of this on the grounds that it's a strict improvement over existing matters and might land faster. Cheers, Alejandro > > ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Oct 06 12:29:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 12:29:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441475.1659089 (Exim 4.92) (envelope-from ) id 1xE4Iq-00022Q-6E; Tue, 06 Oct 2026 12:29:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441475.1659089; Tue, 06 Oct 2026 12: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 1xE4Iq-00022J-3K; Tue, 06 Oct 2026 12:29:52 +0000 Received: by outflank-mailman (input) for mailman id 1441475; Tue, 06 Oct 2026 12:29:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE4Ip-00022C-7v for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 12:29:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE4Io-00C3F2-LB for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:29:50 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4e9b1-e002-0a2a0a5209dd-0a2a450981ee-30 for ; Tue, 06 Oct 2026 14:29:49 +0200 Received: from [40.93.198.26] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4e9bb-be1a-0a2a45090019-285dc61a983b-4 for ; Tue, 06 Oct 2026 14:29:49 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by MW5PR12MB5597.namprd12.prod.outlook.com (2603:10b6:303:192::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 12:29: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.0496.010; Tue, 6 Oct 2026 12:29: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=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=jT51usW4g3monHE6hM2LSH5Y21a8JA1yIcgyrMO7cGVtYj9RX0f42O/j2qnv9lZhkz1jBx9/rgIQaPJxUTp9PAj6aViTztrfmUZSUCSrcoB9S3Pv6J0xukRXT0A+JtTR//6xHCkMRtbIhVF3j09klUFlcDVhpSeF498oCZqmjb7a/DVh0cgYANic0hXgXnVKXdz4/ZSDDCIKxSUz2Dn0oWgf3etuGVEzWt/ltYc+dN8GEajwAnV1oO9kq94/bzhqL8kudBH2v95jq/yzy7+Ez3OsFIuCsbcGcX66xpll+6ZL1q7kvzLPzeLOOmGPADRW6bZu2cS3jjc2nXTMGburiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DuG09F/PZRagwLzwz0P6+lF7+4aB+HcTYJQYawMjQVU=; b=lTTccw1tRfgj4wtKTxfeQ/tw2Dnw6sbqJ3C9P3bIErNwnRl1EmZlKH7HzJUrSzII+lrhlXKcJiCMK1gbqmvE4waWsEmwdH/Y1HP/Kc6qdajmFnrjhl/AvpniYC4YqB6RFIrwuQrSSSo4MH0BfUQLJOQLkuenSHBLtB0lNLgZUWgiW/Yk7gavyv5fo94VDTrCXcV4NN04KWkLJOPn7YQkVpl0f2VNxURjtx3pxh8daSfBMlTjjyDNIe39msfnIszLCAwzHoH5V6mPkSb0Jt30hf+bRwNn8gsWgSDwKL4qEXLioov/xulmaRpmzzhWxGp0Q7diKrhVH+Rnj65iAnN5RA== 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=DuG09F/PZRagwLzwz0P6+lF7+4aB+HcTYJQYawMjQVU=; b=e2tMfPh85XJpVY6xwmOKqy+NZO9j/jegO7/5doVdTp3MVc4H5S3copaCWtRP5jYPH1YuSt5HqAtde28elelIfhpOwvyMyZougfpBTj6UY1jPjABe28zU6jUO2tHUGPxh4F0z6javANRFkQmORNGrlMlBwpJRCaptgnEB5dDw9t8= 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, 06 Oct 2026 14:29:39 +0200 Message-Id: Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" Subject: Re: [PATCH] arm/nospec: Make nospec helpers always_inline From: "Alejandro Vallejo" To: "Orzel, Michal" , X-Mailer: aerc 0.17.0 References: <20261006103142.139422-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-ClientProxiedBy: MR1P264CA0184.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:58::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_|MW5PR12MB5597:EE_ X-MS-Office365-Filtering-Correlation-Id: 987d0c2f-6c3b-4fb6-98f8-08df23a57fb1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: qTHGLbvZPWMZq4OtVBo5Oexe92jHaDYvFn54+DneuIY+hgJP210BMSF0l00xFBbCeQwzdB7isHjaRQ8IH6hkG0nSY/VS2w0talDvAZtoghv15veyB6jCc/G6UKoJq9sDrIX+OWwJ+AldJS2vZ9+ZRCGcjBZ9Eta7ecigsgWpwlPTlmLUbdBTED+QVxBRlSDWvK3pf4YgzeqGME6W8D7ARvvet2fMZkxrkPz0Hy3klEbHLVkAVXL1BO/0cFPxcrljeRgHBaveoauWZuTxsV4GHpI4ZWQ0d0DSjLGvP63bMWB/rTwk+gkOAeUpxIeBcRwAORPvF5Iq2FGl6JOL4Vx7H/6Ykt1w2YjhIDAAAWlmCksp2DNk4YxOKu+8tzjLDXKQ05BA6BAFrSWv1bfD2/XfaNfl4cpU9PH0Hq1WjbzuejrmvAB86rbCvD/6szhCfVP9PQgKFDgBhBf5XvEIF1gQANjuNuGcUtrsEGk8dnMkqH3Ukyb5siYNAsptnLR8/DelzGdmu5aqZMNdGfqavzl31H3LL4UvdDsS+mHY/bmCZoteOwuLujQfKP/wjQBFviXNRSKH1384ltOt8VLNQx0bqCY+k/hYNeip+wRgb5i4lc/D3z6ef+zK7r15tGGea44bAPNxYdYA8reZZASXidva3yqIXGVzav+wsoDNZM1ASzg= 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)(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?ckprRlFqTkVXenpubjk1ZzVOQjh6Y3B0WmhtSXBHZ1k4U2pPemtTMHRHSXZk?= =?utf-8?B?V2VzU1BFaEVnQWliK1RMbFFYdW5nM1UvYzB4MGZpY2ViNDUyTnpzWDdoZGsz?= =?utf-8?B?STZoOFJiSXdFaFBiT1Jodk9vbTFDN2pPSDFiODc4WTlOcmlvTHJ1ZmVkeU41?= =?utf-8?B?QWF5VFpiRVJhWTJVQ0ZIVDBHZG8xMDFvSm1hbklHVXI3UVg2TVRucWJqS0gy?= =?utf-8?B?YzJ2cGpnUTVJSDFtUS9ERVh4dEJjLys4VHV1L0tOdzNhTUxoRUVuUkNhQlBG?= =?utf-8?B?SHo5MWRKbVhPTFNIa2I3ektiOEZrQW1SSXRmeS9UUkJpRDh3VGJ3Q2ZydHVR?= =?utf-8?B?UW1xM0s5b3l0RkdwSzlCQUlNcUw4NFZYVzlPT1B6Y2EvYUg3SmpuOWR3YjIw?= =?utf-8?B?dlo3VHRvcktuQUVkVm93V3Bwb2g4clh3RC9hUlk0VzJIY2hjT09pNys2MVpm?= =?utf-8?B?Z212RlpxRUFCYUFTV1BEaW1QTTA5b2hGWm16L3hpdmtSQ3k4UWg5WnQ3LzRK?= =?utf-8?B?cDZuMXJZdUZmRTk5dks2Q1laTm5jWVhQeDJGN21PckkrVExNUHNyaFlzMVVm?= =?utf-8?B?SDNCeWxUcCtlSnBoZlE5QVJ0RzZoYndRZkFmcXZyc3BXcWFBcjhNcnJ1ZHJt?= =?utf-8?B?TVRPOTNlak9UcmRYNXZtcEdZYmZaeTVQcnlSYXdUSmhDNERxR3JvazNOY3JM?= =?utf-8?B?cUswS2JKYkFVQ05Ha1NJaEZXNis3ajJsMERuNHNwQ0VLeUE2eGY4MFJrMHdS?= =?utf-8?B?V2dIS2NQZTJWNE9qZnNDYUxZTFEybGxiVEREQ3AxbEEyMjgxT1piSm5xOHEz?= =?utf-8?B?WTVveVcvOWdFdFRlK1FwYm1CK0RsOXdaTitXZ1Z3N2c4T0IwV1lZNkNyVkdj?= =?utf-8?B?ck14eTVia2Fram1taEJDOGxrWWRVK1FYeFE2aXlvckNNYXU1RjBFeXU4T1ha?= =?utf-8?B?SkgrNnd0RmhsQUpRMXBkaW5PeDRFOUVDaU9zaFUwVTIxK1VubUNkN3l6YUs5?= =?utf-8?B?Skl3bndMTzk1UjdNVFNaMjhpS3ZQSGF1V3Q0OHJqd2ZqQitrb25PNUVIaHZp?= =?utf-8?B?OGxrZnRkYU5Ma3N1eVVLczB1WisxQkN6dlB1MGdzNjk3eGd2eEc2d2FUWEZq?= =?utf-8?B?ZnN6cExSWVhmeHQ0WHc2RjVldGxCaTBrb00wbERheGd1c0MwMUJpdnRrNEtt?= =?utf-8?B?WnpzTjR6clI2TDR1RUNwdDAyMUF4TG8vbEZxVk1NNzdPZTV3ajB3K0xQN1ln?= =?utf-8?B?YlRUdHcrdDhYZUhYMyt1cEZYTFRNYkFpeWpEQ0g1TmJSMERGN2JQZ1N2RERu?= =?utf-8?B?cVpXODZnWDZxNVB3cE52QkdLcXB2eVpKeVc4djZtOTB0QmdoeXBXMU0wK1lz?= =?utf-8?B?SUZBRHVjU2VXRDlyK0p5bEV5QjFHazRMK3RXYStDUUJ0RXByWlJKRXJ4U3hw?= =?utf-8?B?N1B5MWJ6bGQxU0d5NmptSXZIbk82R3FmUE84cGcyZHlBQTJ3WTlzcWg0Q1JX?= =?utf-8?B?YXNXRSthN1IwWThYemVpanowUHMvM1hVUFF4Q21Sd05aYjVJR3JqT0lCTTJX?= =?utf-8?B?RW5IdkZIdmJjRHpUVVpyY0JZVThGM3cxbm9zVkFUa2F2NTRyYlhiZ05RK3lm?= =?utf-8?B?aGQ0ZEJpYkhvMFJWMlhyRU5jYlQ4amF0K1ZselRpQzltakxkRDhjTGtiVGd6?= =?utf-8?B?ZkRvdUpOeThEVkRxa09GMmM0dW5YNllNVU1XcVVyY3Nva3IvSlVkNnA3SlV0?= =?utf-8?B?ei9aY3ZjN3pOUXY3eWUxOFZKVWNNTnZpVHErckhDc1luZ2J3QzVTYy9VajRV?= =?utf-8?B?elRJVUVNR2xjNXBuV2V3bUpMZXlCeVpzWkcyWnM2S2d0Qld3QWtYMzNSbHNn?= =?utf-8?B?YUMrdXNPa2dIaEpWUkpSR1FQMFYvYkJpVGFscXplVjVqdHlEUkJ0R2hqRTRV?= =?utf-8?B?WERlTWNRKytnUkZscmkxSFMwdDg3bXE5Ump1NTB2bUdibEVhOGU2QjI3RTdH?= =?utf-8?B?SkR5YVZNdFF6dzNUNEw2S29sOFBQY3ZYV3F4WU9vV0tQVzNBeFA0Z001ZmR6?= =?utf-8?B?NUlmMEEraUFkTXQvdmFiSDhlVkpET2w0Zm1XdzFUZzNtUmk5UTdRdHVOeUt3?= =?utf-8?B?MHJ5WHJMdlN3Y0Zoc1ZaaVl1ZkkzUVlzdzlMdlVNR2NIQkxCMlAzK0dwa0h6?= =?utf-8?B?UC9YN3kvSzFDdWdza3ZGMiswU1RVUTc0VWtweXFZZkExQjFXb3ZZb3lXY0Rz?= =?utf-8?B?VCtxUFN1T29XUkdhekQvWi9SaHdyY2g2R3BRVWZmOXdwOFR6OHdyeG9UU29C?= =?utf-8?B?Zm4zQUpQMGhVdCt5Nk1SYU1tNTF0ZUg5MjJDb28vOFVYdWY4alhRZz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 987d0c2f-6c3b-4fb6-98f8-08df23a57fb1 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 12:29:42.9618 (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: Tlc4Wq0ntOHf0S6u6IY3Wt0gAyzdF3RPbK8COBGqmuq5cLy+zW10nb/xWh/vwyhREmtMfh0PhWKwsfBos1H4hA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR12MB5597 X-purgate-ID: tlsNG-bad1c0/1791289789-BDEC6034-D876F640/0/0 X-purgate-type: clean X-purgate-size: 722 On Tue Oct 6, 2026 at 12:45 PM CEST, Orzel, Michal wrote: > > > On 06-Oct-26 12:31, Alejandro Vallejo wrote: > > While today they don't implement fencing in a way that would block > > speculation, once/if they do they'll absolutely need to be inlined, eve= n > > if -fno-inline or -fno-early-inlining are passed. > >=20 > > Signed-off-by: Alejandro Vallejo > Reviewed-by: Michal Orzel > > but this should be done for Arm, RISCV and PPC at once in which case you = can > keep my tag for v2 # for Arm. Neither RISCV nor PPC implement nospec.h today. Should I considered the R-by just settled for this patch? Cheers, Alejandro > > ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 06 13:07:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 13:07:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441494.1659097 (Exim 4.92) (envelope-from ) id 1xE4sk-0000Je-RB; Tue, 06 Oct 2026 13:06:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441494.1659097; Tue, 06 Oct 2026 13:06: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 1xE4sk-0000JX-Ob; Tue, 06 Oct 2026 13:06:58 +0000 Received: by outflank-mailman (input) for mailman id 1441494; Tue, 06 Oct 2026 13:06:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE4sj-0000JR-P4 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:06:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE4si-00Acg7-GJ for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:06:56 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4f26e-bab6-0a2a0a5309dd-0a2a45028844-8 for ; Tue, 06 Oct 2026 15:06:56 +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 6ac4f270-6ca4-0a2a45020019-d1558031c063-3 for ; Tue, 06 Oct 2026 15:06:56 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a1698ea378so5787305e9.2 for ; Tue, 06 Oct 2026 06:06:56 -0700 (PDT) Received: from LukeW.manchester.ac.uk (uom-130-88-226-5.manchester.ac.uk. [130.88.226.5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a03043fae5sm254460855e9.0.2026.10.06.06.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 06:06: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=1791292016; x=1791896816; 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=WFYOvHs1zHB2tYA6ImDHS5zPbAzxghlTOpxWyn9IDQI=; b=GArXisX0hHMK96EjcPYs2snlXiwxQCzet2xcZLMbuzDmzEFDQg30f22EFLHE2EVPeE dv5JhBFaARRR9yKN14P7vMPPby3FmNo5Yrxt/zy3ZOTUm7m7JHZcd5OvOVLbug1pXDnd 6i0BcmrCfRj5o5aotZMgCRaQFUqerqqTb+ucacWjLVXEqSprKI//+I4JqXAPjRG3nLZu xwhmBV4KAhCIqBi4mg1zCYNdtagxfsswyfQdmVUPp/KDhj2pKuu/slBEuRC5WtNOfVTC lzu0RKLCEUVn4X72idatvKS7TQlIj8v8gTvjZ+sWYDJx3gcDWywNQj9LWp0nqFe4K8YT 1wwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791292016; x=1791896816; 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=WFYOvHs1zHB2tYA6ImDHS5zPbAzxghlTOpxWyn9IDQI=; b=lM9MkzXxwaoFDo9fbgsKSqIXEJ0wWWHSDrKf4Gv6mdcOoZk4oOdA2kCUEA0WW7Zn+C rB5aca+MIP1pvNCe9bYY7cbua19jNTWeDqeVnXA3WiU47MEc6uQ972BAOPaSw+6ZXODy s0UEcmLcqTteSSJTjPPuzGwNngQt+6A59SQD0qY81/O69LCzl2VQ5tWDKta7/AKdBP5X joMfi6t6DTHMGg3bpXl8HXCfhdyfj+C/I2UAUeuz2X5X6UwVgQLZh7bcY+QPZH/XGW7a a0F9WmqQUie1WT2lVc/QH1cLaqr1qkDL1r6rqKn20w/PNrdcNFNb7YDAJfezyBT1F7+Z 1w4g== X-Gm-Message-State: AFuF++m1v7lvMnasmgmDU2XTbVaie4Qg46JovFa/bGrFSbcEBbCYNxqH kunI4b1QOMkHyA8a1rHAAbJWd2msCzFVG+8wlUt1wm6JDgVgdqPPP89zfLghcH1Ypu0= X-Gm-Gg: AYBFou3IpFx42KLVJttDbvjQDmavLkBhSK3CGvrVtNGA3JKkDFRmbE5XYZXtvbuFv53 v8CRkLO4O+/agbyLKoOgddMafikypOWunsUTrqzeAVGIhgcuexPoroGPhVgrleyC5ooAGGPXYAr sc0Jp3KTLEl1aaJd3MYMAk0Oq22ULW1jw5pyOEpXhd4X0yk/0PhfEphoZZ5ZctePywrgHBhv5y0 P7+iqHOrl1YRJKQECk+ymQuUH877XCfd4eULTpxZorCxwhII7dgefTtB2rzYbLALooFjtMtJ8Js dbLeZJ7yR6wShGIUF/8sF4z+Bo20cYuosLeU87N1QSMvKK1c8CVehsjj+Og9fQf3/nEBPSA4aAr XPC1bOfr6qHdJE/XutDGB0Dp78sbrrjdnZp76Zed/SqMFmy1zG+sPcwMZGrSgexEVVgTmqP1kNs dwjd8nFmoY8atCl10hAwF2n574RWv+PiWx8zJot+RmBlPsCoVpuv5IzE10iXwVFXCUZZv/9LP1m s5qwWIqJ1e+N2HAvU/FVueXC/8ttk0U/bp4oZCXk7uBV6s= X-Received: by 2002:a05:600d:9:b0:4a0:2391:6529 with SMTP id 5b1f17b1804b1-4a17b55241fmr25854435e9.29.1791292014912; Tue, 06 Oct 2026 06:06:54 -0700 (PDT) From: Weiqi Wang To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, roger@xenproject.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang Subject: [PATCH v3 2/2] xen/pdx: reject regions crossing a lookup table index Date: Tue, 6 Oct 2026 14:06:50 +0100 Message-Id: <71fe1a0cff0563db66df7f427d115fdd1953938e.1791291898.git.weiqi.wang-2@postgrad.manchester.ac.uk> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1791292016-30FCE2AC-0EA17957/0/0 X-purgate-type: clean X-purgate-size: 6148 From: Weiqi Wang pdx_is_region_compressible() only looks up the table entry of the first page, and checks the region against [pfn_base, pfn_base + pdx_region_size). pfn_base need not be aligned to the table index granularity, so that window can extend into the next index, which belongs to a different range with a different offset. A region whose tail lies there is reported compressible, yet its last page on its own is not, and translates through the wrong offset. Require the first and last page of the region to use the same table index. This can be reached from the coverage check in srat_parse_regions() when an e820 RAM range is not covered by the SRAT ranges, which is the case that check is meant to catch. Add a test case that fails without this change. Found with the ESBMC bounded model checker, and confirmed by running the failing case natively against the unmodified code. Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation Signed-off-by: Weiqi Wang --- Notes: Changes in v3: - reword the second paragraph to start with "Require" (Roger) - reword the ESBMC line so it no longer names a counterexample that is not part of the commit log (Roger) - add the reproduction as a test case in tools/tests/pdx (Roger) Changes in v2: - the issue is not tied to huge addresses (Jan): replaced the example with a ~5 GB reproduction and dropped the 2^51 remark This was discussed when the offset compression was reviewed. In the v2 thread [1] Jan asked whether pdx_is_region_compressible() is correct when a region crosses a lookup table slot boundary. The thread concluded it was not an issue, on the basis that pages contiguous in MFN space are also contiguous in PDX space. The case below is one where that does not hold for the code as merged: the region is reported compressible, its last page on its own is not, and that page round-trips to a different PFN. The ranges are as srat_parse_regions() would see them. The RAM range is not covered by either SRAT range, which is the situation the coverage check in srat_parse_regions() is meant to detect. On staging plus the first patch of this series, before this patch: region [0x4ca9b, 0x12982e) compressible: 1 last page: pfn 0x12982d -> pdx 0xa982d -> pfn 0xe982d With this patch the region is reported not compressible, and srat_parse_regions() disables compression. The test case added here is this same ~5 GB layout, checked through pdx_is_region_compressible() directly; it fails before the change and passes after. The existing tests in tools/tests/pdx continue to pass in both mask and offset mode. Other callers that rely on the same answer are mem_hotadd_check() and the EFI ram_range_valid() check. I have not run those paths. One behavioural change to check: with npages == 0 the new condition compares against pfn - 1. The callers I looked at never pass 0. Model checking (ESBMC, 2 SRAT ranges and 2 e820 RAM ranges, all free within a bounded address range, the srat_parse_regions() coverage check modelled) finds no accepted RAM page that fails to round-trip with both patches applied. It also finds no layout where the coverage check now rejects what setup accepted, with RAM equal to the SRAT ranges. This is bounded to 2 ranges. [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg194095.html tools/tests/pdx/test-pdx.c | 33 +++++++++++++++++++++++++++++++++ xen/common/pdx.c | 3 ++- 2 files changed, 35 insertions(+), 1 deletion(-) diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c index 6728ffc7a5..10c659b775 100644 --- a/tools/tests/pdx/test-pdx.c +++ b/tools/tests/pdx/test-pdx.c @@ -288,6 +288,39 @@ int main(int argc, char **argv) } } +#ifdef CONFIG_PDX_OFFSET_COMPRESSION + /* + * srat_parse_regions() passes e820 RAM ranges to + * pdx_is_region_compressible(), and these can be wider than any single + * SRAT range. A region must be rejected when its first and last page + * resolve through different lookup table indices, even if it fits within + * pdx_region_size. The values are PFNs from a ~5 GiB layout. + */ + { + unsigned long ram_start = 0x4ca9bUL, ram_end = 0x12982eUL; + + pfn_pdx_compression_reset(); + pfn_pdx_add_region(pfn_to_paddr(0x5bbd3UL), + pfn_to_paddr(0xf18f2UL - 0x5bbd3UL)); + pfn_pdx_add_region(pfn_to_paddr(0x1869bdUL), + pfn_to_paddr(0x189f58UL - 0x1869bdUL)); + + if ( !pfn_pdx_compression_setup(0) ) + { + printf("table-index crossing test: compression disabled\n"); + ret_code = EXIT_FAILURE; + } + else if ( pdx_is_region_compressible(pfn_to_paddr(ram_start), + ram_end - ram_start) ) + { + printf( + "region [%#lx, %#lx) crosses a table index but was accepted\n", + ram_start, ram_end); + ret_code = EXIT_FAILURE; + } + } +#endif + return ret_code; } diff --git a/xen/common/pdx.c b/xen/common/pdx.c index 23655ef3bd..52928faa15 100644 --- a/xen/common/pdx.c +++ b/xen/common/pdx.c @@ -324,7 +324,8 @@ bool pdx_is_region_compressible(paddr_t base, unsigned long npages) unsigned long pfn_base = pfn_bases[PFN_TBL_IDX(pfn)]; return pfn >= pfn_base && - pfn + npages <= pfn_base + pdx_region_size; + pfn + npages <= pfn_base + pdx_region_size && + PFN_TBL_IDX(pfn) == PFN_TBL_IDX(pfn + npages - 1); } static int __init cf_check cmp_node(const void *a, const void *b) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 13:50:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 13:50:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441511.1659106 (Exim 4.92) (envelope-from ) id 1xE5Yp-0008IV-24; Tue, 06 Oct 2026 13:50:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441511.1659106; Tue, 06 Oct 2026 13: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 1xE5Yo-0008IO-VN; Tue, 06 Oct 2026 13:50:26 +0000 Received: by outflank-mailman (input) for mailman id 1441511; Tue, 06 Oct 2026 13:50:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE5Yn-0008II-7i for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:50:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE5Ym-00573v-H8 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:50:24 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4fc89-2eae-0a2a0a5409dd-0a2a4505c62e-38 for ; Tue, 06 Oct 2026 15:50:24 +0200 Received: from [40.93.194.7] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4fc9e-4cb1-0a2a45050019-285dc207096e-3 for ; Tue, 06 Oct 2026 15:50:23 +0200 Received: from SA3PR12MB7784.namprd12.prod.outlook.com (2603:10b6:806:317::20) by IA1PR12MB8539.namprd12.prod.outlook.com (2603:10b6:208:446::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Tue, 6 Oct 2026 13:50:19 +0000 Received: from SA3PR12MB7784.namprd12.prod.outlook.com ([fe80::bcb5:6549:d82d:1870]) by SA3PR12MB7784.namprd12.prod.outlook.com ([fe80::bcb5:6549:d82d:1870%5]) with mapi id 15.21.0451.026; Tue, 6 Oct 2026 13:50: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=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=xWKC9gBRsUn8hMxW1tpc0YDkwbNEDuF2fAhMo/AHram75tHkwpiCinhJWA9Er4n5Y9FAQIkfxpdU4RLhxUa2Ih/4+1sw5RQhSMufz5Iig0o1dDhZxarIuudfNn++MqGuCK0OCcgkHHGd69CQPrCSCjbm4S2BRd1q0SMKy1J0BWL4EgfkMXm44no19U7bHIcpfQEHJwlFutiz3yQi99Ypo/CK/rVnktEiR0CYWf/TmoJp1zBYQDDdF6vdB1AAaseIs6plXlEmOsXHMuH5WNrWwciYLzESLrFGUmnvvbjxGAG3+FJbNFHuQBR0J/FC3eG6PII+GkTAk5akoE1/GodRaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gmC3Tqk8i2AEAulvzFKpPrk94evSxtynLJIc5VGWLsE=; b=H/Ksx+r1i/T4z4q45WfsmE0476AoX4E70KXDHDNVFIFlbLI5jtKbY345Pb1KFETnXStvZ1vrmMnsPb2xwun+KQR8KUrPvx/Mm0lRveW3Ado3zuydCMbo7ZIkxx0iUHt4TXrwNjRgPrgJL4iXFoHpkzJYhfTM7miHQdLisvUEIS65p5WOVnJPRFPc4doVd29iZMKAam0w1b3K0jyhdQm1lQezX/q3bpTPNmBbObtJLliUb1sJCXfNLwuIKxvRd7QTVBbI1OsPiRSeIZzKotFfCuGUvN0/jskgDNbPWhG0Zd31xS7p57rWFYGLjE6VRxfsSKpHx52OQCIiSAjm4pmiiA== 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=gmC3Tqk8i2AEAulvzFKpPrk94evSxtynLJIc5VGWLsE=; b=3bTS9596prU3O99Li7euCGkEkgkoC4at/ugIoh2m6zNzYJ4u01likcHF90Z3w2CVgqlT1ZKZzVYl7T3wgfvjsqfVX99ayZYee5+YiqTSlPhLPzmHbLypu4Pusri1lh3xrCwDy3b8Rudr2iXIJUT6rMJmNBHdVJTPUKGcZIlqdHA= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Date: Tue, 6 Oct 2026 15:50:13 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Michal Orzel Subject: Re: [PATCH] arm/nospec: Make nospec helpers always_inline Message-ID: References: <20261006103142.139422-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261006103142.139422-1-alejandro.garciavallejo@amd.com> X-ClientProxiedBy: MA3P292CA0044.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::9) To SA3PR12MB7784.namprd12.prod.outlook.com (2603:10b6:806:317::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA3PR12MB7784:EE_|IA1PR12MB8539:EE_ X-MS-Office365-Filtering-Correlation-Id: a0fbd3a2-c46b-44db-b36c-08df23b0c08f 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|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: fftjt7xRuNqiOw88D4DMhlke8/7IAeH4367ClNa15XmJU8oQm/+wT+n3i0dIm4n7YzGKJkKRkm8F5yXeCZuQFTBBcxRMtGixp3shc9qYZsk7PBj7jyz4x//yxiDu5h96gGcvGWzNjVWZSm+GIkyPSFShXeoxcZFkrfNzkFU254Kh0Fnrr9Zw0qK+VNjXy/OuzK/80xsqjAIG8S1wt2p6FSN3ii+jR4mudKRab4K3AKWKLWzbiOkvujc5IxI1xCEdDczpFnwFn+Mdv8mMpygWgiDEU5iVxjI7bg1+EMWe/CVw+ZZhQkiFk4rJpYqyvmUKRY6aQINT6T8jPRIooMq46HcpxdcLlVERn/JlfFGw9qjcUWDOgKDbWsRC9PRdLCDK73zJlV9rB6WM+oCS+7MGQynt6ZQ3S8MevOZLobCX11BiawhC++KpTjMzk428LKYGnRsIjbERdd6NJxQlN1kRIb2ts89LHCKEkJbBu+nybTr46OZDTZQzIHXFZ9IgAJtjyhae4fSWwxHF//mxMUEft37U0M/jnS1Na8JAiQ6KsJ7H6Hmjw5yxfJhOljSoOL6XMuAE326zoTaPuTT9GZPEBkyJnDk6CdnMtTR7aIK2ROTSOltq4Dr02cIz4EHAeC7/s7DNr5AzXFExWOJtE8/+3+K5GNhLAxCDe/aUDco6BMI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR12MB7784.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(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?d0s4RFBCK2FWNlZxSUovU1l1b3AzQjFueG90NmVNTmNZK2crcEZNbmJpa0Vi?= =?utf-8?B?MFVxSGV5dUZkY2c1Y0o1bHVYNkRpRlVkUGNPRVJpMlV5UVpZRXBXSWtzTVJ3?= =?utf-8?B?YkNoL2VSQjNHVEhaK3V6eitvZDdJOXVnclJVRTUwVDFZMnhwcWM4N2Z2SXBG?= =?utf-8?B?Mm51bk0wV01zaVBKMml5RGp5cmMzVlJjeEpQWnQ2YTUwbk41MExlZmhzVEVY?= =?utf-8?B?TG5iak80bFllZlFJb2tKMEFYMlM0RXkwaGd1UThMb1FYZnZXcndqaWhjMlFs?= =?utf-8?B?MjYrcm5leFFua2l2R3VGcEVVNkZPZnJmOWtoS3NTUEZRV1JxWXRhUXpYYXhZ?= =?utf-8?B?YzdBalkralZydmdqZlZSbmlZNXliSXMyN1NYY1JpNDh1dVl6ZVk3c09sQmNk?= =?utf-8?B?UDJnR2lDUUI4Z09uK29zaVNKc3BGMWRTWCtNeGNtT2M2NlFIc0VnRXhWUUJx?= =?utf-8?B?dTdDSDMxd2dTV3YzVU9tQ29HQ212RGpXWXkrZWpVWTg5dENVaG1nMWEyWEtF?= =?utf-8?B?Y0llZTZQbEFWSSs5N3NZcXJjanFEWGUyZjhDa1NBZzJ6RTB0aW1mclkwMVFH?= =?utf-8?B?U01IUmNiYmFVd0JteVJtcnZBWDlvQVZhMGtZSldOU1p2RXU0NVptS0pDSys4?= =?utf-8?B?UFZUa0ZGWHplenJCa1llMHhnaEdweGYya1NKTmJWbkpMS3FVNjY0b05rUUp2?= =?utf-8?B?RFdiOHIvdms2YzhzaitjNmJlRVVDcXlTa0UwbE1zeTlPNXhDeklaREIybjJQ?= =?utf-8?B?d1h3RHFRa1IzUE4rTXNHdXA0azhIQ1JIVkNjdUxJYjdrZk5zYUFSbk1wTEJN?= =?utf-8?B?OUM4d052cmQzaXhYcjBLL2hSMmlhVnRCeFA2S2l4aTdQMDFkQVlHYkUyY21i?= =?utf-8?B?ckFXNFhwSW1mR3lGb2s1MzZ0YU1nWnR0clA1MVQ1YU5RaDZ0bXZLWjNrTHlP?= =?utf-8?B?ZnkycU80d3JRNVA5UzNWbElkZlA2cktxdFlzUGNJSWNXZ2JNN1RTWmk0MVJ4?= =?utf-8?B?Vi9teEVUUWZkV2JZNHJBRVJIbUVGS3FnQkJqQktoOUFoU1JzeTFpNlVFTHBH?= =?utf-8?B?Z09OZDhBL21ZYmUrdXp2VlVySkU0Q29YL09MZVgrQjg4OGp2VTVaYlljNy9C?= =?utf-8?B?Zm8vVjdib2JwU3g1d2tRR0cvS0xRVGhiWXg2YjdLaWk1TXYvdUlxYzN2cnFI?= =?utf-8?B?TzBUL2pmMmI2YjRNTEZmN29yMWR6c2NpNXEyODlIZ0NtS1NLTDRDRHlwbXhS?= =?utf-8?B?NlpZdFRmcTJhbm9nRjAwS0dzL3oyYnNuZWhsS2hhblIyUXM1UXJlRExlWVBF?= =?utf-8?B?ZFJsbWk3a1FnZDBuU3hnRjB3akNuZDR6eE5xVGJ2Vmlpa3JWL0s5Z3I0SkNy?= =?utf-8?B?amV5ZWd5RTB3VUFyU2xkVjFOV25lR1BERUJNTFJpVE92djFKeGhkQ0l6aDE1?= =?utf-8?B?SFM3dG1TeGFzQ3ZvN2ptbDU5RGtQS2JJUmtYTWlUQWRBajZlb0E2MDh6VkV1?= =?utf-8?B?MkNMQ0pIU3F3NFdJbDcxV2tBamJPS2FRUE1hRHdVSWJ5V3hST01WdWN0MEV1?= =?utf-8?B?OVN6SHVUUWpBcDB4Y1QvTXY4ZEdBVWxZSUtqdVhXREk4Mlk3a3k0Y2dJU2k2?= =?utf-8?B?WTRScVA0QzdYZEFacThUWENxS0x2NkR4bUcydmwrSS9rZTlXRDB0bksrNG5N?= =?utf-8?B?QnJaQ0paZUg3MVpKeDJXbFN2SHhucVlaSTNNdnJkL2cxdk9xRkV5enJ3QUV3?= =?utf-8?B?R2d5Sk8wVUhDOU13Tk1QWmlVaDVHYkZkMlBEWWhYdWV4QTU4UVRXZS9nR0dJ?= =?utf-8?B?M2phNXE0WCs1cnlSZnFET1hiSUdrdHdZQnpKdzcxUTdnQk5jblArUXFGUTg2?= =?utf-8?B?cDJsZ2wrazF4KzJ1YnJPYnB1blM2cWNxVWxBa1MvQ3pUb0R1UDlHb2x3NWhU?= =?utf-8?B?REU5dEVrMVd1dTJPNjFCSnhuTDdxUUNJdEs2S0VycVoyWWsrUFRvUlA2M290?= =?utf-8?B?WFY1WHNHbUJCZWFlMXZvNzZOZHJOVEhVSk93M3hTb0Q2Q3EyZHBnaVBUS1RP?= =?utf-8?B?ZmNWcC9LUnR5TnYwTFJSTGRIVE9CaWc3d01sVmNiT1gxT3F1T1h5VU1FUVIx?= =?utf-8?B?UzlBUHRRM3M3SkdxbXZqbmZVdk9MKzdqMlpxVVZzanlZYnAxbWtBekx0eFVv?= =?utf-8?B?MGJ5YnpWcWdGcCswMTQ4RStTM2RKRXdNaGtMbS8wMFZTRWJvVEp3THVYQ05K?= =?utf-8?B?MjQyb05hWnNqN1dIRzNiUkNydEtFdEU0SVZoeFhENkRac2lod2lXbDFJQ2NZ?= =?utf-8?Q?5950WO79mj42/bJ8aM?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0fbd3a2-c46b-44db-b36c-08df23b0c08f X-MS-Exchange-CrossTenant-AuthSource: SA3PR12MB7784.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 13:50:16.5063 (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: yzig2SbjvTNsLNOhOM9iaT05oUX3HWS5FnxCm5JkbmJn/Hm5NM/FIBRrNKgBUC3rkidA+HenKtKBrUVgkkJiZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8539 X-purgate-ID: tlsNG-c201ff/1791294624-2491C2A1-1319990E/0/0 X-purgate-type: clean X-purgate-size: 557 On Tue, Oct 06, 2026 at 12:31:40PM +0200, Alejandro Vallejo wrote: > While today they don't implement fencing in a way that would block > speculation, once/if they do they'll absolutely need to be inlined, even > if -fno-inline or -fno-early-inlining are passed. FWIW, it's my understanding that -fno-early-inlining is not really relevant here; it disables the early inlining pass, but the late(r) one(s) is/are still present, so inlining will happen, just later in the compilation process. -fno-inline is indeed relevant here. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 06 13:56:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 13:56:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441517.1659116 (Exim 4.92) (envelope-from ) id 1xE5eN-0000hH-Ks; Tue, 06 Oct 2026 13:56:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441517.1659116; Tue, 06 Oct 2026 13:56: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 1xE5eN-0000h9-He; Tue, 06 Oct 2026 13:56:11 +0000 Received: by outflank-mailman (input) for mailman id 1441517; Tue, 06 Oct 2026 13:56:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE5eL-0000h0-L1 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 13:56:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE5eK-009Xw4-Tl for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:56:08 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4fdf1-bab6-0a2a0a5309dd-0a2a4506c594-36 for ; Tue, 06 Oct 2026 15:56:08 +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 6ac4fdf8-195a-0a2a45060019-d1558036c82d-3 for ; Tue, 06 Oct 2026 15:56:08 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4956869750eso5337895e9.2 for ; Tue, 06 Oct 2026 06:56:08 -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-4a17a0fc2e4sm68582055e9.3.2026.10.06.06.56.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 06:56: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=1791294967; x=1791899767; 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=/Dhuh/wtI0yX/Les8bDjamHrz/rhROiQMQkvk8Zx65o=; b=JIvSpl0O3CgdnS6stNsvCaYBrDY2D8fUXS5gpZGCHxT0cniaiGs8fTGZ4GA+RMldAx vPkzyCw1worWx2ydUFM4OPB0pdYVXFLj9J6hoFR7ADAWo9BusdT+cWUJYHPmtr/4GVj7 FAh4YcNvgVq53Hms94clWq/SY19OubZ/i+fkVRMxkvQGIxiSoiD3jfHff97/HgQOhMeR 1+PHPuxiTyMiK/oMkFQlm1TjdQDk7aOdGSUmMs/6KC4Ya6D9EJuqhtslLTF09OTxTkqT foC5ip5M92sbqO4NsXAizUJ17Hpnp7/cj4zGfRRAi1AYXusDW+vnWu1Olnn1KNv1Bxet HYfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791294967; x=1791899767; 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=/Dhuh/wtI0yX/Les8bDjamHrz/rhROiQMQkvk8Zx65o=; b=k16PHBwYMbZwVfCkKaqQGYqs6Q2kUmJAFZvAyiKf7aoteQOT0SFXdJzjbQgXsm/qM7 rGkywQWDtvuTdEazDK0yKgoMWPNGCBoJarNML3FxbxirwNuILk4y9ocPNXck0IJGNJnR J9t34EaSH/sC89rXhjc2K1Tli7PC+rbHOQwgylPqB6ZQUqGpJn561Iwo9rm0SEWuzfPs pngxvYn4unmnZ40uX0EU7B0A2m4ttqxb/vkJHyWOLFNP2Op6LPJPTnVYbXL529A2q5HR f4iceLaXuzccS22ohWJ/spjMKrRN7y1tsOoJi8S0QLIZpSBLHQbbElN5JpoO0RZtXoVD Cp/A== X-Forwarded-Encrypted: i=1; AKwUvBwv7/5BbpVvRJqeVQhjbO07jr8j8Uq7qKXViA60814yg6+OkHsPbzpphMp0MylNHWxVEyCpQMa7txY=@lists.xenproject.org X-Gm-Message-State: AFuF++m2ICzqU/amDt28AMKQAusBOgW9eN4zIWkZ4qu8gN4DZBTO8eHf gPvMRtDXG6EekHIRYWWlbPRHgc5QbYLEo/S3UaucLdlePXf0zme4LFRXueg3wn16rCc= X-Gm-Gg: AYBFou1CI44MJj1O4o9Wo8jvthY7R5Z8bNUqtAatER5+DYzrW/LtFuXwg3rGTHJEWOY OrbC+qucN7ZV+Y9QDw/m4yAgmN4Zq89VM0S0Vcl79DAh0IYM6rlwaySt6of2oeYEDdxRNsjpUl/ qP2pgO4y2itlKIZRHGzux4t52joJXB70ZrmZPqBoqng1u9fdgzPWhzqZKzKytL2yprYLFEJtVnM s4O1g8F3P3h3GxoldbqUN7UOGOb2NorTo/vyfgcepCLQG5gW3/K+exfq7jpYNhkDPQWlelWbRnV ctX/to+RsA9jGjMH1iX41tMVWZ6zFzEsEKTP+xCjfOVB4LCM2Zhi2WKcS3WkI3qro0I9HBWqp4d HMPAlgbEyM/WFb3qQM3z2Fpp6LbSkczDsK2B9TPYEmbpT6Blcq5LjZgx1W1G/g/lvVHScnYBBPe J+ZpzTEhdR8OfWMLbToib4qIyNOwhCTvjOkleiyHH1fchUvTd3ANLqhXtyMPjCRDk9qu+Qqtx98 iNGrCv1x8O7tHtBG1CLrsxLsegXUKUYrBX3iy2B2TbEtjtoywwAnZGDDY3/5Zesm7u6XXurXd5H zLqmX2AegmILDgVGkohQyCPQ X-Received: by 2002:a05:600c:5492:b0:4a1:6d35:779a with SMTP id 5b1f17b1804b1-4a17b4f297bmr27971755e9.3.1791294967343; Tue, 06 Oct 2026 06:56:07 -0700 (PDT) Message-ID: Date: Tue, 6 Oct 2026 15:56:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/scsifront: check for a NULL shadow entry on a backend response To: Yehyeong Lee , Stefano Stabellini , Oleksandr Tyshchenko , "James E.J. Bottomley" , "Martin K. Petersen" , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org References: <20261005123555.253995-1-yhlee@isslab.korea.ac.kr> 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: <20261005123555.253995-1-yhlee@isslab.korea.ac.kr> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------nnH7S5YuLqUH0yIqtmqXntAT" X-purgate-ID: tlsNG-16d1c6/1791294968-1F2C677B-772602FC/35/110847 X-purgate-type: clean X-purgate-size: 7844 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------nnH7S5YuLqUH0yIqtmqXntAT Content-Type: multipart/mixed; boundary="------------0I6v6BijZSEvEjvGrfeccWKG"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Yehyeong Lee , Stefano Stabellini , Oleksandr Tyshchenko , "James E.J. Bottomley" , "Martin K. Petersen" , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Message-ID: Subject: Re: [PATCH] xen/scsifront: check for a NULL shadow entry on a backend response References: <20261005123555.253995-1-yhlee@isslab.korea.ac.kr> In-Reply-To: <20261005123555.253995-1-yhlee@isslab.korea.ac.kr> --------------0I6v6BijZSEvEjvGrfeccWKG Content-Type: multipart/mixed; boundary="------------HscB0pQhO6alWtKX55NS0MMB" --------------HscB0pQhO6alWtKX55NS0MMB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDUuMTAuMjYgMTQ6MzUsIFllaHllb25nIExlZSB3cm90ZToNCj4gc2NzaWZyb250X2Rv X3Jlc3BvbnNlKCkgdmFsaWRhdGVzIHRoZSBycWlkIGluIGEgYmFja2VuZCByZXNwb25zZSBh Z2FpbnN0DQo+IFZTQ1NJSUZfTUFYX1JFUVMgYmVmb3JlIHVzaW5nIGl0IHRvIGluZGV4IGlu Zm8tPnNoYWRvd1tdLCBidXQgdGhlbg0KPiBkZXJlZmVyZW5jZXMgdGhlIGVudHJ5IHRvIHRl c3QgLT5pbmZsaWdodCB3aXRob3V0IGNoZWNraW5nIHRoYXQgdGhlIHNsb3QNCj4gaXMgcG9w dWxhdGVkLiAgU2hhZG93IHNsb3RzIGFyZSBOVUxMIGJlZm9yZSBhIGNvbW1hbmQgaXMgc3Vi bWl0dGVkICh0aGUNCj4gaG9zdCBwcml2YXRlIGFyZWEgaXMgemVyb2VkIGF0IGFsbG9jYXRp b24pIGFuZCBhcmUgcmVzZXQgdG8gTlVMTCBpbg0KPiBfc2NzaWZyb250X3B1dF9ycWlkKCkg b25jZSBhIHJlcXVlc3QgY29tcGxldGVzLCBzbyBhbiBpbi1yYW5nZSBycWlkIHRoYXQNCj4g ZG9lcyBub3QgY29ycmVzcG9uZCB0byBhbiBvdXRzdGFuZGluZyByZXF1ZXN0IG1ha2VzIHRo ZSBmcm9udGVuZA0KPiBkZXJlZmVyZW5jZSBhIE5VTEwgcG9pbnRlci4NCj4gDQo+IEEgbWFs aWNpb3VzIG9yIGJ1Z2d5IGJhY2tlbmQgY2FuIHRodXMgY3Jhc2ggdGhlIGd1ZXN0IGJ5IHJl dHVybmluZyBhDQo+IHJlc3BvbnNlIHdob3NlIHJxaWQgaXMgaW4gcmFuZ2UgYnV0IG5vdCBp biBmbGlnaHQgLS0gZm9yIGV4YW1wbGUgYQ0KPiBzcHVyaW91cyByZXNwb25zZSBiZWZvcmUg YW55IGNvbW1hbmQgaGFzIGJlZW4gaXNzdWVkLCBvciBhIGR1cGxpY2F0ZSBvZg0KPiBvbmUg YWxyZWFkeSBjb21wbGV0ZWQuICBUaGUgcmluZyBoYXMgb25seSBWU0NTSUlGX01BWF9SRVFT ICgxNikgc2xvdHMsIHNvDQo+IGJlZm9yZSB0aGUgZmlyc3QgY29tbWFuZCBldmVyeSBpbi1y YW5nZSBycWlkIHNlbGVjdHMgYSBOVUxMIHNsb3QuDQo+IA0KPiBSZWplY3QgYSByZXNwb25z ZSB3aG9zZSBzaGFkb3cgc2xvdCBpcyBub3QgcG9wdWxhdGVkLg0KPiANCj4gRml4ZXM6IDZk MWMyZjQ4ZjNmYyAoInhlbi9zY3NpZnJvbnQ6IGhhcmRlbiBkcml2ZXIgYWdhaW5zdCBtYWxp Y2lvdXMgYmFja2VuZCIpDQo+IENjOiBzdGFibGVAdmdlci5rZXJuZWwub3JnDQo+IFNpZ25l ZC1vZmYtYnk6IFllaHllb25nIExlZSA8eWhsZWVAaXNzbGFiLmtvcmVhLmFjLmtyPg0KDQpS ZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJn ZW4NCg== --------------HscB0pQhO6alWtKX55NS0MMB 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----- --------------HscB0pQhO6alWtKX55NS0MMB-- --------------0I6v6BijZSEvEjvGrfeccWKG-- --------------nnH7S5YuLqUH0yIqtmqXntAT 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/Ey8FAmrE/fYFAwAAAAAACgkQsN6d1ii/Ey8M DQgAn67Our2fo1bMCOV5O+3w37AmRu4L3TTxvToURAAHydJz7TJ3hqBD5FlZhLmX6LdxqaLWYwMO MS3mwgAUtulFRhkwVDuMs63dXLlRNgw0m9426pAPQ3lMva/tjoFsdST2KP0LXwIFspRvsX4dCVHy DlCGLpEeC40ybm7reCHJJBQshsVra+9Jxyer73TGy0vJgVs6qnrjQ1VnzbufezWmAK3Ovzy3Tj3v egMCT2rqTVWsBqXH+2GdbtR+XttYuxwnsYTnDSw5XMMAKECUC9ULqx+K3/Gexxl0lZFNCp9gG8vu xUl/Xqi6SXmtsnr03S4XoWbeHAnhlFgFiBiPkKcNlg== =UJPI -----END PGP SIGNATURE----- --------------nnH7S5YuLqUH0yIqtmqXntAT-- From xen-devel-bounces@lists.xenproject.org Tue Oct 06 14:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 14:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441525.1659124 (Exim 4.92) (envelope-from ) id 1xE5iX-0002NB-46; Tue, 06 Oct 2026 14:00:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441525.1659124; Tue, 06 Oct 2026 14:00: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 1xE5iX-0002N4-19; Tue, 06 Oct 2026 14:00:29 +0000 Received: by outflank-mailman (input) for mailman id 1441525; Tue, 06 Oct 2026 14:00:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE5iW-0002My-3Y for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:00:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE5iV-00Gu1r-B7 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:00:27 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac4fef8-e002-0a2a0a5209dd-0a2a450492e8-18 for ; Tue, 06 Oct 2026 16:00:27 +0200 Received: from [52.101.85.16] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac4fef9-b57f-0a2a45040019-34655510ef9b-3 for ; Tue, 06 Oct 2026 16:00:26 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by BL1PR03MB6086.namprd03.prod.outlook.com (2603:10b6:208:31c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 13:58:22 +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.0496.010; Tue, 6 Oct 2026 13:58: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=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=POMZoS6ntfaMquniUF6vy+olWi2ODdhTz779ZYjbPIRdgi8Ijh3lybfkgVJM6C9WkIA7EBKdWhDC/9r7enRluW9WsisZuiflxujBMXY+3SfBSM8VmDXbctgBvOhvPSmYKzvStPSoRDh9gCT/iSnNYdJ20bDvEIs28DrbB9AChnApHadzhJDBxuCSvzyYCnRNeAZhhwscubfnyOgOy1zEY7OMF1Sx+cJPRitErvXdf5t7FRxzSdhU7ynEsulzANf6YqJaTt9Pu7pI4Pw+ggXbIvD+ticMtDwPflj24ygSGBYDbSbXE4ILPJvc1JzDDybgRjPXWXe2ZuLELMQV9W08Xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lX8X2R1DDq8edidJA8juOKqxFOJ2vapFzb/jiC8u58U=; b=g6FyaB3lP2g52vrnKmDj/67AqfuotkRAnD6714EETNEbUd+eGz01DCoZcufwJ6E5Je8XmoCNAHK2qZpHAlc6VtlK0tktiS/ce0EQkjTGxNHVERprT+g2MWMg/YfEGBAlAgUqJ/nTAhX4tqfy6rdUrnNAQ6cVrdDVTVPoePFtcpzrNG72uaTmyaE2MMglCIUhhGHLsl/WheAI6SywYQFTcQ4fEbXGyd0Mc2x2HM4oOfdmqmRKoMm37ulgqgWxZ2mHGqfZEzuOoCMpON4/kyXNfvgOwlGAN9h11fzS8gglkRYPK9+WCXuSEnlfZfAnrvn1Kbtrfbg9g+54XsdVzYMqEA== 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=lX8X2R1DDq8edidJA8juOKqxFOJ2vapFzb/jiC8u58U=; b=sAc03lntszfRbSsCOosByqVmvmao5apYqUzIlVgvdKCp0jGGlJKSi7xklft0ZUVmQfUrltGC1cpzZLqmWBWf4+Orwg5YkEMp6JH/nW23aup0GFk9t2sQYAkA7dBThwb58rm83ai0TCQbjV+fb4fNts3D6OuKS+7PDI1QW7UHd3A= Authentication-Results: mx.microsoft.com 1; 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, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Ross Lagerwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jens Axboe , stable@vger.kernel.org Subject: [PATCH] xen-blkfront: Fix IO race during unplug Date: Tue, 6 Oct 2026 14:58:06 +0100 Message-ID: <20261006135807.2571779-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.55.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P302CA0004.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c2::9) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|BL1PR03MB6086:EE_ X-MS-Office365-Filtering-Correlation-Id: 829da2cb-2c0d-427c-b64e-08df23b1e262 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|10067099003|56012099006|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: L3M/Qb2JU21SdjhNLTGBgTacUclL0m/4MCmOPLo3LhwXu00OOFn2EP7mGimKtYdE+SwgFc8m2mO5ZWHlSn8qOtlTZqmyVP8dekWVv+kSqeOtpD5FOJIc7eO0dISNR5ICVzWhGAeqBbzY3MDzR75sN9E5B8caYDgU2GdT28G/SCjkL5II+m1sxnqKFIDs3DODR10XkHZhnI7KV1MZwC0Gmb/dKjYtjKrh5S/zjy0VjjiGFdsT6gvYN6vgL5k9gDegRr/A88BSXmo5UfAyG0QCAhhCEtBUGz0axyyveo7PBkJ4iUmD8kssyy4D+upqu5HNT0OLu9dg8O3bl+sxPd1hOhRtXrmXH3lHX0JtrqHGH+NQQM6uIXZhwmEPIX6Z4WXn6oKRc55utVau0bUE4aIeph0Xzpk3gNsyCi9UAQim/j90Tx8INajK886g61xai3phuylhjg185oLK9vRRPt55AMDpHnQv/QJF3U5OLE5thgf42ftE+NSri8nZdwSgmBMnKOOBnwlkaKftU040mKxEsxq7C9CbpeYQTZ/VsVVfIPr6gzXMCK4MS+crNNhWGLOdgsSVgsyt01GK/QcPgLvQ6fjfcRDqiqdwyFks/qRKxDtx/fyKpDcb26ICF7HeBshxQsBpSbn/yrzEvlE0CCwUGwkSr9HJNsec7o1rNTrOKns= 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)(10067099003)(56012099006)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?l5MZ5bTFcUntVBoYYTGCZYOuO8iZ1FqmTddfi5dpm1+G9RvmXFu5UHT0Dsz0?= =?us-ascii?Q?Uygghsa09PFz2yXuuOv/ddyEJGeI/vChlg7D/htlIVoC6N3YGmnVjHN+YgsD?= =?us-ascii?Q?Y6F2APlKk0UpBEZVumCCTOsS65gDVN7Wetgze9WNjefAgzDMnocIiBt8NNZf?= =?us-ascii?Q?xekL+ey5ttFPZj+WZ70hwQibFDRJMuPMdFK1/CvIbSiNcT1BLmJa1WKAnFkf?= =?us-ascii?Q?2jPDqq7lIGEnNIHyELiLHDfDOZHx8WWgYTWmfD/P6MFPCoJZnxMgDFFhh9I+?= =?us-ascii?Q?f44WbCrD/YGzeGvOD24lBqlqozg4WjMuKPBCsvUpRheGA+mfrMi9Kes8TB+V?= =?us-ascii?Q?YQIF88Gf8nC7tyEYRhqCrVW1gKuFmm4tqaARSOyz10w6yN2/TA9+BF1JiKqC?= =?us-ascii?Q?4XWx5Z9K6QTBM2s2+yAhRtBU7qRx+itIfJu+wgjjfaUMb40lHc0Fp68bngfR?= =?us-ascii?Q?dO/HTwD++r4BjKt62U1BgIdW49xa6nH0QJeBcdmZT5bfaCTFXIMp3Q/bPydJ?= =?us-ascii?Q?vA6D7izEgVZ9zq72UKyKmUZyrk+rZSrmSCazkBCIGTVetHfh0PjZ4sdaSfmk?= =?us-ascii?Q?y/YM5pLm8rdIuhklbtyozje5GyD5hfNSR8popccBFcFHeoI8SvjoyKx4UrBj?= =?us-ascii?Q?hOa/ZXYcELkdW9rDR99/5ZNloLZCelHmhCj6x/bXrDhz62NEMMXdjiHGoEUF?= =?us-ascii?Q?c5a3WNdpGKfMIdkSfVlGmStr/G3t5eSlQshBf3poO2U/SJxTTrvKq59PxTCg?= =?us-ascii?Q?IAE59yHbPNppIzEw1nw+JvOkixEo+oxgwi15k5wUzzGc5U2BixcmXcXgLgu7?= =?us-ascii?Q?8b49WmMUc8KJ6iQoN5pexxYMoGPMc5/c+Z+IElkM6pItX4VASd9SkOi/H2VX?= =?us-ascii?Q?SqxRYCu02E+dGO8tXEhtSfZhyAFws9HIIgF1mlMy5XVn7H6Iv9BguYNFbDt6?= =?us-ascii?Q?S/Kqv1DOMYDR8pOLKSC/53VIz8w8NjZAngmRL0VcrlRRW09zh26lYE3wq5WT?= =?us-ascii?Q?i61lvgNK/K6Z4PODaCmg1o+KBl/ggVFk4NDoBJGDVi3fuOffRMvSKyY6EiXF?= =?us-ascii?Q?cPh95DddsZgkaLcolYaqhVZ5J8oSxG/7bR9VqJMcnaTXKfs7GXofB8tyb4/u?= =?us-ascii?Q?QIX4YZhq8o7knu88sksRVoOXv5pMX+GSTs1tCOJuVhGu65NVxr0L0dJmVJrt?= =?us-ascii?Q?2HmMwHX1tgeYANDlDOrvvXp3A71aCgoKZHH6Yo4FO8G3W4E5+5woK11iw4CO?= =?us-ascii?Q?ofYL/lzoLC/bUAOeIyR33JWV2bd8JRHY9DOam3ORD9pMNMDpZPspqb6Sjuu+?= =?us-ascii?Q?ClGVzQWtDdq4o13FDZkmWPFF9ie4CbiEqUS/CcPjUXjKb9OrSfMH6tK+CxP+?= =?us-ascii?Q?Rk+GOsNXAiUGkszsBxSvZkK1NyhXOtDQnZ/DI0tZpZoouQCdvKNB6rGOnw3s?= =?us-ascii?Q?8BlrzzPAyDVk88Un6KM4SiIPo54/ZlCJpA7ESYyI+QPFUboUW3SEfc/kJbc1?= =?us-ascii?Q?45OOUQU4yaE6Mdzxu/gjTapSMtmL2KuGa7cZNyp5i/0HRBtANNGk7LGe07H+?= =?us-ascii?Q?lsFFGVgxHO6CKFMRQs5lakB5spgcEwbnKdw7DKTcimqfKxPVIO4QD5t3y5/F?= =?us-ascii?Q?A9Bvr8dHRHzq2qECiWIT96iw8vH0x5v73KsMAyuey7aoDMXc+21XVQxDmUTB?= =?us-ascii?Q?NEpXlJCY5xEMtjmFoqsEpyh0yDZLkTsN0u9yXrPkrdGbGWxODSefdhiNM2KB?= =?us-ascii?Q?43sjE864174CriJgfRR9kOBcQ/uD8dM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 829da2cb-2c0d-427c-b64e-08df23b1e262 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 13:58:22.4995 (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: Re4Fg4Jp14KLzr5fnXUK6HX8M18IRnUs0rKX/As7+q2sre9AiKvOkT3kuvcsufFDGjoQUgncXVPkn38Kuj1w/QPgv9hXtb3pdz/7kM0iumo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6086 X-purgate-ID: tlsNG-ebf023/1791295227-538C1B50-0788F003/0/0 X-purgate-type: clean X-purgate-size: 1611 During unplug, blkfront stops the hw queues and marks the disk as dead, then later during removal calls del_gendisk(). However, IO issued after the hw queues are stopped but before the call to del_gendisk() will be queued but never handled. This causes del_gendisk() to hang forever waiting for the queue refcount to drop to zero. This can be reproduced by issuing IO during an artificial delay after stopping the hw queues. Fix this by simply not stopping the hw queues directly. Marking the disk as dead also freezes the queue which prevents new requests being added and it synchronously runs the hw queues to clear anything pending. Fixes: 8e141f9eb803 ("block: drain file system I/O on del_gendisk") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Ross Lagerwall --- I'm not sure about the Fixes tag. It's the most likely looking candidate to me but I didn't confirm whether it actually introduced the regression. drivers/block/xen-blkfront.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8dad7bf5f664..69a2315a1b20 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -2138,10 +2138,8 @@ static void blkfront_closing(struct blkfront_info *info) return; /* No more blkif_request(). */ - if (info->rq && info->gd) { - blk_mq_stop_hw_queues(info->rq); + if (info->gd) blk_mark_disk_dead(info->gd); - } for_each_rinfo(info, rinfo, i) { /* No more gnttab callback work. */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 14:15:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 14:15:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441536.1659134 (Exim 4.92) (envelope-from ) id 1xE5wk-0004qd-Cj; Tue, 06 Oct 2026 14:15:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441536.1659134; Tue, 06 Oct 2026 14: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 1xE5wk-0004qW-A0; Tue, 06 Oct 2026 14:15:10 +0000 Received: by outflank-mailman (input) for mailman id 1441536; Tue, 06 Oct 2026 14:15:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE5wj-0004qQ-Ay for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:15:09 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xE5wh-0004Wq-2i; Tue, 06 Oct 2026 14:15: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 1xE5wh-00CcPD-1V; Tue, 06 Oct 2026 14:15: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=okmclJRF1nfHx7FuFEK7SpCGpSWkeD/ZoJo0CdoObYY=; b=XsmRSIuwu20k6VAg1325KMHecr rKy9zx4PwtiLvCMT8/W2aus/0cH1s+AYEnHQwLmq/NARJaO232XKtqg1nNWjR9w0Wi4+FstzPXj2e 8o5REMrrdE8+OxK6dWsgVU++cWqXcV7o7uYceNpx+Fi3gDJQWVrf5l2nCXuTZiOPbe6s=; Date: Tue, 6 Oct 2026 16:14:58 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ross Lagerwall Cc: xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jens Axboe , stable@vger.kernel.org Subject: Re: [PATCH] xen-blkfront: Fix IO race during unplug Message-ID: References: <20261006135807.2571779-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261006135807.2571779-1-ross.lagerwall@citrix.com> On Tue, Oct 06, 2026 at 02:58:06PM +0100, Ross Lagerwall wrote: > During unplug, blkfront stops the hw queues and marks the disk as dead, > then later during removal calls del_gendisk(). However, IO issued after > the hw queues are stopped but before the call to del_gendisk() will be > queued but never handled. This causes del_gendisk() to hang forever > waiting for the queue refcount to drop to zero. > > This can be reproduced by issuing IO during an artificial delay after > stopping the hw queues. So the window is between the blk_mq_stop_hw_queues() and blk_mark_disk_dead() calls where requests would be queued and never processed? > Fix this by simply not stopping the hw queues directly. Marking the disk > as dead also freezes the queue which prevents new requests being added > and it synchronously runs the hw queues to clear anything pending. I think this likely needs expanding a bit: the disk is already marked as dead with the current logic, and in the same place in the code. > Fixes: 8e141f9eb803 ("block: drain file system I/O on del_gendisk") > Cc: stable@vger.kernel.org > Assisted-by: LLM > Signed-off-by: Ross Lagerwall > --- > > I'm not sure about the Fixes tag. It's the most likely looking candidate > to me but I didn't confirm whether it actually introduced the > regression. I was wondering the same, and even then someone might argue this was a latent bug in blkfront itself, and the reference commit just exposed it. I don't have a strong opinion. > > drivers/block/xen-blkfront.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 8dad7bf5f664..69a2315a1b20 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -2138,10 +2138,8 @@ static void blkfront_closing(struct blkfront_info *info) > return; > > /* No more blkif_request(). */ > - if (info->rq && info->gd) { > - blk_mq_stop_hw_queues(info->rq); > + if (info->gd) > blk_mark_disk_dead(info->gd); So blk_mark_disk_dead() behaves differently when called with the queues still active? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 06 14:23:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 14:23:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441543.1659143 (Exim 4.92) (envelope-from ) id 1xE64q-0006am-4r; Tue, 06 Oct 2026 14:23:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441543.1659143; Tue, 06 Oct 2026 14:23: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 1xE64q-0006af-1x; Tue, 06 Oct 2026 14:23:32 +0000 Received: by outflank-mailman (input) for mailman id 1441543; Tue, 06 Oct 2026 14:23:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE64o-0006aZ-I9 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:23:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE64n-00GDKV-QS for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:23:29 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac50452-bab6-0a2a0a5309dd-0a2a450aeaa4-44 for ; Tue, 06 Oct 2026 16:23:29 +0200 Received: from [40.107.159.113] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac50461-f2d2-0a2a450a0019-286b9f71681b-3 for ; Tue, 06 Oct 2026 16:23:29 +0200 Received: from PAXPR03MB7531.eurprd03.prod.outlook.com (2603:10a6:102:1da::11) by AS8PR03MB9560.eurprd03.prod.outlook.com (2603:10a6:20b:5a8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.15; Tue, 6 Oct 2026 14:23:20 +0000 Received: from PAXPR03MB7531.eurprd03.prod.outlook.com ([fe80::77bc:127a:5664:10e]) by PAXPR03MB7531.eurprd03.prod.outlook.com ([fe80::77bc:127a:5664:10e%3]) with mapi id 15.21.0472.016; Tue, 6 Oct 2026 14:23: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=NT4ytPG+BkKkMz8EuA3XVt0lI8dhYmI5YCH08kt1KUpevGEnaEZYKRjLlx6XLDqW6y5SR8XeGjeRgRGskZ9f8W1TKMDFa8zz/ApYOvT3WV2nGEeaqGn/jRKMtstLsFGu5yYuMEZeRl8R21e9D6oq5ALy+Du+frVSmT80sbWqfMIVhxYlbh5VqCPbtgh4mHa9MuLwhSeRTdEfcNT1Lx1vOtSOQQ0gLlbZ5d4Z9Z01sU5CKKM4bc59CyKiy6tf2KL51IlScpdqFNSugvIHpXYOkkt4dgSVnhmIuYS+/HrKFORXqr1brBew9PkA/VBxoWG5BODilUvjXyFV29JMGOXq4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CgShQoPWGyW24mcGZ9e2lq1F4W3v9OLSLZhEXQO5kQ4=; b=P8i4Vywt7ca9ucRD/vyyuF5Fx7gL7bALW5DhDuXX+bohzyPqKmX20Pn8ujIB7HQ/LfjNh3nxmdN/4GLsVMPQ0Lf5roXYSZLWWqTo+o8e2pdTPmPf/TM+UTdLAQC1l5T4pd1Rv86iC+sIODV5NUjPGkPPw1m5Z0JUZ5DpUt6Twn1GNauFzVBRSCzQaTdIIodEIkbaAWgzmoX3g+tllB4Nkkp2/S7SYgyH/BtLX3CvhVySjuERWE6IIz/yABOQ8EK4VvViAa39Jvki3uPTIZ1WRmZCCMk+oEn08ho6C2dHyY+qqpU6Vx/3kewodH8EgZBLxC9CCvFjMJ3/PT4Githncg== 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=CgShQoPWGyW24mcGZ9e2lq1F4W3v9OLSLZhEXQO5kQ4=; b=s6gfbUzV7TEaZcsab9SOY6UTniHC7vqDDNzf6pVztBhZYJh5AQIcYd/pWRVDJ8Z5rSkmdtEevGCRnTNBJUTqmU5nLs0jjD3wMBFfBaYgP8cGYCVgiXY6eXIU5GhF4svTIofL09Xp2JAD1wceeW3epwUHQ8IuawYHGFDY3/qtzF+BqKcgni1mvmGYDfkdAQcVXEilH2W0RUeGiQ1cXrAQfOAX4a0F2tUdqOCMJz5cQgkAUh4I0GM9giigC3wa02+UmKcFgzkKCGcu9+xP9BoyAaEbeRnanXo3JtLYA13B3pJb+PuN8Pxb8gG5tjxUz+pfKUCfCEGeVXZn7LzkwMeCRA== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini Subject: [PATCH] Eclair: scan the last xen-syms linking pass on Arm Thread-Topic: [PATCH] Eclair: scan the last xen-syms linking pass on Arm Thread-Index: AQHdVZ47rgN8qfc/LUyZracn12XLUw== Date: Tue, 6 Oct 2026 14:23:18 +0000 Message-ID: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@epam.com> Accept-Language: en-US, uk-UA, ru-RU 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: PAXPR03MB7531:EE_|AS8PR03MB9560:EE_ x-ms-office365-filtering-correlation-id: 82a0a59a-26c8-45bd-dc93-08df23b55e3d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|42112799006|11063799006|260925021911599003|260925021311599003|10067099003|260925022911599003|56012099006|5023799004|18002099003|38070700021; x-microsoft-antispam-message-info: ZMQZ3uQBE0srj6aEmqHQTP2iJYPCkpNcvuqF452JdMtKjZ1i72uc4bdN+9ak6TW19JEgPBrefBwhpEwNUNoaAig3wN0VgM4aYjKr3ZI+lCf8P/+213WKUEk4q3oGcGRXUoUbF5GFBrtyYp6Whs2FygYagPJttZXPiEkwsOdrVTIkwtJLb6yQdwI8sEeBcd/jBZzgJwzn6dGLn5VZZeI6TGXd1CfDwUpN9t3iL0d1B7zBBDv/TviuNdXySEwcIoD27ScnkzeXZF80m9p/2DdXbGlwiFua98fwYaRzI34I+XaN6x8uaJBnUkLZWDvrdC3KpbW0j2e86ER21MTLtIUs0IGGUAebzhGYFlKxXFZdGslzeazrFxddJHVEj6MR0iuFyTDRpz/wX5vKh1E7xi0lB+JBkqF4D+azsFXqu1HFx5sfN9JiMkDAtJucXafyPcNoj9GrU2aV7keygYyC1qHDUmbeCWkIzthzYDVm2AYinluC12smD2QTqucLo9UPjdb7TSo4UvnjahOF4R853XehAPwHKT/xXp8JzkJ7Ku0v4BP2iD7RbqCoZpEEkx9dipjdIbfGMzb0UN9UKi5A4fUf3mTT5AMbR0mrDJdc7Is4YPeOVMY/3kYOyL1rjUcM+xfLvOyB/E3hSpItttC9WXKF3lf/kB4MtFBwwvq4nLaWbGDZwx/dZC/rx+2WhIkBj/eb9ROfp0Oq3f876zoeTI9L9iFTryJxJIM2TngpbFCfbvs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAXPR03MB7531.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(42112799006)(11063799006)(260925021911599003)(260925021311599003)(10067099003)(260925022911599003)(56012099006)(5023799004)(18002099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Z0Dr1aTkMhrLj+jrpgXB75zSMmY75wX62DasgE6IY/83KTJItULXbe3lT8?= =?iso-8859-1?Q?WgpnFJoDYDhGPiCmPgQxUrn2F8TXJzOBey4luL6PEMbwIFMyp9FPmWKpt9?= =?iso-8859-1?Q?KOTK/zGbj20tfrY1edQHuqFVxaZNBJm0E+PczmJu2z4Rmhz1wM4WBMzvXH?= =?iso-8859-1?Q?daVHdqHgqvVWrz1YRI6diQEg3+9dHw7Wm01IfXhNTtUMLXV3wxfVoy4tOy?= =?iso-8859-1?Q?7P1uind0vOr5NQ5bCYzbdF5QxXhtbdS1lUqNJve4fmAoEC3meD9QevhG17?= =?iso-8859-1?Q?RLtNO7e4SVjCqX6puHMYSENEBu3pTtbhHiitTKWxPGwqBfDcEd5WXwvURh?= =?iso-8859-1?Q?2I3JmrKPDkoBWezwzn3+msQS4luNga122K8EZK4Z+yVWROtWepGBk2n2TS?= =?iso-8859-1?Q?L96V7PehC7HlB9UeREDafMMCSQjq8XxTefOyZLfbyoLKBcmUIai/LO9QNP?= =?iso-8859-1?Q?9vZLcynxDIz9+pwKTyPBDiU08w0Dd12gewWVN0TqKeQk5XFyEjF5d99hsx?= =?iso-8859-1?Q?B6S5YGIRkRqwK7n2USGUlK4BIkelGbDYSNAo0zaCrCwM4ollqu4LifF0Sj?= =?iso-8859-1?Q?iTwhTzWSaXrT34ZUR8/1F/Brve1O+QePAas+rX1RWQP00vMavHBjB84w2i?= =?iso-8859-1?Q?BGmqDOz0zIK9ZXd3Nf0yjlA9zzeFlqmWpGyBAPMwUK5OWXwaP/BVnyy07e?= =?iso-8859-1?Q?PxeHDPD2FxJ95wkBAHR04WEi0GIEdqNZuDoFno3ITPcG2mfGdtPc3paSU/?= =?iso-8859-1?Q?V7rCPW/bzQK/vZCRZjQVyEraHo+QuO9jyv1pcVKt20LQ539wbH9KezPlNu?= =?iso-8859-1?Q?QQDRf7GO/BzfnKpDNk/IPOSt3EPl8gMzwqVxt0s/iMHz6nxc4XldO8+sWC?= =?iso-8859-1?Q?/NWqEYaZzychZ4H6+EfpPwxg8TjMbfwNA5NOKPjxUVg4Rdw8VjMk0t6LkV?= =?iso-8859-1?Q?DUCBPIts5/9BxdtDfNdFo49VVdLQwfrxk5l2soz0VkD2eqaWslMXjGi4Yc?= =?iso-8859-1?Q?4l+0R51fKfpjPDmCMXQUxxc3f+8cmgO8ibDhLwtDGIrO34/KcLEGDKD3lA?= =?iso-8859-1?Q?TOecHvfmYsPzLr3mdJ4xEJb9PhKBjALaXt/t+rLmJsOF4BCHcPnPrISA2N?= =?iso-8859-1?Q?1q+c4orwXqIpbCU1dHkbzQ6p9sAmh/UiigHYbp3RGxfgX6YPREp0MrH8G0?= =?iso-8859-1?Q?eh2kAVsZ34Ys1i5U1jYjyQDg+hSwmeURcjjBp0ITAb2H1kEk6t2aRhy0tA?= =?iso-8859-1?Q?ocfm6iGYdVErq/mN8buW0G2TewM97vKK26jCstRa8ZASLy8JezhqY3bKN1?= =?iso-8859-1?Q?ljeWDIyqitfx0z79T1rmBDw/SauDES5YLBBgwrpVihghyfo8KL+gNJriSv?= =?iso-8859-1?Q?WWIfePRj68OiUyFG9d4B1DUxhHMxjV6nZz1R8d7b3HF9fDUSbe7jCr2MU+?= =?iso-8859-1?Q?E8Ou3LxZl4DwyDSVRuOc5i/rSzRFHwiTA/DtNBL5kDNZM8KGwPYrhvqg6n?= =?iso-8859-1?Q?NjJQw6xRx3tLaL5nyxfMALsDOcrvziGppQB5siHm33CWIEc3YA/GNwydH2?= =?iso-8859-1?Q?8YryrKdpBo94lg43KzqcQkQgQR2o86h8SWBCyAYKIlBb70xMFYk3MeahI/?= =?iso-8859-1?Q?/+DX6ScOIUskc3tv7sqPhYhjGr7Gj5E34bzWKFpxIwrqKGLkkYYujMeT08?= =?iso-8859-1?Q?P7B59kQA1ejPeTDaCwniePwuwO1eo8G6w3NB+PQyAO9sZl6/7+5qQS+E32?= =?iso-8859-1?Q?c97GRJ1+9stZNEbtmyGP3weIiMf6ihNwmEkHmR0uy2X4WOBeX/2/NlTlOV?= =?iso-8859-1?Q?w0/Ulc+JsOMXyCguYbfj3wA1sWFLfIY=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: PAXPR03MB7531.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82a0a59a-26c8-45bd-dc93-08df23b55e3d X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2026 14:23:18.6753 (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: lcpXjyhgzJMVaPU4k6sp1oppUrPKX4gSYjlVDvWTgM1fzG+bkt/9RftBQAkH0lS3c48uSZOatD5HuDHmyPIzvrzKztjQF8clx11w89sTo7o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9560 X-purgate-ID: tlsNG-4011c0/1791296609-52ADCCFC-686E0B87/0/0 X-purgate-type: clean X-purgate-size: 1771 Hiding .xen-syms.[013] assumed the almost-final image is always pass 2. On x86 LAST_LINKING_PASS is 2, so .xen-syms.2 stays visible. On Arm LAST_LINKING_PASS is 3 and the final image is .xen-syms.3, which was hidden. Pass 2 is usually only a symlink, so Eclair saw no program link and reported every translation unit as unreachable. Stop hiding pass 3. Passes 0 and 1 remain excluded. Fixes: a401b5c9dc35 ("Eclair: re-enable scanning of the (almost) final link= ing step") Signed-off-by: Dmytro Prokopchuk --- Test CI pipeline: https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pi= pelines/2918036491 --- automation/eclair_analysis/ECLAIR/analysis.ecl | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/analysis.ecl b/automation/ec= lair_analysis/ECLAIR/analysis.ecl index c6e1a7a95d..4078c14a3c 100644 --- a/automation/eclair_analysis/ECLAIR/analysis.ecl +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl @@ -35,9 +35,11 @@ their Standard Library equivalents." -doc_end =20 -doc_begin=3D"Do not analyze intermediate linking artifacts, as they do no= t differ from their final -counterparts for the purposes of MISRA C static analysis." +counterparts for the purposes of MISRA C static analysis. +The scanned xen-syms link is the last linking pass (.xen-syms.2 on x86, wh= ere +that pass is final, .xen-syms.3 on Arm, where a further pass exists)." -file_tag+=3D{xen_efi_tmp, "^xen/\\.xen\\.efi\\.([01]|alt\\..*)$"} --file_tag+=3D{xen_syms_tmp, "^xen/\\.xen-syms\\.[013]$"} +-file_tag+=3D{xen_syms_tmp, "^xen/\\.xen-syms\\.[01]$"} -frames+=3D{hide, "kind(program)&&target(xen_syms_tmp||xen_efi_tmp)"} -doc_end =20 --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 14:26:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 14:26:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441549.1659152 (Exim 4.92) (envelope-from ) id 1xE67F-00075z-Gn; Tue, 06 Oct 2026 14:26:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441549.1659152; Tue, 06 Oct 2026 14:26: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 1xE67F-00075s-E0; Tue, 06 Oct 2026 14:26:01 +0000 Received: by outflank-mailman (input) for mailman id 1441549; Tue, 06 Oct 2026 14:26:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE67E-00075m-73 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:26:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE67D-00CQSk-K7 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:25:59 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac504ed-bab6-0a2a0a5309dd-0a2a45018224-28 for ; Tue, 06 Oct 2026 16:25:59 +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 6ac504f7-5984-0a2a45010019-d155dd2be431-3 for ; Tue, 06 Oct 2026 16:25:59 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-48b0ef9c76eso2645874f8f.0 for ; Tue, 06 Oct 2026 07:25: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-48c6228d948sm10016500f8f.23.2026.10.06.07.25.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 07:25: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=1791296759; x=1791901559; 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=w0XrXL3ix2wzt12ozCR3hhZOlExIpLHth1wjUxti/TA=; b=Z2B2r3WfwqCr1I2S5LgvSuEZJl8dkFJJr6fY62bfedRO820u/T9jmL6NDuXhJglriL MKYYfjk4utKrj18gfFbIADLF+i1WUEpahZ3KSw430qbZmchzTO8BolFxp6ghk6SW4S0X pELp7sBEgoi+MutgzST6tjginbO0o/Smx3c5TE0EcRhMGUirXFiIJupcz6WmphcCmcTP mp+WXS0KZRyoT2zOAr4v253xVhT5+Cb/juW4s6GkZQteV4ewTfGIzV8kq559kny4MSXD gfdSbRIZq8HYDsKoKP4tDGyq0AeNPA1bkizjAf/c+AV9IC7/XiVZ7D1tBTQaQvMPfrpN vLPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791296759; x=1791901559; 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=w0XrXL3ix2wzt12ozCR3hhZOlExIpLHth1wjUxti/TA=; b=fMolFVyczsyNYXWGzjoQVsf5zXeXS/AAdACV2TWMUlEUdkHxO49jL6AiCTwgmblP9Y c4tVO+FBIoBgBDFUTOj0eBM4JgY7opEd8RfLlx0XGKp2Xje94qhoagMdX7QaXVxc2Nu1 +d7s875NNhF1kob1y0vnpsAvLN5IKxaGioqW5w1HjZ7QFCzqHxmz4EBDGEEFNHfWxBSH SeJ6tjxYrkswH+OCNq9ZKqsqf87FwLPIn/hVEXTARH17svEXeoGUQOyJqYv/jBOWP6Q5 zZn+44fWVJlnAv+gjvN3U2uT+3pvLXeJiGV59HU5pJyJg/wRejXyhZMQDqsOdGZaw6NM oqWw== X-Gm-Message-State: AFq9FYKBLAAyLH/pX6YOMOGk0an56kcjy3lUCOh3p6oWxcJxWTXdBBwN lGfFGAxMMRTKGOaHvi6VqE1IKDs6g/Q4bDX37u0hlqe7jxPNs14gghBjjCLokw== X-Gm-Gg: AYBFou0URIP0IcmGaCARAAJGICAWHiHR4zmgfkUKCXd7cXIhB3jEuJ399rUOQSsNny6 C08hmpS2kww39dIAN86uLW4++xlc9UqXg00Keutw5nH3RfWemEUo2FblgC9PxkcmQBaa1pCUK4v VUPb2++5hLXW1B3gsDE1dQ3Ze6TYZ57g+HO0wB4yWOZsLMutTqBd2njCZEye/NcQeBjWlAMfsuf IjFHd9QIgV6ewonYhLEtMLEnoSDAe9kDH1lU5p63WwqM0R34uaDr2fZ299L5kF7xgUnjh05Y7vQ 5YCXsefDlVY3UiFOe9PiUIHW2uI0PgGGWzm+rNS1gW7yBOIWPjND0sBw3tjmt1XhWJxd5t8FiGe kdqWId1aJFNle2dfyUKTlH5yf7A2eCx2Tba9+B7nPbfMfegfmrDNuaTbN70pZ6GxttYjfG/bs3l P3rokKSr6ujPRyHJ1x8amfofOH0Iyo3ZWnyaC9+v1qnE/8Eeq/I/RpNv3CSxneY2GFP5lgVy+yc v3O39EOYEplqiT/KeonXRD7fMPafHLYh+ZywdzgRbb5hSNC0w== X-Received: by 2002:a05:6000:41d7:b0:488:89e4:c3af with SMTP id ffacd0b85a97d-48c480089c5mr18389145f8f.45.1791296758258; Tue, 06 Oct 2026 07:25:58 -0700 (PDT) Message-ID: Date: Tue, 6 Oct 2026 16:25:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 30/39] xen/riscv: implement APLIC-IMSIC-hart sync barrier for vCPU migration 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: <2075cb10e5f6df787b29f2f087632c82b787a007.1790779209.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2075cb10e5f6df787b29f2f087632c82b787a007.1790779209.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1791296759-1E867757-D433DB0E/10/73395122804 X-purgate-type: spam X-purgate-size: 13663 On 9/30/26 6:23 PM, Oleksii Kurochko wrote: > 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 hypervisor- > 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. > > genmsi's Busy bit clearing only tells that the APLIC has sent the > extempore MSI, not that it has arrived, so the sequence described in the > AIA spec under "Synchronizing interactions between a hart and the APLIC" > is split in two. aplic_genmsi_barrier() does the APLIC side, while > imsic_aplic_sync() does the hart side: it clears the pending bit of the > reserved identity before the genmsi write and spins on it afterwards, > which is what tells that the extempore MSI, and hence every older MSI > from this APLIC to this hart, has really arrived. Keeping the hart side > in imsic.c leaves the APLIC code free of the IMSIC local CSR accessors. > > The last interrupt identity (nr_ids) is reserved for this purpose. > > Migration doesn't use the barrier at this stage, so imsic_migrate_vcpu() > only references imsic_aplic_sync() to keep the compiler from complaining > about it being unused. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v3: > - Rename from "xen/riscv: implement APLIC-hart sync barrier for vCPU > migration", as the barrier waits for the MSIs to reach the hart's IMSIC. > - Re-word the commit message, describing in it how the sequence is split > between aplic_genmsi_barrier() and imsic_aplic_sync(). > - Move imsic_aplic_sync(), imsic_local_is_pending() and imsic_csr_read() > here from "xen/riscv: remap interrupts to new IMSIC VS-file", so that > both halves of the synchronization sequence are introduced together. > - s/aplic_hart_field/aplic_hart_index/ following the rename of the helper > in "xen/riscv: implement virtual APLIC MMIO emulation". > - Drop masking of sync_id with APLIC_TARGET_EIID, which could silently > chop off bits; instead add BUILD_BUG_ON() and ASSERT() to make it > explicit that sync_id always fits into the EIID field. > - Drop the redundant parentheses around the macro argument in > imsic_csr_read(). > - Use unsigned int for isel in imsic_local_is_pending() and drop the > redundant !! as the function returns bool. > - Rename the unused argument of imsic_aplic_sync() to unused. > --- > Changes in v2: > - New patch. > --- > --- > xen/arch/riscv/aplic.c | 33 +++++++++++++++++++ > xen/arch/riscv/imsic.c | 52 ++++++++++++++++++++++++++++++ > xen/arch/riscv/include/asm/aplic.h | 3 ++ > xen/arch/riscv/include/asm/imsic.h | 8 +++++ > 4 files changed, 96 insertions(+) > > diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > index 283e5d6046a6..5f9a894b5a76 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, > @@ -183,6 +185,37 @@ 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; > + > + /* > + * 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; > + > + 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); > +} > + > static void __init aplic_init_hw_interrupts(void) > { > unsigned int i; > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index f1e44dc56bb8..8e0273eab902 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); \ > @@ -203,6 +210,15 @@ void imsic_irq_enable(unsigned int irq) > */ > ASSERT(!local_irq_is_enabled()); > > + if ( irq == imsic_cfg.sync_id ) > + { > + printk(XENLOG_WARNING > + "irq%u is reserved for APLIC sync so shouldn't be set by %s\n", > + irq, __func__); > + > + return; > + } > + > spin_lock(&imsic_cfg.lock); > /* > * There is no irq - 1 here (look at aplic_set_irq_type()) because: > @@ -241,6 +257,15 @@ void imsic_irq_disable(unsigned int irq) > spin_unlock(&imsic_cfg.lock); > } > > +static bool imsic_local_is_pending(unsigned int id) > +{ > + unsigned int 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) > { > @@ -387,6 +412,9 @@ static int __init imsic_parse_node(const struct dt_device_node *node, > > imsic_cfg.nr_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, 64); > > + /* Reserve last identity for APLIC-to-hart synchronization */ > + imsic_cfg.sync_id = imsic_cfg.nr_ids; > + > /* Compute base address */ > *nr_mmios = 0; > rc = dt_device_get_address(node, *nr_mmios, &base_addr, NULL); > @@ -497,6 +525,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 *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(); > +} > + > static void cf_check imsic_vsfile_local_clear(void *data) > { > unsigned int i; > @@ -862,5 +911,8 @@ void imsic_migrate_vcpu(struct vcpu *v) > /* Zero-out new IMSIC VS-file */ > imsic_call_on_cpu(v->processor, imsic_vsfile_local_clear, &vsfile_data); > > + /* Avoid an unused-function error until the barrier has a user. */ > + (void)imsic_aplic_sync; > + > BUG_ON("unimplemented"); > } > diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h > index 9018936ca95a..bfb510b2ae5e 100644 > --- a/xen/arch/riscv/include/asm/aplic.h > +++ b/xen/arch/riscv/include/asm/aplic.h > @@ -94,6 +94,7 @@ > #define APLIC_SETIPNUM_LE 0x2000 > > #define APLIC_GENMSI 0x3000 > +#define APLIC_GENMSI_BUSY BIT(12, U) > > #define APLIC_TARGET_BASE 0x3004 > #define APLIC_TARGET_LAST 0x3ffc > @@ -177,4 +178,6 @@ struct aplic_regs { > uint32_t aplic_hw_read_reg(unsigned int offset); > void aplic_hw_write_reg(unsigned int offset, uint32_t value); > > +void aplic_genmsi_barrier(void); > + > #endif /* ASM_RISCV_APLIC_H */ > diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h > index 8130d125f5c3..f86407e21765 100644 > --- a/xen/arch/riscv/include/asm/imsic.h > +++ b/xen/arch/riscv/include/asm/imsic.h > @@ -62,6 +62,14 @@ struct imsic_config { > */ > unsigned int nr_eix; > > + /* > + * Interrupt identity reserved exclusively for APLIC-to-hart > + * synchronization. > + * > + * Must not be allocated to any interrupt source. > + */ > + unsigned int sync_id; > + > /* MSI */ > const struct imsic_msi *msi; > I think it also makes sense here to apply the following fixup patch: commit db57e94ed8405c98d7a21f4f88764fa5e0ea2d04 (riscv-next-upstreaming-fixups) Author: Oleksii Kurochko Date: Tue Oct 6 15:59:52 2026 +0200 fixup! xen/riscv: implement APLIC-IMSIC-hart sync barrier for vCPU migration In MSI delivery mode the MSI of APLIC source N carries identity N, by which Xen recognises it in its own IMSIC interrupt file. A source numbered sync_id or higher can't be told apart: its identity either isn't implemented, so its MSIs are dropped, or is the one reserved for the sync barrier, which it would satisfy early and whose pending bit would swallow its interrupt. Limit the usable sources to those below sync_id, and document how the identities of Xen's interrupt file are allocated. diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 96aa4edb3958..86ff3cae984d 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -246,6 +246,7 @@ static int __init cf_check aplic_init(void) uint64_t size, paddr; const struct dt_device_node *imsic_node; const struct dt_device_node *node = aplic_info.node; + const struct imsic_config *imsic; int rc; /* Check for associated imsic node */ @@ -270,6 +271,22 @@ static int __init cf_check aplic_init(void) panic("%s: failed to get number of interrupt sources\n", node->full_name); + /* + * In MSI delivery mode the MSI of source N carries identity N, by which + * Xen recognises it in its own IMSIC interrupt file. Hence the sources + * numbered from sync_id on can't be used: their identities either aren't + * implemented or are the one reserved for the APLIC-IMSIC sync barrier. + */ + imsic = imsic_get_config(); + if ( aplic_info.num_irqs >= imsic->sync_id ) + { + printk(XENLOG_WARNING + "%s: only %u of %u interrupt sources usable with %u IMSIC identities\n", + node->full_name, imsic->sync_id - 1, aplic_info.num_irqs, + imsic->nr_ids); + aplic_info.num_irqs = imsic->sync_id - 1; + } + guest_aplic_num_sources = min(GUEST_APLIC_MAX_SOURCES, aplic_info.num_irqs); if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) ) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index ca5243826726..408b94b22ee9 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -533,7 +533,15 @@ static int __init imsic_parse_node(const struct dt_device_node *node, imsic_cfg.nr_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, 64); - /* Reserve last identity for APLIC-to-hart synchronization */ + /* + * The identities of Xen's own interrupt file are allocated statically: + * - the APLIC sources take 1 .. riscv,num-sources, as the MSI of source + * N carries identity N (aplic_init() drops the sources which don't fit + * below sync_id); + * - the last one, nr_ids, is reserved for APLIC-to-hart synchronization. + * Anything else taking identities from this file has to stay clear of + * both. + */ imsic_cfg.sync_id = imsic_cfg.nr_ids; /* Compute base address */ Any thoughts about it? Thanks in advance. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Oct 06 14:44:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 14:44:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441563.1659162 (Exim 4.92) (envelope-from ) id 1xE6Oc-0001zJ-0H; Tue, 06 Oct 2026 14:43:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441563.1659162; Tue, 06 Oct 2026 14:43: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 1xE6Ob-0001zC-T0; Tue, 06 Oct 2026 14:43:57 +0000 Received: by outflank-mailman (input) for mailman id 1441563; Tue, 06 Oct 2026 14:43:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE6Ob-0001z6-9t for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:43:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE6Oa-009gXe-JZ for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:43:56 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac5092c-bab6-0a2a0a5309dd-0a2a4505e8ec-0 for ; Tue, 06 Oct 2026 16:43:56 +0200 Received: from [52.101.53.27] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac5092b-4cb1-0a2a45050019-3465351bd633-3 for ; Tue, 06 Oct 2026 16:43:56 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CH3PR03MB7459.namprd03.prod.outlook.com (2603:10b6:610:1a0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Tue, 6 Oct 2026 14:43:50 +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.0496.010; Tue, 6 Oct 2026 14:43: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=RSZG6PIOrWZ6sqwU6NOv8mVzS8R/kN/9FPpUj374XZUh3g6e5qCABFNXaLSDAiY6Bcy1r5DVfKBy2H6sxCpapDv0kSyv8nI5lA82W0mi1AaQdo/Vvrzmq6H1aeTi5avk7AWmRpG25Ar7z6BOYXLHU0KHAb+SKWcYEezR6gUit/gVxG0GFyIKmVooDuRX56M3W9eG8DDyIzKPB23E68Agr+ygFj3cRmdqpktpvp2fjld65SadIPI0dyEqoHcKmE+djf2xjhmZIMt0tkXrJQzggduKYFA8fz5nw67u/zK0bEELX6pgOJbrgk5T8WjanSGr1NzMfdg//wY0j7Gj7B0gIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lhQaN5T1hU1rRx42cQYMLNsDzKy6RS7+ImA5ST0O1uA=; b=aKuV98wh4TuBGAktz9vBSRkpPCDMUxtMVIKqefc8C13NL/LHS8fqHAYSr9B/i1nzoo1tzCNcwqip44w9U4aL/QOBEuEDOjU43r21AtOFs6oOcnuKYcdrXYC29zDoXXjJ2VNmxX1GWiboXHuVcUECMXJ0Lt7T+Eeoexo5/e6Ap7+dyx3GxOeEIirur6EaFgfsrvAvEhjzFrTFkNSsxWi4VdtBSyhnJuFEDYwvqw7DC2w/y/DrJwhcGTGFQxXwN+u+5ekKZZRALNgZBdrbQa4Qw6yQbrH5Qw+bMZNzMtEFT0pJCCzAWH0WMN45mxgfmCYa5ugXdQRwhDXTz1Xcv0i1Vg== 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=lhQaN5T1hU1rRx42cQYMLNsDzKy6RS7+ImA5ST0O1uA=; b=mwcbv/1uNSrsKccut0rXlY1w/NlNWw5x+/ZZjhrkvjuh1LgZhQ5jm7x92fbc/MNcls6PPsto9kSJ0gy4r4aXQU5LcO8Dh8S4HRnvUvyU1EIzNMwu7d1CQpklBPkuO+Bog/ERqhnZwRxcXdvoE6h68FrJFw2olqtC9SGvDgujTAg= 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: Tue, 6 Oct 2026 15:43:44 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen-blkfront: Fix IO race during unplug To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jens Axboe , stable@vger.kernel.org References: <20261006135807.2571779-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: 8bit X-ClientProxiedBy: LO4P302CA0009.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c2::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_|CH3PR03MB7459:EE_ X-MS-Office365-Filtering-Correlation-Id: 34faecf3-9617-41e7-1ceb-08df23b83c40 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|11063799006|4143699003|6133799003|10067099003|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: NGHT28ITpfGjij1ElAPudr0jFeJDXg3D+tCudvNj72BEksabQ09ChWik+/Tb3jtYD9Fgnnu3afPnFkFECkEswb55IiCGdFhSnAkGCshvwxo5W3AQPum6zeECgoTPVg3FQT6HIllzgCbDUiSrXvQkmOYqw6lCTnD+blS3WkE+1oILYH65Z4LEyT6WhD8yNqodZrV/XSOJFCA89WVg1NJKtg2N9A1sBich6iJVuasd/tDccfwF1Twm3ogijNcFJHtWlKZH/zhuaDzsIf1hSfhIX+PoOPhrzJcL++V/zlL9TyXP1U+yA0/ofGgymctNoqWguu3AEbPEVrpuzluirjqjxmSsLQVHj3S84zs7rnW0BTFKq3FonbUNYyNOD21Ld0vXfi9RBSswByrOE30t2+FGklr8648qDveZ0GtXJIe0miwL+Ax9erxLXRkrJI5G59R0is+bfQltks2r3ugBWa/t+2ebcATaylhzVPbFAPn9K6XlumrG/MJEmpGEmrU0CCV4F2WQtNkrjmJXUubPX0tamC5MTIQ9AG4qJS5nXCaxX2icyj3rCcLL7t4TWbj22oWrbdYD6oWt+qnaioiaQTO7v+UIiu22f5PuX9JxQtQU5PoXHzcsPwOEHNjkVN9PKbvquPxY8utF0blBIt5EQXbtRLOc3jvMg69sbtArLJP6y+8= 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)(11063799006)(4143699003)(6133799003)(10067099003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QWxtdURMWXk1TzQrcHhwNkFDeDE1WUJ4RlN5YVVaeXdBbVMyZlFJYTdFRUhH?= =?utf-8?B?Rkc5bTdITlVrY1IycmVYcTFIMWxVWkhRSGtHWkt5SXg1bWl6MklIZ2o3MzJD?= =?utf-8?B?RDhEcll6TFVwZ2NCMjlEWm4yRGVCejVJWFg1VW8yays2V2RsOFYxVkdQbWV2?= =?utf-8?B?TFY3ZFB5NHlXOTJXUXlCQk93K3ZFL1BNaWpLdUpyWFZScG5hN01UMjRxSzZW?= =?utf-8?B?S3lXdkRXYm15aEYrRUo0R09zYVU3MHNzNlhTVkNXRk5xb2dUZlFHWXN4elZU?= =?utf-8?B?bUkveUJ0N1d3U2k4MXJCUVZwdWZWaDZUU1dBRjZGR1RhQjJwTmE3d1dPWXg2?= =?utf-8?B?UlViRm1rVisrdEsrbWFXazM0RFdYMVBkbndXeFVHTjl3d1RNOUdxMllhcW01?= =?utf-8?B?a05PNjk3MUo1RUlsNmJPM1RmbUZXTmpmMTdXY2R5cjBOZ0s0ZzV3Q2p6Y3FI?= =?utf-8?B?V2l4Y1JjTVI2NFVjRVVqQ0RUaEIrckFneFN5eGU2M0dDSVpmNDRtRERQU2Ni?= =?utf-8?B?QnhLbVh4WmJqOG04SmRlVXh6S2NGZTA2SnhxMGFzQ0RKZkdxelZKRnEzSGE1?= =?utf-8?B?MWpZUkUwYlRwdHVkU1RBazhhSXZTQzY5dm5yM0FnekpBdS9kU3VZOUFFVnBF?= =?utf-8?B?dmJudVN0eENHSzI0VHhxdFZPczllWEltUm5mWmFNc0VtNHJISGdIYm5ERXN4?= =?utf-8?B?RFU3Q1pLbDB4NVZacDhlcXFXRkdmOFA5cEJ0RGMyQWNMTmorL2NpK0FkWWcx?= =?utf-8?B?TWpoOVFWeWtwSHhSanBZd1FXeFdHTlVLaWFpUkxFR3E3T1I1RzBxTEZlaFRs?= =?utf-8?B?MUk2MEVEYzdQUXY4dzQ5TFlOMWpoWGpzRjlTSS83Qld4ZjkxakR6K1QzaWhN?= =?utf-8?B?ZlhpV21hSm12bG5ZR2lSaS95SDBCREZ2SndPMnhNYTlQMThjRk1RdVRhNVAx?= =?utf-8?B?WmlvRm1uY1F0Z2Q3UUJ4bkJORWgwZmI0aVN2bytFbWNUV3VWdzVhbnM0UXFP?= =?utf-8?B?Y1NFUzV3Skx3QWl3SXlqbll4SGYxOUNzc2FmcnA4YkpKRXppM2p0VGdDb2ZF?= =?utf-8?B?c293N2lhQ3JteFNaWUgzS2wxOURmMzhtVk9nL3NVb1ZoR09YQi9jL1ZLZ0tT?= =?utf-8?B?akU4L0RzM1BxdXl2VXBqTFltTnBoUEFNdmFzMDNpK05qQnh0QWl6clB1dW5T?= =?utf-8?B?cFYwRjJmUmpMdVBwUWYwcHQyVUhTWTV3VHZYWHMyUUZqaUc0TFF0UUROdElY?= =?utf-8?B?MVhOeDlDSHdoSjk3TVhZVVVUWVpWemlGZ2tPZlROS1N3NW9Hb1lZV2dLYkpN?= =?utf-8?B?T25jUE9sUzRNRFZxZ3lQSlM2VUpmMVFtM3BBUm1temFmdkxENEJuU29lMmxH?= =?utf-8?B?Rm1ZSkkyK0dnblYzVjF6YzlSNFJVRGFMcy9GazdnK3dxRXJXZGZqNDJlaThP?= =?utf-8?B?UlI5cEkwakxOTTB1T1p3OW5CUGZsQnJvbWpQMFFyYXErMzlwcVUxSmYxZzJI?= =?utf-8?B?cW5wU2tRSGJTQ25wWnhJaE1MQjR4c21lSkR4QkFtTlppVWowK3JCR3ZCa2wr?= =?utf-8?B?d2JHUjJNSU8wRDhhY29Rd3dndktjUmhKVEJqMjVDNmlxUDEvS3ZLUGgyd1Z6?= =?utf-8?B?WVZIRWJyeDZTS2NqeEpnZTYyY0d1NzhRSW9OQXI4YXQvVEdnbUM5bFkzc1dB?= =?utf-8?B?NkRrTTJNZGJJbnI2dGZrZk1kZTMzUXZhMTdjbHlVUlZ6cVJaampVK0Q0R3Zp?= =?utf-8?B?dG9VU0tzWTk3OVR4UlMvWWpjVENORjFaTjhWQ2MyL2VyNHZaWEZNM2tCcXZw?= =?utf-8?B?TUhwYjlUZ1E1REJoNlE3c3ZpQnNQMVMxdSt1U3NVdGF3amZZN0VSMUxBOG9S?= =?utf-8?B?MkE1Sm5LL0UrMUpXYUJKM2ZnSXozTno2U2dyNjZVMkxvUDhyakJtMU0xblIz?= =?utf-8?B?dThkNXJTdWRTYUVOOHBsbVBmOGVldzN5aWN6RDBGZVZweGVBY1FvNGF0VFFZ?= =?utf-8?B?QXlNQXVYLzVLaVpWZkhWYzlwQTlZM1E1K0JPQ0tGdHhXQVNzU01Ja2wxdjRE?= =?utf-8?B?THFTTHJzZlRnQ3RGYnNSZE1DZ2VEbHI3TFNFR1VJd2l0KzFiWWlWM0ZRNnBo?= =?utf-8?B?T2M3ODJ1dVluc1BtRFhkS0JVbGJkNFRMcjZpcjJnNWVGNWxGKzJVd0xKYUIz?= =?utf-8?B?ZEFnL3FxakRJWUJ5OVBkWXAyM0dQYXBNbHRlbFJsZHE3cm5aZi9ZMlc5eGlL?= =?utf-8?B?eGpoeTY1LytES0l1NG5HL1UxbG5vTUV6WXAwVGs3Qkx6Z3dZanJLcnZkamMw?= =?utf-8?B?dmN2b3ByRFZDVXFtdER2SVcyWGZTc2p4aVh4S1pRVXpELzNra0RTTmk3Tzkx?= =?utf-8?Q?pLnpNMHBB20ERKUA=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34faecf3-9617-41e7-1ceb-08df23b83c40 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 14:43:50.3521 (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: dLpIFAqkka1k3aQVyaT1YBkuCrRDKSm2Bra01Vd77TFkTSdxiVmz3QKEgGuf9G4ZIOTiLSRfO3wvTUHLGtYLgsPoWmvSdtLJri5nqyEdfWc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR03MB7459 X-purgate-ID: tlsNG-c201ff/1791297836-F4AA72A1-BC4857C0/0/0 X-purgate-type: clean X-purgate-size: 3033 On 10/6/26 3:14 PM, Roger Pau Monné wrote: > On Tue, Oct 06, 2026 at 02:58:06PM +0100, Ross Lagerwall wrote: >> During unplug, blkfront stops the hw queues and marks the disk as dead, >> then later during removal calls del_gendisk(). However, IO issued after >> the hw queues are stopped but before the call to del_gendisk() will be >> queued but never handled. This causes del_gendisk() to hang forever >> waiting for the queue refcount to drop to zero. >> >> This can be reproduced by issuing IO during an artificial delay after >> stopping the hw queues. > > So the window is between the blk_mq_stop_hw_queues() and > blk_mark_disk_dead() calls where requests would be queued and never > processed? Yes. > >> Fix this by simply not stopping the hw queues directly. Marking the disk >> as dead also freezes the queue which prevents new requests being added >> and it synchronously runs the hw queues to clear anything pending. > > I think this likely needs expanding a bit: the disk is already marked > as dead with the current logic, and in the same place in the code. > >> Fixes: 8e141f9eb803 ("block: drain file system I/O on del_gendisk") >> Cc: stable@vger.kernel.org >> Assisted-by: LLM >> Signed-off-by: Ross Lagerwall >> --- >> >> I'm not sure about the Fixes tag. It's the most likely looking candidate >> to me but I didn't confirm whether it actually introduced the >> regression. > > I was wondering the same, and even then someone might argue this was a > latent bug in blkfront itself, and the reference commit just exposed > it. I don't have a strong opinion. Good point, I might be inclined to drop it then. > >> >> drivers/block/xen-blkfront.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c >> index 8dad7bf5f664..69a2315a1b20 100644 >> --- a/drivers/block/xen-blkfront.c >> +++ b/drivers/block/xen-blkfront.c >> @@ -2138,10 +2138,8 @@ static void blkfront_closing(struct blkfront_info *info) >> return; >> >> /* No more blkif_request(). */ >> - if (info->rq && info->gd) { >> - blk_mq_stop_hw_queues(info->rq); >> + if (info->gd) >> blk_mark_disk_dead(info->gd); > > So blk_mark_disk_dead() behaves differently when called with the > queues still active? Yes. In both cases, the queues are frozen and the hw queues synchronously run, but the latter is a no-op when the hw queues are in the stopped state, therefore it could leave requests unprocessed. How about this for the final paragraph of the commit message? """ Fix this by simply not stopping the hw queues directly. Marking the disk as dead already freezes the queue which prevents new requests being added and it synchronously runs the hw queues to clear anything pending. If the hw queues are stopped when calling blk_mark_disk_dead(), running the hw queues is a no-op and can leave queued requests unprocessed. """ Ross From xen-devel-bounces@lists.xenproject.org Tue Oct 06 14:48:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 14:48:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441571.1659170 (Exim 4.92) (envelope-from ) id 1xE6T6-0002jK-GA; Tue, 06 Oct 2026 14:48:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441571.1659170; Tue, 06 Oct 2026 14:48: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 1xE6T6-0002jD-D7; Tue, 06 Oct 2026 14:48:36 +0000 Received: by outflank-mailman (input) for mailman id 1441571; Tue, 06 Oct 2026 14:48:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE6T5-0002io-Cl for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 14:48:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE6T4-00CULt-Lf for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:48:34 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac50a3e-2eae-0a2a0a5409dd-0a2a450ba28c-8 for ; Tue, 06 Oct 2026 16:48:34 +0200 Received: from [52.101.48.30] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac50a40-b7e8-0a2a450b0019-3465301e106b-3 for ; Tue, 06 Oct 2026 16:48:34 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SAWPR03MB989599.namprd03.prod.outlook.com (2603:10b6:806:55c::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 14:48: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.0496.010; Tue, 6 Oct 2026 14:48: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=L0IxagywmmyO4ktBSgjF0cacK14T6l2iFl44rtPKLpfn0n21SS85YnUR1t7jRvazvdYb00Eb7yd7/vQ00Cloh0Di8b0Ij8S8X0XEBPDrevd3/i3HFitHtXSkUCkasdI5h/+iHS3goFsY/iuN2uQIC8WXkkMMVtinW64GoxOyZaKck2FbSyhb5zAbG/3n/CZkh9iW8IEsjLRyrymeMWzXlAP383N3Rz+QuM8rClcpweuinBJG0Hfs0Ukh2YcSJuejr3EJyFAEp/k6wqxkVLpUmePMPex9eUp1+UErbvz+PkuYob4gIWVF1o+0ujV/5tj2yFYbuFK1IZYXc2Wgt5rh4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uhDcIEiFZcls6I0YzJ2XQWMLqLgbR8/hTYY+1gKHoYI=; b=CpPco7t5Nr63uZ2xFNTZwd7zcws+HvYCnlLtZPMhz5/xXXZa1vyX90dOhJmwwosGuaWuF8gkMmsOH9A9l1CqC6XEJIF7BIetfieagEGlzKGZ/6ceWAAEKY0aqLKQoPX/OmViomyjO2+u8CRldpnjWyESyKCDXF8P2fJwzx4NJgALligAXi7zSof0k3ueyusT9UGAUWN1UDqqA0rZz1vskgShR+QfO0QdqWlJaOOvD9ZLbhswS3LhJrwlvkqC4eN8ldUxukDykO7SfJoMbfLAVMsCunMcTFZDX98R6PPlpBCdHxMoEm9F0JPVziHXu/9XmWrXDJeNVlh2pUYrSjAJmw== 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=uhDcIEiFZcls6I0YzJ2XQWMLqLgbR8/hTYY+1gKHoYI=; b=lvuZD4V0MT7RZYhfvMtXHQf4yIPKUJqGaNNDMTt7fWQdB776YXlGUebFC/ajzDpWSG9P/gb6OIqgBfK/22UTc+2dSPfI1bFnud1mCzPxjoBi+tvNcHVzPOcI6zzI5EbROT2RMU8XREiMwmziSqtTAzBJRTkTXmLTtKnwJETLons= Authentication-Results: mx.microsoft.com 1; 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] x86/svm: Don't clear clean bits on every context switch Date: Tue, 6 Oct 2026 15:48:05 +0100 Message-ID: <20261006144805.2575991-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.55.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: DU2PR04CA0260.eurprd04.prod.outlook.com (2603:10a6:10:28e::25) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SAWPR03MB989599:EE_ X-MS-Office365-Filtering-Correlation-Id: 972d7933-114e-4cd2-392d-08df23b8e3a3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|6133799003|18002099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: QYn7tuYEjdNPw1V4/fpwqQh79eSD4psSH8akc0y2PhWhR1j0AhfpslQ1ZB8J5Rjv9FHuTCCKMArIyRwFyvqR0x8KMUfxTJL/j/jJxjObj/u0zjyfLGtXlOXD/p+dCGPXT9xsnfN0oRZTu4vYUPG2GmENzw+RMvOgF03KRzeytn3aFOq9tjzxwA0JKPxNAoVDnfxzihV6TOsz9/zW/Abz4BWidjKvnkQPuj7Vi90MRcprWL4VmmuHAb5swu5wWZXdiCxFFf11wEksFwi3SEftm0WtR1wOQbCuh893kCeTRxFIVzq0g8K4lY6hfgVTSlmy3DqFLWHL0i11fidRhWWj4TOKDVA3AjToXDzyni10MX7A1n9oKgQ1V5Vz30sYbogY3ATApCkXlt3+/tGPt7amxpyijINN8BMgDviDQhuPKe9aWkKQW0gOZKmVDgHZ45tIWYTUGxYRDWkdgRDmD3ChQdYxQ+5jf7L41GqEhigxzFKd7OWgi6oDzsazaeOf+vkdMlwZuKKGRZSPx0xEdhFfNUO/efwGMOyKe4+iaLUV6eJ2Fn2i9bEXRIV+75YtMhy/VMq1fpWkmWqEwGPkbTo6KRoQ0k/dVWA5oafwvlu5k6fyTTXJ9v3Ls/TXaorBSBHfBQFvHuEKLmtmE0TYMSS3tAs9QbSd8cu0V4WU3BRUG+4= 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)(376014)(1800799024)(366016)(6133799003)(18002099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?mviYxwCk1IlI/LELmMG23YfeofhhJ4w9twf8/y/mh0rdxd/GZ26YKJtOLLlj?= =?us-ascii?Q?qKFrhQCJxVfgTuovO8wvouS09GgE+j1ySAGHjSCQSh+GHQC1D+DUKcwir02r?= =?us-ascii?Q?gbXLPjDsydIzu50Efn2T/SSVLB60wnoMPJba1IdRbi+a8MKURCR4E35gB30j?= =?us-ascii?Q?CRZmWKIjZjq5Qkpd2Zb5AJwdi35vKHnoHH7YOXuQE0MmHFbE/UoTMqE/ivAA?= =?us-ascii?Q?H9nOr7hSP3Eh3uwVNU5Z9x/GvWEm193GKUWmVvCE6X7QfkAC+dt/yJons9UY?= =?us-ascii?Q?UKfQ4WD0K1AFNxJyH19G637GNPkDsPchZMsKPTi7pdPMMMJjw94JVCXLg5t7?= =?us-ascii?Q?Oh9W33AA4ORtuBWjh3xIJ+EQd1nXrcJMqwqgxrApAwOduto1MQe5lbVeZoMj?= =?us-ascii?Q?lre+1aTzzdy08WaqqY755YX/eRwExbwS/Ff8FRqz7gJQepAX8jyGWh6OQQxB?= =?us-ascii?Q?dO04lKNBsI2EM+wqWZrVZ7NvBbGwaP7NXRmcDnKwPqzxLEJC9JDTRWl4VdfR?= =?us-ascii?Q?N+KHDu7fymCDiVQPGRYi7UxgJ8JrN7YGdAGVilPseE0yw4A/KKhgnEpsIfi0?= =?us-ascii?Q?CvNPVquu5XZ8392IA2SBFs/AYzk1PKCcHaAKMQnxEtd5sj++d6zX3qLxSaCp?= =?us-ascii?Q?SfupLFmX+96+PC4InQ6KKZoHLOrhdz0sc5R/+bQVmOjz15dmGW77fwQEE7M4?= =?us-ascii?Q?EwFnhvtb5+E3lzec9x+kQyigQyDp4BXloYJotqEDPTt2bpfPKrXzBxJ3E1sx?= =?us-ascii?Q?5UtHU6g4NEGKqZM4kHV5+Z1mV4xELCzeCIKOyDPnqzjienRInwzDQ6kPgjyC?= =?us-ascii?Q?bgI9Flzjd+/gspbBiFm155V7Aw9cEa2eM8gjNq0KeFI4yBzKGu672Cj5CD1O?= =?us-ascii?Q?D00QrOWg36QiaU8gtlr9X8/QuYKkMm66KvbfP6m0Hb4dxNB159xP84Gue7Q3?= =?us-ascii?Q?Lqp0/0pKZK9ervBqF9t13fgWMOgIIQpMfXdiJvCMRA/K4b0XggfGNlu9EKW+?= =?us-ascii?Q?iMkCTAJLOZk4Fz0TGpaEdhas6/T4I2KhsdM+RpPbBrYpdBVFJztcIPS8/JD8?= =?us-ascii?Q?gPx2mQO5ynoxlM4HzzyRssDN+UTxO69LUhArwI8nuWyIJ5rb7bSuuhnf5UBL?= =?us-ascii?Q?+y+wjR4lpomxZybbukXFItibyMaRkxaFKk+4ES+eC6O2TpT0RHd+Eq2DsLr5?= =?us-ascii?Q?ZtG5BhWGQDewEAtlp2fI9qCNzWgwQ+kNJQK4TxBdrQdhjlMeHnwhg+SqILp5?= =?us-ascii?Q?fO52men1Wlg4CvocDTd1KOy83Uozbwl/uchnPx10wApcAY46r/Bsv4Uryxs5?= =?us-ascii?Q?VnxTI/eUNyyx19ZvlLX/WUaIdZupBrOe1JCOoBBWdTRM4cCIBJYM2mOAmQCg?= =?us-ascii?Q?vS9h6WASuOT3FIcI0gc+DjYUuEN274nZRuFn2oVNfpNSqRtnay6zBFeLf0eZ?= =?us-ascii?Q?Qg+7mhV3ZUEDUenMtTQploOF+3/BkfqTQ3Cf9Uht/0cMSQ6vOc1nNCAPTX34?= =?us-ascii?Q?62VyqBH+/wjaeTUteBWGnycvAaBkYHL9c74RiSt+nN4g1dtaYTe8DOBUbB2j?= =?us-ascii?Q?wwNxktlwEE9wJBmlBXOfJ67SYs0THYlBBbbNydE3bZoTS8tVoKKpN206SFVe?= =?us-ascii?Q?L1eam87ThpoItMTsJ2j3ny2tLKJEJ4iKx92ZoNVc+6VitZbnszs8FuehaveS?= =?us-ascii?Q?nBVB72JHDwGn52tsB19O99QuSaJFO5S2bE3cDi323ODn31GI1E4sbeuWLf1z?= =?us-ascii?Q?86s187TQkvUhMJWfvyVs7AABnlFtJCM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 972d7933-114e-4cd2-392d-08df23b8e3a3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 14:48:31.0713 (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: fAfVJ6e7Gvt0PzhUKYov0aeNpovuPEW+Tivki1en67bedfBQSJe002SOEYcXkfZj8CxcniM0CNKcrS70lqUYRgoRqLLFiFbvRGNuJZGNnX0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SAWPR03MB989599 X-purgate-ID: tlsNG-42698a/1791298114-1AEDE9EA-6A6FB087/0/0 X-purgate-type: clean X-purgate-size: 1413 Clear the cleanbits only when the VMCB is used on a different pCPU rather than on every context switch to the vCPU. This follows the APM guideline for when to clear the cleanbits: "The hypervisor executes the guest on a different CPU core than one used the last time that guest was executed." Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/svm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f22c..4e22322f4b42 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -890,7 +890,6 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v) static void cf_check svm_ctxt_switch_to(struct vcpu *v) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; int cpu = smp_processor_id(); /* @@ -908,7 +907,6 @@ static void cf_check svm_ctxt_switch_to(struct vcpu *v) svm_restore_dr(v); - vmcb->cleanbits.raw = 0; svm_tsc_ratio_load(v); if ( cpu_has_msr_tsc_aux ) @@ -953,6 +951,7 @@ static void noreturn cf_check svm_do_resume(void) hvm_migrate_pirqs(v); /* Migrating to another ASID domain. Request a new ASID. */ hvm_asid_flush_vcpu(v); + vmcb->cleanbits.raw = 0; } if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) ) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 15:04:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 15:04:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441581.1659179 (Exim 4.92) (envelope-from ) id 1xE6hv-0006E3-Mo; Tue, 06 Oct 2026 15:03:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441581.1659179; Tue, 06 Oct 2026 15:03: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 1xE6hv-0006Dw-Jz; Tue, 06 Oct 2026 15:03:55 +0000 Received: by outflank-mailman (input) for mailman id 1441581; Tue, 06 Oct 2026 15:03:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE6hu-0006Do-81 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:03:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE6ht-00Er7J-KC for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 17:03:53 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac50dd0-8faa-0a2a0a5109dd-0a2a45039b50-28 for ; Tue, 06 Oct 2026 17:03:53 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac50dd9-fae8-0a2a45030019-d155802fb97d-3 for ; Tue, 06 Oct 2026 17:03:53 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a0e1b0681bso6466395e9.3 for ; Tue, 06 Oct 2026 08:03: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-4a178c49c35sm85164955e9.9.2026.10.06.08.03.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 08:03: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=1791299033; x=1791903833; 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=CasQ129JnTi1hA4u0R+Ibd5/V27+WKUsP8JrxJJeiTA=; b=MkpMIRWPP9mxbhoSfYQ1ZhsTFlmAJLLSub+v6FITtX9tIlY2eBaIivaCCJ/mtdcJF1 y7Qyca/jQdRcpN3WloBBtI7rfRvRCbZW6zY7uohKmgApiAlOaxMWoxc7zsYnaLHjfos0 e8BGU9lHYGL9vzlOaHlFwDqhVhRP0UF50Dk+UIOlwGpmolHhnfxJdBnjRJXEJN5+JxBv IH15PW5SKctnj31Qlbv8EG0S7TA2QhMM4jzxSyH3NH4tuC1M62ShFPIYHATs2brWx8tX aj8pyteEG5aDxTPHqG8/pXTVlIfdyLnqItFy3utq4sKbGmfNv+5WHEd1ioWAgD1fqjp5 99TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791299033; x=1791903833; 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=CasQ129JnTi1hA4u0R+Ibd5/V27+WKUsP8JrxJJeiTA=; b=S71uz8Lj6VHhJMrPClK2IvPW4QXEy9zFVr+7yZmPnf8rW9qyy3KMCUXdWwmBd2s5Ox V1m7HA+Yk67T9/zHgyLxsuOYadm4+wXFhy9PJQaKaORxxLxItejTy1GWOu9T6u+Bzs92 fltvfLEN9V4RAg+XHL0muSpsmsAYQWk/ww96trbzCBYQ7V4p+uBao2QC2L3Fh3oXpeh/ 0gRnC9dpDRFpcg3YNpzyHC8QUCn3aLGtVTka8l/XCB9nV2GzQQgDlAc9bipXB2tpjC/g PUNoxcPiSGFbEn/Ib08U9nbe87B476e9HEl/+Rh9eEDLtnIpbw7CTOLRVTF9xNux6b3d l97A== X-Forwarded-Encrypted: i=1; AKwUvBzabGvjdCF0uu0HGw6fQGGzF3hqJzxNtH4Rs8EqM98Z9xSuJwUP7thVXpQ8cyrDTtom0eJ2K5aflTk=@lists.xenproject.org X-Gm-Message-State: AFuF++kxFI3ztY8fIL9FQ+ZmTkak3tc9VHx1qa27vWvyxiUt2AvWE6Aj nzyigkjzXPTFi7F1dWje29AB6eGdolVYg+IESDJKXbQdYJ94EHC6n8I0fR+M28hFNgPKAEhZRYl +lR789g== X-Gm-Gg: AYBFou3mBoE8ulVTTrKRg4ZvSpK/jfXa65IiNl8WWEmj5jJzxZ6YllZgFBLHYCkUJMA P8gP3d0Y4r3q3uWUa4DR0B1PRa80t9aFF8940XY3PLeySYK68P61H9AdHdIk+ZwAOWm3NsXPCUr W/vAJMT/HXjFwMApnjw76TNa43EiU+4DinwKwWNg0DuIgjra3TdT1cRO7fiyM11wtnz7xZFu2W9 rNS/KDNjWbYcjGRAayW7YDQq2RTRtAVDwwGjvVf0pSxV1fEjYOCQNR5j6GD8+HFnMYYyB44YhjH IiVhybalsHUjLYaXu5uyzOE6Pw9CF5XNxmvBcc0VOAivz3cTuwwdpBSyFiTbhZUJe5FrQO0UC4j iEmqq054/A3FetySMkqBqvIO8OT2ytayk3mu8kuQQapb/LBza9T0VCSDwDzlkErRXGfwSIKeeqd G2+WfETnk+1GrkqDeV9V2PtETT8/POs7/5dw/PCNU8imc46nEU/tTmqcYJa82f1dZl9f4X18C23 U8yAqbNLDz/aZripRnjQ/lyhfXEV1q1OX/KrZuQHSE7Q5+FbM4JLSpxDMAEKw== X-Received: by 2002:a05:600c:6592:b0:4a0:27eb:49b with SMTP id 5b1f17b1804b1-4a17b5523f2mr31249255e9.30.1791299032616; Tue, 06 Oct 2026 08:03:52 -0700 (PDT) Message-ID: <03338d69-cbde-4918-8ffd-c309230d337f@suse.com> Date: Tue, 6 Oct 2026 17:03:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Eclair: scan the last xen-syms linking pass on Arm To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@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: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1791299033-778F24E9-0C083398/10/78276251493 X-purgate-type: spam X-purgate-size: 1112 On 06.10.2026 16:23, Dmytro Prokopchuk1 wrote: > Hiding .xen-syms.[013] assumed the almost-final image is always pass 2. > On x86 LAST_LINKING_PASS is 2, so .xen-syms.2 stays visible. On Arm > LAST_LINKING_PASS is 3 and the final image is .xen-syms.3, which was > hidden. Pass 2 is usually only a symlink, so Eclair saw no program link > and reported every translation unit as unreachable. When I did that work, rule 2.1 ended up clean for both ARM64-* analysis jobs (iirc). Upon re-checking I now see that ARM64-amd has 177 violations (apparently that's what you talk about above), but ARM64-allcode has none (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2916569232). > Stop hiding pass 3. Passes 0 and 1 remain excluded. This will cause scanning of both passes 2 and 3, i.e. consume more time and report duplicate violations when both passes are real linking steps. I think we want to be smarter than that, to really scan exactly once. I don't have a good idea just yet how to achieve that, though (and I was wondering already when putting together the original patch). Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 15:21:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 15:21:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441593.1659188 (Exim 4.92) (envelope-from ) id 1xE6yX-0000wZ-4g; Tue, 06 Oct 2026 15:21:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441593.1659188; Tue, 06 Oct 2026 15: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 1xE6yX-0000wS-28; Tue, 06 Oct 2026 15:21:05 +0000 Received: by outflank-mailman (input) for mailman id 1441593; Tue, 06 Oct 2026 15:21:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE6yV-0000wK-B6 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:21:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE6yU-00EuNO-OL for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 17:21:02 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac511d4-8faa-0a2a0a5109dd-0a2a450bd782-30 for ; Tue, 06 Oct 2026 17:21:02 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac511de-b7e8-0a2a450b0019-d1558036cd4f-3 for ; Tue, 06 Oct 2026 17:21:02 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a022fee0caso9336695e9.1 for ; Tue, 06 Oct 2026 08:21: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-4a178ca8bc2sm75680745e9.1.2026.10.06.08.20.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 08:21: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=1791300062; x=1791904862; 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=N76OStvHGCqlSA+A8skpaAHQgjICkj5sb3qUI+Aspkg=; b=S5dnFgkJvMWmGPY8mlAX+aXZU04CnqOejKD1MNkICJvNqvnmRoJEdp11n2zRQIwRj5 gdBOea4oLr2lB8NoTr4Rr5yUA7m6heouInsb6g2gGReTsRlvsN+mO3nbXYFaBDBti3gN /eNsKiXILnfHI4HMbZ3Rw3QYD4E0pM/o0tRKlVG3sXt5Ypf5MNx6CoYgNq/79NaOwyB6 Oe8bUcovhsSYkJM/3rq5lbDroLnjGmmxBjJm5wdBD3yRgxNvkTh9JJlYIimGKt0YtZp6 YIZbS9z7j9WvHTf5/yA04vdYV1HTXHp6nSdf/d5WUkeZRVWbqpJz2cdzGswZ286j2xvw qdOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791300062; x=1791904862; 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=N76OStvHGCqlSA+A8skpaAHQgjICkj5sb3qUI+Aspkg=; b=CuWu0z7Z+O65mCjRwoYYsg48xtQ7H+nVr59YnleQgKAEpLbXpVqNekQ/xj14j4FnSO Ox0PlHev3PFJlYAj2DfOBQSaxbcE+P20AsduBq3E5qYpzT7DxTjI6ByCcp2VzvRscSIS nMacz1ttb1sDRQL6JyEYzZnXmbMJXybBT4S9s2nQqu+ff7S4aJFiA9Zo/YzClh5PLksd 09tax7aMYb6DMhVgKTxpzosnxef+LJUAUnTSoxxYYaVc7vegcWNBpKUFO9CyKXtzDvvw zWjcMWVwh60ibk6VzObEyDbDTcaUfgZAfyFEXUt6pJIFRE2hZN9uuqo1R/zNP720RGQ5 fP0A== X-Forwarded-Encrypted: i=1; AKwUvByzHdeSITpkvypgv4oNnll6V0OQjuMR+Hl+DNsHNfiP+diZGTn3srw5p4mXx2xMwxihaShvn0JvGU8=@lists.xenproject.org X-Gm-Message-State: AFuF++koYQysq7U4NkIKCbMUyWmGu8nO1GanM/ASepu5DKWjuSjeun5u PogOwNvE67TgbkuXwgcocrILQP/vRJul/p0X/gpFOAx44O9iIbjrX+z7ALm46US1lg== X-Gm-Gg: AYBFou08b85GUi/1Eps7IWD/+MIb04mnrT8+RVEmSt56itv6fBG7SvGIRuzFklC1J8F Xl+GaRzk+aeWC8T3NvP5W3duM14i8PSMS9aaRsv43L0IMJlC0OOcI9cK/Eq+nLHBQyn7J7W7hho utQg+h624UD6az9Uj+4yjhWd8S43oeOUzjgFFbJQfZw6tUfMgp3ZnjhhQbO2KBSJ8WRRNnflgm8 8KTWuKp7Q/246FJWQcpCshR5/F8QGmj1ZhSs+8W7bF/1GTQYJ4V7sO18CocevdSTRDZTgtn5OWn VLb+eqdfsCVNY5Eh0V5F5gZimHJqVte6Naj3Wh379/Qd06O1v4dgQMeV1xju6WIjU9xztpIInpa bO1W6btSMe2UCR/ZUnJvHmGZ2E03BOzCH+aUwHx0ReyqtEBZFykU0kIdjYiQ32cR3jN0zAI5P5N qXOyxWtLMEbgMRylF6TOSeI5v5ckmYDNi8n8wrhqUJHaEgrzVFVqYqiAn3Ylc4n3lqNQhPgNT4V p7UsG9pcZ7RUw+8genP2oHmIrmiEP3YNTbpBdN6j3pmEvMUmJZP7eXNuLJ2Mw== X-Received: by 2002:a05:600c:8b58:b0:4a1:7259:349e with SMTP id 5b1f17b1804b1-4a17b562032mr26677295e9.27.1791300061963; Tue, 06 Oct 2026 08:21:01 -0700 (PDT) Message-ID: <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> Date: Tue, 6 Oct 2026 17:20:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@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: <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1791300062-1ACDF9EA-31F3EDD8/10/78276251493 X-purgate-type: spam X-purgate-size: 4516 On 05.10.2026 18:00, Baptiste Le Duc wrote: > A RISC-V implementation can manage the PTE A/D bits in one of two ways: > 1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). > 2) Generate a page fault when 'A' and/or 'D' is clear, so that software > can set them (ratified as Svade). > > p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device tree > advertises Svade. Platforms that use scheme (2) without advertising Svade, > such as the HiFive Premier P550, then hit guest-page faults that Xen does > not handle. Is that a quirk then (to avoid the word "bug")? Since it's all DT that conveys available ISA information, why can't the DT for those systems simply be fixed? Depending on the answer here I might question the presence of the Fixes: tag below. > Always preset A/D in G-stage PTEs so scheme (2) never faults. This is > harmless with (1): software just does what hardware would have done on > first access. > > Drop the TODO suggesting to handle A/D faults: only Svade raises them, so This contradicts the earlier paragraph, where you say that page faults can also occur without Svade. > it would not work on Svadu. Dirty/access tracking can restrict the RWX > permissions of p2m entries, as x86 and Arm do. I'm also not convinced that this is what the TODO was after. Oleksii would be able to clarify, I suppose. > 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 > > --- a/xen/arch/riscv/p2m.c > +++ b/xen/arch/riscv/p2m.c > @@ -591,38 +591,16 @@ static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) > 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. > + * A RISC-V implementation can either: > + * 1) Update the 'A' and 'D' PTE bits in hardware. > + * 2) Generate a page fault when 'A' and/or 'D' is clear, so that > + * software can set them. > * > - * 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. > - * > - * 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. > + * Xen supports both, so set 'A' and 'D' up front to avoid the faults > + * of (2). This is harmless with (1): software just does what hardware > + * would have done on first access. "Xen supports both" to me means it suitably handles the page faults resulting with Svade. May I suggest "To support both, set ..."? > */ > - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > - e->pte |= PTE_ACCESSED | PTE_DIRTY; > + e->pte |= PTE_ACCESSED | PTE_DIRTY; > > switch ( t ) > { > From xen-devel-bounces@lists.xenproject.org Tue Oct 06 15:27:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 15:27:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441600.1659197 (Exim 4.92) (envelope-from ) id 1xE74z-0001aL-QN; Tue, 06 Oct 2026 15:27:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441600.1659197; Tue, 06 Oct 2026 15: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 1xE74z-0001aE-Mv; Tue, 06 Oct 2026 15:27:45 +0000 Received: by outflank-mailman (input) for mailman id 1441600; Tue, 06 Oct 2026 15:27:43 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE74x-0001a6-SE for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:27:43 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xE74x-0005nl-0N; Tue, 06 Oct 2026 15:27: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 1xE74v-00DM6h-34; Tue, 06 Oct 2026 15:27: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:References:Message-ID:Subject:Cc:To:From:Date; bh=Ie2ZuA+zUDzrYyXAVifosA8UkUH/9FbQDmI/rKOzWQw=; b=JUXUDo85sKoG9EOuxY58dn7QFs +MByEMV6ya3WTWlJcYGXidN5QDhX/scp1sFF929ojdTAzP9L3TTx3Bhl4gm5PhJdjqSO4lPaEXyr5 oDYQ2aWrGKlLL7zv7a0fC1Yrrj/zaICChmsVt8c2y90cn9XvRBDTrUD8ECu8y/TVIkyk=; Date: Tue, 6 Oct 2026 17:27:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ross Lagerwall Cc: xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jens Axboe , stable@vger.kernel.org Subject: Re: [PATCH] xen-blkfront: Fix IO race during unplug Message-ID: References: <20261006135807.2571779-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Oct 06, 2026 at 03:43:44PM +0100, Ross Lagerwall wrote: > On 10/6/26 3:14 PM, Roger Pau Monné wrote: > > On Tue, Oct 06, 2026 at 02:58:06PM +0100, Ross Lagerwall wrote: > > > During unplug, blkfront stops the hw queues and marks the disk as dead, > > > then later during removal calls del_gendisk(). However, IO issued after > > > the hw queues are stopped but before the call to del_gendisk() will be > > > queued but never handled. This causes del_gendisk() to hang forever > > > waiting for the queue refcount to drop to zero. > > > > > > This can be reproduced by issuing IO during an artificial delay after > > > stopping the hw queues. > > > > So the window is between the blk_mq_stop_hw_queues() and > > blk_mark_disk_dead() calls where requests would be queued and never > > processed? > > Yes. > > > > > > Fix this by simply not stopping the hw queues directly. Marking the disk > > > as dead also freezes the queue which prevents new requests being added > > > and it synchronously runs the hw queues to clear anything pending. > > > > I think this likely needs expanding a bit: the disk is already marked > > as dead with the current logic, and in the same place in the code. > > > > > Fixes: 8e141f9eb803 ("block: drain file system I/O on del_gendisk") > > > Cc: stable@vger.kernel.org > > > Assisted-by: LLM > > > Signed-off-by: Ross Lagerwall > > > --- > > > > > > I'm not sure about the Fixes tag. It's the most likely looking candidate > > > to me but I didn't confirm whether it actually introduced the > > > regression. > > > > I was wondering the same, and even then someone might argue this was a > > latent bug in blkfront itself, and the reference commit just exposed > > it. I don't have a strong opinion. > > Good point, I might be inclined to drop it then. > > > > > > > > > drivers/block/xen-blkfront.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > > > index 8dad7bf5f664..69a2315a1b20 100644 > > > --- a/drivers/block/xen-blkfront.c > > > +++ b/drivers/block/xen-blkfront.c > > > @@ -2138,10 +2138,8 @@ static void blkfront_closing(struct blkfront_info *info) > > > return; > > > /* No more blkif_request(). */ > > > - if (info->rq && info->gd) { > > > - blk_mq_stop_hw_queues(info->rq); > > > + if (info->gd) > > > blk_mark_disk_dead(info->gd); > > > > So blk_mark_disk_dead() behaves differently when called with the > > queues still active? > > Yes. In both cases, the queues are frozen and the hw queues synchronously run, > but the latter is a no-op when the hw queues are in the stopped state, > therefore it could leave requests unprocessed. > > How about this for the final paragraph of the commit message? > > """ > Fix this by simply not stopping the hw queues directly. Marking the disk > as dead already freezes the queue which prevents new requests being added > and it synchronously runs the hw queues to clear anything pending. If the hw > queues are stopped when calling blk_mark_disk_dead(), running the hw queues > is a no-op and can leave queued requests unprocessed. > """ LGTM. I think it might be best if you send v2 with that adjustment and the Fixes tag possibly dropped. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 06 15:29:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 15:29:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441606.1659206 (Exim 4.92) (envelope-from ) id 1xE777-00029E-3o; Tue, 06 Oct 2026 15:29:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441606.1659206; Tue, 06 Oct 2026 15:29: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 1xE777-000297-13; Tue, 06 Oct 2026 15:29:57 +0000 Received: by outflank-mailman (input) for mailman id 1441606; Tue, 06 Oct 2026 15:29:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE775-00028v-25 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:29:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE774-00CbYT-Ey for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 17:29:54 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac513e2-e002-0a2a0a5209dd-0a2a450cb50e-20 for ; Tue, 06 Oct 2026 17:29:54 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac513f2-f479-0a2a450c0019-d1558029dc62-3 for ; Tue, 06 Oct 2026 17:29:54 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a16aaf2067so34618355e9.0 for ; Tue, 06 Oct 2026 08: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-4a178daa062sm80543095e9.8.2026.10.06.08.29.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 08:29: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=1791300594; x=1791905394; 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=GPM7tKYSfVV9A3TLCFS0unR2J4EGEcNKPYw+N+p8nTU=; b=C+3Ry2pKbPKvgdIDVc/BZ8EqYH175MAeEhsNQ0B4xhRyHF07gXbhL4URvTpBp0B2Za Lo1wjMICM2YoMnf6m+TQV4gN3XzX1raeiTd6c+1Yfxaxd/faD06wjHN+NaEIdKDL64F8 MftWxbEJdoiMXusOkmB3RH0OmMyMAToAf3mBCUDzcWW+01BbetNJg4SZvz4itc5QpF7O g3UJdchStvJdrkM7gFBMnTaIUzKBVwqvN7V6RUypWKeb4IJQ944yaxp+3LeNRXOi1u8e 8GG0Hl8+IEI6yn0W/oX2svTRrRnW2iywgSAhpG9jfyRUGxzjiYlIoVFojgLld5zvBCpg iifw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791300594; x=1791905394; 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=GPM7tKYSfVV9A3TLCFS0unR2J4EGEcNKPYw+N+p8nTU=; b=v+pjphd+1PBk1qrRcKvHVXerkqDHJJQjXfEihU+FdADhHXkRLaNGTQ+CUXbYICePXu cdd8Q93CT4lkVJE5HG7op1WKcOGNUrHfi0TMXoFIOF4G0aWs6EUPLzPBmvHMUnCc9o3h sZeAyNPcLQpPnHjRro79h+hMBLjr4RAdz+805nR5yWBakJ5xVivmYLna/LE+8eNRjdC3 FFy4Zth4cz8Ix5Q23QtgqhHph/Sm5JDG7wBmXxJrbZ4UqcZBdyJSm6oh+AALsu166Z7H +qebH2UbTcgRvzYB1N8LIRLwO3nA+pPZr3K7uH/WedYGzquN8w5oxDR5y+P+LamQjPnh dYRQ== X-Forwarded-Encrypted: i=1; AKwUvBzUZ1O+golosXrYiHemL1iQKeBwgphDQiZ01jkVnjBKEMyniGogqTkrriUZWvfu9xYtZsU3Iy3r7wA=@lists.xenproject.org X-Gm-Message-State: AFuF++mLQrmaEhzbFG7QT6pjhCTr+DnLbS9VHeAfi24+0oEuMyFXvOWH 8spJrDSlwwd7s9iihX9JuCj5XNoIiiBQ3Vt8iDSVCDmT8VGYqedc12OdpZDRJPr1wA== X-Gm-Gg: AYBFou3XM2FtIOn4bpMpzy+GOXKPvRG53Gt6GwQojhLu8C+3DEcrht7Mze4zFPA7lSG chUzsDpbmp3Rt1Z4sNAT9N0/D8NrG4p5WE1mZna6qdXNDN8vejyxi7JvB+/5Q9LccXmWnLDLzFP sFIhHnHV64nFNBJhbQLWbTT4Akg8I8ajYnKKzSQf/VKQgmK+XVc26Mc/0TH+3s42rZ5Yo+ycchL wBximGPveXBkMbvD31CSk1vk18190o4yP0ci8BJvdQHVUR6URA55uKnB8Z97q/iq668/uJo9Wju 2Zkc6L8jHiqv8TsGSUUd41vNEvdkGqpFMJ6E785q9U0U6Vupp5sTEZlxwIri9gkFEKA8qQEGEHA xZGHraMPokCgsOFPRSvMgLKIRXBG5qe/5+Je5aFtVsJJ0NLG2t2O39f/8DDX1ZnD7u1FYXdgbRI wm0SX/NnDnqQ3lOV2naMxOQaztfnWVv2W9Ajg22BXo0VF11UAk1f1YDk287W4G/4Ipfv4CQ880J BdWEhq0zVKrP6VB/kQhRIHMK4lkP1nMpjH+wif7zFB/SSP+B98PEEYHb4Sdm6wsltE0TOj0Fw== X-Received: by 2002:a05:600d:82e7:b0:4a1:7baa:7303 with SMTP id 5b1f17b1804b1-4a17baa75dfmr31284515e9.7.1791300593802; Tue, 06 Oct 2026 08:29:53 -0700 (PDT) Message-ID: <17bc987f-6624-4580-a8ee-ee593092e051@suse.com> Date: Tue, 6 Oct 2026 17:29:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6] 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: <5d6d418ef2c89c706e220d38f230a351d4266d66.1790779581.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: <5d6d418ef2c89c706e220d38f230a351d4266d66.1790779581.git.abdelkareem.abdelsaamad@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1791300594-016C6A5B-E9663F09/10/78276251493 X-purgate-type: spam X-purgate-size: 6815 On 30.09.2026 17:50, 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, Section 15.20, Event Injection, 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, Section 15.20, Event Injection and Volume #3, Chapter 3, > General-Purpose Instruction Reference (INTO Interrupt to Overflow Vector), > 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. > > Signed-off-by: Abdelkareem Abdelsaamad > --- > Changes in v6: > - Replace APM revision numbers with section titles in the commit message and > in the comments. > - Review and Correct the testing matrix > - Correct the swapped Naples/Genoa entries in the testing matrix. > - Add the missing X86_EXC_MC, X86_EXC_XM along with the other missing > vectors. > - Combine #BR and #OF exception vectors handling. > - Change the vmcb_valid_event_inj_types_mask type to unsigned int. > - Drop the logging of the exception type from the invalid vector error log. > - Drop the clean up of the svm_vmcb_isvalid function. Code changes themselves look good now, yet of course only as far as we have reached agreement. The remaining open issues (#XM, #MC) are attempted to be covered by the testing matrix, yet I remain unconvinced. I'd therefore make ack-ing this change dependent on buy-in by other x86 maintainers. > --- > 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 vector: 0x2. > 3) 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: > ---------------------------------------------------------------------------- > | Ex. 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 | VMEXIT_INVALID |Guest Triple fault| 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_NM | | | and the VMCB does not | > | X86_EXC_DF | | | have CR4 | > | X86_EXC_TS | | | X86_CR4_OSXMMEXCPT set | > | X86_EXC_NP |Guest Triple fault|Guest Triple fault| with the vector | > | X86_EXC_SS | | | X86_EXC_XM. | > | X86_EXC_GP | | | with the vector | > | X86_EXC_PF | | | X86_EXC_MC. | This continues to be odd: I can't help the impression that the start of the last sentence was lost. With #XM and #MC being somewhat special anyway, I wonder whether they wouldn't have deserved their own separate cells. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 15:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 15:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441622.1659215 (Exim 4.92) (envelope-from ) id 1xE7UQ-0006Xw-1e; Tue, 06 Oct 2026 15:54:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441622.1659215; Tue, 06 Oct 2026 15:54: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 1xE7UP-0006Xp-V9; Tue, 06 Oct 2026 15:54:01 +0000 Received: by outflank-mailman (input) for mailman id 1441622; Tue, 06 Oct 2026 15:54:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE7UP-0006Xe-9y for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 15:54:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE7UO-006NKR-N5 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 17:54:00 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac51993-bab6-0a2a0a5309dd-0a2a4505d61e-8 for ; Tue, 06 Oct 2026 17:54:00 +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 6ac51998-4cb1-0a2a45050019-d155dd31ed72-3 for ; Tue, 06 Oct 2026 17:54:00 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48afcfc4bf5so2547415f8f.1 for ; Tue, 06 Oct 2026 08: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-48c71bd7983sm397837f8f.6.2026.10.06.08.53.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 08: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=1791302040; x=1791906840; 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=4g9CXwELqpWjzsgCZoklKrzBPFR4ZL4W/Epm/kBzmpk=; b=Hj3Q2kPNkP6JGzVMi72BGXfanQhb38GGFScyzP37XdYsTD4DIj7JnAnbnbgX53GSAG 2pfglQEzR5G/gyJynKwjV0GCcuS1zNzXvNF4jygjrR47hG0ojhwuYvKLht4yZoicaSx/ cdhn109uMwULgZlrvdtr5Zoz+3kl9+6QvKqqQc5EkOC9axapyOGI+SYG8QumNWikt8mX ZZv3C+FNwdJ/11eljIQeHfXu4NQMNkYwgDbNrsVb0HpUqo1jfsyzw6QjJvdDQVwlZn+b TGTXQj0kwegFSfd6q7wchU/PKEr7rc/r2xBBw7p9Ks7SrhmMin0B8w5Lj7vn5PxsxvWE gehw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791302040; x=1791906840; 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=4g9CXwELqpWjzsgCZoklKrzBPFR4ZL4W/Epm/kBzmpk=; b=V8jHLFLCm8zFhFehLOg0ztMQPdvJzr375gOSPpwDPug8cmRan4xQTepL44jetUeRfO FkZYm9ZLDTleyFyfhSGgBArw9AcPu2FqUU+Jgb403Cve32AawqysIVqFBZeN7WmBe063 W8vR1UnCRGGuZkq0DqCGLuHAdQHkLjs23dHFXHC+Aj79kPonw5nBx+9QpF85tTloyV/p R+axWdKPZ4p1D6zu9RPt6GVwajmOMe0Hn2rozWmDYXCF1c4xBOkjYazckMxrNaHRpFZJ N2wK1srIBLz5kYS5wwMyk8T4WqVptLeRvCSeEdjG2FjxSnGwYOC0xZ79X8mn02/3NXDk UCXw== X-Gm-Message-State: AFq9FYL8V506drmxPVJi3BKK5zKYeU6XpdjjPNSyUT9vvfoctS4mUalv Fh8FJXR6HpBUGXUHo1v9Gf8NHolRuF2h5eVdzTsaZN5T9v4A6i7b0vG+fQNEsNTHew== X-Gm-Gg: AYBFou1qPP5gp5jyNhYfMaIaDl/wvGfOBWmD+mLYUDxYJ4lxIELXQB3xHDh9JS87UZB mE/6+wmD0OXT+5OMU2kCq+FkJq52BhujcIZb6pLT3hxsboq9m87JybTyrBWpl5ipT+ywOZtdO37 qfYmTLxe/MBY+57GnZWrq2ct9YsROOdeaw2VjpZeRCOO0oMNFAMhqaf8a+ci4c4gZXrAHp0CPnJ qmjTxBorJhfbZO5DT2jb3mzh10Xm9wiRP9QvK4VufZd0u1iRCMxAMec2zJm4PypkAvl9P6/Rj5W ihdZwZzifRvaxZJbXi76AW0yKIAaks/2/PnisZvFVtNfpVLOgQiL3+CjcICJOxzdqmwDIECq4dB Lcd1AoJtEMJV95oOQM1BIBX8UbQkHCixPe0QhMcJhZ14jJbw+JWLjdJlR16v8G6K4kWGo0GjKJj BnB+G3QqGUgvUyIaqa26tMIHQsVOhKPcRt8LxNsuRlvYNiKZz4gpRnoejcqniLpKCcoExFSZAfH zJFVosbzhAH8FA3b0yeskVUEULBuKHY0D7uBOpWWr71u0MSBKUdBPuwWOC7gA== X-Received: by 2002:a05:6000:2413:b0:48a:fcec:2a29 with SMTP id ffacd0b85a97d-48c6d15fa2fmr2828598f8f.20.1791302039838; Tue, 06 Oct 2026 08:53:59 -0700 (PDT) Message-ID: Date: Tue, 6 Oct 2026 17:53:58 +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> <87h5jh56ji.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: <87h5jh56ji.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791302040-716AD2A1-38884D9D/10/78276251493 X-purgate-type: spam X-purgate-size: 2991 On 22.09.2026 23:18, Volodymyr Babchuk wrote: > 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 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. > > ... 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, This has nothing to do with acpi_uintptr_t, and also looks to never have been committed. Were you instead meaning to refer to Linux commit ae57857b9b63? (Oddly enough that commit links the URL you quote above, just that that's not the patch which was committed.) If so, from a Misra perspective this has a significant downside: ACPI_CAST_PTR() could then be used to silently cast away constness. This, imo, is something we want to avoid when the goal is to make our code more safe. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 06 16:05:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 16:05:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441629.1659224 (Exim 4.92) (envelope-from ) id 1xE7ev-0000Q5-W7; Tue, 06 Oct 2026 16:04:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441629.1659224; Tue, 06 Oct 2026 16:04: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 1xE7ev-0000Py-TM; Tue, 06 Oct 2026 16:04:53 +0000 Received: by outflank-mailman (input) for mailman id 1441629; Tue, 06 Oct 2026 16:04:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE7eu-0000Pp-Rm for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:04:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE7et-00F1Ic-KT for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 18:04:51 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac51c19-bab6-0a2a0a5309dd-0a2a45079a7a-12 for ; Tue, 06 Oct 2026 18:04:51 +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 6ac519c8-b4ea-0a2a45070019-aceafc1fbd12-3 for ; Tue, 06 Oct 2026 17:54:49 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id E8EB643489; Tue, 6 Oct 2026 15:54:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 832FE1F0089B; Tue, 6 Oct 2026 15:54: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" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791302087; bh=clRq7rLolI7UK6CY7Y84Un2wUkXIEjH+9LwAXBd+654=; h=Date:From:To:Cc:Subject:In-Reply-To; b=kmnqSnp8AQWKgKdWrXoR3wDP+wjZUfn0pa14Qbsbq0r/YRFOUxfueCxsdsEknVCXS t7PP0lZ60nZVeVas9F+t2Vfv5o2EPyNvh2FhdIqQilg6Zh2lHGXbDkPTowRhjGmder z8oDV+mQ8xqoyLn7+5SUpvn6xTr/npXpvaWIPXEJeOMumGmQV4CNCbJWcj74piLf2t iKdg4RCQQPts16smNQbEtxsGsVa0akn/c0KWEkXDHjMetIynK0hp6K/npScVIlNyKo mwc97d3hDfTvfazgVZx+atdqMV2MlxNiB1/Xf4caiVOm7ghajAcl3q/Y4e3VJD+Ct8 ClVrQlwJl7IhQ== Date: Tue, 6 Oct 2026 10:54:46 -0500 From: Bjorn Helgaas To: Yehyeong Lee Cc: jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, bhelgaas@google.com, jbeulich@suse.com, konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] xen/pcifront: check that an AER callback exists before calling it Message-ID: <20261006155446.GA684274@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr> X-purgate-ID: tlsNG-ef75cf/1791302090-35AC0AE4-D9AE25DF/13/0 X-purgate-type: clean X-purgate-size: 3165 On Tue, Oct 06, 2026 at 11:34:43AM +0900, Yehyeong Lee wrote: > pcifront_common_process() handles an AER request from the backend by > dispatching on aer_op.cmd to the bound driver's PCI error handler. It > only checks that err_handler and err_handler->error_detected are present, > then for the mmio_enabled, slot_reset and resume commands it calls the > corresponding callback unconditionally. Those three callbacks are > optional -- the PCI core NULL-checks each of them individually before > use -- and many drivers (for example igb, igc, ice and ixgbevf) install > error_detected without all of them. > > aer_op.cmd comes from the shared ring, so a malicious or buggy backend > can send XEN_PCI_OP_aer_mmio (or _slotreset/_resume) for a device whose > driver leaves that callback NULL and make the frontend call through a > NULL pointer, crashing the guest. > > Check each callback before calling it. When mmio_enabled or slot_reset is > absent, return PCI_ERS_RESULT_RECOVERED so recovery proceeds, as the PCI > core does for a missing callback; returning PCI_ERS_RESULT_NONE would > instead make xen-pciback tear the guest domain down. > > Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.") > Cc: stable@vger.kernel.org > Signed-off-by: Yehyeong Lee Acked-by: Bjorn Helgaas > --- > v2: return PCI_ERS_RESULT_RECOVERED for an absent mmio_enabled/slot_reset > instead of PCI_ERS_RESULT_NONE, which xen-pciback treats as fatal and > uses to tear the domain down. (Bjorn acked v1; the ack is dropped here > because v2 changes the value returned for an absent callback.) > v1: https://lore.kernel.org/all/20261005133019.284053-1-yhlee@isslab.korea.ac.kr/ > > There is an in-flight fix for a refcount leak in this same function > ("xen/pcifront: Fix PCI device reference leak in AER handling"); this > change is orthogonal and applies in either order. > > drivers/pci/xen-pcifront.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c > index cffc32d660327..5c6f7796d204a 100644 > --- a/drivers/pci/xen-pcifront.c > +++ b/drivers/pci/xen-pcifront.c > @@ -599,11 +599,16 @@ static pci_ers_result_t pcifront_common_process(int cmd, > case XEN_PCI_OP_aer_detected: > return pdrv->err_handler->error_detected(pcidev, state); > case XEN_PCI_OP_aer_mmio: > - return pdrv->err_handler->mmio_enabled(pcidev); > + if (pdrv->err_handler->mmio_enabled) > + return pdrv->err_handler->mmio_enabled(pcidev); > + return PCI_ERS_RESULT_RECOVERED; > case XEN_PCI_OP_aer_slotreset: > - return pdrv->err_handler->slot_reset(pcidev); > + if (pdrv->err_handler->slot_reset) > + return pdrv->err_handler->slot_reset(pcidev); > + return PCI_ERS_RESULT_RECOVERED; > case XEN_PCI_OP_aer_resume: > - pdrv->err_handler->resume(pcidev); > + if (pdrv->err_handler->resume) > + pdrv->err_handler->resume(pcidev); > return PCI_ERS_RESULT_NONE; > default: > dev_err(&pdev->xdev->dev, > -- > 2.43.0 > From xen-devel-bounces@lists.xenproject.org Tue Oct 06 16:09:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 16:09:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441636.1659233 (Exim 4.92) (envelope-from ) id 1xE7je-0001A8-Gd; Tue, 06 Oct 2026 16:09:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441636.1659233; Tue, 06 Oct 2026 16: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 1xE7je-0001A1-Cv; Tue, 06 Oct 2026 16:09:46 +0000 Received: by outflank-mailman (input) for mailman id 1441636; Tue, 06 Oct 2026 16:09:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE7jc-00019v-PF for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:09:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE7jb-00HFSK-Sp for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 18:09:43 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac51d40-e002-0a2a0a5209dd-0a2a450690d6-18 for ; Tue, 06 Oct 2026 18:09:43 +0200 Received: from [52.101.65.77] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac51d47-195a-0a2a45060019-3465414d6bed-3 for ; Tue, 06 Oct 2026 18:09:43 +0200 Received: from PAXPR03MB7531.eurprd03.prod.outlook.com (2603:10a6:102:1da::11) by AS8PR03MB9048.eurprd03.prod.outlook.com (2603:10a6:20b:5b5::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 16:09:39 +0000 Received: from PAXPR03MB7531.eurprd03.prod.outlook.com ([fe80::77bc:127a:5664:10e]) by PAXPR03MB7531.eurprd03.prod.outlook.com ([fe80::77bc:127a:5664:10e%3]) with mapi id 15.21.0472.016; Tue, 6 Oct 2026 16:09: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=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=QuhTykO0jnXr3NrvfIiFbq+6X0j72RD3sPSUKtVhOsBAU9ip8tVq7R7afAuTNla3S1bNnsrmEoSI5NFOPHlZGw2xFC7+A15auiJZJoVstMYbRCAv0BeZ7pTxpqrehrxqkTDdtjI0RIteuXZCOMPSiUNUNFcpDe2CwOFrAl9BNxruBMuHIBKfMYf2LTvaZp/BrJbTWN6bOsjYT+GuoLtVy3OhWCEYDhUfKhOtjqN4Wy4e3TFK+P9NcqgqNhzmEn7VvnenNM64EGtHZj+DKC8EQnZSQvur5qJTxougUQplsfjpf4k5OdteJF7a28eykLBUyb8PYChtOJ8q6Jt/p1EOZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RqeqPmRIP55qeuFGubxWMpyfNYitvyBVmzEDNyDZ9QU=; b=nCFyOXw9vJJY1qmv6IE6SFYnPcvx7zVVBADbqOT9i/jGuGhY+SB7919jpYYQN717IxDAPI46G6BVtP2y6KrQgMOvgumQ1Y6sEayFeZTekCA5kGCU4nmgrd0FdhUZGqYC/qvkkyhT8/iFhKtr19ORDDZ4oblhpDPKHIbKxx8rzbZFaRkoQ/YIhp8C88YOh257Z3Ve1FOdtbjOqp9gZ+mh4lIUDaBnbCcxKg+uYsN5WOaxOw4B91/8ap2611PKuW/+Rql1q/eG6UAWOfm6NChpmvCv8B1ZSGHMfdalV5OqtyYHSovHy3PrEgsf7PaLOaxGR7Xw63CXiPulvoHHy+KNqQ== 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=RqeqPmRIP55qeuFGubxWMpyfNYitvyBVmzEDNyDZ9QU=; b=AaVpjb3j472fILMtW1f6nAYBChc/XAjPDZk0c6qKpYuVzkt/E8DNMCtqBu3+FcaTrDuFttYHwUiilTgZujgy311KRk3JW1CYo2eMTBnGyRpmMvhXqbIQoqWvkpWrNLyaPjY4EYSuPNujcutUTn2KegT0yAOgDnkQeUXmamfBUW5ydeD2AHJdz7Iv6NWQ0NZ3UNIwHTe2gblyWDWaSGSpk6VyttLip+t1iARgBr6CYVTQpY11uDpI8Zo111vPUTkZ6n4CNV4H6FM2G4CTqL6qbsVJOQIqcK6EZEIwzyoWhne+tKGa4QHwNMuZdRUdfCw27FqvdAzJMTcrITZtluZAuA== From: Dmytro Prokopchuk1 To: Jan Beulich CC: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH] Eclair: scan the last xen-syms linking pass on Arm Thread-Topic: [PATCH] Eclair: scan the last xen-syms linking pass on Arm Thread-Index: AQHdVZ47rgN8qfc/LUyZracn12XLU7bwnI6AgAASYQA= Date: Tue, 6 Oct 2026 16:09:39 +0000 Message-ID: <8d3b26df-a42a-4d34-bc6c-81ed26839006@epam.com> References: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@epam.com> <03338d69-cbde-4918-8ffd-c309230d337f@suse.com> In-Reply-To: <03338d69-cbde-4918-8ffd-c309230d337f@suse.com> Accept-Language: en-US, uk-UA, ru-RU 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: PAXPR03MB7531:EE_|AS8PR03MB9048:EE_ x-ms-office365-filtering-correlation-id: 53dd9a2c-476f-4054-559e-08df23c4398b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|376014|23010399003|366016|1800799024|18002099003|22082099003|10067099003|4133799003|38070700021|4143699003|260925021911599003|260925022911599003|260925021311599003|56012099006|11063799006|5023799004; x-microsoft-antispam-message-info: vLbLxmB4TkSIB3vFnrKIVYiKq5dC9EdyFKFJD13w8EOzZjlzsOKtUV0v/tE2mCxpUozJJVlUFGLygCUtmQFPWAGdsFSxwjsPunSoIpAeRMwaHaK3bIpvGoOU6gCpURs3o2CKHOAubVx8HBflhsuJdqoRjUyJu+kb49N5YEfAnuAlrp8ifY89TnCYHgnumQ+50+I7bCkIRkz4SWzAE1ZSYqoInQOXMj3oMEYVz5bAIUEvjYvl9QCLCsvTelSkewwxXGfprxnb7w+8wBURum+VAPUDgoo6zPtqRT0K5Y8MRuRbS2168gGKMDkU1zLoK2smpJg3v+/3tiRtqU78jWgaBxwMY1YuKLlB9uV1aVLtInmg1acouK6u4sLdG4oSTpUtuOu15wBwUziidH6IJ+YWJutJn+QgvOs/Gu0cTez3un5Sx9z5ZFnXw5Ge8PL5OCF1W1pXzkZ+6W4Ch1hkIiOeoONzCBEZ0y/MNxEntCNWXH0x8RZSvBtx46HXHDIS8Fb12iWHkts0DI7S6f1lMFp/JHBSRbOFPjYFvWMx0gWRozkQ5I3zh9G0apCzDBD0ky1j0t/WjcN7xgJh4NApsURZNszL/qU5JSOatfCjxjjTpDbWZzG5qaj3WnPQNdUshkURtvpSsssusIFS0opy0qqINJv4RkJEKOAPBZC5js1JuLE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAXPR03MB7531.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(376014)(23010399003)(366016)(1800799024)(18002099003)(22082099003)(10067099003)(4133799003)(38070700021)(4143699003)(260925021911599003)(260925022911599003)(260925021311599003)(56012099006)(11063799006)(5023799004);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VkVxdHo5cVBTcGhUdVliSmppSXBjTGZXWnRoV1RCRkFQT3JQRy8zMlI0Tlhj?= =?utf-8?B?dGgrc1ZsNStOYS9Uc1ZCQlNPZ1F0Q3dDUDdUZG13Q2d1NGhPNjk3dWllUlVm?= =?utf-8?B?SVR3R0h1blp3YmtpVjNqMWdVZkdXMUdHOG1XcyswaGU2MXRUN1ZNMkl1T2Zm?= =?utf-8?B?Mm1CVDNCbTdSTDBQZjVibXBOTytrQmJreGdHN200b0pyU25KVEEvNWczbVpV?= =?utf-8?B?a0F6Z3lyZ1kzQ3EwWDV6czRIRHkxOHVHWTZQQjJTQ2cxSVJFMUFPQWp2YWJt?= =?utf-8?B?c0Nad2VpS0VleW1Kc2pjRkFGOXprUEczWm5LaXBIM2V4emZDTVYxdzhXcE1r?= =?utf-8?B?aHlQMSs3NnNCM0Y2N0Z0YkpuS3hzZldXV3BtT2NpdmZpbkR0dVJLS3M1TGMr?= =?utf-8?B?TXlGa1cvaFJXemd4N3FTRWpYTkZjVUF5VHJqb1l4NkVpZGJPUFJ2U2RTVjNM?= =?utf-8?B?VGFMaXZzYS90bzg4OStmMndzb2hpSVRTUW5KNTV0bUE4V3JTUDJtak40cTZN?= =?utf-8?B?SDBodnNnd01wdTZvRGYzcCs2TXEzT3pPVE1JeDZWaGdLNHpENVhEclFCRTZN?= =?utf-8?B?S1RSTTRyemgya0NSaGpTQXgxcndlTmRqMmdKc3hyOEt3MGxzd3BuUWdtaDdl?= =?utf-8?B?VjNGTldJdGdleDNJTUhKcEthejBhV3ExRGc3RGNjeHEzbEl4c1lLd2tkSHZU?= =?utf-8?B?TitEbm11RjNzdGw5djIxaTVjWVU1em0yVkFlUDFPWVdNTHNlSk84Z2dnU0tT?= =?utf-8?B?d0Zlckl2RXNrNnVCNzZjWm5YbGU3MHhSVFdQdjNraEU5MEI3RGdWNjRldkxp?= =?utf-8?B?bFMrMUJsZG5XdzJnZHY3VUNLZ01MTy9ZVmh5UVJzWkM0ZGlPejhQdWYvMlhW?= =?utf-8?B?d0tYcTUxVy9HekhXTnhCZjJVZ1RBY3ZQbHpha3UwMzB5dTJmQTI5T3FrTUhj?= =?utf-8?B?aXNXTmp4aTdRbDRtbTJESGtLR2Jkdi9WeDFDc3A2Z0FoYTRDb3ZERGN5bU4z?= =?utf-8?B?S0xlRXN6WVVzeWp6NWNLdWc4dTlVQjJ1a3hib3lJR2EveTZFc2hyaDhNT05v?= =?utf-8?B?V3RiSHkzNWY0V3NZV0ZkM0dqdXlXdEYwMkZ0UFhJcTdyWmxvbEdYS25uQ0lK?= =?utf-8?B?bm5SN25OLzJwM0hUQXh5YW5HdkJGSTNBTzFLQUU0UXQzbGVjVW5VUnVqT3Fs?= =?utf-8?B?K2g0Y0YyeWRVUE5CZjN2cG05VUZIRGhLUm0yTjA4MTZycVU5aHR4L0txcjdK?= =?utf-8?B?VXBPdXR5OWt6VHBET2pnNmRxMmZpK3E3VGpnNlRTeXNwd00wTDhXOG5NVUgy?= =?utf-8?B?blhtWWdRNUsxZXM4c094aEVUVDhOaWNxY0p1dnhxTUtCL29ya1ZkK2xGdUd0?= =?utf-8?B?N3pMTDFINFNQOHZQd3RBQVVJUGpXYjdleWduaU1yRGwvVmRyVlAxczJ4bVlw?= =?utf-8?B?Z3hlcjZJUDZqMGxSM3hvTkwyZVRRYlpKclZHN0Fuc3ZtMHM5Q3djNU1aWUlm?= =?utf-8?B?VDVEb0oyZk9PeGpJR3lqMmUvNkNRY3ZkYVYrOGR0ZkZ4d0dtVGdFN1FuT2xr?= =?utf-8?B?SGNrRHEwdTdBR2FDOE5MajhvZEljWmpZL1h3NjlXeURTbENUVUErSms3eldq?= =?utf-8?B?eHlsNDN5ejBINWhrMmJOOHQwSk4rWGp4Y2o3aTBNWnRHamw4Ym40UkZlM3RB?= =?utf-8?B?UGNhalpEUDhXK080YWJSdWU4cjZXMWkvUU9GeHJFTHJ6QXQ5TlBBRWVyR0ha?= =?utf-8?B?VnhkdWFoZ3A2THU3Z3ZFSWE1cUd3VGhNdnJxazFPR1dkV25xZUhTVlI4b2Y4?= =?utf-8?B?SnRYZ2RkOFJIaDZBYTg4aE1GWjZiL2hIMkRXd1JPZTNIMlphM3NPY3dNZHA2?= =?utf-8?B?bVpkbkt3OXYzaDhDQXU0cWx3Z3lFMzF6Y0p2bWZTY1lSVDdtdjAzQ0tHSDRJ?= =?utf-8?B?aFN2NUlUdWM0aHM3c25IY0M3d1BDYXVuSGZUbk0xZFQwelg2THlwRHlhcEJ2?= =?utf-8?B?aWJrUDRmTEtHQzg2WE1KNGpJMld2b3NlWnpSMDVMZytDY0NpTHZBa2NieHRF?= =?utf-8?B?S3RidHU0WGxlV0VzSm9mMHBoRDNFS3hiaTYyOEgvMXJ3TVhUY3JQT2V1Nk5a?= =?utf-8?B?MlBiaTBobDRaMDdTK1ZGVTdFd2E2YkczcmVMUnV4eTMxWDJqOHVzeXdQN3ZB?= =?utf-8?B?Qm1IbjJvVnY2U3AyL3k5TkpoS3AwNVFaV244V2YySFdsWXhJYjZxdTdJeUhm?= =?utf-8?B?Mmt0Mk0xeUJXQ0tscDlXSFpYaUorY1JaeVhmb2htK1E1NHZYRkJPNmloaG1q?= =?utf-8?B?MjVRYVpDREhEb3NGYURnWHZuZnJpc2ptVjRkUkxWa0UrOVh1MkMwcU9OcS9Z?= =?utf-8?Q?0vpgLvR0sGsBQ3rA=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: PAXPR03MB7531.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53dd9a2c-476f-4054-559e-08df23c4398b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2026 16:09:39.5336 (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: 0ex+7zU8fd6d0hS6g0Q3e0SKXfoXOYKELn8ZD9KNmexjAU3c/dBL6rRffZwb7Mwbqy/oBHUYAyRyP8UbbFSFAQ01s17WfudXdyZZ2xVeRhU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9048 X-purgate-ID: tlsNG-16d1c6/1791302983-FC80577B-8AB3F8CB/0/0 X-purgate-type: clean X-purgate-size: 2502 DQoNCk9uIDEwLzYvMjYgMTg6MDMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNi4xMC4yMDI2 IDE2OjIzLCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+PiBIaWRpbmcgLnhlbi1zeW1zLlsw MTNdIGFzc3VtZWQgdGhlIGFsbW9zdC1maW5hbCBpbWFnZSBpcyBhbHdheXMgcGFzcyAyLg0KPj4g T24geDg2IExBU1RfTElOS0lOR19QQVNTIGlzIDIsIHNvIC54ZW4tc3ltcy4yIHN0YXlzIHZpc2li bGUuIE9uIEFybQ0KPj4gTEFTVF9MSU5LSU5HX1BBU1MgaXMgMyBhbmQgdGhlIGZpbmFsIGltYWdl IGlzIC54ZW4tc3ltcy4zLCB3aGljaCB3YXMNCj4+IGhpZGRlbi4gUGFzcyAyIGlzIHVzdWFsbHkg b25seSBhIHN5bWxpbmssIHNvIEVjbGFpciBzYXcgbm8gcHJvZ3JhbSBsaW5rDQo+PiBhbmQgcmVw b3J0ZWQgZXZlcnkgdHJhbnNsYXRpb24gdW5pdCBhcyB1bnJlYWNoYWJsZS4NCj4NCj4gV2hlbiBJ IGRpZCB0aGF0IHdvcmssIHJ1bGUgMi4xIGVuZGVkIHVwIGNsZWFuIGZvciBib3RoIEFSTTY0LSog YW5hbHlzaXMNCj4gam9icyAoaWlyYykuIFVwb24gcmUtY2hlY2tpbmcgSSBub3cgc2VlIHRoYXQg QVJNNjQtYW1kIGhhcyAxNzcgdmlvbGF0aW9ucw0KPiAoYXBwYXJlbnRseSB0aGF0J3Mgd2hhdCB5 b3UgdGFsayBhYm91dCBhYm92ZSksIGJ1dCBBUk02NC1hbGxjb2RlIGhhcyBub25lDQo+IChodHRw czovL2dpdGxhYi5jb20veGVuLXByb2plY3QvaGFyZHdhcmUveGVuLy0vcGlwZWxpbmVzLzI5MTY1 NjkyMzIpLg0KPg0KPj4gU3RvcCBoaWRpbmcgcGFzcyAzLiBQYXNzZXMgMCBhbmQgMSByZW1haW4g ZXhjbHVkZWQuDQo+DQo+IFRoaXMgd2lsbCBjYXVzZSBzY2FubmluZyBvZiBib3RoIHBhc3NlcyAy IGFuZCAzLCBpLmUuIGNvbnN1bWUgbW9yZSB0aW1lDQo+IGFuZCByZXBvcnQgZHVwbGljYXRlIHZp b2xhdGlvbnMgd2hlbiBib3RoIHBhc3NlcyBhcmUgcmVhbCBsaW5raW5nIHN0ZXBzLg0KPiBJIHRo aW5rIHdlIHdhbnQgdG8gYmUgc21hcnRlciB0aGFuIHRoYXQsIHRvIHJlYWxseSBzY2FuIGV4YWN0 bHkgb25jZS4gSQ0KPiBkb24ndCBoYXZlIGEgZ29vZCBpZGVhIGp1c3QgeWV0IGhvdyB0byBhY2hp ZXZlIHRoYXQsIHRob3VnaCAoYW5kIEkgd2FzDQo+IHdvbmRlcmluZyBhbHJlYWR5IHdoZW4gcHV0 dGluZyB0b2dldGhlciB0aGUgb3JpZ2luYWwgcGF0Y2gpLg0KPg0KPiBKYW4NCg0KSG1tDQoNCkF0 IHRoZSBtb21lbnQNCihodHRwczovL2dpdGxhYi5jb20veGVuLXByb2plY3QvaGFyZHdhcmUveGVu Ly0vcGlwZWxpbmVzLzI5MTczNzU3NzMpIEkNCnNlZSBBUk02NCBSMi4xIHZpb2xhdGlvbnM6DQot IDE3NyBpbiBBTUQNCi0gMjQ5IGluIGFsbGNvZGUNCg0KQW55d2F5LCB3ZSBjYW4gaGF2ZSBpZi1l bHNlIGxpa2UgdGhpcyAoY29waWVkIGZyb20NCmF1dG9tYXRpb24vZWNsYWlyX2FuYWx5c2lzL0VD TEFJUi90YWdnaW5nLmVjbCk6DQoNCi1zZXRxPXRhcmdldCxnZXRlbnYoIlhFTl9UQVJHRVRfQVJD SCIpDQppZihzdHJpbmdfZXF1YWwodGFyZ2V0LCJ4ODZfNjQiKSwNCiAgICAgZmlsZV90YWcrKHsi eGVuX3N5bXNfdG1wIiwgIl54ZW4vXFwueGVuLXN5bXNcXC5bMDEzXSQifSksDQogICAgIGlmKHN0 cmluZ19lcXVhbCh0YXJnZXQsImFybTY0IiksDQogICAgICAgICBmaWxlX3RhZysoeyJ4ZW5fc3lt c190bXAiLCAiXnhlbi9cXC54ZW4tc3ltc1xcLlswMTJdJCJ9KQ0KICAgICApDQopDQoNCl5eXiB0 ZXN0IHBpcGVsaW5lIGlzIGhlcmU6DQpodHRwczovL2dpdGxhYi5jb20veGVuLXByb2plY3QvcGVv cGxlL2RpbWFwcmtwNGsveGVuLy0vcGlwZWxpbmVzLzI5MTg1NzE3NDkNCg0KQlIsIERteXRyby4N Cg== From xen-devel-bounces@lists.xenproject.org Tue Oct 06 16:34:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 16:34:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441650.1659242 (Exim 4.92) (envelope-from ) id 1xE87h-0005yQ-Ah; Tue, 06 Oct 2026 16:34:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441650.1659242; Tue, 06 Oct 2026 16:34: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 1xE87h-0005yH-7U; Tue, 06 Oct 2026 16:34:37 +0000 Received: by outflank-mailman (input) for mailman id 1441650; Tue, 06 Oct 2026 16:34:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE87f-0005yB-Sq for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:34:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE87f-006da6-5v for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 18:34:35 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac52301-2eae-0a2a0a5409dd-0a2a450aa3da-36 for ; Tue, 06 Oct 2026 18:34:35 +0200 Received: from [52.101.193.60] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac52319-f2d2-0a2a450a0019-3465c13ccb10-3 for ; Tue, 06 Oct 2026 18:34:34 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by PH0PR03MB6461.namprd03.prod.outlook.com (2603:10b6:510:b4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Tue, 6 Oct 2026 16:34:30 +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.0496.010; Tue, 6 Oct 2026 16:34: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=nwmMaH2wEDHsEMdt8YR2lgSM5/MYhTj+dyc6ZPY0ypfbfcS/intpwqM/teETiicQwYzdAJ9b3OLoM9Dn5MgZ8KHc6br+Y/PkWFchLSfb3xZKLyi1bmljhQljJJzqUm1rugRyswV0R223shPNP6NR14hpwabGfQSIEScMHXII9YCFIl0CD/+H9m6FV9XUQkSvrJwvr9pSbOjHCuZuQ/yrOW9gJDgeeSnF8mqfnieaBioY4ILVQVCnYa/6o+1jhIu22NkMkomOHZwd65J65UFg8LHocxlWOWVICA6ferYvOp0G9PUj3srXltwldTCpGcqttq0/zWWL02NrJas5GXjrWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1OxaphSh9OHqUGgjs4IJ7W2uOKFI7yP7g6SNyO+K1N8=; b=IlLhTRhFx6IIdcWsGr1K6l6PRMvyZ2ZGTmMBHMp5XXQEESH2PEaTPHBF/P0xBleooSOyyPbsYefYuqPJU7FEMhtH6PyPBB1yuGFubS84rY3g9WY02Lp7uLbSU2zxoz6p0Mv//+oCUTa3IcbT2ECD/mXryefD3CHqO8IJGDDRiKsUhfvKJpr50L2spWJTK+XxpNbk8WSfcdc9zx+WsQnWF26VAGCkfxplpN+RcZ4X2HVPH9Szf17JwcPS0/loCZG+WbLq0r7QqAx5/Kb3UgC6qTVSyxdtqJZ65/JI0tFQzCxum+sRUj1Z3XUD8BflXP7hYAoAFyOyRsvAHuQns4ttmw== 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=1OxaphSh9OHqUGgjs4IJ7W2uOKFI7yP7g6SNyO+K1N8=; b=eyzWJUI2avQEM3L3HVwKCSxDWQNE/1KFj3z5YxAwUBhK3h7kzEs5TudOpGnPwB2zA7kTFFO6M0D40I12ZI4hTRf2zKs5G6a8Pb+BQ7yYhPqZN9mkLDpwaZ3lxVkThmBYYINnjOGg6XPM2Ixx1AMTQOz9QkyXCgvBHsnaV2+/+0M= Authentication-Results: mx.microsoft.com 1; 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, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Ross Lagerwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jens Axboe , stable@vger.kernel.org Subject: [PATCH v2] xen-blkfront: Fix IO race during unplug Date: Tue, 6 Oct 2026 17:34:07 +0100 Message-ID: <20261006163411.2583538-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.55.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO6P123CA0016.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:313::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_|PH0PR03MB6461:EE_ X-MS-Office365-Filtering-Correlation-Id: 66d022da-a89a-4495-4086-08df23c7b212 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|18002099003|10067099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: CYBLiXY2ZTp37FuWMqKMQH8K/bYjwZ/8Xzxw1a/L8zdg3jBSTUaPD89wEfW99bUl/5nlFfhZrf4zN8FJ/Ka5BlIAC6kGD4/AQqDQcZGFfbSwYhPW1infCJbvX1q9kJiHM005dLM+PJBPg+6yq2tdsTO6f5gEz4RXOSl2JsDagF88cOG9aWP1Kc0pdv1dNb5o9E8+8LzJtbk47pP5jU2wRSO6Rw5zYXsvQuHD9uQjY5uU7P5c/LENCEBVSBpgTMUwfMlhESv7K3wsxjUCQeBcJpXOjzFEQhievn3db3VOx8gridMjSHU2q7AkP8B5PQCZlL0cdAxM9qgtb7UsWO5DkGScp6WMioinZYXrJkGqs7kb5+rNiWnf6P0STmJvl2GHabvKQH9M0dZrlExll3reJuHjF15pfZnDqE19yFUJg1L4SoLDWq9ePEeURickTsi5vOTXWrS5tyemmFn1VayjH0l28NCkHi6j2cBAhqQhEYzKZjanPfRrbLpwGBBeGwufHtOA6M3U9RtNPnb/0gYE41zQdiZrhbQQCit7AquLaAsFlZyTODN6UEp2FV4mnbOlL5nLzLKlRvAzBi5DfgF15u2VrJvctr50DZ+tsE6ra0DRFZONVZXr8kVe3aZxihfsCERaaSV7ZOQVragcVxPFDdywf/Cmki5Ct7cq+LRr0QM= 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)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ixtIcJTG883rvOudMTOFFdnNFQlXMw1kevo3evFoKhS2BsBzClIKKI/2zKwr?= =?us-ascii?Q?rb5Q9rxe69leSHtlpAeeGgeCxeqx2IdgIntuq4Oo9x9tPU/yeoUhggcxG8/w?= =?us-ascii?Q?t0DyOG0co5yUWXPIcvTaEZLo28n4CHvWKtONms8Qw7yawytk4uTgG+ZIMgfa?= =?us-ascii?Q?PkJYqVddpYVYNTqSBQqESS0GnlsKeUKTojWaldyEYZL2MJFRnHIafIYoer0p?= =?us-ascii?Q?T7Na7f+33LOwfjyrXvRdpDWftUGaFRShbIfrogtNza5Y38VvX5kY0yLplwpt?= =?us-ascii?Q?rAGMI4JM2+hmmqOBCO97Y/QztaBWMkj1/ShUUVGnRZ5wnavvxsYepkzwtkjG?= =?us-ascii?Q?XoO630PGu5HQGLDMsQzVQe7mf63FaI6rA8IYxZfkAxfsNMPHSlqyjRsO9UZj?= =?us-ascii?Q?ClNYnFULMTcxvV3XtP2iv6RRm1gAYywjivVuOiEBj5l5djmzmBX+Cv6Syhk4?= =?us-ascii?Q?3MfZvqDDIhnXRLmJ+l+xub6cQX5tiHs5eh3WtlhcT/7N7vmsvBUx1F6+E6gs?= =?us-ascii?Q?D6/3qHGQ2A/19hVzTHF0jZd8OKhw0b7Q7Lfb6uHtX0WEjSItagf3l1hjVEqO?= =?us-ascii?Q?GH1UXGfvz7cJW6BC8vpgS8TWvsgZ80klzQECzSgCtXUMC9jeuNz6+hyatGLw?= =?us-ascii?Q?28nqIzYdrkYOQF2LyJZg+dcLfxU2POsHOm0mFG2RXoRhAvhfDtGy2jS4g3Lq?= =?us-ascii?Q?wEZKdivObVwUp+c4A+K4t+NPTDfUJbj4UgQqBZ6MvvgikaPm27ICOv3BobAj?= =?us-ascii?Q?bFBhV7jn7wiF/TaakrphaCDYVzUTp58awJDozfZiCxKnosejDBwsqlidBJXx?= =?us-ascii?Q?xHWITp+bwjIwJZiODEhFbssZlH4FGY25uX/wilRF9TD8vNmuun+B0O1sQQJJ?= =?us-ascii?Q?d2tYgb9n2gpHWHRxn20kFXdZ+JYFYb9paLCPfXUrFH/X4Zt4XJCD/DK2NfH9?= =?us-ascii?Q?aYjXp96774q/ye7TOjxUVy71yDIqHngiNVBDfv3gXXa9+l5DnlQEQaM+hQyu?= =?us-ascii?Q?HR7gAxB7zTNjzYWrsT2CzUR/H3XaXA/T1Ux1/4ZWsrgPb0h5YQI73UnYIZuo?= =?us-ascii?Q?VHcMUGN3J2xzoRE+qyxmm9EOsL5FlT1er/mjxT/xdqguZy+AgsnZnc2vR38/?= =?us-ascii?Q?6g+EKamjIl6QN1ZRSQvNB5RTXjraK/gx7qPmcrPoDKoxG9aSGS9Z3NNVjtb1?= =?us-ascii?Q?vyhdWcuUxZoZ1Ec7yFAslAwOEZPP0kF3D5NqitvtuoDLAfVoYUeg5Urmwij6?= =?us-ascii?Q?QM5BcDHcaM7ApTcsDsOGPkVcSAMfuQ1RpThrnqW10ZgtbMlXNIReTEYSmB+G?= =?us-ascii?Q?nnigMbodfpZAHrw4QZox2Y8sOxk8rUgZ4TQL/6wqeYfPf8mGMbfF40GgjYqh?= =?us-ascii?Q?RNAKGlXcJaXwXJ3sRXLK7esbBDXY1Faetf1LUnDs4hPQ6KXL1GAS9EbDwVmb?= =?us-ascii?Q?aLLdNBV7W1nY/RI/UEB8BzXp1+wfvTul8p9l0vDE1eisC+52rk42xS2NsBam?= =?us-ascii?Q?jx2tXJRJELp1CS7DVkcdEzPH1kAPh2W/lljFRvNXzo1iNhUi2SAD/ApSRo0h?= =?us-ascii?Q?zsyOs0WOo/sPMzQnwSzrvT3Bq95vctJ96/rcC9wBUVlhV+87V0wPJl4gP1TX?= =?us-ascii?Q?7G8Kqo/ZaWIg2NqyA+t5tbPrsbzaE47WzDCfpPyRbCNnKS9AKrMI1n+NuHMM?= =?us-ascii?Q?GTYBuIFQrnorkC5z5ow1TrutBN01p6YyE2SxjZUQod/sW3HMWmMZTtxJ1/CC?= =?us-ascii?Q?jIWnBpPrOd9jBEzE4F9mch+jxyy2CsI=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66d022da-a89a-4495-4086-08df23c7b212 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 16:34:30.3724 (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: sdCKtycDjb7tvKwOElaymsNzWH3PBs5zzNgU/SZ/lRUQRg+Vrpm1jz9SsA3Tst+GIq+UrWb0aWjgh2NQpI4IfTQrphqtqKXFZwuW5yjHJtY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6461 X-purgate-ID: tlsNG-4011c0/1791304475-58DC7CFC-C6E3B36B/0/0 X-purgate-type: clean X-purgate-size: 1584 During unplug, blkfront stops the hw queues and marks the disk as dead, then later during removal calls del_gendisk(). However, IO issued after the hw queues are stopped but before the call to del_gendisk() will be queued but never handled. This causes del_gendisk() to hang forever waiting for the queue refcount to drop to zero. This can be reproduced by issuing IO during an artificial delay after stopping the hw queues. Fix this by simply not stopping the hw queues directly. Marking the disk as dead already freezes the queue which prevents new requests being added and it synchronously runs the hw queues to clear anything pending. If the hw queues are stopped when calling blk_mark_disk_dead(), running the hw queues is a no-op and can leave queued requests unprocessed. Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Ross Lagerwall --- In v2: Drop fixes tag, expand commit message. drivers/block/xen-blkfront.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8dad7bf5f664..69a2315a1b20 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -2138,10 +2138,8 @@ static void blkfront_closing(struct blkfront_info *info) return; /* No more blkif_request(). */ - if (info->rq && info->gd) { - blk_mq_stop_hw_queues(info->rq); + if (info->gd) blk_mark_disk_dead(info->gd); - } for_each_rinfo(info, rinfo, i) { /* No more gnttab callback work. */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 06 16:50:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 16:50:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441668.1659252 (Exim 4.92) (envelope-from ) id 1xE8Mz-0000sB-LJ; Tue, 06 Oct 2026 16:50:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441668.1659252; Tue, 06 Oct 2026 16:50: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 1xE8Mz-0000s4-HE; Tue, 06 Oct 2026 16:50:25 +0000 Received: by outflank-mailman (input) for mailman id 1441668; Tue, 06 Oct 2026 16:50:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xE8Mx-0000ry-Hh for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:50:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE8Mw-00CmhJ-Uo for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 18:50:22 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac526c6-e002-0a2a0a5209dd-0a2a450c8dcc-10 for ; Tue, 06 Oct 2026 18:50:22 +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 6ac526ce-f479-0a2a450c0019-b9ff1c229fdd-3 for ; Tue, 06 Oct 2026 18:50: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1121f8fef0003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 06 Oct 2026 16:50: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 C33AC815DF; Tue, 6 Oct 2026 18:50: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=vn/ztMCm5Fq2N8IKmY15sghlrFHXYcj5dL4MPJfS2P0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=LiJZMmIJO5hwLadBl29/b9rP8WBztZPs14gPSzpYOVixYaq+OQ9jYpO/oIM4ndNtmvaH1GlUd h7VXjSAMLe/ACOhBXd27BkrzsPX5ftPrv4dyNadcz8uqs0W1xm4YVYuC53eZp13ghzMTOVlYo8R 21cN2sLtubhohEMUmvtbh1TtGwPcf1i8EMBY7SX4NoT9rEevBStf9vKUnxxBXVfAsl8x4p+oZct GFsCwTojha/699FLIV6NSSjd6FYALDgD5ZxH2gGLnc4E9NYG4VzrbmcRwnYgKvK8ALLZiupbIFs 1H72+GupcEo+HHNcvyVwEOUht2Ywm3ZYQuw+qQXtcu2Q== X-Zone-Loop: 4d18deb9cafb8a90c87939600601a44ef3a50c0f8371 x-campaign-type: default x-transaction-id: c4cc5cb9-c3c4-4279-a252-0ccc25984fd9 x-swg-uid: 01-1aedab40-09cf-4d89-b452-08d5793c3d7d X-Mailer: Sweego Message-ID: <1791305420.8631fc262581453bbf619ec5b2062170.1a1121f8fef0003f66@vates.tech> x-swg-bid: 1791305420.8631fc262581453bbf619ec5b2062170.1a1121f8fef0003f66 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 v3 11/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: <6e539cc5ded7f62c4347781785af714840893184.1790779209.git.oleksii.kurochko@gmail.com> References: <6e539cc5ded7f62c4347781785af714840893184.1790779209.git.oleksii.kurochko@gmail.com> Date: Tue, 06 Oct 2026 18:50:11 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791305414; l=21865; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=6R81etp+Jo0MWLwbpamHWMogUBgnfS+wgP0PV7zSYCw=; b=KSDElkRgP9p/7VbqNtMoaToE2LQ1g33oFNEHQl7SlP9dXiwZ4szqU37rvkkbSeczze2JhQmAD nhrtVTBkRmWA3ytjzsA/hFsgskzz1n86dw18Xx9JjzP/d6uvmVI2oeL 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: 1791305420015 X-purgate-ID: tlsNG-d25034/1791305422-50D3CA5B-27C65D80/10/73395122804 X-purgate-type: spam X-purgate-size: 21865 > Implement context_switch() and the helpers it needs: save/restore of > 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. The virtual interrupt controller state isn't > switched here. > > Add offsets of struct arch_vcpu's xen_saved_context to asm-offsets.c for > use by __context_switch(). > > henvcfg, htimedelta and vsie are 64-bit on both RV32 and RV64, so store > them as uint64_t and access them with csr_{read,write}64(). For that > purpose introduce csr_read64(). > > The VMID has to be claimed on the context switch rather than on guest > entry: once p2m_ctxt_switch_to() writes HGATP, speculation can populate > G-stage entries under whatever VMID is written there. This is done by > p2m_vmid_switch_to(), called right before the HGATP write: > > - VMIDs are a per-hart resource, so the (generation, vmid) pair of a > vCPU which last ran on another hart is invalidated before a VMID is > claimed for it. The local flush for a wrapped generation moves along > with the claim. > - Nothing is switched in for the idle vCPU, so HGATP keeps pointing at > the p2m of the domain which ran on the hart last. Track that domain > per hart (hgatp_owner) and keep the hart in its dirty_cpumask until a > vCPU of another domain is switched in: p2m_tlb_flush() then goes on > reaching the hart, and a domain which idles between two runs on the > same hart keeps its VMIDs. > - When the owner changes, the hart leaves the old owner's dirty_cpumask > while its TLB may still hold that domain's G-stage translations, so it > is moved to a new VMID generation, which makes none of them reachable > again. It joins the new owner's dirty_cpumask before HGATP is written; > a full barrier there, paired with one in p2m_tlb_flush(), guarantees > that a concurrent P2M change either reaches the hart with an > HFENCE.GVMA or is visible to it before it walks the p2m. > > That leaves p2m_handle_vmenter() with nothing to do, so drop it together > with its call from check_for_pcpu_work(): a VMID is only ever invalidated > while its vCPU isn't running, and p2m_tlb_flush() drops stale entries > with a remote HFENCE.GVMA rather than by retiring VMIDs. Unlike > p2m_handle_vmenter(), HGATP is written unconditionally, as it holds the > G-stage root too, which on a context switch belongs to another domain. > > While at it, fix the inclusion order of headers in asm-offsets.c: Xen's > headers go first, then arch specific ones. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v3: > - Update the commit message. > - Introduce csr_read64(), as vsie is 64-bit on RV32 too, i.e. has to be > accessed as the vsie/vsieh pair there. > - Make vsie declared as uint64_t instead of register_t. > - Rename the parameter of save_csr_regs() to p and of restore_csr_regs() > to n, to match their callers ctxt_switch_from()/ctxt_switch_to() and the > rest of the context switch helpers (p2m_ctxt_switch_{from,to}(), > vtimer_ctxt_switch_{from,to}()). > - s/save_csr_regs/csr_regs_ctxt_switch_from/ > - s/restore_csr_regs/csr_regs_ctxt_switch_to/ > - Drop the forward declaration of struct vcpu in : the > return type of __context_switch() already declares the tag at file > scope. > - Make the next parameter of __context_switch() pointer-to-const, as > next's saved context is only read. > - Extend the comment above __context_switch(): as ra is switched too, it > doesn't return to its caller, but to where next last called it from > (next's own context_switch(), or continue_new_vcpu() for a vCPU which > has never run). > - Call vtimer_ctxt_switch_to() after csr_regs_ctxt_switch_to(), so that > ctxt_switch_to() restores state in the reverse order of > ctxt_switch_from() saving it. > - Rework p2m's VMID handling in the context switch: track the domain > whose p2m HGATP points at in a per-CPU hgatp_owner, so a pass through > idle no longer drops the hart from that domain's dirty_cpumask nor > burns a VMID generation; move the dirty_cpumask update and the > invalidation of a VMID brought from another hart from schedule_tail() > and ctxt_switch_to() to p2m_ctxt_switch_to(), next to the VMID claim; > add the barriers ordering the dirty_cpumask update against > p2m_tlb_flush(). > - Initialise arch_vcpu.last_cpu to CPU_NONE instead of NR_CPUS. > - Mark prev's dirty_cpu clean before ctxt_switch_to() and set current's > after it. > --- > Changes in v2: > - New patch. > --- > --- > xen/arch/riscv/domain.c | 127 ++++++++++++++++++++++ > xen/arch/riscv/entry.S | 48 ++++++++ > xen/arch/riscv/include/asm/csr.h | 13 +++ > xen/arch/riscv/include/asm/domain.h | 15 ++- > xen/arch/riscv/include/asm/p2m.h | 1 - > xen/arch/riscv/include/asm/system.h | 2 + > xen/arch/riscv/p2m.c | 157 ++++++++++++++++++--------- > xen/arch/riscv/riscv64/asm-offsets.c | 19 +++- > xen/arch/riscv/stubs.c | 5 - > xen/arch/riscv/traps.c | 2 - > 10 files changed, 330 insertions(+), 59 deletions(-) > > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index fd62296356..f80643e2d8 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -152,6 +153,8 @@ int arch_vcpu_create(struct vcpu *v) > if ( is_idle_vcpu(v) ) > return 0; > > + v->arch.last_cpu = CPU_NONE; > + > vcpu_csr_init(v); > > if ( (rc = vcpu_vtimer_init(v)) ) > @@ -323,6 +326,130 @@ int arch_domain_create(struct domain *d, > return rc; > } > > +static void csr_regs_ctxt_switch_from(struct vcpu *p) > +{ > + /* > + * There is no need to save these CSRs as only hypervisor writes them in > + * csr_regs_ctxt_switch_to() 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. > + * > + * p->arch.hedeleg = csr_read(CSR_HEDELEG); > + * p->arch.hideleg = csr_read(CSR_HIDELEG); > + * p->arch.henvcfg = csr_read64(CSR_HENVCFG); > + * p->arch.hcounteren = csr_read(CSR_HCOUNTEREN); > + * p->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); > + * > + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + * p->arch.hstateen0 = csr_read(CSR_HSTATEEN0); > + */ > + > + p->arch.hvip = csr_read(CSR_HVIP); > + > + p->arch.vsstatus = csr_read(CSR_VSSTATUS); > + p->arch.vsie = csr_read64(CSR_VSIE); > + p->arch.vstvec = csr_read(CSR_VSTVEC); > + p->arch.vsscratch = csr_read(CSR_VSSCRATCH); > + p->arch.vscause = csr_read(CSR_VSCAUSE); > + p->arch.vstval = csr_read(CSR_VSTVAL); > + p->arch.vsepc = csr_read(CSR_VSEPC); > +} > + > +static void csr_regs_ctxt_switch_to(struct vcpu *n) > +{ > + csr_write(CSR_HEDELEG, n->arch.hedeleg); > + csr_write(CSR_HIDELEG, n->arch.hideleg); > + csr_write(CSR_HVIP, n->arch.hvip); > + csr_write64(CSR_HENVCFG, n->arch.henvcfg); > + csr_write(CSR_HCOUNTEREN, n->arch.hcounteren); > + csr_write64(CSR_HTIMEDELTA, n->arch.htimedelta); > + > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + csr_write(CSR_HSTATEEN0, n->arch.hstateen0); > + > + csr_write(CSR_VSSTATUS, n->arch.vsstatus); > + csr_write64(CSR_VSIE, n->arch.vsie); > + csr_write(CSR_VSTVEC, n->arch.vstvec); > + csr_write(CSR_VSSCRATCH, n->arch.vsscratch); > + csr_write(CSR_VSCAUSE, n->arch.vscause); > + csr_write(CSR_VSTVAL, n->arch.vstval); > + csr_write(CSR_VSEPC, n->arch.vsepc); > +} > + > +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); > + > + csr_regs_ctxt_switch_from(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; > + > + csr_regs_ctxt_switch_to(n); > + > + vtimer_ctxt_switch_to(n); > + > + p2m_ctxt_switch_to(n); > +} > + > +static void schedule_tail(struct vcpu *prev) > +{ > + unsigned int cpu = smp_processor_id(); > + > + ASSERT(prev != current); > + > + ctxt_switch_from(prev); > + > + write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN); > + > + ctxt_switch_to(current); > + > + write_atomic(¤t->dirty_cpu, cpu); > + > + 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); > +} > + > static void __init __maybe_unused build_assertions(void) > { > /* > diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S > index 202a35fb03..017fbb0626 100644 > --- a/xen/arch/riscv/entry.S > +++ b/xen/arch/riscv/entry.S > @@ -99,3 +99,51 @@ restore_registers: > > sret > END(handle_trap) > + > +/* > + * struct vcpu *__context_switch(struct vcpu *prev, const struct vcpu *next) > + * > + * 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) > diff --git a/xen/arch/riscv/include/asm/csr.h b/xen/arch/riscv/include/asm/csr.h > index a5cb24c863..aad82c6a6d 100644 > --- a/xen/arch/riscv/include/asm/csr.h > +++ b/xen/arch/riscv/include/asm/csr.h > @@ -40,6 +40,13 @@ > csr_write(csr ## H, v_ >> 32); \ > }) > > +#define csr_read64(csr) \ > +({ \ > + uint64_t v_ = csr_read(csr ## H); \ This violates Misra 20.12 rule (docs/misra/rules.rst) as we use macro parameter `csr` as an operand of ##, while it could be expanded as a macro (e.g. csr_read64(CSR_HENVCFG)). > + \ > + (v_ << 32) | csr_read(csr); \ > +}) > + > /* > * 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, > @@ -72,6 +79,12 @@ > (void)csr ## H; \ > csr_read(csr); \ > }) > + > +#define csr_read64(csr) \ > +({ \ > + (void)csr ## H; \ Same as above. > + csr_read(csr); \ > +}) > #endif > > #define csr_swap(csr, val) \ > diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h > index 15e8fa1968..77ad888a2d 100644 > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -29,6 +29,11 @@ struct arch_vcpu_io { > struct arch_vcpu { > struct vcpu_vmid vmid; > > + /* > + * The last CPU this vCPU ran on. Initialised to CPU_NONE. > + */ > + 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 +65,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; > + uint64_t vsie; > + register_t vsscratch; > + register_t vsstatus; > + register_t vstval; > + register_t vstvec; > > /* > * VCPU interrupts > diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h > index 0d1dace1a0..9edf78377e 100644 > --- a/xen/arch/riscv/include/asm/p2m.h > +++ b/xen/arch/riscv/include/asm/p2m.h > @@ -262,7 +262,6 @@ struct page_info *p2m_get_page_from_gfn(struct p2m_domain *p2m, gfn_t gfn, > > void p2m_ctxt_switch_from(struct vcpu *p); > void p2m_ctxt_switch_to(struct vcpu *n); > -void p2m_handle_vmenter(void); > > #endif /* ASM__RISCV__P2M_H */ > > diff --git a/xen/arch/riscv/include/asm/system.h b/xen/arch/riscv/include/asm/system.h > index f33af64fd2..d350b9c959 100644 > --- a/xen/arch/riscv/include/asm/system.h > +++ b/xen/arch/riscv/include/asm/system.h > @@ -76,6 +76,8 @@ static inline bool local_irq_is_enabled(void) > > #define arch_fetch_and_add(x, v) __sync_fetch_and_add(x, v) > > +struct vcpu *__context_switch(struct vcpu *prev, const struct vcpu *next); > + > #endif /* __ASSEMBLER__ */ > > #endif /* ASM__RISCV__SYSTEM_H */ > diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c > index de25607247..02e7f6364f 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 p2m_vmid_switch_to(). 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); > } > > @@ -1504,16 +1513,110 @@ void p2m_ctxt_switch_from(struct vcpu *p) > * VMID, world-switch code should zero vsatp, then swap hgatp, then > * finally write the new vsatp value what will be done in > * p2m_ctxt_switch_to(). > - * Note, that also HGATP update could happen in p2m_handle_vmenter(). > */ > p->arch.vsatp = csr_swap(CSR_VSATP, 0); > > /* > - * Nothing to do with HGATP as it will be update in p2m_ctxt_switch_to() > - * or/and in p2m_handle_vmenter(). > + * Nothing to do with HGATP as it will be updated in > + * p2m_ctxt_switch_to(). > */ > } > > +/* > + * 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. The hart also keeps its place in the owner'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. > + * > + * TODO: nothing resets hgatp_owner when its domain is destroyed, so a hart > + * which stays idle from the domain's last run until it is freed is > + * left with a dangling pointer. Once domain_relinquish_resources() > + * tears down the p2m, it has to reset hgatp_owner of every hart still > + * pointing at the domain (cmpxchg() against d), i.e. before the RCU > + * grace period of domain_destroy() and so before the domain is freed. > + */ > +static DEFINE_PER_CPU(struct domain *, hgatp_owner); > + > +/* > + * Update this hart's place in the dirty_cpumask of the domains involved and > + * claim a VMID for n. Must be called before HGATP is pointed at n's p2m, as > + * it is written with the VMID claimed here. > + */ > +static void p2m_vmid_switch_to(struct vcpu *n) > +{ > + unsigned int cpu = smp_processor_id(); > + struct domain *owner = this_cpu(hgatp_owner); > + bool need_flush; > + > + ASSERT(!is_idle_vcpu(n)); > + > + if ( owner != n->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. > + * > + * This has to precede the VMID claim below, so that n gets a VMID of > + * the new generation. > + */ > + if ( owner ) > + { > + vmid_flush_hart(); > + > + cpumask_clear_cpu(cpu, owner->dirty_cpumask); > + } > + > + /* > + * Mark this hart in the incoming domain's dirty_cpumask before HGATP > + * is pointed at its p2m: from that write on the hart may cache the > + * p2m's translations, so p2m_tlb_flush() must already reach it. > + */ > + cpumask_set_cpu(cpu, n->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) = n->domain; > + } > + > + /* > + * 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. > + */ So if I understand correctly, we are setting generation to 0 to mark the vCPU that it is coming from other hart right? Nit: If it's the case I may simplify the comment to: /* * VMIDs and generations are per hart, so a pair issued on another hart * may match this hart's generation by coincidence. Reset the generation * to 0, which no hart ever uses, so that a fresh VMID is claimed from * this hart's pool. */ > + if ( n->arch.last_cpu != cpu ) > + vmid_flush_vcpu(n); > Nit: I had to read this a couple of times to get why the guest entry is too late. "makes HGATP live" doesn't say what happens once it is: if it's because of speculation filling the TLB with G-stage entries tagged with the VMID in HGATP, like you explained in the commit message then it may worth spell out: /* * Claim the VMID before the caller writes HGATP rather than on guest * entry: from that write on, speculation may fill the TLB with this * domain's G-stage entries tagged with that VMID. A stale VMID may * already have been re-issued to a vCPU of another domain, which would * then hit these entries. */ -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 06 16:53:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 16:53:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441675.1659260 (Exim 4.92) (envelope-from ) id 1xE8Pw-0001SD-1R; Tue, 06 Oct 2026 16:53:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441675.1659260; Tue, 06 Oct 2026 16:53: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 1xE8Pv-0001S5-Ua; Tue, 06 Oct 2026 16:53:27 +0000 Received: by outflank-mailman (input) for mailman id 1441675; Tue, 06 Oct 2026 16:53:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE8Pv-0001Ry-An for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 16:53:27 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xE8Pu-0007qv-21; Tue, 06 Oct 2026 16:53: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 1xE8Pu-00EIBy-0t; Tue, 06 Oct 2026 16:53: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=kOlS+lL1hkPrA+M+rforELABkTt5NUaGOO8i1B5fYL8=; b=GpXwiAbtFyf1k/eR8dnrCFI3Nn W2cx9MDoU6bHdFiUSJxufc4F+qJB0+P5hJ+xkZ7Xx0OQGcf7noud9pUdrcLINKGBf9mbkfmPihhpS SkO6gm9ve4wDfIkRj4z2bshFvSw58sIowSp/JTz51tdBhkjugiMS/1yX+y+NasuYWBFA=; Date: Tue, 6 Oct 2026 18:53:23 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ross Lagerwall Cc: xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jens Axboe , stable@vger.kernel.org Subject: Re: [PATCH v2] xen-blkfront: Fix IO race during unplug Message-ID: References: <20261006163411.2583538-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261006163411.2583538-1-ross.lagerwall@citrix.com> On Tue, Oct 06, 2026 at 05:34:07PM +0100, Ross Lagerwall wrote: > During unplug, blkfront stops the hw queues and marks the disk as dead, > then later during removal calls del_gendisk(). However, IO issued after > the hw queues are stopped but before the call to del_gendisk() will be > queued but never handled. This causes del_gendisk() to hang forever > waiting for the queue refcount to drop to zero. > > This can be reproduced by issuing IO during an artificial delay after > stopping the hw queues. > > Fix this by simply not stopping the hw queues directly. Marking the disk > as dead already freezes the queue which prevents new requests being > added and it synchronously runs the hw queues to clear anything pending. > If the hw queues are stopped when calling blk_mark_disk_dead(), running > the hw queues is a no-op and can leave queued requests unprocessed. > > Cc: stable@vger.kernel.org > Assisted-by: LLM > Signed-off-by: Ross Lagerwall Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 06 17:01:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 17:01:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441685.1659269 (Exim 4.92) (envelope-from ) id 1xE8XD-00037l-NC; Tue, 06 Oct 2026 17:00:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441685.1659269; Tue, 06 Oct 2026 17: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 1xE8XD-00037e-KK; Tue, 06 Oct 2026 17:00:59 +0000 Received: by outflank-mailman (input) for mailman id 1441685; Tue, 06 Oct 2026 17:00:58 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE8XC-00037Y-DS for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 17:00:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE8XB-00BEu4-9R for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 19:00:57 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac52929-2eae-0a2a0a5409dd-0a2a45059f7a-40 for ; Tue, 06 Oct 2026 19:00:56 +0200 Received: from [52.101.48.60] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac52946-4cb1-0a2a45050019-3465303c4f89-3 for ; Tue, 06 Oct 2026 19:00:56 +0200 Received: from CY5PR19CA0015.namprd19.prod.outlook.com (2603:10b6:930:15::12) by SJ1PR12MB6147.namprd12.prod.outlook.com (2603:10b6:a03:45a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Tue, 6 Oct 2026 17:00:50 +0000 Received: from CY8PEPF00000054.namprd05.prod.outlook.com (2603:10b6:930:15:cafe::79) by CY5PR19CA0015.outlook.office365.com (2603:10b6:930:15::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 6 Oct 2026 17:00:50 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY8PEPF00000054.mail.protection.outlook.com (10.167.247.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 17:00:50 +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, 6 Oct 2026 12:00:49 -0500 Received: from [192.168.19.2] (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, 6 Oct 2026 12:00: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=aLP3CvU5c28llY55pgkw+ZraPZm4mgxZ4we+Nk9awcNu6I55lqLzy+jdHvKm+XFqrMgWq58mWvuJ1iTENN49j1vl0rQyPNolK0yJMBzzS3i40QNHtZCNeBbOO67O7Ef7JGXzHqcjnNDqAfNqRmQGvDVbGhLrW8/lYEfVZ17DGlEqv9hqb9xXAA+USPUQnQDhdVpmQzMkokQGLgtx4qZEJbrgzbfWEZUjt3qtH41Mmd4k2zfsWNvtGWzsPNo6iZVHHCKbjw1UIozWc4dwz0uCBcXRTiLWNKWLje8ie+TYmIGO9YsYiU6P7Jxco0IB4INGhBlh/GxmVWUuW5oLeqp8vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qWLsZvlZX7pSxYLD31SMhUpsra19H0qFDFuj1hVn+6M=; b=gVdFqIYzQTOKX0nmeKvQzw15NcVkiLSVZRGkUPksAu7vXt8KNJ4h9rIAaZMiwtDZ0VyA8dxnIuW7o536KKxLrR0duJJ256PJudh/5DNBP1WW75PplXxv3nEWaErDvHwlARI3+j/buq8T2RuDmdaOIdXrY5/bBuVs9+6o6Hk8yaVnS8M1bnMVNUZa6w4ITpZQCmFrEWbEmULTa9Gtk8Tabq05yXg9Jt0Jk6ERiMjPxVJ6rv72I16fbCY7rGNeXEqtLhUGV8HNSeHY+C2SLJ1hRHGb5AYzcbD/eIzVdJffCiWVqR4yFvkh8W0Bt7/8TGKKmc2cc3ByywgtHYH9Rtf1WA== 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=qWLsZvlZX7pSxYLD31SMhUpsra19H0qFDFuj1hVn+6M=; b=TXJcCC5TSfcPSN8NIO95Z4k44VYjxaJZiP1D0qNCV65OKhV/fCViVNi2+KGxxgFf1j7hTkh6hPcyAesf4nHNV5Fq6P/RaiLyDOnguEOldNN8MZA7JUffScncUBUYbFmkUqYM1tFT1AQwsK0JWLMB+vv4eUVXQGHeI2teuC++SoI= 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: <39b13edf-1280-4821-beed-615fbc4915f6@amd.com> Date: Tue, 6 Oct 2026 12:23:49 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/svm: Don't clear clean bits on every context switch To: Ross Lagerwall , CC: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <20261006144805.2575991-1-ross.lagerwall@citrix.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20261006144805.2575991-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY8PEPF00000054:EE_|SJ1PR12MB6147:EE_ X-MS-Office365-Filtering-Correlation-Id: b0e768ec-eb4d-4fa0-d343-08df23cb6003 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|376014|36860700016|1800799024|10067099003|6133799003|11063799006|22082099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: jm0I4Z7hMIk3noa3wjJcn6SYw0PkQE6NQM9YZ4I8U7vdALRriYFtax+GgOW96SJtQv0F6NzDJbyRYPlweZwCIPe1+PL59ynQmTkoaUP4LGxad4J2prHNnjtz1U8LJLVO//yhd7i89vQPFNK9rBEGHF9+9f95VYz6mEjfXyrg2TX7gyzNUDg6Xm3GS6zBWQTkakgrlK69aCJ+urEWOyGaVJgKGgjhN/tBoh/xstr/6SibJ66aqcbmZZP9l9D+u9L5OVXO7L2M2gxZ6MVzgNlb4xd9kPkLqkCRSAVuOyN8kfxmgvU3f/ngfmgBmeKuoNY2HYAFY1DddxHSKFJ4uIMB8ZiFSCCXWiNRoifILYtEFkuwh24+h0lxmAwgwmh0mVlfCn6MbloDsRVEUEZGK1v/WOMJqbqlYEKYFNkxL9B2ZZ9kL8rm9MK7rIMnE0fgFhVAjyhohuE9xOZ8aWdVW3/V22TzAuW8UKOnG4MIZoAzN9zQsWTckl8yR4X0im2LS+/tkjPszJaxlbUDm4nwpkQQGaEHhzeuqgsZvrgz2Tm1kEYk3r7MPDZEv5m8SaMa9U+PFLG5NCDahj4vQK6Ajb40Su83GiLNH/+pawi76FBF40xDfYYX4AcISgzxb5ERfZMRCElmNOqYB8MF8wWBx0P1BiYiz962gfrnkTcl6DkBZA237g7XZvOvb4VR5eF1jCI4OXgP/0RR9ACg3uAyHat44g== 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)(23010399003)(376014)(36860700016)(1800799024)(10067099003)(6133799003)(11063799006)(22082099003)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: cTv6K4KBH/tCS+gOgQ5xLHb135n/xGGSpjJZL3/Bh2XSR5y7b/QyWgMDZq775LI/gOqCBtFBxRrXZDQjlhimUgizaRtsnSLqqwrNXkIegOONliuFqzXyYAavA1rckAO2Cl0dMCu+VyZssk5egCs+QcggDaTS5DPf85lsgxnXy7hel6mT78sv3se6XTKjbOIxOyjDwFh4lqg+HXt0tn3iNwI9XbsaQ1xxJ6Jp8uSLP/I++yHjK+xskFsJ+dxGm2bXBSfFvclbL5xeDjmf+dW5O5lW5MbXU3Vx72m+GQ3u8XF5I0MccaOiZYCZcC6u8+itZ7bndTqzeNBooYOAPuqkStnfU5IYkPvDE7OA6017yvC/5mZbI8XIDylo87maLYkKoKYOi9ou+tXje6LKUcefbL6vFi4mnMWbqUdhsVUChx8ydUyiGZY5dEkq72kfBTvK X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 17:00:50.5190 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b0e768ec-eb4d-4fa0-d343-08df23cb6003 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: CY8PEPF00000054.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6147 X-purgate-ID: tlsNG-c201ff/1791306056-6BEB92A1-63FDDF49/0/0 X-purgate-type: clean X-purgate-size: 759 On 2026-10-06 10:48, Ross Lagerwall wrote: > Clear the cleanbits only when the VMCB is used on a different pCPU > rather than on every context switch to the vCPU. This follows the APM > guideline for when to clear the cleanbits: > > "The hypervisor executes the guest on a different CPU core than one used > the last time that guest was executed." > > Signed-off-by: Ross Lagerwall Reviewed-by: Jason Andryuk The other times are: "This is the first time a particular guest is run." The vmcb page is zeroed in alloc_vmcb(). "The hypervisor has moved the guest's VMCB to a different physical page since the last time that guest was executed." VMCBs aren't moved. Regards, Jason From xen-devel-bounces@lists.xenproject.org Tue Oct 06 17:19:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 17:19:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441696.1659278 (Exim 4.92) (envelope-from ) id 1xE8pC-0005DU-6E; Tue, 06 Oct 2026 17:19:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441696.1659278; Tue, 06 Oct 2026 17:19: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 1xE8pC-0005DN-2u; Tue, 06 Oct 2026 17:19:34 +0000 Received: by outflank-mailman (input) for mailman id 1441696; Tue, 06 Oct 2026 17:19:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xE8pA-0005DH-Hk for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 17:19:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xE8p9-005cMA-CD for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 19:19:31 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac52d6e-8faa-0a2a0a5109dd-0a2a45078cac-46 for ; Tue, 06 Oct 2026 19:19:31 +0200 Received: from [52.101.57.3] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac52da1-b4ea-0a2a45070019-34653903ea74-3 for ; Tue, 06 Oct 2026 19:19:30 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6588.namprd03.prod.outlook.com (2603:10b6:303:12b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 17:19: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.0472.020; Tue, 6 Oct 2026 17:19: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=VRnHYouydo2qQ4Tfo+zLN8y4Q33LcZaDE8DV44jr0ZmOyFcbuG0AYjJ8EtBp6ojYqDeyUerDENdUoCPl9aqVqmSUg8Rnxm6u7U9FKMMXjz39rCyWHvxWszfmqdn2UDRz3ntfvzVX5ptFw8zu0mdbr2qqvu0jeKK8HakrYQzLjmJn2w6h7xhii6UHGizGtmJePMMKK6qyQcNHNEvHADozo2I92Wn9Bj4Yq5qJM2TKW/htZk3AqIj0ru1RddL2j7j4Nfg07tprKuLLYVLQw82sSioCRWYt2zhgq9holLwdxvYx578J8cnv+ZjehC72sF542YoQVstzkej63Qfej1QjQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vnxWrWEgvPMvU2YKarKpHb/4KNAphBQw2CO1pEdjm6E=; b=lboWIaumP7BFsK1nf5BCB10j6WUODKI80K3EQwmywjpJLKFoaok7dacdkMTQlsFFEsSIYG3qEEJV2df/1NFxmUTa6v9qhCxAN+6Gd6ci9hFIyvv0b8qo4PU/Yi5mZN+m6sc8gTgZXO9fwrdjqHCDPnVdffnJMMLzqyqJgYYtUgmWp8t4k/wZUazS/b/IOUdctFkiimquVju0dtGJvY67BHXbAh/WYfFUdMdsde9Pg/NkPU0/W/4DIwQM/xTuSLQwHa9gcbDnN+L/fOmlWa3Jh5yEpjpRvNMf4U7VrYd/IUGdZfP76XVKoAE7UVcBBNIdyizdTw7CXOX2RJCMwo3PuA== 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=vnxWrWEgvPMvU2YKarKpHb/4KNAphBQw2CO1pEdjm6E=; b=DXJH4Nw3O2RBF2mGOIUb86kO1s4SyD8MW0r6Van6ttYijkW2BL9XFrwpZXPFmRBp2sukxgcASRua0fz16scNtMrCKp9BJkLdSfA0z9ANO+nvLJRdIfIDL6xFHjeB33bC/DkJ3gH3HoGgnSUS+1PjlHT46cNHBuLvi17VN3ze41Y= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3d4f793c-77ec-4a70-8f73-e647298cf0a6@citrix.com> Date: Tue, 6 Oct 2026 18:19:23 +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] x86/svm: Don't clear clean bits on every context switch To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20261006144805.2575991-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: <20261006144805.2575991-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0278.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:195::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_|MW4PR03MB6588:EE_ X-MS-Office365-Filtering-Correlation-Id: a22bdb7a-52fb-4145-fd11-08df23cdf955 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|18002099003|22082099003|6133799003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: QqCcwES53dw37V64OUcAvtMXHjXpETSqjS9FbWbjE7S36SAR+4cNmekVdhZfXfbA0afyKppHEToF1M6pVSyyoj60yqCZkLxdsLObeOOnQGNeml0euNVKNBTNd/Rr538N5nsMyn0UNQIQo0DeJyNt2aPLuj/yli0gyrrqa2bxMavuxMNDT5RNiPqwEPiLHBQJ0JSkIuWML7sXnBQJdstP8pgIse9HG/cMQhWQhkqchjU0IgEVD5YpBorsRDEvP4Q1WRFNP+afdBkif7AraKRqKO1gH2YV4HnXt/5z14pX/JJiFnUK3aNUR0O36kB6KW2bpD54a5Bl5Ld713s1xOBU1B4crLgCPtCGDGaAIZA9uGQCKW4t436+LSkuLrurb6AoPeKghDEa9wj4Cpf2CNBpLmKSsKjnxytjKhW9gyjF6mEq2c0A/sNGPl/fz8QNM/gBfbLHNKe3PW59785LQ5wBvzPD6uuijVpUfHgIF8gOvDa3d7ULjQM56C6/XFd31LjgkrGNTnCiuN7z8JrKYorrOC9oiXLVjwVe9TM5vOWrKlhvME4MqJ0OPhfo4wkpBinn008rGgXNig0DlzW+Rzx7sWCDdUXyJiDLbCircDoeYDcAeJzr+hufMoIrEqC48ddIyd/0/hI6F6l334rYWrPJEy3sp/mR4voUXaKYKXIwm8c= 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)(18002099003)(22082099003)(6133799003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VlVJdUkwNkhXR2pCck5tYjRUc1ZsekpibFlZQzFPTVUrL1RqR0wrazFoaEY0?= =?utf-8?B?NFBZVFdIWFZuUWMvSTIrVG5nbUREOXBoeXA4M3ExL0dybzJSaXJmYU12elNm?= =?utf-8?B?YVNYUDZiRzJnMnluL2R6WGdIOGVCdzdLYU1HL0NDQi9sUy9YZ3NTZGUrUlJn?= =?utf-8?B?ekY1dWllTjJjNG8xWnNqWm1hQkVQcEx1RzRkaXF2bTVzMzUrL0tYd3JRNzNh?= =?utf-8?B?UzRvb052RFdUbHpBUmczT3lzamN5R0t2NUlXUjR0ZEUyWkhRSE9qTE1wV1lk?= =?utf-8?B?Nm12N0xja29TdzJJeU1TN0ZOaFBvMzlmM1gvRVFLb1RpM1NUNDd6OEZCQXdu?= =?utf-8?B?YjdTR0FkeGpWZlV2bXFHZmlOSlNXaml3cVZUVkVNUFJQMzJ5TjgrajcrR0lp?= =?utf-8?B?MDV4ZWNPZUNQaDJESlkwdGhJRkRKbjZ5SHJtdGoxdloxbzdkbzRzOWUyRUph?= =?utf-8?B?R2NuRkF6WEQ5dUhiUW1tQ2l1VzZRQnZVWjdLT01lL25WR3pkSE1KUThJc2t0?= =?utf-8?B?aXhEdEF6c0VuSWE2dDZaeWJoRDlCZGIrWXZFU2lMT0s5VWE4OEcyb2hhMEZY?= =?utf-8?B?US94VTBxMWdlSXpYTXN0QVR2U1J6YktuaXdaeHV3S0RIcWFPcksxeGNrdDRY?= =?utf-8?B?aWhiY0wydlFHKzRjQ3YwZDNYMEhzaWVFNndrV3N0aHNVUE01VmN2MU02ZUZ6?= =?utf-8?B?SEU5WkppelZRYXZUeWE2cjJrT0VaQzFodGNBajI5WGRaTEtOekJTcHRyemlx?= =?utf-8?B?WGs1eitpbHdXMVZGOXFoejhWeTZzenZpWm03MWxKQnE5RlVCOHpxSE41OW9k?= =?utf-8?B?YzR4K1JkYW1vcjB3clNYNjVlMzMrOE1WWnVRZHk2N1o1ZWJKaE1NNUlGc01O?= =?utf-8?B?dDJ5dzBzOGUwN3VlelgrVWZkUW4rdmRlNlQzZHlYZll6Q1RnNmxBdGljd1Vh?= =?utf-8?B?dUVMM2dyUElkN3VzVXg1TWw4Q2xsSENRU1BjaUVXaWhMWnNHT3VCU1VBYkw4?= =?utf-8?B?YmpQNm45VUp6RDF5ditUR0szK1YxZkRPSFl4dnRMK2hZcFE4MStZZWRSSWZo?= =?utf-8?B?K3NXaVlPQUhZN3hEd3I0bENYOEJtYXJqcEhzWm0wQmNqSWRGODgwVTRUWG94?= =?utf-8?B?TGJMcHRYdzJ0OXlPOTdHenN6LzRNR251dXJ6YTVrTTk5Mlh6ak9ZdStuR1pN?= =?utf-8?B?ME5SRXdMTHhSMyt5UVR0dmpYRFhOSm14dngvc1ZZV2ZuVVpIN1pzWnRCcVNH?= =?utf-8?B?c01QQy8wYzBJVWxaYXRWWTdQdUhZeW53eWFxK25MTUFXTzNQVUxON2dzRi84?= =?utf-8?B?TDJVU1dhVVBKeUVKSEd1dUxHMEF0WXlBb2Y2MzhWOWxPVXF2NnNQMi9mY3hH?= =?utf-8?B?RWExNkQ4dlBHUk5YM2RCTlRJNUdEOEF1WUU2YzFEeE5RVm9DN2ZjNHgwbTY0?= =?utf-8?B?Z2JrRHRudS95cjRxbjlWZmduM1BkZm9PclVOU3ZHTU5XNlVoZ3ZnaWx3N3hB?= =?utf-8?B?N2tCelFlMXNGV0pwVDZUYTlBdGhIcHdNWnZKMnlBZUE3UjJUdGtJN2hhL1pX?= =?utf-8?B?cEt0OXltSG40MWYrT0R6Q1AxblNxOHF0dXJiWjFLcEFrZjZxQmpSSXovUXlh?= =?utf-8?B?K3U4aElZUmp1azYyTUxHMkJQQ1NMK1VjdWVlSy9FWkdoZ2xNZlFJZ0pCYmJ2?= =?utf-8?B?Q3RPaS9waXVoRTIyT1FqT3dpT3B6UG1MK1I0YVQ4OStrRlQ4Qzh6WUNMUDNL?= =?utf-8?B?ZDdnZytyakV5UDFuWGk2MG5va3FuSEROV3dzRFBhSmhCNzA3b2hRMG4zTGNR?= =?utf-8?B?TGRVbGJwcndTeU1iMGVVYWEvTG1WeXBhVndjQ1E0NDV2ZWZKN1l6UjN0SHJW?= =?utf-8?B?VEk5ZVpJMUk4VHZBMjE4VVdHSnN2NUdSYnJuTTBDQlVZZTd4OFk5NENDODNv?= =?utf-8?B?MXRxb1BTdXhtOHhrL3VWY2V4S3BQZi9uVHRlK1pLR1pUMFZxRlNaaGFUSUVs?= =?utf-8?B?ZWVhM0lHVmJjTWU1emRWRktzSmsvdU1mQzFyWXVNT0ZacW5tTmpSNzlPTGhy?= =?utf-8?B?eGhWcCtsYk9tM1R3bmFCQnZDbGwrbFRFc3pPaXFqTmJRUDhYVmVYbHVjT0d0?= =?utf-8?B?SnhkL3RHNkxDcy9VUy9uVS9SZGpUNGx3WWw5MHgra3hUbGZYa3hWdzRTUk1n?= =?utf-8?B?clJuMnRielU2RjNQbGZpRlBPVTE1RlI1Z056T0MvV2ZZWnNpUGtVL2d0OFFD?= =?utf-8?B?Q0JWdVRQTTArOFNJWEc5Sm9kWGtjalJIcmhVNkZ5NHVZN1FzQkozYU1ZaTU0?= =?utf-8?B?Q2txQ0sraExwT3loUTZuU2U2R3M1cGJSaEtlOG9DNTZUNU9MeUU5QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a22bdb7a-52fb-4145-fd11-08df23cdf955 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 17:19:27.0446 (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: J5OdXfu8THl8nhav4gizCl6NvMmVjBsQgSPQoUyfdedeLc8cAMJTl0yZ7isM5Q/S4zWyAUbSV8+oI3BdgVpLu8hfKPQBX0aJXxbV8CkLH5Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6588 X-purgate-ID: tlsNG-ef75cf/1791307171-A4AC8AE4-9AB5CECD/0/0 X-purgate-type: clean X-purgate-size: 662 On 06/10/2026 3:48 pm, Ross Lagerwall wrote: > Clear the cleanbits only when the VMCB is used on a different pCPU > rather than on every context switch to the vCPU. This follows the APM > guideline for when to clear the cleanbits: > > "The hypervisor executes the guest on a different CPU core than one used > the last time that guest was executed." I think this wants the whole section from the APM, not just the one sentence in isolation.  It doesn't quite form a stand-alone sentence. I can fix up on commit. > > Signed-off-by: Ross Lagerwall Code-wise, Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Oct 06 19:01:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 19:01:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441739.1659287 (Exim 4.92) (envelope-from ) id 1xEAPo-0004Lj-4Y; Tue, 06 Oct 2026 19:01:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441739.1659287; Tue, 06 Oct 2026 19: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 1xEAPo-0004Lc-1K; Tue, 06 Oct 2026 19:01:28 +0000 Received: by outflank-mailman (input) for mailman id 1441739; Tue, 06 Oct 2026 19:01:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEAPl-0004LW-T3 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 19:01:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEAPk-00Gmgu-L8 for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 21:01:24 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac54584-8faa-0a2a0a5109dd-0a2a450b8354-0 for ; Tue, 06 Oct 2026 21:01:24 +0200 Received: from [52.101.52.41] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac54583-b7e8-0a2a450b0019-346534294326-3 for ; Tue, 06 Oct 2026 21:01:24 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB6536.namprd03.prod.outlook.com (2603:10b6:a03:394::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Tue, 6 Oct 2026 19:01: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.0472.020; Tue, 6 Oct 2026 19:01: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=xXf7PfggM3MK65v51ssEyXVCMHEdBIiEvQchbZZ49pOpSJ4jEs5cadZKZeLPmbja/OIQYskB9TAysltYJDP8KkpwZaTe7UIPNZXkHFTYzr0WYRccccZO3w/tpfP55aLe1GJKtV8Ht6ZcO4YapbOppsjD5KGRtU3HBM/6ttOKHMYjAmm7Ymwx62pbTVmjIgs+GUNgubO/eo0kM9vsaZ7yOmG+cUYA0VuryN+rkmjqoXz+jTM31owSS3jYNXiQmJxS6JiN2YPbKV0/4U9yvcBH/pY/2i8khKXGpdR4fh9RYyCBMBBiJ8PcYl6EhV7A15f7PPUpqoneI8PWARnZsibEmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lkbLXOBH1bR8qJI/ffu3PzBN2AybD2Uz3fSfJFHnxgg=; b=mIpdhhBDmlleEX6GNUcxkFzm6hoBCBlITZhvNptg2dVHVNZxrNhh96tAKwvSmvEU9eaJtwGt2tPSBrP6F7jKDyyZ8US4qdWUtxZOMIM6qazNOboNNMYxEKmUUbJSDOqR/cYrR+jPj3eYao0eq0oehNpZKxVI1rBPe1Pvx+oAwuW40LR9kcogpjrZy8eTXLi5/GKn4J/jLi7jN7xanblcUZxLJqlrBy3ug/FLGF2zkJe69ofShQsDzrembkS7pYl8NVruAPli75DRV7zkvMkRspr+Y0h2JJXchch58Q1YGdkGlgyE4APSYPTlThkL3HbofgHTurRotXFsqk0LDaPKrw== 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=lkbLXOBH1bR8qJI/ffu3PzBN2AybD2Uz3fSfJFHnxgg=; b=KAw4bCwohN7aJ2Wbu4pRgf9hadI2in2D7YcUNHY/eU7PhQFP7lui9D2hBpUiqy6ZcKi/KYxAMts/rISTTdM9PEF/HopGzzPF0v6uU400tP/Ae9JGQm72zFfTTcfySuXewB4NZdKO+AU4CAsMelSgsH8K7L2PWgheIarK9Fl4qX4= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <288b7c58-8375-41a8-9923-a4884830cc40@citrix.com> Date: Tue, 6 Oct 2026 20:01:17 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel Subject: Re: [PATCH] x86/kexec: Annotate more noreturns To: Jan Beulich References: <20261006105445.511099-1-andrew.cooper3@citrix.com> <3bade5ec-e91d-4181-89d9-de35bd42ce62@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: <3bade5ec-e91d-4181-89d9-de35bd42ce62@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PR1P264CA0093.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:345::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_|SJ0PR03MB6536:EE_ X-MS-Office365-Filtering-Correlation-Id: a7db2f6a-1b16-40db-66eb-08df23dc356f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|22082099003|18002099003|10067099003|4143699003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: 8O+wABqfruaRpHYeVCIciYtCq5aoaDRzHVoDke6uCUcx38SwmCjjonA73hkFJYLbsJMhsNVwNuYRB/UeRX9I+Tw9naixJ8Wb/Fbyeqn0Nl+uc0qMBsduQIkcLV8riCFlati4QhsZ9lV8OipAkm+8OY2Obx6c3zBRAWTa27KPhorQmZKT27N7drWyvurolYJMbxz0F6MzJyIXyWX3US8eZog/cHckyhHVZkgu03v0ZrExk+VzcamL3RkJ6jZGwk3ftih75y1lo8JPYGakX9eNp5lknZCfAgi1oxFXvgIShsgq3jYvj56cNdUGTGTymPAgrzHzl+r7j1Bw32erBIbiRG80+qwWom+qBEMMJlbI7C091RHh7MflDFu8JbAzgLIKpKadQuIhqL8W3Nlabm4VMngLxvnHAdP9CcTX+pIHt5Tdd0yMTkUInFeO2V9KW0j5UygbrrBfYbKkfGBGhl5dX0wLchAx2Tny9Sa5IEv4eGYHZ/ElI6++QDTpvamO0VCjT07LlxLeDKnPkPJhHDt5V+yuQhl8JyPt5EQpv4TEWa+rd2CP6ZfuecRaT5bjEaSGY59fvhMPfxhbbniPR166pbDjs7LbENP9byVHnFM1KrWF5noGcIX4etKunlv4xvvvtbMSI1PVgQsBbMNF0AyiOldpVXsimXOawhocst5orZo= 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)(22082099003)(18002099003)(10067099003)(4143699003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MTErL2U5ZzdPQWdXMjRRL1lKRU1aOWlkVjR2dXdpLzJzd2ZBZmhzcUNyd1VT?= =?utf-8?B?N2VvYWJLZWFXYXp6aDFoazVWc2hHbnlFNUZNeTJLcGlSTUgyR0RmWHVxSTZX?= =?utf-8?B?N2dyMzhnVlpkMUtFWjl2bDFYZ2ZwbmZIMm9RT3dqa3IybDBHbUREa0dMNlpQ?= =?utf-8?B?OUJ4aFNCdXZ6VW1rWWIvam1oSmpWNnFsWDE3Yk1tL0g3U2tzQlUxMWwxbEJn?= =?utf-8?B?cG5PUTcra1hTeDJkYmN4ckRyQXByZDZZTWxTRFc2YTBMUVYvR2ZsRGhXU3Uw?= =?utf-8?B?WURFaUdjQVVIVVVkSGQyckNZalR0VklEd0xqRXNGUlZSWmpUVll2aXBPSVdJ?= =?utf-8?B?dVJWVy9LMHF0THRrWjBESzNHTVl5bEs1NzhzRDBkZGNMZE1LckZYcE8xMGNq?= =?utf-8?B?SFZ2ZEN2eWxxT25qbmtMMGRLRzBxUEZCYlkvVHdXa3lTajBYWGtORU4vdzRG?= =?utf-8?B?aUVpb1BaUUxJRm8vYUNZYTZKYmRsREVzdUVvVHU4amVXQTJIM3dJQ2Rwam1B?= =?utf-8?B?YVlVbnUvakpORkd2a2ZQdU15bkVWdkZHSVRZa3RqR3B0cmhiNERmQVNrdXBl?= =?utf-8?B?Mmd5dDNuTGwydC8xUmp3RlZRVUdCS1QvRmx2djNLM244SFFpYVpYUDBiYnFw?= =?utf-8?B?QndNdjczZjlpNDJ2R09KTHNMQS9hbmFQYVNqMEZoUWxaWnM0SkMxdGRZakRa?= =?utf-8?B?SUxXdUc5OU9Vbml4OHd3SitManZZeldGbnk4b1ZEVG52VS9DSVJYMU9mdEsw?= =?utf-8?B?YXo4QjJFSnRCbVlYNDhLVVZJTW5va1crMmpNSXRxOVRCSnFmZ2U5MW1PbDFm?= =?utf-8?B?TWJEczRRVXd6YlNCaVcxd0tRU0xSU3BtNkd3ZkhaMGFvTUFUY3RuK2xTcGNN?= =?utf-8?B?M1BnMUdVNThVUVBsdlpndmdnVHRMZW9ya2Nhd2ZWUFV2Zmp3RWU0QW80Y2Mx?= =?utf-8?B?U1U0bXBsQWhpc2hIQjN3SElqSkZXUDhJemVqaDZWcjM0d1JDMG4zcGVJZGx3?= =?utf-8?B?UjRxTXFIMlFhVkltVXovenJMaldPdXE0WG03Y2JUdHVTcUZvazEra1oxdERp?= =?utf-8?B?bjVyWm1uVlVET0trL2xocGdvaXc5eER2Vk9Rc1RMNjBEbGF3bWFnVjAwa0VM?= =?utf-8?B?MjNTZWFwdkVoVURzc1pjVUticlhnbCtPVVRhbXFEQWM3Y0k3eEkxWUNpZk93?= =?utf-8?B?N2c4YVFuK1p2djUzZ3l1TFJzTjVMY3FkVC91M2lUZzRIZmdtYzZDUlF2ZGps?= =?utf-8?B?dnowTFJ5NTArQjZ4aVNrL0VXa1k1UFYyaHRSa0tlVEg0UmZDQU81bFdTRCs3?= =?utf-8?B?eW9HOWxIdGNKZG0yenRCYVpiQjltbWtDeEVLV3RtWWxjM25DMUNsblFLczJy?= =?utf-8?B?ZGlKZ0ZjREk5SldTamJRQUdLSzJ4L2lrR0R4b1lHczVZc0dnN0VrQVhCb2FI?= =?utf-8?B?R0NvaXJ3Qy9VZjdCODgvYUFES0gwM3BzWEJRTVVwV1NEWGdIYVNoa2RrbHJm?= =?utf-8?B?MXRxbEdZanhqMmR3Z0xEZFk2K0FoUCtobVZ0c3ExQmFnM1lLcGQwa2d3WGY1?= =?utf-8?B?TlFhTFBjYzc0OEVVOUVidGZUbXJ0QkZRTlVRVUFQVmJlTlp6WkR0TlpOQkNR?= =?utf-8?B?R1E4ZjhOL2piQ1N5eHo1VEREc0dxeWQrNlBsd0ZwMklNczMwbWhYSUpxY2xv?= =?utf-8?B?WDVjaXlSRXV3NEl6UTBhOWpMSEt3elE5TURKUVZBQkRSMUl5SWZzTS8wK2Nv?= =?utf-8?B?RkNRRnNSWk1aQytRQVBYTGdJR2dTRjY0N0dDa1R5eEhnbk9XTEVPZFZNMVZ5?= =?utf-8?B?U1ZqeDdhSnRLMmZwTlpqZVlnYVF2QVpJVDU3N2o3eDVVY0JyTW1sbE1DMDE5?= =?utf-8?B?K2VmWjNHMlRoRGtJSjI1NHlpdm5KSWNxelhLQVpXMWh1VUhJK3ZkRDhGUmJW?= =?utf-8?B?akR4TGY3akRRdWZEK2prWW1vaGdBQlBmSnVEQjdSbXZUMEtRV2hja2k2bWJJ?= =?utf-8?B?aWhvd05VdjJ5Nk13bHRvZHVBNkRLLzBkWm9FL0RUL3RZSTBWazRpSENkbW1P?= =?utf-8?B?MHl1d0lMVUJEbnlYTHgzekQyemZkV05iajY5WU4rVWNoOWRCb281N2xYdDYz?= =?utf-8?B?SjVSL016dGlnV2hIYU4zZm1nbExTbUNsWnR4dUt4Vy9ZQlhXZm03bnIwblhi?= =?utf-8?B?NVdkcHRrTlNKa213WW5iUVp1a1Q3KzdER1NwUWRYbXN1VTJCZmZnVFA1Mnkr?= =?utf-8?B?UjF5UXpzdElPbmcyQ1NsZ2xSZmR1cGFodWQzems0VU5UV3ZkajlQaHVjSUxj?= =?utf-8?B?RXpaNkx3SHk5dVdsV0w5NEpJQktPb0pEcG9wZ3ViOWZTV2hpL1lIdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7db2f6a-1b16-40db-66eb-08df23dc356f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 19:01:20.7227 (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: 2McEy5L7naGTyYC0QbLwHYkV+Mq4kX4kspIA7ZK3svkFoFI1HIk3ZNKOr70t6cANImLd3oEp96AVF7VvmQy8NJMpjc9tsUJK7oivozbD4sI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6536 X-purgate-ID: tlsNG-42698a/1791313284-A84CB9EA-E884AD5F/10/78276251493 X-purgate-type: spam X-purgate-size: 2124 On 06/10/2026 12:26 pm, Jan Beulich wrote: > On 06.10.2026 12:54, Andrew Cooper wrote: >> kexec_reloc() does not return. Plumbing this property upwards lets us mark >> machine_kexec() and machine_reboot_kexec() noreturn too. > The latter already is annotated such (see also next remark) as of 4d2ed2f88a0c. You missed half of it.  I'm surprised that it didn't create a MISRA violation. > >> --- a/xen/arch/x86/machine_kexec.c >> +++ b/xen/arch/x86/machine_kexec.c >> @@ -142,15 +142,14 @@ void machine_kexec_unload(struct kexec_image *image) >> /* no-op. kimage_free() frees all control pages. */ >> } >> >> -void machine_reboot_kexec(struct kexec_image *image) >> +void noreturn machine_reboot_kexec(struct kexec_image *image) >> { >> BUG_ON(smp_processor_id() != 0); >> smp_send_stop(); >> machine_kexec(image); >> - BUG(); >> } >> >> -void machine_kexec(struct kexec_image *image) >> +void noreturn machine_kexec(struct kexec_image *image) >> { >> int i; >> unsigned long reloc_flags = 0; > The annotations here aren't needed, are they? I.e. this hunk can shrink > to just the removal of the BUG() invocation. Readers of this code are not psychic.  They shouldn't need to be in order to follow what's going on. > >> --- a/xen/include/xen/kexec.h >> +++ b/xen/include/xen/kexec.h >> @@ -49,7 +49,7 @@ int machine_kexec_load(struct kexec_image *image); >> void machine_kexec_unload(struct kexec_image *image); >> void machine_kexec_reserved(xen_kexec_reserve_t *reservation); >> void noreturn machine_reboot_kexec(struct kexec_image *image); >> -void machine_kexec(struct kexec_image *image); >> +void noreturn machine_kexec(struct kexec_image *image); > The annotations on the declarations are sufficient, with another Misra > rule making sure we don't omit the inclusion of the header in the CU > having the definitions. > > Preferably with the redundant annotations omitted, and with the description > slightly adjusted: > Reviewed-by: Jan Beulich I am not inclined to make changes. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Oct 06 22:50:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Oct 2026 22:50:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441788.1659296 (Exim 4.92) (envelope-from ) id 1xEDzJ-00039c-AB; Tue, 06 Oct 2026 22:50:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441788.1659296; Tue, 06 Oct 2026 22:50: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 1xEDzJ-00039U-61; Tue, 06 Oct 2026 22:50:21 +0000 Received: by outflank-mailman (input) for mailman id 1441788; Tue, 06 Oct 2026 22:50:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEDzH-00039O-Kq for xen-devel@lists.xenproject.org; Tue, 06 Oct 2026 22:50:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEDzH-006AlA-1q for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:50:19 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac57b20-bab6-0a2a0a5309dd-0a2a450ceabe-8 for ; Wed, 07 Oct 2026 00:50:18 +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 6ac57b2a-f479-0a2a450c0019-b9ff1c229431-3 for ; Wed, 07 Oct 2026 00:50: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 1a113690c000003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 06 Oct 2026 22:50: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 BA7C381FA6; Wed, 7 Oct 2026 00:50: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: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=O81Nv2O6yrvE2UJe/LQnJw/HE85NOJ4NyK1jqNvu62g=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=lwz36CVRRwo8EvVUgNaOdcAioVJYpz94gWTpk5XEHCIe6FI4r4RaBzOkDxPaMyZkjwQLy0e1H 33NN+e8qYKoX8GQsPkgfGPLOev0fGAbWcwLWTE5gac1nXrAcJkIK+wSmYPaaK9Vx9whZ1k0lb4w Yqa3YJO3I9XqB/iUkCbAnyYhURMlfHD/NfHLeIWh+c5r+93Qe3/lTrc6EiuySVDo3BehFfCscRQ I6qgv1tNjlcSDG6DfSkmYQS0X2IHRyqEn8xSLzYw186hUW4RylCSZAbCsqxOsYSkbJCTRmqKgVr IEJ0YsJsl9yWeme4IxFWn5XdIsIi17qeptB7Z9YJWV5w== X-Zone-Loop: 64d199bd89b480ecc2cb888c5d29e4ec68eaec6c380b x-campaign-type: default x-transaction-id: 457943eb-1d24-4365-a3a1-15a782e0812f x-swg-uid: 01-92d62c2c-e386-4107-9190-afd94a12cb2f X-Mailer: Sweego Message-ID: <1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66@vates.tech> x-swg-bid: 1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 7 Oct 2026 00:50:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@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: <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------IXdzjGlGWvVRa00rhhLKK7y4" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791327013041 X-purgate-ID: tlsNG-d25034/1791327018-01CC3A5B-83D008F1/0/0 X-purgate-type: clean X-purgate-size: 13609 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------IXdzjGlGWvVRa00rhhLKK7y4 Content-Type: multipart/mixed; boundary="------------LPrDsaYsYUL9m9NNB03pVcjT"; protected-headers="v1"; hp="clear" Message-ID: <93e52a59-b192-4c99-9226-e7d331a2393e@vates.tech> Date: Wed, 7 Oct 2026 00:50:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@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: <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> --------------LPrDsaYsYUL9m9NNB03pVcjT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDUvMTAvMjAyNiDDoCAxODowMiwgQmFwdGlzdGUgTGUgRHVjIGEgw6ljcml0wqA6DQo+ IEEgUklTQy1WIGltcGxlbWVudGF0aW9uIGNhbiBtYW5hZ2UgdGhlIFBURSBBL0QgYml0cyBp biBvbmUgb2YgdHdvIHdheXM6DQo+ICAgICAgMSkgVXBkYXRlIHRoZSAnQScgYW5kICdEJyBQ VEUgYml0cyBpbiBoYXJkd2FyZSAocmF0aWZpZWQgYXMgU3ZhZHUpLg0KPiAgICAgIDIpIEdl bmVyYXRlIGEgcGFnZSBmYXVsdCB3aGVuICdBJyBhbmQvb3IgJ0QnIGlzIGNsZWFyLCBzbyB0 aGF0IHNvZnR3YXJlDQo+ICAgICAgICAgY2FuIHNldCB0aGVtIChyYXRpZmllZCBhcyBTdmFk ZSkuDQo+IA0KPiBwMm1fc2V0X3B0ZV9mbGFncygpIHByZXNldHMgQS9EIGluIEctc3RhZ2Ug UFRFcyBvbmx5IHdoZW4gdGhlIGRldmljZSB0cmVlDQo+IGFkdmVydGlzZXMgU3ZhZGUuIFBs YXRmb3JtcyB0aGF0IHVzZSBzY2hlbWUgKDIpIHdpdGhvdXQgYWR2ZXJ0aXNpbmcgU3ZhZGUs DQo+IHN1Y2ggYXMgdGhlIEhpRml2ZSBQcmVtaWVyIFA1NTAsIHRoZW4gaGl0IGd1ZXN0LXBh Z2UgZmF1bHRzIHRoYXQgWGVuIGRvZXMNCj4gbm90IGhhbmRsZS4NCg0KSSBzZWNvbmQgd2hh dCBKYW4gc2FpZCAodGhpcyBpcyBsaWtlbHkgYSBmaXJtd2FyZSBidWcsIGdpdmVuIHRoYXQg dGhlIA0KZW51bWVyYXRlZCBiZWhhdmlvciBpcyBub3QgY29uc2lzdGVudCB3aXRoIHRoZSBz cGVjaWZpY2F0aW9uLCBhcyANCmV4aXN0ZW5jZSBvZiBTdmFkdS9TdmFkZSBhbHRlcnMgb2Jz ZXJ2YWJsZSBiZWhhdmlvcikuDQoNCj4gDQo+IEFsd2F5cyBwcmVzZXQgQS9EIGluIEctc3Rh Z2UgUFRFcyBzbyBzY2hlbWUgKDIpIG5ldmVyIGZhdWx0cy4gVGhpcyBpcw0KPiBoYXJtbGVz cyB3aXRoICgxKTogc29mdHdhcmUganVzdCBkb2VzIHdoYXQgaGFyZHdhcmUgd291bGQgaGF2 ZSBkb25lIG9uDQo+IGZpcnN0IGFjY2Vzcy4NCj4gDQo+IERyb3AgdGhlIFRPRE8gc3VnZ2Vz dGluZyB0byBoYW5kbGUgQS9EIGZhdWx0czogb25seSBTdmFkZSByYWlzZXMgdGhlbSwgc28N Cj4gaXQgd291bGQgbm90IHdvcmsgb24gU3ZhZHUuIERpcnR5L2FjY2VzcyB0cmFja2luZyBj YW4gcmVzdHJpY3QgdGhlIFJXWA0KPiBwZXJtaXNzaW9ucyBvZiBwMm0gZW50cmllcywgYXMg eDg2IGFuZCBBcm0gZG8uDQpZZXQsIGV4aXN0ZW5jZSBvZiBTdmFkZSBhbG9uZSBkb2Vzbid0 IG1hbmRhdGUgdGhlIGFjdHVhbCBiZWhhdmlvciwgaXQgaXMgDQphbHNvIGRlcGVuZGFudCBv biB0aGUgdmFsdWUgb2YgQURVRSBiaXQgaW4gY29uZmlndXJhdGlvbiByZWdpc3RlcnMuDQoN CklkZWFsbHkgKGluIGNhc2VzIHdlIGNhbikgd2Ugd291bGQgd2FudCB0byBjb25maWd1cmUg aGFyZHdhcmUgdG8gZm9sbG93IA0KYSBjb25zaXN0ZW50IHNjaGVtZSAod2l0aCB0aGUgb25l IHRoYXQgdXBkYXRlcyBBL0Qgd2l0aCBoYXJkd2FyZSBpLmUgDQpBRFVFPTEsIGFzIGl0J3Mg Y29uc2lzdGVudCB0byB3aXRob3V0IFN2YWRlKSBhbmQgb25seSBjb25zaWRlciB0aGUgDQpB RFVFPTAgYmVoYXZpb3IgZm9yIHNwZWNpZmljIG5lZWRzIGxpa2UgZGlydHkgdHJhY2tpbmcu DQoNCj4gPiBGaXhlczogZmYxNDA1Mzk4M2IwICgieGVuL3Jpc2N2OiBJbXBsZW1lbnQgcDJt X3B0ZV9mcm9tX21mbigpIGFuZCANCnN1cHBvcnQgUEJNVCBjb25maWd1cmF0aW9uIikNCj4g QXNzaXN0ZWQtYnk6IENsYXVkZTpjbGF1ZGUtb3B1cy01DQo+IFNpZ25lZC1vZmYtYnk6IEJh cHRpc3RlIExlIER1YyA8YmFwdGlzdGUubGUtZHVjQHZhdGVzLnRlY2g+DQo+IC0tLQ0KPiBD aGFuZ2VzIHNpbmNlIHY0Og0KPiAtIHJlc3RvcmUgc3ZhZGUgYW5kIHVwZGF0ZSB0aGUgY29t bWl0IG1lc3NhZ2UgYWNjb3JkaW5nbHkuDQo+IC0gcmViYXNlIG9uIHRvcCBvZiBzdGFnaW5n Lg0KPiAtLS0NCj4gQ2hhbmdlcyBzaW5jZSB2MzoNCj4gLSBhbHdheXMgcHJlc2V0IEEvRCBi aXRzIGluIEctc3RhZ2UgbWFwcGluZ3MgaW5zdGVhZCBvZiBrZXlpbmcgb2ZmIHRoZSBEVDoN Cj4gICAgaXQgbWF5IG5vdCByZWZsZWN0IHdoYXQgdGhlIGhhcmR3YXJlIGFjdHVhbGx5IGRv ZXMuDQo+IC0gY2hhbmdlIGNvbW1pdCB0aXRsZS9tZXNzYWdlLg0KPiAtIGRyb3Agc3ZhZGUg YXMgaXQgaXMgbm93LXVudXNlZC4NCj4gLS0tDQo+IENoYW5nZXMgc2luY2UgdjI6DQo+IC0g Y2hhbmdlIGNvbW1pdCB0aXRsZS4NCj4gLSBwcmVzZXQgQS9EIGJpdHMgaW4gcDJtX3NldF9w dGVfZmxhZ3MoKSBpZiAoIXN2YWR1IHx8IHN2YWRlKSwgaW5zdGVhZCBvZg0KPiBzZXR0aW5n IFJJU0NWX0lTQV9FWFRfc3ZhZGUgaW4gdGhlIHJpc2N2X2lzYSBiaXRtYXAgZm9yIGNhc2Vz IDEsIDIgYW5kIDQuDQo+IC0gcmlzY3ZfcmVzb2x2ZV9hZF9zY2hlbWUoKSBub3cgb25seSB3 YXJucyB3aGVuIGJvdGggU3ZhZGUgYW5kIFN2YWR1IGFyZQ0KPiBwcmVzZW50IGFuZCBTQkkg RldGVCBpcyBtaXNzaW5nOyBkcm9wIHRoZSBkZWFkICdzdmFkdSAmJiBzdmFkZScgb3BlcmFu ZC4NCj4gLSByZXBlYXQgWEVOTE9HX1dBUk5JTkcgb24gZWFjaCBsaW5lIG9mIHRoZSB3YXJu aW5nLg0KPiAtIGRyb3AgQVNTRVJUKHN2YWRlICE9IHN2YWR1KSBmcm9tIHAybV9zZXRfcHRl X2ZsYWdzKCkuDQo+IC0gb25seSBhZGQgdGhlIHNiaV9wcm9iZV9leHRlbnNpb24oKSBkZWNs YXJhdGlvbiB0byBzYmkuaC4NCj4gLSByZXdvcmsgdGhlIGNvbW1lbnQgaW4gcDJtX3NldF9w dGVfZmxhZ3MoKS4NCj4gLS0tDQo+IENoYW5nZXMgc2luY2UgdjE6DQo+IC0gY2hhbmdlIGNv bW1pdCB0aXRsZQ0KPiAtIGV4cG9zZSBSSVNDVl9JU0FfRVhUX3N2YWR1IHNvIHRoZSB0d28g ZXh0ZW5zaW9ucyBjYW4gYmUgdG9sZCBhcGFydC4NCj4gLSBtb3ZlIHRoZSBTdmFkZS9TdmFk dSByZXNvbHV0aW9uIHRvIGEgbmV3IHJpc2N2X3Jlc29sdmVfYWRfc2NoZW1lKCksDQo+ICAg IGNhbGxlZCBvbmNlIGZyb20gcmlzY3ZfZmlsbF9od2NhcCgpLg0KPiAtIGV4cG9zZSBzYmlf cHJvYmVfZXh0ZW5zaW9uKCkgKHdhcyBzdGF0aWMpIHRvIHByb2JlIGZvciBTQkkgRldGVC4N Cj4gLSBzdG9wIHByZXNldHRpbmcgQS9EIGJpdHMgdW5jb25kaXRpb25hbGx5IGluIHAybV9z ZXRfcGVybWlzc2lvbigpLCBkbyBpdA0KPiAgICBvbmx5IHdoZW4gU3ZhZGUgaXMgcHJlc2Vu dC4NCj4gLS0tDQo+ICAgeGVuL2FyY2gvcmlzY3YvcDJtLmMgfCAzOCArKysrKysrKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgIDEgZmlsZSBjaGFuZ2VkLCA4IGluc2Vy dGlvbnMoKyksIDMwIGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNo L3Jpc2N2L3AybS5jIGIveGVuL2FyY2gvcmlzY3YvcDJtLmMNCj4gaW5kZXggZjdiMzgwYjkw YS4uMTRjYWU3ZGNkNyAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gvcmlzY3YvcDJtLmMNCj4g KysrIGIveGVuL2FyY2gvcmlzY3YvcDJtLmMNCj4gQEAgLTU5MSwzOCArNTkxLDE2IEBAIHN0 YXRpYyB2b2lkIHAybV9zZXRfcHRlX2ZsYWdzKHB0ZV90ICplLCBwMm1fdHlwZV90IHQpDQo+ ICAgICAgIGUtPnB0ZSB8PSBQVEVfVVNFUjsNCj4gICANCj4gICAgICAgLyoNCj4gLSAgICAg KiBUd28gc2NoZW1lcyB0byBtYW5hZ2UgdGhlIEEgYW5kIEQgYml0cyBhcmUgZGVmaW5lZDoN Cj4gLSAgICAgKiAgIOKAoiBUaGUgU3ZhZGUgZXh0ZW5zaW9uOiB3aGVuIGEgdmlydHVhbCBw YWdlIGlzIGFjY2Vzc2VkIGFuZCB0aGUgQSBiaXQNCj4gLSAgICAgKiAgICAgaXMgY2xlYXIs IG9yIGlzIHdyaXR0ZW4gYW5kIHRoZSBEIGJpdCBpcyBjbGVhciwgYSBwYWdlLWZhdWx0DQo+ IC0gICAgICogICAgIGV4Y2VwdGlvbiBpcyByYWlzZWQuDQo+IC0gICAgICogICDigKIgV2hl biB0aGUgU3ZhZGUgZXh0ZW5zaW9uIGlzIG5vdCBpbXBsZW1lbnRlZCwgdGhlIGZvbGxvd2lu ZyBzY2hlbWUNCj4gLSAgICAgKiAgICAgYXBwbGllcy4NCj4gLSAgICAgKiAgICAgV2hlbiBh IHZpcnR1YWwgcGFnZSBpcyBhY2Nlc3NlZCBhbmQgdGhlIEEgYml0IGlzIGNsZWFyLCB0aGUg UFRFIGlzDQo+IC0gICAgICogICAgIHVwZGF0ZWQgdG8gc2V0IHRoZSBBIGJpdC4gV2hlbiB0 aGUgdmlydHVhbCBwYWdlIGlzIHdyaXR0ZW4gYW5kIHRoZQ0KPiAtICAgICAqICAgICBEIGJp dCBpcyBjbGVhciwgdGhlIFBURSBpcyB1cGRhdGVkIHRvIHNldCB0aGUgRCBiaXQuIFdoZW4g Ry1zdGFnZQ0KPiAtICAgICAqICAgICBhZGRyZXNzIHRyYW5zbGF0aW9uIGlzIGluIHVzZSBh bmQgaXMgbm90IEJhcmUsIHRoZSBHLXN0YWdlIHZpcnR1YWwNCj4gLSAgICAgKiAgICAgcGFn ZXMgbWF5IGJlIGFjY2Vzc2VkIG9yIHdyaXR0ZW4gYnkgaW1wbGljaXQgYWNjZXNzZXMgdG8g VlMtbGV2ZWwNCj4gLSAgICAgKiAgICAgbWVtb3J5IG1hbmFnZW1lbnQgZGF0YSBzdHJ1Y3R1 cmVzLCBzdWNoIGFzIHBhZ2UgdGFibGVzLg0KPiAtICAgICAqIFRoZXJlYnkgdG8gYXZvaWQg YSBwYWdlLWZhdWx0IGluIGNhc2Ugb2YgU3ZhZGUgaXMgYXZhaWxhYmxlLCBpdCBpcw0KPiAt ICAgICAqIG5lY2Vzc2FyeSB0byBzZXQgQSBhbmQgRCBiaXRzLg0KPiArICAgICAqIEEgUklT Qy1WIGltcGxlbWVudGF0aW9uIGNhbiBlaXRoZXI6DQo+ICsgICAgICogMSkgVXBkYXRlIHRo ZSAnQScgYW5kICdEJyBQVEUgYml0cyBpbiBoYXJkd2FyZS4NCj4gKyAgICAgKiAyKSBHZW5l cmF0ZSBhIHBhZ2UgZmF1bHQgd2hlbiAnQScgYW5kL29yICdEJyBpcyBjbGVhciwgc28gdGhh dA0KPiArICAgICAqICAgIHNvZnR3YXJlIGNhbiBzZXQgdGhlbS4NCg0KDQoNCj4gICAgICAg ICoNCj4gLSAgICAgKiBUT0RPOiBGb3Igbm93LCBpdOKAmXMgZmluZSB0byBzaW1wbHkgc2V0 IHRoZSBBL0QgYml0cywgc2luY2UgT3BlblNCSQ0KPiAtICAgICAqICAgICAgIGRlbGVnYXRl cyBwYWdlIGZhdWx0cyB0byBhIGxvd2VyIHByaXZpbGVnZSBtb2RlIGFuZCBzbyBPcGVuU0JJ DQo+IC0gICAgICogICAgICAgaXNuJ3QgZXhwZWN0IHRvIGhhbmRsZSBwYWdlLWZhdWx0cyBv Y2N1cmVkIGluIGxvd2VyIG1vZGVzLg0KPiAtICAgICAqICAgICAgIEJ5IHNldHRpbmcgdGhl IEEvRCBiaXRzIGhlcmUsIHBhZ2UgZmF1bHRzIHRoYXQgd291bGQgb3RoZXJ3aXNlDQo+IC0g ICAgICogICAgICAgYmUgZ2VuZXJhdGVkIGR1ZSB0byB1bnNldCBBL0QgYml0cyB3aWxsIG5v dCBvY2N1ciBpbiBYZW4uDQo+IC0gICAgICoNCj4gLSAgICAgKiAgICAgICBDdXJyZW50bHks IFhlbiBvbiBSSVNDLVYgZG9lcyBub3QgbWFrZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uDQo+ IC0gICAgICogICAgICAgdGhhdCBjb3VsZCBiZSBvYnRhaW5lZCBmcm9tIGhhbmRsaW5nIHN1 Y2ggcGFnZSBmYXVsdHMsIHdoaWNoDQo+IC0gICAgICogICAgICAgY291bGQgb3RoZXJ3aXNl IGJlIHVzZWZ1bCBmb3Igc2V2ZXJhbCB1c2UgY2FzZXMgc3VjaCBhcyBkZW1hbmQNCj4gLSAg ICAgKiAgICAgICBwYWdpbmcsIGNhY2hlLWZsdXNoaW5nIG9wdGltaXphdGlvbnMsIG1lbW9y eSBhY2Nlc3MgdHJhY2tpbmcsZXRjLg0KPiAtICAgICAqDQo+IC0gICAgICogICAgICAgVG8g c3VwcG9ydCB0aGUgbW9yZSBnZW5lcmFsIGNhc2UgYW5kIHRoZSBvcHRpbWl6YXRpb25zIG1l bnRpb25lZA0KPiAtICAgICAqICAgICAgIGFib3ZlLCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g c3RvcCBzZXR0aW5nIHRoZSBBL0QgYml0cyBoZXJlIGFuZA0KPiAtICAgICAqICAgICAgIGlu c3RlYWQgaGFuZGxlIHBhZ2UgZmF1bHRzIHRoYXQgb2NjdXIgZHVlIHRvIHVuc2V0IEEvRCBi aXRzLg0KPiArICAgICAqIFhlbiBzdXBwb3J0cyBib3RoLCBzbyBzZXQgJ0EnIGFuZCAnRCcg dXAgZnJvbnQgdG8gYXZvaWQgdGhlIGZhdWx0cw0KPiArICAgICAqIG9mICgyKS4gVGhpcyBp cyBoYXJtbGVzcyB3aXRoICgxKTogc29mdHdhcmUganVzdCBkb2VzIHdoYXQgaGFyZHdhcmUN Cj4gKyAgICAgKiB3b3VsZCBoYXZlIGRvbmUgb24gZmlyc3QgYWNjZXNzLg0KPiAgICAgICAg Ki8NCj4gLSAgICBpZiAoIHJpc2N2X2lzYV9leHRlbnNpb25fYXZhaWxhYmxlKE5VTEwsIFJJ U0NWX0lTQV9FWFRfc3ZhZGUpICkNCj4gLSAgICAgICAgZS0+cHRlIHw9IFBURV9BQ0NFU1NF RCB8IFBURV9ESVJUWTsNCj4gKyAgICBlLT5wdGUgfD0gUFRFX0FDQ0VTU0VEIHwgUFRFX0RJ UlRZOw0KDQpPbiB0aGUgY29kZSBjaGFuZ2UgaXRzZWxmLCBpdCBsb29rcyBnb29kIHRvIG1l LCBhcyB3ZSBkb24ndCBtYWtlIHVzZSBvZiANCkEvRCBiaXQgYW55d2F5IChhbmQgaW4gY2Fz ZSB3ZSB3b3VsZCBuZWVkIHRvLCB3ZSB3b3VsZCBuZWVkIHRvIGNsZWFyIA0KdGhlbSBhbnl3 YXkpLg0KDQo+ICAgDQo+ICAgICAgIHN3aXRjaCAoIHQgKQ0KPiAgICAgICB7DQo+IA0KDQo= --------------LPrDsaYsYUL9m9NNB03pVcjT-- --------------IXdzjGlGWvVRa00rhhLKK7y4 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+p0QLLz9AFAmrFeyQFAwAAAAAACgkQZg+p0QLLz9Dq QAwAia5g73oRH2OnkE12+WbT4QFI1MJZuJE3dHoRV4Wy/hE+kqFIYEE4kbZf5lTapk4xuulzQsK+ SM+2I1TFKRNqB9IqVxwgkbQQGEXpPJBOPmMGgt9wqyDpEqSLiO+2JQhRUPINtHb5wj2UwDi9LSQl eAapGTAHBATN5UTfAgtNvfGWFZqWTM0BEghZmLOKBOtL1pIYQUTo1qW49TnKNTO6PPJAoKYlVwld 0loPsltSODLdjyOnU1TGi6znusbXduC9rUEce5FvD4UIEKg4hK/FdFJ/cuXbKbmj55LMmVT5daS9 UgTJhZ7CbCazymBMn+yWuU1053LotAcyO75S4Ig4rSCAhnyiJTtMGIkRiYpC514H16qmu64SrVnR 7FeRmys9PeqnZDiyiSTrmTz0QvfXCVMDTEi13PEKdhMC6OSalzVbmzyWQnU1xax+aHy5IhOasiU7 EgCvJBANAnQ6e1as7jfgxkrImssfrgb6nVENtUZ5U84iomwYW3V0m2frh/K1 =g6WS -----END PGP SIGNATURE----- --------------IXdzjGlGWvVRa00rhhLKK7y4-- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441806.1659305 (Exim 4.92) (envelope-from ) id 1xEFAm-000767-BR; Wed, 07 Oct 2026 00:06:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441806.1659305; Wed, 07 Oct 2026 00:06: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 1xEFAm-00075z-6t; Wed, 07 Oct 2026 00:06:16 +0000 Received: by outflank-mailman (input) for mailman id 1441806; Wed, 07 Oct 2026 00:06:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFAj-00075h-Tn for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFAi-000T0Z-Gh for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:12 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58c9c-e002-0a2a0a5209dd-0a2a450ca834-38 for ; Wed, 07 Oct 2026 02:06:12 +0200 Received: from [40.107.159.132] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58cf4-f479-0a2a450c0019-286b9f84d607-3 for ; Wed, 07 Oct 2026 02:06:12 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by VI0PR03MB11456.eurprd03.prod.outlook.com (2603:10a6:800:321::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.23; Wed, 7 Oct 2026 00:06:08 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=Uwr7iZJBIqPOQVpVV7eg1371J/lPbqTBzo6j93H1qPTL3fEE8xrYYe27sdI1Evm4GTr3h4gIXdVI42/4FRO85rLy/d3rKnWf3mgvWt43vxeEwicEN19bTdliGqjbWxiHIMTecTBkpBKwsx8hjgWfqFP6MpucRCl2LxY20K/An/HdimRPv48aZvNkfoQakM/tS1Y33v623T5g2E9At3gAFCQpMvEabahY3/FEjEfQXeJX7HlbDC/D8UfMws6eb+aDRurDsOyD+BW+jIi+mltOJksCg3uery6rpVQHq32tGdPD0xWs32BtikG01CH0jFi8FaQD532zlsm4LLVMinH0pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qDnrABlNaqMUiEp/A59uaP/HrHYZnveJGL4SHIUKVe0=; b=XcO7oq+ThiJcENE4oUVoL29KHqQb2s1oC19yJ88NjXCM3LqaNwu4Vk+gg37VKk3tsPYurKqlfmp0qArcIoZbbNK8VU1/byizdHO3ABaA0r0MOq7X/JSIYOKgXX6FyMFyjegEDKnbCCeXpnYHnIi1vct9wke0lDLjnv8fQZWaaT60QNPRdxjbokn+P6LHIkPhqCZlKS+Vmpm7hQhixmE1CC/M6dtVELnA76B6n1JpeqXQloBlQqPLDY90LT4VC3fnFDs8bJsCVjoxR16aMmlJ1LKHGy42sLB6RozEEX3QWixDPFC+M4ajsHGbL9hAKUWi4er77+ESuu2+iqQVG4p/Vg== 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=qDnrABlNaqMUiEp/A59uaP/HrHYZnveJGL4SHIUKVe0=; b=GCFXjZaT25EFoi9OtoGOrH/nJSPCTaDgYve8vfO7luU4g6oLHfUyAZKMUgrPHH4H/SeOt7uXf/t+d4iU+LtOGr5K3Sjmg3i65cY3V7UOUm77DMU8J4csH1VS5w3D0XGVq9DLyydowQbyor8r5wo8zkEgrFwLACY+4d905cUapYyNB13/RN6nEm5vj5DgZXbkjjLcdGCnEIo3dxJwh5OPlSXo5+leSALkrdyv08e0vs8w1tPnrmromcmUvth7JKpQxDL0KLZWH/RwhgWqQjShDzRVYK12IEeyJYpFgpRgyg67rKopz4BH+xHPuakVEjcBH+FvirXXa0fB7Nc391mPQA== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Milan Djokic , Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Anthony PERARD , Nick Rosbrook , George Dunlap , Juergen Gross , Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "Daniel P. Smith" Subject: [PATCH v4 00/22] Add SMMUv3 Stage 1 Support for Xen guests Thread-Topic: [PATCH v4 00/22] Add SMMUv3 Stage 1 Support for Xen guests Thread-Index: AQHdVe+nlB5jtxSHWEOq+UwovVtjiw== Date: Wed, 7 Oct 2026 00:06:08 +0000 Message-ID: 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: AS2PR03MB9587:EE_|VI0PR03MB11456:EE_ x-ms-office365-filtering-correlation-id: 69d3dd6b-472b-448c-fcdb-08df2406c9c8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|366016|376014|1800799024|56012099006|38070700021|260925022911599003|260925021311599003|260925021911599003|10067099003|6133799003|11063799006|18002099003; x-microsoft-antispam-message-info: Z/VUcbBXvc8vyzcSI6obdNye6/fi55eVm+uccphLtnCVuTKpgW+ZnpM1XrQ/BnazelSZrG00MZfbZBp/VAs6Ye8xrfSxyoRbzHg0JiNsb55Iz736E4YyhDTXDn5C8JxTt4CB416fMv7+vGPB615fvWLV/J5OHS3M976Otp3J/EVN2/fEawYlLhpy8xfSyN9xW+XNMD2iN/w9d+dmC9YpdSxXLTH5ALcA6xgyfSMJK6lsUIW8KmnlH5jjoCUVc8p3W2YuV5L9OwRClDQe+UnxqiIxonOvoEdYvwneHSTxiQ2DpR4bTZU+LVgBEp/zzVcLgUkjgDHKZ8z3VrziSZO7wgfxSuPosVhoaaxE3VALFn7VHnIz+H3wHZwvO9X6Ygr7y9Qv8toiPUHpl08oQeBOHbHeXqWsTU1FNIsvzS56IbL5PwQet/aZ/jrH+/aRguW4ZfkkLrc98Xy4PK4WPpf6sFdm7W+nOMe6TdaQc1CEt4IhXEyGDW5J/2SZQYT25mn39C/AS9QJoN2Lm+CKNe4SPkUSfdSgTrOFw+pRmEBlGL/EA2jSHRtG1wLHw/pxcXsCPlrILQaxJ61e4A+tjkYUdivjTEp5XAPXHy+dW1FTFF3nUnp5ysN9CGaT3MkhgyCQZEkWYAhqrKkG2NQcLs9fg19h/RBKz3ybzxWdCAkFcXWYyHNXifMkMiLm30hPg7IX8KCZS/ZOxInXZLPfjMUpd+NGqFHqFBAfc0ysfdPcI/8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(366016)(376014)(1800799024)(56012099006)(38070700021)(260925022911599003)(260925021311599003)(260925021911599003)(10067099003)(6133799003)(11063799006)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ek14allIT2NidGM2V1BCRE1mK1N2STA4azU2M0czeGFSWDFsSzRTcGdVMkxU?= =?utf-8?B?ZlpvTGRxVzh0bnNaNDRVc3VJMUdZRWFzMTRuNk94OGJWRFZnejVzQ1ovbElx?= =?utf-8?B?T0hpN2dWRndPdGduYjlHVXVOVENwaUZLMGtRMk5FTjRGUzcxOG5nVGxrVjRh?= =?utf-8?B?aitXeGFQZG82cjN5WW5BT1d1NlMwN1o5cmxGMEpTWFRoTjFIUkZpd0ZjRE5y?= =?utf-8?B?QlAyZFhZNHFvVEV5TWpHUHQ3VS9jZGtrY2hQVUpqeU5sRVQrSEJOK0Q5VExr?= =?utf-8?B?eVhOQ0kzeURkK2grc2l5VzA3VDd6bWttR3BjZTlmZ09VTXlsQm9GM0dWZlh0?= =?utf-8?B?OWI1TlErWlNWNzVLS3pic2tpZ3MzSXNpNUlzR1JvQk5TUndGYnZWWUsxMUh3?= =?utf-8?B?UlQ0NS95dlBnNC83NU1JSzdzMmc1THgwb3k4djkrM2czM3VNQW1XV2Y5ZnhU?= =?utf-8?B?ejV1K3h3R2tOQXY1dkd6OVR0VS83MndWbGMyZFEyNUVONVZlY2hPRzJpaG85?= =?utf-8?B?N3pxYmoyOFBzWXZjVm91TEFBZE0yU1psTmdybGpsZFZOVmFFdklSWGhLZzEv?= =?utf-8?B?a1VKYTVDbGtKdENtcU8vNDB5U01KYjFnc1pNVnFZN05sRW4vMVczRnZ5M2M2?= =?utf-8?B?L0hDRVNuYjgzZTBmamtha1dLWkhHNjJSVk41cVFzZFgvakJxcGdYNjVSLzI4?= =?utf-8?B?dkhsNVlkNnMrbnMvN0NNRlNzZXNWZngwRGgvYzBMZWVubi9CSGV2ZmNpRHpw?= =?utf-8?B?Y3lHcGczSEt0N214UjBYeW1QN2ZtZ0hDa25rQUVQQlpkUWl3Q3JTaE4zQ3cy?= =?utf-8?B?N1ZmNlBOaG9YbnpqbWh0SzlIYnk5KzhHVlZtaTNuaytMT3V2cWVQZWhMbStn?= =?utf-8?B?and2OEF6cjloZ3lZSytXeURQN2xwK0JnUVZEbjZMazByT0gxc2RQVnJ2UEVZ?= =?utf-8?B?MHFYME9MaDVuTWFpOFZCR0V4VjJFcTY4eGlLRThPZFJiVUNmamgvWkE4TXhv?= =?utf-8?B?Z1ZHK0I5b1lqSTNjdUJJTnhTeXE3ZjRtYUpFR0pqdzFnWFIrdktNY0FDTUVB?= =?utf-8?B?ckwxRkgxRkczUUEwVk5FaHFMSXRLRi9oQWdvTG8xWE1SeXFaaWpRcS9scE14?= =?utf-8?B?RXJaSWZacElqODhOT2FXYndEOXV3Y25FUHpjanpVOWRUQlhmRm1CSENxNXJP?= =?utf-8?B?UW0yUmxkdWVXZXBLNjZpbFMyck1iVW1kRjVaNmhVaW9JWFlnNEpET3hxQlUr?= =?utf-8?B?akF0Q0FoV1BDMkxoNzZOTFFXRkdtMTV0MHkxMGExNy9VQXJHR2ZmWm1zeVRN?= =?utf-8?B?d3ZseXNIV3Z3Z3RLZjluYmtCRGFHYUdHdHlHY2ppTG5oVmJIczBucnlRN01V?= =?utf-8?B?QlVjKzBmV2xMYjZERmhjSGJlL1l5bUhSU000ejV6ZlcyUWd3ZWxGR2ZlZHBs?= =?utf-8?B?UGxucmpaSndZa045MllPMWpMb0trWnFSMjdrYzAxbmNranljaG1mbUYveWhD?= =?utf-8?B?bkpYRmFLaWQ0cDhBS0tydUFVVEpTWU9nYVppRkpDV1g0YU1rYzg0RFlQTXFH?= =?utf-8?B?SEYxZElVUi8xTGlJU0lBYTRrYmN1ck9PbUxMMlNvYjBJaElZZUsvWEJYT2pq?= =?utf-8?B?NXRpWURCTXRGUHgxYXpybEh3TlJTOXFDUUZWSWlVRVNjYm84MUJ1QkxrL3F5?= =?utf-8?B?SXNLb2JBejNBUXZneFpjVDFvbzI3eHAwMmtDaktaUlZ0K2IxZ084OFNSSmhn?= =?utf-8?B?dURGcU5VVWtscXQ0blVjV05pdkxDcEZlYjVZZXg3L1ZCWmd2bzlhUU5lU0dF?= =?utf-8?B?RUpNSjFPd2tmY2JWak9kRWp6U1prdnFnMXpFbkRjblpHbXp2S2RrNmxld2lK?= =?utf-8?B?Z1oybFVybmdXeTJFOFNxSENZY0NvVDRhY1EyWVhxRE5MZlZvOEZoaFZla1BF?= =?utf-8?B?RkdtYUtITUNURUNkRlM1KzFJbnpPR1lIS2xPMmZqamc0SWovN3FNTEcvZS8r?= =?utf-8?B?cTcxeU5hQzA4YjVhVGlOOTEwV2s0ZFplNXludXJTR2VFSklJQ2ZOQ1hLOVV3?= =?utf-8?B?Ry9pOTduZEtRVFNaOGVRRzRxMDZEbTJONUJWZlpqQmpsUytQYU41ZTlUVWJP?= =?utf-8?B?Tkx2Ym1sVEZETkRrTHVKZGExd1M1Undncm5McitobjBFbE1yNE05YmEveHFD?= =?utf-8?B?L0FkbUhLZUdVWmY5ejIwVE40OG9iZXcyNTVIMnc1ek1wS1VYbEQxWEhUN2hp?= =?utf-8?B?Z0crYmJ0UGRUK0JQdytWR1paZHFaRHJWL1hBaWpyNDdsOUR2L2hxVEorRmZp?= =?utf-8?B?NDNWbkp4Q2NDRnRzeW5xakRRS1hkYlFiTTNod0YwNCtxK2dleHYydz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69d3dd6b-472b-448c-fcdb-08df2406c9c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:08.3069 (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: cchQ8EsEtmmiUfvlRKPeYZCWc6tb6FxgmbwCfPA0bOv+ez2oElBVs6uXnSzPOANO6/RZP6s+Tnplj9G6eWuibw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11456 X-purgate-ID: tlsNG-d25034/1791331572-036D6A5B-CA0981A6/0/0 X-purgate-type: clean X-purgate-size: 10552 VGhpcyBwYXRjaCBzZXJpZXMgcHJvdmlkZXMgZW11bGF0ZWQgU01NVXYzIHN1cHBvcnQgaW4gWGVu LCBlbmFibGluZyBTdGFnZS0xDQp0cmFuc2xhdGlvbiBmb3IgZ3Vlc3Qgb3BlcmF0aW5nIHN5c3Rl bXMuDQoNClN0YWdlLTEgdHJhbnNsYXRpb24gaXMgcmVxdWlyZWQgdG8gcHJvdmlkZSBpc29sYXRp b24gYmV0d2VlbiBkaWZmZXJlbnQNCmRldmljZXMgd2l0aGluIGFuIG9wZXJhdGluZyBzeXN0ZW0u IFhlbiBhbHJlYWR5IHN1cHBvcnRzIFN0YWdlLTIgdHJhbnNsYXRpb24sDQpidXQgdGhlcmUgaXMg bm8gc3VwcG9ydCBmb3IgU3RhZ2UtMSB0cmFuc2xhdGlvbi4gVGhlIGdvYWwgb2YgdGhpcyB3b3Jr IGlzIHRvDQpzdXBwb3J0IFN0YWdlLTEgdHJhbnNsYXRpb24gZm9yIFhlbiBndWVzdHMuDQoNClRo aXMgcGF0Y2ggc2VyaWVzIGlzIGEgY29udGludWF0aW9uIG9mIHRoZSB3b3JrIGJ5IFJhaHVsIFNp bmdoOg0KaHR0cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9jb3Zl ci9jb3Zlci4xNjY5ODg4NTIyLmdpdC5yYWh1bC5zaW5naEBhcm0uY29tLw0KDQpUaGUgb3JpZ2lu YWwgcGF0Y2ggc2VyaWVzIGhhcyBiZWVuIGFsaWduZWQgd2l0aCB0aGUgY3VycmVudCBYZW4gY29k ZQ0Kc3RydWN0dXJlLCB3aXRoIHRoZSBhZGRpdGlvbiBvZiBhIHRyYW5zbGF0aW9uIGxheWVyIHBy b3ZpZGluZyAxOk4NCnZJT01NVS10by1wSU9NTVUgbWFwcGluZy4gVGhpcyBhbGxvd3MgcGFzc3Ro cm91Z2ggb2YgZGV2aWNlcyBhdHRhY2hlZCB0bw0KZGlmZmVyZW50IHBoeXNpY2FsIElPTU1Vcy4N Cg0KV2UgY2Fubm90IHRydXN0IHRoZSBndWVzdCBPUyB0byBjb250cm9sIHRoZSBTTU1VdjMgaGFy ZHdhcmUgZGlyZWN0bHksIGFzIGENCmNvbXByb21pc2VkIGd1ZXN0IE9TIGNvdWxkIGNvcnJ1cHQg dGhlIFNNTVV2MyBjb25maWd1cmF0aW9uIGFuZCBtYWtlIHRoZQ0Kc3lzdGVtIHZ1bG5lcmFibGUu IFRoZSBndWVzdCBvd25zIHRoZSBTdGFnZS0xIHBhZ2UgdGFibGVzIGFuZCBTdGFnZS0xDQpjb25m aWd1cmF0aW9uIHN0cnVjdHVyZXMuIFhlbiBoYW5kbGVzIHRoZSByb290IGNvbmZpZ3VyYXRpb24g c3RydWN0dXJlIGZvcg0Kc2VjdXJpdHkgcmVhc29ucywgaW5jbHVkaW5nIHRoZSBTdGFnZS0yIGNv bmZpZ3VyYXRpb24uDQoNClhlbiBlbXVsYXRlcyB0aGUgU01NVXYzIGhhcmR3YXJlIGFuZCBleHBv c2VzIGEgdmlydHVhbCBTTU1VdjMgdG8gdGhlIGd1ZXN0Lg0KVGhlIGd1ZXN0IGNhbiB1c2UgdGhl IG5hdGl2ZSBTTU1VdjMgZHJpdmVyIHRvIGNvbmZpZ3VyZSBTdGFnZS0xIHRyYW5zbGF0aW9uLg0K V2hlbiB0aGUgZ3Vlc3QgY29uZmlndXJlcyB0aGUgU01NVXYzIGZvciBTdGFnZS0xIHRyYW5zbGF0 aW9uLCBYZW4gdHJhcHMgdGhlDQphY2Nlc3MgYW5kIGNvbmZpZ3VyZXMgdGhlIHBoeXNpY2FsIFNN TVUgYWNjb3JkaW5nbHkuDQoNClRoZSBmaW5hbCBwYXRjaCBpbiB0aGUgc2VyaWVzIHByb3ZpZGVz IGEgZGVzaWduIGRvY3VtZW50IGZvciB0aGUgZW11bGF0ZWQNCklPTU1VIChhcm0tdmlvbW11LnJz dCksIHdoaWNoIHdhcyBwcmV2aW91c2x5IGRpc2N1c3NlZCB3aXRoIHRoZSBtYWludGFpbmVycy4N CkRldGFpbHMgcmVnYXJkaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiwgZnV0dXJlIHdvcmssIGFuZCBz ZWN1cml0eSByaXNrcyBhcmUNCm91dGxpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNClRoZSBwYXRj aCBzZXJpZXMgaGFzIGJlZW4gc3Vic3RhbnRpYWxseSByZXdvcmtlZCBpbiB0aGlzIGl0ZXJhdGlv biwgYWRkcmVzc2luZw0KcmV2aWV3IGNvbW1lbnRzIGZyb20gdGhlIGVhcmxpZXIgdmVyc2lvbiBh bmQgcmVzb2x2aW5nIGxpbWl0YXRpb25zIGFuZCBidWdzDQpkaXNjb3ZlcmVkIGluIHRoZSBtZWFu dGltZS4gVGhpcyB2ZXJzaW9uIGluY2x1ZGVzIHNpZ25pZmljYW50IGNoYW5nZXMgdG8gdGhlDQpp bXBsZW1lbnRhdGlvbiBhbmQgZGVzaWduIChzZWUgQ2hhbmdlcyBpbiB2NCkuDQoNCi0tLQ0KQ2hh bmdlcyBpbiB2MjoNCiAtIFVwZGF0ZWQgZGVzaWduIGFuZCBpbXBsZW1lbnRhdGlvbiB3aXRoIHZJ T01NVS0+cElPTU1VIG1hcHBpbmcgbGF5ZXINCiAtIEFkZHJlc3NlZCBzZWN1cml0eSByaXNrcyBp biB0aGUgZGVzaWduLCBwcm92aWRlZCBpbml0aWFsIHBlcmZvcm1hbmNlDQogICBtZWFzdXJlbWVu dHMNCiAtIEFkZHJlc3NlZCBjb21tZW50cyBmcm9tIHByZXZpb3VzIHZlcnNpb24NCiAtIFRlc3Rl ZCBvbiBSZW5lc2FzIFItQ2FyIHBsYXRmb3JtLCBpbml0aWFsIHBlcmZvcm1hbmNlIG1lYXN1cmVt ZW50cyBmb3INCiAgIHN0YWdlLTEgdnMgc3RhZ2UtMS1sZXNzIGd1ZXN0cw0KLS0tDQoNCi0tLQ0K Q2hhbmdlcyBpbiB2MzoNCiAtIEJ1bXAgZG9tY3RsIHZlcnNpb24sIGFkZGVkIGV4cGxpY2l0IHBh ZGRpbmcgZm9yIHRoZSBuZXcgZG9tY3RsIHN0cnVjdHVyZXMNCiAtIFJlbW92ZSB1bm5lY2Vzc2Fy eSBjaGFuZ2VzIGFjY29yZGluZyB0byByZXZpZXcgY29tbWVudHMNCiAtIEFkZCAiQVJNIiBwcmVm aXggZm9yIHZJT01NVSBLY29uZmlnIG9wdGlvbnMsIHNpbmNlIG9ubHkgQVJNIGFyY2hpdGVjdHVy ZSBpcw0KICAgc3VwcG9ydGVkIGF0IHRoaXMgcG9pbnQgDQogLSBSZS1nZW5lcmF0ZSBnbyBjb2Rl DQogLSBBZGQgbWlzc2luZyBjb21taXQgc2lnbi1vZmYgdGFncw0KLS0tDQoNCi0tLQ0KQ2hhbmdl cyBpbiB2NDoNCiAtIEFkZGVkIGRldGFpbHMgb24gY3VycmVudCBzdXBwb3J0LCB3aXRoIFRPRE9z IG1hcmtpbmcgdW5zdXBwb3J0ZWQgZmVhdHVyZXMNCiAgIGFuZCBsaW1pdGF0aW9ucw0KIC0gVXBk YXRlZCBlbXVsYXRlZCBJT01NVSBmZWF0dXJlIGhhbmRsaW5nIHRvIGFkdmVydGlzZSBmZWF0dXJl cyBzdXBwb3J0ZWQgYnkNCiAgIHRoZSB1bmRlcmx5aW5nIFNNTVUsIGV4Y2VwdCBmb3IgZmVhdHVy ZXMgZXhwbGljaXRseSBkaXNhYmxlZCBpbiB0aGUNCiAgIGVtdWxhdGlvbiBsYXllcg0KIC0gUmV3 b3JrZWQgZXZlbnQgcXVldWUgYW5kIEdFUlJPUiBzdXBwb3J0LCBpbmNsdWRpbmcgR0VSUk9SDQog ICBhc3NlcnQvYWNrbm93bGVkZ2UgbG9naWMsIElSUSBpbmplY3Rpb24sIGFuZCBldmVudCBxdWV1 ZSByZWdpc3RlciBhY2Nlc3MNCiAgIG9uIHBhZ2UgMQ0KIC0gRW5hYmxlZCBTdGFnZS0xLW9ubHkg c3VwcG9ydCB3aGVuIHRoZSB1bmRlcmx5aW5nIGhhcmR3YXJlIGRvZXMgbm90IHN1cHBvcnQNCiAg IFN0YWdlLTINCiAtIFJlbW92ZWQgdGhlIFhlbiBjb21tYW5kLWxpbmUgYm9vdCBvcHRpb24gKCJ2 aW9tbXUiKSBmb3IgZW5hYmxpbmcgdGhlDQogICB2SU9NTVUsIGFzIGl0IHdhcyBjb25zaWRlcmVk IHJlZHVuZGFudC4gVGhlIHZJT01NVSBpcyBub3cgZW5hYmxlZCB0aHJvdWdoDQogICBLY29uZmln IHdoZW4gdGhlIHVuZGVybHlpbmcgU01NVSBoYXJkd2FyZSBpcyBkaXNjb3ZlcmVkIGF0IHJ1bnRp bWUNCiAtIEFkZGVkIGxvY2tpbmcgYW5kIGFjY2VzcyBjaGVja3MgZm9yIHZJT01NVSByZWdpc3Rl ciByZWFkcyBhbmQgd3JpdGVzDQogLSBQb3J0ZWQgZXJyYXRhIHdvcmthcm91bmRzIGZvciBNTVUt NjAwL01NVS03MDAgcHJvZHVjdHMgZnJvbSBMaW51eCB0bw0KICAgZGlzYWJsZSBuZXN0aW5nDQog LSBVcGRhdGVkIHRoZSB2U0lEIHRyYW5zbGF0aW9uIGxheWVyIHRvIG1hcCB2U0lEcyB0byAocFNN TVUsIHBTSUQpIHBhaXJzLA0KICAgcmVzb2x2aW5nIHRoZSBkdXBsaWNhdGVkIHBTSUQgaXNzdWUN CiAtIFVwZGF0ZWQgU3RhZ2UtMiBjb25maWd1cmF0aW9uIHRvIHNoYXJlIHRoZSBWTUlEIGJldHdl ZW4gZGV2aWNlcyBiZWxvbmdpbmcNCiAgIHRvIHRoZSBzYW1lIGRvbWFpbiBhbmQgcFNNTVUNCiAt IEFkZGVkIGJ1ZyBmaXhlcyBhbmQgY29kZSBmb3JtYXR0aW5nIGNoYW5nZXMNCiAtIFVwZGF0ZWQg dGhlIGRlc2lnbiBkb2N1bWVudCAoYXJtLXZpb21tdS5yc3QpIHdpdGggZGV0YWlscyBvbiBjdXJy ZW50DQogICBzdXBwb3J0LCBsaW1pdGF0aW9ucywgYW5kIGZ1dHVyZSB3b3JrYg0KDQpUbyByZWR1 Y2UgdGhlIG51bWJlciBvZiBwYXRjaGVzLCBQQ0kgdXBkYXRlcyBmb3IgdGhlIGVtdWxhdGVkIElP TU1VIGFyZQ0KZXhjbHVkZWQgZnJvbSB0aGlzIHNlcmllcy4gUENJIHN1cHBvcnQgYW5kIGxvbmct cnVubmluZyBjb21tYW5kIHF1ZXVlDQpoYW5kbGluZyB3aWxsIGJlIHNlbnQgYXMgc2VwYXJhdGUg cGF0Y2hlcy4NCg0KU2luY2UgdGhpcyBpcyBhIHNpZ25pZmljYW50IHJld29yayBvZiB0aGUgcGF0 Y2ggc2VyaWVzLCBSZXZpZXdlZC1ieSB0YWdzDQpmcm9tIHByZXZpb3VzIGl0ZXJhdGlvbiBhcmUg aW5jbHVkZWQgb25seSBmb3IgcGF0Y2hlcyB0aGF0IGFyZSB1bmNoYW5nZWQuDQotLS0NCg0KSmVh bi1QaGlsaXBwZSBCcnVja2VyICgxKToNCiAgeGVuL2FybTogc21tdXYzOiBNYWludGFpbiBhIFNJ RC0+ZGV2aWNlIHN0cnVjdHVyZQ0KDQpNaWxhbiBEam9raWMgKDQpOg0KICB4ZW4vYXJtOiBzbW11 djM6IEV4dGVuZCBIVyBmZWF0dXJlcyBkZXRlY3Rpb24gYW5kIGFwcGx5IGVycmF0YQ0KICB4ZW4v YXJtOiB2SU9NTVUgdlNJRC0+cFNJRCBtYXBwaW5nIGxheWVyDQogIGxpYnhsL2FybTogSW50cm9k dWNlIGRvbWN0bCBjb21tYW5kIGZvciBJT01NVSB2U0lEIG1hcHBpbmcNCiAgZG9jL2FybTogdklP TU1VIGRlc2lnbiBkb2N1bWVudA0KDQpSYWh1bCBTaW5naCAoMTcpOg0KICB4ZW4vYXJtOiBzbW11 djM6IEFkZCBzdXBwb3J0IGZvciBzdGFnZS0xIGFuZCBuZXN0ZWQgc3RhZ2UgdHJhbnNsYXRpb24N CiAgeGVuL2FybTogc21tdXYzOiBBbGxvYyBpb19kb21haW4gZm9yIGVhY2ggZGV2aWNlDQogIHhl bi9hcm06IHZJT01NVTogYWRkIGdlbmVyaWMgdklPTU1VIGZyYW1ld29yaw0KICB4ZW4vYXJtOiB2 c21tdXYzOiBBZGQgZHVtbXkgc3VwcG9ydCBmb3IgdmlydHVhbCBTTU1VdjMgZm9yIGd1ZXN0cw0K ICB0b29sczogQWRkIFhFTl9ET01DVExfQ09ORklHX1ZJT01NVV8qIGFuZCB2aW9tbXUgY29uZmln IHBhcmFtDQogIHhlbi9hcm06IHZzbW11djM6IEFkZCBzdXBwb3J0IGZvciByZWdpc3RlcnMgZW11 bGF0aW9uDQogIHhlbi9hcm06IHZzbW11djM6IEFkZCBzdXBwb3J0IGZvciBjbWRxdWV1ZSBoYW5k bGluZw0KICB4ZW4vYXJtOiB2c21tdXYzOiBBZGQgc3VwcG9ydCBmb3IgY29tbWFuZCBDTURfQ0ZH SV9TVEUNCiAgeGVuL2FybTogdnNtbXV2MzogQXR0YWNoIFN0YWdlLTEgY29uZmlndXJhdGlvbiB0 byBTTU1VdjMgaGFyZHdhcmUNCiAgeGVuL2FybTogdnNtbXV2MzogQWRkIHN1cHBvcnQgZm9yIGV2 ZW50IHF1ZXVlIGFuZCBnbG9iYWwgZXJyb3INCiAgeGVuL2FybTogdnNtbXV2MzogSU9NTVUgZGV2 aWNlIHRyZWUgbm9kZSBmb3IgZG9tMA0KICB4ZW4vYXJtOiB2c21tdXYzOiBFbXVsYXRlZCBTTU1V djMgZGV2aWNlIHRyZWUgbm9kZSBmb3IgZG9tMGxlc3MNCiAgYXJtL2xpYnhsOiB2c21tdXYzOiBF bXVsYXRlZCBTTU1VdjMgZGV2aWNlIHRyZWUgbm9kZSBpbiBsaWJ4bA0KICB4ZW4vYXJtOiB2c21t dXYzOiBJbnNlcnQgdklSUSBwcm9wZXJ0aWVzIGludG8gdklPTU1VIGRldmljZSB0cmVlIG5vZGUN CiAgeGVuL2FybTogdnNtbXV2MzogQWRkIHN1cHBvcnQgdG8gc2VuZCBzdGFnZS0xIGV2ZW50IHRv IGd1ZXN0DQogIGxpYnhsL2FybTogdklPTU1VOiBNb2RpZnkgdGhlIHBhcnRpYWwgZGV2aWNlIHRy ZWUgZm9yIGlvbW11cw0KICB4ZW4vYXJtOiB2SU9NTVU6IE1vZGlmeSB0aGUgcGFydGlhbCBkZXZp Y2UgdHJlZSBmb3IgZG9tMGxlc3MNCg0KIGRvY3MvZGVzaWducy9hcm0tdmlvbW11LnJzdCAgICAg ICAgICAgICB8ICA1MDIgKysrKysrKysNCiBkb2NzL21hbi94bC5jZmcuNS5wb2QuaW4gICAgICAg ICAgICAgICAgfCAgIDIyICsNCiB0b29scy9nb2xhbmcveGVubGlnaHQvaGVscGVycy5nZW4uZ28g ICAgfCAgICAyICsNCiB0b29scy9nb2xhbmcveGVubGlnaHQvdHlwZXMuZ2VuLmdvICAgICAgfCAg ICA3ICsNCiB0b29scy9pbmNsdWRlL2xpYnhsLmggICAgICAgICAgICAgICAgICAgfCAgICA1ICsN CiB0b29scy9pbmNsdWRlL3hlbmN0cmwuaCAgICAgICAgICAgICAgICAgfCAgIDEzICsNCiB0b29s cy9saWJzL2N0cmwveGNfZG9tYWluLmMgICAgICAgICAgICAgfCAgIDI1ICsNCiB0b29scy9saWJz L2xpZ2h0L2xpYnhsX2FybS5jICAgICAgICAgICAgfCAgMjEwICsrKy0NCiB0b29scy9saWJzL2xp Z2h0L2xpYnhsX3R5cGVzLmlkbCAgICAgICAgfCAgICA2ICsNCiB0b29scy94bC94bF9wYXJzZS5j ICAgICAgICAgICAgICAgICAgICAgfCAgICA5ICsNCiB4ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVp bGQuYyAgICAgICAgICAgfCAgIDcyICsrDQogeGVuL2FyY2gvYXJtL2RvbWFpbi5jICAgICAgICAg ICAgICAgICAgIHwgICAzNSArLQ0KIHhlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYyAgICAgICAg ICAgICB8ICAxMDQgKy0NCiB4ZW4vYXJjaC9hcm0vZG9tY3RsLmMgICAgICAgICAgICAgICAgICAg fCAgIDM4ICsNCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZG9tYWluLmggICAgICAgfCAgICA1 ICsNCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaW9tbXUuaCAgICAgICAgfCAgICA3ICsNCiB4 ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmlvbW11LmggICAgICAgfCAgMTIzICsrDQogeGVuL2Nv bW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1idWlsZC5jIHwgICA2NSArLQ0KIHhlbi9kcml2ZXJz L3Bhc3N0aHJvdWdoL0tjb25maWcgICAgICAgICB8ICAgMTMgKw0KIHhlbi9kcml2ZXJzL3Bhc3N0 aHJvdWdoL2FybS9NYWtlZmlsZSAgICB8ICAgIDIgKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo L2FybS9zbW11LXYzLmMgICB8ICA2MTMgKysrKysrKysrLQ0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJv dWdoL2FybS9zbW11LXYzLmggICB8ICAgNzUgKy0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h cm0vdmlvbW11LmMgICAgfCAgMTQxICsrKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92 c21tdS12My5jICB8IDEzOTUgKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vZHJpdmVycy9w YXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuaCAgfCAgIDI4ICsNCiB4ZW4vaW5jbHVkZS9wdWJsaWMv YXJjaC1hcm0uaCAgICAgICAgICAgfCAgIDEzICstDQogeGVuL2luY2x1ZGUvcHVibGljL2Rldmlj ZV90cmVlX2RlZnMuaCAgIHwgICAgMSArDQogeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oICAg ICAgICAgICAgIHwgICAyMiArDQogeGVuL2luY2x1ZGUveGVuL2lvbW11LmggICAgICAgICAgICAg ICAgIHwgICAxMCArDQogeGVuL3hzbS9mbGFzay9ob29rcy5jICAgICAgICAgICAgICAgICAgIHwg ICAgNCArDQogeGVuL3hzbS9mbGFzay9wb2xpY3kvYWNjZXNzX3ZlY3RvcnMgICAgIHwgICAgMiAr DQogMzEgZmlsZXMgY2hhbmdlZCwgMzUwMyBpbnNlcnRpb25zKCspLCA2NiBkZWxldGlvbnMoLSkN CiBjcmVhdGUgbW9kZSAxMDA2NDQgZG9jcy9kZXNpZ25zL2FybS12aW9tbXUucnN0DQogY3JlYXRl IG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92aW9tbXUuaA0KIGNyZWF0ZSBt b2RlIDEwMDY0NCB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlvbW11LmMNCiBjcmVhdGUg bW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMNCiBjcmVh dGUgbW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmgNCg0K LS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441808.1659314 (Exim 4.92) (envelope-from ) id 1xEFB8-0007PL-IQ; Wed, 07 Oct 2026 00:06:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441808.1659314; Wed, 07 Oct 2026 00: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 1xEFB8-0007PA-FN; Wed, 07 Oct 2026 00:06:38 +0000 Received: by outflank-mailman (input) for mailman id 1441808; Wed, 07 Oct 2026 00:06:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFB7-0007O7-DR for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFB6-007O6m-B9 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:36 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58caf-bab6-0a2a0a5309dd-0a2a4507e89e-30 for ; Wed, 07 Oct 2026 02:06:36 +0200 Received: from [40.107.159.92] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d0b-b4ea-0a2a45070019-286b9f5c8e41-3 for ; Wed, 07 Oct 2026 02:06:36 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:33 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=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=v1SkJaXgsNSkZoF6MlXqFahMph2gKX0Eanu/UvMzkNV2Xo4J2HUgvJC/jjYydmk8+TJp9/kht1se+kBjHUsGmHxFBKiQh7yocvs+Ue0BCY4zGhfX5u9eqvv3szWG1o7ajwcSe6ITMNLwdRpHY/NZZXEV3rPh8NKiUYEGEpgMbmbcmAhWFrc+Gv+9oxbiWcFGOlxBuRl39mbczD8+32S+4Is2wGfHInIeP2pAAx2fJaGbSD3SC1Hxq1lt4SGDk8vi6XoAxMaQTgFnWINc3E0e11BDe/WT/700rnWCZkGfjfp1yLSu5Dyb+O4d7auoRNw1kPoBKF0WWukAW3wL0a51Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/TCNmBS629Tk2CQr0r+7dTXmQRCqwPC0tTbRHUBG14U=; b=uKPMrbTaUIy1vTYk6dcGIA8WN+68I1ePGuRm0R6QHRDFo9Rw1FaJ1Zzvw3Tj8825aHsJf0J7yCD1nOQY+LStNGfLVwiqykFAV7qm9itFPPLKo8ufNVeZD9dW5srJP9foPI1vHCLG2BLI27OWTd3IHTIs9wtDKizXstMbRDPSxX8iKUA0ssgv/135BNffgLV6aXhuO7KGc+sihvmlj2fSBj1PJkvN0PhYVlX73JxFQi5ymyh71Exm8LD4t4LX5EYLqDX946cMhq2eKGmYFTkOz7Bqbi2fQDLhhcZzFA0hevtk9Eqqw9OL9YmFzXu43XIItsZq/bnoKVh7XVtDlbMy4g== 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=/TCNmBS629Tk2CQr0r+7dTXmQRCqwPC0tTbRHUBG14U=; b=vJ6qr5NqTtobqUd9Z3+jXbxU1mWWdL55QElzBPJ1lzf74pMGfqNpy7/KyVULtwlUin1GtZbnNfEPFjOr2TVmqlCvCbUiO6q9sr0l8AFLHVXPxCebOn39nf1uph7Z+kxKJzPHYRRa9vaBA+KFcsi7O3RlmQv+1rk/CW1vBnkoiSUQdA6WTcRZt32CJiSJ2LcSaQ6kMQ6Yq1JzjUz8cs9jDuGSgnAMsICtQ/F/KU2zv+yD+p+EzJEk/AADoQ41Go9XI6Irtt84LMAzOj8TEsb0KzgIwX68zcXfEbYfuz989IO3kUHzw+eEpsJxJ+okUMbIgVxOAwusWwJZa/Xajd9Mqg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Jean-Philippe Brucker , Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Joerg Roedel , Nicolin Chen , Will Deacon , Milan Djokic Subject: [PATCH v4 01/22] xen/arm: smmuv3: Maintain a SID->device structure Thread-Topic: [PATCH v4 01/22] xen/arm: smmuv3: Maintain a SID->device structure Thread-Index: AQHdVe+2J162OkX1sU2elc/6IbZpDQ== Date: Wed, 7 Oct 2026 00:06:33 +0000 Message-ID: <1e7cd468535ab932244f2a5578743b07d046cf02.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: b9abf91d-d0f5-410d-c5d8-08df2406d8e3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: HUnbLaTD12gJ+PKo37dRygkCAWKi/Y9g3c8cKBICM7ufLE6B0ZvjFCVx1vXC9FMHskc4MEhQRr3IwMO4k9ymVR/xK2NcjCU2utvFK2+KdJrrgYL9RoBRrsfljnsoh6zJ/RJdcLubLXzmaqFFf7z8tRcnf4HPTS2l48GKEZIJPPeVeK3JnwKhIy/R9xhwwCRQkdGqj/JBP/kB4gy8SHHI354ck3CpAfhE6RMGdsDjc2z2WA2lEbdO3q6ufYubYdtHUiR1k8b1saIQ+k1/G1qpmclVI7bynSBXz7fZsdSSuwhGUCWtgKY/9VCsxrXRFzpbXQqlIq6S4gIRojPsORwe58LVvD6bp+ErgbraRJlIpwt9UTHzvmQ/tMQ8DIEEUyG5/tLRngIxnvbIZUMMDMNhdUdRZPzebPLakpfzrAEM5hcvzj7mL1PiucnpvSxSEJwtMgxSFyehoSq1i4vrSIaiZIr8K5HboKNouLshg8I9frbsaEChr1tFmE4HnZ0+Q7vh8OM6IOhR+6KCX8Bm5c6/9Fmuzppcsh9AfGDF3WHFPjvULz2SdnIChPC1DlShdqSrH/N8mBbtXEUj5CZ4gDlVAUDiW2zM9Ebs25wCmgbYo/kKZZIggxd+TMlz9e2wdkDWlSSjGJX+ESVoB1BxXT4ebqrrqGAVAfM6XFGXqTb9VoX3AoEvN23oeGfz2aZgOBm2CwHogL1KXc1zyJRu2k5BbzX0nm73zWWDykcW5m4l9sI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?N2pDcGZtMmMrT1BUT09NRnZic096RUJ3SDQvaEo5OW5qOVo3cVpZeEVCTmRD?= =?utf-8?B?MzdQRXRMMFRHMWo2eVkwdnZpdHUzbFF0VzNFM1dwMWplSkc2RFZyaFNsN3I2?= =?utf-8?B?Z0I4MUYrME5OQWlXMllWVlNxN1pGTDF0UGxjemEwcG1rdGVyZnpSQjVGTXZP?= =?utf-8?B?ejRBTnJvbXEyKzlpZFVvdi9TRmlyWjA5Q3hKWFNxTzNXYjZSVHZ5U1hUbXBK?= =?utf-8?B?TENvQmVqdDRRUGljdkVlZHp3WGlLdmFzQmt0Ny9lQTM1ZVlrQTl4L2dhamNu?= =?utf-8?B?TmcwMGZLdndoWTJjeGpXZWk4MzRmTUN3WU9CYlZ0Y28xOVZIUVpHSWMyb0JB?= =?utf-8?B?YXVjS1hFODhVNzFHc1hNYnZpOEhybkxkT3RMb09COHh3ZWo2UUoxZG1pWHZI?= =?utf-8?B?d3lxQXRkVGtmTjExQ2s3bXdxejRkdDZrdDZ1RlRYSTBoM3dROTVnaENYckcv?= =?utf-8?B?UEFjYUpUTlpsMUdJd3I2L2NwL2hrUmtkNTdIS1NiMDE2RjRUQkZaZXFYc2E0?= =?utf-8?B?S1pqYTVlSkRzUVZqa1lvM3Uvd205VzdhdFAyTEFIQ21QZUdZRzZzV3FyY3Rp?= =?utf-8?B?QkhOWnl2eFJtdlM2eHk4VzNuTTNyQm1BUE9sR2tiN3p1NGF2RnN2UEhLSmdU?= =?utf-8?B?dTV1TE5LNTVBaS9jLzkxRWcyeXNCTlFLNi9tbWU1eSt3ZzA3Y2VxTjRSUzJE?= =?utf-8?B?b2ZuMmlQZGNid25SL0VpMUtONm5DNCt4aGFiYTJidkVyTnZaNXNaSktQWkRm?= =?utf-8?B?RDZyTDdBN3lkWFd5Q2lYVFpLaFdIa2ZyV3dpbHhkTGNwck5uMVVBaWJaZWpn?= =?utf-8?B?Y2lBQkt0bms1cEVFM0Z3NmdwYnE2aVdYMm01U09aeW9HWWIvVVJXUktIbUVY?= =?utf-8?B?c01MbzgxYXd3TDBEN0dSeUpHVjhHT085L2FlUCtNMTEzU1FGSHU4bHo0OWg4?= =?utf-8?B?T2xrRkFUdzlkV1ZaQmJ1M0QrelpXK3VmTkxhK2E4SzA2QUZRVStNOUlydHhE?= =?utf-8?B?aDZSdGpjZlI2cmJkalBEa3lxZnR6Y0xJbEhmWS9vQVl3VGtFYStkTU0waThP?= =?utf-8?B?YjMzNnAycUxNRDlGT2xJZ3cvN1pxZjFsdE93Q0oxT2V6RnpLb2VFSWtVVjhP?= =?utf-8?B?a3lhdVdQeEZYZElSeU9pdm42cmNBMzhwc1JUYzRkd2ZFNkNSV2pZbDVjV3VQ?= =?utf-8?B?My9sWElVVWFDR3IxNGhJRWpBbThJUTBBcXRPRXBaak5DeGtTc2IzMHZLWkMy?= =?utf-8?B?c0lHd3dodDNpVHZBUEEzeDY5QmxnNGNJS1d3U1pWV25xa3cvMzlocWl4M05s?= =?utf-8?B?Ykk5eEJHR09lamp0QmZXc1VIWkpSQ1Q4eUVoaWVZVklFRDh2SXVSVlh5RWt4?= =?utf-8?B?WGtkczNNNkdxMDlJekNHbW1Sd3ZxaENiTmxrK0RkcE4wdUw2VHU3UkpmeHYr?= =?utf-8?B?YzVYeGhwYkk2d1ZpOFdFT1haUkNkTkFLd0xneGJueGNzSm5DVnZjVlQ0Wnpy?= =?utf-8?B?cTMzalphZ3lkVk9FY2ZwWUl1UEN1cDZkM09na29ocTY3UE5aUTV6VTIyYlJQ?= =?utf-8?B?cFpsRHNJcm5GbENiSVF3ZnV3dmwvL0hoeHNTcjFpaUpucTYyY2R4OENBbTBh?= =?utf-8?B?cnYwY1FYN1BDUXJLUGRqaW5JaUM3cVNHbER3bXVtTlAyeDZHdTkxR3BtVnpL?= =?utf-8?B?SzZLQVl4a3U2WUNmQlVOWDJmT1hpWE9XZURrT3llaCtCMjRiVGVzV2tpK1dz?= =?utf-8?B?ekxBZ2NNYXpBbVYrT2VGcVFqN3VVR1VWQzMvOXZGQkEzZUdiN3R3Y0xIckJn?= =?utf-8?B?aGJuTlNqbzhrMEFvWFZrOFMxRjBNRVlJUVZzclRxVEQ2YnV4U0pldHY5TVJP?= =?utf-8?B?OFZORlNiM2IyVVFSRHpqWTdiUHk4dVZtQkpCMlFVYmptejduaDV1Q0x3cEhX?= =?utf-8?B?YUl5eWpaaXd6UFkxcHJubDJzbU1DM2lBNEFTS2F0M3l3TVNxcW9xa3liZlFT?= =?utf-8?B?OGd2QktCM0U1V2FjQWRlUlE0aDdxbno1MlNnMDNHemk3NUdVYjMxY2VZcjUy?= =?utf-8?B?d1paTFpGK0RJWnR1REhNcHUyaU54WnV5emEycnBvRm0vcmpIVFNJWEgxbDBx?= =?utf-8?B?dms4M25MZ2JDbGFlYyt3MmZlU3ZPSUQvRWZtVXJsdGd6bU5jSUFtNk8zVEho?= =?utf-8?B?ZjhOeCtHc0lHY21lOEVxZWFQRkJzUUFBNVg4QzJYSnl0aG5WTlpld1k4NlBO?= =?utf-8?B?L081VmtORmtKV3dYOXZkVVJCS016K0ZTK0U3cmlYN3hCdjV6aE02ZzhYKzIw?= =?utf-8?B?aWgzZHJzdG5vb1VyUmdiWVBDZEo2TkY2L29RQm5nbndoTDVaL2gwQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9abf91d-d0f5-410d-c5d8-08df2406d8e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:33.7057 (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: 0Fz0tXfNop+jAL99ePue7tGgf4QnKfPW+HFL/6MHBiaPJp2kmfsTfhYI6+3vA8UNBTeM6VGQLTF5cU0pm2bvgQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-ef75cf/1791331596-A6EDEAE4-F3694BEC/0/0 X-purgate-type: clean X-purgate-size: 12866 RnJvbTogSmVhbi1QaGlsaXBwZSBCcnVja2VyIDxqZWFuLXBoaWxpcHBlQGxpbmFyby5vcmc+DQoN CkJhY2twb3J0IExpbnV4IGNvbW1pdHMgY2RmMzE1ZjkwN2Q0IGFuZCBiMDBkMjQ5OTdhMTEsIGFk YXB0ZWQgdG8gdGhlIFhlbg0KU01NVXYzIGltcGxlbWVudGF0aW9uLg0KDQpXaGVuIGhhbmRsaW5n IGZhdWx0cyBmcm9tIHRoZSBldmVudCBvciBQUkkgcXVldWUsIHdlIG5lZWQgdG8gZmluZCB0aGUN CnN0cnVjdCBkZXZpY2UgYXNzb2NpYXRlZCB3aXRoIGEgU0lELiBBZGQgYW4gcmJfdHJlZSB0byBr ZWVwIHRyYWNrIG9mDQpTSURzLg0KDQpBbHNvIGhhbmRsZSBkdXBsaWNhdGUgU0lEcywgYXMgYnJp ZGdlZCBQQ0kgZGV2aWNlcyBtYXkgaGF2ZSBtdWx0aXBsZQ0Kc3RyZWFtcyB3aXRoIHRoZSBzYW1l IFNJRC4NCg0KVGhlIGJhY2twb3J0IGlzIGFkYXB0ZWQgdG8gWGVuJ3MgU01NVXYzIGRyaXZlciBz dHJ1Y3R1cmUgYW5kIHR5cGVzLg0KRml4ZXMgYXJlIGFsc28gaW5jbHVkZWQgaW4gdGhlIG1hc3Rl ciBpbnNlcnRpb24gcm9sbGJhY2sNCmFuZCB0ZWFyZG93biBwYXRocyB0byBjb3JyZWN0bHkgaGFu ZGxlIHBhcnRpYWxseQ0KaW5zZXJ0ZWQgc3RyZWFtIGVudHJpZXMgYW5kIGF2b2lkIGxlYXZpbmcg c3RhbGUgcmJfdHJlZSBub2Rlcy4NCg0KTGludXggY29tbWl0czoNCg0KICBjZGYzMTVmOTA3ZDQg KCJpb21tdS9hcm0tc21tdS12MzogTWFpbnRhaW4gYSBTSUQtPmRldmljZSBzdHJ1Y3R1cmUiKQ0K ICBiMDBkMjQ5OTdhMTEgKCJpb21tdS9hcm0tc21tdS12MzogRml4IGlvbW11X2RldmljZV9wcm9i ZSBidWcgZHVlIHRvIGR1cGxpY2F0ZWQgc3RyZWFtIGlkcyIpDQoNCkxpbms6IGh0dHBzOi8vbG9y ZS5rZXJuZWwub3JnL3IvMjAyMTA0MDExNTQ3MTguMzA3NTE5LTgtamVhbi1waGlsaXBwZUBsaW5h cm8ub3JnDQpMaW5rOiBodHRwczovL2xvcmUua2VybmVsLm9yZy9yLzIwMjUwNDE1MTg1NjIwLjUw NDI5OS0xLW5pY29saW5jQG52aWRpYS5jb20NCk9yaWdpbjogZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcv cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdCBjZGYzMTVmOTA3ZDQN Ck9yaWdpbjogZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3Rv cnZhbGRzL2xpbnV4LmdpdCBiMDBkMjQ5OTdhMTENCg0KU2lnbmVkLW9mZi1ieTogSmVhbi1QaGls aXBwZSBCcnVja2VyIDxqZWFuLXBoaWxpcHBlQGxpbmFyby5vcmc+DQpTaWduZWQtb2ZmLWJ5OiBK b2VyZyBSb2VkZWwgPGpyb2VkZWxAc3VzZS5kZT4NClNpZ25lZC1vZmYtYnk6IE5pY29saW4gQ2hl biA8bmljb2xpbmNAbnZpZGlhLmNvbT4NClNpZ25lZC1vZmYtYnk6IFdpbGwgRGVhY29uIDx3aWxs QGtlcm5lbC5vcmc+DQpTaWduZWQtb2ZmLWJ5OiBSYWh1bCBTaW5naCA8cmFodWwuc2luZ2hAYXJt LmNvbT4NClNpZ25lZC1vZmYtYnk6IE1pbGFuIERqb2tpYyA8bWlsYW5fZGpva2ljQGVwYW0uY29t Pg0KLS0tDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYyB8IDE3NiArKysr KysrKysrKysrKysrKysrKysrLS0tLQ0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11 LXYzLmggfCAgMTMgKy0NCiAyIGZpbGVzIGNoYW5nZWQsIDE2MyBpbnNlcnRpb25zKCspLCAyNiBk ZWxldGlvbnMoLSkNCg0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9z bW11LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jDQppbmRleCBi ZjE1MzIyN2RiLi43MTYyNDczZDYyIDEwMDY0NA0KLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91 Z2gvYXJtL3NtbXUtdjMuYw0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUt djMuYw0KQEAgLTgwOSw2ICs4MDksMjcgQEAgc3RhdGljIGludCBhcm1fc21tdV9pbml0X2wyX3N0 cnRhYihzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11LCB1MzIgc2lkKQ0KIAlyZXR1cm4gMDsN CiB9DQogDQorX19tYXliZV91bnVzZWQNCitzdGF0aWMgc3RydWN0IGFybV9zbW11X21hc3RlciAq DQorYXJtX3NtbXVfZmluZF9tYXN0ZXIoc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSwgdTMy IHNpZCkNCit7DQorCXN0cnVjdCByYl9ub2RlICpub2RlOw0KKwlzdHJ1Y3QgYXJtX3NtbXVfc3Ry ZWFtICpzdHJlYW07DQorDQorCW5vZGUgPSBzbW11LT5zdHJlYW1zLnJiX25vZGU7DQorCXdoaWxl IChub2RlKSB7DQorCQlzdHJlYW0gPSByYl9lbnRyeShub2RlLCBzdHJ1Y3QgYXJtX3NtbXVfc3Ry ZWFtLCBub2RlKTsNCisJCWlmIChzdHJlYW0tPmlkIDwgc2lkKQ0KKwkJCW5vZGUgPSBub2RlLT5y Yl9yaWdodDsNCisJCWVsc2UgaWYgKHN0cmVhbS0+aWQgPiBzaWQpDQorCQkJbm9kZSA9IG5vZGUt PnJiX2xlZnQ7DQorCQllbHNlDQorCQkJcmV0dXJuIHN0cmVhbS0+bWFzdGVyOw0KKwl9DQorDQor CXJldHVybiBOVUxMOw0KK30NCisNCiAvKiBJUlEgYW5kIGV2ZW50IGhhbmRsZXJzICovDQogc3Rh dGljIHZvaWQgYXJtX3NtbXVfZXZ0cV90YXNrbGV0KHZvaWQgKmRldikNCiB7DQpAQCAtMTA0Miw4 ICsxMDYzLDggQEAgc3RhdGljIGludCBhcm1fc21tdV9hdGNfaW52X21hc3RlcihzdHJ1Y3QgYXJt X3NtbXVfbWFzdGVyICptYXN0ZXIsDQogCWlmICghbWFzdGVyLT5hdHNfZW5hYmxlZCkNCiAJCXJl dHVybiAwOw0KIA0KLQlmb3IgKGkgPSAwOyBpIDwgbWFzdGVyLT5udW1fc2lkczsgaSsrKSB7DQot CQljbWQtPmF0Yy5zaWQgPSBtYXN0ZXItPnNpZHNbaV07DQorCWZvciAoaSA9IDA7IGkgPCBtYXN0 ZXItPm51bV9zdHJlYW1zOyBpKyspIHsNCisJCWNtZC0+YXRjLnNpZCA9IG1hc3Rlci0+c3RyZWFt c1tpXS5pZDsNCiAJCWFybV9zbW11X2NtZHFfaXNzdWVfY21kKG1hc3Rlci0+c21tdSwgY21kKTsN CiAJfQ0KIA0KQEAgLTEyNzEsMTMgKzEyOTIsMTMgQEAgc3RhdGljIHZvaWQgYXJtX3NtbXVfaW5z dGFsbF9zdGVfZm9yX2RldihzdHJ1Y3QgYXJtX3NtbXVfbWFzdGVyICptYXN0ZXIpDQogCWludCBp LCBqOw0KIAlzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11ID0gbWFzdGVyLT5zbW11Ow0KIA0K LQlmb3IgKGkgPSAwOyBpIDwgbWFzdGVyLT5udW1fc2lkczsgKytpKSB7DQotCQl1MzIgc2lkID0g bWFzdGVyLT5zaWRzW2ldOw0KKwlmb3IgKGkgPSAwOyBpIDwgbWFzdGVyLT5udW1fc3RyZWFtczsg KytpKSB7DQorCQl1MzIgc2lkID0gbWFzdGVyLT5zdHJlYW1zW2ldLmlkOw0KIAkJX19sZTY0ICpz dGVwID0gYXJtX3NtbXVfZ2V0X3N0ZXBfZm9yX3NpZChzbW11LCBzaWQpOw0KIA0KIAkJLyogQnJp ZGdlZCBQQ0kgZGV2aWNlcyBtYXkgZW5kIHVwIHdpdGggZHVwbGljYXRlZCBJRHMgKi8NCiAJCWZv ciAoaiA9IDA7IGogPCBpOyBqKyspDQotCQkJaWYgKG1hc3Rlci0+c2lkc1tqXSA9PSBzaWQpDQor CQkJaWYgKG1hc3Rlci0+c3RyZWFtc1tqXS5pZCA9PSBzaWQpDQogCQkJCWJyZWFrOw0KIAkJaWYg KGogPCBpKQ0KIAkJCWNvbnRpbnVlOw0KQEAgLTE0ODYsNiArMTUwNywxMjMgQEAgc3RhdGljIGJv b2wgYXJtX3NtbXVfc2lkX2luX3JhbmdlKHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKnNtbXUsIHUz MiBzaWQpDQogDQogCXJldHVybiBzaWQgPCBsaW1pdDsNCiB9DQorDQorc3RhdGljIGludCBhcm1f c21tdV9pbnNlcnRfbWFzdGVyKHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKnNtbXUsDQorCQkJCSAg c3RydWN0IGFybV9zbW11X21hc3RlciAqbWFzdGVyKQ0KK3sNCisJaW50IGk7DQorCWludCByZXQg PSAwOw0KKwlzdHJ1Y3QgYXJtX3NtbXVfc3RyZWFtICpuZXdfc3RyZWFtLCAqY3VyX3N0cmVhbTsN CisJc3RydWN0IHJiX25vZGUgKipuZXdfbm9kZSwgKnBhcmVudF9ub2RlID0gTlVMTDsNCisJc3Ry dWN0IGlvbW11X2Z3c3BlYyAqZndzcGVjID0gZGV2X2lvbW11X2Z3c3BlY19nZXQobWFzdGVyLT5k ZXYpOw0KKwlib29sICppbnNlcnQ7DQorDQorCW1hc3Rlci0+c3RyZWFtcyA9IF94emFsbG9jX2Fy cmF5KHNpemVvZigqbWFzdGVyLT5zdHJlYW1zKSwgc2l6ZW9mKHZvaWQgKiksDQorCQkJCQlmd3Nw ZWMtPm51bV9pZHMpOw0KKwlpZiAoIW1hc3Rlci0+c3RyZWFtcykNCisJCXJldHVybiAtRU5PTUVN Ow0KKw0KKwlpbnNlcnQgPSBfeHphbGxvY19hcnJheShzaXplb2YoYm9vbCksIHNpemVvZihib29s ICopLA0KKwkJCQkJZndzcGVjLT5udW1faWRzKTsNCisJaWYgKCFpbnNlcnQpIHsNCisJCXhmcmVl KG1hc3Rlci0+c3RyZWFtcyk7DQorCQltYXN0ZXItPnN0cmVhbXMgPSBOVUxMOw0KKwkJcmV0dXJu IC1FTk9NRU07DQorCX0NCisNCisJbWFzdGVyLT5udW1fc3RyZWFtcyA9IGZ3c3BlYy0+bnVtX2lk czsNCisNCisJbXV0ZXhfbG9jaygmc21tdS0+c3RyZWFtc19tdXRleCk7DQorCWZvciAoaSA9IDA7 IGkgPCBmd3NwZWMtPm51bV9pZHM7IGkrKykgew0KKwkJdTMyIHNpZCA9IGZ3c3BlYy0+aWRzW2ld Ow0KKwkJaW5zZXJ0W2ldID0gZmFsc2U7DQorDQorCQluZXdfc3RyZWFtID0gJm1hc3Rlci0+c3Ry ZWFtc1tpXTsNCisJCW5ld19zdHJlYW0tPmlkID0gc2lkOw0KKwkJbmV3X3N0cmVhbS0+bWFzdGVy ID0gbWFzdGVyOw0KKwkJUkJfQ0xFQVJfTk9ERSgmbmV3X3N0cmVhbS0+bm9kZSk7DQorDQorCQkv Kg0KKwkJICogQ2hlY2sgdGhlIFNJRHMgYXJlIGluIHJhbmdlIG9mIHRoZSBTTU1VIGFuZCBvdXIg c3RyZWFtIHRhYmxlDQorCQkgKi8NCisJCWlmICghYXJtX3NtbXVfc2lkX2luX3JhbmdlKHNtbXUs IHNpZCkpIHsNCisJCQlyZXQgPSAtRVJBTkdFOw0KKwkJCWJyZWFrOw0KKwkJfQ0KKw0KKwkJLyog RW5zdXJlIGwyIHN0cnRhYiBpcyBpbml0aWFsaXNlZCAqLw0KKwkJaWYgKHNtbXUtPmZlYXR1cmVz ICYgQVJNX1NNTVVfRkVBVF8yX0xWTF9TVFJUQUIpIHsNCisJCQlyZXQgPSBhcm1fc21tdV9pbml0 X2wyX3N0cnRhYihzbW11LCBzaWQpOw0KKwkJCWlmIChyZXQpDQorCQkJCWJyZWFrOw0KKwkJfQ0K Kw0KKwkJLyogSW5zZXJ0IGludG8gU0lEIHRyZWUgKi8NCisJCWluc2VydFtpXSA9IHRydWU7DQor CQluZXdfbm9kZSA9ICYoc21tdS0+c3RyZWFtcy5yYl9ub2RlKTsNCisJCXdoaWxlICgqbmV3X25v ZGUpIHsNCisJCQljdXJfc3RyZWFtID0gcmJfZW50cnkoKm5ld19ub2RlLCBzdHJ1Y3QgYXJtX3Nt bXVfc3RyZWFtLA0KKwkJCQkJICAgICAgbm9kZSk7DQorCQkJcGFyZW50X25vZGUgPSAqbmV3X25v ZGU7DQorCQkJaWYgKGN1cl9zdHJlYW0tPmlkID4gbmV3X3N0cmVhbS0+aWQpIHsNCisJCQkJbmV3 X25vZGUgPSAmKCgqbmV3X25vZGUpLT5yYl9sZWZ0KTsNCisJCQl9IGVsc2UgaWYgKGN1cl9zdHJl YW0tPmlkIDwgbmV3X3N0cmVhbS0+aWQpIHsNCisJCQkJbmV3X25vZGUgPSAmKCgqbmV3X25vZGUp LT5yYl9yaWdodCk7DQorCQkJfSBlbHNlIGlmIChjdXJfc3RyZWFtLT5tYXN0ZXIgPT0gbWFzdGVy KSB7DQorCQkJCS8qIEJyaWRnZWQgUENJIGRldmljZXMgbWF5IGVuZCB1cCB3aXRoIGR1cGxpY2F0 ZWQgSURzICovDQorCQkJCWluc2VydFtpXSA9IGZhbHNlOw0KKwkJCQlicmVhazsNCisJCQl9DQor CQkJZWxzZSB7DQorCQkJCWRldl93YXJuKG1hc3Rlci0+ZGV2LA0KKwkJCQkJICJzdHJlYW0gJXUg YWxyZWFkeSBpbiB0cmVlXG4iLA0KKwkJCQkJIGN1cl9zdHJlYW0tPmlkKTsNCisJCQkJcmV0ID0g LUVJTlZBTDsNCisJCQkJaW5zZXJ0W2ldID0gZmFsc2U7DQorCQkJCWJyZWFrOw0KKwkJCX0NCisJ CX0NCisJCWlmIChyZXQpDQorCQkJYnJlYWs7DQorDQorCQlpZihpbnNlcnRbaV0pIHsNCisJCQly Yl9saW5rX25vZGUoJm5ld19zdHJlYW0tPm5vZGUsIHBhcmVudF9ub2RlLCBuZXdfbm9kZSk7DQor CQkJcmJfaW5zZXJ0X2NvbG9yKCZuZXdfc3RyZWFtLT5ub2RlLCAmc21tdS0+c3RyZWFtcyk7DQor CQl9DQorCX0NCisNCisJaWYgKHJldCkgew0KKwkJZm9yIChpLS07IGkgPj0gMDsgaS0tKQ0KKwkJ CWlmIChpbnNlcnRbaV0pDQorCQkJCXJiX2VyYXNlKCZtYXN0ZXItPnN0cmVhbXNbaV0ubm9kZSwg JnNtbXUtPnN0cmVhbXMpOw0KKwkJeGZyZWUobWFzdGVyLT5zdHJlYW1zKTsNCisJCW1hc3Rlci0+ c3RyZWFtcyA9IE5VTEw7DQorCX0NCisJbXV0ZXhfdW5sb2NrKCZzbW11LT5zdHJlYW1zX211dGV4 KTsNCisNCisJeGZyZWUoaW5zZXJ0KTsNCisNCisJcmV0dXJuIHJldDsNCit9DQorDQorc3RhdGlj IHZvaWQgYXJtX3NtbXVfcmVtb3ZlX21hc3RlcihzdHJ1Y3QgYXJtX3NtbXVfbWFzdGVyICptYXN0 ZXIpDQorew0KKwlpbnQgaTsNCisJc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSA9IG1hc3Rl ci0+c21tdTsNCisJc3RydWN0IGlvbW11X2Z3c3BlYyAqZndzcGVjID0gZGV2X2lvbW11X2Z3c3Bl Y19nZXQobWFzdGVyLT5kZXYpOw0KKw0KKwlpZiAoIXNtbXUgfHwgIW1hc3Rlci0+c3RyZWFtcykN CisJCXJldHVybjsNCisNCisJbXV0ZXhfbG9jaygmc21tdS0+c3RyZWFtc19tdXRleCk7DQorCWZv ciAoaSA9IDA7IGkgPCBmd3NwZWMtPm51bV9pZHM7IGkrKykNCisJCWlmKCFSQl9FTVBUWV9OT0RF KCZtYXN0ZXItPnN0cmVhbXNbaV0ubm9kZSkpDQorCQkJcmJfZXJhc2UoJm1hc3Rlci0+c3RyZWFt c1tpXS5ub2RlLCAmc21tdS0+c3RyZWFtcyk7DQorCW11dGV4X3VubG9jaygmc21tdS0+c3RyZWFt c19tdXRleCk7DQorDQorCXhmcmVlKG1hc3Rlci0+c3RyZWFtcyk7DQorfQ0KKw0KIC8qIEZvcndh cmQgZGVjbGFyYXRpb24gKi8NCiBzdGF0aWMgc3RydWN0IGFybV9zbW11X2RldmljZSAqYXJtX3Nt bXVfZ2V0X2J5X2Rldihjb25zdCBzdHJ1Y3QgZGV2aWNlICpkZXYpOw0KIHN0YXRpYyBpbnQgYXJt X3NtbXVfYXNzaWduX2RldihzdHJ1Y3QgZG9tYWluICpkLCB1OCBkZXZmbiwgc3RydWN0IGRldmlj ZSAqZGV2LA0KQEAgLTE0OTUsNyArMTYzMyw3IEBAIHN0YXRpYyBpbnQgYXJtX3NtbXVfZGVhc3Np Z25fZGV2KHN0cnVjdCBkb21haW4gKmQsIHVpbnQ4X3QgZGV2Zm4sDQogDQogc3RhdGljIGludCBh cm1fc21tdV9hZGRfZGV2aWNlKHU4IGRldmZuLCBzdHJ1Y3QgZGV2aWNlICpkZXYpDQogew0KLQlp bnQgaSwgcmV0Ow0KKwlpbnQgcmV0Ow0KIAlzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11Ow0K IAlzdHJ1Y3QgYXJtX3NtbXVfbWFzdGVyICptYXN0ZXI7DQogCXN0cnVjdCBpb21tdV9md3NwZWMg KmZ3c3BlYzsNCkBAIC0xNTMyLDI2ICsxNjcwLDExIEBAIHN0YXRpYyBpbnQgYXJtX3NtbXVfYWRk X2RldmljZSh1OCBkZXZmbiwgc3RydWN0IGRldmljZSAqZGV2KQ0KIA0KIAltYXN0ZXItPmRldiA9 IGRldjsNCiAJbWFzdGVyLT5zbW11ID0gc21tdTsNCi0JbWFzdGVyLT5zaWRzID0gZndzcGVjLT5p ZHM7DQotCW1hc3Rlci0+bnVtX3NpZHMgPSBmd3NwZWMtPm51bV9pZHM7DQogCWRldl9pb21tdV9w cml2X3NldChkZXYsIG1hc3Rlcik7DQogDQotCS8qIENoZWNrIHRoZSBTSURzIGFyZSBpbiByYW5n ZSBvZiB0aGUgU01NVSBhbmQgb3VyIHN0cmVhbSB0YWJsZSAqLw0KLQlmb3IgKGkgPSAwOyBpIDwg bWFzdGVyLT5udW1fc2lkczsgaSsrKSB7DQotCQl1MzIgc2lkID0gbWFzdGVyLT5zaWRzW2ldOw0K LQ0KLQkJaWYgKCFhcm1fc21tdV9zaWRfaW5fcmFuZ2Uoc21tdSwgc2lkKSkgew0KLQkJCXJldCA9 IC1FUkFOR0U7DQotCQkJZ290byBlcnJfZnJlZV9tYXN0ZXI7DQotCQl9DQotDQotCQkvKiBFbnN1 cmUgbDIgc3RydGFiIGlzIGluaXRpYWxpc2VkICovDQotCQlpZiAoc21tdS0+ZmVhdHVyZXMgJiBB Uk1fU01NVV9GRUFUXzJfTFZMX1NUUlRBQikgew0KLQkJCXJldCA9IGFybV9zbW11X2luaXRfbDJf c3RydGFiKHNtbXUsIHNpZCk7DQotCQkJaWYgKHJldCkNCi0JCQkJZ290byBlcnJfZnJlZV9tYXN0 ZXI7DQotCQl9DQotCX0NCisJcmV0ID0gYXJtX3NtbXVfaW5zZXJ0X21hc3RlcihzbW11LCBtYXN0 ZXIpOw0KKwlpZiAocmV0KQ0KKwkJZ290byBlcnJfZnJlZV9tYXN0ZXI7DQogDQogCS8qDQogCSAq IE5vdGUgdGhhdCBQQVNJRCBtdXN0IGJlIGVuYWJsZWQgYmVmb3JlLCBhbmQgZGlzYWJsZWQgYWZ0 ZXIgQVRTOg0KQEAgLTE1OTgsNiArMTcyMSw4IEBAIHN0YXRpYyBpbnQgYXJtX3NtbXVfYWRkX2Rl dmljZSh1OCBkZXZmbiwgc3RydWN0IGRldmljZSAqZGV2KQ0KIAlyZXR1cm4gMDsNCiANCiBlcnJf ZnJlZV9tYXN0ZXI6DQorCWFybV9zbW11X2Rpc2FibGVfcGFzaWQobWFzdGVyKTsNCisJYXJtX3Nt bXVfcmVtb3ZlX21hc3RlcihtYXN0ZXIpOw0KIAl4ZnJlZShtYXN0ZXIpOw0KIAlkZXZfaW9tbXVf cHJpdl9zZXQoZGV2LCBOVUxMKTsNCiAJcmV0dXJuIHJldDsNCkBAIC0xNzk2LDYgKzE5MjEsOSBA QCBzdGF0aWMgaW50IF9faW5pdCBhcm1fc21tdV9pbml0X3N0cnVjdHVyZXMoc3RydWN0IGFybV9z bW11X2RldmljZSAqc21tdSkNCiB7DQogCWludCByZXQ7DQogDQorCW11dGV4X2luaXQoJnNtbXUt PnN0cmVhbXNfbXV0ZXgpOw0KKwlzbW11LT5zdHJlYW1zID0gUkJfUk9PVDsNCisNCiAJcmV0ID0g YXJtX3NtbXVfaW5pdF9xdWV1ZXMoc21tdSk7DQogCWlmIChyZXQpDQogCQlyZXR1cm4gcmV0Ow0K ZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmggYi94ZW4v ZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5oDQppbmRleCBhYjA3MzY2Mjk0Li5hYjFm MjlmNmM3IDEwMDY0NA0KLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMu aA0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuaA0KQEAgLTYzOSw2 ICs2MzksMTUgQEAgc3RydWN0IGFybV9zbW11X2RldmljZSB7DQogCXN0cnVjdCB0YXNrbGV0CQll dnRxX2lycV90YXNrbGV0Ow0KIAlzdHJ1Y3QgdGFza2xldAkJcHJpcV9pcnFfdGFza2xldDsNCiAJ c3RydWN0IHRhc2tsZXQJCWNvbWJpbmVkX2lycV90YXNrbGV0Ow0KKw0KKwlzdHJ1Y3QgcmJfcm9v dAkJc3RyZWFtczsNCisJc3RydWN0IG11dGV4CQlzdHJlYW1zX211dGV4Ow0KK307DQorDQorc3Ry dWN0IGFybV9zbW11X3N0cmVhbSB7DQorCXUzMgkJCQkJCQlpZDsNCisJc3RydWN0IGFybV9zbW11 X21hc3RlcgkJKm1hc3RlcjsNCisJc3RydWN0IHJiX25vZGUJCQkJbm9kZTsNCiB9Ow0KIA0KIC8q IFNNTVUgcHJpdmF0ZSBkYXRhIGZvciBlYWNoIG1hc3RlciAqLw0KQEAgLTY0Nyw4ICs2NTYsOCBA QCBzdHJ1Y3QgYXJtX3NtbXVfbWFzdGVyIHsNCiAJc3RydWN0IGRldmljZQkJCSpkZXY7DQogCXN0 cnVjdCBhcm1fc21tdV9kb21haW4JCSpkb21haW47DQogCXN0cnVjdCBsaXN0X2hlYWQJCWRvbWFp bl9oZWFkOw0KLQl1MzIJCQkJKnNpZHM7DQotCXVuc2lnbmVkIGludAkJCW51bV9zaWRzOw0KKwlz dHJ1Y3QgYXJtX3NtbXVfc3RyZWFtCQkqc3RyZWFtczsNCisJdW5zaWduZWQgaW50CQkJCW51bV9z dHJlYW1zOw0KIAlib29sCQkJCWF0c19lbmFibGVkOw0KIH07DQogDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441810.1659322 (Exim 4.92) (envelope-from ) id 1xEFBF-0007iX-TD; Wed, 07 Oct 2026 00:06:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441810.1659322; Wed, 07 Oct 2026 00:06: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 1xEFBF-0007iQ-Q4; Wed, 07 Oct 2026 00:06:45 +0000 Received: by outflank-mailman (input) for mailman id 1441810; Wed, 07 Oct 2026 00:06:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBE-0007gu-27 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBD-00Bv1m-F5 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:43 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58c9c-e002-0a2a0a5209dd-0a2a450ca834-46 for ; Wed, 07 Oct 2026 02:06:43 +0200 Received: from [40.107.159.99] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d13-f479-0a2a450c0019-286b9f6396f1-3 for ; Wed, 07 Oct 2026 02:06:43 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:41 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=VCKIWYo0KEYPjyl3zbPV18GTE00x9djsabLrDkQgTb5iE/p7e8w2TvnQ0RH/sw63UZ3bQYhRRYbNrX/Y+bN+GGi4DNs2B86D7+ij+QYR7+zk1nWz/VebhzDvEWJ8ous6hL2zKhLFyIuRORlpUsLGoXfO80J2deuwH6zaOlg6wWX5vOdht0SySyKlXXlAlW4Wty953Ha45XGeLSnxufVKsDLNBoouRQuCJvhUJCfx6tZY5J9ablCTH6cLJ55IuuDeX6/XHFc9l9R4yJGvpVYtBIgRgWErNYMuE+15zvRYqNLjB6IgpDT3lmhjhAB6aiBgjBaQmgZgUNOMFtMOsq1ekg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3unhxd+5LFa7/b/Acs0h9YyJ8jBZNU977noc0szTA+o=; b=CjHJngR/+C/Gn/ez4ChzI6TBZAj24C3PUfjqw4E0iaBaaQMBS4XYJi0uCnn8qyxUUqRDtJp4zyRbsJs3a5zokR7tFh8OQ22M72HfCOmQb42eNm0jjXpaD6Epu/otOvUKMkTjwaXJ3rO0uk8v/M+sYl4mO7GnJ4q7DINTp4FrnCDvc8pEyR36z+um8Da5+X7YlWX9Lq8ij2m7DPlTkCUi61fOSceX+k4pQm3ewO7VFsOEJHb7l7N7Ao7TZtQK1cWv0yBxBJ2G7rQCncqhMJScAAiL18dj/gJsvYwe9L/OnpDShuZl3ZGo5OugG+nUvNDRibmRCnhHsVzZhp7hphO46w== 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=3unhxd+5LFa7/b/Acs0h9YyJ8jBZNU977noc0szTA+o=; b=PQEK3UnzoyxSOHZE9wGkhZPhhUkUYben7rHs2VkC9i9wAWqEDGChIp9EwzvHkxjZOJh8P45Bn7tST+BaL+6FgVRgh5cg8grCWSOT4vRPlEmHV3izUH4w7RgzTsedeVeltaeTRTsbYtGcFrQKEnj3bqPE3R5Z/c753LbXP9mBwK9ci+aQCdQHYBvZb/K4lOmMnUWRxDHuU7CuRV6nFGcHeCTEc9LPsE2dCgwuh5a2wZcQ/5Pth8lL+OSstApe4A2sYbBKNulkuv4A0/VNKsVld7dgxcfvqwYYSCYxzxHjlnzRNsSQlCT13HliOvvqL/FwzVYIyGnaLS3taOFCnUqFMw== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Bertrand Marquis , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 02/22] xen/arm: smmuv3: Add support for stage-1 and nested stage translation Thread-Topic: [PATCH v4 02/22] xen/arm: smmuv3: Add support for stage-1 and nested stage translation Thread-Index: AQHdVe+7M24j/0GCrEe+w9oTrSt/Tw== Date: Wed, 7 Oct 2026 00:06:41 +0000 Message-ID: <6e45683f154be94e573a4a5e5d25c7efcc29fbe5.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 9cf78400-9bb4-4275-2fd4-08df2406dd83 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: m0hUHmXl6AV1Vu3wdezC7of84HgzYod76fhc1+qFkHqGVpssPmNV1JlYWf1ip/S5vQG0/1bUwUaMJMeLiWpMASsWLTnbxDPrLsemGgS5/DnVjAgWk7a57ndG5QlKhWcmHxvD/Iox0hY9ktqjr9TS47OzGD3YliymIvVGpD23zZdQ38es6F9hIag9Fld0D4LVaVyP+gVeM69Xl3FR9TazLhJBW4HOdhNbRPPFXOuj9cS55vT6Yu6JikpUQMCq0p4cyG955ImnBkf7lHjPam86vg5NcjJjDejcKOSd6mlRzSay5by792zPtWpkY2mcni9dMC+JSwayusWkgiriJ2rV5pqWWbzyOWRCk3cWja/dCHUohmZepFNC39vQSyHvBkb997Hivspk1qbrq7c18AXvI6Kyd+tj9XyxGKomASNJkQo0/VrPmmBR+sY6QjCO86YsNt9NXd96X0F2VBWKJp4HjrzYJBRZKpVlwZcuri/AK5XSjZ7Ke5Qgt9x6e62BNEGMbQpdF/XA75VnANz4uG4f1Eyxlnql4mfH66o1dmQnkYeJO2mPW2FH2/90ouQohj86jrZwBfU54V79KadGrjG4+c1vLhXsE/U8snH+G2wsKcY2/dpG/KIoJ/hKAVBE5hz2NSz26GwI0Xd2ZKYzFwnVEABJNNSTyg3WZ2cEWid48OknaK+cEd5gGotxWTHsdDfzxFjZul7dNqKegqic4E5J61a5SGNH3G0zJbD23FqnDy8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?d1RKYWZYRDZiMXlCUytyN1o3SFNkbHc5QnA0anZNb1ZudjgrRUJLbU04RUtq?= =?utf-8?B?OW9DVHlVZUlsdFJhUGNzRTNjTlF5VitJUXIxZnNMTVFtS1dEbHNIaHFWUkZh?= =?utf-8?B?UTl4ZnBiU3VrZzlXV3RHNHNwV2VuNDZPM3p4Q0p1bmlmVzgzZy9tR3RtbHcy?= =?utf-8?B?UDJoVGhGWEQwNDBtbWZBRmdvQ09ZcWcyMnFDblYzd1M0Y2h5VmVUY0JUK1Vs?= =?utf-8?B?UnNaTDdBVEFGc2t5WWJSRmRIQTdSVFVldHRidm5ZTkUySHc2UlRicFZTTVE1?= =?utf-8?B?RmIvdE9LTkZRTzZHdHRZTVRkdXhMQzRMY0ZyUHNwbmJiUnZScTdncXNxR3Zh?= =?utf-8?B?eklFMFMwMzdxTDNXWE0rZU5sYVJqM0ZMdkZXUTFYRVFsejF1YVlRVndENFJV?= =?utf-8?B?UWF4UDVJVzRGRmx6a3l4R25DYTBuR3dOclpiMHArYW0wSzJpbWErMVp3UkND?= =?utf-8?B?M01URktGZzFVeGtCN2IvT2UvdS9XTzlWb0FsTHpmazFuS3ZsSEZCVHhYZU1i?= =?utf-8?B?cU54N09OVVNTR1lqQnNJZVBpRE4rcGpwYUpyQUg1dEFRWnVFa2ZPUXlVdUNj?= =?utf-8?B?ZkZZc1hXZTQ3THF3eHMzRlFYOHZrWmhwZnFNMHMyVzlzWVFEOWJCbzdnSW5S?= =?utf-8?B?UVFjUURxK0hWcS9ZOEowMzRTOUJqTGNlWnJEQ3NubjRrM0UyRCtuVzV2ak5V?= =?utf-8?B?dk05L0lXNUJBdmduMWF6SkFHaGpENjU0TmVsWkswdEpERkwyRndKNzV2NDVh?= =?utf-8?B?UngxeDE2dDZjVmcwWE9zLzcvQkl2SUpPdzlLQ256ZXloYk56Z2N1WnZDSFph?= =?utf-8?B?TnRYMXFiTGdJQkx5dFQzOVFHZnNuaUJDNUV1ZXNDNFA2cEgrMUdrNEtqWnBy?= =?utf-8?B?VVJDT2pWZk5LL21HZldNak54emxIcVRTREdjTjVkb3FnQWcybWVqN0R5WU12?= =?utf-8?B?YU8rVjdTRjUrS1MzdXRibnBWOHZ5K2kyeUxlbUtPaEZXOVAwY1E4ZGJkUmJq?= =?utf-8?B?Y0YzTVNPZ3pXeHFPUFZRaXEzSzJjTWJsSjVoS1AvNEhyMVQyVkpmSlMrYlpx?= =?utf-8?B?cW5RYk9xcGNxZnNvaWNWWDVyU3I0SVNkS0p3Y0poSE9BdW9vTmhFbGhIdHp3?= =?utf-8?B?UnpQakZ0ajFadzliNytOZTg5YXgrV3VOcGJMUFE2SVR6ZndISGxzd1h5TlVx?= =?utf-8?B?aHR6dmpZdjk0ZWE3WkVmWENoYVQwczVSekF0bVEzNUljaVlpV0pva1orOGN4?= =?utf-8?B?SFBSOXJxTGZoTFFlSzdRU3FzQ1JrQnA3Zk1QYzNUT2J1ZThkRGpPd21xcXdy?= =?utf-8?B?OHFRam5zZXBmZnJBQytCOVJFZEhBMkNranlWMmt1ekpWbTNHcjk0NWl1d1Vo?= =?utf-8?B?dExIUmtBdWRQdEh5bzNkT2lBRGxpMTR3aU83QiticzFvYmV0ZWlDM25EWVpj?= =?utf-8?B?eWlSbzQySy9jU3dFelgyNzRaQjdOVEJmY0dTWUp0OWxyb2lZalVheVZHRCts?= =?utf-8?B?aStaUkd0dXp4UEVsL1dwUG1kcW9xWFcwOGlCVmxKVmJEOG50RVBBdUZUbVZ2?= =?utf-8?B?cVdaaS9xTkpaQ1RYQTgxbFZLdm01ZDBtNnhaMndPR3dPL3RGSDhTT1o4RjBz?= =?utf-8?B?NWNmOHVsR3hwb3pLL1Y3dkVVM3BCaHVZNm5DdlRVaHlDMkoyT3lhRWd3WUhq?= =?utf-8?B?VHVvSlBvU3drR2k0eGN2eTFvdC9WVHh4NCtQeTk4QWtrQndRU2dLblpoOXVY?= =?utf-8?B?MHFha2xOb2E3cEpBSTlUNW5sM1lCVDRtVEVnNVJ4T3JVdWl6dGxmaThsYi9C?= =?utf-8?B?OXVDMWNHaDZOejA1YVh2VFZrYjA4L0lOZnpXSkplK2s2VHRxQVoveU05aFRF?= =?utf-8?B?V3JmVEhIZGx3b2hUMUJnckhQcFUzakhnNmJXWU53Q3dUdUp0cndSTlVkeUt3?= =?utf-8?B?QVJ6eXhObzhlWUsrbnlpd0dMSTVaS3BuVVlyd2hMSHhGeUZnQUJIL21sU1dw?= =?utf-8?B?WlZaTzNncklnYWlqQ3N2ZGxSM2VxQStNRWNyVzhPM3U2Y1BKWmNGcXFncWJr?= =?utf-8?B?SWtwTUl3OStrRlFmRjVGR0Q4Ym1CMFBkM3prbDdtcXNSODBmakNFak42QWtY?= =?utf-8?B?VzFWQUNIMjh1dXQvNFpKSkRLTXBuSEJhQWRPbUdwb0N6YjlUTFJXTzVRK2Rk?= =?utf-8?B?czJhR1Z0WUdsdHFLanFaeCtXTnhyazVKL21GVkxtdHU0cUdKTDZzb3QwR3Rk?= =?utf-8?B?VW5UMCtlRlRQS1FJd09sSFBsbVJ1TktnR2l0bVFGa25WTlpqb1ovTk9waGVn?= =?utf-8?B?OVFabHVmdmhmTmFDOXRQZmkyS3lqZDNnMXBJWXBnK0ViSWowZiswQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf78400-9bb4-4275-2fd4-08df2406dd83 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:41.4269 (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: zZn5hGoFPhEQJlix1AX1zBH31YlWNV+MktknG6dQF3n/0t6NV5U2KbFnVe0qAwY2XcFHGV69N/QH5iIht+HnxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-d25034/1791331603-018C5A5B-9ABE244D/0/0 X-purgate-type: clean X-purgate-size: 9828 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNClhlbiBTTU1VdjMgZHJp dmVyIG9ubHkgc3VwcG9ydHMgc3RhZ2UtMiB0cmFuc2xhdGlvbi4gQWRkIHN1cHBvcnQgZm9yDQpT dGFnZS0xIHRyYW5zbGF0aW9uIHRoYXQgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBuZXN0ZWQgc3Rh Z2UNCnRyYW5zbGF0aW9uLg0KDQpJbiB0cnVlIG5lc3RlZCBtb2RlLCBib3RoIHMxX2NmZyBhbmQg czJfY2ZnIHdpbGwgY29leGlzdC4NCkxldCdzIHJlbW92ZSB0aGUgdW5pb24uIFdoZW4gbmVzdGVk IHN0YWdlIHRyYW5zbGF0aW9uIGlzIHNldHVwLCBib3RoDQpzMV9jZmcgYW5kIHMyX2NmZyBhcmUg dmFsaWQuDQoNCldlIGludHJvZHVjZSBhIG5ldyBzbW11X2RvbWFpbiBhYm9ydCBmaWVsZCB0aGF0 IHdpbGwgYmUgc2V0DQp1cG9uIGd1ZXN0IHN0YWdlLTEgY29uZmlndXJhdGlvbiBwYXNzaW5nLiBJ ZiBubyBndWVzdCBzdGFnZS0xDQpjb25maWcgaGFzIGJlZW4gYXR0YWNoZWQsIGl0IGlzIGlnbm9y ZWQgd2hlbiB3cml0aW5nIHRoZSBTVEUuDQoNCmFybV9zbW11X3dyaXRlX3N0cnRhYl9lbnQoKSBp cyBtb2RpZmllZCB0byB3cml0ZSBib3RoIHN0YWdlDQpmaWVsZHMgaW4gdGhlIFNURSBhbmQgZGVh bCB3aXRoIHRoZSBhYm9ydCBmaWVsZC4NCg0KU2lnbmVkLW9mZi1ieTogUmFodWwgU2luZ2ggPHJh aHVsLnNpbmdoQGFybS5jb20+DQpTaWduZWQtb2ZmLWJ5OiBNaWxhbiBEam9raWMgPG1pbGFuX2Rq b2tpY0BlcGFtLmNvbT4NCi0tLQ0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYz LmMgfCA5NiArKysrKysrKysrKysrKysrKysrKysrKy0tLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhy b3VnaC9hcm0vc21tdS12My5oIHwgIDkgKysrDQogMiBmaWxlcyBjaGFuZ2VkLCA5MyBpbnNlcnRp b25zKCspLCAxMiBkZWxldGlvbnMoLSkNCg0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0 aHJvdWdoL2FybS9zbW11LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12 My5jDQppbmRleCA3MTYyNDczZDYyLi5kM2U4OGQ1YTU1IDEwMDY0NA0KLS0tIGEveGVuL2RyaXZl cnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYw0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91 Z2gvYXJtL3NtbXUtdjMuYw0KQEAgLTY4Myw4ICs2ODMsMTAgQEAgc3RhdGljIHZvaWQgYXJtX3Nt bXVfd3JpdGVfc3RydGFiX2VudChzdHJ1Y3QgYXJtX3NtbXVfbWFzdGVyICptYXN0ZXIsIHUzMiBz aWQsDQogCSAqIDMuIFVwZGF0ZSBDb25maWcsIHN5bmMNCiAJICovDQogCXU2NCB2YWwgPSBsZTY0 X3RvX2NwdShkc3RbMF0pOw0KLQlib29sIHN0ZV9saXZlID0gZmFsc2U7DQorCWJvb2wgczFfbGl2 ZSA9IGZhbHNlLCBzMl9saXZlID0gZmFsc2UsIHN0ZV9saXZlID0gZmFsc2U7DQorCWJvb2wgYWJv cnQsIHRyYW5zbGF0ZSA9IGZhbHNlOw0KIAlzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11ID0g TlVMTDsNCisJc3RydWN0IGFybV9zbW11X3MxX2NmZyAqczFfY2ZnID0gTlVMTDsNCiAJc3RydWN0 IGFybV9zbW11X3MyX2NmZyAqczJfY2ZnID0gTlVMTDsNCiAJc3RydWN0IGFybV9zbW11X2RvbWFp biAqc21tdV9kb21haW4gPSBOVUxMOw0KIAlzdHJ1Y3QgYXJtX3NtbXVfY21kcV9lbnQgcHJlZmV0 Y2hfY21kID0gew0KQEAgLTY5OSwzMCArNzAxLDU3IEBAIHN0YXRpYyB2b2lkIGFybV9zbW11X3dy aXRlX3N0cnRhYl9lbnQoc3RydWN0IGFybV9zbW11X21hc3RlciAqbWFzdGVyLCB1MzIgc2lkLA0K IAkJc21tdSA9IG1hc3Rlci0+c21tdTsNCiAJfQ0KIA0KLQlpZiAoc21tdV9kb21haW4pDQotCQlz Ml9jZmcgPSAmc21tdV9kb21haW4tPnMyX2NmZzsNCisJaWYgKHNtbXVfZG9tYWluKSB7DQorCQlz d2l0Y2ggKHNtbXVfZG9tYWluLT5zdGFnZSkgew0KKwkJY2FzZSBBUk1fU01NVV9ET01BSU5fUzE6 DQorCQkJczFfY2ZnID0gJnNtbXVfZG9tYWluLT5zMV9jZmc7DQorCQkJYnJlYWs7DQorCQljYXNl IEFSTV9TTU1VX0RPTUFJTl9ORVNURUQ6DQorCQkJczFfY2ZnID0gJnNtbXVfZG9tYWluLT5zMV9j Zmc7DQorCQkJZmFsbHRocm91Z2g7DQorCQljYXNlIEFSTV9TTU1VX0RPTUFJTl9TMjoNCisJCQlz Ml9jZmcgPSAmc21tdV9kb21haW4tPnMyX2NmZzsNCisJCQlicmVhazsNCisJCWRlZmF1bHQ6DQor CQkJYnJlYWs7DQorCQl9DQorCQl0cmFuc2xhdGUgPSBzMV9jZmcgfHwgczJfY2ZnOw0KKwl9DQog DQogCWlmICh2YWwgJiBTVFJUQUJfU1RFXzBfVikgew0KIAkJc3dpdGNoIChGSUVMRF9HRVQoU1RS VEFCX1NURV8wX0NGRywgdmFsKSkgew0KIAkJY2FzZSBTVFJUQUJfU1RFXzBfQ0ZHX0JZUEFTUzoN CiAJCQlicmVhazsNCisJCWNhc2UgU1RSVEFCX1NURV8wX0NGR19TMV9UUkFOUzoNCisJCQlzMV9s aXZlID0gdHJ1ZTsNCisJCQlicmVhazsNCiAJCWNhc2UgU1RSVEFCX1NURV8wX0NGR19TMl9UUkFO UzoNCi0JCQlzdGVfbGl2ZSA9IHRydWU7DQorCQkJczJfbGl2ZSA9IHRydWU7DQorCQkJYnJlYWs7 DQorCQljYXNlIFNUUlRBQl9TVEVfMF9DRkdfTkVTVEVEOg0KKwkJCXMxX2xpdmUgPSB0cnVlOw0K KwkJCXMyX2xpdmUgPSB0cnVlOw0KIAkJCWJyZWFrOw0KIAkJY2FzZSBTVFJUQUJfU1RFXzBfQ0ZH X0FCT1JUOg0KLQkJCUJVR19PTighZGlzYWJsZV9ieXBhc3MpOw0KIAkJCWJyZWFrOw0KIAkJZGVm YXVsdDoNCiAJCQlCVUcoKTsgLyogU1RFIGNvcnJ1cHRpb24gKi8NCiAJCX0NCiAJfQ0KIA0KKwlz dGVfbGl2ZSA9IHMxX2xpdmUgfHwgczJfbGl2ZTsNCisNCiAJLyogTnVrZSB0aGUgZXhpc3Rpbmcg U1RFXzAgdmFsdWUsIGFzIHdlJ3JlIGdvaW5nIHRvIHJld3JpdGUgaXQgKi8NCiAJdmFsID0gU1RS VEFCX1NURV8wX1Y7DQogDQogCS8qIEJ5cGFzcy9mYXVsdCAqLw0KLQlpZiAoIXNtbXVfZG9tYWlu IHx8ICEoczJfY2ZnKSkgew0KLQkJaWYgKCFzbW11X2RvbWFpbiAmJiBkaXNhYmxlX2J5cGFzcykN CisJaWYgKCFzbW11X2RvbWFpbikNCisJCWFib3J0ID0gZGlzYWJsZV9ieXBhc3M7DQorCWVsc2UN CisJCWFib3J0ID0gc21tdV9kb21haW4tPmFib3J0Ow0KKw0KKwlpZiAoYWJvcnQgfHwgIXRyYW5z bGF0ZSkgew0KKwkJaWYgKGFib3J0KQ0KIAkJCXZhbCB8PSBGSUVMRF9QUkVQKFNUUlRBQl9TVEVf MF9DRkcsIFNUUlRBQl9TVEVfMF9DRkdfQUJPUlQpOw0KIAkJZWxzZQ0KIAkJCXZhbCB8PSBGSUVM RF9QUkVQKFNUUlRBQl9TVEVfMF9DRkcsIFNUUlRBQl9TVEVfMF9DRkdfQllQQVNTKTsNCkBAIC03 NDAsNyArNzY5LDMyIEBAIHN0YXRpYyB2b2lkIGFybV9zbW11X3dyaXRlX3N0cnRhYl9lbnQoc3Ry dWN0IGFybV9zbW11X21hc3RlciAqbWFzdGVyLCB1MzIgc2lkLA0KIAkJcmV0dXJuOw0KIAl9DQog DQorCWlmIChzdGVfbGl2ZSkgew0KKwkJLyogRmlyc3QgaW52YWxpZGF0ZSB0aGUgbGl2ZSBTVEUg Ki8NCisJCWRzdFswXSA9IGNwdV90b19sZTY0KFNUUlRBQl9TVEVfMF9DRkdfQUJPUlQpOw0KKwkJ YXJtX3NtbXVfc3luY19zdGVfZm9yX3NpZChzbW11LCBzaWQpOw0KKwl9DQorDQorCWlmIChzMV9j ZmcpIHsNCisJCWRzdFsxXSA9IGNwdV90b19sZTY0KA0KKwkJCSBGSUVMRF9QUkVQKFNUUlRBQl9T VEVfMV9TMURTUywgU1RSVEFCX1NURV8xX1MxRFNTX1NTSUQwKSB8DQorCQkJIEZJRUxEX1BSRVAo U1RSVEFCX1NURV8xX1MxQ0lSLCBTVFJUQUJfU1RFXzFfUzFDX0NBQ0hFX1dCUkEpIHwNCisJCQkg RklFTERfUFJFUChTVFJUQUJfU1RFXzFfUzFDT1IsIFNUUlRBQl9TVEVfMV9TMUNfQ0FDSEVfV0JS QSkgfA0KKwkJCSBGSUVMRF9QUkVQKFNUUlRBQl9TVEVfMV9TMUNTSCwgQVJNX1NNTVVfU0hfSVNI KSB8DQorCQkJIEZJRUxEX1BSRVAoU1RSVEFCX1NURV8xX1NUUlcsIFNUUlRBQl9TVEVfMV9TVFJX X05TRUwxKSk7DQorDQorCQlpZiAoc21tdS0+ZmVhdHVyZXMgJiBBUk1fU01NVV9GRUFUX1NUQUxM UyAmJg0KKwkJICAgIShzbW11LT5mZWF0dXJlcyAmIEFSTV9TTU1VX0ZFQVRfU1RBTExfRk9SQ0Up KQ0KKwkJCWRzdFsxXSB8PSBjcHVfdG9fbGU2NChTVFJUQUJfU1RFXzFfUzFTVEFMTEQpOw0KKw0K KwkJdmFsIHw9IChzMV9jZmctPnMxY3R4cHRyICYgU1RSVEFCX1NURV8wX1MxQ1RYUFRSX01BU0sp IHwNCisJCQlGSUVMRF9QUkVQKFNUUlRBQl9TVEVfMF9DRkcsIFNUUlRBQl9TVEVfMF9DRkdfUzFf VFJBTlMpIHwNCisJCQlGSUVMRF9QUkVQKFNUUlRBQl9TVEVfMF9TMUNETUFYLCBzMV9jZmctPnMx Y2RtYXgpIHwNCisJCQlGSUVMRF9QUkVQKFNUUlRBQl9TVEVfMF9TMUZNVCwgczFfY2ZnLT5zMWZt dCk7DQorCX0NCisNCiAJaWYgKHMyX2NmZykgew0KKwkJdTY0IHZ0dGJyID0gczJfY2ZnLT52dHRi ciAmIFNUUlRBQl9TVEVfM19TMlRUQl9NQVNLOw0KIAkJdTY0IHN0cnRhYiA9DQogCQkJIEZJRUxE X1BSRVAoU1RSVEFCX1NURV8yX1MyVk1JRCwgczJfY2ZnLT52bWlkKSB8DQogCQkJIEZJRUxEX1BS RVAoU1RSVEFCX1NURV8yX1ZUQ1IsIHMyX2NmZy0+dnRjcikgfA0KQEAgLTc1MCwxMiArODA0LDE5 IEBAIHN0YXRpYyB2b2lkIGFybV9zbW11X3dyaXRlX3N0cnRhYl9lbnQoc3RydWN0IGFybV9zbW11 X21hc3RlciAqbWFzdGVyLCB1MzIgc2lkLA0KIAkJCSBTVFJUQUJfU1RFXzJfUzJQVFcgfCBTVFJU QUJfU1RFXzJfUzJBQTY0IHwNCiAJCQkgU1RSVEFCX1NURV8yX1MyUjsNCiANCi0JCUJVR19PTihz dGVfbGl2ZSk7DQorCQlpZiAoczJfbGl2ZSkgew0KKwkJCXU2NCBzMnR0YiA9IGxlNjRfdG9fY3B1 KGRzdFszXSkgJiBTVFJUQUJfU1RFXzNfUzJUVEJfTUFTSzsNCisJCQlCVUdfT04oczJ0dGIgIT0g dnR0YnIpOw0KKwkJfQ0KKw0KIAkJZHN0WzJdID0gY3B1X3RvX2xlNjQoc3RydGFiKTsNCiANCi0J CWRzdFszXSA9IGNwdV90b19sZTY0KHMyX2NmZy0+dnR0YnIgJiBTVFJUQUJfU1RFXzNfUzJUVEJf TUFTSyk7DQorCQlkc3RbM10gPSBjcHVfdG9fbGU2NCh2dHRicik7DQogDQogCQl2YWwgfD0gRklF TERfUFJFUChTVFJUQUJfU1RFXzBfQ0ZHLCBTVFJUQUJfU1RFXzBfQ0ZHX1MyX1RSQU5TKTsNCisJ fSBlbHNlIHsNCisJCWRzdFsyXSA9IDA7DQorCQlkc3RbM10gPSAwOw0KIAl9DQogDQogCWlmICht YXN0ZXItPmF0c19lbmFibGVkKQ0KQEAgLTEyNTQsOCArMTMxNSwxNiBAQCBzdGF0aWMgaW50IGFy bV9zbW11X2RvbWFpbl9maW5hbGlzZShzdHJ1Y3QgaW9tbXVfZG9tYWluICpkb21haW4sDQogew0K IAlpbnQgcmV0Ow0KIAlzdHJ1Y3QgYXJtX3NtbXVfZG9tYWluICpzbW11X2RvbWFpbiA9IHRvX3Nt bXVfZG9tYWluKGRvbWFpbik7DQorCXN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKnNtbXUgPSBzbW11 X2RvbWFpbi0+c21tdTsNCisNCisJaWYgKCEoc21tdS0+ZmVhdHVyZXMgJiBBUk1fU01NVV9GRUFU X1RSQU5TX1MyKSkNCisJCXJldHVybiAwOw0KIA0KLQkvKiBSZXN0cmljdCB0aGUgc3RhZ2UgdG8g d2hhdCB3ZSBjYW4gYWN0dWFsbHkgc3VwcG9ydCAqLw0KKwkvKg0KKwkgKiBEZWZhdWx0IHRvIHN0 YWdlLTIgc3VwcG9ydCBhbmQgaW5pdGlhbGl6ZSBpdC4gU3RhZ2UtMSB3aWxsIGJlDQorCSAqIGlu aXRpYWxpemVkIGR1cmluZyBndWVzdCBjb25maWcgYXR0YWNobWVudCwgaWYgbmVzdGVkIG9yIHN0 YWdlLTENCisJICogbW9kZSBpcyByZXF1aXJlZA0KKwkgKi8NCiAJc21tdV9kb21haW4tPnN0YWdl ID0gQVJNX1NNTVVfRE9NQUlOX1MyOw0KIA0KIAlyZXQgPSBhcm1fc21tdV9kb21haW5fZmluYWxp c2VfczIoc21tdV9kb21haW4sIG1hc3Rlcik7DQpAQCAtMjM5OCwxMSArMjQ2NywxNCBAQCBzdGF0 aWMgaW50IGFybV9zbW11X2RldmljZV9od19wcm9iZShzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpz bW11KQ0KIAkJYnJlYWs7DQogCX0NCiANCisJaWYgKHJlZyAmIElEUjBfUzFQKQ0KKwkJc21tdS0+ ZmVhdHVyZXMgfD0gQVJNX1NNTVVfRkVBVF9UUkFOU19TMTsNCisNCiAJaWYgKHJlZyAmIElEUjBf UzJQKQ0KIAkJc21tdS0+ZmVhdHVyZXMgfD0gQVJNX1NNTVVfRkVBVF9UUkFOU19TMjsNCiANCi0J aWYgKCEocmVnICYgSURSMF9TMlApKSB7DQotCQlkZXZfZXJyKHNtbXUtPmRldiwgIm5vIHN0YWdl LTIgdHJhbnNsYXRpb24gc3VwcG9ydCFcbiIpOw0KKwlpZiAoIShyZWcgJiAoSURSMF9TMVAgfCBJ RFIwX1MyUCkpKSB7DQorCQlkZXZfZXJyKHNtbXUtPmRldiwgIm5vIHRyYW5zbGF0aW9uIHN1cHBv cnQhXG4iKTsNCiAJCXJldHVybiAtRU5YSU87DQogCX0NCiANCmRpZmYgLS1naXQgYS94ZW4vZHJp dmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5oIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gv YXJtL3NtbXUtdjMuaA0KaW5kZXggYWIxZjI5ZjZjNy4uZTI1N2RlNmRiOSAxMDA2NDQNCi0tLSBh L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmgNCisrKyBiL3hlbi9kcml2ZXJz L3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmgNCkBAIC0xOTcsNiArMTk3LDcgQEANCiAjZGVmaW5l IFNUUlRBQl9TVEVfMF9DRkdfQllQQVNTCQk0DQogI2RlZmluZSBTVFJUQUJfU1RFXzBfQ0ZHX1Mx X1RSQU5TCTUNCiAjZGVmaW5lIFNUUlRBQl9TVEVfMF9DRkdfUzJfVFJBTlMJNg0KKyNkZWZpbmUg U1RSVEFCX1NURV8wX0NGR19ORVNURUQJCTcNCiANCiAjZGVmaW5lIFNUUlRBQl9TVEVfMF9TMUZN VAkJR0VOTUFTS19VTEwoNSwgNCkNCiAjZGVmaW5lIFNUUlRBQl9TVEVfMF9TMUZNVF9MSU5FQVIJ MA0KQEAgLTU0OSw2ICs1NTAsMTIgQEAgc3RydWN0IGFybV9zbW11X3N0cnRhYl9sMV9kZXNjIHsN CiAJZG1hX2FkZHJfdAkJCWwycHRyX2RtYTsNCiB9Ow0KIA0KK3N0cnVjdCBhcm1fc21tdV9zMV9j Zmcgew0KKwl1NjQJCQkJczFjdHhwdHI7DQorCXU4CQkJCXMxZm10Ow0KKwl1OAkJCQlzMWNkbWF4 Ow0KK307DQorDQogc3RydWN0IGFybV9zbW11X3MyX2NmZyB7DQogCXUxNgkJCQl2bWlkOw0KIAl1 NjQJCQkJdnR0YnI7DQpAQCAtNjY5LDYgKzY3Niw4IEBAIHN0cnVjdCBhcm1fc21tdV9kb21haW4g ew0KIAlhdG9taWNfdAkJCW5yX2F0c19tYXN0ZXJzOw0KIA0KIAllbnVtIGFybV9zbW11X2RvbWFp bl9zdGFnZQlzdGFnZTsNCisJYm9vbAkJCWFib3J0Ow0KKwlzdHJ1Y3QgYXJtX3NtbXVfczFfY2Zn CXMxX2NmZzsNCiAJc3RydWN0IGFybV9zbW11X3MyX2NmZwlzMl9jZmc7DQogDQogCS8qIFhlbiBk b21haW4gYXNzb2NpYXRlZCB3aXRoIHRoaXMgU01NVSBkb21haW4gKi8NCi0tIA0KMi40My4wDQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441812.1659331 (Exim 4.92) (envelope-from ) id 1xEFBJ-0007xB-31; Wed, 07 Oct 2026 00:06:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441812.1659331; Wed, 07 Oct 2026 00:06: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 1xEFBJ-0007x4-0E; Wed, 07 Oct 2026 00:06:49 +0000 Received: by outflank-mailman (input) for mailman id 1441812; Wed, 07 Oct 2026 00:06:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBH-0007vo-CE for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBG-00HHQD-PA for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:46 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58cfa-8faa-0a2a0a5109dd-0a2a4509c6b0-22 for ; Wed, 07 Oct 2026 02:06:46 +0200 Received: from [52.101.70.110] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d16-be1a-0a2a45090019-3465466ed6be-3 for ; Wed, 07 Oct 2026 02:06:46 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:44 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=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=SwOawrtHUkIw5W50HiOpUyICniTOKTal302ni152Fp9JbJp9Tb0VQyLz00FI4Jyvzrd87RO7rleLTBvgJSM84mvCVsZMFT1iarxOBB+25MMgEaaXoqseLJJ9aWUmGOr6Rs3tT7qzZpGvk1CqU3iWA4ZFHOvLjxlDyHAoOtf7UJpnRtWA3yat/bbE2y0YyWydnvra/B7476KCZplK57CluxWvKB9k5PTatcQJ/6fHjB1UlHGXyv102nQTuYRhrirbLsveV5wxQh/rBPfRy/nt2NOEnRQs4iOPqF6Qr32P4ivZNBl7ypBf1k2jVQy7weBw6O9MHZUzAafMq0JgW+GYpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t5uw3+PZK1x4AE2vbC6jzc6Fds0StjgaUR1yhHZVSTk=; b=iUf7Lc2Xi2rApR86/JFEA3Z6Zr3A9JTcoFLv1nDLaTM1I0yifhhIMRiCYtIdS90xoKdLQGWnG/JzivEJsIl79KOlmJM+6+hHLlmUmY8dtpGlXt4GSuUb0i0tgMR2eks5xq83EFZDlNCpT9T1otdgqvRl50z/54DUUrG2jq7EsKCvNfxB/uo01aEo5rJprtiormzE+9oEoxzbJlf0FVCT2rNfTlGjrt3QMb82N7HdQMXXTDa5PSFrft26C15xkRAdOcgAkGbMgPW9uAmXQnX+r7/hKDVQkkfoUzukRHhvR4DSr/jJO293TSr6yjr8ts9BNFXU6bFqlPUHSQlRC7Xs8w== 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=t5uw3+PZK1x4AE2vbC6jzc6Fds0StjgaUR1yhHZVSTk=; b=bQ9v2+40FzDAvaeKWDsZi3l913Q0RLefAX6Cf97QNqY8O2qowUjSNeNHjzBVQ0QcW8Kx6dY7pWMpOh5zXVGj5cqq7SYtd3skj7GS8mKRurX3uI76/N+7uYdh3wRN6Bqq6WrIS+EkRHir0CjJ40JUghcDrEtqMKSLEw38etUmAfPdcrJTpDdYERjkonht2JpYwNL9TRAja9CgpInpBkLOsLY8L1Wr6i08fmrMq6HGmBX0qZPAV7+OzgVofVtvtzalTbxRZpOY0FTYxUidkRtZlkRw9E4Ba5dKyDZcFU3XcZbWfNlH6jq4veyBaMvpW6YLoPQWe7e5R8PvM24sVzEMig== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Bertrand Marquis , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 03/22] xen/arm: smmuv3: Alloc io_domain for each device Thread-Topic: [PATCH v4 03/22] xen/arm: smmuv3: Alloc io_domain for each device Thread-Index: AQHdVe+9NDppc5gYoUqPmrNkiw396g== Date: Wed, 7 Oct 2026 00:06:44 +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: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 2fe88597-e791-4e9e-3563-08df2406df82 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: WyVAe6HItfkL8OQfkcr6H9nrz1MrVHZJVc34M9xMgA5io9YBptW8rmA49kgxo+/uwPxqCBh3T/iFTPUuklIM6KgEkWRvoRxLWHjQrU0CJTTE5hhr+DifVrDRt+lXv18utOEJydo4voCsNt8RTC3Acu/mFFrZ3xDsr/YyU9n7osMz1ONClmNIW+e4hjuXd7HVWN62vpN6YN/XsofwKu73FwD5z7FqBPj7MEKPko2uKS230o5gA77ot1fUcZw2GAfrnrhBUOBzRscBUOmZwfKLvbMXRZYrjTrnYn9D/eenvCyzvmbywH3BJ3m3KUDgZ6cTYJcJRQvOFLBYVHUY3A3gEcsQArpsDXrRQmCAyBV9Y5bWPX3NjSvp9a+MxFpoc3F/PZGQ5sm60I6aoz7LSYh8zTXOY2ofnb3oikisMqQEV9WBuCPCUso4ELRBajFPNvKSIGew+Ld+0dgkwAb0WdpsuWl9RpFn9594dOGq0wPGG08dpa0mURU3r6bcrSY7s8DBwJwL+p0xk+2XbGVNWp3v2uEuSI500k7cGPFgzqr1qAYJKcdv1WahqXRaLH8mpaWcuOXxntyk4mkQkhBzkj9d30+XvPtblxBlh6Knu/0WY6bZ/JEYAu59+AUEZ9nOGq2R0yGGg+SflfR1M/tSx4gujOvkgeSHo+/uzsA/uDHuvpB3X6WFpPtV5TCu01/xN7WEP4+l9FX/+MSD2jE3MgCSEWhbpG91xFxbW37ayWiodoM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UVFRdWkrTDBISm5VNnp6dm9kY3p5NVEzclhDdmZVdm5pYm9SeTRWNUxHRWdx?= =?utf-8?B?WkZBQk9kU0NQQlRYTTlSVm5JcmpZTWFORFNOQXp6VzNYUWFQSGkrTVpzMlF0?= =?utf-8?B?T3lQMEd2T2dCaFhnakFrd001aTdxbkRWdEFWbmVXN1JxbVczOURBVzZLb0dy?= =?utf-8?B?ek5ZV3o2SHJoaUNKdHAyekVJbFpIaHgvWEttR2U2dXlORC9ka1ljdEtzMkt3?= =?utf-8?B?S0lRWmdBSFhaVDBkMHArQXB3TmtPWEpCVkh6NURHZEtHS2pMWFpiZmdLdjd1?= =?utf-8?B?V1A2YjN2SGUxcnJXUkVoRXNnT3RSUHhVLzlsc1NSaElSTmN2dnFnbk8raFVi?= =?utf-8?B?dFMxd2tiajlVMFNIckphOC9OcFBhMGVOVjJlMnBnQUhFMGladzB3ZVFaeVpX?= =?utf-8?B?clM5Y204MG9LcWJ6K002N0k5UGtWOUJqbVl0SHdzV0kzRHRkZVBWbjQ1Q2s2?= =?utf-8?B?Z1pSVlpRWmxKUnVXNmpzM2pqaUdJTUE3YXlBNjByMU81d0RCVDNQWnFtSE12?= =?utf-8?B?ZHk1L1pBVVh2NmFrRzlPZVpKclpORWFQbkJsWFRsWUNQYkl4MGhOZzdCODZZ?= =?utf-8?B?a1VLUlZXZ2Juc2xQMXAreG9vTHloMytJMXRWTUpiVU1VUHNMbUJuVVdBMmZs?= =?utf-8?B?VEVUWDh5WXo0aXlaZ3p4bklYVXdQN1hzVGNRakppWktPZ0JqazRtdkRNblAr?= =?utf-8?B?UjErdXFHbnFzWmJQWWE2dDQvaVVCOS9pNmlyU051Vm9uOVRveFlxQUtnRm5F?= =?utf-8?B?MjMwbG9ZKzVEVzFlSjJqMm1WOHExZklwc2xhZVVTRHJOWFowQTVEM0xmM3Fi?= =?utf-8?B?NWl1VjNSTVZOUkp3akpXdG85NlQzZWppSUkyWHZwcG9OODdOMWVSZkcrdHY3?= =?utf-8?B?UXFlUFBaeHEzN2wwaVZoYndiREwvQXVmS2pCTFVkN283ek5laXBqMlE3Tmp3?= =?utf-8?B?M3VkeDlqTW5xZTlNdDcvOUFVdkdmY2JtUnkxZXRTYjhkTThSVXZ1UnRyRGN4?= =?utf-8?B?dVVmMXFaRjQ4enlwYzJ3WlVvenFiQVVGQ1VxMXVLaXdQMW5ESUY3djA4OFRF?= =?utf-8?B?ZVZzVTRWcWhmL1dqY1pBYkkvdk5NQkdybTdoNCt4L01NTUlWZ094dnZMbGNY?= =?utf-8?B?S2piUGRzSXRzOS9EUE50azUxblgzeEtkMTNHeTVmbWI5Z2k2SHNYSHNYUDBk?= =?utf-8?B?amdSSDVkVFR1QWF5RE9zVnBHWmtVNGxaQzRxYmdmZmZnRWxJakZvS3g4ZmtJ?= =?utf-8?B?ME5QdDJkdEZtUnFnK0RsVUlZWUdrUUlCTmFMS0MyNHJ2M29scjFOQ1dTamc1?= =?utf-8?B?Rm4vMXRTdUE2ZW8wZzRKcG1PMWoyUkV4TVl4clRnME5ZQ0RoTlAvRUZsODN6?= =?utf-8?B?dnBUUDRtRFpIazdPQVpIckVTWmFQNlVQekltZlR4K3lQcENHdzY4Njdyc2ha?= =?utf-8?B?cFdNcndJOTI3UzZ6SEJsclNvU2p3cTM3NlJBRFhNcUdqUkxVOHBDTkNTSElv?= =?utf-8?B?QW1uaHJsczJQeHFoWTlNNjFFemhoSENmdGJ0QkJUS0xEQngwdVY3N1k5dlcw?= =?utf-8?B?OVNpb3h4U2FCTE1qbW15M0ZtMGRYTUt6dzZtcUF1R1hpV0tCU3ltY3oxL2Uw?= =?utf-8?B?SzRYSy9vRzdpemVrZHJUZUdiamJ0dU1DcldqQ01GZlNYS3JwYWpSU25mdmx3?= =?utf-8?B?NEM2K2xzUG1ZZ0Ivc1JNcWxNR2xuWlNwY2pjVVZlMlErbUd3V2NzWEM1Qzls?= =?utf-8?B?QXd4M0t0ZlhMUVB3ZldLcE5YUElaUU5lRFlIYjQxaGxtb1pDQVNBeTlaVjAw?= =?utf-8?B?eXZ3NXhidyt4VnRtTFE4UE8zY3oxbUFRblpMa29yUEJtSUc0SzBIRHRBZGFE?= =?utf-8?B?QmxSVFlVbUJkQW0yUEo4RnZ4RHhEVHZSc3hYZTJyRVFOdVB6WnJ4RlgwR1Ay?= =?utf-8?B?dnRwam1vb3VsblRoRFZ3NWpGQ3N1N3YwUm9EUXNRc0VRYUUvUHRGUHptcG1D?= =?utf-8?B?REVLWG9NelpOVDdlbXNCMnVhdU9yOW5Jbmo0ZVlNQ3dwMTRUZFVlait3VmUz?= =?utf-8?B?bGw1RE8wVVFYdUtMd0NjR1gvVkpIQzZSazdKekpDQ29RZHJXOUtHT1dZTGZ1?= =?utf-8?B?bjg2Mm1XZ3R5d040eUVWeUwxWlNReG4xaGxxOHpVd0R3K01leUowcDJxMjAy?= =?utf-8?B?WFhoWGc0NCtNcmpyZjhha0VIeXljMXFZaVZ5QVRLMWdzbU9jck9QMGRyeVh3?= =?utf-8?B?cTRxOWZoRTRuekp3cEhuNm9uckllNm1razZNc2o5SVV0VjgvaUZWZWYveTZn?= =?utf-8?B?L0I2VzZxZEphNzc3cXUyU0dNYTJkaEFyRWRUZy8rVXVPbEhNRUZiQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2fe88597-e791-4e9e-3563-08df2406df82 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:44.7617 (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: dULlYYKIK/f4PPYwfifnGUTjVhUNTXk+uKcd0wJLD30AEW44L1/kj1EogjROESpqM5dBtcNi7bIVoZHPSp+Fcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-bad1c0/1791331606-BE6DA034-958D5176/0/0 X-purgate-type: clean X-purgate-size: 8552 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkluIGN1cnJlbnQgaW1w bGVtZW50YXRpb24gaW9fZG9tYWluIGlzIGFsbG9jYXRlZCBvbmNlIGZvciBlYWNoIHhlbg0KZG9t YWluIGFzIFN0YWdlMiB0cmFuc2xhdGlvbiBpcyBjb21tb24gZm9yIGFsbCBkZXZpY2VzIGluIHNh bWUgeGVuDQpkb21haW4uDQoNCk5lc3RlZCBzdGFnZSBzdXBwb3J0cyBTMSBhbmQgUzIgY29uZmln dXJhdGlvbiBhdCB0aGUgc2FtZSB0aW1lLiBTdGFnZTENCnRyYW5zbGF0aW9uIHdpbGwgYmUgZGlm ZmVyZW50IGZvciBlYWNoIGRldmljZSBhcyBsaW51eCBrZXJuZWwgd2lsbA0KYWxsb2NhdGUgcGFn ZS10YWJsZSBmb3IgZWFjaCBkZXZpY2UuDQoNCkFsbG9jIGlvX2RvbWFpbiBmb3IgZWFjaCBkZXZp Y2Ugc28gdGhhdCBlYWNoIGRldmljZSBjYW4gaGF2ZSBkaWZmZXJlbnQNClN0YWdlLTEgYW5kIFN0 YWdlLTIgY29uZmlndXJhdGlvbiBzdHJ1Y3R1cmUuDQoNClRoZSBzdGFnZS0yIGNvbmZpZ3VyYXRp b24gaXMgbm93IHNoYXJlZCBiZXR3ZWVuIGRldmljZXMgYmVsb25naW5nIHRvDQp0aGUgc2FtZSBk b21haW4uIFVwZGF0ZSBpb19kb21haW4gaW5pdGlhbGl6YXRpb24gdG8gY3JlYXRlIGEgbmV3IHN0 YWdlLTINCmNvbmZpZ3VyYXRpb24gb25seSBpZiBhIFZNSUQgaGFzIG5vdCBhbHJlYWR5IGJlZW4g YWxsb2NhdGVkIGZvciB0aGUNCnRhcmdldCBYZW4gZG9tYWluLiBTaW1pbGFybHksIHVwZGF0ZSBp b19kb21haW4gdGVhcmRvd24gdG8gZnJlZSB0aGUNClZNSUQgb25seSB3aGVuIG5vIG90aGVyIGRl dmljZXMgYXJlIGFzc2lnbmVkIHRvIHRoZSB0YXJnZXQgZG9tYWluLg0KQWxzbyBvcHRpbWl6ZSB0 aGUgSU9UTEIgZmx1c2ggcHJvY2VkdXJlIHRvIGludmFsaWRhdGUgZWFjaCBWTUlEIG9ubHkNCm9u Y2UuDQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxyYWh1bC5zaW5naEBhcm0uY29tPg0K U2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBhbS5jb20+DQotLS0N CiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jIHwgMTAyICsrKysrKysrKysr KysrKysrKysrKysrKy0tDQogMSBmaWxlIGNoYW5nZWQsIDk0IGluc2VydGlvbnMoKyksIDggZGVs ZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21t dS12My5jIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYw0KaW5kZXggZDNl ODhkNWE1NS4uYmQwNjg5NjY0YiAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo L2FybS9zbW11LXYzLmMNCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYz LmMNCkBAIC0xMjI5LDE0ICsxMjI5LDQ5IEBAIHN0YXRpYyB2b2lkIGFybV9zbW11X2JpdG1hcF9m cmVlKHVuc2lnbmVkIGxvbmcgKm1hcCwgaW50IGlkeCkNCiAJY2xlYXJfYml0KGlkeCwgbWFwKTsN CiB9DQogDQorc3RhdGljIHN0cnVjdCBhcm1fc21tdV9kb21haW4gKmFybV9zbW11X2dldF9kb21h aW5fczIoc3RydWN0IGRvbWFpbiAqZCwNCisJCQkJc3RydWN0IGFybV9zbW11X2RldmljZSAqc21t dSkNCit7DQorCXN0cnVjdCBpb21tdV9kb21haW4gKmlvX2RvbWFpbjsNCisJc3RydWN0IGFybV9z bW11X2RvbWFpbiAqc21tdV9kb21haW47DQorCXN0cnVjdCBhcm1fc21tdV94ZW5fZG9tYWluICp4 ZW5fZG9tYWluID0gZG9tX2lvbW11KGQpLT5hcmNoLnByaXY7DQorDQorCWlmICghc21tdSkNCisJ CXJldHVybiBOVUxMOw0KKw0KKwkvKg0KKwkgKiBMb29wIHRocm91Z2ggdGhlICZ4ZW5fZG9tYWlu LT5jb250ZXh0cyB0byBsb2NhdGUgYSBjb250ZXh0DQorCSAqIGFzc2lnbmVkIHRvIHRoaXMgU01N VQ0KKwkgKi8NCisJbGlzdF9mb3JfZWFjaF9lbnRyeShpb19kb21haW4sICZ4ZW5fZG9tYWluLT5j b250ZXh0cywgbGlzdCkgew0KKwkJc21tdV9kb21haW4gPSB0b19zbW11X2RvbWFpbihpb19kb21h aW4pOw0KKwkJaWYgKHNtbXVfZG9tYWluLT5zbW11ID09IHNtbXUgJiYNCisJCQlzbW11X2RvbWFp bi0+czJfY2ZnLnZtaWQgIT0gSU5WQUxJRF9WTUlEKQ0KKwkJCQlyZXR1cm4gc21tdV9kb21haW47 DQorCX0NCisNCisJcmV0dXJuIE5VTEw7DQorfQ0KKw0KIHN0YXRpYyB2b2lkIGFybV9zbW11X2Rv bWFpbl9mcmVlKHN0cnVjdCBpb21tdV9kb21haW4gKmRvbWFpbikNCiB7DQogCXN0cnVjdCBhcm1f c21tdV9kb21haW4gKnNtbXVfZG9tYWluID0gdG9fc21tdV9kb21haW4oZG9tYWluKTsNCiAJc3Ry dWN0IGFybV9zbW11X2RldmljZSAqc21tdSA9IHNtbXVfZG9tYWluLT5zbW11Ow0KIAlzdHJ1Y3Qg YXJtX3NtbXVfczJfY2ZnICpjZmcgPSAmc21tdV9kb21haW4tPnMyX2NmZzsNCisJc3RydWN0IGFy bV9zbW11X2RvbWFpbiAqZXhpc3Rpbmc7DQogDQotCWlmIChjZmctPnZtaWQpDQotCQlhcm1fc21t dV9iaXRtYXBfZnJlZShzbW11LT52bWlkX21hcCwgY2ZnLT52bWlkKTsNCisJaWYgKGNmZy0+dm1p ZCkgew0KKwkJLyoNCisJCSAqIFZNSURzIGFyZSBzaGFyZWQgYWNyb3NzIGNvbnRleHRzIGJlbG9u Z2luZyB0byB0aGUgc2FtZQ0KKwkJICogWGVuIGRvbWFpbiBhbmQgU01NVS4gVGhlIGN1cnJlbnQg ZG9tYWluIGhhcyBhbHJlYWR5IGJlZW4NCisJCSAqIHJlbW92ZWQgZnJvbSB0aGUgZG9tYWluIGxp c3QsIHNvIHRoaXMgbG9va3VwIG9ubHkgZmluZHMNCisJCSAqIHJlbWFpbmluZyB1c2VycyBvZiB0 aGUgVk1JRC4NCisJCSAqLw0KKwkJZXhpc3RpbmcgPSBhcm1fc21tdV9nZXRfZG9tYWluX3MyKHNt bXVfZG9tYWluLT5kLCBzbW11KTsNCisNCisJCWlmICghZXhpc3RpbmcpDQorCQkJYXJtX3NtbXVf Yml0bWFwX2ZyZWUoc21tdS0+dm1pZF9tYXAsIGNmZy0+dm1pZCk7DQorCX0NCiANCiAJeGZyZWUo c21tdV9kb21haW4pOw0KIH0NCkBAIC0xMzE2LDYgKzEzNTEsNyBAQCBzdGF0aWMgaW50IGFybV9z bW11X2RvbWFpbl9maW5hbGlzZShzdHJ1Y3QgaW9tbXVfZG9tYWluICpkb21haW4sDQogCWludCBy ZXQ7DQogCXN0cnVjdCBhcm1fc21tdV9kb21haW4gKnNtbXVfZG9tYWluID0gdG9fc21tdV9kb21h aW4oZG9tYWluKTsNCiAJc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSA9IHNtbXVfZG9tYWlu LT5zbW11Ow0KKwlzdHJ1Y3QgYXJtX3NtbXVfZG9tYWluICpleGlzdGluZzsNCiANCiAJaWYgKCEo c21tdS0+ZmVhdHVyZXMgJiBBUk1fU01NVV9GRUFUX1RSQU5TX1MyKSkNCiAJCXJldHVybiAwOw0K QEAgLTEzMjcsNiArMTM2MywyNiBAQCBzdGF0aWMgaW50IGFybV9zbW11X2RvbWFpbl9maW5hbGlz ZShzdHJ1Y3QgaW9tbXVfZG9tYWluICpkb21haW4sDQogCSAqLw0KIAlzbW11X2RvbWFpbi0+c3Rh Z2UgPSBBUk1fU01NVV9ET01BSU5fUzI7DQogDQorCS8qDQorCSAqIExvb2sgZm9yIGFuIGFscmVh ZHkgaW5pdGlhbGl6ZWQgc3RhZ2UtMiBjb25maWd1cmF0aW9uIGZvciB0aGlzDQorCSAqIFhlbiBk b21haW4gYW5kIFNNTVUuDQorCSAqLw0KKwlleGlzdGluZyA9IGFybV9zbW11X2dldF9kb21haW5f czIoc21tdV9kb21haW4tPmQsIHNtbXUpOw0KKw0KKwlpZiAoZXhpc3RpbmcpIHsNCisJCS8qDQor CQkgKiBSZXVzZSB0aGUgc3RhZ2UtMiBjb25maWd1cmF0aW9uLg0KKwkJICovDQorCQlzbW11X2Rv bWFpbi0+czJfY2ZnLnZtaWQgPSBleGlzdGluZy0+czJfY2ZnLnZtaWQ7DQorCQlzbW11X2RvbWFp bi0+czJfY2ZnLnZ0dGJyID0gZXhpc3RpbmctPnMyX2NmZy52dHRicjsNCisJCXNtbXVfZG9tYWlu LT5zMl9jZmcudnRjciA9IGV4aXN0aW5nLT5zMl9jZmcudnRjcjsNCisJCXJldHVybiAwOw0KKwl9 DQorDQorCS8qDQorCSAqIElmIG5vIGV4aXN0aW5nIHN0YWdlLTIgY29uZmlndXJhdGlvbiBmb3Ig dGhpcw0KKwkgKiAoWGVuIGRvbWFpbiwgU01NVSksIGNyZWF0ZSBpdA0KKwkgKi8NCiAJcmV0ID0g YXJtX3NtbXVfZG9tYWluX2ZpbmFsaXNlX3MyKHNtbXVfZG9tYWluLCBtYXN0ZXIpOw0KIAlpZiAo cmV0IDwgMCkNCiAJCXJldHVybiByZXQ7DQpAQCAtMjgwNywyMCArMjg2Myw0MCBAQCBzdGF0aWMg dWludDMyX3QgX19yb19hZnRlcl9pbml0IHBsYXRmb3JtX2ZlYXR1cmVzID0gQVJNX1NNTVVfRkVB VF9DT0hFUkVOQ1k7DQogc3RhdGljIGludCBfX211c3RfY2hlY2sgYXJtX3NtbXVfaW90bGJfZmx1 c2hfYWxsKHN0cnVjdCBkb21haW4gKmQpDQogew0KIAlzdHJ1Y3QgYXJtX3NtbXVfeGVuX2RvbWFp biAqeGVuX2RvbWFpbiA9IGRvbV9pb21tdShkKS0+YXJjaC5wcml2Ow0KLQlzdHJ1Y3QgaW9tbXVf ZG9tYWluICppb19kb21haW47DQorCXN0cnVjdCBpb21tdV9kb21haW4gKmlvX2RvbWFpbiwgKnBy ZXY7DQogDQogCXNwaW5fbG9jaygmeGVuX2RvbWFpbi0+bG9jayk7DQogDQogCWxpc3RfZm9yX2Vh Y2hfZW50cnkoaW9fZG9tYWluLCAmeGVuX2RvbWFpbi0+Y29udGV4dHMsIGxpc3QpIHsNCisJCXN0 cnVjdCBhcm1fc21tdV9kb21haW4gKnNtbXVfZG9tYWluID0gdG9fc21tdV9kb21haW4oaW9fZG9t YWluKTsNCisNCiAJCS8qDQogCQkgKiBPbmx5IGludmFsaWRhdGUgdGhlIGNvbnRleHQgd2hlbiBT TU1VIGlzIHByZXNlbnQuDQogCQkgKiBUaGlzIGlzIGJlY2F1c2UgdGhlIGNvbnRleHQgaW5pdGlh bGl6YXRpb24gaXMgZGVsYXllZA0KIAkJICogdW50aWwgYSBtYXN0ZXIgaGFzIGJlZW4gYWRkZWQu DQogCQkgKi8NCi0JCWlmICh1bmxpa2VseSghQUNDRVNTX09OQ0UodG9fc21tdV9kb21haW4oaW9f ZG9tYWluKS0+c21tdSkpKQ0KKwkJaWYgKHVubGlrZWx5KCFBQ0NFU1NfT05DRShzbW11X2RvbWFp bi0+c21tdSkpKQ0KIAkJCWNvbnRpbnVlOw0KIA0KLQkJYXJtX3NtbXVfdGxiX2ludl9jb250ZXh0 KHRvX3NtbXVfZG9tYWluKGlvX2RvbWFpbikpOw0KKwkJLyoNCisJCSAqIFNraXAgY29udGV4dHMg dGhhdCBzaGFyZSB0aGUgc2FtZSBTTU1VIGFuZCBWTUlEIHdpdGggYW4NCisJCSAqIGVhcmxpZXIg Y29udGV4dC4NCisJCSAqLw0KKwkJbGlzdF9mb3JfZWFjaF9lbnRyeShwcmV2LCAmeGVuX2RvbWFp bi0+Y29udGV4dHMsIGxpc3QpIHsNCisJCQlzdHJ1Y3QgYXJtX3NtbXVfZG9tYWluICpwcmV2X2Rv bWFpbiA9IHRvX3NtbXVfZG9tYWluKHByZXYpOw0KKw0KKwkJCWlmIChwcmV2ID09IGlvX2RvbWFp bikNCisJCQkJYnJlYWs7DQorDQorCQkJaWYgKHByZXZfZG9tYWluLT5zbW11ID09IHNtbXVfZG9t YWluLT5zbW11ICYmDQorCQkJCXByZXZfZG9tYWluLT5zMl9jZmcudm1pZCA9PSBzbW11X2RvbWFp bi0+czJfY2ZnLnZtaWQpDQorCQkJCWJyZWFrOw0KKwkJfQ0KKw0KKwkJaWYgKHByZXYgIT0gaW9f ZG9tYWluKQ0KKwkJCWNvbnRpbnVlOw0KKw0KKwkJYXJtX3NtbXVfdGxiX2ludl9jb250ZXh0KHNt bXVfZG9tYWluKTsNCiAJfQ0KIA0KIAlzcGluX3VubG9jaygmeGVuX2RvbWFpbi0+bG9jayk7DQpA QCAtMjg2NiwxMiArMjk0MiwyMiBAQCBzdGF0aWMgc3RydWN0IGlvbW11X2RvbWFpbiAqYXJtX3Nt bXVfZ2V0X2RvbWFpbihzdHJ1Y3QgZG9tYWluICpkLA0KIA0KIAkvKg0KIAkgKiBMb29wIHRocm91 Z2ggdGhlICZ4ZW5fZG9tYWluLT5jb250ZXh0cyB0byBsb2NhdGUgYSBjb250ZXh0DQotCSAqIGFz c2lnbmVkIHRvIHRoaXMgU01NVQ0KKwkgKiBhc3NpZ25lZCB0byB0aGlzIGRldmljZQ0KIAkgKi8N CiAJbGlzdF9mb3JfZWFjaF9lbnRyeShpb19kb21haW4sICZ4ZW5fZG9tYWluLT5jb250ZXh0cywg bGlzdCkgew0KKwkJdW5zaWduZWQgbG9uZyBmbGFnczsNCisJCWNvbnN0IHN0cnVjdCBhcm1fc21t dV9tYXN0ZXIgKm1hc3RlcjsNCisNCiAJCXNtbXVfZG9tYWluID0gdG9fc21tdV9kb21haW4oaW9f ZG9tYWluKTsNCi0JCWlmIChzbW11X2RvbWFpbi0+c21tdSA9PSBzbW11KQ0KLQkJCXJldHVybiBp b19kb21haW47DQorDQorCQlzcGluX2xvY2tfaXJxc2F2ZSgmc21tdV9kb21haW4tPmRldmljZXNf bG9jaywgZmxhZ3MpOw0KKwkJbGlzdF9mb3JfZWFjaF9lbnRyeShtYXN0ZXIsICZzbW11X2RvbWFp bi0+ZGV2aWNlcywgZG9tYWluX2hlYWQpIHsNCisJCQlpZiAobWFzdGVyLT5kZXYgPT0gZGV2KSB7 DQorCQkJCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnNtbXVfZG9tYWluLT5kZXZpY2VzX2xvY2ss IGZsYWdzKTsNCisJCQkJcmV0dXJuIGlvX2RvbWFpbjsNCisJCQl9DQorCQl9DQorCQlzcGluX3Vu bG9ja19pcnFyZXN0b3JlKCZzbW11X2RvbWFpbi0+ZGV2aWNlc19sb2NrLCBmbGFncyk7DQogCX0N CiAJcmV0dXJuIE5VTEw7DQogfQ0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441814.1659342 (Exim 4.92) (envelope-from ) id 1xEFBM-0008Fj-Ex; Wed, 07 Oct 2026 00:06:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441814.1659342; Wed, 07 Oct 2026 00:06: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 1xEFBM-0008Fa-A1; Wed, 07 Oct 2026 00:06:52 +0000 Received: by outflank-mailman (input) for mailman id 1441814; Wed, 07 Oct 2026 00:06:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBK-0008Dh-T7 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBK-000T4z-9z for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:50 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d03-2eae-0a2a0a5409dd-0a2a4504d466-12 for ; Wed, 07 Oct 2026 02:06:50 +0200 Received: from [40.107.159.131] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d19-b57f-0a2a45040019-286b9f831ebe-3 for ; Wed, 07 Oct 2026 02:06:50 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:48 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=CSJgF/82Bqb4PycJu8Jq1Hk8q/pT1JahavhxWXEemsWsb3ZkQy+27vFG10WTDsYqzkS6mQ7WId5ipAjgG1W9mkFWDUBRFCRFb8yKzi1BTD17LzUErxt/fU3TgjVLsano/4Q6+04a485Wo9ypisBj+EDRVEZJXsC+ktLdxYAac5vTl84etv76v6GcQ2gUTViN3Po9+/oFLgeeFbG1QZsOzDCaUszj5XjxLJteJY6nffqFAQ9FRna4m5Eb8bmy0NJe2M2b7p4k4nJ1uXeBIWd5Ib7xyoyWLRPuPA8vcSa9cOca4fFao79UaFt9yrcBWnutUQcccT7aFFagBuA8iMz3Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iz9sdLiJeBzvpMt8ANDHHNViI22pDvGuG8DtxZkJePI=; b=wRzkg51Gvybb6xF5ngUlo9FKqsGrppLssEfmY5OaklgAOWLxQbmuE0KRfEnnp5SwEraXfIG5esmw6s1hWn6jpVZQXUIe5K9WB453AhK3/R+IJyCs1ZIG02dWaVzpymB6ztnSDGoJrrF3Jw/srKpb62C3FN7l+0STCx7v2CGZQFdHHTtfv/EC90gu5qL3N/PbSMgsKFF7SwKbNTp3xB2K0hsVYIEXuc4NE9sN+O1ITcmPcRu9G1k7V9/rrkLvSMZDIZkCeCivrrN/0115RQwF14K885XV1ezpZelvXVqAZQzCHym1Xm1WWWBJMEhDL2Fy1ae6A+9hlwb54fWFU/fagA== 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=iz9sdLiJeBzvpMt8ANDHHNViI22pDvGuG8DtxZkJePI=; b=fwnX6DzTbYtSwqfErebWnGemjgvxbqHIqXG5YQPQ0/Z7AuPjiBtELv7csgFyvLs7oqs/sVtoyGSJVtLRS9VGCPdpeU1OKaf95PxvxU5Kk6FXwOy6kfM0CreahvLUyA/gMe9Mmj8ga/f/S7si0kUvmf2Mp1gArdrDPcCHLQW6IimSq0QlQJp6sIIV5HVPEii9cgtO6+XPk30m2JlXyqxUs4G9xpU3myaTlm7H0K4bQq0pIxq3AE4ZSSYY0vpzaVziHjEz5eW2f+N+t2IGWXStmjjzX5pP382XCj0/tod5DUeIuejFsKilFY4FGniHAW7cVKd8B80Kv0KEOh2wjGSU2Q== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Milan Djokic Subject: [PATCH v4 04/22] xen/arm: vIOMMU: add generic vIOMMU framework Thread-Topic: [PATCH v4 04/22] xen/arm: vIOMMU: add generic vIOMMU framework Thread-Index: AQHdVe+/Rs/TPiRUCECv1s0B4eCIQw== Date: Wed, 7 Oct 2026 00:06:48 +0000 Message-ID: <6c7570f50af7ebaae8aa709db86959dbd09e1f82.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: a2f1e8a0-01fe-48ba-4788-08df2406e1a7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|260925022911599003|56012099006|260925021911599003|11063799006|10067099003|260925021311599003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: nDuztJVSxIL1w0vhV9ayFa+xPGJWHRNkrBOBCLe15txkvMPVXOeTJaxuFbxCf6k/MXbfQUlLMwaFA0yXkH9Qj3h/kbIdF1BlEJVx22DSgHaGtq/eUeSA3GWhVeXslk1QJzMRvW22akVHaMk6+vFy71UhH5bj9t/iXDLbWOnDGdyZc67lEoHEezKkL18a++NCW3ewvEG3qx5mmijH4zMmTHcF5m+xJeeUxlv1mA1nihx8t279c7LrCk7DQY2yPkXoizVy8d4Lal+h59E4RYlsTbE/GKSZTP4Jmk7hQvCO6+cf9xacMCZr4+0/7aVsCN5qN19g+GXjifJe9GYXKIP3vUacnQFKjITyzSk6eHzH7am5OEQt0FwiDMI/fzY2ydyccDglmFQtc7UtQizPOPcWl+JxQ++houc8s5WKstEDuS5YI1iOYkG4GKyL+DTedi+CE+9KnR5S1whVwjihhPFvGuoUCGvT4/U3VlEX+mrmap0CfKLL9RHHEylv5rvrh6rT+YzvOVq6rZtYNyT0mqVsmJO+HI1fvopX9ZDYc3fIkM5tpGDMwFejd+9ehL/hxg7peX3X5onAfZCdnpQirL2m7YeKTXXf9Q5jfdWBLh6BcwJVSfvAI2JgHCNrzgiO+5cMG7sRK0PnfvisAI4prlIj4G6vO5zRmdMmxUOY1FZn441mZlk1jRPe87q7aR3ryKGcwRzdLU1+00S/4tFj1IN6koHcLmxndaukHbWEMkR7tNw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(260925022911599003)(56012099006)(260925021911599003)(11063799006)(10067099003)(260925021311599003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WVZIYU9GMnZuNDZ1WjV1Wmg3czJTYWRISkZTaExmTWFQd0kzckpTK2FsRDdo?= =?utf-8?B?QVVYYzNBR25oNTVic0VwejcvM2loc2d0SXpHTTdzSHNiUmdlOUNqTFdLby9T?= =?utf-8?B?Mmo5QVIzVm5yYnNoV29ySjlRZnltbGZMdHBPajE3b3QzKzRNMU5OOGJJcGxG?= =?utf-8?B?T0M5WjY0NklzNkZNYVFncy9nc1I5R1Q1NHlKOUVYdWwwczJmVCtQdmJ6T2Zw?= =?utf-8?B?ZkxmNWRINjZ6RUFxbnVacDFSeHlFdDhQdkhXRXk1L2ZrdGNFMFJIbUZ1cVFv?= =?utf-8?B?N2htcUppSWRENklFMWpBeEExWGFNTGpCQjMwOFVmOEJ6SHU0bTQxcWlEM2Jo?= =?utf-8?B?WTF1MFFQOUx0SytpYTdyMFMyeXZ4bGEyTmVFbnRwSXM2blJJTkZUUkV2U3gy?= =?utf-8?B?eTNzdCtra2RhZTlKWFk3K2UvU05VbkN5U3RwcExUYUpOci9kYUlQYTVhbnV2?= =?utf-8?B?ckZPRlBRUDFSbVY5b25hbDBJTFZGaXI0NU9WYzdUV1VNdlJBOGZJbzhqeDlQ?= =?utf-8?B?MWRpdUQxclF0RHFyZjlQNXNDRUlEMkIwclErMnMwbGpIcGh6ZHQ0WXd6NVVQ?= =?utf-8?B?dzRUZEZGT3NpUGhWc3UzRkxVeXB0dXJadG1ib1RMSGtPVm1EdTZ4My9ZL3Zk?= =?utf-8?B?cVV2bmNBQ3lnRWhPQi84TUFPTmN6RlEvNVk0UHkvN0t6VEpSaHh2d28vMTdX?= =?utf-8?B?Y3U5MU1mcE40Q1hKRFIreTB5dG1QQms0bS9waldaUnNzYWFzcnJncDViRGFD?= =?utf-8?B?UVBndkxnL01nRW14TmdMcks1K0dkNkY5U3ZBSnkwRG8yVVpDblVBdTdsZ2RS?= =?utf-8?B?eWp3SzZaYlduVTlmNU5uaHRRUWtjamVzVGR0THM3VU5hQ3BjRzAwVVVWTUxU?= =?utf-8?B?TUlFN0J0dFBnTE9UMzZFM1lNMFBsQjZEaUVrblB3NitsVHgzVVBhMTZvNmVz?= =?utf-8?B?ZFA0SHZGNFN5U3grWjZuUm9HalNtaEJ5R0xRZ1NhS1BrUEhaTklVVEdPRlNR?= =?utf-8?B?WDVxSkhpZ3BObWpGUU1VNGlVT2s4dzNOVXdKUFNTUzB2SkMySzdXRTFsQVdu?= =?utf-8?B?TG1VRXp2aW9vMUtlZW5kcVNkN0FDTjJ4VkNGUjBDY2tPMEszMXpZeHFOcXlD?= =?utf-8?B?TkNlTXNoY0JLa3dWZVdic08yWXEyWVdwL2NNTXIyT2gzR2VUdDlHZXVqdDNp?= =?utf-8?B?ekpaMHU0RzJmSitTV0dKZmhPR0dqYXNrV2VqM2JCa01sZit3RXF6c29PanAv?= =?utf-8?B?YzByL0ppN2lQY2dUR1B0S21pUkxudUZkQjNUNmc2cjRyR29WZitCQXZ3T2cy?= =?utf-8?B?eEprMXpObFNnNUROVlVtRmxYNkZBajhvVlJkSTVmS1BaNFhUU0tvMlViK3RV?= =?utf-8?B?WnBuZlk4V1lvbFV2N3pVNWo2ZTNkN3hsSXVWNzR3c1Vpd0VUZWVaWVBqYXc0?= =?utf-8?B?OWtNVlJQTStEcGgzU0VKeElFR2xDdkUreUt0eS9mOGEvUFpsRGVwVGs1bFJr?= =?utf-8?B?RmF4ZmwzSFpNRHlXbkJJbXBVOUJpaktJQkdLMzFQWVY1R2VObWlwTURCTGg5?= =?utf-8?B?NlF2ekhYVTFPVWZKQkdnU3VPYVFCL2lGYVhLTGVPQ2I0Z3YyUmlCeXJGeU5I?= =?utf-8?B?MDNvaGZETzdkdWRoWFJaaTlYUkRHWjZuekVXbDFmVnlLd3pkM3hJWE1XdndD?= =?utf-8?B?MGN6RFJkcE8rNW5HZHJ1cTc2Yk5mT1hDSUV1Szl4TmdJdW1aN0xIaXRmUjdB?= =?utf-8?B?SVp2bXF2dFQ0ekk3RE5tU0Zkb0Q4TTBwSHYvUlEwR0c5Z3gwMWZIV3lwbDNx?= =?utf-8?B?SlVxSUVTY2hvRldCOURtWlE3bGhIdlRsekZpT1hwN2JvajY4QjBvenNhaU1E?= =?utf-8?B?QVc5UGtyZnFRN21TYnZpN2h5eFFzRC9lMWY3TjI5bXhpUEUyVHRucitYNFUr?= =?utf-8?B?M1NoanRCUUozckQwTnM3YW1jd3dhZTErbC9wbnNRN2N3S2wxa3NqWWhDY0lY?= =?utf-8?B?REhXcml2dWNsQ3RSbzBTZWpOT0lKTFRLVkw4ZXBsQldJUXA4dUcwUGxPeXBt?= =?utf-8?B?dndma3ExdUtKRHNPa0Q5eTBHalQyQmVEVm5vbWVTYXYyTEhSRnI3M1poTGNT?= =?utf-8?B?NjFWeHhmdmV2cmpoYnZkNmlFUnVHMnQyR3dRU3hFZGg3aGxMRVh6OEJoK3NL?= =?utf-8?B?a1hteFJzdjJoYzlWeGxuL0s1cWhWRFArU1ZzbXVTaG1QUDROeHorWmkxamds?= =?utf-8?B?U1p6SXc1eTh5M0ZvM25ET01IdFcwTW9LdTFvT053bEpoV3BxK1czUk91dU9z?= =?utf-8?B?WGFTbUNIVy9vSXpHd1VwMTlTeHJ6K3FpdFFFU3RUdG0wcWlZQzRsQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2f1e8a0-01fe-48ba-4788-08df2406e1a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:48.3517 (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: 5ZD5Un769W/H7PMBREj3Hl27gkzGkwlw+z7o6QiM3xpd6FgbF97VUjYNbh2UZaNqxuZBrz8jT0COd9HKBpvNpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-ebf023/1791331610-508D9B50-8B2EAB18/0/0 X-purgate-type: clean X-purgate-size: 13088 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNClRoaXMgcGF0Y2ggYWRk cyBiYXNpYyBmcmFtZXdvcmsgZm9yIHZJT01NVS4NCg0KU2lnbmVkLW9mZi1ieTogUmFodWwgU2lu Z2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQpTaWduZWQtb2ZmLWJ5OiBNaWxhbiBEam9raWMgPG1p bGFuX2Rqb2tpY0BlcGFtLmNvbT4NCi0tLQ0KIHhlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5j ICAgICAgICB8ICAyICsNCiB4ZW4vYXJjaC9hcm0vZG9tYWluLmMgICAgICAgICAgICAgICAgfCAz MSArKysrKysrKysrKy0NCiB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgICAgfCAg MiArDQogeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oICAgIHwgNzAgKysrKysrKysr KysrKysrKysrKysrKysrKysrKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL0tjb25maWcgICAg ICB8ICA1ICsrDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL01ha2VmaWxlIHwgIDEgKw0K IHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92aW9tbXUuYyB8IDQ5ICsrKysrKysrKysrKysr KysrKysNCiB4ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaCAgICAgICAgfCAgNiArKy0NCiA4 IGZpbGVzIGNoYW5nZWQsIDE2NCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQ0KIGNyZWF0 ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmlvbW11LmgNCiBjcmVhdGUg bW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3Zpb21tdS5jDQoNCmRpZmYg LS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYyBiL3hlbi9hcmNoL2FybS9kb20w bGVzcy1idWlsZC5jDQppbmRleCAzZjQ4Zjc0MjI2Li5mODc0Mzc5MTVlIDEwMDY0NA0KLS0tIGEv eGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCisrKyBiL3hlbi9hcmNoL2FybS9kb20wbGVz cy1idWlsZC5jDQpAQCAtMjMsNiArMjMsNyBAQA0KICNpbmNsdWRlIDxhc20vYXJtNjQvc3ZlLmg+ DQogI2luY2x1ZGUgPGFzbS9kb21haW5fYnVpbGQuaD4NCiAjaW5jbHVkZSA8YXNtL2Zpcm13YXJl L3NjaS5oPg0KKyNpbmNsdWRlIDxhc20vdmlvbW11Lmg+DQogI2luY2x1ZGUgPGFzbS9ncmFudF90 YWJsZS5oPg0KICNpbmNsdWRlIDxhc20vc2V0dXAuaD4NCiANCkBAIC0zNjksNiArMzcwLDcgQEAg aW50IF9faW5pdCBhcmNoX3BhcnNlX2RvbTBsZXNzX25vZGUoc3RydWN0IGR0X2RldmljZV9ub2Rl ICpub2RlLA0KICAgICB1aW50MzJfdCB2YWw7DQogDQogICAgIGRfY2ZnLT5hcmNoLmdpY192ZXJz aW9uID0gWEVOX0RPTUNUTF9DT05GSUdfR0lDX05BVElWRTsNCisgICAgZF9jZmctPmFyY2gudmlv bW11X3R5cGUgPSB2aW9tbXVfZ2V0X3R5cGUoKTsNCiAgICAgZF9jZmctPmZsYWdzIHw9IFhFTl9E T01DVExfQ0RGX2h2bSB8IFhFTl9ET01DVExfQ0RGX2hhcDsNCiANCiAgICAgaWYgKCBkb211X2R0 X3NjaV9wYXJzZShub2RlLCBkX2NmZykgKQ0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21h aW4uYyBiL3hlbi9hcmNoL2FybS9kb21haW4uYw0KaW5kZXggYTczOWRkMTU3ZS4uNWM0MTFhMjMx MCAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9kb21haW4uYw0KKysrIGIveGVuL2FyY2gvYXJt L2RvbWFpbi5jDQpAQCAtMzMsNiArMzMsNyBAQA0KICNpbmNsdWRlIDxhc20vdmdpYy5oPg0KICNp bmNsdWRlIDxhc20vdnBjaS5oPg0KICNpbmNsdWRlIDxhc20vdnBzY2kuaD4NCisjaW5jbHVkZSA8 YXNtL3Zpb21tdS5oPg0KICNpbmNsdWRlIDxhc20vdnRpbWVyLmg+DQogDQogI2luY2x1ZGUgInZ1 YXJ0LmgiDQpAQCAtNjYzLDYgKzY2NCwyMSBAQCBpbnQgYXJjaF9zYW5pdGlzZV9kb21haW5fY29u ZmlnKHN0cnVjdCB4ZW5fZG9tY3RsX2NyZWF0ZWRvbWFpbiAqY29uZmlnKQ0KICAgICAgICAgcmV0 dXJuIC1FSU5WQUw7DQogICAgIH0NCiANCisgICAgaWYgKCAhKGNvbmZpZy0+ZmxhZ3MgJiBYRU5f RE9NQ1RMX0NERl9pb21tdSkgJiYNCisgICAgICAgICBjb25maWctPmFyY2gudmlvbW11X3R5cGUg IT0gWEVOX0RPTUNUTF9DT05GSUdfVklPTU1VX05PTkUgKQ0KKyAgICB7DQorICAgICAgICBkcHJp bnRrKFhFTkxPR19JTkZPLA0KKyAgICAgICAgICAgICAgICAidklPTU1VIHJlcXVlc3RlZCB3aGls ZSBpb21tdSBub3QgZW5hYmxlZCBmb3IgZG9tYWluXG4iKTsNCisgICAgICAgIHJldHVybiAtRUlO VkFMOw0KKyAgICB9DQorDQorICAgIGlmICggY29uZmlnLT5hcmNoLnZpb21tdV90eXBlICE9IFhF Tl9ET01DVExfQ09ORklHX1ZJT01NVV9OT05FICkNCisgICAgew0KKyAgICAgICAgZHByaW50ayhY RU5MT0dfSU5GTywNCisgICAgICAgICAgICAgICAgInZJT01NVSB0eXBlIHJlcXVlc3RlZCBub3Qg c3VwcG9ydGVkIGJ5IHRoZSBwbGF0Zm9ybSBvciBYZW5cbiIpOw0KKyAgICAgICAgcmV0dXJuIC1F SU5WQUw7DQorICAgIH0NCisNCiAgICAgcmV0dXJuIHNjaV9kb21haW5fc2FuaXRpc2VfY29uZmln KGNvbmZpZyk7DQogfQ0KIA0KQEAgLTc2Miw2ICs3NzgsOSBAQCBpbnQgYXJjaF9kb21haW5fY3Jl YXRlKHN0cnVjdCBkb21haW4gKmQsDQogICAgIGlmICggKHJjID0gc2NpX2RvbWFpbl9pbml0KGQs IGNvbmZpZykpICE9IDAgKQ0KICAgICAgICAgZ290byBmYWlsOw0KIA0KKyAgICBpZiAoIChyYyA9 IGRvbWFpbl92aW9tbXVfaW5pdChkLCBjb25maWctPmFyY2gudmlvbW11X3R5cGUpKSAhPSAwICkN CisgICAgICAgIGdvdG8gZmFpbDsNCisNCiAgICAgcmV0dXJuIDA7DQogDQogZmFpbDoNCkBAIC04 MjIsNyArODQxLDggQEAgc3RhdGljIHZvaWQgcmVzdW1lX2N0eF9yZXNldChzdHJ1Y3QgcmVzdW1l X2luZm8gKmN0eCkNCiB2b2lkIGFyY2hfZG9tYWluX2Rlc3Ryb3koc3RydWN0IGRvbWFpbiAqZCkN CiB7DQogICAgIHJlc3VtZV9jdHhfcmVzZXQoJmQtPmFyY2gucmVzdW1lX2N0eCk7DQotDQorICAg IGlmICggdmlvbW11X3JlbGlucXVpc2hfcmVzb3VyY2VzKGQpICkNCisgICAgICAgIHByaW50ayhY RU5MT0dfSU5GTyAiJXBkOiBEb21haW4gdklPTU1VIHRlYXJkb3duIGZhaWxlZFxuIiwgZCk7DQog ICAgIHRlZV9mcmVlX2RvbWFpbl9jdHgoZCk7DQogICAgIC8qIElPTU1VIHBhZ2UgdGFibGUgaXMg c2hhcmVkIHdpdGggUDJNLCBhbHdheXMgY2FsbA0KICAgICAgKiBpb21tdV9kb21haW5fZGVzdHJv eSgpIGJlZm9yZSBwMm1fZmluYWxfdGVhcmRvd24oKS4NCkBAIC0xMDU4LDYgKzEwNzgsNyBAQCBz dGF0aWMgaW50IHJlbGlucXVpc2hfbWVtb3J5KHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwYWdl X2xpc3RfaGVhZCAqbGlzdCkNCiAgKi8NCiBlbnVtIHsNCiAgICAgUFJPR19wY2kgPSAxLA0KKyAg ICBQUk9HX3Zpb21tdSwNCiAgICAgUFJPR19zY2ksDQogICAgIFBST0dfdGVlLA0KICAgICBQUk9H X3hlbiwNCkBAIC0xMTA1LDYgKzExMjYsMTQgQEAgaW50IGRvbWFpbl9yZWxpbnF1aXNoX3Jlc291 cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQ0KICAgICAgICAgaWYgKCByZXQgKQ0KICAgICAgICAgICAg IHJldHVybiByZXQ7DQogI2VuZGlmDQorICAgIC8qDQorICAgICAqIFBDSSBkZXZpY2VzIG1heSBy ZWx5IG9uIHRoZSB2SU9NTVUsIHNvIGl0cyByZXNvdXJjZXMNCisgICAgICogc2hvdWxkIGJlIHJl bGlucXVpc2hlZCBvbmx5IGFmdGVyIHRoZSBQQ0kgZGV2aWNlcyBhcmUgcmVsZWFzZWQuDQorICAg ICAqLw0KKyAgICBQUk9HUkVTUyh2aW9tbXUpOg0KKyAgICAgICAgcmV0ID0gdmlvbW11X3JlbGlu cXVpc2hfcmVzb3VyY2VzKGQpOw0KKyAgICAgICAgaWYgKHJldCApDQorICAgICAgICAgICAgcmV0 dXJuIHJldDsNCiANCiAgICAgUFJPR1JFU1Moc2NpKToNCiAgICAgICAgIHJldCA9IHNjaV9yZWxp bnF1aXNoX3Jlc291cmNlcyhkKTsNCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1 aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCmluZGV4IDcyZDUzMTYxODAuLmNk MmUwOWYwMDUgMTAwNjQ0DQotLS0gYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCisrKyBi L3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KQEAgLTM2LDYgKzM2LDcgQEANCiAjaW5jbHVk ZSA8YXNtL2FybTY0L3N2ZS5oPg0KICNpbmNsdWRlIDxhc20vY3B1ZmVhdHVyZS5oPg0KICNpbmNs dWRlIDxhc20vZG9tYWluX2J1aWxkLmg+DQorI2luY2x1ZGUgPGFzbS92aW9tbXUuaD4NCiAjaW5j bHVkZSA8eGVuL2V2ZW50Lmg+DQogDQogI2luY2x1ZGUgPHhlbi9pcnEuaD4NCkBAIC0xOTY0LDYg KzE5NjUsNyBAQCB2b2lkIF9faW5pdCBjcmVhdGVfZG9tMCh2b2lkKQ0KICAgICBkb20wX2NmZy5h cmNoLm5yX3NwaXMgPSB2Z2ljX2RlZl9ucl9zcGlzKCk7DQogICAgIGRvbTBfY2ZnLmFyY2gudGVl X3R5cGUgPSB0ZWVfZ2V0X3R5cGUoKTsNCiAgICAgZG9tMF9jZmcubWF4X3ZjcHVzID0gZG9tMF9t YXhfdmNwdXMoKTsNCisgICAgZG9tMF9jZmcuYXJjaC52aW9tbXVfdHlwZSA9IHZpb21tdV9nZXRf dHlwZSgpOw0KIA0KICAgICBpZiAoIGlvbW11X2VuYWJsZWQgKQ0KICAgICAgICAgZG9tMF9jZmcu ZmxhZ3MgfD0gWEVOX0RPTUNUTF9DREZfaW9tbXU7DQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJt L2luY2x1ZGUvYXNtL3Zpb21tdS5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5o DQpuZXcgZmlsZSBtb2RlIDEwMDY0NA0KaW5kZXggMDAwMDAwMDAwMC4uOTVmODJkOWNmNQ0KLS0t IC9kZXYvbnVsbA0KKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oDQpAQCAt MCwwICsxLDcwIEBADQorLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IChHUEwtMi4wLW9yLWxh dGVyIE9SIEJTRC0yLUNsYXVzZSkgKi8NCisjaWZuZGVmIF9fQVJDSF9BUk1fVklPTU1VX0hfXw0K KyNkZWZpbmUgX19BUkNIX0FSTV9WSU9NTVVfSF9fDQorDQorI2luY2x1ZGUgPHhlbi9saWIuaD4N CisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+DQorI2luY2x1ZGUgPHB1YmxpYy94ZW4uaD4NCisNCitz dHJ1Y3QgdmlvbW11X29wcyB7DQorICAgIC8qDQorICAgICAqIENhbGxlZCBkdXJpbmcgZG9tYWlu IGNvbnN0cnVjdGlvbiBpZiB0b29sc3RhY2sgcmVxdWVzdHMgdG8gZW5hYmxlDQorICAgICAqIHZJ T01NVSBzdXBwb3J0Lg0KKyAgICAgKi8NCisgICAgaW50ICgqZG9tYWluX2luaXQpKHN0cnVjdCBk b21haW4gKmQpOw0KKw0KKyAgICAvKg0KKyAgICAgKiBDYWxsZWQgZHVyaW5nIGRvbWFpbiBkZXN0 cnVjdGlvbiB0byBmcmVlIHJlc291cmNlcyB1c2VkIGJ5IHZJT01NVS4NCisgICAgICovDQorICAg IGludCAoKnJlbGlucXVpc2hfcmVzb3VyY2VzKShzdHJ1Y3QgZG9tYWluICpkKTsNCit9Ow0KKw0K K3N0cnVjdCB2aW9tbXVfZGVzYyB7DQorICAgIC8qIHZJT01NVSBkb21haW5zIGluaXQvZnJlZSBv cGVyYXRpb25zIGRlc2NyaWJlZCBhYm92ZS4gKi8NCisgICAgY29uc3Qgc3RydWN0IHZpb21tdV9v cHMgKm9wczsNCisNCisgICAgLyoNCisgICAgICogSUQgb2YgdklPTU1VLiBDb3JyZXNwb25kcyB0 byB4ZW5fYXJjaF9kb21haW5jb25maWcudmlvbW11X3R5cGUuDQorICAgICAqIFNob3VsZCBiZSBv bmUgb2YgWEVOX0RPTUNUTF9DT05GSUdfVklPTU1VX3h4eA0KKyAgICAgKi8NCisgICAgdWludDhf dCB2aW9tbXVfdHlwZTsNCit9Ow0KKw0KKyNpZmRlZiBDT05GSUdfQVJNX1ZJUlRVQUxfSU9NTVUN CisNCitpbnQgZG9tYWluX3Zpb21tdV9pbml0KHN0cnVjdCBkb21haW4gKmQsIHVpbnQ4X3Qgdmlv bW11X3R5cGUpOw0KK2ludCB2aW9tbXVfcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFp biAqZCk7DQordWludDhfdCB2aW9tbXVfZ2V0X3R5cGUodm9pZCk7DQorDQorI2Vsc2UNCisNCitz dGF0aWMgaW5saW5lIHVpbnQ4X3QgdmlvbW11X2dldF90eXBlKHZvaWQpDQorew0KKyAgICByZXR1 cm4gWEVOX0RPTUNUTF9DT05GSUdfVklPTU1VX05PTkU7DQorfQ0KKw0KK3N0YXRpYyBpbmxpbmUg aW50IGRvbWFpbl92aW9tbXVfaW5pdChzdHJ1Y3QgZG9tYWluICpkLCB1aW50OF90IHZpb21tdV90 eXBlKQ0KK3sNCisgICAgaWYgKCBsaWtlbHkodmlvbW11X3R5cGUgPT0gWEVOX0RPTUNUTF9DT05G SUdfVklPTU1VX05PTkUpICkNCisgICAgICAgIHJldHVybiAwOw0KKw0KKyAgICByZXR1cm4gLUVO T0RFVjsNCit9DQorDQorc3RhdGljIGlubGluZSBpbnQgdmlvbW11X3JlbGlucXVpc2hfcmVzb3Vy Y2VzKHN0cnVjdCBkb21haW4gKmQpDQorew0KKyAgICByZXR1cm4gMDsNCit9DQorDQorI2VuZGlm IC8qIENPTkZJR19BUk1fVklSVFVBTF9JT01NVSAqLw0KKw0KKyNlbmRpZiAvKiBfX0FSQ0hfQVJN X1ZJT01NVV9IX18gKi8NCisNCisvKg0KKyAqIExvY2FsIHZhcmlhYmxlczoNCisgKiBtb2RlOiBD DQorICogYy1maWxlLXN0eWxlOiAiQlNEIg0KKyAqIGMtYmFzaWMtb2Zmc2V0OiA0DQorICogaW5k ZW50LXRhYnMtbW9kZTogbmlsDQorICogRW5kOg0KKyAqLw0KZGlmZiAtLWdpdCBhL3hlbi9kcml2 ZXJzL3Bhc3N0aHJvdWdoL0tjb25maWcgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9LY29uZmln DQppbmRleCBiNDEzYzMzYTRjLi5hOTJjZmJlYTk4IDEwMDY0NA0KLS0tIGEveGVuL2RyaXZlcnMv cGFzc3Rocm91Z2gvS2NvbmZpZw0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvS2NvbmZp Zw0KQEAgLTM1LDYgKzM1LDExIEBAIGNvbmZpZyBJUE1NVV9WTVNBDQogCSAgKEgzIEVTMy4wLCBN My1XKywgZXRjKSBvciBHZW40IFNvQ3Mgd2hpY2ggSVBNTVUgaGFyZHdhcmUgc3VwcG9ydHMgc3Rh Z2UgMg0KIAkgIHRyYW5zbGF0aW9uIHRhYmxlIGZvcm1hdCBhbmQgaXMgYWJsZSB0byB1c2UgQ1BV J3MgUDJNIHRhYmxlIGFzIGlzLg0KIA0KK2NvbmZpZyBBUk1fVklSVFVBTF9JT01NVQ0KKwlib29s ICJWaXJ0dWFsIElPTU1VIFN1cHBvcnQgKFVOU1VQUE9SVEVEKSIgaWYgVU5TVVBQT1JURUQNCisJ aGVscA0KKwkgIFN1cHBvcnQgdmlydHVhbCBJT01NVSBpbmZyYXN0cnVjdHVyZSB0byBpbXBsZW1l bnQgdklPTU1VLg0KKw0KIGVuZGlmDQogDQogY29uZmlnIEFNRF9JT01NVQ0KZGlmZiAtLWdpdCBh L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9NYWtlZmlsZSBiL3hlbi9kcml2ZXJzL3Bhc3N0 aHJvdWdoL2FybS9NYWtlZmlsZQ0KaW5kZXggYzVmYjNiNThhNS4uYzM3ODMxODhlMyAxMDA2NDQN Ci0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9NYWtlZmlsZQ0KKysrIGIveGVuL2Ry aXZlcnMvcGFzc3Rocm91Z2gvYXJtL01ha2VmaWxlDQpAQCAtMiwzICsyLDQgQEAgb2JqLXkgKz0g aW9tbXUubyBpb21tdV9oZWxwZXJzLm8gaW9tbXVfZndzcGVjLm8NCiBvYmotJChDT05GSUdfQVJN X1NNTVUpICs9IHNtbXUubw0KIG9iai0kKENPTkZJR19JUE1NVV9WTVNBKSArPSBpcG1tdS12bXNh Lm8NCiBvYmotJChDT05GSUdfQVJNX1NNTVVfVjMpICs9IHNtbXUtdjMubw0KK29iai0kKENPTkZJ R19BUk1fVklSVFVBTF9JT01NVSkgKz0gdmlvbW11Lm8NCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9hcm0vdmlvbW11LmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0v dmlvbW11LmMNCm5ldyBmaWxlIG1vZGUgMTAwNjQ0DQppbmRleCAwMDAwMDAwMDAwLi4wYzBlZmQ2 NjhlDQotLS0gL2Rldi9udWxsDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlv bW11LmMNCkBAIC0wLDAgKzEsNDkgQEANCisvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogKEdQ TC0yLjAtb3ItbGF0ZXIgT1IgQlNELTItQ2xhdXNlKSAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vZXJy bm8uaD4NCisjaW5jbHVkZSA8eGVuL2luaXQuaD4NCisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+DQor DQorI2luY2x1ZGUgPGFzbS92aW9tbXUuaD4NCisNCisvKiBTdHJ1Y3QgdG8gaG9sZCB0aGUgdklP TU1VIG9wcyBhbmQgdklPTU1VIHR5cGUgKi8NCitzdGF0aWMgY29uc3Qgc3RydWN0IHZpb21tdV9k ZXNjIF9fcm9fYWZ0ZXJfaW5pdCAqY3VyX3Zpb21tdTsNCisNCitpbnQgZG9tYWluX3Zpb21tdV9p bml0KHN0cnVjdCBkb21haW4gKmQsIHVpbnQ4X3QgdmlvbW11X3R5cGUpDQorew0KKyAgICBpZiAo IHZpb21tdV90eXBlID09IFhFTl9ET01DVExfQ09ORklHX1ZJT01NVV9OT05FICkNCisgICAgICAg IHJldHVybiAwOw0KKw0KKyAgICBpZiAoICFjdXJfdmlvbW11ICkNCisgICAgICAgIHJldHVybiAt RU5PREVWOw0KKw0KKyAgICBpZiAoIGN1cl92aW9tbXUtPnZpb21tdV90eXBlICE9IHZpb21tdV90 eXBlICkNCisgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKw0KKyAgICByZXR1cm4gY3VyX3Zpb21t dS0+b3BzLT5kb21haW5faW5pdChkKTsNCit9DQorDQoraW50IHZpb21tdV9yZWxpbnF1aXNoX3Jl c291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQ0KK3sNCisgICAgaWYgKCAhY3VyX3Zpb21tdSApDQor ICAgICAgICByZXR1cm4gMDsNCisNCisgICAgcmV0dXJuIGN1cl92aW9tbXUtPm9wcy0+cmVsaW5x dWlzaF9yZXNvdXJjZXMoZCk7DQorfQ0KKw0KK3VpbnQ4X3QgdmlvbW11X2dldF90eXBlKHZvaWQp DQorew0KKyAgICBpZiAoICFjdXJfdmlvbW11ICkNCisgICAgICAgIHJldHVybiBYRU5fRE9NQ1RM X0NPTkZJR19WSU9NTVVfTk9ORTsNCisNCisgICAgcmV0dXJuIGN1cl92aW9tbXUtPnZpb21tdV90 eXBlOw0KK30NCisNCisvKg0KKyAqIExvY2FsIHZhcmlhYmxlczoNCisgKiBtb2RlOiBDDQorICog Yy1maWxlLXN0eWxlOiAiQlNEIg0KKyAqIGMtYmFzaWMtb2Zmc2V0OiA0DQorICogaW5kZW50LXRh YnMtbW9kZTogbmlsDQorICogRW5kOg0KKyAqLw0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1 YmxpYy9hcmNoLWFybS5oIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCmluZGV4IDAw ZGUzMGI4OTYuLmExNDkxZjljZjcgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJj aC1hcm0uaA0KKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCkBAIC0zMzQsNiAr MzM0LDggQEAgREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUodmNwdV9ndWVzdF9jb250ZXh0X3QpOw0K ICNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1Y4Ul9FTDFfTVNBX1BNU0EgICAgMQ0KICNk ZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1Y4Ul9FTDFfTVNBX1ZNU0EgICAgMg0KIA0KKyNk ZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfVklPTU1VX05PTkUgICAwDQorDQogc3RydWN0IHhlbl9h cmNoX2RvbWFpbmNvbmZpZyB7DQogICAgIC8qIElOL09VVCAqLw0KICAgICB1aW50OF90IGdpY192 ZXJzaW9uOw0KQEAgLTM2MSw3ICszNjMsOSBAQCBzdHJ1Y3QgeGVuX2FyY2hfZG9tYWluY29uZmln IHsNCiAgICAgdWludDhfdCBhcm1fc2NpX3R5cGU7DQogICAgIC8qIElOICovDQogICAgIHVpbnQ4 X3QgdjhyX2VsMV9tc2E7DQotICAgIHVpbnQxNl90IHBhZDsNCisgICAgLyogSU4gKi8NCisgICAg dWludDhfdCB2aW9tbXVfdHlwZTsNCisgICAgdWludDhfdCBwYWQ7DQogfTsNCiAjZW5kaWYgLyog X19YRU5fXyB8fCBfX1hFTl9UT09MU19fICovDQogDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441815.1659350 (Exim 4.92) (envelope-from ) id 1xEFBO-0008Vf-NF; Wed, 07 Oct 2026 00:06:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441815.1659350; Wed, 07 Oct 2026 00:06: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 1xEFBO-0008VS-Jk; Wed, 07 Oct 2026 00:06:54 +0000 Received: by outflank-mailman (input) for mailman id 1441815; Wed, 07 Oct 2026 00:06:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBN-0008O0-45 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBM-000T4z-HG for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:52 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58cd8-2eae-0a2a0a5409dd-0a2a4505835a-38 for ; Wed, 07 Oct 2026 02:06:52 +0200 Received: from [52.101.70.105] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d1c-4cb1-0a2a45050019-34654669339f-3 for ; Wed, 07 Oct 2026 02:06:52 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:50 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=b7Lei1rcdxaTlBNDb2vQNiq6Gqspxxu73EkWu5WGZLz+y594x5to86UbnK5WrNjXOUvtJWq+10jq6oy/CjopOV6BzmtuJmGdIfPw9BLQyB5zazKkNiDLIDE5MXbJ8Dzv24p1ad8z4oxKn0BRxrGNsVpTM7s2QABLpf2b1whFWYMUBNYYroL9ozZil2PE3mU1nKelSCOoZKR2KPa8vSA0LYtVc4lLyqIgjHHDz3Mbit56wyBNXCEjo/HOfQ+VcwtpN9quB/r5b3aXAuwkg4AoPOgeMrNE85NcubDpHah/xLl6IeH+rk4MzKIkQ8yl4NxnylCWjAJUETrIVLzXk70S8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s6fBeL+MAqASEV6H1dyzlNgG792lYox9FaIzNnli0Ng=; b=uo9pHvkuoplRG3YP102yFpY7CVNHMGlsifuZHbLlCiF3fVmcr0nNBdHhWW9Ov54lszKtwy4y3QwajiaUkTnM7fB//0y+EvOvdOG5VnNEZYQU8vQ0xy/H0SpO//rSUTuYLv8+L+RZHziJnIB5XD0Gt64WSIv5ACJ8jlYOVAeDA0LecBODcn8S7ml64qkdAvVxBtynOph7UVIasTNWh3qIU//1iiomUeio69zsGrKBMmkpRorps5xEpdok1dUPxdPQA8A/m564d7hlJt/Pa8gnEPvQW/FdclT5fey2UbFO2rhhdo7g80fcQRRgLZ4lSJ1QbeODtvGOJcaqKOvdQKgjOA== 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=s6fBeL+MAqASEV6H1dyzlNgG792lYox9FaIzNnli0Ng=; b=vq9V0OzU1LqudO01IBznBHZpdBQvy2+8/4iJfRpYTCBEaSC4gQZNqj03kdg9TAwugyWm40nGTNAhkgoLWy0H/JpR7id/NjoTa5xYtWVEzM+tKoHQaXB9HXC62RpCpVZjZdAMU9yjyhf+54Di0Q+dH1frK/1RLQMdJmfKmBZywclivc86PHxU6pg1NLWUrIVp0rU/YAxZp+pwmyFux7JP4qffpaby54XVeoFrY9gurtiHznNhsCgaG3M3ryn7r8LLeZtZVG2tWjGPJ1yjcWY2G7ceNiWz6lIpQ2H4Hx/4UgBBWq+ymlNdO+zF1btybw3FDAif3rUuJIxxAjoCqVyqfw== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Milan Djokic Subject: [PATCH v4 05/22] xen/arm: vsmmuv3: Add dummy support for virtual SMMUv3 for guests Thread-Topic: [PATCH v4 05/22] xen/arm: vsmmuv3: Add dummy support for virtual SMMUv3 for guests Thread-Index: AQHdVe/A2h41NhEQxEi7iy+7zdwxbg== Date: Wed, 7 Oct 2026 00:06:50 +0000 Message-ID: <2094abe1b6faba477e771390bf47921f80e7e0e7.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: c7269593-516c-4b2b-8f67-08df2406e2be x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|260925022911599003|56012099006|260925021911599003|11063799006|10067099003|260925021311599003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: VGN3KS9yAfi2uwkSkzFjXu98KM7D1Iq8K9a4yvkPOPzMebFZ7oSdBHk3KnIKpXdvCVIedCbDM/KgDGChyR+V1AUw8SLbFMXPgEtU0P+u8CSwvt6g9Sw0lYjDYOWmjAqagESTZi16u4vCDu2VYQdZdgGPoObjrKc1NDqgPo2emxT4y8LimZUJcDOeneSZGQbhkA80zNwqBkH4+aBklRgZ3c0TjvZI2az37jYT9yh1O9PznAyhe6exbPKChR9igGUOIL3w2FKWIE6bkXBMI4Soa9/KKiBRjpkEuilCRBfY5CKmTyuCY3RpDLQfk8Zx72OwHm/+5yzpC4fSsDdsfZWoO+aNp2jWZNGrbLklOVfdOYSa+dol2TGWVnZ3FTb+Jwqfx+5cTqJYjq39QwCP5w1ULPQE/vJmUYUmrvCMuX+cUmVnKEcWOt5FJim2N/c8THAuXAXCuqCKBSsf/VuIoiApZYCQNRPaYQZIsjvJjN87MAAZHXS4/qdRmuBzcyLnIo+TWrcwrP+nIHnDpRomRLJ7eVE8gSBFG6ZwVMvW0bSOXPDgtMrFpR4bN6JGLWE/JTrAGelihvVoJKemlLNAKNpYB5k5iPDI8DwGbeJVKydP86L4wf5Tw/egivVPXMYyIr4u9r6qF+ZIb6MUnYqsC0BtN5pr3j7DsZRyX0sQuc9FmnI0Fb+IpNYN+zyoLhs+1W4UEHw96EW0te1Cqdd55B/olN8LmH4WjSyC2+ku7VwxK7U= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(260925022911599003)(56012099006)(260925021911599003)(11063799006)(10067099003)(260925021311599003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Zm9UUWFVRy9FM2NMdEcrLzlLekJjL2RvdUVGKzE4bDA3NlBsYlFFTFFlaXlB?= =?utf-8?B?NUxPWVJYdkk4M1NhVUE3Y1M4cVIyNEJ4dU02cGJmejRQVXo0TWhvKy82ajJa?= =?utf-8?B?K3RHRzE0SHpKTHFLcFc1MVY2SGwxRU1IaUNzWWdsRnNoWXZoaExwK0M2OHB5?= =?utf-8?B?OTVaRnNoVTNTZ3lQQVQxaWlJUEpWdHVpQmhQOGZnYkU0VzVscE5wcFZhb21C?= =?utf-8?B?VWc4dmJDb2NNS3dESVBaVUZ0b2h1QUg0S2liUC9VSUk2dzZJODFKZy82TXBq?= =?utf-8?B?bGo5Q2wzWitvV0cyakhySGZ3UlpFSHZsSVZ3anpYRzhpR1ExK3FrNzFEeU9s?= =?utf-8?B?RUtWakpOa0dNL1ZJalphMVhTb0RGUnh3c0VZamhnVnVKWFlsc0hTMVNKK2Zw?= =?utf-8?B?VXkwZldBNnlBL1FxVUdmU2ZzbjlWeDRHY2xJT2s0R0dzd3ZLR2Z6Z2lRdWlP?= =?utf-8?B?dlRNcU5lNkh2bko1VmI1WW5CaDJ0VGkrczFBQ0NuWXhFem5SOXRIb05yaHhN?= =?utf-8?B?M3YwenhMQysya0xlZWdsS3U4aVMzT2VBbXVvcmdsbjg3Ymk2eHorSUxqcnlj?= =?utf-8?B?UUhVMG1SYUd2ck85WkFrWVRHdDMyMmJBVFFLb2d1MlZtN2IvNEdRbW5SOFhm?= =?utf-8?B?YzdzU2FTS3czN2w0YkZUQVZ2Sm5ZdnBpRmxBbERyVDBieXd2SFJ5TVdkL0NE?= =?utf-8?B?d2JGanc4aGt5dTVQNGlZcldSdkxETmUrcFVqNjZaTHBIN0Y1QTJiV0VGRkhJ?= =?utf-8?B?Vk4zdFVaZnRyM2xkMUVWZmRyWlZNRDVvQSthdTNFNTNOY3N4d01EWWowbnF1?= =?utf-8?B?Z1NsU0JMdHlaUlBZb1lWUmxBZ3NQOWFBd2h3bm1DVms2RENLOVVmRkVwMTIv?= =?utf-8?B?SE14c1NJOTYxSU5yL3BkVGMyNW4wZDdzbGNSSDhhR1g4S0hKOGRwTHd5S05a?= =?utf-8?B?YVcwcWthSk1yMDhXRVJrbEkrS3I2eUVmS3BjRS8vUEJrNkQvZW5wTlhweU9W?= =?utf-8?B?ZlM0cEJtVU44RFFtc093UnFuaXE0V1lQcEwwNHVOWlhmWWkvTWlacHYxMjlx?= =?utf-8?B?ZkhWRXJ0d0xYV09LbzUzdCtPNm9PQWRFZ1RibU0vR1ZmV1BuV0NOYWgxWHpy?= =?utf-8?B?TzBINUZBNGVUTkZ1U2lTbWUyNXBlNmNMNUlUM2VFOXJtWFE1VUJUcDZucjdk?= =?utf-8?B?NklNNmRaOXJnSklEM1pqR2RuczZNSnpyNW50Ylc2ODdseXlGVzJFaFgwN1lD?= =?utf-8?B?a0F1VXRtZlI1RGlkeGJ4Qkd4MkIrY3lVeUg1K0RScnBzWGJwZktodnhlNHdk?= =?utf-8?B?WldmTVk5MHgvczMrMCtRelNGL08zRGZ0UEd6WEFjRjcxamN3VERja3VPc1N6?= =?utf-8?B?QTlCUDRUdFdTcHZLUTFNb0RudTlWekI4OFNCcFNyRjFYTFpvN3pNaUVpb2lv?= =?utf-8?B?QnpzSWo2VzBheEd2QXVJVmM0YXBIMzkvYndyYWpuNE56c2xtMEVhY2JRalVF?= =?utf-8?B?VGlMSXduOWxlank4TWJGR3Byb21CU3cwNWM2ek9ONVFCU0Z2TGx6N0JCb0Zv?= =?utf-8?B?VmllYTMrM0xiNi9MY01MNUtPU1RqTVNTNXpQMHB6SDNTdjVCOUY2MFJHdFhF?= =?utf-8?B?L1MzZUdTMHBmUzcvczBpN3RPcjBXS0FxU0ttY01SbXA3WTU1LzdxSVJ3cTNy?= =?utf-8?B?YUxxKzFhSXRNL0ZZZnlFVkx3WVY0RzZ1OGVxR3NIb1Z2bmhIR0t5N2tMczZT?= =?utf-8?B?eVdjVmJKZ21ucGloeDNSaUV5Yk1UREpHMjljaHhqblRqaVE3UWFTOTFYMGNs?= =?utf-8?B?NU9TQzN4aGFwNG5kc1dBWmUvVlp2bGRqWXhWS3g0cFU2SHNpNEkzaTRGQms0?= =?utf-8?B?UmNNZDZ2N01kNVY5UFhBcUc1WFBWb2hvYWhpNDQ1TlZFSENxK1JFSHRqQkJt?= =?utf-8?B?cGpoVzRDMjFpbEZnU1NzbVdpOGlYejdaRlEyS0VGSmtYc25zWkI4UlpBSFdG?= =?utf-8?B?dDUxQ3NHZjA2N085QUFzbmZQOGFpY0pKK2tQTW81eHZZWEc0cVc5b25GVWgy?= =?utf-8?B?d0pIYUFVL0ZpVWN3WXNxNVJjTUgrazhaUjRaMWVPQXdyNlBDT25TSUtMbmds?= =?utf-8?B?MnVqUmI2Y2FreXFwbkVJVkpVeDdhMkpUaWtUOVBTU1ErN0VtclJVdjZCdHJZ?= =?utf-8?B?N3NBZVpHalpRSGhnSHRxQmRFY2lOUDc0NlZjTDI4UzZhUmwzY2JuTCtqZTJ5?= =?utf-8?B?Vko2MmREZlF2VzZMWTBRSUI5U0J0aEZyYkJBd2JwYUQzSjhYbDJMTFBVenZy?= =?utf-8?B?RDQ0STZPOThjTi9Id3ZZR1ZBNlBIeUtMd1YzdFNaUFNHdUlDQVpSZz09?= Content-Type: text/plain; charset="utf-8" Content-ID: <3FA688145600604EA53B425ED33DF0D1@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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7269593-516c-4b2b-8f67-08df2406e2be X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:50.1864 (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: AQcdLujEgv8LjY39xSAVqKGzAgkO/PT2H1Aioja2lr+5jzEaO8qObxB5MY7s6PMh5XlHTT1Tow8IINeqCZB7rQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-c201ff/1791331612-F4CA02A1-C102F74D/0/0 X-purgate-type: clean X-purgate-size: 20364 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCmRvbWFpbl92aW9tbXVf aW5pdCgpIHdpbGwgYmUgY2FsbGVkIGR1cmluZyBkb21haW4gY3JlYXRpb24gYW5kIHdpbGwgYWRk DQp0aGUgZHVtbXkgdHJhcCBoYW5kbGVyIGZvciB2aXJ0dWFsIElPTU1VcyBmb3IgZ3Vlc3RzLg0K DQpBIGhvc3QgSU9NTVUgbGlzdCB3aWxsIGJlIGNyZWF0ZWQgd2hlbiBob3N0IElPTU1VIGRldmlj ZXMgYXJlIHByb2JlZA0KYW5kIHRoaXMgbGlzdCB3aWxsIGJlIHVzZWQgdG8gY3JlYXRlIHRoZSBJ T01NVSBkZXZpY2UgdHJlZSBub2RlIGZvcg0KZG9tMC4gRm9yIGRvbTAsIDEtMSBtYXBwaW5nIHdp bGwgYmUgZXN0YWJsaXNoZWQgYmV0d2VlbiB2SU9NTVUgaW4gZG9tMA0KYW5kwqBwaHlzaWNhbCBJ T01NVS4NCg0KRm9yIGRvbVVzLCB0aGUgMS1OIG1hcHBpbmcgd2lsbCBiZSBlc3RhYmxpc2hlZCBi ZXR3ZWVuIGRvbVUgYW5kIHBoeXNpY2FsDQpJT01NVXMuIEEgbmV3IGFyZWEgaGFzIGJlZW4gcmVz ZXJ2ZWQgaW4gdGhlIGFybSBndWVzdCBwaHlzaWNhbCBtYXAgYXQNCndoaWNoIHRoZSBlbXVsYXRl ZCB2SU9NTVUgbm9kZSBpcyBjcmVhdGVkIGluIHRoZSBkZXZpY2UgdHJlZS4NCg0KQWxzbyBzZXQg dGhlIHZJT01NVSB0eXBlIHRvIHZTTU1VdjMgdG8gZW5hYmxlIHZJT01NVSBmcmFtZXdvcmsgdG8g Y2FsbA0KdlNNTVV2MyBkb21haW4gY3JlYXRpb24vZGVzdHJveSBmdW5jdGlvbnMuDQoNClNpZ25l ZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxyYWh1bC5zaW5naEBhcm0uY29tPg0KU2lnbmVkLW9mZi1i eTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBhbS5jb20+DQotLS0NCiB4ZW4vYXJjaC9h cm0vZG9tYWluLmMgICAgICAgICAgICAgICAgICB8ICAgNiArLQ0KIHhlbi9hcmNoL2FybS9pbmNs dWRlL2FzbS9kb21haW4uaCAgICAgIHwgICA1ICsrDQogeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNt L3Zpb21tdS5oICAgICAgfCAgMzYgKysrKysrKysNCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9L Y29uZmlnICAgICAgICB8ICAgOCArKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9NYWtl ZmlsZSAgIHwgICAxICsNCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jICB8 ICAgNyArKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92aW9tbXUuYyAgIHwgIDgzICsr KysrKysrKysrKysrKystDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMg fCAxMTggKysrKysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo L2FybS92c21tdS12My5oIHwgIDIwICsrKysrDQogeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJt LmggICAgICAgICAgfCAgIDUgKysNCiAxMCBmaWxlcyBjaGFuZ2VkLCAyODcgaW5zZXJ0aW9ucygr KSwgMiBkZWxldGlvbnMoLSkNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvYXJtL3ZzbW11LXYzLmMNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvYXJtL3ZzbW11LXYzLmgNCg0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21h aW4uYyBiL3hlbi9hcmNoL2FybS9kb21haW4uYw0KaW5kZXggNWM0MTFhMjMxMC4uMDAzYThkNDVi OSAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9kb21haW4uYw0KKysrIGIveGVuL2FyY2gvYXJt L2RvbWFpbi5jDQpAQCAtNjcyLDcgKzY3Miw4IEBAIGludCBhcmNoX3Nhbml0aXNlX2RvbWFpbl9j b25maWcoc3RydWN0IHhlbl9kb21jdGxfY3JlYXRlZG9tYWluICpjb25maWcpDQogICAgICAgICBy ZXR1cm4gLUVJTlZBTDsNCiAgICAgfQ0KIA0KLSAgICBpZiAoIGNvbmZpZy0+YXJjaC52aW9tbXVf dHlwZSAhPSBYRU5fRE9NQ1RMX0NPTkZJR19WSU9NTVVfTk9ORSApDQorICAgIGlmICggY29uZmln LT5hcmNoLnZpb21tdV90eXBlICE9IFhFTl9ET01DVExfQ09ORklHX1ZJT01NVV9OT05FICYmDQor ICAgICAgICAgY29uZmlnLT5hcmNoLnZpb21tdV90eXBlICE9IHZpb21tdV9nZXRfdHlwZSgpICkN CiAgICAgew0KICAgICAgICAgZHByaW50ayhYRU5MT0dfSU5GTywNCiAgICAgICAgICAgICAgICAg InZJT01NVSB0eXBlIHJlcXVlc3RlZCBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBwbGF0Zm9ybSBvciBY ZW5cbiIpOw0KQEAgLTcyOCw2ICs3MjksOSBAQCBpbnQgYXJjaF9kb21haW5fY3JlYXRlKHN0cnVj dCBkb21haW4gKmQsDQogDQogICAgIGNvdW50ICs9IGRvbWFpbl92cGNpX2dldF9udW1fbW1pb19o YW5kbGVycyhkKTsNCiANCisgICAgaWYgKCBjb25maWctPmFyY2gudmlvbW11X3R5cGUgIT0gWEVO X0RPTUNUTF9DT05GSUdfVklPTU1VX05PTkUgKQ0KKyAgICAgICAgY291bnQgKz0gZG9tYWluX3Zp b21tdV9nZXRfbnVtX21taW9faGFuZGxlcnMoZCk7DQorDQogICAgIGlmICggKHJjID0gZG9tYWlu X2lvX2luaXQoZCwgY291bnQgKyBNQVhfSU9fSEFORExFUikpICE9IDAgKQ0KICAgICAgICAgZ290 byBmYWlsOw0KIA0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9kb21haW4u aCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9kb21haW4uaA0KaW5kZXggYzNkMmM0OTgxZi4u NzBhZjBiZjhiNyAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9kb21haW4u aA0KKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2RvbWFpbi5oDQpAQCAtMTAyLDYgKzEw MiwxMSBAQCBzdHJ1Y3QgYXJjaF9kb21haW4NCiAjaWZkZWYgQ09ORklHX01QVQ0KICAgICB1aW50 OF90IHY4cl9lbDFfbXNhOw0KICNlbmRpZg0KKw0KKyNpZmRlZiBDT05GSUdfQVJNX1ZJUlRVQUxf SU9NTVUNCisgICAgc3RydWN0IGxpc3RfaGVhZCB2aW9tbXVfbGlzdDsgICAgIC8qIExpc3Qgb2Yg dmlydHVhbCBJT01NVXMgKi8NCisjZW5kaWYNCisNCiB9ICBfX2NhY2hlbGluZV9hbGlnbmVkOw0K IA0KIHN0cnVjdCBhcmNoX3ZjcHUNCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h c20vdmlvbW11LmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmlvbW11LmgNCmluZGV4IDk1 ZjgyZDljZjUuLjI4NzU5NTA2OGIgMTAwNjQ0DQotLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h c20vdmlvbW11LmgNCisrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS92aW9tbXUuaA0KQEAg LTMsOSArMywyMyBAQA0KICNkZWZpbmUgX19BUkNIX0FSTV9WSU9NTVVfSF9fDQogDQogI2luY2x1 ZGUgPHhlbi9saWIuaD4NCisjaW5jbHVkZSA8eGVuL2xpc3QuaD4NCiAjaW5jbHVkZSA8eGVuL3R5 cGVzLmg+DQogI2luY2x1ZGUgPHB1YmxpYy94ZW4uaD4NCiANCisvKiBkYXRhIHN0cnVjdHVyZSBm b3IgZWFjaCBoYXJkd2FyZSBJT01NVSAqLw0KK3N0cnVjdCBob3N0X2lvbW11IHsNCisgICAgc3Ry dWN0IGxpc3RfaGVhZCBlbnRyeTsNCisgICAgLyogSU9NTVUgRFQgbm9kZSB1c2VkIHRvIGVzdGFi bGlzaCB2aXJ0dWFsIHRvIHBoeXNpY2FsIElPTU1VL1NJRCBtYXBwaW5nICovDQorICAgIGNvbnN0 IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZHRfbm9kZTsNCisgICAgLyogVXNlZCBmb3IgZG9tMCB2 SU9NTVUgaW5zdGFudGlhdGlvbiAoMS0xIE1NSU8gcmVnaW9ucyBtYXBwaW5ncykgKi8NCisgICAg cGFkZHJfdCBhZGRyOw0KKyAgICAvKiBVc2VkIGZvciBkb20wIHZJT01NVSBpbnN0YW50aWF0aW9u ICgxLTEgTU1JTyByZWdpb25zIG1hcHBpbmdzKSAqLw0KKyAgICBwYWRkcl90IHNpemU7DQorICAg IC8qIFVzZWQgZm9yIGRvbTAgRVZUUSBhbmQgR0VSUk9SIGludGVycnVwdHMgKDEtMSBJUlEgbWFw cGluZykgKi8NCisgICAgdWludDMyX3QgaXJxOw0KK307DQorDQogc3RydWN0IHZpb21tdV9vcHMg ew0KICAgICAvKg0KICAgICAgKiBDYWxsZWQgZHVyaW5nIGRvbWFpbiBjb25zdHJ1Y3Rpb24gaWYg dG9vbHN0YWNrIHJlcXVlc3RzIHRvIGVuYWJsZQ0KQEAgLTMyLDkgKzQ2LDE1IEBAIHN0cnVjdCB2 aW9tbXVfZGVzYyB7DQogDQogI2lmZGVmIENPTkZJR19BUk1fVklSVFVBTF9JT01NVQ0KIA0KK2V4 dGVybiBzdHJ1Y3QgbGlzdF9oZWFkIGhvc3RfaW9tbXVfbGlzdDsNCisNCiBpbnQgZG9tYWluX3Zp b21tdV9pbml0KHN0cnVjdCBkb21haW4gKmQsIHVpbnQ4X3QgdmlvbW11X3R5cGUpOw0KIGludCB2 aW9tbXVfcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCk7DQogdWludDhfdCB2 aW9tbXVfZ2V0X3R5cGUodm9pZCk7DQordm9pZCBhZGRfdG9faG9zdF9pb21tdV9saXN0KHBhZGRy X3QgYWRkciwgcGFkZHJfdCBzaXplLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z dCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUpOw0KK3ZvaWQgc2V0X2N1cl92aW9tbXUoY29u c3Qgc3RydWN0IHZpb21tdV9kZXNjICpkZXNjKTsNCit1bnNpZ25lZCBpbnQgZG9tYWluX3Zpb21t dV9nZXRfbnVtX21taW9faGFuZGxlcnMoc3RydWN0IGRvbWFpbiAqZCk7DQogDQogI2Vsc2UNCiAN CkBAIC01Niw2ICs3NiwyMiBAQCBzdGF0aWMgaW5saW5lIGludCB2aW9tbXVfcmVsaW5xdWlzaF9y ZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCkNCiAgICAgcmV0dXJuIDA7DQogfQ0KIA0KK3N0YXRp YyBpbmxpbmUgdm9pZCBfX2luaXQgYWRkX3RvX2hvc3RfaW9tbXVfbGlzdChwYWRkcl90IGFkZHIs IHBhZGRyX3Qgc2l6ZSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUpDQorew0KKyAgICByZXR1cm47DQor fQ0KKw0KK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IGRvbWFpbl92aW9tbXVfZ2V0X251bV9t bWlvX2hhbmRsZXJzKHN0cnVjdCBkb21haW4gKmQpDQorew0KKyAgICByZXR1cm4gMDsNCit9DQor DQorc3RhdGljIGlubGluZSB2b2lkIF9faW5pdCBzZXRfY3VyX3Zpb21tdShjb25zdCBzdHJ1Y3Qg dmlvbW11X2Rlc2MgKmRlc2MpDQorew0KKyAgICByZXR1cm47DQorfQ0KKw0KICNlbmRpZiAvKiBD T05GSUdfQVJNX1ZJUlRVQUxfSU9NTVUgKi8NCiANCiAjZW5kaWYgLyogX19BUkNIX0FSTV9WSU9N TVVfSF9fICovDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvS2NvbmZpZyBi L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL0tjb25maWcNCmluZGV4IGE5MmNmYmVhOTguLjQwZDA3 MjgyMmYgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9LY29uZmlnDQorKysg Yi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9LY29uZmlnDQpAQCAtNDAsNiArNDAsMTQgQEAgY29u ZmlnIEFSTV9WSVJUVUFMX0lPTU1VDQogCWhlbHANCiAJICBTdXBwb3J0IHZpcnR1YWwgSU9NTVUg aW5mcmFzdHJ1Y3R1cmUgdG8gaW1wbGVtZW50IHZJT01NVS4NCiANCitjb25maWcgVklSVFVBTF9B Uk1fU01NVV9WMw0KKwlib29sICJBUk0gTHRkLiBWaXJ0dWFsIFNNTVV2MyBTdXBwb3J0IChVTlNV UFBPUlRFRCkiDQorCWRlcGVuZHMgb24gQVJNX1NNTVVfVjMgJiYgQVJNX1ZJUlRVQUxfSU9NTVUN CisJaGVscA0KKwkgU3VwcG9ydCBmb3IgaW1wbGVtZW50YXRpb25zIG9mIHRoZSB2aXJ0dWFsIEFS TSBTeXN0ZW0gTU1VIGFyY2hpdGVjdHVyZQ0KKwkgdmVyc2lvbiAzLiBWaXJ0dWFsIFNNTVV2MyBp cyB1bnN1cHBvcnRlZCBmZWF0dXJlIGFuZCBzaG91bGQgbm90IGJlIHVzZWQNCisJIGluIHByb2R1 Y3Rpb24uDQorDQogZW5kaWYNCiANCiBjb25maWcgQU1EX0lPTU1VDQpkaWZmIC0tZ2l0IGEveGVu L2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL01ha2VmaWxlIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91 Z2gvYXJtL01ha2VmaWxlDQppbmRleCBjMzc4MzE4OGUzLi5jOGYwYTVmODAyIDEwMDY0NA0KLS0t IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL01ha2VmaWxlDQorKysgYi94ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9hcm0vTWFrZWZpbGUNCkBAIC0zLDMgKzMsNCBAQCBvYmotJChDT05GSUdf QVJNX1NNTVUpICs9IHNtbXUubw0KIG9iai0kKENPTkZJR19JUE1NVV9WTVNBKSArPSBpcG1tdS12 bXNhLm8NCiBvYmotJChDT05GSUdfQVJNX1NNTVVfVjMpICs9IHNtbXUtdjMubw0KIG9iai0kKENP TkZJR19BUk1fVklSVFVBTF9JT01NVSkgKz0gdmlvbW11Lm8NCitvYmotJChDT05GSUdfVklSVFVB TF9BUk1fU01NVV9WMykgKz0gdnNtbXUtdjMubw0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bh c3N0aHJvdWdoL2FybS9zbW11LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21t dS12My5jDQppbmRleCBiZDA2ODk2NjRiLi4yMWI4MmViYTg1IDEwMDY0NA0KLS0tIGEveGVuL2Ry aXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYw0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvYXJtL3NtbXUtdjMuYw0KQEAgLTkzLDYgKzkzLDcgQEANCiAjaW5jbHVkZSA8YXNtL3Bs YXRmb3JtLmg+DQogDQogI2luY2x1ZGUgInNtbXUtdjMuaCINCisjaW5jbHVkZSAidnNtbXUtdjMu aCINCiANCiAjZGVmaW5lIEFSTV9TTU1VX1ZUQ1JfU0hfSVMJCTMNCiAjZGVmaW5lIEFSTV9TTU1V X1ZUQ1JfUkdOX1dCV0EJCTENCkBAIC0yODI5LDYgKzI4MzAsOSBAQCBzdGF0aWMgaW50IF9faW5p dCBhcm1fc21tdV9kZXZpY2VfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikNCiAJ bGlzdF9hZGQoJnNtbXUtPmRldmljZXMsICZhcm1fc21tdV9kZXZpY2VzKTsNCiAJc3Bpbl91bmxv Y2soJmFybV9zbW11X2RldmljZXNfbG9jayk7DQogDQorCS8qIEFkZCB0byBob3N0IElPTU1VIGxp c3QgdG8gaW5pdGlhbGl6ZSB2SU9NTVUgZm9yIGRvbTAgKi8NCisJYWRkX3RvX2hvc3RfaW9tbXVf bGlzdChpb2FkZHIsIGlvc2l6ZSwgZGV2X3RvX2R0KHBkZXYpKTsNCisNCiAJcmV0dXJuIDA7DQog DQogDQpAQCAtMzE4MSw2ICszMTg1LDkgQEAgc3RhdGljIF9faW5pdCBpbnQgYXJtX3NtbXVfZHRf aW5pdChzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmRldiwNCiANCiAJcGxhdGZvcm1fZmVhdHVyZXMg Jj0gc21tdS0+ZmVhdHVyZXM7DQogDQorCS8qIFNldCB2SU9NTVUgdHlwZSB0byBTTU1VdjMgKi8N CisJdnNtbXV2M19zZXRfdHlwZSgpOw0KKw0KIAlyZXR1cm4gMDsNCiB9DQogDQpkaWZmIC0tZ2l0 IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3Zpb21tdS5jIGIveGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvYXJtL3Zpb21tdS5jDQppbmRleCAwYzBlZmQ2NjhlLi4zNDAxZTRmN2Q5IDEwMDY0 NA0KLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3Zpb21tdS5jDQorKysgYi94ZW4v ZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlvbW11LmMNCkBAIC0yLDEyICsyLDU0IEBADQogDQog I2luY2x1ZGUgPHhlbi9lcnJuby5oPg0KICNpbmNsdWRlIDx4ZW4vaW5pdC5oPg0KKyNpbmNsdWRl IDx4ZW4vaXJxLmg+DQogI2luY2x1ZGUgPHhlbi90eXBlcy5oPg0KKyNpbmNsdWRlIDx4ZW4vc2No ZWQuaD4NCiANCiAjaW5jbHVkZSA8YXNtL3Zpb21tdS5oPg0KIA0KKy8qIExpc3Qgb2YgYWxsIGhv c3QgSU9NTVVzICovDQorTElTVF9IRUFEKGhvc3RfaW9tbXVfbGlzdCk7DQorDQogLyogU3RydWN0 IHRvIGhvbGQgdGhlIHZJT01NVSBvcHMgYW5kIHZJT01NVSB0eXBlICovDQogc3RhdGljIGNvbnN0 IHN0cnVjdCB2aW9tbXVfZGVzYyBfX3JvX2FmdGVyX2luaXQgKmN1cl92aW9tbXU7DQorc3RhdGlj IGJvb2wgaG9zdF9pb21tdV9saXN0X2luY29tcGxldGU7DQorDQorLyogQ29tbW9uIGZ1bmN0aW9u IGZvciBhZGRpbmcgdG8gaG9zdF9pb21tdV9saXN0ICovDQordm9pZCBfX2luaXQgYWRkX3RvX2hv c3RfaW9tbXVfbGlzdChwYWRkcl90IGFkZHIsIHBhZGRyX3Qgc2l6ZSwNCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlKQ0KK3sNCisg ICAgc3RydWN0IGhvc3RfaW9tbXUgKmlvbW11X2RhdGE7DQorICAgIGludCBpcnE7DQorDQorICAg IGlvbW11X2RhdGEgPSB4emFsbG9jKHN0cnVjdCBob3N0X2lvbW11KTsNCisgICAgaWYgKCAhaW9t bXVfZGF0YSApDQorICAgIHsNCisgICAgICAgIGhvc3RfaW9tbXVfbGlzdF9pbmNvbXBsZXRlID0g dHJ1ZTsNCisgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORw0KKyAgICAgICAgICAgICAgICJ2 SU9NTVU6IENhbm5vdCBhbGxvY2F0ZSBtZW1vcnkgZm9yIGhvc3QgSU9NTVUgZGF0YVxuIik7DQor ICAgICAgICByZXR1cm47DQorICAgIH0NCisNCisgICAgaW9tbXVfZGF0YS0+YWRkciA9IGFkZHI7 DQorICAgIGlvbW11X2RhdGEtPnNpemUgPSBzaXplOw0KKyAgICBpb21tdV9kYXRhLT5kdF9ub2Rl ID0gbm9kZTsNCisgICAgaXJxID0gcGxhdGZvcm1fZ2V0X2lycShub2RlLCAwKTsNCisgICAgaWYg KCBpcnEgPCAwICkNCisgICAgew0KKyAgICAgICAgaG9zdF9pb21tdV9saXN0X2luY29tcGxldGUg PSB0cnVlOw0KKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HDQorICAgICAgICAgICAgICAg InZJT01NVTogZGlzYWJsaW5nIHN1cHBvcnQgYmVjYXVzZSBJT01NVSBAMHglIlBSSXg2NA0KKyAg ICAgICAgICAgICAgICIgaGFzIG5vIHVzYWJsZSBJUlEgKCVkKVxuIiwgYWRkciwgaXJxKTsNCisg ICAgICAgIHhmcmVlKGlvbW11X2RhdGEpOw0KKyAgICAgICAgcmV0dXJuOw0KKyAgICB9DQorICAg IGlvbW11X2RhdGEtPmlycSA9IGlycTsNCisNCisgICAgcHJpbnRrKCJ2SU9NTVU6IEZvdW5kIElP TU1VIEAweCUiUFJJeDY0IlxuIiwgYWRkcik7DQorDQorICAgIGxpc3RfYWRkX3RhaWwoJmlvbW11 X2RhdGEtPmVudHJ5LCAmaG9zdF9pb21tdV9saXN0KTsNCit9DQogDQogaW50IGRvbWFpbl92aW9t bXVfaW5pdChzdHJ1Y3QgZG9tYWluICpkLCB1aW50OF90IHZpb21tdV90eXBlKQ0KIHsNCkBAIC0z MywxMiArNzUsNTEgQEAgaW50IHZpb21tdV9yZWxpbnF1aXNoX3Jlc291cmNlcyhzdHJ1Y3QgZG9t YWluICpkKQ0KIA0KIHVpbnQ4X3QgdmlvbW11X2dldF90eXBlKHZvaWQpDQogew0KLSAgICBpZiAo ICFjdXJfdmlvbW11ICkNCisgICAgaWYgKCAhY3VyX3Zpb21tdSB8fCBob3N0X2lvbW11X2xpc3Rf aW5jb21wbGV0ZSB8fA0KKyAgICAgICAgIGxpc3RfZW1wdHkoJmhvc3RfaW9tbXVfbGlzdCkgKQ0K ICAgICAgICAgcmV0dXJuIFhFTl9ET01DVExfQ09ORklHX1ZJT01NVV9OT05FOw0KIA0KICAgICBy ZXR1cm4gY3VyX3Zpb21tdS0+dmlvbW11X3R5cGU7DQogfQ0KIA0KK3ZvaWQgX19pbml0IHNldF9j dXJfdmlvbW11KGNvbnN0IHN0cnVjdCB2aW9tbXVfZGVzYyAqZGVzYykNCit7DQorICAgIGlmICgg Y3VyX3Zpb21tdSAmJiAoY3VyX3Zpb21tdSAhPSBkZXNjKSApDQorICAgIHsNCisgICAgICAgIHBy aW50aygiV0FSTklORzogQ2Fubm90IHNldCB2SU9NTVUsIGFscmVhZHkgc2V0IHRvIGEgZGlmZmVy ZW50IHZhbHVlXG4iKTsNCisgICAgICAgIHJldHVybjsNCisgICAgfQ0KKw0KKyAgICBjdXJfdmlv bW11ID0gZGVzYzsNCit9DQorDQordW5zaWduZWQgaW50IGRvbWFpbl92aW9tbXVfZ2V0X251bV9t bWlvX2hhbmRsZXJzKHN0cnVjdCBkb21haW4gKmQpDQorew0KKyAgICBpZiAoIGlzX2hhcmR3YXJl X2RvbWFpbihkKSApDQorICAgIHsNCisgICAgICAgIHN0cnVjdCBob3N0X2lvbW11ICpod19pb21t dTsNCisgICAgICAgIGludCBjb3VudCA9IDA7DQorDQorICAgICAgICAvKg0KKyAgICAgICAgKiBG b3IgaGFyZHdhcmUgZG9tYWluLCB2SU9NTVUgcGVyIHBJT01NVSBpcyBleHBvc2VkLiBOdW1iZXIg b2YNCisgICAgICAgICogcmVnaW9ucyByZXF1aXJlZCBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gc3Bh Y2UgaXMgZXF1YWwgdG8gbnVtYmVyIG9mDQorICAgICAgICAqIGhvc3QgSU9NTVVzLg0KKyAgICAg ICAgKi8NCisgICAgICAgIGxpc3RfZm9yX2VhY2hfZW50cnkoaHdfaW9tbXUsICZob3N0X2lvbW11 X2xpc3QsIGVudHJ5KQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIGNvdW50Kys7DQorICAgICAg ICB9DQorDQorICAgICAgICByZXR1cm4gY291bnQ7DQorICAgIH0NCisNCisgICAgLyoNCisgICAg ICogRm9yIHVucHJpdmlsaWdlZCBkb21haW5zLCBzaW5nbGUgdklPTU1VIGlzIGV4cG9zZWQgYW5k IHJlcXVpcmVzIG9uZQ0KKyAgICAgKiByZWdpb24gdG8gY292ZXIgdGhlIGNvbmZpZ3VyYXRpb24g c3BhY2UuDQorICAgICAqLw0KKyAgICByZXR1cm4gMTsNCit9DQorDQogLyoNCiAgKiBMb2NhbCB2 YXJpYWJsZXM6DQogICogbW9kZTogQw0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJv dWdoL2FybS92c21tdS12My5jIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYz LmMNCm5ldyBmaWxlIG1vZGUgMTAwNjQ0DQppbmRleCAwMDAwMDAwMDAwLi5lYTNiNWJiMzRkDQot LS0gL2Rldi9udWxsDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMu Yw0KQEAgLTAsMCArMSwxMTggQEANCisvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogKEdQTC0y LjAtb3ItbGF0ZXIgT1IgQlNELTItQ2xhdXNlKSAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vcGFyYW0u aD4NCisjaW5jbHVkZSA8eGVuL3NjaGVkLmg+DQorI2luY2x1ZGUgPGFzbS9tbWlvLmg+DQorI2lu Y2x1ZGUgPGFzbS92aW9tbXUuaD4NCisNCitzdHJ1Y3QgdmlydF9zbW11IHsNCisgICAgc3RydWN0 ICAgICAgZG9tYWluICpkOw0KKyAgICBzdHJ1Y3QgICAgICBsaXN0X2hlYWQgdmlvbW11X2xpc3Q7 DQorfTsNCisNCitzdGF0aWMgaW50IHZzbW11djNfbW1pb193cml0ZShzdHJ1Y3QgdmNwdSAqdiwg bW1pb19pbmZvX3QgKmluZm8sDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnaXN0 ZXJfdCByLCB2b2lkICpwcml2KQ0KK3sNCisgICAgQlVHX09OKCJ1bmltcGxlbWVudGVkIik7DQor ICAgIHJldHVybiBJT19IQU5ETEVEOw0KK30NCisNCitzdGF0aWMgaW50IHZzbW11djNfbW1pb19y ZWFkKHN0cnVjdCB2Y3B1ICp2LCBtbWlvX2luZm9fdCAqaW5mbywNCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHJlZ2lzdGVyX3QgKnIsIHZvaWQgKnByaXYpDQorew0KKyAgICBCVUdfT04o InVuaW1wbGVtZW50ZWQiKTsNCisgICAgcmV0dXJuIElPX0hBTkRMRUQ7DQorfQ0KKw0KK3N0YXRp YyBjb25zdCBzdHJ1Y3QgbW1pb19oYW5kbGVyX29wcyB2c21tdXYzX21taW9faGFuZGxlciA9IHsN CisgICAgLnJlYWQgID0gdnNtbXV2M19tbWlvX3JlYWQsDQorICAgIC53cml0ZSA9IHZzbW11djNf bW1pb193cml0ZSwNCit9Ow0KKw0KK3N0YXRpYyBpbnQgdnNtbXV2M19pbml0X3NpbmdsZShzdHJ1 Y3QgZG9tYWluICpkLCBwYWRkcl90IGFkZHIsIHBhZGRyX3Qgc2l6ZSkNCit7DQorICAgIHN0cnVj dCB2aXJ0X3NtbXUgKnNtbXU7DQorDQorICAgIHNtbXUgPSB4emFsbG9jKHN0cnVjdCB2aXJ0X3Nt bXUpOw0KKyAgICBpZiAoICFzbW11ICkNCisgICAgICAgIHJldHVybiAtRU5PTUVNOw0KKw0KKyAg ICBzbW11LT5kID0gZDsNCisNCisgICAgcmVnaXN0ZXJfbW1pb19oYW5kbGVyKGQsICZ2c21tdXYz X21taW9faGFuZGxlciwgYWRkciwgc2l6ZSwgc21tdSk7DQorDQorICAgIC8qIFJlZ2lzdGVyIHRo ZSB2SU9NTVUgdG8gYmUgYWJsZSB0byBjbGVhbiBpdCB1cCBsYXRlci4gKi8NCisgICAgbGlzdF9h ZGRfdGFpbCgmc21tdS0+dmlvbW11X2xpc3QsICZkLT5hcmNoLnZpb21tdV9saXN0KTsNCisNCisg ICAgcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgZG9tYWluX3ZzbW11djNfaW5pdChzdHJ1 Y3QgZG9tYWluICpkKQ0KK3sNCisgICAgaW50IHJldDsNCisNCisgICAgSU5JVF9MSVNUX0hFQUQo JmQtPmFyY2gudmlvbW11X2xpc3QpOw0KKw0KKyAgICBpZiAoIGlzX2hhcmR3YXJlX2RvbWFpbihk KSApDQorICAgIHsNCisgICAgICAgIHN0cnVjdCBob3N0X2lvbW11ICpod19pb21tdTsNCisNCisg ICAgICAgIGxpc3RfZm9yX2VhY2hfZW50cnkoaHdfaW9tbXUsICZob3N0X2lvbW11X2xpc3QsIGVu dHJ5KQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIHJldCA9IHZzbW11djNfaW5pdF9zaW5nbGUo ZCwgaHdfaW9tbXUtPmFkZHIsIGh3X2lvbW11LT5zaXplKTsNCisgICAgICAgICAgICBpZiAoIHJl dCApDQorICAgICAgICAgICAgICAgIHJldHVybiByZXQ7DQorICAgICAgICB9DQorICAgIH0NCisg ICAgZWxzZQ0KKyAgICB7DQorICAgICAgICByZXQgPSB2c21tdXYzX2luaXRfc2luZ2xlKGQsIEdV RVNUX1ZTTU1VVjNfQkFTRSwgR1VFU1RfVlNNTVVWM19TSVpFKTsNCisgICAgICAgIGlmICggcmV0 ICkNCisgICAgICAgICAgICByZXR1cm4gcmV0Ow0KKyAgICB9DQorDQorICAgIHJldHVybiAwOw0K K30NCisNCitzdGF0aWMgaW50IHZzbW11djNfcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRv bWFpbiAqZCkNCit7DQorICAgIHN0cnVjdCB2aXJ0X3NtbXUgKnBvcywgKnRlbXA7DQorDQorICAg IC8qIENvcGUgd2l0aCB1bmluaXRpYWxpemVkIHZJT01NVSAqLw0KKyAgICBpZiAoIGxpc3RfaGVh ZF9pc19udWxsKCZkLT5hcmNoLnZpb21tdV9saXN0KSApDQorICAgICAgICByZXR1cm4gMDsNCisN CisgICAgbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBvcywgdGVtcCwgJmQtPmFyY2gudmlvbW11 X2xpc3QsIHZpb21tdV9saXN0ICkNCisgICAgew0KKyAgICAgICAgbGlzdF9kZWwoJnBvcy0+dmlv bW11X2xpc3QpOw0KKyAgICAgICAgeGZyZWUocG9zKTsNCisgICAgfQ0KKw0KKyAgICByZXR1cm4g MDsNCit9DQorDQorc3RhdGljIGNvbnN0IHN0cnVjdCB2aW9tbXVfb3BzIHZzbW11djNfb3BzID0g ew0KKyAgICAuZG9tYWluX2luaXQgPSBkb21haW5fdnNtbXV2M19pbml0LA0KKyAgICAucmVsaW5x dWlzaF9yZXNvdXJjZXMgPSB2c21tdXYzX3JlbGlucXVpc2hfcmVzb3VyY2VzLA0KK307DQorDQor c3RhdGljIGNvbnN0IHN0cnVjdCB2aW9tbXVfZGVzYyB2c21tdXYzX2Rlc2MgPSB7DQorICAgIC5v cHMgPSAmdnNtbXV2M19vcHMsDQorICAgIC52aW9tbXVfdHlwZSA9IFhFTl9ET01DVExfQ09ORklH X1ZJT01NVV9TTU1VVjMsDQorfTsNCisNCit2b2lkIF9faW5pdCB2c21tdXYzX3NldF90eXBlKHZv aWQpDQorew0KKyAgICBjb25zdCBzdHJ1Y3QgdmlvbW11X2Rlc2MgKmRlc2MgPSAmdnNtbXV2M19k ZXNjOw0KKw0KKyAgICBzZXRfY3VyX3Zpb21tdShkZXNjKTsNCit9DQorDQorLyoNCisgKiBMb2Nh bCB2YXJpYWJsZXM6DQorICogbW9kZTogQw0KKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCisgKiBj LWJhc2ljLW9mZnNldDogNA0KKyAqIGluZGVudC10YWJzLW1vZGU6IG5pbA0KKyAqIEVuZDoNCisg Ki8NCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuaCBi L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5oDQpuZXcgZmlsZSBtb2RlIDEw MDY0NA0KaW5kZXggMDAwMDAwMDAwMC4uOWY0Yzg2YWJkNQ0KLS0tIC9kZXYvbnVsbA0KKysrIGIv eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmgNCkBAIC0wLDAgKzEsMjAgQEAN CisvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogKEdQTC0yLjAtb3ItbGF0ZXIgT1IgQlNELTIt Q2xhdXNlKSAqLw0KKyNpZm5kZWYgX19BUkNIX0FSTV9WU01NVV9WM19IX18NCisjZGVmaW5lIF9f QVJDSF9BUk1fVlNNTVVfVjNfSF9fDQorDQorI2luY2x1ZGUgPGFzbS92aW9tbXUuaD4NCisNCisj aWZkZWYgQ09ORklHX1ZJUlRVQUxfQVJNX1NNTVVfVjMNCisNCit2b2lkIHZzbW11djNfc2V0X3R5 cGUodm9pZCk7DQorDQorI2Vsc2UNCisNCitzdGF0aWMgaW5saW5lIHZvaWQgX19pbml0IHZzbW11 djNfc2V0X3R5cGUodm9pZCkNCit7DQorICAgIHJldHVybjsNCit9DQorDQorI2VuZGlmIC8qIENP TkZJR19WSVJUVUFMX0FSTV9TTU1VX1YzICovDQorDQorI2VuZGlmIC8qIF9fQVJDSF9BUk1fVlNN TVVfVjNfSF9fICovDQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgg Yi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaA0KaW5kZXggYTE0OTFmOWNmNy4uODg2M2Uy ZTQ1NyAxMDA2NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oDQorKysgYi94 ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaA0KQEAgLTMzNSw2ICszMzUsNyBAQCBERUZJTkVf WEVOX0dVRVNUX0hBTkRMRSh2Y3B1X2d1ZXN0X2NvbnRleHRfdCk7DQogI2RlZmluZSBYRU5fRE9N Q1RMX0NPTkZJR19BUk1fVjhSX0VMMV9NU0FfVk1TQSAgICAyDQogDQogI2RlZmluZSBYRU5fRE9N Q1RMX0NPTkZJR19WSU9NTVVfTk9ORSAgIDANCisjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX1ZJ T01NVV9TTU1VVjMgMQ0KIA0KIHN0cnVjdCB4ZW5fYXJjaF9kb21haW5jb25maWcgew0KICAgICAv KiBJTi9PVVQgKi8NCkBAIC00NjMsNiArNDY0LDEwIEBAIHR5cGVkZWYgdWludDY0X3QgeGVuX2Nh bGxiYWNrX3Q7DQogI2RlZmluZSBHVUVTVF9HSUNWM19HSUNSMF9CQVNFICAgICB4ZW5fbWtfdWxs b25nKDB4MDMwMjAwMDApIC8qIHZDUFUwLi4xMjcgKi8NCiAjZGVmaW5lIEdVRVNUX0dJQ1YzX0dJ Q1IwX1NJWkUgICAgIHhlbl9ta191bGxvbmcoMHgwMTAwMDAwMCkNCiANCisvKiB2c21tdXYzIE1N SU8gbWFwcGluZ3MgKi8NCisjZGVmaW5lIEdVRVNUX1ZTTU1VVjNfQkFTRSAgICAgeGVuX21rX3Vs bG9uZygweDA0MDQwMDAwKQ0KKyNkZWZpbmUgR1VFU1RfVlNNTVVWM19TSVpFICAgICB4ZW5fbWtf dWxsb25nKDB4MDAwMjAwMDApDQorDQogLyoNCiAgKiAyNTYgTUIgaXMgcmVzZXJ2ZWQgZm9yIFZQ Q0kgY29uZmlndXJhdGlvbiBzcGFjZSBiYXNlZCBvbiBjYWxjdWxhdGlvbg0KICAqIDI1NiBidXNl cyB4IDMyIGRldmljZXMgeCA4IGZ1bmN0aW9ucyB4IDQgS0IgPSAyNTYgTUINCi0tIA0KMi40My4w DQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441818.1659359 (Exim 4.92) (envelope-from ) id 1xEFBS-0000ST-5o; Wed, 07 Oct 2026 00:06:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441818.1659359; Wed, 07 Oct 2026 00:06: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 1xEFBS-0000SH-2h; Wed, 07 Oct 2026 00:06:58 +0000 Received: by outflank-mailman (input) for mailman id 1441818; Wed, 07 Oct 2026 00:06:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBQ-0000OW-W3 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBQ-00Bv1m-Cm for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:56 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58ced-e002-0a2a0a5209dd-0a2a4502bac0-34 for ; Wed, 07 Oct 2026 02:06:56 +0200 Received: from [52.101.66.100] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d1f-6ca4-0a2a45020019-346542645a25-3 for ; Wed, 07 Oct 2026 02:06:56 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:52 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=c4WpK2p9fGPB6EVE90+yORPJHMZavqdfX7nQi2MWER/VJoQajR8B9G22NI6glgf0qA3VcO+Evf9FT+35G3i8LLVcScMsg8868t/YgT+JOHijMkKFQ+U/Ki4Pib4M82kYG+a9mB38E+utwkghqtt4lPs7qJK4m2UZH16PHoEwglLG2qO1nRn9QDQGBskvd8e22hs1bWoPZ61XHJC7BU9cYtaRFbOyZlgJNkcA8CmzZk8fG7DI3oyKVOKCTP1ZQacfSn+cMj88JZDVNgLvs9qyeHWOnJHhD9MKTtyUwF7h93lqhOYAktVXfklvFcUxpO5yB0Vexu8QqmQV1xSiZVKKMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=waWPdQQaCGkR+cSpUVpVW9A537eQS/GWZkaC8Wjj8sM=; b=GGSLWOil+4FtpLp2ErH9Wui7UA7OVSu/Sf9rPGJZ1EPzbTDXyFeQgmYEQaJFMuj/hZV5LjwvxPLuxhmJ3Qiw6lT+b6HaxjatJpgevup19N1Pd2KWkJ6UoO2WgjOqZIFjZ13R0+C47UlgoflT4B1WkxGCoKftT3cmuePUrbIUBq9BRQ0mXc3LShoBo09LPA2Xz4F+HNw9gAC+NccgwlqgKaP1yiHdJct05imBl0pL4Ea3SEQ3f9ThtWFrihL7s4Fjs3iw8SFDPYm2VAXWEJ8KLq3V5renR7z6DBjJE5XmxXKM6kKR53sqmevuRWtpl92WX3Wa8lLRdTynHpjVdH4j/A== 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=waWPdQQaCGkR+cSpUVpVW9A537eQS/GWZkaC8Wjj8sM=; b=BXExGWmkJKfu7+2PLksLCfxnEpedJGLY66RzQB2/O/hHm+vDiHl3WYfNhTiD5YbN/KMTHrZj2QuR4nh4Lo1cLCHdRO89JEQWeLc7eC4F3alreUqL1in1W3vQ/LPM/TArmChSAENMuWhGwtaGaVbGEYSGMiPvHmhLBB58fs+jkrS/aMVP5NzCYsDJ6FgvcIy8AIeAWajQYKnikGU1DNprB47WsyR1tPjiuW+6nUZ8f+FhMQ09pcxaNMPUjAojs7epYKi6kFHV24pIK0ICWfVnG9uv1VaeWcHXVo63wcoVKxb1+SFMxoiz3IbhaD6Q+mXsJIHCOaTSdpw1rREIquq6Vg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Anthony PERARD , Nick Rosbrook , George Dunlap , Juergen Gross , Milan Djokic Subject: [PATCH v4 06/22] tools: Add XEN_DOMCTL_CONFIG_VIOMMU_* and viommu config param Thread-Topic: [PATCH v4 06/22] tools: Add XEN_DOMCTL_CONFIG_VIOMMU_* and viommu config param Thread-Index: AQHdVe/Bly2nFNuSGkmmRKsHJLvWBw== Date: Wed, 7 Oct 2026 00:06:52 +0000 Message-ID: <37bf60a30d5261cf5152c3034193c3aebc2964d3.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 81f995c2-e886-461c-2096-08df2406e418 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: 3wVqks9R7En4geBT9Oe1q7CYtGJzMhvtZKi76LhF6TH4YjmKU9hNjdptrWN3r+ovNdyt0vQHCVnnB1PE416QzJxq5W+OGmjXBkgBqBpiZGjVna7by/F3uM+1ywwrWjBaniT60AzR6kVRBs3v4GnIE08UPK0nfhuDydrjxzxvlw0XW4AXvSBio1KKQc2JNKdCRsG/c4m9QLgPxVbZSrF22tw0rhJ7rJgLrzqq4Ctt6BLOewxxDEkEv0jvQxo6T+nVO5GX4LporU1dkhpmAm9MpTmtmHMiElhEe+yRIq8LZRuZdBtX/RvNjdBxlsWUfZaJSZRQMuR2s0q9VHhxmMgC8ssZWNjhEyOA4+mdfsgFhIEHG6r85d1ISBVi4HnccSaF3WsdKr+0iWIG49Yzwc3BVWejHKga9iv7lKW1ZW/Mv8bc2iDpt52LlAFgz0ZcwHGRzkLIMcmEYrkt3KkAe7Bb7ksDoaRb1TzsV/HzazHbIeZiyE/JhivwmD9csgX28qzJbwhyq3sdkiKMj3m8ky8JU3hORgX1OsQJU/mCR7uRwZxYh+YUtd9yyHpUd6DdcgxJUzDk0v1xx9O8BCnN41Q3LnMHim/5opHMPlRX9OSsdu0CEvyfqQx51O4SMVmF0gCFL4OVAwO0Nl2A9UKxk/7IhDIGGPLch2Kw/ciPec9zJWjsyfnISkye21qC0XmSsOzckgiFh11eBqhJs8/6Qpaol1wVlMKdSDFD8nxt8a7QC6g= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VGpudFVTNVdubnV0a0QweDJKWE4wZUpOMFR6elVMakNISVREVmhWNjFWdU9y?= =?utf-8?B?QXovbTVyUGoxYTA3RmJrd2dsUEZnd0pEWTlkL0lwL2k4QWlFSXBMbFQ2UnFp?= =?utf-8?B?SFU3UG9SQmRTTDFjNC8vU1BCVERPTk1IZWlXR2NoU1hmMVVYNUJocXJxRUIr?= =?utf-8?B?RlE3dkRheE5wSkQxMWVma1k4Q1I2VWdKWU13bGcwRWx1SWl3NWM3SFhVL0JN?= =?utf-8?B?SGdjdDJPb3YzekV2Um4yZGx1NS9KV1F0Q1dsZWhVbXRqWURZZ1FYQWw0TGJ6?= =?utf-8?B?ZEtzYStQbGpvQ0NDa0JuRFlMWGU1dUZHWldJSEZxMlFYRGpvcVVpUHlzVGtS?= =?utf-8?B?Z1NlaTY3UVJ6dkdJT1VhRjltUlZDcGFZelZmSXgvZEdFVjRLbTlaM052d0ls?= =?utf-8?B?U2JmczFCU1lRc2RPUmZ1UytXcU8yaGZydFB2TDZORVNFbkVBWlNJcnFkUlRv?= =?utf-8?B?ZU9QSldoT3ZNRDhiakRqdU5HTDFrUFJGZFdWaXpTS1ZNdnVmOTFteU9TOWZB?= =?utf-8?B?RnZBdXNNYWJIM3IwV0EveWN3a0FBTzA1a2Fnckw5ZHRvU3BhcmxGY3pZV3ZK?= =?utf-8?B?c3FLaGl2QzdkTURUQ2tkMndwWG9UbVJVeVc0cnBGeFFhM0gzczZ6S0R1ZEs1?= =?utf-8?B?a081NXJsS2pLdjNvNUFRWEFGM28zYm51bGRKUVJsL3ZsVUpFY0RxZlVNWS8x?= =?utf-8?B?SGVZMnNlUDdQaFVrczFrY3JhS0lYTzVXZ2NmSmlubllTL3M5ZzlJcm1xdDRm?= =?utf-8?B?MGFwT0NYOEUxTkp5Z3RUWHlyOWUyWllROHFneGo4WFBmQms1VEZSOCtsaWFZ?= =?utf-8?B?ZXJQSGttODgwVE14OThYVS96UjgrbStIQ0ZLelp0TUk5ZTlFYWJndTJQTFFB?= =?utf-8?B?Z3lvcEFQd1o0RHRtRzFHUytyTTlxTkhqNzduSlB3SS9lRkxwOFprQ29OUlRS?= =?utf-8?B?T0ZSdFcyUFZPNTM2cGI0eEFVTC90NVgyOGFMRld0Nlc5djliMDlBLy85dTVo?= =?utf-8?B?bTRIaGtBdXMzdWcxTWRoaUwwNmNzQklFZjRtTUJPcUFCNjd2c0xxMEhXYk12?= =?utf-8?B?Q2ZBRW02eDJEMnhQK2MxRTZKbXFRVFdhMXBYc0F5Mk1NN1l4NHNNM0xzR096?= =?utf-8?B?TDNVVUdDUTJ5YmpkTVdQMDJpdlZ0UlNwUnRVci9aQ3RibmZ4TXVQQUFFZjQz?= =?utf-8?B?NDRDeVFqZ0IvUEpTSkYzVnorcW8wbXl4SUlrSXRpbXJxeFFhSWNRWTNDSS9x?= =?utf-8?B?SUlYb1EwSlgvNnFXVEhBV0RUTG9oR0laNjJET21KaTFvdXlMc2N4Q0krb1lG?= =?utf-8?B?UVFLaHFrUFpScmsvdVFlTkRENDIydUhYZEdpSzRTUG9TMkFzQVo2ZkkyKzhF?= =?utf-8?B?RkgyUFdKRjNqb1ZORFNNSVFoR01wTE1BbFpzd2lYQldoak9xU2h5ajE4NkV5?= =?utf-8?B?WndjRVFjTVhFbFZWVjJ2YnZzS0o2cktjbFE4NklXT05ubEFnRnY5U3pMRW1C?= =?utf-8?B?QmM1WUJxbS9nZHNiQ2FWb05zZXFIaDQ3aVo0bmZ0Wk5YSmdER3dOVzlFZi9B?= =?utf-8?B?VFRDemFSTGhodzVZQXNQaE43R0w4Q1BScExrK3ZiUVd3bHBJbmFSRFlCL2p3?= =?utf-8?B?Vm1wMzhFT3FlUVdQa1BaSHVFMUhpTUk5Tjh4QXdOSmdxUnRhaE00UzRFb0dM?= =?utf-8?B?ck02a0tGb3ZJTTBodXQzdnlBeEtQOGdiYUdWNWdlNnBLZ3htajFxVm5zM1J3?= =?utf-8?B?b3lSVzNveDJmT2JQVlMzOUVpVHloZGRsRExGeU8vSHdaYlJMeHVQMzVDN25Z?= =?utf-8?B?cy9uc3dqQjRXdG8rUDdKTXd1bUVuQ3gwcU82Z0J6Tll0VWphNVRXYUY1aDRL?= =?utf-8?B?UUdHdTBvM1lNMG5haUdTM3htdlBJYkdCWmVTVUZoSDNYS0ZRN25ucEJidmZv?= =?utf-8?B?dzEzSVN2M1hkMzdUeWYwaWI0TGR2d2dXZmU1RzB5NnYyZHl0Q3l2RThRTVY4?= =?utf-8?B?MWhqQm82VytPUnFmOWtGSEtRZmNzZFEzT05YeTBGd3BaNWlmWllaWlJrQnNP?= =?utf-8?B?RUR2S3ptK1UwMExwc3NQTTFHRXlHSnJpdDhYRVk2WVYzZ1k5TnpUbTBGRUtK?= =?utf-8?B?WHhsVUVvOEV6a0gyQk1EZDNXZ0NIODNOSGR1VU1VRjRMRnNWc0Q0QTBHUlZD?= =?utf-8?B?OUUwTVp3bDcyRkpndFZ1ZVNmRUhPNy8rYmZ1ZmdiTSs4ckMrMTJsMUdOMzVR?= =?utf-8?B?TUtwWVRXTERxNUJSWGJxMzQ0ejFCREowenJLYkdubUUxTEhYbmw2clhNMEJh?= =?utf-8?B?YXE3aWxKWTVic1JHTUZzTGxZVjFTV0JEb3F2OFpXR09CQVFHclZDQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81f995c2-e886-461c-2096-08df2406e418 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:52.4703 (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: T+rzMSBnQf4sng+xCZvj0I6Amv1YkL5zkyi6MDdkDV+kPA8zL8XNrtkAHf5mbGBjIer0X29OjR4rD3VdDvCTxg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-720697/1791331616-66CB22AC-10AD2ADD/0/0 X-purgate-type: clean X-purgate-size: 8976 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkFkZCBuZXcgdmlvbW11 X3R5cGUgZmllbGQgYW5kIGZpZWxkIHZhbHVlcyBYRU5fRE9NQ1RMX0NPTkZJR19WSU9NTVVfTk9O RQ0KWEVOX0RPTUNUTF9DT05GSUdfVklPTU1VX1NNTVVWMyBpbiB4ZW5fYXJjaF9kb21haW5jb25m aWcgdG8NCmVuYWJsZS9kaXNhYmxlIHZJT01NVSBzdXBwb3J0IGZvciBkb21haW5zLg0KDQpBbHNv IGFkZCB2aW9tbXU9Ik4iIHBhcmFtZXRlciB0byB4bCBkb21haW4gY29uZmlndXJhdGlvbiB0byBl bmFibGUgdGhlDQp2SU9NTVUgZm9yIHRoZSBkb21haW5zLiBDdXJyZW50bHksIG9ubHkgdGhlICJz bW11djMiIHR5cGUgaXMgc3VwcG9ydGVkDQpmb3IgQVJNLg0KDQpTaWduZWQtb2ZmLWJ5OiBSYWh1 bCBTaW5naCA8cmFodWwuc2luZ2hAYXJtLmNvbT4NClNpZ25lZC1vZmYtYnk6IE1pbGFuIERqb2tp YyA8bWlsYW5fZGpva2ljQGVwYW0uY29tPg0KQWNrZWQtYnk6IE5pY2sgUm9zYnJvb2sgPGVucjBu QHVidW50dS5jb20+DQotLS0NCiBkb2NzL21hbi94bC5jZmcuNS5wb2QuaW4gICAgICAgICAgICAg fCAyMiArKysrKysrKysrKysrKysrKysrKysrDQogdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L2hlbHBl cnMuZ2VuLmdvIHwgIDIgKysNCiB0b29scy9nb2xhbmcveGVubGlnaHQvdHlwZXMuZ2VuLmdvICAg fCAgNyArKysrKysrDQogdG9vbHMvaW5jbHVkZS9saWJ4bC5oICAgICAgICAgICAgICAgIHwgIDUg KysrKysNCiB0b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jICAgICAgICAgfCAxMyArKysrKysr KysrKysrDQogdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwgICAgIHwgIDYgKysrKysr DQogdG9vbHMveGwveGxfcGFyc2UuYyAgICAgICAgICAgICAgICAgIHwgIDkgKysrKysrKysrDQog NyBmaWxlcyBjaGFuZ2VkLCA2NCBpbnNlcnRpb25zKCspDQoNCmRpZmYgLS1naXQgYS9kb2NzL21h bi94bC5jZmcuNS5wb2QuaW4gYi9kb2NzL21hbi94bC5jZmcuNS5wb2QuaW4NCmluZGV4IGQzNDk1 MWVkYjkuLjM1NWE3MzgxYzggMTAwNjQ0DQotLS0gYS9kb2NzL21hbi94bC5jZmcuNS5wb2QuaW4N CisrKyBiL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0KQEAgLTMxODUsNiArMzE4NSwyOCBAQCBv cHRpb24uDQogDQogPWJhY2sNCiANCis9b3ZlciA0DQorDQorPWl0ZW0gQjx2aW9tbXU9IlNUUklO RyI+DQorDQorRW5hYmxlIGFuIGVtdWxhdGVkIElPTU1VIGZvciB0aGUgZ3Vlc3QsIGFsbG93aW5n IHRoZSBndWVzdCB0byBjb25maWd1cmUNCitJT01NVSBzdGFnZS0xIHRyYW5zbGF0aW9uIGZvciBn dWVzdC1hc3NpZ25lZCBkZXZpY2VzIHByb3RlY3RlZCBieSB0aGUNCitJT01NVS4NCisNCitUbyBl bmFibGUgdGhlIGVtdWxhdGVkIElPTU1VLCBzcGVjaWZ5IHRoZSBmb2xsb3dpbmcgb3B0aW9uIGlu IHRoZSBWTQ0KK2NvbmZpZ3VyYXRpb24gZmlsZToNCisNCit2aW9tbXUgPSAic21tdXYzIg0KKw0K K0N1cnJlbnRseSwgb25seSB0aGUgInNtbXV2MyIgdHlwZSBpcyBzdXBwb3J0ZWQgb24gQVJNLg0K Kw0KK0ZvciB0aGlzIG9wdGlvbiB0byB0YWtlIGVmZmVjdCwgdGhlIHBhc3N0aHJvdWdoIG9wdGlv biBtdXN0IGFsc28gYmUNCitlbmFibGVkLiBFLmcuIGlmIHBhc3N0aHJvdWdoIGlzIGV4cGxpY2l0 bHkgZGlzYWJsZWQsIG9yIGltcGxpY2l0bHkgd2hlbiBubw0KK2RldmljZXMgcGFzc2VkIHRocm91 Z2ggdG8gdGhlIGd1ZXN0IHdoaWxlIHRoZSB2SU9NTVUgaXMgZW5hYmxlZCwgdGhlDQorZG9tYWlu IGNvbmZpZ3VyYXRpb24gaXMgaW52YWxpZCBhbmQgd2lsbCBiZSByZWZ1c2VkIGJ5IFhlbi4NCisN Cis9YmFjaw0KKw0KID1oZWFkMyB4ODYNCiANCiA9b3ZlciA0DQpkaWZmIC0tZ2l0IGEvdG9vbHMv Z29sYW5nL3hlbmxpZ2h0L2hlbHBlcnMuZ2VuLmdvIGIvdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L2hl bHBlcnMuZ2VuLmdvDQppbmRleCBiMGMwOWRhOTEwLi5iMjRjZmQwNTMzIDEwMDY0NA0KLS0tIGEv dG9vbHMvZ29sYW5nL3hlbmxpZ2h0L2hlbHBlcnMuZ2VuLmdvDQorKysgYi90b29scy9nb2xhbmcv eGVubGlnaHQvaGVscGVycy5nZW4uZ28NCkBAIC0xMjczLDYgKzEyNzMsNyBAQCB4LkFyY2hBcm0u TnJTcGlzID0gdWludDMyKHhjLmFyY2hfYXJtLm5yX3NwaXMpDQogaWYgZXJyIDo9IHguQXJjaEFy bS5Bcm1TY2kuZnJvbUMoJnhjLmFyY2hfYXJtLmFybV9zY2kpO2VyciAhPSBuaWwgew0KIHJldHVy biBmbXQuRXJyb3JmKCJjb252ZXJ0aW5nIGZpZWxkIEFyY2hBcm0uQXJtU2NpOiAldiIsIGVycikN CiB9DQoreC5BcmNoQXJtLlZpb21tdVR5cGUgPSBWaW9tbXVUeXBlKHhjLmFyY2hfYXJtLnZpb21t dV90eXBlKQ0KIGlmIGVyciA6PSB4LkFyY2hYODYuTXNyUmVsYXhlZC5mcm9tQygmeGMuYXJjaF94 ODYubXNyX3JlbGF4ZWQpO2VyciAhPSBuaWwgew0KIHJldHVybiBmbXQuRXJyb3JmKCJjb252ZXJ0 aW5nIGZpZWxkIEFyY2hYODYuTXNyUmVsYXhlZDogJXYiLCBlcnIpDQogfQ0KQEAgLTE4MTUsNiAr MTgxNiw3IEBAIHhjLmFyY2hfYXJtLm5yX3NwaXMgPSBDLnVpbnQzMl90KHguQXJjaEFybS5OclNw aXMpDQogaWYgZXJyIDo9IHguQXJjaEFybS5Bcm1TY2kudG9DKCZ4Yy5hcmNoX2FybS5hcm1fc2Np KTsgZXJyICE9IG5pbCB7DQogcmV0dXJuIGZtdC5FcnJvcmYoImNvbnZlcnRpbmcgZmllbGQgQXJj aEFybS5Bcm1TY2k6ICV2IiwgZXJyKQ0KIH0NCit4Yy5hcmNoX2FybS52aW9tbXVfdHlwZSA9IEMu bGlieGxfdmlvbW11X3R5cGUoeC5BcmNoQXJtLlZpb21tdVR5cGUpDQogaWYgZXJyIDo9IHguQXJj aFg4Ni5Nc3JSZWxheGVkLnRvQygmeGMuYXJjaF94ODYubXNyX3JlbGF4ZWQpOyBlcnIgIT0gbmls IHsNCiByZXR1cm4gZm10LkVycm9yZigiY29udmVydGluZyBmaWVsZCBBcmNoWDg2Lk1zclJlbGF4 ZWQ6ICV2IiwgZXJyKQ0KIH0NCmRpZmYgLS1naXQgYS90b29scy9nb2xhbmcveGVubGlnaHQvdHlw ZXMuZ2VuLmdvIGIvdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L3R5cGVzLmdlbi5nbw0KaW5kZXggZTBm ZDc4ZWMwMy4uZTMwNmY5YzFhYyAxMDA2NDQNCi0tLSBhL3Rvb2xzL2dvbGFuZy94ZW5saWdodC90 eXBlcy5nZW4uZ28NCisrKyBiL3Rvb2xzL2dvbGFuZy94ZW5saWdodC90eXBlcy5nZW4uZ28NCkBA IC01MzAsNiArNTMwLDEyIEBAIHR5cGUgQXJtU2NpIHN0cnVjdCB7DQogVHlwZSBBcm1TY2lUeXBl DQogfQ0KIA0KK3R5cGUgVmlvbW11VHlwZSBpbnQNCitjb25zdCgNCitWaW9tbXVUeXBlTm9uZSBW aW9tbXVUeXBlID0gMA0KK1Zpb21tdVR5cGVTbW11djMgVmlvbW11VHlwZSA9IDENCispDQorDQog dHlwZSBSZG1SZXNlcnZlIHN0cnVjdCB7DQogU3RyYXRlZ3kgUmRtUmVzZXJ2ZVN0cmF0ZWd5DQog UG9saWN5IFJkbVJlc2VydmVQb2xpY3kNCkBAIC02MTksNiArNjI1LDcgQEAgVnVhcnQgVnVhcnRU eXBlDQogU3ZlVmwgU3ZlVHlwZQ0KIE5yU3BpcyB1aW50MzINCiBBcm1TY2kgQXJtU2NpDQorVmlv bW11VHlwZSBWaW9tbXVUeXBlDQogfQ0KIEFyY2hYODYgc3RydWN0IHsNCiBNc3JSZWxheGVkIERl ZmJvb2wNCmRpZmYgLS1naXQgYS90b29scy9pbmNsdWRlL2xpYnhsLmggYi90b29scy9pbmNsdWRl L2xpYnhsLmgNCmluZGV4IDdjMDk4ZWRhYjYuLjFhZjg2MTM0OTkgMTAwNjQ0DQotLS0gYS90b29s cy9pbmNsdWRlL2xpYnhsLmgNCisrKyBiL3Rvb2xzL2luY2x1ZGUvbGlieGwuaA0KQEAgLTMxOCw2 ICszMTgsMTEgQEANCiAgKi8NCiAjZGVmaW5lIExJQlhMX0hBVkVfQlVJTERJTkZPX0FSQ0hfQVJN X1NDSSAxDQogDQorLyoNCisgKiBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyBoYXMgdGhlIGFyY2hf YXJtLnZpb21tdV90eXBlIGZpZWxkLg0KKyAqLw0KKyNkZWZpbmUgTElCWExfSEFWRV9CVUlMRElO Rk9fQVJDSF9BUk1fVklPTU1VIDENCisNCiAvKg0KICAqIExJQlhMX0hBVkVfU09GVF9SRVNFVCBp bmRpY2F0ZXMgdGhhdCBsaWJ4bCBzdXBwb3J0cyBwZXJmb3JtaW5nDQogICogJ3NvZnQgcmVzZXQn IGZvciBkb21haW5zIGFuZCB0aGVyZSBpcyAnc29mdF9yZXNldCcgc2h1dGRvd24gcmVhc29uDQpk aWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYyBiL3Rvb2xzL2xpYnMvbGln aHQvbGlieGxfYXJtLmMNCmluZGV4IDdlOWY4YTFiYzMuLmEyNDg3OTM1ODggMTAwNjQ0DQotLS0g YS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jDQorKysgYi90b29scy9saWJzL2xpZ2h0L2xp YnhsX2FybS5jDQpAQCAtMjQ3LDYgKzI0NywxOSBAQCBpbnQgbGlieGxfX2FyY2hfZG9tYWluX3By ZXBhcmVfY29uZmlnKGxpYnhsX19nYyAqZ2MsDQogICAgIH0NCiAgICAgTE9HKERFQlVHLCAiIC0g U0NJIHR5cGU9JXUiLCBjb25maWctPmFyY2guYXJtX3NjaV90eXBlKTsNCiANCisgICAgc3dpdGNo IChkX2NvbmZpZy0+Yl9pbmZvLmFyY2hfYXJtLnZpb21tdV90eXBlKSB7DQorICAgIGNhc2UgTElC WExfVklPTU1VX1RZUEVfTk9ORToNCisgICAgICAgIGNvbmZpZy0+YXJjaC52aW9tbXVfdHlwZSA9 IFhFTl9ET01DVExfQ09ORklHX1ZJT01NVV9OT05FOw0KKyAgICAgICAgYnJlYWs7DQorICAgIGNh c2UgTElCWExfVklPTU1VX1RZUEVfU01NVVYzOg0KKyAgICAgICAgY29uZmlnLT5hcmNoLnZpb21t dV90eXBlID0gWEVOX0RPTUNUTF9DT05GSUdfVklPTU1VX1NNTVVWMzsNCisgICAgICAgIGJyZWFr Ow0KKyAgICBkZWZhdWx0Og0KKyAgICAgICAgTE9HKEVSUk9SLCAiVW5rbm93biB2SU9NTVUgdHlw ZSAlZCIsDQorICAgICAgICAgICAgZF9jb25maWctPmJfaW5mby5hcmNoX2FybS52aW9tbXVfdHlw ZSk7DQorICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsNCisgICAgfQ0KKw0KICAgICByZXR1cm4g MDsNCiB9DQogDQpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwg Yi90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KaW5kZXggYTc4OTM0NjBmMC4uZjBh OWEyMWJhNCAxMDA2NDQNCi0tLSBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsDQor KysgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KQEAgLTU2MSw2ICs1NjEsMTEg QEAgbGlieGxfYXJtX3NjaSA9IFN0cnVjdCgiYXJtX3NjaSIsIFsNCiAgICAgKCJ0eXBlIiwgbGli eGxfYXJtX3NjaV90eXBlKSwNCiAgICAgXSkNCiANCitsaWJ4bF92aW9tbXVfdHlwZSA9IEVudW1l cmF0aW9uKCJ2aW9tbXVfdHlwZSIsIFsNCisgICAgKDAsICJub25lIiksDQorICAgICgxLCAic21t dXYzIikNCisgICAgXSwgaW5pdF92YWwgPSAiTElCWExfVklPTU1VX1RZUEVfTk9ORSIpDQorDQog bGlieGxfcmRtX3Jlc2VydmUgPSBTdHJ1Y3QoInJkbV9yZXNlcnZlIiwgWw0KICAgICAoInN0cmF0 ZWd5IiwgICAgbGlieGxfcmRtX3Jlc2VydmVfc3RyYXRlZ3kpLA0KICAgICAoInBvbGljeSIsICAg ICAgbGlieGxfcmRtX3Jlc2VydmVfcG9saWN5KSwNCkBAIC03NDUsNiArNzUwLDcgQEAgbGlieGxf ZG9tYWluX2J1aWxkX2luZm8gPSBTdHJ1Y3QoImRvbWFpbl9idWlsZF9pbmZvIixbDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICgic3ZlX3ZsIiwgbGlieGxfc3ZlX3R5cGUpLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoIm5yX3NwaXMiLCB1aW50MzIsIHsnaW5pdF92 YWwnOiAnTElCWExfTlJfU1BJU19ERUZBVUxUJ30pLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoImFybV9zY2kiLCBsaWJ4bF9hcm1fc2NpKSwNCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKCJ2aW9tbXVfdHlwZSIsIGxpYnhsX3Zpb21tdV90eXBlKSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBdKSksDQogICAgICgiYXJjaF94ODYiLCBTdHJ1Y3QoTm9u ZSwgWygibXNyX3JlbGF4ZWQiLCBsaWJ4bF9kZWZib29sKSwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBdKSksDQpkaWZmIC0tZ2l0IGEvdG9vbHMveGwveGxfcGFyc2UuYyBiL3Rvb2xz L3hsL3hsX3BhcnNlLmMNCmluZGV4IDBjY2VjZTNlOGEuLjRlNWJjODRjYTMgMTAwNjQ0DQotLS0g YS90b29scy94bC94bF9wYXJzZS5jDQorKysgYi90b29scy94bC94bF9wYXJzZS5jDQpAQCAtMzA4 MCw2ICszMDgwLDE1IEBAIHNraXBfdXNiZGV2Og0KICAgICAgICAgfQ0KICAgICB9DQogDQorICAg IGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aW9tbXUiLCAmYnVmLCAxKSkgew0K KyAgICAgICAgZSA9IGxpYnhsX3Zpb21tdV90eXBlX2Zyb21fc3RyaW5nKGJ1ZiwgJmJfaW5mby0+ YXJjaF9hcm0udmlvbW11X3R5cGUpOw0KKyAgICAgICAgaWYgKGUpIHsNCisgICAgICAgICAgICBm cHJpbnRmKHN0ZGVyciwNCisgICAgICAgICAgICAgICAgICAgICJVbmtub3duIHZJT01NVSB0eXBl IFwiJXNcIiBzcGVjaWZpZWRcbiIsIGJ1Zik7DQorICAgICAgICAgICAgZXhpdCgtRVJST1JfRkFJ TCk7DQorICAgICAgICB9DQorICAgIH0NCisNCiAgICAgcGFyc2VfdmtiX2xpc3QoY29uZmlnLCBk X2NvbmZpZyk7DQogDQogICAgIGRfY29uZmlnLT52aXJ0aW9zID0gTlVMTDsNCi0tIA0KMi40My4w DQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:06:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:06:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441820.1659367 (Exim 4.92) (envelope-from ) id 1xEFBT-0000iU-Ft; Wed, 07 Oct 2026 00:06:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441820.1659367; Wed, 07 Oct 2026 00:06: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 1xEFBT-0000iB-CN; Wed, 07 Oct 2026 00:06:59 +0000 Received: by outflank-mailman (input) for mailman id 1441820; Wed, 07 Oct 2026 00:06:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBS-0000S6-46 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBR-000T69-HO for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:57 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d1b-8faa-0a2a0a5109dd-0a2a45038154-8 for ; Wed, 07 Oct 2026 02:06:57 +0200 Received: from [40.107.159.96] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d21-fae8-0a2a45030019-286b9f608ab6-3 for ; Wed, 07 Oct 2026 02:06:57 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:55 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=Kqrhb0Xs8F4S5hJLMV6zn+1Qa7CE6KcuoRWRQtsgNX30RizYbjc20T108PkqSTmuK1htmrhAgVIuEnSoWpIYdDweZWejK03WImcxNqJEFuebeHKC5QsDez6Xg/9CZwySsgF/yOMuQUp7iIA31v+3J5L0zNdIWjajhRXRN4a5T2I+OodPUI7p0rVHM7SVLm5/oTSjHKC/STDZsGZZwEL6Tuwr9qx0QlALlaqYmkLiMOcDfZgcaILA7HN89ESHkO4onxgcmComuHWps3gsojQ8lcc5sh06xMrDNlrjy1AhW1+NHM/51OZmb0UX6FdOE8Rjik+FbEs6ZBlrT6a7ae3bOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z7l/InagsXbj6Ej1ONUjrCevKepncUUfCTiVi69NQnI=; b=c7oK6wgM362g9PBpsTEG9QzTOqIoYvt5nvUBEExx1BXedGX06gnBkOC0WDZmLE7ho6+LqvtZiuG0J5rqlqxeV2noFkIQKuHm0m//qL5ra1IgMga3nEIrxDTafM/HsLYWAel/uUVDrf3vspNYDgAPB7w2qzhYyXpLz08hYmyhlssVFDc16SYh2XEWqFsLOeGmw8s7c0gHhTphvp1+AiHpXoPNGFY5HGInvVUo/ai85cDHmzTJZ2HKc5OKO/qqPZTyXdowO8R5lUEbvBvvGLZ5t4cRowZtZD0rYULvJH6QOYFT+imRMV1cfN7ll5IdTTrFtoYt2L0Nghjr9tL5aqfNnA== 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=Z7l/InagsXbj6Ej1ONUjrCevKepncUUfCTiVi69NQnI=; b=OnbMOnbakdVtkepgWhqOpJj51USojQ3Ywj2elNKXX2GDcq25lITOQbysmxyq0Sc70iWnwbGBy3eW4pJ86g0BusM4RsQGm3ht94hz/97Y1ism4mbQ1h1XwMGH9JS/1IPvEZp6X8EFH0dxERgQosCAw1enpqHi+5hM3ebgKtm99eS/0xu4j5Vrpcg7ho0e2IwWup0RvRsYtKiB7yXFjmkaIHa/qf3r8FU/rSbrzPizpRMh4KZ5WRCGK5SiyPLQvN6v05x/5qaoV/1oVNmVhwAxOkgH21Wm+um+lzb+mpSQkrt7Wz15q7imYtt2gNfYzIxgxFRhSoZAN4UfwJJbISxYwg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Milan Djokic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh , Robin Murphy , Will Deacon Subject: [PATCH v4 07/22] xen/arm: smmuv3: Extend HW features detection and apply errata Thread-Topic: [PATCH v4 07/22] xen/arm: smmuv3: Extend HW features detection and apply errata Thread-Index: AQHdVe/CHqFUnj9RrUenBNlAdTO4Ww== Date: Wed, 7 Oct 2026 00:06:54 +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: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: cbb53c54-50a9-4aff-78c3-08df2406e51b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|260925022911599003|56012099006|260925021911599003|11063799006|10067099003|260925021311599003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: A/43v8zlei3/OCsJa0UYdduA4SONxOF7BALieNpwBMOPJlg3l7FAvTGdPqjLGFSlTfC4h1k1M4cKx1McgGcUsbn0NA0ZZc1evFiFzUC5hbIPau9yj82EYEyZQuA5dvo+Xue3wrKsIBsdOO0BYPI4mcuylu47hipAI/+GkcYbCyQwuHWj62+4mOHX7xkYNGylZ21qRwBW3pRhKkR7YDKIf9U/GhEzbxCwusXEnWId/QYkSZWqhdLwN8Z0R+Xqr4Xllt46QWrcONmYY911e8FONdXal+u8D7AegMm9UzQbFW/QY4hH/W9VdXfMNRugEviGzpEwFOnqYHALLhEK5uGTIOB83g+76BKoUIMsm09A16mAAKnaS0c9INHbdAqHu9S3VCxw6LwoRXHnv52b7oc2jrEh4ME3PAt1tLXAYydsWg1BngcOtcAIB8v6Fgk02yLlBzwDyfiSeRwmufX1CjEK1aymjQJJ0ACFTQ6iuu9+IRDGJtnyEQKlT2pfmuydsmBmXnCFmay8VFn3NGHf/P+b4R/GFV3ltPaGXka2GoGi1Ha6MaXBnflSThrUrCgODuq8N9e+qYr3eLyFYsqiEOna44qSBFhrqpvkEjRMcscw9CtiRF499zDtkt53vFcpAt2obRWr6xOBrYV7WsksS3zppm9wqrtuebqzyB+I7axC34s= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(260925022911599003)(56012099006)(260925021911599003)(11063799006)(10067099003)(260925021311599003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QzlsbmtBdkFkSFRDdjd1ZEhrS2xOOGs5bW1BckJRVUQ0cDZKWmxsSm1DMFc1?= =?utf-8?B?NEVZL2l6UVArRE5RS1V4TG1yS1dLK0UrL2FRWkE3UUVyVlVSb2RFeGxVTU9m?= =?utf-8?B?SkZlN3hpSG8zWDI3cUg2aXdPRk9ycXF4blFuNWtNY0d1VmJXWUg3YnhHeTZa?= =?utf-8?B?TzJvaXJpdzRKNi9aQVVIZituZHg3b3ZVYTRGTmpYTGJIZnlWUnFvQU90RVI2?= =?utf-8?B?ZjlrQlpTSmFaMWV5cHJxTTdadk1ESXc0WUxqS2NGSzYrUmY4Y1M1Q0NHc1Yv?= =?utf-8?B?aUtGQTJGWG5yM3dIQXlxTUhwYUJKTWZlR3pNOWhwckpJU0VOcmxydXU2VG95?= =?utf-8?B?UTdUalU4WWpRZW16M1crRWFkVEJTOUtpSFYxVk5KSjI5VUZoSVpqQ1RhZUdR?= =?utf-8?B?eGQzUGlra29xVlBPM1ZPNVNKNDdRcXREcG8rRWl5OHBKYlRGVWR0WWxTQ09K?= =?utf-8?B?QUliNlRkSm5SY25mTit5OEFqODRnczcvOXJ2R2lwMDV5b0lVZ0VlVExVdWdw?= =?utf-8?B?YUxlTld5K1VXV00vL0RBbzR6QVBJeVc3bkU5MlpXcnc4TWtveDZhM0E0RXlE?= =?utf-8?B?UVBKL0NaVU9aRjRXU1RFSmFqZ0VVRFJRVVNKUmthL1MySVNBNHVPclFmcmdU?= =?utf-8?B?blgrN2RjZTlCUjR3cUl5V1NlOGFJUGgzOHpVaWtYTHNzajRTN3kybkxvb0NE?= =?utf-8?B?WnN5aUlmOEFkY1J1Q3ZrTzN4Q2RQV2xXbVRQVkdzamcyYnYzYjZpUy95eXBY?= =?utf-8?B?M0QrMmY4dlVKa29iSFFsZ0NKNUpFZ0szVXZYa2xNVTNPNGJxRVMyWldwV0l4?= =?utf-8?B?MTFNZ0FXVzdZZ3V1VC9UMjRTV0wxOU5QL3NPNzBSQmI3UXVER0lJSlRqTktN?= =?utf-8?B?NGlneDV6K1pReVBZZ2dEWlhET01OSzBNbFJnN053YWYwcWYvSG43NHJSNHZv?= =?utf-8?B?NmZYUmdma0hhT2loeDByeWNzSnJML1d0cjI0TFN1eEhmR2FwZnFWTDRXazU0?= =?utf-8?B?Z0lnL2RxRndjNHRyV0EwQW5iTEtuOGhleDV6SWFNNVd0QURGWXFTZFgzdVFU?= =?utf-8?B?bFpicHIyY2pUeFpEVzhqdklvaUJHQXFEcUNXcy9SVVAyQmVTV2JKL25DSFQ5?= =?utf-8?B?KytVdWZ4d29XV0RBL1RwYStIc2tacHNWVmQvT3JDNXNjYVovT0hSNWxOaWlK?= =?utf-8?B?bXZ1VXZzTGwyWVQ4VVBrd09CN096T2N1RzFIMjkrVVY4L3Jjdk44NWt6M0hV?= =?utf-8?B?QUZpWDVMU2lDVlJPeDNmUmRVcldYVnpoTDJJNHEyRElsVTdMa2ZiYk1sUmhj?= =?utf-8?B?T0h1MkJRckV3ak1GbEdycldrRWdjSWhNRVp0TnRCM3BLeDQzczJGczBia2tw?= =?utf-8?B?ODBueXhTQ3Q3dkE4aVVpQUdTY1ZMTmd4cSs4eHdubEZKakVlTUlsQmxpYVc4?= =?utf-8?B?OWpSa1FDcStpRmphWlJHclB5Z29lUGk2cjdvb29qTDM1ZFVLU3lVdTYzTFUz?= =?utf-8?B?dEtHbXRjczBrdVZCSWxlZ0E5WEhhQXVMamNXaEhCckovT2x2N3RuU21TMVpj?= =?utf-8?B?RzNHSkRoTjg2OGdjTUUwQ2ViTGg3VWN4aG1UTm9qSjhvc0RNRHFhajdJdEFo?= =?utf-8?B?b3dNSmJvNGI3OHYxcURjUXNOM1RmTURhN1hpOWgvd1RkWFF2cnNqNkVhVjRF?= =?utf-8?B?MGM1UE1vRmNLOGRsUXl0WnYweUR1SGJqUERWNnllcnArTGFTeGpyTHo4TmZp?= =?utf-8?B?TTBzR3hIQXJQN3ZqSmg3NWhlc2ZFTm94SDNGM3EzSW9nV1JYQ0RjUU5WSlRE?= =?utf-8?B?RFVQWFR4dkU3bmgyek5EdVB1UFA4QS9hSXlaUnB4TW96UHgyY3FWUFd5Tlgy?= =?utf-8?B?dDFESHczQkxUbWdLZ2RXREVabVgxTXR0L3NGemt1b1RrMnZLN1AzOGVwUnlm?= =?utf-8?B?ZmMwZXZnVllVTXR4dlByK1JLY1VyWDlxczM2dk95Ung2cm1UWjRuTk83YmJV?= =?utf-8?B?NndJbkpQd00zZlNraHFWQzRuRUYxZWtxVW5WNkRCc3o0ZS8yb244N0VXS0t3?= =?utf-8?B?ZXpuUkFVakRjR2NTbjc5YS9RTG43NW1vc2VFZ3h5L0RhMDVOVnJhYm1VM1hr?= =?utf-8?B?MHlvYTFyRGlwU1dZY29QSDhoWGthSG5TOGxWQTFlSloydkJZQm40Yy9qZy9I?= =?utf-8?B?OVdPTVArcHdOR2dDL1dNSUdjQmRTSnhzc0l1b0IxL3VDUnhaSWpUTy84YlZr?= =?utf-8?B?KzBsektCTUFXRllXWEtrWk9BWllORi9zOWM1MENwZ1BpN213S2dqdjJndHp1?= =?utf-8?B?ZHozV0RYZ1BuTjBvMzdQa204dm9pelBPTSt5MWlrQ1NMVmxKQkR2UT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbb53c54-50a9-4aff-78c3-08df2406e51b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:54.1812 (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: HbyMtBYRy576CSWtUgXYi0SyH14wM0dRWykzKK5v88VbThEkBjRkivPYZb516B3zX5A4fcHoq3rsMsy1z3WIUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-33051d/1791331617-74E874E9-3A2ABCED/0/0 X-purgate-type: clean X-purgate-size: 18556 QmFja3BvcnQgTGludXggY29tbWl0cyA0YmJkNjNlYjY4NWIgYW5kIGZkODZiNTk0NDIxNSwgYWRh cHRlZCB0byB0aGUNClhlbiBTTU1VdjMgaW1wbGVtZW50YXRpb24sIGFwcGx5aW5nIGVycmF0YSB3 b3JrYXJvdW5kcyB0byBwcmV2ZW50DQpuZXN0aW5nIG9uIE1NVS02MDAgYW5kIE1NVS03MDAgcHJv ZHVjdHMuDQoNCkRldGVjdCBJT01NVSBoYXJkd2FyZSBmZWF0dXJlcyBhbmQgc3RvcmUgdGhlbSBp biB0aGUgSU9NTVUgaG9zdCBsaXN0DQpmb3IgZWFjaCBwcm9iZWQgU01NVXYzIGRldmljZSwgYWxs b3dpbmcgdGhlIGVtdWxhdGVkIElPTU1VIHRvIGFkdmVydGlzZQ0KZmVhdHVyZXMgc3VwcG9ydGVk IGJ5IHRoZSBwaHlzaWNhbCBJT01NVS4NCg0KTGludXggY29tbWl0czoNCg0KICA0YmJkNjNlYjY4 NWIgKCJpb21tdS9hcm0tc21tdS12MzogV29yayBhcm91bmQgTU1VLTYwMCBlcnJhdHVtIDEwNzY5 ODIiKQ0KICBmZDg2YjU5NDQyMTUgKCJpb21tdS9hcm0tc21tdS12MzogQWRkIGV4cGxpY2l0IGZl YXR1cmUgZm9yIG5lc3RpbmciKQ0KDQpMaW5rOiBodHRwczovL2xvcmUua2VybmVsLm9yZy9hbGwv MDhhZGJlM2QwMTAyNGQ4MzgyYTQ3ODMyNWY3M2I1Njg1MWY3NmU0OS4xNjgzNzMxMjU2LmdpdC5y b2Jpbi5tdXJwaHlAYXJtLmNvbS8NCkxpbms6IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2FsbC8x MzZjM2Y0YTNhODRjYzE0YTVhMTk3OGFjZTU3ZGZkM2VkNjdiNjg4LjE2ODM3MzEyNTYuZ2l0LnJv YmluLm11cnBoeUBhcm0uY29tLw0KT3JpZ2luOiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2Nt L2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0IDRiYmQ2M2ViNjg1Yg0KT3JpZ2lu OiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMv bGludXguZ2l0IGZkODZiNTk0NDIxNQ0KDQpTaWduZWQtb2ZmLWJ5OiBSb2JpbiBNdXJwaHkgPHJv YmluLm11cnBoeUBhcm0uY29tPg0KU2lnbmVkLW9mZi1ieTogV2lsbCBEZWFjb24gPHdpbGxAa2Vy bmVsLm9yZz4NClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxyYWh1bC5zaW5naEBhcm0uY29t Pg0KU2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBhbS5jb20+DQot LS0NCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmlvbW11LmggICAgICB8ICA4ICsrLQ0KIHhl bi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmMgIHwgODEgKysrKysrKysrKysrKysr KysrKysrKysrLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5oICB8IDMy ICsrKysrKysrLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlvbW11LmMgICB8ICA0 ICstDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMgfCA0NCArKysrKysr KysrKystLQ0KIDUgZmlsZXMgY2hhbmdlZCwgMTUyIGluc2VydGlvbnMoKyksIDE3IGRlbGV0aW9u cygtKQ0KDQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oIGIv eGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oDQppbmRleCAyODc1OTUwNjhiLi44NDRj ZjM0ZDU2IDEwMDY0NA0KLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oDQor KysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmlvbW11LmgNCkBAIC0xMiw2ICsxMiw4IEBA IHN0cnVjdCBob3N0X2lvbW11IHsNCiAgICAgc3RydWN0IGxpc3RfaGVhZCBlbnRyeTsNCiAgICAg LyogSU9NTVUgRFQgbm9kZSB1c2VkIHRvIGVzdGFibGlzaCB2aXJ0dWFsIHRvIHBoeXNpY2FsIElP TU1VL1NJRCBtYXBwaW5nICovDQogICAgIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZHRf bm9kZTsNCisgICAgLyogUGh5c2ljYWwgSU9NTVUgZGV2aWNlIHN0cnVjdHVyZSB1c2VkIHRvIGRl dGVjdCBzdXBwb3J0ZWQgZmVhdHVyZXMgKi8NCisgICAgY29uc3Qgdm9pZCAqaW9tbXU7DQogICAg IC8qIFVzZWQgZm9yIGRvbTAgdklPTU1VIGluc3RhbnRpYXRpb24gKDEtMSBNTUlPIHJlZ2lvbnMg bWFwcGluZ3MpICovDQogICAgIHBhZGRyX3QgYWRkcjsNCiAgICAgLyogVXNlZCBmb3IgZG9tMCB2 SU9NTVUgaW5zdGFudGlhdGlvbiAoMS0xIE1NSU8gcmVnaW9ucyBtYXBwaW5ncykgKi8NCkBAIC01 Miw3ICs1NCw4IEBAIGludCBkb21haW5fdmlvbW11X2luaXQoc3RydWN0IGRvbWFpbiAqZCwgdWlu dDhfdCB2aW9tbXVfdHlwZSk7DQogaW50IHZpb21tdV9yZWxpbnF1aXNoX3Jlc291cmNlcyhzdHJ1 Y3QgZG9tYWluICpkKTsNCiB1aW50OF90IHZpb21tdV9nZXRfdHlwZSh2b2lkKTsNCiB2b2lkIGFk ZF90b19ob3N0X2lvbW11X2xpc3QocGFkZHJfdCBhZGRyLCBwYWRkcl90IHNpemUsDQotICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSk7 DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9k ZSAqbm9kZSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgdm9pZCAqaW9tbXUp Ow0KIHZvaWQgc2V0X2N1cl92aW9tbXUoY29uc3Qgc3RydWN0IHZpb21tdV9kZXNjICpkZXNjKTsN CiB1bnNpZ25lZCBpbnQgZG9tYWluX3Zpb21tdV9nZXRfbnVtX21taW9faGFuZGxlcnMoc3RydWN0 IGRvbWFpbiAqZCk7DQogDQpAQCAtNzcsNyArODAsOCBAQCBzdGF0aWMgaW5saW5lIGludCB2aW9t bXVfcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCkNCiB9DQogDQogc3RhdGlj IGlubGluZSB2b2lkIF9faW5pdCBhZGRfdG9faG9zdF9pb21tdV9saXN0KHBhZGRyX3QgYWRkciwg cGFkZHJfdCBzaXplLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSkNCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUs DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgdm9pZCAq aW9tbXUpDQogew0KICAgICByZXR1cm47DQogfQ0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bh c3N0aHJvdWdoL2FybS9zbW11LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21t dS12My5jDQppbmRleCAyMWI4MmViYTg1Li45ZDJiOGE3MDhiIDEwMDY0NA0KLS0tIGEveGVuL2Ry aXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYw0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvYXJtL3NtbXUtdjMuYw0KQEAgLTI0NTEsNiArMjQ1MSwzNyBAQCBlcnJfZnJlZV9pcnFz Og0KIAlyZXR1cm4gcmV0Ow0KIH0NCiANCitzdGF0aWMgdm9pZCBhcm1fc21tdV9kZXZpY2VfaWlk cl9wcm9iZShzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11KQ0KK3sNCisJdTMyIHJlZzsNCisJ dW5zaWduZWQgaW50IGltcGxlbWVudGVyLCBwcm9kdWN0aWQsIHZhcmlhbnQsIHJldmlzaW9uOw0K Kw0KKwlyZWcgPSByZWFkbF9yZWxheGVkKHNtbXUtPmJhc2UgKyBBUk1fU01NVV9JSURSKTsNCisJ aW1wbGVtZW50ZXIgPSBGSUVMRF9HRVQoSUlEUl9JTVBMRU1FTlRFUiwgcmVnKTsNCisJcHJvZHVj dGlkID0gRklFTERfR0VUKElJRFJfUFJPRFVDVElELCByZWcpOw0KKwl2YXJpYW50ID0gRklFTERf R0VUKElJRFJfVkFSSUFOVCwgcmVnKTsNCisJcmV2aXNpb24gPSBGSUVMRF9HRVQoSUlEUl9SRVZJ U0lPTiwgcmVnKTsNCisNCisJc3dpdGNoIChpbXBsZW1lbnRlcikgew0KKwljYXNlIElJRFJfSU1Q TEVNRU5URVJfQVJNOg0KKwkJc3dpdGNoIChwcm9kdWN0aWQpIHsNCisJCWNhc2UgSUlEUl9QUk9E VUNUSURfQVJNX01NVV82MDA6DQorCQkJLyogQXJtIGVycmF0dW0gMTA3Njk4MiAqLw0KKwkJCWlm ICh2YXJpYW50ID09IDAgJiYgcmV2aXNpb24gPD0gMikNCisJCQkJc21tdS0+ZmVhdHVyZXMgJj0g fkFSTV9TTU1VX0ZFQVRfU0VWOw0KKwkJCS8qIEFybSBlcnJhdHVtIDEyMDk0MDEgKi8NCisJCQlp ZiAodmFyaWFudCA8IDIpDQorCQkJCXNtbXUtPmZlYXR1cmVzICY9IH5BUk1fU01NVV9GRUFUX05F U1RJTkc7DQorCQkJYnJlYWs7DQorCQljYXNlIElJRFJfUFJPRFVDVElEX0FSTV9NTVVfNzAwOg0K KwkJCS8qIEFybSBlcnJhdGEgMjI2ODYxOCwgMjgxMjUzMSAqLw0KKwkJCXNtbXUtPmZlYXR1cmVz ICY9IH5BUk1fU01NVV9GRUFUX05FU1RJTkc7DQorCQkJYnJlYWs7DQorCQl9DQorCQlicmVhazsN CisJfQ0KK30NCisNCiBzdGF0aWMgaW50IGFybV9zbW11X2RldmljZV9od19wcm9iZShzdHJ1Y3Qg YXJtX3NtbXVfZGV2aWNlICpzbW11KQ0KIHsNCiAJdTMyIHJlZzsNCkBAIC0yNTM5LDggKzI1NzAs MTAgQEAgc3RhdGljIGludCBhcm1fc21tdV9kZXZpY2VfaHdfcHJvYmUoc3RydWN0IGFybV9zbW11 X2RldmljZSAqc21tdSkNCiAJc3dpdGNoIChGSUVMRF9HRVQoSURSMF9UVEYsIHJlZykpIHsNCiAJ Y2FzZSBJRFIwX1RURl9BQVJDSDMyXzY0Og0KIAkJc21tdS0+aWFzID0gNDA7DQorCQlzbW11LT5m ZWF0dXJlcyB8PSBBUk1fU01NVV9GRUFUX1RURl9BQVJDSDMyXzY0Ow0KIAkJZmFsbHRocm91Z2g7 DQogCWNhc2UgSURSMF9UVEZfQUFSQ0g2NDoNCisJCXNtbXUtPmZlYXR1cmVzIHw9IEFSTV9TTU1V X0ZFQVRfVFRGX0FBUkNINjQ7DQogCQlicmVhazsNCiAJZGVmYXVsdDoNCiAJCWRldl9lcnIoc21t dS0+ZGV2LCAiQUFyY2g2NCB0YWJsZSBmb3JtYXQgbm90IHN1cHBvcnRlZCFcbiIpOw0KQEAgLTI1 NDksNiArMjU4Miw4IEBAIHN0YXRpYyBpbnQgYXJtX3NtbXVfZGV2aWNlX2h3X3Byb2JlKHN0cnVj dCBhcm1fc21tdV9kZXZpY2UgKnNtbXUpDQogDQogCS8qIEFTSUQvVk1JRCBzaXplcyAqLw0KIAlz bW11LT52bWlkX2JpdHMgPSByZWcgJiBJRFIwX1ZNSUQxNiA/IDE2IDogODsNCisJaWYgKHJlZyAm IElEUjBfQVNJRDE2KQ0KKwkJc21tdS0+ZmVhdHVyZXMgfD0gQVJNX1NNTVVfRkVBVF9BU0lEXzE2 Ow0KIA0KIAkvKiBJRFIxICovDQogCXJlZyA9IHJlYWRsX3JlbGF4ZWQoc21tdS0+YmFzZSArIEFS TV9TTU1VX0lEUjEpOw0KQEAgLTI1ODgsMTIgKzI2MjMsMTggQEAgc3RhdGljIGludCBhcm1fc21t dV9kZXZpY2VfaHdfcHJvYmUoc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSkNCiAJc21tdS0+ ZXZ0cS5tYXhfc3RhbGxzID0gRklFTERfR0VUKElEUjVfU1RBTExfTUFYLCByZWcpOw0KIA0KIAkv KiBQYWdlIHNpemVzICovDQotCWlmIChyZWcgJiBJRFI1X0dSQU42NEspDQorCWlmIChyZWcgJiBJ RFI1X0dSQU42NEspIHsNCiAJCXNtbXUtPnBnc2l6ZV9iaXRtYXAgfD0gU1pfNjRLIHwgU1pfNTEy TTsNCi0JaWYgKHJlZyAmIElEUjVfR1JBTjE2SykNCisJCXNtbXUtPmZlYXR1cmVzIHw9IEFSTV9T TU1VX0ZFQVRfR1JBTjY0SzsNCisJfQ0KKwlpZiAocmVnICYgSURSNV9HUkFOMTZLKSB7DQogCQlz bW11LT5wZ3NpemVfYml0bWFwIHw9IFNaXzE2SyB8IFNaXzMyTTsNCi0JaWYgKHJlZyAmIElEUjVf R1JBTjRLKQ0KKwkJc21tdS0+ZmVhdHVyZXMgfD0gQVJNX1NNTVVfRkVBVF9HUkFOMTZLOw0KKwl9 DQorCWlmIChyZWcgJiBJRFI1X0dSQU40Sykgew0KIAkJc21tdS0+cGdzaXplX2JpdG1hcCB8PSBT Wl80SyB8IFNaXzJNIHwgU1pfMUc7DQorCQlzbW11LT5mZWF0dXJlcyB8PSBBUk1fU01NVV9GRUFU X0dSQU40SzsNCisJfQ0KIA0KIAkvKiBJbnB1dCBhZGRyZXNzIHNpemUgKi8NCiAJaWYgKEZJRUxE X0dFVChJRFI1X1ZBWCwgcmVnKSA9PSBJRFI1X1ZBWF81Ml9CSVQpDQpAQCAtMjYyNiwxNSArMjY2 Nyw0NiBAQCBzdGF0aWMgaW50IGFybV9zbW11X2RldmljZV9od19wcm9iZShzdHJ1Y3QgYXJtX3Nt bXVfZGV2aWNlICpzbW11KQ0KIAkJZmFsbHRocm91Z2g7DQogCWNhc2UgSURSNV9PQVNfNDhfQklU Og0KIAkJc21tdS0+b2FzID0gNDg7DQorCQlzbW11LT5mZWF0dXJlcyB8PSBBUk1fU01NVV9GRUFU X09BU180OF9CSVQ7DQogCQlicmVhazsNCiAJfQ0KIA0KIAlzbW11LT5vYXMgPSBtaW5fdCh1bnNp Z25lZCBsb25nLCBQQUREUl9CSVRTLCBzbW11LT5vYXMpOw0KIAlzbW11LT5pYXMgPSBtYXgoc21t dS0+aWFzLCBzbW11LT5vYXMpOw0KIA0KKwlzd2l0Y2ggKHNtbXUtPm9hcykgew0KKwljYXNlIDMy Og0KKwkJc21tdS0+ZmVhdHVyZXMgfD0gQVJNX1NNTVVfRkVBVF9PQVNfMzJfQklUOw0KKwkJYnJl YWs7DQorCWNhc2UgMzY6DQorCQlzbW11LT5mZWF0dXJlcyB8PSBBUk1fU01NVV9GRUFUX09BU18z Nl9CSVQ7DQorCQlicmVhazsNCisJY2FzZSA0MDoNCisJCXNtbXUtPmZlYXR1cmVzIHw9IEFSTV9T TU1VX0ZFQVRfT0FTXzQwX0JJVDsNCisJCWJyZWFrOw0KKwljYXNlIDQyOg0KKwkJc21tdS0+ZmVh dHVyZXMgfD0gQVJNX1NNTVVfRkVBVF9PQVNfNDJfQklUOw0KKwkJYnJlYWs7DQorCWNhc2UgNDQ6 DQorCQlzbW11LT5mZWF0dXJlcyB8PSBBUk1fU01NVV9GRUFUX09BU180NF9CSVQ7DQorCQlicmVh azsNCisJY2FzZSA0ODoNCisJCXNtbXUtPmZlYXR1cmVzIHw9IEFSTV9TTU1VX0ZFQVRfT0FTXzQ4 X0JJVDsNCisJCWJyZWFrOw0KKwljYXNlIDUyOg0KKwkJc21tdS0+ZmVhdHVyZXMgfD0gQVJNX1NN TVVfRkVBVF9PQVNfNTJfQklUOw0KKwkJYnJlYWs7DQorCX0NCisNCiAJLyogWGVuOiBTZXQgbWF4 aW11bSBTdGFnZS0yIGlucHV0IHNpemUgc3VwcG9ydGVkIGJ5IHRoZSBTTU1VLiAqLw0KIAlwMm1f cmVzdHJpY3RfaXBhX2JpdHMoc21tdS0+aWFzKTsNCiANCisJaWYgKChzbW11LT5mZWF0dXJlcyAm IEFSTV9TTU1VX0ZFQVRfVFJBTlNfUzEpICYmDQorCQkoc21tdS0+ZmVhdHVyZXMgJiBBUk1fU01N VV9GRUFUX1RSQU5TX1MyKSkNCisJCXNtbXUtPmZlYXR1cmVzIHw9IEFSTV9TTU1VX0ZFQVRfTkVT VElORzsNCisNCisJYXJtX3NtbXVfZGV2aWNlX2lpZHJfcHJvYmUoc21tdSk7DQorDQogCWRldl9p bmZvKHNtbXUtPmRldiwgImlhcyAlbHUtYml0LCBvYXMgJWx1LWJpdCAoZmVhdHVyZXMgMHglMDh4 KVxuIiwNCiAJCSBzbW11LT5pYXMsIHNtbXUtPm9hcywgc21tdS0+ZmVhdHVyZXMpOw0KIAlyZXR1 cm4gMDsNCkBAIC0yODI5LDkgKzI5MDEsOCBAQCBzdGF0aWMgaW50IF9faW5pdCBhcm1fc21tdV9k ZXZpY2VfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikNCiAJc3Bpbl9sb2NrKCZh cm1fc21tdV9kZXZpY2VzX2xvY2spOw0KIAlsaXN0X2FkZCgmc21tdS0+ZGV2aWNlcywgJmFybV9z bW11X2RldmljZXMpOw0KIAlzcGluX3VubG9jaygmYXJtX3NtbXVfZGV2aWNlc19sb2NrKTsNCi0N CiAJLyogQWRkIHRvIGhvc3QgSU9NTVUgbGlzdCB0byBpbml0aWFsaXplIHZJT01NVSBmb3IgZG9t MCAqLw0KLQlhZGRfdG9faG9zdF9pb21tdV9saXN0KGlvYWRkciwgaW9zaXplLCBkZXZfdG9fZHQo cGRldikpOw0KKwlhZGRfdG9faG9zdF9pb21tdV9saXN0KGlvYWRkciwgaW9zaXplLCBkZXZfdG9f ZHQocGRldiksICh2b2lkICopIHNtbXUpOw0KIA0KIAlyZXR1cm4gMDsNCiANCmRpZmYgLS1naXQg YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5oIGIveGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvYXJtL3NtbXUtdjMuaA0KaW5kZXggZTI1N2RlNmRiOS4uZWY0OTIwOThhZSAxMDA2 NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmgNCisrKyBiL3hl bi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmgNCkBAIC02MCw2ICs2MCwxNiBAQA0K ICNkZWZpbmUgSURSNV9WQVgJCQlHRU5NQVNLKDExLCAxMCkNCiAjZGVmaW5lIElEUjVfVkFYXzUy X0JJVAkJCTENCiANCisjZGVmaW5lIEFSTV9TTU1VX0lJRFIJCQkweDE4DQorI2RlZmluZSBJSURS X1BST0RVQ1RJRAkJCUdFTk1BU0soMzEsIDIwKQ0KKyNkZWZpbmUgSUlEUl9WQVJJQU5UCQkJR0VO TUFTSygxOSwgMTYpDQorI2RlZmluZSBJSURSX1JFVklTSU9OCQkJR0VOTUFTSygxNSwgMTIpDQor I2RlZmluZSBJSURSX0lNUExFTUVOVEVSCQlHRU5NQVNLKDExLCAwKQ0KKw0KKyNkZWZpbmUgSUlE Ul9JTVBMRU1FTlRFUl9BUk0JCTB4NDNiDQorI2RlZmluZSBJSURSX1BST0RVQ1RJRF9BUk1fTU1V XzYwMAkweDQ4Mw0KKyNkZWZpbmUgSUlEUl9QUk9EVUNUSURfQVJNX01NVV83MDAJMHg0ODcNCisN CiAjZGVmaW5lIEFSTV9TTU1VX0NSMAkJCTB4MjANCiAjZGVmaW5lIENSMF9BVFNDSEsJCQkoMSA8 PCA0KQ0KICNkZWZpbmUgQ1IwX0NNRFFFTgkJCSgxIDw8IDMpDQpAQCAtNjAyLDEwICs2MTIsMjQg QEAgc3RydWN0IGFybV9zbW11X2RldmljZSB7DQogI2RlZmluZSBBUk1fU01NVV9GRUFUX0NPSEVS RU5DWQkJKDEgPDwgOCkNCiAjZGVmaW5lIEFSTV9TTU1VX0ZFQVRfVFJBTlNfUzEJCSgxIDw8IDkp DQogI2RlZmluZSBBUk1fU01NVV9GRUFUX1RSQU5TX1MyCQkoMSA8PCAxMCkNCi0jZGVmaW5lIEFS TV9TTU1VX0ZFQVRfU1RBTExTCQkoMSA8PCAxMSkNCi0jZGVmaW5lIEFSTV9TTU1VX0ZFQVRfSFlQ CQkoMSA8PCAxMikNCi0jZGVmaW5lIEFSTV9TTU1VX0ZFQVRfU1RBTExfRk9SQ0UJKDEgPDwgMTMp DQotI2RlZmluZSBBUk1fU01NVV9GRUFUX1ZBWAkJKDEgPDwgMTQpDQorI2RlZmluZSBBUk1fU01N VV9GRUFUX05FU1RJTkcJICAgICgxIDw8IDExKQ0KKyNkZWZpbmUgQVJNX1NNTVVfRkVBVF9TVEFM TFMJCSgxIDw8IDEyKQ0KKyNkZWZpbmUgQVJNX1NNTVVfRkVBVF9IWVAJCSgxIDw8IDEzKQ0KKyNk ZWZpbmUgQVJNX1NNTVVfRkVBVF9TVEFMTF9GT1JDRQkoMSA8PCAxNCkNCisjZGVmaW5lIEFSTV9T TU1VX0ZFQVRfVkFYCQkoMSA8PCAxNSkNCisjZGVmaW5lIEFSTV9TTU1VX0ZFQVRfQVNJRF8xNgkJ KDEgPDwgMTYpDQorI2RlZmluZSBBUk1fU01NVV9GRUFUX1RURl9BQVJDSDY0CQkoMSA8PCAxNykN CisjZGVmaW5lIEFSTV9TTU1VX0ZFQVRfVFRGX0FBUkNIMzJfNjQJKDEgPDwgMTgpDQorI2RlZmlu ZSBBUk1fU01NVV9GRUFUX0dSQU42NEsJKDEgPDwgMTkpDQorI2RlZmluZSBBUk1fU01NVV9GRUFU X0dSQU4xNksJKDEgPDwgMjApDQorI2RlZmluZSBBUk1fU01NVV9GRUFUX0dSQU40SwkoMSA8PCAy MSkNCisjZGVmaW5lIEFSTV9TTU1VX0ZFQVRfT0FTXzMyX0JJVAkoMSA8PCAyMikNCisjZGVmaW5l IEFSTV9TTU1VX0ZFQVRfT0FTXzM2X0JJVAkoMSA8PCAyMykNCisjZGVmaW5lIEFSTV9TTU1VX0ZF QVRfT0FTXzQwX0JJVAkoMSA8PCAyNCkNCisjZGVmaW5lIEFSTV9TTU1VX0ZFQVRfT0FTXzQyX0JJ VAkoMSA8PCAyNSkNCisjZGVmaW5lIEFSTV9TTU1VX0ZFQVRfT0FTXzQ0X0JJVAkoMSA8PCAyNikN CisjZGVmaW5lIEFSTV9TTU1VX0ZFQVRfT0FTXzQ4X0JJVAkoMSA8PCAyNykNCisjZGVmaW5lIEFS TV9TTU1VX0ZFQVRfT0FTXzUyX0JJVAkoMSA8PCAyOCkNCiAJdTMyCQkJCWZlYXR1cmVzOw0KIA0K ICNkZWZpbmUgQVJNX1NNTVVfT1BUX1NLSVBfUFJFRkVUQ0gJKDEgPDwgMCkNCmRpZmYgLS1naXQg YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlvbW11LmMgYi94ZW4vZHJpdmVycy9wYXNz dGhyb3VnaC9hcm0vdmlvbW11LmMNCmluZGV4IDM0MDFlNGY3ZDkuLjQwN2U2OGU2MmQgMTAwNjQ0 DQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlvbW11LmMNCisrKyBiL3hlbi9k cml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92aW9tbXUuYw0KQEAgLTE3LDcgKzE3LDggQEAgc3RhdGlj IGJvb2wgaG9zdF9pb21tdV9saXN0X2luY29tcGxldGU7DQogDQogLyogQ29tbW9uIGZ1bmN0aW9u IGZvciBhZGRpbmcgdG8gaG9zdF9pb21tdV9saXN0ICovDQogdm9pZCBfX2luaXQgYWRkX3RvX2hv c3RfaW9tbXVfbGlzdChwYWRkcl90IGFkZHIsIHBhZGRyX3Qgc2l6ZSwNCi0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlKQ0KKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUs DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHZvaWQgKmlvbW11KQ0KIHsNCiAg ICAgc3RydWN0IGhvc3RfaW9tbXUgKmlvbW11X2RhdGE7DQogICAgIGludCBpcnE7DQpAQCAtNDUs NiArNDYsNyBAQCB2b2lkIF9faW5pdCBhZGRfdG9faG9zdF9pb21tdV9saXN0KHBhZGRyX3QgYWRk ciwgcGFkZHJfdCBzaXplLA0KICAgICAgICAgcmV0dXJuOw0KICAgICB9DQogICAgIGlvbW11X2Rh dGEtPmlycSA9IGlycTsNCisgICAgaW9tbXVfZGF0YS0+aW9tbXUgPSBpb21tdTsNCiANCiAgICAg cHJpbnRrKCJ2SU9NTVU6IEZvdW5kIElPTU1VIEAweCUiUFJJeDY0IlxuIiwgYWRkcik7DQogDQpk aWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMgYi94ZW4v ZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuYw0KaW5kZXggZWEzYjViYjM0ZC4uNzAw MWY4YzIzZiAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12 My5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuYw0KQEAgLTUs OSArNSwxMyBAQA0KICNpbmNsdWRlIDxhc20vbW1pby5oPg0KICNpbmNsdWRlIDxhc20vdmlvbW11 Lmg+DQogDQorI2luY2x1ZGUgInNtbXUtdjMuaCINCisjaW5jbHVkZSAidnNtbXUtdjMuaCINCisN CiBzdHJ1Y3QgdmlydF9zbW11IHsNCiAgICAgc3RydWN0ICAgICAgZG9tYWluICpkOw0KICAgICBz dHJ1Y3QgICAgICBsaXN0X2hlYWQgdmlvbW11X2xpc3Q7DQorICAgIHVpbnQzMl90ICAgIGZlYXR1 cmVzOw0KIH07DQogDQogc3RhdGljIGludCB2c21tdXYzX21taW9fd3JpdGUoc3RydWN0IHZjcHUg KnYsIG1taW9faW5mb190ICppbmZvLA0KQEAgLTI5LDcgKzMzLDggQEAgc3RhdGljIGNvbnN0IHN0 cnVjdCBtbWlvX2hhbmRsZXJfb3BzIHZzbW11djNfbW1pb19oYW5kbGVyID0gew0KICAgICAud3Jp dGUgPSB2c21tdXYzX21taW9fd3JpdGUsDQogfTsNCiANCi1zdGF0aWMgaW50IHZzbW11djNfaW5p dF9zaW5nbGUoc3RydWN0IGRvbWFpbiAqZCwgcGFkZHJfdCBhZGRyLCBwYWRkcl90IHNpemUpDQor c3RhdGljIGludCB2c21tdXYzX2luaXRfc2luZ2xlKHN0cnVjdCBkb21haW4gKmQsIHBhZGRyX3Qg YWRkciwgcGFkZHJfdCBzaXplLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50 MzJfdCBmZWF0dXJlcykNCiB7DQogICAgIHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXU7DQogDQpAQCAt MzgsNiArNDMsNyBAQCBzdGF0aWMgaW50IHZzbW11djNfaW5pdF9zaW5nbGUoc3RydWN0IGRvbWFp biAqZCwgcGFkZHJfdCBhZGRyLCBwYWRkcl90IHNpemUpDQogICAgICAgICByZXR1cm4gLUVOT01F TTsNCiANCiAgICAgc21tdS0+ZCA9IGQ7DQorICAgIHNtbXUtPmZlYXR1cmVzID0gZmVhdHVyZXM7 DQogDQogICAgIHJlZ2lzdGVyX21taW9faGFuZGxlcihkLCAmdnNtbXV2M19tbWlvX2hhbmRsZXIs IGFkZHIsIHNpemUsIHNtbXUpOw0KIA0KQEAgLTUwLDIzICs1Niw1MSBAQCBzdGF0aWMgaW50IHZz bW11djNfaW5pdF9zaW5nbGUoc3RydWN0IGRvbWFpbiAqZCwgcGFkZHJfdCBhZGRyLCBwYWRkcl90 IHNpemUpDQogc3RhdGljIGludCBkb21haW5fdnNtbXV2M19pbml0KHN0cnVjdCBkb21haW4gKmQp DQogew0KICAgICBpbnQgcmV0Ow0KKyAgICBzdHJ1Y3QgaG9zdF9pb21tdSAqaHdfaW9tbXU7DQor ICAgIGNvbnN0IHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKnNtbXU7DQorDQorICAgIGlmICggbGlz dF9oZWFkX2lzX251bGwoJmhvc3RfaW9tbXVfbGlzdCkgKQ0KKyAgICAgICAgcmV0dXJuIC1FTk9E RVY7DQogDQogICAgIElOSVRfTElTVF9IRUFEKCZkLT5hcmNoLnZpb21tdV9saXN0KTsNCiANCiAg ICAgaWYgKCBpc19oYXJkd2FyZV9kb21haW4oZCkgKQ0KICAgICB7DQotICAgICAgICBzdHJ1Y3Qg aG9zdF9pb21tdSAqaHdfaW9tbXU7DQotDQogICAgICAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KGh3 X2lvbW11LCAmaG9zdF9pb21tdV9saXN0LCBlbnRyeSkNCiAgICAgICAgIHsNCi0gICAgICAgICAg ICByZXQgPSB2c21tdXYzX2luaXRfc2luZ2xlKGQsIGh3X2lvbW11LT5hZGRyLCBod19pb21tdS0+ c2l6ZSk7DQorICAgICAgICAgICAgc21tdSA9IChjb25zdCBzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNl ICopIGh3X2lvbW11LT5pb21tdTsNCisgICAgICAgICAgICByZXQgPSB2c21tdXYzX2luaXRfc2lu Z2xlKGQsIGh3X2lvbW11LT5hZGRyLCBod19pb21tdS0+c2l6ZSwNCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHNtbXUtPmZlYXR1cmVzKTsNCiAgICAgICAgICAgICBpZiAo IHJldCApDQogICAgICAgICAgICAgICAgIHJldHVybiByZXQ7DQogICAgICAgICB9DQogICAgIH0N CiAgICAgZWxzZQ0KICAgICB7DQotICAgICAgICByZXQgPSB2c21tdXYzX2luaXRfc2luZ2xlKGQs IEdVRVNUX1ZTTU1VVjNfQkFTRSwgR1VFU1RfVlNNTVVWM19TSVpFKTsNCisgICAgICAgIC8qDQor ICAgICAgICAgKiBSZXF1aXJlOiBGb3Igbm9uLWhhcmR3YXJlIGRvbWFpbnMsIGZlYXR1cmVzIG11 c3QgYmUgdW5pZm9ybSBhY3Jvc3MNCisgICAgICAgICAqIHBoeXNpY2FsIFNNTVVzIHRvIGF2b2lk IGFkdmVydGlzaW5nIGZlYXR1cmVzIHRoYXQgYXJlIHVuc3VwcG9ydGVkIGJ5DQorICAgICAgICAg KiBjZXJ0YWluIHVuaXRzLg0KKyAgICAgICAgICovDQorICAgICAgICB1aW50MzJfdCBmZWF0dXJl czsNCisgICAgICAgIGh3X2lvbW11ID0gbGlzdF9maXJzdF9lbnRyeSgmaG9zdF9pb21tdV9saXN0 LCBzdHJ1Y3QgaG9zdF9pb21tdSwgZW50cnkpOw0KKyAgICAgICAgc21tdSA9IChjb25zdCBzdHJ1 Y3QgYXJtX3NtbXVfZGV2aWNlICopIGh3X2lvbW11LT5pb21tdTsNCisgICAgICAgIGZlYXR1cmVz ID0gc21tdS0+ZmVhdHVyZXM7DQorICAgICAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KGh3X2lvbW11 LCAmaG9zdF9pb21tdV9saXN0LCBlbnRyeSkNCisgICAgICAgIHsNCisgICAgICAgICAgICBzbW11 ID0gKGNvbnN0IHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKikgaHdfaW9tbXUtPmlvbW11Ow0KKw0K KyAgICAgICAgICAgIGlmICggc21tdS0+ZmVhdHVyZXMgIT0gZmVhdHVyZXMgKQ0KKyAgICAgICAg ICAgIHsNCisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19HX0VSUg0KKyAgICAgICAgICAg ICAgICAgICAgICAgInZTTU1VdjM6IFVuc3VwcG9ydGVkIEhXIGxheW91dDogcGh5c2ljYWwgU01N VXMgbXVzdCAiIFwNCisgICAgICAgICAgICAgICAgICAgICAgICJoYXZlIGEgdW5pZm9ybSBzZXQg b2YgZmVhdHVyZXNcbiIpOw0KKyAgICAgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisgICAg ICAgICAgICB9DQorICAgICAgICB9DQorDQorICAgICAgICByZXQgPSB2c21tdXYzX2luaXRfc2lu Z2xlKGQsIEdVRVNUX1ZTTU1VVjNfQkFTRSwgR1VFU1RfVlNNTVVWM19TSVpFLA0KKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBmZWF0dXJlcyk7DQogICAgICAgICBpZiAoIHJldCAp DQogICAgICAgICAgICAgcmV0dXJuIHJldDsNCiAgICAgfQ0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441821.1659373 (Exim 4.92) (envelope-from ) id 1xEFBU-0000p6-3w; Wed, 07 Oct 2026 00:07:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441821.1659373; Wed, 07 Oct 2026 00:07: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 1xEFBT-0000nG-UM; Wed, 07 Oct 2026 00:06:59 +0000 Received: by outflank-mailman (input) for mailman id 1441821; Wed, 07 Oct 2026 00:06:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBS-0000cC-WA for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:06:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBS-00Bv1m-D6 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:06:58 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d14-e002-0a2a0a5209dd-0a2a4501d89a-10 for ; Wed, 07 Oct 2026 02:06:58 +0200 Received: from [40.107.159.140] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d21-5984-0a2a45010019-286b9f8c7748-3 for ; Wed, 07 Oct 2026 02:06:58 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:56 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=V5D0Z/7v/rx3f8OR+yxhDAFSTNCBt/XHm9nQrzSIJNDaUwyaHYHg6qhCwZ1wlccB0BMB1NtfYQHIWMMoOz4cMx/Fszxhb4JfvUTQV6OZABLuybJA4IteJ1fORqnKrwj8S3lKg/WUl390adIBDP/83dRH5sm0soYMIiMVjMn/tmyLgWI1MKhue5nO0vVaL1SkAUh5ili3DwwCvmC5VseL7xJq2yvWdYrGkGA0jbz8KUx+Uo4e6nMM+ug/SB2/Pu06grVcm0M9tQsWQqlrx7lshaPuqDPDNhg2FemgCwsAczlUueOzFRkWD3Lj1iVu5tOYTEMun02U2vOoswN8UEeOyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PnOfyH+o7v/rCLTZfw3zej+ceiQDAH62Oq1z5jMnbx8=; b=p09Rcf8MUbyolSuq6Dbju7rc+negX1ganFCgv1cm5uqh5kUTV37IHXVL4w/rb1B+byR8Xlp7pNPnMJCxdhadousBnG3jZgBxItZ8IJjXTh/Vqw7BbQmDA4HwAVEyVUMG2ERwQD1cUbtxi8/gcxqZOZPlptrihwf/0FNhlJVocoF5LgaWmL9p5Aqu1Xahm4xZN8QXKvAfj/AteBMlQ5VC7Q8ZCRmr8OLEcTwUxEi4Zlemtz7i3jiuTASUZyNrngyHjtBhO8ZtdvFH/sreXTkHp9XLhHvjxwygGuEREEzGHnFCdM1p8IjLmvOnLf22SFOkMytHwblKhD8O6Ls1fycfJQ== 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=PnOfyH+o7v/rCLTZfw3zej+ceiQDAH62Oq1z5jMnbx8=; b=iYg3nKqI0elGYFYv6toyJZKZ0OYGOEHoD6i/G0XnkCeJNsEaRJquovcYfm59QMedTpqFvM1ydcFhshohzQSSnho2q5CUGbIH0jvXs7r0zSlzcy5th5z1o5dWtVuNiijT31JspIVTInlLZ2PQy0S5WulV9rF7STX5P3lnOEh9n3eKykdaRfE6gmMbEdjkEBuYrq7U0Sl5jb5eOVtxz+vk3JGQdWET56t7uigTKzjA7Sh0Ij8E7fFh3zRtM7oUta7xEL5MRZcl19W0VzXgqt41aJyfDwwvfAEEP6raVIZlmqiZFKnCrov9i6uViBIQlnBpCQUOA/UoY14Z6YArOEWVwg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 08/22] xen/arm: vsmmuv3: Add support for registers emulation Thread-Topic: [PATCH v4 08/22] xen/arm: vsmmuv3: Add support for registers emulation Thread-Index: AQHdVe/D9k36RA9JcEOa7HpFq89euA== Date: Wed, 7 Oct 2026 00:06:56 +0000 Message-ID: <36f8c3e3c92ab038641506382fbc6db2d11247c4.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: f04399f9-23af-43ef-eb2a-08df2406e65d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: 8c70XSwXwBw3O/f9GyaWzKP7mfoKVsWHrEJTNm+rO/MaVkeqk6Ex0+2wqnhtdwXNBldpDgl2ESqGgcVmvzwyXUMD0SnQGBQobBZ8aK4xXIgPMA3I/vURe8xbE72kxlnqBY2tSfEWbe+N9NZgfy4/J0rDxsXtdoDToMgF/M3YSVC2ro1X3vicZiU41+LafcE/LB9VziwrRYsVvEHsPiUn3Gl1zS8HPaJRTdtLJCMRAizOny0NwePNmEq9/GDzJ7jJMnPmhytMTLxSGGyiSSk3XXdSgvWAmWR4Ws53V8GrRvEcrG/zzof2idZkJ46WOuoT80L3ndV7kFaNTGn0RyPUJoJGitfqNfVnfnCvjClxblOkeKwA/Y3zYI6yNol/Mg8CnUhChiS4pNCFmDz4eWdZ10HzbAn7RprVTfUf5BKFRjDOIgmL8Gk4WbUzJgkrp1VqRXhiVccVXGKIPX5PZ6j9rS5JqgifOyDd09kuFvoASAAFSDiBFk60KTaT28U7XLsOh7GIoPnfiIL/pPl0xlEpgGOXuJCytPpQzgQxZauVim93hmALW2QHEfZmNGSC4WCCN86nSKhvEg+xPnVQGRG0WdQt0LKfwTj9yC16pEodmM+mh6Ilw3EGAXdcu5gw4sQG9H96+LxVl2hhOZpnKbxRqSRJpywli3p3bmQpmkA6zzL68bc103zApYnpeTG/pAdzQflZ7H0r2n/gondL8yKXFg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Tjd3RlBkTkg5ZGt6SVVNbnJWNlAwL1NSbklJQklDZjYrVndwUjVmVDVPWG9Q?= =?utf-8?B?MmxDejRSczNKeTVET3dLaHRGM25FL29uNmdGWlB3bHBLbUxWQnpwVFR6aHlZ?= =?utf-8?B?dFpMcmZ4Q3BscnVqVEtaRnp1TWF1NDk5WUhhcExUL1NDMWVOUDAxM0FiUWN0?= =?utf-8?B?NkNRb2tLNXhhVFdMaTFrVjJLMTN0SUdHRjg4aUMyN0tOblBKd0VidGRxTjdH?= =?utf-8?B?UXh3M1pJM3hyc0VWbU5BV2tnUFd6elV1WUJCKzNXc2tuWGhnNmpnb0Q1Zjhx?= =?utf-8?B?K3dqbXR0cXlMWVZGRDU3VmFpdnlNeHlSd0JRWkRHUklvYkVQaEp3NUg1VU94?= =?utf-8?B?eVQ1c1RmQmRhNUVNLzRCamZTN29lZEVrUjhJVDJzbGhScXQxK3c0YWJsYWNv?= =?utf-8?B?QTVibWhTUzVKNWRsUmcrRTNZTVl0di9MS2NONmVLMGJrSlRMdEVjdGZ2Q2tj?= =?utf-8?B?UHdieEtKV3pYM1VVb0xweW1IMUEvMDVOSlhZSTlvNVo2NC9MMXhlcGpITjJQ?= =?utf-8?B?bDZsTFZ2R0NldXgrZEJCb203a3k3Z2RUN0ZDQ0lxcC8xTHM5MEJVM2ZmTit0?= =?utf-8?B?Rk0zOTU3V1V3aGNmNlh6MlhaVlRRVjJOOTdtK0Q2cDVnK0NVNVVJUzE2Tm8y?= =?utf-8?B?SDNSMi85aGtEUWRWbGM3Y3duaGxPMTdLdzRxanY0QmZ3Y1R3amxDaWFHd0E3?= =?utf-8?B?eXRxWHZOTVMzbXJWOVFCc0dNVEMxb0tRR1A0Q2ZJZktYMlVlTWFKRTkwOWtm?= =?utf-8?B?emRLVjJta1dLUDNQK2ZjTHJFT1QzYkZZdVdiRmtUSldma3RFSU83OVh5NFJj?= =?utf-8?B?Q2JGZFY3STB5SjJkSlAwMGJ2VEwvOXZoYUg3NTBKTzNQckQwWnhNbHEyRnJ2?= =?utf-8?B?dWFCRmovaFd6VTVYTERSSDFLYUw5cWN4YTFSM0E4QlFLaFBoRXphZXY1UmJX?= =?utf-8?B?TnpSaGpFZ1FrMFlVTlJxK09GRjdHT0tNYjFJLytNSWVacEY5K0dzc1NDbzdu?= =?utf-8?B?TjNiR296VGdBNEdmQTNkeTJ2QWJSVVFnMHhiUVd3REwreTVGOUk3SlNleFln?= =?utf-8?B?cnh2UWROMEM1eGRlR3B0VldxdDVoazFvVG5ud3c3RllYaDlhRHlSNE5LMzAz?= =?utf-8?B?aE11U2w5a0VmMU0yblQ3TTVLT1BRUWdQSWtFcjFMR0lHRTRFdTFIeVp2R2NQ?= =?utf-8?B?UVQrK2RYc2dqRHJWLzVNaUI4RVRnU0dEV1E3YVF1OVNSSmczaXJrNGp6azhO?= =?utf-8?B?S1QvTHVTbWR4WGo4YWJ5QlpCWmN4SkhYektDU3lVZTZBSDFVaHkvNFZBQjQ1?= =?utf-8?B?ZHdMVHRoMXJaVnpLNWVEbW1ISDRCVWhaUi93eElxL2tOL1A3TXVXSWdlZkRq?= =?utf-8?B?TWlqenJyMHVjRFp1bFozYW1seWg3K2l2SXdCRTVLWjdORjZqM2VlSXliQU5F?= =?utf-8?B?QlVDR0NGVnNhaTFRYWlaZStJR2JWMWk5b2xuaEZIa3lPQk9rZithTHFYdS9k?= =?utf-8?B?MG15WVArbEJ5RS9MKzUvTzRobVlERkk1R2VvUnoxZFF4Vi9DMnhCbDU2SWtI?= =?utf-8?B?OWpWUmt3eVlkK1NMbWNLQklZOUlNZXdHeGE5RWpNRWJWb1BGTjJLRDZOeW9H?= =?utf-8?B?b3FYY2hQOUw0WTVzb1J0Q1lhZEpNZFU2RUl4bXlGK0xhUk53enVYTUh0R1Ev?= =?utf-8?B?MysyUk01blFwdUNTcEpQTHpQdG5OVjNEUTVKcDBBZUdTVHEzQjZFbyt3OTJw?= =?utf-8?B?c0RNVk1XUllNZlRRdm9PRTRnU2VoUjVRdVB6WGp4YWszT0FwZ3lTMFZ3aFNB?= =?utf-8?B?RzdXYUxOUjd1UE13RlpDaWE5RFpNOUluQTVsNkxLVW5BZXYwRG9mRVJwZlJK?= =?utf-8?B?MjhKSXR2MGZTYU9qY2dyeFVRcVZNZGMvcFZXYU9GNURwclZiQVozLzk4OERh?= =?utf-8?B?QmE3WCt5QTZLVTYyOGIyTld4bXYxL1c0d3RzdHdlZ0Y0UFNrSTlvM3VRaVF4?= =?utf-8?B?c1dwaUQ0ejRhcXhrc25XTVQvekhPbmlKZTQ4L1VvS1ZoN0xJdUE0eGhnalEw?= =?utf-8?B?Tkp1ZFEvSElRTVFpcExZK0hBMm0wdmk4Q2lhSTE4ei80UDcyU3Y3dHI3cnd5?= =?utf-8?B?UGpsSktQNkJRQkxYZldFangxWG90Y2ltV0p1RTRONk9URy9hNzNkQTQwTXBZ?= =?utf-8?B?L0RuVWpSL1VMd2VWeGJVNGtqOCt6VE9jWWNDbjhrU3ZXek55STUxS0JCa1J5?= =?utf-8?B?S1pvMDdzMklQZXhtblhLQ3YrY0YxaUVQV2gwcU5BU2UyZC8zQjh3d1puZWFJ?= =?utf-8?B?WTVQK1kyOGltcjhnRHV2T2t3UmFUeXYrSjVDdmREd3FuYVU1YndQQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f04399f9-23af-43ef-eb2a-08df2406e65d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:56.2712 (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: MaxNywVB+G+fRfWirdd1pVk5n/W8vcDDnzVtDJklr/+RPJoD73wY4XBYvNvaZdj0e0ZA4lekynaeh4k2vRaJgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-d62444/1791331618-BF66C757-53D69FBE/0/0 X-purgate-type: clean X-purgate-size: 32404 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkFkZCBpbml0aWFsIHN1 cHBvcnQgZm9yIHZhcmlvdXMgZW11bGF0ZWQgcmVnaXN0ZXJzIGZvciB2aXJ0dWFsIFNNTVV2Mw0K Zm9yIGd1ZXN0cyBhbmQgYWxzbyBhZGQgc3VwcG9ydCBmb3IgdmlydHVhbCBjbWRxIGFuZCBldmVu dHEuDQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxyYWh1bC5zaW5naEBhcm0uY29tPg0K U2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBhbS5jb20+DQotLS0N CiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuYyB8IDU3MyArKysrKysrKysr KysrKysrKysrKysrKystDQogMSBmaWxlIGNoYW5nZWQsIDU3MSBpbnNlcnRpb25zKCspLCAyIGRl bGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3Zz bW11LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuYw0KaW5kZXgg NzAwMWY4YzIzZi4uYzRmZWY2ZThiZCAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJv dWdoL2FybS92c21tdS12My5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNt bXUtdjMuYw0KQEAgLTEsMzAgKzEsNTg4IEBADQogLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6 IChHUEwtMi4wLW9yLWxhdGVyIE9SIEJTRC0yLUNsYXVzZSkgKi8NCiANCisvKg0KKyAqIElPTU1V IHN0YWdlLTEgZW11bGF0aW9uIGZvciBBUk0gU01NVXYzLg0KKyAqDQorICogVE9ETzogVXNpbmcg QVJNIGdlbmVyaWMgaW1wbGVtZW50ZXIvcHJvZHVjdC92YXJpYW50IHRvIGF2b2lkIGFjdGl2YXRp bmcNCisgKiBlcnJhdGEgd29ya2Fyb3VuZHMgaW4gdGhlIGd1ZXN0IGRyaXZlciBkdWUgdG8gZW11 bGF0aW9uIGxheWVyLg0KKyAqIFRoaXMgbmVlZHMgdG8gYmUgZnVsbHkgaGFuZGxlZCBpbiB0aGUg ZnV0dXJlLg0KKyAqLw0KKw0KICNpbmNsdWRlIDx4ZW4vcGFyYW0uaD4NCiAjaW5jbHVkZSA8eGVu L3NjaGVkLmg+DQogI2luY2x1ZGUgPGFzbS9tbWlvLmg+DQorI2luY2x1ZGUgPGFzbS92Z2ljLWVt dWwuaD4NCiAjaW5jbHVkZSA8YXNtL3Zpb21tdS5oPg0KKyNpbmNsdWRlIDxhc20vdnJlZy5oPg0K IA0KICNpbmNsdWRlICJzbW11LXYzLmgiDQogI2luY2x1ZGUgInZzbW11LXYzLmgiDQogDQorLyog UmVnaXN0ZXIgRGVmaW5pdGlvbiAqLw0KKyNkZWZpbmUgQVJNX1NNTVVfSURSMiAgICAgICAweDgN CisjZGVmaW5lIEFSTV9TTU1VX0lEUjMgICAgICAgMHhjDQorI2RlZmluZSBBUk1fU01NVV9JRFI0 ICAgICAgIDB4MTANCisjZGVmaW5lIElEUjBfVEVSTV9NT0RFTCAgICAgKDEgPDwgMjYpDQorI2Rl ZmluZSBJRFIzX1JJTCAgICAgICAgICAgICgxIDw8IDEwKQ0KKy8qIE9ubHkgQ01EUSwgRVZFTlRR IGFuZCBTTU1VRU4gc3VwcG9ydGVkICovDQorI2RlZmluZSBDUjBfUkVTRVJWRUQgICAgICAgIDB4 RkZGRkZGRjJVDQorLyogVE9ETzogUmlnaHQgbm93IG9ubHkgMTYtYml0IFNJRCBzaXplIGlzIHN1 cHBvcnRlZCAqLw0KKyNkZWZpbmUgU01NVV9JRFIxX1NJRFNJWkUgICAxNg0KKy8qIFRoZSBDTURR L0VWVFEgc2l6ZXMgYXJlIGN1cnJlbnRseSBzZXQgdG8gdGhlIGFyY2hpdGVjdHVyYWwgbWF4aW11 bS4gKi8NCisjZGVmaW5lIFNNTVVfQ01EUVMgICAgICAgICAgMTkNCisjZGVmaW5lIFNNTVVfRVZU UVMgICAgICAgICAgMTkNCisjZGVmaW5lIERXT1JEU19CWVRFUyAgICAgICAgOA0KKw0KKy8qIHZp cnR1YWwgc21tdSBxdWV1ZSAqLw0KK3N0cnVjdCBhcm1fdnNtbXVfcXVldWUgew0KKyAgICB1aW50 NjRfdCAgICBxX2Jhc2U7IC8qIGJhc2UgcmVnaXN0ZXIgKi8NCisgICAgdWludDMyX3QgICAgcHJv ZDsNCisgICAgdWludDMyX3QgICAgY29uczsNCisgICAgdWludDhfdCAgICAgZW50X3NpemU7DQor ICAgIHVpbnQ4X3QgICAgIG1heF9uX3NoaWZ0Ow0KK307DQorDQogc3RydWN0IHZpcnRfc21tdSB7 DQogICAgIHN0cnVjdCAgICAgIGRvbWFpbiAqZDsNCiAgICAgc3RydWN0ICAgICAgbGlzdF9oZWFk IHZpb21tdV9saXN0Ow0KICAgICB1aW50MzJfdCAgICBmZWF0dXJlczsNCisgICAgcGFkZHJfdCAg ICAgYWRkcjsNCisgICAgdWludDMyX3QgICAgY3JbM107DQorICAgIHVpbnQzMl90ICAgIGNyMGFj azsNCisgICAgdWludDMyX3QgICAgZ2Vycm9yOw0KKyAgICB1aW50MzJfdCAgICBnZXJyb3JuOw0K KyAgICB1aW50MzJfdCAgICBzdHJ0YWJfYmFzZV9jZmc7DQorICAgIHVpbnQ2NF90ICAgIHN0cnRh Yl9iYXNlOw0KKyAgICB1aW50MzJfdCAgICBpcnFfY3RybDsNCisgICAgdWludDY0X3QgICAgZ2Vy cm9yX2lycV9jZmcwOw0KKyAgICB1aW50NjRfdCAgICBldnRxX2lycV9jZmcwOw0KKyAgICBzdHJ1 Y3QgICAgICBhcm1fdnNtbXVfcXVldWUgZXZ0cSwgY21kcTsNCisgICAgc3BpbmxvY2tfdCAgY21k X3F1ZXVlX2xvY2s7DQorICAgIHNwaW5sb2NrX3QgIGV2dF9xdWV1ZV9sb2NrOw0KKyAgICBzcGlu bG9ja190ICBnZXJyb3JfbG9jazsNCisgICAgc3BpbmxvY2tfdCAgY3IwX2xvY2s7DQorICAgIHNw aW5sb2NrX3QgIGNyMV9sb2NrOw0KKyAgICBzcGlubG9ja190ICBjcjJfbG9jazsNCisgICAgc3Bp bmxvY2tfdCAgc3RydGFiX2NmZ19sb2NrOw0KKyAgICBzcGlubG9ja190ICBpcnFfY2ZnX2xvY2s7 DQogfTsNCiANCisvKiBIZWxwZXIgZnVuY3Rpb25zICovDQorc3RhdGljIGlubGluZSBib29sIHNt bXVfZ2V0X3NtbXVfZW5hYmxlZChzdHJ1Y3QgdmlydF9zbW11ICpzbW11KQ0KK3sNCisgICAgYm9v bCBlbmFibGVkOw0KKw0KKyAgICBzcGluX2xvY2soJnNtbXUtPmNyMF9sb2NrKTsNCisgICAgZW5h YmxlZCA9IEZJRUxEX0dFVChDUjBfU01NVUVOLCBzbW11LT5jclswXSk7DQorICAgIHNwaW5fdW5s b2NrKCZzbW11LT5jcjBfbG9jayk7DQorDQorICAgIHJldHVybiBlbmFibGVkOw0KK30NCisNCitz dGF0aWMgaW5saW5lIGJvb2wgc21tdV9nZXRfY21kcV9lbmFibGVkKHN0cnVjdCB2aXJ0X3NtbXUg KnNtbXUpDQorew0KKyAgICBib29sIGVuYWJsZWQ7DQorDQorICAgIHNwaW5fbG9jaygmc21tdS0+ Y3IwX2xvY2spOw0KKyAgICBlbmFibGVkID0gRklFTERfR0VUKENSMF9DTURRRU4sIHNtbXUtPmNy WzBdKTsNCisgICAgc3Bpbl91bmxvY2soJnNtbXUtPmNyMF9sb2NrKTsNCisNCisgICAgcmV0dXJu IGVuYWJsZWQ7DQorfQ0KKw0KK3N0YXRpYyBpbmxpbmUgYm9vbCBzbW11X2dldF9ldnRxX2VuYWJs ZWQoc3RydWN0IHZpcnRfc21tdSAqc21tdSkNCit7DQorICAgIGJvb2wgZW5hYmxlZDsNCisNCisg ICAgc3Bpbl9sb2NrKCZzbW11LT5jcjBfbG9jayk7DQorICAgIGVuYWJsZWQgPSBGSUVMRF9HRVQo Q1IwX0VWVFFFTiwgc21tdS0+Y3JbMF0pOw0KKyAgICBzcGluX3VubG9jaygmc21tdS0+Y3IwX2xv Y2spOw0KKw0KKyAgICByZXR1cm4gZW5hYmxlZDsNCit9DQorDQogc3RhdGljIGludCB2c21tdXYz X21taW9fd3JpdGUoc3RydWN0IHZjcHUgKnYsIG1taW9faW5mb190ICppbmZvLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJlZ2lzdGVyX3Qgciwgdm9pZCAqcHJpdikNCiB7DQotICAg IEJVR19PTigidW5pbXBsZW1lbnRlZCIpOw0KKyAgICBzdHJ1Y3QgdmlydF9zbW11ICpzbW11ID0g cHJpdjsNCisgICAgdWludDY0X3QgcmVnOw0KKyAgICB1aW50MzJfdCByZWczMjsNCisgICAgc3Ry dWN0IGhzcl9kYWJ0IGRhYnQgPSBpbmZvLT5kYWJ0Ow0KKyAgICB1aW50NjRfdCBvZmZzZXQgPSBp bmZvLT5ncGEgLSBzbW11LT5hZGRyOw0KKw0KKyAgICBpZiAoIG9mZnNldCAmIDB4MTAwMDAgKQ0K KyAgICB7DQorICAgICAgICAvKiBwYWdlIDEgKi8NCisgICAgICAgIHN3aXRjaCAoIGluZm8tPmdw YSAmIDB4ZmZmZiApDQorICAgICAgICB7DQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9F VlRRX1BST0QpOg0KKyAgICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdv dG8gYmFkX3dpZHRoOw0KKyAgICAgICAgICAgIC8qICBXcml0ZSBhbGxvd2VkIG9ubHkgd2hlbiBT TU1VX0NSMC5FVlRRRU4gPT0gMCAqLw0KKyAgICAgICAgICAgIGlmICggc21tdV9nZXRfZXZ0cV9l bmFibGVkKHNtbXUpICkNCisgICAgICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICAgICAgc3Bp bl9sb2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7DQorICAgICAgICAgICAgcmVnMzIgPSBzbW11 LT5ldnRxLnByb2Q7DQorICAgICAgICAgICAgdnJlZ19yZWczMl91cGRhdGUoJnJlZzMyLCByLCBp bmZvKTsNCisgICAgICAgICAgICBzbW11LT5ldnRxLnByb2QgPSByZWczMjsNCisgICAgICAgICAg ICBzcGluX3VubG9jaygmc21tdS0+ZXZ0X3F1ZXVlX2xvY2spOw0KKyAgICAgICAgICAgIGJyZWFr Ow0KKyAgICAgICAgY2FzZSBWUkVHMzIoQVJNX1NNTVVfRVZUUV9DT05TKToNCisgICAgICAgICAg ICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAg ICAgICBzcGluX2xvY2soJnNtbXUtPmV2dF9xdWV1ZV9sb2NrKTsNCisgICAgICAgICAgICByZWcz MiA9IHNtbXUtPmV2dHEuY29uczsNCisgICAgICAgICAgICB2cmVnX3JlZzMyX3VwZGF0ZSgmcmVn MzIsIHIsIGluZm8pOw0KKyAgICAgICAgICAgIHNtbXUtPmV2dHEuY29ucyA9IHJlZzMyOw0KKyAg ICAgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7DQorICAgICAgICAg ICAgYnJlYWs7DQorICAgICAgICBkZWZhdWx0Og0KKyAgICAgICAgICAgIHByaW50ayhYRU5MT0df R19FUlINCisgICAgICAgICAgICAgICAgIiVwZDogdlNNTVV2MzogdW5oYW5kbGVkIHdyaXRlIHIl ZCBvZmZzZXQgJSJQUklwYWRkciJcbiIsDQorICAgICAgICAgICAgICAgIHYtPmRvbWFpbiwgaW5m by0+ZGFidC5yZWcsICh1bnNpZ25lZCBsb25nKWluZm8tPmdwYSAmIDB4ZmZmZik7DQorICAgICAg ICAgICAgcmV0dXJuIElPX0hBTkRMRUQ7DQorICAgICAgICB9DQorICAgIH0NCisgICAgZWxzZQ0K KyAgICB7DQorICAgICAgICAvKiBwYWdlIDAgKi8NCisgICAgICAgIHN3aXRjaCAoIGluZm8tPmdw YSAmIDB4ZmZmZiApDQorICAgICAgICB7DQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9D UjApOg0KKyAgICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFk X3dpZHRoOw0KKyAgICAgICAgICAgIHNwaW5fbG9jaygmc21tdS0+Y3IwX2xvY2spOw0KKyAgICAg ICAgICAgIHJlZzMyID0gc21tdS0+Y3JbMF07DQorICAgICAgICAgICAgdnJlZ19yZWczMl91cGRh dGUoJnJlZzMyLCByLCBpbmZvKTsNCisgICAgICAgICAgICBzbW11LT5jclswXSA9IHJlZzMyOw0K KyAgICAgICAgICAgIHNtbXUtPmNyMGFjayA9IHJlZzMyICYgfkNSMF9SRVNFUlZFRDsNCisgICAg ICAgICAgICBzcGluX3VubG9jaygmc21tdS0+Y3IwX2xvY2spOw0KKyAgICAgICAgICAgIGJyZWFr Ow0KKw0KKyAgICAgICAgY2FzZSBWUkVHMzIoQVJNX1NNTVVfQ1IxKToNCisgICAgICAgICAgICBp ZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAgICAg ICBzcGluX2xvY2soJnNtbXUtPmNyMV9sb2NrKTsNCisgICAgICAgICAgICByZWczMiA9IHNtbXUt PmNyWzFdOw0KKyAgICAgICAgICAgIHZyZWdfcmVnMzJfdXBkYXRlKCZyZWczMiwgciwgaW5mbyk7 DQorICAgICAgICAgICAgc21tdS0+Y3JbMV0gPSByZWczMjsNCisgICAgICAgICAgICBzcGluX3Vu bG9jaygmc21tdS0+Y3IxX2xvY2spOw0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAg Y2FzZSBWUkVHMzIoQVJNX1NNTVVfQ1IyKToNCisgICAgICAgICAgICBpZiAoIGRhYnQuc2l6ZSAh PSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAgICAgICBzcGluX2xvY2soJnNt bXUtPmNyMl9sb2NrKTsNCisgICAgICAgICAgICByZWczMiA9IHNtbXUtPmNyWzJdOw0KKyAgICAg ICAgICAgIHZyZWdfcmVnMzJfdXBkYXRlKCZyZWczMiwgciwgaW5mbyk7DQorICAgICAgICAgICAg c21tdS0+Y3JbMl0gPSByZWczMjsNCisgICAgICAgICAgICBzcGluX3VubG9jaygmc21tdS0+Y3Iy X2xvY2spOw0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgY2FzZSBWUkVHNjQoQVJN X1NNTVVfU1RSVEFCX0JBU0UpOg0KKyAgICAgICAgICAgIC8qICBNdXN0IG9ubHkgYmUgd3JpdHRl biB3aGVuIFNNTVVfQ1IwLlNNTVVFTiA9PSAwLCBvdGhlcndpc2UgaWdub3JlICovDQorICAgICAg ICAgICAgaWYgKCBzbW11X2dldF9zbW11X2VuYWJsZWQoc21tdSkgKQ0KKyAgICAgICAgICAgICAg ICBicmVhazsNCisgICAgICAgICAgICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX0RPVUJMRV9XT1JE ICYmIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKQ0KKyAgICAgICAgICAgICAgICBnb3RvIGJhZF93 aWR0aDsNCisgICAgICAgICAgICBzcGluX2xvY2soJnNtbXUtPnN0cnRhYl9jZmdfbG9jayk7DQor ICAgICAgICAgICAgcmVnID0gc21tdS0+c3RydGFiX2Jhc2U7DQorICAgICAgICAgICAgdnJlZ19y ZWc2NF91cGRhdGUoJnJlZywgciwgaW5mbyk7DQorICAgICAgICAgICAgc21tdS0+c3RydGFiX2Jh c2UgPSByZWc7DQorICAgICAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPnN0cnRhYl9jZmdfbG9j ayk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01N VV9TVFJUQUJfQkFTRV9DRkcpOg0KKyAgICAgICAgICAgIC8qICBNdXN0IG9ubHkgYmUgd3JpdHRl biB3aGVuIFNNTVVfQ1IwLlNNTVVFTiA9PSAwLCBvdGhlcndpc2UgaWdub3JlICovDQorICAgICAg ICAgICAgaWYgKCBzbW11X2dldF9zbW11X2VuYWJsZWQoc21tdSkgKQ0KKyAgICAgICAgICAgICAg ICBicmVhazsNCisgICAgICAgICAgICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3Rv IGJhZF93aWR0aDsNCisgICAgICAgICAgICBzcGluX2xvY2soJnNtbXUtPnN0cnRhYl9jZmdfbG9j ayk7DQorICAgICAgICAgICAgcmVnMzIgPSBzbW11LT5zdHJ0YWJfYmFzZV9jZmc7DQorICAgICAg ICAgICAgdnJlZ19yZWczMl91cGRhdGUoJnJlZzMyLCByLCBpbmZvKTsNCisgICAgICAgICAgICBz bW11LT5zdHJ0YWJfYmFzZV9jZmcgPSByZWczMjsNCisgICAgICAgICAgICBzcGluX3VubG9jaygm c21tdS0+c3RydGFiX2NmZ19sb2NrKTsNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAg IGNhc2UgVlJFRzY0KEFSTV9TTU1VX0NNRFFfQkFTRSk6DQorICAgICAgICAgICAgLyogIE11c3Qg b25seSBiZSB3cml0dGVuIHdoZW4gU01NVV9DUjAuQ01EUUVOID09IDAsIG90aGVyd2lzZSBpZ25v cmUgKi8NCisgICAgICAgICAgICBpZiAoIHNtbXVfZ2V0X2NtZHFfZW5hYmxlZChzbW11KSApDQor ICAgICAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERB QlRfRE9VQkxFX1dPUkQgJiYgZGFidC5zaXplICE9IERBQlRfV09SRCApDQorICAgICAgICAgICAg ICAgIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAgICAgICAgIHNwaW5fbG9jaygmc21tdS0+Y21kX3F1 ZXVlX2xvY2spOw0KKyAgICAgICAgICAgIHJlZyA9IHNtbXUtPmNtZHEucV9iYXNlOw0KKyAgICAg ICAgICAgIHZyZWdfcmVnNjRfdXBkYXRlKCZyZWcsIHIsIGluZm8pOw0KKyAgICAgICAgICAgIHNt bXUtPmNtZHEucV9iYXNlID0gcmVnOw0KKyAgICAgICAgICAgIHNtbXUtPmNtZHEubWF4X25fc2hp ZnQgPSBGSUVMRF9HRVQoUV9CQVNFX0xPRzJTSVpFLCBzbW11LT5jbWRxLnFfYmFzZSk7DQorICAg ICAgICAgICAgaWYgKCBzbW11LT5jbWRxLm1heF9uX3NoaWZ0ID4gU01NVV9DTURRUyApDQorICAg ICAgICAgICAgICAgIHNtbXUtPmNtZHEubWF4X25fc2hpZnQgPSBTTU1VX0NNRFFTOw0KKyAgICAg ICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5jbWRfcXVldWVfbG9jayk7DQorICAgICAgICAgICAg YnJlYWs7DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9DTURRX1BST0QpOg0KKyAg ICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0K KyAgICAgICAgICAgIHNwaW5fbG9jaygmc21tdS0+Y21kX3F1ZXVlX2xvY2spOw0KKyAgICAgICAg ICAgIHJlZzMyID0gc21tdS0+Y21kcS5wcm9kOw0KKyAgICAgICAgICAgIHZyZWdfcmVnMzJfdXBk YXRlKCZyZWczMiwgciwgaW5mbyk7DQorICAgICAgICAgICAgc21tdS0+Y21kcS5wcm9kID0gcmVn MzI7DQorICAgICAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPmNtZF9xdWV1ZV9sb2NrKTsNCisg ICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGNhc2UgVlJFRzMyKEFSTV9TTU1VX0NNRFFf Q09OUyk6DQorICAgICAgICAgICAgLyogIE11c3Qgb25seSBiZSB3cml0dGVuIHdoZW4gU01NVV9D UjAuQ01EUUVOID09IDAsIG90aGVyd2lzZSBpZ25vcmUgKi8NCisgICAgICAgICAgICBpZiAoIHNt bXVfZ2V0X2NtZHFfZW5hYmxlZChzbW11KSApDQorICAgICAgICAgICAgICAgIGJyZWFrOw0KKyAg ICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0K KyAgICAgICAgICAgIHNwaW5fbG9jaygmc21tdS0+Y21kX3F1ZXVlX2xvY2spOw0KKyAgICAgICAg ICAgIHJlZzMyID0gc21tdS0+Y21kcS5jb25zOw0KKyAgICAgICAgICAgIHZyZWdfcmVnMzJfdXBk YXRlKCZyZWczMiwgciwgaW5mbyk7DQorICAgICAgICAgICAgc21tdS0+Y21kcS5jb25zID0gcmVn MzI7DQorICAgICAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPmNtZF9xdWV1ZV9sb2NrKTsNCisg ICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGNhc2UgVlJFRzY0KEFSTV9TTU1VX0VWVFFf QkFTRSk6DQorICAgICAgICAgICAgLyogIE11c3Qgb25seSBiZSB3cml0dGVuIHdoZW4gU01NVV9D UjAuRVZUUUVOID09IDAsIG90aGVyd2lzZSBpZ25vcmUgKi8NCisgICAgICAgICAgICBpZiAoIHNt bXVfZ2V0X2V2dHFfZW5hYmxlZChzbW11KSApDQorICAgICAgICAgICAgICAgIGJyZWFrOw0KKyAg ICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERBQlRfRE9VQkxFX1dPUkQgJiYgZGFidC5zaXpl ICE9IERBQlRfV09SRCApDQorICAgICAgICAgICAgICAgIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAg ICAgICAgIHNwaW5fbG9jaygmc21tdS0+ZXZ0X3F1ZXVlX2xvY2spOw0KKyAgICAgICAgICAgIHJl ZyA9IHNtbXUtPmV2dHEucV9iYXNlOw0KKyAgICAgICAgICAgIHZyZWdfcmVnNjRfdXBkYXRlKCZy ZWcsIHIsIGluZm8pOw0KKyAgICAgICAgICAgIHNtbXUtPmV2dHEucV9iYXNlID0gcmVnOw0KKyAg ICAgICAgICAgIHNtbXUtPmV2dHEubWF4X25fc2hpZnQgPSBGSUVMRF9HRVQoUV9CQVNFX0xPRzJT SVpFLCBzbW11LT5ldnRxLnFfYmFzZSk7DQorICAgICAgICAgICAgaWYgKCBzbW11LT5ldnRxLm1h eF9uX3NoaWZ0ID4gU01NVV9FVlRRUyApDQorICAgICAgICAgICAgICAgIHNtbXUtPmV2dHEubWF4 X25fc2hpZnQgPSBTTU1VX0VWVFFTOw0KKyAgICAgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5l dnRfcXVldWVfbG9jayk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICBjYXNlIFZS RUczMihBUk1fU01NVV9JUlFfQ1RSTCk6DQorICAgICAgICAgICAgaWYgKCBkYWJ0LnNpemUgIT0g REFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAgICAgc3Bpbl9sb2NrKCZzbW11 LT5pcnFfY2ZnX2xvY2spOw0KKyAgICAgICAgICAgIHJlZzMyID0gc21tdS0+aXJxX2N0cmw7DQor ICAgICAgICAgICAgdnJlZ19yZWczMl91cGRhdGUoJnJlZzMyLCByLCBpbmZvKTsNCisgICAgICAg ICAgICBzbW11LT5pcnFfY3RybCA9IHJlZzMyOw0KKyAgICAgICAgICAgIHNwaW5fdW5sb2NrKCZz bW11LT5pcnFfY2ZnX2xvY2spOw0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgY2Fz ZSBWUkVHNjQoQVJNX1NNTVVfR0VSUk9SX0lSUV9DRkcwKToNCisgICAgICAgICAgICBpZiAoIGRh YnQuc2l6ZSAhPSBEQUJUX0RPVUJMRV9XT1JEICYmIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKQ0K KyAgICAgICAgICAgICAgICBnb3RvIGJhZF93aWR0aDsNCisgICAgICAgICAgICBzcGluX2xvY2so JnNtbXUtPmlycV9jZmdfbG9jayk7DQorICAgICAgICAgICAgcmVnID0gc21tdS0+Z2Vycm9yX2ly cV9jZmcwOw0KKyAgICAgICAgICAgIHZyZWdfcmVnNjRfdXBkYXRlKCZyZWcsIHIsIGluZm8pOw0K KyAgICAgICAgICAgIHNtbXUtPmdlcnJvcl9pcnFfY2ZnMCA9IHJlZzsNCisgICAgICAgICAgICBz cGluX3VubG9jaygmc21tdS0+aXJxX2NmZ19sb2NrKTsNCisgICAgICAgICAgICBicmVhazsNCisN CisgICAgICAgIGNhc2UgVlJFRzY0KEFSTV9TTU1VX0VWVFFfSVJRX0NGRzApOg0KKyAgICAgICAg ICAgIGlmICggZGFidC5zaXplICE9IERBQlRfRE9VQkxFX1dPUkQgJiYgZGFidC5zaXplICE9IERB QlRfV09SRCApDQorICAgICAgICAgICAgICAgIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAgICAgICAg IHNwaW5fbG9jaygmc21tdS0+aXJxX2NmZ19sb2NrKTsNCisgICAgICAgICAgICByZWcgPSBzbW11 LT5ldnRxX2lycV9jZmcwOw0KKyAgICAgICAgICAgIHZyZWdfcmVnNjRfdXBkYXRlKCZyZWcsIHIs IGluZm8pOw0KKyAgICAgICAgICAgIHNtbXUtPmV2dHFfaXJxX2NmZzAgPSByZWc7DQorICAgICAg ICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPmlycV9jZmdfbG9jayk7DQorICAgICAgICAgICAgYnJl YWs7DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9HRVJST1JOKToNCisgICAgICAg ICAgICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAg ICAgICAgICBzcGluX2xvY2soJnNtbXUtPmdlcnJvcl9sb2NrKTsNCisgICAgICAgICAgICByZWcz MiA9IHNtbXUtPmdlcnJvcm47DQorICAgICAgICAgICAgdnJlZ19yZWczMl91cGRhdGUoJnJlZzMy LCByLCBpbmZvKTsNCisgICAgICAgICAgICBzbW11LT5nZXJyb3JuID0gcmVnMzI7DQorICAgICAg ICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPmdlcnJvcl9sb2NrKTsNCisgICAgICAgICAgICBicmVh azsNCisNCisgICAgICAgIGRlZmF1bHQ6DQorICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19HX0VS Ug0KKyAgICAgICAgICAgICAgICAiJXBkOiB2U01NVXYzOiB1bmhhbmRsZWQgd3JpdGUgciVkIG9m ZnNldCAlIlBSSXBhZGRyIlxuIiwNCisgICAgICAgICAgICAgICAgdi0+ZG9tYWluLCBpbmZvLT5k YWJ0LnJlZywgKHVuc2lnbmVkIGxvbmcpaW5mby0+Z3BhICYgMHhmZmZmKTsNCisgICAgICAgICAg ICByZXR1cm4gSU9fSEFORExFRDsNCisgICAgICAgIH0NCisgICAgfQ0KKw0KKyAgICByZXR1cm4g SU9fSEFORExFRDsNCisNCisgYmFkX3dpZHRoOg0KKyAgICBncHJpbnRrKFhFTkxPR19HX0VSUiwN CisgICAgICAgICAgICAiJXBkOiB2U01NVXYzOiBiYWQgd3JpdGUgd2lkdGggJWQgciVkIG9mZnNl dCAlIlBSSXBhZGRyIlxuIiwNCisgICAgICAgICAgICB2LT5kb21haW4sIGRhYnQuc2l6ZSwgZGFi dC5yZWcsIGluZm8tPmdwYSAmIDB4ZmZmZik7DQogICAgIHJldHVybiBJT19IQU5ETEVEOw0KIH0N CiANCiBzdGF0aWMgaW50IHZzbW11djNfbW1pb19yZWFkKHN0cnVjdCB2Y3B1ICp2LCBtbWlvX2lu Zm9fdCAqaW5mbywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZ2lzdGVyX3QgKnIs IHZvaWQgKnByaXYpDQogew0KLSAgICBCVUdfT04oInVuaW1wbGVtZW50ZWQiKTsNCisgICAgc3Ry dWN0IHZpcnRfc21tdSAqc21tdSA9IHByaXY7DQorICAgIHVpbnQ2NF90IHJlZzsNCisgICAgc3Ry dWN0IGhzcl9kYWJ0IGRhYnQgPSBpbmZvLT5kYWJ0Ow0KKyAgICB1aW50NjRfdCBvZmZzZXQgPSBp bmZvLT5ncGEgLSBzbW11LT5hZGRyOw0KKw0KKyAgICBpZiAoIG9mZnNldCAmIDB4MTAwMDAgKQ0K KyAgICB7DQorICAgICAgICAvKiBwYWdlIDEgKi8NCisgICAgICAgIHN3aXRjaCAoIGluZm8tPmdw YSAmIDB4ZmZmZiApDQorICAgICAgICB7DQorICAgICAgICAgICAgY2FzZSBWUkVHMzIoQVJNX1NN TVVfRVZUUV9QUk9EKToNCisgICAgICAgICAgICAgICAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9X T1JEICkgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAgICAgICAgIHNwaW5fbG9jaygmc21tdS0+ ZXZ0X3F1ZXVlX2xvY2spOw0KKyAgICAgICAgICAgICAgICAqciA9IHZyZWdfcmVnMzJfZXh0cmFj dChzbW11LT5ldnRxLnByb2QsIGluZm8pOw0KKyAgICAgICAgICAgICAgICBzcGluX3VubG9jaygm c21tdS0+ZXZ0X3F1ZXVlX2xvY2spOw0KKyAgICAgICAgICAgICAgICBicmVhazsNCisNCisgICAg ICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9FVlRRX0NPTlMpOg0KKyAgICAgICAgICAgICAg ICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAg ICAgICAgICAgc3Bpbl9sb2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7DQorICAgICAgICAgICAg ICAgICpyID0gdnJlZ19yZWczMl9leHRyYWN0KHNtbXUtPmV2dHEuY29ucywgaW5mbyk7DQorICAg ICAgICAgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7DQorICAgICAg ICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgICAgIGRlZmF1bHQ6DQorICAgICAgICAgICAg ICAgIHByaW50ayhYRU5MT0dfR19FUlINCisgICAgICAgICAgICAgICAgICAgICIlcGQ6IHZTTU1V djM6IHVuaGFuZGxlZCByZWFkIHIlZCBvZmZzZXQgJSJQUklwYWRkciJcbiIsDQorICAgICAgICAg ICAgICAgICAgICB2LT5kb21haW4sIGluZm8tPmRhYnQucmVnLCAodW5zaWduZWQgbG9uZylpbmZv LT5ncGEgJiAweGZmZmYpOw0KKyAgICAgICAgICAgICAgICByZXR1cm4gSU9fSEFORExFRDsNCisg ICAgICAgIH0NCisgICAgfQ0KKyAgICBlbHNlDQorICAgIHsNCisgICAgICAgIC8qIHBhZ2UgMCAq Lw0KKyAgICAgICAgc3dpdGNoICggaW5mby0+Z3BhICYgMHhmZmZmICkNCisgICAgICAgIHsNCisg ICAgICAgIGNhc2UgVlJFRzMyKEFSTV9TTU1VX0lEUjApOg0KKyAgICAgICAgICAgIGlmICggZGFi dC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAgICAgICAgIC8qDQor ICAgICAgICAgICAgICogRW11bGF0ZWQgU01NVSBjYXBhYmlsaXRpZXMuDQorICAgICAgICAgICAg ICoNCisgICAgICAgICAgICAgKiBTb21lIGFyY2hpdGVjdHVyYWwgY2FwYWJpbGl0aWVzIGFyZSBj dXJyZW50bHkgbm90IGltcGxlbWVudGVkDQorICAgICAgICAgICAgICogYnkgdGhlIHN0YWdlLTEg ZW11bGF0aW9uIGxheWVyIG9yIHVuZGVybHlpbmcgWGVuIFNNTVUgc3VwcG9ydCwNCisgICAgICAg ICAgICAgKiB0aGVyZWZvcmUgdGhleSBhcmUgbm90IGFkdmVydGlzZWQgYXRtIGV2ZW4gaWYgc3Vw cG9ydGVkIGJ5IHRoZSBIVw0KKyAgICAgICAgICAgICAqLw0KKyAgICAgICAgICAgIHJlZyAgPSBG SUVMRF9QUkVQKElEUjBfUzFQLCAxKSB8DQorICAgICAgICAgICAgICAgIC8qDQorICAgICAgICAg ICAgICAgICAqIFRPRE86IENvaGVyZW50IGFjY2VzcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBlbXVs YXRpb24gYXRtLg0KKyAgICAgICAgICAgICAgICAgKiBHdWVzdCBtdXN0IHBlcmZvcm0gZXhwbGlj aXQgY2FjaGUgY2xlYW4NCisgICAgICAgICAgICAgICAgICovDQorICAgICAgICAgICAgICAgIEZJ RUxEX1BSRVAoSURSMF9DT0hBQ0MsIDApIHwNCisgICAgICAgICAgICAgICAgLyogVHJhbnNhY3Rp b24gc3RhbGwgb24gZmF1bHQgbm90IGltcGxlbWVudGVkICovDQorICAgICAgICAgICAgICAgIEZJ RUxEX1BSRVAoSURSMF9TVEFMTF9NT0RFTCwgMSkgfA0KKyAgICAgICAgICAgICAgICAvKiBUZXJt aW5hdGluZyBhIHRyYW5zYWN0aW9uIHdpdGggUkFaL1dJIGJlaGF2aW9yIG5vdCBpbXBsZW1lbnRl ZCAqLw0KKyAgICAgICAgICAgICAgICBGSUVMRF9QUkVQKElEUjBfVEVSTV9NT0RFTCwgMSk7DQor DQorICAgICAgICAgICAgLyogSFcgcmVmbGVjdGVkIGNhcGFiaWxpdGllcyAqLw0KKyAgICAgICAg ICAgIHJlZyB8PSBGSUVMRF9QUkVQKElEUjBfU1RfTFZMLA0KKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzbW11LT5mZWF0dXJlcyAmIEFSTV9TTU1VX0ZFQVRfMl9MVkxfU1RSVEFCID8NCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMSA6IDApOw0KKyAgICAgICAgICAgIHJlZyB8PSBG SUVMRF9QUkVQKElEUjBfVFRGLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzbW11LT5m ZWF0dXJlcyAmIEFSTV9TTU1VX0ZFQVRfVFRGX0FBUkNIMzJfNjQgPw0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJRFIwX1RURl9BQVJDSDMyXzY0IDogSURSMF9UVEZfQUFSQ0g2NCk7DQor DQorICAgICAgICAgICAgcmVnIHw9IEZJRUxEX1BSRVAoSURSMF9BU0lEMTYsDQorICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHNtbXUtPmZlYXR1cmVzICYgQVJNX1NNTVVfRkVBVF9BU0lEXzE2 ID8gMSA6IDApOw0KKyAgICAgICAgICAgIGlmICggKHNtbXUtPmZlYXR1cmVzICYgQVJNX1NNTVVf RkVBVF9UVF9MRSkgJiYNCisgICAgICAgICAgICAgICAgKHNtbXUtPmZlYXR1cmVzICYgQVJNX1NN TVVfRkVBVF9UVF9CRSkgKQ0KKyAgICAgICAgICAgICAgICByZWcgfD0gRklFTERfUFJFUChJRFIw X1RURU5ESUFOLCBJRFIwX1RURU5ESUFOX01JWEVEKTsNCisgICAgICAgICAgICBlbHNlIGlmICgg c21tdS0+ZmVhdHVyZXMgJiBBUk1fU01NVV9GRUFUX1RUX0xFICkNCisgICAgICAgICAgICAgICAg cmVnIHw9IEZJRUxEX1BSRVAoSURSMF9UVEVORElBTiwgSURSMF9UVEVORElBTl9MRSk7DQorICAg ICNpZmRlZiBfX0JJR19FTkRJQU4NCisgICAgICAgICAgICBlbHNlIGlmICggc21tdS0+ZmVhdHVy ZXMgJiBBUk1fU01NVV9GRUFUX1RUX0JFICkNCisgICAgICAgICAgICAgICAgcmVnIHw9IEZJRUxE X1BSRVAoSURSMF9UVEVORElBTiwgSURSMF9UVEVORElBTl9CRSk7DQorICAgICNlbmRpZg0KKyAg ICAgICAgICAgICpyID0gdnJlZ19yZWczMl9leHRyYWN0KHJlZywgaW5mbyk7DQorICAgICAgICAg ICAgYnJlYWs7DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9JRFIxKToNCisgICAg ICAgICAgICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisg ICAgICAgICAgICByZWcgID0gRklFTERfUFJFUChJRFIxX1NJRFNJWkUsIFNNTVVfSURSMV9TSURT SVpFKSB8DQorICAgICAgICAgICAgICAgIEZJRUxEX1BSRVAoSURSMV9DTURRUywgU01NVV9DTURR UykgfA0KKyAgICAgICAgICAgICAgICBGSUVMRF9QUkVQKElEUjFfRVZUUVMsIFNNTVVfRVZUUVMp Ow0KKyAgICAgICAgICAgICpyID0gdnJlZ19yZWczMl9leHRyYWN0KHJlZywgaW5mbyk7DQorICAg ICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9JRFIyKToN CisgICAgICAgICAgICBnb3RvIHJlYWRfcmVzZXJ2ZWQ7DQorDQorICAgICAgICBjYXNlIFZSRUcz MihBUk1fU01NVV9JRFIzKToNCisgICAgICAgICAgICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dP UkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAgICAgICByZWcgPSAwOw0KKyAgICAgICAgICAg ICpyID0gdnJlZ19yZWczMl9leHRyYWN0KHJlZywgaW5mbyk7DQorICAgICAgICAgICAgYnJlYWs7 DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9JRFI0KToNCisgICAgICAgICAgICBn b3RvIHJlYWRfaW1wbF9kZWZpbmVkOw0KKw0KKyAgICAgICAgY2FzZSBWUkVHMzIoQVJNX1NNTVVf SURSNSk6DQorICAgICAgICAgICAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBi YWRfd2lkdGg7DQorICAgICAgICAgICAgcmVnID0gMDsNCisgICAgICAgICAgICBpZiAoc21tdS0+ ZmVhdHVyZXMgJiBBUk1fU01NVV9GRUFUX0dSQU42NEspDQorICAgICAgICAgICAgICAgIHJlZyB8 PSBJRFI1X0dSQU42NEs7DQorICAgICAgICAgICAgaWYgKHNtbXUtPmZlYXR1cmVzICYgQVJNX1NN TVVfRkVBVF9HUkFOMTZLKQ0KKyAgICAgICAgICAgICAgICByZWcgfD0gSURSNV9HUkFOMTZLOw0K KyAgICAgICAgICAgIGlmIChzbW11LT5mZWF0dXJlcyAmIEFSTV9TTU1VX0ZFQVRfR1JBTjRLKQ0K KyAgICAgICAgICAgICAgICByZWcgfD0gSURSNV9HUkFONEs7DQorDQorICAgICAgICAgICAgaWYg KHNtbXUtPmZlYXR1cmVzICYgQVJNX1NNTVVfRkVBVF9PQVNfMzJfQklUKQ0KKyAgICAgICAgICAg ICAgICByZWcgfD0gSURSNV9PQVNfMzJfQklUOw0KKyAgICAgICAgICAgIGlmIChzbW11LT5mZWF0 dXJlcyAmIEFSTV9TTU1VX0ZFQVRfT0FTXzM2X0JJVCkNCisgICAgICAgICAgICAgICAgcmVnIHw9 IElEUjVfT0FTXzM2X0JJVDsNCisgICAgICAgICAgICBpZiAoc21tdS0+ZmVhdHVyZXMgJiBBUk1f U01NVV9GRUFUX09BU180MF9CSVQpDQorICAgICAgICAgICAgICAgIHJlZyB8PSBJRFI1X09BU180 MF9CSVQ7DQorICAgICAgICAgICAgaWYgKHNtbXUtPmZlYXR1cmVzICYgQVJNX1NNTVVfRkVBVF9P QVNfNDJfQklUKQ0KKyAgICAgICAgICAgICAgICByZWcgfD0gSURSNV9PQVNfNDJfQklUOw0KKyAg ICAgICAgICAgIGlmIChzbW11LT5mZWF0dXJlcyAmIEFSTV9TTU1VX0ZFQVRfT0FTXzQ0X0JJVCkN CisgICAgICAgICAgICAgICAgcmVnIHw9IElEUjVfT0FTXzQ0X0JJVDsNCisgICAgICAgICAgICBp ZiAoc21tdS0+ZmVhdHVyZXMgJiBBUk1fU01NVV9GRUFUX09BU180OF9CSVQpDQorICAgICAgICAg ICAgICAgIHJlZyB8PSBJRFI1X09BU180OF9CSVQ7DQorICAgICAgICAgICAgaWYgKHNtbXUtPmZl YXR1cmVzICYgQVJNX1NNTVVfRkVBVF9PQVNfNTJfQklUKQ0KKyAgICAgICAgICAgICAgICByZWcg fD0gSURSNV9PQVNfNTJfQklUOw0KKw0KKyAgICAgICAgICAgICpyID0gdnJlZ19yZWczMl9leHRy YWN0KHJlZywgaW5mbyk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICBjYXNlIFZS RUczMihBUk1fU01NVV9JSURSKToNCisgICAgICAgICAgICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJU X1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAgICAgICAvKiBVc2UgZ2VuZXJpYyBBUk0g SUlEUiB2YWx1ZSB0byBhdm9pZCBhY3RpdmF0aW5nIGVycmF0YSB3b3JrYXJvdW5kcyAqLw0KKyAg ICAgICAgICAgIHJlZyAgPSBGSUVMRF9QUkVQKElJRFJfSU1QTEVNRU5URVIsIElJRFJfSU1QTEVN RU5URVJfQVJNKSB8DQorICAgICAgICAgICAgICAgIEZJRUxEX1BSRVAoSUlEUl9SRVZJU0lPTiwg MCkgfA0KKyAgICAgICAgICAgICAgICBGSUVMRF9QUkVQKElJRFJfVkFSSUFOVCwgMCkgfA0KKyAg ICAgICAgICAgICAgICBGSUVMRF9QUkVQKElJRFJfUFJPRFVDVElELCAwKTsNCisgICAgICAgICAg ICAqciA9IHZyZWdfcmVnMzJfZXh0cmFjdChyZWcsIGluZm8pOw0KKyAgICAgICAgICAgIGJyZWFr Ow0KKw0KKyAgICAgICAgY2FzZSBWUkVHMzIoQVJNX1NNTVVfQ1IwKToNCisgICAgICAgICAgICBp ZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAgICAg ICBzcGluX2xvY2soJnNtbXUtPmNyMF9sb2NrKTsNCisgICAgICAgICAgICAqciA9IHZyZWdfcmVn MzJfZXh0cmFjdChzbW11LT5jclswXSwgaW5mbyk7DQorICAgICAgICAgICAgc3Bpbl91bmxvY2so JnNtbXUtPmNyMF9sb2NrKTsNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGNhc2Ug VlJFRzMyKEFSTV9TTU1VX0NSMEFDSyk6DQorICAgICAgICAgICAgaWYgKCBkYWJ0LnNpemUgIT0g REFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAgICAgc3Bpbl9sb2NrKCZzbW11 LT5jcjBfbG9jayk7DQorICAgICAgICAgICAgKnIgPSB2cmVnX3JlZzMyX2V4dHJhY3Qoc21tdS0+ Y3IwYWNrLCBpbmZvKTsNCisgICAgICAgICAgICBzcGluX3VubG9jaygmc21tdS0+Y3IwX2xvY2sp Ow0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgY2FzZSBWUkVHMzIoQVJNX1NNTVVf Q1IxKToNCisgICAgICAgICAgICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJh ZF93aWR0aDsNCisgICAgICAgICAgICBzcGluX2xvY2soJnNtbXUtPmNyMV9sb2NrKTsNCisgICAg ICAgICAgICAqciA9IHZyZWdfcmVnMzJfZXh0cmFjdChzbW11LT5jclsxXSwgaW5mbyk7DQorICAg ICAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPmNyMV9sb2NrKTsNCisgICAgICAgICAgICBicmVh azsNCisNCisgICAgICAgIGNhc2UgVlJFRzMyKEFSTV9TTU1VX0NSMik6DQorICAgICAgICAgICAg aWYgKCBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAg ICAgc3Bpbl9sb2NrKCZzbW11LT5jcjJfbG9jayk7DQorICAgICAgICAgICAgKnIgPSB2cmVnX3Jl ZzMyX2V4dHJhY3Qoc21tdS0+Y3JbMl0sIGluZm8pOw0KKyAgICAgICAgICAgIHNwaW5fdW5sb2Nr KCZzbW11LT5jcjJfbG9jayk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICBjYXNl IFZSRUc2NChBUk1fU01NVV9TVFJUQUJfQkFTRSk6DQorICAgICAgICAgICAgaWYgKCBkYWJ0LnNp emUgIT0gREFCVF9ET1VCTEVfV09SRCAmJiBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkNCisgICAg ICAgICAgICAgICAgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAgICAgc3Bpbl9sb2NrKCZzbW11 LT5zdHJ0YWJfY2ZnX2xvY2spOw0KKyAgICAgICAgICAgICpyID0gdnJlZ19yZWc2NF9leHRyYWN0 KHNtbXUtPnN0cnRhYl9iYXNlLCBpbmZvKTsNCisgICAgICAgICAgICBzcGluX3VubG9jaygmc21t dS0+c3RydGFiX2NmZ19sb2NrKTsNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGNh c2UgVlJFRzMyKEFSTV9TTU1VX1NUUlRBQl9CQVNFX0NGRyk6DQorICAgICAgICAgICAgaWYgKCBk YWJ0LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAgICAgc3Bp bl9sb2NrKCZzbW11LT5zdHJ0YWJfY2ZnX2xvY2spOw0KKyAgICAgICAgICAgICpyID0gdnJlZ19y ZWczMl9leHRyYWN0KHNtbXUtPnN0cnRhYl9iYXNlX2NmZywgaW5mbyk7DQorICAgICAgICAgICAg c3Bpbl91bmxvY2soJnNtbXUtPnN0cnRhYl9jZmdfbG9jayk7DQorICAgICAgICAgICAgYnJlYWs7 DQorDQorICAgICAgICBjYXNlIFZSRUc2NChBUk1fU01NVV9DTURRX0JBU0UpOg0KKyAgICAgICAg ICAgIGlmICggZGFidC5zaXplICE9IERBQlRfRE9VQkxFX1dPUkQgJiYgZGFidC5zaXplICE9IERB QlRfV09SRCApDQorICAgICAgICAgICAgICAgIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAgICAgICAg IHNwaW5fbG9jaygmc21tdS0+Y21kX3F1ZXVlX2xvY2spOw0KKyAgICAgICAgICAgICpyID0gdnJl Z19yZWc2NF9leHRyYWN0KHNtbXUtPmNtZHEucV9iYXNlLCBpbmZvKTsNCisgICAgICAgICAgICBz cGluX3VubG9jaygmc21tdS0+Y21kX3F1ZXVlX2xvY2spOw0KKyAgICAgICAgICAgIGJyZWFrOw0K Kw0KKyAgICAgICAgY2FzZSBWUkVHMzIoQVJNX1NNTVVfQ01EUV9QUk9EKToNCisgICAgICAgICAg ICBpZiAoIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQgKSBnb3RvIGJhZF93aWR0aDsNCisgICAgICAg ICAgICBzcGluX2xvY2soJnNtbXUtPmNtZF9xdWV1ZV9sb2NrKTsNCisgICAgICAgICAgICAqciA9 IHZyZWdfcmVnMzJfZXh0cmFjdChzbW11LT5jbWRxLnByb2QsIGluZm8pOw0KKyAgICAgICAgICAg IHNwaW5fdW5sb2NrKCZzbW11LT5jbWRfcXVldWVfbG9jayk7DQorICAgICAgICAgICAgYnJlYWs7 DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9DTURRX0NPTlMpOg0KKyAgICAgICAg ICAgIGlmICggZGFidC5zaXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAg ICAgICAgIHNwaW5fbG9jaygmc21tdS0+Y21kX3F1ZXVlX2xvY2spOw0KKyAgICAgICAgICAgICpy ID0gdnJlZ19yZWczMl9leHRyYWN0KHNtbXUtPmNtZHEuY29ucywgaW5mbyk7DQorICAgICAgICAg ICAgc3Bpbl91bmxvY2soJnNtbXUtPmNtZF9xdWV1ZV9sb2NrKTsNCisgICAgICAgICAgICBicmVh azsNCisNCisgICAgICAgIGNhc2UgVlJFRzY0KEFSTV9TTU1VX0VWVFFfQkFTRSk6DQorICAgICAg ICAgICAgaWYgKCBkYWJ0LnNpemUgIT0gREFCVF9ET1VCTEVfV09SRCAmJiBkYWJ0LnNpemUgIT0g REFCVF9XT1JEICkNCisgICAgICAgICAgICAgICAgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAg ICAgc3Bpbl9sb2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7DQorICAgICAgICAgICAgKnIgPSB2 cmVnX3JlZzY0X2V4dHJhY3Qoc21tdS0+ZXZ0cS5xX2Jhc2UsIGluZm8pOw0KKyAgICAgICAgICAg IHNwaW5fdW5sb2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7DQorICAgICAgICAgICAgYnJlYWs7 DQorDQorICAgICAgICBjYXNlIFZSRUczMihBUk1fU01NVV9JUlFfQ1RSTCk6DQorICAgICAgICBj YXNlIFZSRUczMihBUk1fU01NVV9JUlFfQ1RSTEFDSyk6DQorICAgICAgICAgICAgaWYgKCBkYWJ0 LnNpemUgIT0gREFCVF9XT1JEICkgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAgICAgc3Bpbl9s b2NrKCZzbW11LT5pcnFfY2ZnX2xvY2spOw0KKyAgICAgICAgICAgICpyID0gdnJlZ19yZWczMl9l eHRyYWN0KHNtbXUtPmlycV9jdHJsLCBpbmZvKTsNCisgICAgICAgICAgICBzcGluX3VubG9jaygm c21tdS0+aXJxX2NmZ19sb2NrKTsNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGNh c2UgVlJFRzY0KEFSTV9TTU1VX0dFUlJPUl9JUlFfQ0ZHMCk6DQorICAgICAgICAgICAgaWYgKCBk YWJ0LnNpemUgIT0gREFCVF9ET1VCTEVfV09SRCAmJiBkYWJ0LnNpemUgIT0gREFCVF9XT1JEICkN CisgICAgICAgICAgICAgICAgZ290byBiYWRfd2lkdGg7DQorICAgICAgICAgICAgc3Bpbl9sb2Nr KCZzbW11LT5pcnFfY2ZnX2xvY2spOw0KKyAgICAgICAgICAgICpyID0gdnJlZ19yZWc2NF9leHRy YWN0KHNtbXUtPmdlcnJvcl9pcnFfY2ZnMCwgaW5mbyk7DQorICAgICAgICAgICAgc3Bpbl91bmxv Y2soJnNtbXUtPmlycV9jZmdfbG9jayk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAg ICBjYXNlIFZSRUc2NChBUk1fU01NVV9FVlRRX0lSUV9DRkcwKToNCisgICAgICAgICAgICBpZiAo IGRhYnQuc2l6ZSAhPSBEQUJUX0RPVUJMRV9XT1JEICYmIGRhYnQuc2l6ZSAhPSBEQUJUX1dPUkQg KQ0KKyAgICAgICAgICAgICAgICBnb3RvIGJhZF93aWR0aDsNCisgICAgICAgICAgICBzcGluX2xv Y2soJnNtbXUtPmlycV9jZmdfbG9jayk7DQorICAgICAgICAgICAgKnIgPSB2cmVnX3JlZzY0X2V4 dHJhY3Qoc21tdS0+ZXZ0cV9pcnFfY2ZnMCwgaW5mbyk7DQorICAgICAgICAgICAgc3Bpbl91bmxv Y2soJnNtbXUtPmlycV9jZmdfbG9jayk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAg ICBjYXNlIFZSRUczMihBUk1fU01NVV9HRVJST1IpOg0KKyAgICAgICAgICAgIGlmICggZGFidC5z aXplICE9IERBQlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAgICAgICAgIHNwaW5fbG9j aygmc21tdS0+Z2Vycm9yX2xvY2spOw0KKyAgICAgICAgICAgICpyID0gdnJlZ19yZWczMl9leHRy YWN0KHNtbXUtPmdlcnJvciwgaW5mbyk7DQorICAgICAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUt PmdlcnJvcl9sb2NrKTsNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGNhc2UgVlJF RzMyKEFSTV9TTU1VX0dFUlJPUk4pOg0KKyAgICAgICAgICAgIGlmICggZGFidC5zaXplICE9IERB QlRfV09SRCApIGdvdG8gYmFkX3dpZHRoOw0KKyAgICAgICAgICAgIHNwaW5fbG9jaygmc21tdS0+ Z2Vycm9yX2xvY2spOw0KKyAgICAgICAgICAgICpyID0gdnJlZ19yZWczMl9leHRyYWN0KHNtbXUt PmdlcnJvcm4sIGluZm8pOw0KKyAgICAgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5nZXJyb3Jf bG9jayk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICBkZWZhdWx0Og0KKyAgICAg ICAgICAgIHByaW50ayhYRU5MT0dfR19FUlINCisgICAgICAgICAgICAgICAgIiVwZDogdlNNTVV2 MzogdW5oYW5kbGVkIHJlYWQgciVkIG9mZnNldCAlIlBSSXBhZGRyIlxuIiwNCisgICAgICAgICAg ICAgICAgdi0+ZG9tYWluLCBpbmZvLT5kYWJ0LnJlZywgKHVuc2lnbmVkIGxvbmcpaW5mby0+Z3Bh ICYgMHhmZmZmKTsNCisgICAgICAgICAgICByZXR1cm4gSU9fSEFORExFRDsNCisgICAgICAgIH0N CisgICAgfQ0KKyAgICByZXR1cm4gSU9fSEFORExFRDsNCisNCisgcmVhZF9pbXBsX2RlZmluZWQ6 DQorICAgIHByaW50ayhYRU5MT0dfR19ERUJVRw0KKyAgICAgICAgICAgIiVwZDogdlNNTVV2Mzog UkFaIG9uIGltcGxlbWVudGF0aW9uIGRlZmluZWQgcmVnaXN0ZXIgb2Zmc2V0ICUiUFJJcGFkZHIi XG4iLA0KKyAgICAgICAgICAgdi0+ZG9tYWluLCBpbmZvLT5ncGEgJiAweGZmZmYpOw0KKyAgICAq ciA9IDA7DQorICAgIHJldHVybiBJT19IQU5ETEVEOw0KKw0KKyByZWFkX3Jlc2VydmVkOg0KKyAg ICBwcmludGsoWEVOTE9HX0dfREVCVUcNCisgICAgICAgICAgICIlcGQ6IHZTTU1VdjM6IFJBWiBv biByZXNlcnZlZCByZWdpc3RlciBvZmZzZXQgJSJQUklwYWRkciJcbiIsDQorICAgICAgICAgICB2 LT5kb21haW4sIGluZm8tPmdwYSAmIDB4ZmZmZik7DQorICAgICpyID0gMDsNCisgICAgcmV0dXJu IElPX0hBTkRMRUQ7DQorIGJhZF93aWR0aDoNCisgICAgZ3ByaW50ayhYRU5MT0dfR19FUlIsDQor ICAgICAgICAgICAgIiVwZDogdlNNTVV2MzogYmFkIHJlYWQgd2lkdGggJWQgciVkIG9mZnNldCAl IlBSSXBhZGRyIlxuIiwNCisgICAgICAgICAgICB2LT5kb21haW4sIGRhYnQuc2l6ZSwgZGFidC5y ZWcsIGluZm8tPmdwYSAmIDB4ZmZmZik7DQogICAgIHJldHVybiBJT19IQU5ETEVEOw0KIH0NCiAN CkBAIC00NCw2ICs2MDIsMTcgQEAgc3RhdGljIGludCB2c21tdXYzX2luaXRfc2luZ2xlKHN0cnVj dCBkb21haW4gKmQsIHBhZGRyX3QgYWRkciwgcGFkZHJfdCBzaXplLA0KIA0KICAgICBzbW11LT5k ID0gZDsNCiAgICAgc21tdS0+ZmVhdHVyZXMgPSBmZWF0dXJlczsNCisgICAgc21tdS0+Y21kcS5l bnRfc2l6ZSA9IENNRFFfRU5UX0RXT1JEUyAqIERXT1JEU19CWVRFUzsNCisgICAgc21tdS0+ZXZ0 cS5lbnRfc2l6ZSA9IEVWVFFfRU5UX0RXT1JEUyAqIERXT1JEU19CWVRFUzsNCisNCisgICAgc3Bp bl9sb2NrX2luaXQoJnNtbXUtPmNtZF9xdWV1ZV9sb2NrKTsNCisgICAgc3Bpbl9sb2NrX2luaXQo JnNtbXUtPmV2dF9xdWV1ZV9sb2NrKTsNCisgICAgc3Bpbl9sb2NrX2luaXQoJnNtbXUtPmdlcnJv cl9sb2NrKTsNCisgICAgc3Bpbl9sb2NrX2luaXQoJnNtbXUtPmNyMF9sb2NrKTsNCisgICAgc3Bp bl9sb2NrX2luaXQoJnNtbXUtPmNyMV9sb2NrKTsNCisgICAgc3Bpbl9sb2NrX2luaXQoJnNtbXUt PmNyMl9sb2NrKTsNCisgICAgc3Bpbl9sb2NrX2luaXQoJnNtbXUtPnN0cnRhYl9jZmdfbG9jayk7 DQorICAgIHNwaW5fbG9ja19pbml0KCZzbW11LT5pcnFfY2ZnX2xvY2spOw0KIA0KICAgICByZWdp c3Rlcl9tbWlvX2hhbmRsZXIoZCwgJnZzbW11djNfbW1pb19oYW5kbGVyLCBhZGRyLCBzaXplLCBz bW11KTsNCiANCi0tIA0KMi40My4wDQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441823.1659387 (Exim 4.92) (envelope-from ) id 1xEFBW-0001IF-L5; Wed, 07 Oct 2026 00:07:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441823.1659387; Wed, 07 Oct 2026 00:07: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 1xEFBW-0001Hz-GB; Wed, 07 Oct 2026 00:07:02 +0000 Received: by outflank-mailman (input) for mailman id 1441823; Wed, 07 Oct 2026 00:07:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBV-000166-BJ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBU-007OBc-OG for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:00 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58cc9-bab6-0a2a0a5309dd-0a2a450abe3a-44 for ; Wed, 07 Oct 2026 02:07:00 +0200 Received: from [40.107.159.76] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d24-f2d2-0a2a450a0019-286b9f4c3390-3 for ; Wed, 07 Oct 2026 02:07:00 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:06:59 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:06: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=OrMeCo8BTIo/tkZ2aoMVlMM5OHxj5tJ2IiwAG3wX5A2zJmBVF3Bm0Yu+x2sHEZFRH9Z9PCGYRo329Je/LupiEj6nkU06KWe/aCo5PD2wPbrH6Ky/qNdflqgVcCwwWNn7cw2v2TtIhmfBl/SjelcfY7wEn3vQxaVOMRO6c8Z3BDdWSPq96US+stlMRVtZK9+Ef/bdSevclQBXsu1Rx9K617LYuzvs7sQ45LG31Drb3mkblqxlF3WSxsmw8vVJTVxDoA8oaOJqG8zEo4V8TXU04GaRNpgO+U1/9SQojbzrycNdMRrdzYBSjDC28ud/J/G2a2zjIkkfSnvwmtbltFt57Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZX1fkNMEr4jp0dkdFeex4eMUWUikMiPdGtiu6YaUq9U=; b=S6G8OYkvpXXcoVuj/dspUS4Y+wjVVfxEQLIxWVxil5VylJrA2gPlZxEqsgZP7Zm76FZ3ABhKRDoBk7nhlGbMpDhYvY1RhacetbwAmPB2SGZPNwS7okC6IZypVlkLmm+BgTTgrNt5Oll8guKDeLD0QSpuQ+qh5ZRf96VcSr6GKXuaq0cdZcACn+rKdrlmjpbiC5sYul/d6dHkQ7+TT4GeyV1xdT18kUpZWBRGq2uTZAgaUy1WyrEk6Aq2WRp8mvIEbifshRiuy/TTQeMDOtySY/s2hMZo32ToATMC/R0+E/seUnG6arbcQ2s9EV+Gq7L1V56lrCPm4UEN/PWO/VzB4A== 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=ZX1fkNMEr4jp0dkdFeex4eMUWUikMiPdGtiu6YaUq9U=; b=Ase6/KUqs9d5JFfwj4LSOcuIiBLgt0HyPluh/LnY2Y3nR+PfNsWy4IxbYg4Ve89JctJw0UCG3DBtHIjB+VbzXtBBjEx/h9YailinDuAjZ80Gb9i76iaIadBPlpPfqRb/rSoLnK0KUFFmRCi6gGgcsdZSWUGNXuM6scAli0i3WB/4cw02iA9bWcdk/SUHZW2u5o28kazBUf0EKaZgdmEbGr1IdVZ5kas8/ClKUkEFDoAO4VoczbtLQ9L8VRF8Ct0m87KsFi8ZosYRiN+zUB7rGja4lz+2c8rdTaqDMlqYeiVqtJm6jOb+e7jJ+ZhNhFVeQlsmtopNNuHnvy+JCv7I+A== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 09/22] xen/arm: vsmmuv3: Add support for cmdqueue handling Thread-Topic: [PATCH v4 09/22] xen/arm: vsmmuv3: Add support for cmdqueue handling Thread-Index: AQHdVe/FeuyLdMB91Eu+JPmDuJ9vXw== Date: Wed, 7 Oct 2026 00:06:58 +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: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 05f0c31c-419a-4d02-0685-08df2406e7cd x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|3023799007|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: xNxCcjEM1NxhoPH1HxJCASu3AOcGCKakDmszI+bOLTz1gvcltd3AEKilhQ3HBm9uJ9+MdxVyluzJCfXs5kYPnEIO3aKwS1+0fSyagavzCEbqDzTNfacWlAxrVNRtYJHaBI5s3vKgHeZ3ThwzTHWyhP7HVmZNRWxhwL58VJpgh7lLWLSULnWgT3hyZ8Xug6bMCEyOpVZ3acGKOURuqCW5fxEFr8uD0JkEvsK/qwbOL83JBqoBcHoq3minpFbAsVYZv+yghXe2iQH1pJJ3EE3JrDiv3uotow2Mao07fDnm9DnEX9+e29XjzdlP7OiYNz1MWVY7EPpm16yApfxCc5Nrgk+CUHBsHxuyIFSIvj4ChyNHD0y10mHufG5l7mQOoJ29COCQI3gxzHPvAQ/FSIq4ajEgO5CjoZBKyOtQOBbWhu1N0HXQFnnJPhLkrMHNaT7uN1F+633wllV3F3huWmL5FzDOBktz/apyHkRGVzUao73DTGUWvgj0/JunyGSomTrlc/O1ZSOt0MCxCQIAqUQz1/aLgOBTtpGIZ/GvApoTVv+ta7WGvDDX23iooqnz4kOj7h/0lAKqG+IEKdbJUspdKnrv+KqKgHLSRcItzqOSFYUwbAxikkitatLsK57+4vUF99CE9G5MNuZkiUryOeOiROXAsCnEzTxYk7gj81hXjVybzaoy0VKEkVubOkAkNuj0VixrPDGiSBFG1RAZtdXZiHAPMZDnhHUfF7UnXR8P3yM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(3023799007)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OWQ1SmdMN3VsSGJ4WWFnTEx4eFlCL0QxakxqMElrRDFGbEJmZlh2NmY2YnBE?= =?utf-8?B?eGJtVGlZWWpWeGhUL0t5MDNnT1hxUGw3Q2MvSXVHN1F2MmZ3YWdVeUlzVjFY?= =?utf-8?B?bWNZcnF6YU5jVVNZaVZxWXl0NzZ0WVdWQU9QeThkcWd5NzBwbGZiejM0WUZl?= =?utf-8?B?VzVOUXI1dnhvNEF4R1BMTmRzUjVaNjZmTWI1WkRraTRnS1BZMG9LWG44N0Ix?= =?utf-8?B?aTFyZit5dnFCYUlxanNpTFhVd2w4MlBYRW1oN1hPM1lKd3JpUm5LWGZKcEdx?= =?utf-8?B?UyswTmJEZHIzdnVHNWZOeW5aeHZnVy9LN0wvYUpmVktNdnY3REo2eXlDNkFp?= =?utf-8?B?ZUVrWnJ6dHlzMGQ5bWl6L1A2QTVYUEJEc1RZWm90QnNCV3hTMndCYXJWZHhS?= =?utf-8?B?QkZONitSUTZoRTZGWjdaMUtXWS9uTWdUOHVBbEYrM3o3MVBJc204Z2pFdDAw?= =?utf-8?B?MFVHYk8vOFZ0UVp6WWI1bGpmZk5oMHZQZExjaGZFVWlBSEFHVHo3dlZFQWQ5?= =?utf-8?B?dnJ3WDdKS0Z6K2tFYUllM04wWE1Pdm52OXlab1RxYS90cXF6Nnc2bSs1M3RB?= =?utf-8?B?OXdPeFNUd1JVT2pmdWNBRnJQQ0VzR2J1cHVZOWNIUE9kMXVBTXovNG5yamRs?= =?utf-8?B?VkRLeXp2aDFMeEFhb3RXNk10bnp0RkhkZjdTT05LZUJ0Z0Q3TFpGNCtNa2k1?= =?utf-8?B?aUpGeUpIKzR0QjJaV1hraGZtb2xwN2drS0d0dGdCbFk5Slh6UzBTYUc3SDRI?= =?utf-8?B?S3NSV3ppbVBMR3J5aXF1eElnWGVjSVdyUFM4ZWdIQzB5L2NyZVV6ODdWak9r?= =?utf-8?B?ZWthbzNXNVNvYWRUcVBseUdUaXJnemNtVHlKRzNQZ1dYekxLWXZWS0RLSHNq?= =?utf-8?B?bUNpQmt5MnZVZ0llai9iREgrUTlOVHZIQWhaVUQ5NHFJemZnWS9IYUtON3FT?= =?utf-8?B?SXVqeDZLQzdkSTR5ZVhINmtwRzRyK1lqaU40bjE5SzEyUHhYZGlIRTllRCtG?= =?utf-8?B?bFE1NWd5UW5uRFhaeTFyUUxMWUUwQnFDZ1V2aEVXSVMyeVZwRVlIM3ZVR1hU?= =?utf-8?B?cFhTYjBsVnhUalZnSkEwa0RlNVRWWGJkL1JLSjFKVC9XdVg0bWVPSTdwZTJZ?= =?utf-8?B?c1NBMGdMMWUweXpuTitPQ1FUeUJ2T3hyTUtnVG9TS3dySDM2eitxd05kY1BW?= =?utf-8?B?VTl3blVrMkFYTTJJUmFMQ0xOVU04akowMkM3NjZ3OEF5UmJKMTJzTnEyUy8y?= =?utf-8?B?Yk9rZUliNTkyU2FxWmZ6MUJhUC9nMG9HTUNwTGNpMkRBTUlCa0F2cUNlemhY?= =?utf-8?B?WnBZZU9heDVxVW1Hclh5aUs4ZFlGVDZVQnRVdkRBMWozRVV2amlRNHRMWFdI?= =?utf-8?B?ZWJKRytYTmcwTHBWbDRSTWg2VSsyeEtXYjhjcmN6UnllMUZzL1N6V0FtNFdT?= =?utf-8?B?T29DTm13Q1FtSy8yTzNLYVN4RDVHb1pyekhuaUtkWDNHdFFzTThRcjUyVlVW?= =?utf-8?B?YWNPTVovUmdSQkM0OVV3OFVoeFJlUXU5bm1FdGZnV29nbmhhUkZXU3NjeW5U?= =?utf-8?B?cHg4QjVJdmF0TUY1OURJL1d5bnliQnlYYS9aMG1JQWZGdnVocjlhSmdPa0pN?= =?utf-8?B?c0VtTmNsZkNmUi9pZUk3aGdaUE85RzVVNE9uNVpadllPNnphZ3BtbmJOOHdu?= =?utf-8?B?NE1aM1UxVEJKdFBzQ3NPZlRqOEk0dGZjUENJVDc2c2Q4T1RyL1hYRnJKcVNH?= =?utf-8?B?SnpaWGFTWVhRM3BFZVZIbFVYUE1GdFhhS0U3VjlLM1JFdW1XREJRaUNKdUd6?= =?utf-8?B?TXBpNTFNNXFEY3FzSWEySlQ0cU5pKzU3a1NMZERjTlZHSGsreXJ4RXIva0FM?= =?utf-8?B?TWZndkJxM1JBNzVwOFkwNFpuNzlTWWs4ZmhXNXVHUXE0N3V5MlZ1YWVwZDlQ?= =?utf-8?B?aFdHUWV0VzJ2QnZQNUFTRUdzT3dJRXprUzlYUk81Y2d2WjJLYzl1TlE0VElh?= =?utf-8?B?WEhDajBETEpkU0dlTUhFUVQ2YXY1RG1wa2szZmtIU1dMUVpiVHIyMWh0d1Vm?= =?utf-8?B?VnA5OVFXL0NDc0xHVVdEZ1JIUXFFd2MrSEhWdEJqL3NBSzhaL2xYK29mRlQ3?= =?utf-8?B?aE5uUHl4aGQ2TE9SUFM0NXd6b1M1T28vRFJ2UFQyR3BlTGcwUm1ZYXVZTFI2?= =?utf-8?B?MVpBbzRjeklRblk2aHhOc1BvQ3ZJazhmZ0JyMXNJcm1mT1RPZUNaN2lETTNE?= =?utf-8?B?UmhRSS9hamFadmZIQnBJT1FGRFZLVVQ1TGN3Q1hhOXltblhKVUdodS92YVJI?= =?utf-8?B?NUdtNTYxNG1QODNPNmlYdWpmQk9FNFUzMW9DbFlPWW5BeG5tcXdQQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 05f0c31c-419a-4d02-0685-08df2406e7cd X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:58.7049 (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: cl+uhOYLPwbpYYpCqoBy7WscD/5V29QVH82DQbj5tRpxmj7Cd+vvCYJIWOrgdYBiE2XK1Q5EUYpFtvQyv1tfVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-4011c0/1791331620-524DFCFC-3EC5DF58/0/0 X-purgate-type: clean X-purgate-size: 7386 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkFkZCBzdXBwb3J0IGZv ciB2aXJ0dWFsIGNtZHF1ZXVlIGhhbmRsaW5nIGZvciBndWVzdHMNCg0KU2lnbmVkLW9mZi1ieTog UmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQpTaWduZWQtb2ZmLWJ5OiBNaWxhbiBE am9raWMgPG1pbGFuX2Rqb2tpY0BlcGFtLmNvbT4NCi0tLQ0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJv dWdoL2FybS92c21tdS12My5jIHwgMTI3ICsrKysrKysrKysrKysrKysrKysrKysrKysNCiAxIGZp bGUgY2hhbmdlZCwgMTI3IGluc2VydGlvbnMoKykNCg0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJz L3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5jIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJt L3ZzbW11LXYzLmMNCmluZGV4IGM0ZmVmNmU4YmQuLjEwMTQzOTI3ZTcgMTAwNjQ0DQotLS0gYS94 ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuYw0KKysrIGIveGVuL2RyaXZlcnMv cGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMNCkBAIC04LDYgKzgsNyBAQA0KICAqIFRoaXMgbmVl ZHMgdG8gYmUgZnVsbHkgaGFuZGxlZCBpbiB0aGUgZnV0dXJlLg0KICAqLw0KIA0KKyNpbmNsdWRl IDx4ZW4vZ3Vlc3RfYWNjZXNzLmg+DQogI2luY2x1ZGUgPHhlbi9wYXJhbS5oPg0KICNpbmNsdWRl IDx4ZW4vc2NoZWQuaD4NCiAjaW5jbHVkZSA8YXNtL21taW8uaD4NCkBAIC0zMyw2ICszNCw1MSBA QA0KICNkZWZpbmUgU01NVV9FVlRRUyAgICAgICAgICAxOQ0KICNkZWZpbmUgRFdPUkRTX0JZVEVT ICAgICAgICA4DQogDQorLyogDQorICogU01NVXYzIGNvbW1hbmQgZGVmaW5pdGlvbnMNCisgKiBT b21lIGNvbW1hbmRzIGFyZSBmdWxseSBoYW5kbGVkIGJ5IHRoZSBlbXVsYXRpb24gbGF5ZXIsIHdo aWxlIG90aGVycyBhcmUNCisgKiBjdXJyZW50bHkgdHJlYXRlZCBhcyBhcmNoaXRlY3R1cmFsIG5v LW9wcyBiZWNhdXNlIHRoZSByZXF1aXJlZCBiZWhhdmlvcg0KKyAqIGlzIGVpdGhlciBpbXBsaWNp dGx5IGd1YXJhbnRlZWQgYnkgWGVuIG9yIG5vdCB5ZXQgbW9kZWxlZCBleHBsaWNpdGx5Lg0KKyAq DQorICogRW11bGF0aW9uIGhhbmRsZWQgY29tbWFuZHM6DQorICoNCisgKiAtIENNRF9DRkdJX1NU RQ0KKyAqIC0gQ01EX1RMQklfTkhfQVNJRA0KKyAqIC0gQ01EX1RMQklfTlNOSF9BTEwNCisgKiAt IENNRF9UTEJJX05IX1ZBDQorICoNCisgKiBOby1vcC9JbXBsaWNpdGx5IGhhbmRsZWQgY29tbWFu ZHM6DQorICoNCisgKiAtIENNRF9TWU5DDQorICogLSBDTURfUFJFRkVUQ0hfQ0ZHDQorICogLSBD TURfQ0ZHSV9DRA0KKyAqIC0gQ01EX0NGR0lfQ0RfQUxMDQorICogLSBDTURfQ0ZHSV9BTEwNCisg Kg0KKyAqIFRPRE86IFJlbWFpbmluZyBhcmNoaXRlY3R1cmUtZGVmaW5lZCBjb21tYW5kcyBhcmUg bm90IHN1cHBvcnRlZCAoZXJyb3INCisgKiBwcm9kdWNlZCksIGR1ZSB0byBsYWNrIG9mIHN1cHBv cnQgaW4gU01NVXYzIGRyaXZlciAvIGVtdWxhdGlvbiBsYXllcg0KKyAqIFRPRE86IFJhbmdlIC8g cGVyLWRldmljZSBpbnZhbGlkYXRpb24gbm90IHN1cHBvcnRlZCBhdG0NCisgKiBUT0RPOiBMb25n LXJ1bm5pbmcgY29tbWFuZCBxdWV1ZSBoYW5kbGluZyBpcyBub3QgaW1wbGVtZW50ZWQgKGNvbW1h bmQNCisgKiBjb25zdW1wdGlvbiBzaG91bGQgYmUgYnVkZ2V0ZWQgd2l0aCBhc3luY2hyb25vdXMg cmVzdW1wdGlvbikuDQorICovDQorI2RlZmluZSBDTURRX09QX1BSRUZFVENIX0NGRyAgICAweDEN CisjZGVmaW5lIENNRFFfT1BfQ0ZHSV9TVEUgICAgICAgIDB4Mw0KKyNkZWZpbmUgQ01EUV9PUF9D RkdJX0FMTCAgICAgICAgMHg0DQorI2RlZmluZSBDTURRX09QX0NGR0lfQ0QgICAgICAgICAweDUN CisjZGVmaW5lIENNRFFfT1BfQ0ZHSV9DRF9BTEwgICAgIDB4Ng0KKyNkZWZpbmUgQ01EUV9PUF9U TEJJX05IX0FTSUQgICAgMHgxMQ0KKyNkZWZpbmUgQ01EUV9PUF9UTEJJX05IX1ZBICAgICAgMHgx Mg0KKyNkZWZpbmUgQ01EUV9PUF9UTEJJX05TTkhfQUxMICAgMHgzMA0KKyNkZWZpbmUgQ01EUV9P UF9DTURfU1lOQyAgICAgICAgMHg0Ng0KKw0KKy8qIFF1ZXVlIEhhbmRsaW5nICovDQorI2RlZmlu ZSBRX0JBU0UocSkgICAgICAgKChxKS0+cV9iYXNlICYgUV9CQVNFX0FERFJfTUFTSykNCisjZGVm aW5lIFFfQ09OU19FTlQocSkgICAoUV9CQVNFKHEpICsgUV9JRFgocSwgKHEpLT5jb25zKSAqIChx KS0+ZW50X3NpemUpDQorI2RlZmluZSBRX1BST0RfRU5UKHEpICAgKFFfQkFTRShxKSArIFFfSURY KHEsIChxKS0+cHJvZCkgKiAocSktPmVudF9zaXplKQ0KKw0KKy8qIEhlbHBlciBNYWNyb3MgKi8N CisjZGVmaW5lIHNtbXVfY21kX2dldF9jb21tYW5kKHgpICAgICBGSUVMRF9HRVQoQ01EUV8wX09Q LCB4KQ0KKw0KIC8qIHZpcnR1YWwgc21tdSBxdWV1ZSAqLw0KIHN0cnVjdCBhcm1fdnNtbXVfcXVl dWUgew0KICAgICB1aW50NjRfdCAgICBxX2Jhc2U7IC8qIGJhc2UgcmVnaXN0ZXIgKi8NCkBAIC05 OSw2ICsxNDUsODMgQEAgc3RhdGljIGlubGluZSBib29sIHNtbXVfZ2V0X2V2dHFfZW5hYmxlZChz dHJ1Y3QgdmlydF9zbW11ICpzbW11KQ0KICAgICBzcGluX3VubG9jaygmc21tdS0+Y3IwX2xvY2sp Ow0KIA0KICAgICByZXR1cm4gZW5hYmxlZDsNCit9Ow0KKw0KKy8qIFF1ZXVlIG1hbmlwdWxhdGlv biBmdW5jdGlvbnMgKi8NCitzdGF0aWMgYm9vbCBxdWV1ZV9lbXB0eShzdHJ1Y3QgYXJtX3ZzbW11 X3F1ZXVlICpxKQ0KK3sNCisgICAgcmV0dXJuIFFfSURYKHEsIHEtPnByb2QpID09IFFfSURYKHEs IHEtPmNvbnMpICYmDQorICAgICAgICAgICBRX1dSUChxLCBxLT5wcm9kKSA9PSBRX1dSUChxLCBx LT5jb25zKTsNCit9DQorDQorc3RhdGljIHZvaWQgcXVldWVfaW5jX2NvbnMoc3RydWN0IGFybV92 c21tdV9xdWV1ZSAqcSkNCit7DQorICAgIHVpbnQzMl90IGNvbnMgPSAoUV9XUlAocSwgcS0+Y29u cykgfCBRX0lEWChxLCBxLT5jb25zKSkgKyAxOw0KKyAgICBxLT5jb25zID0gUV9PVkYocS0+Y29u cykgfCBRX1dSUChxLCBjb25zKSB8IFFfSURYKHEsIGNvbnMpOw0KK30NCisNCitzdGF0aWMgdm9p ZCBkdW1wX3NtbXVfY29tbWFuZCh1aW50NjRfdCAqY29tbWFuZCkNCit7DQorICAgIGdwcmludGso WEVOTE9HX0VSUiwgImNtZCAweCUwMmxseDogJTAxNiJQUkl4NjQiICUwMTYiUFJJeDY0IlxuIiwN CisgICAgICAgICAgICAgc21tdV9jbWRfZ2V0X2NvbW1hbmQoY29tbWFuZFswXSksIGNvbW1hbmRb MF0sIGNvbW1hbmRbMV0pOw0KK30NCitzdGF0aWMgaW50IGFybV92c21tdV9oYW5kbGVfY21kcyhz dHJ1Y3QgdmlydF9zbW11ICpzbW11KQ0KK3sNCisgICAgc3RydWN0IGFybV92c21tdV9xdWV1ZSAq cSA9ICZzbW11LT5jbWRxOw0KKyAgICBzdHJ1Y3QgZG9tYWluICpkID0gc21tdS0+ZDsNCisgICAg dWludDY0X3QgY29tbWFuZFtDTURRX0VOVF9EV09SRFNdOw0KKyAgICBwYWRkcl90IGFkZHI7DQor ICAgIGludCByZXQgPSAwOw0KKw0KKyAgICBpZiAoICFzbW11X2dldF9jbWRxX2VuYWJsZWQoc21t dSkgKQ0KKyAgICAgICAgcmV0dXJuIDA7DQorDQorICAgIHdoaWxlICggIXF1ZXVlX2VtcHR5KHEp ICkNCisgICAgew0KKyAgICAgICAgaW50IHJldDsNCisNCisgICAgICAgIGFkZHIgPSBRX0NPTlNf RU5UKHEpOw0KKyAgICAgICAgcmV0ID0gYWNjZXNzX2d1ZXN0X21lbW9yeV9ieV9ncGEoZCwgYWRk ciwgY29tbWFuZCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNp emVvZihjb21tYW5kKSwgZmFsc2UpOw0KKyAgICAgICAgaWYgKCByZXQgKSB7DQorICAgICAgICAg ICAgcXVldWVfaW5jX2NvbnMocSk7DQorICAgICAgICAgICAgcmV0dXJuIHJldDsNCisgICAgICAg IH0NCisNCisgICAgICAgIHN3aXRjaCAoIHNtbXVfY21kX2dldF9jb21tYW5kKGNvbW1hbmRbMF0p ICkNCisgICAgICAgIHsNCisgICAgICAgIGNhc2UgQ01EUV9PUF9DRkdJX1NURToNCisgICAgICAg ICAgICBicmVhazsNCisgICAgICAgIGNhc2UgQ01EUV9PUF9QUkVGRVRDSF9DRkc6DQorICAgICAg ICBjYXNlIENNRFFfT1BfQ0ZHSV9DRDoNCisgICAgICAgIGNhc2UgQ01EUV9PUF9DRkdJX0NEX0FM TDoNCisgICAgICAgIGNhc2UgQ01EUV9PUF9DRkdJX0FMTDoNCisgICAgICAgIGNhc2UgQ01EUV9P UF9DTURfU1lOQzoNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgQ01EUV9PUF9U TEJJX05IX0FTSUQ6DQorICAgICAgICBjYXNlIENNRFFfT1BfVExCSV9OU05IX0FMTDoNCisgICAg ICAgIGNhc2UgQ01EUV9PUF9UTEJJX05IX1ZBOg0KKyAgICAgICAgICAgIHJldCA9IGlvbW11X2lv dGxiX2ZsdXNoX2FsbChzbW11LT5kLCAxKTsNCisgICAgICAgICAgICBpZiAoICFyZXQgKQ0KKyAg ICAgICAgICAgICAgICBicmVhazsNCisgICAgICAgICAgICBmYWxsdGhyb3VnaDsNCisgICAgICAg IGRlZmF1bHQ6DQorICAgICAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgInZTTU1VdjM6IHVu aGFuZGxlZCBjb21tYW5kXG4iKTsNCisgICAgICAgICAgICBkdW1wX3NtbXVfY29tbWFuZChjb21t YW5kKTsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIH0NCisNCisgICAgICAgIGlmICgg cmV0ICkNCisgICAgICAgIHsNCisgICAgICAgICAgICBnZHByaW50ayhYRU5MT0dfRVJSLA0KKyAg ICAgICAgICAgICAgICAgICAgICJ2U01NVXYzOiBjb21tYW5kIGVycm9yICVkIHdoaWxlIGhhbmRs aW5nIGNvbW1hbmRcbiIsDQorICAgICAgICAgICAgICAgICAgICAgcmV0KTsNCisgICAgICAgICAg ICBkdW1wX3NtbXVfY29tbWFuZChjb21tYW5kKTsNCisgICAgICAgIH0NCisgICAgICAgIHF1ZXVl X2luY19jb25zKHEpOw0KKyAgICB9DQorDQorICAgIHJldHVybiByZXQ7DQogfQ0KIA0KIHN0YXRp YyBpbnQgdnNtbXV2M19tbWlvX3dyaXRlKHN0cnVjdCB2Y3B1ICp2LCBtbWlvX2luZm9fdCAqaW5m bywNCkBAIC0yMjEsNiArMzQ0LDEwIEBAIHN0YXRpYyBpbnQgdnNtbXV2M19tbWlvX3dyaXRlKHN0 cnVjdCB2Y3B1ICp2LCBtbWlvX2luZm9fdCAqaW5mbywNCiAgICAgICAgICAgICByZWczMiA9IHNt bXUtPmNtZHEucHJvZDsNCiAgICAgICAgICAgICB2cmVnX3JlZzMyX3VwZGF0ZSgmcmVnMzIsIHIs IGluZm8pOw0KICAgICAgICAgICAgIHNtbXUtPmNtZHEucHJvZCA9IHJlZzMyOw0KKw0KKyAgICAg ICAgICAgIGlmICggYXJtX3ZzbW11X2hhbmRsZV9jbWRzKHNtbXUpICkNCisgICAgICAgICAgICAg ICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgImVycm9yIGhhbmRsaW5nIHZTTU1VdjMgY29tbWFuZHNc biIpOw0KKw0KICAgICAgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5jbWRfcXVldWVfbG9jayk7 DQogICAgICAgICAgICAgYnJlYWs7DQogDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441825.1659395 (Exim 4.92) (envelope-from ) id 1xEFBY-0001ce-VT; Wed, 07 Oct 2026 00:07:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441825.1659395; Wed, 07 Oct 2026 00: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 1xEFBY-0001cM-OZ; Wed, 07 Oct 2026 00:07:04 +0000 Received: by outflank-mailman (input) for mailman id 1441825; Wed, 07 Oct 2026 00:07:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBW-0001Ge-Et for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBV-00Bv1m-Rr for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:01 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58ced-e002-0a2a0a5209dd-0a2a4502bac0-38 for ; Wed, 07 Oct 2026 02:07:01 +0200 Received: from [40.107.159.126] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d25-6ca4-0a2a45020019-286b9f7e6c75-3 for ; Wed, 07 Oct 2026 02:07:01 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:00 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=ZgtthCFXXDEItba0VKPX9WsWtM2tcZLdf2Pmpmla6LwOsfvzPZUakXb35J9taD8D0emoHEHRZYqwdLrWOcUoQm0sXsgSlrlHCzJ7Yj5j0ipdKNAwBUSNkNqXZ6w3CmorET0qUnVRMYD0rlVTpw2tjF47WphXe6TCgNcUxuLPOHCUN8s41R8MRK4qCSeAMfpiOURo6IR4Q6PJlvrE3UGOF02sgYbHDxIaM/6/yya3AXJ1h5PqCZa48jkskwwP70sKnFrAbrQWJksRWIGmtpVsBORClQHBKeDoQCn4bmn66C1Cwocs8MZrN8JqGnGdC6Q2ZmTh8s2dtLN1CHvTNydLYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vvbG1iCGwJ5eBeKilyoXzLSkIxpeWbybBHX8POsnhdY=; b=EN/kAEYM8xdLHDQPItICsvRvhzQW3jJ8ytIOzcG36Gs7LqombHPee0+ui0XcxkAtPrx9aurBKOV1kzdhBukDwlgqOumTygbyqXWHpkWdCzbJWhefNDt9YgWK9ZUBDEh5N0YwHxSoLV5RRrlx+iazzMxYR53xHZulyMkmo7stLlqMj9JpH0l7VdGOAabtMeiP/SgCX26KyZJdtZA0B2VVPcQFofUaNFpUmwjqRnHOb/Tg0WSJrbAG9wN9+UBQ7pfFQxhX/6xm9dKnP3nRi1Jp/f97E1lrhFHpaoRK35TPgLebjQenkLlUYX6jMFuXqwt1C+5S0ePJ/H69EQfsZAkSoQ== 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=vvbG1iCGwJ5eBeKilyoXzLSkIxpeWbybBHX8POsnhdY=; b=SchcVr7VYvRC425dfLxorkD6TfugecRdeQOpvQU6+ld86Grnsjx5Em2KZkVmrshskCBw64OVYTUTdr094T5VF3vyen1aW7fHMh5w0gcv1LVt+doVzYOmuVkMkRAYa9IYt1UB4Ya7xM2/3/KvVALB7RifKRalLyaEmXeXvUJB3CZuro72m1hbGgewexOOgg8kDF/QrFnIYD87fJITGXxcMqOeuYXbijT6ktsA7k+lmcl4At24I/1fX0BrUdRcjzR2cU54NT5Ela95GrzLHWFxvTK6IDtcX0lOkpgCODQS7Q9SAcTdrtNYKdvdJXG/aqHtKYBZ6dIIM0RK/nY2pSTWFA== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 10/22] xen/arm: vsmmuv3: Add support for command CMD_CFGI_STE Thread-Topic: [PATCH v4 10/22] xen/arm: vsmmuv3: Add support for command CMD_CFGI_STE Thread-Index: AQHdVe/GN7oC5yTKMUuNlB00Lk4TdQ== Date: Wed, 7 Oct 2026 00:06:59 +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: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 135be14f-766d-46c4-9605-08df2406e896 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: Cz52vfgRgdmtLBvJ+FEhyT2poSdis0raZc6Z94gYnrqpgbMh1mUcmoZ1aK7eUhmGjVqnKnShu0duStkMyvmh2wZ6/Lqoez2D0w4xXD90hCXAOwnS3BSOJpYHFJbY49zMCik/ULS1xrr99M3ScFNxnNyWyrW+5g5rXSHHpxtHJg6ezo65DKDk3FsqKQNGBKVdY6idVDVB/KFjEB9/Xh/h2Y0QASE2doE2H2gtjNvakPZfEwhip+ARxhSvdotGDB5Kv33xRJxnoJrnRcV1LKQRgGW3tAVeiOyf9Ak5VZv0oKos1vBm+AYIEuJ1MsalHPzX6ex2XWyrsPcdKhww926N76IQSNkF/4DsUcTL0EWFbqPr1VQ63VKWTwRmzf8dIGbj4Ep+pfmwuyTjmPZKdV9mnaH6wOCE/dqE5Uqgmw011Wb3mGxrpv6tgOBhi7BhMgnZ5axbH34CAjrSviAdET7g0rBlmLnj21aljQ3PaeMHmVmHJIAqo4q4uuAReI9T1VH/UV2MdVBfCkEC4HFYy1U/55jDxPiBE7aLWAuCwY7eDC78/cKZvXMKN2YxMLfUuWbp4VJcy6swRgGFfWzC3pwEX/hcAWCwYwjTkk/Q+9XpOic2xhHuZF4FwduvSiiHGVefR1gkJJ/CA51DlLq0mJC8XzSP/5xGZBqtCuShMY3WlAJ6XRHkx8XSn+pS4i1vsrRut6ZWlueAF7by54K7NaKcXg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QzgxRUVwckFGVUkwdUljYmxQYnNQUnFSMWdwYlRFc2U3eUNXNFNpNXZSUmt1?= =?utf-8?B?cDZuY2JpVzQwZGVnMjNvWnQ5QXhiSElUeHZIQVNnM0VzWjhlWFpsaUV6eSsv?= =?utf-8?B?UzBzNHlKOUcvdktTa2Z6b2Zxbk1MNnYvMlJEczFXSWx6OGVjcnc2NmloYm9L?= =?utf-8?B?dW91SmFMcDJPeTVOTE9zQjJEZCtjTWpOYkJNckhJTGZLbm9nMnJJczBnMmlU?= =?utf-8?B?ZERtZFYxSTh0enh6WElZZE1mZVNCWEtjendrN1FXWk1kU3gwclQ3aENnT29N?= =?utf-8?B?anczZjlYMU43SURzMnpIUFAyZHRvOFJyRkJRai9EQ1BOcGhwR2hxS3NnZW95?= =?utf-8?B?dGU5OExxQ1ZsL2k1aGtmL21BZ3ZZNGY5V0hCdzliTGdRMzNsL1h4L0tabmFn?= =?utf-8?B?bnlkQXA3WUlpSU53WWxHZ0ZwWkZUbElhRGE3NkJ3dSthYkZPTUdsdGNQZUpW?= =?utf-8?B?U1lmYzJocXAxOGxicTdZeEJJRjI2UXNYYnN0TWM5ampzZy96eFltR2NaSVA0?= =?utf-8?B?a2JQVi9GeEZucUcxSjFhd0FHVTNEVUlBZzRnWWswckl3YWQrK3ZUdk14enFR?= =?utf-8?B?N1gzZGI4N1pVK0FoK1ZtR0lTcWZNTmJZc3JWWTRuTWdHWU8vajQ2ZHdxR21r?= =?utf-8?B?b2ROYWNIeE51SDJoUnhWa1hESHJVRDFyYmJ0RWh2UWNRUStDbGdzWkh3clBS?= =?utf-8?B?MGVrNWdJdHJpL2JxVldwYVB2ek5YSTZDRFMxaWQ0alpsdmFQMm02QjZmUzFl?= =?utf-8?B?emNUajJraTRrcDZsa0ZSNmtlRTFUbnB4SEFYY1lQVC9IOXN5eDlsdXR0dGxK?= =?utf-8?B?MWlrR0ZOQ1FQM3M5K1d6bGloU1BPR3NncmM3T1QxVkIyLzRWckhFY0VDVHcr?= =?utf-8?B?QXppMjZ6bGN1NjlteFpnU3lqUElWSWkxZi84WEpPSkRXbHM3QjRKMmhYUzFS?= =?utf-8?B?eXR2YjE3aUpVOEc2NlFaSmtCQzZvUWtVWGxwZW11R1lrTXl0WmxOSnY0UWJ6?= =?utf-8?B?Q1pPTEkraGdzNVovK2pzak5UYmJRYld2Q1d1cGtHQTB3djZPNytvVFlMODBC?= =?utf-8?B?cTNLZkJoY2c4UHZJdTdsdFljKzgyaXVWaEdFMFB3TEdxTnl5WEJsckVXRjdG?= =?utf-8?B?UUc2SEZyMGtzUDdyZ2EvS1hnT3BieDlEWlNnbUoyM1JQdXBiRTB5L2E5ZUdV?= =?utf-8?B?ZVpHS2k4OFN4bERHVE96QWE4N0VQakxoV3l2Y04xRnpHdUJNWDBGZUY3WlFK?= =?utf-8?B?emRDQnF3TVZjY3NLNXl0U0I2cjdnakU0Um12V0J0dEZYcGZlYzlVMnZGV3Bk?= =?utf-8?B?YVBESnB3eEFBZ3B1OGtleWNFcjUyNHBoYTlJQXRzcUtWd2VuRDNPVUVLUHRy?= =?utf-8?B?VjBGVnhUblMrcnJvUFBLSU4yR3ZNWEN4Q3F4MXRMSzlleXd5OXhSWFNaN1Zl?= =?utf-8?B?VExyZmJVM0lQMHczVXVMa3Q2QSs3QVlPVCtLcGJuWGU2cDdqcm56U1VFbnRm?= =?utf-8?B?WDluQk5IcEZHaWJHYzV6cnpscVUydlBzWjRmM3dpSG4yaUZKSXAvZm1aNER4?= =?utf-8?B?KzM3WHVDNW5UYzBOT2dOaHdpUUdoVlY0K2ZHM2ZyYmRJVi9xak1jam1qeEZD?= =?utf-8?B?OCt5bWgxRmJFd1B2aWNUbnZjTU1IOC84U2kxaXhJdzdRL0NUcjRpcWFLcW9t?= =?utf-8?B?NDVaNndJVkpIU1VkNEpTbmw3OVppMS8wNHIwUjVuYUFnVTJnbFJ2Ulc0U0lP?= =?utf-8?B?VEJRdUVHR0hzQ1Q0V081R0JBSkJGQkJoakhac0FEY1d2N1dFYmZhVDJVQXBW?= =?utf-8?B?ZFlOUUo1V1Z2U1c5NE5LVGxXcXUzQXlHYllHL1VFQlV4Z3h5VlQ4c2xnb2NP?= =?utf-8?B?ZzRFbnhhVGUrY28wY2JFWlg5NGl5eUNCa0YxbFNFQlFYaVJzNGR3ZFZhdVB2?= =?utf-8?B?NDVvNk43c2ZqQUFpY1ZZcFJoS2lUb1dxRzdFY0xNaEs0MldWd09ZRFNWQUZo?= =?utf-8?B?azdmS0kyQ05qeERRN1Ztc1Z0cDlQcUR6TUZadjBQdnpGemlxZUNlTVdQYVpI?= =?utf-8?B?WnNGdGZLaWhIbDBONVJuR3VFZTlkM2dmMFA3eUc2S0ExMkNwMlRCcUVBZzhM?= =?utf-8?B?cURPa2FEVU1tTFZlZ0UzTUJ0QUk0aDNKMEk4dFp3NW9zSlQ2TnRsMnhHRWtx?= =?utf-8?B?ckQvazJLTWttLzFCT3ZQZ2VVOUhjcnJ1MzdCYk9kZjRUT2RNZmdaVUw5TERC?= =?utf-8?B?NjFCK3ArcFVHTkJybTU3Y1FZT1lkZlM1cVNBdlJPQkVaQTZWcW83dHNsM3Bi?= =?utf-8?B?WFN5K3lCNks3MEtoMzdXTHRHYVNWNGZ1ZjlRdXJHb3cwTWVlNjBjZz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 135be14f-766d-46c4-9605-08df2406e896 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:06:59.9862 (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: /x4HrDO7ZgklOctIwepJ0bfe6KW4AUl1CMkF97274UvI44Jni3rQBSQxjEjRbP5n4uHqSyk7dJVfiPRggKzCkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-720697/1791331621-F12A12AC-08A7D4BA/0/0 X-purgate-type: clean X-purgate-size: 9828 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkNNRF9DRkdJX1NURSBp cyB1c2VkIHRvIGludmFsaWRhdGUvdmFsaWRhdGUgdGhlIFNURS4gRW11bGF0ZWQgdlNNTVV2Mw0K ZHJpdmVyIGluIFhFTiB3aWxsIHJlYWQgdGhlIFNURSBmcm9tIHRoZSBndWVzdCBtZW1vcnkgc3Bh Y2UgYW5kIGNhcHR1cmUNCnRoZSBTdGFnZS0xIGNvbmZpZ3VyYXRpb24gcmVxdWlyZWQgdG8gc3Vw cG9ydCBuZXN0ZWQgdHJhbnNsYXRpb24uDQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxy YWh1bC5zaW5naEBhcm0uY29tPg0KU2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9k am9raWNAZXBhbS5jb20+DQotLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUt djMuYyB8IDE2OSArKysrKysrKysrKysrKysrKysrKysrKysrDQogMSBmaWxlIGNoYW5nZWQsIDE2 OSBpbnNlcnRpb25zKCspDQoNCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h cm0vdnNtbXUtdjMuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5jDQpp bmRleCAxMDE0MzkyN2U3Li4yNWJhNzM0ZmE3IDEwMDY0NA0KLS0tIGEveGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMNCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Fy bS92c21tdS12My5jDQpAQCAtNzgsNiArNzgsMjEgQEANCiANCiAvKiBIZWxwZXIgTWFjcm9zICov DQogI2RlZmluZSBzbW11X2NtZF9nZXRfY29tbWFuZCh4KSAgICAgRklFTERfR0VUKENNRFFfMF9P UCwgeCkNCisjZGVmaW5lIHNtbXVfY21kX2dldF9zaWQoeCkgICAgICAgICBGSUVMRF9HRVQoQ01E UV9DRkdJXzBfU0lELCB4KQ0KKyNkZWZpbmUgc21tdV9nZXRfc3RlX3MxY2RtYXgoeCkgICAgIEZJ RUxEX0dFVChTVFJUQUJfU1RFXzBfUzFDRE1BWCwgeCkNCisjZGVmaW5lIHNtbXVfZ2V0X3N0ZV9z MWZtdCh4KSAgICAgICBGSUVMRF9HRVQoU1RSVEFCX1NURV8wX1MxRk1ULCB4KQ0KKyNkZWZpbmUg c21tdV9nZXRfc3RlX3Mxc3RhbGxkKHgpICAgIEZJRUxEX0dFVChTVFJUQUJfU1RFXzFfUzFTVEFM TEQsIHgpDQorI2RlZmluZSBzbW11X2dldF9zdGVfczFjdHhwdHIoeCkgICAgRklFTERfUFJFUChT VFJUQUJfU1RFXzBfUzFDVFhQVFJfTUFTSywgXA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEZJRUxEX0dFVChTVFJUQUJfU1RFXzBfUzFDVFhQVFJfTUFTSywgeCkpDQorDQor Lyogc3RhZ2UtMSB0cmFuc2xhdGlvbiBjb25maWd1cmF0aW9uICovDQorc3RydWN0IGFybV92c21t dV9zMV90cmFuc19jZmcgew0KKyAgICBwYWRkcl90IHMxY3R4cHRyOw0KKyAgICB1aW50OF90IHMx Zm10Ow0KKyAgICB1aW50OF90IHMxY2RtYXg7DQorICAgIGJvb2wgICAgYnlwYXNzZWQ7ICAgICAg ICAgICAgIC8qIHRyYW5zbGF0aW9uIGlzIGJ5cGFzc2VkICovDQorICAgIGJvb2wgICAgYWJvcnRl ZDsgICAgICAgICAgICAgIC8qIHRyYW5zbGF0aW9uIGlzIGFib3J0ZWQgKi8NCit9Ow0KIA0KIC8q IHZpcnR1YWwgc21tdSBxdWV1ZSAqLw0KIHN0cnVjdCBhcm1fdnNtbXVfcXVldWUgew0KQEAgLTE2 NSw2ICsxODAsMTU5IEBAIHN0YXRpYyB2b2lkIGR1bXBfc21tdV9jb21tYW5kKHVpbnQ2NF90ICpj b21tYW5kKQ0KICAgICBncHJpbnRrKFhFTkxPR19FUlIsICJjbWQgMHglMDJsbHg6ICUwMTYiUFJJ eDY0IiAlMDE2IlBSSXg2NCJcbiIsDQogICAgICAgICAgICAgIHNtbXVfY21kX2dldF9jb21tYW5k KGNvbW1hbmRbMF0pLCBjb21tYW5kWzBdLCBjb21tYW5kWzFdKTsNCiB9DQorDQorc3RhdGljIGlu dCBhcm1fdnNtbXVfZmluZF9zdGUoc3RydWN0IHZpcnRfc21tdSAqc21tdSwgdWludDMyX3Qgc2lk LA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2NF90ICpzdGUpDQorew0KKyAg ICBwYWRkcl90IGFkZHIsIHN0cnRhYl9iYXNlOw0KKyAgICBzdHJ1Y3QgZG9tYWluICpkID0gc21t dS0+ZDsNCisgICAgdWludDMyX3QgbG9nMnNpemU7DQorICAgIGludCBzdHJ0YWJfc2l6ZV9zaGlm dDsNCisgICAgaW50IHJldDsNCisNCisgICAgc3Bpbl9sb2NrKCZzbW11LT5zdHJ0YWJfY2ZnX2xv Y2spOw0KKyAgICBsb2cyc2l6ZSA9IE1JTihGSUVMRF9HRVQoU1RSVEFCX0JBU0VfQ0ZHX0xPRzJT SVpFLCBzbW11LT5zdHJ0YWJfYmFzZV9jZmcpLA0KKyAgICAgICAgICAgICAgICBTTU1VX0lEUjFf U0lEU0laRSk7DQorICAgIHNwaW5fdW5sb2NrKCZzbW11LT5zdHJ0YWJfY2ZnX2xvY2spOw0KKw0K KyAgICBpZiAoIHNpZCA+PSAoMVUgPDwgbG9nMnNpemUpICkNCisgICAgICAgIHJldHVybiAtRUlO VkFMOw0KKw0KKyAgICBzcGluX2xvY2soJnNtbXUtPnN0cnRhYl9jZmdfbG9jayk7DQorICAgIGlm ICggRklFTERfR0VUKFNUUlRBQl9CQVNFX0NGR19GTVQsIHNtbXUtPnN0cnRhYl9iYXNlX2NmZykg PT0NCisgICAgICAgICBTVFJUQUJfQkFTRV9DRkdfRk1UXzJMVkwgKQ0KKyAgICB7DQorICAgICAg ICBpbnQgaWR4LCBtYXhfbDJfc3RlLCBzcGFuOw0KKyAgICAgICAgcGFkZHJfdCBsMXB0ciwgbDJw dHI7DQorICAgICAgICB1aW50NjRfdCBsMXN0ZDsNCisgICAgICAgIHVpbnQ4X3Qgc2lkX3NwbGl0 ID0gRklFTERfR0VUKFNUUlRBQl9CQVNFX0NGR19TUExJVCwNCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzbW11LT5zdHJ0YWJfYmFzZV9jZmcpOw0KKw0KKyAgICAgICAgLyoNCisgICAg ICAgICogUmVzZXJ2ZWQgU1BMSVQgdmFsdWVzIGJlaGF2ZSBhcyA2IGFjY29yZGluZyB0byB0aGUg YXJjaGl0ZWN0dXJlLg0KKyAgICAgICAgKi8NCisgICAgICAgIGlmICggc2lkX3NwbGl0ICE9IDB4 NiAmJiBzaWRfc3BsaXQgIT0gMHg4ICYmIHNpZF9zcGxpdCAhPSAweEEgKQ0KKyAgICAgICAgew0K KyAgICAgICAgICAgIHNpZF9zcGxpdCA9IDB4NjsNCisgICAgICAgIH0NCisNCisgICAgICAgIHN0 cnRhYl9zaXplX3NoaWZ0ID0gTUFYKDUsIChpbnQpbG9nMnNpemUgLSBzaWRfc3BsaXQgLSAxICsg Myk7DQorICAgICAgICBzdHJ0YWJfYmFzZSA9IHNtbXUtPnN0cnRhYl9iYXNlICYgU1RSVEFCX0JB U0VfQUREUl9NQVNLICYNCisgICAgICAgICAgICAgICAgICAgICAgICB+R0VOTUFTS19VTEwoc3Ry dGFiX3NpemVfc2hpZnQsIDApOw0KKyAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPnN0cnRhYl9j ZmdfbG9jayk7DQorICAgICAgICBpZHggPSAoc2lkID4+IHNpZF9zcGxpdCkgKiBTVFJUQUJfTDFf REVTQ19EV09SRFM7DQorICAgICAgICBsMXB0ciA9IChwYWRkcl90KShzdHJ0YWJfYmFzZSArIGlk eCAqIHNpemVvZihsMXN0ZCkpOw0KKw0KKyAgICAgICAgcmV0ID0gYWNjZXNzX2d1ZXN0X21lbW9y eV9ieV9ncGEoZCwgbDFwdHIsICZsMXN0ZCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNpemVvZihsMXN0ZCksIGZhbHNlKTsNCisgICAgICAgIGlmICggcmV0ICkN CisgICAgICAgIHsNCisgICAgICAgICAgICBnZHByaW50ayhYRU5MT0dfRVJSLA0KKyAgICAgICAg ICAgICAgICAgICAgICJDb3VsZCBub3QgcmVhZCBMMVBUUiBhdCAwWCUiUFJJeDY0IlxuIiwgbDFw dHIpOw0KKyAgICAgICAgICAgIHJldHVybiByZXQ7DQorICAgICAgICB9DQorDQorICAgICAgICBz cGFuID0gRklFTERfR0VUKFNUUlRBQl9MMV9ERVNDX1NQQU4sIGwxc3RkKTsNCisNCisgICAgICAg IC8qIFZhbGlkYXRlIFNQQU4gYWdhaW5zdCB0aGUgYXJjaGl0ZWN0dXJhbGx5IGRlZmluZWQgcmFu Z2UgYW5kIFNQTElULiAqLw0KKyAgICAgICAgaWYgKCAhc3BhbiB8fCBzcGFuID4gMHhCIHx8IHNw YW4gPiBzaWRfc3BsaXQgKyAxICkNCisgICAgICAgIHsNCisgICAgICAgICAgICAvKiBMMlB0ciBp cyBpbnZhbGlkOyB0aGlzIGRlc2NyaXB0b3IgbWF0Y2hlcyBubyB2YWxpZCBTVEVzLiAqLw0KKyAg ICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgbWF4X2wy X3N0ZSA9ICgxVSA8PCAoc3BhbiAtIDEpKSAtIDE7DQorICAgICAgICBsMnB0ciA9IEZJRUxEX1BS RVAoU1RSVEFCX0wxX0RFU0NfTDJQVFJfTUFTSywNCisgICAgICAgICAgICAgICAgICAgIEZJRUxE X0dFVChTVFJUQUJfTDFfREVTQ19MMlBUUl9NQVNLLCBsMXN0ZCkpOw0KKyAgICAgICAgaWR4ID0g c2lkICYgKCgxIDw8IHNpZF9zcGxpdCkgLSAxKTsNCisgICAgICAgIGlmICggaWR4ID4gbWF4X2wy X3N0ZSApDQorICAgICAgICB7DQorICAgICAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgImlk eD0lZCA+IG1heF9sMl9zdGU9JWRcbiIsDQorICAgICAgICAgICAgICAgICAgICAgaWR4LCBtYXhf bDJfc3RlKTsNCisgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisgICAgICAgIH0NCisgICAg ICAgIGFkZHIgPSBsMnB0ciArIGlkeCAqIHNpemVvZigqc3RlKSAqIFNUUlRBQl9TVEVfRFdPUkRT Ow0KKyAgICB9DQorICAgIGVsc2UNCisgICAgew0KKyAgICAgICAgc3RydGFiX3NpemVfc2hpZnQg PSBsb2cyc2l6ZSArIDU7DQorICAgICAgICBzdHJ0YWJfYmFzZSA9IHNtbXUtPnN0cnRhYl9iYXNl ICYgU1RSVEFCX0JBU0VfQUREUl9NQVNLICYNCisgICAgICAgICAgICAgICAgICAgICAgfkdFTk1B U0tfVUxMKHN0cnRhYl9zaXplX3NoaWZ0LCAwKTsNCisgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11 LT5zdHJ0YWJfY2ZnX2xvY2spOw0KKyAgICAgICAgYWRkciA9IHN0cnRhYl9iYXNlICsgc2lkICog c2l6ZW9mKCpzdGUpICogU1RSVEFCX1NURV9EV09SRFM7DQorICAgIH0NCisgICAgcmV0ID0gYWNj ZXNzX2d1ZXN0X21lbW9yeV9ieV9ncGEoZCwgYWRkciwgc3RlLCBzaXplb2YoKnN0ZSksIGZhbHNl KTsNCisgICAgaWYgKCByZXQgKQ0KKyAgICB7DQorICAgICAgICBnZHByaW50ayhYRU5MT0dfRVJS LA0KKyAgICAgICAgICAgICAgICAiQ2Fubm90IGZldGNoIHB0ZSBhdCBhZGRyZXNzPTB4JSJQUkl4 NjQiXG4iLCBhZGRyKTsNCisgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKyAgICB9DQorDQorICAg IHJldHVybiAwOw0KK30NCisNCitzdGF0aWMgaW50IGFybV92c21tdV9kZWNvZGVfc3RlKHN0cnVj dCB2aXJ0X3NtbXUgKnNtbXUsIHVpbnQzMl90IHNpZCwNCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN0cnVjdCBhcm1fdnNtbXVfczFfdHJhbnNfY2ZnICpjZmcsDQorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB1aW50NjRfdCAqc3RlKQ0KK3sNCisgICAgdWludDY0X3Qg dmFsID0gc3RlWzBdOw0KKw0KKyAgICBpZiAoICEodmFsICYgU1RSVEFCX1NURV8wX1YpICkNCisg ICAgICAgIHJldHVybiAtRUFHQUlOOw0KKw0KKyAgICBzd2l0Y2ggKCBGSUVMRF9HRVQoU1RSVEFC X1NURV8wX0NGRywgdmFsKSApDQorICAgIHsNCisgICAgY2FzZSBTVFJUQUJfU1RFXzBfQ0ZHX0JZ UEFTUzoNCisgICAgICAgIGNmZy0+YnlwYXNzZWQgPSB0cnVlOw0KKyAgICAgICAgcmV0dXJuIDA7 DQorICAgIGNhc2UgU1RSVEFCX1NURV8wX0NGR19BQk9SVDoNCisgICAgICAgIGNmZy0+YWJvcnRl ZCA9IHRydWU7DQorICAgICAgICByZXR1cm4gMDsNCisgICAgY2FzZSBTVFJUQUJfU1RFXzBfQ0ZH X1MxX1RSQU5TOg0KKyAgICAgICAgYnJlYWs7DQorICAgIGNhc2UgU1RSVEFCX1NURV8wX0NGR19T Ml9UUkFOUzoNCisgICAgICAgIGdkcHJpbnRrKFhFTkxPR19FUlIsICJ2U01NVXYzIGRvZXMgbm90 IHN1cHBvcnQgc3RhZ2UgMiB5ZXRcbiIpOw0KKyAgICAgICAgZ290byBiYWRfc3RlOw0KKyAgICBk ZWZhdWx0Og0KKyAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgIkludmFsaWQgU1RFIGNvbmZp ZyB0eXBlXG4iKTsNCisgICAgICAgIGdvdG8gYmFkX3N0ZTsNCisgICAgfQ0KKw0KKyAgICBjZmct PnMxY3R4cHRyID0gc21tdV9nZXRfc3RlX3MxY3R4cHRyKHZhbCk7DQorICAgIGNmZy0+czFmbXQg PSBzbW11X2dldF9zdGVfczFmbXQodmFsKTsNCisgICAgY2ZnLT5zMWNkbWF4ID0gc21tdV9nZXRf c3RlX3MxY2RtYXgodmFsKTsNCisgICAgaWYgKCBjZmctPnMxY2RtYXggIT0gMCApDQorICAgIHsN CisgICAgICAgIGdkcHJpbnRrKFhFTkxPR19FUlIsDQorICAgICAgICAgICAgICAgICAidlNNTVV2 MyBkb2VzIG5vdCBzdXBwb3J0IG11bHRpcGxlIGNvbnRleHQgZGVzY3JpcHRvcnNcbiIpOw0KKyAg ICAgICAgZ290byBiYWRfc3RlOw0KKyAgICB9DQorDQorICAgIHJldHVybiAwOw0KKw0KKyBiYWRf c3RlOg0KKyAgICByZXR1cm4gLUVJTlZBTDsNCit9DQorDQorc3RhdGljIGludCBhcm1fdnNtbXVf aGFuZGxlX2NmZ2lfc3RlKHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXUsIHVpbnQ2NF90ICpjbWRwdHIp DQorew0KKyAgICBpbnQgcmV0Ow0KKyAgICB1aW50NjRfdCBzdGVbU1RSVEFCX1NURV9EV09SRFNd Ow0KKyAgICBzdHJ1Y3QgYXJtX3ZzbW11X3MxX3RyYW5zX2NmZyBzMV9jZmcgPSB7MH07DQorICAg IHVpbnQzMl90IHNpZCA9IHNtbXVfY21kX2dldF9zaWQoY21kcHRyWzBdKTsNCisNCisgICAgcmV0 ID0gYXJtX3ZzbW11X2ZpbmRfc3RlKHNtbXUsIHNpZCwgc3RlKTsNCisgICAgaWYgKCByZXQgKQ0K KyAgICAgICAgcmV0dXJuIHJldDsNCisNCisgICAgcmV0ID0gYXJtX3ZzbW11X2RlY29kZV9zdGUo c21tdSwgc2lkLCAmczFfY2ZnLCBzdGUpOw0KKyAgICBpZiAoIHJldCApDQorICAgICAgICByZXR1 cm4gKHJldCA9PSAtRUFHQUlOICkgPyAwIDogcmV0Ow0KKw0KKyAgICByZXR1cm4gMDsNCit9DQor DQogc3RhdGljIGludCBhcm1fdnNtbXVfaGFuZGxlX2NtZHMoc3RydWN0IHZpcnRfc21tdSAqc21t dSkNCiB7DQogICAgIHN0cnVjdCBhcm1fdnNtbXVfcXVldWUgKnEgPSAmc21tdS0+Y21kcTsNCkBA IC0xOTEsNiArMzU5LDcgQEAgc3RhdGljIGludCBhcm1fdnNtbXVfaGFuZGxlX2NtZHMoc3RydWN0 IHZpcnRfc21tdSAqc21tdSkNCiAgICAgICAgIHN3aXRjaCAoIHNtbXVfY21kX2dldF9jb21tYW5k KGNvbW1hbmRbMF0pICkNCiAgICAgICAgIHsNCiAgICAgICAgIGNhc2UgQ01EUV9PUF9DRkdJX1NU RToNCisgICAgICAgICAgICByZXQgPSBhcm1fdnNtbXVfaGFuZGxlX2NmZ2lfc3RlKHNtbXUsIGNv bW1hbmQpOw0KICAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICAgY2FzZSBDTURRX09QX1BSRUZF VENIX0NGRzoNCiAgICAgICAgIGNhc2UgQ01EUV9PUF9DRkdJX0NEOg0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441828.1659401 (Exim 4.92) (envelope-from ) id 1xEFBZ-0001ib-Kc; Wed, 07 Oct 2026 00:07:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441828.1659401; Wed, 07 Oct 2026 00: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 1xEFBZ-0001hZ-A8; Wed, 07 Oct 2026 00:07:05 +0000 Received: by outflank-mailman (input) for mailman id 1441828; Wed, 07 Oct 2026 00:07:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBX-0001Tp-N8 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBX-007OBc-3Z for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:03 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d27-bab6-0a2a0a5309dd-0a2a450ae05a-0 for ; Wed, 07 Oct 2026 02:07:03 +0200 Received: from [40.107.159.91] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d26-f2d2-0a2a450a0019-286b9f5b0c7c-3 for ; Wed, 07 Oct 2026 02:07:02 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:01 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00: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" 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=uhbJoo0gxAESajMZDX0MB7SaxQ3nliIcTQjrbgmSqxB30sON3k4ZN16X3PGvVUQT8Fl7HoikLxeIwjyMp/fgehPQkaPC0F4Lt3ys2EqIVtc6ldlU8otoW09k/ax7lDYa2ZovYtxmqOKEq+5jGxPssFwFnEO+UPjWn1jd8vRK72mkAU731/eg5t5S516t2jzP4BsvawBeMr/vDGH5wEUnP3D/cVLMszo0z4qEBhWHePQVps/8XF+WvmAp84HsG6oA4zDeb2BP86tL/RwzSL299exPxW43doc+UJwDsga2jYg4KGIWiU8ac/SbVZbaII6P7f44j680U2UcrzmB4QtAcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BJZhOYO/spnMKOUCuPxsUy48q3NWnY8yYHp9V6hOcq0=; b=FnyDe64N/CYk0bIWOiUcWl1CxBLvGQyu04TM2dTabmTVHCzZ0zV323GA9diLAbBT4XnSS9oPe8gyF63r7+bH5VxzyLlETnaRlZTPgMy1PHleLoEgBqcp5nQ0ieOpb4LDQI4+bD50LwtPbRoCK9UN8Pc5GxwsvCnbAUEZbxMIM087N0Yo8ufFoFwrfPfT51MVriJC50ufFQ3OMgeuJAnsQU3gTIAreVITgVM2Pwac/Y8BE7KjgAdlBJQE+XXrBZUmmcMcRT0knq/6tmSKF0SrutGPUFKgG/ku5Fpmf2L+OJ7oM4bC+wVryaQ+RuzMo7U8bhweRuwO0chRhItkLNEYKA== 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=BJZhOYO/spnMKOUCuPxsUy48q3NWnY8yYHp9V6hOcq0=; b=PadQX5lIYBQWbk7cbUymEhud+BxAoNSiMYr7+z+RkA8SVUlkzG8v629LRvtQBd0FzA0YktsQEa70X1b8g+n8xhNCTnryque+JnUIa+dce82BmBQ3YwJqTd6VcuKUk+VCvLUK5ENa1GYuKpSiRJCo2X4mNnt84jYsv1kBxchuy7kUlVXBvT0ajfccAmM/fs//3Jh1+TVpuGqJhmd8ICk5jEs7QPsW9RZNsp0VSq7fsGqLlJ7SezuZJVIZU6utoZjK3OKi6s4oJ2I8z5Z/x7gUtHfPOxq4ky/0H3ZY566aG8S+fwyD4QWRUlZLuoQdZx7mCz8nnPS2ATsImRiYktn0gg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Milan Djokic Subject: [PATCH v4 11/22] xen/arm: vsmmuv3: Attach Stage-1 configuration to SMMUv3 hardware Thread-Topic: [PATCH v4 11/22] xen/arm: vsmmuv3: Attach Stage-1 configuration to SMMUv3 hardware Thread-Index: AQHdVe/G0gcm0UOBVUqDKAmSpa1s4A== Date: Wed, 7 Oct 2026 00:07:01 +0000 Message-ID: <4f83a0ee7f46e19c6afec3460a2a7e1bbe8e3c1a.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 894c9770-4071-44c7-b48e-08df2406e957 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: GhY3QFWrBaR6mDS/KSVQmNXqOHuCsRKIoDf5Xr14WWkNXNDVKFgQmdf7pvogmDCFAYgJ7gaeEgM0t4IedWAXg3QYpfLAcaH2ejHU76GxnCX4PmN5GYi61xyEDPUzhxe8RPKO2DvxPJHwEX195iei9uQDjhBZed6KzTgzWGXGsgi9hnNFKJgz6TEOFkeyZ/ugfysA5TKcQzI9tVUESpHnIY5UnfambAa+q3M+rILAPXuc8OCPOIqI/IXA4hoH4JbxoH22VVS2oUKedsBEBh1OBfaPlZWvskJE4pH1KEueydRjnUe9NXHxekcxtKueSuWf2rU8JJwfQH0ySRzcL8Oyb4UV+uGcBQE0QKvAk/OmDbqFw89fHp/mp0TtILOwt7I6uA8qQI9cYAoZFQtf4cYVPEuImstJPhFqD/qdO6uby5f8LS8EKxAwnHGY6+2GZzR+2ISA8e49f90xHvpV3xSl+eSh+VPeFtIbpjy/A2f86lyINYhgbHBzRzHu6JfcwxbqP1z4Zy7D4EIbNu89WVRkyGDBj7ujAfMcSjW9EL+HAz6IrqI6VFwqGqmVlFkWJ0IzZ0ZpKUZ6XXK6pbcmW2qGkIp8O/4HPUEXlOM8+KTmZ3OgLxf6mojBLPPQJT3twdTYyRblAcywCqiQXd1zefjwwLhY1gWdVliPcS0OLmwZ6Hgt+RfPiYi2ZHVxL0VfKiEYIb13GR4+NrmXMUCOhoBIse6xA6J2n0HL6J0b7QkhTQg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZTBaYldYblRDU1Vna3BBc0ZRenRzZUdyb0gxVzZKV0Q2K0lrbzN3M2tPcFNj?= =?utf-8?B?alBsb1owbFFub0J1TG5uWVd4Wnhheno1YmxQbWM3MEJMRlBocXlyTHowUHdt?= =?utf-8?B?STlqaEpIYkpzK2lnRUErbkZscFBYRUtnZ0VpSWVtOGh4Qnk4ZmNCbzZUdkh2?= =?utf-8?B?K2FrL3lUSng0SGpyZVo1QkpIMVlqS0VkTmdpc1lrSHlqQlM1amJuTU53enc3?= =?utf-8?B?TW1tcTdpa29zT25OMzlZdWNIblp4K1hDeUFVKzcwb3c3Z0ZhZEMxUE9WanU0?= =?utf-8?B?RnluY0R6b1FQdlNxeDdqc21NY1F1WitjY1c0RW93Wm9LSFB0VjlidzV0QkNJ?= =?utf-8?B?aWc5a2xCUnQyb2tQajArQXZCTHR2dkdaa2dGa1hOV1QyNm1weitpQkNNVkFB?= =?utf-8?B?OHNxQWVZVFRxY1U5Vnh0OGo2NGVRYVdNNzJGaThvR1Vnb1dzSWIvNDEydzFa?= =?utf-8?B?WGR1dFkvdzhoU09BZTVDNW9vY1R1b1Y5YjF1cllMR05xemF0RWdOa25acjhB?= =?utf-8?B?Q1dFYVIvRjVnK25aKzJqTUJJeU1FVjd6dGpkRmZnR2VGRnRZMG5Xcm93bWRw?= =?utf-8?B?bHUzM1NDTlgrTVVMY0NHcUE5Y2VVbWFKNDg5YVl0OTl2cnA4bkptNzMyVjlT?= =?utf-8?B?T0YzNFZoZzUza0VIQllwR3prZmhsMENLdDZXcmN5ZTBBcTljK0JHMldGZXg1?= =?utf-8?B?Y24zL1czdWdnTXN0Tis1Z1k0cStmZ2FsaXZ2MzdGNXhVQWVKekhFQlExdEZp?= =?utf-8?B?Y1BNMkRkWC9iaklhbHBoL1U1ekVEYXFKWExjNEFzVjRldzRZRVFmVTk5T0tu?= =?utf-8?B?bVlhVHR6RHFISnFYM2dLU2w1T2hoVFB0aTVCSVZyRy9tTzhqY0VpbUxNeTZ5?= =?utf-8?B?aWQzRmZpUDZjUlVudUFNM1FvU3NFWDVqT1dGdHowenR3QjF2Qjk1Z0dwMndp?= =?utf-8?B?R1NucEJLZ2ExWW5qYllOUWV2L3JPcWFHUjV3NVFyWUN0aW83QXJYdkFkVkJI?= =?utf-8?B?Wk5kMjdKcnRyamhpOTlBbWVLMVVkQXRDdTkwdGRhbFpJM2RESkw1VFUvMTE3?= =?utf-8?B?REZkYmM5Z1BRcXNnR0pJSDhDeFJ4d0o2WndGU3JBdlgxZjFwQWVDR0hyTWV4?= =?utf-8?B?ci81YVJ4dml3L1NCNldOYVdHRHJXdkdzUDBQRG5LbEVrQlJKY29ITTJaVGo1?= =?utf-8?B?aXQxNm5NKzlIVXZrQ3BJVWVRd2pTOFpGZmpLVmVXQ0RpOXFqaE5HZ1hvWkNF?= =?utf-8?B?RDUyenBHLzlaUUlNdGRhem02Y1VDdkY5NTJ6Rk1DWTBkTGhudmF5cVFNZ3BX?= =?utf-8?B?L3ZLZjd0T3ZSQzdTZytUNlR0Sjl5YVFRcmJZdEhpYmpGa3Erdk5vaUVzU0Yr?= =?utf-8?B?RVhUaDcyNVViQkNvMHdUNXdyNzdtZTd5QzF5Ymk0WjJGWXdhREdzOTFCOUc0?= =?utf-8?B?WDlsc2h1MzFFSTZaY2pwRi85dm8wVUdlcDdaVi82SG52NlZUMDIzVzVsYkZX?= =?utf-8?B?US9TY2xtK0FKaGVuVTgzb0JVaDBFNnRNTjloUXJCYjFvQjVRZFY2amFOa0o2?= =?utf-8?B?eE5NRFJGZ3RXdXpwSy91cmVoRFRVWGxSUlVHU0VJTjZ5YS9zKytJblJVV0ZH?= =?utf-8?B?a3ZsM2ZJQW5VSkUxemJpV1ZYZXVoOWltV3FKTVdBVWsxNWt4ZGd3cU5SQkFy?= =?utf-8?B?Z3JwUW8yOC9WajVkVDlzdnpCblhjV0FBbzNpYlgrTFUvRWswalQzZkNHaDg5?= =?utf-8?B?cTVXRTgveXJFT01QZkcxcnpqMm16S2p0c0pWVU9UUlUyWkhwcGh3dU5qOUtz?= =?utf-8?B?RWovUElwTjZmOGJCbnJhRE5PZHNTQVY5bGRsUXFTb0U4cVVaQWdua3NhdVRq?= =?utf-8?B?QUNjUnYyZm1XSDJXcW00Vm5zVFczd0RGME9HSzQ3cXRobitxM0gzS2ppTGtq?= =?utf-8?B?VHlOcHJVQi93Mi9Ba2VVTjNMQXhlMjgxbzUxQVlpSTkrcnl0MmJMRTlzaElO?= =?utf-8?B?U0NTL0R5eG1DMUVOTFJsL0twY1RTd2dxTWtDYzBjdXJrY0ZmNXdsMWRzbHpT?= =?utf-8?B?Tm53cGZFZndJM1I3WUMzN1pRU1BtVnV0NkpieFdGTzJuUFhpSHdLR1JhOEVJ?= =?utf-8?B?QVFZUHNDdUg5RkFudVhsUjJWU2RkbksxenUyM3NCVjdNWHZnR3JEdGF0dEp6?= =?utf-8?B?bmdZRm5GQnRKL0xLSWV2MlNVZVZPRURKaDBCaHJMYzVoMWQ5TTNnaE03bHJH?= =?utf-8?B?WTlLTG9ZUGRSUjFFOVNKT2xaWmlmVDExZTB0cmRIb2wrZ2pmZzlRY1ludlpY?= =?utf-8?B?NW1BY1Eya0o0UnBtQThXYUZZMTF3cW9GNmE3OTZwV2F1c3ovNTFLZz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 894c9770-4071-44c7-b48e-08df2406e957 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:01.2796 (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: Fi1YcXLW9V1Uawx5/3yuzNGZHgSswtqpciIyzGY24euakMvQ5ObA4QNp0H/yhJJZFFNuX/cR1v0OCgfa315MRw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-4011c0/1791331623-4AEDACFC-27C2A0ED/0/0 X-purgate-type: clean X-purgate-size: 10678 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkF0dGFjaCB0aGUgU3Rh Z2UtMSBjb25maWd1cmF0aW9uIHRvIGRldmljZSBTVEUgdG8gc3VwcG9ydCBuZXN0ZWQNCnRyYW5z bGF0aW9uIGZvciB0aGUgZ3Vlc3RzLg0KDQpTaWduZWQtb2ZmLWJ5OiBSYWh1bCBTaW5naCA8cmFo dWwuc2luZ2hAYXJtLmNvbT4NClNpZ25lZC1vZmYtYnk6IE1pbGFuIERqb2tpYyA8bWlsYW5fZGpv a2ljQGVwYW0uY29tPg0KLS0tDQogeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lvbW11LmggICAg ICAgfCAgIDcgKysNCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jICB8IDEw NSArKysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJt L3NtbXUtdjMuaCAgfCAgIDEgKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12 My5jIHwgIDE4ICsrKysrDQogeGVuL2luY2x1ZGUveGVuL2lvbW11LmggICAgICAgICAgICAgICAg fCAgIDYgKysNCiA1IGZpbGVzIGNoYW5nZWQsIDEzNyBpbnNlcnRpb25zKCspDQoNCmRpZmYgLS1n aXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vaW9tbXUuaCBiL3hlbi9hcmNoL2FybS9pbmNs dWRlL2FzbS9pb21tdS5oDQppbmRleCBhZDE1NDc3ZTI0Li41NmJjOTMxNGE3IDEwMDY0NA0KLS0t IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2lvbW11LmgNCisrKyBiL3hlbi9hcmNoL2FybS9p bmNsdWRlL2FzbS9pb21tdS5oDQpAQCAtMjAsNiArMjAsMTMgQEAgc3RydWN0IGFyY2hfaW9tbXUN CiAgICAgdm9pZCAqcHJpdjsNCiB9Ow0KIA0KK3N0cnVjdCBpb21tdV9ndWVzdF9jb25maWcgew0K KyAgICBwYWRkcl90ICAgICBzMWN0eHB0cjsNCisgICAgdWludDhfdCAgICAgY29uZmlnOw0KKyAg ICB1aW50OF90ICAgICBzMWZtdDsNCisgICAgdWludDhfdCAgICAgczFjZG1heDsNCit9Ow0KKw0K IGNvbnN0IHN0cnVjdCBpb21tdV9vcHMgKmlvbW11X2dldF9vcHModm9pZCk7DQogdm9pZCBpb21t dV9zZXRfb3BzKGNvbnN0IHN0cnVjdCBpb21tdV9vcHMgKm9wcyk7DQogDQpkaWZmIC0tZ2l0IGEv eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0 aHJvdWdoL2FybS9zbW11LXYzLmMNCmluZGV4IDlkMmI4YTcwOGIuLjE5NmFjNjYwZWYgMTAwNjQ0 DQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jDQorKysgYi94ZW4v ZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jDQpAQCAtMzAwMyw2ICszMDAzLDM3IEBA IHN0YXRpYyBzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICphcm1fc21tdV9nZXRfYnlfZGV2KGNvbnN0 IHN0cnVjdCBkZXZpY2UgKmRldikNCiAJcmV0dXJuIE5VTEw7DQogfQ0KIA0KK3N0YXRpYyBzdHJ1 Y3QgaW9tbXVfZG9tYWluICphcm1fc21tdV9nZXRfZG9tYWluX2J5X3NpZChzdHJ1Y3QgZG9tYWlu ICpkLA0KKwkJCQl1MzIgc2lkKQ0KK3sNCisJaW50IGk7DQorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7 DQorCXN0cnVjdCBpb21tdV9kb21haW4gKmlvX2RvbWFpbjsNCisJc3RydWN0IGFybV9zbW11X2Rv bWFpbiAqc21tdV9kb21haW47DQorCXN0cnVjdCBhcm1fc21tdV9tYXN0ZXIgKm1hc3RlcjsNCisJ c3RydWN0IGFybV9zbW11X3hlbl9kb21haW4gKnhlbl9kb21haW4gPSBkb21faW9tbXUoZCktPmFy Y2gucHJpdjsNCisNCisJLyoNCisJICogTG9vcCB0aHJvdWdoIHRoZSAmeGVuX2RvbWFpbi0+Y29u dGV4dHMgdG8gbG9jYXRlIGEgY29udGV4dA0KKwkgKiBhc3NvY2lhdGVkIHdpdGggdGhlIHRhcmdl dCBTTU1VIGFuZCBkZXZpY2UgU0lEDQorCSAqLw0KKwlsaXN0X2Zvcl9lYWNoX2VudHJ5KGlvX2Rv bWFpbiwgJnhlbl9kb21haW4tPmNvbnRleHRzLCBsaXN0KSB7DQorCQlzbW11X2RvbWFpbiA9IHRv X3NtbXVfZG9tYWluKGlvX2RvbWFpbik7DQorDQorCQlzcGluX2xvY2tfaXJxc2F2ZSgmc21tdV9k b21haW4tPmRldmljZXNfbG9jaywgZmxhZ3MpOw0KKwkJbGlzdF9mb3JfZWFjaF9lbnRyeShtYXN0 ZXIsICZzbW11X2RvbWFpbi0+ZGV2aWNlcywgZG9tYWluX2hlYWQpIHsNCisJCQlmb3IgKGkgPSAw OyBpIDwgbWFzdGVyLT5udW1fc3RyZWFtczsgaSsrKSB7DQorCQkJCWlmIChzaWQgIT0gbWFzdGVy LT5zdHJlYW1zW2ldLmlkKQ0KKwkJCQkJY29udGludWU7DQorCQkJCXNwaW5fdW5sb2NrX2lycXJl c3RvcmUoJnNtbXVfZG9tYWluLT5kZXZpY2VzX2xvY2ssIGZsYWdzKTsNCisJCQkJcmV0dXJuIGlv X2RvbWFpbjsNCisJCQl9DQorCQl9DQorCQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZzbW11X2Rv bWFpbi0+ZGV2aWNlc19sb2NrLCBmbGFncyk7DQorCX0NCisJcmV0dXJuIE5VTEw7DQorfQ0KKw0K IHN0YXRpYyBzdHJ1Y3QgaW9tbXVfZG9tYWluICphcm1fc21tdV9nZXRfZG9tYWluKHN0cnVjdCBk b21haW4gKmQsDQogCQkJCXN0cnVjdCBkZXZpY2UgKmRldikNCiB7DQpAQCAtMzIxNiw2ICszMjQ3 LDc5IEBAIHN0YXRpYyB2b2lkIGFybV9zbW11X2lvbW11X3hlbl9kb21haW5fdGVhcmRvd24oc3Ry dWN0IGRvbWFpbiAqZCkNCiAJeGZyZWUoeGVuX2RvbWFpbik7DQogfQ0KIA0KK3N0YXRpYyBpbnQg YXJtX3NtbXVfYXR0YWNoX2d1ZXN0X2NvbmZpZyhzdHJ1Y3QgZG9tYWluICpkLCB1aW50MzJfdCBz aWQsDQorCQljb25zdCBzdHJ1Y3QgaW9tbXVfZ3Vlc3RfY29uZmlnICpjZmcpDQorew0KKwlpbnQg cmV0ID0gLUVJTlZBTDsNCisJdW5zaWduZWQgbG9uZyBmbGFnczsNCisJc3RydWN0IGFybV9zbW11 X21hc3RlciAqbWFzdGVyOw0KKwlzdHJ1Y3QgYXJtX3NtbXVfZG9tYWluICpzbW11X2RvbWFpbjsN CisJc3RydWN0IGFybV9zbW11X3hlbl9kb21haW4gKnhlbl9kb21haW4gPSBkb21faW9tbXUoZCkt PmFyY2gucHJpdjsNCisJc3RydWN0IGlvbW11X2RvbWFpbiAqaW9fZG9tYWluID0gYXJtX3NtbXVf Z2V0X2RvbWFpbl9ieV9zaWQoZCwgc2lkKTsNCisNCisJaWYgKCFpb19kb21haW4pDQorCQlyZXR1 cm4gLUVOT0RFVjsNCisNCisJc21tdV9kb21haW4gPSB0b19zbW11X2RvbWFpbihpb19kb21haW4p Ow0KKw0KKwlzcGluX2xvY2soJnhlbl9kb21haW4tPmxvY2spOw0KKw0KKwlzd2l0Y2ggKGNmZy0+ Y29uZmlnKSB7DQorCWNhc2UgQVJNX1NNTVVfRE9NQUlOX0FCT1JUOg0KKwkJc21tdV9kb21haW4t PmFib3J0ID0gdHJ1ZTsNCisJCXNtbXVfZG9tYWluLT5zdGFnZSA9IGNmZy0+Y29uZmlnOw0KKwkJ YnJlYWs7DQorCWNhc2UgQVJNX1NNTVVfRE9NQUlOX0JZUEFTUzoNCisJCXNtbXVfZG9tYWluLT5h Ym9ydCA9IGZhbHNlOw0KKwkJc21tdV9kb21haW4tPnN0YWdlID0gY2ZnLT5jb25maWc7DQorCQli cmVhazsNCisJY2FzZSBBUk1fU01NVV9ET01BSU5fUzE6DQorCQkvKiBDaGVjayBzdGFnZS0xIHN1 cHBvcnQgKi8NCisJCWlmICghKHNtbXVfZG9tYWluLT5zbW11LT5mZWF0dXJlcyAmIEFSTV9TTU1V X0ZFQVRfVFJBTlNfUzEpKSB7DQorCQkJZGV2X2luZm8oc21tdV9kb21haW4tPnNtbXUtPmRldiwN CisJCQkJCSJzdGFnZS0xIG5vdCBpbXBsZW1lbnRlZFxuIik7DQorCQkJZ290byBvdXQ7DQorCQl9 DQorDQorCQkvKiBJZiBzdGFnZS0yIGlzIG5vdCBzdXBwb3J0ZWQsIGNvbmZpZ3VyZSBzdGFnZS0x IG9ubHkgKi8NCisJCWlmICghKHNtbXVfZG9tYWluLT5zbW11LT5mZWF0dXJlcyAmIEFSTV9TTU1V X0ZFQVRfVFJBTlNfUzIpKSB7DQorCQkJCWRldl93YXJuKHNtbXVfZG9tYWluLT5zbW11LT5kZXYs DQorCQkJCQkJIlNNTVUgZG9lcyBub3QgaW1wbGVtZW50IHN0YWdlLTIgdHJhbnNsYXRpb24gc3Vw cG9ydC4gIg0KKwkJCQkJCSJGYWxsYmFjayB0byBzdGFnZS0xLW9ubHkgdHJhbnNsYXRpb24gY29u ZmlndXJhdGlvblxuIik7DQorCQkJLyogRW5hYmxlIFN0YWdlLTEgdHJhbnNsYXRpb24uICovDQor CQkJc21tdV9kb21haW4tPnN0YWdlID0gQVJNX1NNTVVfRE9NQUlOX1MxOw0KKwkJfQ0KKwkJZWxz ZSB7DQorCQkJLyogQ2hlY2sgbmVzdGVkIHN1cHBvcnQgKi8NCisJCQlpZiAoIShzbW11X2RvbWFp bi0+c21tdS0+ZmVhdHVyZXMgJiBBUk1fU01NVV9GRUFUX05FU1RJTkcpKSB7DQorCQkJCQlkZXZf aW5mbyhzbW11X2RvbWFpbi0+c21tdS0+ZGV2LA0KKwkJCQkJCQkiTmVzdGVkIHRyYW5zbGF0aW9u IG5vdCBzdXBwb3J0ZWRcbiIpOw0KKwkJCQkJZ290byBvdXQ7DQorCQkJfQ0KKwkJCXNtbXVfZG9t YWluLT5zdGFnZSA9IEFSTV9TTU1VX0RPTUFJTl9ORVNURUQ7DQorCQl9DQorDQorCQkvKiBFbmFi bGUgU3RhZ2UtMSB0cmFuc2xhdGlvbi4gKi8NCisJCXNtbXVfZG9tYWluLT5zMV9jZmcuczFjdHhw dHIgPSBjZmctPnMxY3R4cHRyOw0KKwkJc21tdV9kb21haW4tPnMxX2NmZy5zMWZtdCA9IGNmZy0+ czFmbXQ7DQorCQlzbW11X2RvbWFpbi0+czFfY2ZnLnMxY2RtYXggPSBjZmctPnMxY2RtYXg7DQor CQlzbW11X2RvbWFpbi0+YWJvcnQgPSBmYWxzZTsNCisJCWJyZWFrOw0KKwlkZWZhdWx0Og0KKwkJ Z290byBvdXQ7DQorCX0NCisNCisJc3Bpbl9sb2NrX2lycXNhdmUoJnNtbXVfZG9tYWluLT5kZXZp Y2VzX2xvY2ssIGZsYWdzKTsNCisJbGlzdF9mb3JfZWFjaF9lbnRyeShtYXN0ZXIsICZzbW11X2Rv bWFpbi0+ZGV2aWNlcywgZG9tYWluX2hlYWQpDQorCQlhcm1fc21tdV9pbnN0YWxsX3N0ZV9mb3Jf ZGV2KG1hc3Rlcik7DQorCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnNtbXVfZG9tYWluLT5kZXZp Y2VzX2xvY2ssIGZsYWdzKTsNCisNCisJcmV0ID0gMDsNCitvdXQ6DQorCXNwaW5fdW5sb2NrKCZ4 ZW5fZG9tYWluLT5sb2NrKTsNCisJcmV0dXJuIHJldDsNCit9DQorDQogc3RhdGljIGNvbnN0IHN0 cnVjdCBpb21tdV9vcHMgYXJtX3NtbXVfaW9tbXVfb3BzID0gew0KIAkucGFnZV9zaXplcwkJPSBQ QUdFX1NJWkVfNEssDQogCS5pbml0CQkJPSBhcm1fc21tdV9pb21tdV94ZW5fZG9tYWluX2luaXQs DQpAQCAtMzIyOCw2ICszMzMyLDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBpb21tdV9vcHMgYXJt X3NtbXVfaW9tbXVfb3BzID0gew0KIAkudW5tYXBfcGFnZQkJPSBhcm1faW9tbXVfdW5tYXBfcGFn ZSwNCiAJLmR0X3hsYXRlCQk9IGFybV9zbW11X2R0X3hsYXRlLA0KIAkuYWRkX2RldmljZQkJPSBh cm1fc21tdV9hZGRfZGV2aWNlLA0KKwkuYXR0YWNoX2d1ZXN0X2NvbmZpZyA9IGFybV9zbW11X2F0 dGFjaF9ndWVzdF9jb25maWcsDQogfTsNCiANCiBzdGF0aWMgX19pbml0IGludCBhcm1fc21tdV9k dF9pbml0KHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2LA0KZGlmZiAtLWdpdCBhL3hlbi9kcml2 ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmggYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h cm0vc21tdS12My5oDQppbmRleCBlZjQ5MjA5OGFlLi40YTkxMmJlNzQwIDEwMDY0NA0KLS0tIGEv eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuaA0KKysrIGIveGVuL2RyaXZlcnMv cGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuaA0KQEAgLTQwMiw2ICs0MDIsNyBAQCBlbnVtIGFybV9z bW11X2RvbWFpbl9zdGFnZSB7DQogCUFSTV9TTU1VX0RPTUFJTl9TMiwNCiAJQVJNX1NNTVVfRE9N QUlOX05FU1RFRCwNCiAJQVJNX1NNTVVfRE9NQUlOX0JZUEFTUywNCisJQVJNX1NNTVVfRE9NQUlO X0FCT1JULA0KIH07DQogDQogLyogWGVuIHNwZWNpZmljIGNvZGUuICovDQpkaWZmIC0tZ2l0IGEv eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNz dGhyb3VnaC9hcm0vdnNtbXUtdjMuYw0KaW5kZXggMjViYTczNGZhNy4uM2Y1NTdkMWM0ZCAxMDA2 NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5jDQorKysgYi94 ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuYw0KQEAgLTMxOSw4ICszMTksMTEg QEAgc3RhdGljIGludCBhcm1fdnNtbXVfaGFuZGxlX2NmZ2lfc3RlKHN0cnVjdCB2aXJ0X3NtbXUg KnNtbXUsIHVpbnQ2NF90ICpjbWRwdHIpDQogew0KICAgICBpbnQgcmV0Ow0KICAgICB1aW50NjRf dCBzdGVbU1RSVEFCX1NURV9EV09SRFNdOw0KKyAgICBzdHJ1Y3QgZG9tYWluICpkID0gc21tdS0+ ZDsNCisgICAgc3RydWN0IGRvbWFpbl9pb21tdSAqaGQgPSBkb21faW9tbXUoZCk7DQogICAgIHN0 cnVjdCBhcm1fdnNtbXVfczFfdHJhbnNfY2ZnIHMxX2NmZyA9IHswfTsNCiAgICAgdWludDMyX3Qg c2lkID0gc21tdV9jbWRfZ2V0X3NpZChjbWRwdHJbMF0pOw0KKyAgICBzdHJ1Y3QgaW9tbXVfZ3Vl c3RfY29uZmlnIGd1ZXN0X2NmZyA9IHswfTsNCiANCiAgICAgcmV0ID0gYXJtX3ZzbW11X2ZpbmRf c3RlKHNtbXUsIHNpZCwgc3RlKTsNCiAgICAgaWYgKCByZXQgKQ0KQEAgLTMzMCw2ICszMzMsMjEg QEAgc3RhdGljIGludCBhcm1fdnNtbXVfaGFuZGxlX2NmZ2lfc3RlKHN0cnVjdCB2aXJ0X3NtbXUg KnNtbXUsIHVpbnQ2NF90ICpjbWRwdHIpDQogICAgIGlmICggcmV0ICkNCiAgICAgICAgIHJldHVy biAocmV0ID09IC1FQUdBSU4gKSA/IDAgOiByZXQ7DQogDQorICAgIGd1ZXN0X2NmZy5zMWN0eHB0 ciA9IHMxX2NmZy5zMWN0eHB0cjsNCisgICAgZ3Vlc3RfY2ZnLnMxZm10ID0gczFfY2ZnLnMxZm10 Ow0KKyAgICBndWVzdF9jZmcuczFjZG1heCA9IHMxX2NmZy5zMWNkbWF4Ow0KKw0KKyAgICBpZiAo IHMxX2NmZy5ieXBhc3NlZCApDQorICAgICAgICBndWVzdF9jZmcuY29uZmlnID0gQVJNX1NNTVVf RE9NQUlOX0JZUEFTUzsNCisgICAgZWxzZSBpZiAoIHMxX2NmZy5hYm9ydGVkICkNCisgICAgICAg IGd1ZXN0X2NmZy5jb25maWcgPSBBUk1fU01NVV9ET01BSU5fQUJPUlQ7DQorICAgIGVsc2UNCisg ICAgICAgIGd1ZXN0X2NmZy5jb25maWcgPSBBUk1fU01NVV9ET01BSU5fUzE7DQorDQorICAgIHJl dCA9IGhkLT5wbGF0Zm9ybV9vcHMtPmF0dGFjaF9ndWVzdF9jb25maWcoZCwgc2lkLCAmZ3Vlc3Rf Y2ZnKTsNCisgICAgaWYgKCByZXQgKQ0KKyAgICAgICAgcmV0dXJuIHJldDsNCisNCiAgICAgcmV0 dXJuIDA7DQogfQ0KIA0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9pb21tdS5oIGIveGVu L2luY2x1ZGUveGVuL2lvbW11LmgNCmluZGV4IDM3YzRhMWRjODIuLjI1M2Y4YmI2Y2IgMTAwNjQ0 DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaA0KKysrIGIveGVuL2luY2x1ZGUveGVuL2lv bW11LmgNCkBAIC0zMTIsNiArMzEyLDcgQEAgc3RhdGljIGlubGluZSBpbnQgaW9tbXVfYWRkX2R0 X3BjaV9zaWRlYmFuZF9pZHMoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQogI2VuZGlmIC8qIEhBU19E RVZJQ0VfVFJFRV9ESVNDT1ZFUlkgKi8NCiANCiBzdHJ1Y3QgcGFnZV9pbmZvOw0KK3N0cnVjdCBp b21tdV9ndWVzdF9jb25maWc7DQogDQogLyoNCiAgKiBBbnkgbm9uLXplcm8gdmFsdWUgcmV0dXJu ZWQgZnJvbSBjYWxsYmFja3Mgb2YgdGhpcyB0eXBlIHdpbGwgY2F1c2UgdGhlDQpAQCAtMzg3LDYg KzM4OCwxMSBAQCBzdHJ1Y3QgaW9tbXVfb3BzIHsNCiAjZW5kaWYNCiAgICAgLyogSW5oaWJpdCBh bGwgaW50ZXJydXB0IGdlbmVyYXRpb24sIHRvIGJlIHVzZWQgYXQgc2h1dGRvd24uICovDQogICAg IHZvaWQgKCpxdWllc2NlKSh2b2lkKTsNCisNCisjaWZkZWYgQ09ORklHX0FSTQ0KKyAgICBpbnQg KCphdHRhY2hfZ3Vlc3RfY29uZmlnKShzdHJ1Y3QgZG9tYWluICpkLCB1aW50MzJfdCBzaWQsDQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCBpb21tdV9ndWVzdF9j b25maWcgKmNmZyk7DQorI2VuZGlmDQogfTsNCiANCiAvKg0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441830.1659413 (Exim 4.92) (envelope-from ) id 1xEFBb-0002Fc-Sg; Wed, 07 Oct 2026 00:07:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441830.1659413; Wed, 07 Oct 2026 00: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 1xEFBb-0002FJ-Mu; Wed, 07 Oct 2026 00:07:07 +0000 Received: by outflank-mailman (input) for mailman id 1441830; Wed, 07 Oct 2026 00:07:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBZ-0001i7-Hh for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBY-000T69-Ub for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:04 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58cfa-8faa-0a2a0a5109dd-0a2a4509c6b0-34 for ; Wed, 07 Oct 2026 02:07:04 +0200 Received: from [40.107.159.123] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d28-be1a-0a2a45090019-286b9f7b8a61-3 for ; Wed, 07 Oct 2026 02:07:04 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:03 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=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=UmjyO32lSDQ4ysHO/Hv2h7PHM8+7zYyL/8rennkxc8ENFjBuUJJ8mnjK1yrKpYte2Z0DpV4AdeiEpY/UXl83z8R4FEW1W2MAFOSubDMBJxbmaaFYLSUEphEJVxCkNbmx4eTzjARr6TPN41BawerCpbV2VBaOFMP4tijvUYHQia4E4/IXL+kCgE/UGI63EQU4NRncd74ueGwJmYMhwm7pU1fQoefkU4COUoipRcHd2+VrPdonZUrwkRqceRoiV9pT/HnDwyolMNnmNP90rx6XdlItff0UW4v3A4rfhW1LAa58k/BH0BDD832XrdSKfrnIuTKwJ08VBibgExrWJn/A7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LCqSoTbMVWlWrWhCtrT4/b0XrpHKwXiJ3NC4xH7gusI=; b=rM2VvwdDzHBzB1iG89xRdivmUrkQZRmMQj/WSLl8gLQwcnW68JdaAXJLtIJ1JccgStIRCe4YqK4dF/5wlWSDIy2BM3rOBxsYEl0ou7NE4IlsqeJ2A5xB6ojk1zCALJWSaA3qz941mmu1yQYr5MvcXGafVmvyQAgHQMAIlWSGPBdZ9i8qoceIbIR1Qs1f6YyGEohaRqBMzEkZhwC6EQHOWUUwFPHAT/SeEYuUBs8yYxtrYvn0493YQ4oKq6hrojWkqO/B8lNaucE7K4p0TefeqC+ui3heqAANv6d6H3+MztMtc+T6TnCSAPJDtheKFQ0g+hRXtO4DdK5GTk56RE+lbw== 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=LCqSoTbMVWlWrWhCtrT4/b0XrpHKwXiJ3NC4xH7gusI=; b=JUIg3RQUDCiq/7CB7z841RotoL3eOhJlR66pTQr/HDgH7255B5fmksNr2rqgpySHgwhMXDFG0XZyGY9+I/XgVnpSWwPpkLDjAZ+qFxl1+RDWJZB0sFcVHYUZmLHZa963ns3qvWO+dkNxw4mtzDEy7fq/H0fQUakYNjC+KTkFRy29ojdhfyiMO5vDQ/FKQ7CueFM26AgqGry7KRXs2RZtfBjathRzm708dkSsAgPdgZa7cPy/Yss/TEhtl3/MZT17AQ3zCIHmdAhAQX4zK/C6t5I/w4uXqlG7Df5AtnkE1Qx8jioNmRfJRohIIk6v+NTnAA3/ev06crPcZHSjm4IHcg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 12/22] xen/arm: vsmmuv3: Add support for event queue and global error Thread-Topic: [PATCH v4 12/22] xen/arm: vsmmuv3: Add support for event queue and global error Thread-Index: AQHdVe/HQZPNx9Cm306Bm9pHntkQmg== Date: Wed, 7 Oct 2026 00:07:02 +0000 Message-ID: <1bf1f69e50fa7f6f90bfa6b2c7434c1ba3f65bbf.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: c169ecaa-3f46-4fb5-d969-08df2406ea5a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: /knEnxPhLUIl/aulj7+/lA32fmr4EUPcVrg/iBBBlQt6NB1rDeGskc0MudycyVR8zDFAFivOyQuj9wlfkrtAwNYw4eeV4Hq/nfxuLk4iKcUSTH96I74QhH6Vph+C66wMMsKUVyiqW+kmc9fEMheD/rwHfJSXa+TbkY2iS0Cd4ZGrhh79pXDRwKh7eWj/zYdSSg/Zs+5pc9GCLivrarBnuyO4FG9IbrltJti7PSQRdy6YJB/cZsvLMUqOthUyIPgdBtdJ16VrN+Zptc6VJoEqcXFrxFgw4zMp8hu20R1tZEZmAOPrnK2JkEE6kNjUk7yX3gIaenVsEAPPFtXcmon5rXAgY6mZ2HGxTfU5kV1n3Y2vUK5fBL+cEirxPiyXYbVOVzI5fMHGJYltcvsf7O0FNFrX82Sv78ADxMjj5CdwlzOM//+/2mAvreFh4uAXqswg/KzsbL05e3oUR1AFWc8rBMUw13NFh8OvsLBRtdTXW59JCeyuUcxTNsU3IdvgFRZdt/P78fAmcO+TDP5hGXPRj6OOHl7hDrdR3Lutkh/sQAASDUKcFCywaPKBXXtXWRArqrL+db5KnntqVTaCCMy1qEFAiIKC0pPEKlasCmIcW/ftUf3v633449s/pxrb+TNFfKOBZWyar/Ra3QDKmQkFQhZIJ5woWOs6B3IezdxaghQpgD8GQSBguvASxhwi/vVtCKTxHtw9V+Y2t2VVNbyz7sfylGJrRqL17eMYHyMkO4o= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?V0lFeVJGaWpZT05wUHhrT01Cd1YvUng2a3hjVzFySGlWVXRSMjR2QjJlY1hE?= =?utf-8?B?ME1nU1BvRThiQmF3cHpaSjI3dnNmVHhiREtDSXlmUFFBUnNlbWJ2YmtSTVJP?= =?utf-8?B?dHNZU0svNDZKZUYyV0hVUk1DQnVLVVNtQWQyTVRvOFhWR1ZwZUtJdjA2b2Fs?= =?utf-8?B?UUduZEdiYnl5UmozdGVJNTVkWHUrbllzT0V5NklEdWEwNWhBa2lsMEs2RElt?= =?utf-8?B?VlNqOEhwdUFNbHI1cGg4VUp2MFFYVm1sc1E2M3o0OGxtVTArdm5oRllXQXZ0?= =?utf-8?B?dnk1SCtNNFdhUTRHemVSYkxRWVJpbEpWQjNmT3p4cVpZRzd2MStrbll4WitF?= =?utf-8?B?eUNuT1pwaWRKcDNkM0REWHhTOEhINXhtYWhkSlJWdmN6aGNjSk9ybUk3b2VM?= =?utf-8?B?ckpmVCtNTWdTanY5N1lvMXE3MGZWeVhFU0MwcWQ0S2ZqQVlZZG81UWFvYTBl?= =?utf-8?B?MVBBK2UrdkdDZE9PMlJCT0pIN0RydGFFR2lBWXFQTTlFelFYVk1NNHFKOVpR?= =?utf-8?B?Z2w3eGx3UzNxNVpNZnlIVWJLMExIVWFOOGVqZmFNb0NJUGFsaXpPVWRJTXJr?= =?utf-8?B?ajNobkZJTHdaWHluYTBzUUFId21UaDArS3pJTGxlTXpndGNROHhKalllNXo3?= =?utf-8?B?Y2tJYTEvZnVCaHpLeTJBNXY5N0ZnbjBFUzdGZk5lVDdqRm05K0ZVcTRhalJ5?= =?utf-8?B?Z0JSRmVJOXV2c25naGVWMWZ3S21FRVlQVlRObDdZK0hxS25CUTU2emd6VTVI?= =?utf-8?B?RHo1aXNsYTg2SlJVNkJEUEMzU0c1ZHdjYkgwcldLQjV5aG1rUnkwWkUrN2RG?= =?utf-8?B?THZDa3VlckFFaG5LMFRKVS8xbFphVGhwdjVzNVhCaGFzdG9OMVBWaVNWN0or?= =?utf-8?B?eXhzSmwrS0tKZVJ2Y3N3cHJyckh2WlMzb1hkVFlUakMxRXlpTkV5U3dPSHZj?= =?utf-8?B?N3lBVWU0dVVhOVF2T25jZStYTndzME5sdC83dHoxdHRFdHlvTkJsbWhQbU1Z?= =?utf-8?B?b054eG41aWJibUg0NnphUy82cWZWajIwck9NZm0rY1o3bC8vWDhiemJ2cklO?= =?utf-8?B?TENHQUdZRzlLMDQyVkpuOHp5bXozazJVcEZMbXBBV0Fya1RMWTFJaFV4elFT?= =?utf-8?B?cnJXVkNTSmZXSGFiMllHSzdkVEh3SGxWMGEyMGsvTmxNVi9XMjdPUzc3aWRD?= =?utf-8?B?OWpqdVI4K3FSTjN0ZjNQd05QMzMySzcralNoOTV6aGZjU2pxQkhyOUtCQWlj?= =?utf-8?B?R0tPVHUxdFlWODRmbkpQMWFuZG55VXJJR2FFMSs3V1U5ZEp1b0lCSFFsaGVE?= =?utf-8?B?VlcwQnBvM00reS84SHNxYmV3cHdneWhEeWljY25lcXV6S0F6TjRpQ1BmbE1J?= =?utf-8?B?MjkrMWhWVklZeUhzVkI3SThqUEZTQWZFWTFuUm5BNlZYZHdZandWb21CdHRT?= =?utf-8?B?UmhZUDVGRTBSTTRId2ppV1lPRWw1ekZlTEZPRTk2N3FXUEdUWU1Fc3lDNXZH?= =?utf-8?B?YWZXNVZuM0xGMXdqajhOdFFJZG04QWxWQ3dVS1hOWStnRFFTcytHQUVscFhz?= =?utf-8?B?RlJLWFNsbkxQZGdHMHh1cUhTN2NqWERMN0ZQTjhUZWtVWFY1aThFb25lOWo1?= =?utf-8?B?RnlFbklIUzFXeEFtM0ZkVEZOcmZmNVZaVldzVWRoR2YrM2ZQc092OEJYMjFq?= =?utf-8?B?eTFVa0VLdGNZcXlkTmlxRjJTK1JqNjJkRnc2Z0ZxcHZMWXlaNGs2eGtYN081?= =?utf-8?B?ZFBHTndzNFdqUTdWcCtYb0k0aGlHMWREb0xTeHE0UUcyTG90QlJDNzRldnA2?= =?utf-8?B?My83bGlFYnlGYmRwdVZZSGdpWW9zUHRrLzRFRUt6cEYvd0RQVUNyb0RuTkMy?= =?utf-8?B?VzNkVGhzY2tUbldmQTVqc2l1UE5ZKzBQS0lIK1dKa0l5MGZtenZjQVNJYVRE?= =?utf-8?B?c1dLTXE3Tm1LYXFGcFlXcFpLVkVTZGZYalZydWl3ZENZSURKRGhidmk0M0hZ?= =?utf-8?B?UzBhbFRnU0ljaDNxQkxWU3puRGE1a21JcE9WSnVOdmhNSjgzcXpHTjJoNnpp?= =?utf-8?B?MTRQRXRxKzAxZmJTUEtHNUFTZ0dWUFdobjlENzlMOWtQcFlQM1pBU0krQ0wr?= =?utf-8?B?OWc4MHJuYXQ3NHVQcXI0ZGVUbEJrVGVSZGd1Y2ZRMFlJeE5XY1JHRFdobjNq?= =?utf-8?B?WkZyUkxZOFVRcHVQU3dQZnlCRkhSVzV3djNLRVUvQitqUTg5bmpIdzU3QXoy?= =?utf-8?B?a0pHNmU3eno0R0NEbmpFL1RuZjZJM1o0VkdjV3YrZjlRaUplVUdocU9qOU5Z?= =?utf-8?B?d2sycEdvRDFDN2tEcnpZWmdMK0lQTEF1OGNrNTV1YjJpZW0vdzJ5dz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c169ecaa-3f46-4fb5-d969-08df2406ea5a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:02.9974 (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: tvfoUuuA1Q+k2gCDnr0JaGpIupdfGhyxoMk8mSRjVvGxgn5vf8NRAjSs7fVUbvWkOOZwFgHUMwO7AQX5rmrB8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-bad1c0/1791331624-FC610034-991C501A/0/0 X-purgate-type: clean X-purgate-size: 20720 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkV2ZW50IHF1ZXVlIGlz IHVzZWQgdG8gc2VuZCB0aGUgZXZlbnRzIHRvIGd1ZXN0IHdoZW4gdGhlcmUgaXMgYW4gZXZlbnRz Lw0KZmF1bHRzLiBBZGQgc3VwcG9ydCBmb3IgZXZlbnQgcXVldWUgdG8gc2VuZCBldmVudHMgdG8g Z3Vlc3QuDQoNCkdsb2JhbCBlcnJvciBpbiBTTU1VdjMgaHcgd2lsbCBiZSB1cGRhdGVkIGluIHNt bXVfZ2Vycm9yIGFuZA0Kc21tdV9nZXJyb3JuIHJlZ2lzdGVyLiBBZGQgc3VwcG9ydCBmb3IgZ2xv YmFsIGVycm9yIHJlZ2lzdGVycyB0byBzZW5kDQpnbG9iYWwgZXJyb3IgdG8gZ3Vlc3QuDQoNCkFk ZCBhcmNoaXRlY3R1cmFsIGVycm9yIGhhbmRsaW5nIHRvIHRoZSBlbXVsYXRlZCBjb21tYW5kIHF1 ZXVlLA0KdXBkYXRpbmcgdGhlIGdsb2JhbCBlcnJvciByZWdpc3RlciBhbmQgc3RvcHBpbmcgY29t bWFuZCBjb25zdW1wdGlvbg0Kb24gZXJyb3IuDQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdo IDxyYWh1bC5zaW5naEBhcm0uY29tPg0KU2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxh bl9kam9raWNAZXBhbS5jb20+DQotLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21t dS12My5oICB8ICAyMCArKysNCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMu YyB8IDIzMyArKysrKysrKysrKysrKysrKysrKysrKy0tDQogeGVuL2luY2x1ZGUvcHVibGljL2Fy Y2gtYXJtLmggICAgICAgICAgfCAgIDIgKw0KIDMgZmlsZXMgY2hhbmdlZCwgMjQ0IGluc2VydGlv bnMoKyksIDExIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvYXJtL3NtbXUtdjMuaCBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYz LmgNCmluZGV4IDRhOTEyYmU3NDAuLjQ0ZWNiNWQ4OWMgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5oDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3Vn aC9hcm0vc21tdS12My5oDQpAQCAtMzU4LDYgKzM1OCwyNiBAQA0KIA0KICNkZWZpbmUgRVZUUV8w X0lECQkJR0VOTUFTS19VTEwoNywgMCkNCiANCisjZGVmaW5lIEVWVF9JRF9CQURfU1RSRUFNSUQJ CTB4MDINCisjZGVmaW5lIEVWVF9JRF9CQURfU1RFCQkgICAgCTB4MDQNCisjZGVmaW5lIEVWVF9J RF9UUkFOU0xBVElPTl9GQVVMVAkweDEwDQorI2RlZmluZSBFVlRfSURfQUREUl9TSVpFX0ZBVUxU CQkweDExDQorI2RlZmluZSBFVlRfSURfQUNDRVNTX0ZBVUxUCQkweDEyDQorI2RlZmluZSBFVlRf SURfUEVSTUlTU0lPTl9GQVVMVAkJMHgxMw0KKw0KKyNkZWZpbmUgRVZUUV8wX1NTVgkJCSgxVUwg PDwgMTEpDQorI2RlZmluZSBFVlRRXzBfU1NJRAkJCUdFTk1BU0tfVUxMKDMxLCAxMikNCisjZGVm aW5lIEVWVFFfMF9TSUQJCQlHRU5NQVNLX1VMTCg2MywgMzIpDQorI2RlZmluZSBFVlRRXzFfU1RB RwkJCUdFTk1BU0tfVUxMKDE1LCAwKQ0KKyNkZWZpbmUgRVZUUV8xX1NUQUxMCQkJKDFVTCA8PCAz MSkNCisjZGVmaW5lIEVWVFFfMV9QblUJCQkoMVVMIDw8IDMzKQ0KKyNkZWZpbmUgRVZUUV8xX0lu RAkJCSgxVUwgPDwgMzQpDQorI2RlZmluZSBFVlRRXzFfUm5XCQkJKDFVTCA8PCAzNSkNCisjZGVm aW5lIEVWVFFfMV9TMgkJCSgxVUwgPDwgMzkpDQorI2RlZmluZSBFVlRRXzFfQ0xBU1MJCQlHRU5N QVNLX1VMTCg0MSwgNDApDQorI2RlZmluZSBFVlRRXzFfVFRfUkVBRAkJCSgxVUwgPDwgNDQpDQor I2RlZmluZSBFVlRRXzJfQUREUgkJCUdFTk1BU0tfVUxMKDYzLCAwKQ0KKyNkZWZpbmUgRVZUUV8z X0lQQQkJCUdFTk1BU0tfVUxMKDUxLCAxMikNCiAvKiBQUkkgcXVldWUgKi8NCiAjZGVmaW5lIFBS SVFfRU5UX1NaX1NISUZUCQk0DQogI2RlZmluZSBQUklRX0VOVF9EV09SRFMJCQkoKDEgPDwgUFJJ UV9FTlRfU1pfU0hJRlQpID4+IDMpDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91 Z2gvYXJtL3ZzbW11LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMu Yw0KaW5kZXggM2Y1NTdkMWM0ZC4uODczNDJmZGY2OSAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJz L3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3Vn aC9hcm0vdnNtbXUtdjMuYw0KQEAgLTg1LDYgKzg1LDM1IEBADQogI2RlZmluZSBzbW11X2dldF9z dGVfczFjdHhwdHIoeCkgICAgRklFTERfUFJFUChTVFJUQUJfU1RFXzBfUzFDVFhQVFJfTUFTSywg XA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZJRUxEX0dFVChTVFJUQUJf U1RFXzBfUzFDVFhQVFJfTUFTSywgeCkpDQogDQorLyogZXZlbnQgcXVldWUgZW50cnkgKi8NCitz dHJ1Y3QgYXJtX3NtbXVfZXZ0cV9lbnQgew0KKyAgICAvKiBDb21tb24gZmllbGRzICovDQorICAg IHVpbnQ4X3QgICAgIG9wY29kZTsNCisgICAgdWludDMyX3QgICAgc2lkOw0KKw0KKyAgICAvKiBF dmVudC1zcGVjaWZpYyBmaWVsZHMgKi8NCisgICAgdW5pb24gew0KKyAgICAgICAgc3RydWN0IHsN CisgICAgICAgICAgICB1aW50MzJfdCBzc2lkOw0KKyAgICAgICAgICAgIGJvb2wgc3N2Ow0KKyAg ICAgICAgfSBjX2JhZF9zdGVfc3RyZWFtaWQ7DQorDQorICAgICAgICBzdHJ1Y3Qgew0KKyAgICAg ICAgICAgIGJvb2wgc3RhbGw7DQorICAgICAgICAgICAgdWludDE2X3Qgc3RhZzsNCisgICAgICAg ICAgICB1aW50MzJfdCBzc2lkOw0KKyAgICAgICAgICAgIGJvb2wgc3N2Ow0KKyAgICAgICAgICAg IGJvb2wgczI7DQorICAgICAgICAgICAgdWludDY0X3QgYWRkcjsNCisgICAgICAgICAgICBib29s IHJudzsNCisgICAgICAgICAgICBib29sIHBudTsNCisgICAgICAgICAgICBib29sIGluZDsNCisg ICAgICAgICAgICB1aW50OF90IGNsYXNzOw0KKyAgICAgICAgICAgIHVpbnQ2NF90IGFkZHIyOw0K KyAgICAgICAgfSBmX3RyYW5zbGF0aW9uOw0KKyAgICB9Ow0KK307DQorDQogLyogc3RhZ2UtMSB0 cmFuc2xhdGlvbiBjb25maWd1cmF0aW9uICovDQogc3RydWN0IGFybV92c21tdV9zMV90cmFuc19j Zmcgew0KICAgICBwYWRkcl90IHMxY3R4cHRyOw0KQEAgLTExNSw2ICsxNDQsNyBAQCBzdHJ1Y3Qg dmlydF9zbW11IHsNCiAgICAgdWludDMyX3QgICAgc3RydGFiX2Jhc2VfY2ZnOw0KICAgICB1aW50 NjRfdCAgICBzdHJ0YWJfYmFzZTsNCiAgICAgdWludDMyX3QgICAgaXJxX2N0cmw7DQorICAgIHVp bnQzMl90ICAgIHZpcnE7DQogICAgIHVpbnQ2NF90ICAgIGdlcnJvcl9pcnFfY2ZnMDsNCiAgICAg dWludDY0X3QgICAgZXZ0cV9pcnFfY2ZnMDsNCiAgICAgc3RydWN0ICAgICAgYXJtX3ZzbW11X3F1 ZXVlIGV2dHEsIGNtZHE7DQpAQCAtMTYwLDkgKzE5MCwxNSBAQCBzdGF0aWMgaW5saW5lIGJvb2wg c21tdV9nZXRfZXZ0cV9lbmFibGVkKHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXUpDQogICAgIHNwaW5f dW5sb2NrKCZzbW11LT5jcjBfbG9jayk7DQogDQogICAgIHJldHVybiBlbmFibGVkOw0KLX07DQor fQ0KIA0KIC8qIFF1ZXVlIG1hbmlwdWxhdGlvbiBmdW5jdGlvbnMgKi8NCitzdGF0aWMgYm9vbCBx dWV1ZV9mdWxsKHN0cnVjdCBhcm1fdnNtbXVfcXVldWUgKnEpDQorew0KKyAgICByZXR1cm4gUV9J RFgocSwgcS0+cHJvZCkgPT0gUV9JRFgocSwgcS0+Y29ucykgJiYNCisgICAgICAgICAgIFFfV1JQ KHEsIHEtPnByb2QpICE9IFFfV1JQKHEsIHEtPmNvbnMpOw0KK30NCisNCiBzdGF0aWMgYm9vbCBx dWV1ZV9lbXB0eShzdHJ1Y3QgYXJtX3ZzbW11X3F1ZXVlICpxKQ0KIHsNCiAgICAgcmV0dXJuIFFf SURYKHEsIHEtPnByb2QpID09IFFfSURYKHEsIHEtPmNvbnMpICYmDQpAQCAtMTc1LDEyICsyMTEs MTMzIEBAIHN0YXRpYyB2b2lkIHF1ZXVlX2luY19jb25zKHN0cnVjdCBhcm1fdnNtbXVfcXVldWUg KnEpDQogICAgIHEtPmNvbnMgPSBRX09WRihxLT5jb25zKSB8IFFfV1JQKHEsIGNvbnMpIHwgUV9J RFgocSwgY29ucyk7DQogfQ0KIA0KK3N0YXRpYyB2b2lkIHF1ZXVlX2luY19wcm9kKHN0cnVjdCBh cm1fdnNtbXVfcXVldWUgKnEpDQorew0KKyAgICB1MzIgcHJvZCA9IChRX1dSUChxLCBxLT5wcm9k KSB8IFFfSURYKHEsIHEtPnByb2QpKSArIDE7DQorICAgIHEtPnByb2QgPSBRX09WRihxLT5wcm9k KSB8IFFfV1JQKHEsIHByb2QpIHwgUV9JRFgocSwgcHJvZCk7DQorfQ0KKw0KIHN0YXRpYyB2b2lk IGR1bXBfc21tdV9jb21tYW5kKHVpbnQ2NF90ICpjb21tYW5kKQ0KIHsNCiAgICAgZ3ByaW50ayhY RU5MT0dfRVJSLCAiY21kIDB4JTAybGx4OiAlMDE2IlBSSXg2NCIgJTAxNiJQUkl4NjQiXG4iLA0K ICAgICAgICAgICAgICBzbW11X2NtZF9nZXRfY29tbWFuZChjb21tYW5kWzBdKSwgY29tbWFuZFsw XSwgY29tbWFuZFsxXSk7DQogfQ0KIA0KK3N0YXRpYyB2b2lkIGFybV92c21tdV91cGRhdGVfaXJx KHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXUpDQorew0KKyAgICBib29sIGV2dF9wZW5kaW5nID0gZmFs c2U7DQorICAgIGJvb2wgZ2Vycl9wZW5kaW5nID0gZmFsc2U7DQorICAgIHVpbnQzMl90IGlycV9j dHJsOw0KKw0KKyAgICBzcGluX2xvY2soJnNtbXUtPmlycV9jZmdfbG9jayk7DQorICAgIGlycV9j dHJsID0gc21tdS0+aXJxX2N0cmw7DQorICAgIHNwaW5fdW5sb2NrKCZzbW11LT5pcnFfY2ZnX2xv Y2spOw0KKw0KKyAgICBzcGluX2xvY2soJnNtbXUtPmV2dF9xdWV1ZV9sb2NrKTsNCisgICAgZXZ0 X3BlbmRpbmcgPSAhcXVldWVfZW1wdHkoJnNtbXUtPmV2dHEpOw0KKyAgICBzcGluX3VubG9jaygm c21tdS0+ZXZ0X3F1ZXVlX2xvY2spOw0KKw0KKyAgICBzcGluX2xvY2soJnNtbXUtPmdlcnJvcl9s b2NrKTsNCisgICAgZ2Vycl9wZW5kaW5nID0gKHNtbXUtPmdlcnJvciBeIHNtbXUtPmdlcnJvcm4p ICE9IDA7DQorICAgIHNwaW5fdW5sb2NrKCZzbW11LT5nZXJyb3JfbG9jayk7DQorDQorICAgIHZn aWNfaW5qZWN0X2lycShzbW11LT5kLCBOVUxMLCBzbW11LT52aXJxLA0KKyAgICAgICAgICAgICAg ICAgICAgKChpcnFfY3RybCAmIElSUV9DVFJMX0VWVFFfSVJRRU4pICYmIGV2dF9wZW5kaW5nKSB8 fA0KKyAgICAgICAgICAgICAgICAgICAgKChpcnFfY3RybCAmIElSUV9DVFJMX0dFUlJPUl9JUlFF TikgJiYgZ2Vycl9wZW5kaW5nKSk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGFybV92c21tdV9zZXRf Z2Vycm9yKHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXUsIHVpbnQzMl90IGdlcnJvcl9lcnIpDQorew0K KyAgICB1aW50MzJfdCBwZW5kaW5nLCBuZXdfZ2Vycm9yczsNCisNCisgICAgc3Bpbl9sb2NrKCZz bW11LT5nZXJyb3JfbG9jayk7DQorDQorICAgIHBlbmRpbmcgPSBzbW11LT5nZXJyb3IgXiBzbW11 LT5nZXJyb3JuOw0KKyAgICBuZXdfZ2Vycm9ycyA9IH5wZW5kaW5nICYgZ2Vycm9yX2VycjsNCisN CisgICAgaWYgKCBuZXdfZ2Vycm9ycyApDQorICAgICAgICBzbW11LT5nZXJyb3IgXj0gbmV3X2dl cnJvcnM7DQorDQorICAgIHNwaW5fdW5sb2NrKCZzbW11LT5nZXJyb3JfbG9jayk7DQorDQorICAg IGFybV92c21tdV91cGRhdGVfaXJxKHNtbXUpOw0KK30NCisNCitzdGF0aWMgaW50IGFybV92c21t dV93cml0ZV9ldnRxKHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXUsIHVpbnQ2NF90ICpldnQpDQorew0K KyAgICBzdHJ1Y3QgYXJtX3ZzbW11X3F1ZXVlICpxID0gJnNtbXUtPmV2dHE7DQorICAgIHN0cnVj dCBkb21haW4gKmQgPSBzbW11LT5kOw0KKyAgICBwYWRkcl90IGFkZHI7DQorICAgIGludCByZXQ7 DQorDQorICAgIGlmICggIXNtbXVfZ2V0X2V2dHFfZW5hYmxlZChzbW11KSApDQorICAgICAgICBy ZXR1cm4gLUVJTlZBTDsNCisNCisgICAgc3Bpbl9sb2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7 DQorDQorICAgIGlmICggcXVldWVfZnVsbChxKSApDQorICAgIHsNCisgICAgICAgIHNwaW5fdW5s b2NrKCZzbW11LT5ldnRfcXVldWVfbG9jayk7DQorICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisg ICAgfQ0KKw0KKyAgICBhZGRyID0gUV9QUk9EX0VOVChxKTsNCisNCisgICAgcmV0ID0gYWNjZXNz X2d1ZXN0X21lbW9yeV9ieV9ncGEoZCwgYWRkciwgZXZ0LA0KKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzaXplb2YoKmV2dCkgKiBFVlRRX0VOVF9EV09SRFMsIHRydWUpOw0K KyAgICBpZiAoIHJldCApDQorICAgIHsNCisgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5ldnRf cXVldWVfbG9jayk7DQorICAgICAgICByZXR1cm4gcmV0Ow0KKyAgICB9DQorDQorICAgIHF1ZXVl X2luY19wcm9kKHEpOw0KKw0KKyAgICBzcGluX3VubG9jaygmc21tdS0+ZXZ0X3F1ZXVlX2xvY2sp Ow0KKw0KKyAgICBhcm1fdnNtbXVfdXBkYXRlX2lycShzbW11KTsNCisNCisgICAgcmV0dXJuIDA7 DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGFybV92c21tdV9zZW5kX2V2ZW50KHN0cnVjdCB2aXJ0X3Nt bXUgKnNtbXUsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGFybV9z bW11X2V2dHFfZW50ICplbnQpDQorew0KKyAgICB1aW50NjRfdCBldnRbRVZUUV9FTlRfRFdPUkRT XTsNCisgICAgaW50IHJldDsNCisNCisgICAgbWVtc2V0KGV2dCwgMCwgMSA8PCBFVlRRX0VOVF9T Wl9TSElGVCk7DQorDQorICAgIGlmICggIXNtbXVfZ2V0X2V2dHFfZW5hYmxlZChzbW11KSApDQor ICAgICAgICByZXR1cm47DQorDQorICAgIGV2dFswXSB8PSBGSUVMRF9QUkVQKEVWVFFfMF9JRCwg ZW50LT5vcGNvZGUpOw0KKyAgICBldnRbMF0gfD0gRklFTERfUFJFUChFVlRRXzBfU0lELCBlbnQt PnNpZCk7DQorDQorICAgIHN3aXRjaCAoIGVudC0+b3Bjb2RlICkNCisgICAgew0KKyAgICBjYXNl IEVWVF9JRF9CQURfU1RSRUFNSUQ6DQorICAgIGNhc2UgRVZUX0lEX0JBRF9TVEU6DQorICAgICAg ICBldnRbMF0gfD0gRklFTERfUFJFUChFVlRRXzBfU1NJRCwgZW50LT5jX2JhZF9zdGVfc3RyZWFt aWQuc3NpZCk7DQorICAgICAgICBldnRbMF0gfD0gRklFTERfUFJFUChFVlRRXzBfU1NWLCBlbnQt PmNfYmFkX3N0ZV9zdHJlYW1pZC5zc3YpOw0KKyAgICAgICAgYnJlYWs7DQorICAgIGNhc2UgRVZU X0lEX1RSQU5TTEFUSU9OX0ZBVUxUOg0KKyAgICBjYXNlIEVWVF9JRF9BRERSX1NJWkVfRkFVTFQ6 DQorICAgIGNhc2UgRVZUX0lEX0FDQ0VTU19GQVVMVDoNCisgICAgY2FzZSBFVlRfSURfUEVSTUlT U0lPTl9GQVVMVDoNCisgICAgICAgIGJyZWFrOw0KKyAgICBkZWZhdWx0Og0KKyAgICAgICAgZ2Rw cmludGsoWEVOTE9HX1dBUk5JTkcsICJ2U01NVXYzOiBldmVudCBvcGNvZGUgaXMgYmFkXG4iKTsN CisgICAgICAgIGJyZWFrOw0KKyAgICB9DQorDQorICAgIHJldCA9IGFybV92c21tdV93cml0ZV9l dnRxKHNtbXUsIGV2dCk7DQorICAgIGlmICggcmV0ICkNCisgICAgICAgIGFybV92c21tdV9zZXRf Z2Vycm9yKHNtbXUsIEdFUlJPUl9FVlRRX0FCVF9FUlIpOw0KKw0KKyAgICByZXR1cm47DQorfQ0K Kw0KIHN0YXRpYyBpbnQgYXJtX3ZzbW11X2ZpbmRfc3RlKHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXUs IHVpbnQzMl90IHNpZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50NjRfdCAq c3RlKQ0KIHsNCkBAIC0xODksNiArMzQ2LDE0IEBAIHN0YXRpYyBpbnQgYXJtX3ZzbW11X2ZpbmRf c3RlKHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXUsIHVpbnQzMl90IHNpZCwNCiAgICAgdWludDMyX3Qg bG9nMnNpemU7DQogICAgIGludCBzdHJ0YWJfc2l6ZV9zaGlmdDsNCiAgICAgaW50IHJldDsNCisg ICAgc3RydWN0IGFybV9zbW11X2V2dHFfZW50IGVudCA9IHsNCisgICAgICAgIC5vcGNvZGUgPSBF VlRfSURfQkFEX1NUUkVBTUlELA0KKyAgICAgICAgLnNpZCA9IHNpZCwNCisgICAgICAgIC5jX2Jh ZF9zdGVfc3RyZWFtaWQgPSB7DQorICAgICAgICAgICAgLnNzaWQgPSAwLA0KKyAgICAgICAgICAg IC5zc3YgPSBmYWxzZSwNCisgICAgICAgIH0sDQorICAgIH07DQogDQogICAgIHNwaW5fbG9jaygm c21tdS0+c3RydGFiX2NmZ19sb2NrKTsNCiAgICAgbG9nMnNpemUgPSBNSU4oRklFTERfR0VUKFNU UlRBQl9CQVNFX0NGR19MT0cyU0laRSwgc21tdS0+c3RydGFiX2Jhc2VfY2ZnKSwNCkBAIC0xOTYs NyArMzYxLDEwIEBAIHN0YXRpYyBpbnQgYXJtX3ZzbW11X2ZpbmRfc3RlKHN0cnVjdCB2aXJ0X3Nt bXUgKnNtbXUsIHVpbnQzMl90IHNpZCwNCiAgICAgc3Bpbl91bmxvY2soJnNtbXUtPnN0cnRhYl9j ZmdfbG9jayk7DQogDQogICAgIGlmICggc2lkID49ICgxVSA8PCBsb2cyc2l6ZSkgKQ0KKyAgICB7 DQorICAgICAgICBhcm1fdnNtbXVfc2VuZF9ldmVudChzbW11LCAmZW50KTsNCiAgICAgICAgIHJl dHVybiAtRUlOVkFMOw0KKyAgICB9DQogDQogICAgIHNwaW5fbG9jaygmc21tdS0+c3RydGFiX2Nm Z19sb2NrKTsNCiAgICAgaWYgKCBGSUVMRF9HRVQoU1RSVEFCX0JBU0VfQ0ZHX0ZNVCwgc21tdS0+ c3RydGFiX2Jhc2VfY2ZnKSA9PQ0KQEAgLTI0OSw2ICs0MTcsNyBAQCBzdGF0aWMgaW50IGFybV92 c21tdV9maW5kX3N0ZShzdHJ1Y3QgdmlydF9zbW11ICpzbW11LCB1aW50MzJfdCBzaWQsDQogICAg ICAgICB7DQogICAgICAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgImlkeD0lZCA+IG1heF9s Ml9zdGU9JWRcbiIsDQogICAgICAgICAgICAgICAgICAgICAgaWR4LCBtYXhfbDJfc3RlKTsNCisg ICAgICAgICAgICBhcm1fdnNtbXVfc2VuZF9ldmVudChzbW11LCAmZW50KTsNCiAgICAgICAgICAg ICByZXR1cm4gLUVJTlZBTDsNCiAgICAgICAgIH0NCiAgICAgICAgIGFkZHIgPSBsMnB0ciArIGlk eCAqIHNpemVvZigqc3RlKSAqIFNUUlRBQl9TVEVfRFdPUkRTOw0KQEAgLTI3Nyw2ICs0NDYsMTQg QEAgc3RhdGljIGludCBhcm1fdnNtbXVfZGVjb2RlX3N0ZShzdHJ1Y3QgdmlydF9zbW11ICpzbW11 LCB1aW50MzJfdCBzaWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50NjRf dCAqc3RlKQ0KIHsNCiAgICAgdWludDY0X3QgdmFsID0gc3RlWzBdOw0KKyAgICBzdHJ1Y3QgYXJt X3NtbXVfZXZ0cV9lbnQgZW50ID0gew0KKyAgICAgICAgLm9wY29kZSA9IEVWVF9JRF9CQURfU1RF LA0KKyAgICAgICAgLnNpZCA9IHNpZCwNCisgICAgICAgIC5jX2JhZF9zdGVfc3RyZWFtaWQgPSB7 DQorICAgICAgICAgICAgLnNzaWQgPSAwLA0KKyAgICAgICAgICAgIC5zc3YgPSBmYWxzZSwNCisg ICAgICAgIH0sDQorICAgIH07DQogDQogICAgIGlmICggISh2YWwgJiBTVFJUQUJfU1RFXzBfVikg KQ0KICAgICAgICAgcmV0dXJuIC1FQUdBSU47DQpAQCAtMzEyLDYgKzQ4OSw3IEBAIHN0YXRpYyBp bnQgYXJtX3ZzbW11X2RlY29kZV9zdGUoc3RydWN0IHZpcnRfc21tdSAqc21tdSwgdWludDMyX3Qg c2lkLA0KICAgICByZXR1cm4gMDsNCiANCiAgYmFkX3N0ZToNCisgICAgYXJtX3ZzbW11X3NlbmRf ZXZlbnQoc21tdSwgJmVudCk7DQogICAgIHJldHVybiAtRUlOVkFMOw0KIH0NCiANCkBAIC0zNjIs MTYgKzU0MCwxOSBAQCBzdGF0aWMgaW50IGFybV92c21tdV9oYW5kbGVfY21kcyhzdHJ1Y3Qgdmly dF9zbW11ICpzbW11KQ0KICAgICBpZiAoICFzbW11X2dldF9jbWRxX2VuYWJsZWQoc21tdSkgKQ0K ICAgICAgICAgcmV0dXJuIDA7DQogDQotICAgIHdoaWxlICggIXF1ZXVlX2VtcHR5KHEpICkNCisg ICAgd2hpbGUgKCAhcXVldWVfZW1wdHkocSkgJiYNCisgICAgICAgICAgKChzbW11LT5nZXJyb3Ig XiBzbW11LT5nZXJyb3JuKSAmIChHRVJST1JfQ01EUV9FUlIpKSA9PSAwICkNCiAgICAgew0KLSAg ICAgICAgaW50IHJldDsNCi0NCiAgICAgICAgIGFkZHIgPSBRX0NPTlNfRU5UKHEpOw0KICAgICAg ICAgcmV0ID0gYWNjZXNzX2d1ZXN0X21lbW9yeV9ieV9ncGEoZCwgYWRkciwgY29tbWFuZCwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihjb21tYW5kKSwg ZmFsc2UpOw0KLSAgICAgICAgaWYgKCByZXQgKSB7DQotICAgICAgICAgICAgcXVldWVfaW5jX2Nv bnMocSk7DQotICAgICAgICAgICAgcmV0dXJuIHJldDsNCisgICAgICAgIGlmICggcmV0ICkNCisg ICAgICAgIHsNCisgICAgICAgICAgICBzbW11LT5jbWRxLmNvbnMgJj0gfkNNRFFfQ09OU19FUlI7 DQorICAgICAgICAgICAgc21tdS0+Y21kcS5jb25zIHw9IEZJRUxEX1BSRVAoQ01EUV9DT05TX0VS UiwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ01EUV9FUlJfQ0VS Uk9SX0FCVF9JRFgpOw0KKyAgICAgICAgICAgIGFybV92c21tdV9zZXRfZ2Vycm9yKHNtbXUsIEdF UlJPUl9DTURRX0VSUik7DQorICAgICAgICAgICAgYnJlYWs7DQogICAgICAgICB9DQogDQogICAg ICAgICBzd2l0Y2ggKCBzbW11X2NtZF9nZXRfY29tbWFuZChjb21tYW5kWzBdKSApDQpAQCAtMzk1 LDYgKzU3NiwxMCBAQCBzdGF0aWMgaW50IGFybV92c21tdV9oYW5kbGVfY21kcyhzdHJ1Y3Qgdmly dF9zbW11ICpzbW11KQ0KICAgICAgICAgZGVmYXVsdDoNCiAgICAgICAgICAgICBnZHByaW50ayhY RU5MT0dfRVJSLCAidlNNTVV2MzogdW5oYW5kbGVkIGNvbW1hbmRcbiIpOw0KICAgICAgICAgICAg IGR1bXBfc21tdV9jb21tYW5kKGNvbW1hbmQpOw0KKyAgICAgICAgICAgIHNtbXUtPmNtZHEuY29u cyAmPSB+Q01EUV9DT05TX0VSUjsNCisgICAgICAgICAgICBzbW11LT5jbWRxLmNvbnMgfD0gRklF TERfUFJFUChDTURRX0NPTlNfRVJSLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENNRFFfRVJSX0NFUlJPUl9JTExfSURYKTsNCisgICAgICAgICAgICBhcm1fdnNt bXVfc2V0X2dlcnJvcihzbW11LCBHRVJST1JfQ01EUV9FUlIpOw0KICAgICAgICAgICAgIGJyZWFr Ow0KICAgICAgICAgfQ0KIA0KQEAgLTQwNSw2ICs1OTAsMTUgQEAgc3RhdGljIGludCBhcm1fdnNt bXVfaGFuZGxlX2NtZHMoc3RydWN0IHZpcnRfc21tdSAqc21tdSkNCiAgICAgICAgICAgICAgICAg ICAgICByZXQpOw0KICAgICAgICAgICAgIGR1bXBfc21tdV9jb21tYW5kKGNvbW1hbmQpOw0KICAg ICAgICAgfQ0KKw0KKyAgICAgICAgLyoNCisgICAgICAgICogU3RvcCBjb25zdW1pbmcgdGhlIGNv bW1hbmQgcXVldWUgaWYgYSBjb21tYW5kIGVycm9yIG9jY3VycmVkLg0KKyAgICAgICAgKiBDTURR X0NPTlMgY29udGludWVzIHRvIHBvaW50IGF0IHRoZSBvZmZlbmRpbmcgY29tbWFuZCB1bnRpbCB0 aGUNCisgICAgICAgICogZXJyb3IgaXMgYWNrbm93bGVkZ2VkLg0KKyAgICAgICAgKi8NCisgICAg ICAgIGlmICggKHNtbXUtPmdlcnJvciBeIHNtbXUtPmdlcnJvcm4pICYgR0VSUk9SX0NNRFFfRVJS ICkNCisgICAgICAgICAgICBicmVhazsNCisNCiAgICAgICAgIHF1ZXVlX2luY19jb25zKHEpOw0K ICAgICB9DQogDQpAQCAtNDQzLDYgKzYzNyw3IEBAIHN0YXRpYyBpbnQgdnNtbXV2M19tbWlvX3dy aXRlKHN0cnVjdCB2Y3B1ICp2LCBtbWlvX2luZm9fdCAqaW5mbywNCiAgICAgICAgICAgICB2cmVn X3JlZzMyX3VwZGF0ZSgmcmVnMzIsIHIsIGluZm8pOw0KICAgICAgICAgICAgIHNtbXUtPmV2dHEu Y29ucyA9IHJlZzMyOw0KICAgICAgICAgICAgIHNwaW5fdW5sb2NrKCZzbW11LT5ldnRfcXVldWVf bG9jayk7DQorICAgICAgICAgICAgYXJtX3ZzbW11X3VwZGF0ZV9pcnEoc21tdSk7DQogICAgICAg ICAgICAgYnJlYWs7DQogICAgICAgICBkZWZhdWx0Og0KICAgICAgICAgICAgIHByaW50ayhYRU5M T0dfR19FUlINCkBAIC01NzMsNiArNzY4LDcgQEAgc3RhdGljIGludCB2c21tdXYzX21taW9fd3Jp dGUoc3RydWN0IHZjcHUgKnYsIG1taW9faW5mb190ICppbmZvLA0KICAgICAgICAgICAgIHZyZWdf cmVnMzJfdXBkYXRlKCZyZWczMiwgciwgaW5mbyk7DQogICAgICAgICAgICAgc21tdS0+aXJxX2N0 cmwgPSByZWczMjsNCiAgICAgICAgICAgICBzcGluX3VubG9jaygmc21tdS0+aXJxX2NmZ19sb2Nr KTsNCisgICAgICAgICAgICBhcm1fdnNtbXVfdXBkYXRlX2lycShzbW11KTsNCiAgICAgICAgICAg ICBicmVhazsNCiANCiAgICAgICAgIGNhc2UgVlJFRzY0KEFSTV9TTU1VX0dFUlJPUl9JUlFfQ0ZH MCk6DQpAQCAtNjAyLDYgKzc5OCwxMCBAQCBzdGF0aWMgaW50IHZzbW11djNfbW1pb193cml0ZShz dHJ1Y3QgdmNwdSAqdiwgbW1pb19pbmZvX3QgKmluZm8sDQogICAgICAgICAgICAgdnJlZ19yZWcz Ml91cGRhdGUoJnJlZzMyLCByLCBpbmZvKTsNCiAgICAgICAgICAgICBzbW11LT5nZXJyb3JuID0g cmVnMzI7DQogICAgICAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPmdlcnJvcl9sb2NrKTsNCisg ICAgICAgICAgICBhcm1fdnNtbXVfdXBkYXRlX2lycShzbW11KTsNCisgICAgICAgICAgICBzcGlu X2xvY2soJnNtbXUtPmNtZF9xdWV1ZV9sb2NrKTsNCisgICAgICAgICAgICBhcm1fdnNtbXVfaGFu ZGxlX2NtZHMoc21tdSk7DQorICAgICAgICAgICAgc3Bpbl91bmxvY2soJnNtbXUtPmNtZF9xdWV1 ZV9sb2NrKTsNCiAgICAgICAgICAgICBicmVhazsNCiANCiAgICAgICAgIGRlZmF1bHQ6DQpAQCAt OTA1LDkgKzExMDUsMTAgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBtbWlvX2hhbmRsZXJfb3BzIHZz bW11djNfbW1pb19oYW5kbGVyID0gew0KICAgICAud3JpdGUgPSB2c21tdXYzX21taW9fd3JpdGUs DQogfTsNCiANCi1zdGF0aWMgaW50IHZzbW11djNfaW5pdF9zaW5nbGUoc3RydWN0IGRvbWFpbiAq ZCwgcGFkZHJfdCBhZGRyLCBwYWRkcl90IHNpemUsDQotICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHVpbnQzMl90IGZlYXR1cmVzKQ0KK3N0YXRpYyBpbnQgdnNtbXV2M19pbml0X3Npbmds ZShzdHJ1Y3QgZG9tYWluICpkLCBwYWRkcl90IGFkZHIsDQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBhZGRyX3Qgc2l6ZSwgdWludDMyX3QgdmlycSwgdWludDMyX3QgZmVhdHVyZXMp DQogew0KKyAgICBpbnQgcmV0Ow0KICAgICBzdHJ1Y3QgdmlydF9zbW11ICpzbW11Ow0KIA0KICAg ICBzbW11ID0geHphbGxvYyhzdHJ1Y3QgdmlydF9zbW11KTsNCkBAIC05MTYsNiArMTExNyw3IEBA IHN0YXRpYyBpbnQgdnNtbXV2M19pbml0X3NpbmdsZShzdHJ1Y3QgZG9tYWluICpkLCBwYWRkcl90 IGFkZHIsIHBhZGRyX3Qgc2l6ZSwNCiANCiAgICAgc21tdS0+ZCA9IGQ7DQogICAgIHNtbXUtPmZl YXR1cmVzID0gZmVhdHVyZXM7DQorICAgIHNtbXUtPnZpcnEgPSB2aXJxOw0KICAgICBzbW11LT5j bWRxLmVudF9zaXplID0gQ01EUV9FTlRfRFdPUkRTICogRFdPUkRTX0JZVEVTOw0KICAgICBzbW11 LT5ldnRxLmVudF9zaXplID0gRVZUUV9FTlRfRFdPUkRTICogRFdPUkRTX0JZVEVTOw0KIA0KQEAg LTkyOCw2ICsxMTMwLDE1IEBAIHN0YXRpYyBpbnQgdnNtbXV2M19pbml0X3NpbmdsZShzdHJ1Y3Qg ZG9tYWluICpkLCBwYWRkcl90IGFkZHIsIHBhZGRyX3Qgc2l6ZSwNCiAgICAgc3Bpbl9sb2NrX2lu aXQoJnNtbXUtPnN0cnRhYl9jZmdfbG9jayk7DQogICAgIHNwaW5fbG9ja19pbml0KCZzbW11LT5p cnFfY2ZnX2xvY2spOw0KIA0KKyAgICByZXQgPSB2Z2ljX3Jlc2VydmVfdmlycShkLCB2aXJxKTsN CisgICAgaWYgKCAhcmV0ICkNCisgICAgew0KKyAgICAgICAgcHJpbnRrKFhFTkxPR19HX0VSUg0K KyAgICAgICAgICAgICAgICAgInZTTU1VdjM6IEZhaWxlZCB0byByZXNlcnZlIGRvbWFpbiB2SVJR ICV1XG4iLCB2aXJxKTsNCisgICAgICAgIHhmcmVlKHNtbXUpOw0KKyAgICAgICAgcmV0dXJuIC1F SU5WQUw7DQorICAgIH0NCisNCiAgICAgcmVnaXN0ZXJfbW1pb19oYW5kbGVyKGQsICZ2c21tdXYz X21taW9faGFuZGxlciwgYWRkciwgc2l6ZSwgc21tdSk7DQogDQogICAgIC8qIFJlZ2lzdGVyIHRo ZSB2SU9NTVUgdG8gYmUgYWJsZSB0byBjbGVhbiBpdCB1cCBsYXRlci4gKi8NCkBAIC05NTMsNyAr MTE2NCw3IEBAIHN0YXRpYyBpbnQgZG9tYWluX3ZzbW11djNfaW5pdChzdHJ1Y3QgZG9tYWluICpk KQ0KICAgICAgICAgew0KICAgICAgICAgICAgIHNtbXUgPSAoY29uc3Qgc3RydWN0IGFybV9zbW11 X2RldmljZSAqKSBod19pb21tdS0+aW9tbXU7DQogICAgICAgICAgICAgcmV0ID0gdnNtbXV2M19p bml0X3NpbmdsZShkLCBod19pb21tdS0+YWRkciwgaHdfaW9tbXUtPnNpemUsDQotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzbW11LT5mZWF0dXJlcyk7DQorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBod19pb21tdS0+aXJxLCBzbW11LT5mZWF0dXJl cyk7DQogICAgICAgICAgICAgaWYgKCByZXQgKQ0KICAgICAgICAgICAgICAgICByZXR1cm4gcmV0 Ow0KICAgICAgICAgfQ0KQEAgLTk4Myw3ICsxMTk0LDcgQEAgc3RhdGljIGludCBkb21haW5fdnNt bXV2M19pbml0KHN0cnVjdCBkb21haW4gKmQpDQogICAgICAgICB9DQogDQogICAgICAgICByZXQg PSB2c21tdXYzX2luaXRfc2luZ2xlKGQsIEdVRVNUX1ZTTU1VVjNfQkFTRSwgR1VFU1RfVlNNTVVW M19TSVpFLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmZWF0dXJlcyk7DQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdVRVNUX1ZTTU1VX1NQSSwgZmVhdHVy ZXMpOw0KICAgICAgICAgaWYgKCByZXQgKQ0KICAgICAgICAgICAgIHJldHVybiByZXQ7DQogICAg IH0NCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaCBiL3hlbi9pbmNs dWRlL3B1YmxpYy9hcmNoLWFybS5oDQppbmRleCA4ODYzZTJlNDU3Li5jNDNiOGI3YjcxIDEwMDY0 NA0KLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCisrKyBiL3hlbi9pbmNsdWRl L3B1YmxpYy9hcmNoLWFybS5oDQpAQCAtNTM4LDYgKzUzOCw4IEBAIHR5cGVkZWYgdWludDY0X3Qg eGVuX2NhbGxiYWNrX3Q7DQogI2RlZmluZSBHVUVTVF9WSVJUSU9fTU1JT19TUElfRklSU1QgICAz Mw0KICNkZWZpbmUgR1VFU1RfVklSVElPX01NSU9fU1BJX0xBU1QgICAgNDMNCiANCisjZGVmaW5l IEdVRVNUX1ZTTU1VX1NQSSAgICAgICAgIDQ0DQorDQogLyoNCiAgKiBTR0kgaXMgdGhlIHByZWZl cnJlZCBkZWxpdmVyeSBtZWNoYW5pc20gb2YgRkYtQSBwZW5kaW5nIG5vdGlmaWNhdGlvbnMgb3IN CiAgKiBzY2hlZHVsZSByZWN2ZWl2ZSBpbnRlcnJ1cHQuIFNHSXMgOC0xNSBhcmUgbm9ybWFsbHkg bm90IHVzZWQgYnkgYSBndWVzdA0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441833.1659418 (Exim 4.92) (envelope-from ) id 1xEFBc-0002Oq-Nk; Wed, 07 Oct 2026 00:07:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441833.1659418; Wed, 07 Oct 2026 00: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 1xEFBc-0002NM-DX; Wed, 07 Oct 2026 00:07:08 +0000 Received: by outflank-mailman (input) for mailman id 1441833; Wed, 07 Oct 2026 00:07:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBa-0001yi-Jt for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBa-00Bv1m-02 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:06 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d14-e002-0a2a0a5209dd-0a2a4501d89a-22 for ; Wed, 07 Oct 2026 02:07:05 +0200 Received: from [52.101.66.96] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d29-5984-0a2a45010019-346542605c75-3 for ; Wed, 07 Oct 2026 02:07:05 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:04 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=kROg9S3up0FcySHzCosPr82VITPT7t0nIeOXhvsOBTtH8L8HkQY98QxvkjeILZeucOJXWZuG7QgmGwSkqiHM18jstnmnwFIoVAfpICkBgjQdKVLA6svWA2T9BYulfmOM4Za6gjyDL3xLC+y67jepzyjN2GWCRcO7U2XZLAD1R2HAjxgy4qHiPSpIwL4vb8DDM8KTG1gUOwbVVGGw2NFwi6XnPpC3iGctYUj68s1FRFr7BmcH49+Np/tWTcGKYWQ8coAV6bnehjJZxN/QBR4GNqR4v0UgptAc5aEliawSrVL/DNXlSk+fmRS/70KzkCbGxKQvEXmRg4GJbhrAmIBzkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=80QaLYCIkbbd3V9618ZPaglbC0xPD61hD7G2WmvMdYg=; b=IoKBKwZrdwXZBXuyNqLnmQMayoWuhCli02UF6nesXBm+PY0FDy2lwf9Dx0FKT/czMUMC9GmgZPkjl4I/LhI40h+qZrVZnX/bQdXjjurU27tPqef8ztbh7aKK2qb+R1ffh7+9BPsm3CSX9qSRfz6oflbUKEiKFt4vMEFeA8JXXfSI70Ada9PLChW8tosQHdIkt2j19CteQI9WNlKoFRE8JSq57JOsHtl4BdP+OZPdtYKRCTe0ZPRMoUB3G3J7Yk1u6FTx62fclnKojKq9T4anblsXPOla7pVQjnA9/9xyyR1lh5SojArcUZJVpwufasyhb3mwwyQ3TAmbkCtyB2i6Bg== 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=80QaLYCIkbbd3V9618ZPaglbC0xPD61hD7G2WmvMdYg=; b=GJRnnAr584hZmvsPTihbkTnuoCXlN8Kw1hiF0flAwLxClePhgpoOcYLnEDcDORm5MCKqPBrnQrP361T+kPh2XlQT+jKaggLsx4LmopbweJpXPqGm7qhuRmd7brQaMP0g8d4igeFIpYjK3qr/0jjp+P7VGUHgVevS+qnh//w/q02loVWeX/BsCiULiw6jkja02KBWdpABYorMc9ObGrULyJnvtJM4WRgLXwQn+Xzzo832lRLBqZbKsGLbNATI2Mu6UbKHJi1MjuLc/lCL+OFg80m1b/iFGm+b0SDfKCrYP3eHvSSm8dOGYwmUAdQAyWMAJdBBFDsRbtW/spp6YDXCng== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 13/22] xen/arm: vsmmuv3: IOMMU device tree node for dom0 Thread-Topic: [PATCH v4 13/22] xen/arm: vsmmuv3: IOMMU device tree node for dom0 Thread-Index: AQHdVe/IIN84IILw1U2j1MPuKYXDMQ== Date: Wed, 7 Oct 2026 00:07:04 +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: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 6c6aefb1-d552-4135-1f68-08df2406eb1b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|260925022911599003|56012099006|260925021911599003|11063799006|10067099003|260925021311599003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: HLl+Eupk6HL4DuwS8z6RXrGqks9jMU46ZoCPOVIYb3Mrj5S3SO6uoOpapbMibPrcIecbZV4gmrlFAe2T/7RKCcnZLkF730jXoLMi3oXTeu+bc1G2qlDJ2Wfgn0nuKbSioi+ZSkBo3JVxH5f0PTPDoOsRPW91PgsnzEe7I/NiPJRMwti7/s9DCgTffPovF4icCbBEM2GOqVhIlPfT2HFMZITZy1JwwtFc1cM5LPQRX7XbyjtkkBXwGywog0ThJdN+vynPAvGrLU0LHScZyyegZu2mI9Pa1YEYCFvKCgW/gjNUoH+ps8U5jV1mHESRIAZRDmXc+MHxyDXltJm5sxpZTPTOZ/t/UBY85t/wzQOAum5RAArgKwXKo+rhUfeA6lX6vGX9STtO2DCXKDggVuEwKSsu413Z4vgJ9c6WhqmbQHcLrT9qFnU1CbjL80uSWSE24WThBkm6gs4wVoogWanQEi4JitIxgjB6KYshmC5bRLmqFpKDDcOf3eqlXFW79CUTu4EWnmrZgAk2ndGLHS3cQZlfNnl0ALU+H6DtQ766jR9bXVQqXA7s4VMGS+W8xNgCaI2OSuulm77MViQibiAI6TfzGcxNEGWvvTk8Zqf0fbWmFQCYWeZRiTl/TL/jMv/4gS/Z2lv689L/Wlz64hHYforc9fcqgrN6PfPWiWuS6IYpZbq7Ghw9imfhEEXRmiQmTGmpJLftqmPlNKOO4vEaV+plUywj2/zg/sVm+rTlKYk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(260925022911599003)(56012099006)(260925021911599003)(11063799006)(10067099003)(260925021311599003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dmxYRUxKYVBZeFF4Wm9lMFBjMDJLNTgvVGtsWGxMbFBxRlBBZnlBOGcwVytF?= =?utf-8?B?aHN5TU9DcjBJZkZxbFBCOFdkU0JlOFNVR244NlE0Yi9xNS94UmNURTR4ZmZo?= =?utf-8?B?dGd0SGZ5eExsa25DQ2gwTzNya3RYTGVTRTJWaC9VMmZCKzd4djkxS0llT2M5?= =?utf-8?B?TzRTZk0vVklHTDNuR3d3OHMyQUJRdENQUDg0R1FIaVhMYkpRcnZ4WTF2ek9i?= =?utf-8?B?OEMxVDdMS2IvR0I5SUdWeTFtQTQwRHNvdFYyclNTVktOTURPZjIrQmhlYVJi?= =?utf-8?B?ZXdqQk1zUXpsdTN0L3VnWXl3TUhYM21palV0Q0RzdjJFVlMyeURQWU05NDBX?= =?utf-8?B?N3RQZ3RpR1I3bU5BempHTy9zQUp4VGQ5T0lWMHBOYXljblZqTFVBUTNUampz?= =?utf-8?B?VnpUVHE2SzZnZ1d0eU8xM2RWNUMxdXRSTGt2RkRLWTFpZnZsck5rL1NIdnpt?= =?utf-8?B?bHFtMzl1RXVVVUFxU1U2Q0ZoOWlCRVhBdWUwK1pZL2FHbllVREl4OFpxeDVk?= =?utf-8?B?ejZsUkcxR3d1bGxvSlFEYVpRVUlhd1lQSzlTSFlDNWJBR0w1MGNXaWhVK3Z2?= =?utf-8?B?WERTTHRyRDRJSkRoTmt0Vi8yOUlVOWNYdi9tY3g2dmd6eEpteTBCR3Nwc0RK?= =?utf-8?B?b1g2MElQL1FuaWltRjQ0NUYrQVkxS2g2ZVUyQUZQQmsvUGQ3b1MvMWxFcm83?= =?utf-8?B?d0ZsTStVYlQ0djZGcW8yallON2hCbzhiWndmN2ZUU0E5ZE1GS3NRUEpCMURR?= =?utf-8?B?SXJOSk05WG5UM2RHWDJ3TjdOdHZOY3JzSitFWC9INURQR2JnSHc0WU9oR1JJ?= =?utf-8?B?V0JFNURhT3c1Yi9PTWJ4V2VUZE8wR1NVbUE3QTZHb3k1SHVFV2NVdHIwckZm?= =?utf-8?B?a25aSm8wR3hiY1lqNWYxU1pqdks2bUR0Q2FNekJkVHdkVmdWcmJ1azhlRGRI?= =?utf-8?B?bm1KZyt2M2dxdkV5bFdoWkpPb3p2U2l3eWxCS2t3SU1VQkFIMm15VVU1Q2FK?= =?utf-8?B?cGU3d0ZNejMvU0dVdmwxMVZsV25kZFd2eGNmV0YyeFJXQ1dmTlhTMEZ3U2xs?= =?utf-8?B?WnpBcjJhekIzbU8yRmlFTklBZWsvTzlMY0t2Q0NKS05SNDJnOWJPK1lWOWtM?= =?utf-8?B?V1EyZU13NG5WSTBVcVNudzRnSkt1TlJLLzd6ckFUYUtXN1ZNMXU0TXZpS1lu?= =?utf-8?B?RU5Sa3lmS2Y3cmJRMUtVMGJuOWVLczd1UzgrVjZ0MVdpZHBUSXFzcU9PYVlB?= =?utf-8?B?Q09QZlBKYkhrK0VMNzIzWEdaaEdoTVA1NTRieTVKQkUzbHI2L3BOS1FJVmNL?= =?utf-8?B?MmRKY2VUN05Qems4UHN6d2tRWDhjMHpMZmZEQTJLREllL2ZsS3dTKzl2MHVI?= =?utf-8?B?cnpwY2JpMGJ5R1ZwQlYxMUdDcTZDSW1LWUFqNXhPckllTDJSaHFyTnU2ajRS?= =?utf-8?B?V1JmbVYvMjg3aHVPWjNtZ2VyZXJkR2c5ak9yY21ZU3dKV3NRczg4YllyYVpk?= =?utf-8?B?RmQ5L09VZUdpUm0rOGNIc3h4a2dNcWJDNlNlZC9NMEltbTBPUi8zUHkxUG5v?= =?utf-8?B?Skd2UFlFbjN4L2ZmZDhBSlREZUQ0WDJMLytxdjAxMHZMaEZiaFFsV3Fxa0xS?= =?utf-8?B?SmxNcGhldGZRcVZUbDkrUWttY0JFd2k1Zzg4UFNnZzlnMW1zdjRQUFE5OEdB?= =?utf-8?B?dmxCdHdwQXdtWjJnU0JGMkIxK0tBdEtIMGdzYlAxUks2ZTFTam8rZkx0a3V1?= =?utf-8?B?NGNkZklYVVFNL2ZadGFGKzhYMzh2NW5pTDQ2Q3RyNFl2ODJhVDNiQW56R1hi?= =?utf-8?B?SmVWMGdRbGoxZ0JDVi9CZzlRWGZlak9ObkEvQkNwWUNNeHplZVIxNklINkRj?= =?utf-8?B?WDN3RVBCdUFtU0RxRGdBRzRONWhNYUEzRkFpWjRKS3ZDM0trT2Y3YmVISjEr?= =?utf-8?B?OGM5ODdqM0lKTmRZbUZZNFUyWE5QMlJkRTlWelU3N0VaOWxLY3RCR0djRGJ4?= =?utf-8?B?dlJNckxyRGpXbXA0Z0J1K1VRVnAvQURoZ01HaVE4NDhsV1lzY2s1Z2R6OEtm?= =?utf-8?B?UEIrd1VGaEd5dURvK05JNHZxVkFWekFad29heFNRRUR4c1ZPWVV2cjJYVnNn?= =?utf-8?B?SEVYb3R6VUVrS1V6M01KR1pKd0VXUWROdnozSFAxbW92ZFFScVpEeHJqM1Fi?= =?utf-8?B?S3RLVEV2T1V4NnZZTlZVNDRDQmNHZHl4dngxNWRqOEtpT1daNExwKzdqSjg1?= =?utf-8?B?NzZ6YnY2OXd6NGRqTUIyWXFNaUhPeVppZG84ZmlMNG13Um13NTBBYm1HVE9L?= =?utf-8?B?ZmticFRlWk9MV1ZETld0RituMjRCWEl4d21uQ0QrN0EycEI0bVFmUT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c6aefb1-d552-4135-1f68-08df2406eb1b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:04.2642 (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: 3ClXgeoJzT02GQLyp/pF7wlymeduX7pT+ywakT5X9mtagWuRquqbkooBGNRuxD5eAXQS5udkFI6up2JC/9dq/Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-d62444/1791331625-BEC61757-E9EB88FD/0/0 X-purgate-type: clean X-purgate-size: 6874 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNClhFTiB3aWxsIGNyZWF0 ZSBhbiBJT01NVSBkZXZpY2UgdHJlZSBub2RlIGluIHRoZSBkZXZpY2UgdHJlZQ0KdG8gZW5hYmxl IHRoZSBkb20wIHRvIGRpc2NvdmVyIHRoZSB2aXJ0dWFsIFNNTVV2MyBkdXJpbmcgZG9tMCBib290 Lg0KSU9NTVUgZGV2aWNlIHRyZWUgbm9kZSB3aWxsIG9ubHkgYmUgY3JlYXRlZCB3aGVuIHZpb21t dSBpcyBlbmFibGVkDQp2aWEgS2NvbmZpZyBidWlsZCBvcHRpb25zLg0KDQoiaW9tbXVzIiBwcm9w ZXJ0eSB3aWxsIGJlIGFkZGVkIGZvciBkb20wIGRldmljZXMgdG8gdmlydHVhbA0KSU9NTVUgbm9k ZSB0byBlbmFibGUgdGhlIGRvbTAgbGludXgga2VybmVsIHRvIGNvbmZpZ3VyZSB0aGUgSU9NTVUu DQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxyYWh1bC5zaW5naEBhcm0uY29tPg0KU2ln bmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBhbS5jb20+DQotLS0NCiB4 ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgfCAxMDIgKysrKysrKysrKysrKysrKysr KysrKysrKysrKystDQogeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oIHwgICAxICsN CiAyIGZpbGVzIGNoYW5nZWQsIDEwMSBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQ0KDQpk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jIGIveGVuL2FyY2gvYXJtL2Rv bWFpbl9idWlsZC5jDQppbmRleCBjZDJlMDlmMDA1Li42NTEzMTQwMTMzIDEwMDY0NA0KLS0tIGEv eGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQorKysgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1 aWxkLmMNCkBAIC01NTcsOSArNTU3LDEyIEBAIHN0YXRpYyBpbnQgX19pbml0IHdyaXRlX3Byb3Bl cnRpZXMoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGtlcm5lbF9pbmZvICpraW5mbywNCiAgICAg ICAgICAgICBjb250aW51ZTsNCiAgICAgICAgIH0NCiANCi0gICAgICAgIGlmICggaW9tbXVfbm9k ZSApDQorICAgICAgICAvKg0KKyAgICAgICAgICogRXhwb3NlIElPTU1VIHNwZWNpZmljIHByb3Bl cnRpZXMgdG8gaHdkb20gd2hlbiB2SU9NTVUgaXMNCisgICAgICAgICAqIGVuYWJsZWQuDQorICAg ICAgICAgKi8NCisgICAgICAgIGlmICggaW9tbXVfbm9kZSAmJiB2aW9tbXVfZ2V0X3R5cGUoKSA9 PSBYRU5fRE9NQ1RMX0NPTkZJR19WSU9NTVVfTk9ORSApDQogICAgICAgICB7DQotICAgICAgICAg ICAgLyogRG9uJ3QgZXhwb3NlIElPTU1VIHNwZWNpZmljIHByb3BlcnRpZXMgdG8gaHdkb20gKi8N CiAgICAgICAgICAgICBpZiAoIGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgImlvbW11 cyIpICkNCiAgICAgICAgICAgICAgICAgY29udGludWU7DQogDQpAQCAtMTQ1Nyw2ICsxNDYwLDk1 IEBAIGludCBfX2luaXQgbWFrZV90aW1lcl9ub2RlKGNvbnN0IHN0cnVjdCBrZXJuZWxfaW5mbyAq a2luZm8pDQogICAgIHJldHVybiByZXM7DQogfQ0KIA0KKyNpZmRlZiBDT05GSUdfQVJNX1ZJUlRV QUxfSU9NTVUNCitzdGF0aWMgaW50IF9faW5pdCBtYWtlX2h3ZG9tX3Zpb21tdV9ub2RlKGNvbnN0 IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8pDQorew0KKyAgICB1aW50MzJfdCBsZW47DQorICAg IGludCByZXM7DQorICAgIGNoYXIgYnVmWzI0XTsNCisgICAgdm9pZCAqZmR0ID0ga2luZm8tPmZk dDsNCisgICAgY29uc3Qgdm9pZCAqcHJvcCA9IE5VTEw7DQorICAgIGNvbnN0IHN0cnVjdCBkdF9k ZXZpY2Vfbm9kZSAqaW9tbXUgPSBOVUxMOw0KKyAgICBzdHJ1Y3QgaG9zdF9pb21tdSAqaW9tbXVf ZGF0YTsNCisgICAgZ2ljX2ludGVycnVwdF90IGludHI7DQorDQorICAgIGlmICggbGlzdF9lbXB0 eSgmaG9zdF9pb21tdV9saXN0KSApDQorICAgICAgICByZXR1cm4gMDsNCisNCisgICAgbGlzdF9m b3JfZWFjaF9lbnRyeSggaW9tbXVfZGF0YSwgJmhvc3RfaW9tbXVfbGlzdCwgZW50cnkgKQ0KKyAg ICB7DQorICAgICAgICBpZiAoIGlvbW11X2RhdGEtPmh3ZG9tX25vZGVfY3JlYXRlZCApDQorICAg ICAgICAgICAgcmV0dXJuIDA7DQorDQorICAgICAgICBpb21tdSA9IGlvbW11X2RhdGEtPmR0X25v ZGU7DQorDQorICAgICAgICBzbnByaW50ZihidWYsIHNpemVvZihidWYpLCAiaW9tbXVAJSJQUkl4 NjQsIGlvbW11X2RhdGEtPmFkZHIpOw0KKw0KKyAgICAgICAgcmVzID0gZmR0X2JlZ2luX25vZGUo ZmR0LCBidWYpOw0KKyAgICAgICAgaWYgKCByZXMgKQ0KKyAgICAgICAgICAgIHJldHVybiByZXM7 DQorDQorICAgICAgICBwcm9wID0gZHRfZ2V0X3Byb3BlcnR5KGlvbW11LCAiY29tcGF0aWJsZSIs ICZsZW4pOw0KKyAgICAgICAgaWYgKCAhcHJvcCApDQorICAgICAgICB7DQorICAgICAgICAgICAg cmVzID0gLUZEVF9FUlJfWEVOKEVOT0VOVCk7DQorICAgICAgICAgICAgcmV0dXJuIHJlczsNCisg ICAgICAgIH0NCisNCisgICAgICAgIHJlcyA9IGZkdF9wcm9wZXJ0eShmZHQsICJjb21wYXRpYmxl IiwgcHJvcCwgbGVuKTsNCisgICAgICAgIGlmICggcmVzICkNCisgICAgICAgICAgICByZXR1cm4g cmVzOw0KKw0KKyAgICAgICAgaWYgKCBpb21tdS0+cGhhbmRsZSApDQorICAgICAgICB7DQorICAg ICAgICAgICAgcmVzID0gZmR0X3Byb3BlcnR5X2NlbGwoZmR0LCAicGhhbmRsZSIsIGlvbW11LT5w aGFuZGxlKTsNCisgICAgICAgICAgICBpZiAoIHJlcyApDQorICAgICAgICAgICAgICAgIHJldHVy biByZXM7DQorICAgICAgICB9DQorDQorICAgICAgICAvKiBVc2UgdGhlIHNhbWUgcmVnIHJlZ2lv bnMgYXMgdGhlIElPTU1VIG5vZGUgaW4gaG9zdCBEVEIuICovDQorICAgICAgICBwcm9wID0gZHRf Z2V0X3Byb3BlcnR5KGlvbW11LCAicmVnIiwgJmxlbik7DQorICAgICAgICBpZiAoICFwcm9wICkN CisgICAgICAgIHsNCisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAidklPTU1VOiBDYW4n dCBmaW5kIElPTU1VIHJlZyBwcm9wZXJ0eS5cbiIpOw0KKyAgICAgICAgICAgIHJlcyA9IC1GRFRf RVJSX1hFTihFTk9FTlQpOw0KKyAgICAgICAgICAgIHJldHVybiByZXM7DQorICAgICAgICB9DQor DQorICAgICAgICByZXMgPSBmZHRfcHJvcGVydHkoZmR0LCAicmVnIiwgcHJvcCwgbGVuKTsNCisg ICAgICAgIGlmICggcmVzICkNCisgICAgICAgICAgICByZXR1cm4gcmVzOw0KKw0KKyAgICAgICAg cHJvcCA9IGR0X2dldF9wcm9wZXJ0eShpb21tdSwgIiNpb21tdS1jZWxscyIsICZsZW4pOw0KKyAg ICAgICAgaWYgKCAhcHJvcCApDQorICAgICAgICB7DQorICAgICAgICAgICAgcmVzID0gLUZEVF9F UlJfWEVOKEVOT0VOVCk7DQorICAgICAgICAgICAgcmV0dXJuIHJlczsNCisgICAgICAgIH0NCisN CisgICAgICAgIHJlcyA9IGZkdF9wcm9wZXJ0eShmZHQsICIjaW9tbXUtY2VsbHMiLCBwcm9wLCBs ZW4pOw0KKyAgICAgICAgaWYgKCByZXMgKQ0KKyAgICAgICAgICAgIHJldHVybiByZXM7DQorDQor ICAgICAgICByZXMgPSBmZHRfcHJvcGVydHlfc3RyaW5nKGZkdCwgImludGVycnVwdC1uYW1lcyIs ICJjb21iaW5lZCIpOw0KKyAgICAgICAgaWYgKCByZXMgKQ0KKyAgICAgICAgICAgIHJldHVybiBy ZXM7DQorDQorICAgICAgICBzZXRfaW50ZXJydXB0KGludHIsIGlvbW11X2RhdGEtPmlycSwgMHhm LCBEVF9JUlFfVFlQRV9MRVZFTF9ISUdIKTsNCisNCisgICAgICAgIHJlcyA9IGZkdF9wcm9wZXJ0 eV9pbnRlcnJ1cHRzKGtpbmZvLCAmaW50ciwgMSk7DQorICAgICAgICBpZiAoIHJlcyApDQorICAg ICAgICAgICAgcmV0dXJuIHJlczsNCisNCisgICAgICAgIGlvbW11X2RhdGEtPmh3ZG9tX25vZGVf Y3JlYXRlZCA9IHRydWU7DQorDQorICAgICAgICBmZHRfZW5kX25vZGUoZmR0KTsNCisgICAgfQ0K Kw0KKyAgICByZXR1cm4gcmVzOw0KK30NCisjZW5kaWYNCisNCiBzdGF0aWMgaW50IF9faW5pdCBo YW5kbGVfbm9kZShzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZvLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9k ZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHAybXQpDQpAQCAt MTUyNSw2ICsxNjE3LDEyIEBAIHN0YXRpYyBpbnQgX19pbml0IGhhbmRsZV9ub2RlKHN0cnVjdCBk b21haW4gKmQsIHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQogICAgIGlmICggZHRfbWF0Y2hf bm9kZSh0aW1lcl9tYXRjaGVzLCBub2RlKSApDQogICAgICAgICByZXR1cm4gbWFrZV90aW1lcl9u b2RlKGtpbmZvKTsNCiANCisjaWZkZWYgQ09ORklHX0FSTV9WSVJUVUFMX0lPTU1VDQorICAgIGlm ICggZGV2aWNlX2dldF9jbGFzcyhub2RlKSA9PSBERVZJQ0VfSU9NTVUgJiYNCisgICAgICAgICB2 aW9tbXVfZ2V0X3R5cGUoKSAhPSBYRU5fRE9NQ1RMX0NPTkZJR19WSU9NTVVfTk9ORSApDQorICAg ICAgICByZXR1cm4gbWFrZV9od2RvbV92aW9tbXVfbm9kZShraW5mbyk7DQorI2VuZGlmDQorDQog ICAgIC8qIFNraXAgbm9kZXMgdXNlZCBieSBYZW4gKi8NCiAgICAgaWYgKCBkdF9kZXZpY2VfdXNl ZF9ieShub2RlKSA9PSBET01JRF9YRU4gKQ0KICAgICB7DQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv YXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21t dS5oDQppbmRleCA4NDRjZjM0ZDU2Li41YWUyMTA0MmYwIDEwMDY0NA0KLS0tIGEveGVuL2FyY2gv YXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oDQorKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v dmlvbW11LmgNCkBAIC0yMCw2ICsyMCw3IEBAIHN0cnVjdCBob3N0X2lvbW11IHsNCiAgICAgcGFk ZHJfdCBzaXplOw0KICAgICAvKiBVc2VkIGZvciBkb20wIEVWVFEgYW5kIEdFUlJPUiBpbnRlcnJ1 cHRzICgxLTEgSVJRIG1hcHBpbmcpICovDQogICAgIHVpbnQzMl90IGlycTsNCisgICAgYm9vbCBo d2RvbV9ub2RlX2NyZWF0ZWQ7DQogfTsNCiANCiBzdHJ1Y3QgdmlvbW11X29wcyB7DQotLSANCjIu NDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441836.1659431 (Exim 4.92) (envelope-from ) id 1xEFBf-00031B-FT; Wed, 07 Oct 2026 00:07:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441836.1659431; Wed, 07 Oct 2026 00:07: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 1xEFBf-00030b-AQ; Wed, 07 Oct 2026 00:07:11 +0000 Received: by outflank-mailman (input) for mailman id 1441836; Wed, 07 Oct 2026 00:07:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBc-0002K2-Da for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBb-000T69-QD for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:07 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58cfa-8faa-0a2a0a5109dd-0a2a4509c6b0-38 for ; Wed, 07 Oct 2026 02:07:07 +0200 Received: from [40.107.159.123] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d2b-be1a-0a2a45090019-286b9f7b116a-3 for ; Wed, 07 Oct 2026 02:07:07 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:06 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=jaSB5S1uM7ebrc1sZmvJzD1tebm2b4+9ysCgFDG8PH+ZmXJsdiHkVxqeR/BwhuFg3GAnl0hZ+acDHGDvPhNJXQx+i78sSz2gU3IRaWL0sQAL96NeekYMf/MXDqKYdjoia/ptELR2dfZeuE/dXjN7xw6Uz8hcZfOe1ZVsT00jB8G1NgiZl33la+m6lkXJoUu4q2fb+HUdd4qju8e8/Mkjxd6EO9xD3HmaYQfZ8zpRaPrHAA7XnZ5JW3nl9f8vE7VuoGQlWJSAz6XL6KGCodSCtFWuEGVJjKCTdlhnawin0TXvEi1/XFhn1XuQpNs5WI1XJEqEr99k5DNbciSSuidnsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rGi7QK8sJ6G2H3RYWWAXc6OOMSXEcdq8lHLWXANTsUA=; b=Q/8u1S09mMdY36BaSjmc4SsPV0njfOqOKifHwbgbGpVl1q/NO/0kNBV9EdFNyawXd9sSCmlZKg4mJe5BXjGsfcQbm3NZFySsjDlkoE61nYuAiqB4sXxCwMvsog4BBqMlRccpQmzrZSiopJ5mnMfdj1Uu2ogzFgPyJ37LZ9PUKLA2/pS63LaeUQPts54kj6tY8wo1FiETykrCHAryHp5EeYa/GanWeha6IjXq1fjdIU3zFKgyj0NKjQzhGmP6ynke9Vx9kzL7uWzmU8zQWPSgsFF0Z4iR9m0hjS7vUoKNSNQv4PTsHwElH76FPLp0l9xCALvrXLew2yTMImiML/aGLw== 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=rGi7QK8sJ6G2H3RYWWAXc6OOMSXEcdq8lHLWXANTsUA=; b=vly2Oy9YdKx0UyZyNjLYz2vxr1Ytz28SNB4REeesB2R3uWLywhkHoMPrMsCrMrhbIqksBE367fkdDvym8SLxXyLblO1iQZ+9TOrBK9pU9l1L6k/w5ojKklp3NbGwjAjPKJcEeaq4MscJyl86pbsO9/M+bMN0t+B/6agsBB/L03BHQei/WLtUUG8spuoQTwMZv0eFVn6e5oFmakk9PIo4lf9iQKn+4PkfQmDvgSYMXZErkDAPmJvZiBdcjZoKJbNDrshiWs6ysKGAsTOqz2TBGJnaDOOI+CDrtpIRK04ZJEfDhKAQfiit/pNRXULM4bZ/2nbzBifo0JSRjXI2vfrELA== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Milan Djokic , Luca Fancellu Subject: [PATCH v4 14/22] xen/arm: vsmmuv3: Emulated SMMUv3 device tree node for dom0less Thread-Topic: [PATCH v4 14/22] xen/arm: vsmmuv3: Emulated SMMUv3 device tree node for dom0less Thread-Index: AQHdVe/Jhd313uJS3kSv+TjF+jgGZQ== Date: Wed, 7 Oct 2026 00:07:06 +0000 Message-ID: <1a0f289fdb6f88695852553599f7ad45bcc5a133.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 04520825-e138-4f63-b0cb-08df2406ec2a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: fLNOKbuCJqOkg+6c6Kc0cNJAktfPt1v78njvcogk/mnr2m6SqkxImmwXjV26WWmoCAIIiFH4qOA5HwyAbgg78a8lDfbC6ECmmXU7GVo0OZJs0tXjziZZ7YGICpD2hCPjhd8vxc6N+2IMq0pViAxDv4IS/Lrkhz1o5JHgRM+/KExO/l1kyorKhRV5bvcSLLpgBQtVrtMLc4EZ2wAUKhivg76cE0/dBRbYqZ49DxTLt5c5LZoNAQE1jz/rcS3cZxvRTlAgmYN1SP69eOtwBOeop2XUHRLWbHXhxFlTSKYjPTrAWGsJYOKii7bczgL6HtRUKDwyOX8JqZa/TbAA1A2K3H4/7ueCPULRO7Z0xdgOmFCyClcEYmjcuszr6EEZDmpFhnX2JFhGvLN5JAJolQui4dmfY58G3XWqLyeVsbYBC4xaWwZyupfGhjRenzmKBAgHj757SmBfI/wFHBBYeiUKCxw7dARJz+cTA6AW1SGKrlfNdpZlh4+MLoCeJuJzNUpoY0p2oiwkt/giPO167oxmTxaIskHuavTdS9Zqb8D5sQZhoiw+NxLOOKFlgyoBIE/04r80EvrMVsoXIVyjKG4VOh85OdV0HeU5ChKZkcpsXle03UP+d8UHHzBjnV3BiJjWortuHMy43a61mBtBzicgnaDKti3menqoOPzmLEkhNG5An3gJBmZVgw3Cnz5KC3GN75MhcXayPyblWZLIfEJ7rynJGhuQtmqfe5cLx2Oqs74= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bXpjYmp4Q25uME9nb0pvZmVHYWpUbWJ6ejlhWnhEemlOMkk4L0NaeUZGR0R5?= =?utf-8?B?R04weGI3YkRnMjBQQmM3TStDb0xQYlJTaktNVnp0S3BtcUhyRkRHZmJhR3dQ?= =?utf-8?B?K0dEVitBVDhPRTFJUzVrNXBaNXk2Ymp6TUlGTy9xWUNucWNYeWlvUWFRYkM2?= =?utf-8?B?MXhiYUNvTGVXUHQ2eSt1anl0KzVwaUNFRjJqN1l0eUVGbS9pUHlacmhjNk44?= =?utf-8?B?OExVUGY5OHdDOTM0eHVkRk1qYjRMQzZvRnNFSU1pUFVlOFczVW8wZ3RCNkl4?= =?utf-8?B?czVOTkhRT3JlWGluc0UzUnF4U2xaV2NkMjZnMFBMeGFZekxnQlF1ZW91dDlF?= =?utf-8?B?SUpQUmRveUVrajBBRSs1THV4WVJDZ21rWndIU2NNMWhlVXBwazg5b0RzamFj?= =?utf-8?B?RXBQRlJwcmRXU0IzY0JqSUNUVDdDc1daTSsyd25ud3Y2ek9veGJ4cVoxVkNP?= =?utf-8?B?d0dNOEY2MnYwalpOOSs3OXJoL2VlNXFyblZhLzF3V1NZdFZuZWc3eGN6d3Y0?= =?utf-8?B?M3dwbXhNcFV0Y0YyVm9vd2pmci9uRlpCL0t0VGFJanNvL29UZjEyOHJ5NHNQ?= =?utf-8?B?azhYYnRlR0s4dENPa1k1VHRaTHFZQlJTSDRQbHN1Y1NlWDU0RUVPeklCTFpK?= =?utf-8?B?Sk93djd5MjE4TlVkRjEvTGdMa2JJaXErQmxnbUxrRjJqTUtFSE9SMFFpSEF4?= =?utf-8?B?L0RWeW9oR0NXZVJNd1NJTGZjNXV0aXIzUHFtWENBa0IvQlJQckk1TnZzODFh?= =?utf-8?B?WUVNa2RiZ0J3R0dDSDczVmg2em9HNU5lazdpdW9idXd0WEhVZ0VpSnRuUlhE?= =?utf-8?B?S3ZaMUZKUUxlWG9relpRUGNtNzM2bVJGTy9nQ3ZzTGJyUmluamdNeEZSSWwx?= =?utf-8?B?RmFHSXMrSFB2aVdZOFR6NmVDY3BpMTkwSEJZSHRxNVFKS1VHNFZFMzhjRXVu?= =?utf-8?B?VmNqSEZ0TjZtMGxZRVVvRTdqbWZORVFjOUZBbjRGNG5GZlRDYU9SdmJMeHha?= =?utf-8?B?emcxNkxhN0RkeUxYdU1BM0NaVVJOWXhleXJ3dzFmUXlLeWJ2QkFkVDBnMVp6?= =?utf-8?B?UldCTEdtTnNQa2tRUVllUzRMMHFNWVRvZlNURUppaklrYTc1c0dsMUIzQ2d0?= =?utf-8?B?WUpSa2tWMEs5VmFYekszK0hTdDBZNVlDQWdLbUM5SVUyQVdtRTV3VThsa0o1?= =?utf-8?B?anhMU2taQ1ZGNkQ1S1oyTzdDT0Z5ZGF3VjVMSWdXd0hiK1RxbUJYeGpGb29v?= =?utf-8?B?TjNXVlFCODdmd1ZzQUZXazR2cy9ESzA4ZzBJek1RQURXSHFQU3RXMEtOTnNH?= =?utf-8?B?bUtRc0VacisyQk0rMFh4T3Z5cEpKcnJXVTZRMXk2di9aSmdUTHpxdkdZTDlO?= =?utf-8?B?RnhTTUt0S05hR2RYRG44OUt3dGd6WFk0NWlwUnc0T1NnTGYvYVJ5bnRpdWhU?= =?utf-8?B?MWpSQ3ptVHhmczBzK1dqaUptSUZrYXVlY3hJVENvWUtwV0NIS2xMY1JYTGE1?= =?utf-8?B?ODgvWGVrUkhHbU1rT1BHMXczSE12OUV3T1UzTFN3cVgzaHFYWElOZ09QNktZ?= =?utf-8?B?TVhsM2JhRW03L3R4OTRja0tGeG0xOWJEY0F1WkhhbU1IRUhPeUVGWXk0Wnpq?= =?utf-8?B?N2RUdDAvZExCSXpEL0w2R0ZWUy9yYWZYN2wxRnNnUXNHaTRyS2I0Z3YwcGlw?= =?utf-8?B?aVlDMWhlS001SUpXSUZDRUJ3anZVYXZYSjU5dTdtM1UydzRTcTZ1WFh6QUt0?= =?utf-8?B?c0Mwdkt5Zk9hUzRKSHFQdWY5dFZuNzVJSXF3TUJuOTFYWm5JeG1ZaS91RUVT?= =?utf-8?B?QU9iYW42M1AzYVgwKzJLY3dUS01DczNrR1pNb1Fna2tmM3gyWktxN2sydi9p?= =?utf-8?B?dGNheCtFcTN2VUVHM0d6Q08zdEFRRGFqcWRKL29qK1VUc0VaNm56SVJweW5C?= =?utf-8?B?UkNLcEtsSVhVQStialJlV2NocGFsM21Mb3hHWXM1SHI2ZFBnOVBsMEJEcGV5?= =?utf-8?B?RWZ3a0ZOa2dpcHZ5WGhSNzBYRHFUMDJydU9vVVJ5UVlJWjk4OEUvMUhGMUtq?= =?utf-8?B?Y2xRa3JTSzFLenhTemtHeS9URk4ySmdsSlB3bFowVVNGcU1jdzVLQXdMc2hV?= =?utf-8?B?MjVoaW4vV0c3S2ZEQy9qVmJzL3VoSUJpMlE5OXdaVmxXckIxRG9XNGpaZVFS?= =?utf-8?B?d0VaS0xaQUpFRmF6SlI1Z1dLbS8vNUtwY0haTG1qS3pLMzJZSjFCNXNoQm1Q?= =?utf-8?B?TTVGcXd2RVovZGNBR2J1cDl6aCt2WG5JYk1KcUxmcysyNjl0ZGpjNTVCeVht?= =?utf-8?B?T1VrT28xTUFucXJWQWJCMjhyRzNkd1RtUnlOeDR0WWFyaUZRKzNEZz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 04520825-e138-4f63-b0cb-08df2406ec2a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:06.0269 (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: AoDj6tRTOzCa0nkse4jIOlucyyJoB6QtkzGtM5zHJEUVJJhwg0gnOSKbaPH89TPUz/lTe+auaJ5pyLUmp6NnZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-bad1c0/1791331627-3B8D1034-843649A5/0/0 X-purgate-type: clean X-purgate-size: 4074 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNClhFTiB3aWxsIGNyZWF0 ZSBhbiBFbXVsYXRlZCBTTU1VdjMgZGV2aWNlIHRyZWUgbm9kZSBpbiB0aGUgZGV2aWNlIHRyZWUN CnRvIGVuYWJsZSB0aGUgZG9tMGxlc3MgZG9tYWlucyB0byBkaXNjb3ZlciB0aGUgdmlydHVhbCBT TU1VdjMgZHVyaW5nDQpib290LiBFbXVsYXRlZCBTTU1VdjMgZGV2aWNlIHRyZWUgbm9kZSB3aWxs IG9ubHkgYmUgY3JlYXRlZCB3aGVuIGNtZGxpbmUNCm9wdGlvbiB2c21tdXYzIGlzIGVuYWJsZWQu DQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxyYWh1bC5zaW5naEBhcm0uY29tPg0KU2ln bmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBhbS5jb20+DQpSZXZpZXdl ZC1ieTogTHVjYSBGYW5jZWxsdSA8bHVjYS5mYW5jZWxsdUBhcm0uY29tPg0KLS0tDQogeGVuL2Fy Y2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMgICAgICAgICB8IDUzICsrKysrKysrKysrKysrKysrKysr KysrKysrKw0KIHhlbi9pbmNsdWRlL3B1YmxpYy9kZXZpY2VfdHJlZV9kZWZzLmggfCAgMSArDQog MiBmaWxlcyBjaGFuZ2VkLCA1NCBpbnNlcnRpb25zKCspDQoNCmRpZmYgLS1naXQgYS94ZW4vYXJj aC9hcm0vZG9tMGxlc3MtYnVpbGQuYyBiL3hlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jDQpp bmRleCBmODc0Mzc5MTVlLi5mY2U5Y2RiZWY1IDEwMDY0NA0KLS0tIGEveGVuL2FyY2gvYXJtL2Rv bTBsZXNzLWJ1aWxkLmMNCisrKyBiL3hlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jDQpAQCAt MjE4LDEwICsyMTgsNjMgQEAgc3RhdGljIGludCBfX2luaXQgbWFrZV92cGwwMTFfdWFydF9ub2Rl KHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8pDQogfQ0KICNlbmRpZg0KIA0KKyNpZmRlZiBDT05G SUdfVklSVFVBTF9BUk1fU01NVV9WMw0KK3N0YXRpYyBpbnQgX19pbml0IG1ha2VfdnNtbXV2M19u b2RlKGNvbnN0IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8pDQorew0KKyAgICBpbnQgcmVzOw0K KyAgICBjaGFyIGJ1ZlsyNF07DQorICAgIF9fYmUzMiByZWdbR1VFU1RfUk9PVF9BRERSRVNTX0NF TExTICsgR1VFU1RfUk9PVF9TSVpFX0NFTExTXTsNCisgICAgX19iZTMyICpjZWxsczsNCisgICAg dm9pZCAqZmR0ID0ga2luZm8tPmZkdDsNCisNCisgICAgc25wcmludGYoYnVmLCBzaXplb2YoYnVm KSwgImlvbW11QCVsbHgiLCBHVUVTVF9WU01NVVYzX0JBU0UpOw0KKw0KKyAgICByZXMgPSBmZHRf YmVnaW5fbm9kZShmZHQsIGJ1Zik7DQorICAgIGlmICggcmVzICkNCisgICAgICAgIHJldHVybiBy ZXM7DQorDQorICAgIHJlcyA9IGZkdF9wcm9wZXJ0eV9zdHJpbmcoZmR0LCAiY29tcGF0aWJsZSIs ICJhcm0sc21tdS12MyIpOw0KKyAgICBpZiAoIHJlcyApDQorICAgICAgICByZXR1cm4gcmVzOw0K Kw0KKyAgICAvKiBDcmVhdGUgcmVnIHByb3BlcnR5ICovDQorICAgIGNlbGxzID0gJnJlZ1swXTsN CisgICAgZHRfY2hpbGRfc2V0X3JhbmdlKCZjZWxscywgR1VFU1RfUk9PVF9BRERSRVNTX0NFTExT LCBHVUVTVF9ST09UX1NJWkVfQ0VMTFMsDQorICAgICAgICAgICAgICAgICAgICAgICBHVUVTVF9W U01NVVYzX0JBU0UsIEdVRVNUX1ZTTU1VVjNfU0laRSk7DQorICAgIHJlcyA9IGZkdF9wcm9wZXJ0 eShmZHQsICJyZWciLCByZWcsDQorICAgICAgICAgICAgICAgICAgICAgICAoR1VFU1RfUk9PVF9B RERSRVNTX0NFTExTICsNCisgICAgICAgICAgICAgICAgICAgICAgIEdVRVNUX1JPT1RfU0laRV9D RUxMUykgKiBzaXplb2YoKnJlZykpOw0KKyAgICBpZiAoIHJlcyApDQorICAgICAgICByZXR1cm4g cmVzOw0KKw0KKyAgICByZXMgPSBmZHRfcHJvcGVydHlfY2VsbChmZHQsICJwaGFuZGxlIiwgR1VF U1RfUEhBTkRMRV9WU01NVVYzKTsNCisgICAgaWYgKCByZXMgKQ0KKyAgICAgICAgcmV0dXJuIHJl czsNCisNCisgICAgcmVzID0gZmR0X3Byb3BlcnR5X2NlbGwoZmR0LCAiI2lvbW11LWNlbGxzIiwg MSk7DQorICAgIGlmICggcmVzICkNCisgICAgICAgIHJldHVybiByZXM7DQorDQorICAgIHJlcyA9 IGZkdF9lbmRfbm9kZShmZHQpOw0KKw0KKyAgICByZXR1cm4gcmVzOw0KK30NCisjZW5kaWYNCisN CiBpbnQgX19pbml0IG1ha2VfYXJjaF9ub2RlcyhzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZvKQ0K IHsNCiAgICAgaW50IHJldDsNCiANCisNCisjaWZkZWYgQ09ORklHX1ZJUlRVQUxfQVJNX1NNTVVf VjMNCisgICAgaWYgKCB2aW9tbXVfZ2V0X3R5cGUoKSA9PSBYRU5fRE9NQ1RMX0NPTkZJR19WSU9N TVVfU01NVVYzICkNCisgICAgew0KKyAgICAgICAgcmV0ID0gbWFrZV92c21tdXYzX25vZGUoa2lu Zm8pOw0KKyAgICAgICAgaWYgKCByZXQgKQ0KKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0K KyAgICB9DQorI2VuZGlmDQorDQogICAgIHJldCA9IG1ha2VfcHNjaV9ub2RlKGtpbmZvLT5mZHQp Ow0KICAgICBpZiAoIHJldCApDQogICAgICAgICByZXR1cm4gLUVJTlZBTDsNCmRpZmYgLS1naXQg YS94ZW4vaW5jbHVkZS9wdWJsaWMvZGV2aWNlX3RyZWVfZGVmcy5oIGIveGVuL2luY2x1ZGUvcHVi bGljL2RldmljZV90cmVlX2RlZnMuaA0KaW5kZXggOWU4MGQwNDk5ZC4uNzg0NmEwNDI1YyAxMDA2 NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kZXZpY2VfdHJlZV9kZWZzLmgNCisrKyBiL3hl bi9pbmNsdWRlL3B1YmxpYy9kZXZpY2VfdHJlZV9kZWZzLmgNCkBAIC0xNCw2ICsxNCw3IEBADQog ICovDQogI2RlZmluZSBHVUVTVF9QSEFORExFX0dJQyAoNjUwMDApDQogI2RlZmluZSBHVUVTVF9Q SEFORExFX0lPTU1VIChHVUVTVF9QSEFORExFX0dJQyArIDEpDQorI2RlZmluZSBHVUVTVF9QSEFO RExFX1ZTTU1VVjMgKEdVRVNUX1BIQU5ETEVfSU9NTVUgKyAxKQ0KIA0KICNkZWZpbmUgR1VFU1Rf Uk9PVF9BRERSRVNTX0NFTExTIDINCiAjZGVmaW5lIEdVRVNUX1JPT1RfU0laRV9DRUxMUyAyDQot LSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441843.1659439 (Exim 4.92) (envelope-from ) id 1xEFBi-0003SY-6b; Wed, 07 Oct 2026 00:07:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441843.1659439; Wed, 07 Oct 2026 00: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 1xEFBi-0003SC-2f; Wed, 07 Oct 2026 00:07:14 +0000 Received: by outflank-mailman (input) for mailman id 1441843; Wed, 07 Oct 2026 00:07:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBg-0003Bc-H1 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBf-00Bv1m-Tz for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58ced-e002-0a2a0a5209dd-0a2a4502bac0-46 for ; Wed, 07 Oct 2026 02:07:11 +0200 Received: from [52.101.66.102] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d2f-6ca4-0a2a45020019-34654266bce3-3 for ; Wed, 07 Oct 2026 02:07:11 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:10 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=QRXkLvzhvDdzbH5DGzy3B/xHUvrAYoD3CSRh/2R8fZbHTMSSODbRglgrM+ib+9eHVyheHgQU4G21gKu84PrB/bd/PbVIKG7NnHaB+no57m7bWr2Q2qNeA5Lw2D33GcjYJBfmW96Of8hNlhbnW8qj6iQCybJd7LC9RxyNKelvVPwCcDVnwtdcdamNxSk/lKqeoEv/OMJUeTnY8K7xWAsaAqkDniOTrj9XnajN+68/4KuA95B9mDo3ddHhOsJ7sii7T4rvJXBsqV27LYMRsFocuijCdqbngJ4QTZVYAvZ7GCXOywKfbQvwsEDlWfG/t9H2Nk7P9kuq1cjbrMf0zLwUSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T6MJ1og6BqUCTCvh0lfZhoDbYWXVkuu3ay1bA+0mw50=; b=BE4ME0ktNiMylI7kPDu2mfPNHfNuzshj+hASa/pXK+8/hZ3La2bBbK6WObYlYP7t7SziESBSLqoiCu1oRDifCcQuAuTzPk2jfx6ILJMpkOjfjNSEuN3HvvA+AncIY82dicNXx17C0m2/7z4cyC4cuA2vI/dLOYqQPkf1ggSvGKELkWWt0fL3X5XAifMDswyY3ifqruNSNAxL2ZdrS/ffrYpnBdsXSHrmpKorflTOAEfRnXZtXNIihnD4DB/r4NnsLRBzAxi8H5rBTqZf9wyMvi40NUBw+EbyxN1HtkywwJgXhQasZVHunGQCwkxx42L52ozeNvBJUWW0qagpsurGHw== 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=T6MJ1og6BqUCTCvh0lfZhoDbYWXVkuu3ay1bA+0mw50=; b=g0BSzZS211ZXKmfV4YPCD0eycwHrmUFZh7QYZI1nv+rN089SP8nlTRxZMlA/fo8WcGA/EcD/t+VVibiN6Z8es3JTqpcoU9xP/p7ef0R1rXb8iMLz0N3vAKxV9TWz1PYd4rNibJOKezyPR4xUvmKDAD0Kp0iAUc+3snZtCXTzr7ryp+tp+UW+IY3Fvsso4EbULJQah5z5VnfZ7jzIOyNnnnT+FkGDZf9jiwUBk0eEf549P5sAk5sGCnopESQ5G+b1ybSWE8GqigMpyVTCTW4C+DSvVpevq5fReB3Ha8wbFOAA1wi8r3LkrF3GYZ5UQYRhG/puGBGhpAhpuucwTQ9bzg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Anthony PERARD , Juergen Gross , Milan Djokic Subject: [PATCH v4 15/22] arm/libxl: vsmmuv3: Emulated SMMUv3 device tree node in libxl Thread-Topic: [PATCH v4 15/22] arm/libxl: vsmmuv3: Emulated SMMUv3 device tree node in libxl Thread-Index: AQHdVe/MdypByIea/k+xZJowEVhBGQ== Date: Wed, 7 Oct 2026 00:07:10 +0000 Message-ID: <34d557ae4a5c1fa7f29b55d96ee4517cf8c3027c.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: de5f0e25-f2e8-49e9-cb50-08df2406ee92 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: kia+f/YwWcN1kpwMcuy7swsAiBwB36GbjY9lIquwNHm4ht1ZGzoIGeT6haNlY3Pv/UDJI12hMPP+sh+CYDJz2Np3flyk4smP6EZnu3r66YeM0gEI1Ch0CaVFzMzupsVSAZcuikVDJdf4gFWuOwFkK1bPS/VlQY9lJGNjDARtTiyavHgoeTw9388bq3W7R52UC0lhw+PT4qMCOaHJVDZnmce6h6LKCENzlQhlWZGrNd3aJ8O9TuUv2dMURGWwD2K20FEX97ArU1mSwnuO7MBieuSVf1BX6t0GGQYsB9XweZ/i16hhfsW1TajYzVWF0QT7Qa2GrFSWqmZFcqxDpGIOhBsoZk2aIeW1ISxZDiWLNwM7B7CXoEDucB083Saj17EWTuiqaLA3R4J5Y6iNEzDfT1jEW3A9YqWyyyEy3VxAQ4io1/t9VcwWhQ9XPutMrqNn6N29YL/EhRJ51XdlS9ysaps2gbbGDIiQOHtreF2r8DGDydHJl+KfvpbeWrnQEXnnARtiT5ly7ymrgQQ6zvwwtwu+d6qnJ6yK/rFk4rdadEuD6mGNZeXvafm1a8pwkei4Ca27aF255Ot15x6iOcdWUQNwnY3AowvolCxVaF41o2gcNQ8P6FDliopZM1+I27S9Dsyd6nLzV5Fcm6fF+nCbgG5lFsn4WRXw8ChtKClHGv2+Gqhr6m9XALFYXKDKZDRMXT0voO3hk22209E878KLjdA6R/uIGSBJ+o+FELFl56A= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TjU5akNVOEs0T25NdlhmRmo4Zzhla1hyeXFwVEtxUWNqcHBBQ3A5QWZqVVMx?= =?utf-8?B?MkFxVjB2bGJxUTR2NzU5NWU0K2FnK0J6cW5Pd0FvdFVCVktBMGdNUVdpKzFh?= =?utf-8?B?Q0pUK0pic1ArZnY4NCsxUFdmZHRmWGwrSC8zaWtMS1lLNFZaeU0wZTVROFFI?= =?utf-8?B?U2FycEZaUzFZcVJ3TkJreGY3VGtpLzY5T0ZkOVJpMmlwVnZjRW1Qdkl5UHZF?= =?utf-8?B?QWd3TEtEWmRCVHdtaHZJcG1paUpIbTlsL3pWUnZmb0t2WGVCY0JsQ2lqNC95?= =?utf-8?B?UkY5YlpBc1BqSWcyR0dXcEJDUGVaU3NGN1BQUW5zT0Q2MjR4eFhhWnV2c2JE?= =?utf-8?B?emNyUjMxYm5jN0JybW5sam9GR3kzNXh0VmlGZUF5SUFwYmJjMEdQaVBKTWNs?= =?utf-8?B?SU9HcWpTbVhuK0lyVzFYa2NJMHA5MTlscWFGTExDZjFqTzJQY3o2cFVtQUVp?= =?utf-8?B?WTQvNDQ5SlFNc21meFFWdVJFMDE2T0tCTlpyOUpLUVNJbmp0Z2M2OXJ5V1gr?= =?utf-8?B?MXBtazlmNHliZ290U1RZb1dndlBkT3RRWlh1RG55MEl3OW1KcUhUZE9HMmFB?= =?utf-8?B?bm5Wa25VV0lWQXgrV0RHQkErTVhwZkRnMFZFV3hlWnJINkY5TDhsUlhwYktm?= =?utf-8?B?blk0bW93RndWako0V3d2bzRFcVVLSDB0R0VtaUVDdmxVQVloU2xreERJY0t6?= =?utf-8?B?ZHNERXJZRllBWi9UdTNkZDY0UmFLcHluL25aVzlyeVZ1SDZPcHNpMkxGYmZW?= =?utf-8?B?VEIrclBwVjhLM1BzN3V5RytFUUJSb0RqQ1FPNHNFUE5IWDc3clBjb00ybVRm?= =?utf-8?B?OHFFVXNqVE51Uk5zaG90Z1VyQ0lTalJ3NlpuUlFsQlBvMGdIMldpL25jQjhm?= =?utf-8?B?Wkd4TjlBdXFRVGlxdmZwNnBIL3dpbzNnbkZwWFZRM2tlbnpLUFRFL2xuV1E0?= =?utf-8?B?MDNsaW13ZHBvT1FCbG9lTUQ2VytSSHNTVHYrZmJ6RTU4ak4zUWtHd1QxdFRF?= =?utf-8?B?b3cxQUlraFdDd1ppdDJESUpOaVNCT0lWaTNZUE5uNkQrY1NmblA4VEFRMzEx?= =?utf-8?B?eXFxb2hrYjR0djBxZWRBS29DNi9UYjJUR0I5ZTFwQnVKa3B3M0laeTcrT0M1?= =?utf-8?B?bk1XK0w4RXJZWEI3YThOanV6Qm5MMzk0ckcyYlFtMm9ESzJZcWF3TVU3eks1?= =?utf-8?B?L3dPaEFMYmtyaWsvbUJMY0hYR0xCL3hBUnNqL3l6SE5qckJsdFNFVDJqaDNY?= =?utf-8?B?YWdjMlNuVWZ2TUtqZWNxUzFacVlrSHYyZlA2TityNVJsSHF0V2wvTHJOMnFr?= =?utf-8?B?b0R3WitsNU5HQ25vb1I5THFYeFF4MUowbWJ2NUNjNkRjVnAzWEswVEgxTTJC?= =?utf-8?B?Y0JOU1Bkd09TSEwvRWhhejhIaXZVNjFNa21LNjNta3ZpSEtzVDRZYURrRkts?= =?utf-8?B?RmF6a1VjSTdsU0JNQmJOaWZyeGJRR21zRUFOWVNMbTA3SDhuUHBMZ05EMUtX?= =?utf-8?B?OU51ZWgvRWdNS2ExcUdmSUtDSy9SWVVZWHRZQ2wraUZjNkZSc29UdG5QOUVz?= =?utf-8?B?eGZYaTR0RU5CT1UyazV2REZYSVZrbEZMM255R2lkSUdxUFlWcnZyQmc5WDAy?= =?utf-8?B?Zi9qUnBCQmFrSWdOV3FBZy9CNWwzMSt5WmFRTWJubnRvWHRMNHp6N0R6TFQv?= =?utf-8?B?bngvRThZbm9TUzhHaTJ0bWlmUzdsYmpJRHhYMFo5YXV3Nmw5U09vWEE1Z0FW?= =?utf-8?B?MlN4QUp1WE5qRkRjdWlkdm56azVaeUhtTmJYVjBXMGNpL1VQWU85VDBXd3FQ?= =?utf-8?B?eWpOUEZDajJrKzFtdFh3SFhhQUZpdm5PY0NsRjlQVDhTVXdBeWN4U21sdUVM?= =?utf-8?B?S3c2bjRKWTFsNlZzTVpyWUcrbTM3NlB3anFzRmtPbG9SVmtVc3VxdzFaNTY1?= =?utf-8?B?RWFLekJKd3RPRE5RNkg0UW0wYUxBNjdrVFkyeEpPT3hxZDFQaWIzZUgrdVZJ?= =?utf-8?B?ODNtOTM1WDlSdDNZMnR4bzM0MG8rck9FWVdrenlwclhPWmF6NGdub3lwRC9t?= =?utf-8?B?a2hSYzREWTg3RWhpUEJtSkVHck1Ma25BNnFYdnUyVjVTaXFRQjV6UDF3SWpY?= =?utf-8?B?eStTUzVQQWtFZUtlRldGSk85TUMyZU13dHd2ZTVQMXZMUDZ3QytETWtzTkNF?= =?utf-8?B?OWhpaHhrVFI3V0hpVDRiVmI1aE1wSEwza0FzS0pMeXBwSXNWeEhJeVJWNFd0?= =?utf-8?B?SmU4S09Ub3lYekRjOFYwMkszcG1hSm1mb0lXMnd4UnBiQ2k3M09CK0lGRGxF?= =?utf-8?B?bVJ5SGJ1ZFlNb2xSUHB3SmRxdUhwakZPMFdHajk5aUJlSVFRQ1hpdz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de5f0e25-f2e8-49e9-cb50-08df2406ee92 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:10.0660 (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: lHTn/kVVrltz/J2FLAwFtoiRL2RFf35pApifEo8IGMG1DGh9L8eW+IX86EwwsbE37fn5++q66FzxpbjKGz/hdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-720697/1791331631-317CA2AC-E0392EAF/0/0 X-purgate-type: clean X-purgate-size: 3142 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCmxpYnhsIHdpbGwgY3Jl YXRlIGFuIEVtdWxhdGVkIFNNTVV2MyBkZXZpY2UgdHJlZSBub2RlIGluIHRoZSBkZXZpY2UNCnRy ZWUgdG8gZW5hYmxlIHRoZSBndWVzdCBPUyB0byBkaXNjb3ZlciB0aGUgdmlydHVhbCBTTU1VdjMg ZHVyaW5nIGd1ZXN0DQpib290Lg0KDQpFbXVsYXRlZCBTTU1VdjMgZGV2aWNlIHRyZWUgbm9kZSB3 aWxsIG9ubHkgYmUgY3JlYXRlZCB3aGVuDQoidmlvbW11PXNtbXV2MyIgaXMgc2V0IGluIHhsIGRv bWFpbiBjb25maWd1cmF0aW9uLg0KDQpTaWduZWQtb2ZmLWJ5OiBSYWh1bCBTaW5naCA8cmFodWwu c2luZ2hAYXJtLmNvbT4NClNpZ25lZC1vZmYtYnk6IE1pbGFuIERqb2tpYyA8bWlsYW5fZGpva2lj QGVwYW0uY29tPg0KLS0tDQogdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYyB8IDMzICsrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIDEgZmlsZSBjaGFuZ2VkLCAzMyBpbnNlcnRp b25zKCspDQoNCmRpZmYgLS1naXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jIGIvdG9v bHMvbGlicy9saWdodC9saWJ4bF9hcm0uYw0KaW5kZXggYTI0ODc5MzU4OC4uMTIwN2I2MjBmYSAx MDA2NDQNCi0tLSBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMNCisrKyBiL3Rvb2xzL2xp YnMvbGlnaHQvbGlieGxfYXJtLmMNCkBAIC05MDEsNiArOTAxLDM2IEBAIHN0YXRpYyBpbnQgbWFr ZV92cGwwMTFfdWFydF9ub2RlKGxpYnhsX19nYyAqZ2MsIHZvaWQgKmZkdCwNCiAgICAgcmV0dXJu IDA7DQogfQ0KIA0KK3N0YXRpYyBpbnQgbWFrZV92c21tdXYzX25vZGUobGlieGxfX2djICpnYywg dm9pZCAqZmR0LA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGFy Y2hfaW5mbyAqYWluZm8sDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGNf ZG9tX2ltYWdlICpkb20pDQorew0KKyAgICBpbnQgcmVzOw0KKyAgICBjb25zdCBjaGFyICpuYW1l ID0gR0NTUFJJTlRGKCJpb21tdUAlbGx4IiwgR1VFU1RfVlNNTVVWM19CQVNFKTsNCisNCisgICAg cmVzID0gZmR0X2JlZ2luX25vZGUoZmR0LCBuYW1lKTsNCisgICAgaWYgKHJlcykgcmV0dXJuIHJl czsNCisNCisgICAgcmVzID0gZmR0X3Byb3BlcnR5X2NvbXBhdChnYywgZmR0LCAxLCAiYXJtLHNt bXUtdjMiKTsNCisgICAgaWYgKHJlcykgcmV0dXJuIHJlczsNCisNCisgICAgcmVzID0gZmR0X3By b3BlcnR5X3JlZ3MoZ2MsIGZkdCwgR1VFU1RfUk9PVF9BRERSRVNTX0NFTExTLA0KKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICBHVUVTVF9ST09UX1NJWkVfQ0VMTFMsIDEsIEdVRVNUX1ZTTU1V VjNfQkFTRSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgR1VFU1RfVlNNTVVWM19TSVpF KTsNCisgICAgaWYgKHJlcykgcmV0dXJuIHJlczsNCisNCisgICAgcmVzID0gZmR0X3Byb3BlcnR5 X2NlbGwoZmR0LCAicGhhbmRsZSIsIEdVRVNUX1BIQU5ETEVfVlNNTVVWMyk7DQorICAgIGlmIChy ZXMpIHJldHVybiByZXM7DQorDQorICAgIHJlcyA9IGZkdF9wcm9wZXJ0eV9jZWxsKGZkdCwgIiNp b21tdS1jZWxscyIsIDEpOw0KKyAgICBpZiAocmVzKSByZXR1cm4gcmVzOw0KKw0KKyAgICByZXMg PSBmZHRfZW5kX25vZGUoZmR0KTsNCisgICAgaWYgKHJlcykgcmV0dXJuIHJlczsNCisNCisgICAg cmV0dXJuIDA7DQorfQ0KKw0KIHN0YXRpYyBpbnQgbWFrZV92cGNpX25vZGUobGlieGxfX2djICpn Yywgdm9pZCAqZmR0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGFy Y2hfaW5mbyAqYWluZm8sDQogICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGNfZG9t X2ltYWdlICpkb20pDQpAQCAtMTQwOCw2ICsxNDM4LDkgQEAgbmV4dF9yZXNpemU6DQogICAgICAg ICBpZiAoZF9jb25maWctPm51bV9wY2lkZXZzKQ0KICAgICAgICAgICAgIEZEVCggbWFrZV92cGNp X25vZGUoZ2MsIGZkdCwgYWluZm8sIGRvbSkgKTsNCiANCisgICAgICAgIGlmIChpbmZvLT5hcmNo X2FybS52aW9tbXVfdHlwZSA9PSBMSUJYTF9WSU9NTVVfVFlQRV9TTU1VVjMpDQorICAgICAgICAg ICAgRkRUKCBtYWtlX3ZzbW11djNfbm9kZShnYywgZmR0LCBhaW5mbywgZG9tKSApOw0KKw0KICAg ICAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fZGlza3M7IGkrKykgew0KICAgICAg ICAgICAgIGxpYnhsX2RldmljZV9kaXNrICpkaXNrID0gJmRfY29uZmlnLT5kaXNrc1tpXTsNCiAN Ci0tIA0KMi40My4wDQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441850.1659448 (Exim 4.92) (envelope-from ) id 1xEFBl-00040O-Qt; Wed, 07 Oct 2026 00:07:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441850.1659448; Wed, 07 Oct 2026 00:07: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 1xEFBl-0003zR-LF; Wed, 07 Oct 2026 00:07:17 +0000 Received: by outflank-mailman (input) for mailman id 1441850; Wed, 07 Oct 2026 00:07:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBk-0003su-Ew for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBj-007ODb-Rt for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:15 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d33-e002-0a2a0a5209dd-0a2a4507a862-2 for ; Wed, 07 Oct 2026 02:07:15 +0200 Received: from [40.107.159.140] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d33-b4ea-0a2a45070019-286b9f8c3197-3 for ; Wed, 07 Oct 2026 02:07:15 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:13 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=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=b3/7o/zLPsUU1nCRWLcGFDJPb55m078pfX+93U5sLzbRaBzgcfSE/h3aNZn9yz98vx0omm8wuR5otsUPGJhpM5P8JqMnRtMIRIBI4aEmrPEsIrJe8enHPJfQYemjdrqMeUuf9FzL58ktaaaBjN5WkHHOeWOmvxsY4X3aIzVGk1yxmCnn9c/B1pneqvmAvNKBgfAtJxIhDk2MbkffhAVWTGPlcR8Ho/WO5CuW/oz/ju2cbtJexW8BGG/ozTLX185CyVJKZXAePnVcwPDsaJecIawA1OXueDsRhPI1i9iCYnO20EL7EHr+9YLn5v162g0ocdcghsT2oFx4qixjDzqw2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+RBjyGHKMyCDE9Aii7NGmNigYgh0DUTvdcCMdaLjkcc=; b=WuoKVYqEWcn2vbi03lBZslMKL4HFo/F9YcEDkOKk+iQ+TVCmiqCZK1S7mOtT6JGTtdzqIwnZUh4sEYgJbSJZokCvGlMlxroipMF7VgaQUM7VPeunvrMknempKCfFbOwWrdPz+2+4w3WkeY6zafphKCwc6flasKSqHcFcq+wQU/QwiAwzYLnNwlzsbEvLdjcn2U0yfYRinvP9esAePqosNF65WKTfA9JXVK5JPagediBe/ubZCpsUetU7ZS1pyTncXzDBiNRGLPdIPMWZsQBjLKKASDzzsabQqG4No4ObWgc/goZNhNlFuma74TtSLbGyxp0nnnebLnS1HRa1KU+glg== 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=+RBjyGHKMyCDE9Aii7NGmNigYgh0DUTvdcCMdaLjkcc=; b=G1zM717T31muN2XDCcv8mj83aZUstksNBSrAegXje5+TJwyaIHyTvUX8U3jhKfmzgAxR4chsExk5PUwoHMm20aIPFD2CrqTqCbcHrs5ZMTL82uH1QVjaSxH2SRIbhsCMyeY/LLBYfyER1KEZLYfNwI/OOybTsMhxqcuhryYWdCUsieuDaSV9cgGuv1LuK1DFqWwJwB7WD5CoMga5sDHtYqySmvGe1OW1as18pUjOpWi3fIjLntiQQu2k99N//sa40Nf6X64eMePlOoNXX9fcU630BWt4mv+cvCSVVa8rF0qXfpwZ1MRYqw6YCp3qnGTZ2Adx4yADCl57YJceAs3j/A== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Anthony PERARD , Juergen Gross , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 16/22] xen/arm: vsmmuv3: Insert vIRQ properties into vIOMMU device tree node Thread-Topic: [PATCH v4 16/22] xen/arm: vsmmuv3: Insert vIRQ properties into vIOMMU device tree node Thread-Index: AQHdVe/OQnGcH8ud10GMgq10JjB29Q== Date: Wed, 7 Oct 2026 00:07:13 +0000 Message-ID: <72451b96b206613f92bc79b8adb5f7a2614e70dc.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 8ca01cf1-7b61-4e74-3fa0-08df2406f090 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: Hwtt/WBlbaWh+wU2Ir2niCL0p3FkZeEQPp59xn61E+m6lfKjmkVv5WboEhSd/V6bPCT/z052atkYcOXIk5hsjtKJ6NLK3QlI5N1B2ctYMMGSgYMouHT7oQON1P9R/SBgjo+CVnilMxD932CuyZnC9qUQd4BMYWELE/Pz5oMM8+ve1MjPynK5wMi7CtvN+4IiTVtSmrlzHbOmOeQwPcE4S/tYiWn5mfro5NH+FKckCMhqa5v5/MwNfsuArk5FbUwXjczxMRspPMzwaNc7q7FxO8Gd0JRfTajdjUjDQXhDzfnN43sEeoHzfODh5kTteW04CbrB8bSV4zoYplEFvYUyw73l4gr9yuzs2sa7A6sZMdZJLgUHuTf6l90IDwcMc0/5X9U5KkYIz5ArIck9AxivRaEYFrX1qY3H+yCRlPFVFwvw1+lXNvlxAb0BfSxKxVoIxTwzJ4RGi7zcdlx2xqoeAZgJVJXCm7W6+uNVndwAQj8XxmiAFIMm108hC5/9Q0sTpNTGotLZg4ABydQGwMIwR9pkeeeYvcLPSlpfsC9gH942HyLQGetkM55+4tPggBFI557I+suFnMfXVT3IWH3u7IZu3ftj7I84FwiTujvpp3+dXdYe5xteGaNM3XRccQ78lIC79zPrh4tmjTtSgC6lfHmurrjgXDfd5ATeqcEzLtnBtZbNJrLNHc2T/P/BfTK3vMM9rtIO4+AiduB8yeUZ6f+6noHJxQZGYfrPg8KfhKY= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dkFnbUpUU055YTk2NWY1NHdab3V4RW81bnpNTUNkOHBLeHN1WmhiYjRtOEVR?= =?utf-8?B?WVQrVUwxdlk4Q3FVaytvU1RqS01uUmN1Qk82LzQwL1pSR0lXWG9RSFlFcTJp?= =?utf-8?B?eWl0bTdyNEtKVG55NGdxUVlHMXNoN2krb2NVOS9lTndBbXNjSjRpY1VjU3BS?= =?utf-8?B?a2JwTmI3MWw4Y3E3T05JdjV3K1RaMCtzbjJ5MXBodTFIN3Z2VU8zRUJtdUpp?= =?utf-8?B?czJ2MU1JSm1zQnloWTlLeVlqdnZDbWZxZFpjZnVRYk9rZzFTTVRSRTZnazQ5?= =?utf-8?B?RnhXKzRlTG5jK3VRMWk1d3BadFQ3UFJOQVMyTm94ODlOSUNMb3Q0Nkl5VU5w?= =?utf-8?B?S0FmdXJzZkRJZUlkSHpVa2h1cGtvMGlyMkxmZCtUeGJLRVZmYjRpRDZFOEhj?= =?utf-8?B?SXZET3UvNjdBRC9IK2VxREhmakQ0QzZVYlJNM1pvWW5mWHVZWWhCZVpIcU00?= =?utf-8?B?a2c0OXN3alR3b0hFUW9HY3V5TjRWaytGY3ZUdjQ0bFI0V2lveEMxVUowOU5O?= =?utf-8?B?NURwTm90bS9FVjYzUnIwK3RRUVFjR1pwTXYxRTlqYjY1VkNBblc2b21CRlcr?= =?utf-8?B?NWRCeFNPckU2algvT2NEb3FnZ0dkOXhLcEduaXVZTnI5Vy9NeUs4Zjc4QjNN?= =?utf-8?B?dUlMYnJVTlNON24wZVlKYlJiNEFLU0M4dkVaZDJVRE5Lbk5CTGJ0VVd3bG9j?= =?utf-8?B?RGR5QWh3RGhmT1ZzMytqY3Z3MjBBVWZsNjlubi91RjNSRUx6V2ZMdS90Q1Vq?= =?utf-8?B?aVp4dTAwTy9KRFR0UnlMSUJHeVRzcGR4OEs2emc1SG5UWjMwWWlMeDZENzBw?= =?utf-8?B?OG1PTDFpbm9JRmNQbEZLbHN1QUFzSlFhNjFuRTkraGNVdHJJblVvbUgxT1ox?= =?utf-8?B?RjdLN3RWcDczWFpwQmdhaXZpR1NEUmNNN3MySkZwYWxBMXBsTHk4ZUUvYjN5?= =?utf-8?B?b2NKaVpvbE5QdGhBYkh5cFgwWGp3Q0ZIUEJhUGxVdUN1SG1URFlTbVZNZkpD?= =?utf-8?B?ZnJOMjBsbmFiU1pxTkp4RkxMYmNydE1kWXRMODQ0QVVLUm1FOURQVnd2QlZy?= =?utf-8?B?ZEpFMWc3c0tSaHFsUWNKUGpQZFpiQ1grRDI4M2VqazBmSTNHTHBsUVRrSTZq?= =?utf-8?B?TFFmQWdscXVYN1JzRm8vRHdEdEpYNWFhVjE0akJNaCtXUHlna2k1ckZ3TGJG?= =?utf-8?B?Q2VMbTRHUUY0ZFExT2VPcVRWVnNnbWZvVE55d01iRGhLUWNpakZSdVdyUG9X?= =?utf-8?B?UnFneDBnWTkweDFBMS9oOTdidElPeDZxZDhmSkdTRFNRb0w4ZzA4UTdDN1g1?= =?utf-8?B?MGRBQ3ZNQnYxbWNneVB6cyszUm4xL0tGRWFMcThhNmJJc0FJZzc2RE13Ni8y?= =?utf-8?B?bHlLVWRtN1lYUUlraEx2SC9XUHFBd0h4QnJyckd4bktjLzg5RkJRUHJkdDRa?= =?utf-8?B?eStIb1k3ZmJIeGYyTHZIQjBBWXVoNFluYmpVNU5CRE1EekM3VlFwdk1TSUFn?= =?utf-8?B?VUYyRWFxekFUR2hGWFA5eTRVRmpsSlowOW9QSlRCYm9GUVFoNnF5VEEyU2lL?= =?utf-8?B?eVhzU0F3TGdyaGpDNFZBMjBqc0p0eVlkL1ZGOWQyVlB6SmduSkFZMFJkVm5x?= =?utf-8?B?dUtjSFNZWm5wT0hQZnM4bWEvbmhqejc0bE9yQk1wOWQ3M3llMmd4WERlOFI0?= =?utf-8?B?M3dsQ2RUYjJuYUE2TVF4YksxL2RST0EwaWVtVGVhVUFJNTUzV1VPc2Z4MUdr?= =?utf-8?B?VU93SWZ5MWV6L3JsTDZTcmZiL3JVR0RTWjZjZ0tnc1k5UERDblVTNHo2STUx?= =?utf-8?B?VXZCSXA4RUtwc0c5MUkzZndiZnNXT0NzNzBqdDRFTnZudGUzWmhPeE5IcDFE?= =?utf-8?B?Rm43K1pQemdkL0xuYWhHUWJPaFFkdkRIOHBBc0JxTE5KZU9NVy9vM3U4eTRH?= =?utf-8?B?eDhkVTFCdCtCTEJRRzBkY1lFTFU2bEJCek5NYUlLbnhyNzl0TmZDMEdZS2du?= =?utf-8?B?V29LMFVoeHNvQWdUNk1TTlU5MkRuOVR0YzRZVGIzNWVVSXlnYUwyazJVR21l?= =?utf-8?B?aFdyVlBENVE5VEVOeTFPalhFTGVBSVpNa0YwMC9GZWh5RkNqY3g2VzgyVFBq?= =?utf-8?B?ak93MzZxU0tTQ2hPNUFPRkxRVC93OFdNZndWaW4wY09mdjM0S2tUUjhCdXRK?= =?utf-8?B?ekJaUGg5OGFrb0hoc3J4RjQ1NTZzbU1KYTk5U0NPQmJHSGZLWkNFTll0R2ly?= =?utf-8?B?SCtzZFNKaHpFNzZxMjZwTHEvTnFISWI4ZUw2bFZ3SFpJK2kwQ09yRkFmVlhp?= =?utf-8?B?N2xHdnFxeUFJK2tFMXZRTXgwUUxiVXlydXhwZEcrd1AwZUFOcXZJUT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ca01cf1-7b61-4e74-3fa0-08df2406f090 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:13.3980 (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: l3yyXPPPU4DBbCaQvkx5rlMBMxohiqj06oOOkbfvwql8lzPDad6UlaoN7d9JlHTKe41U8UeGfUxyz58gVhfvqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-ef75cf/1791331635-A62C4AE4-01886601/0/0 X-purgate-type: clean X-purgate-size: 5920 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCkluc2VydCB2SVJRIHBy b3BlcnRpZXMgZm9yIGV2ZW50IHF1ZXVlIGFuZCBHRVJST1IgaGFuZGxpbmcgaW50byB0aGUNCmVt dWxhdGVkIElPTU1VIGRldmljZSB0cmVlIG5vZGUgZm9yIGRvbTBsZXNzIGFuZCBsaWJ4bCBndWVz dHMuDQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxyYWh1bC5zaW5naEBhcm0uY29tPg0K U2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBhbS5jb20+DQotLS0N CiB0b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jICB8IDMwICsrKysrKysrKysrKysrKysrKysr KysrKysrKy0tLQ0KIHhlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jIHwgMTcgKysrKysrKysr KysrKysrKysNCiAyIGZpbGVzIGNoYW5nZWQsIDQ0IGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25z KC0pDQoNCmRpZmYgLS1naXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jIGIvdG9vbHMv bGlicy9saWdodC9saWJ4bF9hcm0uYw0KaW5kZXggMTIwN2I2MjBmYS4uNDEwZGM5OGQwOSAxMDA2 NDQNCi0tLSBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMNCisrKyBiL3Rvb2xzL2xpYnMv bGlnaHQvbGlieGxfYXJtLmMNCkBAIC04Niw4ICs4Niw4IEBAIGludCBsaWJ4bF9fYXJjaF9kb21h aW5fcHJlcGFyZV9jb25maWcobGlieGxfX2djICpnYywNCiB7DQogICAgIHVpbnQzMl90IG5yX3Nw aXMgPSAwLCBjZmdfbnJfc3BpcyA9IGRfY29uZmlnLT5iX2luZm8uYXJjaF9hcm0ubnJfc3BpczsN CiAgICAgdW5zaWduZWQgaW50IGk7DQotICAgIHVpbnQzMl90IHZ1YXJ0X2lycSwgdmlydGlvX2ly cSA9IDA7DQotICAgIGJvb2wgdnVhcnRfZW5hYmxlZCA9IGZhbHNlLCB2aXJ0aW9fZW5hYmxlZCA9 IGZhbHNlOw0KKyAgICB1aW50MzJfdCB2dWFydF9pcnEsIHZpcnRpb19pcnEgPSAwLCB2c21tdV9p cnEgPSAwOw0KKyAgICBib29sIHZ1YXJ0X2VuYWJsZWQgPSBmYWxzZSwgdmlydGlvX2VuYWJsZWQg PSBmYWxzZSwgdnNtbXVfZW5hYmxlZCA9IGZhbHNlOw0KICAgICB1aW50NjRfdCB2aXJ0aW9fbW1p b19iYXNlID0gR1VFU1RfVklSVElPX01NSU9fQkFTRTsNCiAgICAgdWludDMyX3QgdmlydGlvX21t aW9faXJxID0gR1VFU1RfVklSVElPX01NSU9fU1BJX0ZJUlNUOw0KICAgICBpbnQgcmM7DQpAQCAt OTcsMTEgKzk3LDIxIEBAIGludCBsaWJ4bF9fYXJjaF9kb21haW5fcHJlcGFyZV9jb25maWcobGli eGxfX2djICpnYywNCiAgICAgICogb2YgU1BJIFZJUlEgZm9yIHBsMDExLg0KICAgICAgKi8NCiAg ICAgaWYgKGRfY29uZmlnLT5iX2luZm8uYXJjaF9hcm0udnVhcnQgPT0gTElCWExfVlVBUlRfVFlQ RV9TQlNBX1VBUlQpIHsNCi0gICAgICAgIG5yX3NwaXMgKz0gKEdVRVNUX1ZQTDAxMV9TUEkgLSAz MikgKyAxOw0KICAgICAgICAgdnVhcnRfaXJxID0gR1VFU1RfVlBMMDExX1NQSTsNCisgICAgICAg IG5yX3NwaXMgPSBtYXgobnJfc3BpcywgdnVhcnRfaXJxIC0gMzIgKyAxKTsNCiAgICAgICAgIHZ1 YXJ0X2VuYWJsZWQgPSB0cnVlOw0KICAgICB9DQogDQorICAgIC8qDQorICAgICAqIElmIHNtbXV2 MyB2aW9tbXUgaXMgZW5hYmxlZCB0aGVuIGluY3JlbWVudCB0aGUgbnJfc3BpcyB0byBhbGxvdw0K KyAgICAgKiBhbGxvY2F0aW9uIG9mIFNQSSBWSVJRIGZvciBWU01NVS4NCisgICAgICovDQorICAg IGlmIChkX2NvbmZpZy0+Yl9pbmZvLmFyY2hfYXJtLnZpb21tdV90eXBlID09IExJQlhMX1ZJT01N VV9UWVBFX1NNTVVWMykgew0KKyAgICAgICAgdnNtbXVfaXJxID0gR1VFU1RfVlNNTVVfU1BJOw0K KyAgICAgICAgbnJfc3BpcyA9IG1heChucl9zcGlzLCB2c21tdV9pcnEgLSAzMiArIDEpOw0KKyAg ICAgICAgdnNtbXVfZW5hYmxlZCA9IHRydWU7DQorICAgIH0NCisNCiAgICAgZm9yIChpID0gMDsg aSA8IGRfY29uZmlnLT5udW1fZGlza3M7IGkrKykgew0KICAgICAgICAgbGlieGxfZGV2aWNlX2Rp c2sgKmRpc2sgPSAmZF9jb25maWctPmRpc2tzW2ldOw0KIA0KQEAgLTE3MCw2ICsxODAsMTEgQEAg aW50IGxpYnhsX19hcmNoX2RvbWFpbl9wcmVwYXJlX2NvbmZpZyhsaWJ4bF9fZ2MgKmdjLA0KICAg ICAgICAgICAgIHJldHVybiBFUlJPUl9GQUlMOw0KICAgICAgICAgfQ0KIA0KKyAgICAgICAgaWYg KHZzbW11X2VuYWJsZWQgJiYgaXJxID09IHZzbW11X2lycSkgew0KKyAgICAgICAgICAgIExPRyhF UlJPUiwgIlBoeXNpY2FsIElSUSAldSBjb25mbGljdGluZyB3aXRoIHZTTU1VdjMgU1BJXG4iLCBp cnEpOw0KKyAgICAgICAgICAgIHJldHVybiBFUlJPUl9GQUlMOw0KKyAgICAgICAgfQ0KKw0KICAg ICAgICAgaWYgKGlycSA8IDMyKQ0KICAgICAgICAgICAgIGNvbnRpbnVlOw0KIA0KQEAgLTkwNyw2 ICs5MjIsNyBAQCBzdGF0aWMgaW50IG1ha2VfdnNtbXV2M19ub2RlKGxpYnhsX19nYyAqZ2MsIHZv aWQgKmZkdCwNCiB7DQogICAgIGludCByZXM7DQogICAgIGNvbnN0IGNoYXIgKm5hbWUgPSBHQ1NQ UklOVEYoImlvbW11QCVsbHgiLCBHVUVTVF9WU01NVVYzX0JBU0UpOw0KKyAgICBnaWNfaW50ZXJy dXB0IGludHI7DQogDQogICAgIHJlcyA9IGZkdF9iZWdpbl9ub2RlKGZkdCwgbmFtZSk7DQogICAg IGlmIChyZXMpIHJldHVybiByZXM7DQpAQCAtOTI1LDYgKzk0MSwxNCBAQCBzdGF0aWMgaW50IG1h a2VfdnNtbXV2M19ub2RlKGxpYnhsX19nYyAqZ2MsIHZvaWQgKmZkdCwNCiAgICAgcmVzID0gZmR0 X3Byb3BlcnR5X2NlbGwoZmR0LCAiI2lvbW11LWNlbGxzIiwgMSk7DQogICAgIGlmIChyZXMpIHJl dHVybiByZXM7DQogDQorICAgIHJlcyA9IGZkdF9wcm9wZXJ0eV9zdHJpbmcoZmR0LCAiaW50ZXJy dXB0LW5hbWVzIiwgImNvbWJpbmVkIik7DQorICAgIGlmIChyZXMpIHJldHVybiByZXM7DQorDQor ICAgIHNldF9pbnRlcnJ1cHQoaW50ciwgR1VFU1RfVlNNTVVfU1BJLCAweGYsIERUX0lSUV9UWVBF X0xFVkVMX0hJR0gpOw0KKw0KKyAgICByZXMgPSBmZHRfcHJvcGVydHlfaW50ZXJydXB0cyhnYywg ZmR0LCAmaW50ciwgMSk7DQorICAgIGlmIChyZXMpIHJldHVybiByZXM7DQorDQogICAgIHJlcyA9 IGZkdF9lbmRfbm9kZShmZHQpOw0KICAgICBpZiAocmVzKSByZXR1cm4gcmVzOw0KIA0KZGlmZiAt LWdpdCBhL3hlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jIGIveGVuL2FyY2gvYXJtL2RvbTBs ZXNzLWJ1aWxkLmMNCmluZGV4IGZjZTljZGJlZjUuLmRjZTJlYzdmNDkgMTAwNjQ0DQotLS0gYS94 ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KKysrIGIveGVuL2FyY2gvYXJtL2RvbTBsZXNz LWJ1aWxkLmMNCkBAIC0yMjUsNiArMjI1LDcgQEAgc3RhdGljIGludCBfX2luaXQgbWFrZV92c21t dXYzX25vZGUoY29uc3Qgc3RydWN0IGtlcm5lbF9pbmZvICpraW5mbykNCiAgICAgY2hhciBidWZb MjRdOw0KICAgICBfX2JlMzIgcmVnW0dVRVNUX1JPT1RfQUREUkVTU19DRUxMUyArIEdVRVNUX1JP T1RfU0laRV9DRUxMU107DQogICAgIF9fYmUzMiAqY2VsbHM7DQorICAgIGdpY19pbnRlcnJ1cHRf dCBpbnRyOw0KICAgICB2b2lkICpmZHQgPSBraW5mby0+ZmR0Ow0KIA0KICAgICBzbnByaW50Zihi dWYsIHNpemVvZihidWYpLCAiaW9tbXVAJWxseCIsIEdVRVNUX1ZTTU1VVjNfQkFTRSk7DQpAQCAt MjU1LDYgKzI1NiwyMiBAQCBzdGF0aWMgaW50IF9faW5pdCBtYWtlX3ZzbW11djNfbm9kZShjb25z dCBzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZvKQ0KICAgICBpZiAoIHJlcyApDQogICAgICAgICBy ZXR1cm4gcmVzOw0KIA0KKyAgICByZXMgPSBmZHRfcHJvcGVydHlfc3RyaW5nKGZkdCwgImludGVy cnVwdC1uYW1lcyIsICJjb21iaW5lZCIpOw0KKyAgICBpZiAoIHJlcyApDQorICAgICAgICByZXR1 cm4gcmVzOw0KKw0KKyAgICBzZXRfaW50ZXJydXB0KGludHIsIEdVRVNUX1ZTTU1VX1NQSSwgMHhm LCBEVF9JUlFfVFlQRV9MRVZFTF9ISUdIKTsNCisNCisgICAgcmVzID0gZmR0X3Byb3BlcnR5KGtp bmZvLT5mZHQsICJpbnRlcnJ1cHRzIiwNCisgICAgICAgICAgICAgICAgICAgICAgIGludHIsIHNp emVvZihpbnRyKSk7DQorICAgIGlmICggcmVzICkNCisgICAgICAgIHJldHVybiByZXM7DQorDQor ICAgIHJlcyA9IGZkdF9wcm9wZXJ0eV9jZWxsKGtpbmZvLT5mZHQsICJpbnRlcnJ1cHQtcGFyZW50 IiwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAga2luZm8tPnBoYW5kbGVfaW50Yyk7DQor ICAgIGlmICggcmVzICkNCisgICAgICAgIHJldHVybiByZXM7DQorDQogICAgIHJlcyA9IGZkdF9l bmRfbm9kZShmZHQpOw0KIA0KICAgICByZXR1cm4gcmVzOw0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441861.1659457 (Exim 4.92) (envelope-from ) id 1xEFBs-0004qt-7Q; Wed, 07 Oct 2026 00:07:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441861.1659457; Wed, 07 Oct 2026 00: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 1xEFBs-0004p9-0z; Wed, 07 Oct 2026 00:07:24 +0000 Received: by outflank-mailman (input) for mailman id 1441861; Wed, 07 Oct 2026 00:07:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBq-0004a5-3H for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBp-007ODb-GB for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:21 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d2a-e002-0a2a0a5209dd-0a2a450b958c-10 for ; Wed, 07 Oct 2026 02:07:21 +0200 Received: from [52.101.70.138] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d39-b7e8-0a2a450b0019-3465468a6cd9-3 for ; Wed, 07 Oct 2026 02:07:21 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:15 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=QD8WkecedgUnd8ra4T1eloQ4PDUN5pRw3zCLtawl/tySvDZrJxgaeNPtyg8juKN64pipOsQKbgwPu9NuekM/ZNQUhUUCn8lR2vzR6+Y0dESWSIz9E4R0fVtBO/14Haz0guDaodw9kEpYe4JKi77OJf3IdEdzd83Rx3gpTLmY5kS8CnCE1fv6ri0N9qO796dfFPXqb7khugHvvTjLed/5QwwyaEPjSDGDWxKxwRrE27Aq6Svia6wQQ9eQKPutV2cvk3hT4P6lz/K0KAgyS1v6KUAcIuNsWJILMbZ3tKUag6rlxpcoTdq1GiFvlDj1p57oWKGzUew+13/4Dw+PDsqYUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Kscvqz8u7u+M5aaWMtuJsELU0uoAhmtsAXdnJMs9oFY=; b=oyC54tHpKdhyZJk/h9o2zYcwZgqSV2oJRruBLd8QFnIGF77b1uZuOWgaBvmTp1BNRyDLZ3Hd/BLsaBfdt/oh5W5AuBZEBR8g7+FIGOJtxM+fFOINDz2stHJ3NS1nq0icnbpMMu0TGVHu5DUh1g01j27qNY40JMnu3fK6EAXrjSvJSzPQo87SbL23F0Ze39/azQS6kgTc3FUAX75vCNxp9M7t6adUirSIIf8ZyiLlWvnnBoyFYXXV7AbQTfIvstShEtfxfkRkhiueEWQRWR44itP6swUNs8gr+VNBLN1ADZUnc7MbVifu6TetTjJkX+SGEhTrrjgsQAlnK5iG4fl/bg== 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=Kscvqz8u7u+M5aaWMtuJsELU0uoAhmtsAXdnJMs9oFY=; b=g16gJ+vJx9njFU0CQJpF45rT0f/lIT0cGClgg8ItigO1OX3beEO5ZjJeTchd0ylSXumhGD+gPBOvbCAdmPs08RdWznWxGXL1IHMCye5VsZEK1LWVo40XuvmW4kTNV5DJ4OEBgZwJQ+q5y/W3yEBhCtvLfbBAmmX55r22okk8WmvEZkW/vAmWq7DJmMnwnsinGOXl46G856N13NMMgk+D8VLhziXlVxW/RiXbUqfGKiS1NvHYZwhw71kB+ymhBPiCpKJbiGF39Ak9is160t8CiRBcEwnGJzDTr/q6Pp/OdOUyXX4KFuX9B2rSDT0uKctwxcA00tnB5gWWPUAReC2gwQ== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Bertrand Marquis , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Milan Djokic Subject: [PATCH v4 17/22] xen/arm: vsmmuv3: Add support to send stage-1 event to guest Thread-Topic: [PATCH v4 17/22] xen/arm: vsmmuv3: Add support to send stage-1 event to guest Thread-Index: AQHdVe/PKxNpTP5Tkk6OtCTrm7j3dA== Date: Wed, 7 Oct 2026 00:07:15 +0000 Message-ID: <94ab2741c9c61f2b66d9c5a207f913f4241c42a4.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: f0055713-f892-4ea5-c6c3-08df2406f1ea x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: Wdv97aaRUAjeXSNhMq4LbuLhAGGde3XHZ4XnLkVE+6KEWB5S05A91QBxi9DYzKEh/aaIJ45of1s2fY+UtNZIn2e4+xnhqW4eAjZPOHbEGbRR2+FIzn5625trnBPiU47x7fiQXaQfRjyZ4De+ARn3ioJH2UdEJApibOKC4SLiw3BUEesJnVRuJ6n384WUcn/bNsb/VUuqAl4UeD28ue7aw4ls+Ue3k9d9wm5iqbx4dyH7IFpwFDpjki59k8Vlo8j0Mb3t4FqRVZMhKW6Y0HxhjvBwK51DNSWdTt4WaDENeuW0Fa8woVOEUVA1CBy0Tl4i4bL5GlGE3dNdbWTJVGc5C1ZtlXZdMa5Lnowt3UpLA2WAXqpcO+clTnLNDbawwUnJK7V9aaLT7/IH/+W2lUEolKwIpyX9Ryj4J9ZrBHo6Aj2BrjTV4/DpP8hKwKeCMHaCVuAGX0wtMbrQJL2RUxZBLY1+2V9zWiIVwQicZrWn7u8tBF9otyfSqsCPdPwzQa6raDXdUulrmk1IzEcrxZPbFtQgR+g6YYhHdavlnOMcyY5rAfyDTL4xwTfROlvzoacbBpiKb2rEHA0J4gV+tPB53rT05If2oxfCjN3FIrT2+d03TaA0ZzuqDuLG2rojXpZ6MtCy4YJG5a2wPD2IJ2cqyKn/f44DPZscQNjZKFOBmR+D8VxPKQQPz0z5pZb8QRKu38nXVTSgekcUTV7M3i5SXp+j/ywo2L0htOFbuk5r4GM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NWRQUHd6Qyt1UzZhNVNHZ2hqZ0ZBdGs2SHY5K3R1UFE5Y0JQT05PdjlSZVJt?= =?utf-8?B?cmtUelVHVmhBNEJIK1BGYTU4TTNoMHErRnY1UW1sUHFVMjhzUkloSHdqVG5m?= =?utf-8?B?VnpiT2pVUFBYSXc5dVFBb1ZoOEJ0bU9za3I0Rm1lOHhtMkdpUHlab0NIaU5y?= =?utf-8?B?MHpoOFNGU3JoT3FmQWNMeWpyKy9mUThrNnM2L2JtZ1dubk1ueW5lQi9HRjlM?= =?utf-8?B?WnlqeERreG1xU1NJUmpVRkhsUkQwMkVSVEFBTWJPMnVSU1UxWTJLWFUxeTA4?= =?utf-8?B?dGNaNEQ1c1p3SGJXVkdNVDZHVDJQZmkxQTNvZGp5aWpoTEY5MnlSbWxNN0pv?= =?utf-8?B?TDYzUDJ5UmUwaktnYWs2TVBEaGJCaEZZalZqM2RlMkg5YmUreTNIN2kwblZL?= =?utf-8?B?eWU2YzlmNUYydm5mUitwcWlkalhKWTQzTXo4OERyNG82ZHh0WS9ad1owWjNj?= =?utf-8?B?MnNKT1ZCTjQvR3F2dzZGRkFSdHF6ZndIWjNYMHZscE1BL05mbnp5UG0wa29S?= =?utf-8?B?ZWgvaWo3WjNENm5MSW16RGRMemQ2TWt2WitwVEtZaGFORmNYNEFmbnB2RWp3?= =?utf-8?B?dVlYNkM5cFA5SUVHUmo5cTdvUVNmdzhLUDhTWGtUd1RNcjVJVGU0d2VrQ082?= =?utf-8?B?TTRqUFNlNU9waWtmVVo2b1dubHkwL045VkpQNVY5WUZBNUlpclBHaHZXVm5V?= =?utf-8?B?U1JNR2p6TjQ0TEI3K1NOc1VLeWR5OUI1YmpybWx1eFBxUzRVMnVUUHltWVNy?= =?utf-8?B?aTlCSGg3bFF4ZXFFc3hDU0NXeTdDTlM3b3ExVzVTZldMZ05MZ2Vwb3NvOXlw?= =?utf-8?B?R3VqdnB4RFNERVlCQUVUbytsT21zZm9xaDBqWSt6aHpxUGdlbEE2TmNTS0Qv?= =?utf-8?B?VTFtQXdLVGp0ckZ4UXRBWDNGQy9WaXBjTG01Ky9wRzM0blFBejBRM2RUY0ZX?= =?utf-8?B?UjZEeEhxcnZXVVNhKzlGTzJDOHRmMDBzSWs2V3FYbFc0YVdaQWVVUzRyZUdZ?= =?utf-8?B?eXd5alJWc2lHMTA4UkdYVWRTOUhzQmQyZ2VNcEMwazdEU2t1b3JmMkVnViti?= =?utf-8?B?eDBRN1BPT2gxSDdiQnV5YnlqYjZTMHBQc1ExNG1KdFFFYWNhdEdPc1FhQ3B3?= =?utf-8?B?MXJJQWlvSVlkWnd4MTdrUk5vVmRhREUvK1JHL1VCODk5V0MwaUtSUTlEN1Jn?= =?utf-8?B?cHg2WVc2VzdLcEZYTFc4VnlQT0pvV2Q0MEgzWEkvMTVFR1VRYWtrSDZ5d2tX?= =?utf-8?B?RzRLTUd1T3E1VVpCKzVyZlM3Z3VpcjFodjY2L1VmaGR3YXFqVzZiTzJJN2ZY?= =?utf-8?B?RlNCQzRkT2ZXeU1iWWRSYW9tLzVtQXVqWlZuWGFlajh0SmI2ZGFBeDFBSWN3?= =?utf-8?B?NkYyNUZiUzhLZzhxdFl3dHJMejRLaEYzYXNVZ1JLT2xFM25NbnpKU0hlaTlB?= =?utf-8?B?ZkpmdGViQzk2QjR4ZUJGR1RlWVdOWjArYWNnRHkzcERQcEwzd04zczR1TFZl?= =?utf-8?B?Q2h2ZlBHRU05Z2xmVDBzN1kwdmkrR0lqQWwvMW01czR3TGpJNG9QNzk2UXd6?= =?utf-8?B?SGY5ZUZUT0lOakRhUGphbVdPZlZ2ZjFhcjZSRmxpSy9nNU5OeEdVL0E4UzI2?= =?utf-8?B?RFhndElkOFFYcEEwWUVBdTlsRlhwUVd0bGRHV2hpL2NCOGJMaGx4bHlHZTYz?= =?utf-8?B?LzhTU3pXUkMrUkY0cXdoQU13Y09ZYk5wQmlOWVdicHRWRHFKMHJLQkE2OXVQ?= =?utf-8?B?VG05T2U5TE9WVXNzT041cWx5QTVwTnNWbVJ1akxXU0ExL0tQZUxlOG9wSnZ4?= =?utf-8?B?dVFkU1AwYTI3THk1SThsYmszNjV4REptdmc3MS9aVTBuUVIyVmdvOEk2dUVJ?= =?utf-8?B?Z01xenozdExzSmJWWktxdUh3bEVwY0lscUR0ZHZMREY1WVd4eHIzSWxtZFhH?= =?utf-8?B?ekpuRllOWklFb3Brbnc2d01EbnN4c1Bja0ZYTFhBcHpQbW1TVjRwVHduci8y?= =?utf-8?B?WDJ3dkFzRUE0RE9JUTdBdFlLNkVHMFFCeXlTWjNBNjZtZnJDYnoxSk11RHdj?= =?utf-8?B?aHYxVDlWaHRzM2djM3htdEJjWFE3ZitvRmJJK2NXTlJ2MWhLUk9DTUhTbTNH?= =?utf-8?B?Uk85bkpWZHY5S2FWVGxjYU9SR290SWJLME5aN3o3S0h3YjBkcUpIUlpYQ0pT?= =?utf-8?B?QmsyOE1ieDV4bnVqY2xTUWM5cllpbFZ0RGg3WmhDL083YVYwcTk0LzJhbllX?= =?utf-8?B?d25VTTJTUmhJZDBsclN6ZFRhRHN2WkhEemVIZzI2dElKVk1uak5uZmZTS2d2?= =?utf-8?B?dnhhT0Ezcm8zbXF4T1hiZzVqWnczeXo0VS9WL3dGWkZyUTlndmtqdz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0055713-f892-4ea5-c6c3-08df2406f1ea X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:15.6579 (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: 7r34BC/KTndro7X72eRJ0LS4lqgt7oMQ92ulL7eDTfOT0ySZY8Imjj60Fv26rgir33lh1jVkOxYV9/HWwRvM0w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-42698a/1791331641-AA6DA9EA-20F7853D/0/0 X-purgate-type: clean X-purgate-size: 6988 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNClN0YWdlLTEgdHJhbnNs YXRpb24gaXMgaGFuZGxlZCBieSBndWVzdCwgdGhlcmVmb3JlIHN0YWdlLTEgZmF1bHQgaGFzIHRv DQpiZSBmb3J3YXJkZWQgdG8gZ3Vlc3QuDQoNClNpZ25lZC1vZmYtYnk6IFJhaHVsIFNpbmdoIDxy YWh1bC5zaW5naEBhcm0uY29tPg0KU2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9k am9raWNAZXBhbS5jb20+DQotLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12 My5jICB8IDQ4ICsrKysrKysrKysrKysrKysrKysrKysrKy0tDQogeGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvYXJtL3ZzbW11LXYzLmMgfCA0NCArKysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9k cml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5oIHwgIDggKysrKysNCiAzIGZpbGVzIGNo YW5nZWQsIDk4IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS94 ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jIGIveGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvYXJtL3NtbXUtdjMuYw0KaW5kZXggMTk2YWM2NjBlZi4uZTQ0Zjg3MmQyZCAxMDA2NDQN Ci0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmMNCisrKyBiL3hlbi9k cml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmMNCkBAIC04NzEsNyArODcxLDYgQEAgc3Rh dGljIGludCBhcm1fc21tdV9pbml0X2wyX3N0cnRhYihzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpz bW11LCB1MzIgc2lkKQ0KIAlyZXR1cm4gMDsNCiB9DQogDQotX19tYXliZV91bnVzZWQNCiBzdGF0 aWMgc3RydWN0IGFybV9zbW11X21hc3RlciAqDQogYXJtX3NtbXVfZmluZF9tYXN0ZXIoc3RydWN0 IGFybV9zbW11X2RldmljZSAqc21tdSwgdTMyIHNpZCkNCiB7DQpAQCAtODkyLDEwICs4OTEsNTEg QEAgYXJtX3NtbXVfZmluZF9tYXN0ZXIoc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSwgdTMy IHNpZCkNCiAJcmV0dXJuIE5VTEw7DQogfQ0KIA0KK3N0YXRpYyBpbnQgYXJtX3NtbXVfaGFuZGxl X2V2dChzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11LCB1NjQgKmV2dCkNCit7DQorCWludCBy ZXQ7DQorCXN0cnVjdCBhcm1fc21tdV9tYXN0ZXIgKm1hc3RlcjsNCisJdTMyIHNpZCA9IEZJRUxE X0dFVChFVlRRXzBfU0lELCBldnRbMF0pOw0KKw0KKwlzd2l0Y2ggKEZJRUxEX0dFVChFVlRRXzBf SUQsIGV2dFswXSkpIHsNCisJY2FzZSBFVlRfSURfVFJBTlNMQVRJT05fRkFVTFQ6DQorCQlicmVh azsNCisJY2FzZSBFVlRfSURfQUREUl9TSVpFX0ZBVUxUOg0KKwkJYnJlYWs7DQorCWNhc2UgRVZU X0lEX0FDQ0VTU19GQVVMVDoNCisJCWJyZWFrOw0KKwljYXNlIEVWVF9JRF9QRVJNSVNTSU9OX0ZB VUxUOg0KKwkJYnJlYWs7DQorCWRlZmF1bHQ6DQorCQlyZXR1cm4gLUVPUE5PVFNVUFA7DQorCX0N CisNCisJLyogU3RhZ2UtMiBldmVudCAqLw0KKwlpZiAoZXZ0WzFdICYgRVZUUV8xX1MyKQ0KKwkJ cmV0dXJuIC1FRkFVTFQ7DQorDQorCW11dGV4X2xvY2soJnNtbXUtPnN0cmVhbXNfbXV0ZXgpOw0K KwltYXN0ZXIgPSBhcm1fc21tdV9maW5kX21hc3RlcihzbW11LCBzaWQpOw0KKwlpZiAoIW1hc3Rl cikgew0KKwkJcmV0ID0gLUVJTlZBTDsNCisJCWdvdG8gb3V0X3VubG9jazsNCisJfQ0KKw0KKwly ZXQgPSBhcm1fdnNtbXVfaGFuZGxlX2V2dChtYXN0ZXItPmRvbWFpbi0+ZCwgc21tdS0+ZGV2LCBl dnQpOw0KKwlpZiAocmV0KSB7DQorCQlyZXQgPSAtRUlOVkFMOw0KKwkJZ290byBvdXRfdW5sb2Nr Ow0KKwl9DQorDQorb3V0X3VubG9jazoNCisJbXV0ZXhfdW5sb2NrKCZzbW11LT5zdHJlYW1zX211 dGV4KTsNCisJcmV0dXJuIHJldDsNCit9DQorDQogLyogSVJRIGFuZCBldmVudCBoYW5kbGVycyAq Lw0KIHN0YXRpYyB2b2lkIGFybV9zbW11X2V2dHFfdGFza2xldCh2b2lkICpkZXYpDQogew0KLQlp bnQgaTsNCisJaW50IGksIHJldDsNCiAJc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSA9IGRl djsNCiAJc3RydWN0IGFybV9zbW11X3F1ZXVlICpxID0gJnNtbXUtPmV2dHEucTsNCiAJc3RydWN0 IGFybV9zbW11X2xsX3F1ZXVlICpsbHEgPSAmcS0+bGxxOw0KQEAgLTkwNSw2ICs5NDUsMTAgQEAg c3RhdGljIHZvaWQgYXJtX3NtbXVfZXZ0cV90YXNrbGV0KHZvaWQgKmRldikNCiAJCXdoaWxlICgh cXVldWVfcmVtb3ZlX3JhdyhxLCBldnQpKSB7DQogCQkJdTggaWQgPSBGSUVMRF9HRVQoRVZUUV8w X0lELCBldnRbMF0pOw0KIA0KKwkJCXJldCA9IGFybV9zbW11X2hhbmRsZV9ldnQoc21tdSwgZXZ0 KTsNCisJCQlpZiAoIXJldCkNCisJCQkJY29udGludWU7DQorDQogCQkJZGV2X2luZm8oc21tdS0+ ZGV2LCAiZXZlbnQgMHglMDJ4IHJlY2VpdmVkOlxuIiwgaWQpOw0KIAkJCWZvciAoaSA9IDA7IGkg PCBBUlJBWV9TSVpFKGV2dCk7ICsraSkNCiAJCQkJZGV2X2luZm8oc21tdS0+ZGV2LCAiXHQweCUw MTZsbHhcbiIsDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11 LXYzLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuYw0KaW5kZXggODcz NDJmZGY2OS4uYjcxNTExYzJlYiAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo L2FybS92c21tdS12My5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUt djMuYw0KQEAgLTMzOCw2ICszMzgsNDkgQEAgc3RhdGljIHZvaWQgYXJtX3ZzbW11X3NlbmRfZXZl bnQoc3RydWN0IHZpcnRfc21tdSAqc21tdSwNCiAgICAgcmV0dXJuOw0KIH0NCiANCitzdGF0aWMg c3RydWN0IHZpcnRfc21tdSAqdnNtbXV2M19maW5kX2J5X2FkZHIoc3RydWN0IGRvbWFpbiAqZCwg cGFkZHJfdCBwYWRkcikNCit7DQorICAgIHN0cnVjdCB2aXJ0X3NtbXUgKnNtbXU7DQorDQorICAg IGxpc3RfZm9yX2VhY2hfZW50cnkoIHNtbXUsICZkLT5hcmNoLnZpb21tdV9saXN0LCB2aW9tbXVf bGlzdCApDQorICAgIHsNCisgICAgICAgIGlmICggc21tdS0+YWRkciA9PSBwYWRkciApDQorICAg ICAgICAgICAgcmV0dXJuIHNtbXU7DQorICAgIH0NCisNCisgICAgcmV0dXJuIE5VTEw7DQorfQ0K Kw0KK2ludCBhcm1fdnNtbXVfaGFuZGxlX2V2dChzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgZGV2 aWNlICpkZXYsIHVpbnQ2NF90ICpldnQpDQorew0KKyAgICBpbnQgcmV0Ow0KKyAgICBzdHJ1Y3Qg dmlydF9zbW11ICpzbW11Ow0KKw0KKyAgICBpZiAoIGlzX2hhcmR3YXJlX2RvbWFpbihkKSApDQor ICAgIHsNCisgICAgICAgIHBhZGRyX3QgcGFkZHI7DQorICAgICAgICAvKiBCYXNlIGFkZHJlc3Mg Ki8NCisgICAgICAgIHJldCA9IGR0X2RldmljZV9nZXRfYWRkcmVzcyhkZXZfdG9fZHQoZGV2KSwg MCwgJnBhZGRyLCBOVUxMKTsNCisgICAgICAgIGlmICggcmV0ICkNCisgICAgICAgICAgICByZXR1 cm4gLUVJTlZBTDsNCisNCisgICAgICAgIHNtbXUgPSB2c21tdXYzX2ZpbmRfYnlfYWRkcihkLCBw YWRkcik7DQorICAgICAgICBpZiAoICFzbW11ICkNCisgICAgICAgICAgICByZXR1cm4gLUVOT0RF VjsNCisgICAgfQ0KKyAgICBlbHNlDQorICAgIHsNCisgICAgICAgIHNtbXUgPSBsaXN0X2VudHJ5 KGQtPmFyY2gudmlvbW11X2xpc3QubmV4dCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgIHN0 cnVjdCB2aXJ0X3NtbXUsIHZpb21tdV9saXN0KTsNCisgICAgfQ0KKw0KKyAgICByZXQgPSBhcm1f dnNtbXVfd3JpdGVfZXZ0cShzbW11LCBldnQpOw0KKyAgICBpZiAoIHJldCApDQorICAgICAgICBh cm1fdnNtbXVfc2V0X2dlcnJvcihzbW11LCBHRVJST1JfRVZUUV9BQlRfRVJSKTsNCisNCisgICAg cmV0dXJuIDA7DQorfQ0KKw0KIHN0YXRpYyBpbnQgYXJtX3ZzbW11X2ZpbmRfc3RlKHN0cnVjdCB2 aXJ0X3NtbXUgKnNtbXUsIHVpbnQzMl90IHNpZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1aW50NjRfdCAqc3RlKQ0KIHsNCkBAIC0xMTE4LDYgKzExNjEsNyBAQCBzdGF0aWMgaW50 IHZzbW11djNfaW5pdF9zaW5nbGUoc3RydWN0IGRvbWFpbiAqZCwgcGFkZHJfdCBhZGRyLA0KICAg ICBzbW11LT5kID0gZDsNCiAgICAgc21tdS0+ZmVhdHVyZXMgPSBmZWF0dXJlczsNCiAgICAgc21t dS0+dmlycSA9IHZpcnE7DQorICAgIHNtbXUtPmFkZHIgPSBhZGRyOw0KICAgICBzbW11LT5jbWRx LmVudF9zaXplID0gQ01EUV9FTlRfRFdPUkRTICogRFdPUkRTX0JZVEVTOw0KICAgICBzbW11LT5l dnRxLmVudF9zaXplID0gRVZUUV9FTlRfRFdPUkRTICogRFdPUkRTX0JZVEVTOw0KIA0KZGlmZiAt LWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5oIGIveGVuL2RyaXZl cnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmgNCmluZGV4IDlmNGM4NmFiZDUuLmQ0YjdjZjgw NWYgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdnNtbXUtdjMuaA0K KysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmgNCkBAIC04LDYgKzgs OCBAQA0KIA0KIHZvaWQgdnNtbXV2M19zZXRfdHlwZSh2b2lkKTsNCiANCitpbnQgYXJtX3ZzbW11 X2hhbmRsZV9ldnQoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGRldmljZSAqZGV2LCB1aW50NjRf dCAqZXZ0KTsNCisNCiAjZWxzZQ0KIA0KIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2luaXQgdnNtbXV2 M19zZXRfdHlwZSh2b2lkKQ0KQEAgLTE1LDYgKzE3LDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBf X2luaXQgdnNtbXV2M19zZXRfdHlwZSh2b2lkKQ0KICAgICByZXR1cm47DQogfQ0KIA0KK3N0YXRp YyBpbmxpbmUgaW50IGFybV92c21tdV9oYW5kbGVfZXZ0KHN0cnVjdCBkb21haW4gKmQsDQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGRldmljZSAqZGV2LCB1 aW50NjRfdCAqZXZ0KQ0KK3sNCisgICAgcmV0dXJuIC1FSU5WQUw7DQorfQ0KKw0KICNlbmRpZiAv KiBDT05GSUdfVklSVFVBTF9BUk1fU01NVV9WMyAqLw0KIA0KICNlbmRpZiAvKiBfX0FSQ0hfQVJN X1ZTTU1VX1YzX0hfXyAqLw0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441862.1659465 (Exim 4.92) (envelope-from ) id 1xEFBt-0005Dj-OT; Wed, 07 Oct 2026 00:07:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441862.1659465; Wed, 07 Oct 2026 00:07: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 1xEFBt-0005D6-KC; Wed, 07 Oct 2026 00:07:25 +0000 Received: by outflank-mailman (input) for mailman id 1441862; Wed, 07 Oct 2026 00:07:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBr-0004iN-Jc for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBr-000T4z-0B for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:23 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d31-2eae-0a2a0a5409dd-0a2a4502b47a-6 for ; Wed, 07 Oct 2026 02:07:22 +0200 Received: from [40.107.159.102] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d3a-6ca4-0a2a45020019-286b9f660fa9-3 for ; Wed, 07 Oct 2026 02:07:22 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:20 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=f2R97XwvSNrIEygPT/bqtCyAv2Vt2Dj3o5t6/87uqKqfF1umKRfFfe8akYkhaD2MlG84zS22tKMBi9Hz/TY8JCUD+2hz5vrIu2cCPnnxjtFFtcu8rIVuezMTyhu+7Cr5165zf6/8emyEdlYbnS9LfAaQ5BtDwFvH6a4I+v/BCphqhZPkzrVAGaKQElbL0eyKusMyzMkBJwmTj56V/obK5EiphESRbRh+oJiKCYV2YQqRKik2B11smO9378iIgpBpkMxFAfqd3MGRYoBN9GC4Pu3OSD2eR5mDk8DKgR/0B4V931DXGIkhGS1Sa2OlCmQn9QLGhlAokhjlLM3zrKpI8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=53OCYmKFkmCCZj9TDCJ9g+czJuFl75vdsuZUcX/88+o=; b=SKFeXrfBKBAU7GuwHyOrAob2mSReeWd3Od7fUCbEI0FOYLysgV+m+McPiDqxI5eNLptvyAD6JLEuc0eXWafqL2mGzzk2MhH43nKldhOBQ0cc+Z+mtn/0sJVygZJFYpF7lTRsfXPF6W73mm39l1hUzhMu6HYadyC80i1lWgJX7BeY5N9nOnCQw1UBL7Paj4S3r3YXCFuNlr5hWCWDcF4BV868EviVS/YAWf6whzvQRsUF66Bfmp38zlsCUde3XjFe01ghuLxbZ6D4/c8xMXk8Nvliorad089WzHlafTF3JTolVwKn/iGxp//gs6HPcxI5jMqQtnx1lmwQL0/cadsY9Q== 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=53OCYmKFkmCCZj9TDCJ9g+czJuFl75vdsuZUcX/88+o=; b=RhZtwrCwt4KUiAXeq0Mh7UvMGCvPV+EaQbL7rDwtmRml8uWXvLYhzCEqEd/wn6WCE15D/hS5ZP6p8s270DhIo0qIQnN+N8Q65XWZD5Vz2WBmVyXglQ7YuWug1IZYZ//vqOnSS5tjZKLua8BUtXZ5fGtnjt3G7pz07DHFR+cMTlY/iZ/V4F54SoNxufVjywv6ZK8myhVI+qj/IrH35Cdq3bTAfl1dsXHCr6zVdvJpnhr77SZVKd7M0esdEldy7h9u5ZTgMHGsYJieTpQXS9NDgKbnz4q6s18FV0em9dsu5jBN8RayJvcajxtQftqfDSFA+DyOXHKk40KTDb3wfkBSXg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Anthony PERARD , Juergen Gross , Milan Djokic , Luca Fancellu Subject: [PATCH v4 18/22] libxl/arm: vIOMMU: Modify the partial device tree for iommus Thread-Topic: [PATCH v4 18/22] libxl/arm: vIOMMU: Modify the partial device tree for iommus Thread-Index: AQHdVe/QhuTEwvt5Z0unZpDIkK/H5w== Date: Wed, 7 Oct 2026 00:07:17 +0000 Message-ID: <4dd1ba2be09b39fc63fdca29515b410a58989fec.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 15cf203c-a011-49d1-6a40-08df2406f2c8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|6133799003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: JhzI9pCRRICOlUIwlGk/EEFslAZ8owCG1LpCEck1qzjoydsJFRFMGCO/0uYR2i+a1Am2JMaid/OTsLAfyxIV8jXT1xCEKLA39YgU1KzzT9W+MJhtcy0VC+gjwf/TUyPn3GNCRcSn81XYJV9ly8dswg8eif3UsPWbUjV/ubJXlBvP/cqt47Y5ib8O96r1Vv9WBbkLxuUMgb9/GIu9FhQZst1xZQ+txY8jdtcMtJEtd2iUZ7UwqpuJUXqcAPfo4vI7PBqwl/zoQ5dJAyzi4/0/H5YvD/MK7sR9JZLApF0ZnW0T0Abcsul51vtyftb6VnitU68f2MYbW+KPHkQcU65vMDzT8zoni4dOzgdR4eLN9NQsTF4oaYFTtkxs9QiFKYdcshC7lV3iEpUN4IsBb8qPnpN4U+XZbEWMpEJyEH//MmVoYIm+epTBehNkHcyzFyRbD6d28lG4na2qfzT71q/dJmxktWz3+rtnCrvjH9L6CyEGtXUzJ5nmLSrCWKleIZIicwlO56LrB5NDKPHh/RPmOFnu2vcY+JgSZFhRiRJ2MFpNVXg0q6U1gjCnyWQ09sGO/XLjfe/DijxMzyb76zSxCnOJqQkwpz2nWLNB1ZVB+E8TQ8MlyoOwGL5K0HbSpFdL6whunG06njz3CBcQD9rWTJiNoKx7K54kQxU0hbiGc4UAJsgNr+x9xzSVmd5dWqBLImiHadGusdhDOyUq+C8rXvw4viEYNNCunN6grYcJNlA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(6133799003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eldDTEtRMFlXZ0NlV1JuaUlwTkJaWWt2R0dKRVV1eStJNEw2VHp3eFh0ZXdM?= =?utf-8?B?QWRLYnlmN1lCaVlaTjdlYUtUajNJNnYzYVNXYnZNN01FdWdOM0FnSGpEK2pK?= =?utf-8?B?VnJtdTVnSjkwZU16UU8za2Q1bzVDNHVaZUdBM1RWUVd1b1NmRGZMYmZLdU1Y?= =?utf-8?B?NktnQVpFTDNWbmJPcUdSanZTR3U3c0RwNUF6YzdqNmFHUXBNZU5FdmhtSTJZ?= =?utf-8?B?TG1mR2N5UGlEdTRTaVNmdEZIdHMwUk9qMktCa3BQS2V3OC90WVIxZ29QNWg2?= =?utf-8?B?bUljVkpLcHFVMXdWd0w1N2ZpZXQyZDBzSTJodG9OWDJaY0txVzVSNSt5Q1E1?= =?utf-8?B?VFcrMGNxNHk4MmxhTEF4WE8yckJHWWZxcVROSnM0cGFtTnhiRUd1dEwvc1hn?= =?utf-8?B?TEoybkdUZy9LSCsrdm53dUFQZ0Z1YlZmcExSZS9PTVFxTlRhTnRoOWVibVB6?= =?utf-8?B?am9pUCtNY3FUWUtmK1Zpb2lrbVF6WGNQWG5ZaENTbSsvWHZIQUFMVXFMLzRy?= =?utf-8?B?aEpaWlRpeGxCbUFYRTE0eWNDSnNTN1FmL0x6MU9XeDdEcDY5M2dyUzQ5ZlZM?= =?utf-8?B?MEtOMUo1bHdzSHJkK3FpZ1pxSkdVL1ZKYkpxLy83Z3JMNGpaSlF5cHVsSU5G?= =?utf-8?B?T3lRU1dyOVh4ZGdXOXBCbmQraEVhM1NtZUZPc0NYMWcvQ1pTcE92M1BuRWhG?= =?utf-8?B?Z3I0Z0ZPSEt1b3dpSEFVYUhBMG9vQnFGZGR5SEZ4bUFxdm5QU012dzN4ZWRu?= =?utf-8?B?UjgxV1p5NzhlMC9JaVo5U1BoWDFpVm1ya2kyQWRZZDhzQ1lKNDRXNkhxcGdo?= =?utf-8?B?QTUwVUl5UzAzSHJmMW1XNnIwNDEvdFRNaGxjaEcxU3A1MXZqazBVdnU0b0pl?= =?utf-8?B?T083djZRWFNzYUNNUGc0WFBqQkN0SWYzOVRtRnRNRDZ3Z2R4UWlTZWd3MDlR?= =?utf-8?B?YnBPY1NSWTRScWFNcENQRWFKbjdMUkZNNHZuQmVVM0NYd084bDlHc2hyek5S?= =?utf-8?B?aUM3aW9QTWw1NFU2RTR5NGhtT2tkYzN4bmVMMjBxNXVHcXRaQ0N5eVJSTElE?= =?utf-8?B?L3Y0aGJ4eVJ6TFFZZzFRMHFMVVpxMzQrUDUyTGNIeVJaK2RyWXYxN0xLSmVn?= =?utf-8?B?VENDUHgrZXdKcEdBSHRyOGE2bDZ4bEUycWFubktKRFE5MWxEU0NKQ29Bbk1U?= =?utf-8?B?R3gxMi9PUUxCL0VvVEFBS0VqUWZKaVA0R2E4dGdpWFVZMUFmM0tzTkNjNmE2?= =?utf-8?B?NklFMHlpbTBBSzcyUVJZWXdMaVZ2NkpiV0F4N093UFJPMVd3RHhrOVpmc3Ez?= =?utf-8?B?K2lMTEFXbUYzQW5aZjBRbHdXYnkwTmUwZzIvaFVFdWcremhmRlA2eGl1VHFP?= =?utf-8?B?WU1kNEZUZGJaVTZ1S01hK0VsZHUrb0J0Q3lvZ3owODZzb0ZTaXRRakJVQ0xR?= =?utf-8?B?alg2U3I1MnVaUzQrN01PSk55VXhxbnJFS1FlR1VMQS9MeXV5T2h3OC82VE02?= =?utf-8?B?Q0xnanBuMEJ0N3NIZlJFTWdhMHlRRzJHMU5GRldvWUJGd2pNTFBGVDYrYm9Z?= =?utf-8?B?ZklMalFhU3d2T1lOWXQ4ay90T2ZDY2x2Z0FVcGx5cFRHcnlsUFRpRTdqbmhi?= =?utf-8?B?SkYvRnRnYUJnYVFkMjRvU25ZVWFVQ2FSY085a01xRFlpTVlQU1ZhbzJiQjJ6?= =?utf-8?B?dDhjeGpBUmdVQ0VjS3dWQUZDc3FaSXF3SDRtQTkxbTdRdWZ6VnNCVjc3NW1z?= =?utf-8?B?MzllTXRTZVZYdm1PMzAvYXAyeWR5aFNXT0ZhODhZcm1zSGhsQlQwSU5PSlJa?= =?utf-8?B?bHQyYllSVzdJTEloeE1VUE9SV0E4YzRRM0tzV0NPT0p2ZGVDTDgxT3ZFQUw5?= =?utf-8?B?Q2hRTUxiSC9Ddy9pUnF4dVpJeks1OHhvR2dyNkx0Qmt2cDVkOGliRjhQSTdQ?= =?utf-8?B?dXAvRExCdG55RlVselQ1T1pVcGh3cEp1TGM0SlUwMmVZMHNhNEhadHU5N01E?= =?utf-8?B?K2NCK1FJZXVyRCtFVXZ4MXFMZVhPWk1tdFNiOFp5S2U2SmJ1VkMvKzUzSDk2?= =?utf-8?B?TFk5ZmxkSVhWN1dtaXlEOHZNQno3dUhQRzhLeUpBVUpBQXljeFoxL0RNRjBi?= =?utf-8?B?Wkp3STBlbGNzc3NqZ2JCMzJ3czBkZFZsRWp3cjZzMzBKcHBTWFUxRktpTFRq?= =?utf-8?B?S0Y3cTlRTkFWTU5MZ3huc2J0aW9kNUtmclppK0JVNmFRUG8rYVpzUGJhTm1T?= =?utf-8?B?NmpnL05iQk5FbWwzYUF0V1pDTC9oOExjanRObXpydUtDK0sxZlBwNXA3eTBl?= =?utf-8?B?bSt3MC9WL1VkblhiY3JHQ2p3WEVlRHc0NnliUjVxMVRYdnR0RGpBQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15cf203c-a011-49d1-6a40-08df2406f2c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:17.1126 (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: XGEHdFDh9xiiUVyBs/DnJ4sYpFYvzLmsvQOBSMW3SZ6aZY7D+GI1UfFU3zka0db2CjPhI9pGZ9Z2H0KMxrYI2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-720697/1791331642-674BE2AC-956E1315/0/0 X-purgate-type: clean X-purgate-size: 4000 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNClRvIGNvbmZpZ3VyZSBJ T01NVSBpbiBndWVzdCBmb3IgcGFzc3Rocm91Z2ggZGV2aWNlcywgdXNlciB3aWxsIG5lZWQgdG8N CmNvcHkgdGhlIHVubW9kaWZpZWQgImlvbW11cyIgcHJvcGVydHkgZnJvbSBob3N0IGRldmljZSB0 cmVlIHRvIHBhcnRpYWwNCmRldmljZSB0cmVlLiBUbyBlbmFibGUgdGhlIGRvbTAgbGludXgga2Vy bmVsIHRvIGNvbmZpZ3VyZSB0aGUgSU9NTVUNCmNvcnJlY3RseSByZXBsYWNlIHRoZSBwaGFuZGxl IGluIHBhcnRpYWwgZGV2aWNlIHRyZWUgd2l0aCB2aXJ0dWFsDQpJT01NVSBwaGFuZGxlIHdoZW4g ImlvbW11cyIgcHJvcGVydHkgaXMgc2V0Lg0KDQpTaWduZWQtb2ZmLWJ5OiBSYWh1bCBTaW5naCA8 cmFodWwuc2luZ2hAYXJtLmNvbT4NClNpbmdlZC1vZmYtYnk6IE1pbGFuIERqb2tpYyA8bWlsYW5f ZGpva2ljQGVwYW0uY29tPg0KUmV2aWV3ZWQtYnk6IEx1Y2EgRmFuY2VsbHUgPGx1Y2EuZmFuY2Vs bHVAYXJtLmNvbT4NCi0tLQ0KIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMgfCA0NyArKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0NCiAxIGZpbGUgY2hhbmdlZCwgNDYgaW5z ZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KDQpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9saWdo dC9saWJ4bF9hcm0uYyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMNCmluZGV4IDQxMGRj OThkMDkuLmRhYWE4MWYyYWEgMTAwNjQ0DQotLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2Fy bS5jDQorKysgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jDQpAQCAtMTMyMiw2ICsxMzIy LDQxIEBAIHN0YXRpYyBpbnQgY29weV9wYXJ0aWFsX2ZkdChsaWJ4bF9fZ2MgKmdjLCB2b2lkICpm ZHQsIHZvaWQgKnBmZHQpDQogICAgIHJldHVybiAwOw0KIH0NCiANCitzdGF0aWMgaW50IG1vZGlm eV9wYXJ0aWFsX2ZkdChsaWJ4bF9fZ2MgKmdjLCB2b2lkICpwZmR0KQ0KK3sNCisgICAgaW50IG5v ZGVvZmYsIHByb3BsZW4sIGksIHI7DQorICAgIGNvbnN0IGZkdDMyX3QgKnByb3A7DQorICAgIGZk dDMyX3QgKnByb3BfYzsNCisNCisgICAgbm9kZW9mZiA9IGZkdF9wYXRoX29mZnNldChwZmR0LCAi L3Bhc3N0aHJvdWdoIik7DQorICAgIGlmIChub2Rlb2ZmIDwgMCkNCisgICAgICAgIHJldHVybiBu b2Rlb2ZmOw0KKw0KKyAgICBmb3IgKG5vZGVvZmYgPSBmZHRfZmlyc3Rfc3Vibm9kZShwZmR0LCBu b2Rlb2ZmKTsNCisgICAgICAgICBub2Rlb2ZmID49IDA7DQorICAgICAgICAgbm9kZW9mZiA9IGZk dF9uZXh0X3N1Ym5vZGUocGZkdCwgbm9kZW9mZikpIHsNCisNCisgICAgICAgIHByb3AgPSBmZHRf Z2V0cHJvcChwZmR0LCBub2Rlb2ZmLCAiaW9tbXVzIiwgJnByb3BsZW4pOw0KKyAgICAgICAgaWYg KCFwcm9wKQ0KKyAgICAgICAgICAgIGNvbnRpbnVlOw0KKw0KKyAgICAgICAgcHJvcF9jID0gbGli eGxfX3phbGxvYyhnYywgcHJvcGxlbik7DQorDQorICAgICAgICBmb3IgKGkgPSAwOyBpIDwgcHJv cGxlbiAvIDg7ICsraSkgew0KKyAgICAgICAgICAgIHByb3BfY1tpICogMl0gPSBjcHVfdG9fZmR0 MzIoR1VFU1RfUEhBTkRMRV9WU01NVVYzKTsNCisgICAgICAgICAgICBwcm9wX2NbaSAqIDIgKyAx XSA9IHByb3BbaSAqIDIgKyAxXTsNCisgICAgICAgIH0NCisNCisgICAgICAgIHIgPSBmZHRfc2V0 cHJvcChwZmR0LCBub2Rlb2ZmLCAiaW9tbXVzIiwgcHJvcF9jLCBwcm9wbGVuKTsNCisgICAgICAg IGlmIChyKSB7DQorICAgICAgICAgICAgTE9HKEVSUk9SLCAiQ2FuJ3Qgc2V0IHRoZSBpb21tdXMg cHJvcGVydHkgaW4gcGFydGlhbCBGRFQiKTsNCisgICAgICAgICAgICByZXR1cm4gcjsNCisgICAg ICAgIH0NCisgICAgfQ0KKw0KKyAgICByZXR1cm4gMDsNCit9DQorDQogI2Vsc2UNCiANCiBzdGF0 aWMgaW50IGNoZWNrX3BhcnRpYWxfZmR0KGxpYnhsX19nYyAqZ2MsIHZvaWQgKmZkdCwgc2l6ZV90 IHNpemUpDQpAQCAtMTM0MCw2ICsxMzc1LDEzIEBAIHN0YXRpYyBpbnQgY29weV9wYXJ0aWFsX2Zk dChsaWJ4bF9fZ2MgKmdjLCB2b2lkICpmZHQsIHZvaWQgKnBmZHQpDQogICAgIHJldHVybiAtRkRU X0VSUl9JTlRFUk5BTDsNCiB9DQogDQorc3RhdGljIGludCBtb2RpZnlfcGFydGlhbF9mZHQobGli eGxfX2djICpnYywgdm9pZCAqcGZkdCkNCit7DQorICAgIExPRyhFUlJPUiwgInBhcnRpYWwgZGV2 aWNlIHRyZWUgbm90IHN1cHBvcnRlZCIpOw0KKw0KKyAgICByZXR1cm4gRVJST1JfRkFJTDsNCit9 DQorDQogI2VuZGlmIC8qIEVOQUJMRV9QQVJUSUFMX0RFVklDRV9UUkVFICovDQogDQogI2RlZmlu ZSBGRFRfTUFYX1NJWkUgKDE8PDIwKQ0KQEAgLTE0NjIsOCArMTUwNCwxMSBAQCBuZXh0X3Jlc2l6 ZToNCiAgICAgICAgIGlmIChkX2NvbmZpZy0+bnVtX3BjaWRldnMpDQogICAgICAgICAgICAgRkRU KCBtYWtlX3ZwY2lfbm9kZShnYywgZmR0LCBhaW5mbywgZG9tKSApOw0KIA0KLSAgICAgICAgaWYg KGluZm8tPmFyY2hfYXJtLnZpb21tdV90eXBlID09IExJQlhMX1ZJT01NVV9UWVBFX1NNTVVWMykN CisgICAgICAgIGlmIChpbmZvLT5hcmNoX2FybS52aW9tbXVfdHlwZSA9PSBMSUJYTF9WSU9NTVVf VFlQRV9TTU1VVjMpIHsNCiAgICAgICAgICAgICBGRFQoIG1ha2VfdnNtbXV2M19ub2RlKGdjLCBm ZHQsIGFpbmZvLCBkb20pICk7DQorICAgICAgICAgICAgaWYgKHBmZHQpDQorICAgICAgICAgICAg ICAgIEZEVCggbW9kaWZ5X3BhcnRpYWxfZmR0KGdjLCBwZmR0KSApOw0KKyAgICAgICAgfQ0KIA0K ICAgICAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fZGlza3M7IGkrKykgew0KICAg ICAgICAgICAgIGxpYnhsX2RldmljZV9kaXNrICpkaXNrID0gJmRfY29uZmlnLT5kaXNrc1tpXTsN Ci0tIA0KMi40My4wDQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441865.1659470 (Exim 4.92) (envelope-from ) id 1xEFBu-0005Gf-7e; Wed, 07 Oct 2026 00:07:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441865.1659470; Wed, 07 Oct 2026 00: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 1xEFBt-0005FL-Rz; Wed, 07 Oct 2026 00:07:25 +0000 Received: by outflank-mailman (input) for mailman id 1441865; Wed, 07 Oct 2026 00:07:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFBr-0004kq-TR for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFBr-006Hhb-AD for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:23 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d31-2eae-0a2a0a5409dd-0a2a4502b47a-8 for ; Wed, 07 Oct 2026 02:07:23 +0200 Received: from [40.107.159.102] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d3a-6ca4-0a2a45020019-286b9f660fa9-4 for ; Wed, 07 Oct 2026 02:07:23 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by AS4PR03MB8229.eurprd03.prod.outlook.com (2603:10a6:20b:4fb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 00:07:20 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=b/B52BE2llkfVBCIIdyUKyD/CRJI2fJpIj1zdRnBgjCiJ7rBI14mdZ+V1oL7VuAkL5kpkzLSuzgXsQptHqGy5/LLDLELC8CatFx21evWl7lEJtEhIwWwhZpPSZZEPrhdaZJQWjCvD37sFj7PUbSvFhe14p6ZmOqwwOtP7DpYHwi1vAPlBq/g61Y3bO4hiwz52xdhDVMoPMN6dswCcVzaSNqJUN0kNaZvgWlofVuAlQ/IJRBL4oatAz/G06VCqSUhD7egFC5ML+eocsa0GxEo5VaSFpnu+1f7JDD5NtnFxqYzTQoJ9Doip0kSDPzcprSep37SlRLpxdxn8irkRoe4CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1QGjg9ezIGvEpFCVh2gO3DGpM70Awc+cA84nC1Wmbgc=; b=ejytKZBfbB2JW4x+WYIvAp9CucuFku0GFcimI3T985JFcEVWokutDaZIbWnyQVqWNvCHYHr4lEuwfeT672jO3c+BgJa2+QZBCcU3Vp8TcvdBAbJio2RZe0FxeQvNcDacpsnqkwav9KIPsyrUs+K7TBxWJzi+OQA81tfxToJkzEdnq+C3bWndYqVVZas74g01Wv7PLeW+q354+x+8SbGiG1EqKAf0bqT9Rg8DBEBL4qUPnq/XlrzVtIBcz0/l6X6t01459sxTJ07rjlkjbSoQxY8J07KQqV2JI25hvJ+mDCW8Dt+26n7dFHEh1n3u/7T8L2XwmYks5iJAvG4BPF6QZQ== 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=1QGjg9ezIGvEpFCVh2gO3DGpM70Awc+cA84nC1Wmbgc=; b=Xx+rfEgs6f7zdJ9D9Yq6sj9zETCbSTo0Vm4eSyM72IcE5u7DUMz8fQF8K0s+KC3U+RR2m2vwv9QABYmPta/xBSKQT6393UrJsDIwsJrQQ3Tj/5KrVAMy3/498smc5jrwcOtpEGVKKFWAMszWhoMZw/2XnX59H35n2y0Ov5VsPiXDOSeKGHZqMjWTY3bKvjKNfNNJ/LtqpPl16YtUVC1cHm6fv1BvctwZVjW+2SWaUVmhQ4pzZ+Gv24k8MlM18aSufKB/qPjbbtb72WO7uGTvDWB3x84RRLDxpsmj9dH16bBCURNbNUXkoetztEsqHzDM6gugOF5YAoKWK4xQPwJDWQ== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Milan Djokic Subject: [PATCH v4 19/22] xen/arm: vIOMMU: Modify the partial device tree for dom0less Thread-Topic: [PATCH v4 19/22] xen/arm: vIOMMU: Modify the partial device tree for dom0less Thread-Index: AQHdVe/RXw5lTx+Dsky6l5wgBOVJ2g== Date: Wed, 7 Oct 2026 00:07:18 +0000 Message-ID: <9e31544f751d8a9708e1e6385da1b3ac6a438153.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|AS4PR03MB8229:EE_ x-ms-office365-filtering-correlation-id: 49a77cad-c299-41b2-5340-08df2406f502 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|56012099006|11063799006|10067099003|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: e4toScgIDundB/oYEISfpuecXze3CVGZtJ+OMp0Jo2wHNY9yn9hF4W6lOCF8dg8cGZJtAlAqicb0avFXRMsw9Te/LoVy+n2jwNbgeScGuZzypaHeWYCkkO0uFB/IhIKKinhTXHj8oCfmN/CAj8OAiLuM7Vuaq3eBNEXD2KslvMIR4bMna15ouXy+ORfTpp6lsP89/rNU+icWoUU/m+fCTznrC2EunpB6t5H4VZ84MvSsYNtVyq4epMfpFzzAl+M2v+aSu/MYhlco2nZU8hjWU0EAeF8duuM0Gm7TlbgtwKMwNWXv78Uwbd8YEJOu2wOYgMoRs+krf9PXT27Lh4sx+icdUCEN6M0H1Mp4q2u9Ml+Sh4mJivZfW2BWYc2SknjP/hb2ji4XnncYLswaMs6YYx95t4ODjuPglNHe6SKY+oC4i4RIehM75wwFMt4Wm8L1yWK5wLzlfOyV3BwY8AAzeNLsieCytzuOHnyqq9QI8mByXl1kxOF38m6EJtURaeOe7YJNyAfJ4p0n8toXduLFsPZTJ57V3DJuYCnSqhWDMTHSYgsEB2AW0b/bSX8ipWNjOo0hctHAtw1TqTNInBTGdezjF42/45nvutPymV2pKfhzEsMpFOjr7EPmtcmPZPzCTb6gIZRddw81wrJCqIAuKGtoxfUkgaMFXjYqNMkoIPm977uZ1749G/m+1jduyVEKZxO1CTcYUqf3Ad7Bgtdz6szp8dp6IIdAnUXQ26uj4ks= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(56012099006)(11063799006)(10067099003)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WGtjNjlaWmV3MnVNOVRZcFJaSWtGMEFmbWF1VElPMmhVMlUyTWkyZTlJdTd1?= =?utf-8?B?MDRLMUVxbVNXV3NJNTRFZWtqbW5FSmltMWdlNVBsQnFmbHJXZTE1VVlXZzBi?= =?utf-8?B?eUl5aVo0WFdnOWFjbjJQZGVmWnRTZ28ydHRQbE91NVY1QUpEckZxL3hKMEhx?= =?utf-8?B?MW5Vd3M2L2Q1dHc4WExDbG1UODljQXdWUDIxRXpFWTQ5dFJ1MzAyRlNOQWdl?= =?utf-8?B?VTZ1N1o1SDRqZDlocXF1MVgyZkNsenpxM3ZJbWZXNDZGY3RVbEg5L09UK3Q4?= =?utf-8?B?NVFFcStSYW5aWW5IelAvNEJmZjMvTjdNNXZCL2ZrTXY0ZmF2a05BZEhaTjhI?= =?utf-8?B?OEZVdURFNmVPRG0ycG5Ta1hRY1ZMaFBjQ2Z3MzlLMGgyL1g4TzRtc0xiSEpZ?= =?utf-8?B?ckkzNTlOcVRmdHNjM1JPU3JFVGlSRXhCWFZvTUZpaExYVmJabEx0WlpWRlZj?= =?utf-8?B?TTRjbFgzcXZ0ZzlXTldKM3Y4QjBvTko1N2dCY29jQVkwUGRGMUkycjBhb1hI?= =?utf-8?B?MkVQMGRrSVB5OGduRWg2WG5wNWpCNWFEdVI4ZlRETGtkVDBDWHZCdldiTEpW?= =?utf-8?B?YnVaV1NyRnhwanBVdVA4d09ncDB0Y05BbGZUbzFPY3crZmNjeFlmRVpjUGhL?= =?utf-8?B?cE9WZVVGSU5LaHFnbEc1Nis3UHh6UzdmbWFERDgyV0J2OWMzZElmcEhtaFNv?= =?utf-8?B?MG1ZK3VJL29PN0JqTlNhMnpaclZ2bDZpS3Rub21sQjArbkI4Qk1GMGEwcHJR?= =?utf-8?B?OW42Nms2WGtnY1NVaXhqbHVQTlJ3L05xekVMNWhqQ2djdzhTMHdSSWI5U1BK?= =?utf-8?B?Z1NOUytCeEtyRkZRaFd4cU92Rk5vTWhSQUZKOVlMQU53UWhYYmZ4NE1uZkF1?= =?utf-8?B?Y3ZEQXUwZ1pURnMxSlUvV2Jhb1dDUytmSGl0LzFRVSs5Uy9jcXhSNXV6Undm?= =?utf-8?B?Q2UzSC9DaGU5elhUN21Wa3ZhRDRvVnlaVDVGRUxPWDNSeWlBVHpsZHNVS1oy?= =?utf-8?B?VndjSCt0ZVU2VXd4MmkzTFhBejdWK2pVbytyYS9uWGZoWGpKemtRSzdKbGlQ?= =?utf-8?B?TkM4cUNBVmdhZ0xjL1NDUGp2czRxQ1pmM0FDUGVTSHpIcmpyM0EyNDBnRTlj?= =?utf-8?B?Nlo1eVMvOU82UjBTOFlzT2ppVG5PUXhCK3VDbWNsa3JURyt3UlloZHhyaUlj?= =?utf-8?B?T3l1VXpJWjRKVm9ad1J2SDY2amxzSElpVm5QeW5yUTEyVkVTOGk1bTJjMUxM?= =?utf-8?B?N0pmWVdhQkswSFY4bGpZN0xRRXNxYUx6NnpzVThKaVJ6ZERJQU9lV083bDhP?= =?utf-8?B?SFRNeU80WkRET2ZkaERvQ3p5ZGp5M1FLK0dlaU5wS25aNjF6ZjBpTHVLakZj?= =?utf-8?B?NGt0NlBYK29qZHVFRDdsQ0ZFai8wdDBFSmJGcWhMc0ZreUtoVEVIMDYwNk1V?= =?utf-8?B?Q09LQlRBSEx3NVJwdDRxbHJ4YmVoZjE4cG11OWZuNG9ldE4xWVlvQVB3N0JQ?= =?utf-8?B?d2JSSlYrVm1PVzRMSWNjNUJQZTdiUXc2eGVKWEFVbmtHNVlBU2lKQjhteEpG?= =?utf-8?B?T05vMGxOUjE0VE9yYXl6WjRmclZjTmE4OGszQ1A5bUlpdVoweVlmN0kwUWIw?= =?utf-8?B?c2pMeUlrWjdOZ3lMWDlOQTgvYmliaFJKWWU0S2RxWi9BNFpPNUcvbnhnSlNI?= =?utf-8?B?dVhUVEZtV1BpSHZQbTNMa0NqUG9tYmpCSk45bW4xQmJ1ekhCWGlUS2xMS2x6?= =?utf-8?B?NWRNR2F5U090SHVOdU8xL2lUbEZ1Rm9icVozSXFuWGlvMGZkY2NyMlJVak1H?= =?utf-8?B?ZnI1YXZvTEFVZ2V6V3laVXNRMmFXK0hHRE5KVWIrbGVnMmNiOW85MDhUTVlX?= =?utf-8?B?ZDdNbVVOSUh1Ulk4Z0x1ekRSYXVhdWViOUZIdTNTMzdxS2s0ajBxWjgyc0sw?= =?utf-8?B?K09EWTFlZ1NhWE5aOE1yV3NwK1NmVmdEUWY2bHZLcktkaVRGV2Z4NldYWStI?= =?utf-8?B?eVdEMFNGUDdFbXl2RCtHUDNhUExPamhDL3RnK3Zra1lFVzZMOVE1NWJnbHRW?= =?utf-8?B?VTcvRWRHVFlSUnVRU2hFdFdibkk1Z2NZMVZzOXNuQkFFYngrelhRcXRobjhG?= =?utf-8?B?bHFkZVdsR3NUQ1c5azljc1l2TksxQVRsczlsSDFjRU1jb1lVSlJtU1lGU1hj?= =?utf-8?B?cGt4bHBCNFFBT3pqdmp3YnIxTGJKc0RVRHpUUUNXV0FGVVNyWkVlNTJFblB4?= =?utf-8?B?N21seXZMQUVUNnBqcVIzb0Z6OSsrNjZCUHdEYlg1cHlCUEVtYW9OTit0WUxL?= =?utf-8?B?a2libU9zWkMvQ0wxWUczN0ZvQWZWcDAwUFFKY0RtRWs1Y1p4Q0xiUT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49a77cad-c299-41b2-5340-08df2406f502 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:18.4107 (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: 0DC2k6wac7kV+R2zjg9/dNIY4VvSuo2J33GuY7AIcELdjyGt3/TE/90M9x5FUalDcQJMo//iUFdAyfPOP27qSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8229 X-purgate-ID: tlsNG-720697/1791331643-F34BE2AC-2B895AF9/0/0 X-purgate-type: clean X-purgate-size: 3568 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNClRvIGNvbmZpZ3VyZSBJ T01NVSBpbiBndWVzdCBmb3IgcGFzc3Rocm91Z2ggZGV2aWNlcywgdXNlciB3aWxsIG5lZWQgdG8N CmNvcHkgdGhlIHVubW9kaWZpZWQgImlvbW11cyIgcHJvcGVydHkgZnJvbSBob3N0IGRldmljZSB0 cmVlIHRvIHBhcnRpYWwNCmRldmljZSB0cmVlLiBUbyBlbmFibGUgdGhlIGRvbTAgbGludXgga2Vy bmVsIHRvIGNvbmZpZ3VyZSB0aGUgSU9NTVUNCmNvcnJlY3RseSByZXBsYWNlIHRoZSBwaGFuZGxl IGluIHBhcnRpYWwgZGV2aWNlIHRyZWUgd2l0aCB2aXJ0dWFsDQpJT01NVSBwaGFuZGxlIHdoZW4g ImlvbW11cyIgcHJvcGVydHkgaXMgc2V0Lg0KDQpTaWduZWQtb2ZmLWJ5OiBSYWh1bCBTaW5naCA8 cmFodWwuc2luZ2hAYXJtLmNvbT4NClNpZ25lZC1vZmYtYnk6IE1pbGFuIERqb2tpYyA8bWlsYW5f ZGpva2ljQGVwYW0uY29tPg0KLS0tDQogeGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1i dWlsZC5jIHwgNDAgKysrKysrKysrKysrKysrKysrKysrKysrLQ0KIDEgZmlsZSBjaGFuZ2VkLCAz OSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQoNCmRpZmYgLS1naXQgYS94ZW4vY29tbW9u L2RldmljZS10cmVlL2RvbTBsZXNzLWJ1aWxkLmMgYi94ZW4vY29tbW9uL2RldmljZS10cmVlL2Rv bTBsZXNzLWJ1aWxkLmMNCmluZGV4IGZjYmViOGFkYmQuLjcyODBiY2Y3MmIgMTAwNjQ0DQotLS0g YS94ZW4vY29tbW9uL2RldmljZS10cmVlL2RvbTBsZXNzLWJ1aWxkLmMNCisrKyBiL3hlbi9jb21t b24vZGV2aWNlLXRyZWUvZG9tMGxlc3MtYnVpbGQuYw0KQEAgLTMzMSw3ICszMzEsNDQgQEAgc3Rh dGljIGludCBfX2luaXQgaGFuZGxlX3Byb3BfcGZkdChzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZv LA0KICAgICByZXR1cm4gKCBwcm9wb2ZmICE9IC1GRFRfRVJSX05PVEZPVU5EICkgPyBwcm9wb2Zm IDogMDsNCiB9DQogDQotc3RhdGljIGludCBfX2luaXQgc2Nhbl9wZmR0X25vZGUoc3RydWN0IGtl cm5lbF9pbmZvICpraW5mbywgY29uc3Qgdm9pZCAqcGZkdCwNCisjaWZkZWYgQ09ORklHX0FSTV9W SVJUVUFMX0lPTU1VDQorc3RhdGljIHZvaWQgX19pbml0IG1vZGlmeV9wZmR0X25vZGUodm9pZCAq cGZkdCwgaW50IG5vZGVvZmYpDQorew0KKyAgICBpbnQgcHJvcGxlbiwgaSwgcmM7DQorICAgIGNv bnN0IGZkdDMyX3QgKnByb3A7DQorICAgIGZkdDMyX3QgKnByb3BfYzsNCisNCisgICAgcHJvcCA9 IGZkdF9nZXRwcm9wKHBmZHQsIG5vZGVvZmYsICJpb21tdXMiLCAmcHJvcGxlbik7DQorICAgIGlm ICggIXByb3AgKQ0KKyAgICAgICAgcmV0dXJuOw0KKw0KKyAgICBwcm9wX2MgPSB4emFsbG9jX2J5 dGVzKHByb3BsZW4pOw0KKyAgICBpZiAoICFwcm9wX2MgKQ0KKyAgICAgICAgcmV0dXJuOw0KKw0K KyAgICBmb3IgKCBpID0gMDsgaSA8IHByb3BsZW4gLyA4OyArK2kgKQ0KKyAgICB7DQorICAgICAg ICBwcm9wX2NbaSAqIDJdID0gY3B1X3RvX2ZkdDMyKEdVRVNUX1BIQU5ETEVfVlNNTVVWMyk7DQor ICAgICAgICBwcm9wX2NbaSAqIDIgKyAxXSA9IHByb3BbaSAqIDIgKyAxXTsNCisgICAgfQ0KKw0K KyAgICByYyA9IGZkdF9zZXRwcm9wKHBmZHQsIG5vZGVvZmYsICJpb21tdXMiLCBwcm9wX2MsIHBy b3BsZW4pOw0KKyAgICBpZiAoIHJjICkNCisgICAgew0KKyAgICAgICAgZHByaW50ayhYRU5MT0df RVJSLCAiQ2FuJ3Qgc2V0IHRoZSBpb21tdXMgcHJvcGVydHkgaW4gcGFydGlhbCBGRFQiKTsNCisg ICAgICAgIHJldHVybjsNCisgICAgfQ0KKw0KKyAgICByZXR1cm47DQorfQ0KKyNlbHNlDQorICAg IHN0YXRpYyBpbmxpbmUgdm9pZCBfX2luaXQgbW9kaWZ5X3BmZHRfbm9kZSh2b2lkICpwZmR0LCBp bnQgbm9kZW9mZikNCisgICAgew0KKyAgICAgICAgcmV0dXJuOw0KKyAgICB9DQorI2VuZGlmDQor DQorc3RhdGljIGludCBfX2luaXQgc2Nhbl9wZmR0X25vZGUoc3RydWN0IGtlcm5lbF9pbmZvICpr aW5mbywgdm9pZCAqcGZkdCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQg bm9kZW9mZiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBhZGRy ZXNzX2NlbGxzLCB1aW50MzJfdCBzaXplX2NlbGxzLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJvb2wgc2Nhbl9wYXNzdGhyb3VnaF9wcm9wKQ0KQEAgLTM1Nyw2ICszOTQsNyBA QCBzdGF0aWMgaW50IF9faW5pdCBzY2FuX3BmZHRfbm9kZShzdHJ1Y3Qga2VybmVsX2luZm8gKmtp bmZvLCBjb25zdCB2b2lkICpwZmR0LA0KICAgICBub2RlX25leHQgPSBmZHRfZmlyc3Rfc3Vibm9k ZShwZmR0LCBub2Rlb2ZmKTsNCiAgICAgd2hpbGUgKCBub2RlX25leHQgPiAwICkNCiAgICAgew0K KyAgICAgICAgbW9kaWZ5X3BmZHRfbm9kZShwZmR0LCBub2RlX25leHQpOw0KICAgICAgICAgcmMg PSBzY2FuX3BmZHRfbm9kZShraW5mbywgcGZkdCwgbm9kZV9uZXh0LCBhZGRyZXNzX2NlbGxzLCBz aXplX2NlbGxzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY2FuX3Bhc3N0aHJvdWdo X3Byb3ApOw0KICAgICAgICAgaWYgKCByYyApDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:07:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:07:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441906.1659485 (Exim 4.92) (envelope-from ) id 1xEFCK-00085D-Ir; Wed, 07 Oct 2026 00:07:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441906.1659485; Wed, 07 Oct 2026 00:07: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 1xEFCK-000852-FK; Wed, 07 Oct 2026 00:07:52 +0000 Received: by outflank-mailman (input) for mailman id 1441906; Wed, 07 Oct 2026 00:07:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFCI-00082J-V1 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:07:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFCI-007OBc-Bs for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:07:50 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d32-bab6-0a2a0a5309dd-0a2a4505c5b6-16 for ; Wed, 07 Oct 2026 02:07:50 +0200 Received: from [52.101.66.74] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d55-4cb1-0a2a45050019-3465424a4723-4 for ; Wed, 07 Oct 2026 02:07:50 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by VI0PR03MB11456.eurprd03.prod.outlook.com (2603:10a6:800:321::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.23; Wed, 7 Oct 2026 00:07:48 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=erWlWiFX1tK96fyKO77cPcr0PisnDGpTUQg5xee8J/Y4Q2Y2rAzfb7W3zwaCtH8/MtzTcazAuUdl8vnBJLJuR24uC4T4IO4evNyVUQHNLM4yf8JGnbUIew/sNquEBFSL8lOSLbBdwW8MdtPGCl0UGgGa/cXEGVs++YJkAYJNfaW8avP14DaNaOE6gcX/0h/HsIFezRPu9WHcV5zymu3YByNUeFyR1OAg7/RrVaqo9Jc7JvrAaWF/vR0dYya7y5T8Y+d7u+7Bbx04XhAQGGtIJzFP+D3P4J0fKs1zDqzEe2csFfxWEAuR2v5IJt2o1f7IkESKvYW/jge6LppC2WCyGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Pbj4z58icua1HOpqgjmSmnNPacDmhA7QsAerpPMrAXA=; b=DTTSiXQ/ewIV6QO/Bv/snIr8eA2tXC+1UnEdSvYscjH257rQl4TCw5TOCKZNoSPM4cJnB4KiW810WHAGE27wcM9VTeobrMZUDjcKCtLL1fLeRwIrQOO7jKgs0iTlRdKm4a7InjruzPPNkCN/VPOu2Oud4DstIcLPMRcRtuGNmBp5GiNoVx80jt6nLfgoBh4XA9q+rwA569HNinBsMYCoMx1mXjcTHeg0j0yBNTELujPy3ZFmh4Pip1vKuicKz2PG/x1kyNGF7K3tVjy1bOxMRTnFaT4VTa4SCnO24CuYALUgMQo3wxMdDgdK6QWW8w3P0C8aVOIIh9LjvF1T6UsPMA== 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=Pbj4z58icua1HOpqgjmSmnNPacDmhA7QsAerpPMrAXA=; b=hbtI02sl1m2Nge5Dp5zJEGX7fTY2IruTGX6naU1XnXHy/xbYxN7qlUMPu36Hq0/lOtNY6tZ2fVMkntfHS8GCeYehivkBbswnzBCOCF3xW2ncmQi+OEEHGFNEXsUUuX3TuPMA4nV70JpaLYaPP6M78WlnIyBlGVP+KGF/CS2ah4Z4mdPZHddQTQ3u4pp5Why0ueY+Y5I1Lu1ia1Z2Dczjjw8sksza2ryh30L7H8sX8p/peOuIfteLUrGuaFl7IGHpLqbz3iwNJBP/J9eplEF7WTVddOG9FbpGp34OPV3hCvatkORpxHgJmQbzLxf0NmchZy1UVwW2kHdPJsUlQqWyrQ== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Milan Djokic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: [PATCH v4 20/22] xen/arm: vIOMMU vSID->pSID mapping layer Thread-Topic: [PATCH v4 20/22] xen/arm: vIOMMU vSID->pSID mapping layer Thread-Index: AQHdVe/i3kDbHaGIyUybXW8+ElOD4w== Date: Wed, 7 Oct 2026 00:07:48 +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: 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: AS2PR03MB9587:EE_|VI0PR03MB11456:EE_ x-ms-office365-filtering-correlation-id: 99dbee36-40cc-4aa3-36c1-08df2407054c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|56012099006|38070700021|3023799007|10067099003|6133799003|11063799006|22082099003|18002099003; x-microsoft-antispam-message-info: Pyh9Bh+1fzryePTIOsV1UnuWvKa8+7J4ie9JoGGWh85fz17NbC8axGkygylEV6GFqXttHgD58aFqRboqi5NyfzAVTDfeqAV3Mvkb/hmjEgQX74ZIO6Xdc3e3BWV/nMDSPIkisat8s1Tj9lDGZWQU11KrfCMBOJhz6dNh2mF1QotcZHuvglEPhq4NQobfcbf66zWA5VsASVnHXTnrRbKIewk7GBXNpviwT2Vqg9HRuFlvTXuL8QgmGBiyEiLc1e6UBydA/YvRpoBAkxZuylKtpAMe7UbhFsdecQtMKGkksDR8h18puOkZstKr0QvJkskpkbyw0iQv766cyFH3YlE2lv2RgMVeF01veQNwZ/0dsy0Qart8AUQhWCL2zlGkrGM62iTZGTQ73VWGX4hdEYb+4aWqoGPa67lGlLFJYiK6yGUqaN/yD+GGoWWoJwg/doZozFJyPz9y0WuQCMXX9jI5nNIYSC1Mx3nPXLqEKnEv3G0zK2IbBgMOky0WX7jHteuy5AZidXePZ6kRlekNLEIKXvrflegKtYsgH0Bq48oFnnwij2MoGzvisDw1zVKCuxc4rYYfU+zum5WvlM/+7vNjoJz/AXxOh+311PMdv5SejUkS0N/u5FJUFioyqiam37exLr0JsCx4xe7bGsotlQMBDRegkQB+gt1Q44220bdcnYCBLN3v7T+xW29HTC8HR4Tlgt7AYqUKwfgdp3kQyFhrab8cX0KpfeJ4aCnWTGW5Ykw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(56012099006)(38070700021)(3023799007)(10067099003)(6133799003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?L0ZPbm9vcUIvd2ZmdEZaV0dQRE1GMmRZQU1OT2xpWWRmcXgyOTNad0dOOC9C?= =?utf-8?B?N1RsV0ZrTDNjeUlCNVFObGM2Ung1aDFDOGVQRmVqdnVqUGdUc3phQ1NoUCt0?= =?utf-8?B?Y29RMFlZVG5Pd1JrZkFETXdaMTlQaS9lZzZJOUxuSnFWa1pvRStBd2xSeFhB?= =?utf-8?B?VXpUWldVa24xSVlxaHh0NGdCUk5rZ3A3YTAyK3RHbkVnd3JUamV3V1B5RG9x?= =?utf-8?B?QU91czBLaFFmS29OVnZ2UlFJWHpEaU45aXlNeXdIVWhMTmI0OExMU3ZGN0JM?= =?utf-8?B?TTZTWkN2dnZZVFNwdWhvYjdyVnA0aW9ORHN2TEZkRVB6ZGJScHk1M0JHUzB6?= =?utf-8?B?cEpPNkFCV1lhVGFadHdyRkpKbEV0eEFlUWcvUmprTFNGUDZPT0tOZ2VZU21q?= =?utf-8?B?NC9McERsWTUxbE8vRlBzV0hRQ1pzVGx3dEQrMHRiL1J4WS9JSTI0YnNTMmtL?= =?utf-8?B?ak1xVHNjbGRHOUhjcWNSRG9DYlNaeGJ0VkhWMHZsNmVZUkViOEpvTDhDZEM5?= =?utf-8?B?VU5mWFh3MWxPcmdTempPSGw3MERBSkJ1clNyL1JKeWh2SlUxUnpUTk9mQU5u?= =?utf-8?B?OWlNeHh2V2VwRFI1THlSWXZtdUN4UFJhL292SzA1blJsa2x6MDJHeUx4Ukds?= =?utf-8?B?VUlSdnliWHUxdlZsZG9QNnRVVHZhUGhKcW5IRUJFU2hodktaS2xqdHRpRGtH?= =?utf-8?B?WHM2a2pBZ1JEQisrNUNLUjRVOFllTjFzN0dMdTY4WDNUcWxoZWNVMnduY3du?= =?utf-8?B?ZEsyOEM3WjZ1YWVxTHFnK1JEck9BVytlNXZneEFlMzZDWVI1aVgyT0FYejEz?= =?utf-8?B?SWpQUmpUUE55M2dXVWVGcFhqVldQaEFQQS8xSTFlbHVaa0VFVjJXMWZ3dWNu?= =?utf-8?B?a3M4NTBnYjRnVDlYR25lamE2Y3FzTmZZNmJEODZVOC85Z2pjVG1EdTdLQ1dl?= =?utf-8?B?cHJlK2JHMWs4eFpBTnFTMUJXS1BaL252Y3RFL3ZEZE5saDJZK1pFc1hvUWRp?= =?utf-8?B?TElCYVEvQjQwNVF0Vkx2d0dub1h4VUdURjZOUFVJWElwdVgvU0RGUjA3ZVBC?= =?utf-8?B?cGp3WDZlK1JrM1pPSkttVXNuMk8zKzlRK3RSdTFmenBpRjVZT2FQRFJnSXpH?= =?utf-8?B?a2dmTjQ4ZkczcXRwY0Q0a3ZKSEpUZWJ2Y0JQYkpsaFlkdUhaeUhYZ01HRTFE?= =?utf-8?B?RDczdWZNbVNraXZncTJXbEZZVlVCUHArOVluWndJRWVHaG9USmw2ZmIvY1Zr?= =?utf-8?B?U0JvK0t1aTN1RzY4dG14SWZTazF4WTFWY25hU2RnQWRtcHFnM01XckFxQVEv?= =?utf-8?B?UnVKN2FBeE13RzZGL3RoZ2U4QjJZb0hYNUx6RDhhekltWGFRYVhVNDU5MDZN?= =?utf-8?B?eUUxajAvdm1kQUpUV1BnTEdKd05uSldvbjZBVnV2enFXL0w0Smxjc0I1UDhv?= =?utf-8?B?a0kwZ0hzVzM5K2xqMlc5cHlGRy9rKzZUQ3Y1aDFoYlEvNE5sUktNa2NEMUU1?= =?utf-8?B?SjJackhFVFFVOUpzekdmV1VxMmNaUWFMZDJIQW1zYUx2dXNmWmx0Rml5Q0lQ?= =?utf-8?B?UVVIcW5SMHN6UnBVMDh3czJFYWtKZm5hYjZ4Q3pmdmRzd2xJa0J6TGhpNVpG?= =?utf-8?B?TUkzdnJVUHYvMnVXZk42eWpJNUhSWGN0NjdZUnpIL25CMXU4dllCZzgxazUr?= =?utf-8?B?aFArMkJoSmFaSW1JTlJZWXNjZS8rQ3BkRjNnQ21RQzU2dmJIZDNsaEQxaE5E?= =?utf-8?B?bnhsVmxWT3VuQ2thc1pReCtmQnIxalpPS1d0a2ZKd0dOMllCVU1hTERaZVlS?= =?utf-8?B?MnZBSXpaN0RVU2NMbmRvVEVZai9GRXVCOTN6ei9TUGY5Y1RTeVJpNjVVZG9R?= =?utf-8?B?KzltR2VWUU12R2NiS3E5MTBEMkJnd3JSaTFHNWg4UDBKa0wvTHROWExJN1l0?= =?utf-8?B?c1dRZWs0a1FxY09FNWRtZ1ArcURGSmZIV1hMQ3kyMTdncSsxTXRsb1FzLy9L?= =?utf-8?B?RVVOSUgycUZuaFJtV1NjMDRKWjJDUlhJOUloVGJoNmJwNXN5VXp5M3FyZVVM?= =?utf-8?B?eWZQcXJvSmR6djVLaDBQdUU1RzlGaDF1akhlMmlNR3I0NGt0OStzR09GUnFs?= =?utf-8?B?M0dDTGRCRHdaZjNTR20wczllWGtmMkJSbVlEem96cmNqcG11bS95a2lSLzdq?= =?utf-8?B?dStvT3lhZUhIVFl5YlZ6MFVjcGcwN2R3S3ZoeWcvQm5IMzBjZzJGVDNVOFlC?= =?utf-8?B?aGR0Z3ZqK0RwNEFGWGZSdjduSStxY0swaUtJc2hQRThtOVRqc1hxUWhIRjFG?= =?utf-8?B?WnIyYXVVRlh5S0pyYTJYWFpkRi9VSDlLWHdUWi9JSDJaU1lBVisvQT09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99dbee36-40cc-4aa3-36c1-08df2407054c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:48.1592 (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: fXO9TugTVRf9MFIdSnIAOQNpkZYXfaBXTl9HxWaeaM6mV24UkjNpY822w7whPJnxtrHhgJY52eht3BkR1N6lNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11456 X-purgate-ID: tlsNG-c201ff/1791331670-F58AE2A1-137A2651/0/0 X-purgate-type: clean X-purgate-size: 20802 SW50cm9kdWNlIGEgdklPTU1VIG1hcHBpbmcgbGF5ZXIgdG8gc3VwcG9ydCBwYXNzdGhyb3VnaCBv ZiBJT01NVSBkZXZpY2VzDQphdHRhY2hlZCB0byBkaWZmZXJlbnQgcGh5c2ljYWwgSU9NTVVzLCBp bmNsdWRpbmcgZGV2aWNlcyB3aXRoIHRoZSBzYW1lDQpTdHJlYW0gSUQuDQoNCkFkZCBhIG5ldyBn ZW5lcmljIHZJT01NVSBBUEksIHZpb21tdV9hbGxvY2F0ZV92c2lkKCksIHdoaWNoIGFsbG9jYXRl cyBhDQpndWVzdCB2U0lEIGFuZCBtYXBzIGl0IHRvIHRoZSBpbnB1dCBwU0lEIGFuZCB0aGUgYmFj a2luZyBwaHlzaWNhbCBTTU1VLg0KDQpPbmNlIHRoZSBtYXBwaW5nIGlzIGVzdGFibGlzaGVkLCB0 aGUgZ3Vlc3QgdXNlcyB0aGUgdlNJRCBmb3Igc3RhZ2UtMQ0KY29tbWFuZHMsIGFuZCBYZW4gdHJh bnNsYXRlcyB0aGUgdlNJRCB0byB0aGUgY29ycmVzcG9uZGluZyBwU0lEIGJlZm9yZQ0KcHJvY2Vz c2luZyB0aGUgY29tbWFuZCBvbiB0aGUgcGh5c2ljYWwgU01NVS4NCg0KSW1wbGVtZW50IHVzYWdl IG9mIHRoZSBuZXcgQVBJIGZvciBkb20wbGVzcyBndWVzdHMuIEFsbG9jYXRlIHZTSURzIHdoZW4N CmNyZWF0aW5nIHRoZSBndWVzdCBkZXZpY2UgdHJlZSBhbmQgcmVwbGFjZSB0aGUgb3JpZ2luYWwg cFNJRHMgd2l0aCB2U0lEcw0KdGhhdCBhcmUgc3Vic2VxdWVudGx5IHVzZWQgYnkgdGhlIGd1ZXN0 IGRyaXZlci4NCg0KU2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxtaWxhbl9kam9raWNAZXBh bS5jb20+DQotLS0NCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmlvbW11LmggICAgICAgfCAg MTIgKysrDQogeGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1idWlsZC5jIHwgIDMzICsr KysrLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jICAgfCAgMTAgKyst DQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3Zpb21tdS5jICAgIHwgICA5ICsrDQogeGVu L2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMgIHwgMTA5ICsrKysrKysrKysrKysr KysrKysrKysrLQ0KIHhlbi9pbmNsdWRlL3hlbi9pb21tdS5oICAgICAgICAgICAgICAgICB8ICAg NiArLQ0KIDYgZmlsZXMgY2hhbmdlZCwgMTY1IGluc2VydGlvbnMoKyksIDE0IGRlbGV0aW9ucygt KQ0KDQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oIGIveGVu L2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oDQppbmRleCA1YWUyMTA0MmYwLi4zZDBlYjky NjU1IDEwMDY0NA0KLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3Zpb21tdS5oDQorKysg Yi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vdmlvbW11LmgNCkBAIC0zNCw2ICszNCwxNiBAQCBz dHJ1Y3QgdmlvbW11X29wcyB7DQogICAgICAqIENhbGxlZCBkdXJpbmcgZG9tYWluIGRlc3RydWN0 aW9uIHRvIGZyZWUgcmVzb3VyY2VzIHVzZWQgYnkgdklPTU1VLg0KICAgICAgKi8NCiAgICAgaW50 ICgqcmVsaW5xdWlzaF9yZXNvdXJjZXMpKHN0cnVjdCBkb21haW4gKmQpOw0KKw0KKyAgICAvKg0K KyAgICAgKiBBbGxvY2F0ZSBmcmVlIHZTSUQvdlJJRCBmb3IgdGhlIGd1ZXN0IGRldmljZSBhbmQg ZXN0YWJsaXNoIHZJRC0+cElEIG1hcHBpbmcNCisgICAgICogQ2FsbGVkIGR1cmluZyBkb21haW4g ZGV2aWNlIGFzc2lnbm1lbnQuDQorICAgICAqIFJldHVybnMgMCBvbiBzdWNjZXNzIGFuZCBzZXRz IHZzaWQgYXJndW1lbnQgdG8gbmV3bHkgYWxsb2NhdGVkIHZTSUQvdlJJRA0KKyAgICAgKiBtYXBw ZWQgdG8gcGh5c2ljYWwgSUQgKGlkIGFyZ3VtZW50KS4NCisgICAgICogTmVnYXRpdmUgZXJyb3Ig Y29kZSByZXR1cm5lZCBpZiBhbGxvY2F0aW9uIGZhaWxzLg0KKyAgICAgKi8NCisgICAgaW50ICgq YWxsb2NhdGVfdnNpZCkoc3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3QgaWQsIHVpbnQzMl90IHBo YW5kbGUsDQorICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90ICp2c2lkKTsNCiB9Ow0K IA0KIHN0cnVjdCB2aW9tbXVfZGVzYyB7DQpAQCAtNTQsNiArNjQsOCBAQCBleHRlcm4gc3RydWN0 IGxpc3RfaGVhZCBob3N0X2lvbW11X2xpc3Q7DQogaW50IGRvbWFpbl92aW9tbXVfaW5pdChzdHJ1 Y3QgZG9tYWluICpkLCB1aW50OF90IHZpb21tdV90eXBlKTsNCiBpbnQgdmlvbW11X3JlbGlucXVp c2hfcmVzb3VyY2VzKHN0cnVjdCBkb21haW4gKmQpOw0KIHVpbnQ4X3QgdmlvbW11X2dldF90eXBl KHZvaWQpOw0KK2ludCB2aW9tbXVfYWxsb2NhdGVfdnNpZChzdHJ1Y3QgZG9tYWluICpkLCB1aW50 MzJfdCBpZCwgdWludDMyX3QgcGhhbmRsZSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgdWlu dDMyX3QgKnZzaWQpOw0KIHZvaWQgYWRkX3RvX2hvc3RfaW9tbXVfbGlzdChwYWRkcl90IGFkZHIs IHBhZGRyX3Qgc2l6ZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0 IGR0X2RldmljZV9ub2RlICpub2RlLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z dCB2b2lkICppb21tdSk7DQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20w bGVzcy1idWlsZC5jIGIveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1idWlsZC5jDQpp bmRleCA3MjgwYmNmNzJiLi42NzNiY2JiZDFjIDEwMDY0NA0KLS0tIGEveGVuL2NvbW1vbi9kZXZp Y2UtdHJlZS9kb20wbGVzcy1idWlsZC5jDQorKysgYi94ZW4vY29tbW9uL2RldmljZS10cmVlL2Rv bTBsZXNzLWJ1aWxkLmMNCkBAIC0zMSw2ICszMSw4IEBADQogI2luY2x1ZGUgPHhlbi9zdGF0aWMt bWVtb3J5Lmg+DQogI2luY2x1ZGUgPHhlbi9zdGF0aWMtc2htZW0uaD4NCiANCisjaW5jbHVkZSA8 YXNtL3Zpb21tdS5oPg0KKw0KICNkZWZpbmUgWEVOU1RPUkVfUEZOX0xBVEVfQUxMT0MgVUlOVDY0 X01BWA0KIA0KIHN0YXRpYyBkb21pZF90IF9faW5pdGRhdGEgeHNfZG9taWQgPSBET01JRF9JTlZB TElEOw0KQEAgLTMzMiwxMSArMzM0LDEyIEBAIHN0YXRpYyBpbnQgX19pbml0IGhhbmRsZV9wcm9w X3BmZHQoc3RydWN0IGtlcm5lbF9pbmZvICpraW5mbywNCiB9DQogDQogI2lmZGVmIENPTkZJR19B Uk1fVklSVFVBTF9JT01NVQ0KLXN0YXRpYyB2b2lkIF9faW5pdCBtb2RpZnlfcGZkdF9ub2RlKHZv aWQgKnBmZHQsIGludCBub2Rlb2ZmKQ0KK3N0YXRpYyB2b2lkIF9faW5pdCBtb2RpZnlfcGZkdF9u b2RlKHZvaWQgKnBmZHQsIGludCBub2Rlb2ZmLCBzdHJ1Y3QgZG9tYWluICpkKQ0KIHsNCiAgICAg aW50IHByb3BsZW4sIGksIHJjOw0KICAgICBjb25zdCBmZHQzMl90ICpwcm9wOw0KICAgICBmZHQz Ml90ICpwcm9wX2M7DQorICAgIHVpbnQzMl90IHBzaWQsIHBoYW5kbGUsIHZzaWQ7DQogDQogICAg IHByb3AgPSBmZHRfZ2V0cHJvcChwZmR0LCBub2Rlb2ZmLCAiaW9tbXVzIiwgJnByb3BsZW4pOw0K ICAgICBpZiAoICFwcm9wICkNCkBAIC0zNDYsMTAgKzM0OSwyMyBAQCBzdGF0aWMgdm9pZCBfX2lu aXQgbW9kaWZ5X3BmZHRfbm9kZSh2b2lkICpwZmR0LCBpbnQgbm9kZW9mZikNCiAgICAgaWYgKCAh cHJvcF9jICkNCiAgICAgICAgIHJldHVybjsNCiANCisgICAgLyogDQorICAgICAqIEFzc2lnbiA8 dklPTU1VIHZTSUQ+IHBhaXJzIHRvIGlvbW11cyBwcm9wZXJ0eSBhbmQgZXN0YWJsaXNoDQorICAg ICAqIHZTSUQtPnBTSUQgbWFwcGluZ3MNCisgICAgICovDQogICAgIGZvciAoIGkgPSAwOyBpIDwg cHJvcGxlbiAvIDg7ICsraSApDQogICAgIHsNCisgICAgICAgIHBoYW5kbGUgPSBmZHQzMl90b19j cHUocHJvcFtpICogMl0pOw0KKyAgICAgICAgcHNpZCA9IGZkdDMyX3RvX2NwdShwcm9wW2kgKiAy ICsgMV0pOw0KKyAgICAgICAgcmMgPSB2aW9tbXVfYWxsb2NhdGVfdnNpZChkLCBwc2lkLCBwaGFu ZGxlLCAmdnNpZCk7DQorICAgICAgICBpZiAoIHJjICkNCisgICAgICAgIHsNCisgICAgICAgICAg ICBkcHJpbnRrKFhFTkxPR19FUlIsICIoRE9NSUQ9JXUpIEZhaWxlZCB0byBhbGxvY2F0ZSB2U0lE IGZvciAiDQorICAgICAgICAgICAgICAgICAgICAicFNJRDogJXUsIHBJT01NVTogJXUiLCBkLT5k b21haW5faWQsIHBzaWQsIHBoYW5kbGUpOw0KKyAgICAgICAgICAgIHJldHVybjsNCisgICAgICAg IH0NCiAgICAgICAgIHByb3BfY1tpICogMl0gPSBjcHVfdG9fZmR0MzIoR1VFU1RfUEhBTkRMRV9W U01NVVYzKTsNCi0gICAgICAgIHByb3BfY1tpICogMiArIDFdID0gcHJvcFtpICogMiArIDFdOw0K KyAgICAgICAgcHJvcF9jW2kgKiAyICsgMV0gPSBjcHVfdG9fZmR0MzIodnNpZCk7DQogICAgIH0N CiANCiAgICAgcmMgPSBmZHRfc2V0cHJvcChwZmR0LCBub2Rlb2ZmLCAiaW9tbXVzIiwgcHJvcF9j LCBwcm9wbGVuKTsNCkBAIC0zNjIsNyArMzc4LDggQEAgc3RhdGljIHZvaWQgX19pbml0IG1vZGlm eV9wZmR0X25vZGUodm9pZCAqcGZkdCwgaW50IG5vZGVvZmYpDQogICAgIHJldHVybjsNCiB9DQog I2Vsc2UNCi0gICAgc3RhdGljIGlubGluZSB2b2lkIF9faW5pdCBtb2RpZnlfcGZkdF9ub2RlKHZv aWQgKnBmZHQsIGludCBub2Rlb2ZmKQ0KKyAgICBzdGF0aWMgaW5saW5lIHZvaWQgX19pbml0IG1v ZGlmeV9wZmR0X25vZGUodm9pZCAqcGZkdCwgaW50IG5vZGVvZmYsDQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgZG9tYWluICpkKQ0KICAgICB7 DQogICAgICAgICByZXR1cm47DQogICAgIH0NCkBAIC0zNzEsNyArMzg4LDcgQEAgc3RhdGljIHZv aWQgX19pbml0IG1vZGlmeV9wZmR0X25vZGUodm9pZCAqcGZkdCwgaW50IG5vZGVvZmYpDQogc3Rh dGljIGludCBfX2luaXQgc2Nhbl9wZmR0X25vZGUoc3RydWN0IGtlcm5lbF9pbmZvICpraW5mbywg dm9pZCAqcGZkdCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgbm9kZW9m ZiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBhZGRyZXNzX2Nl bGxzLCB1aW50MzJfdCBzaXplX2NlbGxzLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGJvb2wgc2Nhbl9wYXNzdGhyb3VnaF9wcm9wKQ0KKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJvb2wgc2Nhbl9wYXNzdGhyb3VnaF9wcm9wLCBzdHJ1Y3QgZG9tYWluICpkKQ0K IHsNCiAgICAgaW50IHJjID0gMDsNCiAgICAgdm9pZCAqZmR0ID0ga2luZm8tPmZkdDsNCkBAIC0z OTQsOSArNDExLDkgQEAgc3RhdGljIGludCBfX2luaXQgc2Nhbl9wZmR0X25vZGUoc3RydWN0IGtl cm5lbF9pbmZvICpraW5mbywgdm9pZCAqcGZkdCwNCiAgICAgbm9kZV9uZXh0ID0gZmR0X2ZpcnN0 X3N1Ym5vZGUocGZkdCwgbm9kZW9mZik7DQogICAgIHdoaWxlICggbm9kZV9uZXh0ID4gMCApDQog ICAgIHsNCi0gICAgICAgIG1vZGlmeV9wZmR0X25vZGUocGZkdCwgbm9kZV9uZXh0KTsNCisgICAg ICAgIG1vZGlmeV9wZmR0X25vZGUocGZkdCwgbm9kZV9uZXh0LCBkKTsNCiAgICAgICAgIHJjID0g c2Nhbl9wZmR0X25vZGUoa2luZm8sIHBmZHQsIG5vZGVfbmV4dCwgYWRkcmVzc19jZWxscywgc2l6 ZV9jZWxscywNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Nhbl9wYXNzdGhyb3VnaF9w cm9wKTsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Nhbl9wYXNzdGhyb3VnaF9wcm9w LCBkKTsNCiAgICAgICAgIGlmICggcmMgKQ0KICAgICAgICAgICAgIHJldHVybiByYzsNCiANCkBA IC00ODMsNyArNTAwLDcgQEAgc3RhdGljIGludCBfX2luaXQgZG9tYWluX2hhbmRsZV9kdGJfYm9v dF9tb2R1bGUoc3RydWN0IGRvbWFpbiAqZCwNCiAgICAgICAgICAgICByZXMgPSBzY2FuX3BmZHRf bm9kZShraW5mbywgcGZkdCwgbm9kZV9uZXh0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIERUX1JPT1RfTk9ERV9BRERSX0NFTExTX0RFRkFVTFQsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRFRfUk9PVF9OT0RFX1NJWkVfQ0VMTFNfREVGQVVMVCwNCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWxzZSk7DQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZmFsc2UsIGQpOw0KICAgICAgICAgICAgIGlmICggcmVzICkNCiAgICAg ICAgICAgICAgICAgZ290byBvdXQ7DQogICAgICAgICAgICAgY29udGludWU7DQpAQCAtNDkzLDcg KzUxMCw3IEBAIHN0YXRpYyBpbnQgX19pbml0IGRvbWFpbl9oYW5kbGVfZHRiX2Jvb3RfbW9kdWxl KHN0cnVjdCBkb21haW4gKmQsDQogICAgICAgICAgICAgcmVzID0gc2Nhbl9wZmR0X25vZGUoa2lu Zm8sIHBmZHQsIG5vZGVfbmV4dCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBE VF9ST09UX05PREVfQUREUl9DRUxMU19ERUZBVUxULA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIERUX1JPT1RfTk9ERV9TSVpFX0NFTExTX0RFRkFVTFQsDQotICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdHJ1ZSk7DQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdHJ1ZSwgZCk7DQogICAgICAgICAgICAgaWYgKCByZXMgKQ0KICAgICAgICAgICAgICAg ICBnb3RvIG91dDsNCiAgICAgICAgICAgICBjb250aW51ZTsNCmRpZmYgLS1naXQgYS94ZW4vZHJp dmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gv YXJtL3NtbXUtdjMuYw0KaW5kZXggZTQ0Zjg3MmQyZC4uMjk3ZDJlNWU3YiAxMDA2NDQNCi0tLSBh L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmMNCisrKyBiL3hlbi9kcml2ZXJz L3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmMNCkBAIC0zMDQ4LDcgKzMwNDgsNyBAQCBzdGF0aWMg c3RydWN0IGFybV9zbW11X2RldmljZSAqYXJtX3NtbXVfZ2V0X2J5X2Rldihjb25zdCBzdHJ1Y3Qg ZGV2aWNlICpkZXYpDQogfQ0KIA0KIHN0YXRpYyBzdHJ1Y3QgaW9tbXVfZG9tYWluICphcm1fc21t dV9nZXRfZG9tYWluX2J5X3NpZChzdHJ1Y3QgZG9tYWluICpkLA0KLQkJCQl1MzIgc2lkKQ0KKwkJ CQl1MzIgc2lkLCBjb25zdCBzdHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11KQ0KIHsNCiAJaW50 IGk7DQogCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQpAQCAtMzA2NCw2ICszMDY0LDkgQEAgc3RhdGlj IHN0cnVjdCBpb21tdV9kb21haW4gKmFybV9zbW11X2dldF9kb21haW5fYnlfc2lkKHN0cnVjdCBk b21haW4gKmQsDQogCWxpc3RfZm9yX2VhY2hfZW50cnkoaW9fZG9tYWluLCAmeGVuX2RvbWFpbi0+ Y29udGV4dHMsIGxpc3QpIHsNCiAJCXNtbXVfZG9tYWluID0gdG9fc21tdV9kb21haW4oaW9fZG9t YWluKTsNCiANCisJCWlmIChzbW11X2RvbWFpbi0+c21tdSAhPSBzbW11KQ0KKwkJCWNvbnRpbnVl Ow0KKw0KIAkJc3Bpbl9sb2NrX2lycXNhdmUoJnNtbXVfZG9tYWluLT5kZXZpY2VzX2xvY2ssIGZs YWdzKTsNCiAJCWxpc3RfZm9yX2VhY2hfZW50cnkobWFzdGVyLCAmc21tdV9kb21haW4tPmRldmlj ZXMsIGRvbWFpbl9oZWFkKSB7DQogCQkJZm9yIChpID0gMDsgaSA8IG1hc3Rlci0+bnVtX3N0cmVh bXM7IGkrKykgew0KQEAgLTMyOTIsMTQgKzMyOTUsMTUgQEAgc3RhdGljIHZvaWQgYXJtX3NtbXVf aW9tbXVfeGVuX2RvbWFpbl90ZWFyZG93bihzdHJ1Y3QgZG9tYWluICpkKQ0KIH0NCiANCiBzdGF0 aWMgaW50IGFybV9zbW11X2F0dGFjaF9ndWVzdF9jb25maWcoc3RydWN0IGRvbWFpbiAqZCwgdWlu dDMyX3Qgc2lkLA0KLQkJY29uc3Qgc3RydWN0IGlvbW11X2d1ZXN0X2NvbmZpZyAqY2ZnKQ0KKwkJ CQljb25zdCBzdHJ1Y3QgaW9tbXVfZ3Vlc3RfY29uZmlnICpjZmcsDQorCQkJCWNvbnN0IHN0cnVj dCBhcm1fc21tdV9kZXZpY2UgKnNtbXUpDQogew0KIAlpbnQgcmV0ID0gLUVJTlZBTDsNCiAJdW5z aWduZWQgbG9uZyBmbGFnczsNCiAJc3RydWN0IGFybV9zbW11X21hc3RlciAqbWFzdGVyOw0KIAlz dHJ1Y3QgYXJtX3NtbXVfZG9tYWluICpzbW11X2RvbWFpbjsNCiAJc3RydWN0IGFybV9zbW11X3hl bl9kb21haW4gKnhlbl9kb21haW4gPSBkb21faW9tbXUoZCktPmFyY2gucHJpdjsNCi0Jc3RydWN0 IGlvbW11X2RvbWFpbiAqaW9fZG9tYWluID0gYXJtX3NtbXVfZ2V0X2RvbWFpbl9ieV9zaWQoZCwg c2lkKTsNCisJc3RydWN0IGlvbW11X2RvbWFpbiAqaW9fZG9tYWluID0gYXJtX3NtbXVfZ2V0X2Rv bWFpbl9ieV9zaWQoZCwgc2lkLCBzbW11KTsNCiANCiAJaWYgKCFpb19kb21haW4pDQogCQlyZXR1 cm4gLUVOT0RFVjsNCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlv bW11LmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vdmlvbW11LmMNCmluZGV4IDQwN2U2 OGU2MmQuLjZjOTdhY2IwNDkgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h cm0vdmlvbW11LmMNCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92aW9tbXUuYw0K QEAgLTc1LDYgKzc1LDE1IEBAIGludCB2aW9tbXVfcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0 IGRvbWFpbiAqZCkNCiAgICAgcmV0dXJuIGN1cl92aW9tbXUtPm9wcy0+cmVsaW5xdWlzaF9yZXNv dXJjZXMoZCk7DQogfQ0KIA0KK2ludCB2aW9tbXVfYWxsb2NhdGVfdnNpZChzdHJ1Y3QgZG9tYWlu ICpkLCB1aW50MzJfdCBpZCwgdWludDMyX3QgcGhhbmRsZSwNCisgICAgICAgICAgICAgICAgICAg ICAgICAgdWludDMyX3QgKnZzaWQpDQorew0KKyAgICBpZiAoICFjdXJfdmlvbW11ICkNCisgICAg ICAgIHJldHVybiAtRU5PREVWOw0KKw0KKyAgICByZXR1cm4gY3VyX3Zpb21tdS0+b3BzLT5hbGxv Y2F0ZV92c2lkKGQsIGlkLCBwaGFuZGxlLCB2c2lkKTsNCit9DQorDQogdWludDhfdCB2aW9tbXVf Z2V0X3R5cGUodm9pZCkNCiB7DQogICAgIGlmICggIWN1cl92aW9tbXUgfHwgaG9zdF9pb21tdV9s aXN0X2luY29tcGxldGUgfHwNCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h cm0vdnNtbXUtdjMuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS92c21tdS12My5jDQpp bmRleCBiNzE1MTFjMmViLi41M2ZkN2YyZDYzIDEwMDY0NA0KLS0tIGEveGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvYXJtL3ZzbW11LXYzLmMNCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Fy bS92c21tdS12My5jDQpAQCAtODUsNiArODUsOCBAQA0KICNkZWZpbmUgc21tdV9nZXRfc3RlX3Mx Y3R4cHRyKHgpICAgIEZJRUxEX1BSRVAoU1RSVEFCX1NURV8wX1MxQ1RYUFRSX01BU0ssIFwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGSUVMRF9HRVQoU1RSVEFCX1NURV8w X1MxQ1RYUFRSX01BU0ssIHgpKQ0KIA0KKyNkZWZpbmUgTUFYX1ZTSUQgICAoMSA8PCBTTU1VX0lE UjFfU0lEU0laRSkNCisNCiAvKiBldmVudCBxdWV1ZSBlbnRyeSAqLw0KIHN0cnVjdCBhcm1fc21t dV9ldnRxX2VudCB7DQogICAgIC8qIENvbW1vbiBmaWVsZHMgKi8NCkBAIC0xMzIsNiArMTM0LDE0 IEBAIHN0cnVjdCBhcm1fdnNtbXVfcXVldWUgew0KICAgICB1aW50OF90ICAgICBtYXhfbl9zaGlm dDsNCiB9Ow0KIA0KKy8qIHZTSUQtPnBTSUQgbWFwcGluZyBlbnRyeSAqLw0KK3N0cnVjdCB2c2lk X2VudHJ5IHsNCisgICAgYm9vbCAgICAgICAgdmFsaWQ7DQorICAgIHVpbnQzMl90ICAgIHZzaWQ7 DQorICAgIHVpbnQzMl90ICAgIHBzaWQ7DQorICAgIHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKnNt bXU7DQorfTsNCisNCiBzdHJ1Y3QgdmlydF9zbW11IHsNCiAgICAgc3RydWN0ICAgICAgZG9tYWlu ICpkOw0KICAgICBzdHJ1Y3QgICAgICBsaXN0X2hlYWQgdmlvbW11X2xpc3Q7DQpAQCAtMTU2LDYg KzE2Niw3IEBAIHN0cnVjdCB2aXJ0X3NtbXUgew0KICAgICBzcGlubG9ja190ICBjcjJfbG9jazsN CiAgICAgc3BpbmxvY2tfdCAgc3RydGFiX2NmZ19sb2NrOw0KICAgICBzcGlubG9ja190ICBpcnFf Y2ZnX2xvY2s7DQorICAgIHN0cnVjdCB2c2lkX2VudHJ5ICp2c2lkczsNCiB9Ow0KIA0KIC8qIEhl bHBlciBmdW5jdGlvbnMgKi8NCkBAIC01NDUsNiArNTU2LDQ5IEBAIHN0YXRpYyBpbnQgYXJtX3Zz bW11X2hhbmRsZV9jZmdpX3N0ZShzdHJ1Y3QgdmlydF9zbW11ICpzbW11LCB1aW50NjRfdCAqY21k cHRyKQ0KICAgICBzdHJ1Y3QgYXJtX3ZzbW11X3MxX3RyYW5zX2NmZyBzMV9jZmcgPSB7MH07DQog ICAgIHVpbnQzMl90IHNpZCA9IHNtbXVfY21kX2dldF9zaWQoY21kcHRyWzBdKTsNCiAgICAgc3Ry dWN0IGlvbW11X2d1ZXN0X2NvbmZpZyBndWVzdF9jZmcgPSB7MH07DQorICAgIHN0cnVjdCBhcm1f c21tdV9kZXZpY2UgKnBoeXNfc21tdSA9IE5VTEw7DQorICAgIHN0cnVjdCBob3N0X2lvbW11ICpo b3N0X2lvbW11Ow0KKyAgICB1aW50MzJfdCBwc2lkOw0KKyAgICBzdHJ1Y3QgYXJtX3NtbXVfZXZ0 cV9lbnQgZW50ID0gew0KKyAgICAgICAgLm9wY29kZSA9IEVWVF9JRF9CQURfU1RSRUFNSUQsDQor ICAgICAgICAuc2lkID0gc2lkLA0KKyAgICAgICAgLmNfYmFkX3N0ZV9zdHJlYW1pZCA9IHsNCisg ICAgICAgICAgICAuc3NpZCA9IDAsDQorICAgICAgICAgICAgLnNzdiA9IGZhbHNlLA0KKyAgICAg ICAgfSwNCisgICAgfTsNCisNCisgICAgLyogdklPTU1VLT5wSU9NTVUgaWRlbnRpdHkgbWFwcGVk IGZvciBIVyBkb21haW4gKi8NCisgICAgaWYgKCBpc19oYXJkd2FyZV9kb21haW4oZCkgKQ0KKyAg ICB7DQorICAgICAgICBwc2lkID0gc2lkOw0KKyAgICAgICAgbGlzdF9mb3JfZWFjaF9lbnRyeSho b3N0X2lvbW11LCAmaG9zdF9pb21tdV9saXN0LCBlbnRyeSkNCisgICAgICAgIHsNCisgICAgICAg ICAgICBpZiAoIGhvc3RfaW9tbXUtPmFkZHIgPT0gc21tdS0+YWRkciApDQorICAgICAgICAgICAg ew0KKyAgICAgICAgICAgICAgICBwaHlzX3NtbXUgPSAoc3RydWN0IGFybV9zbW11X2RldmljZSAq KSBob3N0X2lvbW11LT5pb21tdTsNCisgICAgICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICAg ICAgfQ0KKyAgICAgICAgfQ0KKyAgICB9DQorICAgIGVsc2Ugew0KKyAgICAgICAgLyogdlNJRCBv dXQgb2YgcmFuZ2Ugb3Igbm90IG1hcHBlZCB0byBwU0lEICovDQorICAgICAgICBpZiAoIHNpZCA+ PSBNQVhfVlNJRCB8fCAhc21tdS0+dnNpZHNbc2lkXS52YWxpZCApDQorICAgICAgICB7DQorICAg ICAgICAgICAgYXJtX3ZzbW11X3NlbmRfZXZlbnQoc21tdSwgJmVudCk7DQorICAgICAgICAgICAg cmV0dXJuIC1FSU5WQUw7DQorICAgICAgICB9DQorDQorICAgICAgICBwc2lkID0gc21tdS0+dnNp ZHNbc2lkXS5wc2lkOw0KKyAgICAgICAgcGh5c19zbW11ID0gc21tdS0+dnNpZHNbc2lkXS5zbW11 Ow0KKyAgICB9DQorDQorICAgIC8qIHZTSUQgbWFwcGVkIHRvIGludmFsaWQgcGh5c2ljYWwgU01N VSAqLw0KKyAgICBpZiAoIXBoeXNfc21tdSkNCisgICAgew0KKyAgICAgICAgYXJtX3ZzbW11X3Nl bmRfZXZlbnQoc21tdSwgJmVudCk7DQorICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisgICAgfQ0K IA0KICAgICByZXQgPSBhcm1fdnNtbXVfZmluZF9zdGUoc21tdSwgc2lkLCBzdGUpOw0KICAgICBp ZiAoIHJldCApDQpAQCAtNTY1LDcgKzYxOSw3IEBAIHN0YXRpYyBpbnQgYXJtX3ZzbW11X2hhbmRs ZV9jZmdpX3N0ZShzdHJ1Y3QgdmlydF9zbW11ICpzbW11LCB1aW50NjRfdCAqY21kcHRyKQ0KICAg ICBlbHNlDQogICAgICAgICBndWVzdF9jZmcuY29uZmlnID0gQVJNX1NNTVVfRE9NQUlOX1MxOw0K IA0KLSAgICByZXQgPSBoZC0+cGxhdGZvcm1fb3BzLT5hdHRhY2hfZ3Vlc3RfY29uZmlnKGQsIHNp ZCwgJmd1ZXN0X2NmZyk7DQorICAgIHJldCA9IGhkLT5wbGF0Zm9ybV9vcHMtPmF0dGFjaF9ndWVz dF9jb25maWcoZCwgcHNpZCwgJmd1ZXN0X2NmZywgcGh5c19zbW11KTsNCiAgICAgaWYgKCByZXQg KQ0KICAgICAgICAgcmV0dXJuIHJldDsNCiANCkBAIC0xMTY0LDYgKzEyMTgsOSBAQCBzdGF0aWMg aW50IHZzbW11djNfaW5pdF9zaW5nbGUoc3RydWN0IGRvbWFpbiAqZCwgcGFkZHJfdCBhZGRyLA0K ICAgICBzbW11LT5hZGRyID0gYWRkcjsNCiAgICAgc21tdS0+Y21kcS5lbnRfc2l6ZSA9IENNRFFf RU5UX0RXT1JEUyAqIERXT1JEU19CWVRFUzsNCiAgICAgc21tdS0+ZXZ0cS5lbnRfc2l6ZSA9IEVW VFFfRU5UX0RXT1JEUyAqIERXT1JEU19CWVRFUzsNCisgICAgc21tdS0+dnNpZHMgPSB4emFsbG9j X2FycmF5KHN0cnVjdCB2c2lkX2VudHJ5LCBNQVhfVlNJRCk7DQorICAgIGlmICggIXNtbXUtPnZz aWRzICkNCisgICAgICAgIHJldHVybiAtRU5PTUVNOw0KIA0KICAgICBzcGluX2xvY2tfaW5pdCgm c21tdS0+Y21kX3F1ZXVlX2xvY2spOw0KICAgICBzcGluX2xvY2tfaW5pdCgmc21tdS0+ZXZ0X3F1 ZXVlX2xvY2spOw0KQEAgLTEyNTQsOCArMTMxMSw5IEBAIHN0YXRpYyBpbnQgdnNtbXV2M19yZWxp bnF1aXNoX3Jlc291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQ0KICAgICBpZiAoIGxpc3RfaGVhZF9p c19udWxsKCZkLT5hcmNoLnZpb21tdV9saXN0KSApDQogICAgICAgICByZXR1cm4gMDsNCiANCi0g ICAgbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBvcywgdGVtcCwgJmQtPmFyY2gudmlvbW11X2xp c3QsIHZpb21tdV9saXN0ICkNCisgICAgbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBvcywgdGVt cCwgJmQtPmFyY2gudmlvbW11X2xpc3QsIHZpb21tdV9saXN0KQ0KICAgICB7DQorICAgICAgICB4 ZnJlZShwb3MtPnZzaWRzKTsNCiAgICAgICAgIGxpc3RfZGVsKCZwb3MtPnZpb21tdV9saXN0KTsN CiAgICAgICAgIHhmcmVlKHBvcyk7DQogICAgIH0NCkBAIC0xMjYzLDggKzEzMjEsNTUgQEAgc3Rh dGljIGludCB2c21tdXYzX3JlbGlucXVpc2hfcmVzb3VyY2VzKHN0cnVjdCBkb21haW4gKmQpDQog ICAgIHJldHVybiAwOw0KIH0NCiANCitpbnQgdnNtbXV2M19hbGxvY2F0ZV92c2lkKHN0cnVjdCBk b21haW4gKmQsIHVpbnQzMl90IGlkLCB1aW50MzJfdCBwaGFuZGxlLA0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgdWludDMyX3QgKnZzaWQpDQorew0KKyAgICB1aW50MzJfdCBpID0gMDsNCisg ICAgc3RydWN0IHZpcnRfc21tdSAqc21tdTsNCisgICAgc3RydWN0IGhvc3RfaW9tbXUgKmhvc3Rf aW9tbXU7DQorICAgIHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKnBoeXNfc21tdSA9IE5VTEw7DQor DQorICAgIGlmICggbGlzdF9oZWFkX2lzX251bGwoJmQtPmFyY2gudmlvbW11X2xpc3QpICkNCisg ICAgICAgIHJldHVybiAtRU5PREVWOw0KKw0KKyAgICBzbW11ID0gbGlzdF9maXJzdF9lbnRyeSgm ZC0+YXJjaC52aW9tbXVfbGlzdCwgc3RydWN0IHZpcnRfc21tdSwgdmlvbW11X2xpc3QpOw0KKw0K KyAgICAvKg0KKyAgICAgKiBGaW5kIHRoZSBwaHlzaWNhbCBTTU1VIGNvcnJlc3BvbmRpbmcgdG8g dGhlIGRldmljZS10cmVlIHBoYW5kbGUuDQorICAgICAqLw0KKyAgICBsaXN0X2Zvcl9lYWNoX2Vu dHJ5KGhvc3RfaW9tbXUsICZob3N0X2lvbW11X2xpc3QsIGVudHJ5KQ0KKyAgICB7DQorICAgICAg ICBpZiAoIGhvc3RfaW9tbXUtPmR0X25vZGUtPnBoYW5kbGUgPT0gcGhhbmRsZSApDQorICAgICAg ICB7DQorICAgICAgICAgICAgcGh5c19zbW11ID0gKHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKikg aG9zdF9pb21tdS0+aW9tbXU7DQorICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICB9DQorICAg IH0NCisNCisgICAgaWYgKCAhcGh5c19zbW11ICkNCisgICAgICAgIHJldHVybiAtRU5PREVWOw0K Kw0KKyAgICAvKiBHZXQgZmlyc3QgZnJlZSB2U0lEIGluZGV4ICovDQorICAgIHdoaWxlICggaSA8 IE1BWF9WU0lEICYmIHNtbXUtPnZzaWRzW2ldLnZhbGlkICkNCisgICAgICAgIGkrKzsNCisNCisg ICAgLyogTWF4IG51bWJlciBvZiB2U0lEcyBhbHJlYWR5IGFsbG9jYXRlZD8gKi8NCisgICAgaWYg KCBpID09IE1BWF9WU0lEICkNCisgICAgICAgIHJldHVybiAtRU5PTUVNOw0KKw0KKyAgICAvKiBF c3RhYmxpc2ggdlNJRC0+cFNJRCBtYXBwaW5nICovDQorICAgIHNtbXUtPnZzaWRzW2ldLnZhbGlk ID0gdHJ1ZTsNCisgICAgc21tdS0+dnNpZHNbaV0udnNpZCA9IGk7DQorICAgIHNtbXUtPnZzaWRz W2ldLnBzaWQgPSBpZDsNCisgICAgc21tdS0+dnNpZHNbaV0uc21tdSA9IHBoeXNfc21tdTsNCisg ICAgKnZzaWQgPSBzbW11LT52c2lkc1tpXS52c2lkOw0KKw0KKyAgICByZXR1cm4gMDsNCit9DQor DQogc3RhdGljIGNvbnN0IHN0cnVjdCB2aW9tbXVfb3BzIHZzbW11djNfb3BzID0gew0KICAgICAu ZG9tYWluX2luaXQgPSBkb21haW5fdnNtbXV2M19pbml0LA0KKyAgICAuYWxsb2NhdGVfdnNpZCA9 IHZzbW11djNfYWxsb2NhdGVfdnNpZCwNCiAgICAgLnJlbGlucXVpc2hfcmVzb3VyY2VzID0gdnNt bXV2M19yZWxpbnF1aXNoX3Jlc291cmNlcywNCiB9Ow0KIA0KZGlmZiAtLWdpdCBhL3hlbi9pbmNs dWRlL3hlbi9pb21tdS5oIGIveGVuL2luY2x1ZGUveGVuL2lvbW11LmgNCmluZGV4IDI1M2Y4YmI2 Y2IuLmM5NGVlNGYwOGUgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaA0KKysr IGIveGVuL2luY2x1ZGUveGVuL2lvbW11LmgNCkBAIC0zMTIsNyArMzEyLDEwIEBAIHN0YXRpYyBp bmxpbmUgaW50IGlvbW11X2FkZF9kdF9wY2lfc2lkZWJhbmRfaWRzKHN0cnVjdCBwY2lfZGV2ICpw ZGV2KQ0KICNlbmRpZiAvKiBIQVNfREVWSUNFX1RSRUVfRElTQ09WRVJZICovDQogDQogc3RydWN0 IHBhZ2VfaW5mbzsNCisjaWZkZWYgQ09ORklHX0FSTQ0KIHN0cnVjdCBpb21tdV9ndWVzdF9jb25m aWc7DQorc3RydWN0IGFybV9zbW11X2RldmljZTsNCisjZW5kaWYNCiANCiAvKg0KICAqIEFueSBu b24temVybyB2YWx1ZSByZXR1cm5lZCBmcm9tIGNhbGxiYWNrcyBvZiB0aGlzIHR5cGUgd2lsbCBj YXVzZSB0aGUNCkBAIC0zOTEsNyArMzk0LDggQEAgc3RydWN0IGlvbW11X29wcyB7DQogDQogI2lm ZGVmIENPTkZJR19BUk0NCiAgICAgaW50ICgqYXR0YWNoX2d1ZXN0X2NvbmZpZykoc3RydWN0IGRv bWFpbiAqZCwgdWludDMyX3Qgc2lkLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zdCBzdHJ1Y3QgaW9tbXVfZ3Vlc3RfY29uZmlnICpjZmcpOw0KKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjb25zdCBzdHJ1Y3QgaW9tbXVfZ3Vlc3RfY29uZmlnICpjZmcsDQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCBhcm1fc21tdV9kZXZpY2Ug KnNtbXUpOw0KICNlbmRpZg0KIH07DQogDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:08:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:08:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441915.1659494 (Exim 4.92) (envelope-from ) id 1xEFCU-0000JF-Ut; Wed, 07 Oct 2026 00:08:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441915.1659494; Wed, 07 Oct 2026 00: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 1xEFCU-0000J8-Ry; Wed, 07 Oct 2026 00:08:02 +0000 Received: by outflank-mailman (input) for mailman id 1441915; Wed, 07 Oct 2026 00:08:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFCT-0000FV-IO for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:08:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFCS-006Hhb-VN for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:08:00 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d20-2eae-0a2a0a5409dd-0a2a4508c722-40 for ; Wed, 07 Oct 2026 02:08:00 +0200 Received: from [52.101.65.117] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d60-f659-0a2a45080019-3465417599b6-3 for ; Wed, 07 Oct 2026 02:08:00 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by VI0PR03MB11456.eurprd03.prod.outlook.com (2603:10a6:800:321::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.23; Wed, 7 Oct 2026 00:07:58 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:07: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=OfzJntBtwTr9Sde7Tv4y576T3r0dUvr+VSh+9fhUTTeI7dfUl4Yc1a/h0FkAdT1ucAMnkFP6o6D+tqtcwzwhVN0HSwyIsQm09gfB0UE4Sv8G/Abv+f0ZI6/0fpvdAuVV6BnDX6Z9OGuOjqXlRXm2MscX7qlu4/CvnofbKi2Oq1OR6fiwNCmDynvZL0Jq3SHSCI8wm4LuprleRxdmb0SNI2XkZFTlbaG+kU+y5FMsI+8ly2bmmlVuL+pT+Re1t1YuQKL7b7IQTka0oQwBNJzHdQtUHCXn8+tBToZK23YTZdRhXM/bqoae5yx4vy4ddrhgXBEISMEAcd7+7wIxb7C/Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zxIf4b+Z7EmYCUEOzHbIOb3dsXQtIAtPh2L3MTCCxo4=; b=gZAJdiwVb3tOVLb8ziL8a4/CfB+AywK5ar1Nf2UI9Fdgr8hfhYZW+beyD3tF1B4GkrcJD0H4hXxw1jX5uycFFgjNA6/qp3Hu7B6ygxYuy8CVVZrk6/Y8sWjHniunXtos0xoty9d1xCxaByf9EAFN3TdIaSYPN9ytYSSF8vwumO3L1duMuf3txf8Yp92ZNqVwUxOfEU8Wj5bGuPKW6S/n+WT9YArkz2IHVHtyfkroe9J1fhjn56q9bRxqmM3niM1eXgpRPD+qfyBN7RqfYkPuZlEJtQQ6jKQkYEofer5CeK9k1YLo6MNiFi7tIJQ26A8R7Ewf+RawqW1SWeTdBO6XGQ== 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=zxIf4b+Z7EmYCUEOzHbIOb3dsXQtIAtPh2L3MTCCxo4=; b=NVXDoXUDUipbAIsj/2Y7HeCcNw17CdiQs+vGuIp8pYOorGwAG/PDGxQXzuBDLhxRDrK/xxm52lHSRZBUPgzOikVz+4HPa/2qNsoU9EKDM/fBa3txoUi7Ynne11rLRFmz0MHnSHHKRcLMwx3BAGkzS3rf+xF8PdGVol5eBgLYX85REs4FhveoCpJ7H5eBiuNAweAufOdBIyF46q4aBJWOHEW+anxFbc/N8DXobF97eUzSegB0PNyPVtMz28hDOq3Tb0aA0Vzu4CvHRQYPxcyh6pSzq0WGuFn90zLPGurnpAT4NLFmWaJ+IKEIPyX5d+869MeXqsJYQ1eHgXVxd8KGLA== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Milan Djokic , Anthony PERARD , Juergen Gross , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" Subject: [PATCH v4 21/22] libxl/arm: Introduce domctl command for IOMMU vSID mapping Thread-Topic: [PATCH v4 21/22] libxl/arm: Introduce domctl command for IOMMU vSID mapping Thread-Index: AQHdVe/p6PS8YaUmiEuuuD/nuNiMhA== Date: Wed, 7 Oct 2026 00:07:58 +0000 Message-ID: <66d35a04bcde0c41050e61e194de4565d6fed045.1791328190.git.milan_djokic@epam.com> References: In-Reply-To: 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: AS2PR03MB9587:EE_|VI0PR03MB11456:EE_ x-ms-office365-filtering-correlation-id: a7c957f1-fa67-431f-6e4e-08df24070b93 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|366016|376014|1800799024|56012099006|38070700021|10067099003|6133799003|11063799006|22082099003|18002099003; x-microsoft-antispam-message-info: WN+n74wwitf3GQv2dOqWu5h4EP5Uu1DHLme06YeRyje7w4rpuZHuPmaK1FXA76H2tcm0dh2O/tQmv4Jp4a+EwVf80gaxXlyYyhs5pa9GtlDZ732trTdELKH7TDIpzo07CZAil/gOqIoggFUq2Rp+DN/vBWyasW12bDTEz31kE8NaFGuOooOoLkRQqyzN1B7BnYlzydVq1uaqnGae+YgxF0IjMXrslPRW2RqekpTmUCfcpHu3kaA/d0V959tyw5SdHKM4KwLWYZP2Ue4e/LdiTYeBy0dADQZk1M1XyEupXqfxc8vAuQP5BI1TsFgPSWiqNRsU6u2FImR6vuUFLhK3vB1QzOw43dv2BVTLjPV4nAAmhRb3WHrEI4W5fNUa1KNSZyTnv5pD2VCtxVs4H+BevujqMIFChKxBHMpf7apVPcYBM0suBBs89cXKhvrgMVBgHaP9oJGjwi6H8tKNc95E2hxbi/6kYJ3cRm3wjYPEp57STEBqtIcf7P/RYot4vGCsTMn1AKNvPxokcvdA3mbBxU8AJADXWFBZBvd7f89+P1e4jITnolhrfovd8+u3u+k2JR+RX+I7CghcuwScGjsytK9bpe4zCEL4wY/6+AeVl17pMY5ANib4NFar85zIGlqRZeydx4VKSOjK1SQ4oqdJk7XlkfXfKASCTFHOyzRUgmUuK7cRKBvfhdNDMk9qoAwmEK7rpYiWmR0pPyCivgWTqxtmhrAAAGGSxNNWxZUXJXM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(366016)(376014)(1800799024)(56012099006)(38070700021)(10067099003)(6133799003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?R1g5R2trT0RnT05nQjlpU3VkN0J0YmxYZ0xYTm1qUXRoQkJFL0lFSFRWb051?= =?utf-8?B?VDBTVTNTU0N0VCtyY2d3U0VYOHYwUVRNWVN0UGRubjMyYmhLYldFdjMzSkpl?= =?utf-8?B?b0VYL20rYXR3QjFMaDRlKzZMOHBBdnVXd1hzbk5LdWhMWlBrYi85TTFCRXJr?= =?utf-8?B?aUkrRVRkMlhBYVJad1RXNWlwNXFLYmVoSUowQWI1dUJCeDlsRFlhcFpBeEZk?= =?utf-8?B?d0J0UENtVDg4VUUyRXdDVjJSZlhxdGlDem00blJUYURzNUwxYWZ0N1R6cHYw?= =?utf-8?B?RzdHNVFDYXFLbVpDUVJCL2tRNlliNHJLanlSOTVtQXY4cGsvRWJmWkMyTXU4?= =?utf-8?B?My9TakhkL1dabFNXTVRwMkx4VHpNVWxLUGhRbjRjS28vcS9tcks4UVMrOUd4?= =?utf-8?B?Mnl0RmhhL2ppSGZNKzcrb0xIRjJqSzU4WnJnVHM2QWh1VTVVUmQ0Q0o2WnBO?= =?utf-8?B?NzgxelhUbE0wV1dWaWNtNnZBWDl0TFZzdmZwZTJvaXh6MmJDZXU3YzFIU2lk?= =?utf-8?B?RUFIdmliNVRDTnNtQ2d0OXd5YUROQ01CVGJYREVpTk5BM2MvRS85STNtODN0?= =?utf-8?B?UGZ5SjE4TU1pZXhJcXUvT0pQdWZpYUN3QUk5Z3VkWWdubnY0bFRaRlgxSFM4?= =?utf-8?B?cVRsKzQyZGhuTERpVzNHS2xaQkFtdWZlRWhnclFacTVWT3N2K09peHBVbDEr?= =?utf-8?B?TTVraUtHeGtmSXhmVkFXTmxVamx5WWxFQ2RtMldwcWwyRnFYZHd4Ui9vV3V0?= =?utf-8?B?Vm1ISk1iaTJTVGlWSFVMVlNxR0xJUy82UjVlU3R1emU5aVNvU1Mvd0JoWTVH?= =?utf-8?B?bGlyV3FMbmczbWd5ZlBCSmcvRURyUGdxeUMxY29majBHTHd5cWVuaWFOMjhU?= =?utf-8?B?cnBSbmQvYm1nclQwMnNZVVFkd21QQUhTam4xSDRZMGlYRjlzbVIyeXR2Uldv?= =?utf-8?B?Q3VGb204VTF2SkJtaGdmQnZtYUo0NXQwZk5TYlJwRU1uWkpLMVVSYk5kcU5U?= =?utf-8?B?SDRoUnhaVlVZaUY1QmhOVkZMcm1oQW1pRXdWNHp5NDVRUzV2bGpxbHJRYTFk?= =?utf-8?B?NktoWlRJYzdZWEJqUHpmWEt6c1p0TVNYdndhNDkxY2JURDZ2WkI5ZTBCU2NH?= =?utf-8?B?USttWUgzVDRpbDFVTEhnbjlFbS9QbXY0QUJLMk5oL1pSYWZuYkhNa3BBVkxz?= =?utf-8?B?NC9wNUprMXFDWUoyeE00QWxZM0p0d2FsVVQ5RWlTcndFR0hYQzVrVGZTY2Fq?= =?utf-8?B?emNYU2xmWjJya3pKZXIvTk5xRkR1emQ3endENzBKOFhnVWpGaDhpRkMrblBL?= =?utf-8?B?WE9kVlhmQXkxaWJ2V3ZyTFc1Q0Qxd01NTy9pVTlycUFCV3B2emszN1ppdVJG?= =?utf-8?B?anl2RzJWRDc0TXlHOGxQR2c5NmFTZThCd1NKdWFudHBWSFdZNkZESUE2c0hk?= =?utf-8?B?OTNENWN2ZUw3WTMwL0JEQmVYeVVOQ0JZVVpIdEpTNkVqVTY3MXBOTCszeHVj?= =?utf-8?B?Y29XSTV5dXZmUXozN2xYQTNURzc1ZDliZjBybVFBcFkwa3FQVWJiVzRMNk9L?= =?utf-8?B?TnRqL3hHR1ArazF1N3oyYXRRWDVGaTJnc3pMc1hmWVVRNFVxR3F1bjhEOUFG?= =?utf-8?B?VnFxbTJITWlMcHlLWEkwSVFINTgxei9OSE9PV0xZa3k2N2Facm1aVzBPUDIv?= =?utf-8?B?aGpCMVZCN0pIUGpmYURTYjU2Y1NSSlg5VnB4bVVIeHp1MVl2VENPbWpaL0h3?= =?utf-8?B?LzJHamlqWXhTTjB0QXRKNXlRRmhvKzRZazFHRWphVWdLTjZJV0VGK25xVm1V?= =?utf-8?B?T1IzY25DWEFhbmM1SUhTanhtUkFWNjNhSzk1b2FQNmZ2RGNxYURTdWRFYUR4?= =?utf-8?B?UjNjYmN5c2JqNkwxcExERTZuMFpaY2JCN0ltOU9NSGlSVlRBeUVzZmV2Ry95?= =?utf-8?B?eU44Rm5HNGNjOTVoejVGalRqVG5MZnh2V0Y1RlFJR29yU0xENGQvZlh6R05x?= =?utf-8?B?MkIvMDhRK0lxOWd0U3FJTWNLUHpPeXRvOW15bXdYaHdCYWw4R0tzTTlEdG9X?= =?utf-8?B?cWxpMEVmL1U3Rm90cGY1STJtRnNvaUo0bmkxRGxQWVdnZ1N2cWlyOHRjN3Nk?= =?utf-8?B?QVJuT0NhUHhwQjgwRnZrZzdlSzJuVW1OZUZKaVZjQmxISUFwa3Z0cXlqWnE1?= =?utf-8?B?ZTRFZW5rVm51U1RGbGNlQU4vUUtSTG5hQURCWHFXUnZvQk5oSGg5QytjdGwz?= =?utf-8?B?eUN6ZXZxRXFTYWVXcGJMSG9vb0dKSmw5NDlrem04dUFHRkhhZ21rSVYwOUZz?= =?utf-8?B?b0xHeDJHYzhoMHhOQ0FrcW5LWUphS2Z3akJWRHR4anZzVWY1TjlyZz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7c957f1-fa67-431f-6e4e-08df24070b93 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:07:58.6761 (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: Ww58bHJwFqffQ54sOjwitJtq5dHj9osZ8Y8X7CODBwgVt0cHOS4na08mUNAv3FNpLT63h4L/anJvPf6lLoHLhg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11456 X-purgate-ID: tlsNG-c1860d/1791331680-D497287B-EF74DB90/0/0 X-purgate-type: clean X-purgate-size: 18474 Rm9yIGd1ZXN0cyBjcmVhdGVkIHZpYSB0aGUgY29udHJvbCBkb21haW4gKHhsLCBaZXBoeXIgeGVu bGliKSwgYSBwYXJ0aWFsDQpkZXZpY2UgdHJlZSBpcyBwYXJzZWQgYW5kIGxvYWRlZCBvbiB0aGUg Y29udHJvbCBkb21haW4gc2lkZS4NCg0KU0lEcyBpbiB0aGUgZ3Vlc3QgZGV2aWNlIHRyZWUgaGF2 ZSB0byBiZSByZXBsYWNlZCB3aXRoIHZpcnR1YWwgU0lEcyB0aGF0DQphcmUgbWFwcGVkIHRvIHRo ZSBjb3JyZXNwb25kaW5nIHBoeXNpY2FsIFNJRHMuIFRvIGRvIHRoaXMsIHRoZSBjb250cm9sDQpk b21haW4gcmVxdWVzdHMgWGVuIHRvIGFsbG9jYXRlIGEgbmV3IHZTSUQgYW5kIG1hcCBpdCB0byB0 aGUgb3JpZ2luYWwNCnBTSUQgZm9yIGVhY2ggSU9NTVUgc3RyZWFtIElEIGFzc29jaWF0ZWQgd2l0 aCBhIGd1ZXN0IGRldmljZS4NCg0KSW50cm9kdWNlIGEgbmV3IGRvbWN0bCBjb21tYW5kIChYRU5f RE9NQ1RMX3Zpb21tdV9hbGxvY2F0ZV92aWQpIHRoYXQNCmFsbG93cyB0aGUgY29udHJvbCBkb21h aW4gdG8gcmVxdWVzdCBhIG5ldyB2U0lEIG1hcHBpbmcgYW5kIHJlcGxhY2UgdGhlDQpvcmlnaW5h bCBwU0lEIHdpdGggdGhlIGFsbG9jYXRlZCB2U0lEIGluIHRoZSBndWVzdCBkZXZpY2UgdHJlZS4N Cg0KSW1wbGVtZW50IHZTSUQgYWxsb2NhdGlvbiBpbiBsaWJ4bCB1c2luZyB0aGlzIGludGVyZmFj ZSBmb3IgZGV2aWNlcw0KY29uZmlndXJlZCBiZWhpbmQgYW4gSU9NTVUuDQoNClNpZ25lZC1vZmYt Ynk6IE1pbGFuIERqb2tpYyA8bWlsYW5fZGpva2ljQGVwYW0uY29tPg0KLS0tDQogdG9vbHMvaW5j bHVkZS94ZW5jdHJsLmggICAgICAgICAgICAgfCAgMTMgKysrKw0KIHRvb2xzL2xpYnMvY3RybC94 Y19kb21haW4uYyAgICAgICAgIHwgIDI1ICsrKysrKysNCiB0b29scy9saWJzL2xpZ2h0L2xpYnhs X2FybS5jICAgICAgICB8IDEwNyArKysrKysrKysrKysrKysrKysrKysrKysrLS0tDQogeGVuL2Fy Y2gvYXJtL2RvbWN0bC5jICAgICAgICAgICAgICAgfCAgMzggKysrKysrKysrKw0KIHhlbi9pbmNs dWRlL3B1YmxpYy9kb21jdGwuaCAgICAgICAgIHwgIDIyICsrKysrKw0KIHhlbi94c20vZmxhc2sv aG9va3MuYyAgICAgICAgICAgICAgIHwgICA0ICsrDQogeGVuL3hzbS9mbGFzay9wb2xpY3kvYWNj ZXNzX3ZlY3RvcnMgfCAgIDIgKw0KIDcgZmlsZXMgY2hhbmdlZCwgMjAyIGluc2VydGlvbnMoKyks IDkgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS90b29scy9pbmNsdWRlL3hlbmN0cmwuaCBi L3Rvb2xzL2luY2x1ZGUveGVuY3RybC5oDQppbmRleCA5ZjAwZDRhMTlkLi5kMzhiMzY1MDc4IDEw MDY0NA0KLS0tIGEvdG9vbHMvaW5jbHVkZS94ZW5jdHJsLmgNCisrKyBiL3Rvb2xzL2luY2x1ZGUv eGVuY3RybC5oDQpAQCAtMjY2NCw2ICsyNjY0LDE5IEBAIGludCB4Y19kb21haW5fc2V0X2xsY19j b2xvcnMoeGNfaW50ZXJmYWNlICp4Y2gsIHVpbnQzMl90IGRvbWlkLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29uc3QgdWludDMyX3QgKmxsY19jb2xvcnMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50MzJfdCBudW1fbGxjX2NvbG9ycyk7DQogDQorLyoNCisgKiBB bGxvY2F0ZSBndWVzdCBJT01NVSB2U0lEIGFuZCBlc3RhYmxpc2ggaXRzIG1hcHBpbmcgdG8gcFNJ RC4NCisgKiBJdCBjYW4gb25seSBiZSB1c2VkIG9uIGRvbWFpbiBEVCBjcmVhdGlvbi4NCisgKiBD dXJyZW50bHkgdXNlZCBmb3IgQVJNIG9ubHksIHBvc3NpYmx5IGZvciBSSVNDLVYgaW4gdGhlDQor ICogZnV0dXJlLiBGdW5jdGlvbiBoYXMgbm8gZWZmZWN0IGZvciB4ODYuDQorICovDQoraW50IHhj X2RvbWFpbl92aW9tbXVfYWxsb2NhdGVfdnNpZF9yYW5nZSh4Y19pbnRlcmZhY2UgKnhjaCwNCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLA0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDE2X3QgbnJfc2lk cywNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZp cnN0X3BzaWQsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50 MzJfdCBwaGFuZGxlLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dWludDMyX3QgKmZpcnN0X3ZzaWQpOw0KKw0KICNpZiBkZWZpbmVkKF9fYXJtX18pIHx8IGRlZmlu ZWQoX19hYXJjaDY0X18pDQogaW50IHhjX2R0X292ZXJsYXkoeGNfaW50ZXJmYWNlICp4Y2gsIHZv aWQgKm92ZXJsYXlfZmR0LA0KICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IG92ZXJsYXlfZmR0 X3NpemUsIHVpbnQ4X3Qgb3ZlcmxheV9vcCk7DQpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9jdHJs L3hjX2RvbWFpbi5jIGIvdG9vbHMvbGlicy9jdHJsL3hjX2RvbWFpbi5jDQppbmRleCA5NGNmYWIw ZmExLi4wYmQzZTQ1ZmJkIDEwMDY0NA0KLS0tIGEvdG9vbHMvbGlicy9jdHJsL3hjX2RvbWFpbi5j DQorKysgYi90b29scy9saWJzL2N0cmwveGNfZG9tYWluLmMNCkBAIC0yMjIyLDYgKzIyMjIsMzEg QEAgb3V0Og0KIA0KICAgICByZXR1cm4gcmV0Ow0KIH0NCisNCitpbnQgeGNfZG9tYWluX3Zpb21t dV9hbGxvY2F0ZV92c2lkX3JhbmdlKHhjX2ludGVyZmFjZSAqeGNoLA0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsDQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBucl9zaWRzLA0KKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmlyc3RfcHNpZCwNCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHBoYW5kbGUs DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCAqZmly c3RfdnNpZCkNCit7DQorICAgIGludCBlcnI7DQorICAgIHN0cnVjdCB4ZW5fZG9tY3RsIGRvbWN0 bCA9IHt9Ow0KKw0KKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF92aW9tbXVfYWxsb2NfdnNp ZF9yYW5nZTsNCisgICAgZG9tY3RsLmRvbWFpbiA9IGRvbWlkOw0KKyAgICBkb21jdGwudS52aW9t bXVfYWxsb2NfdnNpZF9yYW5nZS5maXJzdF9wc2lkID0gZmlyc3RfcHNpZDsNCisgICAgZG9tY3Rs LnUudmlvbW11X2FsbG9jX3ZzaWRfcmFuZ2UucGhhbmRsZSA9IHBoYW5kbGU7DQorICAgIGRvbWN0 bC51LnZpb21tdV9hbGxvY192c2lkX3JhbmdlLm5yX3NpZHMgPSBucl9zaWRzOw0KKw0KKyAgICBp ZiAoIChlcnIgPSBkb19kb21jdGwoeGNoLCAmZG9tY3RsKSkgIT0gMCApDQorICAgICAgICByZXR1 cm4gZXJyOw0KKw0KKyAgICAqZmlyc3RfdnNpZCA9IGRvbWN0bC51LnZpb21tdV9hbGxvY192c2lk X3JhbmdlLmZpcnN0X3ZzaWQ7DQorDQorICAgIHJldHVybiAwOw0KK30NCisNCiAvKg0KICAqIExv Y2FsIHZhcmlhYmxlczoNCiAgKiBtb2RlOiBDDQpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9saWdo dC9saWJ4bF9hcm0uYyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMNCmluZGV4IGRhYWE4 MWYyYWEuLjc1YzZmOGVmYzUgMTAwNjQ0DQotLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2Fy bS5jDQorKysgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jDQpAQCAtMTMyMiwxMSArMTMy Miw5NiBAQCBzdGF0aWMgaW50IGNvcHlfcGFydGlhbF9mZHQobGlieGxfX2djICpnYywgdm9pZCAq ZmR0LCB2b2lkICpwZmR0KQ0KICAgICByZXR1cm4gMDsNCiB9DQogDQotc3RhdGljIGludCBtb2Rp ZnlfcGFydGlhbF9mZHQobGlieGxfX2djICpnYywgdm9pZCAqcGZkdCkNCisvKg0KKyAqIFN0b3Jl IHZpcnR1YWxpemVkICdpb21tdXMnIHByb3BlcnRpZXMgZm9yIGV2ZXJ5IG5vZGUgYXR0YWNoZWQg dG8gSU9NTVUNCisgKiBhbmQgcGFzc3Rocm91Z2hlZCB0byBndWVzdC4NCisgKiBVc2VkIGFzIGEg bG9va3VwIHRhYmxlIGZvciBtYXBwaW5nIDxwaGFuZGxlIHBTSUQ+IC0+IDx2aGFuZGxlIHZTSUQ+ DQorICovDQorc3RydWN0IHZpb21tdV9zdHJlYW0gew0KKyAgICBYRU5fTElTVF9FTlRSWShzdHJ1 Y3QgdmlvbW11X3N0cmVhbSkgZW50cnk7DQorICAgIGNoYXIgcGF0aFsxMjhdOyAgICAgICAgICAv KiBEVCBwYXRoLCBzdGFibGUgYWNyb3NzIHJlc2l6ZXMgKi8NCisgICAgZmR0MzJfdCAqaW9tbXVz OyAgICAgICAgIC8qIGZ1bGx5IHZpcnR1YWxpemVkIGlvbW11cyBwcm9wZXJ0eSAqLw0KK307DQor DQorc3RhdGljIFhFTl9MSVNUX0hFQUQoLCBzdHJ1Y3QgdmlvbW11X3N0cmVhbSkgdmlvbW11X3N0 cmVhbV9saXN0Ow0KKw0KKy8qDQorICogSGVscGVyIGZ1bmN0aW9uIHdoaWNoIGNyZWF0ZXMgbWFw cGluZyBvZiBkdCBub2RlIHRvDQorICogdG8gdmlydHVhbGl6ZWQgJ2lvbW11cycgcHJvcGVydHkN CisgKiBNYXBwaW5ncyBzdG9yZWQgaW4gYSBnbG9iYWwgJ3Zpb21tdV9zdHJlYW1fbGlzdCcgdG8N CisgKiBtYWtlIGl0IHJldXNhYmxlIGZvciBldmVyeSBmZHQgcmVzaXplDQorICovDQorc3RhdGlj IGludCB2aW9tbXVfZ2V0X3N0cmVhbShsaWJ4bF9fZ2MgKmdjLA0KKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdWludDMyX3QgZG9taWQsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb25zdCBmZHQzMl90ICpwcm9wLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50 IHByb3BsZW4sDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyKiBwYXRo LCBmZHQzMl90ICoqaW9tbXVzKQ0KIHsNCi0gICAgaW50IG5vZGVvZmYsIHByb3BsZW4sIGksIHI7 DQorICAgIGludCBpLCByOw0KKyAgICB1aW50MzJfdCB2c2lkLCBwc2lkLCBwaGFuZGxlOw0KKyAg ICBzdHJ1Y3QgdmlvbW11X3N0cmVhbSAqdmlvbW11X3N0cmVhbTsNCisNCisgICAgLyogTG9va3Vw IGlmIHN0cmVhbSBmb3IgdGFyZ2V0IGRldmljZSBpcyBhbHJlYWR5IGFsbG9jYXRlZCAqLw0KKyAg ICBYRU5fTElTVF9GT1JFQUNIKHZpb21tdV9zdHJlYW0sICZ2aW9tbXVfc3RyZWFtX2xpc3QsIGVu dHJ5KQ0KKyAgICB7DQorICAgICAgICBpZiAoIXN0cmNtcCh2aW9tbXVfc3RyZWFtLT5wYXRoLCBw YXRoKSkgew0KKyAgICAgICAgICAgICppb21tdXMgPSB2aW9tbXVfc3RyZWFtLT5pb21tdXM7DQor ICAgICAgICAgICAgcmV0dXJuIDA7DQorICAgICAgICB9DQorICAgIH0NCisNCisgICAgLyogQWxs b2NhdGUgbmV3IHZpb21tdSBzdHJlYW0gKi8NCisgICAgdmlvbW11X3N0cmVhbSA9IG1hbGxvYyhz aXplb2Yoc3RydWN0IHZpb21tdV9zdHJlYW0pKTsNCisgICAgaWYgKCF2aW9tbXVfc3RyZWFtKQ0K KyAgICAgICAgcmV0dXJuIEVSUk9SX05PTUVNOw0KKyAgICBtZW1zZXQodmlvbW11X3N0cmVhbSwg MCwgc2l6ZW9mKHN0cnVjdCB2aW9tbXVfc3RyZWFtKSk7DQorICAgIHZpb21tdV9zdHJlYW0tPmlv bW11cyA9IG1hbGxvYyhwcm9wbGVuKTsNCisgICAgaWYgKCF2aW9tbXVfc3RyZWFtLT5pb21tdXMp IHsNCisgICAgICAgIGZyZWUodmlvbW11X3N0cmVhbSk7DQorICAgICAgICByZXR1cm4gRVJST1Jf Tk9NRU07DQorICAgIH0NCisgICAgbWVtc2V0KHZpb21tdV9zdHJlYW0tPmlvbW11cywgMCwgcHJv cGxlbik7DQorDQorICAgIExPRyhERUJVRywgIkNyZWF0aW5nIHZJT01NVSBzdHJlYW0gZm9yIGRl dmljZSAlcyIsDQorICAgICAgICBwYXRoKTsNCisNCisgICAgLyoNCisgICAgICogVmlydHVhbGl6 ZSBkZXZpY2UgImlvbW11cyIgcHJvcGVydHkNCisgICAgICogKHJlcGxhY2UgcElPTU1VIHdpdGgg dklPTU1VIHBoYW5kbGUgYW5kIHBTSURzIHdpdGggbWFwcGVkIHZTSURzKQ0KKyAgICAgKi8NCisg ICAgZm9yIChpID0gMDsgaSA8IHByb3BsZW4gLyA4OyArK2kpIHsNCisgICAgICAgIC8qIEFsbG9j YXRlIG5ldyB2U0lEIG1hcHBlZCB0byBwU0lEIGFuZCBwaHlzaWNhbCBJT01NVSAqLw0KKyAgICAg ICAgcGhhbmRsZSA9IGZkdDMyX3RvX2NwdShwcm9wW2kgKiAyXSk7DQorICAgICAgICBwc2lkID0g ZmR0MzJfdG9fY3B1KHByb3BbaSAqIDIgKyAxXSk7DQorICAgICAgICByID0geGNfZG9tYWluX3Zp b21tdV9hbGxvY2F0ZV92c2lkX3JhbmdlKENUWC0+eGNoLCBkb21pZCwgMSwgcHNpZCwNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGhhbmRsZSwgJnZz aWQpOw0KKyAgICAgICAgaWYgKHIpIHsNCisgICAgICAgICAgICBMT0coRVJST1IsICJDYW4ndCBh bGxvY2F0ZSBuZXcgdlNJRC92UklEIGZvciBndWVzdCBJT01NVSBkZXZpY2UiKTsNCisgICAgICAg ICAgICByZXR1cm4gcjsNCisgICAgICAgIH0NCisgICAgICAgIHZpb21tdV9zdHJlYW0tPmlvbW11 c1tpICogMl0gPSBjcHVfdG9fZmR0MzIoR1VFU1RfUEhBTkRMRV9WU01NVVYzKTsNCisgICAgICAg IHZpb21tdV9zdHJlYW0tPmlvbW11c1tpICogMiArIDFdID0gY3B1X3RvX2ZkdDMyKHZzaWQpOw0K KyAgICAgICAgTE9HKERFQlVHLCAiTWFwcGVkIHZTSUQ6ICV1IHRvIHBTSUQ6ICV1IiwgdnNpZCwg cHNpZCk7DQorICAgIH0NCisNCisgICAgc3RyY3B5KHZpb21tdV9zdHJlYW0tPnBhdGgsIHBhdGgp Ow0KKyAgICAqaW9tbXVzID0gdmlvbW11X3N0cmVhbS0+aW9tbXVzOw0KKw0KKyAgICBYRU5fTElT VF9JTlNFUlRfSEVBRCgmdmlvbW11X3N0cmVhbV9saXN0LCB2aW9tbXVfc3RyZWFtLCBlbnRyeSk7 DQorDQorICAgIHJldHVybiAwOw0KK30NCisNCisvKg0KKyAqIFVzZWQgdG8gdXBkYXRlIHBhcnRp YWwgZmR0IHdoZW4gdklPTU1VIGlzIGVuYWJsZWQNCisgKiBNYXBzIGR0IHByb3BlcnRpZXMgb2Yg SU9NTVUgZGV2aWNlcyB0byB2aXJ0dWFsIElPTU1VDQorICovDQorc3RhdGljIGludCB2aW9tbXVf bW9kaWZ5X3BhcnRpYWxfZmR0KGxpYnhsX19nYyAqZ2MsIHZvaWQgKnBmZHQsIHVpbnQzMl90IGRv bWlkKQ0KK3sNCisgICAgaW50IG5vZGVvZmYsIHByb3BsZW4sIHI7DQogICAgIGNvbnN0IGZkdDMy X3QgKnByb3A7DQogICAgIGZkdDMyX3QgKnByb3BfYzsNCisgICAgY2hhciBwYXRoWzEyOF07DQog DQogICAgIG5vZGVvZmYgPSBmZHRfcGF0aF9vZmZzZXQocGZkdCwgIi9wYXNzdGhyb3VnaCIpOw0K ICAgICBpZiAobm9kZW9mZiA8IDApDQpAQCAtMTM0MCwxMSArMTQyNSwxNiBAQCBzdGF0aWMgaW50 IG1vZGlmeV9wYXJ0aWFsX2ZkdChsaWJ4bF9fZ2MgKmdjLCB2b2lkICpwZmR0KQ0KICAgICAgICAg aWYgKCFwcm9wKQ0KICAgICAgICAgICAgIGNvbnRpbnVlOw0KIA0KLSAgICAgICAgcHJvcF9jID0g bGlieGxfX3phbGxvYyhnYywgcHJvcGxlbik7DQorICAgICAgICByID0gZmR0X2dldF9wYXRoKHBm ZHQsIG5vZGVvZmYsIHBhdGgsIHNpemVvZihwYXRoKSk7DQorICAgICAgICBpZiAoIHIgPCAwICkg ew0KKyAgICAgICAgICAgIExPRyhFUlJPUiwgIkNhbid0IGdldCBwYXNzdGhyb3VnaCBub2RlIHBh dGgiKTsNCisgICAgICAgICAgICByZXR1cm4gcjsNCisgICAgICAgIH0NCiANCi0gICAgICAgIGZv ciAoaSA9IDA7IGkgPCBwcm9wbGVuIC8gODsgKytpKSB7DQotICAgICAgICAgICAgcHJvcF9jW2kg KiAyXSA9IGNwdV90b19mZHQzMihHVUVTVF9QSEFORExFX1ZTTU1VVjMpOw0KLSAgICAgICAgICAg IHByb3BfY1tpICogMiArIDFdID0gcHJvcFtpICogMiArIDFdOw0KKyAgICAgICAgciA9IHZpb21t dV9nZXRfc3RyZWFtKGdjLCBkb21pZCwgcHJvcCwgcHJvcGxlbiwgcGF0aCwgJnByb3BfYyk7DQor ICAgICAgICBpZiAocikgew0KKyAgICAgICAgICAgIExPRyhFUlJPUiwgIkNhbid0IGdldCB2aW9t bXUgc3RyZWFtIik7DQorICAgICAgICAgICAgcmV0dXJuIHI7DQogICAgICAgICB9DQogDQogICAg ICAgICByID0gZmR0X3NldHByb3AocGZkdCwgbm9kZW9mZiwgImlvbW11cyIsIHByb3BfYywgcHJv cGxlbik7DQpAQCAtMTM1Niw3ICsxNDQ2LDYgQEAgc3RhdGljIGludCBtb2RpZnlfcGFydGlhbF9m ZHQobGlieGxfX2djICpnYywgdm9pZCAqcGZkdCkNCiANCiAgICAgcmV0dXJuIDA7DQogfQ0KLQ0K ICNlbHNlDQogDQogc3RhdGljIGludCBjaGVja19wYXJ0aWFsX2ZkdChsaWJ4bF9fZ2MgKmdjLCB2 b2lkICpmZHQsIHNpemVfdCBzaXplKQ0KQEAgLTEzNzUsNyArMTQ2NCw3IEBAIHN0YXRpYyBpbnQg Y29weV9wYXJ0aWFsX2ZkdChsaWJ4bF9fZ2MgKmdjLCB2b2lkICpmZHQsIHZvaWQgKnBmZHQpDQog ICAgIHJldHVybiAtRkRUX0VSUl9JTlRFUk5BTDsNCiB9DQogDQotc3RhdGljIGludCBtb2RpZnlf cGFydGlhbF9mZHQobGlieGxfX2djICpnYywgdm9pZCAqcGZkdCkNCitzdGF0aWMgaW50IHZpb21t dV9tb2RpZnlfcGFydGlhbF9mZHQobGlieGxfX2djICpnYywgdm9pZCAqcGZkdCwgdWludDMyX3Qg ZG9taWQpDQogew0KICAgICBMT0coRVJST1IsICJwYXJ0aWFsIGRldmljZSB0cmVlIG5vdCBzdXBw b3J0ZWQiKTsNCiANCkBAIC0xNTA3LDcgKzE1OTYsNyBAQCBuZXh0X3Jlc2l6ZToNCiAgICAgICAg IGlmIChpbmZvLT5hcmNoX2FybS52aW9tbXVfdHlwZSA9PSBMSUJYTF9WSU9NTVVfVFlQRV9TTU1V VjMpIHsNCiAgICAgICAgICAgICBGRFQoIG1ha2VfdnNtbXV2M19ub2RlKGdjLCBmZHQsIGFpbmZv LCBkb20pICk7DQogICAgICAgICAgICAgaWYgKHBmZHQpDQotICAgICAgICAgICAgICAgIEZEVCgg bW9kaWZ5X3BhcnRpYWxfZmR0KGdjLCBwZmR0KSApOw0KKyAgICAgICAgICAgICAgICBGRFQoIHZp b21tdV9tb2RpZnlfcGFydGlhbF9mZHQoZ2MsIHBmZHQsIGRvbS0+Z3Vlc3RfZG9taWQpICk7DQog ICAgICAgICB9DQogDQogICAgICAgICBmb3IgKGkgPSAwOyBpIDwgZF9jb25maWctPm51bV9kaXNr czsgaSsrKSB7DQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbWN0bC5jIGIveGVuL2FyY2gv YXJtL2RvbWN0bC5jDQppbmRleCBiNzZhZjU2ZmFkLi5kYzIxZGM5ZmNhIDEwMDY0NA0KLS0tIGEv eGVuL2FyY2gvYXJtL2RvbWN0bC5jDQorKysgYi94ZW4vYXJjaC9hcm0vZG9tY3RsLmMNCkBAIC0x Niw2ICsxNiw3IEBADQogI2luY2x1ZGUgPHhlbi90eXBlcy5oPg0KICNpbmNsdWRlIDx4c20veHNt Lmg+DQogI2luY2x1ZGUgPHB1YmxpYy9kb21jdGwuaD4NCisjaW5jbHVkZSA8YXNtL3Zpb21tdS5o Pg0KIA0KIHZvaWQgYXJjaF9nZXRfZG9tYWluX2luZm8oY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2dldGRvbWFpbmlu Zm8gKmluZm8pDQpAQCAtMTg2LDYgKzE4Nyw0MyBAQCBsb25nIGFyY2hfZG9fZG9tY3RsKHN0cnVj dCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBkb21haW4gKmQsDQogICAgIH0NCiAgICAgY2Fz ZSBYRU5fRE9NQ1RMX2R0X292ZXJsYXk6DQogICAgICAgICByZXR1cm4gZHRfb3ZlcmxheV9kb21j dGwoZCwgJmRvbWN0bC0+dS5kdF9vdmVybGF5KTsNCisNCisjaWZkZWYgQ09ORklHX0FSTV9WSVJU VUFMX0lPTU1VDQorICAgIGNhc2UgWEVOX0RPTUNUTF92aW9tbXVfYWxsb2NfdnNpZF9yYW5nZToN CisgICAgew0KKyAgICAgICAgaW50IHJjID0gMDsNCisgICAgICAgIHVpbnQxNl90IGk7DQorICAg ICAgICB1aW50MzJfdCB2c2lkOw0KKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdmlvbW11X2Fs bG9jX3ZzaWRfcmFuZ2UgKnZzaWRfcmFuZ2UgPQ0KKyAgICAgICAgICAgICZkb21jdGwtPnUudmlv bW11X2FsbG9jX3ZzaWRfcmFuZ2U7DQorDQorICAgICAgICBpZiAoIHZzaWRfcmFuZ2UtPnBhZCAp DQorICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQorDQorICAgICAgICBmb3IgKCBpID0gMDsg aSA8IHZzaWRfcmFuZ2UtPm5yX3NpZHM7IGkrKyApDQorICAgICAgICB7DQorICAgICAgICAgICAg cmMgPSB2aW9tbXVfYWxsb2NhdGVfdnNpZChkLCB2c2lkX3JhbmdlLT5maXJzdF9wc2lkDQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyBpLA0KKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZzaWRfcmFuZ2UtPnBoYW5kbGUsDQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZzaWQpOw0KKyAgICAgICAg ICAgIGlmKCByYyApDQorICAgICAgICAgICAgICAgIHJldHVybiByYzsNCisgICAgICAgIH0NCisN CisgICAgICAgIGlmICggIXJjICkNCisgICAgICAgIHsNCisgICAgICAgICAgICAvKiBDYWxjdWxh dGUgZmlyc3QgdlNJRCBmcm9tIGFsbG9jYXRlZCByYW5nZSAqLw0KKyAgICAgICAgICAgIHZzaWRf cmFuZ2UtPmZpcnN0X3ZzaWQgPSB2c2lkIC0NCisgICAgICAgICAgICAgICAgdnNpZF9yYW5nZS0+ bnJfc2lkcyArIDE7DQorICAgICAgICAgICAgcmMgPSBjb3B5X3RvX2d1ZXN0KHVfZG9tY3RsLCBk b21jdGwsIDEpOw0KKyAgICAgICAgICAgIGlmICggcmMgKQ0KKyAgICAgICAgICAgICAgICByYyA9 IC1FRkFVTFQ7DQorICAgICAgICB9DQorDQorICAgICAgICByZXR1cm4gcmM7DQorICAgIH0NCisj ZW5kaWYNCisNCiAgICAgZGVmYXVsdDoNCiAgICAgICAgIHJldHVybiBzdWJhcmNoX2RvX2RvbWN0 bChkb21jdGwsIGQsIHVfZG9tY3RsKTsNCiAgICAgfQ0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRl L3B1YmxpYy9kb21jdGwuaCBiL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaA0KaW5kZXggNTEw MzAwYmI2Ny4uMjcwODIxNWQ1YiAxMDA2NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21j dGwuaA0KKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oDQpAQCAtMTI3OSw2ICsxMjc5 LDI2IEBAIHN0cnVjdCB4ZW5fZG9tY3RsX2dldF9kb21haW5fc3RhdGUgew0KICAgICB1aW50NjRf dCB1bmlxdWVfaWQ7ICAgICAgLyogVW5pcXVlIGRvbWFpbiBpZGVudGlmaWVyLiAqLw0KIH07DQog DQorLyoNCisgKiBYRU5fRE9NQ1RMX3Zpb21tdV9hbGxvY192c2lkX3JhbmdlDQorICoNCisgKiBB bGxvY2F0ZSBndWVzdCB2U0lEIHJhbmdlIGFuZA0KKyAqIGVzdGFibGlzaCBwU0lELT52U0lEIG1h cHBpbmcgZm9yIHRhcmdldCByYW5nZSBhbmQgcGh5c2ljYWwgSU9NTVUgKHBoYW5kbGUpLg0KKyAq IEFsbG9jYXRlZCByYW5nZSBpcyBjb250aW5vdXMNCisgKi8NCitzdHJ1Y3QgeGVuX2RvbWN0bF92 aW9tbXVfYWxsb2NfdnNpZF9yYW5nZSB7DQorICAgIC8qIElOOiBSYW5nZSBmaXJzdCBwU0lEICAq Lw0KKyAgICB1aW50MzJfdCBmaXJzdF9wc2lkOw0KKyAgICAvKiBJTjogUGh5c2ljYWwgSU9NTVUg cGhhbmRsZSBiZWhpbmQgd2hpY2ggdGhlIHRhcmdldCBkZXZpY2Ugc3RyZWFtcyBhcmUgY29uZmln dXJlZCAqLw0KKyAgICB1aW50MzJfdCBwaGFuZGxlOw0KKyAgICAvKiBJTjogTnVtYmVyIG9mIHZT SURzIHRvIGFsbG9jYXRlICovDQorICAgIHVpbnQxNl90IG5yX3NpZHM7DQorICAgIC8qIHBhZGRp bmcsIG11c3QgYmUgMCAqLw0KKyAgICB1aW50MTZfdCBwYWQ7DQorICAgIC8qIE9VVDogTWFwcGVk IHJhbmdlIGZpcnN0IHZTSUQgKi8NCisgICAgdWludDMyX3QgZmlyc3RfdnNpZDsNCit9Ow0KKw0K IHN0cnVjdCB4ZW5fZG9tY3RsIHsNCiAvKiBTdGFibGUgZG9tY3RsIG9wczogaW50ZXJmYWNlX3Zl cnNpb24gaXMgcmVxdWlyZWQgdG8gYmUgMC4gICovDQogICAgIHVpbnQzMl90IGNtZDsNCkBAIC0x MzcxLDYgKzEzOTEsNyBAQCBzdHJ1Y3QgeGVuX2RvbWN0bCB7DQogI2RlZmluZSBYRU5fRE9NQ1RM X2dzaV9wZXJtaXNzaW9uICAgICAgICAgICAgICAgIDg4DQogI2RlZmluZSBYRU5fRE9NQ1RMX3Nl dF9sbGNfY29sb3JzICAgICAgICAgICAgICAgIDg5DQogI2RlZmluZSBYRU5fRE9NQ1RMX2dldF9k b21haW5fc3RhdGUgICAgICAgICAgICAgIDkwIC8qIHN0YWJsZSBpbnRlcmZhY2UgKi8NCisjZGVm aW5lIFhFTl9ET01DVExfdmlvbW11X2FsbG9jX3ZzaWRfcmFuZ2UgICAgICAgOTENCiAjZGVmaW5l IFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDANCiAjZGVmaW5lIFhF Tl9ET01DVExfZ2Ric3hfcGF1c2V2Y3B1ICAgICAgICAgICAgIDEwMDENCiAjZGVmaW5lIFhFTl9E T01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEwMDINCkBAIC0xNDM5LDYgKzE0NjAs NyBAQCBzdHJ1Y3QgeGVuX2RvbWN0bCB7DQogI2VuZGlmDQogICAgICAgICBzdHJ1Y3QgeGVuX2Rv bWN0bF9zZXRfbGxjX2NvbG9ycyAgICBzZXRfbGxjX2NvbG9yczsNCiAgICAgICAgIHN0cnVjdCB4 ZW5fZG9tY3RsX2dldF9kb21haW5fc3RhdGUgIGdldF9kb21haW5fc3RhdGU7DQorICAgICAgICBz dHJ1Y3QgeGVuX2RvbWN0bF92aW9tbXVfYWxsb2NfdnNpZF9yYW5nZSB2aW9tbXVfYWxsb2NfdnNp ZF9yYW5nZTsNCiAgICAgICAgIHVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBh ZFsxMjhdOw0KICAgICB9IHU7DQogfTsNCmRpZmYgLS1naXQgYS94ZW4veHNtL2ZsYXNrL2hvb2tz LmMgYi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMNCmluZGV4IGQ2NWJhMGFlYWUuLjYzMjFiNDMwOGIg MTAwNjQ0DQotLS0gYS94ZW4veHNtL2ZsYXNrL2hvb2tzLmMNCisrKyBiL3hlbi94c20vZmxhc2sv aG9va3MuYw0KQEAgLTg4MSw2ICs4ODEsMTAgQEAgc3RhdGljIGludCBjZl9jaGVjayBmbGFza19k b21jdGwoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IHhlbl9kb21jdGwgKm9wKQ0KICAgICBjYXNl IFhFTl9ET01DVExfc2V0X2xsY19jb2xvcnM6DQogICAgICAgICByZXR1cm4gY3VycmVudF9oYXNf cGVybShkLCBTRUNDTEFTU19ET01BSU4yLCBET01BSU4yX19TRVRfTExDX0NPTE9SUyk7DQogDQor ICAgIGNhc2UgWEVOX0RPTUNUTF92aW9tbXVfYWxsb2NfdnNpZF9yYW5nZToNCisgICAgICAgIHJl dHVybiBjdXJyZW50X2hhc19wZXJtKGQsIFNFQ0NMQVNTX0RPTUFJTjIsDQorICAgICAgICAgICAg RE9NQUlOMl9fVklPTU1VX0FMTE9DX1ZTSURfUkFOR0UpOw0KKw0KICAgICBkZWZhdWx0Og0KICAg ICAgICAgcmV0dXJuIGF2Y191bmtub3duX3Blcm1pc3Npb24oImRvbWN0bCIsIG9wLT5jbWQpOw0K ICAgICB9DQpkaWZmIC0tZ2l0IGEveGVuL3hzbS9mbGFzay9wb2xpY3kvYWNjZXNzX3ZlY3RvcnMg Yi94ZW4veHNtL2ZsYXNrL3BvbGljeS9hY2Nlc3NfdmVjdG9ycw0KaW5kZXggYmJiOWMxMTdlYy4u MzVhY2JlZmFiMiAxMDA2NDQNCi0tLSBhL3hlbi94c20vZmxhc2svcG9saWN5L2FjY2Vzc192ZWN0 b3JzDQorKysgYi94ZW4veHNtL2ZsYXNrL3BvbGljeS9hY2Nlc3NfdmVjdG9ycw0KQEAgLTI1Myw2 ICsyNTMsOCBAQCBjbGFzcyBkb21haW4yDQogICAgIHNldF9sbGNfY29sb3JzDQogIyBYRU5fRE9N Q1RMX2dldF9kb21haW5fc3RhdGUNCiAgICAgZ2V0X2RvbWFpbl9zdGF0ZQ0KKyMgWEVOX0RPTUNU TF92aW9tbXVfYWxsb2NfdnNpZF9yYW5nZQ0KKyAgICB2aW9tbXVfYWxsb2NfdnNpZF9yYW5nZQ0K IH0NCiANCiAjIFNpbWlsYXIgdG8gY2xhc3MgZG9tYWluLCBidXQgcHJpbWFyaWx5IGNvbnRhaW5z IGRvbWN0bHMgcmVsYXRlZCB0byBIVk0gZG9tYWlucw0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 00:08:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 00:08:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441916.1659503 (Exim 4.92) (envelope-from ) id 1xEFCb-0000gF-6H; Wed, 07 Oct 2026 00:08:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441916.1659503; Wed, 07 Oct 2026 00:08: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 1xEFCb-0000g8-34; Wed, 07 Oct 2026 00:08:09 +0000 Received: by outflank-mailman (input) for mailman id 1441916; Wed, 07 Oct 2026 00:08:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEFCY-0000cl-M9 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 00:08:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEFCY-007OJz-39 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 02:08:06 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac58d32-bab6-0a2a0a5309dd-0a2a4505c5b6-26 for ; Wed, 07 Oct 2026 02:08:06 +0200 Received: from [52.101.83.72] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac58d65-4cb1-0a2a45050019-34655348ae28-3 for ; Wed, 07 Oct 2026 02:08:05 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by VI0PR03MB11456.eurprd03.prod.outlook.com (2603:10a6:800:321::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.23; Wed, 7 Oct 2026 00:08:03 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.010; Wed, 7 Oct 2026 00:08: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=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=jwX/MTP4dAXcWd9Q3TcGfQU0EXWly2VmC94GYqXAI8W+dzOlYGXOeXwvMc2iLxD90t+L6qbdgkVOWpZPH/qdIf+o+VdBEfV4h2BYV0ARcyGtk1S3+bw6gODS6+EXAgh/8DKCFXt4q+mRMrlMQqq6UWr8a5fQ5VvzNGwBdhQjEhFm/k/JmU2rlp4GQEO0uF1MmKLBun1xWRdoo7kYa3sPeys8PuUxFUeVTrbQUHhmzgjezmPm61ZDTi0RZyH6YGYmWWgQh8vREy0IVlOXVsfHAWu56eEKAyeU7k+/17pcSZRu/ESSaatbkySjQxpefjtic63wNx/9s9d8EImIcu4WHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/4Pv0j5L6vsDxpnWHUZHpzdLXDnXJhbljgSj5IwNQps=; b=IX3Bf2QR2buH8LHSYjuBYP2shs6kP1Pn8KQ/erCHAVp0BJdtGW8TV2nSfUTMRCzGdqXgvOJN/5Oi8HusNaBycad3Ob/LBX8b1QpYMdgWjLnv1tLmjzPRLJR+2sKZZh4oRDe6JSVBJJd++2vbClZxrH/xxbPCWQ41icIN4wDglZlHNpLPUc+z5MF/xMblT4WKg9jaEZAKHpLZ9sIgqCPrD4wBhYBOvKA83rPUp4iZaCdYpNrsdq2KIhgT/gjcVUfxaqdZNlUkvUqRoW1FH73Yyoa3ZlhSbcV2PJdQwopDE4ou2WF9pf4Z+DqO9fEsy3cMCdpvjZ2xZoiwR+Rn9iTHsw== 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=/4Pv0j5L6vsDxpnWHUZHpzdLXDnXJhbljgSj5IwNQps=; b=H3dAS9XNohE1ZXE2cj58ORHQxjqekJiKE2/DfGQ2XaR5Ly+u2zuGohmyvcci05OniR2AipmX+rQHoZm4qA2YGbYMH8ZF2MCRn3T9mFf3S4V4dSlejTEq5ICX5uSuUMKf1lTpIn96ypl3QvyZXU6JNiis3sZWSCtaQ4WWRcsJdTM4wS3cPpl8orE1U8yJIAmghm23JrOQnOvy/Zb+O+z5Nc3TJqgr1GLFfUeI9JeSLkVwmDbWfhnFTUZF0M/VEDhCZ8b0TCCvFc3+Sn31enpebNR7GlO9WyqH17ex48A8PwiRod7O3s/pRVCxOCG2aZ9tdGrU4wcq3uGJOy6nP4XZwg== From: Milan Djokic To: "xen-devel@lists.xenproject.org" CC: Milan Djokic , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini Subject: [PATCH v4 22/22] doc/arm: vIOMMU design document Thread-Topic: [PATCH v4 22/22] doc/arm: vIOMMU design document Thread-Index: AQHdVe/sM7vi9s6Ii06+lLPrIVYxvA== Date: Wed, 7 Oct 2026 00:08:03 +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: 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: AS2PR03MB9587:EE_|VI0PR03MB11456:EE_ x-ms-office365-filtering-correlation-id: a9ae961d-4da8-4983-88b9-08df24070ea1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|56012099006|38070700021|260925022911599003|260925021311599003|260925021911599003|3023799007|32116099003|10067099003|6133799003|11063799006|22082099003|18002099003; x-microsoft-antispam-message-info: fFeP59HyW1nQz6Dl60GTdIZepkgt9oUfdqgm0CZ2GouExnq+Qo2hMQrhqB0C22tGcAj1OZOUMpdvihX5dc7Qxz79T5+2D6l/EveZZwyE06JtTyJoyuhE3wJl/UhzD+Zfm+c0m9UxMj7IXbBXEIoVPHD0E1uJomb84iZLAThCHF6d9AFfc1/BXq5qtN6QoOygGtLpQEkOSwuSlJyzcL/7d00A/bYt7OEytyy3m8220k6YuGJ5+Mb/wGZCWiOpaAQsnp+WlWBAWA1YW5ulS35BMmMlg5Dp9+0yDYeeibScf2iLt7jlmR6h4YIcVL8CA28lZV72/d8WgqqnKBWzNu/DEJkkI0j4QQCBXRCyZc4Y+/yfzrBnkTuMAmK35o08ZYpQFl3Mx2QUklkULCns/GHsuhUuT7UQZ8CSBEiHgo64iHYhcYF1r/U83KT+MZ9Ly/rm4UbR4yoDzo0H3rPEpmTBq9DrVFvLSfNLCk8vf1M4g6yqPOT/8WbjKUoRN5JY4H/WOPE72FEyMGkI3Z77zLIJ5dmp9JMMoQQnSEi1p39wOKQH4nBTPZGpB8xIgkEwC0vTNsamqlodJ/l50sAfCiQHFhkeRhTwJRrHRSRYEQthNwCqJT/2nzQFQosg6PUyyIeiGPdyNcOvcuHVjlEOQsE/osWHTe0DYgqCgCFE3anXkm2s0wrlLIeK3vgdosbzPsxoM8sSmAnik0A9Z7ftGlAlRFsxbmMRudvB24vJO0BnYYA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(56012099006)(38070700021)(260925022911599003)(260925021311599003)(260925021911599003)(3023799007)(32116099003)(10067099003)(6133799003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?REhROTdQVkl4R2NLVEN1U0dIN0xrR3RYcFgrV0o2SklITStWT0FvNkdXZUFR?= =?utf-8?B?dzZJcDlDWnBHY0hiMW83U1E4ck1zcWhBdEhaamt1YkZRL1V6SVIwSVNIdUkw?= =?utf-8?B?K2FYb1BwUDgzY1U2SDdnL1QvbW5yaWJRWFNMVm9HT2ZzNzR6aGd0RGN3WUZ6?= =?utf-8?B?K243RUtKd05Dc0lYQTBHYkZzK3UzUnhZS29TL1RpRG1OdUNLTklnWjFJUVRi?= =?utf-8?B?ejM0OHhCeEJocHdGWE1EbTFtdm9RY3hvcENqaW9yQVpMRE50dkp4a0Z4MkR5?= =?utf-8?B?YzhzUzhmTEtldndDa1Joa1lGZE5jcUdlaW8xNmwzRFd4MzlwbU5XVmp0SU9W?= =?utf-8?B?c05NbFVGaTAxY2JMaXYra3Y4TG96UnJEcTdNZmtoN0pqUW5KeGpobnhKdmlV?= =?utf-8?B?L09LVU9wVVB2R2lWKzBwbDlyMlBKTkxsbmFMcjBlajJIbHM1K0RxRlJFaEJH?= =?utf-8?B?dVFhMUJQQkw2R1ZOdGpmUVRhRzluUjNXL0drbDhaSEdvaDY0VTMzS3ZFNXFk?= =?utf-8?B?eklreGhLZGMrYWNKRmhDbThtWHpYdmwzVGZyb25iazNxc2IydFRKUndYU2pz?= =?utf-8?B?Q3l3LzRRaHo3cUZmOGxPNWZGSHlEYlAySFNCc0tJamlXVWpublZSWjJ2eThE?= =?utf-8?B?RXNZczhoWGpsa0RySFh3L2xqdElDSVRIOUwwMTR2UHowa3UzaVhtWERIcld6?= =?utf-8?B?UFcrcEdWalV0OGNRT0lFYlhwMVRvbkVucDZYMmRDZTFldWZ3eEVxYVl1UzA1?= =?utf-8?B?Wk9lQm5CaTcxeGN3amMxdWN4bGNPdXRvaG1rN0ZtbnV0cWFsNzRFbUNYdUtp?= =?utf-8?B?MzJ0VC9KUlJHMHZYTUVxTS80dEpNOTVaUUthKy9VVHJYellxaEcxL1d6RlBh?= =?utf-8?B?b3B0aWVMRUFBM0EzQTVDY2p6WHNncWtrMWdFWlg2NU5hTWNvQ2RKRFN6OHIw?= =?utf-8?B?eVI5TGF4VFVHSklLSzJvTzY2VlRDVjNNOEdZU2VhU3g0SnRxa0F5L0VnR3Zq?= =?utf-8?B?L1VaMFVhN0JRdldqV3ArRVRLOTVHVk4xN1g2b3B3bjlxVFVwY0w3eTBLRk0y?= =?utf-8?B?NVYxbkZ5MkxNd3JrTnlwSVRxbitjTS9ORElFSEFKRzJjWjJxVEMxY0hrZ1Mx?= =?utf-8?B?QjE4TG1nQWVyaUFOMUZ3RkNveFhNUGhET0Q2YVZ3Q1QxY09VK013NklLZ0x1?= =?utf-8?B?RGdwa25pbkRoL1U3eEJjOEdtcmRSSEpZdGtXNWp1Zkh0cHZ0c1QvYVB2a2pu?= =?utf-8?B?ZnU5Y1E1YzRVVi9ZOWl2Ym1jRjFMQm1xTnVnRXM4ck1vcE5vV2pVSjZ1c0ZU?= =?utf-8?B?Skc4OHdrWDJ4Q2Y0a2RmKy9DY252RG9BS0NlN1Y0aHJkTWlZdkRWYiszejNG?= =?utf-8?B?aXBWOEx0VEp2QkNpYnMxaURxL3MvTzhyWURUTkprUitSbTZoYzFabUEzR1M0?= =?utf-8?B?dDV0WkNNUnJPbzAxUGNPbVJsRHZmN21mT1piYU5ERkEzU2hCaldlVVVQMmUv?= =?utf-8?B?amozeVVIdkRMUHhaVkxtbmZjRjdtbEdBcXc4aDloSU9nVUtnSlc3djBPK0RY?= =?utf-8?B?RUdiWTBKdHZCNmRONzFUVWZWWXJ0QTVML3JqMDNtWWlOdWtmY0JCdHU3RkhT?= =?utf-8?B?YS84OTRrRGQ2Z0hSelBHdm5GL0JlKzhwSjF5dzlPQVRsYUZwbEEwcnRPVUpm?= =?utf-8?B?WUJmSHEvRkZZelRwYy9Jejd4RHhldlpwV1k1eUlHMm5TaThOZUhOaHV6V2tC?= =?utf-8?B?S2VUdUltNkJSWUJwTzM3eXBZdWFyRkI0UHdWK25LVTc0dUUyNHhVck1uRGFy?= =?utf-8?B?T1JXWnFzMys0SENpS0pVRmFSUm1sL1NSQmNlc09FM1BhTXhNcXgwSnlndCtF?= =?utf-8?B?NGsyWWo4NHY4aXhSL01xTXZIdDNqN0tqMjVneUk1UVlUQzYxcWtSdWZOTytv?= =?utf-8?B?Y2g2a2p0L0RyT1M4SGNZb0RiaytzaWpQZmxPUHgzM3Q1TGUxcUc1R2YzUFU0?= =?utf-8?B?dU9leEEzcUFNZlhMakVFSGZOemxqZzFpa1NDaENiSXppUWd5Zy9tdlgrbFNp?= =?utf-8?B?NFNPWUJjc0IyVUNTUkVxUmdnK3hIaU5yNWo4dTBybDZEUThtZFpaUG9QQjU5?= =?utf-8?B?Qm52SGZtb0ZTR00xaUowMU9keGgrNGJ2MitNNXBBWUtsV1ZwV1lYK05sdTVM?= =?utf-8?B?RllNT2MwQk9DN2pWVC91Q0dFRmM0UTQrUXFHZDJDYTQyMjhsajVrdHZNcldU?= =?utf-8?B?NytaTFRweFBMVDJ0eXRITHJTTkNnbnFBaHVnd2pFOGIwR2x5U2N0VVNTbDFG?= =?utf-8?B?Um0zTWtaNmJrZHVoK2pRNXNrWkJvSVVPcHF6VGRiSjNFNVZwc3N1Zz09?= 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: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a9ae961d-4da8-4983-88b9-08df24070ea1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 00:08:03.8472 (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: Ru7rdV86kErhBPrtJ+9dS+HKAsb7jMyeYBC0KRiwPRKVOApnlbwszZoLCskkAO5dwq/p/5iiVbuIdRidKlHFQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11456 X-purgate-ID: tlsNG-c201ff/1791331686-F4EA12A1-965838B4/0/0 X-purgate-type: clean X-purgate-size: 27404 VGhpcyBkb2N1bWVudCBvdXRsaW5lcyB0aGUgZGVzaWduIG9mIHRoZSBlbXVsYXRlZCBJT01NVSwN CmluY2x1ZGluZyBzdXBwb3J0ZWQgZmVhdHVyZXMsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQph bmQgZnV0dXJlIGltcHJvdmVtZW50cy4NCg0KU2lnbmVkLW9mZi1ieTogTWlsYW4gRGpva2ljIDxt aWxhbl9kam9raWNAZXBhbS5jb20+DQotLS0NCiBkb2NzL2Rlc2lnbnMvYXJtLXZpb21tdS5yc3Qg fCA1MDIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogMSBmaWxlIGNoYW5n ZWQsIDUwMiBpbnNlcnRpb25zKCspDQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRvY3MvZGVzaWducy9h cm0tdmlvbW11LnJzdA0KDQpkaWZmIC0tZ2l0IGEvZG9jcy9kZXNpZ25zL2FybS12aW9tbXUucnN0 IGIvZG9jcy9kZXNpZ25zL2FybS12aW9tbXUucnN0DQpuZXcgZmlsZSBtb2RlIDEwMDY0NA0KaW5k ZXggMDAwMDAwMDAwMC4uYzY4ZTc3MTcxMQ0KLS0tIC9kZXYvbnVsbA0KKysrIGIvZG9jcy9kZXNp Z25zL2FybS12aW9tbXUucnN0DQpAQCAtMCwwICsxLDUwMiBAQA0KKz09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCitEZXNpZ24gUHJvcG9z YWw6IEFkZCBTTU1VdjMgU3RhZ2UtMSBTdXBwb3J0IGZvciBYRU4gR3Vlc3RzDQorPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KKw0KKzpB dXRob3I6ICAgICBNaWxhbiBEam9raWMgPG1pbGFuX2Rqb2tpY0BlcGFtLmNvbT4NCis6RGF0ZTog ICAgICAgMjAyNi0wMi0xMw0KKzpTdGF0dXM6ICAgICBEcmFmdA0KKw0KK0ludHJvZHVjdGlvbg0K Kz09PT09PT09PT09PQ0KKw0KK1RoZSBTTU1VdjMgc3VwcG9ydHMgdHdvIHN0YWdlcyBvZiB0cmFu c2xhdGlvbi4gRWFjaCBzdGFnZSBvZiB0cmFuc2xhdGlvbiANCitjYW4gYmUNCitpbmRlcGVuZGVu dGx5IGVuYWJsZWQuIEFuIGluY29taW5nIGFkZHJlc3MgaXMgbG9naWNhbGx5IHRyYW5zbGF0ZWQg ZnJvbSANCitWQSB0bw0KK0lQQSBpbiBzdGFnZSAxLCB0aGVuIHRoZSBJUEEgaXMgaW5wdXQgdG8g c3RhZ2UgMiB3aGljaCB0cmFuc2xhdGVzIHRoZSBJUEEgdG8NCit0aGUgb3V0cHV0IFBBLiBTdGFn ZSAxIHRyYW5zbGF0aW9uIHN1cHBvcnQgaXMgcmVxdWlyZWQgdG8gcHJvdmlkZSANCitpc29sYXRp b24gYmV0d2VlbiBkaWZmZXJlbnQNCitkZXZpY2VzIHdpdGhpbiBPUy4gWEVOIGFscmVhZHkgc3Vw cG9ydHMgU3RhZ2UgMiB0cmFuc2xhdGlvbiBidXQgdGhlcmUgaXMgbm8NCitzdXBwb3J0IGZvciBT dGFnZSAxIHRyYW5zbGF0aW9uLg0KK1RoaXMgZGVzaWduIHByb3Bvc2FsIG91dGxpbmVzIHRoZSBp bnRyb2R1Y3Rpb24gb2YgU3RhZ2UtMSBTTU1VdjMgc3VwcG9ydCANCitpbiBYZW4gZm9yIEFSTSBn dWVzdHMuDQorDQorTW90aXZhdGlvbg0KKz09PT09PT09PT0NCisNCitBUk0gc3lzdGVtcyB1dGls aXppbmcgU01NVXYzIHJlcXVpcmUgc3RhZ2UtMSBhZGRyZXNzIHRyYW5zbGF0aW9uIHRvIA0KK2Vu c3VyZSBzZWN1cmUgRE1BIGFuZA0KK2d1ZXN0IG1hbmFnZWQgSS9PIG1lbW9yeSBtYXBwaW5ncy4N CitXaXRoIHN0YWdlLTEgZW5hYmxlZCwgZ3Vlc3QgbWFuYWdlcyBJT1ZBIHRvIElQQSBtYXBwaW5n cyB0aHJvdWdoIGl0cyBvd24gDQorSU9NTVUgZHJpdmVyLg0KKw0KK1RoaXMgZmVhdHVyZSBlbmFi bGVzOg0KKw0KKy0gU3RhZ2UtMSB0cmFuc2xhdGlvbiBmb3IgdGhlIGd1ZXN0IGRvbWFpbg0KKy0g RGV2aWNlIHBhc3N0aHJvdWdoIHdpdGggcGVyLWRldmljZSBJL08gYWRkcmVzcyBzcGFjZQ0KKw0K K0Rlc2lnbiBPdmVydmlldw0KKz09PT09PT09PT09PT09PQ0KKw0KK1RoZXNlIGNoYW5nZXMgcHJv dmlkZSBlbXVsYXRlZCBTTU1VdjMgc3VwcG9ydDoNCisNCistICoqU01NVXYzIFN0YWdlLTEgVHJh bnNsYXRpb24qKjogc3RhZ2UtMSBhbmQgbmVzdGVkIHRyYW5zbGF0aW9uIHN1cHBvcnQNCisgIGlu IFNNTVV2MyBkcml2ZXIuDQorLSAqKnZJT01NVSBBYnN0cmFjdGlvbioqOiBWaXJ0dWFsIElPTU1V IGZyYW1ld29yayBmb3IgZ3Vlc3Qgc3RhZ2UtMQ0KKyAgaGFuZGxpbmcuDQorLSAqKlJlZ2lzdGVy L0NvbW1hbmQgRW11bGF0aW9uKio6IFNNTVV2MyByZWdpc3RlciBlbXVsYXRpb24gYW5kIGNvbW1h bmQNCisgIHF1ZXVlIGhhbmRsaW5nLg0KKy0gKipEZXZpY2UgVHJlZSBFeHRlbnNpb25zKio6IEFk ZHMgYGlvbW11c2AgYW5kIHZpcnR1YWwgU01NVXYzIG5vZGVzIHRvDQorICBkZXZpY2UgdHJlZXMg Zm9yIGRvbTAgYW5kIGRvbTBsZXNzIHNjZW5hcmlvcy4NCistICoqQnVpbGQgQ29uZmlndXJhdGlv bioqOiBJbnRyb2R1Y2VzIGEgS2NvbmZpZyBhcmd1bWVudHMNCisgIChDT05GSUdfQVJNX1ZJUlRV QUxfSU9NTVUsIENPTkZJR19WSVJUVUFMX0FSTV9TTU1VX1YzKSBmb3IgYnVpbGQtdGltZQ0KKyAg ZW5hYmxlbWVudC4NCisNCitEZXBlbmRpbmcgb24gdGhlIGRvbWFpbiB0eXBlLCB0aGUgZW11bGF0 ZWQgSU9NTVUgbW9kZWwgaXMgdGhlIGZvbGxvd2luZzoNCisNCistIEZvciB0aGUgaGFyZHdhcmUg ZG9tYWluLCB0aGUgaG9zdCBsYXlvdXQgaXMgcmUtdXNlZC4gVGhlIG51bWJlciBvZiBleHBvc2Vk DQorICBJT01NVXMgdG8gaGFyZHdhcmUgZG9tYWluIGlzIGVxdWFsIHRvIG51bWJlciBvZiBwaHlz aWNhbCBJT01NVXMNCisgIHByZXNlbnQgKDEtMSBtYXBwaW5nKS4NCistIEZvciBub24taGFyZHdh cmUgZG9tYWluLCBhIHNpbmdsZSB2SU9NTVUgZGV2aWNlIGlzIGV4cG9zZWQgdG8gdGhlIGd1ZXN0 IGFuZA0KKyAgbWFwcGVkIHRvIG9uZSBvciBtb3JlIHBoeXNpY2FsIElPTU1VcyB0aHJvdWdoIGEg WGVuLW1hbmFnZWQgdHJhbnNsYXRpb24gbGF5ZXINCisNCitUaGUgdklPTU1VIGZlYXR1cmUgcHJv dmlkZXMgYSBnZW5lcmljIGZyYW1ld29yayB0b2dldGhlciB3aXRoIGEgYmFja2VuZA0KK2ltcGxl bWVudGF0aW9uIHNwZWNpZmljIHRvIHRoZSB0YXJnZXQgSU9NTVUgdHlwZS4gVGhlIGJhY2tlbmQg aXMgcmVzcG9uc2libGUNCitmb3IgaW1wbGVtZW50aW5nIHRoZSBoYXJkd2FyZS1zcGVjaWZpYyBk YXRhIHN0cnVjdHVyZXMgYW5kIGNvbW1hbmQgaGFuZGxpbmcNCitsb2dpYyAoY3VycmVudGx5IG9u bHkgU01NVXYzIGlzIHN1cHBvcnRlZCkuDQorDQorVGhpcyBtb2R1bGFyIGRlc2lnbiBhbGxvd3Mg dGhlIHN0YWdlLTEgc3VwcG9ydCB0byBiZSByZXVzZWQNCitmb3Igb3RoZXIgSU9NTVUgYXJjaGl0 ZWN0dXJlcyBpbiB0aGUgZnV0dXJlLg0KKw0KK3ZJT01NVSBhcmNoaXRlY3R1cmUNCis9PT09PT09 PT09PT09PT09PT09DQorDQorUmVzcG9uc2liaWxpdGllczoNCisNCitHdWVzdDoNCisgLSBDb25m aWd1cmVzIHN0YWdlLTEgdmlhIHZJT01NVSBjb21tYW5kcy4NCisgLSBIYW5kbGVzIHN0YWdlLTEg ZmF1bHRzIHJlY2VpdmVkIGZyb20gWGVuLg0KKw0KK1hlbjoNCisgLSBFbXVsYXRlcyB0aGUgSU9N TVUgaW50ZXJmYWNlIChyZWdpc3RlcnMsIGNvbW1hbmRzLCBldmVudHMpLg0KKyAtIFByb3ZpZGVz IHZTSUQtPnBTSUQgbWFwcGluZ3MuDQorIC0gUHJvZ3JhbXMgc3RhZ2UtMS9zdGFnZS0yIGNvbmZp Z3VyYXRpb24gaW4gdGhlIHBoeXNpY2FsIElPTU1VLg0KKyAtIFByb3BhZ2F0ZSBzdGFnZS0xIGZh dWx0cyB0byBndWVzdC4NCisNCitUaGUgc3RhZ2UtMSBjb250ZXh0IGlzIHNoYXJlZCBiZXR3ZWVu IHN0cmVhbXMgYXNzaWduZWQgdG8gdGhlIHNhbWUgZGV2aWNlLg0KK1RoaXMgZm9sbG93cyB0aGUg TGludXggU01NVXYzIGRyaXZlciBtb2RlbCwgd2hlcmUgdGhlIElPTU1VIGRvbWFpbiBpcyBhc3Nv Y2lhdGVkDQord2l0aCB0aGUgbWFzdGVyL2RldmljZSwgd2hpbGUgdGhlIGluZGl2aWR1YWwgU0lE cyBhcmUgcmVwcmVzZW50ZWQgYnkgc2VwYXJhdGUNCitTVEVzIHBvaW50aW5nIHRvIHRoZSBzYW1l IHRyYW5zbGF0aW9uIGNvbnRleHQuIFRoaXMgaXMgY29uc2lkZXJlZCBzdWZmaWNpZW50IGZvcg0K K3RoZSBjdXJyZW50IFNNTVV2MyBkcml2ZXIgbW9kZWwsIGFsdGhvdWdoIHRoZSBTTU1VdjMgYXJj aGl0ZWN0dXJlIGRvZXMgbm90DQorZm9yYmlkIGhhdmluZyBzZXBhcmF0ZSB0cmFuc2xhdGlvbiBj b250ZXh0cyBmb3IgZGlmZmVyZW50IFNJRHMuDQorDQordklPTU1VIGNvbW1hbmRzIGFuZCBmYXVs dHMgYXJlIHRyYW5zbWl0dGVkIGJldHdlZW4gZ3Vlc3QgYW5kIFhlbiB2aWENCitjb21tYW5kIGFu ZCBldmVudCBxdWV1ZXMgKG9uZSBjb21tYW5kL2V2ZW50IHF1ZXVlIGNyZWF0ZWQgcGVyIGd1ZXN0 KS4NCisNCit2SU9NTVUgY29tbWFuZCBGbG93Og0KKw0KKzo6DQorDQorICAgIEd1ZXN0Og0KKyAg ICAgICAgc21tdV9jbWQodlNJRCwgSU9WQSAtPiBJUEEpDQorDQorICAgIFhlbjoNCisgICAgICAg IHRyYXAgTU1JTyByZWFkL3dyaXRlDQorICAgICAgICB0cmFuc2xhdGUgdlNJRC0+cFNJRA0KKyAg ICAgICAgc3RvcmUgc3RhZ2UtMSBzdGF0ZQ0KKyAgICAgICAgcHJvZ3JhbSBwSU9NTVUgZm9yIChw U0lELCBJUEEgLT4gUEEpDQorDQorQWxsIGhhcmR3YXJlIHByb2dyYW1taW5nIG9mIHRoZSBwaHlz aWNhbCBJT01NVSBpcyBwZXJmb3JtZWQgZXhjbHVzaXZlbHkgYnkgWGVuLg0KKw0KK3ZJT01NVSBT dGFnZS0xIGZhdWx0IGhhbmRsaW5nIGZsb3c6DQorDQorOjoNCisNCisgICAgWGVuOg0KKyAgICAg ICAgcmVjZWl2ZXMgc3RhZ2UtMSBmYXVsdA0KKyAgICAgICAgdHJpZ2dlcnMgdklPTU1VIGNhbGxi YWNrDQorICAgICAgICBpbmplY3RzIHZpcnR1YWwgZmF1bHQNCisNCisgICAgR3Vlc3Q6DQorICAg ICAgICByZWNlaXZlcyBhbmQgaGFuZGxlcyBmYXVsdA0KKw0KK1JlZ2lzdGVyIGFjY2Vzcw0KKy0t LS0tLS0tLS0tLS0tLQ0KKw0KK0d1ZXN0IGFjY2Vzc2VzIHRvIFNNTVVWMyByZWdpc3RlcnMgYXJl IHRyYXBwZWQgdmlhIE1NSU8gcmVnaW9ucy4gdklPTU1VIGVtdWxhdGVzDQorYSBzdWJzZXQgb2Yg U01NVXYzIHJlZ2lzdGVycyByZWxldmFudCB0byBjdXJyZW50bHkgc3VwcG9ydGVkIGZlYXR1cmVz Lg0KK1Vuc3VwcG9ydGVkIHJlZ2lzdGVycyBhcmUgaGFuZGxlZCBhcyBSQVogKFJlYWQtQXMtWmVy bykgYW5kIFdJIChXcml0ZS1JZ25vcmVkKQ0KK2ZvciB0aGUgcmVnaXN0ZXIgcmVhZCBhbmQgd3Jp dGUgb3BlcmF0aW9ucywgcmVzcGVjdGl2ZWx5Lg0KKw0KK3ZTTU1VdjMgaXMgYSBwYXJ0aWFsbHkg ZW11bGF0ZWQgcmVzb3VyY2UgZm9yIHRoZSBndWVzdCBkb21haW4uIFNvbWUNCitmZWF0dXJlIHJl Z2lzdGVyIGJpdHMgKFNNTVVfSURSKSBhcmUgcmVmbGVjdGluZyB3aGF0IHRoZSB1bmRlcmx5aW5n IEhXIGFjdHVhbGx5DQorc3VwcG9ydCB3aGlsZSB0aGUgcmVzdCBpcyBwcmVzZXQgaW4gdGhlIGVt dWxhdGlvbiBsYXllciB0byBsaW1pdCBndWVzdCBmcm9tDQordXNpbmcgZmVhdHVyZXMgd2hpY2gg YXJlIG5vdCBzdXBwb3J0ZWQgYnkgdGhlIGVtdWxhdGlvbi4gQWxzbywgaW1wbGVtZW50ZXINCitp ZGVudGlmaWNhdGlvbiByZWdpc3RlciBpcyBmdWxseSBlbXVsYXRlZCwgcHJvdmlkaW5nIGdlbmVy aWMgQVJNIGltcGxlbWVudGVyDQorSUQgdmFsdWVzLCB0byBhdm9pZCBhY3RpdmF0aW5nIGVycmF0 YS9xdWlyayBwYXRocyBpbiB0aGUgZ3Vlc3QgU01NVXYzIGRyaXZlci4NCisNCitTdXBwb3J0ZWQg U01NVXYzIENvbW1hbmRzDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KKw0KK1RoZSB2SU9N TVUgaW1wbGVtZW50YXRpb24gY3VycmVudGx5IHN1cHBvcnRzIGEgc3Vic2V0IG9mIHRoZSBTTU1V djMNCithcmNoaXRlY3R1cmFsIGNvbW1hbmQgc2V0IHJlcXVpcmVkIGZvciBzdGFnZS0xIHRyYW5z bGF0aW9uIG1hbmFnZW1lbnQuDQorDQorQ29tbWFuZHMgYXJlIHN1Ym1pdHRlZCBieSB0aGUgZ3Vl c3QgdGhyb3VnaCB0aGUgdmlydHVhbCBDb21tYW5kIFF1ZXVlDQorKENNRFEpIGFuZCBjb25zdW1l ZCBieSBYZW4sIHdoaWNoIHRyYW5zbGF0ZXMgdGhlbSBpbnRvIG9wZXJhdGlvbnMgb24gdGhlDQor cGh5c2ljYWwgU01NVXYzIGhhcmR3YXJlLg0KKw0KK1NvbWUgY29tbWFuZHMgYXJlIGZ1bGx5IGhh bmRsZWQgYnkgdGhlIGVtdWxhdGlvbiBsYXllciwgd2hpbGUgb3RoZXJzIGFyZQ0KK2N1cnJlbnRs eSB0cmVhdGVkIGFzIGFyY2hpdGVjdHVyYWwgbm8tb3BzIGJlY2F1c2UgdGhlIHJlcXVpcmVkIGJl aGF2aW9yDQoraXMgZWl0aGVyIGltcGxpY2l0bHkgZ3VhcmFudGVlZCBieSBYZW4gb3Igbm90IHll dCBtb2RlbGVkIGV4cGxpY2l0bHkuDQorDQorRW11bGF0aW9uIGhhbmRsZWQgY29tbWFuZHM6DQor DQorLSBDTURfQ0ZHSV9TVEUNCistIENNRF9UTEJJX05IX0FTSUQNCistIENNRF9UTEJJX05TTkhf QUxMDQorLSBDTURfVExCSV9OSF9WQQ0KKw0KK05vLW9wL0ltcGxpY2l0bHkgaGFuZGxlZCBjb21t YW5kczoNCisNCistIENNRF9TWU5DDQorLSBDTURfUFJFRkVUQ0hfQ0ZHDQorLSBDTURfQ0ZHSV9D RA0KKy0gQ01EX0NGR0lfQ0RfQUxMDQorLSBDTURfQ0ZHSV9BTEwNCisNCitDb21tYW5kIEhhbmRs aW5nIE1vZGVsDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KKw0KK1RoZSBndWVzdCBzdWJtaXRz IGNvbW1hbmRzIHRocm91Z2ggdGhlIHZpcnR1YWwgQ01EUSBpbnRlcmZhY2UuDQorDQorWGVuOg0K Kw0KKy0gVmFsaWRhdGVzIGNvbW1hbmRzDQorLSBUcmFuc2xhdGVzIHZpcnR1YWwgaWRlbnRpZmll cnMgKHZTSUQtPnBTSUQpIHdoZXJlIHJlcXVpcmVkDQorLSBQcm9ncmFtcyB0aGUgcGh5c2ljYWwg U01NVQ0KKy0gUGVyZm9ybXMgc3luY2hyb25pemF0aW9uDQorDQorVGhlIHBoeXNpY2FsIFNNTVUg ZXhlY3V0ZXMgdGhlIHJlc3VsdGluZyBpbnZhbGlkYXRpb24gb3IgY29uZmlndXJhdGlvbg0KK29w ZXJhdGlvbnMuDQorDQorVW5zdXBwb3J0ZWQgQ29tbWFuZHMNCistLS0tLS0tLS0tLS0tLS0tLS0t LQ0KKw0KK0NvbW1hbmRzIGFzc29jaWF0ZWQgd2l0aCBjdXJyZW50bHkgdW5zdXBwb3J0ZWQgYXJj aGl0ZWN0dXJhbCBmZWF0dXJlcw0KK2FyZSBub3QgaW1wbGVtZW50ZWQuDQorDQorVGhpcyBpbmNs dWRlcyBjb21tYW5kcyByZWxhdGVkIHRvOg0KKw0KKy0gUFJJDQorLSBBVFMNCistIEFkZHJlc3Mv UmFuZ2UgVExCIGludmFsaWRhdGlvbiAoY3VycmVudGx5LCBhbGwgVExCSSBjb21tYW5kcyBwZXJm b3JtIGNvbXBsZXRlDQorICBkb21haW4gVExCIGludmFsaWRhdGlvbikNCistIEFkdmFuY2VkIHN0 YWxsL3JldHJ5IHNlbWFudGljcw0KKy0gQ0QgcnVudGltZSB1cGRhdGUvc3luYw0KKw0KK3ZTSUQg TWFwcGluZyBMYXllcg0KKy0tLS0tLS0tLS0tLS0tLS0tLQ0KKw0KK0VhY2ggbm9uLWhhcmR3YXJl IGRvbWFpbi12aXNpYmxlIFN0cmVhbSBJRCAodlNJRCkgaXMgbWFwcGVkIGJ5IFhlbiB0byBhIHBo eXNpY2FsDQorU3RyZWFtIElEIChwU0lEKS4gVGhlIG1hcHBpbmcgaXMgbWFpbnRhaW5lZCBwZXIt ZG9tYWluLiBUaGUgYWxsb2NhdGlvbiBwb2xpY3kNCitndWFyYW50ZWVzIHZTSUQgdW5pcXVlbmVz cyB3aXRoaW4gYSBkb21haW4gd2hpbGUgYWxsb3dpbmcgcmV1c2Ugb2YgcFNJRHMgZm9yDQorZGlm ZmVyZW50IHBJT01NVXMuDQorDQorKiBQbGF0Zm9ybSBkZXZpY2VzIHJlY2VpdmUgaW5kaXZpZHVh bGx5IGFsbG9jYXRlZCB2U0lEcy4NCisqIFBDSSBkZXZpY2VzIHJlY2VpdmUgYSBjb250aWd1b3Vz IHZTSUQgcmFuZ2UgZGVyaXZlZCBmcm9tIFJJRCBzcGFjZS4NCisNCisNCitTdXBwb3J0ZWQgRGV2 aWNlIE1vZGVsDQorPT09PT09PT09PT09PT09PT09PT09PQ0KKw0KK0N1cnJlbnRseSwgdGhlIHZJ T01NVSBmcmFtZXdvcmsgc3VwcG9ydHMgb25seSBkZXZpY2VzIGRlc2NyaWJlZCB2aWEgdGhlDQor RGV2aWNlIFRyZWUgKERUKSBtb2RlbC4gVGhpcyBpbmNsdWRlcyBwbGF0Zm9ybSBkZXZpY2VzIGFu ZCBiYXNpYyBQQ0kNCitkZXZpY2VzIHN1cHBvcnQgaW5zdGFudGlhdGVkIHRocm91Z2ggdGhlIHZQ Q0kgRFQgbm9kZS4gQUNQSS1kZXNjcmliZWQNCitkZXZpY2VzIGFyZSBub3Qgc3VwcG9ydGVkLg0K Kw0KK0d1ZXN0IGFzc2lnbmVkIHBsYXRmb3JtIGRldmljZXMgYXJlIG1hcHBlZCB2aWEgYGlvbW11 c2AgcHJvcGVydHk6DQorDQorOjoNCisNCisgICAgPCZwSU9NTVUgcFNJRD4gLT4gPCZ2SU9NTVUg dlNJRD4NCisNCitQQ0kgZGV2aWNlcyB1c2UgUklELWJhc2VkIG1hcHBpbmcgdmlhIHRoZSByb290 IGNvbXBsZXggYGlvbW11LW1hcGA6DQorDQorOjoNCisNCisgICAgPFJJRC1iYXNlICZ2aW9tbXUg dlNJRC1iYXNlIGxlbmd0aD4NCisNCitQQ0kgVG9wb2xvZ3kgQXNzdW1wdGlvbnMgYW5kIENvbnN0 cmFpbnRzOg0KKw0KKy0gUklEIHNwYWNlIG11c3QgYmUgY29udGlndW91cw0KKy0gUHJlLWRlZmlu ZWQgY29udGludW91cyBwU0lEIHNwYWNlICgwLTB4MTAwMCkNCistIE5vIHJ1bnRpbWUgUENJIHJl Y29uZmlndXJhdGlvbg0KKy0gU2luZ2xlIHJvb3QgY29tcGxleCBhc3N1bWVkDQorLSBNYXBwaW5n IGlzIGZpeGVkIGF0IGd1ZXN0IERUIGNvbnN0cnVjdGlvbg0KKw0KK0NvbnN0cmFpbnRzIGZvciBQ Q0kgZGV2aWNlcyB3aWxsIGJlIGFkZHJlc3NlZCBhcyBwYXJ0IG9mIHRoZSBmdXR1cmUgd29yayBv bg0KK3RoaXMgZmVhdHVyZS4NCisNCitTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KKz09PT09PT09 PT09PT09PT09PT09PT09DQorDQorU3RhZ2UtMSB0cmFuc2xhdGlvbiBwcm92aWRlcyBpc29sYXRp b24gYmV0d2VlbiBndWVzdCBkZXZpY2VzIGJ5DQorZW5mb3JjaW5nIGEgcGVyLWRldmljZSBJL08g YWRkcmVzcyBzcGFjZSwgcHJldmVudGluZyB1bmF1dGhvcml6ZWQgRE1BLg0KK1dpdGggdGhlIGlu dHJvZHVjdGlvbiBvZiBlbXVsYXRlZCBJT01NVSwgYWRkaXRpb25hbCBwcm90ZWN0aW9uDQorbWVj aGFuaXNtcyBhcmUgcmVxdWlyZWQgdG8gbWluaW1pemUgc2VjdXJpdHkgcmlza3MuDQorDQorMS4g T2JzZXJ2YXRpb246DQorLS0tLS0tLS0tLS0tLS0tDQorU3VwcG9ydCBmb3IgU3RhZ2UtMSB0cmFu c2xhdGlvbiBpbiBTTU1VdjMgaW50cm9kdWNlcyBuZXcgZGF0YSBzdHJ1Y3R1cmVzIA0KKyhgczFf Y2ZnYCBhbG9uZ3NpZGUgYHMyX2NmZ2ApDQorYW5kIGxvZ2ljIHRvIHdyaXRlIGJvdGggU3RhZ2Ut MSBhbmQgU3RhZ2UtMiBlbnRyaWVzIGluIHRoZSBTdHJlYW0gVGFibGUgDQorRW50cnkgKFNURSks IGluY2x1ZGluZyBhbiBgYWJvcnRgDQorZmllbGQgdG8gaGFuZGxlIHBhcnRpYWwgY29uZmlndXJh dGlvbiBzdGF0ZXMuDQorDQorKipSaXNrOioqDQorV2l0aG91dCBwcm9wZXIgaGFuZGxpbmcsIGEg cGFydGlhbGx5IGFwcGxpZWQgY29uZmlndXJhdGlvbg0KK21pZ2h0IGxlYXZlIGd1ZXN0IERNQSBt YXBwaW5ncyBpbiBhbiBpbmNvbnNpc3RlbnQgc3RhdGUsIHBvdGVudGlhbGx5DQorZW5hYmxpbmcg dW5hdXRob3JpemVkIGFjY2VzcyBvciBjYXVzaW5nIGNyb3NzLWRvbWFpbiBpbnRlcmZlcmVuY2Uu DQorDQorKipNaXRpZ2F0aW9uOioqICooSGFuZGxlZCBieSBkZXNpZ24pKg0KK1RoaXMgZmVhdHVy ZSBpbnRyb2R1Y2VzIGxvZ2ljIHRoYXQgd3JpdGVzIGJvdGggYHMxX2NmZ2AgYW5kIGBzMl9jZmdg IHRvDQorU1RFIGFuZCBtYW5hZ2VzIHRoZSBgYWJvcnRgIGZpZWxkIC0gb25seSBjb25zaWRlcmlu Zw0KK2NvbmZpZ3VyYXRpb24gaWYgZnVsbHkgYXR0YWNoZWQuIFRoaXMgZW5zdXJlcyAgaW5jb21w bGV0ZSBvciBpbnZhbGlkDQorZGV2aWNlIGNvbmZpZ3VyYXRpb25zIGFyZSBzYWZlbHkgaWdub3Jl ZCBieSB0aGUgaHlwZXJ2aXNvci4NCisNCisyLiBPYnNlcnZhdGlvbjoNCistLS0tLS0tLS0tLS0t LS0NCitHdWVzdHMgY2FuIG5vdyBpbnZhbGlkYXRlIFN0YWdlLTEgY2FjaGVzOyBpbnZhbGlkYXRp b24gbmVlZHMgZm9yd2FyZGluZw0KK3RvIFNNTVV2MyBoYXJkd2FyZSB0byBtYWludGFpbiBjb2hl cmVuY2UuDQorDQorKipSaXNrOioqDQorRmFpbGluZyB0byBwcm9wYWdhdGUgY2FjaGUgaW52YWxp ZGF0aW9uIGNvdWxkIGFsbG93IHN0YWxlIG1hcHBpbmdzLA0KK2VuYWJsaW5nIGFjY2VzcyB0byBv bGQgbWFwcGluZ3MgYW5kIHBvc3NpYmx5DQorZGF0YSBsZWFrYWdlIG9yIG1pc3JvdXRpbmcgYmV0 d2VlbiBkZXZpY2VzIGFzc2lnbmVkIHRvIHRoZSBzYW1lIGd1ZXN0Lg0KKw0KKyoqTWl0aWdhdGlv bjoqKg0KK1RoZSBndWVzdCBtdXN0IGlzc3VlIGFwcHJvcHJpYXRlIGludmFsaWRhdGlvbiBjb21t YW5kcyB3aGVuZXZlcg0KK2l0cyBzdGFnZS0xIEkvTyBtYXBwaW5ncyBhcmUgbW9kaWZpZWQgdG8g ZW5zdXJlIHRoYXQgdHJhbnNsYXRpb24gY2FjaGVzDQorcmVtYWluIGNvaGVyZW50Lg0KKw0KKzMu IE9ic2VydmF0aW9uOg0KKy0tLS0tLS0tLS0tLS0tLQ0KK0ludHJvZHVjaW5nIG9wdGlvbmFsIHBl ci1ndWVzdCBlbmFibGVkIGZlYXR1cmVzIChgdmlvbW11YCBhcmd1bWVudCBpbiB4bCANCitndWVz dCBjb25maWcpIG1lYW5zIHNvbWUgZ3Vlc3RzDQorbWF5IG9wdC1vdXQuDQorDQorKipSaXNrOioq DQorR3Vlc3RzIHdpdGhvdXQgdklPTU1VIGVuYWJsZWQgKHN0YWdlLTIgb25seSkgY291bGQgcG90 ZW50aWFsbHkgZG9taW5hdGUNCithY2Nlc3MgdG8gdGhlIHBoeXNpY2FsIGNvbW1hbmQgYW5kIGV2 ZW50IHF1ZXVlcywgc2luY2UgdGhleSBieXBhc3MgdGhlDQorZW11bGF0aW9uIGxheWVyIGFuZCBw cm9jZXNzaW5nIGlzIGZhc3RlciBjb21wYXJpbmcgdG8gdklPTU1VLWVuYWJsZWQgZ3Vlc3RzLg0K Kw0KKyoqTWl0aWdhdGlvbjoqKg0KK0F1ZGl0IHRoZSBpbXBhY3Qgb2YgZW11bGF0aW9uIG92ZXJo ZWFkIGVmZmVjdCBvbiBJT01NVSBwcm9jZXNzaW5nIGZhaXJuZXNzDQoraW4gYSBtdWx0aS1ndWVz dCBlbnZpcm9ubWVudC4NCitDb25zaWRlciBlbmFibGluZy9kaXNhYmxpbmcgc3RhZ2UtMSBvbiBh IHN5c3RlbSBsZXZlbCwgaW5zdGVhZCBvZiBwZXItZG9tYWluLg0KKw0KKzQuIE9ic2VydmF0aW9u Og0KKy0tLS0tLS0tLS0tLS0tLQ0KK0d1ZXN0cyBoYXZlIHRoZSBhYmlsaXR5IHRvIGlzc3VlIFN0 YWdlLTEgSU9NTVUgY29tbWFuZHMgbGlrZSBjYWNoZSANCitpbnZhbGlkYXRpb24sIHN0cmVhbSB0 YWJsZSBlbnRyaWVzDQorY29uZmlndXJhdGlvbiwgZXRjLiBBbiBhZHZlcnNhcmlhbCBndWVzdCBt YXkgaXNzdWUgYSBoaWdoIHZvbHVtZSBvZiANCitjb21tYW5kcyBpbiByYXBpZCBzdWNjZXNzaW9u Lg0KKw0KKyoqUmlzazoqKg0KK0V4Y2Vzc2l2ZSBjb21tYW5kcyByZXF1ZXN0cyBjYW4gY2F1c2Ug aGlnaCBoeXBlcnZpc29yIENQVSBjb25zdW1wdGlvbiANCithbmQgZGlzcnVwdCBzY2hlZHVsaW5n LA0KK2xlYWRpbmcgdG8gZGVncmFkZWQgc3lzdGVtIHJlc3BvbnNpdmVuZXNzIGFuZCBwb3RlbnRp YWwgDQorZGVuaWFsLW9mLXNlcnZpY2Ugc2NlbmFyaW9zLg0KKw0KKyoqTWl0aWdhdGlvbjoqKg0K Kw0KKy0gSW1wbGVtZW50IHZJT01NVSBjb21tYW5kcyBleGVjdXRpb24gcmVzdGFydCBhbmQgY29u dGludWF0aW9uIHN1cHBvcnQ6DQorDQorICAtIEludHJvZHVjZSBwcm9jZXNzaW5nIGJ1ZGdldCB3 aXRoIG9ubHkgYSBsaW1pdGVkIGFtb3VudCBvZiBjb21tYW5kcw0KKyAgICBoYW5kbGVkIHBlciBp bnZvY2F0aW9uLg0KKyAgLSBJZiBhZGRpdGlvbmFsIGNvbW1hbmRzIHJlbWFpbiBwZW5kaW5nIGFm dGVyIHRoZSBidWRnZXQgaXMgZXhoYXVzdGVkLA0KKyAgICBkZWZlciBmdXJ0aGVyIHByb2Nlc3Np bmcgYW5kIHJlc3VtZSBpdCBhc3luY2hyb25vdXNseSwgZS5nLiB2aWEgYQ0KKyAgICBwZXItZG9t YWluIHRhc2tsZXQuDQorDQorLSBCYXRjaCBtdWx0aXBsZSBjb21tYW5kcyBvZiBzYW1lIHR5cGUg dG8gcmVkdWNlIGVtdWxhdGlvbiBvdmVyaGVhZDoNCisNCisgIC0gSW5zcGVjdCB0aGUgY29tbWFu ZCBxdWV1ZSBhbmQgZ3JvdXAgY29tbWFuZHMgdGhhdCBjYW4gYmUgcHJvY2Vzc2VkDQorICAgIHRv Z2V0aGVyIChlLmcuIG11bHRpcGxlIHN1Y2Nlc3NpdmUgaW52YWxpZGF0aW9uIHJlcXVlc3RzIG9y IFNURQ0KKyAgICB1cGRhdGVzIGZvciB0aGUgc2FtZSBTSUQpLg0KKyAgLSBFeGVjdXRlIHRoZSBl bnRpcmUgYmF0Y2ggaW4gb25lIGdvLCByZWR1Y2luZyByZXBlYXRlZCBhY2Nlc3NlcyB0bw0KKyAg ICBndWVzdCBtZW1vcnkgYW5kIGVtdWxhdGlvbiBvdmVyaGVhZCBwZXIgY29tbWFuZC4NCisgIC0g VGhpcyByZWR1Y2VzIENQVSB0aW1lIHNwZW50IGluIHRoZSB2SU9NTVUgY29tbWFuZCBwcm9jZXNz aW5nIGxvb3AuDQorICAgIFRoZSBvcHRpbWl6YXRpb24gaXMgYXBwbGljYWJsZSBvbmx5IHdoZW4g Y29uc2VjdXRpdmUgY29tbWFuZHMgb2YgdGhlDQorICAgIHNhbWUgdHlwZSBvcGVyYXRlIG9uIHRo ZSBzYW1lIFNJRC9jb250ZXh0Lg0KKw0KKzUuIE9ic2VydmF0aW9uOg0KKy0tLS0tLS0tLS0tLS0t LQ0KK1NvbWUgZ3Vlc3QgY29tbWFuZHMgaXNzdWVkIHRvd2FyZHMgdklPTU1VIGFyZSBwcm9wYWdh dGVkIHRvIHBJT01NVSANCitjb21tYW5kIHF1ZXVlIChlLmcuIFRMQiBpbnZhbGlkYXRlKS4NCisN CisqKlJpc2s6KioNCitFeGNlc3NpdmUgY29tbWFuZHMgcmVxdWVzdHMgZnJvbSBhYnVzaXZlIGd1 ZXN0IGNhbiBjYXVzZSBmbG9vZGluZyBvZiANCitwaHlzaWNhbCBJT01NVSBjb21tYW5kIHF1ZXVl LA0KK2xlYWRpbmcgdG8gZGVncmFkZWQgcElPTU1VIHJlc3BvbnNpdmVuZXNzIG9uIGNvbW1hbmRz IGlzc3VlZCBmcm9tIG90aGVyIA0KK2d1ZXN0cy4NCisNCisqKk1pdGlnYXRpb246KioNCisNCist IEJhdGNoIGNvbW1hbmRzIHRoYXQgYXJlIHByb3BhZ2F0ZWQgdG8gdGhlIHBJT01NVSBjb21tYW5k IHF1ZXVlIGFuZA0KKyAgaW1wbGVtZW50IGJhdGNoIGV4ZWN1dGlvbiBwYXVzZS9jb250aW51YXRp b24uDQorICBSZWx5IG9uIHRoZSBzYW1lIG1lY2hhbmlzbXMgYXMgaW4gdGhlIHByZXZpb3VzIG9i c2VydmF0aW9uDQorICAoY29tbWFuZCBjb250aW51YXRpb24gYW5kIGJhdGNoaW5nIG9mIHBJT01N VS1yZWxhdGVkIGNvbW1hbmRzIG9mIHRoZSBzYW1lDQorICB0eXBlIGFuZCBjb250ZXh0KS4NCist IElmIHBvc3NpYmxlLCBpbXBsZW1lbnQgZG9tYWluIHBlbmFsaXphdGlvbiBieSBhZGRpbmcgYSBw ZXItZG9tYWluIGJ1ZGdldA0KKyAgZm9yIHZJT01NVS9wSU9NTVUgdXNhZ2U6DQorDQorICAtIEFw cGx5IHBlci1kb21haW4gZHluYW1pYyBidWRnZXRpbmcgb2YgYWxsb3dlZCBJT01NVSBjb21tYW5k cyB0bw0KKyAgICBleGVjdXRlIHBlciBpbnZvY2F0aW9uLCByZWR1Y2luZyB0aGUgYnVkZ2V0IGZv ciBndWVzdHMgd2l0aA0KKyAgICBleGNlc3NpdmUgY29tbWFuZCByZXF1ZXN0cyBvdmVyIGEgbG9u Z2VyIHBlcmlvZCBvZiB0aW1lDQorICAtIENvbWJpbmUgd2l0aCBjb21tYW5kIGNvbnRpbnVhdGlv biBtZWNoYW5pc20NCisNCis2LiBPYnNlcnZhdGlvbjoNCistLS0tLS0tLS0tLS0tLS0NCitUaGUg dklPTU1VIGZlYXR1cmUgaW5jbHVkZXMgYW4gZXZlbnQgcXVldWUgdXNlZCB0byBmb3J3YXJkIElP TU1VIGV2ZW50cw0KK3RvIHRoZSBndWVzdCAoZS5nLiB0cmFuc2xhdGlvbiBmYXVsdHMsIGludmFs aWQgU3RyZWFtIElEcywgcGVybWlzc2lvbiBlcnJvcnMpLg0KK0EgbWFsaWNpb3VzIGd1ZXN0IG1h eSBtaXNjb25maWd1cmUgaXRzIElPTU1VIHN0YXRlIG9yIGludGVudGlvbmFsbHkgdHJpZ2dlcg0K K2ZhdWx0cyBhdCBhIGhpZ2ggcmF0ZS4NCisNCisqKlJpc2s6KioNCitPY2N1cnJlbmNlIG9mIElP TU1VIGV2ZW50cyB3aXRoIGhpZ2ggZnJlcXVlbmN5IGNhbiBjYXVzZSBYZW4gdG8gZmxvb2QgdGhl DQorZXZlbnQgcXVldWUgYW5kIGRpc3J1cHQgc2NoZWR1bGluZyB3aXRoDQoraGlnaCBoeXBlcnZp c29yIENQVSBsb2FkIGZvciBldmVudHMgaGFuZGxpbmcuDQorDQorKipNaXRpZ2F0aW9uOioqDQor DQorLSBJbXBsZW1lbnQgZmFpbC1zYWZlIHN0YXRlIGJ5IGRpc2FibGluZyBldmVudHMgZm9yd2Fy ZGluZyB3aGVuIGZhdWx0cyANCisgIGFyZSBvY2N1cnJlZCB3aXRoIGhpZ2ggZnJlcXVlbmN5IGFu ZA0KKyAgbm90IHByb2Nlc3NlZCBieSBndWVzdDoNCisNCisgIC0gSW50cm9kdWNlIGEgcGVyLWRv bWFpbiBwZW5kaW5nIGV2ZW50IGNvdW50ZXIuDQorICAtIFN0b3AgZm9yd2FyZGluZyBldmVudHMg dG8gdGhlIGd1ZXN0IG9uY2UgdGhlIG51bWJlciBvZiB1bnByb2Nlc3NlZA0KKyAgICBldmVudHMg cmVhY2hlcyBhIHByZWRlZmluZWQgdGhyZXNob2xkLg0KKw0KKy0gQ29uc2lkZXIgZGlzYWJsaW5n IHRoZSBlbXVsYXRlZCBldmVudCBxdWV1ZSBmb3IgdW50cnVzdGVkIGd1ZXN0cy4NCistIE5vdGUg dGhhdCB0aGlzIHJpc2sgaXMgbW9yZSBnZW5lcmFsIGFuZCBtYXkgYWxzbyBhcHBseSB0byBzdGFn ZS0yLW9ubHkNCisgIGd1ZXN0cy4gVGhpcyBzZWN0aW9uIGFkZHJlc3NlcyBtaXRpZ2F0aW9ucyBp biB0aGUgZW11bGF0ZWQgSU9NTVUgbGF5ZXINCisgIG9ubHkuIE1pdGlnYXRpb24gb2YgcGh5c2lj YWwgZXZlbnQgcXVldWUgZmxvb2Rpbmcgc2hvdWxkIGFsc28gYmUgY29uc2lkZXJlZA0KKyAgaW4g dGhlIHRhcmdldCBwSU9NTVUgZHJpdmVyLg0KKw0KKzcuIE9ic2VydmF0aW9uOg0KKy0tLS0tLS0t LS0tLS0tLQ0KK3ZJT01NVSBgQ0ZHSV9TVEVgIGNvbW1hbmRzIGNhbiB0cmlnZ2VyIHNlcmlhbGl6 ZWQgU1RFIHByb2dyYW1taW5nIG9uIHRoZSBwSU9NTVUNCit3aGlsZSBgeGVuX2RvbWFpbi0+bG9j a2AsIGBkZXZpY2VzX2xvY2tgIGFuZCBgY21kX3F1ZXVlX2xvY2tgIGFyZSBoZWxkLCB3aXRoDQor bG9jYWwgaW50ZXJydXB0cyBkaXNhYmxlZC4gU1RFIHByb2dyYW1taW5nIG1heSBpc3N1ZSBtdWx0 aXBsZSBwb2xsaW5nIENNRF9TWU5DDQorb3BlcmF0aW9ucywgZWFjaCB3aXRoIGEgb25lLXNlY29u ZCB0aW1lb3V0Lg0KKw0KKyoqUmlzazoqKg0KK0FuIGFidXNpdmUgZ3Vlc3QgY2FuIGlzc3VlIENG R0lfU1RFIGNvbW1hbmRzIHRoYXQgY2F1c2UgbXVsdGlwbGUgQ01EX1NZTkMNCitvcGVyYXRpb25z IHRvIHJlYWNoIHRoZWlyIHBvbGxpbmcgdGltZW91dC4gVGhpcyBjYW4ga2VlcCBhIHBDUFUgd2l0 aCBpbnRlcnJ1cHRzDQorZGlzYWJsZWQgZm9yIGEgc2lnbmlmaWNhbnQgcGVyaW9kIG9mIHRpbWUs IGRlbGF5aW5nIGludGVycnVwdCBoYW5kbGluZyBhbmQNCitwb3RlbnRpYWxseSBkZWdyYWRpbmcg dGhlIHJlc3BvbnNpdmVuZXNzIG9mIFhlbiBhbmQgb3RoZXIgZG9tYWlucyBydW5uaW5nIG9uDQor dGhlIHNhbWUgcENQVS4NCisNCisqKk1pdGlnYXRpb246KioNCisNCistIEltcGxlbWVudCBwaW5u aW5nIG9yIG90aGVyd2lzZSBtYWludGFpbmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlIHJlcXVpcmVk DQorICBvYmplY3RzIGJlZm9yZSByZWxlYXNpbmcgdGhlIHJlbGV2YW50IGxvY2tzLCBhbGxvd2lu ZyB0aGUNCisgIHNlcmlhbGl6ZWQgU1RFIHByb2dyYW1taW5nIHRvIGJlIHBlcmZvcm1lZCB3aXRo b3V0IGhvbGRpbmcgbG9ja3MgYW5kIHdpdGgNCisgIGxvY2FsIGludGVycnVwdHMgZW5hYmxlZC4N CistIENvbnNpZGVyIHJlZGVzaWduaW5nIHRoZSBTTU1VdjMgY29tbWFuZCBwcm9jZXNzaW5nIGFu ZCBsb2NraW5nIG1vZGVsIGluDQorICBmdXR1cmUgaW1wcm92ZW1lbnRzIHRvIGF2b2lkIHBlcmZv cm1pbmcgcG90ZW50aWFsbHkgbG9uZy1ydW5uaW5nIHBJT01NVQ0KKyAgb3BlcmF0aW9ucyB3aGls ZSBob2xkaW5nIGxvY2tzIGFuZCB3aXRoIGxvY2FsIGludGVycnVwdHMgZGlzYWJsZWQuDQorDQor UGVyZm9ybWFuY2UgSW1wYWN0DQorPT09PT09PT09PT09PT09PT09DQorDQorV2l0aCBpb21tdSBz dGFnZS0xIGFuZCBuZXN0ZWQgdHJhbnNsYXRpb24gaW5jbHVzaW9uLCBwZXJmb3JtYW5jZSANCitv dmVyaGVhZCBpcyBpbnRyb2R1Y2VkIGNvbXBhcmluZyB0byBleGlzdGluZywNCitzdGFnZS0yIG9u bHkgdXNhZ2UgaW4gWGVuLiBPbmNlIG1hcHBpbmdzIGFyZSBlc3RhYmxpc2hlZCwgdHJhbnNsYXRp b25zIA0KK3Nob3VsZCBub3QgaW50cm9kdWNlIHNpZ25pZmljYW50IG92ZXJoZWFkLg0KK0VtdWxh dGVkIHBhdGhzIG1heSBpbnRyb2R1Y2UgbW9kZXJhdGUgb3ZlcmhlYWQsIHByaW1hcmlseSBhZmZl Y3RpbmcgDQorZGV2aWNlIGluaXRpYWxpemF0aW9uIGFuZCBldmVudC9jb21tYW5kIGhhbmRsaW5n Lg0KK1Rlc3RpbmcgaXMgcGVyZm9ybWVkIG9uIFJlbmVzYXMgUi1DYXIgcGxhdGZvcm0uDQorUGVy Zm9ybWFuY2UgaXMgbW9zdGx5IGltcGFjdGVkIGJ5IGVtdWxhdGVkIHZJT01NVSBvcGVyYXRpb25z LCByZXN1bHRzIA0KK3Nob3duIGluIHRoZSBmb2xsb3dpbmcgdGFibGUuDQorDQorKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KK3wgdklPTU1VIE9wZXJhdGlvbiAgICAgICAgICAgICAgfCBFeGVjdXRpb24gdGltZSBpbiBn dWVzdCAgICAgICAgIHwNCisrPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSs9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0rDQorfCBSZWcgcmVhZCAgICAgICAgICAgICAgICAg ICAgICB8IG1lZGlhbjogNjQ1bnMsIHdvcnN0LWNhc2U6IDJ1cyAgfA0KKystLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCit8 IFJlZyB3cml0ZSAgICAgICAgICAgICAgICAgICAgIHwgbWVkaWFuOiA2MzBucywgd29yc3QtY2Fz ZTogMXVzICB8DQorKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KK3wgSW52YWxpZGF0ZSBUTEIgICAgICAgICAgICAgICAg fCBtZWRpYW46IDJ1cywgd29yc3QtY2FzZTogMTB1cyAgIHwNCisrLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQorfCBJbnZh bGlkYXRlIFNURSAgICAgICAgICAgICAgICB8IG1lZGlhbjogNXVzIHdvcnN0X2Nhc2U6IDEwMHVz ICAgfA0KKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCisNCitXaXRoIHZJT01NVSBleHBvc2VkIHRvIGd1ZXN0LCBndWVz dCBPUyBoYXMgdG8gaW5pdGlhbGl6ZSBJT01NVSBkZXZpY2UNCithbmQgY29uZmlndXJlIHN0YWdl LTEgbWFwcGluZ3MgZm9yIHRoZSBkZXZpY2VzDQorYXR0YWNoZWQgdG8gaXQuDQorRm9sbG93aW5n IHRhYmxlIHNob3dzIGluaXRpYWxpemF0aW9uIHN0YWdlcyB3aGljaCBpbXBhY3Qgc3RhZ2UtMSBl bmFibGVkIA0KK2d1ZXN0IGJvb3QgdGltZSBhbmQgY29tcGFyZXMgaXQgd2l0aA0KK3N0YWdlLTEg ZGlzYWJsZWQgZ3Vlc3QuDQorDQorTk9URTogRGV2aWNlIHByb2JlIGV4ZWN1dGlvbiB0aW1lIHZh cmllcyBkZXBlbmRpbmcgb24gZGV2aWNlIGNvbXBsZXhpdHkuDQorQSBVU0IgaG9zdCBjb250cm9s bGVyIHdhcyBzZWxlY3RlZCBhcyB0aGUgdGVzdCBkZXZpY2UgaW4gdGhpcyBjYXNlLg0KKw0KKyst LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KK3wgU3RhZ2UgICAgICAgICAgICAgICB8IFN0YWdlLTEgRW5hYmxlZCBH dWVzdCB8IFN0YWdlLTEgRGlzYWJsZWQgR3Vlc3QgfA0KKys9PT09PT09PT09PT09PT09PT09PT0r PT09PT09PT09PT09PT09PT09PT09PT0rPT09PT09PT09PT09PT09PT09PT09PT09Kw0KK3wgSU9N TVUgSW5pdCAgICAgICAgICB8IH4xMG1zICAgICAgICAgICAgICAgICB8IC8gICAgICAgICAgICAg ICAgICAgICAgfA0KKystLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KK3wgRGV2IEF0dGFjaCAvIE1hcHBpbmd8IH4x MDBtcyAgICAgICAgICAgICAgICB8IH45MG1zICAgICAgICAgICAgICAgICAgfA0KKystLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KKw0KK0ZvciBkZXZpY2VzIGNvbmZpZ3VyZWQgd2l0aCBkeW5hbWljIERNQSBtYXBw aW5ncywgRE1BIGFsbG9jYXRlL21hcC91bm1hcCANCitvcGVyYXRpb25zIHBlcmZvcm1hbmNlIGlz DQorYWxzbyBpbXBhY3RlZCBvbiBzdGFnZS0xIGVuYWJsZWQgZ3Vlc3RzLg0KK0R5bmFtaWMgRE1B IG1hcHBpbmcgb3BlcmF0aW9uIHRyaWdnZXIgZW11bGF0ZWQgSU9NTVUgZnVuY3Rpb25zIGxpa2Ug bW1pbyANCit3cml0ZS9yZWFkIGFuZCBUTEIgaW52YWxpZGF0aW9ucy4NCisNCisrLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCit8IERNQSBPcCAgICAgICAgfCBTdGFnZS0xIEVuYWJsZWQgR3Vlc3QgICAgIHwgU3Rh Z2UtMSBEaXNhYmxlZCBHdWVzdCAgIHwNCisrPT09PT09PT09PT09PT09Kz09PT09PT09PT09PT09 PT09PT09PT09PT09PSs9PT09PT09PT09PT09PT09PT09PT09PT09PSsNCit8IGRtYV9hbGxvYyAg ICAgfCBtZWRpYW46IDIwdXMsIHdvcnN0OiA1bXMgIHwgbWVkaWFuOiA4dXMsIHdvcnN0OiA2MHVz IHwNCisrLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCit8IGRtYV9mcmVlICAgICAgfCBtZWRpYW46IDUwMHVzLCB3 b3JzdDogMTBtc3wgbWVkaWFuOiA2dXMsIHdvcnN0OiAzMHVzIHwNCisrLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN Cit8IGRtYV9tYXAgICAgICAgfCBtZWRpYW46IDEydXMsIHdvcnN0OiA2MHVzIHwgbWVkaWFuOiAz dXMsIHdvcnN0OiAyMHVzIHwNCisrLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCit8IGRtYV91bm1hcCAgICAgfCBt ZWRpYW46IDQwMHVzLCB3b3JzdDogNW1zIHwgbWVkaWFuOiA1dXMsIHdvcnN0OiAyMHVzIHwNCisr LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCisNCitUZXN0aW5nDQorPT09PT09PQ0KKw0KKy0gUUVNVS1iYXNlZCBB Uk0gc3lzdGVtIHRlc3RzIGZvciBTdGFnZS0xIHRyYW5zbGF0aW9uLg0KKy0gQWN0dWFsIGhhcmR3 YXJlIHZhbGlkYXRpb24gdG8gZW5zdXJlIGNvbXBhdGliaWxpdHkgd2l0aCByZWFsIFNNTVV2MyAN CisgIGltcGxlbWVudGF0aW9ucy4NCistIFVuaXQvRnVuY3Rpb25hbCB0ZXN0cyB2YWxpZGF0aW5n IGNvcnJlY3QgdHJhbnNsYXRpb25zIChub3QgaW1wbGVtZW50ZWQpLg0KKw0KK01pZ3JhdGlvbiBh bmQgQ29tcGF0aWJpbGl0eQ0KKz09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KKw0KK1RoaXMg b3B0aW9uYWwgZmVhdHVyZSBkZWZhdWx0cyB0byBkaXNhYmxlZCAoQ09ORklHX0FSTV9WSVJUVUFM X0lPTU1VPW4sDQorQ09ORklHX1ZJUlRVQUxfQVJNX1NNTVVfVjM9bikuDQorDQorRnV0dXJlIGlt cHJvdmVtZW50cw0KKz09PT09PT09PT09PT09PT09PT0NCisNCistIEltcGxlbWVudCB0aGUgcHJv cG9zZWQgbWl0aWdhdGlvbnMgdG8gYWRkcmVzcyBzZWN1cml0eSByaXNrcyB0aGF0IGFyZSANCisg IG5vdCBjb3ZlcmVkIGJ5IHRoZSBjdXJyZW50IGRlc2lnbg0KKyAgKGV2ZW50cyBiYXRjaGluZywg Y29tbWFuZHMgZXhlY3V0aW9uIGNvbnRpbnVhdGlvbikNCistIFBDSSBzdXBwb3J0DQorLSBTdXBw b3J0IGZvciBvdGhlciBJT01NVSBIVyAoUmVuZXNhcywgUklTQy1WLCBldGMuKQ0KKw0KK1JlZmVy ZW5jZXMNCis9PT09PT09PT09DQorDQorLSBPcmlnaW5hbCBmZWF0dXJlIGltcGxlbWVudGVkIGJ5 IFJhaHVsIFNpbmdoOg0KKw0KK2h0dHBzOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcHJvamVjdC94 ZW4tZGV2ZWwvY292ZXIvY292ZXIuMTY2OTg4ODUyMi5naXQucmFodWwuc2luZ2hAYXJtLmNvbS8g DQorDQorLSBTTU1VdjMgYXJjaGl0ZWN0dXJlIGRvY3VtZW50YXRpb24NCistIEV4aXN0aW5nIHZJ T01NVSBjb2RlIHBhdHRlcm5zIChLVk0sIFFFTVUpDQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZp bGUNCi0tIA0KMi40My4wDQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 07 05:45:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 05:45:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1441978.1659513 (Exim 4.92) (envelope-from ) id 1xEKTA-0001Z3-RQ; Wed, 07 Oct 2026 05:45:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1441978.1659513; Wed, 07 Oct 2026 05:45: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 1xEKTA-0001Ys-MK; Wed, 07 Oct 2026 05:45:36 +0000 Received: by outflank-mailman (input) for mailman id 1441978; Wed, 07 Oct 2026 05:45:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEKT9-0001Ym-2b for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 05:45:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEKT7-00CRx5-Ob for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 07:45:33 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac5dc6e-bab6-0a2a0a5309dd-0a2a450b98d2-14 for ; Wed, 07 Oct 2026 07:45:33 +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 6ac5dc7d-b7e8-0a2a450b0019-a237832facce-3 for ; Wed, 07 Oct 2026 07:45: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 3BB144EE01FB; Wed, 7 Oct 2026 07:45: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=1791351933; b=w/3JMW86rJQTwqW4oeDBjWstPixHRYuIM9LP41wdGCu/5nz0m4nl8RxOMDfApxFtFpFP lgtBdOOB32nECFJv9O6GT8nBW0QbP52hrkmIYk/P9NyHO4M8BCB/9Arz68vWdJhbs+9Mc +w51kxT0claRQwc07LHDla+Yst6WS4xRWB5s18MmZ1/pNjMSIqXwZ0x4CtOlNjSwAqtdR hgUk7iIF1Jjtfepfpj6C81lpTSHKC0WK7N4easmphtlc7q2nOVj6kj7B7N/aE3tGigBY9 UKu7a7gFH2w6y6kLilh7uR4kLK7LHO5RM37OrrlQ4fZP5NPH5lKNwqFRa51u9NTQzfIvE 0Ee80zFSmtulmSrHBbmOxDuFHIT6xOnh1EaDblVU4QcLE0LEIz0b+z6HD6TubKuae7RyW kpvbigsB5jLXVvpVBy16tDJAnqIr568PlB0tqHc4YausNf+BEI6cTENh91iKkMrpgmRJh I5ZNthbwG2/BboC8NXKCP7yeUPxNU0w/CTFPXPLu3lGaTnajj92CdH0YQISbz7akOBGJe HFZYHiYkssNkMNy1dgtL820Op7iPZN6L7TKEsRvJAMHK1JkjpHJTBQPXDs5tkCu8lDq4d hiy+uXyIDJjH/RWrspqWSn4mMWM7nyMPEujZbjLGlqwKrXBiGx83jDOP0/tpuA0= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1791351933; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=rex59e9VM4dDveOiR19eBUpIma2cN/MESd8hU5/XKJ4=; b=V4bjuhFq99hWEKt91JsYE2pGVH9G27rCG1m5avxGpoc8+8XfnzmQL0FO6qDl9rNNTZrF KZtZglwV6EtMV7lFizV0SrSKeCQU0gmUGZymz5ZBTMo7u4JwfW0FrbfzwdkARecS7yTCE z96J/vZ0TUnzD5UIwIntvmR8qU0icWgDX4TCrf5HNBSa7lhKo3nT1hunFfkjh87PhOjpK eYOjkUldk3VBoijbsQV3+S+IlXhew/xbROfa+l1PmDS8mCdh6RXdIChYHxehtPcpWvagk n162llBFPZ2i3709UJhqoMAIDjN1c0yPBtT6AHb5WTfGZU47Oadu3U/PENWUqHQ3QRCsn Muq93gBzPsf4WqvDvzjKfnW9quuvH0bT4CMBIob8ho+v+3ASZyxTHc1glzS4ks4M5DL5D VURa6JLN7KcTRVcinc0cIxSlGME2NfXGoUPsvlK5Y/Ygbn41IuR/idtkESMejGVkE4hGF MTYXrGAJfJkavlFiWoP0O7vjJaTfnITXaVDtY3rVugWk/cdNyQzTamAbojJHmag1hc9py mkek5g/axnwCMiHrirmT1PXHMFTx0udc+gUVitTgm5xVcnWwWFBqZd0qH3Djmc3wXawgT ovESTxF3B13kzcFLoITh5DVP2hkh/ATZEOKnvEnbY0/maG/xrnFios5adkWnOVw= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Wed, 07 Oct 2026 07:45:33 +0200 From: Nicola Vetrini To: Dmytro Prokopchuk1 Cc: Jan Beulich , Doug Goldstein , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] Eclair: scan the last xen-syms linking pass on Arm In-Reply-To: <8d3b26df-a42a-4d34-bc6c-81ed26839006@epam.com> References: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@epam.com> <03338d69-cbde-4918-8ffd-c309230d337f@suse.com> <8d3b26df-a42a-4d34-bc6c-81ed26839006@epam.com> Message-ID: <22ed9e39767c74e820e964acc2e32a32@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-42698a/1791351933-182F49EA-489EDD47/0/0 X-purgate-type: clean X-purgate-size: 2867 On 2026-10-06 18:09, Dmytro Prokopchuk1 wrote: > On 10/6/26 18:03, Jan Beulich wrote: >> On 06.10.2026 16:23, Dmytro Prokopchuk1 wrote: >>> Hiding .xen-syms.[013] assumed the almost-final image is always pass >>> 2. >>> On x86 LAST_LINKING_PASS is 2, so .xen-syms.2 stays visible. On Arm >>> LAST_LINKING_PASS is 3 and the final image is .xen-syms.3, which was >>> hidden. Pass 2 is usually only a symlink, so Eclair saw no program >>> link >>> and reported every translation unit as unreachable. >> >> When I did that work, rule 2.1 ended up clean for both ARM64-* >> analysis >> jobs (iirc). Upon re-checking I now see that ARM64-amd has 177 >> violations >> (apparently that's what you talk about above), but ARM64-allcode has >> none >> (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2916569232). >> >>> Stop hiding pass 3. Passes 0 and 1 remain excluded. >> >> This will cause scanning of both passes 2 and 3, i.e. consume more >> time >> and report duplicate violations when both passes are real linking >> steps. >> I think we want to be smarter than that, to really scan exactly once. >> I >> don't have a good idea just yet how to achieve that, though (and I was >> wondering already when putting together the original patch). >> >> Jan > > Hmm > > At the moment > (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2917375773) I > see ARM64 R2.1 violations: > - 177 in AMD > - 249 in allcode > > Anyway, we can have if-else like this (copied from > automation/eclair_analysis/ECLAIR/tagging.ecl): > > -setq=target,getenv("XEN_TARGET_ARCH") > if(string_equal(target,"x86_64"), > file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[013]$"}), > if(string_equal(target,"arm64"), > file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[012]$"}) > ) > ) > > ^^^ test pipeline is here: > https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2918571749 > > BR, Dmytro. In theory we could even generate a configuration file on the fly just before invoking make. See e.g. [1] and [2]. In this way, we can determine programmatically which is the linking step to consider, since the logic involves some conditionals in the Makefile rules. In any case intercepting one more command that is just a symlink does not incur in a big cost: only if the intercepted step is another linking command ~5 more minutes are needed. [1] https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/eclair_analysis/ECLAIR/generate_ecl.sh?ref_type=heads [2] https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/eclair_analysis/ECLAIR/generate-linker-symbols.sh?ref_type=heads -- 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 Oct 07 07:47:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 07:47:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442000.1659521 (Exim 4.92) (envelope-from ) id 1xEMN8-0000tk-2X; Wed, 07 Oct 2026 07:47:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442000.1659521; Wed, 07 Oct 2026 07: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 1xEMN7-0000td-VX; Wed, 07 Oct 2026 07:47:29 +0000 Received: by outflank-mailman (input) for mailman id 1442000; Wed, 07 Oct 2026 07:47:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEMN6-0000tX-RC for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 07:47:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEMN5-008CkA-FK for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 09:47:27 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac5f90a-8faa-0a2a0a5109dd-0a2a45049c10-14 for ; Wed, 07 Oct 2026 09:47:27 +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 6ac5f90e-b57f-0a2a45040019-d155dd2de960-3 for ; Wed, 07 Oct 2026 09:47:27 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48bbb06e746so1952346f8f.3 for ; Wed, 07 Oct 2026 00:47: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-4a1808d7b52sm17254795e9.2.2026.10.07.00.47.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 00:47: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=1791359246; x=1791964046; 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=g7ljQ8QJLZNNdO100l4fN08FN/ZzE/N+9TqclgR6ffQ=; b=ADrB1f/TUvSGXi/fV9VPc6sSvPU+MR1+7eD23kMnylKHzqU2HRggXAwWIsLul3KLH/ 3TQ2MyssZTVYEfU+++YDwZhb9Q6g8YBq7F9xNd3TkyIvLxB8A5IWIrsQY6NbheSpQkHb ECZ6UHpz6T+obyKuMicwtN94l2qj08qgk3RihBwH+XHbiWQAmKYM3rs9NawSjH2HfL5H 6cOBQje4mFCjwyr8HFJemP9zokOTWSxx8rRhwCr4k/VpmgHfnl5dAiePxhSoOkFKXU06 KaKI+bSVYxWebB5asT9da4cV/JMia2jRfZqPwWLkWhERYC+T6ozfB7fjePMvKFm8bp8Q HmRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791359246; x=1791964046; 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=g7ljQ8QJLZNNdO100l4fN08FN/ZzE/N+9TqclgR6ffQ=; b=rYwKmNu8H7/lF2CXC+ROteQjWnx3grZVW/CZhqKWSl/Cjwcufgd3Y26dI0DCFLjPY/ YCqO+cnPCdU93uqsO1MojB/uBADz/wlsxiyeZ/MHi0U7Z9s3X7pjnPirZe84NyYIsetA w40c8BzZIv58xQin0LRDm2K6giqA0k7PZSzJ/4+ef8azdrwvh4mlBFA7Dtx+n0j3Ygeh m6HoLeKJLsgC4HcMlaJspC7O9SzQ6ft1ImvmaVuOAyxlWZLagZD2fOvXR8r7eiiqI2O0 AKYRNVMmGCmTqxkbhLfHr3AvOVz4k9n8oj6YbWxnLC21oIcPxJ1bHfbHDINzlkfkLR+x YcmQ== X-Forwarded-Encrypted: i=1; AKwUvByjZws6r4B4w4G6kLQ+0/EcASuF0t+Bdh2VXt0YWEz7YEaYySHjzsl7Cghslo8aB4fJrl6/CKza7Y0=@lists.xenproject.org X-Gm-Message-State: AFuF++kebg31aAZQyNcvEvWdp94TrI1FDsPzONW3mLvowSTSICluVBqL 743X4LZMp3W247Y7qia0UnzWE5syX8uNx8wWdNbwFM+CiTU6P8sJYZNETyYwA+GS0Yg6VhEkhpO 5ZPx3yQ== X-Gm-Gg: AYBFou2JqnpfC4wGkIvDxoAXoweHPNlTCvncu89CtDcJ/haF9pVWL/xJJWUOWwh5DU5 ExfbhDnhA9f1gDnH41cIf6H+6VtyDd2MHsV8dKT9QUCcJBfI/GSQ//xzWUCV7AmenVS4t5ugaVG 8TsMtE4heDBN2tnBW8/8YzHXKXyEGLCvsfch0jJ0EQI/LKXLF8tsqJ+dGWEVq11n5z2BaDxCDjR EO4zZFdXygQ6EVGNc1rHKmeOQpOLoHPi9NabDVf65hNY4aLzuLacRp8+LDZdK/7nwh2mbEZKGeL a9t+GBLjxchTq/xF41DtifI8GRMBrEsFWU6oKPnFq0Vel3nQeJDA7JHzlMHMLPslsXKEQBZSRaS 1rRE9HXeI7MyWyHtKFbhyJRnkzHuBdiRnJyvtC5KXL2zpeDJTsAVfN2pmpohOe3wcBZgW3GIPr9 QirwxAa5CldwZDaDTMj8iKR3yn3EJYz30sLlVpr4pInylwyhvDOYRMo9F9kLGfDdex2smy2/VYq 1JJBGteIqhc3sDZEOp/92uzgYtvyoBqAZeSxEcQQ5PXo+X1PZi6AGDXH0QcVQ== X-Received: by 2002:a05:600c:64c6:b0:49f:cbf1:e765 with SMTP id 5b1f17b1804b1-4a18008688cmr17973355e9.0.1791359246584; Wed, 07 Oct 2026 00:47:26 -0700 (PDT) Message-ID: <5f5dca6c-92ff-43d8-8dc3-2ee171bd1ca3@suse.com> Date: Wed, 7 Oct 2026 09:47:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/kexec: Annotate more noreturns To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20261006105445.511099-1-andrew.cooper3@citrix.com> <3bade5ec-e91d-4181-89d9-de35bd42ce62@suse.com> <288b7c58-8375-41a8-9923-a4884830cc40@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: <288b7c58-8375-41a8-9923-a4884830cc40@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791359247-510DDB50-904E4A63/10/78276251493 X-purgate-type: spam X-purgate-size: 2884 On 06.10.2026 21:01, Andrew Cooper wrote: > On 06/10/2026 12:26 pm, Jan Beulich wrote: >> On 06.10.2026 12:54, Andrew Cooper wrote: >>> kexec_reloc() does not return. Plumbing this property upwards lets us mark >>> machine_kexec() and machine_reboot_kexec() noreturn too. >> The latter already is annotated such (see also next remark) as of 4d2ed2f88a0c. > > You missed half of it.  I'm surprised that it didn't create a MISRA > violation. Please clarify what it is that I missed. >>> --- a/xen/arch/x86/machine_kexec.c >>> +++ b/xen/arch/x86/machine_kexec.c >>> @@ -142,15 +142,14 @@ void machine_kexec_unload(struct kexec_image *image) >>> /* no-op. kimage_free() frees all control pages. */ >>> } >>> >>> -void machine_reboot_kexec(struct kexec_image *image) >>> +void noreturn machine_reboot_kexec(struct kexec_image *image) >>> { >>> BUG_ON(smp_processor_id() != 0); >>> smp_send_stop(); >>> machine_kexec(image); >>> - BUG(); >>> } >>> >>> -void machine_kexec(struct kexec_image *image) >>> +void noreturn machine_kexec(struct kexec_image *image) >>> { >>> int i; >>> unsigned long reloc_flags = 0; >> The annotations here aren't needed, are they? I.e. this hunk can shrink >> to just the removal of the BUG() invocation. > > Readers of this code are not psychic.  They shouldn't need to be in > order to follow what's going on. "Psychic"? What are you trying to tell me? There's nothing wrong with repeating this kind of annotation on the definition, but there also is no need for doing so. Hence as far as I can judge, the change I made was self-consistent. If you feel like repeating the annotation is wanted, then that's different from you (half implicitly, half explicitly) claiming it's _needed_. >>> --- a/xen/include/xen/kexec.h >>> +++ b/xen/include/xen/kexec.h >>> @@ -49,7 +49,7 @@ int machine_kexec_load(struct kexec_image *image); >>> void machine_kexec_unload(struct kexec_image *image); >>> void machine_kexec_reserved(xen_kexec_reserve_t *reservation); >>> void noreturn machine_reboot_kexec(struct kexec_image *image); >>> -void machine_kexec(struct kexec_image *image); >>> +void noreturn machine_kexec(struct kexec_image *image); >> The annotations on the declarations are sufficient, with another Misra >> rule making sure we don't omit the inclusion of the header in the CU >> having the definitions. >> >> Preferably with the redundant annotations omitted, and with the description >> slightly adjusted: >> Reviewed-by: Jan Beulich > > I am not inclined to make changes. Well, so be it then. Yet it again indicates that in certain situations you're simply not willing to accept that there may be (valid) viewpoints other than yours. Or, if you think those aren't valid, make clear what's objectively wrong. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 07 08:04:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 08:04:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442016.1659529 (Exim 4.92) (envelope-from ) id 1xEMdO-0004WK-O9; Wed, 07 Oct 2026 08:04:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442016.1659529; Wed, 07 Oct 2026 08: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 1xEMdO-0004WD-LU; Wed, 07 Oct 2026 08:04:18 +0000 Received: by outflank-mailman (input) for mailman id 1442016; Wed, 07 Oct 2026 08:04:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEMdN-0004W6-JT for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 08:04:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEMdN-00BgAJ-0E for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:04:17 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac5fcf1-2eae-0a2a0a5409dd-0a2a4505e886-48 for ; Wed, 07 Oct 2026 10:04:16 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac5fd00-4cb1-0a2a45050019-d1558029d44d-3 for ; Wed, 07 Oct 2026 10:04:16 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a02667ccebso12321325e9.0 for ; Wed, 07 Oct 2026 01:04: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-4a17f4480a4sm37883315e9.0.2026.10.07.01.04.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 01:04: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=1791360256; x=1791965056; 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=UFvLNkFrmQ9GmESvDDrjahsnp3/aj+8+4G1fgvZAmw4=; b=FQUN30/nev7yU0hynJjgvyvq3OOf8VWnDYMs8AtEbqqourIm+5qjDksG8HdS0JyavA qmPtFd0JAgz2YMPBMpA6l0GVZBwrw1BToekg/lCmA9vpmGUWGsiIHzdCp39f778URf6f eiI62Kz9Ep8nV+2LlFYIFtA0Y3QRXRb03Di909ICfhJGn4bdzaTiwNIQtUQseVJMiUBi 3Yt4GctuE3VoQObiTy8eQw8OfggZ/JVDW/JhhkUF4kFldV+sPb8/9HJO9mp1Gvy5w3ll dQ4U6p4yQdTmn9nzKcmd3eUIGD+k5eFPzFOiuFKKxPnu+NfyK7BiMP+Wvc8B8DDzlb0J AuEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791360256; x=1791965056; 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=UFvLNkFrmQ9GmESvDDrjahsnp3/aj+8+4G1fgvZAmw4=; b=kRnXbwdT8co/LvWlMlszTumwhVGkBNyCK9DwMF97gGfTayi9GEA/gadbbyr/LkOc8A kxQ7d4LqixfIn+obzXGyZ3K6kPeHFYBJzLSpzzxFmx4yvDo762/ni79lvFfS1XcQP+fa Waox0NEYfOms2Y9Mvd2fTuSg9UnKIrVwNTMkf3Tw0EfGSEURjVtrJIedoKOnzI7F6dYH eZTOR8gb4zIeYPBoloZZi0TjJi3BuBTAAfj3ulnrB81dZFfiySL6iNwsGWbuken9eNRW P1UjaGFJ4E5uc235CpGE+2M7PCNQtWZj1/83fxMaGIZDvh5z+7DT4ftK9lGxqXDmhv8g uZCw== X-Gm-Message-State: AFuF++m18bUv1xApQjS0tM4VIkJDTsgb4vTUmaOfpdPSOlNTDMUBAX9a dXnetRXaWXZEY3WO/22f4YUj7v/4KPrYRKeKf9q+sK5KXSKw2Qos1Te/jZ5SrG5qyQ== X-Gm-Gg: AYBFou1/UYy5v5ScJWOgytkNROLeFin5Ub/81iq+w3W5as5L+huZWSpeMo3gu9i818s i0yZcYNuj5iat7SQ4Mt9U0sUYSXKPslniV7GhfMemInI/w4Pt9D4wMZo+jFDf+xhWh6MKmzkQsx ftSog9bwBZvEDaUmX9uOeR7NMmx6vKbZtwkrZSauXHHyXENJhuhqG3x6wDfS9DcCZ06OjYxDdJA zxrDyAsW/5CV4JSldy3SP5yAI+nQP9VoQITRIAWdeYMPkQczeH5Lp+p2aUUxaX4/nY2/xkDS0gj LpYgbT34m5PIEA990JiVQUpj9i4C9THC1Q0X/47mU1p2FlrdrXyMtFm8yldR0+UkROESV/vXhAz 7hUXZod42YPlRoUpxv0a2mpQMkeiH5C6iXyktXoUt5ZewxW58gd7t1IjMUNyR0+QnDrX/+N6JPH YDB+zVuyD8SZ5fiohdkcwS85qhryaChRuHu5tmAjV4ySEr6+4uWA7HH/wjkJy4/WpSXSTl6s9Qn fuF4xRH3sN/3J/aE5NUYAkT21Fa7+UFI5Vb1A/bFmCpT1Lab2f7EADA8kc4b4W3H8UYcFT8pg== X-Received: by 2002:a05:600c:4ecb:b0:49f:ff7b:f056 with SMTP id 5b1f17b1804b1-4a180409410mr18598795e9.9.1791360254656; Wed, 07 Oct 2026 01:04:14 -0700 (PDT) Message-ID: <2d5f2558-e4f7-43d5-888c-36727519270d@suse.com> Date: Wed, 7 Oct 2026 10:04:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 11/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: <6e539cc5ded7f62c4347781785af714840893184.1790779209.git.oleksii.kurochko@gmail.com> <1791305420.8631fc262581453bbf619ec5b2062170.1a1121f8fef0003f66@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: <1791305420.8631fc262581453bbf619ec5b2062170.1a1121f8fef0003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791360256-F64B42A1-52A83C43/10/78276251493 X-purgate-type: spam X-purgate-size: 13836 On 06.10.2026 18:50, Baptiste Le Duc wrote: >> Implement context_switch() and the helpers it needs: save/restore of >> 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. The virtual interrupt controller state isn't >> switched here. >> >> Add offsets of struct arch_vcpu's xen_saved_context to asm-offsets.c for >> use by __context_switch(). >> >> henvcfg, htimedelta and vsie are 64-bit on both RV32 and RV64, so store >> them as uint64_t and access them with csr_{read,write}64(). For that >> purpose introduce csr_read64(). >> >> The VMID has to be claimed on the context switch rather than on guest >> entry: once p2m_ctxt_switch_to() writes HGATP, speculation can populate >> G-stage entries under whatever VMID is written there. This is done by >> p2m_vmid_switch_to(), called right before the HGATP write: >> >> - VMIDs are a per-hart resource, so the (generation, vmid) pair of a >> vCPU which last ran on another hart is invalidated before a VMID is >> claimed for it. The local flush for a wrapped generation moves along >> with the claim. >> - Nothing is switched in for the idle vCPU, so HGATP keeps pointing at >> the p2m of the domain which ran on the hart last. Track that domain >> per hart (hgatp_owner) and keep the hart in its dirty_cpumask until a >> vCPU of another domain is switched in: p2m_tlb_flush() then goes on >> reaching the hart, and a domain which idles between two runs on the >> same hart keeps its VMIDs. >> - When the owner changes, the hart leaves the old owner's dirty_cpumask >> while its TLB may still hold that domain's G-stage translations, so it >> is moved to a new VMID generation, which makes none of them reachable >> again. It joins the new owner's dirty_cpumask before HGATP is written; >> a full barrier there, paired with one in p2m_tlb_flush(), guarantees >> that a concurrent P2M change either reaches the hart with an >> HFENCE.GVMA or is visible to it before it walks the p2m. >> >> That leaves p2m_handle_vmenter() with nothing to do, so drop it together >> with its call from check_for_pcpu_work(): a VMID is only ever invalidated >> while its vCPU isn't running, and p2m_tlb_flush() drops stale entries >> with a remote HFENCE.GVMA rather than by retiring VMIDs. Unlike >> p2m_handle_vmenter(), HGATP is written unconditionally, as it holds the >> G-stage root too, which on a context switch belongs to another domain. >> >> While at it, fix the inclusion order of headers in asm-offsets.c: Xen's >> headers go first, then arch specific ones. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v3: >> - Update the commit message. >> - Introduce csr_read64(), as vsie is 64-bit on RV32 too, i.e. has to be >> accessed as the vsie/vsieh pair there. >> - Make vsie declared as uint64_t instead of register_t. >> - Rename the parameter of save_csr_regs() to p and of restore_csr_regs() >> to n, to match their callers ctxt_switch_from()/ctxt_switch_to() and the >> rest of the context switch helpers (p2m_ctxt_switch_{from,to}(), >> vtimer_ctxt_switch_{from,to}()). >> - s/save_csr_regs/csr_regs_ctxt_switch_from/ >> - s/restore_csr_regs/csr_regs_ctxt_switch_to/ >> - Drop the forward declaration of struct vcpu in : the >> return type of __context_switch() already declares the tag at file >> scope. >> - Make the next parameter of __context_switch() pointer-to-const, as >> next's saved context is only read. >> - Extend the comment above __context_switch(): as ra is switched too, it >> doesn't return to its caller, but to where next last called it from >> (next's own context_switch(), or continue_new_vcpu() for a vCPU which >> has never run). >> - Call vtimer_ctxt_switch_to() after csr_regs_ctxt_switch_to(), so that >> ctxt_switch_to() restores state in the reverse order of >> ctxt_switch_from() saving it. >> - Rework p2m's VMID handling in the context switch: track the domain >> whose p2m HGATP points at in a per-CPU hgatp_owner, so a pass through >> idle no longer drops the hart from that domain's dirty_cpumask nor >> burns a VMID generation; move the dirty_cpumask update and the >> invalidation of a VMID brought from another hart from schedule_tail() >> and ctxt_switch_to() to p2m_ctxt_switch_to(), next to the VMID claim; >> add the barriers ordering the dirty_cpumask update against >> p2m_tlb_flush(). >> - Initialise arch_vcpu.last_cpu to CPU_NONE instead of NR_CPUS. >> - Mark prev's dirty_cpu clean before ctxt_switch_to() and set current's >> after it. >> --- >> Changes in v2: >> - New patch. >> --- >> --- >> xen/arch/riscv/domain.c | 127 ++++++++++++++++++++++ >> xen/arch/riscv/entry.S | 48 ++++++++ >> xen/arch/riscv/include/asm/csr.h | 13 +++ >> xen/arch/riscv/include/asm/domain.h | 15 ++- >> xen/arch/riscv/include/asm/p2m.h | 1 - >> xen/arch/riscv/include/asm/system.h | 2 + >> xen/arch/riscv/p2m.c | 157 ++++++++++++++++++--------- >> xen/arch/riscv/riscv64/asm-offsets.c | 19 +++- >> xen/arch/riscv/stubs.c | 5 - >> xen/arch/riscv/traps.c | 2 - >> 10 files changed, 330 insertions(+), 59 deletions(-) >> >> diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c >> index fd62296356..f80643e2d8 100644 >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -11,6 +11,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -152,6 +153,8 @@ int arch_vcpu_create(struct vcpu *v) >> if ( is_idle_vcpu(v) ) >> return 0; >> >> + v->arch.last_cpu = CPU_NONE; >> + >> vcpu_csr_init(v); >> >> if ( (rc = vcpu_vtimer_init(v)) ) >> @@ -323,6 +326,130 @@ int arch_domain_create(struct domain *d, >> return rc; >> } >> >> +static void csr_regs_ctxt_switch_from(struct vcpu *p) >> +{ >> + /* >> + * There is no need to save these CSRs as only hypervisor writes them in >> + * csr_regs_ctxt_switch_to() 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. >> + * >> + * p->arch.hedeleg = csr_read(CSR_HEDELEG); >> + * p->arch.hideleg = csr_read(CSR_HIDELEG); >> + * p->arch.henvcfg = csr_read64(CSR_HENVCFG); >> + * p->arch.hcounteren = csr_read(CSR_HCOUNTEREN); >> + * p->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); >> + * >> + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + * p->arch.hstateen0 = csr_read(CSR_HSTATEEN0); >> + */ >> + >> + p->arch.hvip = csr_read(CSR_HVIP); >> + >> + p->arch.vsstatus = csr_read(CSR_VSSTATUS); >> + p->arch.vsie = csr_read64(CSR_VSIE); >> + p->arch.vstvec = csr_read(CSR_VSTVEC); >> + p->arch.vsscratch = csr_read(CSR_VSSCRATCH); >> + p->arch.vscause = csr_read(CSR_VSCAUSE); >> + p->arch.vstval = csr_read(CSR_VSTVAL); >> + p->arch.vsepc = csr_read(CSR_VSEPC); >> +} >> + >> +static void csr_regs_ctxt_switch_to(struct vcpu *n) >> +{ >> + csr_write(CSR_HEDELEG, n->arch.hedeleg); >> + csr_write(CSR_HIDELEG, n->arch.hideleg); >> + csr_write(CSR_HVIP, n->arch.hvip); >> + csr_write64(CSR_HENVCFG, n->arch.henvcfg); >> + csr_write(CSR_HCOUNTEREN, n->arch.hcounteren); >> + csr_write64(CSR_HTIMEDELTA, n->arch.htimedelta); >> + >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + csr_write(CSR_HSTATEEN0, n->arch.hstateen0); >> + >> + csr_write(CSR_VSSTATUS, n->arch.vsstatus); >> + csr_write64(CSR_VSIE, n->arch.vsie); >> + csr_write(CSR_VSTVEC, n->arch.vstvec); >> + csr_write(CSR_VSSCRATCH, n->arch.vsscratch); >> + csr_write(CSR_VSCAUSE, n->arch.vscause); >> + csr_write(CSR_VSTVAL, n->arch.vstval); >> + csr_write(CSR_VSEPC, n->arch.vsepc); >> +} >> + >> +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); >> + >> + csr_regs_ctxt_switch_from(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; >> + >> + csr_regs_ctxt_switch_to(n); >> + >> + vtimer_ctxt_switch_to(n); >> + >> + p2m_ctxt_switch_to(n); >> +} >> + >> +static void schedule_tail(struct vcpu *prev) >> +{ >> + unsigned int cpu = smp_processor_id(); >> + >> + ASSERT(prev != current); >> + >> + ctxt_switch_from(prev); >> + >> + write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN); >> + >> + ctxt_switch_to(current); >> + >> + write_atomic(¤t->dirty_cpu, cpu); >> + >> + 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); >> +} >> + >> static void __init __maybe_unused build_assertions(void) >> { >> /* >> diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S >> index 202a35fb03..017fbb0626 100644 >> --- a/xen/arch/riscv/entry.S >> +++ b/xen/arch/riscv/entry.S >> @@ -99,3 +99,51 @@ restore_registers: >> >> sret >> END(handle_trap) >> + >> +/* >> + * struct vcpu *__context_switch(struct vcpu *prev, const struct vcpu *next) >> + * >> + * 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) First: None of the reply context above is relevant in your reply. Why did you keep it? As indicated before, this way you make every reader scroll through many lines, until they would finally find the first piece of the actual reply. (I've deliberately kept it all, to show the percentage of the overall reply that this occupied.) >> --- a/xen/arch/riscv/include/asm/csr.h >> +++ b/xen/arch/riscv/include/asm/csr.h >> @@ -40,6 +40,13 @@ >> csr_write(csr ## H, v_ >> 32); \ >> }) >> >> +#define csr_read64(csr) \ >> +({ \ >> + uint64_t v_ = csr_read(csr ## H); \ > This violates Misra 20.12 rule (docs/misra/rules.rst) as we use macro > parameter `csr` as an operand of ##, while it could be expanded as a > macro (e.g. csr_read64(CSR_HENVCFG)). Yes. But: You say nothing as to a possible (and plausible) different way of coding this. Imo the best way to deal with this is by a deviation (iirc we already have a few), yet I don't think we're going to add deviations for RISC-V until we actually are about to routinely scan the code. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 07 08:21:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 08:21:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442025.1659539 (Exim 4.92) (envelope-from ) id 1xEMu5-0007QQ-66; Wed, 07 Oct 2026 08:21:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442025.1659539; Wed, 07 Oct 2026 08: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 1xEMu5-0007QJ-3K; Wed, 07 Oct 2026 08:21:33 +0000 Received: by outflank-mailman (input) for mailman id 1442025; Wed, 07 Oct 2026 08:21:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEMu3-0007QD-5o for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 08:21:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEMu1-00GvLM-Oc for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:21:29 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac600fc-e002-0a2a0a5209dd-0a2a4505c4b0-34 for ; Wed, 07 Oct 2026 10:21:29 +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 6ac60108-4cb1-0a2a45050019-b9ff1c128a35-3 for ; Wed, 07 Oct 2026 10:21: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a11573f8520003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 08:21:24 +0000 Received: from [192.168.1.17] (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 7D059823E5 for ; Wed, 7 Oct 2026 10:21:23 +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: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=4pLwyzQQFJGhtYUNy17q8KGyMjzeB42hdIs0/iMhWPM=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=RTjJPE+9aTEzdtuK5d5oY/UMd3+LbB2O2rAHdaylBFtiLLJZZDQDhF5PoRCOCEQvDXop4ysB5 /NoafheKI6Q5PZN7MePdNnsVyJTCCvQBMKNqAPaPqIf+0fEjkcKZmwRb6AMJsrH8Xq7VDivfzFU GqH96oAkfiPudAcbl7d1i958tFcXmZgnupt2ojFSBRugms2i3OeFAIvZPB9agryi/JrpXlPfOX7 ENeYda/wdfOBxiIRRCmVZvKkUG1Ro9TZVCh+N+b9p5CYPDkBZtfgULVHXsqveHemOyjxZMTpCeI 4Gn37OL7Cq2zaRUAMM/HVOJ2QYRYJLbnGqgnSOI5FwhQ== X-Zone-Loop: fdcbe07ba325e44e47c8a3d60219734b7c28015dbdc2 x-campaign-type: default x-transaction-id: 377ae544-48bf-4437-8a6a-02b8e5b05ef4 x-swg-uid: 01-38b5aa80-e042-423f-ad45-41a057740fe5 X-Mailer: Sweego Message-ID: <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@vates.tech> x-swg-bid: 1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 7 Oct 2026 10:21:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: xen-devel@lists.xenproject.org References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66@vates.tech> Content-Language: en-US From: Baptiste Le Duc In-Reply-To: <1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791361283560 X-purgate-ID: tlsNG-c201ff/1791361289-F54AC2A1-133829DC/0/0 X-purgate-type: clean X-purgate-size: 8317 On 10/7/26 00:50, Teddy Astie wrote: > Le 05/10/2026 à 18:02, Baptiste Le Duc a écrit : >> A RISC-V implementation can manage the PTE A/D bits in one of two ways: >>      1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). >>      2) Generate a page fault when 'A' and/or 'D' is clear, so that >> software >>         can set them (ratified as Svade). >> >> p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device >> tree >> advertises Svade. Platforms that use scheme (2) without advertising >> Svade, >> such as the HiFive Premier P550, then hit guest-page faults that Xen >> does >> not handle. > > I second what Jan said (this is likely a firmware bug, given that the > enumerated behavior is not consistent with the specification, as > existence of Svadu/Svade alters observable behavior). > Thanks, agreed on both points. I'll reword the commit message: it shouldn't imply that Svade in the DT means faults will occur, since with Svadu also present that depends on henvcfg.ADUE. On the firmware-bug point: I don't think the P550 is really inconsistent with the spec. Svade and Svadu didn't exist when the P550 core was designed. They were only ratified later, to name the two behaviors that already existed in the wild. Before that, the privileged spec just allowed either: hardware updating A/D, or raising a page fault. The P550 implements the second, and there was no extension it could advertise for it. Therefore, the DT lacks svade because the extension didn't exist when the platform description was written, not because the vendor misdescribed anything. I agree that, where Svadu is available, Xen should ideally configure a consistent scheme (ADUE=1) and use ADUE=0 only for specific needs such as dirty tracking. But Xen doesn't support Svadu today, so that is a separate piece of work which I'd prefer to do later. In the meantime, presetting A/D in the G-stage PTEs is the only way to avoid the faults on hardware like the P550, and it is harmless on hardware that updates A/D itself. For v6 I'll keep the unconditional preset and reword the commit message to say this, what do you think? >> >> Always preset A/D in G-stage PTEs so scheme (2) never faults. This is >> harmless with (1): software just does what hardware would have done on >> first access. >> >> Drop the TODO suggesting to handle A/D faults: only Svade raises >> them, so >> it would not work on Svadu. Dirty/access tracking can restrict the RWX >> permissions of p2m entries, as x86 and Arm do. > Yet, existence of Svade alone doesn't mandate the actual behavior, it > is also dependant on the value of ADUE bit in configuration registers. > > Ideally (in cases we can) we would want to configure hardware to > follow a consistent scheme (with the one that updates A/D with > hardware i.e ADUE=1, as it's consistent to without Svade) and only > consider the ADUE=0 behavior for specific needs like dirty tracking. > >> > 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 v4: >> - restore svade and update the commit message accordingly. >> - rebase on top of staging. >> --- >> Changes since v3: >> - always preset A/D bits in G-stage mappings instead of keying off >> the DT: >>    it may not reflect what the hardware actually does. >> - change commit title/message. >> - drop svade as it is now-unused. >> --- >> Changes since v2: >> - change commit title. >> - preset A/D bits in p2m_set_pte_flags() if (!svadu || svade), >> instead of >> setting RISCV_ISA_EXT_svade in the riscv_isa bitmap for cases 1, 2 >> and 4. >> - riscv_resolve_ad_scheme() now only warns when both Svade and Svadu are >> present and SBI FWFT is missing; drop the dead 'svadu && svade' operand. >> - repeat XENLOG_WARNING on each line of the warning. >> - drop ASSERT(svade != svadu) from p2m_set_pte_flags(). >> - only add the sbi_probe_extension() declaration to sbi.h. >> - rework the comment in p2m_set_pte_flags(). >> --- >> 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/p2m.c | 38 ++++++++------------------------------ >>   1 file changed, 8 insertions(+), 30 deletions(-) >> >> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c >> index f7b380b90a..14cae7dcd7 100644 >> --- a/xen/arch/riscv/p2m.c >> +++ b/xen/arch/riscv/p2m.c >> @@ -591,38 +591,16 @@ static void p2m_set_pte_flags(pte_t *e, >> p2m_type_t t) >>       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. >> +     * A RISC-V implementation can either: >> +     * 1) Update the 'A' and 'D' PTE bits in hardware. >> +     * 2) Generate a page fault when 'A' and/or 'D' is clear, so that >> +     *    software can set them. > > > >>        * >> -     * 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. >> -     * >> -     *       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. >> +     * Xen supports both, so set 'A' and 'D' up front to avoid the >> faults >> +     * of (2). This is harmless with (1): software just does what >> hardware >> +     * would have done on first access. >>        */ >> -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) >> -        e->pte |= PTE_ACCESSED | PTE_DIRTY; >> +    e->pte |= PTE_ACCESSED | PTE_DIRTY; > > On the code change itself, it looks good to me, as we don't make use > of A/D bit anyway (and in case we would need to, we would need to > clear them anyway). > >>         switch ( t ) >>       { >> > From xen-devel-bounces@lists.xenproject.org Wed Oct 07 08:28:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 08:28:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442031.1659547 (Exim 4.92) (envelope-from ) id 1xEN0u-00083m-RZ; Wed, 07 Oct 2026 08:28:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442031.1659547; Wed, 07 Oct 2026 08:28: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 1xEN0u-00083f-Ou; Wed, 07 Oct 2026 08:28:36 +0000 Received: by outflank-mailman (input) for mailman id 1442031; Wed, 07 Oct 2026 08:28:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEN0t-00083Z-42 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 08:28:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEN0r-00Bm35-Ko for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:28:33 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac602aa-bab6-0a2a0a5309dd-0a2a45079c82-14 for ; Wed, 07 Oct 2026 10:28:33 +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 6ac602b0-b4ea-0a2a45070019-b9ff1c23a1ed-3 for ; Wed, 07 Oct 2026 10:28: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 1a1157a77720003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 08:28:29 +0000 Received: from [192.168.1.17] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 33F2381F2B; Wed, 7 Oct 2026 10:28:29 +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=qIkZ+a1KoGAxP/lnvgZm+8EOQN8dXV21ZS1R8VY/MMg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=tvnik4BPKuPau6L36RKpzJK9kP6rhRgBzYug97xUD4r9HlVDh5JVfYkRRmlxOmJr5rPZWGSHg nxdzBlte7BcQ56RLEhnq78mYweWb4mMJ9SjKtbryAW8NUW4LT9ylyhAFB7CVQdJDFpi0TpJWwny 5UVh2r+gdl8G6NteCsctFHOvDq2k8ahYEdggRKu4NAkqDyyFElcP8DPHgcBdAZk1rg8h6GQ/GeR MnWhl/5XJsws2IjxOfNVkric6DTsQWhROtzu8GfbpvjKbe5ptUpOWSWpG7Ms1T41gq2o+nNpaLa dyzizWRTS2eC0AMhBjBSOxsIFWkHC0awJ8OKo1OOQudg== X-Zone-Loop: 54648ba53d8986a92f9f41d56634693e085a46c26df9 x-campaign-type: default x-transaction-id: 8cb1486e-4714-434b-a759-a1a819c474f4 x-swg-uid: 01-2100764c-f83a-4b4c-b3ac-9e693dc3d7c9 X-Mailer: Sweego Message-ID: <1791361710.8631fc262581453bbf619ec5b2062170.1a1157a77720003f66@vates.tech> x-swg-bid: 1791361710.8631fc262581453bbf619ec5b2062170.1a1157a77720003f66 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 v3 11/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: <2d5f2558-e4f7-43d5-888c-36727519270d@suse.com> References: <6e539cc5ded7f62c4347781785af714840893184.1790779209.git.oleksii.kurochko@gmail.com> <1791305420.8631fc262581453bbf619ec5b2062170.1a1121f8fef0003f66@vates.tech> <2d5f2558-e4f7-43d5-888c-36727519270d@suse.com> Date: Wed, 07 Oct 2026 10:27:30 +0200 X-Developer-Signature: v=1; a=openssh-sha256; t=1791361709; l=1374; i=baptiste.le-duc@vates.tech; h=from:subject:message-id; bh=B7EBBZ55K7PX7Zp//Piz5dkiUp8tYHWwTqgPL6BclH8=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgQKqDblDzOFimZyyhA+RsKnxim2EiA 60KatQBsuueKYUAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QDnXNO6Q3pqnoNYfCUZRKU4+n2YAmAi5APU5ZrSZGq1Id+WZ0ifGg6KN/HzYYXAE0Jvrk5RaLRv jFZXMxbFDWAw= X-Developer-Key: i=baptiste.le-duc@vates.tech; a=openssh; fpr=SHA256:YieMhmvNcCYpeUbL6HuedGp4rwSlu4mQ+D7EJoVHM+k X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791361709459 X-purgate-ID: tlsNG-ef75cf/1791361713-366DAAE4-F99999EB/0/0 X-purgate-type: clean X-purgate-size: 1378 On 2026-10-07 10:04:12+02:00, Jan Beulich wrote: > On 06.10.2026 18:50, Baptiste Le Duc wrote: > > >> Implement context_switch() and the helpers it needs: save/restore of > > First: None of the reply context above is relevant in your reply. Why > did you keep it? As indicated before, this way you make every reader > scroll through many lines, until they would finally find the first > piece of the actual reply. (I've deliberately kept it all, to show > the percentage of the overall reply that this occupied.) > Yes sorry, I thought b4 would have trimmed for me. I would be careful about that in next replies. > >> --- a/xen/arch/riscv/include/asm/csr.h > > This violates Misra 20.12 rule (docs/misra/rules.rst) as we use macro > > parameter `csr` as an operand of ##, while it could be expanded as a > > macro (e.g. csr_read64(CSR_HENVCFG)). > > Yes. But: You say nothing as to a possible (and plausible) different > way of coding this. Imo the best way to deal with this is by a > deviation (iirc we already have a few), yet I don't think we're going > to add deviations for RISC-V until we actually are about to routinely > scan the code. I didn't propose anything because I didn't have any other way to code this. Concerning the fact to not add deviation for RISC-V I agree that it doesn't make too much sense for the moment. > > Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 07 08:31:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 08:31:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442035.1659557 (Exim 4.92) (envelope-from ) id 1xEN3I-00015v-7O; Wed, 07 Oct 2026 08:31:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442035.1659557; Wed, 07 Oct 2026 08:31: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 1xEN3I-00015o-4i; Wed, 07 Oct 2026 08:31:04 +0000 Received: by outflank-mailman (input) for mailman id 1442035; Wed, 07 Oct 2026 08:31:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEN3G-00015i-Ch for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 08:31:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEN3F-00GwzR-Ph for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:31:01 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac60342-8faa-0a2a0a5109dd-0a2a4503ba6c-8 for ; Wed, 07 Oct 2026 10:31:01 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac60345-fae8-0a2a45030019-d155802bb123-3 for ; Wed, 07 Oct 2026 10:31:01 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a061a13884so13212575e9.3 for ; Wed, 07 Oct 2026 01:31: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-4a178c40a28sm145557345e9.7.2026.10.07.01.31.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 01:31: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: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=1791361861; x=1791966661; 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=59vxMKFygRRXTpGVaBbehooknbFJQ4iCaF/7vJel9ak=; b=sVIgzFl1dwxHQMh/8kOfOpYvPFhcu83hDv+JwjXSSmUvd9V0NOYBFW498MnT5tlGDj J0EkfzvceFtUwPuedxgVd90ik2pp4c924EOSg079H6lGBGKwQgRmq5kl8XjzrkqnT8RR lA4F8W9HgZxANNy33acwUxO7NVFX6rjrShTGM2gQY3QthL4ubuUqPGrkom2L9lYFYWmp ndBMhFBoP79OJD86nS+fnuwYqvleaLn/pjaZM8zq+iW/GKVQWR1RD0+te17H15cOJMBu DiC2uOXe7Aa8/9Jh+56fKU8ghpaMJujuCLzNg1IQ7bw4XyQaAAqfT2ysUUCUfEfljNyf yW2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791361861; x=1791966661; 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=59vxMKFygRRXTpGVaBbehooknbFJQ4iCaF/7vJel9ak=; b=U3C+wCLbWufz70DBBVFKTQ54G6GvD0AnHZPbSf1pYuWVZk0IHXfn1G7+uvQ1xHsOx6 H7hAKoGFp3nLtqchATaeD9aUmHpMrOvaLVTuzlOIl1Q9BxoBDX8asNEApZA9Z1LPySa0 t4SKY7vdSwMxbNP6in3anVqQ6rb3rCWOLnAUXlOT/4xFOujxF1RRh+ZE8aGaHAVIpZ90 4Lbi8In7EDmdutpRabBFgsj8KzFvC8np9mRryfYSSIJ/zi9+2Md+HoKb6klJO+jAIoeH SqCZqf3rWn0cfLA+M+VJYAYCjnUWL6FksrE5qLQm/ILeUnI4jtvMqgK1bU/MVuL8lkCm F9Fw== X-Forwarded-Encrypted: i=1; AKwUvBxlNwzBVMUn25r00YH4t9UbwzNV59EfjSA7gxKrA0fgfF2/IvGrW26ksjbRb5xToJhBAKUuLdF0giM=@lists.xenproject.org X-Gm-Message-State: AFuF++mR2jadBOizzOej7I8V716sNrcdViketctxlMC8ZapHU15O0bc8 HAl4s4yRP6WAzTiNr4RJ2pcIXrtWn2iWEsBcHXuIR79WfvQdQnBBSSlS X-Gm-Gg: AYBFou0nA2OEBmXHkoOxm+mIof77TgJ5HWukLSfADZNwswqhPEinoycXCngm2mEAY4e 7syNyFEkpk9z+mIdPK4c1LwxaGxUQB4SkjUspM/XxUDi9zgYSCzYU9CFVXclTlzgSRPqV5BYaLj FBAYWfKukqe7uKskh7sWLF7KxAg36ipWK3G1ol4/fw+t90jp1MbyrRwmAclOVIzH8n6kAfOjeJj yp0Hfpd4IpviBPKf6gF96og9GRK5PMz6yRDFcWLSzEcLUKoM6E0RPqORfDEL5SdnYvL4UT0KG3S 3y9z8P8Mjt0sHkq9imWOPz+k34phL/FJZVPsrcO1+NSEYlX8+acDNCd3K6fR7YmTUIgsEs+s56c kEsw/H+b5uuw9WdxBqDasGVpcntFcm9UR+i8ZkeLeNpV891b690k8pYvaoe7yNgDXpRzH8Jv8ks TeeIckwduiwlSuz29ERpb99JwZpHer5FjwOsXJAVgIQM+oGg1RjOiCRIgHuRt59/WbIa2OwajVl qeALin22bWNjRuMlk0+TMhi2OskWOSNDjiuEdLvUpAuwm5F6ycaGOyuLgfz X-Received: by 2002:a05:600c:3f08:b0:4a1:7703:e537 with SMTP id 5b1f17b1804b1-4a180313b66mr18708995e9.10.1791361860894; Wed, 07 Oct 2026 01:31:00 -0700 (PDT) Message-ID: <3204203d-83eb-4afe-a99b-5baf1e19777d@gmail.com> Date: Wed, 7 Oct 2026 10:30:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66@vates.tech> <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1791361861-6F2C84E9-5A6BAFC3/10/73395122804 X-purgate-type: spam X-purgate-size: 2546 On 10/7/26 10:21 AM, Baptiste Le Duc wrote: > On 10/7/26 00:50, Teddy Astie wrote: >> Le 05/10/2026 à 18:02, Baptiste Le Duc a écrit : >>> A RISC-V implementation can manage the PTE A/D bits in one of two ways: >>>      1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). >>>      2) Generate a page fault when 'A' and/or 'D' is clear, so that >>> software >>>         can set them (ratified as Svade). >>> >>> p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device >>> tree >>> advertises Svade. Platforms that use scheme (2) without advertising >>> Svade, >>> such as the HiFive Premier P550, then hit guest-page faults that Xen >>> does >>> not handle. >> >> I second what Jan said (this is likely a firmware bug, given that the >> enumerated behavior is not consistent with the specification, as >> existence of Svadu/Svade alters observable behavior). >> > Thanks, agreed on both points. > > I'll reword the commit message: it shouldn't imply that Svade in the DT > means faults will occur, since with Svadu also present that depends on > henvcfg.ADUE. > > On the firmware-bug point: I don't think the P550 is really inconsistent > with the spec. Svade and Svadu didn't exist when the P550 core was > designed. They were only ratified later, to name the two behaviors that > already existed in the wild. Before that, the privileged spec just > allowed either: hardware updating A/D, or raising a page fault. The P550 > implements the second, and there was no extension it could advertise for > it. > Therefore, the DT lacks svade because the extension didn't exist when > the platform description was written, not because the vendor > misdescribed anything. > > I agree that, where Svadu is available, Xen should ideally configure a > consistent scheme (ADUE=1) and use ADUE=0 only for specific needs such > as dirty tracking. But Xen doesn't support Svadu today, so that is a > separate piece of work which I'd prefer to do later. It would be nice to have such option to configure ADUE bit but IIRC it could be configured only in M-mode (so OpenSBI and OpenSBI really set ADUE to 1 when Svadu is available) so we will need some kind of new SBI call to do that as we are working in HS-mode and can't change ADUE bit. So IMO we don't really need that for now until we really will start to use A/D bits for Xen purpose. For me, at the moment, it is more then enough just to have them always set. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 07 08:31:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 08:31:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442037.1659567 (Exim 4.92) (envelope-from ) id 1xEN3Q-0001LE-F9; Wed, 07 Oct 2026 08:31:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442037.1659567; Wed, 07 Oct 2026 08:31: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 1xEN3Q-0001L7-Ba; Wed, 07 Oct 2026 08:31:12 +0000 Received: by outflank-mailman (input) for mailman id 1442037; Wed, 07 Oct 2026 08:31:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEN3P-0001KH-5C for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 08:31:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEN3O-00Gx2g-G8 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:31:10 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6034d-8faa-0a2a0a5109dd-0a2a450aebd2-8 for ; Wed, 07 Oct 2026 10:31:10 +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 6ac6034e-f2d2-0a2a450a0019-d155802ded58-3 for ; Wed, 07 Oct 2026 10:31:10 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so36058385e9.1 for ; Wed, 07 Oct 2026 01: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 5b1f17b1804b1-4a17a0fc2e4sm130900585e9.3.2026.10.07.01.31.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 01:31: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=1791361870; x=1791966670; 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=xwFdaNiudN2iiylPMoo56VdyeBK0OseTg6BPlmrhMsg=; b=Q9PeOPaTZVLR5XJzKhY603vX1DeqPZC0LOlQN1XQCV73PDDZRWinWeSE8Q86UoD0j3 VRqoV2CHDxWeW23F/6Nr1+mz+bGmUDOAIS4G/FJ+rYOMLopfL7kqu9PzhIp9OMyI1Pnz qTSOaYHMsu7/jV6u7E/Ai0CbQvsSq1sZKn6aHjSTlA61fxq32ALpcsWYPYSj8QY6GQSu bsfrxC68frJ5mSlTRcm4tyWPyy6QW+DPssTtCdtprm3f8wRxGzXHXUDisSfVuWjOZ3PB Nhi8zT2EYQODM04xtV1gcAqFv81huggYyIreEadHFLi9F1smtNTuLORGhpZEUhxnR/wU S2zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791361870; x=1791966670; 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=xwFdaNiudN2iiylPMoo56VdyeBK0OseTg6BPlmrhMsg=; b=rhhGv92ZlPZrppQngE5SW4fjU4E38Km4vlUrhc28GdAPCyUusNZUPErhX+l2rAGqNP zBGMMg69rf0SvuAgQzLsdjlCTNJCd90fSzFj6nQWioQgTJKf0AnUuaqN9xBtOSc91CSF iERzlE6Wn2XweHFcbJmfgMW42oumwmJUBbRupK9SslujT09apDP3dmMkfLUPufk9GNJ/ RgCClm/WEg21ZnyzynCeeSNsaf44mcddf3LO9TWQN1MoByoOEOTAfoDufjl2Isi8fl/4 brN5wghKXRNGIS7bWkGAwcwBcbrKi3HHysWu/yObZfi/PU9YWjxXI9L2+x2+wp9F9syS znMA== X-Forwarded-Encrypted: i=1; AKwUvBzdzAOLzG6XFUZKCtMD3ZL8wtaB5iLElU8/N9IUl67gc495cW0dM8bGMSFZfzYIQzEw9XM4yC/nz5A=@lists.xenproject.org X-Gm-Message-State: AFuF++nZxP9u5Ro+3ehZkvJNLqpdeNrWjOvAHzRB7O0XgjDMcAc02Ww6 eUF3+oi4gMcaglrWG5jmRd93kRGFLA0Xix1upWEKRHOgfMM89uUgF1BnG9EJn3VWxA== X-Gm-Gg: AYBFou2f93HWD5Zq+V1k+esvarAsCbFU5cy2Zd/AqYZqhvP5yuOPkQgtGwUnf/wDkH5 jV9Hh92U+wDSqvAxhscVfbbJtgLpkSakAWhOszO3S5plL5ZvA1G9jQJmiicTAbUH+z6Oaegi9jp iigiF+J3kOzRFcn9MeTLNceLl5ooHo2Ld38ue4/QrJPyspthDfpEky3x+JrwdLlQnFWJqqEpaSa O3SfPv10QFmRgAuYE9TgqePZoBiabU+XvhMRvazG+lPITo26Jop/0hwLi6qtzDOiRTqK0AYROyI QvOdelHQ6vXm8q57qB1MVFHjcGiSzBW8OAVXrVqGIcsh0Umgxdegp/jyqtMa/W5sc+R6XcYzXQE ZR6iXpI+v1de5ZyI0dZ87ENzpItnfHIy9VGtVWZhjA4aGqTMQ7K4Zwwkupc1yzcRgI3X8/+9Tey GeZ1ZC6neT/EtQaZnlIPlbg3QLraEeJ1Uy4mwsExn17zxp1LatLzKdZmInwZi9rMVaX41QoQd4c Ii7NsWNxoRMDzyc4cz4b15M+/1aBgYf1Nd5j5B/D+hP94fMdw/yh+Jvsmfflg== X-Received: by 2002:a05:600c:46c4:b0:4a0:eae0:769a with SMTP id 5b1f17b1804b1-4a180660fc7mr17337865e9.28.1791361869630; Wed, 07 Oct 2026 01:31:09 -0700 (PDT) Message-ID: <8304c0cf-8166-483a-b9cb-534b434a3a3a@suse.com> Date: Wed, 7 Oct 2026 10:31:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Eclair: scan the last xen-syms linking pass on Arm To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@epam.com> <03338d69-cbde-4918-8ffd-c309230d337f@suse.com> <8d3b26df-a42a-4d34-bc6c-81ed26839006@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: <8d3b26df-a42a-4d34-bc6c-81ed26839006@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791361870-4B6D6CFC-1DDF8764/10/78276251493 X-purgate-type: spam X-purgate-size: 2389 On 06.10.2026 18:09, Dmytro Prokopchuk1 wrote: > > > On 10/6/26 18:03, Jan Beulich wrote: >> On 06.10.2026 16:23, Dmytro Prokopchuk1 wrote: >>> Hiding .xen-syms.[013] assumed the almost-final image is always pass 2. >>> On x86 LAST_LINKING_PASS is 2, so .xen-syms.2 stays visible. On Arm >>> LAST_LINKING_PASS is 3 and the final image is .xen-syms.3, which was >>> hidden. Pass 2 is usually only a symlink, so Eclair saw no program link >>> and reported every translation unit as unreachable. >> >> When I did that work, rule 2.1 ended up clean for both ARM64-* analysis >> jobs (iirc). Upon re-checking I now see that ARM64-amd has 177 violations >> (apparently that's what you talk about above), but ARM64-allcode has none >> (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2916569232). >> >>> Stop hiding pass 3. Passes 0 and 1 remain excluded. >> >> This will cause scanning of both passes 2 and 3, i.e. consume more time >> and report duplicate violations when both passes are real linking steps. >> I think we want to be smarter than that, to really scan exactly once. I >> don't have a good idea just yet how to achieve that, though (and I was >> wondering already when putting together the original patch). > > At the moment > (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2917375773) I > see ARM64 R2.1 violations: > - 177 in AMD > - 249 in allcode Which demonstrates how variable the situation is. > Anyway, we can have if-else like this (copied from > automation/eclair_analysis/ECLAIR/tagging.ecl): > > -setq=target,getenv("XEN_TARGET_ARCH") > if(string_equal(target,"x86_64"), > file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[013]$"}), > if(string_equal(target,"arm64"), > file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[012]$"}) > ) > ) Ah, yes, perhaps. Yet there isn't any if-else needed here, is there? tagging.ecl also uses two simply if()-s afaics. (Excluding .xen-syms.3 on x86 is pointless. There's no 3rd pass there just yet, and once one would need adding, we'd want to similarly scan that rather than the potentially no-op pass 2.) The thing that continues to worry me with this is: This way we have a connection between the build machinery under xen/ and the patterns here, which need keeping in sync manually. That's going to be pretty easy to miss. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 07 08:35:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 08:35:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442047.1659576 (Exim 4.92) (envelope-from ) id 1xEN7H-0002AU-2L; Wed, 07 Oct 2026 08:35:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442047.1659576; Wed, 07 Oct 2026 08:35: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 1xEN7G-0002AN-U5; Wed, 07 Oct 2026 08:35:10 +0000 Received: by outflank-mailman (input) for mailman id 1442047; Wed, 07 Oct 2026 08:35:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEN7F-0002AH-Kj for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 08:35:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEN7D-00Gxv1-MZ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:35:07 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6042d-8faa-0a2a0a5109dd-0a2a4508dd6e-46 for ; Wed, 07 Oct 2026 10:35:07 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac6043b-f659-0a2a45080019-d1558035f18d-3 for ; Wed, 07 Oct 2026 10:35:07 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a140e7405dso36516535e9.3 for ; Wed, 07 Oct 2026 01:35: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-4a1803040cbsm25389685e9.4.2026.10.07.01.35.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 01:35: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=1791362107; x=1791966907; 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=XNlrugeeqhDFnUlFOnug3O3G9mVKhBdJxg6dJhVlq44=; b=N6ezHND6zYvLX9jWqPAth3DuGRUk0OMuklhIFR8tWrKVh1khHBM+xsBDSvbyTQ+Ol6 Ykl0YVs1EcpP5hnXg28NXrPLIa22TMCkih+hvkh8wwYRtwJ/d1bzJvqmR9Hz3qZBUOM2 GQDzXAubEEYZPmnbchMnevh1Md6bb9QZlDfe9TOx0IlXi0q/wfB6frUox6jMoTOZirwo CGexqcjjD1ujyVRZo2ug9x7xsNXgPf8tb5acGx/CAld9gaHyeu4AIQwxggXhQzTnRUGB d4aAx/3pggFXde4xV/7VjeZbsvM5ECm8m1BjBGggMMHbB1/w/xw/wRSbzX0d7QN8JrtY wKOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791362107; x=1791966907; 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=XNlrugeeqhDFnUlFOnug3O3G9mVKhBdJxg6dJhVlq44=; b=Hvrfg+giX93tYmZ9trbGAD1w0EbykcT8UvuVTDb/XuvYdv2K+KxeZqWrkiJB2l5dde GUcPGitkDVKHnZr8YJGxMTvXvn5AS+kFdgeOiBfXXb25K+XlVf9sSN+2tQ24tvXBMAh8 Ts2rO2nqbF/Fxi+Qm7YkjmXpXQ5Nmq9H8Z9wxzUYqCxcy1OVjqTkiIbVLFL3hPYxLyEA S7c0HOCk6N8/TLI3MoNsn89W/mdrd8XrO9rJN0Lmw4qiA+J8z+nfSHV+0i7SGUrSa4EA kMWmkaAH3qCegRtu3anbGT3fPXwJ7PUCTC7COZnIafK1pwVnz+yi+Z6QGVQOVA/X0tsW yF+w== X-Forwarded-Encrypted: i=1; AKwUvBxP1F/NHLilDEUz+65tXrZz51UFbj4SSLW7nIo5+0xHSndEvKW00wIUhyYnsau0qgie9V6SxPR00sA=@lists.xenproject.org X-Gm-Message-State: AFuF++kStGdLL3h2ew2yan9Xa/3AP76OFt7GLHIYEjMTCbnp1NtdFNW2 say/sxG+k2Os0ULHja3kAwuimpxkynp9OxaLf6wvqwTOJKnjtVDcmBT/b8w+V533/w== X-Gm-Gg: AYBFou3dmMySPmEm6H0xKk4pfONRp51wmQyzJFIWHtTpMiWiN+LsewTXbWjxz2tgSdj 1GR38FNkpyAeEDjoWbcsgHd4K+SAmlfs5nriVqV9qFlTWjLKP+e7lYRBREwfAzWtFofhMWwImay /pC1Vgjnoad1GXUWmzwlFhaM9vnqPhckXSePT05wUgYA2C+QxjV+ZVr1iqAllHA9rNqt28BRm8m MVpdfJ5plt03gqeVm8FBlSp9R+TmcCPYdH7JdjGUyc0vSb668Y2A+tAeo4gDbZg4WE7MPT3RJkX pjf06nIdY8aKp2zKhzyBjv1d+bXwV/XqmkZeN9896U79FuSGYv4d1tYreLav1ibdzV3KD1TVA9X Ox10eKLt7MY6vp7NxW7mrbIEYZ2XrnLjOjiaQAIXVYKNAXrpc+qHLqoEwVEmKanRMphZF5xINnC 5umN7RgPhO+/2ibZj7TbAncgiLXvwWTLbjlhNhxCe/9Gda5P05nkWJZ3Ltz7kglCiVTilYz8nUE EEm2Hr0Ffv7VYdj63bCt0GIe2Npjjf8P7icXsYDl6bNa8xf4sszdJM3ejn6I8Ajfr/T7QH//A== X-Received: by 2002:a05:600c:46c4:b0:4a0:eae0:769a with SMTP id 5b1f17b1804b1-4a180660fc7mr17504055e9.28.1791362106746; Wed, 07 Oct 2026 01:35:06 -0700 (PDT) Message-ID: <7cadeebd-3ba7-4d8e-9874-aa5f4aeef93e@suse.com> Date: Wed, 7 Oct 2026 10:35:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Eclair: scan the last xen-syms linking pass on Arm To: Nicola Vetrini Cc: Doug Goldstein , Stefano Stabellini , xen-devel@lists.xenproject.org, Dmytro Prokopchuk1 References: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@epam.com> <03338d69-cbde-4918-8ffd-c309230d337f@suse.com> <8d3b26df-a42a-4d34-bc6c-81ed26839006@epam.com> <22ed9e39767c74e820e964acc2e32a32@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: <22ed9e39767c74e820e964acc2e32a32@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1791362107-D457487B-5A39C413/10/78276251493 X-purgate-type: spam X-purgate-size: 3102 On 07.10.2026 07:45, Nicola Vetrini wrote: > On 2026-10-06 18:09, Dmytro Prokopchuk1 wrote: >> On 10/6/26 18:03, Jan Beulich wrote: >>> On 06.10.2026 16:23, Dmytro Prokopchuk1 wrote: >>>> Hiding .xen-syms.[013] assumed the almost-final image is always pass >>>> 2. >>>> On x86 LAST_LINKING_PASS is 2, so .xen-syms.2 stays visible. On Arm >>>> LAST_LINKING_PASS is 3 and the final image is .xen-syms.3, which was >>>> hidden. Pass 2 is usually only a symlink, so Eclair saw no program >>>> link >>>> and reported every translation unit as unreachable. >>> >>> When I did that work, rule 2.1 ended up clean for both ARM64-* >>> analysis >>> jobs (iirc). Upon re-checking I now see that ARM64-amd has 177 >>> violations >>> (apparently that's what you talk about above), but ARM64-allcode has >>> none >>> (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2916569232). >>> >>>> Stop hiding pass 3. Passes 0 and 1 remain excluded. >>> >>> This will cause scanning of both passes 2 and 3, i.e. consume more >>> time >>> and report duplicate violations when both passes are real linking >>> steps. >>> I think we want to be smarter than that, to really scan exactly once. >>> I >>> don't have a good idea just yet how to achieve that, though (and I was >>> wondering already when putting together the original patch). >>> >>> Jan >> >> Hmm >> >> At the moment >> (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2917375773) I >> see ARM64 R2.1 violations: >> - 177 in AMD >> - 249 in allcode >> >> Anyway, we can have if-else like this (copied from >> automation/eclair_analysis/ECLAIR/tagging.ecl): >> >> -setq=target,getenv("XEN_TARGET_ARCH") >> if(string_equal(target,"x86_64"), >> file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[013]$"}), >> if(string_equal(target,"arm64"), >> file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[012]$"}) >> ) >> ) >> >> ^^^ test pipeline is here: >> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2918571749 >> >> BR, Dmytro. > > In theory we could even generate a configuration file on the fly just > before invoking make. See e.g. [1] and [2]. In this way, we can > determine programmatically which is the linking step to consider, since > the logic involves some conditionals in the Makefile rules. Hmm, yes, that looks promising. > In any case > intercepting one more command that is just a symlink does not incur in a > big cost: only if the intercepted step is another linking command ~5 > more minutes are needed. Yet that's an issue, at least as long as the analysis jobs generally determine pipeline overall latency. Plus with code size (almost) only ever growing, that time is also only going to (almost) ever grow. Jan > [1] > https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/eclair_analysis/ECLAIR/generate_ecl.sh?ref_type=heads > [2] > https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/eclair_analysis/ECLAIR/generate-linker-symbols.sh?ref_type=heads > > From xen-devel-bounces@lists.xenproject.org Wed Oct 07 08:54:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 08:54:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442052.1659583 (Exim 4.92) (envelope-from ) id 1xENPz-0005PA-F7; Wed, 07 Oct 2026 08:54:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442052.1659583; Wed, 07 Oct 2026 08: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 1xENPz-0005P3-CY; Wed, 07 Oct 2026 08:54:31 +0000 Received: by outflank-mailman (input) for mailman id 1442052; Wed, 07 Oct 2026 08:54:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xENPx-0005Ox-Mo for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 08:54:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xENPw-008Yyq-2g for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:54:28 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac608bb-bab6-0a2a0a5309dd-0a2a4504c524-36 for ; Wed, 07 Oct 2026 10:54:28 +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 6ac608c3-b57f-0a2a45040019-b9ff1c2380d9-3 for ; Wed, 07 Oct 2026 10:54: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1159231980003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 08:54:24 +0000 Received: from [192.168.1.17] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id EBD3E8236A; Wed, 7 Oct 2026 10:54:23 +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=9H7EU+338BJ6nYgha7M1fS/gnRwsEUNAP49R3i652pc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=YM3cRif3Yrrd2pBXO8lX6tZ5WHtdEQcn8BLGYYyA0u6kjLdZjsE8WCJGyr5gredeqIA/z6Wlt 4PiL8MTD7pyXfBiaSjRo4gjx1fzJeG/auFBvPVjZ5JN/KLbcypFy5W5kuNymrH7SZ+sRJoF+RO8 qGIWaASqtKY7iRfFvImZIg0Vp0tEKeIFR8c27VL2MuOWmC/yNBOZNt13/ambeg50q2Vz1RLugbM S87X4Wo+kBfIsujnQ2fAzRZvHmkrD5/PN2DMHUvwOkdpo+voN6cZbKPPP819g6YdKgAQt/0ta3k Or39FBD6iqfe25R8qTAx5wCiCoPsgqysfJ4Y87Wpiztg== X-Zone-Loop: d427c0c52273cc89542b146e1d07098b5d03a5ae8c2e x-campaign-type: default x-transaction-id: a139b88a-aab6-484a-b470-14817d643fe9 x-swg-uid: 01-2abdb0a7-cb74-423f-b21e-baa6def5d590 X-Mailer: Sweego Message-ID: <1791363264.8631fc262581453bbf619ec5b2062170.1a1159231980003f66@vates.tech> x-swg-bid: 1791363264.8631fc262581453bbf619ec5b2062170.1a1159231980003f66 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 v3 12/39] xen/riscv: save and restore vsiselect 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: <3a454373368c507a7bf9693c6651a7749d2a86b7.1790779209.git.oleksii.kurochko@gmail.com> References: <3a454373368c507a7bf9693c6651a7749d2a86b7.1790779209.git.oleksii.kurochko@gmail.com> Date: Wed, 07 Oct 2026 10:53:43 +0200 X-Developer-Signature: v=1; a=openssh-sha256; t=1791363263; l=2088; i=baptiste.le-duc@vates.tech; h=from:subject:message-id; bh=aRs9i42FCl60M4rG8URJpD+haILXPXtXQ3+RW/xf3qs=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgQKqDblDzOFimZyyhA+RsKnxim2EiA 60KatQBsuueKYUAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPELU8vAfjdCDmtIiCJo8TQatYlNN6wwCNeJuEaI2li3ttOKta/FEZVxqdkxvdvm5goVTOwjSTq aIwtFzXCx6Ao= X-Developer-Key: i=baptiste.le-duc@vates.tech; a=openssh; fpr=SHA256:YieMhmvNcCYpeUbL6HuedGp4rwSlu4mQ+D7EJoVHM+k X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791363264211 X-purgate-ID: tlsNG-ebf023/1791363268-C22D4B50-C94FDA68/10/73395122804 X-purgate-type: spam X-purgate-size: 2088 > 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. Nit: I'd suggest a more tighter version that might be more clear. Feel free to use it: ``` vsiselect isn't saved/restored, yet the guest writes it directly (VS-mode accesses to siselect go to vsiselect). After a context switch a vCPU therefore sees the selector left by the previous vCPU on that hart: a guest writing siselect, getting descheduled, then accessing sireg hits a register it never selected, and it can 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 Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 07 09:11:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 09:11:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442061.1659594 (Exim 4.92) (envelope-from ) id 1xENge-0000TI-Ru; Wed, 07 Oct 2026 09:11:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442061.1659594; Wed, 07 Oct 2026 09:11: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 1xENge-0000TB-Nw; Wed, 07 Oct 2026 09:11:44 +0000 Received: by outflank-mailman (input) for mailman id 1442061; Wed, 07 Oct 2026 09:11:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xENgd-0000T5-8V for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 09:11:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xENgc-008cvQ-LG for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:11:42 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac60ccc-bab6-0a2a0a5309dd-0a2a450ad4de-26 for ; Wed, 07 Oct 2026 11:11:42 +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 6ac60ccd-f2d2-0a2a450a0019-b9ff1c229b41-3 for ; Wed, 07 Oct 2026 11:11: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a115a1f37e0003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 09:11:37 +0000 Received: from [192.168.1.17] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 846FC81DDC; Wed, 7 Oct 2026 11: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=WRO3g9gRG1WLovFJ+ZYBe4O9w4/UxWnJx8GUWks1gXo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=VXgb4+t7iUPrkxN8ZepfE1pJi6ylYu+gjMI5AIQRLc+TOtSyMJduWz/HcfjWVnDLiKwPgNnWj tfIzIwDqRzv1Su4chyhXgbwGcTwYxqgv/b8+yM/v0WaoisQJ+CiZmFIQ4mQWE22II30jcNukzyu isoZI5avWQJOOjFjmnhclKoAUqzRlBoFyFle9Q2O20lNPZEH0WnqeIFbriRYoqxaB4R5L2Nsxrx Q4aLMM2/9FD+dCsmX0rBO4Rs5qbHllhOYbGBjAirK+qcUNd5Q7SSnKUO/nxoRbISyTS0j77fssW hVqIOpXSJXdM884iU4pMKyVE0sb8mD0h8GyGxhrewWwg== X-Zone-Loop: 9f648b2da2008d5afde89651beb59ccb324e34e3b602 x-campaign-type: default x-transaction-id: 4db2b20c-102e-45b1-b1fd-5994e78b90ef x-swg-uid: 01-6b847cc4-5bf7-4d57-b673-2dac810960a9 X-Mailer: Sweego Message-ID: <1791364297.8631fc262581453bbf619ec5b2062170.1a115a1f37e0003f66@vates.tech> x-swg-bid: 1791364297.8631fc262581453bbf619ec5b2062170.1a115a1f37e0003f66 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 v3 13/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: <752ca5c3e7af9e4d2037783d7d213a9bc2360c83.1790779209.git.oleksii.kurochko@gmail.com> References: <752ca5c3e7af9e4d2037783d7d213a9bc2360c83.1790779209.git.oleksii.kurochko@gmail.com> Date: Wed, 07 Oct 2026 11:11:22 +0200 X-Developer-Signature: v=1; a=openssh-sha256; t=1791364296; l=569; i=baptiste.le-duc@vates.tech; h=from:subject:message-id; bh=DbsrGgsALD7GsKnsa4PdK2X/4zVx4OIJDrDoVpqQUmI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgQKqDblDzOFimZyyhA+RsKnxim2EiA 60KatQBsuueKYUAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QJxSrq4S3LjnlfnQ45zGvgt9+1XnefuluqSltVvDRwDkaRlM2lZ9ipVt27bQWK6iJ8mLohwd4uU gbIe7szWINAc= X-Developer-Key: i=baptiste.le-duc@vates.tech; a=openssh; fpr=SHA256:YieMhmvNcCYpeUbL6HuedGp4rwSlu4mQ+D7EJoVHM+k X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791364296787 X-purgate-ID: tlsNG-4011c0/1791364302-4ACDBCFC-7DA5FD87/10/73395122804 X-purgate-type: spam X-purgate-size: 569 On Wed, 30 Sep 2026 18:23:32 +0200, 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. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 07 09:13:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 09:13:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442065.1659602 (Exim 4.92) (envelope-from ) id 1xENiM-0000vu-5Z; Wed, 07 Oct 2026 09:13:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442065.1659602; Wed, 07 Oct 2026 09: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 1xENiM-0000vn-2K; Wed, 07 Oct 2026 09:13:30 +0000 Received: by outflank-mailman (input) for mailman id 1442065; Wed, 07 Oct 2026 09:13:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xENiK-0000vf-MW for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 09:13:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xENiJ-008Vhi-W4 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:13:28 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac60d2d-8faa-0a2a0a5109dd-0a2a4508ed84-42 for ; Wed, 07 Oct 2026 11:13:27 +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 6ac60d37-f659-0a2a45080019-b9ff1c128f37-3 for ; Wed, 07 Oct 2026 11:13: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a115a38ea30003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 09:13:22 +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 1B8968233F; Wed, 7 Oct 2026 11:13: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: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=ojFYZS8maUGImwXqG3ZeKe5T0crpp+V1kSjqN1hbyrc=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references:feedback-id; b=E0+oVSV4RIqXN7K11Jq3zTLQFUJ+u4/LZ0HvdujNNvjBVt4X/ap8KHQjZme50ih+uAUx2hNDu YxQhVLfBq4MFc6TG7PmWq+7eslkBSgnw6nGNOKzbIMAr0TnfhP5SIQNMh2x1W4BHR77xAVqKo/8 LVLY8daM/M0mxoC63FXSc53ZyHZ0lzgtBBa/LKHPG60tec7un3PbKYNTBFvk405AXb6LwKwEkPu L3ZiPzxooXvni8OBwgoqBry294NxnhBPP4IVSVWFrFJcLtl1cUIhV+6KemqKBHwkeFKvj3hmF9o Y+tcJZrqlxxhQ/l/alNRuxQy90b6pF9Mh/t/+V3snASA== X-Zone-Loop: 618143cedf6e22ec084116a0007d10de2944c26c5544 x-campaign-type: default x-transaction-id: 7cdbbb1f-e8b7-4649-b085-d2a4e56ae651 x-swg-uid: 01-91b5b443-6589-4d91-bb4b-06dadccc981d X-Mailer: Sweego Message-ID: <1791364402.8631fc262581453bbf619ec5b2062170.1a115a38ea30003f66@vates.tech> x-swg-bid: 1791364402.8631fc262581453bbf619ec5b2062170.1a115a38ea30003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 7 Oct 2026 11:13:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66@vates.tech> <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@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: <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@vates.tech> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------WYCOH5lZIV0R4buNC0zn0Emm" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791364402193 X-purgate-ID: tlsNG-c1860d/1791364407-CD74B87B-5DF54D7A/0/0 X-purgate-type: clean X-purgate-size: 18437 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------WYCOH5lZIV0R4buNC0zn0Emm Content-Type: multipart/mixed; boundary="------------rS8oI0PpMQN9AOKUU04WK8nI"; protected-headers="v1"; hp="clear" Message-ID: Date: Wed, 7 Oct 2026 11:13:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66@vates.tech> <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@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: <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@vates.tech> --------------rS8oI0PpMQN9AOKUU04WK8nI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDcvMTAvMjAyNiDDoCAxMDoyNCwgQmFwdGlzdGUgTGUgRHVjIGEgw6ljcml0wqA6DQo+ IE9uIDEwLzcvMjYgMDA6NTAsIFRlZGR5IEFzdGllIHdyb3RlOg0KPj4gTGUgMDUvMTAvMjAy NiDDoCAxODowMiwgQmFwdGlzdGUgTGUgRHVjIGEgw6ljcml0wqA6DQo+Pj4gQSBSSVNDLVYg aW1wbGVtZW50YXRpb24gY2FuIG1hbmFnZSB0aGUgUFRFIEEvRCBiaXRzIGluIG9uZSBvZiB0 d28gd2F5czoNCj4+PiDCoMKgwqDCoCAxKSBVcGRhdGUgdGhlICdBJyBhbmQgJ0QnIFBURSBi aXRzIGluIGhhcmR3YXJlIChyYXRpZmllZCBhcyBTdmFkdSkuDQo+Pj4gwqDCoMKgwqAgMikg R2VuZXJhdGUgYSBwYWdlIGZhdWx0IHdoZW4gJ0EnIGFuZC9vciAnRCcgaXMgY2xlYXIsIHNv IHRoYXQgDQo+Pj4gc29mdHdhcmUNCj4+PiDCoMKgwqDCoMKgwqDCoCBjYW4gc2V0IHRoZW0g KHJhdGlmaWVkIGFzIFN2YWRlKS4NCj4+Pg0KPj4+IHAybV9zZXRfcHRlX2ZsYWdzKCkgcHJl c2V0cyBBL0QgaW4gRy1zdGFnZSBQVEVzIG9ubHkgd2hlbiB0aGUgZGV2aWNlIA0KPj4+IHRy ZWUNCj4+PiBhZHZlcnRpc2VzIFN2YWRlLiBQbGF0Zm9ybXMgdGhhdCB1c2Ugc2NoZW1lICgy KSB3aXRob3V0IGFkdmVydGlzaW5nIA0KPj4+IFN2YWRlLA0KPj4+IHN1Y2ggYXMgdGhlIEhp Rml2ZSBQcmVtaWVyIFA1NTAsIHRoZW4gaGl0IGd1ZXN0LXBhZ2UgZmF1bHRzIHRoYXQgWGVu IA0KPj4+IGRvZXMNCj4+PiBub3QgaGFuZGxlLg0KPj4NCj4+IEkgc2Vjb25kIHdoYXQgSmFu IHNhaWQgKHRoaXMgaXMgbGlrZWx5IGEgZmlybXdhcmUgYnVnLCBnaXZlbiB0aGF0IHRoZSAN Cj4+IGVudW1lcmF0ZWQgYmVoYXZpb3IgaXMgbm90IGNvbnNpc3RlbnQgd2l0aCB0aGUgc3Bl Y2lmaWNhdGlvbiwgYXMgDQo+PiBleGlzdGVuY2Ugb2YgU3ZhZHUvU3ZhZGUgYWx0ZXJzIG9i c2VydmFibGUgYmVoYXZpb3IpLg0KPj4NCj4gVGhhbmtzLCBhZ3JlZWQgb24gYm90aCBwb2lu dHMuDQo+IA0KPiBJJ2xsIHJld29yZCB0aGUgY29tbWl0IG1lc3NhZ2U6IGl0IHNob3VsZG4n dCBpbXBseSB0aGF0IFN2YWRlIGluIHRoZSBEVCANCj4gbWVhbnMgZmF1bHRzIHdpbGwgb2Nj dXIsIHNpbmNlIHdpdGggU3ZhZHUgYWxzbyBwcmVzZW50IHRoYXQgZGVwZW5kcyBvbiANCj4g aGVudmNmZy5BRFVFLg0KPiANCj4gT24gdGhlIGZpcm13YXJlLWJ1ZyBwb2ludDogSSBkb24n dCB0aGluayB0aGUgUDU1MCBpcyByZWFsbHkgaW5jb25zaXN0ZW50IA0KPiB3aXRoIHRoZSBz cGVjLiBTdmFkZSBhbmQgU3ZhZHUgZGlkbid0IGV4aXN0IHdoZW4gdGhlIFA1NTAgY29yZSB3 YXMgDQo+IGRlc2lnbmVkLiBUaGV5IHdlcmUgb25seSByYXRpZmllZCBsYXRlciwgdG8gbmFt ZSB0aGUgdHdvIGJlaGF2aW9ycyB0aGF0IA0KPiBhbHJlYWR5IGV4aXN0ZWQgaW4gdGhlIHdp bGQuIEJlZm9yZSB0aGF0LCB0aGUgcHJpdmlsZWdlZCBzcGVjIGp1c3QgDQo+IGFsbG93ZWQg ZWl0aGVyOiBoYXJkd2FyZSB1cGRhdGluZyBBL0QsIG9yIHJhaXNpbmcgYSBwYWdlIGZhdWx0 LiBUaGUgUDU1MCANCj4gaW1wbGVtZW50cyB0aGUgc2Vjb25kLCBhbmQgdGhlcmUgd2FzIG5v IGV4dGVuc2lvbiBpdCBjb3VsZCBhZHZlcnRpc2UgZm9yIA0KPiBpdC4NCj4gVGhlcmVmb3Jl LCB0aGUgRFQgbGFja3Mgc3ZhZGUgYmVjYXVzZSB0aGUgZXh0ZW5zaW9uIGRpZG4ndCBleGlz dCB3aGVuIA0KPiB0aGUgcGxhdGZvcm0gZGVzY3JpcHRpb24gd2FzIHdyaXR0ZW4sIG5vdCBi ZWNhdXNlIHRoZSB2ZW5kb3IgDQo+IG1pc2Rlc2NyaWJlZCBhbnl0aGluZy4NCj4gDQoNCkF0 IGxlYXN0IGluIGxhdGVzdCBzcGVjaWZpY2F0aW9uLCBhYnNlbmNlIG9mIFN2YWRlIGltcGxp ZXMgdGhhdCBBL0QgYml0IA0KaXMgdXBkYXRlZCBvbiBwYWdlLXRhYmxlIGFjY2Vzcy4NCg0K VGhlIHNwZWMgYWxzbyBpbnNpc3Qgb24gdGhlIG5vLVN2YWRlIGJlaGF2aW9yLg0KDQogPiBU aGUgU3ZhZGUgZXh0ZW5zaW9uOiB3aGVuIGEgdmlydHVhbCBwYWdlIGlzIGFjY2Vzc2VkIGFu ZCB0aGUgQSBiaXQgaXMNCiA+IGNsZWFyLCBvciBpcyB3cml0dGVuIGFuZCB0aGUgRCBiaXQg aXMgY2xlYXIsIGEgcGFnZS1mYXVsdCBleGNlcHRpb24gaXMNCiA+IHJhaXNlZC4NCiA+DQog PiBXaGVuIHRoZSBTdmFkZSBleHRlbnNpb24gaXMgbm90IGltcGxlbWVudGVkLCB0aGUgZm9s bG93aW5nIHNjaGVtZQ0KID4gYXBwbGllcy4NCiA+DQogPiAoLi4uIGhhcmR3YXJlIHVwZGF0 ZXMgQS9EIGJpdCkNCg0KVGhlIG5vLVN2YWRlIGJlaGF2aW9yIGNhbiB0aGVuIGJlIHJlLWlu dHJvZHVjZWQgd2l0aCBTdmFkdSB3aXRoIEFEVUU9MQ0KDQogPiBJZiB0aGUgU3ZhZHUgZXh0 ZW5zaW9uIGlzIGltcGxlbWVudGVkLCB0aGUgQURVRSBiaXQgY29udHJvbHMgd2hldGhlcg0K ID4gaGFyZHdhcmUgdXBkYXRpbmcgb2YgUFRFIEEvRCBiaXRzIGlzIGVuYWJsZWQgZm9yIFZT LXN0YWdlIGFkZHJlc3MNCiA+IHRyYW5zbGF0aW9uLiBXaGVuIEFEVUU9MSwgaGFyZHdhcmUg dXBkYXRpbmcgb2YgUFRFIEEvRCBiaXRzIGlzIGVuYWJsZWQNCiA+IGR1cmluZyBWUy1zdGFn ZSBhZGRyZXNzIHRyYW5zbGF0aW9uLCBhbmQgdGhlIGltcGxlbWVudGF0aW9uIGJlaGF2ZXMg YXMNCiA+IHRob3VnaCB0aGUgU3ZhZGUgZXh0ZW5zaW9uIHdlcmUgbm90IGltcGxlbWVudGVk IGZvciBWUy1tb2RlIGFkZHJlc3MNCiA+IHRyYW5zbGF0aW9uLiBXaGVuIEFEVUU9MCwgdGhl IGltcGxlbWVudGF0aW9uIGJlaGF2ZXMgYXMgdGhvdWdoIFN2YWRlDQogPiB3ZXJlIGltcGxl bWVudGVkIGZvciBWUy1zdGFnZSBhZGRyZXNzIHRyYW5zbGF0aW9uLiBJZiBTdmFkdSBpcyBu b3QNCiA+IGltcGxlbWVudGVkLCBBRFVFIGlzIHJlYWQtb25seSB6ZXJvLg0KDQpUaGUgc3Bl Y2lmaWNhdGlvbiBpcyB1bmZvcnR1bmF0ZWx5IHdyaXR0ZW4gYSBiaXQgc2lkZXdheXMsIHRo ZSBiYXNlIA0KYmVoYXZpb3IgaGFwcGVucyB0byBiZSAib3B0LWluIiB0aHJvdWdoIGFub3Ro ZXIgZXh0ZW5zaW9uLg0KDQpCdXQgdGhhdCdzIHNwZWNpZmljYXRpb24sIGFuZCBpdCdzIHBv c3NpYmxlIHRoYXQgZmlybXdhcmUgZm9sbG93cyBhIA0KZWFybGllciByZXZpc2lvbiBvZiBp dCB0aGF0IGhhcyB1bnNwZWNpZmllZCBBL0Qgc2VtYW50aWNzIGluc3RlYWQuIEJ1dCANCmlu IHRoaXMgY2FzZSwgdGhlIGZpcm13YXJlIGlzIG91dCBvZiBzeW5jIHdpdGggY3VycmVudCBz cGVjaWZpY2F0aW9ucyANCmFuZCBwcm9iYWJseSB3YW50cyB0byBiZSB1cGRhdGVkLg0KDQo+ IEkgYWdyZWUgdGhhdCwgd2hlcmUgU3ZhZHUgaXMgYXZhaWxhYmxlLCBYZW4gc2hvdWxkIGlk ZWFsbHkgY29uZmlndXJlIGEgDQo+IGNvbnNpc3RlbnQgc2NoZW1lIChBRFVFPTEpIGFuZCB1 c2UgQURVRT0wIG9ubHkgZm9yIHNwZWNpZmljIG5lZWRzIHN1Y2ggDQo+IGFzIGRpcnR5IHRy YWNraW5nLiBCdXQgWGVuIGRvZXNuJ3Qgc3VwcG9ydCBTdmFkdSB0b2RheSwgc28gdGhhdCBp cyBhIA0KPiBzZXBhcmF0ZSBwaWVjZSBvZiB3b3JrIHdoaWNoIEknZCBwcmVmZXIgdG8gZG8g bGF0ZXIuDQo+IA0KPiBJbiB0aGUgbWVhbnRpbWUswqBwcmVzZXR0aW5nIEEvRCBpbiB0aGUg Ry1zdGFnZSBQVEVzIGlzIHRoZSBvbmx5IHdheSB0byANCj4gYXZvaWQgdGhlIGZhdWx0cyBv biBoYXJkd2FyZSBsaWtlIHRoZSBQNTUwLCBhbmQgaXQgaXMgaGFybWxlc3Mgb24gDQo+IGhh cmR3YXJlIHRoYXQgdXBkYXRlcyBBL0QgaXRzZWxmLg0KDQpMb29rcyBnb29kIHRvIG1lLg0K DQo+IA0KPiBGb3IgdjYgSSdsbCBrZWVwIHRoZSB1bmNvbmRpdGlvbmFsIHByZXNldCBhbmQg cmV3b3JkIHRoZSBjb21taXQgbWVzc2FnZSANCj4gdG8gc2F5IHRoaXMsIHdoYXQgZG8geW91 IHRoaW5rPw0KPiANCj4+Pg0KPj4+IEFsd2F5cyBwcmVzZXQgQS9EIGluIEctc3RhZ2UgUFRF cyBzbyBzY2hlbWUgKDIpIG5ldmVyIGZhdWx0cy4gVGhpcyBpcw0KPj4+IGhhcm1sZXNzIHdp dGggKDEpOiBzb2Z0d2FyZSBqdXN0IGRvZXMgd2hhdCBoYXJkd2FyZSB3b3VsZCBoYXZlIGRv bmUgb24NCj4+PiBmaXJzdCBhY2Nlc3MuDQo+Pj4NCj4+PiBEcm9wIHRoZSBUT0RPIHN1Z2dl c3RpbmcgdG8gaGFuZGxlIEEvRCBmYXVsdHM6IG9ubHkgU3ZhZGUgcmFpc2VzIA0KPj4+IHRo ZW0sIHNvDQo+Pj4gaXQgd291bGQgbm90IHdvcmsgb24gU3ZhZHUuIERpcnR5L2FjY2VzcyB0 cmFja2luZyBjYW4gcmVzdHJpY3QgdGhlIFJXWA0KPj4+IHBlcm1pc3Npb25zIG9mIHAybSBl bnRyaWVzLCBhcyB4ODYgYW5kIEFybSBkby4NCj4+IFlldCwgZXhpc3RlbmNlIG9mIFN2YWRl IGFsb25lIGRvZXNuJ3QgbWFuZGF0ZSB0aGUgYWN0dWFsIGJlaGF2aW9yLCBpdCANCj4+IGlz IGFsc28gZGVwZW5kYW50IG9uIHRoZSB2YWx1ZSBvZiBBRFVFIGJpdCBpbiBjb25maWd1cmF0 aW9uIHJlZ2lzdGVycy4NCj4+DQo+PiBJZGVhbGx5IChpbiBjYXNlcyB3ZSBjYW4pIHdlIHdv dWxkIHdhbnQgdG8gY29uZmlndXJlIGhhcmR3YXJlIHRvIA0KPj4gZm9sbG93IGEgY29uc2lz dGVudCBzY2hlbWUgKHdpdGggdGhlIG9uZSB0aGF0IHVwZGF0ZXMgQS9EIHdpdGggDQo+PiBo YXJkd2FyZSBpLmUgQURVRT0xLCBhcyBpdCdzIGNvbnNpc3RlbnQgdG8gd2l0aG91dCBTdmFk ZSkgYW5kIG9ubHkgDQo+PiBjb25zaWRlciB0aGUgQURVRT0wIGJlaGF2aW9yIGZvciBzcGVj aWZpYyBuZWVkcyBsaWtlIGRpcnR5IHRyYWNraW5nLg0KPj4NCj4+PiA+IEZpeGVzOiBmZjE0 MDUzOTgzYjAgKCJ4ZW4vcmlzY3Y6IEltcGxlbWVudCBwMm1fcHRlX2Zyb21fbWZuKCkgYW5k IA0KPj4gc3VwcG9ydCBQQk1UIGNvbmZpZ3VyYXRpb24iKQ0KPj4+IEFzc2lzdGVkLWJ5OiBD bGF1ZGU6Y2xhdWRlLW9wdXMtNQ0KPj4+IFNpZ25lZC1vZmYtYnk6IEJhcHRpc3RlIExlIER1 YyA8YmFwdGlzdGUubGUtZHVjQHZhdGVzLnRlY2g+DQo+Pj4gLS0tDQo+Pj4gQ2hhbmdlcyBz aW5jZSB2NDoNCj4+PiAtIHJlc3RvcmUgc3ZhZGUgYW5kIHVwZGF0ZSB0aGUgY29tbWl0IG1l c3NhZ2UgYWNjb3JkaW5nbHkuDQo+Pj4gLSByZWJhc2Ugb24gdG9wIG9mIHN0YWdpbmcuDQo+ Pj4gLS0tDQo+Pj4gQ2hhbmdlcyBzaW5jZSB2MzoNCj4+PiAtIGFsd2F5cyBwcmVzZXQgQS9E IGJpdHMgaW4gRy1zdGFnZSBtYXBwaW5ncyBpbnN0ZWFkIG9mIGtleWluZyBvZmYgDQo+Pj4g dGhlIERUOg0KPj4+IMKgwqAgaXQgbWF5IG5vdCByZWZsZWN0IHdoYXQgdGhlIGhhcmR3YXJl IGFjdHVhbGx5IGRvZXMuDQo+Pj4gLSBjaGFuZ2UgY29tbWl0IHRpdGxlL21lc3NhZ2UuDQo+ Pj4gLSBkcm9wIHN2YWRlIGFzIGl0IGlzIG5vdy11bnVzZWQuDQo+Pj4gLS0tDQo+Pj4gQ2hh bmdlcyBzaW5jZSB2MjoNCj4+PiAtIGNoYW5nZSBjb21taXQgdGl0bGUuDQo+Pj4gLSBwcmVz ZXQgQS9EIGJpdHMgaW4gcDJtX3NldF9wdGVfZmxhZ3MoKSBpZiAoIXN2YWR1IHx8IHN2YWRl KSwgDQo+Pj4gaW5zdGVhZCBvZg0KPj4+IHNldHRpbmcgUklTQ1ZfSVNBX0VYVF9zdmFkZSBp biB0aGUgcmlzY3ZfaXNhIGJpdG1hcCBmb3IgY2FzZXMgMSwgMiANCj4+PiBhbmQgNC4NCj4+ PiAtIHJpc2N2X3Jlc29sdmVfYWRfc2NoZW1lKCkgbm93IG9ubHkgd2FybnMgd2hlbiBib3Ro IFN2YWRlIGFuZCBTdmFkdSBhcmUNCj4+PiBwcmVzZW50IGFuZCBTQkkgRldGVCBpcyBtaXNz aW5nOyBkcm9wIHRoZSBkZWFkICdzdmFkdSAmJiBzdmFkZScgb3BlcmFuZC4NCj4+PiAtIHJl cGVhdCBYRU5MT0dfV0FSTklORyBvbiBlYWNoIGxpbmUgb2YgdGhlIHdhcm5pbmcuDQo+Pj4g LSBkcm9wIEFTU0VSVChzdmFkZSAhPSBzdmFkdSkgZnJvbSBwMm1fc2V0X3B0ZV9mbGFncygp Lg0KPj4+IC0gb25seSBhZGQgdGhlIHNiaV9wcm9iZV9leHRlbnNpb24oKSBkZWNsYXJhdGlv biB0byBzYmkuaC4NCj4+PiAtIHJld29yayB0aGUgY29tbWVudCBpbiBwMm1fc2V0X3B0ZV9m bGFncygpLg0KPj4+IC0tLQ0KPj4+IENoYW5nZXMgc2luY2UgdjE6DQo+Pj4gLSBjaGFuZ2Ug Y29tbWl0IHRpdGxlDQo+Pj4gLSBleHBvc2UgUklTQ1ZfSVNBX0VYVF9zdmFkdSBzbyB0aGUg dHdvIGV4dGVuc2lvbnMgY2FuIGJlIHRvbGQgYXBhcnQuDQo+Pj4gLSBtb3ZlIHRoZSBTdmFk ZS9TdmFkdSByZXNvbHV0aW9uIHRvIGEgbmV3IHJpc2N2X3Jlc29sdmVfYWRfc2NoZW1lKCks DQo+Pj4gwqDCoCBjYWxsZWQgb25jZSBmcm9tIHJpc2N2X2ZpbGxfaHdjYXAoKS4NCj4+PiAt IGV4cG9zZSBzYmlfcHJvYmVfZXh0ZW5zaW9uKCkgKHdhcyBzdGF0aWMpIHRvIHByb2JlIGZv ciBTQkkgRldGVC4NCj4+PiAtIHN0b3AgcHJlc2V0dGluZyBBL0QgYml0cyB1bmNvbmRpdGlv bmFsbHkgaW4gcDJtX3NldF9wZXJtaXNzaW9uKCksIA0KPj4+IGRvIGl0DQo+Pj4gwqDCoCBv bmx5IHdoZW4gU3ZhZGUgaXMgcHJlc2VudC4NCj4+PiAtLS0NCj4+PiDCoCB4ZW4vYXJjaC9y aXNjdi9wMm0uYyB8IDM4ICsrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4gwqAgMSBmaWxlIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgMzAgZGVsZXRpb25z KC0pDQo+Pj4NCj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvcmlzY3YvcDJtLmMgYi94ZW4v YXJjaC9yaXNjdi9wMm0uYw0KPj4+IGluZGV4IGY3YjM4MGI5MGEuLjE0Y2FlN2RjZDcgMTAw NjQ0DQo+Pj4gLS0tIGEveGVuL2FyY2gvcmlzY3YvcDJtLmMNCj4+PiArKysgYi94ZW4vYXJj aC9yaXNjdi9wMm0uYw0KPj4+IEBAIC01OTEsMzggKzU5MSwxNiBAQCBzdGF0aWMgdm9pZCBw Mm1fc2V0X3B0ZV9mbGFncyhwdGVfdCAqZSwgDQo+Pj4gcDJtX3R5cGVfdCB0KQ0KPj4+IMKg wqDCoMKgwqAgZS0+cHRlIHw9IFBURV9VU0VSOw0KPj4+IMKgIMKgwqDCoMKgwqAgLyoNCj4+ PiAtwqDCoMKgwqAgKiBUd28gc2NoZW1lcyB0byBtYW5hZ2UgdGhlIEEgYW5kIEQgYml0cyBh cmUgZGVmaW5lZDoNCj4+PiAtwqDCoMKgwqAgKsKgwqAg4oCiIFRoZSBTdmFkZSBleHRlbnNp b246IHdoZW4gYSB2aXJ0dWFsIHBhZ2UgaXMgYWNjZXNzZWQgYW5kIA0KPj4+IHRoZSBBIGJp dA0KPj4+IC3CoMKgwqDCoCAqwqDCoMKgwqAgaXMgY2xlYXIsIG9yIGlzIHdyaXR0ZW4gYW5k IHRoZSBEIGJpdCBpcyBjbGVhciwgYSBwYWdlLWZhdWx0DQo+Pj4gLcKgwqDCoMKgICrCoMKg wqDCoCBleGNlcHRpb24gaXMgcmFpc2VkLg0KPj4+IC3CoMKgwqDCoCAqwqDCoCDigKIgV2hl biB0aGUgU3ZhZGUgZXh0ZW5zaW9uIGlzIG5vdCBpbXBsZW1lbnRlZCwgdGhlIA0KPj4+IGZv bGxvd2luZyBzY2hlbWUNCj4+PiAtwqDCoMKgwqAgKsKgwqDCoMKgIGFwcGxpZXMuDQo+Pj4g LcKgwqDCoMKgICrCoMKgwqDCoCBXaGVuIGEgdmlydHVhbCBwYWdlIGlzIGFjY2Vzc2VkIGFu ZCB0aGUgQSBiaXQgaXMgY2xlYXIsIA0KPj4+IHRoZSBQVEUgaXMNCj4+PiAtwqDCoMKgwqAg KsKgwqDCoMKgIHVwZGF0ZWQgdG8gc2V0IHRoZSBBIGJpdC4gV2hlbiB0aGUgdmlydHVhbCBw YWdlIGlzIA0KPj4+IHdyaXR0ZW4gYW5kIHRoZQ0KPj4+IC3CoMKgwqDCoCAqwqDCoMKgwqAg RCBiaXQgaXMgY2xlYXIsIHRoZSBQVEUgaXMgdXBkYXRlZCB0byBzZXQgdGhlIEQgYml0LiBX aGVuIA0KPj4+IEctc3RhZ2UNCj4+PiAtwqDCoMKgwqAgKsKgwqDCoMKgIGFkZHJlc3MgdHJh bnNsYXRpb24gaXMgaW4gdXNlIGFuZCBpcyBub3QgQmFyZSwgdGhlIEctIA0KPj4+IHN0YWdl IHZpcnR1YWwNCj4+PiAtwqDCoMKgwqAgKsKgwqDCoMKgIHBhZ2VzIG1heSBiZSBhY2Nlc3Nl ZCBvciB3cml0dGVuIGJ5IGltcGxpY2l0IGFjY2Vzc2VzIHRvIA0KPj4+IFZTLWxldmVsDQo+ Pj4gLcKgwqDCoMKgICrCoMKgwqDCoCBtZW1vcnkgbWFuYWdlbWVudCBkYXRhIHN0cnVjdHVy ZXMsIHN1Y2ggYXMgcGFnZSB0YWJsZXMuDQo+Pj4gLcKgwqDCoMKgICogVGhlcmVieSB0byBh dm9pZCBhIHBhZ2UtZmF1bHQgaW4gY2FzZSBvZiBTdmFkZSBpcyBhdmFpbGFibGUsIA0KPj4+ IGl0IGlzDQo+Pj4gLcKgwqDCoMKgICogbmVjZXNzYXJ5IHRvIHNldCBBIGFuZCBEIGJpdHMu DQo+Pj4gK8KgwqDCoMKgICogQSBSSVNDLVYgaW1wbGVtZW50YXRpb24gY2FuIGVpdGhlcjoN Cj4+PiArwqDCoMKgwqAgKiAxKSBVcGRhdGUgdGhlICdBJyBhbmQgJ0QnIFBURSBiaXRzIGlu IGhhcmR3YXJlLg0KPj4+ICvCoMKgwqDCoCAqIDIpIEdlbmVyYXRlIGEgcGFnZSBmYXVsdCB3 aGVuICdBJyBhbmQvb3IgJ0QnIGlzIGNsZWFyLCBzbyB0aGF0DQo+Pj4gK8KgwqDCoMKgICrC oMKgwqAgc29mdHdhcmUgY2FuIHNldCB0aGVtLg0KPj4NCj4+DQo+Pg0KPj4+IMKgwqDCoMKg wqDCoCAqDQo+Pj4gLcKgwqDCoMKgICogVE9ETzogRm9yIG5vdywgaXTigJlzIGZpbmUgdG8g c2ltcGx5IHNldCB0aGUgQS9EIGJpdHMsIHNpbmNlIA0KPj4+IE9wZW5TQkkNCj4+PiAtwqDC oMKgwqAgKsKgwqDCoMKgwqDCoCBkZWxlZ2F0ZXMgcGFnZSBmYXVsdHMgdG8gYSBsb3dlciBw cml2aWxlZ2UgbW9kZSBhbmQgc28gDQo+Pj4gT3BlblNCSQ0KPj4+IC3CoMKgwqDCoCAqwqDC oMKgwqDCoMKgIGlzbid0IGV4cGVjdCB0byBoYW5kbGUgcGFnZS1mYXVsdHMgb2NjdXJlZCBp biBsb3dlciBtb2Rlcy4NCj4+PiAtwqDCoMKgwqAgKsKgwqDCoMKgwqDCoCBCeSBzZXR0aW5n IHRoZSBBL0QgYml0cyBoZXJlLCBwYWdlIGZhdWx0cyB0aGF0IHdvdWxkIA0KPj4+IG90aGVy d2lzZQ0KPj4+IC3CoMKgwqDCoCAqwqDCoMKgwqDCoMKgIGJlIGdlbmVyYXRlZCBkdWUgdG8g dW5zZXQgQS9EIGJpdHMgd2lsbCBub3Qgb2NjdXIgaW4gWGVuLg0KPj4+IC3CoMKgwqDCoCAq DQo+Pj4gLcKgwqDCoMKgICrCoMKgwqDCoMKgwqAgQ3VycmVudGx5LCBYZW4gb24gUklTQy1W IGRvZXMgbm90IG1ha2UgdXNlIG9mIHRoZSANCj4+PiBpbmZvcm1hdGlvbg0KPj4+IC3CoMKg wqDCoCAqwqDCoMKgwqDCoMKgIHRoYXQgY291bGQgYmUgb2J0YWluZWQgZnJvbSBoYW5kbGlu ZyBzdWNoIHBhZ2UgZmF1bHRzLCANCj4+PiB3aGljaA0KPj4+IC3CoMKgwqDCoCAqwqDCoMKg wqDCoMKgIGNvdWxkIG90aGVyd2lzZSBiZSB1c2VmdWwgZm9yIHNldmVyYWwgdXNlIGNhc2Vz IHN1Y2ggYXMgDQo+Pj4gZGVtYW5kDQo+Pj4gLcKgwqDCoMKgICrCoMKgwqDCoMKgwqAgcGFn aW5nLCBjYWNoZS1mbHVzaGluZyBvcHRpbWl6YXRpb25zLCBtZW1vcnkgYWNjZXNzIA0KPj4+ IHRyYWNraW5nLGV0Yy4NCj4+PiAtwqDCoMKgwqAgKg0KPj4+IC3CoMKgwqDCoCAqwqDCoMKg wqDCoMKgIFRvIHN1cHBvcnQgdGhlIG1vcmUgZ2VuZXJhbCBjYXNlIGFuZCB0aGUgb3B0aW1p emF0aW9ucyANCj4+PiBtZW50aW9uZWQNCj4+PiAtwqDCoMKgwqAgKsKgwqDCoMKgwqDCoCBh Ym92ZSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHN0b3Agc2V0dGluZyB0aGUgQS9EIGJpdHMg DQo+Pj4gaGVyZSBhbmQNCj4+PiAtwqDCoMKgwqAgKsKgwqDCoMKgwqDCoCBpbnN0ZWFkIGhh bmRsZSBwYWdlIGZhdWx0cyB0aGF0IG9jY3VyIGR1ZSB0byB1bnNldCBBL0QgDQo+Pj4gYml0 cy4NCj4+PiArwqDCoMKgwqAgKiBYZW4gc3VwcG9ydHMgYm90aCwgc28gc2V0ICdBJyBhbmQg J0QnIHVwIGZyb250IHRvIGF2b2lkIHRoZSANCj4+PiBmYXVsdHMNCj4+PiArwqDCoMKgwqAg KiBvZiAoMikuIFRoaXMgaXMgaGFybWxlc3Mgd2l0aCAoMSk6IHNvZnR3YXJlIGp1c3QgZG9l cyB3aGF0IA0KPj4+IGhhcmR3YXJlDQo+Pj4gK8KgwqDCoMKgICogd291bGQgaGF2ZSBkb25l IG9uIGZpcnN0IGFjY2Vzcy4NCj4+PiDCoMKgwqDCoMKgwqAgKi8NCj4+PiAtwqDCoMKgIGlm ICggcmlzY3ZfaXNhX2V4dGVuc2lvbl9hdmFpbGFibGUoTlVMTCwgUklTQ1ZfSVNBX0VYVF9z dmFkZSkgKQ0KPj4+IC3CoMKgwqDCoMKgwqDCoCBlLT5wdGUgfD0gUFRFX0FDQ0VTU0VEIHwg UFRFX0RJUlRZOw0KPj4+ICvCoMKgwqAgZS0+cHRlIHw9IFBURV9BQ0NFU1NFRCB8IFBURV9E SVJUWTsNCj4+DQo+PiBPbiB0aGUgY29kZSBjaGFuZ2UgaXRzZWxmLCBpdCBsb29rcyBnb29k IHRvIG1lLCBhcyB3ZSBkb24ndCBtYWtlIHVzZSANCj4+IG9mIEEvRCBiaXQgYW55d2F5IChh bmQgaW4gY2FzZSB3ZSB3b3VsZCBuZWVkIHRvLCB3ZSB3b3VsZCBuZWVkIHRvIA0KPj4gY2xl YXIgdGhlbSBhbnl3YXkpLg0KPj4NCj4+PiDCoCDCoMKgwqDCoMKgIHN3aXRjaCAoIHQgKQ0K Pj4+IMKgwqDCoMKgwqAgew0KPj4+DQo+Pg0KPiANCg0K --------------rS8oI0PpMQN9AOKUU04WK8nI-- --------------WYCOH5lZIV0R4buNC0zn0Emm 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+p0QLLz9AFAmrGDTEFAwAAAAAACgkQZg+p0QLLz9Bu zAv/dk6nWEtlFzVa3iF8tElJTyNsFu7yf/OU1fMOej8Regxjg7pRuoRaO1+6qWBmZiYIImm6OTAT D1dV9i07esU+lRzT3mllYciiA/GZ+oK8Ui3lh+AijSTYLbdrjVC1pJ+xFUfilaX/hu5Zzviy4r0P NySghEEKsJyb3wDf0yI7d7KIybRMfsMnVRCqNDiIAmiKm7Liq+e2x8LIGtknqud3+RELHoDA9TqQ 2OJoPYxqD54MCe0mOsEvQ1xQ2ODj0FxYcrZ3ggSIkOb6Vt1VXO9ZUQgkIXjqJnm6N/PcyexWMqb8 vqNCI5ZXp1chfyhNJNbuiX67mDMkBHyxhwOUeNRj8YmQKHpUL2jDbxCyLTYjmKRpO4SlvkmBYFjt V1eSVc1TAhF0gmBZMjZ10t2UM0LOkgEg1yn7ex2tC2NOOEW8V1KLJTh1k7KdvNIsGbbY9rYwf7qD XQ7TmRItWlPMXGNG5tg39eKt74WSYVwyNe/fEUP4vb6zqGq1mw7CAvR2FxrU =PK7C -----END PGP SIGNATURE----- --------------WYCOH5lZIV0R4buNC0zn0Emm-- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:03:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:03:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442081.1659611 (Exim 4.92) (envelope-from ) id 1xEOUo-00005u-Od; Wed, 07 Oct 2026 10:03:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442081.1659611; Wed, 07 Oct 2026 10:03: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 1xEOUo-00005n-Lq; Wed, 07 Oct 2026 10:03:34 +0000 Received: by outflank-mailman (input) for mailman id 1442081; Wed, 07 Oct 2026 10:03:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEOUn-00005f-Qj for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:03:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEOUl-00HIUO-Qg for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:03:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac618a3-8faa-0a2a0a5109dd-0a2a4504b4d6-34 for ; Wed, 07 Oct 2026 12:03:31 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac618f3-b57f-0a2a45040019-d1558030e0f4-3 for ; Wed, 07 Oct 2026 12:03:31 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a1635f7c89so37257915e9.2 for ; Wed, 07 Oct 2026 03:03: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-4a17f51beffsm59968245e9.2.2026.10.07.03.03.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 03:03: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=1791367411; x=1791972211; 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=yOGoC8k/+o27Ntp+OuBXBAJ0vJdmg5oYVfJKR3ii81E=; b=Lw4kp9te/Y/91DwJzGlsj5ZKX1R6ur8Nfa6rtjpSisJ6Ern46z+TXkov+eCsFBC1pX AYAGMZlqL5dnv2y7+uMPUO1UWU4TIwARC7DOB+1DeC1oYGZxl0ltEzRD2NmkQaeFy5FJ N5rqPw6EpqQgNf3sxIlsTtvHukI7+/qcCMsH8dGBI6bwr77i81wullSiQegCC1k2Ts4J MWau6hCbqUYa54nT+Qr6mlXtYvNOqhFGFpZInEOefW033LUH4ThZ4KPgiShhQxP8H9Zy bB5ex0KNBdWk4vBQFYJiyEIJm4VokWTrm/cJ1BWPgp1KXr7l9tg/XpUJrq6gacunENTz 0xOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791367411; x=1791972211; 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=yOGoC8k/+o27Ntp+OuBXBAJ0vJdmg5oYVfJKR3ii81E=; b=ObHSppOLe7EG5IHVP8cUKns89XyGZlybmHLu5WVP36GagOUvi9Vj15AS0yA043NlFn z2PAaJhyf0n/NtDtQZ8oi+XlxpecetGqLfO+O7vnVBX49qEBNccljpFa9fJ+IO3FHdwf ZLZqBEPZbo/GxqEwyqAshs+F9BVU2c3oEHxTZjFM3UhUC5ac7Ezd+vfZ0bxqk1hcQdvO YbRKkvYHHbY53gt0fou+03T8yQGe07xtfPsixekWcKr28ArLGRa2RhGOvXTWzKLO56V8 N5MwxyGFYgnVxuaPfPyhMxvhS/GeIH3dT3P5t0q3FYsdxe8l5ztRv6D6h+erDIRlWy0v fo8g== X-Forwarded-Encrypted: i=1; AKwUvBx7AUw2TUUYlYgitH5bTmj6CSOrycaDPagwH/oIofSPdzlQ9/PmcdRRgf+HHiIMLRKTIXgCDr0KEEk=@lists.xenproject.org X-Gm-Message-State: AFuF++koDz4+kfyyOxMMq66+mDFz6GptkvILiaB1tr5leBuAL8QUekSV 04aaOM9zhaeC1Xhg+fouC2/LJnR9PwzAW2qWN5JVk4kGAUrD6j7bVxA/ X-Gm-Gg: AYBFou2/vgOQBeVF66jHNuKa8wD6lJ/KcO+OX7MiV3c+BngPiStEOloMUE1vU/ES77L 4KILHa2BXbN5YHBqiYCNm5xWvkz6JxQMT71zXBV0C9eiVky8hc4IpCdNVLaKuMiRhVf2wHTE1jt nZllS2LXqIEfO6RJpMWAX6A+a1IF52r2nMQI2pURXKRW2aSj5tOJOjUFy8WgdvbdEmm+fwiEuif d1+gq3ofuQl1QPndcj6fD8IMIlxYDPpMcWKdKNWlYfGXzjOG7vTPoBjNCgc00g6cGRiLS6wBSuD AxrC6pR3prTPcuDm22JUxpilu1Y00N0LuAgxB7DUUkGlGaT0NlxifDH4o0bUnLL0N7dwobz6XFE 6P8uvGlRhoJFqc0t/vr80wNC/1s7pxJOUg5XYuxBBfEcuwCVxIVADEXyuQpClKFT4iSO8c9kwv+ 5n3UIvuWxG/rFzvvIb+JvmI8AajWSdOwlvbwCLZOtgnRdClInzdA/3lmZVzdQlEnZDjg3tXTEOq M0YUrQ4y6je5we+rVdMxNoUYRUw53ntLNTmJ7T1LR55r8fNLg== X-Received: by 2002:a05:600c:64c6:b0:49f:fe90:de63 with SMTP id 5b1f17b1804b1-4a180455e85mr26206385e9.28.1791367410728; Wed, 07 Oct 2026 03:03:30 -0700 (PDT) Message-ID: <4a0b0d62-c312-43c1-908a-fcff7c081149@gmail.com> Date: Wed, 7 Oct 2026 12:03:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Jan Beulich , Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791367411-C3CC7B50-BD3B2A75/10/73395122804 X-purgate-type: spam X-purgate-size: 8534 On 10/6/26 5:20 PM, Jan Beulich wrote: > On 05.10.2026 18:00, Baptiste Le Duc wrote: >> A RISC-V implementation can manage the PTE A/D bits in one of two ways: >> 1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). >> 2) Generate a page fault when 'A' and/or 'D' is clear, so that software >> can set them (ratified as Svade). >> >> p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device tree >> advertises Svade. According to the code it seems like it is setting A/D bits always independently on what is DT file. Baptiste, am I missing something? Platforms that use scheme (2) without advertising Svade, >> such as the HiFive Premier P550, then hit guest-page faults that Xen does >> not handle. > > Is that a quirk then (to avoid the word "bug")? Since it's all DT that > conveys available ISA information, why can't the DT for those systems > simply be fixed? Depending on the answer here I might question the > presence of the Fixes: tag below. I think it can at some point. Let me clarify why "at some point"... So how the things are working now: OpenSBI detects the available ISA extensions in two steps: 1. It parses the CPU nodes in the DTB. If a node has the riscv,isa-extensions property, OpenSBI uses it; otherwise it falls back to riscv,isa. riscv,isa-extensions describes the same extensions as riscv,isa, but as a list of strings, which makes it easier to parse. From this, OpenSBI builds a per-hart bitmap of available extensions (basically what we do in Xen). (Platform-specific code can also add extensions to the bitmap at this step.) 2. It then probes a small, fixed set of extensions (Sstc, Smaia, Sscofpmf, Smstateen, Ssstateen, Smcntrpmf, Sdtrig) by reading a CSR that the extension introduces and checking whether the access traps. This is similar to what we do for Sstc in Xen. Step 2 only adds extensions to the bitmap. It does not check or clear the extensions that came from the DT; the only exception is Zicntr, which is detected purely by probing. So for extensions such as Svade/Svadu, which have no CSR to probe, the DT is the only source of truth. Now, what OpenSBI does with Svade/Svadu specifically. First, it disables hardware A/D updating by default, i.e. it clears menvcfg.ADUE: Now, what OpenSBI does with Svade/Svadu specifically. First, it disables hardware A/D updating by default, i.e. it clears menvcfg.ADUE: /* Disable HW A/D updating by default */ menvcfg_val &= ~ENVCFG_ADUE; Then it sets ADUE again, depending on which extensions are listed in the DTB: /* * Assume only Svadu is supported when it is the only extension * present in the ISA string. Svade is assumed when neither are * present. When both are present we must default to Svade (see * the zero reset value of FWFT.PTE_AD_HW_UPDATING). */ if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE)) __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE); So all OpenSBI does is set or clear menvcfg.ADUE based on what is mentined in DTB. So, to answer your original question: yes, this can be fixed just by updating the DTS. OpenSBI will then configure menvcfg.ADUE according to the extensions listed there. Note that the logic above is from OpenSBI v1.9. Versions v1.5–v1.8 behave the same when the DT lists only svadu, only svade, or both. When neither is listed, they leave ADUE unchanged instead of clearing it. Versions before v1.5 don't handle Svade/Svadu at all. But IIRC such approach was suggested in one of vX and it was rejected because we can't in Xen be sure that passed DTB is correct and corresponds to how real h/w is configured as specifically with ADUE bit in menvcfg we can't read it in HS-mode as an exception will occur as it is M-mode register. So we have to trust that OpenSBI (or other firmware will configure the A/D update scheme according to what is mentioned in DTS). So then basically the question is do we want to rely on that how OpenSBI configures h/w? It seems like it could be fine. For example, without support for the FWFT extension, we can't access or change the menvcfg bit anyway. The FWFT extension was ratified in 2025, so we have to trust OpenSBI anyway (or introduce our own extension or port the FWFT extension to an earlier OpenSBI version) before FWFT is started to be available. With this explanation would you (Jan) be okay to go with just providing proper DTS? > >> Always preset A/D in G-stage PTEs so scheme (2) never faults. This is >> harmless with (1): software just does what hardware would have done on >> first access. >> >> Drop the TODO suggesting to handle A/D faults: only Svade raises them, so > > This contradicts the earlier paragraph, where you say that page faults can > also occur without Svade. > >> it would not work on Svadu. Dirty/access tracking can restrict the RWX >> permissions of p2m entries, as x86 and Arm do. > > I'm also not convinced that this is what the TODO was after. Oleksii would > be able to clarify, I suppose. I think the TODO below in the code should be added back, as it indicates that something needs to be changed if (or when) we decide to support tracking of the A/D bits. ~ Oleksii > >> 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 >> >> --- a/xen/arch/riscv/p2m.c >> +++ b/xen/arch/riscv/p2m.c >> @@ -591,38 +591,16 @@ static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) >> 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. >> + * A RISC-V implementation can either: >> + * 1) Update the 'A' and 'D' PTE bits in hardware. >> + * 2) Generate a page fault when 'A' and/or 'D' is clear, so that >> + * software can set them. >> * >> - * 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. >> - * >> - * 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. >> + * Xen supports both, so set 'A' and 'D' up front to avoid the faults >> + * of (2). This is harmless with (1): software just does what hardware >> + * would have done on first access. > > "Xen supports both" to me means it suitably handles the page faults resulting > with Svade. May I suggest "To support both, set ..."? > >> */ >> - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) >> - e->pte |= PTE_ACCESSED | PTE_DIRTY; >> + e->pte |= PTE_ACCESSED | PTE_DIRTY; >> >> switch ( t ) >> { >> > From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:41:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442102.1659638 (Exim 4.92) (envelope-from ) id 1xEP56-0006LE-4t; Wed, 07 Oct 2026 10:41:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442102.1659638; Wed, 07 Oct 2026 10:41: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 1xEP56-0006Jd-0O; Wed, 07 Oct 2026 10:41:04 +0000 Received: by outflank-mailman (input) for mailman id 1442102; Wed, 07 Oct 2026 10:41:02 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP54-0006Df-DW for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:02 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP54-001biM-0e; Wed, 07 Oct 2026 10:41:02 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP53-001QnT-34; Wed, 07 Oct 2026 10:41: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=3unBXKoSIkkOI4lQHAOOYMO5jJksROtYlSF7H+YURFQ=; b=LusKlcGYZaE+yA7HIQA5d1uH1u tdRg7BXimupG6gKpn7KsvQ/MwUItTUsp4ad0jKfxmaDIrGqMNLuchRdJMifCVMgEAVIkdh9973hrE Dx/LMCkIALELlEOP7pft5tEXJ80sONnS1w9p/T5KkbQCtS4EdF4ds6chHkdi3BxnI8nI=; 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?= , Teddy Astie Subject: [PATCH v3 03/18] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas Date: Wed, 7 Oct 2026 11:40:36 +0100 Message-ID: <20261007104051.48841-4-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 one remaining caller, free_compat_arg_xlat(), is already in a vCPU context, so we just need to change the parameter from a domain pointer to a vCPU pointer. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series): free_compat_arg_xlat() is the only caller left. - Drop the linear-page-table fast path altogether (Jan): its only user would have been guest-driven LDT teardown, and without it the function does not depend on the linear mapping being available. Changes in v2: - Added to the series Changes since the previously posted version: - The fast path is gone (v3), and with it the previously posted version's sync_local_execstate() call. - 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 | 3 ++- xen/arch/x86/x86_64/mm.c | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 2254a7e3fe..b19b1ae53f 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -606,7 +606,7 @@ 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 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 b158742408..769b9b3016 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6334,10 +6334,11 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, return rc; } -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)); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 2a1805964d..8c576acdc7 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -744,7 +744,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 Oct 07 10:41:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442100.1659628 (Exim 4.92) (envelope-from ) id 1xEP55-0006EA-L6; Wed, 07 Oct 2026 10:41:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442100.1659628; Wed, 07 Oct 2026 10:41: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 1xEP55-0006E3-I5; Wed, 07 Oct 2026 10:41:03 +0000 Received: by outflank-mailman (input) for mailman id 1442100; Wed, 07 Oct 2026 10:41:02 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP54-0006DR-1M for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:02 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP53-001bi9-2d; Wed, 07 Oct 2026 10:41:01 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP51-001QnT-2w; Wed, 07 Oct 2026 10:41: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" 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=2RJgLX/T1ocfyreFYfWOaC+F5mQipEttx11jUlqCQM0=; b=tMkIj0NdqAsng2M5MZct4j4SKp t5kSrOztB1EGFXGdlcQNQsrlJhJFG6bstpFNicTIGu24fE0DsX+FVmORPQUxLZkOG2diQqUqCfspd mIO06AozB/lw/DRLWPHaeogU7ko5vwI9QxYAYec2LwR9AHA7x9/Wcgtk8wiefXRAcbHo=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3 01/18] x86/PoD: map one page at a time in p2m_pod_zero_check() Date: Wed, 7 Oct 2026 11:40:34 +0100 Message-ID: <20261007104051.48841-2-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit p2m_pod_zero_check() maps every page of its batch that passes its checks, up to POD_SWEEP_STRIDE (16) of them, and keeps them mapped across the p2m lookups and updates which follow, each of which maps page-table pages of its own. Its callers hold mappings too: the p2m lookup which found the entry to populate still has its page-table page mapped, and a PV mmu_update() the L1 page it is writing. map_domain_page() cannot always provide that many at once. It uses the mapcache on behalf of PV vCPUs only: in debug builds for every page, in release builds for pages beyond the reach of the directmap in PV guests' page-tables (5TiB, 3.5TiB with CONFIG_BIGMEM). The mapcache has MAPCACHE_VCPU_ENTRIES (16) slots per vCPU of the domain, shared by its vCPUs, and a mapping which finds no slot free or reclaimable hits the BUG_ON() in map_domain_page(): the host crashes. The sweep runs in the context of whichever vCPU populates a PoD entry while the domain's PoD cache is empty. The guest's own vCPUs, being HVM, map through the directmap; a PV vCPU gets there when its domain maps or copies the guest's memory: a device model in dom0 or in a stub domain, a backend doing grant copies. A PV domain with a single vCPU, as a device-model stub domain or a dom0 booted with dom0_max_vcpus=1 is, has 16 slots, and a sweep over 16 candidate pages needs more. The sweep has mapped its whole batch at once since 9ad9a1609fbe ("PoD memory 5/9: emergency scan"), when x86-64 reached all memory through the directmap. The per-vCPU budget came with the mapcache's return to x86-64 in 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al"). Map one page at a time instead, as p2m_pod_zero_check_superpage() already does: map a page for the quick check and unmap it again, and map it anew for the full check after the p2m update and the TLB flush. The checks and their order are unchanged. Each page is mapped twice, which costs little next to scanning it, and the error paths no longer have mappings to undo. Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al") Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- NB this issue was raised in review and verified only by code inspection; it hasn't been demonstrated. --- xen/arch/x86/mm/p2m-pod.c | 72 +++++++++++++++++++-------------------- 1 file changed, 35 insertions(+), 37 deletions(-) diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c index 4602c32cff..0b0beca15a 100644 --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -901,7 +901,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { mfn_t mfns[POD_SWEEP_STRIDE]; p2m_type_t types[POD_SWEEP_STRIDE]; - unsigned long *map[POD_SWEEP_STRIDE]; + bool check[POD_SWEEP_STRIDE]; + const unsigned long *map; struct domain *d = p2m->domain; unsigned int i, j, max_ref = 1; @@ -911,7 +912,12 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count if ( paging_mode_shadow(d) ) max_ref++; - /* First, get the gfn list, translate to mfns, and map the pages. */ + /* + * First, get the gfn list, translate to mfns, and pick the pages to + * check. They are mapped one at a time below, as in + * p2m_pod_zero_check_superpage(): a vCPU can hold only a few transient + * mappings at once, and the p2m lookups and updates here need some too. + */ for ( i = 0; i < count; i++ ) { p2m_access_t a; @@ -921,18 +927,17 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count /* * If this is ram, and not a pagetable or a special page, and - * probably not mapped elsewhere, map it; otherwise, skip. + * probably not mapped elsewhere, check it; otherwise, skip. */ - map[i] = NULL; + check[i] = false; if ( p2m_is_ram(types[i]) ) { const struct page_info *pg = mfn_to_page(mfns[i]); - if ( !is_special_page(pg) && - (pg->count_info & PGC_allocated) && - !(pg->count_info & PGC_shadowed_pt) && - ((pg->count_info & PGC_count_mask) <= max_ref) ) - map[i] = map_domain_page(mfns[i]); + check[i] = !is_special_page(pg) && + (pg->count_info & PGC_allocated) && + !(pg->count_info & PGC_shadowed_pt) && + ((pg->count_info & PGC_count_mask) <= max_ref); } } @@ -942,18 +947,24 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count */ for ( i = 0; i < count; i++ ) { - if ( !map[i] ) + if ( !check[i] ) continue; /* Quick zero-check */ + map = map_domain_page(mfns[i]); for ( j = 0; j < 16; j++ ) - if ( *(map[i] + j) != 0 ) - goto skip; + if ( map[j] != 0 ) + break; + unmap_domain_page(map); /* Try to remove the page, restoring old mapping if it fails. */ - if ( p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, + if ( j < 16 || + p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, p2m_populate_on_demand, p2m->default_access) ) - goto skip; + { + check[i] = false; + continue; + } /* * See if the page was successfully unmapped. (Allow one refcount @@ -961,6 +972,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count */ if ( (mfn_to_page(mfns[i])->count_info & PGC_count_mask) > 1 ) { + check[i] = false; + /* * If the previous p2m_set_entry call succeeded, this one shouldn't * be able to fail. If it does, crashing the domain should be safe. @@ -970,14 +983,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { ASSERT_UNREACHABLE(); domain_crash(d); - goto out_unmap; + return; } - - skip: - unmap_domain_page(map[i]); - map[i] = NULL; - - continue; } } @@ -986,22 +993,20 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count /* Now check each page for real */ for ( i = 0; i < count; i++ ) { - if ( !map[i] ) + if ( !check[i] ) continue; - for ( j = 0; j < (PAGE_SIZE / sizeof(*map[i])); j++ ) - if ( *(map[i] + j) != 0 ) + map = map_domain_page(mfns[i]); + for ( j = 0; j < (PAGE_SIZE / sizeof(*map)); j++ ) + if ( map[j] != 0 ) break; - - unmap_domain_page(map[i]); - - map[i] = NULL; + unmap_domain_page(map); /* * See comment in p2m_pod_zero_check_superpage() re gnttab * check timing. */ - if ( j < (PAGE_SIZE / sizeof(*map[i])) ) + if ( j < (PAGE_SIZE / sizeof(*map)) ) { /* * If the previous p2m_set_entry call succeeded, this one shouldn't @@ -1012,14 +1017,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { ASSERT_UNREACHABLE(); domain_crash(d); - out_unmap: - /* - * Something went wrong, probably crashing the domain. Unmap - * everything and return. - */ - for ( i = 0; i < count; i++ ) - if ( map[i] ) - unmap_domain_page(map[i]); + return; } } else -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:41:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442099.1659620 (Exim 4.92) (envelope-from ) id 1xEP52-000619-FQ; Wed, 07 Oct 2026 10:41:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442099.1659620; Wed, 07 Oct 2026 10: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 1xEP52-000612-Ci; Wed, 07 Oct 2026 10:41:00 +0000 Received: by outflank-mailman (input) for mailman id 1442099; Wed, 07 Oct 2026 10:40:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP51-00060w-Eq for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:40:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP51-001bht-0j for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:40:59 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP50-001QnT-3C for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:40: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" 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:To:From; bh=MAkw5G1K3FbvfvIIjecvRR1tqFdb7fcdhV92wmhQAjE=; b=OGL6eKRS8BOPr6hXX3OcKKHozG SVmZ07YFN7NGjafcx8wsJHjPsQLsFqxCWDAZCJXpDGRTLoL/pVFMap5hmHeOvxWKd7YidZr+LQ9mA xnmVW6ILJQVW0kJzKTyfV5H/LdGFtIp4joaBN1KSk6U/Xb1gF3QT7AuaEqQnYlEdGQXc=; From: George Dunlap To: xen-devel@lists.xenproject.org Subject: [PATCH v3 00/18] ASI: HVM per-vCPU areas and sparse-view directmap Date: Wed, 7 Oct 2026 11:40:33 +0100 Message-ID: <20261007104051.48841-1-gwd@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 In an attempt to reach something useful for XenServer sooner, I've changed the approach somewhat. The previous approach implemented sparse direct-map and intra-domain isolation everywhere, for all types of guests. Implementing intra-domain isolation for PV guests introduces a large amount of complexity, due to the ABI of Xen running on guest pagetables. Start from the other direction instead, and focus just on getting ASI and intra-domain isolation for HVM guests. This series looks like this: - A fix that should be considered for backport (01). - Implement per-vCPU per-domain area and per-vCPU mapcaches for HVM guests. (02-11). This is much simpler since each HVM vcpu already has its own monitor table. - Maintain two "views" of the directmap (12-18): A full directmap, and a sparse directmap. The full directmap is what we have now; the sparse directmap, which removes non-xenheap heap memory. The key patch to get feedback on is patch 13/18. Note that at the end of this series, PV guests can be given the sparse direct-map; this isolates them from other domains, but doesn't isolate vCPUs within a domain. An advantage of this is that it allows us to easily turn the sparse directmap off for dom0 (or other system domains). Some quick tests on my local test rig show that network throughput from dom0 to a guest drops 31% when the sparse directmap is enabled for dom0 vs not. The rest of the series would look like this: - Implement a per-vCPU state area, and move key bits of guest state into it. - Implement per-pCPU stacks. In this mode, per-pCPU stacks would only be for HVM guests using the "sparse directmap". Until we get per-vCPU root pagetables for PV guests, it's not practical to prevent a PV guest from seeing all the stacks. A dependency graph of the above functionality can be found here: https://xenbits.xenproject.org/people/gdunlap/asi-series-deps.html Extending the intra-domain isolation to PV guests would involve implementing per-vCPU root pagetables for PV guests. There are draft implementations of this, but they are quite complicated. George Dunlap (9): x86/PoD: map one page at a time in p2m_pod_zero_check() x86/domain_page: don't unmap a mapcache entry that is not present x86/mm: let Xen's page-table walker operate on a given root x86/mm: build and maintain a sparse view of the directmap x86/domain_page: key the directmap fast paths on the loaded view x86/mm: flush owned pages before reuse with the sparse directmap view x86/domain_page: keep the maphash's slots, not their mappings x86/mm: run guest contexts on the sparse directmap view x86/spec-ctrl: wire the sparse directmap view into the asi= option Roger Pau Monné (9): 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/hvm: introduce per-vCPU L3 page-table x86/domain_page: prepare the mapcache for per-vCPU accounting x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains docs/misc/xen-command-line.pandoc | 49 ++ xen/arch/x86/Kconfig | 1 + xen/arch/x86/Makefile | 1 + xen/arch/x86/domain.c | 21 +- xen/arch/x86/domain_page.c | 311 ++++++++--- xen/arch/x86/hvm/hvm.c | 6 - xen/arch/x86/include/asm/domain.h | 62 ++- xen/arch/x86/include/asm/mm.h | 26 +- xen/arch/x86/include/asm/sparse-directmap.h | 98 ++++ xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/mm.c | 259 +++++++-- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/p2m-pod.c | 72 ++- xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 5 +- xen/arch/x86/pv/dom0_build.c | 6 +- xen/arch/x86/pv/domain.c | 14 +- xen/arch/x86/setup.c | 7 + xen/arch/x86/sparse-directmap.c | 570 ++++++++++++++++++++ xen/arch/x86/spec_ctrl.c | 194 ++++++- xen/arch/x86/x86_64/mm.c | 10 +- xen/common/Kconfig | 18 + xen/common/page_alloc.c | 55 +- xen/include/xen/mm.h | 41 ++ 24 files changed, 1615 insertions(+), 217 deletions(-) create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h create mode 100644 xen/arch/x86/sparse-directmap.c -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:41:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442103.1659647 (Exim 4.92) (envelope-from ) id 1xEP56-0006WS-Me; Wed, 07 Oct 2026 10:41:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442103.1659647; Wed, 07 Oct 2026 10:41: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 1xEP56-0006VA-Gp; Wed, 07 Oct 2026 10:41:04 +0000 Received: by outflank-mailman (input) for mailman id 1442103; Wed, 07 Oct 2026 10:41:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP55-0006Dv-6o for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP55-001biU-0O; Wed, 07 Oct 2026 10:41:03 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP54-001QnT-3A; Wed, 07 Oct 2026 10:41: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" 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=qnQj2VEk2nRRCGqKLbeeB4D2O0uugqBN47xEZ7vScLM=; b=69sijNqB/D1jvpPjMn/yj6zyHe cNpGtNQeMTPuL9suIhR8GXL8J9vjASriTf/Gh3F5bKl572Cv4rEjtUZVje8ClMMI10zGCgUsd+gPb qDKODXMT97MlDWyjLv7E69yp2ONtFP61/ho7jwuTQti8ds1Oc7KeS41RarEB95ef8oUA=; 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?= , Teddy Astie Subject: [PATCH v3 04/18] x86/domain_page: drop redundant create_perdomain_mapping() call Date: Wed, 7 Oct 2026 11:40:37 +0100 Message-ID: <20261007104051.48841-5-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 populating 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. In debug builds, and on hosts with memory hotplug or with more memory than the PV directmap covers, the call was also what first allocated a PV domain's per-domain L3. Release builds on other hosts already allocated it only with the first vCPU. Drop the call; now we always allocate only with the first vCPU. With the only fallible operation gone, mapcache_domain_init() becomes void, and arch_domain_create()'s error handling for it goes away. The per-domain-mapping work in mapcache_vcpu_init() stays where it is rather than moving into mapcache_domain_init() along with this change, ready for a later patch which introduces per-vCPU mapcaches. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series); no functional difference. - Say why the per-vCPU part stays in mapcache_vcpu_init() (Jan). - Say that the call also first allocated a PV domain's per-domain L3 in some builds, which all builds now do with the first vCPU. 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 | 8 ++------ xen/arch/x86/include/asm/domain.h | 2 +- 3 files changed, 4 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 996b50af7a..85cedc3d03 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 72c00194f3..3c90acd2bc 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -223,7 +223,7 @@ void unmap_domain_page(const void *ptr) local_irq_restore(flags); } -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; @@ -232,7 +232,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 + @@ -244,10 +244,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, - NIL(l1_pgentry_t *), NULL); } 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 6cb76781e4..c32dec793a 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 Oct 07 10:41:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442101.1659635 (Exim 4.92) (envelope-from ) id 1xEP55-0006GT-Uu; Wed, 07 Oct 2026 10:41:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442101.1659635; Wed, 07 Oct 2026 10:41: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 1xEP55-0006FP-Od; Wed, 07 Oct 2026 10:41:03 +0000 Received: by outflank-mailman (input) for mailman id 1442101; Wed, 07 Oct 2026 10:41:02 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP54-0006DW-2I for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:02 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP53-001biB-2h; Wed, 07 Oct 2026 10:41:01 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP52-001QnT-30; Wed, 07 Oct 2026 10:41: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=6F4975xROA4Reejah9p3olstS3Fw/yLAgfx1ings2V8=; b=nmlrjvuu3lPXyJn0kGJ9MeqIEV sg9DtgM5em1DTeXrSTinPasdGpSch/Kl1QigB5IDM+SaHf6YbwS+2DcxpFqzjCYD2ZI+srlGZphO4 2QgwM//vGv8UvussFgbA258MQMW903xs/KfYOBXKWQg8H17b8oiudJFwgRaubM6Hteb0=; 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?= , Teddy Astie Subject: [PATCH v3 02/18] x86/mm: purge unneeded destroy_perdomain_mapping() Date: Wed, 7 Oct 2026 11:40:35 +0100 Message-ID: <20261007104051.48841-3-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 at both of its call sites. arch_domain_destroy() unconditionally calls free_perdomain_mappings(), which tears down the same entries and additionally frees the page-table structures; and the other caller, the error path of pv_domain_initialise(), returns into arch_domain_create()'s failure path, which invokes free_perdomain_mappings() as well. One vCPU-scoped caller, pv_destroy_gdt_ldt_l1tab(), is covered the same way: a vCPU is only ever destroyed together with its domain, or on the failure path of creating it, and both routes end in free_perdomain_mappings(); the GDT/LDT slots hold no area-owned pages, so there is nothing else for the call to do. While we're getting rid of unneccessary callers, drop this one too. Note that free_compat_arg_xlat() keeps its explicit teardown: in addition to vCPU teardown, it serves switch_compat()'s undo path, where the domain lives on as a 64-bit one and the argument-translation pages have to go. Add a comment to make sure it isn't missed. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Changes in v3: - Note that pv_domain_destroy()'s other call site, the error path of pv_domain_initialise(), is covered the same way (Jan). - Also drop pv_destroy_gdt_ldt_l1tab(), the per-vCPU teardown call (Jan), and comment on why free_compat_arg_xlat() keeps its own. The Reviewed-by tags given for the previous form are dropped. 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 | 10 ---------- xen/arch/x86/x86_64/mm.c | 5 +++++ 3 files changed, 5 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 192309c2fc..3924c1b204 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 03262a4952..07ea4bb4d2 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -332,12 +332,6 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) NULL); } -static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) -{ - destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v), - 1U << GDT_LDT_VCPU_SHIFT); -} - void pv_vcpu_destroy(struct vcpu *v) { if ( is_pv_32bit_vcpu(v) ) @@ -346,7 +340,6 @@ void pv_vcpu_destroy(struct vcpu *v) release_compat_l4(v); } - pv_destroy_gdt_ldt_l1tab(v); XFREE(v->arch.pv.trap_ctxt); } @@ -394,9 +387,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); FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 8eadab7933..2a1805964d 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -737,6 +737,11 @@ int setup_compat_arg_xlat(struct vcpu *v) NULL, NIL(struct page_info *)); } +/* + * Besides vCPU teardown, which free_perdomain_mappings() would cover, this + * serves switch_compat()'s undo path: the domain lives on as a 64-bit one + * there, so the translation area has to go right away. + */ void free_compat_arg_xlat(struct vcpu *v) { destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v), -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:41:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442104.1659663 (Exim 4.92) (envelope-from ) id 1xEP57-00070b-Uz; Wed, 07 Oct 2026 10:41:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442104.1659663; Wed, 07 Oct 2026 10:41: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 1xEP57-0006zE-Q0; Wed, 07 Oct 2026 10:41:05 +0000 Received: by outflank-mailman (input) for mailman id 1442104; Wed, 07 Oct 2026 10:41:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP56-0006VT-I5 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:04 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP56-001bid-0Y; Wed, 07 Oct 2026 10:41:04 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP55-001QnT-31; Wed, 07 Oct 2026 10:41: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=YN/PwYdSyq7VIT0fmDEyLm8kDVbqAXggB4l9ZiyBJMg=; b=RkBIxN5W8+L9JPPHukfY1G4qdh Q48ollnxvI89JXACHnR91jF1kUTQ5a1Da4URTfytAyTeXBA823JWKVUpKLmApnc1N6ZNW2otEL1ot e8mY91fd61hIloJ33EmNx/MYl3uCYEI0iGcaCEeBs9+vtmO0r3Gz85ZOrGMnzVAEi6d4=; 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?= , Teddy Astie Subject: [PATCH v3 05/18] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas Date: Wed, 7 Oct 2026 11:40:38 +0100 Message-ID: <20261007104051.48841-6-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 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, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series): the capture parameters stay, as the PV GDT/LDT stash still uses them. 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 | 3 ++- xen/arch/x86/pv/domain.c | 2 +- xen/arch/x86/x86_64/mm.c | 2 +- 7 files changed, 18 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 85cedc3d03..b670cea52b 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, NULL, NULL); + 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 3c90acd2bc..9119f735f5 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -260,15 +260,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, + int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, NIL(l1_pgentry_t *), NULL); /* Populate bit maps. */ if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse, + rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse, nr, NULL, NIL(struct page_info *)); if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage, + rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage, nr, NULL, NIL(struct page_info *)); if ( rc ) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 3924c1b204..5572728db3 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, NULL, NULL); - 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 b19b1ae53f..87bbe1a6f5 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -603,7 +603,7 @@ 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, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, l1_pgentry_t **pl1tab, struct page_info **ppg); void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 769b9b3016..ca22107cd3 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6211,10 +6211,11 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e) (_PAGE_PRESENT | _PAGE_AVAIL0); } -int create_perdomain_mapping(struct domain *d, unsigned long va, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, l1_pgentry_t **pl1tab, struct page_info **ppg) { + 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 07ea4bb4d2..9877771cd4 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -326,7 +326,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, v->domain->arch.pv.gdt_ldt_l1tab, NULL); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 8c576acdc7..0f9e0469ef 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), NULL, NIL(struct page_info *)); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:41:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442105.1659673 (Exim 4.92) (envelope-from ) id 1xEP59-0007Jz-Cu; Wed, 07 Oct 2026 10:41:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442105.1659673; Wed, 07 Oct 2026 10:41: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 1xEP59-0007Jp-9g; Wed, 07 Oct 2026 10:41:07 +0000 Received: by outflank-mailman (input) for mailman id 1442105; Wed, 07 Oct 2026 10:41:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP58-0007BF-Fw for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:06 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP57-001bin-1w; Wed, 07 Oct 2026 10:41:05 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP57-001QnT-1B; Wed, 07 Oct 2026 10:41: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=iRGNOpRPWzouzTTqvxlO4hygSWei2nMKlmUXT9MAbQg=; b=4Hr+ztIwSfu28djVniEge4dP0f xKdXcJiuOmQymV/YnDTvZYGHn0L2DQLJKr9J3p1SkClvhDd/0QhVx7V0Zc7y8570iUjpChHtGIWUR 0IFAdwzbcDM/DaKkAnvGI78RymaiqNjsIf8io/93cfZG2a3zgfKsk4gjpaHDxMPKB2K4=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Teddy Astie Subject: [PATCH v3 06/18] x86/spec-ctrl: introduce Address Space Isolation command line option Date: Wed, 7 Oct 2026 11:40:39 +0100 Message-ID: <20261007104051.48841-7-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Introduce the `asi=` command line option, and the opt_vcpu_pt_{hwdom,hvm} knobs plus the per-domain d->arch.vcpu_pt setting they control. 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. The mechanisms this option controls apply to HVM domains: an HVM vCPU already runs on its own monitor table, so a per-vCPU per-domain area needs no work at context switch. d->arch.vcpu_pt is therefore only ever set for HVM domains, a PVH hardware domain included; PV domains, a PV hardware domain included, are unaffected. The boot log gains "ASI features for ..." lines for Dom0 and HVM domains, so hardware-domain-only configurations remain visible. 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, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - HVM only: drop the PV knob and its interaction with XPTI. vCPU-PT applies to HVM domains and to a PVH hardware domain; the Dom0 boot log line says None for a PV one. Changes in v2: - Added to the series Changes since the previously posted version: - Include the hardware domain in the development warning and the boot log summary. - Make the opt_vcpu_pt_* knobs plain booleans preinitialised to false, dropping the late -1 resolution. - Documentation: mention possible protection against unmitigated attacks, and state that hvm= does not affect the hardware domain. - Rewrite the commit message. --- docs/misc/xen-command-line.pandoc | 26 +++++++++ xen/arch/x86/include/asm/domain.h | 6 +++ xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/spec_ctrl.c | 79 ++++++++++++++++++++++++++++ 4 files changed, 113 insertions(+) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index b2c94ae56d..785e099c0a 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -202,6 +202,32 @@ 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 [ , hvm=, vcpu-pt= | vcpu-pt=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. + +The mechanisms currently implemented apply to HVM guests, including a PVH +hardware domain. PV guests, including a PV hardware domain, are unaffected. + +* `hvm=` enables the features for HVM guests other than 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` gives each vCPU its own per-domain area: the per-domain slot of + each vCPU's monitor table maps a region private to that vCPU. + ### asid (x86) > `= ` diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index c32dec793a..b192c86bc1 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -477,6 +477,12 @@ struct arch_domain /* Don't unconditionally inject #GP for unhandled MSRs. */ bool msr_relaxed; + /* + * Give each vCPU its own per-domain area (HVM only: each vCPU already + * runs on its own monitor table). + */ + 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..b62229ab5d 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_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..999e41aefa 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -86,6 +86,13 @@ bool __ro_after_init opt_bp_spec_reduce = true; static bool __initdata opt_ibpb_alt; +/* + * Give each vCPU of an HVM domain its own per-domain area (vCPU-PT). Off by + * default until the feature is complete. + */ +bool __ro_after_init opt_vcpu_pt_hvm; +bool __ro_after_init opt_vcpu_pt_hwdom; + static int __init cf_check parse_spec_ctrl(const char *s) { const char *ss; @@ -487,6 +494,62 @@ 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_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_hwdom = opt_vcpu_pt_hvm = val; + break; + + default: + 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_hwdom = opt_vcpu_pt_hvm = val; + break; + + case -2: + s += strlen("vcpu-pt="); + 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 +743,14 @@ static void __init print_details(enum ind_thunk thunk) opt_pv_l1tf_hwdom ? "enabled" : "disabled", opt_pv_l1tf_domu ? "enabled" : "disabled"); #endif + + /* vCPU-PT is implemented for HVM only: a PV Dom0 gets none of it. */ + printk(" ASI features for Dom0:%s\n", + opt_dom0_pvh && opt_vcpu_pt_hwdom ? " vCPU-PT" : " None"); +#ifdef CONFIG_HVM + printk(" ASI features for HVM VMs:%s\n", + opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); +#endif } static bool __init check_smt_enabled(void) @@ -1866,6 +1937,9 @@ 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 = !pv && (is_hardware_domain(d) ? opt_vcpu_pt_hwdom + : opt_vcpu_pt_hvm); } void __init init_speculation_mitigations(void) @@ -2158,6 +2232,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_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 Oct 07 10:41:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442106.1659682 (Exim 4.92) (envelope-from ) id 1xEP5B-0007cF-L3; Wed, 07 Oct 2026 10:41:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442106.1659682; Wed, 07 Oct 2026 10:41: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 1xEP5B-0007bw-HU; Wed, 07 Oct 2026 10:41:09 +0000 Received: by outflank-mailman (input) for mailman id 1442106; Wed, 07 Oct 2026 10:41:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP5A-0007Tq-3D for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP5A-001bj0-01; Wed, 07 Oct 2026 10:41:08 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP59-001QnT-2n; Wed, 07 Oct 2026 10:41: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=dhqUQmvZLvbJ486b5VhpqBi7A5iX71jVcCO1Kn2eJgk=; b=Oux8bGxlk0zuVswcqf2KM8B1xF qPJZf1b1rdYN1TRjZZy7yzL/qU9OLjTt2xD/bE79ikYVkc4o3Tpip4VDlmqIju3EeWbuxlzRr7rVj fqjl3Bo3eE+S/kuzK5eQxi9TJTUUgvsSsf530NRrAolbf6TMQQJtCtrI6zPL6EOFyA1Y=; 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?= , Teddy Astie Subject: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting Date: Wed, 7 Oct 2026 11:40:41 +0100 Message-ID: <20261007104051.48841-9-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Currently, only PV domains have a mapcache, which is domain-wide one. In preparation for enabling per-vCPU mapcaches for HVM domains, split the accounting out into a struct mapcache, embedded in struct mapcache_domain. Introduce has_mapcache(), for whether a vCPU has a mapcache, and vcpu_mapcache(), which returns the accounting for a vCPU's mapcache and, in *dcache, the domain-wide mapcache whose lock and TLB epoch the caller has to take into account. For now has_mapcache() is is_pv_vcpu(), and vcpu_mapcache() always returns the domain's accounting. map_domain_page() and unmap_domain_page() stop repeating the is_pv_vcpu() check mapcache_current_vcpu() has made. Move map_domain_page()'s handling of the domain-wide lock and TLB epoch into three helpers: mapcache_lock() takes the lock and catches up with a wrap another vCPU caused, mapcache_new_epoch() starts a new epoch after a wrap, and mapcache_unlock() drops the lock. A per-vCPU mapcache can then skip them without map_domain_page() being re-indented. struct mapcache_domain keeps its size (40 bytes, x86_64 debug build), and so do the structures containing it. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 155 ++++++++++++++++++++---------- xen/arch/x86/include/asm/domain.h | 19 ++-- 2 files changed, 116 insertions(+), 58 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 9119f735f5..5d90f77bed 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -18,17 +18,23 @@ #include #include +/* + * Whether v has a mapcache: PV vCPUs (whose domain-wide mapcache may still be + * disabled, see mapcache_domain_init()). HVM vCPUs reach everything through + * the directmap, which covers all physical address space for them. + */ +static bool has_mapcache(const struct vcpu *v) +{ + return is_pv_vcpu(v); +} + static inline struct vcpu *mapcache_current_vcpu(void) { struct vcpu *v = this_cpu(pgtable_vcpu); struct vcpu *curr = current; - /* - * During early boot pgtable_vcpu is not set, callers must handle NULL. - * Non-PV domains don't have a mapcache, the directmap covers all physical - * address space. - */ - if ( !v || !is_pv_vcpu(v) ) + /* During early boot pgtable_vcpu is not set, callers must handle NULL. */ + if ( !v || !has_mapcache(v) ) return NULL; /* @@ -54,6 +60,55 @@ static inline struct vcpu *mapcache_current_vcpu(void) return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } +/* + * The accounting for v's mapcache: the domain's, with *dcache set so the + * caller takes the domain-wide lock and TLB-epoch machinery into account. + */ +static struct mapcache *vcpu_mapcache(struct vcpu *v, + struct mapcache_domain **dcache) +{ + struct domain *d = v->domain; + + *dcache = &d->arch.pv.mapcache; + return &(*dcache)->cache; +} + +/* + * The domain-wide mapcache's lock and TLB-epoch machinery, taken around + * allocating a slot: the domain's vCPUs share the mapcache's slots, and each + * catches up with a wrap another one caused, flushing its TLB if it has not + * been flushed since. + */ +static void mapcache_lock(struct mapcache_domain *dcache, + struct mapcache_vcpu *vcache) +{ + spin_lock(&dcache->lock); + + /* Has some other CPU caused a wrap? We must flush if so. */ + if ( unlikely(dcache->epoch != vcache->shadow_epoch) ) + { + vcache->shadow_epoch = dcache->epoch; + if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) ) + { + perfc_incr(domain_page_tlb_flush); + flush_tlb_local(); + } + } +} + +/* A wrap has just flushed this CPU's TLB: start a new epoch. */ +static void mapcache_new_epoch(struct mapcache_domain *dcache, + struct mapcache_vcpu *vcache) +{ + vcache->shadow_epoch = ++dcache->epoch; + dcache->tlbflush_timestamp = tlbflush_current_time(); +} + +static void mapcache_unlock(struct mapcache_domain *dcache) +{ + spin_unlock(&dcache->lock); +} + #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) #define MAPCACHE_L2_ENTRIES (mapcache_l2_entry(MAPCACHE_ENTRIES - 1) + 1) #define MAPCACHE_L1ENT(idx) \ @@ -66,6 +121,7 @@ void *map_domain_page(mfn_t mfn) struct vcpu *v; struct mapcache_domain *dcache; struct mapcache_vcpu *vcache; + struct mapcache *cache; struct vcpu_maphash_entry *hashent; #ifdef NDEBUG @@ -74,12 +130,12 @@ void *map_domain_page(mfn_t mfn) #endif v = mapcache_current_vcpu(); - if ( !v || !is_pv_vcpu(v) ) + if ( !v ) return mfn_to_virt(mfn_x(mfn)); - dcache = &v->domain->arch.pv.mapcache; + cache = vcpu_mapcache(v, &dcache); vcache = &v->arch.pv.mapcache; - if ( !dcache->inuse ) + if ( !cache->inuse ) return mfn_to_virt(mfn_x(mfn)); perfc_incr(map_domain_page_count); @@ -90,41 +146,30 @@ void *map_domain_page(mfn_t mfn) if ( hashent->mfn == mfn_x(mfn) ) { idx = hashent->idx; - ASSERT(idx < dcache->entries); + ASSERT(idx < cache->entries); hashent->refcnt++; ASSERT(hashent->refcnt); ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn)); goto out; } - spin_lock(&dcache->lock); - - /* Has some other CPU caused a wrap? We must flush if so. */ - if ( unlikely(dcache->epoch != vcache->shadow_epoch) ) - { - vcache->shadow_epoch = dcache->epoch; - if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) ) - { - perfc_incr(domain_page_tlb_flush); - flush_tlb_local(); - } - } + mapcache_lock(dcache, vcache); - idx = find_next_zero_bit(dcache->inuse, dcache->entries, dcache->cursor); - if ( unlikely(idx >= dcache->entries) ) + idx = find_next_zero_bit(cache->inuse, cache->entries, cache->cursor); + if ( unlikely(idx >= cache->entries) ) { unsigned long accum = 0, prev = 0; /* /First/, clean the garbage map and update the inuse list. */ - for ( i = 0; i < BITS_TO_LONGS(dcache->entries); i++ ) + for ( i = 0; i < BITS_TO_LONGS(cache->entries); i++ ) { accum |= prev; - dcache->inuse[i] &= ~xchg(&dcache->garbage[i], 0); - prev = ~dcache->inuse[i]; + cache->inuse[i] &= ~xchg(&cache->garbage[i], 0); + prev = ~cache->inuse[i]; } - if ( accum | (prev & BITMAP_LAST_WORD_MASK(dcache->entries)) ) - idx = find_first_zero_bit(dcache->inuse, dcache->entries); + if ( accum | (prev & BITMAP_LAST_WORD_MASK(cache->entries)) ) + idx = find_first_zero_bit(cache->inuse, cache->entries); else { /* Replace a hash entry instead. */ @@ -144,19 +189,18 @@ void *map_domain_page(mfn_t mfn) i = 0; } while ( i != MAPHASH_HASHFN(mfn_x(mfn)) ); } - BUG_ON(idx >= dcache->entries); + BUG_ON(idx >= cache->entries); /* /Second/, flush TLBs. */ perfc_incr(domain_page_tlb_flush); flush_tlb_local(); - vcache->shadow_epoch = ++dcache->epoch; - dcache->tlbflush_timestamp = tlbflush_current_time(); + mapcache_new_epoch(dcache, vcache); } - set_bit(idx, dcache->inuse); - dcache->cursor = idx + 1; + set_bit(idx, cache->inuse); + cache->cursor = idx + 1; - spin_unlock(&dcache->lock); + mapcache_unlock(dcache); l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW)); @@ -170,6 +214,7 @@ void unmap_domain_page(const void *ptr) unsigned int idx; struct vcpu *v; struct mapcache_domain *dcache; + struct mapcache *cache; unsigned long va = (unsigned long)ptr, mfn, flags; struct vcpu_maphash_entry *hashent; @@ -179,10 +224,10 @@ void unmap_domain_page(const void *ptr) ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END); v = mapcache_current_vcpu(); - ASSERT(v && is_pv_vcpu(v)); + ASSERT(v); - dcache = &v->domain->arch.pv.mapcache; - ASSERT(dcache->inuse); + cache = vcpu_mapcache(v, &dcache); + ASSERT(cache->inuse); idx = PFN_DOWN(va - MAPCACHE_VIRT_START); mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); @@ -205,7 +250,7 @@ void unmap_domain_page(const void *ptr) hashent->mfn); l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty()); /* /Second/, mark as garbage. */ - set_bit(hashent->idx, dcache->garbage); + set_bit(hashent->idx, cache->garbage); } /* Add newly-freed mapping to the maphash. */ @@ -217,7 +262,7 @@ void unmap_domain_page(const void *ptr) /* /First/, zap the PTE. */ l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); /* /Second/, mark as garbage. */ - set_bit(idx, dcache->garbage); + set_bit(idx, cache->garbage); } local_irq_restore(flags); @@ -239,9 +284,9 @@ void mapcache_domain_init(struct domain *d) 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long))) > MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20)); bitmap_pages = PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)); - dcache->inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE; - dcache->garbage = dcache->inuse + - (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); + dcache->cache.inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE; + dcache->cache.garbage = dcache->cache.inuse + + (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); spin_lock_init(&dcache->lock); } @@ -249,15 +294,23 @@ void mapcache_domain_init(struct domain *d) int mapcache_vcpu_init(struct vcpu *v) { struct domain *d = v->domain; - struct mapcache_domain *dcache = &d->arch.pv.mapcache; + struct mapcache_domain *dcache; + struct mapcache *cache; unsigned long i; - unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; - unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); + unsigned int ents, nr; - if ( !is_pv_vcpu(v) || !dcache->inuse ) + if ( !has_mapcache(v) ) return 0; - if ( ents > dcache->entries ) + cache = vcpu_mapcache(v, &dcache); + if ( !cache->inuse ) + /* Domain-wide mapcache disabled (fully direct-mapped build). */ + return 0; + + ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; + nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); + + if ( ents > cache->entries ) { /* Populate page tables. */ int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, @@ -265,16 +318,16 @@ int mapcache_vcpu_init(struct vcpu *v) /* Populate bit maps. */ if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse, + rc = create_perdomain_mapping(v, (unsigned long)cache->inuse, nr, NULL, NIL(struct page_info *)); if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage, + rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, nr, NULL, NIL(struct page_info *)); if ( rc ) return rc; - dcache->entries = ents; + cache->entries = ents; } /* Mark all maphash entries as not in use. */ diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index a6c6eaf53a..6f5873879e 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -57,6 +57,16 @@ struct trap_bounce { unsigned long eip; }; +struct mapcache { + /* The number of array entries, and a cursor into the array. */ + unsigned int entries; + unsigned int cursor; + + /* Which mappings are in use, and which are garbage to reap next epoch? */ + unsigned long *inuse; + unsigned long *garbage; +}; + #define MAPHASH_ENTRIES 8 #define MAPHASH_HASHFN(pfn) ((pfn) & (MAPHASH_ENTRIES-1)) #define MAPHASHENT_NOTINUSE ((u32)~0U) @@ -73,10 +83,6 @@ struct mapcache_vcpu { }; struct mapcache_domain { - /* The number of array entries, and a cursor into the array. */ - unsigned int entries; - unsigned int cursor; - /* Protects map_domain_page(). */ spinlock_t lock; @@ -84,9 +90,8 @@ struct mapcache_domain { unsigned int epoch; u32 tlbflush_timestamp; - /* Which mappings are in use, and which are garbage to reap next epoch? */ - unsigned long *inuse; - unsigned long *garbage; + /* Accounting of the domain-wide mapcache. */ + struct mapcache cache; }; void mapcache_domain_init(struct domain *d); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:41:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442107.1659687 (Exim 4.92) (envelope-from ) id 1xEP5C-0007fN-1N; Wed, 07 Oct 2026 10:41:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442107.1659687; Wed, 07 Oct 2026 10:41: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 1xEP5B-0007fA-Rz; Wed, 07 Oct 2026 10:41:09 +0000 Received: by outflank-mailman (input) for mailman id 1442107; Wed, 07 Oct 2026 10:41:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP5A-0007aX-Vk for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP59-001biv-08; Wed, 07 Oct 2026 10:41:07 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP58-001QnT-2a; Wed, 07 Oct 2026 10:41: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=dxYHMPntQ+4kmk+nNJUY+2zkq3fsoiDnWTQiSZvrAmg=; b=sEIS1rJ1iqPopni0BxJAmvyFTL A66gDejbvn7BMqOQPgpPVcmtcSnkq2RP9hnvkeIP1Yh79ZDNDeiaOe9QGRsan3grlAGnCNGW4kOjJ Py3/gcQS5h7kt0B1phthmC7HKQ3+0aqZ1kfeOLuV1o0mz84nt5SeM8kPBhrgjf98RlFw=; 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?= , Teddy Astie , Tim Deegan Subject: [PATCH v3 07/18] x86/hvm: introduce per-vCPU L3 page-table Date: Wed, 7 Oct 2026 11:40:40 +0100 Message-ID: <20261007104051.48841-8-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 COMPAT_ARG_XLAT pages, and for PV each vCPU's GDT/LDT window 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. Allow the "per-domain" area to be per-vCPU instead ("VCPU-PT") for HVM domains. HVM monitor tables are already per-vCPU, so this needs nothing at context switch: every monitor table carries its vCPU's own L3 from creation, and the per-vCPU mappings are isolated from other running vCPUs at once. We will later build on this, adding a per-vCPU mapcache and per-vCPU mapped areas, into which we can move the vCPU state mentioned above. 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; PV domains always use the domain-wide one.) In {create,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. Give init_xen_l4_slots() the vCPU a table is private to, and use perdomain_l3() to select the value to install in slot 260 when one is given. The HVM monitor tables and the 32-bit PV Xen-owned L4s pass their vCPU; tables the domain's vCPUs share -- promoted PV guest L4s, PV shadow L4s, and the PV dom0 L4 under construction -- pass NULL and keep the domain-wide L3, which is all a PV domain has. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-fable-5-1, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - HVM only: PV domains keep the domain-wide area, so the PV parts go (the single-vCPU limit, the shadow refusals, the XPTI slot install). init_xen_l4_slots() takes the vCPU as an extra, optional argument rather than in place of the domain, so PV guest L4s, which no vCPU owns, are promoted exactly as before. - Retitle (was: "x86/mm: introduce per-vCPU L3 page-table"). - free_compat_arg_xlat()'s comment names free_pervcpu_mappings() as the teardown for a vCPU-PT domain. Changes in v2: - Added to the series Changes since the previously posted version: - Expand the commit message with the motivation and the design rationale. - 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. - 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. --- xen/arch/x86/domain.c | 10 +++-- xen/arch/x86/include/asm/domain.h | 12 +++++ xen/arch/x86/include/asm/mm.h | 5 ++- xen/arch/x86/mm.c | 73 ++++++++++++++++++++++--------- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 5 ++- xen/arch/x86/pv/dom0_build.c | 2 +- xen/arch/x86/pv/domain.c | 2 +- xen/arch/x86/x86_64/mm.c | 7 +-- 10 files changed, 87 insertions(+), 33 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index b670cea52b..0aba2cca2e 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, NULL, NULL); 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) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index b192c86bc1..a6c6eaf53a 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -335,6 +335,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. */ @@ -691,6 +696,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 87bbe1a6f5..87131dd4bf 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -369,8 +369,10 @@ int devalidate_page(struct page_info *page, unsigned long type, int preemptible); void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d); +struct page_info *perdomain_l3(const struct vcpu *v); void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, - const struct domain *d, mfn_t sl4mfn, bool ro_mpt); + const struct domain *d, const struct vcpu *v, + mfn_t sl4mfn, bool ro_mpt); bool fill_ro_mpt(mfn_t mfn); void zap_ro_mpt(mfn_t mfn); @@ -609,6 +611,7 @@ int create_perdomain_mapping(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 ca22107cd3..7258935528 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1638,6 +1638,17 @@ 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. + */ +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. * @@ -1645,12 +1656,16 @@ static int promote_l3_table(struct page_info *page) * 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. All other parameters are optional and will either fill or zero the - * appropriate slots. Pagetables not shared with guests will gain the + * *l4t. v names the vCPU the table is private to (an HVM monitor table, a + * 32-bit PV vCPU's Xen-owned L4), or is NULL for tables the domain's vCPUs + * share; it is mandatory for a vCPU-PT domain, whose per-domain area is + * per-vCPU. 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 domain *d, const struct vcpu *v, + mfn_t sl4mfn, bool ro_mpt) { /* * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full @@ -1678,8 +1693,11 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW); /* Slot 260: Per-domain mappings. */ + ASSERT(!v || v->domain == d); + ASSERT(v || !d->arch.vcpu_pt); l4t[l4_table_offset(PERDOMAIN_VIRT_START)] = - l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); + l4e_from_page(v ? perdomain_l3(v) : d->arch.perdomain_l3_pg, + __PAGE_HYPERVISOR_RW); /* Slot 4: Per-domain mappings mirror. */ BUILD_BUG_ON(IS_ENABLED(CONFIG_PV32) && @@ -1835,7 +1853,7 @@ static int promote_l4_table(struct page_info *page) if ( !rc ) { init_xen_l4_slots(pl4e, l4mfn, - d, INVALID_MFN, VM_ASSIST(d, m2p_strict)); + d, NULL, INVALID_MFN, VM_ASSIST(d, m2p_strict)); atomic_inc(&d->arch.pv.nr_l4_pages); } unmap_domain_page(pl4e); @@ -6216,7 +6234,7 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va, struct page_info **ppg) { 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; @@ -6225,14 +6243,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); @@ -6242,7 +6263,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))); @@ -6339,16 +6360,16 @@ 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; - 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 ) @@ -6387,16 +6408,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 ) { @@ -6432,10 +6448,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..9fc59f0702 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, d, v, INVALID_MFN, false); unmap_domain_page(l4e); return m4mfn; diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c index e6fb97c4b6..833e378e30 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, d, 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 7f72b4b7b2..b2017c1010 100644 --- a/xen/arch/x86/mm/shadow/multi.c +++ b/xen/arch/x86/mm/shadow/multi.c @@ -974,8 +974,9 @@ 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) && - VM_ASSIST(d, m2p_strict))); + init_xen_l4_slots(l4t, gmfn, d, NULL, smfn, + (!is_pv_32bit_domain(d) && + VM_ASSIST(d, m2p_strict))); unmap_domain_page(l4t); } break; diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index ddeb144b06..bf980eba8c 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, NULL, INVALID_MFN, true); v->arch.guest_table = pagetable_from_paddr(__pa(l4start)); } else diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 9877771cd4..c1611fdcff 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->domain, v, INVALID_MFN, false); unmap_domain_page(l4tab); /* This page needs to look like a pagetable so that it can be shadowed */ diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 0f9e0469ef..baee0a9cfe 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -738,9 +738,10 @@ int setup_compat_arg_xlat(struct vcpu *v) } /* - * Besides vCPU teardown, which free_perdomain_mappings() would cover, this - * serves switch_compat()'s undo path: the domain lives on as a 64-bit one - * there, so the translation area has to go right away. + * Besides vCPU teardown, which the per-domain area's own teardown would + * cover (free_perdomain_mappings(), or free_pervcpu_mappings() for a + * vCPU-PT domain), this serves switch_compat()'s undo path: the domain lives + * on as a 64-bit one there, so the translation area has to go right away. */ void free_compat_arg_xlat(struct vcpu *v) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:41:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:41:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442108.1659693 (Exim 4.92) (envelope-from ) id 1xEP5C-0007oz-LG; Wed, 07 Oct 2026 10:41:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442108.1659693; Wed, 07 Oct 2026 10:41: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 1xEP5C-0007ni-Du; Wed, 07 Oct 2026 10:41:10 +0000 Received: by outflank-mailman (input) for mailman id 1442108; Wed, 07 Oct 2026 10:41:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEP5B-0007ay-40 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:41:09 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEP5B-001bjC-0B; Wed, 07 Oct 2026 10:41:09 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5A-001QnT-2f; Wed, 07 Oct 2026 10:41: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=ZVsDH654BNOr5j/nSB+hEf87XBdvPaHAdCERFcMYZ2E=; b=x/3yVIuNIlXPV+gDEtn/VLKHgC p0rkmckTlK1KK9lAR5ZoqZ4spaxI3w8kUcVLaQC4PMzRDJ9gkGSL8tWLkgjV44lUIx/e4cY1EgDSV CU/6qb00yjdMeKfLmL9XHFnEaz6L08Ga67CeJSkO/rVqMfuAzrwG5Yh1F9Dhfgy17DGg=; 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?= , Teddy Astie Subject: [PATCH v3 09/18] x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu Date: Wed, 7 Oct 2026 11:40:42 +0100 Message-ID: <20261007104051.48841-10-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné struct mapcache_vcpu, the per-vCPU part of the mapcache (the maphash and the vCPU's shadow of the domain's TLB epoch), lives in struct pv_vcpu, as only PV vCPUs have a mapcache. In preparation for implementing mapcaches for HVM domains, move it to struct arch_vcpu: v->arch.pv.mapcache becomes v->arch.mapcache. struct pv_vcpu shrinks from 512 to 376 bytes, and struct vcpu grows from 2880 to 3008 bytes (x86_64, debug build), within its page: from here on HVM vCPUs carry the 136-byte struct mapcache_vcpu too, ahead of its use by those of vCPU-PT domains. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 6 +++--- xen/arch/x86/include/asm/domain.h | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 5d90f77bed..f91ec8a75a 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -134,7 +134,7 @@ void *map_domain_page(mfn_t mfn) return mfn_to_virt(mfn_x(mfn)); cache = vcpu_mapcache(v, &dcache); - vcache = &v->arch.pv.mapcache; + vcache = &v->arch.mapcache; if ( !cache->inuse ) return mfn_to_virt(mfn_x(mfn)); @@ -231,7 +231,7 @@ void unmap_domain_page(const void *ptr) idx = PFN_DOWN(va - MAPCACHE_VIRT_START); mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); - hashent = &v->arch.pv.mapcache.hash[MAPHASH_HASHFN(mfn)]; + hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)]; local_irq_save(flags); @@ -334,7 +334,7 @@ int mapcache_vcpu_init(struct vcpu *v) BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES); for ( i = 0; i < MAPHASH_ENTRIES; i++ ) { - struct vcpu_maphash_entry *hashent = &v->arch.pv.mapcache.hash[i]; + struct vcpu_maphash_entry *hashent = &v->arch.mapcache.hash[i]; hashent->mfn = ~0UL; /* never valid to map */ hashent->idx = MAPHASHENT_NOTINUSE; diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 6f5873879e..cfa24c4e75 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -552,9 +552,6 @@ struct arch_domain struct pv_vcpu { - /* map_domain_page() mapping cache. */ - struct mapcache_vcpu mapcache; - unsigned int vgc_flags; struct trap_info *trap_ctxt; @@ -650,6 +647,9 @@ struct arch_vcpu #define async_exception_state(t) async_exception_state[(t)-1] uint8_t async_exception_mask; + /* map_domain_page() mapping cache. */ + struct mapcache_vcpu mapcache; + /* Virtual Machine Extensions */ union { struct pv_vcpu pv; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:44:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:44:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442154.1659710 (Exim 4.92) (envelope-from ) id 1xEP8p-0002RA-7F; Wed, 07 Oct 2026 10:44:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442154.1659710; Wed, 07 Oct 2026 10:44: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 1xEP8p-0002R3-4F; Wed, 07 Oct 2026 10:44:55 +0000 Received: by outflank-mailman (input) for mailman id 1442154; Wed, 07 Oct 2026 10:44:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEP8o-0002Qx-82 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:44:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEP8n-00HQBU-L9 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:44:53 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6229e-2eae-0a2a0a5409dd-0a2a450abbe2-14 for ; Wed, 07 Oct 2026 12:44:53 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac622a5-f2d2-0a2a450a0019-d155dd2edd77-3 for ; Wed, 07 Oct 2026 12:44:53 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48b03f23305so3343259f8f.1 for ; Wed, 07 Oct 2026 03:44: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-48c71c0b708sm4185375f8f.12.2026.10.07.03.44.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 03:44: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=1791369893; x=1791974693; 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=jALpHFmm/OFAU5+//4GxIdjSbZ+7OUdEp+033IIftcs=; b=B/McBp0ocT9mYMj5nZ1sIakem8o1jRlc4Ao6bVFVhQAyYZIPq0BUDnE+iALYVx+WFT p2hQ6MGnmaNIKViZHwwfwDWX2KN3Y93ARkaitFnLKtxULw6CpfRksKqe4KixNJn5ZJsy VG/vQYB3llpA0YKtRnSLo3G3sLTQHWKLVrebVtsNaJf+cSZtfRIQe+SlSRxez1PbvSIJ FRmmdPy6ZFSSKxtaxb3x4C+XH1uxyZ47luIJ9gqy5vwvTINazlGi3zOix+GUHh5KNU/I 6zg2Vrem/gfCXtTKwMZwWexv9VNV0poEFA6UQeNv+ZAcb553yDvraXSoaI9J6Ydz3fvZ EnSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791369893; x=1791974693; 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=jALpHFmm/OFAU5+//4GxIdjSbZ+7OUdEp+033IIftcs=; b=lUfCSuWymZjyQcKlZdEVkDQ1zmgK2EsjiticG9+hfH9CeOUNphlUE92ArECLdEmz/3 iis6o4qvnMTIheyQ/VvfzkbWOPQZGh62XiJVrAyDKiftbY8dA1B6X+MxhVdAQ4jIrSgA kyGoh5T96/3JYkde/Cnp6S/KuWhNQZiO5nLg2F1uFbZG4XknuolDenVMDtwUzuhX+ATP 2PeXW6UxCRy/DKOor0ISs2Rv4ac855R6qlMCZMTW9oRmDPaGLEe71dR3V9VTUf+ND5QL SOEbcxSzXnOJqprco2NIxgy0nUAcsK9ETE2AQvq7euv1+OYInt40ysifMTlc/sKGChcw Nq5w== X-Forwarded-Encrypted: i=1; AKwUvByD367JTv2leSCL01seyKGYYI1QiCCBnFNMDc45E4PgQ/R8DZmjhT0Ybdfp35TRLO7tQzeVZJTTT6I=@lists.xenproject.org X-Gm-Message-State: AFq9FYJJnOj0W2oqCXdnxUL7MwcYm9kDFSnvBmEsyXe4I3h2fuiQKoKh 7CgdfTxk8o0ncQAE7cQH/l8rcqzwNWpQViua3otO57grUiuoE4XSiA8CiE8CI7Wyaw== X-Gm-Gg: AYBFou133Pt16rET63XmW0WlIyxj1ZQ6Vhw9rybrI13wEvZgqIQZnpxvm815ZyRNVUS c3warIsG9Xwu3kPiDd5kqOS9GOqpHzJbSsJ/sL7PZ4iC4711rxTz1iWZy0Aay2T7bc426DjlOBB qAN9NOhYkEkg5hLQZGvU3GY4rePKvJ+XbQhfimpcKvlgXLKq7gQVOzto+hjz4oHTQ/L2UYElZFU j7A3H/I+mj68pqbD5VV0mo2F06CjSqSkcEejdK28xNUGvrz/Ehq2ZIIwo3dA0T8Gd25RGmWkz+A 7FGKXg8ZvIBHyYvufI0naqVxNfXZEmCCSuseRPcN6Hbwj4V6o6NjWV9t7vnF5OTtB71NRWk8nnG wVSTJ9iCEQQ7kkOfFAj1u8b/THcNW3WwFcF2uEm0nxokVPaKsNhM4ed3p4CA6hPL/DFsQVIyAnS LyEuFGRcimukYqnyoITvOxtabnKwrPgNolCXUjNS58F0fCHkaLXSG2aFFofC+Q0JcMjM1V1LEE+ XOgIB/1Bu1OT5B1VxDHi1fXMrGI6tyFArdjvkbBC63j8M+mdbSXYYMu8JIfLFiqyv1NerN7 X-Received: by 2002:a5d:484f:0:b0:48b:12f:50da with SMTP id ffacd0b85a97d-48c7277c64amr2878088f8f.23.1791369892847; Wed, 07 Oct 2026 03:44:52 -0700 (PDT) Message-ID: <4fa78acf-4de9-48bc-aea8-fed774d80cfa@suse.com> Date: Wed, 7 Oct 2026 12:44:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Oleksii Kurochko Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> <4a0b0d62-c312-43c1-908a-fcff7c081149@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: <4a0b0d62-c312-43c1-908a-fcff7c081149@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1791369893-593C4CFC-7282BDCE/10/78276251493 X-purgate-type: spam X-purgate-size: 5429 On 07.10.2026 12:03, Oleksii Kurochko wrote: > On 10/6/26 5:20 PM, Jan Beulich wrote: >> On 05.10.2026 18:00, Baptiste Le Duc wrote: >>> A RISC-V implementation can manage the PTE A/D bits in one of two ways: >>> 1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). >>> 2) Generate a page fault when 'A' and/or 'D' is clear, so that software >>> can set them (ratified as Svade). >>> >>> p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device tree >>> advertises Svade. > > According to the code it seems like it is setting A/D bits always > independently on what is DT file. Baptiste, am I missing something? > > Platforms that use scheme (2) without advertising Svade, >>> such as the HiFive Premier P550, then hit guest-page faults that Xen does >>> not handle. >> >> Is that a quirk then (to avoid the word "bug")? Since it's all DT that >> conveys available ISA information, why can't the DT for those systems >> simply be fixed? Depending on the answer here I might question the >> presence of the Fixes: tag below. > > I think it can at some point. Let me clarify why "at some point"... > > So how the things are working now: > > OpenSBI detects the available ISA extensions in two steps: > 1. It parses the CPU nodes in the DTB. If a node has the > riscv,isa-extensions property, OpenSBI uses it; otherwise it falls back > to riscv,isa. riscv,isa-extensions describes the same extensions as > riscv,isa, but as a list of strings, which makes it easier to parse. > From this, OpenSBI builds a per-hart bitmap of available extensions > (basically what we do in Xen). (Platform-specific code can also add > extensions to the bitmap at this step.) > 2. It then probes a small, fixed set of extensions (Sstc, Smaia, > Sscofpmf, Smstateen, Ssstateen, Smcntrpmf, Sdtrig) by reading a CSR that > the extension introduces and checking whether the access traps. This is > similar to what we do for Sstc in Xen. > > Step 2 only adds extensions to the bitmap. It does not check or clear > the extensions that came from the DT; the only exception is Zicntr, > which is detected purely by probing. So for extensions such as > Svade/Svadu, which have no CSR to probe, the DT is the only source of truth. > Now, what OpenSBI does with Svade/Svadu specifically. First, it disables > hardware A/D updating by default, i.e. it clears menvcfg.ADUE: > > Now, what OpenSBI does with Svade/Svadu specifically. First, it disables > hardware A/D updating by default, i.e. it clears menvcfg.ADUE: > > /* Disable HW A/D updating by default */ > menvcfg_val &= ~ENVCFG_ADUE; > > Then it sets ADUE again, depending on which extensions are listed in the > DTB: > > /* > * Assume only Svadu is supported when it is the only extension > * present in the ISA string. Svade is assumed when neither are > * present. When both are present we must default to Svade (see > * the zero reset value of FWFT.PTE_AD_HW_UPDATING). > */ > if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE)) > __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE); > > So all OpenSBI does is set or clear menvcfg.ADUE based on what is > mentined in DTB. > > So, to answer your original question: yes, this can be fixed just by > updating the DTS. OpenSBI will then configure menvcfg.ADUE according to > the extensions listed there. Note that the logic above is from OpenSBI > v1.9. Versions v1.5–v1.8 behave the same when the DT lists only svadu, > only svade, or both. When neither is listed, they leave ADUE unchanged > instead of clearing it. Versions before v1.5 don't handle Svade/Svadu at > all. > > But IIRC such approach was suggested in one of vX and it was rejected > because we can't in Xen be sure that passed DTB is correct and > corresponds to how real h/w is configured as specifically with ADUE bit > in menvcfg we can't read it in HS-mode as an exception will occur as it > is M-mode register. So we have to trust that OpenSBI (or other firmware > will configure the A/D update scheme according to what is mentioned in DTS). > > So then basically the question is do we want to rely on that how OpenSBI > configures h/w? > > It seems like it could be fine. For example, without support for the > FWFT extension, we can't access or change the menvcfg bit anyway. The > FWFT extension was ratified in 2025, so we have to trust OpenSBI anyway > (or introduce our own extension or port the FWFT extension to an earlier > OpenSBI version) before FWFT is started to be available. > > With this explanation would you (Jan) be okay to go with just providing > proper DTS? I can't answer this, as I lack details on where the DTS is coming from. So far I thought this was a blob handed to Xen (as kind of a module) at boot. What you say above makes me uncertain about that. If it is a blob as I thought, how difficult is it for people to edit a broken blob, for it to correctly reflect their hardware's capabilities? If that's not "very simple", or if there's concern that people may object to doing such editing, then I think we could (should) go without that. All I then would ask is that the description be clarified a little further (clarifying that absence of both extensions is a valid, albeit historical situation). Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 07 10:52:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 10:52:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442161.1659720 (Exim 4.92) (envelope-from ) id 1xEPFi-0004DE-TZ; Wed, 07 Oct 2026 10:52:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442161.1659720; Wed, 07 Oct 2026 10:52: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 1xEPFi-0004D7-Pk; Wed, 07 Oct 2026 10:52:02 +0000 Received: by outflank-mailman (input) for mailman id 1442161; Wed, 07 Oct 2026 10:52:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEPFh-0004Bw-5c for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 10:52:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEPFg-001Bbe-F3 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:52:00 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6243a-bab6-0a2a0a5309dd-0a2a450c98b8-18 for ; Wed, 07 Oct 2026 12:52:00 +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 6ac6244f-f479-0a2a450c0019-d155802ea9c9-3 for ; Wed, 07 Oct 2026 12:52:00 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49e73611928so12142315e9.1 for ; Wed, 07 Oct 2026 03:52: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-48c71d1ffbcsm4485995f8f.36.2026.10.07.03.51.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 03:51: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=1791370319; x=1791975119; 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=4bE8M2atturKEkKiYTQd+NDT+t5UNdSZHEAESlHSsvo=; b=LFzD59djpiipC/Y6a5e1BP4fYoan2mLHJMUAS/wDloyZX3va0UElCJx6afX4Q5DuPe CLgEIFjlS/pMOImBKH0yWXIjWt/HlRbklsuHGyoLEGpZEI5ZP9Ebp1HKQzPUn10akXWa tSWChyCEa825Q+zGC/4Vs5bAhaxbcBKj40dPpg21xeXkB2YBmqMjaOJ4QTn9IssjAcAd QWIvyxmrcWu4HT49tWRr5YZfxpE2ghaJ7tavcEiGgrO2QwKCvJ1xJN+SWrosYzlOYsfQ VfMvYYU0myavbWKyqF9eVfpH9tB6Vi26qFsRcG6ujaaNSue1xpaAZraNdZTXzDom0ayU trqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791370319; x=1791975119; 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=4bE8M2atturKEkKiYTQd+NDT+t5UNdSZHEAESlHSsvo=; b=0WSdidvi1kNzE9NB7sUq4BOHk8Xca4I+meAnJgIT2aCOmbCHFUPR4dKM9c8zrE4uZ0 RRRfnsnmu4ZGqM5Y5BbcnQ1VLtVeBvR8rUpaMoeaxNPL9K1OxmBkABx4C2d6bB0v1gbA Gwnot/mwjqK4wndgzejNr36fDK0KmeDhSHRHaxaBi29c8y5HrYIlZBWkng5kivKfoGER tb820uvc1Ua4LBKVBikRiSUHWBdhJvszrtXrd6zF8a1m6jLV/6iuEKaJJIdlWiqvXRnI quWI3Y8BDx7MZjLtzVH28KLwqZSCPSmUthiwYRmZ/71KAzbzU9QRc3jCou7LRWsM4YnG rKEg== X-Forwarded-Encrypted: i=1; AKwUvBywgdQ5TvdP43AY6T82717s3SOPaqYe6YKYhNq+QILZZYBg3VkjWTcgbH0nWcJKyhmPTxeF9Ua3W9c=@lists.xenproject.org X-Gm-Message-State: AFuF++kHbzX9mSIzbGDJs+LkgJ445cRMZCFdN17YHvMk/cHLLGOVvFN1 uIYal33faipHI+5RE41suTLs7H+HhB1Tsd98gKyw28rB08pHE8hjoE8POBR2yuEENA== X-Gm-Gg: AYBFou1afgTw+KHp8t8LozTCGCrlHxlMPJs0IAUA5ChD3zNcLE8U4CwowQkKoENa0Ew VP6tLnKxBMRvc0Xw9pBhsMikujeiR6j3cZ8wOZHZzPo/qbEZ8xcsp8zrmLNPPtT5o8a6hgist30 s864W+RTgWyS+E+CbWhIcyFtg00wbL8AEZH5hyifeftqT3D+pGAasfQIW0UkwR0LKzb8V2bynaw kEX/9uJw1Zh5tdBm5bUkfYRrMkVhgQW5UxOFxypCdLGgJfmF3xb5EMGdI3sEyYXU+ctr0WRu3qb hESBX92AtqGlNOKkr3PC6Mdr6Q4ixUeBEVZnPMPMRu7/ZYAaOGhdFeFzQQI0VJWSAYPisN4mVng VkrJuKGuVXsinfU7pkIKEOzOGcL6a64j44I658/ProCcCKrxmhucSB3Xn3AAmzSxwtXyfQv7L/K gWCBfWRpEPZc7WlgO1ipZYn3HVFgX7sXeuo1vRczBB7DdD2DrCHJzH/39+0DSFVn2XCOCLcSNCe OWMszZhgchOUtFo8jnnz9RGsNxBid78JltkF2DHZee/gUagD+de4pAOsf6cOw== X-Received: by 2002:a7b:c7c5:0:b0:4a1:6df8:caa6 with SMTP id 5b1f17b1804b1-4a178a2be2bmr79405205e9.12.1791370319589; Wed, 07 Oct 2026 03:51:59 -0700 (PDT) Message-ID: <6f8521ad-e853-4b07-9916-044e6ed5a1f8@suse.com> Date: Wed, 7 Oct 2026 12:51:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 01/18] x86/PoD: map one page at a time in p2m_pod_zero_check() To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-2-gwd@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: <20261007104051.48841-2-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1791370320-01EC2A5B-A2B11E70/10/78276251493 X-purgate-type: spam X-purgate-size: 2373 On 07.10.2026 12:40, George Dunlap wrote: > p2m_pod_zero_check() maps every page of its batch that passes its > checks, up to POD_SWEEP_STRIDE (16) of them, and keeps them mapped > across the p2m lookups and updates which follow, each of which maps > page-table pages of its own. Its callers hold mappings too: the p2m > lookup which found the entry to populate still has its page-table page > mapped, and a PV mmu_update() the L1 page it is writing. > > map_domain_page() cannot always provide that many at once. It uses the > mapcache on behalf of PV vCPUs only: in debug builds for every page, in > release builds for pages beyond the reach of the directmap in PV guests' > page-tables (5TiB, 3.5TiB with CONFIG_BIGMEM). The mapcache has > MAPCACHE_VCPU_ENTRIES (16) slots per vCPU of the domain, shared by its > vCPUs, and a mapping which finds no slot free or reclaimable hits the > BUG_ON() in map_domain_page(): the host crashes. > > The sweep runs in the context of whichever vCPU populates a PoD entry > while the domain's PoD cache is empty. The guest's own vCPUs, being > HVM, map through the directmap; a PV vCPU gets there when its domain > maps or copies the guest's memory: a device model in dom0 or in a stub > domain, a backend doing grant copies. A PV domain with a single vCPU, > as a device-model stub domain or a dom0 booted with dom0_max_vcpus=1 > is, has 16 slots, and a sweep over 16 candidate pages needs more. > > The sweep has mapped its whole batch at once since 9ad9a1609fbe ("PoD > memory 5/9: emergency scan"), when x86-64 reached all memory through the > directmap. The per-vCPU budget came with the mapcache's return to > x86-64 in 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al"). > > Map one page at a time instead, as p2m_pod_zero_check_superpage() > already does: map a page for the quick check and unmap it again, and > map it anew for the full check after the p2m update and the TLB flush. > The checks and their order are unchanged. Each page is mapped twice, > which costs little next to scanning it, and the error paths no longer > have mappings to undo. > > Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al") > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442171.1659728 (Exim 4.92) (envelope-from ) id 1xEPNr-0005z2-Kr; Wed, 07 Oct 2026 11:00:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442171.1659728; Wed, 07 Oct 2026 11:00: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 1xEPNr-0005yv-I1; Wed, 07 Oct 2026 11:00:27 +0000 Received: by outflank-mailman (input) for mailman id 1442171; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005y4-CP for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNq-001bwE-0E; Wed, 07 Oct 2026 11:00:26 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5F-001QnT-3A; Wed, 07 Oct 2026 10:41: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=TM6vht0L2x66h0TuR6VE5MmWXE909ZBf8rVHG8TYJUE=; b=WOyYOzYsAKYp3mrMUOmh1+fLW6 mX0fITo87iQr26jqqSPOH2gVRr4e8mf17UerDfMSQAP9TKX8LdR6sjnAWT5Txoz9PgzSNRWp8ugxd uZ2asj2H3zjdeewbgiqWxHmTCbMNKEZSVnUgDtRfW0lHMM/BzLX8wdr2NWGK1ZlqZGNo=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3 14/18] x86/domain_page: key the directmap fast paths on the loaded view Date: Wed, 7 Oct 2026 11:40:47 +0100 Message-ID: <20261007104051.48841-15-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit map_domain_page() returns directmap addresses whenever it can: for any MFN the directmap covers in release builds, and for vCPUs without a mapcache. Once guest contexts may run on the sparse view of the directmap, modify this to take the fast path returning the directmap address only when the full directmap is loaded. The release-build shortcut ahead of the vCPU lookup looks at the vCPU whose page-tables are loaded, without completing a lazy context switch: if that vCPU is not on the sparse view, its page-tables map the page through the directmap, and completing the switch would only move the CPU to the idle vCPU's page-tables, which map it too. mapcache_current_vcpu() may complete the lazy context switch (sync_local_execstate()) and switch us onto the idle vCPU (which has a full view), so check again if we can use the directmap afterwards. A vCPU on the sparse view always has a mapcache: HVM ones through per-vCPU page-tables, PV ones through the domain-wide mapcache, which mapcache_domain_init() now sets up for a domain using the sparse view in release builds too, rather than only when the directmap does not cover all memory. map_domain_page_global() mappings must be valid in every context: use vmap() for all of them once a sparse view is configured, as arch_mfns_in_directmap() then says. Add d->arch.sparse_dmap and sparse_dmap_active for this; nothing sets them yet. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version. --- xen/arch/x86/domain_page.c | 44 +++++++++++++++++++-- xen/arch/x86/include/asm/domain.h | 6 +++ xen/arch/x86/include/asm/sparse-directmap.h | 8 ++++ xen/arch/x86/sparse-directmap.c | 1 + 4 files changed, 56 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 0500bb9dba..48f85b670d 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -61,6 +61,16 @@ static inline struct vcpu *mapcache_current_vcpu(void) return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } +/* + * Whether the directmap in @v's page-tables is the sparse view, which maps + * none of the heap's memory beyond the xenheap: the mapcache must serve + * every mapping then. + */ +static bool on_sparse_dmap(const struct vcpu *v) +{ + return sparse_dmap_active && v->domain->arch.sparse_dmap; +} + /* * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's * otherwise, in which case *dcache is set so the caller takes the domain-wide @@ -142,17 +152,39 @@ void *map_domain_page(mfn_t mfn) #ifdef NDEBUG if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) - return mfn_to_virt(mfn_x(mfn)); + { + const struct vcpu *pt_vcpu = this_cpu(pgtable_vcpu); + + /* + * The page-tables loaded map @mfn through the directmap, unless they + * carry the sparse view. Don't complete a lazy context switch to + * find out: it would only move this CPU to the idle vCPU's + * page-tables, which map @mfn too. + */ + if ( !pt_vcpu || !on_sparse_dmap(pt_vcpu) ) + return mfn_to_virt(mfn_x(mfn)); + } #endif + /* No vCPU (early boot), or no mapcache: the full directmap is loaded. */ v = mapcache_current_vcpu(); if ( !v ) return mfn_to_virt(mfn_x(mfn)); +#ifdef NDEBUG + /* The lookup may have completed a lazy switch off the sparse view. */ + if ( !on_sparse_dmap(v) && + mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) + return mfn_to_virt(mfn_x(mfn)); +#endif + cache = vcpu_mapcache(v, &dcache); vcache = &v->arch.mapcache; if ( !cache->inuse ) + { + ASSERT(!on_sparse_dmap(v)); return mfn_to_virt(mfn_x(mfn)); + } perfc_incr(map_domain_page_count); @@ -307,7 +339,9 @@ void mapcache_domain_init(struct domain *d) ASSERT(is_pv_domain(d)); #ifdef NDEBUG - if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) + /* Not needed when the directmap loaded for the domain covers everything. */ + if ( !d->arch.sparse_dmap && !mem_hotplug && + max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) return; #endif @@ -392,8 +426,12 @@ void *map_domain_page_global(mfn_t mfn) system_state < SYS_STATE_active) || local_irq_is_enabled())); + /* + * Global mappings must hold in every context: a sparse view of the + * directmap rules the directmap out. + */ #ifdef NDEBUG - if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) + if ( arch_mfns_in_directmap(mfn_x(mfn), 1) ) return mfn_to_virt(mfn_x(mfn)); #endif diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 80415ab2c2..76a22b4040 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -499,6 +499,12 @@ struct arch_domain */ bool vcpu_pt; + /* + * Root page-tables carry the sparse view of the directmap, once it is + * active (see asm/sparse-directmap.h). + */ + bool sparse_dmap; + /* Emulated devices enabled bitmap. */ uint32_t emulation_flags; } __cacheline_aligned; diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index 48c1f3c951..512f8064d6 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -22,6 +22,12 @@ extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm; /* Root of the sparse view, once built (NULL before, or if not configured). */ extern l4_pgentry_t *sparse_dmap_root; +/* + * Set once guest contexts run on the sparse view: from then on, the root + * page-tables of domains with d->arch.sparse_dmap carry it. + */ +extern bool sparse_dmap_active; + static inline bool sparse_dmap_configured(void) { return opt_sparse_dmap_pv || opt_sparse_dmap_hvm; @@ -37,6 +43,8 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); #else /* !CONFIG_SPARSE_DIRECTMAP */ +#define sparse_dmap_active false + static inline bool sparse_dmap_configured(void) { return false; } static inline void sparse_dmap_init(void) {} static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c index 1eb092c3ea..a41731ccfa 100644 --- a/xen/arch/x86/sparse-directmap.c +++ b/xen/arch/x86/sparse-directmap.c @@ -57,6 +57,7 @@ bool __ro_after_init opt_sparse_dmap_hvm; /* Root of the sparse view: only ever walked and copied from, never loaded. */ static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIES]; l4_pgentry_t *__ro_after_init sparse_dmap_root; +bool __read_mostly sparse_dmap_active; /* * Before the sparse view is built: the MFN ranges handed to the heap, which -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442178.1659773 (Exim 4.92) (envelope-from ) id 1xEPNu-0006iG-42; Wed, 07 Oct 2026 11:00:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442178.1659773; Wed, 07 Oct 2026 11:00: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 1xEPNt-0006eF-O9; Wed, 07 Oct 2026 11:00:29 +0000 Received: by outflank-mailman (input) for mailman id 1442178; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005yi-Sz for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNq-001bwC-07; Wed, 07 Oct 2026 11:00:26 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5K-001QnT-1b; Wed, 07 Oct 2026 10:41: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" 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=rWZqp3rjAtDLkijlzZwCExLStfGu/Llce80YZdzxLFY=; b=i6PnpxQ0OgUkwF639pPSmIortD 8SrC4BOQZcV4rxOqROAjq/XF9XHFXydG5Dnsi1Oln0j1LW8qc0pceXrqU3JgyUouL7zUuWtzPVJIr w8FH0oqmVJ8ZhGTsgUsk0mybYa8s/98OKNujGCB6wVwPZa7SW0nzEho4jzW8b6ZEwJ7E=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Teddy Astie Subject: [PATCH v3 18/18] x86/spec-ctrl: wire the sparse directmap view into the asi= option Date: Wed, 7 Oct 2026 11:40:51 +0100 Message-ID: <20261007104051.48841-19-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Let asi= choose which domains run on the sparse view of the directmap, when the hypervisor is built with CONFIG_SPARSE_DIRECTMAP: * `asi` and `asi=` enable or disable the sparse view, along with vCPU-PT, for every domain: HVM and PV guests, and the hardware domain, PV or PVH. HVM guests, a PVH hardware domain included, use the sparse view together with vCPU-PT, which gives them the mapcache it needs; PV guests all have one. A PV guest on the sparse view keeps its domain-wide mapcache and per-domain mappings: the sparse view separates it from other domains, not its vCPUs from each other. * `asi=hvm=`, and new `asi=pv=` and `asi=dom0=`, do the same for HVM or PV guests other than the hardware domain, or for the hardware domain, whatever its type: `asi=1,dom0=0` leaves the hardware domain out of ASI altogether. * A new `asi=directmap=` selects the sparse view for all domains, as `asi=vcpu-pt=` selects vCPU-PT; `vcpu-pt=` alone leaves the sparse view off. On a hypervisor built without CONFIG_SPARSE_DIRECTMAP the forms enabling all features leave the sparse view off, and `directmap=` is ignored with a warning. A guest type the build lacks is ignored, so that the sparse view is not built for nothing. * Only one of XPTI and the sparse view are enabled. Enabled explicitly, for dom0, domUs or both, XPTI takes precedence: the PV domains it covers keep the full directmap, and the boot log says so. Left to its default, XPTI yields: it is disabled for the PV domains using the sparse view, with a boot-log warning where it would otherwise be enabled, as the sparse view does not replace it yet (it still maps the xenheap and Xen's stacks). Each domain's case is settled at its creation. The boot log gains a line with the directmap mode, "sparse" once a sparse view is configured and "full" otherwise, and the "ASI features for ..." lines, one for PV guests now among them, say which domains use the sparse view. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version. --- docs/misc/xen-command-line.pandoc | 35 +++++- xen/arch/x86/include/asm/sparse-directmap.h | 28 ++++- xen/arch/x86/sparse-directmap.c | 4 +- xen/arch/x86/spec_ctrl.c | 130 ++++++++++++++++++-- 4 files changed, 171 insertions(+), 26 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 785e099c0a..0bbc8ebeff 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -203,7 +203,8 @@ to appropriate auditing by Xen. Argo is disabled by default. buggy or malicious other domain spamming the ring. ### asi (x86) -> `= List of [ , hvm=, vcpu-pt= | vcpu-pt=hvm= ]` +> `= List of [ , {pv,hvm,dom0}=, directmap=, +> vcpu-pt= | vcpu-pt=hvm= ]` > Default: `false` @@ -214,12 +215,16 @@ 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. -The mechanisms currently implemented apply to HVM guests, including a PVH -hardware domain. PV guests, including a PV hardware domain, are unaffected. +The mechanisms currently implemented are `vcpu-pt`, for HVM guests including +a PVH hardware domain, and `directmap`, for all guests including the hardware +domain, PV or PVH. The plain boolean enables or disables both, wherever they +apply. -* `hvm=` enables the features for HVM guests other than the hardware domain, - which follows the whole-feature forms (the plain boolean, or an un-suffixed - `vcpu-pt=`). +* `pv=`, `hvm=` and `dom0=` enable the features for PV guests or HVM guests + other than the hardware domain, or for the hardware domain, PV or PVH. The + plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain + out. The forms naming no guest type (an un-suffixed `vcpu-pt=`, and + `directmap=`) cover the hardware domain too. **WARNING: manual de-selection of enabled options will invalidate any protection offered by the feature. The fine grained options provided below @@ -228,6 +233,18 @@ are meant to be used for debugging purposes only.** * `vcpu-pt` gives each vCPU its own per-domain area: the per-domain slot of each vCPU's monitor table maps a region private to that vCPU. +* `directmap` (only available when Xen is built with + `CONFIG_SPARSE_DIRECTMAP`) runs guest contexts on a sparse view of the + directmap, which maps the memory Xen needs to reach at all times (the Xen + heap, Xen's own image, firmware tables), while guest memory is mapped + transiently. This selection is system-wide; `pv=`, `hvm=` and `dom0=` + make it for one guest type, along with the other features. HVM guests use + the sparse view only together with `vcpu-pt`, and PV guests only without + XPTI, which yields to the sparse view unless enabled explicitly (see + `xpti`). The whole-feature forms (`asi`, `asi=`, and `pv=`, `hvm=` + and `dom0=`) set this too, on builds that support it; on other builds they + leave it off, and `directmap` is ignored with a warning. + ### asid (x86) > `= ` @@ -3118,6 +3135,12 @@ Meltdown for all domains. With `dom0` and `domu` it is possible to control page table isolation for dom0 or guest domains only. +With `asi`, XPTI and the sparse directmap view (`asi=directmap`) exclude each +other for a PV guest. Enabled explicitly, as a whole or with `dom0` or +`domu`, XPTI keeps the PV guests it covers off the sparse view, and the boot +log says so. Left to its default, XPTI is disabled for the PV guests using +the sparse view, with a boot-log warning where it would otherwise be enabled. + ### xsave (x86) > `= ` diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index 41866b77e9..5349b2ba62 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -17,7 +17,11 @@ #define SPARSE_DMAP_END HYPERVISOR_VIRT_END #define SPARSE_DMAP_END_MFN (virt_to_mfn(SPARSE_DMAP_END - 1) + 1) -extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm; +/* + * Which domains use the sparse view: PV guests and HVM guests other than the + * hardware domain, and the hardware domain, PV or PVH. + */ +extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm, opt_sparse_dmap_hwdom; /* Root of the sparse view, once built (NULL before, or if not configured). */ extern l4_pgentry_t *sparse_dmap_root; @@ -30,13 +34,22 @@ extern bool sparse_dmap_active; static inline bool sparse_dmap_configured(void) { - return opt_sparse_dmap_pv || opt_sparse_dmap_hvm; + return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; } -/* Whether a new domain of the given type is to use the sparse view. */ -static inline bool sparse_dmap_wanted(bool pv) +static inline bool sparse_dmap_pv(void) { return opt_sparse_dmap_pv; } +static inline bool sparse_dmap_hvm(void) { return opt_sparse_dmap_hvm; } +static inline bool sparse_dmap_hwdom(void) { return opt_sparse_dmap_hwdom; } + +/* + * Whether a new domain of the given type is to use the sparse view. The + * hardware domain, PV or PVH, has a knob of its own. + */ +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { - return sparse_dmap_root && (pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); + return sparse_dmap_root && + (hwdom ? opt_sparse_dmap_hwdom + : pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); } void sparse_dmap_init(void); @@ -54,7 +67,10 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); #define sparse_dmap_active false static inline bool sparse_dmap_configured(void) { return false; } -static inline bool sparse_dmap_wanted(bool pv) { return false; } +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { return false; } +static inline bool sparse_dmap_pv(void) { return false; } +static inline bool sparse_dmap_hvm(void) { return false; } +static inline bool sparse_dmap_hwdom(void) { return false; } static inline void sparse_dmap_init(void) {} static inline void sparse_dmap_activate(void) {} static inline void sparse_dmap_install(l4_pgentry_t *l4t, bool pv) {} diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c index 54a6e36132..4fe160dad3 100644 --- a/xen/arch/x86/sparse-directmap.c +++ b/xen/arch/x86/sparse-directmap.c @@ -55,6 +55,7 @@ bool __ro_after_init opt_sparse_dmap_pv; bool __ro_after_init opt_sparse_dmap_hvm; +bool __ro_after_init opt_sparse_dmap_hwdom; /* Root of the sparse view: only ever walked and copied from, never loaded. */ static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIES]; @@ -358,7 +359,8 @@ void __init sparse_dmap_init(void) { printk(XENLOG_WARNING "Sparse directmap: too many early heap ranges, disabled\n"); - opt_sparse_dmap_pv = opt_sparse_dmap_hvm = false; + opt_sparse_dmap_pv = opt_sparse_dmap_hvm = opt_sparse_dmap_hwdom = + false; return; } diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 46105ef185..65e1d14861 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -390,6 +390,19 @@ int8_t __ro_after_init opt_xpti_domu = -1; static __init void xpti_init_default(void) { + /* + * XPTI and the sparse directmap view exclude each other for a PV domain + * (see spec_ctrl_init_domain()). Enabled explicitly, XPTI takes + * precedence: the PV domains it covers stay off the sparse view. Left to + * its default, it yields: it is off where the sparse view is asked for. + */ + if ( !opt_dom0_pvh && opt_xpti_hwdom == 1 && sparse_dmap_hwdom() ) + printk(XENLOG_ERR + "XPTI enabled, disabling Dom0 sparse-directmap\n"); + if ( opt_xpti_domu == 1 && sparse_dmap_pv() ) + printk(XENLOG_ERR + "XPTI enabled, disabling PV DomU sparse-directmap\n"); + if ( (boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) || cpu_has_rdcl_no ) { @@ -400,10 +413,23 @@ static __init void xpti_init_default(void) } else { + bool yield_hwdom = opt_xpti_hwdom < 0 && !opt_dom0_pvh && + sparse_dmap_hwdom(); + bool yield_domu = opt_xpti_domu < 0 && sparse_dmap_pv(); + + /* + * The default is on here, so alert the user when it yields. + */ + if ( yield_hwdom || yield_domu ) + printk(XENLOG_WARNING + "XPTI defaults off for PV %s on the sparse directmap\n", + yield_hwdom ? (yield_domu ? "Dom0 and DomU" : "Dom0") + : "DomU"); + if ( opt_xpti_hwdom < 0 ) - opt_xpti_hwdom = 1; + opt_xpti_hwdom = !sparse_dmap_hwdom(); if ( opt_xpti_domu < 0 ) - opt_xpti_domu = 1; + opt_xpti_domu = !sparse_dmap_pv(); } } @@ -494,6 +520,33 @@ static int __init cf_check parse_pv_l1tf(const char *s) } custom_param("pv-l1tf", parse_pv_l1tf); +/* + * The sparse directmap view, for PV guests and HVM guests other than the + * hardware domain, and for the hardware domain, PV or PVH. A guest type the + * build lacks can't use the sparse view, and doesn't get it built. Without + * CONFIG_SPARSE_DIRECTMAP there is no sparse view: the forms enabling all + * features, generally or for one guest type, leave it off. + */ +static void __init set_sparse_dmap(bool pv, bool hvm, bool hwdom, bool val) +{ +#ifdef CONFIG_SPARSE_DIRECTMAP + if ( pv && IS_ENABLED(CONFIG_PV) ) + opt_sparse_dmap_pv = val; + if ( hvm && IS_ENABLED(CONFIG_HVM) ) + opt_sparse_dmap_hvm = val; + if ( hwdom ) + opt_sparse_dmap_hwdom = val; +#endif +} + +/* + * An explicit asi=directmap on a build without the sparse directmap view. + * Warned about from init_speculation_mitigations(): printed while the command + * line is parsed, the message would stay in the console ring, and not reach + * the console. + */ +static bool __initdata asi_directmap_ignored; + static int __init cf_check parse_asi(const char *s) { const char *ss; @@ -501,7 +554,10 @@ static int __init cf_check parse_asi(const char *s) /* Interpret 'asi' alone in its positive boolean form. */ if ( *s == '\0' ) + { opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = true; + set_sparse_dmap(true, true, true, true); + } do { ss = strchr(s, ','); @@ -514,11 +570,29 @@ static int __init cf_check parse_asi(const char *s) case 0: case 1: opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; + set_sparse_dmap(true, true, true, val); break; default: - if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + if ( (val = parse_boolean("pv", s, ss)) >= 0 ) + set_sparse_dmap(true, false, false, val); + else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + { opt_vcpu_pt_hvm = val; + set_sparse_dmap(false, true, false, val); + } + else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) + { + opt_vcpu_pt_hwdom = val; + set_sparse_dmap(false, false, true, val); + } + else if ( (val = parse_boolean("directmap", s, ss)) >= 0 ) + { + /* System-wide: every guest type, the hardware domain too. */ + set_sparse_dmap(true, true, true, val); + asi_directmap_ignored = val && + !IS_ENABLED(CONFIG_SPARSE_DIRECTMAP); + } else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) { switch ( val ) @@ -744,13 +818,35 @@ static void __init print_details(enum ind_thunk thunk) opt_pv_l1tf_domu ? "enabled" : "disabled"); #endif - /* vCPU-PT is implemented for HVM only: a PV Dom0 gets none of it. */ - printk(" ASI features for Dom0:%s\n", - opt_dom0_pvh && opt_vcpu_pt_hwdom ? " vCPU-PT" : " None"); + /* + * vCPU-PT is implemented for HVM only, and HVM guests use the sparse + * directmap only with it; PV guests for which XPTI is enabled don't use + * it (see xpti_init_default()). Dom0 is listed as its type makes it. + */ + { + bool hwdom_pt = opt_dom0_pvh && opt_vcpu_pt_hwdom; + bool hwdom_sd = sparse_dmap_hwdom() && + (opt_dom0_pvh ? hwdom_pt : !opt_xpti_hwdom); + + printk(" ASI directmap mode: %s\n", + sparse_dmap_configured() ? "sparse" : "full"); + printk(" ASI features for Dom0:%s%s%s\n", + hwdom_pt || hwdom_sd ? "" : " None", + hwdom_pt ? " vCPU-PT" : "", + hwdom_sd ? " sparse-directmap" : ""); #ifdef CONFIG_HVM - printk(" ASI features for HVM VMs:%s\n", - opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); + printk(" ASI features for HVM VMs:%s%s%s\n", + opt_vcpu_pt_hvm ? "" : " None", + opt_vcpu_pt_hvm ? " vCPU-PT" : "", + opt_vcpu_pt_hvm && sparse_dmap_hvm() + ? " sparse-directmap" : ""); #endif +#ifdef CONFIG_PV + printk(" ASI features for PV VMs:%s\n", + sparse_dmap_pv() && !opt_xpti_domu + ? " sparse-directmap" : " None"); +#endif + } } static bool __init check_smt_enabled(void) @@ -1942,11 +2038,14 @@ void spec_ctrl_init_domain(struct domain *d) : opt_vcpu_pt_hvm); /* - * The sparse directmap view needs a mapcache: PV domains all have one, - * HVM domains through per-vCPU page-tables. + * The sparse directmap view needs a mapcache: PV domains all have + * one, HVM domains through per-vCPU page-tables. Left to its + * default, XPTI is off for the domains meant for the sparse view, + * so this happens only where it was enabled explicitly + * (xpti_init_default()). */ - d->arch.sparse_dmap = pv ? sparse_dmap_wanted(true) - : d->arch.vcpu_pt && sparse_dmap_wanted(false); + d->arch.sparse_dmap = (pv ? !d->arch.pv.xpti : d->arch.vcpu_pt) && + sparse_dmap_wanted(pv, is_hardware_domain(d)); } void __init init_speculation_mitigations(void) @@ -2239,7 +2338,12 @@ 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_hwdom || opt_vcpu_pt_hvm ) + if ( asi_directmap_ignored ) + warning_add( + "asi: directmap ignored, Xen built without\n" + "CONFIG_SPARSE_DIRECTMAP.\n"); + + if ( opt_vcpu_pt_hwdom || opt_vcpu_pt_hvm || sparse_dmap_configured() ) warning_add( "Address Space Isolation is not functional, this option is\n" "intended to be used only for development purposes.\n"); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442174.1659744 (Exim 4.92) (envelope-from ) id 1xEPNs-0006BR-Ck; Wed, 07 Oct 2026 11:00:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442174.1659744; Wed, 07 Oct 2026 11:00: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 1xEPNs-0006AJ-6J; Wed, 07 Oct 2026 11:00:28 +0000 Received: by outflank-mailman (input) for mailman id 1442174; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005y6-FB for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNq-001bwO-0d; Wed, 07 Oct 2026 11:00:26 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5J-001QnT-0V; Wed, 07 Oct 2026 10:41: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=oxwTS9MOb2PIX3bMecdpJFmahOt3FYv9Hqo2e2XCx8U=; b=oRHmf+2uFw+h+kuvyOl50xczl3 eS5WBPGkfTapjD4dO5FbUguoCgNPpmVty2iWkybo1VvOh9IaRXt7UVwvQ7/vgeQaKKxJqHOqeSEqB DAT5ldXrpxNsualX40jTSCVfQtLQzMIubjQ50hvMcVVZzN5eZyZkqvTVu7ZZ0ugHZJvg=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3 17/18] x86/mm: run guest contexts on the sparse directmap view Date: Wed, 7 Oct 2026 11:40:50 +0100 Message-ID: <20261007104051.48841-18-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In init_xen_l4_slots(), if d->arch.sparse_dmap is set, point the directmap L3 at the sparse view. d->arch.sparse_dmap is decided at domain creation: PV domains all have a mapcache, HVM domains need per-vCPU page-tables for one. No option asks for the sparse view yet. The sparse view becomes active once dom0 is built, before it first runs: dom0's construction runs on the full directmap, which it needs, and its root page-tables so far (a PV dom0's first L4s, a PVH dom0's monitor tables) are switched over then. A PV dom0 booted with dom0=shadow is switched as well: shadow mode is enabled only later, from a tasklet, and its shadow L4s then get the sparse view from init_xen_l4_slots(), as for any PV domain entering shadow mode. Anything built later gets the sparse view from init_xen_l4_slots(). The sparse view's slots are marked NX at activation, as the full directmap's slots are. The two directmaps differ where the sparse view leaves memory out, so no translation of the full directmap may remain usable on page-tables carrying the sparse view. Directmap mappings stay global nevertheless: every CR3 write which can move a CPU onto the sparse view goes through switch_cr3_cr4(), which flushes the old page-tables' translations, global entries included, before it returns. The CR3 writes which keep entries -- a PV vCPU's switch between its kernel and user page-tables, XPTI's entry and exit -- stay within one vCPU's page-tables, which carry the same directmap, or go to XPTI's per-CPU root, which maps only Xen's own per-CPU pages there. Removals from the sparse view are flushed on every CPU, global entries included. PV guests running with global pages, a PV dom0 not using the sparse view among them, so keep their directmap TLB entries across switches between guest kernel and user mode. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version. --- xen/arch/x86/include/asm/sparse-directmap.h | 11 ++ xen/arch/x86/mm.c | 9 +- xen/arch/x86/setup.c | 3 + xen/arch/x86/sparse-directmap.c | 129 ++++++++++++++++++++ xen/arch/x86/spec_ctrl.c | 7 ++ 5 files changed, 157 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index 512f8064d6..41866b77e9 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -33,7 +33,15 @@ static inline bool sparse_dmap_configured(void) return opt_sparse_dmap_pv || opt_sparse_dmap_hvm; } +/* Whether a new domain of the given type is to use the sparse view. */ +static inline bool sparse_dmap_wanted(bool pv) +{ + return sparse_dmap_root && (pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); +} + void sparse_dmap_init(void); +void sparse_dmap_activate(void); +void sparse_dmap_install(l4_pgentry_t *l4t, bool pv); int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags); int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, @@ -46,7 +54,10 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); #define sparse_dmap_active false static inline bool sparse_dmap_configured(void) { return false; } +static inline bool sparse_dmap_wanted(bool pv) { return false; } static inline void sparse_dmap_init(void) {} +static inline void sparse_dmap_activate(void) {} +static inline void sparse_dmap_install(l4_pgentry_t *l4t, bool pv) {} static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags) { diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 4a1bd9d146..4e2f9e1f12 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1662,7 +1662,8 @@ struct page_info *perdomain_l3(const struct vcpu *v) * share; it is mandatory for a vCPU-PT domain, whose per-domain area is * per-vCPU. All other parameters are optional and will either fill or zero * the appropriate slots. Pagetables not shared with guests will gain the - * extended directmap. + * extended directmap, unless the domain runs on the sparse view of the + * directmap, which replaces the directmap slots (see sparse_dmap_install()). */ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, const struct domain *d, const struct vcpu *v, @@ -1670,7 +1671,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, { /* * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full - * directmap. + * directmap, unless the domain runs on the sparse view (below). */ bool short_directmap = !paging_mode_external(d); @@ -1743,6 +1744,10 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots - l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); } + + /* The domain's contexts may run on the sparse view of the directmap. */ + if ( sparse_dmap_active && d->arch.sparse_dmap ) + sparse_dmap_install(l4t, short_directmap); } bool fill_ro_mpt(mfn_t mfn) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index e52388ad28..21edab9cea 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -2216,6 +2216,9 @@ void asmlinkage __init noreturn __start_xen(void) if ( !dom0 ) panic("Could not set up DOM0 guest OS\n"); + /* Before dom0 first runs, and after it was built on the full directmap. */ + sparse_dmap_activate(); + heap_init_late(); init_constructors(); diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c index ef13f9e95d..54a6e36132 100644 --- a/xen/arch/x86/sparse-directmap.c +++ b/xen/arch/x86/sparse-directmap.c @@ -46,8 +46,10 @@ #include #include #include +#include #include +#include #include #include @@ -437,3 +439,130 @@ void __init sparse_dmap_init(void) printk(XENLOG_INFO "Sparse directmap: %lu pages mapped\n", mapped); } + +/* + * Point the directmap slots of the root page-table @l4t at the sparse view. + * Every slot it covers gets its L3, whatever the full directmap has there, + * so that memory added later is covered too. A PV root has guest slots + * above; any other root loses the rest of the directmap, which the sparse + * view does not cover. + * + * Directmap mappings may be global, in either hierarchy. Translations of + * the full directmap must not remain usable on a root carrying the sparse + * view: every CR3 write which can move a CPU from the one to the other goes + * through switch_cr3_cr4(), which flushes what the old root left in the TLB, + * global entries included, before it returns. The other CR3 writes, which + * may keep global or PCID-tagged entries (_toggle_guest_pt(), XPTI's entry + * and exit paths), switch between one vCPU's roots, which carry the same + * directmap, or to XPTI's per-CPU root, which maps only this CPU's stack, + * IDT and TSS there. Removals from the sparse view flush all CPUs, global + * entries included. + */ +void sparse_dmap_install(l4_pgentry_t *l4t, bool pv) +{ + unsigned int i; + + ASSERT(sparse_dmap_root); + + for ( i = l4_table_offset(SPARSE_DMAP_START); + i < l4_table_offset(SPARSE_DMAP_END); i++ ) + l4t[i] = sparse_dmap_root[i]; + + if ( !pv ) + for ( ; i < l4_table_offset(DIRECTMAP_VIRT_END); i++ ) + l4t[i] = l4e_empty(); +} + +static void __init sparse_dmap_install_mfn(mfn_t mfn, bool pv) +{ + l4_pgentry_t *l4t = map_domain_page(mfn); + + sparse_dmap_install(l4t, pv); + unmap_domain_page(l4t); +} + +/* + * Let guest contexts run on the sparse view. Root page-tables built from + * here on carry it (init_xen_l4_slots()); those of the domains built so far + * (dom0, which has not run yet) are switched over here. Its construction ran + * on the full directmap, and needed to. + */ +void __init sparse_dmap_activate(void) +{ + struct domain *d; + struct vcpu *v; + unsigned long va, mapped = 0; + unsigned int i, switched = 0; + + if ( !sparse_dmap_root ) + return; + + /* + * Nothing in the directmap is executed: as subarch_init_memory() does + * for the full directmap, mark the sparse view's slots NX, before any + * root page-table takes a copy of them. + */ + if ( cpu_has_nx ) + for ( i = l4_table_offset(SPARSE_DMAP_START); + i < l4_table_offset(SPARSE_DMAP_END); i++ ) + l4e_add_flags(sparse_dmap_root[i], _PAGE_NX_BIT); + + rcu_read_lock(&domlist_read_lock); + + for_each_domain ( d ) + { + if ( !d->arch.sparse_dmap ) + continue; + + /* + * A PV domain runs on shadow L4s only in shadow mode, which boot + * does not enter before this point: dom0=shadow enables it later, + * from a tasklet, and the shadow L4s then get the sparse view from + * init_xen_l4_slots(), as for any PV domain entering shadow mode. + */ + switched++; + for_each_vcpu ( d, v ) + { + if ( is_hvm_vcpu(v) ) + { + if ( !pagetable_is_null(v->arch.hvm.monitor_table) ) + sparse_dmap_install_mfn( + pagetable_get_mfn(v->arch.hvm.monitor_table), false); + continue; + } + + if ( !pagetable_is_null(v->arch.guest_table) ) + sparse_dmap_install_mfn( + pagetable_get_mfn(v->arch.guest_table), true); + if ( !pagetable_is_null(v->arch.guest_table_user) ) + sparse_dmap_install_mfn( + pagetable_get_mfn(v->arch.guest_table_user), true); + } + } + + rcu_read_unlock(&domlist_read_lock); + + /* + * Belt and braces: nothing runs on these page-tables yet, and PV dom0's + * construction, which ran on its own, returned to the idle page-tables + * through switch_cr3_cr4(), dropping what it left in the TLB. + */ + flush_all(FLUSH_TLB_GLOBAL); + + sparse_dmap_active = true; + + for ( va = SPARSE_DMAP_START; va < SPARSE_DMAP_END; ) + { + pte_attr_t flags; + unsigned long n; + + if ( !mfn_eq(xen_mapping_lookup(sparse_dmap_root, va, &flags, &n), + INVALID_MFN) ) + mapped += n; + va += n << PAGE_SHIFT; + } + + printk(XENLOG_INFO + "Sparse directmap: active, %lu pages mapped, %u domain(s) on it\n", + mapped, switched); +} diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 999e41aefa..46105ef185 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -1940,6 +1940,13 @@ void spec_ctrl_init_domain(struct domain *d) d->arch.vcpu_pt = !pv && (is_hardware_domain(d) ? opt_vcpu_pt_hwdom : opt_vcpu_pt_hvm); + + /* + * The sparse directmap view needs a mapcache: PV domains all have one, + * HVM domains through per-vCPU page-tables. + */ + d->arch.sparse_dmap = pv ? sparse_dmap_wanted(true) + : d->arch.vcpu_pt && sparse_dmap_wanted(false); } void __init init_speculation_mitigations(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442176.1659757 (Exim 4.92) (envelope-from ) id 1xEPNt-0006P1-3h; Wed, 07 Oct 2026 11:00:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442176.1659757; Wed, 07 Oct 2026 11:00: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 1xEPNs-0006NK-RD; Wed, 07 Oct 2026 11:00:28 +0000 Received: by outflank-mailman (input) for mailman id 1442176; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005y5-GJ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNq-001bwI-0R; Wed, 07 Oct 2026 11:00:26 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5C-001QnT-2W; Wed, 07 Oct 2026 10:41: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=Y8xkRRzMKr9RKUFhQ6zYIhHgopPKevxFWSbNje8Fa5c=; b=cKUxmqfSVUd0AHjkiUk36XseHk a5Hz9xRk0KRR/fcRIni1RYSi2yLsvgL6hQglGSmv7B+clNODYkWiyRcHm5MJIJGxiZz50LnIk48Pm GU89Erit5zkZg8njuYF8AqFCwmxlwIE8HjNSCsDrukapMWhEuNi3zJCdXDjgJi3WEv5E=; 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?= , Teddy Astie Subject: [PATCH v3 11/18] x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains Date: Wed, 7 Oct 2026 11:40:44 +0100 Message-ID: <20261007104051.48841-12-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Add a struct mapcache to struct mapcache_vcpu for the per-vCPU accounting. Since MAPCACHE_VCPU_ENTRIES is 16, its inuse and garbage bitmaps are a word each: declare them inline in struct mapcache_vcpu, rather than mapping them in the per-domain area as the domain-wide bitmaps are. A per-vCPU mapcache is only ever used by its own vCPU, and so by one pCPU at a time. We can therefore skip both the lock and the TLB-epoch tracking the domain-wide mapcache needs; a wrap still flushes the local TLB. struct mapcache_vcpu grows from 136 to 176 bytes, and struct vcpu from 3008 to 3072 bytes (x86_64, debug build), within its page. Unlike a domain-wide mapcache, a per-vCPU one cannot, by design, borrow slots from other vCPUs: MAPCACHE_VCPU_ENTRIES (16) is the most single-page mappings such a vCPU can hold at once, interrupt handlers' included, and one more hits the BUG_ON() in map_domain_page(). The PoD zero-page sweep held up to 16 on top of its callers' until "x86/PoD: map one page at a time in p2m_pod_zero_check()". mapcache_current_vcpu()'s lazy-context-switch handling (sync_local_execstate() plus a pgtable_vcpu re-read) now applies to any vCPU with a mapcache: when the idle vCPU runs lazily on an HVM vCPU's monitor table, the full switch happens before the idle context uses a mapcache. In release builds map_domain_page() still tries the directmap first, for any vCPU; debug builds exercise the new mapcache. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - HVM only, and per-vCPU from the start: the HVM enablement of "x86: Initialize the mapcache for PV, HVM, and idle domains" (from the directmap removal series) is folded in, without the idle domain and without a domain-wide HVM mapcache. - Retitle (was: "x86/mm: introduce a per-vCPU mapcache when using ASI"). - Say which second unmaps the not-present check in unmap_domain_page() catches: those of an entry the first unmap zapped. - State the budget of single-page mappings a vCPU can hold at once. - The mapcache accounting refactor, the move of struct mapcache_vcpu to struct arch_vcpu and the not-present check in unmap_domain_page() are split out, for review, into the three patches before this one. --- xen/arch/x86/domain_page.c | 70 ++++++++++++++++++++++--------- xen/arch/x86/include/asm/domain.h | 6 +++ 2 files changed, 57 insertions(+), 19 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 708df90a00..0500bb9dba 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -20,12 +20,13 @@ /* * Whether v has a mapcache: PV vCPUs (whose domain-wide mapcache may still be - * disabled, see mapcache_domain_init()). HVM vCPUs reach everything through - * the directmap, which covers all physical address space for them. + * disabled, see mapcache_domain_init()) and the vCPUs of an HVM domain using + * per-vCPU page-tables. Other HVM vCPUs reach everything through the + * directmap, which covers all physical address space for them. */ static bool has_mapcache(const struct vcpu *v) { - return is_pv_vcpu(v); + return is_pv_vcpu(v) || v->domain->arch.vcpu_pt; } static inline struct vcpu *mapcache_current_vcpu(void) @@ -38,10 +39,10 @@ static inline struct vcpu *mapcache_current_vcpu(void) return NULL; /* - * If we are in a lazy context-switch state from a PV vCPU do a full switch - * 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. + * If we are in a lazy context-switch state from a vCPU with a mapcache do + * a full switch 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. */ if ( unlikely(this_cpu(curr_vcpu) != curr) ) { @@ -61,14 +62,21 @@ static inline struct vcpu *mapcache_current_vcpu(void) } /* - * The accounting for v's mapcache: the domain's, with *dcache set so the - * caller takes the domain-wide lock and TLB-epoch machinery into account. + * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's + * otherwise, in which case *dcache is set so the caller takes the domain-wide + * lock and TLB-epoch machinery into account. */ static struct mapcache *vcpu_mapcache(struct vcpu *v, struct mapcache_domain **dcache) { struct domain *d = v->domain; + if ( d->arch.vcpu_pt ) + { + *dcache = NULL; + return &v->arch.mapcache.cache; + } + *dcache = &d->arch.pv.mapcache; return &(*dcache)->cache; } @@ -77,11 +85,15 @@ static struct mapcache *vcpu_mapcache(struct vcpu *v, * The domain-wide mapcache's lock and TLB-epoch machinery, taken around * allocating a slot: the domain's vCPUs share the mapcache's slots, and each * catches up with a wrap another one caused, flushing its TLB if it has not - * been flushed since. + * been flushed since. A per-vCPU mapcache (no dcache) needs neither: only its + * own vCPU, and so one pCPU at a time, uses it. */ static void mapcache_lock(struct mapcache_domain *dcache, struct mapcache_vcpu *vcache) { + if ( !dcache ) + return; + spin_lock(&dcache->lock); /* Has some other CPU caused a wrap? We must flush if so. */ @@ -100,13 +112,17 @@ static void mapcache_lock(struct mapcache_domain *dcache, static void mapcache_new_epoch(struct mapcache_domain *dcache, struct mapcache_vcpu *vcache) { + if ( !dcache ) + return; + vcache->shadow_epoch = ++dcache->epoch; dcache->tlbflush_timestamp = tlbflush_current_time(); } static void mapcache_unlock(struct mapcache_domain *dcache) { - spin_unlock(&dcache->lock); + if ( dcache ) + spin_unlock(&dcache->lock); } #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) @@ -191,7 +207,12 @@ void *map_domain_page(mfn_t mfn) } BUG_ON(idx >= cache->entries); - /* /Second/, flush TLBs. */ + /* + * /Second/, flush TLBs. A per-vCPU mapcache needs a local flush + * only: its entries are never _PAGE_GLOBAL, and this vCPU's + * page-tables can only have been loaded on another pCPU via + * switch_cr3_cr4(), which flushes non-global mappings. + */ perfc_incr(domain_page_tlb_flush); flush_tlb_local(); mapcache_new_epoch(dcache, vcache); @@ -313,11 +334,19 @@ int mapcache_vcpu_init(struct vcpu *v) return 0; cache = vcpu_mapcache(v, &dcache); - if ( !cache->inuse ) + if ( !dcache ) + { + /* Per-vCPU bitmaps are a word each: they live in the vCPU itself. */ + cache->inuse = v->arch.mapcache.inuse; + cache->garbage = v->arch.mapcache.garbage; + ents = MAPCACHE_VCPU_ENTRIES; + } + else if ( !cache->inuse ) /* Domain-wide mapcache disabled (fully direct-mapped build). */ return 0; + else + ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; - ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); if ( ents > cache->entries ) @@ -326,13 +355,16 @@ int mapcache_vcpu_init(struct vcpu *v) int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, NIL(l1_pgentry_t *), NULL); - /* Populate bit maps. */ - if ( !rc ) + /* Populate the domain-wide bit maps (kept in the per-domain area). */ + if ( !rc && dcache ) + { rc = create_perdomain_mapping(v, (unsigned long)cache->inuse, nr, NULL, NIL(struct page_info *)); - if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, - nr, NULL, NIL(struct page_info *)); + if ( !rc ) + rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, + nr, NULL, + NIL(struct page_info *)); + } if ( rc ) return rc; diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index cfa24c4e75..80415ab2c2 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -80,6 +80,12 @@ struct mapcache_vcpu { uint32_t idx; uint32_t refcnt; } hash[MAPHASH_ENTRIES]; + + /* Accounting of a per-vCPU mapcache (vCPU-PT domains). */ + struct mapcache cache; + /* Backing for cache.{inuse,garbage}. */ + DECLARE_BITMAP(inuse, MAPCACHE_VCPU_ENTRIES); + DECLARE_BITMAP(garbage, MAPCACHE_VCPU_ENTRIES); }; struct mapcache_domain { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442173.1659738 (Exim 4.92) (envelope-from ) id 1xEPNs-00066A-2s; Wed, 07 Oct 2026 11:00:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442173.1659738; Wed, 07 Oct 2026 11:00: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 1xEPNr-00065V-Uh; Wed, 07 Oct 2026 11:00:27 +0000 Received: by outflank-mailman (input) for mailman id 1442173; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005y8-EQ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNq-001bwG-0K; Wed, 07 Oct 2026 11:00:26 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5B-001QnT-2O; Wed, 07 Oct 2026 10:41: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=P7gSAZkpbEQZ016S+qOjogD467NTdt8ZgNSKB5Dcc3E=; b=UqZuNYEs3z/YdvEmir5hdRchl0 OrJXg/t8GcPNmh29depEDwhjTJa6JvMiKv/+nUQ6V4c3KV6dLZL8BeiHlqN6HyTFMZ68UkFI11pdt NZKTC5q+G0NtJgF4uGnNudhuW+nL27/TeaXhawt7fTju1LvjlQFXk3aHnKI1Yd3q428Y=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3 10/18] x86/domain_page: don't unmap a mapcache entry that is not present Date: Wed, 7 Oct 2026 11:40:43 +0100 Message-ID: <20261007104051.48841-11-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Mappings must be torn down by the vCPU that created them, and only once. Have unmap_domain_page() check that the entry it is handed is present and bail out otherwise (ASSERT_UNREACHABLE()), rather than read an MFN out of an empty PTE and act on it, as a second unmap of an entry the first one zapped would. (A second unmap of an entry the maphash kept is caught, as before, only by the refcount ASSERT() in debug builds.) Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index f91ec8a75a..708df90a00 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -230,6 +230,16 @@ void unmap_domain_page(const void *ptr) ASSERT(cache->inuse); idx = PFN_DOWN(va - MAPCACHE_VIRT_START); + /* + * Mappings must be unmapped once, by the vCPU that created them. With + * nothing present there is nothing to tear down: leave the hash and the + * bitmaps alone rather than act on a stale or foreign pointer. + */ + if ( !(l1e_get_flags(MAPCACHE_L1ENT(idx)) & _PAGE_PRESENT) ) + { + ASSERT_UNREACHABLE(); + return; + } mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)]; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442177.1659764 (Exim 4.92) (envelope-from ) id 1xEPNt-0006ZL-LN; Wed, 07 Oct 2026 11:00:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442177.1659764; Wed, 07 Oct 2026 11:00: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 1xEPNt-0006XJ-Ad; Wed, 07 Oct 2026 11:00:29 +0000 Received: by outflank-mailman (input) for mailman id 1442177; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005yd-QZ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNp-001bwA-3B; Wed, 07 Oct 2026 11:00:25 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5H-001QnT-13; Wed, 07 Oct 2026 10:41: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=lKK7xvuX4KaLB6q8iiI3K8qFh2zb9vOgIFdBlslvfS4=; b=SbnMG71qmDmAShULXYcfZDKMO/ 7vaer8XkcruYMK9QQs0whBB9/ckI9o485iK2WNcUMFTGg93/lxcbg1aBssljhsgj2UYISaPVV/5NY xybQ0No0nYsvGRooTrlSDKRFw6CRiBJwrAykq4na0ANReJ2hxhm4XRV2jRgaRVqXkPQE=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: 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 15/18] x86/mm: flush owned pages before reuse with the sparse directmap view Date: Wed, 7 Oct 2026 11:40:48 +0100 Message-ID: <20261007104051.48841-16-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Since d7bf1b8ea275 ("x86/mm: limit deferred TLB flushing to PV domain support") a page freed by its owner is flushed from TLBs before it is handed out again only in builds with PV support, on the premise that PV domains, with their (limited) control over the host MMU and over when flushes happen, are the only ones to leave stale entries behind. Xen's transient mappings of domain pages are another source. The mapcache zaps a slot when it is unmapped but defers the flush: the slot's translation can stay in the TLB of the CPU which used it until that CPU next flushes, by which time the page may have been freed and handed to another domain. Before "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains", only PV vCPUs use the mapcache, so the PV condition covers it. Now that the vCPUs of an HVM domain with per-vCPU page-tables have one as well. While the full directmap is loaded in every context, stale transient mappings only map what's already mapped in the full directmap. On the sparse view of the directmap, a stale translation of a page handed to another domain would keep it reachable from a context which has nothing to do with it. So flush owned pages before reuse wherever a sparse view is configured, as before d7bf1b8ea275. In builds without PV support, mark_page_free() now also asks a new hook, arch_freed_pages_need_tlbflush(), declared with the xenheap hooks the sparse view already uses. x86 answers with sparse_dmap_configured(); without CONFIG_SPARSE_DIRECTMAP, and on other architectures, the answer is no. Builds with PV support flush as before, and HVM-only builds keep d7bf1b8ea275's saving unless a sparse view is configured, which nothing does until a later patch. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version. --- xen/arch/x86/sparse-directmap.c | 14 ++++++++++++++ xen/common/page_alloc.c | 14 +++++++++----- xen/include/xen/mm.h | 6 ++++++ 3 files changed, 29 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c index a41731ccfa..ef13f9e95d 100644 --- a/xen/arch/x86/sparse-directmap.c +++ b/xen/arch/x86/sparse-directmap.c @@ -185,6 +185,20 @@ bool arch_xenheap_needs_scrub(void) return sparse_dmap_configured(); } +/* + * Pages freed by their owner are flushed from TLBs before reuse once a + * sparse view is configured. Contexts on the sparse view reach domain-heap + * memory only through mappings made for the purpose, and the mapcache zaps a + * transient mapping when it is dropped but defers the flush: a translation + * left behind would keep the page reachable after it has been handed to + * another owner. With PV support, owned pages are flushed before reuse + * anyway. + */ +bool arch_freed_pages_need_tlbflush(void) +{ + return sparse_dmap_configured(); +} + /* Pages have been allocated from the heap as xenheap pages. */ int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) { diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 69e8e982b6..477301ef7c 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1539,12 +1539,16 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) } /* - * If a page has no owner and there's no PV domain support it does not need - * a 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. + * If a page has no owner, or there's no PV domain support and the + * architecture doesn't ask for one, it does not need a safety TLB flush. + * PV domains can keep stale entries on the TLB, as they have (limited) + * control over the host MMU and when flushes are performed. On x86, + * while a sparse directmap view is configured, so can Xen's transient + * mappings of the page, whose translations may outlive the mappings. */ - pg->u.free.need_tlbflush = IS_ENABLED(CONFIG_PV) && page_get_owner(pg); + pg->u.free.need_tlbflush = page_get_owner(pg) && + (IS_ENABLED(CONFIG_PV) || + arch_freed_pages_need_tlbflush()); if ( pg->u.free.need_tlbflush ) page_set_tlbflush_timestamp(pg); diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 2bcc45cf58..1628f7a897 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -110,6 +110,8 @@ bool arch_xenheap_needs_scrub(void); int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order); /* Xenheap pages are to be freed. Non-zero: failed, don't reuse them. */ int arch_xenheap_pages_free(mfn_t mfn, unsigned int order); +/* Pages freed by their owner need a TLB flush before they are reused. */ +bool arch_freed_pages_need_tlbflush(void); #else static inline bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) { @@ -127,6 +129,10 @@ static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) { return 0; } +static inline bool arch_freed_pages_need_tlbflush(void) +{ + return false; +} #endif /* Free an allocation, and zero the pointer to it. */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442172.1659733 (Exim 4.92) (envelope-from ) id 1xEPNr-00061S-R7; Wed, 07 Oct 2026 11:00:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442172.1659733; Wed, 07 Oct 2026 11:00: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 1xEPNr-00060h-NC; Wed, 07 Oct 2026 11:00:27 +0000 Received: by outflank-mailman (input) for mailman id 1442172; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005y7-DU for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNq-001bwS-0k; Wed, 07 Oct 2026 11:00:26 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5D-001QnT-2H; Wed, 07 Oct 2026 10:41: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" 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=s8gKbLWFi6wgE9b8CopwbaynqyW9W4JENY9bvZeWPyQ=; b=RTJdZXiZ9hOcVUqeIYc0rzDHem KQEr6odiA8Vib09s/JCjysCQbx64bRWAttC2MnHSmlc88ttE/AMeAuvsIE0ZjTB4UDMIwGXBe9NYK sU1kymKGSoxusls3hoNU0qAaY83+5HX8cx7oASKlMn+2PFkUDmepItVd6NeNSe1c0B50=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3 12/18] x86/mm: let Xen's page-table walker operate on a given root Date: Wed, 7 Oct 2026 11:40:45 +0100 Message-ID: <20261007104051.48841-13-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit map_pages_to_xen() and modify_xen_mappings() maintain Xen's own mappings, walking from idle_pg_table, whose Xen slots every other root page-table copies. A later patch introduces a second directmap hierarchy: page tables for the directmap virtual address range that some guest contexts use in place of idle_pg_table's. It needs the same maintenance at the same virtual addresses. Give virt_to_xen_l{3,2,1}e() the L4 to walk from, and move the bodies of map_pages_to_xen() and modify_xen_mappings() into map_pages_in() and modify_mappings_in(), which take the root as well. The public functions pass idle_pg_table. The EFI runtime-services page-tables mirror idle_pg_table's L4 entries only, so a newly allocated L3 is propagated to them only when the root is idle_pg_table. TLB flushing is unaffected: it is by virtual address, and the same addresses are mapped in either hierarchy. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version. --- xen/arch/x86/mm.c | 55 ++++++++++++++++++++++++++++++++++------------- 1 file changed, 40 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 7258935528..94b96c3d9b 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5201,13 +5201,14 @@ static DEFINE_SPINLOCK(map_pgdir_lock); /* * For virt_to_xen_lXe() functions, they take a linear address and return a - * pointer to Xen's LX entry. Caller needs to unmap the pointer. + * pointer to Xen's LX entry in the page-table hierarchy rooted at @root + * (idle_pg_table for Xen's own mappings). Caller needs to unmap the pointer. */ -static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) +static l3_pgentry_t *virt_to_xen_l3e(l4_pgentry_t *root, unsigned long v) { l4_pgentry_t *pl4e; - pl4e = &idle_pg_table[l4_table_offset(v)]; + pl4e = &root[l4_table_offset(v)]; if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) ) { bool locking = system_state > SYS_STATE_boot; @@ -5223,7 +5224,8 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) l4_pgentry_t l4e = l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR); l4e_write(pl4e, l4e); - efi_update_l4_pgtable(l4_table_offset(v), l4e); + if ( root == idle_pg_table ) + efi_update_l4_pgtable(l4_table_offset(v), l4e); l3mfn = INVALID_MFN; } if ( locking ) @@ -5234,11 +5236,11 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) return map_l3t_from_l4e(*pl4e) + l3_table_offset(v); } -static l2_pgentry_t *virt_to_xen_l2e(unsigned long v) +static l2_pgentry_t *virt_to_xen_l2e(l4_pgentry_t *root, unsigned long v) { l3_pgentry_t *pl3e, l3e; - pl3e = virt_to_xen_l3e(v); + pl3e = virt_to_xen_l3e(root, v); if ( !pl3e ) return NULL; @@ -5272,11 +5274,11 @@ static l2_pgentry_t *virt_to_xen_l2e(unsigned long v) return map_l2t_from_l3e(l3e) + l2_table_offset(v); } -static l1_pgentry_t *virt_to_xen_l1e(unsigned long v) +static l1_pgentry_t *virt_to_xen_l1e(l4_pgentry_t *root, unsigned long v) { l2_pgentry_t *pl2e, l2e; - pl2e = virt_to_xen_l2e(v); + pl2e = virt_to_xen_l2e(root, v); if ( !pl2e ) return NULL; @@ -5352,7 +5354,7 @@ mfn_t xen_map_to_mfn(unsigned long va) bool locking = system_state > SYS_STATE_boot; unsigned int l2_offset = l2_table_offset(va); unsigned int l1_offset = l1_table_offset(va); - const l3_pgentry_t *pl3e = virt_to_xen_l3e(va); + const l3_pgentry_t *pl3e = virt_to_xen_l3e(idle_pg_table, va); const l2_pgentry_t *pl2e = NULL; const l1_pgentry_t *pl1e = NULL; struct page_info *l3page; @@ -5392,7 +5394,12 @@ mfn_t xen_map_to_mfn(unsigned long va) return ret; } -int map_pages_to_xen( +/* + * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or + * another hierarchy sharing its virtual addresses. + */ +static int map_pages_in( + l4_pgentry_t *root, unsigned long virt, mfn_t mfn, unsigned long nr_mfns, @@ -5443,7 +5450,7 @@ int map_pages_to_xen( UNMAP_DOMAIN_PAGE(pl3e); UNMAP_DOMAIN_PAGE(pl2e); - pl3e = virt_to_xen_l3e(virt); + pl3e = virt_to_xen_l3e(root, virt); if ( !pl3e ) goto out; @@ -5567,7 +5574,7 @@ int map_pages_to_xen( free_xen_pagetable(l2mfn); } - pl2e = virt_to_xen_l2e(virt); + pl2e = virt_to_xen_l2e(root, virt); if ( !pl2e ) goto out; @@ -5612,7 +5619,7 @@ int map_pages_to_xen( /* Normal page mapping. */ if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) { - pl1e = virt_to_xen_l1e(virt); + pl1e = virt_to_xen_l1e(root, virt); if ( pl1e == NULL ) goto out; } @@ -5797,6 +5804,15 @@ int map_pages_to_xen( return rc; } +int map_pages_to_xen( + unsigned long virt, + mfn_t mfn, + unsigned long nr_mfns, + pte_attr_t flags) +{ + return map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); +} + int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) { return map_pages_to_xen(virt, INVALID_MFN, nr_mfns, MAP_SMALL_PAGES); @@ -5813,8 +5829,12 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * flags are ignored. * * It is an error to call with present flags over an unpopulated range. + * + * modify_mappings_in() does so in the hierarchy rooted at @root, as + * map_pages_in() does. */ -int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) +static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, + unsigned long e, pte_attr_t nf) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -5841,7 +5861,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) UNMAP_DOMAIN_PAGE(pl2e); UNMAP_DOMAIN_PAGE(pl3e); - pl3e = virt_to_xen_l3e(v); + pl3e = virt_to_xen_l3e(root, v); if ( !pl3e ) goto out; @@ -6092,6 +6112,11 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) #undef flush_area +int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) +{ + return modify_mappings_in(idle_pg_table, s, e, nf); +} + int destroy_xen_mappings(unsigned long s, unsigned long e) { return modify_xen_mappings(s, e, _PAGE_NONE); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442179.1659780 (Exim 4.92) (envelope-from ) id 1xEPNu-0006uL-MO; Wed, 07 Oct 2026 11:00:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442179.1659780; Wed, 07 Oct 2026 11:00: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 1xEPNu-0006qV-7Q; Wed, 07 Oct 2026 11:00:30 +0000 Received: by outflank-mailman (input) for mailman id 1442179; Wed, 07 Oct 2026 11:00:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNr-0005yp-8T for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:27 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNp-001bw8-2z; Wed, 07 Oct 2026 11:00:25 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5F-001QnT-08; Wed, 07 Oct 2026 10:41: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=n89simzdmROfxUVTPCbuqHlbqGiH8SNCmEeAKkxXiY8=; b=cx9kdRn6GVCDclNUoGjK+lRlMa xwFzR9Jwf8sOsBeBE3BgO5xZnuEyOjcT69S7Hne2/DGqWF47LKOqvOrRrjbREp+8ibTAxowh7hqTf vjYzT5JJ6K+umk8QmwArrYN2nGDt3tJb5i8ntzmASJwKde6MfU8gM8StGV+1dPMTM3+U=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: 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 13/18] x86/mm: build and maintain a sparse view of the directmap Date: Wed, 7 Oct 2026 11:40:46 +0100 Message-ID: <20261007104051.48841-14-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The directmap maps all of RAM, and every root page-table carries it, so while any guest context runs, all guest memory is reachable from Xen's address space. For ASI, guest contexts are to run on a view of the directmap which maps only what Xen must reach through it at all times, leaving guest memory to transient mappings (map_domain_page()). Rather than remove the directmap for everyone, keep the full directmap as it is, for the idle domain and for guest contexts not using ASI, and build a second, sparse view: page-tables for the same virtual addresses (the part of the directmap PV guests can see, where everything Xen reaches through the directmap lives), mapping a subset of what the full directmap maps, each entry a copy of the full directmap's. Boot, dom0 construction and the idle domain keep the full directmap, so nothing in them needs converting. The sparse view maps the xenheap, and memory never handed to the heap allocator (Xen's image, boot-time allocations, firmware tables). It is built once the boot allocator has handed its memory to the heap, from the full directmap minus the ranges the heap was given, plus the xenheap allocations made meanwhile (NUMA node heap metadata). The page-tables then come from the heap, and no other CPU is up. The sparse view has an L3 for each of its L4 slots from the start, so its L4 entries never change and root page-tables can take copies of them. It is then kept in step: - xenheap allocations are added, and taken out again before the pages are freed. If that fails the pages stay mapped, and are leaked with a warning rather than reused (the same reasoning as in "xen/page_alloc: Add a path for xenheap when there is no direct map" of the directmap removal series); - memory handed to the heap later (boot modules, .init, memory hot-add) is taken out, and is not handed over if that fails; - a PV dom0's initrd, assigned to dom0 in place, is taken out; - page-tables from the boot allocator, which the sparse view maps with every other boot-time allocation, are taken out when idle_pg_table's hierarchy frees them, and are not freed if that fails, so that the sparse view never keeps a page the heap may hand out; - changes to the full directmap through map_pages_to_xen() and modify_xen_mappings() are mirrored. After boot, map_pages_to_xen() maps into the directmap only memory Xen keeps (stack guard and shadow stack pages, firmware tables) or hot-added memory about to be handed to the heap, which the second rule then takes out again. Common code gains four hooks for this, arch_heap_pages_init(), arch_xenheap_needs_scrub() and arch_xenheap_pages_{alloc,free}(), no-ops unless CONFIG_SPARSE_DIRECTMAP is selected. A failed arch_xenheap_pages_alloc() may have mapped part of the pages: alloc_xenheap_pages() then takes them out through arch_xenheap_pages_free(), as a free would, before freeing them, and leaks them if that fails too. xen_mapping_lookup(), built only with CONFIG_SPARSE_DIRECTMAP, reads an entry of either hierarchy under the L3 table lock. alloc_xenheap_pages() accepts pages still awaiting scrubbing (MEMF_no_scrub). That is harmless while the directmap maps all memory anyway, but the sparse view would make such a page's contents, a dying domain's data for instance, reachable from every context on it until overwritten. With a sparse view configured, arch_xenheap_needs_scrub() makes xenheap allocations scrub those pages first, as domain heap allocations do; clean pages need nothing extra. arch_mfns_in_directmap() says whether an MFN range is reachable through the directmap; it now answers for every context, so false once a sparse view is configured. Its one caller, init_node_heap(), then keeps a NUMA node's heap metadata in the xenheap instead of carving it out of the node's memory through the directmap: carved out of a range handed to the heap, it would be left out of the sparse view, which every heap allocation needs it in. The sparse view is built only when some guest type is to use it, which nothing can request yet: this patch changes nothing on its own. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version. --- xen/arch/x86/Kconfig | 1 + xen/arch/x86/Makefile | 1 + xen/arch/x86/include/asm/mm.h | 17 +- xen/arch/x86/include/asm/sparse-directmap.h | 63 +++ xen/arch/x86/mm.c | 128 +++++- xen/arch/x86/pv/dom0_build.c | 4 + xen/arch/x86/setup.c | 4 + xen/arch/x86/sparse-directmap.c | 424 ++++++++++++++++++++ xen/common/Kconfig | 18 + xen/common/page_alloc.c | 41 +- xen/include/xen/mm.h | 35 ++ 11 files changed, 722 insertions(+), 14 deletions(-) create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h create mode 100644 xen/arch/x86/sparse-directmap.c diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index e5535ac484..cd72102ccc 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -31,6 +31,7 @@ config X86 select HAS_SCHED_GRANULARITY select HAS_SHARED_INFO imply HAS_SOFT_RESET + select HAS_SPARSE_DIRECTMAP select HAS_UBSAN select HAS_VMAP select HAS_VPCI if HVM diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 8a205c3d27..22b3c8bf6b 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -63,6 +63,7 @@ obj-y += shutdown.o obj-y += smp.o obj-y += smpboot.o obj-y += spec_ctrl.o +obj-$(CONFIG_SPARSE_DIRECTMAP) += sparse-directmap.o obj-y += srat.o obj-y += string.o obj-$(CONFIG_SYSCTL) += sysctl.o diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 87131dd4bf..0d1e319c09 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -7,6 +7,7 @@ #include #include #include +#include #include /* @@ -595,6 +596,15 @@ mfn_t alloc_xen_pagetable(void); void free_xen_pagetable(mfn_t mfn); void *alloc_mapped_pagetable(mfn_t *pmfn); +int map_pages_in(l4_pgentry_t *root, unsigned long virt, mfn_t mfn, + unsigned long nr_mfns, pte_attr_t flags); +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, unsigned long e, + pte_attr_t nf); +#ifdef CONFIG_SPARSE_DIRECTMAP +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, + pte_attr_t *flags, unsigned long *nr); +#endif + int __sync_local_execstate(void); /* Arch-specific portion of memory_op hypercall. */ @@ -655,12 +665,17 @@ void write_32bit_pse_identmap(uint32_t *l2); /* * x86 maps part of physical memory via the directmap region. - * Return whether the range of MFN falls in the directmap region. + * Return whether the range of MFN falls in the directmap region, as seen from + * every context: with a sparse directmap view configured (see + * asm/sparse-directmap.h), no range is, except through a xenheap allocation. */ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) { unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END); + if ( sparse_dmap_configured() ) + return false; + return (mfn + nr) <= (virt_to_mfn(eva - 1) + 1); } diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h new file mode 100644 index 0000000000..48c1f3c951 --- /dev/null +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -0,0 +1,63 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef X86_SPARSE_DIRECTMAP_H +#define X86_SPARSE_DIRECTMAP_H + +#include +#include +#include + +#ifdef CONFIG_SPARSE_DIRECTMAP + +/* + * The part of the directmap the sparse view covers: the part PV guests can + * see, which is where everything Xen reaches through the directmap lives. + * SPARSE_DMAP_END_MFN is the first MFN past it. + */ +#define SPARSE_DMAP_START DIRECTMAP_VIRT_START +#define SPARSE_DMAP_END HYPERVISOR_VIRT_END +#define SPARSE_DMAP_END_MFN (virt_to_mfn(SPARSE_DMAP_END - 1) + 1) + +extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm; + +/* Root of the sparse view, once built (NULL before, or if not configured). */ +extern l4_pgentry_t *sparse_dmap_root; + +static inline bool sparse_dmap_configured(void) +{ + return opt_sparse_dmap_pv || opt_sparse_dmap_hvm; +} + +void sparse_dmap_init(void); +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, + pte_attr_t flags); +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf); +int sparse_dmap_remove(mfn_t mfn, unsigned long nr); +int sparse_dmap_drop_pagetable(mfn_t mfn); + +#else /* !CONFIG_SPARSE_DIRECTMAP */ + +static inline bool sparse_dmap_configured(void) { return false; } +static inline void sparse_dmap_init(void) {} +static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, + unsigned long nr, pte_attr_t flags) +{ + return 0; +} +static inline int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf) +{ + return 0; +} +static inline int sparse_dmap_remove(mfn_t mfn, unsigned long nr) +{ + return 0; +} +static inline int sparse_dmap_drop_pagetable(mfn_t mfn) +{ + return 0; +} + +#endif /* CONFIG_SPARSE_DIRECTMAP */ + +#endif /* X86_SPARSE_DIRECTMAP_H */ diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 94b96c3d9b..4a1bd9d146 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -127,6 +127,7 @@ #include #include #include +#include #include #include #include @@ -5394,11 +5395,104 @@ mfn_t xen_map_to_mfn(unsigned long va) return ret; } +#ifdef CONFIG_SPARSE_DIRECTMAP +/* + * Look @va up in the hierarchy rooted at @root, without allocating anything. + * Returns the MFN mapped at @va, or INVALID_MFN, with the mapping's flags in + * L1 form in *flags, and in *nr the number of pages from @va to the end of + * the entry that maps @va (or that finds it unmapped). + */ +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, + pte_attr_t *flags, unsigned long *nr) +{ + bool locking = system_state > SYS_STATE_boot; + l4_pgentry_t l4e = root[l4_table_offset(va)]; + const l3_pgentry_t *pl3e = NULL; + const l2_pgentry_t *pl2e = NULL; + const l1_pgentry_t *pl1e = NULL; + struct page_info *l3page; + unsigned int shift = L4_PAGETABLE_SHIFT; + mfn_t ret = INVALID_MFN; + + L3T_INIT(l3page); + *flags = 0; + + if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) ) + goto out; + + pl3e = map_l3t_from_l4e(l4e) + l3_table_offset(va); + l3page = l4e_get_page(l4e); + L3T_LOCK(l3page); + + shift = L3_PAGETABLE_SHIFT; + if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) ) + goto out; + if ( l3e_get_flags(*pl3e) & _PAGE_PSE ) + { + /* The superpage PAT bit sits among the address bits. */ + *flags = lNf_to_l1f(l3e_get_flags(*pl3e)) | + (l3e_get_intpte(*pl3e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); + ret = _mfn((l3e_get_pfn(*pl3e) & ~((1UL << (2 * PAGETABLE_ORDER)) - 1)) + + (PFN_DOWN(va) & ((1UL << (2 * PAGETABLE_ORDER)) - 1))); + goto out; + } + + pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(va); + shift = L2_PAGETABLE_SHIFT; + if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) + goto out; + if ( l2e_get_flags(*pl2e) & _PAGE_PSE ) + { + *flags = lNf_to_l1f(l2e_get_flags(*pl2e)) | + (l2e_get_intpte(*pl2e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); + ret = _mfn((l2e_get_pfn(*pl2e) & ~((1UL << PAGETABLE_ORDER) - 1)) + + l1_table_offset(va)); + goto out; + } + + pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(va); + shift = PAGE_SHIFT; + if ( l1e_get_flags(*pl1e) & _PAGE_PRESENT ) + { + *flags = l1e_get_flags(*pl1e); + ret = l1e_get_mfn(*pl1e); + } + + out: + L3T_UNLOCK(l3page); + unmap_domain_page(pl1e); + unmap_domain_page(pl2e); + unmap_domain_page(pl3e); + *nr = ((((va >> shift) + 1) << shift) - va) >> PAGE_SHIFT; + return ret; +} +#endif /* CONFIG_SPARSE_DIRECTMAP */ + +/* + * Free a page-table page that the hierarchy rooted at @root has stopped + * using. idle_pg_table's hierarchy has pages from the boot allocator, + * which the sparse directmap view maps along with every other boot-time + * allocation: such a page leaves the sparse view before it reaches the + * heap, and is kept if it cannot. That takes the sparse view's L3 lock + * with an L3 lock of idle_pg_table's hierarchy held, the only order in + * which the two nest. The sparse view's own page-tables come from the + * heap, which it does not map, and are freed directly, as the caller may + * hold the sparse view's L3 lock; so are tables freed straight after being + * allocated, having lost a race to be installed. + */ +static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) +{ + if ( root == idle_pg_table && sparse_dmap_drop_pagetable(mfn) ) + return; + + free_xen_pagetable(mfn); +} + /* * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or * another hierarchy sharing its virtual addresses. */ -static int map_pages_in( +int map_pages_in( l4_pgentry_t *root, unsigned long virt, mfn_t mfn, @@ -5503,10 +5597,10 @@ static int map_pages_in( ol2e = l2t[i]; if ( (l2e_get_flags(ol2e) & _PAGE_PRESENT) && !(l2e_get_flags(ol2e) & _PAGE_PSE) ) - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } unmap_domain_page(l2t); - free_xen_pagetable(l3e_get_mfn(ol3e)); + free_pagetable_in(root, l3e_get_mfn(ol3e)); } } @@ -5604,7 +5698,7 @@ static int map_pages_in( flush_flags(l1e_get_flags(l1t[i])); flush_area(virt, flush_flags); unmap_domain_page(l1t); - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } } @@ -5736,7 +5830,7 @@ static int map_pages_in( flush_area(virt - PAGE_SIZE, FLUSH_TLB_GLOBAL | FLUSH_ORDER(PAGETABLE_ORDER)); - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -5783,7 +5877,7 @@ static int map_pages_in( flush_area(virt - PAGE_SIZE, FLUSH_TLB_GLOBAL | FLUSH_ORDER(2*PAGETABLE_ORDER)); - free_xen_pagetable(l3e_get_mfn(ol3e)); + free_pagetable_in(root, l3e_get_mfn(ol3e)); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -5810,7 +5904,12 @@ int map_pages_to_xen( unsigned long nr_mfns, pte_attr_t flags) { - return map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); + int rc = map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); + + if ( !rc ) + rc = sparse_dmap_mirror_map(virt, mfn, nr_mfns, flags); + + return rc; } int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) @@ -5833,8 +5932,8 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * modify_mappings_in() does so in the hierarchy rooted at @root, as * map_pages_in() does. */ -static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, - unsigned long e, pte_attr_t nf) +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, + unsigned long e, pte_attr_t nf) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -6044,7 +6143,7 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, if ( locking ) spin_unlock(&map_pgdir_lock); flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ - free_xen_pagetable(l1mfn); + free_pagetable_in(root, l1mfn); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -6088,7 +6187,7 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, if ( locking ) spin_unlock(&map_pgdir_lock); flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ - free_xen_pagetable(l2mfn); + free_pagetable_in(root, l2mfn); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -6114,7 +6213,12 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) { - return modify_mappings_in(idle_pg_table, s, e, nf); + int rc = modify_mappings_in(idle_pg_table, s, e, nf); + + if ( !rc ) + rc = sparse_dmap_mirror_modify(s, e, nf); + + return rc; } int destroy_xen_mappings(unsigned long s, unsigned long e) diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index bf980eba8c..f0a1197e62 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -22,6 +22,7 @@ #include #include #include +#include /* Allow ring-3 access in long mode as guest cannot use ring 1 ... */ #define BASE_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_USER) @@ -651,6 +652,9 @@ static int __init dom0_construct(const struct boot_domain *bd) while ( count-- ) if ( assign_pages(mfn_to_page(_mfn(mfn++)), 1, d, 0) ) BUG(); + /* The initrd is dom0's now: out of the sparse directmap. */ + if ( sparse_dmap_remove(_mfn(initrd_mfn), PFN_UP(initrd_len)) ) + panic("Cannot unmap dom0's initrd\n"); /* * We have mapped the initrd directly into dom0, and assigned the * pages. Tell the boot_module handling that we've freed it, so the diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index a636e3205c..e52388ad28 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -54,6 +54,7 @@ #include #include #include +#include #include #include @@ -1938,6 +1939,9 @@ void asmlinkage __init noreturn __start_xen(void) system_state = SYS_STATE_boot; + /* The heap now has all memory: page-tables come from it from here on. */ + sparse_dmap_init(); + bsp_stack = cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ if ( !bsp_stack ) panic("No memory for BSP stack\n"); diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c new file mode 100644 index 0000000000..1eb092c3ea --- /dev/null +++ b/xen/arch/x86/sparse-directmap.c @@ -0,0 +1,424 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * A sparse view of the directmap. + * + * Xen maps all of RAM at DIRECTMAP_VIRT_START, and every root page-table + * carries those mappings. The sparse view is a second set of page-tables + * for the same virtual addresses (the part of the directmap PV guests can + * see, which is where everything Xen reaches through the directmap lives), + * mapping only what Xen needs to reach through the directmap at all times. + * + * Memory in the full directmap can be classified into three groups: + * + * - Memory never handed to the heap. This includes Xen's image, + * boot-time allocations, and firmware tables. Mapped in the sparse + * view. + * - Memory handed to the heap, and not allocated to the xenheap. Not + * mapped in the sparse view: guest memory will come from here. + * - Memory handed to the heap, then allocated to the xenheap. Mapped + * in the sparse view. + * + * Guest contexts selected on the command line run on root page-tables + * carrying the sparse view's L3s in the directmap slots. + * + * Conceptually, the sparse view starts as a copy of the full directmap + * (idle_pg_table's hierarchy), and then: + * - Removes memory when it is handed to the heap. + * - Adds pages back when they are allocated as xenheap pages, and removes + * them again when they are freed. + * - Mirrors changes to the full directmap (map_pages_to_xen(), + * modify_xen_mappings()). + * - Removes memory handed to a domain without passing through the heap + * (a PV dom0's initrd, used in place), and page-tables the boot + * allocator provided when idle_pg_table's hierarchy frees them. + * + * Every virtual address mapping in the sparse view should be either + * identical to the corresponding full view mapping, or empty. + * + * The sparse view is built once the boot allocator has handed its + * memory to the heap (sparse_dmap_init()). Until then, the hooks record + * the ranges handed to the heap and the xenheap allocations made from + * them, which sparse_dmap_init() leaves out and puts back. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +bool __ro_after_init opt_sparse_dmap_pv; +bool __ro_after_init opt_sparse_dmap_hvm; + +/* Root of the sparse view: only ever walked and copied from, never loaded. */ +static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIES]; +l4_pgentry_t *__ro_after_init sparse_dmap_root; + +/* + * Before the sparse view is built: the MFN ranges handed to the heap, which + * it leaves out, and the xenheap allocations made meanwhile (heap metadata of + * NUMA nodes), which it puts back. + */ +struct mfn_range { + unsigned long s, e; +}; +static struct mfn_range early_heap[256]; +static unsigned int nr_early_heap; +static struct mfn_range early_xenheap[2 * MAX_NUMNODES]; +static unsigned int nr_early_xenheap; +static bool early_overflow; + +/* + * Clip [*mfn, *mfn + *nr) to what the sparse view covers; false if nothing is + * left. + */ +static bool clip_to_sparse_view(unsigned long *mfn, unsigned long *nr) +{ + unsigned long end = SPARSE_DMAP_END_MFN; + + if ( *mfn >= end ) + return false; + if ( *nr > end - *mfn ) + *nr = end - *mfn; + + return *nr; +} + +static void early_range_add(struct mfn_range *r, unsigned int *nr, + unsigned int max, unsigned long s, unsigned long e) +{ + if ( *nr && r[*nr - 1].e == s ) + r[*nr - 1].e = e; + else if ( *nr < max ) + r[(*nr)++] = (struct mfn_range){ s, e }; + else + early_overflow = true; +} + +static void early_range_del(struct mfn_range *r, unsigned int *nr, + unsigned long s, unsigned long e) +{ + unsigned int i; + + for ( i = 0; i < *nr; i++ ) + if ( r[i].s == s && r[i].e == e ) + { + r[i] = r[--*nr]; + return; + } +} + +/* + * Copy the full directmap's mappings of MFNs [mfn, mfn + nr) into the sparse + * view. + */ +static int add_to_sparse_view(l4_pgentry_t *root, unsigned long mfn, + unsigned long nr) +{ + unsigned long va = (unsigned long)mfn_to_virt(mfn); + unsigned long end = va + (nr << PAGE_SHIFT); + + while ( va < end ) + { + pte_attr_t flags; + unsigned long n; + mfn_t m = xen_mapping_lookup(idle_pg_table, va, &flags, &n); + int rc; + + n = min(n, (end - va) >> PAGE_SHIFT); + if ( !mfn_eq(m, INVALID_MFN) && + (rc = map_pages_in(root, va, m, n, flags)) ) + return rc; + va += n << PAGE_SHIFT; + } + + return 0; +} + +static int remove_from_sparse_view(unsigned long mfn, unsigned long nr) +{ + unsigned long va = (unsigned long)mfn_to_virt(mfn); + + return modify_mappings_in(sparse_dmap_root, va, va + (nr << PAGE_SHIFT), + _PAGE_NONE); +} + +/* Memory is about to be handed to the heap allocator. */ +bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) +{ + unsigned long s = mfn_x(mfn); + + if ( !sparse_dmap_configured() || !clip_to_sparse_view(&s, &nr) ) + return true; + + if ( !sparse_dmap_root ) + { + early_range_add(early_heap, &nr_early_heap, ARRAY_SIZE(early_heap), + s, s + nr); + return true; + } + + if ( remove_from_sparse_view(s, nr) ) + { + printk(XENLOG_ERR + "sparse directmap: cannot unmap MFNs %#lx-%#lx, not freeing\n", + s, s + nr - 1); + return false; + } + + return true; +} + +/* + * Xenheap pages enter the sparse view, which guest contexts run on: they + * must not bring along what a previous owner left in them, such as a dying + * domain's data still awaiting the scrubber. Pages needing scrubbing are + * scrubbed as they are allocated then; clean ones need nothing. + */ +bool arch_xenheap_needs_scrub(void) +{ + return sparse_dmap_configured(); +} + +/* Pages have been allocated from the heap as xenheap pages. */ +int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) +{ + unsigned long s = mfn_x(mfn), nr = 1UL << order; + + if ( !sparse_dmap_configured() ) + return 0; + + /* Xenheap pages must be reachable through the sparse view. */ + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); + + if ( !sparse_dmap_root ) + { + early_range_add(early_xenheap, &nr_early_xenheap, + ARRAY_SIZE(early_xenheap), s, s + nr); + return 0; + } + + return add_to_sparse_view(sparse_dmap_root, s, nr); +} + +/* + * Xenheap pages are about to be freed. A failure means the pages may still + * be reachable through the sparse view, and must not be reused. + */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +{ + unsigned long s = mfn_x(mfn), nr = 1UL << order; + + if ( !sparse_dmap_configured() ) + return 0; + + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); + + if ( !sparse_dmap_root ) + { + early_range_del(early_xenheap, &nr_early_xenheap, s, s + nr); + return 0; + } + + return remove_from_sparse_view(s, nr); +} + +/* Memory leaves Xen's hands without passing through the heap. */ +int sparse_dmap_remove(mfn_t mfn, unsigned long nr) +{ + return arch_heap_pages_init(mfn, nr) ? 0 : -ENOMEM; +} + +/* + * A page-table page of idle_pg_table's hierarchy is about to be freed. One + * the boot allocator provided is in the sparse view, as every boot-time + * allocation is: take it out before the heap may hand it on. One allocated + * since came from the heap and is not in the sparse view, which a lookup + * finds without changing, or flushing, anything. Non-zero: the page may + * still be mapped, and must not be freed. + */ +int sparse_dmap_drop_pagetable(mfn_t mfn) +{ + unsigned long s = mfn_x(mfn), nr = 1, n; + pte_attr_t flags; + int rc; + + if ( !sparse_dmap_root || !clip_to_sparse_view(&s, &nr) || + mfn_eq(xen_mapping_lookup(sparse_dmap_root, + (unsigned long)mfn_to_virt(s), &flags, &n), + INVALID_MFN) ) + return 0; + + rc = remove_from_sparse_view(s, 1); + if ( rc ) + printk(XENLOG_WARNING + "Leaking page-table page %"PRI_mfn": still in the sparse directmap\n", + mfn_x(mfn)); + + return rc; +} + +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, + pte_attr_t flags) +{ + if ( !sparse_dmap_root || virt < SPARSE_DMAP_START || + virt >= SPARSE_DMAP_END ) + return 0; + + nr = min(nr, (SPARSE_DMAP_END - virt) >> PAGE_SHIFT); + + return map_pages_in(sparse_dmap_root, virt, mfn, nr, flags); +} + +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf) +{ + unsigned long va; + + if ( !sparse_dmap_root || e <= SPARSE_DMAP_START || + s >= SPARSE_DMAP_END ) + return 0; + + s = max(s, SPARSE_DMAP_START); + e = min(e, SPARSE_DMAP_END); + + if ( !(nf & _PAGE_PRESENT) ) + return modify_mappings_in(sparse_dmap_root, s, e, nf); + + /* + * A permission change applies where the sparse view maps anything: it + * never creates mappings, and the sparse view need not map all of [s, e). + */ + for ( va = s; va < e; ) + { + pte_attr_t flags; + unsigned long n; + mfn_t m = xen_mapping_lookup(sparse_dmap_root, va, &flags, &n); + int rc; + + n = min(n, (e - va) >> PAGE_SHIFT); + if ( !mfn_eq(m, INVALID_MFN) && + (rc = modify_mappings_in(sparse_dmap_root, va, + va + (n << PAGE_SHIFT), nf)) ) + return rc; + va += n << PAGE_SHIFT; + } + + return 0; +} + +static int __init cf_check cmp_mfn_range(const void *a, const void *b) +{ + const struct mfn_range *l = a, *r = b; + + return l->s < r->s ? -1 : l->s > r->s; +} + +static void __init cf_check swap_mfn_range(void *a, void *b) +{ + SWAP(*(struct mfn_range *)a, *(struct mfn_range *)b); +} + +/* + * Build the sparse view: the full directmap, minus the ranges handed to the + * heap so far, plus the xenheap allocations made from them. Called once the + * heap has taken over from the boot allocator, so that the page-tables come + * from the heap, and before any other CPU is up. + */ +void __init sparse_dmap_init(void) +{ + unsigned long va, mapped = 0; + unsigned int i, j; + + if ( !sparse_dmap_configured() ) + return; + + if ( early_overflow ) + { + printk(XENLOG_WARNING + "Sparse directmap: too many early heap ranges, disabled\n"); + opt_sparse_dmap_pv = opt_sparse_dmap_hvm = false; + return; + } + + /* An L3 for every slot, so that the L4 entries never change. */ + for ( va = SPARSE_DMAP_START; va < SPARSE_DMAP_END; + va += 1UL << L4_PAGETABLE_SHIFT ) + { + mfn_t l3mfn; + void *l3t = alloc_mapped_pagetable(&l3mfn); + + if ( !l3t ) + panic("Sparse directmap: out of memory\n"); + unmap_domain_page(l3t); + sparse_l4[l4_table_offset(va)] = + l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR); + } + + sort(early_heap, nr_early_heap, sizeof(*early_heap), cmp_mfn_range, + swap_mfn_range); + + /* + * The full directmap, leaf by leaf, minus the ranges added to the + * heap. Leaves come in address order, which is MFN order in the + * directmap, so the cursor into the sorted (and disjoint) heap + * ranges only moves forward. + */ + for ( va = SPARSE_DMAP_START, j = 0; va < SPARSE_DMAP_END; ) + { + pte_attr_t flags; + unsigned long n, s, e; + mfn_t m = xen_mapping_lookup(idle_pg_table, va, &flags, &n); + + n = min(n, (SPARSE_DMAP_END - va) >> PAGE_SHIFT); + if ( mfn_eq(m, INVALID_MFN) ) + { + va += n << PAGE_SHIFT; + continue; + } + + for ( s = mfn_x(m), e = s + n; s < e; ) + { + unsigned long upto = e; + + while ( j < nr_early_heap && early_heap[j].e <= s ) + j++; + if ( j < nr_early_heap && early_heap[j].s <= s ) + { + s = min(e, early_heap[j].e); + continue; + } + if ( j < nr_early_heap ) + upto = min(e, early_heap[j].s); + + if ( map_pages_in(sparse_l4, va + ((s - mfn_x(m)) << PAGE_SHIFT), + _mfn(s), upto - s, flags) ) + panic("Sparse directmap: out of memory\n"); + mapped += upto - s; + s = upto; + } + + va += n << PAGE_SHIFT; + } + + /* + * Now add back in ranges from the heap which were allocated to + * the xenheap. + */ + for ( i = 0; i < nr_early_xenheap; i++ ) + { + unsigned long nr = early_xenheap[i].e - early_xenheap[i].s; + + if ( add_to_sparse_view(sparse_l4, early_xenheap[i].s, nr) ) + panic("Sparse directmap: out of memory\n"); + mapped += nr; + } + + sparse_dmap_root = sparse_l4; + + printk(XENLOG_INFO "Sparse directmap: %lu pages mapped\n", mapped); +} diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 5b289e444f..8f2f605e45 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -167,6 +167,9 @@ config HAS_STATIC_MEMORY config HAS_SOFT_RESET bool +config HAS_SPARSE_DIRECTMAP + bool + config HAS_STACK_PROTECTOR bool @@ -299,6 +302,21 @@ config SPECULATIVE_HARDEN_LOCK This option is disabled by default at run time, and needs to be enabled on the command line. + +config SPARSE_DIRECTMAP + bool "Sparse directmap view" + depends on HAS_SPARSE_DIRECTMAP + help + Build support for a sparse view of the directmap, alongside the + full one: it maps only the memory Xen needs to reach at all times + (the Xen heap, Xen's own image, firmware tables), while guest + memory is reached through transient mappings. Guest contexts + selected with the `asi=` command line option run on the sparse + directmap view, narrowing the memory reachable from Xen's address + space while they run, and hence the memory disclosure surface of + speculative side channels. + + If unsure, say N. endmenu menu "Other hardening" diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index fe150eccd7..69e8e982b6 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1971,6 +1971,9 @@ static void init_heap_pages( unsigned long i; bool need_scrub = scrub_debug; + if ( !arch_heap_pages_init(page_to_mfn(pg), nr_pages) ) + return; + /* * Keep MFN 0 away from the buddy allocator to avoid crossing zone * boundary when merging two buddies. @@ -2540,10 +2543,33 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags) if ( !(memflags >> _MEMF_bits) ) memflags |= MEMF_bits(xenheap_bits); - pg = alloc_domheap_pages(NULL, order, memflags | MEMF_no_scrub); + /* + * Pages still awaiting scrubbing may do as xenheap pages: the directmap + * maps them anyway. Not so if an arch's sparse directmap view makes them + * reachable where the rest of the heap's memory is not. + */ + if ( !arch_xenheap_needs_scrub() ) + memflags |= MEMF_no_scrub; + + pg = alloc_domheap_pages(NULL, order, memflags); if ( unlikely(pg == NULL) ) return NULL; + if ( arch_xenheap_pages_alloc(page_to_mfn(pg), order) ) + { + /* + * The hook may have mapped part of the pages before failing: take + * them out again as a free would, and leak them if that fails too. + */ + if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + printk(XENLOG_WARNING + "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", + mfn_x(page_to_mfn(pg)), 1U << order); + else + free_domheap_pages(pg, order); + return NULL; + } + for ( i = 0; i < (1u << order); i++ ) pg[i].count_info |= PGC_xen_heap; @@ -2562,6 +2588,19 @@ void free_xenheap_pages(void *v, unsigned int order) pg = virt_to_page(v); + /* + * If the pages cannot be taken out of an arch's sparse directmap view, + * they may remain reachable through it: leak them rather than hand them + * out. + */ + if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + { + printk(XENLOG_WARNING + "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", + mfn_x(page_to_mfn(pg)), 1U << order); + return; + } + for ( i = 0; i < (1u << order); i++ ) pg[i].count_info &= ~PGC_xen_heap; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 153c57f5dd..2bcc45cf58 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -94,6 +94,41 @@ bool scrub_free_pages(void); #define alloc_xenheap_page() (alloc_xenheap_pages(0,0)) #define free_xenheap_page(v) (free_xenheap_pages(v,0)) +/* + * Hooks for an architecture keeping a second, sparse view of its directmap, + * which maps the xenheap but not the rest of the heap's memory. + */ +#ifdef CONFIG_SPARSE_DIRECTMAP +/* Memory is about to be handed to the heap. False: don't, keep it out. */ +bool arch_heap_pages_init(mfn_t mfn, unsigned long nr); +/* Xenheap pages are to be allocated. True: scrub those needing it first. */ +bool arch_xenheap_needs_scrub(void); +/* + * Xenheap pages were allocated. Non-zero: failed, possibly part-way; the + * pages go through arch_xenheap_pages_free() before being freed again. + */ +int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order); +/* Xenheap pages are to be freed. Non-zero: failed, don't reuse them. */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order); +#else +static inline bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) +{ + return true; +} +static inline bool arch_xenheap_needs_scrub(void) +{ + return false; +} +static inline int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) +{ + return 0; +} +static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +{ + return 0; +} +#endif + /* Free an allocation, and zero the pointer to it. */ #define FREE_XENHEAP_PAGES(p, o) do { \ void *_ptr_ = (p); \ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:00:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:00:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442175.1659750 (Exim 4.92) (envelope-from ) id 1xEPNs-0006JX-NV; Wed, 07 Oct 2026 11:00:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442175.1659750; Wed, 07 Oct 2026 11:00: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 1xEPNs-0006HI-IQ; Wed, 07 Oct 2026 11:00:28 +0000 Received: by outflank-mailman (input) for mailman id 1442175; Wed, 07 Oct 2026 11:00:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPNq-0005y3-FD for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:00:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEPNq-001bwM-0X; Wed, 07 Oct 2026 11:00:26 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96) (envelope-from ) id 1xEP5I-001QnT-0o; Wed, 07 Oct 2026 10:41: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=uTtFastgCN5QzSIxMSLM2WRMVTyMNwx08i8QJomPSZ4=; b=E/3A8IsJsQ8CdM5jaS3m1u6wCc MAfj8CUS0mhwRfZtW0E/DI7wswq0NEUGyP/mGzmDs0gQa8MbsiBpzeVG4BJ4Fl4KTHd/KsRRYK2B7 OR+YgZwi/PQbLU07SpnvZIXi+fke+SaQGfI+nElTTto0z3tCI092ceDbBw/t7+hO93b8=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3 16/18] x86/domain_page: keep the maphash's slots, not their mappings Date: Wed, 7 Oct 2026 11:40:49 +0100 Message-ID: <20261007104051.48841-17-gwd@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261007104051.48841-1-gwd@xenproject.org> References: <20261007104051.48841-1-gwd@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit unmap_domain_page() keeps a recently unmapped slot in the vCPU's maphash (MAPHASH_ENTRIES, 8 per vCPU) for a quick remap of the same MFN, and leaves its PTE in place until the entry is displaced by a later unmap or reclaimed by a full cache. Until then the page stays mapped, although nothing refers to the mapping and the mapcache holds no reference to the page. A page freed meanwhile and handed to another domain stays mapped in the previous user's mapcache: in the vCPU's own area for a domain with per-vCPU page-tables, in the domain-wide area of a PV domain, where all of its vCPUs can reach it. While the full directmap is loaded, that reaches nothing it does not map anyway. On the sparse view of the directmap, Xen reaches domain-heap memory only through mappings made for the purpose, and a mapping kept in the maphash would leave another domain's page reachable from a context which has nothing to do with it. Keep the slot, not the mapping: unmapping the last reference zaps the PTE and keeps the hash entry, and a later hit maps the page again in the same slot. The slot has mapped nothing else in between, so that needs no flush. Reusing the slot for another page still goes through the garbage map, or through the replacement of a hash entry when the cache is full, both of which flush first. A translation of the zapped PTE left in a TLB is covered, for owned pages, by the flush the page allocator arranges before a freed page is reused wherever a sparse view is configured ("x86/mm: flush owned pages before reuse with the sparse directmap view"). The cost is one PTE write per unmap into the maphash and per remap from it. A second unmap of an entry in the maphash now finds its PTE not present and is caught by the check unmap_domain_page() has for entries the first unmap zapped, rather than by the reference count's ASSERT() in debug builds only. The change does not depend on asi= or on a sparse view of the directmap being configured. PV vCPUs use the domain-wide mapcache on the default command line too: in debug builds for every page, in release builds for pages beyond the reach of the full directmap in their page-tables (5TiB, 3.5TiB with CONFIG_BIGMEM). For them the change adds the PTE writes above. It also leaves up to MAPHASH_ENTRIES fewer pages per vCPU mapped in the domain-wide area. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v3: - New in this version. --- xen/arch/x86/domain_page.c | 34 +++++++++++++++++++++++-------- xen/arch/x86/include/asm/domain.h | 5 ++++- 2 files changed, 30 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 48f85b670d..eee66b848c 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -195,6 +195,14 @@ void *map_domain_page(mfn_t mfn) { idx = hashent->idx; ASSERT(idx < cache->entries); + /* + * An entry the maphash kept holds on to its slot, not to its mapping + * (see unmap_domain_page()): map the page again. No flush is needed, + * as the slot has mapped nothing else since. + */ + if ( !hashent->refcnt ) + l1e_write(&MAPCACHE_L1ENT(idx), + l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW)); hashent->refcnt++; ASSERT(hashent->refcnt); ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn)); @@ -227,8 +235,8 @@ void *map_domain_page(mfn_t mfn) if ( hashent->idx != MAPHASHENT_NOTINUSE && !hashent->refcnt ) { idx = hashent->idx; - ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) == hashent->mfn); - l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); + ASSERT(!(l1e_get_flags(MAPCACHE_L1ENT(idx)) & + _PAGE_PRESENT)); hashent->idx = MAPHASHENT_NOTINUSE; hashent->mfn = ~0UL; break; @@ -298,25 +306,35 @@ void unmap_domain_page(const void *ptr) local_irq_save(flags); + /* + * The maphash keeps recently freed slots for a quick remap of the same + * page, but not their mappings: the page may change hands meanwhile, and + * must not stay reachable from this context then. A translation left in + * a TLB is covered, for owned pages, by the flush the page allocator + * arranges before a freed page is handed out again wherever a sparse + * directmap view is configured; without one, the directmap maps the page + * anyway. + */ if ( hashent->idx == idx ) { ASSERT(hashent->mfn == mfn); ASSERT(hashent->refcnt); hashent->refcnt--; + if ( !hashent->refcnt ) + l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); } else if ( !hashent->refcnt ) { + /* The entry replaced has no mapping left: mark its slot as garbage. */ if ( hashent->idx != MAPHASHENT_NOTINUSE ) { - /* /First/, zap the PTE. */ - ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(hashent->idx)) == - hashent->mfn); - l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty()); - /* /Second/, mark as garbage. */ + ASSERT(!(l1e_get_flags(MAPCACHE_L1ENT(hashent->idx)) & + _PAGE_PRESENT)); set_bit(hashent->idx, cache->garbage); } - /* Add newly-freed mapping to the maphash. */ + /* Add the newly-freed slot to the maphash, without its mapping. */ + l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); hashent->mfn = mfn; hashent->idx = idx; } diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 76a22b4040..51741f9d42 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -74,7 +74,10 @@ struct mapcache_vcpu { /* Shadow of mapcache_domain.epoch. */ unsigned int shadow_epoch; - /* Lock-free per-VCPU hash of recently-used mappings. */ + /* + * Lock-free per-VCPU hash of recently-used mappings. An entry without + * references keeps its slot but not its mapping (see unmap_domain_page()). + */ struct vcpu_maphash_entry { unsigned long mfn; uint32_t idx; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:01:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:01:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442210.1659808 (Exim 4.92) (envelope-from ) id 1xEPPC-0001mZ-IW; Wed, 07 Oct 2026 11:01:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442210.1659808; Wed, 07 Oct 2026 11: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 1xEPPC-0001mS-Fk; Wed, 07 Oct 2026 11:01:50 +0000 Received: by outflank-mailman (input) for mailman id 1442210; Wed, 07 Oct 2026 11:01:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEPPB-0001le-EA for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:01:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEPPA-008pDh-Di for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:01:48 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac62698-bab6-0a2a0a5309dd-0a2a4508cf88-12 for ; Wed, 07 Oct 2026 13:01:48 +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 6ac6269b-f659-0a2a45080019-b9ff1c22a3eb-3 for ; Wed, 07 Oct 2026 13:01: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 1a11606beaf0003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 11:01:43 +0000 Received: from [192.168.1.17] (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 E825981FAA for ; Wed, 7 Oct 2026 13:01:38 +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: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=aSZZkSioV2HZ1n7DfrheCNoDkgkMOhWqs5CzorKW/IE=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=anuwEmJAut0Np04wLmk92Qk7O6fiNQkW3Rznpnp4eHpHQfH+8p/C+j9VLkwbwYJ4VSgBMKZ+7 tBhlbouHDmpXBVst7Tw0tNEEK4Yr5Qhtr5HYAbKm2RVuVgMgSrl7Ub/4+y+Iv1vZ7BGvXiie6AY vQ01UArV/w4KrJ2FfJR0uCtTEemTnHtpvBLTAHfL35d0i0Q7I7ksewvnUxgfHa5QEzS8XNOTGbr r+GxKWkNP1j1ceoZy7IBmviIU94tHkGEW/eLtD+yrV8qwDoK1P4aTokGBH+t7ZfYDDO2D8WYjEi 6B/lUQFRLgt6VlhZnPa1g7IdMtUXZ1van5wLrY2flLOA== X-Zone-Loop: 1d780a8d8004902239c1a81cd51fa76795558e39928c x-campaign-type: default x-transaction-id: 8529ca9c-da92-4715-8f8f-996734edac51 x-swg-uid: 01-691bbcec-7612-48ce-8a48-f7e09970ab8e X-Mailer: Sweego Message-ID: <1791370903.8631fc262581453bbf619ec5b2062170.1a11606beaf0003f66@vates.tech> x-swg-bid: 1791370903.8631fc262581453bbf619ec5b2062170.1a11606beaf0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 7 Oct 2026 13:01:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: xen-devel@lists.xenproject.org References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <1791327013.8631fc262581453bbf619ec5b2062170.1a113690c000003f66@vates.tech> <1791361284.8631fc262581453bbf619ec5b2062170.1a11573f8520003f66@vates.tech> <1791364402.8631fc262581453bbf619ec5b2062170.1a115a38ea30003f66@vates.tech> Content-Language: en-US From: Baptiste Le Duc In-Reply-To: <1791364402.8631fc262581453bbf619ec5b2062170.1a115a38ea30003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791370898998 X-purgate-ID: tlsNG-c1860d/1791370908-CCB7187B-A3484DAB/0/0 X-purgate-type: clean X-purgate-size: 4447 On 10/7/26 11:13, Teddy Astie wrote: > Le 07/10/2026 à 10:24, Baptiste Le Duc a écrit : >> On 10/7/26 00:50, Teddy Astie wrote: >>> Le 05/10/2026 à 18:02, Baptiste Le Duc a écrit : >>>> A RISC-V implementation can manage the PTE A/D bits in one of two >>>> ways: >>>>      1) Update the 'A' and 'D' PTE bits in hardware (ratified as >>>> Svadu). >>>>      2) Generate a page fault when 'A' and/or 'D' is clear, so that >>>> software >>>>         can set them (ratified as Svade). >>>> >>>> p2m_set_pte_flags() presets A/D in G-stage PTEs only when the >>>> device tree >>>> advertises Svade. Platforms that use scheme (2) without advertising >>>> Svade, >>>> such as the HiFive Premier P550, then hit guest-page faults that >>>> Xen does >>>> not handle. >>> >>> I second what Jan said (this is likely a firmware bug, given that >>> the enumerated behavior is not consistent with the specification, as >>> existence of Svadu/Svade alters observable behavior). >>> >> Thanks, agreed on both points. >> >> I'll reword the commit message: it shouldn't imply that Svade in the >> DT means faults will occur, since with Svadu also present that >> depends on henvcfg.ADUE. >> >> On the firmware-bug point: I don't think the P550 is really >> inconsistent with the spec. Svade and Svadu didn't exist when the >> P550 core was designed. They were only ratified later, to name the >> two behaviors that already existed in the wild. Before that, the >> privileged spec just allowed either: hardware updating A/D, or >> raising a page fault. The P550 implements the second, and there was >> no extension it could advertise for it. >> Therefore, the DT lacks svade because the extension didn't exist when >> the platform description was written, not because the vendor >> misdescribed anything. >> > > At least in latest specification, absence of Svade implies that A/D > bit is updated on page-table access. > > The spec also insist on the no-Svade behavior. > > > 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. > > > > (... hardware updates A/D bit) > > The no-Svade behavior can then be re-introduced with Svadu with ADUE=1 > > > If the Svadu extension is implemented, the ADUE bit controls whether > > hardware updating of PTE A/D bits is enabled for VS-stage address > > translation. When ADUE=1, hardware updating of PTE A/D bits is enabled > > during VS-stage address translation, and the implementation behaves as > > though the Svade extension were not implemented for VS-mode address > > translation. When ADUE=0, the implementation behaves as though Svade > > were implemented for VS-stage address translation. If Svadu is not > > implemented, ADUE is read-only zero. > > The specification is unfortunately written a bit sideways, the base > behavior happens to be "opt-in" through another extension. I'm not sure this holds for the !Svade && !Svadu case. In fact, in that case, my strict reading of the text from spec above is : "If the Svadu extension is implemented" then:         - "ADUE=0 => Svade" Therefore, in !Svade && !Svadu case, if we followed the spec, we would felt into "When the Svade extension is not implemented, the following scheme applies [...] -> hardware updates A/D bits" However, it is not the case of the P550 that doesn't support hw updates of A/D bits... Do you read it the same way, or am I missing something? > > But that's specification, and it's possible that firmware follows a > earlier revision of it that has unspecified A/D semantics instead. But > in this case, the firmware is out of sync with current specifications > and probably wants to be updated. >> I agree that, where Svadu is available, Xen should ideally configure >> a consistent scheme (ADUE=1) and use ADUE=0 only for specific needs >> such as dirty tracking. But Xen doesn't support Svadu today, so that >> is a separate piece of work which I'd prefer to do later. >> >> In the meantime, presetting A/D in the G-stage PTEs is the only way >> to avoid the faults on hardware like the P550, and it is harmless on >> hardware that updates A/D itself. > > Looks good to me. >> > From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:32:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:32:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442233.1659818 (Exim 4.92) (envelope-from ) id 1xEPt3-0006Bv-QN; Wed, 07 Oct 2026 11:32:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442233.1659818; Wed, 07 Oct 2026 11:32: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 1xEPt3-0006Bo-NP; Wed, 07 Oct 2026 11:32:41 +0000 Received: by outflank-mailman (input) for mailman id 1442233; Wed, 07 Oct 2026 11:32:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEPt2-0006Bi-3o for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:32:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEPt1-0025OF-C5 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:32:39 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac62dd0-2eae-0a2a0a5409dd-0a2a4503bc42-18 for ; Wed, 07 Oct 2026 13:32:39 +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 6ac62dd7-fae8-0a2a45030019-d1558036f07b-3 for ; Wed, 07 Oct 2026 13:32:39 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a0286c981dso36121115e9.2 for ; Wed, 07 Oct 2026 04:32: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 ffacd0b85a97d-48c71b786d8sm5059564f8f.0.2026.10.07.04.32.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 04:32: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=1791372759; x=1791977559; 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=PHW3B5o3N3ilCM+9E2QvAbEwtGUHiB9qDO2zWEqNFUA=; b=ivxqzcRuauiGIoqvmS4RGsKN5HvnMv66qEgYpALyDqsu0bEwevnFVRSH/XvaEEK4uG tRSRGfIYonUMhsymaymxu/ztdpvgGQ0BEunWsD8qlttYfumRUwNXLbXuP/0YBA4xiJqk HNTvVYeIXIIekkkd/hRHx7GMsM+zROriq6xcfr9iCC+TQwOt+6U51QNkXP3k6VA2ib69 Uy+elEZ2NKIznS7GRUAjZcgPvG7K8K6kK7KeCfoBQPDCR94K79a60WMlby3rKaxU5Zqm ttqjgZiflJzqHaQ4hkEyyKkuPACT6bJJwZjZ6BELYwp0Q7+yANdRjT7z6wLBFWxw96qI pzOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791372759; x=1791977559; 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=PHW3B5o3N3ilCM+9E2QvAbEwtGUHiB9qDO2zWEqNFUA=; b=JtEQdAM5k87Vl2ZfdFeR0Xq8vITcoUKrtl7N08YUq6s2cFEscfmXhsOtTnOJw9bQ9e GaAqNM3pKS3mdaBqcay0rD4pOlaZGVPw1bV5x4KUh8/LIPzGDCnoeerGvA7YfzAIjXK0 JkzfnKwHDhD+D42dV4kIEZais3VDxUbR/sHVHiDQbGNcwl1Pa+T+D8wJjxjR72O953Xr k7abBLAqmniAiiXfKyZtvyi+jysCqh/2G9fLhZInhavOfZ4vcBf51R7HFiwESwx0gMnf M5x7cmSs7ZOAwy/zj8AbL4647TjeGDOn4ReipA7r1H2mTkvOgPu4K7ED8z7ma7sTS4Su 12YA== X-Forwarded-Encrypted: i=1; AKwUvBzZ+mv9XoXHa3aZ1iDpABRiku4vYmFZIlMAR9/mTpOoQ2HlNM8NQsUBWthUsP1ez9XywrIJP+ioff8=@lists.xenproject.org X-Gm-Message-State: AFuF++nN8at7yhETHz/eMEaS5aweiSPsUxYVrZa0ZUweuFj7b8NV9Kqs t7Nc3vtawDWcUdb++BvF1rGd8WY9xJZJU26Zr/5Cur9TLXyThVr1HOY9 X-Gm-Gg: AYBFou2QucPoMEwYZuj0pSRZQHx4l4utO0qY1pby29oAqhCQyIRjxOBRDarWkX/cGoU drnYrBWhxhLPS37GYVD1YrUGt57tgwaGEy+H+O7pBnUFD5XrWTwzDPaVaguGd01LE7myORByk7X g3AEoapNdGC2I5kRkTFLIqLcG6g+LbsoR5DFmHk7vmWfvKyKeHs33lj76eKn7qBCXXERERWxCa7 ObHeHXDv2S/bbYeMGoKbTjQ5VU+3naZ0Yy4jxBTn2rB5VP09P4OLiYntnJoVEhfcBAy62UmOXz2 ppIvlv8f7qvSPT/hc70ZiYhM5vlBYnT13qD8hyuc66XiKH+T3Q8eumhfNaiTM4Z++XySBvCUang 6wbaVSNrdsTP8SyshvDuhGnDlONuXtMSYrYjSFXZWjn03cZJmlid0HjjL0QMk8mz2CtB/WfwAFr zj+RMokJLGQA8Wl/izZEBohkbqHgaluDRBJctag1I0fis+5/eIYDnOKNELJdy5mglnlhm16R+7P 5MwXCcfdGSYXLzI3xpS3u/OYThYWueLoY4fVKxMuZDFlE2mOdvCCPzEqHov X-Received: by 2002:a05:600c:8b09:b0:4a1:7ce1:2eaf with SMTP id 5b1f17b1804b1-4a180682d24mr27212855e9.34.1791372758428; Wed, 07 Oct 2026 04:32:38 -0700 (PDT) Message-ID: Date: Wed, 7 Oct 2026 13:32:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> <4a0b0d62-c312-43c1-908a-fcff7c081149@gmail.com> <4fa78acf-4de9-48bc-aea8-fed774d80cfa@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <4fa78acf-4de9-48bc-aea8-fed774d80cfa@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1791372759-76EF74E9-ADA12144/10/73395122804 X-purgate-type: spam X-purgate-size: 8129 On 10/7/26 12:44 PM, Jan Beulich wrote: > On 07.10.2026 12:03, Oleksii Kurochko wrote: >> On 10/6/26 5:20 PM, Jan Beulich wrote: >>> On 05.10.2026 18:00, Baptiste Le Duc wrote: >>>> A RISC-V implementation can manage the PTE A/D bits in one of two ways: >>>> 1) Update the 'A' and 'D' PTE bits in hardware (ratified as Svadu). >>>> 2) Generate a page fault when 'A' and/or 'D' is clear, so that software >>>> can set them (ratified as Svade). >>>> >>>> p2m_set_pte_flags() presets A/D in G-stage PTEs only when the device tree >>>> advertises Svade. >> >> According to the code it seems like it is setting A/D bits always >> independently on what is DT file. Baptiste, am I missing something? >> >> Platforms that use scheme (2) without advertising Svade, >>>> such as the HiFive Premier P550, then hit guest-page faults that Xen does >>>> not handle. >>> >>> Is that a quirk then (to avoid the word "bug")? Since it's all DT that >>> conveys available ISA information, why can't the DT for those systems >>> simply be fixed? Depending on the answer here I might question the >>> presence of the Fixes: tag below. >> >> I think it can at some point. Let me clarify why "at some point"... >> >> So how the things are working now: >> >> OpenSBI detects the available ISA extensions in two steps: >> 1. It parses the CPU nodes in the DTB. If a node has the >> riscv,isa-extensions property, OpenSBI uses it; otherwise it falls back >> to riscv,isa. riscv,isa-extensions describes the same extensions as >> riscv,isa, but as a list of strings, which makes it easier to parse. >> From this, OpenSBI builds a per-hart bitmap of available extensions >> (basically what we do in Xen). (Platform-specific code can also add >> extensions to the bitmap at this step.) >> 2. It then probes a small, fixed set of extensions (Sstc, Smaia, >> Sscofpmf, Smstateen, Ssstateen, Smcntrpmf, Sdtrig) by reading a CSR that >> the extension introduces and checking whether the access traps. This is >> similar to what we do for Sstc in Xen. >> >> Step 2 only adds extensions to the bitmap. It does not check or clear >> the extensions that came from the DT; the only exception is Zicntr, >> which is detected purely by probing. So for extensions such as >> Svade/Svadu, which have no CSR to probe, the DT is the only source of truth. >> Now, what OpenSBI does with Svade/Svadu specifically. First, it disables >> hardware A/D updating by default, i.e. it clears menvcfg.ADUE: >> >> Now, what OpenSBI does with Svade/Svadu specifically. First, it disables >> hardware A/D updating by default, i.e. it clears menvcfg.ADUE: >> >> /* Disable HW A/D updating by default */ >> menvcfg_val &= ~ENVCFG_ADUE; >> >> Then it sets ADUE again, depending on which extensions are listed in the >> DTB: >> >> /* >> * Assume only Svadu is supported when it is the only extension >> * present in the ISA string. Svade is assumed when neither are >> * present. When both are present we must default to Svade (see >> * the zero reset value of FWFT.PTE_AD_HW_UPDATING). >> */ >> if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE)) >> __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE); >> >> So all OpenSBI does is set or clear menvcfg.ADUE based on what is >> mentined in DTB. >> >> So, to answer your original question: yes, this can be fixed just by >> updating the DTS. OpenSBI will then configure menvcfg.ADUE according to >> the extensions listed there. Note that the logic above is from OpenSBI >> v1.9. Versions v1.5–v1.8 behave the same when the DT lists only svadu, >> only svade, or both. When neither is listed, they leave ADUE unchanged >> instead of clearing it. Versions before v1.5 don't handle Svade/Svadu at >> all. >> >> But IIRC such approach was suggested in one of vX and it was rejected >> because we can't in Xen be sure that passed DTB is correct and >> corresponds to how real h/w is configured as specifically with ADUE bit >> in menvcfg we can't read it in HS-mode as an exception will occur as it >> is M-mode register. So we have to trust that OpenSBI (or other firmware >> will configure the A/D update scheme according to what is mentioned in DTS). >> >> So then basically the question is do we want to rely on that how OpenSBI >> configures h/w? >> >> It seems like it could be fine. For example, without support for the >> FWFT extension, we can't access or change the menvcfg bit anyway. The >> FWFT extension was ratified in 2025, so we have to trust OpenSBI anyway >> (or introduce our own extension or port the FWFT extension to an earlier >> OpenSBI version) before FWFT is started to be available. >> >> With this explanation would you (Jan) be okay to go with just providing >> proper DTS? > > I can't answer this, as I lack details on where the DTS is coming from. > So far I thought this was a blob handed to Xen (as kind of a module) at > boot. What you say above makes me uncertain about that. If it is a blob > as I thought, how difficult is it for people to edit a broken blob, for > it to correctly reflect their hardware's capabilities? It depends... So usually the things are going in this way products like U-boot, Linux has dts in its code source base and then these DTSes are compiled by build system to DTB, and then this DTB is put to the place where U-boot, Linux can reach it, or U-boot provides through a register DTB to Linux. Sometimes it also could be a case when what is U-boot/Linux source code base is taken as a base and then a new dts is provided based on them, for example, to choose what h/w should be enabled/disabled or probably for some specific board some device is connected to a different pin and so DTS will be needed to be updated, and so on... From one side, it could be super easy as DTB (blob) could be taken by anyone then just decompile (it using a default dtc compiler) to DTS, update the necessary properties and then updated DTS (using dtc compiler again) compile back to DTB. But on the other side it could be some kind of secure boot where all the binaries are signed and then it will be pretty hard to decompile and compile DTB with the same sign.... > > If that's not "very simple", or if there's concern that people may > object to doing such editing, then I think we could (should) go without > that. All I then would ask is that the description be clarified a > little further (clarifying that absence of both extensions is a valid, > albeit historical situation). > Also I am looking at henvcfg register which we could access in HS-mode and it also has ADUE bit and the description for it is the following: ``` If the Svadu extension is implemented, the ADUE bit controls whether hardware updating of PTE A/D bits is enabled for VS-stage address translation. When ADUE=1, hardware updating of PTE A/D bits is enabled during VS-stage address translation, and the implementation behaves as though the Svade extension were not implemented for VS-mode address translation. When ADUE=0, the implementation behaves as though Svade were implemented for VS-stage address translation. If Svadu is not implemented, ADUE is read-only zero ``` So, at some point, we could verify how OpenSBI configured the hardware and compare it with what is specified in the DTS file. The only problem is how to interpret this part: “If Svadu is not implemented, ADUE is read-only zero.” The spec does not explicitly state that Svade will be used in this case, but logically, it seems that if Svadu is not implemented, the implementation has no other choice but to provide Svade and so basically we could detect if Svade is used based only on ADUE bit. If we accept this assumption, we could fully verify, in HS-mode, both what is specified in the DTS and how OpenSBI configured the hardware. This would allow us to require users to provide a proper DTS with the A/D bits update scheme correctly specified. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:40:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:40:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442240.1659826 (Exim 4.92) (envelope-from ) id 1xEQ0b-0007pD-Fl; Wed, 07 Oct 2026 11:40:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442240.1659826; Wed, 07 Oct 2026 11:40: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 1xEQ0b-0007p6-DB; Wed, 07 Oct 2026 11:40:29 +0000 Received: by outflank-mailman (input) for mailman id 1442240; Wed, 07 Oct 2026 11:40:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEQ0a-0007p0-8O for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:40:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEQ0Z-00959A-Ep for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:40:27 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac62f9f-e002-0a2a0a5209dd-0a2a4506d762-30 for ; Wed, 07 Oct 2026 13:40:27 +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 6ac62fab-195a-0a2a45060019-d1558035b470-3 for ; Wed, 07 Oct 2026 13:40:27 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a021c809e3so17362535e9.0 for ; Wed, 07 Oct 2026 04:40:27 -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-4a178c33091sm146321435e9.4.2026.10.07.04.40.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 04:40: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: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=1791373227; x=1791978027; 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=fxQn707ALc/LL3QUmDsNHwOoEljnAO3jUsJRBgN2r8U=; b=Pf9f1r8YKNAu/4c6v1C1FmDgiW54idOe95XTC4cdv5NLFBDr/Kp3vbXjohlUK/z69m Hcac7t/eEA4Zm04nYeWOAPB14yncHQMuULeGTb7jOEMRLfAK2YFe5Dq4sjoKJP3Wp1wB bCA58KXPzn22BaFMMKdUdfu5b8nFXieP9EtIIFVXOY39Aha2iLs5KlgGnRehI0k5pXmH kCVpO1nugS9uQXa/df7mL0tRoeK3pFnzuraMhR9zzG/se5hqfPQt9gm54lZATzUB508w XRPzACYt4njkucKTVzuH8lFDYwRKn9hOiWc2XqtkS46m9ovFfc+QnOTdfkGKr5csUAfk m8Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791373227; x=1791978027; 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=fxQn707ALc/LL3QUmDsNHwOoEljnAO3jUsJRBgN2r8U=; b=DIQPF7QU6wgFrmL47o6j0z+CdKX370N77Y5nY+DGZ9HF2fUIcmTak1oNJcT0gHpQj4 FQ5Ik+IMkE8NADF505lktixZNNKnuMu4/qnvq0nwd2vLLE1T4AMxKpCln3RT4xYruz2g YUz9+Xv5AAC6MZxC00GlYshy5AixrvM0/8MO9LIUaVtLwEnWHmhdkID/Mfn24cQCoOMD aVdrE4SNhH56P5Y79yY+OtoG2RsaVfzE5/tD9hsfGwn0Nx/RYmly1uH7SyR0np7IzCkp Zxpp0JSXp2ieECvTS5sGelzar05hzCw/hdWjIKQpzfNTXKwlKQWkGu1Ki/KfgudvE/on jTyA== X-Forwarded-Encrypted: i=1; AKwUvBzMdsxuZQy2jf9FEUoQ8fvhl+dVulZyBbqUt9/PAyppVK+0xA7eDUhb726j65KEQHg3HA3pJ+zqDg0=@lists.xenproject.org X-Gm-Message-State: AFuF++l/ynSbgfuqR0Pgm6qPFQBLIjvctMz2R0noRqSN9oUFOk2/P4QH pHGQxtexa+Ftx1m657RTa/o3088vRy8YZWSgzyW7NI/kchqGeCRsCsqf X-Gm-Gg: AYBFou2zKPIWjVqtNfrkNdg5qfcg1LQBgCBiJiLbP9wHcuzPmSS7p8ptad2mNOrxZDc P/CxyjMMF0xH04VAVtrM/j5P+TEt8lWDnoWnTWri8hZiJb6iXtiZkar1lcHCLCLTaZHH7EkI4nH 3Klx0hoaz2QYuMmvsfRf9ZOneBkzOHwdxWqAqS72nhyLagTASwtJ334zA3v018SI41L4Awg0D5E PIzxuUrMVQToI6YcNHTs3qMkyGxbhIFAjJyJVHO00epnfk4CqFoU90c4Zrrm4+J9WzRhNsWIWrY viTgMXSBWp/4+6QDwxYXBQ0qwU4JtbAZgu7laEvpC243Z+SAUYiKLRwqfnvcwcMUWWk8sDjqKk9 Zj3L2Fj1zLKhE7LPtDb8MIFRKRidnTEpF6a/kPnZSLyWqmZfn809Jx0fskf2+BWRDu8/guwGovq RaOmVd+t97FhmM5R7vWgxKNEQgl2VLmGuaLj+y9Jg5W6VTnV/zxlwPpdTV083jgGwvxGc+t0XjX J0xsKEfJto2nX2DrmGqJY0LG3Qx1UfpTTZebLCp2EpNDjcdOA== X-Received: by 2002:a05:600c:818c:b0:499:b65e:49c9 with SMTP id 5b1f17b1804b1-4a180419643mr26080295e9.10.1791373226729; Wed, 07 Oct 2026 04:40:26 -0700 (PDT) Message-ID: Date: Wed, 7 Oct 2026 13:40:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs From: Oleksii Kurochko To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> <4a0b0d62-c312-43c1-908a-fcff7c081149@gmail.com> <4fa78acf-4de9-48bc-aea8-fed774d80cfa@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/1791373227-FD80D77B-B8306C4D/10/73395122804 X-purgate-type: spam X-purgate-size: 8716 On 10/7/26 1:32 PM, Oleksii Kurochko wrote: > > > On 10/7/26 12:44 PM, Jan Beulich wrote: >> On 07.10.2026 12:03, Oleksii Kurochko wrote: >>> On 10/6/26 5:20 PM, Jan Beulich wrote: >>>> On 05.10.2026 18:00, Baptiste Le Duc wrote: >>>>> A RISC-V implementation can manage the PTE A/D bits in one of two >>>>> ways: >>>>>       1) Update the 'A' and 'D' PTE bits in hardware (ratified as >>>>> Svadu). >>>>>       2) Generate a page fault when 'A' and/or 'D' is clear, so >>>>> that software >>>>>          can set them (ratified as Svade). >>>>> >>>>> p2m_set_pte_flags() presets A/D in G-stage PTEs only when the >>>>> device tree >>>>> advertises Svade. >>> >>> According to the code it seems like it is setting A/D bits always >>> independently on what is DT file.  Baptiste, am I missing something? >>> >>>    Platforms that use scheme (2) without advertising Svade, >>>>> such as the HiFive Premier P550, then hit guest-page faults that >>>>> Xen does >>>>> not handle. >>>> >>>> Is that a quirk then (to avoid the word "bug")? Since it's all DT that >>>> conveys available ISA information, why can't the DT for those systems >>>> simply be fixed? Depending on the answer here I might question the >>>> presence of the Fixes: tag below. >>> >>> I think it can at some point. Let me clarify why "at some point"... >>> >>> So how the things are working now: >>> >>> OpenSBI detects the available ISA extensions in two steps: >>> 1. It parses the CPU nodes in the DTB. If a node has the >>> riscv,isa-extensions property, OpenSBI uses it; otherwise it falls back >>> to riscv,isa. riscv,isa-extensions describes the same extensions as >>> riscv,isa, but as a list of strings, which makes it easier to parse. >>>   From this, OpenSBI builds a per-hart bitmap of available extensions >>> (basically what we do in Xen). (Platform-specific code can also add >>> extensions to the bitmap at this step.) >>> 2. It then probes a small, fixed set of extensions (Sstc, Smaia, >>> Sscofpmf, Smstateen, Ssstateen, Smcntrpmf, Sdtrig) by reading a CSR that >>> the extension introduces and checking whether the access traps. This is >>> similar to what we do for Sstc in Xen. >>> >>> Step 2 only adds extensions to the bitmap. It does not check or clear >>> the extensions that came from the DT; the only exception is Zicntr, >>> which is detected purely by probing. So for extensions such as >>> Svade/Svadu, which have no CSR to probe, the DT is the only source of >>> truth. >>> Now, what OpenSBI does with Svade/Svadu specifically. First, it disables >>> hardware A/D updating by default, i.e. it clears menvcfg.ADUE: >>> >>> Now, what OpenSBI does with Svade/Svadu specifically. First, it disables >>> hardware A/D updating by default, i.e. it clears menvcfg.ADUE: >>> >>>     /* Disable HW A/D updating by default */ >>>     menvcfg_val &= ~ENVCFG_ADUE; >>> >>> Then it sets ADUE again, depending on which extensions are listed in the >>> DTB: >>> >>>     /* >>>      * Assume only Svadu is supported when it is the only extension >>>      * present in the ISA string. Svade is assumed when neither are >>>      * present. When both are present we must default to Svade (see >>>      * the zero reset value of FWFT.PTE_AD_HW_UPDATING). >>>      */ >>>     if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE)) >>>     __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE); >>> >>> So all OpenSBI does is set or clear menvcfg.ADUE based on what is >>> mentined in DTB. >>> >>> So, to answer your original question: yes, this can be fixed just by >>> updating the DTS. OpenSBI will then configure menvcfg.ADUE according to >>> the extensions listed there. Note that the logic above is from OpenSBI >>> v1.9. Versions v1.5–v1.8 behave the same when the DT lists only svadu, >>> only svade, or both. When neither is listed, they leave ADUE unchanged >>> instead of clearing it. Versions before v1.5 don't handle Svade/Svadu at >>> all. >>> >>> But IIRC such approach was suggested in one of vX and it was rejected >>> because we can't in Xen be sure that passed DTB is correct and >>> corresponds to how real h/w is configured as specifically with ADUE bit >>> in menvcfg we can't read it in HS-mode as an exception will occur as it >>> is M-mode register. So we have to trust that OpenSBI (or other firmware >>> will configure the A/D update scheme according to what is mentioned >>> in DTS). >>> >>> So then basically the question is do we want to rely on that how OpenSBI >>> configures h/w? >>> >>> It seems like it could be fine. For example, without support for the >>> FWFT extension, we can't access or change the menvcfg bit anyway. The >>> FWFT extension was ratified in 2025, so we have to trust OpenSBI anyway >>> (or introduce our own extension or port the FWFT extension to an earlier >>> OpenSBI version) before FWFT is started to be available. >>> >>> With this explanation would you (Jan) be okay to go with just providing >>> proper DTS? >> >> I can't answer this, as I lack details on where the DTS is coming from. >> So far I thought this was a blob handed to Xen (as kind of a module) at >> boot. What you say above makes me uncertain about that. If it is a blob >> as I thought, how difficult is it for people to edit a broken blob, for >> it to correctly reflect their hardware's capabilities? > > It depends... > > So usually the things are going in this way products like U-boot, Linux > has dts in its code source base and then these DTSes are compiled by > build system to DTB, and then this DTB is put to the place where U-boot, > Linux can reach it, or U-boot provides through a register DTB to Linux. > Sometimes it also could be a case when what is U-boot/Linux source code > base is taken as a base and then a new dts is provided  based on them, > for example, to choose what h/w should be enabled/disabled or probably > for some specific board some device is connected to a different pin and > so DTS will be needed to be updated, and so on... > > From one side, it could be super easy as DTB (blob) could be taken by > anyone then just decompile (it using a default dtc compiler) to DTS, > update the necessary properties and then updated DTS (using dtc compiler > again) compile back to DTB. > > But on the other side it could be some kind of secure boot where all the > binaries are signed and then it will be pretty hard to decompile and > compile DTB with the same sign.... > >> >> If that's not "very simple", or if there's concern that people may >> object to doing such editing, then I think we could (should) go without >> that. All I then would ask is that the description be clarified a >> little further (clarifying that absence of both extensions is a valid, >> albeit historical situation). >> > > Also I am looking at henvcfg register which we could access in HS-mode > and it also has ADUE bit and the description for it is the following: > ``` > If the Svadu extension is implemented, the ADUE bit controls whether > hardware updating of PTE A/D bits is enabled for VS-stage address > translation. When ADUE=1, hardware updating of PTE A/D bits is enabled > during VS-stage address translation, and the implementation behaves as > though the Svade extension were not implemented for VS-mode address > translation. When ADUE=0, the implementation behaves as though Svade > were implemented for VS-stage address translation. If Svadu is not > implemented, ADUE is read-only zero > ``` > > So, at some point, we could verify how OpenSBI configured the hardware > and compare it with what is specified in the DTS file. > > The only problem is how to interpret this part: “If Svadu is not > implemented, ADUE is read-only zero.” The spec does not explicitly state > that Svade will be used in this case, but logically, it seems that if > Svadu is not implemented, the implementation has no other choice but to > provide Svade and so basically we could detect if Svade is used based > only on ADUE bit. > > If we accept this assumption, we could fully verify, in HS-mode, both > what is specified in the DTS and how OpenSBI configured the hardware. > This would allow us to require users to provide a proper DTS with the A/ > D bits update scheme correctly specified. Probably we could do such assumption as I found the following in the spec: The Svade extension requires page-fault exceptions be raised when PTE A/D bits need be set, hence Svade is implemented when ADUE=0. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 07 11:59:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 11:59:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442259.1659836 (Exim 4.92) (envelope-from ) id 1xEQIl-0001k8-2D; Wed, 07 Oct 2026 11:59:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442259.1659836; Wed, 07 Oct 2026 11:59: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 1xEQIk-0001k1-V2; Wed, 07 Oct 2026 11:59:14 +0000 Received: by outflank-mailman (input) for mailman id 1442259; Wed, 07 Oct 2026 11:59:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEQIi-0001jt-RW for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 11:59:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEQIh-00CQ4C-QS for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:59:11 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6340e-2eae-0a2a0a5409dd-0a2a4507ed40-8 for ; Wed, 07 Oct 2026 13:59:11 +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 6ac6340f-b4ea-0a2a45070019-b9ff1c22af61-3 for ; Wed, 07 Oct 2026 13:59: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 1a1163b4a7d0003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 11:59:06 +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 02EA782388; Wed, 7 Oct 2026 13:59:05 +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=tVc3zRgmDIOuP2JV7CZKp5R4gCp9SFNVyZHsnrd3Wm0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=P9SNCCFHUf4O5jdzEceiSPbVNG+Q2SCLt6+RkhI5zexCt7g/pTX27/oC//FT8bFjlhLRDnKxs PsSJfigDTw3NrtVtcy3Zsc4eoKfLCnKiaUceNwQ/0Q9TrL4KSoLcLu5rN51FthirjXiB+ryj7Br sLbqAPKwS86IuewUUDij9z96wpzINKYX+geuZnUvz4ZsuNeL3G58bNTHodp6xYZ0ti4NcqACnHz FYOuiGNzuJd3V53YjqP5H0PxtuwRsAyoXWTTY5E9XE6nhy98U828itdjXIUCDMhgA/T3mR0Ynoi K+qKRviseT1qtJI2wXBiBb5kuSJmc0q2pY8YJ2KtUr5A== X-Zone-Loop: d688e437cafd28e1079eb9061beb36ad0b68a70c8241 x-campaign-type: default x-transaction-id: 6777d653-77e1-4c36-b90d-f657b87c2ffd x-swg-uid: 01-fb820b22-1ddf-4d79-80bb-e7d86c0231b4 X-Mailer: Sweego Message-ID: <1791374346.8631fc262581453bbf619ec5b2062170.1a1163b4a7d0003f66@vates.tech> x-swg-bid: 1791374346.8631fc262581453bbf619ec5b2062170.1a1163b4a7d0003f66 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 7 Oct 2026 13:59:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Oleksii Kurochko , Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> <4a0b0d62-c312-43c1-908a-fcff7c081149@gmail.com> <4fa78acf-4de9-48bc-aea8-fed774d80cfa@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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------yK1TrqNChZZZM4x4ILmMMtCG" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791374346259 X-purgate-ID: tlsNG-ef75cf/1791374351-364DBAE4-575C653C/0/0 X-purgate-type: clean X-purgate-size: 8178 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------yK1TrqNChZZZM4x4ILmMMtCG Content-Type: multipart/mixed; boundary="------------l1VK03TfshMeovI68YfiQXRP"; protected-headers="v1"; hp="clear" Message-ID: <9f170b09-7868-4352-adc2-df22f439e819@vates.tech> Date: Wed, 7 Oct 2026 13:59:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Oleksii Kurochko , Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> <4a0b0d62-c312-43c1-908a-fcff7c081149@gmail.com> <4fa78acf-4de9-48bc-aea8-fed774d80cfa@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: --------------l1VK03TfshMeovI68YfiQXRP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDcvMTAvMjAyNiDDoCAxMzozNSwgT2xla3NpaSBLdXJvY2hrbyBhIMOpY3JpdMKgOg0K PiBBbHNvIEkgYW0gbG9va2luZyBhdCBoZW52Y2ZnIHJlZ2lzdGVyIHdoaWNoIHdlIGNvdWxk IGFjY2VzcyBpbiBIUy1tb2RlIA0KPiBhbmQgaXQgYWxzbyBoYXMgQURVRSBiaXQgYW5kIHRo ZSBkZXNjcmlwdGlvbiBmb3IgaXQgaXMgdGhlIGZvbGxvd2luZzoNCj4gYGBgDQo+IElmIHRo ZSBTdmFkdSBleHRlbnNpb24gaXMgaW1wbGVtZW50ZWQsIHRoZSBBRFVFIGJpdCBjb250cm9s cyB3aGV0aGVyIA0KPiBoYXJkd2FyZSB1cGRhdGluZyBvZiBQVEUgQS9EIGJpdHMgaXMgZW5h YmxlZCBmb3IgVlMtc3RhZ2UgYWRkcmVzcyANCj4gdHJhbnNsYXRpb24uIFdoZW4gQURVRT0x LCBoYXJkd2FyZSB1cGRhdGluZyBvZiBQVEUgQS9EIGJpdHMgaXMgZW5hYmxlZCANCj4gZHVy aW5nIFZTLXN0YWdlIGFkZHJlc3MgdHJhbnNsYXRpb24sIGFuZCB0aGUgaW1wbGVtZW50YXRp b24gYmVoYXZlcyBhcyANCj4gdGhvdWdoIHRoZSBTdmFkZSBleHRlbnNpb24gd2VyZSBub3Qg aW1wbGVtZW50ZWQgZm9yIFZTLW1vZGUgYWRkcmVzcyANCj4gdHJhbnNsYXRpb24uIFdoZW4g QURVRT0wLCB0aGUgaW1wbGVtZW50YXRpb24gYmVoYXZlcyBhcyB0aG91Z2ggU3ZhZGUgDQo+ IHdlcmUgaW1wbGVtZW50ZWQgZm9yIFZTLXN0YWdlIGFkZHJlc3MgdHJhbnNsYXRpb24uIElm IFN2YWR1IGlzIG5vdCANCj4gaW1wbGVtZW50ZWQsIEFEVUUgaXMgcmVhZC1vbmx5IHplcm8N Cj4gYGBgDQo+IA0KPiBTbywgYXQgc29tZSBwb2ludCwgd2UgY291bGQgdmVyaWZ5IGhvdyBP cGVuU0JJIGNvbmZpZ3VyZWQgdGhlIGhhcmR3YXJlIA0KPiBhbmQgY29tcGFyZSBpdCB3aXRo IHdoYXQgaXMgc3BlY2lmaWVkIGluIHRoZSBEVFMgZmlsZS4NCj4gDQo+IFRoZSBvbmx5IHBy b2JsZW0gaXMgaG93IHRvIGludGVycHJldCB0aGlzIHBhcnQ6IOKAnElmIFN2YWR1IGlzIG5v dCANCj4gaW1wbGVtZW50ZWQsIEFEVUUgaXMgcmVhZC1vbmx5IHplcm8u4oCdIFRoZSBzcGVj IGRvZXMgbm90IGV4cGxpY2l0bHkgc3RhdGUgDQo+IHRoYXQgU3ZhZGUgd2lsbCBiZSB1c2Vk IGluIHRoaXMgY2FzZSwgYnV0IGxvZ2ljYWxseSwgaXQgc2VlbXMgdGhhdCBpZiANCj4gU3Zh ZHUgaXMgbm90IGltcGxlbWVudGVkLCB0aGUgaW1wbGVtZW50YXRpb24gaGFzIG5vIG90aGVy IGNob2ljZSBidXQgdG8gDQo+IHByb3ZpZGUgU3ZhZGUgYW5kIHNvIGJhc2ljYWxseSB3ZSBj b3VsZCBkZXRlY3QgaWYgU3ZhZGUgaXMgdXNlZCBiYXNlZCANCj4gb25seSBvbiBBRFVFIGJp dC4NCj4gDQoNClRvIG15IHVuZGVyc3RhbmRpbmcsIHdoZW4gIVN2YWRlICYmICFTdmFkdSBB RFVFIGJpdCBkb2Vzbid0IGV4aXN0IGFuZCBpcyANCk1CWi4gVGhhdCBkb2Vzbid0IGltcGx5 IFN2YWRlIHNlbWFudGljcyBtdXN0IGJlIHVuY29uZGl0aW9uYWxseSBhcHBsaWVkLCANCmJ1 dCB0aGUgY29udHJhcnkgKG90aGVyd2lzZSwgaXQgd291bGQgY29udHJhZGljdCB0aGUgbWFp biBzcGVjKS4NCg0KQUlVSSwgU3ZhZHUgJiYgIVN2YWRlIGJlaGF2ZXMgdGhlIHNhbWUgYXMg U3ZhZHUgJiYgU3ZhZGUsIGFzIGluIHRoaXMgDQpjYXNlLCBBRFVFIG1hbmRhdGUgdGhlIFBU RSBBL0Qgc2NoZW1lIHRoYXQgaXMgZWZmZWN0aXZlLg0KSWYgYnkgZGVmYXVsdCBBRFVFIGlz IDAsIHRoZW4gd2UgaGF2ZSBTdmFkZSBzZW1hbnRpY3MgYnkgZGVmYXVsdCBpbiANCnByYWN0 aWNlLCBidXQgdGhhdCBjYW4gKCptYXliZSopIGJlIG9wdGVkLW91dC4NCg0KSXQgY291bGQg YmUgaW50ZXJlc3RpbmcgdG8gY2hlY2sgaWYgdGhlIFA1NTAgaGFzIFN2YWR1ICYmICFTdmFk ZSwgYXMgaXQgDQptYXkgZXhwbGFpbiB3aHkgU3ZhZGUgc2VtYW50aWNzIGFyZSBlZmZlY3Rp dmUgd2hpbGUgbm90IGhhdmluZyBTdmFkZSANCmV4dGVuc2lvbi4NCg0KPiBJZiB3ZSBhY2Nl cHQgdGhpcyBhc3N1bXB0aW9uLCB3ZSBjb3VsZCBmdWxseSB2ZXJpZnksIGluIEhTLW1vZGUs IGJvdGggDQo+IHdoYXQgaXMgc3BlY2lmaWVkIGluIHRoZSBEVFMgYW5kIGhvdyBPcGVuU0JJ IGNvbmZpZ3VyZWQgdGhlIGhhcmR3YXJlLiANCj4gVGhpcyB3b3VsZCBhbGxvdyB1cyB0byBy ZXF1aXJlIHVzZXJzIHRvIHByb3ZpZGUgYSBwcm9wZXIgRFRTIHdpdGggdGhlIEEvIA0KPiBE IGJpdHMgdXBkYXRlIHNjaGVtZSBjb3JyZWN0bHkgc3BlY2lmaWVkLg0KPiANCj4gfiBPbGVr c2lpDQoNClRlZGR5DQo= --------------l1VK03TfshMeovI68YfiQXRP-- --------------yK1TrqNChZZZM4x4ILmMMtCG 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+p0QLLz9AFAmrGNAkFAwAAAAAACgkQZg+p0QLLz9DJ 8gv/TsFbkq7CdD6MPOX7I3ftXbFEtXZcrt85lIeszXmN/lhNDoQQT17nL6S7ZjUwuVjm8kmbEQj5 ssIg5wJ3KJVY3+SQSXimYZN2re1oOJOGHA2T6PGYIqdNIJMF3QI9f1ZZbbpzWmuRasdyIsNL5sLa xq/TUEu7LA4ayeq2SH1vrUfzcVrq/uvuZ1OqVpNAyKYQWGYOPAkrciPJeOeJcsUs7B5d8qW3mTJv Q80hplNjLuaOjYEz+fGFqW6Yt0yj8q/J4bAJTCe478d67IUo1MURCIM+5+x6fgSzt+bbbVxUEuoc Z3tq6FY5HXKrTPT/LpRLdHEwgV9a6UokFqVMGiKYMkjUcncdl8V0Xu0Anoxrjcp4Xj5JRy8cPW5n fdA89McsX8LiQEUYx5C2B1endLTghhzwDSmPHW6u8pdHZypMO2F5U0vo1027RKS0+HSpv/rv860o JuEt/HDkCmNKH9qTkN55dTC37TeRWFx2UTzLRgk3zUKPBTjidNyjC76p2Les =VrXC -----END PGP SIGNATURE----- --------------yK1TrqNChZZZM4x4ILmMMtCG-- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 12:00:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 12:00:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442266.1659844 (Exim 4.92) (envelope-from ) id 1xEQKE-0003KQ-Eq; Wed, 07 Oct 2026 12:00:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442266.1659844; Wed, 07 Oct 2026 12: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 1xEQKE-0003KJ-C1; Wed, 07 Oct 2026 12:00:46 +0000 Received: by outflank-mailman (input) for mailman id 1442266; Wed, 07 Oct 2026 12:00:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEQKD-0003K7-ND for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:00:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEQKC-00CQri-Tp for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:00:45 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac63468-8faa-0a2a0a5109dd-0a2a450b9f62-4 for ; Wed, 07 Oct 2026 14:00:44 +0200 Received: from [52.101.52.0] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac6346a-b7e8-0a2a450b0019-34653400b619-3 for ; Wed, 07 Oct 2026 14:00:43 +0200 Received: from BN9PR03CA0066.namprd03.prod.outlook.com (2603:10b6:408:fc::11) by SJ2PR12MB8651.namprd12.prod.outlook.com (2603:10b6:a03:541::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Wed, 7 Oct 2026 12:00:32 +0000 Received: from BN1PEPF0000468B.namprd05.prod.outlook.com (2603:10b6:408:fc:cafe::78) by BN9PR03CA0066.outlook.office365.com (2603:10b6:408:fc::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 7 Oct 2026 12:00:31 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN1PEPF0000468B.mail.protection.outlook.com (10.167.243.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 12:00:31 +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, 7 Oct 2026 07:00:30 -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, 7 Oct 2026 07:00:30 -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; Wed, 7 Oct 2026 07:00:29 -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=J1iqlmldR8VJ/EqSJD7OzL8gHOojJ1Fwp+KhAJCuZaF9gWuc/zarr8FyayvEcMhTSEgX5/vJFvtKB0jFM/x71Sd3HX6AhscZ0uWkqDoDmDpzpWKaUjELY13dK8X/v8ZZYB8gByLnI7CKoV+tiqAZ+KrtZeR8t0Mv12w589Er5fw/DY8Teb7L6YC+QBOS3dxUSNE7ZE/PQCgEErQivS+EifVS4i+gsZfKiRz2pApeHKAzwIYC9rQkIuPjP5nj0XrAnCAr5UlnqVhJvw+IdO9/QTcwCRddP11ApgqVK9jYwYW/0GC2mVg8htuAN8fAO6AdmdlC/M8q4NJ/CmvjuJkcvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A/uCyFSvq0Vh8IMLf8yXpqJuRKqkn+sKLnhmNJT74LQ=; b=blTILmzI8TNadK+r/nrU7vWmYx3Vw0CHzQiHFjFa5G/NZoiYgvOfd77pNYTPJ46OAjkBbr3OQD/VxtGWsir/ell7/roJBCPdH7enZbWV5X4xIR1MAW/PAbxcHWqqB9f5acl2uB23SXKEaRzjI6S+fi+nOTOsL5P7rKlrSaYXy11pgjlZlkWpcskAQJceH1l45Gpd7HqUdTgM9XQgrlI+eUtUPI2ga6sQssY7ROYQUzMmLEBhdHSEUq2rjxsqn12ixv9J8VnRoqG+4bjaEUBT1WueacSnJgvxk0nhEkQnBDLwPNevLXQs6UYs5airDyb4/46vFv5P4Kj8jM+ONE9ARQ== 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=A/uCyFSvq0Vh8IMLf8yXpqJuRKqkn+sKLnhmNJT74LQ=; b=tdvHiuUQOe4MxcfBgzTe6Nsds7k0RElGXRI0HH7A3hjU1Jnvb9r5IPOkEAUWK5ZQMr33xbZrqaoWEFWWvAfMvdrYD6+XDfM9CdJuo9yYj8uAxIddFRssYTPxe4PughB88I0cBOU/CH8CWBf4RQ3gEbkGKDuXhAi/IbClcs5JDPs= 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: <311e02a0-8935-464c-bfa1-ec4e6aa23462@amd.com> Date: Wed, 7 Oct 2026 14:00:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm/nospec: Make nospec helpers always_inline To: Alejandro Vallejo , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <20261006103142.139422-1-alejandro.garciavallejo@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: BN1PEPF0000468B:EE_|SJ2PR12MB8651:EE_ X-MS-Office365-Filtering-Correlation-Id: 6994c4eb-400f-425a-3921-08df246a9629 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|82310400026|376014|1800799024|36860700016|18002099003|22082099003|10067099003|11063799006|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: 6OSX1oWHutKT43wN1WwmJijeFYFiNPkSd84u7knanCu7xImWWr0/WlYCPUmZZjmg6pevcoGlNhMvzKVxzCi+VvS0HdnDLhwcwHKnaIoq6jcK85xo5ZFxt6B2bDSsMWqULAhSBG2XPiAgN2hoCIfgAolCK6gJL8Cma43L4IhmGIlrbd+IUkGrCs3zxbvNLTmb44f21DVmrui+ZBYNyH065ArCjrV0nUf2NILpTNAaN+ydmLLVD/ElNaWsrblNQAtjwOZg40P+OX+cP7XgnSrZrrZ6DB2iQ6PmWTYRZ3yjfIfO9anr81g6Jq4JuHy67/ljVo8sXdSxFOKp8Yj17uQkJgt14MsZpFnGy2PYo3b6EDw9mgnLiDozYWGhXy2knVBFZ7AVqNhLmvUsS2PHIcsvkWdfyq6Yn819VKy2WhryIqIxvK0LCe/XAVw/qs/37ujX4gytYpniv/i+OKhudps5afVjcGXaprcz/MSofqvadKfd73c3SA934ZQ9GYOrMEjI/j8Y/cajEM1GnCQBOvHkHX9DYZnzizYtffqrFXpbX4L2Yp2Nd4j/xs2aUHsEY2Xy4df7407dwVKUG0oxwbpPeDJELP+V/yX6nKHtiyjwmELp5TT/doo/Z72pGh06FmUB3fTsIhwnZQ4UrT9M2nQduxsvSPPI4fZCwYdOa9qioioFt1XD7H71G2jEAWAafUvlkSV9BnSv/LB3pd8aU5cL+w== 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)(82310400026)(376014)(1800799024)(36860700016)(18002099003)(22082099003)(10067099003)(11063799006)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: kbQfIc1zeQrm+/9L+94+dicfDlVVKZEn9s8zfgSU+ha7NOXq5csXv2lHHqR94mNEfkv9oSw8EOHdP1XlbfOFlR5dfiGC1TMqo/3yeKFtG+P3T7p/lSA0VlJdITJBo/jkFe5BgmGZPT9TZucWinOSZvtson4CLnEuzh926JUj0Lp1rhOdqsvWBKLZzUksXs28YwYRnO7EJ9u4hK+9lleCpNL0zPrcM7vf76DWohE+OZiW9+avGSNhmM9MAQP9twoN1wP/Wt7s77x6vXTxmmjDY5Hf38lOZkN+2eFGq040I0hQRJT8NX/sixdVswwOTlTol4BQ6C5oynUgjoNO0ZrqUCEiwNc6aP3/y1Lfza0Eo2fXXjj7y+aZN+kKdaTIczZoBcnbLnoITHpK2nPNSl1/HOUsPAyZ9+0J9e1PzYY0ATxgem2zY07GPolXwpEkJI2+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 12:00:31.3919 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6994c4eb-400f-425a-3921-08df246a9629 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: BN1PEPF0000468B.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8651 X-purgate-ID: tlsNG-42698a/1791374444-A8ECE9EA-95DDC85B/0/0 X-purgate-type: clean X-purgate-size: 947 On 06-Oct-26 14:29, Alejandro Vallejo wrote: > On Tue Oct 6, 2026 at 12:45 PM CEST, Orzel, Michal wrote: >> >> >> On 06-Oct-26 12:31, Alejandro Vallejo wrote: >>> While today they don't implement fencing in a way that would block >>> speculation, once/if they do they'll absolutely need to be inlined, even >>> if -fno-inline or -fno-early-inlining are passed. >>> >>> Signed-off-by: Alejandro Vallejo >> Reviewed-by: Michal Orzel >> >> but this should be done for Arm, RISCV and PPC at once in which case you can >> keep my tag for v2 # for Arm. > > Neither RISCV nor PPC implement nospec.h today. Should I considered the > R-by just settled for this patch? I'm not sure I understand. You wrote that they don't implement the header whereas I can see: arch/riscv/include/asm/nospec.h arch/ppc/include/asm/nospec.h hence my remark to fix all at once. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 07 12:35:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 12:35:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442286.1659854 (Exim 4.92) (envelope-from ) id 1xEQry-000097-V7; Wed, 07 Oct 2026 12:35:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442286.1659854; Wed, 07 Oct 2026 12:35: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 1xEQry-000090-RV; Wed, 07 Oct 2026 12:35:38 +0000 Received: by outflank-mailman (input) for mailman id 1442286; Wed, 07 Oct 2026 12:35:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEQrx-00008u-NZ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:35:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEQrw-002HVv-Vs for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:35:36 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac63c8d-2eae-0a2a0a5409dd-0a2a450ca420-42 for ; Wed, 07 Oct 2026 14:35:36 +0200 Received: from [40.107.208.44] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac63c97-f479-0a2a450c0019-286bd02c7d87-3 for ; Wed, 07 Oct 2026 14:35:36 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ2PR03MB7499.namprd03.prod.outlook.com (2603:10b6:a03:556::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 12:33:26 +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.0496.015; Wed, 7 Oct 2026 12:33: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=i+AnVgEJG4KRPdsCkYAhgzvA/lcI8ecaxTOiHYiRQo7K5ULlGKX+m2vqzNQtKG6x8REPSAffTYHv85bVTxrOA6jRASB60a9qRinCs1KmtKqLlKMayzMGWTW4InfgG3UjopGUjTx3XurDZ0JAAtG8QdgJwE2UFpHfotti6FlxTBbs659f3KUSd2Sa0FSlyC+oRG9JrZ4NuDm9sdDbEZasdPtWr6WEQj+1sZUzdiXTySijJbBCtLKSlaljTJ9DE5Feug4V9fBWEmnhBt31X57Lchmm8Vg4qRCtvi5b27/p/5m1KsIjqnOKAVcDjhbiwfKxowYOwxTFqqH97ORC5j4BvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2qgHDDAYykJYNq8u3LGBiFBWecoR5UPdHfjjJSkKE1w=; b=fzONIwHeYNuPJppmGyMH1lF+62QAnQYYEvkXgPeB9FgSkvihgzzOQYJSFUfgmTY0Gh8O/deU0Zq/Pz7lwZd9wAjW34F1KDcqCE1DQ2QHRSGoSFmskjD+E9NYYbIakiGEAx8ZpiBgwKxKBnEfMM6fFf1G+T+NesDPwuuiRShX2iDIsjEVY46xEopKEdMD++3OPB4zc7mN9AoRKGauM/iXVlmVnib+cSAdnZxMonh4gkuDPaQ+5skRTfODenKV3rVMVUN9ssYg1YRB1OjRQXxF4SJpsksl1TMSICSPRpv8UHuohcwuUKp1E1XUF3z/6XsWyn0GGMtvy0qxbWrWIzlH4Q== 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=2qgHDDAYykJYNq8u3LGBiFBWecoR5UPdHfjjJSkKE1w=; b=VxoJE+kGPVAPmMcG5CtG/6l1SWa8q0jyNNnHNeGRU1F9WPeCp5SqFfBbe9b3GLS4WeysVROptjLJpOvs6QSFIKtEDyFwXnRk2HzAkkDF//PdYdZgrxIqOmVMTSh2humVkukCrsHbWRs40EMWsrAT3Oh/wK0R8jnk/0x46j6j4DY= 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, 7 Oct 2026 13:33:22 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH v3 01/18] x86/PoD: map one page at a time in p2m_pod_zero_check() To: George Dunlap , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-2-gwd@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: <20261007104051.48841-2-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0246.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a7::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_|SJ2PR03MB7499:EE_ X-MS-Office365-Filtering-Correlation-Id: 4be7ee36-0c88-4125-7750-08df246f2f04 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|10067099003|11063799006|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: nYmUCeoWGx/yFoyu7C4gdh0xvgQxsBvX+j8of0WbLG1n/RqPl79PdSg5pkpBwzugzWDKXW2ynW4G/USGSfwcx/wrbD3y7HRr2482YvpmkQrxqFCQEPHjqS9tJYJtMk4jRwUVN2cDH2i6Fg5HExz8gomXr1IT7eHclkJpNQySlvJZNdDRYZwG4WG9VNr4MfVGhlsSowuOKsjzlv1HVSvJI4fHEKtJNQ+0+lf3PGjVBYFZZHv/TI6ByyfZ2oqI0Lt0qdE9wgiB7/5lP/PkdXLxq6pw06xklIxxWHGMX4gFHU+ETe/8oXvvr9sXlAZEVe7DA/SX5T3+oIxxUDREQ5wmIKODtU0Kn0c+YY/zK8pN5DKk+VQHwgBpOLOOuSp9B7t3TSYn/+To6Vnakkc2HFvpKFhqcq9ZF4Cne8h42mYso3ASaO2GBUwvQ543o/ZhSMFdwgevxPRylENj8ZXZzRzU98d4D4hwHJum7RLb44JH4nmf6FKFhtVe0fJn9XkzlTN8tHCbmN/LvuuE87MNKYLUX/CkOdCW6Q/paLML14z5K7mmMKKWjrOQM1xo62gyfIhavgd5BtYNa81hvHJemMPUa0duMgFL6Ltvq3vMcU3e2DCkcsDDnIaUwOgk+yTOKCsb7W3wC4eiNToLr3IEL3dLybsf6Q3c4oiVR6CJWgv8B+c= 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)(18002099003)(22082099003)(10067099003)(11063799006)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bTJuMEFGL1FoNjlubFJ3aTBlU3RzN2I1U0JqNE92bDNSTmFISFVKekwwMC9G?= =?utf-8?B?RStKSGZ1eHgySEdGbFZMcytORCt4b1VqR0VSZGcyMzQ4ZnQ1Uk1NRG14R3M1?= =?utf-8?B?dCtzNkFoWDRvbWxPNFFQd2haUGxnRGsyei9KS2tGL3FoV3o4d21SYm9sYWx1?= =?utf-8?B?dFVIRjdEemlVVFVvTnFEY3dGZUtRcWdpa1daUTZNRzUxSmtzVDJDY2ppOEZh?= =?utf-8?B?OFNyRWh4ZE5Cbi84RmxMTGE1MVlIdU95UzJSYk1xd3BtZ25sK3RLYVB5SmFY?= =?utf-8?B?S1R1WDJPeEJ1SE16WmxxUUlWRmF3ZTVuNEVsckliQTQ4M01DcGJyQkZRS0Rq?= =?utf-8?B?ZTZ4dG4weEhQQndxTGE4bXV5VzJwYjNtUTZkVGJydURNSkoxS0Q2enJwTnN4?= =?utf-8?B?ZDZlM0ZDQjdmc1QvUW4rb09WdkN1SHJrTUJqZXM3aFhqLy9tUndpQmQ0YUU3?= =?utf-8?B?alVzK1ZGVXJLMWNmcGx3K25NZjkwalBWaFpBRjhuYi9OdnBXcGVkZzNsRmJs?= =?utf-8?B?b2NXRmEzblZ1d2JOWlRoUml1RGkvbitWNUhwK2ErL3FuRDhRbW9XSStyUnkz?= =?utf-8?B?enl1aDFvL2NRa09YczNVYnRXTElnNTNHUmpTWGI4L0hlQ1ZTb1dmRWRsVVhI?= =?utf-8?B?bGpwalhpYkNqd1lLdzVuQU9yRnBBR2hlLzJXZFkyN2R2Nm81U3ZmS2pxUjVF?= =?utf-8?B?OW1rUkJocm9YK2x4Sm53QzloeXRhZjE1dURrdDRnS2JKNE1sUVBjZVNPelI2?= =?utf-8?B?WGlmVkRiQjgyUUNhM0NWZmZzYjFKdVF5QzJldzRreHlsUGd0c1dqRUxXdWYw?= =?utf-8?B?czh5SHZJdWpwYlVxQjFlWFFBNEp3aU1lKy9ud0txTEl2akVzTEdLalNkdU4w?= =?utf-8?B?Y0hmbUZrQVBPNURHaVJXY3F1bWdaalBtMzRiZEhaMWVRT3ZEdjRXdUI4Rkts?= =?utf-8?B?aE43VEdXZENqWWgvcVNrUFVoSXB6Z0MzQWJZTjl5ZWt0aWg4MjBselVpRHhp?= =?utf-8?B?dDFZZUlBYzRhTjVqRGdTTmFTSzlMdXVtUWxyVlVxR3JUUEJqWklJeUd3eTcz?= =?utf-8?B?em1DcWlEYk15SElRa3d6dUxiOWxnTENQdkZ5bjhKeWtueG1VamY3MllkOWpH?= =?utf-8?B?ZXVveHByWG5WcXNyR2tFVmxRZS9vZDVTckFIeUFlcFlEWUR4Qm1KVzNEU0Rw?= =?utf-8?B?WkdQQnVsYk5FMW5DNVEzZStiSkNHdk1HM0NML1RTVDdhRURCeG5tcnNmcWlq?= =?utf-8?B?ZTVrZ29GblhnVHZaRmUvY3RiOUxiTVp6VVVneEtrUHlwUE9Oam52NEVYbUor?= =?utf-8?B?T2oxNkcrSG0yUnJEaUhFZnFlR1ZRSXExY0hFak9jSmV1NHIybmppOXUxUitS?= =?utf-8?B?Y3FpZXBySmVRdkdyOXQxK1hIQ2lkOUc0M2tJY0FVL2xMWUg0WkIvWHBIT3l6?= =?utf-8?B?VThFQ0NTYkNtQkNWRUhIMlhST2pOY3hYWFdpcTR2MTdiMndOUitmd0l2TFkv?= =?utf-8?B?V0diZGtMSGlvMkQxZUEyUnFrK1E4T3dwNFd5eUJORHM0aG1PL0pnOXpvTGFi?= =?utf-8?B?S0lCaExoeGxWdElFTmhDSjJhaFl3ZnRadFhPT3BlR00vdlZFdkpDekRvVTRE?= =?utf-8?B?d1JmN1VvYis2QnBHQVFZL0RpajZxcWRHeE5kVDNwc01mWlpvRjhjcXdEY09s?= =?utf-8?B?QVJEZEdLWVhNNTA1dzlyUWhKa0ZzUnhMZTlDQm5DNDNqMFBIV3gwRVRCL2ZW?= =?utf-8?B?eVExVUtqWGxRdldWQzdORm5XZ2xoQlhxWEF1WldTaC9rMysxaUZ1bVRieG9J?= =?utf-8?B?NzdGLzFRQ3J6cE5oU1JiblpoQlA5dGx0UzdveGJ2NkY4MHRyZ1VNdi82dVRr?= =?utf-8?B?cEY5ODVxYjErQkFHQ2lNS01LemJNbEFHMGVpbkpvSU5NY0YwWGF1azYyTG52?= =?utf-8?B?Q3NzYWhPeU1XOGl6NDhyL2IwUElTOXhTT0VDQ3ZydzN3YzZNRzIrR29hbFF0?= =?utf-8?B?UXRFUTR4QXJ2UnZlZTJ4ZndWRThIZWhPOFdJMmVWQjcrRUxiOEVFdG1WU1NC?= =?utf-8?B?TmwvbGpFNVZUL2Y0dVYybEZqL3FUS3dLY3Y1WHduNW12THREaEo3eGJzYk5i?= =?utf-8?B?aGUvY3R5R0J6ZEVUYjhxc1QrQm1kRmcxZXI0bDFQcGF3YVdpTXRYRWU0V0p4?= =?utf-8?B?dmMzTUlveDMyOWQ0UDY2NFJEQm5KcElpS25ZLzFNL25uYXRvK2Rwc1A3WGQv?= =?utf-8?B?ZjdraWNuaG5GeEZ6bkh4eG5nWUhnNEkwL1k1bytvUGRRbUxhUDFITkkxSklz?= =?utf-8?B?MTFlS2xwMWs1cUkwRVMvRnBXMTd2RG5DcUFZb1FnMVJnWXBxcEtXUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4be7ee36-0c88-4125-7750-08df246f2f04 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 12:33:25.9549 (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: M3Jf6jOnAA9/YjRTDdg2bGAWpbSP0i0g1IUSZdZyZjlO+VUckBljB5Rkfi7l2OSOZ8ykc3g6feI6Qpo2H3NAdqgOzMZPtSvoicjKQun9a9E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR03MB7499 X-purgate-ID: tlsNG-d25034/1791376536-01CC3A5B-838C20FE/0/0 X-purgate-type: clean X-purgate-size: 7560 On 07/10/2026 11:40 am, George Dunlap wrote: > p2m_pod_zero_check() maps every page of its batch that passes its > checks, up to POD_SWEEP_STRIDE (16) of them, and keeps them mapped > across the p2m lookups and updates which follow, each of which maps > page-table pages of its own. Its callers hold mappings too: the p2m > lookup which found the entry to populate still has its page-table page > mapped, and a PV mmu_update() the L1 page it is writing. > > map_domain_page() cannot always provide that many at once. It uses the > mapcache on behalf of PV vCPUs only: in debug builds for every page, in > release builds for pages beyond the reach of the directmap in PV guests' > page-tables (5TiB, 3.5TiB with CONFIG_BIGMEM). The mapcache has > MAPCACHE_VCPU_ENTRIES (16) slots per vCPU of the domain, shared by its > vCPUs, and a mapping which finds no slot free or reclaimable hits the > BUG_ON() in map_domain_page(): the host crashes. > > The sweep runs in the context of whichever vCPU populates a PoD entry > while the domain's PoD cache is empty. The guest's own vCPUs, being > HVM, map through the directmap; a PV vCPU gets there when its domain > maps or copies the guest's memory: a device model in dom0 or in a stub > domain, a backend doing grant copies. A PV domain with a single vCPU, > as a device-model stub domain or a dom0 booted with dom0_max_vcpus=1 > is, has 16 slots, and a sweep over 16 candidate pages needs more. > > The sweep has mapped its whole batch at once since 9ad9a1609fbe ("PoD > memory 5/9: emergency scan"), when x86-64 reached all memory through the > directmap. The per-vCPU budget came with the mapcache's return to > x86-64 in 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al"). > > Map one page at a time instead, as p2m_pod_zero_check_superpage() > already does: map a page for the quick check and unmap it again, and > map it anew for the full check after the p2m update and the TLB flush. > The checks and their order are unchanged. Each page is mapped twice, > which costs little next to scanning it, and the error paths no longer > have mappings to undo. > > Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al") > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > NB this issue was raised in review and verified only by code > inspection; it hasn't been demonstrated. > --- > xen/arch/x86/mm/p2m-pod.c | 72 +++++++++++++++++++-------------------- > 1 file changed, 35 insertions(+), 37 deletions(-) > > diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c > index 4602c32cff..0b0beca15a 100644 > --- a/xen/arch/x86/mm/p2m-pod.c > +++ b/xen/arch/x86/mm/p2m-pod.c > @@ -901,7 +901,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > { > mfn_t mfns[POD_SWEEP_STRIDE]; > p2m_type_t types[POD_SWEEP_STRIDE]; > - unsigned long *map[POD_SWEEP_STRIDE]; > + bool check[POD_SWEEP_STRIDE]; > + const unsigned long *map; > struct domain *d = p2m->domain; > unsigned int i, j, max_ref = 1; I agree with getting rid of the map batching, but your LLM has done a poor job doing so. An array of 16 bools is excessive.  You want "unsigned int check = 0;" here, so ... > > @@ -911,7 +912,12 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > if ( paging_mode_shadow(d) ) > max_ref++; > > - /* First, get the gfn list, translate to mfns, and map the pages. */ > + /* > + * First, get the gfn list, translate to mfns, and pick the pages to > + * check. They are mapped one at a time below, as in > + * p2m_pod_zero_check_superpage(): a vCPU can hold only a few transient > + * mappings at once, and the p2m lookups and updates here need some too. > + */ > for ( i = 0; i < count; i++ ) > { > p2m_access_t a; > @@ -921,18 +927,17 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > > /* > * If this is ram, and not a pagetable or a special page, and > - * probably not mapped elsewhere, map it; otherwise, skip. > + * probably not mapped elsewhere, check it; otherwise, skip. > */ > - map[i] = NULL; > + check[i] = false; ... this can be dropped, and ... > if ( p2m_is_ram(types[i]) ) > { > const struct page_info *pg = mfn_to_page(mfns[i]); > > - if ( !is_special_page(pg) && > - (pg->count_info & PGC_allocated) && > - !(pg->count_info & PGC_shadowed_pt) && > - ((pg->count_info & PGC_count_mask) <= max_ref) ) > - map[i] = map_domain_page(mfns[i]); > + check[i] = !is_special_page(pg) && > + (pg->count_info & PGC_allocated) && > + !(pg->count_info & PGC_shadowed_pt) && > + ((pg->count_info & PGC_count_mask) <= max_ref); ... this can be put back to it's older if() form, with `check |= (1U << i);` instead, so ... > } > } > > @@ -942,18 +947,24 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > */ > for ( i = 0; i < count; i++ ) > { > - if ( !map[i] ) > + if ( !check[i] ) > continue; ... this and ... > > /* Quick zero-check */ > + map = map_domain_page(mfns[i]); > for ( j = 0; j < 16; j++ ) > - if ( *(map[i] + j) != 0 ) > - goto skip; > + if ( map[j] != 0 ) > + break; > + unmap_domain_page(map); > > /* Try to remove the page, restoring old mapping if it fails. */ > - if ( p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, > + if ( j < 16 || > + p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, > p2m_populate_on_demand, p2m->default_access) ) > - goto skip; > + { > + check[i] = false; > + continue; > + } > > /* > * See if the page was successfully unmapped. (Allow one refcount > @@ -961,6 +972,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > */ > if ( (mfn_to_page(mfns[i])->count_info & PGC_count_mask) > 1 ) > { > + check[i] = false; > + > /* > * If the previous p2m_set_entry call succeeded, this one shouldn't > * be able to fail. If it does, crashing the domain should be safe. > @@ -970,14 +983,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > { > ASSERT_UNREACHABLE(); > domain_crash(d); > - goto out_unmap; > + return; > } > - > - skip: > - unmap_domain_page(map[i]); > - map[i] = NULL; > - > - continue; > } > } > > @@ -986,22 +993,20 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > /* Now check each page for real */ > for ( i = 0; i < count; i++ ) > { > - if ( !map[i] ) > + if ( !check[i] ) > continue; ... this can turn into for_each_set_bit() loops. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Oct 07 12:38:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 12:38:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442292.1659864 (Exim 4.92) (envelope-from ) id 1xEQub-0000sl-Fv; Wed, 07 Oct 2026 12:38:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442292.1659864; Wed, 07 Oct 2026 12:38: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 1xEQub-0000sc-B6; Wed, 07 Oct 2026 12:38:21 +0000 Received: by outflank-mailman (input) for mailman id 1442292; Wed, 07 Oct 2026 12:38:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEQua-0000rk-23 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:38:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEQuZ-0097lM-F5 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:38:19 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac63d32-bab6-0a2a0a5309dd-0a2a4505d94c-30 for ; Wed, 07 Oct 2026 14:38:19 +0200 Received: from [52.101.85.24] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac63d38-4cb1-0a2a45050019-346555182a2c-4 for ; Wed, 07 Oct 2026 14:38:18 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by IA3PR03MB8023.namprd03.prod.outlook.com (2603:10b6:208:509::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Wed, 7 Oct 2026 12:38: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.0496.015; Wed, 7 Oct 2026 12:38: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=Ht3rcRBzlAKpi55BkdxKiLtt4aZ4RhM8v16QTqbuNVqj8jR+DM7rvZl4wsKVmPrkhVczQ3IYPfZ7aamiCQQCxPunKAvfpo5E+/McNDJ8clmvT7HHFr8Jq1Is3GHXCFXWaWk/exmSEEWxgSR4TIe0IupktOk9ApJtXjs5QgGqOTi7+9Mn2COWfVLoqK7ADbDKVNpCtzcxF6NcR05WOtDsdhMRmCwqf02YTDwnNGnDoWJzAlNy7O/1EC+gARwozypAPiYuLoeIxD56T9j3USxoXooCSiE8pjk0boq/rWY91xVg6uqNl3PV2u4dKk03fWORtfb96xf3Sii2CDAxw56z8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8YY9cqyUfKoDTK1PGZqm8ng1IS/cVdxO+SikKAV7S3g=; b=NUa3xkTSV4HdfZoRW4zUWJ01o89UzsF4jH6CROU1UH8mKW0oQQ+MiTeT2K2z3zuxR5tAXGIErbBcl/DwuZMf4LVSgAlhiv/gnWi4Ti/+BpnSawFs9ovD5J+zofb7K4yZzHSQ+E+ml77H5ejIY56jinHlWUbifGxzRg8/lvxsxtQY7UCRIO5cM0Rqf+1GkmYDC2yIZUtjAIT+OyzKwILShWTP7NkkZRQWxR0axgq6Zeh7cDIreGvK8OXKkbGo0+G+cFZ6eNwnfKJsjBIy8nlCdwkVyzsBhb/q/XOpTgvyMFk4vKKfkMXBWalI+dLhmjzJWBF764Vt9i0Cl/IPHF1GFg== 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=8YY9cqyUfKoDTK1PGZqm8ng1IS/cVdxO+SikKAV7S3g=; b=vOH+brCE4qaXb4vgxwmX/uJ9bNVLZAdq3R19p5yYWXpydt3ssGpFXExzY0JH0XvQv1mD73gX0pEakaaAYQeYP0qm9EBYF9eeuS2VNLEnLAZ/PWLF1jfEoDcsRz0OCA2Q+3dyt0rwciXft4LeHpqmoEW37W6jWmOQSS73xvSa0u0= 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, 7 Oct 2026 13:38:08 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH v3 01/18] x86/PoD: map one page at a time in p2m_pod_zero_check() To: George Dunlap , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-2-gwd@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: <20261007104051.48841-2-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0039.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:317::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_|IA3PR03MB8023:EE_ X-MS-Office365-Filtering-Correlation-Id: 5000a09c-ccbc-4a08-e158-08df246fd9a4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|10067099003|18002099003|4143699003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: bf984I6LyuKanhzTZV7cZuRueaJFUzrtT1PHDMStk3YGY1EasLr/wVsCwSNgitF/Q12HvKiRxo6q7c3T/Rt7oCM/aNNbribxGPaIHg5oynWtoDMyrmSGUtgPS4RYdGCTsrEva8UVYjw7cZCfxmU6ztW5GdB4s8HEDwktV+7WYwqppai21kBLmL/mGt326J04b91Vf60rBgWkj5IheI55LBGX8+zO0hR2WR3/aXOJjib1CNgWlDWGa22JHRy1MYJ0zEsP/OLZfY84qYt1JByQ765JOUfgRpjfYP9toot3QT7rmPJJJ0vRwSV6+gPSRnXs85X9pFvgTjsZzt4OKBOtBIS+Z9FwY45S8s6MK2EZCrHwaAyl0tbKF1wGeHTWSKlxmqstCZaK4/GZxy9gy+2QjI7OqcQpSubnKlZwzR9R1x6l90mobCxF275udV48sHpcJqD7uRky5dY4yce52FN7swhVY2739w9JciMjKapp3HSLk9sEzXkRGWVPxv3S665Agn14fI1LjmzTSDEexxc2ZWfdLsVd6X3fsnlXCXihv6aIFsdHQUw0M2zICy2+jj7BqrmD3FQytZlIapwpOOvL3Qr3yG1Huyh8tECNedrosGOWG2O961IKDqo0oOn7co6q+H+f9lDAgdz4T8AX/OuAtHzhv5fkrAOAyHX7uJD6kcw= 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)(22082099003)(10067099003)(18002099003)(4143699003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bys1bUdQVWR5VE9IM0ZONnpUdksvSUVXcmhsOEhKbE4xNlI1YmRlZnhiVUEz?= =?utf-8?B?a1Vwenh4YlkxSDl6SGR2bVYxc2tTM1BCZHVQZFR5b1BuYmsrZWR2Y3RnUFQr?= =?utf-8?B?VVdYNElHdDk3YTNHU2FUMmhqWE05czFnYjN1Y3BYVmd6dmhnazI1TWtScXlZ?= =?utf-8?B?ejV1MGM2eXFWVjduUEdBZ0QvUUtqeEpQSFdrWDBPUW93aWhwMDl3MnROc0RD?= =?utf-8?B?OG1FdlozQ09ydFArZ3lkb3dKbzN5dmhLS2kxY1ljZ09UQ1dlcTI2dUt2ZEZZ?= =?utf-8?B?QmJYay80OWVNK1FEM2d2V2xlOExWRWZWeTZzL1Qrc0xKU1dtV3FHYXEvd3l1?= =?utf-8?B?Q0ROUkRNajJPMFh2S3pRMm5ob2ozako0dzdmSkxFeGMxSUNZbThhSDFTMmN5?= =?utf-8?B?bi9RRVIxVTY1aWF2MFF6YlZsamFvdzk0SXVjSnRuMFZLbHdnSkVWMEYvWDh4?= =?utf-8?B?bGFmeHN6LzFJclpUbWQ5dmNHK0FpQVZ0Z3VvUjRKWXVWY011aGFCUkNHU0t5?= =?utf-8?B?aGJnRlgxYitSejIyeFB6ZE1yb3dIMkZBUFBmTnM0TndoTnl6dUNUMkJ0Ulhv?= =?utf-8?B?VjFtV1ZLclkvcHRCUHlUMzB1dzlaai95TzBvMmc2MEhhaDVqOTV1S1NseDI2?= =?utf-8?B?NC9hZENEYURCaWNNNDUxL3pTenl5RjJ6UVV4M09oVkE0TGZaeE9pVEc5b0Er?= =?utf-8?B?Ymw2cTd1QkxKMzF2blF6bDViOERiTldTNDJReXBDd09Pc0tnaTRPRitzNlI1?= =?utf-8?B?dEVYUVZZOVg2UjZYeXc1SFU0N0huQ1R0dERrei8rZWIwbW55SVJNaUdKMUpG?= =?utf-8?B?dE5EekNmYXh3MWxmdmdpWENDUVA5ZUdTNUhYalc4ajNaZTFwekpKZXlpNDZ5?= =?utf-8?B?OE1BcnBrWHVhRWlEcnlWL2pZYXMydmFxeXBRdVVSRlBHSXJSeU1HSE9XZDcy?= =?utf-8?B?Qm1SYkhDMXh5UzU2ZjZYeUpxWEJYMUJBcFlSZTVXVXo4MmZtaE5ITExSR0xj?= =?utf-8?B?N1ZWaGVoZjdoeFpTV0pIeUxXTEN2cXFOa3N4RmhQMVVYcWtVNldneVNuQnVl?= =?utf-8?B?bnl4UjZyU05VNnAzRy9nbjBpZ3prKzl4alg0RGJHR2grUHZQNlRrZ2t3UnYw?= =?utf-8?B?MmxrSnRYNzFCYkNIYTFuZlpQWCtEaTNOWm5GTUJadXVEbUtlZFZHbGtyV0h1?= =?utf-8?B?d09QT3grTlgyYkZjRnc4Q3Z4UDBFSjFhUVk5NWVKaGM4VWlpQzlPS3A4bEF2?= =?utf-8?B?VzB2K3pRb1lyQm55ZUZTTFZYOWpuaDhXTHRpd0hHM1QwdjBJNXZKSklpSHpO?= =?utf-8?B?OThZaWtkU2pYMmdzZjhuZUhEeUJqTnlYRWlkVW44bDhUdUZOR2tsYUlnd0cr?= =?utf-8?B?M2hGS3lDQUthdkQvdENoczhLODFmc2xqTHhYV2daL2JzOXJ0QkVob2s0RUZF?= =?utf-8?B?UEk4N0pYazhjSUdwK0l5ZlV6bld2QXlPUU43R2ZGWWJHYjRGbnBXMHEybnhW?= =?utf-8?B?aE1DTHZRSXBVZWxtMVhYSFVVQmFZbzVKZytSMFFyTjRDSkEyWWF2bkMwTUth?= =?utf-8?B?SjNEOGJBbmVObWcwYTZxM2ZXSysySGxEbURpVld3UXVHQllTS0NVWVFKRWxq?= =?utf-8?B?V0NLeWptcjhNdXEyU09mc3drN2ZIQllEbitBaC9Mcy90SCtXeXBGYkFXdFA5?= =?utf-8?B?VHVsWEMzeFg1VE1UNnZOT2h6K0Jvb245NGxiTHBRWGt5aHNDWFlOWk1zb2Vu?= =?utf-8?B?aTJ5ODFFY2ltNFJkcUdQQ2FPS1lMczVIQVE1dzB4Um5CS1Jza3hGbmVqdFZS?= =?utf-8?B?UnpqamNSS3VtRmJDbHZUOFV5aGIrdlpEWlRYTGtvN09lejh0dXN0MHVnNUJw?= =?utf-8?B?L2plMXNGVHFVcDFPaFE2RktxY0JKTnh2RTdsOVh0cHd2aEM4TTFqcHlKWStD?= =?utf-8?B?SjdtdEZ3aGtmWXJnN1FTeFlvWlQyaTgwT3RnZjZBYkZpTTJpdWdGWFlycFdx?= =?utf-8?B?WmlsY1F3S0djN3l1U1lzTm5kcDAvVXdTL1dDeDFheS9mZG5JbDh4SHhNdkVO?= =?utf-8?B?cjhhWnE1WWtFejBqVlFoNitWemFsUWRSQ212eGxMdVlJb2pDQWRjcDBqaDRh?= =?utf-8?B?QnlSSzlxbDV1OTFSdHcrekNrdU1MVG1YekFuZk1QcWpXRUQ5UmtnVnljVStR?= =?utf-8?B?Q3cybVAraTRIOEc1aDkrK20rVUgvMUR5dkx6MGVqVGl1VVE5NThTVmpnRzVv?= =?utf-8?B?b0lNVlNJaG52L0pLZzQ5VjVrakhyQ291cms2UzVkZmcrSUtLblVweVZvWHZn?= =?utf-8?B?Ym0zRDl1d1hORlVTdzFBZEUvdFMzSTJPdkMyZWQ5dGM2SDNSQjluQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5000a09c-ccbc-4a08-e158-08df246fd9a4 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 12:38:12.2122 (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: jnLGt0eLSnepB2o/fUuIH1WlVGLdluDr9PVxbq3pNlDxozlBIbSmNT89vMadjOBq9f1g8K/ZiPNZXiqsUSREjwE5DS5+tvUOoWxPNIouMhk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8023 X-purgate-ID: tlsNG-c201ff/1791376699-F74BC2A1-AFD56B14/0/0 X-purgate-type: clean X-purgate-size: 1149 On 07/10/2026 11:40 am, George Dunlap wrote: > diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c > index 4602c32cff..0b0beca15a 100644 > --- a/xen/arch/x86/mm/p2m-pod.c > +++ b/xen/arch/x86/mm/p2m-pod.c > @@ -911,7 +912,12 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > if ( paging_mode_shadow(d) ) > max_ref++; > > - /* First, get the gfn list, translate to mfns, and map the pages. */ > + /* > + * First, get the gfn list, translate to mfns, and pick the pages to > + * check. They are mapped one at a time below, as in > + * p2m_pod_zero_check_superpage(): a vCPU can hold only a few transient > + * mappings at once, and the p2m lookups and updates here need some too. > + */ Actually, I think this wants almost entirely dropping.   Yes, "and maps the pages." needs editing, and should probably say "and check for being a plausible candidate" or so, which was missing previously. The rest is a justification of why we do mapping in the same way we do it generally, and not useful to have in the source code. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Oct 07 12:40:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 12:40:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442298.1659872 (Exim 4.92) (envelope-from ) id 1xEQwg-0002OG-Of; Wed, 07 Oct 2026 12:40:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442298.1659872; Wed, 07 Oct 2026 12: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 1xEQwg-0002O9-Lj; Wed, 07 Oct 2026 12:40:30 +0000 Received: by outflank-mailman (input) for mailman id 1442298; Wed, 07 Oct 2026 12:40:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEQwe-0002O2-QL for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:40:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEQwd-00FNLK-Mj for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:40:27 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac63dae-e002-0a2a0a5209dd-0a2a4507c808-36 for ; Wed, 07 Oct 2026 14:40:27 +0200 Received: from [52.101.201.18] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac63db9-b4ea-0a2a45070019-3465c912c10c-3 for ; Wed, 07 Oct 2026 14:40:27 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by IA1PR12MB7519.namprd12.prod.outlook.com (2603:10b6:208:418::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 12:40:22 +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.0496.010; Wed, 7 Oct 2026 12:40: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=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=te5tjDTC11RLqkQjQTzPZjTXXzPOioZFK1+H2wMAoXoIQC234cVm9YfIFDgsuZcUdQU14EFRHdr1o9sJ/IWaOCgZR1lLCkIesRa1LMoYCYha/wpSbOvZB/IgQ4CZ4G/tAI/deVO65VH9cQsPiS9tpOczM2kb9IyQ5PE8BhGaY5V6L52j99q6s2N6fdSl5fuwPbBZ40UBakPvWEMQbclRCxKmAqX/TbfKr+TERDbUTF83Nt8qZdZeGSatEJ3+x6n//IwXB0upehYevHGGjJ/VLywnlDCYNr+VaGcYOkvSJg8UsFXswy0wJ7VYQdiUIgYB2I5d3AU8E4+jySeZSZ13tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bmh3QbpAof4Mqz4sBwWiSL+74rmVYal5ceFU8kCv9SQ=; b=yRDay9qKvIOn+T7s+pgM20x9Se9XXk5vrjyWuNwjkhEZIY2rWJR8BtFAyoBNH2ifLvUBt1Rs7aYQY6F0w4udHhinJP5P8oGI169RJK0oWxsQ4cpyYls2iZszd2a2adIcUIWrHsOaO7sohprTY3/gV65RlFRWe/0tPYX3bbcxk1mUiW/3NCE719rY3w5yz/DgS7WdCS3yofgt+7xjuYgOdPzqyWjhlQLOCYTHSWMwlLYqi+6lLqwvOad/2NKYQpl63AykdLneGj+/DV89tm7exG13/vZ1x3ED+cUo61wwnl6RxApEp74BeBkiIg1I6aTLbcLdi4PviOnfwrwUtzEv+w== 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=bmh3QbpAof4Mqz4sBwWiSL+74rmVYal5ceFU8kCv9SQ=; b=owx8Kl0BSLVYX/GoN8Tg8IjYs7AwYSxHY5vmsUDPWHJ7/NDEqL8AdRau2dJN765ymhxSbqce7l+DWXzXzlM5jSYveTfgGf7kx77xR/gDk4scd4foSgWquRUou++YcqkQaWi1004xqcJFs4qDbd7jFVWPvpmgVs07QVC+J80jXQs= 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: Wed, 07 Oct 2026 14:40:19 +0200 Message-Id: Subject: Re: [PATCH] arm/nospec: Make nospec helpers always_inline From: "Alejandro Vallejo" To: "Orzel, Michal" , Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" X-Mailer: aerc 0.17.0 References: <20261006103142.139422-1-alejandro.garciavallejo@amd.com> <311e02a0-8935-464c-bfa1-ec4e6aa23462@amd.com> In-Reply-To: <311e02a0-8935-464c-bfa1-ec4e6aa23462@amd.com> X-ClientProxiedBy: MA3P292CA0018.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:47::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_|IA1PR12MB7519:EE_ X-MS-Office365-Filtering-Correlation-Id: 03a686b4-32c2-41a6-6296-08df24702766 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|22082099003|18002099003|10067099003|11063799006|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: A7uTUwZVhYUyRGt0UhKh1rrUmx7Yb1XBM7FDvRmwaIj/RAs3d6JlZ4usMVeW7lsApWyC+qoKffPcWHF+ZFG0bSC0wJ3J7LfJLgTTUndLKK3G85EqvNrVHetGCSLhRU8VUsG6DrGWAciIs04iCKFdtveKmQBmB1BZ08Ve56aE9h/9swADiULZf1C1sFXpNruFKhi6+rDyxI5fVoaKMd6Y0lrWjqqOOu6G6vVorAlUoszUp+39QHLo+rbFK2Mc2Y2KWqQxqXtYrB35Src9nt21R8zs499/+6TpSAYN+P1N6Fjq3ET7+CsHYhiYCl79IiwYhN180PFoxYDSNk2/p1NJWq6IyxRq9IA5MnJjKU2V2Zp14jAniwRFbRO5Wv8NgY8koR6/75g6CZ4a5d3j0jM+uGRHASoWR+Tq7u+an97SiQshX9UYZNP1isW5yYaZpfOxofg1vB3WDrsKF2M28z5AXoP+aKWKPkGEmLB7rEtB4vuuvM3JlMRdZ0lrtOIUyQi3FOOEoz1bgUNbk/jOVumqZllNCha8iu17z9yN/ErzFapbuhov3FWBym5mGsTLK9m/XwpmpG5qFFQinnFRoDd7lsYe1d/MJOJE3D5YqWvuLLeCk44oI2F/L2uA3wmwimBA5oBiN3pZFSNxMFNBsQqPyT4Aaesg4pLwdCCxx2yIaL0= 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)(23010399003)(376014)(1800799024)(22082099003)(18002099003)(10067099003)(11063799006)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a1JzL2JvMHIxdjcza0QrTER1Z1FNMGs3VDdrSkV5d3l2UGt6dFdYMHdyLzd0?= =?utf-8?B?YWxQNVJpYU5wazltc25wamJ2eGNxZ2RuSXZhQitqNG9XZ2lhdXFuUmtMblQ4?= =?utf-8?B?REhQQ0VjZ2pFaGpmODJHT3lFS1dXUUNIUEkvLzRoU0kwdHByNElKMVUxT3FV?= =?utf-8?B?Ui9hV0oxd1BRWml5cnNJNmlrY1duRTQvTkxnWDcyTFJSZE1pV3VBck9FblNS?= =?utf-8?B?a2ZNeUdxUHl3eTdUUUJWaWlkeUkxaXdrQXdmZWJ5Tytha1lmUTI1YVdobk11?= =?utf-8?B?Tk0xV0ZvLzB4cER1RG5zei9PWEdEYXBTcGVmMDJvUmJqT1pJRHE4bkVjalQv?= =?utf-8?B?ZWhua1RHbUJNNHlFcllBUU43Zk96Y1lZTzVKUVpFdXZNejcrNWIzTCtqOEtp?= =?utf-8?B?OXVaV0s4eStHc0FNVGtUTXYwSnVWcFVyL3puV0loUEJkM3ZoSFE3WUNhMG1t?= =?utf-8?B?d1BmTkdLMkJTRGF1ekJ6S1U0T1dFWGRXdGlXMkJDRlUxMGZSU1FwNEd6TGxZ?= =?utf-8?B?bGZWOUxGa2NvVkcwSjQ5SnUxN1JITjRZT3cyYWE0dDFWb3daN2UxdzVqYmpz?= =?utf-8?B?eFNCOWVKRERKYXVxZWpHVXAwdVNYZTFLckJPZ1h6K254SG1ZRGE0R3B6SnQw?= =?utf-8?B?QlUza3IyQlZFWGJPNnBzekZ4eG43dVU1YWlWUWRTZ2EzNy9YRXN5eFBPU2RF?= =?utf-8?B?YnhYYU9FMjUzTTdDMCt1YXRXMytCZDNyVmNCL0l2V0o4WHlUK3VkL0YyenVw?= =?utf-8?B?UU9PTXdFcW5wb3hPM0FjdWlGYjltbmFsS1Z3OFJlYVpkdzVkbERzQ21Sd0Rt?= =?utf-8?B?V0FldlBzbEVyQWtWQzkySzFiMGpkMzZ5UUxaZkpuc2JROUIzZFNidS9qci9o?= =?utf-8?B?eFFyVVdwb2pidUFFOVF4QWZPOWw0RzE3MUlob0FGTndGdzVYd2QrR3NmaUFL?= =?utf-8?B?ZE9zaCs5RnMrMWdpLzlydGdkVUxTRkFBR3lrQkN2cE5tb0FwZDZMcGRZSjJF?= =?utf-8?B?K2tSOEsxOGxzWW1zcGNmRWxSLytKZmFlM2JQOS9kZzFkN1pTbGRjUm1rM2pa?= =?utf-8?B?NnJ1Wi81MkExc0lxUitVN21RV0hKYTk1cmpKSVVjclMrMTB0bDcwc0htcTha?= =?utf-8?B?aXVXRUtraVlxQnpMc1RvbjVsT0hiSG45bFk0SGRkV3hkdGpleVI2RWtIMm93?= =?utf-8?B?RlgrS2ptYnFyODdvQ1EwOERnbmpSMWovelhOZTVqdUJBNmhDNndwVHBxYnBj?= =?utf-8?B?RTRBM21zY0tiNWRCSHdJOTBES2RLM29Id0dmMG1WYStYN0M1bU9wSEFPWkhF?= =?utf-8?B?UGJrOHNVc1ZwRVlZVWFleEpZUkduOXVBamFucnJuMkw1U2JTdnExODVKeTlR?= =?utf-8?B?NUUzRHk3SWVCMjBjVTh5RlpyMWpMVWZDQ0NrOWJ2UGRMQnBaVzFkOFIvM1Ri?= =?utf-8?B?OXM4NGl6aEFRQncwVitFREU2TnRtMkExZHlvSkpJdnd0czVYLzlKcEQ0K1FT?= =?utf-8?B?SGVGemlqV3VRaW04czZhcWxSeDY2SitqVmxJMFZoQWRlcFczUnhydlpnalVi?= =?utf-8?B?ZytjS3BGK3dhZ2M1MGhMdXRQbm1VQi9RZThKWVlRU0FhbTcwcUM4MjZhKzZ3?= =?utf-8?B?M29oM292RldvVGZKaXlBRitQYmFSM1E3dWF5akpDTERJMEI1YTZJMXM5Z244?= =?utf-8?B?VmM1bmo1c0wyRDAwempCc2NidDIwMDdkbExWdFBycDl5RGlFRy9PUGoxNjJu?= =?utf-8?B?Z281WEo0Y3dLeGxERmJxVXV2SDFtVnphcExrY1JibnNPL2JWS1Z2OHpJTEZH?= =?utf-8?B?empiUUxEbFlqTTc1L1V5dHNMRmtuOE1kNDkxRmtUYklFT1c5ZGJ5Uk9sdnBz?= =?utf-8?B?bTZSQ0lvMm5nTlltUnFETmovOGM3aFhaK3NHVnA1YmQwdFAzTjkxbE1ObVhx?= =?utf-8?B?cVI4dCtLV3BwWnN2Zy9pdE5teC9tSllIek43OGxpcXIxb1luM1AxRmdpSG5a?= =?utf-8?B?RlV5emRCeWJlNi9mMDBzRy9lRDc1aEVmSlFvZE0yYXZlNnNmZ29xSVVIVWNy?= =?utf-8?B?bEFSZWh3VTF6KzJyUEhoMFIxNThjZjZkbmZJWittSEw5Q1Qwb3dhMmRRL3Fy?= =?utf-8?B?dmVxVnpuMmJzNW9XS0RhM1ZSOW9qTkx5ek1iTzZpdnpvUWR4c3ZkVmRJaHQv?= =?utf-8?B?K1o3Q3ZzWFhUQ1VHRERERlBROW1HU0NtenpaZHpHTW4zczZQMnltZk9QUXkz?= =?utf-8?B?Y3phbmhxUHc1VEFwTGoxa1BBNXpISHljQ0k0UUtZakJKRnZaYW13Q0lpVDFv?= =?utf-8?B?NWYvMFBYVGU2ZGM0LzA3a294SWNkZStzTmc5bGRQK0MwZ3o5SVMwdz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03a686b4-32c2-41a6-6296-08df24702766 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 12:40:22.6857 (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: fVeRwnubDLI/2vZKRESdYO+mTrKG2AX+8G0dpsDwvNQ2w3o0SKV/y+aIbPsJPRYVSSODPqTBZ1Grh+l7j9aRCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7519 X-purgate-ID: tlsNG-ef75cf/1791376827-A5AC0AE4-F9C648FC/0/0 X-purgate-type: clean X-purgate-size: 1223 On Wed Oct 7, 2026 at 2:00 PM CEST, Orzel, Michal wrote: > > > On 06-Oct-26 14:29, Alejandro Vallejo wrote: > > On Tue Oct 6, 2026 at 12:45 PM CEST, Orzel, Michal wrote: > >> > >> > >> On 06-Oct-26 12:31, Alejandro Vallejo wrote: > >>> While today they don't implement fencing in a way that would block > >>> speculation, once/if they do they'll absolutely need to be inlined, e= ven > >>> if -fno-inline or -fno-early-inlining are passed. > >>> > >>> Signed-off-by: Alejandro Vallejo > >> Reviewed-by: Michal Orzel > >> > >> but this should be done for Arm, RISCV and PPC at once in which case y= ou can > >> keep my tag for v2 # for Arm. > >=20 > > Neither RISCV nor PPC implement nospec.h today. Should I considered the > > R-by just settled for this patch? > I'm not sure I understand. You wrote that they don't implement the header > whereas I can see: > arch/riscv/include/asm/nospec.h > arch/ppc/include/asm/nospec.h > hence my remark to fix all at once. Bah, I was on a completely different baseline than I should've been. Even v1 doesn't apply cleanly. Let me prep a proper v2 then. Cheers, Alejandro > > ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 07 12:48:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 12:48:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442307.1659881 (Exim 4.92) (envelope-from ) id 1xER4j-0003D2-Fu; Wed, 07 Oct 2026 12:48:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442307.1659881; Wed, 07 Oct 2026 12:48: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 1xER4j-0003Cv-DB; Wed, 07 Oct 2026 12:48:49 +0000 Received: by outflank-mailman (input) for mailman id 1442307; Wed, 07 Oct 2026 12:48:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xER4h-0003Cp-M8 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 12:48:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xER4g-001ZYo-SX for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:48:46 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac63fa2-bab6-0a2a0a5309dd-0a2a4506bff8-22 for ; Wed, 07 Oct 2026 14:48:46 +0200 Received: from [40.93.201.65] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac63fac-195a-0a2a45060019-285dc9417d59-3 for ; Wed, 07 Oct 2026 14:48:46 +0200 Received: from CH0P221CA0039.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11d::21) by DSVPR12MB999126.namprd12.prod.outlook.com (2603:10b6:8:383::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 12:48:41 +0000 Received: from CH1PEPF0000AD7F.namprd04.prod.outlook.com (2603:10b6:610:11d:cafe::15) by CH0P221CA0039.outlook.office365.com (2603:10b6:610:11d::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 7 Oct 2026 12:48:40 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH1PEPF0000AD7F.mail.protection.outlook.com (10.167.244.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 12:48:40 +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, 7 Oct 2026 07:48:39 -0500 Received: from APPOL-18KY0J4.amd.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, 7 Oct 2026 07:48:37 -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=HT3gxFmMQdGku+BGnvWjndBQJPaiAplA6qzvtG3uPfg469CX/9tqg1jHTI9h1aaxYYA6qkDzlsTq6F3Oxqewad2STaYJp9IuOQIcpLRM05ru6iJDiW0s/P+Htk8vz+PrI2rnfv24MMa0SGwvAt5d2CNr7zifxaBe0ZXqO3+jyesYnGT5KdX0jW9MHb1yRhQBTo3OKVoV0ypWwMcBR/F1CUZWcnGnQuJeovHkD0Z228ORAydEl/YkGo+UGlQYrM0DQHXpzCgL3OM6PyCNnTkBSB6zQd4B9iJCm7DhZYn4KOJ23WOS7nG/vTZaj52PGjaXcOvWobpiH1xFQ6zn4yrXsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HUJVRizNZmdEf6Vn70Frllzcj4hzPR8FEdALiHfbpog=; b=MnV9rdlYsZ5gKCZbU5GKda1m/oXMeCoyBva2F5+20sqxZVSVMZ2zqeZ8nSnhA0z89WXIZiZd7agzH4X3QZi6de5gHqlqwo3qStPGg+X+cOtXBBsE4CFmI+8ViWx+lU5VDm6vnTIbayL9z2Fcd6UIAL4r88WpdlzVBpmSRIW0mpOl1FlSn5wr+N6sqXODOM3c1NrlMi9i5bRJ0IZ1bVreMIT5iybM3NSURYEuFVc5/VYRY85svodRVFQjUrCZxLEVakr81FOr3XwR6uy8o9O0P9DdVTC42SEfODoSpmESbrDYusbflT9qQ7hcJtj3aMRx0JWV6plG5yQh4g7gWTD6BQ== 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=HUJVRizNZmdEf6Vn70Frllzcj4hzPR8FEdALiHfbpog=; b=fhyAD08FUlLlvWv4E8bZzI12GDTjRkjIv7sWdBkEWSWMVSf2b9/hHbN1QPCgF6/1hIhTZ5ol10eaNsnytFRQeem3rwUX0Kdwy3lCxr05ytS8p+pZiyV0X2SyiLciOTEonvXlk1hT6ww7SsuPLrcn6dHODlYDhH3kOqHdnu0XJuk= 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 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?= Subject: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size Date: Wed, 7 Oct 2026 14:48:13 +0200 Message-ID: <20261007124813.177940-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: CH1PEPF0000AD7F:EE_|DSVPR12MB999126:EE_ X-MS-Office365-Filtering-Correlation-Id: 834729a6-669e-40bf-2397-08df24715028 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|82310400026|36860700016|10067099003|56012099006|11063799006|18002099003; X-Microsoft-Antispam-Message-Info: CIcEy6FnlUif4L0ZGy3rixlH2FBUUkpPR7dW8vT1xR+gMrNXMU5flc0qCfzwJgxwM2mOxrNh+UjlLIIcko/Z4FAEzEpL/G4/oac37pWcljk81220gXuTeYFIn/ka4Fnb+sL2kmRRtCvNgOlRwzE4l+nZFNB/vg6MDbo0R8mQzgvQA6ptvkHJEDSqPLyPk3ZTgLT0sOiLCkrIarTEhcSlGnUjTG/WLQLud4iBlL7MScH/WiWjm3lLiu4t/Hbb1ZKgjvS44LyoDmRh6H1tBvR+Wck+X83GS0Ixmx96tAzJs7LOilOxL9q3teU6aCBURVAtgkUY9Dr5R+y9zeFlj/ysKw2hmwL11MkUioY7Ml0C2Et7mJaKABfO5VAodqbMQbuxRucIrHCHSs7htMeOjWK2A9RXsTtpdiGIlrumarNoWg1m5xn4PznvPrNjrG3QUw7jhvPfxRGx4JQISrRS10A6yUvEPQAXvd+VzWbKukRH6y6HTVyg7500OXgPZVElW/XCzpVhSNWJuRgJfHhMKNGJtsFLBhqYf5P+oILn9RCxvoVuOfD8UP7tvPPq2t16FBaFy0dNAO7L2k7jRa+RDR3LXUKhYwltZvtYToinmsF1AjT9y3FgCw9Q0ItnfzNMlx73jZZT8YPZPqyK0JEjYmT9dYWQxjytHtcRS0iQH2OyqsHDWd83p4B7YFhCx/L/792xk+tycUkXZFCYG0+ARoQ5gw== 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)(82310400026)(36860700016)(10067099003)(56012099006)(11063799006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: XDU+JlnGaWN12K8IpPZ/6TGvOPQf4T4NjCy0X3wFWu4/EAy6A+31psI+4BcCgFqp77wOcHpOj4/Ye1HxgiBKvFRcBlZYVIftWki6gVS91FfDjD3zKIPiQuVBAYMdzyR5FQvOp29Bv2ZKtxKFZbSkVht+3E6iaa2b/h88jOagwI8CJqeMzp95ztuHuXmnsWW1dszypRoXpeerTsPUWGXEzOw5SPk56Pva10YpXSjmof+gMY3PK2UboAXAPFWlHxQLZU3qMGyImJQnTSmrFe1kh67d/6okl/xNlEu29FiHO2ZmRunoxL33R83NdWVAsHBhkaBRDR1KsAdarEDktVXi5Rb7bWFprgWrVs2YsHdlfeB5dLmO3SaQetBtYvSGURSFeXQFvehrh2+rk0CEclcX4AhAzIAZ6i3f7o8AGGYsaFMQE5wp+sn7hZUj9L8i5khJ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 12:48:40.4034 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 834729a6-669e-40bf-2397-08df24715028 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: CH1PEPF0000AD7F.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR12MB999126 X-purgate-ID: tlsNG-16d1c6/1791377326-F72C677B-58E5BB7D/0/0 X-purgate-type: clean X-purgate-size: 3432 We require memory to allocate for a domain as RAM to be a multiple of a page size. However, we neither document this nor sanity test. Specifying memory size that does not conform to this requirement fails the domain memory allocation in the non-obvious way that is difficult to parse for the user (printing over-allocation messages followed by the panic that Xen could not allocate the requested amount of memory). While there, fix indentation from tabs to spaces for "memory" parameter in booting.txt. Signed-off-by: Michal Orzel --- docs/misc/arm/device-tree/booting.txt | 4 ++-- docs/misc/xen-command-line.pandoc | 5 +++-- xen/arch/arm/domain_build.c | 6 ++++++ xen/common/device-tree/dom0less-build.c | 7 +++++++ 4 files changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index bcb06bc796bf..7dfac2062a37 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -155,8 +155,8 @@ with the following properties: - memory - A 64-bit integer specifying the amount of kilobytes of RAM to - allocate to the guest. + A 64-bit integer specifying the amount of kilobytes of RAM to + allocate to the guest. Must be a multiple of 4KB (the page size). - cpus diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index ea0e3368b1d6..d49db353d8a8 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1020,8 +1020,9 @@ and architecture-specific domain limits. > `= ` Set the amount of memory for the initial domain (dom0). It must be -greater than zero. This parameter is required (and only used) when the initial -domain is not described in the Device-Tree. +greater than zero and a multiple of the page size (4KB). This parameter is +required (and only used) when the initial domain is not described in the +Device-Tree. ### dom0_mem (x86) > `= List of ( min: | max: | )` diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 72d531618045..bc3d1ebad1c4 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1881,6 +1881,12 @@ static int __init construct_dom0(struct domain *d) warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR NOW\n"); dom0_mem = MB(512); } + else if ( dom0_mem % PAGE_SIZE ) + { + printk("%pd: specified dom0_mem (%"PRIu64"B) is not a multiple of a page size\n", + d, dom0_mem); + return -EINVAL; + } d->max_pages = dom0_mem >> PAGE_SHIFT; diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index fcbeb8adbd73..b3f24e5d555f 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -789,6 +789,13 @@ static int __init construct_domU(struct kernel_info *kinfo, } kinfo->unassigned_mem = (paddr_t)mem * SZ_1K; + if ( kinfo->unassigned_mem % PAGE_SIZE ) + { + printk("%pd: specified \"memory\" (%"PRIu64"KB) is not a multiple of a page size\n", + d, mem); + return -EINVAL; + } + rc = domain_p2m_set_allocation(d, mem, node); if ( rc != 0 ) return rc; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 13:34:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 13:34:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442333.1659889 (Exim 4.92) (envelope-from ) id 1xERmn-00022O-RH; Wed, 07 Oct 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 1442333.1659889; Wed, 07 Oct 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 1xERmn-00022H-Oc; Wed, 07 Oct 2026 13:34:21 +0000 Received: by outflank-mailman (input) for mailman id 1442333; Wed, 07 Oct 2026 13:34:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xERmm-00022B-K1 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:34:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xERml-008Ig2-Q6 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:34:19 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac64a4d-8faa-0a2a0a5109dd-0a2a450aaed8-38 for ; Wed, 07 Oct 2026 15:34:19 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac64a5b-f2d2-0a2a450a0019-d1558030dc52-3 for ; Wed, 07 Oct 2026 15:34:19 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a16aaf2067so46580575e9.0 for ; Wed, 07 Oct 2026 06:34: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 5b1f17b1804b1-4a17f493761sm108208455e9.2.2026.10.07.06.34.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 06:34: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=1791380059; x=1791984859; 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=69LatKWuTl442WAQ2wOX8LJAx2OtprmYI3vYMK0Ne0k=; b=nxEQWW/5aUApIogBcdePfj/7vrpCmU5fA9jFLZcN0ve2TaTudl+5vzOlwB0qpifadh HT9SEyCg9qVgWa8IwCG49kigDMWC2BEe3oOAsrtOASsg9DXh9AbrHKWio+Mk7k2UF2D+ e63oY8AOa0iXkVH3q4R/Ga7iOxBNLiVATmSwUb1Sg7/3XCLLrcIb6VW8C2ILB7Me8tHH Dc96fol3tVacmfmIYdD6deB7Fo1GGXFEOzESmcFanCLhP8ZYXIV+fPORfZICSjzbaeWB jHo6cg2In3NZ+kcRkoau81vnG7KGbg/FuxtAVk3r5GgE/GelIMd4sZdWWonVyd8CAZhD sEEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791380059; x=1791984859; 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=69LatKWuTl442WAQ2wOX8LJAx2OtprmYI3vYMK0Ne0k=; b=G+4MbBMEyaZIyKAm6JmmLO4Te1ZPssGrTFiOwHlFm0hzjcQvZwbtWEiMhtaOHfKJvS EPF31KN3ppx8Gm6aXOf0mFZlpkb2F+a9nUeHzIJ1HHMGuRwqRm2DjW/K/55ywrBPNnMx m1c0EKX6RmbaG9L0BtY8EaVU9mtvgQw4dQmxl96/eDaHSkg22YZU+YbPDiCh4fZBrI+o CpxlUZfVoAduhTHGQq+dAVDQQQC7dg4pPekWon6tfg5gEzFI1E8fQ/uQtZl7TRP2Jo0P A0EBXn5bX3GhjsshHZVhd77dO7fRu4yykVaoUsABAmygvS5NxQdhqpHYewaAz9MfuS// gLEg== X-Forwarded-Encrypted: i=1; AKwUvBwxelhen6DgynNWFIFGtj2WBl7llHXW5uo9ddfvAJOiOV12h/niEh1akHDXuNW3wdPU9biUzh0nOZo=@lists.xenproject.org X-Gm-Message-State: AFuF++kO+J7/+Ym/f6zLSdEX7+YTW/EQp3R9DUNic48OFlD8oEy/I0uw Ter0uGoekZcYB5tiHvspTAkJCVhKLb+YFNGc86W4xBsjGdOck7kTvBND X-Gm-Gg: AYBFou0BUE47/V4EGJhGd4sc8kjtaZpGXnVjzaPDgDufpWadcWvIL/Tbg55ZWe2UD0Y 9y3sAIjKAH9bVwuTMlOn5DpI36ogXXVEahdWifLXkpN+60YfjKQ8fceE6kFYmUYjHJzxjH2EABQ 2No9olD7Wx1Xq7DYEIyX6LsZAQOIU5kAFuMvAE5BzDsV7LXzUJpCBAeNS9vSSoscbrsRSbLUafL XHri3eYEeehXd7BjXcIa22YtPy9PBZdWAK7wOTC4K327ABqny7ZI1FLZ/IWVptfk4I8gV5Oz1oE vIwUllPfxAKW2CNqlQhvxLAqU2oQm3/PGMmBPGxGvzLAi670AemsOqbzvV00u7LLvl08u/8nnFo OkemE8s9ei4lO/Svx6nCFLs9W1jcrXy9y5cveSJgEHFMK9sD/yTPXGHIEgXzRFJ23vFVusok7VR a9TWxh6BZcDs62+whBVSElDz/fZ2nYI93UDxPm9Wt5Q/7XAvSIFauFC9HE7hepqS46dmfkCRtad 9uX+2zngkexGJTCmaYJ72c5DTJtSX0LDE5PWtg4eLAw0jtQFA== X-Received: by 2002:a05:600c:4687:b0:4a1:7811:6cc4 with SMTP id 5b1f17b1804b1-4a180650943mr41275485e9.34.1791380058348; Wed, 07 Oct 2026 06:34:18 -0700 (PDT) Message-ID: Date: Wed, 7 Oct 2026 15:34:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs To: Teddy Astie , Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc References: <1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech> <1791216017.8631fc262581453bbf619ec5b2062170.1a10ccb5ec20003f66@vates.tech> <793b6d0d-68ca-4f9d-8ca5-c37f2c013478@suse.com> <4a0b0d62-c312-43c1-908a-fcff7c081149@gmail.com> <4fa78acf-4de9-48bc-aea8-fed774d80cfa@suse.com> <1791374346.8631fc262581453bbf619ec5b2062170.1a1163b4a7d0003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791374346.8631fc262581453bbf619ec5b2062170.1a1163b4a7d0003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1791380059-514C7CFC-2F4BB363/10/73395122804 X-purgate-type: spam X-purgate-size: 3439 On 10/7/26 1:59 PM, Teddy Astie wrote: > Le 07/10/2026 à 13:35, Oleksii Kurochko a écrit : >> Also I am looking at henvcfg register which we could access in HS-mode >> and it also has ADUE bit and the description for it is the following: >> ``` >> If the Svadu extension is implemented, the ADUE bit controls whether >> hardware updating of PTE A/D bits is enabled for VS-stage address >> translation. When ADUE=1, hardware updating of PTE A/D bits is enabled >> during VS-stage address translation, and the implementation behaves as >> though the Svade extension were not implemented for VS-mode address >> translation. When ADUE=0, the implementation behaves as though Svade >> were implemented for VS-stage address translation. If Svadu is not >> implemented, ADUE is read-only zero >> ``` >> >> So, at some point, we could verify how OpenSBI configured the hardware >> and compare it with what is specified in the DTS file. >> >> The only problem is how to interpret this part: “If Svadu is not >> implemented, ADUE is read-only zero.” The spec does not explicitly >> state that Svade will be used in this case, but logically, it seems >> that if Svadu is not implemented, the implementation has no other >> choice but to provide Svade and so basically we could detect if Svade >> is used based only on ADUE bit. >> > > To my understanding, when !Svade && !Svadu ADUE bit doesn't exist and is > MBZ. That doesn't imply Svade semantics must be unconditionally applied, > but the contrary (otherwise, it would contradict the main spec). > > AIUI, Svadu && !Svade behaves the same as Svadu && Svade, as in this > case, ADUE mandate the PTE A/D scheme that is effective. > If by default ADUE is 0, then we have Svade semantics by default in > practice, but that can (*maybe*) be opted-out. At least, in my version of RISC-V privilige spec (Version 20240411) ADUE bit always exists. It could be read-only zero, yes (in the case when Svadu isn't implemented) and in this case according to the spec Svade will be default behavior: ``` The Svade extension requires page-fault exceptions be raised when PTE A/D bits need be set, hence Svade is implemented when ADUE=0. ``` Hence based on the spec version I mentioned at least something from Svade and/or Svadu should be implemented. > > It could be interesting to check if the P550 has Svadu && !Svade, as it > may explain why Svade semantics are effective while not having Svade > extension. p550 basically follows Svade behavior. The open question could also be if (in that *old non-ratified* H extension which p550 decides to implement) it supports henvcfg and hencfg.ADUE bit. But I am not sure that we should care about it now as it is mentioned somewhere in cover letter that p550 support won't be upstreamed at least for now because of some other difficulties. I think we should back to this question when we really will decide to return back to full p550 support in upstream. For now, for other boards it will be enough what was mentioned above. ~ Oleksii > >> If we accept this assumption, we could fully verify, in HS-mode, both >> what is specified in the DTS and how OpenSBI configured the hardware. >> This would allow us to require users to provide a proper DTS with the >> A/ D bits update scheme correctly specified. >> >> ~ Oleksii > > Teddy From xen-devel-bounces@lists.xenproject.org Wed Oct 07 13:40:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 13:40:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442343.1659900 (Exim 4.92) (envelope-from ) id 1xERsX-0003n6-F7; Wed, 07 Oct 2026 13:40:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442343.1659900; Wed, 07 Oct 2026 13: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 1xERsX-0003mz-At; Wed, 07 Oct 2026 13:40:17 +0000 Received: by outflank-mailman (input) for mailman id 1442343; Wed, 07 Oct 2026 13:40:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xERsV-0003mt-N1 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:40:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xERsU-008JZo-Uq for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:40:14 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac64bba-2eae-0a2a0a5409dd-0a2a4504d5aa-10 for ; Wed, 07 Oct 2026 15:40:14 +0200 Received: from [40.93.194.24] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac64bbc-b57f-0a2a45040019-285dc218ade2-3 for ; Wed, 07 Oct 2026 15:40:14 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by CY8PR12MB7121.namprd12.prod.outlook.com (2603:10b6:930:62::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.19; Wed, 7 Oct 2026 13:40:07 +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.0496.010; Wed, 7 Oct 2026 13:40: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=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=RAbmGUgxHvgWE7ljK44jpU1qPoW7g98xJWud9MXDJwcGRgY3JKHzXJiKNyJgBs8F2HIC1Gvh7MinKCFWOijqHiTYHbFcoLEKVg/mhFsHiapt2zz8mI+fHJcKJ0S+CVvN4QdcxGnyAgON/hPlZi8l4VGNg0JCE9EL7XpIBLtCdf8WRSjn4nH/dBM8bCJPWn1l0yuXmKohaQdJQPc9WOhOGogW8svdcimIgqvIXzdLuvhRdFPUsqSo7aBqhfpNMks9QGO8jUQyT8qfUi/i3Wui2EyoItvR9v6R7eR7pWRpRPb1d+j6cKZiLoKLigsy3G9tePLPaHt7LBzcK9oHg49e/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=Cz9WeqqwdBHYfBplQ//PrsacBTML2jDjUyTygECUkQE=; b=bBAOaOOAa35wXqIsOgC/0+tSUol8E7dB7qjzO2oRkYaq2MlXgCbc3Ty3KpVkerlCLqeSm+m5oR2vbxS5kxuEXT8wfXQrN4zfGliZsuUG0XSsWRbwS+LUsbM2YdJAViWtzlgV5XFyPu4f36b+AqBexr91laaKw0k51UlaDN1btzlt08V4ufmI/5pwBzd4tRs1OirMbqiUYBjrFAV6PBOrPscG4QkBUBryLNuEzXOqypCvQgILUr8toK9RzIDaCQbRLde1vd/ShKuCC+9lrf15kNAFBsijT7T9ckQiiyCWcU8Hy1w3Q9tRTwtC6VLFKJjqIs/7Hu0nQIR6glLDSA+x6w== 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=Cz9WeqqwdBHYfBplQ//PrsacBTML2jDjUyTygECUkQE=; b=kHvuQ/BSw60hzslzOnkWOYmXbb0QWg7rDswB5cPrbXFeO8wp208uhoEwf5E4Y2gvMmSoGm0Gz6/Oiz40K0Wji1bV4QUL0aaVBl9wCNgbcAmO+spfKBpQo/GdGAudqCNqZQAm342X3ogeR5yr80L7N5KEVt4mqW3toPY3LsmHsTQ= 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: Wed, 07 Oct 2026 15:40:03 +0200 Message-Id: Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" , "Andrew Cooper" , "Anthony PERARD" , "Jan Beulich" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size From: "Alejandro Vallejo" To: "Michal Orzel" , X-Mailer: aerc 0.17.0 References: <20261007124813.177940-1-michal.orzel@amd.com> In-Reply-To: <20261007124813.177940-1-michal.orzel@amd.com> X-ClientProxiedBy: MR1P264CA0055.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3e::16) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|CY8PR12MB7121:EE_ X-MS-Office365-Filtering-Correlation-Id: 70a58ec7-13f2-46a4-ec66-08df24787ff4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|56012099006|11063799006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Uv4E4TTxDT6gf8xIyP44hgVKEcFqcVpoY7By4RUEkE3bPooOTCp/9Qjjj71vrnjcqJnqovc9grju86jqh9dv6BpJ24DTX9dJmPPVPHobZSMPLNIPj8BYqkqtqeHvv4teKImauAn9q2of/zxPnkh1dEFOlLYi48RRrUKh41fgnjLmfp+zSI2HP9Y8SP3glsA0l+MMpvAMSmcejHS0BMNud5zS2zgMmd0U8IGIwFIKSuJEEMPOxM+l67oPmGBJyB+XCLtIixAuq2hVZECyOzmtJzGDrm3kwBKxWWYX3SQmtHP3fHg/WMPi6Ky4qTd/ZE3cdzP7dmaBeOA/qYT/c5uS78CAB2DY+pV/W+yhEvAb0gNdPG1mUZ9U4sEhS2fK9tO4wPFsoG2/dJsBjtTJWQJQ+/aX7OhNdx6U3ZqaU7BJC6yYWIYkkZUxcttt7mIEJoTIOyPC4DiroJfsvoB35qyaJ2qGrlA+Mg+HzyyDPiOO3you876qxOYx0VubK7zRgAZFFbKbMW7xMC8TTqNG+R25Wo5SPSrimzT8eR1C3xTqoizCVYWNrymwvv53oCLPIkj8nve1MQlwZws27V4ionDWYBD9oTVeqNKEIZlu5gjrEZce1PoNMHXI8GcAxvp+IE1isyz5i+ISpdiivqNYCJqbXM68FePvt9llF1kw6SDn/Aw= 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)(23010399003)(366016)(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?cERkak5NTEoyUG1uZlE3OGJiRUxlMDdodUFDdVhKb0hQcy9JSGhKaTIvR0Rh?= =?utf-8?B?eTJlelZJMEordTZ5VyszYVNtWWhzTHg3UUYxaHY0dGhWcENvR0l3NEVtSlNq?= =?utf-8?B?alJKVVpjU2VlQUJxcUtqWEtyS2tab01WT3JDWlBNNmFQVmJuUVV5V2tkS1Jy?= =?utf-8?B?OXhrQXNORmlobmtDN0pLSWZ2dk9QQkgrZjV4OG1UWjc5RjRKdGJlOFEyR01B?= =?utf-8?B?RCtqMUNnelNQOTNTVEk0RFhadkpqdmhObUE0akJLdFZXTTRWUk43eTd1STJC?= =?utf-8?B?ZTRxaUh6cXllV29xZEE1VGZMbjdtUzFvejdGaHlmdDduZnFwTzVrNkxDYk5k?= =?utf-8?B?T0JzekhZc3lHeUwrR2RFQThIRCtGZVhlYnNMcEZIM3d6blBhN0x3UEFOdHRM?= =?utf-8?B?S2h3SE82ZkdHbzJTbGRTQk41UUs1RytwdTc5UlJYZDNscjNaY2R0Mno4ZG5l?= =?utf-8?B?NTZTYW11RkhKcVRjYmdraDN2L3lDWHE5UCtkNGRNUVJ0L3VUaHQ4NGpDSFNt?= =?utf-8?B?aGdjS1h0Q2I1U1pGbmQ1N2ZSUXowOWpJa09objZBYzdzeXk3L3V5cGErWFRZ?= =?utf-8?B?VWhyd1k2dnB1My9hcldrMWM2MmN0MU9sV2lXOGM5Ujc5ellrQnRhYTlXdC91?= =?utf-8?B?d0dzeHpTVnlqeXV0aEpoY0JnL1BldUQ4VEZlRFhKeE9TMkl1WEpGSjBTNjlx?= =?utf-8?B?clNJTERpRXIzYVRCVFBkWUxRM1NMYjZhTnpNUkpqN1Rjd2dXSlhGQVArVnIx?= =?utf-8?B?WUd0Ky8wUFZGQUh3ODZndEd4am9HV016UTIySyswZkFhZ3EreVhBeXBDM1Zx?= =?utf-8?B?ay8rMXMyQ0xPTURXK1FaelRudk0zUUZWNDlESGEralJPNWZSMk5JYXV3NVk1?= =?utf-8?B?Q3J4TkpUM2U0bFlacE04Q1JFRFJaWjRQSTZrWjNici9WQ1Q2Ujg4d3Z5UW5n?= =?utf-8?B?ckxDRzR5dXhrTlBVSlRzNEgvWUpUNFIvQjB6WElRREVwdmluZDcwd25GMlk4?= =?utf-8?B?MStFbDVmYlBYTHZlQ1dCQ1Q5SExkM0k5MnRqd1h6YUR5MUVGdGNjWWF1RFNW?= =?utf-8?B?Yy9GL1Q5alpuUGNISmhMQVZXaHpXUHZUckZXaTFwSnNOdGlDRHU0WDlodlMw?= =?utf-8?B?VnpoYmJSTXlpMHJFdkYxSWpsWjlLeUdzaUJwQy9lc2k4TmdWK3dYdDFEb0U1?= =?utf-8?B?UGlyZWF6QjNRSkVweGRJakdYZzlobXlQbWw5b3FZU1RyOW4xb0pQbzRkaFRF?= =?utf-8?B?TGVCandSaS9zYUpxWUZhQkpHUGdCTDZsaFZDZFc5SE9lR1VQVjFpaHVmVTVN?= =?utf-8?B?RkwrVkJhcC83eFdvU3EzY2pSd2tyaHdLUkJHVXZSVi9VK29rbmwrNUlpVEQv?= =?utf-8?B?T1A5Szlkd1dvQUc1QXl3TmhtWFpLVWI1VkI4elg3SFlBNW4xLzdKZG51MU5s?= =?utf-8?B?YmRBSmsyQ0swZDJ0cWNKU096KzFmcTM2WkpsTE5RbTVhTHZoWCtHVDBSTEFy?= =?utf-8?B?V3BReUNVWnBEaThFQ1B3ZjN5VXRLU3oxYzMvNzc3aExIVlc5NXNJMlIvOUw4?= =?utf-8?B?SmZYd0tYZTdJdXFkWXMvRWpmZXp6OUxiakZSODErYS83dkhTdjllUHJKMEtO?= =?utf-8?B?bWl6Ny93WTVaYTVBNGZDYnh4UmtrN1lFRDF3Q1BCRDAvWUlMaXhZcmhmTEpD?= =?utf-8?B?ZkxXcEQxbXEvRFNsNHN1YS8rTzNVQ1V5S3FkRHVTWkNrTFlJZzBCVVNjQ0dS?= =?utf-8?B?V3pOSEtqRk5LQkhGZDFzM2hLUEd4VnJWNE4yNU84SFVndTdJTFVFY3RzSllh?= =?utf-8?B?OEZVam5aL1JTRWNwTFhiNjA3MG53MklqajgyZnJZSTNNdmVvRlZPZ2VwM0Js?= =?utf-8?B?ZjJ1a0xsejZINitIeHhXREVOT01sckRhSldtcFRrYS8zKzJxc3FSL2tsNzJq?= =?utf-8?B?TWx0Q1ZWQ2ZYQ2FyNEZ6OVVmTGsxYWp2WElBTkRlcmdEZjliUjE0bUV1emhD?= =?utf-8?B?cnBSWEltbitlZDlSUXEvWUF1dmJMTThJdWlSSTAyQnhJdWpVRDNEOTJqS3RF?= =?utf-8?B?M2dreUdWenN3b1BwVUN5N3R4UFpNbHdreDV5WGRUbUJXSE1nQVVySWszNVp3?= =?utf-8?B?Yi9TUk1HZmxHOVFTdWhpUnZVTDRPa0ZlQkpRZlN6bHIyMmNyV1hxWmJIZllE?= =?utf-8?B?ZVZSaE1DUUpuSWJYVHRvMTh0eGRBZnVvZHc3T2VCZkpZR1ZaZFowMjlsRzFQ?= =?utf-8?B?eEFZN1BLNEtZZnVHQmJLWjVSamdDcTc0M1Y5SlFjZTkzdWpTWXJHYVFhT0Zq?= =?utf-8?B?RUlET3ZQV05ZazhpNnFWUU8rN0hrUXQxeXBsYUJJMlExQjh2U0QrUT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70a58ec7-13f2-46a4-ec66-08df24787ff4 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 13:40:07.3624 (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: GjjYCTqFeG7zbfFVCorPRPkzY2TnkpAJUZY+ku8faFIOMRI3+BCnI3tzqPE/DPOJ14o0ZUBpldFK7ckf/wF4/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7121 X-purgate-ID: tlsNG-ebf023/1791380414-510DDB50-8F1CCF12/0/0 X-purgate-type: clean X-purgate-size: 4337 On Wed Oct 7, 2026 at 2:48 PM CEST, Michal Orzel wrote: > We require memory to allocate for a domain as RAM to be a multiple of a > page size. However, we neither document this nor sanity test. Specifying > memory size that does not conform to this requirement fails the domain > memory allocation in the non-obvious way that is difficult to parse for > the user (printing over-allocation messages followed by the panic that Xe= n > could not allocate the requested amount of memory). > > While there, fix indentation from tabs to spaces for "memory" parameter i= n > booting.txt. > > Signed-off-by: Michal Orzel > --- > docs/misc/arm/device-tree/booting.txt | 4 ++-- > docs/misc/xen-command-line.pandoc | 5 +++-- > xen/arch/arm/domain_build.c | 6 ++++++ > xen/common/device-tree/dom0less-build.c | 7 +++++++ > 4 files changed, 18 insertions(+), 4 deletions(-) > > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device= -tree/booting.txt > index bcb06bc796bf..7dfac2062a37 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -155,8 +155,8 @@ with the following properties: > =20 > - memory > =20 > - A 64-bit integer specifying the amount of kilobytes of RAM to > - allocate to the guest. > + A 64-bit integer specifying the amount of kilobytes of RAM to > + allocate to the guest. Must be a multiple of 4KB (the page size). nit: s/KB/KiB But page size isn't always 4KiB on all ports. PowerPC has 64KiB pages. IMO, 4KB shouldn't be here or elsewhere in documentation. > =20 > - cpus > =20 > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-li= ne.pandoc > index ea0e3368b1d6..d49db353d8a8 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1020,8 +1020,9 @@ and architecture-specific domain limits. > > `=3D ` > =20 > Set the amount of memory for the initial domain (dom0). It must be > -greater than zero. This parameter is required (and only used) when the i= nitial > -domain is not described in the Device-Tree. > +greater than zero and a multiple of the page size (4KB). This parameter = is > +required (and only used) when the initial domain is not described in the > +Device-Tree. Same 4KB remark. > =20 > ### dom0_mem (x86) > > `=3D List of ( min: | max: | )` > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 72d531618045..bc3d1ebad1c4 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -1881,6 +1881,12 @@ static int __init construct_dom0(struct domain *d) > warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR = NOW\n"); > dom0_mem =3D MB(512); > } > + else if ( dom0_mem % PAGE_SIZE ) > + { > + printk("%pd: specified dom0_mem (%"PRIu64"B) is not a multiple o= f a page size\n", > + d, dom0_mem); > + return -EINVAL; > + } nit: XENLOG_WARNING? Also, is this is meant to be self-healing? If so the return should just be: dom0_mem =3D round_pgdown(dom0_mem); and continue. And if it isn't meant to be self-healing, why not just panic(= )? > =20 > d->max_pages =3D dom0_mem >> PAGE_SHIFT; > =20 > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-= tree/dom0less-build.c > index fcbeb8adbd73..b3f24e5d555f 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -789,6 +789,13 @@ static int __init construct_domU(struct kernel_info = *kinfo, > } > kinfo->unassigned_mem =3D (paddr_t)mem * SZ_1K; > =20 > + if ( kinfo->unassigned_mem % PAGE_SIZE ) > + { > + printk("%pd: specified \"memory\" (%"PRIu64"KB) is not a multipl= e of a page size\n", Seeing how PowerPC has 64KiB it might be prudent to print PAGE_SIZE to avoid surprises later. Same remark about panic() vs self-healing (either is fine. It's this middle ground that looks off). > + d, mem); > + return -EINVAL; > + } > + > rc =3D domain_p2m_set_allocation(d, mem, node); > if ( rc !=3D 0 ) > return rc; Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Oct 07 13:44:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 13:44:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442358.1659907 (Exim 4.92) (envelope-from ) id 1xERww-0004Q3-TW; Wed, 07 Oct 2026 13:44:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442358.1659907; Wed, 07 Oct 2026 13:44: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 1xERww-0004Pw-Qn; Wed, 07 Oct 2026 13:44:50 +0000 Received: by outflank-mailman (input) for mailman id 1442358; Wed, 07 Oct 2026 13:44:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xERwv-0004Pq-UN for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:44:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xERwv-00FaBc-B8 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:44:49 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac64cc7-e002-0a2a0a5209dd-0a2a450b888e-42 for ; Wed, 07 Oct 2026 15:44:49 +0200 Received: from [40.107.209.23] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac64ccd-b7e8-0a2a450b0019-286bd1172519-3 for ; Wed, 07 Oct 2026 15:44:48 +0200 Received: from BN9PR03CA0901.namprd03.prod.outlook.com (2603:10b6:408:107::6) by MW6PR12MB8898.namprd12.prod.outlook.com (2603:10b6:303:246::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.16; Wed, 7 Oct 2026 13:44:41 +0000 Received: from IA0PEPF0000003D.namprd03.prod.outlook.com (2603:10b6:408:107:cafe::11) by BN9PR03CA0901.outlook.office365.com (2603:10b6:408:107::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Wed, 7 Oct 2026 13:44:40 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by IA0PEPF0000003D.mail.protection.outlook.com (10.167.249.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 13:44:39 +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; Wed, 7 Oct 2026 08:44: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.49 via Frontend Transport; Wed, 7 Oct 2026 08:44: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=gI7aGN/QzFbeVX8EF65Hw76beGcN6kh/lBJ7kwWISUh47nh65ObYmRR1RVDbEPeZHgiqrPETC0Ifx1leSIWqwYFVBzqyTx0yA+m8eetkpw0NLxF2PgpF5wAbNedpljUFDuJBbZbBTXLBj3N2xW//U78lsMTKMUwz348P53IiOyLpQLKMo+N7frclqXw+Gih0F5VjLN+ZTY5VkBdG6JLMLhSCZfio4MD3rlqvUgdc+mr5ikWDGkbIapFfCGKVUlLS78nlMgDdKysgwhSdpJgR+xVle78bgxmF/oo89tuY6WrSzTfThdTUx/HmiWzLSKDXAh1IavsPhr6ixgO9ThT+Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w5WTVUPd9E0VgosHkW7VWrS3q+RIZNjmpZKDgQJ6ixM=; b=AJ+XQvhC6C1N3rvBupNhe+c4wStrhpkK406pctx/4278pkfr1o6C2zeqiUdWJTE7g4kKJFHbGB0/7ro7t4cqpzg04UiOUa/1ZVHmylYi0vFwdHu77RaSTCj8vH7+BZXL1hH3c8LYtmvND5msM3kla5oVn1da+r7AZQjV24seUch7JuEJv9N1Xi36LtWyg2Zkr5nSULnLqfFOKqX/7Oc/5i+TCYntEhKldU28BcZaeELfT36LrN30AQ8o8+nYVi4f645WbsuHR8EsrxJj9sbB5vMdWg5mtRw06jc/CbjP/zVzhzb0jL1Zit0JuyA2VncTQrzOXQyW1k1e0+v9U6xMzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=solinno.co.uk 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=w5WTVUPd9E0VgosHkW7VWrS3q+RIZNjmpZKDgQJ6ixM=; b=Xy38J6VUguYEB1Y5SWuWErmnbQu9IFXlmOFgtEXqLph/dLpLn7Qm4Fx0+8g832EChMBzZy0SRFODwdtY6FawiaW5qQm5YGbsAYxmqMoXU7sZ0Y9DdVJPpuj2efuKg9CctIwHxU9BP7tsy6hFdKj13ATgBpi3F4QYyk3ypegI/ZM= 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: <2d2765c0-be80-4f51-9a6e-a4f6d7507ea3@amd.com> Date: Wed, 7 Oct 2026 07:41:45 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/2] Finalise bridge VLAN support To: Leigh Brown , CC: Andrew Cooper , Anthony Perard , Jason Andryuk References: <20240517140506.8460-1-leigh@solinno.co.uk> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20240517140506.8460-1-leigh@solinno.co.uk> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PEPF0000003D:EE_|MW6PR12MB8898:EE_ X-MS-Office365-Filtering-Correlation-Id: 43fb34b2-38ef-4566-37ad-08df24792282 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|376014|1800799024|23010399003|22082099003|18002099003|10067099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: B7l1UzDYfTGvNXPIgi63aB+OpTqE+oOS3DI5Zrrj9PEUBsgme9xloIv+alpKEyvt2030mcwhMLBqPP/1suhmTuM3cotTeVbsSTbatljGzu/AYMTd2eoM2r+eNl+nP3UAzYDDCdkPF7W+Ew3qEOYSv87j4z0I3HzWtUguKgbwF8RqYJcrnRPDpxi8LaHERLVuwQfrUMdJ5flQoSrLu+zkOUHmfT76TurgdoejXDoyIa61SE435Cuwjj0Bg4SPcO9EB9lLHiIYHSqZWaXMx46GS6MyzXo6Jr7lMvHhSI2QHv9oyA5OCX3wIZrTdZ93iHwjCiululUz1Oj/qq9qw2U0dTvVmROLsIu0xst94JX9c/P6rrKiQb2ASrpiBueEiQFA5l69/AjTBHHf0bAYRyWFvkuxUJ/GZo/jWs9Iorj6xn7CXSG7/AHUaxFERqU9Pjgzfkyzj2HvrnLxyg6u9udpXE+prbwjMgdoA2Z03J3nRTs/RB6R8bW2HrNhaks3nvHGNhYs9mXrKLUNCefTBPYB+ntctj+LU4RG9aGpl0/Ghmw4Itg1DT5kLqQ3jlI9nhHDrTApPJ6BqCjvgF2ieg0od/XmFb2kz8Avq7kUCMZFquMhUPn56K3XPlJzhvARXK6r8pT/IdbM896hyfJ/5IgaVzZz4vqaCp8x39rgCt+rfeC02vA1JcuNIRwM+8h4snucuPjGam7Mvl5mwbKB5VCUNA== 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)(376014)(1800799024)(23010399003)(22082099003)(18002099003)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: innjrUNoTxkpbShyIqZvMEIq3P9MQJTe1Tal/sHALpncTypdZuX6ZC1r97psjFKH/gVI9Efydz+S7EKJMqvyQnB/rNj6I13tcLdvNAfAiVEnvNXhoDHgBcb89zH8USirbIzMs9abSg0Se/FjksRe3d42f9fMpvc/wrs5DpQkQQ6a+yPSKFoaQ9CMwUa9mK3U8wK5qhItULzaVZbkOc/yAG3TW+nGhM7UvWRneaL127AbZ91h5m173DrvnSOBfMDxxm/ibGcqo7ewrLX0yLy8+dOQngkLtKFKhtb9/yjM8GMFMo4pOHRNcgzeuWQsqv7OtaW2kdwM89tlKHvvK1Hn3yVfzodmZSP3qRy3ExWz6wHjGkB97f230dWb0+vUu5Rd+CRkAo4Sal/w0lwrOAEGILjnD5rJfPWY51s2+fq6o/oXPNaC/fnjU3K3ni/MhQri X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 13:44:39.8065 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 43fb34b2-38ef-4566-37ad-08df24792282 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: IA0PEPF0000003D.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8898 X-purgate-ID: tlsNG-42698a/1791380688-A96C29EA-2E93E4D8/0/0 X-purgate-type: clean X-purgate-size: 447 On 2024-05-17 10:05, Leigh Brown wrote: > Hello, > > The first two patches have been merged so this version has the remaining > two. Only the first of these two patches has changed since v3. I was asked about vlan support recently - apparently it's not working. As Leigh states, the xl changes were merged, but these two hotplug script changes were not. I reviewed them, but they need Anthony's Maintainer Ack/R-b. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Wed Oct 07 13:46:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 13:46:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442365.1659917 (Exim 4.92) (envelope-from ) id 1xERyw-00054O-Ax; Wed, 07 Oct 2026 13:46:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442365.1659917; Wed, 07 Oct 2026 13:46: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 1xERyw-00054H-8F; Wed, 07 Oct 2026 13:46:54 +0000 Received: by outflank-mailman (input) for mailman id 1442365; Wed, 07 Oct 2026 13:46:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xERyu-00054B-HP for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:46:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xERyt-002VHa-UR for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:46:51 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac64d4b-2eae-0a2a0a5409dd-0a2a45018c54-0 for ; Wed, 07 Oct 2026 15:46:51 +0200 Received: from [52.101.201.55] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac64d4a-5984-0a2a45010019-3465c9376929-3 for ; Wed, 07 Oct 2026 15:46:51 +0200 Received: from PH7P220CA0099.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:32d::23) by PH9PR12MB145095.namprd12.prod.outlook.com (2603:10b6:510:415::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.16; Wed, 7 Oct 2026 13:46:46 +0000 Received: from BY1PEPF000264B2.namprd02.prod.outlook.com (2603:10b6:510:32d:cafe::7c) by PH7P220CA0099.outlook.office365.com (2603:10b6:510:32d::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 7 Oct 2026 13:46:45 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BY1PEPF000264B2.mail.protection.outlook.com (10.167.242.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 13:46:44 +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; Wed, 7 Oct 2026 08:46:42 -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; Wed, 7 Oct 2026 08:46:41 -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=xF2W/JvG6Bi1ailYuCrzG71Z2O9+UdPKtPbX5e78fGTN5VLQwZq2ccyvsX7wEmvM8+lW8bqmJJlcUv4EPpZeKDqpEmiVRbOWiHztHQXzP1DiYUbguye+YgyT79Dx/SDUjdy78+mgnO0KnZq93/Su70KbNuZ/Izl3c9hEHwYseEhRQPs+ZAqFc1Syv+h7eq5SJv4EXIIFznaSK+mHtiuvT1V2Gshtdfi1ZNK1BopIMxwbmo6Qk3tfQ20E1IoqhqlPR5qBiZ9jsFgNxcAhhtnEQPiUCMvJm6tFLWNEio+NNbCN9vyP86lyvL42LjFReiZy8Qc5StyP2ftV4Uu6OGpHCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ehoWudiVxKxtcEhrI+8Z6MQx3xOk3h86OlBn7DITZ60=; b=UgIcdC0Vp7m8fFn+J7umIgAgTJF/gcqdtFsk/sYuWDjmQZ0IZ4Mh/qV5uvvQgnIQqMFMBApf1Cp58Ak1AfcijD5RjSLjCoP71qPBkSJw+QnA9s6ft+ELMH2xhxOejZeh41Ts0XrVrfuy3dLVhVuVs/LuLqrDATmXXY385Le1t0FDrrAbslhfpTkL6zyv0onUppPIM1v/0pEez5oTN9RkQLGvxBV26num47iGVVMiQEAwkPTyH4uaqP7BXZ0hdZNyfr+VINn+ka1UKV3pzJtIqBcvhSEs4/+UlEyHPUl/ZwJkM9A8qxaGajNpdxT7MSIn6jXvuCk60sScy/4O2tePJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=solinno.co.uk 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=ehoWudiVxKxtcEhrI+8Z6MQx3xOk3h86OlBn7DITZ60=; b=fH5PQFPrrvxtBkQMmcSRwAuZ8xe9ed5M52BWAySNwWE0rlxBEVUgwQE3TtUFRN6oHn5tnwGFX1NIdzD7iHLdCEFzm4Qh2z+/z/LHyl9VF9JE2o0Dcy7TLGUMHnn5RiVnJrkH1abbtfRRVo9KlP7m7b+Sws3PTtkzXhDjxAdER4w= 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: <299f80e8-63c4-48d6-8b79-e492ab85b81e@amd.com> Date: Wed, 7 Oct 2026 07:43:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/2] Finalise bridge VLAN support From: Jason Andryuk To: Leigh Brown , , Anthony PERARD CC: Andrew Cooper , Jason Andryuk References: <20240517140506.8460-1-leigh@solinno.co.uk> <2d2765c0-be80-4f51-9a6e-a4f6d7507ea3@amd.com> Content-Language: en-US In-Reply-To: <2d2765c0-be80-4f51-9a6e-a4f6d7507ea3@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: BY1PEPF000264B2:EE_|PH9PR12MB145095:EE_ X-MS-Office365-Filtering-Correlation-Id: 06a90732-0918-42e7-218f-08df24796cf5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|1800799024|36860700016|376014|18002099003|22082099003|10067099003|11063799006|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: tXq/Yeug04IgM6fpMj8WPvFs3CTkHgBQeLpOEmDJogDHr9p2vokooPOI6xzq9ZRnrzXaRypO0E7EgMebRDbG1UpvFAc/W+1e4plDHIl2dytZ84C3iGrOas1du45B4MuZX4uX6ADyZ8Ma7R8IcKCqp6ErV0K/gIUyMxhlacTUGlanzhn91LB4lSIf92LBFeqnptF0aJzf+UACV1AMfmSphz26domnv93fJy2BgAW9kwQxLVvD/8Mt2vBzbxkdYieMfv1Sgwj49dGFKioVZnarhKhD+XU27tuLf99fsdBEGkQpojiVMk0BONu0EUOxs/MCxr57cfACm964acnA8DJqk3PDVZfvm3doVungWeQgkPBcnOymGuX9LE0Y3XnxRY/dYi6Jwf7bbIi5Cs5F9BFuHV1FEfzNuM8li/qTaFaoaHMt287ZgBhaoWfwKV8VB205hhF4ljuWmuaV6nDfF58KIXet7bI88Ewcdb5G7xAsgubvZFh204MmkJ+uRONeBC+GPJ29+D5Lat41GE2fFK2HXtzFUX2UrF84qcvO1AGAmKummC9ZHUUrZct9uQOHawsz4c2fDg4PKzlg5cB2vhUdOTIfpolCDkEvSQI3novesw68XdeD1mlNZs0u99Hnq9/G8FSeuqeMh3+Wo/QkiOSla87pein46tld9pXkR+ZvEFYAdN78cibnvV4c7/Jz2UjZBRicr6Vt+/6YFd3DzsR6PA== 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)(23010399003)(1800799024)(36860700016)(376014)(18002099003)(22082099003)(10067099003)(11063799006)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: o/v+Gdb36BjVpCOqPlXPcDWhbGadOvmsqG4zKaXcfsZybtgQ9Rx/akfjmbfTUATST8/Z/rY7/jt8lnUH3a+y8slvPoOCjPA7ii2py/5Thb984+R788wLJqh4orDE8zSqsJ52R2VhkCP43VKu9sjRir26qHsP0Ns47KggvyXnSTs7c96ki5p7neH255CxumUqP6/HNGPOnkXhYr727uKV/9GX6Z+mbUXzSGOD+21B7PKfbv/bGQqqoc7RaZCjg1P/2T/IUm5mamP2PsM4ZGunkzGw9bKZ7v7DSbZ+sIqP7IZ4V6xuBxF8xTihiYv/UQK6BnKX2iIgXzICOyvTda8+HGnVudy3L8/kp1AQTh372NQgu09mWhspOzQgdloaXY2Zh6HDSxLEk9a2/H6neeSWvZU01a0G43ipqt3zA1bPxT+xcyPHsIVSYhojlk5FF9Vg X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 13:46:44.6275 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 06a90732-0918-42e7-218f-08df24796cf5 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: BY1PEPF000264B2.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH9PR12MB145095 X-purgate-ID: tlsNG-d62444/1791380811-1D87F757-416A0C55/0/0 X-purgate-type: clean X-purgate-size: 547 On 2026-10-07 07:41, Jason Andryuk wrote: > On 2024-05-17 10:05, Leigh Brown wrote: >> Hello, >> >> The first two patches have been merged so this version has the remaining >> two. Only the first of these two patches has changed since v3. > I was asked about vlan support recently - apparently it's not working. > As Leigh states, the xl changes were merged, but these two hotplug > script changes were not. > > I reviewed them, but they need Anthony's Maintainer Ack/R-b. Once again with Anthony's current email address. -Jason From xen-devel-bounces@lists.xenproject.org Wed Oct 07 13:59:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 13:59:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442373.1659925 (Exim 4.92) (envelope-from ) id 1xESAk-00079d-9w; Wed, 07 Oct 2026 13:59:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442373.1659925; Wed, 07 Oct 2026 13: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 1xESAk-00079W-7F; Wed, 07 Oct 2026 13:59:06 +0000 Received: by outflank-mailman (input) for mailman id 1442373; Wed, 07 Oct 2026 13:59:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESAi-00079O-Dy for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 13:59:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESAh-001mD6-8l for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:59:03 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac65022-bab6-0a2a0a5309dd-0a2a450bac9c-20 for ; Wed, 07 Oct 2026 15:59:02 +0200 Received: from [40.107.200.32] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac65022-b7e8-0a2a450b0019-286bc8200569-3 for ; Wed, 07 Oct 2026 15:59:02 +0200 Received: from CH2PR04CA0020.namprd04.prod.outlook.com (2603:10b6:610:52::30) by DS7PR12MB6262.namprd12.prod.outlook.com (2603:10b6:8:96::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.26; Wed, 7 Oct 2026 13:58:52 +0000 Received: from DM2PEPF00003FC8.namprd04.prod.outlook.com (2603:10b6:610:52:cafe::ab) by CH2PR04CA0020.outlook.office365.com (2603:10b6:610:52::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Wed, 7 Oct 2026 13:58:52 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by DM2PEPF00003FC8.mail.protection.outlook.com (10.167.23.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 13:58:52 +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; Wed, 7 Oct 2026 08:58:50 -0500 Received: from APPOL-18KY0J4.amd.com (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, 7 Oct 2026 08:58: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=ZSNXPvcOlfC0JIRANksZxO43kSQymnZtUyLFYnr22oyX5599yECAXBCj1/Kfq7NJ40nnwph/VM4GqeK19xTkZdsmAtbP306mLkgeJHYwZ8NFa/YgO5QX5f0jxp+EzxZcPTT/0asaVVz/DKNnRnUeFv6Bujl2Yl9ZuKR3WjtyjuseD1wLl1giC9NDgywPbfytWOHO6gPk1rNg4UEuV3I2smyl/fwAf/2EPYPc9u2axkWIjAYvfb4YFZ1Cvt2GEyv3uo26DnrKt7S/Tlq4Jhp9A/flBT5cZSvuo2XfNoOz/jstP14Ce02Uwr8AxF7AB1zemX9mrMnNZQ6jvIATYXRmBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AolQ6BjlzNs+PwrahIUve3U3eotV5pf1jtleJTOhi1M=; b=HcRHHVdruIg6aDWtKepMVLrZyNWKox17Tj2QWvfa3iRoOPX1p+gCcwayHcon7ha926He8+QUQHRSiQGdyqIzuaeXkZ43i9wxliUhK+F1kX/aH9klD7o0FPMbXmSdjpPG8RRGGV8+pdL+OHIWGeiqRVlmZNnIkfUYzzhJW2df9Ue7y6XwaOlhTYvCzlZtwE/5ADwB4aitKK9L+LtLGOoQMes4x4qr+yGQJta3dUKVZg2/2tlIxYyV3lquW6jjFASIhtLcm7trxdCbLhE588QG4KFhFy7fRXzGXeG/pKW3KEmPOD5mueSCvPqo2NiDP71+6Rt0lBXazOf6qztq0qVTug== 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=AolQ6BjlzNs+PwrahIUve3U3eotV5pf1jtleJTOhi1M=; b=SgD2FSBLFnyR1WxnFmVSkMkTCjUDVZTMXUqnNdg47CCAaTmQ611gQF1IrtmWXhmceOAgNBrwq0OYOmWOQWQ2qNCf47csH/KCxy2T9l9eR6JbEsMNWJhNzXFtc8tWV6+YLQSUW1snDg+lCzutaD7qaVtBY7yG5BCNhV5O3ulbrls= 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 From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH] xen/arm: Fix under-mapping in map_range_to_domain() Date: Wed, 7 Oct 2026 15:58:48 +0200 Message-ID: <20261007135848.220047-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: DM2PEPF00003FC8:EE_|DS7PR12MB6262:EE_ X-MS-Office365-Filtering-Correlation-Id: 413cf0df-e157-43f9-90a0-08df247b1e8b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|82310400026|36860700016|376014|11063799006|6133799003|56012099006|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: J+dYTxb706WFa25UM9huY8z+i5GfLJljQgnGsah1xX1FW3gNHr+0dfeW1sh+gNox/VjF+pOsvsg38bW+fTSZWcVTcD0eZl7yktTMe0aW967/VLQrtq8vbLp0K5N4Dc+EhbM+JPGptJ43FIiPwsPn0juSPxiwGD4XLQaifdNm6mVRlUwB9gE6M3DPAE8IfFHSjPCr1+tBUioO1vMIJCsZ9S+j+PUXTH75qszw6SnkaXPct9RHC1xy5szbuwhHv7418FcD8eZlGUz/aciyVjQewA2m9u4SAUd5budB9XzyEZbAZVQuhhmn3Out0prmj5qXjFOEVPltfgyqtm1jxVgguAX1RBBeHykIyGzK0ptia4XFFOCqmRIxxx9RhCPsDoz9nMKQMIdqWvCEVNj1jDJp7PsANxoZjWCFg5m5/SnGUgWMRlDiK1NVUZJDCS8GBFN5lHlE1ED1Cgw+E0FBwPWjLgSFdHJAckNsF7LKW/lAkEsUwGx0oZ9s4XedtNgNdUs6YIQ5J7DzR9zY0u0wW0c51KP6l2RTVVLeWdR9ItdqPeOCtjowOZuD7L9lf3Ib5ez3pz+RqVLJZF0QAZFyxuqTiUvJXHZhwJsQ1bbEhcmlk4iW9sEsmfu0wKtsulYabZtpGMNiwHd2taByP6l1vYaikToNvc3t08BcEDD6Lg+laMSMCedwDeFw5EMDon7Dqiov2Z9vYG5xL+oaYxWK4IDfew== 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)(1800799024)(82310400026)(36860700016)(376014)(11063799006)(6133799003)(56012099006)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4y7wWS6cSqKnv4/zNHxuME9yQR0aX16eplU0FWnedZPVJFELJocgzRRR2Bpj9rSQQ26DvSYGPAKj0cuKKTDR2tOCSqJRSduPheSEbQ+XL0ElEVIK4jJ49gH8T3AAG3ySJbq+WY5X29fxONaV/JNsZwNxNrQaRS8rNHVw2XPO8tsiZR2VLqoKwY2yuYR/A1954vKSJciWm+szp07W37tkbJX+Y5Xfu3Pu8+qE/QWTzoa7fIY1BGeG3dziNyf+MsSf7lVyZHT0foN6Xi4OmBKYjCBJjzO1nprG/DaRoy6ee4Gu5aMAbpBfdUo1AbeVzh4LMWr8j42+bmWyHIPfAOlgq1RhJ8UJMJqMLFYagzMIJtXnn/3qyvSbuOno3Afv4li6nne3uJY+m458Vf03TfE//S5qY6GLGn8KJiLJeC4PhhiL5SxZZ8/eRIahhRjhwypk X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 13:58:52.1035 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 413cf0df-e157-43f9-90a0-08df247b1e8b 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: DM2PEPF00003FC8.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6262 X-purgate-ID: tlsNG-42698a/1791381542-192CC9EA-0A5000C4/0/0 X-purgate-type: clean X-purgate-size: 1165 If the memory region to be mapped does not start at the page boundary and its end spans over the page boundary, map_range_to_domain() passes a number of pages that is short by one to map_regions_p2mt(). Domain's attempt to access memory within that page will fail. Fix it by calculating the number of pages to be mapped taking into account the start offset. Fixes: 88c10b0d6eee ("arch/arm: let map_mmio_regions() use start and count") Signed-off-by: Michal Orzel --- xen/arch/arm/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c index b11366d722ef..ad50838b9f11 100644 --- a/xen/arch/arm/device.c +++ b/xen/arch/arm/device.c @@ -89,7 +89,7 @@ int __overlay_init map_range_to_domain(const struct dt_device_node *dev, { res = map_regions_p2mt(d, gaddr_to_gfn(addr), - PFN_UP(len), + PFN_UP(addr + len) - PFN_DOWN(addr), maddr_to_mfn(addr), mr_data->p2mt); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:06:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:06:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442383.1659935 (Exim 4.92) (envelope-from ) id 1xESHe-0000OU-VW; Wed, 07 Oct 2026 14:06:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442383.1659935; Wed, 07 Oct 2026 14:06: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 1xESHe-0000ON-Sn; Wed, 07 Oct 2026 14:06:14 +0000 Received: by outflank-mailman (input) for mailman id 1442383; Wed, 07 Oct 2026 14:06:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESHd-0000OF-I7 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:06:13 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xESHc-001f6P-2t; Wed, 07 Oct 2026 14:06: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 1xESHc-002gsy-1l; Wed, 07 Oct 2026 14:06: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=Vv5lG8kNckQBl7yOzo92aC95niVE4Zl0Y7N88RjR8ME=; b=NmdwHEYvkuhZ1BMY6iJao9i8JN W/audPmvampMAv3STBxKyzFX6oC+mf2Itn2r67VTgW6lEYDzq0nC07lDeSxe9mapy813clZNug8U1 UIcMCUVfToK0bdnzCnztoA2kB4wDGqVLWyLVMg3U9/pFjHqD3sLgNlfGvKFBg3gtUhII=; Date: Wed, 7 Oct 2026 16:06:07 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 02/18] x86/mm: purge unneeded destroy_perdomain_mapping() Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-3-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-3-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:35AM +0100, 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 at both of its call > sites. arch_domain_destroy() unconditionally calls > free_perdomain_mappings(), which tears down the same entries and > additionally frees the page-table structures; and the other caller, > the error path of pv_domain_initialise(), returns into > arch_domain_create()'s failure path, which invokes > free_perdomain_mappings() as well. > > One vCPU-scoped caller, pv_destroy_gdt_ldt_l1tab(), is covered the > same way: a vCPU is only ever destroyed together with its domain, or > on the failure path of creating it, and both routes end in > free_perdomain_mappings(); the GDT/LDT slots hold no area-owned pages, > so there is nothing else for the call to do. While we're getting rid > of unneccessary callers, drop this one too. > > Note that free_compat_arg_xlat() keeps its explicit teardown: in > addition to vCPU teardown, it serves switch_compat()'s undo path, > where the domain lives on as a 64-bit one and the argument-translation > pages have to go. Add a comment to make sure it isn't missed. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - Note that pv_domain_destroy()'s other call site, the error path of > pv_domain_initialise(), is covered the same way (Jan). > - Also drop pv_destroy_gdt_ldt_l1tab(), the per-vCPU teardown call > (Jan), and comment on why free_compat_arg_xlat() keeps its own. The > Reviewed-by tags given for the previous form are dropped. > > 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 | 10 ---------- > xen/arch/x86/x86_64/mm.c | 5 +++++ > 3 files changed, 5 insertions(+), 11 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 192309c2fc..3924c1b204 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 03262a4952..07ea4bb4d2 100644 > --- a/xen/arch/x86/pv/domain.c > +++ b/xen/arch/x86/pv/domain.c > @@ -332,12 +332,6 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) > NULL); > } > > -static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) > -{ > - destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v), > - 1U << GDT_LDT_VCPU_SHIFT); > -} > - > void pv_vcpu_destroy(struct vcpu *v) > { > if ( is_pv_32bit_vcpu(v) ) > @@ -346,7 +340,6 @@ void pv_vcpu_destroy(struct vcpu *v) > release_compat_l4(v); > } > > - pv_destroy_gdt_ldt_l1tab(v); > XFREE(v->arch.pv.trap_ctxt); > } > > @@ -394,9 +387,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); > > FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab); > diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c > index 8eadab7933..2a1805964d 100644 > --- a/xen/arch/x86/x86_64/mm.c > +++ b/xen/arch/x86/x86_64/mm.c > @@ -737,6 +737,11 @@ int setup_compat_arg_xlat(struct vcpu *v) > NULL, NIL(struct page_info *)); > } > > +/* > + * Besides vCPU teardown, which free_perdomain_mappings() would cover, this > + * serves switch_compat()'s undo path: the domain lives on as a 64-bit one > + * there, so the translation area has to go right away. I'm unsure we want to be that verbose, but if so I would mention PV explicitly, possible: "the PV domain lives ..." Otherwise LGTM, but I don't think I can RB or Ack it being also the author. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:12:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:12:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442390.1659944 (Exim 4.92) (envelope-from ) id 1xESNR-00025p-Ib; Wed, 07 Oct 2026 14:12:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442390.1659944; Wed, 07 Oct 2026 14:12: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 1xESNR-00025i-FX; Wed, 07 Oct 2026 14:12:13 +0000 Received: by outflank-mailman (input) for mailman id 1442390; Wed, 07 Oct 2026 14:12:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESNQ-00025c-Pi for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:12:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESNP-00Co7a-Ak for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:12:11 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac65331-8faa-0a2a0a5109dd-0a2a450ca94e-36 for ; Wed, 07 Oct 2026 16:12:10 +0200 Received: from [52.101.193.18] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac65339-f479-0a2a450c0019-3465c112f82e-3 for ; Wed, 07 Oct 2026 16:12:10 +0200 Received: from DS1P223CA0003.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:453::8) by CY5PR12MB6324.namprd12.prod.outlook.com (2603:10b6:930:f::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.16; Wed, 7 Oct 2026 14:12:00 +0000 Received: from CH3PEPF00000016.namprd21.prod.outlook.com (2603:10b6:8:453:cafe::1e) by DS1P223CA0003.outlook.office365.com (2603:10b6:8:453::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Wed, 7 Oct 2026 14:12:00 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CH3PEPF00000016.mail.protection.outlook.com (10.167.244.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.3 via Frontend Transport; Wed, 7 Oct 2026 14:11:59 +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, 7 Oct 2026 09:11:58 -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; Wed, 7 Oct 2026 09:11: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=cpY07SY9tIh+Bcgwk5D79c2tvGpEXvAwCX9qluXf8IrHDSqXi9NSEn+RizQl05219eOlsm8CtC5i6mJqMUPkUVXVEgBw7tl0srHJ0EX3JISu5szluJSNk0iy8BEYdLFoPAyea/7Zoou0TmzjOA+Yc2sEdeQ8RfsVRPFqmeh1kQP7O/FNp5h9No+D2oR0zTBQD0LwXAMOcDyNjG5k3YGugXX9ppdkm6zbmknzY0KPdpJE7IFqH5hhViwGArPv0tAsSLb03XspHHzWOwjtGgLJLUOsW9ntEsoMJRI9Vutz85NyX6xk9Id65zMsHE86463owpDFFRtBKLx9luqorIrX1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=F8PJJt72r4MKUoSLSWYFAElI2DUq3ANtL5xCa9pcYcE=; b=otsDL7LfCJUQTZM6WaxYYV5mNnvhriZ3JPOFSoev7CeZa2zSazmfXavX4n0plmKpPFxiOgK426ty8MRRfgGTkZMIvZDAKQfrxJpFTY2q7U2k7b20pINOuhqtCrKman8acLG+fWFJHlSQeEpDs7tc17y/aBr6n4CZ2G/czsqIXUA8YE763yiCfcYBl/aertBnvHOwruqG/bh/BG7GI8GcGDocTclv2uMS2girFaO65HXFPA9xwkHBjdo3fjKprp3L4cnMLtA5Kz/GFdaB3qkdld2CLvoX3/OA3LcW3NvlfvEuMMnut7F3hp1Qm694XD/Hlf+LEKfEd0927fjd3ZQifQ== 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=F8PJJt72r4MKUoSLSWYFAElI2DUq3ANtL5xCa9pcYcE=; b=zfIJUfS8nH7nquxw2aKjoYyLvCOiOHwWoBqOdafw345/8ZegDzdKhqvUKv7hS/8iqNtYnKPpnNWUfpLHK/9yk+vfRJNGf5IoBFlnwITyCLpZ5QNruiAbpmpYmdR8s/wI4hVZezpM1dCxBvXO9v8UMBqgyLOthYwLa8UGAytaNq4= 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: <45cb2679-c79e-4d67-abaf-a4fe8e5ddc51@amd.com> Date: Wed, 7 Oct 2026 16:11:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size To: Alejandro Vallejo , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261007124813.177940-1-michal.orzel@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: CH3PEPF00000016:EE_|CY5PR12MB6324:EE_ X-MS-Office365-Filtering-Correlation-Id: 8b9c1594-dfc8-4e16-0da9-08df247cf418 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|82310400026|376014|1800799024|56012099006|11063799006|4143699003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: +qx9XmRa/9YsXUp2iDdcB+/TbrH+UDPV+kMoliaCU1ijqp1HpeDB0dbYWFs8fgGVJ+W+qqgKXcSYPppMUsXSSxWlIm8rt39k076jhQAiOvB7D1OyHg9VuCRtmYnjplHFy2tXCPJlbc6CpC12acmmNL6pSGl9JVziGlIbKFRZUB0nAApMOTOJBj0CWxcW7l0EEScr/DNyUAX3Q4A3MFg5zao4KUPgItIYG3bciV7KQhEZs0f9cRtLFI1OxBe9MEkGPSCjYWxKMwj9LxIyhOqu8j/zj0t09rE7R+yf2iWM8VnRicyHWgouqdINDxKwiyyRSgN9Bh5dwDoKOKOPs4wOvXa/CLi2XMmjEYKlKzGjqR95aiVV6dNGIUR6DXUoULDIijQ2IkjCNoKsGt5iyo+02tnqEWjhKTQaPOh2LS7tfwEovG7t3E7yD7BsJ3oglm7RojRrKYQ91CGcnJlB4D9DAci/rMeYMisXhY8qyyz2CfLGRlFskbY7uncY9e0AkoOx1MQhnSRLlqg6E+f8SJ0HIIj1OZWXIh8LcjVVHMJuBxQ/FjwQnSIctn+NFnKARsnIoF25q2+Vdylae4b06JQNNAybysXPgih7st94lR8X798dPNF6L9hNEi+2Vv1r2TIX3gQ0MaW8lPmTw1vRXBr2DfoadcBw9bkCPNDKTs4JYgyeaQ8QyV6JL2Gk6K65pc7CByaD6/rKhfey3r54ZslH6A== 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)(82310400026)(376014)(1800799024)(56012099006)(11063799006)(4143699003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: kJhxgbg3pgex7K8CaxQALnkjeAOKW9437kmyxAqrYwqCA450v2p7CXS15hyF94MZ8ZBE02BF09u8ZfSyfrQELa+0YCCwg1xoxnoqz7k0AElAjWiWbHEVm3sChzeytkJdpOgQflCjbSLQKCKc8x52OgaagJQUe7rXORNws5PMQqKTKbExRbVeZKGn/Jtprdoptm6UlF33HmdNlGj2DTRRlcBn3eATZehKJKJxYu93fEk+fSYbsbz5JpW3xCH2FpeaxYOOl4oV63nhd1JtSra92T7LffzriTQcPfA9/1jUZXawn3e8WDBoQROhmE0kQvjMNHjl6GPtVzSX7PWa1SbdJL82a+eEcaKRoNROqnmeqVXTW4mDaw3nTzkzDsR5u/eV6Ua+hU2vtyUDnfdPu20vCW4Eadh5/1ei0ciKCCWGv29wZoj34P6qiVMZdzDX1RMQ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 14:11:59.9090 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8b9c1594-dfc8-4e16-0da9-08df247cf418 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: CH3PEPF00000016.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6324 X-purgate-ID: tlsNG-d25034/1791382330-026DEA5B-CA5EF5A4/0/0 X-purgate-type: clean X-purgate-size: 5516 On 07-Oct-26 15:40, Alejandro Vallejo wrote: > On Wed Oct 7, 2026 at 2:48 PM CEST, Michal Orzel wrote: >> We require memory to allocate for a domain as RAM to be a multiple of a >> page size. However, we neither document this nor sanity test. Specifying >> memory size that does not conform to this requirement fails the domain >> memory allocation in the non-obvious way that is difficult to parse for >> the user (printing over-allocation messages followed by the panic that Xen >> could not allocate the requested amount of memory). >> >> While there, fix indentation from tabs to spaces for "memory" parameter in >> booting.txt. >> >> Signed-off-by: Michal Orzel >> --- >> docs/misc/arm/device-tree/booting.txt | 4 ++-- >> docs/misc/xen-command-line.pandoc | 5 +++-- >> xen/arch/arm/domain_build.c | 6 ++++++ >> xen/common/device-tree/dom0less-build.c | 7 +++++++ >> 4 files changed, 18 insertions(+), 4 deletions(-) >> >> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt >> index bcb06bc796bf..7dfac2062a37 100644 >> --- a/docs/misc/arm/device-tree/booting.txt >> +++ b/docs/misc/arm/device-tree/booting.txt >> @@ -155,8 +155,8 @@ with the following properties: >> >> - memory >> >> - A 64-bit integer specifying the amount of kilobytes of RAM to >> - allocate to the guest. >> + A 64-bit integer specifying the amount of kilobytes of RAM to >> + allocate to the guest. Must be a multiple of 4KB (the page size). > > nit: s/KB/KiB Is it? I don't think it matters at all seeing the number of occurrences in the code. > > But page size isn't always 4KiB on all ports. PowerPC has 64KiB pages. > IMO, 4KB shouldn't be here or elsewhere in documentation. This is Arm doc and on Arm we only support 4KB at the moment. User should not need to dig into the code to check what is the page size. It's better imo to give this information right away and change in the future when we add support for 16 and 64KB pages on Arm. > >> >> - cpus >> >> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc >> index ea0e3368b1d6..d49db353d8a8 100644 >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -1020,8 +1020,9 @@ and architecture-specific domain limits. >> > `= ` >> >> Set the amount of memory for the initial domain (dom0). It must be >> -greater than zero. This parameter is required (and only used) when the initial >> -domain is not described in the Device-Tree. >> +greater than zero and a multiple of the page size (4KB). This parameter is >> +required (and only used) when the initial domain is not described in the >> +Device-Tree. > > Same 4KB remark. Still Arm only section and see my reasoning above. > >> >> ### dom0_mem (x86) >> > `= List of ( min: | max: | )` >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 72d531618045..bc3d1ebad1c4 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -1881,6 +1881,12 @@ static int __init construct_dom0(struct domain *d) >> warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR NOW\n"); >> dom0_mem = MB(512); >> } >> + else if ( dom0_mem % PAGE_SIZE ) >> + { >> + printk("%pd: specified dom0_mem (%"PRIu64"B) is not a multiple of a page size\n", >> + d, dom0_mem); >> + return -EINVAL; >> + } > > nit: XENLOG_WARNING? I can use XENLOG_ERR. > > Also, is this is meant to be self-healing? If so the return should just be: > > dom0_mem = round_pgdown(dom0_mem); > > and continue. And if it isn't meant to be self-healing, why not just panic()? 1. It should not be self-healing. On Arm and in DT subsystem in general we chose to follow the contract to bail out on unsatisfied user requests rather than silently adjusting them. 2. I think it's always better to propagate the error to the caller if possible. Sometimes you don't know where this function end up being used in the future. In general if the function returns non-void I tend to leave the decision (here panic will be executed anyway) to the caller. Printk explains why and the panic follow. This also matches the existing paths nearby this code. > >> >> d->max_pages = dom0_mem >> PAGE_SHIFT; >> >> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c >> index fcbeb8adbd73..b3f24e5d555f 100644 >> --- a/xen/common/device-tree/dom0less-build.c >> +++ b/xen/common/device-tree/dom0less-build.c >> @@ -789,6 +789,13 @@ static int __init construct_domU(struct kernel_info *kinfo, >> } >> kinfo->unassigned_mem = (paddr_t)mem * SZ_1K; >> >> + if ( kinfo->unassigned_mem % PAGE_SIZE ) >> + { >> + printk("%pd: specified \"memory\" (%"PRIu64"KB) is not a multiple of a page size\n", > > Seeing how PowerPC has 64KiB it might be prudent to print PAGE_SIZE to > avoid surprises later. Yes, I can print page size here. > > Same remark about panic() vs self-healing (either is fine. It's this > middle ground that looks off). > >> + d, mem); >> + return -EINVAL; >> + } >> + >> rc = domain_p2m_set_allocation(d, mem, node); >> if ( rc != 0 ) >> return rc; > > Cheers, > Alejandro ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:21:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:21:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442406.1659956 (Exim 4.92) (envelope-from ) id 1xESWn-00041c-IF; Wed, 07 Oct 2026 14:21:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442406.1659956; Wed, 07 Oct 2026 14:21: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 1xESWn-00041V-EV; Wed, 07 Oct 2026 14:21:53 +0000 Received: by outflank-mailman (input) for mailman id 1442406; Wed, 07 Oct 2026 14:21:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESWm-00041P-9Z for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:21:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESWl-001qkw-Mf for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:21:51 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac65576-e002-0a2a0a5209dd-0a2a4509991a-20 for ; Wed, 07 Oct 2026 16:21:51 +0200 Received: from [40.107.209.65] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac6557d-be1a-0a2a45090019-286bd14112b9-3 for ; Wed, 07 Oct 2026 16:21:51 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by SA3PR12MB9129.namprd12.prod.outlook.com (2603:10b6:806:397::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 14:21:45 +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.0496.010; Wed, 7 Oct 2026 14:21: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=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=rRVF7fKZPbLJRETL74AuKcXmrZxng7IsSL3eyrD6Eqkvd3j0IMYYwsHOuHZOlctZ0jr0Of7kVfPeH7utDwy6/M7goVDvNUvRdxhEofNhzwXx+gpi0siXGecuFDwLqnMfF3Rb3bWdtKfCkddkgGckkaWy4ATolyjY8beVcyyAKGwodKzhPs+HlLovha8zBYDu1QPUzKAbd6OtiMh+m5EbnpTV1ID0iuKgGFQnnulDIz9cMRJ21GLHJLi4oAH6kJaRzTm4Je2VmCasvWU5mNl5eWFgmYBtzWH87O7VignFqnFhNG7qTspPtZfZAfa4EF66/Cu2xVhN4/6K+6EmBjWfWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=psoKytfEhEGV1HfE4md0GFtZSUeMLgTFdljFFncIOG4=; b=V2U3ViW6vlshZms2Bfcr4/n358S0g9GxE1vJ2QUBZtq1Lrot5cUc84afVWMBDJQPKkW/ZxMtfJ7JrlC86KBh4cbSBbr9msQwRg3o8sotfrsviFl7wVGzcYyAJ4ROPQXPlb0HycBf9bpOKAQTZbFMXqDNlTVBPb8FAG78dxl7cd6J9XoAJUpbqEwdOMWk8ZvWJoEJWOi+GoFDsm8dmLtNAS142hdpw11zb3MJeHSTcwF5itwu9/F2HM72d5SJSj7GwVN7Krl5iOoodkV0bantlLB/BQzcL38k59UEJG0jao/QLL27TrZPCx7nb6m+Jz7eaVa17qqbkEKVpZGT/00tEg== 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=psoKytfEhEGV1HfE4md0GFtZSUeMLgTFdljFFncIOG4=; b=B6j9J+qJtbDIQS6Vy/DHQ7vwIX91K+7s2GCFdolIbVQrk78syfQf6eaeJYo6sYqQ6EYCh3fLlZc0zfbtoJs+LadKcRmyJ4bM1c+bcet3nzL0NZilgIVb6xpxAsiAamvsZHxeMQdHh153s2N5zVgb+VItVu0hTeX47sY8Gzj5PT0= 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: Wed, 07 Oct 2026 16:21:41 +0200 Message-Id: Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" , "Andrew Cooper" , "Anthony PERARD" , "Jan Beulich" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size From: "Alejandro Vallejo" To: "Orzel, Michal" , X-Mailer: aerc 0.17.0 References: <20261007124813.177940-1-michal.orzel@amd.com> <45cb2679-c79e-4d67-abaf-a4fe8e5ddc51@amd.com> In-Reply-To: <45cb2679-c79e-4d67-abaf-a4fe8e5ddc51@amd.com> X-ClientProxiedBy: MA4P292CA0001.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::20) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|SA3PR12MB9129:EE_ X-MS-Office365-Filtering-Correlation-Id: 305fa81b-648a-48d4-c2a4-08df247e50ba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|10067099003|56012099006|11063799006|6133799003|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 5LIrcL5jnVWll3Lg1rl/NM43aApM2blUv+fFVEMY9Z4IVX23BkzfTm8FEl8BMpmLwmfkyJrXQFe/T06FxErfK6qqylijvbJxoouyrAzjBlA/O84qKnrGF+a3/RxGy94RKvyOf7zwUDsys1lYPIXaarF1NH4+gDVDgF3yAn28984nL/tJ7g0DS1Be3nHwO/4CPrB9tTQMPsTdkGckudw0nJOVCuuI1LptdD2tJeEWycF8+x/znHtlQqUOBfJhSYz2CNpd38ncNTUr1xgQZwjzmVjLKR0AJiFTt+8Y5CldXnRB2UZ8ZhPOIEW+bmJSyCfcJeslaR8A08yIpoxYSTjcPrtlS5li22RYSxOojjYkw4atba+EhhHFjmbdHB24tRfFdvrM+u7uhgwEcUxo6PVwNg+yhRIJ6MP7Q/+3d8SxoNZA2K6dJtBQ08egJLot0YLgRVNZEQdyOyyvKTP+wVFUfZblMexxFddsqPLtjm6MmqaPqQ31sukK5ZpTQnlwVfxB0f7RBJvHzFhHLihk934eg9V3pN+fDuYRAVrFppHW7Jtb/x9C4fuRF6eZal0MckXBn/hcJ141Gyd0Lqksq/88qCURUoYlmDBDUOscy9Nbn2k6uYqYu+KXb2oYcxmIEdF59uTZAhWqlajJNwMSZ6hbYLcaxIjW4xvGNZTCkY6iVVA= 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)(23010399003)(366016)(1800799024)(10067099003)(56012099006)(11063799006)(6133799003)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V3ZnbVhCcXF5MFY1ekpYbmMvdFJBdXJ5dGh5VVVtaVdHNmNrMnFyNStkb24r?= =?utf-8?B?K2VtZHlCTExNYUEvSE1CTmZEUjY1anEwUEFOV0RvaVRFanlCTHF5K2xTRjlB?= =?utf-8?B?OFR0c2drbi9sMkx0bUl5RXRZTGNWakVrbnUxQVN4c2JTeERIcVVrRWtEMndj?= =?utf-8?B?V2pLMDRxSmRyeTNkZnNXSkhVMVEvWUhvZU1ORy9pV2VzRFZvUytOOHMwQm5Q?= =?utf-8?B?RDVNVkpjUXlkQnJ5T2ljVWJ2ZDZEODMySWhmV1RDekxxd3NuaDJaM1hhQ0RJ?= =?utf-8?B?ZVN6YU42UFgrQno4MnZQUHRSN0JidU5mZ01UNXNwVklKR1JnMGZzZFpmc0Rs?= =?utf-8?B?amduYXFZaS9KQ29lNjBCb3hTbHZ4eHdhUGZDbCtMd1lURWFSZWFWb01TUE1s?= =?utf-8?B?Q1FzMXNnR2pqRzRoTFpCY3NBd2ZkbnY0Q0NvSjZhSGNZWnl6Q0E1Y2pTcUJS?= =?utf-8?B?QStPb05KZmVJa2hkTEgxM0FDYmxaTVhPZWRHODJ0RHFqQm9lUGxNRWIyVytk?= =?utf-8?B?U2NpdkVNZWQ0bkdNMEtXSWoyNXRsNi9zbGVJZkdmSnFPdE00dkdCbFJLVnlC?= =?utf-8?B?Wk5ydGtlajJNTlpvek5oczU4eFB5U0tJV1V5V3c4dlUzdDlzaXpjNlpMUW04?= =?utf-8?B?ZExjTGdNbGczWGlaWDFmeFlVemY4YTgzMHdaN2ZDYjlZa1dHd3l0TllKR0wy?= =?utf-8?B?TERwcE9HLzJjVGhFdnJOQnFsaVMxVnU3NkNKbVJjd3dkUVZBcHJneHR0Tjh1?= =?utf-8?B?a0FzSWlRMmZ1OVplSmc3bGpsMUtqTmtKYzdjck9nRmVqYWdYaGlBM20wRTNx?= =?utf-8?B?N0EzMElCRTdHMmZoQ2hjSGFvdTFjUVg4b1NtcXQwTmtUdmYyaEJDZ2xHcWJD?= =?utf-8?B?aElLWU5tNGYzN1NpUE9hMzY4YnNubVV2eHJpL0ZXR3lhT2ZldVZhblFOcXFz?= =?utf-8?B?R2VxeXcrM21oSFpvM0prZmxadERwcmk3ekFZZHZrZ3VXSmVoTkt1S0FjU0FN?= =?utf-8?B?ZWNVSHR0RkozWGJRNTBKaFJxTWs0U0pvSThkZXpQclE2cWRySzMvc0VnR3Z2?= =?utf-8?B?aHZpK1NPQmsvV1JBNTlEOTh3Q2ZqN0lJUnRoeTYzZUdkSmRLelhRV2c3aDk5?= =?utf-8?B?cWpkckh0UHRiejF3aFBzN2tiTVBxWjVYMDl2WGVXRndhRVFRZVJaV1AvaWlO?= =?utf-8?B?ODZHUlZhaGVOV01KRWxhb0FvWGpyci9lbk83czdwNkNEdDQwZmV2RnE1YWdl?= =?utf-8?B?cGpGRzhuWkZvUXdCWXh1cENCdys4YlpCWElvOEN4YzhPWEhCbmhmaGZEeU1i?= =?utf-8?B?UWwxN3B5dVRxeUxIamljRXk4bFEzbDRYQXZvbkQ1Q1U3RFZySFAyRjJwZFpp?= =?utf-8?B?eW5wV3FRMTBTanVRYnlUWmcxaUJhT1NVdDRFU3Voa1czbjhmeFBHYlpZYXE1?= =?utf-8?B?bHA0WVhBNTlkd0p1eldZU1pBNlZpVGJJMVFnOVB3UFNTdERXTnZYUW1DRUtY?= =?utf-8?B?Z1dsNW5wdFBnQnpOdXI1K1FkbjNCRWhKRTRNTFQvazB5aHE3OUZGY05PWjhn?= =?utf-8?B?ZGM0UGJUYVExYUdzRE8xTW1Ed2R6QTdnTmVDTHlsM0pycWhDdWRWeDJaRWwz?= =?utf-8?B?YjdHdCtKc1ErL0RFenk4L01EOUVGN09wTVFTOG85WXdjZWZJQys3eC9lUGx4?= =?utf-8?B?bGduV0NCeW9xeWNzclQvYzdPdk5MVHpqZFFaV3VmQWdQaTFCNUp6bFBJVzNz?= =?utf-8?B?OGJYMjh4SVNHMGxUTFNKWWl0ZW9FRWJWbnNUVVE4WjkreUpzV1NFeDFuMCtU?= =?utf-8?B?MEtiaUpIZm5UbzlWVU9BMDdSMFIzNnF6Mm9lVm5RanNlb3I2UVg3RmVEVjFk?= =?utf-8?B?SlY1T0dqNlFqbkprWUJ3VXd6Nm8rMlJlUk9lSGl5RjlsblJGWWhzVGZueHMr?= =?utf-8?B?SnkwTTNnRENYSjN2KzFvUDRNcDRBa2lJalJadjFzR1BRZ2gxbzVndHcrVVA2?= =?utf-8?B?NWJSNFphWStPbUJFSUo5RTN1NXFNRXJQMVQ3WnRKeDZmbFlMRkVqV1Y4amhL?= =?utf-8?B?eGNiZVVGOU5SVTFxOW5NSldYeUFaaWpONXlGVmxEamJuSGJIVzZCeElHYVBM?= =?utf-8?B?RUcrNG92dmVsU05YNmcyM3lna2dTMVRyR2MyZEhZbmFVZkl0dWRMRk5UUzZq?= =?utf-8?B?M1pVK2ZLdkpVeHh0TWYzQ3lQdjV3eHhSNW5pa2dBbVY1VEkveVBic042LzVL?= =?utf-8?B?RDZnVDFhK05TOHUvUjFWZFB5VU1MUUJRR2tQZ0FvVEgvNmhha2xvbFVoSFc1?= =?utf-8?B?REwvK2dsV1hFWTJIQUs0N2doZTdIdkhkcEZUbmJxU2JMYW5VSnFjZz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 305fa81b-648a-48d4-c2a4-08df247e50ba X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 14:21:45.0066 (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: YIeC/lsy/keFohGURjRHtixKk/rNJ5N1oobg23UuLub+9mo8k4G7QAaN6geVE92UFBkkM5nrjy7FSxTODvo72g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9129 X-purgate-ID: tlsNG-bad1c0/1791382911-BC4CB034-A16240B3/0/0 X-purgate-type: clean X-purgate-size: 6392 On Wed Oct 7, 2026 at 4:11 PM CEST, Orzel, Michal wrote: > > > On 07-Oct-26 15:40, Alejandro Vallejo wrote: > > On Wed Oct 7, 2026 at 2:48 PM CEST, Michal Orzel wrote: > >> We require memory to allocate for a domain as RAM to be a multiple of = a > >> page size. However, we neither document this nor sanity test. Specifyi= ng > >> memory size that does not conform to this requirement fails the domain > >> memory allocation in the non-obvious way that is difficult to parse fo= r > >> the user (printing over-allocation messages followed by the panic that= Xen > >> could not allocate the requested amount of memory). > >> > >> While there, fix indentation from tabs to spaces for "memory" paramete= r in > >> booting.txt. > >> > >> Signed-off-by: Michal Orzel > >> --- > >> docs/misc/arm/device-tree/booting.txt | 4 ++-- > >> docs/misc/xen-command-line.pandoc | 5 +++-- > >> xen/arch/arm/domain_build.c | 6 ++++++ > >> xen/common/device-tree/dom0less-build.c | 7 +++++++ > >> 4 files changed, 18 insertions(+), 4 deletions(-) > >> > >> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/dev= ice-tree/booting.txt > >> index bcb06bc796bf..7dfac2062a37 100644 > >> --- a/docs/misc/arm/device-tree/booting.txt > >> +++ b/docs/misc/arm/device-tree/booting.txt > >> @@ -155,8 +155,8 @@ with the following properties: > >> =20 > >> - memory > >> =20 > >> - A 64-bit integer specifying the amount of kilobytes of RAM to > >> - allocate to the guest. > >> + A 64-bit integer specifying the amount of kilobytes of RAM to > >> + allocate to the guest. Must be a multiple of 4KB (the page size). > >=20 > > nit: s/KB/KiB > Is it? I don't think it matters at all seeing the number of occurrences i= n the code. > > >=20 > > But page size isn't always 4KiB on all ports. PowerPC has 64KiB pages. > > IMO, 4KB shouldn't be here or elsewhere in documentation. > This is Arm doc and on Arm we only support 4KB at the moment. User should= not > need to dig into the code to check what is the page size. It's better imo= to > give this information right away and change in the future when we add sup= port > for 16 and 64KB pages on Arm. This is already the only reference the other ports have for dom0less. The document shouldn't be here since the movement of dom0less to common code, but the side effect of it is that this no longer an arm-only referenc= e. I won't be annoying about moving the doc on this patch because that's a separate matter, but not adding more easily avoidable debt seems warranted. > > >=20 > >> =20 > >> - cpus > >> =20 > >> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command= -line.pandoc > >> index ea0e3368b1d6..d49db353d8a8 100644 > >> --- a/docs/misc/xen-command-line.pandoc > >> +++ b/docs/misc/xen-command-line.pandoc > >> @@ -1020,8 +1020,9 @@ and architecture-specific domain limits. > >> > `=3D ` > >> =20 > >> Set the amount of memory for the initial domain (dom0). It must be > >> -greater than zero. This parameter is required (and only used) when th= e initial > >> -domain is not described in the Device-Tree. > >> +greater than zero and a multiple of the page size (4KB). This paramet= er is > >> +required (and only used) when the initial domain is not described in = the > >> +Device-Tree. > >=20 > > Same 4KB remark. > Still Arm only section and see my reasoning above. > > >=20 > >> =20 > >> ### dom0_mem (x86) > >> > `=3D List of ( min: | max: | )` > >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > >> index 72d531618045..bc3d1ebad1c4 100644 > >> --- a/xen/arch/arm/domain_build.c > >> +++ b/xen/arch/arm/domain_build.c > >> @@ -1881,6 +1881,12 @@ static int __init construct_dom0(struct domain = *d) > >> warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M F= OR NOW\n"); > >> dom0_mem =3D MB(512); > >> } > >> + else if ( dom0_mem % PAGE_SIZE ) > >> + { > >> + printk("%pd: specified dom0_mem (%"PRIu64"B) is not a multipl= e of a page size\n", > >> + d, dom0_mem); > >> + return -EINVAL; > >> + } > >=20 > > nit: XENLOG_WARNING? > I can use XENLOG_ERR. > > >=20 > > Also, is this is meant to be self-healing? If so the return should just= be: > >=20 > > dom0_mem =3D round_pgdown(dom0_mem); > >=20 > > and continue. And if it isn't meant to be self-healing, why not just pa= nic()? > 1. It should not be self-healing. On Arm and in DT subsystem in general w= e chose > to follow the contract to bail out on unsatisfied user requests rather th= an > silently adjusting them. > 2. I think it's always better to propagate the error to the caller if pos= sible. > Sometimes you don't know where this function end up being used in the fut= ure. In > general if the function returns non-void I tend to leave the decision (he= re > panic will be executed anyway) to the caller. Printk explains why and the= panic > follow. This also matches the existing paths nearby this code. Fair enough. > > >=20 > >> =20 > >> d->max_pages =3D dom0_mem >> PAGE_SHIFT; > >> =20 > >> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/devi= ce-tree/dom0less-build.c > >> index fcbeb8adbd73..b3f24e5d555f 100644 > >> --- a/xen/common/device-tree/dom0less-build.c > >> +++ b/xen/common/device-tree/dom0less-build.c > >> @@ -789,6 +789,13 @@ static int __init construct_domU(struct kernel_in= fo *kinfo, > >> } > >> kinfo->unassigned_mem =3D (paddr_t)mem * SZ_1K; > >> =20 > >> + if ( kinfo->unassigned_mem % PAGE_SIZE ) > >> + { > >> + printk("%pd: specified \"memory\" (%"PRIu64"KB) is not a mult= iple of a page size\n", > >=20 > > Seeing how PowerPC has 64KiB it might be prudent to print PAGE_SIZE to > > avoid surprises later. > Yes, I can print page size here. > > >=20 > > Same remark about panic() vs self-healing (either is fine. It's this > > middle ground that looks off). > >=20 > >> + d, mem); > >> + return -EINVAL; > >> + } > >> + > >> rc =3D domain_p2m_set_allocation(d, mem, node); > >> if ( rc !=3D 0 ) > >> return rc; > >=20 > > Cheers, > > Alejandro > > ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:24:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:24:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442413.1659966 (Exim 4.92) (envelope-from ) id 1xESZT-0004b3-Uc; Wed, 07 Oct 2026 14:24:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442413.1659966; Wed, 07 Oct 2026 14:24: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 1xESZT-0004aw-Rq; Wed, 07 Oct 2026 14:24:39 +0000 Received: by outflank-mailman (input) for mailman id 1442413; Wed, 07 Oct 2026 14:24:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xESZS-0004ao-3D for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:24:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESZR-008Rgk-GJ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:24:37 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac65608-2eae-0a2a0a5409dd-0a2a450ca07c-48 for ; Wed, 07 Oct 2026 16:24:37 +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 6ac65622-f479-0a2a450c0019-d155802ac0ad-3 for ; Wed, 07 Oct 2026 16:24:35 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a1698ea378so16326785e9.2 for ; Wed, 07 Oct 2026 07: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-48c71d1fec3sm5803750f8f.37.2026.10.07.07.24.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 07:24: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=1791383074; x=1791987874; 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=c+UlPByOSDDKiYU85ckUaf2MWo/G2nQzS4XpVT5HQnU=; b=aDQl/ZhNjX+rfKKhh4wgZ+7wXXk4kt97ZCIxOtVfQ7uAMAR2W30nQWXmrFhiQpz4Mv hcRiY1+DSpCkuOSxdqX18go+mvFGX0HIN3lU1vpeaXHRXt2TPWmu2ey1ntjSvn14VVgh yfTIrPGwjM7lEk5AXkjNfMEauORC5Pen4713I0ZSAVN3MdRgI/J5kGAAusAO3QBlU8Se lyT3hIbWb412zgsSbHvCOdKnbVOqoWnWk+ItycACY2BLmzkyIJf6/dvy0Vdfi01RZI4g k6S/vQQnodPoU1MNOfX+6IkrTBIqDCMlTyoNf7O/7bxQ7B51fZgoLNkPgB8aW9rCQSCa N4UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791383074; x=1791987874; 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=c+UlPByOSDDKiYU85ckUaf2MWo/G2nQzS4XpVT5HQnU=; b=A5LAHnmczh1z2cfDDnXz20xxrzhdqHKqRoFfF9uTywDlU5GTgJQKoEmngxrG+ZpdWt WZ3WvI7MhHoD2u74mIL748tkzcUrKReUYIsaxavULxgaORU6LZxZn5kWD3pGsx9CwjaP yJO+G2wpKSiEOBMiiQu0S+5cjIkgYX49RPojTAND22KwG+I7BoeIV2wsWTjHlFO2BHdN j+HX5ahqmU0Cx1JzT6xdCcxCiszp3VZwbor5ahbXII2zBlgyPrcuidjXWQGGC6+ojE1V 3ILtwPda9n1nWOsnLskNFzjCG73yiVbBrL/w0Scm5v/0rd+e6rHLbroD3YodLsJR0fmy eGTQ== X-Gm-Message-State: AFuF++kZpoEMSNUd9kd0tGFWM/xH3LXlek/SHQcyMcMuK8zk2RHDJl3K UfsAuK0Z1L9nAfkwDkDvbX5zV0abX5nnoqEieYSViAL5+xe9OOw4d8H8uNYXt8REjQ== X-Gm-Gg: AYBFou18pKZNHMDNqiuTeD2zSZ0UXiKwylf/1/qp7UujSBO1rJRc50vYePi5PiRyAGN ytWtYLhlad2T6Ox6fgLTCNYPtPqpiBGJisgEDkvL4WhRZGePsaDVqEQ4cf+vQKjGCAnFvq6L4Sc 1OJIpEJ/y7oByDAXDLb/VWqJSci+123WEEFjY/9vOYxu4zrBVkyu5F4noPgKUuob905ffkLpNbN kQn8aiLARAEh/8oS6xnWCFVEWAAb4jdsnP5Sg2TaybO3xLxYunk/p+zgO/aa+FwCR2caCB98Cn1 4P8XKcKLPg15RQTjGf94e79zaMYEM052Pkq7jyPxVBhhw7LexNtv5BTR2KTU3J54tmtVofujYvy OGLRkFr1r1bJ3ws4YgbYBnDRgajH35OGcZIuKVqT6ozqokxbV6aiCLr9MuX1PsZwj+un2OwWzo3 IXV0LTrlpx1c61NR6w8v0QkWMSpt5MDAGhfK3hJSTmFabf35CJ/bxpFJoIbDxDeDDex81Tah0J7 wZwAsEmaO23Fw2vuLojmZ9zxpZb3TvEvHtAjUQFmREhnkEPatS80KdgRnXFpg== X-Received: by 2002:a05:600c:4ecf:b0:4a1:7d08:780e with SMTP id 5b1f17b1804b1-4a1800ca15fmr40613235e9.1.1791383074420; Wed, 07 Oct 2026 07:24:34 -0700 (PDT) Message-ID: <41713068-b683-4971-af8b-1dea1bba500c@suse.com> Date: Wed, 7 Oct 2026 16:24:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 02/18] x86/mm: purge unneeded destroy_perdomain_mapping() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , George Dunlap Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-3-gwd@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1791383075-768DDA5B-7FE46A45/10/78276251493 X-purgate-type: spam X-purgate-size: 387 On 07.10.2026 16:06, Roger Pau Monné wrote: > Otherwise LGTM, but I don't think I can RB or Ack it being also the > author. You can, as per earlier discussions of the topic. George's S-o-b effectively implies an R-b on the code he's taken unchanged. Your R-b then covers the parts he has changed (and the overall result). That fulfills the 2-pairs-of- eyes requirement. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:31:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:31:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442423.1659975 (Exim 4.92) (envelope-from ) id 1xESgF-0006W0-K8; Wed, 07 Oct 2026 14:31:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442423.1659975; Wed, 07 Oct 2026 14: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 1xESgF-0006Vt-Gs; Wed, 07 Oct 2026 14:31:39 +0000 Received: by outflank-mailman (input) for mailman id 1442423; Wed, 07 Oct 2026 14:31:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESgD-0006Vn-Lb for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:31:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESgD-002dDM-1y for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:31:37 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac657c8-8faa-0a2a0a5109dd-0a2a450aaaa4-4 for ; Wed, 07 Oct 2026 16:31:36 +0200 Received: from [40.93.194.70] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac657c7-f2d2-0a2a450a0019-285dc246d53a-3 for ; Wed, 07 Oct 2026 16:31:36 +0200 Received: from PH7P220CA0055.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:32b::8) by PH7PR12MB6762.namprd12.prod.outlook.com (2603:10b6:510:1ac::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 14:31:32 +0000 Received: from CY8PEPF00000053.namprd05.prod.outlook.com (2603:10b6:510:32b:cafe::79) by PH7P220CA0055.outlook.office365.com (2603:10b6:510:32b::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 7 Oct 2026 14:31:31 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY8PEPF00000053.mail.protection.outlook.com (10.167.247.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 14:31:31 +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; Wed, 7 Oct 2026 09:31:27 -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=n1t0+88qYZe3VZa7FOl4bVUelbQbxBiY0EFsfSTuMJ5v+LWENWIQz/QteDr4nJgv+HjkMJYWC3LVnYvgcXLa6rQq4FmAYiabvAveKguS8hWlk0x2lnjxDrFQGo79T0TMBNvV9du/1411LTE0OWnikl/bv5i0VhA/lB/enC9LtKme6X6CQhOCn/Scq7agNsh0kO2yub4nv/3w7Xg27g9iIDh8BxrK3XvGQNtTM4ehQBV/Dt92y+fM/Aq1L6QGPCtZdsO5wp3ZpPk1qW5xJCraWK9GT9H4TNS2rfl1DyKg+BOiRdAKpulZwI7h3St2HnKxnH0/uwikYB57V1oHOjFXIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7N2EF5DcR5aHz1GMCf3jJBv/RTxXRgszVGoIOnJbEpA=; b=VDC1A5RJvbDO4dcacxow020YPxpsbGQeZI/5CTrUTI+JPD4pAq1n5LyCE8F3fgRFRsIXU4s6sVKGstkTuSt9AGuwa2797oqCVDoHCxJ5GlOZYezV33RPEADlEG7Y6ZdpcyZISH4r5ESZsFSHjEdMqggh0I+p0DqFl8AoGsflCZQIPV45XL8DnKBp18hzhYLGSxFhFz6yXxC4GjRtrq48Hp7wPVYtOpatYh//odClUaLLHVYuqwVMH8i6qE5rhbnmiWb0O3t46hyVemfkCwKGLZxWTj3dth720nIUmVeoW3qqRrt7ypEzovtbH5apD4/uPaBwjUFbNm6oMFZD4+TDyg== 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=7N2EF5DcR5aHz1GMCf3jJBv/RTxXRgszVGoIOnJbEpA=; b=PNGWcDaJqO15IEz6g+VVubbkSWwJ+QpPDs+pzv7h2X+aUifnB3ab1K0nz56Fk1lUqS3CcbDy/GIvk24xAm5fJZHrW/rkkUxnNCAPUUKxjEF0eRKEMel2w4Qt9lEYwMhyVL1R5KWAiAeH58+TSr5db01+1ibkXi6anq1UNke5Cb8= 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 From: Alejandro Vallejo To: CC: Alejandro Vallejo , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Alistair Francis , Connor Davis , "Oleksii Kurochko" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Timothy Pearson Subject: [PATCH v2 0/3] xen/nospec: Make nospec helpers always_inline Date: Wed, 7 Oct 2026 16:31:05 +0200 Message-ID: <20261007143117.757375-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: CY8PEPF00000053:EE_|PH7PR12MB6762:EE_ X-MS-Office365-Filtering-Correlation-Id: 7b4b7ef9-c702-46d7-7b6a-08df247fae61 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|376014|36860700016|82310400026|1800799024|56012099006|11063799006|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: e9OCCqJtb80fCB8BkOw7aZma/tl2H8/HNgVO4xFghYPVQpPIpA0lM2PjqwAaCIXGdKoYBdai/n10GWlIb/BdQgbsa0oUnJh9tvWdgH1frpEhBxOEzxXkZ4RVTlJOZUcqlRj7TdtVpOaX8r9PBSaOU9hLYp4kqVDYD5PVgVgbHv2+0cEyVFObCZ0+ueDHXVcpNTPK70fa24p9KfBKDWzyj8C+xysFk1xuYZRR9IPI5A5pTPKJwLc8YQI8PsVMZ1jdWq1KImAnWosqpdpP70M3HizGdQMB0Ijc3JNHAwyDhHJl6PC8L+CFUvaziGK+5yfwFZOISJpYDJ3ei5YxLgEm+cxu1jpw9rqkhMI1V6oY+kidhbisGYn2KWAeTpVZa5RBeeF64pY9KdpAergIwcqgEdfIgNh4EaFNE+sYLYTXws3AC8JkoRJ8EuASXFT80gO4Zjv+2mvtVoWk1u8XXrJcAQHwQxaBjBZw/whZLRpABwvLpShhAjcL8M5L2Gs6X4ZJmBFB+mf1pT80EdOu9Fy5nMBbHzf4a51GeSR6leQ1H8/1ZLdSUFQ7Ai/cacAZyks3TsOEFlLAZsNbhAcsCpkgcJcZIS2DLOVPkCNuBgGN7UoSrrierZ0Jd7hAZl7KxGPnWUl4iuytUoCPrBsDI0BnhO1RqlfKfdE0N7GhBfIX+g8= 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)(36860700016)(82310400026)(1800799024)(56012099006)(11063799006)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 8cciF6RNOTrcZI8kmP3gDJbGvrm+l9ZzdPnUWdX0Kgzt8UTjZcZ+jLsTLYjzsrpV+yZdUwgD6eM6qmJg/z2w/ybK0d15G9k2U0iJWTsy5lbUDcz45GeXK0dsnY67NGKAfUfJfjRXm8ubegj9x0Y9ZrwW9t0ja5jcenTtQpdg4iqvd6tYSWzi0mibgJDBYk7nyvLv5cVvBC2QDeOY+5w7TS0ixBnA2Cfwuro2f2KihLfb9f1zc9t5nqj2dzOq9D/m/HPq6tWzmfMs9jbjmUHQJKKEdnI28Xd399MNZJ0FczkBJpwcMmkDqoecgN0YNI1cQA4IH58RFQ4NzmaJzZm0sIZ0qYOIDiiUVIioHveWfy8+H6JgW3dBIc2/29dFsjyxbs6xmjUvrb5iqbL2OibJtJyLImgyF8A7OdDhr0ziCthPRePsu/xVz3Y3AlPZqP2/ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 14:31:31.4072 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4b7ef9-c702-46d7-7b6a-08df247fae61 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: CY8PEPF00000053.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6762 X-purgate-ID: tlsNG-4011c0/1791383496-538D5CFC-EC202137/0/0 X-purgate-type: clean X-purgate-size: 610 Hi, v1: https://lore.kernel.org/xen-devel/asT8lQktOeLhcva3@Mac.lan/T/#t What the subject line says. Split in one patch per affected arch. Cheers, Alejandro Alejandro Vallejo (3): arm/nospec: Make nospec helpers always_inline riscv/nospec: Make nospec helpers always_inline ppc/nospec: Make nospec helpers always_inline xen/arch/arm/include/asm/nospec.h | 4 ++-- xen/arch/ppc/include/asm/nospec.h | 4 ++-- xen/arch/riscv/include/asm/nospec.h | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) base-commit: 63d0e8cc842975e786455f8a2e6502e85685f258 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:31:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:31:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442424.1659984 (Exim 4.92) (envelope-from ) id 1xESgH-0006j7-Sp; Wed, 07 Oct 2026 14:31:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442424.1659984; Wed, 07 Oct 2026 14:31: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 1xESgH-0006j0-Pr; Wed, 07 Oct 2026 14:31:41 +0000 Received: by outflank-mailman (input) for mailman id 1442424; Wed, 07 Oct 2026 14:31:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESgG-0006dS-9H for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:31:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESgF-00CsYD-MI for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:31:39 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac657be-e002-0a2a0a5209dd-0a2a450c8f70-26 for ; Wed, 07 Oct 2026 16:31:39 +0200 Received: from [52.101.53.64] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac657ca-f479-0a2a450c0019-34653540e761-3 for ; Wed, 07 Oct 2026 16:31:39 +0200 Received: from CY5PR18CA0008.namprd18.prod.outlook.com (2603:10b6:930:5::11) by SA1PR12MB7222.namprd12.prod.outlook.com (2603:10b6:806:2bf::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.16; Wed, 7 Oct 2026 14:31:33 +0000 Received: from CY8PEPF00000055.namprd05.prod.outlook.com (2603:10b6:930:5:cafe::79) by CY5PR18CA0008.outlook.office365.com (2603:10b6:930:5::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 7 Oct 2026 14:31:32 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY8PEPF00000055.mail.protection.outlook.com (10.167.247.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 14:31:32 +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; Wed, 7 Oct 2026 09:31: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=nAt+MNgc0MzGi87zXm9MoD/GFu7cGp1edZXzixLmZeBejxcHKFfVT9oD0PRRRdk5FOR5UvoRzCN8ht1B3Z+4CYPjlbhOhK7aVE1AczLl3mZXmT+K8qKwRbF1BunqkY24UcvtYKcKGmOFskwuw94szvVmqbBA6zzWpadlEgM+jxjakLJO5e1hWwu7ctuFGe8W9CEq/D8niAaQAHFoAfmMCWT8HjFjAd6MIOx5lnfMyM+Rv7Dvsy1z3Jp6s+YDuOZZSXFX2PDmK0Cd5O59FynC2RuMLuIA54sexEtvG3gVk8ETuh20RHMLeHg3JWgUx2+PKlbdLkZuClg+SSbNDAIYAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=e1k3d/RJ0g6r3Fac+Mwo9TkBEpOBTeJbujfVfJAO7g0=; b=SUjq8F5Fuk/9IN6RjwrjeFRILLy0Tou26j6y1ogGokdigdtcHKsYBAdKK/w7G72MaBXCPyfJxOrPb8PEJXEqgb+QhXs94UlhETA0xaHfAJZ3a48OsV5UeuUNNm0i6LOIt7RmmlNGhrEgeA+3xRRCvPa1rCy5HJZ12igeM8uMlVl8pG5oiHyfSeubAzLzXOaZUGzl4L9MqPk3ZYdoo2+5v8zFneSsmB5vLrvJhiU86Z0+VYvo8wt6T3HrH1SOKlMWCtwWq+7WKZiINH54U67E51JOM4uj5TFr2hdHngboIi+fHJ9Pv8yzOSWSFz5I0qjZWlx2eXh10k/zIGfXFVpiHQ== 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=e1k3d/RJ0g6r3Fac+Mwo9TkBEpOBTeJbujfVfJAO7g0=; b=Fn6+oWaDiqRRzNq4nMWr0cbD49NmYzBQuZ7xZqy93D8jNPCyWY4vInFJa/tACU2H+GcuPtaMATbt1R4IfjvZgEyr9cZ85At6CM1IoxpsFZ7l0C1ENEJDJwiNVtdb6eTc0HWKIzHDjaojV+H0fhiSTVLurjo0oHGvDVT/wztbybA= 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 From: Alejandro Vallejo To: CC: Alejandro Vallejo , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [PATCH v2 1/3] arm/nospec: Make nospec helpers always_inline Date: Wed, 7 Oct 2026 16:31:06 +0200 Message-ID: <20261007143117.757375-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261007143117.757375-1-alejandro.garciavallejo@amd.com> References: <20261007143117.757375-1-alejandro.garciavallejo@amd.com> 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: CY8PEPF00000055:EE_|SA1PR12MB7222:EE_ X-MS-Office365-Filtering-Correlation-Id: 833effc0-e0ae-44ab-9a62-08df247faf44 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|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: QGlXbn4Fplj1jU+TP0IoPKn1HgfavMWr4DTMZenEmjop+HMHEjwC8PlsD5bkGMxHlLFiM8GEuLKCLb9VAGuSN+HmlUCxs7PiUg40WBtC4I0K9rMT52fRRROpZ1J4BeU74begvUzi531hCWKAwnmsSl9DwJS38usEisFz4HB8etuWbavVTD0z55u7XO7dSVquzBtxo3AQDgQvZBiWqJw3ZV5tAra0mU2ov/jbeUz0O4WbOqdokvkQPcIuDhJj8Ua9bYQFj6EgpL23F3TpyKCowdJLxzw3/5ZPnGP8tvIOfHBKS6E2F4zRARwn5y6TkYeukNQWRhJLHllpT65eo7mK+Do7ewlOi7GLCuJ3sIHLd5n7FBY0QAWd3eUMRZnYPXFLU0bOpwq3kfXKzM2OhUZ1sexlHkKoIKVKw9vL84+vhfAj3SwyzpWy0FU2WTCrWKAPPSANCRlSKJ9hYqYfjQDmGmCI3rvfnk+FGVuUyix1Jm4bYg03O6uYcDMEa5Qo7qWV1UD1C3cmWavxE5ed8Y0GOdcjcTGwkFxsjFry5hTqz8Fu8Agi/hQ/l3ARn3Tb7KqaF/eL+f6B1/m8NGHVa3FIG3NesYJ6S9/wSb2tQU92APEwUj2cv8MNGdTy9ePO8R3+0viQWY9JUPqnuNEe00U1Z+xBmYXsSgh88kzTFPeqm4LASFQUWqZRoNB/3PlGx8R8GZ32iWtllAdTKYpiHLj1uQ== 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)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: JRt3OLKHyUeEKvE7Ve4m/AexKm54Nlhw1SKfX1/VvGLANw4wuAWnbabMllpYBCCYu23ANQ1r8fIdeItj5uhKejof1odY1USjf5gBSZLwaREeD6blk7gYyDrcXFjnUPS/LaLsDP/NUKCYob4Nb9CG1DF8EI4V8hByMnwYp3u/LFtcK2Gp8pW72tKWfjHUeWKaNtK9gAg3ygxDdQABmMurlWbxHQiez4Jv7Mi5WQcztg/h2ZXrsbhgKNJt8Mhkv9N4LgtPUyjHWPFEMnM1iR6jPSBi9eR1nAekUiRSMNJL/Os++ajUTOJ7MZol3HELiwhXMcAIrP+tzfXuF63qQFcNsQHl+AUZqr38NewRHVDdUBr61rPu1QntJpA8uaFcQ8RJ1L/Gp4g35jjl114UMCx++D5SBzlK/8xht88VCXV2Y+yhBL5bNsUDmyPyrx84pTL1 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 14:31:32.9216 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 833effc0-e0ae-44ab-9a62-08df247faf44 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: CY8PEPF00000055.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7222 X-purgate-ID: tlsNG-d25034/1791383499-00ACCA5B-6990F1D7/0/0 X-purgate-type: clean X-purgate-size: 998 While today they don't implement fencing in a way that would block speculation, once/if they do they'll absolutely need to be inlined, even if -fno-inline is passed. Signed-off-by: Alejandro Vallejo Reviewed-by: Michal Orzel --- v2: * Removed -fno-early-inlining from the commit message. --- xen/arch/arm/include/asm/nospec.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/include/asm/nospec.h b/xen/arch/arm/include/asm/nospec.h index 9c70eed605..ef0d8ddd01 100644 --- a/xen/arch/arm/include/asm/nospec.h +++ b/xen/arch/arm/include/asm/nospec.h @@ -12,12 +12,12 @@ # error "unknown ARM variant" #endif -static inline bool evaluate_nospec(bool condition) +static always_inline bool evaluate_nospec(bool condition) { return condition; } -static inline void block_speculation(void) +static always_inline void block_speculation(void) { } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:31:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:31:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442426.1659993 (Exim 4.92) (envelope-from ) id 1xESgS-00073c-5w; Wed, 07 Oct 2026 14:31:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442426.1659993; Wed, 07 Oct 2026 14:31: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 1xESgS-00073V-1X; Wed, 07 Oct 2026 14:31:52 +0000 Received: by outflank-mailman (input) for mailman id 1442426; Wed, 07 Oct 2026 14:31:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESgQ-000729-QJ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:31:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESgQ-008Syv-6P for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:31:50 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac657ce-2eae-0a2a0a5409dd-0a2a450ae994-32 for ; Wed, 07 Oct 2026 16:31:49 +0200 Received: from [40.107.208.67] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac657d1-f2d2-0a2a450a0019-286bd0433a16-3 for ; Wed, 07 Oct 2026 16:31:47 +0200 Received: from CYXPR02CA0002.namprd02.prod.outlook.com (2603:10b6:930:cf::28) by MN0PR12MB5931.namprd12.prod.outlook.com (2603:10b6:208:37e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 14:31:40 +0000 Received: from SN1PEPF00036F3D.namprd05.prod.outlook.com (2603:10b6:930:cf:cafe::73) by CYXPR02CA0002.outlook.office365.com (2603:10b6:930:cf::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 7 Oct 2026 14:31:40 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF00036F3D.mail.protection.outlook.com (10.167.248.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 14:31:39 +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; Wed, 7 Oct 2026 09:31:36 -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=qGxiXy1dm6MTSOr8cEKVgLHlSS+mds6tB+3uinOZkpBZcX9wUZySelX3DNyZzDd0L5LXW1ZZeIi4es9Un0TKXiJD9eaOrbpbv8bm/Up8+nQWK1Xj54Tk63uws/cHK7utYtlwVKkOKylEBrPPp8WvgqJRempPJAefksMQcqTQv4MW2ujN7R/HrQho/Bxjw1pAqTWOQW244X525Y9vvXPv+w1BQeSggccu8vsxsOCYt5wQOu4e16C/MfxGRu3YgZz+/ksqrHIm1gdLiU8Qyn07L7ToDQ6wPalNGR4Xgwd+UrKLSV0M8hjva4FLzmrI4/w1v1hqkF/oDnLBLgoI8g4D8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pKkCPFa4pzpfzKbbz3YgL7Xlp/A9xi/G2NwMw10eKJ4=; b=pYGQVmAeeBakdHn2yPFk/jNWDJVG0r96cFv3nPArjZz9417SIfnL27NcZcjsg1dHopfee2nkD6eCLkTvJYGqJOhbncV/rXkmrn4AJq6AFPfqiACGVq0k5xNhAUweV+eRysrUAxmN+FqWmv+NkK15WOqmUtgFc+OulesrmsqZQeizMlehfmW4TpJjBF0w85sX9KM5PCvSdiQiO2xnSUmP/4tJ5j+QBg4jw4Ob7AUyEZH8BZQi7tfzvd0XopgxAZiCj9/+aVpOuZK3dn+wyCMeIR9WfbcxlrwZdiQc3xeuh+2dTcpkFrzRUxqegM/lOxnw4ej46Yv3OJd4XqTS1lkNLQ== 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=pKkCPFa4pzpfzKbbz3YgL7Xlp/A9xi/G2NwMw10eKJ4=; b=Af5UJ4/lTZYARCjTPcCzpeQGcjBIZIravSgpZBTOD/4a1n2J+PRkxrxTlXqnP7S2Z/tfGJU2OD9/1q6Yq/CqNugirQKXElAbqlZFc97jTOehcCptolGIXcr0HMQ8fd+R7EgvUXPj9XQbk7gFeaTNg7uUmOYij6mH1Xbe8zBDep4= 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 From: Alejandro Vallejo To: CC: Alejandro Vallejo , Timothy Pearson , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 3/3] ppc/nospec: Make nospec helpers always_inline Date: Wed, 7 Oct 2026 16:31:08 +0200 Message-ID: <20261007143117.757375-4-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261007143117.757375-1-alejandro.garciavallejo@amd.com> References: <20261007143117.757375-1-alejandro.garciavallejo@amd.com> 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: SN1PEPF00036F3D:EE_|MN0PR12MB5931:EE_ X-MS-Office365-Filtering-Correlation-Id: dba2cd52-5ef7-40e6-6fe4-08df247fb342 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|376014|82310400026|23010399003|11063799006|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: HA2TXq1CorMIYHJdFkgqCFzPy9ynOyUM2RpodXi59GyWHW2sWwTxh3UpcE5z8laNQ6tBV10dmr60AmKIPCX2xNCMhdyo0a5t8HyCrT/gb2yy++BfnYUiA+drABmmBJhLM1+xQBz6dUhchVSYmkq6mtFNwDIW90j9QJubB97t+BfUVLX+HInl1dAWe//tDf6CVl8Awv0k/tuY5+mCjlCaFetc1vFxTZ2MSEdOyHdSksAvc54rJJEtiZ9K6shZUIHxyGvWaMDPUtmpOid4Oqgu1YRmHxssl9g01Pp8O/7OntHzc+hqPTatiPoaeP0yaBLNBI7ty8YFWHw4WymGnoMjWcMyDwvSIKzaGqbAnbCUS9Ge6bl5q8KokAR/aPL8XBTuFgL389tbZfCbTv1Sbf20SkUX/ahM0CmjRGCi06J58R3qYPTIjmN3o9qxblEvjclBB0aahSNTpmrTmouEg6xAETfd7N396lWA+a6q0RjXWzeFgjjS2MiwWbMdP9JuwYB5rasyOHIZ0sLVi9RBlpOP8A2XECBmfXl8Z0/OLIc8yLgcCP5FJQsQa28ppyP1P+EHC/JD1HmjbRg1XvOW/D4pYSLyF0byMsAUMEOT9ObetXlMt2SWeSqcri6t5OYO8O3wS0M1gTuWVLqqBpOsTgbVC+QAA7YtSQJr33wLuolYZhky9bvVqI+KPvDDgitXan7f0wnioWSeGqqEscXhIHjupA== 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)(82310400026)(23010399003)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: lKu+WthuaU5ZdXk9V8/a5JxlRIAUZWAj35dOe5iBj2mhEEvdnn+cRI8qpZ8MLOTKe8VC14/Pd7dz/iN4tFjYya/r8fMOS21K39Be2x9rESTLdiEfCku5gm/fLGoLITYpxVY6KFEnddtf5sJQR1Dug+lV4nbmKfH6fI4daI+OckFDNJT/04QrDq3SgoHo6bmwwDQlc0fw0oFF79Lpaeh8ovfLc7Rd2WchpGMbFSSXEvoyObB6N3OKvNHkTU6H17r5FXx5GuNQvN7pERiSgzkuwPv3AMy3uQ0i/RGGhOS6i/3bsmHb5m0chd9iBP4hMeaX4EoAZ5qLDgohRx8uNMAGdywxFJ9uK02c2U7/rseUfkIi9u3co94fScXsYZh2MDsrmvhd2f8T+Rg2w3SBBWHr/3eModafJWKnTSHHE6aJziOjXPE/se4F1pAsiBR/d1PP X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 14:31:39.6430 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dba2cd52-5ef7-40e6-6fe4-08df247fb342 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: SN1PEPF00036F3D.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5931 X-purgate-ID: tlsNG-4011c0/1791383509-5ABD8CFC-170FAD37/0/0 X-purgate-type: clean X-purgate-size: 899 While today they don't implement fencing in a way that would block speculation, once/if they do they'll absolutely need to be inlined, even if -fno-inline is passed. Signed-off-by: Alejandro Vallejo --- xen/arch/ppc/include/asm/nospec.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/ppc/include/asm/nospec.h b/xen/arch/ppc/include/asm/nospec.h index b97322e48d..647800b123 100644 --- a/xen/arch/ppc/include/asm/nospec.h +++ b/xen/arch/ppc/include/asm/nospec.h @@ -3,12 +3,12 @@ #ifndef __ASM_PPC_NOSPEC_H__ #define __ASM_PPC_NOSPEC_H__ -static inline bool evaluate_nospec(bool condition) +static always_inline bool evaluate_nospec(bool condition) { return condition; } -static inline void block_speculation(void) +static always_inline void block_speculation(void) { } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:32:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:32:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442427.1660003 (Exim 4.92) (envelope-from ) id 1xESga-0007OG-FI; Wed, 07 Oct 2026 14:32:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442427.1660003; Wed, 07 Oct 2026 14: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 1xESga-0007Nj-9J; Wed, 07 Oct 2026 14:32:00 +0000 Received: by outflank-mailman (input) for mailman id 1442427; Wed, 07 Oct 2026 14:31:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESgY-0007Lj-KZ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:31:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESgY-008T22-0l for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:31:58 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac657d5-2eae-0a2a0a5409dd-0a2a450b93f2-20 for ; Wed, 07 Oct 2026 16:31:57 +0200 Received: from [52.101.52.59] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac657d8-b7e8-0a2a450b0019-3465343b5bab-3 for ; Wed, 07 Oct 2026 16:31:53 +0200 Received: from CYZPR17CA0008.namprd17.prod.outlook.com (2603:10b6:930:8c::17) by CH3PR12MB8727.namprd12.prod.outlook.com (2603:10b6:610:173::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.16; Wed, 7 Oct 2026 14:31:39 +0000 Received: from CY8PEPF00000052.namprd05.prod.outlook.com (2603:10b6:930:8c:cafe::6e) by CYZPR17CA0008.outlook.office365.com (2603:10b6:930:8c::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.21 via Frontend Transport; Wed, 7 Oct 2026 14:31:38 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY8PEPF00000052.mail.protection.outlook.com (10.167.247.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 14:31:38 +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; Wed, 7 Oct 2026 09:31:32 -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=OzHWDshsU1OkUEIpjeqoO493UorzG7w+6vX6oeQv35BSr0LT/M06rQCHiqtlF51q3hiDOumOpYGicA9i8+pgcwGt+GQdtsqBVGB0Bx12WUESQAvIpkzOAcxrfxo/fW59KOdfFv7Nvo4oIsFqWNLvjDvEQto+E2hhFpnhbMHDuMoIOyaPMwSfgnrml5yv4qyJc0uAZJAgEsqtQmdlPLQV/kKXzGMsHR45h8lnS/N3vXiXYTbp1Oi9MV0a1VK1Ohtj1WAvid5EN/VadUDH8q7JkwVHDU2aMKLbvkDrjkQcKTOMY7NucNgiKOdKsuwGCb+7KfveAim6Kwx2/CD5y0yv0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QpzggtEvc89d4Zq2S3JWjnl+sYf63o/UJpx7GfD7Wis=; b=PUOP9ch/+RLDxy39iRBbzHpwwBRrlxWga3fr4oGGt8uUWFBsIyqnJ+yfvwq7galIYNHrddW74TlRUrBiesyQX2a18niiXXYbijdlipjynLRVnsgkyledYymS5M7cgYkhL849jjnnBuRCXZPH8aiu9iM5kTUwx3GokI+Ly3hK0HaojQQ58RsPus4WOPZv/Ec4CkC4pDGegVeiHPXnDJNwYayrCQfiFbRujQ6mjz0XbMOzqA1HL6ynv14tNa2LOeddzrWHpWmCCves+I/gVERTKwtySJlPPQ6jq3CZVABnAc4MZxakvkeAbA9i1HWFAtPgTwlGzfmD9IUqyhgFMXJQbA== 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=QpzggtEvc89d4Zq2S3JWjnl+sYf63o/UJpx7GfD7Wis=; b=XlJa5yRzFI/B3M8aMfWbRhMtQFAb/77p2Md0bVRCDNLiTiLQLrtIZRaWOLNRHBXL7x27QkXRRjstfrCNqFLKeV151Hd0hizhURor50lCm9L9BsNFRTOStP/8AhdXmoW2oCGk5mJeu7w3+UUZGLlXYOJolibhOailtyu3MFDTDEA= 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 From: Alejandro Vallejo To: CC: Alejandro Vallejo , Alistair Francis , Connor Davis , "Oleksii Kurochko" , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 2/3] riscv/nospec: Make nospec helpers always_inline Date: Wed, 7 Oct 2026 16:31:07 +0200 Message-ID: <20261007143117.757375-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261007143117.757375-1-alejandro.garciavallejo@amd.com> References: <20261007143117.757375-1-alejandro.garciavallejo@amd.com> 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: CY8PEPF00000052:EE_|CH3PR12MB8727:EE_ X-MS-Office365-Filtering-Correlation-Id: c1b0f4cd-4c82-4746-d6fa-08df247fb27f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|82310400026|7416014|376014|1800799024|56012099006|11063799006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: /1nG6vc+gn4c90w/qER0vce4HbnjqwW772jbfW7FeP6MYhjfNpweOtj8tatOGAiNVhOS3tU51Lc+vh2sEI+g+9q81Az10mZSlLR50WyCVVSGDyZGwAEBRmyOQDELONJk4BpJGp4GiVpzNf66G3GDYANbMwS2h7AaQmw3AWhr1tHXGFx7N8jHA9tGgoYMoJqBEF2e2+e0hHtFrJPAAngZjAQw9Pu+Ux6gOoNcOrc+Z9LJzp304O5+InpafKev87aQFp20rm4Os3TleljdGC07IPRNkMhxEgDrJRWrlMMfhOyC+k9NHEVGVQSUWe37pkjc8jYxG9VwBHBUHFlZoysVOmJoevKUjsqBjo8sktFE0X5mpSzAV8d64LTuUctIIicLNBK7CyhwuGsvQXzziqwjw4ikjDii83lMI7AUyhZ5Qr3tEU2O97hhdugq658VRd7ncWrVmwXEoGbCeEp2KdILQDTJ1yizXEZlRgfAWZ81vWvQLLCk2GrIlZwgseEubBHcteR/fAJJd0PgUAcC2iTOz5g8n9cPlPJDxv7sZM3pqmZr3gwJnTPm1GiymkvGEB89iu/ExU2hbdsEZ/UNZRp11iBq9d5y01RxKKJ4z32IqZJbRxEWVzugT/tQFJVklQV3Thvbs6BEYEHfK6OnkbWhvxJpXJyLiydIRpB07obrhgPPiUbp4yUyE8t55GGAL1AJN40Qz54xzqlIIyqDTq64Ag== 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)(36860700016)(82310400026)(7416014)(376014)(1800799024)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 55CvLi0yJjTL2PgJ9iHJ+ZuJ2t9JuevTDqrkIs5+x31JeLt08+2YYE8eUVbNuNVefOE1oIEigGWjOfNwKxeNOC1G1ios71gJSdrCH26kjv8fPxJisLICNZn2gYr6dpolnTPm8968nc2INgZGd1DxfVa4p67VQGznPSUctRA7tlRfozueW017PvbAwwR8r51U2V10yqXnMQ/jXFoLTO7siyVo0ulxO4SCyvN7KDkYriXzQnVoYW+9C8zRaNNXMXGdyWG5qkxf1WAKqPebjQneTirV67JIdU3MmlkatsW6drY+K6d/TbCUu/EZ0r/zDUdMV7zebmZM/tmVPlSJNxCdTQzJX/gf/dKMTHOyexDUsnBvH01fjkrqcOC6oZp/9bUNSoHFoFHz8E+JBIUk+04dPd6sf3k7KDYPo733a9xx+mJ8NMIY63dtSuqrCuC21VM2 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 14:31:38.3174 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c1b0f4cd-4c82-4746-d6fa-08df247fb27f 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: CY8PEPF00000052.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8727 X-purgate-ID: tlsNG-42698a/1791383513-A86CA9EA-BA593B66/0/0 X-purgate-type: clean X-purgate-size: 909 While today they don't implement fencing in a way that would block speculation, once/if they do they'll absolutely need to be inlined, even if -fno-inline is passed. Signed-off-by: Alejandro Vallejo --- xen/arch/riscv/include/asm/nospec.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/include/asm/nospec.h b/xen/arch/riscv/include/asm/nospec.h index f9b0241c98..f9bba8b2bb 100644 --- a/xen/arch/riscv/include/asm/nospec.h +++ b/xen/arch/riscv/include/asm/nospec.h @@ -4,12 +4,12 @@ #ifndef ASM__RISCV__NOSPEC_H #define ASM__RISCV__NOSPEC_H -static inline bool evaluate_nospec(bool condition) +static always_inline bool evaluate_nospec(bool condition) { return condition; } -static inline void block_speculation(void) +static always_inline void block_speculation(void) { } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 14:34:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 14:34:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442442.1660012 (Exim 4.92) (envelope-from ) id 1xESiq-00007X-Oz; Wed, 07 Oct 2026 14:34:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442442.1660012; Wed, 07 Oct 2026 14:34: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 1xESiq-00007Q-Kk; Wed, 07 Oct 2026 14:34:20 +0000 Received: by outflank-mailman (input) for mailman id 1442442; Wed, 07 Oct 2026 14:34:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xESip-00007H-Hl for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 14:34:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xESio-009cPk-NC for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:34:18 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac65867-8faa-0a2a0a5109dd-0a2a4502a79c-18 for ; Wed, 07 Oct 2026 16:34:17 +0200 Received: from [52.101.62.41] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac65868-6ca4-0a2a45020019-34653e29e1cb-3 for ; Wed, 07 Oct 2026 16:34:17 +0200 Received: from CY5PR18CA0009.namprd18.prod.outlook.com (2603:10b6:930:5::24) by BN7PPF28614436A.namprd12.prod.outlook.com (2603:10b6:40f:fc02::6c9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 14:31:16 +0000 Received: from CY8PEPF00000055.namprd05.prod.outlook.com (2603:10b6:930:5:cafe::17) by CY5PR18CA0009.outlook.office365.com (2603:10b6:930:5::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Wed, 7 Oct 2026 14:31:16 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY8PEPF00000055.mail.protection.outlook.com (10.167.247.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Wed, 7 Oct 2026 14:31:16 +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; Wed, 7 Oct 2026 09:31:15 -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; Wed, 7 Oct 2026 09:31: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=nGWXs07FFdjc6jE/ct6UTMsb+DkpMU9K7SEfaxxzvYIxOE4PRWUIKxBQkpPYbWFRDQo29E2nwcUxramWGTN1HQfiw60eb5IbizHX6z6i5XgLRatsE+M+euaHX3TS3IDcgrRytbR8AOdaXDTJO+YqD6/rbcZfFDE6mFlByek7e3tn2S8GE9znOXTb5lqubTQ96mYiMj7/cp6Z3/JpfZPipRwHVa8Yn1abyffws42rCxj9u7HdGq+iVI1r31Pau1cGH8Gf6+XNUsXHnzUGzCwnOi6aw25CZonMNcr7a0p8WmwEYoAxc5+DuPH2lS+XyQE80OpXD2hTnj7CnG03QNnpDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LMvEvt3PmEvvo8Z2rYykP2WCm+Odx1Ex0pKl+fqumhU=; b=KLVrMzlzHnznzLdpNV5YDUXxf89I4itIaeLXiUwkJL0nkfEIPzS2CuYmn+hKxb/AqzoECw99qFFmI3cRfrojokvWLIRJ1+3kQw+w0PlGJdFzM9esHVv8tK6q2W6LNibdc1COSpPK8GabuhNecmuXLrZcO/jiykZSCLkZ/EOhK5pJ4xmkbJlVHGF+LGVKb9lblqNztrKATQwy0xkWtpQmsOC+4E7HL/Cpj/49YchtbGqzHhfqbprLnrJKa6bEnN3g9tHE+629xkrZ1/FkzUNM3x1zZaYX8uCxuYk5yz8PGMv+cbswaJyNg6AYKUs1ZXDref/gTke93ZJYYxSFKZL5Zw== 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=LMvEvt3PmEvvo8Z2rYykP2WCm+Odx1Ex0pKl+fqumhU=; b=c5ZZzJHVC5rKHCKNgl0SuHEidizFCnXw7SPpWE6NSnQv9+JT7YUhPxklVlVwHgdZZDZmxpvAZ04YWDezTZ1JLmEMT8mmDs2ADWkMGDZCHPDOHj6SVtj3QGTucmofpwEw+qvjgvFlQYgcHfBCKiMKHt8d+gzqDadN3PwiODqf184= 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: <9600e1ea-d85c-4c59-abf9-bb90b1e8cd72@amd.com> Date: Wed, 7 Oct 2026 16:31:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size To: Alejandro Vallejo , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261007124813.177940-1-michal.orzel@amd.com> <45cb2679-c79e-4d67-abaf-a4fe8e5ddc51@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: CY8PEPF00000055:EE_|BN7PPF28614436A:EE_ X-MS-Office365-Filtering-Correlation-Id: fab24775-6379-4367-0d99-08df247fa53e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|376014|82310400026|1800799024|56012099006|11063799006|4143699003|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: mSnjQd8XW1Z/O1raCckqQwt5cIXM0RyuAnNoykiEz09KeaIhJP59nVV/O3VBkVaaiyCcszSr1JLGN7p/M8oL1TZK2zNFLRmkBS92i1pmYlo+kRPXmg9ErMyF0PLLhYs84qLehqB2rf5kE3VCTlVHP/QfWsNazqPBG/w6g/rdZzJ9Ll3rX/PfVa5gI5bTXpuOIGK6dhf5ge2xC/hkMzzTrYHy1sYvgNpIBtw+yASvofFTyKePrMbJIAoWRQG/SsZtBQ77D/fsMfPif+sSVWNUP4Wmd1EN6Y+pcEjhxvX0psLlJPn21osw2ZZjtco78VEk/MUzaXJO0IrrAGGLBbGK+oseBgulrpZrpDRAz+wB/rZnHoc7VS7dGpo+ykw2BTJWeagi8vBKUCNNEOOqHqhNBKS+zVQY1WUZObwWdWEHU4xCe4w1ustLtAlkIi6hx8uqANrm6Ch2I/xOSeWWWCsTmWl3OepEfEh0oAZ0h2ZCHua8bghwxq+Pw/3S/WUs2A5RDxTQuhhCjalNwsqMerLy4Ovs8sG6bX4gPFyaBo2cOtjmlYzZg29zubazeKZHtRRUx9pl0GzWQqNKIOZ8MdAlKdUK4KQlGebaDM0YxhyDRH6hwHhsUAqcbk20pSunEi361dO7N3L+7DH7vpDanbCOvCH3qVPfDr9oDfMqA5U9Qoah/0/6vZPcx1Rmi5esYvMFq02JG1o7BOVbFixAWopkxw== 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)(376014)(82310400026)(1800799024)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: COPot5bHIyiHHeATst8isjFwwx3okB2QHc4X+nBnNDMpBDxOvGZsYyiN/TPq12LheFGKTCXckvy/yQkXiBeVZcFGfXYY+cP2ZxEyLV0kSEGxUrcMtJFtG/B8nlPwn2OlFr+v1D4vv+hQZHa4T8+/l+Ls2mocF1sOm/elbUDJSrB8oqP2Xc+sLjYDXSvEVl/QTyvYV9AowEWcLZObHbKY7ogg5CjYFYteigljQ/vdomdMoptvZu/RaXKtRrB/T3bw1WflpAzXA9ZQKsBZDlt0CEzjuQwnVEgTXcCskm2NNmGmUes5ZVRF68Gxm5Ao8cLfkkxqhdYBaJHKnya7oCZfV1fPy1rx+/MTjcfX+zriCRgHwoxqPlcCcFJRGy97mqGw9bLFAse4AE6vp5408CGC3hZjKcUbGDIqVjKD5bAbczNpdtgngw72BoGl8e6vpGPe X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 14:31:16.0794 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fab24775-6379-4367-0d99-08df247fa53e 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: CY8PEPF00000055.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF28614436A X-purgate-ID: tlsNG-720697/1791383657-F02992AC-0AFF0A73/0/0 X-purgate-type: clean X-purgate-size: 3072 On 07-Oct-26 16:21, Alejandro Vallejo wrote: > On Wed Oct 7, 2026 at 4:11 PM CEST, Orzel, Michal wrote: >> >> >> On 07-Oct-26 15:40, Alejandro Vallejo wrote: >>> On Wed Oct 7, 2026 at 2:48 PM CEST, Michal Orzel wrote: >>>> We require memory to allocate for a domain as RAM to be a multiple of a >>>> page size. However, we neither document this nor sanity test. Specifying >>>> memory size that does not conform to this requirement fails the domain >>>> memory allocation in the non-obvious way that is difficult to parse for >>>> the user (printing over-allocation messages followed by the panic that Xen >>>> could not allocate the requested amount of memory). >>>> >>>> While there, fix indentation from tabs to spaces for "memory" parameter in >>>> booting.txt. >>>> >>>> Signed-off-by: Michal Orzel >>>> --- >>>> docs/misc/arm/device-tree/booting.txt | 4 ++-- >>>> docs/misc/xen-command-line.pandoc | 5 +++-- >>>> xen/arch/arm/domain_build.c | 6 ++++++ >>>> xen/common/device-tree/dom0less-build.c | 7 +++++++ >>>> 4 files changed, 18 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt >>>> index bcb06bc796bf..7dfac2062a37 100644 >>>> --- a/docs/misc/arm/device-tree/booting.txt >>>> +++ b/docs/misc/arm/device-tree/booting.txt >>>> @@ -155,8 +155,8 @@ with the following properties: >>>> >>>> - memory >>>> >>>> - A 64-bit integer specifying the amount of kilobytes of RAM to >>>> - allocate to the guest. >>>> + A 64-bit integer specifying the amount of kilobytes of RAM to >>>> + allocate to the guest. Must be a multiple of 4KB (the page size). >>> >>> nit: s/KB/KiB >> Is it? I don't think it matters at all seeing the number of occurrences in the code. >> >>> >>> But page size isn't always 4KiB on all ports. PowerPC has 64KiB pages. >>> IMO, 4KB shouldn't be here or elsewhere in documentation. >> This is Arm doc and on Arm we only support 4KB at the moment. User should not >> need to dig into the code to check what is the page size. It's better imo to >> give this information right away and change in the future when we add support >> for 16 and 64KB pages on Arm. > > This is already the only reference the other ports have for dom0less. > The document shouldn't be here since the movement of dom0less to common > code, but the side effect of it is that this no longer an arm-only reference. > > I won't be annoying about moving the doc on this patch because that's a > separate matter, but not adding more easily avoidable debt seems > warranted. I don't quite understand your reasoning. If you worry about dom0less != Arm, then on that basis HAS_DOM0LESS is selected only for Arm and RISCV where PAGE_SIZE is 4KB. I don't think I'm introducing any doubt here. I can remove the 4KB mentioning from the docs if you really insist but at least for me it's clearer for the user to know right away what's the requirement for the size. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:20:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:20:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442469.1660021 (Exim 4.92) (envelope-from ) id 1xETRd-0007mk-5X; Wed, 07 Oct 2026 15:20:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442469.1660021; Wed, 07 Oct 2026 15: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 1xETRd-0007md-14; Wed, 07 Oct 2026 15:20:37 +0000 Received: by outflank-mailman (input) for mailman id 1442469; Wed, 07 Oct 2026 15:20:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xETRc-0007mX-GT for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:20:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xETRc-001gVi-0f for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:20:36 +0000 Received: from mail-lf1-f49.google.com ([209.85.167.49]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xETRc-0037XS-0S for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:20:36 +0000 Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5bad794b197so2029993e87.1 for ; Wed, 07 Oct 2026 08:20: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" 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=XgnzklmhT8bnP8wqwUCcRSgDGw8gGQNowfphipKGoTQ=; b=tsgYWdTRYYCpuNYzX76783GyDW 8g1dilqpLzhHqTQzNnzpJVwKCA+ehmzGYuCDQeURKymr/W0w6dgWsBr9G15Z0KZNWcgGyR86kT7aP ZhAcdYtxGxcy+HE9GznrXDb1KFFiBCYlivbPvqwxq4D7zM285R+JpejNPOXmGTG+TZlo=; X-Gm-Message-State: AFq9FYLx8/lhvlve8sd030SSvY1La84LbUCy4IyvWssZrGIDilzJQvcb ZwdTgA2ts07kaDTxYy+vRYyuLCSkzzhwzEyjmMHI7vKsQZtgupbhL5sxe1WXeqUGWTGhGdG6Igz owaOMVkY7u7uD/0bUC76xOoBvbPz+BnA= X-Received: by 2002:a05:6512:6682:20b0:5bc:d17f:38b2 with SMTP id 2adb3069b0e04-5bcd17f3bbfmr472123e87.22.1791386435051; Wed, 07 Oct 2026 08:20:35 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-14-gwd@xenproject.org> In-Reply-To: <20261007104051.48841-14-gwd@xenproject.org> From: George Dunlap Date: Wed, 7 Oct 2026 16:20:23 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9FiueNVSk7bDR-F3LnyDod2Ns7j7cRMRrqM9Ch-YWCShOYECUUS6SNaaA Message-ID: Subject: Re: [PATCH v3 13/18] x86/mm: build and maintain a sparse view of the directmap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2026 at 12:00=E2=80=AFPM George Dunlap = wrote: > The directmap maps all of RAM, and every root page-table carries it, so > while any guest context runs, all guest memory is reachable from Xen's > address space. For ASI, guest contexts are to run on a view of the > directmap which maps only what Xen must reach through it at all times, > leaving guest memory to transient mappings (map_domain_page()). Note that a deeper review has found a bunch of random corner-cases, mostly to do with allocation failures when modifying the sparse view's pagetables. I'm going through them; my current plan is in most cases to add fixes after this series, to make them easier to review, unless they're obviously core to the functionality of this patch as it is. -George From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:37:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:37:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442482.1660028 (Exim 4.92) (envelope-from ) id 1xETi3-0001UP-ED; Wed, 07 Oct 2026 15:37:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442482.1660028; Wed, 07 Oct 2026 15:37: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 1xETi3-0001UI-Bi; Wed, 07 Oct 2026 15:37:35 +0000 Received: by outflank-mailman (input) for mailman id 1442482; Wed, 07 Oct 2026 15:37:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xETi2-0001U9-RM for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:37:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xETi2-001gu6-1r for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:37:34 +0000 Received: from mail-lj1-f170.google.com ([209.85.208.170]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xETi2-003F2s-1g for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:37:34 +0000 Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-3a98fc80925so14671891fa.0 for ; Wed, 07 Oct 2026 08:37: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" 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=w+XKidOF5LxyFtTFhGjvoyegJV3ckygR4rxmKB8hda0=; b=ZkS2auj iWV24Xj+DG42EzP4OBT1I86/pXGCbnr5qGQ2Ow46rb/jvlBGDjKCQ+4m4h68X/aAqiD1Kzjp/bRYH 72yT9OwK1asN1ndsPoghbGDEWt/9Rb4WNn9EmPJH4Nq8Js2v3nfYaf8R5wyTDE/kLJ5nPleBE71jN TjZhGFzGJ8=; X-Gm-Message-State: AFq9FYJNPE3K9nJWP+MaOOnoVI5rkk8BjRrozfvwjiPemWg5ldmK/zs5 W1G9o7vL3mN4eSYy0/l9v5QaIiA4/lzx0KrVQoF2kEcIWsXLu8TCWzj9ZAGCX4CMZx6JMs729fH YyZSInnGnM83MYC47WZArCHEw3QiKXpE= X-Received: by 2002:a05:651c:b29:b0:3a9:74f3:17d5 with SMTP id 38308e7fff4ca-3a9a2b8ec4emr6888291fa.3.1791387453444; Wed, 07 Oct 2026 08:37:33 -0700 (PDT) MIME-Version: 1.0 From: Cody Zuschlag Date: Wed, 7 Oct 2026 17:37:21 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK96hoj_DYbop9OlJ6I2_oQmr-Tqk6jKQ9OzN6rIp_3nR70-D6Vw38K_BXQ Message-ID: Subject: [ANNOUNCE] Xen Community Call - Tomorrow, Thursday, 8 October at 15:00 UTC To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d155ee065d41e45f" --000000000000d155ee065d41e45f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, It's time for the October Xen Project Community Call, happening tomorrow, Thursday, 8 October 2026 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 before 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 helpful We'll also follow up on Xen Summit 2026. The event was a success, and the talks are now published. If you haven't already, please complete the feedback survey . The agenda includes the meeting link and a link to find your local meeting time. *Call Details* Date: *Thursday, 8 October 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 . See you tomorrow! Cody Zuschlag Xen Project - Community Manager --000000000000d155ee065d41e45f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi everyone,

It's time for the October X= en Project Community Call, happening tomorrow, Thursday, 8 October 2026 at = 15:00 UTC.

Whether you have updates to share or just want to listen i= n, we'd love to have you join. It's a great opportunity to hear wha= t the community has been working on, discuss ongoing project activities, an= d catch up on recent developments.

Preparation

=F0=9F=91=89 Please take a few minutes to review and update the agenda= before the call.

Feel free to:

  • Add topics or project u= pdates

  • Suggest anything we can drop or defer

  • = Include links to patches, mailing list threads, or documentation where help= ful

We'll also follow up on Xen Summit 2026. The event = was a success, and the talks are now published. If you haven't already,= please complete the feed= back survey.

The agenda includes the meeting link and a link to f= ind your local meeting time.

Call Details

Date= : Thursday, 8 October 2026
Time: 15:00 UTC (agenda starts at 1= 5:05 UTC)
Join: https://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 annou= ncements?

Add or remove yourself from our sign-up sheet.

Se= e you tomorrow!



Cody Zus= chlag
Xen Project - Community Manager
--000000000000d155ee065d41e45f-- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:43:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:43:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442490.1660038 (Exim 4.92) (envelope-from ) id 1xETnu-0003Cx-1H; Wed, 07 Oct 2026 15:43:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442490.1660038; Wed, 07 Oct 2026 15:43: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 1xETnt-0003Cq-Uf; Wed, 07 Oct 2026 15:43:37 +0000 Received: by outflank-mailman (input) for mailman id 1442490; Wed, 07 Oct 2026 15:43:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xETns-0003Bc-9h for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:43:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xETnr-002ol7-DO for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:43:35 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6687e-8faa-0a2a0a5109dd-0a2a450bbee8-44 for ; Wed, 07 Oct 2026 17:43:35 +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 6ac668a6-b7e8-0a2a450b0019-b9ff1c22808f-3 for ; Wed, 07 Oct 2026 17:43: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 1a11708bf380003f66.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 15:43: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 93BFE8108D; Wed, 7 Oct 2026 17:43: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=rDl2j1bOq4XKzcwO60J1RdsI72stV9z1o/0sInWqrhA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=LNn3eFKVs9eu6OGhcIVePwuVwFKJ1ZxRu8zOMqL96dCXGXKUKxSIhmKqypM+DkiH9yFIh9Enm l86wrOfM7NIsjCH0WhZz/eaeOLhPQiTQicF8qKh16xHWSasANBXIilco1Oy/wmNL6ZN5cCPm12F gJJwXYTsmaPsR6p361iSiiVckX6BjPyfPM0cW2wb07BpX8WEHKsbfY9SUtpk/zF9Tkx+Ttkbt9A OwtO6RmHWgJFV1RRCxv4ORH1EfNhKBtIvNV1StkrcPTuCwnRovRBY/MkwrDo5FO1wl8vpZZabRL BCe1adD7UhGKMAue7jPHgavWcay4U8rs49MptZiO8Cfg== X-Zone-Loop: fc869ddd6d0c96c54dcb4148bad17f26ba80e19f89d5 x-campaign-type: default x-transaction-id: 68b78bb6-795f-4864-a945-75e184c16ea7 x-swg-uid: 01-2e0ceb0e-db64-441d-9ad0-b6290752018c X-Mailer: Sweego Message-ID: <1791387811.8631fc262581453bbf619ec5b2062170.1a11708bf380003f66@vates.tech> x-swg-bid: 1791387811.8631fc262581453bbf619ec5b2062170.1a11708bf380003f66 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 , Anthony PERARD , Juergen Gross , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" Subject: [RFC PATCH 0/4] Introduce a interface to query cpu status map Date: Wed, 7 Oct 2026 17:40:43 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.6ff.b65add74318a0ded.1a11708bc14.a426533906f15c3a=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791387810837 X-purgate-ID: tlsNG-42698a/1791387815-A96C29EA-F460B28B/0/0 X-purgate-type: clean X-purgate-size: 2563 ---=Part.6ff.b65add74318a0ded.1a11708bc14.a426533906f15c3a=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, this is originally meant to make xenpm get-core-temp more robust, but happens to also be useful in other cases=2E CPUs can offline for various reasons including hot-pluggable CPUs (possible CPUs) or through explicit offlining with xen-hptool (present but offline)=2E However, there is no way to probe which CPU is in which state outside of Xen itself (cpu_online_map and other maps)=2E That leads to problems in some cases as xenpm get-core-temp may try to query CPU temperature of offline CPUs (leading to ENODEV) or observe a incorrect cores_per_socket (if offline CPUs are a part of the first socket), leading to inconsistent package temperatures reporting=2E The first commit expose a new sysctl to query the cpu_online_map, cpu_present_map and cpu_possible_map bitmaps=2E The 2 following commits add a matching interface in xl and new `xl info -m` to get the CPU status map (Online/Offline status of each pCPU)=2E And the latest commit reworks xenpm get-core-temp core/socket selection logic to properly handle cases when CPUs are brought offline and be more robust against some complicated CPU topologies=2E This can be trivially tested using `xen-hptool cpu-{on,off}line N` to bring a CPU offline along with `xl info -m` and `xenpm get-core-temp` to observe it=2E Teddy Astie (4): sysctl: Introduce XEN_SYSCTL_get_cpu_status_map libxl: Introduce CPU status map interface xl: Expose CPU status map with 'xl info -m' xenpm: Rework get-core-temp around CPU status map and topology tools/include/libxl=2Eh | 11 ++++++ tools/include/xenctrl=2Eh | 4 ++ tools/libs/ctrl/xc_misc=2Ec | 45 +++++++++++++++++++++ tools/libs/light/libxl=2Ec | 39 +++++++++++++++++++ tools/libs/light/libxl_types=2Eidl | 6 +++ tools/misc/xenpm=2Ec | 67 ++++++++++++++++++++++++++++---- tools/xl/xl_cmdtable=2Ec | 4 +- tools/xl/xl_info=2Ec | 46 ++++++++++++++++++++-- xen/common/sysctl=2Ec | 34 ++++++++++++++++ xen/include/public/sysctl=2Eh | 13 +++++++ xen/xsm/flask/hooks=2Ec | 1 + 11 files changed, 258 insertions(+), 12 deletions(-) --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.6ff.b65add74318a0ded.1a11708bc14.a426533906f15c3a=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:46:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:46:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442498.1660047 (Exim 4.92) (envelope-from ) id 1xETqt-0003qh-FX; Wed, 07 Oct 2026 15:46:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442498.1660047; Wed, 07 Oct 2026 15:46: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 1xETqt-0003qa-Cc; Wed, 07 Oct 2026 15:46:43 +0000 Received: by outflank-mailman (input) for mailman id 1442498; Wed, 07 Oct 2026 15:46:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xETqs-0003qU-1F for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:46:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xETqr-008eFd-Bn for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:46:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac66961-8faa-0a2a0a5109dd-0a2a450ba5ac-2 for ; Wed, 07 Oct 2026 17:46:41 +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 6ac66960-b7e8-0a2a450b0019-b9ff1c22902f-3 for ; Wed, 07 Oct 2026 17:46: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1170b92c90003f66.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 15:46:36 +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 08DB781DEB; Wed, 7 Oct 2026 17:46: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: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=rk3uy03w5V24iPjfPh6M2D24moaVetkS2x93l1CxY9g=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=q96vPC+bHmZk2E383Ax0sG+CQg1LgqB9jVIwTfx6VntH/EhXke9YAl/RPI8dp5T4jAdjUTpyo SVWIXY3Be6rjQaxSa2zuCmtx8zRTHe64bvTRGRWhN3MeHuaG+eEkOQoc0gbjFQmhAyW9Y0sl0Sw uLPQOvBDWB1Nk2zoyX0wdE3ifwSaJEvdPGKKu4uLJ39ceoZppCeo71z8mkjJmR6BOOeW14ne9JW /BpUnEpoK15JxewL+SX+/5BcTPP8ZuUGYFmmyKumVHN+rYPfS5bihInoLVKbTeQR5VyWIZS+G3R Ui6i1r/Vzfz5jzVQuZrYMnP8x3yqnImnNr0Ml/LyEcgQ== X-Zone-Loop: 87df29df85a04a18a7b16c952131a823607fd96f2a11 x-campaign-type: default x-transaction-id: 11fc5f81-23fd-4004-88cc-f4a23a93d46b x-swg-uid: 01-915d429a-e14a-48f4-81c0-dde98a2859e9 X-Mailer: Sweego Message-ID: <1791387996.8631fc262581453bbf619ec5b2062170.1a1170b92c90003f66@vates.tech> x-swg-bid: 1791387996.8631fc262581453bbf619ec5b2062170.1a1170b92c90003f66 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 , Anthony PERARD , Juergen Gross , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" Subject: [RFC PATCH 1/4] sysctl: Introduce XEN_SYSCTL_get_cpu_status_map Date: Wed, 7 Oct 2026 17:46:03 +0200 In-Reply-To: <1791387811.8631fc262581453bbf619ec5b2062170.1a11708bf380003f66@vates.tech> References: <1791387811.8631fc262581453bbf619ec5b2062170.1a11708bf380003f66@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.702.3f88af7e61409967.1a1170b9067.3da2fa25f2569846=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791387996263 X-purgate-ID: tlsNG-42698a/1791388001-19CC79EA-1AB07DBA/0/0 X-purgate-type: clean X-purgate-size: 7687 ---=Part.702.3f88af7e61409967.1a1170b9067.3da2fa25f2569846=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Introduce XEN_SYSCTL_get_cpu_status_map as a way to get bitmaps of cpu_online_map, cpu_present_map and cpu_possible_map (if available)=2E Signed-off-by: Teddy Astie --- On x86, cpu_possible_map doesn't exist, that may not be expected=2E Should we add additional infos like cpu_sibling_mask and cpu_core_mask ? tools/include/xenctrl=2Eh | 4 ++++ tools/libs/ctrl/xc_misc=2Ec | 45 +++++++++++++++++++++++++++++++++++++ xen/common/sysctl=2Ec | 34 ++++++++++++++++++++++++++++ xen/include/public/sysctl=2Eh | 13 +++++++++++ xen/xsm/flask/hooks=2Ec | 1 + 5 files changed, 97 insertions(+) diff --git a/tools/include/xenctrl=2Eh b/tools/include/xenctrl=2Eh index 9f00d4a19d=2E=2E55804f2f1c 100644 --- a/tools/include/xenctrl=2Eh +++ b/tools/include/xenctrl=2Eh @@ -1145,6 +1145,10 @@ typedef uint32_t xc_node_to_node_dist_t; int xc_physinfo(xc_interface *xch, xc_physinfo_t *info); int xc_cputopoinfo(xc_interface *xch, unsigned *max_cpus, xc_cputopo_t *cputopo); +int xc_get_cpu_status_map(xc_interface *xch, unsigned nr_cpus, + xc_cpumap_t cpu_online_map, + xc_cpumap_t cpu_present_map, + xc_cpumap_t cpu_possible_map); int xc_microcode_update(xc_interface *xch, const void *buf, size_t len, unsigned int flags); int xc_get_cpu_version(xc_interface *xch, struct xenpf_pcpu_version *cpu_= ver); diff --git a/tools/libs/ctrl/xc_misc=2Ec b/tools/libs/ctrl/xc_misc=2Ec index 10ddf85667=2E=2Ebff4f5ff01 100644 --- a/tools/libs/ctrl/xc_misc=2Ec +++ b/tools/libs/ctrl/xc_misc=2Ec @@ -264,6 +264,51 @@ int xc_get_ucode_revision(xc_interface *xch, return 0; } =20 +int xc_get_cpu_status_map(xc_interface *xch, unsigned nr_cpus, + xc_cpumap_t cpu_online_map, + xc_cpumap_t cpu_present_map, + xc_cpumap_t cpu_possible_map) +{ + int ret; + struct xen_sysctl sysctl =3D {}; + struct xen_sysctl_cpu_status_map cpu_status_map; + DECLARE_HYPERCALL_BOUNCE(cpu_online_map, (nr_cpus + 7) / 8, + XC_HYPERCALL_BUFFER_BOUNCE_OUT); + DECLARE_HYPERCALL_BOUNCE(cpu_present_map, (nr_cpus + 7) / 8, + XC_HYPERCALL_BUFFER_BOUNCE_OUT); + DECLARE_HYPERCALL_BOUNCE(cpu_possible_map, (nr_cpus + 7) / 8, + XC_HYPERCALL_BUFFER_BOUNCE_OUT); + + if ( (ret =3D xc_hypercall_bounce_pre(xch, cpu_online_map)) ) + goto out; + + if ( (ret =3D xc_hypercall_bounce_pre(xch, cpu_present_map)) ) + goto out; + + if ( (ret =3D xc_hypercall_bounce_pre(xch, cpu_possible_map)) ) + goto out; + + sysctl=2Ecmd =3D XEN_SYSCTL_get_cpu_status_map; + + set_xen_guest_handle(cpu_status_map=2Ecpu_online_map=2Ebitmap, cpu_on= line_map); + cpu_status_map=2Ecpu_online_map=2Enr_bits =3D nr_cpus; + set_xen_guest_handle(cpu_status_map=2Ecpu_present_map=2Ebitmap, cpu_p= resent_map); + cpu_status_map=2Ecpu_present_map=2Enr_bits =3D nr_cpus; + set_xen_guest_handle(cpu_status_map=2Ecpu_possible_map=2Ebitmap, cpu_= possible_map); + cpu_status_map=2Ecpu_possible_map=2Enr_bits =3D nr_cpus; + + sysctl=2Eu=2Ecpu_status_map =3D cpu_status_map; + + ret =3D do_sysctl(xch, &sysctl); + +out: + xc_hypercall_bounce_post(xch, cpu_online_map); + xc_hypercall_bounce_post(xch, cpu_present_map); + xc_hypercall_bounce_post(xch, cpu_possible_map); + + return ret; +} + int xc_cputopoinfo(xc_interface *xch, unsigned *max_cpus, xc_cputopo_t *cputopo) { diff --git a/xen/common/sysctl=2Ec b/xen/common/sysctl=2Ec index 8fb5ff0af3=2E=2E840b2243bf 100644 --- a/xen/common/sysctl=2Ec +++ b/xen/common/sysctl=2Ec @@ -474,6 +474,40 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u= _sysctl) if ( ret !=3D -ENOSYS && ret !=3D -EOPNOTSUPP ) copyback =3D 1; break; + =20 + case XEN_SYSCTL_get_cpu_status_map: + { + struct xen_sysctl_cpu_status_map *csm =3D &op->u=2Ecpu_status_map= ; + + if ( !guest_handle_is_null(csm->cpu_online_map=2Ebitmap) ) + { + ret =3D cpumask_to_xenctl_bitmap(&csm->cpu_online_map, + &cpu_online_map); + if ( ret ) + break; + } + + if ( !guest_handle_is_null(csm->cpu_present_map=2Ebitmap) ) + { + ret =3D cpumask_to_xenctl_bitmap(&csm->cpu_present_map, + &cpu_present_map); + if ( ret ) + break; + } + + if ( !guest_handle_is_null(csm->cpu_possible_map=2Ebitmap) ) + { +#ifdef CONFIG_X86 + /* On x86, cpu_possible_map doesn't exist, use cpumask_all in= stead=2E */ + ret =3D cpumask_to_xenctl_bitmap(&csm->cpu_possible_map, + &cpumask_all); +#else + ret =3D cpumask_to_xenctl_bitmap(&csm->cpu_possible_map, + &cpu_possible_map); +#endif + } + break; + } =20 default: ret =3D arch_do_sysctl(op, u_sysctl); diff --git a/xen/include/public/sysctl=2Eh b/xen/include/public/sysctl=2Eh index 63d0ee062b=2E=2E3a2a1d2402 100644 --- a/xen/include/public/sysctl=2Eh +++ b/xen/include/public/sysctl=2Eh @@ -1181,6 +1181,17 @@ struct xen_sysctl_livepatch_op { } u; }; =20 +/*=20 + * XEN_SYSCTL_get_cpu_status_map + * + * Get bitmaps of CPU status (possible, online, present)=2E + */ +struct xen_sysctl_cpu_status_map { + struct xenctl_bitmap cpu_online_map; + struct xenctl_bitmap cpu_present_map; + struct xenctl_bitmap cpu_possible_map; +}; + #if defined(__i386__) || defined(__x86_64__) /* * XEN_SYSCTL_get_cpu_policy (x86 specific) @@ -1262,6 +1273,7 @@ struct xen_sysctl { /* #define XEN_SYSCTL_set_parameter 28 */ #define XEN_SYSCTL_get_cpu_policy 29 #define XEN_SYSCTL_dt_overlay 30 +#define XEN_SYSCTL_get_cpu_status_map 31 uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */ union { struct xen_sysctl_readconsole readconsole; @@ -1288,6 +1300,7 @@ struct xen_sysctl { struct xen_sysctl_psr_alloc psr_alloc; struct xen_sysctl_cpu_featureset cpu_featureset; struct xen_sysctl_livepatch_op livepatch; + struct xen_sysctl_cpu_status_map cpu_status_map; #if defined(__i386__) || defined(__x86_64__) struct xen_sysctl_cpu_policy cpu_policy; #endif diff --git a/xen/xsm/flask/hooks=2Ec b/xen/xsm/flask/hooks=2Ec index d65ba0aeae=2E=2E4ea0aeb1bb 100644 --- a/xen/xsm/flask/hooks=2Ec +++ b/xen/xsm/flask/hooks=2Ec @@ -952,6 +952,7 @@ static int cf_check flask_sysctl(const struct xen_sysc= tl *op) case XEN_SYSCTL_numainfo: case XEN_SYSCTL_pcitopoinfo: case XEN_SYSCTL_get_cpu_policy: + case XEN_SYSCTL_get_cpu_status_map: return domain_has_xen(current->domain, XEN__PHYSINFO); =20 case XEN_SYSCTL_getdomaininfolist: --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.702.3f88af7e61409967.1a1170b9067.3da2fa25f2569846=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:46:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:46:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442499.1660057 (Exim 4.92) (envelope-from ) id 1xETqv-00044K-S8; Wed, 07 Oct 2026 15:46:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442499.1660057; Wed, 07 Oct 2026 15: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 1xETqv-00044D-MK; Wed, 07 Oct 2026 15:46:45 +0000 Received: by outflank-mailman (input) for mailman id 1442499; Wed, 07 Oct 2026 15:46:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xETqt-0003r3-MX for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:46:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xETqt-008eFd-3R for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:46:43 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac66961-8faa-0a2a0a5109dd-0a2a450ba5ac-12 for ; Wed, 07 Oct 2026 17:46:43 +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 6ac66960-b7e8-0a2a450b0019-b9ff1c22902f-4 for ; Wed, 07 Oct 2026 17:46: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1170b93ac0003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 15:46:37 +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 8A7A681F5F; Wed, 7 Oct 2026 17:46: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: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=WwKq5yOW5P38TgAgPmeL7dXcpScmTECxeMSB9MdS3mo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=RhYHFS7z7YUntviwe2BgMSxCAn5BbYhUlzzJof7P8fDR5dh15rwFqvq5l8BW5cmV/YlWygQq1 SjeH/pRT8q0w3heKyhkEdHGgEWJ6FZpXcueyZ3e0/3IacvF2GXUWTBTco2NTdLWES95Ii8OuFpt uFLTE/rSfIp9uXci9G7JquGTDJcCFZBeias4IJZBJN34j7aDloDZDLu2nUmrRF2K0Ds8wIGZYYs JjexdlCLv7I2xbaO/iL/45VXtAPado4t5EIyUD8tcHX4QMRF7ezbSBsVwUBpEXP2fD9j5XXJvXN 3YSmqUHQFV+sNMrcNCWSFomUgwNxgwu/BGGVor/H5Muw== X-Zone-Loop: 5a423810c237a6b2973e1c4a5a2daeea5bbc121134bd x-campaign-type: default x-transaction-id: a4b6c01e-995c-45bc-a4d1-1fd194071bc4 x-swg-uid: 01-b3ad82ba-bfb1-4773-ab6d-5880a001f0e2 X-Mailer: Sweego Message-ID: <1791387997.8631fc262581453bbf619ec5b2062170.1a1170b93ac0003f66@vates.tech> x-swg-bid: 1791387997.8631fc262581453bbf619ec5b2062170.1a1170b93ac0003f66 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 , Anthony PERARD , Juergen Gross Subject: [RFC PATCH 2/4] libxl: Introduce CPU status map interface Date: Wed, 7 Oct 2026 17:46:04 +0200 In-Reply-To: <20261007154607.119543-2-teddy.astie@vates.tech> References: <1791387811.8631fc262581453bbf619ec5b2062170.1a11708bf380003f66@vates.tech> <20261007154607.119543-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.703.294bea765ded471c.1a1170b91ff.9461faef7aed09b3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791387996671 X-purgate-ID: tlsNG-42698a/1791388002-A88C99EA-74E899A5/0/0 X-purgate-type: clean X-purgate-size: 4113 ---=Part.703.294bea765ded471c.1a1170b91ff.9461faef7aed09b3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Introduce a way to query CPU status map (online, present, possible) using the newly introduced XEN_SYSCTL_get_cpu_status_map operation=2E Signed-off-by: Teddy Astie --- tools/include/libxl=2Eh | 11 +++++++++ tools/libs/light/libxl=2Ec | 39 ++++++++++++++++++++++++++++++++ tools/libs/light/libxl_types=2Eidl | 6 +++++ 3 files changed, 56 insertions(+) diff --git a/tools/include/libxl=2Eh b/tools/include/libxl=2Eh index 7c098edab6=2E=2E08a2df7fc3 100644 --- a/tools/include/libxl=2Eh +++ b/tools/include/libxl=2Eh @@ -1536,6 +1536,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,= const libxl_mac *src); */ #define LIBXL_HAVE_XEN_PLATFORM_PCI_BAR_UC =20 +/* + * LIBXL_HAVE_CPU_STATUS_MAP + * + * If this is defined, libxl_get_cpu_status_map() is available to query C= PUs + * status map (online, present, possible)=2E + */ +#define LIBXL_HAVE_CPU_STATUS_MAP + /* * LIBXL_HAVE_XENSTORE_QUOTA * @@ -2191,6 +2199,9 @@ void libxl_pcitopology_list_free(libxl_pcitopology *= , int num_devs); libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr); void libxl_numainfo_list_free(libxl_numainfo *, int nr); =20 +libxl_cpu_status_map *libxl_get_cpu_status_map(libxl_ctx *ctx, int *nr); +void libxl_cpu_status_map_free(libxl_cpu_status_map *); + libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid, int *nb_vcpu, int *nr_cpus_out); void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr_vcpus); diff --git a/tools/libs/light/libxl=2Ec b/tools/libs/light/libxl=2Ec index a1fe16274d=2E=2E6d4b2cf4f4 100644 --- a/tools/libs/light/libxl=2Ec +++ b/tools/libs/light/libxl=2Ec @@ -546,6 +546,45 @@ libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, in= t *nr) return ret; } =20 +libxl_cpu_status_map *libxl_get_cpu_status_map(libxl_ctx *ctx, int *nr) +{ + GC_INIT(ctx); + libxl_cpu_status_map *ret =3D NULL; + + ret =3D libxl__zalloc(NOGC, sizeof(*ret)); + + *nr =3D xc_get_max_cpus(ctx->xch); + if (*nr < 0) { + LOGE(ERROR, "getting max_cpus"); + goto out; + } + + libxl_bitmap_alloc(ctx, &ret->cpu_online_map, *nr); + libxl_bitmap_alloc(ctx, &ret->cpu_present_map, *nr); + libxl_bitmap_alloc(ctx, &ret->cpu_possible_map, *nr); + + if (xc_get_cpu_status_map(ctx->xch, *nr, + ret->cpu_online_map=2Emap, + ret->cpu_present_map=2Emap, + ret->cpu_possible_map=2Emap)) { + LOGE(ERROR, "getting cpu_status_map"); + goto out; + } + +out: + GC_FREE; + return ret; +} + +void libxl_cpu_status_map_free(libxl_cpu_status_map *cpu_status_map) +{ + libxl_bitmap_dispose(&cpu_status_map->cpu_online_map); + libxl_bitmap_dispose(&cpu_status_map->cpu_possible_map); + libxl_bitmap_dispose(&cpu_status_map->cpu_present_map); + + free(cpu_status_map); +} + const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx) { GC_INIT(ctx); diff --git a/tools/libs/light/libxl_types=2Eidl b/tools/libs/light/libxl_t= ypes=2Eidl index a7893460f0=2E=2E33b81d93c8 100644 --- a/tools/libs/light/libxl_types=2Eidl +++ b/tools/libs/light/libxl_types=2Eidl @@ -1276,6 +1276,12 @@ libxl_pcitopology =3D Struct("pcitopology", [ ("node", uint32), ], dir=3DDIR_OUT) =20 +libxl_cpu_status_map =3D Struct("cpu_status_map", [ + ("cpu_online_map", libxl_bitmap), + ("cpu_present_map", libxl_bitmap), + ("cpu_possible_map", libxl_bitmap), +]) + libxl_sched_credit_params =3D Struct("sched_credit_params", [ ("tslice_ms", integer), ("ratelimit_us", integer), --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.703.294bea765ded471c.1a1170b91ff.9461faef7aed09b3=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:46:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:46:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442500.1660062 (Exim 4.92) (envelope-from ) id 1xETqw-00046I-4S; Wed, 07 Oct 2026 15:46:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442500.1660062; Wed, 07 Oct 2026 15:46: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 1xETqv-00045q-TI; Wed, 07 Oct 2026 15:46:45 +0000 Received: by outflank-mailman (input) for mailman id 1442500; Wed, 07 Oct 2026 15:46:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xETqt-0003wU-VE for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:46:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xETqt-008eFd-Bs for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:46:43 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac66961-8faa-0a2a0a5109dd-0a2a450ba5ac-16 for ; Wed, 07 Oct 2026 17:46:43 +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 6ac66960-b7e8-0a2a450b0019-b9ff1c22902f-5 for ; Wed, 07 Oct 2026 17:46: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 1a1170b94750003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 15:46:37 +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 C3B6482191; Wed, 7 Oct 2026 17:46: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: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=eBAH3WHU7ZzQ413sxtWXDDZRko1V52GT0XqzM+g0T2k=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ax3WEjv60t3eid6ewZTic5EZ9XxJ03pMtZSJolrpN8NyQv5PD4a6UM3q+7ULIkNa41lXggMEA KROBKyWUOrxGJIv6Dmp6a28j37/QWWPaoSSHLktYbV5t+SXxV2ES6Isv7fxrHyRhQzZokPuKcwY Eu7Be1X2vI43RRnEjMwRhb5wGyER+VaI5Vq9W1Ke5SWxhGcLD0nAeKwdtcyruNTtr3NM9cTsEVC 3ieRWpyLnttE/M6kqKncIU9GQfsr1Vr4TlIi2IkzJXURAtZte8KRL2ISp4H5r7Ch7J+LS18Tk8B i53x71476nEbASeDNAoiM29hTUxiHGA5YHsrU6rmqJZA== X-Zone-Loop: 16fc0de5a55e8e88e2df1ac9b3b220e89446d566fa04 x-campaign-type: default x-transaction-id: 00bd7085-32a3-47ce-b74b-5fa51080fa23 x-swg-uid: 01-f907e347-9c60-4d98-9b0d-7b7f83ad6041 X-Mailer: Sweego Message-ID: <1791387997.8631fc262581453bbf619ec5b2062170.1a1170b94750003f66@vates.tech> x-swg-bid: 1791387997.8631fc262581453bbf619ec5b2062170.1a1170b94750003f66 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 , Anthony PERARD Subject: [RFC PATCH 3/4] xl: Expose CPU status map with 'xl info -m' Date: Wed, 7 Oct 2026 17:46:05 +0200 In-Reply-To: <20261007154607.119543-2-teddy.astie@vates.tech> References: <1791387811.8631fc262581453bbf619ec5b2062170.1a11708bf380003f66@vates.tech> <20261007154607.119543-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.704.b4aaaba915cd2de1.1a1170b92d9.263815be9e54d56a=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791387996889 X-purgate-ID: tlsNG-42698a/1791388003-AAEDE9EA-A89D8D7A/0/0 X-purgate-type: clean X-purgate-size: 3629 ---=Part.704.b4aaaba915cd2de1.1a1170b92d9.263815be9e54d56a=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Signed-off-by: Teddy Astie --- tools/xl/xl_cmdtable=2Ec | 4 +++- tools/xl/xl_info=2Ec | 46 ++++++++++++++++++++++++++++++++++++++---- 2 files changed, 45 insertions(+), 5 deletions(-) diff --git a/tools/xl/xl_cmdtable=2Ec b/tools/xl/xl_cmdtable=2Ec index 502244f683=2E=2E68caafd5bd 100644 --- a/tools/xl/xl_cmdtable=2Ec +++ b/tools/xl/xl_cmdtable=2Ec @@ -261,7 +261,9 @@ const struct cmd_spec cmd_table[] =3D { { "info", &main_info, 0, 0, "Get information about Xen host", - "-n, --numa List host NUMA topology information", + "[options]", + "-n, --numa List host NUMA topology information\n" + "-m, --map Show CPU status map" }, { "sharing", &main_sharing, 0, 0, diff --git a/tools/xl/xl_info=2Ec b/tools/xl/xl_info=2Ec index 98fc879e63=2E=2Ebed8996c9b 100644 --- a/tools/xl/xl_info=2Ec +++ b/tools/xl/xl_info=2Ec @@ -420,7 +420,39 @@ static void output_xenstore_info(void) xs_close(xsh); } =20 -static void print_info(int numa, bool xs) +static void output_cpumap(void) +{ + int nr, i; + + libxl_cpu_status_map *cpu_status_map =3D libxl_get_cpu_status_map(ctx= , &nr); + if (!cpu_status_map) { + fprintf(stderr, "libxl_get_cpu_status_map failed=2E\n"); + return; + } + + printf("CPU statuses\n"); + =20 + for (i =3D 0; i < nr; i++) { + const char *status =3D "None"; + bool online =3D libxl_bitmap_test(&cpu_status_map->cpu_online_map= , i); + bool present =3D libxl_bitmap_test(&cpu_status_map->cpu_present_m= ap, i); + bool possible =3D libxl_bitmap_test(&cpu_status_map->cpu_possible= _map, i); + + if (online) + status =3D "Online"; + else if (present) + status =3D "Offline (Present)"; + else if (possible) + status =3D "Offline (Possible)"; + + printf(" %d: %s\n", i, status); + } + + libxl_cpu_status_map_dispose(cpu_status_map); + free(cpu_status_map); +} + +static void print_info(int numa, bool xs, bool cpu_map) { output_nodeinfo(); =20 @@ -430,6 +462,8 @@ static void print_info(int numa, bool xs) output_topologyinfo(); output_numainfo(); } + if (cpu_map) + output_cpumap(); output_xeninfo(); =20 if (xs) @@ -732,18 +766,22 @@ int main_info(int argc, char **argv) static struct option opts[] =3D { {"numa", 0, 0, 'n'}, {"xenstore", 0, 0, 'x'}, + {"map", 0, 0, 'm'}, COMMON_LONG_OPTS }; int numa =3D 0; - bool xs =3D false; + bool xs =3D false, cpu_map =3D false; =20 - SWITCH_FOREACH_OPT(opt, "nx", opts, "info", 0) { + SWITCH_FOREACH_OPT(opt, "nxm", opts, "info", 0) { case 'n': numa =3D 1; break; case 'x': xs =3D true; break; + case 'm': + cpu_map =3D true; + break; } =20 /* @@ -753,7 +791,7 @@ int main_info(int argc, char **argv) if (numa =3D=3D 0 && argc > optind) info_name =3D argv[optind]; =20 - print_info(numa, xs); + print_info(numa, xs, cpu_map); return 0; } =20 --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.704.b4aaaba915cd2de1.1a1170b92d9.263815be9e54d56a=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:46:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:46:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442501.1660066 (Exim 4.92) (envelope-from ) id 1xETqw-00049q-C5; Wed, 07 Oct 2026 15:46:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442501.1660066; Wed, 07 Oct 2026 15:46: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 1xETqw-00047r-4G; Wed, 07 Oct 2026 15:46:46 +0000 Received: by outflank-mailman (input) for mailman id 1442501; Wed, 07 Oct 2026 15:46:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xETqu-0003yI-I0 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:46:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xETqt-0022WU-Ja for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:46:43 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac66961-8faa-0a2a0a5109dd-0a2a450ba5ac-18 for ; Wed, 07 Oct 2026 17:46:43 +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 6ac66960-b7e8-0a2a450b0019-b9ff1c22902f-6 for ; Wed, 07 Oct 2026 17:46: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 1a1170b955a0003f66.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 07 Oct 2026 15:46:37 +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 02C3981DEB; Wed, 7 Oct 2026 17:46: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: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=rSN6u6bHZ5QzzlBfugU+xcXP+4p5XrIY6NkPSwW+1mc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ru48aYnryweRttAV4ItK1qPCdEA7fsKwVIIC9fdkX4/UCQDRlyF9s07SqZQ4N5f4XtmnTPI+h rGtdXcTRKCkUHihfLsz5tpe1ZTDkVkt47clwy3oh1AuPMjH2u40ksYyhWDKCbVX74QmLqJc5SIO 9tIcR+MOrUcHItbfXpZ658QfgqUlOqFtA4PuvU3XLkhUQvcArxP+oT8IA7N14iCch5p1WG+3U65 IAMgUdqnnnwbjvjmSwhf2WV3x7HuuVqtmtnBrxDCmUjS4SAQ9jCxENt3v6J6Mj1dQwgrqwQRO4j o8A/y/zJBum4FlZ/fenH9vrh9mM56BlHMMKkWBywjM8Q== X-Zone-Loop: 6a1f2c71f598e007e75589bcf340be281a20a2d186d8 x-campaign-type: default x-transaction-id: 307586ce-98bb-4d77-8c0b-05028f079274 x-swg-uid: 01-405f1bfa-6df0-465f-9ad1-1120048dbaa4 X-Mailer: Sweego Message-ID: <1791387997.8631fc262581453bbf619ec5b2062170.1a1170b955a0003f66@vates.tech> x-swg-bid: 1791387997.8631fc262581453bbf619ec5b2062170.1a1170b955a0003f66 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 , Anthony PERARD Subject: [RFC PATCH 4/4] xenpm: Rework get-core-temp around CPU status map and topology Date: Wed, 7 Oct 2026 17:46:06 +0200 In-Reply-To: <20261007154607.119543-2-teddy.astie@vates.tech> References: <1791387811.8631fc262581453bbf619ec5b2062170.1a11708bf380003f66@vates.tech> <20261007154607.119543-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.705.73c0cff9a55a1186.1a1170b93aa.fe6734302212fccf=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791387997098 X-purgate-ID: tlsNG-42698a/1791388003-A96C29EA-1BCFC72A/0/0 X-purgate-type: clean X-purgate-size: 4973 ---=Part.705.73c0cff9a55a1186.1a1170b93aa.fe6734302212fccf=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Current get-core-temp core selection logic has some corner cases, in particular when CPUs are offlined=2E When some CPUs are offline, we observe various issues : - XENPF_resource_op fails with ENODEV on offline CPUs - cores_per_socket can be incorrect if there are offline CPUs on the first socket, leading to incorrect socket count calculation Rather than trying to workaround the problem, rework the algorithm to check if the CPU is online using XEN_SYSCTL_get_cpu_status_map and use CPU topology to select CPU sockets in a more robust way=2E Signed-off-by: Teddy Astie --- I'm not happy with the way sockets are handled=2E Using a bitmap would be a better option, but it would make things more complicated than it already is=2E tools/misc/xenpm=2Ec | 67 +++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 60 insertions(+), 7 deletions(-) diff --git a/tools/misc/xenpm=2Ec b/tools/misc/xenpm=2Ec index ecb39c911d=2E=2Ef6d1241496 100644 --- a/tools/misc/xenpm=2Ec +++ b/tools/misc/xenpm=2Ec @@ -1419,9 +1419,11 @@ static int fetch_dts_temp(xc_interface *xch, uint32= _t cpu, bool package, int *te =20 static void get_core_temp(int argc, char *argv[]) { - int temp =3D -1, cpu =3D -1; - unsigned int socket; + int temp =3D -1, cpu =3D -1, socket =3D -1; bool has_data =3D false; + xc_cputopo_t *cputopo =3D NULL; + unsigned int max_cpus =3D max_cpu_nr; + xc_cpumap_t cpu_online_map =3D NULL; =20 if ( argc > 0 ) parse_cpuid(argv[0], &cpu); @@ -1439,25 +1441,72 @@ static void get_core_temp(int argc, char *argv[]) return; } =20 + cputopo =3D calloc(max_cpu_nr, sizeof(*cputopo)); + if ( !cputopo ) + { + fprintf(stderr, "Unable to allocate CPU topology list\n"); + goto out; + } + + cpu_online_map =3D xc_cpumap_alloc(xc_handle); + if ( !cpu_online_map ) + { + fprintf(stderr, "Unable to allocate CPU status bitmap\n"); + goto out; + } + + if ( xc_cputopoinfo(xc_handle, &max_cpus, cputopo) ) + { + fprintf(stderr, + "Unable to get CPU topology (%d - %s)\n", + errno, strerror(errno)); + goto out; + } + + if ( (xc_get_cpu_status_map(xc_handle, max_cpu_nr, cpu_online_map, + NULL, NULL)) ) + { + fprintf(stderr, "Unable to get CPU online map (%d - %s)\n", + errno, strerror(errno)); + /* Assume all populated */ + memset(cpu_online_map, 0xff, xc_get_cpumap_size(xc_handle)); + } + + if ( max_cpus > max_cpu_nr ) + { + fprintf(stderr, "xc_cputopoinfo returned more CPU than physinfo ?= \n"); + max_cpus =3D max_cpu_nr; + } + /* Per socket measurement */ - for ( socket =3D 0, cpu =3D 0; cpu < max_cpu_nr; - socket++, cpu +=3D physinfo=2Ecores_per_socket * physinfo=2Ethr= eads_per_core ) + for ( cpu =3D 0; cpu < max_cpus; cpu++ ) { + if ( !xc_cpumap_testcpu(cpu, cpu_online_map) || + cputopo->core =3D=3D XEN_INVALID_CORE_ID || + (int)(cputopo[cpu]=2Esocket) <=3D socket ) + continue; + + socket =3D cputopo[cpu]=2Esocket; + if ( fetch_dts_temp(xc_handle, cpu, true, &temp) ) { fprintf(stderr, "[Package%u] Unable to fetch temperature (%d - %s)\n"= , - cpu, errno, strerror(errno)); + socket, errno, strerror(errno)); /* CPU may not support package temperatures, but still suppor= t DTS */ break; } =20 has_data =3D true; - printf("Package%u: %d=C2=B0C\n", socket, temp); + printf("Package%d: %d=C2=B0C\n", socket, temp); } =20 - for ( cpu =3D 0; cpu < max_cpu_nr; cpu +=3D physinfo=2Ethreads_per_co= re ) + for ( cpu =3D 0; cpu < max_cpus; cpu +=3D physinfo=2Ethreads_per_core= ) { + if ( !xc_cpumap_testcpu(cpu, cpu_online_map) || + cputopo[cpu]=2Ecore =3D=3D XEN_INVALID_CORE_ID ) + continue; + if ( fetch_dts_temp(xc_handle, cpu, false, &temp) ) { fprintf(stderr, "[CPU%d] Unable to fetch temperature (%d - %s= )\n", @@ -1469,6 +1518,10 @@ static void get_core_temp(int argc, char *argv[]) printf("CPU%d: %d=C2=B0C\n", cpu, temp); } =20 +out: + free(cputopo); + free(cpu_online_map); + if ( !has_data ) exit(EXIT_FAILURE); } --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.705.73c0cff9a55a1186.1a1170b93aa.fe6734302212fccf=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 07 15:58:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 15:58:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442523.1660084 (Exim 4.92) (envelope-from ) id 1xEU2e-0007XY-9D; Wed, 07 Oct 2026 15:58:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442523.1660084; Wed, 07 Oct 2026 15:58: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 1xEU2e-0007XR-4f; Wed, 07 Oct 2026 15:58:52 +0000 Received: by outflank-mailman (input) for mailman id 1442523; Wed, 07 Oct 2026 15:58:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEU2c-0007XL-Ma for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 15:58:50 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEU2c-001hKG-0k; Wed, 07 Oct 2026 15:58:50 +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 1xEU2b-003PQY-2u; Wed, 07 Oct 2026 15:58: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" 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=jR8JWj+lE7x4RrahFD+kLgeeLgo2Ww30CzL7fgVm0nw=; b=opbeA5OzcUEGZ1zbIADnF77th9 v/bw1QuH+d7veTn4OEunf5Cxz+KLb5uMEIwGvfziSzIKYxiaItbLrJlFJn+kSrMgcnIoYMraYLUym Z5HS9FxyegwnAjU4IkKSE7BuxMvRrFK+oZ2X7l9nSC9lleLPWUcJPRl8QhH8P1xAhDWo=; Date: Wed, 7 Oct 2026 17:58:47 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 03/18] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-4-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-4-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:36AM +0100, 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. > > The one remaining caller, free_compat_arg_xlat(), is already in a vCPU > context, so we just need to change the parameter from a domain pointer > to a vCPU pointer. Without the linear mapping usage this is now a non-functional change, I would possibly state that on the commit message. > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 07 16:07:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 16:07:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442536.1660092 (Exim 4.92) (envelope-from ) id 1xEUAR-0001HA-WD; Wed, 07 Oct 2026 16:06:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442536.1660092; Wed, 07 Oct 2026 16: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 1xEUAR-0001H3-Sm; Wed, 07 Oct 2026 16:06:55 +0000 Received: by outflank-mailman (input) for mailman id 1442536; Wed, 07 Oct 2026 16:06:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEUAQ-0001Gx-RD for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:06:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEUAQ-00D9eH-3r for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:06:54 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac66e1d-bab6-0a2a0a5309dd-0a2a4506acfc-2 for ; Wed, 07 Oct 2026 18:06:53 +0200 Received: from [40.107.162.87] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac66e1d-195a-0a2a45060019-286ba2576a2f-3 for ; Wed, 07 Oct 2026 18:06:53 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by GVXPR03MB618890.eurprd03.prod.outlook.com (2603:10a6:150:3a8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Wed, 7 Oct 2026 16:06:50 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.015; Wed, 7 Oct 2026 16:06: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=UHBwVMQREhQ15uoSCmR6T9WmCBTpmWof16i92QAM4w/8vKs9lb/3Nv19Fj95B2Y7JzKizMfYRDwCBitm+S+lk231zFEn4XR/suJfqmQ9itUsb1WN2Q/7F3WaSbPRvp8WpEtC5Bmi81Dut8zAeLYsCk2rOHG6lVw+pBO8AppFYZjTUtVWqznzL095RAbjJ13ZF9oLs5zqnn9BjrGFG1czthuUGPPJ4TOdUlCAXE+Gmio7Y3Km8pDP4ANjs12/dpja6vgUw9krfbMEUmOJjxwCWMHcoTnWXZCeCH5L6cBS6l/rhp6Qte4R2x6pmfGZWJriFqKIFF84awedbM0+2GqY3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Y5SFiT6sE6nHK4ZZuS7tB8MC18Q0At9FgX0U3zXzrO4=; b=th3Ke+5QGls+F7aq4FD4M2eN2aq1cLOlAQPTTiU2RNnNQsMmiAvtYcLxhp3soQstBn+dg0JGYjC7oHyQ/BY9QP8Hww1HQnG0bXaGoiTcUrairzGljk3DdVDDm1I0/g7JviPkoMo4BMMS0SVo+u1cyK8EWEzPMRAD2neLPpjoUajH2YKM8GDQGTVIyGyXh8GPWc9Yy+Tro7/yBZ7YVI7hASbe3HIluWHok0dbzgMiXuUyTkFdqG0iPUCWTB/kzq5b10NwQ2MM+VPheU2x974H7zH4gfOwleLqrJB1KSCH+7OdEqW+GcKV939kq7uOs5vLVL2v5yyU2GSadJ+6atw5OQ== 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=Y5SFiT6sE6nHK4ZZuS7tB8MC18Q0At9FgX0U3zXzrO4=; b=PpKqsvFZ1RKtXqhusOb9vN5WhWvx0+XNdXg20kYr0WezQ8akSaMDKKBKI/wkcUgLaDzqa6ttppN8My7kiaNDeBokxkV00lW+HGB2ch0L6tDeITH4QT1vAYBJd1x3crAJR7uiH7+XfDALOdiFeaEwIp6uY7jlvGJwj21VlKH3vIMpk2MTcQHjdqt3P45ayGo00REKxp2rbyZjS3LvU1jAhYRdlSll/afi/RDLYKF8cA73JqKg7Kg+24kdYlg3M/32UOXOnJaqD2rF+zUX5Yhnxft2Soegvp7O2D2o9vHV0CCdYN48FN9ajSe3j+boy1ElhMBwVK61mFpeOIPw5nKzZQ== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 1/6] x86/PV: adjust APPEND_CALL() to comply to Misra rule 18.2 Thread-Topic: [PATCH 1/6] x86/PV: adjust APPEND_CALL() to comply to Misra rule 18.2 Thread-Index: AQHdQFsRwAlF7v7XhUCFnbTczq2eTLbyawGA Date: Wed, 7 Oct 2026 16:06:49 +0000 Message-ID: <62d12b18-7413-4f65-9182-d410d3093140@epam.com> References: In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|GVXPR03MB618890:EE_ x-ms-office365-filtering-correlation-id: 1dff950c-8dc8-4f9e-a32f-08df248cfedc x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|42112799006|1800799024|56012099006|4143699003|10067099003|11063799006|18002099003|22082099003|38070700021; x-microsoft-antispam-message-info: oXebRXSpzUAbtlAFZmiWouicqvc30FG8rTQrd9o8h7Ao63p/9I+zOlnL4v16E8lhGm/mJVbs2d+S991pRLuaUWkzouy80TLdI49uXEn/dikREC1rGRE2QarapWXNoOEeMf7SikJymC9zPFMirK4futeI2hMdXDR0LH51Rh9Xg9rsftOU4kPsfTqB7mUeVRruz8yWfBb3m6QkmXYkZ1jua35mV/JQLo7wrCirB4PEYbmljTrJAUtDtV9Ay06dvJW3KG6yGQ5leMjwVOdN3Efo6gbwHzIWynj3vG/tPaV1e9roEN1P/9bfVZjNYHDULF5eEV1cXeTLMrcv67PrlCq7A1bC6UMdDUx5jUogmMcm2wnEbMqFhrlJStUimblYgY2cBXKDCbUygb8MeXhQsVoWA6q1d3AkUqdqlBEg+mXA2f8o9XkKVZCl3vFhz8HTHNj/qB+5AlOrOBT0nnMn4350AyR0MDTmqL0zlfKMxrqeWTGTIhqunGx8fi38qF0e/so8L4aMjyP9FaCrcyNrlcvLnXQFt2locXgiWhl+bqn2w2zaZItyqroWIeyvaguASrqEO+MwoLxnwQ/+367XWjsylfwl4PC+hUltD3PP06lortJpW3p61WpfMT8CSVZmjAlgBX2jid4SLqMzT8XnUHxOzYiXbMWoyddrrO0mpxHKsM1cL/Ua/f5LIAvBtsnCQCbosoUadGWz4SlgkQV2BkTytlIIMIOWaWbE5Awn5JOxnEw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(42112799006)(1800799024)(56012099006)(4143699003)(10067099003)(11063799006)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bEtuSVp5M3RFYlNUSmZ5S0hRcEpEOCtQc21UUnE0bW5QT1RKU3hHM3hIVjF0?= =?utf-8?B?emNwUmY2M2h5UDk5M3ppdUZIYnE3TkJYbWNhdmRPSWUyN0VCNGJ4TWE4cTNB?= =?utf-8?B?a3dlemNlRWhTak9oMFNRZWlJSVV6dmtsODRpQnA4c3JjcjBYNm9wblBrZDNL?= =?utf-8?B?czZ2c1FkTENHWU0wVjdONUU2RDJuR1liNW1VNDFCSHMrZUIraUtBUHpVcGJW?= =?utf-8?B?Yk1USHVsa3drOXB3ZDdjQy9OWVlvaURFZzdES2JFOFVmN3FZTUh6T0lQbW91?= =?utf-8?B?NnpEd0pCMFljT2QyeDBwMnFLcFRKWmpacHFRNEtadDVwN2JuZ3JzZ2lWcXBW?= =?utf-8?B?bm9FSVVpVkZQOTVTQ1NvOXFvMGE4SHVtdS9kTnVsVitMdCtlV0d2NzJPQnhY?= =?utf-8?B?dlZ5cXpnRHVwckVSdXQvc1dCV3ZrdWp3UGhuVFg0ZGszRVFOTjdTOVZFWWhL?= =?utf-8?B?RDJ3M05DWTFjRS9iQU9pZXNlRUdqUEpycTFkdzZkVFB6VGxkN2o5ZC9mQWE2?= =?utf-8?B?NDhXN2xMSlNyaWcxTnBhenM2cCtFd1haZEs2NUJwOEc4TnVNZit4QWMvd2dZ?= =?utf-8?B?bXZLR044eDhaQmlvditHdjBBVEdraU9Icmo1N1Y5SWxFNWsrbjllb3pDRUVK?= =?utf-8?B?TndSMFdtSUxCZS9hMllhcGpsTmZRbDZnMDVLRE02RjBrcFYwS0pvWEg3OWlj?= =?utf-8?B?R25ZNER5TE5pQ1N1UHUvYW03VVJPdHMwNFNFUFcvNU5iVGVNUDB3NG9IQWd0?= =?utf-8?B?cjZEam5CYXkrSThhdk5PMmg0V0oyZjVBamprdkhXaEg0T1hYMFVrRWs4eDlp?= =?utf-8?B?czRwUzQvQnpuOFRTcVFNZ2dEbkw0WHpCaFNUcHdCY0lQeU8vbEJBMHV5eXZp?= =?utf-8?B?ZVhYQTdoM2UyKzVSdW1CUEwxS0JCZ0FWcmdQeWpKTUtkNDJHdE1RdjZrMXc4?= =?utf-8?B?RWZ1VlJka0RMNkN4bnUxQ09DSm1YUDArTVFKUDRkUjJkamh5LzZBYngyMkJ5?= =?utf-8?B?eWhMZGZMTW16WjhDWXdDNmdVbG9PblJyWFRQV2tVSVlESmY4M01tRmNBM0VW?= =?utf-8?B?L2xjSDQ1bGNJeFppRGZic0RxYlR1MlFCdTUwS2FMMGhkTGo3a1g1RlVHdWNm?= =?utf-8?B?SzFhVWFUM21xVlNta0pOWldKeWVpRXFVWnVuTFk1T3Z3T2VySGxSRGFIR0hr?= =?utf-8?B?REp3OTZ6NG1VSGFvN0JSMWxtY1Q0N2NncUJmVTJvVnozOGdWbWpLZmJubGN6?= =?utf-8?B?aG1FU08rWTZlcFc0ZU8yTUxwbTdlanJSdkZaTmIrTUNZdHF0YUE3d3JlbDVt?= =?utf-8?B?N1pmLzNjUERrYk96Zmc0R1ZhMTUyNzBBdGc0QTJHc2NPeDdWQWVYT29rNHVX?= =?utf-8?B?a1JPVm10UXoxL2JaR2VmY1RwRTdTT2E0VlJNTWlYaDZZOHY2UzNVMllEVnpa?= =?utf-8?B?RFowWGlNVmNXdXE2bzVQazZjU2R5VjRTSFE0TVJ5bU9aMG9WT1pNQVBzTitR?= =?utf-8?B?RjY0ODMyaE80RjlaUEV5TCsvejg0Q3A1SFFqM2ZNMEFTODFTdW8wTm0wMmpB?= =?utf-8?B?L1dGVTJMMEY5ZTRta3Z4aXlhMDhzZWx3ZzVxRUU0bHR4ek9oY1VoOVNSSkdz?= =?utf-8?B?SXJCeW8zRnRpL0F5T0RaVWJJVWdOTXpKQU54aUIvVTFXUDNIYWY2VllFaXVy?= =?utf-8?B?eUNhdStRUGFQR0hkaUdZZWpDck8waXNYTlFZQlFOeTdmYzJLWnBXcWc5STNl?= =?utf-8?B?WTlxUUR0YnUxeDg0V2liaXJta2ZJOFdObVBZL0IvQmVoWTAxV2Z4by9IamRD?= =?utf-8?B?SkpNRHg5elBYR29MeFRVLzVnaWg1aWdVWVBUNlVMcEtPbWNkTzJUT0VxZk9Q?= =?utf-8?B?b3VPTDdJbVp1dEdlaDUvRVVTZG16WlQyUkJZdVJod0tTVGJMcTFzOW44RlY3?= =?utf-8?B?S3hjUnlEdUEvenVqeE0rTEJYb2h3VTBWTTRUTVQyYkFpWVhLak82S3hSYmZO?= =?utf-8?B?SHZ5ZVdsN1Y5L01ORjh1RHV3L2dUZ3FhM1RZRFhwQ2h4eVN0aXRnaXZaZzIx?= =?utf-8?B?M3dKOGpPdmprL3dDWkkyZCtjcVljSjZ2QmtyY1JVd095aElJSlVsS3M0ands?= =?utf-8?B?eTZGcndKOUNZQkNkV2JRZEpXQWpaVHNmR1JTaCsrUlJIQ1RKS1IvU2NXdGt0?= =?utf-8?B?UVA2dkZQWXJGSi9vSTR6cFhOMkxSSmtMQWpVTW1wU0xWd2xaUENacGZpSmxr?= =?utf-8?B?YmFuWE5zdHRoeFN1WkZBZUplUVZTdjVqeFN0cWU1b25HYTdUNURLU1VZZjZk?= =?utf-8?B?Zk9Zc0hvVlRyYkJHbXN5V1Z2VDE4ek1MVCtNaytDTmtyRjFSb0Mzb2JCUjJ6?= =?utf-8?Q?5w8fmFlZuig+cj9c=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <53E85B772EDF04468DC025755CC27D73@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1dff950c-8dc8-4f9e-a32f-08df248cfedc X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 16:06:49.9289 (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: BnzBBWNO+5JizOv6DNlTxxKKM2PgHo6TWMFj888uinNMWWj1HjlgRafUPlduVAJxLQEmmP76fuxPhISAyqsi8FzAGr/tdWI3iH1Y4D5/zKc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB618890 X-purgate-ID: tlsNG-16d1c6/1791389213-FE27077B-37E24A42/10/78276251493 X-purgate-type: spam X-purgate-size: 1964 DQoNCk9uIDkvOS8yNiAxNTo1OSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IFdoaWxlIGNhc3Rpbmcg dG8gcG9pbnRlciB0eXBlcyBtYXkgYmUgbW9yZSBuYXR1cmFsIHRoZXJlLCB0aGUgc3VidHJhY3Rp b24NCj4gdGhlbiBlbmRzIHVwIHZpb2xhdGluZyAiU3VidHJhY3Rpb24gYmV0d2VlbiBwb2ludGVy cyBzaGFsbCBvbmx5IGJlIGFwcGxpZWQNCj4gdG8gcG9pbnRlcnMgdGhhdCBhZGRyZXNzIGVsZW1l bnRzIG9mIHRoZSBzYW1lIGFycmF5Ii4gVXNlIGxvbmcgYXJpdGhtZXRpYw0KPiBpbnN0ZWFkLg0K PiANCj4gTm8gZnVuY3Rpb25hbCBjaGFuZ2UgaW50ZW5kZWQuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5 OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IC0tLQ0KPiBEZXBlbmRzIG9uICJF Y2xhaXI6IHJlbGF4IGxvbmcgPC0+IGZ1bmN0aW9uLXBvaW50ZXIgY29udmVyc2lvbiBkZXZpYXRp b24iDQo+IHRvIG5vdCBpbnRyb2R1Y2Ugb3RoZXIgdmlvbGF0aW9ucyBpbiB0dXJuLg0KPiANCj4g LS0tIGEveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jDQo+ICsrKyBiL3hlbi9hcmNoL3g4 Ni9wdi9lbXVsLXByaXYtb3AuYw0KPiBAQCAtOTIsNyArOTIsOCBAQCBzdGF0aWMgaW9fZW11bF9z dHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1DQo+ICAgI2RlZmluZSBBUFBFTkRfQlVGRihiKSAoeyBt ZW1jcHkocCwgYiwgc2l6ZW9mKGIpKTsgcCArPSBzaXplb2YoYik7IH0pDQo+ICAgI2RlZmluZSBB UFBFTkRfQ0FMTChmKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgXA0KPiAgICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gLSAgICAgICAgbG9uZyBkaXNwID0gKHZv aWQgKikoZikgLSAoc3R1Yl92YSArIChwIC0gY3R4dC0+aW9fZW11bF9zdHViKSArIDUpOyBcDQo+ ICsgICAgICAgIGxvbmcgZGlzcCA9IChsb25nKShmKSAtICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBcDQo+ICsgICAgICAgICAgICAgICAgICAgICgobG9uZylzdHViX3Zh ICsgKHAgLSBjdHh0LT5pb19lbXVsX3N0dWIpICsgNSk7ICAgICBcDQo+ICAgICAgICAgICBCVUdf T04oKGludDMyX3QpZGlzcCAhPSBkaXNwKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXA0KPiAgICAgICAgICAgKnArKyA9IDB4ZTg7ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gICAgICAgICAgICooaW50MzJfdCAqKXAgPSBk aXNwOyBwICs9IDQ7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQoNCkxHVE0u DQoNClJldmlld2VkLWJ5OiBEbXl0cm8gUHJva29wY2h1ayA8ZG15dHJvX3Byb2tvcGNodWsxQGVw YW0uY29tPg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 16:14:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 16:14:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442549.1660101 (Exim 4.92) (envelope-from ) id 1xEUHb-000302-QY; Wed, 07 Oct 2026 16:14:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442549.1660101; Wed, 07 Oct 2026 16:14: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 1xEUHb-0002zu-NA; Wed, 07 Oct 2026 16:14:19 +0000 Received: by outflank-mailman (input) for mailman id 1442549; Wed, 07 Oct 2026 16:14:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEUHZ-0002z0-U8 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:14:17 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEUHZ-001i6y-1O; Wed, 07 Oct 2026 16:14:17 +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 1xEUHZ-003XMO-0L; Wed, 07 Oct 2026 16:14: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=wyyl9UAOzk73xXmM5mfnr7RlHBErYaRJAGrqdTLMHKY=; b=ojvH39jRu28XUEDTV2jPEHrKae Y7yuh4xZVCxvfeMTU4zdemzOiKFBkEuBHzUNfyLjSBDeAV3OrK6jQKm4BqqSaWUcsHEy6KASxds5J N2ctFcnl3ot/xM1Ix3gARC4SmEq5XE6BCBkqkb1+GF9N8nz2y6q7v4Cn+kfHzSt7sxaQ=; Date: Wed, 7 Oct 2026 18:14:15 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 04/18] x86/domain_page: drop redundant create_perdomain_mapping() call Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-5-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-5-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:37AM +0100, 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 > 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 populating 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. > > In debug builds, and on hosts with memory hotplug or with more memory > than the PV directmap covers, the call was also what first allocated a > PV domain's per-domain L3. Release builds on other hosts already > allocated it only with the first vCPU. > > Drop the call; now we always allocate only with the first vCPU. > > With the only fallible operation gone, mapcache_domain_init() becomes > void, and arch_domain_create()'s error handling for it goes away. > > The per-domain-mapping work in mapcache_vcpu_init() stays where it is > rather than moving into mapcache_domain_init() along with this change, > ready for a later patch which introduces per-vCPU mapcaches. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 07 16:32:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 16:32:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442561.1660110 (Exim 4.92) (envelope-from ) id 1xEUYg-00061j-7Z; Wed, 07 Oct 2026 16:31:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442561.1660110; Wed, 07 Oct 2026 16:31: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 1xEUYg-00061c-3x; Wed, 07 Oct 2026 16:31:58 +0000 Received: by outflank-mailman (input) for mailman id 1442561; Wed, 07 Oct 2026 16:31:56 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEUYe-00061W-U4 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:31:56 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEUYe-001iQE-21; Wed, 07 Oct 2026 16:31: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 1xEUYe-003hbh-10; Wed, 07 Oct 2026 16:31: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-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=x151EDjMbL+Rnk3egyIDcF1TYhS8M+FaW6V0IbaysBc=; b=Cx0pk1eGZrQR7KzatBzjhYgblQ 7Jdn7AYZ9gtODoLs4fC+VCYRHfPD1sh9aD8yV5x3GsPhH/Od06sGbriBPFwWSCqm5H+X5gn5u4G1A G2bW/vBUhPQjgEDF/mV7Cf/DW1TPJJv3gBetVnzXRTR1JHXitNSjLBa4pPLVBYc0lsLU=; Date: Wed, 7 Oct 2026 18:31:53 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 05/18] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-6-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-6-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:38AM +0100, 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 > 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 before any page > tables referencing it are built. vCPU creation is > where the call must end up; move it there directly. I think it's clear from the paragraph above the call must be moved there, there's likely no need to re-iterate that fact. > 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. Even then - we will still need to support non-ASI (PV domains) not using a per-vCPU slot, and hence the call can't be moved as-is just when per-vCPU support is available? > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - Rebased onto staging without the GDT/LDT conversions (for the > HVM-only series): the capture parameters stay, as the PV GDT/LDT > stash still uses them. > > 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 | 3 ++- > xen/arch/x86/pv/domain.c | 2 +- > xen/arch/x86/x86_64/mm.c | 2 +- > 7 files changed, 18 insertions(+), 12 deletions(-) > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index 85cedc3d03..b670cea52b 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. I think the comment here is not very useful - it's not helpful that the comment here references the previous position of the call. It only makes sense in the context of this change, but not for someone looking at the code after this commit has landed. I would terminate the commit at the ":". The code itself looks good to me. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 07 16:52:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 16:52:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442576.1660118 (Exim 4.92) (envelope-from ) id 1xEUsa-0000zt-Qh; Wed, 07 Oct 2026 16:52:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442576.1660118; Wed, 07 Oct 2026 16:52: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 1xEUsa-0000zm-Ne; Wed, 07 Oct 2026 16:52:32 +0000 Received: by outflank-mailman (input) for mailman id 1442576; Wed, 07 Oct 2026 16:52:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEUsZ-0000ze-Kw for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 16:52:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEUsY-001ilx-17; Wed, 07 Oct 2026 16:52: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 1xEUsX-003wLb-3A; Wed, 07 Oct 2026 16:52: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-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=WkLWYu0cut+Xr8em7bPgsjYyZjyggw1577LGo/Ir+bo=; b=RWEwMefFWl4Qkke0v+OSMe/IhW 2atYEVrlZ0v7g6q1ei3lumqvQRq0usrvfOP22mI3a/oadXH3RP+T4O2f7i9cxZ2fqFqICsgwQs8Mu M7K60vexzuJlfHLM8JUg4IVW4nwtV8uOPTg0br97Gz9cDr2uL5XvobWmguhsv9xm2Trg=; Date: Wed, 7 Oct 2026 18:52:27 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , Teddy Astie Subject: Re: [PATCH v3 06/18] x86/spec-ctrl: introduce Address Space Isolation command line option Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-7-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-7-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:39AM +0100, George Dunlap wrote: > From: Roger Pau Monné > > Introduce the `asi=` command line option, and the > opt_vcpu_pt_{hwdom,hvm} knobs plus the per-domain d->arch.vcpu_pt > setting they control. 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. I would possibly avoid using "taint" above, as we have a taint mechanism and it might create confusion in the context here. Using ASI doesn't taint the hypervisor. > > The mechanisms this option controls apply to HVM domains: an HVM vCPU > already runs on its own monitor table, so a per-vCPU per-domain area > needs no work at context switch. d->arch.vcpu_pt is therefore only > ever set for HVM domains, a PVH hardware domain included; PV domains, > a PV hardware domain included, are unaffected. > > The boot log gains "ASI features for ..." lines for Dom0 and HVM > domains, so hardware-domain-only configurations remain visible. > > 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, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - HVM only: drop the PV knob and its interaction with XPTI. vCPU-PT > applies to HVM domains and to a PVH hardware domain; the Dom0 boot > log line says None for a PV one. > > Changes in v2: > - Added to the series > > Changes since the previously posted version: > - Include the hardware domain in the development warning and the boot > log summary. > - Make the opt_vcpu_pt_* knobs plain booleans preinitialised to false, > dropping the late -1 resolution. > - Documentation: mention possible protection against unmitigated > attacks, and state that hvm= does not affect the hardware domain. > - Rewrite the commit message. > --- > docs/misc/xen-command-line.pandoc | 26 +++++++++ > xen/arch/x86/include/asm/domain.h | 6 +++ > xen/arch/x86/include/asm/spec_ctrl.h | 2 + > xen/arch/x86/spec_ctrl.c | 79 ++++++++++++++++++++++++++++ > 4 files changed, 113 insertions(+) > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index b2c94ae56d..785e099c0a 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -202,6 +202,32 @@ 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) AFAICT the sparse direct map series contained support for ARM also, I assume this is being dropped from the content pushed (at least in this round). I think we will possibly duplicate the "asi" command line option between architectures? > +> `= List of [ , hvm=, vcpu-pt= | vcpu-pt=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. > + > +The mechanisms currently implemented apply to HVM guests, including a PVH > +hardware domain. PV guests, including a PV hardware domain, are unaffected. In the above you mix "guests" and "domains", I would rather use "domains" consistently: "... apply to HVM domains, including a PVH hardware domain ...". Same for the instances below. > + > +* `hvm=` enables the features for HVM guests other than 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` gives each vCPU its own per-domain area: the per-domain slot of > + each vCPU's monitor table maps a region private to that vCPU. > + > ### asid (x86) > > `= ` > > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h > index c32dec793a..b192c86bc1 100644 > --- a/xen/arch/x86/include/asm/domain.h > +++ b/xen/arch/x86/include/asm/domain.h > @@ -477,6 +477,12 @@ struct arch_domain > /* Don't unconditionally inject #GP for unhandled MSRs. */ > bool msr_relaxed; > > + /* > + * Give each vCPU its own per-domain area (HVM only: each vCPU already > + * runs on its own monitor table). > + */ > + bool vcpu_pt; Do we want to place this inside of an "asi" structure, and possibly make it a single bit bitfield? I think we expect to add more boolean ASI related options, so might be nice to have them packed together, ie: /* Fine grained ASI related options. */ struct { bool vcpu_pt : 1; } asi; Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 07 17:09:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 17:09:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442584.1660128 (Exim 4.92) (envelope-from ) id 1xEV91-00039J-4y; Wed, 07 Oct 2026 17:09:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442584.1660128; Wed, 07 Oct 2026 17:09: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 1xEV91-00039B-1X; Wed, 07 Oct 2026 17:09:31 +0000 Received: by outflank-mailman (input) for mailman id 1442584; Wed, 07 Oct 2026 17:09:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEV8z-000395-Ky for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:09:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEV8y-008nCJ-WA for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 19:09:29 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac67cbb-e002-0a2a0a5209dd-0a2a4506a7a4-32 for ; Wed, 07 Oct 2026 19:09:28 +0200 Received: from [40.107.130.79] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac67cc8-195a-0a2a45060019-286b824f34da-3 for ; Wed, 07 Oct 2026 19:09:28 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 17:09:24 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.015; Wed, 7 Oct 2026 17:09: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=jxa5SaopmgIf50+28UcDQqo5veFlBzfIpYVVbxUY9aF8+jtpZTDd57ll2E6SkARl8QoW45IQdlG483nmfTuliyB0xE02ub6rnrtttWugtdbBHOeWXV3/MY8Tu3lDTOf7kxboiDi813JvMO0neVzlWw0J2cn2YyEyGJCDQ/QCVnT6Q/SoDKkh0441TzgUtBF5lP9RSaI2QsxqTL/bVjCfABNMjG/kA0kpy2stozgxfL0vJ2ap7CDxP8uikp4ez5ZPf/qyHHfFltNQu9SdAN3XF5CCq+y77WH1eFym9N9wqn7oJ9J+VsGRJclTfYxJAsEQDKKwv4svRUhLCVMGWaPO2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w4p6tVk0AAfZ2qiQHiUWiyFlFnENM70hfHdz8Z4lSV4=; b=Uu/MOgj1pcBIGN+4Mgl7Ud7alAmDQUzWwx8gwAz1mRcESTAPQ+2vc96p8cft5YcAmM3vv0rFgGA20NqTZgdXErYT8OzZlLgPgRuAosceUviaKLjBwmRKGOz1uzeQdhF+DO1qH+CAvRRZSt9s3RJSEdyOVcXschTsMUlyFsNfxW94xS3ig5col5JWjhhY8EGaPPLns+IVQOrCrJ4jMklawECY5cZSe8PdkZ9fobtQtwTPiFrKmSar1jtU+wdIV070e5E8VMEXub+9FE4IKypc0GHs1iGJRm5vk0/LhP8+LYvPa5PxK1UvyaaGTgEL/F9l+K9qqgR3IFb26qsFswGZSw== 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=w4p6tVk0AAfZ2qiQHiUWiyFlFnENM70hfHdz8Z4lSV4=; b=t75R+Zs7hNWqfX5Zbxo5+pbuIdp9/wDxDrP5entLbQRkFca6QjFAaJhYoHWrcfN+7QopIyjqlgkwuo+TnrwhxH4+uf+ua0gAsfdZVODn49wpT58hXODrtVL4h8fbJlSCnhOFAHX3wSBgB3oAsj40/6JbJdMx16inGfxWGH8yW42rB7inAVkkRUfsTTtJDMIRrNXSftguTm+LYzdCkHcvAhRTWR/N72wdhgzzSd6HPEONb8fUhfFhA29eXb73Ui1s9AqQVUGKcStB5HlPhoblhBzYJT9yX16WzTUjg/T/QIAzsjUE3YptzvEZH3MSD+1LtKHaOtfmmkWn1Ox8Sd7C4Q== From: Dmytro Prokopchuk1 To: Jan Beulich , Nicola Vetrini CC: Doug Goldstein , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH] Eclair: scan the last xen-syms linking pass on Arm Thread-Topic: [PATCH] Eclair: scan the last xen-syms linking pass on Arm Thread-Index: AQHdVZ47rgN8qfc/LUyZracn12XLU7bwnI6AgAASYQCAAOP3gIAAL16AgACPsoA= Date: Wed, 7 Oct 2026 17:09:24 +0000 Message-ID: <8e6cf8dc-7b93-4dba-b290-d41858a6fec8@epam.com> References: <2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro_prokopchuk1@epam.com> <03338d69-cbde-4918-8ffd-c309230d337f@suse.com> <8d3b26df-a42a-4d34-bc6c-81ed26839006@epam.com> <22ed9e39767c74e820e964acc2e32a32@bugseng.com> <7cadeebd-3ba7-4d8e-9874-aa5f4aeef93e@suse.com> In-Reply-To: <7cadeebd-3ba7-4d8e-9874-aa5f4aeef93e@suse.com> Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|AS2PR03MB8907:EE_ x-ms-office365-filtering-correlation-id: ba710202-63be-4772-efbd-08df2495bcb7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|42112799006|1800799024|23010399003|260925022911599003|56012099006|4143699003|260925021911599003|11063799006|4133799003|10067099003|6133799003|260925021311599003|5023799004|22082099003|38070700021|18002099003; x-microsoft-antispam-message-info: K6bzG3i0JVcVdZTSBChsKkYe0aHDGlNH8WL7AO+8swewDpBOLuciTbMLmXKAGNdFp0x4XBt1W6XUmGyyG6TnKEpEBazQoff9HgptZMCdIeTxW3n8xmlJ0rt/m6xNyk1qclnMUaMk1knDdBaS+nSD5S+hFb8Tm73UMq/ijmFeS5ss58zWUABSFG8va16cw65Vw30kb3kr1ox68XNSzW0JvwnxV7X0Mx0Qmrf8IkUwUWy8iSiBukYK/m+dRCdje7ojbf4tMDws6nevpw0pvbvzdpKTYK6/Ts+fAjElnEUo4fp3C14fFJ9hNi0SRB2JxPgMooqXARYVgLQEDprfkE38TdglVCtQ480WCGih2+jMDp8gX80pLJiLRvJ1nPMZ6CJSWcxxDTgfQ9TNIh0uB6eSG3zbGyl1P71Gs121C08dqo2oWKJ3Z9IHS2yn07fbpxmByigx/Mb6vvWkXF8nkuj13NflN/AL07NhChgd0FyhufqJaACJUCYPKwsA9KvWVvEiuRrdKVru5JR7/wJia7cx8hr0mGa7j6SWFBdjq+Ui92sqkZsopJ30hWTOpKNOy4sruojLi+MvXOSkobQRRN87taO4eSnVlXyXp8287YqsjHVfnr5wkSlfUUY6cQ2+Hg7yvxs+3pdRo1YWxk0Gd89iQkhiZEKherFbh6YjK78QKeZHV1AtHef9WQiwVDyjKG/8 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(42112799006)(1800799024)(23010399003)(260925022911599003)(56012099006)(4143699003)(260925021911599003)(11063799006)(4133799003)(10067099003)(6133799003)(260925021311599003)(5023799004)(22082099003)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ci94UFBRQlR0alJFZWg5RFJmWWp6cGExalp6TUVuUHd3R2tiSmhFM0ZydnU2?= =?utf-8?B?VVdTdmorVFJwb3NpQUo5dnoyZ1QzWHRxeFRCK2VVTWovNldEYTZtUnkrblNV?= =?utf-8?B?SzJ6Wm84SjNMcGI4clpmK1MyNXJnZzdIZ01VOFFiQm5VOFhUVCtVTDdvaHRP?= =?utf-8?B?OHhJaU5tUEdGQUZCejhVNjEvbjhQZ3FZVjc0Wnp4RFdwTjB2Lyt3Y1BxSHlE?= =?utf-8?B?RTBvQ1N6dTlMK1liaVNnc3JRRFRST2xjTldkTkFlaXNuUm85bGJ3TXhMYXpp?= =?utf-8?B?WWZWMEduQ1YxdkpBMndZWGtyZnRIYzlFVURYV3NPZFd1ZnJYNkF5by9LYkFz?= =?utf-8?B?WGY3N1d3N3JIMk82QUM4YVlyZ2tITnNtSzh3bkR2d0V1WmJuc1ZpekVzcEVM?= =?utf-8?B?cExCeSthWjhrZnBVVk0yQ1VSay9LYTZJSXFNakd0SWZqdzRmSW5ISFdpT0pq?= =?utf-8?B?azRpd2lmeWpJY2l4T05PUFgrV0h0d2dLV3hhcWdUU3FIaFpSU1R6eGJ4TGY0?= =?utf-8?B?OG9sb050eXpWSDErbEhpVnp6RGUxazdPL3U3aThWcWdMZ0xTdEVCNHdtaTgx?= =?utf-8?B?akN5eXVpSjl2OWhNNytjanRPWVBLbC9penhNZjByblMxeDYzMFRKVUo1d2RP?= =?utf-8?B?V1BvVWZPQnJkdGgrdmdBczYyQ3pkNkhIYTNqcmVPWG9DMytrQ1RnbDZaMDkr?= =?utf-8?B?WW1idE82Zy9TSGE1ZjY2V1BsbURkYXlHTkQyOVhHVGdRRTlwaHdWTUZDQ2h6?= =?utf-8?B?SkJCV1FFWUNLSzlpak0ySUpHZGtOVXcwWmRxbHRVdkpGQUpIQjZvekwrNDhY?= =?utf-8?B?a1JsS1FIajlSejIvNUorY25nckdCTXpxMnhONHBYamJyM05mWFVJa2gvWVZv?= =?utf-8?B?VGhzWTJpdmJpK3hGVmZ3TUl4MDdXYkJibzJuMmFaUXNGSGVhV2VpNFJaajhN?= =?utf-8?B?T3NYR2I0dDV6akdoVDZpckF5QkUxMENJTkNzK1l3bVl5VVU2TjJtaFlxZ3I0?= =?utf-8?B?RktIQUI1SHpZVmhoc0ZTVWZCSG4xUEZsWXVDRVBZTGt6MnhnMzhncm1RT3hI?= =?utf-8?B?TXMveEdvUFZRTU0vd1NwUWNKd0kvSll4TWliajdVTFZLQWhrNm8rWWQ4cldR?= =?utf-8?B?QjhlbzZ6Zmx5eVJkeHV4VktjY0JHdDU1Nld1UkN5U0lwaFl5YlVJU3NleVZR?= =?utf-8?B?UFYrbm5tcTF2d3JGVnN4SG4yclpIQ0ppeGd4RXgwa0dYTHlKQnNmQ3czQWFE?= =?utf-8?B?RCtLUlJSQ1hRUkdMWjhOZ2IwOEpvZTI0QWw0NnFlWlplQ0d6WWdEQXE1K1NZ?= =?utf-8?B?WXdUbWNJdFdQWnZBbXJSZE9JaXZtMVBwY3JkZW55ZVBvTEpSOTlEU2c3TC9X?= =?utf-8?B?Tlk3eGF0aWd1M3lja1krUE5NZWVuY092Y1d4aXVwYVpiUnBnYmx6NmEwZmlB?= =?utf-8?B?UlpMRXVPTi9KRzNvL1VEY1hUbVp1WmpSRkI4d3VkYWsveDMxekhUejN3ejlX?= =?utf-8?B?UUxNV1cwSHdDZjZGN2tHQkhNNHJQSzRpQjd1R2xoajdycC9xYUJ1bFMwdDR2?= =?utf-8?B?Q1NvRTNpdUpGdVRpRGZXYTNJZElyL1NwMFNZTHd6NlFqR2RaVzEzNVhGNGVp?= =?utf-8?B?TXJLbmVua3pzUkRBNnZOMCtBWjVWcFZLaWdFY3BzRWRpZjI1L29ETE95MURm?= =?utf-8?B?QkIvdTU4b25jMFRMd0xUVVdDbEFCSVFUSXN2RWdtdEtZNlRDOFYrcHRqREF4?= =?utf-8?B?UHFDVnlSTENVR1dpdk5XT0IzVTJtRXp5c1huc29JSlVPZTVTZUhBVGRKTStC?= =?utf-8?B?V2wwUFlwVkJ5K2hBbXhpY3RWcTVGNFFsbmpyNktCSVZjN1QvbWcwbWUrOU1k?= =?utf-8?B?Rk5sc0RiY3Rub2hPTzhaZkV4L0VTc1QyRUpBOWlCcDZxRUtmQkdWVnlPajUz?= =?utf-8?B?L3YreGh1WjU5TGhyRVVwZCtCcjEvR2lyZjM0ODU5bWFpM2VPbEpUTUxoMDlY?= =?utf-8?B?ckRGWTAyQU5VdHFQQWIwNTJuVmY3STFNQVNJcTJ1MUxVNjMwZDg1WGt6OG1y?= =?utf-8?B?anI3UE1Fd3YwbFZFTUYzRHpWbENBWTdWU2dDaUNSVGk5Y2l3czFhSFlsZWJI?= =?utf-8?B?TWxhNWpmaEovOFFSTVpzd0tYT05kVDRraUZ5QmpCbjAweUpYZy9iTngwcXdk?= =?utf-8?B?QjNaeTgxRmtBR20xajRndGFuaWtVN0ZQV3RlLzh6V0YxclVRcG9kYzBYV1JZ?= =?utf-8?B?Yk9vNVNqOWdDRFpmdkxQRDhqNWtCS1JUWnFIKzVCQkJQOGx0blhhVU9McVlq?= =?utf-8?B?dGVLLzk2NmRsZ2xnV3I2ekNaTGNkNHZEUlFXeXRWYnVTZXNyZzdSUkY2RDY1?= =?utf-8?Q?iC0W3RS5Ex9y/8Gw=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <48DB5EC13BD6B84F93DFC05EF0707B12@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba710202-63be-4772-efbd-08df2495bcb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 17:09:24.4170 (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: Y/S5o0w0PIF+TWOFgKYu+NDrMEYdWkuOQY2CObdV8buLB6JzMODDFzCVdQwzhxfL+xcYjixxh7nrZ0iYCaSd5H7vAzylUdhV/Khoodtfz0E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB8907 X-purgate-ID: tlsNG-16d1c6/1791392968-FEC7777B-ACB5E0F8/0/0 X-purgate-type: clean X-purgate-size: 4504 DQoNCk9uIDEwLzcvMjYgMTE6MzUsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNy4xMC4yMDI2 IDA3OjQ1LCBOaWNvbGEgVmV0cmluaSB3cm90ZToNCj4+IE9uIDIwMjYtMTAtMDYgMTg6MDksIERt eXRybyBQcm9rb3BjaHVrMSB3cm90ZToNCj4+PiBPbiAxMC82LzI2IDE4OjAzLCBKYW4gQmV1bGlj aCB3cm90ZToNCj4+Pj4gT24gMDYuMTAuMjAyNiAxNjoyMywgRG15dHJvIFByb2tvcGNodWsxIHdy b3RlOg0KPj4+Pj4gSGlkaW5nIC54ZW4tc3ltcy5bMDEzXSBhc3N1bWVkIHRoZSBhbG1vc3QtZmlu YWwgaW1hZ2UgaXMgYWx3YXlzIHBhc3MNCj4+Pj4+IDIuDQo+Pj4+PiBPbiB4ODYgTEFTVF9MSU5L SU5HX1BBU1MgaXMgMiwgc28gLnhlbi1zeW1zLjIgc3RheXMgdmlzaWJsZS4gT24gQXJtDQo+Pj4+ PiBMQVNUX0xJTktJTkdfUEFTUyBpcyAzIGFuZCB0aGUgZmluYWwgaW1hZ2UgaXMgLnhlbi1zeW1z LjMsIHdoaWNoIHdhcw0KPj4+Pj4gaGlkZGVuLiBQYXNzIDIgaXMgdXN1YWxseSBvbmx5IGEgc3lt bGluaywgc28gRWNsYWlyIHNhdyBubyBwcm9ncmFtDQo+Pj4+PiBsaW5rDQo+Pj4+PiBhbmQgcmVw b3J0ZWQgZXZlcnkgdHJhbnNsYXRpb24gdW5pdCBhcyB1bnJlYWNoYWJsZS4NCj4+Pj4NCj4+Pj4g V2hlbiBJIGRpZCB0aGF0IHdvcmssIHJ1bGUgMi4xIGVuZGVkIHVwIGNsZWFuIGZvciBib3RoIEFS TTY0LSoNCj4+Pj4gYW5hbHlzaXMNCj4+Pj4gam9icyAoaWlyYykuIFVwb24gcmUtY2hlY2tpbmcg SSBub3cgc2VlIHRoYXQgQVJNNjQtYW1kIGhhcyAxNzcNCj4+Pj4gdmlvbGF0aW9ucw0KPj4+PiAo YXBwYXJlbnRseSB0aGF0J3Mgd2hhdCB5b3UgdGFsayBhYm91dCBhYm92ZSksIGJ1dCBBUk02NC1h bGxjb2RlIGhhcw0KPj4+PiBub25lDQo+Pj4+IChodHRwczovL2dpdGxhYi5jb20veGVuLXByb2pl Y3QvaGFyZHdhcmUveGVuLy0vcGlwZWxpbmVzLzI5MTY1NjkyMzIpLg0KPj4+Pg0KPj4+Pj4gU3Rv cCBoaWRpbmcgcGFzcyAzLiBQYXNzZXMgMCBhbmQgMSByZW1haW4gZXhjbHVkZWQuDQo+Pj4+DQo+ Pj4+IFRoaXMgd2lsbCBjYXVzZSBzY2FubmluZyBvZiBib3RoIHBhc3NlcyAyIGFuZCAzLCBpLmUu IGNvbnN1bWUgbW9yZQ0KPj4+PiB0aW1lDQo+Pj4+IGFuZCByZXBvcnQgZHVwbGljYXRlIHZpb2xh dGlvbnMgd2hlbiBib3RoIHBhc3NlcyBhcmUgcmVhbCBsaW5raW5nDQo+Pj4+IHN0ZXBzLg0KPj4+ PiBJIHRoaW5rIHdlIHdhbnQgdG8gYmUgc21hcnRlciB0aGFuIHRoYXQsIHRvIHJlYWxseSBzY2Fu IGV4YWN0bHkgb25jZS4NCj4+Pj4gSQ0KPj4+PiBkb24ndCBoYXZlIGEgZ29vZCBpZGVhIGp1c3Qg eWV0IGhvdyB0byBhY2hpZXZlIHRoYXQsIHRob3VnaCAoYW5kIEkgd2FzDQo+Pj4+IHdvbmRlcmlu ZyBhbHJlYWR5IHdoZW4gcHV0dGluZyB0b2dldGhlciB0aGUgb3JpZ2luYWwgcGF0Y2gpLg0KPj4+ Pg0KPj4+PiBKYW4NCj4+Pg0KPj4+IEhtbQ0KPj4+DQo+Pj4gQXQgdGhlIG1vbWVudA0KPj4+ICho dHRwczovL2dpdGxhYi5jb20veGVuLXByb2plY3QvaGFyZHdhcmUveGVuLy0vcGlwZWxpbmVzLzI5 MTczNzU3NzMpIEkNCj4+PiBzZWUgQVJNNjQgUjIuMSB2aW9sYXRpb25zOg0KPj4+IC0gMTc3IGlu IEFNRA0KPj4+IC0gMjQ5IGluIGFsbGNvZGUNCj4+Pg0KPj4+IEFueXdheSwgd2UgY2FuIGhhdmUg aWYtZWxzZSBsaWtlIHRoaXMgKGNvcGllZCBmcm9tDQo+Pj4gYXV0b21hdGlvbi9lY2xhaXJfYW5h bHlzaXMvRUNMQUlSL3RhZ2dpbmcuZWNsKToNCj4+Pg0KPj4+IC1zZXRxPXRhcmdldCxnZXRlbnYo IlhFTl9UQVJHRVRfQVJDSCIpDQo+Pj4gaWYoc3RyaW5nX2VxdWFsKHRhcmdldCwieDg2XzY0Iiks DQo+Pj4gICAgICAgZmlsZV90YWcrKHsieGVuX3N5bXNfdG1wIiwgIl54ZW4vXFwueGVuLXN5bXNc XC5bMDEzXSQifSksDQo+Pj4gICAgICAgaWYoc3RyaW5nX2VxdWFsKHRhcmdldCwiYXJtNjQiKSwN Cj4+PiAgICAgICAgICAgZmlsZV90YWcrKHsieGVuX3N5bXNfdG1wIiwgIl54ZW4vXFwueGVuLXN5 bXNcXC5bMDEyXSQifSkNCj4+PiAgICAgICApDQo+Pj4gKQ0KPj4+DQo+Pj4gXl5eIHRlc3QgcGlw ZWxpbmUgaXMgaGVyZToNCj4+PiBodHRwczovL2dpdGxhYi5jb20veGVuLXByb2plY3QvcGVvcGxl L2RpbWFwcmtwNGsveGVuLy0vcGlwZWxpbmVzLzI5MTg1NzE3NDkNCj4+Pg0KPj4+IEJSLCBEbXl0 cm8uDQo+Pg0KPj4gSW4gdGhlb3J5IHdlIGNvdWxkIGV2ZW4gZ2VuZXJhdGUgYSBjb25maWd1cmF0 aW9uIGZpbGUgb24gdGhlIGZseSBqdXN0DQo+PiBiZWZvcmUgaW52b2tpbmcgbWFrZS4gU2VlIGUu Zy4gWzFdIGFuZCBbMl0uIEluIHRoaXMgd2F5LCB3ZSBjYW4NCj4+IGRldGVybWluZSBwcm9ncmFt bWF0aWNhbGx5IHdoaWNoIGlzIHRoZSBsaW5raW5nIHN0ZXAgdG8gY29uc2lkZXIsIHNpbmNlDQo+ PiB0aGUgbG9naWMgaW52b2x2ZXMgc29tZSBjb25kaXRpb25hbHMgaW4gdGhlIE1ha2VmaWxlIHJ1 bGVzLg0KPg0KPiBIbW0sIHllcywgdGhhdCBsb29rcyBwcm9taXNpbmcuDQo+DQo+PiBJbiBhbnkg Y2FzZQ0KPj4gaW50ZXJjZXB0aW5nIG9uZSBtb3JlIGNvbW1hbmQgdGhhdCBpcyBqdXN0IGEgc3lt bGluayBkb2VzIG5vdCBpbmN1ciBpbiBhDQo+PiBiaWcgY29zdDogb25seSBpZiB0aGUgaW50ZXJj ZXB0ZWQgc3RlcCBpcyBhbm90aGVyIGxpbmtpbmcgY29tbWFuZCB+NQ0KPj4gbW9yZSBtaW51dGVz IGFyZSBuZWVkZWQuDQo+DQo+IFlldCB0aGF0J3MgYW4gaXNzdWUsIGF0IGxlYXN0IGFzIGxvbmcg YXMgdGhlIGFuYWx5c2lzIGpvYnMgZ2VuZXJhbGx5DQo+IGRldGVybWluZSBwaXBlbGluZSBvdmVy YWxsIGxhdGVuY3kuIFBsdXMgd2l0aCBjb2RlIHNpemUgKGFsbW9zdCkgb25seSBldmVyDQo+IGdy b3dpbmcsIHRoYXQgdGltZSBpcyBhbHNvIG9ubHkgZ29pbmcgdG8gKGFsbW9zdCkgZXZlciBncm93 Lg0KPg0KPiBKYW4NCj4NCj4+IFsxXQ0KPj4gaHR0cHM6Ly9naXRsYWIuY29tL3hlbi1wcm9qZWN0 L2hhcmR3YXJlL3hlbi8tL2Jsb2Ivc3RhZ2luZy9hdXRvbWF0aW9uL2VjbGFpcl9hbmFseXNpcy9F Q0xBSVIvZ2VuZXJhdGVfZWNsLnNoP3JlZl90eXBlPWhlYWRzDQo+PiBbMl0NCj4+IGh0dHBzOi8v Z2l0bGFiLmNvbS94ZW4tcHJvamVjdC9oYXJkd2FyZS94ZW4vLS9ibG9iL3N0YWdpbmcvYXV0b21h dGlvbi9lY2xhaXJfYW5hbHlzaXMvRUNMQUlSL2dlbmVyYXRlLWxpbmtlci1zeW1ib2xzLnNoP3Jl Zl90eXBlPWhlYWRzDQo+Pg0KPj4NCj4NCg0KSmFuLCBOaWNvbGENCg0KVGhhbmsgeW91IGZvciB0 aGUgcmV2aWV3Lg0KU2VuZGluZyBWMi4NCg0KQlIsIERteXRyby4NCg== From xen-devel-bounces@lists.xenproject.org Wed Oct 07 17:12:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 17:12:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442591.1660138 (Exim 4.92) (envelope-from ) id 1xEVBo-0004gl-Jx; Wed, 07 Oct 2026 17:12:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442591.1660138; Wed, 07 Oct 2026 17:12: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 1xEVBo-0004ge-GT; Wed, 07 Oct 2026 17:12:24 +0000 Received: by outflank-mailman (input) for mailman id 1442591; Wed, 07 Oct 2026 17:12:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEVBm-0004gX-UO for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:12:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEVBl-0030VJ-Uf for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 19:12:21 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac67d67-2eae-0a2a0a5409dd-0a2a450ad4ec-46 for ; Wed, 07 Oct 2026 19:12:21 +0200 Received: from [52.101.65.101] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac67d75-f2d2-0a2a450a0019-3465416587d4-3 for ; Wed, 07 Oct 2026 19:12:21 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 7 Oct 2026 17:12:18 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.015; Wed, 7 Oct 2026 17:12: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=LbAkSKT1WFQi6uHDWaeq5nksjrAdWsctsQ93y2LucF8J0P7izu/K8Mwkv5egRZo2pnLBnPbSAQy7OKVgEhDKxVijsgOqKpYq8/ykXmS4aEO+xbEFnOUg1ONQmHM3Hhaf5ZmE1wJlOc08FQguxEY4Uf8yUQX7CyRcl2+s5zP4vhnsuYtrb0G6BCvoU/qdccIrsz3/6QtasXMCSoCk8VHTNYFN26JQQRRxxuxNepLADjorsC5Yte3Nn/Y+xGWugxcq0LVU5Cx2yAziNgFldxvi6SjNBHciRkiYZsMkoel3wehJiD/mxVB+huxbbeDFjXOWNvEjVR5bvldgJnlblyiy9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A8YOGnWnUtt3vkVfHxoh7qJ2JSo9ob0CIBbEG6hibYY=; b=oJFtDuCXX/7xPu9KtXdxBoSMTgw0HZ88ojAPjgPl/wjnFkRumMHJihAlui/hpA8AlZykbsL+Ng6mYEEPbwcJaVxgWaf/nto2z8jd9tAciXiXdiA5S9ssuNYRr7z96QgtPhNVtC5DrmiF7VUyZpytNjzMUqLwSXnCBvGws6veonGJMWVwzWgSmqO8rpJeuqsoWYMvcjuo8hsgKeuxNU4fSnzQef9GJpkosI5IjzUAytbjPipaetDY9sSU5J40ALgxiEYUmdng/UxRcN/KjtutprVS0aMqGXOoSaWC/DY/4GFuQm801BmNYOxHL89+FZjAiWtJsiDLBprVhdQCIpsz9Q== 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=A8YOGnWnUtt3vkVfHxoh7qJ2JSo9ob0CIBbEG6hibYY=; b=E5IN3yn3nXK4JxWQmNB5X7E9WmTQKAVA0zjUh9K5QDNvf8HpF3hggNMYd0ytGTkl90Cw17zmJ6UFOuwfF7UPjUOnMaMvd6DJTuyHsd8MAXyuy2tzzJUHeXAIg+UCKlcbmRwMPvn1nQgjZMOjBKVk0eK3yEHk7uHPL9OhOEw+FsqcJqPbEVibGpMjhTsAJml9w5iO6zm+UPzyTJk8vTJ5/NmBPJ7yA8nJ6dYxxj7TdMvOyTtcqI4XetA01owfUA0DoqzZgctfYxCFT0/TMMRNX/TcWhgjWNjS10QQQ+ZqCXqmc5aTXTKJHSqIWuXV8yJe6R+xDafp8+cOGPthubz01g== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini Subject: [PATCH v2] Eclair: scan the last xen-syms linking pass on Arm Thread-Topic: [PATCH v2] Eclair: scan the last xen-syms linking pass on Arm Thread-Index: AQHdVn8C9qte4lKYxEOXexEb5NUBWg== Date: Wed, 7 Oct 2026 17:12:18 +0000 Message-ID: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|AS2PR03MB8907:EE_ x-ms-office365-filtering-correlation-id: 98b65a35-36a3-4513-3c89-08df24962499 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|42112799006|1800799024|23010399003|260925022911599003|56012099006|260925021911599003|11063799006|10067099003|260925021311599003|3023799007|5023799004|38070700021|18002099003; x-microsoft-antispam-message-info: MwXuzeNvRFOR/lOa7uxD3X1J3U3O+cxeRy70PK3SW3eXp0E9PikDDNYGzMKps0VnOd77uQ4joMa4fMlxsfPv6cL8mB1MN/3thORCgCpQX5G/7+w0S2xQFwneEbeqQwTMONOgn4yQzuKes3XV6l0+y8HYJK5cW3fVG7m1h9sQdE5Pk/d31K/4+xjclk2dk/QWy47LAZIp4GwugIJPskBxK6Hc1y2EQdvXowYEtGXWjUkM6m6PT8EKL2uJdTA8dLBMa+cG6q2RwCRgPlKiFH6ccKJPscJDhLuMXaVcslLP/UlkUkjWNbLG2hebduluJ3xN6HiJ3PRVbwBj4eo+e9kRaHRhXNTTdGIsVNRiQp0lA/3+YdPnMLLJWL9sF7Z8vlIHFAhQoiw2JbB8Tdybj+ucrMHCPkI0oo+o1KaRO3n+/HlfIj6SKckGEE5b4oCK87+RDwwwTozVfzIELt/cRBTcWQePyPAtW1ghJrSJwVsYWAPbDoVbLdZGkLlLoPJ3VeW/TKPflFRk13+QZT2sHc8vuwY8TY3oRMa11afr79VJbbyzPLxCEqQXbAsw4BG//7AOW1VlC9+S9XaWt/vV/xVyJLS6XyhJwdAe1FpE+5hszqCAY8LmXRMOoJsyD8hi2vdSDG7WV2OGL68WF7e5IrRff643jU2wiDHFJjb3L6olQI4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(42112799006)(1800799024)(23010399003)(260925022911599003)(56012099006)(260925021911599003)(11063799006)(10067099003)(260925021311599003)(3023799007)(5023799004)(38070700021)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?b1FkcklWcHNxaHA1dVQxcXZGOVdiL0xsMUZjSUxXUzZrODFwbjR0Vm9mN2VE?= =?utf-8?B?Ykw5Y0Vhc09wOXBickw1WGYzQ2xRYmRvaFFSQjZ6SVVQcHovMFBMVW0raVds?= =?utf-8?B?dEhVaUFqUVBOdHJuSkN4empsbWZKdk1nTFcxcE95dEl1ejBPUlJ5Y29BZnZm?= =?utf-8?B?anp2NnphNGhHblRjdTBnOXh4RUtCaHB5cXI4TjMwSWZCK2NkK2pqRWNxenRs?= =?utf-8?B?MEd5RjQ0Q1F6QWVWY1ZtOUJXRGdlWThpbzZoQUJsUFRuUXAwN3N2eDAzMm5s?= =?utf-8?B?WnlsN0lqeDhSa1hxeks1ZHh5aHlZME0wSFUwaGd1SXp3aUZ0YkQrRVBBY0ds?= =?utf-8?B?QVFtS2VncTc3WkhsVG5oUjFSaWFzRjNUMGpiWm1uOFY2ZVF0bG9sd1ljREw3?= =?utf-8?B?NmlVU29KVFYzZnJ5QnpoaTRWcjR4ZEVLcUhENEl5Um5FcmtPcGhOcTJnSzNQ?= =?utf-8?B?WWt1b3VUWjloMGZDWFFzVlh1Zm41dEFBMWlRZWlnNXVib0NzeUY2ZjRUaTNG?= =?utf-8?B?eTB2MXRiUFM4MWxqTnErU0NoeE9aYnlnSzBENTdXQ2JjcnhNbDNWd1NoTVRB?= =?utf-8?B?dko4Z0EwbE1uWUZsTkdmeVdkeWMzN1QrMjBaWXZqU3VoTXRrOUhXbisrcjE1?= =?utf-8?B?ellENjMvVk9QYWJRNk5rQWNRSzhCend3bXNaL0ZlczV0bkhNTGFSNVNDdlpu?= =?utf-8?B?czZna1pHbi91TVJaMlJ0STRJanVZeHZpSm5OTzJOQTRlU0RmZ3E5NlMybUtp?= =?utf-8?B?VHZZVHdUenJVRUdUMEtaaVhRZGpOUUYxbGUzWGlZTTdxejc4WVRXUlFJWllI?= =?utf-8?B?NDBpWVNSQWJLcUFwdkNaU29abFZPK2lGRmlYTVQvWTZsNDQwN2dKS3BGSk5R?= =?utf-8?B?VFJpeU9uVnk1cFB0RUtyNjZNTjc5dXFSajVmcE1IRm1Pd01vYUtkVzVtNXZZ?= =?utf-8?B?RWFwckJVcFBzdExiOUdkZ0t2VkwrUitjKzl5UExFSy9mZ29IdXFNdFBDTmtT?= =?utf-8?B?V3d3VTFQaGxlanpxbjVjSFhmVE9pQTAwL3VkR0dnazVmMHpDZzdtTWJNclh5?= =?utf-8?B?ejQ2NjlKa1BxSGs3UHFuTkdvVmJ5WlJINXpWZ1pyZE53Y0FINFJKckh6bTFt?= =?utf-8?B?cnBRUkxkV2Z5VFRKVFZuUHdFaG9La25pbFBWanVSQ2dNTGthc3JobkVuMFBO?= =?utf-8?B?elIvZnE0ZzZydHlUc29wNHBWSlk3NGRKUjl5YkVGM01kblFLeTdaS0xHL1Zw?= =?utf-8?B?UTZNL3dUZElvQjdxU0ZiRElWRDlRWHBHb01DMk05K3pUSGhDMlk2a1ZJeTBI?= =?utf-8?B?cFBlRi85enNHU01YdGtHdmpITTZWZ1VuaXZaSWRKOXJ4N3ZYOU5QUjNSOGF1?= =?utf-8?B?T0J4UEh0Tm9uVlprYmhUeEROY1F6YnloeFAwbW5Pc0tqVTRBNnVmUThFUURz?= =?utf-8?B?UXRMRTFCTWg3UWtSTGQwOWRtOW1NbjBQTGtuL0xZZmlGeDBSZ3dsOTlJeG5S?= =?utf-8?B?SEE3ZFBUVzZrb1FMdEc5bmdweWtzUmhCeDRySVBUOTQ2WmR5TDJPNlpyK2hu?= =?utf-8?B?R1plN2Y1VmpWK2NVc0VCY0JmaGZRaDQySThiNmdxM05sOTl0OE1xSzRuSHNv?= =?utf-8?B?Q1QwQStuUWd5UkViMVE3NGF0Z2hRT3k5eVFEOVVyTFVJRFVkRGgxWWpmUmtW?= =?utf-8?B?MUxOR0x6elFzN1RxRzRIRmRXZlZuY2VxeDVsYitsaVhsaUFiamVtMW13WGRJ?= =?utf-8?B?L2pTSU9xZnJLaWlDMUVFL2poczRWZDVmR0RPTkRoYnFLSHNaYU5OeFEwamdT?= =?utf-8?B?L1EraElRZGVyVk1WWTVVQTBJdmdoenJjaWMrVnVtR3IzNTluZmx5RmxXaU5l?= =?utf-8?B?WVNscktteVhnZkxoVWIrSFlXMllSdkVFbzhMcmx6UjFEalgzQ0JUM21uWThj?= =?utf-8?B?c0VBTWFmNVQ0eWdGcW1uMTB1Q252ZHQzOFBKbmZFUis4SHlxdHFsSklRYTFh?= =?utf-8?B?dU5IenlyVURicXEvblNGZnBsRXl6bTV4TjlwS1ZCajZWT1VXUERvOTFkbzlE?= =?utf-8?B?ZWwrTDdycVliNEl6VzBQT212WUdmQjJRbkY5K0R4Tk94NGN5OTFlaFpIL0Q3?= =?utf-8?B?MElPNkw4T0hPVTIvWlZwaWt2SEhCakRHZTAzSGNFc0FxUWlXVUo0WldFck5p?= =?utf-8?B?TW51NzNQRWZjOVkrOGpkYXAzTjd4RXNPN3pEbDJibUxGYld2eW9URWpocEtq?= =?utf-8?B?OWhpNElVb2h0VXB5dFVnY1dNQUh4ZXA5Tks0Mk1CV2xsZGdxN1hrK0NCK0Nr?= =?utf-8?B?UkJoUjhoY0xoUmVaRkRNSjBDYWhiZk9VV1RLTUhXZTA2WkIrNjZwMU5rdnV2?= =?utf-8?Q?F/bAbg9q27MRXVB0=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98b65a35-36a3-4513-3c89-08df24962499 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 17:12:18.6961 (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: q10cqTmUrCx2vWROnxEDuOXIIGE6QXXDQ5RlIRJ3AzcvkmdlMu3ksB3EDIhPukWjLRuya38js8TxMyoVGm74y72m4C54r05brO56fxrF/rI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB8907 X-purgate-ID: tlsNG-4011c0/1791393141-51AC4CFC-C5899A99/0/0 X-purgate-type: clean X-purgate-size: 5148 VGhlIGhpZGUgcGF0dGVybiAueGVuLXN5bXMuWzAxM10gbGVhdmVzIHBhc3MgMiB2aXNpYmxlLiBP biB4ODYNCkxBU1RfTElOS0lOR19QQVNTIGlzIDIsIHNvIHRoYXQgaXMgdGhlIGZpbmFsIGxpbmsu IE9uIEFybQ0KTEFTVF9MSU5LSU5HX1BBU1MgaXMgMyBhbmQgdGhlIGZpbmFsIGltYWdlIGlzIC54 ZW4tc3ltcy4zLiBQYXNzIDIgaXMNCnVzdWFsbHkgb25seSBhIHN5bWxpbmssIHNvIEVjbGFpciBz YXcgbm8gcHJvZ3JhbSBsaW5rIGFuZCByZXBvcnRlZCBldmVyeQ0KdHJhbnNsYXRpb24gdW5pdCBh cyB1bnJlYWNoYWJsZS4NCg0KQmVmb3JlIHRoZSBhbmFseXNpcyBidWlsZCwgcmVhZCBMQVNUX0xJ TktJTkdfUEFTUyBmcm9tIHRoZSBhcmNoaXRlY3R1cmUNCm1ha2VmaWxlIGFuZCB0aGUgcGFzcyBu dW1iZXJzIGZyb20gdGhlIGZvcmVhY2ggbGlzdCBpbg0KeGVuL3NjcmlwdHMvTWFrZWZpbGUubGlu ay4gSGlkZSBldmVyeSBwYXNzIGV4Y2VwdCB0aGF0IG9uZS4gQW4gZWFybGllcg0KcGFzcyB0aGF0 IGlzIGEgcmVhbCBsaW5rIHN0YXlzIGhpZGRlbi4NCg0KRml4ZXM6IGE0MDFiNWM5ZGMzNSAoIkVj bGFpcjogcmUtZW5hYmxlIHNjYW5uaW5nIG9mIHRoZSAoYWxtb3N0KSBmaW5hbCBsaW5raW5nIHN0 ZXAiKQ0KU2lnbmVkLW9mZi1ieTogRG15dHJvIFByb2tvcGNodWsgPGRteXRyb19wcm9rb3BjaHVr MUBlcGFtLmNvbT4NCi0tLQ0KQ3VycmVudCBwYXRjaCBpc24ndCB0ZXN0ZWQsIHNlbnQganVzdCBm b3IgcmV2aWV3IChpZiB0aGlzIGFjY2VwdGVkLCBJJ2xsIHJ1biBwaXBlbGluZSkuDQoNCkNoYW5n ZXMgaW4gdjI6DQotIHVwZGF0ZSBjb21taXQgbWVzc2FnZQ0KLSBnZW5lcmF0ZSBoaWRlIHBhdHRl cm4gYmVmb3JlIGFuYWx5c2lzDQotIHJlYWQgTEFTVF9MSU5LSU5HX1BBU1MgZnJvbSB0aGUgYXJj aCBNYWtlZmlsZSBhbmQgcGFzcyBudW1iZXJzIGZyb20gdGhlIE1ha2VmaWxlLmxpbmsNCg0KTGlu ayB0byB2MToNCmh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzJmNjdlZjdjNDU5M2QzYWI5NGI3NWI1 YjgxOWU3ZTA0NmUwNTU3OTYuMTc5MTI5MzY4MC5naXQuZG15dHJvLl81RnByb2tvcGNodWsxQGVw YW0uY29tLw0KLS0tDQogLi4uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHlzaXMuZWNsICAg ICAgIHwgIDIgKy0NCiBhdXRvbWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHl6ZS5z aCAgfCAgMyArKysNCiAuLi4vRUNMQUlSL2dlbmVyYXRlLXhlbi1zeW1zLXBhc3Nlcy5zaCAgICAg ICAgfCAyMCArKysrKysrKysrKysrKysrKysrDQogMyBmaWxlcyBjaGFuZ2VkLCAyNCBpbnNlcnRp b25zKCspLCAxIGRlbGV0aW9uKC0pDQogY3JlYXRlIG1vZGUgMTAwNzU1IGF1dG9tYXRpb24vZWNs YWlyX2FuYWx5c2lzL0VDTEFJUi9nZW5lcmF0ZS14ZW4tc3ltcy1wYXNzZXMuc2gNCg0KZGlmZiAt LWdpdCBhL2F1dG9tYXRpb24vZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9hbmFseXNpcy5lY2wgYi9h dXRvbWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHlzaXMuZWNsDQppbmRleCBjNmUx YTdhOTVkLi5kZjEwMDZiY2FhIDEwMDY0NA0KLS0tIGEvYXV0b21hdGlvbi9lY2xhaXJfYW5hbHlz aXMvRUNMQUlSL2FuYWx5c2lzLmVjbA0KKysrIGIvYXV0b21hdGlvbi9lY2xhaXJfYW5hbHlzaXMv RUNMQUlSL2FuYWx5c2lzLmVjbA0KQEAgLTM3LDcgKzM3LDcgQEAgdGhlaXIgU3RhbmRhcmQgTGli cmFyeSBlcXVpdmFsZW50cy4iDQogLWRvY19iZWdpbj0iRG8gbm90IGFuYWx5emUgaW50ZXJtZWRp YXRlIGxpbmtpbmcgYXJ0aWZhY3RzLCBhcyB0aGV5IGRvIG5vdCBkaWZmZXIgZnJvbSB0aGVpciBm aW5hbA0KIGNvdW50ZXJwYXJ0cyBmb3IgdGhlIHB1cnBvc2VzIG9mIE1JU1JBIEMgc3RhdGljIGFu YWx5c2lzLiINCiAtZmlsZV90YWcrPXt4ZW5fZWZpX3RtcCwgIl54ZW4vXFwueGVuXFwuZWZpXFwu KFswMV18YWx0XFwuLiopJCJ9DQotLWZpbGVfdGFnKz17eGVuX3N5bXNfdG1wLCAiXnhlbi9cXC54 ZW4tc3ltc1xcLlswMTNdJCJ9DQorLWV2YWxfZmlsZT14ZW5fc3ltc19wYXNzZXMuZWNsDQogLWZy YW1lcys9e2hpZGUsICJraW5kKHByb2dyYW0pJiZ0YXJnZXQoeGVuX3N5bXNfdG1wfHx4ZW5fZWZp X3RtcCkifQ0KIC1kb2NfZW5kDQogDQpkaWZmIC0tZ2l0IGEvYXV0b21hdGlvbi9lY2xhaXJfYW5h bHlzaXMvRUNMQUlSL2FuYWx5emUuc2ggYi9hdXRvbWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xB SVIvYW5hbHl6ZS5zaA0KaW5kZXggMjM1NmZjNDAwNy4uZWY1OWU4NzIxMiAxMDA3NTUNCi0tLSBh L2F1dG9tYXRpb24vZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9hbmFseXplLnNoDQorKysgYi9hdXRv bWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHl6ZS5zaA0KQEAgLTc4LDYgKzc4LDkg QEAgZXhwb3J0IEVDTEFJUl9QUk9KRUNUX05BTUU9IlhFTl8ke1ZBUklBTlR9LSR7U0VUfSINCiBy bSAtcmYgIiR7RUNMQUlSX09VVFBVVF9ESVI6P30vKiINCiBta2RpciAtcCAiJHtFQ0xBSVJfREFU QV9ESVJ9Ig0KIA0KKyMgR2VuZXJhdGUgaGlkZSBwYXR0ZXJuLg0KKyIke1NDUklQVF9ESVJ9L2dl bmVyYXRlLXhlbi1zeW1zLXBhc3Nlcy5zaCINCisNCiAjIFBlcmZvcm0gdGhlIGJ1aWxkIChmcm9t IHNjcmF0Y2gpIGluIGFuIEVDTEFJUiBlbnZpcm9ubWVudC4NCiAiJHtFQ0xBSVJfQklOX0RJUn1l Y2xhaXJfZW52IiBcDQogICAgICItY29uZmlnX2ZpbGU9JyR7U0NSSVBUX0RJUn0vYW5hbHlzaXMu ZWNsJyIgXA0KZGlmZiAtLWdpdCBhL2F1dG9tYXRpb24vZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9n ZW5lcmF0ZS14ZW4tc3ltcy1wYXNzZXMuc2ggYi9hdXRvbWF0aW9uL2VjbGFpcl9hbmFseXNpcy9F Q0xBSVIvZ2VuZXJhdGUteGVuLXN5bXMtcGFzc2VzLnNoDQpuZXcgZmlsZSBtb2RlIDEwMDc1NQ0K aW5kZXggMDAwMDAwMDAwMC4uZTM3OTVlODIzNA0KLS0tIC9kZXYvbnVsbA0KKysrIGIvYXV0b21h dGlvbi9lY2xhaXJfYW5hbHlzaXMvRUNMQUlSL2dlbmVyYXRlLXhlbi1zeW1zLXBhc3Nlcy5zaA0K QEAgLTAsMCArMSwyMCBAQA0KKyMhL2Jpbi9iYXNoDQorDQorIyBIaWRlIGV2ZXJ5IHhlbi1zeW1z IGxpbmtpbmcgcGFzcyBleGNlcHQgTEFTVF9MSU5LSU5HX1BBU1MuDQorIyBUaGUgcGFzcyBsaXN0 IGlzIHRoZSBmb3JlYWNoIGluIHhlbi9zY3JpcHRzL01ha2VmaWxlLmxpbmsuDQorDQorc2V0IC1l DQorDQorY2QgIiQoZGlybmFtZSAiJDAiKSINCithcmNoPSQoZWNobyAiJHtYRU5fVEFSR0VUX0FS Q0h9IiB8IHNlZCAtZSAncy94ODYuKi94ODYvJyAtZSAncy9hcm0uKi9hcm0vJykNCitsYXN0PSQo c2VkIC1uICdzL15MQVNUX0xJTktJTkdfUEFTUyAqOj0gKlwoWzAtOV1cKS4qL1wxL3AnIFwNCisg ICAgIi4uLy4uLy4uL3hlbi9hcmNoLyR7YXJjaH0vTWFrZWZpbGUiIHwgaGVhZCAtbiAxKQ0KK3Bh c3Nlcz0kKHNlZCAtbiAncy8uKmZvcmVhY2ggbixcKFswLTkgXSpcKS4qL1wxL3AnIFwNCisgICAg Li4vLi4vLi4veGVuL3NjcmlwdHMvTWFrZWZpbGUubGluayB8IGhlYWQgLW4gMSkNCit0ZXN0IC1u ICIke2xhc3R9Ig0KK3Rlc3QgLW4gIiR7cGFzc2VzfSINCitoaWRkZW49JChwcmludGYgJyVzJyAi JHtwYXNzZXN9IiB8IHRyIC1kICIgJHtsYXN0fSIpDQorDQorcHJpbnRmICclc1xuJyBcDQorICAg ICItZmlsZV90YWcrPXt4ZW5fc3ltc190bXAsIFwiXnhlbi9cXFxcLnhlbi1zeW1zXFxcXC5bJHto aWRkZW59XVwkXCJ9IiBcDQorICAgID54ZW5fc3ltc19wYXNzZXMuZWNsDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Oct 07 17:46:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 17:46:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442611.1660146 (Exim 4.92) (envelope-from ) id 1xEVik-0000hV-1m; Wed, 07 Oct 2026 17:46:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442611.1660146; Wed, 07 Oct 2026 17:46: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 1xEVij-0000hO-Uc; Wed, 07 Oct 2026 17:46:25 +0000 Received: by outflank-mailman (input) for mailman id 1442611; Wed, 07 Oct 2026 17:46:24 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEVih-0000hI-Tl for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:46:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEVig-00EYXC-DX for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 19:46:22 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68543-bab6-0a2a0a5309dd-0a2a45098e14-42 for ; Wed, 07 Oct 2026 19:46:22 +0200 Received: from [52.101.84.119] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac6856d-be1a-0a2a45090019-346554774639-3 for ; Wed, 07 Oct 2026 19:46:22 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by AS2PR03MB10155.eurprd03.prod.outlook.com (2603:10a6:20b:64d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 17:46:20 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.015; Wed, 7 Oct 2026 17:46: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=GVctzl8Je3zIkFAINwci3stlEMkX6ndJ2tDkfOEzAhN1vP4JZaWKLj8LPiIPe7oNnGiTpaHk14RLPwRLxZVYskG15Cr70kUjkTOXK2NCKyfbdCnGdSyrrDOtWVeCp4y+GLylPCEx+ITRod8Xp6j7xmmygicHUODV3pWhptCmIwzJNc1ZHfhqCa/6SMhm9lZMzueJW5Rrwe6Z+2+nG7kvzQ/oJSRBNbqOkoPZ+0iU78d2xXeYxlmQ7EiMQ5GpsDzmkmHSmpNoK1LbqOSL8pwN9N/tylQHWO5tdrsqpJPZaOVCQ4FrymWfFFP/wkMAR0umOsNuEEdnAu4w+RenkD5v0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=etNi6/tzL0jNLVy4LsgM26NsX76EYCqaVyyNtm3ZzvI=; b=DQ1KYllYZBWAPlaA89vy/ZSYn5eUe4y5hjGmQ5p44ubezXFsbdJrTqANhOOEBHOYaiTPLKdIXA+Ix9ajuDwV3Wxu9C2XWoUAmwdEgwr7QlVBD6LD94WPNEmpmKUu374at36v91A8+qtgwZvXMsjeunapS8ejChkCSpvqzPO8oxRat/ep5bkzM0JGJyKUvkwZQ7I7DsuBu+m7CLy1IduhJeErqsha9wdX5vkc6DppvZMw++5vGixCpO8uqAaTwaUewD3Rwm427ht8Ew+52Sp79FO8Ug6xTCPKOVNWljZXraGelIWS3Msd7SxoC8ATClh/xqZKEderlWxtwMuHkzyxKA== 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=etNi6/tzL0jNLVy4LsgM26NsX76EYCqaVyyNtm3ZzvI=; b=X8U5U3IhfUd2mbcoa566mFCpJ2R233RO+X3CopHYmuSDFqEBwRweIu0Ylgfxyh7QjT76jv1sepfdXFw/uje3rYA5eqlgYKslFl+eqatg/UN8NQK+p38e+Isquh3kVy9b/j0C7FiOxuHgPjRAjkMZPnBJC3+YtnDrtHpKv1T5jSxbcUMLroQ7IECckhjPMpUnUd48rHGjLAc4UB+GsNrb5rRX1VBc0c34nfVOiIRvBKE1pq5CNyRQDt9bcrtDqtKKyU5hRMQ3SlCLY1QV4A2CmwyoEihONmISg7JngIJWpvsSDKdq8cjr/mX1gsbtefORTsWhEuKPx5hoxqj/pznTZQ== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 2/6] x86/alternatives: adjust _apply_alternatives() to comply to Misra rule 18.2 Thread-Topic: [PATCH 2/6] x86/alternatives: adjust _apply_alternatives() to comply to Misra rule 18.2 Thread-Index: AQHdQFsfe75+NzGtXk64qzkN3mSrm7byhs6A Date: Wed, 7 Oct 2026 17:46:20 +0000 Message-ID: References: <6e503818-3446-4bdc-8b65-d61169667b7a@suse.com> In-Reply-To: <6e503818-3446-4bdc-8b65-d61169667b7a@suse.com> Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|AS2PR03MB10155:EE_ x-ms-office365-filtering-correlation-id: 847d593b-f527-4bf1-8c40-08df249ae58e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|42112799006|10067099003|56012099006|4143699003|11063799006|22082099003|18002099003|38070700021; x-microsoft-antispam-message-info: QrsFY5Ee00zrhATjFHany3SizBtQA50rXb1flXZRwLurZ4RvZ95cacyfrizOKsTiA1YLfzurc92suJ+yQCa4xpdyo+/IlQeDQ+Po3OMsuBVvIdPrNFubnh4LAKFITmqyHuy7oKDIQQflbXE/MZqzbHN+ZrKA8LeoWD8A1FVorByMLj64UULUdBrf9+owdsDkOxq7y4ht0byN5alBhGUCs/yf2mnDz5YuCaY8yk9Xq7oCu/sD5oH1bOxg3sKhOfE/Ep7B5UdhYMuGRs1/+V+qzDPGkEnRCTTgN4g+Tj+397/6NrMYAoTun8CSXSPzQHlRA/ylbdKtW2Rl067kAnNCJDuOQZqlVKrn8hJRIxNCFna1Da32scbt/atgzx4ZeZo/zVsBj0u7AmlCe9rUvmTlPcvsXUNFGeyqrn/ZnEndYYesJ+RceKq//ZP0haqHPQXtITVE9EtXqDXMHK5vfmFA8y8w4A3px4eYWbFpm6u4dVa10cYGhTFMJ4dCgGyIdc8yVSmC8uaVR0ZI/xnxwA9VsWq5+2uX18gcRKKCZdFSnXTaS7mc9moeIB6M/+/QehxqO7cFQs6LAgXBapKJilHpHvibQfTXp1Xh1xsEfLBLorarO836JRGR9D7zcStmQaBxx+fuo34RF50ER2yeimonQF7V0H5i/PpJCOm+YVJqOONzmKeQ3ihgcWiPFxH/V7tPrlsZca8l+eLfk0pfEs0Mzw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(42112799006)(10067099003)(56012099006)(4143699003)(11063799006)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NUp4aExKVVFuaVZ2cVBCR2pWdVAwak1teklnMEJkbkVTS2Vmc1VHYnp6dllt?= =?utf-8?B?ejRXUlpzSGwxaHdWR28rbGNiNmg4aHM4VFVwUXFWQ1M2L2JHRFdmWUxBMWFR?= =?utf-8?B?VzlybXU5d3d0ZW5ZRUNPT0Q3Q0NhSnZTLzNJcDZ2VWFncnBwYTlxb3BPZDBR?= =?utf-8?B?MXRlOGRGVGZFaG5MdEZ4ZHc1UGVMa2Z1U3VER0RpeCtLM3hjUGZLOTQ3aVdH?= =?utf-8?B?RHMzOVRRY2pqNGFSTE82bC9GcXJkVGdYWklDWHdsTlNleFh5bHJ2b1h1a3dC?= =?utf-8?B?cTkyL0lUeDhUcDNJbGlBaXg5TDZBVHBSOHRWcUNZN3JSdHNibEsyalBnWHlt?= =?utf-8?B?enJqbldhU2g2M0VaSGlRVHBvelI3OUF2elpJUFhoZEt3VmdzWVU1V0pacGpG?= =?utf-8?B?K0tYbHF2cFowYmZTK2VET2JRQ1NBQkFJWmxyRE1Gc3RBRU1WS1RuUk9iSnNx?= =?utf-8?B?QzVVbkFtSWRXQ2Q4NEkrajlNbHplblhHNlpMRDJlaUNyQVNoQXJCeTVVS3Iw?= =?utf-8?B?L3dNRmVXMzJkOXdQVlkwWEx1RDV6VDEzKzlQV1A0VURuTERVUVlGam54MXpw?= =?utf-8?B?c2l5dFFHZHIzbHZ0T1E3UlplcmY5azd0RXZTSU4yTk8yb2JFQkx2VWRqalpZ?= =?utf-8?B?aDY1cUxwNjYwSU5SU0lBY1JJT050M2sxU1F3amlnRTRGeHFUK0dCVWQxZ21i?= =?utf-8?B?WVZxMHp3VUhGRmU0WHBHYVFtZWxkWWpLNll2QnJJNnFOVHlOcXM5NllaTjdn?= =?utf-8?B?SGtETSsxODZwMThuRmk2RC9rU1dZWERxN3QzM3lWajdvRFh5eUI5bVhHVnc4?= =?utf-8?B?U0ZCWHhOUm9ldy9JcG0vcW11aHlucXQvZTAzcHNVVXF6K0hpNnhWdVZkcGtX?= =?utf-8?B?Rk5KV1FMQUExOW55RjR6REMzRFVpY3BEcXU1d3FNL2paazNHcUZIbk5rb2sr?= =?utf-8?B?ZmQ4L2FtbzdSZk0rU0hXZGVXNUx4QUQ0MFVreGVveTVVWG1YMkpQL0lxNWUv?= =?utf-8?B?K2tFc201Y1k2V01xWUVHNVVZTmFPWE9VZ3psZ3JCVFJJMTlmc0xyUHpoMGRM?= =?utf-8?B?cFhjZVUvQ3dNTGR5TDZDc3ZjUDZvcDZEakdab1podlVKUFEycldPYWZyL2lZ?= =?utf-8?B?cmZwWlg0b0JkZ2F0b0EvSGUzeHl1eGo4LzBoU1c3RTVZblRNTmlLc3dLWXU1?= =?utf-8?B?ekJMdGVMOVd3RnQ4bm9VZjQwZUZmcXdINnhQa2srRWpxSEhHdVZuV01ySFhW?= =?utf-8?B?bmhiS21uWmcxa0t0MjFrRlBXWTBmUVpQZFJ6QUZ6ZXBpVDRXM08vQzJZRlNz?= =?utf-8?B?dWZqWFNjVW5uZTJLejVBYWh3M0d0aVhxZnZYV3lVeXIrSnV5b3daVmNESExE?= =?utf-8?B?Y0hJM0JUOFhCakI1Z0lHcTlYNk5XOXVYS2pXemdzaHFCME00akdWZThLVnow?= =?utf-8?B?YzgvM05LZGE1Z3VCanJuOHYvZitvY2xuaERXcXJGdUlZbXk5KzlTNGZFQm9V?= =?utf-8?B?dVdFdXJINzQ2UVFTL1BIMEdZNHdHemhaa2V4dDk4SFBQMGtQUHU3OGdtTUpV?= =?utf-8?B?Z3o4bHlGRGtWTGVQUEE4aVdlYmo1cmtNWlZQSk95ZHhTZVRGYUVWSkxDenNG?= =?utf-8?B?SmRyQU0vYWU5QlY3eWpQd2hDUFlHNGhDVjZtRlBMdmNLR0lrVXZoV2pYaHJO?= =?utf-8?B?OW5DdmFiU2VYejV1WmoraHhTYkxMNHMxYjFkbnptSFhDRWRvQ2NwSUVzVGNZ?= =?utf-8?B?NUxhN1orZmh1bHhWbHJEY2JQSW5HWVJvNFI0WUVFelJGenRwNyswbDZxeGM5?= =?utf-8?B?bkE4NFlnNXZRZ2lkanU2UGI2NlYvdDJNbW1pVTRLc0d6YTdFQmdxOVlaakd4?= =?utf-8?B?dGFDeXQyNmdGN09lUG50c2xSU25yZVJ3ZjRyZ3p2Y0hBdUNmem5qVmtRN2p6?= =?utf-8?B?bHV0VUswZWxFTXRXdGdrc0gyUDRjdTQ1VW5jSzRzZGhSZWp5bE5HZHRySkVp?= =?utf-8?B?RjVobzlOMDJYWCt0SE5MK2dYbnN6eU4wZnZHSXlwbmxoUlJrbUt0YXRNYTJj?= =?utf-8?B?SU9kK3JIbnhlQTR0Yk0vdldnTzVGKzkrQnF1V1FsRlpoejg2R3pjZ3p0RzNm?= =?utf-8?B?NE92bXJTUGlYdjdFdlA2N3dBNjNuSWVrMzEvdXdLYldnbHZpQ1ZRZmNTb3ky?= =?utf-8?B?VFdvYWZIdmQzWFIvdUl5ZXNDVnRLYkVUQlZBNXhQSDJwYksrdHNoQWVFTHRM?= =?utf-8?B?Z1BhYTBNRVFtaFFyYXFia1FBWEtCTk0zY253cCtkTzBpVS94N05reXhBckRi?= =?utf-8?B?RDZyZC9jem1LdllkUGR1eDdua29weTVBaTluN3VuemJLOW9wM2JEaDRicHFL?= =?utf-8?Q?00iyIdvvSHPaNy2I=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <32905446D955154D8E52D0BF18CF2A6D@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 847d593b-f527-4bf1-8c40-08df249ae58e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 17:46:20.4521 (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: wZpj3R8LFMo8G1vqXTh2ZfBSIWn+bwwvKCb2VJNHGzd2DHhucLw9rAG//e/SozcvxlSwYqaKCrfdSqHfVzgrEcqVftYiD47Tq1xCZuQci1c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB10155 X-purgate-ID: tlsNG-bad1c0/1791395182-BF2DC034-72F01FF8/10/78276251493 X-purgate-type: spam X-purgate-size: 1804 DQoNCk9uIDkvOS8yNiAxNTo1OSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IFdoaWxlIGF2b2lkaW5n IGNhc3RzIHdvdWxkIGJlIHByZWZlcmFibGUgaGVyZSwgdGhlIHN1YnRyYWN0aW9uIGVuZHMgdXAN Cj4gdmlvbGF0aW5nICJTdWJ0cmFjdGlvbiBiZXR3ZWVuIHBvaW50ZXJzIHNoYWxsIG9ubHkgYmUg YXBwbGllZCB0byBwb2ludGVycw0KPiB0aGF0IGFkZHJlc3MgZWxlbWVudHMgb2YgdGhlIHNhbWUg YXJyYXkiLiBVc2UgbG9uZyBhcml0aG1ldGljIGluc3RlYWQuDQo+IA0KPiBObyBmdW5jdGlvbmFs IGNoYW5nZSBpbnRlbmRlZC4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1 bGljaEBzdXNlLmNvbT4NCj4gDQo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jDQo+ ICsrKyBiL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jDQo+IEBAIC0zNDIsMTMgKzM0MiwxMyBA QCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9hbHRlDQo+ICAgDQo+ICAgICAg ICAgICAvKiAweGU4LzB4ZTkgYXJlIHJlbGF0aXZlIGJyYW5jaGVzOyBmaXggdGhlIG9mZnNldC4g Ki8NCj4gICAgICAgICAgIGlmICggYS0+cmVwbF9sZW4gPj0gNSAmJiAoKmJ1ZiAmIDB4ZmUpID09 IDB4ZTggKQ0KPiAtICAgICAgICAgICAgKihpbnQzMl90ICopKGJ1ZiArIDEpICs9IHJlcGwgLSBv cmlnOw0KPiArICAgICAgICAgICAgKihpbnQzMl90ICopKGJ1ZiArIDEpICs9IChsb25nKXJlcGwg LSAobG9uZylvcmlnOw0KPiAgICAgICAgICAgZWxzZSBpZiAoIElTX0VOQUJMRUQoQ09ORklHX1JF VFVSTl9USFVOSykgJiYNCj4gICAgICAgICAgICAgICAgICAgICBhLT5yZXBsX2xlbiA+IDUgJiYg YnVmW2EtPnJlcGxfbGVuIC0gNV0gPT0gMHhlOSAmJg0KPiAgICAgICAgICAgICAgICAgICAgICgo bG9uZylyZXBsICsgYS0+cmVwbF9sZW4gKw0KPiAgICAgICAgICAgICAgICAgICAgICAqKGludDMy X3QgKikoYnVmICsgYS0+cmVwbF9sZW4gLSA0KSA9PQ0KPiAgICAgICAgICAgICAgICAgICAgICAo bG9uZylfX3g4Nl9yZXR1cm5fdGh1bmspICkNCj4gLSAgICAgICAgICAgICooaW50MzJfdCAqKShi dWYgKyBhLT5yZXBsX2xlbiAtIDQpICs9IHJlcGwgLSBvcmlnOw0KPiArICAgICAgICAgICAgKihp bnQzMl90ICopKGJ1ZiArIGEtPnJlcGxfbGVuIC0gNCkgKz0gKGxvbmcpcmVwbCAtIChsb25nKW9y aWc7DQo+ICAgDQo+ICAgICAgICAgICBhLT5wcml2ID0gMTsNCj4gICANCg0KUmV2aWV3ZWQtYnk6 IERteXRybyBQcm9rb3BjaHVrIDxkbXl0cm9fcHJva29wY2h1azFAZXBhbS5jb20+DQoNCkJSLCBE bXl0cm8u From xen-devel-bounces@lists.xenproject.org Wed Oct 07 17:56:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 17:56:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442624.1660154 (Exim 4.92) (envelope-from ) id 1xEVs4-0002S5-Sf; Wed, 07 Oct 2026 17:56:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442624.1660154; Wed, 07 Oct 2026 17: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 1xEVs4-0002Ry-Ph; Wed, 07 Oct 2026 17:56:04 +0000 Received: by outflank-mailman (input) for mailman id 1442624; Wed, 07 Oct 2026 17:56:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEVs3-0002Ro-Cr for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:56:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEVs2-0010dr-1l for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 19:56:02 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac687b1-2eae-0a2a0a5409dd-0a2a4502cd82-0 for ; Wed, 07 Oct 2026 19:56:01 +0200 Received: from [209.85.160.182] (helo=mail-qt1-f182.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac687b0-6ca4-0a2a45020019-d155a0b6e1ad-3 for ; Wed, 07 Oct 2026 19:56:01 +0200 Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-53397554beaso41838261cf.3 for ; Wed, 07 Oct 2026 10:56:01 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.242]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5357211719csm25090341cf.16.2026.10.07.10.55.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 10:55: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: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=1791395760; x=1792000560; darn=lists.xenproject.org; h=cc:to:message-id:content-transfer-encoding:content-type :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=xmwkg4obehY78DK/gvFot3vkf85Y9oVRiaNJ/eUX4mE=; b=PDRgnwm1BmWnMlYaMAeH5TREiqIb3lGPIg+IEDibTY3XBVuK/e+SJE8tXxDyRz2HyW kJ3iswG26nj/CHRI/4rSLqhX334T2p4Nmm4aZfSnPqx9tqPT0UltBVdMGZ+b/3KGuOBH bJ0j6zoDA9jYoiP6OclkK6w+0JIry9PhXPoplSIkYcRfeTUq3rtddSjFc3M+YcUNOAHt VBJT2ui8w/lVQk1bekebIxyXpfqjlsQdN31XNVaEpG6ockVs4LEyMGt6rVZSBMdTfGG2 rPskN/1DL/heLp8lvFt3jNA9UazHXUi/MEvaHJhpLXoRaFuVDAp2d8tlYpgp7Uuts2/W MW8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791395760; x=1792000560; h=cc:to: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=xmwkg4obehY78DK/gvFot3vkf85Y9oVRiaNJ/eUX4mE=; b=a/dEVEGJfVE75oW0WrqmwG0CpKW7Z5HDF7NUyMJqKb37JmPoHLOR5W+LG6bmQYE7NM 56aQmIisCoH/7ELSGccyLUCUmJr5Z5R8AzRdXgIDQOIdolZ9K/idn/e0QxD9vNegT44H Uv9TgSzINRBqK8T1HRYp3sDFS6OqSBkjh0NI3BbrjKDQqkVfU1HH8kgPwg5+efPte/eT hphy4bFq70cRLwhzCLrWbzKYiriBOzcWjCoaaP8gmIb793kygBLTEu8TDq7aT2IWD8sN PtKdLMsHs1JEIjacSXUburRTO8rgIUCW391snlP00Fd4cKrK7qR5xuMf5p8Gyhp3I7Iz GI4g== X-Gm-Message-State: AFuF++lU1pASJSdOayvwrQ+ia8r0KPKFFyo/4JeCq2pzVQMJyO0QKR/T 0unhJw4Q8DjQ4QMtM37b8QiYZT1DbdXdxSkCbSNX/sz2A6q7tTWTQwuu98aAwt374sQ= X-Gm-Gg: AYBFou0KswvGVlPXdxzEyjhAPn41jNZFDSxEcIfROX/TnIVlSkABu31tFpeHibhwzsJ 9zZODEwUmMLgVgNZGYdMD9P93VNgYeefo4wXcTqEvo5q+8TJaBosQd1VG296qkIJ+fJCrIN/v/y RAJgF3dvj97LYGGq9HvUD8rCeHScAYNcTrgu11BxGMR1lQAdRpVyW87rFW9GP/44e4goDqA4PI6 YexVkV9cm6FgjzDDFVUvYOp/3ppbXMv4zOaQNtEQUSTN1fUNpwGxJ1JuTUGpjQZamwCA9YqQZO0 OZqbEF+t50OSiKATZ0qE7fXTQtmZLXW36zBCrpy3RHUCR1ZwiHOx5SKy1VGN7zDX1OExK3zJ+A8 z+tnU3S5XsdXWD6gQlUWeflceRuxZJr3I6DoI83JJueOoumIMn8vNS7rq7mZTnAZq/v7o6Qq9Zv jxs8vUdRhZb+oD9/le/dSsZKyWBJUhp+UhMfb+ytQE03KX25hHSfKUZjsqOco9Pcb/SvgiSsF6I lzlBNT8AHABtHU= X-Received: by 2002:a05:622a:228f:b0:532:d202:3280 with SMTP id d75a77b69052e-53575587ed0mr53145321cf.17.1791395759016; Wed, 07 Oct 2026 10:55:59 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 17:55:40 +0000 Subject: [PATCH net] xen/netfront: drop RX packets with a short Ethernet header MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com> X-B4-Tracking: v=1; b=H4sIAJyHxmoC/3WNzQrCMBCEX6Xs2aVpiUF9FekhP1sTkaRkoxRK3 92knj3Ox8w3GzDlQAy3boNMn8AhxRqGUwfW6/ggDK5mGMWoBiEUGokrRYxU5pxiQfYpF/SkHcr z5UrkalEpqIIl0xzWQ36HOoDpB/ltnmRL07aa0Uxoso7WN/RaeiP7A/45gn3/ApL5MHK4AAAA X-Change-ID: 20261006-b4-xen-netfront-short-head-4589eed26166 To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Chris Wright , Jeremy Fitzhardinge , Jeff Garzik Cc: xen-devel@lists.xenproject.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791395753; l=2871; i=josef@toxicpanda.com; h=from:subject:message-id; bh=A37dHJSUMP/nvKcIqGBinBiB2RmDmS9OMtLDSfYEGv4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QBma8pM3Gytl7OfKxBBYVgGtx7BbS2eOhz5s1BtEXfNAHtDhR2In+nspjxyU+mEHrN5zQE+wIHz sHiMpR5ErGQA= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1791395761-668B42AC-A3C06F9F/0/0 X-purgate-type: clean X-purgate-size: 2873 handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored. Fixes: 0d160211965b ("xen: add virtual network device driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Josef Bacik --- I found this reading the code while going through the callers of __pskb_pull_tail(). To check it I ran a guest under QEMU's KVM Xen emulation with QEMU's xen_nic backend changed to split some frames across several RX slots. Without this patch, a frame with an 8 byte first slot followed by a second slot hits the BUG() at include/linux/skbuff.h in eth_type_trans(), called from xennet_poll(). With it, frames with a 1-13 byte first slot arrive intact, frames shorter than an Ethernet header are dropped and counted in rx_errors, and ordinary traffic is unaffected. There's a net-next series converting the other __pskb_pull_tail() callers in drivers, including the one in xennet_fill_frags(). It doesn't touch handle_incoming_queue(), so the two don't conflict. Thanks, Josef --- drivers/net/xen-netfront.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 2ed673649c48..d269457e839e 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1234,8 +1234,16 @@ static int handle_incoming_queue(struct netfront_queue *queue, while ((skb = __skb_dequeue(rxq)) != NULL) { int pull_to = NETFRONT_SKB_CB(skb)->pull_to; - if (pull_to > skb_headlen(skb)) - __pskb_pull_tail(skb, pull_to - skb_headlen(skb)); + /* pull_to comes from the first slot's length, which the + * backend controls. Make sure the head holds at least an + * Ethernet header for eth_type_trans(). + */ + if (!pskb_may_pull(skb, max(pull_to, ETH_HLEN))) { + kfree_skb(skb); + packets_dropped++; + queue->info->netdev->stats.rx_errors++; + continue; + } /* Ethernet work: Delayed to here as it peeks the header. */ skb->protocol = eth_type_trans(skb, queue->info->netdev); --- base-commit: d5a007b9b457c915ab1a53227e8939e4018aa97a change-id: 20261006-b4-xen-netfront-short-head-4589eed26166 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 17:57:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 17:57:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442633.1660163 (Exim 4.92) (envelope-from ) id 1xEVtr-00036X-9n; Wed, 07 Oct 2026 17:57:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442633.1660163; Wed, 07 Oct 2026 17: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 1xEVtr-00036P-6S; Wed, 07 Oct 2026 17:57:55 +0000 Received: by outflank-mailman (input) for mailman id 1442633; Wed, 07 Oct 2026 17:57:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEVtp-00034i-Uj for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 17:57:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEVtp-002J09-Bc for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 19:57:53 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac687e2-2eae-0a2a0a5409dd-0a2a4503edca-36 for ; Wed, 07 Oct 2026 19:57:53 +0200 Received: from [209.85.160.179] (helo=mail-qt1-f179.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68820-fae8-0a2a45030019-d155a0b3addf-3 for ; Wed, 07 Oct 2026 19:57:53 +0200 Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-53512cd2f85so21065801cf.1 for ; Wed, 07 Oct 2026 10:57:52 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.251]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93e991fe1a1sm269754085a.43.2026.10.07.10.57.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 10:57: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: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=1791395872; x=1792000672; darn=lists.xenproject.org; h=cc:to:message-id:content-transfer-encoding:content-type :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=MAJHQ2Wkik4PqvnpAIT0i+1papDfY48uBw0Kb6tIGEA=; b=qk/aAx7b+rnaAChXJbeGcOdBURVLhhOc1OfbrcAWjvAFQa/allMxGwNUwj5WQdq7Z1 n2sgYpi3N+PEX5X5LjYA8QdaOpZPx2WvXwV6MyqJRGZzlIOCqkATIFjO2e/5Mk9emA8b +AJu+KZLOzHGhQHnCJu6h3y7YylN6glWs5aQZTydS7MFUBMSOco6AMz4VHAB3fTHII/7 xpCDMjv9HHDnRs7wy5EFSFs8N8aDRMCbZAixaMG/igTrG+Oha9+npmIcyQqj6cSNdHxc QR1CXjqurW5nXDfawhZ6EgW8k7aJ3FeD3jAM0cl1lDyhPTgxgytpHol8BdTguoJPr87m HFfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791395872; x=1792000672; h=cc:to: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=MAJHQ2Wkik4PqvnpAIT0i+1papDfY48uBw0Kb6tIGEA=; b=kS0girR8SRxtpoJSyg5yADcxSOF22oZbJ4azVSAbf6lnIjSN+bkZynF5UXb+XYf4Lh sXtbTSHzMdxNYsQrM6hxVjg7jMCrrZvE97MqT9xOxTAuB0n1YyXr7QZkfGmVDgqPO5cm 1s7UgV/BhWi5T1USin4c8YpK/71hkvR+gySr6faqufh6wFHNvkpfQF1+01WVJjf6Q6hb /U2F5VR9udoZqHhezJSYczo6C+qg+ToNHCZQucGEWXh3OPQImeAGbGF2SEEjWLuYlu0t G/rS0BDipNXwJjiNQ4iDAb9y8hyYaT6ZLtWomLHlQrz31tRTQpWccU7g7k6zCfQSOm83 /vyQ== X-Gm-Message-State: AFuF++nEoR5fioJOGg324CiIpho6HFMLLpVYT2RLUGPb2LaFi6omptt5 9yaZjVYsPXiPHI8zXY9WseGXGRLdiYkBl9wN79vRk7ejj/VL71O/iPnilmL2ojqFIfI= X-Gm-Gg: AYBFou0dUczssVppJcsmmLvTvqQKIhStSlA67CFZQyLCoeS3xsKxd2wxKcUHvfpEtNd aKsTEnFhcmEmf48x87t54CyKLbfSgrDf3j3A1AmC0sGA06gjp0dnFp4MLh0DG0r7YqetP5dpWsX ywkSATn5Dqmdi8BhARjUO+1uKAyx8QLgpn6kSYNYUY5D8FuL1+KqKiQrGRSIEaBNI2gTqEW0yPB vELNqno2ATjD7Z6pqXQwXtRa6eLuSkLZJUIZZQ1C9gUYbSUz1C5jD7ALdOR07sObE0vuYt0uNU+ lZeM1BQcxTGiQWJ784UHMXcZYaKs1qgY62GII8mwy5ebVKjl4qV9FpTTfwGLlFlskHQ5qpiOh7M JAcxtNdxUXCFkWssV+UFZDGVhS45YayMQzy76ZFzfiINt3PEosy32t+cZbuCJAPDYlgnpktuQgS Ss2rOZ8FMLfXtalZgkmpYdsSwA/m05ZM0bYrnngBxQMPAxDUsHrXCTHquovSDBgkXaNMCWA6tCO Z1TPR/Cdj/FdWU= X-Received: by 2002:a05:620a:890c:b0:93e:5b69:fa8 with SMTP id af79cd13be357-93e9b80d367mr562281185a.66.1791395871851; Wed, 07 Oct 2026 10:57:51 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 17:57:32 +0000 Subject: [PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.com> X-B4-Tracking: v=1; b=H4sIAAyIxmoC/32NQQ6DIBREr2L+uj+ipZD0Ko0LwI/SEjRAGxPj3 Qt23+W8zMzbIVF0lODe7BDp45JbQgndpQEzqzARurFk6FkvOsYkao4bBQyUbVxCRuu8RxvVlNC TeuH1Jo2SXIwkNJSXNZJ122l4QFnB8IPprZ9kcv2uNa0SoY4qmLkiv7aatyf8Z4Pj+AJbKHhWw gAAAA== X-Change-ID: 20261007-b4-xen-netfront-fill-frags-leak-357ca746de6b To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: xen-devel@lists.xenproject.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791395867; l=1952; i=josef@toxicpanda.com; h=from:subject:message-id; bh=8siqpym+SZiWtWrY6ilp/qzOSB35ebH+f54wdBWICCI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QKPBUTwP/hi5b4ZMT7RDyKAACyTKaU+F86iAtqdwrk+vWoZzfHOvsW0aj2tgmsgdCJbxvHAP8g7 hKN5N3lq1pwY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1791395873-77CC34E9-2CC44285/0/0 X-purgate-type: clean X-purgate-size: 1954 When a response chain has more slots than fit in the skb's frags, xennet_fill_frags() returns an error and xennet_poll() jumps to its error path. That path moves what's left on tmpq to errq to be freed, but the skb being filled was already dequeued from tmpq, so it's never freed. Each chain that overflows leaks the skb and the pages attached to it as frags, and the backend decides how many slots it sends. Put the skb back on tmpq before taking the error path, like the xennet_set_skb_gso() failure just above it does. Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Josef Bacik --- I found this while testing an unrelated netfront fix under QEMU's KVM Xen emulation, with QEMU's xen_nic backend changed to spread frames over more RX slots than netfront can fit. kmemleak reported one unreferenced skb from xennet_alloc_rx_buffers() for every frame that overflowed. With this patch the overflowing frames still take the error path, and kmemleak no longer finds any skbs left behind by them. Thanks, Josef --- drivers/net/xen-netfront.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 2ed673649c48..e8675bdca595 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1338,8 +1338,10 @@ static int xennet_poll(struct napi_struct *napi, int budget) skb->data_len = rx->status; skb->len += rx->status; - if (unlikely(xennet_fill_frags(queue, skb, &tmpq))) + if (unlikely(xennet_fill_frags(queue, skb, &tmpq))) { + __skb_queue_head(&tmpq, skb); goto err; + } if (rx->flags & XEN_NETRXF_csum_blank) skb->ip_summed = CHECKSUM_PARTIAL; --- base-commit: 23609bce9e1de525d1d0e73fc68c6e7971d0b49e change-id: 20261007-b4-xen-netfront-fill-frags-leak-357ca746de6b From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:07:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:07:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442645.1660173 (Exim 4.92) (envelope-from ) id 1xEW3R-0004uV-5B; Wed, 07 Oct 2026 18:07:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442645.1660173; Wed, 07 Oct 2026 18:07: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 1xEW3R-0004uO-2T; Wed, 07 Oct 2026 18:07:49 +0000 Received: by outflank-mailman (input) for mailman id 1442645; Wed, 07 Oct 2026 18:07:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEW3Q-0004uC-7B for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:07:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEW3P-008tbe-4q for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:07:47 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68a34-8faa-0a2a0a5109dd-0a2a450aa69e-30 for ; Wed, 07 Oct 2026 20:07:47 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68a72-f2d2-0a2a450a0019-a237832fc924-3 for ; Wed, 07 Oct 2026 20:07:47 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id B78464EE0216; Wed, 7 Oct 2026 20:07: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; 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=1791396466; b=SCPO44R4CA9S8Vsk+kzF5079r1Yvh8vpWUUlplHi5KNywCMSGkLurEdFLn/8yHCxIObN smgAIVWg1xBYZ4VipDisQOIceYks89BCCibhTFI7GHSx6zSfi89dXbbTiLUKpSYBTIMgx TLDfYw/CGnttthy83K8dO/Ie4usdoRxfzPI5uFb2czcsxlpOtoh+VtMCyYzZPcOTDtYZq afi7oEUhjLSzN8+PERdE4+4AagoHxyUkQOSw5LNW1jZINdwG18eZ/xi3667+ijkV1ou+4 Zpq27a8g2wnD4M62Dc4FhWr3v2bIs0QtR7uhXINmlh1+y7JjVJKVolRJl++k5BgwkgKZu 6/rpQsqbhsl/Cob2EZR69CGF8Hrq+07TpU/mEswaCpfHN9EaO8Z70gMZMBBmHuZv+PPTV PNUkkawKFE49POsKMU+2G8fKGFZTw2bX7HSlDQQgKMienLwJlZ+DCkSCtkUcYES6exryu /dBaM5MYtH3hIzgJDFikBJqAQ1g5eY7loKLnPyZsxyUTXr+fpR75r6yieKIpL9e094LnD kqdYJZTZVKSTmEGJVrT0ASjP1YUjOp+n2ZbcLEhda0ZmFIH/cKrd8wv8elKpVrLKwAqqj OBJh7NmpV+1LfZDrbL4/sBW2za0cMfWduavuCM6LGxR7GdCU2Ukfenp6Zs2+VMg= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1791396466; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=kKoqfZ9oNLAGrvGPtldZE8hf6KjD7k5BKmZFYhyYQog=; b=CkdN9Bck7HmwNPqNK7PDaLejtzxzzugaSCjP3cTEGzBggwbFYJn+cckx3AA88lqOM/fU vNGMZ0Tzfji3txdDw/jCXGAe360jp06Olpb2oxBf05pV64oMnXALyMPRxMfGEqlh+kwy5 7wuZQtBzM3Fg7xNHXThT3brsTK7MWh5YWsyRdxKrUjG2FXG8f0P9nJj9ec9m8FNV8edKE l959P3l7L2RiXwm1S0zsTNTSlb4lL7/MG0LqMgIAuqAGGlb3wtkBbrQiFv5sB097vN8Vm Ob67sm1yahKAdCCR3taCyZQ67sRI6VTvKih6DLi5aoasuco2gnHp3SQPs8DteJo90dQEC zi5ziUcXVwGYhg8FVRc8id0zZoB/qmD6QvgnS2SLMK0RMlutvtJ0MeMybmLd+WDCjtEnU V5noJWgrgjqCO6QG7TojRTBpEF+eTLyBJgNdbX9NJSXesFO2x89YVaxSmZPf0GDzNBIu2 W4gDEDzWFhr+G/jYfM1/pM1HtRJDmhp8Tzs6208QHMo5r8nYIQm69uiS4ltLh7cxHV63T eXpWhy2iOGdcp/uMeLVvBZW2A6G1GUyYy20dIEkEyNtmXRBmD5wrQ6hQHPjztNFqD2KXu R6d0Llxz2ox/HfAmgjUhaTzrulemNDuDMNYxgxQvn1XsCKhmar9VsHP4tMdQ9kc= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Wed, 07 Oct 2026 20:07:46 +0200 From: Nicola Vetrini To: Dmytro Prokopchuk1 Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v2] Eclair: scan the last xen-syms linking pass on Arm In-Reply-To: References: 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-4011c0/1791396467-518C5CFC-A2FFB00D/0/0 X-purgate-type: clean X-purgate-size: 4428 On 2026-10-07 19:12, Dmytro Prokopchuk1 wrote: > The hide pattern .xen-syms.[013] leaves pass 2 visible. On x86 > LAST_LINKING_PASS is 2, so that is the final link. On Arm > LAST_LINKING_PASS is 3 and the final image is .xen-syms.3. Pass 2 is > usually only a symlink, so Eclair saw no program link and reported > every > translation unit as unreachable. > > Before the analysis build, read LAST_LINKING_PASS from the architecture > makefile and the pass numbers from the foreach list in > xen/scripts/Makefile.link. Hide every pass except that one. An earlier > pass that is a real link stays hidden. > > Fixes: a401b5c9dc35 ("Eclair: re-enable scanning of the (almost) final > linking step") > Signed-off-by: Dmytro Prokopchuk > --- > Current patch isn't tested, sent just for review (if this accepted, > I'll run pipeline). > > Changes in v2: > - update commit message > - generate hide pattern before analysis > - read LAST_LINKING_PASS from the arch Makefile and pass numbers from > the Makefile.link > > Link to v1: > https://patchew.org/Xen/2f67ef7c4593d3ab94b75b5b819e7e046e055796.1791293680.git.dmytro._5Fprokopchuk1@epam.com/ > --- > .../eclair_analysis/ECLAIR/analysis.ecl | 2 +- > automation/eclair_analysis/ECLAIR/analyze.sh | 3 +++ > .../ECLAIR/generate-xen-syms-passes.sh | 20 +++++++++++++++++++ > 3 files changed, 24 insertions(+), 1 deletion(-) > create mode 100755 > automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > > diff --git a/automation/eclair_analysis/ECLAIR/analysis.ecl > b/automation/eclair_analysis/ECLAIR/analysis.ecl > index c6e1a7a95d..df1006bcaa 100644 > --- a/automation/eclair_analysis/ECLAIR/analysis.ecl > +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl > @@ -37,7 +37,7 @@ 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\\.([01]|alt\\..*)$"} > --file_tag+={xen_syms_tmp, "^xen/\\.xen-syms\\.[013]$"} > +-eval_file=xen_syms_passes.ecl > -frames+={hide, "kind(program)&&target(xen_syms_tmp||xen_efi_tmp)"} > -doc_end > > diff --git a/automation/eclair_analysis/ECLAIR/analyze.sh > b/automation/eclair_analysis/ECLAIR/analyze.sh > index 2356fc4007..ef59e87212 100755 > --- a/automation/eclair_analysis/ECLAIR/analyze.sh > +++ b/automation/eclair_analysis/ECLAIR/analyze.sh > @@ -78,6 +78,9 @@ export ECLAIR_PROJECT_NAME="XEN_${VARIANT}-${SET}" > rm -rf "${ECLAIR_OUTPUT_DIR:?}/*" > mkdir -p "${ECLAIR_DATA_DIR}" > > +# Generate hide pattern. > +"${SCRIPT_DIR}/generate-xen-syms-passes.sh" > + I would prefer it integrated in [1] instead, running in prepare.sh. At least we keep these calls to ECL generation scripts together. [1] https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/eclair_analysis/ECLAIR/generate_ecl.sh?ref_type=heads > # Perform the build (from scratch) in an ECLAIR environment. > "${ECLAIR_BIN_DIR}eclair_env" \ > "-config_file='${SCRIPT_DIR}/analysis.ecl'" \ > diff --git > a/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > new file mode 100755 > index 0000000000..e3795e8234 > --- /dev/null > +++ b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > @@ -0,0 +1,20 @@ > +#!/bin/bash > + > +# Hide every xen-syms linking pass except LAST_LINKING_PASS. > +# The pass list is the foreach in xen/scripts/Makefile.link. > + > +set -e > + > +cd "$(dirname "$0")" > +arch=$(echo "${XEN_TARGET_ARCH}" | sed -e 's/x86.*/x86/' -e > 's/arm.*/arm/') > +last=$(sed -n 's/^LAST_LINKING_PASS *:= *\([0-9]\).*/\1/p' \ > + "../../../xen/arch/${arch}/Makefile" | head -n 1) > +passes=$(sed -n 's/.*foreach n,\([0-9 ]*\).*/\1/p' \ > + ../../../xen/scripts/Makefile.link | head -n 1) > +test -n "${last}" > +test -n "${passes}" > +hidden=$(printf '%s' "${passes}" | tr -d " ${last}") > + > +printf '%s\n' \ > + "-file_tag+={xen_syms_tmp, > \"^xen/\\\\.xen-syms\\\\.[${hidden}]\$\"}" \ > + >xen_syms_passes.ecl -- 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 Oct 07 18:11:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:11:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442651.1660182 (Exim 4.92) (envelope-from ) id 1xEW6r-0006X1-J1; Wed, 07 Oct 2026 18:11:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442651.1660182; Wed, 07 Oct 2026 18:11: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 1xEW6r-0006Wu-GP; Wed, 07 Oct 2026 18:11:21 +0000 Received: by outflank-mailman (input) for mailman id 1442651; Wed, 07 Oct 2026 18:11:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEW6p-0006Wg-K8 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:11:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEW6o-0012q7-PM for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:11:18 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68b33-2eae-0a2a0a5409dd-0a2a4505d320-24 for ; Wed, 07 Oct 2026 20:11:18 +0200 Received: from [40.107.162.125] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68b46-4cb1-0a2a45050019-286ba27deb6d-3 for ; Wed, 07 Oct 2026 20:11:18 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAWPR03MB9788.eurprd03.prod.outlook.com (2603:10a6:102:2ef::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 18:11: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.0472.016; Wed, 7 Oct 2026 18:11: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=KTikAHlXg4PIJbquW7aPk29t4tAuqKfY/wj7cIRT41ZUZ1bbVaBQZ4CCgSTEiqiJ8UiCIHgM/wNElGQ+ycODX4Gc2OXSks3YT+Es1on+79GSsby2+R9AwhhgAEcs2cC1Icn2gosz4Dv2CiwHr8dn5VVbRspG79XpEZ21RU3zwST9JLVbPLEV0ZkO9vPHmqnV5IwiX3k699HsrmBWWPyHxhIe/xkCzusDEqfaovReaFM3Hwe+MlFMXMJJfRs4ySN8WweodENdDRuvo2G33fOGEierNE+uiak5pTKgrhmZAZkKqZ3R/X+1daC1MAaAF7GkXv6irOmIn0fmSSkMg78xaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kHdT48kq+wT7uC4uuIfGYnDjzFbwLpZbUDog5uvLSF4=; b=rOFocPLFNhk6V/zuL8gkqkpXJQCLC7+dmOpcYSLPH7ScVZAfYuP+pWXeRADDgmGS5ynVBqHUAutvqV28NYSZUpcMMnxqNX7H3jzqldD+tbzOmQcfrW3kmEeIep8tc2d6BnNCgz4IbmmyBMLeE3MVncvL/gT8NVKXLCtKbp+nJmniAUHPWhLVUFHyVmdDdVOWFM7TyoBq9mKsSI0G/coiuSayuKqO0+WlQG9FKuFzbVy7tAPRZHx7qphod58HBBMOkxp1v3ejpJbIjeaeHLr7+5F2Oz2zAXgfdxaqr2LcE/UHuiMCR5EkyUBl3GGtlA5pbzw0V22Fg4MVaO+XGWQIKw== 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=kHdT48kq+wT7uC4uuIfGYnDjzFbwLpZbUDog5uvLSF4=; b=mu43uyBjhQ+k6nUBAUnUpUCbcuebkX8O0nIxngDkvI63GRiOuEShX/3sGgudoIZ5wYDoZBgE1gsuPRlj0HSTF3/wse4ZaGdDDrFCCMSb8DB9362C4z/F2J2rcC2tnCMsql4CyJI5G9pmOVSNdAus9nkeFJfP0VjmFaRkevgU494sgfCtdNEp6hWPSWCtm/9PUdmbDhk8Hrad7kh4LvLIQc1XMdACThVuA6lTCHGOultRmFXJ1UO92Pwp/S5AFOr1F/CnceIE/sBsNSf88VYTlqFK64wzDCw29Jn8/nIfgvGNfhCK8Y9bYokKt3acyigL0Mif3xnVEaAS6tN7odktoQ== 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH 0/2] tools/symbols: fix oversized names and token expansion Date: Wed, 7 Oct 2026 21:11:01 +0300 Message-ID: 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_|PAWPR03MB9788:EE_ X-MS-Office365-Filtering-Correlation-Id: 01c036c3-9dca-45e3-49cf-08df249e6112 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|56012099006|5023799004|11063799006|10067099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: bB+kHm0zBOhKFoSFiHH0VYY7Nf3shINLR5Byh50N/jMnuvrHgpzveVwEs61F7swCG7LGeTsVv/zdL0kgNgi5akJA3B4J77mbe7iJYEqqnR5bPvxduj51J6HYOQD9Gejy3tGdw+oySHVX/3Kwjkm9LF5DTYnddrv1lBkEUtlwJQiETjH/ln8fT+r0PTCrAcRrv+383OL2VIU7qe/pONWwqBTRAmb+h5MeAFw5SRjXQM/tzOUZpLyDMMp2R7M4oszQQslcqkQFPHJURhyPeKzOS1/ZR/p4cSyB3syJubkekaqmqgAj70hrsOiWsxZuDo5oirQ6kmw2Hx2062l3Jo069yElninJiKTAtSGKp3zuqthY+mQ/zoIPG4/VSv7ukKHJG3CWSFEOK7zvAsCi2XKxlA4ntYmBU8C+oBtrfTCTFvSU3efbvB/PD9GoUgzhb6HqnEDhTuX7DHvtBgi/xQwDKZjg4GeTJquN3g1fP7qBTJ8ZPzPj6l9fHNBiPyo05anQt9hhbQj0lQSeV5lwJGPCZ/8ePVSps046N7Nbndxnb01j7ySnihKfFeGOTFd88ekldXrL0cQbFHz5FJnqe9ltW/F7zTC05nIxT5R0kQjj3tCnc/OU69BsfoaQGD+PKMrDG1IeJb1pTV0dcqvhpc3R1rrGrdOoQky7pLAsPYP5GNI= 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)(376014)(1800799024)(23010399003)(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?J5pSUPOBmC/8MRQmonkFoZP2dFIC0Tep/ObioHoLFFQ1nIPCTrtCOiAwCl5m?= =?us-ascii?Q?Q+owXmz9QW6hZdKInZLFP3bAvIfEsnkqVJEOLpKg7PeY+/ukZgLKqz3YW0s9?= =?us-ascii?Q?y46SJAhMDdiR/HgwdCLaulPaPuX44740XzZhyq5CI5+/oColLMHRIh0gKmQq?= =?us-ascii?Q?idMxspsJ8m8+yx3FXViWiJZ06N56uwPxlUh860rQA8++rsauH3xAaf/FBY79?= =?us-ascii?Q?lkNbnnFByJHRzxi1uOYZr3l/drL93VgjW0EOe1YQAJzfEWFqS98B0qLNMsA1?= =?us-ascii?Q?kWkT4ngGzzURCC8HYfC5Aqnk7KngOHjF1fqT444Qyg4DOCv3LTx+pn4AT4hH?= =?us-ascii?Q?8frolIlQr6UGt0do4Z3djBibuNHJOupm7MX9DElKUM02Q2J5TrIjcakGdKyk?= =?us-ascii?Q?9O9eyszOjv8AEaOlBF76kjoErcmnFtLJCbkFBLa5pFcsRfffGXE00cwSRIK6?= =?us-ascii?Q?NBg+V7XyLTTnRPYZT50OhPPlW8xUkYvtTRcfs/YPVeaPwChgO3plNAG+mFhW?= =?us-ascii?Q?zFol5FBI/l97JkaNmduqsX12JVtHm6d9KgppGUuJLf3G9YA4qYq9nN2El990?= =?us-ascii?Q?63G2uCAWpMAlLZKMmlx4Y2xr/rJc3hce8R46s4JJQ3AH4p5QyLw7VbIaXAFK?= =?us-ascii?Q?W+dYLFLKxRDRbPax56062LaWSdrhW0DIz0oFpX28Z3zj62G2v2YnUxfDp4cy?= =?us-ascii?Q?3Csr4wqMoRwdrSSuw0BCSKXvhuYslJe+koPLR+52PA28xbWjOviUmjRQDpKQ?= =?us-ascii?Q?u2K3Og1kntyVIrlGeqcN8U/8SUloeLQ+CcV0lT82Bcez0+rXg3GuPw9++jZV?= =?us-ascii?Q?1cGwWTo2LZkWV0MZjWoA4kIBPxQoxn6NeA6nUK5/XMGHQisJN1D+9XlN8kF2?= =?us-ascii?Q?Ws4OZ5qZWR7UabbkCsFInbcxPejCxYVKk9mo1uYf1xsV34qFgKdnxERzfXlI?= =?us-ascii?Q?4TJelHtstOIex8Wnkd57cdeQWyWmBHoJxH4UqQSr0zzzGDwnf+/q7r6H+6W6?= =?us-ascii?Q?qNsanvdW3nH8eBwzzvB3jD5UnSlrj3Cd/M5hHhkY9G1DQz8S5fKNUXjh17tR?= =?us-ascii?Q?t5dySwia7cVb+FOZUtUYVVdSQSNLj+M9A/ezNUm/nLKJKMjotF4luOC5G06v?= =?us-ascii?Q?SrObEEJVa523yO+3cv3zC4C8dW2DqrIk8l0H+jaJyJ7vx46mu43W3gFn9fIR?= =?us-ascii?Q?ymUiIqSUSZBQas7MGyfqv1beceIo/xpZnmyD1bMED19LxzMtbXNSBDAyb93c?= =?us-ascii?Q?EvFrdpR4t4AYhCpKR9BL0pDxvZeBpo0LRDHocqwAvpmqtGRGIIrq86UrjhWM?= =?us-ascii?Q?3R8hX18Pq05TQd52QtNGRTq7KG+QIv8b0Fv0FHrAr7OJUWPDOwXwC5aIhgeY?= =?us-ascii?Q?VpQHmJrdEvDOl8jb0jEk8e/Te6+iksjP4flffCN1WwYWjWUgdlaUQ3TNpfDa?= =?us-ascii?Q?T4mPCttoZC3WSXpV8cCS6TZ2hnSVHpCKGC/jXz1AcQ71WH6dEgkSQtjjiXpc?= =?us-ascii?Q?Yu2cmh73AJ5w9LkZV0wC3QI613ZeDsTbWuK/g1hDV43uxoqFJ363QYLcX2/o?= =?us-ascii?Q?HsOr0NTvutqwCAZTcdPmMDRJhJzyomm5QJ632mczIx/wLErMaGpo3z0oolD2?= =?us-ascii?Q?TKhVD4ng86XyuKf/tYqW3uMcLmB+Vp75LHCW0GtNjiDaMopUVzgNLR3a+naY?= =?us-ascii?Q?6sHZb/Z4CkEKWa9rPtjoPOUTpeUUlWZW8aS/iXJJdSfguV17TGaVUugfZp7F?= =?us-ascii?Q?bfL2OGGJAw=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01c036c3-9dca-45e3-49cf-08df249e6112 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 18:11:16.3280 (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: dLvGaU++TGO3bSfOomDip3YQS6lbSiTrMJFEAeo2OiosUBMlRTFUnEITZLx2bEXE0QOvC4EzZGe/fJUg2xNzdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9788 X-purgate-ID: tlsNG-c201ff/1791396678-F66B52A1-44B3F722/0/0 X-purgate-type: clean X-purgate-size: 2103 Hi all, This short series fixes two bugs in the build-time symbol table generator (xen/tools/symbols). Both are host tool bugs; the runtime code is not changed. At runtime, symbol names are expanded into buffers of KSYM_NAME_LEN + 1 bytes (128). The generator did not check that the names it puts into the table fit into these buffers. Patch 1 fixes the first bug. In SYSV input, local symbols are prefixed with the source file name ("filename#symbol"). A long absolute build path can therefore create a name longer than 127 bytes, even when the symbol itself is short. A debug Xen build on an Orange Pi 5 (RK3588S) crashed during the boot self-tests: symbols_lookup_by_name() expanded such a name into its 128-byte buffer and overwrote the saved frame pointer and return address. The patch rejects retained names longer than KSYM_NAME_LEN during the build and prints the offending name. Readable --xensyms maps are not restricted. Nothing changes for names of at most 127 bytes. A build from a long absolute source path can now fail at link time. On x86, in-tree builds use relative paths and are not affected. An out-of-tree build with the default config fails if the absolute path of xen/ is longer than 78 bytes; the longest such name is kexec_reloc.S#compatibility_mode. Patch 2 fixes the second bug. In the compressed stream, each symbol is stored as [type][name]. A compression token can therefore expand to the type byte plus a full 127-byte name (128 bytes), and write_src() adds a terminating NUL. Its local buffer was 128 bytes, one byte too small. The patch allocates KSYM_NAME_LEN + 2 bytes (type + name + NUL). This bug can trigger with fully valid names, but only with a very small symbol table; real symbol tables do not hit it. The new size relies on the name limit from patch 1. Mykola Kvach (2): tools/symbols: reject names exceeding the runtime limit tools/symbols: leave room for the type byte and NUL when expanding tokens xen/tools/symbols.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:11:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:11:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442652.1660192 (Exim 4.92) (envelope-from ) id 1xEW6s-0006jh-R9; Wed, 07 Oct 2026 18:11:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442652.1660192; Wed, 07 Oct 2026 18:11: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 1xEW6s-0006ja-MI; Wed, 07 Oct 2026 18:11:22 +0000 Received: by outflank-mailman (input) for mailman id 1442652; Wed, 07 Oct 2026 18:11:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEW6q-0006Wm-TI for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:11:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEW6q-0012q7-AB for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:11:20 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68b33-2eae-0a2a0a5409dd-0a2a4505d320-26 for ; Wed, 07 Oct 2026 20:11:20 +0200 Received: from [52.101.65.72] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68b47-4cb1-0a2a45050019-34654148161e-3 for ; Wed, 07 Oct 2026 20:11:20 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAWPR03MB9788.eurprd03.prod.outlook.com (2603:10a6:102:2ef::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 18:11: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.0472.016; Wed, 7 Oct 2026 18:11: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=PbBfH6jY8/4fr0pyCcc5K9En9PqUd/eft9GL01ElB4JPDW2wCaAXL0gE5ajmeCoEo1TJ8d7zMKaoyzbbl3564gpFUqHCvMj4AJFMtxsxOxYDpi5CjJMm0VtYfph3A16HIX4UdgL7BLlwpd2RAMxWhN5YzRw37036uUqjnjLvaDYi32sOquDJpFUQOEBDq8HUfGxW3AVnOnkbbzfozc+Eg313oBEoiFQoX8PRyQPFs2MjCyBZGfKm0jZgzp3GHHOmP1dh+G8l8rPiFIdr6WDSQoU9RpBib7TM2Z1S0X3xklSdJMCXugf3JUEm2AdexsHU3XNwHtmqbXkYxNeTYNpLxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KJ/SWrGIpUv/PLRbu/p6/k51GXDlaNdmbUFmS03sfGo=; b=Ydnax2fSyFb6nhjX1leLzRUo666C7y3dYNw9gEJJE68kZLO63ly7FOjIn1RVo8VUX3rbzboHpS4v/AlIQh2kH1QUO5/wftJYmt0e0rA09piuJ8rs2fisLPRZoH8y81zUtUbYseWs1cyBC0VeXc00N4dZ0tGUaWXpZUs0zaRtHq4noe+lbEMdCjlnxEeyAo7sE5vPOc1CDfQ4vZ57qzFa70yG678085qYlI45jnPZvAl73FEVHbfiWexS0GnRjeKccj+mB9UgF9MKF3CLjozPuGuWtV6Tkwwf+Va2CKCWaax1g+TNrjjDuwA13hPAULB+mdRvs3Y+iPbSnVYg0ClzFQ== 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=KJ/SWrGIpUv/PLRbu/p6/k51GXDlaNdmbUFmS03sfGo=; b=VmfoKegU41IM4HMFgvi082651Gtu0tu1+b1fbreGt6/HTo+qu8HgCnriw0Ge8br8tqcGToyQWA+fP83Jkftj6SszYvuCjFL1zHuxPLZmD1zf7b0TX/NNW3aVJ3sRqPpE15i/5KeQ/P9P2ga3c8BC3FC4wVaIvn1gztzQAwyyeRUzEsc/aEn4cwUPslbYLIhfYJLUJMkkzhP7sIn7AaRCSCbZX4VNG2wBF9krcQR4NzIcIU8Rxp78NaP//CAmWZN6AzU19ZoLUfyAHC5je2CWyVuejwcOaoW74NMgPl3OYSPZZqHE/TpYOAccK8xcAXSSOkkwtwGnPYQqA7XxQ5iKMw== 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH 1/2] tools/symbols: reject names exceeding the runtime limit Date: Wed, 7 Oct 2026 21:11:02 +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: 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_|PAWPR03MB9788:EE_ X-MS-Office365-Filtering-Correlation-Id: 4539ccd7-a4d8-4cb5-98f3-08df249e6223 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|56012099006|11063799006|10067099003|22082099003|18002099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: hhaFBTVMKT5Lp9L+9BHKYekxkosV0arxSZWoZ3RbNq0I2ptWQkAmFJt3U00ka26gLDmpp3V+lJW+ghy2XDiFZz9D3AO8Eeb/BMWihOacv9eS4Ior14vI75hCRuEFLbLzbrMpcH/xcUrNxpDhFcgmZT3xgw65mdLxF9URWOezSaHcYIEEN0TmANdvnLAcC4UPtTYlkFmZcxQ6eCduLjHZ4YWeIaOpu5G9juJ8FDqzR5iY3tMtHW0akZI2d7FLbqBWTEB4SXbYNE+FcPNnH8eNwx3m7WtwN2DMsrXLGZoQFbp++H8TIv2eZmxDwqtSDbrIYomB+Kv6BE1JL0qpQoSOlbhj+/PL+xtF4fLUpKN//7wSUfsDLEpMkVWb+QpQ7YFpX539dLNgsUH+zW8GDT8sIPVV5UnIzz0WlWnZHD5mR8l1o7zFLeFVMTIJimjxZQwyr7pb98uRzD6V+krK/BVSV1jd+B/5lo6OYzelC9duLSN5pXxh5YqMY7YYMLK4ZBjk+Ev4vNDgbJUl1ZBzTriAj94mG76Ay3pDY+NB7N+fdBuJ+HXgumzZQsE5wGpOwwXev/0pyT8/6sxnyW9OFuzZWZjCeJsRKoU3sBr8vPRW3ipb36+FcIIsoYiw31eXl9w4EWdnAYdRysdbuFzq+2vNYXw4Evo87JanhcJnj2nv2Tw= 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)(376014)(1800799024)(23010399003)(56012099006)(11063799006)(10067099003)(22082099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?nHchEU1yBLCXcxysOgqLrWpGwKTBQXVe/F9cHMivU7mMTxm4ihuSh3XBuhZU?= =?us-ascii?Q?9SJxVMKLjpDV0xeHGtpaR7AUVwGRlzUusIOJu3HoL8vfI5nJjr8LRakcxCtB?= =?us-ascii?Q?XiOyLSyineDdrVUxHUdooWzXojSZ4a/r0Xhsr4Wzhlvv9Uzt/LAQFpBlzfjt?= =?us-ascii?Q?+iMkZyCjGAcOxtKtcDdCIA+GlJmYrwjuiqrtXpsIKa2bmB1MxalsbkWy0iH/?= =?us-ascii?Q?kerE26xW8FjdGeoJyRch8hQEzND9S3Kz7DztBNMsxUCrjEAqaVXFiSnhpeYG?= =?us-ascii?Q?4z8aa7GEAxM4UCI8VnEi25ySJil7u6giuaFlwOpfDM/AmJL1ewnwH25toeG+?= =?us-ascii?Q?UgW96taI2Rz1T4LzqpUct68NBAGMY8Z3csFU8oXXnbSRajteiNXrNZ1eL8gd?= =?us-ascii?Q?LryWPQek7cRkJxSWB6qDrgpQG2a4pJZQFygTI4UqYzMZ1s7QJDg3Re0gH4rK?= =?us-ascii?Q?kE5s2H1HbHznB4ueiVdJw56A4NHu/IHGlowLSMTxsVj6OAyEvBj1PHZBm9mt?= =?us-ascii?Q?zRe63YDHm6jSPx7+8g3dIEdTSUjmc17P7ipBv08tiKutx2sKQvfQFks40cQD?= =?us-ascii?Q?MHpy9lFEmoAQlulJ0ei2AAUhoJ1G0QctCBV5C375qJiqj2WN7xrujwLkRO90?= =?us-ascii?Q?vF0/MlQ5poqfUmKin7YRRnZXnnJI25hZ1BbaS6DsrHubVUH3uS+St+PcJ/99?= =?us-ascii?Q?BvNQQaFyKx6j82IPo9Udo8RNxHk9JY2jkYna09ATWs/ob65C6KfJ6iCM+6bF?= =?us-ascii?Q?O9AOI2Y9wc5ILBVVVp+2wFpjzUgNVMUJecMGqzp5EQgXSm09BxE5vB3vw+cq?= =?us-ascii?Q?TizRKA6IRrJvs4nwoz4y3Kc9KnCbn8mteEYHRh6Y6xLtHvIr7iSpXLOtDhuw?= =?us-ascii?Q?iz+tsLK7tYNr/RVk/lBnf4R5pmn8w4GLWrBlfnmf4HX9Pi9AxZB/ingyYygn?= =?us-ascii?Q?zJho02BdbGE4Va41QiPB7T71DfLsaqtG/06aI7JWmW4ngtwppUvOZWrOn8B7?= =?us-ascii?Q?HMGSzS3CswGMym8sQ+CB9v+egxHW7jwPLKrkq7x9Bk9CXPibJn6IHSR/sLUO?= =?us-ascii?Q?GnM+p+4xjtscgQXTUET3QCafT7wCYIrbOeq49dWBVHrdcEpQFA2xGtEw6Jbi?= =?us-ascii?Q?3nVFQ/E8shBw7q8n264uP7OjOykxaOcfI39fLU8s4i3+7OUgskCqgJUZ5+Zo?= =?us-ascii?Q?Hx7gUpvTiPUxcIlqVxdSyTEO8cB7rhjCv1L6qiiGG4aovRuWA/BfslI2Cgul?= =?us-ascii?Q?fIQMho+rh5R7V+MwH26pK1/Ot0ZIAoVqjQpgK34G5gTYATkiX1ZSYlEe8b03?= =?us-ascii?Q?4ujKjcrVJtyjl0P4VfgUYBwzq2jZIAlwb7g4BKTw06zt2i9AS9CmFdoUrOaX?= =?us-ascii?Q?Qkp80HV82DI5yxie0G7bHVQLk9a6I3sfAKMFU0eWqy4XtnMvAJElTjiIO+oE?= =?us-ascii?Q?rNAe/4/1iujslkq6L2eWvwHhatBLdfOmK5XfAjha+560/4lYJWClxSWeWEOF?= =?us-ascii?Q?MnZwK8dBZKtO7mHFlnCstjhl27aVfc/CZePMKa3SFylSVK+dqD4cx+VQd+iZ?= =?us-ascii?Q?p6q6yqXAaEpDvN1k+5ZVQ4c5ZKUlwpMgaaSGjhbAYUBB29r3k+CtvzqXXxgU?= =?us-ascii?Q?E7AWmuw15ORPHPMcSpAm3w3BLTAnd/+hosYNouPBUtUG8yBW/ZVomOFq/nj4?= =?us-ascii?Q?Vecdb3f4Mr3j+DPZX0GkQDTaajCHXxRw59xn9T86cuRzZb4cZlkN5Ompi+IR?= =?us-ascii?Q?u0M1dAGuOQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4539ccd7-a4d8-4cb5-98f3-08df249e6223 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 18:11:18.0565 (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: kXSbbOQLRxmo8g78XLRtr/5gY6OnFeT/u4s3D/tKGU9N3VBUCLO50YtJmesoGwGf4TiFQctd9aGLvskyx+GaMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9788 X-purgate-ID: tlsNG-c201ff/1791396680-F78BE2A1-C8F1633E/0/0 X-purgate-type: clean X-purgate-size: 2507 The symbol generator accepts names longer than the runtime lookup buffers, which hold KSYM_NAME_LEN + 1 bytes. SYSV input prefixes local symbols with their filename, so an absolute assembly source path can produce an oversized name even when the symbol itself is short. This caused a debug Xen boot to crash on an Orange Pi 5. The expanded name ending in mmu/head.S#identity_mapping_removed was 145 bytes long. During the test_symbols() constructor (CONFIG_SELF_TESTS), symbols_lookup_by_name() expanded it into a 128-byte buffer and overwrote the saved frame pointer and return address. The board reported: (XEN) [ 5.064767] Hypervisor Trap. HSR=0x0000008a000000 EC=0x22 IL=1 Syndrome=0x0 (XEN) [ 5.066709] PC: 65766f6d65725f67 65766f6d65725f67 (XEN) [ 5.067190] LR: 65766f6d65725f67 (XEN) [ 5.074749] X27: 0000000000000000 X28: 0000000049000000 FP: 6e697070616d5f79 The FP and LR values decode to "y_mappin" and "g_remove", respectively, matching bytes 128 through 143 of the expanded name. Reject retained names exceeding the existing KSYM_NAME_LEN limit before compression. Report the offending name and its byte length, so that the build fails with, for example (name shortened here):: Symbol '...#compatibility_mode' is too long (128 bytes, maximum 127) A build from a very long absolute source path now stops at link time, instead of producing an image with a latent overflow. Apply the check after symbol filtering and preserve unrestricted human-readable --xensyms maps. Fixes: d37d63d4b548 ("symbols: prefix static symbols with their source file names") Assisted-by: Codex:GPT-6.1 Assisted-by: Copilot:claude-sonnet-5.5 # host and x86 build tests Signed-off-by: Mykola Kvach --- xen/tools/symbols.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c index 9db1c0a20c..e15273a8ad 100644 --- a/xen/tools/symbols.c +++ b/xen/tools/symbols.c @@ -485,6 +485,13 @@ static void build_initial_tok_table(void) pos = 0; for (i = 0; i < table_cnt; i++) { if ( symbol_valid(&table[i]) ) { + if (!map_only && table[i].len > KSYM_NAME_LEN + 1) { + fprintf(stderr, + "Symbol '%s' is too long (%u bytes, maximum %u)\n", + SYMBOL_NAME(&table[i]), table[i].len - 1, + KSYM_NAME_LEN); + exit(1); + } if (pos != i) table[pos] = table[i]; learn_symbol(table[pos].sym, table[pos].len); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:11:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:11:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442653.1660200 (Exim 4.92) (envelope-from ) id 1xEW6v-0006z3-4L; Wed, 07 Oct 2026 18:11:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442653.1660200; Wed, 07 Oct 2026 18:11: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 1xEW6v-0006yw-0y; Wed, 07 Oct 2026 18:11:25 +0000 Received: by outflank-mailman (input) for mailman id 1442653; Wed, 07 Oct 2026 18:11:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEW6t-0006tM-LD for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:11:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEW6t-0012q7-1N for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:11:23 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68b33-2eae-0a2a0a5409dd-0a2a4505d320-28 for ; Wed, 07 Oct 2026 20:11:23 +0200 Received: from [52.101.83.103] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68b4a-4cb1-0a2a45050019-346553671815-3 for ; Wed, 07 Oct 2026 20:11:22 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAWPR03MB9788.eurprd03.prod.outlook.com (2603:10a6:102:2ef::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 7 Oct 2026 18:11:19 +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.0472.016; Wed, 7 Oct 2026 18:11: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=cxUoUOMPREnxu2BL0e4HlLcJUeAbNFQW5U6skpwzzI8xzOpsS3U27SOl1O4fHwRFvwNHjkC1AJ2OYusyZlXX1NEoOk+fSgaIbf7WnG1PsbEMYs5NwHOTc3zQ5VRa1B6WevvGsTCifvdMcrV2VGDhw+zFbNYk1nPuopJpAcsRr9Q8yO+gYdJ7PtCmkRzYzZQbuXxFYpya7znBTgmEH0E1XdpzOXIr/SI+a5IW2lqPDeBozF3eSZFYd9484ohSyHvFZFpbOTblv59/jEHWlJ5BPYMEl/xigPbpOMO7PC9iWgxp4zcY5RtoSwo/nPt9aJRSyFpVAPQ1bIWPKQkn0p3UNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vT7c5Zm4QjQGT2duyBnbTwAOk8VXrr8iH57eJmZ0978=; b=SS0KjzNGqwVMlxizri/1vONlm9qur7XZ/Kj5IKEwHVljxeZlxYkG3D1ftF+TvSS1+hYanfu19Y5uhE5837/NypMnE3nGbR8T/9Ysr8kk9ZRRa1EqZjWB8sATfTJYhwO0OUTXdQE1SpxSdjgXyeQNvT61/cK2326pwznllUanO6ouzuT74XCGVIxq/HHNU8SlTJkO08tQA03JgUcqHbSFSeQDhIgz9UlKHYA1jboMQc1ZIT2xKbjXu+ObZxkar022png2nFkWEs9dxBu5LJ09mzJBICyGDBMeg8IKwi3yadaQbF2LgQciBZmMoq9uoaVHy2LJ35VkQq1L76nWvaaQ+w== 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=vT7c5Zm4QjQGT2duyBnbTwAOk8VXrr8iH57eJmZ0978=; b=UURqZKwFwo32gCOBiTrd+B7tsDGDSGcvIa63UguNeojAY8AOzU557nUJpwKemMCcrn2UGM2mqNM1nvtOWsYLDFJU5jtc25+RKhnM+xNQEsnroQ8Zya+uDN1NVbXYwhaqmQb1jwoM0KLNU7Xsm06CN9BIm97kDErWt2iVV0hp1dHjqwvugAW1eJ5cs0r7luOqvAC0Noe2/s9MJ32rhiUfAkO08NuFvf8s16j8qWBU2xlBkE1jLl+dWD76ux1gru6knQp+vdZNxti2Y5nV9EwgXzIcRbhqjv5IJZd8+cjQSAC35WZ3KdHUOZdFP9uwvlmn7dIyZC0ARMBSByO1Ef6FsQ== 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH 2/2] tools/symbols: leave room for the type byte and NUL when expanding tokens Date: Wed, 7 Oct 2026 21:11:03 +0300 Message-ID: <07789bb485f6120e82bc5dc8253ab45056af1004.1791384310.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: 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_|PAWPR03MB9788:EE_ X-MS-Office365-Filtering-Correlation-Id: cdc59912-1f33-48b7-160d-08df249e6309 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|56012099006|11063799006|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: ivIif4qv+v5/t01lAR2HnPQdOjHfXEw2f0cGXUX9zdSB17xA/xUJDAl57ebipd5XpDKNij3d2LDh0WF1IekpGtZnrYlXE5gphCi4aYQkg4YmOa3J1RdAoHfviIs7xtBMOA+SOuhveeyEFBN2Vo30yrjcq/644iBO4Z7HlHyhUFXAY5+DIOo8MSgd23DgW+g0QZ8cUJRl66dHBJsz5WDugzJe+eheD7jSbT8N0DwYN00xym5MZJDaQT1Ndp1qh5HWSlC+vKzm81noxzjjDvkr7hxmA6/utftM1T9CHmjBE1NpNJOvEHMOxLBDKB0B05N3x3/r8z5u8Y556Kp1R4wbonnq3RD4+ITj06EbeLkKQ9xOHx4Bss+gZBTkET5tDKH3OpNFYqvMU9G95Ebah4JLw1GZQ+5qbsFbxT3bkVK6dafny4kJOFb0uR9uokXTq7ua3aOaKXlrkVH98R7E0zynKM7levCu+ierb14M6KxMS+QFkhlBjrvzaq9mrSOQ37tTaq+yblBLsaCtKF9YT9BLMUc11vNL9WBNziSAf55iNem+p0/HRI3pbusxDWPODNx0UYT7OvUvxUY2/Se8Z7L3zan70LSlinaj4pEMAurJ8QgVWg5UIRqzVB5M8hFVQSNY1EbjK0TKANuPxdSwQ+YjdNPoiUqo7LeUlZAQPs7e42w= 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)(376014)(1800799024)(23010399003)(56012099006)(11063799006)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uaB7QEbWhfPs6ILWeDW4F4ZFfm0sQ5TTBIR66rtUY439cVJIsOtS+U9ITls3?= =?us-ascii?Q?HfOwwobIHOwQHt+OujrhIQ2OXNWVOwe4tvtbmdfBNwgUk07eG1J77GDRLbA+?= =?us-ascii?Q?9sfDipm8ZN8ZFRo42sH0hsAlOjoOnTxJWTq6lUa+CKYABNDub8b9G+zAVYhu?= =?us-ascii?Q?iTIOrlnp4JwOYEULLy9v796LfHiiLqX503cnr2GwpIoPNm1kyh0/6Q+eJMfh?= =?us-ascii?Q?W+XJ5UbHGsAwBrJPF5MRAia0POEiwzCP7NSMmz2PhNp4VqJJw6yHj2uw1IDC?= =?us-ascii?Q?8wwmPjrVs2NqTKVQ3pDWw590xpl1boXcU6/4oqS8bs9RBe0GS1BlMc2isOVX?= =?us-ascii?Q?pkFfICV2bSrZpK9r2GGu8yO9f6DkDaXY9q4/GkvTYi/Ktx185oX2xdO6z8mt?= =?us-ascii?Q?FyuaniUvzxlGjogNSabdRiZ8MIj1ohB1SiBBRmWGRGrb2DF7o3Lcd5XUSW16?= =?us-ascii?Q?4yT+Q2MVoP8+vnH1dF3Ldawz8PyRLqLJIpQJFGcE0kTr1O1XQgaqf9pvSrZ6?= =?us-ascii?Q?EGCOZ4mUNILcsnJV8M54uamVRNxXXQM5KM5td3Olj4+gIUZYspZ18hhA2Svs?= =?us-ascii?Q?npw1JpRn9a/VT0KtEYQkbA3KdkbSGpfvTnHTTKt7gAiriETFiEa/ZrR1V6XL?= =?us-ascii?Q?HSe9qM3qPs9Yv5wBz1KiVio6JZ6Bz7UPrL2IYoZFejbGBwJ0gfHApBafKMvx?= =?us-ascii?Q?NFyLXALwlOHeeWEvlaP7judUDmzGLsoAiKEt3uLihkSxe/1wJRKNKk9Hf/6b?= =?us-ascii?Q?5UzS5pxQxE22xrmQVIO0+gCm5l5qUBuff8oMNlXtmaWgAqfkkk2yjEY/VQp+?= =?us-ascii?Q?AXmAyANgdlh/8UiGDTxqaba0CHG61fXGo6WoRMS8ArGdNi9GunyU4dVwDKlk?= =?us-ascii?Q?MzMVa5BpZEJ1n7dlq0A2ZaxljBsFE+EUbnDlM+OTmpeN2JG7drkshI3HGIZE?= =?us-ascii?Q?Ut4ZSBHRIo70YYxo2ZB03D9y2XpaemLBra5zf+lFt1FtjVTyBypGfWxjtMYc?= =?us-ascii?Q?a6VhWT36RpJROSUjrwm7KgAKZ5nFOL3HRr9tgwKFyvFk8qWm5+/T1EQmcnng?= =?us-ascii?Q?AaHfrtJ5hhGkrGmXS3oXUI89ANPmmlkqIiMelUgFXA/njOuLdwIWBSNOZM0i?= =?us-ascii?Q?h1NuwyQSeAG+j/FN10UghL1DOoT5CK/EHon8/ZgBL1GU1y46dL7PfhQydxtq?= =?us-ascii?Q?iJODkHAuyt0jt6sUgX8JRz6CCGV8CDA7aMwXcLqx5EBkQu5VzQVfZdiz7BaX?= =?us-ascii?Q?RsPlLAqMcA2xi870Z84mOmswoUJfSF6byQqUIrn9Vmzu+wi+n0o3ICpnNIqb?= =?us-ascii?Q?ysC+NTaT2z3jK+lJAxtxUilVk1DGkfoftBMXenNTNSeSiz9D3CKbiVULjIMq?= =?us-ascii?Q?lCLD0n9tKBmT5QDSmDsAPjm8zb3RdqLKCrlOpu6BmzVGQ6Q7MgowhmVOxwT+?= =?us-ascii?Q?qDe05iTWX9QCxIjq13NSIpyjwEXij7DW5AnmvsLLWUpzTCq9iKdEX7IQe6t5?= =?us-ascii?Q?fCWsWCYnZNrJNfhHgRB9HkygiZ+D8/yoRv0dQopo8WGzYv49im/ENoKZhnKP?= =?us-ascii?Q?SaTBwOfclZxE73hsu30yhxWTniiPGmHEksOXbZSh5vO1gCA2ymYTPiFhIONi?= =?us-ascii?Q?d3UbS+XVtzGmf6lYOolxHBnXsjbf5wqW2eEfloPZ9Apg8oFMypQYUs2u0pgu?= =?us-ascii?Q?pPeXZEAjODtfeAl7/cWPyeVXHIZnNfyBCRN93TaZWz8Pfr7WJrCI3AYEfpXQ?= =?us-ascii?Q?pPPqFVszEw=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdc59912-1f33-48b7-160d-08df249e6309 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 18:11:19.5602 (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: D/0IUk6K//J5WX+xMiO3YfQX67aDast6Pcy5s2Wg20O+UB2I60TcKHHQEPCsOjjr6J8NnXzDUesDlK8LksW0bQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9788 X-purgate-ID: tlsNG-c201ff/1791396682-71AAF2A1-652E232A/0/0 X-purgate-type: clean X-purgate-size: 2302 Symbol records in the compressed stream are stored as [type][name]: the symbol type byte is part of the compressed data ("include the type field in the symbol name, so that it gets compressed together"). A compression token can therefore expand to a full record, i.e. the type byte followed by an entire legal 127-byte name: 1 + 127 = 128 bytes. write_src() expands every token into a local buffer to emit the token dictionary, and expand_symbol() appends a terminating NUL to the result. The buffer was char buf[KSYM_NAME_LEN + 1] (128 bytes) -- room for the type and name, but not for the NUL. A token covering a full record overruns it by one byte. Allocate KSYM_NAME_LEN + 2 bytes, so the buffer holds type + name + NUL (1 + 127 + 1 = 129 bytes). The previous patch limits names to KSYM_NAME_LEN bytes, so no token can be longer than this. This is a host generator overflow that occurs even when every symbol name satisfies the runtime limit. It needs a token that covers a whole record, which only happens with a very small symbol table. Real symbol tables do not trigger it, and Xen itself is not affected. A host reproducer supplies 64 identical 127-byte names of type T at successive addresses. The original generator reports: SUMMARY: AddressSanitizer: stack-buffer-overflow xen/tools/symbols.c:307 in expand_symbol The overflowing object is reported as: [1184, 1312) 'buf' (line 341) <== Memory access at offset 1312 overflows this variable The fixed generator processes the same input successfully under ASan/UBSan with no diagnostics. Assisted-by: Codex:GPT-6.1 Assisted-by: Copilot:claude-sonnet-5.5 # host and x86 build tests Signed-off-by: Mykola Kvach --- xen/tools/symbols.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c index e15273a8ad..f6319d6259 100644 --- a/xen/tools/symbols.c +++ b/xen/tools/symbols.c @@ -338,7 +338,8 @@ static void write_src(void) unsigned int i, k, off, ends; unsigned int best_idx[256]; unsigned int *markers; - char buf[KSYM_NAME_LEN+1]; + /* Type byte, longest name and terminating NUL. */ + char buf[KSYM_NAME_LEN + 2]; if (map_only) { for (i = 0; i < table_cnt; i++) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442671.1660218 (Exim 4.92) (envelope-from ) id 1xEWBx-0008Na-UT; Wed, 07 Oct 2026 18:16:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442671.1660218; Wed, 07 Oct 2026 18: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 1xEWBx-0008NT-Rj; Wed, 07 Oct 2026 18:16:37 +0000 Received: by outflank-mailman (input) for mailman id 1442671; Wed, 07 Oct 2026 18:16:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWBw-0008Mw-AS for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWBv-00GBp9-Ni for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:35 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c6e-e002-0a2a0a5209dd-0a2a4508a346-16 for ; Wed, 07 Oct 2026 20:16:35 +0200 Received: from [209.85.160.180] (helo=mail-qt1-f180.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c82-f659-0a2a45080019-d155a0b4c5b8-3 for ; Wed, 07 Oct 2026 20:16:35 +0200 Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-5350cc60b51so35409151cf.1 for ; Wed, 07 Oct 2026 11:16:35 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.250]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-53572163ceesm25476671cf.20.2026.10.07.11.16.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11:16: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=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=1791396994; x=1792001794; 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=a3FpKl0vN7petfzZgqIhlc2NP9KQ4OIDsR/ta4Cqq6o=; b=L6+K1GKqZS8REPfMl1v1AMZKm1L4b1reWXOetaixnleuy2ZrGbopmQolMbW3xmMkEy qfqej1S9GPvQaOZ9vWM1dPh7sEKHUVyl2i0JozykNWBaXXbZKovkaT28vwSG7pcBmX8w s04bFiqDa454EuU+WgAZmnLAVmScp5352vWI3vE7CyDKTCLoLcKxNKNpMv8j/nG/Xsah x2MfhqRuLS2DXytfQHz2Ub+7rrEFwMVvLtfl2FpkUUYazNoYUqdLxrQ5kSgipcRORsCJ FskO68cqF7awLnvIfo5A0Xq4TbDH3Z+svngpPpbMu0GVtupOtPgo+LSD2ao7PEPalqPv oPzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791396994; x=1792001794; 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=a3FpKl0vN7petfzZgqIhlc2NP9KQ4OIDsR/ta4Cqq6o=; b=UsSrjGa0wMae3GNujnhtrjv1evqJyrn3C7y6gZYjme1iAmOQ/uWrRHQUnTLE0mhuis Fp2sovRPT9IggO2I341wKOVHO7PZu9TETHiMxCMefRY2mHqN4Zui3Udsb7MLpxglZ86g XcGMWr3zOhbKKUtHUXReVzM3y7edn8d963t4C2NeG4shsbDrexsy9vscyOrwoLwgDfqa AhpBOYJzwnYBC2jCi+cVEnNl2ha+DY+S8iIIRIEegOuljS9eK5xw3TDnLlTqS8Gqrs2A H1SNSwXp7GY92j6/O9LIr1qxWtE0Dd7W67bK62R5gfEBK0LkUQj9Lm3w8yv/cuKjfstn OHPA== X-Forwarded-Encrypted: i=1; AKwUvByaVyJcPp2SPs6D6Jij48nMEk+7CLM88wjEab1xuRKirtfjUAu/4od14vhwUF7cOkjbhP9Vm76NZ7M=@lists.xenproject.org X-Gm-Message-State: AFuF++mhij3/toWIv6AM8QBm0Skmk2cqF3WukQ+R8GPUdrlq+kdAE7Oj Se+XoUnSBuD3T1VNxMSFHGQMob5XPjGyM4mDtHm0aPBKLfOHmTMfOXTptbrjCyJ8ccjO1Tg3Kw2 SJI9Q16XTyA== X-Gm-Gg: AYBFou2ZVPu95on2fjVmq0YwZf9wShORn3taFXVp1QoO3OR4UZ0Gwv0qVa92CG0q3eC ez8BIL8pCeVwkdoA9GJF2POkeRWF/7p32rovQNQkXWRlFEMIk+kBcv7ywd7Tsoan2AWoyOChtSy dTBsm6m51AIWQOZiACIkaoyvwQTb/rRIs1OjYeKHYns5WtfIilh5pjxKFKSoKwuhXPsmzmkpj74 Vmkn9RcisnWe+WX3KM9ZT7GSi1ddLe2lJxUY10PfloqIzlVcs3j63/S0od87uRWaDK+/ub+8RCF UQTiIcM4Qx5ZRh2H+q+TtgVexyFXmJJ6W4WjKlAaCyiX6UlimXE+qfYNbQNvvY/2KvY/BFFodCW M2xC+uOouNejFsMLNfw7XMWF1Z5GIB8omIOVm4ANnTjq9fqN1ZGpMS8bc9jJdpX0YC66/xuaeIy OQ5pNWb/jx7Dcqi5ziQB2byXTNxhGA+omqY9WbVHmhj1WZKklDM6YHsUXlC1DsbqW+b8iICDStl YiyqmenjB6Naz+AAt1mOTK2Cw== X-Received: by 2002:a05:622a:e113:20b0:535:8607:d2e2 with SMTP id d75a77b69052e-5358607f4bamr14319421cf.56.1791396994064; Wed, 07 Oct 2026 11:16:34 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:14 +0000 Subject: [PATCH net-next 1/9] net: ftmac100: check for failure when pulling in the RX header MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-1-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1745; i=josef@toxicpanda.com; h=from:subject:message-id; bh=YaVSidg1Bo1cVWoGQJzV4z/nBT+SLxbK+9NmCYkL+oY=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLi6NM2cH1GaCjQ09bIeFY42DV/aexWSzx1/i1cHNG8H1PuIyQKikelvwnWe7Tmx+A2sBSVuNWU /fPwJUm49cAs= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1791396995-D755C87B-191EB717/0/0 X-purgate-type: clean X-purgate-size: 1747 ftmac100_rx_packet() uses __pskb_pull_tail() to pull either the Ethernet header or, for small frames, the whole frame into the skb head, and ignores the return value. If that pull ever failed, eth_type_trans() would find less than ETH_HLEN in the head and BUG() in __skb_pull(). It doesn't fail today because the skb is freshly allocated, isn't shared and has room in the head, but that's only true because of how this driver allocates. Use pskb_may_pull() for the header and __skb_linearize() for small frames, which is what the two pulls are doing, and drop the frame if either fails. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/faraday/ftmac100.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c index 40ba001d4b3f..a1eb04ead2d8 100644 --- a/drivers/net/ethernet/faraday/ftmac100.c +++ b/drivers/net/ethernet/faraday/ftmac100.c @@ -469,15 +469,21 @@ static bool ftmac100_rx_packet(struct ftmac100 *priv, int *processed) if (length > 128) { skb->truesize += PAGE_SIZE; /* We pull the minimum amount into linear part */ - __pskb_pull_tail(skb, ETH_HLEN); + ret = pskb_may_pull(skb, ETH_HLEN); } else { /* Small frames are copied into linear part to free one page */ - __pskb_pull_tail(skb, length); + ret = !__skb_linearize(skb); } ftmac100_alloc_rx_page(priv, rxdes, GFP_ATOMIC); ftmac100_rx_pointer_advance(priv); + if (unlikely(!ret)) { + netdev->stats.rx_dropped++; + kfree_skb(skb); + return true; + } + skb->protocol = eth_type_trans(skb, netdev); netdev->stats.rx_packets++; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442670.1660209 (Exim 4.92) (envelope-from ) id 1xEWBu-0008Ak-OE; Wed, 07 Oct 2026 18:16:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442670.1660209; Wed, 07 Oct 2026 18:16: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 1xEWBu-0008Ab-L4; Wed, 07 Oct 2026 18:16:34 +0000 Received: by outflank-mailman (input) for mailman id 1442670; Wed, 07 Oct 2026 18:16:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWBt-0008AV-QJ for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWBt-0013Km-3p for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:33 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c78-2eae-0a2a0a5409dd-0a2a4505dcac-16 for ; Wed, 07 Oct 2026 20:16:32 +0200 Received: from [209.85.160.172] (helo=mail-qt1-f172.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c7f-4cb1-0a2a45050019-d155a0acc568-3 for ; Wed, 07 Oct 2026 20:16:32 +0200 Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-5350cc60b51so35408561cf.1 for ; Wed, 07 Oct 2026 11:16:32 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.242]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5357209ff04sm25811551cf.7.2026.10.07.11.16.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11:16: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=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=1791396991; x=1792001791; 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=+d7uJDJhZJvHZwnUFL8rPNX4HlSixikJ7Pt8tEZOBOA=; b=MeASrOUDeYRs+g8VxXwVJtQUIB+Y+/wmmKmA0NYddPcSJTYcS0KYj/TZIKs+P9lRsP TezsLVI8gqoApHMJGRfoz8ICw7baY9mWpWpqUQH0VYgV9wN/fe5Yo7cVjrC0OZBtzvCl VXr5orDU2wLldyDe2tCJE6KSKyjCakixEqZc2sl2LAgiEsePxAkmKTMCJHdh02vmmeUp 7vVliCyJz0r5H4j1Moj96xXHFsWENJ62q/wVnU3mkkDGh6+UKAKq7T1EFRf/ZmPSJkTX 7Ei71AUWH6rsuyUACWzrHeBkrAP1aWpq6ksjD90/MatSBI7u82El1Tza3zy5pMOLoTUT LBuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791396991; x=1792001791; 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=+d7uJDJhZJvHZwnUFL8rPNX4HlSixikJ7Pt8tEZOBOA=; b=co0AhnZu/oynUhjuOYicNUkN+BpDkH5rfsEk5Rivk7EIIILzpCa1/jgdLUv6abvj5V XYiLj/yu2fUfDGOFK5GA1rIgJ06G5Lsfm2D6MlSFBFUZlAFJJ/OzZnfFlgiuzaCS/J3f LxRNx0L7vyYZkJzC2MExEytxjcWa+QyulXjg7WyIXYtsr+yLglDjv0VF8mfNJDZZoIfI MYN2ghDv5o7gIqVFFmgix3qyVxVltpzYaJYArN/t7FELgTByGRQbdjcBnzYkUeBHJVW1 bnR3mblYwVBhbqZYrTIJJeWCq/bjaDdi6NoATNIvmaPdOQlA5WYGG4ZNZw+uX1J+Yri9 BvNQ== X-Forwarded-Encrypted: i=1; AKwUvBxrE4o5y72aP1sYmrAlXEDM+mJR4UcP5vcJD7sRe3WswU/s8YybLsjqTK5Sn1y4E0wDJQ5kUAL4gsY=@lists.xenproject.org X-Gm-Message-State: AFuF++lDn7gVBZUB8Um7DMlisrjXgKZ0yu5ACUWQMt58cXlCdG9T4T5W wk+C5bWHJ81VoLN9QRtUAY2sc5W3WljtLZpCyYaVq/XtcGbWJ+3612vTnX/UPqRXqhU6whGCNVR pU01urwcGlg== X-Gm-Gg: AYBFou1YqTqqVwwzh3Yi5VokIljwhr7rRDZDlZIBHEm33NhzPUk5RQRMHhfZTt6rRQK NCQJCWeCihGUaUjM6rjLIUPJOnhXZ8QM7WizViNenfe3bC9AmSVhIY3iRtsgQCuGC2Ye68TCSyV g3Lt/ADP/zMkxfNiwJphX3urC7qniAa5kx9xJkJrskIOPnfNWnrJucTWqulUJO8akW3wmXbJ2ea ofE2zfsnfsUJH2VRKijDmmPLzXFLjNMit5mu8+bxUYF3xZfcFfeBzohVN7BJvBiwK4qSyghz9f7 9N+OB/tecECpyQ5U0Z2i9TokP1xpwmdV9wYy+ezRR3FdvrP7Pvzn2HgEviJZaEJDIoUe+DWjLpc K+Yf/jND7S8FskoyZHEgQ87TN+bNNDLIojTb79OSfQNcqotzxYIPbm/X7gVTcA2veRc4omTFH8M DVIKMhtoF3icjN65juZTtQ0ZqzDKlCSgK6IXqXOZDpBNLS7GVI9hxhgdbjEJiJvbDcjFp51fNns 147IEmc34DKykI= X-Received: by 2002:a05:622a:98b:b0:535:15a9:2516 with SMTP id d75a77b69052e-5357560fcb8mr47504081cf.53.1791396991271; Wed, 07 Oct 2026 11:16:31 -0700 (PDT) From: Josef Bacik Subject: [PATCH net-next 0/9] net: stop calling __pskb_pull_tail() from drivers Date: Wed, 07 Oct 2026 18:16:13 +0000 Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAG+MxmoC/22NywqDMBBFf0Vm3cEHQWh/pXSRiZM6bUhDJoog/ nvVbru8r3NXUM7CCrdqhcyzqHziLtpLBW608ckow66ha7q+bZoeyWDSN2GaQsBiJeCQZeas6L3 x1F17w62FfZ8ye1lO9h0iF4y8FHj8Ep3oxa4c6KNLVhkp2+jGwwqpJlOf5v8z2LYvyPZACbsAA AA= X-Change-ID: 20261006-b4-pskb-pull-tail-drivers-ff4fb2964e1a To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=4206; i=josef@toxicpanda.com; h=from:subject:message-id; bh=vn8FTVHGMrT37pYQ+kom/lZJg3xw5yD+Z8WzSqCiJUE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNQafSGevfmZO2PVgBdAMDrT/Q8BcDOZO7ALSZDi6LHzWalQ1RcI/ykJ522k74cd/ODbB0drvUX 1QhkjFs1aWQY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c201ff/1791396992-F62AB2A1-1C90D3C0/0/0 X-purgate-type: clean X-purgate-size: 4208 __pskb_pull_tail() is the slow path behind pskb_may_pull() and __skb_linearize(), and drivers shouldn't be calling it directly. It takes the number of bytes to pull relative to the current head and does no bounds checking on it. Ask for more than the skb holds and it BUG()s in skb_copy_bits(). Ask for a negative amount, which is what a caller computing "len - skb_headlen(skb)" gets once the head is already long enough, and skb_copy_bits() is handed a length of nearly 4GB to copy into the head. Under KASAN that shows up as an out-of-bounds read of size 4294967288, after which __pskb_pull_tail() returns success with the skb's head and paged lengths no longer matching its frags. It also returns NULL on failure with nothing making the caller look at it. Eight network drivers call it directly and four of them don't check. All four are RX paths where a failed pull is followed by eth_type_trans() or skb_pull(), which BUG() in __skb_pull() once the head is shorter than what they pull. As far as I can tell none of the four can fail today, since the skb is fresh, isn't shared and has room in the head, but that only holds because of how each driver happens to allocate. pskb_may_pull() and __skb_linearize() take the length the head should end up with, check it against skb->len and fail cleanly, which is what every one of these callers wants. Convert all eight drivers to them, check the result, and drop the packet on failure. The last patch makes skb_condense() check its pull as well. It can't fail there today, but it would undercount truesize if it ever did. The callers left in aoe and xen-netfront are fixed separately, through the block and net trees: https://lore.kernel.org/r/20261007-b4-aoe-short-packets-v1-1-db5155f7bb9c@toxicpanda.com https://lore.kernel.org/r/20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com Once those are in I'd like to stop exporting __pskb_pull_tail() so new drivers can't pick it up. Testing: every touched file builds with W=1 on x86_64 allmodconfig (ftmac100 on i386, it's 32-bit only). e1000e under QEMU, which hits the converted TSO workaround on every TSO packet, passes TCP traffic between two emulated 82574Ls, and with failslab failing 5% of atomic allocations the failed pulls drop the packet and nothing falls over. The same setup with jumbo frames and copybreak off makes skb_condense() pull frag data into the head tens of thousands of times a run. xen-netfront ran as a Xen HVM guest under QEMU's KVM Xen emulation, with the backend changed to spread frames over 18 and 19 RX slots, which takes the converted pull in xennet_fill_frags() and its overflow path. The other drivers are compile tested only. Thanks, Josef --- Josef Bacik (9): net: ftmac100: check for failure when pulling in the RX header net/mlx5e: check for failure when pulling the Ethernet header after XDP net: niu: check for failure when pulling in the RX header xen/netfront: check for failure when pulling in xennet_fill_frags() e1000: use pskb_may_pull() in the 82544 TSO workaround e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround netxen: use pskb_may_pull() to pull excess TX frags into the head qlcnic: use pskb_may_pull() to pull excess TX frags into the head net: skbuff: don't reset truesize in skb_condense() if the pull fails drivers/net/ethernet/faraday/ftmac100.c | 10 ++++++++-- drivers/net/ethernet/intel/e1000/e1000_main.c | 5 ++--- drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++-- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 9 ++++++--- .../net/ethernet/qlogic/netxen/netxen_nic_main.c | 2 +- drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 2 +- drivers/net/ethernet/sun/niu.c | 6 +++++- drivers/net/xen-netfront.c | 22 ++++++++++------------ net/core/skbuff.c | 3 ++- 9 files changed, 37 insertions(+), 26 deletions(-) --- base-commit: a5e7d8e446af9803e37a3b6a4d416fb41178348f change-id: 20261006-b4-pskb-pull-tail-drivers-ff4fb2964e1a From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442672.1660227 (Exim 4.92) (envelope-from ) id 1xEWC1-0000Bl-8E; Wed, 07 Oct 2026 18:16:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442672.1660227; Wed, 07 Oct 2026 18:16: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 1xEWC1-0000Bc-4L; Wed, 07 Oct 2026 18:16:41 +0000 Received: by outflank-mailman (input) for mailman id 1442672; Wed, 07 Oct 2026 18:16:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWBz-00009H-6f for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWBy-002L24-Jh for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:38 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c67-bab6-0a2a0a5309dd-0a2a450be6f2-36 for ; Wed, 07 Oct 2026 20:16:38 +0200 Received: from [209.85.219.45] (helo=mail-qv1-f45.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c85-b7e8-0a2a450b0019-d155db2ddd67-3 for ; Wed, 07 Oct 2026 20:16:38 +0200 Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-91951405546so48932176d6.1 for ; Wed, 07 Oct 2026 11:16:38 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.252]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91996bac803sm26531506d6.3.2026.10.07.11.16.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11:16: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=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=1791396997; x=1792001797; 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=J9GuqCKMi/hN2ncI5Ot6sRINUqKwZdItx3f86TmeMcg=; b=eG09EqCY7izKl3xafxRc74JBSatbhYmVUr4Pl9oxF5HHPgEPG76Z9luqNPTIyyPSQX gSjUQ/+nU0GYkICd0wtdg3k/f5FQEqfXGQVeurRlWr0DvjSSN8ZiCofWBVyXhjV5xwsB YUYrXElc4T/RxShhhFCQzu7+FsVnFSAIdW0YIAUjedHqYssHL4K3tH+BWN25WoOYIQFm 9Q+ZzVdrEdmHSizVPOyXEhw99hiesHJK2Dfu6V8HWymv32ipznJuzzedfCDSi5JTq+vq XiynsrCtNBpWdvkOIDdeJO8M7twbQCag72903IXCuTo2czjPFsuMyfgH5xiBt3wha+48 jqjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791396997; x=1792001797; 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=J9GuqCKMi/hN2ncI5Ot6sRINUqKwZdItx3f86TmeMcg=; b=FAt4IqTjfDP+dN9/GxCvxyb9mED+k+CPrgPux8E8N0ArjPaztEaz6wE9j+ENXlqBpe W52iljSdAtZe0g2rJFTZGiY/Z3bmgbURSLKtquPpfywhbOS7WtWgB7b5V43bJPuaNpWz dZxPhfwvFFBTMMNriv08gVhXhNoNukwyvj5MfjPc5K+/DRhxTMw8jwM/iGVoAHVYJ6ky rIFa2uWYeajcIMHtIhp1VtvsmEU5Fuyf4+UFAb9tPBbO2duwbnbHT/EmqTSni9QdcLKu k+zGCzuTlJFgvwPNJHpGLE4VBuiEXo66PaBVT87fqyhYhqMD2zZDkZ2PDF7aOe4D7Z0V /LAg== X-Forwarded-Encrypted: i=1; AKwUvBxe64LZ9GegXi+9y+DdVhg259Gp6Hhk1Hx/hZin+DaCB2FVo/nGBf/N/4TfQW2Euxem25DB9iKk3SI=@lists.xenproject.org X-Gm-Message-State: AFq9FYJxmtPlKvB1lmxoKuyQNGd7uZG92xZbWHbooFBA3gv9iBsdZx0n m3k1QrkzzMOlLJMvzAImxJ2jHG46n362Xy0MtOC9+wtXkHTd2Xam8uG2zAH/oSpvrPtfJ6BiqeR valR0yItapw== X-Gm-Gg: AYBFou3Z/zftzDm36NPVKSXFpldHVkm7wTu4QaFBmbQT3cSdKI7OkZY5UGaS6ByaZJU DTLkmwBkpoaIHEZYd9pNT7NiqSOsBLuYNfi7Erj0f4ebJxV1qhAbmTfkGwY+H5ZtDs0bQy7qkO/ 1LlqcZfEqqTUxuzlg/F66tTKZxt9n2n6xhOpUGtU7XqbY0CA7ygRsGCouJcM90/tlxKfmpsrFJ4 9pqO+ox1PeDEJ5P9f2CrgbDdv4XujKyPXrOYEl0owSFMjN4C5u9WKzYQ2AwBsSLs3dTEvyoJ7w5 9H25gnDLdUrNqQJ4E/Meg0vSx0qA0DbYlaB1mBCLS4nGfuv+hAVWScbnRy5SJW2ddUm7HHahJw9 dEsBGoyaJfqebbJaeP+KRkVvLQ9xe7LDa1QVFYJxVxGo06ScvkS5bjVrn4o39OLrKsfpmSt8gAk tOU3cRgEVvily7aD9yP3CG0aHTnHI3HyzO55CpOS2UxhlK0oKXtZrsJSHwIvOJ9Uc0KT1INaUal SGer2jo50a1CdE= X-Received: by 2002:a05:6214:29ea:b0:917:8400:5eec with SMTP id 6a1803df08f44-919976fd758mr60391986d6.5.1791396996945; Wed, 07 Oct 2026 11:16:36 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:15 +0000 Subject: [PATCH net-next 2/9] net/mlx5e: check for failure when pulling the Ethernet header after XDP MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-2-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1491; i=josef@toxicpanda.com; h=from:subject:message-id; bh=zznhnNGgkEt9ZSSy2T9PlgogR6INn8I/GpUQzjq8ahE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QM+jiGljpi2X00qowHNyzmeos/hw24wETOq7O8HQRrlF1LPa5A0l/9HtyUoj5T4Hstal4F6tvLe zEFqab3/2JAY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1791396998-1A4DB9EA-6A0B5F53/0/0 X-purgate-type: clean X-purgate-size: 1493 When an XDP program leaves less than ETH_HLEN in the linear part of a multi-buffer packet, mlx5e_skb_from_cqe_mpwrq_nonlinear() pulls the rest of the Ethernet header in from the frags with __pskb_pull_tail() and ignores the return value. If that pull fails, eth_type_trans() later finds less than ETH_HLEN in the head and BUG()s in __skb_pull(). Use pskb_may_pull() instead and drop the packet if it fails. Pulling min(ETH_HLEN, skb->len) keeps today's behaviour for a frame shorter than an Ethernet header. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c index e3f915beebe1..b1e1e30a77e2 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c @@ -2060,9 +2060,12 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w pagep->frags++; while (++pagep < frag_page); - if (len < ETH_HLEN) - __pskb_pull_tail(skb, min(ETH_HLEN - len, - skb->data_len)); + if (len < ETH_HLEN && + !pskb_may_pull(skb, min(ETH_HLEN, skb->len))) { + rq->stats->buff_alloc_err++; + dev_kfree_skb_any(skb); + return NULL; + } } } else { if (xdp_buff_has_frags(&mxbuf->xdp)) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442673.1660236 (Exim 4.92) (envelope-from ) id 1xEWC2-0000Q1-Ej; Wed, 07 Oct 2026 18:16:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442673.1660236; Wed, 07 Oct 2026 18:16: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 1xEWC2-0000Ps-Ai; Wed, 07 Oct 2026 18:16:42 +0000 Received: by outflank-mailman (input) for mailman id 1442673; Wed, 07 Oct 2026 18:16:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWC1-0000BC-11 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWC0-0013Km-EF for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:40 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c6a-2eae-0a2a0a5409dd-0a2a4502e452-40 for ; Wed, 07 Oct 2026 20:16:40 +0200 Received: from [209.85.160.173] (helo=mail-qt1-f173.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c87-6ca4-0a2a45020019-d155a0ada878-3 for ; Wed, 07 Oct 2026 20:16:40 +0200 Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-53505bc6524so37826221cf.0 for ; Wed, 07 Oct 2026 11:16:40 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.252]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-535720ea17csm25632781cf.12.2026.10.07.11.16.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11: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=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=1791396999; x=1792001799; 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=blrnvRK83a0BrC00ZsKjSLnGbEsSK17m6K1yrBXm/SE=; b=UO2ptSmgA1wjJ6CTlVpols8FA1KPXch5pZHHYE7v6pxJe9PAzbxxYvsZuM5ngP5/Rq Tepo5Wf01psoLxCdSRpGaYw0j8ZfOf3bXZ9vZKpAbH8OCDmI2i//EQir63qHr0XbNZIO 3XUUzH4zs5IwAlUskAlx6d/u76mMc05dTy5U/eOYvggZiARoWJlcptMACgVvkZseOVmA Wr5fJDQtdvt0SUDfqEED2euN1AykNNH19HoWwMh8YDCGCSVW4uKA6OgUim4OjSwQ2C4T /lhVbzTV81aT63IX4cNKa/wVCDOKHsh6jpntpHOtDKJA4hquFRTOW3i9ivBXu4l+Zo/1 bWgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791396999; x=1792001799; 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=blrnvRK83a0BrC00ZsKjSLnGbEsSK17m6K1yrBXm/SE=; b=Om+aTvqeUpTCqHyeTpc2F+NJ2hOAR0YHWeTzTrCDlmjUuo8Vkhlb93+BE4ToqQWNgh wwPqDhi5WNy8Pj9jV7O2cmT+tDA3Sw3Nq45vIHV/YSjYNCAKeN4Z6syg02NxkOR6aLyB LcJGN9j0B2zBd7uYzJ163h3eBO/jm7tPO9DCY+79GrB+VapJ9ghO4Drxd+faRT0QZiBP 0iDE3sZJs4JNH3b3Au6JbNyn5O8WXxPCFju4Y2anrMH+q31h/NE1BPkFJbgqZcbO54dW Xc+JQxUfLh7PMHAn/DfiPa53ZgkxDoZji76oaNYWGFIrn1qEdT61JXZ+cDfSsaBZkjG2 s5fA== X-Forwarded-Encrypted: i=1; AKwUvBxNPBnBKbQfUfjUsefJXkdYknkrnYrJuFGyjGQV474q+V8GudeEw2EshYfdyPO26KbUU08XPpTtz38=@lists.xenproject.org X-Gm-Message-State: AFuF++mdyYcheaPwoYxVKUjqJy0gF++EpulRbw0BE927fbOTzz+WTX9d 9py8D/CjcdUcZbOHpHcaem9dUDEumcf/VLickCjdjOmlxBeEV1jSv1DOHr6F7c9nViCoIfReHkO BGZFjsV8vCA== X-Gm-Gg: AYBFou0DZ4y80s9dO6148FrTDFtlm0B+NYYJnZSzgNv1/ubvY3V6opRcS+fp2ZByH7X p37UOvJp9cP1XMwvq2dqV+01ta92VgVzsN5kwSTVBuZaaBqsTBd8dAlNKdKTH5pQoqbNSnH3trC aPn/jovKi8JSZDxGa544rYP3czMkA6FBSxrTegC3rVmGcsWWxC9RC8t0dusswvV26rPYRSVe5NB slRtd5npitG0G/dkIvsd1DZLK4K8Cj41ipzBSPnLqaTZSher32N6gxfkMoKw3x7u1WjjKsH/2iJ ZbrmbEXMdOGAvT1lKTueGr6RnJ1yLe7mYvoyT45cgEMT4Ze95J7P/ULIVoYcrOVRpf0fRKl08g1 Jmz7v4yzM07TYwlV2hc8xNTOdayLOvSIYIq19O7iqNV7vG2LdSIOm+JKh2/8fOsNplLSYP9HzAm muT64FJFhBYNJJzGbaru9DH1cxcpoeQhEP6Srsh3hqeCocbj5wR4/BL7224bxexnjeKcTWXL5Jv KFaH4dvhUYkXh6W3gBnRke7mw== X-Received: by 2002:ac8:59d2:0:b0:535:1740:d334 with SMTP id d75a77b69052e-53575201aa2mr52033281cf.3.1791396998937; Wed, 07 Oct 2026 11:16:38 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:16 +0000 Subject: [PATCH net-next 3/9] net: niu: check for failure when pulling in the RX header MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-3-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1236; i=josef@toxicpanda.com; h=from:subject:message-id; bh=3f5WzTjnDsDOAnT0hR8gZXIWFT9KoT8c/AVMjDx6NOM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPE8F38TpAIjOskJy1CfHBTawvG2+Cdej+o6C6KckWCrmqZc3RT77tIgX51AS0sYEQy/f1nhpBP sPFJm2+lltwI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1791397000-F2AB52AC-D502BB7D/0/0 X-purgate-type: clean X-purgate-size: 1238 niu_process_rx_pkt() uses __pskb_pull_tail() to pull the hardware RX header and the Ethernet header into the skb head, and ignores the return value. If that pull failed, the skb_pull() of the RX header right after it would BUG() in __skb_pull(). It doesn't fail today because the skb is freshly allocated, isn't shared and has room in the head. Use pskb_may_pull() anyway and drop the packet if it fails, rather than depending on that. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/sun/niu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c index c74a97fe5464..d1c0e868004d 100644 --- a/drivers/net/ethernet/sun/niu.c +++ b/drivers/net/ethernet/sun/niu.c @@ -3488,7 +3488,11 @@ static int niu_process_rx_pkt(struct napi_struct *napi, struct niu *np, len += sizeof(*rh); len = min_t(int, len, sizeof(*rh) + VLAN_ETH_HLEN); - __pskb_pull_tail(skb, len); + if (unlikely(!pskb_may_pull(skb, len))) { + rp->rx_dropped++; + kfree_skb(skb); + return num_rcr; + } rh = (struct rx_pkt_hdr1 *) skb->data; if (np->dev->features & NETIF_F_RXHASH) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442674.1660245 (Exim 4.92) (envelope-from ) id 1xEWC3-0000ea-Lx; Wed, 07 Oct 2026 18:16:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442674.1660245; Wed, 07 Oct 2026 18:16: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 1xEWC3-0000eR-Hy; Wed, 07 Oct 2026 18:16:43 +0000 Received: by outflank-mailman (input) for mailman id 1442674; Wed, 07 Oct 2026 18:16:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWC2-0000Uw-Tk for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWC2-00A5su-Ao for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:42 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c88-8faa-0a2a0a5109dd-0a2a4506d70c-4 for ; Wed, 07 Oct 2026 20:16:42 +0200 Received: from [209.85.222.169] (helo=mail-qk1-f169.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c89-195a-0a2a45060019-d155dea9d146-3 for ; Wed, 07 Oct 2026 20:16:42 +0200 Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-93e4c00d71aso163416385a.3 for ; Wed, 07 Oct 2026 11:16:41 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.250]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93e9915a259sm272174685a.22.2026.10.07.11.16.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11:16: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=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=1791397001; x=1792001801; 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=sSCgQuUXGYAa0Wwwh5eq4aENwa4g4z1qSYLp4/+HlX0=; b=kgz+XjzJSHj62mJROPlLOd+zkISk/fKGacJO+vW/RSqeqq5G/QUhOTHrIqLvi/xT53 THNJ91vpkvX3eiP741heH01ASqFV1p1NxyumdtXRWRD5UEE8dOiaLbWbb00H6tbFRNZq XAgKVQEeFX7oAeZY/UqaQazNuPsM8pRgx3zvgHbXG7rGbXXU0CNlRCM4mPnppw5Bot+F YeI79j10aVhJz0i8xj/QhCYrO/FVtBJkHDJoxkAuBxeLT0UO4VAX4d9oDB+xzpkPto17 0T7zHmB8KAa6P6WB03q3zp1dq8HQxVHJBv4zy1wykBAhryKTJFWoaXwP0x6sYOHCeZv7 dqgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791397001; x=1792001801; 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=sSCgQuUXGYAa0Wwwh5eq4aENwa4g4z1qSYLp4/+HlX0=; b=WFnjQEQp/ox2zRKhp/gzSvaMPe+z4a/mrwoUA7QxPQuBeb1YyHNFLysWi4GJWRoTxp BTBKFpP8U8iAndifdmlTfsmP9f34Qm7/jG0J5CBw+DrFXBvB21zEfqDwlzIxoqaOXYem Mb7WtInqyzDrs+qARJfTbl5o2AATNbOyQxsvIjrHuVd8+t/ASkNjBAFi0YNrAoEbEB8k 73LUZ/q7TJpKgCfD5zA6NVYumBeRCME+868aFU0wXXpfGPyR23U8KxIofCNznwaAdYk+ oSzVjlscHoOZhmSRaznmSI0l5cwcx/gZ4Ni4QprlE0SkXpQbJGR8aCA4MTJCC0Vjw+0n Sljw== X-Forwarded-Encrypted: i=1; AKwUvBwNrnTczdXGoPcDQ+QytEn1NlTX8O538qZbBE9Vx0ZkSV2J6Qn2ntEzwAeQTfNghy0vmNGcesEa9qk=@lists.xenproject.org X-Gm-Message-State: AFuF++li6p/UFqONAf5jJ/cVa0wCHumO5GxHkBO1NRI795k5LEt+zpDB xkRFoTOLYU2m3O1bfA33v1sJ+1/iRBMG7utJ9ltrKmD88TYA7aJsIXAYAVb00ROdGXbnrIiifWX 4MWrBzLcmdg== X-Gm-Gg: AYBFou3fJg/bhioe2BpsoXbkBtEh5vfb2GWcY66/I1bQtDNs857P9sImbSXnH+6kxWX lFmlnROje2EX1py2bhq08V2kV4IJL0x82zI4iLt9ql3NgqyNV+0Za7E3/KwxLHxWVenrlgKCF4t 9iDDMCPUzLI6ZA6E7J80jKl/bI/NAknqgZk27NS+fNPSXGAE5mldtsAVaYCGeyonptkBNT/uz2B BOH/IkSxIDeWTx6p44qpfiBloJKfTfSmcAiGJOfxYcgAl3k1pxmp3ssMe2Bn+V/jpsVkCaccRbg VPJKdkX5KJcvhPXlAyfN2rWJTobkOkq8/2/2nj82M61Z++r4r57BcgIbgMKVsiCXfez/xl2ojxl YjSRXyPk2jdNEb0D1Go4SbgXotymyZl6WXzKq4mrvzStioak5KEztNYqf+l3UAiai5foZ0LOjG+ QnuQn3VBUZrnpPgoyr/Gc79DulFqRXEX6UTBLPjAYugiKrO0Vo4jrzLyNFFpPuWVEvq0QFaALPg 95J6C/KIKys1fc= X-Received: by 2002:a05:620a:29c7:b0:936:dc4c:3bf4 with SMTP id af79cd13be357-93e9b7436bamr598926085a.28.1791397000824; Wed, 07 Oct 2026 11:16:40 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:17 +0000 Subject: [PATCH net-next 4/9] xen/netfront: check for failure when pulling in xennet_fill_frags() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-4-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=2095; i=josef@toxicpanda.com; h=from:subject:message-id; bh=SzoPfHs/Y0Yp5wMeUYR89lBIZmoL94dSQOZucEHgjz8=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QE2mPs8pQLqezwaIQAKe007VJT1pjZBj9lcqG8tW/4kuSaDQpOlcqMEPoJV+xlZe2oi4kfjBSKZ BVy2K6gSrcAQ= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-16d1c6/1791397002-F6C7777B-3A4C5F99/0/0 X-purgate-type: clean X-purgate-size: 2097 When the skb already has MAX_SKB_FRAGS frags, xennet_fill_frags() pulls the start of the packet into the head to try to free up a frag slot. It ignores the return value of __pskb_pull_tail(), which works out only because the nr_frags check right after it drops the packet if no slot was freed. Use pskb_may_pull() and take the error path explicitly if it fails. pskb_may_pull() does nothing if the head already holds pull_to bytes, so the BUG_ON() for pull_to < skb_headlen(skb), which protected the subtraction, can go. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/xen-netfront.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 2ed673649c48..6e01a883cc64 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1174,18 +1174,11 @@ static int xennet_fill_frags(struct netfront_queue *queue, RING_COPY_RESPONSE(&queue->rx, ++cons, &rx); - if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS) { - unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to; - - BUG_ON(pull_to < skb_headlen(skb)); - __pskb_pull_tail(skb, pull_to - skb_headlen(skb)); - } - if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) { - xennet_set_rx_rsp_cons(queue, - ++cons + skb_queue_len(list)); - kfree_skb(nskb); - return -ENOENT; - } + if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS && + unlikely(!pskb_may_pull(skb, NETFRONT_SKB_CB(skb)->pull_to))) + goto err; + if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) + goto err; skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, skb_frag_page(nfrag), @@ -1198,6 +1191,11 @@ static int xennet_fill_frags(struct netfront_queue *queue, xennet_set_rx_rsp_cons(queue, cons); return 0; + +err: + xennet_set_rx_rsp_cons(queue, ++cons + skb_queue_len(list)); + kfree_skb(nskb); + return -ENOENT; } static int checksum_setup(struct net_device *dev, struct sk_buff *skb) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442676.1660253 (Exim 4.92) (envelope-from ) id 1xEWC5-0000vj-Tu; Wed, 07 Oct 2026 18:16:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442676.1660253; Wed, 07 Oct 2026 18:16: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 1xEWC5-0000vO-QZ; Wed, 07 Oct 2026 18:16:45 +0000 Received: by outflank-mailman (input) for mailman id 1442676; Wed, 07 Oct 2026 18:16:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWC4-0000r8-Pm for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWC4-002L24-6m for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:44 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c67-bab6-0a2a0a5309dd-0a2a450be6f2-44 for ; Wed, 07 Oct 2026 20:16:44 +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 6ac68c8b-b7e8-0a2a450b0019-d155a0acb918-3 for ; Wed, 07 Oct 2026 20:16:44 +0200 Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-533930955a4so19991111cf.3 for ; Wed, 07 Oct 2026 11:16:43 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.251]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-53571f185d7sm26074811cf.2.2026.10.07.11.16.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11:16: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: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=1791397003; x=1792001803; 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=jtyJNESs2NfaCrmwRAvvPnxlfOHCunirXFuek+zM5MM=; b=fH3AE8L3Bd0TIZ/fShZcK5AOn+WjPY+A+urEgTFIOlGIbZ4sMrRrF3cOYN3XRjlf4o uhlHmO5qBIMew4ToKfq+UUPPerhyYdHvjCwoj2nCP0tmwsGSQQL2cX9Z75OSqfVDFyt/ rMoxSGd0H6D8MkvZaz7WPkcgTOx9bImsxYTvWpORxcpx3nd96zuVB/azlVtWanObRgu9 jZoN0atVGbqN5cScDjgBn6hqztdNgBXikHOmP03f/1bkDo1nxkghhpX9bQMS0xOjxHpB oNwHZCrA6AnsJR6vlUTRzwwj84WSKIOJIoGAbs86hWoeKi14Is+1P5Npc7Dz5jVDWl1T BYfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791397003; x=1792001803; 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=jtyJNESs2NfaCrmwRAvvPnxlfOHCunirXFuek+zM5MM=; b=BwBzBjrwmXxRa6ixqwUXiLATmfTlRjx4XJL72CLICR8q/CxFHpqRowMw7nwRmr1pJs vp3zr9y4mFrln8Fox5y5vwAEoUre924bEe2HM0t41pmV5CEpZogPUvHyzLDYj+0k6hwe 4h6cBX5hSHEGe2XUfTAGcqc34bLGh+jhSBSgcUyFNm6GtjDA9bKtL3MWYquXVgGztJen R2VA2TDgGgROZ1Zx/LF70tymaVf1Q8Fl5zJONcCgBKsACW8ZeTlJAgb/qSqZztL1sOKz XMSP1PV/mc2WcuEMzCsm5YQmgArlV9gRf0BLHHn8GHGdgMyagglf+z/8XPfiLERWjtOM 1AWw== X-Forwarded-Encrypted: i=1; AKwUvBwCxghR7z+t/lBZzmul3nwWZl7+mjI3gE/dS6KRgwkC1+2qmmXrrzyRdQJUiJaPp1ep/AwCLclD9+0=@lists.xenproject.org X-Gm-Message-State: AFuF++lOgPnEnBAaaF5zucf/Ln3RWDDUnfZ96mjKSPGNZgUqmYrm09Rm 2lBT7fAPRbFfJIIWTF5cYeQg2AJI+CwEENwGtwWVJ+oS3Xw0B+KTuyYmLU52JeeHfOu10sN0pu4 R4hAvcxMS+w== X-Gm-Gg: AYBFou2xwscozbM1gL0IPf1T846JYrlamKAr0+ihehobAAg/s7uSOfUIOwtQZuTZcAd hkWl94FuVs4TX9QX2q8R7N2JUvRLBUAxUhJ2YcdY1f6XDRLUy0Gjw74zvmFKi8bYQAqq7dwNlVo UEuMsQbkIND+XTH5IXhWV6LHt0pZe+tX7ZyVfhkRHwa3NfKCSwxmXt/MOQmFwg0FFa8kfs84yj0 D/sOZl31lVJAjy5KDE9jTwzWXF/+3/43WI2dHyqFyS1F2wflV3IDbYATyGd6uf/l0bu1wul8Lsf ujZL+VeiC1gZJ7DcGDj9Djxk7Jb9y7jOs7eK45lhb+TSsxdWXp0R46MfrHOXIVkg/wQ2anT9qyr XZrAxztDM8VK3wvCv5PgOtbLU/cKkRZ13FPWpdHOc8I7yLEN3jfT+wFPehVFSHTjeE4U9Y7nUeI lOHA74G22BSFqxjsL+Q/RAmog2aqKwY78/qw0mKas+AtxjpavpbM6D1dfHPyCZBPnXF9gymBW0H O9/ILwJFkVFKWPSUeWi5UyGsw== X-Received: by 2002:ac8:6f10:0:b0:530:5152:75f0 with SMTP id d75a77b69052e-53575522f94mr50565161cf.22.1791397002737; Wed, 07 Oct 2026 11:16:42 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:18 +0000 Subject: [PATCH net-next 5/9] e1000: use pskb_may_pull() in the 82544 TSO workaround MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-5-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1221; i=josef@toxicpanda.com; h=from:subject:message-id; bh=yldyXc+k9IUGHFBVvbXY7100U73O47dmandGyjhHpkE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNqFTCEFL30xWoiEbNRl0xB0Ou+bDMfIq1Ujmi8Mmc+Z3YK0ZHA9JyEcAtxrEeF+xJvGJrfmT0r 2sKFeMZQHNwo= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1791397004-1BAD09EA-E0A11FA6/0/0 X-purgate-type: clean X-purgate-size: 1223 e1000_xmit_frame() uses __pskb_pull_tail() to pull up to 4 bytes of payload into the head for the 82544 TSO workaround. It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/intel/e1000/e1000_main.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c index d7f5c6f16142..3a55b211f5a6 100644 --- a/drivers/net/ethernet/intel/e1000/e1000_main.c +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c @@ -3155,9 +3155,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb, & 4) break; pull_size = min((unsigned int)4, skb->data_len); - if (!__pskb_pull_tail(skb, pull_size)) { - e_err(drv, "__pskb_pull_tail " - "failed.\n"); + if (!pskb_may_pull(skb, len + pull_size)) { + e_err(drv, "pskb_may_pull failed.\n"); dev_kfree_skb_any(skb); return NETDEV_TX_OK; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442677.1660263 (Exim 4.92) (envelope-from ) id 1xEWC8-0001Da-Al; Wed, 07 Oct 2026 18:16:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442677.1660263; Wed, 07 Oct 2026 18:16: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 1xEWC8-0001DQ-6t; Wed, 07 Oct 2026 18:16:48 +0000 Received: by outflank-mailman (input) for mailman id 1442677; Wed, 07 Oct 2026 18:16:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWC6-00014K-OP for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWC6-00GBp9-4z for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:46 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c80-e002-0a2a0a5209dd-0a2a4503a5c0-36 for ; Wed, 07 Oct 2026 20:16:46 +0200 Received: from [209.85.219.48] (helo=mail-qv1-f48.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c8d-fae8-0a2a45030019-d155db30d595-3 for ; Wed, 07 Oct 2026 20:16:46 +0200 Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-9179bfa9e9cso33869596d6.1 for ; Wed, 07 Oct 2026 11:16:45 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.242]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-919aa0ff38esm986706d6.26.2026.10.07.11.16.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11:16: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=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=1791397005; x=1792001805; 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=pgpiLoGoqA0xV5yWN2rO1XVw1oOPWsG2lgMDpzrz1ts=; b=qzLaUiyxTlDOr0zm1/y1CkzyYF3UIYe03Y7LN/TKCquVuyzfaxEJHM7FhSYsebU+P0 lSM0/ilZDnO78/Zh97VEzvCa1e0Mu7Zsw2pqbUcK2KOlAGQR23waJ5wtHVA0fPiTdtZb MCdEBaDKGfl44984Ov2GzpX/wz+4rI+8Ll7C/KRs4Hgj+UmULFhdyExb230ZghYqhXL/ 9sXbaLg6sreC03PKxvmnkEqXpr6W++2wAui85ckDeVLfdIN9zI2r2708lVfgqzXkiF8W 9704DZXD3MI4yvgvQZTyTOmFuG4ba9aOAoEdySMg9dg9a4tc1Ua92HOEoBOmR2SRpBEF WZbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791397005; x=1792001805; 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=pgpiLoGoqA0xV5yWN2rO1XVw1oOPWsG2lgMDpzrz1ts=; b=2Y9UfPJMM1NsMkXL5sOjdDzoWsxc6HtgqQ67iYUFoQZsqFGfdNeLqd2MuSZzHSgzy7 IKbAu5PrdgbGTVrZlyfUI5+G+/61OFCS5epAbWC2UorL3ZcscNCfH4iMb/9e4hAx/2iJ sB2QwFWpD2Y4UT/yyh4ZVYjqpWOfK2umn745e430Qj0Gag+B7KW6FbrO+2C7pGFANnPB VDb94G872PAz61zVD6w2Vz+2jqU3Ny8SYIjPNx22aVFrxEF1Jk5Vqfxmc2dfT1ZmSNdI DRu2ly3+B7IOdHv3/8yYGEo54ZdFeJ9OY5HEp15DFgxORQgx/Mmu7mYPYWyutqPdqtfw swNQ== X-Forwarded-Encrypted: i=1; AKwUvByeYqcXKhcqQRZXsuUCZktHuNy9o2j3jHOZAQMiVpqV4eE/4M2HSpHg5dPo/Xc+WrYcZ73nviSz0Js=@lists.xenproject.org X-Gm-Message-State: AFuF++n5OOglzOP4McYBdMafofZM0pnD5RnCjQCBpF5bYG31HxNcmQol v1PzIs7e0HFZELohA5H6PNQ3XpnSeTIuE0IfL95q3MIyB9eGCo8h82B/KZWR2bALumJ0jEiOkLu 6YZygNwgKhw== X-Gm-Gg: AYBFou1MMScng3sYq0dvMB2HGlFc62VtYzZi0scGR/xI/OwURPxy/QMeLcfI2sWbwvX QobIYR9WMHJNay5TZZR5KcOVaKajIt/A8cg7bsKprErpqXg4QAZit+CfTJmg2EwxRampVk+C2jW OQ2wyjNWI6+ePHecxSgMll8Mrah6k4gEEA9cCACGgcvop13pxsLL6I5nqqgOe05GlwJehnr5L5o mBlkZY4ZFaDgQRjYM8hQNYzyHdvzhTOPqsmZ31yDxwdRqdDggXIbNd21z28Z0tj+mKO15gKkmpc bO1yOFiaz7CtoK/MP6s2SC8shejfiduW1qlgKq4cUaBLAPnEOp7+qLeuiLIOZYC/Z1Wr4/2y9U6 LMiFlcdI3AIfsrBt2/QUJolYTcTXPGZdoe8sHRqYm5redk83oUwH+nO5KnX2GLuoOzrvaPOaPZX Kt51+lGcQRLo0xg3b0ZH+Hcx1+zulhxMUBFmTBVnCEu39vZd8jb5nUxqqAc7tX75aJtd6RvnHGW 1WRFLEQu/7LJ+o= X-Received: by 2002:a05:6214:2408:b0:90f:5154:6a93 with SMTP id 6a1803df08f44-919977eb9a4mr57210916d6.11.1791397004534; Wed, 07 Oct 2026 11:16:44 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:19 +0000 Subject: [PATCH net-next 6/9] e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-6-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1188; i=josef@toxicpanda.com; h=from:subject:message-id; bh=2XY23bjEEEbmilzyi/OT0dLNP6D+zOB3zspYb8/aVZ4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QCZC1nd2AgIaYMzIFdyfEIqZLuxEhag0euZBWHhtKoqomivMvwvOvEoJ6R+5XulLE3AuLwN94C9 RAHLj79e6mAY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1791397006-77AC44E9-A09DA23E/0/0 X-purgate-type: clean X-purgate-size: 1190 e1000_xmit_frame() uses __pskb_pull_tail() to pull up to 4 bytes of payload into the head when the head holds only the TSO headers. It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 844f31ab37ad..e216868e15cb 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5859,8 +5859,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb, unsigned int pull_size; pull_size = min_t(unsigned int, 4, skb->data_len); - if (!__pskb_pull_tail(skb, pull_size)) { - e_err("__pskb_pull_tail failed.\n"); + if (!pskb_may_pull(skb, len + pull_size)) { + e_err("pskb_may_pull failed.\n"); dev_kfree_skb_any(skb); return NETDEV_TX_OK; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442678.1660272 (Exim 4.92) (envelope-from ) id 1xEWCA-0001Vs-Jw; Wed, 07 Oct 2026 18:16:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442678.1660272; Wed, 07 Oct 2026 18:16: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 1xEWCA-0001VZ-Fe; Wed, 07 Oct 2026 18:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1442678; Wed, 07 Oct 2026 18:16:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWC8-0001Ds-H6 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWC7-00GBp9-T5 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c68-e002-0a2a0a5209dd-0a2a4504b38e-30 for ; Wed, 07 Oct 2026 20:16:47 +0200 Received: from [209.85.160.178] (helo=mail-qt1-f178.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c8e-b57f-0a2a45040019-d155a0b2e537-3 for ; Wed, 07 Oct 2026 20:16:47 +0200 Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-5351748222cso34596061cf.1 for ; Wed, 07 Oct 2026 11:16:47 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.242]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-53572103ae6sm26011521cf.15.2026.10.07.11.16.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11:16: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=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=1791397006; x=1792001806; 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=HlPhbKKLwkJ8jfy0wR1jO0OPJAX2t4fwgDWWxi6hd3M=; b=gwJNpiayR9qjcJ8E7j/M60zn7pM1oyOWHoImbq6U2PIbEErFBmdJcLXof0itK35sD1 7ihqZpUan2j8IzSYUzzQ/zC+cmjzaT3/mkitwWYOGb0JmQIBawf0zJiLmdSZpOfM962b XP533ZrdZOk/guKz3PP7Y4MW2tFxaR2cFgk/9NAvv9ego6ibKqsXh2kfAvyQag9SG0D8 4rXWyONtj+o8UJW9Byv3uDH4kcpJdAm/EYBTQ1UTHTbxBuQXKkGyT+x6ECQ4HsvhHCJK LR+D1lDbCFgh0OAX+HPZr1sA4OzDOoz7uObvG2lrVjr9SKvbk4gEwpBlDde1VhM1i3NS YpXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791397006; x=1792001806; 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=HlPhbKKLwkJ8jfy0wR1jO0OPJAX2t4fwgDWWxi6hd3M=; b=GIh80iU9dXxb2Mp/QsRhFB+slkSCsp/HJLxpjV9Q8ah/3WjU/L6WPGRiUTv873IMUA 1Zl+piMmQNZ3AIhI9GF+NyMsJFRO5zdbrSMfTmdzDbbCtMqfH5czdagv8FlVBA7asI4j TiOYAT9l9hY+DHkITcCMv+14F1blhfj5AaJeckt/dwpTfaLTNOpJs/EKCsazFAfciiSr 4xGRle9p2M2+riVT/Kp3D0q1tKau7YXrPLpXZg8eOtISJZ8pFYA6dERFhdMHLd8/gNTv kOQxQUAxIUuXHSIyOBIZsiXskslDLQQPlnAYnw4ZBXL6I7lUUvnkr2nQSTOs7eWvRqeZ lQAA== X-Forwarded-Encrypted: i=1; AKwUvByO6HkiIpGORS+3BwmYDJ02R6+uAWnCr7JujcrkgOHGJiFUDDrgn1dHo62Vvq4Si7aYtZXUIkD/u6g=@lists.xenproject.org X-Gm-Message-State: AFuF++l7DSEwGyf52oercrJ8eNBf+VcwzmhSRSN2YkUqsqsJP1hg313s KZeGpI5Epme/UhjeybDvU8USvGVQbaoEfvB356kD11Y1eX6IKJwiaChYv3fWNoehTYd1OYeznQ1 uNt84gr0jtA== X-Gm-Gg: AYBFou3C7SZfr7KNWlHBulK0BEj4w/wlCgYyq/ElCiRawuOGtq2JA0L1MmgLy/5caKQ BnLxutT/6wmqMG1JnkRS4CJxCGFeVZolHgK8pY/HFQcVj5u1UC0hGEjWxI5yOMWi0I671Kq4P9Y YlImVNWZ4m88ql4y1A9A9MwQZQSzIXSKIkoWQXGJ1WpPtJ/h0DjwgR1IQj508gA1Q9Ryb/Vn2Qe zaEP/00aYzwcxKn79hgmSVYAcy2ayLZ1Oya//0IZsXhVZu6z3R9+YVCC5imTKhPDt6aNVPRrCF3 5JIP+aZNGVlWPKNeGGIgM1WRqmgDeiwUxDgPc089IBV3htm6TtaN+qUb9dVeJi+9p5VUC37NAOW fi/NDTq13o0sZ49ypuhAnsUE2bQ7T2qF8JW1Denq4M/3QH2ICZw8ydN09QIghRjZ4V8/G759KCs J/8lgiawFXLWJNoU7j9IJb9xEqnQr0Y1hl8F5zHn3YYEIzPftK83w+Qxv4KjQqHNICSsisKcxlY UECuzhT9D81avM= X-Received: by 2002:a05:622a:4106:b0:533:3d48:37f0 with SMTP id d75a77b69052e-53575555c86mr50817771cf.47.1791397006325; Wed, 07 Oct 2026 11:16:46 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:20 +0000 Subject: [PATCH net-next 7/9] netxen: use pskb_may_pull() to pull excess TX frags into the head MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-7-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1110; i=josef@toxicpanda.com; h=from:subject:message-id; bh=McO8YjXlypOeoX4QkYeNrhdO3XuQh8G3BcccmslsJYQ=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QEER6Cf6YiSeQas1SDvrXyD48BT2JMKt5v+EgNKlM2X9W7DYLscC2uLR/v/alcS1X9KdG7G/jh6 TE0kjRM5PRAc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1791397007-512DCB50-5877B80D/0/0 X-purgate-type: clean X-purgate-size: 1112 netxen_nic_xmit_frame() pulls the frags that don't fit in a TX descriptor into the head with __pskb_pull_tail(). It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c index 67d9bf69f8f2..202deb64ddef 100644 --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c @@ -2045,7 +2045,7 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev) delta += skb_frag_size(frag); } - if (!__pskb_pull_tail(skb, delta)) + if (!pskb_may_pull(skb, skb_headlen(skb) + delta)) goto drop_packet; frag_count = 1 + skb_shinfo(skb)->nr_frags; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442681.1660278 (Exim 4.92) (envelope-from ) id 1xEWCB-0001ZQ-1h; Wed, 07 Oct 2026 18:16:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442681.1660278; Wed, 07 Oct 2026 18:16: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 1xEWCA-0001ZA-Qm; Wed, 07 Oct 2026 18:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1442681; Wed, 07 Oct 2026 18:16:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWCA-0001UL-5W for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWC9-00A5su-Im for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:49 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c77-8faa-0a2a0a5109dd-0a2a450a939e-24 for ; Wed, 07 Oct 2026 20:16:49 +0200 Received: from [209.85.222.173] (helo=mail-qk1-f173.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c90-f2d2-0a2a450a0019-d155deadb59b-3 for ; Wed, 07 Oct 2026 20:16:49 +0200 Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-93e63522076so135693385a.1 for ; Wed, 07 Oct 2026 11:16:49 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.250]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91996cb6482sm26056716d6.14.2026.10.07.11.16.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11: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=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=1791397008; x=1792001808; 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=v9LzkPOzVBtC2oeBzL2RQojlIYdLdy9WRgZ+InvbO8E=; b=jqSlf4FXPAAnaa7WuWk+E6lsFP0qWQ+QLV7CT48ghhn0mUgUI1JzgN/oVvJdWPBALs S7cWGgOxFfo79yySLhWcmECUMGDpLQMIxLWGJi7Momr5eoqwXAykJjKIatCxoOIAiw5/ 1de6mvdJVynRVcubJbNoNQRhN2luua5h2rXXuEymYw0PZr08dCggwKtloW7IWwTQarnP w8JThd9AzIIxXXy4HCSqjbsG6HM7HmmcncjF6C5mbINxqtUnJ8vO3BRJ0TKttFEV03QX BlbazhgSArOeaz2kQAKb96YxWyJq9cWu8mCrBDpTPSb6tj7dqT1J6Qpdv9JVYz4+Wd8/ UE6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791397008; x=1792001808; 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=v9LzkPOzVBtC2oeBzL2RQojlIYdLdy9WRgZ+InvbO8E=; b=YYYmdfud6TZfWl2YxFLooK6UQncvYkxYDUcQKJK9fzvSxK3xYTdIsSW6nvu15qyMkb 41ERYWt/kcI1ns01+pnByFsHf11pyYFc3ES/hgFW/ga/XGjFbvTfxS/jMr7PtAyZ30lP NgUyemw+E2bbKJ1fjreSrp6CiGzpYG/POrRn8R/09qJxwHf5M+NMto9TydmZTD17l4TF mynDFdLC1a99D3i8WezePx0XukE1XkIzdmfuUhV/u3ysS13pYuz+0FZTvxTUqle7ONeu +yBMN2ZBFBCEG7x0arernjUWclFLkoQ+oiKUkEYj3f3xqbtuxQ/LlW/c8OciQ0El86pM C3eQ== X-Forwarded-Encrypted: i=1; AKwUvBx273cTtaXZmI+yL0w0+x4xhI75OAw+32rL4rTJG9SDmhmiBlvM5vJIjsn+fC2nZwXL6ccs8brIfgk=@lists.xenproject.org X-Gm-Message-State: AFuF++nKwVvgqwGdKOhQGhEC0kyfRLsW/2bz35qnoq0crFZbzkWwj+DT BUd4Df4SNL5i7kWOdnqo5GIqNU8rAC7vnogOYX5UaB6rn9C32eiHGqYj9mwqTFV7DSdixGJlwxn 8bxcjXDoDwA== X-Gm-Gg: AYBFou07oLZNsjYJFfjNH49Xxo3DwqWOeCChLyZ/95HwRM1uXuY3n2sgAbULkU1IG9L kj1qHqcNt/7h0Gr/v5r12TAsUizudpfJBnv921n9DnHHFiq2Xwj2Foj2QSitTD/AGhUidiJbJNo afkKWEWkpGT/jAuQXV+RsOA1fwqHPvrNtNC9qEEYr2S4XDk1WhllcN/8ZfzK1xwOV08ArMxrhHk 28QYF6cvrGE8xRB3KK0zTH+k4Axew9Xt0gZBcL0IyQcCcDo7btQCjoYeK0Z9UaqITtmL3D6l9sT FwrnVHpWYM3BIG+80hKHHcRAoD8gSe1afFgb41I+3D+//WlijlgUqtkHW6kTC5yU46X4c4lq+d3 5RNLm2LdU8Z/NmT7dbn4a3C5gZ0bCaMz0xg5Vo7qU+K2EQ8KteCFQ0yBC4B0HIQM4IK/PkLjmPH Ep30dfoWXl+PUzJt4Q9eCp7J5xxrBVljI6jyaOFOaLME//jFCG0tsqpgDPz6++UHIyEfTVUQQIM DsFgZhFRaJgwEU= X-Received: by 2002:a05:620a:1d01:b0:92e:bc28:5479 with SMTP id af79cd13be357-93e9b0d409fmr622164685a.2.1791397008056; Wed, 07 Oct 2026 11:16:48 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:21 +0000 Subject: [PATCH net-next 8/9] qlcnic: use pskb_may_pull() to pull excess TX frags into the head MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-8-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1162; i=josef@toxicpanda.com; h=from:subject:message-id; bh=SB4NDDKRAhqSJIc9FavKPbItFv2yX/PiEJ0MJpAzuVo=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QKawHW1ued0W6S4cwaeFnOXmxDTI/W4Hxcn7RUYBu6+BybT6utdZRP6YL9LzmS5Mmr1yUPxsj4f B1rA2kxPagA8= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-4011c0/1791397009-508CDCFC-FB0B9D0F/0/0 X-purgate-type: clean X-purgate-size: 1164 qlcnic_xmit_frame() pulls the frags that don't fit in a TX descriptor into the head with __pskb_pull_tail(). It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c index 761ef3bc8193..4a81d499e51c 100644 --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c @@ -682,7 +682,7 @@ netdev_tx_t qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev) for (i = 0; i < (frag_count - QLCNIC_MAX_FRAGS_PER_TX); i++) delta += skb_frag_size(&skb_shinfo(skb)->frags[i]); - if (!__pskb_pull_tail(skb, delta)) + if (!pskb_may_pull(skb, skb_headlen(skb) + delta)) goto drop_packet; frag_count = 1 + skb_shinfo(skb)->nr_frags; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 18:16:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 18:16:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442682.1660289 (Exim 4.92) (envelope-from ) id 1xEWCD-00023j-9i; Wed, 07 Oct 2026 18:16:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442682.1660289; Wed, 07 Oct 2026 18:16: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 1xEWCD-00023T-6W; Wed, 07 Oct 2026 18:16:53 +0000 Received: by outflank-mailman (input) for mailman id 1442682; Wed, 07 Oct 2026 18:16:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEWCC-0001tp-99 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 18:16:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEWCB-002L24-Ld for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:16:51 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac68c79-bab6-0a2a0a5309dd-0a2a4509c082-10 for ; Wed, 07 Oct 2026 20:16:51 +0200 Received: from [209.85.160.172] (helo=mail-qt1-f172.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac68c92-be1a-0a2a45090019-d155a0acb5dd-3 for ; Wed, 07 Oct 2026 20:16:51 +0200 Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-5352a876d5aso24839131cf.1 for ; Wed, 07 Oct 2026 11:16:51 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.242]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5357214830fsm26034571cf.19.2026.10.07.11.16.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 11: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=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=1791397010; x=1792001810; 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=DbLtENrG5I00kMX4i+UCiZIr5Qm/AkQbhE28uvMASeM=; b=ER52XcKVHz+2LK/IUppbJl73vyGbzmkolxsdnvfnTmtQjegJqXIQpplKzsuQH10fJs oQ4ngRw9OqcAPXR7qg3NbMuPM34JbxmxdaRXlr3Tn+xi+8hX/ZZvEYjzw0AvkguyB/l8 8BZHGIEMs4U0P2NrzDb7cnHL51X4wZ4gcS3eFCwIBAB/QoU2WAZLy5Ur6tholirJOBFo YX1244kykN8FB7pNqA9WaVcAK/+VoxIp8niRAEoCSI9oSmy/0bO9EbxEXbUL1sZL/ee3 NowU9Dgxeq9iffAuALFTRxAGFh2GuJxFPzDCKQUSmhfC5xGl2rQsQEEfex6AnaXhsJln tSeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791397010; x=1792001810; 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=DbLtENrG5I00kMX4i+UCiZIr5Qm/AkQbhE28uvMASeM=; b=CE4Uyp/pIYSbHcr3v+RNjrEsCvrMW7mxqMUvigKJDZBj3RMdWyy0oTZ48AIproGxWz wE7ytv1hgSBStvdWBO+/8mGLBPByH8kjYq7w+Wuev4JOn3jQxuT4JkzoLWipYVTIDsH9 JfoYH/Nv6LgEkHTO8Oxssv918Xs8XuFbz+DcwZyZVIRw/YE2NxozdC+PMyryfP44qFM/ A+Z1Bcuw3zCEFxit0LczGZ23EDK9SezqGxU1wnKYziCv6KeQ2vz5+YGI6H96H0SQSdoM EV9aj9smUKnLnxbqRMOpgMRvSBb/SCDBGYgS8b3bBJbXv1Dea3ZemuCOU6pxMCtr15SQ 5BBQ== X-Forwarded-Encrypted: i=1; AKwUvByCzrt25h7VyExqP8Ox5tI/Vrz/ssRz7J6g/XVVXsc1J8VaRFOhPWZENoSxatpPBrugSDxsGwjUVC8=@lists.xenproject.org X-Gm-Message-State: AFuF++lhjwSP5I/MapWhPu/X84rZ7ODSVMaju1AG9Kl0Ip4ZrKKvzUvY vu3EEuU21SadkG2wk0Tx2u/UAHljRpKMsvC+LFC+/qj/Yf2WNeTjx6ahjm9DBcoWzUERrIWCmc4 iWuieaJ/zjQ== X-Gm-Gg: AYBFou1+/OEvO+dtD2nEHERvEMOSc5Ntopxa7FToDcW3/Lz0Z7IJuM3+23IV8hYD4NS pl8e0/62gJ8FS9NicDysFIOn+RIrvkIkIApaRXrueHFL/mKbuWwwzqwoCw9Q5PB03KGBQUg9E1S rjH8lBRBehv2Tl1+lVSvwO/HflByMo2CnRMZni7bLm4c1WML22J7MrkUf7sdrb3nD4YOuBc6JSy RU/+kt7jW2Zj9u2wHO6du+Q2Ucqhb133joeyauQFc++3sVCbG87PPngGhf5mtTozcaDUR0TRRt6 EP6y1Ed4Gqtl77Bm69mqyOcmESXlUTPS0QCT3QNUtLVc47o9gQMif7Dnr8ojUH3EKUk6vklEzN4 8tOCwv2hxePrep5jBY36tNqHUnI6hgm3ZPtB/pxZ3Xu7v83GWYeIo89xZPIUBIN14O3TMt9hBsM 4tl73FvTsIFpKQRn2E2G+yGqr/W+SddijVieXW+/XODCn+nc29p2dYztuuikoPHBlBc4nDJ3sW8 OFKMNDcTk4mf+ZnTEcjXyce3Q== X-Received: by 2002:a05:622a:60b:b0:533:94fc:1e69 with SMTP id d75a77b69052e-535755237d0mr54333081cf.21.1791397010017; Wed, 07 Oct 2026 11:16:50 -0700 (PDT) From: Josef Bacik Date: Wed, 07 Oct 2026 18:16:22 +0000 Subject: [PATCH net-next 9/9] net: skbuff: don't reset truesize in skb_condense() if the pull fails MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261007-b4-pskb-pull-tail-drivers-v1-9-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791396985; l=1285; i=josef@toxicpanda.com; h=from:subject:message-id; bh=aE3S/MO9vLOemBhMvEWEtBv4CYrulZjUcAw8T5FEx9E=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QAKmlD/cXgBiooOoWC6A+H7tw5dWzG4gHatAYnnjbF9tFpPNqC/1rDXMvdLjveUvTCKNu/kJ24U cYCfNc2tlrQI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1791397011-BDEC6034-39718009/0/0 X-purgate-type: clean X-purgate-size: 1287 skb_condense() pulls all of the frag data into the head and then sets truesize to cover just the head, but it ignores the return value of __pskb_pull_tail(). If the pull failed, the frags would still be attached and truesize would undercount them. It can't fail today. The caller has checked that the head has room, that the skb isn't cloned and that the frags are readable, and pulling all of data_len eats every frag_list skb whole, so nothing is allocated. Check the result anyway and leave the skb alone on failure, so this stays correct if any of that changes. Use __skb_linearize(), which is what this pull is. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 43ebe61c7fc4..70df607da05e 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -7118,7 +7118,8 @@ void skb_condense(struct sk_buff *skb) return; /* Nice, we can free page frag(s) right now */ - __pskb_pull_tail(skb, skb->data_len); + if (__skb_linearize(skb)) + return; } /* At this point, skb->truesize might be over estimated, * because skb had a fragment, and fragments do not tell -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 07 19:22:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 19:22:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442748.1660299 (Exim 4.92) (envelope-from ) id 1xEXCz-0006OQ-4r; Wed, 07 Oct 2026 19:21:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442748.1660299; Wed, 07 Oct 2026 19: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 1xEXCz-0006OJ-1w; Wed, 07 Oct 2026 19:21:45 +0000 Received: by outflank-mailman (input) for mailman id 1442748; Wed, 07 Oct 2026 19:21:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEXCy-0006OD-Dy for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 19:21:44 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEXCw-001lXl-0z; Wed, 07 Oct 2026 19:21:42 +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 1xEXCv-004xqo-2r; Wed, 07 Oct 2026 19:21: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:References:Message-ID:Subject:Cc:To:From:Date; bh=TaWY11l20d4YtKC/7kW9m6cZPXITLgh/ZOnA/puDdRc=; b=l1SbtPD3YiQNbdw807o1IUPS75 7Ms4fcfRy2p3DGZOwEhEXFFT2CuZ/Ri0m2oJgB+gcfYneaI4UR2ijSvvBrot9hfBn+DBPVez/bskn S1I3Gj/zVFtcerxwouShjZJ7bclXJ6xSqQdJ4Ym4lxqud0i2mHa3bebSpnGbbG1Zpklw=; Date: Wed, 7 Oct 2026 21:21:34 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie , Tim Deegan Subject: Re: [PATCH v3 07/18] x86/hvm: introduce per-vCPU L3 page-table Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-8-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-8-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:40AM +0100, George Dunlap wrote: > From: Roger Pau Monné > > The per-domain area is currently a single domain-wide structure: one L3, nit: s/structure/entry/ might be better? > 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 > COMPAT_ARG_XLAT pages, and for PV each vCPU's GDT/LDT window 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. > > Allow the "per-domain" area to be per-vCPU instead ("VCPU-PT") for HVM > domains. HVM monitor tables are already per-vCPU, so this needs nothing > at context switch: every monitor table carries its vCPU's own L3 from > creation, and the per-vCPU mappings are isolated from other running > vCPUs at once. We will later build on this, adding a per-vCPU mapcache > and per-vCPU mapped areas, into which we can move the vCPU state > mentioned above. > > 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; PV > domains always use the domain-wide one.) > > In {create,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. > > Give init_xen_l4_slots() the vCPU a table is private to, and use Can't you replace the domain parameter with a vcpu one, and obtain domain as v->domain? > perdomain_l3() to select the value to install in slot 260 when one is > given. The HVM monitor tables and the 32-bit PV Xen-owned L4s pass > their vCPU; tables the domain's vCPUs share -- promoted PV guest L4s, > PV shadow L4s, and the PV dom0 L4 under construction -- pass NULL and > keep the domain-wide L3, which is all a PV domain has. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-fable-5-1, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - HVM only: PV domains keep the domain-wide area, so the PV parts go > (the single-vCPU limit, the shadow refusals, the XPTI slot install). > init_xen_l4_slots() takes the vCPU as an extra, optional argument > rather than in place of the domain, so PV guest L4s, which no vCPU > owns, are promoted exactly as before. Hm, I see, so this is the reason. PV L4s are promoted ahead of being loaded into a vCPU %cr3, and hence when init_xen_l4_slots() is called the per-vCPU L3 to use is not clear. > - Retitle (was: "x86/mm: introduce per-vCPU L3 page-table"). > - free_compat_arg_xlat()'s comment names free_pervcpu_mappings() as the > teardown for a vCPU-PT domain. > > Changes in v2: > - Added to the series > > Changes since the previously posted version: > - Expand the commit message with the motivation and the design > rationale. > - 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. > - 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. > --- > xen/arch/x86/domain.c | 10 +++-- > xen/arch/x86/include/asm/domain.h | 12 +++++ > xen/arch/x86/include/asm/mm.h | 5 ++- > xen/arch/x86/mm.c | 73 ++++++++++++++++++++++--------- > xen/arch/x86/mm/hap/hap.c | 2 +- > xen/arch/x86/mm/shadow/hvm.c | 2 +- > xen/arch/x86/mm/shadow/multi.c | 5 ++- > xen/arch/x86/pv/dom0_build.c | 2 +- > xen/arch/x86/pv/domain.c | 2 +- > xen/arch/x86/x86_64/mm.c | 7 +-- > 10 files changed, 87 insertions(+), 33 deletions(-) > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index b670cea52b..0aba2cca2e 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, NULL, NULL); > 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); Do we really need the extra label? It would seem to me like the existing cleanup functions are harmless to execute regardless of whether the matching initialization routine has been called. > > 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) > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h > index b192c86bc1..a6c6eaf53a 100644 > --- a/xen/arch/x86/include/asm/domain.h > +++ b/xen/arch/x86/include/asm/domain.h > @@ -335,6 +335,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. */ > @@ -691,6 +696,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 87bbe1a6f5..87131dd4bf 100644 > --- a/xen/arch/x86/include/asm/mm.h > +++ b/xen/arch/x86/include/asm/mm.h > @@ -369,8 +369,10 @@ int devalidate_page(struct page_info *page, unsigned long type, > int preemptible); > > void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d); > +struct page_info *perdomain_l3(const struct vcpu *v); > void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, > - const struct domain *d, mfn_t sl4mfn, bool ro_mpt); > + const struct domain *d, const struct vcpu *v, > + mfn_t sl4mfn, bool ro_mpt); > bool fill_ro_mpt(mfn_t mfn); > void zap_ro_mpt(mfn_t mfn); > > @@ -609,6 +611,7 @@ int create_perdomain_mapping(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 ca22107cd3..7258935528 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -1638,6 +1638,17 @@ 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. > + */ > +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. > * > @@ -1645,12 +1656,16 @@ static int promote_l3_table(struct page_info *page) > * 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. All other parameters are optional and will either fill or zero the > - * appropriate slots. Pagetables not shared with guests will gain the > + * *l4t. v names the vCPU the table is private to (an HVM monitor table, a > + * 32-bit PV vCPU's Xen-owned L4), or is NULL for tables the domain's vCPUs > + * share; it is mandatory for a vCPU-PT domain, whose per-domain area is > + * per-vCPU. 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 domain *d, const struct vcpu *v, > + mfn_t sl4mfn, bool ro_mpt) > { > /* > * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full > @@ -1678,8 +1693,11 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, > l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW); > > /* Slot 260: Per-domain mappings. */ > + ASSERT(!v || v->domain == d); > + ASSERT(v || !d->arch.vcpu_pt); > l4t[l4_table_offset(PERDOMAIN_VIRT_START)] = > - l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); > + l4e_from_page(v ? perdomain_l3(v) : d->arch.perdomain_l3_pg, > + __PAGE_HYPERVISOR_RW); > > /* Slot 4: Per-domain mappings mirror. */ > BUILD_BUG_ON(IS_ENABLED(CONFIG_PV32) && > @@ -1835,7 +1853,7 @@ static int promote_l4_table(struct page_info *page) > if ( !rc ) > { > init_xen_l4_slots(pl4e, l4mfn, > - d, INVALID_MFN, VM_ASSIST(d, m2p_strict)); > + d, NULL, INVALID_MFN, VM_ASSIST(d, m2p_strict)); > atomic_inc(&d->arch.pv.nr_l4_pages); > } > unmap_domain_page(pl4e); > @@ -6216,7 +6234,7 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va, > struct page_info **ppg) > { > 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; > @@ -6225,14 +6243,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); > @@ -6242,7 +6263,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))); > > @@ -6339,16 +6360,16 @@ 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; > > - 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 ) > @@ -6387,16 +6408,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 ) > { > @@ -6432,10 +6448,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; We have been (recently) following the model of first setting the pointer to NULL, and then freeing it, ie: struct page_info *l3_pg = v->arch.pervcpu_l3_pg; if ( !l3_pg ) return; v->arch.pervcpu_l3_pg = NULL; free_perdomain_l3(l3_pg); Like XFREE() and similar macros. It's possibly worth using the same pattern here. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 07 20:21:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 20:21:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442769.1660308 (Exim 4.92) (envelope-from ) id 1xEY8M-0006NB-94; Wed, 07 Oct 2026 20:21:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442769.1660308; Wed, 07 Oct 2026 20:21: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 1xEY8M-0006N4-6A; Wed, 07 Oct 2026 20:21:02 +0000 Received: by outflank-mailman (input) for mailman id 1442769; Wed, 07 Oct 2026 20:21:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEY8L-0006My-5O for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:21:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEY8J-00AAtX-TF for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 22:20:59 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6a973-bab6-0a2a0a5309dd-0a2a4504c31e-30 for ; Wed, 07 Oct 2026 22:20:59 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac6a9ab-b57f-0a2a45040019-d1558030dd55-3 for ; Wed, 07 Oct 2026 22:20:59 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a17f65ab8bso7829295e9.1 for ; Wed, 07 Oct 2026 13:20:59 -0700 (PDT) Received: from [10.100.0.120] (cst2-151-250.cust.vodafone.cz. [31.30.151.250]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1842abfbdsm16240185e9.4.2026.10.07.13.20.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 13:20: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; none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791404459; x=1792009259; 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=WOBu50LMlpYF3gCdofVWzPBym8WuwUtov6HfU896/jY=; b=DRMaI6VFaswsAtWZQLwZJ1BmQc6WCxMvi0IJq7osBpS0Xf8qhB6PYs0k2W5iYg7Odk ZP+OArBPtM1+HqIsRIv/mOQM0q1JciohGBadtirPaZKcx3d19hhEW+PddUiQeqOvU0wP GHgpwE9OVaLhpsvs4iE0YtOomCHr2Og+5r7VEeyvrjmsF/0GozJrwvxoSRQ3eqrHXKh/ +K6X4ycVd/MBIAZhncZ/H7Y8nfSPVEwt7SlxZZV3anSpEytiONAkh+65bC8809Kw7455 yLDLKPjrC4CL5UYpFeFPzzp/mdHSPYBvY2SQ+cmb1D8iIXNaACfPzUUKlir8lbkKKXSY jbMg== X-Forwarded-Encrypted: i=1; AKwUvBzbXTdylaWeYrcYA/Qvenai/YqM5vj0z6mjner2sFwWjk+q3YyRWC5pCZcPMSlz/61lxJDTfMqSrNM=@lists.xenproject.org X-Gm-Message-State: AFuF++lJa3DvFY/6nI7XBY5eaVDzXa/JUWM+WTJRQ00hWBw/SIZGUQ7K NdTv4q94pVOzd1vN/chVwgpIXiqYcxYSEooeJwCpbtUk/7WRTOdkrtI6 X-Gm-Gg: AYBFou1DrT3to0x0xjai9RClxz39hotuUXpRVIGT/Tx5pourci/s/+eRwfEKyC90Wk2 3szXCnmVZQdu8obAoBN3bItmsDrDfHL/9oja2znxasXVYTHVkEZuhThvpHRZ8IJr9QTWDOn06F3 tlmRnffZcHD9e5zXZjy4aR274EOmGIgNjPADOTk70Fm8PDcM2q3EjDYcxJYXwf/ONiVnhpSM0NC 7as836nJ+lcncaCwal74hNE/SY0SvBgMC/GBT0gfyG52eHZhSgbKVB99mBMQDIM6kffaOnAGIJH ++DWG3b+C5iko9au6bGGm9B/Flbfm4rQ3Z6CQQu6AHtX9vV2QBAjQmffVufTXQqoofZM8JVnCQ3 +mMXYDTdAveFQHO5IHqksrCPSay5sU6/9fO8mNf4mY5btG2tEwA5iCLH5QaOLmcIJxi6NGUfOn1 8giF4uIaAAdSQojJqBgltPZiP/tCNP8BMwFEDD84QzSmQHDX+IdYr9yULcguZyztkXm9w3Rfo7z lwZdiTIvBn5N47qXm6JZIHRHbXDi89RSVhuZlB5XLiF5NMZ2Lw= X-Received: by 2002:a05:600c:3e0b:b0:4a0:c02:938c with SMTP id 5b1f17b1804b1-4a1804459e5mr60188195e9.25.1791404459187; Wed, 07 Oct 2026 13:20:59 -0700 (PDT) Message-ID: <055dc887-0cfd-4274-a5f6-e5afdd576746@xen.org> Date: Wed, 7 Oct 2026 22:20:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Fix under-mapping in map_range_to_domain() To: Michal Orzel , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20261007135848.220047-1-michal.orzel@amd.com> Content-Language: en-GB From: "Grall, Julien" In-Reply-To: <20261007135848.220047-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791404459-53CC7B50-85C40E27/0/0 X-purgate-type: clean X-purgate-size: 1189 Hi Michal, On 07/10/2026 15:58, Michal Orzel wrote: > If the memory region to be mapped does not start at the page boundary > and its end spans over the page boundary, map_range_to_domain() passes > a number of pages that is short by one to map_regions_p2mt(). Domain's > attempt to access memory within that page will fail. Fix it by calculating > the number of pages to be mapped taking into account the start offset. Can you provide an example where the caller doesn't suitably align? > > Fixes: 88c10b0d6eee ("arch/arm: let map_mmio_regions() use start and count") > Signed-off-by: Michal Orzel The fix LGTM in the current context. However given map_range_to_domain() is now used in more places (e.g. overlay), I wonder whether this is the right decision to allow map_range_to_domain() with non-aligned region. Imagine a user say "I want to map 0x400 - 0x1000 to domain A and map domain B "0x0 - 0x400". This could result to interesting behavior if the user is not aware of the alignment (this would become even more problematic if we decide to ever support different page granularity on Arm). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Oct 07 20:40:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Oct 2026 20:40:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442781.1660316 (Exim 4.92) (envelope-from ) id 1xEYQf-0008Av-Ly; Wed, 07 Oct 2026 20:39:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442781.1660316; Wed, 07 Oct 2026 20: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 1xEYQf-0008Ao-JI; Wed, 07 Oct 2026 20:39:57 +0000 Received: by outflank-mailman (input) for mailman id 1442781; Wed, 07 Oct 2026 20:39:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEYQe-00089d-HX for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 20:39:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEYQd-00AKwi-Di for xen-devel@lists.xenproject.org; Wed, 07 Oct 2026 22:39:55 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac6ae1a-8faa-0a2a0a5109dd-0a2a450982e8-2 for ; Wed, 07 Oct 2026 22:39:55 +0200 Received: from [40.107.162.93] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac6ae1a-be1a-0a2a45090019-286ba25d4c39-3 for ; Wed, 07 Oct 2026 22:39:55 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by AS8PR03MB7335.eurprd03.prod.outlook.com (2603:10a6:20b:2eb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Wed, 7 Oct 2026 20:39:52 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.015; Wed, 7 Oct 2026 20: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=E/nOhF+Jotbs1HZ/g5UZQxD1ccfqvr/LP/gVs4CFn1PqWwIF00QYu//ilR2Tqcy9LwBCjZcf4UDcSc2RACMVXNM2uSFXWEsBltUN8sz3UnG33eCy9NEPqU5QigCDsdjdMcK6VJUufftyElsMw23ClPgjDdfKJGGrTxnI2t3LH8C+wkArpSf7LQHXF2o4Rrmf/zhudmvoNjMxsJuod6mB+f+TpasuJmBMYqQu+bIMYVkIL33/9+VynY0RP6tl9+TpdkMhBScHmLgvPg5ITY9iOO2usuvoEwapOHXQOqxYADpAYBgICJQSXfcyNQ2KOs9Gn+SZE1oB2UGQh82aLTjO8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eG2iyk45wfTTtGBClH2QYspdg4KSKGMoA6n0lnGh65E=; b=LH8pqquNoUoJp8X11KvUzBH96d5Tn6xCHelMd+lxggYXnzPX46RiQpuDJgtZNH0IA6YlmSnfzI2vWB6WO5RzCmFp+DO1MNqDDrBe/Q2Ovh+al5MWMs0VZNPqPhWwq3XphgAuz7YDVsQpZIPcOJukirq0exoT0mJID4unUBEKxytJbzrGD7jCqv43jqtyUNrTDwkKhCE7qKHqw7fzrwIV2xTlh+DQi/Tt/IGvxhKCNr5JvMxKvcBNIZW0JYIeWmDqrY3I0chkHOqTcSM+SeOGQaEsFbnc0+9LlYi7+gy41FWE/4AnzkEeMmT4dxNAhZ1HTVOMzA5v5cqbHPlwV1vlgA== 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=eG2iyk45wfTTtGBClH2QYspdg4KSKGMoA6n0lnGh65E=; b=jvnM1x9kBpxid4/RomOi2ymK8hY/q6T1RC6ZwKXpfkeQpGFkqU3+4vA1R8lMMPC2mTZsDYjUrdAbwitrgfNnRh7K5XYxk1o9Q96a2jLPIvw+reUmpvIaa9Mw039W8gI0cjyOK07uDAuQtPJaQtKqKTXTTH/Z3vD//TkPKW2kosPJcfIp3/XQR2KenZSp6tXcZXQjLCAkajG0+X7SWmag+dWmPh0zHwtAMjuBOIvjXLlyRHXrUCVXL99k5kLkeUK29WBKeQl8TS/NrW8mkwXlIj+y6zOEyoH9ijf0vKl42k6hj1345deutsm51rT7EQt/HnQ+5mTkMLioP9FS57vmUA== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stewart Hildebrand , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: [PATCH v2] vPCI: resolve MISRA R10.1 boolean arithmetic type violation Thread-Topic: [PATCH v2] vPCI: resolve MISRA R10.1 boolean arithmetic type violation Thread-Index: AQHdVpwBNG1sftA3/ky6kFfXebDmZA== Date: Wed, 7 Oct 2026 20:39:52 +0000 Message-ID: <7549daf9e0de3420198913f6f91c16c929a31834.1791404375.git.dmytro_prokopchuk1@epam.com> Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|AS8PR03MB7335:EE_ x-ms-office365-filtering-correlation-id: 12160b7b-febc-4f23-eb87-08df24b3238e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|42112799006|1800799024|23010399003|376014|18002099003|11063799006|56012099006|10067099003|260925022911599003|260925021911599003|260925021311599003|38070700021; x-microsoft-antispam-message-info: VkjTdVk1UW8G6za2x5qVK9Uxu2fCqHISFtwXeyovaXXUgTkOQ/lWmb1/9lw+tzoe2KfwaLSAbBgcTVJ7rlEHgGX/v3LNCP9s2K9mpG3p/vIGfVB22umayKd7+uVf2JXC4ds5H9HfdhJufgKF/FfHfK3R/hDvSEh+IcBApIRHmsMY15ZlKKEgH/Z6W4DB5mY+NSGCumv1MOgNDRdtJ5S6IByVXKNCLOEtwoYS/1UBgUxR/wVbfEOeihUBocEuxW3BKWP7Fog4guDCIusSSSqANqxwdszw40624bgVm4/VRAf3O3pLjlVeueUo97e/1k7LVNgKaVfcVbxdbfoM+eQ12xzgfuxMK69gGzQv65qLnoko+LfulGlJB13RdOi9QB85A3I0YdkwizPHMZo0tjRFKkEv3oxj5mkGO6r/jx95fQG1VOiUe2M8vfehNcDd5M/LNM3/9qG13Ie+u2fbJ1Rqr87m1/Pnwb20J/gsgx0umBjDpF2JkzkDOhFIhsNS11rXU6rTLYIRXl+7GZEgMlRRmoFkiD+X5tSLOHX+PDCC9fIl8X9nm8WdbNGYTUnzHSqlPjS5aDG0Y7sSIVb279Ociq93V0muvUVoOSK1pvBPLd1LCesv+C9/e19Zy8fd5VwRgh0uilqKOHbL/Xkc5UxHfGk0TuiKTpuaUSYRfk3l6Qs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(42112799006)(1800799024)(23010399003)(376014)(18002099003)(11063799006)(56012099006)(10067099003)(260925022911599003)(260925021911599003)(260925021311599003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SkU0cU1zd20zUlBrdzRIampBdzR0dmY4ekIxOWhyYzFGR0JVRGxQd0lUS3Zq?= =?utf-8?B?ak9IalJOd0YzT1l2Slo3RVZQVkhVSWV3VkJ0MkZXMDJGK2tteHA1Uk01K0ZG?= =?utf-8?B?UmtWMmxPeGI4UlVHcm9sZ01vV3VwUEZ2Rk5PRFRsd0RMSnpvSmtJekUra3dm?= =?utf-8?B?YUoyUVIzbkhIZmI1N251ejBFVmt5MlZmUnp2MW1xb1oxT1l1VFR1UnNrQ2l6?= =?utf-8?B?N08vZmRNSFEyWTFFcEJuN0ZnVlg4Q09aTU9zQnNOMnEyRVlyYk81NE1NMjB5?= =?utf-8?B?NTZmMkYyanNqM3J4dlVxcnlPSzFrK3FGT1o4WWtSa2JrU0ZVUmhiVUJtekc3?= =?utf-8?B?a1lDUDNVVWU0VXRUczZBUkRoN2dGd0VzVG8rbkdNNWhxSjBZdkx5OERndDgv?= =?utf-8?B?M0NvcDJZN0lqNjBBNjZWY1F2Mm9PYjdrOUNFVHViUUZUUm5PZzE5UHRzUnd5?= =?utf-8?B?N2t5MVNWWUZzMCtlaTJaWHJXb3ZodW9zOTdMRHBGaU1GRU5uVVdUSTgxME1y?= =?utf-8?B?YVpJWktNOWhoZFlNYWlibDM4UFlmSEtjVDlQVTVYdlV0NzJJVyt2OU1aeFdL?= =?utf-8?B?MmF6dythcVduNmduQjY0NitHTzN2Y3ptazM0V2FhNUdLR2NoZzlkQW9WS3di?= =?utf-8?B?OEdpNmVVb1Y4N0xobFljMUZpRjRTTmQ2czhqdWRqbnlKbmlIT3IxVC9HUnRF?= =?utf-8?B?UjhCcUd3eGhkN3pZMkVQdnVHN2NpUU10ZFQ3MHg2TlptS3VqWjJ3S1pXZFpR?= =?utf-8?B?NEhicmRDMGUySjIvRWxFQllMR0RMWng4dE1vZFJicnl2WmdkcDlweitvOUgw?= =?utf-8?B?bmtKSGtScElWVUVscGJJazZVR1p2cnQySmhUWGdBdzZERHJIdm4yNFB1R3Fp?= =?utf-8?B?N2lvWmVKbWFpeDRGVFljYU8xSFpiKytSK1YwenEzYnFwOE5RR1pyQ3Y3bUNs?= =?utf-8?B?Mm9lUWUrOEtwTFlTeW5ZaXFYOFlPY3pyZzhZZTZzSi9yZUVaM0R0QS9xWlI5?= =?utf-8?B?SjZvcGZqbkIzaERWYm5oby9wYTY5aEhqdTZYVEZuS3p0UUx6Q3dwRzM0djZu?= =?utf-8?B?SDlzTWxaRVpKSHk5SHVoN3dySjkzSHBjVDd6RVBQeEpqUTE1U1ArQWlyNDFm?= =?utf-8?B?Y2VWZGlPQ242a1piVmhMOUVwTitxWHg5SGtMSjZCTjFRaXhYZDZBQ0ozZTVE?= =?utf-8?B?V09naEZCTHhvSjNrQmJwbzhkMlczSnFnSGhJa3V0ZVROckk0dWxNZlBHVm1X?= =?utf-8?B?b2hmTU9KQ2J1a2IwQTZ5cE9IKzdvM3RLdVdpRlZtK1Rnc1lNakZTTWxzZVBT?= =?utf-8?B?bkJaa0YydXNwUTlMVDdzb1ZaVXQyMm5Yb1VZSm41R3FvNTdWN0Flcmt3TEdu?= =?utf-8?B?OExGYzNjWlRKWElKQmtYYisrUlNpVmpoWmRZL25DTmoxSnhreHA0TVlpQXB3?= =?utf-8?B?ZlFLbGtZVm9jcG5RYnR3NHQvMEp0NzEvZHBBcnVvemhBMTN1YlpsYjVKNjVH?= =?utf-8?B?TExEd2hHbDl5bjBXNDE3Rk16bTg1NjNUU0xlWWUzSC9qQUpFcVJHYkxRaFhw?= =?utf-8?B?S2czeC93MlRqV1dmT3lMUWM0VlFjdDBncUt0OUs1a0dvVGtyTDQ5cDJvZjN6?= =?utf-8?B?OGRzUkhSOVlRZW9pNFBCMzFnUDcwcmtlUm1OOTBMZkZSVU5meFE3OCtiN0VF?= =?utf-8?B?OU5KMW1kTGVZOS9XTW53TlNKY1Rwd2dKd2h2ODg4SU1Td2RBOUs2Wm4xdnAw?= =?utf-8?B?VFBkY25ERjFFV3lSbEVOdUIrR0FQbmRYVkhES09ZOUV2VGJlaU1odE1PUGNX?= =?utf-8?B?Qk1jaFpKWnpZcEhySDdqaS9VdXR1b0pUaUk5NnlnSzZscWE2dkg5QXgyQ0ha?= =?utf-8?B?T09KVzUwNW9UM1FNQ1VPVXBOYWxLQ1M0aFNhK2p5ZXlrMUtMNWNNbDB4SzQz?= =?utf-8?B?WkVXY213SUJBOG1KU3orOHJPcUl0Rkh0Vlp2ZjhkTkZ2c2p1RkFSZW8xMThw?= =?utf-8?B?QS9NaDhzek9TZUIweFpraHByTVZ5aW1venNmL1Z5elduSklVZ0xqOHdEZlBH?= =?utf-8?B?cmFsdk03M3cvNlRMNkVmUVB4akFKNnAxTzRWdk5uWFdGRC9YM3grb0FQMzd6?= =?utf-8?B?YjJrL2NKWUMvcWNFK0Q2OFkwMnhYdFlBRFU0VjB1S2ZzVVpGMEM1K05CUGda?= =?utf-8?B?N1FsYjhMQ2lFdUt2NnZaZU1NM3ZSNjVvYXBWZDA0ekkwRDlLbjlMMDZmUXFP?= =?utf-8?B?S3NvQmU5dWdLOEg5RzhEMGh5QklRRkk5bjhuNlhzSDJmWHFaTTNvZitSc3V3?= =?utf-8?B?Sk5qei9wNE01RlJ6ekR4eTdiandTcGFmeVFYNmVBdDVPQkZ4ek05alpjb3Vo?= =?utf-8?Q?rCY1oqXpRmvnJ/b8=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <74BC962BD394E848BD48D032B337B0D7@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12160b7b-febc-4f23-eb87-08df24b3238e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2026 20:39:52.3658 (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: XVFpj1CQlD1rJKrnIZ8Kj1nPpKnIj787bDIN0L7ZOkUIhJhEjzOQMQnvAaBE+RsbY3B4Iq/Sz54e9yLawDE5vOr9LjnQFIh0ZIRKilzXDMI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7335 X-purgate-ID: tlsNG-bad1c0/1791405595-BC2F4034-E538EEAB/0/0 X-purgate-type: clean X-purgate-size: 3294 TUlTUkEgQyBSdWxlIDEwLjEgc3RhdGVzOiAiT3BlcmFuZHMgc2hhbGwgbm90IGJlIG9mIGFuIGlu YXBwcm9wcmlhdGUNCmVzc2VudGlhbCB0eXBlIi4NCg0KYmFyX3dyaXRlKCkgYW5kIGd1ZXN0X21l bV9iYXJfd3JpdGUoKSBhZGRlZCB0aGUgYm9vbGVhbiAnaGknIHRvIGENCnBvaW50ZXIgZGlmZmVy ZW5jZSB3aGVuIHByaW50aW5nIHRoZSBpZ25vcmVkIEJBUiBpbmRleC4gVGhlc2UgaGFuZGxlcnMN CmFyZSByZWdpc3RlcmVkIG9ubHkgZm9yIHRoZSBtZW1vcnkgQkFSIHJlZ2lzdGVycywgc28gcHJp bnQNCihyZWcgLSBQQ0lfQkFTRV9BRERSRVNTXzApIC8gNCBpbnN0ZWFkLiBUaGUgZXhwcmVzc2lv biBoYXMgdHlwZQ0KdW5zaWduZWQgaW50LCBzbyB1c2UgJXUuDQoNCk5vIGZ1bmN0aW9uYWwgY2hh bmdlcy4NCg0KU3VnZ2VzdGVkLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4 LmNvbT4NClNpZ25lZC1vZmYtYnk6IERteXRybyBQcm9rb3BjaHVrIDxkbXl0cm9fcHJva29wY2h1 azFAZXBhbS5jb20+DQotLS0NCkluIHRoZSBWMSAoaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vZTIz MjY2MTkxYTM2NmFiZTY2ZDgxMDQ3ODNkOTc1NzhhYTg3MzRhNC4xNzc5NDI4ODI2LmdpdC5kbXl0 cm8uXzVGcHJva29wY2h1azFAZXBhbS5jb20vKQ0KdGhlcmUgd2FzIGEgbG9uZyBkaXNjdXNzaW9u LCBhbmQgSSBkb24ndCBzZWUgYSBtdWNoIHNlbmNlIHRvIGFuc3dlciB0aG9zZSBxdWVzdGlvbnMN CihhY3R1YWxseSBJIGRvbid0IGhhdmUgYWRkaXRpb25hbCBwcm9wb3NhbHMpLg0KDQpMb29rcyBs aWtlIG1vc3QgYWdyZWVkIHdpdGggUm9nZXIncyBhbHRlcm5hdGl2ZSBmb3IgdGhpcyBjYXNlLg0K U28sIGxldCdzIHByb2NlZWQgd2l0aCB0aGF0Lg0KDQpWMiB0ZXN0IHBpcGVsaW5lOiBodHRwczov L2dpdGxhYi5jb20veGVuLXByb2plY3QvcGVvcGxlL2RpbWFwcmtwNGsveGVuLy0vcGlwZWxpbmVz LzI5MjM5MTk1OTINCi0tLQ0KIHhlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgfCA4ICsrKystLS0t DQogMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkNCg0KZGlm ZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgYi94ZW4vZHJpdmVycy92cGNpL2hl YWRlci5jDQppbmRleCBkMWM5MmNmNzdmLi43ZTVmNGI4YTAwIDEwMDY0NA0KLS0tIGEveGVuL2Ry aXZlcnMvdnBjaS9oZWFkZXIuYw0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0KQEAg LTU4NSw4ICs1ODUsOCBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayBiYXJfd3JpdGUoDQogICAgICAg ICAvKiBJZiB0aGUgdmFsdWUgd3JpdHRlbiBpcyB0aGUgY3VycmVudCBvbmUgYXZvaWQgcHJpbnRp bmcgYSB3YXJuaW5nLiAqLw0KICAgICAgICAgaWYgKCB2YWwgIT0gKHVpbnQzMl90KShiYXItPmFk ZHIgPj4gKGhpID8gMzIgOiAwKSkgKQ0KICAgICAgICAgICAgIGdwcmludGsoWEVOTE9HX1dBUk5J TkcsDQotICAgICAgICAgICAgICAgICAgICAiJXBwOiBpZ25vcmVkIEJBUiAlenUgd3JpdGUgd2hp bGUgbWFwcGVkXG4iLA0KLSAgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIGJhciAtIHBk ZXYtPnZwY2ktPmhlYWRlci5iYXJzICsgaGkpOw0KKyAgICAgICAgICAgICAgICAgICAgIiVwcDog aWdub3JlZCBCQVIgJXUgd3JpdGUgd2hpbGUgbWFwcGVkXG4iLA0KKyAgICAgICAgICAgICAgICAg ICAgJnBkZXYtPnNiZGYsIChyZWcgLSBQQ0lfQkFTRV9BRERSRVNTXzApIC8gNCk7DQogICAgICAg ICByZXR1cm47DQogICAgIH0NCiANCkBAIC02NDYsOCArNjQ2LDggQEAgc3RhdGljIHZvaWQgY2Zf Y2hlY2sgZ3Vlc3RfbWVtX2Jhcl93cml0ZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCiAg ICAgICAgIC8qIElmIHRoZSB2YWx1ZSB3cml0dGVuIGlzIHRoZSBjdXJyZW50IG9uZSBhdm9pZCBw cmludGluZyBhIHdhcm5pbmcuICovDQogICAgICAgICBpZiAoIGd1ZXN0X2FkZHIgIT0gYmFyLT5n dWVzdF9hZGRyICkNCiAgICAgICAgICAgICBncHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KLSAgICAg ICAgICAgICAgICAgICAgIiVwcDogaWdub3JlZCBndWVzdCBCQVIgJXp1IHdyaXRlIHdoaWxlIG1h cHBlZFxuIiwNCi0gICAgICAgICAgICAgICAgICAgICZwZGV2LT5zYmRmLCBiYXIgLSBwZGV2LT52 cGNpLT5oZWFkZXIuYmFycyArIGhpKTsNCisgICAgICAgICAgICAgICAgICAgICIlcHA6IGlnbm9y ZWQgZ3Vlc3QgQkFSICV1IHdyaXRlIHdoaWxlIG1hcHBlZFxuIiwNCisgICAgICAgICAgICAgICAg ICAgICZwZGV2LT5zYmRmLCAocmVnIC0gUENJX0JBU0VfQUREUkVTU18wKSAvIDQpOw0KICAgICAg ICAgcmV0dXJuOw0KICAgICB9DQogICAgIGJhci0+Z3Vlc3RfYWRkciA9IGd1ZXN0X2FkZHI7DQot LSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Thu Oct 08 07:19:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 07:19:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442973.1660334 (Exim 4.92) (envelope-from ) id 1xEiOv-0007E9-7B; Thu, 08 Oct 2026 07:18:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442973.1660334; Thu, 08 Oct 2026 07:18: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 1xEiOv-0007E2-4G; Thu, 08 Oct 2026 07:18:49 +0000 Received: by outflank-mailman (input) for mailman id 1442973; Thu, 08 Oct 2026 07:18:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEiOt-0007Dw-DI for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 07:18:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEiOs-00BPYn-QR for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:18:46 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac743d1-bab6-0a2a0a5309dd-0a2a450cdb74-18 for ; Thu, 08 Oct 2026 09:18:46 +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 6ac743d5-f479-0a2a450c0019-c387df829c68-3 for ; Thu, 08 Oct 2026 09:18:45 +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 6612A21B5A; Thu, 8 Oct 2026 07:18:45 +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 EA98213354; Thu, 8 Oct 2026 07:18: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 gwkoMNJDx2otcQAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 07:18: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: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-Type:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1791443925; 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; bh=+Zu9EkyDeEf3sTMIssXK8yB1SpG14s7M8zu+mZwF9dw=; b=Ijw0v335ATWAH8BGZYbce0h0Z5ZjdSozluRBn2LNhl55YQ3SFuIcMthD7UbZ7h/QX79BMk dwYPMvKKXhyNQp442zOMtMhWpXbIMUD1twHawcJ9T6ZwRyAdhcN8png7n1M47vXecuxMgG sBks/5FLgUfVw0FsIR7VOP5kSvrS5Qk= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1791443925; 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; bh=+Zu9EkyDeEf3sTMIssXK8yB1SpG14s7M8zu+mZwF9dw=; b=Ijw0v335ATWAH8BGZYbce0h0Z5ZjdSozluRBn2LNhl55YQ3SFuIcMthD7UbZ7h/QX79BMk dwYPMvKKXhyNQp442zOMtMhWpXbIMUD1twHawcJ9T6ZwRyAdhcN8png7n1M47vXecuxMgG sBks/5FLgUfVw0FsIR7VOP5kSvrS5Qk= 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 v4 00/13] x86/msr: Drop 32-bit MSR interfaces Date: Thu, 8 Oct 2026 09:18:26 +0200 Message-ID: <20261008071839.2247074-1-jgross@suse.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Flag: NO X-Spam-Score: -1.80 X-Spam-Level: X-Spamd-Result: default: False [-1.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; 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]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo] X-purgate-ID: tlsNG-d25034/1791443925-5290EA5B-BEC846CE/35/110847 X-purgate-type: clean X-purgate-size: 10367 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-10-07. IMHO at least patches 2 and 3 should be applied rather sooner than later in order to avoid new instances of the 32-bit variants of the *_safe() functions creeping in again. Changes in V2: - dropped already applied patches - added patch 1 - rebased Changes in V3: - small fixes in patches 4 and 13 - rebased Changes in V4: - 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 | 6 +-- 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, 576 insertions(+), 695 deletions(-) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 07:20:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 07:20:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442977.1660343 (Exim 4.92) (envelope-from ) id 1xEiQ4-0007gH-Ge; Thu, 08 Oct 2026 07:20:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442977.1660343; Thu, 08 Oct 2026 07: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 1xEiQ4-0007gA-DE; Thu, 08 Oct 2026 07:20:00 +0000 Received: by outflank-mailman (input) for mailman id 1442977; Thu, 08 Oct 2026 07:19:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEiQ2-0007g1-Fr for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 07:19:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEiQ1-00BQ4D-Sh for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:19:57 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac74411-8faa-0a2a0a5109dd-0a2a4504c37e-28 for ; Thu, 08 Oct 2026 09:19:57 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7441d-b57f-0a2a45040019-c387df83aba8-3 for ; Thu, 08 Oct 2026 09:19:57 +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 DE8671F786; Thu, 8 Oct 2026 07:19:56 +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 6D4F913354; Thu, 8 Oct 2026 07:19: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 +HIxERpEx2pTcgAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 07:19: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: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-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1791443997; 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; bh=GvSWUwsXYcEZU/uMpHHlbW0flpKBPYidSJ9VIEc3i7g=; b=VouT4WRRI4a0v0wrZ3IaZa9LBFbTFxiFVaaSGnSf5GPayb9pMbQguW2Rfxp1QuUjFwKgl8 Hu0UHecYkkRFC/y36wU4INER2teaOxVkuB4UG42ZnnfXOPk8lVjbrchK6cBxM374iYptf1 lEhcVtiyusiy5XiSI6B5PL5j7tgYYHg= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1791443996; 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; bh=GvSWUwsXYcEZU/uMpHHlbW0flpKBPYidSJ9VIEc3i7g=; b=qdNon6+X6rlxEgsAvrMwxRn9p7V7mtkRX3vq2T2vYVqaXX6CGmllAGs4GYOSR7vk93Fisf bIojXbKqLyYFh+9Dg3jDWoJbeICxIIf3vBEG77Itylov6zvKzwXLeuCBoHEsN8ofKW6vLS bXjXZaXtCdtImDkRwl2D7ICc0mhZpQ8= 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 , Zhongqiu Han Subject: [PATCH v4 12/13] treewide: convert rdmsrq() from a macro to an inline function Date: Thu, 8 Oct 2026 09:18:38 +0200 Message-ID: <20261008071839.2247074-13-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261008071839.2247074-1-jgross@suse.com> References: <20261008071839.2247074-1-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -5.80 X-Spam-Level: X-Spam-Flag: NO X-Spamd-Result: default: False [-5.80 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVRCPT(0.00)[outlook.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[suse.com,kernel.org,redhat.com,alien8.de,linux.intel.com,zytor.com,infradead.org,arm.com,google.com,intel.com,linaro.org,microsoft.com,broadcom.com,hygon.cn,amd.com,zhaoxin.com,oracle.com,selenic.com,gondor.apana.org.au,roeck-us.net,gmail.com,arndb.de,linuxfoundation.org,bootlin.com,nod.at,ti.com,gmx.de,lists.xenproject.org,lists.infradead.org,outlook.com,oss.qualcomm.com]; R_RATELIMIT(0.00)[to_ip_from(RLbixyxwsf3a5i7e4ez64ejni4)]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_GT_50(0.00)[97]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,intel.com:email,outlook.com:email,imap1.dmz-prg2.suse.org:helo,qualcomm.com:email] X-purgate-ID: tlsNG-ebf023/1791443997-C3AC08F0-26F52D9F/35/110847 X-purgate-type: clean X-purgate-size: 167599 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: Rafael J. Wysocki (Intel) # ACPI, cpufreq, powercap, thermal Acked-by: Sean Christopherson Acked-by: Reinette Chatre # resctrl Reviewed-by: Zhongqiu Han # cpufreq Acked-by: Ilpo Järvinen # pdx86 --- 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 | 6 ++-- 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, 484 insertions(+), 486 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 54b13faba116..0cc060c7a9e6 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 a55646fcb846..0972690c7d45 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 3ef80882843e..ab52322e9fb7 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -2975,7 +2975,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; } @@ -3519,7 +3519,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) { /* @@ -6310,8 +6310,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 @@ -6467,7 +6466,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; @@ -8048,7 +8047,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 d0329a7eb8a5..6089e9e0e0f8 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -3239,7 +3239,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 22e2a06d5786..49e474c98e5a 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); *br = (struct perf_branch_entry){ .from = msr_lastbranch.from, 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 fab9da78a5c7..6f91dfeaacee 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -1471,11 +1471,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); } } @@ -1629,7 +1629,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 39f238952e14..0d1a0f9a0333 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; } } @@ -2207,7 +2207,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 9f09d388ed20..7d481d28fcdb 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -1017,7 +1017,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 fe0cba4731b2..305b818f77a6 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4625,8 +4625,8 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags) vmcb_mark_all_clean(svm->vmcb); 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); } /* if exit due to PF check for async PF */ @@ -5482,7 +5482,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 b25216862740..a0fbc5508823 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -7359,8 +7359,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 70a8c4816135..b610bd411bcb 100644 --- a/arch/x86/kvm/vmx/pmu_intel.c +++ b/arch/x86/kvm/vmx/pmu_intel.c @@ -323,7 +323,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); @@ -775,7 +775,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 @@ -804,7 +804,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); @@ -819,7 +819,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 aad065d035fb..afc64d2825f5 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 17158cb25dd8..4681d0a51fac 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); } @@ -1359,7 +1359,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; @@ -1736,7 +1736,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); } @@ -2030,7 +2030,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; } @@ -2038,7 +2038,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; } @@ -2046,7 +2046,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; } @@ -2077,7 +2077,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); @@ -2093,7 +2093,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); @@ -2104,7 +2104,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( @@ -2112,7 +2112,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; } @@ -2460,8 +2460,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); @@ -3652,7 +3652,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"); @@ -3708,7 +3708,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 Thu Oct 08 07:35:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 07:35:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442989.1660352 (Exim 4.92) (envelope-from ) id 1xEiez-0002dX-Vp; Thu, 08 Oct 2026 07:35:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442989.1660352; Thu, 08 Oct 2026 07:35: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 1xEiez-0002dQ-T4; Thu, 08 Oct 2026 07:35:25 +0000 Received: by outflank-mailman (input) for mailman id 1442989; Thu, 08 Oct 2026 07:35:24 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEiex-0002dK-W9 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 07:35:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEiev-002Yru-Vc for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:35:21 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac747b6-e002-0a2a0a5209dd-0a2a4507cd4c-10 for ; Thu, 08 Oct 2026 09:35:21 +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 6ac747b9-b4ea-0a2a45070019-d1558035bd7d-3 for ; Thu, 08 Oct 2026 09:35:21 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a02718da81so20597715e9.1 for ; Thu, 08 Oct 2026 00:35: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-4a1843df445sm48642385e9.12.2026.10.08.00.35.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 00:35: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=1791444921; x=1792049721; 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=t6kPmwEer3ezcMtwe2rCD124a2D8iDGY92ujr4XdubA=; b=dRGmXorUgy9SSmfCXzM19iZEBMhii1bbXwKV+e/KAODkaJvuaJN4Zz6VkEL5mNKZVd dlQsAaRJud8wExPgBqOj3Uaxwv98KqcRDkWnTL64YcTvV/67rzrQQ3FNrEDK8AOYwgdf gphh86OQ97iVNKETL+JhrZi11V2SCDTiC0OizefpMGfuMkyDi2pAEe82xTz9o00uk+7I exPYIHXxYR1tJQ14vcOhFd/eITLy9TAxXpTyJIyXaFOT2MNF0UjVHteshuDTyjLjTC92 yRW+WajxUnsQo9yb259XWR2O39Parz2ayEKdNRziJEbUa3QEvj6Fp2nU9r5DdPEPj5fB xQPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791444921; x=1792049721; 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=t6kPmwEer3ezcMtwe2rCD124a2D8iDGY92ujr4XdubA=; b=RgCAaNyPWxDRXsErVbJrLNioY8mY813iWiKo29c0Co6KN6MVNKZNYN7ZsfEgh7rykR qySmtOopPquqvIWzvwhLE19xwrAk8gzQ1Y2eocOgJ7KePyjVkjsG7aQ6jtBcTj5XrY+a PZ5jHt/6OI4IpPZuFwDJy24vo8vLsf8+aBMF4NXtPgExoM1srIPCVStHP71TwCnT7y+D 3CJCXKZ2pmgdRkJUuTTS2/5HqanRXZOQe8MJaRvRlTQGVkJFclJQYi07ELJpgF/fxnqd npzv0WLDsLOOk03EN6IRiV+O8SostUHo8KMfTBsRs3Lvc7i1RY++Fahrd6Q+nHGUy0yv /aKw== X-Forwarded-Encrypted: i=1; AKwUvByzcbt3WMbEO05jf3I3Y+lcrRSzdgSdUABcySStuekWbcIf8xD1SQbGVSbXjPt8VeR/SRBodRxJj2I=@lists.xenproject.org X-Gm-Message-State: AFuF++nRIILawMBa6OEaYj94n7kAUBWySmwi6dm67HOih950DUnKxeha EeOMGL4jk8sqCCm3UxaLZiHXe4SSzH45F79lBs9GBtr9x0I/N/BeiHVsptOp5lx7lQ== X-Gm-Gg: AYBFou22U3uH8gEbBbCeuPk6QxBDCJiP8TiV1Pb2JrLGkBONss3Fcvfy/3Kfp05RiRv r5RZyJt89pd1wWKk0pB1Pys1yt03s3PLWoH+1V6ogWCWMvyNamxCghVw9vSipkswyHnoGrNVUJB 9+RVTegyMo6gp0kOetiHbQHWJHpZosC3TuFGqM7lltIkpNc4S6hp9xF7lxZkgKWULcdt0ydSqwY pAGxBRC5SFmeC+4q3j7yMYRAMUlIBhZzxXFM3z2rKIOSyRhVZGMAWJ/gNqr11hHkIu9ZZFMU0C9 RnDipSfq9dtW6pt5TDbCnpNMq8fjQ9DRpKWNc4nsgdecHtFY74mEwMzBvv9xbIChzJ+HMXltSYf vIyv5KKzhGZHt55OH2G5wADeybnRowdXNlN9TnjDIsHcONV+VWiYvgfWwWaWgQ17R20Ewut8aS1 e958AgAl+P2PACf05LppboDfMHiRTzBZ5np2g/ZCG1VXa0QMJJ1tfJF3uNWGowgZpAyICu4jODm 1oknpuYymmKLNSsW0oL1T43ob2SMjakBsERcV4AO0bwBzHNvfySpppOc+FrVKY= X-Received: by 2002:a05:600c:3b0a:b0:4a0:276e:9efb with SMTP id 5b1f17b1804b1-4a1800ca1dcmr78124545e9.4.1791444921159; Thu, 08 Oct 2026 00:35:21 -0700 (PDT) Message-ID: <2f41315f-b533-471e-9f88-57f6eae384ec@suse.com> Date: Thu, 8 Oct 2026 09:35:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] tools/symbols: fix oversized names and token expansion To: Mykola Kvach 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: 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/1791444921-A54C3AE4-4DC8D961/10/78276251493 X-purgate-type: spam X-purgate-size: 3303 On 07.10.2026 20:11, Mykola Kvach wrote: > Patch 1 fixes the first bug. In SYSV input, local symbols are prefixed > with the source file name ("filename#symbol"). A long absolute build > path can therefore create a name longer than 127 bytes, even when the > symbol itself is short. A debug Xen build on an Orange Pi 5 (RK3588S) > crashed during the boot self-tests: symbols_lookup_by_name() expanded > such a name into its 128-byte buffer and overwrote the saved frame > pointer and return address. The patch rejects retained names longer than > KSYM_NAME_LEN during the build and prints the offending name. > Readable --xensyms maps are not restricted. Nothing changes for names > of at most 127 bytes. > > A build from a long absolute source path can now fail at link time. This isn't acceptable imo. Omitting such a symbol is a far less severe action (see below for another option). As a more general remark: We've inherited this tool from Linux. Any issues we find want cross checking there. If fixed there, taking their change is often preferable over making our own. To cover overly long symbols names, they have a check in read_symbol(). As we add the filename for static symbols there as well, I don't see why we couldn't similarly have the check there. Furthermore, if the main issue is with long filenames, for static symbols an option would be to replace the filename prefix with some surrogate (either a shortened form of the path, or something like "...#"). Yet further, the problem of (long or not) absolute path names is to be solved differently anyway. Not just for reproducible builds we want to omit them altogether. There are two separate proposals [1], [2]; what's missing is a decision which way to go. (Both are pending a resubmission, yet perhaps not just me but also Marek is hesitant to do so when the decision which route to go is still pending.) > On x86, in-tree builds use relative paths and are not affected. An > out-of-tree build with the default config fails if the absolute path of > xen/ is longer than 78 bytes; the longest such name is > kexec_reloc.S#compatibility_mode. > > Patch 2 fixes the second bug. In the compressed stream, each symbol is > stored as [type][name]. A compression token can therefore expand to > the type byte plus a full 127-byte name (128 bytes), and write_src() > adds a terminating NUL. Its local buffer was 128 bytes, one byte too > small. The patch allocates KSYM_NAME_LEN + 2 bytes (type + name + > NUL). This bug can trigger with fully valid names, but only with a very > small symbol table; real symbol tables do not hit it. The new size > relies on the name limit from patch 1. Linux'es write_src() doesn't even add 1 to KSYM_NAME_LEN. The +1 there went away in 2.6.23, commit 9281acea6a36 ("kallsyms: make KSYM_NAME_LEN include space for trailing '\0'"). (Later KSYM_NAME_LEN was bumped to 512, btw.) Might we not want to follow that approach? (There then still looks to be an off-by-one due to the type that's being prefixed to all symbols. If that's indeed the case, a patch may want sending also for Linux.) Jan [1] https://lists.xen.org/archives/html/xen-devel/2025-09/msg00311.html [2] https://lists.xen.org/archives/html/xen-devel/2025-09/msg00362.html From xen-devel-bounces@lists.xenproject.org Thu Oct 08 07:47:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 07:47:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1442998.1660364 (Exim 4.92) (envelope-from ) id 1xEir5-0004lM-1i; Thu, 08 Oct 2026 07:47:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1442998.1660364; Thu, 08 Oct 2026 07:47: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 1xEir4-0004lF-VL; Thu, 08 Oct 2026 07:47:54 +0000 Received: by outflank-mailman (input) for mailman id 1442998; Thu, 08 Oct 2026 07:47:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEir3-0004l9-WD for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 07:47:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEir3-00G6VK-Cw for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:47:53 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac74a9e-8faa-0a2a0a5109dd-0a2a4502c620-24 for ; Thu, 08 Oct 2026 09:47:53 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac74aa9-6ca4-0a2a45020019-d155dd2ae01b-3 for ; Thu, 08 Oct 2026 09:47:53 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48b001cd92bso2566912f8f.2 for ; Thu, 08 Oct 2026 00:47: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-48c71bd7690sm9885060f8f.2.2026.10.08.00.47.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 00:47: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=1791445673; x=1792050473; 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=NKF73/Dub3v+IFx5x7L7MHvvzVbzfSk1n1lIrqsiZIU=; b=R6Fo0Mh3hrz2INFT5begX9cb4V6NygDbcF7SqRjMmBQKnn/TXPMhBFlmlvMMyrwnsK 0HJRSqq1we7Uxh7XAWufE0gwKRnriD3XQBU6e8WhCkSAtWRRnZ1wzoZMMnTH28rEdzQX n3ud9GflI4GKhwrnVxn+IX5rSCf7yveHHW7zimT6LomoqO1oj9Pn2WeDR3mC1uFWUV09 YWL3QZYNd7Dp4DlJvHPNd6gFLvkF8/KmoyXJIL++BLFHKky/UA2DN3Xp4JX/XgLH7pXJ 8iHqSCdVqro2QJM1z9nhD6MhYyTdylkJmA/VtCVOu/lilftxgkq4/tXeQ38nz1Ya8ZVl qIlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791445673; x=1792050473; 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=NKF73/Dub3v+IFx5x7L7MHvvzVbzfSk1n1lIrqsiZIU=; b=BJBP0qT7lHEB3yba099gqMCNfkDUekri2lOQ6ic8hpGJRgx2ZC+hq/jkmAc0sTZtOE ikOWAxKDTTHWkggcwZlKtXZa3X+P1c2eD4TDzTqbxSvprWhGwOpNaN1WVBnUyfiwg8A+ u8+sDS9Hc1FUcRbibWGj7VHB75htMl9pYDXB8vz7SOSA7XcnKiAr1MIp8qxAqDjTK8TO jBYlMzkSmzISOOcxzgMMT72vBwXU4fHfwa8HKi39Sp1OWCw25+Ipwb4uvXWutciDVmfG OXW9GydC3hAyhNwBigfAOw8sN8gOHB0nXkYKDl1Pw7IiQueAhvWo1d14NhbHyjAHP5ge rYyw== X-Forwarded-Encrypted: i=1; AKwUvBylGmgxiN/eXEco21e2KVON+JmHRCgQ0DQr45wjo/zf1mlx2CYBpBJMVeXAfjKqyDCa5u8mRRewgbE=@lists.xenproject.org X-Gm-Message-State: AFq9FYLza4b0HmdLcWhKExTlwDBs/r2aJpnd2pux/+vO8+yUZQVtjl+R tjTJVJvcpeZUl4PhPXtHRogRW8O8BpcmJ/OkpK4kEevdDdbJmvE/QPg7RWzX/YcOlQ== X-Gm-Gg: AYBFou0MsgbHjUcABq2x3dlLJqTC3pu3dAcrFunOy59pS33qDmm38FZ2biq8kIyuCYi oZo2uBqcWOvs15R/6j7O6eYIebGrYyBiabCPYyfixJqHGWN1V/7Jms4oXWKcWj0T/AzvBl1vmZK TYvfErDuey4aX+08VF9CwaYHJn9nS4wxod92QSSqZdzuVyoBfo/MHf70dtWwOuCym8ejyi1JMtt 8+n1OEMLju9Bsv/B/W4254+dXiWO0B3W5v3YAzbWjydupdA1lXjmUdc1ZfR0YmUqCRnfGbBSMF1 afrMKFvLA7BmmbFBlll8y75/WdLkTsje6uj7NhKH6yBmOohhVY/YGOlMqP1EURZs0c8RpBO54Dr myZH/IVGZbb36Vk7SQ3oQmVlj0BycAbIqKwDPK5XYdGkJVVyxBb7VXeslidF3u9eQ3DlERoUETK Yxp9zj5e8GxvqROILL+k531x7YHFo4cnVVQ/mVdkZlULbEw7bEI3kH+DeVAlZ7o1cx0Ymh7tuzm 8mtPRhGVa9okWGkmCMSmKKzSlMxb1FUJANRnXClMubYkzoWT3nMpeKq4lY4Nk4= X-Received: by 2002:a05:6000:29d5:b0:48b:948:c720 with SMTP id ffacd0b85a97d-48c7276a70fmr6191031f8f.11.1791445672573; Thu, 08 Oct 2026 00:47:52 -0700 (PDT) Message-ID: <499a8e0f-b3e3-44b0-91fb-128a0a952482@suse.com> Date: Thu, 8 Oct 2026 09:47:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] vPCI: resolve MISRA R10.1 boolean arithmetic type violation To: Dmytro Prokopchuk1 Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand , "xen-devel@lists.xenproject.org" References: <7549daf9e0de3420198913f6f91c16c929a31834.1791404375.git.dmytro_prokopchuk1@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: <7549daf9e0de3420198913f6f91c16c929a31834.1791404375.git.dmytro_prokopchuk1@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1791445673-317CA2AC-2427570D/10/78276251493 X-purgate-type: spam X-purgate-size: 651 On 07.10.2026 22:39, Dmytro Prokopchuk1 wrote: > MISRA C Rule 10.1 states: "Operands shall not be of an inappropriate > essential type". > > bar_write() and guest_mem_bar_write() added the boolean 'hi' to a > pointer difference when printing the ignored BAR index. These handlers > are registered only for the memory BAR registers, so print > (reg - PCI_BASE_ADDRESS_0) / 4 instead. The expression has type > unsigned int, so use %u. > > No functional changes. > > Suggested-by: Roger Pau Monné > Signed-off-by: Dmytro Prokopchuk Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 08 07:55:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 07:55:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443003.1660373 (Exim 4.92) (envelope-from ) id 1xEiyk-0006cV-PQ; Thu, 08 Oct 2026 07:55:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443003.1660373; Thu, 08 Oct 2026 07: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 1xEiyk-0006cM-Mh; Thu, 08 Oct 2026 07:55:50 +0000 Received: by outflank-mailman (input) for mailman id 1443003; Thu, 08 Oct 2026 07:55:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEiyk-0006cG-6U for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 07:55:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEiyi-00Ex35-Ns for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:55:48 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac74c82-bab6-0a2a0a5309dd-0a2a45018ca4-20 for ; Thu, 08 Oct 2026 09:55:48 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac74c84-5984-0a2a45010019-d155802ec813-3 for ; Thu, 08 Oct 2026 09:55:48 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4956869750eso15842425e9.2 for ; Thu, 08 Oct 2026 00:55: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-4a1814ce9a0sm106828745e9.3.2026.10.08.00.55.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 00:55: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=1791446148; x=1792050948; 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=aR8wWmpS7pUtclz8GpE0BatDzkEzQxBuP1Dw0ecl2N4=; b=geu0j54+iOLBa8deOdqeI0MPYV2Wgn077n8TbmvtdNnRL8xpHEEnSSQ3u9oSD0oYZg fLx+6SQaWjBmjmjZ88MGPvOwIZLg2wJzITkl7CGgYT2I84/DyKHEd920XxmQIsy5bP29 zp482ot5db58I6j9SoHPTUTvohJc+pRgn7lk5PYLrGYC6K3vhHwV7mAsw+OXk7HUyqJH 33sLG0NoMaNdqWpxcMZMBl9CM+OtoJEfXyJHMy2u211f0q1HRIRzb8e1FyB7OxbcPSw6 UNPebzryLr6qkmEeNbJ0zN9YWXcWmPRX+piTNcc0mKjztTkbM6XiHSvzJqHi/BynkFoC MhBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791446148; x=1792050948; 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=aR8wWmpS7pUtclz8GpE0BatDzkEzQxBuP1Dw0ecl2N4=; b=ecspj6TVAzkZ85HHchNev+aDzqqO++2WgE0OvOFpgmTYT7LEa/G3UjjpZFXLwg129S Lfy/EHpY/qr7rztZEEOLEi8KREKcHXNS+AXtjLSLnAP3RxlF5wfuLpB67uaIkiAvRLzQ Ed+beobjtyrwbOU2maL1KT4YRYV/ptNDHExuHYstZW4q8OnW89ZUSA5Gp0mhWH63IcGQ 0C0zmZww4tBd96JzIpRFOD/UKg7YEMxDQaHKlbz8oxnd7mTVbmwuUos4lhgp4iRyQqm1 o4fQbgXQI7v1LrmacLcioeH/EWxBLeFwt0XdDnt9eWw4nC6DZ6U8f3IAA0zgPsuGM8Yf AfKg== X-Forwarded-Encrypted: i=1; AKwUvBxU+GagcW7+GE5x52bOhd/Vz554vIIR+h0rQbp8cEtFcW7G+NT4H1srbaf0gckltEwdZSApJMRS44g=@lists.xenproject.org X-Gm-Message-State: AFuF++lJaQ/dcsU+ETK9IXhLH8Av1wvA3ElOht0VKh0EQVMkJD3QDWmc QA9fuRhK9Gn2YwUIxDFXs5VyIRQ7Onnx6F1JWJhmQ40Hqsd1rCsUD7aFidZAAsv9hg== X-Gm-Gg: AYBFou1FjJO8Htc4NN4yY+WM5eQsKQV0aUIQGar8ymxnwa/I51xpEnaRYzFhoN2K9OB AshGyUNjiX9QCm3UA2BCmPcDSaLgtHIgO6ksTYX9ZLCkNlIg9SLfaSC4+UqzE/gBxtZTLlDPqRE qlQUij6MGlatt0u9vd5U78pZc1aHe00ECEcVX49fv+qylHryRv5Lh+WBAT2vaIq73SwGW/f33kX N4faET6b88kwqpAxjxhMQV7netfnfPDx5pUklktFc7+urbBIGZdinyKrN88uBYnbXoXtUCYolxm +N7csnqwryda+1wV5huIDOMdQMn+gNEuR0gm3OvRef8iO/eBRN35hJdWxleg8jwGlL86z+jL8oG X7JBtKW8aWVgKmFbI5wfzcGR2zahtvXwsEnde5pBNDkjWfVgJd5rWGILa3OjzA24IOweisugQm7 ASUIHEuzu1UGv1xH7NncuW+gsKdZBhMcUow7tGsTWy7OxOvD3eyLh/RQ7ez0zS+SY6bfU8QnPSw q9+Eu0+TfSjGWkhS2g79VHhavMHwmxGg6Dj6OZ7p3Z9D4+YKOpb8sdm5LhCo0Y= X-Received: by 2002:a05:600c:470d:b0:4a0:1c17:4fb2 with SMTP id 5b1f17b1804b1-4a180648f8amr84783045e9.31.1791446148077; Thu, 08 Oct 2026 00:55:48 -0700 (PDT) Message-ID: <0149f2e4-e35c-4593-b2d2-0358913d353f@suse.com> Date: Thu, 8 Oct 2026 09:55:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 02/18] x86/mm: purge unneeded destroy_perdomain_mapping() To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-3-gwd@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: <20261007104051.48841-3-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1791446148-1D073757-0D921E9E/10/78276251493 X-purgate-type: spam X-purgate-size: 824 On 07.10.2026 12:40, George Dunlap wrote: > --- a/xen/arch/x86/x86_64/mm.c > +++ b/xen/arch/x86/x86_64/mm.c > @@ -737,6 +737,11 @@ int setup_compat_arg_xlat(struct vcpu *v) > NULL, NIL(struct page_info *)); > } > > +/* > + * Besides vCPU teardown, which free_perdomain_mappings() would cover, this > + * serves switch_compat()'s undo path: the domain lives on as a 64-bit one > + * there, so the translation area has to go right away. > + */ Is it really "has to"? The xlat area is simply unused for 64-bit guests, so it would be merely "needlessly occupying resources" if we deferred freeing until domain destruction. Preferably with a respective adjustment (and perhaps also the adjustment suggested by Roger): Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:05:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:05:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443022.1660382 (Exim 4.92) (envelope-from ) id 1xEj88-0000pN-1c; Thu, 08 Oct 2026 08:05:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443022.1660382; Thu, 08 Oct 2026 08: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 1xEj87-0000pG-VJ; Thu, 08 Oct 2026 08:05:31 +0000 Received: by outflank-mailman (input) for mailman id 1443022; Thu, 08 Oct 2026 08:05:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEj86-0000pA-Kk for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:05:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEj86-00ASNz-1G for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:05:30 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac74ec8-8faa-0a2a0a5109dd-0a2a450bca38-8 for ; Thu, 08 Oct 2026 10:05:29 +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 6ac74ec9-b7e8-0a2a450b0019-d155dd2fb96b-3 for ; Thu, 08 Oct 2026 10:05:29 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-487048857f6so2273752f8f.3 for ; Thu, 08 Oct 2026 01:05: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-48c71c0b604sm10153971f8f.13.2026.10.08.01.05.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 01: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=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=1791446729; x=1792051529; 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=mT/WMTwC9Pntbn7PkhRaBjdPQb+5Cm86/PMMKaL6YGw=; b=QQ/EFpcl99zbW1885RelSZx7r4o3nnjfNkL9WKNgH91dWVmoTNnAVXeSBV7vpKtjcO hsy9MjJ4XfBTk4i7bLIqVWY3u8974wLo0qbRuzUZAiw08uy8X5CUEdJ+fF7QShb9X+IV 6c6ieBzUOFiXjUsr5V/ti7fE3+yR3uof8dmxzUHPg1k39VGaiFV2WoeSPAf7K/8ZP7YJ 3FzssjlhKY77yh+ROqnmqlxxNtRhL3OAPxMvc0iVZBu4Fetd9vTT9HYemQ/Q8KXf3Ted C1IDQzvbE+kL69ZEbnyvFoPh3JWnguUrc8pLEVRtT3ffhAzqMWo5LfQlwr7crb8l5nJr Wxpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791446729; x=1792051529; 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=mT/WMTwC9Pntbn7PkhRaBjdPQb+5Cm86/PMMKaL6YGw=; b=XzM/X5eV+gg3NSYYPxGDMsKnZae9ia3Z2Gbe+GYqvmDjcNzBoU7cvfCs/goD6qySuB oBXgwFJ0bPls+1prcENWp6QvnWM9KLI7CeWmBW8AAgsuwU3KWzwkG0AtbVo12uwkhWyw JrQiy92oD3TjfWhwTYJVVgTOphPw5yOIKT382jVRZOuAJXiAm9alYFKYr71v6Wfl17I6 wQr+8bFgv1H5ydR9+TzGepplgqq3oVVee7sAiXilKEB30heMNVzlsrfP2dde45VwSAV7 x35dMhtlB2VvnpL3DV3181EcmwdaPljG4ov/XLvL0+E1zfsuGFftzoZupwTK+UavnEIG MM6g== X-Forwarded-Encrypted: i=1; AKwUvBx+BYHSzv4Kl9Qlg+aKh0A7sfFGJaaM4BEsdz1x/Ys0Yag0jfxwPx269DAKlNUVQx3gw5zuM1FFrUA=@lists.xenproject.org X-Gm-Message-State: AFq9FYIkH8CAETrhXUByxM3kHbCcxZvxvAMtXMY+mfVlfz1kkqlL//Qa aKCjyLOmtY1kYdLpbL6er7EPwFGeeuhmGHZdJSIHN7TxXpxQMBPM87dhVQfcJT6LzmYQclOftNI GHYd+IA== X-Gm-Gg: AYBFou12DXQkHxtsHNz1deR//MouWe0Rt1UUCUNm7QRXPTZhdORJqG3spn02Hc4JYuo 57/jwuBz8shcPzFDM/R8rHAXQHnzoi8EW9Cp/T9aXuxlzFTV/IvuJfYSxB4BMHe8d37KIR/ljP6 QZIUtINFwlXlHruX/rWtqhYepJKSthEJsubL9rActg+YtNnHpuHvpCZKmjX32b+jCU+CGzy2gho nITAJcl7zJqCAg55aqg27SMbbRgViJDGBofnHUcIcDJpdizPloI78vgsCibagGouzsS+j6LUh6P ZkgRP91EGCYF/YCZBhCE2MAvn+Faq33IvXsRoYNhNMF3GrnAgP8U4/T3Fo2gRu/PIxBdZIcVemE PqDMPsYizksiNX3NqRgT2qDURb+ggvIuMxnh94b5j/Ty9e0gWE3UkxCcWFjj49kRSbWum5ldXsC HfdopD/fT0RIGLyPNLQpr9KNN9soQm2eiKZu2dFn6Y8A/svxEeeBl8XqM8DxrEvvTyPtd4GHXzO O3pknQzBhvfe0XSRSnMSWdM1zVtyBDYktqQHGT0dNyI8GY2waak4Xdmdi8+0ufxzVuGwnIZkg== X-Received: by 2002:a05:6000:38f:b0:48a:fb6e:bc50 with SMTP id ffacd0b85a97d-48c727891c3mr8801688f8f.27.1791446729056; Thu, 08 Oct 2026 01:05:29 -0700 (PDT) Message-ID: <4042778c-8648-44a6-9b9a-eeec138b1d58@suse.com> Date: Thu, 8 Oct 2026 10:05:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 05/18] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-6-gwd@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: <20261007104051.48841-6-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1791446729-19CC79EA-EE02236E/10/78276251493 X-purgate-type: spam X-purgate-size: 2820 On 07.10.2026 12:40, 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 > 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 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, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap Preferably with Roger's suggested comment adjustment: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:22:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:22:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443030.1660397 (Exim 4.92) (envelope-from ) id 1xEjOD-0004Sb-HL; Thu, 08 Oct 2026 08:22:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443030.1660397; Thu, 08 Oct 2026 08: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 1xEjOD-0004SU-DI; Thu, 08 Oct 2026 08:22:09 +0000 Received: by outflank-mailman (input) for mailman id 1443030; Thu, 08 Oct 2026 08:22:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEjOC-0004SO-5i for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:22:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEjOB-0038NC-2P; Thu, 08 Oct 2026 08:22: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 1xEjOB-008mUs-1K; Thu, 08 Oct 2026 08:22: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=m0WYskPCFlkJyiVXeKFrGkSQjXbrscz83PSiADfB2HU=; b=dJEaV1RxLJ4DRYQoC4GQY/imfY lgvIczt1fb9KeoETB/oESMGqm82RAAlAoRKLlFiRtY2S6tj7T2Q0Dx+vCE+2jBhbxkRFRsaTvHSTO TpcqrKC3HHswInbVlVqvSWaEzXu/7Lr8o8ia/Bzvh22xry73XxC58KLHrsVB7it2TjJE=; Date: Thu, 8 Oct 2026 10:22:01 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-9-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:41AM +0100, George Dunlap wrote: > From: Roger Pau Monné > > Currently, only PV domains have a mapcache, which is domain-wide one. > In preparation for enabling per-vCPU mapcaches for HVM domains, split > the accounting out into a struct mapcache, embedded in struct > mapcache_domain. > > Introduce has_mapcache(), for whether a vCPU has a mapcache, and > vcpu_mapcache(), which returns the accounting for a vCPU's mapcache > and, in *dcache, the domain-wide mapcache whose lock and TLB epoch the > caller has to take into account. For now has_mapcache() is > is_pv_vcpu(), and vcpu_mapcache() always returns the domain's > accounting. map_domain_page() and unmap_domain_page() stop repeating > the is_pv_vcpu() check mapcache_current_vcpu() has made. > > Move map_domain_page()'s handling of the domain-wide lock and TLB epoch > into three helpers: mapcache_lock() takes the lock and catches up with > a wrap another vCPU caused, mapcache_new_epoch() starts a new epoch > after a wrap, and mapcache_unlock() drops the lock. A per-vCPU > mapcache can then skip them without map_domain_page() being > re-indented. > > struct mapcache_domain keeps its size (40 bytes, x86_64 debug build), > and so do the structures containing it. > > No functional change. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - New in this version, split out of "x86/hvm: introduce per-vCPU > mapcache for vCPU-PT domains" for review. > --- > xen/arch/x86/domain_page.c | 155 ++++++++++++++++++++---------- > xen/arch/x86/include/asm/domain.h | 19 ++-- > 2 files changed, 116 insertions(+), 58 deletions(-) > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > index 9119f735f5..5d90f77bed 100644 > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -18,17 +18,23 @@ > #include > #include > > +/* > + * Whether v has a mapcache: PV vCPUs (whose domain-wide mapcache may still be > + * disabled, see mapcache_domain_init()). HVM vCPUs reach everything through > + * the directmap, which covers all physical address space for them. I've been wondering whether there could be a way to write this comment so that it doesn't need rewording once we switch to per-vCPU mapcaches, as to avoid adding a comment here that will very likely be completely re-worded by a later change in the series. However I cannot find anything much better rather than stripping most of the comment content. > + */ > +static bool has_mapcache(const struct vcpu *v) > +{ > + return is_pv_vcpu(v); > +} > + > static inline struct vcpu *mapcache_current_vcpu(void) > { > struct vcpu *v = this_cpu(pgtable_vcpu); > struct vcpu *curr = current; > > - /* > - * During early boot pgtable_vcpu is not set, callers must handle NULL. > - * Non-PV domains don't have a mapcache, the directmap covers all physical > - * address space. > - */ > - if ( !v || !is_pv_vcpu(v) ) > + /* During early boot pgtable_vcpu is not set, callers must handle NULL. */ > + if ( !v || !has_mapcache(v) ) > return NULL; > > /* > @@ -54,6 +60,55 @@ static inline struct vcpu *mapcache_current_vcpu(void) > return ACCESS_ONCE(this_cpu(pgtable_vcpu)); > } > > +/* > + * The accounting for v's mapcache: the domain's, with *dcache set so the > + * caller takes the domain-wide lock and TLB-epoch machinery into account. > + */ > +static struct mapcache *vcpu_mapcache(struct vcpu *v, > + struct mapcache_domain **dcache) > +{ > + struct domain *d = v->domain; > + > + *dcache = &d->arch.pv.mapcache; > + return &(*dcache)->cache; > +} > + > +/* > + * The domain-wide mapcache's lock and TLB-epoch machinery, taken around > + * allocating a slot: the domain's vCPUs share the mapcache's slots, and each > + * catches up with a wrap another one caused, flushing its TLB if it has not > + * been flushed since. Thinking forward about how this function will end up looking when we have per-vCPU map caches, do you maybe want to place this comment inside the function body itself? I expect per-vCPU splitting will add a short-circuit at the top of the function that will skip taking the lock or doing the flushing, and hence the comment won't need shuffling around? > + */ > +static void mapcache_lock(struct mapcache_domain *dcache, Maybe mapcache_enter() would be a better suited name once there's no longer a need to take a lock for the mapcache? Just wondering, no strong opinion really (the more that I don't even know how the code will end up looking yet). > + struct mapcache_vcpu *vcache) > +{ > + spin_lock(&dcache->lock); > + > + /* Has some other CPU caused a wrap? We must flush if so. */ > + if ( unlikely(dcache->epoch != vcache->shadow_epoch) ) > + { > + vcache->shadow_epoch = dcache->epoch; > + if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) ) > + { > + perfc_incr(domain_page_tlb_flush); > + flush_tlb_local(); > + } > + } > +} > + > +/* A wrap has just flushed this CPU's TLB: start a new epoch. */ > +static void mapcache_new_epoch(struct mapcache_domain *dcache, > + struct mapcache_vcpu *vcache) > +{ Since this is now a function on its own, I would possibly assert that dcache->lock is taken on entry. Let me know what you think of the suggestions above, overall I think the logic is fine. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:24:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:24:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443035.1660404 (Exim 4.92) (envelope-from ) id 1xEjQm-00052k-Sa; Thu, 08 Oct 2026 08:24:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443035.1660404; Thu, 08 Oct 2026 08:24: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 1xEjQm-00052d-Ph; Thu, 08 Oct 2026 08:24:48 +0000 Received: by outflank-mailman (input) for mailman id 1443035; Thu, 08 Oct 2026 08:24:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEjQm-00052X-52 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:24:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEjQl-002ke0-8J for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:24:47 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7534f-2eae-0a2a0a5409dd-0a2a4505bde4-0 for ; Thu, 08 Oct 2026 10:24:47 +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 6ac7534e-4cb1-0a2a45050019-d155dd36b4ae-3 for ; Thu, 08 Oct 2026 10:24:47 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48af27fe287so1999867f8f.0 for ; Thu, 08 Oct 2026 01:24: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-48c724b660fsm9450462f8f.18.2026.10.08.01.24.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 01:24: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=1791447886; x=1792052686; 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=omuwir6pvuXtLUY7GTNBQtV9k9Tm1hms0wnsm7RbXJg=; b=AUMJ2hLN27jOCnJGBuAB731VbVX0RCG+nR9SKjpvtF39wcEITkWkqGa5MKG6fHWJol OZ2wgG+KcvauA08+9XoJ/d7HuFCBm/IS9bgzAvECmzErg76Yhwb6rgaY0zNT6XJj+tqb g560csIPmrpcbVagBTuBrylog13q6Px41ZPvO28ZmFyflOtVvRE3f4CShpjTsrFo8wGN I5j7VcjcNOZLL3nfjtZ+K2BsIh39kv/++ygz8IkZA41IvwPZN+lKpLN2ncGVopql9xEx 1jPBrNfA7kSSnhMtZSWygdoMJyx74naYTr+uK+iKi4drjrA5C3Q2YaWRTDOKRT4l20X2 Hp8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791447886; x=1792052686; 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=omuwir6pvuXtLUY7GTNBQtV9k9Tm1hms0wnsm7RbXJg=; b=wdexmZo5jZzCRlpBwHYZU46BzFa65GLrzOdYsL04DzOnx9vZ4U2//wKx/2YGpiZWYL nDNMx/iwOjNqWvtLVEYmMlvtJu1la2hOpP3dV6/fxgbiULe2Ab3lSuhs0oOioBUvy902 VwHHvYZX71MpJH4sVbNXUUXO9sKeFVDkTLtzFBsr/hJ2XkTB2uovIs2erlJDclucmNuX JjSjlGc0fUu7XuhXoZKOUS7clyvi+CVTWhxjiHf9SFzl3MGgLXeu0lbeLvZM/VniTpKr TwVPJ+Fw+qUqojeqWuhtEWm2VNBH2bEPoD1beSzOw/owxy+uImcBtBs1v2U6WX0XIPyH /Tcw== X-Forwarded-Encrypted: i=1; AKwUvBxT2VCLGVgkUTerIfFy80PC/u2X3HTRrARBQVIZsN1FgYBmdf6/We+miUA3AvZDDRD11b1+1lV9EIY=@lists.xenproject.org X-Gm-Message-State: AFq9FYI2MwpVlRDxssSPEVBZv4qr4PGa4JWfhS82284VMJVligF7Tk7o cglxZ/AuyNTJ9O2ZqUDt27Zn9LlF9NznTfj4ofZBLc9yHb6vnBjnLo1q/St+hbYvQg== X-Gm-Gg: AYBFou1DnFTZMWFIWuaGvOUMVt/wOCpbi4SPkVEcRXi5EtmvX1Dc2R/O+/hiTB+fMKt HT8N1HgULBwNZ5r2VIYgXJ8MG06hUXy6Mt4fsnDJvjXYwhGrifJ56E0NHqCP6F/A56A5QASwPQl PsRS3GLWndL80YkTht8WDPUBXi6Gk03Cuu046JsbuJTII3JhnCCtdoyVDlp3+on1UZyqF0bdjah JcASHxLGXXxc3KrvN1BE9in5ZCiIoIOxIuH5O00p/zP7e7aquM9OkODxurjr9qITPVR91ZxlLzp q5r55IHETy7/0wozwV/2FvHA6yiAbe52JAmm8ETYQPJmV7QTEyb+kZfzDyhozg2aGfG4+07wRNC Vp+F2nNhR0vyf95prya3RN0J6kVlCEAY8uJs9GMEZm3Ed+58WwKs7Dbfc2iiaKPr7knJgdb4Lvq /B4l3qa/90eEAPuxHMETKu+xaZhiR4gQFVRWQ5MDB4PWeC71YetwGZDxfPoGwFASuV1uYBLR5qC mJ5ND6p3jLXynEj9QlTpzdXT1sO1PgEneNx0obm1ctys82k9K2kQRg115QTMfc= X-Received: by 2002:a05:6000:2002:b0:487:88b:4681 with SMTP id ffacd0b85a97d-48c7277925bmr8655375f8f.10.1791447886463; Thu, 08 Oct 2026 01:24:46 -0700 (PDT) Message-ID: <3441a775-7081-43cf-aed9-56d51658c32e@suse.com> Date: Thu, 8 Oct 2026 10:24:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 06/18] x86/spec-ctrl: introduce Address Space Isolation command line option To: George Dunlap Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Teddy Astie , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-7-gwd@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: <20261007104051.48841-7-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791447887-71CA82A1-2AC0B57D/10/78276251493 X-purgate-type: spam X-purgate-size: 2555 On 07.10.2026 12:40, George Dunlap wrote: > --- a/xen/arch/x86/spec_ctrl.c > +++ b/xen/arch/x86/spec_ctrl.c > @@ -86,6 +86,13 @@ bool __ro_after_init opt_bp_spec_reduce = true; > > static bool __initdata opt_ibpb_alt; > > +/* > + * Give each vCPU of an HVM domain its own per-domain area (vCPU-PT). Off by > + * default until the feature is complete. > + */ > +bool __ro_after_init opt_vcpu_pt_hvm; > +bool __ro_after_init opt_vcpu_pt_hwdom; I'm a little worried of this name, which doesn't distinguish PV and PVH. Yes, the variable name is already long-ish, yet I think inserting "pvh" is going to help. > @@ -487,6 +494,62 @@ 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_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_hwdom = opt_vcpu_pt_hvm = val; > + break; > + > + default: > + 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_hwdom = opt_vcpu_pt_hvm = val; > + break; > + > + case -2: > + s += strlen("vcpu-pt="); > + if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) > + opt_vcpu_pt_hvm = val; > + else > + default: > + rc = -EINVAL; > + break; While personally I like the reduced redundancy from placing case labels like the default: one here, Misra rule 16.2 wants us to not use such. Note that as written there's no violation, yet iirc Andrew keeps asking for figure braces in such constructs. I think we're better off not introducing new instances (the rule is marked clean, so with the braces added we simply can't, unless the file is excluded from scanning). Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:28:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:28:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443041.1660413 (Exim 4.92) (envelope-from ) id 1xEjUE-0005l9-9q; Thu, 08 Oct 2026 08:28:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443041.1660413; Thu, 08 Oct 2026 08:28: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 1xEjUE-0005l2-7I; Thu, 08 Oct 2026 08:28:22 +0000 Received: by outflank-mailman (input) for mailman id 1443041; Thu, 08 Oct 2026 08:28:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEjUC-0005kw-JP for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:28:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEjUB-0038TD-3B; Thu, 08 Oct 2026 08:28: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 1xEjUB-008osB-28; Thu, 08 Oct 2026 08:28: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=1gzvQ8LcEHJFYChCtYeQP4UMM+HW0KR67yYs09uWdNU=; b=YOO343ujn4DDgtL3YrTfLUxUfz eNiL2LSZL/J3TlgTv9ucWIK993bsSMhtrP1Q0SF020d3BS8/p7+PzNsIaNPZGWp4xWp3SP6ca9LdC GU5bQ7GK0cacSzh3zYa0TfZs/PilQ4WpLBMK+LXiwTxC057xRd8xhumPT7jagAxJ/LBw=; Date: Thu, 8 Oct 2026 10:28:17 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 09/18] x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-10-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-10-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:42AM +0100, George Dunlap wrote: > From: Roger Pau Monné > > struct mapcache_vcpu, the per-vCPU part of the mapcache (the maphash > and the vCPU's shadow of the domain's TLB epoch), lives in struct > pv_vcpu, as only PV vCPUs have a mapcache. In preparation for > implementing mapcaches for HVM domains, move it to struct arch_vcpu: > v->arch.pv.mapcache becomes v->arch.mapcache. > > struct pv_vcpu shrinks from 512 to 376 bytes, and struct vcpu grows > from 2880 to 3008 bytes (x86_64, debug build), within its page: from > here on HVM vCPUs carry the 136-byte struct mapcache_vcpu too, ahead of > its use by those of vCPU-PT domains. > > No functional change. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné > --- > Changes in v3: > - New in this version, split out of "x86/hvm: introduce per-vCPU > mapcache for vCPU-PT domains" for review. > --- > xen/arch/x86/domain_page.c | 6 +++--- > xen/arch/x86/include/asm/domain.h | 6 +++--- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > index 5d90f77bed..f91ec8a75a 100644 > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -134,7 +134,7 @@ void *map_domain_page(mfn_t mfn) > return mfn_to_virt(mfn_x(mfn)); > > cache = vcpu_mapcache(v, &dcache); > - vcache = &v->arch.pv.mapcache; > + vcache = &v->arch.mapcache; > if ( !cache->inuse ) > return mfn_to_virt(mfn_x(mfn)); > > @@ -231,7 +231,7 @@ void unmap_domain_page(const void *ptr) > > idx = PFN_DOWN(va - MAPCACHE_VIRT_START); > mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); > - hashent = &v->arch.pv.mapcache.hash[MAPHASH_HASHFN(mfn)]; > + hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)]; > > local_irq_save(flags); > > @@ -334,7 +334,7 @@ int mapcache_vcpu_init(struct vcpu *v) > BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES); > for ( i = 0; i < MAPHASH_ENTRIES; i++ ) > { > - struct vcpu_maphash_entry *hashent = &v->arch.pv.mapcache.hash[i]; > + struct vcpu_maphash_entry *hashent = &v->arch.mapcache.hash[i]; > > hashent->mfn = ~0UL; /* never valid to map */ > hashent->idx = MAPHASHENT_NOTINUSE; > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h > index 6f5873879e..cfa24c4e75 100644 > --- a/xen/arch/x86/include/asm/domain.h > +++ b/xen/arch/x86/include/asm/domain.h > @@ -552,9 +552,6 @@ struct arch_domain > > struct pv_vcpu > { > - /* map_domain_page() mapping cache. */ > - struct mapcache_vcpu mapcache; > - > unsigned int vgc_flags; > > struct trap_info *trap_ctxt; > @@ -650,6 +647,9 @@ struct arch_vcpu > #define async_exception_state(t) async_exception_state[(t)-1] > uint8_t async_exception_mask; > > + /* map_domain_page() mapping cache. */ > + struct mapcache_vcpu mapcache; FWIW, I would maybe place this at the top of the structure, like it was placed in pv_vcpu? In any case the placement of the fields of arch_vcpu is a mess already, so it doesn't make much of a difference. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:31:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:31:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443047.1660423 (Exim 4.92) (envelope-from ) id 1xEjWv-0007Oo-ME; Thu, 08 Oct 2026 08:31:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443047.1660423; Thu, 08 Oct 2026 08:31: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 1xEjWv-0007Oh-JR; Thu, 08 Oct 2026 08:31:09 +0000 Received: by outflank-mailman (input) for mailman id 1443047; Thu, 08 Oct 2026 08:31:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEjWu-0007Oa-PO for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:31:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEjWr-0038XL-0o; Thu, 08 Oct 2026 08:31: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 1xEjWq-008pcY-31; Thu, 08 Oct 2026 08:31: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=+Zfd5bWUL6y9OaDmX7F2SX+mtHZ1F7rKvNIwuDLzKP8=; b=sjjMMm8zylE5QNyFr8hzUO4Yvw qXJf1v6GMyrYJZe14XTlmTHzyyBAzcghY2Yl44v/8ZOFN0hGLeBVJu2Smr9ZAs0wR6NDSuLY7OruB NKRXnxgiQ/3v8eBu8W4vtgmU8e5y46oWosugoiIYhzFQWgr1mDUT/DogRCqPwk65CSiM=; Date: Thu, 8 Oct 2026 10:31:02 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: George Dunlap , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 02/18] x86/mm: purge unneeded destroy_perdomain_mapping() Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-3-gwd@xenproject.org> <0149f2e4-e35c-4593-b2d2-0358913d353f@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0149f2e4-e35c-4593-b2d2-0358913d353f@suse.com> On Thu, Oct 08, 2026 at 09:55:46AM +0200, Jan Beulich wrote: > On 07.10.2026 12:40, George Dunlap wrote: > > --- a/xen/arch/x86/x86_64/mm.c > > +++ b/xen/arch/x86/x86_64/mm.c > > @@ -737,6 +737,11 @@ int setup_compat_arg_xlat(struct vcpu *v) > > NULL, NIL(struct page_info *)); > > } > > > > +/* > > + * Besides vCPU teardown, which free_perdomain_mappings() would cover, this > > + * serves switch_compat()'s undo path: the domain lives on as a 64-bit one > > + * there, so the translation area has to go right away. > > + */ > > Is it really "has to"? The xlat area is simply unused for 64-bit guests, > so it would be merely "needlessly occupying resources" if we deferred > freeing until domain destruction. I wondered the same, but pv_vcpu_destroy() won't free the xlat are if is_pv_32bit_vcpu() returns false, which would be the case if switch_compat() fails. All this could be adjusted, but it seemed more churn than benefit. Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:40:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:40:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443054.1660432 (Exim 4.92) (envelope-from ) id 1xEjgJ-00010p-GJ; Thu, 08 Oct 2026 08:40:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443054.1660432; Thu, 08 Oct 2026 08: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 1xEjgJ-00010i-Dh; Thu, 08 Oct 2026 08:40:51 +0000 Received: by outflank-mailman (input) for mailman id 1443054; Thu, 08 Oct 2026 08:40:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEjgI-00010c-0f for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:40:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEjgH-00Ab0I-DZ for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:40:49 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac75707-8faa-0a2a0a5109dd-0a2a4507cb80-32 for ; Thu, 08 Oct 2026 10:40:49 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac75710-b4ea-0a2a45070019-d155dd2ac8fc-3 for ; Thu, 08 Oct 2026 10:40:48 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48c4d870d54so1771051f8f.2 for ; Thu, 08 Oct 2026 01:40: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-48c75b4e399sm8936643f8f.56.2026.10.08.01.40.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 01:40: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=1791448848; x=1792053648; 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=4vMvz8pjS1xywNZLHwQXBMAQcuHHZcZfe8Xkd/FjYQk=; b=Dr3O2QAsER61ogBpvkDiw/YiUWkpGduOlzbbsVrdc5UFYo3a9xMsNCXnKZQ8T0vp+Y 3Vrifek4EDdIBP2bG/VTd80laHfx6z09HykiNx3Gmd51LHJIfvnfGgrlOVVSab3SJjX6 ghLyCWtQ2phv0UxXFKxRl1Cm0Ci4wiILOYm7ZPuK1fyiEkXSxHw3b2LF/kpfi5vjTgtk wPgON7HLMDtEU1rwup6ajuwnoynEds5dZ5GzlGgY/BCIgJ+oajT9iIlqZdDoC85JBwHN BJjEyMjHlAriJY4JI7gFdTXl7MXn0TSUkBy0AEB0GMUDeSh0kjDxFhzA3zAhju6SYU+G JvAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791448848; x=1792053648; 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=4vMvz8pjS1xywNZLHwQXBMAQcuHHZcZfe8Xkd/FjYQk=; b=SWY00Aj3kLNLG8BdLl94wAmtcpV3dd9rDdfU9Oww3cuBjK4JCOE/NQeXeQrNr7eMyy 6LuqZLXa9uT9I/ZLtUxKa8SZCNhAakyzJMhadd6iwqH4XjuYbOTdWP92K0KFCengSTmI PANF8O/qqdey9ZEsp2sFVMbzDfDn9ylcjrkh1BUa69yIeE8MFHPz3qWkhl1EYRYUPN3R CXQbN3wSCfzX6SGeF/4b/anw0cSklKffRyKXshEbzaxNwg4wD3pdirqoodTBEpr8/yi6 7OrH6dZXqlQrOIeuypu4rXpptvj3auIdkrSQmRPlvTXNJC+z3PUzjsg94c8kFwUs/zDp SZBw== X-Forwarded-Encrypted: i=1; AKwUvBzoslxl6gW511rU+rXk+th3OC8OtKe0JoYWW9pYkDe+TnUE0lgTK7BtjZqDtOZeP58Tltizp3HfE1c=@lists.xenproject.org X-Gm-Message-State: AFq9FYJWG1sDejfoUvgEYwUN5yRiNHJ3J6fzp2+fHIL2BeR6Z4q8Udb9 SOOy0GuJ17kySQl6NC2dqmYfZ9LtXtGE0QqlEEtlSjlFhs8SJt4SkezX7Gziv610Dg== X-Gm-Gg: AYBFou3KQ6i7/fNJYc8z3Rzg3VUU5bqO4c6LqBm9Ilnywf3Z+1zF5qBYi0PPul/WR3P YH4PzOUaVqc4VjTF/uV0YAx0QCl7BH62r94ATw5Ve9gj0xr41DvYEftcRItOWp5gz+FIP8TnT8i NfRUU/IOBQzMfvgFCSnA427okUCqlrUzPQqGDjDB3mMWz+Qcy9cXAQMbOzLWfpH89PLv9KOLsIs geDDcNEtn1Vdt3jdal0xDdzfbPkC6OztKqmF8PD0PGxyUKyjoFfmqHzHkWsQmLLAomKPP1ZbKlw Z8F4LB7RthtbTmD6eh0nxVK+flMRFPuY95kAQQRV4r/p0VgK1500OpBVHxxv+fj1GGb3Jtg9ByI oiTFhhpfJSvhyVH37G3VWaUCLCfl4D4hoRsaB//ldM9/t8NOrAnERgOe0g3B8uB7g0JYQK7UCUr zT4xxlF+6qb2GGgv+eh1KOeT+riG/mt2B1T9PXTbQHx5OEzNt2LTGMLPk6sm9J7RhYgqrru3LVI Cff8UOhUVtQL4IBmja38NllSij5KnYExTwGaJH4/i6qUdL2kjncbhfvdogPhQ== X-Received: by 2002:a05:6000:1846:b0:48b:d17:139c with SMTP id ffacd0b85a97d-48c728858b5mr9256437f8f.51.1791448848142; Thu, 08 Oct 2026 01:40:48 -0700 (PDT) Message-ID: <7bced27f-5391-4120-b9cf-b97bb88758ca@suse.com> Date: Thu, 8 Oct 2026 10:40:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 07/18] x86/hvm: introduce per-vCPU L3 page-table To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Tim Deegan , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-8-gwd@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: <20261007104051.48841-8-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791448848-368D9AE4-E0DF25F5/10/78276251493 X-purgate-type: spam X-purgate-size: 1078 On 07.10.2026 12:40, George Dunlap wrote: > @@ -1835,7 +1853,7 @@ static int promote_l4_table(struct page_info *page) > if ( !rc ) > { > init_xen_l4_slots(pl4e, l4mfn, > - d, INVALID_MFN, VM_ASSIST(d, m2p_strict)); > + d, NULL, INVALID_MFN, VM_ASSIST(d, m2p_strict)); Nit: Take the opportunity and re-flow the statement (i.e. move more args onto the 1st line)? > --- 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->domain, v, INVALID_MFN, false); This being PV-only code, don't you want to pass NULL here? The description talks about this, but (a) it's not quite clear why PV32 would want handling differently from PV64 at this point and (b) in sh_make_shadow() you do pass NULL unconditionally. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:47:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:47:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443059.1660440 (Exim 4.92) (envelope-from ) id 1xEjmZ-0001gH-8K; Thu, 08 Oct 2026 08:47:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443059.1660440; Thu, 08 Oct 2026 08:47: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 1xEjmZ-0001gA-5Y; Thu, 08 Oct 2026 08:47:19 +0000 Received: by outflank-mailman (input) for mailman id 1443059; Thu, 08 Oct 2026 08:47:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEjmX-0001g4-VR for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:47:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEjmW-000MjN-NP for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:47:16 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7588c-2eae-0a2a0a5409dd-0a2a450bd148-28 for ; Thu, 08 Oct 2026 10:47:13 +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 6ac75891-b7e8-0a2a450b0019-d155802acc0f-3 for ; Thu, 08 Oct 2026 10:47:13 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a168355946so24938525e9.0 for ; Thu, 08 Oct 2026 01:47: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-4a1843cb256sm49360005e9.5.2026.10.08.01.47.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 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=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=1791449233; x=1792054033; 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=aFTz6/ey6PBFnkyw1RG2MwqdUAInL3A+nwIFvu9l3GU=; b=REfM6hR1f6IXCU6B8GiCXHSU9S1FkcYrafwUZHEYLvJGs7C1s1MBctFDAluO7fVUjx MG5VKAaww9UFZe7P3Bv7XwZZg6tlGsgFBYg/G8j7wW8M1xaCksc7nKIavFav0LPNVddo AVJ/rEH2VWj8qiUB2/dhTfYJSA+pyzo35h7v9Hv56V1qHygTiWxp98GbZv0/17XXby+y 8CH6dfIlXRRvfdnntsAJVhGLoX2Q5I0slwe09GoULMDepW325jbPJBbWQdtXFFVPGNIG OaGg4to+p/sw3KZU0UEo3PRj19oDqdIeLPmN6N9J8b8iQhgDIAH8GDFOst8H9LkLOFqq CU6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791449233; x=1792054033; 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=aFTz6/ey6PBFnkyw1RG2MwqdUAInL3A+nwIFvu9l3GU=; b=mkTte3O+HF5HLy5jsLPGot6+JdQmzMfuq8HZ4c7MW9ze7vhclEDrP8vDp4d40n1tRx 6jRRbgUTcMXIO7Byj6NiKPQuATWqUweO/t9LTX43+oyU5oHBx/JmiJAfirpazZ25jnr7 Q6gd5z6OOX7/tCn34jWR5bo/pmGvvEzDz8xFE7yXwiu603Ny+/ay66bEArBxn+lIm4dL OxFE2bb2BEvry0RULntic71cga+Eu5JsyxegstD0gu2dTaNvWZ7CJA+w+QSGDxCmKYhp eD8TltrfR+RL5aYN9jCTo5Z5fCAEpCDtGi8gmF/9URc0BlLoTaVuWLrr7YaqycjFk2N7 4inQ== X-Forwarded-Encrypted: i=1; AKwUvBwWR4lPEWonIkP6E/cyms2URRWzKtF8TCSV8LS6Rff3u+9tNe8fyRfQB8/2iaz7ZLpZjH2Qv9caQps=@lists.xenproject.org X-Gm-Message-State: AFuF++m2hWo5rQ6D9slvks72rDZnbRMHxr8Cav9gIEDPVR/6BU5ZEL8D UAp9Iy82PL+jTxHlozhfOwx3QNUdfCzmxGaVdSY2f4Jat0aTXO2d3HKkUkRLLPh1WA== X-Gm-Gg: AYBFou3fD2z5prfNm3kztIiByNwzTYWplstWt3RPDDYh9XqtvPBHsrDw0AEtoEgyKOo //QMl7JNdtqX9u0uWSzUwqd4HBWa2EZIuUNQH4Y65+F6Dqm5RrUEiMBBt72w+FM/hyPjIWaoW2M 5YUEnicQCT0GXrWIAb/BdH1e+GXNhzUlhlBV1Ydc/PyG++ZKud7RBTBIgcnvxqt1/SaYlng1PnR CyfaBfQCPMAqvxqoX83/u43vYxDit79ySPoaLdB8xy2aSmOu4cDNavzL1/VN++dJEY5y9g/vCm6 xljbxOL5w7jbSxNkeRFP4NBjYhCc434ruYZ9bxr/jbCl3b8nGbC6chhm8FWySABED8tzJwoM4X4 En5r/O8+0CfZPJH05gEbCMFPGp9de/Qnehr+2mIi5SEy0EuD3GH26G6bR4bNOc5vr7sCcvleOnF LuObtUu3rxsYaP78avQs3rczZiHGvvdmvKNOs7Qwwn6jeWCQO4y/clo8/szZzFSwkvzpff1Wxda iXIBNkEwtnB1W5gtjTN6IaTTbCtnBIBo7HRbNZrhO+T1WFoWmv3qig04b9PqDE= X-Received: by 2002:a05:600c:8116:b0:4a0:108:3b48 with SMTP id 5b1f17b1804b1-4a18030428cmr83460935e9.7.1791449232671; Thu, 08 Oct 2026 01:47:12 -0700 (PDT) Message-ID: <506d21d6-a6e7-4abd-b054-aeccd59565cf@suse.com> Date: Thu, 8 Oct 2026 10:47:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] xen/pdx: reject regions crossing a lookup table index To: Weiqi Wang Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, sstabellini@kernel.org, roger@xenproject.org, lucas.cordeiro@manchester.ac.uk, Weiqi Wang , xen-devel@lists.xenproject.org References: <71fe1a0cff0563db66df7f427d115fdd1953938e.1791291898.git.weiqi.wang-2@postgrad.manchester.ac.uk> 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: <71fe1a0cff0563db66df7f427d115fdd1953938e.1791291898.git.weiqi.wang-2@postgrad.manchester.ac.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791449233-AB2DC9EA-E6CF3655/10/78276251493 X-purgate-type: spam X-purgate-size: 3032 On 06.10.2026 15:06, Weiqi Wang wrote: > From: Weiqi Wang > > pdx_is_region_compressible() only looks up the table entry of the first > page, and checks the region against [pfn_base, pfn_base + > pdx_region_size). pfn_base need not be aligned to the table index > granularity, so that window can extend into the next index, which belongs > to a different range with a different offset. A region whose tail lies > there is reported compressible, yet its last page on its own is not, and > translates through the wrong offset. > > Require the first and last page of the region to use the same table > index. > > This can be reached from the coverage check in srat_parse_regions() when an > e820 RAM range is not covered by the SRAT ranges, which is the case that > check is meant to catch. > > Add a test case that fails without this change. > > Found with the ESBMC bounded model checker, and confirmed by running the > failing case natively against the unmodified code. > > Fixes: c5c45bcbd6a1 ("pdx: introduce a new compression algorithm based on region offsets") > Assisted-by: Claude Code:claude-opus-5-5 # finding the issue with ESBMC, patch creation > Signed-off-by: Weiqi Wang Reviewed-by: Jan Beulich with ... > --- a/tools/tests/pdx/test-pdx.c > +++ b/tools/tests/pdx/test-pdx.c > @@ -288,6 +288,39 @@ int main(int argc, char **argv) > } > } > > +#ifdef CONFIG_PDX_OFFSET_COMPRESSION > + /* > + * srat_parse_regions() passes e820 RAM ranges to > + * pdx_is_region_compressible(), and these can be wider than any single > + * SRAT range. A region must be rejected when its first and last page > + * resolve through different lookup table indices, even if it fits within > + * pdx_region_size. The values are PFNs from a ~5 GiB layout. > + */ > + { > + unsigned long ram_start = 0x4ca9bUL, ram_end = 0x12982eUL; > + > + pfn_pdx_compression_reset(); > + pfn_pdx_add_region(pfn_to_paddr(0x5bbd3UL), > + pfn_to_paddr(0xf18f2UL - 0x5bbd3UL)); > + pfn_pdx_add_region(pfn_to_paddr(0x1869bdUL), > + pfn_to_paddr(0x189f58UL - 0x1869bdUL)); > + > + if ( !pfn_pdx_compression_setup(0) ) > + { > + printf("table-index crossing test: compression disabled\n"); > + ret_code = EXIT_FAILURE; > + } > + else if ( pdx_is_region_compressible(pfn_to_paddr(ram_start), > + ram_end - ram_start) ) > + { > + printf( > + "region [%#lx, %#lx) crosses a table index but was accepted\n", ... this format string placed normally. We don't mind format strings going past 80 columns. Possibly the word "region" could also be omitted. (Surely this adjustment can be done while committing; no need to submit v4 just for this.) Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 08:48:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 08:48:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443063.1660450 (Exim 4.92) (envelope-from ) id 1xEjo2-0002Kf-IN; Thu, 08 Oct 2026 08:48:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443063.1660450; Thu, 08 Oct 2026 08:48: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 1xEjo2-0002KY-Fd; Thu, 08 Oct 2026 08:48:50 +0000 Received: by outflank-mailman (input) for mailman id 1443063; Thu, 08 Oct 2026 08:48:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEjo1-0002KQ-Gn for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 08:48:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEjo0-004p7f-HE for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:48:48 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac758ed-e002-0a2a0a5209dd-0a2a45018cd0-30 for ; Thu, 08 Oct 2026 10:48:48 +0200 Received: from [52.101.83.108] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac758ef-5984-0a2a45010019-3465536cab26-3 for ; Thu, 08 Oct 2026 10:48:48 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by PAWPR03MB9178.eurprd03.prod.outlook.com (2603:10a6:102:342::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Thu, 8 Oct 2026 08:48:43 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0496.015; Thu, 8 Oct 2026 08:48: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=krvh39CFNZ65y0sKVCVSF1vvWSsuzchXg6XPq07gjhV3BN+Ikg75zuZcorm87AccT5eIWhc8qcfuoxnY4DdR+80XrQiCG3xxbuAxe/l9mi3G3AcDqYxqI3LebUPam1yFLuKphyE8Xa0ht0o1DhpRqQ10BbJj7GcBblfjA83nEA54yrQmqBFxpVgVJhXFrKGhUuxPDcXx3rN8sO58Z7VtA4Ms4pemPmNhR3Xkd+QmV9LRcw08UpGhRqun7QXBByHrZsa0jkAjhSR4e4/Xv45osSQEYa4+BfNiTxHaiz4hWqWCRFvslErhgVG3UmIZPJbOH5qP1ghCoXLYTPvbav0zpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5mS4FDbP6ENKZD64FEZ8XvAoAMwqSYYfUVdgtbLP0wE=; b=NaNdi4JzoSW1+MGmAqEEEn2TV3C9whHelXvoI2Jy1tOJAlpZmBWKgnGOQiw7hLzdbwyQ2ijM4ueOOuYeMUw0JenZ688epsBJ1LOTr/rl2W+/fj2XZZO6QFklQxg7bxKALQqBClsFNSOFeWqypDhCoXfmeY3Qb38W3BV7QDWELRAZUZcZfb60BlEHl+FaLLOcp+5k0DSSfhCFr+ZHy5Us9UUjUvCZJKbyzul8QygzKOsRxgjDPJerbu7TQC/EkMafR0yhcawEbqonv5BgSxSs3ty9D/OHF43WJhku9ZksGUwkB+N5d+6p6m5+sQ2vlafRzVS6QGl0MwJjtoHx1CYc0A== 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=5mS4FDbP6ENKZD64FEZ8XvAoAMwqSYYfUVdgtbLP0wE=; b=hUFFRafNFuCtAXSIOHAClWU8+xXk3dE9t236+kb4Hsxg4inVyDGMXU2jvTJFo5dC95w0FLtOWyc/cXfQlm2pHsPteqUKpqnQP2X1MWwh0SoFGyRSJnwxQ/Qq4OmrJS24lbnDS1IlYPYumcd9cIwT8nxNiZ3pTogIisLPJDeLNLe5M9oi/UyXcZN7qDDtFyCsJSHKYIJ0KGGghPF5PBUGTPYuu3nHg88Ad7aprBXjmszi9l5Hx8Jjfqfwgb6GXGfyI7fbRgCW3n6YjxMRL5NHiE3fHMPKraVBCehNIfeIBs0YtYoKn9GJG2Gh2VNv635bJ3QNpSPvsDv+dVFksPY/kA== From: Mykyta Poturai To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini Subject: Re: [PATCH v9 6/6] docs: Document CPU hotplug Thread-Topic: [PATCH v9 6/6] docs: Document CPU hotplug Thread-Index: AQHdLu5YUFC+BXJe80SorzYjSmg7ErbzpccA Date: Thu, 8 Oct 2026 08:48:43 +0000 Message-ID: <6b106b71-cc16-420e-9466-91246fc06dc6@epam.com> References: <70484b3362f3b816bf4ed5f70c374c198a8a6eea.1787042017.git.mykyta_poturai@epam.com> <87bj9q84w5.fsf@epam.com> In-Reply-To: <87bj9q84w5.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: PAVPR03MB10102:EE_|PAWPR03MB9178:EE_ x-ms-office365-filtering-correlation-id: 59e5ed58-2b77-43e4-3b8d-08df2518f565 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|6133799003|18002099003|22082099003|260925021911599003|56012099006|260925021311599003|260925022911599003|10067099003|4143699003|38070700021|11063799006; x-microsoft-antispam-message-info: HiwbeQf5Rb61el2+owJOCu2KhWoZ0MWnMJB3ZFZeDS/CeIBeQyZQYhWBr27xF9GDNHYMz1MWMvbzNbP42HbIVRztW5ZK/xrj5iTr176cD+2zpd+cx3ynCliHu1odIpWnkvmm9XUbyr30/bw3aT4hOWbGVpQAjrhc22Dpbixnx6U+ixd2ukRLXuMwo/ZTc68FTgpSrg6MmC4PcPmkjGHktqjDDFMQatfCZwbmsr/8Gq2ytSp2Wl32xUfFMUuXWrUgMRlLoUNi7kG2PNSh97BtDIJ7SLVr79Wr0hxMyXBGIFdCOSHGy1YTiE1/BBpgj06NwHWJD7MMicErN5Sxb0OYjF13f/BTeouuAldBxPONTW7YTJjfOijR8P71SsZ2Ldg22NiDpIWkfOdti+fyQ5QU0ztyjnbknID+ig7F8AfIy+/qycJnPtaAZ+lgKOWtLbiYWfBJVtwgCOp1Qtmm26rZ0MZd2sW4ZFl5LDWtBKZ0mcFGots5kPVnWEl1JgPWeZ9YmpohiuYC9lVFaruQSgzm6SIUXGcQEbuO0g6igMwaCiwHe9LmGH+McVWguUwHDBB8lkrIA2bYhSnPPQbYxNi9zDY9/kOogHu/4SCIfOKX+S/9H1178ELktw/O3FQVYZ+0oNc/XmMuBlVKyPCoHrR/GtW/gxSDWoRbgqbRjmEsSBk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(6133799003)(18002099003)(22082099003)(260925021911599003)(56012099006)(260925021311599003)(260925022911599003)(10067099003)(4143699003)(38070700021)(11063799006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?b1VySFpZUGcwaUowZEs1VXN4RHN1akdpdC9neTJHSEk1M1crL21xM1dDOXQ2?= =?utf-8?B?QVpYN1lCWnpzdklYMmdRWEo2Zy9sSGFBdld6ZmN4YUZBclUxQmkxYjBRWUFa?= =?utf-8?B?TUIxaTdNL015RzdjdjF0bGwzVDRHZzlGT0hXYXFxRlI3UEppUUtBdzRacXdN?= =?utf-8?B?WVpSL3hKY3lIRktUKytYWWhHSEJtZzFGK0MzWnA0UXBycktIYWVPU2pTa0hr?= =?utf-8?B?SWYxN0tnTzNTUmo1TUdqcm80V05CKzJFZkEvV2E5NGN4VDN3MnJad1JWRWpM?= =?utf-8?B?K2x5ZHBCUFQ0VVN3TXUwbEN0akllbXFMYlY3ZU9jd2hmZGUwK1RxQjhCc1A2?= =?utf-8?B?NEduZlRxUGVxZ0dOTXAybHppWUdONU04cTY2UUU5L0RFcnNYamJJTWVZK2hM?= =?utf-8?B?U0IySXZUaFhiRUJpSWtHc3ZOSXcyK3FpTlR6R04xcU5IUFFmaTNkMTZiUFZy?= =?utf-8?B?K3pqeW9Sc2F6cTFYTk1uZklXZUFYUmc5NlR1anF6dFhSMDdrOSt3VkVVcGNx?= =?utf-8?B?dkdTY0YvemkyUThrSGFuekVMU2NyQk1vaGZvbGZpYkx0VytLYm1aa045MVNP?= =?utf-8?B?aUZVcWJyd2Nic2c0UERnS0lVeWxqY0Z5eU91NHJRcW53b1JjMXdyWkJSdFJJ?= =?utf-8?B?VUh0RkZnaGJuNFhacWZudjVPY3JHVXJrK0o5alNTaEtDNEpoSDJOMHdpd1I4?= =?utf-8?B?TC9RMmwreFI0T0hoQ3ZEeHhJRCtMYlRCOHVVbDNCaFRFdUxaK0RyVUU1cTFV?= =?utf-8?B?SkhLY1NUU0psRlRlaTFPREFCb2NUOHQ1QzVMRDN6NURYN3lmOFpyemZnRzZV?= =?utf-8?B?WFFXY2MybmRVNzdaQmlIYXRPQzdqT1k0OXNEZDhBcjNVZDB2Qzk1NXdWSVZR?= =?utf-8?B?am5JWWNLK0RWQlUvczZHbG50WTA2dWJDd1kxZ0J4amxhSGNtdkthQ3I1VjVt?= =?utf-8?B?dzVFYURXVTVNeEZIYXpCdjhINlZxNENnWFExMHZ1OS9NNE9uV1o3a0p1dFVG?= =?utf-8?B?QzFlUGxwMlVFVEZYVk90U1lxV2dwMlBqbDhHNi94RWd0LzNpb0FkbnI5cURO?= =?utf-8?B?dktoYWJHek5MRmVCc3RQeitvNzhTZ1dPTllBL1dsVEZKUHhnYUkramtpc1RQ?= =?utf-8?B?NmtmdGdVNEtXaDVHVkc3N1ZsanNqaE0wZmxhY2FLaEhIVDNtUjN2RWV4VU5r?= =?utf-8?B?a2dKZzhKWitwZmV1WmgzcjZlTVlBWjNCYXI4U2plYUx4aENjaGx6bFQ1ejk0?= =?utf-8?B?UmU1TjNsdUVLWnJDdHdoSzg5LzFkZVFwTlhqNnhmbkJ2UkQrQU0zL2d2M0Jj?= =?utf-8?B?eEsrbkpHTUVMWlREL1lQcXE2YnJhb2pBYVloZ3c0YmtaYmY3cGJWVEQwaEV5?= =?utf-8?B?WStYMVlGV0k2UzVHei9jU2JVNXlNSjlBU3NlMHBEUE9qRThKajh1aFhac3lB?= =?utf-8?B?T0tFT2tRSDIrVnh4NVRZd3dnb3lnc1RwT1ZjVkl1L05xZzYrcnl5MUFwbGZh?= =?utf-8?B?T1VmS1JuaUpHQVZZT1hEMW5GK1QwTENpQzhHZGMvbHNOQVR2WnFVdDE4MDJO?= =?utf-8?B?d096Tm9BQWJoRmZNaFNWTWNPRCswcjhUOW1abFZnQWttMGp0eE9sRFRPb3B4?= =?utf-8?B?MkpIWDAzYUVJTHdld3FlVE5JSXRSN1ExQ3B2aHhBT1paaUVCMDdXcUNnQlZJ?= =?utf-8?B?elRNTThjbmx6WFpPTFhPaGxhMFF5N2ZIYVArNlFnazJkTHJBSGZXeTFaU2Y3?= =?utf-8?B?L0xLdDZnWThRTnRkcVdENWtUOHFKZ2RqRGJRV3dTTzVjUDZndWkyYjJhQ3hh?= =?utf-8?B?SXQvNFdabFhmdzNWa3ZpTG1kWklLVjE0UUt1NWpRYmxPeWtPTWNFNzZQamJC?= =?utf-8?B?cnBvVC80WjQ0WlpjbmpKa0xTWk0rZytJODZDWkJvQytPZmFGWkcrVzJnalBn?= =?utf-8?B?UzlRTGhucjYxUE91dVFoNWtBQklwOU1Hc2pQYVkwZFNGdFpFb3hSZ2ZmTjhE?= =?utf-8?B?NGxsM2kzcVhyclJMZHZCdEhvQ0xTRTRJaWtzQVhBaW9zUVVOSEdUdlpQY0tw?= =?utf-8?B?U2FuTVd6ZEtKZlVRMk44VFV0aGtvKzcxSy9Kdk50YTFrZXlNNlJNQVM1UnFF?= =?utf-8?B?clhCTFcwZ1NEaEUvVzlnVTJ4djR0WFlKcXVKTUh1QklRQXlsOStPdTFFb0py?= =?utf-8?B?cit5U0ZHQ2Q0Qjl5MXZMbVc3cEtVNTkyOFFHbFBTTTJIT01lTnduMGdlQURy?= =?utf-8?B?VWRyRmpGeEMyd1l0YlEydmszaFZnR0Y3N3VNb2RCR0pNeDJoc3dGVnM3V2xn?= =?utf-8?B?WmhNQmFRT1VLKzRjUnRSS2NGQlJzdjd5SG42RFdzbmZGZ3RrZldrbDlFRllv?= =?utf-8?Q?I93FUQvkDzIg+/Nw=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <5419398F4B46A74A8948CD1F47B34452@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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59e5ed58-2b77-43e4-3b8d-08df2518f565 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2026 08:48:43.5783 (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: dc1eI3O2HCelQpb08kJfUi3ghTjbxz+GcZYPcr1I8H+JzDm0NgIuEsZ0cV3Z9dANgz2AoLzgpkZEaDWYoHkqGA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9178 X-purgate-ID: tlsNG-d62444/1791449328-C495A757-6908EB13/0/0 X-purgate-type: clean X-purgate-size: 4758 T24gOS8yMi8yNiA0OjEzIEFNLCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4gSGksDQo+IA0K PiBNeWt5dGEgUG90dXJhaSA8TXlreXRhX1BvdHVyYWlAZXBhbS5jb20+IHdyaXRlczoNCj4gDQo+ IEkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnMsIHBsZWFzZSBzZWUgYmVsb3cNCj4gDQo+PiBT aWduZWQtb2ZmLWJ5OiBNeWt5dGEgUG90dXJhaSA8bXlreXRhX3BvdHVyYWlAZXBhbS5jb20+DQo+ PiAtLS0NCj4+IHY4LT52OToNCj4+ICogZml4IHR5cG9zDQo+Pg0KPj4gdjctPnY4Og0KPj4gKiBy ZW1vdmUgc3VwcG9ydCBzdGF0dXMgdXBkYXRlDQo+PiAqIHVwZGF0ZSBjb25maWcgb3B0aW9uIG5h bWUNCj4+DQo+PiB2Ni0+djc6DQo+PiAqIGFkZCB0ZXN0aW5nIGFuZCBsaW1pdGF0aW9ucw0KPj4N Cj4+IHY1LT52NjoNCj4+ICogbm8gY2hhbmdlcw0KPj4NCj4+IHY0LT52NToNCj4+ICogcy9zdXBw b3J0ZWQvaW1wbGVtZW50ZWQvDQo+PiAqIHVwZGF0ZSBTVVBQT1JULm1kDQo+Pg0KPj4gdjMtPnY0 Og0KPj4gKiB1cGRhdGUgY29uZmlndXJhdGlvbiBzZWN0aW9uDQo+Pg0KPj4gdjItPnYzOg0KPj4g KiBwYXRjaCBpbnRyb2R1Y2VkDQo+PiAtLS0NCj4+ICAgZG9jcy9taXNjL2NwdS1ob3RwbHVnLnR4 dCB8IDk4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPj4gICAxIGZp bGUgY2hhbmdlZCwgOTggaW5zZXJ0aW9ucygrKQ0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgZG9j cy9taXNjL2NwdS1ob3RwbHVnLnR4dA0KPj4NCj4+IGRpZmYgLS1naXQgYS9kb2NzL21pc2MvY3B1 LWhvdHBsdWcudHh0IGIvZG9jcy9taXNjL2NwdS1ob3RwbHVnLnR4dA0KPj4gbmV3IGZpbGUgbW9k ZSAxMDA2NDQNCj4+IGluZGV4IDAwMDAwMDAwMDAuLjRmNjA2OGRiMzANCj4+IC0tLSAvZGV2L251 bGwNCj4+ICsrKyBiL2RvY3MvbWlzYy9jcHUtaG90cGx1Zy50eHQNCj4+IEBAIC0wLDAgKzEsOTgg QEANCj4+ICtDUFUgSG90cGx1Zw0KPj4gKz09PT09PT09PT09DQo+PiArDQo+PiArQ1BVIGhvdHBs dWcgaXMgYSBmZWF0dXJlIHRoYXQgYWxsb3dzIHBDUFUgY29yZXMgdG8gYmUgYWRkZWQgdG8gb3Ig cmVtb3ZlZCBmcm9tIGENCj4+ICtydW5uaW5nIHN5c3RlbSB3aXRob3V0IHJlcXVpcmluZyBhIHJl Ym9vdC4gSXQgaXMgaW1wbGVtZW50ZWQgb24geDg2IGFuZCBBcm02NA0KPj4gK2FyY2hpdGVjdHVy ZXMuDQo+PiArDQo+PiArSW1wbGVtZW50YXRpb24gRGV0YWlscw0KPj4gKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+ICsNCj4+ICtDUFUgaG90cGx1ZyBpcyBpbXBsZW1lbnRlZCB0aHJvdWdoIHRo ZSBgWEVOX1NZU0NUTF9DUFVfSE9UUExVR18qYCBzeXNjdGwgY2FsbHMuDQo+PiArVGhlIHNwZWNp ZmljIGNhbGxzIGFyZToNCj4+ICsNCj4+ICstIGBYRU5fU1lTQ1RMX0NQVV9IT1RQTFVHX09OTElO RWA6IEJyaW5ncyBhIHBDUFUgb25saW5lDQo+PiArLSBgWEVOX1NZU0NUTF9DUFVfSE9UUExVR19P RkZMSU5FYDogVGFrZXMgYSBwQ1BVIG9mZmxpbmUNCj4+ICstIGBYRU5fU1lTQ1RMX0NQVV9IT1RQ TFVHX1NNVF9FTkFCTEVgOiBFbmFibGVzIFNNVCB0aHJlYWRzICh4ODYgb25seSkNCj4+ICstIGBY RU5fU1lTQ1RMX0NQVV9IT1RQTFVHX1NNVF9ESVNBQkxFYDogRGlzYWJsZXMgU01UIHRocmVhZHMg KHg4NiBvbmx5KQ0KPj4gKw0KPj4gK0FsbCBjb3JlcyBjYW4gYmUgZGlzYWJsZWQsIGFzc3VtaW5n IGhhcmR3YXJlIHN1cHBvcnQsIGV4Y2VwdCBmb3IgdGhlIGJvb3QgY29yZS4NCj4+ICtTeXNjdGwg Y2FsbHMgYXJlIHJvdXRlZCB0byB0aGUgYm9vdCBjb3JlIGJlZm9yZSBkb2luZyBhbnkgYWN0dWFs IHVwL2Rvd24NCj4+ICtvcGVyYXRpb25zIG9uIG90aGVyIGNvcmVzLg0KPj4gKw0KPj4gK0lmIHRo ZXJlIGFyZSBYZW4tYm91bmQgaW50ZXJydXB0cyBwaW5uZWQgdG8gdGhlIHBDUFUgYmVpbmcgb2Zm bGluZWQsIHRoZXkgd2lsbA0KPj4gK2JlIGF1dG9tYXRpY2FsbHkgbWlncmF0ZWQgdG8gb3RoZXIg b25saW5lIHBDUFVzLiBJbnRlcnJ1cHRzIHVzZWQgYnkgZ3Vlc3QNCj4+ICtkb21haW5zIGFyZSBo YW5kbGVkIGJ5IHRoZSBzY2hlZHVsZXIgd2hlbiBpdCByZXNjaGVkdWxlcyB0aGUgdkNQVXMgdG8g YSBuZXcsDQo+PiArb25saW5lLCBwQ1BVLiBXaGVuIGEgcENQVSBpcyBiZWluZyBvbmxpbmVkLCBz b21lIFhlbi1ib3VuZCBpbnRlcnJ1cHRzIHdpbGwgZ2V0DQo+PiArcmVkaXN0cmlidXRlZCB0byB0 aGUgbmV3bHkgb25saW5lZCBwQ1BVIHRvIHByZXZlbnQgaW1iYWxhbmNlLg0KPj4gKw0KPj4gK0lm IHBDUFUgYmVpbmcgb2ZmbGluZWQgaGFzIHNvbWUgdkNQVXMgcGlubmVkIHRvIGl0LCB0aGV5IHdp bGwgYmUgYXV0b21hdGljYWxseQ0KPj4gK3VucGlubmVkIGFuZCBtaWdyYXRlZCB0byBvdGhlciBv bmxpbmUgcENQVXMuDQo+PiArDQo+PiArTGltaXRhdGlvbnMNCj4+ICstLS0tLS0tLS0tLQ0KPj4g Kw0KPj4gK09uIEFybTY0IGNwdSBob3RwbHVnIGlzIGN1cnJlbnRseSBub3QgY29tcGF0aWJsZSB3 aXRoIElUUywgZHVlIHRvIGFuIGlzc3VlIHdpdGgNCj4+ICt0aGUgcmVkaXN0cmlidXRvciBhc3Np Z25tZW50Lg0KPiANCj4gSW4gdGhpcyBjYXNlIHlvdSBwcm9iYWJseSB3YW50IHRvIG1ha2Ugc3Vy ZSB0aGF0DQo+IENPTkZJR19DUFVfT05MSU5FX09GRkxJTkUgaXMgaW5jb21wYXRpYmxlIHdpdGgg Q09ORklHX0hBU19JVFMNCj4gDQo+PiArDQo+PiArT24gQXJtNjQgdGhlcmUgY2FuIGJlIHByb2Js ZW1zIHdpdGggRkZBIGlmIHNlY3VyZSBGVyBzdXBwb3J0cyB0aGUgbm90aWZpY2F0aW9uDQo+PiAr QUJJLCBhbmQgd2l0aCBURUUsIGFzIGJvdGggdXNlIG5vbi1zdGF0aWMgSVJRIGFjdGlvbnMuDQo+ IA0KPiBDb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBvbiB0aGlzPyBBRkFJSywgT1AtVEVFIGhh cyBvd24NCj4gY3B1X3VwL2NwdV9kb3duIGNhbGxiYWNrcywgc28gaXQgc2hvdWxkIGtub3cgd2hp Y2ggQ1BVcyBhcmUgb25saW5lLg0KDQpJdCdzIG1vcmUgb2YgYSBwcm9ibGVtIHdpdGggdGhlIHdh eSBpbnRlcnJ1cHQgaGFuZGxlcnMgYXJlIHNldCB1cCBpbiANClhlbi4gTXlrb2xhIGFscmVhZHkg aGFzIGZpeGVzIGZvciBpdCBpbiBhIHNlcGFyYXRlIHNlcmllcywgYnV0IEknbSBub3QgDQpob3cg dG8gYmVzdCBzeW5jIHVwIG91ciBlZmZvcnRzLg0KDQpodHRwczovL3BhdGNoZXcub3JnL1hlbi9j b3Zlci4xNzg3ODM4NDU1LmdpdC5teWtvbGEuXzVGa3ZhY2hAZXBhbS5jb20vNjIzYmU5YTBhNTYw MzA3M2YyNWQwMDk5NzlhYjQ5YjYxMWU3ZGRkYy4xNzg3ODM4NDU1LmdpdC5teWtvbGEuXzVGa3Zh Y2hAZXBhbS5jb20vDQoNCmh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuL2NvdmVyLjE3ODc4Mzg0NTUu Z2l0Lm15a29sYS5fNUZrdmFjaEBlcGFtLmNvbS9jYzEwODg4ZjM0ZTg4N2Y3MzlkNjYzMTJhYTg3 MWE2ZGY0MTk2MjA0LjE3ODc4Mzg0NTUuZ2l0Lm15a29sYS5fNUZrdmFjaEBlcGFtLmNvbS8NCg0K From xen-devel-bounces@lists.xenproject.org Thu Oct 08 09:29:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 09:29:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443088.1660467 (Exim 4.92) (envelope-from ) id 1xEkQp-0000H2-Ih; Thu, 08 Oct 2026 09:28:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443088.1660467; Thu, 08 Oct 2026 09:28: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 1xEkQp-0000Gu-Fw; Thu, 08 Oct 2026 09:28:55 +0000 Received: by outflank-mailman (input) for mailman id 1443088; Thu, 08 Oct 2026 09:28:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEkQo-0000Go-7r for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:28:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEkQn-0049km-7H for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:28:53 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7624f-e002-0a2a0a5209dd-0a2a4508e5b0-36 for ; Thu, 08 Oct 2026 11:28:53 +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 6ac76254-f659-0a2a45080019-d155802ad820-3 for ; Thu, 08 Oct 2026 11:28:52 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a020e65269so21289825e9.2 for ; Thu, 08 Oct 2026 02:28: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-48c71d123b5sm9930222f8f.24.2026.10.08.02.28.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 02:28: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: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=1791451732; x=1792056532; 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=q5TXs4tm9M71FUzuIHR7e3tnd6xBqprQJ5FUBQIYQts=; b=ewKdn65c4Do1TY0AGgH9xBfphl1ps1ZTxw20k+hHL5lwUwSFnYWa8yCcUfLgnlennG 8oxdKnilDtsRXPvmKS+OiWLyoC2l6fpgK6pK+CmkI8yiWu3AmJblR4xbWc1k035o1a7K Vdk+QDsmF5PY39HGElIJuz/kpTnoI1Ax+XjdqbiWS4Q+6j1H2i/xP6iIe+Ya4DEQ07RP H5U/a+u7LowfNwkR1eb+Tgz7TmCPF31S3ZdirAhZo/64af1cbp0iF62+jEMRmuXTxWYk ZjgBKh7WaORd9qYq9TNo1GHXcYGFCuOMjU+S6H+8TiAWp3JdGiUcgiN1+DatcgXMjxrj Hf7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791451732; x=1792056532; 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=q5TXs4tm9M71FUzuIHR7e3tnd6xBqprQJ5FUBQIYQts=; b=bwWb9UuCruIvoO9FR07WiqZcyFu6KY/4/0znabH/XzUUeuNBhysax87mfw83s1cr3W 4+hPbvU72eyvuFQNkL5YDum8PZZH//S3RvN4Z0rpRJlxMvzapP6x/ZRQOmgyvWrLTC44 A7GVx0K+vaYyT8i6KUZ4ZewAMUoU0ACVPCLKp860GGlK552VjHujy+9Gm5q9OC8fAQ9n clAhyEnw8RjTESTFGaJPropfG1B3F0cgu4y+PCzVD7lHTyWBXK/SrLe1d2cjrwjCPtuQ 3qd7Y0PHCSXn31EjbbZiujJOj4EA5wB539BGi+tL8lU0AvQbpEaCcu8mgz9v8Q09ecVQ 1tUg== X-Gm-Message-State: AFuF++nJxVTlOzOJVf+aiL3sJxvaDOnOv2bCs4SWrDR7hXkeJfM3/jBq Rs8kMMpYybOWKw7BbJGuaC44Q6JONymoS2GsEQofg8mlW4TQMQ9bcK2BlUGVW5E7vOkhWozjLGl b25Tvuw== X-Gm-Gg: AYBFou331AnmKVLW6vPlF1VxuBoly3wzsMDyYGZVQ4QwKOapW66fPEsNXGXQ29BklX0 u2KFr/AHxERG0GAJh4C5fpKkx7YFQX8CVX5KyGncurbeSZl4phTVcaed1stFYiVYjV6OaAuYD/k MM2W0CSJ99XkEsKWTrcwpFSuYAJ+rsIjUvJn3QN1xU7BBIfHNixK1vPHca95THmfudTdaWCgRGW Q4eY0HMxw2PeAscUl9teGLbZCMsDWeyeIFIIOoNMW72QAHqfiSUsO+VyNF9/Y1Cbplc7EuqpZI5 AauUhJ+26ftLO6XEjc6870Wy7NMHyLmDzOXqIE9N+bF/pojsptSCkpg8A0cXPykN2Bmhrbo3Rm+ hFgEcor3ClzcrEItCuWDLCWe8raHk5ZAZK6rgb9CIterxS9Jt6iUTuMZndUm4rw6Ol4aKFUOH3o WdEbf5nWx5WurmiW2p6MVi7+/Wx6Fg58zR89+NjRuO2nSMIzJOmH0Cv9WU6xaBI4rlPc2PJdcT8 6WxKN7bzPRSWfxavZhQueJnbEbueS1gcd2d2RYsIXVEWKmM9F9vo/hpJDi2VEgYEhBJ3yV4tQ== X-Received: by 2002:a05:600c:19c7:b0:4a1:70f0:ac2 with SMTP id 5b1f17b1804b1-4a180648d69mr89183895e9.24.1791451732053; Thu, 08 Oct 2026 02:28:52 -0700 (PDT) Message-ID: Date: Thu, 8 Oct 2026 11:28:50 +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] gnttab: avoid use of raw_shah and union grant_combo in _set_status_v2() Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1791451732-CE34587B-C68E68AE/10/78276251493 X-purgate-type: spam X-purgate-size: 4586 The main issue here being the cast to establish raw_shah; where possible such casts are best avoided. (The (ab)use of unions is an issue as well, but we have uses like this all over the place.) With shared and status entries separated, we don't really need to mirror _set_status_v1() behavior here. The shared entry fields can be accessed normally, merely using compiler barriers to ensure checks are done on stable local copies. In particular, torn reads (not that we expect the compiler to emit such, i.e. this is a purely theoretical concern here anyway) are not a problem. While there also avoid unnecessary use of a fixed-width type for the "mask" local variable (which wants to match "flags" anyway). Signed-off-by: Jan Beulich --- I'm puzzled by gcc's codegen with uint16_t vs unsigned int for the two local variables: Use of unsigned int in principle would allow to generate better code, if only the compiler wouldn't (as per observations with gcc16) - emit redundant MOVZWL, - needlessly clobber a register variable, thus causing use of %ebx (and hence saving/restoring of %rbx). Overall there's no change in size of compiled code (when really it could shrink). Note that no similar odd effects are observable for Arm. --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -832,26 +832,26 @@ static int _set_status_v2(const grant_en domid_t ldomid) { int rc = GNTST_okay; - const uint32_t *raw_shah = (const uint32_t *)shah; - union grant_combo scombo; - uint16_t mask = GTF_type_mask; + domid_t domid = shah->domid; + unsigned int flags = shah->flags, mask = GTF_type_mask; - scombo.raw = ACCESS_ONCE(*raw_shah); - - /* if this is a grant mapping operation we should ensure GTF_sub_page + /* If this is a grant mapping operation we should ensure GTF_sub_page is not set */ if ( mapflag ) mask |= GTF_sub_page; + /* Make sure all checks below are done on stable local copies. */ + barrier(); + /* If not already pinned, check the grant domid and type. */ if ( !act->pin && - ((((scombo.flags & mask) != GTF_permit_access) && - (mapflag || ((scombo.flags & mask) != GTF_transitive))) || - (scombo.domid != ldomid)) ) + ((((flags & mask) != GTF_permit_access) && + (mapflag || ((flags & mask) != GTF_transitive))) || + (domid != ldomid)) ) { gdprintk(XENLOG_WARNING, "Bad flags (%x) or dom (%d); expected d%d, flags %x\n", - scombo.flags, scombo.domid, ldomid, mask); + flags, domid, ldomid, mask); rc = GNTST_general_error; goto done; } @@ -862,7 +862,7 @@ static int _set_status_v2(const grant_en } else { - if ( unlikely(scombo.flags & GTF_readonly) ) + if ( unlikely(flags & GTF_readonly) ) { gdprintk(XENLOG_WARNING, "Attempt to write-pin a r/o grant entry\n"); @@ -876,26 +876,30 @@ static int _set_status_v2(const grant_en still valid */ smp_mb(); - scombo.raw = ACCESS_ONCE(*raw_shah); + flags = shah->flags; + domid = shah->domid; + + /* Again, all checks below need doing on stable local copies. */ + barrier(); if ( !act->pin ) { - if ( (((scombo.flags & mask) != GTF_permit_access) && - (mapflag || ((scombo.flags & mask) != GTF_transitive))) || - (scombo.domid != ldomid) || - (!readonly && (scombo.flags & GTF_readonly)) ) + if ( (((flags & mask) != GTF_permit_access) && + (mapflag || ((flags & mask) != GTF_transitive))) || + (domid != ldomid) || + (!readonly && (flags & GTF_readonly)) ) { gnttab_clear_flags(rd, GTF_writing | GTF_reading, status); gdprintk(XENLOG_WARNING, "Unstable flags (%x) or dom (%d); expected d%d (r/w: %d)\n", - scombo.flags, scombo.domid, ldomid, !readonly); + flags, domid, ldomid, !readonly); rc = GNTST_general_error; goto done; } } else { - if ( unlikely(scombo.flags & GTF_readonly) ) + if ( unlikely(flags & GTF_readonly) ) { gnttab_clear_flags(rd, GTF_writing, status); gdprintk(XENLOG_WARNING, "Unstable grant readonly flag\n"); From xen-devel-bounces@lists.xenproject.org Thu Oct 08 09:48:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 09:48:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443108.1660496 (Exim 4.92) (envelope-from ) id 1xEkjw-0003lB-CF; Thu, 08 Oct 2026 09:48:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443108.1660496; Thu, 08 Oct 2026 09:48: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 1xEkjw-0003l4-9K; Thu, 08 Oct 2026 09:48:40 +0000 Received: by outflank-mailman (input) for mailman id 1443108; Thu, 08 Oct 2026 09:48:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEkju-0003ky-Aq for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:48:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEkjt-004DXj-Nv for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:48:37 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac766f5-2eae-0a2a0a5409dd-0a2a4503be1e-2 for ; Thu, 08 Oct 2026 11:48: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 6ac766f5-fae8-0a2a45030019-d1558031a48c-3 for ; Thu, 08 Oct 2026 11:48:37 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a16c1608faso6031855e9.0 for ; Thu, 08 Oct 2026 02:48: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-4a17f4480a4sm101044835e9.0.2026.10.08.02.48.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 02: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: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=1791452917; x=1792057717; 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=DWfH1DGE58SIHUKFq2jZgD9LIrfRjNCQ+Kf8MfrXNwo=; b=IZz1HWsYYRp2hIbfisybyHPsIUtQQPt2hR+F3Gozxbt/UXqw3/2dL+wGh9lOmnMtWJ j+nQqT5SBkG0eytWUM/6EJmBZH+cz4WT5s/V8ZswUm+WdxoN4HS67URknoM8s9SwusZ4 pUfYXbck7wkfUHP3ChxKkMXlpsWcdxZ2zZzUCd+nJsAPVmpQJUFNEnguJ2uK1D7H4VNw BXxJSYgppF6aFK7/EDad9pGdJpPKZzHJci8FshF4ynpuj5oHNb3bGzAMfxkVpm7tP5W8 eUqG2/sM/ucgP9uHshs3F3VcfnWESXZHQVwoSY0fM9KlK08rT2PzLm1IzZ6rE39we2tt 1aJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791452917; x=1792057717; 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=DWfH1DGE58SIHUKFq2jZgD9LIrfRjNCQ+Kf8MfrXNwo=; b=bE89iACoECTF9WGXSiWDLgMk2qPVcn5MH7J5nj3OGWlZMmAJObuOVlMfiXhwgEOF2J vgRMKCl4JZrDNgvDjD1T8MCeuO1dRb0DOcMJL/RtVoZ0Y7o1rHB+SkIEntmPiW3jq9Lr a56OxC3oGkCVLi/IFf+15kqsZoyj3AM2LtW9MJz33OsUQ/rriFrPgAWT9Tg5aax58Yy6 5CqUce2J7xByeP61xi3muZsIil6NRH+3gez/+SQjdVZQszG6z+Vn0RlWLE/QqrOiJQG1 ZbxX1cWKGwV6wl5bWiEApHKpwNSiTH3icf9CMoZpF6nwyin6SlrCOqUnzi3nhyfcQ3Po MQGA== X-Gm-Message-State: AFuF++lQ4TSL+RxQ79ZKzzhBSLctab/uimlSpwF9WC6n+geUPIKfRlod URHBTPdCZ/ZEbck9MhBwXjB1JRwSOQP9E6HcvL6tkyZ4BDuVxgL7SVNcVx8NHZX2PgEmI2oPvwc x8s+dlg== X-Gm-Gg: AYBFou3H8EpJP2YsWOHDBbsStXQ81sg9WinP9N/D6cW5n382xADew31Rob+XNz0vMgg OxPOCfcm7oh+L6O4ml+n/Q4o12AyjLCb8gBtTBp9EZskTWtctVUTpLn7lXrG1n0KhSjHLL7a2QA 0fmwYIOTPYokWRvDnbbq041LoD64fcMfhq6Oy0cosIkspaKkdQpM+btFo4JIM5ltoFij6kWqQov UcafYRVTyRYOtW31x1NvTHQAmgSpuF9NB+MJIjHJKJB9IY5lwUdfVOL12PF6wMP+m9CBR6XSxTn XGypedROIC5+KZDEVZzD5L52uaoIfCVAadrf/xwR5lkIld8iYrGFIX5gTK9YmjcDFfzzRBbN/dr YYqETs/KDsQuzJK8RdECRoOnIBYjcua+eIqUwl8Hb4NoobjhMc/BifsPxCZ2vsz/A3kv5tW90wn /hEZtPH3Qmt+TCbp3DKEyyZ2cYRYa9rf/akb2/uydXKVzCalNIHYc77weNyqETlZAT8zgAgQePe zJXpCzQRuovWuQhg11BMNuK7SA9dc8+66DEOqWRdCce+jKKgvWapG2pki5iGw== X-Received: by 2002:a05:600c:3ca0:b0:4a0:1b14:d009 with SMTP id 5b1f17b1804b1-4a1851a34b3mr32197565e9.1.1791452916413; Thu, 08 Oct 2026 02:48:36 -0700 (PDT) Message-ID: <9698d810-6664-4a9d-a847-18ad124261e0@suse.com> Date: Thu, 8 Oct 2026 11:48:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Juergen Gross , Boris Ostrovsky From: Jan Beulich Subject: [PATCH LINUX] x86/PVH: don't truncate initrd address/size Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1791452917-75C804E9-485E0624/10/78276251493 X-purgate-type: spam X-purgate-size: 750 Consuming merely the lower halves of the provided values isn't very useful. (While generally loaders try to place it below 4G, especially when it's huge it may not fit there.) Fixes: 7243b93345f7 ("xen/pvh: Bootstrap PVH guest") Signed-off-by: Jan Beulich --- a/arch/x86/platform/pvh/enlighten.c +++ b/arch/x86/platform/pvh/enlighten.c @@ -78,7 +78,9 @@ static void __init init_pvh_bootparams(b struct hvm_modlist_entry *modaddr = __va(pvh_start_info.modlist_paddr); pvh_bootparams.hdr.ramdisk_image = modaddr->paddr; + pvh_bootparams.ext_ramdisk_image = modaddr->paddr >> 32; pvh_bootparams.hdr.ramdisk_size = modaddr->size; + pvh_bootparams.ext_ramdisk_size = modaddr->size >> 32; } /* From xen-devel-bounces@lists.xenproject.org Thu Oct 08 09:54:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 09:54:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443116.1660505 (Exim 4.92) (envelope-from ) id 1xEkpx-0005P0-Va; Thu, 08 Oct 2026 09:54:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443116.1660505; Thu, 08 Oct 2026 09:54: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 1xEkpx-0005Ot-Ss; Thu, 08 Oct 2026 09:54:53 +0000 Received: by outflank-mailman (input) for mailman id 1443116; Thu, 08 Oct 2026 09:54:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEkpx-0005On-2I for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 09:54:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEkpv-00AqCA-VC for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:54:51 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac76862-2eae-0a2a0a5409dd-0a2a45089936-42 for ; Thu, 08 Oct 2026 11:54:51 +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 6ac7686b-f659-0a2a45080019-b9ff1c12acc9-3 for ; Thu, 08 Oct 2026 11:54: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 1a11aefddb50003f66.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 08 Oct 2026 09:54: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 E5F9481F99; Thu, 8 Oct 2026 11:54: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=B9pQljgIBPXNu5V97rMnBqSwLr4UJebQOzSb3YSE1yY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=T3eRU5TA8npedaq1vKqbSC/5cmshdvrkXQc1HkK3maJzr9s6PUbyY30RqDHzF8up7c8mORqPC +DviYbbWocTrFByaqhCAZd3tMkALptokSxSTG/fgcBlJ47uU2nfui5BJfYiV3pBAXdiScdBktDg X2FeJ/9qOJx4pOmnVAmWse/4rSwiSgT/jTd1E5VMTAVMYMiq7lXUHbJoJmh9gcOlwQfp6S1IwoY RJqVGzh0/x8rgZl8wsGpcZhYSQc/fO62QxDzvjBRhTYfxsULAohmIlhtf1EuT1bAzo3+Pt4ojsR aZW+5m7vHzg8dEIp4xAc6jGjOSwElx1eY/uy4zu2BRKw== X-Zone-Loop: 8da2d054154ff9621530021e8ac5c3c07e8a682f8cb9 x-campaign-type: default x-transaction-id: 40e098d1-bff1-461e-a30f-a0478cf31e6a x-swg-uid: 01-11c22fbd-4bd5-4929-a379-19289ecbcf11 X-Mailer: Sweego Message-ID: <1791453289.8631fc262581453bbf619ec5b2062170.1a11aefddb50003f66@vates.tech> x-swg-bid: 1791453289.8631fc262581453bbf619ec5b2062170.1a11aefddb50003f66 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 v3 14/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: References: Date: Thu, 08 Oct 2026 11:54:42 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791453283; l=2006; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=7tlJvdarwH4nTpyDkyDBiMB+wRx2EiTODtmYWrm13pc=; b=XJ1/JVvx9Ns82cwZP6bAbE39T7jap8/QUGjPXYIxomh3Uvs4iVq1aFvgWYmecXryz5oLF1wxv KmTD1ohYN4aCnPvG9Nn5mIZ+5Bi9IhRgJAYfOvvYQLxIxvM8sUMU8/g 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: 1791453289152 X-purgate-ID: tlsNG-c1860d/1791453291-CDF4787B-210DFFB0/10/73395122804 X-purgate-type: spam X-purgate-size: 2006 > 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. Nothing reads the recorded value yet. > > imsic_ctxt_switch_to() has nothing to do: switching a vCPU in on the CPU > which owns its guest interrupt file needs no IMSIC update. Only a move to > another CPU does (a new VGEIN and a remapped file), and that isn't part of > the context switch. Nit: I think it could make sense to mention that if a migration happen, it would go anyway in imsic_migrate_vcpu() before imsic_ctxt_switch_to(). > > 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 the only one vAPLIC emulates, 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 Should add Signed-off-by Romain Caritey. Without that, everything is ok from my side > Signed-off-by: Oleksii Kurochko > --- a/xen/arch/riscv/vaplic.c > +++ b/xen/arch/riscv/vaplic.c > @@ -456,6 +456,12 @@ 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, so the vAPLIC state to save Nit: Do we want to always support only MSI delivery? If not, maybe adapt the comment. Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 08 10:16:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 10:16:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443128.1660515 (Exim 4.92) (envelope-from ) id 1xElAN-0000eX-K9; Thu, 08 Oct 2026 10:15:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443128.1660515; Thu, 08 Oct 2026 10:15: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 1xElAN-0000eQ-FT; Thu, 08 Oct 2026 10:15:59 +0000 Received: by outflank-mailman (input) for mailman id 1443128; Thu, 08 Oct 2026 10:15:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xElAM-0000eK-0G for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:15:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xElAL-00FShf-6Y for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:15:57 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac76d56-bab6-0a2a0a5309dd-0a2a450cd3ce-14 for ; Thu, 08 Oct 2026 12:15:56 +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 6ac76d5c-f479-0a2a450c0019-c387df83be30-3 for ; Thu, 08 Oct 2026 12:15:56 +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 6F8671F79D; Thu, 8 Oct 2026 10:15:56 +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 321EC1339F; Thu, 8 Oct 2026 10:15:56 +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 GDNuAlxtx2q+MwAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 10:15: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; none Authentication-Results: smtp-out2.suse.de; none Message-ID: Date: Thu, 8 Oct 2026 12:15:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH LINUX] x86/PVH: don't truncate initrd address/size To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Boris Ostrovsky References: <9698d810-6664-4a9d-a847-18ad124261e0@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: <9698d810-6664-4a9d-a847-18ad124261e0@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------wNxBEm2fcAqQvsRZLSll8NvO" X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spamd-Result: default: False [0.00 / 50.00] X-Spam-Score: 0.00 X-Spam-Flag: NO X-Spam-Level: X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-purgate-ID: tlsNG-d25034/1791454556-02CDBA5B-469825A8/10/78276251493 X-purgate-type: spam X-purgate-size: 8041 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------wNxBEm2fcAqQvsRZLSll8NvO Content-Type: multipart/mixed; boundary="------------tq292TXrjXzjAXiWDRzgJ6zs"; protected-headers="v1" From: Juergen Gross To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Boris Ostrovsky Message-ID: Subject: Re: [PATCH LINUX] x86/PVH: don't truncate initrd address/size References: <9698d810-6664-4a9d-a847-18ad124261e0@suse.com> In-Reply-To: <9698d810-6664-4a9d-a847-18ad124261e0@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= --------------tq292TXrjXzjAXiWDRzgJ6zs Content-Type: multipart/mixed; boundary="------------1FMfH77NUIvnnLCI4G0ki5g0" --------------1FMfH77NUIvnnLCI4G0ki5g0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDguMTAuMjYgMTE6NDgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBDb25zdW1pbmcgbWVy ZWx5IHRoZSBsb3dlciBoYWx2ZXMgb2YgdGhlIHByb3ZpZGVkIHZhbHVlcyBpc24ndCB2ZXJ5 DQo+IHVzZWZ1bC4gKFdoaWxlIGdlbmVyYWxseSBsb2FkZXJzIHRyeSB0byBwbGFjZSBpdCBi ZWxvdyA0RywgZXNwZWNpYWxseQ0KPiB3aGVuIGl0J3MgaHVnZSBpdCBtYXkgbm90IGZpdCB0 aGVyZS4pDQo+IA0KPiBGaXhlczogNzI0M2I5MzM0NWY3ICgieGVuL3B2aDogQm9vdHN0cmFw IFBWSCBndWVzdCIpDQo+IFNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz dXNlLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNv bT4NCg0KDQpKdWVyZ2VuDQo= --------------1FMfH77NUIvnnLCI4G0ki5g0 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----- --------------1FMfH77NUIvnnLCI4G0ki5g0-- --------------tq292TXrjXzjAXiWDRzgJ6zs-- --------------wNxBEm2fcAqQvsRZLSll8NvO 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/Ey8FAmrHbVsFAwAAAAAACgkQsN6d1ii/Ey89 iQf+I2N2YnEJCZc34cQRcPBWSmEcyIJCSsaGCyLXToGr9rAu39goH7APfyCOAlPgmt07z3dtuyh/ raLpreAzGn/+QlRWQZZPVVuHujJXKi/KzpPhXVOK66vUSEpPWvbSbLU9rCop+x6TVMoRoPFV1xcq UX1JUrLscefbgC4cxmc2NTXqtBOVN/dAWwanm5aUUOw0OWEMGzQql8ETpPmkXNPK6SI1OS7flJF1 jSfLJC0u+uHaBlMo3fsXmhnmqHk15e92WvqzTL1rAgQPDQlyr7PAV3njgJS/ISq4+AzjFCNbr9c5 aHrt2BKkZtxImhxxLQuvgCytKfDkEkdudBuN5fG1AA== =H96A -----END PGP SIGNATURE----- --------------wNxBEm2fcAqQvsRZLSll8NvO-- From xen-devel-bounces@lists.xenproject.org Thu Oct 08 10:16:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 10:16:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443133.1660524 (Exim 4.92) (envelope-from ) id 1xElBK-00017q-Rx; Thu, 08 Oct 2026 10:16:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443133.1660524; Thu, 08 Oct 2026 10:16: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 1xElBK-00017j-OL; Thu, 08 Oct 2026 10:16:58 +0000 Received: by outflank-mailman (input) for mailman id 1443133; Thu, 08 Oct 2026 10:16:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xElBI-00017U-Sl for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:16:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xElBH-00Gcr5-Nr for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:16:55 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac76d79-2eae-0a2a0a5409dd-0a2a450cc41e-44 for ; Thu, 08 Oct 2026 12:16:55 +0200 Received: from [210.118.77.11] (helo=mailout1.w1.samsung.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac76d95-f479-0a2a450c0019-d2764d0b8ddb-3 for ; Thu, 08 Oct 2026 12:16:54 +0200 Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20261008101653euoutp0199d22d6fe9bd4e2d748dfbbf669835df~chnrJlrZB3263932639euoutp01W for ; Thu, 8 Oct 2026 10:16:53 +0000 (GMT) Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20261008101650eucas1p2fa4adb7e7ece5173cba39c726300b64b~chnoAgJC60145601456eucas1p2Q; Thu, 8 Oct 2026 10:16:50 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20261008101649eusmtip2ee55bcf0281241017f5f2c9511114ef9~chnnP_ko_2421124211eusmtip2t; Thu, 8 Oct 2026 10:16:49 +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 mailout1.w1.samsung.com 20261008101653euoutp0199d22d6fe9bd4e2d748dfbbf669835df~chnrJlrZB3263932639euoutp01W DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1791454613; bh=mO4q4g0VGAokDsTnWCtbTL+H8XVcJzLn5OxmzhD0cdI=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=RyO+WNwUSfa24tfqEVn30FJVpxPoHsWDhqUoSf4SU6BUSj7n+E4ksCk0UftGrFtMJ epit+ff7Tyb2DfzpNjpAsUNl9hVBaVijdfNpwW+7ADftqkOShT6EwtJQATn+uOo/eb zfvVoWbPNEj4cEqDsviDE4pEITEe5ASd/J1DZfbY= Message-ID: <04643c93-7d1b-49f6-870e-15c4c7306a05@samsung.com> Date: Thu, 8 Oct 2026 12:16:48 +0200 MIME-Version: 1.0 User-Agent: Betterbird (Windows) Subject: Re: [PATCH] swiotlb: fix default_swiotlb_limit() for non-growable default pool To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: Robin Murphy , Christoph Hellwig , Petr Tesarik , Andreas Greve , James Dingwall Content-Language: en-US From: Marek Szyprowski In-Reply-To: <20261005070518.1590097-1-m.szyprowski@samsung.com> Content-Transfer-Encoding: 8bit X-CMS-MailID: 20261008101650eucas1p2fa4adb7e7ece5173cba39c726300b64b X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20261005070528eucas1p18d16ec6ecc4e879d0adc66538122132c X-EPHeader: CA X-CMS-RootMailID: 20261005070528eucas1p18d16ec6ecc4e879d0adc66538122132c References: <20261005070518.1590097-1-m.szyprowski@samsung.com> X-purgate-ID: tlsNG-d25034/1791454614-038D5A5B-19A7FCBD/0/0 X-purgate-type: clean X-purgate-size: 2354 On 05.10.2026 09:05, Marek Szyprowski wrote: > Commit ad96ce3252db ("swiotlb: determine potential physical address > limit") changed default_swiotlb_limit() to return the maximum physical > address that could ever be used by dynamically allocated pools, so that > the value stays constant when CONFIG_SWIOTLB_DYNAMIC=y. However, > io_tlb_default_mem.phys_limit is returned even when the default pool > cannot grow, e.g. when swiotlb_init_remap() is called with a remap > callback. > > This breaks Xen dom0 on x86: pci_xen_swiotlb_init() passes SWIOTLB_ANY > and xen_swiotlb_fixup(), so phys_limit is set to the top of dom0 memory, > although xen_swiotlb_fixup() makes the default pool below the 32-bit > boundary. xen_swiotlb_dma_supported() then rejects 32-bit DMA masks, > even though the bounce buffer is perfectly usable by such devices. > > Return phys_limit only if the default pool can actually grow, otherwise > report the real end of the default pool, like in the > !CONFIG_SWIOTLB_DYNAMIC case. > > Reported-by: Andreas Greve > Reported-by: James Dingwall > Fixes: ad96ce3252db ("swiotlb: determine potential physical address limit") > Closes: https://lore.kernel.org/xen-devel/f74668db-52fd-4575-8372-7bfdf10d62ac@a-greve.de/ > Cc: stable@vger.kernel.org > Assisted-by: Claude Opus 5.5 (1M context) > Signed-off-by: Marek Szyprowski Applied to dma-mapping-fixes with additional "Tested-by: James Dingwall" tag, which I've received on priv. > --- > kernel/dma/swiotlb.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c > index aa2f1c4588b9..5edea93ec635 100644 > --- a/kernel/dma/swiotlb.c > +++ b/kernel/dma/swiotlb.c > @@ -1844,10 +1844,10 @@ 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; > -#else > - return io_tlb_default_mem.defpool.end - 1; > + 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 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From xen-devel-bounces@lists.xenproject.org Thu Oct 08 10:17:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 10:17:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443137.1660531 (Exim 4.92) (envelope-from ) id 1xElC6-0001gp-64; Thu, 08 Oct 2026 10:17:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443137.1660531; Thu, 08 Oct 2026 10: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 1xElC6-0001gi-3K; Thu, 08 Oct 2026 10:17:46 +0000 Received: by outflank-mailman (input) for mailman id 1443137; Thu, 08 Oct 2026 10:17:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xElC4-0001fM-Pn for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:17:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xElC3-00C6V1-Lg for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:17:43 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac76db8-2eae-0a2a0a5409dd-0a2a4501b4a2-46 for ; Thu, 08 Oct 2026 12:17:43 +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 6ac76dc2-5984-0a2a45010019-c387df82afea-3 for ; Thu, 08 Oct 2026 12:17:38 +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 08BEF21BD4; Thu, 8 Oct 2026 10:17: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 89F351339F; Thu, 8 Oct 2026 10:17:36 +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 fZ8YGMBtx2oQNQAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 10:17: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=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=1791454657; 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=tnPI19hLzgDy/8vZeUAaHQ4NBdptenN6dYiOPf1FfNY=; b=p7LDQVD6h9GmmPYZJ/+F0QrV8wDZ7eJ2zOSajStw80zlhkvZiLJUmXGge13dPEIauzn7to gf5v+A7jNwFP2F5l/2AfZOHn6Dnr01ADlrNXiVJv3qLKQZzqH2Fu9ItLKJX/xIIfRLt7Pb 0d9TCY1MHApJtgxcn/pq7OQsy5vG2XM= Authentication-Results: smtp-out1.suse.de; dkim=none Message-ID: <2388e2e3-c1dc-4cfe-8e94-2ce224a95ea5@suse.com> Date: Thu, 8 Oct 2026 12:17:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails To: Josef Bacik , Stefano Stabellini , Oleksandr Tyshchenko , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: xen-devel@lists.xenproject.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.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: <20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------5i0eKVeuAtbb10q82x9pH0HV" X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [6.20 / 50.00]; NEURAL_SPAM_LONG(3.50)[1.000]; BAYES_HAM(-3.00)[99.99%]; NEURAL_SPAM_SHORT(3.00)[0.999]; R_DKIM_NA(2.20)[]; SIGNED_PGP(-2.00)[]; SUSPICIOUS_RECIPS(1.50)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; XM_UA_NO_VERSION(0.01)[]; MX_GOOD(-0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCPT_COUNT_TWELVE(0.00)[12]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[netdev]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; HAS_ATTACHMENT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:email,toxicpanda.com:email] X-Spamd-Bar: ++++++ X-Rspamd-Queue-Id: 08BEF21BD4 X-Spam-Flag: NO X-Spam-Score: 6.20 X-Spam-Level: ****** X-Rspamd-Action: no action X-purgate-ID: tlsNG-d62444/1791454658-1E07B757-ED9E3E35/35/110847 X-purgate-type: clean X-purgate-size: 7321 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5i0eKVeuAtbb10q82x9pH0HV Content-Type: multipart/mixed; boundary="------------QedACrEh28nuHxKLS3RQdjN0"; protected-headers="v1" From: Juergen Gross To: Josef Bacik , Stefano Stabellini , Oleksandr Tyshchenko , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: xen-devel@lists.xenproject.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Message-ID: <2388e2e3-c1dc-4cfe-8e94-2ce224a95ea5@suse.com> Subject: Re: [PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails References: <20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.com> In-Reply-To: <20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.com> --------------QedACrEh28nuHxKLS3RQdjN0 Content-Type: multipart/mixed; boundary="------------Lu8eVUG7qHd0a0zC9G7vrqdi" --------------Lu8eVUG7qHd0a0zC9G7vrqdi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDcuMTAuMjYgMTk6NTcsIEpvc2VmIEJhY2lrIHdyb3RlOg0KPiBXaGVuIGEgcmVzcG9u c2UgY2hhaW4gaGFzIG1vcmUgc2xvdHMgdGhhbiBmaXQgaW4gdGhlIHNrYidzIGZyYWdzLA0K PiB4ZW5uZXRfZmlsbF9mcmFncygpIHJldHVybnMgYW4gZXJyb3IgYW5kIHhlbm5ldF9wb2xs KCkganVtcHMgdG8gaXRzDQo+IGVycm9yIHBhdGguICBUaGF0IHBhdGggbW92ZXMgd2hhdCdz IGxlZnQgb24gdG1wcSB0byBlcnJxIHRvIGJlIGZyZWVkLA0KPiBidXQgdGhlIHNrYiBiZWlu ZyBmaWxsZWQgd2FzIGFscmVhZHkgZGVxdWV1ZWQgZnJvbSB0bXBxLCBzbyBpdCdzIG5ldmVy DQo+IGZyZWVkLiAgRWFjaCBjaGFpbiB0aGF0IG92ZXJmbG93cyBsZWFrcyB0aGUgc2tiIGFu ZCB0aGUgcGFnZXMgYXR0YWNoZWQNCj4gdG8gaXQgYXMgZnJhZ3MsIGFuZCB0aGUgYmFja2Vu ZCBkZWNpZGVzIGhvdyBtYW55IHNsb3RzIGl0IHNlbmRzLg0KPiANCj4gUHV0IHRoZSBza2Ig YmFjayBvbiB0bXBxIGJlZm9yZSB0YWtpbmcgdGhlIGVycm9yIHBhdGgsIGxpa2UgdGhlDQo+ IHhlbm5ldF9zZXRfc2tiX2dzbygpIGZhaWx1cmUganVzdCBhYm92ZSBpdCBkb2VzLg0KPiAN Cj4gRml4ZXM6IGFkNGYxNWRjMmM3MCAoInhlbi9uZXRmcm9udDogZG9uJ3QgYnVnIGluIGNh c2Ugb2YgdG9vIG1hbnkgZnJhZ3MiKQ0KPiBDYzogc3RhYmxlQHZnZXIua2VybmVsLm9yZw0K PiBBc3Npc3RlZC1ieTogTExNDQo+IFNpZ25lZC1vZmYtYnk6IEpvc2VmIEJhY2lrIDxqb3Nl ZkB0b3hpY3BhbmRhLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9z c0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo= --------------Lu8eVUG7qHd0a0zC9G7vrqdi 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----- --------------Lu8eVUG7qHd0a0zC9G7vrqdi-- --------------QedACrEh28nuHxKLS3RQdjN0-- --------------5i0eKVeuAtbb10q82x9pH0HV 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/Ey8FAmrHbcAFAwAAAAAACgkQsN6d1ii/Ey/2 wQf/f4VI4Q18cBoaYxYxMSUNsRsMwy067gRvNxNYIH20fKQdf5yh8JFs3HUzWTBlxxFMGqisPbOF 9+0WK2eAFa8dGLBfYeLNlPgds+cxT7ihcbV8ryIkY8RaCxl+DEH103g1HsvAPBlEfZNQQKwokRAb IFM/u6Am89j2pglQojNPIgfqxpHXVYuKJMwNhzXHdX/UWZ4DGXiW+cbmBac3x+Y92R4tkTByYSvc 0Q07hFeAFRfn3Q0QsoItcQinqR74HIpJelLkXBKaxcFw5fw/HGXdCe+Qm59966pgDpBRgkuzV5tw MXS1Cv+qzDXqorqNpXyiwc2NZ/5ldSnrd/byJPYfsg== =vIex -----END PGP SIGNATURE----- --------------5i0eKVeuAtbb10q82x9pH0HV-- From xen-devel-bounces@lists.xenproject.org Thu Oct 08 10:33:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 10:33:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443153.1660557 (Exim 4.92) (envelope-from ) id 1xElRU-00058y-KJ; Thu, 08 Oct 2026 10:33:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443153.1660557; Thu, 08 Oct 2026 10:33: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 1xElRU-00058r-Gv; Thu, 08 Oct 2026 10:33:40 +0000 Received: by outflank-mailman (input) for mailman id 1443153; Thu, 08 Oct 2026 10:33:39 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xElRT-00058h-1X for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:33:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xElRS-003D3T-4G for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:33:38 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac77179-e002-0a2a0a5209dd-0a2a4501ab0a-30 for ; Thu, 08 Oct 2026 12:33:38 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac77181-5984-0a2a45010019-c387df83ebba-3 for ; Thu, 08 Oct 2026 12: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 23FF31F441; Thu, 8 Oct 2026 10:33: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 9248A136DC; Thu, 8 Oct 2026 10:33: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 MYidHH9xx2rsRQAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 10:33: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-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1791455616; 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=gbr1u+u80m70NFdYTGfZHIyUnPU4YMbmIwhVKiS1bl4=; b=NnJ8RDl51A5KdqM2QzEUDmI4KLpTAF2kavp0tkeSL7YBnlNS+VZKpRfeBlEtqLrGF67RDb MHKv0BlQ2G9z4ZqJcDKF8LbgsgqFLlSF0GYYQ1jQKerVloJnnVZf8ZcTGpFvX3Pg9MFuXZ clz2H+okBiB2Ep0BBweesZTpDLznvy0= Authentication-Results: smtp-out2.suse.de; dkim=none Message-ID: Date: Thu, 8 Oct 2026 12:33:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/pcifront: check that an AER callback exists before calling it To: Yehyeong Lee , sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, bhelgaas@google.com, jbeulich@suse.com, konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org References: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr> 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: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8gctMZysacNUg04EXglOdQFe" X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [4.53 / 50.00]; NEURAL_SPAM_LONG(3.50)[1.000]; BAYES_HAM(-3.00)[100.00%]; NEURAL_SPAM_SHORT(2.83)[0.943]; R_DKIM_NA(2.20)[]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; XM_UA_NO_VERSION(0.01)[]; MX_GOOD(-0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[10]; MID_RHS_MATCH_FROM(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:email,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,korea.ac.kr:email] X-Spamd-Bar: ++++ X-Rspamd-Queue-Id: 23FF31F441 X-Spam-Flag: NO X-Spam-Score: 4.53 X-Spam-Level: **** X-Rspamd-Action: no action X-purgate-ID: tlsNG-d62444/1791455617-1DA7E757-515B0F6C/35/110847 X-purgate-type: clean X-purgate-size: 9527 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8gctMZysacNUg04EXglOdQFe Content-Type: multipart/mixed; boundary="------------6rtO6HI61SAhPorWYYQy3SMb"; protected-headers="v1" From: Juergen Gross To: Yehyeong Lee , sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, bhelgaas@google.com, jbeulich@suse.com, konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Message-ID: Subject: Re: [PATCH v2] xen/pcifront: check that an AER callback exists before calling it References: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr> In-Reply-To: <20261006023443.338194-1-yhlee@isslab.korea.ac.kr> 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= --------------6rtO6HI61SAhPorWYYQy3SMb Content-Type: multipart/mixed; boundary="------------pwuvVF7TOmy7zbxc0yi1FJKI" --------------pwuvVF7TOmy7zbxc0yi1FJKI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYuMTAuMjYgMDQ6MzQsIFllaHllb25nIExlZSB3cm90ZToNCj4gcGNpZnJvbnRfY29t bW9uX3Byb2Nlc3MoKSBoYW5kbGVzIGFuIEFFUiByZXF1ZXN0IGZyb20gdGhlIGJhY2tlbmQg YnkNCj4gZGlzcGF0Y2hpbmcgb24gYWVyX29wLmNtZCB0byB0aGUgYm91bmQgZHJpdmVyJ3Mg UENJIGVycm9yIGhhbmRsZXIuICBJdA0KPiBvbmx5IGNoZWNrcyB0aGF0IGVycl9oYW5kbGVy IGFuZCBlcnJfaGFuZGxlci0+ZXJyb3JfZGV0ZWN0ZWQgYXJlIHByZXNlbnQsDQo+IHRoZW4g Zm9yIHRoZSBtbWlvX2VuYWJsZWQsIHNsb3RfcmVzZXQgYW5kIHJlc3VtZSBjb21tYW5kcyBp dCBjYWxscyB0aGUNCj4gY29ycmVzcG9uZGluZyBjYWxsYmFjayB1bmNvbmRpdGlvbmFsbHku ICBUaG9zZSB0aHJlZSBjYWxsYmFja3MgYXJlDQo+IG9wdGlvbmFsIC0tIHRoZSBQQ0kgY29y ZSBOVUxMLWNoZWNrcyBlYWNoIG9mIHRoZW0gaW5kaXZpZHVhbGx5IGJlZm9yZQ0KPiB1c2Ug LS0gYW5kIG1hbnkgZHJpdmVycyAoZm9yIGV4YW1wbGUgaWdiLCBpZ2MsIGljZSBhbmQgaXhn YmV2ZikgaW5zdGFsbA0KPiBlcnJvcl9kZXRlY3RlZCB3aXRob3V0IGFsbCBvZiB0aGVtLg0K PiANCj4gYWVyX29wLmNtZCBjb21lcyBmcm9tIHRoZSBzaGFyZWQgcmluZywgc28gYSBtYWxp Y2lvdXMgb3IgYnVnZ3kgYmFja2VuZA0KPiBjYW4gc2VuZCBYRU5fUENJX09QX2Flcl9tbWlv IChvciBfc2xvdHJlc2V0L19yZXN1bWUpIGZvciBhIGRldmljZSB3aG9zZQ0KPiBkcml2ZXIg bGVhdmVzIHRoYXQgY2FsbGJhY2sgTlVMTCBhbmQgbWFrZSB0aGUgZnJvbnRlbmQgY2FsbCB0 aHJvdWdoIGENCj4gTlVMTCBwb2ludGVyLCBjcmFzaGluZyB0aGUgZ3Vlc3QuDQo+IA0KPiBD aGVjayBlYWNoIGNhbGxiYWNrIGJlZm9yZSBjYWxsaW5nIGl0LiAgV2hlbiBtbWlvX2VuYWJs ZWQgb3Igc2xvdF9yZXNldCBpcw0KPiBhYnNlbnQsIHJldHVybiBQQ0lfRVJTX1JFU1VMVF9S RUNPVkVSRUQgc28gcmVjb3ZlcnkgcHJvY2VlZHMsIGFzIHRoZSBQQ0kNCj4gY29yZSBkb2Vz IGZvciBhIG1pc3NpbmcgY2FsbGJhY2s7IHJldHVybmluZyBQQ0lfRVJTX1JFU1VMVF9OT05F IHdvdWxkDQo+IGluc3RlYWQgbWFrZSB4ZW4tcGNpYmFjayB0ZWFyIHRoZSBndWVzdCBkb21h aW4gZG93bi4NCj4gDQo+IEZpeGVzOiA5NTZhOTIwMmNkMTIgKCJ4ZW4tcGNpZnJvbnQ6IFhl biBQQ0kgZnJvbnRlbmQgZHJpdmVyLiIpDQo+IENjOiBzdGFibGVAdmdlci5rZXJuZWwub3Jn DQo+IFNpZ25lZC1vZmYtYnk6IFllaHllb25nIExlZSA8eWhsZWVAaXNzbGFiLmtvcmVhLmFj LmtyPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0K DQoNCkp1ZXJnZW4NCg== --------------pwuvVF7TOmy7zbxc0yi1FJKI 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----- --------------pwuvVF7TOmy7zbxc0yi1FJKI-- --------------6rtO6HI61SAhPorWYYQy3SMb-- --------------8gctMZysacNUg04EXglOdQFe 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/Ey8FAmrHcX8FAwAAAAAACgkQsN6d1ii/Ey9s Vwf9HRlL7X7EoZ/5DXTpuK59X/4TndaeW2HGoPGrzPzsqLw5jW7om6qB6QAOpy3S6OyI22T6nFdh 2nYnzhF3+urGGpqwcF8409TqxXJPxUjOH0ycNkdwP0qJ2+7UlHA8JoLUXMOnrRreuEBuQGGWXnVO pdwiTuFiizRyq3nocUyc65gQY/x/8zDApoeba/kA6N8E6g1FwpICBE08u1NRJ8TILprZJ/unbePZ qGEU/XRbxpT+Zd4bH+qg1UvoL3DmfAy8XOXSmk/o0+RTfAY35rDjiGLLyyT1TBBTjM6oDgvoEtpK NjwQRPebqHHpLdWSOIchxJ2lAqeCoCln5/pkvFMjiA== =IJGy -----END PGP SIGNATURE----- --------------8gctMZysacNUg04EXglOdQFe-- From xen-devel-bounces@lists.xenproject.org Thu Oct 08 10:37:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 10:37:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443161.1660570 (Exim 4.92) (envelope-from ) id 1xElUp-0005tW-6d; Thu, 08 Oct 2026 10:37:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443161.1660570; Thu, 08 Oct 2026 10:37: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 1xElUp-0005tP-3z; Thu, 08 Oct 2026 10:37:07 +0000 Received: by outflank-mailman (input) for mailman id 1443161; Thu, 08 Oct 2026 10:37:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xElUo-0005sC-0j for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:37:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xElUn-000kGa-DR for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:37:05 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac77248-2eae-0a2a0a5409dd-0a2a450ab014-22 for ; Thu, 08 Oct 2026 12:37:05 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac77250-f2d2-0a2a450a0019-c387df83b986-3 for ; Thu, 08 Oct 2026 12:37:04 +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 53D0F1F441; Thu, 8 Oct 2026 10:37:03 +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 03FC51339F; Thu, 8 Oct 2026 10:37:02 +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 oh2aMk5yx2rwSQAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 10:37: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=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: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1791455823; 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=6LF2uQsgvY/fzl3eAWc6/iZ2APHLSLZu8+2XZlkFoAA=; b=W/K+h4iGfHSf/2qELGHqBCVMLWXJnK3sAaCy/ftEIDaV2G/vcVv2Rz3gXiEjKOk9SGIOdY cHqYCCTZappnG5jl3CjLOhb4PcbRY9s8L63/Uk7vOD383MwTf2oG9b4BlYgbPv87c1IIpU RkPCczZkXgUuf9RUDYevhhu0ALeXy+w= Message-ID: <576bbb3d-48a3-436c-b626-b0f2dd493a9e@suse.com> Date: Thu, 8 Oct 2026 12:37:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/privcmd: Only claim ioreqs matching an ioeventfd To: Koichiro Den , Viresh Kumar , Stefano Stabellini , Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20260821084112.2374949-1-den@valinux.co.jp> 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: <20260821084112.2374949-1-den@valinux.co.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------e46aryaWW0KyeUhbWDPpmWNY" X-Spamd-Result: default: False [0.00 / 50.00] X-Spamd-Bar: / X-Rspamd-Queue-Id: 53D0F1F441 X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spam-Level: X-Rspamd-Action: no action X-Spam-Score: 0.00 X-Spam-Flag: NO X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-purgate-ID: tlsNG-4011c0/1791455824-502F0CFC-3CB1C65A/35/110847 X-purgate-type: clean X-purgate-size: 7257 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------e46aryaWW0KyeUhbWDPpmWNY Content-Type: multipart/mixed; boundary="------------qu7IWwy8QFAhpVzf0SBiucwQ"; protected-headers="v1" From: Juergen Gross To: Koichiro Den , Viresh Kumar , Stefano Stabellini , Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Message-ID: <576bbb3d-48a3-436c-b626-b0f2dd493a9e@suse.com> Subject: Re: [PATCH] xen/privcmd: Only claim ioreqs matching an ioeventfd References: <20260821084112.2374949-1-den@valinux.co.jp> In-Reply-To: <20260821084112.2374949-1-den@valinux.co.jp> --------------qu7IWwy8QFAhpVzf0SBiucwQ Content-Type: multipart/mixed; boundary="------------LGUGRzYu6Aev1yfiF9nnrIok" --------------LGUGRzYu6Aev1yfiF9nnrIok Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjEuMDguMjYgMTA6NDEsIEtvaWNoaXJvIERlbiB3cm90ZToNCj4gVGhlIGlvZXZlbnRm ZCBoYW5kbGVyIHNoYXJlcyBpdHMgZXZlbnQgY2hhbm5lbCB3aXRoIHRoZSB1c2Vyc3BhY2Ug ZGV2aWNlDQo+IG1vZGVsLiBJdCBtdXN0IG9ubHkgY2xhaW0gcmVxdWVzdHMgdGhhdCBtYXRj aCBhIHJlZ2lzdGVyZWQgaW9ldmVudGZkLg0KPiBPdGhlciByZXF1ZXN0cyBhcmUgbGVmdCBm b3IgdXNlcnNwYWNlLg0KPiANCj4gaW9ldmVudGZkX2ludGVycnVwdCgpIGN1cnJlbnRseSBt YXJrcyBldmVyeSBNTUlPIHdyaXRlIElOUFJPQ0VTUyBiZWZvcmUNCj4gbG9va2luZyBmb3Ig YSBtYXRjaC4gRm9yIGFuIHVubWF0Y2hlZCByZXF1ZXN0IGl0IGRyb3BzIHRoZSBsb2NrIGFu ZA0KPiByZXN0b3JlcyBSRUFEWS4gVXNlcnNwYWNlIG1heSBzZWUgSU5QUk9DRVNTIGFuZCBz a2lwIGl0LiBSZXN0b3JpbmcgUkVBRFkNCj4gZG9lcyBub3Qgc2VuZCBhbm90aGVyIG5vdGlm aWNhdGlvbi4gSWYgdXNlcnNwYWNlIGhhbmRsZXMgdGhlIHJlcXVlc3QgYXQNCj4gdGhlIHNh bWUgdGltZSwgdGhlIFJFQURZIHN0b3JlIG1heSBvdmVyd3JpdGUgaXRzIHN0YXRlLg0KPiAN Cj4gRmluZCBhIG1hdGNoaW5nIGlvZXZlbnRmZCBiZWZvcmUgY2hhbmdpbmcgdGhlIHJlcXVl c3Qgc3RhdGUuDQo+IA0KPiBUaGUgbG9jayBub3cgcHJvdGVjdHMgb25seSB0aGUgaW9ldmVu dGZkIGxpc3QuIFVzZSBleHBsaWNpdCB2aXJ0XyptYigpDQo+IGJhcnJpZXJzIGZvciB0aGUg aW9yZXEgc2hhcmVkIHdpdGggWGVuLg0KPiANCj4gRml4ZXM6IGYwZDdkYjdiMzMyNCAoInhl bjogcHJpdmNtZDogQWRkIHN1cHBvcnQgZm9yIGlvZXZlbnRmZCIpDQo+IENjOiBzdGFibGVA dmdlci5rZXJuZWwub3JnDQo+IFNpZ25lZC1vZmYtYnk6IEtvaWNoaXJvIERlbiA8ZGVuQHZh bGludXguY28uanA+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3Vz ZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------LGUGRzYu6Aev1yfiF9nnrIok 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----- --------------LGUGRzYu6Aev1yfiF9nnrIok-- --------------qu7IWwy8QFAhpVzf0SBiucwQ-- --------------e46aryaWW0KyeUhbWDPpmWNY 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/Ey8FAmrHck4FAwAAAAAACgkQsN6d1ii/Ey/M ZQgAhkQLIt4TjQvAFXWfjlDCaBYqZUEB7jUItizu1VaYHKsmDNqz8Ys+xTvKCDBBnvlTLaXe3rbx AZyukz0JlgiE2cw+zeMnPe4GXt/xHCI3qXjyPz/p76bHSCNriViLWbyzrLGU5waW45m3HyE5zYZS diCx8hRHLqrexRaghbzoq3GiLib60CrvtT/PrXxdPKtsKlh5g8My5A1QlEMZ+me4L72G5FFPz0fL greynD0JpO6oLNVU45MedP1A3x10a3piEo92BTwre6Ez9Vb2efTbLoQ29qtOPOdeL8xHxBiQ41SH wjpAIGdbDFDrIbcOR2PjThuCpQoFrFoMsnvulZitKQ== =OQxM -----END PGP SIGNATURE----- --------------e46aryaWW0KyeUhbWDPpmWNY-- From xen-devel-bounces@lists.xenproject.org Thu Oct 08 10:51:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 10:51:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443173.1660583 (Exim 4.92) (envelope-from ) id 1xEliI-0000dv-D0; Thu, 08 Oct 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 1443173.1660583; Thu, 08 Oct 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 1xEliI-0000do-9m; Thu, 08 Oct 2026 10:51:02 +0000 Received: by outflank-mailman (input) for mailman id 1443173; Thu, 08 Oct 2026 10:51:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEliG-0000dh-Px for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 10:51:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEliF-00FZXD-Hd for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:50:59 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7758b-8faa-0a2a0a5109dd-0a2a45019448-34 for ; Thu, 08 Oct 2026 12:50:59 +0200 Received: from [52.101.46.42] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac77591-5984-0a2a45010019-34652e2add0a-3 for ; Thu, 08 Oct 2026 12:50:58 +0200 Received: from SJ0PR05CA0027.namprd05.prod.outlook.com (2603:10b6:a03:33b::32) by LV5PR12MB9803.namprd12.prod.outlook.com (2603:10b6:408:306::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Thu, 8 Oct 2026 10:50:53 +0000 Received: from MWH0EPF000A6730.namprd04.prod.outlook.com (2603:10b6:a03:33b:cafe::6b) by SJ0PR05CA0027.outlook.office365.com (2603:10b6:a03:33b::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Thu, 8 Oct 2026 10:50:52 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MWH0EPF000A6730.mail.protection.outlook.com (10.167.249.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Thu, 8 Oct 2026 10:50:51 +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, 8 Oct 2026 05:50:46 -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, 8 Oct 2026 05:50:46 -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; Thu, 8 Oct 2026 05:50: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=k1SRXK2wozQzq5LknsY0Txf+Qz/6fb/aK++S9hdCAtlfxC4kueHKTQHnNGKv34hHeRCVyfVcgkUJhM1fksVbPFp2vVf68EhZdGT6STbwa91QXDKq6yWaBTAqjlsaPPi0ZI5BahPZji7SviLjIJnDuja76DwFMXRnaDhCtGU/stybT/OSvxDq0KdjOCNJQ9vdBhjb9x9fDN1WcmMhCEZ+TKjDHW4RVOKIuWTGBMamM0zdRZaYG0ny2BBDYPUuo911WKgiW7hF6kPrOy4NfbdeQyaRNsqLRfaf54BfzX5PxsthHzBkkLvJPt1AY0TQt86VmzdDAHJBW61JrqhxIOC2ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=itRferSoPV/YznOfLEimJZClMaBcIE/n/2WyuD6Dgls=; b=KqWa7rYa9M5sPzDiFZNMWOC2rhKE72w182fw1ONGhqTkhRwiXhzcLlVARBi9K9VSW7ocnQGMUct1plPK0QiYoHoX9ZdPsiQkn9zsv2erQuYQVhsyFlfO+IuZwJZ2CAp+0j3osA89vi411KIqfscbzUq0hLJpd0FGBmV2naMTg1X60Ta5IFFGaxpKTswlJwkEPw5N6GlXd0LP3LlL+Zq6VJOiHoG/PRpZI6aORG4Okgo03WV0+o92yiMN5uSrGM+1U+dRkSH1I4WG2+vqKmfMPVbw2ynmIqpaIxxXQF8ZMHYkU6//ST0l9JV9xYYr48g2kxBCwbLJ+AJd77Mo93m1KA== 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=itRferSoPV/YznOfLEimJZClMaBcIE/n/2WyuD6Dgls=; b=eITPl37UHwTVGDnZWQggNOSAGHU1SB6+kPivGHiv7JAvqY+68Rr9nqPQNrNR8JDEdapLOYURLeAuK2lPadPCIBdhrOhjF7RzLWVqkpZuarzEVtA6VLLrDj/FJU8pB3U2HY1PsUZtIGu/zRFN4kgjjmCuwrYoQqCIFvOz7jyyilk= 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: <9a4f56d4-4c2e-4d5a-8489-9300170729a3@amd.com> Date: Thu, 8 Oct 2026 12:50:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Fix under-mapping in map_range_to_domain() To: "Grall, Julien" , CC: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20261007135848.220047-1-michal.orzel@amd.com> <055dc887-0cfd-4274-a5f6-e5afdd576746@xen.org> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <055dc887-0cfd-4274-a5f6-e5afdd576746@xen.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A6730:EE_|LV5PR12MB9803:EE_ X-MS-Office365-Filtering-Correlation-Id: c1a371bb-a2e2-4ba3-8040-08df252a0565 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|36860700016|82310400026|1800799024|56012099006|4143699003|11063799006|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: lh5VxvjN1iieq2v+Z4Cw+k/UFgBXQ61nc143cU1YbK081L4g+XbVl8WDZnSvJaO8KubvDdAwDeQB+eoRbx4tGAEqoNRkMsn4KyWJN1g8fDnsmJm0jg/pCw8/jvRgz4ayHa5Tphud5obOLhmdWDzX0v/Us4x6ApdOs5cUMNDM2Hrplz3fTaa8zQYKnrGB+uLSLn3fzqPPmIJ+JzvNA6t3LibSEnoVUUqaK1Ta0x6s3Sb6cZV1TBMbpXdzi3rI0ePKYGTNrdoyHvG6XP7sKKEbZwIf/IO0MAbwSp4gsOl9d7YswGgyITzoMOyZvnRDHJbDNqLA/jP8RfqA5khKvrwe2NFFnlatKMR7Ck+Ru9XDwbNXzw0cuDIYV2Ro389VoK8Pf2g3rWJ39LWPgWm2OzoueRSU1n8EoWqlb8MYdgVT10QlG9U7c2NwrKOoSmn/WNVURN46o2+IDy7Yp3TOLBchP5m4GudTnPbXNoyotA7hMvC5iZQMD9KZpFWc9hhWbeClfJyBsDMG6BkC8BtQrMd9BIcyk7frmlIFXyx86Od+Z5tYmu45SK6EArpIoHc+qiWDn9BasK+7Ldu2ozcCeVlDO0/quk0HMzV60ASkLypDNNR2FNii22YJyFbWmo8xDh67+PGvte6NEf+NvJnRESjjkBhH5P1WaAHlWigHKhY/GndxEEhf8OmMdpDSkvYBoVcSXCET0COpU9zvX7gTCeWb6Q== 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)(82310400026)(1800799024)(56012099006)(4143699003)(11063799006)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: NTaX32knXQ8j3Bylg8BektLxlUBqANL9osIfaApblP3ZCUjEN27KvexvFgK3m8Cnd93A68gH+hsxJrsSmNflJ9o46ap6c64RLoVROBBfKGvJ/VXQNMIvEFd9ngkRq2sPd+ZD51EgRPIdT43yQhfsBoLSTuvnRs7Zv7kunsKw0H0Pno7wcgViHZcOKMJUJwV84E6fBI6bLVq/sjA8vVdLBa02N8w25FEDxTqRhWNKRJlIzy582MdcHvtKPeaBSuA8ImRoQvmKwEYzUK+W8Q1Xcb5/rL4iNQxZfh/X9rqdB2jhUsK1KEEASyJkKSiClU4/uvOIGoyhMoKTF8zLdKBxMrks0Ayv4+9pBo3ENTZAFJMA/2+XnqC82Tkzb6Ff9NS+/tOEDmWeaQIY4Rd1JF3M+/JG1me/m+pDUL06fuYH766Bcglr/a5+pBQvFuacXhUX X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2026 10:50:51.7951 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c1a371bb-a2e2-4ba3-8040-08df252a0565 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: MWH0EPF000A6730.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR12MB9803 X-purgate-ID: tlsNG-d62444/1791456659-BCD44757-28C80CD8/0/0 X-purgate-type: clean X-purgate-size: 2368 On 07-Oct-26 22:20, Grall, Julien wrote: > Hi Michal, > > On 07/10/2026 15:58, Michal Orzel wrote: >> If the memory region to be mapped does not start at the page boundary >> and its end spans over the page boundary, map_range_to_domain() passes >> a number of pages that is short by one to map_regions_p2mt(). Domain's >> attempt to access memory within that page will fail. Fix it by calculating >> the number of pages to be mapped taking into account the start offset. > > Can you provide an example where the caller doesn't suitably align? Sure. Example is handle_device() being called on the hwdom DTB creation time for a node whose address is not page aligned i.e. /reserved-memory node or basically any node, given that DT spec does not mention anything about memory region alignment and there are existing DTs like that. With reg = <0x0 0x800 0x0 0x1000>, today we only map 0x0-0xfff and an access to 0x1000-0x17ff faults. > >> >> Fixes: 88c10b0d6eee ("arch/arm: let map_mmio_regions() use start and count") >> Signed-off-by: Michal Orzel > > The fix LGTM in the current context. However given map_range_to_domain() > is now used in more places (e.g. overlay), I wonder whether this is the > right decision to allow map_range_to_domain() with non-aligned region. > > Imagine a user say "I want to map 0x400 - 0x1000 to domain A and map > domain B "0x0 - 0x400". This could result to interesting behavior if the > user is not aware of the alignment (this would become even more > problematic if we decide to ever support different page granularity on Arm). I agree this is not great, but this is not something introduced here: iomem_permit_access() and the iomem_ranges rangeset already cover whole pages and we already map the full first page. This patch only makes the p2m mapping match what we already allow. I don't think we can reject unaligned regions in map_range_to_domain() though, as the host DT is not under our control and hwdom would fail to boot on platforms with sub-page devices. I asked AI to look at the Linux boards for Arm and Arm64 (140 boards in total with unaligned regions) and even the boards we claim to support have nodes that would fail: - RPI4: hdmi@7ef00700, <0x7ef01f00 0x400> - IMX8QXP: clock-controller@5b290004, <0x5b290004 0x10000> ~Michal From xen-devel-bounces@lists.xenproject.org Thu Oct 08 11:04:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 11:04:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443190.1660592 (Exim 4.92) (envelope-from ) id 1xElv5-0002bn-DE; Thu, 08 Oct 2026 11:04:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443190.1660592; Thu, 08 Oct 2026 11:04: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 1xElv5-0002bg-AU; Thu, 08 Oct 2026 11:04:15 +0000 Received: by outflank-mailman (input) for mailman id 1443190; Thu, 08 Oct 2026 11:04:14 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xElv4-0002ba-BS for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:04:14 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xElv3-003BWA-2S; Thu, 08 Oct 2026 11:04: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 1xElv3-009oBp-1J; Thu, 08 Oct 2026 11:04: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=ngGCyRPdLWaA1HcZq2VYElzwvYRaginNeAyaLOLh6bg=; b=beHsGFXI2m3keavbJNghEizx56 FMNyMQCSqSg22Dv9hBiGAhaHxvAbx8ZL+96q7VQC36KJtYkNvYHALuXhJ6hwtyRdUKN3bLKx3U9GW GxkjAQ29kzwPUutnX6y7s+OT417DwkLBIjs1LhOMOu+C/dB7ao6ujaZKxP8uJrt20bTs=; Date: Thu, 8 Oct 2026 13:03:59 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 10/18] x86/domain_page: don't unmap a mapcache entry that is not present Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-11-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-11-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:43AM +0100, George Dunlap wrote: > Mappings must be torn down by the vCPU that created them, and only > once. Have unmap_domain_page() check that the entry it is handed is > present and bail out otherwise (ASSERT_UNREACHABLE()), rather than read > an MFN out of an empty PTE and act on it, as a second unmap of an entry > the first one zapped would. (A second unmap of an entry the maphash > kept is caught, as before, only by the refcount ASSERT() in debug > builds.) > > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné > --- > Changes in v3: > - New in this version, split out of "x86/hvm: introduce per-vCPU > mapcache for vCPU-PT domains" for review. > --- > xen/arch/x86/domain_page.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > index f91ec8a75a..708df90a00 100644 > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -230,6 +230,16 @@ void unmap_domain_page(const void *ptr) > ASSERT(cache->inuse); > > idx = PFN_DOWN(va - MAPCACHE_VIRT_START); > + /* > + * Mappings must be unmapped once, by the vCPU that created them. With > + * nothing present there is nothing to tear down: leave the hash and the > + * bitmaps alone rather than act on a stale or foreign pointer. The comment makes more claims that what can be checked for: there's no check that the unmap is being done by the same vCPU that created it, neither is easy to add one. Any mismatch like that would become more obvious once we switch to a per-vCPU mapcache. I would possibly reduce the comment to: /* Ensure the entry to unmap is populated. */ The commit message already have the lengthily details. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 11:10:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 11:10:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443197.1660600 (Exim 4.92) (envelope-from ) id 1xEm0e-0003K7-Vb; Thu, 08 Oct 2026 11:10:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443197.1660600; Thu, 08 Oct 2026 11:10: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 1xEm0e-0003K0-Sh; Thu, 08 Oct 2026 11:10:00 +0000 Received: by outflank-mailman (input) for mailman id 1443197; Thu, 08 Oct 2026 11:09:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEm0d-0003Ju-Rs for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:09:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEm0d-003BcX-1X for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:09:59 +0000 Received: from mail-lj1-f169.google.com ([209.85.208.169]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xEm0d-009qdD-1O for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:09:59 +0000 Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-3a76ac0bdafso4588481fa.1 for ; Thu, 08 Oct 2026 04:09: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" 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=XXwEq2jkEw3cHBn/lYvFEYcp02xt6GrgrRtn3to52sg=; b=B0M2CbRZCcued7RS2dhpT4mPoJ 6ITX4rBBI6QjTtiKgjJffNGUeLxvrJ48Kyhw/vJPo3PdIAORDkdgNNxQWFTfjrJB1MkZvemOIA5XN mQqulKc+2bzysRW8B8UPKiXCNGl2/nHbWI3i+bJOewdXlTiYZMShaMLfmmM5VtxplUVg=; X-Gm-Message-State: AFq9FYJsJCDn6EE9OPkbmHnv+7khwBvMsTGQm9KEfkXii+BhKPucWyBl C1GSMVvYY0y3MfckPbawmTQDTfy1xCKvjydUdU0/f1B4+A8yoHIJy5hTP7JX0wZKNupgODTiNQy XkJCEgcxb98xv+fGvC3/h2nJ0ccq22fI= X-Received: by 2002:a2e:8b8e:0:b0:3a6:6e61:2887 with SMTP id 38308e7fff4ca-3a9ae46553bmr4296861fa.1.1791457798346; Thu, 08 Oct 2026 04:09:58 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-2-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Thu, 8 Oct 2026 12:09:45 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8JkFHQBCJhfFEW2qfskbg9BL7uxifZZaRbUZ0VUf7FQe6olxlBwR3FO38 Message-ID: Subject: Re: [PATCH v3 01/18] x86/PoD: map one page at a time in p2m_pod_zero_check() To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2026 at 1:38=E2=80=AFPM Andrew Cooper wrote: > > On 07/10/2026 11:40 am, George Dunlap wrote: > > diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c > > index 4602c32cff..0b0beca15a 100644 > > --- a/xen/arch/x86/mm/p2m-pod.c > > +++ b/xen/arch/x86/mm/p2m-pod.c > > @@ -911,7 +912,12 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const g= fn_t *gfns, unsigned int count > > if ( paging_mode_shadow(d) ) > > max_ref++; > > > > - /* First, get the gfn list, translate to mfns, and map the pages. = */ > > + /* > > + * First, get the gfn list, translate to mfns, and pick the pages = to > > + * check. They are mapped one at a time below, as in > > + * p2m_pod_zero_check_superpage(): a vCPU can hold only a few tran= sient > > + * mappings at once, and the p2m lookups and updates here need som= e too. > > + */ > > Actually, I think this wants almost entirely dropping. Yes, "and maps > the pages." needs editing, and should probably say "and check for being > a plausible candidate" or so, which was missing previously. > > The rest is a justification of why we do mapping in the same way we do > it generally, and not useful to have in the source code. Yes, sorry about the verbose comment, I forgot to go back and give this a more detailed review. I'll trim back the comment. Re the bool array: I assumed the compiler would turn that into a bitmask. That not being the case, I'll switch to bitops. Thanks, -George From xen-devel-bounces@lists.xenproject.org Thu Oct 08 11:19:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 11:19:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443209.1660610 (Exim 4.92) (envelope-from ) id 1xEm9t-0005Ak-Sp; Thu, 08 Oct 2026 11:19:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443209.1660610; Thu, 08 Oct 2026 11:19: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 1xEm9t-0005Ad-Pd; Thu, 08 Oct 2026 11:19:33 +0000 Received: by outflank-mailman (input) for mailman id 1443209; Thu, 08 Oct 2026 11:19:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEm9s-0005AS-F9 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:19:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEm9r-000t4p-Rw for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 13:19:31 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac77c29-8faa-0a2a0a5109dd-0a2a45079f56-44 for ; Thu, 08 Oct 2026 13:19:31 +0200 Received: from [52.101.85.45] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac77c41-b4ea-0a2a45070019-3465552d2051-3 for ; Thu, 08 Oct 2026 13:19:31 +0200 Received: from SJ0PR03CA0343.namprd03.prod.outlook.com (2603:10b6:a03:39c::18) by MN2PR12MB4174.namprd12.prod.outlook.com (2603:10b6:208:15f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Thu, 8 Oct 2026 11:19:24 +0000 Received: from SJ5PEPF000001D3.namprd05.prod.outlook.com (2603:10b6:a03:39c:cafe::64) by SJ0PR03CA0343.outlook.office365.com (2603:10b6:a03:39c::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Thu, 8 Oct 2026 11:19:24 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001D3.mail.protection.outlook.com (10.167.242.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Thu, 8 Oct 2026 11:19: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; Thu, 8 Oct 2026 06:19:18 -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; Thu, 8 Oct 2026 06:19:17 -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; Thu, 8 Oct 2026 06:19:15 -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=LBzXqK7UmbICItDxpd8o7hvmQRgOion1d1w6l8CHuA9LXqhmLCqlzMnAXd7jDcbE3gG/pWYK3QaI4Vvtvo6H4hO2flcmivmp3dmsIuLjudrSDeXjhhX7wfu+pfAOAe/NXuOaPTKM0JTnEOam8NmP+8It5VYtXpYaKoapKhYI8Zf3uWnzD/jqzQOV5gL6WukDnpfcekMwpPVGOtgunRIpNgZvuLVlmatR56i4XkhbILzT7luDJxJQj718A22TB94YjHPCkNkyKtXqBp8tkas3FuRHqMOfJyVz3V9MOGLKz6+jChxtKNW9kna/oPYMkb4tZ7VVVcWq5OGCSkyPKQsY/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=qLSse4rAU+6PCtYi9uC8Lbii33l9MhxK/pNybWLbHno=; b=cCV22iE0kJput2j09kEiQaqasZIo7ik6kkvvwouXUbeGcl5L2c7JuDnqTAKbREH3V4/YwtNJUDMx0ZxDFPoiZPaSKRv2c8d7HSwF9KtaRvx1D2yYNGEOKLjpYGtCcN0/DUPfcj2/3G/8bBLiMiZT8YG2RI15xVyzusavvXHHdB/6630aa5eU5fwmGMJrrBe4Ki2ULXIQYDx+nplgw053puEEQFdpK+gKZBNLLbco+S/HyoS7tL0uhAd5E3C5GdfU937tfkMk9TWlBkGt2Il2JO290U2eVn+dbp4huH0tRJ0v2PphmRBVzIU6KCzjHLxZclDYitUZf1pxYHKdeuSZ6A== 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=qLSse4rAU+6PCtYi9uC8Lbii33l9MhxK/pNybWLbHno=; b=x3YGgH5G8Dba6lK9zUGBJikFTimwDhAucH8cqd7o5jlQXlr/5diqW2Uq5sSf6HJNgVq9JRqu8k+i3B+dLBzHM8mBsozO4OwLksMgAeH3y5daCyzUF4ScQlZn2dYCxeAHNTEycbIosGMUBS5d2ji6Udze3O2MM09aO1A+lD+pIX8= 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: Thu, 8 Oct 2026 13:19:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/device-tree: move discard_initial_modules() to common code To: Oleksii Kurochko , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261001111630.112472-1-oleksii.kurochko@gmail.com> <20261001111630.112472-3-oleksii.kurochko@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261001111630.112472-3-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D3:EE_|MN2PR12MB4174:EE_ X-MS-Office365-Filtering-Correlation-Id: d63600c8-a1f0-4ba6-8428-08df252e01c7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|23010399003|82310400026|376014|7416014|4143699003|5023799004|11063799006|10067099003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 5bBKA7YGDOGnxGTGGwDgoAp7LQbPRN4UR0Ea2ladzMkCZfAAhFTTir6j9/wynbR74N60CCRVGZpi8EdXCsgORLl0Fd1BAnMkCcWhuERyEC8ikss+RGct+voWvQtLi2yv1mPfX2TEoCbIY64TX2sLfOONp3VLzaaKJ1h0ELofhDZ0tmSc4EQRAvQLQVHzOaAAriAR92gmb9f0X+dpDvoPmfz4ZexHnYznKRV5S6T20A+dZW7f3R9ljcqx6M1xAzaiSXQwrLk1nI8CESlnNXuUj4wcIJZl77qNRClFPDxFxhzhJS+AuQgBJUE/CoPCsjqpJTtjgFHpNaiwgzYDz4AAzAlBZGPyD5zBzQFVweXNv589XMXGfvwDRkDPqp5PL4+c4bn2ekep1rIE8S+vl6xbC1yKe9Fh+IUD9ELzr8LPPu2qOkEBWVWXCFUXhmQZpuJVyHYWpiSjNqLJlNupReySbcWxDvWqu/lG2nQ9U9JTkxbdQb6xkjv/o4PMIvYpPRsU06uSh7Iw0+VFWzA2ccGHNfxaB94EqKIkiM8TJXDHKUiK7kACVLgNBsN1y3vgvHx8lxCy9NdRIi/KdoIJ2zCGErgKUd3UgE54nRYH3u4fob1A0gz+7000QyilnzBRoZHcmWWQHLRtGsn8LxRcr0l0WXdrX+TzF47cBamlRjRx7xNTbwaGqHF337RTANKXxMq1CpP4sN5fq2ZVimDfl9OKsw== 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)(82310400026)(376014)(7416014)(4143699003)(5023799004)(11063799006)(10067099003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: X254T8ElKqszDK8Mw802WmQjXSC7C3YI0NcYBhWLdKD/fLnLSShIYjZnwuOXGDyuMO4Z363DQkt34e/5LtfSBx1eVhg4Mrci/n79w61x/PiZnW18Zx9nV2lSPlUkAfyQGA5oTi7V0+odhR7ogZolUm1yWHTJSJxQe14tK/q1ooe7qPxlDCgojTxOMGWZrGLswJPxhDiTLQD0Eae3fJctqPHPj5sg29IGjG4E6jehfv6nag6cPQSTA4pdUn/lIkwlc9uSm65ijO90Muu0KmPAsQKlK/OlLKlsiaM0VDmZ1JYBaQE608FisdXI1RdCqtW1urKl1kiqAIRdYXwdoz9y0xTd/GR/gt24m6fgCeGyJWW7u60W5ev6ImcAcOAGhnYdrxBHslcC0i8yS9H+IisCpAw/Yr2QdWzau4dT1DsFnT13O9wc2ORtYMy8x6IWHl1Z X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2026 11:19:23.7195 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d63600c8-a1f0-4ba6-8428-08df252e01c7 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: SJ5PEPF000001D3.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4174 X-purgate-ID: tlsNG-ef75cf/1791458371-A54C3AE4-55841F77/10/73395122804 X-purgate-type: spam X-purgate-size: 3547 On 01-Oct-26 13:16, Oleksii Kurochko wrote: > Everything discard_initial_modules() touches is already common code: > bootinfo.modules, using_static_heap and fw_unreserved_regions(). Move it > out of Arm into common/device-tree/bootinfo.c, next to the boot allocator > handling of the same memory, and declare it in xen/bootinfo.h, so that > other device-tree based architectures can reuse it instead of growing a > copy of their own. > > The arch-specific remove_early_mappings() is not moved along with it: > how the early FDT mapping is torn down is up to the architecture. As the > DTB is one of the boot modules being released, the mapping has to go once > they are discarded, so call it from start_xen() right after > discard_initial_modules(), which keeps the common function free of any > arch dependency. > > While moving it, use unsigned int for the loop counter and replace the > "goto out" by a plain return, as there is nothing left to do at the label. > > No functional change. > > Signed-off-by: Oleksii Kurochko > --- > xen/arch/arm/include/asm/setup.h | 2 -- > xen/arch/arm/setup.c | 35 ++----------------------------- > xen/common/device-tree/bootinfo.c | 30 ++++++++++++++++++++++++++ > xen/include/xen/bootinfo.h | 8 +++++++ > 4 files changed, 40 insertions(+), 35 deletions(-) > > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h > index c491c567298f..02fdf2b56c9c 100644 > --- a/xen/arch/arm/include/asm/setup.h > +++ b/xen/arch/arm/include/asm/setup.h > @@ -40,8 +40,6 @@ int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]); > > void create_dom0(void); > > -void discard_initial_modules(void); > - > void init_pdx(void); > void setup_mm(void); > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 16f899dff57b..a65c3d2a655e 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -210,39 +210,6 @@ static void __init processor_id(void) > processor_setup(); > } > > -void __init discard_initial_modules(void) > -{ > - struct boot_modules *mi = &bootinfo.modules; > - int i; > - > - /* > - * When using static heap feature, don't give boot_modules memory back to > - * the heap allocator > - */ > - if ( using_static_heap ) > - goto out; > - > - for ( i = 0; i < mi->nr_mods; i++ ) > - { > - paddr_t s = mi->module[i].start; > - paddr_t e = s + PAGE_ALIGN(mi->module[i].size); > - > - if ( mi->module[i].kind == BOOTMOD_XEN ) > - continue; > - > - if ( !mfn_valid(maddr_to_mfn(s)) || > - !mfn_valid(maddr_to_mfn(e)) ) > - continue; > - > - fw_unreserved_regions(s, e, init_domheap_pages, 0); > - } > - > - mi->nr_mods = 0; > - > - out: > - remove_early_mappings(); > -} > - > /* Relocate the FDT in Xen heap */ > static void __init relocate_fdt(const void **dtb_vaddr, size_t dtb_size) > { > @@ -509,6 +476,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) > */ > discard_initial_modules(); The comment above is now duplicated with the one you added in xen/bootinfo.h. I'd drop it from here (can be done on commit). Other than that: Reviewed-by: Michal Orzel NIT for the future: if you send a series of patches, please move the fixes/code movement changes at the beginning of the series. ~Michal From xen-devel-bounces@lists.xenproject.org Thu Oct 08 11:52:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 11:52:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443242.1660619 (Exim 4.92) (envelope-from ) id 1xEmfe-0002BS-8l; Thu, 08 Oct 2026 11:52:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443242.1660619; Thu, 08 Oct 2026 11:52: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 1xEmfe-0002BL-5L; Thu, 08 Oct 2026 11:52:22 +0000 Received: by outflank-mailman (input) for mailman id 1443242; Thu, 08 Oct 2026 11:52:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEmfd-0002BF-KL for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:52:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEmfc-005T0N-TL for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 13:52:20 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac783d1-2eae-0a2a0a5409dd-0a2a450ae50a-48 for ; Thu, 08 Oct 2026 13:52:20 +0200 Received: from [40.107.162.138] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac783f4-f2d2-0a2a450a0019-286ba28a320c-3 for ; Thu, 08 Oct 2026 13:52:20 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by PA4PR03MB8223.eurprd03.prod.outlook.com (2603:10a6:102:26d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Thu, 8 Oct 2026 11:52:18 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.015; Thu, 8 Oct 2026 11:52: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=EyU5ZGETtHfOr68qXGAhr4IefJVo96vCE1couCn9Kh+3/CVZtbBS3JREHIG/EdPPuSEwhUQB7BmknSOej+ldRD31GyQM+ZrPK1lNa0sQTgjKAl9aYNRrS1QFrPS4lCaLm6UUY4olmP1zBrjFRwPQ8dva7QeU3KWSxlEaySNqvZ/Ih77jc1tZIfg336y4A2n5xXZdVdyxSgCx73PQhdH8VkI0j9Ma+47837Jk7w6u/QcgOuyOKFAgL7ReQPHh69O4rkC6FclnR6J9OQHXEc3yqPOJG/5Zs90b2u51MrVR5j6uwYGckbswpgtsnSYntLx63GVv2D6gg4lI1oeAIzNKeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sZDA2glfVKsohaT+q9MvuOP/DiisaMtmTAUR0MP4+R8=; b=sDVKvYUoCVqhhtXmH75mJYtsfdjwUrMVPaIbIIrvzbpxiSx/gj64wIRSk5RB2N18/f3JlGPIE0U7g3nueyjbIBgbZLNwVtaO/Jp1BgVgwAXxwKfNEcn3XkSqspCIb/Q40cYLhECrPsgo5uVO+QwungswSsbucGVChaNwyDzd6/luP9eXVtwOnlJHk8B1fj+WcxIht3Evmktak1hSD2Dw/kru0D05fssnyT+CQjzlYDnvzrTB3Tnab6f5pJnpVpL2Q6RCY31gRHcaqDE9bcKZs2Kz8gsXKiC0POyltnFzy+tLor2JwhICHE8MA21Gvph7ct2UbY+3fZqhgnuiSPrBNQ== 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=sZDA2glfVKsohaT+q9MvuOP/DiisaMtmTAUR0MP4+R8=; b=PyBNYmL8Y51VoORCqGf9ukoMtY2qdoe4UdDMId12Hid4qRM0F5tAhPt1YptPK1ykR37ASuKBNGN1RlsTiB4jhxbMxPkWNbRWkbyHI1XOmWL0qOlYyuvTy1A2/Z+Fa54PA4BiKZVmcvmskmiMQBBWfA7vjW/1TQI2znTDiwUaOgMKxuaAsylITlQ8r8shHdEcQAsL4zkGccQPEADPXOaqbIR6I4yqJeh+ECQ5LpCX1SK4afs+i7ivgFi6Ra1+ZY3+RaBmzBm9wU6nRc+QvEuOFdrtXHRkCuwr9fZSL60Y8fLZQbV0hE3VPRYSjsZGiTZCG6lABJUS3mKFFXRH42LjUg== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini Subject: [PATCH] virtual_region: address Misra C:2012 rule 18.3 Thread-Topic: [PATCH] virtual_region: address Misra C:2012 rule 18.3 Thread-Index: AQHdVxt4SHehqFazWUu0IFdrUKTAbA== Date: Thu, 8 Oct 2026 11:52:18 +0000 Message-ID: <2281ddbddfaec79635ba8d2cf8aec669ac858e89.1791458533.git.dmytro_prokopchuk1@epam.com> Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|PA4PR03MB8223:EE_ x-ms-office365-filtering-correlation-id: 724c8204-b68b-43c0-2b1f-08df25329ad1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|376014|42112799006|366016|1800799024|18002099003|10067099003|38070700021|11063799006|260925021311599003|260925022911599003|260925021911599003|56012099006; x-microsoft-antispam-message-info: a1XUUD3luA3j5qsxyXWNTcjAVQ7sR+HR1zJio9qWuOxy7rMkY/u+zsAAWkFsZPbSo5OCnhHlXqlhcouNtttJa2Iv6YooU/bpI/yX+I+EI3qGdOkR0ZYMHcpuzX1ism1W9Ax0n5O/HNLrLmYINRzqRNE16GlKL+KJyCAP1AWuUExFCYR3vpGoVijTpATP44fjpDCYdWrOfKinU0DpJksA+/Kr0DrGKhL+tp6dmO1JYJ3MxCSrk/pd7NfAEyfKrFALu3RUwheDlELnVvy/08GptsZnUABsy8I4/ljfos7grx0riLYi3UUjURqcIUzKB2iI3gWM8NGfLZnKtWgOprPNYf9ymVnjnXWnp3RVXQP9H+K8pLM/loA/StVPX1CtXy19yRmfGuEIy4wc4pnaKj7u1KtEpzCk6IP/jx9d+cQji+7UxRDh7ZmQYneiOsXiZ9OtroTbxBi2eWwSevrdnYyTAWRvX3IcRu0dWZQueYfQLP+SvUByctrEyhvp3J/8Mjw/A4VsxlVD4muRYY/o0vUypKipaMQCPuOpmE3JTWwUfErZXPur5k9eEuWIntBqt88FIc5lucDjqOrErI4WJ5zeRjfmG6/cfs7rs06tmdPXXb5jt9bToKebBK2KOxtZrqdvJQxe8JN9St6/TJolgtgKXu4sA/aUvCa3Vzbfds4FB8w= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(42112799006)(366016)(1800799024)(18002099003)(10067099003)(38070700021)(11063799006)(260925021311599003)(260925022911599003)(260925021911599003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?e+MmtGZb0T3lA5SG8pqDYNAs20+jIekReAkd2iKH5AzD1HsfeeG3ZGK2DA?= =?iso-8859-1?Q?daTiyPliOeObAsWMd0dmTckBADtv2+Cececb1SWZZ0oUqbXX5lbEuaFR1P?= =?iso-8859-1?Q?wD2VffKvHp/XDTu6YkMMDTR1HE+qNiDPI6eX/ObQYovT7TI1ruj27MIKrY?= =?iso-8859-1?Q?o/srzDGvZWnW3UFvI11DYkNoiHE1EKuOQeb/st3K2rR5o9yWi1YNe2wPJv?= =?iso-8859-1?Q?TUZah40IYKJ5/KCS97KhxsYtWW8y6n13BO0YUCqyEYnF39pjuQP/tKfzDB?= =?iso-8859-1?Q?n7SYDelO1xKFKvemCcifdauNv8kWsQPwhTGyUm2TJwnRfMGWSbkmmz2twD?= =?iso-8859-1?Q?+tsbM+NijZeC0zzv51yDBdxuRMs/dcau4C+QMSemkFc2TzH9tPSAFoGydd?= =?iso-8859-1?Q?RhWM8dAUr7i11dA94gEXOt9IhS9zOlrPqzOdL7fBlmsLOToqxhAUFlmeyI?= =?iso-8859-1?Q?ksXVsltbZEnzwbB2/0t9TX1E5w7Z9R76nRdKBYdEf9Vx1JJDIXBoK8bHTN?= =?iso-8859-1?Q?RmsYbyOovLmoSL8VG1X0hn/XvXkAy+eXMI94LIPW1Ci8EtMR556aey0n43?= =?iso-8859-1?Q?SKGC45qsXbqOOC4Qnjl1P/hLQF7qG3sdEdJDZCA6fQZXuyjzlkT8VUwGSW?= =?iso-8859-1?Q?Fxa5fzdSB3L0F1m1KAsPathchMRQ/UPHkcLRrHEhhP9T6W9h0tYoN4Q8zt?= =?iso-8859-1?Q?y5Vu0BimfvDPbX+jCbyjy7ZNqFpxsYqfWT+hJSD9o9cJeLxMZfjZ0cp3Tz?= =?iso-8859-1?Q?uwFxeFdpoHyxmrq/ywOFSxDZ/Kpfhjm+qNCyC1CHfThr5FtW2hUUEYb/iI?= =?iso-8859-1?Q?DOt1r5A1Z7o9DHd+qqjJcB0P5TtTyclL1zmLsIwOqO80Ww9GJYWvtItGQR?= =?iso-8859-1?Q?0jkkqAHLNVZydb0Oj2KXou3lubAHjhEgrBDmBM7pt5aGT6iHz3PRPoAkk0?= =?iso-8859-1?Q?dTnsOnBoGQO14eaK8zvoecLr/rilXwJZbh2U1bmrlwcVrD9OkGv6D0zxfF?= =?iso-8859-1?Q?70SP4xUYSCveVtQgAolOWkBOU9t0+C+HnlFwVVnIU5d3ZoZaFW9UZbIIjU?= =?iso-8859-1?Q?pYWqNjtaKzekrGjptWafXNucvs1zGmq+MWwLUazhZF0xquZVQPsdKpnsth?= =?iso-8859-1?Q?BQ8bRRKYVbUeBgbrP9jv5FvpeMUwWredHoXltBjysR3z0B6ThNsRUkisda?= =?iso-8859-1?Q?y++UeQYnfZ/mn2lZ8PT6H9XmRSOXLeYcQ/3Qs2Aqbmg1O9gOrKwwzILOrj?= =?iso-8859-1?Q?3+vcFJJrRRGauUl1GCHKDBB84qSwn5DlEFzKrqpUwhTrHusKJ6I3TpW/sK?= =?iso-8859-1?Q?naQKn8/BNNZEmdWQF37el1EkHH34CAvlA48uzpfnNV/ONTFccHtrCdVyaj?= =?iso-8859-1?Q?hqX+dScLhH5sGmx3YjP+drrYN5ybx+Mc0kkgscYbrg0MwPC4/IAGwvR9tQ?= =?iso-8859-1?Q?kb20nf0feO/6w4hmfKpegJXLJDQfu6YNWuS8FF4G+/Zmsg10xsDeGfxtmP?= =?iso-8859-1?Q?KLFyZuUfZ0jy5It6dNiI/0dlX60nkM7NoWKCwm01gpEzVzr3aIco+KTQdu?= =?iso-8859-1?Q?n4DJ91T1Wpk4i33d63/0Kb8U4DlxRvV398owV6svWHotnP0SNorUSoBGuD?= =?iso-8859-1?Q?PXX8RjPjfW3/knW055Xk+ej18lxq28x5plmTt9M7y+wkDkCz96UlMoE+HW?= =?iso-8859-1?Q?7WiX0W7SgBhzcRyZnl94LdpC3KxeNM/W9JgzMsAhFTCk1/Dlk5qgSBo+1O?= =?iso-8859-1?Q?GvGQ8cBjDsVxFIWWu7nbgEkAy3OhObF/FI8BY04sitIeUEbZ4nZqSkBcHJ?= =?iso-8859-1?Q?P3+Nxz2MZeAOlkjxLU/AQk1haqmK6M0=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 724c8204-b68b-43c0-2b1f-08df25329ad1 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2026 11:52:18.5327 (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: jZUou34u7RLHgo+U4RKLHjDCopdez/l1aiFbP9jWLOsBZ65uJB0aKLR7A/Sk0r5FlfEAtVeVpJyAbDGZcqVM6KMyE3EUGtCj+0qPkUCyLyU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB8223 X-purgate-ID: tlsNG-4011c0/1791460340-508CDCFC-0D865313/0/0 X-purgate-type: clean X-purgate-size: 1582 find_text_region() tests whether an arbitrary address lies inside [text_start, text_end). The address and those bounds are not known to point into one object, so relational operators on the pointers are undefined behaviour and violate Misra C:2012 rule 18.3. The bounds are cast to unsigned long because addr already has that type. The type is wide enough to hold a pointer, so the comparison result stays the same. No functional changes. Signed-off-by: Dmytro Prokopchuk --- A deviation does not fit because find_text_region() compares an arbitrary a= ddress with bounds (as was proposed here: https://patchew.org/Xen/901917945f704643e95842a773be9e8676f76d10.1755690681= .git.dmytro._5Fprokopchuk1@epam.com/). Casting resolve this MISRA violation. --- xen/common/virtual_region.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c index 1dc2e9f592..a30e6b9c30 100644 --- a/xen/common/virtual_region.c +++ b/xen/common/virtual_region.c @@ -83,8 +83,8 @@ const struct virtual_region *find_text_region(unsigned lo= ng addr) rcu_read_lock(&rcu_virtual_region_lock); list_for_each_entry_rcu ( iter, &virtual_region_list, list ) { - if ( (void *)addr >=3D iter->text_start && - (void *)addr < iter->text_end ) + if ( addr >=3D (unsigned long)iter->text_start && + addr < (unsigned long)iter->text_end ) { region =3D iter; break; --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 11:57:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 11:57:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443250.1660627 (Exim 4.92) (envelope-from ) id 1xEmkY-0002nj-PE; Thu, 08 Oct 2026 11:57:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443250.1660627; Thu, 08 Oct 2026 11: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 1xEmkY-0002nc-MX; Thu, 08 Oct 2026 11:57:26 +0000 Received: by outflank-mailman (input) for mailman id 1443250; Thu, 08 Oct 2026 11:57:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEmkX-0002nW-BE for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 11:57:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEmkW-00CPFC-L4 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 13:57:24 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7850d-e002-0a2a0a5209dd-0a2a45038f42-44 for ; Thu, 08 Oct 2026 13:57:24 +0200 Received: from [40.93.196.31] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac78520-fae8-0a2a45030019-285dc41f6d5a-3 for ; Thu, 08 Oct 2026 13:57:23 +0200 Received: from PH8P221CA0060.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:349::9) by SJ0PR12MB5612.namprd12.prod.outlook.com (2603:10b6:a03:427::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.16; Thu, 8 Oct 2026 11:57:16 +0000 Received: from SA2PEPF00003F62.namprd04.prod.outlook.com (2603:10b6:510:349:cafe::7e) by PH8P221CA0060.outlook.office365.com (2603:10b6:510:349::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Thu, 8 Oct 2026 11:57:16 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00003F62.mail.protection.outlook.com (10.167.248.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Thu, 8 Oct 2026 11:57:15 +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; Thu, 8 Oct 2026 06:57:11 -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; Thu, 8 Oct 2026 06:57: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=J2XKYqwZo6vRK8GmMovUaEEa10t5s2lNackhTUGUPajnnn/NoYarjE7zwciQwBrpRYi/HEb6N7fgjeOwvKOl2bO+8/i7rR3Z0Ds0M3hAJQFuLKxv67nfS7Mx+wDX/G6x7zDer6/azekVrajf5t1nAEYvrTqHf42tL/zu/PYgMz0g/wzFAt3S+OAgE1uEsPM7hPY3RguBRHQHTF1uIZ7U0Yr0FMxMF/MtDnGRPx7tkN/oo04At7kYuGSqDaF16PonwMU5o5KpAgcp2gje6Fn/iURxLVzDXSpy8AYEetV/LZ6vB4+7AmHTZyHSzOsMu6bSPeGuWCnw9eq/aqtUJFrdnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OvUcOoxGa9GM4rKmJX/AvXT9lpP1bCoPA6uImLgNC5Q=; b=FWtgFBN+6polqRmdCstjKk4Jg4iIDqo5sl1rwFfQKgIoDvI9eOPWUQtwAudnA5JqOLV50M8MRlcjTgscEOQ21+Gx5dzASFSXR9jGuCzJS4A+Ewii3fB8dKoxfbiSHRU1APjh3m+AhLfgd6m5+E1NCDEx6ylMbxDxgrojlhH8Nrr/rbE0RIkLR2q3UQO/QZf/IR+2uTkH5OSydNMnaF2uSAQlWN6bFLHqz0lZy05uJAEvAjoFFppd7O2p/hzfmDC+K+NaI9FvUIpMCH5thatSyVObdH8jI3GIM/264qj8I0cnkq38JDEXThbtPxDxUObc3aflDuBWyrJOT/iPNYNuBA== 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=OvUcOoxGa9GM4rKmJX/AvXT9lpP1bCoPA6uImLgNC5Q=; b=UW3qwsMg8AvWtTkz/U1h5SUpC9LKAQac4WXOYWguZwD2/htIWzDuUGgObWTkJUv3Hx5D6LCqqxq3xXtyu6NP6igdPp5CU+zvNP/W2GHuGyuwn5EpJ8m+TKTHGCCAImIL3ACkZQPWCvRH2nrYLsTbfOYpGJRDlDj2oKtahBwGuwM= 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: Thu, 8 Oct 2026 13:57:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/device-tree: add a helper to dump an FDT in DTS-like format To: Oleksii Kurochko , CC: Andrew Cooper , Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis References: <20261001111630.112472-1-oleksii.kurochko@gmail.com> <20261001111630.112472-2-oleksii.kurochko@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261001111630.112472-2-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F62:EE_|SJ0PR12MB5612:EE_ X-MS-Office365-Filtering-Correlation-Id: 4911ef6f-4459-4f78-be77-08df25334c12 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|82310400026|376014|1800799024|6133799003|11063799006|5023799004|56012099006|4143699003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: plWMpPiKYY8Np+5PdcKZ4VUs7oxFXvySykqxVSZN36qOhJGyS2RwIey0w6kftQnD2HCJWqohUE66/+kLtPW/tmBUUSgrXuC/+EDtTJ/LgJThM+o4T+3fTktXhXzPOKqtgB7rAgVw2FH5d12MCWH7BWdBKJjLIZrXYan6oFkDUHkgrniD/RhDnmKSL+3bxpFxt48p5k/sTKAjN4CEpd/Ltb+TW5OpA66eAFOggYDTMrT+u8ntrev676aIjkTIycyXgnutzhunLy5ZSIYQp/metbJUnTfa6usl1iMwqjNs/8I4bgTqxc5ZjXbj4qvNWz16E7YFO8835Yma4t8B2HZMYf6Z4pTPaN4oWmvOA0SXOfRqvc4VJ4LP7BN0b8aGL/IaVGP5/hraP+9SQZb7cEpqcBK1TSsXUA/zJH5f5R2DTZqF8Y405bXkqTFfV1tm+atiGk4dE4TsoTg8oD70NbUD8t0eyAor7ZsWP+ScgTuoxmh9tJFXT7hmlg0hImG7DdorBesFP26vAZp099kPLi+ah8Zrsp5h1pZ7z9dJpYQxErXOrfSNCiMQAxgoiESctRaGnJjhPkGOrH8HO03kEq6eyvlXjNzbm+S7kNN8mpoOWKHap7JlGE98EGcQ3c4NYr1h/YCpw/5TFs9g3meXi/WZbNqPZwzT7incOuLlAZuv/gZ3htQvCx7k5pbRQFEPSTEq3tDywHhWpmH1TZ+Et6eLSw== 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)(36860700016)(82310400026)(376014)(1800799024)(6133799003)(11063799006)(5023799004)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: pP1Oywsnu7GlM5JPUW+RhnzSIr8S2vlZCivVQ9UD/AAzzBN3KBl4PdZY2/RVL+iYOYFf1YqmtrLkzEi7KTqzHLY8ALJOb/835XhDbtGFjnZpMnZDa0f45vV0MUvGxjLMt8wpJKPxtx8msvQ6T1eWtPAHVAGeG9suJVDAMG/W9jVLy7arzLLbQWduSIk9nyk1E0Cyn2FGUaNdbjF0ylm/zQ+poa2sXgYIs7Zy8H1dgyHgke49eQ/2w4zVgkDNpt7zJG2IEuOwhICyq+FOKn7PmKdq1vLiRb2ddGYkL0NwYt679BD0inx8PItdT87n9QWR1W9rNOhE1IHKFPGrNvp2JVzawXat3vtRZe4E1ZZryGG3y5SWaoU1ZOSL7aUnNd+o5ooiBzB71gigDbuuTG81KdzcQ7XuUpBVNI2P5Y/2cY29rpiq/gS4gdxC1UjPjlEe X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2026 11:57:15.9133 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4911ef6f-4459-4f78-be77-08df25334c12 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: SA2PEPF00003F62.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB5612 X-purgate-ID: tlsNG-33051d/1791460644-754844E9-031CB6EB/10/73395122804 X-purgate-type: spam X-purgate-size: 5531 On 01-Oct-26 13:16, Oleksii Kurochko wrote: > The device tree Xen builds for a dom0less domain is only ever consumed > by the guest, so a mistake in it surfaces as an obscure failure inside > the domain, far away from the code which produced the tree. > > Add device_tree_dump(). The output follows dtc's format so that a dump > can be diffed against the source DTS or fed back to dtc; the value > formatting heuristics are ported from dtc's utilfdt_print_data() for > that reason. The walk itself goes through libfdt rather than decoding > the tag stream by hand as dtc's fdtdump does. > > Dumping a whole tree is only useful while debugging and costs both code > size and a lot of console output, hence CONFIG_DEVICE_TREE_DEBUG. Mention > the dump in the help text of the option. We should also dump the DTB for dom0/hwdom in prepare_dtb_hwdom(). Please add that to this patch. > > Signed-off-by: Oleksii Kurochko > --- > xen/Kconfig.debug | 3 +- > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/dom0less-build.c | 4 + > xen/common/device-tree/fdt-dump.c | 180 ++++++++++++++++++++++++ > xen/include/xen/bootfdt.h | 13 ++ > 5 files changed, 200 insertions(+), 1 deletion(-) > create mode 100644 xen/common/device-tree/fdt-dump.c > > diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug > index d900d926c555..664f50bf8a96 100644 > --- a/xen/Kconfig.debug > +++ b/xen/Kconfig.debug > @@ -95,7 +95,8 @@ config DEVICE_TREE_DEBUG > depends on DEVICE_TREE_PARSE > help > Device tree parsing and DOM0 device tree building messages are > - logged in the Xen ring buffer. > + logged in the Xen ring buffer. The device tree generated for each > + dom0less domU is dumped there as well, in a DTS-like format. I think we could have a separate option DEVICE_TREE_DUMP that depends on DEVICE_TREE_PARSE. Sometimes all we need is just to see how the generated DTB look like without seeing thousands of other DT debug messages. Especially that nothing in fdt-dump.c depends on DEVICE_TREE_DEBUG. > If unsure, say N here. > > config SCRUB_DEBUG > diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile > index 9036e455d66a..959dd2a9fd30 100644 > --- a/xen/common/device-tree/Makefile > +++ b/xen/common/device-tree/Makefile > @@ -6,6 +6,7 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o > obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o > obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-bindings.init.o > obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o > +obj-$(CONFIG_DEVICE_TREE_DEBUG) += fdt-dump.init.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o > obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o > obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index fcbeb8adbd73..182201384faf 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -1,5 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > +#include > #include > #include > #include > @@ -587,6 +588,9 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > if ( ret < 0 ) > goto err; > > + dt_dprintk("Device tree for %pd:\n", d); Move this message to device_tree_dump. > + device_tree_dump(kinfo->fdt); > + > return 0; > > err: > diff --git a/xen/common/device-tree/fdt-dump.c b/xen/common/device-tree/fdt-dump.c > new file mode 100644 > index 000000000000..fc3d9eca5891 > --- /dev/null > +++ b/xen/common/device-tree/fdt-dump.c > @@ -0,0 +1,180 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +/* > + * Dump a flattened device tree blob in a DTS-like format. > + * > + * is_printable_string() and print_value() are derived from > + * util_is_printable_string() and utilfdt_print_data() in the device tree > + * compiler (dtc). > + * > + * Copyright 2011 The Chromium Authors, All Rights Reserved. > + * Copyright 2008 Jon Loeliger, Freescale Semiconductor, Inc. > + * util_is_printable_string contributed by > + * Pantelis Antoniou > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Deeper nodes are still printed, but not indented any further. */ > +#define DUMP_MAX_INDENT_DEPTH 32 > + > +/* Indentation, in characters, of a node at depth @depth. */ > +static int __init indent_of(int depth) > +{ > + return 2 * min(depth, DUMP_MAX_INDENT_DEPTH); > +} > + > +static bool __init is_printable_string(const void *data, unsigned int len) > +{ > + const char *s = data; > + const char *se = s + len; > + > + /* A zero length property, or one which isn't NUL terminated, isn't one. */ > + if ( (len == 0) || (s[len - 1] != '\0') ) > + return false; > + > + while ( s < se ) > + { > + const char *ss = s; > + > + while ( (s < se) && *s && isprint(*s) ) Xen's is_print() behaves differently than what dtc uses. You need to combine it with is_ascii. Otherwise 0xff would be marked as printable. ~Michal From xen-devel-bounces@lists.xenproject.org Thu Oct 08 12:19:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 12:19:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443286.1660678 (Exim 4.92) (envelope-from ) id 1xEn63-0006eF-05; Thu, 08 Oct 2026 12:19:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443286.1660678; Thu, 08 Oct 2026 12:19: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 1xEn62-0006e7-Rx; Thu, 08 Oct 2026 12:19:38 +0000 Received: by outflank-mailman (input) for mailman id 1443286; Thu, 08 Oct 2026 12:19:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEn61-0006e1-PB for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:19:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEn61-003Cwz-1J for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:19:37 +0000 Received: from mail-lf1-f47.google.com ([209.85.167.47]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xEn61-00AJ65-1B for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:19:37 +0000 Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-5bcb3726952so1041433e87.3 for ; Thu, 08 Oct 2026 05:19: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" 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=HP6qqmm0I4lJJBoiO4TK3AioXVE4WsCl/RMtKYAT5VY=; b=WXyECy+l59Kplc+59GTcEEfUn+ BHd8sTmULsNFK9JSzCq+B2YSmeN2GBI6oYGOwtHdSnOjFNDbsLucjUPfqFHjSXFkQBCJisDKll7Es /QzoVE0hHVjmxnHHStx7oe+Ij0MUEQQXZVXXcPaBWGjZP0bIyHnmNq0ABYV/2VzuQmlU=; X-Forwarded-Encrypted: i=1; AKwUvBw2c0RovfCtd26ed16UnmYMqdx3RVwOTjiE859O++pAsYjJIaWh5+wJxO6bqXMr/YxUtwHjHESqiZU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKJL8EoJPMmh3AYiqG7HIi5754gSyfYnT04g571wynpHl7Ba7is qJrqOAp0U3fxehvNHdQ0Y7pY1Z4qDrl+uisc809Fl88YfyxNVZEBc6g3gLPUeavke4LD20ZCl7B Dh5wygnZf0O2mgo99CiGf+QuP6TaAfWI= X-Received: by 2002:a05:6512:696:b0:5bb:7bdf:c884 with SMTP id 2adb3069b0e04-5bcd074d646mr2068925e87.66.1791461976243; Thu, 08 Oct 2026 05:19:36 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-3-gwd@xenproject.org> <41713068-b683-4971-af8b-1dea1bba500c@suse.com> In-Reply-To: <41713068-b683-4971-af8b-1dea1bba500c@suse.com> From: George Dunlap Date: Thu, 8 Oct 2026 13:19:23 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9NIdfdIp0mnwPSfTZHlTSJ-9ysJotEZU72dkbLPSUkkRo8UnmjjXy0IEo Message-ID: Subject: Re: [PATCH v3 02/18] x86/mm: purge unneeded destroy_perdomain_mapping() To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2026 at 3:24=E2=80=AFPM Jan Beulich wrot= e: > > On 07.10.2026 16:06, Roger Pau Monn=C3=A9 wrote: > > Otherwise LGTM, but I don't think I can RB or Ack it being also the > > author. > > You can, as per earlier discussions of the topic. George's S-o-b effectiv= ely > implies an R-b on the code he's taken unchanged. Your R-b then covers the > parts he has changed (and the overall result). That fulfills the 2-pairs-= of- > eyes requirement. Yes -- relevant section from MAINTAINERS quoted below. So basically, the tags should look like: Signed-off-by: Roger Pau Monn=C3=A9 Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monn=C3=A9 OK to add your R-b, Roger, pending comment tweaks? -Georeg 8<--- In the case where two people collaborate on a patch, at least one of whom is a maintainer -- typically where one maintainer will do an early version of the patch, and another maintainer will pick it up and revise it -- there should be two Signed-off-by's and one Acked-by or Reviewed-by; with the maintainer who did the most recent change sending the patch, and an Acked-by or Reviewed-by coming from the maintainer who did not most recently edit the patch. This satisfies the requirement #2 because a) the Signed-off-by of the sender approves the final version of the patch; including all parts of the patch that the sender did not write b) the Reviewed-by approves the final version of the patch, including all patches that the reviewer did not write. Thus all code in the patch has been approved by someone who did not write it. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 12:27:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 12:27:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443300.1660686 (Exim 4.92) (envelope-from ) id 1xEnDy-0008NS-MX; Thu, 08 Oct 2026 12:27:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443300.1660686; Thu, 08 Oct 2026 12:27: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 1xEnDy-0008NL-Jj; Thu, 08 Oct 2026 12:27:50 +0000 Received: by outflank-mailman (input) for mailman id 1443300; Thu, 08 Oct 2026 12:27:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEnDy-0008NF-2U for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:27:50 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEnDx-003D4J-2f for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:27:49 +0000 Received: from mail-lf1-f41.google.com ([209.85.167.41]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xEnDx-00ALlN-2X for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 12:27:49 +0000 Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5bc18f54abbso994965e87.1 for ; Thu, 08 Oct 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" 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=yuBwwIpi4SGchYnvh0LXzEve/kvG1su7EyhM9rnVmCM=; b=3bzG47WBrPN5hxOcPq0ndKnVOT cLrB/go/S9235J5PUIlue7SfhxOvFZmtfP+0440oet5zjtDen9sIL5ygzXbP/hcBOYYElrrSiS+2/ P60lx9ws+ggfvF/rsXznY66rEsN1gulpQk9S4ug7xDR45RrA1kylVFKH2ha8Q3w2guuI=; X-Forwarded-Encrypted: i=1; AKwUvBws40fsjT6sbt9pOi2nT3JcSQgmCNInq6E7xuQ1hHFnVb375XweIlD7h9LVwN2bdMBX3MiLNRF9Kpc=@lists.xenproject.org X-Gm-Message-State: AFq9FYLVuOh38Ww1LcHztfDdy/2v7jHw+X5H0/G+abtC0PpMUfvwHvpb 7q2kjwohjKvoqpJ5Id5SLQks/fofiGBfKkUWOmqYHVYESQigeTxWO6vjU7UvAFVUTt0lxAcK/Ct 05PmXOKjByyRTw7ZQIwz+LrpuMHSNxeU= X-Received: by 2002:a05:6512:b25:b0:5b6:1a7c:59cb with SMTP id 2adb3069b0e04-5bcd0716b5cmr1940557e87.37.1791462468728; Thu, 08 Oct 2026 05:27:48 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-3-gwd@xenproject.org> <0149f2e4-e35c-4593-b2d2-0358913d353f@suse.com> In-Reply-To: From: George Dunlap Date: Thu, 8 Oct 2026 13:27:37 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-riMMJByybTiAuvuq7Od9syXVk8KYBsmlvFUOusUcGk1kj5_waRCmOaXY Message-ID: Subject: Re: [PATCH v3 02/18] x86/mm: purge unneeded destroy_perdomain_mapping() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Jan Beulich , Andrew Cooper , Teddy Astie , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 9:31=E2=80=AFAM Roger Pau Monn=C3=A9 wrote: > > On Thu, Oct 08, 2026 at 09:55:46AM +0200, Jan Beulich wrote: > > On 07.10.2026 12:40, George Dunlap wrote: > > > --- a/xen/arch/x86/x86_64/mm.c > > > +++ b/xen/arch/x86/x86_64/mm.c > > > @@ -737,6 +737,11 @@ int setup_compat_arg_xlat(struct vcpu *v) > > > NULL, NIL(struct page_info *)); > > > } > > > > > > +/* > > > + * Besides vCPU teardown, which free_perdomain_mappings() would cove= r, this > > > + * serves switch_compat()'s undo path: the domain lives on as a 64-b= it one > > > + * there, so the translation area has to go right away. > > > + */ > > > > Is it really "has to"? The xlat area is simply unused for 64-bit guests= , > > so it would be merely "needlessly occupying resources" if we deferred > > freeing until domain destruction. > > I wondered the same, but pv_vcpu_destroy() won't free the xlat are if > is_pv_32bit_vcpu() returns false, which would be the case if > switch_compat() fails. All this could be adjusted, but it seemed more > churn than benefit. But free_perdomain_mappings() would still free them; so as Jan says, it's just about hanging on to unnecessary resources. I was really on the fence about the comment at all; but I think it should probably go. There's little chance of someone removing it later without checking, and even if they did, the only result would be a few pages held unnecessarily; in the common case that would be almost immediately. (It's theoretically possible for a toolstack to keep a 64-bit domain around after the 32-bit domain creation failed, but it would be very strange.) -George From xen-devel-bounces@lists.xenproject.org Thu Oct 08 13:28:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 13:28:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443341.1660695 (Exim 4.92) (envelope-from ) id 1xEoA5-0000Ao-SK; Thu, 08 Oct 2026 13:27:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443341.1660695; Thu, 08 Oct 2026 13:27: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 1xEoA5-0000Ah-PN; Thu, 08 Oct 2026 13:27:53 +0000 Received: by outflank-mailman (input) for mailman id 1443341; Thu, 08 Oct 2026 13:27:52 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEoA4-0000Ab-D7 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 13:27:52 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEoA4-003EAc-00 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 13:27:52 +0000 Received: from mail-lf1-f46.google.com ([209.85.167.46]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xEoA3-00Akv5-34 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 13:27:51 +0000 Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-5ba4180a65aso2605263e87.2 for ; Thu, 08 Oct 2026 06:27: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" 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=ufySbFGG/woxT3Fdl094NGQeH59b6ZPti6MO8yVVDe4=; b=kmzVRFcNRNKh2tQpAJM9C7Tuw/ 96dDThGXjZtC+3E9zfx+bYef4kOI1Y6l5IdbHQBYCrGIKWCXzTC58OOsS9MCWndZ+0rWVQ8pDiW75 I0s8FsrbC32k2sMew0+RazHlwTn5GRi47rrCEg2/kvWxc4Bm0by9+LMSUccEcMtG6sws=; X-Gm-Message-State: AFq9FYLz6vactL9jJaHxpCLpSuArWMKAMFm10ctRLQIxRJfIU9INaLTA Fq7WaSBQYeiTUcd5I2PnIRnONKUtWVhRAwgiBn+pB/uvjqWuSq6tb+zDFiaSfwZrqXy/EJUgpWa mSyzvrv5KgSSjJ5lQFOGk1vWV9GtwQ30= X-Received: by 2002:a05:6512:3f0f:b0:5bc:c9e3:d59c with SMTP id 2adb3069b0e04-5bcd074202dmr2180689e87.56.1791466070852; Thu, 08 Oct 2026 06:27:50 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-4-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Thu, 8 Oct 2026 14:27:38 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-U2QvNLYFAown4_8wYopYmzXZPBnKe8PITuQtkRkRcxL2uHazou-IdTrc Message-ID: Subject: Re: [PATCH v3 03/18] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2026 at 4:58=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:36AM +0100, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > 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 one remaining caller, free_compat_arg_xlat(), is already in a vCPU > > context, so we just need to change the parameter from a domain pointer > > to a vCPU pointer. > > Without the linear mapping usage this is now a non-functional change, > I would possibly state that on the commit message. Ack. > > Signed-off-by: Roger Pau Monn=C3=A9 > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, C= laude Code:claude-opus-5-5 > > Signed-off-by: George Dunlap > > Reviewed-by: Roger Pau Monn=C3=A9 Thanks, -George From xen-devel-bounces@lists.xenproject.org Thu Oct 08 13:56:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 13:56:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443370.1660704 (Exim 4.92) (envelope-from ) id 1xEobS-0004j4-T7; Thu, 08 Oct 2026 13:56:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443370.1660704; Thu, 08 Oct 2026 13:56: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 1xEobS-0004ix-QK; Thu, 08 Oct 2026 13:56:10 +0000 Received: by outflank-mailman (input) for mailman id 1443370; Thu, 08 Oct 2026 13:56:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEobR-0004ip-6T for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 13:56:09 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEobQ-003EhH-1P; Thu, 08 Oct 2026 13:56:08 +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 1xEobQ-00B00V-0M; Thu, 08 Oct 2026 13:56: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=inAT+xDwEexTXt1oitaM0VvNUjHvpyAGagRYSMkfzK8=; b=PeGa+Bw0lZYzrsbp6pjmE2dKC4 qolivNY6uhgz4aI4X0Mqt/59qS9czBTxEOyS1K9C2gfUqy81ckA5f4AY/pYKD8Quhldpyf79/Segc hyK2tNRzUa90Ku/S/4emfqp6pV9fO6EoqYGfBYK0+vo6ziBDe0KctVIM4BxwtZ5GHzfA=; Date: Thu, 8 Oct 2026 15:56:00 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 11/18] x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-12-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261007104051.48841-12-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:44AM +0100, George Dunlap wrote: > From: Roger Pau Monné > > Add a struct mapcache to struct mapcache_vcpu for the per-vCPU > accounting. Since MAPCACHE_VCPU_ENTRIES is 16, its inuse and garbage > bitmaps are a word each: declare them inline in struct mapcache_vcpu, > rather than mapping them in the per-domain area as the domain-wide > bitmaps are. > > A per-vCPU mapcache is only ever used by its own vCPU, and so by one > pCPU at a time. We can therefore skip both the lock and the TLB-epoch > tracking the domain-wide mapcache needs; a wrap still flushes the > local TLB. > > struct mapcache_vcpu grows from 136 to 176 bytes, and struct vcpu from > 3008 to 3072 bytes (x86_64, debug build), within its page. > > Unlike a domain-wide mapcache, a per-vCPU one cannot, by design, > borrow slots from other vCPUs: MAPCACHE_VCPU_ENTRIES (16) is the most > single-page mappings such a vCPU can hold at once, interrupt handlers' > included, and one more hits the BUG_ON() in map_domain_page(). The PoD > zero-page sweep held up to 16 on top of its callers' until "x86/PoD: map > one page at a time in p2m_pod_zero_check()". Is it really the best approach to keep the same limit? As you note, with the mapcache being per-vcpu the limit of 16 active mappings is going to be strictly enforce, which it wasn't before. The per-vcpu mapcache area is a whole L1 page-directory (it cannot be smaller), so that's 512 entries per-vcpu, of which we limit ourselves to 16. Can we consider using bigger per-vcpu mapcaches, maybe 512 is overkill for the bitmap sizes, but using greater than 16 will likely avoid frequent TLB flushes to re-use the entries. Maybe 64 entries, so the bitmap is still a single unsigned long on 64bit arches. Note that declare bitmap will already use at least an unsigned long for the bitmap itself. > > mapcache_current_vcpu()'s lazy-context-switch handling > (sync_local_execstate() plus a pgtable_vcpu re-read) now applies to > any vCPU with a mapcache: when the idle vCPU runs lazily on an HVM > vCPU's monitor table, the full switch happens before the idle context > uses a mapcache. > > In release builds map_domain_page() still tries the directmap first, > for any vCPU; debug builds exercise the new mapcache. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - HVM only, and per-vCPU from the start: the HVM enablement of "x86: > Initialize the mapcache for PV, HVM, and idle domains" (from the > directmap removal series) is folded in, without the idle domain and > without a domain-wide HVM mapcache. > - Retitle (was: "x86/mm: introduce a per-vCPU mapcache when using ASI"). > - Say which second unmaps the not-present check in unmap_domain_page() > catches: those of an entry the first unmap zapped. > - State the budget of single-page mappings a vCPU can hold at once. > - The mapcache accounting refactor, the move of struct mapcache_vcpu > to struct arch_vcpu and the not-present check in unmap_domain_page() > are split out, for review, into the three patches before this one. > --- > xen/arch/x86/domain_page.c | 70 ++++++++++++++++++++++--------- > xen/arch/x86/include/asm/domain.h | 6 +++ > 2 files changed, 57 insertions(+), 19 deletions(-) > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > index 708df90a00..0500bb9dba 100644 > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -20,12 +20,13 @@ > > /* > * Whether v has a mapcache: PV vCPUs (whose domain-wide mapcache may still be > - * disabled, see mapcache_domain_init()). HVM vCPUs reach everything through > - * the directmap, which covers all physical address space for them. > + * disabled, see mapcache_domain_init()) and the vCPUs of an HVM domain using > + * per-vCPU page-tables. Other HVM vCPUs reach everything through the > + * directmap, which covers all physical address space for them. > */ > static bool has_mapcache(const struct vcpu *v) > { > - return is_pv_vcpu(v); > + return is_pv_vcpu(v) || v->domain->arch.vcpu_pt; > } > > static inline struct vcpu *mapcache_current_vcpu(void) > @@ -38,10 +39,10 @@ static inline struct vcpu *mapcache_current_vcpu(void) > return NULL; > > /* > - * If we are in a lazy context-switch state from a PV vCPU do a full switch > - * 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. > + * If we are in a lazy context-switch state from a vCPU with a mapcache do > + * a full switch 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. > */ > if ( unlikely(this_cpu(curr_vcpu) != curr) ) > { > @@ -61,14 +62,21 @@ static inline struct vcpu *mapcache_current_vcpu(void) > } > > /* > - * The accounting for v's mapcache: the domain's, with *dcache set so the > - * caller takes the domain-wide lock and TLB-epoch machinery into account. > + * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's > + * otherwise, in which case *dcache is set so the caller takes the domain-wide > + * lock and TLB-epoch machinery into account. > */ > static struct mapcache *vcpu_mapcache(struct vcpu *v, > struct mapcache_domain **dcache) > { > struct domain *d = v->domain; > > + if ( d->arch.vcpu_pt ) > + { > + *dcache = NULL; > + return &v->arch.mapcache.cache; > + } > + > *dcache = &d->arch.pv.mapcache; > return &(*dcache)->cache; > } > @@ -77,11 +85,15 @@ static struct mapcache *vcpu_mapcache(struct vcpu *v, > * The domain-wide mapcache's lock and TLB-epoch machinery, taken around > * allocating a slot: the domain's vCPUs share the mapcache's slots, and each > * catches up with a wrap another one caused, flushing its TLB if it has not > - * been flushed since. > + * been flushed since. A per-vCPU mapcache (no dcache) needs neither: only its > + * own vCPU, and so one pCPU at a time, uses it. > */ > static void mapcache_lock(struct mapcache_domain *dcache, > struct mapcache_vcpu *vcache) > { > + if ( !dcache ) > + return; > + > spin_lock(&dcache->lock); > > /* Has some other CPU caused a wrap? We must flush if so. */ > @@ -100,13 +112,17 @@ static void mapcache_lock(struct mapcache_domain *dcache, > static void mapcache_new_epoch(struct mapcache_domain *dcache, > struct mapcache_vcpu *vcache) > { > + if ( !dcache ) > + return; > + > vcache->shadow_epoch = ++dcache->epoch; > dcache->tlbflush_timestamp = tlbflush_current_time(); > } > > static void mapcache_unlock(struct mapcache_domain *dcache) > { > - spin_unlock(&dcache->lock); > + if ( dcache ) > + spin_unlock(&dcache->lock); > } > > #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) > @@ -191,7 +207,12 @@ void *map_domain_page(mfn_t mfn) > } > BUG_ON(idx >= cache->entries); > > - /* /Second/, flush TLBs. */ > + /* > + * /Second/, flush TLBs. A per-vCPU mapcache needs a local flush > + * only: its entries are never _PAGE_GLOBAL, and this vCPU's > + * page-tables can only have been loaded on another pCPU via > + * switch_cr3_cr4(), which flushes non-global mappings. > + */ Shouldn't the above comment be inside of mapcache_new_epoch()? It's a bit disconnected from the code here, as apparently there's no different handling here between per-domain and per-vcpu mapcaches. > perfc_incr(domain_page_tlb_flush); > flush_tlb_local(); > mapcache_new_epoch(dcache, vcache); > @@ -313,11 +334,19 @@ int mapcache_vcpu_init(struct vcpu *v) > return 0; > > cache = vcpu_mapcache(v, &dcache); > - if ( !cache->inuse ) > + if ( !dcache ) > + { > + /* Per-vCPU bitmaps are a word each: they live in the vCPU itself. */ > + cache->inuse = v->arch.mapcache.inuse; > + cache->garbage = v->arch.mapcache.garbage; Well, the size of the bitmap is set to 16 bits, but due to the usage of DECLARE_BITMAP() the underlying type is unsigned long, so it's effectively using 64 bits (a quad). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:29:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:29:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443406.1660713 (Exim 4.92) (envelope-from ) id 1xEp7H-000174-E4; Thu, 08 Oct 2026 14:29:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443406.1660713; Thu, 08 Oct 2026 14:29: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 1xEp7H-00016x-BB; Thu, 08 Oct 2026 14:29:03 +0000 Received: by outflank-mailman (input) for mailman id 1443406; Thu, 08 Oct 2026 14:29:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEp7F-00016r-Ge for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:29:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEp7E-005xGr-Tl for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:29:00 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7a898-e002-0a2a0a5209dd-0a2a4506d4e8-38 for ; Thu, 08 Oct 2026 16:28:56 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7a8a8-195a-0a2a45060019-d155dd30d12f-3 for ; Thu, 08 Oct 2026 16:28:56 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48b0be347b8so2566581f8f.3 for ; Thu, 08 Oct 2026 07:28: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 ffacd0b85a97d-48c71d1245bsm11483417f8f.26.2026.10.08.07.28.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 07:28: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=1791469735; x=1792074535; 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=kUX0L8Oc1BZMsIbZpkkIHxEqPvnUZyqY+30eG0TgJfw=; b=Bov0bS6ALzqaqwKSnE08+bwLYkuAbDe7gKMjFiaGi35p/I2AcSTnWaGqA6V0UGHyIo pbivjmmpOYp0nAksABYemJXC0v8jToVJJfTYbiex5t6+QdjCtE5Ros6aFo19tLqw7Z56 gRbzsihehuWyNkHe/63zBHrKNQwezmxc9DPk2M4NVnrbCo4HqL8Eq0rqPufWmawVIqIT fjLOSA9hy16b+Ao89Iy2D7Ys/nm8CMofo9TaTll/eOVelXM+TmODelmvE88KNkiZppD3 tQJYGnfAXQkuFL8Zp186RyurXJAyeeEw83BFz4RIbvJrVJ3SbCWZEy+lJlfKg4I0QtDT 9GqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791469735; x=1792074535; 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=kUX0L8Oc1BZMsIbZpkkIHxEqPvnUZyqY+30eG0TgJfw=; b=A954sK0ylbPGhW5xEiXFI2ocRQGJibieFYxOiNhme2734CEwHQjFkFgXOaQPvpaTqs aajvfzKlZ9e7Xa05OYyh4lomweuN8ucp8UNgZpGbF057EKxswWHRadSGhI5+WoXbQr9d UOp1NQHPApeqUnghc1sBZQy8PK4RNiN4ScS7EWIPniESfVMkZTwd7HjsrDA4Fl3KbcA5 /mOjMmpNXNx9ZwBCl19T34SUckKo5zXPzhu6YILXYsj+ulwH/EuaBBPbeLNP6Io2fMId d8M2rOrCMtJKhJFoVDupGTx0fOOzbk2XiuyxHtUjya2abZLKkQZMZfkUNbaz/rv2ZSto N4bA== X-Forwarded-Encrypted: i=1; AKwUvBzbwvV7/2ksi9QBmbXQNJSBZOtRKpCV9xEoj7C1NURFNcXwcrkoDSgQY6x1HTsAJYRoyaa8m5ZgOrE=@lists.xenproject.org X-Gm-Message-State: AFq9FYIJTH00NwNXyYYl+DgbUC77Chgq9bd7fDvZVAMtR56wrH5T64+l 5zV38tsl/niL+O/+kHTwHUYjlwrrd0XlkPpfNbjSwz9Bz/4fMxrOjYbHHVnwDL1qOg== X-Gm-Gg: AYBFou39Z9h2/gZIQLP1UCA40moJID3IijVbHWDBiGOo5r5W6sp8gPpCzLaVzHKQ4mj bHvX/96d1rbrs8+uFB3NSAuziz7ISnTRQIxfIB5LHIdCjNyRcFapGP+h5TVKo5esXp7FfpJLKpz NPtF/r17PxEFsrRF7jeF0wOSWX3txIv63vVnFaUQP7JHGg2vfs8MV3m1YDIVXAKI0twC0EKq0H2 eQ+l3omQ3yliEgzUh7ZcnXF4KLU7b9TqMBMUEWhHbxavAkG5DfPnqFmPxqfNWRQDASTYcIuUHmD IErwJBoW1YMJf21nVLxW1D2zM+U5qQNUAgJHfhFQJ0dsvnh4NEImPiR38o+IPlCzfiTwh33eIcW bmvQB7cwe2XD/+CcXmtuzz+T5NH6r2nq6u48cwRyb8YhVjRW9N2F5tx1bqeVtk1IR38OHiK4kfl hLkcC2+4nlCQQLvdcCYr3lmee9REkvDCs20fbOsu1V4bLyAEIliMWvDzG8edqdrXpJW/O5Bt638 2pZmHhPwVKNYzjxIFVGt9HIx+FCFLRAgq+GBdpaNgmUNYniwe7ukY4lOZjdyw== X-Received: by 2002:a05:6000:230c:b0:48a:fb1c:c2a1 with SMTP id ffacd0b85a97d-48c7289c2bemr11061268f8f.47.1791469735608; Thu, 08 Oct 2026 07:28:55 -0700 (PDT) Message-ID: Date: Thu, 8 Oct 2026 16:28:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] virtual_region: address Misra C:2012 rule 18.3 To: Dmytro Prokopchuk1 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: <2281ddbddfaec79635ba8d2cf8aec669ac858e89.1791458533.git.dmytro_prokopchuk1@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: <2281ddbddfaec79635ba8d2cf8aec669ac858e89.1791458533.git.dmytro_prokopchuk1@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1791469736-1ECC577B-13ED8176/10/78276251493 X-purgate-type: spam X-purgate-size: 639 On 08.10.2026 13:52, Dmytro Prokopchuk1 wrote: > find_text_region() tests whether an arbitrary address lies inside > [text_start, text_end). The address and those bounds are not known to > point into one object, so relational operators on the pointers are > undefined behaviour and violate Misra C:2012 rule 18.3. > > The bounds are cast to unsigned long because addr already has that > type. The type is wide enough to hold a pointer, so the comparison > result stays the same. > > No functional changes. > > Signed-off-by: Dmytro Prokopchuk Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:30:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:30:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443411.1660723 (Exim 4.92) (envelope-from ) id 1xEp8b-0002bb-Rq; Thu, 08 Oct 2026 14:30:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443411.1660723; Thu, 08 Oct 2026 14: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 1xEp8b-0002bU-Nq; Thu, 08 Oct 2026 14:30:25 +0000 Received: by outflank-mailman (input) for mailman id 1443411; Thu, 08 Oct 2026 14:30:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEp8b-0002bO-85 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:30:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEp8a-00Bo1l-Kv for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:30:24 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7a8f6-e002-0a2a0a5209dd-0a2a450686fc-22 for ; Thu, 08 Oct 2026 16:30:24 +0200 Received: from [40.93.196.14] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7a8fd-195a-0a2a45060019-285dc40e93a1-3 for ; Thu, 08 Oct 2026 16:30:23 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB5777.namprd03.prod.outlook.com (2603:10b6:303:9c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Thu, 8 Oct 2026 14:30:17 +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.0496.015; Thu, 8 Oct 2026 14:30: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=EXv7GpzR6BhWmpv9hSssZwUlwxIHMAiLjTaZoEg0KE5oQonHQc27K/2SNkwbUDKFO5PKTeT3DOcDFG+0aKrgODGl6pMmgkAADnoWAqu8QkR23pAvR7jNqhna2+8Z4VbWAgUFDXjgQaYNwIBptEf2MX9sPeSFGN782ogRrNU8Vj9a2K7w0gf65xcmiojWzIrOBo9drD38FKYve/lXvleekA/caQ6td6UP+2xfK6hZ+ORRIZic7eP0L9Jui9UtTifiJS7Ilp+Ak7q0usq9IzXUkZU2QCbzxyGpDx2jEyYneT1lkoDAH7o9CMEZIVkiLp6BPlOGaWo+HRTFSTrEfuhJ/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=NSxKxEh4EqXztVHf8t9b6M1lh9UUrL2vy27tKTfYjiQ=; b=RVEOd/STJ375ZIsyFjlelh2WbpcO7CoyMIu+EZZ93Ip1uo/0UGl60AGlDOdb+06iIdJgM1U5C1s5h9wdzekk7wH5pO6R43j37qed+vjKraxgZ+H0oNLZeMvqU3hSDnAdgWwwRl1XTsfoaePl6n9/WgXXL9GPNrg/7E0TupXVuTIqeIkPSD0Msxop5llMRX5c/SM6KhunutdXi6tsTVZdLd8meTLO+/8qiS/imAcIb41C2wVd11PY2JRcPXncr7Fc2mQzJ82WDUTZ7YRcQDJ1jdPq6Md+d/MAcmxVXjlu0EyyMDwKRKAdaKUKzzR6S8G2DcJwdU0/IL5ptiHyYC+2ng== 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=NSxKxEh4EqXztVHf8t9b6M1lh9UUrL2vy27tKTfYjiQ=; b=ztXcgqGZ1Cz/ZIApR6mRevr+90GtZizp81Xg750Lc7al6psAHZSlTPOROHdQtlI9MsXUSkImx4eZMEiV1yKcMY+5Xw1PhxHh+UCIFvDTqqYaJEm/GJrdFsNn9RHEf+wHZjp7aLjR5xiiYmnh+q7MaizM8KMdNNjVQb0I07eMS5U= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <62fabcf5-9094-4a7d-89f3-414e7025154f@citrix.com> Date: Thu, 8 Oct 2026 15:30:13 +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] virtual_region: address Misra C:2012 rule 18.3 To: Dmytro Prokopchuk1 , "xen-devel@lists.xenproject.org" References: <2281ddbddfaec79635ba8d2cf8aec669ac858e89.1791458533.git.dmytro_prokopchuk1@epam.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: <2281ddbddfaec79635ba8d2cf8aec669ac858e89.1791458533.git.dmytro_prokopchuk1@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0123.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:192::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_|CO1PR03MB5777:EE_ X-MS-Office365-Filtering-Correlation-Id: a3a1e7a8-c174-4a2a-7c9a-08df2548ac56 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|22082099003|18002099003|260925021911599003|56012099006|11063799006|260925021311599003|260925022911599003|10067099003; X-Microsoft-Antispam-Message-Info: xczIQ/uVmEe0Toc71gyY3dv+mcaeK5BUqhY76h4U8dfR65oob5J6IEgPP5fwnrstdOCIiTAqodlZy/gyMovzyPAbsYLS1PCGnKPxMFapbSLe4KVDfuKCBUCxMDHibFiqZ1QOHtZv/Xs0YxKsHhzTOMmEXKA0MOI4NuXRdyqA8TkF1cNVWUvs8Rlk4UZnuhK4E41hz36jZF4d8bIf3Rq89abbnm/1nYdQI50j34pzPJnSnMiYXIhv6tPQ+8e8QetPds5FSACYBgChuRK30H/tnkUm9+WoGGJjGerxGK4AjBk84ASl9tD581JzsSuqJGngIiJwhqdlMZVtm7ZpV6qrBotqxA3X0gPRHFZydrzQ2ry8LINoJh41fAmGq8k6x2i3tFZbiInM2htdXeWVMR8ga3khB9FW0o95BYl/TwItXyq3frpOI1WohF0uO/XTT9y5AtxDi/MybuupOlQMQ8KGR0Ado+SPzcTlRJZ0o/IhCU/HD3c/cT06Er/xpDjRS3ih49o/hPWACGQq8qduevKdyHipCjDUEwadyar+MYYbouscBoKLHdYg1kAbhBDSBQlt7LcCcDJCH+spf6l/FDoSisRcqILlV5NzUK8I2cqjj0U= 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)(366016)(23010399003)(22082099003)(18002099003)(260925021911599003)(56012099006)(11063799006)(260925021311599003)(260925022911599003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Tkk4dkNjY25lTGc2MmFKVUJRZ3lCWm9rWTJqVytnWTM0Z20zb1VVV3ZUUGR6?= =?utf-8?B?SHJIYjNiaXVFWEVqY2t3dW5sSGN1M2p2ZkoweVc2THhBNWZPMjNVckk5VDJt?= =?utf-8?B?RzRZanBxZHNUS01YczFRQVBpN3YyOVNTZG00VWhyNm5TRjZWZTI4TVdIMm1p?= =?utf-8?B?cWtyZGZnYkVBb3V2Z3c1Y05FaEJQWDhQQVBEU2piT3c0UzFSNGlWSFd5RTd2?= =?utf-8?B?Sy9qaDNjMUlQblF6VkRyeVBzUFAvNEJKWTFOK3RaN1FNaFIrSEFPaEJrQ2NL?= =?utf-8?B?R0VRbGpOTFg4bTFRc2lOdHRpSk8yVWNJQlpTTHZnMlVaVXBzNE1JSUIzRFN6?= =?utf-8?B?clFSTUdKb2t6ZWxrT2xNTnJDbm82MlptcWcvaXU4dFV6SHFQSXV5NUNhWDVU?= =?utf-8?B?WmFoZGZqVGg5VHZHT2RBTlVuZ0RqWDZUOE9UbVJRRHkyZS9zZkZmTklObzdo?= =?utf-8?B?RXNQQ1h3aTZscWFQS3h2Nm4rTm1uWkhZa2UwOFZPdWVlbEE5R1hDTG9WdDZU?= =?utf-8?B?OUhyYnBxd1VuSHpJY2VjQVE1U0hVWU1sQ0hmK3NpYlM5TGRaRVdNR0hHNXhD?= =?utf-8?B?NUZRd0VjeTYyUmFRaTlwU0ZvemNsV291RVdnb1p6TGVLb0VnakZwYS96OTUw?= =?utf-8?B?UnNwWFVXcXljNzJQNHBVRmJ6NGhFenpBSGxpSlc2NGMrQkxaNi9hTzB4cmlz?= =?utf-8?B?N0dkTXpKNTU4d2I4UWdLb25TRWh0WTNsanA2S2ROZHJPRnBnWVJSWmVndE1D?= =?utf-8?B?L0h0ZFZBSm5qSkhvaDhzajAvMldPcUxuWWRDL01MeG9XUGYyV2REWEdHbWta?= =?utf-8?B?REh6UlVsYlJQZ1p6Y3Flbmd0dmtoUSttL3ZZNUorMFNHS2RJTmhzSGRsb2R2?= =?utf-8?B?OWI4dlNNaktQV0pwREt0QWJaZ0k1UG1yRFY0MTdkN2dONXprOENwZEFSWlRD?= =?utf-8?B?QzhoNDBEMEppV05VRnZSam9BbE9VcEpNMFJORTJaUmhKR2h3QkNjT1h3bjJv?= =?utf-8?B?V255L0lvTjVieDV5V2RBUWtjY3N5TjBxMDBsTUVtY1lWbUJ3UXg0QStTamcv?= =?utf-8?B?L3VBWVFjOGxSVXZ1NFhTaXVrQkFzbzM4bGZuTmNoaGZBOVZ1N3JNdXZKL2NL?= =?utf-8?B?S0cxMExQSVRNaWoyTnNQbWp3Z2g5VzZ3aURpb0lNK2prc2ZFOHU2dnpBWGsy?= =?utf-8?B?cUdILzIydFlDTmJCRFdVZEVSMFJGVDFJYjVkd0dYTGhoU0dsL0REUFhGS1Vk?= =?utf-8?B?bi92SWhTUm02QjhMTGdCUlBuck9mcElOTUplRktUQXNjUWkxSUc2blI2RjBF?= =?utf-8?B?bC9ka1RkZHNFU3BmNWlpaVFMTGFmZ1VVRHFHOXlyVk4xMFRsSGdhOTdlN1Qz?= =?utf-8?B?cXo5Uks3TlBhQnVrMTk1aFZuQWxqYU55bDlOdzlGc0hTZG5ybmUxdXlWZ2xC?= =?utf-8?B?SFRBQTdlOUFCa2pmS0R0VGl2Q1ZHazVhaWdWVWpRaytvR3Z2bnVrZVhDTWpj?= =?utf-8?B?Y1JsK0NTTkdKenM2QURWcnNZaEhLREJYMlYvWndIcGtDK1BMRXBUMXJWN01T?= =?utf-8?B?MFFJTEl1eWRsdGF4ZTc4Uis2WFZTT3hwVlE2V0xGTGZaazIzcFRRTThsa1No?= =?utf-8?B?ZmxlTlFFN1NnNFdTTEdPL2lBNllvblBuelVMNEw0V2c3anhURmRROWRqSTZO?= =?utf-8?B?TFBMS29qSThVZmRBQnc3UzZJeTAxeUxTMWVnR0YwV0dKVnVsUmN0TjZaQi9H?= =?utf-8?B?TmdKNFBaWnJNNVZaT0lHamtMR0dqTzRYeFJRSUtnRG9KTnZJZHFzTnRmRFNm?= =?utf-8?B?QlQ3dmlxc2FSNmwrdDFlak9MSHIxdG12M0VTbUdrSFQrT1BtUDNwZWgvYW5C?= =?utf-8?B?L0VUNU1jZ1lmTzh6NkZNNkJDbXIzM3A5WFl6MEF3VTZiNmlabW9aNjhIZnhr?= =?utf-8?B?NDVMek5LYWpjOTFFQ0ZHVDQ2K29rdGNWUXQwRlRnUHhWRjBnamlVTlozTVMy?= =?utf-8?B?ckZ5TCtCZ1dsZlk1QkcwQ3NOdHg5SmhtOWdBT3d3dnhtMTFCZVFwcDRpNHFF?= =?utf-8?B?dDVJY25rOWFlOSs5cVhrSmlsWjBDeGNnZE9rQy9JWGxIWFRlWkZMaUNKTDBY?= =?utf-8?B?dEFuMytYVjIxMjZaM0xSZmhONEw4OUJrelVNZnVsR24ybCtEOHRvV1RBbjZj?= =?utf-8?B?UGFtaGVtMlg1SnpYV3ZoTE9YTHQwbWNqSEl6cW8vTHFZTlNtNlZPcE9lUDBo?= =?utf-8?B?Mm54elZNU1JPRkJxK2dYSWZmRFZPWDVZQ1VUaUdsdzBtb0dtSlhPUHVLL1Fx?= =?utf-8?B?WjNLZjd6VS9XeXVYem9BYnJ0Tnh5eENvS29mdjRwbXVuS1ZmRG5xdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3a1e7a8-c174-4a2a-7c9a-08df2548ac56 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2026 14:30:17.0873 (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: wdeOIEcktKzGw1brjGAtSzq5hAvaaam+GCw/nsA7yxVugwblW92d7+nsFGluVlHbzCRm0kSIxCME37mcp27Hc0Ig47NwtnZMxtBJMREj9o4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5777 X-purgate-ID: tlsNG-16d1c6/1791469823-F520877B-87ACFED2/0/0 X-purgate-type: clean X-purgate-size: 1690 On 08/10/2026 12:52 pm, Dmytro Prokopchuk1 wrote: > find_text_region() tests whether an arbitrary address lies inside > [text_start, text_end). The address and those bounds are not known to > point into one object, so relational operators on the pointers are > undefined behaviour and violate Misra C:2012 rule 18.3. > > The bounds are cast to unsigned long because addr already has that > type. The type is wide enough to hold a pointer, so the comparison > result stays the same. > > No functional changes. > > Signed-off-by: Dmytro Prokopchuk > --- > A deviation does not fit because find_text_region() compares an arbitrary address > with bounds (as was proposed here: > https://patchew.org/Xen/901917945f704643e95842a773be9e8676f76d10.1755690681.git.dmytro._5Fprokopchuk1@epam.com/). > > Casting resolve this MISRA violation. > --- > xen/common/virtual_region.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c > index 1dc2e9f592..a30e6b9c30 100644 > --- a/xen/common/virtual_region.c > +++ b/xen/common/virtual_region.c > @@ -83,8 +83,8 @@ const struct virtual_region *find_text_region(unsigned long addr) > rcu_read_lock(&rcu_virtual_region_lock); > list_for_each_entry_rcu ( iter, &virtual_region_list, list ) > { > - if ( (void *)addr >= iter->text_start && > - (void *)addr < iter->text_end ) > + if ( addr >= (unsigned long)iter->text_start && > + addr < (unsigned long)iter->text_end ) Please don't break the tabulation.   It's important for legibility. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:35:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:35:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443423.1660731 (Exim 4.92) (envelope-from ) id 1xEpD6-0003Gy-AO; Thu, 08 Oct 2026 14:35:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443423.1660731; Thu, 08 Oct 2026 14: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 1xEpD6-0003Gr-7N; Thu, 08 Oct 2026 14:35:04 +0000 Received: by outflank-mailman (input) for mailman id 1443423; Thu, 08 Oct 2026 14:35:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEpD5-0003Gl-Cy for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:35:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEpD4-00Bos5-BB for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:35:02 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7aa0e-e002-0a2a0a5209dd-0a2a4502a57a-20 for ; Thu, 08 Oct 2026 16:35:02 +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 6ac7aa16-6ca4-0a2a45020019-d155dd33e53e-3 for ; Thu, 08 Oct 2026 16:35:02 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso3162628f8f.1 for ; Thu, 08 Oct 2026 07:35: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-48c75b4e399sm10814734f8f.56.2026.10.08.07.35.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 07:35: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=1791470102; x=1792074902; 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=h21BfFZWA4UUJWMfzdIoAAxeKQm/P1kA2SL5dyMpd+A=; b=GzzMtLhx+hTkkLLxGW/eGWPYl16BrQ+jGhgtTwsAqWuMpZlNdCLAOBhUwI9KYIt4Z0 1Kw8QuzZMs0xF0z03Bd57vydC2IZJ7uPt4LzYwEKt3EW2sDaZ4VbX/IHAYCRbRvox9ld Ke/8/GxLDCqzcyyuFofTn2Onpu8Nss57uS567ov7KTi3fVbf1lICtofUx0Xyr2XBoQa0 V5MhVWWKMmdwZWVvh3YNfFmVXyFgD22RohOVZrqfd/KtJ2m/K5iIXTv5hr0sqPJEKH7o pWsStU7D3RT1pP1mDLrWQOpkTM31ETcRI6BwtIdtSjd2WizfudaZOv6g/k0b9DnS8Cvh 1yGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791470102; x=1792074902; 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=h21BfFZWA4UUJWMfzdIoAAxeKQm/P1kA2SL5dyMpd+A=; b=VwaN/QULv8OOT0y30FjGy9f+A3Sg4rA/LCDSwlD/bVauV5QAKSqQwT8+dh4CpWR5jc lqYb1XB5KZCSzU0pNMqfCbJ0iBNPP0oyzkfouhxidVPkEGQOam0tasbb+qk7gsUUyQaU Bk4q0vIrYn8GF8iMqn4oX6gT37F82BlI9CtASJDLtkVdZghsr/R9S6IreOMLlaQammBE JlV6hiC/gph1SKZt39CuMq0tAEZa9r/U54Z9xmBrRn8z8r/toMTRTnxATkqKPC22wWsZ yXEE+x3DlZmdA9pfuphgSKl5xSk7wqt69Ay/tRQNYKnd1PEsr8oV9AYbI0oz78l3XCO0 fCxw== X-Gm-Message-State: AFq9FYKfH/qmxca8bhvw3N10Czd+yEhNC8gkfkTBFbe+TOO6Tk+mzgmn LLS7Iv0EafH+fa3u6dEPYCpKtKJMYt1SU5yZeG+p6CfxWgeeXkXRmSgLL+5IbLHaMQ== X-Gm-Gg: AYBFou0IyLleRnXoC4DHNyaHDVOremgCL3Vu+RoK/p9GSvq5Vn6iFdqjWY56ooHfNZS JeBp4RwZUo5O+bwEWH4yACID5379TQyEL7d1VNtXYAML+d+y6KDht9dnNiQVKnjhb6SEI66Qv7q wqLX1vE89FzmYT3PUZv4OfgzTJAMs06usxFZwshz4OFFQ8YbedD2Oz3e6XmX8vqx0Iwm9eEa/Nl 0qtsDFPN3u2jf2Y1a8P9v3veQD9I95Xyc+kGVEdvp85IHMdrr9N/FE4mUlLup+84PRVXWQMuCfe X2QDIJA3cdplXwkzS0LCI5Q+VUreKZxQLrdjdAH+UmQFUU63gFRn4yEkufdJn5xCkd/gXaerzU6 wsk3Nfb6OsGFLodcthF+uo3dXN12lRnBIN5gOEPZI+rzP0g/l2TswChunXnPcHSWCk2Tpe3lBY3 lfHbzVOIXWNDnjwZRdZeLGumebzoPRI+CJr2s9pMZ4XhFWQ5svSZk08ernWERwsOwjUs+nqBfha FAMMvaXiA3+nRgoAs2oaFKBGxZ3QNW7NEhr25kb08yPRwCGyz0Jiw6ZSK7PkA== X-Received: by 2002:a05:6000:4308:b0:488:6561:b324 with SMTP id ffacd0b85a97d-48c727878e3mr11341233f8f.9.1791470101662; Thu, 08 Oct 2026 07:35:01 -0700 (PDT) Message-ID: <86d08b6a-a1ce-4aae-8a4c-6b0bcc0b9696@suse.com> Date: Thu, 8 Oct 2026 16:35:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 01/39] xen/riscv: drop INSN_{16,32}BIT_MASK and report unknown instruction lengths 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: <1791194529.8631fc262581453bbf619ec5b2062170.1a10b837ff10003f66@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: <1791194529.8631fc262581453bbf619ec5b2062170.1a10b837ff10003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1791470102-F1EAB2AC-DC97AE4A/10/78276251493 X-purgate-type: spam X-purgate-size: 820 On 05.10.2026 12:01, Baptiste Le Duc wrote: > On Wed, 30 Sep 2026 18:18:43 +0200, Oleksii Kurochko wrote: >> Both constants were inherited from OpenSBI and their names are misleading. >> The length of an instruction is encoded in its low bits: bits[1:0] != 11 >> means 16 bits, otherwise bits[4:2] != 111 means 32 bits, and anything else >> is 48 bits or wider. 0x3 and 0x1c are the patterns compared against in >> these two tests, not masks selecting a 16-bit or a 32-bit instruction. As >> each constant is needed in one place only, once INSN_IS_16BIT() and >> INSN_IS_32BIT() encapsulate the tests, drop them and spell the values out >> in those two macros instead. > > Reviewed-by: Baptiste Le Duc Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:36:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:36:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443428.1660739 (Exim 4.92) (envelope-from ) id 1xEpEa-0003ls-K3; Thu, 08 Oct 2026 14:36:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443428.1660739; Thu, 08 Oct 2026 14:36: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 1xEpEa-0003ll-H0; Thu, 08 Oct 2026 14:36:36 +0000 Received: by outflank-mailman (input) for mailman id 1443428; Thu, 08 Oct 2026 14:36:35 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEpEZ-0003lf-Hz for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:36:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEpEY-003zGN-Ut for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:36:34 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7aa61-2eae-0a2a0a5409dd-0a2a4504bfcc-46 for ; Thu, 08 Oct 2026 16:36:34 +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 6ac7aa72-b57f-0a2a45040019-d155dd34d975-3 for ; Thu, 08 Oct 2026 16:36:34 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48afcd7ba9bso1840165f8f.3 for ; Thu, 08 Oct 2026 07:36: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-48c71d04c0fsm11497458f8f.10.2026.10.08.07.36.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 07:36: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=1791470194; x=1792074994; 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=5uMleNFgQuIv1PK7feFhdNwrJNvYuYO1HHmx6TRacQE=; b=N3hilyTT4+f0Uon4ERYU23hwDB4fUCruh07jukck/k1Y1sAXgT4FS9AC38p8THoUSK e2Y0AyhjpLG+t6TK7LgZfWWBaa0+RlM3So7z1qAhjlbD2xqgP3Z4RwyL0tmdnmczdBjp AgVb4zH71uSOXS54tk37VmqbaHWDpnj69hDZPxmVA5k48yb4IDz2prdu5ONmD58jd6Ft PW8owyYX4HauWUdNwTXKQCDT9Vg/wkBTIoOd1tAkxI8JYuwHztRwQs67wKrI7W346RPQ ue8al9K7QfljpWz9ZNEQONRXtUzHFpwuTApzAGluv68jQhKoFY3ZpLCmq89OhbxQSIjF bZDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791470194; x=1792074994; 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=5uMleNFgQuIv1PK7feFhdNwrJNvYuYO1HHmx6TRacQE=; b=nr+lrXRfSQ/EwHhY1VIgY/Hw8Na1Orl5WYM3gNkAJ2/n23aL8J1QFxq2wSkZgw0rCr fhe712oCI+EcZ1TFUay8INRbrS3d2JicH/glfKjH8xpNk/0V6nE4ud4b62IpDR0e+/8x N2pDZAbmAQcI9AGhwNaUAYp1O+xnZLREk7DWOWUDz0vRTWVVz+jeSwE1ZUW6xhxkq0Lz 6OvQAMwAsqWmSzOcv66zn/ymeQkEbRMvQDGXPbh1Pz3C0lfInSFtq4PgpMJe1CEvdi7z AX2l5I7yDoO/sk173+jpcF3apWkSBri9cR9uLUKKqBizPWEYtWqqKQtTVaw+1OTkuhWx U9Cg== X-Gm-Message-State: AFq9FYKl/aJpSVQa87Oo5Spgv24cK2wN3AqK4qUBy7o6rcN3qunMz/JU 2ikAPrLm7rwE63HD3Azog8uPOwEf8NQEsGKkdrloY6tX1Zt/bOzwsZ61NE1AVD3KITCZbyhwPde 0Ah4Sqw== X-Gm-Gg: AYBFou3B8Pvo2CJ9F1XCO/8omM2LYyVl7gJmzW1Z+ij1+3fiiXj0rMPTkc/jhMrat0u cwmG6NlK7gpeEcq+N6fcJLf5OLo813U4ncZAFtsCLPRZPCPY3eXPwSiJxPyS49MK0HNsHVcEKhp 2237K4fTFDiLV2uxuz/dsudQVM8gOeA4yQw3y9uKsh07GnKLAlUXEeRTUGyKespEcAc5ZSxPu1U jqJyZeUoxMO2TLyO80xPsQu6cQ7Rh1kFRmw0rBoqHzxprSYk04oySIt3AMbChRh0974K47w2C7c pWSrTRTPQuaIw/sE+8v3AY9eqd0Wx3YxnN6Wrd/wOvmc1t6nJb0T8d1J7MEbfFdw3OhvraZu2lu l8/fuuiUO0tDWjZusqDow/YW3emgRT6HfxtRrORvGCEatpU+B84Lq9QTVLSInUl3Lc4vttgS6qb OOLE/jQqLKsO1NSC8/lL1N4V3jDP88zqm7Onc/rLT/9Yyq8osCcwiUvNr+JT8B5vSRR6ingvU4T DAvMKEPDG0SJG4wM0KRG8qIzOqiBfRw3GHy5Jerc/POn5FZbVgvkrcSBCMerQ== X-Received: by 2002:a05:6000:24c3:b0:48c:7386:af18 with SMTP id ffacd0b85a97d-48c7386b121mr9751068f8f.8.1791470194279; Thu, 08 Oct 2026 07:36:34 -0700 (PDT) Message-ID: Date: Thu, 8 Oct 2026 16:36:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 02/39] xen/riscv: set the domain type for 64-bit kernel images 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: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b8381180003f66@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: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b8381180003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791470194-C34C3B50-452569AE/10/78276251493 X-purgate-type: spam X-purgate-size: 580 On 05.10.2026 12:01, Baptiste Le Duc wrote: > On Wed, 30 Sep 2026 18:18:44 +0200, Oleksii Kurochko wrote: >> kernel_image64_probe() never set info->type, so every domain kept the >> DOMAIN_32BIT value a zeroed KERNEL_INFO_INIT leaves behind, even though >> Xen on RISC-V is only built for RV64 and accepts nothing but a 64-bit >> Image. >> >> Nothing consumes d->type on RISC-V yet, so there is no functional change. >> >> [...] > > Reviewed-by: Baptiste Le Duc Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:47:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:47:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443437.1660749 (Exim 4.92) (envelope-from ) id 1xEpOp-0005ks-Hs; Thu, 08 Oct 2026 14:47:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443437.1660749; Thu, 08 Oct 2026 14:47: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 1xEpOp-0005kl-F6; Thu, 08 Oct 2026 14:47:11 +0000 Received: by outflank-mailman (input) for mailman id 1443437; Thu, 08 Oct 2026 14:47:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEpOn-0005kf-Ov for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:47:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEpOm-0041ll-OI for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:47:08 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7ace0-e002-0a2a0a5209dd-0a2a4501eda6-12 for ; Thu, 08 Oct 2026 16:46:59 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7ace3-5984-0a2a45010019-d155dd35b939-3 for ; Thu, 08 Oct 2026 16:46:59 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-487048857f6so2719221f8f.3 for ; Thu, 08 Oct 2026 07:46: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-48c71d10309sm11217125f8f.22.2026.10.08.07.46.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 07:46: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=1791470819; x=1792075619; 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=OHk0TylREpzICKHjwliZ1bgAG2HqegPcPv2gp49ue5E=; b=ScVnj8MePJNL/k2ytbC/OoelZ+JVc4LTcPqW6JHAg+eFaNyJ1iuHOuShIsD7yoDmHo k22vBq8IwuAUiWD+GbtZ0dIvKi30PYX5qYGvRvssSmiNAV9iBxVkEnf/ySeRX4h5xoSG VSG96KAPx+/i4fhCqksizsTO6GpfHE0Q4RZLGMzGOS1yYwERA3zQKyElnRErRFn173Cp wjWxyfBxrTc6StC2le95IH87i3bXH15FAPype5pgB1igo4Q79FGJVsgtQkO5PTKMH1dZ o6sLIcWjrCd/NxOTq3sNi/YKwc1zYbcJ7I8hha/dhoJDS4VpuTJnTbEZLS0wUid5Jqas CQrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791470819; x=1792075619; 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=OHk0TylREpzICKHjwliZ1bgAG2HqegPcPv2gp49ue5E=; b=xzU5j9OaNaYEupU7CZj5Bp95l0a//ayVUUothfY2dQn6942DagsHRY57qxv3LL6vAd LJtIF7kzSDHcLxkrTGf2k4TP5HIyJcIiC67eEh0qv02G8y3cdX60QbMvawYar6HT6D2b ivqSYZjPKnYG6+BDjfypExqaPobiTeMF2dJnneu+EzI+NAZAHETWGSPYOAiumm1U/RPd pFyGCS27w55q4ihL3/p3LTcQ9qUiNU7c66q8l2fnsFM4XmjG1SntA0DuGoqu14fbGbMw wbHV1SxybysX+yeqURpBdcJ7SOmcNDPSRJeiJUMV3AM/FwU2BNXIZkmqhmHTNt5xbZR5 6yGA== X-Forwarded-Encrypted: i=1; AKwUvBwe3GGE+rKBJuJOk2y6pNzE9bMTvddXCknSAlYUzVldnPy/ze0ODi0wpFPnIeLL55wk7zPc3IrTBtg=@lists.xenproject.org X-Gm-Message-State: AFq9FYIPI7gTtGH4SVBLFTGpCZJoI8OvzBwJt6rUD885wyy2Bo4dVeV2 lLiQeV3ZCy5ByEICCUSF0gJNk886DoujzKJANjAO1Bvl5dlT5uA+7iFCo4ggPhog6w== X-Gm-Gg: AYBFou2v1iHYfIeB6lzAJMplgcPM1sH6UACdbbUtheeu2Zovlc5aRZsTiiZG1LELiyz /tCWIg6Ptq7Id3jjByZTgaFXBbPO1aa8n6FW7FMMJ+N3NZACZYApOt+YxLWW5m5B/Uych/Mapb3 mx+mPf6kSTJVYU2/6stUu+o6h7/UfSI8AtdFKb2D2JmnAcpPhWZlH8+3IvAmtDrY7PZ3FPKW7hi AdxmdUZq0GA61urZidi5qF9WsIy15p5oPsmeJQS5trLPGSeDB0omguaBE3fnL5b0OLiqC2qQOwS NpGbd+QfMeHLDigoGADOtFByOW1cMoaKgIUuL99gn9sPym1B1XjTUI7rSDkv6DXRHuosp6Aq3Rw B11R0YYw4w0Nvt7NbqDRKCbeI0MFrxVW1OWoBa6nnjcaody0YsuPdfylV3gUi/La5ElLxnB85LE O1rDsX/eYdwtQMMtXxqkexTPNVZIR/GPx/8I33syIzgawxhONRtt7D9b/vPv2XZI236QAxqrzrk tDQjKkkpbgchADoBhm02FyZWb8jW2hyBLogt6PXVv1yc50SvfojYMngq0XmuA== X-Received: by 2002:a05:6000:2013:b0:48a:fcd6:f351 with SMTP id ffacd0b85a97d-48c727797acmr10735533f8f.20.1791470818584; Thu, 08 Oct 2026 07:46:58 -0700 (PDT) Message-ID: Date: Thu, 8 Oct 2026 16:46:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 03/39] xen/riscv: introduce csr_volatile_read64() 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-d62444/1791470819-1F46D757-82662E10/10/78276251493 X-purgate-type: spam X-purgate-size: 3301 On 30.09.2026 18:18, Oleksii Kurochko wrote: > On RV32 a 64-bit CSR is accessed as two halves, and H. Reading > the halves with two separate instructions isn't always safe: for a CSR > which hardware increments, a carry from the low half into the high one can > happen in between, so a plain pair of reads can produce a value the CSR > never held. Therefore the high half is re-read and the sequence retried if > it changed in the meantime. > > Only CSRs which change under Xen's feet need that, hence the name. The > majority can be read with a plain pair of csr_read()s, so no helper for > those is introduced here as there would be no user for it. > > Use it for CSR_TIME, which is exactly such a counter, and widen cycles_t to > uint64_t. Otherwise get_cycles() would still truncate the time counter to > 32 bits on RV32. > > No functional change on RV64. > > Fixes: a541ddadec0a ("xen/riscv: introduce time.h") > Signed-off-by: Oleksii Kurochko Reviewed-by: Jan Beulich Nevertheless, a few remarks below. > --- a/xen/arch/riscv/include/asm/csr.h > +++ b/xen/arch/riscv/include/asm/csr.h > @@ -39,12 +39,39 @@ > 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. > + * > + * Only needed for CSRs which change under Xen's feet. > + */ > +#define csr_volatile_read64(csr) \ > +({ \ > + uint32_t hi_, lo_, old_; \ > + \ > + hi_ = csr_read(csr ## H); \ This could be the initializer of the variable. > + do { \ > + old_ = hi_; \ > + lo_ = csr_read(csr); \ > + } while ( (hi_ = csr_read(csr ## H)) != old_ ); \ > + \ > + ((uint64_t)hi_ << 32) | lo_; \ > +}) > #else > #define csr_write64(csr, val) \ > ({ \ > csr_write(csr, val); \ > (void)csr ## H; \ While I notice the same exists here already, I wonder what the purpose of this and ... > }) > + > +#define csr_volatile_read64(csr) \ > +({ \ > + (void)csr ## H; \ ... this is (and why their placements differ). Generally a pure 64-bit environment would have no need for these ...H constants, and their availability looks to be all that's checked for here. As Baptiste did point out on patch 11, these uses constitute Misra violations, which we then would need to deviate. I think we want to try to limit the number of needed deviations. And then, seeing how patch 11 introduces an exact copy of this as csr_read64() - can't we simply have #define csr_volatile_read64 csr_read64 ? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:53:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:53:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443447.1660758 (Exim 4.92) (envelope-from ) id 1xEpV9-0007di-6U; Thu, 08 Oct 2026 14:53:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443447.1660758; Thu, 08 Oct 2026 14: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 1xEpV9-0007da-30; Thu, 08 Oct 2026 14:53:43 +0000 Received: by outflank-mailman (input) for mailman id 1443447; Thu, 08 Oct 2026 14:53:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEpV7-0007dT-Gw for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:53:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEpV5-00GOI8-O0 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:53:39 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7ae6c-bab6-0a2a0a5309dd-0a2a450b99a2-14 for ; Thu, 08 Oct 2026 16:53:39 +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 6ac7ae73-b7e8-0a2a450b0019-d1558032e1f3-3 for ; Thu, 08 Oct 2026 16:53:39 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49d0da752ffso49037125e9.3 for ; Thu, 08 Oct 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-4a1843be1f4sm73302815e9.15.2026.10.08.07.53.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 07:53: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=1791471219; x=1792076019; 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=vL8+v/52efkUmaCGszyTqSPmC4RbCwW0w1qqvG0WMFY=; b=HASLRJVyb81mpcz9WmRZgKmw/hLrPQFt4mbeS7WusDs69pCkiU7I6xGCqf4dx8tmsG TOYSo+eof7sYWmC1vmhFNsE22cKf6RkHCwcMFePynlkaHdgpkjthE/JpU4J+FraMlrWa TVqe+6E9isMZFjWQ07W7/ahU8gAxzVYOHThwOevn6VwcSiXh+VieEVmrvUIi/vZDx54r SZTOBaGimaaw9kqeqIHoPPQ37LUxB9CtN5eSKA4M7CSiENewKcMf5cP2CvKy+opJ8kEO GLNU7TUFYpeqUUvb6Z/las+ShDJx/EKjclnoBESxgubr8r02y/IOvk6xCf5f/vtitYL9 PN4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791471219; x=1792076019; 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=vL8+v/52efkUmaCGszyTqSPmC4RbCwW0w1qqvG0WMFY=; b=Zl14qEzbSvHxm9WfIvwES4TAbuPJfBhW6Q2xkcfin7RGDiiRIJ6cP69YLprI/W2Amb AUaQUENYFq2DyxR+jRwA7UMez+zuew6HNXkZ6qMNgc/wZ1FTdUSSTbu78R2Xtf+ZJM52 Ij1l8ei+7hg0uI7ro7l8ESDgUjak3nJN+gk8Nz9OY7lwLofy5Ly0g2dHZEySDqewsIw/ vXVRDPzChgOqa9AwiPlsXuB/nRjxJ/UXuJdJCcEJkx8s7BGpB7Urcskr3J9vyDS9PF1b m911fiKeb/UFGI3I50vah1OGHDo4uNuIOPbBGN0x+4jiN92CpUbGhzqcw1br6uP9viQb usyA== X-Gm-Message-State: AFuF++lsLeYwrfd24e5Qs96gBvxDji9+7ZAgfkQ5qOiVwsVo3AJlR2t1 n7t357a5Fik9/eowjMYIGqndFe1CG79QWCrjZHgSQUkXFSZXlfZhZMgDU0qu3sYIew== X-Gm-Gg: AYBFou2atV/rnkWdp/FNF8pTLZyVVwRga5Z9p7oGMCvwzVxlvwj9IAeuvoXueBhFKHl eev3r9GehN9G/UX98WUZaqClm07HW8EFs11TpZmjAqg8hcGd/EgeCDpW+0/cs8TeUjvNF1sUZ9r etKtdC57/y1nswJ9iJS22SVnDULS86YdVOaDaz/CN8ldGIlGRjgm0cr1ofjvEFuKE58nTdQgu6I 57M1EUmOlfcZECldQcAkAyAcVdxh/oE4Z9OAUMINmgzpvHMwcs5PpyommHWrVd946m6LWmOFOJa adnpxPfFMIlMIWXTtdrw6b7aHxxOSRkXQGxvw7hDLWM2CeO7YqiKEnDbOui6JzcJ/AM8SNnDJ0x aOB0hv8G84qQNawR4hWeZXAG14pcfvZGgs6cJsSv9c9J7bsCBBkhRIMu/JHXSfxwHEsXV8zz2FC kAjAwmMKFk3ALKoz4rhbq5CWZmE6bMbI2EdRLMia99ta3q0qJpl2e6i1HHyOz+7ODx0LWPZ9N5d WQM0ohRdZ6bd80K376X7iUhfj+LjcWMPGIIsW/EvWKZVBW5+r4oyO9jy5aykUeM X-Received: by 2002:a05:600c:821a:b0:4a1:777b:8a12 with SMTP id 5b1f17b1804b1-4a1803112f1mr103688245e9.14.1791471219128; Thu, 08 Oct 2026 07:53:39 -0700 (PDT) Message-ID: <0e1557d7-6a90-4a6c-ac21-5e69d0c29e5f@suse.com> Date: Thu, 8 Oct 2026 16:53:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 04/39] xen/riscv: request a G-stage flush on vmenter when VMIDs are disabled 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: <7b3e9a486b348470b3c3b371b6a8d3f7afe0e53f.1790779209.git.oleksii.kurochko@gmail.com> <1791194530.8631fc262581453bbf619ec5b2062170.1a10b83837a0003f66@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: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b83837a0003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791471219-A8AC89EA-50E01E8B/10/78276251493 X-purgate-type: spam X-purgate-size: 707 On 05.10.2026 12:01, Baptiste Le Duc wrote: > On Wed, 30 Sep 2026 18:18:46 +0200, Oleksii Kurochko wrote: >> vmid_handle_vmenter() reports that no flush is needed when VMIDs are >> unavailable (e.g. 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. >> >> Report that a flush is needed on every entry instead. >> >> [...] > > Reviewed-by: Baptiste Le Duc Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443452.1660767 (Exim 4.92) (envelope-from ) id 1xEpW3-00088X-EA; Thu, 08 Oct 2026 14:54:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443452.1660767; Thu, 08 Oct 2026 14: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 1xEpW3-00088Q-BR; Thu, 08 Oct 2026 14:54:39 +0000 Received: by outflank-mailman (input) for mailman id 1443452; Thu, 08 Oct 2026 14:54:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEpW1-00088G-Sa for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:54:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEpW1-0042fh-9G for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:54:37 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7aea4-bab6-0a2a0a5309dd-0a2a450985fa-18 for ; Thu, 08 Oct 2026 16:54:37 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7aead-be1a-0a2a45090019-d1558036a9cf-3 for ; Thu, 08 Oct 2026 16:54:37 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49e73611928so6128885e9.1 for ; Thu, 08 Oct 2026 07:54: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-4a17fc664d5sm69587725e9.0.2026.10.08.07.54.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 07: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=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=1791471277; x=1792076077; 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=uLROtRdXp9YDF2vXSzsAzm8iHpmdQzZbvMD4RhUDsNk=; b=T101gC8rjcSjOTq2BXsDta4xLaPCWw3EZtc4yo0vA2qd9LRKLrKaQ/fF8q2dU+TKtD XWDZUKTNovd6gpCSi9P94OpmUJ6FCnqYS/WW4U5W5dIQbbUN0gnJKEhZMwExHnJEhAZ7 XNNHtiGjeuSC8+D5CnyD9Kxi5TBXPPcho0j3XLBcrH9dvm52PXiZz8bJktm2pLpG+ykP WxMjcbk+DACEtkxj/1xRYSgmGM6Y/HucqyqmW3jCEPceQ46CZfE6mvEuVaYZwBWFFFKx 6ApdRkG2Th88a+d9Y1hOC0PnhqvYgk2ezh1SBAyjs4tkna8y7MwSsjiIXtCPYdT9vtEz 2vIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791471277; x=1792076077; 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=uLROtRdXp9YDF2vXSzsAzm8iHpmdQzZbvMD4RhUDsNk=; b=0R+82DaVpWrqG8T0Mzv/8+lkA6vR039E4xa+4R14Lm7qAyKbA4J54i1fP8/QsybFet cS3Fauct2zyT60QgNplyhzkVbqxlEsVqbcWY2Xb7VvBx8SMOUTd2qpENlXqtudgI4mBD 8b4sSDr6lBgBTs2GCRlctpDVLwaUpKP6rkUCiZt9H6ViXfCQKvwlWo3pwsvgv9GDHMPn UE40Jwm3MlW2/NgcDupDN260yfLvAOBZnXSXshYMNtHKbpB+7+ktI2246GJ7+XO1H6U9 XsV4/nqkpys11D7MryCYXljCHlQ6S/i3rMPF+5pAJq+l1InRqJGcHQlZ8L/bKbeZTf1s /bBQ== X-Forwarded-Encrypted: i=1; AKwUvBwUO7WTtK8cVAZ4Bf+XntPQ3B1pp64fPBXBeJb7XBgrf9UVR9FLX0s9q5DJIYgYxHrrlmwJ2KSGIV0=@lists.xenproject.org X-Gm-Message-State: AFuF++mSI99a1B1mIujDHG/UtN8bw/qpdkxSSUVXe0eM8WIOjRCeENGQ Nk6IfTGkbFNxLqu/r8+BbB+nGPUy0f939sdChGal2xFh9ogXx7n5gHxJ7hxasDiUTA== X-Gm-Gg: AYBFou1Ctke2HooXn235j9g308bMzmmHPzNeJR67gmOVfizra36pryU6uy3a4/feCAh yVEK5pYK2V/h96Nryb5xXB012cEWGUTaOdxM8VaoY0EqiVCHKMlKo6AS+PwddS0ogccBie5frCn u0G4LJrWgOqll4T/bVXeA+snTb4A2GqBYHRNDGKV9qFrI/5LBW68lotGQqHg8NqLM8uh6FtnwFB gN1IzclZnVxWfTjGwwE/Vx1BujhYLpw5UeDainQWgB0d+ge+5RUycje8GdusZmojA4QBQYPmQI/ Bw80NwB+xz3I3QL7N+zsC2ZcbW44RFw5pnL63s/bAusSrJ7U+DRph1aTJXM3Q4ZFJW5ZGkzX+o4 frY1mAEFXUUNo8GMLbHI9YHl+Pb4gI4OBwSGsAhpYEu5YbYWmnaUmTz8hLKyiDKGl4dPaYwNdn+ a72UIWsCTsOoPjRMNiAh01SI04I23fLpZWpmCCbJ9WPPNpf4t96idz4JSZD2kRmK9st/LWeVnla GemCCrwYBZlcX3oMaR4gX1DDnvbuJAr56Tp/fPfgeWmmKCWdFCbgZrhsCOJXw== X-Received: by 2002:a05:600c:4fd4:b0:49e:65f2:db64 with SMTP id 5b1f17b1804b1-4a1851ac4c7mr50371665e9.5.1791471276058; Thu, 08 Oct 2026 07:54:36 -0700 (PDT) Message-ID: <2a2935af-23be-48c2-87cc-7bd0f9b82cc9@suse.com> Date: Thu, 8 Oct 2026 16:54:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 05/39] xen/riscv: use ~0 instead of ULONG_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: <96c87282b3c36e910f8d504a1c85e5802f75efad.1790779209.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: <96c87282b3c36e910f8d504a1c85e5802f75efad.1790779209.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791471277-3B6D2034-5D52D937/10/78276251493 X-purgate-type: spam X-purgate-size: 1048 On 30.09.2026 18:18, 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 ~0 instead: csr_write64() converts its argument to uint64_t, and the > conversion of the signed -1 sign-extends to all ones, so both halves get > 0xffffffff. On RV64 the result is equal to ULONG_MAX, so no functional > change there. > > Fixes: 25e032730690 ("xen/riscv: allow Xen to use SSTC while hiding it from guests") > Signed-off-by: Oleksii Kurochko > Reviewed-by: Baptiste Le Duc Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:57:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:57:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443459.1660775 (Exim 4.92) (envelope-from ) id 1xEpYu-0000IJ-QY; Thu, 08 Oct 2026 14:57:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443459.1660775; Thu, 08 Oct 2026 14: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 1xEpYu-0000IA-NS; Thu, 08 Oct 2026 14:57:36 +0000 Received: by outflank-mailman (input) for mailman id 1443459; Thu, 08 Oct 2026 14:57:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEpYt-0000Hx-UD for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:57:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEpYt-00627l-Au for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:57:35 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7af5e-e002-0a2a0a5209dd-0a2a45059208-6 for ; Thu, 08 Oct 2026 16:57:35 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7af5f-4cb1-0a2a45050019-d1558031e0a7-3 for ; Thu, 08 Oct 2026 16:57:35 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a1635f7c89so55414065e9.2 for ; Thu, 08 Oct 2026 07:57: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-4a17f486b6fsm115547715e9.1.2026.10.08.07.57.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 07:57: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=1791471455; x=1792076255; 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=2oUNES7EamklFcAW7NtMFwCaZ9b536afhhJ2PodqlTs=; b=AhCDDxwr5NLOY+LiQO6DeWNy97p9X46UTI8XOczNn5dxjaZG1HezCDMRgbg/m8e9XF Y+AsEBbB/HfYyHkhnX/x25wRv+9SS8c1V/24VokLec3tR2il8NCvR15TV8A5SdVgUTQ4 4nxKgaLgDsG1i/Q1lTgBY7SwOZ/QWkFpdm4JBJ4Wt6u+cXmZDpOTmcZviMRLITZvIzWJ d4exCjujArnZEJLpLmO1VcYHJ4qjIAa7sMBaqMdM51AqiHfBUJHyq2L8x9sJW2dGLw7+ 4M46pDhABDRdNdyoW3BZwOVmv4AttAjgJmQWF7TJ4z6JbnO5CQZQ1spkv2rQcOeT9Yhb WeJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791471455; x=1792076255; 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=2oUNES7EamklFcAW7NtMFwCaZ9b536afhhJ2PodqlTs=; b=aBF0KPkFIJ7iSB6TNcXa6Ad/qLMy4QOo0S7eMxXfpKBLSfGWqKvocon7b1DHHGGg8p aN2FdpwV9LMWStS70eMmggLPtQx+Ys22ZH2c8TA919IE9FnWejFUFp1qCnFrL+lT7Ylx IamvQwOeq4CkV8pec7g7ngmovdbdczNZtlLBk0YgodgdfJyt8nyvIOO049PRM1Ti/Taw A7W1G9mzCF4jUUqwWnQxeAwgIWn2hbYfRqwy26yhaPSFFMxMPzKnOpRwufls6s2ijNxt 4Ql26xOEPKtNfI2PMk8EcnMUKrMga5dn+nzkZxMNMJq9kWAKtCxQYIdQazePw2B4p2Yi BiAQ== X-Gm-Message-State: AFuF++nMjphOS0216X18v8TcugPunsoOPC7kYEzDLPwhwAFdDxJQVqkU hW9jQoAR5vuD4nIvQD4G8QsiZ+3M9Fj/+Sj2VpdimaKCytyTJDvBGxRb/1X2JQOcaQ== X-Gm-Gg: AYBFou21aI+Ie+ilDYJKE2iGJaLcdIWw+6Q+gKQwE8qG/J+6/Ohv6C35xtdc7wHbELx dKHkigu43J0mVZvpTQjptsZBtYWQJTvANd/a466qoteCnXaoKidIPjTrezHZZjvbMtcEBBBMTmh 8rvJrGRRYDL+8i19yKGhLL4il5TfNXq4mKYu+9lhHWtuaJCWBdUz6gNNKP79ZzGgB0el51EN2A4 dobBagg8gExwJvFPpr4YPL8Yhl5dPhl4AvxMVUX57jI+X+Cd9+mX1cOU16Ks9C81HFKInI9NzBx lGypfA1LebUHDMqbNe3U6oyz2/p3bjatzrzoAgvk6scTKpfvd+0Zg9ambHdXKb2csEDLldQPsAz Y5zdJNwkZj4kH1EQAuVuwKp1MdWorj0gzVfeLM6CkfPl/0Q/xwsZUGN8NyzkiR+8/Ikzpkg/tCy io5x4fQo8jqpuYQgPDrXihjMAJqOdLh0QauUVckrjHgm3J9mD1y6feDWNU80gPlOqWvHX6JaLCx Jp1oZT1rvEsOhLH7ovSlWwkYPvvEe3nQWuPIrcKskdyoB9piB8fLA3hseYJRAdae/0GqfvndA== X-Received: by 2002:a05:600c:810a:b0:4a1:7baa:7303 with SMTP id 5b1f17b1804b1-4a1802eb4b1mr106527225e9.7.1791471454722; Thu, 08 Oct 2026 07:57:34 -0700 (PDT) Message-ID: <8aab6ff3-512e-418a-8170-5182ae7f30dc@suse.com> Date: Thu, 8 Oct 2026 16:57:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 06/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 , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko References: <1791194531.8631fc262581453bbf619ec5b2062170.1a10b8384c50003f66@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: <1791194531.8631fc262581453bbf619ec5b2062170.1a10b8384c50003f66@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791471455-72CB02A1-AE89B359/10/78276251493 X-purgate-type: spam X-purgate-size: 467 On 05.10.2026 12:01, Baptiste Le Duc 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 > Should be ASM__RISCV_MMIO_H instead to be consistant with other header > files in riscv/include/asm. No, please see the bottom of ./CODING_STYLE. It's many of the other headers which would want updating (eventually; there's no urgency I think). Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 14:59:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 14:59:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443463.1660786 (Exim 4.92) (envelope-from ) id 1xEpaJ-000126-7B; Thu, 08 Oct 2026 14:59:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443463.1660786; Thu, 08 Oct 2026 14:59: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 1xEpaJ-00011z-3l; Thu, 08 Oct 2026 14:59:03 +0000 Received: by outflank-mailman (input) for mailman id 1443463; Thu, 08 Oct 2026 14:59:01 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEpaH-00011p-LB for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 14:59:01 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEpaH-003FtE-00; Thu, 08 Oct 2026 14:59: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 1xEpaG-00BZbl-24; Thu, 08 Oct 2026 14: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" 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=9Cl7qznlPW73DNpmiIMzy+AWYFYOhUSvLiSZFtQPyVY=; b=FVjx74ACE/gdhH0qsK4ZiFa+zo h22zDNo1/bXEN/sIwXoELqNewGgj7EEOwVzNJHj2CdkOFGIViD1YDwVE3beYiJy9dTs3F1551Scuz P0c725x2W5jXCTtD7k29ruOoK1cCVVAa1cXe5txsFaHIQ5qJjNmP20Z0c250h1XLd+qU=; Date: Thu, 8 Oct 2026 16:58:58 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 12/18] x86/mm: let Xen's page-table walker operate on a given root Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-13-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261007104051.48841-13-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:45AM +0100, George Dunlap wrote: > map_pages_to_xen() and modify_xen_mappings() maintain Xen's own mappings, > walking from idle_pg_table, whose Xen slots every other root page-table > copies. A later patch introduces a second directmap hierarchy: page > tables for the directmap virtual address range that some guest contexts > use in place of idle_pg_table's. It needs the same maintenance at the > same virtual addresses. I assume that "second directmap hierarchy" refers to the sparse directmap approach? > Give virt_to_xen_l{3,2,1}e() the L4 to walk from, and move the bodies of > map_pages_to_xen() and modify_xen_mappings() into map_pages_in() and > modify_mappings_in(), which take the root as well. The public functions > pass idle_pg_table. The EFI runtime-services page-tables mirror > idle_pg_table's L4 entries only, so a newly allocated L3 is propagated > to them only when the root is idle_pg_table. > > TLB flushing is unaffected: it is by virtual address, and the same > addresses are mapped in either hierarchy. The virtual address space is just part of it, so far map_pages_to_xen() has been doing global TLB flushes, because all CPUs used the same page-tables for the Xen slots that map_pages_to_xen() modifies. With the change to pass different L4, there's also the assumption that the Xen slots on those L4 will be different, and hence not all CPUs might need flushing? Maybe I'm thinking ahead too much - but if this is going to be used to manage the sparse directmap we might want to avoid IPIs to CPUs that are running with the full directmap when the sparse one is changed, as those are useless. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 15:05:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 15:05:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443481.1660793 (Exim 4.92) (envelope-from ) id 1xEpgu-0002pF-Qu; Thu, 08 Oct 2026 15:05:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443481.1660793; Thu, 08 Oct 2026 15:05: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 1xEpgu-0002p8-OC; Thu, 08 Oct 2026 15:05:52 +0000 Received: by outflank-mailman (input) for mailman id 1443481; Thu, 08 Oct 2026 15:05:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEpgt-0002p2-NS for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 15:05:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEpgt-001cUA-40 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 17:05:51 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7b135-e002-0a2a0a5209dd-0a2a4508cd50-48 for ; Thu, 08 Oct 2026 17:05:51 +0200 Received: from [103.168.172.153] (helo=fhigh-a2-smtp.messagingengine.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7b149-f659-0a2a45080019-67a8ac9982a3-3 for ; Thu, 08 Oct 2026 17:05:45 +0200 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id BD5631400080 for ; Thu, 8 Oct 2026 11:05:44 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Thu, 08 Oct 2026 11:05:44 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 8 Oct 2026 11:05:42 -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=fm2 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=1791471944; x=1791558344; bh=V7CVtt8UjAOTc+v6GmcQPc4AI8cyfV3U gzoL9yePEMg=; b=eK28EMs8cB0BSu0aik+tOGTKqVwmxQj48O5qttOZr53Akeu0 GoOthPAmIzVttrqus+n2h1hz2TOScVfddSgUQg4GvpPk7xVF3SeS0wfbyNBqbllt aid5M8O/laGQgn9olfbSvNiJZpkFu2cB9K71EPXGuHxme9Rp0PT3FWiUry5Tl31G M8asKIp9UFCeG2epyxifzPUcyQO6BasCHohmbDoek2q05e71i9mbZEgkvWuqBBFm 9SMN15aqJlVUbPR5JRm21pX/7oWyv0lFCfrInR3TyQ0UmNn+X5JAGmR+0FQUYLF9 vwhYl3+q95RDaiWjWg26Wf3i3kV1py7mLvxfDA== 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= fm2; t=1791471944; x=1791558344; bh=V7CVtt8UjAOTc+v6GmcQPc4AI8cy fV3UgzoL9yePEMg=; b=r8zguwPgNaQ1oQrgOd/ALhu67Poq7HTBmCjOWFCgOmjC Ephlye3vaQ0UuW2VVqmqXzFfMoJwu3QrCdLdk4NfX/wYrsxJcxWnrL3pPoqckGAT sYK0EUME5qqR273q0W8YNeyow6PeGCKX98qvrBJSAiuA78Pejs4775UgFTKqVcdC qpGvRi+tgD1GVI8TqmlL9NKl6ByYC18E1xthW+deg0f10lkV5+o2di5elFkaa0q5 ZU94kVRw5Bm7wtsTkhQwXGUQzvbcbPRMfkmr8ki6Mj5If1B4vwerG03Hp2FcPBOv PPCfBLr2UMGhvbElf/h2YhSnNQ5II87MC0Ef8CIwLg== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=sign d=invisiblethingslab.com a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1791471944; d=invisiblethingslab.com; mf=PG1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20+; rt=PHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZz4=; s=fm1:rsa-sha256:YiZ5dU+E03SLJZi/NJKsQUoe5J80dRbS35q13e05YO+La9b yz/bR4nDiR773e661hJGJEYykm52Z6GcxLh2YlZ49OsyEi7+KlywRiooLzvIhO17 NuzBdN7Z4bFvkV1aJLCw7uB1WcUvDuaaffOaUbWdal0SBUkcJu5S5s035m5GbVId lFZS/u5AnfO818AdjqDjNlbtQTehrCs1p4mQpNPDx/8o7XijaqzIaT2m6kayvYr1 STmV2PeEglIb+p8JKxeFtrIkFAFtanW7U2nien8Op3y1EQ1DXfdfKIucqqog9fcC HCSQ8ZjN3LVOY4+BecpvycX6igGCBSX8iKZkAmA==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=mi-m=1; hc=10; hn=cc,content-transfer-encoding,content-type,date,feedback-id, from,message-id,mime-version,subject,to; Message-Instance: m=1; h=sha256:5mRXosrnGBEgCGXLFIEwNEa/+95B04CyOWenoFub1a0=:A6V6pYOhtSaPvokUUGE+GBYBUZa/rWHEUCzv3sjz8GE=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEfqnYsk68pL9AE/ZkNtT8L3YnI3ip+ay8ekXGsMGpEkygu+is92NCH1vJY4KQvy4 wnL7A7s8n64FXFwHqoGBwZE1oPuUWImnL2kgM7ijPxze1ZKNVdhMqb4b8ctCA4Xy7zBaaZ xBCyctcF+cbYwWot/AG8Q68Wm8rANUGyhIci8IKoLYLRAYhKtoWpKBDv7UJHr2WMs6+hQ9 VwJNXNWry5wZm2HmY53KbtziPv2tiQ0dwGX5sG2eEFyH4HrwBhOKZjBTKHHmoxxac/IB3A H6g90xkY9Lo8kyv4QdhKOuB8tZjXF2qs137eiJlR3Cetb9mQNgsAvub1rdQcSU2GweFcP1 8G3Wafr84DYgNASXAH2lMdOHyhnAOsX+2ow+dpAusUBBnGGeAKcudT8Y2xBOnjNGcYwNF1 EUF7MPg7zltGgnb2TNW1AqIvthsqad2gMXYWAfHlOCpnLTkwvV2zK7AscjxoRdUxRuXA1k folLvvIM41Us1I9Goj13p6d0N7LM5D/ougDOWfvs7SUqubEdfZEY8MTzA06q+kAhrB5V3L 3r7G5nHaNsPeWTbWFf8JGEpKFrLgzmBsN8f7qpLFoi5yTGcmY5/wy76/1I5TBDk4yukoTA RjDcgdJbRN3tAo1muh4NZUu8y1LVRYZ8MKFejXWB7dHJp6O3ouzN0stzZGIQ X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] drivers/char: add timeout for XHCI console cable Date: Thu, 8 Oct 2026 17:05:23 +0200 Message-ID: <20261008150528.359731-1-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1791471951-D6F5F87B-69FEACE9/0/0 X-purgate-type: clean X-purgate-size: 3791 Do not wait indefinitely for XHCI to configure console connection. If the cable is not plugged in, timeout after about 1s and continue boot. If the cable is plugged in later, the console will be activated then (see final part of dbc_ensure_running()). When timeout occurs, print a warning message - it will be saved in the console ring buffer, to be later retrieved from dom0, or possibly later printed when the cable is finally connected. But, do not print the warning when waiting after controller reset, as that may have been called from from console dbc_putc() and printing here would result in (possibly infinite) recursion. Try the timeout to be about 1s, which is way above time needed for configuring already connected cable. But, since this part runs very early in the Xen startup, time is not calibrated yet, and functions like NOW() do not work yet. Use raw TSC and estimate needed time to be at least 1s on a fast CPU (5GHz), and possibly longer on a slower one. This is not very accurate method, but fortunately it doesn't need to be. This also helps with similar situation on resuming from suspend - if cable got unplugged in the meantime, system will not hang waiting for the console anymore. And finally, on some systems, when dom0 is also allowed to access the USB controller, it may put the device into low power mode that in some older controllers (for example Kaby Lake) disables also debug capability. In such a case, adding a timeout allows the system to resume, then dom0 can wake up the controller and Xen will resume XHCI console. Signed-off-by: Marek Marczykowski-Górecki --- xen/drivers/char/xhci-dbc.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c index d85c8cd6c36a..3d02bda97999 100644 --- a/xen/drivers/char/xhci-dbc.c +++ b/xen/drivers/char/xhci-dbc.c @@ -851,9 +851,15 @@ static void dbc_reset_debug_port(struct dbc *dbc) } } -static void dbc_enable_dbc(struct dbc *dbc) +static bool dbc_enable_dbc(struct dbc *dbc) { struct dbc_reg *reg = dbc->dbc_reg; + s_time_t start; + /* + * Too early for proper time calibration, assume a 5GHz CPU and let it wait + * about 1s, with still reasonable timeout on a slower CPU. + */ + unsigned long timeout_ticks = 5UL*1000*1000*1000; wmb(); writel(readl(®->ctrl) | (1U << DBC_CTRL_DCE), ®->ctrl); @@ -870,8 +876,12 @@ static void dbc_enable_dbc(struct dbc *dbc) writel(readl(®->portsc) | (1U << DBC_PSC_PED), ®->portsc); wmb(); - while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 ) + start = rdtsc_ordered(); + while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 && + rdtsc_ordered() - start < timeout_ticks ) cpu_relax(); + + return readl(®->ctrl) & (1U << DBC_CTRL_DCR); } static void dbc_disable_dbc(struct dbc *dbc) @@ -970,7 +980,8 @@ static bool __init dbc_open(struct dbc *dbc) dbc_init_work_ring(dbc, &dbc->dbc_owork); dbc_init_work_ring(dbc, &dbc->dbc_iwork); - dbc_enable_dbc(dbc); + if ( !dbc_enable_dbc(dbc) ) + printk(XENLOG_WARNING "Timeout waiting for XHCI console cable\n"); dbc->open = true; return true; @@ -1307,7 +1318,8 @@ static void cf_check dbc_uart_resume(struct serial_port *port) return; } - dbc_enable_dbc(dbc); + if ( !dbc_enable_dbc(dbc) ) + printk(XENLOG_WARNING "Timeout waiting for XHCI console cable\n"); dbc->suspended = false; dbc_flush(dbc, &dbc->dbc_oring, &dbc->dbc_owork); set_timer(&uart->timer, NOW() + MICROSECS(DBC_POLL_INTERVAL)); -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 15:55:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 15:55:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443532.1660802 (Exim 4.92) (envelope-from ) id 1xEqSR-0002AX-6i; Thu, 08 Oct 2026 15:54:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443532.1660802; Thu, 08 Oct 2026 15:54: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 1xEqSR-0002AQ-3m; Thu, 08 Oct 2026 15:54:59 +0000 Received: by outflank-mailman (input) for mailman id 1443532; Thu, 08 Oct 2026 15:54:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEqSP-0002AH-Lw for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 15:54:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEqSP-006BLQ-2q for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 17:54:57 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7bcb1-e002-0a2a0a5209dd-0a2a450cea74-36 for ; Thu, 08 Oct 2026 17:54:56 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7bcd0-f479-0a2a450c0019-d1558036e819-3 for ; Thu, 08 Oct 2026 17:54:56 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49d05d51553so38837815e9.2 for ; Thu, 08 Oct 2026 08:54: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-4a1843df445sm78094745e9.12.2026.10.08.08.54.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 08:54: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=1791474896; x=1792079696; 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=JavdErP7KbBKiaezabZFBSgKfepvWSMx5svLCFcmWLE=; b=KFmDl8dRP4IIxszpDGu+x+OdW7qoQbVv/AmRKgLsQrm4cEhovhF++JyqsC/ioDV6Vw ukaKP9zgkECilqhYQR6aTQq/9Wc9XQPiGk8FsWkvKu1IeKwhoViEVOsPkFOPEl84ZMO+ wx9S5BZBg4hnC0fxHCPgDo8tEvpBvZEnVlW0rttIHZqXWSlNLMh/UPP3Gzwhbt2X/z2l IBIXxsTM5LwqRWe52PAWc7YslR7jrtREpLXTqKQg8EnNTn9vHPKuZ1Jnj9nwmR+jz+bY uxnb4FyaHXKoZJsBWib5pbFFDOIZ8gqh/T3e4FHfFIJ5KL7nZCKr4AAaZ4siZu4p3WwM UfIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791474896; x=1792079696; 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=JavdErP7KbBKiaezabZFBSgKfepvWSMx5svLCFcmWLE=; b=oXB7lWiq+4pBHRzjltb/2SpIKSklfem/G/5pBpyKd/jSWKG7fV+p3CXK8Xend1xEiD CLMato1TC0uy03aqhgULeZEdC8WxTbGbTIQuFrtTkPzq45PtzZ8ZaTGZXWM6LP0rIeuR VrzoPlz5nduwNXroxrYcGfgJFmNhTGys4udE0NjGEYVK0yze1PKsiBdIGRL4FD6oE3x5 syvkL1QaZY12XAeLLzShoyeM0t3xll5znWJp7ot6Zd63ZfmmH2gPmbK0plmsY88vA0tp k8KFsSstEaKKuMinw4hRZPRAeU0DPl3egHfJi9RKP0h5Na64+YrdOHpSxPCkrhb5DjFf NISg== X-Forwarded-Encrypted: i=1; AKwUvBx9CodPKw0nSVuOJOWQvd1hChwoN+lMpwmSAAqW0YlITZnp0rWn6M9DQcla+pBvqn9dGTkIWTFk9Yc=@lists.xenproject.org X-Gm-Message-State: AFuF++kmDxYyG7GiXyKy9wkfqpUTOAGerinMhMKlJIoQHvpSygjnch/W z5dLkQHVKKwf3Da8WYt7LZ5kg6eP/MbbD/R9mJhtnAOKKUpz3fh3zsobyrKTuDK3MQ== X-Gm-Gg: AYBFou3jvKd/Zi0A7cDSN04lFTCibtMyodHTgmibnTfD9xZppenHSDm1eAemLx+qt10 LNJhMhcLpePQPjSfJCmcvd9mLcMgt7zQ1oeJ1z8FoBPeolDRKlmLoIluQObPqykaT1bQ8KlziGX Ll8a7vneRKmB768C/HHq1it2xP0OIev54Yn8YrZyC7aMF6zFxUI/F4Eoegt3bbqrFEnM89hhacq nBlOXVwrTtaa7HpmFwuyWTDZLwNVeVAd1RHTq+4lhnDIuGdvlmV+RjsH155xBarmYaaMSUF9SUu LGbPZZJc/3QWu2wxNMI1XxvEcqDcaiGoayWztyWpJ/jY5dNtI1nLAaJ+eTqwEM7J7HQWiAvADy+ RDPwnVvwuUMbmrmajKCGr13O+pfeW9lcsmynwzSw97i7STNrLsE1El0QNZCqu4XEh0a8ldaqMbZ 8ZZPcug8uh03qSbhPlwwXgQgNSizKmygOeP8cohHjnDLl8PkT/UY+SxC6HMbFzE7d8bny/VdqHk ESu3lveZG15e1QTMs0sGpKK0+9cU0JbjdowMcy3kxlOhNVrTV1gkO3tJ9oUIOY= X-Received: by 2002:a05:600c:3e0a:b0:4a1:6c79:fd31 with SMTP id 5b1f17b1804b1-4a180459354mr100534465e9.12.1791474894673; Thu, 08 Oct 2026 08:54:54 -0700 (PDT) Message-ID: <8f61b665-17ca-4eda-b452-313eff8bff93@suse.com> Date: Thu, 8 Oct 2026 17:54:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: add timeout for XHCI console cable To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 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: <20261008150528.359731-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: <20261008150528.359731-1-marmarek@invisiblethingslab.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1791474896-034D7A5B-A521AD3D/10/78276251493 X-purgate-type: spam X-purgate-size: 2494 On 08.10.2026 17:05, Marek Marczykowski-Górecki wrote: > Do not wait indefinitely for XHCI to configure console connection. If > the cable is not plugged in, timeout after about 1s and continue boot. > If the cable is plugged in later, the console will be activated then > (see final part of dbc_ensure_running()). When timeout occurs, print a > warning message - it will be saved in the console ring buffer, to be > later retrieved from dom0, or possibly later printed when the cable is > finally connected. But, do not print the warning when waiting after > controller reset, as that may have been called from from console > dbc_putc() and printing here would result in (possibly infinite) > recursion. > > Try the timeout to be about 1s, which is way above time needed for > configuring already connected cable. But, since this part runs very > early in the Xen startup, time is not calibrated yet, and functions like > NOW() do not work yet. Use raw TSC and estimate needed time to be at > least 1s on a fast CPU (5GHz), and possibly longer on a slower one. This > is not very accurate method, but fortunately it doesn't need to be. A little fragile, but well... > --- a/xen/drivers/char/xhci-dbc.c > +++ b/xen/drivers/char/xhci-dbc.c > @@ -851,9 +851,15 @@ static void dbc_reset_debug_port(struct dbc *dbc) > } > } > > -static void dbc_enable_dbc(struct dbc *dbc) > +static bool dbc_enable_dbc(struct dbc *dbc) > { > struct dbc_reg *reg = dbc->dbc_reg; > + s_time_t start; > + /* > + * Too early for proper time calibration, assume a 5GHz CPU and let it wait > + * about 1s, with still reasonable timeout on a slower CPU. > + */ > + unsigned long timeout_ticks = 5UL*1000*1000*1000; Even if right now we don't use the driver in any 32-bit env, I think we better wouldn't deliberately break such a possible use. IOW unsigned long isn't a suitable type to use here. Also, nit (style): Blanks please around *. > @@ -870,8 +876,12 @@ static void dbc_enable_dbc(struct dbc *dbc) > writel(readl(®->portsc) | (1U << DBC_PSC_PED), ®->portsc); > wmb(); > > - while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 ) > + start = rdtsc_ordered(); > + while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 && > + rdtsc_ordered() - start < timeout_ticks ) Urgh - now the driver's truly becoming x86-specific. Is there a reason this cannot be get_cycles()? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 08 16:08:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 16:08:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443546.1660812 (Exim 4.92) (envelope-from ) id 1xEqfW-0004i6-CE; Thu, 08 Oct 2026 16:08:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443546.1660812; Thu, 08 Oct 2026 16:08: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 1xEqfW-0004hx-7E; Thu, 08 Oct 2026 16:08:30 +0000 Received: by outflank-mailman (input) for mailman id 1443546; Thu, 08 Oct 2026 16:08:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEqfU-0004hr-Iy for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 16:08:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEqfT-006DMi-3t for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 18:08:27 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7bfe9-bab6-0a2a0a5309dd-0a2a450b80fe-42 for ; Thu, 08 Oct 2026 18:08:27 +0200 Received: from [103.168.172.149] (helo=fout-a6-smtp.messagingengine.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7bff9-b7e8-0a2a450b0019-67a8ac95bd7b-3 for ; Thu, 08 Oct 2026 18:08:26 +0200 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id A9904EC0B1C for ; Thu, 8 Oct 2026 12:08:20 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Thu, 08 Oct 2026 12:08:20 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 8 Oct 2026 12:08:18 -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=fm2 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=1791475700; x=1791562100; bh=j4yKi+CxVYZjG+7LsXl25zrq4CZKQkF5vLwRqud13D8=; b= asWbyatbObYw9SLAX5mDBQtokk+kIwEC2ndQW3BAKRxm3WJJE9DTSPY+36RHnzS2 r26EmZPtlcTvMJ0guOiUvPre1OqOhaJHSSdOnlzYN1fL5zjDMA4daD8U6BaF6qbG 8X3R0Jys0eRNtmw+iXRwT5KyvGJNZzANttfJPYdPZfQ4YndRmujMPtKjblyaB1Rn 1BBNaDgFiGTKXNZsvZIR/SoGhhy3bTXKG6RHZXYOWo8SI9pM42Rx7EShCfjMzXKM TKiPWttqZFcD/ceJ6m7NlFZVWsfVjcYGMwbeTubT9Juj7vGVGt8e16yP2I+ikvuk nsNRERvbJYB5LVZrz00m3g== 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=fm2; t= 1791475700; x=1791562100; bh=j4yKi+CxVYZjG+7LsXl25zrq4CZKQkF5vLw Rqud13D8=; b=lRhAWDNd6xSzsS/NSad40WfVPzNjd36ytfiHVFwi8M+QVeFLEXT QIjHKrXTvHjgtxO/QAaC10TqVI4WpYy6SM+S7TyRInEFfVKL+YiIbYQVVMA75OP0 SQ6Y0FzgU7jud9+U3quqjVzU35GnHHPw6YFfUWskasz9MU+0ZKBw2xqSkvYElwSK BiIa4ntixAGfQ1hkzdcQb4d37/9/6JpohaPwi1rk+vpfbRNY2U15/Ct3saM/utGO TPpdfhpDWW613CK7s1qRoc3xluH7ffxLjZf86Oj3retfqGkRLah0Kjs8jep705FK FTxwIRFHGsbP1wf/8+9GFtWj0dv7N4MeC9g== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=sign d=invisiblethingslab.com a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1791475700; d=invisiblethingslab.com; mf=PG1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20+; rt=PHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZz4=; s=fm1:rsa-sha256:oQRvh1qw/5Gm4/kTdiAvLeMswnc/bnfdXwimvfzRDoaKCV/ 4kwDSE7ls4TvhWYQW0WYp2ddYvvA3U6fsj7TcL7ch8mUFz+TdMdCXbse5ethtnIV JGLlCdumAmTVF51NfzIJM3FLOI2eZoiHFqf0ZQ4BoHQ/SI7uJCdpAhOr4kXcfiUo ENg+fooRYH3MtJ76LF5Fzcc5XfnGJD7nD15FHuj6tzMnR04ZAkF6rod/C9VQ73lJ ELQ1M+InHyILd/rPvc5BNFjdM9QerZIhLMBeKotRmObHtNieJqGwVMOYDwOKYKxS ql9i+6o7r5Qdad9Bv1pKJ9EgZf5PnoXIwTgo9Ug==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=mi-m=1; hc=12; hn=cc,content-disposition,content-type,date,feedback-id,from, in-reply-to,message-id,mime-version,references,subject,to; Message-Instance: m=1; h=sha256:cO1nAwtgffwz6uMCVr/qINUXSQjslTQr8MrCvI1aieM=:WUcRze/hXAyibIAcgHT9rlQCh+eo1SYSiI9gXmQc80E=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGinpzVWOI+crd2k56253wTV9mHJnEA/0hSCKXUf9cGkxoSOH2SL0ldkx699GRx5B RyovquPAtBS2vm+B2YBmNZDu8UxjaqHd7LvRQnIE/kTJCoKJoX0lhq9pczJZb7RqoGtv4a Z2y0UGblPjozVrM5V6dB+qpie/GO+vJN5qTKKL8G99I+z65OBTwzCRjGz4JxVtv3NcvJh6 tZQZDPVBBMkzGf9hZwPdYrtMMyMHU8cZ9lo6Fq5WesN7nWiyHptp1LFSiIl2M0ITj5BaJ8 pLytyQBsT5pNbdVL3nE4eFpcObEnNBdj5SMykaS5WI4RJ9Fo1S4+2vh9m1Pi5h+Y4yT5I7 j68jvZf84Af0DuxzFv+Bc4E0FmzVoY8Fw7BEb7fA5kxnhr7D3Y35NPKT6u3CBo2xyvAlRI CdTfA0G7kyHocPgo5vGlQMOC9VGnYr6FXgK0z2qezQ/OJscPumjlJFQ3P/VlTTzVI7D+jW ZzT6oEuFnnPlhqn7CDZnzJAYt82szwUKJWRrYr0HR570TLLKe1x2PhWYSzCIjf3jZ2ob4y E0E87i2v18AWpVIPcdOh6qqZrJ4xwdkCXdZpPr4nvWNiAohJ+iZnK+2r1i+irKQ9mgvU+p FBdTfmsXKCqwvyytPipJgwi3nDarR4FdXqI+x29UQ79SgkxxSFSAmszcLHvw X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Thu, 8 Oct 2026 18:08:16 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] drivers/char: add timeout for XHCI console cable Message-ID: References: <20261008150528.359731-1-marmarek@invisiblethingslab.com> <8f61b665-17ca-4eda-b452-313eff8bff93@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hfxb7/CCakpY23MN" Content-Disposition: inline In-Reply-To: <8f61b665-17ca-4eda-b452-313eff8bff93@suse.com> X-purgate-ID: tlsNG-42698a/1791475707-182F49EA-81D130A7/0/0 X-purgate-type: clean X-purgate-size: 4285 --hfxb7/CCakpY23MN Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2026 18:08:16 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?PT91dGYtOD9CP1RXOXVic09wPz0=?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] drivers/char: add timeout for XHCI console cable On Thu, Oct 08, 2026 at 05:54:53PM +0200, Jan Beulich wrote: > On 08.10.2026 17:05, Marek Marczykowski-G=C3=B3recki wrote: > > Do not wait indefinitely for XHCI to configure console connection. If > > the cable is not plugged in, timeout after about 1s and continue boot. > > If the cable is plugged in later, the console will be activated then > > (see final part of dbc_ensure_running()). When timeout occurs, print a > > warning message - it will be saved in the console ring buffer, to be > > later retrieved from dom0, or possibly later printed when the cable is > > finally connected. But, do not print the warning when waiting after > > controller reset, as that may have been called from from console > > dbc_putc() and printing here would result in (possibly infinite) > > recursion. > >=20 > > Try the timeout to be about 1s, which is way above time needed for > > configuring already connected cable. But, since this part runs very > > early in the Xen startup, time is not calibrated yet, and functions like > > NOW() do not work yet. Use raw TSC and estimate needed time to be at > > least 1s on a fast CPU (5GHz), and possibly longer on a slower one. This > > is not very accurate method, but fortunately it doesn't need to be. >=20 > A little fragile, but well... >=20 > > --- a/xen/drivers/char/xhci-dbc.c > > +++ b/xen/drivers/char/xhci-dbc.c > > @@ -851,9 +851,15 @@ static void dbc_reset_debug_port(struct dbc *dbc) > > } > > } > > =20 > > -static void dbc_enable_dbc(struct dbc *dbc) > > +static bool dbc_enable_dbc(struct dbc *dbc) > > { > > struct dbc_reg *reg =3D dbc->dbc_reg; > > + s_time_t start; > > + /* > > + * Too early for proper time calibration, assume a 5GHz CPU and le= t it wait > > + * about 1s, with still reasonable timeout on a slower CPU. > > + */ > > + unsigned long timeout_ticks =3D 5UL*1000*1000*1000; >=20 > Even if right now we don't use the driver in any 32-bit env, I think we > better wouldn't deliberately break such a possible use. IOW unsigned > long isn't a suitable type to use here. So, uint64_t? > Also, nit (style): Blanks please around *. >=20 > > @@ -870,8 +876,12 @@ static void dbc_enable_dbc(struct dbc *dbc) > > writel(readl(®->portsc) | (1U << DBC_PSC_PED), ®->portsc); > > wmb(); > > =20 > > - while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) =3D=3D 0 ) > > + start =3D rdtsc_ordered(); > > + while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) =3D=3D 0 && > > + rdtsc_ordered() - start < timeout_ticks ) >=20 > Urgh - now the driver's truly becoming x86-specific. Is there a reason > this cannot be get_cycles()? Sure, it can be get_cycles(). I just need it to not try to apply scaling that works only after calibration, but indeed get_cycles() should work. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --hfxb7/CCakpY23MN Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmrHv/AACgkQ24/THMrX 1yxT+wf9HjVlb4mWp1HQMPrYJDS/3xYXcJmWC7couH8B8N5WCKGPqSXmtVa0FfQp a4ZLeRmsXwOvloz38O7te8s3x7JfkkEScvG36EXlufwo2MFtF2wOP/X8umgE6AYt 3r7Ai96TDkif+rCa1WTtjjQgm0xkL3YTDcuFVsnEEJFya3/yXhZneT/w3l1VKSg4 ePP3QDyaK0guUkIAJa8TMsfhJTLbyiUiBVfnHoCk+cCASKsThuxsh7iYJYyNRdb1 T2cZ+Xi6D7zUivaLQqHlHNOkamkmjBnzegS4bhu6LClTjC0tmba5UZbuv5vRNlBj 0oK9rJ/1tZl3YQ82Z1Tb6Zdg9pb2GQ== =F1g0 -----END PGP SIGNATURE----- --hfxb7/CCakpY23MN-- From xen-devel-bounces@lists.xenproject.org Thu Oct 08 17:57:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 17:57:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443631.1660821 (Exim 4.92) (envelope-from ) id 1xEsMW-0004xy-ON; Thu, 08 Oct 2026 17:57:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443631.1660821; Thu, 08 Oct 2026 17:57: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 1xEsMW-0004xq-Jb; Thu, 08 Oct 2026 17:57:00 +0000 Received: by outflank-mailman (input) for mailman id 1443631; Thu, 08 Oct 2026 17:56:59 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xEsMV-0004xk-F4 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 17:56:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEsMU-00GnBA-Oh for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 19:56:58 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7d94e-8faa-0a2a0a5109dd-0a2a450cdbf4-40 for ; Thu, 08 Oct 2026 19:56:58 +0200 Received: from [40.107.208.55] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac7d968-f479-0a2a450c0019-286bd0371424-3 for ; Thu, 08 Oct 2026 19:56:57 +0200 Received: from BN0PR04CA0022.namprd04.prod.outlook.com (2603:10b6:408:ee::27) by BL1PR12MB5730.namprd12.prod.outlook.com (2603:10b6:208:385::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.25; Thu, 8 Oct 2026 17:56:51 +0000 Received: from BN7PEPF00000097.namprd03.prod.outlook.com (2603:10b6:408:ee:cafe::5f) by BN0PR04CA0022.outlook.office365.com (2603:10b6:408:ee::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Thu, 8 Oct 2026 17:56:51 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN7PEPF00000097.mail.protection.outlook.com (10.167.245.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Thu, 8 Oct 2026 17:56:50 +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, 8 Oct 2026 12:56:44 -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, 8 Oct 2026 12:56:44 -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, 8 Oct 2026 12:56:43 -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=hdZamWPNDMxGv3RAFDxJWnboJXPf/UvhDos0hd24Zp+5UzHOhhFfixuqcw4uEJmO6a6PE5yR/aGQ7CXzUTI+P398/ju1Eudag8mj0yqpLy51e7daLKpXDjPhNmetz5vslyR72vNYnvj3nqbJC3TzQ5f9TA9X/XpRpDGW+4Ntdgh0FvQqDbrw4gpRJQKT+0jjm2jt9SZ4hbH/WbR/w3T9G+3j5bCbYUqBVHChRYSYqXMQUngDfvk+V+zz0Au3IRvKB0ZHMcKEf6t1HcSTEgmPPeXtm/ntLyGWbGHUHRTA0dT4ym7efhzQ54sfQcyPWGu5QqoW1sTN44BSV39hreV40Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hcmfXU9nzokEMDfUM6eAdhEGwO0cEiWL+9WL0YUnHfk=; b=U7GrIVDT4xd3aIuvIradavOPhOi83NSFXQUGtrYzlg2CjQcAuqHvMjw+V+PsMN275jkcOvgcGykCdtYvh/wwseMlNO4KunQu8chluy5cxl3USPS8FqOQAPuUlutRlAYBVIPqy6Gfhnvjw+eX3O/a4Qzx3ryOpKQ8vhQgkGOOHXZGnnnAhU3E/pcm2aKh6vDe0D4V2y40Wf0iPGh8ji+nnVBurVwEC4ojzocbX8xPnlwCHM7T79s0BkQQUL/wKrQ4d/QLEkgdTad5rIs2CRSCl1cfhKYPcMwds4zNPUivbMh0diExFVmSTYsE7a3qkNOcD7GF+/nJ4oxw+8WGWHNp8g== 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=hcmfXU9nzokEMDfUM6eAdhEGwO0cEiWL+9WL0YUnHfk=; b=mkGhRDWJj85xlE4Gnv31OGQFWl/tBnpgLB9jwf791bFVEOWXiL2tFilULUqfbwFxpFTSyifmnMWGlA1/rL4QB95x7CAErC6GdMLfc8JN8RtRhy6rqxAw2mQD0y5yCiZyrMiwGGJP5UpzPTYvOqW0Is1aadrmcSOhO1FZ6mNiaVY= 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: <6830b928-aada-4b5e-a62e-8083d13cb074@amd.com> Date: Thu, 8 Oct 2026 13:56:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH LINUX] x86/PVH: don't truncate initrd address/size To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Juergen Gross , Boris Ostrovsky References: <9698d810-6664-4a9d-a847-18ad124261e0@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <9698d810-6664-4a9d-a847-18ad124261e0@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PEPF00000097:EE_|BL1PR12MB5730:EE_ X-MS-Office365-Filtering-Correlation-Id: c595d7f3-a23c-49c3-58b9-08df256587ce X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|36860700016|376014|1800799024|56012099006|18002099003|22082099003|10067099003|11063799006; X-Microsoft-Antispam-Message-Info: zFggqChIC/0M1C3y1OHlaQzRaOpuE9lElHCdzfo0g1A/UdQcqYad/SnqvQ2vCKjcxYHlEgmWBm1AM81HGEQgMqVQpNx9dlb13EIKynb4AhfIiC+8ULntSio+HlQWtW34SQL1cD3tOyX2ogjR067XDiErahykc3ME8Tk4AQLkjA/CChSPNI2whrxoSEWRPCbsoyw9ohYW2HeBMp5HhCSw1IROtUqNouq7wD1WahpxBipLRpM60ewOYqIFpw5WedOR1hr1YFsDw6cZ9eiFmZqOJggv7X+9TOR7IkN+55Z/VWOABGal1UBdmtzdu5SfCFl/ZUUy/V8yUN+Xgo4McF/WjSQFXGbzwuuJhxO5628t/6sRRboOFCcgE9naYJxTli9hrFrjntJ9c/S8G3rFhmRWBmacRnL6RF1bwARAwvBKSo6NyX3OTRV5LH4riq1id8HBqPOgwfSOTV3PxsvieJTOW6JBcXGX9kwF1rgu5vrQs/Qwf9IGglX+GCx/x+6nHkiFbFlPGGT2lcBIdOmfzUS3A5/UAoyeECqkuvjYWEvigNZBm/yR0kF80OBcQ3wmR/SrFXGcsg//Peyt1jCJP7uGrRzByC2SoaE2hp3dEskzUO61qHrSoYXyJs0fACqNmbFDON6OiQ10wZV3R5r+uyBb2a22pmib8xCaOyNVhXligQnnkDHVPMdttlO32WOUXHguJq9YXn2w2fuMeCNeK85x1w== 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)(23010399003)(36860700016)(376014)(1800799024)(56012099006)(18002099003)(22082099003)(10067099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 5yd6da8pZBLmP4g4R/xfk82cZlRaP+2n6EIkLWmyfYqk/fITHwdfL8cTqULgvh6bzOQGf03KrL4T2GqeSlXHZfzX71Yhdc6+WWezi9QLe7JRs3CQS3ZM8MI6puagH7nSCtH37fRa+AW1SbY8cYEuLIBp7p4YbTCIN8i3QWDsLfjpYLU+DbK+DIqs6pwTS0IdLP+OTbhKQNwwbSV7zpaUhyU2vnj/lRYV6LOIRtQLKPdmpVS/lF5c0Tfp88dMRcWASIlzoingJ4W4drmFErmD44XJ6KWH4WTqljdwmm+xTyH/4SAb5oMaifJAOuLUfLERNZIv6tPxzkpTMrBhF47W+XVww8Re4fzMGLzkYpxX/rq6frwselaSB1CXaqIDxvEMHmLuPqVjlzf/SSAEVVvEC551x46FHO2tnSorJKoC2dCYq8BPlRbBfhUVvWvt1+J2 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2026 17:56:50.9829 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c595d7f3-a23c-49c3-58b9-08df256587ce 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: BN7PEPF00000097.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5730 X-purgate-ID: tlsNG-d25034/1791482218-036D6A5B-DE0CF2DA/10/78276251493 X-purgate-type: spam X-purgate-size: 388 On 2026-10-08 05:48, Jan Beulich wrote: > Consuming merely the lower halves of the provided values isn't very > useful. (While generally loaders try to place it below 4G, especially > when it's huge it may not fit there.) > > Fixes: 7243b93345f7 ("xen/pvh: Bootstrap PVH guest") > Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Thu Oct 08 18:02:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 18:02:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443643.1660831 (Exim 4.92) (envelope-from ) id 1xEsRj-0006kR-96; Thu, 08 Oct 2026 18:02:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443643.1660831; Thu, 08 Oct 2026 18: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 1xEsRj-0006kJ-4u; Thu, 08 Oct 2026 18:02:23 +0000 Received: by outflank-mailman (input) for mailman id 1443643; Thu, 08 Oct 2026 18:02:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEsRh-0006kD-Nd for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 18:02:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEsRe-003JqT-2j; Thu, 08 Oct 2026 18:02:18 +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 1xEsRe-00DMTx-1B; Thu, 08 Oct 2026 18:02: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" 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=i2SfNZb94HElowcmzbtSYPbRD0G4JoBRpeSOq29fYgE=; b=vpqk7dg+ZAl0IDNJ7HIcQ6sNWS 0Xsn35VYZS0TR0HKtt9ECI58svB5lRlDSAS65l4Rcr0gyrIav934JcSTcTRpKRiiQUxDevlLN+6G1 i8tIOQTOP+/pU1kqPDfC7bz4mL2IrcMJifcyHkjocALHH8QUV9x9fkG/yGay+EzLxg68=; Date: Thu, 8 Oct 2026 20:02:12 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v3 13/18] x86/mm: build and maintain a sparse view of the directmap Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-14-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261007104051.48841-14-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:46AM +0100, George Dunlap wrote: > The directmap maps all of RAM, and every root page-table carries it, so > while any guest context runs, all guest memory is reachable from Xen's > address space. For ASI, guest contexts are to run on a view of the > directmap which maps only what Xen must reach through it at all times, > leaving guest memory to transient mappings (map_domain_page()). > > Rather than remove the directmap for everyone, keep the full directmap > as it is, for the idle domain and for guest contexts not using ASI, and > build a second, sparse view: page-tables for the same virtual addresses > (the part of the directmap PV guests can see, where everything Xen > reaches through the directmap lives), mapping a subset of what the full > directmap maps, each entry a copy of the full directmap's. Boot, dom0 > construction and the idle domain keep the full directmap, so nothing in > them needs converting. > > The sparse view maps the xenheap, and memory never handed to the heap > allocator (Xen's image, boot-time allocations, firmware tables). It is > built once the boot allocator has handed its memory to the heap, from > the full directmap minus the ranges the heap was given, plus the xenheap > allocations made meanwhile (NUMA node heap metadata). The page-tables > then come from the heap, and no other CPU is up. The sparse view has an > L3 for each of its L4 slots from the start, so its L4 entries never > change and root page-tables can take copies of them. It is then kept in > step: > > - xenheap allocations are added, and taken out again before the pages > are freed. If that fails the pages stay mapped, and are leaked with > a warning rather than reused (the same reasoning as in "xen/page_alloc: > Add a path for xenheap when there is no direct map" of the directmap > removal series); I would probably remove this last sentence, it doesn't add any meaningful information. > - memory handed to the heap later (boot modules, .init, memory > hot-add) is taken out, and is not handed over if that fails; > - a PV dom0's initrd, assigned to dom0 in place, is taken out; I assume dom0 kernel memory is freed, and it doesn't need the same kind of special handling the initrd needs due to it being assigned in place. > - page-tables from the boot allocator, which the sparse view maps with > every other boot-time allocation, are taken out when idle_pg_table's > hierarchy frees them, and are not freed if that fails, so that the > sparse view never keeps a page the heap may hand out; > - changes to the full directmap through map_pages_to_xen() and > modify_xen_mappings() are mirrored. After boot, map_pages_to_xen() > maps into the directmap only memory Xen keeps (stack guard and shadow > stack pages, firmware tables) or hot-added memory about to be handed > to the heap, which the second rule then takes out again. > > Common code gains four hooks for this, arch_heap_pages_init(), > arch_xenheap_needs_scrub() and arch_xenheap_pages_{alloc,free}(), no-ops > unless CONFIG_SPARSE_DIRECTMAP is selected. A failed > arch_xenheap_pages_alloc() may have mapped part of the pages: > alloc_xenheap_pages() then takes them out through > arch_xenheap_pages_free(), as a free would, before freeing them, and > leaks them if that fails too. xen_mapping_lookup(), built only with > CONFIG_SPARSE_DIRECTMAP, reads an entry of either hierarchy under the > L3 table lock. > > alloc_xenheap_pages() accepts pages still awaiting scrubbing > (MEMF_no_scrub). That is harmless while the directmap maps all memory > anyway, but the sparse view would make such a page's contents, a dying > domain's data for instance, reachable from every context on it until > overwritten. With a sparse view configured, arch_xenheap_needs_scrub() > makes xenheap allocations scrub those pages first, as domain heap > allocations do; clean pages need nothing extra. There's another possible issue here I think: even when requesting scrubbed pages the allocator can decide to scrub them in-place, mapping them using map_domain_page(). Could this also cause concern, as Xen is mapping possibly sensitive data in a context that's not supposed to access it, even if just for the scrubbing. > arch_mfns_in_directmap() says whether an MFN range is reachable through > the directmap; it now answers for every context, so false once a sparse > view is configured. Its one caller, init_node_heap(), then keeps a NUMA > node's heap metadata in the xenheap instead of carving it out of the > node's memory through the directmap: carved out of a range handed to the > heap, it would be left out of the sparse view, which every heap > allocation needs it in. > > The sparse view is built only when some guest type is to use it, which > nothing can request yet: this patch changes nothing on its own. Is it worth mentioning that modify_xen_mappings_lite() doesn't need adjustment because it only deals with virtual addresses in the XEN_VIRT_{START,END} range, and those are cloned in the sparse directmap view? > > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - New in this version. > --- > xen/arch/x86/Kconfig | 1 + > xen/arch/x86/Makefile | 1 + > xen/arch/x86/include/asm/mm.h | 17 +- > xen/arch/x86/include/asm/sparse-directmap.h | 63 +++ > xen/arch/x86/mm.c | 128 +++++- > xen/arch/x86/pv/dom0_build.c | 4 + > xen/arch/x86/setup.c | 4 + > xen/arch/x86/sparse-directmap.c | 424 ++++++++++++++++++++ > xen/common/Kconfig | 18 + > xen/common/page_alloc.c | 41 +- > xen/include/xen/mm.h | 35 ++ > 11 files changed, 722 insertions(+), 14 deletions(-) > create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h > create mode 100644 xen/arch/x86/sparse-directmap.c I have to admit reviewing this 1K line diff is challenging. I've tried my best, but it's likely I've missed stuff. > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index e5535ac484..cd72102ccc 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -31,6 +31,7 @@ config X86 > select HAS_SCHED_GRANULARITY > select HAS_SHARED_INFO > imply HAS_SOFT_RESET > + select HAS_SPARSE_DIRECTMAP > select HAS_UBSAN > select HAS_VMAP > select HAS_VPCI if HVM > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile > index 8a205c3d27..22b3c8bf6b 100644 > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -63,6 +63,7 @@ obj-y += shutdown.o > obj-y += smp.o > obj-y += smpboot.o > obj-y += spec_ctrl.o > +obj-$(CONFIG_SPARSE_DIRECTMAP) += sparse-directmap.o > obj-y += srat.o > obj-y += string.o > obj-$(CONFIG_SYSCTL) += sysctl.o > diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h > index 87131dd4bf..0d1e319c09 100644 > --- a/xen/arch/x86/include/asm/mm.h > +++ b/xen/arch/x86/include/asm/mm.h > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > > /* > @@ -595,6 +596,15 @@ mfn_t alloc_xen_pagetable(void); > void free_xen_pagetable(mfn_t mfn); > void *alloc_mapped_pagetable(mfn_t *pmfn); > > +int map_pages_in(l4_pgentry_t *root, unsigned long virt, mfn_t mfn, > + unsigned long nr_mfns, pte_attr_t flags); > +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, unsigned long e, > + pte_attr_t nf); > +#ifdef CONFIG_SPARSE_DIRECTMAP > +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, > + pte_attr_t *flags, unsigned long *nr); > +#endif > + > int __sync_local_execstate(void); > > /* Arch-specific portion of memory_op hypercall. */ > @@ -655,12 +665,17 @@ void write_32bit_pse_identmap(uint32_t *l2); > > /* > * x86 maps part of physical memory via the directmap region. > - * Return whether the range of MFN falls in the directmap region. > + * Return whether the range of MFN falls in the directmap region, as seen from > + * every context: with a sparse directmap view configured (see > + * asm/sparse-directmap.h), no range is, except through a xenheap allocation. > */ > static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) > { > unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END); > > + if ( sparse_dmap_configured() ) > + return false; > + > return (mfn + nr) <= (virt_to_mfn(eva - 1) + 1); > } > > diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h > new file mode 100644 > index 0000000000..48c1f3c951 > --- /dev/null > +++ b/xen/arch/x86/include/asm/sparse-directmap.h > @@ -0,0 +1,63 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef X86_SPARSE_DIRECTMAP_H > +#define X86_SPARSE_DIRECTMAP_H > + > +#include > +#include > +#include > + > +#ifdef CONFIG_SPARSE_DIRECTMAP > + > +/* > + * The part of the directmap the sparse view covers: the part PV guests can > + * see, which is where everything Xen reaches through the directmap lives. > + * SPARSE_DMAP_END_MFN is the first MFN past it. > + */ > +#define SPARSE_DMAP_START DIRECTMAP_VIRT_START > +#define SPARSE_DMAP_END HYPERVISOR_VIRT_END > +#define SPARSE_DMAP_END_MFN (virt_to_mfn(SPARSE_DMAP_END - 1) + 1) > + > +extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm; > + > +/* Root of the sparse view, once built (NULL before, or if not configured). */ > +extern l4_pgentry_t *sparse_dmap_root; > + > +static inline bool sparse_dmap_configured(void) > +{ > + return opt_sparse_dmap_pv || opt_sparse_dmap_hvm; > +} > + > +void sparse_dmap_init(void); > +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, > + pte_attr_t flags); > +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, > + pte_attr_t nf); > +int sparse_dmap_remove(mfn_t mfn, unsigned long nr); > +int sparse_dmap_drop_pagetable(mfn_t mfn); > + > +#else /* !CONFIG_SPARSE_DIRECTMAP */ > + > +static inline bool sparse_dmap_configured(void) { return false; } > +static inline void sparse_dmap_init(void) {} > +static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, > + unsigned long nr, pte_attr_t flags) > +{ > + return 0; > +} > +static inline int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, > + pte_attr_t nf) > +{ > + return 0; > +} > +static inline int sparse_dmap_remove(mfn_t mfn, unsigned long nr) > +{ > + return 0; > +} > +static inline int sparse_dmap_drop_pagetable(mfn_t mfn) > +{ > + return 0; > +} > + > +#endif /* CONFIG_SPARSE_DIRECTMAP */ > + > +#endif /* X86_SPARSE_DIRECTMAP_H */ > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index 94b96c3d9b..4a1bd9d146 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -127,6 +127,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -5394,11 +5395,104 @@ mfn_t xen_map_to_mfn(unsigned long va) > return ret; > } > > +#ifdef CONFIG_SPARSE_DIRECTMAP > +/* > + * Look @va up in the hierarchy rooted at @root, without allocating anything. > + * Returns the MFN mapped at @va, or INVALID_MFN, with the mapping's flags in > + * L1 form in *flags, and in *nr the number of pages from @va to the end of > + * the entry that maps @va (or that finds it unmapped). > + */ > +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, > + pte_attr_t *flags, unsigned long *nr) > +{ > + bool locking = system_state > SYS_STATE_boot; > + l4_pgentry_t l4e = root[l4_table_offset(va)]; > + const l3_pgentry_t *pl3e = NULL; > + const l2_pgentry_t *pl2e = NULL; > + const l1_pgentry_t *pl1e = NULL; > + struct page_info *l3page; > + unsigned int shift = L4_PAGETABLE_SHIFT; > + mfn_t ret = INVALID_MFN; > + > + L3T_INIT(l3page); > + *flags = 0; > + > + if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) ) > + goto out; > + > + pl3e = map_l3t_from_l4e(l4e) + l3_table_offset(va); > + l3page = l4e_get_page(l4e); > + L3T_LOCK(l3page); > + > + shift = L3_PAGETABLE_SHIFT; > + if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) ) > + goto out; > + if ( l3e_get_flags(*pl3e) & _PAGE_PSE ) > + { > + /* The superpage PAT bit sits among the address bits. */ > + *flags = lNf_to_l1f(l3e_get_flags(*pl3e)) | > + (l3e_get_intpte(*pl3e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); > + ret = _mfn((l3e_get_pfn(*pl3e) & ~((1UL << (2 * PAGETABLE_ORDER)) - 1)) + > + (PFN_DOWN(va) & ((1UL << (2 * PAGETABLE_ORDER)) - 1))); > + goto out; > + } > + > + pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(va); > + shift = L2_PAGETABLE_SHIFT; > + if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) > + goto out; > + if ( l2e_get_flags(*pl2e) & _PAGE_PSE ) > + { > + *flags = lNf_to_l1f(l2e_get_flags(*pl2e)) | > + (l2e_get_intpte(*pl2e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); > + ret = _mfn((l2e_get_pfn(*pl2e) & ~((1UL << PAGETABLE_ORDER) - 1)) + > + l1_table_offset(va)); > + goto out; > + } > + > + pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(va); > + shift = PAGE_SHIFT; > + if ( l1e_get_flags(*pl1e) & _PAGE_PRESENT ) > + { > + *flags = l1e_get_flags(*pl1e); > + ret = l1e_get_mfn(*pl1e); > + } > + > + out: > + L3T_UNLOCK(l3page); > + unmap_domain_page(pl1e); > + unmap_domain_page(pl2e); > + unmap_domain_page(pl3e); > + *nr = ((((va >> shift) + 1) << shift) - va) >> PAGE_SHIFT; > + return ret; > +} > +#endif /* CONFIG_SPARSE_DIRECTMAP */ > + > +/* > + * Free a page-table page that the hierarchy rooted at @root has stopped > + * using. idle_pg_table's hierarchy has pages from the boot allocator, > + * which the sparse directmap view maps along with every other boot-time > + * allocation: such a page leaves the sparse view before it reaches the > + * heap, and is kept if it cannot. That takes the sparse view's L3 lock > + * with an L3 lock of idle_pg_table's hierarchy held, the only order in > + * which the two nest. The sparse view's own page-tables come from the > + * heap, which it does not map, and are freed directly, as the caller may > + * hold the sparse view's L3 lock; so are tables freed straight after being > + * allocated, having lost a race to be installed. > + */ > +static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) > +{ > + if ( root == idle_pg_table && sparse_dmap_drop_pagetable(mfn) ) > + return; > + > + free_xen_pagetable(mfn); > +} > + > /* > * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or > * another hierarchy sharing its virtual addresses. > */ > -static int map_pages_in( > +int map_pages_in( > l4_pgentry_t *root, > unsigned long virt, > mfn_t mfn, > @@ -5503,10 +5597,10 @@ static int map_pages_in( > ol2e = l2t[i]; > if ( (l2e_get_flags(ol2e) & _PAGE_PRESENT) && > !(l2e_get_flags(ol2e) & _PAGE_PSE) ) > - free_xen_pagetable(l2e_get_mfn(ol2e)); > + free_pagetable_in(root, l2e_get_mfn(ol2e)); > } > unmap_domain_page(l2t); > - free_xen_pagetable(l3e_get_mfn(ol3e)); > + free_pagetable_in(root, l3e_get_mfn(ol3e)); > } > } > > @@ -5604,7 +5698,7 @@ static int map_pages_in( > flush_flags(l1e_get_flags(l1t[i])); > flush_area(virt, flush_flags); > unmap_domain_page(l1t); > - free_xen_pagetable(l2e_get_mfn(ol2e)); > + free_pagetable_in(root, l2e_get_mfn(ol2e)); > } > } > > @@ -5736,7 +5830,7 @@ static int map_pages_in( > flush_area(virt - PAGE_SIZE, > FLUSH_TLB_GLOBAL | > FLUSH_ORDER(PAGETABLE_ORDER)); > - free_xen_pagetable(l2e_get_mfn(ol2e)); > + free_pagetable_in(root, l2e_get_mfn(ol2e)); > } > else if ( locking ) > spin_unlock(&map_pgdir_lock); > @@ -5783,7 +5877,7 @@ static int map_pages_in( > flush_area(virt - PAGE_SIZE, > FLUSH_TLB_GLOBAL | > FLUSH_ORDER(2*PAGETABLE_ORDER)); > - free_xen_pagetable(l3e_get_mfn(ol3e)); > + free_pagetable_in(root, l3e_get_mfn(ol3e)); > } > else if ( locking ) > spin_unlock(&map_pgdir_lock); > @@ -5810,7 +5904,12 @@ int map_pages_to_xen( > unsigned long nr_mfns, > pte_attr_t flags) > { > - return map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); > + int rc = map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); > + > + if ( !rc ) > + rc = sparse_dmap_mirror_map(virt, mfn, nr_mfns, flags); > + > + return rc; > } > > int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) > @@ -5833,8 +5932,8 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) > * modify_mappings_in() does so in the hierarchy rooted at @root, as > * map_pages_in() does. > */ > -static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, > - unsigned long e, pte_attr_t nf) > +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, > + unsigned long e, pte_attr_t nf) > { > bool locking = system_state > SYS_STATE_boot; > l3_pgentry_t *pl3e = NULL; > @@ -6044,7 +6143,7 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, > if ( locking ) > spin_unlock(&map_pgdir_lock); > flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ > - free_xen_pagetable(l1mfn); > + free_pagetable_in(root, l1mfn); > } > else if ( locking ) > spin_unlock(&map_pgdir_lock); > @@ -6088,7 +6187,7 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, > if ( locking ) > spin_unlock(&map_pgdir_lock); > flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ > - free_xen_pagetable(l2mfn); > + free_pagetable_in(root, l2mfn); > } > else if ( locking ) > spin_unlock(&map_pgdir_lock); > @@ -6114,7 +6213,12 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, > > int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) > { > - return modify_mappings_in(idle_pg_table, s, e, nf); > + int rc = modify_mappings_in(idle_pg_table, s, e, nf); > + > + if ( !rc ) > + rc = sparse_dmap_mirror_modify(s, e, nf); > + > + return rc; > } > > int destroy_xen_mappings(unsigned long s, unsigned long e) > diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c > index bf980eba8c..f0a1197e62 100644 > --- a/xen/arch/x86/pv/dom0_build.c > +++ b/xen/arch/x86/pv/dom0_build.c > @@ -22,6 +22,7 @@ > #include > #include > #include > +#include > > /* Allow ring-3 access in long mode as guest cannot use ring 1 ... */ > #define BASE_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_USER) > @@ -651,6 +652,9 @@ static int __init dom0_construct(const struct boot_domain *bd) > while ( count-- ) > if ( assign_pages(mfn_to_page(_mfn(mfn++)), 1, d, 0) ) > BUG(); > + /* The initrd is dom0's now: out of the sparse directmap. */ > + if ( sparse_dmap_remove(_mfn(initrd_mfn), PFN_UP(initrd_len)) ) > + panic("Cannot unmap dom0's initrd\n"); > /* > * We have mapped the initrd directly into dom0, and assigned the > * pages. Tell the boot_module handling that we've freed it, so the > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index a636e3205c..e52388ad28 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -54,6 +54,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -1938,6 +1939,9 @@ void asmlinkage __init noreturn __start_xen(void) > > system_state = SYS_STATE_boot; > > + /* The heap now has all memory: page-tables come from it from here on. */ > + sparse_dmap_init(); > + > bsp_stack = cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ > if ( !bsp_stack ) > panic("No memory for BSP stack\n"); > diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c > new file mode 100644 > index 0000000000..1eb092c3ea > --- /dev/null > +++ b/xen/arch/x86/sparse-directmap.c > @@ -0,0 +1,424 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * A sparse view of the directmap. > + * > + * Xen maps all of RAM at DIRECTMAP_VIRT_START, and every root page-table > + * carries those mappings. The sparse view is a second set of page-tables > + * for the same virtual addresses (the part of the directmap PV guests can > + * see, which is where everything Xen reaches through the directmap lives), > + * mapping only what Xen needs to reach through the directmap at all times. > + * > + * Memory in the full directmap can be classified into three groups: > + * > + * - Memory never handed to the heap. This includes Xen's image, > + * boot-time allocations, and firmware tables. Mapped in the sparse > + * view. > + * - Memory handed to the heap, and not allocated to the xenheap. Not > + * mapped in the sparse view: guest memory will come from here. > + * - Memory handed to the heap, then allocated to the xenheap. Mapped > + * in the sparse view. > + * > + * Guest contexts selected on the command line run on root page-tables > + * carrying the sparse view's L3s in the directmap slots. > + * > + * Conceptually, the sparse view starts as a copy of the full directmap > + * (idle_pg_table's hierarchy), and then: > + * - Removes memory when it is handed to the heap. > + * - Adds pages back when they are allocated as xenheap pages, and removes > + * them again when they are freed. > + * - Mirrors changes to the full directmap (map_pages_to_xen(), > + * modify_xen_mappings()). > + * - Removes memory handed to a domain without passing through the heap > + * (a PV dom0's initrd, used in place), and page-tables the boot > + * allocator provided when idle_pg_table's hierarchy frees them. > + * > + * Every virtual address mapping in the sparse view should be either > + * identical to the corresponding full view mapping, or empty. > + * > + * The sparse view is built once the boot allocator has handed its > + * memory to the heap (sparse_dmap_init()). Until then, the hooks record > + * the ranges handed to the heap and the xenheap allocations made from > + * them, which sparse_dmap_init() leaves out and puts back. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +bool __ro_after_init opt_sparse_dmap_pv; > +bool __ro_after_init opt_sparse_dmap_hvm; Do we need an extra opt_sparse_dmap_dom0? So that dom0 can opt-out independently of everything else? > + > +/* Root of the sparse view: only ever walked and copied from, never loaded. */ > +static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIES]; > +l4_pgentry_t *__ro_after_init sparse_dmap_root; > + > +/* > + * Before the sparse view is built: the MFN ranges handed to the heap, which > + * it leaves out, and the xenheap allocations made meanwhile (heap metadata of > + * NUMA nodes), which it puts back. Explicitly mentioning NUMA node metadata is likely to go out of date, as changing that logic will most likely forget to update the comment here. > + */ > +struct mfn_range { > + unsigned long s, e; > +}; > +static struct mfn_range early_heap[256]; > +static unsigned int nr_early_heap; > +static struct mfn_range early_xenheap[2 * MAX_NUMNODES]; > +static unsigned int nr_early_xenheap; > +static bool early_overflow; > + > +/* > + * Clip [*mfn, *mfn + *nr) to what the sparse view covers; false if nothing is > + * left. > + */ > +static bool clip_to_sparse_view(unsigned long *mfn, unsigned long *nr) > +{ > + unsigned long end = SPARSE_DMAP_END_MFN; > + > + if ( *mfn >= end ) > + return false; > + if ( *nr > end - *mfn ) > + *nr = end - *mfn; > + > + return *nr; > +} > + > +static void early_range_add(struct mfn_range *r, unsigned int *nr, > + unsigned int max, unsigned long s, unsigned long e) > +{ > + if ( *nr && r[*nr - 1].e == s ) > + r[*nr - 1].e = e; > + else if ( *nr < max ) > + r[(*nr)++] = (struct mfn_range){ s, e }; > + else > + early_overflow = true; > +} > + > +static void early_range_del(struct mfn_range *r, unsigned int *nr, > + unsigned long s, unsigned long e) > +{ > + unsigned int i; > + > + for ( i = 0; i < *nr; i++ ) > + if ( r[i].s == s && r[i].e == e ) > + { > + r[i] = r[--*nr]; > + return; > + } > +} > + > +/* > + * Copy the full directmap's mappings of MFNs [mfn, mfn + nr) into the sparse > + * view. > + */ > +static int add_to_sparse_view(l4_pgentry_t *root, unsigned long mfn, > + unsigned long nr) > +{ > + unsigned long va = (unsigned long)mfn_to_virt(mfn); > + unsigned long end = va + (nr << PAGE_SHIFT); > + > + while ( va < end ) > + { > + pte_attr_t flags; > + unsigned long n; > + mfn_t m = xen_mapping_lookup(idle_pg_table, va, &flags, &n); > + int rc; Since you are fetching the mfn from the idle (non-sparse) page-tables, don't you want to check it matches the mfn passed as the function parameter? > + n = min(n, (end - va) >> PAGE_SHIFT); > + if ( !mfn_eq(m, INVALID_MFN) && > + (rc = map_pages_in(root, va, m, n, flags)) ) > + return rc; > + va += n << PAGE_SHIFT; > + } > + > + return 0; > +} > + > +static int remove_from_sparse_view(unsigned long mfn, unsigned long nr) > +{ > + unsigned long va = (unsigned long)mfn_to_virt(mfn); > + > + return modify_mappings_in(sparse_dmap_root, va, va + (nr << PAGE_SHIFT), > + _PAGE_NONE); > +} > + > +/* Memory is about to be handed to the heap allocator. */ > +bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) > +{ > + unsigned long s = mfn_x(mfn); > + > + if ( !sparse_dmap_configured() || !clip_to_sparse_view(&s, &nr) ) > + return true; > + > + if ( !sparse_dmap_root ) > + { > + early_range_add(early_heap, &nr_early_heap, ARRAY_SIZE(early_heap), > + s, s + nr); > + return true; > + } > + > + if ( remove_from_sparse_view(s, nr) ) > + { > + printk(XENLOG_ERR > + "sparse directmap: cannot unmap MFNs %#lx-%#lx, not freeing\n", > + s, s + nr - 1); > + return false; > + } > + > + return true; > +} > + > +/* > + * Xenheap pages enter the sparse view, which guest contexts run on: they > + * must not bring along what a previous owner left in them, such as a dying > + * domain's data still awaiting the scrubber. Pages needing scrubbing are > + * scrubbed as they are allocated then; clean ones need nothing. > + */ > +bool arch_xenheap_needs_scrub(void) > +{ > + return sparse_dmap_configured(); > +} > + > +/* Pages have been allocated from the heap as xenheap pages. */ > +int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) > +{ > + unsigned long s = mfn_x(mfn), nr = 1UL << order; > + > + if ( !sparse_dmap_configured() ) > + return 0; > + > + /* Xenheap pages must be reachable through the sparse view. */ > + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); > + > + if ( !sparse_dmap_root ) > + { > + early_range_add(early_xenheap, &nr_early_xenheap, > + ARRAY_SIZE(early_xenheap), s, s + nr); > + return 0; > + } > + > + return add_to_sparse_view(sparse_dmap_root, s, nr); > +} > + > +/* > + * Xenheap pages are about to be freed. A failure means the pages may still > + * be reachable through the sparse view, and must not be reused. > + */ > +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) > +{ > + unsigned long s = mfn_x(mfn), nr = 1UL << order; > + > + if ( !sparse_dmap_configured() ) > + return 0; > + > + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); > + > + if ( !sparse_dmap_root ) > + { > + early_range_del(early_xenheap, &nr_early_xenheap, s, s + nr); > + return 0; > + } > + > + return remove_from_sparse_view(s, nr); > +} > + > +/* Memory leaves Xen's hands without passing through the heap. */ > +int sparse_dmap_remove(mfn_t mfn, unsigned long nr) > +{ > + return arch_heap_pages_init(mfn, nr) ? 0 : -ENOMEM; > +} > + > +/* > + * A page-table page of idle_pg_table's hierarchy is about to be freed. One > + * the boot allocator provided is in the sparse view, as every boot-time > + * allocation is: take it out before the heap may hand it on. One allocated > + * since came from the heap and is not in the sparse view, which a lookup > + * finds without changing, or flushing, anything. Non-zero: the page may > + * still be mapped, and must not be freed. > + */ > +int sparse_dmap_drop_pagetable(mfn_t mfn) > +{ > + unsigned long s = mfn_x(mfn), nr = 1, n; > + pte_attr_t flags; > + int rc; > + > + if ( !sparse_dmap_root || !clip_to_sparse_view(&s, &nr) || > + mfn_eq(xen_mapping_lookup(sparse_dmap_root, > + (unsigned long)mfn_to_virt(s), &flags, &n), > + INVALID_MFN) ) > + return 0; > + > + rc = remove_from_sparse_view(s, 1); > + if ( rc ) > + printk(XENLOG_WARNING > + "Leaking page-table page %"PRI_mfn": still in the sparse directmap\n", > + mfn_x(mfn)); > + > + return rc; > +} > + > +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, > + pte_attr_t flags) > +{ > + if ( !sparse_dmap_root || virt < SPARSE_DMAP_START || > + virt >= SPARSE_DMAP_END ) > + return 0; > + > + nr = min(nr, (SPARSE_DMAP_END - virt) >> PAGE_SHIFT); > + > + return map_pages_in(sparse_dmap_root, virt, mfn, nr, flags); > +} > + > +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, > + pte_attr_t nf) > +{ > + unsigned long va; > + > + if ( !sparse_dmap_root || e <= SPARSE_DMAP_START || > + s >= SPARSE_DMAP_END ) > + return 0; > + > + s = max(s, SPARSE_DMAP_START); > + e = min(e, SPARSE_DMAP_END); > + > + if ( !(nf & _PAGE_PRESENT) ) > + return modify_mappings_in(sparse_dmap_root, s, e, nf); > + > + /* > + * A permission change applies where the sparse view maps anything: it > + * never creates mappings, and the sparse view need not map all of [s, e). > + */ > + for ( va = s; va < e; ) > + { > + pte_attr_t flags; > + unsigned long n; > + mfn_t m = xen_mapping_lookup(sparse_dmap_root, va, &flags, &n); > + int rc; > + > + n = min(n, (e - va) >> PAGE_SHIFT); > + if ( !mfn_eq(m, INVALID_MFN) && > + (rc = modify_mappings_in(sparse_dmap_root, va, > + va + (n << PAGE_SHIFT), nf)) ) > + return rc; > + va += n << PAGE_SHIFT; > + } > + > + return 0; > +} > + > +static int __init cf_check cmp_mfn_range(const void *a, const void *b) > +{ > + const struct mfn_range *l = a, *r = b; > + > + return l->s < r->s ? -1 : l->s > r->s; The last arm of this ternary operator is doing an implicit conversion from boolean to integer, I think that's not fine MISRA-wise? > +} > + > +static void __init cf_check swap_mfn_range(void *a, void *b) > +{ > + SWAP(*(struct mfn_range *)a, *(struct mfn_range *)b); > +} > + > +/* > + * Build the sparse view: the full directmap, minus the ranges handed to the > + * heap so far, plus the xenheap allocations made from them. Called once the > + * heap has taken over from the boot allocator, so that the page-tables come > + * from the heap, and before any other CPU is up. > + */ > +void __init sparse_dmap_init(void) > +{ > + unsigned long va, mapped = 0; > + unsigned int i, j; > + > + if ( !sparse_dmap_configured() ) > + return; > + > + if ( early_overflow ) > + { > + printk(XENLOG_WARNING > + "Sparse directmap: too many early heap ranges, disabled\n"); > + opt_sparse_dmap_pv = opt_sparse_dmap_hvm = false; > + return; > + } > + > + /* An L3 for every slot, so that the L4 entries never change. */ > + for ( va = SPARSE_DMAP_START; va < SPARSE_DMAP_END; > + va += 1UL << L4_PAGETABLE_SHIFT ) > + { > + mfn_t l3mfn; > + void *l3t = alloc_mapped_pagetable(&l3mfn); > + > + if ( !l3t ) > + panic("Sparse directmap: out of memory\n"); > + unmap_domain_page(l3t); > + sparse_l4[l4_table_offset(va)] = > + l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR); > + } > + > + sort(early_heap, nr_early_heap, sizeof(*early_heap), cmp_mfn_range, > + swap_mfn_range); > + > + /* > + * The full directmap, leaf by leaf, minus the ranges added to the > + * heap. Leaves come in address order, which is MFN order in the > + * directmap, so the cursor into the sorted (and disjoint) heap > + * ranges only moves forward. > + */ > + for ( va = SPARSE_DMAP_START, j = 0; va < SPARSE_DMAP_END; ) > + { > + pte_attr_t flags; > + unsigned long n, s, e; > + mfn_t m = xen_mapping_lookup(idle_pg_table, va, &flags, &n); > + > + n = min(n, (SPARSE_DMAP_END - va) >> PAGE_SHIFT); > + if ( mfn_eq(m, INVALID_MFN) ) > + { > + va += n << PAGE_SHIFT; > + continue; > + } > + > + for ( s = mfn_x(m), e = s + n; s < e; ) > + { > + unsigned long upto = e; > + > + while ( j < nr_early_heap && early_heap[j].e <= s ) > + j++; > + if ( j < nr_early_heap && early_heap[j].s <= s ) > + { > + s = min(e, early_heap[j].e); > + continue; > + } > + if ( j < nr_early_heap ) > + upto = min(e, early_heap[j].s); > + > + if ( map_pages_in(sparse_l4, va + ((s - mfn_x(m)) << PAGE_SHIFT), > + _mfn(s), upto - s, flags) ) Why use map_pages_in() directly here, instead of add_to_sparse_view()? > + panic("Sparse directmap: out of memory\n"); > + mapped += upto - s; > + s = upto; The above logic is complicated to follow, maybe some simple comments will help. > + } > + > + va += n << PAGE_SHIFT; > + } > + > + /* > + * Now add back in ranges from the heap which were allocated to > + * the xenheap. > + */ > + for ( i = 0; i < nr_early_xenheap; i++ ) > + { > + unsigned long nr = early_xenheap[i].e - early_xenheap[i].s; > + > + if ( add_to_sparse_view(sparse_l4, early_xenheap[i].s, nr) ) > + panic("Sparse directmap: out of memory\n"); > + mapped += nr; > + } > + > + sparse_dmap_root = sparse_l4; This logic involves a fair amount of calls to map_pages_in(), I think there will be no flushes in this case, because we are strictly populating the page-tables, and hence the old PTE will always be non-present. Worth confirming, otherwise we might need some TLB flush avoidance, as doing TLB flushes makes no sense here, the page-tables are not in use. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 18:40:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 18:40:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443677.1660839 (Exim 4.92) (envelope-from ) id 1xEt2K-0004OD-3e; Thu, 08 Oct 2026 18:40:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443677.1660839; Thu, 08 Oct 2026 18:40: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 1xEt2K-0004O6-07; Thu, 08 Oct 2026 18:40:12 +0000 Received: by outflank-mailman (input) for mailman id 1443677; Thu, 08 Oct 2026 18:40:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEt2I-0004O0-Tg for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 18:40:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEt2I-004ZRm-Af for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 20:40:10 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7e37b-2eae-0a2a0a5409dd-0a2a4505e2a2-14 for ; Thu, 08 Oct 2026 20:40:10 +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 6ac7e388-4cb1-0a2a45050019-aceafc1f8b44-3 for ; Thu, 08 Oct 2026 20:40:10 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 29FED43FF2; Thu, 8 Oct 2026 18:40:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A23C1F00893; Thu, 8 Oct 2026 18:40:08 +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 F1CFB380CEC8; Thu, 8 Oct 2026 18:40: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=1791484808; bh=XOy9VCsw6wr5foJLfeAQGfzThCHf/MXSMumL1DRZnYw=; h=Subject:From:Date:References:In-Reply-To:To:Cc; b=ZFnYGdAPg+aN8Gw6kFG2XdkqJEbC76kf//c4JAVpB/2G6RScHAir/8V9QeXXk58K0 RjT0DWozxc7Q1AEIULPkH9EbZ6PLRB/JQmLsbtPbZdU8x5gr6vmvljpQNGav+VYmcj 0UCsFLleKbCc9sSVpBxEctTVuc/Z3UOS7nfTPGAjgzXtbPoxBG8m87bH7M0KBimKq3 4IK+V6jWTtj9AJEEJc6oC+B0AMhz/fmj6CiehZP/dta3THNsLQiT85lRVD5JI2dLeB QRSUU2FF2org9dRKGS/TCqmMphP0Ok8eIw3MzOqJCSgyG9SBL7CRZUW76SVhIPNvUI WIc/JYfKvQlYQ== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH net] xen/netfront: don't leak the skb when xennet_fill_frags() fails From: patchwork-bot+netdevbpf@kernel.org Message-Id: <179148480652.386807.10828311641077520646.git-patchwork-notify@kernel.org> Date: Thu, 08 Oct 2026 18:40:06 +0000 References: <20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.com> In-Reply-To: <20261007-b4-xen-netfront-fill-frags-leak-v1-1-a8a01ff9cd52@toxicpanda.com> To: Josef Bacik Cc: jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, xen-devel@lists.xenproject.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org X-purgate-ID: tlsNG-c201ff/1791484810-72EB12A1-12B114C5/0/0 X-purgate-type: clean X-purgate-size: 871 Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski : On Wed, 07 Oct 2026 17:57:32 +0000 you wrote: > When a response chain has more slots than fit in the skb's frags, > xennet_fill_frags() returns an error and xennet_poll() jumps to its > error path. That path moves what's left on tmpq to errq to be freed, > but the skb being filled was already dequeued from tmpq, so it's never > freed. Each chain that overflows leaks the skb and the pages attached > to it as frags, and the backend decides how many slots it sends. > > [...] Here is the summary with links: - [net] xen/netfront: don't leak the skb when xennet_fill_frags() fails https://git.kernel.org/netdev/net/c/93ccaf1c26e2 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 Oct 08 18:40:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 18:40:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443678.1660848 (Exim 4.92) (envelope-from ) id 1xEt2Q-0004bX-96; Thu, 08 Oct 2026 18:40:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443678.1660848; Thu, 08 Oct 2026 18:40: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 1xEt2Q-0004bQ-6A; Thu, 08 Oct 2026 18:40:18 +0000 Received: by outflank-mailman (input) for mailman id 1443678; Thu, 08 Oct 2026 18:40:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEt2O-0004ar-Sg for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 18:40:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEt2O-005dXG-5u for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 20:40:16 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac7e35a-e002-0a2a0a5209dd-0a2a45098e74-42 for ; Thu, 08 Oct 2026 20:40:16 +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 6ac7e38e-be1a-0a2a45090019-ac6904fec0f8-3 for ; Thu, 08 Oct 2026 20:40:15 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 56811602D4; Thu, 8 Oct 2026 18:40:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B3471F00898; Thu, 8 Oct 2026 18:40:14 +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 F170C380CEC8; Thu, 8 Oct 2026 18:40: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="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=1791484814; bh=VkDY4ley1sWol3yb7WWyF4QJs3i/YJjEQTTXobutVZM=; h=Subject:From:Date:References:In-Reply-To:To:Cc; b=PJwc4GiZZYOldv17sp8Wbd5dZHYRxlbCEjXpM7m8KfHhoRfuJhF4nCkeNels1AOWY /c0T4I8kXGt2G7KecUytwwHjpgVOT7YC1e5z1uRqbzQgvUVjLYWza6peUvrIShJ6lk HBs9MRyZLz4WG6hsYhcf6kYCfxj/NZVtXM9I0NfTNGtegslWE2bGcPVUuBFAOXJVeS 33ERJzN7z5nuiRBHmB+xGRL7IqzOkfV4gA25LY3CjA5n49uGuxP5+/BfSYpkZpaBjq 1hbTGWcuC1T6L0aLRjYTXBTk/AyGuPVi8S4aSiyEFyeCsHCWmRrl8R9xnNxc1wAhvx SK7Mgbn4X/OAQ== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH net] xen/netfront: drop RX packets with a short Ethernet header From: patchwork-bot+netdevbpf@kernel.org Message-Id: <179148481252.386807.13451642616243196690.git-patchwork-notify@kernel.org> Date: Thu, 08 Oct 2026 18:40:12 +0000 References: <20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com> In-Reply-To: <20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com> To: Josef Bacik Cc: jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, chrisw@sous-sol.org, jeremy@xensource.com, jeff@garzik.org, xen-devel@lists.xenproject.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org X-purgate-ID: tlsNG-bad1c0/1791484816-BE2C4034-0066B19E/0/0 X-purgate-type: clean X-purgate-size: 1010 Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski : On Wed, 07 Oct 2026 17:55:40 +0000 you wrote: > handle_incoming_queue() pulls pull_to bytes into the head before > calling eth_type_trans(). pull_to is the length of the first RX slot, > capped at RX_COPY_THRESHOLD, and that length comes from the backend. > Nothing checks it against ETH_HLEN. > > If the first slot is shorter than ETH_HLEN and more slots follow, the > head ends up shorter than an Ethernet header while skb->len is longer, > and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is > shorter than ETH_HLEN, eth_type_trans() reads the header past the end > of the data instead. > > [...] Here is the summary with links: - [net] xen/netfront: drop RX packets with a short Ethernet header https://git.kernel.org/netdev/net/c/089e58805c45 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 Oct 08 18:51:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 18:51:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443692.1660857 (Exim 4.92) (envelope-from ) id 1xEtCz-0006yY-5I; Thu, 08 Oct 2026 18:51:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443692.1660857; Thu, 08 Oct 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 1xEtCz-0006yR-1z; Thu, 08 Oct 2026 18:51:13 +0000 Received: by outflank-mailman (input) for mailman id 1443692; Thu, 08 Oct 2026 18:51:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEtCx-0006yL-Lf for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 18:51:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEtCx-003Kj2-0t; Thu, 08 Oct 2026 18:51:11 +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 1xEtCw-00Diji-30; Thu, 08 Oct 2026 18:51: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" 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=VYqhasEhRNSfGGrb6kLfnXdw9k9YeeeavPia4FsnSV0=; b=oI1lhscId5HcTOkmv8O3CDJQ1I qHLss1p3cLlm7L8OJGgm58G7G1u8AnJYkQNwr7ZSY9sR8dqdkBblIxyHEBFVl2qyRRCTjJgWGtHOl lcQLhpUQN57fWoDP0mn+TWrGGqj5t65YDhd6VZBpdV19+0Ckbgn3Y+NDSyiWhHM48Jak=; Date: Thu, 8 Oct 2026 20:51:05 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 14/18] x86/domain_page: key the directmap fast paths on the loaded view Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-15-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261007104051.48841-15-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:47AM +0100, George Dunlap wrote: > map_domain_page() returns directmap addresses whenever it can: for any > MFN the directmap covers in release builds, and for vCPUs without a > mapcache. Once guest contexts may run on the sparse view of the > directmap, modify this to take the fast path returning the directmap > address only when the full directmap is loaded. > > The release-build shortcut ahead of the vCPU lookup looks at the vCPU > whose page-tables are loaded, without completing a lazy context > switch: if that vCPU is not on the sparse view, its page-tables map > the page through the directmap, and completing the switch would only > move the CPU to the idle vCPU's page-tables, which map it too. > > mapcache_current_vcpu() may complete the lazy context switch > (sync_local_execstate()) and switch us onto the idle vCPU (which has a > full view), so check again if we can use the directmap afterwards. > > A vCPU on the sparse view always has a mapcache: HVM ones through > per-vCPU page-tables, PV ones through the domain-wide mapcache, which > mapcache_domain_init() now sets up for a domain using the sparse view in > release builds too, rather than only when the directmap does not cover > all memory. > > map_domain_page_global() mappings must be valid in every context: use > vmap() for all of them once a sparse view is configured, as > arch_mfns_in_directmap() then says. > > Add d->arch.sparse_dmap and sparse_dmap_active for this; nothing sets > them yet. > > No functional change. > > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - New in this version. > --- > xen/arch/x86/domain_page.c | 44 +++++++++++++++++++-- > xen/arch/x86/include/asm/domain.h | 6 +++ > xen/arch/x86/include/asm/sparse-directmap.h | 8 ++++ > xen/arch/x86/sparse-directmap.c | 1 + > 4 files changed, 56 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > index 0500bb9dba..48f85b670d 100644 > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -61,6 +61,16 @@ static inline struct vcpu *mapcache_current_vcpu(void) > return ACCESS_ONCE(this_cpu(pgtable_vcpu)); > } > > +/* > + * Whether the directmap in @v's page-tables is the sparse view, which maps > + * none of the heap's memory beyond the xenheap: the mapcache must serve > + * every mapping then. > + */ > +static bool on_sparse_dmap(const struct vcpu *v) > +{ > + return sparse_dmap_active && v->domain->arch.sparse_dmap; > +} > + > /* > * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's > * otherwise, in which case *dcache is set so the caller takes the domain-wide > @@ -142,17 +152,39 @@ void *map_domain_page(mfn_t mfn) > > #ifdef NDEBUG > if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > - return mfn_to_virt(mfn_x(mfn)); > + { > + const struct vcpu *pt_vcpu = this_cpu(pgtable_vcpu); > + > + /* > + * The page-tables loaded map @mfn through the directmap, unless they > + * carry the sparse view. Don't complete a lazy context switch to > + * find out: it would only move this CPU to the idle vCPU's > + * page-tables, which map @mfn too. > + */ > + if ( !pt_vcpu || !on_sparse_dmap(pt_vcpu) ) > + return mfn_to_virt(mfn_x(mfn)); > + } > #endif > > + /* No vCPU (early boot), or no mapcache: the full directmap is loaded. */ > v = mapcache_current_vcpu(); > if ( !v ) > return mfn_to_virt(mfn_x(mfn)); > > +#ifdef NDEBUG > + /* The lookup may have completed a lazy switch off the sparse view. */ > + if ( !on_sparse_dmap(v) && > + mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > + return mfn_to_virt(mfn_x(mfn)); > +#endif > + > cache = vcpu_mapcache(v, &dcache); > vcache = &v->arch.mapcache; > if ( !cache->inuse ) > + { > + ASSERT(!on_sparse_dmap(v)); > return mfn_to_virt(mfn_x(mfn)); > + } > > perfc_incr(map_domain_page_count); > > @@ -307,7 +339,9 @@ void mapcache_domain_init(struct domain *d) > ASSERT(is_pv_domain(d)); > > #ifdef NDEBUG > - if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > + /* Not needed when the directmap loaded for the domain covers everything. */ > + if ( !d->arch.sparse_dmap && !mem_hotplug && > + max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > return; > #endif > > @@ -392,8 +426,12 @@ void *map_domain_page_global(mfn_t mfn) > system_state < SYS_STATE_active) || > local_irq_is_enabled())); > > + /* > + * Global mappings must hold in every context: a sparse view of the > + * directmap rules the directmap out. > + */ > #ifdef NDEBUG > - if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > + if ( arch_mfns_in_directmap(mfn_x(mfn), 1) ) > return mfn_to_virt(mfn_x(mfn)); > #endif > > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h > index 80415ab2c2..76a22b4040 100644 > --- a/xen/arch/x86/include/asm/domain.h > +++ b/xen/arch/x86/include/asm/domain.h > @@ -499,6 +499,12 @@ struct arch_domain > */ > bool vcpu_pt; > > + /* > + * Root page-tables carry the sparse view of the directmap, once it is > + * active (see asm/sparse-directmap.h). > + */ > + bool sparse_dmap; What do you mean with "once it is active"? Either a domain is using the sparse direct map or not, but it shouldn't have an external dependency on anything. Or maybe I'm reading the comment the wrong way. > + > /* Emulated devices enabled bitmap. */ > uint32_t emulation_flags; > } __cacheline_aligned; > diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h > index 48c1f3c951..512f8064d6 100644 > --- a/xen/arch/x86/include/asm/sparse-directmap.h > +++ b/xen/arch/x86/include/asm/sparse-directmap.h > @@ -22,6 +22,12 @@ extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm; > /* Root of the sparse view, once built (NULL before, or if not configured). */ > extern l4_pgentry_t *sparse_dmap_root; > > +/* > + * Set once guest contexts run on the sparse view: from then on, the root > + * page-tables of domains with d->arch.sparse_dmap carry it. > + */ > +extern bool sparse_dmap_active; Shouldn't sparse_dmap_active be opt_sparse_dmap_pv || opt_sparse_dmap_hvm? I'm afraid I don't understand the point of tracking whether there are domain using the sparse direct map or not, that's already tracked by d->arch.sparse_dmap? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 19:00:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 19:00:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443704.1660866 (Exim 4.92) (envelope-from ) id 1xEtMD-0000PC-VY; Thu, 08 Oct 2026 19:00:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443704.1660866; Thu, 08 Oct 2026 19: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 1xEtMD-0000P4-Rq; Thu, 08 Oct 2026 19:00:45 +0000 Received: by outflank-mailman (input) for mailman id 1443704; Thu, 08 Oct 2026 19:00:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEtMD-0000Oy-1f for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 19:00:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEtMA-003KwY-2F; Thu, 08 Oct 2026 19:00:42 +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 1xEtMA-00Dn4u-0u; Thu, 08 Oct 2026 19: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" 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=i5yaBIHn+0f5ortW46y9lHDI6574Zwvhg7IDwdSQtjk=; b=fTat1jUA0Hd2gvxu+T8oqQXK0n /zOFSgb7eu6k1hLY2t1g/0Je4ChC29Q0zVNIlQA3424/cHGEaks1pHGeeaeB88W9cmAxKVXXmJIWT GxRuxPBLHvJTad/II9t6xnweJVD/Ahjku62clHzvMwUGfjvxvq2lVNIW/vtoupP41qv4=; Date: Thu, 8 Oct 2026 21:00:40 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v3 15/18] x86/mm: flush owned pages before reuse with the sparse directmap view Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-16-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261007104051.48841-16-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:48AM +0100, George Dunlap wrote: > Since d7bf1b8ea275 ("x86/mm: limit deferred TLB flushing to PV domain > support") a page freed by its owner is flushed from TLBs before it is > handed out again only in builds with PV support, on the premise that PV > domains, with their (limited) control over the host MMU and over when > flushes happen, are the only ones to leave stale entries behind. > > Xen's transient mappings of domain pages are another source. The > mapcache zaps a slot when it is unmapped but defers the flush: the > slot's translation can stay in the TLB of the CPU which used it until > that CPU next flushes, by which time the page may have been freed and > handed to another domain. Before "x86/hvm: introduce per-vCPU > mapcache for vCPU-PT domains", only PV vCPUs use the mapcache, so the > PV condition covers it. Now that the vCPUs of an HVM domain with > per-vCPU page-tables have one as well. > > While the full directmap is loaded in every context, stale transient > mappings only map what's already mapped in the full directmap. On the > sparse view of the directmap, a stale translation of a page handed to > another domain would keep it reachable from a context which has > nothing to do with it. But if it's handed to another domain, then it also hasn't gone through a free cycle, which is what pg->u.free.need_tlbflush covers? > So flush owned pages before reuse wherever a sparse view is > configured, as before d7bf1b8ea275. In builds without PV support, > mark_page_free() now also asks a new hook, > arch_freed_pages_need_tlbflush(), declared with the xenheap hooks the > sparse view already uses. x86 answers with sparse_dmap_configured(); > without CONFIG_SPARSE_DIRECTMAP, and on other architectures, the > answer is no. Builds with PV support flush as before, and HVM-only > builds keep d7bf1b8ea275's saving unless a sparse view is configured, > which nothing does until a later patch. I think this is not fully correct, in fact I think we need to flush the map cache on every return to guest, otherwise you risk leaking contents between processes running on the same vCPU (and by extension the same physical CPU). We either need a flush flush before returning to guest, or we need to invalidate every page that unmapped from the mapcache. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 19:09:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 19:09:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443710.1660875 (Exim 4.92) (envelope-from ) id 1xEtUE-0001IR-Lg; Thu, 08 Oct 2026 19:09:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443710.1660875; Thu, 08 Oct 2026 19:09: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 1xEtUE-0001IK-Ih; Thu, 08 Oct 2026 19:09:02 +0000 Received: by outflank-mailman (input) for mailman id 1443710; Thu, 08 Oct 2026 19:09:01 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEtUD-0001IE-9O for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 19:09:01 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEtUC-003L7F-1d; Thu, 08 Oct 2026 19:09:00 +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 1xEtUC-00DqP3-0Z; Thu, 08 Oct 2026 19:09: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" 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=pL4BZT6JiKwWU1Tagwo1RutSMWGZUVear7peu41Yir4=; b=ZmX1T5c0H0CyWrDs11IUtugIBH KQXkGQrvhQ97W9I6V7eR0FkgyVX2NFSzCJw3cO83Ei3xXCxo3V63YwJDUQlP4DNkfmPlgxHLQUZ2m 8voIS22FDli92a9kXqHzHsdBHv781yDyIbksjSAGZ0QabwdJLoP/skFrrUmuop6/dEJ0=; Date: Thu, 8 Oct 2026 21:08:58 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 16/18] x86/domain_page: keep the maphash's slots, not their mappings Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-17-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261007104051.48841-17-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:49AM +0100, George Dunlap wrote: > unmap_domain_page() keeps a recently unmapped slot in the vCPU's > maphash (MAPHASH_ENTRIES, 8 per vCPU) for a quick remap of the same > MFN, and leaves its PTE in place until the entry is displaced by a later > unmap or reclaimed by a full cache. Until then the page stays mapped, > although nothing refers to the mapping and the mapcache holds no > reference to the page. A page freed meanwhile and handed to another > domain stays mapped in the previous user's mapcache: in the vCPU's own > area for a domain with per-vCPU page-tables, in the domain-wide area of > a PV domain, where all of its vCPUs can reach it. > > While the full directmap is loaded, that reaches nothing it does not > map anyway. On the sparse view of the directmap, Xen reaches > domain-heap memory only through mappings made for the purpose, and a > mapping kept in the maphash would leave another domain's page > reachable from a context which has nothing to do with it. > > Keep the slot, not the mapping: unmapping the last reference zaps the > PTE and keeps the hash entry, and a later hit maps the page again in the > same slot. The slot has mapped nothing else in between, so that needs > no flush. Reusing the slot for another page still goes through the > garbage map, or through the replacement of a hash entry when the cache > is full, both of which flush first. A translation of the zapped PTE > left in a TLB is covered, for owned pages, by the flush the page > allocator arranges before a freed page is reused wherever a sparse view > is configured ("x86/mm: flush owned pages before reuse with the sparse > directmap view"). As commented on the previous patch, I'm not convinced that's enough. I do think we need to do a flush here, as it's not so much as the page being used by another domain (or by Xen itself), internally the guest might also have different contexts and we should prevent leaks between them. > > The cost is one PTE write per unmap into the maphash and per remap from > it. A second unmap of an entry in the maphash now finds its PTE not > present and is caught by the check unmap_domain_page() has for entries > the first unmap zapped, rather than by the reference count's ASSERT() > in debug builds only. > > The change does not depend on asi= or on a sparse view of the directmap > being configured. PV vCPUs use the domain-wide mapcache on the default > command line too: in debug builds for every page, in release builds for > pages beyond the reach of the full directmap in their page-tables (5TiB, > 3.5TiB with CONFIG_BIGMEM). There's likely no need to mention again the exact conditions that make the mapcache active for PV domains, that's IMO too verbose and doesn't add anything of value to the reasoning here. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 19:22:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 19:22:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443726.1660885 (Exim 4.92) (envelope-from ) id 1xEtgg-0004NY-Ny; Thu, 08 Oct 2026 19:21:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443726.1660885; Thu, 08 Oct 2026 19: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 1xEtgg-0004NR-KV; Thu, 08 Oct 2026 19:21:54 +0000 Received: by outflank-mailman (input) for mailman id 1443726; Thu, 08 Oct 2026 19:21:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEtgf-0004NL-Si for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 19:21:53 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEtge-003LJQ-1A; Thu, 08 Oct 2026 19:21: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 1xEtge-00DvIr-02; Thu, 08 Oct 2026 19:21: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=9RTE3YC/cHJsybbYC3CDYIQUmhKWeBgXwQe/2+R7VeA=; b=JSSROQfOCeJvhhX1vTya00qr2J C03I1zFntCojb0DGF/jkHAhN260twbBWEy/TW1WP+eHc844RH8V+a2u/fPYIpeG7eTt4JqyO/tl/B 1tC0ttvdUk0ShyLrEHZlFCtXXOHiKE6SbLFaX6pYGwOhmebeelZTZTfEJqnv1qNBLEuk=; Date: Thu, 8 Oct 2026 21:21:50 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , Teddy Astie Subject: Re: [PATCH v3 18/18] x86/spec-ctrl: wire the sparse directmap view into the asi= option Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-19-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261007104051.48841-19-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:51AM +0100, George Dunlap wrote: > Let asi= choose which domains run on the sparse view of the directmap, > when the hypervisor is built with CONFIG_SPARSE_DIRECTMAP: > > * `asi` and `asi=` enable or disable the sparse view, along with > vCPU-PT, for every domain: HVM and PV guests, and the hardware > domain, PV or PVH. HVM guests, a PVH hardware domain included, use > the sparse view together with vCPU-PT, which gives them the mapcache > it needs; PV guests all have one. A PV guest on the sparse view > keeps its domain-wide mapcache and per-domain mappings: the sparse > view separates it from other domains, not its vCPUs from each other. > > * `asi=hvm=`, and new `asi=pv=` and `asi=dom0=`, do > the same for HVM or PV guests other than the hardware domain, or for > the hardware domain, whatever its type: `asi=1,dom0=0` leaves the > hardware domain out of ASI altogether. > > * A new `asi=directmap=` selects the sparse view for all domains, > as `asi=vcpu-pt=` selects vCPU-PT; `vcpu-pt=` alone leaves the > sparse view off. On a hypervisor built without > CONFIG_SPARSE_DIRECTMAP the forms enabling all features leave the > sparse view off, and `directmap=` is ignored with a warning. A guest > type the build lacks is ignored, so that the sparse view is not built > for nothing. > > * Only one of XPTI and the sparse view are enabled. Enabled > explicitly, for dom0, domUs or both, XPTI takes precedence: the PV > domains it covers keep the full directmap, and the boot log says > so. Left to its default, XPTI yields: it is disabled for the PV > domains using the sparse view, with a boot-log warning where it > would otherwise be enabled, as the sparse view does not replace it > yet (it still maps the xenheap and Xen's stacks). Each domain's > case is settled at its creation. > > The boot log gains a line with the directmap mode, "sparse" once a > sparse view is configured and "full" otherwise, and the "ASI features > for ..." lines, one for PV guests now among them, say which domains use > the sparse view. > > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - New in this version. > --- > docs/misc/xen-command-line.pandoc | 35 +++++- > xen/arch/x86/include/asm/sparse-directmap.h | 28 ++++- > xen/arch/x86/sparse-directmap.c | 4 +- > xen/arch/x86/spec_ctrl.c | 130 ++++++++++++++++++-- > 4 files changed, 171 insertions(+), 26 deletions(-) > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 785e099c0a..0bbc8ebeff 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -203,7 +203,8 @@ to appropriate auditing by Xen. Argo is disabled by default. > buggy or malicious other domain spamming the ring. > > ### asi (x86) > -> `= List of [ , hvm=, vcpu-pt= | vcpu-pt=hvm= ]` > +> `= List of [ , {pv,hvm,dom0}=, directmap=, > +> vcpu-pt= | vcpu-pt=hvm= ]` > > > Default: `false` > > @@ -214,12 +215,16 @@ 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. > > -The mechanisms currently implemented apply to HVM guests, including a PVH > -hardware domain. PV guests, including a PV hardware domain, are unaffected. > +The mechanisms currently implemented are `vcpu-pt`, for HVM guests including > +a PVH hardware domain, and `directmap`, for all guests including the hardware > +domain, PV or PVH. The plain boolean enables or disables both, wherever they > +apply. > > -* `hvm=` enables the features for HVM guests other than the hardware domain, > - which follows the whole-feature forms (the plain boolean, or an un-suffixed > - `vcpu-pt=`). > +* `pv=`, `hvm=` and `dom0=` enable the features for PV guests or HVM guests > + other than the hardware domain, or for the hardware domain, PV or PVH. The > + plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain > + out. The forms naming no guest type (an un-suffixed `vcpu-pt=`, and > + `directmap=`) cover the hardware domain too. Shouldn't this generic pv, hvm, dom0 set of values go in at the same time that `hvm=` is defined? That would avoid having to re-write the paragraph that's been added on this same series. > > **WARNING: manual de-selection of enabled options will invalidate any > protection offered by the feature. The fine grained options provided below > @@ -228,6 +233,18 @@ are meant to be used for debugging purposes only.** > * `vcpu-pt` gives each vCPU its own per-domain area: the per-domain slot of > each vCPU's monitor table maps a region private to that vCPU. > > +* `directmap` (only available when Xen is built with > + `CONFIG_SPARSE_DIRECTMAP`) runs guest contexts on a sparse view of the > + directmap, which maps the memory Xen needs to reach at all times (the Xen > + heap, Xen's own image, firmware tables), while guest memory is mapped > + transiently. This selection is system-wide; `pv=`, `hvm=` and `dom0=` > + make it for one guest type, along with the other features. HVM guests use > + the sparse view only together with `vcpu-pt`, and PV guests only without > + XPTI, which yields to the sparse view unless enabled explicitly (see > + `xpti`). The whole-feature forms (`asi`, `asi=`, and `pv=`, `hvm=` > + and `dom0=`) set this too, on builds that support it; on other builds they > + leave it off, and `directmap` is ignored with a warning. > + > ### asid (x86) > > `= ` > > @@ -3118,6 +3135,12 @@ Meltdown for all domains. > With `dom0` and `domu` it is possible to control page table isolation > for dom0 or guest domains only. > > +With `asi`, XPTI and the sparse directmap view (`asi=directmap`) exclude each > +other for a PV guest. Enabled explicitly, as a whole or with `dom0` or > +`domu`, XPTI keeps the PV guests it covers off the sparse view, and the boot > +log says so. Left to its default, XPTI is disabled for the PV guests using > +the sparse view, with a boot-log warning where it would otherwise be enabled. > + > ### xsave (x86) > > `= ` > > diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h > index 41866b77e9..5349b2ba62 100644 > --- a/xen/arch/x86/include/asm/sparse-directmap.h > +++ b/xen/arch/x86/include/asm/sparse-directmap.h > @@ -17,7 +17,11 @@ > #define SPARSE_DMAP_END HYPERVISOR_VIRT_END > #define SPARSE_DMAP_END_MFN (virt_to_mfn(SPARSE_DMAP_END - 1) + 1) > > -extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm; > +/* > + * Which domains use the sparse view: PV guests and HVM guests other than the > + * hardware domain, and the hardware domain, PV or PVH. > + */ > +extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm, opt_sparse_dmap_hwdom; > > /* Root of the sparse view, once built (NULL before, or if not configured). */ > extern l4_pgentry_t *sparse_dmap_root; > @@ -30,13 +34,22 @@ extern bool sparse_dmap_active; > > static inline bool sparse_dmap_configured(void) > { > - return opt_sparse_dmap_pv || opt_sparse_dmap_hvm; > + return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; The opt_sparse_dmap_hwdom definition should be part of the patch that adds opt_sparse_dmap_pv and opt_sparse_dmap_hvm (I've already commented there I think). > } > > -/* Whether a new domain of the given type is to use the sparse view. */ > -static inline bool sparse_dmap_wanted(bool pv) > +static inline bool sparse_dmap_pv(void) { return opt_sparse_dmap_pv; } > +static inline bool sparse_dmap_hvm(void) { return opt_sparse_dmap_hvm; } > +static inline bool sparse_dmap_hwdom(void) { return opt_sparse_dmap_hwdom; } > + > +/* > + * Whether a new domain of the given type is to use the sparse view. The > + * hardware domain, PV or PVH, has a knob of its own. > + */ > +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) > { > - return sparse_dmap_root && (pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); > + return sparse_dmap_root && > + (hwdom ? opt_sparse_dmap_hwdom > + : pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); > } > > void sparse_dmap_init(void); > @@ -54,7 +67,10 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); > #define sparse_dmap_active false > > static inline bool sparse_dmap_configured(void) { return false; } > -static inline bool sparse_dmap_wanted(bool pv) { return false; } > +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { return false; } > +static inline bool sparse_dmap_pv(void) { return false; } > +static inline bool sparse_dmap_hvm(void) { return false; } > +static inline bool sparse_dmap_hwdom(void) { return false; } > static inline void sparse_dmap_init(void) {} > static inline void sparse_dmap_activate(void) {} > static inline void sparse_dmap_install(l4_pgentry_t *l4t, bool pv) {} > diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c > index 54a6e36132..4fe160dad3 100644 > --- a/xen/arch/x86/sparse-directmap.c > +++ b/xen/arch/x86/sparse-directmap.c > @@ -55,6 +55,7 @@ > > bool __ro_after_init opt_sparse_dmap_pv; > bool __ro_after_init opt_sparse_dmap_hvm; > +bool __ro_after_init opt_sparse_dmap_hwdom; > > /* Root of the sparse view: only ever walked and copied from, never loaded. */ > static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIES]; > @@ -358,7 +359,8 @@ void __init sparse_dmap_init(void) > { > printk(XENLOG_WARNING > "Sparse directmap: too many early heap ranges, disabled\n"); > - opt_sparse_dmap_pv = opt_sparse_dmap_hvm = false; > + opt_sparse_dmap_pv = opt_sparse_dmap_hvm = opt_sparse_dmap_hwdom = > + false; > return; > } > > diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c > index 46105ef185..65e1d14861 100644 > --- a/xen/arch/x86/spec_ctrl.c > +++ b/xen/arch/x86/spec_ctrl.c > @@ -390,6 +390,19 @@ int8_t __ro_after_init opt_xpti_domu = -1; > > static __init void xpti_init_default(void) > { > + /* > + * XPTI and the sparse directmap view exclude each other for a PV domain > + * (see spec_ctrl_init_domain()). Enabled explicitly, XPTI takes > + * precedence: the PV domains it covers stay off the sparse view. Left to > + * its default, it yields: it is off where the sparse view is asked for. > + */ > + if ( !opt_dom0_pvh && opt_xpti_hwdom == 1 && sparse_dmap_hwdom() ) > + printk(XENLOG_ERR > + "XPTI enabled, disabling Dom0 sparse-directmap\n"); > + if ( opt_xpti_domu == 1 && sparse_dmap_pv() ) > + printk(XENLOG_ERR > + "XPTI enabled, disabling PV DomU sparse-directmap\n"); > + > if ( (boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) || > cpu_has_rdcl_no ) > { > @@ -400,10 +413,23 @@ static __init void xpti_init_default(void) > } > else > { > + bool yield_hwdom = opt_xpti_hwdom < 0 && !opt_dom0_pvh && > + sparse_dmap_hwdom(); > + bool yield_domu = opt_xpti_domu < 0 && sparse_dmap_pv(); > + > + /* > + * The default is on here, so alert the user when it yields. > + */ > + if ( yield_hwdom || yield_domu ) > + printk(XENLOG_WARNING > + "XPTI defaults off for PV %s on the sparse directmap\n", > + yield_hwdom ? (yield_domu ? "Dom0 and DomU" : "Dom0") > + : "DomU"); > + > if ( opt_xpti_hwdom < 0 ) > - opt_xpti_hwdom = 1; > + opt_xpti_hwdom = !sparse_dmap_hwdom(); > if ( opt_xpti_domu < 0 ) > - opt_xpti_domu = 1; > + opt_xpti_domu = !sparse_dmap_pv(); > } > } > > @@ -494,6 +520,33 @@ static int __init cf_check parse_pv_l1tf(const char *s) > } > custom_param("pv-l1tf", parse_pv_l1tf); > > +/* > + * The sparse directmap view, for PV guests and HVM guests other than the > + * hardware domain, and for the hardware domain, PV or PVH. A guest type the > + * build lacks can't use the sparse view, and doesn't get it built. Without > + * CONFIG_SPARSE_DIRECTMAP there is no sparse view: the forms enabling all > + * features, generally or for one guest type, leave it off. > + */ > +static void __init set_sparse_dmap(bool pv, bool hvm, bool hwdom, bool val) > +{ > +#ifdef CONFIG_SPARSE_DIRECTMAP > + if ( pv && IS_ENABLED(CONFIG_PV) ) > + opt_sparse_dmap_pv = val; > + if ( hvm && IS_ENABLED(CONFIG_HVM) ) > + opt_sparse_dmap_hvm = val; > + if ( hwdom ) > + opt_sparse_dmap_hwdom = val; > +#endif > +} > + > +/* > + * An explicit asi=directmap on a build without the sparse directmap view. > + * Warned about from init_speculation_mitigations(): printed while the command > + * line is parsed, the message would stay in the console ring, and not reach > + * the console. > + */ > +static bool __initdata asi_directmap_ignored; > + > static int __init cf_check parse_asi(const char *s) > { > const char *ss; > @@ -501,7 +554,10 @@ static int __init cf_check parse_asi(const char *s) > > /* Interpret 'asi' alone in its positive boolean form. */ > if ( *s == '\0' ) > + { > opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = true; > + set_sparse_dmap(true, true, true, true); > + } > > do { > ss = strchr(s, ','); > @@ -514,11 +570,29 @@ static int __init cf_check parse_asi(const char *s) > case 0: > case 1: > opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; > + set_sparse_dmap(true, true, true, val); > break; > > default: > - if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) > + if ( (val = parse_boolean("pv", s, ss)) >= 0 ) > + set_sparse_dmap(true, false, false, val); > + else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) > + { > opt_vcpu_pt_hvm = val; > + set_sparse_dmap(false, true, false, val); > + } > + else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) > + { > + opt_vcpu_pt_hwdom = val; > + set_sparse_dmap(false, false, true, val); > + } > + else if ( (val = parse_boolean("directmap", s, ss)) >= 0 ) > + { > + /* System-wide: every guest type, the hardware domain too. */ > + set_sparse_dmap(true, true, true, val); > + asi_directmap_ignored = val && > + !IS_ENABLED(CONFIG_SPARSE_DIRECTMAP); I think we should return error here, rather than print a warning: we don't do this for any other command line option that's not parsed because the required support has been compiled out. > + } > else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) > { > switch ( val ) > @@ -744,13 +818,35 @@ static void __init print_details(enum ind_thunk thunk) > opt_pv_l1tf_domu ? "enabled" : "disabled"); > #endif > > - /* vCPU-PT is implemented for HVM only: a PV Dom0 gets none of it. */ > - printk(" ASI features for Dom0:%s\n", > - opt_dom0_pvh && opt_vcpu_pt_hwdom ? " vCPU-PT" : " None"); > + /* > + * vCPU-PT is implemented for HVM only, and HVM guests use the sparse > + * directmap only with it; PV guests for which XPTI is enabled don't use > + * it (see xpti_init_default()). Dom0 is listed as its type makes it. I'm not sure this comment is very useful, and it will keep growing as more features are added. The set of available options is clearly seen in the logic below, and I don't think it deserves the extra comment. > + */ > + { > + bool hwdom_pt = opt_dom0_pvh && opt_vcpu_pt_hwdom; > + bool hwdom_sd = sparse_dmap_hwdom() && > + (opt_dom0_pvh ? hwdom_pt : !opt_xpti_hwdom); > + > + printk(" ASI directmap mode: %s\n", > + sparse_dmap_configured() ? "sparse" : "full"); > + printk(" ASI features for Dom0:%s%s%s\n", > + hwdom_pt || hwdom_sd ? "" : " None", > + hwdom_pt ? " vCPU-PT" : "", > + hwdom_sd ? " sparse-directmap" : ""); > #ifdef CONFIG_HVM > - printk(" ASI features for HVM VMs:%s\n", > - opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); > + printk(" ASI features for HVM VMs:%s%s%s\n", > + opt_vcpu_pt_hvm ? "" : " None", > + opt_vcpu_pt_hvm ? " vCPU-PT" : "", > + opt_vcpu_pt_hvm && sparse_dmap_hvm() > + ? " sparse-directmap" : ""); > #endif > +#ifdef CONFIG_PV > + printk(" ASI features for PV VMs:%s\n", > + sparse_dmap_pv() && !opt_xpti_domu > + ? " sparse-directmap" : " None"); > +#endif > + } > } > > static bool __init check_smt_enabled(void) > @@ -1942,11 +2038,14 @@ void spec_ctrl_init_domain(struct domain *d) > : opt_vcpu_pt_hvm); > > /* > - * The sparse directmap view needs a mapcache: PV domains all have one, > - * HVM domains through per-vCPU page-tables. > + * The sparse directmap view needs a mapcache: PV domains all have > + * one, HVM domains through per-vCPU page-tables. Left to its In principle HVM domains could also use the per-domain mapcache, I don't think we should tie the sparse dmap to HVM domains use per-vCPU mapcaches. The point of having the fine-grained options is to enable them on such fine grained basis. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 08 20:55:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 20:55:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443787.1660893 (Exim 4.92) (envelope-from ) id 1xEv92-0001lt-6G; Thu, 08 Oct 2026 20:55:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443787.1660893; Thu, 08 Oct 2026 20:55: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 1xEv92-0001la-0i; Thu, 08 Oct 2026 20:55:16 +0000 Received: by outflank-mailman (input) for mailman id 1443787; Thu, 08 Oct 2026 20:55:14 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEv90-0001lU-HV for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 20:55:14 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEv90-003Mzt-11 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 20:55:14 +0000 Received: from mail-lf1-f52.google.com ([209.85.167.52]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xEv90-00EOsT-0r for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 20:55:14 +0000 Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-5ba4180a65aso3035332e87.2 for ; Thu, 08 Oct 2026 13:55: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" 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=v6wA9GWm1MKmhpwSeNomqmtmSSNtaCoK1KF40RRj4zU=; b=2KRssqrHNiu9RcwClugEOjW+gM XfoNCuyQo2UajVZ0f1qi39vs+CW6ZfSgUdcMyaGLfdadE9LkdO2e0l2mzkzvDx2tHncQ/R1o5fDKZ NoXmcmbIZQgXvUA8b8ZIG0GAUW/G9uh/2oyFz+F2NZANHqFMI/hiud7tfob9japTRh0s=; X-Gm-Message-State: AFq9FYL1/LulIJt60RUHTwCMXnxu13kgYUhxaFoWE+cIUCh+d1HRMEmg hkedHBdb/zkDoAEfsChBnos/9xRCT4+kM4TDVz7bGyMtOyOV/u7zabelpQxjDgNi79MnIQcsI1e 2GibUlF76J/3U/xBqIzyydk5YmQJhTis= X-Received: by 2002:a05:6512:138d:b0:5b6:1870:268b with SMTP id 2adb3069b0e04-5bcd0745ecemr2505923e87.60.1791492913158; Thu, 08 Oct 2026 13:55:13 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-8-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Thu, 8 Oct 2026 21:55:00 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9jfQ8RFRvqUVEV7O7LZ66NfI6eULQQL1gV9Z2lwmjqBFBPYefs365iNCg Message-ID: Subject: Re: [PATCH v3 07/18] x86/hvm: introduce per-vCPU L3 page-table To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie , Tim Deegan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2026 at 8:21=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:40AM +0100, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > The per-domain area is currently a single domain-wide structure: one L3= , > > nit: s/structure/entry/ might be better? Not sure why? After this change, there's still a single perdomain entry; but each vCPU has its own tree, whereas previously there was only a single tree. A tree is a structure. I could change it to "tree" if you want, but I'm not sure that's any cleare= r. > > Give init_xen_l4_slots() the vCPU a table is private to, and use > > Can't you replace the domain parameter with a vcpu one, and obtain > domain as v->domain? [snip] - > > Changes in v3: > > - HVM only: PV domains keep the domain-wide area, so the PV parts go > > (the single-vCPU limit, the shadow refusals, the XPTI slot install). > > init_xen_l4_slots() takes the vCPU as an extra, optional argument > > rather than in place of the domain, so PV guest L4s, which no vCPU > > owns, are promoted exactly as before. > > Hm, I see, so this is the reason. PV L4s are promoted ahead of being > loaded into a vCPU %cr3, and hence when init_xen_l4_slots() is called > the per-vCPU L3 to use is not clear. Right, so your v2 passed d->vcpu[0] in a couple of places where there was no current cpu (e.g., dom0 creation). I think the reason this version ended up this way is that in theory, the toolstack could do something that would cause promote_l4_table() to be called before the vcpus are created (by XEN_DOMCTL_max_vcpus). If we have init_xen_l4_slots() take only a vcpu argument, we'd have to modify that to check that d->vcpu[0] existed, and fail the call if not; and any toolstack that did promote an l4 before creating the vCPUs would stop working. As it happens, libxc / libxl always call max_vcpus first. So I think failing the call would be OK. Then most of the sites would just take a single argument, and Jan's question about 32-bit PV guests just goes away. I'll give that a try and see how it looks, unless someone has an objection. > > @@ -525,12 +525,12 @@ int arch_vcpu_create(struct vcpu *v) > > */ > > rc =3D create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, NU= LL, NULL); > > if ( rc ) > > - return rc; > > + goto fail_early; > > > > paging_vcpu_init(v); > > > > if ( (rc =3D vcpu_init_fpu(v)) !=3D 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 =3D NULL; > > + fail_early: > > + free_pervcpu_mappings(v); > > Do we really need the extra label? It would seem to me like the > existing cleanup functions are harmless to execute regardless of > whether the matching initialization routine has been called. Huh, just noticed that all the fail paths call all the cleanup functions, regardless of whether they need to be cleaned up. OK, yeah, we can do the same thing. > > + free_perdomain_l3(v->arch.pervcpu_l3_pg); > > + v->arch.pervcpu_l3_pg =3D NULL; > > We have been (recently) following the model of first setting the > pointer to NULL, and then freeing it, ie: > > struct page_info *l3_pg =3D v->arch.pervcpu_l3_pg; > > if ( !l3_pg ) > return; > > v->arch.pervcpu_l3_pg =3D NULL; > free_perdomain_l3(l3_pg); > > Like XFREE() and similar macros. It's possibly worth using the same > pattern here. Ack. -George From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:00:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:00:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443795.1660903 (Exim 4.92) (envelope-from ) id 1xEvEO-0003U5-NN; Thu, 08 Oct 2026 21:00:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443795.1660903; Thu, 08 Oct 2026 21:00: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 1xEvEO-0003Ty-IY; Thu, 08 Oct 2026 21:00:48 +0000 Received: by outflank-mailman (input) for mailman id 1443795; Thu, 08 Oct 2026 21:00:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvEN-0003Ts-8a for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:00:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xEvEM-003N7t-36 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:00:46 +0000 Received: from mail-lf1-f52.google.com ([209.85.167.52]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xEvEM-00ERMn-2y for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:00:46 +0000 Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-5ba7ed32ccdso6632537e87.0 for ; Thu, 08 Oct 2026 14:00: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" 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=BHNmwhHspsXjbVq1MwXZ29V6oW901isliLvupE29bdo=; b=Eh6Oqk6rj3lg476Y8OybzNnLPy vTX2Ft4ptHRFaA3Y6i0RTsed++HIAslsLcSVt9Th1u6571pgziyVTUh8UUzZzQmTC92cQzaiGMLvw Mk5612fBqlBI5FU1wf+gLXNiYUpDozIr947GTftZh2t1IxdDGvf4xhb9p6UKyZkUHaVI=; X-Forwarded-Encrypted: i=1; AKwUvBwyOKLROMoGxcvErZw8GB6EOtegJpyXr5c3BZWhubL82BXKXn82t4BiXaGqnaluIGw6hrUNDOOBpKQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYK5zE+7Qenrg1qKjSeoa12cr+t9AQyhtq4j7WAnjWxwMUDPm+U0 TCCYgPvOXAxj+oqbCeYcZbbkff0K1RZuxqDBeDkLtYd6kkLWD8DcbtDz4GgZC7ixQxDkVuktDR7 7FwXbgUNQPQEUu47hA/dl41fluB1tMp8= X-Received: by 2002:a05:6512:1194:b0:5ba:3fb8:1827 with SMTP id 2adb3069b0e04-5bcd06de59bmr2609729e87.22.1791493245812; Thu, 08 Oct 2026 14:00:45 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-8-gwd@xenproject.org> <7bced27f-5391-4120-b9cf-b97bb88758ca@suse.com> In-Reply-To: <7bced27f-5391-4120-b9cf-b97bb88758ca@suse.com> From: George Dunlap Date: Thu, 8 Oct 2026 22:00:33 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8tQjUV8hPeDeijLFaQArX23oiUw3phOTs2-y32JTi9WqjVbgJNX68-Wkw Message-ID: Subject: Re: [PATCH v3 07/18] x86/hvm: introduce per-vCPU L3 page-table To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Tim Deegan , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 9:40=E2=80=AFAM Jan Beulich wrot= e: > > On 07.10.2026 12:40, George Dunlap wrote: > > @@ -1835,7 +1853,7 @@ static int promote_l4_table(struct page_info *pag= e) > > if ( !rc ) > > { > > init_xen_l4_slots(pl4e, l4mfn, > > - d, INVALID_MFN, VM_ASSIST(d, m2p_strict)); > > + d, NULL, INVALID_MFN, VM_ASSIST(d, m2p_stric= t)); > > Nit: Take the opportunity and re-flow the statement (i.e. move more args > onto the 1st line)? Ack > > --- 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 =3D page_to_mfn(pg); > > l4tab =3D 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->domain, v, INVALID_MFN, false); > > This being PV-only code, don't you want to pass NULL here? The descriptio= n > talks about this, but (a) it's not quite clear why PV32 would want handli= ng > differently from PV64 at this point and (b) in sh_make_shadow() you do pa= ss > NULL unconditionally. This is actually left over from the previous iteration of the series which supports PV guests; and apparently it would be a lot easier for implement per-vCPU pagetables for 32-bit PV guests, since the L4 doesn't belong to the guest. But it's outside of the scope of the current work. At any rate, I'm going to try passing a single vcpu, as Roger suggested. That restricts toolstacks to not being able to promote PV L4s before calling XEN_DOMCTL_max_vcpus, but that seems fine to me. -George From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443800.1660910 (Exim 4.92) (envelope-from ) id 1xEvGs-00046B-2a; Thu, 08 Oct 2026 21:03:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443800.1660910; Thu, 08 Oct 2026 21: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 1xEvGr-000460-UM; Thu, 08 Oct 2026 21:03:21 +0000 Received: by outflank-mailman (input) for mailman id 1443800; Thu, 08 Oct 2026 21:03:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvGq-00045s-Fr for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvGp-00Dgxi-T3 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:19 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac804ff-2eae-0a2a0a5409dd-0a2a4504996c-34 for ; Thu, 08 Oct 2026 23:03:19 +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 6ac80516-b57f-0a2a45040019-d155a0aae0aa-3 for ; Thu, 08 Oct 2026 23:03:19 +0200 Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-5338f65913dso60592461cf.2 for ; Thu, 08 Oct 2026 14:03:19 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5359b7dd1a0sm3101431cf.27.2026.10.08.14.03.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=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=1791493398; x=1792098198; 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=veWMGuSVswTQSpRQuCY1UJnPdK7Vk9Kj0h3fikv2+bk=; b=lOhict64goEkLiXbsm/Ks8z7FJQkwMOCblP9e1I9yXFIdSQuaM0MV7A2MmulKJ0eD6 FbKyNBFGQP2jE7kjJAPWXxQUfKgDvJBIWyp60COFsjnRbCkVt99H+4hWyYVLb4/Fok25 IATSb4Li02kY54CaaHTHDyUPltOe0b0pIqIAx8+FjntgedNvnzb5vxR3RQhA8Q01PGeq xXeUdEevkk39uE5o7bZ/y6cKrd1Sm94rSOnmM+AZTK1f5afd3fwRhZoTveVgIp6Yy9SO djGoS7unPY27N2HyddB+TGEN/GudrYincCfv9uwCByouO8CGfYvNn1TeuDxO7KBQgk0c EHcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493398; x=1792098198; 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=veWMGuSVswTQSpRQuCY1UJnPdK7Vk9Kj0h3fikv2+bk=; b=2nmc4v7EUfdgueHuEcIByIUEOhAY4sJqGSopBQ+nMYmCk7jM0xoOfPIdtzLF43Km83 YvqWoWI7k4S45ee4vaI34QQ9RL5kLRM43IUBkj6Pbu2WuZtePaErHwvoF0WhIpZjoKo3 /BzWVoPEtlDn1bFr1MTe6mQyn02UEaZ23YqiWyNLiNspQSA74/fbTf2VTargDyl8mMJi 0EzZ5FUyOsG6ssU7iipBS7dvn+zSpUjc1K/HdGTkr76c2adBfMjpJ3CiXi12NlyChvgR WOFHkr6jWgKQev0VezkmHo+aXZcXafQzkwHHHMEnn7lAZsU5w6eb0AutNjE75UMyAyEv PDlA== X-Forwarded-Encrypted: i=1; AKwUvBwEUOghXKr45O7HlWADjb83evswQSnlk9voivfwd7AvEgun7PiNHPNtUVcDarJo0d56fga3uZxtfZM=@lists.xenproject.org X-Gm-Message-State: AFuF++lGfzHza7zgUoB36p+B79u05Wn8G5lSJThNtATrC+6IW5GBzo+o SDzr2wdpEGLHLcIMIgFZIPLu3BD3Cyc6u/D+VOB6cYg4rVYOnqzen0rRMIGsXhh8FSI= X-Gm-Gg: AYBFou1ferAmJ1h9a0QZzYGc0XL872AyfF8YQLYGZ5G4l5dVOrpW5mKPzFZdBuetUJ9 0haBDA4EJ0/GzEZc4+GHfsRGZldt/irsvsBpvXmNWtPJgG6TA35fxj0+lzVFiQ95Zo1GfrLDmas GqfnA4ySh4YaRaBAwti3qQ942UU0DSpVIbjgVaKLGhcDHebIgKrhqPxccnILNOw3Zlb8OBfgodl cO6CvjyybdNTLGVrxICe9yltTxGQv6l+ytvVKxQ0P0HbTLoImexA/YpMxO2q1RVQo33qfJ3D8Sx N/4dtHimpHMeuzgFlILgGDj8yTK827Fzb/bbtKzPGIMOee2HVySDhfZ3ldpbqyqE1evqN6t7vTo 9RFG129rI40noixRdA7c0kp6StvZioa0E8omE7KHcD7pv+fMzFDQpxXTpMouNXXg1o4u7+QCO/G vubm9axsQF78jMipDKzeLBswjXXNlcNt5pxOKsBGW2Y1kLIrZMWYghj+oYke6fg0Gvv2oU6b581 uFbQ/+Yz/c6S60= X-Received: by 2002:a05:622a:1f1b:b0:535:70b3:aa38 with SMTP id d75a77b69052e-5357573e670mr108763961cf.74.1791493396306; Thu, 08 Oct 2026 14:03:16 -0700 (PDT) From: Josef Bacik Subject: [PATCH net-next v2 00/10] net: stop calling __pskb_pull_tail() from drivers Date: Thu, 08 Oct 2026 21:02:47 +0000 Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAPkEyGoC/32OwW6DMBBEfyXac7exLQqip/5HlYPXrMMmxFi2g 4gi/j1Ae6x6nNmdmfeEzEk4w+fhCYknyTKGVZi3A7jehjOjdKsGo0ytlaqRKoz5Shjvw4DFyoB dkolTRu8rT6atK9YW1nxM7GXeu78hcMHAc4HTzyXf6cKubNXbL9nMSMkG12/WEI9UHXfz77Et0 0suY3rs6JPeV34pm38oJ40K2w9tSHlqm4a+yjiLizZ09t2NNzgty/IC68Wn+BcBAAA= X-Change-ID: 20261006-b4-pskb-pull-tail-drivers-ff4fb2964e1a To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493384; l=4998; i=josef@toxicpanda.com; h=from:subject:message-id; bh=uEkT7bvpoCXxFRYilwrMqw4m/avYlKD/tw+E4y7qkfI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QCXCcPzYE6MckGlWvZs5GlcBhgvsQUwMKctcIvHVU60iM6MoRF4p5/Zxb/dlkHyUCxdBM8d4+e7 75wiNZDfujgQ= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1791493399-C3EC6B50-BC1503CD/0/0 X-purgate-type: clean X-purgate-size: 5000 v1: https://lore.kernel.org/all/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com/ v1->v2: - New 1/10: skb_drop_empty_frags(). xen-netfront, netxen and qlcnic relied on __pskb_pull_tail() releasing zero-length frags even when there's nothing to pull, which pskb_may_pull() doesn't do (Sashiko). - xen-netfront, netxen, qlcnic: call skb_drop_empty_frags() after pskb_may_pull(). - skb_drop_empty_frags() checked with a boot-time test under KASAN and kmemleak, on cloned and uncloned skbs. --- Original email (v1) --- __pskb_pull_tail() is the slow path behind pskb_may_pull() and __skb_linearize(), and drivers shouldn't be calling it directly. It takes the number of bytes to pull relative to the current head and does no bounds checking on it. Ask for more than the skb holds and it BUG()s in skb_copy_bits(). Ask for a negative amount, which is what a caller computing "len - skb_headlen(skb)" gets once the head is already long enough, and skb_copy_bits() is handed a length of nearly 4GB to copy into the head. Under KASAN that shows up as an out-of-bounds read of size 4294967288, after which __pskb_pull_tail() returns success with the skb's head and paged lengths no longer matching its frags. It also returns NULL on failure with nothing making the caller look at it. Eight network drivers call it directly and four of them don't check. All four are RX paths where a failed pull is followed by eth_type_trans() or skb_pull(), which BUG() in __skb_pull() once the head is shorter than what they pull. As far as I can tell none of the four can fail today, since the skb is fresh, isn't shared and has room in the head, but that only holds because of how each driver happens to allocate. pskb_may_pull() and __skb_linearize() take the length the head should end up with, check it against skb->len and fail cleanly, which is what every one of these callers wants. Convert all eight drivers to them, check the result, and drop the packet on failure. The last patch makes skb_condense() check its pull as well. It can't fail there today, but it would undercount truesize if it ever did. The callers left in aoe and xen-netfront are fixed separately, through the block and net trees: https://lore.kernel.org/r/20261007-b4-aoe-short-packets-v1-1-db5155f7bb9c@toxicpanda.com https://lore.kernel.org/r/20261007-b4-xen-netfront-short-head-v1-1-12d7113a7e4e@toxicpanda.com Once those are in I'd like to stop exporting __pskb_pull_tail() so new drivers can't pick it up. Testing: every touched file builds with W=1 on x86_64 allmodconfig (ftmac100 on i386, it's 32-bit only). e1000e under QEMU, which hits the converted TSO workaround on every TSO packet, passes TCP traffic between two emulated 82574Ls, and with failslab failing 5% of atomic allocations the failed pulls drop the packet and nothing falls over. The same setup with jumbo frames and copybreak off makes skb_condense() pull frag data into the head tens of thousands of times a run. xen-netfront ran as a Xen HVM guest under QEMU's KVM Xen emulation, with the backend changed to spread frames over 18 and 19 RX slots, which takes the converted pull in xennet_fill_frags() and its overflow path. The other drivers are compile tested only. Thanks, Josef --- Changes in v2: - Link to v1: https://patch.msgid.link/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com --- Josef Bacik (10): net: skbuff: add skb_drop_empty_frags() net: ftmac100: check for failure when pulling in the RX header net/mlx5e: check for failure when pulling the Ethernet header after XDP net: niu: check for failure when pulling in the RX header xen/netfront: check for failure when pulling in xennet_fill_frags() e1000: use pskb_may_pull() in the 82544 TSO workaround e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround netxen: use pskb_may_pull() to pull excess TX frags into the head qlcnic: use pskb_may_pull() to pull excess TX frags into the head net: skbuff: don't reset truesize in skb_condense() if the pull fails drivers/net/ethernet/faraday/ftmac100.c | 10 ++++- drivers/net/ethernet/intel/e1000/e1000_main.c | 5 +-- drivers/net/ethernet/intel/e1000e/netdev.c | 4 +- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 9 +++-- .../net/ethernet/qlogic/netxen/netxen_nic_main.c | 3 +- drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 3 +- drivers/net/ethernet/sun/niu.c | 6 ++- drivers/net/xen-netfront.c | 26 +++++++------ include/linux/skbuff.h | 1 + net/core/skbuff.c | 43 +++++++++++++++++++++- 10 files changed, 84 insertions(+), 26 deletions(-) --- base-commit: a5e7d8e446af9803e37a3b6a4d416fb41178348f change-id: 20261006-b4-pskb-pull-tail-drivers-ff4fb2964e1a From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443801.1660920 (Exim 4.92) (envelope-from ) id 1xEvGt-0004Ih-8B; Thu, 08 Oct 2026 21:03:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443801.1660920; Thu, 08 Oct 2026 21:03: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 1xEvGt-0004Ia-3o; Thu, 08 Oct 2026 21:03:23 +0000 Received: by outflank-mailman (input) for mailman id 1443801; Thu, 08 Oct 2026 21:03:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvGr-00045y-QH for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvGr-00Dgxi-6y for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:21 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac804fb-2eae-0a2a0a5409dd-0a2a4503b842-18 for ; Thu, 08 Oct 2026 23:03:21 +0200 Received: from [209.85.219.51] (helo=mail-qv1-f51.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac80518-fae8-0a2a45030019-d155db33d58a-3 for ; Thu, 08 Oct 2026 23:03:21 +0200 Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-9179bfa9e9cso53323316d6.1 for ; Thu, 08 Oct 2026 14:03:20 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91b55120027sm41246d6.49.2026.10.08.14.03.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14: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=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=1791493400; x=1792098200; 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=cJq2iGR6XjS9tOGb5y7ebTTlkIKkVZtFa6s12jsD6jo=; b=qvsxqAv57v5kfrgAKA3TZjFIpFmKIbgZJihqj6tJT0/s47X51sunW4YevY7UZG0FBQ TCae7EekfX+vG92EguXqYgAhrbdMlVLz+Kb7iKZGp+8bKzxXXziVgPDQpctLq/AyKF8m j+2tVdQPqXTConGpec93+TgCZloyUwkVfWgpp7/aSnAp5U93A7jf4n63LNH8013Jz1Wt kRZjbtL7Bw2w81oqweveNmjAb1a9M6IBcwPNhTgLZkZaXQz/qwQRbhv5ewdgRZH6vvnK OrN4lHl1yyDEyp0+uI4AzBLuEvSib9laeAq/hMhjrtSgll/5VAQ4d5jlwaJuD5exVllx 8YDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493400; x=1792098200; 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=cJq2iGR6XjS9tOGb5y7ebTTlkIKkVZtFa6s12jsD6jo=; b=fNn+8rWp073SjyYGUOLAc2aqUC6XPesjKiVn/FM7slea4jFWydqVzTUoLEv5ALAnYT PDIrHYbKHnKQl1CrqpAThN/C9w5KrZ/PMB1AGHrYfVzjHFMRhnO5zVquUo8fCYijfRPy 9c1EmL7Bk0u9B3d//z/N8FymGP8Pj/5qJJ3u58k2qd3HLmxufhgbeum7yg9JHF7NZDBb 1XlGzBEasSw41y9LdzakqcY47i5c5Ek6p0GQnwhtYZssyE+5+CbYGoYCVIh2iLQkPbkO GmDnuCDMI8nVKZNdffxWe8vAzJUOlz0nH+HscvEveNpH+f257FzBe8lWe/0uHBOZ96X0 WnsA== X-Forwarded-Encrypted: i=1; AKwUvBwpMWMlEOoRGbw5Acch3RpqppHeBrGCeFW61PrvIAYys1JulH1Yrxd4/1+hH2k4L4bMzqZyXeuaXy4=@lists.xenproject.org X-Gm-Message-State: AFq9FYKHVpQXCbbdPYwrHtj7jQapqCda3dt3lKD4rmm/RF1qAge2hkl5 CtDWavLUCBTlU4cdKp4SuiZyGdP4c02SBS/RN7kRUFhWkF3VP4envdwhwP9vWGORbL0= X-Gm-Gg: AYBFou3TG5+6xGMNS4bkHwwoVm7rJHwYwkR4AkukcW5SYxe1Sj7ruFeBHe7HcnKE19T Ymx0vsrvwHCTH0Xf2NszNAPJVrl1g3KNl6BsZVKBkrESaM1fjt1G3SbTHf6P4oj/HM7Ixj33Lew Pi+w3+KXABov0qZVW1miqdiQvcTyiiMVnNINmrAqZFD+T3l+tiAm1SMW2Ilwv69yVFSR0rhZ8MF B1F1je8dCtWc2OUeQaiAudo/myhiJ1FF6KY8Y+8zTfr5mL1JadA0PNYdmjBaHvJcAC1ZQ9ReJBc 0RaxU+7hBCeqVmztfHnp45SC9sXQ8NFw1StTTT8eJM2i53be1YJ9WiPUMOzu67KMoZo5asK7AGh gBiBQSW+oqtBqVhdp0ScT88a5/RwjbNCcEGO2Q3n3X4dhnKLyaOf2/6shnDAiTG0bQ31O+HUbcN Zp/cbaNElmBspf7mX3JovV7Rhq0Q/Gs2AKJ9mJvLHwNA+VQLAatO7ezWwSjbc//Rir8jeX5VVAV I9RiOTOh5Vte/8= X-Received: by 2002:a05:6214:8506:10b0:91b:51ea:8f3e with SMTP id 6a1803df08f44-91b51ea9005mr10470996d6.49.1791493399667; Thu, 08 Oct 2026 14:03:19 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:48 +0000 Subject: [PATCH net-next v2 01/10] net: skbuff: add skb_drop_empty_frags() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-1-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493384; l=3047; i=josef@toxicpanda.com; h=from:subject:message-id; bh=eNF9AfY31ifKJcp/wEnDWb5NxkFPFrVkSamyLYsUttM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QOI8lG/wdh6wd8yc4i7FHBwvmuyCaLtAuFDjmIGDKRvpDQpmhSkJsjkYyP5E/1+czZMvAKz61ka mmydLfI/gLQo= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1791493401-6EACC4E9-BD386250/0/0 X-purgate-type: clean X-purgate-size: 3049 __pskb_pull_tail() releases every zero-length page frag as it walks the frags array, even when it's asked to pull nothing. Some drivers depend on that. xen-netfront calls it with a zero count on purpose to make room when a backend fills the frags with empty slots, see commit d81c5054a5d1 ("xen/netfront: tolerate frags with no data"). netxen and qlcnic get the same effect when the frags they pull to fit a TX descriptor happen to be empty. pskb_may_pull() returns before getting there when the head already holds the requested length, so these drivers can't simply switch to it. Add skb_drop_empty_frags() to do just that part, unsharing the skb first if it's cloned like __pskb_pull_tail() does. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/skbuff.h | 1 + net/core/skbuff.c | 40 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 41 insertions(+) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 27ec1e38c828..c1295f6baf6d 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -2840,6 +2840,7 @@ static inline void *skb_pull_inline(struct sk_buff *skb, unsigned int len) void *skb_pull_data(struct sk_buff *skb, size_t len); void *__pskb_pull_tail(struct sk_buff *skb, int delta); +int skb_drop_empty_frags(struct sk_buff *skb, gfp_t gfp); static __always_inline enum skb_drop_reason pskb_may_pull_reason(struct sk_buff *skb, unsigned int len) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 43ebe61c7fc4..f798118df112 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3004,6 +3004,46 @@ void *__pskb_pull_tail(struct sk_buff *skb, int delta) } EXPORT_SYMBOL(__pskb_pull_tail); +/** + * skb_drop_empty_frags - release the zero-length page frags of an skb + * @skb: buffer to clean up + * @gfp: allocation priority, used if @skb has to be unshared + * + * Releases every page frag of @skb that holds no data and closes up + * the frags array, so the remaining frags keep their order. The + * frag_list is left alone. A cloned @skb is unshared first, since + * the frags array is shared between clones. + * + * Returns 0 on success, or -ENOMEM if @skb had to be unshared and + * that failed, in which case @skb is unchanged. + */ +int skb_drop_empty_frags(struct sk_buff *skb, gfp_t gfp) +{ + struct skb_shared_info *shinfo = skb_shinfo(skb); + int i, k; + + for (i = 0; i < shinfo->nr_frags; i++) + if (!skb_frag_size(&shinfo->frags[i])) + break; + if (i == shinfo->nr_frags) + return 0; + + if (skb_unclone(skb, gfp)) + return -ENOMEM; + + shinfo = skb_shinfo(skb); + for (i = 0, k = 0; i < shinfo->nr_frags; i++) { + if (!skb_frag_size(&shinfo->frags[i])) { + skb_frag_unref(skb, i); + continue; + } + shinfo->frags[k++] = shinfo->frags[i]; + } + shinfo->nr_frags = k; + return 0; +} +EXPORT_SYMBOL(skb_drop_empty_frags); + /** * skb_copy_bits - copy bits from skb to kernel buffer * @skb: source skb -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443803.1660929 (Exim 4.92) (envelope-from ) id 1xEvGx-0004YV-JJ; Thu, 08 Oct 2026 21:03:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443803.1660929; Thu, 08 Oct 2026 21: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 1xEvGx-0004YO-FY; Thu, 08 Oct 2026 21:03:27 +0000 Received: by outflank-mailman (input) for mailman id 1443803; Thu, 08 Oct 2026 21:03:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvGw-0004XO-C7 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvGv-00Dgwy-PE for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:25 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac80516-e002-0a2a0a5209dd-0a2a4507bc3a-6 for ; Thu, 08 Oct 2026 23:03:25 +0200 Received: from [209.85.222.180] (helo=mail-qk1-f180.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8051c-b4ea-0a2a45070019-d155deb4dddf-3 for ; Thu, 08 Oct 2026 23:03:25 +0200 Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-93e55db58cfso502626885a.1 for ; Thu, 08 Oct 2026 14:03:25 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93eb9724fd1sm26327885a.1.2026.10.08.14.03.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14: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=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=1791493404; x=1792098204; 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=a3FpKl0vN7petfzZgqIhlc2NP9KQ4OIDsR/ta4Cqq6o=; b=GgFIRCIc6+RrRH9YY0LiNlQMkOOtA2Yu5fxOdAoRjE3zr4/fG79ZEgmtDEw10yafpj 6hOFlJMMceGjvYw0IjUXhZ9m4hHPThAFQOLDVgKTn5vtd+MRu1C5F42c0yAM/Ljk31aw fwqmYnatn3HQIuZZn+0UYss1/3feiLJXy8hCu7im+2CcWZQkt3BQX1qaEqH73A3lHGgo SatTKGqNnHOf4bSYlr27ZdHex7r8oauzRvL7hw6cQZoZ1SdaZaxNR+a7AdbRc60GDH+k iC3xH1PIEk7PApiQqvyP28KK28YjzAGaJJ2/avhvQ/fJLNQsy8uJH8nx7F26obOSVeen 0tRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493404; x=1792098204; 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=a3FpKl0vN7petfzZgqIhlc2NP9KQ4OIDsR/ta4Cqq6o=; b=VMi8rzJf5MDUZm8ckSovrYaC+6P0ycgitFxaFoS+wb6nF0wKY6F4JsksgerccnR0Kf gQBZVCYgxwk1QUi0mm8nAp5kBUXnBnAUzKYy+HtPsMKide+T2n/OSLFC2koRdmgqudF8 NQ/3MsUsEK3bfLiO4FfMGPrcQVGR4hSsuftx/zxBOV52bdzOC7nw9aDyy9FnwM4LFjyX 9L7hjxqLclTi0EXNc78LfoWb8Wgpjcv5b/1wvpW23sVDjeyzIz3MJud/0f1Pqe3bcak9 rbaGeet8JrXum3m85kXQyRVehNwlioI5Dv8ADg03ux6AgGustrpZBS6MOa7MHPu6QinY 0ihw== X-Forwarded-Encrypted: i=1; AKwUvBzpHyIAUKG/kAzgVZ/XIywA3NHm7wOfce9el7WM2VlM1t6x44S6NhZIXgrEL8NhmWLWSCkwhLcDVEQ=@lists.xenproject.org X-Gm-Message-State: AFuF++ndG8uu98rrDGMax+euliB+hN2butf06ZxRB15oUU+wy8dXwH7i biqE8ZY33++pnsoyv6n1tD5FZ5s+tvUiCTZYaxfziFXWtrSOViClGZ9GXS5aKvnuNponf6tJ0/+ a4kqB3ZNlPw== X-Gm-Gg: AYBFou03kS++pDKW72t04OMOeR2k0P/67Y8RXsfFjEIEHRha2zT2yuiFqxXp2wt2dfC QLhW8d4X1yYPD6uW5XXSWzbBHqcwMkjqY9jjint6cZGFFihl/N15K2FhDrpImLk6Erpxbx3sQif mv/Fnm7vquK+swurdlcOfG+nLHuLG3MPNctd6lalQOnMaHF9V0+lgV5zhqo0Ryw/+tS4uG2gFNv SXfPL5k+PzZT6HhVa8VeNysfbUWWC0Y1LnXNAKN+YQ0PBWbaEdcAuQWOs5AkAG3pnSYW08i6UmA ictEMGOeew7wjUVqXiD4IRH9eNz7u0/BtDhzQAASJdv5egsJBFwDyItl36HbeE0PcpINFfnriV6 ZAZVOTDf244yqOd49W0XvujlkrYSkoO2yZL5VFnFC1ljedgoF85v+ODLpOpffU0q2NGwM08z5pT JPj4n/GWSUNVGv313EucBYjNClybRbZhTv5MJdgVljxjySVobNk3dX5f2U6FS5uYbTUJ4qQAqHJ JtF1u2pwWdswpAuWZgeLfgW8A== X-Received: by 2002:a05:620a:29c7:b0:93b:beb3:5898 with SMTP id af79cd13be357-93e9b807709mr1263365385a.49.1791493403829; Thu, 08 Oct 2026 14:03:23 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:49 +0000 Subject: [PATCH net-next v2 02/10] net: ftmac100: check for failure when pulling in the RX header MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-2-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493384; l=1745; i=josef@toxicpanda.com; h=from:subject:message-id; bh=YaVSidg1Bo1cVWoGQJzV4z/nBT+SLxbK+9NmCYkL+oY=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QKPRKOQSDQ67QodM++vQrU2bAaf9t1GHfgEbAcRMIyyvBlr3tTyXLKb7mAyGosVPXukX94UmJf/ pTxPq3ZQboAQ= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ef75cf/1791493405-A5AC0AE4-65613C8D/0/0 X-purgate-type: clean X-purgate-size: 1747 ftmac100_rx_packet() uses __pskb_pull_tail() to pull either the Ethernet header or, for small frames, the whole frame into the skb head, and ignores the return value. If that pull ever failed, eth_type_trans() would find less than ETH_HLEN in the head and BUG() in __skb_pull(). It doesn't fail today because the skb is freshly allocated, isn't shared and has room in the head, but that's only true because of how this driver allocates. Use pskb_may_pull() for the header and __skb_linearize() for small frames, which is what the two pulls are doing, and drop the frame if either fails. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/faraday/ftmac100.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c index 40ba001d4b3f..a1eb04ead2d8 100644 --- a/drivers/net/ethernet/faraday/ftmac100.c +++ b/drivers/net/ethernet/faraday/ftmac100.c @@ -469,15 +469,21 @@ static bool ftmac100_rx_packet(struct ftmac100 *priv, int *processed) if (length > 128) { skb->truesize += PAGE_SIZE; /* We pull the minimum amount into linear part */ - __pskb_pull_tail(skb, ETH_HLEN); + ret = pskb_may_pull(skb, ETH_HLEN); } else { /* Small frames are copied into linear part to free one page */ - __pskb_pull_tail(skb, length); + ret = !__skb_linearize(skb); } ftmac100_alloc_rx_page(priv, rxdes, GFP_ATOMIC); ftmac100_rx_pointer_advance(priv); + if (unlikely(!ret)) { + netdev->stats.rx_dropped++; + kfree_skb(skb); + return true; + } + skb->protocol = eth_type_trans(skb, netdev); netdev->stats.rx_packets++; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443805.1660938 (Exim 4.92) (envelope-from ) id 1xEvH2-0004qh-S9; Thu, 08 Oct 2026 21:03:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443805.1660938; Thu, 08 Oct 2026 21: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 1xEvH2-0004qW-OR; Thu, 08 Oct 2026 21:03:32 +0000 Received: by outflank-mailman (input) for mailman id 1443805; Thu, 08 Oct 2026 21:03:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvH0-0004oF-SU for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvH0-005tQx-9P for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:30 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac80522-8faa-0a2a0a5109dd-0a2a4504d040-0 for ; Thu, 08 Oct 2026 23:03:30 +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 6ac80521-b57f-0a2a45040019-d155deb3c58b-3 for ; Thu, 08 Oct 2026 23:03:30 +0200 Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-93e7ad9f78dso391965085a.1 for ; Thu, 08 Oct 2026 14:03:29 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93eb98c818esm23024485a.36.2026.10.08.14.03.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=1791493409; x=1792098209; 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=J9GuqCKMi/hN2ncI5Ot6sRINUqKwZdItx3f86TmeMcg=; b=M0KOn4ATa8ip5eiVZOgGxWLAgcvgIaOK8YsWSOBI6xhh94xDnTVxdT2cGZZnO9Saca qeY++wVDvjZaKG0+kjaTdWemnqhHtXPcbHyQB5yI0e4h1ZyzGcfqC8SuBdjfR5QY7uBC BQgbIGhDWKLDLab12tPs9ClYmSkN4CvbigUqlH14XNLaCHbQKVjM3SstXp19OiKm02Az TE3Uxm0sUNtcME2ZLYgzZD21mRNE++ANlz5LG0cRSXdqA+VEYActK2FAQmF5Fv8yXHz/ R/Z73Hjdf90xuexSnMr6w1sHRvaQ3o4DgtEeIBQtLXmo1329zf+cYR8F48OOU4MS18qa 6kAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493409; x=1792098209; 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=J9GuqCKMi/hN2ncI5Ot6sRINUqKwZdItx3f86TmeMcg=; b=jwIzGwe3x3lEnjvy9nzed5MDNYXH1QwN2+nxN3XXD9GKSwSweMBBmo0KfjTrHC1jVa /1sLpXgVCLDil852SGlh6udnkIFMY32Z9qbeZMHKVezKg5tGbj0+sjvhlbWxTmLGI58b xxtu5cbvWnSRDzsAR7UNzf5E2IQxV3gE08Ef0hNmIMeCKMjXVagbArAevYRUMhi3LvJY 5zIuGLW6kIGrcbDmvNL0G5PxVyDc9/wLMUopp9WNbWH2CHUec6ih84UQG3R07tvhj6i4 B/3gn7lw+znzvJyS/OCPo3Bujuu8vodB2CZkzDRiDkOvnuZBRAUbfkm2lU9yFr8F5KvQ tfDw== X-Forwarded-Encrypted: i=1; AKwUvByCVl5sVdCgDqdH/DFQ98Yxx8LjVELQovh5L0JzF/BnefLIO/dRVSMAEgHP5W07RI0Q/Qo4juF1Q7M=@lists.xenproject.org X-Gm-Message-State: AFq9FYJAFfUn4cQL8tl/IeNCugCTBFpRB2PtS+nUGts3gk2q82yRDVOG festetdPjj0h+hhUkNMraqkKQtcGpB6jai4vyLgOODh9Vo2p0WHVDj3NwodlwMrM3AU= X-Gm-Gg: AYBFou0hBm2z4TujwpBsbb7PAOfB3d5s5ujgEVMmp4AzbasBW34Q0d3WV7t2avw1F8c QzKiBJvhWr8uK2QOBkeeXnLGLUGso3ggnwTwuQhxtqACQbMdpL8+DaVs3Rbf2baciv3OXD2zTK9 KSwFDO4qHnX+4rIEnZNwhqCiU9dr1D4dqihuHmLcNgJwhPRVfu82fDQlR94bI38PzU0pTXDv3dY iKhwKlFYFs751nEp/xmT7hiP+90ZUvS2t5Ek+DsI/KPGUG7MOo/vzSog2lhsr5fgchlCjGCU6x4 yfC4Sl/HzGQux+AaTed+HADQRe45VVZ7rULUemROHnzhqQvgEumVZa5qoRTGGumWlqKKj0z33DQ axZ0jIkDltq+7kuUNEISRedM2KhClUKaKIFG9PmXD4a0YYOq0XI7U1wif8LfHeUclLYT0zIcVRf geyzLbm8XmUZVa0M5OuQNdgRY7ANFFH775H2tgyydPMswGTXohUh+UV1haoAwePYArNO8HWng7r SPD3sNvmNa9cbY= X-Received: by 2002:a05:620a:29c7:b0:93a:2a59:3377 with SMTP id af79cd13be357-93e9b799671mr1358007485a.41.1791493405607; Thu, 08 Oct 2026 14:03:25 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:50 +0000 Subject: [PATCH net-next v2 03/10] net/mlx5e: check for failure when pulling the Ethernet header after XDP MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-3-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493384; l=1491; i=josef@toxicpanda.com; h=from:subject:message-id; bh=zznhnNGgkEt9ZSSy2T9PlgogR6INn8I/GpUQzjq8ahE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QFaj9m1MCb6yydGhkDduTFS5Q4Ekj/GXk/66W/KuEGtH8miGll+pKUls7h6lvdP0A6+k8X0JuWF J9s3G82EktQ0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1791493410-51AD0B50-CB4CFD57/0/0 X-purgate-type: clean X-purgate-size: 1493 When an XDP program leaves less than ETH_HLEN in the linear part of a multi-buffer packet, mlx5e_skb_from_cqe_mpwrq_nonlinear() pulls the rest of the Ethernet header in from the frags with __pskb_pull_tail() and ignores the return value. If that pull fails, eth_type_trans() later finds less than ETH_HLEN in the head and BUG()s in __skb_pull(). Use pskb_may_pull() instead and drop the packet if it fails. Pulling min(ETH_HLEN, skb->len) keeps today's behaviour for a frame shorter than an Ethernet header. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c index e3f915beebe1..b1e1e30a77e2 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c @@ -2060,9 +2060,12 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w pagep->frags++; while (++pagep < frag_page); - if (len < ETH_HLEN) - __pskb_pull_tail(skb, min(ETH_HLEN - len, - skb->data_len)); + if (len < ETH_HLEN && + !pskb_may_pull(skb, min(ETH_HLEN, skb->len))) { + rq->stats->buff_alloc_err++; + dev_kfree_skb_any(skb); + return NULL; + } } } else { if (xdp_buff_has_frags(&mxbuf->xdp)) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443806.1660947 (Exim 4.92) (envelope-from ) id 1xEvH4-000558-3h; Thu, 08 Oct 2026 21:03:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443806.1660947; Thu, 08 Oct 2026 21:03: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 1xEvH4-00054s-01; Thu, 08 Oct 2026 21:03:34 +0000 Received: by outflank-mailman (input) for mailman id 1443806; Thu, 08 Oct 2026 21:03:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvH2-0004qB-KW for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvH2-00Dgxi-1O for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:32 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac804fb-2eae-0a2a0a5409dd-0a2a4503b842-30 for ; Thu, 08 Oct 2026 23:03:32 +0200 Received: from [209.85.160.170] (helo=mail-qt1-f170.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac80523-fae8-0a2a45030019-d155a0aabcda-3 for ; Thu, 08 Oct 2026 23:03:31 +0200 Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-535179e995bso37088491cf.0 for ; Thu, 08 Oct 2026 14:03:31 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93eb99074f7sm22172785a.46.2026.10.08.14.03.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=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=1791493410; x=1792098210; 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=blrnvRK83a0BrC00ZsKjSLnGbEsSK17m6K1yrBXm/SE=; b=SyZdNvttdFPvNh6xPf3rcjjSWeUYGF96LaiGtkNRwZuDLrcwZLqgv3AXf1lx0SxP+H Lng8mNLgZ8lp0EUhA9vSMv4JAfS10vE+kdYAyw5AyDSvoj8FuptLq8FIs4y8u3chiQbi QWiIq8rG+Ls85gu8Wn3Sx0kBMcjPU+sS/dHy3YFZeYGY2jODFcKdn64W8tdqRFfhggdc 86fx73d6VkGMPriTV8Lv5SgwRmOz/WkUleQaWz0JbkxF/Ax6MB6Qk1T9FvxO6zL2l7Je fd3LOz1J2psyYaDEOFAkSM6cpRKl7Sqn0tEjtdjl0IrDNCnqpVBvRxPwrfbGuOoUnsdo H6pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493410; x=1792098210; 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=blrnvRK83a0BrC00ZsKjSLnGbEsSK17m6K1yrBXm/SE=; b=QYdAs2h1S3WOtXYwTCv01JQMOJcMu8/ci5fsD6U3jXjuEKJf1FJDasegb0Vc+4ZHQF lik9lQ89JtNDHh4lFcC1cK8mvPU0xBE1wVavCoOSkl5H8BZb8gwDxBXth+obnq7/Uq2P uBjo+TM7XD6Cl1nfbf/VVEiRWhc4G+nwByxMnqOXD46XWHA1sUI3iaFFjTvTjHbPDK+s dvsTY5lpFSAGhuMMDGPafDRiB+bOfsgnK3U4+Mes5VKkGKjfs8l2KMfUasyfEzMtAQmp 3CLYC2JX/aBTLf+iC70qWY8VjVynaNNYFGOcjJy32xnboM55w5j0Hx6lEzqTBI9elBXK bvTw== X-Forwarded-Encrypted: i=1; AKwUvByM7dc6tHZ2cpX7I2Kcx5h8XwHtNH2RWb3zqdQ6Pssr0tMk6CPEQC1X9zcN2UrDZb1wH2RwGeHQKzI=@lists.xenproject.org X-Gm-Message-State: AFuF++nTR3pQjw+RyhgsLOCT3truQMyPBauITvJjvrwn04rSlyfDsAc9 61Hg5zABZmL3BY+TTGAU0M2veo3lV/HY1b1TGze1BqSARWZMZCoeYocxfeU4S7eOCpk= X-Gm-Gg: AYBFou3hKfZeVqKtus/AMBOi1gys630GIqhF2lJ4RC5XFY2LPcdUGVwtOvzTGPYsEeW CtQLvO1e7Ci1OtaP6YehP6VRfperyVHJ1qHCKv0+A00jbfGtGapncAHUGmn15at/oupmtJ5n6WK ps9FHAVwodPY7FYUW7osnng38faSavimz+DSxbaHfQiPLZuL1H+ch2t16sOGqAdFpm45zYwaJ58 R6Mcy20eTdKfgm4Y4YmnfhCdBCsAsrRRz59eEl/7vP8QBS2Sx6p0EJXyMYpGkkj+06kg5dkpeNT q0NX5p5ZqrPV33IWeaPWGAFtou2fnU6CbZDYGmtW/fe0JiqL7Eo3qvlpddzizalT7GYxx0ickC4 bQOPIG/d+hOnAoKvUGhFW0fvf1U3sGzX6CJpgcpFeFLRuEEIFkwGxMo15c/LVBKfFyWvNTmKhIc +ZNw/2L/kMb1M71CxsSNwUt2HMTx4xBQ3g6deCR3d0WL+1ID3STJ6qgKqq8l5S9aYArsPAtjCPc x88c1Z1cXqU1FE= X-Received: by 2002:a05:620a:1d03:b0:93e:9809:dbff with SMTP id af79cd13be357-93e9b8ecbf4mr1178890585a.82.1791493410404; Thu, 08 Oct 2026 14:03:30 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:51 +0000 Subject: [PATCH net-next v2 04/10] net: niu: check for failure when pulling in the RX header MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-4-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493385; l=1236; i=josef@toxicpanda.com; h=from:subject:message-id; bh=3f5WzTjnDsDOAnT0hR8gZXIWFT9KoT8c/AVMjDx6NOM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QHTAZLO2IxS2OmXjiwrMC0xtj/kaDkW3OSxxKLc7dWB8wtA0dY5E/Ye18IDZRljWIONenVbHWP+ B0r4Rpj6pmA0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1791493412-778F24E9-429D3BF7/0/0 X-purgate-type: clean X-purgate-size: 1238 niu_process_rx_pkt() uses __pskb_pull_tail() to pull the hardware RX header and the Ethernet header into the skb head, and ignores the return value. If that pull failed, the skb_pull() of the RX header right after it would BUG() in __skb_pull(). It doesn't fail today because the skb is freshly allocated, isn't shared and has room in the head. Use pskb_may_pull() anyway and drop the packet if it fails, rather than depending on that. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/sun/niu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c index c74a97fe5464..d1c0e868004d 100644 --- a/drivers/net/ethernet/sun/niu.c +++ b/drivers/net/ethernet/sun/niu.c @@ -3488,7 +3488,11 @@ static int niu_process_rx_pkt(struct napi_struct *napi, struct niu *np, len += sizeof(*rh); len = min_t(int, len, sizeof(*rh) + VLAN_ETH_HLEN); - __pskb_pull_tail(skb, len); + if (unlikely(!pskb_may_pull(skb, len))) { + rp->rx_dropped++; + kfree_skb(skb); + return num_rcr; + } rh = (struct rx_pkt_hdr1 *) skb->data; if (np->dev->features & NETIF_F_RXHASH) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443807.1660957 (Exim 4.92) (envelope-from ) id 1xEvH6-0005MG-Ck; Thu, 08 Oct 2026 21:03:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443807.1660957; Thu, 08 Oct 2026 21:03: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 1xEvH6-0005Lx-8O; Thu, 08 Oct 2026 21:03:36 +0000 Received: by outflank-mailman (input) for mailman id 1443807; Thu, 08 Oct 2026 21:03:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvH5-0005KG-KM for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvH5-00H9qs-1L for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:35 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac804dd-e002-0a2a0a5209dd-0a2a45029fc4-40 for ; Thu, 08 Oct 2026 23:03:35 +0200 Received: from [209.85.160.181] (helo=mail-qt1-f181.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac80526-6ca4-0a2a45020019-d155a0b5cccd-3 for ; Thu, 08 Oct 2026 23:03:34 +0200 Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-533972e0cccso34166731cf.0 for ; Thu, 08 Oct 2026 14:03:34 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5359b46dda0sm3472151cf.4.2026.10.08.14.03.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=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=1791493413; x=1792098213; 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=jXT5xqnUz/gqqG3F9wxnjnCJ7kPBk+m9Im3cz1NP6m0=; b=ZzwE3k+D0kR2U26YevlujJqJFej8h+t8jGgEM+2qaBrq3pW7tEqt55dOsvhmunp/A8 dMGgnFKy9z0sDCAd12Puli/hGqxyN3FnN3QS80c8gfqr0WjQBJWwMzYtAsIcXKQruWOD Lf9IFNmsqkJvSoN87wWlkNtJLgsIJq0iH5cq+H3O+WyypA8xXBJaYv4F+/oLYlUv7flK U2APLIO8665AWtY+tI+utA0r3NcfHnKezoG02fczdmc1QdlePku4G/felyVdBf3PMyMg O+ZRaYU0QmoM8Lgpy5ltXn/1DfT0tuSjVzZuB9NGCEmDEjiyKw9ERTU0sQRQ7nboMTh9 D47g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493413; x=1792098213; 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=jXT5xqnUz/gqqG3F9wxnjnCJ7kPBk+m9Im3cz1NP6m0=; b=KrrXwBBBxXfjPZYmuT8/SBnvaIHfTRCwk4uggvVnLvegFnjEgJl3afLcpmr++zqVK4 jv9nAN1C1Bkw0fYH6yVqTEoSD8ny8FwGpOmoWANQ9w7Cdf0rzhCHgFmLu3CpiUwt4KWI SxZvv1jfKtwovOqbJ+glxq0xvguGsD8aOmCQo6w6MjyEZL8Vr5xqHdT/lABmBhvc+CmG D3JA2HiBAv4coEP0ZCd3GsD85szS0TQIjh5saKR/xRQUphr1CpWBC6exrbaAAS04240v xGYaFfHTqjSnDTq6HwL6/FDmI2DVHrvhQRBNCM/1NWmL12rXdUTPOcKzMMpBzGKj3nS2 asnw== X-Forwarded-Encrypted: i=1; AKwUvBz7datNDS2jSTo4qNQZg/6Sg2YxnSWb4XQ3duD3kyH/b4XrcX1Y1MGK23JHOIcUlsO+sxybvUYMrNI=@lists.xenproject.org X-Gm-Message-State: AFuF++nKwVmyO5tJaj4EEPgepg1dC4mCxNCaoLK1ugSPpTIJaDAbG2fR xQXr4ZKDRlK9gwIxd+iFP1cPpJ1QC9YdghYvwkgPh/NoDUDod6i2jHfpCjX+z9URCWk= X-Gm-Gg: AYBFou1DYdgO80THkWrsRxQPAxkDhQVt90ylD2Ekxh9QZByuL7FFbTDg152OUrGbFWu EvxcsfeDi/2yE3go43dre+MViuGRCjhPk2F8yI7r7V4hzwVb33jLQNXzTzh3R5Z7TkIdz61RCej d5kMqd8RhBHq+JHp2zQPxLZ5cRYzp1TwMnOAF4BGFA7DT6odmOM+V/rFxFZ0I+mr0SfHF/2s9Kc z1ao8mE1X7rfx2HBDlT9LXhp7frYM/J+IHOJgq5o3/1HNQrSGJ0XU/VwryLKq9ho0Po28tTY8II vFzFqE3sV56alPzDC2sx2+AQ6KyQSmOIybhXxZJHKKRDLGtl4gY/g2mSPYOFG1i8RVg8qLeja+f eISak6vqdRdXvkREg3MpcyiqV3u/dYR8vOt0QYZe9lSBMu8F78I+f2RCZAbXA6kSwmgc7d+ixY4 QB+VYLZWgeipXI7rLqC1zA78KjYxyHCu8bEhSTIV6EhFg4cwmnjrLABWwPSOwFsK69EBpyGm3QM K6rxIuOJbytLvc= X-Received: by 2002:a05:622a:1a91:b0:535:70c4:9a94 with SMTP id d75a77b69052e-535757c8eecmr123953171cf.74.1791493413537; Thu, 08 Oct 2026 14:03:33 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:52 +0000 Subject: [PATCH net-next v2 05/10] xen/netfront: check for failure when pulling in xennet_fill_frags() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-5-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493385; l=2516; i=josef@toxicpanda.com; h=from:subject:message-id; bh=eg6ZiA9VrIpAG1HGYjPkKMEWwjo8D3VwigBhj0jOQMI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QAYzg3nASJLuLmRvMNvnGKJmwP15K/QJrV/X+gIw+dmiWX6S/LgMrQ8OB+kIWHKPWdMQHYgaFiD sh9Hj7FexRAU= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1791493415-F06A72AC-94772804/0/0 X-purgate-type: clean X-purgate-size: 2518 When the skb already has MAX_SKB_FRAGS frags, xennet_fill_frags() calls __pskb_pull_tail() to free up a frag slot. That frees slots in two ways: it pulls the start of the packet into the head, and it releases empty frags, even when there's nothing left to pull. The second part is what commit d81c5054a5d1 ("xen/netfront: tolerate frags with no data") relies on. The return value is ignored, which works out only because the nr_frags check right after it drops the packet if no slot was freed. Use pskb_may_pull() followed by skb_drop_empty_frags(), and take the error path explicitly if either fails. pskb_may_pull() does nothing if the head already holds pull_to bytes, so the BUG_ON() for pull_to < skb_headlen(skb), which protected the subtraction, can go. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/xen-netfront.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 2ed673649c48..007fa3bbc9e6 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1174,18 +1174,15 @@ static int xennet_fill_frags(struct netfront_queue *queue, RING_COPY_RESPONSE(&queue->rx, ++cons, &rx); - if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS) { - unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to; - - BUG_ON(pull_to < skb_headlen(skb)); - __pskb_pull_tail(skb, pull_to - skb_headlen(skb)); - } - if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) { - xennet_set_rx_rsp_cons(queue, - ++cons + skb_queue_len(list)); - kfree_skb(nskb); - return -ENOENT; - } + /* Out of frag slots: pull the start of the packet into the + * head and drop empty frags to make room. + */ + if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS && + unlikely(!pskb_may_pull(skb, NETFRONT_SKB_CB(skb)->pull_to) || + skb_drop_empty_frags(skb, GFP_ATOMIC))) + goto err; + if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) + goto err; skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, skb_frag_page(nfrag), @@ -1198,6 +1195,11 @@ static int xennet_fill_frags(struct netfront_queue *queue, xennet_set_rx_rsp_cons(queue, cons); return 0; + +err: + xennet_set_rx_rsp_cons(queue, ++cons + skb_queue_len(list)); + kfree_skb(nskb); + return -ENOENT; } static int checksum_setup(struct net_device *dev, struct sk_buff *skb) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443808.1660964 (Exim 4.92) (envelope-from ) id 1xEvH8-0005eT-Q8; Thu, 08 Oct 2026 21:03:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443808.1660964; Thu, 08 Oct 2026 21:03: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 1xEvH8-0005eF-MW; Thu, 08 Oct 2026 21:03:38 +0000 Received: by outflank-mailman (input) for mailman id 1443808; Thu, 08 Oct 2026 21:03:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvH7-0005bV-PQ for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvH7-00H9qs-6R for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac804fd-e002-0a2a0a5209dd-0a2a4508bc14-46 for ; Thu, 08 Oct 2026 23:03:37 +0200 Received: from [209.85.160.180] (helo=mail-qt1-f180.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac80528-f659-0a2a45080019-d155a0b4d0a2-3 for ; Thu, 08 Oct 2026 23:03:36 +0200 Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-53391022dc0so36962751cf.2 for ; Thu, 08 Oct 2026 14:03:36 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.241]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93eb986c0e9sm24158885a.20.2026.10.08.14.03.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14: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=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=1791493415; x=1792098215; 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=jtyJNESs2NfaCrmwRAvvPnxlfOHCunirXFuek+zM5MM=; b=X9rg4hoBb1kp8i6mvaIkowGiJ5SkGMFsq74a3nCRquIBooj1UkdoMmaNn7REgb2GUq 9E3MlvbP8ZimGv38qup69576zcpRy1Fm+O6c9dyu8fJRq2EtQ1y72kAs2LnT4dahQ5Zj QrLjASPXA9IohwgeFWTe4O9amr0HJuGVH5xOqr8FIzcHjd65z1MDsPe/XNDI9HKkfhHS 74bC54GzLQiZtNDlWUPUXUult8uFR38M8TFnG6+eyPOHBOLvkPXOpSMMf5TqX8RUGqS7 Pr6HMYxZt6AAngCvrvRD2wHVeMoaNUFITq3C9M1lySqD+w81Eic+BHlCWZQeC5LJRM6F UzaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493415; x=1792098215; 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=jtyJNESs2NfaCrmwRAvvPnxlfOHCunirXFuek+zM5MM=; b=vhG5fnDJkC6HF5qd0wmeFAknufHa6RgRDyV7vIe5zV5LmH4h4wAiV2Nb/PmG4ItGYQ NCv+BUGh0l6ORnDwrX1Tbob7nm0DLywaHgWL4842wg26t6uSSKI2dmzBO/qLOGYCWigB NCckfIJapE/5pyRFkvxTX56z/JeJYjGB4LbfPjinMhwQoP7zNmYt6By6TUqWB8SjNy5p I+THuYMQMpGW4NVByg/6pEWo73FXb6O4YpKz3ugpzLaYIOo4qB8Q/+mO/p/3xObqKEMk wg1kj5Faem/Nw5sui+4W9ZZko6DVMZjeduMLJHpDOI9qeLg1xzBjiFALeiCLqL0vcFYS 3rDg== X-Forwarded-Encrypted: i=1; AKwUvByO/cp5uQKZDAG60qb5uS4LKQwPY+xowLERtUd5n9+Ra/z4CFnMJHS3rMDc5YK7iP8nN3tpmQcH6dM=@lists.xenproject.org X-Gm-Message-State: AFuF++mosBDKIDmcnycgs7IJT5E1L9qKBq5YPf8qldnFzgBKQ3yKIeb4 A0/sd4YVcu6d6TZkAFqhcTYBgHnO/NapCyFJtq07vFlLWYVzz9FLim3168OOjNDpUC4= X-Gm-Gg: AYBFou0EtiVMRz1v+YyBONAXK+As0s1sGCdJVaogGZsyQT2KwFDFMI/tbgIs0V4uEfx J8TnG3Xn1iMcde48nqBD4xpyB2z1lu0PoaKrZMQYYkY+6EAaPtP7Se+rgwaWM8ha2ShPvSnL5hF pgG88olPzI2zRiLcdAJJ1rLRHrNcerrqEw11zBa9w6E/0Y7fCokFMELJZfJ/1mKhQ8g3Z3ElUka MxhKe5U2mmtGLiNViWlp2dZEUtDkBpwz7KZF68h8HGiUY4HbfNCsWG+QwxG1R4S+zQFUjF0aZ+Z g/VPj+lXLrAmZatn1iYHf5oVEuI9K3AEQtxfxlcdQx66XcglQxDrqIjH105YJYVWeTM8eH+80cw xGNSBaYTHumh1znTjN+89gNMQa75imYBuEZnGL0QIvTkyxSBGXhqSshPccsHwmlWEQ/wXxmRc1h FKGpX1vmnI7FTJ0fnc4jhb9fd9QuoXkWNt1otCq9zr+6N8lT/KVzWQuzXKbVIFceaA5RcSXY/AY TLkQtCFhQsvrAs= X-Received: by 2002:a05:620a:4613:b0:934:ab73:ac53 with SMTP id af79cd13be357-93e9af42cd2mr1369444185a.0.1791493415593; Thu, 08 Oct 2026 14:03:35 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:53 +0000 Subject: [PATCH net-next v2 06/10] e1000: use pskb_may_pull() in the 82544 TSO workaround MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-6-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493385; l=1221; i=josef@toxicpanda.com; h=from:subject:message-id; bh=yldyXc+k9IUGHFBVvbXY7100U73O47dmandGyjhHpkE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QO2CfzCzBOeK9ZW88WGSv+B3RUqXFGdARFKgVlna7gjBWdR0TdJniqj/mr2mdJ20mJNMEnviLw3 DiEJcfynbhAc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1791493417-CD94A87B-9BD72912/0/0 X-purgate-type: clean X-purgate-size: 1223 e1000_xmit_frame() uses __pskb_pull_tail() to pull up to 4 bytes of payload into the head for the 82544 TSO workaround. It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/intel/e1000/e1000_main.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c index d7f5c6f16142..3a55b211f5a6 100644 --- a/drivers/net/ethernet/intel/e1000/e1000_main.c +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c @@ -3155,9 +3155,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb, & 4) break; pull_size = min((unsigned int)4, skb->data_len); - if (!__pskb_pull_tail(skb, pull_size)) { - e_err(drv, "__pskb_pull_tail " - "failed.\n"); + if (!pskb_may_pull(skb, len + pull_size)) { + e_err(drv, "pskb_may_pull failed.\n"); dev_kfree_skb_any(skb); return NETDEV_TX_OK; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443811.1660973 (Exim 4.92) (envelope-from ) id 1xEvHC-0005yG-0J; Thu, 08 Oct 2026 21:03:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443811.1660973; Thu, 08 Oct 2026 21:03: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 1xEvHB-0005y7-TN; Thu, 08 Oct 2026 21:03:41 +0000 Received: by outflank-mailman (input) for mailman id 1443811; Thu, 08 Oct 2026 21:03:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvHA-0005tm-5d for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvH9-00Dh5Q-Iz for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:39 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac80529-2eae-0a2a0a5409dd-0a2a450bdbd6-2 for ; Thu, 08 Oct 2026 23:03:39 +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 6ac8052a-b7e8-0a2a450b0019-d155a0b2c82a-3 for ; Thu, 08 Oct 2026 23:03:39 +0200 Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-53504882980so48852351cf.2 for ; Thu, 08 Oct 2026 14:03:39 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.248]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5359b7ecccdsm3179791cf.30.2026.10.08.14.03.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=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=1791493418; x=1792098218; 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=pgpiLoGoqA0xV5yWN2rO1XVw1oOPWsG2lgMDpzrz1ts=; b=md3qrK4zoVnDvTnTVzK1hRtTapY6MH1o2579fsWFpmtykmtfGptcR40UblnMenYhxI +u0Uat4CNfjFhU0RuI4PF+3PIMEXba2is7ygX7b7xmBSO75aYFXH7z4zQhUPN5hKWe0s y6xT/8TKF8G3+XIT3vCyKiHpO7YqB2+OgX3ERgUW6K27V6gMHxTHjyeYibKuT8sJYD4X uCkXWdlzRsl7FOQrmZTHiawMF1IRyvk647KHCo+HQCMRiPPdolAU/DYTN5r/3d4+y+sV yQt3hrGhBrxoNC2I4H+2eJSKsPd4CTAAuf2nrcBJPcNLZ8RMwxPhnZUkVoaGQKIiCai4 K8zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493418; x=1792098218; 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=pgpiLoGoqA0xV5yWN2rO1XVw1oOPWsG2lgMDpzrz1ts=; b=p0uwXazXjkHsd7L8b6zb5b+DRr9gNomKGjJfnY4VRpGz1DDCAiMQtbBujEDje9Z2k1 l2/LxiXlWyq+itSGXVXVu9GhNMoN1tHRBtnUbrYWgfELCIJEDZ3dpqEy7GIkl5AIYXcu kNYtgNHsl6OL+z6hf0G3IgK5cg1uLbDUIReLLHqWrO3AnuNfeDvAcCerCPGash7a00y6 LcC0iEZqSiauO6Tprs10lXK2ii1wTV4djnO0Uw6KV79UUHC3sujEjlGC8RfX5qfjmEDw Rm6kyS0yoUMsj4VmvY8qNSeW+PkFlS4xztGWCeck8hPnsiUe5X1EoX0wzsXUpn0x9QmJ +X1Q== X-Forwarded-Encrypted: i=1; AKwUvBymJ5S9hLB/THiMxymD5cMdsVJulYGXJtQ2LULGPp8LoQdrH84wn4o2yGNUutKEyvYKGHzlsUeTt0M=@lists.xenproject.org X-Gm-Message-State: AFuF++kbyrsEuHP9xkJCbtIgXUPOFHthXzJQipLFxy3hK2bw1HO37vfb 9J1h6Z1JJQTga1EbMHSTyD4xQvghBeujndoZA27FktHOwdHla4AhNhyf2vpKIbmL51M= X-Gm-Gg: AYBFou0eL6DDhEwsbgFPTzi/IgaIUInLWAGPQBwfB5bP0etI38AiENAd+dkYFQeh/u4 Qwkkl2u7E3rFGkVqUsYJ8fLgt4gnk6dEhtgT19DWPSE7AgHhzogppZvQCznfmc8rbegI9RkSmr6 jQLwZ4KJsbQgLCqrNGTuISwyFhAMN1zcNXu9H+dM1vlv/QdZNfOpcS6KQSpf1UQIXPK4d0pY2Lu TWCaMspvyZbb4OgIIuRuf7cfwcuXUl1My3FruQkLm6T+E9Rc2BV0FFhy1BhjtsPauG5L6ImQMvc mnJZ+hBAKl1WewdsFM0aQ7p17wQ+A8kYpT58bSRIwfwTEeJMfdrF4rvRtvaCxZ33kvbmn/wYPCM nfP+Y5A3/aOvYk+HFYGrv/ZuYvmxqminLBro9XJaO6Blyk6gPDMNz934MTqyb40DXqSwIUfJqZo gfszusVR6KqzPZKJ5IXjAm8raMmtcpjkmMKMKueREljqLtZ/VYY1HlrFGWiy0o+ZJ50Dbdj5JF/ i/x2Xr85Tth7Dg= X-Received: by 2002:a05:622a:90a:b0:530:e52a:8ef0 with SMTP id d75a77b69052e-535754fe4e9mr117963541cf.26.1791493418024; Thu, 08 Oct 2026 14:03:38 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:54 +0000 Subject: [PATCH net-next v2 07/10] e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-7-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493385; l=1188; i=josef@toxicpanda.com; h=from:subject:message-id; bh=2XY23bjEEEbmilzyi/OT0dLNP6D+zOB3zspYb8/aVZ4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QAo/dBnlSZS1Mj/EC08Jadkujj6NZVKDZ6T6FMxXeYq/Bm8xNWGafGFpWL2jadSBYVOawvF0VKq O0PAtfO9A+w0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1791493419-A9AC09EA-58F2B083/0/0 X-purgate-type: clean X-purgate-size: 1190 e1000_xmit_frame() uses __pskb_pull_tail() to pull up to 4 bytes of payload into the head when the head holds only the TSO headers. It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 844f31ab37ad..e216868e15cb 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5859,8 +5859,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb, unsigned int pull_size; pull_size = min_t(unsigned int, 4, skb->data_len); - if (!__pskb_pull_tail(skb, pull_size)) { - e_err("__pskb_pull_tail failed.\n"); + if (!pskb_may_pull(skb, len + pull_size)) { + e_err("pskb_may_pull failed.\n"); dev_kfree_skb_any(skb); return NETDEV_TX_OK; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443812.1660983 (Exim 4.92) (envelope-from ) id 1xEvHD-0006Dv-Cc; Thu, 08 Oct 2026 21:03:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443812.1660983; Thu, 08 Oct 2026 21:03: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 1xEvHD-0006De-8D; Thu, 08 Oct 2026 21:03:43 +0000 Received: by outflank-mailman (input) for mailman id 1443812; Thu, 08 Oct 2026 21:03:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvHB-0005xv-Vy for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvHB-005tQx-CW for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:41 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac804fa-8faa-0a2a0a5109dd-0a2a4501cd66-48 for ; Thu, 08 Oct 2026 23:03:41 +0200 Received: from [209.85.219.49] (helo=mail-qv1-f49.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8052c-5984-0a2a45010019-d155db31bda8-3 for ; Thu, 08 Oct 2026 23:03:41 +0200 Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-9178aabd30dso34366136d6.1 for ; Thu, 08 Oct 2026 14:03:41 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.249]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91b550ce8a5sm77746d6.40.2026.10.08.14.03.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=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=1791493420; x=1792098220; 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=hz4PLreF7SMRfFt85q6B38gbUo5+Y+8z8sLQb0vICiM=; b=r0x9pXrNMk9z9SW3DuBk4j3mzM2W41MoV37Hvbn3nm/jEeI1XlWIKu5gvu6KN3CVSM IJOKvKmCzKfYDeZtmOi4EjwNL2bwezoAjvHyNhy2gt18nXrdZovhvXYGIE++GODgr0/a UHtHP1EolggBFHO7SwFsyhy+v2Ss9RMBqLiQW7m+Hh1IfBoyQlZ9mqZe6FtD3OMfw9wi Gta6kgI6IKPnPIQ2a1J/D6tFlk21fZ2vYnI5SPFHAx8ypV3tTfS+NlQZgSUp0RX7RpyS wyXybaMky9aRwyzIrX2MlahiydyKr6orO01iO8JTjSZOjvBtVkdxJ+tgb2YDFmM64tqe 5xZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493420; x=1792098220; 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=hz4PLreF7SMRfFt85q6B38gbUo5+Y+8z8sLQb0vICiM=; b=IGhitPJPlZgVGwwb7u11rkjZtfbCZvFSCikY0noP+C04vZ8ssiScBEZMaaKQHOBOoN 3YhA+ipLamX4UJ3fSnk3oR8GU7CaNTIJy/KqzOkAUdFj5GoXVzrE7wcDYyysM5tzt6gb TFYbXe0UlkUl09v4PB1Ha9SBYZGZWsDxJ7PEKAtg/HEXEdGKePZVbA06HgbdsVeUH0uO 1StpuRtKnjPSqvihJlHhTLLxPKMXMsT1fOLOp6ypu35w7R2qPSu+loLdxDkpkT9agrXS UfkhF9yKUd3iIkxb9mnELf0hoQ0G4G9m1SlAAK4ssH0aBFcrGwryIXtm4smWsZPHDQWT ER+A== X-Forwarded-Encrypted: i=1; AKwUvBwfZndDMdyurdG5l+u58FDnkBic44baZ9aOTYY/Cttqtx/2D5C3ItJODYARSVJZ3bpgvqFxSoyI3AU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKh/7KCcULuF9tg+t26uDxl0R/xwBrsquppRa9G1YaxL6shLWsi 4Btdl1erE0VWxG9AHE1zdClH6MvIODLR+3I4QZ4DUJPJVTf4TDV368Cd6YAZvfNdMvc= X-Gm-Gg: AYBFou20aKrFsyWFeEOgzGaN9VdQ9yVhPdmQfUKSbra5ZIlLZYCWrsnFsb8BzrB3I5B TDbENdugdQa+ZxWqVDqJY7YOfK//zSKVH2KltF4KwFi+2YclJpQDN7J4AofSvgHyDrjKIAPd+0k rRImp4NFCfhiCG0orDSdN2fdlTQLFjls9NVTxXsAVSvp1fmxb3l7Zjrj1mh1X5j9EYl3/8gW+76 Cq5vnMaGRsGrOZZKFG61UZqXTPFTayXZHWXFhdVtPAXKBH0PviF6U2A1C8ok8YrtiFeCijGNC9q cPLzX3xoLfVz5kgtobqxRg2NiBOOg+Di/LPIYUvsMmB/er+P6LZcsxxfN4GxC1gUfcKka/3CNkX kvYoFkHNdM0Xf+DM0si0Kj6sa5gguByOIycrDhW41DuZm/6i72o5ibjG4mF29ezb5wP+oeRmH+e XUya1dzOQr3M91KFsBjGRk397sRE8LxkLo0AxYwdhlxKJrnsT+5ctZ0JrEqusmSMO4sBJdoW7iz fwnVn1sZANrr5w= X-Received: by 2002:a05:6214:2b86:b0:919:952e:588d with SMTP id 6a1803df08f44-919978d6737mr122288916d6.56.1791493419767; Thu, 08 Oct 2026 14:03:39 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:55 +0000 Subject: [PATCH net-next v2 08/10] netxen: use pskb_may_pull() to pull excess TX frags into the head MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-8-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493385; l=1424; i=josef@toxicpanda.com; h=from:subject:message-id; bh=2MH/LzfAfYyw21+HKj408easdoK7+Tc42GivpUT/gq0=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QKxQbKwa+3oPMIR9/8wstf89TfYBkXylWZ+7HP6SNMiYKVAMjbRgDk4LveZCkr1O9fxCwKO82Xi ZBjyd9+CX/ww= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1791493421-BD341757-1E7CFBF0/0/0 X-purgate-type: clean X-purgate-size: 1426 netxen_nic_xmit_frame() pulls the frags that don't fit in a TX descriptor into the head with __pskb_pull_tail(). It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. __pskb_pull_tail() also releases empty frags, even when there's nothing to pull, so if the frags being pulled are all empty it still gets the frag count under the limit. pskb_may_pull() returns early in that case, so follow it with skb_drop_empty_frags(). Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c index 67d9bf69f8f2..f5f89ed87d95 100644 --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c @@ -2045,7 +2045,8 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev) delta += skb_frag_size(frag); } - if (!__pskb_pull_tail(skb, delta)) + if (!pskb_may_pull(skb, skb_headlen(skb) + delta) || + skb_drop_empty_frags(skb, GFP_ATOMIC)) goto drop_packet; frag_count = 1 + skb_shinfo(skb)->nr_frags; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443815.1660992 (Exim 4.92) (envelope-from ) id 1xEvHE-0006Tv-MQ; Thu, 08 Oct 2026 21:03:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443815.1660992; Thu, 08 Oct 2026 21:03: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 1xEvHE-0006TQ-Hg; Thu, 08 Oct 2026 21:03:44 +0000 Received: by outflank-mailman (input) for mailman id 1443815; Thu, 08 Oct 2026 21:03:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvHD-0006K9-SU for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvHD-005tQx-9M for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:43 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8052e-8faa-0a2a0a5109dd-0a2a4501aacc-2 for ; Thu, 08 Oct 2026 23:03:43 +0200 Received: from [209.85.160.182] (helo=mail-qt1-f182.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8052e-5984-0a2a45010019-d155a0b6f186-3 for ; Thu, 08 Oct 2026 23:03:43 +0200 Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-53396adbc53so58804691cf.3 for ; Thu, 08 Oct 2026 14:03:42 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.241]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5359b6fa262sm3360381cf.6.2026.10.08.14.03.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=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=1791493422; x=1792098222; 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=soiW+4bnwYoMWX+4s8jp0T9nXKlporFXyr3eC0IUFGM=; b=nlxcQrq/kIVHUnQ9fevqlpHqNUaY09idgkcEGk/uq9la8+EdQ2DJWOELa0hcByXZNt CclOZuTYw/dyLVUDKGx/9KUGoQqtekg7TrEbNGk51/UmoOPbTFSO9oFlwYEbWhKdNhnb 8bfFgPusgNlG7k4a/wkNN3lI3r6jr6SsCzdHSEeXDsMb91HbnHTVO8ZbZ8P7GA7X3UM2 JUEonScpKwfu4A5Bjv5YaJhT1n8eHr8xgR4UeDoUg3LZe5V3yrIHdWQIYEif9GYLTcfG wIXJkIdlm185jFkVBLwgeLCa+fzftRwCl2ycDNxAu8k4XQQrO5/lTQNE9tdlxedgyinz OqsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493422; x=1792098222; 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=soiW+4bnwYoMWX+4s8jp0T9nXKlporFXyr3eC0IUFGM=; b=eGzfvdOJkKuADkQinObDB2S8Ly3GGe3b6dtw7oY2R9bJh+xHykcQI8vUqr+MPmn9/I +KV/4+DOQcLio/9qX9CH2Uqv/q1IXTE3un20wTA28ZEO+9B9ARXR3RqsQ3MuMFnIJ4B5 GMqzPTklQDLixj32GZjICcQDNRZDqrNZVvsdca5EaeiE92xnEOc+TtsFEi4tWqOpZbrJ GQE9PAfCy+bYCDEGnyS6GV21LmOzeSV+yzBFXKf4C+OOatqwsec7eDPuQjs/XHNXpQes BzwZT/dXhCYCHCjtgSl0J6Jx+vZr9vH6O5X1GouUJKfZQGJ+LoSGx8bNh+PaeKyYIiha T6Ng== X-Forwarded-Encrypted: i=1; AKwUvBz5CV/w31IiA/GBAlVsPQr9Htla11VBCveoOYhjl1G9g1ErQgrOPkCfTLHuj1KcQdq7mwCd3Rf58Ak=@lists.xenproject.org X-Gm-Message-State: AFuF++muYXf7HHf7211UV22LYZuMQqVTVHOjdbAlRCGIdrHl10CxkH7r ahC93funGYX9/fU4ZCI+WipHmli3au9mcdLQ81rd30c5F+cRdr7k+M5Roe4KbBbmXsI= X-Gm-Gg: AYBFou0ms+xfgGf6CxF1WeF1DsN2X/1GNUn+fYecoPDCdiwPv5l0pxa4Uq4Q7XHDSes OfvlTf+MjXQeJTXjgKl+9zte3yIEVyQp1+S4Wr19el66/bHwH8VhzJlcXYKHXjjoKAmNK9DOd+h ddEJPnViWbi4fT6u2baoIKrjG2mNPbuKeqSwwpRS3VRO+gQ9oeLbjG89J8rX5czXwJ8Fr4i/+zq G96Nbbq10qXOlJx6R0ifbEM1gytTmrVRjC+WgPa1RMRZLKVDCdQK6lFliy8crNb0kTRcytZvJzO AnDytI/nlLwWADmT0ptLCrvqnddZEOxnjBW4Qtbfm873ABKOOBAQRQ1leRCHXx12d9CiAZ9yOIG lCY948UeYE4BFV4b/+RkhzUIxHigrtD8Iw0jZ4S3XSMwuuI0nHhtr0+Mo74ZBQjETsyrhD+0ytT nMSqoqrNvO2je1qc7gV0WfUsGzkptONowmSz60/+GxiE1ZcxLhMoap6EL7DaQDC+sXWXGrOJrkf 3IqRlH88qh0JM8= X-Received: by 2002:a05:622a:4016:b0:530:f634:467f with SMTP id d75a77b69052e-53575391446mr121614331cf.15.1791493421782; Thu, 08 Oct 2026 14:03:41 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:56 +0000 Subject: [PATCH net-next v2 09/10] qlcnic: use pskb_may_pull() to pull excess TX frags into the head MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-9-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493385; l=1476; i=josef@toxicpanda.com; h=from:subject:message-id; bh=ySH+2yHpni3G+Qu86hbeGyzGTFoSfZJVBnTvasjUVEw=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPIm2UmKVJ/FEKcAKGan3gEEsd83c98i++zBisuax140+xkclErvJSJq3lYfXk1tL7clYoB6cuo y7erG0zM7/wc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1791493423-1FE68757-95B04C18/0/0 X-purgate-type: clean X-purgate-size: 1478 qlcnic_xmit_frame() pulls the frags that don't fit in a TX descriptor into the head with __pskb_pull_tail(). It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb, so this driver no longer calls __pskb_pull_tail() directly. __pskb_pull_tail() also releases empty frags, even when there's nothing to pull, so if the frags being pulled are all empty it still gets the frag count under the limit. pskb_may_pull() returns early in that case, so follow it with skb_drop_empty_frags(). Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c index 761ef3bc8193..e7ab5586798b 100644 --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c @@ -682,7 +682,8 @@ netdev_tx_t qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev) for (i = 0; i < (frag_count - QLCNIC_MAX_FRAGS_PER_TX); i++) delta += skb_frag_size(&skb_shinfo(skb)->frags[i]); - if (!__pskb_pull_tail(skb, delta)) + if (!pskb_may_pull(skb, skb_headlen(skb) + delta) || + skb_drop_empty_frags(skb, GFP_ATOMIC)) goto drop_packet; frag_count = 1 + skb_shinfo(skb)->nr_frags; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:03:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:03:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443817.1661001 (Exim 4.92) (envelope-from ) id 1xEvHI-00070V-6t; Thu, 08 Oct 2026 21:03:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443817.1661001; Thu, 08 Oct 2026 21:03: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 1xEvHI-00070F-1w; Thu, 08 Oct 2026 21:03:48 +0000 Received: by outflank-mailman (input) for mailman id 1443817; Thu, 08 Oct 2026 21:03:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvHG-0006lG-3H for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:03:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvHF-00H9qs-GG for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:03:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac804fa-e002-0a2a0a5209dd-0a2a45058608-36 for ; Thu, 08 Oct 2026 23:03:45 +0200 Received: from [209.85.219.48] (helo=mail-qv1-f48.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac80530-4cb1-0a2a45050019-d155db30e447-3 for ; Thu, 08 Oct 2026 23:03:45 +0200 Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-9178d514951so44008966d6.0 for ; Thu, 08 Oct 2026 14:03:45 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91b550d394bsm79796d6.41.2026.10.08.14.03.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2026 14:03: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=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=1791493424; x=1792098224; 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=D0uSM/A3oRPIUcCVkMNaXKAYlboH4f+zE5JovH6Ln9w=; b=FN6pICXzk8lxXJQcB9Yn0uYlXOcbchVD7uKqbpdl0ZwmraaOm3d5oGqfDxrLn5Y57y Ank6ILUeuwLlF4obzmncx7IuEBymHtfwfMhr+SI+9DYcVp8WfraSEtfWLfP71luMI0Ix tLXWNjjinuuwIfEVz+fgUuJ79pwKq3tEHucfKrCztOeJVH5zzuguqCswr0Fy5lT3EIgw 9fHUWuBceM2i9qus2/hCCiyooC60X6BEeg+Et+sotyIdQACNVAt8cU27Y4l0HmyPzuqq RhtGvZBxd3Fc+ikij110egfFGUK7Sds6MgiJzi9UJJ6KU7EpfLP9aCMjpO9tvHqCXBYh UKZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791493424; x=1792098224; 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=D0uSM/A3oRPIUcCVkMNaXKAYlboH4f+zE5JovH6Ln9w=; b=0rPb9XCFOB7jAsaesPp0NqqGKn2Y1x1o49lxm+kogYum6wxJu5gJlEulrNwBGDg7Mo 9P10UwlOY5hIpBjXVCDgWKYNl956eXIQBXy9/f9rIvvx37hoP0OLey3QPyMDUJ1p7cVj uFku77/68NoXZfxA15jLnX/r9N4Srh11YlDoPNHXh0EIuNNIrqURSIPehH5nU/dYRd2L pTXAaXbAqy+7f/tKmq6Ly2nuAJND+A4EY4VEObysxH5yteXvROplQWISkz+6Rml1OFYx VmpyGGlI2/NNMbo8wIGgdxJjJlC99fwMyBBul3SgFxRba+fKRcJHvsDCYGQAVUHYQBfV jjCA== X-Forwarded-Encrypted: i=1; AKwUvByh6anpGI5hFLFJz1ymPR0U14Kui/717xiVHMCwBsgcnm1iAlZ3vsEpUvFh1YWpfr5nr+MsaLxRsPo=@lists.xenproject.org X-Gm-Message-State: AFq9FYLxRGQMrKRQksNK+kYsoYinLFWdTY1Mqp15Y+nUENiJ8E50mnsF JN9Mw7mHmCjVdMdi7cnc2/GwX74RGxZjXlazGwzPXvDsbbiKV2QKij90uP6CHkkJA3FUmXb0ESv RgHM4/3y/Bg== X-Gm-Gg: AYBFou1ShSShmRyWsMhVdaf58iHoimy3ew/Kf7VxkJldGrygRmXyh63vy2oS/MvIgfz hmXWeTsW03EN+/myuzpm7+/g9BUzVKWTQtFZJGUTXwhynOnXUsoqNyZ6Z7dV/DecE63urzAIeR9 asaUGQXK6Tn4nCcI8onJp0oIXLWqqpcdusIl+urNjsoYGCMDIaAWqiLc4oCt/b3+X7sssfAyac/ yyhxT4c6Zg+rVEjk9ZBAUXq3NMqt2j0jTRx2oPfV6pqcfp9F7LTOJVe2uXmkONZ/gk+FQIF5ScH Wrv+jBgp//QRW2bvPkQs4mJ17jlfT3Dfqob5SYsMIcAaA+lrg7vVwJDlDXN6xh3D2ptZaQbGEMW gHOHxd2je0UrPrFeE4H+jl0/MFI+P/fbrxttjvtjo7QE6OpYD8Nc6sZqCvicrmkbUG2w0JDm2TS R5ZABFW+Roa/6EGxnvG98Su3APXfAVkHRmKOlGAzTjD6PcvH9+3BrknUgErHkA52Ca31EJ9Fywk AmSZiz9Z4NQwJY= X-Received: by 2002:a05:6214:ca3:b0:919:952d:7ff9 with SMTP id 6a1803df08f44-919978f7ebamr126853616d6.57.1791493423774; Thu, 08 Oct 2026 14:03:43 -0700 (PDT) From: Josef Bacik Date: Thu, 08 Oct 2026 21:02:57 +0000 Subject: [PATCH net-next v2 10/10] net: skbuff: don't reset truesize in skb_condense() if the pull fails MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261008-b4-pskb-pull-tail-drivers-v2-10-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> To: Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1791493385; l=1285; i=josef@toxicpanda.com; h=from:subject:message-id; bh=G4GQSS/z86H6HrzRjtGCGkhfNcr1ZqkSUEOCEKTi8N4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QD7QXznJXVwY4tvhlA2g/ntlgNB9z4EYJ24pFBre8ehTYCPfcNpsZClmKSf0INhwTvOUpctCjRC vzNH0Zo1blA8= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c201ff/1791493425-F64B42A1-BD22BD31/0/0 X-purgate-type: clean X-purgate-size: 1287 skb_condense() pulls all of the frag data into the head and then sets truesize to cover just the head, but it ignores the return value of __pskb_pull_tail(). If the pull failed, the frags would still be attached and truesize would undercount them. It can't fail today. The caller has checked that the head has room, that the skb isn't cloned and that the frags are readable, and pulling all of data_len eats every frag_list skb whole, so nothing is allocated. Check the result anyway and leave the skb alone on failure, so this stays correct if any of that changes. Use __skb_linearize(), which is what this pull is. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index f798118df112..556d37981f0f 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -7158,7 +7158,8 @@ void skb_condense(struct sk_buff *skb) return; /* Nice, we can free page frag(s) right now */ - __pskb_pull_tail(skb, skb->data_len); + if (__skb_linearize(skb)) + return; } /* At this point, skb->truesize might be over estimated, * because skb had a fragment, and fragments do not tell -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 08 21:11:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 21:11:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443858.1661011 (Exim 4.92) (envelope-from ) id 1xEvOs-00036M-0C; Thu, 08 Oct 2026 21:11:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443858.1661011; Thu, 08 Oct 2026 21:11: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 1xEvOr-00036F-Sm; Thu, 08 Oct 2026 21:11:37 +0000 Received: by outflank-mailman (input) for mailman id 1443858; Thu, 08 Oct 2026 21:11:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEvOq-000368-9E for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 21:11:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEvOp-005uKM-1W for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 23:11:35 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac806e8-2eae-0a2a0a5409dd-0a2a4506cdc8-28 for ; Thu, 08 Oct 2026 23:11:34 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac80705-195a-0a2a45060019-aceafc1fc0e8-3 for ; Thu, 08 Oct 2026 23:11:34 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id C9CAC42D5E; Thu, 8 Oct 2026 21:11:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A0CF1F000FF; Thu, 8 Oct 2026 21:11: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=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=1791493892; bh=lO9Q2e8Y8FPOsNAN94Y+ZK3KJEQqlWXugM2M+fiTfDI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=S706qOQl1KAdCZOgdDVMYgOE4hYOCFoLj0OyQ4qoN9BspPLdeodADinWXSjmhRHPm YK6++L4AqfMMStuF3wzAtgh6ofzYLZyTuNkxuyHRftbWxys9dfl71hAL2ADlumB2j4 Tlf+AacXZTvAllcV36WUE+Y/a0IFDRwSp+VV1bOhp608vbuhGe4I50uG/6bjXTuRbU MgtwPQ9PON+9mJdWcdYRCA/L+ckiTY+6L5j/raZg/L3j8/d3+Hj0xoxEow7kB5Iox5 crTPl9+UhAUBLNXTGVR130JjQDVJHP9OplaEfsJcnRyehfe3Di3kCPBvhOprydKfRb IRpNlHZe0yUqQ== Date: Thu, 8 Oct 2026 14:11:31 -0700 From: Jakub Kicinski To: Josef Bacik Cc: Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn , Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Subject: Re: [PATCH net-next v2 00/10] net: stop calling __pskb_pull_tail() from drivers Message-ID: <20261008141131.0ac356dd@kernel.org> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1791493894-1F6C877B-FE15340C/0/0 X-purgate-type: clean X-purgate-size: 685 On Thu, 08 Oct 2026 21:02:47 +0000 Josef Bacik wrote: > v1->v2: > - New 1/10: skb_drop_empty_frags(). xen-netfront, netxen and qlcnic > relied on __pskb_pull_tail() releasing zero-length frags even when > there's nothing to pull, which pskb_may_pull() doesn't do (Sashiko). > - xen-netfront, netxen, qlcnic: call skb_drop_empty_frags() after > pskb_may_pull(). > - skb_drop_empty_frags() checked with a boot-time test under KASAN and > kmemleak, on cloned and uncloned skbs. Please keep in mind that we ask people to limit themselves to 15 outstanding patches per tree. You have 18 right now. (200 active netdev contributors + an LLM) x 20 patches == insanity :/ From xen-devel-bounces@lists.xenproject.org Thu Oct 08 22:24:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Oct 2026 22:24:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443896.1661018 (Exim 4.92) (envelope-from ) id 1xEwXY-0000v1-T7; Thu, 08 Oct 2026 22:24:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443896.1661018; Thu, 08 Oct 2026 22: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 1xEwXY-0000uu-Q7; Thu, 08 Oct 2026 22:24:40 +0000 Received: by outflank-mailman (input) for mailman id 1443896; Thu, 08 Oct 2026 22:24:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xEwXY-0000uo-4X for xen-devel@lists.xenproject.org; Thu, 08 Oct 2026 22:24:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xEwXX-002TsI-EK for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 00:24:39 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac817fd-bab6-0a2a0a5309dd-0a2a450ab848-12 for ; Fri, 09 Oct 2026 00:24:39 +0200 Received: from [52.101.43.35] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8181a-f2d2-0a2a450a0019-34652b23af54-3 for ; Fri, 09 Oct 2026 00:24:28 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DSM1PFC01C1A90F.namprd03.prod.outlook.com (2603:10b6:f:fc02::557) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Thu, 8 Oct 2026 22:24: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.0496.015; Thu, 8 Oct 2026 22:24: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=d0FhqAY/6UpxYIptU0FZbhlLuJfcEtDgWCdU9lTzFX+uPad3ngD7JF67I+6AAAsPvcifbBn6UwEjBJ0cAsn7iP/8LsHzBlB0RaMXD2C9sWPbAhNIb9C4ejxI940VxKrIIWPIZkFM/NhhRPikUJtvA8mGt3wux2Fz1GSGBLZkyJ6O0dLUaRa2SV9i5z6FUu9e/yjEzeHXm0hPo7l7Bn2rwWytKdBoRblBpiEPAGddxYhK3R8ndv8ccBdCs4WqODS+kD3BXAdQkKQCjU8L+94a+PMO7SUwOVYWvLvQ6cD2TxS7vLaixBF1Al/I2nfUg5LibzvjvnnOvAQ5UYa0n7ir8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6pCxmB9xXZ17+QIHJjnwcnU9NS8Cm6QIPEn6kWj5V/k=; b=OsAatPyPlej6BFDWNehBvV5pqTVgYyTmbgdxHTTBwKu25HWmX5MIFl64xIqg8ArNN2FZ/qQDaTBwyfp8d9hs+tmuY1Orndd6XUgFrRWCL4cQy6dZRrtZvRpJ0jFTVtcXLunDJ8Dd9QIgGvip+hf5SHJltjbtYpz0C3e2XUghjh3njHr7nxzw5hc/9iZikpW7LXpf8QzC290Nd49U6V+HHviJUmpBGbL1v7/RE8+e2ZMJl5E9BcWtbZVoSCWTcppVLgbx/3+OmHbo3AJQb9AMC24ZjClXSgH/q2PIomrrvZk9k0osSK0Bka5ILaVF1QosoWCShqvOEpT0shQTX+jP+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=6pCxmB9xXZ17+QIHJjnwcnU9NS8Cm6QIPEn6kWj5V/k=; b=Z+5eFd6xKxBZq8XkIbpnX+19RYrFa3ldTwnsC5dG1CS+apm2IDLuKn98Vz32ld/SVGjQk5wZl6p9CNtKOAl29xWK94E0l4uEy8Dd/5gmOsjTkmVHspkM4fwVP7nVVEetSEUWtqIPMBmp5Xq9UuJpMtjJ95Q9ngUqpX+PohhB6jc= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1710db3c-049d-40d4-bb49-2dba34609c77@citrix.com> Date: Thu, 8 Oct 2026 23:24:20 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH v3 01/18] x86/PoD: map one page at a time in p2m_pod_zero_check() To: George Dunlap References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-2-gwd@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0510.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:272::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DSM1PFC01C1A90F:EE_ X-MS-Office365-Filtering-Correlation-Id: 854a6ff4-653c-4003-efd6-08df258ae7ef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|56012099006|11063799006|4143699003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: iS7aNpO8wa9qzeJYgwqbb178z9cYPSr8JvIBBXoXguRSkUbrWgayRgqSm680UlUx/1O14n633kNym7tZrSDrdBQJVKTSIK1lBsO5gypWUUmPQThtMhpWM5GKt2i8XshHMsKSifFUPn4Dikh20vGkOq5Iu9EJKnhEXTvQQ5JBXGo3u3UwsuM3stX/uHt7mYu0nx5tOqwb2GR256p2FbNPlC+WyajxlqTwBbrTx5iMnaBtYv/E7rATnJ5/bV6IQMoOYY7Xm0l6+962PGMLme2f6gZGlasvzfuc6ndf8K2942Cc99oEkc8Y+t0VJt2EAtSI/+gv51WwU/HIdMksGRGlomicArZwTksDcKppA1xIxLTgrcf/Lcp1T+MEN9POcJZUyGp1Ioc/ROwDo9w4RZXJrlj2gncGartYe4X/9RJF2tR7C6EUJR0HrX2NO19qFjquGqu3X89ixmOszf3akH6kcrc/nUh7962NF1ds+cKt3PiCdEyr5Am6fVonQvLrdLpyUCBZrSfrk7dkf3B8X0BTOz039wMIdww77ARB0npK5zxBCPgUoFY3iAh1iTGu5C6M6v+ocK/r/eOT7Osg7fBiJ3LJOcPwEiC+I52sDHUlJ8NvROCQLiPmB5BLoZi8JmyO 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)(23010399003)(376014)(56012099006)(11063799006)(4143699003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U0J1YUVNU21YNm5aZktWM3pnYldQbWF5cDRVeklmNlhjakhEQWdHSDlxemFw?= =?utf-8?B?NndPMC8wOE5XbTI3Z1BpSXZob1FGOWJWT2RxTUVTYUprYWdyYkQ3UmVvZkFH?= =?utf-8?B?SHVaRUhVcS8veVJzcy9GeXBTbmQrdW5HVVRZVWxpSWlNOEUwbHdxTVFpZTd2?= =?utf-8?B?dnl0bXNIZWFVMVd1eVFsYkZvSDViRjRZMUxvVmhZSXpQSmpFcjUrUTJ4anly?= =?utf-8?B?THA1SEFVcGErdVp2THJaWkNIN1BWWXpySkdvdlo1RGwxa1FZa21lcmJqQ0Nh?= =?utf-8?B?YzJjajhNcE1KbGZBTlZsV0QzTkNhZHhIbkJHaTlFSXh2RHU1Njg2QXVtSjJq?= =?utf-8?B?NTV4RTVQa21aQTR6V3liWlQzV1JHVkV0N2wxc3B5R1NLZzVHVkd5cGt0am1M?= =?utf-8?B?aU1ERVoxcUdZalhId0JsZ3ZJK2ZGTk13VUp3Ym5BNFhJVEQ5U1R0U0tZdWJk?= =?utf-8?B?anFtQ2x3TTc1RUcrMHR0UEY0QmlsU005cWNvUG1sRWlya3d1VTAxUUZ2dUl3?= =?utf-8?B?c0Q2NksrZWdyOEtlRWVCK0k4S251NVpKOWk1NVRQSDR2bXMyM3N5STNJeEF0?= =?utf-8?B?QW9KZ0dQWlVoRGpya21iZktHM1B5QjlhWW5sS1NsRVh0VVpEQ0hsaS9odXpF?= =?utf-8?B?bWxSUHFrL0ZDMWJWNXQvMzAzRDdxNG4zczR1Q1d6d05aN2VvNU5CbnZvM3lR?= =?utf-8?B?WHg2WDk2QWwzSTJsV0lBVnBOalNJMUJTWExMQUZBZGFIYlFrY21nYmJHeEov?= =?utf-8?B?WWM3WjhCTnI3MmVwQkVWdjN0VStoY3Q4QkxEbmYyd2VFZmZKamlJS1M1eG5K?= =?utf-8?B?MERwMzAvaWN5WWluYXRaVkUzZEc0MlEwaHAxTUtqdk9CdlJPWUM2bUxIMXBC?= =?utf-8?B?SGFHK1FMUjhVWERSTGRYSm1sckdVTVdmUEJneFhnOHQ4elRRUXBWbVdNZFhv?= =?utf-8?B?dmZMUzE5NnBWWUZZMzJLQTlwQVc1V2NxS0dkeUVNUkpDTzlVV1BxRFk5MWty?= =?utf-8?B?RmZ6NHV3SVBwS3llT1hLSDZvWXR3d1ArMlRBMk5hblpKT1BVZ3FuNzVlNm9U?= =?utf-8?B?MmJBSWZHa3hlUzB4L1lCM2xpekF1ZHpyemlBY2tsa1J5VUlFWGpjTjlsSUdV?= =?utf-8?B?bUVCeGZUVGZaRFdRcHBUNys2b3dickNyVWxGaFBTenRQaGlIQWh0Q2tRQjE4?= =?utf-8?B?ZHhhRS9lUmVoQ3hHMmk1VlA2Y2xrQlZMUy8vcGYxSWFmZlBiT0ZtZlA3Rjkv?= =?utf-8?B?SWFTYTBJckJtRlQrdnpPZUhDTWtqaDFEdVoxQ2dleEhiMG84SGhIenpPMEda?= =?utf-8?B?SFIwY0Y5Zko0aVhJbkpEZ0FSNlpTaFRrNzk1OXV3WStrWExGSm5qNXIxQk1n?= =?utf-8?B?ZXVIdFVwdTVZM0NtZlM2elE2UUhuZkl4ejlFVS9YOGNrWm5tQkhIYkUzbG8r?= =?utf-8?B?a2x5cTFqdzFZYWZ0U3RhenB4Skl4U2pST0doVjdRZlhUbGlKMGpWSW1ZLzdJ?= =?utf-8?B?cjNrYzlJVVFuWWlybWdad01iR1hnbFpaMG5SL3ZGYmp1d2tZV041MW1nZjhN?= =?utf-8?B?RnkrNHdsNlZtaDExbjFvcHd5ZXlienNnbmVEa0RidUFUdFJHeTN2YmZyMXND?= =?utf-8?B?YitHbmszQ1k2RGN6akJDNHJwbGpUZ0pjdnNtSmE5VTNSbUpObmJmTDJ1ZUZC?= =?utf-8?B?a1MwNGZhZzlzcklaL0lHNFFTUVJiQldnRUlJNzVlSldSU2F3QSs3VEFhUmQz?= =?utf-8?B?R25vcjdnMFBhQVQ4R25MNlNvOFM0VWxMeGNuZ1huR0VycG1zbW1MZCt4OFdm?= =?utf-8?B?c0dLSEdMaVdSSUQ0ZkdQRW5PL3BLWERTeHZTblRxUXFWRkRHVWQ3aTBHNlZv?= =?utf-8?B?VjZjNjRZUGdiNmd3a3BoY3JQMUZTQzVsZ2pYN3ZwT1ZCUVpsZHBialAySUwx?= =?utf-8?B?Z2xnRXBDWi9rUGkvV1lab0grT01JTUJZam9HM1RPa2ZvQVBzUUJRRmZUZGxP?= =?utf-8?B?ZkxGQ1JTYVc0UWY4ZElTZEk1MHRSd0dnOFNSeGZtR2VxOG40eHUvYXZVUk1Z?= =?utf-8?B?d1ErY2dDaEVnNk5sVHlpTU4zcXZpckh3a2lGN21FOFVKbWR2ZnNha3E0dUFh?= =?utf-8?B?eHNiY052RjBsTVRnTmtpVEl0OEFNRFdNSUt2MVRoV2I3NXMxTlBWTHlsc3ZU?= =?utf-8?B?VjlOclBNTm5RclplRm8zUEhoR1REVDk0azkyNTFLdHFVMmg0ZjdML0ltR1Rw?= =?utf-8?B?Ry9NWDduL2dGNXgxZmtYd1Y2Q0x6a3hCUlk5UEkxZ203SW1vTDRHWFRTWkxp?= =?utf-8?B?WE5DaVlHaDBZOFdHQllpclMzbU45RldCWWFlNUJFVWtkVDIxUXhaQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 854a6ff4-653c-4003-efd6-08df258ae7ef X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2026 22:24:23.7707 (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: ox9hG1h3xsJFTBUAN+IRf5CuI/7lvXaVn3c2fl2Say0uatp+q5m/twjcd2fbgX2vjafKbdUaGeuHgC1ehm+LdsX2Vc4LTyqSwe/SOy7FPdI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSM1PFC01C1A90F X-purgate-ID: tlsNG-4011c0/1791498268-589C9CFC-400DA203/0/0 X-purgate-type: clean X-purgate-size: 1856 On 08/10/2026 12:09 pm, George Dunlap wrote: > On Wed, Oct 7, 2026 at 1:38 PM Andrew Cooper wrote: >> On 07/10/2026 11:40 am, George Dunlap wrote: >>> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c >>> index 4602c32cff..0b0beca15a 100644 >>> --- a/xen/arch/x86/mm/p2m-pod.c >>> +++ b/xen/arch/x86/mm/p2m-pod.c >>> @@ -911,7 +912,12 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count >>> if ( paging_mode_shadow(d) ) >>> max_ref++; >>> >>> - /* First, get the gfn list, translate to mfns, and map the pages. */ >>> + /* >>> + * First, get the gfn list, translate to mfns, and pick the pages to >>> + * check. They are mapped one at a time below, as in >>> + * p2m_pod_zero_check_superpage(): a vCPU can hold only a few transient >>> + * mappings at once, and the p2m lookups and updates here need some too. >>> + */ >> Actually, I think this wants almost entirely dropping. Yes, "and maps >> the pages." needs editing, and should probably say "and check for being >> a plausible candidate" or so, which was missing previously. >> >> The rest is a justification of why we do mapping in the same way we do >> it generally, and not useful to have in the source code. > Yes, sorry about the verbose comment, I forgot to go back and give > this a more detailed review. I'll trim back the comment. Thanks. > > Re the bool array: I assumed the compiler would turn that into a > bitmask. That not being the case, I'll switch to bitops. I'm not aware of any optimisation pass which could make that transform. https://godbolt.org/z/d76qW4Tzz GCC will convert the (1 << x) expressions into BT{,S,R} when it can see they're all in range, but it can't turn the bool array into a bitmap. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 09 05:22:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 05:22:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1443979.1661028 (Exim 4.92) (envelope-from ) id 1xF33u-0001uA-CD; Fri, 09 Oct 2026 05:22:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1443979.1661028; Fri, 09 Oct 2026 05:22: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 1xF33u-0001u2-6x; Fri, 09 Oct 2026 05:22:30 +0000 Received: by outflank-mailman (input) for mailman id 1443979; Fri, 09 Oct 2026 03:42:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF1Ug-0002LN-Oa for xen-devel@lists.xen.org; Fri, 09 Oct 2026 03:42:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF1Uf-002yIb-Bj for xen-devel@lists.xen.org; Fri, 09 Oct 2026 05:42:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac86275-2eae-0a2a0a5409dd-0a2a4504dde2-22 for ; Fri, 09 Oct 2026 05:42:01 +0200 Received: from [79.135.106.102] (helo=mail-106102.protonmail.ch) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac86288-b57f-0a2a45040019-4f876a6655c7-3 for ; Fri, 09 Oct 2026 05:42:00 +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=1791517320; x=1791776520; bh=7xEP0BwOm+Wjfg745mbqtSbJwSPPZ5c6kTyYB62ycjc=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=ePn72O3t2Jh3jMSNTvA/tqQrM5BZBuDa6QINpJp0b+D71wcYIG6Tlir8+4bmru1qs ccysKaRF6Aj+bi/hU9Jt7SYA2oP+oPX13IrJGCuvUNDL3rTOiGgPuLwieX0Rnw+Nuh jFqHCuyv8eVeyGJ1Ek4+LHwp4R0fXiZ+o+psRL9PZDdiYhWvGR7ub2yUvRtijt9w/g hjU+oVcGAYdbd7Xxv/RUepTgc5ncX0PZMmUp8fpQwVWXGry6MlQXwQIhZUQhltZlXN bj+t5/GGvNt0QaeeGgnBUYGS2mUoug/3pbUNU8z+j1fP4h+dFW2ep5SutBNsAh8J/m mTAyhsoHQwRYw== Date: Fri, 09 Oct 2026 03:41:54 +0000 To: "xen-devel@lists.xen.org" From: Egon Ojamaa Subject: [BUG] Xen Dom0 fails to boot with "nvme.poll_queues=24" and "dom0_max_vcpus=6 dom0_vcpus_pin" Message-ID: Feedback-ID: 7420290:user:proton X-Pm-Message-ID: a5b2b37bade96ace708a66bf0105832a11b84d4c MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_gYh7w7uHhel9M57pR6drcK6XRP3DOFRXOtqU3YCg" X-purgate-ID: tlsNG-ebf023/1791517321-583C0B50-A5229B45/0/0 X-purgate-type: clean X-purgate-size: 9433 --b1=_gYh7w7uHhel9M57pR6drcK6XRP3DOFRXOtqU3YCg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sIFJlYWwgaHVtYW4gd3JpdGluZywgbm90IEFJIGhlcmUgOykKCiMjIyMgUHJvYmxlbToK CkJvb3RpbmcgWGVuIGh5cGVydmlzb3Igd2l0aCBMaW51eCBEb20wLgpHUlVCIGxvYWRzLCBYZW4g a2VybmVsIG1lc3NhZ2VzIGxvYWQgdXAgdG8gIlVzaW5nIDYgQ1BVIgoKIyBGcm9tIHRoaXMgcG9p bnQ6Ck5leHQgc2NyZWVuIGdvZXMgYmxhY2sgYW5kIHN0YXlzIGJsYW5rIGZvciAxMCttaW51dGVz LgpIYXZlIHRvIGZvcmNlIHJlYm9vdCBhbmQgY2hvb3NlIG5vbiBYRU4ga2VybmVsIGJvb3Rpbmcg b3B0aW9uIHZpYSBHUlVCLgoKIyBGcm9tIHRoaXMgcG9pbnQgZXhwZWN0ZWQgYmVoYXZpb3VyIHdp dGhvdXQgYnVnOgpOZXh0IHNjcmVlbiBnb2VzIGJsYWNrIGFuZCBzdGF5cyBzbyBmb3IgMzAtNzBz ZWMgYW5kIERvbTAga2VybmVsIG1lc3NhZ2VzIGFwcGVhciwKTmV4dCBsb2dpbiBpcyBwb3NzaWJs ZSBhbmQgc3lzdGVtIGlzIHJ1bm5pbmcsICJ4bCBpbmZvIiBhbmQgb3RoZXIgeGwgY29tbWFuZHMg ZnVuY3Rpb24uCgojIyMjIENhdXNlOgpJIHNwZW50IDIgZGF5cyByZWJvb3RpbmcgdG8gbmFycm93 IHRoaXMgZG93bi4uCgpUaGlzIGhhcHBlbnMgaWYgd2Ugc2V0IGJvdGggc2V0dGluZ3Mgc2FtZSB0 aW1lOgpOVk1FIGlvIHBvbGxpbmcgYW5kIFhFTiBrZXJuZWwgQ1BVIGxpbWl0cywgdmlhIGRlZmF1 bHQgZ3J1YiBjb25maWdzOgoKR1JVQl9DTURMSU5FX0xJTlVYX0RFRkFVTFQ9Im52bWUucG9sbF9x dWV1ZXM9MjQiCgojIENhbiBhbHNvIGJlIHNldCB2aWEgL21udC9vbGRyb290L2V0Yy9tb2Rwcm9i ZS5kL252bWUuY29uZgojIEZvciBwcm9wZXIgcG9sbGluZyBzZXR1cCBudm1lLmlvX3BvbGw9MSBz aG91bGQgYWxzbyBiZSBzZXQsCiMgYnV0IHN5bXB0b20gYWxyZWFkeSBhcHBlYXJzIGlmIHdlIHNl dCBvbmx5IG52bWUucG9sbF9xdWV1ZXM9MjQKCmFuZAoKR1JVQl9DTURMSU5FX1hFTl9ERUZBVUxU PSJkb20wX21heF92Y3B1cz02IGRvbTBfdmNwdXNfcGluIgoKIyMjIyBBZmZlY3RlZCBzb2Z0d2Fy ZToKCjI0LjA0LjQgTFRTIChOb2JsZSBOdW1iYXQpCktlcm5lbDogNi44LjAtMTM2LWdlbmVyaWMg eDg2XzY0CkFuZCBIV0U6IDcuMC4wLTM4LWdlbmVyaWMgeDg2XzY0Cnhlbi1oeXBlcnZpc29yLTQu MTctYW1kNjQgNC4xNy4zKzEwLWcwOTE0NjZiYTU1LTEuMXVidW50dTMKCiMjIHVwZGF0aW5nIHdh cyBhdHRlbXB0ZWQsIGJ1dCBzYW1lIHN5bXB0b21zIHN0aWxsOgoKMjYuMDQuMSBMVFMgKFJlc29s dXRlIFJhY2Nvb24pCktlcm5lbDogNy4wLjAtMzgtZ2VuZXJpYyB4ODZfNjQKeGVuLWh5cGVydmlz b3ItNC4yMC1hbWQ2NCA0LjIwLjIrNy1nMWJhZGNmNTAzNS0yYnVpbGQyCgojIyMjIEhhcmR3YXJl OgoKU3VwZXJtaWNybyBNQiwKQU1EIEVQWUMgWmVuNSBDUFUgd2l0aCA0OHRocmVhZHMsCihob3Jy ZW5kZXVzIDIrbWluIGJvb3QgdGltZSB0byBHUlVCLCBzZXJ2ZXIgTUIgd2l0aCBCTUMvSVBNSSkK CkJJT1MgKG5vdCBzdXJlIGhvdyByZWxldmFudCk6CkFDUEkgU1JBVCBMMyBDYWNoZSBBcyBOVU1B IERvbWFpbiAtIEVuYWJsZWQKSU9NTVUgLSBlbmFibGVkCkRNQSBQcm90ZWN0aW9uIC0gZW5hYmxl ZApETUFyIFN1cHBvcnQgLSBkaXNhYmxlZCAoaWYgZW5hYmxlZCB3ZSBnZXQgKzUwc2VjIHRvIGJv b3QgdGltZSkKRFJUTSBWaXJ0dWFsIERldmljZSBTdXBwb3J0IC0gZW5hYmVsZApEUlRNIE1lbW9y eSBSZXNlcnZhdGlvbiAtIGVuYWJlbGQKU0VWLVNOUCBTdXBwb3J0IC0gZW5hYmxlZApBU1BNIFN1 cHBvcnQgLSBlbmFibGVkIGZvciAyNC4wNCB0ZXN0aW5nIGxhdGVyIHNldCBpdCB0byBkaXNhYmxl ZCBmb3IgMjYuMDQgdGVzdGluZy4KCkdlbjUgTlZNRSBkaXNrcyBjb25uZWN0ZWQgdmlhIGJpZnVy Y2F0aW9uIGNhcmRzOgo1cGllY2VzOiBDcnVjaWFsIFQ3MDAgLyBQTjogQ1QyMDAwVDcwMFNTRDUK NHBpZWNlczogRmlyZUN1ZGEgNTQwIC8gUE46IDNKVDMwMS0zMDAKMXBpZWNlOiBMZXhhciBOTTEw OTAgLyBQTjogTE5NMTA5MDAwMlQtUk5BTkcKClNhZGx5IG5vdCBteSBwZXJzb25hbCBzeXN0ZW0s IHNvIEkgY2FuIG5vdCBkbyBmdXJ0aGVyIGhlYXZ5IHRlc3Rpbmcgb24gaXQuCmlvIHBvbGxpbmcg ZG9lcyBnaXZlIHZlcnkgZ29vZCBwZXJmb3JtYW5jZSBib29zdCB0byBHZW41IE5WTUUsIGFuZCBl dmVuIEdlbjQuClNhZCB3ZSBjYW50IHVzZSBpdCwgYXMgQ1BVIHBpbm5pbmcgaXMgbW9yZSBpbXBv cnRhbnQgZm9yIFhFTiBoeXBlcnZpem9yIHN5c3RlbS4KClRoaXMgaGFzIGJlZW4gYWxzbyByZXBv cnRlZCB0byBsYXVuY2hwYWQubmV0OgpodHRwczovL2J1Z3MubGF1bmNocGFkLm5ldC91YnVudHUv K3NvdXJjZS9saW51eC8rYnVnLzIxNzAyNzAKClNpbmNlcmVseSwKRWdvbiBPLg== --b1=_gYh7w7uHhel9M57pR6drcK6XRP3DOFRXOtqU3YCg Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdj48c3Bhbj5IZWxsbywgUmVhbCBodW1hbiB3cml0aW5nLCBub3QgQUkgaGVyZSA7KTwvc3Bh bj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPiMjIyMgUHJvYmxlbTo8L3NwYW4+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5Cb290aW5nIFhlbiBoeXBlcnZpc29yIHdpdGgg TGludXggRG9tMC48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5HUlVCIGxvYWRzLCBYZW4ga2VybmVs IG1lc3NhZ2VzIGxvYWQgdXAgdG8gIlVzaW5nIDYgQ1BVIiA8L3NwYW4+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48c3Bhbj4jIEZyb20gdGhpcyBwb2ludDo8L3NwYW4+PC9kaXY+PGRpdj48c3Bh bj5OZXh0IHNjcmVlbiBnb2VzIGJsYWNrIGFuZCBzdGF5cyBibGFuayBmb3IgMTArbWludXRlcy48 L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5IYXZlIHRvIGZvcmNlIHJlYm9vdCBhbmQgY2hvb3NlIG5v biBYRU4ga2VybmVsIGJvb3Rpbmcgb3B0aW9uIHZpYSBHUlVCLjwvc3Bhbj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PjxzcGFuPiMgRnJvbSB0aGlzIHBvaW50IGV4cGVjdGVkIGJlaGF2aW91ciB3 aXRob3V0IGJ1Zzo8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5OZXh0IHNjcmVlbiBnb2VzIGJsYWNr IGFuZCBzdGF5cyBzbyBmb3IgMzAtNzBzZWMgYW5kIERvbTAga2VybmVsIG1lc3NhZ2VzIGFwcGVh ciwgPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+TmV4dCBsb2dpbiBpcyBwb3NzaWJsZSBhbmQgc3lz dGVtIGlzIHJ1bm5pbmcsICJ4bCBpbmZvIiBhbmQgb3RoZXIgeGwgY29tbWFuZHMgZnVuY3Rpb24u PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PHNwYW4+IyMjIyBDYXVzZTo8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5JIHNwZW50IDIg ZGF5cyByZWJvb3RpbmcgdG8gbmFycm93IHRoaXMgZG93bi4uPC9zcGFuPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PHNwYW4+VGhpcyBoYXBwZW5zIGlmIHdlIHNldCBib3RoIHNldHRpbmdzIHNh bWUgdGltZTo8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5OVk1FIGlvIHBvbGxpbmcgYW5kIFhFTiBr ZXJuZWwgQ1BVIGxpbWl0cywgdmlhIGRlZmF1bHQgZ3J1YiBjb25maWdzOjwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkdSVUJfQ01ETElORV9MSU5VWF9ERUZBVUxUPSJudm1l LnBvbGxfcXVldWVzPTI0Ijwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPiMg Q2FuIGFsc28gYmUgc2V0IHZpYSAvbW50L29sZHJvb3QvZXRjL21vZHByb2JlLmQvbnZtZS5jb25m PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+IyBGb3IgcHJvcGVyIHBvbGxpbmcgc2V0dXAgbnZtZS5p b19wb2xsPTEgc2hvdWxkIGFsc28gYmUgc2V0LCA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4jIGJ1 dCBzeW1wdG9tIGFscmVhZHkgYXBwZWFycyBpZiB3ZSBzZXQgb25seSBudm1lLnBvbGxfcXVldWVz PTI0PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+YW5kPC9zcGFuPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+R1JVQl9DTURMSU5FX1hFTl9ERUZBVUxUPSJkb20w X21heF92Y3B1cz02IGRvbTBfdmNwdXNfcGluIjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPiMjIyMgQWZmZWN0ZWQgc29m dHdhcmU6PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+MjQuMDQuNCBMVFMg KE5vYmxlIE51bWJhdCk8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5LZXJuZWw6ICZuYnNwOyA2Ljgu MC0xMzYtZ2VuZXJpYyB4ODZfNjQgJm5ic3A7IDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkFuZCBI V0U6ICZuYnNwOzcuMC4wLTM4LWdlbmVyaWMgeDg2XzY0PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+ eGVuLWh5cGVydmlzb3ItNC4xNy1hbWQ2NCA0LjE3LjMrMTAtZzA5MTQ2NmJhNTUtMS4xdWJ1bnR1 Mzwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPiMjIHVwZGF0aW5nIHdhcyBh dHRlbXB0ZWQsIGJ1dCBzYW1lIHN5bXB0b21zIHN0aWxsOjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PjxzcGFuPjI2LjA0LjEgTFRTIChSZXNvbHV0ZSBSYWNjb29uKTwvc3Bhbj48L2Rp dj48ZGl2PjxzcGFuPktlcm5lbDogJm5ic3A7IDcuMC4wLTM4LWdlbmVyaWMgeDg2XzY0PC9zcGFu PjwvZGl2PjxkaXY+PHNwYW4+eGVuLWh5cGVydmlzb3ItNC4yMC1hbWQ2NCA0LjIwLjIrNy1nMWJh ZGNmNTAzNS0yYnVpbGQyPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+IyMjIyBIYXJkd2FyZTo8L3NwYW4+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj48c3Bhbj5TdXBlcm1pY3JvIE1CLDwvc3Bhbj48L2Rpdj48ZGl2Pjxz cGFuPkFNRCBFUFlDIFplbjUgQ1BVIHdpdGggNDh0aHJlYWRzLDwvc3Bhbj48L2Rpdj48ZGl2Pjxz cGFuPihob3JyZW5kZXVzIDIrbWluIGJvb3QgdGltZSB0byBHUlVCLCBzZXJ2ZXIgTUIgd2l0aCBC TUMvSVBNSSk8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5CSU9TIChub3Qg c3VyZSBob3cgcmVsZXZhbnQpOiA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDtBQ1BJIFNS QVQgTDMgQ2FjaGUgQXMgTlVNQSBEb21haW4gLSBFbmFibGVkPC9zcGFuPjwvZGl2PjxkaXY+PHNw YW4+Jm5ic3A7SU9NTVUgLSBlbmFibGVkPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7RE1B IFByb3RlY3Rpb24gLSBlbmFibGVkPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7RE1BciBT dXBwb3J0IC0gZGlzYWJsZWQgKGlmIGVuYWJsZWQgd2UgZ2V0ICs1MHNlYyB0byBib290IHRpbWUp PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7RFJUTSBWaXJ0dWFsIERldmljZSBTdXBwb3J0 IC0gZW5hYmVsZDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwO0RSVE0gTWVtb3J5IFJlc2Vy dmF0aW9uIC0gZW5hYmVsZDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwO1NFVi1TTlAgU3Vw cG9ydCAtIGVuYWJsZWQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDtBU1BNIFN1cHBvcnQg LSBlbmFibGVkIGZvciAyNC4wNCB0ZXN0aW5nIGxhdGVyIHNldCBpdCB0byBkaXNhYmxlZCBmb3Ig MjYuMDQgdGVzdGluZy48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5HZW41 IE5WTUUgZGlza3MgY29ubmVjdGVkIHZpYSBiaWZ1cmNhdGlvbiBjYXJkczo8L3NwYW4+PC9kaXY+ PGRpdj48c3Bhbj41cGllY2VzOiBDcnVjaWFsIFQ3MDAgLyBQTjogQ1QyMDAwVDcwMFNTRDUgPC9z cGFuPjwvZGl2PjxkaXY+PHNwYW4+NHBpZWNlczogRmlyZUN1ZGEgNTQwIC8gUE46IDNKVDMwMS0z MDA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4xcGllY2U6IExleGFyIE5NMTA5MCAvIFBOOiBMTk0x MDkwMDAyVC1STkFORzwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PjxzcGFuPlNhZGx5IG5vdCBteSBwZXJzb25hbCBzeXN0ZW0sIHNvIEkgY2FuIG5vdCBkbyBm dXJ0aGVyIGhlYXZ5IHRlc3Rpbmcgb24gaXQuPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+aW8gcG9s bGluZyBkb2VzIGdpdmUgdmVyeSBnb29kIHBlcmZvcm1hbmNlIGJvb3N0IHRvIEdlbjUgTlZNRSwg YW5kIGV2ZW4gR2VuNC48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5TYWQgd2UgY2FudCB1c2UgaXQs IGFzIENQVSBwaW5uaW5nIGlzIG1vcmUgaW1wb3J0YW50IGZvciBYRU4gaHlwZXJ2aXpvciBzeXN0 ZW0uPGJyPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4+PGJyPlRoaXMgaGFzIGJlZW4gYWxzbyBy ZXBvcnRlZCB0byBsYXVuY2hwYWQubmV0Ojxicj48c3Bhbj48YSB0YXJnZXQ9Il9ibGFuayIgcmVs PSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVmPSJodHRwczovL2J1Z3MubGF1bmNo cGFkLm5ldC91YnVudHUvK3NvdXJjZS9saW51eC8rYnVnLzIxNzAyNzAiPmh0dHBzOi8vYnVncy5s YXVuY2hwYWQubmV0L3VidW50dS8rc291cmNlL2xpbnV4LytidWcvMjE3MDI3MDwvYT48L3NwYW4+ PGJyPjxicj5TaW5jZXJlbHksPGJyPkVnb24gTy48YnI+PGJyPjwvc3Bhbj48L2Rpdj48c3Bhbj48 L3NwYW4+ --b1=_gYh7w7uHhel9M57pR6drcK6XRP3DOFRXOtqU3YCg-- From xen-devel-bounces@lists.xenproject.org Fri Oct 09 05:57:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 05:57:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444007.1661038 (Exim 4.92) (envelope-from ) id 1xF3bI-0007cT-Tp; Fri, 09 Oct 2026 05:57:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444007.1661038; Fri, 09 Oct 2026 05:57: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 1xF3bI-0007cL-Pr; Fri, 09 Oct 2026 05:57:00 +0000 Received: by outflank-mailman (input) for mailman id 1444007; Fri, 09 Oct 2026 05:56:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xF3bH-0007cD-Mn for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 05:56:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF3bH-00EaxV-3i for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 07:56:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8821d-2eae-0a2a0a5409dd-0a2a4509e1fc-26 for ; Fri, 09 Oct 2026 07:56:59 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8822a-be1a-0a2a45090019-d155dd2dc042-3 for ; Fri, 09 Oct 2026 07:56:58 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48b042c0759so2981138f8f.2 for ; Thu, 08 Oct 2026 22:56: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 ffacd0b85a97d-48db98c38f4sm2323024f8f.27.2026.10.08.22.56.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2026 22:56: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=1791525418; x=1792130218; 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=l+rL8v2kQ8U6lg4n2oLB7unBdmY9A+5fNdSo4wCgado=; b=c9Da7gqeqoY7Cajhif7xKfn5PhVSUutbkYUmO1klRpY1rKPYzqKDwz5R4ytAVOZ73t /IV19CTilZvleD9iNICFUz0MrpyDraJklWx91bvkpFQvwY6iCS23mGNh0FLdnBAwAYvV TFrwsgM9UvONZ3zhYMJb4QbUrknd8zj/U8XlY9Qgz0VNUJ6nqK+AuJLw/RxuGBUdOw6q 8yj0OLett22JxBvPoUwvFz05nLeGBaStzLnV6CNwbb9qpn30UcHH8LqclQCge3V/K0SH dyAnzCBpE7sREULJMRQPmsNLdcRQyjQZqIEivMN051fYZUJf00SKVRZ6x1jJtR2frapg lrbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791525418; x=1792130218; 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=l+rL8v2kQ8U6lg4n2oLB7unBdmY9A+5fNdSo4wCgado=; b=FPforxVgRUOh1L8QzPzeMIfIFjulhTjw0skAjk25XsMSfya0wrRne3CBsqR1weMZ1V qc00YdlLnifgXqoF4zGnGZdD1/yZZTLRQCMzKObLkSwv7+McPyVCIuVFNHqG90On9Svz 1aTjr7o81rRk8IQBHTi0X3PmPsCRpQY7rVrOAFZ5C0VJ0TNN1aqoGCemXzPj0cj/GnhG yGAGaQ67PuUnhy5xkQ27oELihnnU6uZdXI4DYIEemA2ELDXyaR+1W6IhfvO9C2tOB+BC pe33TVqz8adOMbw2LZ1/UPcvwy684krYizHSbmvmRQ35+vU+Nuq0Od5PBMBtJgIT84ZZ 8JGg== X-Forwarded-Encrypted: i=1; AKwUvBzgbkVoogCLLqTXGpdjuLd+N2Q6hYBabK1RNNW3+F96UlfZ7tjGhmMw+JK6Kew0KV2sB+exQPW4i18=@lists.xenproject.org X-Gm-Message-State: AFq9FYKeVhsKJxlYf6yMVUzUMyyI7FAwSXZYqiXQb0J1g783saZ0zGfz rbBhXhcEot15i/Hsuzfk2VcmzxPn5e/bCivVTaUBfqum48Bvfuhx6W0IxrLLjxv8KQ== X-Gm-Gg: AYBFou3+y+dQuRfxkSi+yqY5FIE3VyxvHInj1odPZC/fDwVIkbx9MxW9O4PIW5u5TNz DL+78GVHxkRxNsYTFylNy9C/Zf1qHNcKltVCNfLCbURmUc8hlCqKTPIyb3+s4xZQi83GGSpAfXD EFopHgzvzFoV05286FptrP6qF17aCFYqNxeunuyQXIMRUDjG+Yy2SbyTYuRklR+ZFzrLF6Spjn3 0g4X3XtIyLkPm/A+ZYv3v3ELXGoVPCUESgw2F5EzSxmK5LE16F4JVX5R0f/Igh9mt58N07o9sVd M/HaRUnNWRK0JlewtfiX4DWtZgaIO4o4k65LqaOxeN31SFsVm0n9DEzHgQz/SASdgduKl+bkClR gQxqZxbKwgtlnHhUQQdRxlVXZMzi13pA0Dz7Gn4SqyjNuD42cliwaQTp6x8NyrRi785yFYVnXtN qaSrEf/NhE22Vqw71MW2HptwPOljCsj0QP8eeX/KsVwzPnLh3EMSwiK3cPKBEKtandm7ek/y0dQ IxQI0Lkyhl4/dbiqanaHVpg3KmAchoVp8YdSfGZ5e+Zzju8OJa81XZPQoevhLNR X-Received: by 2002:a05:6000:2992:10b0:488:654b:ccd8 with SMTP id ffacd0b85a97d-48dba7819famr976363f8f.6.1791525417754; Thu, 08 Oct 2026 22:56:57 -0700 (PDT) Message-ID: Date: Fri, 9 Oct 2026 07:56:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: add timeout for XHCI console cable To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 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: <20261008150528.359731-1-marmarek@invisiblethingslab.com> <8f61b665-17ca-4eda-b452-313eff8bff93@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/1791525418-BDEC6034-71982DB8/10/78276251493 X-purgate-type: spam X-purgate-size: 2966 On 08.10.2026 18:08, Marek Marczykowski-Górecki wrote: > On Thu, Oct 08, 2026 at 05:54:53PM +0200, Jan Beulich wrote: >> On 08.10.2026 17:05, Marek Marczykowski-Górecki wrote: >>> Do not wait indefinitely for XHCI to configure console connection. If >>> the cable is not plugged in, timeout after about 1s and continue boot. >>> If the cable is plugged in later, the console will be activated then >>> (see final part of dbc_ensure_running()). When timeout occurs, print a >>> warning message - it will be saved in the console ring buffer, to be >>> later retrieved from dom0, or possibly later printed when the cable is >>> finally connected. But, do not print the warning when waiting after >>> controller reset, as that may have been called from from console >>> dbc_putc() and printing here would result in (possibly infinite) >>> recursion. >>> >>> Try the timeout to be about 1s, which is way above time needed for >>> configuring already connected cable. But, since this part runs very >>> early in the Xen startup, time is not calibrated yet, and functions like >>> NOW() do not work yet. Use raw TSC and estimate needed time to be at >>> least 1s on a fast CPU (5GHz), and possibly longer on a slower one. This >>> is not very accurate method, but fortunately it doesn't need to be. >> >> A little fragile, but well... >> >>> --- a/xen/drivers/char/xhci-dbc.c >>> +++ b/xen/drivers/char/xhci-dbc.c >>> @@ -851,9 +851,15 @@ static void dbc_reset_debug_port(struct dbc *dbc) >>> } >>> } >>> >>> -static void dbc_enable_dbc(struct dbc *dbc) >>> +static bool dbc_enable_dbc(struct dbc *dbc) >>> { >>> struct dbc_reg *reg = dbc->dbc_reg; >>> + s_time_t start; >>> + /* >>> + * Too early for proper time calibration, assume a 5GHz CPU and let it wait >>> + * about 1s, with still reasonable timeout on a slower CPU. >>> + */ >>> + unsigned long timeout_ticks = 5UL*1000*1000*1000; >> >> Even if right now we don't use the driver in any 32-bit env, I think we >> better wouldn't deliberately break such a possible use. IOW unsigned >> long isn't a suitable type to use here. > > So, uint64_t? No, as per ... >> Also, nit (style): Blanks please around *. >> >>> @@ -870,8 +876,12 @@ static void dbc_enable_dbc(struct dbc *dbc) >>> writel(readl(®->portsc) | (1U << DBC_PSC_PED), ®->portsc); >>> wmb(); >>> >>> - while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 ) >>> + start = rdtsc_ordered(); >>> + while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 && >>> + rdtsc_ordered() - start < timeout_ticks ) >> >> Urgh - now the driver's truly becoming x86-specific. Is there a reason >> this cannot be get_cycles()? > > Sure, it can be get_cycles(). I just need it to not try to apply scaling > that works only after calibration, but indeed get_cycles() should work. ... this it would want to be cycles_t. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 09 07:07:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 07:07:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444021.1661046 (Exim 4.92) (envelope-from ) id 1xF4h5-00013e-Nc; Fri, 09 Oct 2026 07:07:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444021.1661046; Fri, 09 Oct 2026 07:07: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 1xF4h5-00013W-KO; Fri, 09 Oct 2026 07:07:03 +0000 Received: by outflank-mailman (input) for mailman id 1444021; Fri, 09 Oct 2026 07:07:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xF4h4-00013Q-4V for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 07:07:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF4h3-00Ep9J-HG for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 09:07:01 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac89286-e002-0a2a0a5209dd-0a2a4507bc4a-14 for ; Fri, 09 Oct 2026 09:06:57 +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 6ac89290-b4ea-0a2a45070019-d155802dc456-3 for ; Fri, 09 Oct 2026 09:06:57 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a018792ab3so33742085e9.0 for ; Fri, 09 Oct 2026 00:06: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-4a18bf2343asm64123705e9.9.2026.10.09.00.06.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 00:06: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=1791529616; x=1792134416; 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=VLtL/UQ4aw9dMmG4Iu9JqlxjJJAQbHVRvsBfn3pquMw=; b=RgcbAzpV5nHtvcM7KaJel3ytPSApdcefg8HCFV8qBCHY4tZ4FAVq9yVcJ7Y1X5MmNg 86YI0mpqXkwc4KerAcS8rUEVAFnoLtf6PSRh0+fF9hiUnMr0u4Yq1wtKVWtKH0UDg4vv 2h0TuSMLgQLOIPPlTNbIV6tUsbj0OJw6TF0wh61EXITv5zDM7vLgFSz6BzcciD1YeoMi fnPQm8IGJCUBwMss67m/b2szn9JaD0hNQLYo6eLjTtYFJl5ADy+nq0MCIp2sXWuFSUbW ehWwpLOLLQJXf4nYCTxpTYG4WBTgkD70BXSYZyLAA1N0gP4zj2PxIBW2VgyhLjaDse3d TKEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791529616; x=1792134416; 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=VLtL/UQ4aw9dMmG4Iu9JqlxjJJAQbHVRvsBfn3pquMw=; b=PkTysTI+xsgB1ExEiJjunr7fCNIMTCDPvxzVFvbjKf7h4/o+YLiQ5SgnoUIX/bFHyE mNmF+azX8mcMqMb7R4RN/d4bP306jMao1sdQ7sdHxbWU6f86SBrNhwj17rr7lR5GAOA1 3rRvV4R42pTeG3FTkTg+W3vIeZbvM8uU9TkI9XN1hW4I/5K9YDXog4J/LUkzGk9dq+4B 9gyofutlB7G7jqcZpLbKUCpjE6k4r+FGQACkg43NTzc98IvP8eaid04pVYMLkhd6d2eH +PhrCKBNU1He53/qOjyqWQfcb0SpMJQO5kaE5LZQ/0NIdTR5NIwRp3k4LvUyxDTDZzau amnA== X-Forwarded-Encrypted: i=1; AKwUvBxfLAqIeDshRTRNzj0rM49+FiedwZ/r+f1LPCTZ6krbASN0NdtTxVj78f1UFqehOWLvlUv7E7kt1r8=@lists.xenproject.org X-Gm-Message-State: AFuF++m0r9TWl9TOO62PW6flCNRNCnd4YpDybY6UW9VUdeCrTRYeqNu3 pGi6rFjnGjsTTEHFwMX6aE1GfjKaUNxua1wiEO1DCmtLJpXP+rim76HNpyHjqmNHzg== X-Gm-Gg: AYBFou0/Jby4Ipp4DqraZ9V8jKAMm+t1Ys1ZcDhnf5SXLtT8ZAEi6HKCuga+azH2EtX auzT9qfjbQOhW5REFYixn0N4CWEwg4e+dsOV+f2xLNFGUYFOzW3aMvnh9ro8F4k7XQpClp5b8R7 5B93Kd6NDWKwFOztVaGRlEL1mNFyjdI8GF621l83kAQ1puGjSeHMEcSmKZhDDj2IxS2/IEwcibu BpCDox8mtRvnKYw0gX/daYwl89mH4HxOG6G3uT/zAtJYBTCmO9FbR1+NphIaiKz5PUm2Xrsp0Um ZF+MlhW3zsifdv1M4VUKyNgCg4UzoxrqmzdCg7icnCWaAoKu/pnf13A91dCsnHnlFNR5Yr4yoiI zQHMnU245ehmQrN7gV1YrCyS265UQLjto9mhpn9aFy7ocOR5rRknGza924svPC1mg8n3w5F2AQd GPWlUnzGTtB7o3Ys1TCbjyN7hbBOU/8HUh/zQcdF9z35cj7jKgBH03lba2EUb8zgg4eeLK1gIVv H1ncg4tmmIac0w4ugMKd6VE7VCrIdtc97tzQm+G5WKJeoe9X49hevdfATTaKQ== X-Received: by 2002:a05:600c:8184:b0:4a0:1c17:4fb2 with SMTP id 5b1f17b1804b1-4a18e4d854cmr12053725e9.31.1791529616576; Fri, 09 Oct 2026 00:06:56 -0700 (PDT) Message-ID: <10316579-4372-4ade-9114-53c737053e0c@suse.com> Date: Fri, 9 Oct 2026 09:06:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 07/18] x86/hvm: introduce per-vCPU L3 page-table To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Tim Deegan , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-8-gwd@xenproject.org> <7bced27f-5391-4120-b9cf-b97bb88758ca@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/1791529617-A56C2AE4-1DDA1060/10/78276251493 X-purgate-type: spam X-purgate-size: 1414 On 08.10.2026 23:00, George Dunlap wrote: > On Thu, Oct 8, 2026 at 9:40 AM Jan Beulich wrote: >> On 07.10.2026 12:40, George Dunlap wrote: >>> --- 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->domain, v, INVALID_MFN, false); >> >> This being PV-only code, don't you want to pass NULL here? The description >> talks about this, but (a) it's not quite clear why PV32 would want handling >> differently from PV64 at this point and (b) in sh_make_shadow() you do pass >> NULL unconditionally. > > This is actually left over from the previous iteration of the series > which supports PV guests; and apparently it would be a lot easier for > implement per-vCPU pagetables for 32-bit PV guests, since the L4 > doesn't belong to the guest. But it's outside of the scope of the > current work. > > At any rate, I'm going to try passing a single vcpu, as Roger > suggested. That restricts toolstacks to not being able to promote PV > L4s before calling XEN_DOMCTL_max_vcpus, but that seems fine to me. But my question was why it's not NULL that is being passed here. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 09 07:59:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 07:59:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444035.1661056 (Exim 4.92) (envelope-from ) id 1xF5VF-0008DV-Aj; Fri, 09 Oct 2026 07:58:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444035.1661056; Fri, 09 Oct 2026 07: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 1xF5VF-0008DN-74; Fri, 09 Oct 2026 07:58:53 +0000 Received: by outflank-mailman (input) for mailman id 1444035; Fri, 09 Oct 2026 07:58:51 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF5VD-0008DH-Hm for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 07:58:51 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xF5VC-004haQ-2s; Fri, 09 Oct 2026 07:58:50 +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 1xF5VC-000xRX-1h; Fri, 09 Oct 2026 07:58: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" 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=lr4MY+D+xpnz1ymcfppbFvLxwpTSo1hOMK+sxi+OY5Q=; b=qWd+Vts5xpqkOpHTIijYAbme4C SktYu+1WhN56Itb2VXl/Yh5TLQY5O8Ug1D9pmrmT9h2wsZyVpbYgjc1HG2WXRn5sS/1+vpglk5F5G b6L3ScqdvqKY2hcktTscC31cZi+ixP2SkDo5HIaVYOkbOIqLMNHGK5JRlyNQZzaYBW1k=; Date: Fri, 9 Oct 2026 09:58:45 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 17/18] x86/mm: run guest contexts on the sparse directmap view Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-18-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261007104051.48841-18-gwd@xenproject.org> On Wed, Oct 07, 2026 at 11:40:50AM +0100, George Dunlap wrote: > In init_xen_l4_slots(), if d->arch.sparse_dmap is set, point the > directmap L3 at the sparse view. > > d->arch.sparse_dmap is decided at domain creation: PV domains all have a > mapcache, HVM domains need per-vCPU page-tables for one. No option asks > for the sparse view yet. Is it strictly needed to tie the sparse directmap to having a per-vCPU mapcache on HVM? AFAICT HVM domains could also use the classic per-domain mapcache. > The sparse view becomes active once dom0 is built, before it first runs: > dom0's construction runs on the full directmap, which it needs, and its > root page-tables so far (a PV dom0's first L4s, a PVH dom0's monitor > tables) are switched over then. A PV dom0 booted with dom0=shadow is > switched as well: shadow mode is enabled only later, from a tasklet, and > its shadow L4s then get the sparse view from init_xen_l4_slots(), as for > any PV domain entering shadow mode. Anything built later gets the > sparse view from init_xen_l4_slots(). The sparse view's slots are > marked NX at activation, as the full directmap's slots are. Is NX worth mentioning here? The expectation is that the sparse dmap slots will use the same attributes as the full dmap, and hence I would focus on the differences (if any). > The two directmaps differ where the sparse view leaves memory out, so no > translation of the full directmap may remain usable on page-tables > carrying the sparse view. Directmap mappings stay global nevertheless: > every CR3 write which can move a CPU onto the sparse view goes through > switch_cr3_cr4(), which flushes the old page-tables' translations, > global entries included, before it returns. The CR3 writes which keep > entries -- a PV vCPU's switch between its kernel and user page-tables, > XPTI's entry and exit -- stay within one vCPU's page-tables, which carry > the same directmap, or go to XPTI's per-CPU root, which maps only Xen's > own per-CPU pages there. Removals from the sparse view are flushed on > every CPU, global entries included. PV guests running with global > pages, a PV dom0 not using the sparse view among them, so keep their > directmap TLB entries across switches between guest kernel and user > mode. > > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - New in this version. > --- > xen/arch/x86/include/asm/sparse-directmap.h | 11 ++ > xen/arch/x86/mm.c | 9 +- > xen/arch/x86/setup.c | 3 + > xen/arch/x86/sparse-directmap.c | 129 ++++++++++++++++++++ > xen/arch/x86/spec_ctrl.c | 7 ++ > 5 files changed, 157 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h > index 512f8064d6..41866b77e9 100644 > --- a/xen/arch/x86/include/asm/sparse-directmap.h > +++ b/xen/arch/x86/include/asm/sparse-directmap.h > @@ -33,7 +33,15 @@ static inline bool sparse_dmap_configured(void) > return opt_sparse_dmap_pv || opt_sparse_dmap_hvm; > } > > +/* Whether a new domain of the given type is to use the sparse view. */ > +static inline bool sparse_dmap_wanted(bool pv) > +{ > + return sparse_dmap_root && (pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); > +} > + > void sparse_dmap_init(void); > +void sparse_dmap_activate(void); > +void sparse_dmap_install(l4_pgentry_t *l4t, bool pv); > int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, > pte_attr_t flags); > int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, > @@ -46,7 +54,10 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); > #define sparse_dmap_active false > > static inline bool sparse_dmap_configured(void) { return false; } > +static inline bool sparse_dmap_wanted(bool pv) { return false; } > static inline void sparse_dmap_init(void) {} > +static inline void sparse_dmap_activate(void) {} > +static inline void sparse_dmap_install(l4_pgentry_t *l4t, bool pv) {} > static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, > unsigned long nr, pte_attr_t flags) > { > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index 4a1bd9d146..4e2f9e1f12 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -1662,7 +1662,8 @@ struct page_info *perdomain_l3(const struct vcpu *v) > * share; it is mandatory for a vCPU-PT domain, whose per-domain area is > * per-vCPU. All other parameters are optional and will either fill or zero > * the appropriate slots. Pagetables not shared with guests will gain the > - * extended directmap. > + * extended directmap, unless the domain runs on the sparse view of the > + * directmap, which replaces the directmap slots (see sparse_dmap_install()). > */ > void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, > const struct domain *d, const struct vcpu *v, > @@ -1670,7 +1671,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, > { > /* > * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full > - * directmap. > + * directmap, unless the domain runs on the sparse view (below). > */ > bool short_directmap = !paging_mode_external(d); > > @@ -1743,6 +1744,10 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, > (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots - > l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); > } > + > + /* The domain's contexts may run on the sparse view of the directmap. */ > + if ( sparse_dmap_active && d->arch.sparse_dmap ) > + sparse_dmap_install(l4t, short_directmap); Instead of doing the copy of the full directmap from the idle page tables, and then rewriting, won't it be simpler if the copied directmap was the correct one right away rather than doing a fixup afterwards? > } > > bool fill_ro_mpt(mfn_t mfn) > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index e52388ad28..21edab9cea 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -2216,6 +2216,9 @@ void asmlinkage __init noreturn __start_xen(void) > if ( !dom0 ) > panic("Could not set up DOM0 guest OS\n"); > > + /* Before dom0 first runs, and after it was built on the full directmap. */ > + sparse_dmap_activate(); > + > heap_init_late(); > > init_constructors(); > diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c > index ef13f9e95d..54a6e36132 100644 > --- a/xen/arch/x86/sparse-directmap.c > +++ b/xen/arch/x86/sparse-directmap.c > @@ -46,8 +46,10 @@ > #include > #include > #include > +#include > #include > > +#include > #include > #include > > @@ -437,3 +439,130 @@ void __init sparse_dmap_init(void) > > printk(XENLOG_INFO "Sparse directmap: %lu pages mapped\n", mapped); > } > + > +/* > + * Point the directmap slots of the root page-table @l4t at the sparse view. > + * Every slot it covers gets its L3, whatever the full directmap has there, > + * so that memory added later is covered too. A PV root has guest slots > + * above; any other root loses the rest of the directmap, which the sparse > + * view does not cover. > + * > + * Directmap mappings may be global, in either hierarchy. Translations of > + * the full directmap must not remain usable on a root carrying the sparse > + * view: every CR3 write which can move a CPU from the one to the other goes > + * through switch_cr3_cr4(), which flushes what the old root left in the TLB, > + * global entries included, before it returns. The other CR3 writes, which > + * may keep global or PCID-tagged entries (_toggle_guest_pt(), XPTI's entry > + * and exit paths), switch between one vCPU's roots, which carry the same > + * directmap, or to XPTI's per-CPU root, which maps only this CPU's stack, > + * IDT and TSS there. Removals from the sparse view flush all CPUs, global > + * entries included. IMO parts of this comment are likely out of scope here. It's fine to discuss about the flushing strategy in the commit message, however doing so in a comment here, that's disconnected from the definitions of switch_cr3_cr4() and _toggle_guest_pt() seems out of place. I would also avoid referencing function names in code comments: it's fine to do so in the commit message, but it's likely those references in comments will go stale as functions change names or disappear. Commit messages are otherwise tied to a specific point in time, so the context and the referenced functions are always accurate and it will never go stale in the context is was committed. > + */ > +void sparse_dmap_install(l4_pgentry_t *l4t, bool pv) > +{ > + unsigned int i; > + > + ASSERT(sparse_dmap_root); > + > + for ( i = l4_table_offset(SPARSE_DMAP_START); > + i < l4_table_offset(SPARSE_DMAP_END); i++ ) > + l4t[i] = sparse_dmap_root[i]; > + > + if ( !pv ) > + for ( ; i < l4_table_offset(DIRECTMAP_VIRT_END); i++ ) > + l4t[i] = l4e_empty(); > +} > + > +static void __init sparse_dmap_install_mfn(mfn_t mfn, bool pv) > +{ > + l4_pgentry_t *l4t = map_domain_page(mfn); > + > + sparse_dmap_install(l4t, pv); > + unmap_domain_page(l4t); > +} > + > +/* > + * Let guest contexts run on the sparse view. Root page-tables built from > + * here on carry it (init_xen_l4_slots()); those of the domains built so far > + * (dom0, which has not run yet) are switched over here. Its construction ran > + * on the full directmap, and needed to. > + */ > +void __init sparse_dmap_activate(void) > +{ > + struct domain *d; > + struct vcpu *v; > + unsigned long va, mapped = 0; > + unsigned int i, switched = 0; > + > + if ( !sparse_dmap_root ) > + return; > + > + /* > + * Nothing in the directmap is executed: as subarch_init_memory() does > + * for the full directmap, mark the sparse view's slots NX, before any > + * root page-table takes a copy of them. > + */ > + if ( cpu_has_nx ) > + for ( i = l4_table_offset(SPARSE_DMAP_START); > + i < l4_table_offset(SPARSE_DMAP_END); i++ ) > + l4e_add_flags(sparse_dmap_root[i], _PAGE_NX_BIT); Shouldn't this be done when the sparse directmap L4 are populated, instead of here? > + > + rcu_read_lock(&domlist_read_lock); > + > + for_each_domain ( d ) > + { > + if ( !d->arch.sparse_dmap ) > + continue; You should likely ensure the domain is paused here, otherwise nothing good can came out of playing with its root page-table. > + > + /* > + * A PV domain runs on shadow L4s only in shadow mode, which boot > + * does not enter before this point: dom0=shadow enables it later, > + * from a tasklet, and the shadow L4s then get the sparse view from > + * init_xen_l4_slots(), as for any PV domain entering shadow mode. > + */ > + switched++; > + for_each_vcpu ( d, v ) > + { > + if ( is_hvm_vcpu(v) ) nit: you could pull is_hvm_vcpu() out of the loop and store in a boolean, so that you don't need to call it for each domain vCPU. > + { > + if ( !pagetable_is_null(v->arch.hvm.monitor_table) ) > + sparse_dmap_install_mfn( > + pagetable_get_mfn(v->arch.hvm.monitor_table), false); > + continue; > + } > + > + if ( !pagetable_is_null(v->arch.guest_table) ) > + sparse_dmap_install_mfn( > + pagetable_get_mfn(v->arch.guest_table), true); > + if ( !pagetable_is_null(v->arch.guest_table_user) ) > + sparse_dmap_install_mfn( > + pagetable_get_mfn(v->arch.guest_table_user), true); > + } > + } > + > + rcu_read_unlock(&domlist_read_lock); > + > + /* > + * Belt and braces: nothing runs on these page-tables yet, and PV dom0's > + * construction, which ran on its own, returned to the idle page-tables > + * through switch_cr3_cr4(), dropping what it left in the TLB. > + */ > + flush_all(FLUSH_TLB_GLOBAL); > + > + sparse_dmap_active = true; > + > + for ( va = SPARSE_DMAP_START; va < SPARSE_DMAP_END; ) > + { > + pte_attr_t flags; > + unsigned long n; > + > + if ( !mfn_eq(xen_mapping_lookup(sparse_dmap_root, va, &flags, &n), > + INVALID_MFN) ) > + mapped += n; > + va += n << PAGE_SHIFT; > + } This looks to be extremely expensive just for the purposes of printing the number of mapped pages in the sparse directmap, it should be under CONFIG_DEBUG if anything. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 09 08:16:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 08:16:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444051.1661063 (Exim 4.92) (envelope-from ) id 1xF5lY-0003V8-1H; Fri, 09 Oct 2026 08:15:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444051.1661063; Fri, 09 Oct 2026 08:15: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 1xF5lX-0003V1-Ue; Fri, 09 Oct 2026 08:15:43 +0000 Received: by outflank-mailman (input) for mailman id 1444051; Fri, 09 Oct 2026 08:15:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF5lX-0003Uv-1Z for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 08:15:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF5lW-0069AX-Eg for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 10:15:42 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8a2a9-e002-0a2a0a5209dd-0a2a450abdba-16 for ; Fri, 09 Oct 2026 10:15:42 +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 6ac8a2ae-f2d2-0a2a450a0019-c387df82a2f2-3 for ; Fri, 09 Oct 2026 10:15:42 +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 EC3CB21BCB; Fri, 9 Oct 2026 08:15:41 +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 9337C1368B; Fri, 9 Oct 2026 08:15:41 +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 FAvRGq2iyGpKDQAAD6G6ig (envelope-from ); Fri, 09 Oct 2026 08:15: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; none Authentication-Results: smtp-out1.suse.de; none Message-ID: <8054e545-149d-48cc-9e2d-5a3cd3bd662d@suse.com> Date: Fri, 9 Oct 2026 10:15:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/gntdev: Fix gntdev_dmabuf ref leak in dmabuf_exp_wait_released() To: Wentao Liang , boris.ostrovsky@oracle.com Cc: linux-kernel@vger.kernel.org, oleksandr_andrushchenko@epam.com, oleksandr_tyshchenko@epam.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, stable@vger.kernel.org References: <20260916170956.2086505-1-vulab@iscas.ac.cn> 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: <20260916170956.2086505-1-vulab@iscas.ac.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------5XtmSpn2jOOlI7yHrMJeTWOH" X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spamd-Bar: / X-Rspamd-Queue-Id: EC3CB21BCB X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [0.00 / 50.00] X-purgate-ID: tlsNG-4011c0/1791533742-4B4D7CFC-A35CEE71/0/0 X-purgate-type: clean X-purgate-size: 7055 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5XtmSpn2jOOlI7yHrMJeTWOH Content-Type: multipart/mixed; boundary="------------5DJvWL8YxTJ1TDGiVkey8XYO"; protected-headers="v1" From: Juergen Gross To: Wentao Liang , boris.ostrovsky@oracle.com Cc: linux-kernel@vger.kernel.org, oleksandr_andrushchenko@epam.com, oleksandr_tyshchenko@epam.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, stable@vger.kernel.org Message-ID: <8054e545-149d-48cc-9e2d-5a3cd3bd662d@suse.com> Subject: Re: [PATCH] xen/gntdev: Fix gntdev_dmabuf ref leak in dmabuf_exp_wait_released() References: <20260916170956.2086505-1-vulab@iscas.ac.cn> In-Reply-To: <20260916170956.2086505-1-vulab@iscas.ac.cn> --------------5DJvWL8YxTJ1TDGiVkey8XYO Content-Type: multipart/mixed; boundary="------------507C04RoOaZQOEvNpTLFrDSZ" --------------507C04RoOaZQOEvNpTLFrDSZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTYuMDkuMjYgMTk6MDksIFdlbnRhbyBMaWFuZyB3cm90ZToNCj4gZG1hYnVmX2V4cF93 YWl0X3JlbGVhc2VkKCkgdGFrZXMgYSByZWZlcmVuY2Ugb24gdGhlIGV4cG9ydGVkDQo+IGdu dGRldl9kbWFidWYgd2l0aCBkbWFidWZfZXhwX3dhaXRfb2JqX2dldF9kbWFidWYoKSBhbmQg cGFzc2VzIGl0IHRvDQo+IGRtYWJ1Zl9leHBfd2FpdF9vYmpfbmV3KCksIHdoaWNoIGRyb3Bz IHRoYXQgcmVmZXJlbmNlIGFmdGVyIGFkZGluZyB0aGUNCj4gd2FpdCBvYmplY3QgdG8gdGhl IHdhaXQgbGlzdC4gIFdoZW4gdGhlIHdhaXQgb2JqZWN0IGFsbG9jYXRpb24gZmFpbHMsDQo+ IGRtYWJ1Zl9leHBfd2FpdF9vYmpfbmV3KCkgcmV0dXJucyBFUlJfUFRSKC1FTk9NRU0pIGVh cmx5IGFuZCB0aGUNCj4gcmVmZXJlbmNlIGlzIG5ldmVyIGRyb3BwZWQsIGxlYWtpbmcgYSBy ZWZlcmVuY2UgdG8gdGhlIGV4cG9ydGVkDQo+IGdudGRldl9kbWFidWYuDQo+IA0KPiBEcm9w IHRoZSByZWZlcmVuY2Ugb24gdGhlIGFsbG9jYXRpb24gZmFpbHVyZSBwYXRoIHNvIHRoZSBy ZWZlcmVuY2UgaXMNCj4gY29uc3VtZWQgd2hldGhlciB0aGUgd2FpdCBvYmplY3QgaXMgY3Jl YXRlZCBvciBub3QuDQo+IA0KPiBGaXhlczogOTMyZDY1NjIxNzllICgieGVuL2dudGRldjog QWRkIGluaXRpYWwgc3VwcG9ydCBmb3IgZG1hLWJ1ZiBVQVBJIikNCj4gQ2M6IHN0YWJsZUB2 Z2VyLmtlcm5lbC5vcmcNCj4gU2lnbmVkLW9mZi1ieTogV2VudGFvIExpYW5nIDx2dWxhYkBp c2Nhcy5hYy5jbj4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNl LmNvbT4NCg0KDQpKdWVyZ2VuDQo= --------------507C04RoOaZQOEvNpTLFrDSZ 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----- --------------507C04RoOaZQOEvNpTLFrDSZ-- --------------5DJvWL8YxTJ1TDGiVkey8XYO-- --------------5XtmSpn2jOOlI7yHrMJeTWOH 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/Ey8FAmrIoq0FAwAAAAAACgkQsN6d1ii/Ey+q igf9G0if6s4i2ivYNbf5VuMGEvy4KfsBLLasJmNuKmY1TLEJoSWrQyqnsJ9zu5RLQgJM1QQK2U6B ATXzaYtr5VoStTT+RNEEI/q1p5yjNLMJAXRfmDNZaOI4E9XG8LCL6m6ssSzdbgjRkvxClpk7I4hi BK8XyGxw3t00NWkmbKsSt/ZBsPSlZbdg8/8pLUgLp6TT32JtJlpNZI18scIa3X9DUZ2wzAAGnu7v 6LeRyvAYWbl0xRw8LAenftphL4FbHeLC9AtIHXHZ0qc/7ww8kBeB0VWo0veYP8dH7SUIWw0PabFk aEeypY4E6F+9KGQ4XSZIImrvSu9PfBLNTAKBahsQmA== =xLsP -----END PGP SIGNATURE----- --------------5XtmSpn2jOOlI7yHrMJeTWOH-- From xen-devel-bounces@lists.xenproject.org Fri Oct 09 08:17:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 08:17:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444056.1661073 (Exim 4.92) (envelope-from ) id 1xF5nb-00040D-DP; Fri, 09 Oct 2026 08:17:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444056.1661073; Fri, 09 Oct 2026 08:17: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 1xF5nb-000405-AL; Fri, 09 Oct 2026 08:17:51 +0000 Received: by outflank-mailman (input) for mailman id 1444056; Fri, 09 Oct 2026 08:17:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF5nZ-0003zx-Tu for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 08:17:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF5nY-008213-Av for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 10:17:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8a328-8faa-0a2a0a5109dd-0a2a4505a00e-12 for ; Fri, 09 Oct 2026 10:17:48 +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 6ac8a32b-4cb1-0a2a45050019-c387df83df84-3 for ; Fri, 09 Oct 2026 10:17:48 +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 CE52F1F790; Fri, 9 Oct 2026 08:17: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 754251368B; Fri, 9 Oct 2026 08:17:47 +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 IJlUEyujyGp3DwAAD6G6ig (envelope-from ); Fri, 09 Oct 2026 08:17: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; none Authentication-Results: smtp-out2.suse.de; none Message-ID: <57604f7f-fc89-4b9d-bf54-467399436fb2@suse.com> Date: Fri, 9 Oct 2026 10:17:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf() To: Wentao Liang , Jiqian.Chen@amd.com Cc: linux-kernel@vger.kernel.org, oleksandr_tyshchenko@epam.com, ray.huang@amd.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, stable@vger.kernel.org References: <20260916171141.2086627-1-vulab@iscas.ac.cn> 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: <20260916171141.2086627-1-vulab@iscas.ac.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------PVMbtoKQccvREt1EzLZT7aiE" X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spamd-Bar: / X-Rspamd-Queue-Id: CE52F1F790 X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [0.00 / 50.00] X-purgate-ID: tlsNG-c201ff/1791533868-73ABF2A1-AE600CD6/0/0 X-purgate-type: clean X-purgate-size: 6728 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------PVMbtoKQccvREt1EzLZT7aiE Content-Type: multipart/mixed; boundary="------------7uCpS5pR8FWWGFP0rwJ19PkT"; protected-headers="v1" From: Juergen Gross To: Wentao Liang , Jiqian.Chen@amd.com Cc: linux-kernel@vger.kernel.org, oleksandr_tyshchenko@epam.com, ray.huang@amd.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, stable@vger.kernel.org Message-ID: <57604f7f-fc89-4b9d-bf54-467399436fb2@suse.com> Subject: Re: [PATCH] xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf() References: <20260916171141.2086627-1-vulab@iscas.ac.cn> In-Reply-To: <20260916171141.2086627-1-vulab@iscas.ac.cn> --------------7uCpS5pR8FWWGFP0rwJ19PkT Content-Type: multipart/mixed; boundary="------------w4z6D0h0DWAil0ycWEiPBP9K" --------------w4z6D0h0DWAil0ycWEiPBP9K Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTYuMDkuMjYgMTk6MTEsIFdlbnRhbyBMaWFuZyB3cm90ZToNCj4gcGNpc3R1Yl9nZXRf Z3NpX2Zyb21fc2JkZigpIG9idGFpbnMgdGhlIHN0dWIgZGV2aWNlIHdpdGgNCj4gcGNpc3R1 Yl9kZXZpY2VfZmluZCgpLCB3aGljaCByZXR1cm5zIGl0IHdpdGggaXRzIGtyZWYgaW5jcmVt ZW50ZWQsIGFuZA0KPiByZXR1cm5zIHBzZGV2LT5nc2kgd2l0aG91dCBkcm9wcGluZyB0aGF0 IHJlZmVyZW5jZSBhZ2Fpbi4gIFRoZSBjYWxsZXINCj4gY2Fubm90IHJlbGVhc2UgaXQgZWl0 aGVyLCBzbyBldmVyeSBsb29rdXAgbGVha3Mgb25lIHJlZmVyZW5jZSB0byB0aGUNCj4gc3R1 YiBkZXZpY2UuDQo+IA0KPiBSZWxlYXNlIHRoZSByZWZlcmVuY2UgYWZ0ZXIgcmVhZGluZyBn c2kuDQo+IA0KPiBGaXhlczogMmZhZTZiYjdiZTMyICgieGVuL3ByaXZjbWQ6IEFkZCBuZXcg c3lzY2FsbCB0byBnZXQgZ3NpIGZyb20gZGV2IikNCj4gQ2M6IHN0YWJsZUB2Z2VyLmtlcm5l bC5vcmcNCj4gU2lnbmVkLW9mZi1ieTogV2VudGFvIExpYW5nIDx2dWxhYkBpc2Nhcy5hYy5j bj4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0K DQpKdWVyZ2VuDQo= --------------w4z6D0h0DWAil0ycWEiPBP9K 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----- --------------w4z6D0h0DWAil0ycWEiPBP9K-- --------------7uCpS5pR8FWWGFP0rwJ19PkT-- --------------PVMbtoKQccvREt1EzLZT7aiE 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/Ey8FAmrIoysFAwAAAAAACgkQsN6d1ii/Ey98 2Af/YpPQ8dl3lICFTOxJwMHYlDJSemck+tgHfkkeZVguq1vOKcyyLJTsTAzOevyvSrA0qQDWAaa/ 4pyW3h15QqMhvv5sqLgwVQ1BcGKrzYP9DJSUpvrPW6rAhAhrZVWOczvTAUR0Ig9d1FJ9OEgtuHFV CpcU1KInU6Ccp0XdbpcQL9drbhzzhxa5nJBYClZBGcjWny5DNi9Fa4xBIt6IxLQUVsOkQAVe+6N9 N4sLhKkByTVc1hur6AgynWi4zlFcPrgh1haVHgq6v8G8ctDevPjaIt2NATSpKse1dHOFW4/3+njR kOQQU9mP0QRvmMmwhM7aEY+48WBX3zQrC72zWjhC8w== =KTjX -----END PGP SIGNATURE----- --------------PVMbtoKQccvREt1EzLZT7aiE-- From xen-devel-bounces@lists.xenproject.org Fri Oct 09 08:23:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 08:23:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444063.1661082 (Exim 4.92) (envelope-from ) id 1xF5tD-0005da-0A; Fri, 09 Oct 2026 08:23:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444063.1661082; Fri, 09 Oct 2026 08:23: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 1xF5tC-0005dT-TB; Fri, 09 Oct 2026 08:23:38 +0000 Received: by outflank-mailman (input) for mailman id 1444063; Fri, 09 Oct 2026 08:23:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF5tA-0005dN-St for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 08:23:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF5tA-00FCc6-6S for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 10:23:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8a47e-e002-0a2a0a5209dd-0a2a4505b01a-32 for ; Fri, 09 Oct 2026 10:23:36 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8a487-4cb1-0a2a45050019-c387df82d61a-3 for ; Fri, 09 Oct 2026 10:23:36 +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 983F021B63; Fri, 9 Oct 2026 08:23: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 375B61368B; Fri, 9 Oct 2026 08:23: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 Az2LAYekyGqwFAAAD6G6ig (envelope-from ); Fri, 09 Oct 2026 08:23: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; none Authentication-Results: smtp-out1.suse.de; none Message-ID: <90cc2e5c-8e45-46bb-8a06-d80be43cb36c@suse.com> Date: Fri, 9 Oct 2026 10:23:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/pcifront: Fix PCI device reference leak in pcifront_common_process() To: Wentao Liang , bhelgaas@google.com Cc: boris.ostrovsky@oracle.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, stable@vger.kernel.org References: <20260917132944.2153421-1-vulab@iscas.ac.cn> 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: <20260917132944.2153421-1-vulab@iscas.ac.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mMsoEsECVXshZ3a54icb6Ldr" X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spam-Flag: NO X-Spam-Level: X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spamd-Result: default: False [0.00 / 50.00] X-Spam-Score: 0.00 X-purgate-ID: tlsNG-c201ff/1791534216-F7EB92A1-D2782E59/0/0 X-purgate-type: clean X-purgate-size: 6955 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mMsoEsECVXshZ3a54icb6Ldr Content-Type: multipart/mixed; boundary="------------gXANajgOhKNMZShjzPUCU41g"; protected-headers="v1" From: Juergen Gross To: Wentao Liang , bhelgaas@google.com Cc: boris.ostrovsky@oracle.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, stable@vger.kernel.org Message-ID: <90cc2e5c-8e45-46bb-8a06-d80be43cb36c@suse.com> Subject: Re: [PATCH] xen/pcifront: Fix PCI device reference leak in pcifront_common_process() References: <20260917132944.2153421-1-vulab@iscas.ac.cn> In-Reply-To: <20260917132944.2153421-1-vulab@iscas.ac.cn> --------------gXANajgOhKNMZShjzPUCU41g Content-Type: multipart/mixed; boundary="------------LvJtMZGI3ErSL3r97uVzAYoM" --------------LvJtMZGI3ErSL3r97uVzAYoM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTcuMDkuMjYgMTU6MjksIFdlbnRhbyBMaWFuZyB3cm90ZToNCj4gcGNpZnJvbnRfY29t bW9uX3Byb2Nlc3MoKSBnZXRzIGEgcmVmZXJlbmNlIHRvIHRoZSBQQ0kgZGV2aWNlIHdpdGgN Cj4gcGNpX2dldF9kb21haW5fYnVzX2FuZF9zbG90KCkgYW5kIG9ubHkgZHJvcHMgaXQgb24g dGhlIGVhcmx5IGVycm9yDQo+IHBhdGguICBSZXR1cm5pbmcgZGlyZWN0bHkgZnJvbSB0aGUg QUVSIGhhbmRsZXIgc3dpdGNoIGluc3RlYWQgb2YNCj4gcmVjb3JkaW5nIHRoZSByZXN1bHQg YW5kIGZhbGxpbmcgdGhyb3VnaCB0byB0aGUgY29tbW9uDQo+IHBjaV9kZXZfcHV0KHBjaWRl dikgbGVha3MgdGhlIHJlZmVyZW5jZSBvbiBldmVyeSBzdWNjZXNzZnVsIGNhbGwuDQo+IA0K PiBDb2xsZWN0IHRoZSBoYW5kbGVyIHJlc3VsdCBpbiBhIHZhcmlhYmxlIGFuZCBkcm9wIHRo ZSByZWZlcmVuY2Ugb24gdGhlDQo+IHNpbmdsZSBleGl0IHBhdGggYWdhaW4uDQo+IA0KPiBG aXhlczogMzRhYjMxNmQ3Mjg3ICgieGVuL3BjaWZyb250OiBEcm9wIHBjaWZyb250X2NvbW1v bl9wcm9jZXNzKCkgdGVzdHMgb2YgcGNpZGV2LCBwZHJ2IikNCj4gQ2M6IHN0YWJsZUB2Z2Vy Lmtlcm5lbC5vcmcNCj4gU2lnbmVkLW9mZi1ieTogV2VudGFvIExpYW5nIDx2dWxhYkBpc2Nh cy5hYy5jbj4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNv bT4NCg0KDQpKdWVyZ2VuDQo= --------------LvJtMZGI3ErSL3r97uVzAYoM 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----- --------------LvJtMZGI3ErSL3r97uVzAYoM-- --------------gXANajgOhKNMZShjzPUCU41g-- --------------mMsoEsECVXshZ3a54icb6Ldr 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/Ey8FAmrIpIYFAwAAAAAACgkQsN6d1ii/Ey/m 3wgAjglIjBSKYXaGC2w43B7mNrPNirCK2TyXTOfygAaZnRdil6ktJl4XE6HZL7jVQlJJV2vg8/82 SU7YQ/qvEylJPAp8yRe1xZnZnT0LigKEqi7b5g9wbhZqHtETYDPfLQhno8QsUQ6M/GktcfQoOOau cJSoxGX11eu+6Ux9BOD2upjnIgJkMucH+Xh/t26EyCyo/FDnWXqM4cw9PDG4bZA0kFf37oWq3Hmd bIMF2tFS+UeRi7HZ3DgvcTo4Btn96ekscxNSkTD+fyZC7SehN9YbMATBS4ImXv/JzEs8lP7jI6/F bCAn2vnK3sxf+x8JziwytIKbsTqe9Hz+BA5IbGw2Pw== =gIOM -----END PGP SIGNATURE----- --------------mMsoEsECVXshZ3a54icb6Ldr-- From xen-devel-bounces@lists.xenproject.org Fri Oct 09 08:27:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 08:27:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444071.1661091 (Exim 4.92) (envelope-from ) id 1xF5wr-0006Ku-GP; Fri, 09 Oct 2026 08:27:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444071.1661091; Fri, 09 Oct 2026 08:27: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 1xF5wr-0006Kn-Dc; Fri, 09 Oct 2026 08:27:25 +0000 Received: by outflank-mailman (input) for mailman id 1444071; Fri, 09 Oct 2026 08:27:25 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF5wq-0006Kc-RV for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 08:27:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF5wq-000x0I-8M for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 10:27:24 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8a562-bab6-0a2a0a5309dd-0a2a450cdb88-8 for ; Fri, 09 Oct 2026 10:27:24 +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 6ac8a56c-f479-0a2a450c0019-c387df82d988-3 for ; Fri, 09 Oct 2026 10:27: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 DA44521C2D; Fri, 9 Oct 2026 08:27: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 932DD1326D; Fri, 9 Oct 2026 08:27: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 DiCrGmulyGpWGAAAD6G6ig (envelope-from ); Fri, 09 Oct 2026 08:27: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; none Authentication-Results: smtp-out1.suse.de; none Message-ID: <7778808e-6963-479f-9cfb-a218de0c382e@suse.com> Date: Fri, 9 Oct 2026 10:27:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH Linux v3 6/6] xen: Add new Xen pv-op pte_get_and_clear. To: Kevin Lampis , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-7-kevin.lampis@citrix.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: <20261001174749.2275245-7-kevin.lampis@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------lB0vQoboxv0a1mcmVQlSoSYq" X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spamd-Bar: / X-Rspamd-Queue-Id: DA44521C2D X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [0.00 / 50.00] X-purgate-ID: tlsNG-d25034/1791534444-028DDA5B-3C91E2AA/0/0 X-purgate-type: clean X-purgate-size: 8095 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------lB0vQoboxv0a1mcmVQlSoSYq Content-Type: multipart/mixed; boundary="------------eGjqmWZqlfy9PNPtwGZXEvuP"; protected-headers="v1" From: Juergen Gross To: Kevin Lampis , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech Message-ID: <7778808e-6963-479f-9cfb-a218de0c382e@suse.com> Subject: Re: [PATCH Linux v3 6/6] xen: Add new Xen pv-op pte_get_and_clear. References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-7-kevin.lampis@citrix.com> In-Reply-To: <20261001174749.2275245-7-kevin.lampis@citrix.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= --------------eGjqmWZqlfy9PNPtwGZXEvuP Content-Type: multipart/mixed; boundary="------------JhflpNEe5JGDrwaIqx2xOsKw" --------------JhflpNEe5JGDrwaIqx2xOsKw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMTAuMjYgMTk6NDcsIEtldmluIExhbXBpcyB3cm90ZToNCj4gSWYgWGVuIHN1cHBv cnRzIFhFTkZFQVRfbW11X3B0X3VwZGF0ZV9zd2FwIHRoZW4gZm9yIHBlcmZvcm1hbmNlIHJl YXNvbnMNCj4gY2FsbCBtbXVfdXBkYXRlIHdpdGggdGhlIG5ldyBNTVVfUFRfVVBEQVRFX1NX QVAgZmxhZyBpbnN0ZWFkIG9mDQo+IG5hdGl2ZV9wdGVwX2dldF9hbmRfY2xlYXIoKS4NCj4g DQo+IFNpZ25lZC1vZmYtYnk6IEtldmluIExhbXBpcyA8a2V2aW4ubGFtcGlzQGNpdHJpeC5j b20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoN Ckkgd2lsbCB0YWtlIHRoaXMgcGF0Y2ggd2hlbiB0aGUgWGVuIHNpZGUgaGFzIGdvbmUgaW4u DQoNCg0KSnVlcmdlbg0K --------------JhflpNEe5JGDrwaIqx2xOsKw 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----- --------------JhflpNEe5JGDrwaIqx2xOsKw-- --------------eGjqmWZqlfy9PNPtwGZXEvuP-- --------------lB0vQoboxv0a1mcmVQlSoSYq 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/Ey8FAmrIpWsFAwAAAAAACgkQsN6d1ii/Ey9h YggAg4zFe/Q1X6fqnlV/1S/g3maa+iK8veq3C58JmPQUzMH78jCcB+00SD3sbDZHoFPboP47LIJw zv6lDeFosXhWtZnlJyzZ9NVfED3KeVTAEXMLqFSi0yfmNL3Ur5T5q45xHvhvV34I7xvkfn6+Rg27 CL6WzoTxQDE17TH5pWbWuVTnT8qpHTyExh0c20DDNZ7oj4ZO2zkZUHFkIBvUh7X13+8M03WWOGJX KZ1CnzJYYmid9E2e6nESnX8gzYVOJ3/tJeAaRkGqgGRLezoHxLXX7FU8pFSADmOiw4p1/GbYf6Ql o0+1xeSNQ+bR7hF3RxLdUJ4yORBnSKFnSsLXjJ40uA== =NGl3 -----END PGP SIGNATURE----- --------------lB0vQoboxv0a1mcmVQlSoSYq-- From xen-devel-bounces@lists.xenproject.org Fri Oct 09 08:27:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 08:27:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444072.1661095 (Exim 4.92) (envelope-from ) id 1xF5wr-0006NH-N0; Fri, 09 Oct 2026 08:27:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444072.1661095; Fri, 09 Oct 2026 08:27: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 1xF5wr-0006Mt-Jl; Fri, 09 Oct 2026 08:27:25 +0000 Received: by outflank-mailman (input) for mailman id 1444072; Fri, 09 Oct 2026 08:27:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF5wq-0006Kb-VN for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 08:27:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF5wp-00FDig-MP for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 10:27:23 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8a55f-2eae-0a2a0a5409dd-0a2a4507da74-32 for ; Fri, 09 Oct 2026 10:27:23 +0200 Received: from [40.93.195.58] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8a568-b4ea-0a2a45070019-285dc33a687c-3 for ; Fri, 09 Oct 2026 10:27:22 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by BY5PR12MB4098.namprd12.prod.outlook.com (2603:10b6:a03:205::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Fri, 9 Oct 2026 08:27:17 +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.0496.015; Fri, 9 Oct 2026 08:27: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=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=qJoZASVnfHiuQTvmLP7MmEhtFMgRRCiixJAZPsEP/U+apg5A9yAH6WIZAH4t4oXYoLjrVJJlmM6vqfH0rectj0qsO1yBhpgfM+m7/6Ay1cAbXkoand3P6jhP9Okxlam7ON3o3dIlMcVSdsQoHpb5QUucMAjSPQ7GSSdBcrcFJt+ujszZoAFGuULq7C53nk8+j0qIyHeYjr2HhHg7M9e++eHi6BO74QYNVaztPSjY3TMhwSAqPTCjRIp0cG5f56goKgYLomLN1uzQw8/zVG3cj8VMIKZMqvUr3oezVOElXzbRftNx+epDfCAJq8BQijI95NkVaa+64+mLjNj2X+F5tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IBAr+FGmNVov5kwYsJG0nmjFF6lCChS+ZKjKTew6/ME=; b=CJ1wacDjI2XKO7AvkA5MkmUXeX+EjKl9zwZnAw1TjCj4dQYzC3c7iq3Z6Fe0lCbiEIl6NIcCn0dkNTj/HnVqO0CLr3DfPexdNKqrJ/9J499PTSNWMU+hk6RgmKmcqNecxXQ1raYxrfVIhYRWupNrJDDr3BHmgI1vhDPUrBkcgdtUzb86rHhUClHRHCjVf/Fz625uRym4/K0w+7hAFWfT1IoOwOHhunZtIAGDOvAK7pgGg99elnOPiYWY4ZW1MaVtJZE+yzw7+8Ckqq1SGwRiS1R8OBrZg2m+L5IRr5smtl8dMPjD6oN1+6g0NJSo6aMwwE4DH7Xie41Q2wu5T0rqmQ== 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=IBAr+FGmNVov5kwYsJG0nmjFF6lCChS+ZKjKTew6/ME=; b=LJZiEI5+y7z6ppGdDmOE0J3douVmmmWPYEm+l3BdeRjLBCc3ZX2l/OaUv2EjHxnN4QRgg0JX1qH9T3atbOYl/8O2d+yHzl1wJoxSXkfuH0qyr4/rbrOmJtv3j6hh9xu/jZZA9eVAD3UwdrIFStCSjZ+TviJssQO+c+/J+5kn+KU= 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: Fri, 09 Oct 2026 10:27:12 +0200 Message-Id: From: "Alejandro Vallejo" To: "Orzel, Michal" , Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" , "Andrew Cooper" , "Anthony PERARD" , "Jan Beulich" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size X-Mailer: aerc 0.17.0 References: <20261007124813.177940-1-michal.orzel@amd.com> <45cb2679-c79e-4d67-abaf-a4fe8e5ddc51@amd.com> <9600e1ea-d85c-4c59-abf9-bb90b1e8cd72@amd.com> In-Reply-To: <9600e1ea-d85c-4c59-abf9-bb90b1e8cd72@amd.com> X-ClientProxiedBy: MR1P264CA0212.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:56::20) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|BY5PR12MB4098:EE_ X-MS-Office365-Filtering-Correlation-Id: fc7c1690-ebb8-4821-efda-08df25df2148 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|56012099006|4143699003|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: RxTgLYuLxlj/+ghKZE8s4YwAmyCpocFQQyrsInAzi2WyV3nJheoyAYrm+Ij49sH4iOobTHZWfS1i3kHXpOmavmRY6tudsM7fHg5TfDvtwo88JzUAVBRP58mDvPhX42f0TjAtUw4l/Qqj2ywIp9SOjkk8957P7QpWQA/akdkeXdVEEMFJroHXj7adZ3dV39S6S5p1hnvcOWVeRilBdEpJ61hN7t+GYSuqJi44y/0mv3mOCsQuNQVPmPO69kLmwHBKCw7raGCclLKGUmxFGmy6uNJISuK8dGgn/7igoHmxJXo0JFyCOSNVpCsnAchJIbabIlUC42NbgGUlVSUrsZc6FNzmpcCTG5TQpNee9RXvg2zxKN17rFe1uXgHTeMlOvSm6PToyVMzvEBYTJdpT4VKFCaxhUUlc371VSD3J6KkHTky1gt5C4kvvA8NEW5xUt6X5waocHSJ8ABRGnIV4V4PoP4uAT1AoHL8Cm0n87hQdqR2+N9QcYiVlhxK6+cZgHOcGwdRzOtgN91Um01KIejc0parP75CcaB4mRNCc9farlMDmMTBZkYd+ImoZ+l37mTpuiLLi6x6tJQaIzUf3MMlDJFptm5XthfZyR3KsonEDht5u+fVrHxnc1NADD89SAKG4MR90RUA4kEyisSMVvVEkehcrYl/gJdzhcqPOQH3qmk= 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)(23010399003)(366016)(376014)(1800799024)(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?OEhvVFM5TVRZNmc5RFJCc0lFZ0pENnUzdVNLaXkwcHRzNVZVVGdsM29TYVR1?= =?utf-8?B?RDAxSERTOExHQVhOaVBKaFVMZG1CYXJ5anFLWURPbDUrcmVSWXU1NXRTS3dh?= =?utf-8?B?KzRyV2hDL0VqL2dnbTUvNDJ4VjdiMnpxekRtdG8vZk05M3BMN0RMUFIzR2lQ?= =?utf-8?B?clJseE9KZjVFT1BKWUNKaUdWdDZ1a3hIdVhhYjI0SGJBWXhPYXNPWjUyUzhS?= =?utf-8?B?NTI3KzBvdjhSUkxmbnloV25NeEoyUzBsRFdnbXRuME95bTRaN3NIVkpFeWdM?= =?utf-8?B?QVRsTkxIVE9vQ3BpcDJkNHFLUERrNUxzK0w1d0IrMDlFNDIvbk0yODNZN0Uv?= =?utf-8?B?UVhLUE1LNjljcXMyNlVuUXFib0F6d08zRHpaTnRvTHJTK0Ezc3pjV2xWenZX?= =?utf-8?B?MldSdGQxd1c1WTd1QmE3QjlxN2RIWENNQXZ5OGxmNVZEN3VFbnkyRkhrakVO?= =?utf-8?B?a0pDVjIrK1REekcyWWNNMXpwTGcyY0VpNTZUWmVBNnMzS3E1V0ZXdnU2Y2Er?= =?utf-8?B?MkRFS2s1SHRaa1JsazVQTnJTdGpCTkMyZEhGaFg0a0daT1gxWGszbFpOUUkr?= =?utf-8?B?QUREOHc4QVhmTURkUnB3NnU1WGFVQzY1NE11V2VQdmpLN05qNnNGR2FaS1or?= =?utf-8?B?MmtwVzZBc0RHMnNoaW5CSVppMXdMMktGWHBKWVFNSXpYYTh4T2ozS3FvQ2s4?= =?utf-8?B?di9hTk51bERISVlPSVUvc1FmdmdzTWhaZklmOXVpeFZIcFMyZmhEWWRFcVNU?= =?utf-8?B?aDNDM1ZmVUdGYk5jcERrakxJdWg4c1NmcTVPanFGMFRDN0hZSTJ3UTlLWWla?= =?utf-8?B?azFFV244TzFGNDU4ZDllZjBVV0U5QnQ5MkM2NXNncG0vMmVZY1lUSlhhbVFz?= =?utf-8?B?NEJueFNhWGU1QkJyWUhBSC9ETmNjSjVuT0JDeHVnMUlDNy9FZjR1ODBQSjV2?= =?utf-8?B?NFpNY0V4YjBjOVJBOXIzakszdWZ2eDlwMUJ0M0x0VWo3YWZ3QVRVTVJHa3F4?= =?utf-8?B?d2w4b0p3NCtLVFVKeWV2NFFqWGlDTUFkSDZDcXV0bEFUdGp0MU9WR1h2WGYz?= =?utf-8?B?WFJrWTEwREEzTk9JbUhHOGxxWUttVXVPM0V0eGw2NDFuZXNpVWh6QnBBcVov?= =?utf-8?B?L3I1Yjg3TDR5ZXg5c0hxODN0NWVYUUV0bE5QeTg3R2RuREh4bVZVSVB5RFFx?= =?utf-8?B?TURid0E2ak9ES1RxQXpyWFNaYjhjREtkY2NHU3pGKzRwT3J6RU9NUGYzOXJ4?= =?utf-8?B?L29RQWI5V0JDZElnL3pXeFF2NTM5bCs4Q0NZQVlrVEVBbWJqUkEvL0RUOUhJ?= =?utf-8?B?MENiQmlqN1VTQWVMWmFWdlA1Nm85MjgvNzRwWTZMVkJZZjV0QUJnL1RPb2N3?= =?utf-8?B?L2lDQjBnSUNSWWZrNW1qSWN5dmFQN0lJYy9qV3NDTjJvVlFyNFNxeVVob2hY?= =?utf-8?B?Y0N5Vml6R3FkdWxDV3NGSHNoZXpLRnRETUgySkdoSWQ2dlA0M1loaHpFUWFY?= =?utf-8?B?MVkrdXlYcEFVclk0SnNZNmd4YksrNXBMb3RUZTh6N0Rlb0MwajlsVUh4dnhp?= =?utf-8?B?Q1VVTENFc0lLeU9nRlRjQXBnYkpkTWE5eU5QMFRtTEl2cXl1M3pNcmJlVGdI?= =?utf-8?B?VTBYMDVYaUxEV1oybjRaZnZ5b1JxSTJtZkNvUnRsT3ErbkRKZkE3MVd5OGRp?= =?utf-8?B?MEUyNG5PNmg3aXpremxVVkorYitEN3ErWGkvZ0pacldnN05zMWRSV2lLMG5j?= =?utf-8?B?bm4zZ1ZpYUxyREk5V25Ca3lVMnF3S2JJZkcvemJhdGRjaE5PWHVTb0NTSlFt?= =?utf-8?B?OE5RU29FbzMvd09memxHdE0rMWpkMndXclhsT1JiQndidVl1NFkrOXpFWGJy?= =?utf-8?B?NTVXd3BVQjRIamFVYWVpRU5CZ2VsTlgxKzcvSUlWRWhmQlp6SmI0MlJrYkFp?= =?utf-8?B?SCtISURybnJKaDZDM2VxRlJqWUlUUE5zbm5qMXIxdXcybnozMENjczBxeG5x?= =?utf-8?B?YVptcXk4Z0pKR2kwRW1KeEkrNUtQemNlNHNtSFN4cXJuVWFqay9FYzl5Q3FQ?= =?utf-8?B?N2czZlkvdjhWOFFnSW9hZHR0azJMRDdJT2NjbjF0TnRxZXNCQ1BzZDVpQjEz?= =?utf-8?B?dTBRcTVZQm1NYnZDNEFQWmYrOVVuUmlyaUgxZllRSy9QeHE0cFA1SlRPdDVD?= =?utf-8?B?VmpQOFl1c3FpUFo1dksxOFByOEFuMmoyT2VCeEczNkV6UWtIbWs5NldpUjNm?= =?utf-8?B?clAxL3JGSkhXSTVCQWkyYVdjcFdxMkdieU5zUDRmd2tPa0lrWXM4VmVUY2Rh?= =?utf-8?B?dFpQN2w0RCtNd0tRQWtEbDFxcUE1MjNRRkVxT1RENWZGcjhaWnNYUT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc7c1690-ebb8-4821-efda-08df25df2148 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 08:27:17.7485 (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: QGMKS18vl9gEUi1fZcOu5ZNBEl1C8KrjfVECiKL+ISwA3+kn+aw96tTIfVB2aP0cXK0AgczYe2Mr48iLWs6iCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4098 X-purgate-ID: tlsNG-ef75cf/1791534443-36AD8AE4-842907B9/0/0 X-purgate-type: clean X-purgate-size: 3770 On Wed Oct 7, 2026 at 4:31 PM CEST, Orzel, Michal wrote: > > > On 07-Oct-26 16:21, Alejandro Vallejo wrote: > > On Wed Oct 7, 2026 at 4:11 PM CEST, Orzel, Michal wrote: > >> > >> > >> On 07-Oct-26 15:40, Alejandro Vallejo wrote: > >>> On Wed Oct 7, 2026 at 2:48 PM CEST, Michal Orzel wrote: > >>>> We require memory to allocate for a domain as RAM to be a multiple o= f a > >>>> page size. However, we neither document this nor sanity test. Specif= ying > >>>> memory size that does not conform to this requirement fails the doma= in > >>>> memory allocation in the non-obvious way that is difficult to parse = for > >>>> the user (printing over-allocation messages followed by the panic th= at Xen > >>>> could not allocate the requested amount of memory). > >>>> > >>>> While there, fix indentation from tabs to spaces for "memory" parame= ter in > >>>> booting.txt. > >>>> > >>>> Signed-off-by: Michal Orzel > >>>> --- > >>>> docs/misc/arm/device-tree/booting.txt | 4 ++-- > >>>> docs/misc/xen-command-line.pandoc | 5 +++-- > >>>> xen/arch/arm/domain_build.c | 6 ++++++ > >>>> xen/common/device-tree/dom0less-build.c | 7 +++++++ > >>>> 4 files changed, 18 insertions(+), 4 deletions(-) > >>>> > >>>> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/d= evice-tree/booting.txt > >>>> index bcb06bc796bf..7dfac2062a37 100644 > >>>> --- a/docs/misc/arm/device-tree/booting.txt > >>>> +++ b/docs/misc/arm/device-tree/booting.txt > >>>> @@ -155,8 +155,8 @@ with the following properties: > >>>> =20 > >>>> - memory > >>>> =20 > >>>> - A 64-bit integer specifying the amount of kilobytes of RAM to > >>>> - allocate to the guest. > >>>> + A 64-bit integer specifying the amount of kilobytes of RAM to > >>>> + allocate to the guest. Must be a multiple of 4KB (the page size= ). > >>> > >>> nit: s/KB/KiB > >> Is it? I don't think it matters at all seeing the number of occurrence= s in the code. > >> > >>> > >>> But page size isn't always 4KiB on all ports. PowerPC has 64KiB pages= . > >>> IMO, 4KB shouldn't be here or elsewhere in documentation. > >> This is Arm doc and on Arm we only support 4KB at the moment. User sho= uld not > >> need to dig into the code to check what is the page size. It's better = imo to > >> give this information right away and change in the future when we add = support > >> for 16 and 64KB pages on Arm. > >=20 > > This is already the only reference the other ports have for dom0less. > > The document shouldn't be here since the movement of dom0less to common > > code, but the side effect of it is that this no longer an arm-only refe= rence. > >=20 > > I won't be annoying about moving the doc on this patch because that's a > > separate matter, but not adding more easily avoidable debt seems > > warranted. > I don't quite understand your reasoning. If you worry about dom0less !=3D= Arm, > then on that basis HAS_DOM0LESS is selected only for Arm and RISCV where > PAGE_SIZE is 4KB. I don't think I'm introducing any doubt here. I can rem= ove the > 4KB mentioning from the docs if you really insist but at least for me it'= s > clearer for the user to know right away what's the requirement for the si= ze. It's a small adjustment to make the documentation truly generic. And prevents the pgsz =3D=3D 4KiB assumption from spreading further. Many docs are spawned from copying other docs. If you're so strongly against, that's fine; it's not incorrect today. I still think the 4K should be gone, but if don't want to block the patch on such silly things. Reviewed-by: Alejandro Vallejo Cheers, Alejandro > > ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 09 08:53:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 08:53:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444096.1661114 (Exim 4.92) (envelope-from ) id 1xF6Ld-0002Ui-Ti; Fri, 09 Oct 2026 08:53:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444096.1661114; Fri, 09 Oct 2026 08:53: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 1xF6Ld-0002TO-NY; Fri, 09 Oct 2026 08:53:01 +0000 Received: by outflank-mailman (input) for mailman id 1444096; Fri, 09 Oct 2026 08:53:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF6Lc-0002RJ-LR; Fri, 09 Oct 2026 08:53:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF6Lb-0020KT-Ny; Fri, 09 Oct 2026 10:52:59 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8ab68-8faa-0a2a0a5109dd-0a2a45078778-18 for ; Fri, 09 Oct 2026 10:52:59 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8ab6a-b4ea-0a2a45070019-6882d725ae08-3 for ; Fri, 09 Oct 2026 10:52:59 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xF6LU-004j7d-2d; Fri, 09 Oct 2026 08:52:52 +0000 Received: from julieng by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1xF6LU-001PzP-2R; Fri, 09 Oct 2026 08:52: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; 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 522 v1 (CVE-2026-98375) - Linux xen-netfront: backend can crash guest via malformed RX packets Message-Id: Date: Fri, 09 Oct 2026 08:52:52 +0000 X-purgate-ID: tlsNG-ef75cf/1791535979-378D1AE4-126C4B0D/0/0 X-purgate-type: clean X-purgate-size: 5448 --=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-98375 / XSA-522 Linux xen-netfront: backend can crash guest via malformed RX packets ISSUE DESCRIPTION ================= If a RX packet sent from the networking backend to the Linux xen-netfront driver is split into multiple slots and the first slot is shorter than an Ethernet header, a BUG() will crash the guest. This is a backend induced Denial of Service (DoS). IMPACT ====== A malicious network backend can cause a DoS affecting the entire guest it is serving. VULNERABLE SYSTEMS ================== All Linux guests being served by a potentially untrusted network backend (i.e. a network backend in a driver domain) are affected. Linux guests with a kernel from 2.6.23 onwards are affected. MITIGATION ========== Using a trusted network backend will avoid the issue in the guests. CREDITS ======= This issue was discovered by Josef Bacik of Anthropic. RESOLUTION ========== Applying the attached patch resolves this issue. xsa522-linux.patch Linux $ sha256sum xsa522* 5bd78edbf9f039b6e12e725c883a44485fd60e7e8e06c493d57bb2ecfeccbb6e xsa522-linux.patch $ NOTE REGARDING LACK OF EMBARGO ============================== This issue was disclosed in public. -----BEGIN PGP SIGNATURE----- iQFcBAEBCABGFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrIqswbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzDBxwZ3BAeGVuLm9yZwAKCRCD/hTJV+gr2Z0aB/4x lyvVclfKLPKO7TezBS0Du+ee3t8PbwMfWe7Gw3rMOkaytQs+XbBZrZ/lF9uNgSyu a+bwaALjNvTuBJiU2Hq6w6qSMjrDb4Kfn1vRe+iw/MXj5K1q8J6NzXP/rZGkIPCl E1NyC8RPiRzva/X3CgfO59nsHNxmVxy5cFowP4oxGjp/sAqTLR4JMbK9tALa50Hz 5dc+CUC7i9YlbVgcn1KatORknlSBBqvefRM/zF/uLtGi5YCmVWVc7QlHF5BCBgio Gu5zjEqA+De5/Rg0o5gHH3Jh6xWTtfThoZewROQgu+P9QYUmHZpGKfCkYazTddzi Ns9Hz1obvGY4JuCanYvF =QR/D -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa522-linux.patch" Content-Disposition: attachment; filename="xsa522-linux.patch" Content-Transfer-Encoding: base64 RnJvbSBjODQzZGRhMTg3YmQ0NGExMmQ4YTJiMWI1NmFlYmZjN2Y2NzFiODIw IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKb3NlZiBCYWNpayA8 am9zZWZAdG94aWNwYW5kYS5jb20+CkRhdGU6IFdlZCwgNyBPY3QgMjAyNiAx Nzo1NTo0MCArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIHhlbi9uZXRmcm9udDog ZHJvcCBSWCBwYWNrZXRzIHdpdGggYSBzaG9ydCBFdGhlcm5ldCBoZWFkZXIK CmhhbmRsZV9pbmNvbWluZ19xdWV1ZSgpIHB1bGxzIHB1bGxfdG8gYnl0ZXMg aW50byB0aGUgaGVhZCBiZWZvcmUKY2FsbGluZyBldGhfdHlwZV90cmFucygp LiAgcHVsbF90byBpcyB0aGUgbGVuZ3RoIG9mIHRoZSBmaXJzdCBSWCBzbG90 LApjYXBwZWQgYXQgUlhfQ09QWV9USFJFU0hPTEQsIGFuZCB0aGF0IGxlbmd0 aCBjb21lcyBmcm9tIHRoZSBiYWNrZW5kLgpOb3RoaW5nIGNoZWNrcyBpdCBh Z2FpbnN0IEVUSF9ITEVOLgoKSWYgdGhlIGZpcnN0IHNsb3QgaXMgc2hvcnRl ciB0aGFuIEVUSF9ITEVOIGFuZCBtb3JlIHNsb3RzIGZvbGxvdywgdGhlCmhl YWQgZW5kcyB1cCBzaG9ydGVyIHRoYW4gYW4gRXRoZXJuZXQgaGVhZGVyIHdo aWxlIHNrYi0+bGVuIGlzIGxvbmdlciwKYW5kIGV0aF90eXBlX3RyYW5zKCkg QlVHKClzIGluIF9fc2tiX3B1bGwoKS4gIElmIHRoZSB3aG9sZSBwYWNrZXQg aXMKc2hvcnRlciB0aGFuIEVUSF9ITEVOLCBldGhfdHlwZV90cmFucygpIHJl YWRzIHRoZSBoZWFkZXIgcGFzdCB0aGUgZW5kCm9mIHRoZSBkYXRhIGluc3Rl YWQuCgpQdWxsIGF0IGxlYXN0IEVUSF9ITEVOLCBhbmQgZHJvcCB0aGUgcGFj a2V0IGlmIHRoYXQgZmFpbHMsIHdoaWNoIGFsc28KZHJvcHMgcGFja2V0cyB0 b28gc2hvcnQgdG8gaG9sZCBhbiBFdGhlcm5ldCBoZWFkZXIuICBUaGlzIGFs c28gY2hlY2tzCnRoZSByZXR1cm4gdmFsdWUgb2YgdGhlIHB1bGwsIHdoaWNo IHdhcyBpZ25vcmVkLgoKVGhpcyBpcyBYU0EtNTIyIC8gQ1ZFLTIwMjYtOTgz NzUKCkZpeGVzOiAwZDE2MDIxMTk2NWIgKCJ4ZW46IGFkZCB2aXJ0dWFsIG5l dHdvcmsgZGV2aWNlIGRyaXZlciIpCkNjOiBzdGFibGVAdmdlci5rZXJuZWwu b3JnCkFzc2lzdGVkLWJ5OiBMTE0KU2lnbmVkLW9mZi1ieTogSm9zZWYgQmFj aWsgPGpvc2VmQHRveGljcGFuZGEuY29tPgpNZXNzYWdlLUlEOiA8MjAyNjEw MDctYjQteGVuLW5ldGZyb250LXNob3J0LWhlYWQtdjEtMS0xMmQ3MTEzYTdl NGVAdG94aWNwYW5kYS5jb20+ClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3Nz IDxqZ3Jvc3NAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jv c3MgPGpncm9zc0BzdXNlLmNvbT4KLS0tCiBkcml2ZXJzL25ldC94ZW4tbmV0 ZnJvbnQuYyB8IDEyICsrKysrKysrKystLQogMSBmaWxlIGNoYW5nZWQsIDEw IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv ZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmMgYi9kcml2ZXJzL25ldC94ZW4t bmV0ZnJvbnQuYwppbmRleCAyZWQ2NzM2NDljNDguLmQyNjk0NTdlODM5ZSAx MDA2NDQKLS0tIGEvZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmMKKysrIGIv ZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmMKQEAgLTEyMzQsOCArMTIzNCwx NiBAQCBzdGF0aWMgaW50IGhhbmRsZV9pbmNvbWluZ19xdWV1ZShzdHJ1Y3Qg bmV0ZnJvbnRfcXVldWUgKnF1ZXVlLAogCXdoaWxlICgoc2tiID0gX19za2Jf ZGVxdWV1ZShyeHEpKSAhPSBOVUxMKSB7CiAJCWludCBwdWxsX3RvID0gTkVU RlJPTlRfU0tCX0NCKHNrYiktPnB1bGxfdG87CiAKLQkJaWYgKHB1bGxfdG8g PiBza2JfaGVhZGxlbihza2IpKQotCQkJX19wc2tiX3B1bGxfdGFpbChza2Is IHB1bGxfdG8gLSBza2JfaGVhZGxlbihza2IpKTsKKwkJLyogcHVsbF90byBj b21lcyBmcm9tIHRoZSBmaXJzdCBzbG90J3MgbGVuZ3RoLCB3aGljaCB0aGUK KwkJICogYmFja2VuZCBjb250cm9scy4gIE1ha2Ugc3VyZSB0aGUgaGVhZCBo b2xkcyBhdCBsZWFzdCBhbgorCQkgKiBFdGhlcm5ldCBoZWFkZXIgZm9yIGV0 aF90eXBlX3RyYW5zKCkuCisJCSAqLworCQlpZiAoIXBza2JfbWF5X3B1bGwo c2tiLCBtYXgocHVsbF90bywgRVRIX0hMRU4pKSkgeworCQkJa2ZyZWVfc2ti KHNrYik7CisJCQlwYWNrZXRzX2Ryb3BwZWQrKzsKKwkJCXF1ZXVlLT5pbmZv LT5uZXRkZXYtPnN0YXRzLnJ4X2Vycm9ycysrOworCQkJY29udGludWU7CisJ CX0KIAogCQkvKiBFdGhlcm5ldCB3b3JrOiBEZWxheWVkIHRvIGhlcmUgYXMg aXQgcGVla3MgdGhlIGhlYWRlci4gKi8KIAkJc2tiLT5wcm90b2NvbCA9IGV0 aF90eXBlX3RyYW5zKHNrYiwgcXVldWUtPmluZm8tPm5ldGRldik7Ci0tIAoy LjU1LjAKCg== --=separator-- From xen-devel-bounces@lists.xenproject.org Fri Oct 09 09:43:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 09:43:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444181.1661156 (Exim 4.92) (envelope-from ) id 1xF78Z-0002In-3H; Fri, 09 Oct 2026 09:43:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444181.1661156; Fri, 09 Oct 2026 09: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 1xF78Z-0002Ig-03; Fri, 09 Oct 2026 09:43:35 +0000 Received: by outflank-mailman (input) for mailman id 1444181; Fri, 09 Oct 2026 09:43:33 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xF78X-0002Ia-Be for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 09:43:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF78W-001BU3-9c for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 11:43:32 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8b73d-bab6-0a2a0a5309dd-0a2a450bb406-28 for ; Fri, 09 Oct 2026 11:43: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 6ac8b744-b7e8-0a2a450b0019-d155dd2fbd91-3 for ; Fri, 09 Oct 2026 11:43:32 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-486e8faff03so2113356f8f.1 for ; Fri, 09 Oct 2026 02:43:32 -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-48db9acfa28sm3043407f8f.51.2026.10.09.02.43.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 02:43: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=1791539012; x=1792143812; 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=QkYQAmoOaC2itQPGRrtVr/J2+wfI4WHHCUFX5ylxF7I=; b=IgjSus313JlGXnm/mzMKz5L1QhBVc5HfXP4aZuhh1dzOEaXJwBJqnDO/k0oYB0DdT7 8hQdVm1dHiksQVyfnZIvTcQbuv6Iw7sdvXcHaXlFEmar6MVLY/yXijZ9VLCv5tgAaXyN nEVFUjhmOwA1faTYpX+/NroectaSeVb+seMjZH/VWSZFLvjpKs/SkJ9q2TrGAXGPxWOD IaPYKZHqIu5a9z2qN71PKcyClv82F34+/5MwueXInjTOeBPJrMpA7PP7nLKCs21OvYkM /kNA5IC66qozGdgYR4GXvmjoEgEvaNMvgl2Cq3VKrLX3f/n+CXhkkvfuID3OCiuU3zzm nfcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791539012; x=1792143812; 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=QkYQAmoOaC2itQPGRrtVr/J2+wfI4WHHCUFX5ylxF7I=; b=AbgsdPUp5SM7sugrQM7ORslpXMPZ/No8EWBhAJ9bo6pt03lbVqlfg5oJGS8l8EWu4j fN8eWPmR5sQL5zxmLMtfIam8UCYW1afUCZq2NuH3OokNjhY/BIFy1kQFzfLNDxS5Jgyi ReHm2l8rqUyB1LrxF4xXHIdjSRLq0EMEii2zNAzFRiFGXG/Jf/weR7ootB+0J74OvgqA R4IEopG99JGE09/lTKMRrDWC2e7jGsIIOItJj6M7denp8dPMoJ1goeIRSlnMySCG0PKG ef8iMII8SB2WeC5z+Ai++2IhuOk5jqpYl62JYtGAZwarz4lCRPqgg7QfRxVOnmxa2Vi4 kkJw== X-Forwarded-Encrypted: i=1; AKwUvBxzXvbtZs7y8P5mvMTBVutTV9+OGC5bAqeTg6lD+V0T0Hc4DWM20ceWp2cuWFLevLn4F+hejI+UaD4=@lists.xenproject.org X-Gm-Message-State: AFuF++kHIsWx3ITBII/bG1q2mXeYp5CxmKglJlUB1L3s6Bxz5G8l6ac1 490VzyAqiZ+/F6xtVH5Z8mYadEg3nGRPLYTuOidWG9fs2+vZ/9QzRa7p X-Gm-Gg: AYBFou3rfUk3y+xRDAJ5Ip68tkleYhdSt2Nq/08VzmVgjSHEJxGtfglBwXLaUU0nxXE Aozvc0Fxe2eDr28bVnAHOKqNywn6n69Yx0W/lvnJpvyfrHbUYtl4COyyX6scCAs6dcpuHE44QLe BnRkagnEABxYAlEX7/Cd65mnROgPQRsG6w80rGvIPjprrfXcK1NRImDBzq7uycmqwGk8bSlmq0r PGP3DF8OwFsiY2FZVh6PZbk9I6Ws5qi2SYWDzkmwdmyxNxlQeW/tIEmIpa2LZ3aL6oZXc+uQ30n 9HboV7gXrBAWjFvYVRp03XR+McYArnt7conZ9X6xRnLsoFsgyVyjjXnH5Fs4YnpKP9nQLvrHp4h CMroMHlGhtcS8gIjnORTfxQfY0Zb6DK1EOy+bjzZcsavy9T4SigQQ6CVYXLBD5KBlc81BPWxtbA ssufedkwLd8FtYg6hhpk7al7KGjBS2npyPiOowjP1UlnRRvpoTdgCEOL7c0k10q9+Eet2S+cD0H H3I93POzwZJMnhM0aZP6OvZjByukop25jmc/zzKat6G3Y8AQQ== X-Received: by 2002:a05:600c:3146:b0:49d:1fd8:b874 with SMTP id 5b1f17b1804b1-4a18e4af3a8mr25219235e9.19.1791539011531; Fri, 09 Oct 2026 02:43:31 -0700 (PDT) Message-ID: <80c6fcbd-f411-4869-a71f-5be8e2d62b82@gmail.com> Date: Fri, 9 Oct 2026 11:43:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/device-tree: move discard_initial_modules() to common code To: "Orzel, Michal" , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261001111630.112472-1-oleksii.kurochko@gmail.com> <20261001111630.112472-3-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-42698a/1791539012-1B2DC9EA-59850B9B/10/73395122804 X-purgate-type: spam X-purgate-size: 3910 On 10/8/26 1:19 PM, Orzel, Michal wrote: > > > On 01-Oct-26 13:16, Oleksii Kurochko wrote: >> Everything discard_initial_modules() touches is already common code: >> bootinfo.modules, using_static_heap and fw_unreserved_regions(). Move it >> out of Arm into common/device-tree/bootinfo.c, next to the boot allocator >> handling of the same memory, and declare it in xen/bootinfo.h, so that >> other device-tree based architectures can reuse it instead of growing a >> copy of their own. >> >> The arch-specific remove_early_mappings() is not moved along with it: >> how the early FDT mapping is torn down is up to the architecture. As the >> DTB is one of the boot modules being released, the mapping has to go once >> they are discarded, so call it from start_xen() right after >> discard_initial_modules(), which keeps the common function free of any >> arch dependency. >> >> While moving it, use unsigned int for the loop counter and replace the >> "goto out" by a plain return, as there is nothing left to do at the label. >> >> No functional change. >> >> Signed-off-by: Oleksii Kurochko >> --- >> xen/arch/arm/include/asm/setup.h | 2 -- >> xen/arch/arm/setup.c | 35 ++----------------------------- >> xen/common/device-tree/bootinfo.c | 30 ++++++++++++++++++++++++++ >> xen/include/xen/bootinfo.h | 8 +++++++ >> 4 files changed, 40 insertions(+), 35 deletions(-) >> >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h >> index c491c567298f..02fdf2b56c9c 100644 >> --- a/xen/arch/arm/include/asm/setup.h >> +++ b/xen/arch/arm/include/asm/setup.h >> @@ -40,8 +40,6 @@ int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]); >> >> void create_dom0(void); >> >> -void discard_initial_modules(void); >> - >> void init_pdx(void); >> void setup_mm(void); >> >> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c >> index 16f899dff57b..a65c3d2a655e 100644 >> --- a/xen/arch/arm/setup.c >> +++ b/xen/arch/arm/setup.c >> @@ -210,39 +210,6 @@ static void __init processor_id(void) >> processor_setup(); >> } >> >> -void __init discard_initial_modules(void) >> -{ >> - struct boot_modules *mi = &bootinfo.modules; >> - int i; >> - >> - /* >> - * When using static heap feature, don't give boot_modules memory back to >> - * the heap allocator >> - */ >> - if ( using_static_heap ) >> - goto out; >> - >> - for ( i = 0; i < mi->nr_mods; i++ ) >> - { >> - paddr_t s = mi->module[i].start; >> - paddr_t e = s + PAGE_ALIGN(mi->module[i].size); >> - >> - if ( mi->module[i].kind == BOOTMOD_XEN ) >> - continue; >> - >> - if ( !mfn_valid(maddr_to_mfn(s)) || >> - !mfn_valid(maddr_to_mfn(e)) ) >> - continue; >> - >> - fw_unreserved_regions(s, e, init_domheap_pages, 0); >> - } >> - >> - mi->nr_mods = 0; >> - >> - out: >> - remove_early_mappings(); >> -} >> - >> /* Relocate the FDT in Xen heap */ >> static void __init relocate_fdt(const void **dtb_vaddr, size_t dtb_size) >> { >> @@ -509,6 +476,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) >> */ >> discard_initial_modules(); > The comment above is now duplicated with the one you added in xen/bootinfo.h. > I'd drop it from here (can be done on commit). I will drop it in v2 (if it won't merged at the moment when I will start address the comments for this patch series). > > Other than that: > Reviewed-by: Michal Orzel Thanks! > > NIT for the future: if you send a series of patches, please move the fixes/code > movement changes at the beginning of the series. > I will take into account that in the future. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 09 10:58:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 10:58:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444239.1661182 (Exim 4.92) (envelope-from ) id 1xF8Iv-0004wl-BX; Fri, 09 Oct 2026 10:58:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444239.1661182; Fri, 09 Oct 2026 10:58: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 1xF8Iv-0004we-8K; Fri, 09 Oct 2026 10:58:21 +0000 Received: by outflank-mailman (input) for mailman id 1444239; Fri, 09 Oct 2026 10:58:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xF8It-0004wG-Vn for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 10:58:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF8Is-002Mst-U8 for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 12:58:18 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8c8c0-bab6-0a2a0a5309dd-0a2a4502dbdc-46 for ; Fri, 09 Oct 2026 12:58:18 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8c8ca-6ca4-0a2a45020019-d155dd35ec6c-3 for ; Fri, 09 Oct 2026 12:58:18 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48c6f764f82so1459050f8f.0 for ; Fri, 09 Oct 2026 03:58: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 ffacd0b85a97d-48db94e2d8fsm3457470f8f.19.2026.10.09.03.58.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 03: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=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=1791543498; x=1792148298; 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=cD4D5yQJqIgnvtSJaG+Q546Ka2q0dabYKIwILrlQm/o=; b=jtHMW1CnzKVcoI/DEpUq4wa3HAe7t3La5D3OlShtb7mzYwHXkjSYEcBWjD2VM3lmWX C+ggFZdvMcURyxg9yE7Dur1wPg4GJLQAGI/HOty+BQaKxwbLTXEX1E+NqOPooTUhqdfq vfywDzopUWPUklVFqykNJf141NsnT1QDaaWRjN7SyjUBv2Xct3Qw29c5KzotBTNGIoBG +VcckAkwmo8hiiZibTRAOMQnPj/FKlCoL3XTk+/5BW9M3ahUaOF90oEvwRnN+JGlvURD UNt3qCeAQmGl58E79+8L4/xW5QuzBNiXkUB4GynfWDOY8cx8p+emMZKvAVn21/aAH8co cg9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791543498; x=1792148298; 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=cD4D5yQJqIgnvtSJaG+Q546Ka2q0dabYKIwILrlQm/o=; b=uriKin1zPdAY0iCsl9qmz5B6N04WfugWJunBWOWzAgxbRGl6XiUZcUYikZf5RVSW9R hplq47TUi7K5pOs8i8YjIxjWvWZ3xqbGBAXLvOyvJna7cf62EWuo8+hjpliTzXRjDnkW fNutEgmLZNbYLW37xyfXGpapxFyB1YNArazEykKZNLSgssy4BE9Gg2uqSk51viDwm6ip F06yuOtzDX8MvqdMjCGTzdHeEQItmqOvxda6QzIAOZxSl+CoMcbc/yhX0HimsjxBMRfd rPXaQ//Uk+PhsHyipiUYkxQW6Y+fMJYAb9OxkUpImVSlw/fJK+tppWyBTR97f+Vhu8Pa cUag== X-Forwarded-Encrypted: i=1; AKwUvBwBVFKCRZFfD3aIt+Sf0yWJJz6TZree4G1gxlIESM84n0ry/IxpFSg0s/Wl4QFt1ubOA8jcKx0Pag0=@lists.xenproject.org X-Gm-Message-State: AFq9FYKwXRHqFdf1Od2LWTkq/o51iowjhqqDo4fC+8dbbol7Z86Zlm+U yAoLjd3QnM4X5ft+eiHIP0GMxSomrmjOin+jg5ovtZCCmUJ4sH3dfvgX X-Gm-Gg: AYBFou3Q+bQ9Hj+QitWgMs4+SO08e6+KWfvGG/NBC0tDu5+InybHvJN3Z1Qy+U8+9rU RkmvMJGZIk6Jb8Ei2gUHpuEdZv7U8cOr8r0HeyiIh+kxubMklPRLCD/NmQmJyi1qcMv+qGcW99d iPCc0SodtQpvWpxNhsT6+phUwz7Kxbdujk6Wy/sFc6s3W4uSCLjjZhFJWVZgEUJftIE5x1SJTKw jZFYGYiyiT+9+mKWyIw9T4uGyZPu4Dm/hhb+IJjdNaRhhtXq0mEqbrlhuswWZ9+Qi6DrpyzdGGv sZ2tzbFE1nb+5Wh+WoKV2Y0tIXiQFWYTFSC2H+dQRz80kmmhY6HUanv9yziAcORdRVJJutf8GSk jntN9JMRl+pSMiCG7XsVw22R5WpvqmqeaDpyH7ZFH60txvP10zb0B/JgavYpQQvWzpA4OLMLyE1 HHUF6sGIM2PcrtcimpWtJQYTyyvvVrTv86E9EI3HiP9hWklDd3soF4B6C9AzN0YsPFs3u9kFF1N +oRSEDS3wcNeMKydnLoVMmPOF/DuCna/WtxzXFCVNm46nP8dQ== X-Received: by 2002:a05:6000:4213:b0:487:1ac0:32af with SMTP id ffacd0b85a97d-48dbaceb5c7mr3201148f8f.51.1791543498116; Fri, 09 Oct 2026 03:58:18 -0700 (PDT) Message-ID: <2dcf7454-9eee-40a9-8a6a-eec0c8e5a696@gmail.com> Date: Fri, 9 Oct 2026 12:58:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/device-tree: add a helper to dump an FDT in DTS-like format To: "Orzel, Michal" , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis References: <20261001111630.112472-1-oleksii.kurochko@gmail.com> <20261001111630.112472-2-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-720697/1791543498-664B62AC-4F6A6E9E/10/73395122804 X-purgate-type: spam X-purgate-size: 6585 On 10/8/26 1:57 PM, Orzel, Michal wrote: > > > On 01-Oct-26 13:16, Oleksii Kurochko wrote: >> The device tree Xen builds for a dom0less domain is only ever consumed >> by the guest, so a mistake in it surfaces as an obscure failure inside >> the domain, far away from the code which produced the tree. >> >> Add device_tree_dump(). The output follows dtc's format so that a dump >> can be diffed against the source DTS or fed back to dtc; the value >> formatting heuristics are ported from dtc's utilfdt_print_data() for >> that reason. The walk itself goes through libfdt rather than decoding >> the tag stream by hand as dtc's fdtdump does. >> >> Dumping a whole tree is only useful while debugging and costs both code >> size and a lot of console output, hence CONFIG_DEVICE_TREE_DEBUG. Mention >> the dump in the help text of the option. > We should also dump the DTB for dom0/hwdom in prepare_dtb_hwdom(). Please add > that to this patch. It makes sense to me. I will add it. > >> >> Signed-off-by: Oleksii Kurochko >> --- >> xen/Kconfig.debug | 3 +- >> xen/common/device-tree/Makefile | 1 + >> xen/common/device-tree/dom0less-build.c | 4 + >> xen/common/device-tree/fdt-dump.c | 180 ++++++++++++++++++++++++ >> xen/include/xen/bootfdt.h | 13 ++ >> 5 files changed, 200 insertions(+), 1 deletion(-) >> create mode 100644 xen/common/device-tree/fdt-dump.c >> >> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug >> index d900d926c555..664f50bf8a96 100644 >> --- a/xen/Kconfig.debug >> +++ b/xen/Kconfig.debug >> @@ -95,7 +95,8 @@ config DEVICE_TREE_DEBUG >> depends on DEVICE_TREE_PARSE >> help >> Device tree parsing and DOM0 device tree building messages are >> - logged in the Xen ring buffer. >> + logged in the Xen ring buffer. The device tree generated for each >> + dom0less domU is dumped there as well, in a DTS-like format. > I think we could have a separate option DEVICE_TREE_DUMP that depends on > DEVICE_TREE_PARSE. Sometimes all we need is just to see how the generated DTB > look like without seeing thousands of other DT debug messages. Especially that > nothing in fdt-dump.c depends on DEVICE_TREE_DEBUG. Agree, it will be better to have DEVICE_TREE_DUMP. I will introduce the following config: config DEVICE_TREE_DUMP bool "Dump generated device trees" depends on DEVICE_TREE_PARSE help The device tree Xen generates for dom0/hwdom and for each om0less domain is printed on the Xen console in a DTS-like format. The dump is logged at debug level, so on a non-debug build it is only shown with "loglvl=all". If unsure, say N here. > >> If unsure, say N here. >> >> config SCRUB_DEBUG >> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile >> index 9036e455d66a..959dd2a9fd30 100644 >> --- a/xen/common/device-tree/Makefile >> +++ b/xen/common/device-tree/Makefile >> @@ -6,6 +6,7 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o >> obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o >> obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-bindings.init.o >> obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o >> +obj-$(CONFIG_DEVICE_TREE_DEBUG) += fdt-dump.init.o >> obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o >> obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o >> obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o >> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c >> index fcbeb8adbd73..182201384faf 100644 >> --- a/xen/common/device-tree/dom0less-build.c >> +++ b/xen/common/device-tree/dom0less-build.c >> @@ -1,5 +1,6 @@ >> /* SPDX-License-Identifier: GPL-2.0-only */ >> >> +#include >> #include >> #include >> #include >> @@ -587,6 +588,9 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> if ( ret < 0 ) >> goto err; >> >> + dt_dprintk("Device tree for %pd:\n", d); > Move this message to device_tree_dump. > I'll move. >> + device_tree_dump(kinfo->fdt); >> + >> return 0; >> >> err: >> diff --git a/xen/common/device-tree/fdt-dump.c b/xen/common/device-tree/fdt-dump.c >> new file mode 100644 >> index 000000000000..fc3d9eca5891 >> --- /dev/null >> +++ b/xen/common/device-tree/fdt-dump.c >> @@ -0,0 +1,180 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >> +/* >> + * Dump a flattened device tree blob in a DTS-like format. >> + * >> + * is_printable_string() and print_value() are derived from >> + * util_is_printable_string() and utilfdt_print_data() in the device tree >> + * compiler (dtc). >> + * >> + * Copyright 2011 The Chromium Authors, All Rights Reserved. >> + * Copyright 2008 Jon Loeliger, Freescale Semiconductor, Inc. >> + * util_is_printable_string contributed by >> + * Pantelis Antoniou >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* Deeper nodes are still printed, but not indented any further. */ >> +#define DUMP_MAX_INDENT_DEPTH 32 >> + >> +/* Indentation, in characters, of a node at depth @depth. */ >> +static int __init indent_of(int depth) >> +{ >> + return 2 * min(depth, DUMP_MAX_INDENT_DEPTH); >> +} >> + >> +static bool __init is_printable_string(const void *data, unsigned int len) >> +{ >> + const char *s = data; >> + const char *se = s + len; >> + >> + /* A zero length property, or one which isn't NUL terminated, isn't one. */ >> + if ( (len == 0) || (s[len - 1] != '\0') ) >> + return false; >> + >> + while ( s < se ) >> + { >> + const char *ss = s; >> + >> + while ( (s < se) && *s && isprint(*s) ) > Xen's is_print() behaves differently than what dtc uses. You need to combine it > with is_ascii. Otherwise 0xff would be marked as printable. I'll add the is_ascii() before isprint(): /* * Xen's isprint() also accepts the Latin-1 characters 0xa0-0xff, * while the one dtc uses only accepts ASCII ones. */ while ( (s < se) && *s && isascii(*s) && isprint(*s) ) ... Thanks for review! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 09 11:25:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 11:25:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444260.1661191 (Exim 4.92) (envelope-from ) id 1xF8ip-0000oF-9B; Fri, 09 Oct 2026 11:25:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444260.1661191; Fri, 09 Oct 2026 11: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 1xF8ip-0000o8-63; Fri, 09 Oct 2026 11:25:07 +0000 Received: by outflank-mailman (input) for mailman id 1444260; Fri, 09 Oct 2026 11:25:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xF8in-0000o0-FS for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 11:25:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF8im-002RQ2-SR for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 13:25:04 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8cf10-2eae-0a2a0a5409dd-0a2a4504d64a-0 for ; Fri, 09 Oct 2026 13:25:04 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8cf10-b57f-0a2a45040019-d1558032b5c0-3 for ; Fri, 09 Oct 2026 13:25:04 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a180fbeef5so27249105e9.1 for ; Fri, 09 Oct 2026 04:25:04 -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-4a18bf2343asm94420665e9.9.2026.10.09.04.25.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 04:25: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:From: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=1791545104; x=1792149904; 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=nfVrsniM2DhNE5QjrHY1Qlgp3HIW0cjW0j90MKoAzw4=; b=kEPRES4zqtaVoygJN/zlPujjMJIzaadLpNOLH8rDDfHgUCQyPKeCUlVvX3B3p9bnh+ /bxCpraSstZeGj26L8ivHmMHHE7QzRaZY1zu4aIvsR2ZrNLiHjkku2TfTmffqhJuqyMA 3agW9hGEe5D/qTc0YEKYtTVKMrDksKIj4w96DkuWgr7/ipYQwNJ8MP2Q8VN2xDSKSOL6 3xG6XxhSJ2HMzsCkjB249zJTD787sLSIUYa/mPaQaVqS1p9A0WCtB6pPUnrKLjOFo+vb HjymH0XSoFIb1ojTClqR3uOhGG5gCHTZ/cyRzura43Df6UocqosG5ZMxfh3w/2z3b4wG uScw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791545104; x=1792149904; 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=nfVrsniM2DhNE5QjrHY1Qlgp3HIW0cjW0j90MKoAzw4=; b=F32Z1AtKKssAVTagvBJB77OQoyXBBQCAHxTTQRBST78bwK43Ginf+ZI2b+HBzRW+gP u62qJSWO8Ven00xjRxnKuhR3vDqZbMr2rSp1qfjuBTAyE1u6lc1mG+i+6l4182XbVUOI zZ9cIR1qP4JXaagPUTYcWnn8OzgH0yePXpWTs/lpO/SAtTLw4hosy+swo6lDTEjgVtj6 kQiMu5TSs3Mca4Fgf/P122lAwl2YcihRJF2kJhcg9A7ldzo+G0yIDDyFnVj5TgqCU8OU 2iz7bhsgM/hZLMtJIJoUkH43CBhxRNfM37jjJu5sHveNpUivSnFjNvScYDZl6m8Xal/q P8Dg== X-Forwarded-Encrypted: i=1; AKwUvBw1fFuRdjEEMXAqIUQ0Dmui/jNsp2BAhpltSYtUleyVpuqEwkkdLrdYyGkTJKkyfl2ju+tBrUjB4pE=@lists.xenproject.org X-Gm-Message-State: AFuF++ks0mio497HhYmS47H9k+QP/y1O/B0kQibWQQNoN4dNL2mmGYb4 u2xVqS6Surt9FqcWpk38Uka7fvXFfU0fPxszQT6zk8BAtIJmnVK7Udvx X-Gm-Gg: AYBFou0mRitYuXNMombvdwmnSjbNsIjKzNvQveFfjqoqx4xCMYIjM+pDme9qfprv6WK RCCmSpC0gi2hwx4OGka+FIg/67N66okwDEYhQ146IeNotuh6vW4qmJ6kATNQmJQaKdAXcdP5gQ6 nKUHHkyHjCMVNld7bKXL5OtdZYhWKdZd9tQHeQH11cU/oN16e7NQOBKyGG9GfUcO/pKHBVlnOSN 5d+EImlf70UxXBeXXTd1CTMynfEpLcizp3OmESvIdPydK9S8FyAoGwmy/y8l7RqBGcViuYcvKcw rd3fRK526VWkH5f7JPvxv9G6nCv5CzcLF1VSugAT/dH1anGSxHU8XsoqagxHndFiEZnc7lJoFoi gW0s4beUP+pwpfALExw0VrlasyZfclBpw+QyEnHXUfeoOJO2TabDnPJ/aze5h1Wu7ifEnBaCfwm oPSKAaZaJ8RPz+McifFQ3WvWHpdNP4SnWx7ffqZ0dfKxe12oLVvtR3ArIyXFDpxdLTicswhQ/20 +Q+Ml8ewOEyepzh1o5pEOLNVbcMYxfJxGkVpDfs2XV0hqy+zg== X-Received: by 2002:a05:600c:8b28:b0:49f:bd3c:bc1b with SMTP id 5b1f17b1804b1-4a18e499da4mr27083925e9.22.1791545104192; Fri, 09 Oct 2026 04:25:04 -0700 (PDT) Message-ID: <7090790f-6777-4706-b44f-a7720b52fadc@gmail.com> Date: Fri, 9 Oct 2026 13:25:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] riscv/nospec: Make nospec helpers always_inline To: Alejandro Vallejo , xen-devel@lists.xenproject.org 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 References: <20261007143117.757375-1-alejandro.garciavallejo@amd.com> <20261007143117.757375-3-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20261007143117.757375-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791545104-C20D5B50-5170AB3B/10/73395122804 X-purgate-type: spam X-purgate-size: 1109 On 10/7/26 4:31 PM, Alejandro Vallejo wrote: > While today they don't implement fencing in a way that would block > speculation, once/if they do they'll absolutely need to be inlined, even > if -fno-inline is passed. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/riscv/include/asm/nospec.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/riscv/include/asm/nospec.h b/xen/arch/riscv/include/asm/nospec.h > index f9b0241c98..f9bba8b2bb 100644 > --- a/xen/arch/riscv/include/asm/nospec.h > +++ b/xen/arch/riscv/include/asm/nospec.h > @@ -4,12 +4,12 @@ > #ifndef ASM__RISCV__NOSPEC_H > #define ASM__RISCV__NOSPEC_H > > -static inline bool evaluate_nospec(bool condition) > +static always_inline bool evaluate_nospec(bool condition) > { > return condition; > } > > -static inline void block_speculation(void) > +static always_inline void block_speculation(void) > { > } > LGTM: Reviewed-by: Oleksii Kurochko Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 09 11:33:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 11:33:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444271.1661209 (Exim 4.92) (envelope-from ) id 1xF8rI-0002Wq-4l; Fri, 09 Oct 2026 11:33:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444271.1661209; Fri, 09 Oct 2026 11: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 1xF8rI-0002Wj-19; Fri, 09 Oct 2026 11:33:52 +0000 Received: by outflank-mailman (input) for mailman id 1444271; Fri, 09 Oct 2026 11:33:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF8rH-0002Wd-37 for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 11:33:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF8rG-006ml6-Di for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 13:33:50 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8d116-8faa-0a2a0a5109dd-0a2a4509ecc8-14 for ; Fri, 09 Oct 2026 13:33:50 +0200 Received: from [52.101.193.11] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8d11c-be1a-0a2a45090019-3465c10be4b9-4 for ; Fri, 09 Oct 2026 13:33:49 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO6PR03MB6210.namprd03.prod.outlook.com (2603:10b6:5:356::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Fri, 9 Oct 2026 11:33: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.0496.015; Fri, 9 Oct 2026 11:33: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=dF44rZNriaKObqLfumqvjQSgS9vwSMk1CV+XG5UQ/HPnJ0cJRgKY4tRIm4xfJ9zfiITxIRTLAy+fERctOrrHwH7QmHJUeXdIpESv09TTNJ7bwBLkulKS8fgiFusuA4hLK1NAgb6ICtOI1BKwPdYW4vcPV49bSjasFgjwQ5tQ3qa7Dqnsy/EVyh5x1ReXzSHF38KqHj34HCgPB0Z+NMV5hLLk8oH2Bz4lsw9lSGLPH67gL7aHTlxdYWJVhhYwk0Ifteqo8mLG2eQRE/a0G7gZSso5PZnqjgYS1PXbelmBC7cH9U1W8+2KvnXkt25c8Fd35U4cwPVboQXguosscI9/EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/WyrPRdTuvD0r8LZkwdNqFuIqm3cqujM1UA8B6JtthM=; b=X6BLhmlMLxjrtbpoP3rpjuGcEe+7MpD/Us5YwNlHj/9S8Tmtfxvu9TMjrSjw2cdzv3V7Jn4XBKooilMp5LjhUWZwNn7yGeMdlJmiK33i3KpkfPCyVtw8f6PsLkNubmeV1eKlG9EbWFhbfLBpsVpcMRSGqqUwgxXwMlXkpbvfGEccCCeSSoiFS3mksd7d2LnzcaCtso+Py+9ZEAnLyTmKf8qozuXUffWXIWEhkWAXfZZWQbU6lEFvez0Nhu+/QkzXPWXkw5CNLRA9HznN7aKk5dhMge0cMG0Z82H2QWneRMRZA7xv27PsqJbEBADTSzi5cAxemS1jC/Lo1o3KBwr+YA== 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=/WyrPRdTuvD0r8LZkwdNqFuIqm3cqujM1UA8B6JtthM=; b=FgqcLgoMk3Z2zHNX2eowQaZ+K1rGDL041GQUAF8N7LnsybMcogkmeLsUk6KAd/o/oi8VnKWcpXgd7SN/W4MKcevpzDnPVe4JdOVwAuNXba4cEmUrcpfJB4Es3y281C5tfQDBIO1xB1OH4/QGnO7JYoaLsMDCHV5vfZiH1yNLPOo= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <64b40c8f-81da-4481-85a6-336d0a89a21d@citrix.com> Date: Fri, 9 Oct 2026 12:33:42 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, teddy.astie@vates.tech Subject: Re: [PATCH Linux v3 6/6] xen: Add new Xen pv-op pte_get_and_clear. To: Juergen Gross , Kevin Lampis , xen-devel@lists.xenproject.org References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-7-kevin.lampis@citrix.com> <7778808e-6963-479f-9cfb-a218de0c382e@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: <7778808e-6963-479f-9cfb-a218de0c382e@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO0P123CA0009.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:354::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO6PR03MB6210:EE_ X-MS-Office365-Filtering-Correlation-Id: bd4c6e9e-edaa-4e5b-0dde-08df25f92e02 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|4143699003|56012099006|11063799006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: OpdzLCiOuQQ268bfzd71a2g/OWjmvZHM7gyQeLVlchThZstlMbaRt3BlTRTRMgzFIwhkUBwookCCXt5anc1BwvVA4KYQtxfv4pn7U7PaSiXBr+86XP0vdd9BixDrNiwXb9jmDOX3WzsiD87cc/aRVXU8G98LCsNXeq+0Sgbr0z+eBl5PXTCtqPZ3veGkyWHtpG6zRxmauJAxw3OK2hvW9md0/4dWdhBtWUXvFfVcEinYrbhDgaA6g6AG/sQnyYkgvMRQmneVgghKWy9J3c2QhkC4KAxImOxXm/hYqVqHbd1gvDu3o0Eu8Sa6C/Gj3BuyGKV37UuAOjRQiS2RiygsTogLQq1Hg1DRDsx44yxMAt2CvSw9rmNIK6R2mjw2UNJmrZtYuHsJc+gnjWs/bNbT6SEOb5O7TQfbBjwF370X/gtmLa8GDSbcLKfC0pGK2Tjy8p/uwS4zYrsXYh5KHzxyrqK/HgpxqexEa7pHYjr6MhoIpJ/ts/TIvRbfWmBYim0KpEyfz69z+GsYc/uqlRftp9oJkAWGuaLLmzV3ZY4DJ3HQfbZaxcLv9FQqBCABGMY8IJ/77omEvhi1XVqxzAzUxySg3tfiLt1m6gtdcu/mr05+L8Tf6KteV1jhudEcjp1msRMj1v7q/5O+pwn2AJ0/KdXecVnKeC/hdy0UXRB3dnE= 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)(366016)(1800799024)(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?cnlpbmNvUVh2aHRmek9VMHUyK0sxOVRkM3FlT0xEWlJSYTY5ZlJQTkF6Z29P?= =?utf-8?B?ejMxTklVdks0eU1VQ205TGp3R09OUGpqbmZEVzdIb3piZ1JXeWZjMUdON290?= =?utf-8?B?Sjc4a2E4cnRGdU01UHVZUVhTcVJYcUUxQTNSL284YWlraStPV3RzNXhhQXpt?= =?utf-8?B?OU1yS0xMSFk3QTBKeVdXazBEbVBoSWhiZDREV0oydDRKMHB2MFdTekJKVGkx?= =?utf-8?B?a2FDcVd0NUdzSDRUMHRYbVZqUzgzNHpDYkhOcXR5Mis4b1c3QkdtT1lBRG1H?= =?utf-8?B?MCtkTVdqa0ViOHllK2wzdjVnOXB3anI0SVpVTElRWTNtR1VkOWxka081amZp?= =?utf-8?B?WmxMOVQ0ZTkxUnEwamRxSGIxNlVTazZpNkxnMnR0dDBBS1h6eXhzeHpkMi9F?= =?utf-8?B?NTJlUjl3UUlhalB3R2dUeEVYZGpVcUdBbVNCUDI1QXM1b0swTXIyTVhyKzgv?= =?utf-8?B?RXhtZCtqWUcxaDlpM2dQTnlYQkVwYWw1eUlLZTNPY245Z3FjOEVpUXhzNTJn?= =?utf-8?B?TG1hWjN5Q1dUMnA2V1liSWx6bUJyY0FITm42N2xJaE1jQ2NkRWRiTVYzS2ow?= =?utf-8?B?UE8yNmFQcVhRSVBwWkNyNzViMXRYSHlyd3lvWVJxSHZNdjA3YnhSdHorWVNY?= =?utf-8?B?RjRBZWt6dmlmL2IyU1RmZG1ZV2QxWkFKNjBiSE0wclMyTFdiemZPQjBUd1JY?= =?utf-8?B?SHhLUitFSUp3eGZEbHNsc1Y2bktObGZrYlZIbElPMDczcDR6NjdlTnZFQ0Rk?= =?utf-8?B?ejZzaGJRNUgraE8zbWljRjdzRDFKM2JscUhxbFdGOXFBcUZGRUVLWTkvdHZF?= =?utf-8?B?WDBDaEJoOEVjSjBYVU51THJjK1lmRXV0Vk5OTlZ4aCs3d0ZCQytHZUgyZ3pD?= =?utf-8?B?YXIvV2V5QXpaWElFMitvQm9WTW5pZGhIZzYrKzVzVGcrMlhuN1hLMFFTbzRh?= =?utf-8?B?MHRIdVJzYWQwbjdIdzYvYURqdHFIaFoyZmZYOTlBOXJRWnJvMyt2a3podW9w?= =?utf-8?B?ZUUvbDJiWHVBOUE1TTdKR0p0cVAyVjhLVjY3VUEyeW9hSjFwZ2JyV25VUXpz?= =?utf-8?B?NnE2dnZrSVBzRkhONXZITWRLTDlkTldQVTNQUHVSVmM4WTFqcTQ0R2pqVUFD?= =?utf-8?B?MjlybzNTa3NNMEhUbFd6eHdnTFBWNHpYRld2OXlQMFRNQkdNYzdnVUhhK25M?= =?utf-8?B?Q25EN2JOeWFNVnZxWlc2bFNnZ00wWkFJc29aNUdWQmFVSW5HS0ZQMmg1cURl?= =?utf-8?B?WlY1eW9mQVZCRlhOR3JyK0VES2NWMzBpUmNic1lFeFBvSld4a0wyTHU3dEVG?= =?utf-8?B?dVdEeHFHZ21hWXhmdU5oeEJ6MksyUDBQR1NRWVFqdVc0dXJGS1lGQW8yUGtX?= =?utf-8?B?Tll1eWF6TG1vRkNqbXRSS1FZRW4zWTREWGpEbXFqMXBXSmN6di9Kc0Q0WVdu?= =?utf-8?B?MHJ5emhQQmM5QmdUaEdwWWtObmVWbXQrYkN2Q1FVNVhJRHI3SWhiSFRSL2NP?= =?utf-8?B?R1l1cFE1Zmx5WDVhMklzRWNMLzNkcFVXVlhablVPOTRrcTFiNHNCNmp6bGl2?= =?utf-8?B?a3o1dHFSMVF4V2lxSi9icTNDazZOMFhIS2dERi9lZ0NibDk5NERxN0trZ2U2?= =?utf-8?B?dSsvR1ZYbEw3WTVxR3ZtNS9uUnJuRjhKL3RqYmFTV2JMelZyaTdyNEhHQStB?= =?utf-8?B?YUlvMHhaR0NmMFRFSHAybUJ1N0xvdDI5N0xveGNUcWJXa3ZYajNNT3pZa24x?= =?utf-8?B?KzVWMEExc3BLRkJIWDFRc1h2SmJJYVZVZXhld1VaWVlqZnh5bFJYcVpXVEdz?= =?utf-8?B?OXYveWo3c2VINndRRUt3YVdHNWVpU1Z6dFpDandyYnZENTJvOVlnM2lZbEdy?= =?utf-8?B?SkYzVDYzb1RUSUZIZG1EQ1hKYWxPWmVJNlFjWitIQTdRQjdydXVUam1xYjdo?= =?utf-8?B?Zkc1M0treFRRSC8zaWNheVowUlZTUFRhTDYyMk1LOUhQMEFORHlDeUpJeDVa?= =?utf-8?B?b3VrM2NLdFdOQTUvSUJCT1A4cFFONWlYN0RwMTlYMFBKRkJSSHczMDNUcTBG?= =?utf-8?B?OEVoODhhOEJIR21sdTlyYUhqUXNhUWVkWnFUc295NWx4alV4ZzFEOHJ2Wk4r?= =?utf-8?B?dkw2cXJCZlRsODlkRyt6RU1MdnZYa1ZIRGR1aXd0MERyV0huUkh4Qi90TmJ1?= =?utf-8?B?ZDQ0dmx6aHgxUG9MWk1nNjFLdmZCa0VYMGpYdVY1YldUY1Evb0VFanVMa0J4?= =?utf-8?B?NnZyTjRNbXBDK0N6RWVPcitqMGV6T253VjF6NWc0ZCs0VmdCL2ppTkNNTVg4?= =?utf-8?B?eStvR2lWdTMrUjFXYkdVS3lqVkk4L2tRUmwybmlMZDlUQXRUbVhUQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd4c6e9e-edaa-4e5b-0dde-08df25f92e02 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 11:33:45.9641 (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: ywnQL7bwNCoEI1jwYqBsqL96MuuX7UaUjZRwA0C2dIlTPsyFGBbUxRXKBfcMxlxvwQ8CI4ENQZH52UKmB9JYMWQ8y6dmxrVIzMNA3RNCbfA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR03MB6210 X-purgate-ID: tlsNG-bad1c0/1791545630-3B4D3034-3CF379B9/0/0 X-purgate-type: clean X-purgate-size: 738 On 09/10/2026 9:27 am, Juergen Gross wrote: > On 01.10.26 19:47, 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 > > Reviewed-by: Juergen Gross > > I will take this patch when the Xen side has gone in. "for performance reasons" is of little use to people reading the patch. Can I suggest instead: "If Xen supports XENFEAT_mmu_pt_update_swap, use the new MMU_PT_UPDATE_SWAP instead of native_ptep_get_and_clear().  This avoids the the pagetable write trapping for emulation." ? ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 09 11:41:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 11:41:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444284.1661229 (Exim 4.92) (envelope-from ) id 1xF8yu-0004O6-37; Fri, 09 Oct 2026 11:41:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444284.1661229; Fri, 09 Oct 2026 11:41: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 1xF8yu-0004Nz-0P; Fri, 09 Oct 2026 11:41:44 +0000 Received: by outflank-mailman (input) for mailman id 1444284; Fri, 09 Oct 2026 11:41:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF8ys-0004Ns-GQ for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 11:41:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF8yr-001Ytt-Pp for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 13:41:41 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8d2e4-e002-0a2a0a5209dd-0a2a45099a38-48 for ; Fri, 09 Oct 2026 13:41:41 +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 6ac8d2f5-be1a-0a2a45090019-d155802cb0b6-3 for ; Fri, 09 Oct 2026 13:41:41 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a0213948d3so24995415e9.2 for ; Fri, 09 Oct 2026 04:41:41 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18bf135fasm46955185e9.5.2026.10.09.04.41.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 04:41: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=1791546101; x=1792150901; 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=J1vtJyHxi9TImrGC6xqZu5sra+7jmxwQQAbeO8lJtZQ=; b=tFf8k9v0eJGF5YRmb7PBtDVL7hG1dF10kJq82NKToBPb7gLQ/iRJi2mNN+TSDEOzJI BjUs4PosCYIgIn4JP0tOs4ygoEuLfSplKGtwcBn8xbVIgZm98xYb4SHCE5yPZZbMI526 HmBWVLSGo1TvKvn4u+/utq8Ceo9NEZAQp1XX9HWLg7MAHucYO6jroz2SqGnxqa3WujJn OhOSEvlY5t0oiK8j+Hlk33YLZLwMCMgRFsUoSb22hwydrIqE8yIrgPkBHuMKtxSoYvGB apa3zDzNYXmnOLSoRM/72wOng2iRtFt9K1GBVehuLBumko5aGbpU1hTWl4ms5pzaBg1I Vevg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791546101; x=1792150901; 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=J1vtJyHxi9TImrGC6xqZu5sra+7jmxwQQAbeO8lJtZQ=; b=2eoQxCD/SbdHn+X95ljZNWQkptZWCPUsudMDOS/+T+sncc2pCLjAcXeOHWIkeffxYS pii0FCckAMEOjqnhWxQhIGbsY1//nF2zCyi//vDKEhTFXFUjPyeVxwA8YPtT9BqtpCUj P+WtXskLrt2/y5+Pzd8Ukpo+h9KRjp/KrXRyo5ghB+Azx+YzMa7np5OWcZuzTsYx/Q38 U2xCriY90k+goRpszUAkQoBQqR/9zHuO0TtcXF+UyW0Ci/0sAdzBUWX96x7q+oXI5uu7 yuK/C9uwoZtJSPF4ITqxKboEAFHkFmK1hsyrGNTt9ul0x4bob1tNjiz06f51AkBY41kU HLQA== X-Forwarded-Encrypted: i=1; AKwUvBxpFndD1tA15L/Vwa426mKb+yOYvAOFLR3KbqGhXhLlI97mkbKIYgMKYoGMgwwKQt7wC4d0Y7+nnDE=@lists.xenproject.org X-Gm-Message-State: AFuF++kcZzXGJLWAt4urtnYaICKISY9M3tHVrlOT3IKf69TtjrUMKHQ3 ihopbmA2dvPJ3vCBV+9vOeDP5I/JN72cWxRmVjf4Of86WD/yDtTDrabj X-Gm-Gg: AYBFou0UyIE38eAyU8ipxL+ha/5O3O/NpnpisWqD8hihq/l2R6PW7fJ7jX4Aed+Ba1H xC4uR1ASuU+McDjTZASpKW+70t542aCQjrIw5Hoa9N8rKA9JjYTq6fO7WLgoqtBNMy+aeaxRrb3 Ux4Miwktg4gft09Kg8ghfZjHxaTkmUvKfARSx4PCWxVDlVeQtXMOk9Rw8RhDeyYGlZm1sCWePz+ 5g7BnJ3nv6GUroy7dcvzN23x7XNhESi+N9GMsZ9FJuYljljKPc/EQmnBOTocBHdtyFr8nk2FeOW 3iWgSLJup1ZZKH+h4xdv5+EEd0Ng7om4EFFTEv7dk7xaK8L7MlxgwRGYpl61C+Gvcd9E0+kRvD6 QcqnCTP8ExHgBp3wpS+jYqKplc2wBhaS5OShBISzfOWi1LfUELp/K2sB3WRkQwfJKeWZqdSlovF f4TgHaIX7DykUr10AIdsbFXzLDwJQmH6s8wylsDCC2Q1VLTw+Ho0XcN+a5JHP2LNDh5LHQSTSh5 Tg= X-Received: by 2002:a05:600c:3ba5:b0:4a1:70d4:c69 with SMTP id 5b1f17b1804b1-4a18e4c03bbmr33938215e9.28.1791546101013; Fri, 09 Oct 2026 04:41:41 -0700 (PDT) Message-ID: <144fe444-39ef-456b-9fd4-747c0abc02c5@gmail.com> Date: Fri, 9 Oct 2026 14:41:39 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 04/22] xen/arm: vIOMMU: add generic vIOMMU framework To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6c7570f50af7ebaae8aa709db86959dbd09e1f82.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <6c7570f50af7ebaae8aa709db86959dbd09e1f82.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791546101-BF8D1034-FDDD29F8/0/0 X-purgate-type: clean X-purgate-size: 10715 On 10/7/26 03:06, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > This patch adds basic framework for vIOMMU. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/arch/arm/dom0less-build.c | 2 + > xen/arch/arm/domain.c | 31 +++++++++++- > xen/arch/arm/domain_build.c | 2 + > xen/arch/arm/include/asm/viommu.h | 70 ++++++++++++++++++++++++++++ > xen/drivers/passthrough/Kconfig | 5 ++ > xen/drivers/passthrough/arm/Makefile | 1 + > xen/drivers/passthrough/arm/viommu.c | 49 +++++++++++++++++++ > xen/include/public/arch-arm.h | 6 ++- > 8 files changed, 164 insertions(+), 2 deletions(-) > create mode 100644 xen/arch/arm/include/asm/viommu.h > create mode 100644 xen/drivers/passthrough/arm/viommu.c > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 3f48f74226..f87437915e 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 > > @@ -369,6 +370,7 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node, > uint32_t val; > > d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > + d_cfg->arch.viommu_type = viommu_get_type(); > 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..5c411a2310 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > #include > > #include "vuart.h" > @@ -663,6 +664,21 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > return -EINVAL; > } > > + if ( !(config->flags & XEN_DOMCTL_CDF_iommu) && > + config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) > + { > + dprintk(XENLOG_INFO, > + "vIOMMU requested while iommu not enabled for domain\n"); > + return -EINVAL; > + } I might miss something, but if CONFIG_ARM_VIRTUAL_IOMMU=y and we have SMMUv3 the dom0less domains "without passthrough" will fail to build. arch_parse_dom0less_node() sets viommu_type for every guest. But CDF_iommu is only set when passthrough = "enabled" or the node has a multiboot DTB. So a plain guest without passthrough is therefore rejected here. > + > + if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) > + { > + dprintk(XENLOG_INFO, > + "vIOMMU type requested not supported by the platform or Xen\n"); > + return -EINVAL; > + } > + > return sci_domain_sanitise_config(config); > } > > @@ -762,6 +778,9 @@ int arch_domain_create(struct domain *d, > if ( (rc = sci_domain_init(d, config)) != 0 ) > goto fail; > > + if ( (rc = domain_viommu_init(d, config->arch.viommu_type)) != 0 ) > + goto fail; > + > return 0; > > fail: > @@ -822,7 +841,8 @@ static void resume_ctx_reset(struct resume_info *ctx) > void arch_domain_destroy(struct domain *d) > { > resume_ctx_reset(&d->arch.resume_ctx); > - > + if ( viommu_relinquish_resources(d) ) > + printk(XENLOG_INFO "%pd: Domain vIOMMU teardown failed\n", d); > tee_free_domain_ctx(d); > /* IOMMU page table is shared with P2M, always call > * iommu_domain_destroy() before p2m_final_teardown(). > @@ -1058,6 +1078,7 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list) > */ > enum { > PROG_pci = 1, > + PROG_viommu, > PROG_sci, > PROG_tee, > PROG_xen, > @@ -1105,6 +1126,14 @@ int domain_relinquish_resources(struct domain *d) > if ( ret ) > return ret; > #endif > + /* > + * PCI devices may rely on the vIOMMU, so its resources > + * should be relinquished only after the PCI devices are released. > + */ > + PROGRESS(viommu): > + ret = viommu_relinquish_resources(d); > + if (ret ) > + return ret; > > PROGRESS(sci): > ret = sci_relinquish_resources(d); > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 72d5316180..cd2e09f005 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -1964,6 +1965,7 @@ void __init create_dom0(void) > dom0_cfg.arch.nr_spis = vgic_def_nr_spis(); > dom0_cfg.arch.tee_type = tee_get_type(); > dom0_cfg.max_vcpus = dom0_max_vcpus(); > + dom0_cfg.arch.viommu_type = viommu_get_type(); > > if ( iommu_enabled ) > dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu; > diff --git a/xen/arch/arm/include/asm/viommu.h b/xen/arch/arm/include/asm/viommu.h > new file mode 100644 > index 0000000000..95f82d9cf5 > --- /dev/null > +++ b/xen/arch/arm/include/asm/viommu.h > @@ -0,0 +1,70 @@ > +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ > +#ifndef __ARCH_ARM_VIOMMU_H__ > +#define __ARCH_ARM_VIOMMU_H__ > + > +#include > +#include > +#include > + > +struct viommu_ops { > + /* > + * Called during domain construction if toolstack requests to enable > + * vIOMMU support. > + */ > + int (*domain_init)(struct domain *d); > + > + /* > + * Called during domain destruction to free resources used by vIOMMU. > + */ > + int (*relinquish_resources)(struct domain *d); > +}; > + > +struct viommu_desc { > + /* vIOMMU domains init/free operations described above. */ > + const struct viommu_ops *ops; > + > + /* > + * ID of vIOMMU. Corresponds to xen_arch_domainconfig.viommu_type. > + * Should be one of XEN_DOMCTL_CONFIG_VIOMMU_xxx > + */ > + uint8_t viommu_type; > +}; > + > +#ifdef CONFIG_ARM_VIRTUAL_IOMMU > + > +int domain_viommu_init(struct domain *d, uint8_t viommu_type); > +int viommu_relinquish_resources(struct domain *d); > +uint8_t viommu_get_type(void); > + > +#else > + > +static inline uint8_t viommu_get_type(void) > +{ > + return XEN_DOMCTL_CONFIG_VIOMMU_NONE; > +} > + > +static inline int domain_viommu_init(struct domain *d, uint8_t viommu_type) > +{ > + if ( likely(viommu_type == XEN_DOMCTL_CONFIG_VIOMMU_NONE) ) > + return 0; > + > + return -ENODEV; > +} > + > +static inline int viommu_relinquish_resources(struct domain *d) > +{ > + return 0; > +} > + > +#endif /* CONFIG_ARM_VIRTUAL_IOMMU */ > + > +#endif /* __ARCH_ARM_VIOMMU_H__ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig > index b413c33a4c..a92cfbea98 100644 > --- a/xen/drivers/passthrough/Kconfig > +++ b/xen/drivers/passthrough/Kconfig > @@ -35,6 +35,11 @@ config IPMMU_VMSA > (H3 ES3.0, M3-W+, etc) or Gen4 SoCs which IPMMU hardware supports stage 2 > translation table format and is able to use CPU's P2M table as is. > > +config ARM_VIRTUAL_IOMMU > + bool "Virtual IOMMU Support (UNSUPPORTED)" if UNSUPPORTED > + help > + Support virtual IOMMU infrastructure to implement vIOMMU. > + > endif > > config AMD_IOMMU > diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile > index c5fb3b58a5..c3783188e3 100644 > --- a/xen/drivers/passthrough/arm/Makefile > +++ b/xen/drivers/passthrough/arm/Makefile > @@ -2,3 +2,4 @@ obj-y += iommu.o iommu_helpers.o iommu_fwspec.o > obj-$(CONFIG_ARM_SMMU) += smmu.o > obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o > obj-$(CONFIG_ARM_SMMU_V3) += smmu-v3.o > +obj-$(CONFIG_ARM_VIRTUAL_IOMMU) += viommu.o > diff --git a/xen/drivers/passthrough/arm/viommu.c b/xen/drivers/passthrough/arm/viommu.c > new file mode 100644 > index 0000000000..0c0efd668e > --- /dev/null > +++ b/xen/drivers/passthrough/arm/viommu.c > @@ -0,0 +1,49 @@ > +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ > + > +#include > +#include > +#include > + > +#include > + > +/* Struct to hold the vIOMMU ops and vIOMMU type */ > +static const struct viommu_desc __ro_after_init *cur_viommu; > + > +int domain_viommu_init(struct domain *d, uint8_t viommu_type) > +{ > + if ( viommu_type == XEN_DOMCTL_CONFIG_VIOMMU_NONE ) > + return 0; > + > + if ( !cur_viommu ) > + return -ENODEV; > + > + if ( cur_viommu->viommu_type != viommu_type ) > + return -EINVAL; > + > + return cur_viommu->ops->domain_init(d); > +} > + > +int viommu_relinquish_resources(struct domain *d) > +{ > + if ( !cur_viommu ) > + return 0; > + > + return cur_viommu->ops->relinquish_resources(d); > +} > + > +uint8_t viommu_get_type(void) > +{ > + if ( !cur_viommu ) > + return XEN_DOMCTL_CONFIG_VIOMMU_NONE; > + > + return cur_viommu->viommu_type; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index 00de30b896..a1491f9cf7 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -334,6 +334,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_PMSA 1 > #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA 2 > > +#define XEN_DOMCTL_CONFIG_VIOMMU_NONE 0 > + > struct xen_arch_domainconfig { > /* IN/OUT */ > uint8_t gic_version; > @@ -361,7 +363,9 @@ struct xen_arch_domainconfig { > uint8_t arm_sci_type; > /* IN */ > uint8_t v8r_el1_msa; > - uint16_t pad; > + /* IN */ > + uint8_t viommu_type; > + uint8_t pad; > }; > #endif /* __XEN__ || __XEN_TOOLS__ */ > From xen-devel-bounces@lists.xenproject.org Fri Oct 09 12:34:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 12:34:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444345.1661238 (Exim 4.92) (envelope-from ) id 1xF9nw-0003fi-4i; Fri, 09 Oct 2026 12:34:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444345.1661238; Fri, 09 Oct 2026 12:34: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 1xF9nw-0003fb-24; Fri, 09 Oct 2026 12:34:28 +0000 Received: by outflank-mailman (input) for mailman id 1444345; Fri, 09 Oct 2026 12:34:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xF9nv-0003fV-98 for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 12:34:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xF9nu-00FzXn-CD for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 14:34:26 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8df47-2eae-0a2a0a5409dd-0a2a4505b19a-42 for ; Fri, 09 Oct 2026 14:34:26 +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 6ac8df51-4cb1-0a2a45050019-d155dd2de115-3 for ; Fri, 09 Oct 2026 14:34:25 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48b9d8055dfso4925564f8f.3 for ; Fri, 09 Oct 2026 05:34:25 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db9acdb6dsm3548456f8f.48.2026.10.09.05.34.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 05:34: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=1791549265; x=1792154065; 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=qFSCxbIvOEEeQKIu0h8lYBgS09CRD0JpdNANfgF+YRw=; b=Mc6dm6ppLnjeuUrahdKapP6VnvO+opUPbtipsyS8xLcDZJ0a5NBUgZgQSDWNOCPj/n VUDuLql4jpajIf3bxoR+3wuLwV/CE5slJpRV7rI//hApqyEf8ChC9m0hi/6VZHpm3+r4 7ucEXhWj+unBssxo8aYZ+DP8UTLrQNHsbHpL/IRO98pqb7Jepa49Dc1PPJ2KANjVd2h4 usmuv0zvVocHciJyx39Cvca1g0FdsS2yWkYmocHNH+UMPIJ5iWZ7PhSIu0y8y3YXQLeI owDNGEWgZBZdTYqTPMldxkmLEBwyCbgLgicDyBDxBJksM9dOjGZZaYom80M8jOWtTLjW Hgvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791549265; x=1792154065; 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=qFSCxbIvOEEeQKIu0h8lYBgS09CRD0JpdNANfgF+YRw=; b=NniSWfqqyprG7LFG2ueLJF6NJs+cFrL+mmg/I7rQfowkpmJMQ47xRGZNUlrLFix7UQ M1yW1R7VOd3MOiCDpM0jvhXQ47YBX4FcvM5ax3gjxTf+P3j+rGLQ9Ct+m+rTqb9KCRwj 26lG+wwwmiWOJ9d/726U1HNDIZHnbNo7ZA3DzhXfSniSf2Z1kiJ91hGB40qX0uR2J20p z1NOTA41Mnryy2PSc2J91aGNpz7tUAocBI+6RQW2FPj7Dt9OPlP/0EEGJdGFs+VrLoMX zRSEaMgZuwD+9kAbvUTzHuAb5TeWBg7NVJricblLbouW9Q+3SbxxFpiOcMZU/l9D6QZE Virw== X-Forwarded-Encrypted: i=1; AKwUvBzUPcwVFr6ngIkRp5EH+fXuT+8NM3AqNHzoct+TD7YT3rX2bWrmKZkjgFjiMnHvgRRvtmukCiaK/XQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYKyPvV//XyhK5tTRDY4lEgS0h8XmGzGr0gpPm0TUeJBLasZ1rvi YDw4lJIy8oycdyfexHTLegGmGlsrGRhkg2SfEV2ue8wjnPBI1WDVWFN/ X-Gm-Gg: AYBFou06v/0Whyaqvt2xqPHLLRI9yTpYq8DvtnH2YuyDHvtsQXTirbs2Qbm6IFOeeHM 00IpRHqRftKuMadBKTcoRCcWuU9ZNCen3A3I5IDNIWnH+sJiolbiqhxXTW742F6yCbBKGQBXmVK 3weFapEdpQZ3OO9YOwBL7weRD1H41VT7fhRThdNH7RzWtaOtCXEMGo2h0b+VOTGfhccxq0o9Yns w2xOq25Ebel46PmNYZqq1d1pywRvy1vbsR2K2bTB9PfpBPsWryOrpUceG0BkenjjR9gnJn7XJA1 JtMJGVaRr1UGiGut0I9FaQhqPuTVWmURQkYm0pi7RFAYtOoa0uT2l4ZlmkcNklQYEd55gkknYEj wN/SjSTXifhSATbQfBXi9ppYff5aZnk2XjqNEd6Q1f4gK/SZZri203oDSpSt8r5WcM2KfP21SD8 XKPAbHp6N0OoEgPcD1Z/L5B/Fkn/CsPaYmkehqrWCdiqIvkw/UlP27RHjYiIoFgX7FTXCU1rLMP p0= X-Received: by 2002:a5d:6410:0:b0:48b:4c8:7b07 with SMTP id ffacd0b85a97d-48dbacf33camr2008893f8f.52.1791549265200; Fri, 09 Oct 2026 05:34:25 -0700 (PDT) Message-ID: Date: Fri, 9 Oct 2026 15:34:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 19/22] xen/arm: vIOMMU: Modify the partial device tree for dom0less To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel References: <9e31544f751d8a9708e1e6385da1b3ac6a438153.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <9e31544f751d8a9708e1e6385da1b3ac6a438153.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791549265-F44A42A1-97160712/0/0 X-purgate-type: clean X-purgate-size: 3254 On 10/7/26 03:07, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > To configure IOMMU in guest for passthrough devices, user will need to > copy the unmodified "iommus" property from host device tree to partial > device tree. To enable the dom0 linux kernel to configure the IOMMU > correctly replace the phandle in partial device tree with virtual > IOMMU phandle when "iommus" property is set. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/common/device-tree/dom0less-build.c | 40 ++++++++++++++++++++++++- > 1 file changed, 39 insertions(+), 1 deletion(-) > > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index fcbeb8adbd..7280bcf72b 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -331,7 +331,44 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo, > return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0; > } > > -static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, > +#ifdef CONFIG_ARM_VIRTUAL_IOMMU > +static void __init modify_pfdt_node(void *pfdt, int nodeoff) > +{ > + int proplen, i, rc; > + const fdt32_t *prop; > + fdt32_t *prop_c; > + > + prop = fdt_getprop(pfdt, nodeoff, "iommus", &proplen); > + if ( !prop ) > + return; > + > + prop_c = xzalloc_bytes(proplen); > + if ( !prop_c ) > + return; > + > + for ( i = 0; i < proplen / 8; ++i ) > + { > + prop_c[i * 2] = cpu_to_fdt32(GUEST_PHANDLE_VSMMUV3); > + prop_c[i * 2 + 1] = prop[i * 2 + 1]; > + } > + > + rc = fdt_setprop(pfdt, nodeoff, "iommus", prop_c, proplen); > + if ( rc ) > + { > + dprintk(XENLOG_ERR, "Can't set the iommus property in partial FDT"); > + return; > + } > + > + return; > +} > +#else > + static inline void __init modify_pfdt_node(void *pfdt, int nodeoff) > + { > + return; > + } > +#endif > + > +static int __init scan_pfdt_node(struct kernel_info *kinfo, void *pfdt, > int nodeoff, > uint32_t address_cells, uint32_t size_cells, > bool scan_passthrough_prop) > @@ -357,6 +394,7 @@ static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, > node_next = fdt_first_subnode(pfdt, nodeoff); > while ( node_next > 0 ) > { > + modify_pfdt_node(pfdt, node_next); I might miss something, but ^^^ returns void, so allocation or vSID assigment failures (viommu_allocate_vsid() is added by next commit #20/22) are ignored. So the guest might be created with the host phandle and SID in its device tree or with a half-updated device tree. The IOMMU may (will?) not work and nobody is told. Should not we return the error here? Also looks like the each rewritten node also leaks prop_c. > rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, > scan_passthrough_prop); > if ( rc ) From xen-devel-bounces@lists.xenproject.org Fri Oct 09 13:07:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 13:07:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444374.1661246 (Exim 4.92) (envelope-from ) id 1xFAK6-0008KQ-Gm; Fri, 09 Oct 2026 13:07:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444374.1661246; Fri, 09 Oct 2026 13: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 1xFAK6-0008KJ-E9; Fri, 09 Oct 2026 13:07:42 +0000 Received: by outflank-mailman (input) for mailman id 1444374; Fri, 09 Oct 2026 13:07:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFAK5-0008KD-9O for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 13:07:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFAK4-001s56-MX for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:07:40 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8e716-bab6-0a2a0a5309dd-0a2a4504b4d4-16 for ; Fri, 09 Oct 2026 15:07:40 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8e71c-b57f-0a2a45040019-d1558032a4ce-3 for ; Fri, 09 Oct 2026 15:07:40 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a16c1608faso20610615e9.0 for ; Fri, 09 Oct 2026 06:07:40 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18ee9bd19sm34067205e9.1.2026.10.09.06.07.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 06:07: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=1791551260; x=1792156060; 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=L45L97LSOrdTS6K1MJ/W6YBixnL98U2oylFsU9uAZ6g=; b=hoxDQkWh0CpnS5p+gID1YrTzfRHITDlTyrw6rksuaMcsFVtkq+DuO8d+cVwnEWcgpV heo6cuFJhUoRBlD1iF52vVbg3FBLYVA0lJhKdp3AIoHmBO1XN2lJch6wPtJRSKNHQhzh oYnAfopEVfo/UCBvVbiAEjnCVGTfxA3mFpwm67hgEI1/Py9ESsKd57Dq4heAq2e6c1p+ sAI0jpfIAt2fX4+Q10oo8d/6O1i5VGKXAtH6toZzHj5Wg/+fNLNWaCYV4XzmGU4UJPzc rRLli2yU/N6scDos5xKtcDd6U42CJa9pBMkDo7FXnXkariVQrYgSJU39cLWGXMGKEFN+ AX9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791551260; x=1792156060; 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=L45L97LSOrdTS6K1MJ/W6YBixnL98U2oylFsU9uAZ6g=; b=a3CEKG2GPStxIN0iPswHEeXeyCP5/+hIocJ9rm90kd9eM6jdKjCCpos6+JZR3/DgR8 s+9erZgWVL4WUkFSUu21XUOhn8OhzKE/CY8CTPzGdHo4YFvtg9UunhesBf/m4A1A+Wqn esZ62Kuq9FktEJ32s8EUo5Q7zLcLOFLpLE2w/nkm+JRaXofwqbk67XmN984VEyG+a5S7 jPi0ZrmTwJl4YTWiFZna/Vay46pSVxMxzhakODndBMhZhptfWgdy4SMJRmvQOXfojuHa scBXBD8fzt+xMtv8xELqzXsiHZr2vnk6hSEj1/dA2nD+avrKBRV3iSFH2ZVwwR5ykVoR Bzqg== X-Forwarded-Encrypted: i=1; AKwUvByXdTPp8JNznvGow6ryu13+L7dD8c+sHp3vvuVFf67JB73M/oyDUqnk9A9tZpB+punuij346dopJKg=@lists.xenproject.org X-Gm-Message-State: AFuF++nx/WBh0CeqtIX21YXo0bdIjtwAnFjHXhf5qT0OIGCnV1Cd9D1h 9kD9iO4O0mE6HeHyAZJ5Fp9kOokRK28NiXp6lACG+ZhYuJ/2hLdOjQEo X-Gm-Gg: AYBFou0/gXSIL2V+nrBI4i19MwAED433qWrDp1yrKYn1R1lQLUly8suVbWH/ctKDHiy mNbNof5Sh/vd3lJMbWK3TqIRRTLgqgQCKG87W9Ga4cZWd7ff+nVmJYGy9olrWsmV4aLNCiIBb98 2G5xpYbd268JSpO4p/fwjWrZS+tibNi73sMsJR6QOUFaGIdZdOjZOcNjCh9RBB2id7fPxKNDgHM px46LHhkb2bu7Xplt7a1uYj5vhUtHr/tXZEJfjvQJ+xic/cp7w+Edbmvd7/1IFAjrWlaZ1QcsPl UzpykGEMgI5GH3ufKWpqUt7jU7ddg7IwBq+0PUqXw4TlSnhg5ey3mWfu38DRE+3cPVjtRJ5Uhkg zQE6DWk2FY1ftpgiHRSegQ/VFyIB7cNwFoH+WN1wxhaAnTH4IxWB+2VkgB1sn/l3jl76Wo4F4D6 pSrYV5cmi6dyrpRyxRNfhqeIiG472zMKbOu/nfs79huk/IAkVtHTz0QmTrNV6+2mgxO86PE/vWC Ok= X-Received: by 2002:a05:600c:a011:b0:49e:6581:7baf with SMTP id 5b1f17b1804b1-4a18e447d8bmr33849925e9.2.1791551259602; Fri, 09 Oct 2026 06:07:39 -0700 (PDT) Message-ID: <37275fb7-d8c3-414f-ad72-8bd399310323@gmail.com> Date: Fri, 9 Oct 2026 16:07:36 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 21/22] libxl/arm: Introduce domctl command for IOMMU vSID mapping To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Anthony PERARD , Juergen Gross , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" References: <66d35a04bcde0c41050e61e194de4565d6fed045.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <66d35a04bcde0c41050e61e194de4565d6fed045.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791551260-C34C3B50-9EA31E38/0/0 X-purgate-type: clean X-purgate-size: 14681 On 10/7/26 03:07, Milan Djokic wrote: Hello Milan > For guests created via the control domain (xl, Zephyr xenlib), a partial > device tree is parsed and loaded on the control domain side. > > SIDs in the guest device tree have to be replaced with virtual SIDs that > are mapped to the corresponding physical SIDs. To do this, the control > domain requests Xen to allocate a new vSID and map it to the original > pSID for each IOMMU stream ID associated with a guest device. > > Introduce a new domctl command (XEN_DOMCTL_viommu_allocate_vid) that > allows the control domain to request a new vSID mapping and replace the > original pSID with the allocated vSID in the guest device tree. > > Implement vSID allocation in libxl using this interface for devices > configured behind an IOMMU. > > Signed-off-by: Milan Djokic > --- > tools/include/xenctrl.h | 13 ++++ > tools/libs/ctrl/xc_domain.c | 25 +++++++ > tools/libs/light/libxl_arm.c | 107 +++++++++++++++++++++++++--- > xen/arch/arm/domctl.c | 38 ++++++++++ > xen/include/public/domctl.h | 22 ++++++ > xen/xsm/flask/hooks.c | 4 ++ > xen/xsm/flask/policy/access_vectors | 2 + > 7 files changed, 202 insertions(+), 9 deletions(-) > > diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h > index 9f00d4a19d..d38b365078 100644 > --- a/tools/include/xenctrl.h > +++ b/tools/include/xenctrl.h > @@ -2664,6 +2664,19 @@ int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid, > const uint32_t *llc_colors, > uint32_t num_llc_colors); > > +/* > + * Allocate guest IOMMU vSID and establish its mapping to pSID. > + * It can only be used on domain DT creation. > + * Currently used for ARM only, possibly for RISC-V in the > + * future. Function has no effect for x86. > + */ > +int xc_domain_viommu_allocate_vsid_range(xc_interface *xch, > + uint32_t domid, > + uint16_t nr_sids, > + uint32_t first_psid, > + uint32_t phandle, > + uint32_t *first_vsid); > + > #if defined(__arm__) || defined(__aarch64__) > int xc_dt_overlay(xc_interface *xch, void *overlay_fdt, > uint32_t overlay_fdt_size, uint8_t overlay_op); > diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c > index 94cfab0fa1..0bd3e45fbd 100644 > --- a/tools/libs/ctrl/xc_domain.c > +++ b/tools/libs/ctrl/xc_domain.c > @@ -2222,6 +2222,31 @@ out: > > return ret; > } > + > +int xc_domain_viommu_allocate_vsid_range(xc_interface *xch, > + uint32_t domid, > + uint16_t nr_sids, > + uint32_t first_psid, > + uint32_t phandle, > + uint32_t *first_vsid) > +{ > + int err; > + struct xen_domctl domctl = {}; > + > + domctl.cmd = XEN_DOMCTL_viommu_alloc_vsid_range; > + domctl.domain = domid; > + domctl.u.viommu_alloc_vsid_range.first_psid = first_psid; > + domctl.u.viommu_alloc_vsid_range.phandle = phandle; > + domctl.u.viommu_alloc_vsid_range.nr_sids = nr_sids; > + > + if ( (err = do_domctl(xch, &domctl)) != 0 ) > + return err; > + > + *first_vsid = domctl.u.viommu_alloc_vsid_range.first_vsid; > + > + return 0; > +} > + > /* > * Local variables: > * mode: C > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c > index daaa81f2aa..75c6f8efc5 100644 > --- a/tools/libs/light/libxl_arm.c > +++ b/tools/libs/light/libxl_arm.c > @@ -1322,11 +1322,96 @@ static int copy_partial_fdt(libxl__gc *gc, void *fdt, void *pfdt) > return 0; > } > > -static int modify_partial_fdt(libxl__gc *gc, void *pfdt) > +/* > + * Store virtualized 'iommus' properties for every node attached to IOMMU > + * and passthroughed to guest. > + * Used as a lookup table for mapping -> > + */ > +struct viommu_stream { > + XEN_LIST_ENTRY(struct viommu_stream) entry; > + char path[128]; /* DT path, stable across resizes */ > + fdt32_t *iommus; /* fully virtualized iommus property */ > +}; > + > +static XEN_LIST_HEAD(, struct viommu_stream) viommu_stream_list; Looks like ^^^ is keyed only by DT path ... > + > +/* > + * Helper function which creates mapping of dt node to > + * to virtualized 'iommus' property > + * Mappings stored in a global 'viommu_stream_list' to > + * make it reusable for every fdt resize > + */ > +static int viommu_get_stream(libxl__gc *gc, > + uint32_t domid, > + const fdt32_t *prop, > + int proplen, > + const char* path, fdt32_t **iommus) > { > - int nodeoff, proplen, i, r; > + int i, r; > + uint32_t vsid, psid, phandle; > + struct viommu_stream *viommu_stream; > + > + /* Lookup if stream for target device is already allocated */ > + XEN_LIST_FOREACH(viommu_stream, &viommu_stream_list, entry) > + { > + if (!strcmp(viommu_stream->path, path)) { > + *iommus = viommu_stream->iommus; > + return 0; > + } > + } ... a second domain with the same DT path gets the first domain’s cached vSIDs without any mapping being created for it. Is it ok? > + > + /* Allocate new viommu stream */ > + viommu_stream = malloc(sizeof(struct viommu_stream)); > + if (!viommu_stream) > + return ERROR_NOMEM; > + memset(viommu_stream, 0, sizeof(struct viommu_stream)); > + viommu_stream->iommus = malloc(proplen); > + if (!viommu_stream->iommus) { > + free(viommu_stream); > + return ERROR_NOMEM; > + } > + memset(viommu_stream->iommus, 0, proplen); > + > + LOG(DEBUG, "Creating vIOMMU stream for device %s", > + path); > + > + /* > + * Virtualize device "iommus" property > + * (replace pIOMMU with vIOMMU phandle and pSIDs with mapped vSIDs) > + */ > + for (i = 0; i < proplen / 8; ++i) { > + /* Allocate new vSID mapped to pSID and physical IOMMU */ > + phandle = fdt32_to_cpu(prop[i * 2]); > + psid = fdt32_to_cpu(prop[i * 2 + 1]); > + r = xc_domain_viommu_allocate_vsid_range(CTX->xch, domid, 1, psid, > + phandle, &vsid); > + if (r) { > + LOG(ERROR, "Can't allocate new vSID/vRID for guest IOMMU device"); > + return r; > + } > + viommu_stream->iommus[i * 2] = cpu_to_fdt32(GUEST_PHANDLE_VSMMUV3); > + viommu_stream->iommus[i * 2 + 1] = cpu_to_fdt32(vsid); > + LOG(DEBUG, "Mapped vSID: %u to pSID: %u", vsid, psid); > + } > + > + strcpy(viommu_stream->path, path); > + *iommus = viommu_stream->iommus; > + > + XEN_LIST_INSERT_HEAD(&viommu_stream_list, viommu_stream, entry); > + > + return 0; > +} > + > +/* > + * Used to update partial fdt when vIOMMU is enabled > + * Maps dt properties of IOMMU devices to virtual IOMMU > + */ > +static int viommu_modify_partial_fdt(libxl__gc *gc, void *pfdt, uint32_t domid) > +{ > + int nodeoff, proplen, r; > const fdt32_t *prop; > fdt32_t *prop_c; > + char path[128]; > > nodeoff = fdt_path_offset(pfdt, "/passthrough"); > if (nodeoff < 0) > @@ -1340,11 +1425,16 @@ static int modify_partial_fdt(libxl__gc *gc, void *pfdt) > if (!prop) > continue; > > - prop_c = libxl__zalloc(gc, proplen); > + r = fdt_get_path(pfdt, nodeoff, path, sizeof(path)); > + if ( r < 0 ) { > + LOG(ERROR, "Can't get passthrough node path"); > + return r; > + } > > - for (i = 0; i < proplen / 8; ++i) { > - prop_c[i * 2] = cpu_to_fdt32(GUEST_PHANDLE_VSMMUV3); > - prop_c[i * 2 + 1] = prop[i * 2 + 1]; > + r = viommu_get_stream(gc, domid, prop, proplen, path, &prop_c); > + if (r) { > + LOG(ERROR, "Can't get viommu stream"); > + return r; > } > > r = fdt_setprop(pfdt, nodeoff, "iommus", prop_c, proplen); > @@ -1356,7 +1446,6 @@ static int modify_partial_fdt(libxl__gc *gc, void *pfdt) > > return 0; > } > - > #else > > static int check_partial_fdt(libxl__gc *gc, void *fdt, size_t size) > @@ -1375,7 +1464,7 @@ static int copy_partial_fdt(libxl__gc *gc, void *fdt, void *pfdt) > return -FDT_ERR_INTERNAL; > } > > -static int modify_partial_fdt(libxl__gc *gc, void *pfdt) > +static int viommu_modify_partial_fdt(libxl__gc *gc, void *pfdt, uint32_t domid) > { > LOG(ERROR, "partial device tree not supported"); > > @@ -1507,7 +1596,7 @@ next_resize: > if (info->arch_arm.viommu_type == LIBXL_VIOMMU_TYPE_SMMUV3) { > FDT( make_vsmmuv3_node(gc, fdt, ainfo, dom) ); > if (pfdt) > - FDT( modify_partial_fdt(gc, pfdt) ); > + FDT( viommu_modify_partial_fdt(gc, pfdt, dom->guest_domid) ); > } > > for (i = 0; i < d_config->num_disks; i++) { > diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c > index b76af56fad..dc21dc9fca 100644 > --- a/xen/arch/arm/domctl.c > +++ b/xen/arch/arm/domctl.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > > void arch_get_domain_info(const struct domain *d, > struct xen_domctl_getdomaininfo *info) > @@ -186,6 +187,43 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d, > } > case XEN_DOMCTL_dt_overlay: > return dt_overlay_domctl(d, &domctl->u.dt_overlay); > + > +#ifdef CONFIG_ARM_VIRTUAL_IOMMU > + case XEN_DOMCTL_viommu_alloc_vsid_range: > + { > + int rc = 0; > + uint16_t i; > + uint32_t vsid; > + struct xen_domctl_viommu_alloc_vsid_range *vsid_range = > + &domctl->u.viommu_alloc_vsid_range; > + > + if ( vsid_range->pad ) > + return -EINVAL; > + > + for ( i = 0; i < vsid_range->nr_sids; i++ ) > + { > + rc = viommu_allocate_vsid(d, vsid_range->first_psid > + + i, > + vsid_range->phandle, > + &vsid); > + if( rc ) > + return rc; > + } > + > + if ( !rc ) > + { > + /* Calculate first vSID from allocated range */ > + vsid_range->first_vsid = vsid - > + vsid_range->nr_sids + 1; With vsid_range->nr_sids == 0, vsid stays uninitialised and garbage is copied back to the caller. > + rc = copy_to_guest(u_domctl, domctl, 1); > + if ( rc ) > + rc = -EFAULT; > + } > + > + return rc; > + } > +#endif > + > default: > return subarch_do_domctl(domctl, d, u_domctl); > } > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h > index 510300bb67..2708215d5b 100644 > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -1279,6 +1279,26 @@ struct xen_domctl_get_domain_state { > uint64_t unique_id; /* Unique domain identifier. */ > }; > > +/* > + * XEN_DOMCTL_viommu_alloc_vsid_range > + * > + * Allocate guest vSID range and > + * establish pSID->vSID mapping for target range and physical IOMMU (phandle). > + * Allocated range is continous > + */ > +struct xen_domctl_viommu_alloc_vsid_range { > + /* IN: Range first pSID */ > + uint32_t first_psid; > + /* IN: Physical IOMMU phandle behind which the target device streams are configured */ > + uint32_t phandle; > + /* IN: Number of vSIDs to allocate */ > + uint16_t nr_sids; > + /* padding, must be 0 */ > + uint16_t pad; > + /* OUT: Mapped range first vSID */ > + uint32_t first_vsid; > +}; > + > struct xen_domctl { > /* Stable domctl ops: interface_version is required to be 0. */ > uint32_t cmd; > @@ -1371,6 +1391,7 @@ struct xen_domctl { > #define XEN_DOMCTL_gsi_permission 88 > #define XEN_DOMCTL_set_llc_colors 89 > #define XEN_DOMCTL_get_domain_state 90 /* stable interface */ > +#define XEN_DOMCTL_viommu_alloc_vsid_range 91 > #define XEN_DOMCTL_gdbsx_guestmemio 1000 > #define XEN_DOMCTL_gdbsx_pausevcpu 1001 > #define XEN_DOMCTL_gdbsx_unpausevcpu 1002 > @@ -1439,6 +1460,7 @@ struct xen_domctl { > #endif > struct xen_domctl_set_llc_colors set_llc_colors; > struct xen_domctl_get_domain_state get_domain_state; > + struct xen_domctl_viommu_alloc_vsid_range viommu_alloc_vsid_range; > uint8_t pad[128]; > } u; > }; > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c > index d65ba0aeae..6321b4308b 100644 > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -881,6 +881,10 @@ static int cf_check flask_domctl(struct domain *d, struct xen_domctl *op) > case XEN_DOMCTL_set_llc_colors: > return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_LLC_COLORS); > > + case XEN_DOMCTL_viommu_alloc_vsid_range: > + return current_has_perm(d, SECCLASS_DOMAIN2, > + DOMAIN2__VIOMMU_ALLOC_VSID_RANGE); > + > default: > return avc_unknown_permission("domctl", op->cmd); > } > diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors > index bbb9c117ec..35acbefab2 100644 > --- a/xen/xsm/flask/policy/access_vectors > +++ b/xen/xsm/flask/policy/access_vectors > @@ -253,6 +253,8 @@ class domain2 > set_llc_colors > # XEN_DOMCTL_get_domain_state > get_domain_state > +# XEN_DOMCTL_viommu_alloc_vsid_range > + viommu_alloc_vsid_range > } > > # Similar to class domain, but primarily contains domctls related to HVM domains From xen-devel-bounces@lists.xenproject.org Fri Oct 09 13:30:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 13:30:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444392.1661255 (Exim 4.92) (envelope-from ) id 1xFAfb-00033w-6n; Fri, 09 Oct 2026 13:29:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444392.1661255; Fri, 09 Oct 2026 13:29: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 1xFAfb-00033p-4D; Fri, 09 Oct 2026 13:29:55 +0000 Received: by outflank-mailman (input) for mailman id 1444392; Fri, 09 Oct 2026 13:29:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xFAfZ-00033j-Qf for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 13:29:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFAfY-002mzT-LU for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:29:52 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8ec50-e002-0a2a0a5209dd-0a2a4507b1c6-4 for ; Fri, 09 Oct 2026 15:29:52 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8ec50-b4ea-0a2a45070019-d155dd2cbc3d-3 for ; Fri, 09 Oct 2026 15:29:52 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48c45111bebso2663425f8f.0 for ; Fri, 09 Oct 2026 06:29:52 -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-48db9acc936sm3871405f8f.44.2026.10.09.06.29.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 06:29: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=1791552592; x=1792157392; 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=YUWeuiFsOPNVbMIg8/ULg3P/7iHi93UDzAgRV2VBvgE=; b=WTRdnkPQUnVr+Wx4yEF0avaWn0Evk1wl/tM2DOnMq4uhK5hlgDaGVb3Agiie7fc9UN IMo1lT+9W8P/x3kYMyeLvl9nrHf0iFoX1XPMZDncn9lO20SqCDflqCSYNq/2yfiVkuRg CG7E8jcZgWKAy9cnpNORA+bppFNhfnNfjtlZ3ApUbnQ8WSOOZILAJBWv+egB01fYZnEI VJrqJ6Tb9QvEcfsvNkcHwovsrCsWfPpWiDoe61ah5luJ8ltuuY/tpJDr9gNXrW4f4+oo x2Gy4DkyvJ9AVBpjbT76j3HXQgjVFNtLqQuPUjjE5ko0JkKdaKQzo39Vr11AIZL8cUTX 5zOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791552592; x=1792157392; 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=YUWeuiFsOPNVbMIg8/ULg3P/7iHi93UDzAgRV2VBvgE=; b=CdUZCIeCCoDV5rQ3dzMB/3vy16Y1QZ4ztNIIHejJjG77ik0F58DMyJy3HBYRmt1Ow/ ckuQSHQ/8C+Zp6+0KU3EyWFbEF/RlK8Pt9gj0spTuBpEuYSCRhSqDiYtsQZjOkfMadlQ xpA1M/hrR9eE9dHBP0Q+vEM/eTeilxmjSOZUSYawYwuiCYG/S6c88k4ajw9KmcG3lXMX NoXE7dIIjtTHPAbQvbQF/95tqCGToRMcPuxMCMLxSl41F1xT0Qr48fQr7uqYmKBhHLgG pdONB7fpYsplNdu2NbtQ3fgfHjOMOnLfZTCi0dzWuEXjaNFhU16kdDqbFT30XC5SNt5a xGXA== X-Gm-Message-State: AFq9FYItKQ1GHXEyeeOEHHxRObXziaHeOoJy+ryxUtjQlc/xVCPh4Toc G6pBFRD0mLG2ZhOUmhoSelH11cI7gb+dut3ee+V9zNkwVAfA2R8AzlMy X-Gm-Gg: AYBFou1uwbmA77EwGyif04TJn4sb+I3Yh1nTxFOVozrRvya/nEQgsWCuaz/trmTEisJ SiAClF4k8rhdEVPxbeSoFAEdOn428Gh9T8IVnjkKhiC3L8cKMdbBINmuOdk9qqbC+qbrPmrRcxi ywbfo8nJ0+T2ytP838mOKf+UtAcpWyHcrK62+xWkMsFIBF6ZWI4jCDQG/V/y1gFKdCIx5TQPx2y at4pzsVmhZ+u0CJkCknivzJsZQHADdA6gFZITmyWeLWRWO1fN+aCDB6kfCm9oCP6SQNZQX5Pumz 0wlbLOwAIFidHXO6Dp7in4pf76O899la8JtVylOYSVVzls6isX3OKFwwQR4KJGZovqlV4wFnYDd tP8DuNtszYEmsdD3NWE6LSyNVvjeWQuJeoCCdFipNvx06cOx/zrhZ8CSZPt5TT244hG+hWZHY3+ qb4UVENHIgrgTe+SMPwtuUQ4/YXnSRdoQS/8sSlfHhvYPBMmF9J0t+pnbTKqa0tZJjWCGFHw8D0 3fOamgLyPqqsX1q8VnxMNQ/kCl6KgZZLQNWz7XKKfDn7uZc5w== X-Received: by 2002:a05:6000:454f:b0:48c:69bd:e971 with SMTP id ffacd0b85a97d-48dbaadb133mr2609638f8f.16.1791552591955; Fri, 09 Oct 2026 06:29:51 -0700 (PDT) Message-ID: Date: Fri, 9 Oct 2026 15:29:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 03/39] xen/riscv: introduce csr_volatile_read64() 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: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b8382510003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791194530.8631fc262581453bbf619ec5b2062170.1a10b8382510003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791552592-366DAAE4-50FF18AE/10/73395122804 X-purgate-type: spam X-purgate-size: 677 On 10/5/26 12:01 PM, Baptiste Le Duc wrote: >> On RV32 a 64-bit CSR is accessed as two halves, and H. Reading > As far as I can tell RV32 can't currently be selected (RISCV_64 is def_bool y, > no RISCV_32 in Kconfig), so this path can't even be build-tested. I've tested that manually. > Is the retry > loop really needed now, or a least in this patch series? > I think it is worth keeping the retry loop now so that the code is ready if RV32 support needs to be added in the future, reducing the changes required at that point. It also helps explain why a separate csr_volatile_read64() function is needed in the first place. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 09 13:36:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 13:36:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444401.1661264 (Exim 4.92) (envelope-from ) id 1xFAlt-0004gu-U8; Fri, 09 Oct 2026 13:36:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444401.1661264; Fri, 09 Oct 2026 13:36: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 1xFAlt-0004gn-RQ; Fri, 09 Oct 2026 13:36:25 +0000 Received: by outflank-mailman (input) for mailman id 1444401; Fri, 09 Oct 2026 13:36:24 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFAls-0004ge-5I for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 13:36:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFAlr-00G9ik-Hx for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:36:23 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8edb6-e002-0a2a0a5209dd-0a2a4506aa7a-30 for ; Fri, 09 Oct 2026 15:36:23 +0200 Received: from [103.168.172.144] (helo=fout-a1-smtp.messagingengine.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8edd5-195a-0a2a45060019-67a8ac90948f-3 for ; Fri, 09 Oct 2026 15:36:22 +0200 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id BB13EEC0011 for ; Fri, 9 Oct 2026 09:36:21 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Fri, 09 Oct 2026 09:36:21 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 9 Oct 2026 09:36:19 -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=fm2 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=1791552981; x=1791639381; bh=eXX7bS2mbjbkizKF4zKhStCw3lsDydTB T7bx3WXvOA4=; b=nNJy7JmXICst/tn1L87d54gMmNGltMpbqOTxCaHouqEc9KKv ik6PnofFZU+FhSTAmL7ank2P22X/nDyKjAwkgKFNtsyuBhd59VRMD68mElhhvfQj Pj2Nh9R2RBJEaXN9SzYL0395tsM/SHM1JDOSO8swFbvjYaCRv5qP+OBrJGjFXl/x FaXOrNlvJLDXkeOkWJKv8Is3DgrvTmTpnrl6qh2ihffxoRkS27eLpm2d7Vr1LJqK xgMMRjwAZUmYw4QK4KPXt07xB0chdN/K0J3e+K5tb3IltWJPolZjjERs6Zb0GkA4 hADQNnpqlRDMD4LxITbHdzEyBfqsq4sHjkKvSQ== 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= fm2; t=1791552981; x=1791639381; bh=eXX7bS2mbjbkizKF4zKhStCw3lsD ydTBT7bx3WXvOA4=; b=NQIpbmCvYF2XegLyjdjvPOkj5y0P8vc/rVaWf3XB7rNQ Ki325tsZ9zv2/DQjcIDOxZNkwhm5/qTNP/sLYPJk/OJdAvYWjpsLFmHaXb2NOgJI AlO9TXJYrAerHJ5Ert1sIoza73dq3QhjLXK36rO6WDf/DsZlR7o0fBCj/AS0cKUX 5kO+7/rK4kAkpu4L4NJ6d+py9Mzx9Ddrr54ESX7kn2t34QThXV/fd1sjBxZQeNxG ePvIobT7wrOMJLguhlQ/49jOLCvC7S7SdEQRLk3RQMMuSfiaQv6ulh5at7sSqcev 8nOPE7/xkkot04afy8KykPROhOI9KU84wG/D383Yog== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=sign d=invisiblethingslab.com a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1791552981; d=invisiblethingslab.com; mf=PG1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20+; rt=PHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZz4=; s=fm1:rsa-sha256:NVftbXvxRFoIm41IVip0BxiQM4f2h0E+GtzS72B+FqE9eEr GnPNSjrTu4XXOHmU1s7WXjFAIIadJRRaoeRTtEv+XQXZQJcn5DLCQgq22W+CkMq1 CYn0OJQHi4Vzns83ZHiZB14HgkZ/bqut/2dC2fjyeZwf+Xw5LQ+FYd2KZbRg+Z+b 0DjusDZB3UbYlivP+99W5BJv4Cowf9Xp4fdeCLF5hm2i2PhNICyWyW8NnUYZ0dCS SGVz4ikuNVBi4wQxY3cFrkYUVLaWjGecjHJS/gSmngkeySjGOSfZY504lpK59NGw OYUYZkBTFcgPiAeeSMDWFbYibJzeYxkMENKtt0A==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=mi-m=1; hc=10; hn=cc,content-transfer-encoding,content-type,date,feedback-id, from,message-id,mime-version,subject,to; Message-Instance: m=1; h=sha256:7uwuMWbTpbHUAfMaQVF36ZGVCwEwIZ2gjszEZTuPovo=:PpZLmPaIJnAfjiy/T1yKfWLq73e3pYLK+GJXD1hQdoM=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGlrcD0Gt8OPHBnJoYu0c5vrj1VXyOadjJd/B0SotCdtEJeJKOcxmTCBOJ8jYevPz nfRpRYAQMyP9BfRZxXnYeRAtcy4tAYVR/Um/W0RXo3lXQjgc94YyT7Drgzt0RUe+BlS1Yu e592xh2497B1+GEus7HXoFClW6h26UwGadJ7gpc6r8+MCDb0ad5zU/JtTKir0WfFUZ8IPv rmkr7bhOkA9YryVTjR+FdJ4jMpfsodE9+m9D1S5bKLQvRe/X7t96JDTz/QMMckgs0iKmlB c5PgGFV3k3c50pLaNrCZcEVI/Pb840fydYflRK5s0iRC5QrAG9TXacR45qJQMRd6ESESq0 6ku12fveDAnLAn/pKTs2Ofbu9vIJ+XO1TM/eJqeiduXnTp8mzvFtUwPedWL6uP8fsdRpVL BwtYF2v2DaTEHNeqj5DJKJDnByz401wzC3i+ap63Oc7zpeIEnrK/Ir5mCKSBOwL+T6Hd1x ViKZAjWtQNIbn1T0eO+zyass1IlLNs/74g4/AqXj40/S0lOM+mXoZUGG677nsnSbzI+QBw 8C62DWHjdYxO23pRSyC3/imXYSf5XEZNYeXjmUY75SQT85faL7hMpf2LWEedD9Shg0boDr +TLe6ww/Fn5mXF0yJQCI2nkG+hTldYkQ/+XBCjDdyridIFlujNJWNzteBzlA X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2] drivers/char: add timeout for XHCI console cable Date: Fri, 9 Oct 2026 15:35:59 +0200 Message-ID: <20261009133608.364312-1-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1791552983-F7ACA77B-9D273087/0/0 X-purgate-type: clean X-purgate-size: 3851 Do not wait indefinitely for XHCI to configure console connection. If the cable is not plugged in, timeout after about 1s and continue boot. If the cable is plugged in later, the console will be activated then (see final part of dbc_ensure_running()). When timeout occurs, print a warning message - it will be saved in the console ring buffer, to be later retrieved from dom0, or possibly later printed when the cable is finally connected. But, do not print the warning when waiting after controller reset, as that may have been called from from console dbc_putc() and printing here would result in (possibly infinite) recursion. Try the timeout to be about 1s, which is way above time needed for configuring already connected cable. But, since this part runs very early in the Xen startup, time is not calibrated yet, and functions like NOW() do not work yet. Use raw TSC and estimate needed time to be at least 1s on a fast CPU (5GHz), and possibly longer on a slower one. This is not very accurate method, but fortunately it doesn't need to be. This also helps with similar situation on resuming from suspend - if cable got unplugged in the meantime, system will not hang waiting for the console anymore. And finally, on some systems, when dom0 is also allowed to access the USB controller, it may put the device into low power mode that in some older controllers (for example Kaby Lake) disables also debug capability. In such a case, adding a timeout allows the system to resume, then dom0 can wake up the controller and Xen will resume XHCI console. Signed-off-by: Marek Marczykowski-Górecki --- Changes in v2: - use get_cycles() and cycles_t type (Jan) --- xen/drivers/char/xhci-dbc.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c index d85c8cd6c36a..ddb1051b0832 100644 --- a/xen/drivers/char/xhci-dbc.c +++ b/xen/drivers/char/xhci-dbc.c @@ -851,9 +851,15 @@ static void dbc_reset_debug_port(struct dbc *dbc) } } -static void dbc_enable_dbc(struct dbc *dbc) +static bool dbc_enable_dbc(struct dbc *dbc) { struct dbc_reg *reg = dbc->dbc_reg; + cycles_t start; + /* + * Too early for proper time calibration, assume a 5GHz CPU and let it wait + * about 1s, with still reasonable timeout on a slower CPU. + */ + cycles_t timeout_ticks = 5UL * 1000 * 1000 * 1000; wmb(); writel(readl(®->ctrl) | (1U << DBC_CTRL_DCE), ®->ctrl); @@ -870,8 +876,12 @@ static void dbc_enable_dbc(struct dbc *dbc) writel(readl(®->portsc) | (1U << DBC_PSC_PED), ®->portsc); wmb(); - while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 ) + start = get_cycles(); + while ( (readl(®->ctrl) & (1U << DBC_CTRL_DCR)) == 0 && + get_cycles() - start < timeout_ticks ) cpu_relax(); + + return readl(®->ctrl) & (1U << DBC_CTRL_DCR); } static void dbc_disable_dbc(struct dbc *dbc) @@ -970,7 +980,8 @@ static bool __init dbc_open(struct dbc *dbc) dbc_init_work_ring(dbc, &dbc->dbc_owork); dbc_init_work_ring(dbc, &dbc->dbc_iwork); - dbc_enable_dbc(dbc); + if ( !dbc_enable_dbc(dbc) ) + printk(XENLOG_WARNING "Timeout waiting for XHCI console cable\n"); dbc->open = true; return true; @@ -1307,7 +1318,8 @@ static void cf_check dbc_uart_resume(struct serial_port *port) return; } - dbc_enable_dbc(dbc); + if ( !dbc_enable_dbc(dbc) ) + printk(XENLOG_WARNING "Timeout waiting for XHCI console cable\n"); dbc->suspended = false; dbc_flush(dbc, &dbc->dbc_oring, &dbc->dbc_owork); set_timer(&uart->timer, NOW() + MICROSECS(DBC_POLL_INTERVAL)); -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 09 13:43:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 13:43:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444411.1661273 (Exim 4.92) (envelope-from ) id 1xFAt2-0006Qm-Jd; Fri, 09 Oct 2026 13:43:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444411.1661273; Fri, 09 Oct 2026 13: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 1xFAt2-0006Qf-Gm; Fri, 09 Oct 2026 13:43:48 +0000 Received: by outflank-mailman (input) for mailman id 1444411; Fri, 09 Oct 2026 13:43:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFAt0-0006QZ-Re for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 13:43:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFAt0-004grD-0l for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:43:46 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8ef8b-e002-0a2a0a5209dd-0a2a4505caf8-10 for ; Fri, 09 Oct 2026 15:43:46 +0200 Received: from [74.125.82.177] (helo=mail-dy1-f177.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8ef90-4cb1-0a2a45050019-4a7d52b1b55e-3 for ; Fri, 09 Oct 2026 15:43:45 +0200 Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-354ba08cfd1so680699eec.1 for ; Fri, 09 Oct 2026 06: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=toxicpanda.com header.i="@toxicpanda.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=1791553424; cv=none; d=google.com; s=arc-20260327; b=NYFhxVb5diyr7jjBZJbK8Aude9UoV43ZL0UR/Pc8WHI608GtNj+/LpT5RrUtoie8Vi mhxFSQVUKbEKRkFh1e33AyC6Yi3mRhNZJ7Ss+C9lpAAgtn7uRZ6WYTuDQFi2K9Hu126Z GXMmwQKNRcd58f1rxAD/12Lhuc9DYTpig4l2O8W0MPjhbOkBc95EvwDDFpySQmcTd7pM BqRq3A57Hhqy8RIMr26UmvmsNyjn19EDh136TUXc1fvcxm6e0zfdPwdvj970hH7TsE2i lrq7U5EaBA+1w1IyoJrgiMA0MkhjL4x5TOGv/zUWSBal9fJIZBpstnpXVGJ+IInBdZgr 9snA== 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=Cr53QXzLPPnzzAYL9+Ow9RuREkmHHvveZLDzlgyx6as=; fh=f4v+fmtPwzY0SRokZxYCwr5G2OFpMlb0pe8xMOD0FGI=; b=UXnu9gGWD9cs1LJhf1y0axFIHtB/mJYvDG4x+IFKcoSe9pvAzrDFYqP7I0Ukkp5HLo RZmFHQUrX6/+3v3JGRWuoDvBh13J0jpdfrkVSEKn8/7/2UoAEkawtkBeBf1u74USkrSM WGWSAvCi8sSi41wXTMEwUAYPaAifQ8Xm0JUaXke6EE+mJvzChx9PAbChelu9vnA+3ZUn LbpcyIb8wCiyx+D7wgcCkt3qe3CR//lVIQylqxbSTeN7UpKEtDpoAFtRLbZheCVjztPw b84gD/NOJR6pdbiaI9K3iEAMA2zZYAArK6HLBIDUHGLHxIybxqi3HtZkmisUVYVO2jPj ujxA==; 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=toxicpanda.com; s=google; t=1791553424; x=1792158224; 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=Cr53QXzLPPnzzAYL9+Ow9RuREkmHHvveZLDzlgyx6as=; b=KzydRzWAOYmFgCqUUo02orS01mOz665E0xgWIYfLnrcLNQf8TYBITw/3gzkcaI0+cn DZNUEX3aRhBMGoW8LAKdEmde0PVdHqcXRlhi0XDoPYIRFOpC2hbYVMZ6tL+UViNEDU6H u4No0FuySeKW8G2P5uUjEsYth2OVJBfz+n4u6NICiu2U7mIfY9BRYrPZZDR8oOUl6Om7 dw/yKsYoxRVI1ue8ySdyco2a+UzXEUzImVHqOd4/Zh2P4QdUZFiNIwna4eiqkpy7LXXJ QgCgPUT0TEAKqoHZdrVc+F7reyW9QNjneksZll/B27U3ecQ+jGBow4G3NWdr2NCeXsDN MezQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791553424; x=1792158224; 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=Cr53QXzLPPnzzAYL9+Ow9RuREkmHHvveZLDzlgyx6as=; b=zvUYi4Fb7x2hxjHxgvRUfqkzgU6uLpefQ3rPHJFJIdoUH1xycouJn4GxWeYn6YisVQ zOUzzsdesOQ8MPzOOAdzqY7XLSxSgJgxCRES/Z8NlF2HFnS2QYkuJqi0DyawzWNHiKwC vflSXj8H64+WlBHej0HKtSeUDUXuS/qdwZmn4d8UZY4sstCulXOvAyCZvuYU1NUbtI5G qaKKjbaLxechFRaPmS75Wp6vOGtxA0h6sCYzLan3dZEhZb5Ip2yfby0mMpxGepgcTiKl DrPvXqj8iZ3yq88SJxArlYArJGgIE1iUYW58EONMXffxQjdnb3yfW2kTsu7lyqW0N/JK yTjA== X-Forwarded-Encrypted: i=1; AKwUvBzUtGkMeHTGkr793aUkcJXqk30J/0c+WqJNRF06HLqw9Gn47SVZsraDMpfX1FTifomZisQ+3r+dm88=@lists.xenproject.org X-Gm-Message-State: AFuF++n0QckBO5cEbsH9GMtxBC76hmRYeYWu76rYf1zQ3bgTg21vwwG7 qTjtFjNfg6RrOZUN4VIoWfOa24ZeKt+mH5hf8Z4vHjWV6mRvLVT7zKCYcxJOkiQvX5UYH5irIxs KPnOV4cA1u3kGwJE+uvK8u9LPCDMOcC4+vBsZGDNsCg== X-Gm-Gg: AYBFou3kLI9gme3yxHGvYBja22GxagoknZwpTU4NuESQQVpYopKSM6hdr0SUixVnPqL EtSxZVkkYlP/nsJpcieBZ0oDfDX6A4mvC7naA2UYHFCWBXd8ODwZKT7pMHokhV06e+ldNadImfa hq0mp3cBw00b00Ch/du/HoqIldVRRw1mpGo3qyW4gIy9+UZNqmtu8M292ujrKRm9hC73RfyHSfq 4QHXlp+mItYfmNK3Qbs+xJnfiYZFbDi0N3zUYZSaszN0dJowqkHooELF2TpxTfYjKGFSDxLQsHp hVaTeAqdPlGm1keHfPMd/ePOF+BtTwSszmpx4eKrgcWf6IfwNhorLMbFBKLX2J3fVNZlouLIGXB TUW+ZgqyLOa+zEA== X-Received: by 2002:a05:7301:6e98:b0:33c:e74:4624 with SMTP id 5a478bee46e88-3537e112919mr2778982eec.27.1791553422908; Fri, 09 Oct 2026 06:43:42 -0700 (PDT) MIME-Version: 1.0 References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008141131.0ac356dd@kernel.org> In-Reply-To: <20261008141131.0ac356dd@kernel.org> From: Josef Bacik Date: Fri, 9 Oct 2026 09:43:31 -0400 X-Gm-Features: AclHuK9i2kH_QiKyGXflCaQStHSk6ronnlxME5kUtzkQ0rs0GpgdrjH4gnmAJRI Message-ID: Subject: Re: [PATCH net-next v2 00/10] net: stop calling __pskb_pull_tail() from drivers To: Jakub Kicinski Cc: Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn , Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1791553425-F4EA12A1-1B794979/0/0 X-purgate-type: clean X-purgate-size: 1089 On Thu, Oct 8, 2026 at 5:11=E2=80=AFPM Jakub Kicinski wro= te: > > On Thu, 08 Oct 2026 21:02:47 +0000 Josef Bacik wrote: > > v1->v2: > > - New 1/10: skb_drop_empty_frags(). xen-netfront, netxen and qlcnic > > relied on __pskb_pull_tail() releasing zero-length frags even when > > there's nothing to pull, which pskb_may_pull() doesn't do (Sashiko). > > - xen-netfront, netxen, qlcnic: call skb_drop_empty_frags() after > > pskb_may_pull(). > > - skb_drop_empty_frags() checked with a boot-time test under KASAN and > > kmemleak, on cloned and uncloned skbs. > > Please keep in mind that we ask people to limit themselves to 15 > outstanding patches per tree. You have 18 right now. > (200 active netdev contributors + an LLM) x 20 patches =3D=3D insanity :/ Eesh sorry Jakub, the skbuff BUG_ON() removal series is the more important one, this series is the followup so I can finish that work. By outstanding do you mean per-merge window or once I get notifications for things being merged I'm good to send the next batch? Thanks, Josef From xen-devel-bounces@lists.xenproject.org Fri Oct 09 14:00:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 14:00:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444424.1661282 (Exim 4.92) (envelope-from ) id 1xFB96-0001NI-T0; Fri, 09 Oct 2026 14:00:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444424.1661282; Fri, 09 Oct 2026 14: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 1xFB96-0001NB-QG; Fri, 09 Oct 2026 14:00:24 +0000 Received: by outflank-mailman (input) for mailman id 1444424; Fri, 09 Oct 2026 14:00:24 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xFB96-0001N5-3I for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 14:00:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFB94-00GE3Y-RN for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 16:00:22 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8f36d-8faa-0a2a0a5109dd-0a2a450b9cfe-22 for ; Fri, 09 Oct 2026 16:00:22 +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 6ac8f376-b7e8-0a2a450b0019-d155dd33e92a-3 for ; Fri, 09 Oct 2026 16:00:22 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48bbb06e746so3483564f8f.3 for ; Fri, 09 Oct 2026 07:00:22 -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-48db9463230sm4930194f8f.1.2026.10.09.07.00.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 07:00: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=1791554422; x=1792159222; 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=/cJ5kByjlNpwLVnkCGkRj3iBv1xbQvfIquQOlXXDjkg=; b=Cxv6lY/iOqjzyQoJqOYmA283MJbzhtRzteQIk6P5Ironq5voC4Ri2cbl98brB97lsj 4kzN+raYLNGFZNaEf+HzF6kKjXm3WInsyoI4jO+J8ojWxiTUgcOxlum8CCbDZfSQN8sf eEWkgLynh+wPwmK3WlG8/Dy501G9ggLbgG3nxFg7UAjlC6gqYRoYE0bfVGIgN41kOmjv 3OYOYuZdnvsvnp8+rn4Zpses+nNqgHW4aQfI/bcxXHijWiRYEqzabae3KvbDcGF4n+WX Bi7e46YFlNCG3wYMbkBHFNM7PtByZHXkbyH1xg3JSFrCLXqj8Nh4FD6U4lEhJnnQDgoH T2sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791554422; x=1792159222; 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=/cJ5kByjlNpwLVnkCGkRj3iBv1xbQvfIquQOlXXDjkg=; b=h3eOMGmqyMSRSKRF05rDIJ1vtSWx21HcSDBcqTq2TCIDSe1EFjdLq84OGx/oN0F1Jz y6dV4Xm0389bn4I7ejKO5/fadvuBBVbh28EuVgqPb1Rawi1RERckGN/LiFhkzI4S/z4z Y2X2/vZ7/Khg1URNvqFlsdiuG3oxi4jhjTy2xK97BxZZy3e9BNcQVwQz9qDFtn1QR8s/ rhgn0lBcaBwJy353+3djiZzVw7CilR13JQyXYdeUwESUCtCDG+RXisj3flaiZ/aCKCcc pK0fceBZzWSNkIOntwp3aFtBXI3WJKimUmIdwqDrA+Zw9Qx9ztDsIQ/l/qsHiec7AzEp fDEw== X-Forwarded-Encrypted: i=1; AKwUvBwNoIX0CX4mfjatiBV/2QrmxHmi4Gs52flDmbldsefYXyxHgMrQYI+1vljzBZp/fYeuo7EqrSqVXD0=@lists.xenproject.org X-Gm-Message-State: AFq9FYIWo0MLZf6ZbJ7icbfO94QO0W+0O+Jls61uN8F1kRC9O/hkHzjv ENXPXyjaGmL7WLQ67+EjDsM2fmAq6Ctlwh/D6Ldz0FnUKTNwwUSSRT1c X-Gm-Gg: AYBFou1S9chBecnK2GfTcEPHrQKOvJ065K+wwJY7o2qoT5own6MZXsUblun62W2GnR4 uz3iYbKcT8gAWvCKbCziYcgY45SVy1Mo9Stdf8z9/FGCyVhrWvPDtzX4eNEO3eqU9GaJ5ZtXXIi N5DtTZZiRHHSxkOHnMUWbWgXfc5IgrQ7R+GFA8D44Ky8fq8t2m5m3GusZSeN40xPrPBOEtuSr6U iOtyP08WWg+Eb44DtzfyKFuxElV1IHp9kcBaezW149O1Mc4CdVpXEty8VaEDZW/ThS31x5jAde/ eDzSq0vLoWFqZyo/UtKUwepydYgb84uaYNSWC+ZtbbxBCHsZK2wjvjl7Q8hFfa3YwOcLCbO49f9 tC67QdpqQGMcSbZ8ZCQKyNriy5bDb+U4fSh4A/r6uMU0pZketuTTWovzdicqhL/1Gq2nfHOWpJf bkYyI200o6AsX4ZW4pu4vp54J3y1ZnT8Pa9RGbu5tDi/9IGTEMfANyezURWqztiU9lYNNoKKXGV F5WZo/XgPo8x4AbM+ZpkZ+wNcCNSUb2Kwnk27w9R0Q8EAvUdQ== X-Received: by 2002:a05:6000:260b:b0:485:8c16:a34b with SMTP id ffacd0b85a97d-48dba9dd11bmr3934799f8f.35.1791554421537; Fri, 09 Oct 2026 07:00:21 -0700 (PDT) Message-ID: Date: Fri, 9 Oct 2026 16:00:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 03/39] xen/riscv: introduce csr_volatile_read64() 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-42698a/1791554422-A9CC79EA-DD292EE8/10/78276251493 X-purgate-type: spam X-purgate-size: 4924 On 10/8/26 4:46 PM, Jan Beulich wrote: > On 30.09.2026 18:18, Oleksii Kurochko wrote: >> On RV32 a 64-bit CSR is accessed as two halves, and H. Reading >> the halves with two separate instructions isn't always safe: for a CSR >> which hardware increments, a carry from the low half into the high one can >> happen in between, so a plain pair of reads can produce a value the CSR >> never held. Therefore the high half is re-read and the sequence retried if >> it changed in the meantime. >> >> Only CSRs which change under Xen's feet need that, hence the name. The >> majority can be read with a plain pair of csr_read()s, so no helper for >> those is introduced here as there would be no user for it. >> >> Use it for CSR_TIME, which is exactly such a counter, and widen cycles_t to >> uint64_t. Otherwise get_cycles() would still truncate the time counter to >> 32 bits on RV32. >> >> No functional change on RV64. >> >> Fixes: a541ddadec0a ("xen/riscv: introduce time.h") >> Signed-off-by: Oleksii Kurochko > > Reviewed-by: Jan Beulich Thanks. > > Nevertheless, a few remarks below. > >> --- a/xen/arch/riscv/include/asm/csr.h >> +++ b/xen/arch/riscv/include/asm/csr.h >> @@ -39,12 +39,39 @@ >> 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. >> + * >> + * Only needed for CSRs which change under Xen's feet. >> + */ >> +#define csr_volatile_read64(csr) \ >> +({ \ >> + uint32_t hi_, lo_, old_; \ >> + \ >> + hi_ = csr_read(csr ## H); \ > > This could be the initializer of the variable. > >> + do { \ >> + old_ = hi_; \ >> + lo_ = csr_read(csr); \ >> + } while ( (hi_ = csr_read(csr ## H)) != old_ ); \ >> + \ >> + ((uint64_t)hi_ << 32) | lo_; \ >> +}) >> #else >> #define csr_write64(csr, val) \ >> ({ \ >> csr_write(csr, val); \ >> (void)csr ## H; \ > > While I notice the same exists here already, I wonder what the purpose of > this and ... I can drop it in separate patch. The purpose was just for the symmetry with RV32 case. > >> }) >> + >> +#define csr_volatile_read64(csr) \ >> +({ \ >> + (void)csr ## H; \ > > ... this is (and why their placements differ). Generally a pure 64-bit > environment would have no need for these ...H constants, and their > availability looks to be all that's checked for here. As Baptiste did > point out on patch 11, these uses constitute Misra violations, which we > then would need to deviate. I think we want to try to limit the number of > needed deviations. If I understood MISRA Rule 20.12 correctly (Baptiste pointed me to it on patch 11), the issue is that the csr parameter is used both as an operand of ## and in ordinary, macro-expanded context. I think it would be better to just rewrite these macros so that no deviation is needed: #ifdef CONFIG_RISCV_32 #define csr_write64(name, val) \ ({ \ uint64_t v_ = (val); \ csr_write(CSR_ ## name, v_); \ csr_write(CSR_ ## name ## H, v_ >> 32); \ }) #define csr_read64(name) \ ({ \ uint64_t v_ = csr_read(CSR_ ## name ## H); \ \ (v_ << 32) | csr_read(CSR_ ## name); \ }) /* csr_volatile_read64() similarly */ #else #define csr_write64(name, val) \ ({ \ csr_write(CSR_ ## name, val); \ (void)CSR_ ## name ## H; \ }) ... #endif For RV64, '(void)CSR_ ## name ## H;' could be dropped altogether, and csr_volatile_read64() would be reworked in the same way. IIUC, with such definitions there is no violation of MISRA Rule 20.12. > > And then, seeing how patch 11 introduces an exact copy of this as > csr_read64() - can't we simply have > > #define csr_volatile_read64 csr_read64 > > ? It could be an option, then I will move csr_read64 to this patch. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 09 14:15:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 14:15:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444437.1661292 (Exim 4.92) (envelope-from ) id 1xFBNf-0003Oj-1z; Fri, 09 Oct 2026 14:15:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444437.1661292; Fri, 09 Oct 2026 14:15: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 1xFBNe-0003Oc-Vd; Fri, 09 Oct 2026 14:15:26 +0000 Received: by outflank-mailman (input) for mailman id 1444437; Fri, 09 Oct 2026 14:15:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFBNd-0003OW-Sn for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 14:15:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFBNd-004mFA-9W for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 16:15:25 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8f6ed-bab6-0a2a0a5309dd-0a2a4509c22e-28 for ; Fri, 09 Oct 2026 16:15:25 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac8f6fd-be1a-0a2a45090019-d155dd33a5fd-3 for ; Fri, 09 Oct 2026 16:15:25 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48870973bddso1195396f8f.1 for ; Fri, 09 Oct 2026 07:15:25 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db93d6069sm3878029f8f.0.2026.10.09.07.15.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 07: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=1791555325; x=1792160125; 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=HHPCuC0Z5PfEAw1qPTnZIfiaqv2lLm8bFwsyxAno1Go=; b=lj3GC/bANh5hO/RG64ybc++PvoZGW7oKgsTqhRctYyS5QpSnk7CoeFLLi0SZL69M2f NciBHlnhdtrjF7AXYcLatku3eh85eA2yn8yWlAcRF8/6XMgYTxug0JKwks6FWwYbIX+S 0ThrbffEz8MKJanYppiWjiya3gR28D7RkMN5ArmGqIBmwRB9Nm5yLqsaAHH27Rr6rGgk NVwfpfmO5/AkzeEsSa+p+2bwxvXL75qr+kGr/nf9pdfa7u8A916M+C2B4StfDS81Rz0K irny8iToqo+nCAWILzvgAm24stewM0aGQTwBP7oQyHaoZYrlHSirMp+77OWkuDK+KF8u lSXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791555325; x=1792160125; 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=HHPCuC0Z5PfEAw1qPTnZIfiaqv2lLm8bFwsyxAno1Go=; b=cGmBbaa0UQWaueDjM/Dzst2Cp0bN+YR/FdR61kOtgwHrcuIPORkgNxpmpBSIvEw0Ng fZlBW4no6ZDT0BVVlP/WzUwUBuVKKjhNKyHTbT8rKi5Zl97UEEd5xuQpdSVHdaQmCq2U /BF0Qb+9/e6wcLrbczBZAz5ZdrMWhFRc+2B153fT/hxdw1WdIiKPalD5ZmQ98kSeGu/K fiaAjwF5d7Pfub0hyd9fhHjtW59+fx0CpjvFSdF1SVGaB8dwkf8FWgUB5PteIsVod0eU epFMqwbNtKOT93+06lb8eKSVTMxAGmGk9Rh+CEfol1smIiufva23Q84UZF5SXvZKPxrw DOXQ== X-Forwarded-Encrypted: i=1; AKwUvBxmYQ8l/G9j/qjbQ78F46fVAA9E8+SEcLo5HAcaRoYV8NabABPH+l7c0EKn2Z0geqCi+fbiGmUVA/Y=@lists.xenproject.org X-Gm-Message-State: AFq9FYIplZiLwZQ15KqUNfjVRO+ontEkZ6poH2+ENs50ub7rWs/tdWlu vm2FJku0CBW7jQUXiSGzofz3RA71VXn0NLjy4gnF0qnu33O7JG9UuGLl X-Gm-Gg: AYBFou0htNbv6ByrE4HC1zQiwOgud/PAZbiVj1+m5BodyvWVX9J2TEh6+oN4W4HQEMx 2NfUC3R0ZEjmWbMQAUm8gY+adrJXyYEj1mwNFuChs7mIU0NRu4ksCDuqzLECS8YXx8zjpZI9UfW AKu+kN9aRAw/UnPHLMgR7BIkP3X4UEmHIr7HxTl83m5Gj8c/UxuQeNmQNoHRV6n9Sku7AE7y7uW acSk6qfXBbeoHunD1ZCkOKPxOe3KToBp8Cck1hxnx3v9fuQR9vNRjTCDjslPj5WaQKWGhg9QoCj 5uCabKYDA2LQudEuS2dp5FuB+H6qMzmzXT8Wku9mpJnUEGISQCnIG6lQojdOGTqlGvTrYRFgVNV PHAv/MN1v5+JU3sCyQci3A64qPPBTcwopixLiFCX3L+m2Ce/dUZ4U91WvW+Ij+AzanR2h7wF4aK IGZycCykLhhbznzK+ODmfAwa76v6x93DBr/88yKbBO/eVURj2+svB0QKAhqyDTg5bLUl8h0nCjY mM= X-Received: by 2002:a5d:5e88:0:b0:48d:bafc:a3f6 with SMTP id ffacd0b85a97d-48dbafca4a1mr3971395f8f.0.1791555324411; Fri, 09 Oct 2026 07:15:24 -0700 (PDT) Message-ID: Date: Fri, 9 Oct 2026 17:15:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 20/22] xen/arm: vIOMMU vSID->pSID mapping layer To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1791555325-BF0DD034-4BB31841/0/0 X-purgate-type: clean X-purgate-size: 16922 On 10/7/26 03:07, Milan Djokic wrote: Hello Milan > Introduce a vIOMMU mapping layer to support passthrough of IOMMU devices > attached to different physical IOMMUs, including devices with the same > Stream ID. > > Add a new generic vIOMMU API, viommu_allocate_vsid(), which allocates a > guest vSID and maps it to the input pSID and the backing physical SMMU. > > Once the mapping is established, the guest uses the vSID for stage-1 > commands, and Xen translates the vSID to the corresponding pSID before > processing the command on the physical SMMU. > > Implement usage of the new API for dom0less guests. Allocate vSIDs when > creating the guest device tree and replace the original pSIDs with vSIDs > that are subsequently used by the guest driver. > > Signed-off-by: Milan Djokic > --- > xen/arch/arm/include/asm/viommu.h | 12 +++ > xen/common/device-tree/dom0less-build.c | 33 +++++-- > xen/drivers/passthrough/arm/smmu-v3.c | 10 ++- > xen/drivers/passthrough/arm/viommu.c | 9 ++ > xen/drivers/passthrough/arm/vsmmu-v3.c | 109 +++++++++++++++++++++++- > xen/include/xen/iommu.h | 6 +- > 6 files changed, 165 insertions(+), 14 deletions(-) > > diff --git a/xen/arch/arm/include/asm/viommu.h b/xen/arch/arm/include/asm/viommu.h > index 5ae21042f0..3d0eb92655 100644 > --- a/xen/arch/arm/include/asm/viommu.h > +++ b/xen/arch/arm/include/asm/viommu.h > @@ -34,6 +34,16 @@ struct viommu_ops { > * Called during domain destruction to free resources used by vIOMMU. > */ > int (*relinquish_resources)(struct domain *d); > + > + /* > + * Allocate free vSID/vRID for the guest device and establish vID->pID mapping > + * Called during domain device assignment. > + * Returns 0 on success and sets vsid argument to newly allocated vSID/vRID > + * mapped to physical ID (id argument). > + * Negative error code returned if allocation fails. > + */ > + int (*allocate_vsid)(struct domain *d, uint32_t id, uint32_t phandle, > + uint32_t *vsid); > }; > > struct viommu_desc { > @@ -54,6 +64,8 @@ extern struct list_head host_iommu_list; > int domain_viommu_init(struct domain *d, uint8_t viommu_type); > int viommu_relinquish_resources(struct domain *d); > uint8_t viommu_get_type(void); > +int viommu_allocate_vsid(struct domain *d, uint32_t id, uint32_t phandle, > + uint32_t *vsid); > void add_to_host_iommu_list(paddr_t addr, paddr_t size, > const struct dt_device_node *node, > const void *iommu); > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index 7280bcf72b..673bcbbd1c 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -31,6 +31,8 @@ > #include > #include > > +#include > + > #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX > > static domid_t __initdata xs_domid = DOMID_INVALID; > @@ -332,11 +334,12 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo, > } > > #ifdef CONFIG_ARM_VIRTUAL_IOMMU > -static void __init modify_pfdt_node(void *pfdt, int nodeoff) > +static void __init modify_pfdt_node(void *pfdt, int nodeoff, struct domain *d) > { > int proplen, i, rc; > const fdt32_t *prop; > fdt32_t *prop_c; > + uint32_t psid, phandle, vsid; > > prop = fdt_getprop(pfdt, nodeoff, "iommus", &proplen); > if ( !prop ) > @@ -346,10 +349,23 @@ static void __init modify_pfdt_node(void *pfdt, int nodeoff) > if ( !prop_c ) > return; > > + /* > + * Assign pairs to iommus property and establish > + * vSID->pSID mappings > + */ > for ( i = 0; i < proplen / 8; ++i ) > { > + phandle = fdt32_to_cpu(prop[i * 2]); > + psid = fdt32_to_cpu(prop[i * 2 + 1]); > + rc = viommu_allocate_vsid(d, psid, phandle, &vsid); > + if ( rc ) > + { > + dprintk(XENLOG_ERR, "(DOMID=%u) Failed to allocate vSID for " > + "pSID: %u, pIOMMU: %u", d->domain_id, psid, phandle); > + return; As I mentioned in prev commit #19/22, in that case the guest DT keeps the host phandle and pSID while the domain creates normally since the failure is ignored. I think, we need to propagate the error and fail domain creation. What do you think? > + } > prop_c[i * 2] = cpu_to_fdt32(GUEST_PHANDLE_VSMMUV3); > - prop_c[i * 2 + 1] = prop[i * 2 + 1]; > + prop_c[i * 2 + 1] = cpu_to_fdt32(vsid); > } > > rc = fdt_setprop(pfdt, nodeoff, "iommus", prop_c, proplen); > @@ -362,7 +378,8 @@ static void __init modify_pfdt_node(void *pfdt, int nodeoff) > return; > } > #else > - static inline void __init modify_pfdt_node(void *pfdt, int nodeoff) > + static inline void __init modify_pfdt_node(void *pfdt, int nodeoff, > + struct domain *d) > { > return; > } > @@ -371,7 +388,7 @@ static void __init modify_pfdt_node(void *pfdt, int nodeoff) > static int __init scan_pfdt_node(struct kernel_info *kinfo, void *pfdt, > int nodeoff, > uint32_t address_cells, uint32_t size_cells, > - bool scan_passthrough_prop) > + bool scan_passthrough_prop, struct domain *d) > { > int rc = 0; > void *fdt = kinfo->fdt; > @@ -394,9 +411,9 @@ static int __init scan_pfdt_node(struct kernel_info *kinfo, void *pfdt, > node_next = fdt_first_subnode(pfdt, nodeoff); > while ( node_next > 0 ) > { > - modify_pfdt_node(pfdt, node_next); > + modify_pfdt_node(pfdt, node_next, d); > rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, > - scan_passthrough_prop); > + scan_passthrough_prop, d); > if ( rc ) > return rc; > > @@ -483,7 +500,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, d); > if ( res ) > goto out; > continue; > @@ -493,7 +510,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, > - true); > + true, d); > if ( res ) > goto out; > continue; > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index e44f872d2d..297d2e5e7b 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -3048,7 +3048,7 @@ static struct arm_smmu_device *arm_smmu_get_by_dev(const struct device *dev) > } > > static struct iommu_domain *arm_smmu_get_domain_by_sid(struct domain *d, > - u32 sid) > + u32 sid, const struct arm_smmu_device *smmu) > { > int i; > unsigned long flags; > @@ -3064,6 +3064,9 @@ static struct iommu_domain *arm_smmu_get_domain_by_sid(struct domain *d, > list_for_each_entry(io_domain, &xen_domain->contexts, list) { > smmu_domain = to_smmu_domain(io_domain); > > + if (smmu_domain->smmu != smmu) > + continue; > + > spin_lock_irqsave(&smmu_domain->devices_lock, flags); > list_for_each_entry(master, &smmu_domain->devices, domain_head) { > for (i = 0; i < master->num_streams; i++) { > @@ -3292,14 +3295,15 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d) > } > > static int arm_smmu_attach_guest_config(struct domain *d, uint32_t sid, > - const struct iommu_guest_config *cfg) > + const struct iommu_guest_config *cfg, > + const struct arm_smmu_device *smmu) > { > int ret = -EINVAL; > unsigned long flags; > struct arm_smmu_master *master; > struct arm_smmu_domain *smmu_domain; > struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv; > - struct iommu_domain *io_domain = arm_smmu_get_domain_by_sid(d, sid); > + struct iommu_domain *io_domain = arm_smmu_get_domain_by_sid(d, sid, smmu); > > if (!io_domain) > return -ENODEV; > diff --git a/xen/drivers/passthrough/arm/viommu.c b/xen/drivers/passthrough/arm/viommu.c > index 407e68e62d..6c97acb049 100644 > --- a/xen/drivers/passthrough/arm/viommu.c > +++ b/xen/drivers/passthrough/arm/viommu.c > @@ -75,6 +75,15 @@ int viommu_relinquish_resources(struct domain *d) > return cur_viommu->ops->relinquish_resources(d); > } > > +int viommu_allocate_vsid(struct domain *d, uint32_t id, uint32_t phandle, > + uint32_t *vsid) > +{ > + if ( !cur_viommu ) > + return -ENODEV; > + > + return cur_viommu->ops->allocate_vsid(d, id, phandle, vsid); > +} > + > uint8_t viommu_get_type(void) > { > if ( !cur_viommu || host_iommu_list_incomplete || > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c > index b71511c2eb..53fd7f2d63 100644 > --- a/xen/drivers/passthrough/arm/vsmmu-v3.c > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c > @@ -85,6 +85,8 @@ > #define smmu_get_ste_s1ctxptr(x) FIELD_PREP(STRTAB_STE_0_S1CTXPTR_MASK, \ > FIELD_GET(STRTAB_STE_0_S1CTXPTR_MASK, x)) > > +#define MAX_VSID (1 << SMMU_IDR1_SIDSIZE) > + > /* event queue entry */ > struct arm_smmu_evtq_ent { > /* Common fields */ > @@ -132,6 +134,14 @@ struct arm_vsmmu_queue { > uint8_t max_n_shift; > }; > > +/* vSID->pSID mapping entry */ > +struct vsid_entry { > + bool valid; > + uint32_t vsid; > + uint32_t psid; > + struct arm_smmu_device *smmu; > +}; > + > struct virt_smmu { > struct domain *d; > struct list_head viommu_list; > @@ -156,6 +166,7 @@ struct virt_smmu { > spinlock_t cr2_lock; > spinlock_t strtab_cfg_lock; > spinlock_t irq_cfg_lock; > + struct vsid_entry *vsids; > }; > > /* Helper functions */ > @@ -545,6 +556,49 @@ static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) > struct arm_vsmmu_s1_trans_cfg s1_cfg = {0}; > uint32_t sid = smmu_cmd_get_sid(cmdptr[0]); > struct iommu_guest_config guest_cfg = {0}; > + struct arm_smmu_device *phys_smmu = NULL; > + struct host_iommu *host_iommu; > + uint32_t psid; > + struct arm_smmu_evtq_ent ent = { > + .opcode = EVT_ID_BAD_STREAMID, > + .sid = sid, > + .c_bad_ste_streamid = { > + .ssid = 0, > + .ssv = false, > + }, > + }; > + > + /* vIOMMU->pIOMMU identity mapped for HW domain */ > + if ( is_hardware_domain(d) ) > + { > + psid = sid; > + list_for_each_entry(host_iommu, &host_iommu_list, entry) > + { > + if ( host_iommu->addr == smmu->addr ) > + { > + phys_smmu = (struct arm_smmu_device *) host_iommu->iommu; > + break; > + } > + } > + } > + else { > + /* vSID out of range or not mapped to pSID */ > + if ( sid >= MAX_VSID || !smmu->vsids[sid].valid ) > + { > + arm_vsmmu_send_event(smmu, &ent); > + return -EINVAL; > + } > + > + psid = smmu->vsids[sid].psid; > + phys_smmu = smmu->vsids[sid].smmu; > + } > + > + /* vSID mapped to invalid physical SMMU */ > + if (!phys_smmu) > + { > + arm_vsmmu_send_event(smmu, &ent); > + return -EINVAL; > + } > > ret = arm_vsmmu_find_ste(smmu, sid, ste); > if ( ret ) > @@ -565,7 +619,7 @@ static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) > else > guest_cfg.config = ARM_SMMU_DOMAIN_S1; > > - ret = hd->platform_ops->attach_guest_config(d, sid, &guest_cfg); > + ret = hd->platform_ops->attach_guest_config(d, psid, &guest_cfg, phys_smmu); > if ( ret ) > return ret; > > @@ -1164,6 +1218,9 @@ static int vsmmuv3_init_single(struct domain *d, paddr_t addr, > smmu->addr = addr; > smmu->cmdq.ent_size = CMDQ_ENT_DWORDS * DWORDS_BYTES; > smmu->evtq.ent_size = EVTQ_ENT_DWORDS * DWORDS_BYTES; > + smmu->vsids = xzalloc_array(struct vsid_entry, MAX_VSID); ^^^ is 65536 × 24 bytes = 1.5 MiB per vSMMU allocated contiguously even if, lets say, the domain has two devices? And the hwdom allocates vsids[MAX_VSID] per pSMMU even though the hwdom never uses it (vIOMMU->pIOMMU identity mapped for HW domain) if I got the code right. > + if ( !smmu->vsids ) > + return -ENOMEM; Leaks smmu when the vsids allocation fails. and failure of vgic_reserve_virq() (non-visible in the context) leaks vsids. > > spin_lock_init(&smmu->cmd_queue_lock); > spin_lock_init(&smmu->evt_queue_lock); > @@ -1254,8 +1311,9 @@ static int vsmmuv3_relinquish_resources(struct domain *d) > if ( list_head_is_null(&d->arch.viommu_list) ) > return 0; > > - list_for_each_entry_safe(pos, temp, &d->arch.viommu_list, viommu_list ) > + list_for_each_entry_safe(pos, temp, &d->arch.viommu_list, viommu_list) > { > + xfree(pos->vsids); > list_del(&pos->viommu_list); > xfree(pos); > } > @@ -1263,8 +1321,55 @@ static int vsmmuv3_relinquish_resources(struct domain *d) > return 0; > } > > +int vsmmuv3_allocate_vsid(struct domain *d, uint32_t id, uint32_t phandle, > + uint32_t *vsid) > +{ > + uint32_t i = 0; > + struct virt_smmu *smmu; > + struct host_iommu *host_iommu; > + struct arm_smmu_device *phys_smmu = NULL; > + > + if ( list_head_is_null(&d->arch.viommu_list) ) > + return -ENODEV; > + > + smmu = list_first_entry(&d->arch.viommu_list, struct virt_smmu, viommu_list); > + > + /* > + * Find the physical SMMU corresponding to the device-tree phandle. > + */ > + list_for_each_entry(host_iommu, &host_iommu_list, entry) > + { > + if ( host_iommu->dt_node->phandle == phandle ) > + { > + phys_smmu = (struct arm_smmu_device *) host_iommu->iommu; > + break; > + } > + } > + > + if ( !phys_smmu ) > + return -ENODEV; > + > + /* Get first free vSID index */ > + while ( i < MAX_VSID && smmu->vsids[i].valid ) > + i++; > + > + /* Max number of vSIDs already allocated? */ > + if ( i == MAX_VSID ) > + return -ENOMEM; > + > + /* Establish vSID->pSID mapping */ > + smmu->vsids[i].valid = true; > + smmu->vsids[i].vsid = i; > + smmu->vsids[i].psid = id; > + smmu->vsids[i].smmu = phys_smmu; > + *vsid = smmu->vsids[i].vsid; > + > + return 0; > +} > + > static const struct viommu_ops vsmmuv3_ops = { > .domain_init = domain_vsmmuv3_init, > + .allocate_vsid = vsmmuv3_allocate_vsid, > .relinquish_resources = vsmmuv3_relinquish_resources, > }; > > diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h > index 253f8bb6cb..c94ee4f08e 100644 > --- a/xen/include/xen/iommu.h > +++ b/xen/include/xen/iommu.h > @@ -312,7 +312,10 @@ static inline int iommu_add_dt_pci_sideband_ids(struct pci_dev *pdev) > #endif /* HAS_DEVICE_TREE_DISCOVERY */ > > struct page_info; > +#ifdef CONFIG_ARM > struct iommu_guest_config; > +struct arm_smmu_device; > +#endif > > /* > * Any non-zero value returned from callbacks of this type will cause the > @@ -391,7 +394,8 @@ struct iommu_ops { > > #ifdef CONFIG_ARM > int (*attach_guest_config)(struct domain *d, uint32_t sid, > - const struct iommu_guest_config *cfg); > + const struct iommu_guest_config *cfg, > + const struct arm_smmu_device *smmu); > #endif > }; > From xen-devel-bounces@lists.xenproject.org Fri Oct 09 14:20:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 14:20:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444444.1661302 (Exim 4.92) (envelope-from ) id 1xFBS5-00045R-L1; Fri, 09 Oct 2026 14:20:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444444.1661302; Fri, 09 Oct 2026 14:20: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 1xFBS5-00045K-Hg; Fri, 09 Oct 2026 14:20:01 +0000 Received: by outflank-mailman (input) for mailman id 1444444; Fri, 09 Oct 2026 14:20:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xFBS4-00045E-8g for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 14:20:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFBS3-002uaB-Hk for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 16:19:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac8f7f7-2eae-0a2a0a5409dd-0a2a4509ac44-36 for ; Fri, 09 Oct 2026 16:19:59 +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 6ac8f80f-be1a-0a2a45090019-d155802dd4ac-3 for ; Fri, 09 Oct 2026 16:19:59 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a02667ccebso32596355e9.0 for ; Fri, 09 Oct 2026 07:19: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-4a18f3b43efsm63270195e9.1.2026.10.09.07.19.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 07:19: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=1791555599; x=1792160399; 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=zFDohNVEqor8J343V/3mVqI5r1oMdKV/L3Us9FLV25Y=; b=YvAZCvRvrGBMXghfKh7hKtlZLfWTVXxd36wYvicZ8RP26ymECmdADaNTzpvYS24Od0 6dZVCg8pRY4fEBtjPtbPVFGhScYybFq6wHBn0lL8X0jCLCw3nC3oZM5KBM49nu/1DxJd JvALtg0PClgEY8HCKtv0oFvocTTRVrxneSXpme0gpkE8HMibcVxI01giQtah+y2I4RKc bNxyLRVBq9WIgLwgiNA1zy/XKdhMBLQbQDdf0KAQATDF1s+AfDydrPqGK5Jb9ONF4gTl JdOjVlc63WcYsK6RIn7zra1Ij3pCseLY1RZafW9rhU9i4G+NNF5TMYXgmx/M8O22QWtm 526Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791555599; x=1792160399; 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=zFDohNVEqor8J343V/3mVqI5r1oMdKV/L3Us9FLV25Y=; b=zVgQqcftOA5/NAaW/VpMd5bU9NmCzVYVu9LEkocinsCgGR+5xsp9HhlwbPe8XHSflm HKZpJ/XqwUn9+A8TBBGPdv1Q+2oMhPbjxSUTEK7UERJzzuxuKtyNFqXFbSYg6OFLM6Qb gc6ZFQ0gumlDV2YcJpXy+Eg/3TtrSD82e/KHwYS8hHJQNxcAS5nvqL72RiRV48W65QJI EC+6riFxtiJrOXCwNOLenxsTR1d2Wcw8SC65YyM6sZ2Xk4Pqve/K2dMk11UYSa2dtCGv n1NcJX70Tn4wYix/dsY8mfjQfJJ4HUmlEQgttt9tXIuF9+RPjH5v96EfW8cMLwD4zQt9 WBZg== X-Forwarded-Encrypted: i=1; AKwUvBxB3zt+vf9AZY6UJTJccgcdFoFpDId/0tXgdFf7gFt3Q2eST8m6MRQ6P1HiiGSQXkIoO4vMTcV26aM=@lists.xenproject.org X-Gm-Message-State: AFuF++kCtxAzTKTwnaNK0lw9NIZx0KMmKBNrzikx8zzoD0Mhq0oETz/s dZREpJ1yUGvjhQhG5pFpCJvERruRPydPxJvy8GrnqMnqcX+l0FgD4rTeADBmlmkj8Q== X-Gm-Gg: AYBFou0pkt7uNNy/3hNW3b1Rjk3mOk9l8jV37uxbbRz9Z5lJ2OcCuJzdxfBUVtFAmBv QNF6GqR/9pwtzryrl/BjBsIiWnUTeKPMI8bL6DOkdz9/OwwqFQhLcQcwFdA4KCGFt4H3wVR4XDE XpZDIcCzbyYigzRYpIgRW+66dl6xksOfLr4ea0hsH70oyVD7q0deZGSGjYebkZrXhKG/gB+jE+q 1gZe/xbHXfPM8+S0fk4ABb59p+ta5/KI8LE5L2RRuMt/scERC6D5eM6GuiRUuJ4l4DNUF1N/5At 7OTOtg9pbrK+NaK1ffCT2NHyAOkZLCKLaGXuoHC2i01b7SXS/aqt8Bj9hYIGqSIOWGqFlDO0R0m IE3EwckQlq3MNCn8s5L1tYNWBR2UpiEYDOYqXihEJ6LzIeyu1bRLc4KFUkwIYkulBs5vSSp47TT 4N+8j02UUwtoaHkRXdop5Nhcjtrjr7+01Ssc30HmGjPQ2ZbLYMMcD3FD4TV6vyaG4PBQ+u6SpEh Fv0TGsWwWqETh5S+w0eIfGafjPGT4cBGbV7TKjW76Yy/InN964ZKpV1R4ZBJPU= X-Received: by 2002:a05:600c:a010:b0:4a0:2500:2cd0 with SMTP id 5b1f17b1804b1-4a18e4b4646mr37620695e9.18.1791555598754; Fri, 09 Oct 2026 07:19:58 -0700 (PDT) Message-ID: <25cfacf6-7e3b-4498-93c2-471ecd2ad655@suse.com> Date: Fri, 9 Oct 2026 16:19:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 03/39] xen/riscv: introduce csr_volatile_read64() 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-bad1c0/1791555599-BD4C3034-99518A7B/10/78276251493 X-purgate-type: spam X-purgate-size: 3872 On 09.10.2026 16:00, Oleksii Kurochko wrote: > On 10/8/26 4:46 PM, Jan Beulich wrote: >> On 30.09.2026 18:18, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/include/asm/csr.h >>> +++ b/xen/arch/riscv/include/asm/csr.h >>> @@ -39,12 +39,39 @@ >>> 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. >>> + * >>> + * Only needed for CSRs which change under Xen's feet. >>> + */ >>> +#define csr_volatile_read64(csr) \ >>> +({ \ >>> + uint32_t hi_, lo_, old_; \ >>> + \ >>> + hi_ = csr_read(csr ## H); \ >> >> This could be the initializer of the variable. >> >>> + do { \ >>> + old_ = hi_; \ >>> + lo_ = csr_read(csr); \ >>> + } while ( (hi_ = csr_read(csr ## H)) != old_ ); \ >>> + \ >>> + ((uint64_t)hi_ << 32) | lo_; \ >>> +}) >>> #else >>> #define csr_write64(csr, val) \ >>> ({ \ >>> csr_write(csr, val); \ >>> (void)csr ## H; \ >> >> While I notice the same exists here already, I wonder what the purpose of >> this and ... > > I can drop it in separate patch. The purpose was just for the symmetry > with RV32 case. > >> >>> }) >>> + >>> +#define csr_volatile_read64(csr) \ >>> +({ \ >>> + (void)csr ## H; \ >> >> ... this is (and why their placements differ). Generally a pure 64-bit >> environment would have no need for these ...H constants, and their >> availability looks to be all that's checked for here. As Baptiste did >> point out on patch 11, these uses constitute Misra violations, which we >> then would need to deviate. I think we want to try to limit the number of >> needed deviations. > > If I understood MISRA Rule 20.12 correctly (Baptiste pointed me to it on > patch 11), the issue is that the csr parameter is used both as an operand > of ## and in ordinary, macro-expanded context. > > I think it would be better to just rewrite these macros so that no > deviation is needed: > > #ifdef CONFIG_RISCV_32 > #define csr_write64(name, val) \ > ({ \ > uint64_t v_ = (val); \ > csr_write(CSR_ ## name, v_); \ > csr_write(CSR_ ## name ## H, v_ >> 32); \ > }) > > #define csr_read64(name) \ > ({ \ > uint64_t v_ = csr_read(CSR_ ## name ## H); \ > \ > (v_ << 32) | csr_read(CSR_ ## name); \ > }) > /* csr_volatile_read64() similarly */ > #else > #define csr_write64(name, val) \ > ({ \ > csr_write(CSR_ ## name, val); \ > (void)CSR_ ## name ## H; \ > }) > ... > #endif > > For RV64, '(void)CSR_ ## name ## H;' could be dropped altogether, and > csr_volatile_read64() would be reworked in the same way. > > IIUC, with such definitions there is no violation of MISRA Rule 20.12. That's my understanding, too. So afaic - yes please (preferably with the casts to void of the *H constants also dropped). Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 09 15:12:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 15:12:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444484.1661319 (Exim 4.92) (envelope-from ) id 1xFCGs-0004WE-D7; Fri, 09 Oct 2026 15:12:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444484.1661319; Fri, 09 Oct 2026 15: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 1xFCGs-0004W7-83; Fri, 09 Oct 2026 15:12:30 +0000 Received: by outflank-mailman (input) for mailman id 1444484; Fri, 09 Oct 2026 15:12:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFCGr-0004W1-0b for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:12:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFCGq-00GOwQ-Dq for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 17:12:28 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9044c-8faa-0a2a0a5109dd-0a2a4504b49e-16 for ; Fri, 09 Oct 2026 17:12:28 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac9045c-b57f-0a2a45040019-d155dd36a94b-3 for ; Fri, 09 Oct 2026 17:12:28 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48b0d19cf7eso1446777f8f.1 for ; Fri, 09 Oct 2026 08:12:28 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db98c3a13sm4260445f8f.25.2026.10.09.08.12.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 08: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=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=1791558747; x=1792163547; 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=mXUTk109MUNiV3CHwbLxgh4TujqsBi7GZrDNElkSRj8=; b=jX3N9KUIVCC9mMij0d+IiKMgR9QZOVEac7EeDh75+k+C4KI8udSEiEexqzfUY+yG49 wOHUDhV0xxCqdUc442w2JjAZ2xuVIXxSb0sepuaVHcOip5xHKEpN7FfHUuz/byQg5+Oy XFanGJcgdH7IQhl5b45rSmcIdjAnL6zTd8Dwy3WBlpxYfZb5QixNVkvp7d1socxjLVQS ffmrjYk+Nw+RAh8i7YQ6Y7B55whIFGBqTL+LPW8M+mS0r5+bSODfJAvvxbmDKY54z3Z8 jTcl42pJ2SRyjoSJR9cQpMJaXwy6TqHzrqANAkr3EYcikMDepfBpARXr4dKMCScfQjGZ TGSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791558747; x=1792163547; 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=mXUTk109MUNiV3CHwbLxgh4TujqsBi7GZrDNElkSRj8=; b=hd7IOsP1Uir8+7kg9RAXLSZcvEPuIZRC7jhEss0Yp/K9T9JrSwvp18aj7h2cNcR6ol eUewB5ZBztwtM/dweCiwx0yPIfifvtJwUJnc7kfE0Fr6OBx1e6kkvxRSSsSTKxfBluPx tUOXMp4mt2egydD38/RjkVn4mQGdkWxoykUj61OCJYdi8NMUAkOtDlZGSaDFSHhicAFq 5BZzSKZ2OIthIX3oeOmH9oMuvS0DXVMRcNr/pB2gzKFh48L4ru0ZuXt8tbiwvn5KN6p/ HmvwBxRCtgJmd8RWW2qvLI4cbR0fE8+Ro0rBEunwhTvJtArd6a0UvGGKnIELjUrVq+3o Bvog== X-Forwarded-Encrypted: i=1; AKwUvBzcjC6JH8DZARAaKrCmk5EnrA9ZHBBkhGnLLwef6xQpf1pPeRx5FfzHDAa48aAwpyqAznCVQA0mH+0=@lists.xenproject.org X-Gm-Message-State: AFq9FYL/AczXMB6kGhsO6zyMr9tsSnrnA1WOSP4l+cNw4xj/VUbLWYQf oW4Th7Oi2RgI94ybtQol+GZFvShJHA+Lg+wAb7Jj8dcbVEy/HXKHWiJv X-Gm-Gg: AYBFou3iU4657pvrqqGcUJp3viGNniua0ZEKffXr3E1iWqku0Jg7b4tyGnoZ6cVtuOh TiQo4+ekOtSovIEaDeZDQP5FqUntHX40wPdSTcvKsQm1piWQHNR5AaI6O4SGuDbD23YV3gRpNLz OpaUdBct/t4rg+oRahyVFMwTxKKb5DWDUhZgTNdf1J4jHVau9p+Ix6kvzSpFGLkRW8EC7grLQBB xiQ+fZ6GCiF5bPq9njySvGcXnnog+JCL9qKI/GwjtCIOTQq7YTLMOdD/TSdY6z5BvDleprSd440 0T9J0m+7UuI2xZ2+nK4dVKKYuiQqj8U8yivL2+S95T0nO/JV5ho9AAzycqnTzklBBcAaPXPLvZy vdAZsAO3xT8sUyaWcID/eOvpBfDxrkwd4i8TK1W/XAU/b57cfoFwM/tVDbqdqVGR86ooChO9PuS MKbJFD+ShXiXyhL3Dlp9crcJ1EpgJ3NUHlguR5DICGeYU3bQ1JANKqxF//wh8dSx3Rpt0sUauAx 8U= X-Received: by 2002:a05:6000:2dc5:b0:48a:f4d4:e1f3 with SMTP id ffacd0b85a97d-48dbaaecd68mr3640264f8f.13.1791558745058; Fri, 09 Oct 2026 08:12:25 -0700 (PDT) Message-ID: <7b1f3938-2d07-4884-a377-ce7d9b66fdb9@gmail.com> Date: Fri, 9 Oct 2026 18:12:22 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 17/22] xen/arm: vsmmuv3: Add support to send stage-1 event to guest To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Bertrand Marquis , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk References: <94ab2741c9c61f2b66d9c5a207f913f4241c42a4.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <94ab2741c9c61f2b66d9c5a207f913f4241c42a4.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791558748-51AD0B50-1BD0A6AA/0/0 X-purgate-type: clean X-purgate-size: 6197 On 10/7/26 03:07, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > Stage-1 translation is handled by guest, therefore stage-1 fault has to > be forwarded to guest. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/drivers/passthrough/arm/smmu-v3.c | 48 ++++++++++++++++++++++++-- > xen/drivers/passthrough/arm/vsmmu-v3.c | 44 +++++++++++++++++++++++ > xen/drivers/passthrough/arm/vsmmu-v3.h | 8 +++++ > 3 files changed, 98 insertions(+), 2 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index 196ac660ef..e44f872d2d 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -871,7 +871,6 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid) > return 0; > } > > -__maybe_unused > static struct arm_smmu_master * > arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid) > { > @@ -892,10 +891,51 @@ arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid) > return NULL; > } > > +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt) > +{ > + int ret; > + struct arm_smmu_master *master; > + u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]); Maybe my comment should better be suited for commit #20/22 (where the vSID->pSID mapping is introduced)... Look like the event is copied to the guest unchanged (with patch 20 applied). It carries the pSID instead of the vSID, even though patch 20’s table could translate it. So the domain might not find the device, or might blame a different one whose vSID matches that number. Or I missed something? > + > + switch (FIELD_GET(EVTQ_0_ID, evt[0])) { > + case EVT_ID_TRANSLATION_FAULT: > + break; > + case EVT_ID_ADDR_SIZE_FAULT: > + break; > + case EVT_ID_ACCESS_FAULT: > + break; > + case EVT_ID_PERMISSION_FAULT: > + break; > + default: > + return -EOPNOTSUPP; > + } > + > + /* Stage-2 event */ > + if (evt[1] & EVTQ_1_S2) > + return -EFAULT; > + > + mutex_lock(&smmu->streams_mutex); > + master = arm_smmu_find_master(smmu, sid); > + if (!master) { > + ret = -EINVAL; > + goto out_unlock; > + } > + > + ret = arm_vsmmu_handle_evt(master->domain->d, smmu->dev, evt); ^^^ dereferences master->domain->d with no NULL check. Would it be possible that a fault event queued earlier can still arrive after the device is detached (on domain destruction), so master->domain is NULL? > + if (ret) { > + ret = -EINVAL; > + goto out_unlock; > + } > + > +out_unlock: > + mutex_unlock(&smmu->streams_mutex); > + return ret; > +} > + > /* IRQ and event handlers */ > static void arm_smmu_evtq_tasklet(void *dev) > { > - int i; > + int i, ret; > struct arm_smmu_device *smmu = dev; > struct arm_smmu_queue *q = &smmu->evtq.q; > struct arm_smmu_ll_queue *llq = &q->llq; > @@ -905,6 +945,10 @@ static void arm_smmu_evtq_tasklet(void *dev) > while (!queue_remove_raw(q, evt)) { > u8 id = FIELD_GET(EVTQ_0_ID, evt[0]); > > + ret = arm_smmu_handle_evt(smmu, evt); > + if (!ret) > + continue; > + > dev_info(smmu->dev, "event 0x%02x received:\n", id); > for (i = 0; i < ARRAY_SIZE(evt); ++i) > dev_info(smmu->dev, "\t0x%016llx\n", > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c > index 87342fdf69..b71511c2eb 100644 > --- a/xen/drivers/passthrough/arm/vsmmu-v3.c > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c > @@ -338,6 +338,49 @@ static void arm_vsmmu_send_event(struct virt_smmu *smmu, > return; > } > > +static struct virt_smmu *vsmmuv3_find_by_addr(struct domain *d, paddr_t paddr) > +{ > + struct virt_smmu *smmu; > + > + list_for_each_entry( smmu, &d->arch.viommu_list, viommu_list ) > + { > + if ( smmu->addr == paddr ) > + return smmu; > + } > + > + return NULL; > +} > + > +int arm_vsmmu_handle_evt(struct domain *d, struct device *dev, uint64_t *evt) > +{ > + int ret; > + struct virt_smmu *smmu; > + > + if ( is_hardware_domain(d) ) > + { > + paddr_t paddr; > + /* Base address */ > + ret = dt_device_get_address(dev_to_dt(dev), 0, &paddr, NULL); > + if ( ret ) > + return -EINVAL; > + > + smmu = vsmmuv3_find_by_addr(d, paddr); > + if ( !smmu ) > + return -ENODEV; > + } > + else > + { > + smmu = list_entry(d->arch.viommu_list.next, > + struct virt_smmu, viommu_list); > + } > + > + ret = arm_vsmmu_write_evtq(smmu, evt); > + if ( ret ) > + arm_vsmmu_set_gerror(smmu, GERROR_EVTQ_ABT_ERR); > + > + return 0; > +} > + > static int arm_vsmmu_find_ste(struct virt_smmu *smmu, uint32_t sid, > uint64_t *ste) > { > @@ -1118,6 +1161,7 @@ static int vsmmuv3_init_single(struct domain *d, paddr_t addr, > smmu->d = d; > smmu->features = features; > smmu->virq = virq; > + smmu->addr = addr; > smmu->cmdq.ent_size = CMDQ_ENT_DWORDS * DWORDS_BYTES; > smmu->evtq.ent_size = EVTQ_ENT_DWORDS * DWORDS_BYTES; > > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.h b/xen/drivers/passthrough/arm/vsmmu-v3.h > index 9f4c86abd5..d4b7cf805f 100644 > --- a/xen/drivers/passthrough/arm/vsmmu-v3.h > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.h > @@ -8,6 +8,8 @@ > > void vsmmuv3_set_type(void); > > +int arm_vsmmu_handle_evt(struct domain *d, struct device *dev, uint64_t *evt); > + > #else > > static inline void __init vsmmuv3_set_type(void) > @@ -15,6 +17,12 @@ static inline void __init vsmmuv3_set_type(void) > return; > } > > +static inline int arm_vsmmu_handle_evt(struct domain *d, > + struct device *dev, uint64_t *evt) > +{ > + return -EINVAL; > +} > + > #endif /* CONFIG_VIRTUAL_ARM_SMMU_V3 */ > > #endif /* __ARCH_ARM_VSMMU_V3_H__ */ From xen-devel-bounces@lists.xenproject.org Fri Oct 09 15:25:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 15:25:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444495.1661327 (Exim 4.92) (envelope-from ) id 1xFCTQ-0006J1-De; Fri, 09 Oct 2026 15:25:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444495.1661327; Fri, 09 Oct 2026 15:25: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 1xFCTQ-0006Iq-8t; Fri, 09 Oct 2026 15:25:28 +0000 Received: by outflank-mailman (input) for mailman id 1444495; Fri, 09 Oct 2026 15:25:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFCTO-0006Ih-SH for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:25:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFCTN-00GQzu-Cs for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 17:25:25 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9073e-8faa-0a2a0a5109dd-0a2a4506c6c4-38 for ; Fri, 09 Oct 2026 17:25:25 +0200 Received: from [40.93.198.39] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac90760-195a-0a2a45060019-285dc627b1f8-3 for ; Fri, 09 Oct 2026 17:25:25 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SN4PR03MB998611.namprd03.prod.outlook.com (2603:10b6:806:218::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Fri, 9 Oct 2026 15:25: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.0496.015; Fri, 9 Oct 2026 15:25: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=Y8LkXIFZRmCQm8DNUeS/f6jqGj3BHjk1YEsm30t8ft8gyyueI/03XugeEF09FicKLdcxdI3kO9DXIARdbf6wp+dwUQQgAXtLqMRgxXl2R2Ma2jyL0PRx1+Wh9gIV93VM7xw5tsOrzrzAoTd0PIXPQkt6roS/+gby+Jgh6XVupObZSSZKbqEJG+BaV8TGjSwWTz6Mgl+f+HrYaQaQCzvtWyGtPBVNMQLCrzrJb0yztLQ96uaxIUk6bzVDNWwY/Tf8CKl+wWPGPy5z4tc/nxalzVu3wjg2f2e7Urj/QmTqbhzsVs0cz++4Jb2kd827A77f0VNuI5zLmzSyP1ZIA0Vu/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=ingmyAoLJQaBTry0Pl4sw5csPWCENmolAoLeZlfxa24=; b=MUv/zpg9lOtghuKItcYc4bzlk57RumzZm2dUzEQx5HBx5f+6thQuY/MxtPGAq8hSJtNgV8HFXxXEZy4bQtIa4CMlN6Lh8mXYclXKAnH1h6WGTmJ6Fvasuj7Hzta/tk0TClzOaoPxa1rJNR2YJ3+DeqMCT7uL6RoduJe5CU5zxxqt8FCzbwiWaTMT7odoE9z6C26If9wLYMF0JBnyipAZforpDmmQKAVE9qMYW4qKVXG6OOAE8KckDL4epFtxSXjYXncRDCcwe0HiauNw1Xi/EjUtzRePqerlePq0z83nTJuDyOL2tBhQuFRQPrj4PLbgV2Gfjfs321xxzErKN3V8ew== 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=ingmyAoLJQaBTry0Pl4sw5csPWCENmolAoLeZlfxa24=; b=tXduahzN87ytat82RFqKut8cyY8XtCmSNdjBT5tAUDKLuSDNTYLVUqa2ole8iHZr6cj1tb6tUzUXTX5tumidAGzqWSDBHYSCADvzrbrSw8e1zLp9iMrjSGbwNxSBBVaYC5mFTHma0u4V3BqZqrNb4M2TI0YV+D4zn+edAUlF4hc= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1f48cb36-49eb-4f9e-8aac-25c1bc86674c@citrix.com> Date: Fri, 9 Oct 2026 16:25:15 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , "teddy.astie@vates.tech" , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v3 1/6] x86: Remove return value from UPDATE_ENTRY To: Kevin Lampis , Jan Beulich References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-2-kevin.lampis@citrix.com> <2db46bf6-87e7-4f1f-b440-b73be1f86b55@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PA7P264CA0519.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:3db::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SN4PR03MB998611:EE_ X-MS-Office365-Filtering-Correlation-Id: 4528f9db-e39a-4f9b-0160-08df261986b0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|22082099003|18002099003|10067099003|4143699003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: yjXK3Kn2G4rLlzbIt7o8YiMNsz1EBSw4Oktlq92NwjiGQXVFgScbF2VOCuN+HPY3kTPPIJMjMb+kY4GHTlY5prstfC6dKe5JUMRP8/CjUWJq6iV1B3P6Jm5p/WHfAUDMbo0r4Olmul5u1OW/VZ9zSRetLxXbkpX5ZWXM8jd/zYt+vqLivOWxe1jLyA0gHtlYyqNaffHgkDb6KMuQ1Sn03ZnMYz62+TleNyQVjUNFbV62zhPKbngbKHrTm1Fnqw+/geqloxm6R2aQ99VKKrtMFWVaWaBE+8GnJR4imt6HQ+px4cu0jidGi7mrY33Nj1lv1QpMucAGzuHatAXpJ82xn22jwkXuuEG81ZKK8krscxwZ269hLRHikgE2qPfKEQrD7dqDTX/tb5AhV+zxhlNIiMsk2vAVJpptlV+MFJQvbEIWileFRNDm3kU+CMhwHZdLIltKwcBK2gXITtYFrU3b/jffIwEjIR9WRDB5WWGLBOJp63C9PSTnlRntpL5oOUt22ZfyZ5jATyMhLeTIcrZCnp2gQp5iqU/lUbaW693laZbw91aSuwaTdqql9HfgVmbeOJp17b3mYAy0SviQFeIQslo27fkxv5xsSA9bFolj09gPMbMYOcxRs8mJCQ0jnKdl 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)(22082099003)(18002099003)(10067099003)(4143699003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZmhRdjQ4ZFJPTFJkTWpmZnVveVJiWHhYMmJoc2tRTUhhMkNVYlVJWmNYWVll?= =?utf-8?B?RWNSSXBHRTY5WHQ0YjdJdi9hR1FPN1BZMURXUXJDdWd1K2tnRThGM1lLaFdM?= =?utf-8?B?VG4wMFg4Z3VUOFExYzhkb0ZDM2pqNWM4SGFlMHpPOHdMT05ob3NLWHdmaHFT?= =?utf-8?B?aG5xcWlrNEhKUFYyaCsvcVFxVjVRWm80ajcrSFpYMXl1ZzBxUmtEaFRSTW5l?= =?utf-8?B?R0NwMUY4dXpxanV4OUR2WDdPaU1ZS1cwTkNqZStVUFV3ekVYeElRM3pKQjlw?= =?utf-8?B?Uy95QkQ1bjcvdzRiSXdXNU82Z3AvS28xZFQyVW5TTlMwMlhaRWlQNGtFNHRM?= =?utf-8?B?QWpzcUorY2FMZ3RiSnRtQzFqMDFtVnB1bW9aaUNjTmhtYkgzMVFaRlp4V0ZP?= =?utf-8?B?UktCUytTL1pLaE9qTTdrOGxSSytsZUpUMGxUUDlnR1pXOTJZK2NzN3lDczkw?= =?utf-8?B?d1Q5WmJBNFpiTTdkU2VwamdOMXo4RGdWN2JaU0RNUWl0WlVLRmVTNkkxRnQz?= =?utf-8?B?YTYwd0VpRWxXT3dVanRXY3djbU8vaFY2QTRnQVorTnRFemkrWVluaWlBSHNY?= =?utf-8?B?SnpnM2duR2hEMytlQW11VEhsalpwbnJaemFmYS9GNXExTFdhNitPcFVoUTBS?= =?utf-8?B?TGpROGtjbnppT0J1ajBZNTdTY3dMdW9jY2ZERmsyOGp1ZlZCTEpqMmxOWmUw?= =?utf-8?B?T1ExVXVRYm9uUklDVDhhSUpDOFQwbkk2ZmtUZGd0aHZFNzFVc1JWdEZURTFB?= =?utf-8?B?Q1hyakpmYjY0S25ZU0pVa016eE9ZRStBQ0J4b1Ezclo5VHQ5NFBtdnh1Nys0?= =?utf-8?B?TDBZbFIrZElCcDdOaVpNdE1KeldoYjRDck53WUxzUDdHWmI3NEVsZjl1ZHJx?= =?utf-8?B?dDFTejVMSVg5Smt3ZUJZVG05aHRuKyt4TXd2MG1MSEp5OFg3MEFmS3cwUjFa?= =?utf-8?B?NWNSa25XYlowLzhUR3ZBcURyTmJ6bTYrSlBEOGQ4ZDRIVGZnZy9PdVViNXIx?= =?utf-8?B?RE1OZGkwSnVIalo3a2pOckw1RXFPY1dOaWNqUEE4L1RMTGdhbk1tSjlSTGhR?= =?utf-8?B?VXcrcWVjZEllUzlyTC9rVzRPSnY1L3c1MlJnbUtYZVZsUG5BcGEvQ1JjdjRt?= =?utf-8?B?MkpwcE5SQUdUVjh0WmRHdzBBVjN3ZVJveUFrZFF0aFMydnhPKzJLclY0TFVV?= =?utf-8?B?TnJNVmxpZ2RDcGlXOWZQdVhyQzQyQ2RiMEc3R3NMVWtBN1VQM3lVcGh1TTBw?= =?utf-8?B?MS9tZTNBL25MU2NJcGtHdHMrbkoxeFBuMzltOTR5MmpmeDZPaVFIbEQwWkdU?= =?utf-8?B?SWRxdWVIZUNwSzJZUEZvaEpDSVJvdytSU2p4NWZWRk0xYk5HTWxDa2gvNmVx?= =?utf-8?B?WW5BZVArdUg5a0h1VEw0disyblRuMTN6R0xISGdTNjIyeU1LRmJDV2M5SFBV?= =?utf-8?B?clBFOXRFcVdXU2N6ZXo5ZmpVdzQ0ZVpndkxlZkIwQTJnM1psVkh6d0FtUzRC?= =?utf-8?B?YmsrbFhlNHFXOVM5a05JL3FJZXZqWndOaWQwSTBJUEZqRk5od0o3STlFOVVS?= =?utf-8?B?U1VpdEttcjVOYVBkU2FsUGpScFByNEFXNDMrMXBBVjIyRnRZYklOZzJSaHdQ?= =?utf-8?B?MnM5ditJeko1R2FQN21FejVacVVxeGpVT0tYS3JBcHUwSFFoUC9MRVg0SXRO?= =?utf-8?B?UUlldlBPczJoZVBlUGdjU1ZXK1BSUnVMTi9YU29iR3Nlbmd6d1BOajVETUxT?= =?utf-8?B?Q1EwTTlNQk9jU0VhcWFtOURxRnFpM0JaTUhyYmR5T3YrRXRtNnZ5K0xCb3dv?= =?utf-8?B?UTVPUGdOaEZuUFlJUlJ0bXFRaFZ5aUNnUmNCNGRxL0pFNDRIaWFkQk5zU1Qr?= =?utf-8?B?M2phcGg0YjFtTkNpTWVEMXJxSDhId2plNHZnYW1Ma3hEZHZTTGlleFdSTVgw?= =?utf-8?B?SzM3OVJJMDFFRDdtQWtGaytrWmh2WFVJdHFnZkxWbWlQaWtjYys2Q0t0N1ZV?= =?utf-8?B?QUFudi95SFAvZ2RHTGxOakR2RlpzRklOeWFIbDh2bm1HYXFaaGN0YkhzSVBX?= =?utf-8?B?b0lUR0wzWnA1SXNpTHFZT3kwb24zMFZXTkV2M0NXU1lXRXdPUDgwWjJPdGVO?= =?utf-8?B?TUQyVjBBSnVHYmlPVThzYitBTm5VOXlJdkp4L013Q2xqazlkYTFZdzBVQlg0?= =?utf-8?B?ampmNW45RmplbXlKQ3BqWllVZkJQT0tHQkhBK1JnWUN1YWVyVlhwaS9Qb0Nm?= =?utf-8?B?RWtnSXM5QlFaLy9zTlN6YU9kZjdRdjh0Rit2N1JLUWc1bDM0cDdvbWtmTytS?= =?utf-8?B?blVTbWs3dGJoSW9qMjRwb09sOWpjRDZyOUE1TU80eno1d2lWZ0NMZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4528f9db-e39a-4f9b-0160-08df261986b0 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 15:25:18.6840 (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: gs65yJiEW6eacHU3/1V2B3ZOiAmYQBLmEvKWraf+YA+X+yegj3KnwPUmSQZvNVfyYFNbwPhfnflfkH3Y0US8h8ZCJP9IjyYBo06/NW4DXd0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB998611 X-purgate-ID: tlsNG-16d1c6/1791559525-F687577B-4494D9E3/0/0 X-purgate-type: clean X-purgate-size: 317 On 02/10/2026 11:52 am, Kevin Lampis wrote: >> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=5ec86c22b4b3f26eab0fe9af4cbd0f90d315d820 > I'm sorry for missing that, I should have rebased. Yes, I had to take this patch together with the first one in order to untangle the XenServer patchqueue. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 09 15:37:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 15:37:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444509.1661337 (Exim 4.92) (envelope-from ) id 1xFCew-0008CR-Gh; Fri, 09 Oct 2026 15:37:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444509.1661337; Fri, 09 Oct 2026 15: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 1xFCew-0008CK-CS; Fri, 09 Oct 2026 15:37:22 +0000 Received: by outflank-mailman (input) for mailman id 1444509; Fri, 09 Oct 2026 15:37:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFCev-0008CE-50 for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:37:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFCeu-002GpV-IP for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 17:37:20 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac90a04-bab6-0a2a0a5309dd-0a2a4506a652-20 for ; Fri, 09 Oct 2026 17:37:20 +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 6ac90a30-195a-0a2a45060019-a237832f9a9c-3 for ; Fri, 09 Oct 2026 17:37:20 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 64A4F4EE0211; Fri, 9 Oct 2026 17:37: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; 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=1791560240; b=cW2mQL+CBni6hwK0hTJFX4cJCOl9UydalDxkk5t1l81qPzPKt8OCHDoETgbW+22hmZHX R57wtoS+L/Z2L/O04cT3uWLpO0fMFZK2dgBkwIeJwCwej5pBSQAuPAzKxingbStekACjB wpVkpAGNH4waGF5phGPTpQHE/azt00SKlEA0J2f2UK84bf91VYIuIgRhiLnbMwykN7u9G efNAtLFNjZioTaJtnXcJNnpLdjyxDa3FpMbd36Wnog5KV8qAKUAYtQD/zxDziQpm6pUR1 PesnRQKDAFPVTUILAGpKEFkp2TjcZa6ceFxy93y5I+XEfoSPGEHZW9/zyd7BIDlzDNIY1 62qX1Y2m/NhSJO0X/S0e/1if05S2BuNinPlu0X8jr7KLuzNRLmu5kCFf+JuLCT6K/2HPf xJSyHbf8sTfQSSoOx+tt1g9GbUagcCbetFWo6zDiikCkYn7TksiAN3HgGKOiXPq7w9r58 DKWTyL9/GY2sRDc52kibIZ0Icptez8DKMBtMbwn8WgaWxXiezp4GUeZlsbGyVVa8TeHek lTEBHJYZk3e1mhjVrEUfW2NxEZxV+A9DHplyx8C1a9VI1ki9Fv9fxrfmTyrohhOXJPOHt d9oNAGD40UxaqMq98UnIrA8GWhv0LSz2Gs+P0c1nxsmELdj0Ze8H34kh3JPcjHs= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1791560240; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=wnQK4qWyR832CxicqxWHinwbzaeqLnPL4WpG+H3T6YQ=; b=5EeF8JHZ/Oze/amMmnMH6q8yLDYPFYeQD/nvvRX4SAZk6D/jYbY7wGXRVMPCjAQGFjIF 6W0gz860hJ7ilXo4Ssztub4nFNwQA2Nb6FKfvP7aZ/rgtPNZukPY4NEYNwqmx00QT8mEQ 4VSnfGhBT2ji/0EXZM4VakoYsdkyYArkG+0eAkXcj+dBlKBBkzjrQXrOe2ZQKdIeJdlxv 3XknLJX1e2xbtXCjWA/84c8RuOnSSogKXMdV2ub2SRQ6ou5kJ8x09kKibeSlRPDXf3mL6 JF0f8YntWFeWFE9b1arPymKo9dudYomcDULJ3X3u231kz59xaJzOCa8XMbCuGk1w/8H/n WKax7K06k+brAqmOXNrhOE15oiIn/EKvBj1tXnmBZ0OTl64QRwwLD4bu0u3nZNWPMGuXv 34JefHDgajirvz9T6pVQua8AIajt5e/itTZRqxFRA/3i8G4UkpZMmrcAtQdgUq+WtJAld 5H40WMCe9FHJC7r7+sEzlWZBB++YcfjaWaLirtFGNYWBjBQ1jdECOF/1ltx+UDN4/Kwdm L7w9o3UIzr+8tV0MmFtSqR9EkyyanJnnn+85x/cvGFnPyMSh4zA40AKyWw2pS+8LuNZWz Ol3WFHaWhNIR9ZqZm4Loe3WupQeIo+SOtznKyTq7zup3ZNmgqrMRNbydt+VpnQE= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Fri, 09 Oct 2026 17:37:19 +0200 From: Nicola Vetrini To: Dmytro Prokopchuk1 Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation In-Reply-To: References: Message-ID: <5b5cccc8bbbc4c87fc99427eb4c1c413@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/1791560240-F687577B-5FD8B61F/0/0 X-purgate-type: clean X-purgate-size: 6049 On 2026-10-05 20:56, Dmytro Prokopchuk1 wrote: > The R11.1 safe cast only matched void noreturn (*)(void *). Accept any > noreturn function pointer converted to a compatible function pointer. > canonical() covers typeof destinations, and compatible_deep_unqualified > keeps the parameter and return types aligned. > > Signed-off-by: Dmytro Prokopchuk > --- > > This patch tries to cover both of these: > > 1. eclair: widen R11.1 noreturn cast deviation > https://patchew.org/Xen/c6632dd805a119aca54b9d1ae2eea68ef9c1334c.1790674358.git.dmytro._5Fprokopchuk1@epam.com/ > > 2. Eclair: relax "noreturn" function-pointer conversion deviation > https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com/4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com/ > > Test CI pipeline: > https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2914802667 > > The only one Rule11.1 violation remains, which is covered by this Jan's > patch: > x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() > The change itself is fine, but the aspect I'm concerned with is the following: if you have a function marked noreturn, the compiler is entitled to essentially remove any code following it, so in principle this could be the case also when invoking a function pointer (i.e. the compiler has no obligation to retain code after a call to a function pointer that is actually a noreturn function). While this in practice may not happen often (e.g., the analysis done by a compiler is probably too shallow to actually infer paths where the function pointer is only ever assigned to noreturn functions when it is called), it is still not completely true to say that the behavior is not altered by casting away noreturn. I have given in [1] my R-by to the previous form of this deviation, but I realize that this aspect should be mentioned. This is of course supported by testing and code coverage evidence that the behavior is indeed the same, or a suitable guarantee from the compiler vendor that the behavior never diverges. [1] https://gitlab.com/xen-project/hardware/xen/-/commit/b5497ad4a4a2b9a97100ca002cc82b573b198071 > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +++++---- > docs/misra/deviations.rst | 8 ++++---- > docs/misra/rules.rst | 7 ++++--- > 3 files changed, 13 insertions(+), 11 deletions(-) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl > b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 6cdb10a129..d89976a894 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -394,11 +394,12 @@ constant expressions are required.\"" > } > -doc_end > > --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void > (*)(void *)' is safe > -because the semantics of the 'noreturn' attribute do not alter the > calling convention or behavior of the resulting code." > +-doc_begin="The conversion from a noreturn function pointer to a > function pointer > +with a compatible signature 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(canonical(__function_pointer_types)))&&from(expr(skip(!syntactic(), > + ref(property(noreturn)))))&&relation(compatible_deep_unqualified)"} > -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." > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 6bcc2adf95..ed7129b8dc 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -392,10 +392,10 @@ Deviations related to MISRA C:2012 Rules: > - Tagged as `safe` for ECLAIR. > > * - R11.1 > - - 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, parameters > handling remain > - consistent. > + - The conversion from a noreturn function pointer to a function > pointer > + with a compatible signature is safe because the semantics of > the > + 'noreturn' attribute do not alter the calling convention or > behavior > + of the resulting code. > - Tagged as `safe` for ECLAIR. > > * - R11.2 > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index a59cf1782e..bd288bba29 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -435,9 +435,10 @@ maintainers if you want to suggest a change. > and any other type > - 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. > + and void* are permitted. Conversions from a noreturn function > pointer > + to a function pointer with a compatible signature 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 Fri Oct 09 15:38:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 15:38:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444512.1661346 (Exim 4.92) (envelope-from ) id 1xFCgF-0000MS-Q7; Fri, 09 Oct 2026 15:38:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444512.1661346; Fri, 09 Oct 2026 15:38: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 1xFCgF-0000MK-MJ; Fri, 09 Oct 2026 15:38:43 +0000 Received: by outflank-mailman (input) for mailman id 1444512; Fri, 09 Oct 2026 15:38:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFCgE-0000L9-2z for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:38:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFCgD-0036Rf-1o for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 17:38:41 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac90a6d-2eae-0a2a0a5409dd-0a2a45029ea6-20 for ; Fri, 09 Oct 2026 17:38:40 +0200 Received: from [52.101.52.44] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac90a7f-6ca4-0a2a45020019-3465342c644e-3 for ; Fri, 09 Oct 2026 17:38:40 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB6675.namprd03.prod.outlook.com (2603:10b6:a03:38d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Fri, 9 Oct 2026 15:38: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.0496.015; Fri, 9 Oct 2026 15:38: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=ZNU4QY5OGJLN6b3GjGBS+0kjBSh6TEZ6QTj7DK3THx6ihGeuDrQcQXJRSejpfp6tNXJ3EFrrEbUyjrXF8R2TMw7A3fJIgsURktDOx1+yeMWwGLCfSNm+BYW1CNOWeMsjv4Cy/dwdnyQfui+vEtWNUmVS02iCLtbD4Mk+sq1t7HIt8h+j0GA0nirStpIyAysIt5yuV7ElH9glxuMeyrEvHz6fRYZtvmbYV62rhoTNPvypgcScSODKhZObjI2SQYndXXnSyDHuwRad7mcMM4RhQsgyJ8SkfcT8eQPZDtynYW0DiOfP1quq37J26zYp6Diu82Jl+c6/fTlFr2Gn4jy+/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=RrIISEZ9fctREw6Ti1nPFUzin+e3reGV70y+Qxa/Yyc=; b=d4PYGUR2n8EShyL5nCqQxULXpWNgfodLCVnuI6pmtd4ohgzdJIN2QvUFzv1njtJ/PpEVTrSvoZyITtt+sN3ksHeUbwIjm87VGuxMIY9PLdkOF/qM3fqXwtUk8w6g+ljf8+IcNUuuTlO3bGU+qYoKtkK3ROgOjTonGYYobhzYqGuKtxN2m2NRjZgTzH/Kw8NtFcnkW6KRXmfuxmRD8z748uEX6TVigG29QdW0/hByY0UgzzdPKOL/IEm1HRNf408yca0YcIgFQ6Ddgx32ItZttXyPoHeeB7H5BSssfa5xlVkeuS85SwK3wOl3cEvVWyuDQtWWIw0cYTuhVjhvw2K9VA== 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=RrIISEZ9fctREw6Ti1nPFUzin+e3reGV70y+Qxa/Yyc=; b=WLIRgRW5SHC7z9vNiKv7CNuM8KDHIDktW/vHZ8FlnLrAHbS0ZmicjvXjzBC922PrnS/ftRzrSKzMwLzVDuOVmxcwY5R2HynyppfBfVQf6d49Ci/dYNRCeQmRxyeMNl6fyuX9r/W8fPZdweLclTcjNQXdo6lXOHqlhsJhLOPopCE= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4f9aabc1-2317-4587-a505-11057d4aef0c@citrix.com> Date: Fri, 9 Oct 2026 16:38:33 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, teddy.astie@vates.tech Subject: Re: [PATCH v3 2/6] x86: extend update_intpte() to support atomic get-and-update To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-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: <20261001174749.2275245-3-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0088.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bc::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_|SJ0PR03MB6675:EE_ X-MS-Office365-Filtering-Correlation-Id: 1704bbc2-c5bd-4e4a-bc91-08df261b62b5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|56012099006|4143699003|10067099003|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Y38vcPtaw5hSlohXMBmP9NbHarYfHc4paepujs6HhqN88aPtUoiYKAO5Lkutfl52i8zbwljRkd5D3cxXFoQ0HNaYtTfmqCEOdiH9HC8+wYE/QdYiegHPSmacbtQyVOxyNR2oOc+N3jDZ7NLblOX6s6HiI00hid2R2DWAMcI159nNQSuvC2wDLg8lkO6wYv+9jVT2Dxf08A6HvYasWWehkAPNTifNCk6GS2PzSUjNJVxVIx3NE6+NMu6ygBGUxwDK9i2k6blpuOqsvmKirOJ9WlfQ6fwApi1aPAml0qoLwr5N0r6GzjPoKyLCY3ZmYvA9zM2W5drBQi3neIaWMX3uQ8vk6Hg0byIz7BEWj6ZOR+VYoJfaR23hFW/f9WhaN99DMB5D0bOMZ2po+GXRlegK+j2hb5lPNgeu91tnS1CGrnRWJKK6Mpa9Yd+m5Z16RBFso0AjbRzePj7s4nvjWVs83Bwqiu6d5/dRLp5tCRmvmXo9IOKHl2v83VKvnDzmQkJGN0yuftaergLNDeRQqyhGxqUGYFQqiXLFQ46DQCt1itbrDrXPNPXi9AofktdmDvKBqZh9ycEyPRGIVIuYnjdxa05rMQrp/oLaNcfaOvaNUTXd3PLukeOWE+8N7zrsCO46qn3KczuCPlGP//F2v1jhCBJJnr3T26S4C2UARuHvc0k= 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)(4143699003)(10067099003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZkNYay80eDNNOW1kdkJhTWRVSDByNXpSQVRKZkdQUHZ5R2VtK1dvMXp4Qjl1?= =?utf-8?B?YU1kUGdTVkR1dHlia3VmdkREQ3U3di9PVkhvNWRaNkJ5YXNObldqQytRVlRG?= =?utf-8?B?VnVSdnpmOFluZytldXVDQzdMb2RTL1hTd2FwZ2dneUl2SUI2MjVyRWdiUU5k?= =?utf-8?B?dFNEWEVKS3BsSE1ZbkJ3amFHeWdLcktiSW4xenFXOUIySlVzc3RId2Q1Ykdv?= =?utf-8?B?RWF4RjM1eUZFZFc5cnB3bjI1MkZHdFhQSWk0WUF2NlVvc2dKWFF1bVpNR21o?= =?utf-8?B?T0VnVHFEUEJ3YUJYVkZ6eDFQTWYxR3NuajE4Nlp6cHJnVFhvRENqb3ZZK3pD?= =?utf-8?B?enRvclFMZTdwdHlGK0JnRkZSc0tRaEFaLzBTcnZQb1cwQis4T0ZoUWxCZ1pq?= =?utf-8?B?VnhjRWtJbmhram5JbGVjS0djUWFtVWU5c3loSkI4aUkvb3JBOHR6MFplcG4y?= =?utf-8?B?b1NDYTl2cHpIdlNCZFJUTXJyVHI4VFBEV2lnVWkxemtyYmF3QkUwK3pKd2ow?= =?utf-8?B?Nncrb2hFR21jd1RXd1dPa2trVnhJcEpjQ2g4b1hVU2ZYNGphaEY5aWZNYmkz?= =?utf-8?B?WFVBRmI3WTkvaEhETldZN2pBanVtMDFYQnAxNStiSk80S0tFb3pHUy9kTWtI?= =?utf-8?B?VWtGQWF0SkhFdGNnTXlkc093QXFFVVdVRVUvL3h0Wi9FRFIrTmkzdkZaRGxB?= =?utf-8?B?QUpmQkZtRTBmOUs5NFJxaEJ4M0VoaGsvbzdlK1BKM082ZldiZHFJR0FZK0pI?= =?utf-8?B?SzlRK3VHb0FqK2RYQkRkWThtWUdLazlNYzduNDQ0TFNqYXFITGNJK3R3Z05S?= =?utf-8?B?UDNwNUc2RXE2Yytzc3AxWjIrZWF6SEVERU1IeWxNRUQzSXBvWVErZ1BKM3Vx?= =?utf-8?B?bHhiZWRKT09PMkRTZjJMSklRQ2FlNTRwL1RCQzdveUtHazlYZ1ZpL09ncS9D?= =?utf-8?B?ZmdkUWlWMXZHcWY1WWswR1FyeFFHN0JxdCtnS1kyd2NsaWRaVlZkYjNDc0pj?= =?utf-8?B?RWRWcEZOSVh2Ri8ray8vZ1k2QThkYkxieWpjTlJtb3pwaWUrdTBqWkJhQzJp?= =?utf-8?B?VWNRMUt6NzlhcmtBdm16bStqcWN0TFViNFFYUWJ3Q3doTGN4MGp3YkI1YlRZ?= =?utf-8?B?Yy9aMWRaZUMvU1NIQUwvUlUzci9pOUt2MDNjZ0NoOXJYdW1KWnQ3UnJPWmRs?= =?utf-8?B?TjVYejZXNXgzaUtMR2JLTDNVeDVhTWdaL3NPVThsLy83cHZ1aTcvM3JGODRB?= =?utf-8?B?NEdFL2lML0FkcXMreWpSRXhzaTRDSTRwcko3N3N4Q0cxb2xqSXpDN0VxVWlh?= =?utf-8?B?TzlOcWhGeURYL01ZSE56Q1Y2RWNsQ01kaWgvRVF1c2dNUFdFQnpWdTB0eW5o?= =?utf-8?B?SCtHNlVpWEJWSjBHY016d1FYN2UwcTk0WHI0enlEd3JkUjY5U3dmUGdrTDhq?= =?utf-8?B?ZDB3MVcrd2oweFY5SGNTRFI4TkE2RXlnM3pXZVRZYW1oZWF5enZuZ2E5bE5S?= =?utf-8?B?b2dYanc4NUxkMU8zOXFOOVhWWUg1K25RK3h0SjZ0MzV1TEFzUkQ0VjRBUjJB?= =?utf-8?B?b1hJZFEyOWZYOVdzcWxoSGhYWFJ2ZENNUDRYV3V1U0dCZzRIa2dKbEhaUmw1?= =?utf-8?B?ZW1wTGV4WUMrc0JLNDFHczc1c0xFRzBuYlJ4VVRhSjJ0ZlRlUlpWWkVncmdy?= =?utf-8?B?d1AwQk95TmVEWEdJejZOb3JPMVZnUFVobnVCTFZuaDF0SVg0Sk10dmVGUzdM?= =?utf-8?B?RHp2OUE3bzBxNFlESHBQRk90ZU0xanF2RW55SW83cy9PTkZPQVZXRHhuT3ZJ?= =?utf-8?B?MDFJQS83eEVsdG5RWS9sMTlMOXBzN1Q5QUJmWGFUUE1xbWNCVDhHYnZLYTlt?= =?utf-8?B?SjJUM0ZzN2ROTmIxN25GK0xmWmF0YmgxZEJnRHBDcmpwUm5xemZZRE9VdkM1?= =?utf-8?B?TXVoNDE3QytNVTc4OWNHUmF2N2NvWm1jZVp2N0tSSCt5bTAvNlAwZStPSnFE?= =?utf-8?B?aEE1bEdqdWtQMlE5RmFabUNzOWRzSXhDQ0NjYzdNRnhUbFlMVGhqR2tEbTMr?= =?utf-8?B?SXZaVjNKbHFtT1pXSWRuemlLYzVmWitvNlBhQWljRjYrTEFGeCtnT3BKdVpj?= =?utf-8?B?UUhMeHJIaHlkYVFjTlA3c21tblY4ZXpFdkV4OTd1QjRXdFQwMUFZTE1BZUpt?= =?utf-8?B?YnpkU3pnVHVMKzVnZEFjdkRkNUVhd2JBR1BWcGNqeW50OVgwcUF6SWZTV0ND?= =?utf-8?B?bWVWQzVJZnhVZC92NEc0WWx1WnZYUmF2UmZVd0k0bENmVk1BSXZlaHlEamtC?= =?utf-8?B?RkdvOXBWb090eThva2FkT0U5M2p6NURMbUJJM3JOVVZEM1VzVm1Pdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1704bbc2-c5bd-4e4a-bc91-08df261b62b5 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 15:38:37.2627 (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: Dko8uzLZ6cPOzCQmRZZDo3iWc+K6RaUnY6cVAUL5VhkksdnBHB87iYSXjpLmpqKuJaiKXRW80uR9WPEhJuRknYEahZ8Jb0vZDGncHAZhkvo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6675 X-purgate-ID: tlsNG-720697/1791560320-309C32AC-242D0B60/0/0 X-purgate-type: clean X-purgate-size: 2960 On 01/10/2026 6:47 pm, Kevin Lampis wrote: > diff --git a/xen/arch/x86/pv/mm.h b/xen/arch/x86/pv/mm.h > index bfee0feb7b21..363db35b5fe3 100644 > --- a/xen/arch/x86/pv/mm.h > +++ b/xen/arch/x86/pv/mm.h > @@ -64,16 +64,23 @@ 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. > + * If the SWAP flag is set then does an atomic swap and returns the old PTE > + * value, otherwise returns 0. > */ > -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); > + return 0; > + } > else Not for this patch, but a little bit of follow-on work could make this a lot nicer. We really want to be using XCHG rather than CMPXCHG for SWAP, and indeed doing actually allow the optimiser room to remove the loop. However, this would require introducing paging_xchg_guest_entry().  In the shadow code, falling back to CMPXCHG is probably fine, and at least that allows the non-shadow case to avoid the loop. > #endif > { > @@ -95,17 +102,26 @@ 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) > > +/* > + * Macro that wraps UPDATE_ENTRY. > + * This version converts the return type to l{1,2,3,4}_pgentry_t > + * The return value must be used because of compiler flags. > + */ > +#define UPDATE_ENTRY_SWAP(_t ,_p ,_o ,_n ,_m ,_v , fl) \ > + _t ## e_from_intpte(UPDATE_ENTRY(_t, _p, _o, _n, _m, _v, fl)) > + I'm not sure we want this wrapper.  But see the next patch for the discussion in the context of the caller. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 09 15:40:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 15:40:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444519.1661354 (Exim 4.92) (envelope-from ) id 1xFChu-0001sf-3s; Fri, 09 Oct 2026 15:40:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444519.1661354; Fri, 09 Oct 2026 15:40: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 1xFChu-0001sW-0W; Fri, 09 Oct 2026 15:40:26 +0000 Received: by outflank-mailman (input) for mailman id 1444519; Fri, 09 Oct 2026 15:40:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFChs-0001sM-SD for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 15:40:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFChs-00GT3h-8t for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 17:40:24 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac90abd-8faa-0a2a0a5109dd-0a2a450c835e-42 for ; Fri, 09 Oct 2026 17:40:24 +0200 Received: from [40.107.162.132] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac90ae7-f479-0a2a450c0019-286ba2842f7b-3 for ; Fri, 09 Oct 2026 17:40:24 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by DBBPR03MB6795.eurprd03.prod.outlook.com (2603:10a6:10:208::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Fri, 9 Oct 2026 15:40:22 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.015; Fri, 9 Oct 2026 15:40: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=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=MougUdDwCDdCVvCIesZd+/cKJKCd5KbHmMnyiPt0jd7+jMhjBaj0R8hu1F+VLJGZZOGVX7j96H2WPHR/HQ3TszFYMmxbegfkiaaakQDIhYNxYxkVwtsutvxH9lSkBRW3Huw3KxDMvTSNhYV4+OEvbYUWI3G9J5ezb0uYCQ7jntneX24yyaG7DifyJx7lDOErehXrmd+AFFbIRCGgzM5FSsQZOwBJjr6z6Egts76VKJn6Jlq/mBqLVPL+uAIFwZRstp6WKYYOjHcjcP8JwuyGkW5p9X2WBsuy1qhsneOiRAHBIHispLq05Twjg+m4V32JF+6cUx2dR82BIwLVOfzAgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z7AkEXxkYnQf5bNggObmHFrCevrPyJMQJyi4cQp4h0I=; b=tvDVYcelTTir/Jf8Y+Uou67PbOvtr7/ZAUS0JneWXJukre3X7DBPEl6ykhPabXtGUayjp2EkeImsbYvxmHMCO/Yo7yLNHocMmQ1CIy85RSGzDmenuRSyWx4La4En87bH5y2rGGeS+pOSE8wdgVuLPY4pVAH5qcepU4Ojcuq0O0rB+eZkI3PxNPtxMr02VCt5L1k6dCC2EgojaF9InleNLG7AbmgFy1Z3ywSCTh1Z1Tn900CDEE59LrSvNnG/LLkrLmMnvQKndHle9MNZbk1fT4GYFJEzT2B6RilvOkx96H9OK9A8brnw9JaTy/7e+lkbdnoWJVx9muOqnzsbKxFdBA== 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=Z7AkEXxkYnQf5bNggObmHFrCevrPyJMQJyi4cQp4h0I=; b=TaO/Xu+W+wCVW8prLjRbWR2kH/qxG+Z3yRSnRIjFo6Z6niRzAwHeMSVE6ANn928rIADRlynIejLZFqLdjqePKYCivNdxU5jZC2XIlrqnaA6mVtpHYEKes7/I0ngC+vtmXqoa0uQkUrluXcefWSqB015G7VbYDNNRBn5yeQuZjafeNY9K1oJhAkkJyJwfb18lZAAZRJz/D/cjyw9GOCwaNdDQMcbdJsN2aP7WDrwQZRDtgGyY8XDrurckcvMlvhEQ/KTZ27BeAUq9/ye8k3cM9RMiX2Bybmv36L6Wetdc9HFQijAFFDtrgUb8dtD6qE05SrzJN5eQy3GgdM48z1Qchw== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v4 22/22] doc/arm: vIOMMU design document Thread-Topic: [PATCH v4 22/22] doc/arm: vIOMMU design document Thread-Index: AQHdVe/9FVgp3UFZEkGVTDxicRcCh7b1XRyA Date: Fri, 9 Oct 2026 15:40:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|DBBPR03MB6795:EE_ x-ms-office365-filtering-correlation-id: 6f7904dd-8124-40e7-25b3-08df261ba151 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|42112799006|38070700021|4143699003|56012099006|11063799006|10067099003|18002099003|22082099003|3023799007; x-microsoft-antispam-message-info: gJ6evktQOHYKu9QzqxCaSvGeOMnx5Gm++R3vkWuoEvg/Zj4nHOMvcjGvo26ruVokG/utTuWVJtm2zq9mcPqr72PNwJVbYykI97ftFJRusM1I++N+E4Q+AkQcE1hyIX0fLn2sd1+ljXkiu2wdqBJhipP5bIw6cA4lFqCZO3NQQsbLlCTOh9VsZGwDchr6gc2O1/Ke2L6Dq1Sd69kOfmpdOsJQ1s8d+xteQBmRVyO/+I+PSxVGczxoxlecPgLOytfu8BT0IfqSQtofQHTtBdR0n8ykGix8zvnV6a7oDTcPUnfpeCASTkduLOFJd/na93L2HN/EbiolXQSqcJmLKxfg5K8/pKRWR0wUgwkR9dflZvbxK9Ot8ehA5VoarFvONUEH8TGCqSRLORlmTj5HXd8j28+2MeiZg7uxwKIKXukkq3nqL/yEPOdW8SzX0F26yLk2ZZs8dLfFN+/te4tCdg/KI2EQS14Ci6605Dh8iLB6YWhkSh/Ok5LKLlRUtqOC93i+olpBZ4CMXLvbTqfLWz8/Xhy3i8bLtfSNyphtL1VPCkHLJDc4va9yyLtSJ8lbaCCzWGV056NdxVwoXYhx+5vOHlFW99gwXPGbwdOShhZjmAzHLqUVJW1mSavhTebvBFGJgDvTLs+2gdnzhguzDJat5jBvcR5sW1Ib8uTCR2WWyJSCagHlnOqWLKqNhv/1M2mWDiqA+GQxgVTfpLoZhA3DmNYpg3MNGu4NuP3zdcqRXQ8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(42112799006)(38070700021)(4143699003)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dDRNcFRFY1g5OGM1SVIyT3BpN1Z1ZmovSVdsczB4OTBKdUtCbWpkaE1PMENF?= =?utf-8?B?YkxIY2dGc2xWaEk4SUZFb1dkdVNBRWswcTNiOTNma0dRdG8xdlN0akxNbTBz?= =?utf-8?B?TEsxYVNJVEZBb055NllQYVNKM0FEaDRQVnJpY2xSckVyWVJQYWNNWEFveCtn?= =?utf-8?B?U096MmpNUHpKTFBpZzNOQVNHWlZKMHBzYU1NSHJoZ0t5ejAwVGxZZURxMzNH?= =?utf-8?B?QnE1cWdtT3Zwbi84eVl1SFFIZ1c4ZWdhc2VSZjFFSFZGUjhBZkpzeGNYYi8x?= =?utf-8?B?UVRtMyt3c0NTaGF0K0EwRFY0bE11Nmo0RnBuN1ZUYlE3TXZtR1VTaDJINFJk?= =?utf-8?B?Tk44aTJ4T0k2T3kzUU5tMzIzRG9GcENsclJVVXMzUTdHaUpCZjZhTnpvYkh4?= =?utf-8?B?RytNL3VTOW1ORFB1cWJGekQ3eEdiTzBNV2RzNlJUU3BML29oc2dzTDE4alM4?= =?utf-8?B?ckRrVzd6SFdzc1V1Mjh6d0tNQytwQXZRWmNwd2hwR2VDUTdtT1JLa20wNGJj?= =?utf-8?B?VmlyWGphVk01ZzNnZzRtSlpib09FaGg3d3paS2V4bk9PZzE3OGlHWG9PeHFx?= =?utf-8?B?VEQ5RCtQbmpmcHdtVEdGYTl6c1puWFZGc1pzbU9aVnZaL0w4QnJqbitOZm9k?= =?utf-8?B?SEIxNHFYWU5yaEplZzV5YmpyUnhTWCtNU3RZM1FYL3pTbzJ2Nzd3NWdPNGxC?= =?utf-8?B?d00zK245QTJTVnQ3a0h2a0JSTGxMMHBudFJEK28ya2ljRlRhakIwampmY2ZK?= =?utf-8?B?OWRGTVIzbEZYUnBtNmRrL3drVzNqUlNRRGJMTGV3L21xTys0eWU3Zk9rZ1FG?= =?utf-8?B?dXB0NTA0YjVqaWJqUzBXRGxkRzl6bnRtMk54R0NPRlFLNDBpOTE5OVpSKzNY?= =?utf-8?B?MU1wRzQxM3BRSDlHM1Y4QjAvOUZ0aHRwRnpaMzhWM3FKVklZTmRseU1DWXls?= =?utf-8?B?a0lBMGRjaVBlZGhqazArVDMyNXJ6UE1uOEk5ek10UTl4ZEhTZUVEbnZrYVZR?= =?utf-8?B?K0FPT2FzQ0trTDcvTEZDRnk2blJBNkZMZmpZazhhWmhMK2F4L3pnbDlxUjhV?= =?utf-8?B?aUZyMXpOYXJLdWFra3QxZnhCOStmSENURDFwVGRYRnFaeUg3NXE2cTg4ZkJF?= =?utf-8?B?VTdlUlhYMWV2Q0w1VFlydGpvRTgzc0lCTk9oenArK1BqMXBMbmVKbWJ1NDhB?= =?utf-8?B?dUNIeFpTV3FNekFFeFhHcVdKMGNNSEFsdjFNdkNwYkh6dFlNL2krTk8wSEhv?= =?utf-8?B?dXJpMnBOS2tTeGl5ZkdjMldCeHdwWVVHYkw3UVpDbzd5OXBpbnFrbEtrM09S?= =?utf-8?B?ejhTRFBFZURKUzRoME9uOHE1NUttT1paMUc4bWVLQS9kMDg3YXRPZHk4ZTh2?= =?utf-8?B?cTdOTVQ5bFE2a25NSmJHUWhKSjFCQ09RbWJwYldJU0NEMjlqQ3FGTCtrcXkz?= =?utf-8?B?VnRkL256UGREN1lPZmdVeHhSZFFXWHd5bGNZOEp0SmZueWl6NUNwK1ZTa0dq?= =?utf-8?B?Y0xkcDZ2L3ZyUngwR010a01UZVNkV0VMUklVTVBMTjRkb25tS21ZSGRERjY3?= =?utf-8?B?TWZSUWx5NnJScHh6bWpiVWVZNytvZnU2VnNJZ3F2MW9xRzNRWXpLdVJXVlU5?= =?utf-8?B?NGp5MXR0TG5DNTlNMnJCSXZXcXNXQ3d2cVJER1g5dG90dTZNT3hsektiNU84?= =?utf-8?B?MDFlQTBlK0FkdEQzTzJQSzBGZTM1bUN2dnhadDcrZlkxZUZGOVNRYU9zakxE?= =?utf-8?B?SktHdkpuT0JISlZ0a083SFB0a0ozM1ZuTkdrb2VmQW1sLzQ2VndRbWgzUU95?= =?utf-8?B?aFVObXRWOGgyOVdaQ0daQlhmcU1XSFdJZi83d1RzN1huNVJ3ZmJVWlpseFRM?= =?utf-8?B?b2JUTUNDRWFjMmNlRFpZcHNqWmVaNmV0U0wxSzRnN0JBZGJqTUJ2Qk45a1lN?= =?utf-8?B?dlEybVBka3o4Q1NQTXcvM1ZWdDBucTh4SmV0czl1UDhRSUxzOStkUllTUCt1?= =?utf-8?B?YnY5Yi95TGlBTnpjWnZxY0NkVGFHOWdHQ0VLNm85elVzMVVZbWtxbDdIMitm?= =?utf-8?B?cEdJWm5XZTBIUVVuWnBORW5YdGVLbG8zZ2VUQnRBRzVWeCtXTDBGOWFHcTd1?= =?utf-8?B?b25pNy8wSnhCTXgyeUJMOWFyWCt6bXRWa2RaTVlXWDNhR2I0dEtpUWprZzFZ?= =?utf-8?B?UWcxOTRLUkhldFF5a0hEZ3dLQVJKUFVmUXdvNEtuWVl0OEFyQzVxbjVlUWN5?= =?utf-8?B?Q1VDUTIvZmtoTFA3WTlCalgyK05JQVFIamk0NFBDT2xXakhDMUZaQWxxT3BZ?= =?utf-8?B?WG9yYituQWpIT2wyVXkzYUJ1d1NKbkpYRE9uQXR5b2R5amI3bWU2ZEpXYlJs?= =?utf-8?Q?P5xUpf2epO4qQc6k=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <2DABA10171F0F64FAA67495FB8A2471B@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f7904dd-8124-40e7-25b3-08df261ba151 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2026 15:40:22.1192 (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: XACtX0rIvRLaq+Ru4Gk/9h+UJyd1wzHLiZOzBTZIeU2Xw+0d72dGsQOUMu0IrrfQTCwFMD1TNJ5hWVQ5xl/qvIgvux7m6aYx+4AuHiDa/Sk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB6795 X-purgate-ID: tlsNG-d25034/1791560424-004CFA5B-83AB088A/0/0 X-purgate-type: clean X-purgate-size: 1306 SGkgTWlsYW4sDQoNCk9uIDEwLzcvMjYgMDM6MDgsIE1pbGFuIERqb2tpYyB3cm90ZToNCj4gVGhp cyBkb2N1bWVudCBvdXRsaW5lcyB0aGUgZGVzaWduIG9mIHRoZSBlbXVsYXRlZCBJT01NVSwNCj4g aW5jbHVkaW5nIHN1cHBvcnRlZCBmZWF0dXJlcywgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4g YW5kIGZ1dHVyZSBpbXByb3ZlbWVudHMuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBNaWxhbiBEam9r aWMgPG1pbGFuX2Rqb2tpY0BlcGFtLmNvbT4NCj4gLS0tDQo+ICAgZG9jcy9kZXNpZ25zL2FybS12 aW9tbXUucnN0IHwgNTAyICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPiAg IDEgZmlsZSBjaGFuZ2VkLCA1MDIgaW5zZXJ0aW9ucygrKQ0KPiAgIGNyZWF0ZSBtb2RlIDEwMDY0 NCBkb2NzL2Rlc2lnbnMvYXJtLXZpb21tdS5yc3QNCj4gDQoNClRoaXMgZmlsZSBoYXMgbWFueSB0 cmFpbGluZyB3aGl0ZXNwYWNlcy4gUGxlYXNlLCByZW1vdmUgdGhlbS4NCkUuZy46DQoNCmRvY3Mv ZGVzaWducy9hcm0tdmlvbW11LnJzdDoxMjogdHJhaWxpbmcgd2hpdGVzcGFjZS4NCitUaGUgU01N VXYzIHN1cHBvcnRzIHR3byBzdGFnZXMgb2YgdHJhbnNsYXRpb24uIEVhY2ggc3RhZ2Ugb2YgdHJh bnNsYXRpb24NCmRvY3MvZGVzaWducy9hcm0tdmlvbW11LnJzdDoxNDogdHJhaWxpbmcgd2hpdGVz cGFjZS4NCitpbmRlcGVuZGVudGx5IGVuYWJsZWQuIEFuIGluY29taW5nIGFkZHJlc3MgaXMgbG9n aWNhbGx5IHRyYW5zbGF0ZWQgZnJvbQ0KZG9jcy9kZXNpZ25zL2FybS12aW9tbXUucnN0OjE3OiB0 cmFpbGluZyB3aGl0ZXNwYWNlLg0KK3RoZSBvdXRwdXQgUEEuIFN0YWdlIDEgdHJhbnNsYXRpb24g c3VwcG9ydCBpcyByZXF1aXJlZCB0byBwcm92aWRlDQpkb2NzL2Rlc2lnbnMvYXJtLXZpb21tdS5y c3Q6MjE6IHRyYWlsaW5nIHdoaXRlc3BhY2UuDQoNCkJSLCBEbXl0cm8u From xen-devel-bounces@lists.xenproject.org Fri Oct 09 16:25:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 16:25:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444560.1661363 (Exim 4.92) (envelope-from ) id 1xFDPh-00008N-9r; Fri, 09 Oct 2026 16:25:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444560.1661363; Fri, 09 Oct 2026 16:25: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 1xFDPh-00008D-7C; Fri, 09 Oct 2026 16:25:41 +0000 Received: by outflank-mailman (input) for mailman id 1444560; Fri, 09 Oct 2026 16:25:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFDPf-000087-Ee for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 16:25:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFDPe-00FBcF-Mk for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 18:25:38 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9156e-8faa-0a2a0a5109dd-0a2a4506a990-22 for ; Fri, 09 Oct 2026 18:25:38 +0200 Received: from [40.93.198.41] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac91580-195a-0a2a45060019-285dc629f859-3 for ; Fri, 09 Oct 2026 18:25:38 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS1PR03MB7871.namprd03.prod.outlook.com (2603:10b6:8:21f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Fri, 9 Oct 2026 16:25:35 +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.0496.015; Fri, 9 Oct 2026 16:25: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=CdgJga+T/6fjcfOSkJ0sp28FJg8QCa4qAT+ncLJk4Abs5HUaauiASlZqgLCKgecPbcfzRh9OwzAgLNCtlEhTzyhOqb5nj93ztwo6DxFqP+Gi8B4gFjDYw6QZM3l/9pfLfQnbYVQ+8OPiUSPWMY5+YdZOjq44+sK+mWyrwpgMDQKx0mapPXwSPE8ZIxafuC/8DVwkDu4lUr6VILFF0F6IJjcv1DC6rJw4ngR6vAJ4eWjfgQxRiCkvM2EedAJ66ihAAA42xXezDRtoV5v4HZJhCk9lGR38AZlJJImIMW7LAIc5m1YSMr8QK+RQZMaXf37Rx5bUWGK9HKhimQoIqDKf7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lPwChnQRHX1pTxtlrfp4+rkywm9j/I8bIOW075bZYgI=; b=WqXa1kkJ0xuMbk6hEmZhLc7FiPM8NQ1ehIJLFMYqhrzaVByup6bIfDrMewXiG+Hu+P4FJr0o4pozuzICB0eajdZESldy5pC/p9YIOf5l545pzEP+9dFaomF8C1Ri5vtyJKOuy4u1VKMjf7SvA0NFwz4d0c88d41nx7eek+mnD6w9qXfV2Homx/Fn6jo/M/HrYe7DzrHvLz9S+vdHRbssT7GqfcF//W4DH+HiblR0TFNCKB7qi+5rE+8Mf3djRXK1NAsfFGIaVjoitKTHDBoXLnErnWsCdevzR4iDwAB2DPkVjbt++VqitB/mypuBzqimDiT8Em+nKLV9xPoOBiH/Vw== 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=lPwChnQRHX1pTxtlrfp4+rkywm9j/I8bIOW075bZYgI=; b=plyqeIF2R7RZy1fIfBD3mcunBNtOBkcPt7ytiQYOi4ge5HnTJQsn6Bnm12K0rgNlInrEjVCqP8E7opUt70c6Io/9N/qjf3IC++wafXUZa/AFhtWT4EJGPUgyWtBovD12Vwg5sC+rdD9XkTqVSXCmxbLQuC/I9KISM/CiqGqiciA= 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, 9 Oct 2026 17:25:32 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, teddy.astie@vates.tech Subject: Re: [PATCH v3 3/6] x86: extend mod_l*_entry() to optionally return the old PTE value To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-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: <20261001174749.2275245-4-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0505.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:272::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_|DS1PR03MB7871:EE_ X-MS-Office365-Filtering-Correlation-Id: 122a7018-a593-490d-7950-08df2621f272 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|56012099006|4143699003|10067099003|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: XlG2rNSuQwrHP+2UMCmYRB5rjVI/T50dsvMBY4MJVqpO7gA6hrz9jqkJJ0CTQfUmP9w4++lejDoceyjHXNKpnpvFqKFrUFNEWcGtNahjMWFlbvvq2FCOuggJ2HwF5llErixavI8zzoWTQp9XrtzoSVgJYQF8J9d32CXYsUg+MbjLNW6luDlWuPK9K11VK5QE3UREAkqC/ODRe6+h/jkqkP44032ptMGIv7k9R9MES9OkWdjHZa2PuFx6ILsHU+zu2DOWQqZlolRyPwADlebkJTvZ5s5nATLG8/v5xvzONAHwo+Y3FA+eldUkGW7pSdJvUcsKYxqClGxAFf+b9ZjZNfPTbTFNWevO2YlgSu8D6PNVLAd4daQBq46e+h/cwGbnt4DY9YpvBnr0cxUgV/M+m54Y77cCjuwyDDFBKXX2+TfzOPWx/u9UfOCQkeOX99Hb5ZQsSJirqVxUqBjwMbB2TiSXKl6OkafqfDr93/tmLIjGBKRjfbJrqBxepL2LlKIKPGIOWGlVaVeKqUu5qaHwj6tVJL9f9YuqjFjOICyY7ncpMePJJnO9ltq2FKyNU0soxBVpHVBevqeahcD8ZW/lhmGLVoW1k5RkHJmd7y+g3hV8QZR4HN2qQvzi+DkcVPbyIqcNv+n1c5q8LebCV5PmYQqO9MPYQ1x+d3k7kjOIsF4= 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)(23010399003)(376014)(56012099006)(4143699003)(10067099003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L1VubFF0SFBUWDJBakQ2c0RkNTZsNkVFVzIwanJwWEVoTk1IUnBIWmtidGNC?= =?utf-8?B?OUpaeDZ0OUhkTnlOdGRtQWVVRWtFNTBIZTh1T1ZFNnkxL3Q3U2lEYzIwb2w3?= =?utf-8?B?Y1dzQXBNdnIwekdFRThUeUJHSUFkdXhPWWdFQkMzbDR6VmcwdWNHUjN2T1FF?= =?utf-8?B?WVJHb21rSFlxZUR2elJBZ2U4MGNYSWtFSlhZM3I0YXZ5ckFaOC9mUEJrU1ZG?= =?utf-8?B?K1FINkduV3p5MFZ0UzRPbFBBK2JWZlFFNEFKb3F2bjlkeHVjbjJDY0tNcDU1?= =?utf-8?B?bFRGaVp4QzRwby92eWVscFBuOEVPditMOWUzVHhhZ3JDQXkxWnJiazFqbGVO?= =?utf-8?B?SWJTUmNRdE5LczE5ZUJvd05FSTExeVBIaEtZVFpmWUF3V2swN1d5dy9iS2t5?= =?utf-8?B?eFc4dU5uam1GKzNlOTBNSzQzNys4bWY5aUZxZzBkNzBOb3Rqd1Fpb0RUWWdQ?= =?utf-8?B?TGptejNnY3lvSWxLZC9oQnN0MnpTY2krNFk0WW5tbm1ZL3phT2ErdVBGbi9k?= =?utf-8?B?U3gvTmpHYnBlZFBLMXppdmduUE01Y3I2QmV6V0xIQzErWEZzc29GVUpPS2Z3?= =?utf-8?B?VWF4ajVBSm1OWWQwaEpKRUFWRTlpOENaRGRUZXZrVHhhL3NXNnNXb1FYZDhG?= =?utf-8?B?N0RNQVlRamxKTytKaFZqbXBvWGcydmxodzcyZ1o3VDVXSUJmSkZMR2NHbTdo?= =?utf-8?B?eE11QXYwczFXRTBCUTVDUm4rb0lwRFhPQnRHRHYvRHl0UStmb2lkOHZKZldj?= =?utf-8?B?VFhoTnc0UWw2MjV6NElEQ3dqTmJ2cE1FMGphTUtOMTRQOUdEb1g0UlRXY2tN?= =?utf-8?B?NUxlbzJleWZYQWowbDlSaEdEVEhnU3JPRzAvM1I2R1FaQXloSlJVK2w0U042?= =?utf-8?B?TnFZRTFKZEVmRFpYSEk5akhpOEhSWUF4dG5uVmgrWlpISnNsMU95MUpUaFR0?= =?utf-8?B?LzNzN2w3dFBPb0lIUEtob09iN3R0cmI2eXNobnNVcVF5MVJZNDgyWWw4MVFu?= =?utf-8?B?cmNhRlRCdGJEc1ZJbld1VkJzZXpSR2JzYll2Mm9JZkZ4VWN4WkNVajczRWxa?= =?utf-8?B?UGNuaHBadjhDRnYzYUczemVrOGYvM3p6Uzh1S0xQMjR5eGJqRlB1anRsSkh4?= =?utf-8?B?bm13SVlFaWFDNXQ1blJDQ1pEdS8vandYRUZFSDlsRjBMa05yclllKzdjM0FI?= =?utf-8?B?Y1A4d2l4cTZ6dkdSblhOblk1b0c3MkFNSGVPUVp2NUVyQy9ZQk5tS3d1dGdX?= =?utf-8?B?SFNNWUJpVTFCTFFmQmFYeDdweWVCNVI0MDRVQzl1SzVRMHZYcStwSHMzbVps?= =?utf-8?B?dVlVeWFCMXZ2NXB2dWp5aEM4VGVWb0s5L29ZMXlBNHM3UHQxSUs1SDlHQU5w?= =?utf-8?B?eXZLU2l6RWhpdlpGS1U0Tk9MbEYraXM4dmZ0WTY1TG9HUUdteE40NkxiK04z?= =?utf-8?B?WUp5Z3Z1RE4rQUQzUXFRZTkzVjM1U01TS1MvL3Raam9WemhjaHNwbE5vMHhH?= =?utf-8?B?Q2VhSzZxOUdKZEhENGVCT1RXWVpuWXQ2Smt4a1JSMFR0L2U3NjFYcjQ1T1J2?= =?utf-8?B?S0QyQ2xzT0RrMDdPZkszWXJ1enpuNldzN0Zra1RjUFVDSEIrR0FGS096K081?= =?utf-8?B?dmJaRXVBd2JWcHM5WjMwUUJSMUJiNnJUMW54ME1ZTEV0ZEdJOWhNU0ZweEhN?= =?utf-8?B?WEllN3ZVRTl1Wkx1OFI0T0NFVWRnTkh1L0VYRHdyUnR3SmxYWkY2STM4QXZB?= =?utf-8?B?ZVBuVlY2VTdnWjl3anVzZWRyRUxmbDI0OGhwUGlyYTVBRzY1dGNlVGVOazJx?= =?utf-8?B?ZFE0U2pJbnJTQTlZWElheE5xeXc0VzBRM2xEVmV1eEVMUlNwQVc1ZW1PZ3hO?= =?utf-8?B?Rm1scjNnWjU2Ykx5cFlLYjB0bTNwOW1TQ2haM3ZDWmNvUEhSeEk4dlRDQlBK?= =?utf-8?B?TWRQbG1uSmJCYXZORXFtaU9pUjJ3cUlOWTlKeDFZd1cyOHhRRzdlVkxmZDND?= =?utf-8?B?YzBYTHNJek5SYkhzWFAzTDIzcEh6RjNiRm1QZzIrM2plWkdxWTczRUZ5cFN2?= =?utf-8?B?YmhjcHE4RWdjYjRjU0FGMEtHMkFUdzRQWVZrNTlYYmhoVlBDd0w3c0FuUXJr?= =?utf-8?B?MnFST0xCc2EwZkxuZFgwa29ybS94SjQyblJnOHU2L0RyWnpPNm94VHVpaUpX?= =?utf-8?B?anRhS0tjN1FuSytES25SbFk4Z2FBZjE3dEJjdzdCdnh0WmNWY09obGJLT0Qz?= =?utf-8?B?WXg3S1o4bVZlbVRwODNQbk1jTEZrbFFkTi80cnBvVC9zeUJCeEk2RzhYRjYy?= =?utf-8?B?SDVpdzlham1tNEhWT0dQbmFDT1UySmlVdEhoMm5nYXBERkpOUjRsUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 122a7018-a593-490d-7950-08df2621f272 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 16:25:35.4929 (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: g0LzCRRUCUuIjJOjg0rPl4uAoTt8V0Q8nxhe8HOB9RjMSJvlsclA8McP/JnKRG+N6UvGEiBx8nflw2JLDBoJze46XJ095jhqAkK3zABSa9k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS1PR03MB7871 X-purgate-ID: tlsNG-16d1c6/1791563138-F647377B-E94E442A/0/0 X-purgate-type: clean X-purgate-size: 3692 On 01/10/2026 6:47 pm, Kevin Lampis wrote: > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index 1ddb8b71469a..535a62139cad 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -2154,7 +2154,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; > @@ -2215,7 +2216,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); > + if ( ol1e_out ) > + *ol1e_out = UPDATE_ENTRY_SWAP(l1, pl1e, ol1e, nl1e, gl1mfn, > + pt_vcpu, update_flags); > + else > + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); > + This is a reoccurring pattern.   Also, from the subsequent patch, this is the caller's reoccuring pattern: > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index > 535a62139cad..a2d05d6c7113 100644 --- a/xen/arch/x86/mm.c +++ > b/xen/arch/x86/mm.c @@ -4111,6 +4111,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; @@ -4172,10 +4173,27 @@ long do_mmu_update( update_flags = > PTE_UPDATE_PRESERVE_AD; else if ( cmd == MMU_PT_UPDATE_NO_TRANSLATE ) > update_flags = PTE_UPDATE_NO_TRANSLATE; + else if ( cmd == > MMU_PT_UPDATE_SWAP ) + update_flags = PTE_UPDATE_SWAP; switch ( > page->u.inuse.type_info & PGT_type_mask ) { case PGT_l1_page_table: + > if ( cmd == MMU_PT_UPDATE_SWAP ) + { + l1_pgentry_t ol1e; + 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; Both are rather intractable as far as logic goes.   We've got MMU_PT_UPDATE_SWAP setting flags=PTE_UPDATE_SWAP which both gets passed in flags and expressed through the NULL-ness of of the ol?e_out pointer, which then choses UPDATE_ENTRY() or UPDATE_ENTRY_SWAP(). The only thing UPDATE_ENTRY_SWAP() is doing is wrapping the return intpte_t into a typesafe variant.  It doesn't play with PTE_UPDATE_SWAP, so the name is misleading.  It's unfortunate that we can't wrap UPDATE_ENTRY(), but I think we'll just have to live with that. I think the logic in mod_l?_entry() wants to be along these lines:     intpte_t old = UPDATE_ENTRY(...);     if ( ol1e_out )         *ol1e_out = l1e_from_intpte(old); and the logic in do_mmu_update() wants to be along these lines:     {         l1_pgentry_t ol1e;         rc = mod_l1_entry(..., &ol1e);         if ( !rc && cmd == MMU_PT_UPDATE_SWAP )             ...         break;     } I think this gets us the same behaviour as before, while keeping the same (single) calls to mod_l?_entry() and UPDATE_ENTRY(). ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 09 17:24:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 17:24:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444600.1661373 (Exim 4.92) (envelope-from ) id 1xFEKm-0000Ag-ES; Fri, 09 Oct 2026 17:24:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444600.1661373; Fri, 09 Oct 2026 17: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 1xFEKm-0000AZ-Az; Fri, 09 Oct 2026 17:24:40 +0000 Received: by outflank-mailman (input) for mailman id 1444600; Fri, 09 Oct 2026 17:24:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFEKl-0000AT-4J for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 17:24:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFEKk-009OPC-0p for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 19:24:38 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac92344-e002-0a2a0a5209dd-0a2a4503ba3e-18 for ; Fri, 09 Oct 2026 19:24:37 +0200 Received: from [52.101.72.77] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac92355-fae8-0a2a45030019-3465484dfd52-4 for ; Fri, 09 Oct 2026 19:24:37 +0200 Received: from PAXPR03MB7531.eurprd03.prod.outlook.com (2603:10a6:102:1da::11) by PA4PR03MB7373.eurprd03.prod.outlook.com (2603:10a6:102:108::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.16; Fri, 9 Oct 2026 17:24:36 +0000 Received: from PAXPR03MB7531.eurprd03.prod.outlook.com ([fe80::77bc:127a:5664:10e]) by PAXPR03MB7531.eurprd03.prod.outlook.com ([fe80::77bc:127a:5664:10e%3]) with mapi id 15.21.0496.015; Fri, 9 Oct 2026 17:24: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=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=UEkOkw0xGsMy9OWLBn5k1DptzmUK0R6Pu/gzlgJCMn7tXeMQNCi1HLuOjO1XB28GgxRciq6xIugOlhOzhbKRfNdquzHMyxdbYbzeAb5qeprq3xTn2/ds9BP4eGHIWWzDfpt0fZ14Y9IDps7vK1HHP4ETs8AKBoj6yYpAigGShSHPkaWi+qLHyqg1u30q9zmsuE40fSbiR0yp1J9nWMzl7a7bIG7luqWRUAgevc+jq1MmD0x/qHvMS4ZHdMkt/pyaw+wXwRGxhX7QD+06ctBHwR9e8Qh1TqlqsAzVCcWmeznetMttOFcO1quorBsvqb0/PvirnvOFw0ao7RzlRBNohw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/kG0Nrink/VIjzZVh3uGkOeZoaYXZYdL5u63rSihIUQ=; b=wF8apXMnHQWyt9c4ezDKtBvru8KQCtt4DIlU6s5xmUkURjjAfTBj+4Fr7Krbkxv7qRtkYOJjmiQtLZiuEX8rUD/R7TnLfHsOg0YvPYpi+m/hMrI5tkRSMF8av19O5CBXrbl6ttFbnoPsG7qPdaCKpjJiCMJNAOelBMfcXdG8O3hmH4eYcuY0kKA1cYLde7uPJFWZIZ1yQkw54TnrEy+ApThbKTXrOQyqHijP4CD8PrekNqpCyKFUHJtukXeCht+3ngvDiej05wAu778q1SOVmSf3CfZ+RagB1rNGTRqmcAzMgBzQHjIG9YHmWlGZBgnYVHSm3NjJ2/o/gb7molFk7Q== 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=/kG0Nrink/VIjzZVh3uGkOeZoaYXZYdL5u63rSihIUQ=; b=kLUKMMwOr9BeVnTgT4CVA0TRkxASMsKhKhssQBbo/uf6OYIyw65WEs4pMF3paGWu8Ko4bNyvdGmwQwARUbFkYL+Nz87x62EdFilmqxymWFIf4gBam6VrFutae153fDJwxklyCpT9KeVWvpTMT9F5O76A+cCANnZJxsgy2Uz6SYO2D+KVGCUVIXtNoCe4ghikj6emXE5mcwVaq3de5ZRkXHr657Ecv4P/fTHkmoiR252f+jRHErZNdeLWLo3+sfSS1oOn6067I5dCBasxEs8Qk/oLkLkXG0esKR6s6XtaZ4QXUsZvTMRuNxj9QuIyzYeAHKLac1BrgfQQOwhbxEGhbg== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH 10/19] arm/its: Keep track of BASER regs Thread-Topic: [RFC PATCH 10/19] arm/its: Keep track of BASER regs Thread-Index: AQHclF+MPQ/oNp2C80CWhnrkrdvP0rb2/VyA Date: Fri, 9 Oct 2026 17:24:35 +0000 Message-ID: <4965f6c4-0c37-4f55-9e10-72990ba40090@epam.com> References: In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: PAXPR03MB7531:EE_|PA4PR03MB7373:EE_ x-ms-office365-filtering-correlation-id: 8d32759b-7390-4341-4ff9-08df262a30e3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|42112799006|23010399003|38070700021|56012099006|10067099003|4143699003|11063799006|18002099003|22082099003; x-microsoft-antispam-message-info: iBLQyyKH0dMXnAUfZqAks6DMtt7cCYFDyZuQZuE1mItV5OJQ0VTU8BmBKqlbKGPatGQmJn5QjqT2ZyfZFz83lv6QA5NfDINmwDgkd3VYRjT4i/a55uHwPhFKKXJcDS8a8UGc23W5AW9KwS4avQsVu2D8S6JYPNsYCDBYZGG5O+h2hnJwl9g46PgbZthDsEpqe3EBgti2B4xuyyWdZ7vrGxblRXpIXxAQjQ7w0mTH2DtQA966C6xg90FCnnjXUShbzKxNmlwTtub2m08FZdRTYRP0otAnc4f/upMSqkOHCroToeiFrjY1OqZSBMoWQesIgNZG+cBOYfZmrX4oBR2VUA/Y+6iwZ+OxdudF7dSBJowjAvPMPzB/GW1KI7JkkGkdYM53/N4ARPBjyvRAICYwm+26zBEJ8aoyS4yqy3rL9lr+ugh18CXKxxLgw1N5DsJmdf8P9g1hR5OtpDU0vayCmWDJ9N/mBXt6ipusnFxoQuWaFZfLag+MNMEnMtNRgnFGIh3BxwExWsyYWzVPfRNSfAta/rLxAlrVZNu1/4/VJ/yzkWmc1Aj6oE/CWqgLF9EqZBUGuuIBUxOo4jNX1uTCRmVtglQginybWmDry3TCySbU+aBgFQdcolkXWcoTWVgzDbxVsbGLUBJ7UnmdtCIJ88grLug5TN8c1wFIbyCOfzhPPmJnN+klcYxZm/oswWrG7FhCoJZ8YcK8nJ364KYlfBAPuNjQV5BsMgpecAbLBYc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAXPR03MB7531.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(42112799006)(23010399003)(38070700021)(56012099006)(10067099003)(4143699003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cTBFZ1hsNEtJblpaMGgybWpaNEVlcksxVWswZ09TTTZJMzJZbVE4WEdOSW5w?= =?utf-8?B?djY4MFp4QXBUSDFnTyszTkFFcWxyV2laVDZiR0dHTDJzc1Zha2w0RHZhNlF4?= =?utf-8?B?VUtnaWlBVHpLTmIxVjJPdHBqVUl6eFYwU25TT2F0WlBscit3Tzk3ZlhXQS9X?= =?utf-8?B?Mmw5Qmg3b293cXBpeGhrZjhTU0lZc1VuNkE2M2NHV0lSTjZMbTR3aUpsL1hT?= =?utf-8?B?MVROMFl5NDhuRHpqZkdWcVRFM3M3Wlg3eTBLUXNrM0piYmJhUGQybW5BNDZh?= =?utf-8?B?K20xUW5IVUpVbEY3NC9xTGc1cjNwalRrR05aa1pONkJ2SUVPTGlHUlpSY0hY?= =?utf-8?B?WkMzTG81K3lVaFBRelp0U0VUREsxdDArM280QXRKVG1TampIbG8wbkFnbVZs?= =?utf-8?B?VWFJdWx2MGk1Nk1odnZEUDRjTEVDS0dUaFlaMjdnT2pRc1dSS0pUMC90MVlM?= =?utf-8?B?azBOZWRJT3JWZnBYOHoyNHBGYUVOcWpubjBQRS9IbzBxRnRwclZha2ZkVDZB?= =?utf-8?B?MkFNZUlvU1hhaW8xUTJFeUhaKzFXQmdQcG9WNVhEN3p6bjdlWE9ET0VmZG9U?= =?utf-8?B?OWdkK3ozb0c2dkkzOHJ3eEo1QUNsT1k3Nmt2ekVyQ1dmMmxUZkVyOTE4c3Ex?= =?utf-8?B?bUZVdU5TVHY1VUl6Nm1ia2FBVDQwZE1VMGpVaEhBaExXZVN4WkxXT0t4ZVly?= =?utf-8?B?VHNGSXB5bnhYd01lSDNaV3FycTdXRU1zUjdOTVJDU1A1WXpqQldTcXVZbDdE?= =?utf-8?B?cVFOaVhYM3M5eTJidExoQ0RjeGxCamV4Z3RRcWd6dkNCL0JqN1V5TlVPWTZQ?= =?utf-8?B?UUJCR3BPM3A0aGg1SCtiKy9uM1dha2FhcHZpYm5wbU5MY1FZSUREZjkwaDR3?= =?utf-8?B?VU11Mkk2RjY3Zk1WZHZ1Rjl5NWF2YStOM2tyS082S3YySjNodE9DdVlNNW1K?= =?utf-8?B?N1QyUGVON1p2YkMyWjRIT3Rpa1pxTi9Wa3JtYmc4cUZrVFRLZ0IrTmFXcHNH?= =?utf-8?B?aU5qdk9lTU1jZ0MxWFhWL1Y3M01kM01weC82TG40YUFpTVA5T08yY1RRaEZx?= =?utf-8?B?bFhYcUl2blBKNWw2bnBEWlgzQ3RHaE4yQTJweFo5R2xBN1VNSjRCUXVYQzBs?= =?utf-8?B?UjdkMWFNTk1jdTBIUTFuUXh6NzRwUlR3NHBUeWdpVXhXRUZTKzlCVTZyb1F3?= =?utf-8?B?SzBGMGNYRHM3dlVxcUUwY0c4Nk5tVjRQSWlZbjZYSEF0cFJnYng4dmZHUGl4?= =?utf-8?B?VmJQV1o5Z3pyV1BOT09LRTJvR3RtNExYUERCWlN5Y1RDL1NEdVZWUjBUbnpz?= =?utf-8?B?NEZJbm1rdGxrNXU1UDdacmM4S0tCWk5teTltNE1ybWxyUlc5ZUQzUGMyODRt?= =?utf-8?B?NUNiOW1KQXpjQWp4WU1kR1ZVemNwNlF4N1dUUEtxZllDZCtyUHMvN2hlZE5x?= =?utf-8?B?dEpkbmQ4K2N5WjVJLzhSMWNHbURJY1NrMzMza0tTQXhzTzZHSVNQYkx1MHA0?= =?utf-8?B?akhQSjlLM21vMFNjbmdUQkI3NUdvZW03UjFEVVF5UWhMKy9wKzRBdGkwYkc2?= =?utf-8?B?Y3VJb281UUlOQ2hzeFc1ZWhmSG9lcE1VSUtQMFJYcTFwZ1JGdWpSeTEvK2xC?= =?utf-8?B?ZEhyWENUVkZqVDRJVzgwRllCWWNLRlltR2xJUHFrelZIeGJzUmdFZ2JpVlQ1?= =?utf-8?B?SUR2STI5emxsQ1d4cWVieEZPN3c1ck53QmM1ejV0UmU1eGJITmxXdjBUYzhL?= =?utf-8?B?MzJnS3NiQ0R0RHloZE9zZURBVnFjQ3owdVB0aUEvMGpoMlFBUWc4YThvYy9C?= =?utf-8?B?Wk4rTVEyOS9DUDFGbG93SE9OUHFvcWVEQStCem5odUw3dXZMY2ZoU1BybVg2?= =?utf-8?B?NnEvRm9uMjZRSjA1UW8xVTlaczgzK3NDQWh4MzZrVG1lcWJSd00yT29NUlJW?= =?utf-8?B?Zlpic2M0VGltNG81eVVwNEkrb1RZaGszem96TXdwbGRBWXJpWlBYTHBDSmZZ?= =?utf-8?B?TmpTdFJ6TnlYMG1Ia2lXNHlwTDd5dmZINW5LaFJDeFhWZ3VkSDJxZkFHekNq?= =?utf-8?B?QmJsU1daZXBxZ0UwSEpsMkxscnAzeUt6OVNZQmtxNlBqeitaNWx3a0s4NzY4?= =?utf-8?B?aWRmQkVwZXhVWlAvNEw2TVR5cnhwOWk0Y2diN3lQZlMrL1FlZzdSbTExbEg5?= =?utf-8?B?V1Btc1JmR014akp2NXlZZHA1TXhYUnZYQ0hCWkVQeitWbk1aNm9rRnZWNkRJ?= =?utf-8?B?d1lnODY5QjRobzVpeWU3TG9zcUZGd0tkTXFFdjBod0F6NElEUEszZjJxZWZq?= =?utf-8?B?UnlBcUtBNGh1a0JUNGVOdU5INFhWb29YOElTL1dmQmlVSTNtY3c4SVFWa09z?= =?utf-8?Q?dw3kETzPaPggbveM=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: PAXPR03MB7531.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d32759b-7390-4341-4ff9-08df262a30e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2026 17:24:36.0010 (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: myrjhowcAjKJOsfulaFvJrhIKj+4KFPLRz+pL2NstY+C7r2Qakj0Jbb8b7QIREqu/64JcIkEFSc2b7JaChVeGp3+Rymuspv1XTKAiR1SDdw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7373 X-purgate-ID: tlsNG-33051d/1791566677-77EC24E9-DC5BC314/0/0 X-purgate-type: clean X-purgate-size: 2570 DQoNCk9uIDIvMi8yNiAxODoxNCwgTXlreXRhIFBvdHVyYWkgd3JvdGU6DQo+IEtlZXAgYWxsIHRo ZSBpbmZvIGFib3V0IEJBU0VSIHJlZ3MgaW4gaG9zdF9pdHMgc3RydWN0dXJlIHRvIGJlIGFibGUg dG8gZWFzaWx5DQo+IGFjY2VzcyBpdCBsYXRlci4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IE15a3l0 YSBQb3R1cmFpIDxteWt5dGFfcG90dXJhaUBlcGFtLmNvbT4NCj4gLS0tDQo+ICAgeGVuL2FyY2gv YXJtL2dpYy12My1pdHMuYyAgICAgICAgICAgICB8IDM2ICsrKysrKysrKysrKysrKysrKysrKy0t LS0tLQ0KPiAgIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9naWNfdjNfaXRzLmggfCAxNCArKysr KysrKysrKw0KPiAgIDIgZmlsZXMgY2hhbmdlZCwgNDMgaW5zZXJ0aW9ucygrKSwgNyBkZWxldGlv bnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZ2ljLXYzLWl0cy5jIGIveGVu L2FyY2gvYXJtL2dpYy12My1pdHMuYw0KPiBpbmRleCBjNjI4OTU5ZjQyLi4yMzI4NTk1YTg1IDEw MDY0NA0KPiAtLS0gYS94ZW4vYXJjaC9hcm0vZ2ljLXYzLWl0cy5jDQo+ICsrKyBiL3hlbi9hcmNo L2FybS9naWMtdjMtaXRzLmMNCj4gQEAgLTQzMCwxNiArNDMwLDMyIEBAIHN0YXRpYyB2b2lkICpp dHNfbWFwX2NiYXNlcihzdHJ1Y3QgaG9zdF9pdHMgKml0cykNCj4gICAvKiBUaGUgSVRTIEJBU0Ug cmVnaXN0ZXJzIHdvcmsgd2l0aCBwYWdlIHNpemVzIG9mIDRLLCAxNksgb3IgNjRLLiAqLw0KPiAg ICNkZWZpbmUgQkFTRVJfUEFHRV9CSVRTKHN6KSAoKHN6KSAqIDIgKyAxMikNCj4gICANCj4gK3N0 cnVjdCBpdHNfYmFzZXIgKml0c19nZXRfYmFzZXIoc3RydWN0IGhvc3RfaXRzICpod19pdHMsIHVp bnQzMl90IHR5cGUpDQo+ICt7DQo+ICsgICAgdW5zaWduZWQgaW50IGk7DQo+ICsNCj4gKyAgICBm b3IgKCBpID0gMDsgaSA8IEdJVFNfQkFTRVJfTlJfUkVHUzsgaSsrICkNCj4gKyAgICB7DQo+ICsg ICAgICAgIGlmIChHSVRTX0JBU0VSX1RZUEUoaHdfaXRzLT50YWJsZXNbaV0udmFsKSA9PSB0eXBl KQ0KPiArICAgICAgICAgICAgcmV0dXJuICZod19pdHMtPnRhYmxlc1tpXTsNCj4gKyAgICB9DQo+ ICsNCj4gKyAgICByZXR1cm4gTlVMTDsNCj4gK30NCj4gKw0KPiAgIHN0YXRpYyBpbnQgaXRzX21h cF9iYXNlcih2b2lkIF9faW9tZW0gKmJhc2VyZWcsIHVpbnQ2NF90IHJlZ2MsDQo+IC0gICAgICAg ICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IG5yX2l0ZW1zKQ0KPiArICAgICAgICAgICAg ICAgICAgICAgICAgIHVuc2lnbmVkIGludCBucl9pdGVtcywgc3RydWN0IGl0c19iYXNlciAqYmFz ZXIpDQo+ICAgew0KPiAgICAgICB1aW50NjRfdCBhdHRyLCByZWc7DQo+ICAgICAgIHVuc2lnbmVk IGludCBlbnRyeV9zaXplID0gR0lUU19CQVNFUl9FTlRSWV9TSVpFKHJlZ2MpOw0KPiAtICAgIHVu c2lnbmVkIGludCBwYWdlc3ogPSAyOyAgICAvKiB0cnkgNjRLIHBhZ2VzIGZpcnN0LCB0aGVuIGdv IGRvd24uICovDQo+ICsgICAgdW5zaWduZWQgaW50IHBhZ2Vfc2l6ZVs0XSA9IHtTWl80SywgU1pf MTZLLCBTWl82NEssIFNaXzY0S307DQo+ICsgICAgdW5zaWduZWQgaW50IHBhZ2VzeiA9IDA7ICAg IC8qIHRyeSA2NEsgcGFnZXMgZmlyc3QsIHRoZW4gZ28gZG93bi4gKi8NCg0KQ29tbWVudCBzYXlz ICJ0cnkgNjRLIHBhZ2VzIGZpcnN0IiwgYnV0IHBhZ2VzeiBzdGFydHMgZnJvbSAwIChmcm9tIDRL KS4NCg0KQW5kIHRoZXJlIGlzIGEgY2hlY2sgYXQgdGhlIGVuZCBvZiB0aGlzIGZ1bmN0aW9uOg0K DQogICAgIGlmICggcGFnZXN6LS0gPiAwICkNCiAgICAgICAgIGdvdG8gcmV0cnk7DQoNCndoaWNo IGRvZXNuJ3Qgd29yayBhdCBhbGwgd2hlbiBwYWdlc3ogPSAwOw0KDQpCUiwgRG15dHJvLg0K From xen-devel-bounces@lists.xenproject.org Fri Oct 09 17:37:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 17:37:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444612.1661380 (Exim 4.92) (envelope-from ) id 1xFEXI-0002Dp-Eu; Fri, 09 Oct 2026 17:37:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444612.1661380; Fri, 09 Oct 2026 17:37: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 1xFEXI-0002Di-CF; Fri, 09 Oct 2026 17:37:36 +0000 Received: by outflank-mailman (input) for mailman id 1444612; Fri, 09 Oct 2026 17:37:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFEXG-0002DQ-TD for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 17:37:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFEXF-009Q9J-Kr for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 19:37:33 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9264b-bab6-0a2a0a5309dd-0a2a4508ec7e-6 for ; Fri, 09 Oct 2026 19:37:31 +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 6ac9265b-f659-0a2a45080019-d155802fa594-3 for ; Fri, 09 Oct 2026 19:37:31 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a166199820so661575e9.1 for ; Fri, 09 Oct 2026 10:37:31 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18ee9bd19sm46952685e9.1.2026.10.09.10.37.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2026 10:37: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=1791567451; x=1792172251; 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=uHmt7UFh3M6yXtrvb6bO+ouICIWFWyTELgpVwoR0wF4=; b=Ut1nJCr80YJJ0xd/qKq2rTOdUphmi4Vbmfd5f3h9gzeeb0B1J1XPhXcZnGUj13iE0V Flcko3A6Kpv8mPGvnUd+GMhzz3r6L4pqYtVO9IrWxsDjURhJsGKgxFDw52H9BMGmAtrm ceZeFHpqHo4xCwGaSLCkPQqgDEk/6thJMP/z3lkaOaPAL+EuZts3EqZ6QV97EDoHdQmZ vUKf+wR1JJ1IIY4N56Gs5y3fJcChy+mdFDIkE//ygcGkwzzpiGKbcS95gxAMUpkyVLSb cUPer1JPTx/YZid0OceLX3jk8f5mu9nFvIW7LxuYb89tUDiN0dm2DfCMjySA5bEQrEN1 8A/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791567451; x=1792172251; 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=uHmt7UFh3M6yXtrvb6bO+ouICIWFWyTELgpVwoR0wF4=; b=zzwSUl9M4UQoSC0Eb2ThNwJbEPGIxmYmIyGO9LmbbzzYsmTHvLNOAiKRFAmH9s8JIz 7/9fa9gBRBOhbfOzDPtowfC2Posx+JPr3rouYy7JQax1JYV799VKsQzK+tC0fC9PfnSF 0AiPt8XLqzXGezexYqWweT6bHQdpEmvu0izzKV1GxmIYGT9m2Jue0DS0mwsFIz0wIywN EmRc3pJYN4/zSdz87YwCQ4sG28tDEwwJp6Gb3+89D9vRZukTHSvG55/PR4IL4lLKVtsK pLuOHKRNT0TuNesACr/0jT4ifgocBcal7IfVwOjNe16qHGAsfxqEHUOuj7Vf4kZFl/h4 6gUA== X-Forwarded-Encrypted: i=1; AKwUvBzAPY4JiQ4ogZMLE7zN07OFgx/mNPY0YSO4gCXCwNpquSW1GngG4E0HNd4dIBrMBFnpq6/bK3N6uiM=@lists.xenproject.org X-Gm-Message-State: AFuF++n9cGUo3gX02vjhcWVh29qCHVFfoRaPjORTk0RmUX5woJqVNud/ YctvhinOrkBON2O/VmuLTlDO65kyUccxiwOP+qQd2tdklfT4CC4uNY2c X-Gm-Gg: AYBFou3QCiZaf+6ky6ckmVEcYffJNmqsVLhLRJunfPu3RYP4kCzAS8dDKoszLLSOeFL JGRX9Rz8gGFvYOBlULvaqgbJRbf2K7Bh5ry8StwJVJlkGr43Qi6Jm2aQLZoMOLDn9+B83fKFBhl QBdz6tUYiYQF++eh6YJDc9ARfYnEb9F/QWryxaDJSI87PcXfLtFDd6ZZYLuVQsM+Jul9yvCn0dC aWSkGy8qOiJPCg0d+GjZXMnutAnAqq7jBo+vVRWFQSV950rvpOdThzQvhVZ3E8oZ42xim9TDD+R HdiGLTXPoQ9oyXGJwQy9OZFfzKmfaJXE2iZ3OmNqYPBpcJrIym83txBuFsuFjiLmsj7Q9dhBzPx QPuoXaxO6J6h8P9VLXnYYETAfZhUuOyAz42jVoKRGLG9L/Ei5p5wRe0vgdXZyx28IeEYdN7PeyO aKHyfvErlJgr0HfELq99f96nF/ln4qkPQzreMUJULDR4pRzhGQTJ0Hou+SApilkJJewD7chSAFH nbs0DMSZ5hTrQ== X-Received: by 2002:a05:600c:3b0a:b0:4a1:8963:b865 with SMTP id 5b1f17b1804b1-4a18e447e9emr52422685e9.1.1791567450673; Fri, 09 Oct 2026 10:37:30 -0700 (PDT) Message-ID: Date: Fri, 9 Oct 2026 20:37:28 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/22] xen/arm: smmuv3: Add support for stage-1 and nested stage translation To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Bertrand Marquis , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk References: <6e45683f154be94e573a4a5e5d25c7efcc29fbe5.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <6e45683f154be94e573a4a5e5d25c7efcc29fbe5.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1791567451-DF8D587B-28E33593/0/0 X-purgate-type: clean X-purgate-size: 8725 On 10/7/26 03:06, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > Xen SMMUv3 driver only supports stage-2 translation. Add support for > Stage-1 translation that is required to support nested stage > translation. > > In true nested mode, both s1_cfg and s2_cfg will coexist. > Let's remove the union. When nested stage translation is setup, both > s1_cfg and s2_cfg are valid. > > We introduce a new smmu_domain abort field that will be set > upon guest stage-1 configuration passing. If no guest stage-1 > config has been attached, it is ignored when writing the STE. > > arm_smmu_write_strtab_ent() is modified to write both stage > fields in the STE and deal with the abort field. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/drivers/passthrough/arm/smmu-v3.c | 96 +++++++++++++++++++++++---- > xen/drivers/passthrough/arm/smmu-v3.h | 9 +++ > 2 files changed, 93 insertions(+), 12 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index 7162473d62..d3e88d5a55 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -683,8 +683,10 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, > * 3. Update Config, sync > */ > u64 val = le64_to_cpu(dst[0]); > - bool ste_live = false; > + bool s1_live = false, s2_live = false, ste_live = false; > + bool abort, translate = false; > struct arm_smmu_device *smmu = NULL; > + struct arm_smmu_s1_cfg *s1_cfg = NULL; > struct arm_smmu_s2_cfg *s2_cfg = NULL; > struct arm_smmu_domain *smmu_domain = NULL; > struct arm_smmu_cmdq_ent prefetch_cmd = { > @@ -699,30 +701,57 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, > smmu = master->smmu; > } > > - if (smmu_domain) > - s2_cfg = &smmu_domain->s2_cfg; > + if (smmu_domain) { > + switch (smmu_domain->stage) { > + case ARM_SMMU_DOMAIN_S1: > + s1_cfg = &smmu_domain->s1_cfg; > + break; > + case ARM_SMMU_DOMAIN_NESTED: > + s1_cfg = &smmu_domain->s1_cfg; > + fallthrough; > + case ARM_SMMU_DOMAIN_S2: > + s2_cfg = &smmu_domain->s2_cfg; > + break; > + default: > + break; > + } > + translate = s1_cfg || s2_cfg; > + } > > if (val & STRTAB_STE_0_V) { > switch (FIELD_GET(STRTAB_STE_0_CFG, val)) { > case STRTAB_STE_0_CFG_BYPASS: > break; > + case STRTAB_STE_0_CFG_S1_TRANS: > + s1_live = true; > + break; > case STRTAB_STE_0_CFG_S2_TRANS: > - ste_live = true; > + s2_live = true; > + break; > + case STRTAB_STE_0_CFG_NESTED: > + s1_live = true; > + s2_live = true; > break; > case STRTAB_STE_0_CFG_ABORT: > - BUG_ON(!disable_bypass); > break; > default: > BUG(); /* STE corruption */ > } > } > > + ste_live = s1_live || s2_live; > + > /* Nuke the existing STE_0 value, as we're going to rewrite it */ > val = STRTAB_STE_0_V; > > /* Bypass/fault */ > - if (!smmu_domain || !(s2_cfg)) { > - if (!smmu_domain && disable_bypass) > + if (!smmu_domain) > + abort = disable_bypass; > + else > + abort = smmu_domain->abort; > + > + if (abort || !translate) { > + if (abort) > val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_ABORT); > else > val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS); > @@ -740,7 +769,32 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, > return; > } > > + if (ste_live) { > + /* First invalidate the live STE */ > + dst[0] = cpu_to_le64(STRTAB_STE_0_CFG_ABORT); > + arm_smmu_sync_ste_for_sid(smmu, sid); > + } > + > + if (s1_cfg) { > + dst[1] = cpu_to_le64( > + FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0) | > + FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) | > + FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) | > + FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH) | > + FIELD_PREP(STRTAB_STE_1_STRW, STRTAB_STE_1_STRW_NSEL1)); > + > + if (smmu->features & ARM_SMMU_FEAT_STALLS && > + !(smmu->features & ARM_SMMU_FEAT_STALL_FORCE)) > + dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD); > + > + val |= (s1_cfg->s1ctxptr & STRTAB_STE_0_S1CTXPTR_MASK) | > + FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) | > + FIELD_PREP(STRTAB_STE_0_S1CDMAX, s1_cfg->s1cdmax) | > + FIELD_PREP(STRTAB_STE_0_S1FMT, s1_cfg->s1fmt); > + } > + > if (s2_cfg) { > + u64 vttbr = s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK; > u64 strtab = > FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) | > FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) | > @@ -750,12 +804,19 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, > STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2AA64 | > STRTAB_STE_2_S2R; > > - BUG_ON(ste_live); > + if (s2_live) { > + u64 s2ttb = le64_to_cpu(dst[3]) & STRTAB_STE_3_S2TTB_MASK; > + BUG_ON(s2ttb != vttbr); > + } > + > dst[2] = cpu_to_le64(strtab); > > - dst[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK); > + dst[3] = cpu_to_le64(vttbr); > > val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS); > + } else { > + dst[2] = 0; > + dst[3] = 0; > } > > if (master->ats_enabled) > @@ -1254,8 +1315,16 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain, > { > int ret; > struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > + struct arm_smmu_device *smmu = smmu_domain->smmu; > + > + if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S2)) > + return 0; I am not fully confident I understood all the magic here correctly, but it appears the initial state may be broken on SMMUs without stage-2 (stage-1-only hosts). Here we return early without setting a stage, and the zeroed domain has stage-1 (enum value 0). So a new domain is left in a default stage-1 state with no real config. The first attach then writes a live S1 STE with s1ctxptr = 0 in arm_smmu_write_strtab_ent(), so the hardware reads a context descriptor from physical address 0. I wonder we should default the domain to abort. Could you please double-check? Also, it is my understanding that without stage-2 translation the guest’s s1ctxptr and the stage-1 output address are used as host physical addresses. The guest decides where the hardware reads and writes. I wonder whether we should refuse this mode for non-hardware (non-direct-mapped) domains. Apologies if this has already been discussed. > > - /* Restrict the stage to what we can actually support */ > + /* > + * Default to stage-2 support and initialize it. Stage-1 will be > + * initialized during guest config attachment, if nested or stage-1 > + * mode is required > + */ > smmu_domain->stage = ARM_SMMU_DOMAIN_S2; > > ret = arm_smmu_domain_finalise_s2(smmu_domain, master); > @@ -2398,11 +2467,14 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) > break; > } > > + if (reg & IDR0_S1P) > + smmu->features |= ARM_SMMU_FEAT_TRANS_S1; > + > if (reg & IDR0_S2P) > smmu->features |= ARM_SMMU_FEAT_TRANS_S2; > > - if (!(reg & IDR0_S2P)) { > - dev_err(smmu->dev, "no stage-2 translation support!\n"); > + if (!(reg & (IDR0_S1P | IDR0_S2P))) { > + dev_err(smmu->dev, "no translation support!\n"); > return -ENXIO; > } > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthrough/arm/smmu-v3.h > index ab1f29f6c7..e257de6db9 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.h > +++ b/xen/drivers/passthrough/arm/smmu-v3.h > @@ -197,6 +197,7 @@ > #define STRTAB_STE_0_CFG_BYPASS 4 > #define STRTAB_STE_0_CFG_S1_TRANS 5 > #define STRTAB_STE_0_CFG_S2_TRANS 6 > +#define STRTAB_STE_0_CFG_NESTED 7 > > #define STRTAB_STE_0_S1FMT GENMASK_ULL(5, 4) > #define STRTAB_STE_0_S1FMT_LINEAR 0 > @@ -549,6 +550,12 @@ struct arm_smmu_strtab_l1_desc { > dma_addr_t l2ptr_dma; > }; > > +struct arm_smmu_s1_cfg { > + u64 s1ctxptr; > + u8 s1fmt; > + u8 s1cdmax; > +}; > + > struct arm_smmu_s2_cfg { > u16 vmid; > u64 vttbr; > @@ -669,6 +676,8 @@ struct arm_smmu_domain { > atomic_t nr_ats_masters; > > enum arm_smmu_domain_stage stage; > + bool abort; > + struct arm_smmu_s1_cfg s1_cfg; > struct arm_smmu_s2_cfg s2_cfg; > > /* Xen domain associated with this SMMU domain */ From xen-devel-bounces@lists.xenproject.org Fri Oct 09 20:26:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Oct 2026 20:26:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444696.1661390 (Exim 4.92) (envelope-from ) id 1xFHAG-0000W5-U6; Fri, 09 Oct 2026 20:26:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444696.1661390; Fri, 09 Oct 2026 20: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 1xFHAG-0000Vx-QL; Fri, 09 Oct 2026 20:26:00 +0000 Received: by outflank-mailman (input) for mailman id 1444696; Fri, 09 Oct 2026 20:26:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFHAF-0000Vo-PG for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 20:26:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFHAF-009hdL-6B for xen-devel@lists.xenproject.org; Fri, 09 Oct 2026 22:25:59 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac94dc0-8faa-0a2a0a5109dd-0a2a4506df62-14 for ; Fri, 09 Oct 2026 22:25:59 +0200 Received: from [209.85.128.175] (helo=mail-yw1-f175.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac94dd6-195a-0a2a45060019-d15580afa8f7-3 for ; Fri, 09 Oct 2026 22:25:59 +0200 Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-8aca54b75d4so16860147b3.0 for ; Fri, 09 Oct 2026 13:25:58 -0700 (PDT) Received: from StolidWingnut.localdomain ([174.80.170.224]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b07f1eab6csm11469547b3.20.2026.10.09.13.25.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Oct 2026 13:25: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=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=1791577557; x=1792182357; 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=viiD07VAm0wzPwhi7WCLojzjM3p/uz3mpHV0GNtwMuE=; b=NLpS+QGJPwlc+gxi4SrepdIdDcZm8znZBNYWKPAvAcoisdZKnqHVhv1zRggl1i4TnZ BSO5DqrY4Eh3m/PAfbuWeeEfVsN8Tin4WRDny1vjkNxQ7qfgHs5nhkTpzNdt86K5uRoE 02o/2fhjtQzfbRibuijeMEg7lbwcZjuyxKyL8wE0M8RMGuIo32Nzl30zo6TxcDUEhARO kKuKEZaWC9MIhT+nszOnGjdhx2VLD0MYBCablb0B35/OC6uTp9/P5bTUJmsmjF8sqnr4 VDnBW2+A9BK0nuoPjB444EnKTGgQjkUyo8A0Q8T48i30Xo1sZXh6SyUpR5B/OgPbb0P5 nj9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791577557; x=1792182357; 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=viiD07VAm0wzPwhi7WCLojzjM3p/uz3mpHV0GNtwMuE=; b=OtYBFhvZEBNHUTg9PW2S7jrRy9RHkIcB1n5M8bEZopCGvLmU1NZD2xSqa7E1WT7qPO BdQtxSiILxlNQE0S2P3W8M9PNzzulqFCTXoDDSnB+dDQxw6V8T+xeTTxBV095ngeGbq5 4WPFOey8DaJei//mupEDnBh6MkB4t2DE6xNQ4oLMm41jJJpMCcNJ/vrkOC1QxLX6vSso nPpeIdO6Za/AVMfbvbEnr5I7VCjX8nY0dkV9ml4Waq35tPe0BX5EOfikhmwvyabrrxnp U7ZWmlNbowyWoQj2VRFoFu00HAkNf/GG6b9EXVcxLQbKtZ5YYgCeAJ8uMaxcneuZC/Cw f3ZA== X-Gm-Message-State: AFq9FYKllLiKh0SxTu5QuoFyNrJvdTKCMzcrNkvR9XvW4uBPr9od+ZfV 0730NAUT+e4TYHl78SHhPjKJDr86zCKXGyCVgy3mDRQiTIPtUhZjD6+jf6/d9Mzawt6H6yurjk/ UthslKQUBJg== X-Gm-Gg: AYBFou3THsk7YmeAhc9S4mKjdBVI6TBB54raBFtxVdIcaWmi7HMhKR4fIdZP+f58sVb /L30M+bcV7Ozs/HQYaUTbv0qPDAUtwlSRJuZCwifAVYkICarSWqLDkQflDSU2oHJKWh6GJbJCkx 7tYnOcahgj1w84WtJlKMIQk1cwhIvN64v4WhmC7ippkUw/QliEynfGg1PJzc9zR820LDwhIRhVh pylrPOvgE9UrU9ow8uiGwZF19aXO9j7eBih3bXy0nXNHj6wHqlAV7exKiDYH5AS8k2dqwaLaPXi onyUGRLEAz0sKPaYaXM3459KxTOuXFHQRrFPr0MHHGViUSkxmS+h0itaSh6vhm/VXVefFmmjxBX bktLbJ5LLQ1oMtvWbNZWW5A5O5XNl5ZI+GoKtDVSj4MLnefZOOnY2Uy5n1A9j30TNtk2sRPQiIb TK6nB0kOL0CDGTZCnfd9IRY5bxWo45f74jofhE7tAdf05dCqCwb4U0GkgZwLalh3IQuVJAfV9zH Y4toS9hPJh/Bjc9E9Q8QpZHLdGHGCjySf7BzRp5n0E+z2lZLYK8m//AO9VdNyVXSwZ0FAc= X-Received: by 2002:a05:690c:c50d:b0:890:f416:7a27 with SMTP id 00721157ae682-8b07ed91534mr9377927b3.19.1791577557288; Fri, 09 Oct 2026 13:25:57 -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 "auto" to scan PCI only when the default base has no UART Date: Fri, 9 Oct 2026 16:24:47 -0400 Message-ID: <20261009202447.852414-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-16d1c6/1791577559-F6C7777B-A7031A45/0/0 X-purgate-type: clean X-purgate-size: 5461 On some systems the console UART is at the legacy I/O port, and on others, such as Amazon EC2 bare metal instances, the only UART is on PCI. "com1=...,pci" finds the PCI UART, but it prefers any PCI serial device to the legacy port, so it is not correct on a system that has both. No option today says "use the legacy port, and scan PCI only if it has no UART". A deployment that boots one command line on many kinds of machine needs exactly that. Add "auto" as a value in the position. With it, Xen probes the default base as usual. Only if check_existence() fails there does it scan PCI, as "pci" does. Without "auto", nothing changes. The scan runs only when the command line asks for it, at the same point in boot as "pci" and "amt". There is no console yet, but the scan is not silent: it logs the device that it picked, and PARSE_ERR() logs a failure. Both messages go to the console ring, and console_init_preirq() replays the ring to each console that comes up, VGA included. Only a hang or a crash inside the scan goes unreported, as with "pci" and "amt" today. To limit what an unexpected scan can touch, "auto" only considers devices that are in uart_config[]. A serial-class device without built-in parameters is skipped before its BARs are sized, so a firmware that misreports the legacy port cannot move com1 to an arbitrary plug-in card. When the scan finds nothing, pci_uart_config() puts back the original base, and check_existence() does not test MMIO addresses. Thus ps_bdf_enable, not check_existence(), tells whether a device was found. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Benjamin Leggett --- docs/misc/xen-command-line.pandoc | 5 ++++- xen/drivers/char/ns16550.c | 31 ++++++++++++++++++++++++++++++- 2 files changed, 34 insertions(+), 2 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index ea0e3368b1..58ef53a5b2 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -357,7 +357,7 @@ ACPI indicating none to be there. ### com1 (x86) ### com2 (x86) -> `= [/][,[DPS][,[|pci|amt][,[|msi][,[][,[]]]]]]` +> `= [/][,[DPS][,[|pci|amt|auto][,[|msi][,[][,[]]]]]]` Both option `com1` and `com2` follow the same format. @@ -387,6 +387,9 @@ Both option `com1` and `com2` follow the same format. avoiding Intel AMT devices. * `amt` indicated that Xen should scan the PCI bus for the UART, including Intel AMT devices if present. +* `auto` indicates that Xen should use the default I/O base if a UART + responds there, and otherwise scan the PCI bus for the UART as `pci` + does, but only for devices with built-in parameters in Xen. A typical setup for most situations might be `com1=115200,8n1` diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index cdda28879e..ab55e2ba45 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -66,6 +66,7 @@ static struct ns16550 { bool dw_usr_bsy; #ifdef NS16550_PCI /* PCI card parameters. */ + bool pci_fallback; /* if =1, scan PCI if io_base has no UART */ 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; @@ -1321,6 +1322,10 @@ pci_uart_config(struct ns16550 *uart, bool skip_amt, unsigned int idx) } } + /* Keep "auto" off unknown devices, including their BARs. */ + if ( uart->pci_fallback && i == ARRAY_SIZE(uart_config) ) + continue; + if ( port_idx >= param->max_ports ) { idx -= param->max_ports; @@ -1628,6 +1633,11 @@ static bool __init parse_positional(struct ns16550 *uart, char **str) return true; conf += 3; } + else if ( strncmp(conf, "auto", 4) == 0 ) + { + uart->pci_fallback = true; + conf += 4; + } else #endif { @@ -1819,7 +1829,26 @@ 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"); + { +#ifdef CONFIG_HAS_PCI + if ( uart->pci_fallback ) + { + pci_uart_config(uart, 1 /* skip AMT */, uart - ns16550_com); + if ( uart->ps_bdf_enable ) + printk("ns16550: com%u: no UART at default base, using %pp\n", + (unsigned int)(uart - ns16550_com) + 1, + &uart->pci_device); + } + + /* + * A failed scan puts back the rejected base, and check_existence() + * passes MMIO addresses untested, so only ps_bdf_enable says that + * a device was found. + */ + if ( !uart->ps_bdf_enable || !check_existence(uart) ) +#endif + PARSE_ERR("16550-compatible serial UART not present"); + } /* Register with generic serial driver. */ serial_register_uart(uart - ns16550_com, &ns16550_driver, uart); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 03:14:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 03:14:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444824.1661399 (Exim 4.92) (envelope-from ) id 1xFNX2-0007W8-PX; Sat, 10 Oct 2026 03:13:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444824.1661399; Sat, 10 Oct 2026 03:13: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 1xFNX2-0007W0-KW; Sat, 10 Oct 2026 03:13:56 +0000 Received: by outflank-mailman (input) for mailman id 1444824; Sat, 10 Oct 2026 03:13:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFNX1-0007Vu-O6 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 03:13:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFNX0-0001Wg-JB for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 05:13:54 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9ad31-8faa-0a2a0a5109dd-0a2a4506cc7e-14 for ; Sat, 10 Oct 2026 05:13:53 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac9ad6e-195a-0a2a45060019-9fe2fb158db6-3 for ; Sat, 10 Oct 2026 05:13:52 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowACXa+9prclqNfdpCg--.21498S2; Sat, 10 Oct 2026 11:13:46 +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: Zhang Zheng To: xen-devel@lists.xenproject.org Cc: Zhang Zheng , Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 0/2] xen/ns16550: preserve UART operation across firmware handover Date: Sat, 10 Oct 2026 11:14:04 +0800 Message-ID: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:qwCowACXa+9prclqNfdpCg--.21498S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtryUZF1DKF45trykJw1kXwb_yoWkCrX_uw 4vkrWDGryDGFs8AF98tF4UCFZ5CrW5Wrn2vay0qF1ayw10yrs3uFW5Gry5Zrn8C3yqyF1k CFyYyrWSq3929jkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUba8FF20E14v26r4j6ryUM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8w A2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_ Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr1j6F4UJwAm72CE4IkC6x0Yz7v_Jr 0_Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E 8cxan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFV Cjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWl x4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r 1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_ JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcS sGvfC2KfnxnUUI43ZEXa7VU11rW7UUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-16d1c6/1791602033-F7ACA77B-CFA12F4F/0/0 X-purgate-type: clean X-purgate-size: 1156 V1 replaced the RISC-V SBI early console with direct 8250 MMIO access. Following review, v2 keeps the generic SBI console and instead fixes the handover in ns16550. K3 testing exposed two issues during this handover: clearing IER disables its XScale-compatible UART, and resetting the FIFO can discard output still pending after an SBI console call. I originally planned to submit the XScale support separately, but both fixes are needed for the same handover, so they are included here as two patches. Tested with QEMU 11.0.0/OpenSBI 1.7 and on SpacemiT K3 hardware. Changes in v2: - Keep the SBI early console and legacy SBI v0.1 support. - Preserve UART_IER_UUE and drain TX before ns16550 reinitialization. v1: https://lore.kernel.org/xen-devel/20260928023857.1030884-1-zhangzheng@iscas.ac.cn/ Zhang Zheng (2): xen/ns16550: detect and preserve UART_IER_UUE xen/ns16550: drain TX before reinitializing xen/drivers/char/ns16550.c | 16 +++++++++++++++- xen/include/xen/8250-uart.h | 1 + 2 files changed, 16 insertions(+), 1 deletion(-) base-commit: 0d3bb3c98bc99ec1c84ebb3df71b6e18daebff4f -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 03:14:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 03:14:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444825.1661409 (Exim 4.92) (envelope-from ) id 1xFNX4-0007iY-Uu; Sat, 10 Oct 2026 03:13:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444825.1661409; Sat, 10 Oct 2026 03:13: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 1xFNX4-0007iO-Qo; Sat, 10 Oct 2026 03:13:58 +0000 Received: by outflank-mailman (input) for mailman id 1444825; Sat, 10 Oct 2026 03:13:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFNX3-0007ew-PD for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 03:13:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFNX3-0001Y0-6T for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 05:13:57 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9ad71-e002-0a2a0a5209dd-0a2a4503dc34-2 for ; Sat, 10 Oct 2026 05:13:55 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac9ad70-fae8-0a2a45030019-9fe2fb15c5f4-3 for ; Sat, 10 Oct 2026 05:13:54 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowACXa+9prclqNfdpCg--.21498S3; Sat, 10 Oct 2026 11:13:47 +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: Zhang Zheng To: xen-devel@lists.xenproject.org Cc: Zhang Zheng , Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE Date: Sat, 10 Oct 2026 11:14:05 +0800 Message-ID: <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:qwCowACXa+9prclqNfdpCg--.21498S3 X-Coremail-Antispam: 1UD129KBjvJXoW7uFWxGry7Jry3CFW7Kw18Grg_yoW8uw17pF WxKFnYyrWDtr10kr9Iq3Wjga1xWas3X34FkrZ3u39xXr1kJw40kF4UJF17Xr4kur4ktr4U uFs2yrWUAF98Zr7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmF14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr1j6F4UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2 IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY 6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17 CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF 0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIx AIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2 KfnxnUUI43ZEXa7VUjhFxUUUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-33051d/1791602035-778C54E9-F3C38F06/0/0 X-purgate-type: clean X-purgate-size: 2347 XScale-compatible UARTs require UART_IER_UUE to remain set. Probe the bit during setup and preserve it when enabling receive interrupts, so the xscale/PXA UART remains operational after ns16550 takes over. Signed-off-by: Zhang Zheng --- xen/drivers/char/ns16550.c | 12 +++++++++++- xen/include/xen/8250-uart.h | 1 + 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index cdda28879e..c174465059 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -64,6 +64,7 @@ static struct ns16550 { bool intr_works; bool force_polling; bool dw_usr_bsy; + bool xscale; #ifdef NS16550_PCI /* PCI card parameters. */ bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) /* No interrupts. */ ns_write_reg(uart, UART_IER, 0); + uart->xscale = false; + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) + { + ns_write_reg(uart, UART_IER, UART_IER_UUE); + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) + uart->xscale = true; + } + /* Handle the DesignWare 8250 'busy-detect' quirk. */ handle_dw_usr_busy_quirk(uart); @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); /* Enable receive interrupts. */ - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); + ns_write_reg(uart, UART_IER, + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); } if ( uart->irq >= 0 ) diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h index d13352940c..358d264698 100644 --- a/xen/include/xen/8250-uart.h +++ b/xen/include/xen/8250-uart.h @@ -42,6 +42,7 @@ #define UART_IER_ETHREI 0x02 /* tx reg. empty */ #define UART_IER_ELSI 0x04 /* rx line status */ #define UART_IER_EMSI 0x08 /* MODEM status */ +#define UART_IER_UUE 0x40 /* UART unit enable (XScale/PXA) */ /* Interrupt Identification Register */ #define UART_IIR_NOINT 0x01 /* no interrupt pending */ -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 03:31:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 03:31:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444845.1661417 (Exim 4.92) (envelope-from ) id 1xFNoL-0002mM-AN; Sat, 10 Oct 2026 03:31:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444845.1661417; Sat, 10 Oct 2026 03: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 1xFNoL-0002mE-6v; Sat, 10 Oct 2026 03:31:49 +0000 Received: by outflank-mailman (input) for mailman id 1444845; Sat, 10 Oct 2026 03:31:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFNoK-0002m8-Bp for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 03:31:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFNoJ-008b6O-C2 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 05:31:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9b176-bab6-0a2a0a5309dd-0a2a4504e0fc-18 for ; Sat, 10 Oct 2026 05:31:46 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac9b19f-b57f-0a2a45040019-9fe2fb15aef8-3 for ; Sat, 10 Oct 2026 05:31:45 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowABnP_OasclqbmRqCg--.37430S2; Sat, 10 Oct 2026 11:31:39 +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: Sat, 10 Oct 2026 11:32:02 +0800 From: Zhang Zheng To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini Subject: Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART Message-ID: References: <20260928023857.1030884-1-zhangzheng@iscas.ac.cn> <5919f1f2-e24c-4b0e-a7dd-126ac6fbe38f@gmail.com> <3152e70f-881f-4a58-9b2d-df661887dc80@gmail.com> <8836d1e3-77c8-4447-b1ef-132620a71441@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8836d1e3-77c8-4447-b1ef-132620a71441@gmail.com> X-CM-TRANSID:qwCowABnP_OasclqbmRqCg--.37430S2 X-Coremail-Antispam: 1UD129KBjvJXoW3WryDZw1UJry8uF43WFWxJFb_yoWxKw1kpF W3Ka15tFs5JFWa9rn2vw4kJFWrt395GF4UWrn5J3yUZwn8tryrArW7tF45ua4DJrs3Jr12 vF4jv343Wa4UZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvGb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr1j6F 4UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkI wI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr 0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY 17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcV C0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY 6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa 73UjIFyTuYvjxUqdHjUUUUU X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-ebf023/1791603106-51CD7B50-AFCE491F/0/0 X-purgate-type: clean X-purgate-size: 7774 On Wed, Sep 30, 2026 at 01:22:46PM +0200, Oleksii Kurochko wrote: > Hello Zheng, > > On 9/29/26 5:10 AM, Zhang Zheng wrote: > > On Mon, Sep 28, 2026 at 08:53:15PM +0800, Zhang Zheng wrote: > > > On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote: > > > > > > > > > > > > On 9/28/26 10:40 AM, Zhang Zheng wrote: > > > > > On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote: > > > > > > > > > > > > > > > > > > On 9/28/26 4:38 AM, Zhang Zheng wrote: > > > > > > > The legacy SBI console extension is planned for deprecation. Replace the > > > > > > > RISC-V early printk backend with direct access to 8250 UART MMIO. > > > > > > > > > > > > Won't it better just to start to add support of newer SBI? It provides > > > > > > pretty good support + faster as it supports passing of string instead of one > > > > > > char. > > > > > > > > > > > > > > > > Using the newer SBI DBCN extension would indeed result in a smaller change. At > > > > > the time, I mainly followed the direction suggested by the TODO and referred > > > > > directly to the arm64 implementation, from which most of the code was adapted. > > > > > > > > I think TODO was written at that way because I missed DBCN (or it wasn't > > > > ratified at that moment). Considering that it is ratified now ... > > > > > > > > > > > > > > > Also, I think it will lead to lesser changes. > > > > > > > > > > > > > > > > If falling back to SBI console putchar is acceptable, DBCN should work > > > > > well here. > > > > > > > > ... I prefer to use SBI functionality (in the current case DBCN) as maximum > > > > as possible so if there is no any reason (and I don't see at the moment it) > > > > which doesn't allow us to use DBCN here, I would prefer to use DBCN. > > > > > > > > > > Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware, > > > which should ship with a recent version of OpenSBI, I think you are right that > > > there is no real need to provide a fallback here. > > > > > > > If you still want to in the way suggested by TODO then some parts which are > > > > common between Arm and RISC-V should be moved to common instead of > > > > introducing them in RISC-V specific folder. > > > > > > > > > > I also tried to make the current patch as minimal as possible, but it would > > > still end up touching quite a few places. > > > > > > > Let me know which approach you are going to follow. If the current one you > > > > already introduced then I will start to review it, if you will go SBI-way > > > > then I prefer to wait for your v2. > > > > > > > > ~ Oleksii > > > > > > > > > > I misunderstood the TODO comment, I thought that would be the preferred > > > implementation. Therefore, I will switch to using DBCN and send a v2. > > I think I didn’t word it in the best way. > > For early debug, I think it would be better to use the SBI function. At some > point, it doesn’t really matter which one we use, SBI 0.1 or DBCN. If we > switch to using the UART’s MMIO directly, we wouldn’t need to change the > privilege mode or perform a context switch, so it should be faster. > > However, considering that the early console is mainly used during bring-up, > it seems like the overhead of an SBI function call isn’t a big price to pay. > In return, we could potentially have early printk support even for UARTs > that aren’t currently supported by Xen. > > > > > > > Best regards, > > > > > > Zhang > > > > > > > Hi Oleksii, > > > > I initially assumed that the DBCN console-write call would wait until the > > whole string had been transmitted. After checking the SBI specification > > and the Linux implementation, I found that this is not the case. > > I think Linux does roughly the same here: its SBI earlycon > calls sbi_debug_console_write() (or something like that) in a loop until the > whole buffer has been written. > > Also note that Linux supports both the legacy SBI v0.1 console_putchar > and DBCN console write for earlycon. It picks DBCN when the firmware > provides it and falls back to v0.1 otherwise (when CONFIG_RISCV_SBI_V01 > is enabled). I would really like Xen to do the same rather than drop > SBI v0.1 support. A board might not support DBCN, or might implement only > the legacy SBI extensions, and we still want console output there. So we > should keep both. > > I'd go further: we probably don't need to add DBCN support at this point. > It would be enough to fix the bug you originally hit with the legacy SBI > call. > > Also, in Linux the SBI console is only used as an early (boot) console. > Once the UART driver has probed and registered a real console, printk > switches to it and unregisters the boot console (unless keep_bootcon is > passed). So this switch doesn't cause any issues in Linux, and I don't see > why it should be a problem in our case either. Switching to DBCN, or the > approach taken in the current patch, looks to me like it is just hiding an > issue somewhere else. > > > > > The DBCN Console Write function is explicitly non-blocking. Linux uses DBCN > > through the HVC console driver, so the DBCN backend remains the owner of the > > console and the 8250 driver does not subsequently reinitialize the same UART > > or clear its FIFO. > > > > On the other hand, when Linux uses an 8250 earlycon, it accesses the UART > > directly and waits for UART_LSR_TEMT before the regular 8250 driver takes > > over. > > > > The current Xen setup combines these two paths: early printk uses the SBI > > console, while the later 8250 driver initializes the same UART. During this > > handover, the 8250 driver clears the TX FIFO, which can discard characters > > that were accepted by SBI but have not yet been transmitted by the UART. > > Isn't a question just doing flush before switch to 8250 so we won't loose > anything? (and then again why Linux doesn't have such issue considering that > they have the similar way of work, even without virtualization) > > > > > Therefore, if Xen is going to use the 8250 driver after early printk, I > > think the early console should use the same 8250 MMIO path, as Linux does > > with 8250 earlycon. This keeps the early-console backend consistent with > > the driver that takes ownership of the UART and allows Xen to wait for > > UART_LSR_TEMT before reinitialization. > > At some point, yes, but then we could lose support for other UARTs that > OpenSBI could provide out of the box for initial bring-up debugging. > > Also, we could have both implementations for early printk (SBI-based and > MMIO-based), configurable through some option, and allow the user to choose > which approach to use. But for now, I think we could live with the SBI-based > implementation (even with support only for old SBI console call for a > while), as it is more generic, until we actually face a performance issue > where the MMIO-based approach would start to provide a benefit. > > ~ Oleksii Hi Oleksii, Thanks for the clarification and suggestion. I have sent v2, keeping the existing SBI early console unchanged. Following your suggestion, it drains pending TX data before ns16550 reinitializes the UART. While bringing up Xen on K3 I also encountered an issue with its XScale-compatible UART, so v2 includes a separate fix to detect and preserve the UART_IER_UUE bit. As a result, v2 now mainly fixes UART handover issues rather than changing the RISC-V early printk implementation. I'm not sure whether carrying these fixes as v2 of the original series is the best approach, so please let me know if you have any concerns. Zhang From xen-devel-bounces@lists.xenproject.org Sat Oct 10 04:05:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 04:05:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444858.1661426 (Exim 4.92) (envelope-from ) id 1xFOKx-0007NK-RJ; Sat, 10 Oct 2026 04:05:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444858.1661426; Sat, 10 Oct 2026 04:05: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 1xFOKx-0007NC-NW; Sat, 10 Oct 2026 04:05:31 +0000 Received: by outflank-mailman (input) for mailman id 1444858; Sat, 10 Oct 2026 04:05:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFOKv-0007N4-S6 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 04:05:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFOKv-0068Z3-5O for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 06:05:29 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ac9b965-e002-0a2a0a5209dd-0a2a4503a36e-10 for ; Sat, 10 Oct 2026 06:05:29 +0200 Received: from [52.101.193.1] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ac9b987-fae8-0a2a45030019-3465c101a39f-4 for ; Sat, 10 Oct 2026 06:05:28 +0200 Received: from BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) by SA5PR03MB8428.namprd03.prod.outlook.com (2603:10b6:806:476::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 04:05:26 +0000 Received: from BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550]) by BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550%2]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 04:05: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=m7qpeppD6tNuYH9cPFiEnK6NzRP00HEIdWaxZHuhmh14Q1oOxQQFcZYxBlAUyvu88rL3tTmmkFmWd/MqFQiiCM2fDgiyx3IQJpKiyUASlY0KyG0whvigmjJhE3NS9sXIE+n0PCw4C1VbLm95MH+MpLEj3OgP0Mgm2JR62irqN5oQ1zEhrPPiyhOTOUMhx5Apq33oUU5HBGbBplt8wbBH1jW8eHCeeHpDcDvpjtdY8Mg4JdsJdCLmHsMAD2oyW0TYaon/L/Yjv59RLfbWvo2JprFbuS3ixmpm8oD//Dka0D1cRMKCnllCQ5QAsh1xU3rOPilPIgbI9obJDEXxzfvIZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eqy7CVCB5sQxyVXT2EVuVVOIkP3k3Vbdge2Vuw9ZONA=; b=QvZQVnEzAoQJhlghOlErI8wqcWcExlbGlv1L1GgSX3+DOZYR9H8vPRECcfGSrk1MaczNYsyx4ST2gerJ5Pl3utL77elYdMbfy+JfYfy9TKQXRe9WvQLsPiYVb8yJATOA7RVxsg8bT1/ApElUU/j5VjagjxuXGFFvbQuyVP3sCAnm65msLO4MoM77l32mqMQbwFv5z3KUpyHsrUxEPBzDZZkP5otS+uwVhBUeBFb6lqSPEbG/oV9xYwUvt194U65fl0HFGkhy45W7PJUerRm/cf5RQ7hLeBQOsxvUAciQc+oQT+g8pjaA2GOjOYJQAp/AaPNzi/DUBUcIr4vdcLnokw== 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=eqy7CVCB5sQxyVXT2EVuVVOIkP3k3Vbdge2Vuw9ZONA=; b=n7cNnyVezF8pRla8pCIbrg93ubUM9aJ8GX6sBKJDktmRf2WV7EJXEQL8cP3t5wgmuZIghhb3gKOnIXbOWUjHehr5oS53niKTPHRddEpjkK+dgda9CGzGGoX05aF0lYdqyGpXHyv2XFMxmuaeGuppzf+jKi6UWgPVDjB3XJcfYcY= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Cc: chunjie.zhu@citrix.com, jason.andryuk@amd.com, jbeulich@suse.com, roger@xenproject.org, ross.lagerwall@citrix.com, teddy.astie@vates.tech Subject: [PATCH v2] x86/svm: Sync nextrip during virtual VMRUN Date: Sat, 10 Oct 2026 12:05:02 +0800 Message-Id: <20261010040502.96413-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <0835710d-f67d-4678-ba39-4597b9c9c7f7@citrix.com> References: <0835710d-f67d-4678-ba39-4597b9c9c7f7@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KL1PR0401CA0022.apcprd04.prod.outlook.com (2603:1096:820:e::9) To BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR03MB5315:EE_|SA5PR03MB8428:EE_ X-MS-Office365-Filtering-Correlation-Id: c416e868-83c2-493d-b238-08df2683b564 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|18002099003|22082099003|10067099003|6133799003|261009223027099003|5023799004|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: g+MCYWehBdo9AvPVCbNnGD6Ty0bk1gilucd8pUk5zzbopUOieDpW8wTKEzoD+jam7uLc+MLqlv7UX549Mmli22mik0x/w6Q3f0Mh5LQta8mT2++ZckGZHBJD7/MQkd+4+zNFLawc2ozLopNstjEhJp2aGGL8mI+yCHVYkV3yFCf3v10oe4aEWp4d8hlWlllwJsEyYpD7a3roANvhCBz4gqZx/hD4s4wnq7UziH3iAzB6znz+kaX8Zc0Rzw5cMBevYOka7SgkJy5sZCida6TAKTN69CH4SloJ32pAWLkjpqbGOQzutEQNdFgXIX2xFURi+bCW08AOe1uf/6f/xZm+8+etEDUhPRzQpUHgsSeTLT+ydnlrLCSWZkUK330LKXjPRZa0cR8Cyhz1+BBWXR037PPDV7VPCLJUZR7mvxtbBcDLzahZZgAZIvD3SsYsgySEVJKV5c1SnAzPnoSTOxHE3m41qnNX/qf8UKMAPbNOtAWP5dp5eBsXQTotc+5vbX0DKFeVOoktpjakwcZxh8JeNdun6XsYhNjfwKssz3CVJWIZF4ZGPqmFB6vHvwej2yJ44CvLdBe+zmnIrNTsIrYrmcj+dTdb/fy9xh1fnkDbzG0LgXr5lOLfBVsKWzipO+tyU77OjuZhFGXXlgLkCgLUivLLmuAJTAO1O+3B+FWJvr8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR03MB5315.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(18002099003)(22082099003)(10067099003)(6133799003)(261009223027099003)(5023799004)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?NrjUIt6uUIatFaw8y02KVXbV21jAGSe6VQMC6aDOxk6/AZWcevkMRLoAC5Vr?= =?us-ascii?Q?yNaM9ITbfgZfw6cLAIBaJmVNivLfnyaG1i4uPGpILyKxIi3+CyMUFE7aV2TW?= =?us-ascii?Q?nKA0AiHAzpmaBMC8lDiEbVyx6Tueiv8mm+FUO1neMKeIbHiCMf+dq+MM85Id?= =?us-ascii?Q?ELaN1DE/SN6yqb1K/IvnDtt9hpC1NgEBmEmdM1a+pKvIAAWba8BvxP5cSmjc?= =?us-ascii?Q?zu7vxBlbq43KfGiuJJw2e6y0iawgeEOrMWG5pECqOzXqGSc3SdXUeD/FjU7q?= =?us-ascii?Q?842ZTumK2l9qoqV7I4v3M5Oh8Oi35GbG79CyFBoqfesi3EuEzicyKLkYhPTa?= =?us-ascii?Q?V+k2geNpqdW1M60LWPa0Qt/LdrP3FxabwVITu5fvlZXSPu+b9r31m8XUynjD?= =?us-ascii?Q?XwIdSALRqiSII2KOB3K6myZItrcf2WhYMxtUdrqJyEEE/S28270/eiK30G/A?= =?us-ascii?Q?xYU5NvM2OeHmskc1hQfeSM++yVQ+BT+XZABQk+KxL4r5JR0BX4G0WiOfHIJs?= =?us-ascii?Q?pRTnSp/5dx00ymBb5NTQ+UoX+zW0UWhyAY57TDBQccd3jtiOJpWC5J+XjPLr?= =?us-ascii?Q?Y/K9MHsjkQA4S/kr+e5QQeCyb6Xn6IRabKHuUjh2x/wOFROyKjUlLv5uPnL/?= =?us-ascii?Q?64q9GoI3DeXNXf6xfbY+5omxXoBi3PBwZQg9u/iaei6ynTcW8duQLl4OQeVR?= =?us-ascii?Q?ptBvl5RQPBzs2Fun+Kl5xDJ8cyeoMh5HLRVrRJlDExgnxGUFxM7Y9YQtbk3E?= =?us-ascii?Q?PwJsJuuHvcAsynDgO3ldKtoMh09AtMZl36BxenxvkNiQTiCIRwImHDKR/5bY?= =?us-ascii?Q?kAGxqzxtSqa+F2+DOGoVFIvdNltnd2vTFtMXxvIQ7Slc/U2nSNMHTJbRkT7V?= =?us-ascii?Q?5uMaCKWDmAfAjUcBga6UUSBEpr+E7d8CV4fVpQKoHc1RpTeqjtP0T5/8ZgKz?= =?us-ascii?Q?FbrPPxKp81BfBl94U6KvMwb61U97kTFLg8Z7xL4OAVR/c4yhLDfSYxGiLW8O?= =?us-ascii?Q?3gqZ+6AdvqSUvDYstJmFYfc3Ba5zHxTs1xIFYItevI/uvOeSXtKzyMMFI+DW?= =?us-ascii?Q?SDNnHke6jBhrGbKLsZSjTLdloA4vDwzopplBvSp6xXq2sk7y8O8wM65IIaap?= =?us-ascii?Q?R20/+mlWEdCk1oRo994Ptb5axCA8ZGtqsYBNXKrl50JUof6FncHpN055Z8AT?= =?us-ascii?Q?zuYPgr5DRMwM6zQu3AQmMbEAW7dxRf4NcLSkbzb9ImK1XodxyGgqP46wgFvF?= =?us-ascii?Q?AxzCyo91/e0WleS1GKVJVhj6REyI36JhnuxKGtjZZ30ABQatXUHeIxWqXhaE?= =?us-ascii?Q?6bh7EsHdlb5TJGUd/cw3seohpi8B3kF+pbb+4fH1uzAxP88w2cxe/6Jb/Eax?= =?us-ascii?Q?+ALiOhHTGJX06dQuPV6aVTezul6VqfMocDnj+CfqG9FsuvNmP3pfemotoa2B?= =?us-ascii?Q?/RZbig0ueDWV7Lt0xoCC+omqFJK8mW3QZkoOgiT14x1MQKlBBxyzBCGoqtu2?= =?us-ascii?Q?RbkG7hjtWLzanBL/9KQzIHzbBngSsEGeBjTzJRWc5nXaBlExQTWoukx7mPM9?= =?us-ascii?Q?PEmNeLgFTDp50156hTwTiUjwokz/dWL3N/fy89ZqxU4bVAlT80oBZL5Ukz5B?= =?us-ascii?Q?0gaLG9VRVauSxpxeupYmDgVhEPNKcA9hjIQ3UrFzzzF2q6IA4m5QtPbSGqFU?= =?us-ascii?Q?DD4xUpn+SLUx4gNPdqcuOpzl+pryonCBY3QRzZwekfMGJj7Ubbq1E05YD31V?= =?us-ascii?Q?6tkmDNkaGw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c416e868-83c2-493d-b238-08df2683b564 X-MS-Exchange-CrossTenant-AuthSource: BY5PR03MB5315.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 04:05:25.8867 (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: EFyn8/aa7+xrEvHC0/ZgUgw8CyL+wBzZp4I6fgXnt9n2XfnZ7FB7tA2bCntCqC+AIu5kG6q+Ma0oRWl4H4yylQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PR03MB8428 X-purgate-ID: tlsNG-33051d/1791605129-7488A4E9-1E2ADA3F/0/0 X-purgate-type: clean X-purgate-size: 2578 From: Chunjie Zhu NextRIP is consumed on VMRUN as the return address pushed onto the stack for injected soft exceptions/interrupts. nsvm_vmcb_prepare4vmrun() builds n2vmcb from the virtual VMCB on every entry to the L2 guest, but never copied this field, leaving n2vmcb->nextrip stale. Injecting an event in this state can wedge the L2 vCPU, as the APM does not define behaviour for a VMRUN with a garbage NextRIP. Nested virt is only offered on NRIPS-capable hardware, and NRIPS is required to be advertised to L1 (see start_nested_svm()), so the L1 hypervisor is required to keep NextRIP correct. Therefore no conditional logic is needed here; an unconditional sync suffices. Suggested-by: Andrew Cooper Signed-off-by: Chunjie Zhu --- Changes in v2: - Retitle from "x86/svm: mandatory update VMCB nextrip for soft interrupts" to "x86/svm: Sync nextrip during virtual VMRUN" (Andrew Cooper). - Move the rationale out of the in-code comment and into the commit message; keep the code comment short (Jan Beulich). - Drop the stray non-ASCII whitespace characters from the comment (Jan Beulich). - Drop the speculation about garbage/invalid NextRIP values: nested virt is only enabled on NRIPS-capable hardware and NRIPS is mandatorily advertised to L1, so the L1 hypervisor is required to keep NextRIP valid and no conditional sync is needed (Andrew Cooper). - Cc AMD SVM maintainers/reviewers per submission guidelines (Jan Beulich). xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index faacfe007832..f2f3f9d14ec6 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -465,7 +465,14 @@ 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 on VMRUN as the return address pushed on the + * stack for injected soft exceptions/interrupts. Nested virt is only + * available on NRIPS-capable hardware and NRIPS is required to be + * advertised to L1 (see start_nested_svm), so the L1 hypervisor is + * required to keep this field correct. + */ + n2vmcb->nextrip = ns_vmcb->nextrip; /* * VMCB Save State Area -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:14:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:14:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444961.1661436 (Exim 4.92) (envelope-from ) id 1xFU5R-0000VI-4e; Sat, 10 Oct 2026 10:13:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444961.1661436; Sat, 10 Oct 2026 10:13: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 1xFU5Q-0000VA-Ur; Sat, 10 Oct 2026 10:13:52 +0000 Received: by outflank-mailman (input) for mailman id 1444961; Sat, 10 Oct 2026 10:13:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU5O-0000V4-VP for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:13:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU5N-004mxa-Qb for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:13:49 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca0f83-e002-0a2a0a5209dd-0a2a45068568-48 for ; Sat, 10 Oct 2026 12:13:49 +0200 Received: from [52.101.193.37] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca0fdc-195a-0a2a45060019-3465c125669a-3 for ; Sat, 10 Oct 2026 12:13:49 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by CO1PR03MB7916.namprd03.prod.outlook.com (2603:10b6:303:276::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.20; Sat, 10 Oct 2026 10:13:45 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:13: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=C8NNEPEDAuJCMq7RJO70uvbsHSC643tPpWropW2sS15ecVzKgt8PmliyX4kgoma/BRXSYfuylFwGunoxUhBjzULPG+noNOIT2YIjIp+bz5xonbxnmkeosDCwAR0k8Y7WrEUayE66x4ppkyC5es8qZa7HaTI3rp00IzmuZNz7h5r4kPIwxlN5g8aO2dvMZGjWiPXeuJ8k2tpS+z4RUjbqn4k5eYijZS/o/OcLSNrFmAxBUJjyGtJhoa6szKKDxLnrZDWJjfKjoDQuI1KxFOU88OLjFnmAxO0VF7MIMWpoMXpa/GJK1KRCQd+jwk5gwHLLQ09yYVbVnNYmQFpvLqe/VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oqugbetrJdX8gVZTXaNh2smkuMQZeQG1KnruYZO7cYo=; b=zIERtxQIYpFVWc2BVVJqTLtaFn+lz0z/tkDnpbLtry1YXiFvxfjWz+jqbh62Um/b1MpYqqWJZuiC6rA1VfJ1/AxrcfxXDiYQ/idoXgCQ8UxQ37rvwXk1lgEHZssvzcFaWLPJlkQkJ8LBhQeYa75ent0V50NCRGylhwOaYAtOL6TlOC8lBJuuzyLigqMKA4sJmRXJz+BTknLvnQo7NMfmEn5FJtoMcPimSLL09I6jO/c8x+1d4N8hvuZ9bc5w/A9ujf5vUfEJ1UvLNtcZi+QYY8/ZahwYmgbF/Z6aXGoHMqyAqqk9kFpjL0RKPnoJ/De7yFwOb15aCiy0mdcT+t1utg== 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=oqugbetrJdX8gVZTXaNh2smkuMQZeQG1KnruYZO7cYo=; b=DQN2s5CBYP6+JoMz7wpn+I6NUsIx+ull3+tGfshcNWac9V35g7srqWmr6xoZSoGg979/DQQ7kLcJaZiJH8BlB2B9Xodu07s7oveHAEZ9iVuqJ2qMbFzPYSJqU7peQnejaWJDXeocj8MFGo+L+GkK0fiZcXqm3adcrv49eNH4G0Y= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, Chunjie Zhu Subject: [PATCH v2 00/13] x86/nestedsvm: rework nested VMRUN/VMEXIT handling Date: Sat, 10 Oct 2026 18:13:13 +0800 Message-Id: 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: KU0P306CA0015.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:17::19) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|CO1PR03MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: 8785c17a-21ce-47da-331e-08df26b72a30 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|10067099003|18002099003|22082099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: Di8LRXtve735BUIQzK315agSuZUhHXT1MykaiDetteSuYO2I8BVr1gRjJ9/TCrEqPVqAnvBTDB8TdwaDTEoQo4UQIGI+XwEh+9OHKf+v04RMs0dYETrbJnnaXIXed93peffH3KGBOZZmwLZ2DHPNfM8ASLwGK7OSlhufOdepsqnedrKVujlvdL9V7c9xFrBVtW8UAye+1R3qOJIhyRDu1HDrXi86k6mSje7H9de1TUBGlFXrvltWvX37n2vLd+DStQ8R9lrYYV4lG8GF07E0ZxEyRmCEeWOVOKxJEB7HY1MdnHHvIXYigYnnEplQ/b7TuddQbkmJrl+Huke8u+z/CgAL5ss2tNiu8FrdwtsL0fcIL68ShZKzu0+BFtfj7cr3+c+lFu2jbmCUmZa72zA1QSWi2/IOwD4smFLrRRpkhcAOFwLm4Iaf4qFi0iANn7qHnknZkL8U/AKFbgolVajQvdosEpKhkBPG+dN9NeMH5cNmqY/18c6eS4pU6lvBiK+FajunhgttjltCdAp5jzYzcHHKTvJC/h0vCPLowQMN9fTaorPELorqC55jRTOR16nG3iEcXfsFVtFWtawYKOAEHQYOhTzbAvi69OULdBYNAyaRpZm2TTpCCNc7A6I/qxffZbyKNRZxbKNvMazuHvCJPW6J6baQN2nH1QDUY6Ox8+Q= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(6133799003)(10067099003)(18002099003)(22082099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2KfV+hNsN3CkmqoPhkQqh1OppwGM6MJT5AiOARtmSgl0+R+zA100tp4vmRjY?= =?us-ascii?Q?gjFE3yR6zVwSiA+Kl6mtODllp3klSxrleLzSt3oi65tcX3gy/yHGALxfe0+C?= =?us-ascii?Q?umHXMjL7k21csSB9PvC950HybYAJdXget0OuXgOdWAzTX7ku4tyFHQmCXlLN?= =?us-ascii?Q?g+TVs1W0gWDu8oNm/KSTBXevFgpFmJQUT6seFcefOB3SfRYDWv5qpzXfphYV?= =?us-ascii?Q?zqx9C+DKrY6Ozf3AdWTsPyxU1e9yMjg+ZbcJsyBfVQUQCxsvaOEoRYX6eaNw?= =?us-ascii?Q?NKfRtcKBU0Of7HMO+3HRhU+3a0rCM7sZN2jMkQh086L0oiDU/5D+Y+Qi4Ydj?= =?us-ascii?Q?Lvj+P6XK5Ypq1H3nOKAV/J7AfFEJFjp1xCUPdphB2fR4KhhU7isbjdUV09Jz?= =?us-ascii?Q?+9jj5h1ZNTVKuDeItN+ymmXZr41Ef2LyzX6QRD8u6EmsTwVvLHuWH48zPbLv?= =?us-ascii?Q?lDByWHjIW/E/CE3htZ2tV0hSXk5dfkSHewhRNg51vj2lb25U4/sKfVbJBJ7G?= =?us-ascii?Q?RPDv9/YQbRIhnr+9Cn/iYQ8iALo4w5CNkIaYZM/7hhtyTk8uHTN8FHv4i6iZ?= =?us-ascii?Q?4eTAy16D8uBXGZS72a8PKn2ydsAI0Nez9LDnZFu/iMCLIFDEsF1B/7gBythM?= =?us-ascii?Q?yovyAaPORfkUu6NPg1MKi5Uh6qgjQy+4mMmovN7lPhCiMRExX+LivSGtD4TJ?= =?us-ascii?Q?O9DJpUyJvlG4gAf/LQOPKHTOoRCegNtEndjKQ3tgg9qPqIOzVLYstzfL3rNc?= =?us-ascii?Q?XKKYDtkQIrDzUXIbOTYSblDLlo1YCwAQJDpkn4fZ5gJ7mTijjh3HRfxr29oj?= =?us-ascii?Q?rcK0hafFyAc8aS2gk1j8QbIu5OnZmWPGn2XlF9y9ul55JKuxXo0uATjNi+WQ?= =?us-ascii?Q?mNTuofE2IeEJegZ0FcZPkxxfG487UfZODcrTch2npkOzeV+Ke7H8yN2w6jnL?= =?us-ascii?Q?TOC/qC1RMH7fgKZ5AZ0ejIqxPc91DkPTz0JA6yKzy1gyLikNG31Q21pRTb5q?= =?us-ascii?Q?rR2bgkHW4q9JANNqwzXMsRmO6JAb2jBbevUTraknsfH40zLEgzI4L6pt2uvC?= =?us-ascii?Q?Y5uvc67EQFRdqxybRQ+ztj4Pd9HoboBGRn0I5UQIogIXgdseVC25Iko1yopv?= =?us-ascii?Q?A6gYB922GX23vLq7vGUqZB0IsO5qOSJIuntBrKexonEhxmXRBKujdPB4U7np?= =?us-ascii?Q?waLyFj1k9snZuoz3BFfQgVqt2/L8W0+ArPeEzSR/Ohg9DuMTe6OS8uLm+XXd?= =?us-ascii?Q?KZ/SFnmlv0okStJ2wGXtCrO3sm8sNa+G3SjzbliIaNmYPUTjB75tCtbmlXNx?= =?us-ascii?Q?yycCLh+OFX4jQSdVqUdO8x0lqsbgqJCJjJoZwoP8+4jjoTS57F9PveHmIwEY?= =?us-ascii?Q?8Op094a/9ktuWhAOA8nDHvQA8jM88dHNGFM3A4QGZHBArjMWXxCgylf8R2sH?= =?us-ascii?Q?nbdyfaG7tlhawlhZqFdVJZ4yts5MNob1faJxTR7iboB8Zo9+NlDRtt+0naEo?= =?us-ascii?Q?4nH6jEaEgkOgv4V6bC/3x3V7WINyIwNmoz1Kq12DU1jO40tVwFTWab4TRB0g?= =?us-ascii?Q?ri0iSGnd1TN3N3mq1S+7g6V3GHdo6hj2LoNi9BpdygFigwSC0RWZQCYI3k/t?= =?us-ascii?Q?cvjOInf7d9Cu8Ykc7xATKSLsMGyO7ezjy/0WiGrbb5PXrSCsoTND2+KkgXZQ?= =?us-ascii?Q?kOAuQEuNLl9KFysKjiN9iA+FGExduaTo5O9sL9zVeVyO5FesT+PIe1ZsOSdq?= =?us-ascii?Q?TCqC5jSCwA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8785c17a-21ce-47da-331e-08df26b72a30 X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:13:45.3519 (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: GXTQv6b7shoD/XcVAhZXB5Bfio4YgmOfXmD1XhCxmLGPuvRZh5c0zaopXY2ULAJSAHem3u8SbTB9L3unH6Q8gw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7916 X-purgate-ID: tlsNG-16d1c6/1791627229-FC80577B-2887AFBF/0/0 X-purgate-type: clean X-purgate-size: 3348 From: Chunjie Zhu This series simplifies nested SVM execution by removing pending and deferred state from the VMRUN and VMEXIT paths, and includes the nested SVM / Viridian fixes the rework depends on. Changes in v2 (following Ross Lagerwall's review of v1): - Dropped the v1 "x86/nestedsvm: update vmcb correctly" and "x86/nestedsvm: fix up" patches, which mixed in unrelated bug fixes from our internal patchqueue. - Those fixes are now submitted as separate patches (1-10) at the start of the series, with the original authorship preserved. The p2m.c change from v1 5/5 is not included. - The three rework patches from v1 (1-3/5) are now patches 11-13. The stale_np2m handling from v1 5/5 is folded into patch 11; the rest is rebased only. See per-patch notes below the "---" line. Contributions by author: Ross Lagerwall (patches 1-6, 8-9): - Fix CR3 MBZ check - Adjust L2's DR intercept when adjusting L1 - Use the correct VMCB for vGIF - Set GIF during VMRUN if vGIF is enabled - Viridian stimer direct mode support in libxl - Clamp Viridian features to known set - Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 - Fix VMLOAD/VMSAVE state handling when using nested virt Stephen Cheng (patch 7): - Require VMSAVEvirt for nested virt Lin Liu (patch 10): - Don't clear TLB_CONTROL on #VMEXIT Chunjie Zhu (patches 11-13): - Rework of nested VMRUN/VMEXIT without pending or deferred flags, and removal of nv_vmentry_pending Chunjie Zhu (3): x86/nestedsvm: update vmrun without pending or deferred x86/nestedsvm: remove nv_vmentry_pending x86/nestedsvm: update vmexit without pending or deferred flag Lin Liu (1): x86/nSVM: Don't clear TLB_CONTROL on #VMEXIT Ross Lagerwall (8): nestedsvm: Fix CR3 MBZ check nestedsvm: Adjust L2's DR intercept when adjusting L1 nestedsvm: Use the correct VMCB for vGIF nestedsvm: Set GIF during VMRUN if vGIF is enabled tools/libxl: Add support for Viridian stimer direct mode x86/hvm: Clamp Viridian features to known set nestedsvm: Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 x86/svm: Fix VMLOAD/VMSAVE state handling when using nested virt Stephen Cheng (1): x86/svm: require VMSAVEvirt for nested virt docs/designs/nested-svm-cpu-features.md | 11 + 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/cpu-policy.c | 3 +- xen/arch/x86/hvm/hvm.c | 4 +- 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 | 305 +++++++++-------------- xen/arch/x86/hvm/svm/svm.c | 226 +++++++---------- xen/arch/x86/hvm/svm/svm.h | 2 - xen/arch/x86/hvm/svm/vmcb.c | 32 +-- xen/arch/x86/hvm/svm/vmcb.h | 3 +- xen/arch/x86/include/asm/hvm/svm-types.h | 7 - xen/arch/x86/x86_64/asm-offsets.c | 1 + 17 files changed, 302 insertions(+), 385 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:14:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:14:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444963.1661444 (Exim 4.92) (envelope-from ) id 1xFU5e-0000k5-9j; Sat, 10 Oct 2026 10:14:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444963.1661444; Sat, 10 Oct 2026 10:14: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 1xFU5e-0000ju-5g; Sat, 10 Oct 2026 10:14:06 +0000 Received: by outflank-mailman (input) for mailman id 1444963; Sat, 10 Oct 2026 10:14:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU5d-0000jK-6L for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:14:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU5c-009FpX-4X for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:14:04 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca0fec-8faa-0a2a0a5109dd-0a2a450ab500-0 for ; Sat, 10 Oct 2026 12:14:04 +0200 Received: from [52.101.56.60] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca0fea-f2d2-0a2a450a0019-3465383c1759-3 for ; Sat, 10 Oct 2026 12:14:03 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by CO1PR03MB7916.namprd03.prod.outlook.com (2603:10b6:303:276::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.20; Sat, 10 Oct 2026 10:14:01 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:14: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=Ae+fUicMJoFK+jbaez19ylFeT6C/9bHWfrTbLtcdZs3PQaOEWu6F9hG9CPfU3D56yRGn7l0UK+zHz5eWdQH1fI9j2yme5SrNmzoMaele5SMSiM6HLbdMVunTgNA0vfKZtp0WRyvE/a2QqAy7Aq6TlN/L/2bAjIdP1P0y5L5vOGp1QdswGh6/CYISmmgM0BSWvc/QVKeux6OgmrRJoqiGlWn094N9q2OV5iwPzU7H4pJgm8hztd29uk8A4gcmU5iysXJNvza2NcpNmu/x4Nr4RmCVELiISkmzJn0pTnvOyL4sVYAV2aKUYKdPeLw+LAUdfqYENcz3wVvKtKAlcQE59g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p45N7ux0N530bLgT9Agjd5ubAblfxj5lZPu2zbDLpDQ=; b=JCkepnfeEoRVZz+uaIUMgI3IC+L/iBoDAsz9GuctmqnV1KCKLt9zVWpEoID15dHQ5bdEH561s3o441Ovj/8k4QnmB3/Q4HGy+/3Nh821uR3bhTn1mDJl9Dc/3Vsrz18Iof6/zDaMk0gYwtG8c09VHoRbiOLkMxAfjYiK9BLfyE2a24Jp/CGt60GOKPk7weJSek4IoccTmolYExldTTfCvK5n7H3jtB2UiHEz6hbgx4NmZnzL9BoFk/FJMS4sTGOtZ+UNSZBVbMUT1P8q6iZfQbSHZhKiS59wP/LMwaRRHahFlxddWYwkKT6RKgaXXrTFTfMVCaw7hNcbHgZrozbc6A== 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=p45N7ux0N530bLgT9Agjd5ubAblfxj5lZPu2zbDLpDQ=; b=CM+rbOyceVHA6KcNyvVdptwJswSSn2ItDH/+2wkudq4ZPQ6Knxqbbh3wSDglgD7hiJgvD+NiFVUyv6YHQgMKVFPZcTfBirE6jK75DrL6TruX3+wSv5S08XdBWJAodMOq3kj+IaYmTiuZNHAOXvzVf4VUmcZeXB8+pncWDQ5vjA4= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 01/13] nestedsvm: Fix CR3 MBZ check Date: Sat, 10 Oct 2026 18:13:14 +0800 Message-Id: <56d1229d7efc8da215272a7f03dade9e293652b7.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU0P306CA0063.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:23::11) To MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|CO1PR03MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: 720fd19b-aa29-4cc7-9991-08df26b73453 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|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: rkfniI30vTV5KqjHdogXoCLQvWVWDZAcY41mk4lz3OQ9KjPDys3P6Oh9wnYDGGcFm0UBMbiM4QD/0qDxaIb5giZyZJkxh0TzYaasF/JNMynprou7nqbNwA+0UWm8SqHzPSaRXHjuzUSJnF/b3YGDZCifjZfEQ08s1H5yk6Gd6ZIZM63+u8WS1EPhD70HdtEXJGzBSyvlXarZa3vNMtrIpRVuB+GQJnQ4gPahqVbUK6FEkdmbmj4iqroN2J1m3Tt6ITpZUI2of7deNfPj+UP1vJMN5x40aoTACuSBIJcYayUI1TrcqdULsJd0cm/PHwaXbPr+Bm1o28nQJUhvnBG+39xkySNprZDcpJSOGP1unySiZhPwi6PCbxJUesa42v5zwDMbN3yGFYd1uD3RN21CpnnqUpeKi4RexW9hCNdE+zJFMaKL6Xv59NvkCgFlxHQImKl2odam69tWtzG/uOaxlODDw+uFJ38UkuUJ77f0S3UUFL1XeFvttKA/f0pw/2mbM5D97q2pdw7wVy8QgWQbxxp7mC33GDA64MfkXyPyIbCKR33vk7I3ND8dIJoTcsJ+t6U9iO8BNXCYbkepDs7Q5hvyj3LGMmOB8/Fuhgnv/CvMMKLD94cxG8EGGyNw6UcaRTxa+4bzNATfDmzJ3c+cvzasmBQ9RHpeaaaaQw1zTDQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(10067099003)(18002099003)(22082099003)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?L6BNKkgonILu8blSeujFgub2XA7yifTAnxaQZDyQyI4g7Efc5L+25GeLUg3E?= =?us-ascii?Q?l+viwXsevLHKgwCLx3/S3O9NofhBz/K+nhlII8hkCspTjHpmwwNh3MVcS6tt?= =?us-ascii?Q?HOHOpqxzNSnVtfr3naLssb+y9gEA5mVYrf7gK5qK3q7we8M809/dnhFAdpnN?= =?us-ascii?Q?/HU3EhxMddSG2bJO/B5tSVC03KgUzdphcepFMi36dy5BMwkU9OSwVJvHaSjm?= =?us-ascii?Q?iM5mhcLfFGiOgu07k5NVPgcGcXo7QXG46pvSuGefsi83fCXXb6r/amBCtCfO?= =?us-ascii?Q?61xxzdX2rYK9kSC+JyZuHtVM7LVM1wVcTbXwc1k01Jz46EdgqlE3oYbRb9sg?= =?us-ascii?Q?sh+cxfiBKkLn2bDYHHcSFtz5LgZ2yI7nJWDPxVZOPURMnZFtIGxVD3SfKYFV?= =?us-ascii?Q?ntgXclSpFLGTmDnyyQii8UHtSW35TfCpSRB8nOH69cKxfAzGyK/6uqz6Zby/?= =?us-ascii?Q?iYbaloqqqXBZ4d6neCgYdcF4HtaC3Gfm1mVK7GEBuxwRoAzVex16P05lGM63?= =?us-ascii?Q?bZtzX8qptCRcoqligxU4r0nkzIrCbjQd8VZ4/M7w37XysRrwlbo2UNTmcOuY?= =?us-ascii?Q?shjeirfJrAQRMXiSRl3gdEf4VoYheScoiudvfO/I1rcFMEswUzNQdSDb70ac?= =?us-ascii?Q?lsuC4Lb4nMczQKZob4cnSMTWTf99PjHUnDYl64QuKEAAGog4NyrqoPyVep7g?= =?us-ascii?Q?bX2X3dmvT0Tx8AlPywTOISJ72C0AGCMK8GokBx/CjDEkK7Np5TbgoLqe91PJ?= =?us-ascii?Q?ouwWW4Jrt0vf+hkeESnGjsTLTScw0TJ4ioseKNjG5Fo/CCp9FWl24yJXPuH1?= =?us-ascii?Q?A+xBSK2tKOAO3dJfv8QdEjumepoqSGdiolElhFCydjco2aMMvsFhC8F9vLjR?= =?us-ascii?Q?lT18lN8/Gc7jDrkG0cg3Qz034Q3xiPRfBJpiuF7qhhzChXoQInpr0rktFXbz?= =?us-ascii?Q?QMUcaNc2lUrSY2ElrzK8SHMfINf1kkhMJXwuK+eGa2JWVWgb1/RNAWclo8/u?= =?us-ascii?Q?P5zFgev9gxsMInrhJYo3kVefDV0EoJJ7EdySZDP2OPuzIaH3A+iT2oKFDLyY?= =?us-ascii?Q?Kwrntiw1+BFJSJ6VhoD+nAbHx4KeNci6XUXmxP9DbOtE+hZDm8bLTWp9xcfq?= =?us-ascii?Q?tLkQK9t3ocbYpseM3etzt2FeACeN22h6KIYNwQsB6tIZcJElJCDpYAA7IBNS?= =?us-ascii?Q?XlsYvzGrob210MBvgRxl50siF+iHaufMWeAsyqDCYqGEo/DMLs2Vu5GzV/xY?= =?us-ascii?Q?Xi091qCa1sno44u4WxECobquDISEz+Wn6Vv0+QSDnsifONFTgkEhCx/MEguV?= =?us-ascii?Q?VjrfqsuTBwq/wRcf4MYCWbI2eyg/q8UpfmhYV/RyuY7Ge9ad+X8nVBc6SgBD?= =?us-ascii?Q?6nwa2qiuWm/HwHlAWMaQeUp44XTG7G51DbVFEV3toO/vByn06nhCg2ZCWWMU?= =?us-ascii?Q?Z67Ls4Yv3wMiu4sl2mM4599dmqcZcfTnV5VN7WDjDyDF1toO47LFr+Ek9CxU?= =?us-ascii?Q?Ai8P9CEfnoe+1V5aiYuJKrGxZ0zRNvOBlyGm8GeU/q0USR9QmsngrlqUX1kR?= =?us-ascii?Q?JJDXuj8cbyO7Zzz8lFX09H5O3IcWMHHkifZ/8kErApEGMZoAtD100UaAh2Af?= =?us-ascii?Q?GGkIRlad2ijF7L9j8gbNp608neckhffYV1RftKw84q/n1suhbUmhgVJIlKIZ?= =?us-ascii?Q?OgxEPWPA9QzlsahenTsF1RKelXIpSEjzb9u0/17u3SpXL4BOei2AMIaCKgNo?= =?us-ascii?Q?Jk86PjjYpg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 720fd19b-aa29-4cc7-9991-08df26b73453 X-MS-Exchange-CrossTenant-AuthSource: MN2PR03MB5328.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:14:01.0739 (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: Yz8nxC92dQjo9kjqkK/CWLVyJOVfWiSHc61yamT5t4/3ClH/M5UtRAiRZehpeBuM360DxZbsizsZnmwYmeOrKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7916 X-purgate-ID: tlsNG-4011c0/1791627243-51EC2CFC-096229A5/0/0 X-purgate-type: clean X-purgate-size: 1315 From: Ross Lagerwall The existing code checks for any reserved bit set while the APM only considers it invalid if an MBZ bit is set. Relax the check to match the APM and hardware. Some of the reserved bits were observed to be set running Rocky Linux 10.1 on Xen on Xen. Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/vmcb.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index a6f09672a7c5..39b9e6bf2068 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -354,10 +354,8 @@ 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))) ) + ((efer & EFER_LMA) && + (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) ) PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3); valid = hvm_cr4_guest_valid_bits(v->domain); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:14:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:14:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444965.1661453 (Exim 4.92) (envelope-from ) id 1xFU5r-00014N-Jo; Sat, 10 Oct 2026 10:14:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444965.1661453; Sat, 10 Oct 2026 10:14: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 1xFU5r-000149-Gb; Sat, 10 Oct 2026 10:14:19 +0000 Received: by outflank-mailman (input) for mailman id 1444965; Sat, 10 Oct 2026 10:14:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU5q-00012I-6O for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:14:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU5p-000Nv5-Jg for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:14:17 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca0f8a-2eae-0a2a0a5409dd-0a2a450b898a-38 for ; Sat, 10 Oct 2026 12:14:17 +0200 Received: from [40.93.198.56] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca0ff8-b7e8-0a2a450b0019-285dc63864df-3 for ; Sat, 10 Oct 2026 12:14:17 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by CO1PR03MB7916.namprd03.prod.outlook.com (2603:10b6:303:276::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.20; Sat, 10 Oct 2026 10:14:14 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:14: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=Ux/prACwtzzi3TK/ndwiSAuMQgMteOV8p5IEPNwkdUE9B9P+JcpWD7gl+s8cQb4+CBNgy8UPMVtTF29ll4JOQcG++FpXQWi4f9lERL88cV6F/n3xOIum9fhf1O0CQdru05TrCcmHn/ag3BaRL2WrNGwXvVQK3AnrcSuCEwPyVy+Jb6HmwLwF6J4PYxOgpy2CINnXfqoCdl2B1bzSyA8nDajfZN6cRnMW7HljoEszJXOQmpeIEbqyqQN4NQZezW4l70RfqOBq0vxH1rXJGfCUsTDlqDINjNdUkwqZpHQesrMdTtx3prufZf5TtCjzIAHV/YDjioz48DoNgMdCdDk8wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uMc5XsDxFnIKWsB/TD9NiKgookFxuMjyFAx2AsysM4M=; b=lmtRM/Wmvj3dFaTYKfq2dOfe510VhJl+sG1Pgjhr8eYfGqjyqkgdkdNlg6E16WtntwCz0IKuzt75cDW+Me7qPMw61axLhOalLofQn4Cgn+HwSgZ1Hi2OmCAnnsNmM8n6hs4dY6ubon2rph6G4M5SWvkocHWPaInMy3/bEX/xJwISbSYxcnaPaoJCGUum64AAjbn0+rkWQaySfD2lURJkdmYV7LTIC0uehYGVNgVsybM9VOvcDDH26DEz6BeZlE4guerXC+9g1O+P5rYLUeNGjQEDOzT44n/vkXVcSz9RmsXhA8qnK8OPwBimhDnBmxTT13AlGiaWnvgy6Rek3KeL2w== 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=uMc5XsDxFnIKWsB/TD9NiKgookFxuMjyFAx2AsysM4M=; b=XlYSSG0jDv17mE9206Cvv9vD/Ib+pcY3GWaTtlORqoQzdbnLB7kqhcYdlPvIRcHX8w4rY1AnflkkfCyEt/aLEeHEHHOoqJOeLycWgtmXQtQjys2kBRW5+chdj7mm+Mk5skQyq0U2MOi3bSBqiYgBc16tgHZ8bY0SqHHefYgkwQk= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 02/13] nestedsvm: Adjust L2's DR intercept when adjusting L1 Date: Sat, 10 Oct 2026 18:13:15 +0800 Message-Id: <9b6e4ec9a5fd34db2071adcf8e73b0c50a1528aa.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU2P306CA0066.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:39::17) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|CO1PR03MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: f1396176-9819-4df3-d5f8-08df26b73c3a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|10067099003|18002099003|22082099003|3023799007|11063799006|4143699003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: GH91WZ5JQdquz6lpzwc+2txRSWkxHEriGEN0BdAIVIolMdNFePmZ3n1isbliY9fpxURCF17mScvlI4gVciHUYn/rkGgjULJChFhrFyNpAl3eZxgnXEdumFEaviWQzoAIiyycQrbw7LT+FTPhkSEbHumPKqya+/RH+ggjKVMsKdVr6S4dziAtZIKwoCmvNxUcITRJ1N2w9HiZJUqB6HvsbAeiu4nVpcz6HbMBPpjoLyf382sI5p/Lk30Ylh92zsFdfVC7r8Sezb+eQNUP3jNOGjkJ5ksyhEKn0a3ztIUgEzXhunCP2DgHx1q1yagH4hTbQ19m6yDbjueqyXjV3alAC8MvVnL2167W9MFfk07U70SrD1U0JEQRloGQosj7MAAH1JFhICb1JVABHq8VGdo5Q4pu0XR9LfxgJCyvokFj1HVvCa1IJN8C321QI8wnPBpIIyUy0jR9CUJQU+6DwaK7+LV2SYf5qehPuQcbhFi2xgkkXvknC5vdP1kKR4LC07ZKTSqaSik4jQmlNAi/GZA3q1bFl2FfoPOVINDf5J7HN4aT42BpRaTvSo7sAvZogQmMJ2FgLNEa2eVOs7WQe/OsvKpkV4Xrclpfol0Tr4N578HC2BaFZCbKGWUX5iKYOOFxjDaw9S0l2RGZm/ozxti/hTVFvd8yHLJaXzDbeTqN30w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(6133799003)(10067099003)(18002099003)(22082099003)(3023799007)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tRwI49dL7JFgmE9/KSF1w5j5vmNYR2ENe1979uS7is4/VUkYH27j3LeOyA5F?= =?us-ascii?Q?gCT3+lLkAVMzFpQ5c3WbsvZ9XiOIbLwjYzwqpFWb+8CKvUSeWHVs7BvtlcU3?= =?us-ascii?Q?78n3SJ7V5KG+i8WGY3j/p/3K3nMNnP7DyadG3+D5HkxkvzD8kd5SpmoKHEUC?= =?us-ascii?Q?2z6BmFq8/dUJITZ3Q0Llg+8BIEkOoQ9ShJglqxE7SV5sWpZ4A8nSBoHYmW3I?= =?us-ascii?Q?t/C7daZkgvO86JnWVM8k+M7DrQcsCAxYA196aiXK8+kWhh0xE0MAr7FLN3Yu?= =?us-ascii?Q?glqstKoVFMDsSJ9SDb6UvKBgWgj6HF1ne5OZB+EoSNCIQJ2sKc9nOgbggz8V?= =?us-ascii?Q?cckyPWN3tKID8jykyeHwIz2uDnW15UE4E7ZHOq/636kODFf3wqGnXwELsp6g?= =?us-ascii?Q?4dwJ/n5ldtnNyEbBejiiLRNVBzQqvbKdoSXTot3O5vz9uV/mG5Cgb2Uu7wEk?= =?us-ascii?Q?uMg1iacaUgH9C3rEaliV/Ia2D33R6jBRE+6Y7ZORP5Ze5UamaqesF9R1Z10C?= =?us-ascii?Q?wr2kV9C0Yp0NH0dsIatHDrPjbRfSZebSgjNZYU0rwRPZL0ydW2YoytZLW0xf?= =?us-ascii?Q?M6FEHoHUG+kKZ7CvOcyl63dR4HhBW0fjIddRq5lQljck9mXfl+ifcP2ZhT9M?= =?us-ascii?Q?xxYSi7nxGMraIbv337ZXUIjAsKAyh5desVf1vFIkYrRA9zUclSWPM/vdPt47?= =?us-ascii?Q?lYt4bDSAlIvuxJOMaA2AkQr9AyrlAPNyUOht6UwW+PrbccceU0LruUN28URI?= =?us-ascii?Q?2YvluVGdLb4dxepL3mzZ9Fywxm5CjqTJG4H9yw3ZY6/JXLW5Y+9JMb8OkSjG?= =?us-ascii?Q?PfeKTIXZOQZnJDe7W7hCIEd9iB8ujSpfMfYMJ9huph61/LPp9iyPhmBK6y+8?= =?us-ascii?Q?nFAKq/QX56P16siGtRJ3iuUzN0FXGvypO/xbm2VRRbMhDI6UMux86q1CZJWU?= =?us-ascii?Q?pMVgTysyVGHVFtfqrUY4xlJm2uIfE/v0wIIdp8UoJ5juwh/6DG+oLrxrVmU7?= =?us-ascii?Q?c0a5P/guF4qICU6ThnrviIGoXjFX6CSKjvPmjYnAJNmjzradSJf/sAXssT6M?= =?us-ascii?Q?FycTdNfKElhelcTLX2HtHZMG/QyZMwbxfg7qIdGYRdr/hIxB6P6xYFaDMLqj?= =?us-ascii?Q?MZD3YDhREmJ0RSO2hIapPq3gA9TDazzBjkVrqjE8pZx76VtWuYMpjXXjViOo?= =?us-ascii?Q?uKzx3TF2P9bIwwd7Fp9SGehiFslOzhBqh4HDP8X4o5cXMLGSmF5/trOGVUvx?= =?us-ascii?Q?5n6K+FiB2NaDiQiqEVVqJ1fuJQid0NlDFkWr4Bt1RfH4MtfZNffWzl402OVJ?= =?us-ascii?Q?+OVY2fFwPasBnUPcIoG6T+fvqeqnRqqvB9CbM3vcEvvdv0RyYOe4SmCw4pQU?= =?us-ascii?Q?66/2CpM5Ekq6ZIygT/G82CIQeFj/PvolAxRLuTLIE7rkuYRYdtNWPnCJyav6?= =?us-ascii?Q?CUnsmZCyMlD/scU03yx0KS0jo9h/08i4f2wx4vMx2oXzv1j6yAOcZ6h7tB/W?= =?us-ascii?Q?yzHYebYKMEiBx/Wbv+qIKlbtDgSnMZ6BRHJmyrsidQ7DaVOK1bUnkW8GC8hO?= =?us-ascii?Q?rCtu/XlCpmGaBPLqvLZkU/k3fIp4nj7lzYTvqJvJ6ULuKM04R7oCxiJnUGYj?= =?us-ascii?Q?dEgKYnUGuieGCfHKyG2d7nzRtrIkrxwJrnpl+Vuy+JfGRRzcD1t0pZHGcE+C?= =?us-ascii?Q?avH8RHdd0UHiWX75M6NIKOIKJqTc56n8cM5TKoPkdScN+5DYDouj1acZv9Wv?= =?us-ascii?Q?OEdyBla81A=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1396176-9819-4df3-d5f8-08df26b73c3a X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:14:14.6668 (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: 4Pm8YVuX3w41VADQHFCU1PbtTqQGD5BgJepTxNbTYfqDbdTAE8EJZ+vM1iDOe+eF1AMMCp5z3y7Kya4n8/99UA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7916 X-purgate-ID: tlsNG-42698a/1791627257-19AC09EA-7ADC527B/0/0 X-purgate-type: clean X-purgate-size: 1209 From: Ross Lagerwall If L2 accesses a debug register (like reading DR7) without L1 intercepting it, it locks up the vCPU. L0 intercepts VMEXIT_DR7_READ, which disables the intercept for L1 and then restarts L2 which re-executes the instruction and then this repeats indefinitely. Disable the intercept for the current VMCB if in guest mode to reflect what would happen if the VMCB were recreated via nsvm_vmcb_prepare4vmrun(). Fixes: a59a7be91b61 ("nestedsvm: fix DRn handling") Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/svm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f22c..8f97f6c31716 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1657,6 +1657,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( -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:14:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:14:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444973.1661463 (Exim 4.92) (envelope-from ) id 1xFU6A-0001ch-Ts; Sat, 10 Oct 2026 10:14:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444973.1661463; Sat, 10 Oct 2026 10:14: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 1xFU6A-0001cX-PE; Sat, 10 Oct 2026 10:14:38 +0000 Received: by outflank-mailman (input) for mailman id 1444973; Sat, 10 Oct 2026 10:14:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU68-0001aZ-S4 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:14:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU68-00GnTa-93 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:14:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca0fc7-bab6-0a2a0a5309dd-0a2a45058f6c-30 for ; Sat, 10 Oct 2026 12:14:36 +0200 Received: from [52.101.193.67] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca100a-4cb1-0a2a45050019-3465c143b498-3 for ; Sat, 10 Oct 2026 12:14:36 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by CO1PR03MB7916.namprd03.prod.outlook.com (2603:10b6:303:276::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.20; Sat, 10 Oct 2026 10:14:33 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:14: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=S/Er0rPP9no5e+uTD6maQQTDeKTlWR0HfVONH0rO537qKF41pc7LmCkK1WEk8RVqkt9dDb1kyz4uY5j/QVdYhtatHYkXs17o0yCy2mhQZm5LU7aKZONtIOdR9HfQ8jdCqgQhWcys1n13Ov0SfFeACGTzSztmn4086FehO7jXW72DCqmZH4w4PARW+DJDcViDHdH/GzJiKHEbPyxJ8kKkRF0mHyPnZ8WX+JRsf0f2nLmsopnZPUdhU9k60q8bwPCXjftdhY+OPX/in2iLEIFE/v582DdMPCbWrRcM8nklM6xWXOi3fN/3TUCskb25F0/qyKW+kuM6wBn/iAzLipMI5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fplgRATSf0U0Gi24zkdk5u+MJxVZj8K0K0i9XI/ZazA=; b=knB9zZcwRJW2zyW76DiCdGGxyzsLPmoIbNp1To83UQLXJsk/FyeK9Fj4kkWK434bin45NCCC0KplKhLxo9M++bcHk+ogGPGZfRw9EYpEo1+vOkeVz/hx7yRl96rh3inZecJZovTQdPRx0BBZMLlNBjsMBUYrLoAa6VnUXG68lj/ctbtXpAY8ODoLQydiy8dcTW7MnkgVIhFwFbdrQxWnOKXMj0OQKuff808nIs7N7LzIk3Z2+Hx9GgOBgUVcLBybU1c/UQ/TjEI2Qz1lvtDfeKvUzYnw7/BGhUDTmRzpw5viRwyCpJnJuZO5DLbXJvZ92B8c7RHV6mO7q5LCLnd4mg== 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=fplgRATSf0U0Gi24zkdk5u+MJxVZj8K0K0i9XI/ZazA=; b=Dl/pAnVoc2W/sPLwiqNkFdiGhNu8euhXLDcsl6xMGeqr3vbdtwLY9DwJhtyrFORiNviXSglnc/6LriKZgfMAs1JIZIugZ9DrwTj+Oqrc/MWpwP1XCWatc2jeGYDsjuhBQdiz74dRxVkJNo6kzDfEeBqNP23z7ZEF5QP3Jycq3io= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 03/13] nestedsvm: Use the correct VMCB for vGIF Date: Sat, 10 Oct 2026 18:13:16 +0800 Message-Id: <9c8767613e21f19071e3d7be7edfdaa33bc883cf.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU2P306CA0076.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:3a::6) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|CO1PR03MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: 14660939-74a3-4192-5778-08df26b747a5 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|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: Wg1QO3zXv4OmU47+vQ4/MowQNIeH3FsqcZ2Gb55CP9Edfvt0LKgI6KT2jfaJSCfMpFHdb5tP1pDbnskx9GI0rQNpzhCtZlj3/JELnyULPrnq+QR03QK35nXFFLXnF/HZNz5vU3E//mBI/qjhuPZh1DSZ1IeHPpNPzklMRAh5UtTX86v+PtnhMWIv/A8IK3PbmkppMY9pha3tqMoBr3Lgz+g5NywHWxwZSQud+r5vWWv7n7gcgU33BCNJZZpVFdlFrDkFfdcRiE246hzqlqkRGmieZsTLL3iT8o/htWRpGO6YRLGUilw/HwuFHsS2oreMzCbDBTHt5DUDK9CDVV32UzB+ho+OIMrXc5zfHNMNgmcN5RoixINBw1cK01dUL/YfhDRfHCisxH9YD+A+TLww3jW32H8WIiLBRzNLkuyV1/O+phgseGgKxDrRkvmMdDATaVpitdoihNrqne9/wS74ULodBfKBGH+DwpBD+9Ufde1hzYsyRrMetM7IOLNZhFI3Ezmjzkf851G7UMFtdBQCg2Hq7kj8+AykDlybP5kZFDoPQM0zPPskSn2k6FrWljdlJXLtsDVtPsYEV2gX+M6wGFP7fcw2racLQ5qveU76Y8pveBXCc9enzLaBkqzXeGW4A2ng5zw4teBpnSR4mLxTD+T6fiD89zb8wlMS+QBCTgs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(10067099003)(18002099003)(22082099003)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?PQtv4Np9NdvtCqrO4idsu7qyj1DJNgS61Ux8fQ9mDTOtSl5FIDNBGHc11zX+?= =?us-ascii?Q?AjqptbC0mjJgMHY6Q2gg9nvy5u4pPpt/OE0F7rMl1mOZbEm4cyx9U5sx+uD8?= =?us-ascii?Q?wz0yGICxEEF2zGGZWtyecTd25+/v+RyonpznZamkKOEx60vSuqOcqITgiPic?= =?us-ascii?Q?S0fJnNtq6iDmCgdOUvQe3cy3YcGwMEDMvmT/hKGqGrcqhzCKg2IRUHuERpaQ?= =?us-ascii?Q?WP6MdtoZe9SNdWbshLT1zyQnf0BZ4OT//GDlGwxGCwFQRJqAICv39jBOa+nf?= =?us-ascii?Q?bq94R57wjxDV9jO/LgQNUT0n7VrPMWAfihi0ppLSHhsr6TFiCTwb/Tl3M81a?= =?us-ascii?Q?K5HivGboC3MdOxZ0ViRDzjSoe31c6cyfIceb/7D00MUiQgmepXhZRL6J7I+w?= =?us-ascii?Q?Q8XGwTa5DZuvysZSaCq6x0QU7jVN2Xli0j44qSDN+uSk9AWVVZgkS3hD66pz?= =?us-ascii?Q?zFs5a4scuTB9q6P2SinmIUjcQVZT/s+3d8WyIWdo2VP+BTdFCLHkhw/COWCd?= =?us-ascii?Q?WQymq/8p8OvJW6EgrdgNLhQ8Ybm28k+TtaZM6ehBBZryY/BahIF6OkamxDQV?= =?us-ascii?Q?Hus7uX0togckt+6+5VD3oknJrs2TGbhKJppfg40+ZVyNB/QqjLOhG+BwmHoF?= =?us-ascii?Q?ztUCCECrHtBKfqAK/n6k57syT6WG4r11OGM0+woX1mWeFsuADFup7no4B17E?= =?us-ascii?Q?qEDyk4dfwmQ6Xv5CWze2cSGS9zBP9dRoKNheM8IukH4go0XVyyMjWTAq7CqE?= =?us-ascii?Q?FBjtRUB4HZbqjUqymew/wb9X0ZDc4koiY/gPRw1mhTNVucCmoYR/vfQZySkR?= =?us-ascii?Q?SNCVSPSNxEEYx2y4ytF6uJXR/Vg0to9BieDSOSN8J+EXleINw1xrB2+bUiHl?= =?us-ascii?Q?1aSmvlPg+myB1WcwZ94mix+FdIRz6rcoWMmhy9QaPdgT9U5ERYY7FBj61Y9S?= =?us-ascii?Q?LfR3OuBN61NSnJUDgR+QNfyBTLX0S32DhQzgU7MwviStOIbKdPB5xw0oV0RK?= =?us-ascii?Q?BPYw2pbXCS+sXfxKbJYXXia58hHa7qAmoz7qAJZkVvY25ISd/urY72tem3xR?= =?us-ascii?Q?9jQZNKup4h6Nnkz3MFlw5mfiQJTA1aweGtVKrS5PkBuYafj4KbKjjLZxxcbY?= =?us-ascii?Q?emO6HtG2WUasgn3OeIzOgYxfoGbm9QhgBpyLKk0nNyTGp2vem8t1O5sCrd0s?= =?us-ascii?Q?GExuz3nC5FkraFPQyeB4MBX+HhJLxarvqHpDT4wGI5O5mfEIKD+BVm8mWBQG?= =?us-ascii?Q?A7jvbCmQL8i569ZGwQ6C9bk+kM0YPf7+sYCU9I2jMOsJyopI9+GDH7yzpoOb?= =?us-ascii?Q?MpalPHLjXZvNOoeo/I/Y062rOFaV6Xw3ScJZ73OOgckgvocpClmA0+MUhFLP?= =?us-ascii?Q?a7HkzfrO6qrBj7EzFOtM5r2c6/9zkZk6i95tjudZ/e8yjf9PvERLplB8SVuy?= =?us-ascii?Q?LM78D+4yYFBQvDetH3JeXhBXSbH+jQNLFpsPLEtq53+Sv1lUT3+jzU0Fa2mn?= =?us-ascii?Q?oifJgDmSXK44iJNCyFPXpcs+UMtjPe9Xdb1Xewss1a9RSrBcdIGRuaPtpIF4?= =?us-ascii?Q?4Z/iSij0lKf3k4lnBcx+YPrvx6B0OtnOCZYQGSame2jt8H9YO6rWkdwi9ptq?= =?us-ascii?Q?EFjXBZXlUcVzrZ1iUF0zGkz5ERCmNFvA+ivlOBhmRmMH0YN9dyJze9Qfdo38?= =?us-ascii?Q?xl67hgGyIooyqE9z7OnIzxVtrD0w6u5/+yUq8n0SR5yG7VKyR1MfdjTrJMMe?= =?us-ascii?Q?znCzJABZig=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14660939-74a3-4192-5778-08df26b747a5 X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:14:33.6413 (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: 0bOlAa7p8ixUkDHesjePpyfPLYrHPsP/vg6O3dkCRzdfRFLzcHXIYsCl3E9bZQNZ9jrskmpJdFdw59Vdxp6jDQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7916 X-purgate-ID: tlsNG-c201ff/1791627276-F5AAF2A1-5B948285/0/0 X-purgate-type: clean X-purgate-size: 1960 From: Ross Lagerwall In some cases, Xen uses the current VMCB to check/change the state of vGIF but the current VMCB might be VMCB(0-2). Adjust the cases to use VMCB(1) instead. L0 may use vGIF to speed up L1 but whether L2 uses vGIF is the L1 hypervisor's choice and L0 should never need to check/change it. Fixes: 4cd0fad64590 ("x86/svm: Add virtual GIF support") Fixes: 05bb1116b8c1 ("x86/svm: update VGIF support") Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/nestedsvm.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 2e3b70345b68..8943d61e2b25 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1215,10 +1215,11 @@ 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; + struct nestedvcpu *nv = &vcpu_nestedhvm(v); + struct vmcb_struct *n1vmcb = nv->nv_n1vmcx; - if ( vmcb->_vintr.fields.vgif_enable ) - vmcb->_vintr.fields.vgif = 0; + if ( n1vmcb->_vintr.fields.vgif_enable ) + n1vmcb->_vintr.fields.vgif = 0; else svm->ns_gif = 0; @@ -1482,11 +1483,12 @@ 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; /* get the vmcb gif value if using vgif */ - if ( vmcb->_vintr.fields.vgif_enable ) - return vmcb->_vintr.fields.vgif; + if ( n1vmcb->_vintr.fields.vgif_enable ) + return n1vmcb->_vintr.fields.vgif; else return svm->ns_gif; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:14:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:14:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444976.1661472 (Exim 4.92) (envelope-from ) id 1xFU6T-00026M-64; Sat, 10 Oct 2026 10:14:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444976.1661472; Sat, 10 Oct 2026 10:14: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 1xFU6T-000259-1C; Sat, 10 Oct 2026 10:14:57 +0000 Received: by outflank-mailman (input) for mailman id 1444976; Sat, 10 Oct 2026 10:14:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU6R-000246-Bi for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:14:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU6Q-004n2i-Oi for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:14:54 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca0fea-e002-0a2a0a5209dd-0a2a4506ed36-26 for ; Sat, 10 Oct 2026 12:14:54 +0200 Received: from [40.93.198.39] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca101d-195a-0a2a45060019-285dc6277b3b-3 for ; Sat, 10 Oct 2026 12:14:54 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by CO1PR03MB7916.namprd03.prod.outlook.com (2603:10b6:303:276::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.20; Sat, 10 Oct 2026 10:14:52 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:14: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=diUAZW4sxBfhmFT0EYZkG6buYOjXz7Dpe3w/prS89Lix5P2OMEaCFFNelRhNLqqq6Fq4AkGa0axckLTE6J8fq+Qy4dJn4en4Xhux5cYHBG2f7oI6QwDqIyPMxXKi0RWeKa/H6Q6WWV40OKFfAVxsKRZSgdgqRsH0Tq3MndMYMlEdNUqnU8xzJKFnfs++G+wx7nJfjsnHzxAL6o/h6dttb6WNwAotInt0qUhiX+c1Zb09CsZ7XEeiGXAwx0dhuqOA0GnzVe2zklzexGNo4//aO9F9Fy0/m496bMwu+Qo/behfLq93ROfNpKyTWBcaJgUSLEv49pQ8/NY6TpmycYMiDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WdaTuBkbnXYbNEnhmF8wQG3H1dNpqN4nruFVqpzOWRA=; b=b9yCL7guTpSAHad76kJG9L77D9dLJbEoF+zCvMVVlXvXxfFGyykRXafIZDqFyMPLWCMGMwdTeVUnJjqA+DGrkNM/EZJPLIJH1sW+CUySIvArV2kIbY9K1Tnh2yyYoJseGAZtCX4vo1sV5NRyefwZg+L1SG7upN5Pc8OPukGRbOBM6U4Gz5o3IkTnt3ozXI8XSTqlnUXGr5R1m9Rb2pEBZEgj9u3t5BcDPvBI9L9I0qgl3QnNietIhKNpgN5quET9yPkeG+TU6GSqcafJkH6zC3ZGzTxiLkRyVn0nHK61UWiqlaReP306av340Kv/QnhDVZ0Y2VV4Mrl0ZvYbvEgVrQ== 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=WdaTuBkbnXYbNEnhmF8wQG3H1dNpqN4nruFVqpzOWRA=; b=t0/sbXqfOPouQG6AD/L9EQ/Yp+5vuhjGrtWcTkXZQwJNlRbm1k5a1+wtcXM36m4JIB6q4zpUkVVTJzNy/p5O4HHEClV53rF2dso+/fO1BziNL6wVxt8Gz5MOdGcYvR76hcvSotMIYoakUuATa5dqTVFE9HqPCi14n7/b6F3Z7pk= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 04/13] nestedsvm: Set GIF during VMRUN if vGIF is enabled Date: Sat, 10 Oct 2026 18:13:17 +0800 Message-Id: <54cb598ffad0679b1e0b74a73d68595b353c9cea.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KUZPR03CA0001.apcprd03.prod.outlook.com (2603:1096:d10:2a::7) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|CO1PR03MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: a89d8836-9646-4737-4bff-08df26b7526c 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|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: JXPes4sosAo1g0wcluFO43Grtt5aioG9wTao1UAfKO2aWCvPb/cMWvaitZp7au3dVF3olfzS4z4qZ0Kv4CQ9XgBLH0pGxWigV0feTZujoTyohSaVXBGfZSxdzcytRan5QQESnh3LF+B5mE6RKm2Y7aZYEYaDCTMeDYEMukeEciSZWXeJqYw8+A1Aqd6nZ1MLapHEIOAo8WG1hIikEv6/CdpmD7VMYCcYXwwWqX6cUZTn1nIpnQ8i2WjZT762PqxY924D31rEJ1N0DsnLjOSQ2fXYZUoCQjiMgqYUQBGeH7cu7l4pOHqQCuNB7slTJFgTIV+n4625G9P0HpnA3vyg07uDyV0/e5T77m25UC4mok2Wv7h5wk16XTJtVWRvnXGVlT/MsNUjCggoHt8M8iSAj6Lhsy55fMF06Ic8BY+tm8Ce8mB/raeeH5J7uNHdihKXRMMYRMvNa6lsO6rbLPlkUGz5dXsfXnqgOKr2cvtLDhprnlNG10iEU8k9I89ByAWFl/5usbeuzgcePs5uVbOVMMNd2VNIs0ZFQAqTUWQdbJRlR7dCbcbj1EM0VVQWIylYqsTprJuC2EsCq5Eb/zR4PU4UdEmEJA3jLKAQZtA0+9jZR0RGzs1Y8h0clDlHZVDad27yE8qIY4QeNLFhm9DJ/ja+OrnEWqRgeRpc+ti915Y= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(10067099003)(18002099003)(22082099003)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GFIIw7mFsLx0UpgBFFsoDjwZ//m8LV+8htT+4ubXBX4KOvTb7WIbZxVon5KP?= =?us-ascii?Q?X/uxwe7657SiQrBHIZwW0KeMxRz0hY7hGY09WyjlHO0WvjSu026C13iXsLm6?= =?us-ascii?Q?PVv296nolW/bHMaC4hgZiigMVbTlzzK9Y0F2zrpL8Vmk4iByhgv8M5BSPwl2?= =?us-ascii?Q?zB8QLTRy0cOzB7Lcv7pU/SxDFLAE+WNeNeyveioEyZKOBWW0pcxl50mJAIwn?= =?us-ascii?Q?cJYdYeKzW8iAPawF7ETB/Yuws6ooWIpzFiPC4imhoyNvgV1jr/8hSogZhaUq?= =?us-ascii?Q?0ymtZeW09WL/cPDjqIIpjMJYZfjdjiEQqDR1pD7BzTIhr0mUn6sV5dXIVoIK?= =?us-ascii?Q?9PDXReCTwpPpBjaXnMSMtHLgBJ2oaAR1fbdek6o8pQMtKGMl0zelnBI2HoHt?= =?us-ascii?Q?Niq1zgXUmneQId8lztWhNPnw4E4Vkmb2L1c9//itLGExeD1tRqC0H2sl3LxU?= =?us-ascii?Q?FKtD+/nMFORcJeCcgJ2oD24XZGCxpEL2CafqqqRz6V5XQrwxm0xwK8v2QK6j?= =?us-ascii?Q?0oO8cTtN5iRjYdNspiGpSn8bIqIbsvr0sTqeN9azz1rnp5K44MbyP40sA9Vd?= =?us-ascii?Q?9XqOjm+ZuzT+s1Bzd0Lmxsg7HazTYpY5wUzX7vbelS3mhkOtOFcq5gN7ZLK7?= =?us-ascii?Q?cZe01pVrTTPiYPk2qIz4Ntgh4KhAY3YUxyK/L12pv5T7n6uPwmgK8r/TZYyu?= =?us-ascii?Q?TrU47wtug1ie/CByf3vmckkxz1UPMXBltu2CgDxU1VhWzqYwJAHBudp3zcco?= =?us-ascii?Q?5BcB20NlL6KOQ+/H5YARepyMqIVPmt/tsRfO0LFnBU/SzGOr1ZKXMfxCTsoV?= =?us-ascii?Q?hhhMG5wUD6quYFsnaHj0xBMtm5P74ezcs1EGmNbXDo+D4jpZP4Ii8C98SAAw?= =?us-ascii?Q?l/uSF9VCNsP4p49I6aTTG20ZJdwKvPTMn1djBTpDV6GDPcpd46pnQ4ZU/rN3?= =?us-ascii?Q?Mk2Tz/XGl7Plx21+k/GGwc/XmidFkFQSdbjgQ5ymV4rp14pLT/DKA2rf1sD+?= =?us-ascii?Q?XwiUYkt2cbg8BoIHuMneVDntNi6SEnmVMGehmAIj/O9U6fyFtI6AUwpQuFJk?= =?us-ascii?Q?CyBwDK2RM/YUiYDxLAo8X63yeHuFBl0biqOd8NYyFeNwJhts7Uil2T7IHqOa?= =?us-ascii?Q?2S5YdTqlinNfn9lHD4qPS8QfHy+sgTYI1duz6owKwiF/zd8JNoWr8pHcgwhx?= =?us-ascii?Q?al/rs8QcOxQM045XkVTlWVVl7gVGGa9ly5OZCHvEihfx2uTJDZ9AHCU1otg7?= =?us-ascii?Q?Ps9ADX/aH/azfCN7x5PPiY8q8rgBIZuZSjx6sqCfsHtk0jW/XFQPFbcWla63?= =?us-ascii?Q?Nm2cw3tkeRca5tf07bJpaFtV2dVyYAM+wV1WcCIZtscYXYEbxHRr/eXNOV6O?= =?us-ascii?Q?ZMzO2sfUoQp60q5ab6g5KfqIVR/qYdzaxoQy1nonfcJngDCXf19TjbkW4Nxv?= =?us-ascii?Q?hGUTMoQPAtO/C3ysL2k3tEVGeBgTilDtfc+8rAS5QpgTTSaLLAOEQsYnRNyB?= =?us-ascii?Q?Pffg6grzeA/EEYbLyydPOeDefy0Svm3mGmDtqtfltEcK/wDG19rEjWOfStUV?= =?us-ascii?Q?shgqPFvFs05rFUmndrE2lL3nc+x6bJgKkvF7z6wCuoddG7mpZQoMIzIOr1Sz?= =?us-ascii?Q?MbL1qI6U9GHwwv+Hr5qcAzax5+9jBH7rsl2ph9jkOH4WjT3tpS8m7VNbX1w7?= =?us-ascii?Q?d/E2jrURJxixFUSMQQaHx8tGcm9swaWMtx9axKdtci/vXFzA94/cLB2nrx1Y?= =?us-ascii?Q?vgldBE7mVQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a89d8836-9646-4737-4bff-08df26b7526c X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:14:51.9058 (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: BqbZpXXHx7HtF5HYki7ptRhfV1PvrP56xUAyQ/1fUqWk5ibVpWk0mtVg0RCWUZtqzMnNsKm1lqy2iE4XmmeBrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7916 X-purgate-ID: tlsNG-16d1c6/1791627294-F7ACA77B-592F9F35/0/0 X-purgate-type: clean X-purgate-size: 1455 From: Ross Lagerwall During a VMRUN, the GIF is set by the processor so when Xen emulates VMRUN, it should set the flag too. This was already handled for !vGIF so handle it for the vGIF case too. Fixes: 4cd0fad64590 ("x86/svm: Add virtual GIF support") Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/nestedsvm.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 8943d61e2b25..a76cec1fecf1 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -625,10 +625,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); @@ -673,7 +675,10 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, return ret; } - svm->ns_gif = 1; + if ( n1vmcb->_vintr.fields.vgif_enable ) + n1vmcb->_vintr.fields.vgif = 1; + else + svm->ns_gif = 1; return 0; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:15:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:15:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444979.1661480 (Exim 4.92) (envelope-from ) id 1xFU6a-0002Rp-HZ; Sat, 10 Oct 2026 10:15:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444979.1661480; Sat, 10 Oct 2026 10:15: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 1xFU6a-0002Re-E1; Sat, 10 Oct 2026 10:15:04 +0000 Received: by outflank-mailman (input) for mailman id 1444979; Sat, 10 Oct 2026 10:15:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU6Z-0002R2-Ok for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:15:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU6Z-000Nv5-5f for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:15:03 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca101f-2eae-0a2a0a5409dd-0a2a45059e2c-6 for ; Sat, 10 Oct 2026 12:15:03 +0200 Received: from [52.101.56.19] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca1025-4cb1-0a2a45050019-346538139170-3 for ; Sat, 10 Oct 2026 12:15:02 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by CO1PR03MB7916.namprd03.prod.outlook.com (2603:10b6:303:276::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.20; Sat, 10 Oct 2026 10:14:59 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:14: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=YBtZu5u9peWF/SJp77kuhJ7eaLrvcNkyj9Xm/bcRMcuLAnrUHCSKKJ0YqIk+U+BJoGsD7JuBRbMV8YuLLX6oJ4FQTysLe1bRtQBeaQ5Zvi5EbS+ASmhXOUMTsounolOoFodMQQKb5aKAjglzV25p9ULKXbTnkVyPHl0qwyxRkr1e02IjoZKW6hZRSXRAMUefbaUFYpl7MHA7XvrMGDL1dsDuDV0KiRKpX2dJ0sGy1ciDnPyAE87kLFpMXkDJ5tLxogn8nV8IMbIK/IjdKQ7N+ad2mbdeI5hy9jwcGXb0xrCy4soydis3h0j9Wf8RRd8hVPCY6PJB8cq2HxNplno7KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dWE20jPhPc/AOUVQe2SDwtuiBVTKCXXIz1GSqI7YLy4=; b=wAhLc4FRytIDa8v7o4oRzz9YGnUIENhPg77kWX4AOc6miQQCnp+z4g8sf3q4FO+APkhHy06Xn2uQAtrz0R+hh6nyEre4CoJsgN9gY3NeAkZHf/9Yy/YGD55uR1wZuJ8mlBJSph4GtaoQsSxlgHyAPkdyYTqx9jA3ZcAECq0R0TSMqEG97F0kJ4G/m8pBaVKnp8W6uBu/c8nTlF0UAWMusUOtf2XEArRGy6vzRAt/UlG6CX29nD2w+2vV+EpdXiASX5VrqreJQ8ZXNW0Mu6WmMVjgIXEMgatCY11N9OJBXHy2xuE1JNESUyg9S5dU6WQnhSegV6RVDXzVFjtqVbs1CA== 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=dWE20jPhPc/AOUVQe2SDwtuiBVTKCXXIz1GSqI7YLy4=; b=CwUWqfqw3yo+t5jQYWYRjv4sGK/AoZLSAbngai7dv32D0Gw+Ao1F5txzzq17jykz+HYL1AqC2Ggs1APdVAIqtseSNRt3ecX9BdqIWQ5sCKC+achGFyejIPbV343popcMJDOUmOOqGzTkz8BRlX8CI7w4wKtSyO4jgZo/lTfd8IU= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 05/13] tools/libxl: Add support for Viridian stimer direct mode Date: Sat, 10 Oct 2026 18:13:18 +0800 Message-Id: <6e26064971c8c4a4a5edbceae0b536e60fdb02fe.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2P153CA0014.APCP153.PROD.OUTLOOK.COM (2603:1096:4:140::6) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|CO1PR03MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: 1331e807-fd5d-4d06-ad31-08df26b75711 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|10067099003|18002099003|22082099003|11063799006|4143699003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: hzBgj1iQ4Bl1Y7Z5TXkIpb0it2kmU6vD4MDKPZX5/L1APGgkO9Lbp8v7jM6hcAH8HFKqHs38PPK1bu2JIkMZuXLQZQ7ikYpZ3MurERO1C4aDA0d5GxVjxrLwm/w09Jb0caIh6SbAOKD8GxEpsoZ52I/zlsP6pR3TFQ6DqnU6EQvVr6lw7LPQIdjjEgj5D4tVLMBMUfJ3yq5KcegnoIx7MmuPxpWKk1XMGSwRQqT2JfU8e1ja9bVq1mnwDSnp2XAkSOb2cRWhHnxtX6B7SkmBLRJ//8PWdn3nIzuY9KzVKpYO5ieoABW39vpAozg6whSZEEDf/RdYyPxrV2X5bQy0Bl7WU3uIgLLrQnP/JNBXrfauzXoAS/79f5MDGudQwUJnkl/Rvddv6+ZSPCOZDItcvA8DsS8Jzj72hH6y4M23bsgjzty5Fv4BHjoYuz4Hmn3yztz7bIJzus5K6tZp8YiUAP0MOcb6LYvgqrQOB4qb1TrDTtjn8U3LzyNUNG+JeX4HSXOk59Leg2xsoOwgXw/pjIe0qYTKJib0bfjkQF/Oe7LOAhluaSB4I5/+eJtzfkOfCWQ3vVHCTgb1c5chRaPXyhNRWeZG8hWDx5duGJJPhnBo8aPj/QCzOO3nDPXyfu/yOSIh9yxaiqpXrSqX5MNP88t7u2X6/axsxBv9ABk84ng= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(6133799003)(10067099003)(18002099003)(22082099003)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AkQiHMpqxPkK2vR2EAZ7viNvdc/oYCDansvmYOz1OzRuIQPSY7q2kJ925JKl?= =?us-ascii?Q?TUKHCR8hKe0mIggYJacqEN0sPhR+3gtdlu7wwNAy4m+bd+3Wudq62IWEcZu4?= =?us-ascii?Q?q/ReaKzDGIM0CgfCIdA/6/kUkp2YjGFB33kEXZaDOoHWcSdTFHS/l/8cSfio?= =?us-ascii?Q?qx+KRoZVWp8BsI1bgWWQ8jnz5uS6601n1nXF81h7PPjPRUs5sekUEeBiEnN9?= =?us-ascii?Q?Mjled7R1S9DFPW13WkG329SLAJJiaCZ7Jkvf90maWYtQQlyNbm5T/eWOCv2n?= =?us-ascii?Q?oP5G5s29MIM+1DXSz3AgG6BTRecMjEUlfDFN6ixPrBKRD0cjFHImc/fsIDTi?= =?us-ascii?Q?h4eP0iO3rrCZFHciJSvFMvlOTg8cd2vueqOZDkwyStL7qTvj/35LF3cfRXrU?= =?us-ascii?Q?SSP1C0NDPdlwePwf7ZBgn0OUxaU/X/Ji0SQlPLo6ZqieBHZJtDZexuA4TY7z?= =?us-ascii?Q?7UMIMak5G3kIWzBftSO5T3XjuyxIsA20XZaFpr/e8LvRoZ0ZyvyzS7eo7H8r?= =?us-ascii?Q?JlDdS7nkXDZDN48CidGzzbTulFL0YrVSajWfera6l07HyBOXPgdfwqUEWcv/?= =?us-ascii?Q?/Eo9O2UWcAUQmc28yD6xg9XVxDjFYP2LRVPcKWvHhqwiJhcoYvzIc+wcbN8D?= =?us-ascii?Q?kEUOTDNiaJxYF2JN6vL4JbkxL+wrHyiFcDYYMbOZByZm8Bduer/vi05T/ae+?= =?us-ascii?Q?LyYcLJuLdXeZIVcCbbv1RnWfWINTCmA+V/NUzZ5oK6DABXAy2rF/ulhwW9Hp?= =?us-ascii?Q?QKAbsj/sJr8qdv8EBtHRJwm5qMgz9Nixt4kj35ZubnzP6RnOQYPpYhOEzGu/?= =?us-ascii?Q?j5oeL+xT7XOWLf9V9WNwKTe1yAdsZ73EUpi25j1dWJFoAPNnL4l7OuMPAMsU?= =?us-ascii?Q?q4VLwFiR3CKYKU3dfbcX4sdZGRFT9g//gJYfNMZS7GnMxLOdmDiwxR1NeWMr?= =?us-ascii?Q?lYkTJ0CHynvoifwqkYuWiFlhqqArgBp9wHWwHxIvfsPOXDfWJ0sThJ2CXukl?= =?us-ascii?Q?sT8BFzRsJfyU1DMPav+lEZQldJqxjU1Ner3nb/eIvybUfBZ6gfISabhQaUVD?= =?us-ascii?Q?3PElER0CRIESd7mKu0gGyz2bdCrkXg3Ga2ZaH9Lt56jJUDGBdHuVa8Oyrarh?= =?us-ascii?Q?EzW4Absfef0x+tWYuRdIkALcC9qy2WONxWmKTLT7U9xjU8psLwOXbKjxV2rR?= =?us-ascii?Q?d22KWQHdd+O6buThuWNvY3v4uX2OX6ukeVCyOgdth2V02i9vGv0BRRpHIyMy?= =?us-ascii?Q?MrOL+61EnLSkwE3RpaqyVN5coRl1xz9aDc2L1wpjFPrLHpIU4VKEFpsSa/SE?= =?us-ascii?Q?n7cN3o3GIb8nXJlbobzNihCiXeT7PzBryVnkaGl+HRRAaRd0F5ErsRsv0Mic?= =?us-ascii?Q?idOhmKtlBTVB9ZUs+ZGxfBGx7SBtTDlW5o+IUQY7eaMPM5IsERby497ocOJ1?= =?us-ascii?Q?t5OpHmL+eA0t9u4dKauZj8mOhM+tp4MbXZ6XUeHa2UWm7GJWiVPPg+IN60mi?= =?us-ascii?Q?Rlify3FeFQlgp+aO3eAnxJpYyibL9V+oHxVVw0JrKLjSkUlGjMjmOalaCi/e?= =?us-ascii?Q?4pQQjoGn+nWGcltcdMJ252QQgQbJ4f/l418ZDqxZMOuC5IMOGue0P2IsOhlZ?= =?us-ascii?Q?vDNIsvgeZtcWA2aPBF6OAJpuaVDVeUEvWjakhkwAJZHg5jQxWufEwUbLr/L/?= =?us-ascii?Q?s/4fcgVIKWxTkPfz2YB7sPHG00xyTVZxSEPp5jCkdbkfugKpJiYgkq/XyipI?= =?us-ascii?Q?CapiwHjV5w=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1331e807-fd5d-4d06-ad31-08df26b75711 X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:14:59.5726 (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: C9k1E8bCXsM2PLxR6vFMSU7JNE07T+GAyrYKa42UNuQ2iaOPNd8aq/qbT3s43EgPBsKha6kfgXN6hsM7RjVNXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7916 X-purgate-ID: tlsNG-c201ff/1791627303-6BEB92A1-05CFADAB/0/0 X-purgate-type: clean X-purgate-size: 2783 From: Ross Lagerwall Add support to libxl for using the stimer enlightenments in direct mode. Signed-off-by: Ross Lagerwall --- 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.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:15:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:15:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444981.1661489 (Exim 4.92) (envelope-from ) id 1xFU6i-0002lo-PM; Sat, 10 Oct 2026 10:15:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444981.1661489; Sat, 10 Oct 2026 10:15: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 1xFU6i-0002lb-Lt; Sat, 10 Oct 2026 10:15:12 +0000 Received: by outflank-mailman (input) for mailman id 1444981; Sat, 10 Oct 2026 10:15:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU6h-0002k5-6C for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:15:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU6g-0044U6-AR for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:15:10 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca0fff-2eae-0a2a0a5409dd-0a2a450b9390-38 for ; Sat, 10 Oct 2026 12:15:10 +0200 Received: from [40.93.198.34] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca102c-b7e8-0a2a450b0019-285dc622c7bb-3 for ; Sat, 10 Oct 2026 12:15:10 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by CO1PR03MB7916.namprd03.prod.outlook.com (2603:10b6:303:276::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.20; Sat, 10 Oct 2026 10:15:07 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:15: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=uuR5YDqQvSiHUBX4G8NXRQVi3kShcdebYzunSvSTiau9rjl6HfG1Ce4aiL0++MQc6JG71VKWXj7CNvpSySfINJ8u05KY6yVNSEO/nwukvOaYbrANsjaSU45LzY7NnIVoU5sCT2KdSOwt2iVWGBeNWQrrhoakz1gyfaHyylgDWLn0FNh9B/xtjDTzZ8o8Fh66A4RUA6kcCvxl5UO9fVlSG8VT5Q7JVsiP4hJJ3zGK9Hh/zKqOrFSoo0/Rdp4GC5kKOLfEKfRDsy25NuSrRa6I+4X57R5ZxdszatfaZTb5sVweOPlleo52qoG2bkahMEcM5b98gVsHUMoqzLwOCh4zBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bwU9gir2MKPzRvplN3rIcyzo64FzHBo/tZ4TRRP+JYc=; b=pV1flZ73JCOJcJMKlnYMzN3CAj9RI5uLmweSl+uyL2p8JG3WVrDMA0VIFOJ8QBar9cA7Fi+8hzOF+/sHISUnfhXKdh/CGua8lr5Qpizif0kLraiXvOjvvNBXSD7RkIFRZCd/+/pKf789+886HhRe/6+5ckqV59HLe804swRT4qh7/IGFXK0KJXD15FHMxLLaZmBi4Uf3k7RiNM6h0ZTK/WWWjnu2/zWXBcRExazIkU6TSaZ0U76rzpf9zYwiWJRHG7tEwxtwuYNEearihTdtDdWzGCz3BayZXz/T+hgCn9yB1jdZSPoIXqElCt07NOomaI2KKFEGbNpUDKnV3Eiqlg== 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=bwU9gir2MKPzRvplN3rIcyzo64FzHBo/tZ4TRRP+JYc=; b=kUQZblCdcGV8nn06vr9HlRwPnclYQ01e1Q8KsM9FUXMn0+Xqzc0Z/aRIze3tGFVfZbwYs8xw2CEc10XgJPkn1bLmPFTV0vNTQuPKOxCJDxU3ngWh+D543QPr/61Va1RnSSM5TVUdZVBg78CfRvvYlhXWiF29LWTSn3DJ2mwUVGo= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 06/13] x86/hvm: Clamp Viridian features to known set Date: Sat, 10 Oct 2026 18:13:19 +0800 Message-Id: <16057af6a0433e8cec576825b784e3316fc2c06a.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2P153CA0013.APCP153.PROD.OUTLOOK.COM (2603:1096:4:140::12) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|CO1PR03MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: 55e228a2-8611-4346-72b8-08df26b75bd4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|10067099003|18002099003|22082099003|11063799006|4143699003|56012099006|5023799004; X-Microsoft-Antispam-Message-Info: CMUsN0zBfheIKHa9W2X0BLtCCWukULZy36POcQvLzmAQnL6PpgFgnlI8P/Mxh0Jm93hztmTLofMWA39ppPvryP+w+YGXHTZrA10xSmjoEqOjyB2wyjwPIPYWXhcejv+ltD9M9MmqaIYM8uYvvOij3idael3aB4Wh8KqgBFCZ1wz7y4TH1XMWRwviJUsQeVHgj97xphK5NYVyfbl89Z5BWKLWtdRKrjaltNLw5iL95osM1f3/V7KGbPRkq2nbu+OtLzIry+F92gTMlnC1anFefC+z2mLbNwwv81yWjxVk8YkCcGqCYev5JyKfEF2223YSSgJrrjhpblLdY6G3vwvBT/yU/8plA/pj1cZMHXGFtZrmy3oO1R/fayGTHFdhEHIxILnv2zH00a3h+PERMlMdE+Z/zbJ+bHIM9kzjftXCbdG8unl2wj9Fjrk3EbyyDHh7kpj7UXlcKR/stEB6kPMZPgkefIhA5Z1tCcUzqqi+1ry3rKL6EQi7U4Bi8nG/avZxwzsGyJ3SVMCMe/vvwXe97E27AWrU3JNwOiFwpmlgbzRyKKT2egmdU1hv9WOZ8UQSXpTZcpntGKxxDBHdi1pL20dlLrk5+i+Zso35nL1gE9aeV4IJjgPXnlz2ZR6G655zyF2NU10LlaVIO9A77O473rOQY4zBrgSpSUyrpw00arA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(6133799003)(10067099003)(18002099003)(22082099003)(11063799006)(4143699003)(56012099006)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bXyRe20EhlksgmysfUZ/YsJ5f/hHsHmjM0dAiXlOM+ixMaGIhCVASrqlov1b?= =?us-ascii?Q?umUPQdz3GXWN+iXNrmVMI+eOrZJ821yc7Ce18PU90s/offXOSJs7oBeHAKjg?= =?us-ascii?Q?IDGyFdipMRyjh3zxSmyRXrYgcY1ZMLZaNJrBBlzsJliLmsrvJD9rXassNu0/?= =?us-ascii?Q?LHC4093+Y//W4J4XF2qvgRF3WfUW4hL+w227F5YN2+nmIModtZMzKiLd05jj?= =?us-ascii?Q?C0n0JwS7w21KkqOlAkTo4SGBbBaUROPQu8yAMydS14JsFhDtLPDGPufcixl+?= =?us-ascii?Q?z+4Th7mpCqsK1SCIq76pChFJLtZ4xObeSxadiyIVOxs3DUjAK2dRnDkNt51e?= =?us-ascii?Q?bo+sB6Q44VB49vS4toTkn7tp8baOEy/IQpKjcNNRy9Wq+3l9RVYvepV+8O6h?= =?us-ascii?Q?G5g4mQK7B43RJYKLQ5Vq1rlm0FNgLPm3B6IRMJwgG1l8hD0YDgmg4IVG52zP?= =?us-ascii?Q?P5gQf6UNWKsyz8zr4jEdkHwduJBe4ppF8iNLWMmWsI+tPpz9LkPARDhilzJI?= =?us-ascii?Q?MOuGqeEWsqQv5mJLvSW0g6kMqldvhYe/pbEWqQxvo32+cwL3U7srVRl4VROh?= =?us-ascii?Q?VsH6jrftqes3MzfnboZySKMBzFpoNUW9lby4JtzcPscUTBc/1VFGyGFkVgiz?= =?us-ascii?Q?VVpssUYRAW8MFnR9KliwA0Afr4AwA+61NYa/btL9SKXw06h41vejGYu50Jiq?= =?us-ascii?Q?4VB6iFJ49EGUhWFqABL13JlVwj0GP7a3k6B/rLIGMx3kshDdogKWFEgBvN1Y?= =?us-ascii?Q?KAaPh9U+3ZS1tRALYqF0MjySQmlh8d7j+2175v97BM0CpE8wxlr+2MPhTIFh?= =?us-ascii?Q?iSkZ6gh4B82SJnPPjpDl19nKyPkgPIT1uJXO99413TxqNCRYybsEGPf//zlB?= =?us-ascii?Q?gIczybUISnVgKveJFp9xMSq5gDEESbgZAk3hW7dRL1gVe9fwDZIReqpHzCxm?= =?us-ascii?Q?UXn33ABiUniad/86SPzpEY4pJQAcNpnWZzwfQyklJPcIT+i3rKbe7CDXRdD3?= =?us-ascii?Q?2WHgolrH5M7RyXGJGa41ECRFqz2fVUGx6kL0FBOKjgXd22QZAqI26zrZnrMh?= =?us-ascii?Q?5N/hzQC61wffC32An2Xj87kAv65atcAo9qFzd1Q0Cdi+Cd5KbcXbMAS6eg5N?= =?us-ascii?Q?vGOBG7CES2fjyTsIH3QBsdZNUu85Q2/s8SYXdQzu14yofNAZWgzhhzP5b7CN?= =?us-ascii?Q?PWi/fjJGKmBP0P8Akd19mKLQADzbsNByTi4snbhMwDWLXgpZk3KBzbcGaYwc?= =?us-ascii?Q?8IroW2FHfuKXx3n4Zii660j/qHVp5b2z7e09RAOgCU0gS7s1LmWp0n1WGycw?= =?us-ascii?Q?TZiydcSWQ21i1oQbEF4NCljzBmIgzMh6/AEivLdIV5NhtHJ3NpxQosDHhVkk?= =?us-ascii?Q?wPcQ5pEPqBit1/rd+ZQvv729gGu/CcsXNNZlF4akGFVvyZi5BIra4i1QT2mq?= =?us-ascii?Q?Fb1MwXItrJwws4rdRSktGzrYjZNlQv1aAC04wpzPMEB6cQT9/Xfbdjtu7WZe?= =?us-ascii?Q?heUCxw9ZlRaVI+/P4HJUTt2X6SR8QiQXAJXWi4II463REytuzOK1FuWjmERy?= =?us-ascii?Q?VknXpW3rmHXAigJgarswVd8Qcv7YOa3bgGVI6auTT4LpX2M2QCfcJQHdic65?= =?us-ascii?Q?b4MjTA/yw0SXmxJgMMbPHsWul3GW6yfN4koWS+KlhQ6K6vDmAGloEuqmVV+u?= =?us-ascii?Q?KncENnel8+6NHN1gABLM80ubrB3y57rH07N7FnYOx47kuyWhgdt52S4GVdFy?= =?us-ascii?Q?0hJ42T205w=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55e228a2-8611-4346-72b8-08df26b75bd4 X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:15:07.5225 (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: 2MdLtacU2xQT8wTqP/oC3AeZYK3V+fV4N9/STvl1QTsQp78sTPKf2tsFBTaePpdxnLmJHeg2TbpyS2oWmZtKcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7916 X-purgate-ID: tlsNG-42698a/1791627310-A92CC9EA-7AB683FE/0/0 X-purgate-type: clean X-purgate-size: 1167 From: Ross Lagerwall 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 ef9c7cd05777..e2c31d87afc9 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4235,8 +4235,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.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:15:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:15:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444986.1661498 (Exim 4.92) (envelope-from ) id 1xFU6y-0003K6-0E; Sat, 10 Oct 2026 10:15:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444986.1661498; Sat, 10 Oct 2026 10:15: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 1xFU6x-0003Jz-Th; Sat, 10 Oct 2026 10:15:27 +0000 Received: by outflank-mailman (input) for mailman id 1444986; Sat, 10 Oct 2026 10:15:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU6w-0003Iw-Is for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:15:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU6v-009G2i-W9 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:15:26 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca102f-8faa-0a2a0a5109dd-0a2a450786f6-10 for ; Sat, 10 Oct 2026 12:15:25 +0200 Received: from [40.107.200.22] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca103c-b4ea-0a2a45070019-286bc816586d-3 for ; Sat, 10 Oct 2026 12:15:25 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by DS7PR03MB5591.namprd03.prod.outlook.com (2603:10b6:5:2ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 10:15:21 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10: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" 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=PGmOXBkh370l+GU50wxY/860Da+jdD6qaunC63Qs+Ant9cmCWihJGnCJapPd5Px9qwLCkvx/fAV3HMWputQlnMupQdCVJhAh1J2O3yrjEMYswQDlZ4TFjGDB41SLt2EDcZdPAZEs/YcwZ0rGklHiFhFaJx70jpB2RJukC5M0BtuAuJNtQEC/O2yJGopR4yO46gJVw8+5+hrIgLG9isVsGJu6TNdWrNHma2jPFQWEy+Xu1SW04Ue9fp4VkRRLEOlmFKzlwwrhFQJVuNqj5MyOEwmOM1JIjM12OZTYLMDYKWa1NabquSmoIERB+qiBX7xH9lSB1jaKcuKsVVikITc8ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wwX/FVYmbOkdCgYbltdQ1OEvaIYZaWMFwkVw65AldX0=; b=Ub1vLtOGpz6+ogPsW3uDmZaWFUzOs1nkzwVL7cdUQtHYF6fBY718ENqqabvwlk0JeQSdIUsUTSPdEgZFqtx0RwWE1oHaR1m4TOu9KnwTNcbEomXU4fMLght1tcIZkv27ftD2W+bgRFTXHH2xB+r9hVDeyUq9KzAvHYqrNc92P1JsouRisZ0/9fop6dnF6jxmKsYYiuQvILy2fg/nXzxkFEjwX2FVe8C5wNa3NUTkPga78MAzhY1vBrQjjWqzREnFv0pxZUtyTAz4A6D1V3DJ/r6Dl9gF+4PX4IwwRziINgTirw2p1bDrWCV/CPFCTmQPs8xmKvq6Nbos7QvcjhOK6Q== 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=wwX/FVYmbOkdCgYbltdQ1OEvaIYZaWMFwkVw65AldX0=; b=r4fu248fRHxt3bBvMgp2SiLvWBOY6dP0+uaqi8c84oDI73OF+s1eEC0FDtDuJXwKR11THBGq8f2+alDSCiDrQGUhQCDs8Cmrb0+fqD0swa0z0lWflE0yDGh5WG+cx/1nIv37Qh7q1kxNuzBLy00ujPaA2iby+bsCdFvn9LD1Q1o= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 07/13] x86/svm: require VMSAVEvirt for nested virt Date: Sat, 10 Oct 2026 18:13:20 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU2P306CA0064.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:39::15) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|DS7PR03MB5591:EE_ X-MS-Office365-Filtering-Correlation-Id: ab6162bc-3a4a-458e-384c-08df26b76433 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4143699003|56012099006|5023799004|11063799006|22082099003|18002099003|6133799003|10067099003|3023799007|261009223027099003; X-Microsoft-Antispam-Message-Info: s8lePsEfAZ0wYj4aTHWCuG3EiMYPYkEYOzClvTyh6DX7AYsevpHFOsw8amARFVSKyPnYWf2qjQQUCNZ0FHUEubDt7VTQlGdem7bHPf5iYzh+1vBZs1YpIBvHlYGwXDaWBCklzCzinphK6w8NHI5eKOIAPnjS0e9vtE4L8I0IheaOjCeoifdzWogiOyzldIDjkRSuuZSpPKl+F0qovdnd1r0o6ITu4i7MFkxHOPgDuJd8es7Sx/JYKT5OnslpZFBQNiCpw2NBLlHXxYki8zSmz9Cb6wCVH4InPFL8HlBNp0xjgiusvyj/z20ObCgHBA0k+5fXs0s8NkNo8bPwlmNNlrTVAYuRGefNGbxuI22lvJSG8XvNXj7uwmkAlaAHLzUw3uN6DkjwmZ8y7B+aOuKQAzkFvCgnbiWPUwo0J2RpVG+g4W8cWKZG0FLhF4QafZZIM8zJvn1epLfpbsX8E5WUp/MHamk9HCmUnKqtxL0IlIg3jx71Q8XAM4BqRW1jFMnmMQhdhD9GYgy5qxbdVz/NF7NjDP3egVxQZ2JCqrJznrQyRk/GOmxgtG+68IsXHZDzHHK4lfzi67kzTJiFoiJux6tB/KohyMKv6B7lzuAgginDTXezhM2h8JzjIPRTUyJ++337nmVlJ04y3maV3s5YZwPtnoQTceLayWyukj+ai5g= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4143699003)(56012099006)(5023799004)(11063799006)(22082099003)(18002099003)(6133799003)(10067099003)(3023799007)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+vUbYyxuhfJ5KfuQ0pDwh4tKOKKRXSC9XAh2HxdfVgbziazBBPlv6H0vuMDe?= =?us-ascii?Q?Euco47V5j5HtKv94ZGguPLvSmMPd4NSTE24jJ+eig8XfPbvWpS7T7/cyO2cu?= =?us-ascii?Q?u9EgJQOUEAZcAcy7CtQby/joMm2FlWWgbZPXqcrg3zbvYCcpJ9/ld90DFy7R?= =?us-ascii?Q?I0qQGXCsfCXvPcB+FGIR2ngRp+Q0KFewjpIYIHuANw75HSyMMdcusoEMV8c5?= =?us-ascii?Q?r8dPet8bnKLiLmP/FOwYU4aVjR2yadqJQ4N3YkYwAzdnjqaxQH/kJkIwRLZJ?= =?us-ascii?Q?0pxBa717NpH6AxGtPO6mjUkQoCYoDHo8yA35eEroAiy5c1VkYE2anHAHX+K1?= =?us-ascii?Q?yN2bEIsRgXQB9WfgUZI20I/Mho3+O4ssXcPzgt9M0cdGCxJApZMhHX3CQBp3?= =?us-ascii?Q?YojDCU2Z1G5rzYqYPSO51i6G8AT+Ld/VoBNl2GfJkC3IR2UJPb7ZnXOLj9NF?= =?us-ascii?Q?lHGmuf4YWhY5GQ1eFJVsKusZn2BeK0syr4P8I6T/kI1weSPKBxWVEaxaNwMj?= =?us-ascii?Q?A2x6famnnCGZXBktTeRR/0ndHFWSzujZu7ApMtWNXMS0ZUj+j8cqrEnBkhcl?= =?us-ascii?Q?I1ptZCQAJRNJ/T+EoTzk8njD177ICFIIYO2OoI+TaA09OdHD9T/ZkDEZM9pK?= =?us-ascii?Q?Dg+uIrAfw7N5qfKjVbeipwiufdSBS4JIGuvIoteCcqfmZoQ0osprGkQrCvBX?= =?us-ascii?Q?dqzIYDKxleK/SQRJ47c93h8RyvSPrXT9gXzVb+ysiMUYUoPP85kHYq1isAWG?= =?us-ascii?Q?KB0fpeP1YXnFKbzd/fdq5T+HZAODPnQrvpZf9sAdDh+2UkV2GxgxxFY+0uel?= =?us-ascii?Q?k058kulujB56hzMJs3KlPUBc1MTcjAV1Hv2diggOtMMcRoyH3GNV/xaZDWcj?= =?us-ascii?Q?drLcl+nu4GC+0mqFGPfV1FjQ5Dgk/h9Njz/P24UVHZOo2X7gR3nKU0pZpNSc?= =?us-ascii?Q?aDtZE8M/UD8+GVAHt8T4jRAa8GaTKKb1pS5lpT4kIIvCVF5kdk7zsPPblZg0?= =?us-ascii?Q?M4JwHZuDVdA2A1ngKAy8n/U6zrarqeO54R1UH2w8HGj57gSo97MW4YXDMX+Z?= =?us-ascii?Q?I+zPZjL5WDksaGtR2zJ5K7y74eyvDZEnwpMjEJzM3pyQnGm4tvDj8Fr/ehz1?= =?us-ascii?Q?2AqCWNRYaysvisnDxrPS2y0abCkxROJ2UNSCBB+1BEpGhIsTHsOhXjQmLgQz?= =?us-ascii?Q?uMpslF9FlYkz5Mmj/oaKfksz3RASdzHZ5mB90g58bbNbDgtBQOdARCBgCG6I?= =?us-ascii?Q?Wrr+ckfw6r9+LafKiuMNmKL07gCrR+kmmtDh6hh6ZZoCOVRQpmPeosjHwmeU?= =?us-ascii?Q?HEAe2UEJxe1oOPRhCWDRfFLLFkNS9DKnPf/+DfcVny6kbtt/5nVaY5yjhL3y?= =?us-ascii?Q?rj+ZIFdBfkxMLXYJMyEDUbJhVF+niQu50Ec8fkaOOM4QlpbXp0DXu30kTFro?= =?us-ascii?Q?hqwQDI6xuI5d9VI4RJ9IDd2AunHKn4tqwNeS91Xr1U39Q/hbFaewoFjWxfLL?= =?us-ascii?Q?AEI4SKt6z+oEFvowOvVPmgYHQE3B8JptttPMiBgxf5uicMWVhoT+29+3mvyO?= =?us-ascii?Q?ZuBEwcwlvfOpj5M2EkyWX/yqQLRtX6dIoB7Imozq38xxmViS9nTfSNc7NcvE?= =?us-ascii?Q?Ze4MPjg4vALT6lsMkKruYrs0itRrCmAd5ZcSmumGVd3dp/5rNPPTKRTcdFYT?= =?us-ascii?Q?RiF03ECEvShksOwwzQjhpSL/BU9fRLaU3HmVS63Km1LivBqOTl9v6c3GCS+q?= =?us-ascii?Q?GoP3iAxu2A=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab6162bc-3a4a-458e-384c-08df26b76433 X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:15:21.5519 (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: UYw7e/awR6pF3MQWewfDcuGwRvUOWipQHV9mX/EjpDa+cubPt0I48a9pRR55IIxvazygQmuG3FZUst5kJr6GEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5591 X-purgate-ID: tlsNG-ef75cf/1791627325-36EDEAE4-9C06361B/0/0 X-purgate-type: clean X-purgate-size: 9887 From: Stephen Cheng 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, complicating security-sensitive state handling. Make VMSAVEvirt a hard requirement for nested SVM. Advertise it to L1, enable it when L1 enables SVM, and remove the nested VMLOAD/VMSAVE emulation path. Any remaining intercept therefore comes from a guest which has not enabled SVM and receives #UD. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Stephen Cheng --- docs/designs/nested-svm-cpu-features.md | 11 +++ xen/arch/x86/cpu-policy.c | 3 +- xen/arch/x86/hvm/svm/nestedsvm.c | 24 ++++-- xen/arch/x86/hvm/svm/svm.c | 100 +++--------------------- xen/arch/x86/hvm/svm/svm.h | 2 - 5 files changed, 41 insertions(+), 99 deletions(-) diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md index ce168e68e1b3..798480b259c8 100644 --- a/docs/designs/nested-svm-cpu-features.md +++ b/docs/designs/nested-svm-cpu-features.md @@ -109,3 +109,14 @@ 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, provide to L1 + + 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. diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index 48a3185eed8d..a350270f2229 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -845,7 +845,8 @@ static void __init calculate_hvm_max_policy(void) (1u << SVM_FEATURE_NRIPS) | (1u << SVM_FEATURE_FLUSHBYASID) | (1u << SVM_FEATURE_PAUSEFILTER) | - (1u << SVM_FEATURE_DECODEASSISTS)); + (1u << SVM_FEATURE_DECODEASSISTS) | + (1u << SVM_FEATURE_VLOADSAVE)); /* Enable features which are always emulated. */ p->extd.raw[0xa].d |= (1u << SVM_FEATURE_VMCBCLEAN); } diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index a76cec1fecf1..79242bdd9117 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 */ @@ -1113,7 +1116,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 */ @@ -1565,9 +1571,14 @@ void svm_nested_features_on_efer_update(struct vcpu *v) */ if ( nsvm_efer_svm_enabled(v) ) { + /* + * VMSAVEvirt is a hard requirement for nested virt (see + * start_nested_svm()), so it is guaranteed present here. + */ + ASSERT(cpu_has_svm_vloadsave); + if ( !vmcb->virt_ext.fields.vloadsave_enable && - !paging_mode_shadow(v->domain) && - cpu_has_svm_vloadsave ) + !paging_mode_shadow(v->domain) ) { vmcb->virt_ext.fields.vloadsave_enable = 1; general2_intercepts = vmcb_get_general2_intercepts(vmcb); @@ -1621,9 +1632,10 @@ void __init start_nested_svm(struct hvm_function_table *hvm_function_table) * docs/designs/nested-svm-cpu-features.md for rationale. */ hvm_function_table->caps.nested_virt = - hvm_function_table->caps.hap && + hvm_function_table->caps.hap && cpu_has_svm_lbrv && cpu_has_svm_nrips && cpu_has_svm_flushbyasid && - cpu_has_svm_decode; + cpu_has_svm_decode && + cpu_has_svm_vloadsave; } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 8f97f6c31716..ea32dcead218 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2136,95 +2136,17 @@ svm_vmexit_do_vmrun(struct cpu_user_regs *regs, return; } -static struct page_info * -nsvm_get_nvmcb_page(struct vcpu *v, uint64_t vmcbaddr) -{ - p2m_type_t p2mt; - struct page_info *page; - struct nestedvcpu *nv = &vcpu_nestedhvm(v); - - if ( !nestedsvm_vmcb_map(v, vmcbaddr) ) - return NULL; - - /* Need to translate L1-GPA to MPA */ - page = get_page_from_gfn(v->domain, nv->nv_vvmcxaddr >> PAGE_SHIFT, - &p2mt, P2M_ALLOC | P2M_UNSHARE); - if ( !page ) - return NULL; - - if ( !p2m_is_ram(p2mt) || p2m_is_readonly(p2mt) ) - { - put_page(page); - return NULL; - } - - return page; -} - -static void -svm_vmexit_do_vmload(struct vmcb_struct *vmcb, - struct cpu_user_regs *regs, - struct vcpu *v, uint64_t vmcbaddr) -{ - unsigned int inst_len; - struct page_info *page; - - if ( (inst_len = svm_get_insn_len(v, INSTR_VMLOAD)) == 0 ) - return; - - if ( !nsvm_efer_svm_enabled(v) ) - { - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); - return; - } - - page = nsvm_get_nvmcb_page(v, vmcbaddr); - if ( !page ) - { - gdprintk(XENLOG_ERR, - "VMLOAD: mapping failed, injecting #GP\n"); - hvm_inject_hw_exception(X86_EXC_GP, 0); - return; - } - - svm_vmload_pa(page_to_maddr(page)); - put_page(page); - - /* State in L1 VMCB is stale now */ - v->arch.hvm.svm.vmcb_sync_state = vmcb_needs_vmsave; - - __update_guest_eip(regs, inst_len); -} - static void -svm_vmexit_do_vmsave(struct vmcb_struct *vmcb, - struct cpu_user_regs *regs, - struct vcpu *v, uint64_t vmcbaddr) +svm_vmexit_do_vmload_vmsave(struct vcpu *v) { - unsigned int inst_len; - struct page_info *page; - - if ( (inst_len = svm_get_insn_len(v, INSTR_VMSAVE)) == 0 ) - return; - - if ( !nsvm_efer_svm_enabled(v) ) - { - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); - return; - } - - page = nsvm_get_nvmcb_page(v, vmcbaddr); - if ( !page ) - { - gdprintk(XENLOG_ERR, - "VMSAVE: mapping vmcb failed, injecting #GP\n"); - hvm_inject_hw_exception(X86_EXC_GP, 0); - return; - } - - svm_vmsave_pa(page_to_maddr(page)); - put_page(page); - __update_guest_eip(regs, inst_len); + /* + * VMSAVEvirt is required for nested virt, so once a guest enables SVM its + * VMLOAD/VMSAVE execute natively and are no longer intercepted. An + * intercepted VMLOAD/VMSAVE therefore means the guest has not enabled SVM: + * inject #UD. + */ + ASSERT(!nsvm_efer_svm_enabled(v)); + hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); } static int svm_is_erratum_383(struct cpu_user_regs *regs) @@ -2956,10 +2878,8 @@ void asmlinkage svm_vmexit_handler(void) svm_vmexit_do_vmrun(regs, v, regs->rax); break; case VMEXIT_VMLOAD: - svm_vmexit_do_vmload(vmcb, regs, v, regs->rax); - break; case VMEXIT_VMSAVE: - svm_vmexit_do_vmsave(vmcb, regs, v, regs->rax); + svm_vmexit_do_vmload_vmsave(v); break; case VMEXIT_STGI: svm_vmexit_do_stgi(regs, v); diff --git a/xen/arch/x86/hvm/svm/svm.h b/xen/arch/x86/hvm/svm/svm.h index cfa411ad5ae1..56a1a4840b37 100644 --- a/xen/arch/x86/hvm/svm/svm.h +++ b/xen/arch/x86/hvm/svm/svm.h @@ -52,8 +52,6 @@ static inline void svm_invlpga(unsigned long linear, uint32_t asid) #define INSTR_XSETBV INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0321) /* octal-ok */ #define INSTR_VMRUN INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0330) /* octal-ok */ #define INSTR_VMCALL INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0331) /* octal-ok */ -#define INSTR_VMLOAD INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0332) /* octal-ok */ -#define INSTR_VMSAVE INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0333) /* octal-ok */ #define INSTR_STGI INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0334) /* octal-ok */ #define INSTR_CLGI INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0335) /* octal-ok */ #define INSTR_INVLPGA INSTR_ENC(X86EMUL_OPC(0x0f, 0x01), 0337) /* octal-ok */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:15:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:15:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444993.1661507 (Exim 4.92) (envelope-from ) id 1xFU7K-00041U-By; Sat, 10 Oct 2026 10:15:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444993.1661507; Sat, 10 Oct 2026 10: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 1xFU7K-00041N-8y; Sat, 10 Oct 2026 10:15:50 +0000 Received: by outflank-mailman (input) for mailman id 1444993; Sat, 10 Oct 2026 10:15:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU7I-00040e-9c for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:15:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU7H-009G2i-Mm for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:15:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca1013-8faa-0a2a0a5109dd-0a2a4504a83e-34 for ; Sat, 10 Oct 2026 12:15:47 +0200 Received: from [52.101.52.9] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca1052-b57f-0a2a45040019-3465340945fd-3 for ; Sat, 10 Oct 2026 12:15:47 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by DS7PR03MB5591.namprd03.prod.outlook.com (2603:10b6:5:2ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 10:15:43 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:15: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=rikAVu81sc8AypQ/GgomOr8zPltWuy0Nx9J0dDCULqFTcagxleBO3BMVNa0qYOmd7TWdRhl+xhEQphkt81cSgFR0s/If5X3oCPzvWQ0uloerqG/IhetJU3diS7VVUcQAmHagZhnhptXJye5qBdqte4He0SalNosncQNH7Xmf2R18jK3oRieHnNLIt+tcL6ryX0w5wDSLqX4lHZ1J6tXLqkIDgrUoYetKyOl/YAcbeWfFm/RPfxpjWGl/yDo4lKH/tFvNnzuNr4u17vssrRKJ2F5AVUIo1ffitr21qZm1NmqzsihpV0WgcZOryreJH179El0B/Kln4FXVl81Cn54GXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oexZirZAMZNzftk6MpNV1/OYjX520+aEwGhwJ24lOgU=; b=mh1xm3/VzX2QCemhXNqWCv8ZBX8ar11CxpTbp/Xn88tbvV02sMMMpH85Je3gmr5qr1RzsRCkCIlKeuHn+BjiadCYWHPnFm6juzaiqgVGjVagJ/5STcZBO9UKHCpG3mIkrXgvfAFYsx205FXIxcsNQZJCDTcNCdpGDzwBwgHLsGyxQFVx/p5Vo0JQNu9QaWqDnQE/ibxRdm4t8Hi339EDTOaa4LnKfSxwT0UmiFJzB+C2r+PBX8V5dZL+2YKjJLD4hxFNR9WAa5KrbkEFbbdmvPk2H37enxClvJ1DNOOon7TfVkKdylRsgLU2k9uWLXu7HNQpnniJC+fWL8nEH3CDng== 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=oexZirZAMZNzftk6MpNV1/OYjX520+aEwGhwJ24lOgU=; b=IEFjuhK8V1PYK1KAhzd7vWUEkE8VHkXTU+dY+Km2HPmgzTVOcni+xNXvt+nbnH6C6zuyXkL9l06yRbzUACVGopFlJ3/IaGFvEKVl77rOAJqPEU8VG4rkAOy21uKtjIGGoqvQO+ILHPBpJYeCUniskNIas3Ieyl7jUH9JtgQBU38= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 08/13] nestedsvm: Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 Date: Sat, 10 Oct 2026 18:13:21 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU0P306CA0085.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:2b::15) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|DS7PR03MB5591:EE_ X-MS-Office365-Filtering-Correlation-Id: 6932c811-ebce-4747-253d-08df26b77113 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4143699003|56012099006|11063799006|22082099003|18002099003|10067099003|261009223027099003; X-Microsoft-Antispam-Message-Info: 3o7iwPtreOMTMhRxr6TwTY0yWrI7CWb6iKT9kzICBSM98J4HMfFScG9F1AONgx5Ovw3bsFkJkp6wRAQmqsmXCGE1lr1kCayu285IgwP11B5y9tPW1g5jL7N5nCyc6bqu2p5nJwJXdyDibFlKvttsXAvSxocK/nRQzhWwObXm/HJKdujZdtTThhrTyQladIH8vpWnvBKBUA+D/6gUiPiQyXtJhqSPr0H56EKp33VWoeASdE6VhVdFjWvekZ2YGY1uD9h2Js+7eg2EtQUC+6MCtLUJYoWBIyV2eZKwMPMfN4+iKitn7mkUcfqDXUj2TSwu+ejxjtW/0KakcW6S8nYUVlpEH2PJmvTD2axC/WLDQeavwhSOOcNJVCwfgJDZAATjf9m4ZfMXyG3Vk4/kF1uI3vhMCiihNEpcXNyQy0tZ+aTN40lk5Un9ZJIuOmBFdTZLQvJmDON+2azypODNXiWG49/HfRLCyhn9lyCSHuayr8HWhopvZYGAVLUFtfqEgTnPIX5BdvRFMsJ8j49bNCvTAKzSqO8rLXFqHsD/R51N3z+H9J1AffjdsjaCOdkCHcL/GNWT7cQWUOQT8u78gYWPZNW+bYk1gAPnic34Bbmj85l5j/JCKnyJIpa+soRKifSmZnD+PZzW9fXoI9vZajfDb80ACpytCaqG7vMqGYlXydU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(10067099003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KYbSiZqNADIVPP/I3nzRN/pASW9khZ7pWcO+e+GneTo3/OzR9oKoIHOjp8F1?= =?us-ascii?Q?IO1Oh2zLMjOImYIa/305MiEVEInfK3vi1QJXEa2d+/Eo38OPcbjWbibzTcsi?= =?us-ascii?Q?tFn6eDKXSm0GifH71Z64hbVAgPwMy4XbQvdmC7jO8j4cwV42iDs04WkJuDiB?= =?us-ascii?Q?3V38HmA93TyMwrPv/ywVlGJYLHpLxTPvVNklFVKJBnWi9RKaODe5dEUmj4xo?= =?us-ascii?Q?ZiJ+c6KDcmfJdc6JR814ZNmBpE4KcmXX+LNan5+SnruZb6pD0F3jnW5pdszm?= =?us-ascii?Q?LtjdHtEcAvP0LJjpyjRjP4uArmBY64xwDOp+LVuQQziFKHIDUbbMtXSjlRCN?= =?us-ascii?Q?asjXY6I9x+IgM1r72ioAqGu3k3krFZG/9iwqyXcWxTFH514fXmINlpEQbVU2?= =?us-ascii?Q?RvyXXy07UkltAAhBa7mYKN3qQKy8Oy1787lx1G5OoGIhO3Kg+0Lfwk5kROHl?= =?us-ascii?Q?XQvgEhtcQoGut3arHDMkvdBlj994stCJAzIxl7FoEEWj9Cv7d44xTb7325+g?= =?us-ascii?Q?LwIDb6JBfjnhbaxuQeOHMRFGbgh/9CZJoh+i4TtB8Wv62rfdoHGF65JaxtaL?= =?us-ascii?Q?Tu/XXiLLkKs7Bf2kxQbv0hFFE6e4D7dgGrsGiKkC8SLXWuLcx/FkrylaiJc6?= =?us-ascii?Q?cZPUtTXZB7y+rR9gFK5iiP7lr1Gcl9kqEcaiGjRNoyvnLo2AglKxYVkhUzWr?= =?us-ascii?Q?q0KVgU8KQg5BgNbk9pkkPzMbsLBO8Vv9xfkF5VBX/yqCP0ixWIgiqBWQWg2N?= =?us-ascii?Q?LMVijTTA3D1ABF5kUiyOX9RwvpAyn5IHUNaR3VQb2mpeLbCeNFiOG9ZVUaEt?= =?us-ascii?Q?X1udlwB6l74KwpXP87X5CoblfZgrPLymD7cqMukXVHu0xrlEspBpKPIpnI74?= =?us-ascii?Q?QxSlf1PSl1UCYxhHGEUF3WTMyhv+W1qT2dLE01Nd/v/YpKiaDkBORbJTFHQE?= =?us-ascii?Q?HJsq22u0wYuChwd2eTxlY8E3JbJGH/kaC/gzj/3hVuFn9me6P1F+NpnkcDAm?= =?us-ascii?Q?xMp7TX6V6DBdfkaft9MOTmUqQ6fMiKP8ZlnL6U/Ch1AndtAZo/CylzbGGyNr?= =?us-ascii?Q?b/0/iwKDg/cFpjY5C/WW091iOMcQser/hglvlqkxv9DZzCFRho7IS8rL8+77?= =?us-ascii?Q?f02c2u7wasdyyrBmfJULsNYp2RqxHJ4dfndHPskRdK+GsJggHYn6KcCceQtA?= =?us-ascii?Q?FRdhh40T6phRsI/6GIP1BJd42qSiOGCyxIzND8EE6Gct7j89DhBD/AeyV/0I?= =?us-ascii?Q?DYKkyiWjxNO9Nkw6UmHvZveDFWPySFNZtnUI1zll6XZffG4GaGOWTBFunlaY?= =?us-ascii?Q?/puRPjSrdOhtfwT/xXjWD01gC6IbSl8nMTfZFj1wy9MnS3BMDmAZQ9dNMLCy?= =?us-ascii?Q?6FuUYhCun7J2CNeRtBNhWwu0VqF3Klht8b8e0R10a3WC9/3NbArzGWmHRHUX?= =?us-ascii?Q?/R5w8jBHbs3P5tukoNcinPpgNW7Leyq4eVTrKfg6svGasxtRLkqDvAsa+AIV?= =?us-ascii?Q?aM1sn7uZl7OTLISOTQlEFN3JsRXvkqKbawkXjcARkXvNaX78bH+Nm/vQU2sY?= =?us-ascii?Q?H390vV6YMdGlMW1SvoTuu4dq2fPC7GZ7DciDyd8mabBsyxLOgV4mssR3khBX?= =?us-ascii?Q?B2gM/hGIBEYYq6Uy3kyH818PTpcQHMnHHV6U0ClzwAcSK4VQ9MJ1O+8a7V3j?= =?us-ascii?Q?3ram4LrwKtU7sqH/8evHITPF+7QcCPF4U4A0jzcTUlBpoiTsErNyujE55/MS?= =?us-ascii?Q?g8e5PBRtJA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6932c811-ebce-4747-253d-08df26b77113 X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:15:43.3494 (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: oFg0rfWmK/1YpC+1rZBwWR9xDLdooD2oc4gc4c2RsGfLNqZdG6fsv25IPAl7yNtKq3alUIa84nyZOtMzmf5Ndw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5591 X-purgate-ID: tlsNG-ebf023/1791627347-528C9B50-4F32F112/0/0 X-purgate-type: clean X-purgate-size: 2688 From: Ross Lagerwall 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 | 36 +++----------------------------- 1 file changed, 3 insertions(+), 33 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 79242bdd9117..d47e57c8a1d7 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1031,37 +1031,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_shadow(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 */ @@ -1090,8 +1059,9 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) ns_vmcb->_efer = v->arch.hvm.guest_efer; /* CRn */ - ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4]; - ns_vmcb->_cr0 = v->arch.hvm.guest_cr[0]; + ns_vmcb->_cr4 = n2vmcb->_cr4; + ns_vmcb->_cr3 = n2vmcb->_cr3; + ns_vmcb->_cr0 = n2vmcb->_cr0; /* DRn */ ns_vmcb->_dr7 = n2vmcb->_dr7; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:15:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:15:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444994.1661517 (Exim 4.92) (envelope-from ) id 1xFU7S-0004Pp-K1; Sat, 10 Oct 2026 10:15:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444994.1661517; Sat, 10 Oct 2026 10:15: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 1xFU7S-0004Pg-Fx; Sat, 10 Oct 2026 10:15:58 +0000 Received: by outflank-mailman (input) for mailman id 1444994; Sat, 10 Oct 2026 10:15:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU7Q-0004Mo-Fp for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:15:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU7P-009G2i-Sh for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:15:55 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca102f-8faa-0a2a0a5109dd-0a2a450786f6-40 for ; Sat, 10 Oct 2026 12:15:55 +0200 Received: from [52.101.43.57] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca1059-b4ea-0a2a45070019-34652b3922af-4 for ; Sat, 10 Oct 2026 12:15:55 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by DS7PR03MB5591.namprd03.prod.outlook.com (2603:10b6:5:2ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 10:15:52 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:15: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=szgvBfbpZw/TksHMzhCDAn+s/+elyWAjN1U47k8iOJNfRGxT6HB3IqMa4hD96iAczlZ8/wJbj+q1kmE6TAAn60eu+MK9/8bQbzj2dP3SlFmjYf4faZ/eM4rLD4Pu03RaPkuX8QQgMDsnNpRrsx3Q9qWHxmLvMUMYIhbzJdxw/DINDpEkqs8iwsdIPH5wbAxbCHVC3qKujSbm0zbfLWROWqDEx4idVJf7MzTqvZPONAXvM5tXx4ALRWl1wsYIiXdRrPjruAaEaTNkTPVyP/cSjkCfqmqtMkp0I2C2lWVHl87nThTsys44GjtAF219lLpsYdU0mqqVjMiFLX2AOgobtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TubJ5WWWxAoWmbngom3t1u6MgQONdCbxh67FzIrAJEs=; b=Y8QldvFAqfsaTCj5U+5F9ISR/7G1xUNFrdUf2TlKMlyCeYu6E/KaaNIFkeofe3tK3P9hJI8HRCXUxUWMR+vjFOCEhHAlphCgJ2mdE0WVGFHRYZFUVvcCBB8Nf0lSUoD6YraK0CTICF+lRxkkny/lixhiuVfdKgzz8x2cf4aulSmPACrvAxWQOzqDnVw3foHrsGqbiQTVBWhYhRQZg4ji0BpVNNPqRXO7SuNe+NcaTe337qiXbqjkCKQzCMK7QE5QIgexl3rw0xr3Wn4SAatlZqtGO0F5UBYDg0o5KRHitP26ftvlXY55gCvSJI8y0/WGSEn0eWs4Cf6dyrfGGCsVZg== 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=TubJ5WWWxAoWmbngom3t1u6MgQONdCbxh67FzIrAJEs=; b=bXAgnb9JsDoKr1JhMXAojv42zIhj0bv3VVkdBKx9NTQXJ9iZPIWEPQCfZCO2r5i/SI/u2SQBNPh4SZJrsAgExKK9bI9m0vt1Vbt2nDmCOouP2LUGMBvczUbTXrxlOIXNXfY55d0waJDqKag6LvYzcHcLwhiCpEQ23dMGNqcyotg= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 09/13] x86/svm: Fix VMLOAD/VMSAVE state handling when using nested virt Date: Sat, 10 Oct 2026 18:13:22 +0800 Message-Id: <106eb64227ca2b0784c74791913ae049bb99a7d2.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR01CA0021.apcprd01.prod.exchangelabs.com (2603:1096:4:192::19) To MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|DS7PR03MB5591:EE_ X-MS-Office365-Filtering-Correlation-Id: eecc38b1-902b-4ecd-dae2-08df26b77628 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4143699003|56012099006|11063799006|22082099003|18002099003|6133799003|10067099003|261009223027099003; X-Microsoft-Antispam-Message-Info: QuF5+bWgUoWFHaW4piL1Ow5Zmr40R/WBrzauMwuo7/hYaAybo/KQxXumzNMANuf3SOJxPjykJtuqwu8Qv+Q2L8YMseTe9lqQNvtNlwKBEzECJ2LUqD3pEFa8wbMlpTphUnz4NNvN7EcifG2VVysq7pOqraJwomYkrI3yRiZDvdbJOGCanD/sx78cIcPMQDEGYTzW10etDuXzafDNM5UdADnUmdcu8EZEWuK+OIwbFUQZ1GcOgHDCmbzC+BNHi2cqIRsop0lYaCAwr1hLqCCVCUYoPAb26lFdhCWB5tjlgI/psax4d8l5qGRUAseoO9uDqcPKEzeRq/qsHzCaiABibujnHw2Di1fV3/tWDN8ESJC9JeyhSfhM6cKlEUN4qWEZFmdV9ZwhX1IBS33GdshN/eS0VfIIuEDJUDPAZsoEVJN4NlHll7LtuhO4AIkW+njesvHiIho5FzjwFksLXhS58Pm5QZIzjp3k5NBMB40zHRgN3ghqW8FFyk5M4/gX3PWJfEsYOkWB9U6DVsvM5sV4QG1aLkDa5oZy6/aGWfdgmC01FtE3MJq+w4y9Om8YhZ8IYBeXjiYM3ZcIgN3pqqZDZNVhCnxKLH4jzjDiCf4R+WOr57oyjFG4FCFcMhYjYY4PQBsQLbjrBq3ez6z1kQ1EFqgDFIf+8JzXwLcD+Czvs8E= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(6133799003)(10067099003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ANeOUzlpCh21YYFuMED/cNHTw/2O/7e8WZITgcElcbQqbIKZ6M+L1y0A6r0A?= =?us-ascii?Q?/PhX6j//S6g79dSZx3/tpQ//cqTrTHhY0k/2sgGuYJzfWw6TrB27VIFg3tzz?= =?us-ascii?Q?xb4WX+zDxg3VFvZTizN4yPgLfwg7fJajIwSQn7OfctVMAl4FpUsbMN0Uzr2o?= =?us-ascii?Q?eUbp6CTVphO2t+j/q5tOjBAsnozxD+aDb/aoAbPW3kluT1ffMMM04bXEejDE?= =?us-ascii?Q?uETSZKGIdTwPlnVckNDjQWM/GeSAv3+Js5+Uj7BXVJlHu403+JgZ8wg1c39H?= =?us-ascii?Q?JM9ya3hLo/Wapwc+Zxje8kG2HeeMigpao9IvbjKBMUpYinhhIYp2FPbVPmjG?= =?us-ascii?Q?M+FOTghk2knGP3AN+yhsjcRZHBCk+ZgDV3CF9AUkw7lQNDkAwelUbQr50+nd?= =?us-ascii?Q?JU7sZVhTPO+94B7diCM6wTfgImfcem3DHKHDqe2zI28U/+r5CH5+BlrO6vkI?= =?us-ascii?Q?zJIE7bLSe3k7CFEHxewxI7V2xbRn/1meQplNUZrrUciO5E2dVkWrJaEvDnSA?= =?us-ascii?Q?eNDR0N0KDinwpJGaOuIyyf1RzDzj7oOTYnp6cxo1J9bDDs6WIlFIsdlTRZjs?= =?us-ascii?Q?AMc8a+svnC/E5NbEiRUslS/ezRVSmtLVVYIQ0AUhUVaUF6SV2RlVG+utoqrc?= =?us-ascii?Q?idwhmNaCGP8ovXBo8cr/o5QD1ic4t2pPuMFC3amKDerlkHnPTe4pz12tgys/?= =?us-ascii?Q?YasbULaBHIuwoYUm0WHw57zF1VmAwHy4E+Jn70flel9I3WKh2FlQFU9Juwg4?= =?us-ascii?Q?xzggDeBs8mG3C8mtgQrFem8JON9BdPUS4mhDyYtPepVAJ4VZltjpZz5QXipQ?= =?us-ascii?Q?mV+TGIYw0Tq70robkjvSGh4xkI9ZLO2NJhKsla37ZAlkmmfGz75r+QTdkkBU?= =?us-ascii?Q?t1wPrNGvEXSiMIdUPzWKpSnkFnF/ophcDE9MURQuG+VgcVj5QLRLxi4j+Wja?= =?us-ascii?Q?YcbynJiZIKxH9uun8yAXVj18RjplvuNKnH+CN9SSnEtLVDuZYtZFT4eNRKSc?= =?us-ascii?Q?2D4/Sef+B1lp2L6hnTIerHgvMMyHFejT0w8+/fSgwDkuuohSSqYbeqYDBY7f?= =?us-ascii?Q?wnmXPy+eHlalosO3Qc3ceAyyuSZ/jTTwrhl9Jvh3pcD3CWtssIUUXEHJK1dv?= =?us-ascii?Q?WJyEKC6YqsEgSsRSxLQPB4aJKxV+MVySOqB4WITof63Je77OenwQwN+RSKPq?= =?us-ascii?Q?C3pYlBqt62Nu8qMT6GNa6HJps8dggqZAyjUTrj7T3An3cHc2n4JLOnMFkWgZ?= =?us-ascii?Q?aOao4iT8RMgrmPftOD1yL6iwPp+B+SlZPFZBzjao23bC4EYq9Tijxa6ZpgCQ?= =?us-ascii?Q?ndvpXEgGwiYAwlXZInTq2vRJCFMNv7rPK9B4W+H7sJIuaWqTTKDM3wCe3Siz?= =?us-ascii?Q?VzseBUta5JkJ8jBpdWyQeQapLUKY0DdlLFZeKsjmH5gYvvW/oMe78rOZwmaZ?= =?us-ascii?Q?BgV/QI1KuL3nyUJWImYCO9MpBZT5JOYtVAFEnprwA8vsvPvSaoP8SxYrse11?= =?us-ascii?Q?el/SBKDZ78DJA4LwTVcNTmgYulos2Y/o/TpUTLCJBAI5nezwGG7FALh2WxJP?= =?us-ascii?Q?Zb8UMxPOt9p2PF6U/2pzFuPlvF+FVD0UoSO0z8aUMbWvBLf+XiT41/gN8H1e?= =?us-ascii?Q?HlYhkhCWofR5LXo2UrESXPGbc4Xw4+iYaJGec8Q42aSd6j4j+uuY7JB7+yjt?= =?us-ascii?Q?wWvMqwCj7ZNwAzcCr8xP0G8LG74GptQ7j/vB0gjU4khP+yHLTEZVCqgHJbl9?= =?us-ascii?Q?SEByVGxOsA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: eecc38b1-902b-4ecd-dae2-08df26b77628 X-MS-Exchange-CrossTenant-AuthSource: MN2PR03MB5328.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:15:51.4953 (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: H/i6zPst8DHpni8ArSb7iPhE+6gXL1FBynRRQEvXiJEQ6rb57Z/pe5kOcol96PH4SkQB6jZfXqnXA2cHMf1hIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5591 X-purgate-ID: tlsNG-ef75cf/1791627355-374D3AE4-EDFF499F/0/0 X-purgate-type: clean X-purgate-size: 16754 From: Ross Lagerwall 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 d47e57c8a1d7..e1cb10e1de11 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; @@ -977,8 +972,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 ea32dcead218..5aeffd5e416f 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -443,30 +443,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); } @@ -578,18 +578,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; @@ -605,6 +606,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)); @@ -612,8 +614,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]; @@ -623,7 +626,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: @@ -636,7 +639,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: @@ -651,6 +654,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)); @@ -689,12 +693,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: @@ -708,7 +716,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: @@ -1667,6 +1675,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; @@ -1689,43 +1698,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 */ @@ -1858,6 +1867,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 ) @@ -1891,45 +1901,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: @@ -2257,6 +2267,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; @@ -2268,7 +2279,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", @@ -2544,7 +2555,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 39b9e6bf2068..fc3ba7c44815 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -250,16 +250,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", @@ -293,7 +294,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", @@ -305,9 +307,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", @@ -319,12 +321,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( @@ -423,7 +425,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 28dae325ced0..650465b090cf 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.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:16:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:16:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1444997.1661525 (Exim 4.92) (envelope-from ) id 1xFU7c-0004nj-VJ; Sat, 10 Oct 2026 10:16:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1444997.1661525; Sat, 10 Oct 2026 10: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 1xFU7c-0004na-Rq; Sat, 10 Oct 2026 10:16:08 +0000 Received: by outflank-mailman (input) for mailman id 1444997; Sat, 10 Oct 2026 10:16:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU7c-0004mx-5h for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:16:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU7b-009G7U-Iw for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:16:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca105b-8faa-0a2a0a5109dd-0a2a450a9d7e-16 for ; Sat, 10 Oct 2026 12:16:07 +0200 Received: from [40.107.209.56] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca1065-f2d2-0a2a450a0019-286bd1382122-4 for ; Sat, 10 Oct 2026 12:16:07 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by DS7PR03MB5591.namprd03.prod.outlook.com (2603:10b6:5:2ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 10:16:04 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:16: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=lXCFZ4wDXhLROFtv0ggOJl69FWcHz7LZgBb3Ke6pe2MxY9MYrRtzWJzxwNYkXw2xi6E0QU98/Ln2/8hkow+qnCLpH+919sF8V6y58CAaDvCYZ7BGsCR/AnXVVSDH6eQ9w5XcC2Fo4ndW6X2+8KNFrGfxLro43ztsyuICom0PRKfTrXEOaLtT4yybA6UToVis1kODJYMztMCWkxV0U4+OGJIFmxi4R6k5/EfdIywTkgMiJ3KZGF3XGQ3LqSPc6TDixarcAjaeoSBgXw51sdIvLILb/x0QDaEjlKLx+QnrWcgAxXvPI5tA51hE0BGjUV+as07qdeSD2BHwGDJm2wFeqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VQkfC444jHQee7yDdB7yiyHt3FUp358FjQN7aeCVTlY=; b=E670TWZhNOchtbzqfJbyOdodch5FOB1tZjEAQXn5IZAelC+jZPg75V3bvdXvWdeB8GbpJLYFOEMxrHCL2kTcZuR//cFpF8CHQ+YMSFOEs0geJGXu86xTg7r2NU87ySAMDjELh/xxc8lyE3oHfyy3D2iZkH1zLnG4QT0hPH5u7eZE50AedXKfDtCUnQ9qtoUe+DHPTdIOfMZFZ1JA77pTGp/pdHohCsYC4larBZn//FCkdwrHI7jnJTsim6E/PrwkIKJ4DzSwADXO34JIK44lktfTBg2JHKS6fX2L5qhXvboHM6jBvYZN9F45W8qj7BbDBZXQYiV45W2BpzRc9ugsKg== 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=VQkfC444jHQee7yDdB7yiyHt3FUp358FjQN7aeCVTlY=; b=Qh6UZe7UIB23Wc/1l8wKWA+XcA1/AIyh7vfMuJzN97AZ/2L1PqNdSAtcC5uqCO38Og7qqGGb7SmrnWEshdpEkMhwGog2/WJjPxEoSwwCmhd6UbNnIPHiOICPfI6q4JUKfeLtqSFiFu+uQ1kNr/5zA1D9QslZJpS76EOHW0y23e8= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com Subject: [PATCH v2 10/13] x86/nSVM: Don't clear TLB_CONTROL on #VMEXIT Date: Sat, 10 Oct 2026 18:13:23 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR02CA0007.apcprd02.prod.outlook.com (2603:1096:4:194::23) To MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|DS7PR03MB5591:EE_ X-MS-Office365-Filtering-Correlation-Id: 0671a6a9-ff91-4088-621b-08df26b77ddd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4143699003|56012099006|11063799006|22082099003|18002099003|10067099003|3023799007|261009223027099003; X-Microsoft-Antispam-Message-Info: UykM0D6Ey5YoeL1qqmUR0xznefrefMD/ZW8NknELRbr3g9D7HhtKJuY6YEVDIWdzjWpM1L4a/AEkStfPhrl1Vaoy7AYSBBk9Y36TQKb9GynajQXARMp7XBWoePu+3TTPGcK2CvrMQgF/xL69cECKNGoSWuqxuzBzwSomtfP/JV80vCMCivG97r6E1gcTCw37XGj3j8iPZPkIkLoezPwvvgPIZOyAyKcQkl7MS7KfixMAcJPx4Rn0vc/RG7sxf+ERqyy6GCvnlWM20dbh7CIPUuYIzqGEcU8S7BZeZtJBnHFG5VZMR1RERFyOg/MAgyIRmF7eC7Qn5OOpne/f4gXl+nsFh7wJ/NjRYJZPsvgneIGRXrA3/4xgi/GmlBQ5+Xa/sc7n9jsMMhUNndwxe1RsiHRxApO7AoTbvbc5six7xqrfI/kDFaF625dktrr57jAfcCm7exRqMMqlpPBqlFyq7HioglGUUhsYETmbvoPbe605v77OAvWfbhqBciW6T5ZtvTv2HwcswJWXKAFBf0tdjAAdA/uMmBh/AwFx7/49bpLdKeoAl/BoZD+9/kRMEdglW0Qvis3+BZwZ7wJxjoRrkQ7BizSh5pFB2Ui1oyD1aGrGmbHBlUoo33XjZubtr7jqpQ059y3bAbDNoH7f7NRJr5yWZDDJDMfn34Ga8+mlzaw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(10067099003)(3023799007)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?S9ZUWTIVJSGdWu1aaCXYqSJUvb764ksDMBQsbT9wd3SFKamo8m846Z1jnCO+?= =?us-ascii?Q?2tQIWBkECPnbi7d1UqVOLBaw1Vwh2Ihel3RPqFELCSgbU6oSs+ZmYnYXrTQB?= =?us-ascii?Q?B68AM/vYi+g1USE1MXYAVobJfFy4Mx0cnZCdS1YOomsV31pWCYniaKkzDEus?= =?us-ascii?Q?lMA5Vt+TFedJqDdLnqZoslWIUepYb9OUXhLPKmsOg75unUlmp8Gnv3JHbWCc?= =?us-ascii?Q?H4Da9CLZkRCvPjVRaD5DPVaFzfBgPf2isfRIhBVeJcpQhsDrTIzrUG2tqtnB?= =?us-ascii?Q?mOwWTOr/ydhdMtg+LpXD6j0WC0bTbQkyVGArXXUMrmx2qM2mFkaQooWQzqDd?= =?us-ascii?Q?yPIA21QgWH7Ru1NoXvpJOkYOormk4wiuEc3WJv2jT7C9KSdhru+Sx962J3lA?= =?us-ascii?Q?IE4BThHUmXSh+LvtBV7MX6144jF8Yuxbdf7UTd2ZvrACt0jBnZZx6FijYF6F?= =?us-ascii?Q?g97K/fp1FIEJruqNUQclOj0hstvHCm26bQLfxxYf59ccAE7kGLdWwQoAeozw?= =?us-ascii?Q?csLO2O+2nJZs41VxpQKyPaw/gtTBCnZbMzKKywcOI0C9C5fmgQQjiP/wA/xC?= =?us-ascii?Q?8X0uPBnggpHAyCUJ3BSpwyhJqQdSeB8gNagYvf9kWmuRnZxSyYMR8W3nMd2L?= =?us-ascii?Q?WwS63l1ttBRWv6b5CJbNo156cCGPgUKhw9IyUAIrGvTmv9ZzTbcQQK+X5A27?= =?us-ascii?Q?lKsZiYNybjz8+RMzvn7B6Yfk6lVnBIhMo4eSAXQgML1L7oB8rEueheXtnfpb?= =?us-ascii?Q?Zn7G12z5viMUoMndsHLiSQVRunQmPET3ndtp1dJ1t82fvytH0vewHe68vOEN?= =?us-ascii?Q?DAxRGagCFb7rdUQm3DVhY1VIHFYtlUDkQdnHMW9eZFcIuR9IhMld4nn2jIzH?= =?us-ascii?Q?iy78bvWiGDGC0Ss0w2FBszKzdWo79KAgywZDSPxgTtBTS77bDIeZ+eJMT4hw?= =?us-ascii?Q?E1VGSdM57kEsU+58ZgzajSet7gdyo8+We2PPKqWJjEJ/XUUrZw+h5OEfI06D?= =?us-ascii?Q?VDBI2G9wcbl2nO8Z75l+HTGmmVxAKlufHP7hSJ5d/ZbuZhFH1QOkAca7lXdM?= =?us-ascii?Q?r8JVOJmOBk5e6hERqYkSNogYHOkBdCGvpHJPVZQsUZqjumMEKAv6ZXZ6IDyW?= =?us-ascii?Q?spmd1v1TCIUwkk965pgdQk7ErFZ9aG/ukn5EkTTHwVBS2SuPU/jZenvIg7XY?= =?us-ascii?Q?FDh/EMeHKiXlzOd3B0iZqc8jUwaC0+DtF3f2YpkXpf6mj6mS5JTO4gQH6Sjv?= =?us-ascii?Q?CTx5mfL515giXxz25RGEb1FUOPChHL41pwoUtXpCoqBMZ2xHeTH2UqWjC8Oe?= =?us-ascii?Q?2Ml4GzXdBd7M0ojTtrh+v67qJzpLeZldpVx0OOPX/VfErAxdLK2nrvABGxXt?= =?us-ascii?Q?shIuEr/RSzPkJ+VcSwAWCxrZJRG9aDO6smptP4qnR5CoceFeotf+8J3/zTUD?= =?us-ascii?Q?ZiN7UD0KMQOkzcKLOFzqZvRqZDWhZQW8tzQUdojE4/WpssZyVykPo+I+dYvm?= =?us-ascii?Q?mR6yYdEmQLReTqK+zJPpgAcrxua0AzaaR5acCCanxX/rUlwPHYaE1nOMYJzs?= =?us-ascii?Q?GXjnTl/N4Tj3giOUswE15BYay0O23qVZVLwHB2P8eXU0DepeogNrwn+riotq?= =?us-ascii?Q?Pi9oLdAXWErutRe6CLSbNcvA+cx6R/BUh7PM7cqiatCpnJl8K8HA9dnnhJZI?= =?us-ascii?Q?E0ZDm+wnNrkAsKD4aEKRJlgiXyLNtxCWpR4I/pY03/RAlV5KaAJgmfBofQr/?= =?us-ascii?Q?bew/CUSqpA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0671a6a9-ff91-4088-621b-08df26b77ddd X-MS-Exchange-CrossTenant-AuthSource: MN2PR03MB5328.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:16:04.5252 (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: 4qoSO0qHSo38xpQ1wgX373/RhOVOGHf3Ctqhfqvcd15bF5qcPz/Nb5Xz0DSbB6qWBW/W56LrRC2oSTJSTCmp/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5591 X-purgate-ID: tlsNG-4011c0/1791627367-53CD3CFC-20E4EBA0/0/0 X-purgate-type: clean X-purgate-size: 1163 From: Lin Liu 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 e1cb10e1de11..3b0afb828c91 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -992,9 +992,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.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 10 10:16:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:16:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445003.1661535 (Exim 4.92) (envelope-from ) id 1xFU7s-0005M1-7R; Sat, 10 Oct 2026 10:16:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445003.1661535; Sat, 10 Oct 2026 10: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 1xFU7s-0005Lr-38; Sat, 10 Oct 2026 10:16:24 +0000 Received: by outflank-mailman (input) for mailman id 1445003; Sat, 10 Oct 2026 10:16:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU7q-0005KM-Vi for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:16:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU7q-0044YC-Cb for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:16:22 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca1031-2eae-0a2a0a5409dd-0a2a4506baae-44 for ; Sat, 10 Oct 2026 12:16:22 +0200 Received: from [40.93.196.50] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca1075-195a-0a2a45060019-285dc432211c-3 for ; Sat, 10 Oct 2026 12:16:22 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by DS7PR03MB5591.namprd03.prod.outlook.com (2603:10b6:5:2ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 10:16:19 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:16: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=LVt/0Sq1/kO7btGQRs7eN34zFohMbDr7hWvyUmgMNqZwNWx7mfMuL8kGYTQGINQ79OQUiHeYzP/Ak/y5BhtX/otL3Ab6clCeUkYZt7gyu1cP1NdhXL4WNW9YO6PBnkJ1MH9lRTEifL/6sGvjA0+IXLi2dpSVt+CbDlRk/20jtwlo9Bjx5fxa3RBzJewrGmy766oj7bZJDmTP7rkjPBt1fds4+WpJj41JD1H0BP+8NTjAnz1ZBz6JY3rTTCb3twNz1QDkCfFbILM+dDPmbzEoAjaF3zbk+cXoOrd/MKcDD5xf1uWh1qzomdCRBVg8Izxgn02v6KOEddWOD3Tg0/Xz3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dpFZYPmjLYrTEbmLk/yLvFaJ1oQ2qJLie7e4rkLRGzY=; b=jNxiYzzzQz8Fn9ah1XO/cB+QgpHEbiuXXFJ9oGSLWC0Zff0PcLClc6bkMjx7mUdCdcTCimBiNIy4htmhyAJFqnBIYOqjhaouljZYjntUIIZ6hS670bpGEiQstRYNjiYWd46aWRlt3cbbDUCc3D3dbqs4cIzjPVB8LYiMAm26xE1JQapaHeciHztwi6MqfF6sQYsVX/S6cPhJaEFzCLmjUQ6RcveFkngfv5DWETiobmBEUea+65GwJlAV75pSDYDjyV/aR+UQg0wItd4HSn7Gx7fCU8vEWw+BSCB3aAXBA/eK/DCs+nxJuwYJuxMEOJSZpMUx8GFT11/NNFpw4aIOkQ== 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=dpFZYPmjLYrTEbmLk/yLvFaJ1oQ2qJLie7e4rkLRGzY=; b=z7x15iiXS7YLCB24wDuBDLVC+EThTn2K1bUMBAB8zeY5Ixz+loWzUFhPKwPvY48TYueNNR9vnmVOh3da+dZKFTL36qGgSzxXXv86oX4uwh3e2AcLjIMsZd56IIkQdMovT16rw9q2vc8NBVVoi1HSUeZ1MN89fFlOnxc8/nBUCbc= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, Chunjie Zhu Subject: [PATCH v2 11/13] x86/nestedsvm: update vmrun without pending or deferred Date: Sat, 10 Oct 2026 18:13:24 +0800 Message-Id: <2ad85517317a823d22ca5fc02fcb7ee1432b9ec8.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU0P306CA0070.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:23::13) To MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|DS7PR03MB5591:EE_ X-MS-Office365-Filtering-Correlation-Id: a251c11a-e4a1-4349-4ee5-08df26b786b5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4143699003|56012099006|11063799006|22082099003|18002099003|10067099003|261009223027099003; X-Microsoft-Antispam-Message-Info: XI5jg4/UDO0KZ4UnRl3rJgGvjmcBSNoEosdZedNvK0A80wP9AUTaqOedpJLfC27zqSsQsmBdmKikWG8KnbewHH/ea8Ddg10WanQYs482tHozLofRnN1eYsKQstsaRv+4hHUAvslpZ0z4xHBIfg8SUiLJkQw9shB/KGdSiAWlJyWXsSfMXKkxi+cV9Fvk7WFGa3XjLDngiS77PZYauPj1w+aMenSBu8gHhbcb4R/xkbi+fI3YctvFMlvyrm4OaDnqUOITCo6cAXKf50VqNCcIL56P7Z1WvUSlClVmqe4I5Q0G+7HGETUEqZJjImNzMgDDgU2k40YQ35565VpwV+lwBGQt5Ifn/7KFG4OmrRe5KgFGAjqqdknMSjkX9oEkEHIca5z31pF77eYCkiKleyu3qB1yLBpWoFVaaDFQNbu0xmDCf3b/oeek1GriIzfuU3rPwMAK07/kwDSLgUtYqr4SfokA/ND66edJ9n/pfzWdCSoSaGvGuxvhS3ArtaehR+KK/2riv8AR3UgDY/6n1yIrn/NlRfETNQVwMkDFKJvtK5x/k29aw1VVXgYWZZ3A9em4kAaEaJHbgRVedl9SS8nsolbM4yD/XCqVLeeVPMSU5nUm/qA8BBVJ6cckfvTqsSJJArgmQ9ZinYzQiteb8ZPjxE31v9yFMRyZa01y+/6RxsY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(10067099003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9ggxsVFS9APJH6lcoeCURNCJewxQoeT8ehmv17bgxsCOF9v2+wP/kjHL4xh4?= =?us-ascii?Q?3rnMG14XqcV8gY6pq6uIPyP4et1vfi2bOOAubALJal5Pajlf7Mu4sdIaS3yT?= =?us-ascii?Q?yXiZRQpgcJeRsGmApApGbfXm2IHplf0JlZV0a7rw7VzRewe6R8u/hZ7nDH7I?= =?us-ascii?Q?0iwSgyrI4FGeplVOlE3ZKSU4Xp1pKl20My31DVfxtORPG9Bv18dHTFZUA0BP?= =?us-ascii?Q?uUurteu0OD5FpfeV3NS15WaMc1UenbWqenpSiUNn5hG2rDjlZ6BiXBbZlsRT?= =?us-ascii?Q?I9kVmCZ6KTCMZOipD3qoNk25oo9dmZtpGKo/PuFSxmaXv4FbwRhv3zbZ32gv?= =?us-ascii?Q?Lm5B2MS5Cs1thmRhrVcmP+bALtmuxUgHEDhwLpbLngwp2wC0bKqaYzOmKtjS?= =?us-ascii?Q?uO8BzqMkvWYnHwcLhZAVMxbB0PVAeZZGWG9HU3eHYeH11tSLcu6QDyBL170o?= =?us-ascii?Q?AyeUKxan9fK/FqPYcUXl1NJTkxvh2PAB3Fn5t0l//ly+T/Hp/ZAIBtWWfnc7?= =?us-ascii?Q?8Al0lj6odgnw6xj+0VqBlG0O/JeLAYCeIAqKPXbBV9LLtPbi0mDKNPGffnnk?= =?us-ascii?Q?55Xa8twNEHqF0csBocQTukI9mvlmm5k3tQMKOojO0o3fhvy2UqP7BrzQI+aX?= =?us-ascii?Q?SXsTmMKMEl6NftZJBWDoCBgsDSBFhpcv2uGz7GY2IX6byoDGxrVjffqKL08E?= =?us-ascii?Q?JzD49t00+A1JWpvJNvhSMnPhQ1LPk+9MaZdnDTTR4YsC+2OeM8ekLUSj0A9P?= =?us-ascii?Q?cO4huWJXUrzvmQAo8zndIrYpdx38LlyeXR56G3EpWT0/xDITDhPcKwgyhjba?= =?us-ascii?Q?NmJAICWg+iR4Xrr93HP/js1yV2ui+4HBvZLEproFsj9L++W/t+Nr/Zp3jpf7?= =?us-ascii?Q?/sVtFYEMZzhvfoYBF3oOdTEHbQbLGSZqk5ARL3Km378RCl1JUu6m0gHo9+r0?= =?us-ascii?Q?xb79ojSIWj5gS+eZkwLMI4ryZ5GSysAbrD3u3/xdi2NDhzPRO8lBmY5sQ0GD?= =?us-ascii?Q?Di0MUW9snFs+CRbz+pbFsiFfCitwm8terjPuJMuZUW8MLfybu9VlaSo89Ux8?= =?us-ascii?Q?M6wKJ33EfxLGVcVQGxaI+DqVNXJm0lmB+lAamEo/zwjERk9pstt6qhl1Ji4Z?= =?us-ascii?Q?SL6ksThDGS8wGOHsBPGMwIxiYWYtlZv14KpAuwYLvKGRPJR6uDs30C3SV08z?= =?us-ascii?Q?ARJ8C7kkxdmF2is1maPXtPuQ9VyYYWkIht0xu0z8EsIz0nc3tKRNweCTAAOk?= =?us-ascii?Q?J0W+ZFbxNaEvVXCtz1tRb3s2qvp4nspcn+iqX+/zsYMpgp+FwmdxlHJNfCuR?= =?us-ascii?Q?FBlCjn+etimIZ+n9wwU9BglIZ5En+b8gXyoLtn2s0BSLnozpJBSsZa595s5o?= =?us-ascii?Q?axmOi1UlrcMArix7y4c/AtRkWnKA3//sHph0Jg7CpL2AhWKKgM7bC9Wa64JZ?= =?us-ascii?Q?nVQ4NSxj/WGSajgs4leylkQGlgxEv6gAjGGCjxDCmotXwSbrElzsB0LRVRit?= =?us-ascii?Q?KaLYRCox+MvyK/E+Xaein984xsiHYt3/VEPgKPyMkSgwzRqYG4I7mFTl+jmp?= =?us-ascii?Q?vQSDpKbIwNKRe/SMU0MAsAX4AxQ/93Tu/3Up6StNUpEYlr97LuvTFW1Os/8i?= =?us-ascii?Q?okFwv2g3mmtUVIE19Z6w1qJkxARk+uSJFM3aM5epzHRZX21fPIZ7lTvn3iQF?= =?us-ascii?Q?NrXsM15YYfZ4KKNXjzBlLi0cnrwHVpklvfyChoS9XjuLCcqiCpk5CcppE2rd?= =?us-ascii?Q?9RZLDVC0oA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a251c11a-e4a1-4349-4ee5-08df26b786b5 X-MS-Exchange-CrossTenant-AuthSource: MN2PR03MB5328.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:16:19.3873 (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: e4n7zzW0pl2Oh386VaELYDhWxtzR31yOG6cpTLl/yybnQQoU+yBKVdRYsqrtYYnYf5B/w6TZ/ajnmP3JLLLi8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5591 X-purgate-ID: tlsNG-16d1c6/1791627382-1FCCD77B-BCF8292D/0/0 X-purgate-type: clean X-purgate-size: 7105 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- Changes in v2: - Fold the nested p2m related part of the v1 "fix up" patch in here: nsvm_vcpu_update_nestedp2m() now clears nv->stale_np2m before checking whether the host CR3 needs updating, so a concurrent flush that sets it again is not lost. - Rebased on top of the preceding patches; no other functional change. xen/arch/x86/hvm/svm/entry.S | 48 +++++++++++++++++++++++-------- xen/arch/x86/hvm/svm/nestedhvm.h | 1 + xen/arch/x86/hvm/svm/nestedsvm.c | 33 ++++++++++++++++++++- xen/arch/x86/hvm/svm/svm.c | 11 +++++-- xen/arch/x86/x86_64/asm-offsets.c | 1 + 5 files changed, 79 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 3b0afb828c91..09a2187ac7e0 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -356,6 +356,37 @@ 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 vmcb_struct *vvmcb, *n2vmcb; + struct p2m_domain *p2m; + + ASSERT(v != NULL); + + nv = &vcpu_nestedhvm(v); + svm = &vcpu_nestedsvm(v); + vvmcb = nv->nv_vvmcx; + n2vmcb = nv->nv_n2vmcx; + + if ( !nestedhvm_paging_mode_hap(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 + * nested flush IPI from another CPU. We've got a different P2M so the + * host CR3 needs updating. + */ + if ( svm->ns_vmcb_hostcr3 != vvmcb->_h_cr3 || + n2vmcb->_h_cr3 != + pagetable_get_paddr(p2m_get_pagetable(p2m)) ) + nestedsvm_vmcb_set_nestedp2m(v, vvmcb, n2vmcb); +} + static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); @@ -511,7 +542,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 5aeffd5e416f..cb09e924dcd3 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2129,6 +2129,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); @@ -2142,8 +2144,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 void 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 Sat Oct 10 10:16:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:16:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445006.1661543 (Exim 4.92) (envelope-from ) id 1xFU7z-0005jt-FZ; Sat, 10 Oct 2026 10:16:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445006.1661543; Sat, 10 Oct 2026 10:16: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 1xFU7z-0005jj-Az; Sat, 10 Oct 2026 10:16:31 +0000 Received: by outflank-mailman (input) for mailman id 1445006; Sat, 10 Oct 2026 10:16:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU7y-0005ha-4N for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:16:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU7x-00A73P-HT for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:16:29 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca1066-bab6-0a2a0a5309dd-0a2a4509df26-12 for ; Sat, 10 Oct 2026 12:16:29 +0200 Received: from [40.107.200.27] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca107c-be1a-0a2a45090019-286bc81b868f-3 for ; Sat, 10 Oct 2026 12:16:29 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by DS7PR03MB5591.namprd03.prod.outlook.com (2603:10b6:5:2ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 10:16:26 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10:16: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=xpEVIvRfiu0uGcPK88LXRRLhLy1v0rjwgF16OUrO5VHaH42j2fPaKD+8mJ1YQF7It/YXkeT3k9S5gjKTBH+MErfvSOn3DOqoXDgqBldakSfw1kzPt2jhP23rX8KZ/8zPRsUSgGZvwc/ofbEACfZ0wSLCJJv6PQuiEZ16871BaVzJNUG9ul40KxHc9v4ZOJaGfM0GKO/JUuQTrs4YlZ/nyujPdLxnrT5kbYb6dIQpY7yMf7YnqPYFi34wpxzaUbha92P9I9rjju79wbGZE3UBfd6+Kuhs0yvAN6izca2Tl/GZSOjG3aJmiBuFY5G5okzG3Rwkyoy/qdLBOppeWchx1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=84G7VyoSq6ahE+el+e03faUCiDHk31YLBplLXYBqCOI=; b=Jcd5vmhW4e8BzO6SyCRTU9mvdiKXvjptai2SFuosC0H2RgdTNwn/vKqiWF4YW8eDzTUXTR31BdLJvuU/u51ocbxJ3t+L93nYiPJiSCihUnfYtdTOxMByR7JHI4D5j9x3+vkjpeGXi53DVbFKrRbY1n96h1sHGx+x7oi361vhriD6G57bCDpPXi+7bK0nWvJnDBxMHfDjuEOdwgmGF3gjmY4VjLDGtmdiyFl58/GgGbsrpp1S6DNmGvrvQrgEgCsIzHY/piSP4VVEGPJ+3p439AMVU25EruOfDEB56U8DpITEY2pGO/F9oPwNr0VX3CZOXWdmVoD4Qw+4uxg3JEbYTA== 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=84G7VyoSq6ahE+el+e03faUCiDHk31YLBplLXYBqCOI=; b=t6EU9Spm6lYKDgRkobOEJ5u5tn43EsHTEavrJ3qpMXr83502D/B0nWiYAWgt7lEVwBc3+ePD4gPPrI5chWlCMchZCd3C3gBo5TE0oOYZVdQnRtuArwUXXK89RCYDl2UPz7TKQjjGE94svvy3hrpT1IUIMT591TjeGEsmUu8cxTQ= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, Chunjie Zhu Subject: [PATCH v2 12/13] x86/nestedsvm: remove nv_vmentry_pending Date: Sat, 10 Oct 2026 18:13:25 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU2P306CA0074.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:3a::14) To MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|DS7PR03MB5591:EE_ X-MS-Office365-Filtering-Correlation-Id: 26a91fac-e4d6-4152-0e84-08df26b78b09 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4143699003|56012099006|11063799006|22082099003|18002099003|10067099003|261009223027099003; X-Microsoft-Antispam-Message-Info: 2iElmtdqJOAGpoks50hl6mlSWKKAc7+1NAEQatSGq5/iowt5+EaGcucFEOuGu0rTa0eAqzmRq9OVfgrP8kw+f8IYCT4kcqru/lLF9wlYHGrtTN7qkH6I325P3iBkigKy0TD7GoCQrx2gRaaGv8vQ+HZaVkt2BmJfn3++kuDhddlaQZd9sr9MHLUCqoZGIfQJwyHIFS9wbJSe9V3DApRbLSh+OYLDvnHhugJUxeUpikMvYYqo5XYcvYl84i4UXbWjVZx+yUyQjNRFgzq5zCbciXVAgxhRe+uykcKMQ4Zi2dWroy3Ad/v+QJ0vBKjhRBODpfqXZTXHar4gZKji/ZdYFmw+/CSpCfUfuiwjF29J1sPfdkXJLRFWvYnOxEpDrwGfKoDX2CYpyCeNCvIPBFFymUoRPsYl03VmWGq7cF9kcrK0CCmdMNsm5Y7Vzeho7CK9UimPDCWL38n/s/DqyEBKcf2aKjKOHnealE/VTukqYYK/G8xC4RFLf+qrSykpFIeukkfdFf8clWBNszebg+3rxx0ji7ehO3Ja3b6MkRYMPrzBeATQuEUODDxBrVAiMsXdGbbGKeUIIwT26k/+j0iEjV0ElEEp8Ph/Z/psQ99R7z6I+YDNQEA0BdrkcvzfQBfIe5lZI7TDHkPvA/PiuQ6mhjgT/UljzqWSmQ1J6Fc/07Q= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(10067099003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?IJfnkZk2/KOs4ApXr1veOoCSsJ0x1FWyLqKRxL2qGBcjIcUHsVCvWDW488lQ?= =?us-ascii?Q?jI1dHW4+nO24zzbcP+Uc+lMxKu30FCUl16uqfwUklxJKjTb81AQGu5rWTLC9?= =?us-ascii?Q?3Cez9NsdlUnmfiBLp0f7BxL90CzYlmnLOCUI3LOd1HmWUPh3neD9fw8ST6QO?= =?us-ascii?Q?CG0NxM1HW6GJyIhVpy/P1w7f0QmTpkxIXcMUnumNb3Yw631fC/Kn/lyE1kFf?= =?us-ascii?Q?9SyYVioLYdsEkf5vLCDuzrgSCBVzS3iUcZ7R5VlyfsXpRZqBEPiYfZxM7EG0?= =?us-ascii?Q?StpFTV/qARiDMlzduIawTBmczZ2ODycoS54NWP5Kbd7B/RJJkNInEhQbo9Cv?= =?us-ascii?Q?4h5uTFt7uA06UzMpBpC6lW02qoxZYeDXbgjsDmimG+oNLF2ZgiIkquDJtLYp?= =?us-ascii?Q?WdUiAVmy4XWaQnPP4aSs/q8TCMZ0ujPRrtbTKVBjQHN0Kg5pzMJFCE1VV/C5?= =?us-ascii?Q?AOu4wMUW0YRJSUvV+2qMYQz8cAr7jBDVmFzScZXoUo5DaYjXAQAlZ1kNrCR0?= =?us-ascii?Q?CgjtpJdwGL0OFjFES7iDXQoRcthNziWpRBGH+Oly4ObubSQJHsFW22dAIzDT?= =?us-ascii?Q?3nyI2LAnr0Yn0f4OPLDzJ+SIN23ybYfjyZ2Ms0UpC1C5wxbUeAx4LndungAR?= =?us-ascii?Q?7z0HTjqxPKNQs84eacP5EhTJMVDyGN9jLJoaiAHU1UcznVlILu7ubt6X8S2/?= =?us-ascii?Q?TN2+egkGcLL5HyxaNNDbitpIHhi+6I2eJLS2XOwUjncyiYbg1cnUm/fQ4ztC?= =?us-ascii?Q?wX/dw/8WAhQElqR4VL5lKxxfIbtqh3RcZD7fos2aK3PQQtjUVhL5/IWe1TD0?= =?us-ascii?Q?UulnQvDxQudqy4jQ3t0TPkaz1CUJOey8rgnESkPro6mSaJ0O7P4b2dHjRZSm?= =?us-ascii?Q?suj4K+pXIKDcOjzjUkKyu+MaeMjoNkLjAx8kDRs6IsCsgy91grmK/iTMeXXy?= =?us-ascii?Q?bdmNAshCbnI3IUcBUewc8jUKl1ecnvkoHIZGGpEruIkmkj19d03wdBds+hyc?= =?us-ascii?Q?N/Xs6CXa91v2X0lchtXsFi7vnNZtZlU7cc7sP5tOy/be+e4d8AowFSSdLsxo?= =?us-ascii?Q?m0mfyLuCcmH0SBvu/WnfLTlscz6vwocKp5NUiwXkUxj1FsxfkpbHTfW5oyjq?= =?us-ascii?Q?sL08zdioPfCHgX1foXx6EOpFpG3m9T4rbJIRhg4ytKjF3t+BdIrCPGiweK4i?= =?us-ascii?Q?X/TTwgPSB316F7+PSfZn8ThCko7OskAMAzYFI0BoQVixn7SKXnNz6iAnJHWw?= =?us-ascii?Q?8zIYnsyzgH+W0lKPtTGR4JV8ZxAClLL8o/3SbjLamKqKZqII/kOBPWkRXvyo?= =?us-ascii?Q?GWJGyRM3ftdOKuwW5q3cw5ky6xyVRqYi6pQ2PNA5qFfqAntAyfySZ1y2RIYc?= =?us-ascii?Q?n5SOWJjuYHwR0ZCSNnkaqNrHUtvuZdI/Gy9Juj4q3FkA4UD6tBMydxA/3p+T?= =?us-ascii?Q?EqPr7QD2q5NUN86NFof6KBsiFeWghUHr/PozVztEjeeUHtoLWWPtkJszEXor?= =?us-ascii?Q?NJKTQ4CpbtKBifqConhvtWAEzSN/3kGkp8cMk2WpUsdMx7/X0EOKIm/EU/O9?= =?us-ascii?Q?kqhRWseRUn5k9jUXKHpP31WOGsCdSPDTuZ8R7tR5az2CuI30cwWaPbb4SB3I?= =?us-ascii?Q?Lu1zJeh2sLY2qDZkVCbW8huXELLVdSEOEisXfAaDZEAcKdyWvBi/UaBpgs1v?= =?us-ascii?Q?0VaMwaEiBPPD+pkI7uQpBkPF2dJJ2fcU8xL6Z1la/1ycaknNYtnPURWhj2Ah?= =?us-ascii?Q?6f9CaXPtLQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26a91fac-e4d6-4152-0e84-08df26b78b09 X-MS-Exchange-CrossTenant-AuthSource: MN2PR03MB5328.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:16:26.7089 (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: DaEHV5OvFoM9TZ374/IYUsF65g/7iTqTfy7dj/VkVFRH+EPWsbD9XCin4eHbzqbUuJgbaFmtIq21pfTkJaapOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5591 X-purgate-ID: tlsNG-bad1c0/1791627389-39AC0034-C970A118/0/0 X-purgate-type: clean X-purgate-size: 2570 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- Changes in v2: - No functional change, rebased only. 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 09a2187ac7e0..da5cd4848bb6 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1407,31 +1407,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 Sat Oct 10 10:16:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:16:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445013.1661552 (Exim 4.92) (envelope-from ) id 1xFU8G-0006KC-TC; Sat, 10 Oct 2026 10:16:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445013.1661552; Sat, 10 Oct 2026 10:16: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 1xFU8G-0006JJ-Q7; Sat, 10 Oct 2026 10:16:48 +0000 Received: by outflank-mailman (input) for mailman id 1445013; Sat, 10 Oct 2026 10:16:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFU8E-0006GG-Ra for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:16:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFU8E-0044YC-8C for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 12:16:46 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca1063-2eae-0a2a0a5409dd-0a2a4507e9d6-34 for ; Sat, 10 Oct 2026 12:16:46 +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 6aca108c-b4ea-0a2a45070019-286bc81ebe9c-3 for ; Sat, 10 Oct 2026 12:16:45 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by DS7PR03MB5591.namprd03.prod.outlook.com (2603:10b6:5:2ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Sat, 10 Oct 2026 10:16:43 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0496.017; Sat, 10 Oct 2026 10: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=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=mwraQ8W7GR0UFWGvMoTuIbQq6veXONEoc5DRSQYpqzUAPw5v5Tx5yjh246Cu6dj3r9W09UyPudLL0OezSySF+1N+A96HoDHHu/8cDUcmx3vd6Zo/zWayvYK3EAkB73dXcUCL/3yrR3o0z+S9BAOUL6dUy+dM4qXKpddXUu5xOc/WLDazAoi8r/pWrKJmE5sV+7ijY5EDb9u91FanGGIUh8zm5q2QHlNYjNw8VKiH+OiBfp/Bm1LXsevZ37zoiRGAOu4IVsE2p/agLimJIsl/iko9q5edNRnAmXv2B2+MzJOJAnendsiDzVSyQwXKGMbrOOsRIAXiwrzawwYgf1ISeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LbsvD4NFq5A2h8etUsRMpbeRgLqfmLD61kIxJLAZioo=; b=akN9F4rpiTzdV6lUKUBqDAJozN5CLSY0ojIRTllQFa2UMdWvenOFIJgS6KsIZn9k68OTen0Zk+zl7t2dGV6dPbsqeC7Omkhb36qAe4AZfe2anNhDRuAaCG8NlFWoWWWWbJDFJkO6FPM0PiUpq90KTGJKk2uf6jAiEl8YWmSCGh2QDaiHsqt3a8yHGtmv0G0+A5n86ADquaxVk7x3lu4l0X/6sE2iCYcJvNdva368RanWu8Uye90eji+z19X/RXInd/yMGIbxngEniqnziIRNFnFh8IK5FgZy6aKhSWCAHAJVZjpAVGjOhVcspVeLSNIhlh0miKTWBN1xNQ6UCiDKWw== 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=LbsvD4NFq5A2h8etUsRMpbeRgLqfmLD61kIxJLAZioo=; b=OJVehhq3KXq4KKzd5Gmx31mIpS9zAe1CPgD9MO6PbY9SafNCRp6NLvru5BMOZePbBFsdlHe+81fSnsbXyYUUmnj32ViM6F6jhSOQ0YKlz5qmiWEzIK6XuJBZqDEas5OIrdp3nlQvGL+QGedzquWxfOUfHmtvF32hDpi4zG1Ujao= Authentication-Results: mx.microsoft.com 1; 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: ross.lagerwall@citrix.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, Chunjie Zhu Subject: [PATCH v2 13/13] x86/nestedsvm: update vmexit without pending or deferred flag Date: Sat, 10 Oct 2026 18:13:26 +0800 Message-Id: <957eded24f073f5b6d05c83a6e13dd3d093892ff.1791625578.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KUZPR04CA0004.apcprd04.prod.outlook.com (2603:1096:d10:32::6) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|DS7PR03MB5591:EE_ X-MS-Office365-Filtering-Correlation-Id: c167f3d0-509e-4df0-4a61-08df26b79513 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4143699003|56012099006|11063799006|22082099003|18002099003|10067099003|261009223027099003; X-Microsoft-Antispam-Message-Info: Xutdq2874zBXQmBKpUH6imSP23Vf33Dw39GZvQCGM+uLp3QLHI/IK4eSyHDgLgmFt2NPxF4auA1kuPmd1vTgf+h0wgMn3gLNlZ7m7BAwC/X1sGlWVxHf0K79PZsO/DcAtilrhTSufdm3q+b2z3Q/xeZZqScsFrtdaJV2SNV+dr2ERPAXyD/U/904g/gH03QHbUdEjP/A0u9aCUOCG5sGxb2pojXy6DQOpQfLwLz6+2mo+GTjH9pX3Jd1c+dXuqrfd+DLkVakwOP7+smN3leL1ly3Wqc+ua7G1jC7KHgjFrCECqQuvHSvSK6UePXZ6Y7mo47q4fsq4prnjAeA6HUP+C9gXDjYMh1NpE7aJ4Tq3X47nYa7aOS+XTXVJmuQYuZgjOTOd+LDf5NGj/AT/ml+1pRm65wOsUiOd7Cpd6lvNckiwm5A5pKIsfCjhAS0zmq8CkKG0ALhIq9N14KOnaovriw4aEtoyyTfXwQMiCSklljwhTbp8bGYwyvB0f8rfnIbjYUJnNUaR04WzQsFJEYH0oAH+7Ovg7ORLFHGl4fhonWaisi/wur48Ob9lbUl/2xP8jG1+AyRV6f7/bV99rHZfEI59/gquRqV8veMH/yaxk3XEzYMVbFJTv4KwsrNf44Arr34Huv+/FllBKSmf1Ee3BC1ayIk8VogtFW1ELtNjd0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(10067099003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KN43jGYbkO+99GLOD02iZfAyCtZnqyf1i4xPp9ncBzrEawIwdQ21uR4B/WUR?= =?us-ascii?Q?l058fhxa6CydXHwSvFFPWpfZPa40TqN+G0wSDoDv3iM8jH12zZcw5W6ScxN7?= =?us-ascii?Q?gWVVAbUE1zwAb88lj2bFM9nKo9mKls1BHCI5e6o+bk26KxqfXuKov3rCXPAB?= =?us-ascii?Q?6AXS72MnAAYpUgi/6weVSGwzLspAlW/PBHvZfbiMjVfj6FtBJsDCIqW8+I7O?= =?us-ascii?Q?D6KvdYiVs9swJtcEfdsxhAL2Yb+Gs3JZ/U3Ai+eNryw2d2eGjgbKFHkaPvEu?= =?us-ascii?Q?dJb4UweWhimmm/9Tl84Qu9UTH1gHN996mlNO+sIT2WuZ3kLvbQyak9hyI8lw?= =?us-ascii?Q?UN14p77DxtlbJgmdRnr8b4MDUg7TUKR0ymfuydgU2t0ZqU75D5sMI6mw2ARV?= =?us-ascii?Q?SH8gvPHQYFMzg8/Z00L54U8ycgeMT2ZPCNd9qNd2UJhx1RXMWjxVTPPf8yPW?= =?us-ascii?Q?RdzFlNzQc9JaWVarM06LRCEY48sLibN4clq0SsRGzf7UBCrRLlp5lQJfEQzE?= =?us-ascii?Q?ty+50tlal2WfqJKW1X6wZgvBJnx3vG51ITIgkbi3k03H0q42Qg2VwPKk9RCo?= =?us-ascii?Q?EkbQs1+Orm0QTc6DZABRQs2oMK/tNVI+XyPpkSqf1QIJy9nyziUsZy1uuHjx?= =?us-ascii?Q?T3YKHIG6eIoHhwLw1P22LKi8i3yCEH0M7huwU4M7Esftyucpoiuq1G7XX7rI?= =?us-ascii?Q?Wvikxj+zk+UH2EwpD5myDhv5xgmCIzVEE7dICDfxh+GrP7vifwINYv84JRye?= =?us-ascii?Q?gqyevtq3BE8Lu24ebxseyfHvrInw8TN494o4/aicFNxUda15QCMCTW2ol1fW?= =?us-ascii?Q?6kpd4p8RjPVdpDHSsC/GGIxjIvI8Py6ayk4zgL7CFNf52AclybTKWSIg2g/g?= =?us-ascii?Q?1IWfWNJ7h8HEfSlCNn02UIxtzxAB7JVNIrgX7KefWkxSyPLmkTswak8mawVI?= =?us-ascii?Q?mwblN3xE8lOsWdKZ5MUeWMYzzm2FfutDDg7s0r8nipNomC3b+jq7af2/WytL?= =?us-ascii?Q?6V95BwiYbAal/4odV54gWkOycOaeQkCIIbHj6I999e92M9srVtQGmQUYCq8G?= =?us-ascii?Q?SzRgHWabOHn4sIyF5IS7zDIN9zsKowtdCNaNkAnQHbBvkZwAB/29SmR/K2nZ?= =?us-ascii?Q?USPvy0oB9tWpDw/OE3fKXUF28ENwd7NHuhl5LHSnNPxR2xftFChBP3hUiTAF?= =?us-ascii?Q?f+xYXhNBJZLqZQl+LbfzFjcLOoaDXIYtP7XqE+qV3fFqXJsrpHhAOndzVNT2?= =?us-ascii?Q?gDiRkuvEUJCGQCMoid8n9qiOsU6hfcA/Qd3n/QdzC4UDQoWqCtAloHZrlIgZ?= =?us-ascii?Q?82EyH/j7DnAdAAQ+aEnNWBh4WCUr+KjxKK1RZ+AbBmicyrjuF0PzhCLoKJxj?= =?us-ascii?Q?n7OpsfcL9F6qnKCSIaWmXpdLZXEpvEABE2f6O+4j1SROneIAzXttQnG23IoL?= =?us-ascii?Q?Dz2V2MiDhD/WKCrAQ6Fc+cW9IeVpKRqyLGJEj8ydjjdL3ZE8PyFnMoIjzuBf?= =?us-ascii?Q?5/6znq7xgeUAiXvPjISH726PXuM/AT0amtoqFehioLE7KpEjbO7afZ/MRVpX?= =?us-ascii?Q?B36T6kl08UP8C3Epkh8Zf6X/td1qxvPPogVjZ4Qxu966RFUGT0Vni+2L59fn?= =?us-ascii?Q?J+ZrZZS7Od4J7wJouI+gvX8hcHTs7e/g2Zi2vPnkhceOC0DEVPkNz5lN+Bo/?= =?us-ascii?Q?T/AUUkLipWSo87SNm4IvqrGbwVOVwBSF7qGWn67N19QJ0smRtBZvCT1j7hH1?= =?us-ascii?Q?pNAKf0HOLQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c167f3d0-509e-4df0-4a61-08df26b79513 X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2026 10:16:43.6315 (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: DCkTJ2AgOAKYnb6P3Yya2NHqr2yTihFRMk0JaOVyZy1r2xXZ5Q9wW5exyL1v1YhwC7U+r7r+sapEtQMuu6RTow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5591 X-purgate-ID: tlsNG-ef75cf/1791627406-3C610AE4-C6EF7C7E/0/0 X-purgate-type: clean X-purgate-size: 14365 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- Changes in v2: - Rebased on top of the preceding patches (nestedsvm_vmexit_defer() now removed in its updated form that uses the correct VMCB for vGIF); no other functional change. xen/arch/x86/hvm/svm/intr.c | 4 +- xen/arch/x86/hvm/svm/nestedhvm.h | 5 +- xen/arch/x86/hvm/svm/nestedsvm.c | 164 ++++++++--------------- xen/arch/x86/hvm/svm/svm.c | 10 +- xen/arch/x86/include/asm/hvm/svm-types.h | 7 - 5 files changed, 71 insertions(+), 119 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 da5cd4848bb6..8c673bcea9f6 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; @@ -717,14 +715,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); @@ -743,15 +737,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; } @@ -765,7 +754,7 @@ 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); @@ -779,33 +768,44 @@ nsvm_vcpu_vmexit_inject(struct vcpu *v, struct cpu_user_regs *regs, 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; @@ -816,10 +816,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; } @@ -1192,7 +1198,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 @@ -1201,43 +1207,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 nestedvcpu *nv = &vcpu_nestedhvm(v); - struct vmcb_struct *n1vmcb = nv->nv_n1vmcx; - - if ( n1vmcb->_vintr.fields.vgif_enable ) - n1vmcb->_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); /* @@ -1326,11 +1304,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; @@ -1342,14 +1321,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(); @@ -1369,46 +1346,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 */ @@ -1451,7 +1400,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 cb09e924dcd3..d955077a484a 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1626,7 +1626,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; } @@ -2529,8 +2531,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 Sat Oct 10 10:39:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 10:39:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445044.1661560 (Exim 4.92) (envelope-from ) id 1xFUTi-000330-IP; Sat, 10 Oct 2026 10:38:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445044.1661560; Sat, 10 Oct 2026 10: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 1xFUTi-00032t-FJ; Sat, 10 Oct 2026 10:38:58 +0000 Received: by outflank-mailman (input) for mailman id 1445044; Sat, 10 Oct 2026 10:38:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFUTh-00032n-OO for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 10:38:57 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xFUTg-006LDA-3C; Sat, 10 Oct 2026 10:38:56 +0000 Received: from [2a02:8012:3a1:0:94b1:aa8d:8098:b789] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1xFUTg-00Fdib-2Y; Sat, 10 Oct 2026 10:38: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=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=5iDG8PX/lXyZDo3LebQztPnRw6XmuJ0rnGaESwTnB1k=; b=OIOV39c4m7o9IorgKgb5ucTeBr Xnpzv0BvglG0/CqfTLdkeR+5g79c4AjcCO2MChDrDuJoeYm4Q4BQ+lonVNjcT41FKT4W28a55FK59 CBCYmx7rXx9ox0++BO5psPRb7bkFThHp5fUXTYEaWswAbz4aYbfcbBGHqOBHe4jMTm2Q=; Message-ID: <71defbe4-44a1-4b76-8d0a-bcc6ab40515f@xen.org> Date: Sat, 10 Oct 2026 11:38:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Fix under-mapping in map_range_to_domain() To: "Orzel, Michal" , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20261007135848.220047-1-michal.orzel@amd.com> <055dc887-0cfd-4274-a5f6-e5afdd576746@xen.org> <9a4f56d4-4c2e-4d5a-8489-9300170729a3@amd.com> Content-Language: en-GB From: Julien Grall In-Reply-To: <9a4f56d4-4c2e-4d5a-8489-9300170729a3@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Michal, On 08/10/2026 11:50, Orzel, Michal wrote: > > > On 07-Oct-26 22:20, Grall, Julien wrote: >> Hi Michal, >> >> On 07/10/2026 15:58, Michal Orzel wrote: >>> If the memory region to be mapped does not start at the page boundary >>> and its end spans over the page boundary, map_range_to_domain() passes >>> a number of pages that is short by one to map_regions_p2mt(). Domain's >>> attempt to access memory within that page will fail. Fix it by calculating >>> the number of pages to be mapped taking into account the start offset. >> >> Can you provide an example where the caller doesn't suitably align? > Sure. Example is handle_device() being called on the hwdom DTB creation time for > a node whose address is not page aligned i.e. /reserved-memory node or basically > any node, given that DT spec does not mention anything about memory region > alignment and there are existing DTs like that. With reg = <0x0 0x800 0x0 > 0x1000>, today we only map 0x0-0xfff and an access to 0x1000-0x17ff faults. Thanks! > >> >>> >>> Fixes: 88c10b0d6eee ("arch/arm: let map_mmio_regions() use start and count") >>> Signed-off-by: Michal Orzel >> >> The fix LGTM in the current context. However given map_range_to_domain() >> is now used in more places (e.g. overlay), I wonder whether this is the >> right decision to allow map_range_to_domain() with non-aligned region. >> >> Imagine a user say "I want to map 0x400 - 0x1000 to domain A and map >> domain B "0x0 - 0x400". This could result to interesting behavior if the >> user is not aware of the alignment (this would become even more >> problematic if we decide to ever support different page granularity on Arm). > I agree this is not great, but this is not something introduced here: > iomem_permit_access() and the iomem_ranges rangeset already cover whole pages > and we already map the full first page.This patch only makes the p2m mapping > match what we already allow. I am possibly misinterpreting what you wrote, but I disagree with such statement. The fact existing code may be wrong doesn't mean we should continue with the wrongness. > > I don't think we can reject unaligned regions in map_range_to_domain() > though, as the host DT is not under our control and hwdom would fail to > boot on platforms with sub-page devices. I asked AI to look at the Linux boards > for Arm and Arm64 (140 boards in total with unaligned regions) and even the > boards we claim to support have nodes that would fail: > - RPI4: hdmi@7ef00700, <0x7ef01f00 0x400> > - IMX8QXP: clock-controller@5b290004, <0x5b290004 0x10000> I am not suggesting to reject unaligned regions when mapped into the hardware domain. I am suggesting to reject it when we want to passthrough to another domain. So we don't end up in a situation two different devices on the same page are passthrough to two different domains (or between Xen and a domain). Codewise, it would mean map_range_to_domain() would enforce the alignment and the caller will be left to decide what to do. We could also decide about the alignment base don whether this is the HW domain or not within the function. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Sat Oct 10 13:29:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 13:29:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445127.1661571 (Exim 4.92) (envelope-from ) id 1xFX88-0003Z6-9y; Sat, 10 Oct 2026 13:28:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445127.1661571; Sat, 10 Oct 2026 13:28: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 1xFX88-0003Yx-4Y; Sat, 10 Oct 2026 13:28:52 +0000 Received: by outflank-mailman (input) for mailman id 1445127; Sat, 10 Oct 2026 13:28:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFX86-0003Yr-Sz for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 13:28:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFX85-00H6J3-PR for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 15:28:49 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca3d6a-8faa-0a2a0a5109dd-0a2a4504e2da-44 for ; Sat, 10 Oct 2026 15:28:49 +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 6aca3d91-b57f-0a2a45040019-d155dd34dd94-3 for ; Sat, 10 Oct 2026 15:28:49 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48b03f23305so482149f8f.1 for ; Sat, 10 Oct 2026 06:28:49 -0700 (PDT) Received: from MacBookPro.mynet ([2a01:4b00:d30b:d900:6ddd:39b4:db1c:54b9]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db946323bsm10253800f8f.2.2026.10.10.06.28.48 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 10 Oct 2026 06:28: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:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791638929; x=1792243729; 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=P1/Es9O9eGH8bjYRkCHog0dJrMCbWBRJpn4ygZ0p15g=; b=mdIE8uyOCbQGp+4SXz4tvtBihmHlWc/rEMrXDSxrYb2PEQZNQfj437L7pNpHDIxh4m 1naAVTuKUK9WLMcG1z9rI4B6VaE6nt8aC8P/q0dLnUwJjI/8f9pYADKMfPibnNLUuE8u 3l5Gg4e2eP+LFsepejbdPb0o/+DyszYC+FJBpJlDLJLn+E8kN+w6zwcEZ4xWuHN4Z1gG YQz/19rWdiR0s2ykj6pvvAVC0n+pH5HXGJEisfw2bcTo4o21mGBuakLtgtbDvllkQXkD b5mpGQWDO+SQatjWU25HQRGF9nMjq26wHIgdqanhYKF+lsTRbpO6QCRNZoQR5wWcP9fF iJRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791638929; x=1792243729; 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=P1/Es9O9eGH8bjYRkCHog0dJrMCbWBRJpn4ygZ0p15g=; b=Y779/RmTF1H1WRepzSZNpfTNh509jo7b2UdEI6CMbilS6WVZDqyfJD4AgztSTTJUyv M7DQQlbfSwOL1J5ufQRWCgudbsglpQfJCRi0iGpQjA2BghUiOzpH9UXL17FolOKbMWyX ABaGp9OZ4PSAfC/DwrNp35byjBPYJsUtLUenhmVAWQe77/B/nOJJeo6OhbUOl28jVW+M 6EDJy1weF2v3YArvCBYiBAJMU1vvL8qLZf2XPTos7dh6OdHhewKtyiTVj8RaH4/8aqJX TQbnLugVHPQ6AoNr2n39EbNyTFv3Fyh7MKVzn6SWJrDp+l9XfgRnkFbGJ5A3eW+RJugu rqJA== X-Gm-Message-State: AFq9FYJo/dvFramTjbmu+eTUWrbtAs3Bmc9abHE9F+V9HUIKv49rbrbT QGY2fUN/iTwl4dX03HteDTeNWngA45dH3B6O/1nTHGBEcP2AGEoNn566OI0KAu+yuTo= X-Gm-Gg: AYBFou2DrHNJs09wprEezUHF1q/xmVNpUKJD+BeP4p7Xhh+AEZO2ujcaRGU0nJGfP9U 9jTkYkWaubqcx6CZnP0BLHTnbd7smJEISYdLR5vaPBxdN5kipXAzsWZ6sF40yAQdJr+cToM5Cms ilg5BmokTtu5m9bvgM+kBfDDMNgDMtNeyh2f3Q7kyhv6QoYN0OcU1EoI61olRVn7HBLW1HeOOVW tQa8bikZGhzLSdcp5NH2o7qqnBfnY3wyxgX2N6EZVmPPmgnoXFdzuLqqvLsTcQ77jmIOPU56273 yrHpfsXkQAfv2oYAkvuOSYhnKgl9uyuGAfexBJTi0tKo8XNcK3ZUoTrvOCkwnKh/WN7HsPch4dr sde+lGykkhKa9O3U+UNKaLctLw4e/D8HtU38AQ6PgwuFdZMztZvLyazYAShUvsoIiVjYJOLcwsi wWF2YHYimFSaEyOVB3nCumdPuimfJzEAMOIfwUY0fQrSur39i29NRy591M+RI5Nmgxzfqjd08pW ITzsaGO0yW4DR5mzhjMWMPWt5poD4QdH53P3cw= X-Received: by 2002:a5d:5e91:0:b0:48c:7387:6b88 with SMTP id ffacd0b85a97d-48dbacdf252mr9272302f8f.37.1791638929043; Sat, 10 Oct 2026 06:28:49 -0700 (PDT) From: WeiqiW X-Google-Original-From: WeiqiW To: xen-devel@lists.xenproject.org Cc: Jason Andryuk , "Daniel P . Smith" , Weiqi Wang , WeiqiW Subject: [PATCH] xen/argo: make the ring copy length check overflow-safe Date: Sat, 10 Oct 2026 14:28:45 +0100 Message-ID: <20261010132845.36208-1-lukewang19@outlook.com> X-Mailer: git-send-email 2.50.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791638929-C28C9B50-714926AA/0/0 X-purgate-type: clean X-purgate-size: 1328 From: Weiqi Wang memcpy_to_guest_ring() bounds the copy against the ring size with if ( len + offset > XEN_ARGO_MAX_RING_SIZE ) where len and offset are unsigned int. offset is masked below PAGE_SIZE just above, but a len close to UINT_MAX makes len + offset wrap below XEN_ARGO_MAX_RING_SIZE and pass the check. The head_len computation in the loop wraps the same way, so the copy length is no longer bounded. All current callers bound len via iov_count(), so this is not reachable in practice. Do not rely on that: bound len first, then compare offset against the room that is left. No functional change for in-range inputs. Signed-off-by: WeiqiW --- xen/common/argo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/common/argo.c b/xen/common/argo.c index 0b9a54db36..b308ee8311 100644 --- a/xen/common/argo.c +++ b/xen/common/argo.c @@ -568,7 +568,8 @@ memcpy_to_guest_ring(const struct domain *d, struct argo_ring_info *ring_info, offset &= ~PAGE_MASK; - if ( len + offset > XEN_ARGO_MAX_RING_SIZE ) + if ( len > XEN_ARGO_MAX_RING_SIZE || + offset > XEN_ARGO_MAX_RING_SIZE - len ) return -EFAULT; while ( len ) -- 2.50.1 (Apple Git-155) From xen-devel-bounces@lists.xenproject.org Sat Oct 10 14:48:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 14:48:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445166.1661579 (Exim 4.92) (envelope-from ) id 1xFYMg-0007bd-Iy; Sat, 10 Oct 2026 14:47:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445166.1661579; Sat, 10 Oct 2026 14:47: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 1xFYMg-0007bW-G9; Sat, 10 Oct 2026 14:47:58 +0000 Received: by outflank-mailman (input) for mailman id 1445166; Sat, 10 Oct 2026 14:47:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFYMf-0007bQ-U9 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 14:47:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFYMf-00HDZl-6i for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 16:47:57 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca5017-bab6-0a2a0a5309dd-0a2a450b9ab6-2 for ; Sat, 10 Oct 2026 16:47:57 +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 6aca501d-b7e8-0a2a450b0019-d155dd33f077-3 for ; Sat, 10 Oct 2026 16:47:57 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48afe75f055so573922f8f.2 for ; Sat, 10 Oct 2026 07:47:57 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db9ae17e9sm9563108f8f.57.2026.10.10.07.47.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2026 07:47: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=1791643676; x=1792248476; 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=i9CJCR04M4KEKAlC6TAhPNCSjMy7tExBRGygibQ8+QA=; b=C0PB0VpOEmkh3a12iU2hdcArlQz24yxgvMWVATbveNxiiilUik2iHWt+CNMgi5yYRp D7Y/KS/r5zZao6bb/j1AhF1up4hPF1wRmBJoDC6090y1W4+El3qDbSNWoF1ayFYEgSmm ArbA5NdEMGeuGJd3x9X8ZXy/ZGdoqdBjPMIonS/B7DCt6PKXdfuyiKcw22NASY5Z2L2/ mwV1I0f/bsKf57y11qDFn9g7K0BfLUfIVoDEBtGHL+iWTstKRwv0kLZ4hqCvg2Isu3qY pby17DGW9rC1e78WwPO6yMfRVUiMIPQjiwVi1hkMIC7TIUmgaaXSZMBVJrcliKjlcH5k dWHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791643676; x=1792248476; 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=i9CJCR04M4KEKAlC6TAhPNCSjMy7tExBRGygibQ8+QA=; b=u4cfjboJsqlD8ZCo+4Clxt36MiBTHEJrwqIcAJjnE/dOfdVKiM1ZgrGH53ajklanvg fLrHYxxLIQcPD7xQ5C9s4RkmYTi6OgqUcxxTdVWMyWfIJhs86/w7Nwserjw4fEx9z5ie BO+4A7p9Cgdg/+sLLlJbnOjzGCl2vQ+D720WAftrA15XSVcJspGELpxcYESnPG8DL6Vs M0g6059UkDW01FTe+zjs9TYrtvIzp6byjgJQpzX5B2SXkvNv4keANPnJzg79D06akpc0 I4r/SKCzHVFaDqpDuE4ZBDjUE3f6WoVlGIVm205IONWg2YzlY71Si3cAzl4V/pO9g6xg 9CRg== X-Forwarded-Encrypted: i=1; AKwUvBxFQ1WzR7LMry1Ln7rOoMjHKmxn7zU9gu0D6y5Av9QrOiknuhUnYtxqFYvl1CM3RiLmYqCvBiJULik=@lists.xenproject.org X-Gm-Message-State: AFq9FYLBCf53v8O+una/ARiOuQMSSGppWbFCMqmMda1+hmyJniz2lbn3 ld571B4zC3uZMxLFlS+ej0dpcvIm1JaksoH1YmZz1Svl3Ejmfyf2HKn8 X-Gm-Gg: AYBFou1KbgJNcPFX1LMwKrfCKwdAHiHYu/Xeud4kMJgV3cQsznGnLNH1FNH8H9V2F3B 2g6R+uwXchJ9+6ivfLF+MHucqHqM2bWc/WCAWFKCd1vry3M/uF7/UqCzbuC5/pL9ETdFtxHvLk6 nJGV63rV51AFeAjOX7lWBlFtM5RaZ/HbyaVqqanPROmaCVRcRoCLbDx7WrFHp25gcvBg5hoY0xI v473afiwzJEg9cRM4dDC8Y23q6zzYhpLkFt3WkxF8u0yI4oxB0Dw5d3/r55aCqn2zea8MoX4wWj /aXhA8exAfPgGhfdpHOHuF730cQI6LhtMfUrAcL5Dw7xfxyWIQ1JpKWYYmo8v7ecN4mezqW07gx wRyoyLkBPYtPNYGdcf+rBoNrim8fKTK6zNILA5ANorvFmeBQzUNHRy8lcUN0StMaJIxOpWPIFuy 1oIK9MDw3RaMcMBmxxbBq+Gba/qbHLmucYS/TWZCdkx+5HMQhPWMAI2Rq5g0xBI4SL8Dko3bdPT Y4= X-Received: by 2002:a05:6000:29c3:b0:488:764c:7a17 with SMTP id ffacd0b85a97d-48dba788922mr6170623f8f.1.1791643676372; Sat, 10 Oct 2026 07:47:56 -0700 (PDT) Message-ID: <84d8b1c8-f716-41bf-82f7-fdfdb6207c04@gmail.com> Date: Sat, 10 Oct 2026 17:47:51 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 11/22] xen/arm: vsmmuv3: Attach Stage-1 configuration to SMMUv3 hardware To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4f83a0ee7f46e19c6afec3460a2a7e1bbe8e3c1a.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <4f83a0ee7f46e19c6afec3460a2a7e1bbe8e3c1a.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1791643677-AA6DA9EA-63932922/0/0 X-purgate-type: clean X-purgate-size: 11172 On 10/7/26 03:07, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > Attach the Stage-1 configuration to device STE to support nested > translation for the guests. My review of this is based on the full series being applied and includes the surrounding code context. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/arch/arm/include/asm/iommu.h | 7 ++ > xen/drivers/passthrough/arm/smmu-v3.c | 105 +++++++++++++++++++++++++ > xen/drivers/passthrough/arm/smmu-v3.h | 1 + > xen/drivers/passthrough/arm/vsmmu-v3.c | 18 +++++ > xen/include/xen/iommu.h | 6 ++ > 5 files changed, 137 insertions(+) > > diff --git a/xen/arch/arm/include/asm/iommu.h b/xen/arch/arm/include/asm/iommu.h > index ad15477e24..56bc9314a7 100644 > --- a/xen/arch/arm/include/asm/iommu.h > +++ b/xen/arch/arm/include/asm/iommu.h > @@ -20,6 +20,13 @@ struct arch_iommu > void *priv; > }; > > +struct iommu_guest_config { > + paddr_t s1ctxptr; > + uint8_t config; > + uint8_t s1fmt; > + uint8_t s1cdmax; > +}; > + > const struct iommu_ops *iommu_get_ops(void); > void iommu_set_ops(const struct iommu_ops *ops); > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index 9d2b8a708b..196ac660ef 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -3003,6 +3003,37 @@ static struct arm_smmu_device *arm_smmu_get_by_dev(const struct device *dev) > return NULL; > } > > +static struct iommu_domain *arm_smmu_get_domain_by_sid(struct domain *d, > + u32 sid) > +{ > + int i; > + unsigned long flags; > + struct iommu_domain *io_domain; > + struct arm_smmu_domain *smmu_domain; > + struct arm_smmu_master *master; > + struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv; > + > + /* > + * Loop through the &xen_domain->contexts to locate a context > + * associated with the target SMMU and device SID > + */ > + list_for_each_entry(io_domain, &xen_domain->contexts, list) { > + smmu_domain = to_smmu_domain(io_domain); > + > + spin_lock_irqsave(&smmu_domain->devices_lock, flags); > + list_for_each_entry(master, &smmu_domain->devices, domain_head) { > + for (i = 0; i < master->num_streams; i++) { > + if (sid != master->streams[i].id) > + continue; > + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); > + return io_domain; > + } > + } > + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); > + } > + return NULL; > +} > + > static struct iommu_domain *arm_smmu_get_domain(struct domain *d, > struct device *dev) > { > @@ -3216,6 +3247,79 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d) > xfree(xen_domain); > } > > +static int arm_smmu_attach_guest_config(struct domain *d, uint32_t sid, > + const struct iommu_guest_config *cfg) > +{ > + int ret = -EINVAL; > + unsigned long flags; > + struct arm_smmu_master *master; > + struct arm_smmu_domain *smmu_domain; > + struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv; > + struct iommu_domain *io_domain = arm_smmu_get_domain_by_sid(d, sid); > + > + if (!io_domain) > + return -ENODEV; > + > + smmu_domain = to_smmu_domain(io_domain); I might be wrong, but it feels to me that io_domain should be fetched after acquiring the lock below since concurrent deassign can free the io_domain. arm_smmu_deassign_dev() takes xen_domain->lock, decrements io_domain->ref, and if it hits 0, calls arm_smmu_destroy_iommu_domain() which frees the memory. > + > + spin_lock(&xen_domain->lock); > + > + switch (cfg->config) { > + case ARM_SMMU_DOMAIN_ABORT: > + smmu_domain->abort = true; > + smmu_domain->stage = cfg->config; > + break; > + case ARM_SMMU_DOMAIN_BYPASS: > + smmu_domain->abort = false; > + smmu_domain->stage = cfg->config; I am not quite sure where the best place is to leave this comment, but unless I am missing something, it looks like a guest can trivially disable stage-2 translation. If the guest requests CFG_BYPASS, arm_vsmmu_decode_ste() sets bypassed and guest_cfg.config becomes ARM_SMMU_DOMAIN_BYPASS. arm_smmu_attach_guest_config() then sets that stage. Consequently, arm_smmu_write_strtab_ent() finds neither s1_cfg nor s2_cfg and writes the physical STE as CFG_BYPASS, which bypasses both stages. So any device the guest puts in bypass (which Linux might legitimately do for identity domains) can read and write any physical memory, including Xen’s memory. Even for well-behaved guests, this is problematic: the device would use IOVA (which equals IPA) directly as a host physical address instead of going through the domain’s P2M. I think that guest bypass request should map to S2-only physical STE. > + break; > + case ARM_SMMU_DOMAIN_S1: > + /* Check stage-1 support */ > + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_TRANS_S1)) { > + dev_info(smmu_domain->smmu->dev, > + "stage-1 not implemented\n"); > + goto out; > + } > + > + /* If stage-2 is not supported, configure stage-1 only */ > + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_TRANS_S2)) { > + dev_warn(smmu_domain->smmu->dev, > + "SMMU does not implement stage-2 translation support. " > + "Fallback to stage-1-only translation configuration\n"); > + /* Enable Stage-1 translation. */ > + smmu_domain->stage = ARM_SMMU_DOMAIN_S1; As I already mentioned for commit #02/22, Without stage-2 there is no layer to turn the stage-1 output's IPA into PA. Should we allow this fallback only for privileged, direct-mapped domains? And apologies if this has already been discussed. > + } > + else { > + /* Check nested support */ > + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_NESTING)) { > + dev_info(smmu_domain->smmu->dev, > + "Nested translation not supported\n"); > + goto out; According to commit #07/22 "MMU-600 variant < 2 and all MMU-700" are affected. But it seems that Xen still offers SMMU, a guest still sees SMMU and might believe it is working. The attach fails with only a log line (gdprintk in arm_vsmmu_handle_cmds()) and the guest is never told. Device DMA then might land in the wrong guest memory. Please consider gating this at viommu_get_type() or at domain creation. > + } > + smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED; > + } > + > + /* Enable Stage-1 translation. */ > + smmu_domain->s1_cfg.s1ctxptr = cfg->s1ctxptr; > + smmu_domain->s1_cfg.s1fmt = cfg->s1fmt; > + smmu_domain->s1_cfg.s1cdmax = cfg->s1cdmax; > + smmu_domain->abort = false; Since all this stored per smmu_domain, one domain-wide S1 config (bypass, abort, context pointer) is applied to all of device’s SIDs (from the design doc I got this as intentional for current driver implementation) ... > + break; > + default: > + goto out; > + } > + > + spin_lock_irqsave(&smmu_domain->devices_lock, flags); > + list_for_each_entry(master, &smmu_domain->devices, domain_head) > + arm_smmu_install_ste_for_dev(master); ... ^^^ loops over all masters and applies the identical config to all of them. If, lets say, a device (PCI?) exposes several SIDs, and the guest tries to program SID 0 with one mappings and SID 1 with a different mappings, the second command will silently overwrite SID 0's mappings. I do not want to ask for extra work, but should Xen at least report an error when a guest programs different configs, rather than silently overwriting the previous one? Or at least leave a TODO? > + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); > + > + ret = 0; > +out: > + spin_unlock(&xen_domain->lock); > + return ret; > +} > + > static const struct iommu_ops arm_smmu_iommu_ops = { > .page_sizes = PAGE_SIZE_4K, > .init = arm_smmu_iommu_xen_domain_init, > @@ -3228,6 +3332,7 @@ static const struct iommu_ops arm_smmu_iommu_ops = { > .unmap_page = arm_iommu_unmap_page, > .dt_xlate = arm_smmu_dt_xlate, > .add_device = arm_smmu_add_device, > + .attach_guest_config = arm_smmu_attach_guest_config, > }; > > static __init int arm_smmu_dt_init(struct dt_device_node *dev, > diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthrough/arm/smmu-v3.h > index ef492098ae..4a912be740 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.h > +++ b/xen/drivers/passthrough/arm/smmu-v3.h > @@ -402,6 +402,7 @@ enum arm_smmu_domain_stage { > ARM_SMMU_DOMAIN_S2, > ARM_SMMU_DOMAIN_NESTED, > ARM_SMMU_DOMAIN_BYPASS, > + ARM_SMMU_DOMAIN_ABORT, > }; > > /* Xen specific code. */ > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c > index 25ba734fa7..3f557d1c4d 100644 > --- a/xen/drivers/passthrough/arm/vsmmu-v3.c > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c > @@ -319,8 +319,11 @@ static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) > { > int ret; > uint64_t ste[STRTAB_STE_DWORDS]; > + struct domain *d = smmu->d; > + struct domain_iommu *hd = dom_iommu(d); > struct arm_vsmmu_s1_trans_cfg s1_cfg = {0}; > uint32_t sid = smmu_cmd_get_sid(cmdptr[0]); > + struct iommu_guest_config guest_cfg = {0}; > > ret = arm_vsmmu_find_ste(smmu, sid, ste); > if ( ret ) > @@ -330,6 +333,21 @@ static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) > if ( ret ) > return (ret == -EAGAIN ) ? 0 : ret; > > + guest_cfg.s1ctxptr = s1_cfg.s1ctxptr; > + guest_cfg.s1fmt = s1_cfg.s1fmt; > + guest_cfg.s1cdmax = s1_cfg.s1cdmax; > + > + if ( s1_cfg.bypassed ) > + guest_cfg.config = ARM_SMMU_DOMAIN_BYPASS; > + else if ( s1_cfg.aborted ) > + guest_cfg.config = ARM_SMMU_DOMAIN_ABORT; > + else > + guest_cfg.config = ARM_SMMU_DOMAIN_S1; > + > + ret = hd->platform_ops->attach_guest_config(d, sid, &guest_cfg); > + if ( ret ) > + return ret; > + > return 0; > } > > diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h > index 37c4a1dc82..253f8bb6cb 100644 > --- a/xen/include/xen/iommu.h > +++ b/xen/include/xen/iommu.h > @@ -312,6 +312,7 @@ static inline int iommu_add_dt_pci_sideband_ids(struct pci_dev *pdev) > #endif /* HAS_DEVICE_TREE_DISCOVERY */ > > struct page_info; > +struct iommu_guest_config; > > /* > * Any non-zero value returned from callbacks of this type will cause the > @@ -387,6 +388,11 @@ struct iommu_ops { > #endif > /* Inhibit all interrupt generation, to be used at shutdown. */ > void (*quiesce)(void); > + > +#ifdef CONFIG_ARM > + int (*attach_guest_config)(struct domain *d, uint32_t sid, > + const struct iommu_guest_config *cfg); > +#endif > }; > > /* From xen-devel-bounces@lists.xenproject.org Sat Oct 10 15:17:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 15:17:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445187.1661587 (Exim 4.92) (envelope-from ) id 1xFYoq-0004Mv-Nq; Sat, 10 Oct 2026 15:17:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445187.1661587; Sat, 10 Oct 2026 15:17: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 1xFYoq-0004Mo-KZ; Sat, 10 Oct 2026 15:17:04 +0000 Received: by outflank-mailman (input) for mailman id 1445187; Sat, 10 Oct 2026 15:17:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFYop-0004La-Cg for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 15:17:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFYoo-00AbL3-3S for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 17:17:02 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca56c9-e002-0a2a0a5209dd-0a2a450b9748-34 for ; Sat, 10 Oct 2026 17:17:02 +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 6aca56ed-b7e8-0a2a450b0019-d155802ab500-3 for ; Sat, 10 Oct 2026 17:17:02 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a180fbeef5so5867855e9.1 for ; Sat, 10 Oct 2026 08:17:01 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18dcd7dd3sm86534725e9.2.2026.10.10.08.16.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2026 08: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=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=1791645421; x=1792250221; 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=NjlFr7guwoLOFhLjs/XB8izsuXbGxHF7rFdwL0lpGts=; b=ixhjA0ZaD2vWV3PGPzuCjFFXezb3D7XMwT6lF0ZN7IkMDXOkjgJcU90Zx+tD7ubOC4 CDHaAwGF/SiTxGwov0G6Gkz0aOAjxlAAYuy2PoGiBdDr4MkjxKY7uMdw3resxJKrCKgJ 0sKDdrv7mQurulhwoiOve2IkyDWuPWF1Ow2bVFkYwb6ICul3eAEZyVIpUtij49aQv/Q4 LF5znae3/qLa8PB8YOodE+b1S3gMmFxOBUIMzggJqeRl6kpveH+u5xFex3lMzYK8Q4jl CLUxhrZzIL6zaahOEVDKKnaFdSQdU+VcKBHNERGzRc0wSToekzZhKMuatJpEoa4UPnNm qDrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791645421; x=1792250221; 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=NjlFr7guwoLOFhLjs/XB8izsuXbGxHF7rFdwL0lpGts=; b=rRNcaHsU4q7SLrowJ+RFAwPw8aR7UAMxIsCgGxQqn6CaDY1jtBQv0zsRcHPEZB087a Q6yn8O0hGLHWOcuLKF6HjyBqRkGXCtAD94/iToVMbBh9qj7MNXpesWsX9duyt0ylvX5W YcKrXoE3rgoSqEl/EYSRx6ePnnCDjB9we/BTsx+7+nsMQld+RrIQSIWsQrinfon69zrJ nYpK5X1kKOjEumRw9EECcUrvr593t4zAwKvZVRC1euq5yM8pLaSHb6WHGwAeeOVoNF8r MqCKz2XmTC/tUVszUzAZm5wkpUbXTcDmr1usySVhguBJLK7YGIgvMvPNoP+zSeKRaPbq sRqQ== X-Forwarded-Encrypted: i=1; AKwUvBzOXcG9qTow9udBRQTr+wFDQILXXnK23kUdVgv6VGBpekIET34hi50EgNAGBv9Z8ucq39NwNvyKrzc=@lists.xenproject.org X-Gm-Message-State: AFq9FYIycHDDw3ObxWNg/wJRXBKZ+l86YGgIytv+jNvWgOGIFzpV02x8 uUjpboFOyXv03or3bbea6EhekIfaIf5QsD3xBPVM99L67lY6/hFoL3YB X-Gm-Gg: AYBFou1us0MUZoU7bRRNJpKtKuRJb77U/JCW2OIXXUn2Uliw/Zpg9WANGfiOfODJ9Rf VSuyS/CNpCr0w0YWTJ/OzoopSV8pllNgeF/GhbsZPMjMo0YhjZgxk+Bx+hMI1dFsxvmyed2wlp3 i7mwp15f4j/L7UcH7OJC6Q5w8KM20K75NuGBj2kuntP2u/UqVZdkN1IXWnkz8vjV2rjYQwnoOSZ b3Lnj4pAxgrZ6INq0J28XUkMBNWjy2hFGb4j/7u10SO6u8X+YU6AJo7Qy1VpRIZZEWK0GHo4bI0 4iiDQbHJWl8jDXq712dTf/kJnYDqijCKj9CUsDD8ePYTVfbCYJvFDY/F66/edGpUMT5Z/ooAePI peoru4OJIQtuYvjocAHFGrJd/ZqFd7CB75L/W3TxI14Rpqnvb1+Hk+kxANTvfAGyJIsygNqnNNE f8wK0v4RCt8f1hSFcRe7kcUXPAG5QccXK5Vi+xZvSFIcOWyhwwgtt/OCAI0QinY3puSgd7fxHLP VM= X-Received: by 2002:a05:600c:1553:b0:49f:e8bf:8f9b with SMTP id 5b1f17b1804b1-4a18e443ea6mr94381545e9.4.1791645421283; Sat, 10 Oct 2026 08:17:01 -0700 (PDT) Message-ID: <1396633e-8e1b-4ceb-82e4-f5b0b40eae0c@gmail.com> Date: Sat, 10 Oct 2026 18:16:59 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 22/22] doc/arm: vIOMMU design document To: Milan Djokic , "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 References: Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791645422-A8AC89EA-B0ABF6E3/0/0 X-purgate-type: clean X-purgate-size: 21286 On 10/7/26 03:08, Milan Djokic wrote: Hello Milan > This document outlines the design of the emulated IOMMU, > including supported features, security considerations > and future improvements. > > Signed-off-by: Milan Djokic > --- > docs/designs/arm-viommu.rst | 502 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 502 insertions(+) > create mode 100644 docs/designs/arm-viommu.rst > > diff --git a/docs/designs/arm-viommu.rst b/docs/designs/arm-viommu.rst > new file mode 100644 > index 0000000000..c68e771711 > --- /dev/null > +++ b/docs/designs/arm-viommu.rst > @@ -0,0 +1,502 @@ > +========================================================== > +Design Proposal: Add SMMUv3 Stage-1 Support for XEN Guests > +========================================================== > + > +:Author: Milan Djokic > +:Date: 2026-02-13 > +:Status: Draft > + > +Introduction > +============ > + > +The SMMUv3 supports two stages of translation. Each stage of translation > +can be > +independently enabled. An incoming address is logically translated from > +VA to > +IPA in stage 1, then the IPA is input to stage 2 which translates the IPA to > +the output PA. Stage 1 translation support is required to provide > +isolation between different > +devices within OS. XEN already supports Stage 2 translation but there is no > +support for Stage 1 translation. > +This design proposal outlines the introduction of Stage-1 SMMUv3 support > +in Xen for ARM guests. Look like this doc does not mention the stage-1-only fallback. > + > +Motivation > +========== > + > +ARM systems utilizing SMMUv3 require stage-1 address translation to > +ensure secure DMA and > +guest managed I/O memory mappings. > +With stage-1 enabled, guest manages IOVA to IPA mappings through its own > +IOMMU driver. > + > +This feature enables: > + > +- Stage-1 translation for the guest domain > +- Device passthrough with per-device I/O address space > + > +Design Overview > +=============== > + > +These changes provide emulated SMMUv3 support: > + > +- **SMMUv3 Stage-1 Translation**: stage-1 and nested translation support > + in SMMUv3 driver. > +- **vIOMMU Abstraction**: Virtual IOMMU framework for guest stage-1 > + handling. > +- **Register/Command Emulation**: SMMUv3 register emulation and command > + queue handling. > +- **Device Tree Extensions**: Adds `iommus` and virtual SMMUv3 nodes to > + device trees for dom0 and dom0less scenarios. > +- **Build Configuration**: Introduces a Kconfig arguments > + (CONFIG_ARM_VIRTUAL_IOMMU, CONFIG_VIRTUAL_ARM_SMMU_V3) for build-time > + enablement. > + > +Depending on the domain type, the emulated IOMMU model is the following: > + > +- For the hardware domain, the host layout is re-used. The number of exposed > + IOMMUs to hardware domain is equal to number of physical IOMMUs > + present (1-1 mapping). > +- For non-hardware domain, a single vIOMMU device is exposed to the guest and > + mapped to one or more physical IOMMUs through a Xen-managed translation layer > + > +The vIOMMU feature provides a generic framework together with a backend > +implementation specific to the target IOMMU type. The backend is responsible > +for implementing the hardware-specific data structures and command handling > +logic (currently only SMMUv3 is supported). > + > +This modular design allows the stage-1 support to be reused > +for other IOMMU architectures in the future. > + > +vIOMMU architecture > +=================== > + > +Responsibilities: > + > +Guest: > + - Configures stage-1 via vIOMMU commands. > + - Handles stage-1 faults received from Xen. > + > +Xen: > + - Emulates the IOMMU interface (registers, commands, events). > + - Provides vSID->pSID mappings. > + - Programs stage-1/stage-2 configuration in the physical IOMMU. > + - Propagate stage-1 faults to guest. > + > +The stage-1 context is shared between streams assigned to the same device. > +This follows the Linux SMMUv3 driver model, where the IOMMU domain is associated > +with the master/device, while the individual SIDs are represented by separate > +STEs pointing to the same translation context. This is considered sufficient for > +the current SMMUv3 driver model, although the SMMUv3 architecture does not > +forbid having separate translation contexts for different SIDs. > + > +vIOMMU commands and faults are transmitted between guest and Xen via > +command and event queues (one command/event queue created per guest). > + > +vIOMMU command Flow: > + > +:: > + > + Guest: > + smmu_cmd(vSID, IOVA -> IPA) > + > + Xen: > + trap MMIO read/write > + translate vSID->pSID > + store stage-1 state > + program pIOMMU for (pSID, IPA -> PA) > + > +All hardware programming of the physical IOMMU is performed exclusively by Xen. > + > +vIOMMU Stage-1 fault handling flow: > + > +:: > + > + Xen: > + receives stage-1 fault > + triggers vIOMMU callback > + injects virtual fault > + > + Guest: > + receives and handles fault > + > +Register access > +--------------- > + > +Guest accesses to SMMUV3 registers are trapped via MMIO regions. vIOMMU emulates > +a subset of SMMUv3 registers relevant to currently supported features. > +Unsupported registers are handled as RAZ (Read-As-Zero) and WI (Write-Ignored) > +for the register read and write operations, respectively. > + > +vSMMUv3 is a partially emulated resource for the guest domain. Some > +feature register bits (SMMU_IDR) are reflecting what the underlying HW actually > +support while the rest is preset in the emulation layer to limit guest from > +using features which are not supported by the emulation. Also, implementer > +identification register is fully emulated, providing generic ARM implementer > +ID values, to avoid activating errata/quirk paths in the guest SMMUv3 driver. > + > +Supported SMMUv3 Commands > +------------------------- > + > +The vIOMMU implementation currently supports a subset of the SMMUv3 > +architectural command set required for stage-1 translation management. > + > +Commands are submitted by the guest through the virtual Command Queue > +(CMDQ) and consumed by Xen, which translates them into operations on the > +physical SMMUv3 hardware. > + > +Some commands are fully handled by the emulation layer, while others are > +currently treated as architectural no-ops because the required behavior > +is either implicitly guaranteed by Xen or not yet modeled explicitly. > + > +Emulation handled commands: > + > +- CMD_CFGI_STE > +- CMD_TLBI_NH_ASID > +- CMD_TLBI_NSNH_ALL > +- CMD_TLBI_NH_VA > + > +No-op/Implicitly handled commands: > + > +- CMD_SYNC > +- CMD_PREFETCH_CFG > +- CMD_CFGI_CD > +- CMD_CFGI_CD_ALL > +- CMD_CFGI_ALL > + > +Command Handling Model > +---------------------- > + > +The guest submits commands through the virtual CMDQ interface. > + > +Xen: > + > +- Validates commands > +- Translates virtual identifiers (vSID->pSID) where required > +- Programs the physical SMMU > +- Performs synchronization > + > +The physical SMMU executes the resulting invalidation or configuration > +operations. > + > +Unsupported Commands > +-------------------- > + > +Commands associated with currently unsupported architectural features > +are not implemented. > + > +This includes commands related to: > + > +- PRI > +- ATS > +- Address/Range TLB invalidation (currently, all TLBI commands perform complete > + domain TLB invalidation) > +- Advanced stall/retry semantics > +- CD runtime update/sync > + > +vSID Mapping Layer > +------------------ > + > +Each non-hardware domain-visible Stream ID (vSID) is mapped by Xen to a physical > +Stream ID (pSID). The mapping is maintained per-domain. The allocation policy > +guarantees vSID uniqueness within a domain while allowing reuse of pSIDs for > +different pIOMMUs. > + > +* Platform devices receive individually allocated vSIDs. > +* PCI devices receive a contiguous vSID range derived from RID space. > + > + > +Supported Device Model > +====================== > + > +Currently, the vIOMMU framework supports only devices described via the > +Device Tree (DT) model. This includes platform devices and basic PCI > +devices support instantiated through the vPCI DT node. ACPI-described > +devices are not supported. > + > +Guest assigned platform devices are mapped via `iommus` property: > + > +:: > + > + <&pIOMMU pSID> -> <&vIOMMU vSID> > + > +PCI devices use RID-based mapping via the root complex `iommu-map`: I failed to find iommu-map generation in libxl or dom0less. > + > +:: > + > + > + > +PCI Topology Assumptions and Constraints: > + > +- RID space must be contiguous > +- Pre-defined continuous pSID space (0-0x1000) > +- No runtime PCI reconfiguration > +- Single root complex assumed > +- Mapping is fixed at guest DT construction > + > +Constraints for PCI devices will be addressed as part of the future work on > +this feature. > + > +Security Considerations > +======================= > + > +Stage-1 translation provides isolation between guest devices by > +enforcing a per-device I/O address space, preventing unauthorized DMA. > +With the introduction of emulated IOMMU, additional protection > +mechanisms are required to minimize security risks. > + > +1. Observation: > +--------------- > +Support for Stage-1 translation in SMMUv3 introduces new data structures > +(`s1_cfg` alongside `s2_cfg`) > +and logic to write both Stage-1 and Stage-2 entries in the Stream Table > +Entry (STE), including an `abort` > +field to handle partial configuration states. > + > +**Risk:** > +Without proper handling, a partially applied configuration > +might leave guest DMA mappings in an inconsistent state, potentially > +enabling unauthorized access or causing cross-domain interference. > + > +**Mitigation:** *(Handled by design)* > +This feature introduces logic that writes both `s1_cfg` and `s2_cfg` to > +STE and manages the `abort` field - only considering > +configuration if fully attached. This ensures incomplete or invalid > +device configurations are safely ignored by the hypervisor. Please see a potential bypass issue in commit #11/22 > + > +2. Observation: > +--------------- > +Guests can now invalidate Stage-1 caches; invalidation needs forwarding > +to SMMUv3 hardware to maintain coherence. > + > +**Risk:** > +Failing to propagate cache invalidation could allow stale mappings, > +enabling access to old mappings and possibly > +data leakage or misrouting between devices assigned to the same guest. > + > +**Mitigation:** > +The guest must issue appropriate invalidation commands whenever > +its stage-1 I/O mappings are modified to ensure that translation caches > +remain coherent. > + > +3. Observation: > +--------------- > +Introducing optional per-guest enabled features (`viommu` argument in xl > +guest config) means some guests > +may opt-out. > + > +**Risk:** > +Guests without vIOMMU enabled (stage-2 only) could potentially dominate > +access to the physical command and event queues, since they bypass the > +emulation layer and processing is faster comparing to vIOMMU-enabled guests. > + > +**Mitigation:** > +Audit the impact of emulation overhead effect on IOMMU processing fairness > +in a multi-guest environment. > +Consider enabling/disabling stage-1 on a system level, instead of per-domain. > + > +4. Observation: > +--------------- > +Guests have the ability to issue Stage-1 IOMMU commands like cache > +invalidation, stream table entries > +configuration, etc. An adversarial guest may issue a high volume of > +commands in rapid succession. > + > +**Risk:** > +Excessive commands requests can cause high hypervisor CPU consumption > +and disrupt scheduling, > +leading to degraded system responsiveness and potential > +denial-of-service scenarios. > + > +**Mitigation:** > + > +- Implement vIOMMU commands execution restart and continuation support: > + > + - Introduce processing budget with only a limited amount of commands > + handled per invocation. > + - If additional commands remain pending after the budget is exhausted, > + defer further processing and resume it asynchronously, e.g. via a > + per-domain tasklet. > + > +- Batch multiple commands of same type to reduce emulation overhead: > + > + - Inspect the command queue and group commands that can be processed > + together (e.g. multiple successive invalidation requests or STE > + updates for the same SID). > + - Execute the entire batch in one go, reducing repeated accesses to > + guest memory and emulation overhead per command. > + - This reduces CPU time spent in the vIOMMU command processing loop. > + The optimization is applicable only when consecutive commands of the > + same type operate on the same SID/context. > + > +5. Observation: > +--------------- > +Some guest commands issued towards vIOMMU are propagated to pIOMMU > +command queue (e.g. TLB invalidate). > + > +**Risk:** > +Excessive commands requests from abusive guest can cause flooding of > +physical IOMMU command queue, > +leading to degraded pIOMMU responsiveness on commands issued from other > +guests. > + > +**Mitigation:** > + > +- Batch commands that are propagated to the pIOMMU command queue and > + implement batch execution pause/continuation. > + Rely on the same mechanisms as in the previous observation > + (command continuation and batching of pIOMMU-related commands of the same > + type and context). > +- If possible, implement domain penalization by adding a per-domain budget > + for vIOMMU/pIOMMU usage: > + > + - Apply per-domain dynamic budgeting of allowed IOMMU commands to > + execute per invocation, reducing the budget for guests with > + excessive command requests over a longer period of time > + - Combine with command continuation mechanism > + > +6. Observation: > +--------------- > +The vIOMMU feature includes an event queue used to forward IOMMU events > +to the guest (e.g. translation faults, invalid Stream IDs, permission errors). > +A malicious guest may misconfigure its IOMMU state or intentionally trigger > +faults at a high rate. > + > +**Risk:** > +Occurrence of IOMMU events with high frequency can cause Xen to flood the > +event queue and disrupt scheduling with > +high hypervisor CPU load for events handling. > + > +**Mitigation:** > + > +- Implement fail-safe state by disabling events forwarding when faults > + are occurred with high frequency and > + not processed by guest: > + > + - Introduce a per-domain pending event counter. > + - Stop forwarding events to the guest once the number of unprocessed > + events reaches a predefined threshold. > + > +- Consider disabling the emulated event queue for untrusted guests. > +- Note that this risk is more general and may also apply to stage-2-only > + guests. This section addresses mitigations in the emulated IOMMU layer > + only. Mitigation of physical event queue flooding should also be considered > + in the target pIOMMU driver. > + > +7. Observation: > +--------------- > +vIOMMU `CFGI_STE` commands can trigger serialized STE programming on the pIOMMU > +while `xen_domain->lock`, `devices_lock` and `cmd_queue_lock` are held, with > +local interrupts disabled. STE programming may issue multiple polling CMD_SYNC > +operations, each with a one-second timeout. > + > +**Risk:** > +An abusive guest can issue CFGI_STE commands that cause multiple CMD_SYNC > +operations to reach their polling timeout. This can keep a pCPU with interrupts > +disabled for a significant period of time, delaying interrupt handling and > +potentially degrading the responsiveness of Xen and other domains running on > +the same pCPU. > + > +**Mitigation:** > + > +- Implement pinning or otherwise maintaining the lifetime of the required > + objects before releasing the relevant locks, allowing the > + serialized STE programming to be performed without holding locks and with > + local interrupts enabled. > +- Consider redesigning the SMMUv3 command processing and locking model in > + future improvements to avoid performing potentially long-running pIOMMU > + operations while holding locks and with local interrupts disabled. > + > +Performance Impact > +================== > + > +With iommu stage-1 and nested translation inclusion, performance > +overhead is introduced comparing to existing, > +stage-2 only usage in Xen. Once mappings are established, translations > +should not introduce significant overhead. > +Emulated paths may introduce moderate overhead, primarily affecting > +device initialization and event/command handling. > +Testing is performed on Renesas R-Car platform. > +Performance is mostly impacted by emulated vIOMMU operations, results > +shown in the following table. > + > ++-------------------------------+---------------------------------+ > +| vIOMMU Operation | Execution time in guest | > ++===============================+=================================+ > +| Reg read | median: 645ns, worst-case: 2us | > ++-------------------------------+---------------------------------+ > +| Reg write | median: 630ns, worst-case: 1us | > ++-------------------------------+---------------------------------+ > +| Invalidate TLB | median: 2us, worst-case: 10us | > ++-------------------------------+---------------------------------+ > +| Invalidate STE | median: 5us worst_case: 100us | > ++-------------------------------+---------------------------------+ > + > +With vIOMMU exposed to guest, guest OS has to initialize IOMMU device > +and configure stage-1 mappings for the devices > +attached to it. > +Following table shows initialization stages which impact stage-1 enabled > +guest boot time and compares it with > +stage-1 disabled guest. > + > +NOTE: Device probe execution time varies depending on device complexity. > +A USB host controller was selected as the test device in this case. > + > ++---------------------+-----------------------+------------------------+ > +| Stage | Stage-1 Enabled Guest | Stage-1 Disabled Guest | > ++=====================+=======================+========================+ > +| IOMMU Init | ~10ms | / | > ++---------------------+-----------------------+------------------------+ > +| Dev Attach / Mapping| ~100ms | ~90ms | > ++---------------------+-----------------------+------------------------+ > + > +For devices configured with dynamic DMA mappings, DMA allocate/map/unmap > +operations performance is > +also impacted on stage-1 enabled guests. > +Dynamic DMA mapping operation trigger emulated IOMMU functions like mmio > +write/read and TLB invalidations. > + > ++---------------+---------------------------+--------------------------+ > +| DMA Op | Stage-1 Enabled Guest | Stage-1 Disabled Guest | > ++===============+===========================+==========================+ > +| dma_alloc | median: 20us, worst: 5ms | median: 8us, worst: 60us | > ++---------------+---------------------------+--------------------------+ > +| dma_free | median: 500us, worst: 10ms| median: 6us, worst: 30us | > ++---------------+---------------------------+--------------------------+ > +| dma_map | median: 12us, worst: 60us | median: 3us, worst: 20us | > ++---------------+---------------------------+--------------------------+ > +| dma_unmap | median: 400us, worst: 5ms | median: 5us, worst: 20us | > ++---------------+---------------------------+--------------------------+ > + > +Testing > +======= > + > +- QEMU-based ARM system tests for Stage-1 translation. > +- Actual hardware validation to ensure compatibility with real SMMUv3 > + implementations. > +- Unit/Functional tests validating correct translations (not implemented). > + > +Migration and Compatibility > +=========================== > + > +This optional feature defaults to disabled (CONFIG_ARM_VIRTUAL_IOMMU=n, > +CONFIG_VIRTUAL_ARM_SMMU_V3=n). > + > +Future improvements > +=================== > + > +- Implement the proposed mitigations to address security risks that are > + not covered by the current design > + (events batching, commands execution continuation) > +- PCI support > +- Support for other IOMMU HW (Renesas, RISC-V, etc.) > + > +References > +========== > + > +- Original feature implemented by Rahul Singh: > + > +https://patchwork.kernel.org/project/xen-devel/cover/cover.1669888522.git.rahul.singh@arm.com/ > + > +- SMMUv3 architecture documentation > +- Existing vIOMMU code patterns (KVM, QEMU) > \ No newline at end of file From xen-devel-bounces@lists.xenproject.org Sat Oct 10 15:30:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 15:30:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445201.1661598 (Exim 4.92) (envelope-from ) id 1xFZ1e-0007bV-Ul; Sat, 10 Oct 2026 15:30:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445201.1661598; Sat, 10 Oct 2026 15:30: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 1xFZ1e-0007bO-RS; Sat, 10 Oct 2026 15:30:18 +0000 Received: by outflank-mailman (input) for mailman id 1445201; Sat, 10 Oct 2026 15:30:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFZ1d-0007bI-Cy for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 15:30:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFZ1c-00HHMl-QD for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 17:30:16 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca59be-e002-0a2a0a5209dd-0a2a45099080-26 for ; Sat, 10 Oct 2026 17:30:16 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aca5a08-be1a-0a2a45090019-d155802ed178-3 for ; Sat, 10 Oct 2026 17:30:16 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a1923f15afso1988725e9.3 for ; Sat, 10 Oct 2026 08:30:16 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18e481993sm114124975e9.2.2026.10.10.08.30.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2026 08:30: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=1791646216; x=1792251016; 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=rdsCltFn/cNp2RN68Rx6lk8r6oZbvRWdm6uZaoASPZ4=; b=VcMY5bpzaJqfdYSUD4HsUJAofXx9vgzizgUvQAeweMkVHhyPhuX8jFij5P+3F2ag0p V/cvCGsyR5SkHySKIujMbc6xSg2VQEdHAtig7vuValyVTxGOhnsLWxX02NfZui+SW5wd QqXOzkIS+HfK4D+lB090bIrCsAfhlzDJYmc2ZDUEgKyosfLwzGcaWzq0B98r9fC1HEhg /I4kPTb7acPtW1Fg8Dz3bGlWLqht/3Vh4iCFlvDh57ze4f/lY/37jAZ0wgFfb+/e86ii WoJ25beejIPwNtbO4rHsOEULNViujn5yUWPu7VkzDjAp1HvgzJOr2MV+uHoept9X0w6A h7Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791646216; x=1792251016; 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=rdsCltFn/cNp2RN68Rx6lk8r6oZbvRWdm6uZaoASPZ4=; b=Htsq7KYXfIIkDkamIIzQz7r7zczJgigrw/ZOOQmdMZOKBoL5RumXmMtcFeQDK2fXAN w4vQ+LsQpOX//mT6hg0FA3Bjka8jI6RRi04558Z3Ug4ovV3xkur++yqRR0bPAnXZIYSE QxkJo513PSacODhrxMGt6XdxtPFajwt+ouBVak9+SWa5nqggYCZd8cMvYDB3tRGKoLP/ QxPwxc6/icwkWO1S+JIRK4Hl992Qz3kcJabJeTJMvdVJft2BHCGJFEQV9AWsunwFx4x8 4iuxuhVEl//czDG3OW+canMZUPfOkDim7B7/ihAQk0jZqt/9X22kjX+GFt6p7ViNw1U4 LsqA== X-Forwarded-Encrypted: i=1; AKwUvBwaL++IuvRJxl8pQFv37tRQT4pQJjpMO9Ua1z+DJPSO3QTDBK1RVi0b6CTfDGgZ030LdTdYN4pyjsw=@lists.xenproject.org X-Gm-Message-State: AFq9FYKTtjlTr9QYYkzPbeAEoOOhXnue7MU4bJb/uyKtgRPWRYXAKGr/ 541cjLisnNN3iZlvQiOrl+fyrj0KQ5fta6o50ar3SNxRadPm4zqC4Ux1 X-Gm-Gg: AYBFou1deO29MEDi2IipL7uvvBE/3zdhEuOAQ8gnSyPGVqjJNJStvvLKDdZ3MOCK94f 03h56EOuDlg4wdSB80Y2CmRlJKEiEtAnjSUx/nlRMoEDorPLCodxJ/vaoKxRvhhJ0dNTXf/s0+1 9tHZf/i9RNqkJ2XunDfC6Vz+g3i24llsz7YBtgfAiQIO4CQ66rHWcL/22A22vAwzdopWqH6OYls Shbexj+zT/jQJcLpRnKrGRg7+QlgsOi62ixihOCvNTqV/nzkoonPom4PiU/6wgiLka8vzWqDekd bUarHRa82QWIHWKRz2D0Z6lUy5Byd3CFK9OpGxUP/6nebxDoRslEeiGmnlmD3s+pkTqkw8bltki 4rOQCIcW1nDmbY/T96QoyW96zXE3GPYZKydFJYptkMUmCHemS4N1dyI1Zbl9bHlGzDCBUzicZOE MK1g53MVpQz10pk0k90dyHZktVllsttNqIy+a1N19aSXeyqI9aAt5gQbVHCHSXLWeGr4O+fTDy9 TY= X-Received: by 2002:a05:600c:354a:b0:49c:d019:70c5 with SMTP id 5b1f17b1804b1-4a18e3ef23cmr88925775e9.0.1791646215886; Sat, 10 Oct 2026 08:30:15 -0700 (PDT) Message-ID: Date: Sat, 10 Oct 2026 18:30:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 13/22] xen/arm: vsmmuv3: IOMMU device tree node for dom0 To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791646216-3AEDE034-C78D83DD/0/0 X-purgate-type: clean X-purgate-size: 5618 On 10/7/26 03:07, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > XEN will create an IOMMU device tree node in the device tree > to enable the dom0 to discover the virtual SMMUv3 during dom0 boot. > IOMMU device tree node will only be created when viommu is enabled > via Kconfig build options. > > "iommus" property will be added for dom0 devices to virtual > IOMMU node to enable the dom0 linux kernel to configure the IOMMU. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/arch/arm/domain_build.c | 102 +++++++++++++++++++++++++++++- > xen/arch/arm/include/asm/viommu.h | 1 + > 2 files changed, 101 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index cd2e09f005..6513140133 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -557,9 +557,12 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo, > continue; > } > > - if ( iommu_node ) > + /* > + * Expose IOMMU specific properties to hwdom when vIOMMU is > + * enabled. > + */ > + if ( iommu_node && viommu_get_type() == XEN_DOMCTL_CONFIG_VIOMMU_NONE ) > { > - /* Don't expose IOMMU specific properties to hwdom */ > if ( dt_property_name_is_equal(prop, "iommus") ) > continue; > > @@ -1457,6 +1460,95 @@ int __init make_timer_node(const struct kernel_info *kinfo) > return res; > } > > +#ifdef CONFIG_ARM_VIRTUAL_IOMMU > +static int __init make_hwdom_viommu_node(const struct kernel_info *kinfo) > +{ > + uint32_t len; > + int res; > + char buf[24]; > + void *fdt = kinfo->fdt; > + const void *prop = NULL; > + const struct dt_device_node *iommu = NULL; > + struct host_iommu *iommu_data; > + gic_interrupt_t intr; > + > + if ( list_empty(&host_iommu_list) ) > + return 0; > + > + list_for_each_entry( iommu_data, &host_iommu_list, entry ) > + { > + if ( iommu_data->hwdom_node_created ) > + return 0; > + > + iommu = iommu_data->dt_node; > + > + snprintf(buf, sizeof(buf), "iommu@%"PRIx64, iommu_data->addr); > + > + res = fdt_begin_node(fdt, buf); > + if ( res ) > + return res; > + > + prop = dt_get_property(iommu, "compatible", &len); > + if ( !prop ) > + { > + res = -FDT_ERR_XEN(ENOENT); > + return res; > + } > + > + res = fdt_property(fdt, "compatible", prop, len); > + if ( res ) > + return res; > + > + if ( iommu->phandle ) > + { > + res = fdt_property_cell(fdt, "phandle", iommu->phandle); > + if ( res ) > + return res; > + } > + > + /* Use the same reg regions as the IOMMU node in host DTB. */ > + prop = dt_get_property(iommu, "reg", &len); > + if ( !prop ) > + { > + printk(XENLOG_ERR "vIOMMU: Can't find IOMMU reg property.\n"); > + res = -FDT_ERR_XEN(ENOENT); > + return res; > + } > + > + res = fdt_property(fdt, "reg", prop, len); > + if ( res ) > + return res; > + > + prop = dt_get_property(iommu, "#iommu-cells", &len); > + if ( !prop ) > + { > + res = -FDT_ERR_XEN(ENOENT); > + return res; > + } > + > + res = fdt_property(fdt, "#iommu-cells", prop, len); > + if ( res ) > + return res; > + > + res = fdt_property_string(fdt, "interrupt-names", "combined"); > + if ( res ) > + return res; > + > + set_interrupt(intr, iommu_data->irq, 0xf, DT_IRQ_TYPE_LEVEL_HIGH); > + > + res = fdt_property_interrupts(kinfo, &intr, 1); > + if ( res ) > + return res; > + > + iommu_data->hwdom_node_created = true; > + > + fdt_end_node(fdt); > + } > + > + return res; > +} > +#endif > + > static int __init handle_node(struct domain *d, struct kernel_info *kinfo, > struct dt_device_node *node, > p2m_type_t p2mt) > @@ -1525,6 +1617,12 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, > if ( dt_match_node(timer_matches, node) ) > return make_timer_node(kinfo); > > +#ifdef CONFIG_ARM_VIRTUAL_IOMMU > + if ( device_get_class(node) == DEVICE_IOMMU && > + viommu_get_type() != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) > + return make_hwdom_viommu_node(kinfo); So all vIOMMU nodes are created at the position of the first pIOMMU node, right? If so, could it be possible in real life for IOMMUs to sit under different buses (under different parent nodes)? > +#endif > + > /* Skip nodes used by Xen */ > if ( dt_device_used_by(node) == DOMID_XEN ) > { > diff --git a/xen/arch/arm/include/asm/viommu.h b/xen/arch/arm/include/asm/viommu.h > index 844cf34d56..5ae21042f0 100644 > --- a/xen/arch/arm/include/asm/viommu.h > +++ b/xen/arch/arm/include/asm/viommu.h > @@ -20,6 +20,7 @@ struct host_iommu { > paddr_t size; > /* Used for dom0 EVTQ and GERROR interrupts (1-1 IRQ mapping) */ > uint32_t irq; > + bool hwdom_node_created; > }; > > struct viommu_ops { From xen-devel-bounces@lists.xenproject.org Sat Oct 10 16:14:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 16:14:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445238.1661605 (Exim 4.92) (envelope-from ) id 1xFZiD-0006Mg-0f; Sat, 10 Oct 2026 16:14:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445238.1661605; Sat, 10 Oct 2026 16:14: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 1xFZiC-0006MZ-Tf; Sat, 10 Oct 2026 16:14:16 +0000 Received: by outflank-mailman (input) for mailman id 1445238; Sat, 10 Oct 2026 16:14:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFZiA-0006MN-Us for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 16:14:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFZi9-004fC0-UD for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 18:14:13 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca6407-2eae-0a2a0a5409dd-0a2a4504d3ec-34 for ; Sat, 10 Oct 2026 18:14:13 +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 6aca6455-b57f-0a2a45040019-d155802ebd0a-3 for ; Sat, 10 Oct 2026 18:14:13 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a02718da81so5041335e9.1 for ; Sat, 10 Oct 2026 09:14:13 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18bf31b83sm146824735e9.12.2026.10.10.09.14.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2026 09:14: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=1791648853; x=1792253653; 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=0QFp0ewMEzIch4eJ6rQSol9C79n5M8aePUwxgayz468=; b=ClIaGA/AMCRHRomkb1iu/gC66M2ySUbB9BatleAI9HyPM9DX6kWJ/ahJ/3nS1R/TO5 o7MaGquYPOh0P1Omp6F0/VLt71GKcA/B8iJvhHH+mRX//foZdHLBGoxGc/s6ZBc2KrXZ I/5zm6NQBAUbzbAen0TSXkIYCDHFhhu2Qkg7nmIPT2sRHD7ICUV/xgW8sze7T9d7SnTK gzZjqLTrycl/pL+/7+Hl/ypv9+oM4dNyhbXa0pLp8KHUpiTAaMglNuhs95tBPCtp9H3v 7zr8EbeWRBtgA70O2bxYIg/mBR/XqMXFJ68KNcJOlSv0mccepRR7OzkeCPHLVmmghQhC aJJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791648853; x=1792253653; 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=0QFp0ewMEzIch4eJ6rQSol9C79n5M8aePUwxgayz468=; b=f72YONMvbZQ73Kox9hf92uDB55kgANMyHmBiN3FOxyHwFjz9hRLqdbZTc2a1P6y46B V/UFqVZd1iqKgIJnnlco+n+G/4O+9wodM0tyWzxup5P1W4ignIN1EzeQR8dcKV+7vz0C qki7inYpLs5i1AmyqcRfSdOUjDQYQ/IQfS2Psw//cf2x6akbsC4/yQhdocU0fn8AV4gO BoqX+4pNKezXp4/oryXDU5fRsuJsSQJ7BTo6Rrid5tDKmB4+N6CXIkOXZqlc31on1eT6 fFSTEuOzowLFjlLcB4O0EMowrLBU7nomA3v5XYDdv1Qz0IZOzmxzGT1evtzkK84sBMT2 bX9Q== X-Forwarded-Encrypted: i=1; AKwUvBxwALkwhwzQu/zHgkjDtf+kW8Hgq7WspA/fi6/YHi7oWd/tUmSPayhpvieF66CgJVPZDe3Lnnwa/lc=@lists.xenproject.org X-Gm-Message-State: AFq9FYJARdBVNymEfc41RErtnyIFrHqa0CvYkQpyEzVX3Rcy/h/5heAl Ksmh1/TpGeD5Ivo5wqtrlx059DxCpfxF+k2TW6+PtBtP9T/iWntEjF43 X-Gm-Gg: AYBFou1ThUCbR8uykK2p+mL4NB363DJib0xlEsB/HnYr+IBxqbUyQgGHLwxgTjEC6WL K1FMY8fMnlbKzRjNZL6nT2tbl0Lem3/u+/D9B4J9HHAgci+m9qQOBFmmt69NQtPY9skOdmY6XXP LmxVmtHQun3YL6zwaf5wtt9E7dMCsMZ/f7Y45oHsSbeQTttgDjf1BwWiuBUzY5dr9KCexyrP9li PrWc5wEJtPzRotqaJZ8pUTUZ10dX5eNM4CJSWw4QSJAHFAwt+QdZk59vvnTcVvXDpSxDsT06xja W4jIg7nyEQhc09h3PGRQBtUIimpDeHUOzy1gWRYtZD+MCc06Px0t/X1YrjKP0HKC7C+qgjndmNl EkEf2hIsdna6wOd05R+Y6L/64cwgXb9f7E66AlObn3TDdlx+E8CiVndwmUtSCCsDg7N+A7bhUer RAROogg7XPcRTepr7WriSZjT+NplHi9uPwUF9ho/EjD7Axo05uPt30bj63+Qn34b5aXG1Um2Ug5 Mc9+GcfHQvP2Aw= X-Received: by 2002:a05:600c:3b0a:b0:4a1:779c:dc8e with SMTP id 5b1f17b1804b1-4a18e4a01b7mr100792775e9.10.1791648853208; Sat, 10 Oct 2026 09:14:13 -0700 (PDT) Message-ID: Date: Sat, 10 Oct 2026 19:14:10 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 10/22] xen/arm: vsmmuv3: Add support for command CMD_CFGI_STE To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791648853-51CD7B50-667F1062/0/0 X-purgate-type: clean X-purgate-size: 8033 On 10/7/26 03:06, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > CMD_CFGI_STE is used to invalidate/validate the STE. Emulated vSMMUv3 > driver in XEN will read the STE from the guest memory space and capture > the Stage-1 configuration required to support nested translation. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/drivers/passthrough/arm/vsmmu-v3.c | 169 +++++++++++++++++++++++++ > 1 file changed, 169 insertions(+) > > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c > index 10143927e7..25ba734fa7 100644 > --- a/xen/drivers/passthrough/arm/vsmmu-v3.c > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c > @@ -78,6 +78,21 @@ > > /* Helper Macros */ > #define smmu_cmd_get_command(x) FIELD_GET(CMDQ_0_OP, x) > +#define smmu_cmd_get_sid(x) FIELD_GET(CMDQ_CFGI_0_SID, x) > +#define smmu_get_ste_s1cdmax(x) FIELD_GET(STRTAB_STE_0_S1CDMAX, x) > +#define smmu_get_ste_s1fmt(x) FIELD_GET(STRTAB_STE_0_S1FMT, x) > +#define smmu_get_ste_s1stalld(x) FIELD_GET(STRTAB_STE_1_S1STALLD, x) > +#define smmu_get_ste_s1ctxptr(x) FIELD_PREP(STRTAB_STE_0_S1CTXPTR_MASK, \ > + FIELD_GET(STRTAB_STE_0_S1CTXPTR_MASK, x)) > + > +/* stage-1 translation configuration */ > +struct arm_vsmmu_s1_trans_cfg { > + paddr_t s1ctxptr; > + uint8_t s1fmt; > + uint8_t s1cdmax; > + bool bypassed; /* translation is bypassed */ > + bool aborted; /* translation is aborted */ > +}; > > /* virtual smmu queue */ > struct arm_vsmmu_queue { > @@ -165,6 +180,159 @@ static void dump_smmu_command(uint64_t *command) > gprintk(XENLOG_ERR, "cmd 0x%02llx: %016"PRIx64" %016"PRIx64"\n", > smmu_cmd_get_command(command[0]), command[0], command[1]); > } > + > +static int arm_vsmmu_find_ste(struct virt_smmu *smmu, uint32_t sid, > + uint64_t *ste) > +{ > + paddr_t addr, strtab_base; > + struct domain *d = smmu->d; > + uint32_t log2size; > + int strtab_size_shift; > + int ret; > + > + spin_lock(&smmu->strtab_cfg_lock); > + log2size = MIN(FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, smmu->strtab_base_cfg), > + SMMU_IDR1_SIDSIZE); > + spin_unlock(&smmu->strtab_cfg_lock); > + > + if ( sid >= (1U << log2size) ) > + return -EINVAL; > + > + spin_lock(&smmu->strtab_cfg_lock); > + if ( FIELD_GET(STRTAB_BASE_CFG_FMT, smmu->strtab_base_cfg) == > + STRTAB_BASE_CFG_FMT_2LVL ) > + { > + int idx, max_l2_ste, span; > + paddr_t l1ptr, l2ptr; > + uint64_t l1std; > + uint8_t sid_split = FIELD_GET(STRTAB_BASE_CFG_SPLIT, > + smmu->strtab_base_cfg); > + > + /* > + * Reserved SPLIT values behave as 6 according to the architecture. > + */ > + if ( sid_split != 0x6 && sid_split != 0x8 && sid_split != 0xA ) > + { > + sid_split = 0x6; > + } > + > + strtab_size_shift = MAX(5, (int)log2size - sid_split - 1 + 3); > + strtab_base = smmu->strtab_base & STRTAB_BASE_ADDR_MASK & > + ~GENMASK_ULL(strtab_size_shift, 0); > + spin_unlock(&smmu->strtab_cfg_lock); > + idx = (sid >> sid_split) * STRTAB_L1_DESC_DWORDS; > + l1ptr = (paddr_t)(strtab_base + idx * sizeof(l1std)); > + > + ret = access_guest_memory_by_gpa(d, l1ptr, &l1std, > + sizeof(l1std), false); > + if ( ret ) > + { > + gdprintk(XENLOG_ERR, > + "Could not read L1PTR at 0X%"PRIx64"\n", l1ptr); > + return ret; > + } > + > + span = FIELD_GET(STRTAB_L1_DESC_SPAN, l1std); > + > + /* Validate SPAN against the architecturally defined range and SPLIT. */ > + if ( !span || span > 0xB || span > sid_split + 1 ) > + { > + /* L2Ptr is invalid; this descriptor matches no valid STEs. */ > + return -EINVAL; > + } > + > + max_l2_ste = (1U << (span - 1)) - 1; > + l2ptr = FIELD_PREP(STRTAB_L1_DESC_L2PTR_MASK, > + FIELD_GET(STRTAB_L1_DESC_L2PTR_MASK, l1std)); > + idx = sid & ((1 << sid_split) - 1); > + if ( idx > max_l2_ste ) > + { > + gdprintk(XENLOG_ERR, "idx=%d > max_l2_ste=%d\n", > + idx, max_l2_ste); > + return -EINVAL; > + } > + addr = l2ptr + idx * sizeof(*ste) * STRTAB_STE_DWORDS; > + } > + else > + { > + strtab_size_shift = log2size + 5; > + strtab_base = smmu->strtab_base & STRTAB_BASE_ADDR_MASK & > + ~GENMASK_ULL(strtab_size_shift, 0); > + spin_unlock(&smmu->strtab_cfg_lock); > + addr = strtab_base + sid * sizeof(*ste) * STRTAB_STE_DWORDS; > + } > + ret = access_guest_memory_by_gpa(d, addr, ste, sizeof(*ste), false); > + if ( ret ) > + { > + gdprintk(XENLOG_ERR, > + "Cannot fetch pte at address=0x%"PRIx64"\n", addr); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int arm_vsmmu_decode_ste(struct virt_smmu *smmu, uint32_t sid, > + struct arm_vsmmu_s1_trans_cfg *cfg, > + uint64_t *ste) > +{ > + uint64_t val = ste[0]; > + > + if ( !(val & STRTAB_STE_0_V) ) > + return -EAGAIN; I am sorry, but I do not follow why invalid entry ... > + > + switch ( FIELD_GET(STRTAB_STE_0_CFG, val) ) > + { > + case STRTAB_STE_0_CFG_BYPASS: > + cfg->bypassed = true; > + return 0; > + case STRTAB_STE_0_CFG_ABORT: > + cfg->aborted = true; > + return 0; > + case STRTAB_STE_0_CFG_S1_TRANS: > + break; > + case STRTAB_STE_0_CFG_S2_TRANS: > + gdprintk(XENLOG_ERR, "vSMMUv3 does not support stage 2 yet\n"); > + goto bad_ste; > + default: > + gdprintk(XENLOG_ERR, "Invalid STE config type\n"); > + goto bad_ste; > + } > + > + cfg->s1ctxptr = smmu_get_ste_s1ctxptr(val); > + cfg->s1fmt = smmu_get_ste_s1fmt(val); > + cfg->s1cdmax = smmu_get_ste_s1cdmax(val); > + if ( cfg->s1cdmax != 0 ) > + { > + gdprintk(XENLOG_ERR, > + "vSMMUv3 does not support multiple context descriptors\n"); > + goto bad_ste; > + } > + > + return 0; > + > + bad_ste: > + return -EINVAL; > +} > + > +static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) > +{ > + int ret; > + uint64_t ste[STRTAB_STE_DWORDS]; NIT: Looks like ste[0] is only used today (first 8 bytes), the rest is uninitialised. > + struct arm_vsmmu_s1_trans_cfg s1_cfg = {0}; > + uint32_t sid = smmu_cmd_get_sid(cmdptr[0]); > + > + ret = arm_vsmmu_find_ste(smmu, sid, ste); > + if ( ret ) > + return ret; > + > + ret = arm_vsmmu_decode_ste(smmu, sid, &s1_cfg, ste); > + if ( ret ) > + return (ret == -EAGAIN ) ? 0 : ret; ... is treated as success an no-op. The physical STE keeps its old guest_cfg (added by subsequent commit) after the guest invalidates it. Could you please clarify why this is ok. Should not it become abort? > + > + return 0; > +} > + > static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) > { > struct arm_vsmmu_queue *q = &smmu->cmdq; > @@ -191,6 +359,7 @@ static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) > switch ( smmu_cmd_get_command(command[0]) ) > { > case CMDQ_OP_CFGI_STE: > + ret = arm_vsmmu_handle_cfgi_ste(smmu, command); > break; > case CMDQ_OP_PREFETCH_CFG: > case CMDQ_OP_CFGI_CD: From xen-devel-bounces@lists.xenproject.org Sat Oct 10 16:58:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 16:58:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445261.1661615 (Exim 4.92) (envelope-from ) id 1xFaPG-0004J1-4Y; Sat, 10 Oct 2026 16:58:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445261.1661615; Sat, 10 Oct 2026 16:58: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 1xFaPG-0004Iu-1L; Sat, 10 Oct 2026 16:58:46 +0000 Received: by outflank-mailman (input) for mailman id 1445261; Sat, 10 Oct 2026 16:58:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFaPE-0004Io-Rf for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 16:58:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFaPD-007LPG-JT for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 18:58:43 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aca6ec0-bab6-0a2a0a5309dd-0a2a450cb87c-8 for ; Sat, 10 Oct 2026 18:58: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 6aca6ec3-f479-0a2a450c0019-d155802dbc6a-3 for ; Sat, 10 Oct 2026 18:58:43 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a171b677d2so4612045e9.0 for ; Sat, 10 Oct 2026 09:58:43 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a192d3efb6sm69286695e9.1.2026.10.10.09.58.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2026 09:58: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=1791651523; x=1792256323; 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=2wLM0oRL98F2dE8DMArrd/THEFPncK/SZtO4L4llatE=; b=W1PfPoU8TqtJfEJtBuFOUbV6aOyab7DzyHImA64xqENUFTKbfJ1yqx9sBatye/Qp0a kOLY/cLynXkLq+Gx/ukZgpuqta9yJT0S2ZTLSPrlLZE+ZFp5PmO27VWdOIoA1xiobXB+ 9il3KvzTwdXxG34KnPdsw8obM37EINucwY3qhdFPAFU8ntekUXgXe8YZr3ulscbkwYv6 NNg3Hv8EgApcQ5mfWgkrrnuJG2zZwSqewO+Dkvev/p3kimxrGr4WEjKJeua96PA3ukcu CSuSuCmPtxkbF4puXNGp0+zDBAgz5i7SYsNJkypBpZ+ip/FWlRNGmizD2TPQLmlsFzEI V6Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791651523; x=1792256323; 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=2wLM0oRL98F2dE8DMArrd/THEFPncK/SZtO4L4llatE=; b=JlQHe7V65bGWiPCq2omWNtVJ+ksCjOF39a7WqXtj90weSalG9B4Hpd/TLKF2g+fdU0 FnnPPm5WXP0HvBGQEZ9xs430xiZZzpvmYo1ZpRPBpaGPBZlapngoS5fKvtRclUZeQ6f8 mfED4KG2TxzpTZv8/KurrMT5u/h/jllpmpKwN9++j5EfBB/jppeFD44RiIXIxo/vanxU pXQhv8h0GLqcGMIsNEjp/zyzDX9/7p+ysDE3JJ4MSlc/xzuq+cAKF4x/ALC2JjCpq7Qg JA6nwESwu+GxTQ1A5flEB94DtuHqI10qSdHyrUCsi93iiw6suWlyhyyIJC9x3JGVespS 8jAA== X-Forwarded-Encrypted: i=1; AKwUvBxxXSTch63YT4auUq2AFcBa7CJ9MDzt/+xDqaxK66a4bQghaDdLWMkSN9o5gvC19G1EzQOfq8zxL38=@lists.xenproject.org X-Gm-Message-State: AFq9FYKPPsc38jKTpT45brGbyTqiBwg7OZp1KLc31nVIyQONcVmBha0f ARQ0kbVqEj4AeVZSaCL+ZqKbDM43SeTqc2MJtjEMbo8N7WB8haLi2FTk X-Gm-Gg: AYBFou0t3KqkzkTDOc6vlY8uUKj2j/4qFouePWruYta/CjLBV3NjmBCIvKoAjV74eXi JF+wdqyy6zvcuFBf5UY+GeTN1aHU56E7lSOeEAKVvR898HbCGS+xPcdVwDPHRU0+2cbn9sxziXZ um6f46Q1nO2FwIfpuLWpnLf2NNx+ycuM3awq0CR61AWSpSCEMMt67d2ngOg1GYkRLqAfYXOK8NZ dlCI+sK8i039BiphFnL8eBzOy4Pg1Z3cIYdWs7a+F5QwvXgp2KHYNkh7DL93h+7AO1Cqn4yZu6L 1LbMsql4bUtaMbl1x5+o2Pg0KWFLfa7sWB8Vt4XDAmJP2Zl5pd1bVyK84aNy46vIX1yGzqbG6qx V2b+ocNv0iftCJZHj0kHa8VPsg7vUgdCTS7KPO1gcZ+ThFzJBojpygl/NEomnzcJGVngRffcXok zEjLbz9wGmN2071KIn1SDRlZRpvaQvejitHl/mXpFaGGvZBjWXf69kEMMpQNop/ehEddL2NPxjE 2BfCDglBeXjgw== X-Received: by 2002:a05:600c:4ec9:b0:4a1:8961:78dd with SMTP id 5b1f17b1804b1-4a18e4c9e46mr101813185e9.27.1791651522725; Sat, 10 Oct 2026 09:58:42 -0700 (PDT) Message-ID: <60e304f6-6c65-40cb-8b4b-1584e5c47272@gmail.com> Date: Sat, 10 Oct 2026 19:58:39 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 09/22] xen/arm: vsmmuv3: Add support for cmdqueue handling To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1791651523-03AD4A5B-E0D77712/0/0 X-purgate-type: clean X-purgate-size: 6409 On 10/7/26 03:06, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > Add support for virtual cmdqueue handling for guests > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/drivers/passthrough/arm/vsmmu-v3.c | 127 +++++++++++++++++++++++++ > 1 file changed, 127 insertions(+) > > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c > index c4fef6e8bd..10143927e7 100644 > --- a/xen/drivers/passthrough/arm/vsmmu-v3.c > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c > @@ -8,6 +8,7 @@ > * This needs to be fully handled in the future. > */ > > +#include > #include > #include > #include > @@ -33,6 +34,51 @@ > #define SMMU_EVTQS 19 > #define DWORDS_BYTES 8 > > +/* > + * SMMUv3 command definitions > + * Some commands are fully handled by the emulation layer, while others are > + * currently treated as architectural no-ops because the required behavior > + * is either implicitly guaranteed by Xen or not yet modeled explicitly. > + * > + * Emulation handled commands: > + * > + * - CMD_CFGI_STE > + * - CMD_TLBI_NH_ASID > + * - CMD_TLBI_NSNH_ALL > + * - CMD_TLBI_NH_VA > + * > + * No-op/Implicitly handled commands: > + * > + * - CMD_SYNC > + * - CMD_PREFETCH_CFG > + * - CMD_CFGI_CD > + * - CMD_CFGI_CD_ALL > + * - CMD_CFGI_ALL > + * > + * TODO: Remaining architecture-defined commands are not supported (error > + * produced), due to lack of support in SMMUv3 driver / emulation layer > + * TODO: Range / per-device invalidation not supported atm > + * TODO: Long-running command queue handling is not implemented (command > + * consumption should be budgeted with asynchronous resumption). > + */ > +#define CMDQ_OP_PREFETCH_CFG 0x1 > +#define CMDQ_OP_CFGI_STE 0x3 > +#define CMDQ_OP_CFGI_ALL 0x4 > +#define CMDQ_OP_CFGI_CD 0x5 > +#define CMDQ_OP_CFGI_CD_ALL 0x6 > +#define CMDQ_OP_TLBI_NH_ASID 0x11 > +#define CMDQ_OP_TLBI_NH_VA 0x12 > +#define CMDQ_OP_TLBI_NSNH_ALL 0x30 > +#define CMDQ_OP_CMD_SYNC 0x46 > + > +/* Queue Handling */ > +#define Q_BASE(q) ((q)->q_base & Q_BASE_ADDR_MASK) > +#define Q_CONS_ENT(q) (Q_BASE(q) + Q_IDX(q, (q)->cons) * (q)->ent_size) > +#define Q_PROD_ENT(q) (Q_BASE(q) + Q_IDX(q, (q)->prod) * (q)->ent_size) > + > +/* Helper Macros */ > +#define smmu_cmd_get_command(x) FIELD_GET(CMDQ_0_OP, x) > + > /* virtual smmu queue */ > struct arm_vsmmu_queue { > uint64_t q_base; /* base register */ > @@ -99,6 +145,83 @@ static inline bool smmu_get_evtq_enabled(struct virt_smmu *smmu) > spin_unlock(&smmu->cr0_lock); > > return enabled; > +}; > + > +/* Queue manipulation functions */ > +static bool queue_empty(struct arm_vsmmu_queue *q) > +{ > + return Q_IDX(q, q->prod) == Q_IDX(q, q->cons) && > + Q_WRP(q, q->prod) == Q_WRP(q, q->cons); > +} > + > +static void queue_inc_cons(struct arm_vsmmu_queue *q) > +{ > + uint32_t cons = (Q_WRP(q, q->cons) | Q_IDX(q, q->cons)) + 1; > + q->cons = Q_OVF(q->cons) | Q_WRP(q, cons) | Q_IDX(q, cons); > +} > + > +static void dump_smmu_command(uint64_t *command) > +{ > + gprintk(XENLOG_ERR, "cmd 0x%02llx: %016"PRIx64" %016"PRIx64"\n", > + smmu_cmd_get_command(command[0]), command[0], command[1]); > +} > +static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) > +{ > + struct arm_vsmmu_queue *q = &smmu->cmdq; > + struct domain *d = smmu->d; > + uint64_t command[CMDQ_ENT_DWORDS]; > + paddr_t addr; > + int ret = 0; > + > + if ( !smmu_get_cmdq_enabled(smmu) ) > + return 0; > + > + while ( !queue_empty(q) ) > + { This is unbounded loop, guest controls PROD and the advertised queue size is big enough. Below ... > + int ret; > + > + addr = Q_CONS_ENT(q); > + ret = access_guest_memory_by_gpa(d, addr, command, > + sizeof(command), false); > + if ( ret ) { > + queue_inc_cons(q); > + return ret; > + } > + > + switch ( smmu_cmd_get_command(command[0]) ) > + { > + case CMDQ_OP_CFGI_STE: > + break; > + case CMDQ_OP_PREFETCH_CFG: > + case CMDQ_OP_CFGI_CD: > + case CMDQ_OP_CFGI_CD_ALL: > + case CMDQ_OP_CFGI_ALL: > + case CMDQ_OP_CMD_SYNC: > + break; > + case CMDQ_OP_TLBI_NH_ASID: > + case CMDQ_OP_TLBI_NSNH_ALL: > + case CMDQ_OP_TLBI_NH_VA: > + ret = iommu_iotlb_flush_all(smmu->d, 1); ... TLBI does full-VMID flush and waits for the hardware. All of this runs inside one MMIO trap with cmd_queue_lock held, so CPU could stall. Yes, this is honestly mentioned in the design doc (Security Considerations, Observation ...) and doc calls it future work. Yes, this should be sorted out before driver can be treated as supported feature. So please treat my comment as a remark. For now, I would put a TODO (e.g., above the while loop so it does not get forgotten. > + if ( !ret ) > + break; > + fallthrough; > + default: > + gdprintk(XENLOG_ERR, "vSMMUv3: unhandled command\n"); > + dump_smmu_command(command); > + break; > + } > + > + if ( ret ) > + { > + gdprintk(XENLOG_ERR, > + "vSMMUv3: command error %d while handling command\n", > + ret); > + dump_smmu_command(command); > + } > + queue_inc_cons(q); > + } > + > + return ret; > } > > static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, > @@ -221,6 +344,10 @@ static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, > reg32 = smmu->cmdq.prod; > vreg_reg32_update(®32, r, info); > smmu->cmdq.prod = reg32; > + > + if ( arm_vsmmu_handle_cmds(smmu) ) > + gdprintk(XENLOG_ERR, "error handling vSMMUv3 commands\n"); > + > spin_unlock(&smmu->cmd_queue_lock); > break; > From xen-devel-bounces@lists.xenproject.org Sat Oct 10 22:11:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 22:11:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445415.1661624 (Exim 4.92) (envelope-from ) id 1xFfI1-0000dz-4J; Sat, 10 Oct 2026 22:11:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445415.1661624; Sat, 10 Oct 2026 22:11: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 1xFfI0-0000dr-Vj; Sat, 10 Oct 2026 22:11:36 +0000 Received: by outflank-mailman (input) for mailman id 1445415; Sat, 10 Oct 2026 22:11:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFfHy-0000dl-R8 for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 22:11:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFfHx-00C1X3-IS for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 00:11:33 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acab814-e002-0a2a0a5209dd-0a2a4501bf32-2 for ; Sun, 11 Oct 2026 00:11: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 6acab814-5984-0a2a45010019-b9ff1c1285ff-3 for ; Sun, 11 Oct 2026 00:11: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 1a127df076400080d7.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 10 Oct 2026 22:11:30 +0000 Received: from leducb.local (213.40.31.93.rev.sfr.net [93.31.40.213]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 1575981FCC; Sun, 11 Oct 2026 00:11:29 +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=1MAI2QqfgN2yo0slA4ww5wNdXSNQc6My1P2h7nd5f2w=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ExlyZ3QeReL0xFcZcr6lrKbdtyyF/1F11QdR9+BxJnXJs1nC9y869nPGtlLiwO8L7l7nqz8Sc lEXSxgwJkJ35A4VQ4ujCeBNlP+ndzmtKZB2z9WH/7eZzeFcE+mekbGxYltsggJdi/OMlPb1Nxph DWcnEA0lmL0DMmq0Lb2veSXs4TBeg3Sz33rmh1l4vxqnm4Sl0XdC1hekdGiEDEndXVCg648reQT QmiRq0U1APk8M84/ljNUDSfNvUA0Tujqr4+AlqMngKpELk+gYHaha7IYujV/JtpDdjgR9Wz3tQR GXSaJplsPEgQTCj9991Nqi+JBbXsSWrABnm27EmByMuw== X-Zone-Loop: f965ad316f0f786b6f5700e6fd263c6ddbd9b349eadd x-campaign-type: default x-transaction-id: 2f668421-3225-464b-8acf-33c6b638bb66 x-swg-uid: 01-68cf55e6-81cc-49fb-819d-e290ad239085 X-Mailer: Sweego Message-ID: <1791670290.8631fc262581453bbf619ec5b2062170.1a127df076400080d7@vates.tech> x-swg-bid: 1791670290.8631fc262581453bbf619ec5b2062170.1a127df076400080d7 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/2] xen/ns16550: detect and preserve UART_IER_UUE From: Baptiste Le Duc To: Zhang Zheng Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> Date: Sun, 11 Oct 2026 00:11:27 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791670288; l=2641; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=rcqIVlD1jsQOGAsTxlqeRiT5qSgxGa6V81/f8bVyIZs=; b=4wnftcPCZhbdR6juEgXcXfeJ4Zkt5YiWkYugLWuHiLWnft8rrztO8TpHLEJDQaiP6gGk3pjuo r6zxj7pinL7DDJbl5fxfFlXB9gxtZ2hxFb877nLQ+JJS7e03YA7C6xV 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: 1791670289249 X-purgate-ID: tlsNG-d62444/1791670293-BE664757-33DA9322/0/0 X-purgate-type: clean X-purgate-size: 2641 > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index 593d208483..953d166314 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > /* No interrupts. */ > ns_write_reg(uart, UART_IER, 0); Do we know of a UART where UUE reads back as 1 whatever is written? I could not find any such hardware, so I am not sure the check is needed but it might be wrong. If not, then we could drop this write but if so, then I propose to move it in a dedicated function: ``` static bool ns_is_xscale(const struct ns16550 *uart) { /* * We're going to explicitly set the UUE bit to 0 before * trying to write and read a 1 just to make sure it's not * already a 1 and maybe locked there before we even start. */ ns_write_reg(uart, UART_IER, 0); if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) { /* Now we are in a 0 state */ ns_write_reg(uart, UART_IER, UART_IER_UUE); if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) return true; } return false; } ``` > + uart->xscale = false; > + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > + { > + ns_write_reg(uart, UART_IER, UART_IER_UUE); > + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > + uart->xscale = true; > + } > + > /* Handle the DesignWare 8250 'busy-detect' quirk. */ > handle_dw_usr_busy_quirk(uart); > > @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) > UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); > > /* Enable receive interrupts. */ > - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); > + ns_write_reg(uart, UART_IER, > + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); > Every IER write has to keep UUE on an XScale UART, otherwise the UART is switched off. Open-coding the ternary at each call site makes it easy for a future caller to forget. Would it be better to add a helper, e.g.: static void ns_write_ier(const struct ns16550 *uart, unsigned int val) { ns_write_reg(uart, UART_IER, uart->xscale ? val | UART_IER_UUE : val); } and use it for all futures IER writes? Thanks for contributing! -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Sat Oct 10 22:13:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Oct 2026 22:13:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445419.1661634 (Exim 4.92) (envelope-from ) id 1xFfJX-000183-CX; Sat, 10 Oct 2026 22:13:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445419.1661634; Sat, 10 Oct 2026 22:13: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 1xFfJX-00017w-8n; Sat, 10 Oct 2026 22:13:11 +0000 Received: by outflank-mailman (input) for mailman id 1445419; Sat, 10 Oct 2026 22:13:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xFfJV-00017q-Fh for xen-devel@lists.xenproject.org; Sat, 10 Oct 2026 22:13:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFfJU-005B5U-T8 for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 00:13:08 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acab820-2eae-0a2a0a5409dd-0a2a45088230-42 for ; Sun, 11 Oct 2026 00:13:08 +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 6acab874-f659-0a2a45080019-b9ff1c239517-3 for ; Sun, 11 Oct 2026 00:13: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 1a127e070a900080d7.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 10 Oct 2026 22:13:02 +0000 Received: from [192.168.31.249] (213.40.31.93.rev.sfr.net [93.31.40.213]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id A35C381FCC; Sun, 11 Oct 2026 00:13: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=ZAu6Hk56oBtUF6yeK+C0zOkn9lPD/TWacsgO27G78p0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=sVC2PUiLSr070no8g3mXxY76witXW32SiTAif6MU/TIv9yDn28ScWzckbhCPEhGVoX40bJVVK zou2+atzqJJ0RQ+DTvsMjI4gryUD3lq/qfe9mzLx9R8M+aZ0n+OanC7VQV6OAolnS0Aw5pzDH5J w5O4ki13Gm9ffstc+/tU2UZcYSn/eh9aKZulxeiqEnh8v19IN2Qpm8XxoGlFE9NF0qQYsup8I9c I076wLz02RudPylMtaSN6EAVETQndPMlj2ENgX3ek1wlZsSoFRTs2f/LvAjW2WDxhHexBtp46hE eDwxX5uq/NyKbk1Z0uPdSkHwORzcPsYtFsm4pbyo5smw== X-Zone-Loop: e5b2f2b3987b1f8a339583ea68001ad70479a1e42374 x-campaign-type: default x-transaction-id: 6b245b9a-32b6-4213-b3a8-27f903c9e01e x-swg-uid: 01-af59a75c-e324-4c47-ace0-23ae5b215440 X-Mailer: Sweego Message-ID: <1791670382.8631fc262581453bbf619ec5b2062170.1a127e070a900080d7@vates.tech> x-swg-bid: 1791670382.8631fc262581453bbf619ec5b2062170.1a127e070a900080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Sun, 11 Oct 2026 00:13:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing To: Zhang Zheng , xen-devel@lists.xenproject.org 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 References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> 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: <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> 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: 1791670381792 X-purgate-ID: tlsNG-c1860d/1791670388-CF15E87B-9F5C6C2D/10/73395122804 X-purgate-type: spam X-purgate-size: 1367 For any reasons, it seems this patch has not been received by ML server, I couldn't find him here: https://lore.kernel.org/xen-devel/20261010031406.2057735-1-zhangzheng@iscas.ac.cn/T/#t On 10/10/26 5:21 AM, Zhang Zheng wrote: > An SBI console call may return before the UART finishes transmitting. > Wait for UART_LSR_TEMT before ns16550 reprograms the UART and clears its > FIFO, preserving pending early-console output and legacy SBI v0.1 support. > > Suggested-by: Oleksii Kurochko > Link: https://lore.kernel.org/xen-devel/8836d1e3-77c8-4447-b1ef-132620a71441@gmail.com/ > Signed-off-by: Zhang Zheng > --- > xen/drivers/char/ns16550.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index c174465059..278d38822d 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -427,6 +427,10 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) > #endif > } > > + /* Preserve output queued by firmware before taking over the UART. */ > + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) > + cpu_relax(); > + > ns16550_setup_preirq(uart); > > /* Check this really is a 16550+. Otherwise we have no FIFOs. */ From xen-devel-bounces@lists.xenproject.org Sun Oct 11 13:28:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Oct 2026 13:28:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445584.1661642 (Exim 4.92) (envelope-from ) id 1xFtat-0006tA-OB; Sun, 11 Oct 2026 13:28:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445584.1661642; Sun, 11 Oct 2026 13: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 1xFtat-0006t2-JN; Sun, 11 Oct 2026 13:28:03 +0000 Received: by outflank-mailman (input) for mailman id 1445584; Sun, 11 Oct 2026 13:28:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFtas-0006sw-3S for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 13:28:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFtar-00CWd9-Gc for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 15:28:01 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acb8ed9-bab6-0a2a0a5309dd-0a2a4502bd2e-8 for ; Sun, 11 Oct 2026 15:28:01 +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 6acb8ee1-6ca4-0a2a45020019-d155dd32b57a-3 for ; Sun, 11 Oct 2026 15:28:01 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48c4d99c32bso1016110f8f.1 for ; Sun, 11 Oct 2026 06:28:01 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48dba033a0fsm12420647f8f.14.2026.10.11.06.27.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Oct 2026 06:27: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: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=1791725281; x=1792330081; 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=BNpvVUPDUetdWXIygPA+RI81XwLH8JbVKHpBZJrVaFQ=; b=A1EdHF3jYGg0v0u4TE3O504CDglz5jODx+/DKpnPxie8Ggr+Nk5+GB1EflQzK4JDke rD9rdL8uncu8yWZC+vfHA36+NzmLyjWXkAb5oE47kmc8jR6EZPt1w0QD5XMDMfHqpLgZ qI56TNrSVEydBv9OkGB6wnKz8LyqIOLSfsq9Ox55wk/7PsfGCMhDhxiWCDDFJ3B3ODTH 7UqFd4JgilKqqLWo/aO2xe2qduEPR0DVOjqdo8hZezduumgzOmX2/VYQ89DE963OPEQp SWMYXERgvFmWm/9NmC+Z5IVW2SAb5RS23hoYxCkkPf2n9CRnq0i55qENqu08pMxh7lV4 UHDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791725281; x=1792330081; 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=BNpvVUPDUetdWXIygPA+RI81XwLH8JbVKHpBZJrVaFQ=; b=hMbR58vvM5VBK2U3z0wTmvZWQIi0yTXewvMtrhhUx2k95VeHvoFKBCRREN3jTIQ7cO NqBVumo/GgNCqRCmfSqGhgytjgzOSEE7V/nfMUuaCr507mD2E7S9qiP+THBCLILveG9R DR3TOyFkZEMvGXwI2i57DaNs+F9x5EuiQ1oWBiWdEojBQkFsBF8Fp+EOtnZ5PTyy2cII dhjhZFFYrPr9X0857e7Qm/mk1sAniMm1oseINV0Gli4Fvm6y5Ne7Qr0ta3d0Lv7+M/C7 KCkEqeMU/FreV9N1VXhRTEVlFc2T/dYaeLpE7I1spdmEKidn/EpfLZFnJlm0wpUQOzD4 3rtA== X-Forwarded-Encrypted: i=1; AKwUvBz5im6uYQUHgU9PTCtdsXrOfcH6PF9iA7EFJs39fVrsNxw/3mFQkPlL5jRWxbNJmon/K3Y4o++zC1w=@lists.xenproject.org X-Gm-Message-State: AFq9FYJn0X8BUuEtBZRxsqL9AVxlisdfbM8nLAqDaizwAlrRiHlV9yHA lkrRAhYVPm7zyAjcs2aAK4owErKYAWjbwixa+3quOqcBWdbtRt5TLoG8 X-Gm-Gg: AYBFou0v2UfDBffz2aTe5KB0zC/BQNTbhOaJHHaObhPHag0R9dHRmovtc7ikbMGIfTh d5NbH9rcIezwA/IMH3Q6M/HCevpH65X9vWOUuXGsBFEDnlrM5jWBbNHmjpJZAfW3BxzL2lhyB6u Nxg0rnEzbHUOdt1qgGrEIssku1Tgyar/DLoxpxiSmuHOtw6UHScdzM0nZ8rzDn4KbzRjhvZt4W3 teEkA7JdP5cbr/pjWPuHLb8xWMCeUOSyyE0kSVlpABvCu2Bfv54osXjx2qhnPmrEJDkMktKGS4R QtgLZFuDvhjgwod6DJjavn8d75DZa+h0FLxsXeHMC1JXX+7x0Q2sw/Mou33J/moueOJGK964Amp 2filkW0a+GGyMKNgeIagsHqTQA5RXPDPYSYPIehTwxgtN5s2L2S4ipEc09ZXkeOk5NTDdmGGVqh POi6LOAC8zidOz6K8Q0St1yTvRU+BzRzyGH1Lhwoj7/8wUtXBObzO91+yyZFOpUlEmCvWEEoeyJ fY= X-Received: by 2002:a5d:4988:0:b0:48b:4c8:7b08 with SMTP id ffacd0b85a97d-48dbaae3a61mr9100131f8f.34.1791725280520; Sun, 11 Oct 2026 06:28:00 -0700 (PDT) Message-ID: Date: Sun, 11 Oct 2026 16:27:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 12/22] xen/arm: vsmmuv3: Add support for event queue and global error To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <1bf1f69e50fa7f6f90bfa6b2c7434c1ba3f65bbf.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <1bf1f69e50fa7f6f90bfa6b2c7434c1ba3f65bbf.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1791725281-F26B72AC-935A3263/0/0 X-purgate-type: clean X-purgate-size: 17405 On 10/7/26 03:07, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > Event queue is used to send the events to guest when there is an events/ > faults. Add support for event queue to send events to guest. > > Global error in SMMUv3 hw will be updated in smmu_gerror and > smmu_gerrorn register. Add support for global error registers to send > global error to guest. > > Add architectural error handling to the emulated command queue, > updating the global error register and stopping command consumption > on error. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/drivers/passthrough/arm/smmu-v3.h | 20 +++ > xen/drivers/passthrough/arm/vsmmu-v3.c | 233 +++++++++++++++++++++++-- > xen/include/public/arch-arm.h | 2 + > 3 files changed, 244 insertions(+), 11 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthrough/arm/smmu-v3.h > index 4a912be740..44ecb5d89c 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.h > +++ b/xen/drivers/passthrough/arm/smmu-v3.h > @@ -358,6 +358,26 @@ > > #define EVTQ_0_ID GENMASK_ULL(7, 0) > > +#define EVT_ID_BAD_STREAMID 0x02 > +#define EVT_ID_BAD_STE 0x04 > +#define EVT_ID_TRANSLATION_FAULT 0x10 > +#define EVT_ID_ADDR_SIZE_FAULT 0x11 > +#define EVT_ID_ACCESS_FAULT 0x12 > +#define EVT_ID_PERMISSION_FAULT 0x13 > + > +#define EVTQ_0_SSV (1UL << 11) > +#define EVTQ_0_SSID GENMASK_ULL(31, 12) > +#define EVTQ_0_SID GENMASK_ULL(63, 32) > +#define EVTQ_1_STAG GENMASK_ULL(15, 0) > +#define EVTQ_1_STALL (1UL << 31) > +#define EVTQ_1_PnU (1UL << 33) > +#define EVTQ_1_InD (1UL << 34) > +#define EVTQ_1_RnW (1UL << 35) > +#define EVTQ_1_S2 (1UL << 39) > +#define EVTQ_1_CLASS GENMASK_ULL(41, 40) > +#define EVTQ_1_TT_READ (1UL << 44) > +#define EVTQ_2_ADDR GENMASK_ULL(63, 0) > +#define EVTQ_3_IPA GENMASK_ULL(51, 12) > /* PRI queue */ > #define PRIQ_ENT_SZ_SHIFT 4 > #define PRIQ_ENT_DWORDS ((1 << PRIQ_ENT_SZ_SHIFT) >> 3) > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c > index 3f557d1c4d..87342fdf69 100644 > --- a/xen/drivers/passthrough/arm/vsmmu-v3.c > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c > @@ -85,6 +85,35 @@ > #define smmu_get_ste_s1ctxptr(x) FIELD_PREP(STRTAB_STE_0_S1CTXPTR_MASK, \ > FIELD_GET(STRTAB_STE_0_S1CTXPTR_MASK, x)) > > +/* event queue entry */ > +struct arm_smmu_evtq_ent { > + /* Common fields */ > + uint8_t opcode; > + uint32_t sid; > + > + /* Event-specific fields */ > + union { > + struct { > + uint32_t ssid; > + bool ssv; > + } c_bad_ste_streamid; > + > + struct { > + bool stall; > + uint16_t stag; > + uint32_t ssid; > + bool ssv; > + bool s2; > + uint64_t addr; > + bool rnw; > + bool pnu; > + bool ind; > + uint8_t class; > + uint64_t addr2; > + } f_translation; > + }; > +}; > + > /* stage-1 translation configuration */ > struct arm_vsmmu_s1_trans_cfg { > paddr_t s1ctxptr; > @@ -115,6 +144,7 @@ struct virt_smmu { > uint32_t strtab_base_cfg; > uint64_t strtab_base; > uint32_t irq_ctrl; > + uint32_t virq; > uint64_t gerror_irq_cfg0; > uint64_t evtq_irq_cfg0; > struct arm_vsmmu_queue evtq, cmdq; > @@ -160,9 +190,15 @@ static inline bool smmu_get_evtq_enabled(struct virt_smmu *smmu) > spin_unlock(&smmu->cr0_lock); > > return enabled; > -}; > +} > > /* Queue manipulation functions */ > +static bool queue_full(struct arm_vsmmu_queue *q) > +{ > + return Q_IDX(q, q->prod) == Q_IDX(q, q->cons) && > + Q_WRP(q, q->prod) != Q_WRP(q, q->cons); > +} > + > static bool queue_empty(struct arm_vsmmu_queue *q) > { > return Q_IDX(q, q->prod) == Q_IDX(q, q->cons) && > @@ -175,12 +211,133 @@ static void queue_inc_cons(struct arm_vsmmu_queue *q) > q->cons = Q_OVF(q->cons) | Q_WRP(q, cons) | Q_IDX(q, cons); > } > > +static void queue_inc_prod(struct arm_vsmmu_queue *q) > +{ > + u32 prod = (Q_WRP(q, q->prod) | Q_IDX(q, q->prod)) + 1; > + q->prod = Q_OVF(q->prod) | Q_WRP(q, prod) | Q_IDX(q, prod); > +} > + > static void dump_smmu_command(uint64_t *command) > { > gprintk(XENLOG_ERR, "cmd 0x%02llx: %016"PRIx64" %016"PRIx64"\n", > smmu_cmd_get_command(command[0]), command[0], command[1]); > } > > +static void arm_vsmmu_update_irq(struct virt_smmu *smmu) > +{ > + bool evt_pending = false; > + bool gerr_pending = false; > + uint32_t irq_ctrl; > + > + spin_lock(&smmu->irq_cfg_lock); > + irq_ctrl = smmu->irq_ctrl; > + spin_unlock(&smmu->irq_cfg_lock); > + > + spin_lock(&smmu->evt_queue_lock); > + evt_pending = !queue_empty(&smmu->evtq); > + spin_unlock(&smmu->evt_queue_lock); > + > + spin_lock(&smmu->gerror_lock); > + gerr_pending = (smmu->gerror ^ smmu->gerrorn) != 0; > + spin_unlock(&smmu->gerror_lock); > + > + vgic_inject_irq(smmu->d, NULL, smmu->virq, > + ((irq_ctrl & IRQ_CTRL_EVTQ_IRQEN) && evt_pending) || > + ((irq_ctrl & IRQ_CTRL_GERROR_IRQEN) && gerr_pending)); > +} > + > +static void arm_vsmmu_set_gerror(struct virt_smmu *smmu, uint32_t gerror_err) > +{ > + uint32_t pending, new_gerrors; > + > + spin_lock(&smmu->gerror_lock); > + > + pending = smmu->gerror ^ smmu->gerrorn; > + new_gerrors = ~pending & gerror_err; > + > + if ( new_gerrors ) > + smmu->gerror ^= new_gerrors; > + > + spin_unlock(&smmu->gerror_lock); > + > + arm_vsmmu_update_irq(smmu); > +} > + > +static int arm_vsmmu_write_evtq(struct virt_smmu *smmu, uint64_t *evt) > +{ > + struct arm_vsmmu_queue *q = &smmu->evtq; > + struct domain *d = smmu->d; > + paddr_t addr; > + int ret; > + > + if ( !smmu_get_evtq_enabled(smmu) ) > + return -EINVAL; If the queue is disabled, the event is simply discarded and nothing is wrong. Why do we then raise GERROR.EVTQ_ABT_ERR via arm_vsmmu_set_gerror()? > + > + spin_lock(&smmu->evt_queue_lock); > + > + if ( queue_full(q) ) > + { > + spin_unlock(&smmu->evt_queue_lock); > + return -EINVAL; This does not look like a global error either. From what I got from the SMMU spec (ARM IHI 0070/H.a 7.4 Event queue overflow), when the queue is full the event should be discarded and the overflow flag should be set in EVTQ_PROD. "The Event queue overflow condition is present when: SMMU_EVENTQ_PROD.OVFLG != SMMU_EVENTQ_CONS.OVACKFLG When an overflow occurs, the SMMU toggles the SMMU_EVENTQ_PROD.OVFLG flag if the overflow condition is not already present." Otherwise the guest might show a misleading message (an event queue memory-write error instead of an overflow). Or I really missed something? > + } > + > + addr = Q_PROD_ENT(q); > + > + ret = access_guest_memory_by_gpa(d, addr, evt, > + sizeof(*evt) * EVTQ_ENT_DWORDS, true); > + if ( ret ) > + { > + spin_unlock(&smmu->evt_queue_lock); > + return ret; > + } > + > + queue_inc_prod(q); > + > + spin_unlock(&smmu->evt_queue_lock); > + > + arm_vsmmu_update_irq(smmu); > + > + return 0; > +} > + > +static void arm_vsmmu_send_event(struct virt_smmu *smmu, > + struct arm_smmu_evtq_ent *ent) > +{ > + uint64_t evt[EVTQ_ENT_DWORDS]; > + int ret; > + > + memset(evt, 0, 1 << EVTQ_ENT_SZ_SHIFT); > + > + if ( !smmu_get_evtq_enabled(smmu) ) > + return; > + > + evt[0] |= FIELD_PREP(EVTQ_0_ID, ent->opcode); > + evt[0] |= FIELD_PREP(EVTQ_0_SID, ent->sid); > + > + switch ( ent->opcode ) > + { > + case EVT_ID_BAD_STREAMID: > + case EVT_ID_BAD_STE: > + evt[0] |= FIELD_PREP(EVTQ_0_SSID, ent->c_bad_ste_streamid.ssid); > + evt[0] |= FIELD_PREP(EVTQ_0_SSV, ent->c_bad_ste_streamid.ssv); > + break; > + case EVT_ID_TRANSLATION_FAULT: > + case EVT_ID_ADDR_SIZE_FAULT: > + case EVT_ID_ACCESS_FAULT: > + case EVT_ID_PERMISSION_FAULT: > + break; > + default: > + gdprintk(XENLOG_WARNING, "vSMMUv3: event opcode is bad\n"); > + break; > + } > + > + ret = arm_vsmmu_write_evtq(smmu, evt); > + if ( ret ) > + arm_vsmmu_set_gerror(smmu, GERROR_EVTQ_ABT_ERR); > + > + return; > +} > + > static int arm_vsmmu_find_ste(struct virt_smmu *smmu, uint32_t sid, > uint64_t *ste) > { > @@ -189,6 +346,14 @@ static int arm_vsmmu_find_ste(struct virt_smmu *smmu, uint32_t sid, > uint32_t log2size; > int strtab_size_shift; > int ret; > + struct arm_smmu_evtq_ent ent = { > + .opcode = EVT_ID_BAD_STREAMID, > + .sid = sid, > + .c_bad_ste_streamid = { > + .ssid = 0, > + .ssv = false, > + }, > + }; > > spin_lock(&smmu->strtab_cfg_lock); > log2size = MIN(FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, smmu->strtab_base_cfg), > @@ -196,7 +361,10 @@ static int arm_vsmmu_find_ste(struct virt_smmu *smmu, uint32_t sid, > spin_unlock(&smmu->strtab_cfg_lock); > > if ( sid >= (1U << log2size) ) > + { > + arm_vsmmu_send_event(smmu, &ent); > return -EINVAL; > + } > > spin_lock(&smmu->strtab_cfg_lock); > if ( FIELD_GET(STRTAB_BASE_CFG_FMT, smmu->strtab_base_cfg) == > @@ -249,6 +417,7 @@ static int arm_vsmmu_find_ste(struct virt_smmu *smmu, uint32_t sid, > { > gdprintk(XENLOG_ERR, "idx=%d > max_l2_ste=%d\n", > idx, max_l2_ste); > + arm_vsmmu_send_event(smmu, &ent); > return -EINVAL; > } > addr = l2ptr + idx * sizeof(*ste) * STRTAB_STE_DWORDS; > @@ -277,6 +446,14 @@ static int arm_vsmmu_decode_ste(struct virt_smmu *smmu, uint32_t sid, > uint64_t *ste) > { > uint64_t val = ste[0]; > + struct arm_smmu_evtq_ent ent = { > + .opcode = EVT_ID_BAD_STE, > + .sid = sid, > + .c_bad_ste_streamid = { > + .ssid = 0, > + .ssv = false, > + }, > + }; > > if ( !(val & STRTAB_STE_0_V) ) > return -EAGAIN; > @@ -312,6 +489,7 @@ static int arm_vsmmu_decode_ste(struct virt_smmu *smmu, uint32_t sid, > return 0; > > bad_ste: > + arm_vsmmu_send_event(smmu, &ent); > return -EINVAL; > } > > @@ -362,16 +540,19 @@ static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) > if ( !smmu_get_cmdq_enabled(smmu) ) > return 0; > > - while ( !queue_empty(q) ) > + while ( !queue_empty(q) && > + ((smmu->gerror ^ smmu->gerrorn) & (GERROR_CMDQ_ERR)) == 0 ) > { > - int ret; > - > addr = Q_CONS_ENT(q); > ret = access_guest_memory_by_gpa(d, addr, command, > sizeof(command), false); > - if ( ret ) { > - queue_inc_cons(q); > - return ret; > + if ( ret ) > + { > + smmu->cmdq.cons &= ~CMDQ_CONS_ERR; > + smmu->cmdq.cons |= FIELD_PREP(CMDQ_CONS_ERR, > + CMDQ_ERR_CERROR_ABT_IDX); > + arm_vsmmu_set_gerror(smmu, GERROR_CMDQ_ERR); > + break; > } > > switch ( smmu_cmd_get_command(command[0]) ) > @@ -395,6 +576,10 @@ static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) > default: > gdprintk(XENLOG_ERR, "vSMMUv3: unhandled command\n"); > dump_smmu_command(command); > + smmu->cmdq.cons &= ~CMDQ_CONS_ERR; > + smmu->cmdq.cons |= FIELD_PREP(CMDQ_CONS_ERR, > + CMDQ_ERR_CERROR_ILL_IDX); > + arm_vsmmu_set_gerror(smmu, GERROR_CMDQ_ERR); > break; > } > > @@ -405,6 +590,15 @@ static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) > ret); > dump_smmu_command(command); > } > + > + /* > + * Stop consuming the command queue if a command error occurred. > + * CMDQ_CONS continues to point at the offending command until the > + * error is acknowledged. > + */ > + if ( (smmu->gerror ^ smmu->gerrorn) & GERROR_CMDQ_ERR ) > + break; > + > queue_inc_cons(q); > } > > @@ -443,6 +637,7 @@ static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, > vreg_reg32_update(®32, r, info); > smmu->evtq.cons = reg32; > spin_unlock(&smmu->evt_queue_lock); > + arm_vsmmu_update_irq(smmu); > break; > default: > printk(XENLOG_G_ERR > @@ -573,6 +768,7 @@ static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, > vreg_reg32_update(®32, r, info); > smmu->irq_ctrl = reg32; > spin_unlock(&smmu->irq_cfg_lock); > + arm_vsmmu_update_irq(smmu); > break; > > case VREG64(ARM_SMMU_GERROR_IRQ_CFG0): > @@ -602,6 +798,10 @@ static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, > vreg_reg32_update(®32, r, info); > smmu->gerrorn = reg32; > spin_unlock(&smmu->gerror_lock); > + arm_vsmmu_update_irq(smmu); > + spin_lock(&smmu->cmd_queue_lock); > + arm_vsmmu_handle_cmds(smmu); > + spin_unlock(&smmu->cmd_queue_lock); > break; > > default: > @@ -905,9 +1105,10 @@ static const struct mmio_handler_ops vsmmuv3_mmio_handler = { > .write = vsmmuv3_mmio_write, > }; > > -static int vsmmuv3_init_single(struct domain *d, paddr_t addr, paddr_t size, > - uint32_t features) > +static int vsmmuv3_init_single(struct domain *d, paddr_t addr, > + paddr_t size, uint32_t virq, uint32_t features) > { > + int ret; > struct virt_smmu *smmu; > > smmu = xzalloc(struct virt_smmu); > @@ -916,6 +1117,7 @@ static int vsmmuv3_init_single(struct domain *d, paddr_t addr, paddr_t size, > > smmu->d = d; > smmu->features = features; > + smmu->virq = virq; > smmu->cmdq.ent_size = CMDQ_ENT_DWORDS * DWORDS_BYTES; > smmu->evtq.ent_size = EVTQ_ENT_DWORDS * DWORDS_BYTES; > > @@ -928,6 +1130,15 @@ static int vsmmuv3_init_single(struct domain *d, paddr_t addr, paddr_t size, > spin_lock_init(&smmu->strtab_cfg_lock); > spin_lock_init(&smmu->irq_cfg_lock); > > + ret = vgic_reserve_virq(d, virq); > + if ( !ret ) > + { > + printk(XENLOG_G_ERR > + "vSMMUv3: Failed to reserve domain vIRQ %u\n", virq); > + xfree(smmu); > + return -EINVAL; > + } > + > register_mmio_handler(d, &vsmmuv3_mmio_handler, addr, size, smmu); > > /* Register the vIOMMU to be able to clean it up later. */ > @@ -953,7 +1164,7 @@ static int domain_vsmmuv3_init(struct domain *d) > { > smmu = (const struct arm_smmu_device *) hw_iommu->iommu; > ret = vsmmuv3_init_single(d, hw_iommu->addr, hw_iommu->size, > - smmu->features); > + hw_iommu->irq, smmu->features); > if ( ret ) > return ret; > } > @@ -983,7 +1194,7 @@ static int domain_vsmmuv3_init(struct domain *d) > } > > ret = vsmmuv3_init_single(d, GUEST_VSMMUV3_BASE, GUEST_VSMMUV3_SIZE, > - features); > + GUEST_VSMMU_SPI, features); > if ( ret ) > return ret; > } > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index 8863e2e457..c43b8b7b71 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -538,6 +538,8 @@ typedef uint64_t xen_callback_t; > #define GUEST_VIRTIO_MMIO_SPI_FIRST 33 > #define GUEST_VIRTIO_MMIO_SPI_LAST 43 > > +#define GUEST_VSMMU_SPI 44 So this is the same emulated SPI as the one used for vPL011. You likely need to update d_cfg->arch.nr_spis if vSMMU is enabled for the domain, to ensure that we allocate enough SPIs for it (refer to arch_parse_dom0less_node(), when "nr_spis" is not explicitly specified we update nr_spis if vPL011 is requested). Moreover, you already do this in libxl. > + > /* > * SGI is the preferred delivery mechanism of FF-A pending notifications or > * schedule recveive interrupt. SGIs 8-15 are normally not used by a guest From xen-devel-bounces@lists.xenproject.org Sun Oct 11 14:06:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Oct 2026 14:06:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445598.1661651 (Exim 4.92) (envelope-from ) id 1xFuCO-0004CX-G3; Sun, 11 Oct 2026 14:06:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445598.1661651; Sun, 11 Oct 2026 14:06: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 1xFuCO-0004CQ-DE; Sun, 11 Oct 2026 14:06:48 +0000 Received: by outflank-mailman (input) for mailman id 1445598; Sun, 11 Oct 2026 14:06:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFuCN-0004CK-A8 for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 14:06:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFuCK-009C9C-1p for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 16:06:44 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acb97cb-e002-0a2a0a5209dd-0a2a4508bdb2-40 for ; Sun, 11 Oct 2026 16:06:44 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acb97f3-f659-0a2a45080019-d1558031f1fd-3 for ; Sun, 11 Oct 2026 16:06:43 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a140e7405dso13644225e9.3 for ; Sun, 11 Oct 2026 07:06:43 -0700 (PDT) Received: from [192.168.0.114] ([91.123.150.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18e4225f4sm276043415e9.0.2026.10.11.07.06.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Oct 2026 07:06: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=1791727603; x=1792332403; 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=oNP0IY6tQpS+QuFI40+y6YIPkQ3x50tKOZJ+SbSc1zI=; b=VJGqWsrFL8lCXA4hOpQ9CGlqJ95axnsx8Cxr6L+6Qj0jn9/QyeNF5VLaZa6RelUl57 BdFmr9Q+dLDcaxQtIaWMlnP2p1ke4UVbdTF0hu2+s4YzdgoFvdp0rgB3ld4xY6JgzUOP x6T+hDCqP4ERjOxo4Ge/i+9pFRGW5uEVVgBIC5dpXdVo7mLeDJbCL25EcZ+nYXXUw05S jvPoxnQP2yq5fhcxnDOd0mtNSzpfk3rb64MaJRp4foSag+rVdmjz9cVdnPWPD5VFiMZT xyKfoBij1gAO1Oi35aAgkLT2J/dbVqE0pspgCe50tD5/mn0ex7Ty4YYrHTKYHbZvl7jp Ba0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791727603; x=1792332403; 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=oNP0IY6tQpS+QuFI40+y6YIPkQ3x50tKOZJ+SbSc1zI=; b=BQgJvNe4UvbE1smG3LCuC4R8gDSJZ0wscLg4GCSNOAfhaXIk5pWVfuooLo785snTp4 OHRrOOkPZ/w5rA6rrXhaxdAN200rmbAkRMb2zeoASC/HuH7j0IDsi7COvrfxNW8BrqeX 5DU4l3nvV0SCAeGrIdtKrqiRT81+QXzbnro5uclwHPpTpDDlQ//e1YnBc/IJvGq8iFbF jj43aEW+3u0fv8kaaFxZKtFPX1YAOYdoIZ6nNczsryP7qlaFm2ZHCa4OD2fRaGWQ8sYL Oijrnf6pOfU8ltc8OnDb8z4viHKEtAzo9lx27RPbhybyddVwg4lfLtctrRNqv73cgQIB M7lA== X-Forwarded-Encrypted: i=1; AKwUvByU+tKlq9/mHABwR0jXYpKoFhyi7gBf9uxSiMtJP0b7XvWWubMbM7NH2swe2wBQUa2hxGmnnW/Ts7Q=@lists.xenproject.org X-Gm-Message-State: AFq9FYKVAuKA8abE0TmuIUNMRUvfJYAqxUb02hDbo+U6IM4/g3TgOuQt 4sTFzlM2UxQ/1BsAqxOcOqpa3WapYG2MVOA/4hrTfZXDrlxSrfu+ILIe X-Gm-Gg: AYBFou2UWhQNXRE5B7V9T29EOHNSs+7elEUsikNoPGOmvJ7UZJoV3L7Jbk9yA+fSj+t NZoyv7qR63yOUtBj+WWfOd29QzWKOvdwxh+FqJhiGwhOxOJdUjMz/VnPZ+tX05pUab+Y9AemBIx LyJ1G3cW74V4tvf/h6YaOrBeD1phtKkwb3APncKZpQiclRJzFc9CGUFwbv1/iCrAEWZ4aFzCoDw N02ASIYFs68vl7v7L+/6YD9ve/tpGqsrIY5Y9ZKDttIGTxoqZ2FdEfzRLlGktfPYV4rtu9tkLx5 Vl6lmw0u8GNBvoAZ0Z1UoQadpCnq1e3UBJPxvYTRlmheLChPYKFbJFoHuAe12SGsFKNOj0VbGy6 wRcKZlBUmwX3C/gpeHX3Sg9a4fxRJwJEZT8QkpB/Hvlffwxt6egPJo1AaUxls4MbQBmVnVgLzHf 5MN+SVihaIyeI9AvA9NaDKfjpNnkPIfVpi8bY5UusHe97d1ltGiyp7i2YR/o6b3B1WzDRG+0L5P f8= X-Received: by 2002:a05:600c:34cd:b0:4a1:7163:3e41 with SMTP id 5b1f17b1804b1-4a18e49885emr122869345e9.9.1791727603214; Sun, 11 Oct 2026 07:06:43 -0700 (PDT) Message-ID: Date: Sun, 11 Oct 2026 17:06:39 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 05/22] xen/arm: vsmmuv3: Add dummy support for virtual SMMUv3 for guests To: Milan Djokic , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <2094abe1b6faba477e771390bf47921f80e7e0e7.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <2094abe1b6faba477e771390bf47921f80e7e0e7.1791328190.git.milan_djokic@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1791727603-DFCD387B-4311AC05/0/0 X-purgate-type: clean X-purgate-size: 16438 On 10/7/26 03:06, Milan Djokic wrote: Hello Milan > From: Rahul Singh > > domain_viommu_init() will be called during domain creation and will add > the dummy trap handler for virtual IOMMUs for guests. > > A host IOMMU list will be created when host IOMMU devices are probed > and this list will be used to create the IOMMU device tree node for > dom0. For dom0, 1-1 mapping will be established between vIOMMU in dom0 > and physical IOMMU. > > For domUs, the 1-N mapping will be established between domU and physical > IOMMUs. A new area has been reserved in the arm guest physical map at > which the emulated vIOMMU node is created in the device tree. > > Also set the vIOMMU type to vSMMUv3 to enable vIOMMU framework to call > vSMMUv3 domain creation/destroy functions. > > Signed-off-by: Rahul Singh > Signed-off-by: Milan Djokic > --- > xen/arch/arm/domain.c | 6 +- > xen/arch/arm/include/asm/domain.h | 5 ++ > xen/arch/arm/include/asm/viommu.h | 36 ++++++++ > xen/drivers/passthrough/Kconfig | 8 ++ > xen/drivers/passthrough/arm/Makefile | 1 + > xen/drivers/passthrough/arm/smmu-v3.c | 7 ++ > xen/drivers/passthrough/arm/viommu.c | 83 ++++++++++++++++- > xen/drivers/passthrough/arm/vsmmu-v3.c | 118 +++++++++++++++++++++++++ > xen/drivers/passthrough/arm/vsmmu-v3.h | 20 +++++ > xen/include/public/arch-arm.h | 5 ++ > 10 files changed, 287 insertions(+), 2 deletions(-) > create mode 100644 xen/drivers/passthrough/arm/vsmmu-v3.c > create mode 100644 xen/drivers/passthrough/arm/vsmmu-v3.h > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 5c411a2310..003a8d45b9 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -672,7 +672,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > return -EINVAL; > } > > - if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) > + if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE && > + config->arch.viommu_type != viommu_get_type() ) > { > dprintk(XENLOG_INFO, > "vIOMMU type requested not supported by the platform or Xen\n"); > @@ -728,6 +729,9 @@ int arch_domain_create(struct domain *d, > > count += domain_vpci_get_num_mmio_handlers(d); > > + if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) > + count += domain_viommu_get_num_mmio_handlers(d); > + > if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 ) > goto fail; > > diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h > index c3d2c4981f..70af0bf8b7 100644 > --- a/xen/arch/arm/include/asm/domain.h > +++ b/xen/arch/arm/include/asm/domain.h > @@ -102,6 +102,11 @@ struct arch_domain > #ifdef CONFIG_MPU > uint8_t v8r_el1_msa; > #endif > + > +#ifdef CONFIG_ARM_VIRTUAL_IOMMU > + struct list_head viommu_list; /* List of virtual IOMMUs */ > +#endif > + > } __cacheline_aligned; > > struct arch_vcpu > diff --git a/xen/arch/arm/include/asm/viommu.h b/xen/arch/arm/include/asm/viommu.h > index 95f82d9cf5..287595068b 100644 > --- a/xen/arch/arm/include/asm/viommu.h > +++ b/xen/arch/arm/include/asm/viommu.h > @@ -3,9 +3,23 @@ > #define __ARCH_ARM_VIOMMU_H__ > > #include > +#include > #include > #include > > +/* data structure for each hardware IOMMU */ > +struct host_iommu { > + struct list_head entry; > + /* IOMMU DT node used to establish virtual to physical IOMMU/SID mapping */ > + const struct dt_device_node *dt_node; > + /* Used for dom0 vIOMMU instantiation (1-1 MMIO regions mappings) */ > + paddr_t addr; > + /* Used for dom0 vIOMMU instantiation (1-1 MMIO regions mappings) */ > + paddr_t size; > + /* Used for dom0 EVTQ and GERROR interrupts (1-1 IRQ mapping) */ > + uint32_t irq; > +}; > + > struct viommu_ops { > /* > * Called during domain construction if toolstack requests to enable > @@ -32,9 +46,15 @@ struct viommu_desc { > > #ifdef CONFIG_ARM_VIRTUAL_IOMMU > > +extern struct list_head host_iommu_list; > + > int domain_viommu_init(struct domain *d, uint8_t viommu_type); > int viommu_relinquish_resources(struct domain *d); > uint8_t viommu_get_type(void); > +void add_to_host_iommu_list(paddr_t addr, paddr_t size, > + const struct dt_device_node *node); > +void set_cur_viommu(const struct viommu_desc *desc); > +unsigned int domain_viommu_get_num_mmio_handlers(struct domain *d); > > #else > > @@ -56,6 +76,22 @@ static inline int viommu_relinquish_resources(struct domain *d) > return 0; > } > > +static inline void __init add_to_host_iommu_list(paddr_t addr, paddr_t size, > + const struct dt_device_node *node) > +{ > + return; > +} > + > +static inline unsigned int domain_viommu_get_num_mmio_handlers(struct domain *d) > +{ > + return 0; > +} > + > +static inline void __init set_cur_viommu(const struct viommu_desc *desc) > +{ > + return; > +} > + > #endif /* CONFIG_ARM_VIRTUAL_IOMMU */ > > #endif /* __ARCH_ARM_VIOMMU_H__ */ > diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig > index a92cfbea98..40d072822f 100644 > --- a/xen/drivers/passthrough/Kconfig > +++ b/xen/drivers/passthrough/Kconfig > @@ -40,6 +40,14 @@ config ARM_VIRTUAL_IOMMU > help > Support virtual IOMMU infrastructure to implement vIOMMU. > > +config VIRTUAL_ARM_SMMU_V3 > + bool "ARM Ltd. Virtual SMMUv3 Support (UNSUPPORTED)" > + depends on ARM_SMMU_V3 && ARM_VIRTUAL_IOMMU > + help > + Support for implementations of the virtual ARM System MMU architecture > + version 3. Virtual SMMUv3 is unsupported feature and should not be used > + in production. > + > endif > > config AMD_IOMMU > diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile > index c3783188e3..c8f0a5f802 100644 > --- a/xen/drivers/passthrough/arm/Makefile > +++ b/xen/drivers/passthrough/arm/Makefile > @@ -3,3 +3,4 @@ obj-$(CONFIG_ARM_SMMU) += smmu.o > obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o > obj-$(CONFIG_ARM_SMMU_V3) += smmu-v3.o > obj-$(CONFIG_ARM_VIRTUAL_IOMMU) += viommu.o > +obj-$(CONFIG_VIRTUAL_ARM_SMMU_V3) += vsmmu-v3.o > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index bd0689664b..21b82eba85 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -93,6 +93,7 @@ > #include > > #include "smmu-v3.h" > +#include "vsmmu-v3.h" > > #define ARM_SMMU_VTCR_SH_IS 3 > #define ARM_SMMU_VTCR_RGN_WBWA 1 > @@ -2829,6 +2830,9 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev) > list_add(&smmu->devices, &arm_smmu_devices); > spin_unlock(&arm_smmu_devices_lock); > > + /* Add to host IOMMU list to initialize vIOMMU for dom0 */ > + add_to_host_iommu_list(ioaddr, iosize, dev_to_dt(pdev)); > + > return 0; > > > @@ -3181,6 +3185,9 @@ static __init int arm_smmu_dt_init(struct dt_device_node *dev, > > platform_features &= smmu->features; > > + /* Set vIOMMU type to SMMUv3 */ > + vsmmuv3_set_type(); > + > return 0; > } > > diff --git a/xen/drivers/passthrough/arm/viommu.c b/xen/drivers/passthrough/arm/viommu.c > index 0c0efd668e..3401e4f7d9 100644 > --- a/xen/drivers/passthrough/arm/viommu.c > +++ b/xen/drivers/passthrough/arm/viommu.c > @@ -2,12 +2,54 @@ > > #include > #include > +#include > #include > +#include > > #include > > +/* List of all host IOMMUs */ > +LIST_HEAD(host_iommu_list); > + > /* Struct to hold the vIOMMU ops and vIOMMU type */ > static const struct viommu_desc __ro_after_init *cur_viommu; > +static bool host_iommu_list_incomplete; > + > +/* Common function for adding to host_iommu_list */ > +void __init add_to_host_iommu_list(paddr_t addr, paddr_t size, > + const struct dt_device_node *node) > +{ > + struct host_iommu *iommu_data; > + int irq; > + > + iommu_data = xzalloc(struct host_iommu); > + if ( !iommu_data ) > + { > + host_iommu_list_incomplete = true; > + printk(XENLOG_WARNING > + "vIOMMU: Cannot allocate memory for host IOMMU data\n"); > + return; > + } > + > + iommu_data->addr = addr; > + iommu_data->size = size; > + iommu_data->dt_node = node; > + irq = platform_get_irq(node, 0); > + if ( irq < 0 ) > + { > + host_iommu_list_incomplete = true; > + printk(XENLOG_WARNING > + "vIOMMU: disabling support because IOMMU @0x%"PRIx64 > + " has no usable IRQ (%d)\n", addr, irq); > + xfree(iommu_data); > + return; > + } > + iommu_data->irq = irq; > + > + printk("vIOMMU: Found IOMMU @0x%"PRIx64"\n", addr); > + > + list_add_tail(&iommu_data->entry, &host_iommu_list); > +} > > int domain_viommu_init(struct domain *d, uint8_t viommu_type) > { > @@ -33,12 +75,51 @@ int viommu_relinquish_resources(struct domain *d) > > uint8_t viommu_get_type(void) > { > - if ( !cur_viommu ) > + if ( !cur_viommu || host_iommu_list_incomplete || > + list_empty(&host_iommu_list) ) > return XEN_DOMCTL_CONFIG_VIOMMU_NONE; > > return cur_viommu->viommu_type; > } > > +void __init set_cur_viommu(const struct viommu_desc *desc) > +{ > + if ( cur_viommu && (cur_viommu != desc) ) > + { > + printk("WARNING: Cannot set vIOMMU, already set to a different value\n"); > + return; > + } > + > + cur_viommu = desc; > +} > + > +unsigned int domain_viommu_get_num_mmio_handlers(struct domain *d) > +{ > + if ( is_hardware_domain(d) ) > + { > + struct host_iommu *hw_iommu; > + int count = 0; > + > + /* > + * For hardware domain, vIOMMU per pIOMMU is exposed. Number of > + * regions required for the configuration space is equal to number of > + * host IOMMUs. > + */ > + list_for_each_entry(hw_iommu, &host_iommu_list, entry) > + { > + count++; > + } > + > + return count; > + } > + > + /* > + * For unpriviliged domains, single vIOMMU is exposed and requires one > + * region to cover the configuration space. > + */ > + return 1; > +} > + > /* > * Local variables: > * mode: C > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c > new file mode 100644 > index 0000000000..ea3b5bb34d > --- /dev/null > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c > @@ -0,0 +1,118 @@ > +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ > + > +#include > +#include > +#include > +#include > + > +struct virt_smmu { > + struct domain *d; > + struct list_head viommu_list; > +}; > + > +static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, > + register_t r, void *priv) > +{ > + BUG_ON("unimplemented"); > + return IO_HANDLED; > +} > + > +static int vsmmuv3_mmio_read(struct vcpu *v, mmio_info_t *info, > + register_t *r, void *priv) > +{ > + BUG_ON("unimplemented"); > + return IO_HANDLED; > +} > + > +static const struct mmio_handler_ops vsmmuv3_mmio_handler = { > + .read = vsmmuv3_mmio_read, > + .write = vsmmuv3_mmio_write, > +}; > + > +static int vsmmuv3_init_single(struct domain *d, paddr_t addr, paddr_t size) > +{ > + struct virt_smmu *smmu; > + > + smmu = xzalloc(struct virt_smmu); > + if ( !smmu ) > + return -ENOMEM; > + > + smmu->d = d; > + > + register_mmio_handler(d, &vsmmuv3_mmio_handler, addr, size, smmu); > + > + /* Register the vIOMMU to be able to clean it up later. */ > + list_add_tail(&smmu->viommu_list, &d->arch.viommu_list); > + > + return 0; > +} > + > +static int domain_vsmmuv3_init(struct domain *d) > +{ > + int ret; > + > + INIT_LIST_HEAD(&d->arch.viommu_list); > + > + if ( is_hardware_domain(d) ) Looking over other device emulations in Xen (vpl011, vgic, etc.), I see that the host (hardware) MMIO range is also exposed to direct-mapped domains, as there might be a non-hwdom 1:1 domain. Xen even has a specific macro for that: domain_use_host_layout. Here, however, the guest MMIO range will be exposed to a regular direct-mapped domain. Is there a specific reason for that (is this intentional)? > + { > + struct host_iommu *hw_iommu; > + > + list_for_each_entry(hw_iommu, &host_iommu_list, entry) > + { > + ret = vsmmuv3_init_single(d, hw_iommu->addr, hw_iommu->size); > + if ( ret ) > + return ret; > + } > + } > + else > + { > + ret = vsmmuv3_init_single(d, GUEST_VSMMUV3_BASE, GUEST_VSMMUV3_SIZE); > + if ( ret ) > + return ret; > + } > + > + return 0; > +} > + > +static int vsmmuv3_relinquish_resources(struct domain *d) > +{ > + struct virt_smmu *pos, *temp; > + > + /* Cope with uninitialized vIOMMU */ > + if ( list_head_is_null(&d->arch.viommu_list) ) > + return 0; > + > + list_for_each_entry_safe(pos, temp, &d->arch.viommu_list, viommu_list ) > + { > + list_del(&pos->viommu_list); > + xfree(pos); > + } > + > + return 0; > +} > + > +static const struct viommu_ops vsmmuv3_ops = { > + .domain_init = domain_vsmmuv3_init, > + .relinquish_resources = vsmmuv3_relinquish_resources, > +}; > + > +static const struct viommu_desc vsmmuv3_desc = { > + .ops = &vsmmuv3_ops, > + .viommu_type = XEN_DOMCTL_CONFIG_VIOMMU_SMMUV3, > +}; > + > +void __init vsmmuv3_set_type(void) > +{ > + const struct viommu_desc *desc = &vsmmuv3_desc; > + > + set_cur_viommu(desc); > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.h b/xen/drivers/passthrough/arm/vsmmu-v3.h > new file mode 100644 > index 0000000000..9f4c86abd5 > --- /dev/null > +++ b/xen/drivers/passthrough/arm/vsmmu-v3.h > @@ -0,0 +1,20 @@ > +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ > +#ifndef __ARCH_ARM_VSMMU_V3_H__ > +#define __ARCH_ARM_VSMMU_V3_H__ > + > +#include > + > +#ifdef CONFIG_VIRTUAL_ARM_SMMU_V3 > + > +void vsmmuv3_set_type(void); > + > +#else > + > +static inline void __init vsmmuv3_set_type(void) > +{ > + return; > +} > + > +#endif /* CONFIG_VIRTUAL_ARM_SMMU_V3 */ > + > +#endif /* __ARCH_ARM_VSMMU_V3_H__ */ > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index a1491f9cf7..8863e2e457 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -335,6 +335,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA 2 > > #define XEN_DOMCTL_CONFIG_VIOMMU_NONE 0 > +#define XEN_DOMCTL_CONFIG_VIOMMU_SMMUV3 1 > > struct xen_arch_domainconfig { > /* IN/OUT */ > @@ -463,6 +464,10 @@ typedef uint64_t xen_callback_t; > #define GUEST_GICV3_GICR0_BASE xen_mk_ullong(0x03020000) /* vCPU0..127 */ > #define GUEST_GICV3_GICR0_SIZE xen_mk_ullong(0x01000000) > > +/* vsmmuv3 MMIO mappings */ > +#define GUEST_VSMMUV3_BASE xen_mk_ullong(0x04040000) > +#define GUEST_VSMMUV3_SIZE xen_mk_ullong(0x00020000) > + > /* > * 256 MB is reserved for VPCI configuration space based on calculation > * 256 buses x 32 devices x 8 functions x 4 KB = 256 MB From xen-devel-bounces@lists.xenproject.org Sun Oct 11 15:16:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Oct 2026 15:16:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445626.1661660 (Exim 4.92) (envelope-from ) id 1xFvHY-0005nB-CI; Sun, 11 Oct 2026 15:16:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445626.1661660; Sun, 11 Oct 2026 15:16: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 1xFvHY-0005n2-8u; Sun, 11 Oct 2026 15:16:12 +0000 Received: by outflank-mailman (input) for mailman id 1445626; Sun, 11 Oct 2026 15:16:10 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFvHW-0005mu-J4 for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 15:16:10 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xFvHW-000000007d7-04i7; Sun, 11 Oct 2026 15:16:09 +0000 Received: from [2a02:8012:3a1:0:94b1:aa8d:8098:b789] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xFvHS-00000000I5D-2QvK; Sun, 11 Oct 2026 15:16: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=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=4vLAabyXUF+p1z3Sk2EwmJMzDuyIAWDYxx95hcnUxRk=; b=htp/H6G1qOBJ9rFlGqggGBSmM6 /jdAMuEJhBjfICdtvO2t/OE0e9mJ6Llm7juM1y8H5LNSFLl7ms5Pg85JqKxXs/3fQe+0TaBhgBUAv 7s7GV7OfKzRs1iF/hYgc0CZoSJKlBKNmpsV7YtpNfJDeiEMF6s8DT7822cRZfGCWSl1k=; Message-ID: <0304e375-ddbf-4760-b61c-3c563e67416d@xen.org> Date: Sun, 11 Oct 2026 16:16:03 +0100 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> <1da5f563-9fb3-4043-b13e-fa7a4f390911@oracle.com> Content-Language: en-GB From: Julien Grall In-Reply-To: <1da5f563-9fb3-4043-b13e-fa7a4f390911@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 18/09/2026 22:23, Jan Setje-Eilers wrote: > On 9/17/26 04:06, Grall, Julien wrote: >> 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. Thanks for clarification. I would have though most of such HW are pretty much gone :). I am not entirely sure what's the best way forward for HW not supporting FEAT_FWB. With your approach, I am concerned we may be missing some cases after boot, so we could potentially skip the flush if the pages have not been touched for Xen (you said the pages are not scrubbed for static memory). I'd like some opinions from Bertrand, Michal and Stefano on this. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Oct 12 06:01:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 06:01:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445827.1661669 (Exim 4.92) (envelope-from ) id 1xG95x-0007pe-HH; Mon, 12 Oct 2026 06:01:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445827.1661669; Mon, 12 Oct 2026 06:01: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 1xG95x-0007pV-Bq; Mon, 12 Oct 2026 06:01:09 +0000 Received: by outflank-mailman (input) for mailman id 1445827; Mon, 12 Oct 2026 06:01:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xG95w-0007pN-DN for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 06:01:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xG95u-00AhKf-Ko for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:01:06 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc779f-8faa-0a2a0a5109dd-0a2a4509be46-4 for ; Mon, 12 Oct 2026 08:01:06 +0200 Received: from [40.107.209.28] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc77a0-be1a-0a2a45090019-286bd11c6cf9-3 for ; Mon, 12 Oct 2026 08:01:05 +0200 Received: from BN0PR04CA0020.namprd04.prod.outlook.com (2603:10b6:408:ee::25) by DM4PR12MB5915.namprd12.prod.outlook.com (2603:10b6:8:68::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.17; Mon, 12 Oct 2026 06:00:50 +0000 Received: from BL2PEPF000352CE.namprd02.prod.outlook.com (2603:10b6:408:ee:cafe::4d) by BN0PR04CA0020.outlook.office365.com (2603:10b6:408:ee::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.15 via Frontend Transport; Mon, 12 Oct 2026 06:00:50 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL2PEPF000352CE.mail.protection.outlook.com (10.167.249.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 12 Oct 2026 06:00:50 +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.53; Mon, 12 Oct 2026 01:00:44 -0500 Received: from [10.136.45.168] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 12 Oct 2026 01:00: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=YdndVQv7Pp/pjB5WZW1ATFwHqVZf7bIhmQY5jsohIhPKQK7sZtLw8qPP40XcUUs6lk1v3PEIQ2bmmmsNavAlf/5BlhXEdQ9l2ZUm+jA900TSAkAHW+aCzoaeQta+OOKqdCKNuhykMSzTkqk+k7jklOZVBKVYgYQjbaAtCA7pFausMrbujP9/PcNo4QMY/DKaz7FW+TxGGAgJmqJyjcEKdmdkX3G/1HZTWG08SKnhDVM4ziQGTYo8GKAyj3awAVe4zffhDquOkOWT60KfyvTTAjq4jKxA5xVdQb5/XQq66fAmXAVylf4BYN2POrL2IR+z4zNslAiX8JKow2ji1He7rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7Smck2Bpq2BqceuhanfQ8/7aHT50jGp8guUJfZ5IM5M=; b=LDvY6hp+Ap5qA+w75mmWJGWvnibPSCwJtgFM3FbeIIPWnicycJ+H8vDuPvxLVnbqsqtkePLJ/7TED/Bdyzo0XDOY+Ao5siob7w6+YVWjqLBVHNHNHC89o/71QRDPKadlgLHP235IntuKPI2Mu71pWt9UdGUAeLkk4vtPNQtZFw9xp4/0scjf27iuBOU3Uo0oawz0iU3gz/ql4IPFY3HgL9wa2MForacGndCb1q/y12LSgOdrRAoPTtWNrsYp8emOlEko5wviW2r1TCpKhWArIOaIytL/1ZkPhbNznHufevgNX1EDPA58HEr2O+cQiVoXGyyV/U+hTribXz/I3VkPJg== 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=7Smck2Bpq2BqceuhanfQ8/7aHT50jGp8guUJfZ5IM5M=; b=REvgliFe6xqeGmJaHQpBPQkuDcwnC+71UR0LQltJw4zmcdi+ul5Edno40nCS2b8kCnBCy2MdkkhnLagyiHXQoz4nJNO+GH9rrb5HIxUjIgeXsOoxFvc3Qdv8Y4HYw1atKJLnaq8aU2EfwdemOoFyUWu4kNwujEiK3uPZ1l0PgJo= 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, 12 Oct 2026 11:30:15 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 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 , 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" , 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" , Zhongqiu Han References: <20261008071839.2247074-1-jgross@suse.com> <20261008071839.2247074-13-jgross@suse.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20261008071839.2247074-13-jgross@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL2PEPF000352CE:EE_|DM4PR12MB5915:EE_ X-MS-Office365-Filtering-Correlation-Id: 7cfeebe3-ee41-47b1-9a45-08df28262b02 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|32650700020|82310400026|23010399003|1800799024|376014|36860700016|7416014|18002099003|10067099003|22082099003|921020|4143699003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: iF/4vsFZ0oCxke5nY+IzxcsajSzz5fPHlKfX0Y7e1Yx6IxBZC2sr3ME/4gk3EsXUGoPLFu//3fq/5B93Fmnz6J+cejonYpLtAT5O3MoE9q/2qtUyA6JQVe9/KyUI0Zq2D53G0gSEYWNHVkklvOhGU3AX60Gl1/Dp2o8a7kr9auN2+ROJk55lgWuFVdOkGsnI/RjqR5yBE4YcIzdhUzo75yL+R1wluPkHvKzcBNUfJfs6UStcg3RvocQJvos3t8Ie55dbTBkmiXWO4GzaPMQMnWvyrNt99CU+kzYB2REQ6ZgmORiF6Vk/sQETKzhd/wI0RnhOuijITF21qZ+26lP8Z1rMGjpDfGCIA9/mHEWxy19fLdKyoLhnKunjb3sOk/NjA6nyZye1VKAQiR8L+P5Ix+8q4LpC4K9NO5pUbHiCkPwvUKcnq+gpAnjBtETeBz9J8IgxTvjLZVYS/5A/5aHcDzbNe/52x+IvEtxiu4QwbGgfgQNEwe5+0Ldvt/OFZn81u5mxvzdiUgvrqnm5Z0EPSmw6fhhzpuABtp4EULwt7/UHejEZxA8hCVUgDY1Q+MtNR7qd7b7NKZfskF+X+GyK6f1MXX9RGTjpff8PVrN7Vh2ybgNyjgBkyttYSxy15Sbssdy9hqKgVgE1S47frdT5p4BSbk28gX3HPHxEKRKgrLPQYvWGajX7RRYx+4XJkjMv2YlOgsIGCq/STIrTUogxtK+o1EhIKanpaAYU/pnTG0R/okTYWsplHnynkYPwx2IJ 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)(23010399003)(1800799024)(376014)(36860700016)(7416014)(18002099003)(10067099003)(22082099003)(921020)(4143699003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 7oS2RettfJciXjAoPrqIpsgslkhkkpGAiW01FyzZHJNa6VOeV1Fs9l0RKNylshp8F43mwG7dYZK4yEnC3v2OZJfklqhnVYV8xmuueMD12u9jjbrj9fZR1VkqsUWmm6umnN6nxJeXy+PoYlQEQJEoloPH4EFw7pN+5lvyUMKMLbcWDF1wFCxmgit2RPf6HuaBXte6l7/4hBbWSHicYtdXGpY5AbGKJBmFA25RMv92aM3cXFiCCKCvG1U1CnGToXMhntV12UFo+3Pw59MKrc8GTvPBosZ0etwE2n1Wp4DIHjySvFMuIGuPBtltL9UDWxOmFJngwwXyApuTDlKSDb3h4ptwXkO8ss96jh/qHKPb0lo2Kg4bHCwK5V1iWIh7xJJ4YSFLPtrgDz0pQVTJQQpgka82T+jZZUitzlQX5OGrgr2p+XXZY9v881FQ+I0KBjNe X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2026 06:00:50.4752 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7cfeebe3-ee41-47b1-9a45-08df28262b02 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: BL2PEPF000352CE.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5915 X-purgate-ID: tlsNG-bad1c0/1791784865-3B6D2034-3203A458/0/0 X-purgate-type: clean X-purgate-size: 1221 Hello Juergen, On 10/8/2026 12:48 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 > Acked-by: Rafael J. Wysocki (Intel) # ACPI, cpufreq, powercap, thermal > Acked-by: Sean Christopherson > Acked-by: Reinette Chatre # resctrl > Reviewed-by: Zhongqiu Han # cpufreq > Acked-by: Ilpo Järvinen # pdx86 Feel free to include: Reviewed-by: K Prateek Nayak # amd-pstate Tested-by: K Prateek Nayak -- Thanks and Regards, Prateek From xen-devel-bounces@lists.xenproject.org Mon Oct 12 06:52:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 06:52:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445834.1661678 (Exim 4.92) (envelope-from ) id 1xG9tE-0006wx-WD; Mon, 12 Oct 2026 06:52:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445834.1661678; Mon, 12 Oct 2026 06:52: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 1xG9tE-0006wp-T7; Mon, 12 Oct 2026 06:52:04 +0000 Received: by outflank-mailman (input) for mailman id 1445834; Mon, 12 Oct 2026 06:52:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xG9tD-0006wQ-El for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 06:52:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xG9tC-004PUo-3A for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:52:02 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc8386-8faa-0a2a0a5109dd-0a2a450c97bc-42 for ; Mon, 12 Oct 2026 08:52:01 +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 6acc8391-f479-0a2a450c0019-d155802bacf9-3 for ; Mon, 12 Oct 2026 08:52:01 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a01933b584so13076535e9.0 for ; Sun, 11 Oct 2026 23:52: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-4a1a1feb78csm46401155e9.0.2026.10.11.23.52.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Oct 2026 23: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=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=1791787921; x=1792392721; 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=/2BxOHwtQlUBpqjW1VD0N3o/AdhodhpFyfCbd5R0rMY=; b=YWYI6HWGdBhGUZFTrnzPOm1gP81LzvuoVP/vTkngkbAUd73tD4sfZp+5jWrxNXQ8Ut O8yxrHJ703mzxEIxRaXhNDTVw3PNogimfgEcIUF+lPAUzC642QwoY7AZ0ukOPOpwoPgt ps9X1vgaABDPZgD+oitnQzMta1tkoClzX9dBFPVeV4hEtKdQ9bimI0zWiMgu1CILQiv+ mmlojorMdJx+4Ar/hgNWlaI9Eqw9RR/ozvTrwwqTVJcItrYFurtOTl8BEKolMTMbnARR wNIUwYdLsq4mA7hhpy/EXucWQzR3xlVI44dcGJngCObx2fPh5xTi5t+Iy+qrYw/czyXK 0O7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791787921; x=1792392721; 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=/2BxOHwtQlUBpqjW1VD0N3o/AdhodhpFyfCbd5R0rMY=; b=MvtS2xtpcnrMIglha2bSKggjd3G/+cJEzvUrmVp+etw5T6aYWSC42fhJAlkIkC3CJr cb9X7+PCviF6I491NORucP+BRuu7cuB8/NqGTecEQKxP+sLzxO/dV/29BVGUFLi1xb7p 7ySqxevj9z9caFUOwhy0R+wpqJH23StKWIjFZmzSNuVxYrzisJPjDWIrhaJV59LOhCeq d4zFFo6JL9IqIC3ycINHdjwDfwnVV3EvOaqEVi01dYfp+8jR2g9zV5wIbvC5fzl14xFD HkyYSzNr1Gxy5xTYjMJAeLOG23ImmHrkizcfkh3c34QmdOJcAsmKTzebEHSDnqTN5v8K R0OQ== X-Gm-Message-State: AFq9FYJunOkxo4eYa4cNmiim2hWRxkIh6GbU/q0K7AYfzTURONXWb8KS XSl0it07Xei75pPcBTiBWDYcYUP7zCEVuCyPpuejToZ9ls9uo2Ll+/Gf4ty+tk6rMQ== X-Gm-Gg: AYBFou39rl0qABQXHZUD8XSMqEsrH+vWkrQVjVCbdm8AWeiau64NiQ203kIrZ6qRT1z idGNcvKl7rma6yy8eXzSofFceGiRNr8X5FLYMVHRht/4qyWQ/wBuZSFGp1y3rdaFOtnBQIKb/yf tHilOrhIym4wXBaGGNPOLb9Tn1KfCZ20pC78NKxA/evNPk25/xasZO9Uy+4zFCpaM226RWmQIkw iCk07/NdmhOJMll0gB6m8BMQhvERtNtL/awg6Niw60QZhvzkLUSF1JRh18urCOp/OxuZS3tUlLq xLi0XXptyT8CCmf5LRDshemRUNQIZcAG1Qn/N/hs5qT1Tkd7BHKci10TIExM1HQEOErYxJHR/kh 1r1PV9tSsf3eWHa1CuU7yFFkXrUkBWKSvZ+YCMg0RwlDs2Ce7nDWuqj9/fpZtPybg2XbygRYtoB RT07aCpCVKRYOpjSuFNMf229bOK51ZaehrB/tdYbp+kTt5YPzEQ7i9jxzC9QkEygPq0iK7l7grR Oc8KYgHCpLdV7jsMCaFU92+TP7msLfZC+S0M7w15bdgKx+SANQxtenx72WXfw== X-Received: by 2002:a05:600c:3554:b0:4a0:1b14:e283 with SMTP id 5b1f17b1804b1-4a18e43a1cemr158201245e9.1.1791787921061; Sun, 11 Oct 2026 23:52:01 -0700 (PDT) Message-ID: <96319798-7cf6-4905-9b1b-37bb6a41bdcd@suse.com> Date: Mon, 12 Oct 2026 08:52:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Dmytro Prokopchuk1 References: <5b5cccc8bbbc4c87fc99427eb4c1c413@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: <5b5cccc8bbbc4c87fc99427eb4c1c413@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1791787921-00ACCA5B-33AA6C74/10/78276251493 X-purgate-type: spam X-purgate-size: 2552 On 09.10.2026 17:37, Nicola Vetrini wrote: > On 2026-10-05 20:56, Dmytro Prokopchuk1 wrote: >> The R11.1 safe cast only matched void noreturn (*)(void *). Accept any >> noreturn function pointer converted to a compatible function pointer. >> canonical() covers typeof destinations, and compatible_deep_unqualified >> keeps the parameter and return types aligned. >> >> Signed-off-by: Dmytro Prokopchuk >> --- >> >> This patch tries to cover both of these: >> >> 1. eclair: widen R11.1 noreturn cast deviation >> https://patchew.org/Xen/c6632dd805a119aca54b9d1ae2eea68ef9c1334c.1790674358.git.dmytro._5Fprokopchuk1@epam.com/ >> >> 2. Eclair: relax "noreturn" function-pointer conversion deviation >> https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com/4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com/ >> >> Test CI pipeline: >> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2914802667 >> >> The only one Rule11.1 violation remains, which is covered by this Jan's >> patch: >> x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() >> > > The change itself is fine, but the aspect I'm concerned with is the > following: if you have a function marked noreturn, the compiler is > entitled to > essentially remove any code following it, so in principle this could be > the case also when invoking a function pointer (i.e. the compiler has no > obligation to retain code after a call to a function pointer that is > actually a noreturn function). While this in practice may not happen > often (e.g., the analysis done by a compiler is probably too shallow to > actually infer paths where the function pointer is only ever assigned to > noreturn functions when it is called), it is still not completely true > to say that the behavior is not altered by casting away noreturn. With "behavior" here you mean that of the compiler? Because Xen's behavior won't change if the code following such an indirect call isn't eliminated. It will "just" be unreachable code then. That said, ... > I have > given in [1] my R-by to the previous form of this deviation, but I > realize that this aspect should be mentioned. This is of course > supported by testing and code coverage evidence that the behavior is > indeed the same, or a suitable guarantee from the compiler vendor that > the behavior never diverges. ... making this explicit in the patch and/or deviation description is of course not going to hurt. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 07:04:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 07:04:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445840.1661688 (Exim 4.92) (envelope-from ) id 1xGA5X-0000NU-0v; Mon, 12 Oct 2026 07:04:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445840.1661688; Mon, 12 Oct 2026 07: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 1xGA5W-0000NN-TQ; Mon, 12 Oct 2026 07:04:46 +0000 Received: by outflank-mailman (input) for mailman id 1445840; Mon, 12 Oct 2026 07:04:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGA5V-0000NG-Ti for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 07:04:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGA5R-0055a0-TV for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:04:41 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc867d-2eae-0a2a0a5409dd-0a2a4503c17a-34 for ; Mon, 12 Oct 2026 09:04:41 +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 6acc8689-fae8-0a2a45030019-d155dd32a4bd-3 for ; Mon, 12 Oct 2026 09:04:41 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48b02a2359aso1393515f8f.0 for ; Mon, 12 Oct 2026 00:04: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-48db9aba3e5sm17507061f8f.31.2026.10.12.00.04.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 00:04: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=1791788681; x=1792393481; 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=t5H9B39Nd5D95c8kb4KNIU0U3j7Hw+T4Kk/G3QmQq88=; b=STHEUxJPWJ+CduLhPGuUPUkq2xPMkJ8EV60/mObF0qCwGoab2ErdXauKPcDs8wBU5Z AG6ooB9K7iR29bddVVhynDsD38u1x0Gmzv9VBi7XdDbn4TbkNS4osgQIxjXDBVf0JxsS 1eTTtEmW3Y2pMnLuhS9ZZ7zvbEHvw6gt7fgo+pd8r9F6sUsBBicblhDRgg2nWEXBiJHn sgu0GpQmDPigb1fi8MJltwTaJruTeExoxRz2RIlyhnksNvIb3bkJMQyrnigYyiO/NIw2 Gh7P10SJH5GCYHU1pZOjAN6xo1PoCACv+oHC2gfNrKmHAH+3Jrf8fWpNYyMgEgZ1Ww/0 jFLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791788681; x=1792393481; 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=t5H9B39Nd5D95c8kb4KNIU0U3j7Hw+T4Kk/G3QmQq88=; b=LBBVo1n+RHcME5iNeiE8npoP/B/eUBUbIiMSwin00H/6/kCPL7m84ulYbER4s+tFlt IXW/5Y7uhdb7KwxXT/Vhc/jpeZFVU/gQXt2XEE6M0yMnyPOb7lbNGpWaMP4oejii6+N+ mdszJMhClfO77WFI5J+N7w81CqxdybSZYL3amIc4A3GjgTJhWkSch02VYhHVBcTjebMG v3tm4jQpDYHJ6DzW2y7qhcDRuEnU/235mxW+sscczEsTpmsPRPclK7E8SWsHkH6QYDug qTd6mCezK0LLpdiYoDnJi6IzSwV9RLHvtPc9lI4dEeVLb6/LRTM+bI5QxOqmmAZImCL3 7xow== X-Forwarded-Encrypted: i=1; AKwUvByoEANmel0mrSOOu8rz1odAI+YSmrPJy6WoqHpduZwO+B4qAcdQ6KZMSY3XjXh0Z8GUs84l8lqo5gU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKG37JYbUeLErVzNJu5cZrv8FSn2Gr3NmiIoT9Ncf6uRzjvxgAo 9/vYzjp936b5pXIv1fcVOX0yfVDex3Ed/pBKxMytFzxi8q3M05dVhdyeTWU9JvGnuiRxmDX13Ck 4jIxVnw== X-Gm-Gg: AYBFou3rpM8/wmVhukmAEnctIhfUGRE8gl8G/8A7EVE2rmpUrhZDSsidQ+bWUfTPJ6G h+nOR/sJn8wawHIOl+AcFDW1McQ6T20wJpKqsWbywvlsT/nEzn73VgykNtImXMAM2zoBq6Dt6tw Vi/kUzQu5UxerDMUH7JBuGxHdOErxlq7349WNOHyzlrKUreL508oS3i3alWzasM0xhnjv0WegDk MFc0croG7IoJk69crGiJ6dHn/7RlZ7GLSxGEHXmrs5JZxlZoH+yIbqZVH2figdvSq16EfgLfFOc wT6fjq0JNePMBvGjOzKEneGHYkmSpeN5op++0wkGYElMx5IRPHOYI4ITsrpVzmBlXnpe0IK5C7V Z8WJcTXFKaaWGDb1hYIGxDLnJqECo/JcgV82vo5BcYEaWW5EWRbjr8UfD+0zGFAwItl8h9DkU+U NXqyVvhlq6osyva5vTuPwBHoH3demNSdlEIvi2/2Yr/OUdlVrAsLi6TgDJTVkTRKroRmqxeYXtG HRCWI6JOe4GPB/x8RCoaSaU24cO1T9SAGUuUhjCxUc0qwO18aM0+UE6YKOJZBXJsz/nfuQd6Q== X-Received: by 2002:a05:6000:25e8:b0:48c:55c1:fb47 with SMTP id ffacd0b85a97d-48db9464fbemr17188299f8f.10.1791788681016; Mon, 12 Oct 2026 00:04:41 -0700 (PDT) Message-ID: <0e9d573f-299a-4459-81d0-94c905c85c8e@suse.com> Date: Mon, 12 Oct 2026 09:04:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/argo: make the ring copy length check overflow-safe To: WeiqiW Cc: Jason Andryuk , "Daniel P . Smith" , Weiqi Wang , WeiqiW , xen-devel@lists.xenproject.org References: <20261010132845.36208-1-lukewang19@outlook.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: <20261010132845.36208-1-lukewang19@outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1791788681-6F0C94E9-0F0F064A/10/78276251493 X-purgate-type: spam X-purgate-size: 1554 On 10.10.2026 15:28, WeiqiW wrote: > From: Weiqi Wang > > memcpy_to_guest_ring() bounds the copy against the ring size with > > if ( len + offset > XEN_ARGO_MAX_RING_SIZE ) > > where len and offset are unsigned int. offset is masked below PAGE_SIZE > just above, but a len close to UINT_MAX makes len + offset wrap below > XEN_ARGO_MAX_RING_SIZE and pass the check. The head_len computation in > the loop wraps the same way, so the copy length is no longer bounded. > > All current callers bound len via iov_count(), so this is not reachable > in practice. Which makes it questionable whether the change is actually needed. But as it doesn't look to introduce (e.g.) dead code, the change is likely fine to make. However, there's a formal aspect which may need sorting: > Do not rely on that: bound len first, then compare offset > against the room that is left. > > No functional change for in-range inputs. > > Signed-off-by: WeiqiW There are two different real names and three different email addresses involved in your submission. Generally we'd expect at least the From: that's going to be transformed to commit author to match the S-o-b. The mail coming from yet another email address is maybe okay-ish, but not helpful. The main problem being - how would anyone (reliably) determine that all three belong to one an the same person, not several merely happening to have identical / similar names. Hence no ack just yet. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 07:32:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 07:32:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445849.1661700 (Exim 4.92) (envelope-from ) id 1xGAWC-0005CZ-3y; Mon, 12 Oct 2026 07:32:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445849.1661700; Mon, 12 Oct 2026 07: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 1xGAWC-0005CS-1M; Mon, 12 Oct 2026 07:32:20 +0000 Received: by outflank-mailman (input) for mailman id 1445849; Mon, 12 Oct 2026 07:32:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGAWA-0005CK-RB for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 07:32:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGAW9-005BA0-IC for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:32:17 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc8cfb-bab6-0a2a0a5309dd-0a2a4507d784-40 for ; Mon, 12 Oct 2026 09:32:17 +0200 Received: from [40.107.209.46] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc8cff-b4ea-0a2a45070019-286bd12e4ce1-3 for ; Mon, 12 Oct 2026 09:32:16 +0200 Received: from BY3PR05CA0032.namprd05.prod.outlook.com (2603:10b6:a03:39b::7) by SAWPR12MB999142.namprd12.prod.outlook.com (2603:10b6:806:4e1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.21; Mon, 12 Oct 2026 07:32:11 +0000 Received: from SJ1PEPF000037AB.namprd03.prod.outlook.com (2603:10b6:a03:39b:cafe::6d) by BY3PR05CA0032.outlook.office365.com (2603:10b6:a03:39b::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Mon, 12 Oct 2026 07:32:11 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000037AB.mail.protection.outlook.com (10.167.244.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 12 Oct 2026 07:32:10 +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.53; Mon, 12 Oct 2026 02:31:58 -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.53; Mon, 12 Oct 2026 02:31:58 -0500 Received: from [10.27.77.50] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 12 Oct 2026 02:31:56 -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=p2PULSOcAM9VJIi9Z2/rjbDb2ZQ6GCjBEOXgxVeQwfB//VwXk8Rcu1Yh8lN4eb/QuORTsZWQY5kuWJm2V7v1on0hJw6k1TVAY8OM8blB6IWbAEsiLRShw6poyEkz7ARhNzkzYqfyrDQ4VqYyfhX9rAPIMsugEyhDs8CX5LJSvNSUvHHKMyF26nHQKP26mzxS8x6A3c7KMbijE01XoMGWT5JBkcCX+BMDbPDQTLvGvFJU2mqmHkwUfH7DBkgwkdILyCDTK5xdpYznprIoJ0K1tV9CQaOMgq5fYftRb8iqT89mYvEuYk3z4Cc+NmS+ED/AlzBu9rJr1m9XFC6Y7sP1Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/MxTUYpqdo3ktSYxb0sZm0A+NJ1qRXX6YhLwnGe9o7Y=; b=bwYd2ZqsiN4D3+gLKCA0nYie1zA8dLXielZ0yRQjkIpZz5+ii1WqfSbepIiCeKeR+5XWPLXF3z7nQ8ITf9KUcVLe6ATEXRFGc2Jb6sC3NK8riJAPG+VuwC3cC6EtrwLPP/RaE59nn/f8bLMy8gz7uGR4AIMdljX0NGgh8on/zk1QJn7bQl0YTZlEn72Ny5/ytl4FRLxtHPNIJ1EJIKLGl4Q95/5gHcfoSAvZCjDfE0ty/Q8yZW3fAGbr2ffeC0oUJwzCtmAwpYDWNTWN5PIX2q1YKGVgFozgl1/pcMBJ+KKjVKEkNXM6XbkKfanwmTyO1749Qqi2S94tiVcJMNTK7g== 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=/MxTUYpqdo3ktSYxb0sZm0A+NJ1qRXX6YhLwnGe9o7Y=; b=wtqFS8wNBBxtw9FkIP6qXmS5qy7cxaus0s1fnrLpxDG7L9fWWZONIpxr/jj+0cVXhZRJ5bf2acTCFgCcfdIKXl0nCE5lTwYP0LBwpHwmvRkH6dbR9iGt3024Z6TNM/1bB8sf1Jtc2op3f/AQ6VTRrEO70/3yqGtqZJPBEfA1l18= 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: <9d970022-6b08-421c-aca0-589a0b5c2c27@amd.com> Date: Mon, 12 Oct 2026 09:32:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Fix under-mapping in map_range_to_domain() To: Julien Grall , CC: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20261007135848.220047-1-michal.orzel@amd.com> <055dc887-0cfd-4274-a5f6-e5afdd576746@xen.org> <9a4f56d4-4c2e-4d5a-8489-9300170729a3@amd.com> <71defbe4-44a1-4b76-8d0a-bcc6ab40515f@xen.org> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <71defbe4-44a1-4b76-8d0a-bcc6ab40515f@xen.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000037AB:EE_|SAWPR12MB999142:EE_ X-MS-Office365-Filtering-Correlation-Id: 8fbc0f5b-b930-48d5-4531-08df2832ed8f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|23010399003|376014|82310400026|10067099003|5023799004|11063799006|4143699003|6133799003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: BqV7DRvHDkHxaVYoYMfycCmmOnNkxBpDeW8FxcFIW9adOGI+BLffS7/cQ5LWJll50CNRAXy4a3CiaXzZMaKZeuDxQX8LlR66BFI3MLofVI10iFJsIt4v0c4fKNfN6QcGWDPgPdBtfHfsLHNc1XLuewICJNS23DtulXlarFKDQVUmBRzfxrwhDabtOp9nt6skjQn/2hrpJGNjh7nKU1XjJIZj32jq9uxcq+ukJXvJ0wQUo8TpBHOsLTEPH5Chzd4O6SqwNgl4uow5sNiH8QuCcZL96XRD1gZ5Ttlji++5HQheC/CoecR8yZ5wspoW7smiZ1fRw7CIlAKOWiJapWaaiyiITS3Z1lxHSQXLvRA7575Fpj2kTZ4BYQnbcQE9z1MpNTwF1q0o4zDF496EcMUFufh0dvCBfL8c87rYi7rUnkTvv9K7NhzENm5JDrDK43zFAMfc7t5LkLM0zDheYh1AZ6ff2ELN1/K7SfBYcBj7Nkqm1zj+z7FLOLv9anLIOJ2qhR1A3B5qnX3NDSp7Rd0Gv2Hqm0nRt/3N16fsg5EqKfVSBiF41BELYrCEjyIaJT3eUNooRrVKuwOmZyzSvOfxxFwghlm6N7UhrDzKxxg/67x86hXZHYSe4MLF1q0nDiIng33V7qgR3Re9tUh5Xg7Pp5dToSWY0xCT3tQkyMPiFqiSLdBCfNRXzG2uvTUn8KFYyOaPm9MKS4h2oykTJCl+WA== 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)(376014)(82310400026)(10067099003)(5023799004)(11063799006)(4143699003)(6133799003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: xkJSNGv/06ZaYPoEwgXnzExPSH9cm4OXtAgiBufPsJiMgPxHDABwSO63HSEdtShEcyH1ZAGIWcKDC3ylLG6IzbGSh45VVgxhPlCjlcrC5bbmpqNX6Zt4kHWBpMT0cGhoWib9eE9f7eqIHeYNdxqyo92gGWZAR9MkpWE14HaMZ4nZ5E8L9ARN2Zu2MzPaG3i7uL3F+o6pdFRXxgei2EzxPlodlAd9MtdRSilXtzaDHpeYwBqO/jlAhty/8TCTAKb4dPYibTHKDy9x5FvnqUCCa9Chh59x/GO2T4Q3QGnclD2E74PB+GL5KHNU+AenJHWu7mIOYHEGDDOxWxcB7eFPXLmG16aPQX16ks6qiccTPk/xSXCDeRXItMQXIanHBL69t4egcHkiE12k5GG7JuFik5OoubidvS5QXChb/JxGJc1vhAI7VjoPhTbrflUWop4t X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2026 07:32:10.7694 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8fbc0f5b-b930-48d5-4531-08df2832ed8f 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: SJ1PEPF000037AB.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SAWPR12MB999142 X-purgate-ID: tlsNG-ef75cf/1791790337-360C5AE4-7790CA99/0/0 X-purgate-type: clean X-purgate-size: 4267 On 10-Oct-26 12:38, Julien Grall wrote: > Hi Michal, > > On 08/10/2026 11:50, Orzel, Michal wrote: >> >> >> On 07-Oct-26 22:20, Grall, Julien wrote: >>> Hi Michal, >>> >>> On 07/10/2026 15:58, Michal Orzel wrote: >>>> If the memory region to be mapped does not start at the page boundary >>>> and its end spans over the page boundary, map_range_to_domain() passes >>>> a number of pages that is short by one to map_regions_p2mt(). Domain's >>>> attempt to access memory within that page will fail. Fix it by calculating >>>> the number of pages to be mapped taking into account the start offset. >>> >>> Can you provide an example where the caller doesn't suitably align? >> Sure. Example is handle_device() being called on the hwdom DTB creation time for >> a node whose address is not page aligned i.e. /reserved-memory node or basically >> any node, given that DT spec does not mention anything about memory region >> alignment and there are existing DTs like that. With reg = <0x0 0x800 0x0 >> 0x1000>, today we only map 0x0-0xfff and an access to 0x1000-0x17ff faults. > > Thanks! >> >>> >>>> >>>> Fixes: 88c10b0d6eee ("arch/arm: let map_mmio_regions() use start and count") >>>> Signed-off-by: Michal Orzel >>> >>> The fix LGTM in the current context. However given map_range_to_domain() >>> is now used in more places (e.g. overlay), I wonder whether this is the >>> right decision to allow map_range_to_domain() with non-aligned region. >>> >>> Imagine a user say "I want to map 0x400 - 0x1000 to domain A and map >>> domain B "0x0 - 0x400". This could result to interesting behavior if the >>> user is not aware of the alignment (this would become even more >>> problematic if we decide to ever support different page granularity on Arm). >> I agree this is not great, but this is not something introduced here: >> iomem_permit_access() and the iomem_ranges rangeset already cover whole pages >> and we already map the full first page.This patch only makes the p2m mapping >> match what we already allow. > > I am possibly misinterpreting what you wrote, but I disagree with such > statement. The fact existing code may be wrong doesn't mean we should > continue with the wrongness. It was just to clarify that this patch does not change who can access the page. > >> >> I don't think we can reject unaligned regions in map_range_to_domain() >> though, as the host DT is not under our control and hwdom would fail to >> boot on platforms with sub-page devices. I asked AI to look at the Linux boards >> for Arm and Arm64 (140 boards in total with unaligned regions) and even the >> boards we claim to support have nodes that would fail: >> - RPI4: hdmi@7ef00700, <0x7ef01f00 0x400> >> - IMX8QXP: clock-controller@5b290004, <0x5b290004 0x10000> > > I am not suggesting to reject unaligned regions when mapped into the > hardware domain. I am suggesting to reject it when we want to > passthrough to another domain. So we don't end up in a situation two > different devices on the same page are passthrough to two different > domains (or between Xen and a domain). > > Codewise, it would mean map_range_to_domain() would enforce the > alignment and the caller will be left to decide what to do. We could > also decide about the alignment base don whether this is the HW domain > or not within the function. For passthrough this is already the case. map_range_to_domain() does not map anything for nodes with xen,passthrough and the domU mapping is done by handle_passthrough_prop(), which rejects mstart, gstart and size that are not page aligned. The remaining case is the overlay which can be attached to any 1:1 domain and this goes through handle_device() -> map_range_to_domain() without any alignment check. All the other callers operate on hwdom, so I think we could reject a region that is not page aligned if d is not the hardware domain, before granting the iomem permission in map_range_to_domain(). Shouldn't we accept this patch as is so that we can backport (overlay is not supported) it as a fix and then add a second one with a rejection mentioned above that will help the overlay (and any future) case? ~Michal From xen-devel-bounces@lists.xenproject.org Mon Oct 12 07:34:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 07:34:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445855.1661715 (Exim 4.92) (envelope-from ) id 1xGAYf-0005jP-Qj; Mon, 12 Oct 2026 07:34:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445855.1661715; Mon, 12 Oct 2026 07:34: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 1xGAYf-0005jH-Kj; Mon, 12 Oct 2026 07:34:53 +0000 Received: by outflank-mailman (input) for mailman id 1445855; Mon, 12 Oct 2026 07:34:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGAYd-0005gY-D9 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 07:34:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGAYc-005BV3-Q5 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:34:50 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc8d91-bab6-0a2a0a5309dd-0a2a4506b5c0-48 for ; Mon, 12 Oct 2026 09:34:50 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc8d9a-195a-0a2a45060019-d155dd32ade2-3 for ; Mon, 12 Oct 2026 09:34:50 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48c6955a7c3so225637f8f.1 for ; Mon, 12 Oct 2026 00:34:50 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db9aba3e5sm17622702f8f.31.2026.10.12.00.34.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2026 00:34: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=1791790490; x=1792395290; 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=u85WjwwTDumBM2QRM9L5Q/kESBWlmNyvbPl4+ZXJng4=; b=VOqqxXLXyQC6M3CpPd3po7X0FozQur2Fwf1XcllSrixMENjSGEUl8diunNi44g6hMu m3uj/V08xmIAU3WCbn/1WCLMS+HqBbzAhMCWFPTXM4rmkH0nyRDiJWtw4s8pXJU0FAK4 hfkrADFzWHMfnmFgO4hPsItlJAhLVK+/aqg8mJEs9XrOaQQKmLqJfioesBwdN9iDbGUt DDohbVosBcAZAHAnB1jmkp+Dhz2020/R/5GDySqcu6tOSCxGH1pazB8T4yfbNCJ95mZt Wjm2LdNUV1r8r39OzXSeoicMY7TwF+RHbN07o2MeX6PfItZWz4XsB5FNP8FeYDIIAQdf g2Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791790490; x=1792395290; 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=u85WjwwTDumBM2QRM9L5Q/kESBWlmNyvbPl4+ZXJng4=; b=zZ4+LrTsrYvjUnJa0ki3yVCE1d/iBDjruEtWN8yQ5EQ/BTQmU2Tq2Ap0sLLi+CgDlZ 5dkGlRzJbw1nQf4xP6Lv2C1pa2CcUBfxiCOrNJeV1pthYE4LyZJBYTQsMy54+HloACRo C/tBBk/SMfNN9bx2HPzvzKNufG7gS+ceo5g+xSIFKiAmVWgW0f0sal+Y5NWpcwda8G5T y8l2kwW5aYoNHL1NcZi291gqBBXh5m/jZEmz8eQBFttq/kP5NjpSOU824n00Qslcwhgd 9ivXKuJWqK/a8jLC689M5QDGZujzzHWkcdklVPifJjmbPe6hEUJXyz4fmOno8kcxHuor 8J/g== X-Gm-Message-State: AFq9FYJSoNircqydIlegWdLTtlEtgyC5yWpkq/oAVmHDbFUz1uP9WnZY uBcQLS1ZE3N3urfYBYSjho/bt1XzGDRmi8rKYYExkUXzM8ureqoOo+0rWdJuGA== X-Gm-Gg: AYBFou2KXyzSGRpWwnu1crXBxqnnS/NpHcNhVyz3G2jQ8bBTfU70iDlh7lp3QrhqvnQ JL5+0sD7P7bxVxrABRzLN4dr2dOMKDQGHqoIPxgDv/0VMA5PwloMCqUTYBtCILPkXdMEAB5Iwqj krOsTcZI1qTh0XcgmIKbiBEnqdy3+X+eYGi0L6QgLUaqzNZuXX/9JjJ5O2VFhGarXYcJaCO3qEy woTxd/EVeZcMGdIF6etkD9wUS93vBSdtzFr1zV+TNROJMHnAMYmV2uPcJoMOexpVZ6gDKhrRsEP Au5gz373grFh6ajXl4iaJ4ei9pVnOZ8VOGheJgumA2JrIi0zLB2l9ovyL/a+Qn0d7G+ijUyE+Kt +c4el3QtY0rp9ctH+bmvTnymIzuhEHTMk1OHObaDbaIlaEbIe8DPXlei176NtUIkdwwHUuFBD79 TY+PmTNqvwNce4VJFdJuI0iVvrwojaDhpdAKg/TjCNmnLUe/o1lxcWywJNBSBRHkHw5GAbi6J+g GupjAS1NdaTH2f6gtTC9htGQAU4XCRwVWjhDtqw X-Received: by 2002:adf:f782:0:b0:48c:71b8:c633 with SMTP id ffacd0b85a97d-48dbad34569mr12042628f8f.43.1791790489938; Mon, 12 Oct 2026 00:34:49 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Michal Orzel Subject: [PATCH v2 1/2] xen/device-tree: move discard_initial_modules() to common code Date: Mon, 12 Oct 2026 09:34:41 +0200 Message-ID: <20261012073442.15819-2-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261012073442.15819-1-oleksii.kurochko@gmail.com> References: <20261012073442.15819-1-oleksii.kurochko@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1791790490-FD40B77B-2D081998/10/73395122804 X-purgate-type: spam X-purgate-size: 5267 Everything discard_initial_modules() touches is already common code: bootinfo.modules, using_static_heap and fw_unreserved_regions(). Move it out of Arm into common/device-tree/bootinfo.c, next to the boot allocator handling of the same memory, and declare it in xen/bootinfo.h, so that other device-tree based architectures can reuse it instead of growing a copy of their own. The arch-specific remove_early_mappings() is not moved along with it: how the early FDT mapping is torn down is up to the architecture. As the DTB is one of the boot modules being released, the mapping has to go once they are discarded, so call it from start_xen() right after discard_initial_modules(), which keeps the common function free of any arch dependency. While moving it, use unsigned int for the loop counter and replace the "goto out" by a plain return, as there is nothing left to do at the label. No functional change. Signed-off-by: Oleksii Kurochko Reviewed-by: Michal Orzel --- Changes in v2: - Drop the comment above the call of discard_initial_modules() from arm/setup.c as it duplicates the comment added in xen/bootfdt.h. - Add Reviewed-by: Michal Orzel . --- --- xen/arch/arm/include/asm/setup.h | 2 -- xen/arch/arm/setup.c | 39 ++----------------------------- xen/common/device-tree/bootinfo.c | 30 ++++++++++++++++++++++++ xen/include/xen/bootinfo.h | 8 +++++++ 4 files changed, 40 insertions(+), 39 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index c491c567298f..02fdf2b56c9c 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -40,8 +40,6 @@ int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]); void create_dom0(void); -void discard_initial_modules(void); - void init_pdx(void); void setup_mm(void); diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 16f899dff57b..2cd1c021b559 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -210,39 +210,6 @@ static void __init processor_id(void) processor_setup(); } -void __init discard_initial_modules(void) -{ - struct boot_modules *mi = &bootinfo.modules; - int i; - - /* - * When using static heap feature, don't give boot_modules memory back to - * the heap allocator - */ - if ( using_static_heap ) - goto out; - - for ( i = 0; i < mi->nr_mods; i++ ) - { - paddr_t s = mi->module[i].start; - paddr_t e = s + PAGE_ALIGN(mi->module[i].size); - - if ( mi->module[i].kind == BOOTMOD_XEN ) - continue; - - if ( !mfn_valid(maddr_to_mfn(s)) || - !mfn_valid(maddr_to_mfn(e)) ) - continue; - - fw_unreserved_regions(s, e, init_domheap_pages, 0); - } - - mi->nr_mods = 0; - - out: - remove_early_mappings(); -} - /* Relocate the FDT in Xen heap */ static void __init relocate_fdt(const void **dtb_vaddr, size_t dtb_size) { @@ -503,12 +470,10 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) alloc_static_evtchn(); } - /* - * This needs to be called **before** heap_init_late() so modules - * will be scrubbed (unless suppressed). - */ discard_initial_modules(); + remove_early_mappings(); + heap_init_late(); init_constructors(); diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c index c637c45ad594..6772bf2df002 100644 --- a/xen/common/device-tree/bootinfo.c +++ b/xen/common/device-tree/bootinfo.c @@ -471,6 +471,36 @@ void __init populate_boot_allocator(void) } } +void __init discard_initial_modules(void) +{ + struct boot_modules *mi = &bootinfo.modules; + unsigned int i; + + /* + * When using static heap feature, don't give boot_modules memory back to + * the heap allocator + */ + if ( using_static_heap ) + return; + + for ( i = 0; i < mi->nr_mods; i++ ) + { + paddr_t s = mi->module[i].start; + paddr_t e = s + PAGE_ALIGN(mi->module[i].size); + + if ( mi->module[i].kind == BOOTMOD_XEN ) + continue; + + if ( !mfn_valid(maddr_to_mfn(s)) || + !mfn_valid(maddr_to_mfn(e)) ) + continue; + + fw_unreserved_regions(s, e, init_domheap_pages, 0); + } + + mi->nr_mods = 0; +} + /* * Local variables: * mode: C diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h index dbf492c2e36e..60ef25f3cf83 100644 --- a/xen/include/xen/bootinfo.h +++ b/xen/include/xen/bootinfo.h @@ -214,4 +214,12 @@ void fw_unreserved_regions(paddr_t s, paddr_t e, void (*cb)(paddr_t ps, paddr_t pe), unsigned int first); +/* + * Return the memory occupied by the boot modules to the heap allocator. + * + * It needs to be called **before** heap_init_late() so that the released + * modules are scrubbed (unless suppressed). + */ +void discard_initial_modules(void); + #endif /* XEN_BOOTINFO_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 12 07:34:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 07:34:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445854.1661709 (Exim 4.92) (envelope-from ) id 1xGAYf-0005h1-HC; Mon, 12 Oct 2026 07:34:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445854.1661709; Mon, 12 Oct 2026 07:34: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 1xGAYf-0005gu-EA; Mon, 12 Oct 2026 07:34:53 +0000 Received: by outflank-mailman (input) for mailman id 1445854; Mon, 12 Oct 2026 07:34:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGAYd-0005gV-AP for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 07:34:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGAYc-008U87-3i for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:34:50 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc8d91-2eae-0a2a0a5409dd-0a2a4505dbaa-28 for ; Mon, 12 Oct 2026 09:34:50 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc8d99-4cb1-0a2a45050019-d155dd35b0d2-3 for ; Mon, 12 Oct 2026 09:34:50 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48af4d4e61fso991510f8f.2 for ; Mon, 12 Oct 2026 00:34:50 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db9aba3e5sm17622702f8f.31.2026.10.12.00.34.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2026 00:34: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:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791790489; x=1792395289; 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=zHGX4VtiBD6X9kVo3dl0fflqY4sIieR53kMuKpSIpfg=; b=DftGgjSe2QU9KF7+6Tu/VvVc+RXR2GWz91KmQkvmcOP4hhgjain7wHx9hpphbqKaNg uGlWVin1Bp/RA5Y/VVlFMlUO3PXVxm4LUoVYbyfb1mCt3EqFCBQFiB+gx1sFphfoMdka pAsqgXQv/uVgOnpIAl16LXk/y77AGBxgJBuA2PYg3LEarhKNetlQWTayGXpt2udx/wSQ 5IaAuUW9bqdN7nYtG/XnUO47f2BaOrU8N30VPkqb7V+25FrY29SSwyOLmjZbXXybks1q RiUV02BYAhOyzzn/yar/k5VDQnZJvRbjKUtp3bLxqztjgpeAq3iVEKDQliD94iquEWOB 7evw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791790489; x=1792395289; 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=zHGX4VtiBD6X9kVo3dl0fflqY4sIieR53kMuKpSIpfg=; b=LHRefIHtQdQkw800Iylv9wPhf7Y4NAy/iQgdBMEXnRHd3Qk6reju+iNhIF506eqRWp hEGEfmBMUD/4aRPphkTJLiPqeX93mYMd3bkJPzxKlitM++kXIClaG6c1ZF0Hxu73VqZ9 bGfb4e2rFFpHVxS7PYtzq/2mEnAZt0DbjcGklWi2qRu1xmnS+7Glgy0G84fyVOwj7Loe wcec94RIFfTkT3eZi7IbeiZKMll11MeRE9ZaENEGyPKXL1VHK4kpJ8VAvcXTdoHwyJmT 5lIGzPdH6LgNk7E+lNQ9WOr1jCY5Q76L8zJCgrgvKRkE83CfNTFGzdQ2Xn6BwM5zgfU4 zqPg== X-Gm-Message-State: AFq9FYLY7xxPZ/+fFLw6OuQyYtAkw4XqtKN9MWr8NQzN79VndnklddJ8 TaSQpqJuAizYqNp+lrkrcLaQb6R1j/bwkJpc/almYh5xn9lZZVzoTsi3W2XqMg== X-Gm-Gg: AYBFou3hmVRkvqxo391eBiCFX/9gwEe90xFThiamDJ1g0hfnXc0NQjUtA1kTvAUiExN CgW3DdgrjnKFeP2ebOe1yYvtxdmhoUZeUs1d/7MnuKBY/IQEYRYfZKEs+UMMjyZGaoK/woMI35W 2v8Khx8naDGKGI3Ityg6+flbsK/oZFInY5VVNF4pTRsClSNCBdLDhCiGF3wMiqIupL7RvMz4OlG 0KHcKVDyvERpFHvW+AHYJDDdPPvS4n7/WsQENHN9Uu/G9DCG05mKBgQ4c6ewHeyIA/3hfa194wn mp7E5yStGce/fjoD6zQhbyyWFBPb94eIRD+NeIYDKqtis0EFIbAds2+dzw9rgAl084gW12QprUz X5ZYbUl+YzyjF+6AYawV31B9bNsP+mBCKJ+rvmCn2PduoNJMi12j0Jh5aaMwBZqGSeNlR02ks+M 2steApKLhjjSW9YkwN3roNYEvk0M7Onb7cA1ugbFCF4T++LmExaHTl07njO0Y5cdxCt0DsJVfKF CJrRBgnBczptHSIEKYzJJp+X0ZvQdFehTsjW9Ip X-Received: by 2002:a05:6000:dc8:b0:48c:7768:9ee6 with SMTP id ffacd0b85a97d-48dbad18258mr12359283f8f.38.1791790489229; Mon, 12 Oct 2026 00:34:49 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko Subject: [PATCH v2 0/2] xen/device-tree: FDT dump helper and common discard_initial_modules() Date: Mon, 12 Oct 2026 09:34:40 +0200 Message-ID: <20261012073442.15819-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/1791790490-716AD2A1-8EFAC805/10/73395122804 X-purgate-type: spam X-purgate-size: 1614 Two small, independent device-tree changes. Arm is the only user of both at the moment; RISC-V is going to use them as well. Patch 1 moves discard_initial_modules() from Arm to common device-tree code, as everything it uses is already common, so that other device-tree based architectures can reuse it. No functional change. Patch 2 adds device_tree_dump(), which prints an FDT in a DTS-like format under CONFIG_DEVICE_TREE_DEBUG, to make it possible to inspect the device tree Xen generates for a dom0less domain. Build-tested on arm64 and arm32. CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2930332473 --- v2: - Update the order of the patches. - Address other comments from ML. --- Oleksii Kurochko (2): xen/device-tree: move discard_initial_modules() to common code xen/device-tree: add a helper to dump an FDT in DTS-like format xen/Kconfig.debug | 10 ++ xen/arch/arm/domain_build.c | 2 + xen/arch/arm/include/asm/setup.h | 2 - xen/arch/arm/setup.c | 39 +---- xen/common/device-tree/Makefile | 1 + xen/common/device-tree/bootinfo.c | 30 ++++ xen/common/device-tree/dom0less-build.c | 3 + xen/common/device-tree/fdt-dump.c | 185 ++++++++++++++++++++++++ xen/include/xen/bootfdt.h | 16 ++ xen/include/xen/bootinfo.h | 8 + 10 files changed, 257 insertions(+), 39 deletions(-) create mode 100644 xen/common/device-tree/fdt-dump.c base-commit: 63d0e8cc842975e786455f8a2e6502e85685f258 -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 12 07:34:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 07:34:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445856.1661718 (Exim 4.92) (envelope-from ) id 1xGAYf-0005oL-Vp; Mon, 12 Oct 2026 07:34:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445856.1661718; Mon, 12 Oct 2026 07:34: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 1xGAYf-0005nU-S2; Mon, 12 Oct 2026 07:34:53 +0000 Received: by outflank-mailman (input) for mailman id 1445856; Mon, 12 Oct 2026 07:34:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGAYe-0005gj-Lj for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 07:34:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGAYd-00AzWn-Js for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:34:51 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc8d99-8faa-0a2a0a5109dd-0a2a4507cc18-6 for ; Mon, 12 Oct 2026 09:34:51 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc8d9b-b4ea-0a2a45070019-d155dd2adc9e-3 for ; Mon, 12 Oct 2026 09:34:51 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48c5358fc28so1066236f8f.0 for ; Mon, 12 Oct 2026 00:34:51 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db9aba3e5sm17622702f8f.31.2026.10.12.00.34.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2026 00:34: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=1791790491; x=1792395291; 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=SMxGP51tjn0U25bigtlNPn8d5ZOyybDKcznQ2+Ll/K8=; b=Dw6+dfZTp+iiZCFwIf96avU4u5mpHwdWDX4F69fdiKuTG3R33zwxd9hQQOliF2Z8MS z5tIeo095MX5x+J3DZ7jdQzlbJuEs4KahEAYHwbYTtmoiK6VEVxYnC7G7P2SygeRFhog ShSN4kT/7gnw/QO+8fRQEZ3LqE1FmmsWSfMGblvBC4o6vAI8p7vwed6XhM17YQAK18AT gwHxmiBX096Y+ypkbiuSBgXO3kQoBWR07OYNdI8h2DbQlb/aUElqt0lS+f1/weuSM2qh WBK7ZNODRhDZrXhkPCkEMAKtDKeutic92ADZx3gWOiLqLXipVoL0DfBCbFGqigAv38de gVKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791790491; x=1792395291; 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=SMxGP51tjn0U25bigtlNPn8d5ZOyybDKcznQ2+Ll/K8=; b=SGRtEU5aHqi7s4N0tjSLjuhj5zTyWpi8SVKM57YKzxg2u+fnjG2vHQYm+gaRqOhIlo 4rY2w/7Y5HuNa+Ac07w42ijN24NtP8S4maGf3pzfwiiOfRxNb7H1eDEc2EIuzpIQY65i YQF8h4dTDG3ia0vWfTM1BGsOMR3NXPm6LhqYRwevO4sVFVDrx6zwBkXoRx4crPjIXrhQ u6oG1CsUiWVprUAsJrnJ5UmTS5uK0J7oRVni9qv39zCExjI8fcSCuHXYMU73MJK8CHGM DwHHADFW4k6BDUyPeVOLoTFj2jYSYKFlBFJdtGcos7JUlhvJ3PYrCBYlNzc8V1VY3B5i lMNA== X-Gm-Message-State: AFq9FYLn9+Z6Vb5TKK3d5BcYPKCD+D3ZqFyEj8WCyw3UrRXkPWCvtqyk zVK7X42234ZXMIuospT74FgZRmCc7GwRVTm+WWwluGKoVIIETk9NP/rHlrOo+Q== X-Gm-Gg: AYBFou3jJD3QXsLKIEteoTMsCEkrPQ72sINXBmU74qsac4A+4B7dToVdKm86wXp5UDc xm8TQQi4w9BijV1WNShOaLd0maLThOol3rGRCIgLVFYyjLVxyaMJrv3fuZR3e4OMk1VGqqyzWd3 iSmHYF3TISama+JDTw7FbTxW2DR/88lBmw0e3UxJvCCz3YWASR+DvqLzygmxjYSfwOkrgvvOSNa idUsq/ffF6E+Ne32yv9rw8klZ0x6rYddweysGo+ptMuBiqDyB3T1/YQp/OrZwul4nLeQn+hjOJq 0Z68fPYgv1wIFAAnPN6V7Y6GxN55qlJhT3MCEWVSHPK22TN5jCQfOYlY7JhXoR+4F/cLe3u8J1V OhI4xtoawFU/aSEN4lauioEA49jXeAf6rG+uyVatty5JM1NPrBNUNUZIeivjuo1o4ZShL9mc97J w5BAV+1UuObooeIeWM4K/t6/zcOQNu7wp8ny4muqeqnBypKNp6meY8zoM6kMk0BET37mOK1eStf HpwAN4aJ9cuNhzqvRtDqLnuQ8aztU0hokKL+mAdhfmQw4biiVU= X-Received: by 2002:adf:e00f:0:20b0:48b:2ae:686f with SMTP id ffacd0b85a97d-48dba7892e9mr11201208f8f.5.1791790490723; Mon, 12 Oct 2026 00:34:50 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko Subject: [PATCH v2 2/2] xen/device-tree: add a helper to dump an FDT in DTS-like format Date: Mon, 12 Oct 2026 09:34:42 +0200 Message-ID: <20261012073442.15819-3-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261012073442.15819-1-oleksii.kurochko@gmail.com> References: <20261012073442.15819-1-oleksii.kurochko@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1791790491-A7ED6AE4-05ACBAE2/10/73395122804 X-purgate-type: spam X-purgate-size: 10913 The device tree Xen builds for dom0/hwdom or for a dom0less domain is only ever consumed by the guest, so a mistake in it surfaces as an obscure failure inside the domain, far away from the code which produced the tree. Add device_tree_dump(). The output follows dtc's format so that a dump can be diffed against the source DTS or fed back to dtc; the value formatting heuristics are ported from dtc's utilfdt_print_data() for that reason. The walk itself goes through libfdt rather than decoding the tag stream by hand as dtc's fdtdump does. Dumping a whole tree is only useful while debugging and costs both code size and a lot of console output, so it is put under its own option, CONFIG_DEVICE_TREE_DUMP. It is separate from CONFIG_DEVICE_TREE_DEBUG because the generated tree is often all that is needed, without the rest of the device tree debug messages. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Dump the device tree generated for dom0/hwdom as well. - Put the dump under its own CONFIG_DEVICE_TREE_DUMP instead of CONFIG_DEVICE_TREE_DEBUG. - Pass the domain to device_tree_dump() and print the "Device tree for" header from it. - Combine isprint() with isascii(), as Xen's isprint() also accepts the characters 0xa0-0xff, unlike the one dtc uses. - Update the commit message. --- --- xen/Kconfig.debug | 10 ++ xen/arch/arm/domain_build.c | 2 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/dom0less-build.c | 3 + xen/common/device-tree/fdt-dump.c | 185 ++++++++++++++++++++++++ xen/include/xen/bootfdt.h | 16 ++ 6 files changed, 217 insertions(+) create mode 100644 xen/common/device-tree/fdt-dump.c diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug index d900d926c555..45cff9dbc467 100644 --- a/xen/Kconfig.debug +++ b/xen/Kconfig.debug @@ -98,6 +98,16 @@ config DEVICE_TREE_DEBUG logged in the Xen ring buffer. If unsure, say N here. +config DEVICE_TREE_DUMP + bool "Dump generated device trees" + depends on DEVICE_TREE_PARSE + help + The device tree Xen generates for dom0/hwdom and for each dom0less + domain is printed on the Xen console in a DTS-like format. + The dump is logged at debug level, so on a non-debug build it is + only shown with "loglvl=all". + If unsure, say N here. + config SCRUB_DEBUG bool "Page scrubbing test" default DEBUG diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 72d531618045..6a20af23e1bb 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1705,6 +1705,8 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) if ( ret < 0 ) goto err; + device_tree_dump(d, kinfo->fdt); + return 0; err: diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile index 9036e455d66a..730d202349eb 100644 --- a/xen/common/device-tree/Makefile +++ b/xen/common/device-tree/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-bindings.init.o obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o +obj-$(CONFIG_DEVICE_TREE_DUMP) += fdt-dump.init.o obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index fcbeb8adbd73..24a9c6b1e3e1 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include #include @@ -587,6 +588,8 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret < 0 ) goto err; + device_tree_dump(d, kinfo->fdt); + return 0; err: diff --git a/xen/common/device-tree/fdt-dump.c b/xen/common/device-tree/fdt-dump.c new file mode 100644 index 000000000000..296ae0d90d12 --- /dev/null +++ b/xen/common/device-tree/fdt-dump.c @@ -0,0 +1,185 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Dump a flattened device tree blob in a DTS-like format. + * + * is_printable_string() and print_value() are derived from + * util_is_printable_string() and utilfdt_print_data() in the device tree + * compiler (dtc). + * + * Copyright 2011 The Chromium Authors, All Rights Reserved. + * Copyright 2008 Jon Loeliger, Freescale Semiconductor, Inc. + * util_is_printable_string contributed by + * Pantelis Antoniou + */ + +#include +#include +#include +#include +#include +#include + +/* Deeper nodes are still printed, but not indented any further. */ +#define DUMP_MAX_INDENT_DEPTH 32 + +/* Indentation, in characters, of a node at depth @depth. */ +static int __init indent_of(int depth) +{ + return 2 * min(depth, DUMP_MAX_INDENT_DEPTH); +} + +static bool __init is_printable_string(const void *data, unsigned int len) +{ + const char *s = data; + const char *se = s + len; + + /* A zero length property, or one which isn't NUL terminated, isn't one. */ + if ( (len == 0) || (s[len - 1] != '\0') ) + return false; + + while ( s < se ) + { + const char *ss = s; + + /* + * Xen's isprint() also accepts the characters 0xa0-0xff, while the + * one dtc uses only accepts ASCII ones. + */ + while ( (s < se) && *s && isascii(*s) && isprint(*s) ) + s++; + + /* Stopped on a non printable character, or the string is empty. */ + if ( (*s != '\0') || (s == ss) ) + return false; + + s++; + } + + return true; +} + +/* + * Print the value of a property, using the same heuristics as dtc: a list of + * NUL terminated printable strings is printed as such, a value which is a + * multiple of 4 bytes as a list of cells, anything else as a byte string. + * + * The caller has already started the line (and with it selected the log + * level), so no XENLOG_* prefix may be used here. + */ +static void __init print_value(const void *data, unsigned int len) +{ + unsigned int i; + + /* Empty property, nothing to print. */ + if ( len == 0 ) + return; + + if ( is_printable_string(data, len) ) + { + const char *s = data; + const char *end = data + len; + + printk(" = "); + while ( s < end ) + { + printk("\"%s\"", s); + s += strlen(s) + 1; + if ( s < end ) + printk(", "); + } + } + else if ( IS_ALIGNED(len, sizeof(fdt32_t)) ) + { + const fdt32_t *cell = data; + + printk(" = <"); + for ( i = 0; i < len / sizeof(*cell); i++ ) + printk("%s0x%08x", i ? " " : "", fdt32_ld(&cell[i])); + printk(">"); + } + else + { + const uint8_t *byte = data; + + printk(" = ["); + for ( i = 0; i < len; i++ ) + printk("%s%02x", i ? " " : "", byte[i]); + printk("]"); + } +} + +static void __init print_properties(const void *fdt, int node, int indent) +{ + int prop; + + fdt_for_each_property_offset ( prop, fdt, node ) + { + const char *name; + const void *data; + int len; + + data = fdt_getprop_by_offset(fdt, prop, &name, &len); + if ( !data ) + { + printk(XENLOG_DEBUG "%*scouldn't read property at offset %d: %s\n", + indent, "", prop, fdt_strerror(len)); + return; + } + + printk(XENLOG_DEBUG "%*s%s", indent, "", name); + print_value(data, len); + printk(";\n"); + } + + if ( (prop < 0) && (prop != -FDT_ERR_NOTFOUND) ) + printk(XENLOG_DEBUG "%*scouldn't walk the properties: %s\n", + indent, "", fdt_strerror(prop)); +} + +void __init device_tree_dump(const struct domain *d, const void *fdt) +{ + int node, depth = 0; + /* Depth up to which nodes are open and still have to be closed. */ + int open_depth = 0; + + printk(XENLOG_DEBUG "Device tree for %pd:\n", d); + printk(XENLOG_DEBUG "/dts-v1/;\n"); + + /* + * fdt_next_node() signals the end of the subtree it was started on by + * making the depth negative, and only returns an error when the blob + * itself is malformed. + */ + for ( node = 0; (node >= 0) && (depth >= 0); + node = fdt_next_node(fdt, node, &depth) ) + { + const char *name = fdt_get_name(fdt, node, NULL); + + /* Close the nodes which aren't a parent of the current one. */ + while ( open_depth > depth ) + printk(XENLOG_DEBUG "%*s};\n", indent_of(--open_depth), ""); + + printk(XENLOG_DEBUG "%*s%s {\n", indent_of(depth), "", + (depth == 0) ? "/" : (name ?: "")); + print_properties(fdt, node, indent_of(depth) + 2); + + open_depth = depth + 1; + } + + while ( open_depth > 0 ) + printk(XENLOG_DEBUG "%*s};\n", indent_of(--open_depth), ""); + + if ( node < 0 ) + printk(XENLOG_DEBUG "The device tree dump is incomplete: %s\n", + fdt_strerror(node)); +} + +/* + * 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/bootfdt.h b/xen/include/xen/bootfdt.h index 0e82ccea2f84..b19e0fa41a1b 100644 --- a/xen/include/xen/bootfdt.h +++ b/xen/include/xen/bootfdt.h @@ -99,6 +99,22 @@ int device_tree_for_each_node(const void *fdt, int node, device_tree_node_func func, void *data); +struct domain; + +/* + * device_tree_dump - print a device tree blob in a DTS-like format + * @d: domain the device tree was generated for. + * @fdt: flat device tree. + * + * The tree is printed at debug log level and is only meant to be used for + * debugging, so it is a no-op unless CONFIG_DEVICE_TREE_DUMP is enabled. + */ +#ifdef CONFIG_DEVICE_TREE_DUMP +void device_tree_dump(const struct domain *d, const void *fdt); +#else +static inline void device_tree_dump(const struct domain *d, const void *fdt) {} +#endif + typedef enum { BOOTMOD_XEN, BOOTMOD_FDT, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 12 07:39:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 07:39:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445875.1661735 (Exim 4.92) (envelope-from ) id 1xGAdA-0007Rp-Ix; Mon, 12 Oct 2026 07:39:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445875.1661735; Mon, 12 Oct 2026 07: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 1xGAdA-0007Ri-GF; Mon, 12 Oct 2026 07:39:32 +0000 Received: by outflank-mailman (input) for mailman id 1445875; Mon, 12 Oct 2026 07:39:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGAd9-0007Rc-3v for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 07:39:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGAd8-004Yjm-DE for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:39:30 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc8eb2-e002-0a2a0a5209dd-0a2a4503e04e-0 for ; Mon, 12 Oct 2026 09:39:30 +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 6acc8eb2-fae8-0a2a45030019-d1558031d4f2-3 for ; Mon, 12 Oct 2026 09:39:30 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a02667ccebso10074185e9.0 for ; Mon, 12 Oct 2026 00:39: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-4a18c85009csm210608885e9.2.2026.10.12.00.39.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 00:39: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=1791790770; x=1792395570; 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=vmbB8deohtfma7MFZruRY7kPcQzqKJfblRZurzIi8WU=; b=XshMj7kS7jq4MsB2SVVY9XyUlccrsjfbrzaJav/qifd7LIfrpuvMf+p5oxB8Vs/GDm UR9pN7Fgk21Z55fGd6ncAGIceJsLJeIKUqXxyAx4dDq0G9M7gfYjyOM9/51ReyvjiDSo vnHmDa0IMJyQy3+4XyoerW3vKjWCcHzv1behMvv7BaNSfxtyqiADwGczvoJEWtQFwgOW YASS7qIY0dKiCE99uWOZ7VqxvNArqMkG6AFPLIx3W3YzUv6/1fWIseFzMf9fpXed4vk3 TF56seEkI1+QWCbr/MF6KTKvgeKv0XgCMkkcTMDElM0i2EuwzCpDWrTeaX6g3Dg3UC0F UKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791790770; x=1792395570; 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=vmbB8deohtfma7MFZruRY7kPcQzqKJfblRZurzIi8WU=; b=gCFRFHrXleKwW5MKlhO0arGl8dWaV8P1yzb5C/IzHyIq4TdrlKKv/Gj/ldXIFAB/yO 8EwCpt+PWWEEVVGINyvb0bNkZdrRRiw9/vBKFvDPGSHzuiMs2aUxy61du98skmZ6j8We B73wdwHl7oJw7BFm2P31kXIpsYRuxGuLiLC2lk5J1OqQJ/GifeWuB3mt4wreA16Tcauo q0DKDu55LR+vS4ItDTSFLusDO7yEuliqf90L/8506D4b+/0Xcs0jEZbI6LdLDJZ4eezI twQZ0rebTny+/LZOIj6c/60AC4x2cy2g8AUBVZ5jRxf2mqB/5RiL8WBqmD7mSdsPZjGw I74A== X-Gm-Message-State: AFq9FYLUNVQC8wAVs/feDvPTjSPO9lyD+1cDyBduciML8Dbz66U6lvtQ XB/LfyTvGb+xhCcmIeDGfc1C2bSFFmnBXfphAxLRc4XGwMytCSIY3tdF X-Gm-Gg: AYBFou36ajcWAAMXLvk3wEWJEY9zg/C2gYs29vM1XaWSKuaP9XIcLL/FH3QovMOjoCw V/QvSAjJvJv4BQQ3Ev+oYlMqaRtV2R/xs8PRYCrLHe/LElJlg3Xlal1trDRr29l+ZBcEIMV9hLm 9bBB/MUDvEJbNbi06qNh+AHAbla2Oj4rd0uNScn8CZRb2672R3ST4HX/hP+43x0aaHs68UdNKQR BkLw0nYl/1dSOdWd8zDVjVSIMfoZweBhlw9iOeQwUZnHJ5CgArLYj6+eIfVgyLv+EERCCjRHcx6 3vOzC6yRGy/ZiOmYO+okKMCbmfvZvwen0Ku2BAuUNHRtLgPfpLqbC5c9JxONyNtXA56AWAF4irb si9YVj2Y7N6auoaYv4nsgVYB++bgKSsZ7rWA273VASpb8IOMAeVpFgyHQM/h87KK+Q1XHXSX/jV qPz8L6/3HiYDRDnpmgs5JoIhTcw6t0BDnXSE4T0a0THjNGqb2Y97cBtUjrAWB5f/6AlxXCOZaUO cmjvcBPZGdwvKyKQ+h36E6gbQbeaSmhGFfCpaTMzx6M469/YisEgaArxah6 X-Received: by 2002:a05:600c:8b28:b0:49f:ff7b:f056 with SMTP id 5b1f17b1804b1-4a18e4a3c24mr139892275e9.9.1791790769674; Mon, 12 Oct 2026 00:39:29 -0700 (PDT) Message-ID: <55dd5d53-34f8-41e2-a5b4-fbac30b791f8@gmail.com> Date: Mon, 12 Oct 2026 09:39:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART To: Zhang Zheng Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <20260928023857.1030884-1-zhangzheng@iscas.ac.cn> <5919f1f2-e24c-4b0e-a7dd-126ac6fbe38f@gmail.com> <3152e70f-881f-4a58-9b2d-df661887dc80@gmail.com> <8836d1e3-77c8-4447-b1ef-132620a71441@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-33051d/1791790770-6F2C84E9-3D9877EB/10/73395122804 X-purgate-type: spam X-purgate-size: 8069 On 10/10/26 5:32 AM, Zhang Zheng wrote: > On Wed, Sep 30, 2026 at 01:22:46PM +0200, Oleksii Kurochko wrote: >> Hello Zheng, >> >> On 9/29/26 5:10 AM, Zhang Zheng wrote: >>> On Mon, Sep 28, 2026 at 08:53:15PM +0800, Zhang Zheng wrote: >>>> On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote: >>>>> >>>>> >>>>> On 9/28/26 10:40 AM, Zhang Zheng wrote: >>>>>> On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote: >>>>>>> >>>>>>> >>>>>>> On 9/28/26 4:38 AM, Zhang Zheng wrote: >>>>>>>> The legacy SBI console extension is planned for deprecation. Replace the >>>>>>>> RISC-V early printk backend with direct access to 8250 UART MMIO. >>>>>>> >>>>>>> Won't it better just to start to add support of newer SBI? It provides >>>>>>> pretty good support + faster as it supports passing of string instead of one >>>>>>> char. >>>>>>> >>>>>> >>>>>> Using the newer SBI DBCN extension would indeed result in a smaller change. At >>>>>> the time, I mainly followed the direction suggested by the TODO and referred >>>>>> directly to the arm64 implementation, from which most of the code was adapted. >>>>> >>>>> I think TODO was written at that way because I missed DBCN (or it wasn't >>>>> ratified at that moment). Considering that it is ratified now ... >>>>> >>>>>> >>>>>>> Also, I think it will lead to lesser changes. >>>>>>> >>>>>> >>>>>> If falling back to SBI console putchar is acceptable, DBCN should work >>>>>> well here. >>>>> >>>>> ... I prefer to use SBI functionality (in the current case DBCN) as maximum >>>>> as possible so if there is no any reason (and I don't see at the moment it) >>>>> which doesn't allow us to use DBCN here, I would prefer to use DBCN. >>>>> >>>> >>>> Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware, >>>> which should ship with a recent version of OpenSBI, I think you are right that >>>> there is no real need to provide a fallback here. >>>> >>>>> If you still want to in the way suggested by TODO then some parts which are >>>>> common between Arm and RISC-V should be moved to common instead of >>>>> introducing them in RISC-V specific folder. >>>>> >>>> >>>> I also tried to make the current patch as minimal as possible, but it would >>>> still end up touching quite a few places. >>>> >>>>> Let me know which approach you are going to follow. If the current one you >>>>> already introduced then I will start to review it, if you will go SBI-way >>>>> then I prefer to wait for your v2. >>>>> >>>>> ~ Oleksii >>>>> >>>> >>>> I misunderstood the TODO comment, I thought that would be the preferred >>>> implementation. Therefore, I will switch to using DBCN and send a v2. >> >> I think I didn’t word it in the best way. >> >> For early debug, I think it would be better to use the SBI function. At some >> point, it doesn’t really matter which one we use, SBI 0.1 or DBCN. If we >> switch to using the UART’s MMIO directly, we wouldn’t need to change the >> privilege mode or perform a context switch, so it should be faster. >> >> However, considering that the early console is mainly used during bring-up, >> it seems like the overhead of an SBI function call isn’t a big price to pay. >> In return, we could potentially have early printk support even for UARTs >> that aren’t currently supported by Xen. >> >>>> >>>> Best regards, >>>> >>>> Zhang >>>> >>> >>> Hi Oleksii, >>> >>> I initially assumed that the DBCN console-write call would wait until the >>> whole string had been transmitted. After checking the SBI specification >>> and the Linux implementation, I found that this is not the case. >> >> I think Linux does roughly the same here: its SBI earlycon >> calls sbi_debug_console_write() (or something like that) in a loop until the >> whole buffer has been written. >> >> Also note that Linux supports both the legacy SBI v0.1 console_putchar >> and DBCN console write for earlycon. It picks DBCN when the firmware >> provides it and falls back to v0.1 otherwise (when CONFIG_RISCV_SBI_V01 >> is enabled). I would really like Xen to do the same rather than drop >> SBI v0.1 support. A board might not support DBCN, or might implement only >> the legacy SBI extensions, and we still want console output there. So we >> should keep both. >> >> I'd go further: we probably don't need to add DBCN support at this point. >> It would be enough to fix the bug you originally hit with the legacy SBI >> call. >> >> Also, in Linux the SBI console is only used as an early (boot) console. >> Once the UART driver has probed and registered a real console, printk >> switches to it and unregisters the boot console (unless keep_bootcon is >> passed). So this switch doesn't cause any issues in Linux, and I don't see >> why it should be a problem in our case either. Switching to DBCN, or the >> approach taken in the current patch, looks to me like it is just hiding an >> issue somewhere else. >> >>> >>> The DBCN Console Write function is explicitly non-blocking. Linux uses DBCN >>> through the HVC console driver, so the DBCN backend remains the owner of the >>> console and the 8250 driver does not subsequently reinitialize the same UART >>> or clear its FIFO. >>> >>> On the other hand, when Linux uses an 8250 earlycon, it accesses the UART >>> directly and waits for UART_LSR_TEMT before the regular 8250 driver takes >>> over. >>> >>> The current Xen setup combines these two paths: early printk uses the SBI >>> console, while the later 8250 driver initializes the same UART. During this >>> handover, the 8250 driver clears the TX FIFO, which can discard characters >>> that were accepted by SBI but have not yet been transmitted by the UART. >> >> Isn't a question just doing flush before switch to 8250 so we won't loose >> anything? (and then again why Linux doesn't have such issue considering that >> they have the similar way of work, even without virtualization) >> >>> >>> Therefore, if Xen is going to use the 8250 driver after early printk, I >>> think the early console should use the same 8250 MMIO path, as Linux does >>> with 8250 earlycon. This keeps the early-console backend consistent with >>> the driver that takes ownership of the UART and allows Xen to wait for >>> UART_LSR_TEMT before reinitialization. >> >> At some point, yes, but then we could lose support for other UARTs that >> OpenSBI could provide out of the box for initial bring-up debugging. >> >> Also, we could have both implementations for early printk (SBI-based and >> MMIO-based), configurable through some option, and allow the user to choose >> which approach to use. But for now, I think we could live with the SBI-based >> implementation (even with support only for old SBI console call for a >> while), as it is more generic, until we actually face a performance issue >> where the MMIO-based approach would start to provide a benefit. >> >> ~ Oleksii > > Hi Oleksii, Hello Zheng, > > Thanks for the clarification and suggestion. > > I have sent v2, keeping the existing SBI early console unchanged. Following > your suggestion, it drains pending TX data before ns16550 reinitializes the > UART. I will check your v2 during this week. > > While bringing up Xen on K3 I also encountered an issue with its > XScale-compatible UART, so v2 includes a separate fix to detect and preserve > the UART_IER_UUE bit. As a result, v2 now mainly fixes UART handover issues > rather than changing the RISC-V early printk implementation. Sounds good to me! > > I'm not sure whether carrying these fixes as v2 of the original series is the > best approach, so please let me know if you have any concerns. I think I don't have any concern but probably it would be better to say that it is v1 as patches don't touch RISC-V specific code anymore. But you mentioned basically why it is v2 in cover letter and it is okay to me, at least. Thanks for v2! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445894.1661749 (Exim 4.92) (envelope-from ) id 1xGBEG-0005eI-Qg; Mon, 12 Oct 2026 08:17:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445894.1661749; Mon, 12 Oct 2026 08: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 1xGBEG-0005eB-Nb; Mon, 12 Oct 2026 08:17:52 +0000 Received: by outflank-mailman (input) for mailman id 1445894; Mon, 12 Oct 2026 08:17:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBEG-0005e5-3h for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:17:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBEE-00FKXj-Ni for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:17:50 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc979b-bab6-0a2a0a5309dd-0a2a45048b56-2 for ; Mon, 12 Oct 2026 10:17:50 +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 6acc97ae-b57f-0a2a45040019-d155dd33d87a-3 for ; Mon, 12 Oct 2026 10:17:50 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48c4649b3aaso870157f8f.2 for ; Mon, 12 Oct 2026 01:17: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-48db9462ebcsm18792340f8f.8.2026.10.12.01.17.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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=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=1791793070; x=1792397870; 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=OHWjBqyyg8UYml9PaDVcL9L7xfErHxLUmSgaLenq97k=; b=XVmbFQmApsACuHzol1oKtLiFf9d/RFS9nFY3a/anv43i2yIAeRF2vVxzZYRZyEKMS6 tBNXADxAtItOj/T7oBCG/dekJ7BQWaJB8NCnVoWtadDTu3qyPu8OoDZ9OUDqxhG+9cxu 0oX63aDkFtRJvyQGFIII+szmXu0/eVO+ag7tNlCNnBhdSLc3PFGXMex/VlD+Om1hav+2 7Ao+rzVpLoDYb7oQNMiUoZ7Se7UHeQ6s8wIdVKVbty1FVGwMPua3b5UjBaQiBrsAHkP3 lwWyoXn21bGWg9BmMHUQ7RiP47Oyx5PGD9btsO5AEwkssYReVi2RVSwJr8oOojDX+6JP 7Sww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793070; x=1792397870; 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=OHWjBqyyg8UYml9PaDVcL9L7xfErHxLUmSgaLenq97k=; b=wuvOhza0a7rButqHxrtS+XPduGm8uTbJGpW7bMiY25K7Pn/gGBZdoerhBlNZ4Txs0s PEKZ1HIq0HVo90gRh11fSdgjD8RDG6YqD9tAzI7eEArE75FJpyWf9ZHpcrGg0GNZ/Bza BDy/nSEcwGpTmlrhkYSQqQS5e18krReE3PaxI86dOZhFqmNJDmEOpdROwAa7bvJ/TJ3B OmWx8E3VHBNxxuA/aQiENOb1oKcah7cUescGwKzcpes98EP05KLcGTVk62hfmdk9JOPS AKOXjyAyyqW3b/CCTcu2br/HVaZfjQj2uhzGgwYer3WYe9qGN3gfBKH2gNkZWHNYvoSg kYgA== X-Gm-Message-State: AFq9FYI0RxnJD+2YlG8aM+HkTuEtViylioxySPAupEE39oorlAO21G0w JPyxEWTsIivAxT6HuiM92XXiHJzC2R2nFJchCeKSBjyVCwwKLZ/TY2+m1mqBuZTwUInkyDQ3gXV L/HyzaA== X-Gm-Gg: AYBFou0hkcERyTSJpcKuVaMAwviSFYEKBUViYnYE2UHJ8GajkPyk1U7+JsQIEJC8yYB wNWo00rJ5ImDx3HVn8fkne3h9ygIShPmr8RyMerw1n1VQLGkSzK7A1OHCKL5GmoflieLuqxHf9R 67RCw3eVxp4M3gb3wn1T1PIijgpir5X900Hf/Cxsy9rN2jwJu5mAm/dqxRVDwUMdKxIzNqI9nTH FpvC+jbAoT06mzj8bMExFU1SHA006Uj92RuzsZ2r8JHLF+kLheC3ampTxIxyGcGE6xdzQrePLjE JqDbVI4v1EiXfQJyKstrgr7AZcy8bJl22kXcIp+pZy7VhCAp0GpfkR/eZ79O7gJpl0xQfgIo6sX E4Au2sTm037LE7BnVxGk0DcIuf8f5NG2cC4HuOSdkEcW089AMBq6HJKF+s8KU6R7+Q8hidXGVMw FuTUwc4FBXbUXmrnE92p5HxRa+K9o+h3uZeb1/knTIApr8J80SrEO0ZxYRX+bgT8l29i92u9E3G N4yieNngn6tJTIuGnHk/0Bcwhh9+zIW4gNW26rq6mfmLQJEF9UI6qHfB1Vx/ks= X-Received: by 2002:a5d:5cc2:0:b0:488:8212:5d73 with SMTP id ffacd0b85a97d-48dbacda836mr12404637f8f.31.1791793069859; Mon, 12 Oct 2026 01:17:49 -0700 (PDT) Message-ID: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Date: Mon, 12 Oct 2026 10:17:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH 00/15] x86: PVH Dom0 loading rework Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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-ebf023/1791793070-518D1B50-72218272/10/78276251493 X-purgate-type: spam X-purgate-size: 1413 The primary goal is to accommodate large initrd-s without requiring people to restrict Dom0's memory just for that. Other issues are being addressed as well, though, and some cleanup is done, in part even outside of the main target area of this series. 01: EFI: guard against oversized modules 02: PV: make better use of assign_pages() 03: setup: break out E820_RAM accumulation 04: setup: special treatment of initrd for PVH Dom0 05: PVH: split pvh_load_kernel() 06: PVH: keep a copy of Dom0's initial E820 map 07: PVH: lift E820 alignment requirement 08: PVH: split pvh_setup_acpi() 09: PVH: split pvh_setup_acpi() 10: PVH: convert find_memory() to using a rangeset 11: PVH: try to map initrd directly into Dom0 12: PVH: heed the kernel in pvh_steal_ram() 13: PVH: prefer smaller E820 regions for stealing from 14: PVH: log Dom0's E820 map earlier 15: PVH: simplify writing of Dom0's RSDP While repeatedly looking at the logs, the memory allocation stats logged further suggested that we may be able to do better in populating the P2M. I was hoping that by going backwards, we might be able to allow for one more 1G mapping. Yet testing that (now omitted) change on two sufficiently different systems resulted in "makes no difference". I conclude (without having proven it) that perhaps earlier during boot we shatter an order-18 page, when perhaps we could avoid doing so. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:19:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:19:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445899.1661759 (Exim 4.92) (envelope-from ) id 1xGBFX-00068L-3X; Mon, 12 Oct 2026 08:19:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445899.1661759; Mon, 12 Oct 2026 08:19: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 1xGBFX-00068E-02; Mon, 12 Oct 2026 08:19:11 +0000 Received: by outflank-mailman (input) for mailman id 1445899; Mon, 12 Oct 2026 08:19:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBFV-000684-Lx for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:19:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBFT-00DmAU-Pl for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:19:07 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc97e2-e002-0a2a0a5209dd-0a2a4508d940-40 for ; Mon, 12 Oct 2026 10:19:07 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc97fb-f659-0a2a45080019-d1558036cd2b-3 for ; Mon, 12 Oct 2026 10:19:07 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a022fee0caso13353915e9.1 for ; Mon, 12 Oct 2026 01:19: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-4a1a1feb78csm54311515e9.0.2026.10.12.01.19.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:19: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=1791793147; x=1792397947; 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=hDxn+GQ1+PpL1OmvTJ3Q3xBKxpxRCK2r29ws8joPDYI=; b=AewDTRGRV4NhLSNRux4atDrtS0pZs07b01McIxTgJowDhklLX4Q+pieBFLCbhXMKds 0SrlHaNoVoI1gX47Cs9jUd8JbxiBwpOwLzvDXMUqR9kd0NKmPEvcAuL5G6NoT5fz0YlX DfLZVjh4wX7L5vaJaMrMc260Hm59bVFCSKJRBxnVLeZCSzpwg60F8EgDyvrVQCVIx872 FJxOmb/XZbW6vXmymtbNOURYslZV+HZufMQhpfdNlPlZeXeAkM4ziuFUwC0SKoo4x2Hp ZM4g0zSEYH1Iz3t/8Fch7euP3pNaHP/Wj6EDki2mNZhJiPnYwImkqZsL0zljwTQ4JkpQ ICyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793147; x=1792397947; 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=hDxn+GQ1+PpL1OmvTJ3Q3xBKxpxRCK2r29ws8joPDYI=; b=QoSPv98vQ16EyZXi5v7dJtjSWYjkL6pmkxBoK14nx9RosAJVJ78TMplnZwq8Yh6EJ3 sv0UdR0BFupHoKnf0D+ZHmNa6ItoQ4pMjQz7Jb7PxLif/wJ4tn2o0PhNVE4xjFcfjmWx b7zIdTLqSLaaZY2+kbASFgRy9bVRu6Rpnd/eLvGXonoYTyW00C3GMwX9bP7GXHJCIqTa b+oThbpAx2jVqxfGtfz5aKvvkHIzXVim27b9p71YVQ+6BVWRSIhHdMpbsSUeB+DXsb9E vnspwoKwUZF9q+P/uCqr2dEzFHYdXfWs6f0s/8sUu7cN1cxcjl6oMIgwMK9vc+OO9uWY gI9g== X-Gm-Message-State: AFq9FYLEBiDDFTWGZHorcfzuwv7CcCDodfnZ+Tc4obKoL1NnaIBZQqjm S0p26z7eTu4SE5PRff7qzH45URRl/n6kTQZe6639c0GPjOeZ4wqJ5H8z+G6Dr3puQAPozTmWC9u kC9Yh3A== X-Gm-Gg: AYBFou1I0scY9dQfsnWqfQ1uauM8dHcuzBtx+APO9qXXYqIYnIZVqL6LiEY7wmfYKej LfDHmLsPJgmBd/5mm9spuaxO6XG64tWOCKwQS7e7WbSnbDl7qUhHOrDwcgHriobZ6wvBxcG+mDX 5i5FSCK1x14FvJy6+178q6bha/hz26URl2Id1pt2FPqUJudpBiGEp30GTMtMMC2CniUoHSyvIJu bNzEZEuD1rkN71HSLa8AWaptOqHb3+buoso2hf4Hc6xibpxLenu2YeJKDtQdzDgHU93d0866DEC KpXy+g5KdPO0tr9EdANAMz52FrC+p0PcCRs27JDOVHchIeH5BQquZOTU37J+beKa/DbTHHF78cz kIOr44un3RNyYT5Pj1Vhg1fPTv2o5gFPfQDFx0g/jqb5B3oJkJcD70DxBVufWEUzUe8bzCmVsEe En04pIB2Os65CPoDsThB73IFKQKBQalzcEPokAmM12oJno3no3Y4N9V3nU2avaRKKmIv1mA7vEj thXPVQOitayBfUwNT5kW0HFaaI3Zl4fkix+BGhrerL9TOk0PatqozqffUgJ0jJMk9sHaBosHg== X-Received: by 2002:a05:600c:3e8d:b0:4a1:7701:f863 with SMTP id 5b1f17b1804b1-4a18e4aeae4mr153478395e9.15.1791793147052; Mon, 12 Oct 2026 01:19:07 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:19:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 01/15] x86/EFI: guard against oversized modules From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski , Daniel Smith References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1791793147-CF55C87B-40CECC3C/10/78276251493 X-purgate-type: spam X-purgate-size: 962 x86/EFI: guard against oversized modules module_t's mod_end field (which we repurpose to hold a module's size) cannot hold values 4Gb and up. Don't let truncation go silently. Signed-off-by: Jan Beulich --- MB and MB2 also constrain module to below 4Gb. The constraint here may be possible to drop once hyperlaunch work has progressed enough to no longer require the intermediate mb_modules[]. --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -736,6 +736,13 @@ static void __init efi_arch_handle_modul place_string(&mb_modules[mbi.mods_count].string, local_name.s); mb_modules[mbi.mods_count].mod_start = file->addr >> PAGE_SHIFT; mb_modules[mbi.mods_count].mod_end = file->size; + + if ( mb_modules[mbi.mods_count].mod_end != file->size ) + { + PrintStr(name); + blexit(L" is too large"); + } + ++mbi.mods_count; efi_bs->FreePool(ptr); } From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:19:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:19:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445902.1661768 (Exim 4.92) (envelope-from ) id 1xGBG2-0006aO-Av; Mon, 12 Oct 2026 08:19:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445902.1661768; Mon, 12 Oct 2026 08: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 1xGBG2-0006aF-6u; Mon, 12 Oct 2026 08:19:42 +0000 Received: by outflank-mailman (input) for mailman id 1445902; Mon, 12 Oct 2026 08:19:40 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBG0-0006Yl-L1 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:19:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBFz-009Avp-NY for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:19:39 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9812-2eae-0a2a0a5409dd-0a2a450ad75a-28 for ; Mon, 12 Oct 2026 10:19:39 +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 6acc981b-f2d2-0a2a450a0019-d155dd31bc09-3 for ; Mon, 12 Oct 2026 10:19:39 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48c45111bebso842116f8f.0 for ; Mon, 12 Oct 2026 01:19: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-48db9463499sm17335044f8f.3.2026.10.12.01.19.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:19: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: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=1791793179; x=1792397979; 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=Ne1we7oWBnWjye1X1yXvq3Rk57Agg+SPNNApBuN6AbA=; b=ZwDY9OygvvmW66jhiSiK++vcedPm0VMw2OrQOppRUvO8N0+FypbsgGeMDi2sILap5f BTlwi9IJqlU7Tkn4p4QXbdb9HnWlTphGFG2fe5EGqyJNwWxPq1puHdVX6rrfM+Jq8iVD glZIDbsX+Qya/VtsAOmib1YV0IIw6/y9i1JPIGuzYb8IFdHDVqVhYsIabhC4pODcs0aB 3inZeZk4XAYA6iOyx/5qejq3Ney1lG7+a6fZvkCwMxZncxPApcgt2AfgNSqSV12FZkV1 dI7F/l6AJNJLWCvBXdjJ6+3Nnsgs1XSflSuZbn/kLT3yxdstJBE61a5ag+bzSEpXoS6y pzZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793179; x=1792397979; 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=Ne1we7oWBnWjye1X1yXvq3Rk57Agg+SPNNApBuN6AbA=; b=L+2vpkLqDnPUXOo8Kb//A6tpn5GeLlNMjxCH6xlmFsE2wGtNhL1cH096X8NIPdB6eF GpieN2HtuWx26uN3jB2nEs75QnfXY9XA6OCwwZakQP+GCYhby6viCkA3I9xX8/ru60iY hAjkRXhGxZL/wXeRFtmjmbtLCP8Mm6scOhj4ymVEpXX6vf4sAseA+FctggWRrcFXe0GZ DZfRwlSHi7dH6WrRIr0A3sbQ9rbtkZQYxu/WmA9HDWpvGGs3madsNFRscWNfGDntZwI0 InckEsx3YKU4SJeqrC5D3ftAyhJDVeiF1XbnG3orp1/Uv6Uulg19Ttfr3TXdzN1D7Ps6 yplQ== X-Gm-Message-State: AFq9FYKzqtpyJ8vbgcVCcFXjPiPe9l8DXX2XOG4JkacKJAz6KuE0BeHS 74EZyEoxlMGNWF/wrV/dsjq3TAxMWpPc7wsfFieF1GRq0l4v+Z5Cue2hb3pvhS2DLa0gDeiUbzU YAs2m0A== X-Gm-Gg: AYBFou1ckr8KaASDUZzeksXLu++A4fr3evbr191SWVSIuZMwQipgMdpz7J1hz2yYIcc tRmbuWmcLysUs3W0r0Sc2GjHIJdL2dFHbuxfnYTVdoRCt15cewxOqO/EB7e51DcfZlA37tGeIfN GFKBy2oQUuWczuVzfwiqDnoy+i8AInZnNbVyuU9SowD0QV3Bru4dm1CxV2hBAPrg7h9GL5UM+nW LXt6/ew2N9V+7VwqJ5pVfjQ1XR2wZZxGJdCQK26XqvoOeVv+0vGNen09dwj8bn4OzdCYJUly4Xz 12hu9kRfErAG9ES4Lz+ZLZ5U6LkJ+F6WJA4w0paOUyHVk7C0E/b6b6Goh9ehKU0ns6/1v5FguqU 0V1Tp2FIW47SfYfPfC3ZG4eJke7M7sXzC0MK/bqcJLTk7aR8pUUKBwdmIuSLU8Dmo73ruKoO3eT qGDt1Tq3RBMXvckMRdU+ahpf11FcTIfBYl5IHzk5GBiFLNrUftqEl8VdbvrcOM2QPShhRkfMxDJ aaO8hVWrZUoskx0MFNP+SQkM9cVccU63F6WDnQpfyz8mI9M6dyUUC6YSdEsmh4= X-Received: by 2002:a05:6000:29ce:b0:48c:6fa4:fc89 with SMTP id ffacd0b85a97d-48dbaadb050mr10446761f8f.12.1791793179001; Mon, 12 Oct 2026 01:19:39 -0700 (PDT) Message-ID: <0c6f1d50-9eb2-44c1-aea5-c366204316e3@suse.com> Date: Mon, 12 Oct 2026 10:19:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 02/15] x86/PV: make better use of assign_pages() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791793179-520C1CFC-BE8775AF/10/78276251493 X-purgate-type: spam X-purgate-size: 1598 As of the referenced commit there's no reason to open-code the loop anymore. With that replaced by a single call, there's then also no point in using the local "mfn" in this code. Amends: 5260e8fb93f0 ("xen: re-define assign_pages and introduce a new function assign_page") Signed-off-by: Jan Beulich --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -618,12 +618,12 @@ static int __init dom0_construct(const s (vinitrd_start - v_start) >> PAGE_SHIFT : domain_tot_pages(d); initrd_mfn = paddr_to_pfn(initrd->start); - mfn = initrd_mfn; count = PFN_UP(initrd_len); #ifdef CONFIG_PV32 if ( d->arch.pv.physaddr_bitsize && - ((mfn + count - 1) >> (d->arch.pv.physaddr_bitsize - PAGE_SHIFT)) ) + ((initrd_mfn + count - 1) >> + (d->arch.pv.physaddr_bitsize - PAGE_SHIFT)) ) { order = get_order_from_pages(count); page = alloc_domheap_pages(d, order, MEMF_no_scrub); @@ -648,9 +648,8 @@ static int __init dom0_construct(const s else #endif { - while ( count-- ) - if ( assign_pages(mfn_to_page(_mfn(mfn++)), 1, d, 0) ) - BUG(); + if ( assign_pages(mfn_to_page(_mfn(initrd_mfn)), count, d, 0) ) + BUG(); /* * We have mapped the initrd directly into dom0, and assigned the * pages. Tell the boot_module handling that we've freed it, so the From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:20:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:20:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445909.1661776 (Exim 4.92) (envelope-from ) id 1xGBGd-00086G-K8; Mon, 12 Oct 2026 08:20:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445909.1661776; Mon, 12 Oct 2026 08: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 1xGBGd-000869-Gz; Mon, 12 Oct 2026 08:20:19 +0000 Received: by outflank-mailman (input) for mailman id 1445909; Mon, 12 Oct 2026 08:20:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBGb-00085j-L6 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:20:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBGb-008dPg-1h for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:20:17 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9836-e002-0a2a0a5209dd-0a2a4505db12-28 for ; Mon, 12 Oct 2026 10:20:16 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc9840-4cb1-0a2a45050019-d1558030b1f5-3 for ; Mon, 12 Oct 2026 10:20:16 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a061a13884so13544685e9.3 for ; Mon, 12 Oct 2026 01: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 ffacd0b85a97d-48db9463230sm19785814f8f.1.2026.10.12.01.20.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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: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=1791793216; x=1792398016; 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=sfs9vuHfnurXyzPhSvFEZTPE91v+YY4wNKDoi7B1ZQk=; b=GKFPipOiLJ9pR56Q7zgEGV8R6CF/z42vKn/KHW1IGo0Lm5QguLjDlKK2BI4ZkIfFz1 5yithxvREin3J2HDLe45Ih2oPaihZ/N7y5XBPXwPCcTo9h/0kQJjkpBUOkIp+/taDWlk 6/zZ++YNM/5PpawBVN2HeGOKs7GqUP7jWUerg9FcLCmAQcQG5GRSxEmC5ZaR7C6XKiyK uj+X9/rH30yrwR9SQXy+/hIoYEKQrSyEec6Z3MGnt4adgXaoABhh63KqqYrhcQebeVc4 TnjruipbCdUXFGi8dkZav8aPq0oJX+Hr1QuGt8aoa2dPa5SJlV6g2U9vR7xQnGJQL7iN hxtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793216; x=1792398016; 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=sfs9vuHfnurXyzPhSvFEZTPE91v+YY4wNKDoi7B1ZQk=; b=A75Q6B7jx2YwV11uNQbKcQeYz5faRibzf9mWlPI3YvHJ0mT4fupGcXP8y7BJ+QhwUA T1LOZjEDlU+hoihxgsVxd01sVQQ6WJbN90K2fwuughd4Fso1Ak3l/7FrAGG2kzOrpBlQ r93X6Mhy5mRBUIipSXOx6BTZy8UlVENRhLCjTUmtD185Tg/Ox9rke80BxAdhGa4VVSkO HoBhiSKfS+U4UqdPR1OPE+6NVRI0NKDf2nppj48yx+wYQuAX2llTattPQ9g62ezOwVFs DoKbw5xRrQANr6qFwPAU7gu/RuTuAgPo2hJ7Ln+NPLf64RCVE62x3n0QnJ5B8kcpm0ui eNYw== X-Gm-Message-State: AFq9FYIb5dSaq2c47fiDksL3F5sE0qnZFkWwJbU5ZYfPbDhw64awQ+/3 UGPzG2o4OQ/bQjO4lto6yZkAr6V65ocUrEIYlEKRs5OaDt24FPEOfwFGW/IGL6urPvsomqx51RP F8UoKpQ== X-Gm-Gg: AYBFou38PSPUN5L43712cvUtG/FqYhRauwaO82+GCE5DtFeSiQGI0hOd2Qm5aUJZad/ rG3W2L2KzVVGoWNBIv+NDF776lFQottN4vO4t03CM9uSbDxZLynOo4igXKPc2zzd5SntHQ+Izc5 oXQ1Ktw382j3yrlmJt7aKXqccHBLPK0knA/jHT9oABo+YRx63x6kr+ty+UqTQ32CRp0exprH+UY sUyZSgnuQ/dbVPGEZgPNVL571A5leUYvLrlZWYjV95kjHY+Bq3j29j2QXEvE3nzZwq7ZFa0lJVg EXD4/5R1p8nvG1YDsuGNQVrwvorV5Ly7Cdg4rDs5tGInuiebg3T4Jg87Dm4a6iA5/1BLG7bcNmn P7TiCjvKogQ4bZixxO4jkA3pLXfq3S21HEP39lobjZi5HPwmNAy1sH2M1/9lYV/skowhF1JguKj sU5aD57Uv66wDh7LOtZfjIkazVMtEixam7v+aryfyb2QosztG6EichCtlsbT8Ywdj54CrbM9ONx TeB+rd6upZOe/ocp2DgOyp8+uPeJ7IXjdY0JwQcUEdkMOmCl5eH8YobYVWBrIo= X-Received: by 2002:a05:600c:3ba5:b0:4a1:70d4:c69 with SMTP id 5b1f17b1804b1-4a18e4c03bbmr187729245e9.28.1791793216076; Mon, 12 Oct 2026 01:20:16 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:20:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 03/15] x86/setup: break out E820_RAM accumulation From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791793216-F58AE2A1-D6C71979/10/78276251493 X-purgate-type: spam X-purgate-size: 2452 We already have two instances of this, and we're about to gain a third. Signed-off-by: Jan Beulich --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1007,6 +1007,17 @@ static unsigned int __init copy_bios_e82 return n; } +static unsigned long __init nr_ram_pages(void) +{ + unsigned long nr_pages = 0; + + for ( unsigned int i = 0; i < e820.nr_map; i++ ) + if ( e820.map[i].type == E820_RAM ) + nr_pages += e820.map[i].size >> PAGE_SHIFT; + + return nr_pages; +} + /* * Calculate the maximum possible size of the dom0 cmdline. Pieces of the * dom0 cmdline optionally come from the bootloader directly, from Xen's @@ -1139,7 +1150,7 @@ void asmlinkage __init noreturn __start_ struct cpu_info *info = get_cpu_info(), *bsp_info; unsigned int initrdidx, num_parked = 0; struct boot_info *bi; - unsigned long nr_pages, raw_max_page; + unsigned long raw_max_page; int i, j, bytes = 0; unsigned long eb_start, eb_end; bool acpi_boot_table_init_done = false, relocated = false; @@ -1491,11 +1502,7 @@ void asmlinkage __init noreturn __start_ memcpy(&boot_e820, &e820, sizeof(e820)); /* Early kexec reservation (explicit static start address). */ - nr_pages = 0; - for ( i = 0; i < e820.nr_map; i++ ) - if ( e820.map[i].type == E820_RAM ) - nr_pages += e820.map[i].size >> PAGE_SHIFT; - set_kexec_crash_area_size((u64)nr_pages << PAGE_SHIFT); + set_kexec_crash_area_size(nr_ram_pages() << PAGE_SHIFT); kexec_reserve_area(); for ( i = 0; i < bi->nr_modules; i++ ) @@ -1862,14 +1869,10 @@ void asmlinkage __init noreturn __start_ (unsigned long)__va(__pa(__2M_rodata_end)), PAGE_HYPERVISOR_RO); - nr_pages = 0; - for ( i = 0; i < e820.nr_map; i++ ) - if ( e820.map[i].type == E820_RAM ) - nr_pages += e820.map[i].size >> PAGE_SHIFT; + total_pages = nr_ram_pages(); printk("System RAM: %luMB (%lukB)\n", - nr_pages >> (20 - PAGE_SHIFT), - nr_pages << (PAGE_SHIFT - 10)); - total_pages = nr_pages; + total_pages >> (20 - PAGE_SHIFT), + total_pages << (PAGE_SHIFT - 10)); /* Sanity check for unwanted bloat of certain hypercall structures. */ BUILD_BUG_ON(sizeof_field(struct xen_platform_op, u) != From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:20:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:20:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445912.1661785 (Exim 4.92) (envelope-from ) id 1xGBH1-0008V0-Rr; Mon, 12 Oct 2026 08:20:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445912.1661785; Mon, 12 Oct 2026 08:20: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 1xGBH1-0008Uq-OV; Mon, 12 Oct 2026 08:20:43 +0000 Received: by outflank-mailman (input) for mailman id 1445912; Mon, 12 Oct 2026 08:20:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBH0-0008Uc-03 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:20:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBGz-004g3v-Ck for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:20:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9859-2eae-0a2a0a5409dd-0a2a450bedc8-0 for ; Mon, 12 Oct 2026 10:20:41 +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 6acc9859-b7e8-0a2a450b0019-d155dd30b495-3 for ; Mon, 12 Oct 2026 10:20:41 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48af27fe287so1350063f8f.0 for ; Mon, 12 Oct 2026 01:20: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-48db9ade914sm16905502f8f.54.2026.10.12.01.20.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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=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=1791793241; x=1792398041; 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=X5vwWawFBiTfx1OYyOkPcGB9kPAiPFbLrv4Ssm0jEl8=; b=BYpKX9dvvAadksgNtMT3z3XoYXnX6iBK1qJ57UZYkvzUJnkc53RNHWZ1RcbIFJqoXD xA96vntFsG4M+/2bi9L0BuXzMXnFgLEQLQbspWcK9q9khNUMtZjd1nTEZPGPACTT4iH7 rFeG79cIj19GtFlmhMXGKzb0zidBMaIlp3KBXJK5cEGAgix0IgGSI6+tbMlmzj4vCIOA t84G7EdNgor9x0LEwngX3UfSvqpdYieUBTY8EIkD2+aN4oRA77wsfqKydBBPz5Lkw2ol jkkk/Olnw6FmCq/IO+4Hm9Uk4DBBSOUBjv9Tx70wHRQYofDVKmhnANiypH1cVRx01BX4 ifbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793241; x=1792398041; 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=X5vwWawFBiTfx1OYyOkPcGB9kPAiPFbLrv4Ssm0jEl8=; b=S2lur/SJrUlFzhVWIIShoM0HxNwplueSQV6P4FZBTD+tV41R8N+dqd6QtuM7NKtzJc 7+ypQ5kC0xGes1LjKbdseAcVoAMmo5kJVr3jhp4a6fhItuW22Y8X+VDpYJK/tnb3ZWT6 sdpfTVEyGaO2SsNuE809xOMZNE9rS0WTO5yECWlU2K7GadzVxcjIyt2fbT8DUAh5CjQL XuqxW0ha0XpQkaVHA3o2LrRqZ7RHmuWDz1ONy+gCkU08xlwlSMuheCTmlzUgrvUhu/FO OkORU2dFIfwtJi1rFKSXl1sR6pi4SoHLbMy1zdhU0bhu6dWYHjtdlpsLo9MIR4d5LxzJ l5xA== X-Gm-Message-State: AFq9FYL0XYQqJe8/g4Zl4s6EOIb+dopMti7ac8tjNcYzkQX1sT4AV0bN bPy1bk+1oBBU/42x6JZsTpzqaiGkxVmza011UGzL0BxTPMm98+P/EY9lHpenvQrSUqih5FBFxCn rzotCrw== X-Gm-Gg: AYBFou3Vs2D/2PMBrsswDNedb+m6fHhRYIEGWJIJWxJCnPGf14u39Riqjk3PhSgn5km fVydlcrYYBuTbd0h8wL6j/pKyY37WllNHgTHNJbLMMEJP2SUgSNCZZBXUGJmea2JwvV2rrCOV82 QnfOPL/xbH4Tm1xqE7JNxyPTOPPczhvQT8+K1g17qCcEHIdEcis6B/5PL0iyiPiJM101hUAnltp 2F5q8fddOSzF1+z5MBV33zZni4cNvR0bpqFJ7ca84lq0uW4R+daGxFsQELX6x8xrOjwBkp1YiZx cggfLVGW6EYAsNUMTQfgltzQMFOcqBw3NIOdEh8UVv+R3D5RRQ/oAvS5kU7KjvKZMbkBYiDSjiS dY4SttWBnJ39RrIp5fNMd8viDjbB9rIpG6gwjZYgjEFWEZLZebMT1tbCwmWj0wC1nmLcXXyWVh2 h00qlxTsyQb0Fc5x/Ze6jyUcVY1slvdgNgU+a5myLdVB/O1JrzSM7ZcZJkx4bTJfs5nMTdjM7Qc dO6VrkOFKoa3ovbwXfMMo+1aNqaGeIC0I3zyT+y8BSdyXphMA89mA/cVhaChjY= X-Received: by 2002:a05:600c:3ba8:b0:4a0:174:579e with SMTP id 5b1f17b1804b1-4a18e4ab221mr186397255e9.28.1791793240572; Mon, 12 Oct 2026 01:20:40 -0700 (PDT) Message-ID: <125982a7-f491-4a10-98e9-d31f9f3b6444@suse.com> Date: Mon, 12 Oct 2026 10:20:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 04/15] x86/setup: special treatment of initrd for PVH Dom0 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791793241-1A6DA9EA-1A5D5F54/10/78276251493 X-purgate-type: spam X-purgate-size: 5686 Dealing with large initrd-s is problematic in two ways: We needlessly copy around a large chunk of data, and our calculation of how much memory to give Dom0 assumes the space taken by the initrd is actually available at the time of populating Dom0's P2M. As a first step, make effort during early boot to try to place the initrd in a chunk of memory that's a multiple of 1Gb (or, if not available / not possibly going to fit, in a chunk a multiple of 2Mb in size). This may (but generally won't) result in more copying, which we simply need to accept. Record (and use) the extra space allocated in (as) headroom, which then needs accouting for in pvh_load_kernel(). Signed-off-by: Jan Beulich --- Not being able to check bm->kind is of course not very nice. The field is only set quite a bit later, and that setting can - afaict - not be moved ahead of the call to xsm_multiboot_init(). The bumping of mask to L3's in __start_xen() transiently breaks booting of Dom0 with overly much memory assigned to it. That'll be resolved when the headroom space is properly dealt with (consumed into Dom0, or freed). Therefore this patch and everything up to the one adding the consuming code want committing together, or addition of that conditional wants delaying until that later change. Simply using nr_ram_pages()' return value is of course a pretty raw estimate. We could e.g. also subtract Xen's image size and, perhaps more relevant, an estimate of frame_table[]. --- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -445,6 +445,20 @@ unsigned long __init dom0_compute_nr_pag return nr_pages; } +/* + * A simplistic sibling of dom0_compute_nr_pages(), for obtaining a very early + * estimate. + */ +unsigned long __init get_dom0_size(unsigned long avail) +{ + if ( CONFIG_DOM0_MEM[0] && !dom0_mem_set ) + parse_dom0_mem(CONFIG_DOM0_MEM); + + return get_memsize(memsize_gt_zero(&dom0_size) ? &dom0_size + : &dom0_max_size, + avail); +} + static void __init process_dom0_ioports_disable(struct domain *dom0) { unsigned long io_from, io_to; --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -653,7 +653,8 @@ static int __init pvh_load_kernel( void *image_base = bootstrap_map_bm(image); void *image_start = image_base + image->arch.headroom; unsigned long image_len = image->size; - unsigned long initrd_len = initrd ? initrd->size : 0; + unsigned long initrd_len = + initrd ? initrd->size - initrd->arch.headroom : 0; size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0; const char *initrd_cmdline = NULL; struct elf_binary elf; @@ -751,7 +752,8 @@ static int __init pvh_load_kernel( if ( initrd != NULL ) { - rc = hvm_copy_to_guest_phys(last_addr, __va(initrd->start), + rc = hvm_copy_to_guest_phys(last_addr, + __va(initrd->start + initrd->arch.headroom), initrd_len, v); if ( rc ) { --- a/xen/arch/x86/include/asm/setup.h +++ b/xen/arch/x86/include/asm/setup.h @@ -68,4 +68,6 @@ extern bool opt_dom0_verbose; extern bool opt_dom0_cpuid_faulting; extern bool opt_dom0_msr_relaxed; +unsigned long get_dom0_size(unsigned long avail); + #endif --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1608,6 +1608,40 @@ void asmlinkage __init noreturn __start_ struct boot_module *bm = &bi->mods[j]; unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size); + /* + * For PVH Dom0 try to place the initrd in a full multi-Gb (or + * multi-2Mb) chunk, such that assigning the pages directly can + * be done while still using superpage mappings. + */ + if ( opt_dom0_pvh && j == 1 /* bm->kind == BOOTMOD_RAMDISK */ ) + { + if ( get_dom0_size(nr_ram_pages()) >= PFN_DOWN(GB(2)) ) + mask = (1UL << L3_PAGETABLE_SHIFT) - 1; + + for ( ; mask > PAGE_SIZE; mask >>= PAGETABLE_ORDER ) + { + if ( !(bm->start & mask) && bm->arch.relocated ) + break; + + size = PAGE_ALIGN(bm->size - bm->arch.headroom); + end = e; + do { + end = consider_modules((s + mask) & ~mask, end & ~mask, + (size + mask) & ~mask, bi->mods, + bi->nr_modules + relocated, j); + } while ( (end & mask) && end > s ); + + if ( highmem_start && end > highmem_start ) + break; + + size = (size + mask) & ~mask; + bm->start += bm->arch.headroom; + bm->size -= bm->arch.headroom; + bm->arch.headroom = size - PAGE_ALIGN(bm->size); + goto move_module; + } + } + if ( bm->arch.relocated ) continue; @@ -1620,6 +1654,7 @@ void asmlinkage __init noreturn __start_ if ( s < end && (bm->arch.headroom || (end - size) > bm->start) ) { + move_module: move_memory(end - size + bm->arch.headroom, bm->start, bm->size); bm->start = (end - size); bm->size += bm->arch.headroom; From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:21:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:21:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445918.1661793 (Exim 4.92) (envelope-from ) id 1xGBHY-0000fe-29; Mon, 12 Oct 2026 08:21:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445918.1661793; Mon, 12 Oct 2026 08: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 1xGBHX-0000fX-VS; Mon, 12 Oct 2026 08:21:15 +0000 Received: by outflank-mailman (input) for mailman id 1445918; Mon, 12 Oct 2026 08:21:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBHV-0000bZ-Qy for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:21:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBHV-00B8Vx-7o for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:21:13 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc986a-bab6-0a2a0a5309dd-0a2a4503cc60-38 for ; Mon, 12 Oct 2026 10:21:13 +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 6acc9879-fae8-0a2a45030019-d155dd35b410-3 for ; Mon, 12 Oct 2026 10:21:13 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48af27fe287so1350592f8f.0 for ; Mon, 12 Oct 2026 01:21: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-48db9acf12bsm18695082f8f.46.2026.10.12.01.21.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:21: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=1791793273; x=1792398073; 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=uTkWmDigDdOyowJ4/rV8AMuW49VhKWzJFUPn6PZy8mI=; b=gJHvyo6LYRJ93cUay1J38G96BrjzCMZ6HlDmH8VT6ChbBOuMs+Alq/HiWaucdc+CEt zlafGHGqzajjpHAEvSsIBbuyCFw/kyKiFIEfH4tIBfCswkAooQa5zRmaNAFnJhDn+bBK NJwMxCgU7aBht+YGt8q5qlWIoo9uO/4VUWE0gS6ux9E1zstoXnGs3YcXHv/s/WJgTqpf bBNWFwt/YG7FymIUEwBfZ4wjI8frjwFIxrKR6VckqE02MCCLix8AD3PMorPPU46mJ5Of 4lhiSqvlKftrA5H3jBNmo6gkxWdFYFRuyIzZ7zcI4WU0ASEAtc7AVsmDzpwmTC/PlC8i e7Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793273; x=1792398073; 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=uTkWmDigDdOyowJ4/rV8AMuW49VhKWzJFUPn6PZy8mI=; b=d8Cy/KdJsVcl/eSwEQ30e3wv64LrAcs1o2eLp/+akwtP18T2u5q/bn+QmQIRdyP01v GLxyMQg5Exq2F/HQXWOylYbbR+csUPlbugZNHt2xjw/usQVSObw7+2FEufjdTQsMvUlE +EVLFVvYBGBr2+Qbyp7W80JKXlYPxUL/iQlp01In1WLtS3FmNGyS9VocmVOgtchsvEmp HWdHjBcFOCzbeuz56LgRbYsl6nCHywTs9aIDe++37Z0hKxU5lYDGy7+XRDh1fzmEc2fd UDqGELbmwtQ5lYHUlzIknGuOBHYf2Taa+SZTJOrglk/xV9Qv2vk5jB7O9mOtueXENGvS /Uxg== X-Gm-Message-State: AFq9FYJ0BLwO/POeiEm9elwSP2UHjKwOfaSIv+N9EaV+JpSBvECmw00n idZRs21vDQf9T3ruK0l1rzPRnayPC30q3OldlFKZlfLCvtkzj7zfm2xesPWv5Dyle1SWFQEFVxC UeztRTg== X-Gm-Gg: AYBFou2o1KUoBtv0YG/MBCu1AJTaCcX/uyhsVIM9DGqjY/Nk5JiZkOzrqAIKG9mMXff c3KbU31ZSMswSgBDkecuv4OJa8lj1z/X7MVVzzncaywUNVpSvp7mLaJV9j2ZJ8YTAFpVnHesRRc le1akq1h660ErVD/HzrbeszBzf38btlwDPymYJLlg5q7EuiQSaYUHqKgypZ5lRvHQA/t36JkdZm AM6XP4pzrXPhLEFjfZ4mnl6y7KttffSicngckjfNjj/hRNVlg2SUEVi8jW/5y/djDGDcrxosv/8 x9V+8KSY8BnF0NhQ1LhJzrX4qYjqsf2nNVBav7KdtS124AleW6CEe7t9zW6lXW+E40F6WFhjSC0 FBJAA7RGqB9DaWaTAQ8zAlyiIGxy7+uB8G6D74W5ZV2xemCD4YpMdNhxhYDAu5kf210uK0Iaw+n ahKe14X0NZTeSHj7UiFusRDuuAzTluOqv3TIi3Y44fm8lnn8nj+d58V06C9XNJLEtB7RQ6AeB8R bjftzIn4dUpS6ttzRObPdU4lFFOFWGKqTcafmSMrfBdmuUZ0jkGJRw983RpsGbQKGeosL6/Tw== X-Received: by 2002:a05:6000:40ce:b0:48d:bb54:77e7 with SMTP id ffacd0b85a97d-48dbb547b24mr16271468f8f.29.1791793272485; Mon, 12 Oct 2026 01:21:12 -0700 (PDT) Message-ID: <3ff41e03-b30b-43c0-9a20-28cdd9ae30d0@suse.com> Date: Mon, 12 Oct 2026 10:21:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 05/15] x86/PVH: split pvh_load_kernel() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1791793273-766FB4E9-620E0EF0/10/78276251493 X-purgate-type: spam X-purgate-size: 6834 All E820 manipulations want to happen before the initrd is placed. As a first step, split placing the kernel from actually loading it. Then placement of other data (ACPI, VMX) can be inserted between kernel placement and P2M population (followed by the loading of the kernel). Signed-off-by: Jan Beulich --- If need be, moving the "elf" local variable to dom0_construct_pvh() could of course further be split off. Just that this by itself doesn't make much sense. --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -644,26 +644,17 @@ static bool __init check_and_adjust_load return true; } -static int __init pvh_load_kernel( - const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr) +static int __init pvh_place_kernel( + const struct boot_domain *bd, + struct elf_binary *elf, + paddr_t *entry) { struct domain *d = bd->d; struct boot_module *image = bd->kernel; - struct boot_module *initrd = bd->initrd; void *image_base = bootstrap_map_bm(image); void *image_start = image_base + image->arch.headroom; unsigned long image_len = image->size; - unsigned long initrd_len = - initrd ? initrd->size - initrd->arch.headroom : 0; - size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0; - const char *initrd_cmdline = NULL; - struct elf_binary elf; struct elf_dom_parms parms; - size_t extra_space; - paddr_t last_addr; - struct hvm_start_info start_info = { 0 }; - struct hvm_modlist_entry mod = { 0 }; - struct vcpu *v = d->vcpu[0]; int rc; if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 ) @@ -672,19 +663,19 @@ static int __init pvh_load_kernel( return rc; } - if ( (rc = elf_init(&elf, image_start, image_len)) != 0 ) + if ( (rc = elf_init(elf, image_start, image_len)) != 0 ) { printk("Unable to init ELF\n"); return rc; } if ( opt_dom0_verbose ) - elf_set_verbose(&elf); - elf_parse_binary(&elf); - if ( (rc = elf_xen_parse(&elf, &parms, true)) != 0 ) + elf_set_verbose(elf); + elf_parse_binary(elf); + if ( (rc = elf_xen_parse(elf, &parms, true)) != 0 ) { printk("Unable to parse kernel for ELFNOTES\n"); - if ( elf_check_broken(&elf) ) - printk("%pd kernel: broken ELF: %s\n", d, elf_check_broken(&elf)); + if ( elf_check_broken(elf) ) + printk("%pd kernel: broken ELF: %s\n", d, elf_check_broken(elf)); return rc; } @@ -697,20 +688,43 @@ static int __init pvh_load_kernel( if ( (rc = initdom_check_parms(d, &parms)) != 0 ) return rc; - /* Copy the OS image and free temporary buffer. */ - elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base); - elf.dest_size = parms.virt_kend - parms.virt_kstart; + elf->dest_base = (void *)(parms.virt_kstart - parms.virt_base); + elf->dest_size = parms.virt_kend - parms.virt_kstart; - if ( !check_and_adjust_load_address(d, &elf, &parms) ) + if ( !check_and_adjust_load_address(d, elf, &parms) ) return -ENOSPC; - elf_set_vcpu(&elf, v); - rc = elf_load_binary(&elf); + *entry = parms.phys_entry; + + return 0; +} + +static int __init pvh_load_kernel( + const struct boot_domain *bd, + struct elf_binary *elf, + paddr_t *start_info_addr) +{ + struct domain *d = bd->d; + struct boot_module *initrd = bd->initrd; + unsigned long initrd_len = + initrd ? initrd->size - initrd->arch.headroom : 0; + size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0; + const char *initrd_cmdline = NULL; + size_t extra_space; + paddr_t last_addr; + struct hvm_start_info start_info = { 0 }; + struct hvm_modlist_entry mod = { 0 }; + struct vcpu *v = d->vcpu[0]; + int rc; + + /* Copy the OS image and free temporary buffer. */ + elf_set_vcpu(elf, v); + rc = elf_load_binary(elf); if ( rc < 0 ) { printk("Failed to load kernel: %d\n", rc); - if ( elf_check_broken(&elf) ) - printk("%pd kernel: broken ELF: %s\n", d, elf_check_broken(&elf)); + if ( elf_check_broken(elf) ) + printk("%pd kernel: broken ELF: %s\n", d, elf_check_broken(elf)); return rc; } @@ -724,7 +738,7 @@ static int __init pvh_load_kernel( if ( initrd ) { - size_t initrd_space = elf_round_up(&elf, initrd_len); + size_t initrd_space = elf_round_up(elf, initrd_len); if ( initrd->arch.cmdline_pa ) { @@ -741,9 +755,9 @@ static int __init pvh_load_kernel( initrd = NULL; } - extra_space += elf_round_up(&elf, cmdline_len); + extra_space += elf_round_up(elf, cmdline_len); - last_addr = find_memory(d, &elf, extra_space); + last_addr = find_memory(d, elf, extra_space); if ( last_addr == INVALID_PADDR ) { printk("Unable to find a memory region to load initrd and metadata\n"); @@ -763,7 +777,7 @@ static int __init pvh_load_kernel( mod.paddr = last_addr; mod.size = initrd_len; - last_addr += elf_round_up(&elf, initrd_len); + last_addr += elf_round_up(elf, initrd_len); if ( initrd_cmdline ) { size_t len = strlen(initrd_cmdline) + 1; @@ -796,7 +810,7 @@ static int __init pvh_load_kernel( * Round up to 32/64 bits (depending on the guest kernel bitness) so * the modlist/start_info is aligned. */ - last_addr += elf_round_up(&elf, cmdline_len); + last_addr += elf_round_up(elf, cmdline_len); if ( initrd != NULL ) { @@ -820,7 +834,6 @@ static int __init pvh_load_kernel( return rc; } - *entry = parms.phys_entry; *start_info_addr = last_addr; return 0; @@ -1338,6 +1351,7 @@ int __init dom0_construct_pvh(const stru { paddr_t entry, start_info; struct domain *d = bd->d; + struct elf_binary elf; int rc; printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id); @@ -1375,6 +1389,13 @@ int __init dom0_construct_pvh(const stru iommu_hwdom_init(d); + rc = pvh_place_kernel(bd, &elf, &entry); + if ( rc ) + { + printk("Failed to place Dom0 kernel\n"); + return rc; + } + rc = pvh_populate_p2m(d); if ( rc ) { @@ -1382,7 +1403,7 @@ int __init dom0_construct_pvh(const stru return rc; } - rc = pvh_load_kernel(bd, &entry, &start_info); + rc = pvh_load_kernel(bd, &elf, &start_info); if ( rc ) { printk("Failed to load Dom0 kernel\n"); From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:21:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:21:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445925.1661803 (Exim 4.92) (envelope-from ) id 1xGBID-0001Cy-E8; Mon, 12 Oct 2026 08:21:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445925.1661803; Mon, 12 Oct 2026 08: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 1xGBID-0001Cr-Av; Mon, 12 Oct 2026 08:21:57 +0000 Received: by outflank-mailman (input) for mailman id 1445925; Mon, 12 Oct 2026 08:21:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBIC-0001BS-65 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:21:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBIB-00B8gn-In for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:21:55 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc989c-bab6-0a2a0a5309dd-0a2a4504af40-20 for ; Mon, 12 Oct 2026 10:21:55 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc98a3-b57f-0a2a45040019-d155dd2ac597-3 for ; Mon, 12 Oct 2026 10:21:55 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48b042c0728so264404f8f.1 for ; Mon, 12 Oct 2026 01:21: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 ffacd0b85a97d-48db9ab981asm18612998f8f.30.2026.10.12.01.21.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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: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=1791793315; x=1792398115; 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=jW8u2BaMdN617mSpoQPZYCC4FPlFgwFVGfByY61ToiY=; b=NqiUHkKuQh/iVYCQ4kakFXUxmOUj/uT+GdVbIj7zixmTmzdZZvpgYPNqYRMEZ8REwz 7QxU50czEO/SmLWiaDTkfJFObosNE0ce5oLNlmb1h0fWvdnBUT2kDHj6yFhVYWwn5CqZ x1stdj2VeeIF25EH0f7luahvpvFqWC7BAVx3YXJ2SY+P2eoIOtgsQVkTwLLPd5ehhru8 PtdlV+yWfseIFFii+ayF84HAR48vsWgcvikS62+akHJ/afX1YmtrVoyZIkqJporuns0v ztZ/cFoYMDeJfQywbQMbhJbEBTF7oLj1yZPRsCxzqKrFppJpbwjqEX7QxvxnYr+7clPN DgVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793315; x=1792398115; 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=jW8u2BaMdN617mSpoQPZYCC4FPlFgwFVGfByY61ToiY=; b=ygcyypx64REWbE096u/IV6pl7ye9z3Ntyj6cX2yAGr5iAHIIkgw+4xUKs0IkFmAi1A KBkq4rIg6CBKCFHFSOqJhp3jOtUY2Jmkyd7subrfU9/wtpYbBcRwe/i0/gX32RotUAYR gsdZVrQ0Y6RhRYw7n92X+J4Ts6OH90FevvbX78gjvst8lzDfU9ZrNUAArIFdR69AadIx Hti9Br1c+QE/WFjf9pTbH8qVl0AQn47No68bKsq5u1OMe+zHFFBP+TXTYkwTgumCbPYA XYMywQmI61/ueZa5k/wZlw0pkbv+VR9hfXpEu0f7gukFoRBfw0DWY4X54S02mYQ9uYhn lcqg== X-Gm-Message-State: AFq9FYLDeOHNziiuNyNxk7wzWb27dnoLCfsE7pfLxmObJeBbCKKdxpBl zUS2fIFTb7nWA6hvuILM2NqFwd/LPDiTQ8/ktOwLLc/p2yb1XbC4E7nm7tj4whZZLuLnLutQ4ZM htehScw== X-Gm-Gg: AYBFou39ivYtZVxKKKXXPjS/BnDPMtuPzBcCvWlB9lBjBc3zVOuLjbZLdDTYYelKXVR OWdk4BipFvHImPl3F2lQRGj+Ex0q2rRF0flbjRYEi6BNeinwAoOWdwctrKCgTytFzlq75dDRd0j zhFXh9E7ZQDesE/RhFKVnJkdLYBaQ/TvlaZvBgJZUXilrmTKIy2sf5+a/om5y6a5JSXocH+XNvX 5LqRedPG85Rs/0lF8Qra84jPcO7zCZqULncSsvj2JotgPPRO8vGPfL8PZvT3qNHcS6LdrGMXtYh ORGpvh4R/CkvEzlQAD8wIOsoVw44ClkbFahVFIJr6AzmTPv12iFZ3Y7TT6HvyEf8jB3cP/qrChs YrUcLwacq6rovnwkgO3vBC/qojqT/iHgPsoP50TUEUa1kJrxL/bQZM5FmdewZ5G5y+8HTk5UUq1 X8/Ro7jAF0711LZC1KflDK4uJY+lNIYeZUem0Ns2IfXfppqmgN8cnbfwuVnn8TpiaDMBTKqGhlE Tfb4WMDpE04peqdZMflFbPs4Hk8leegz/HK1CeTr061MNVx7yj5HlfWEkFDkmc= X-Received: by 2002:a05:6000:2610:b0:48b:60a:760c with SMTP id ffacd0b85a97d-48dbacdbca4mr15772871f8f.31.1791793314718; Mon, 12 Oct 2026 01:21:54 -0700 (PDT) Message-ID: <575ec1bc-764c-4016-a584-a79e57817d9a@suse.com> Date: Mon, 12 Oct 2026 10:21:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791793315-C0CDFB50-C602F82D/10/78276251493 X-purgate-type: spam X-purgate-size: 3511 pvh_populate_p2m() needs to populate RAM according to the initial map established, prior to any stealing by pvh_steal_ram(). Subsequently the invocations of those functions will (need to) move ahead of pvh_populate_p2m(), so what to act on is no longer Dom0's memory map at the time of invocation. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -13,6 +13,7 @@ #include #include #include +#include #include @@ -413,7 +414,10 @@ static void __init pvh_init_p2m(struct d } while ( preempted ); } -static int __init pvh_populate_p2m(struct domain *d) +static int __init pvh_populate_p2m( + struct domain *d, + const struct e820entry *e820, + unsigned int nr_e820) { struct vcpu *v = d->vcpu[0]; unsigned int i; @@ -421,15 +425,15 @@ static int __init pvh_populate_p2m(struc #define MB1_PAGES PFN_DOWN(MB(1)) /* Populate memory map. */ - for ( i = 0; i < d->arch.nr_e820; i++ ) + for ( i = 0; i < nr_e820; i++ ) { unsigned long addr, size; - if ( d->arch.e820[i].type != E820_RAM ) + if ( e820[i].type != E820_RAM ) continue; - addr = PFN_DOWN(d->arch.e820[i].addr); - size = PFN_DOWN(d->arch.e820[i].size); + addr = PFN_DOWN(e820[i].addr); + size = PFN_DOWN(e820[i].size); rc = pvh_populate_memory_range(d, addr, size); if ( rc ) @@ -438,11 +442,11 @@ static int __init pvh_populate_p2m(struc if ( addr < MB1_PAGES ) { uint64_t end = min_t(uint64_t, MB(1), - d->arch.e820[i].addr + d->arch.e820[i].size); + e820[i].addr + e820[i].size); enum hvm_translation_result res = hvm_copy_to_guest_phys(mfn_to_maddr(_mfn(addr)), mfn_to_virt(addr), - end - d->arch.e820[i].addr, + end - e820[i].addr, v); if ( res != HVMTRANS_okay ) @@ -1352,6 +1356,8 @@ int __init dom0_construct_pvh(const stru paddr_t entry, start_info; struct domain *d = bd->d; struct elf_binary elf; + struct e820entry *orig_e820; + unsigned int nr_orig_e820; int rc; printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id); @@ -1389,6 +1395,15 @@ int __init dom0_construct_pvh(const stru iommu_hwdom_init(d); + nr_orig_e820 = d->arch.nr_e820; + orig_e820 = xvmalloc_array(struct e820entry, nr_orig_e820); + if ( !orig_e820 ) + { + printk("No memory for copy of E820 map (%u entries)\n", nr_orig_e820); + return -ENOMEM; + } + memcpy(orig_e820, d->arch.e820, nr_orig_e820 * sizeof(*orig_e820)); + rc = pvh_place_kernel(bd, &elf, &entry); if ( rc ) { @@ -1396,13 +1411,15 @@ int __init dom0_construct_pvh(const stru return rc; } - rc = pvh_populate_p2m(d); + rc = pvh_populate_p2m(d, orig_e820, nr_orig_e820); if ( rc ) { printk("Failed to setup Dom0 physical memory map\n"); return rc; } + xvfree(orig_e820); + rc = pvh_load_kernel(bd, &elf, &start_info); if ( rc ) { From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:22:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:22:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445932.1661812 (Exim 4.92) (envelope-from ) id 1xGBIj-0001dw-LB; Mon, 12 Oct 2026 08:22:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445932.1661812; Mon, 12 Oct 2026 08:22: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 1xGBIj-0001dp-IA; Mon, 12 Oct 2026 08:22:29 +0000 Received: by outflank-mailman (input) for mailman id 1445932; Mon, 12 Oct 2026 08:22:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBIi-0001dc-C3 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:22:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBIh-008dsg-OY for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:22:27 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc98b2-bab6-0a2a0a5309dd-0a2a4507d932-46 for ; Mon, 12 Oct 2026 10:22:27 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc98c3-b4ea-0a2a45070019-d155802ce833-3 for ; Mon, 12 Oct 2026 10:22:27 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49d05d51553so9743465e9.2 for ; Mon, 12 Oct 2026 01:22: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-4a18bf214a1sm311753545e9.7.2026.10.12.01.22.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:22: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: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=1791793347; x=1792398147; 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=hE/SXNVKI/0qWDwe9Mw7V0YXt4dz6aAjn4Zm0MO3tsw=; b=M/1h30q63zjPCY97yk1NVLJO3vnCjVFisrcqNQ7hd7sjEPZxuU46HFJHVdh7xwTW0b XyjtWHITkHfYzn+LF+zyy48zxt0uOKpSz2rK9Ft2LWhVknPWFALGBtTRQELPxcxjbhh/ 5JcMrv8mO/wms7WCpJnSGHtAq99gpUBo6c1mZoAcW+0oWBj+QQCWDcfIG3cWOUCdb/YG 4hDKwJ/s6yAc5JMJbXS31IKE9e8WYkXcW5eebZxmO3eCJjTjnWy269LeqAkUGvrfGwMy g+6TU2SFsQYOeizMIL8yi5jYVGV0XcLIVrnpZNHjGah7BgZUh8C1KluxKtUK3z4not60 EtVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793347; x=1792398147; 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=hE/SXNVKI/0qWDwe9Mw7V0YXt4dz6aAjn4Zm0MO3tsw=; b=cSefES+UeewkXaLlo9DycF2S56OmlVq4J3qgboKQKc8b0w8GzAR5xjzx9/egHDB6Pj 4oTRr+rXLQW9k7vj7SSxsCdrCx4VZ/2aTxZitWHivncKN5yqQAxUBeYDerZJ4NfO1+He Lpg1lc4WZLNvf6C6J70bvU6jORJcT0EESzP73OpO0B8jjgXYFrq4EEumhYgSa6qClvuX novO07BFprdx706iWywIYrLbW1nFesGBINebxSxL23btCI8iNO3knH4htgkNKhgs3YkU Gcm6DxVL2pQ7RgnTHW9IDRfEdVN+CdMtdyWHy0fRUO4xVyPgqJSWXxKp2N07DmkMhzr9 y85Q== X-Gm-Message-State: AFq9FYJDR1/GHzyz9e3WseTuD3wpW2m2NJhjkgRx9+fpf1os9udqc3aG er0taTf4zDDxa8MpRPOxbDGwOU2f0816OMjBwYH+sASi6csg0N78SRVxht/IngX1waHkdphMOp5 f/ACHyg== X-Gm-Gg: AYBFou1G7s4UTe6lj/SpYtf8LN64hjL5G9/AnbYNIth3BlMQNJpP/0X8bsXsOzE47Ov ZGzoQdizID1VYtlQjgYs2T883GI1ylIIBujGfjjheCgWZRo4qvr3XlIwObQbeiKQ6HH4jdTQ8Hp glG8u3szGAaYjzHPPNuGTEWlFnManBoRj8mCoFNVfuydwyytNxj4GYHTEPjj3NTiG7Jl1SpB3zh hMxOrlASHSg2AE81uKdPf3HnFmmfzXSPJfdvypnWtFioGgeapxGqhLPaUjVsMErTuKezu9Dxz+M jf8NBfDM1899K6m/+TdpXnsY0YvpfaRop1e3iv71jgNf1GrkEX2V73wHGjPCRsD+kM7G11yuEns lNlscs0I5FG42gXWMttrrU/2T0muYt6hh03y1yF0pNjt//zr/5sDOi2TuHGnegHar6rdTGqpJQk 9SMZj9QUcSYXscZxis7C6twaXQhTVs1FTF4pBUg3mhawSsQv4aKR8Ry8h5NHUOMO4ShNf+Fesgi cgWnPfdMz7LWlk0Zb+4fufTe8jRIjm7BQxo1bartuXzlQGUeF+qD60GxJd/jGc= X-Received: by 2002:a05:600c:83c4:b0:4a1:7367:5395 with SMTP id 5b1f17b1804b1-4a18e446f4amr159958945e9.2.1791793346987; Mon, 12 Oct 2026 01:22:26 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:22:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 07/15] x86/PVH: lift E820 alignment requirement From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791793347-364DBAE4-F5C670E9/10/78276251493 X-purgate-type: spam X-purgate-size: 2254 Before reordering things (to move in particular pvh_steal_ram() invocations ahead of the pvh_populate_p2m() one) drop an undue (and as it turns out unnecessary) assumption: find_memory() doesn't really depend on E820 regions to end on page boundaries. Signed-off-by: Jan Beulich --- Really the assumption towards the start of regions doesn't look to be relevant either, yet I thought I'd limit the change to the minimum needed. (In fact the statement immediately ahead of the assertion arranges for page alignment, so the check is dubious altogether.) We also could consider whether kernel_end really needs rounding up to a page boundary: Technically there's no need, but the question is whether it would be a good idea to have the tail of the kernel region share a page with metadata (or, as things still are at this point of the series, the initrd). --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -365,6 +365,9 @@ static __init void pvh_setup_e820(struct * that's the minimum granularity of the 2nd stage translation. Since * the p2m code uses PAGE_ORDER_4K internally, also use it here in * order to prevent this code from getting out of sync. + * + * Note that this is only for pvh_populate_p2m(). Subsequent uses of + * pvh_steal_ram() will break the length part. */ start = ROUNDUP(entry->addr, PAGE_SIZE << PAGE_ORDER_4K); end = (entry->addr + entry->size) & @@ -506,8 +509,8 @@ static paddr_t __init find_memory( unsigned int i; /* - * The memory map is sorted and all RAM regions starts and sizes are - * aligned to page boundaries. + * The memory map is sorted and all RAM region starts are aligned to + * page boundaries. */ for ( i = 0; i < d->arch.nr_e820; i++ ) { @@ -519,7 +522,7 @@ static paddr_t __init find_memory( start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1)); - ASSERT(IS_ALIGNED(start, PAGE_SIZE) && IS_ALIGNED(end, PAGE_SIZE)); + ASSERT(IS_ALIGNED(start, PAGE_SIZE)); /* * NB: Even better would be to use rangesets to determine a suitable From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:23:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:23:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445939.1661821 (Exim 4.92) (envelope-from ) id 1xGBJW-0002Cc-Ta; Mon, 12 Oct 2026 08:23:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445939.1661821; Mon, 12 Oct 2026 08:23: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 1xGBJW-0002CV-Qp; Mon, 12 Oct 2026 08:23:18 +0000 Received: by outflank-mailman (input) for mailman id 1445939; Mon, 12 Oct 2026 08:23:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBJV-0002CA-BF for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:23:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBJU-008eBq-KM for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:23:16 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc98ef-2eae-0a2a0a5409dd-0a2a450ad9a4-22 for ; Mon, 12 Oct 2026 10:23:16 +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 6acc98f4-f2d2-0a2a450a0019-d1558029a5ae-3 for ; Mon, 12 Oct 2026 10:23:16 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a166199820so9628575e9.1 for ; Mon, 12 Oct 2026 01:23: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-4a18bf135fasm239176775e9.5.2026.10.12.01.23.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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=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=1791793396; x=1792398196; 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=wrGgJRxfvckrAU7r760vA2zhmoEopAmIopsny2HpFJ0=; b=H0VYnK9hVu8PHONmHF8TVXLzb6GZOAa0ogxcaOSWmzn5fcvXvWkJlGI5feRg3jhiE4 PnSCDDWT/MF/GRz6LXx0CynRwtKmA/nH+r/oMRazp4Jto3LzDreax929u0a/06jiJ/qE 8sBn0aqisS2NhZOEuXRUu243iuwDt1MdbCC1GpuGd7kqyttXVBNGwUNAJ5oPz7D11VJS 17CVkj8Fi/S+OyHr6ITtS/T8002pzsnnhOmpCLoJC87H+v9XBlfpzuISahR+ZbbmnCFc RWP0p3kNCHeysoJHGLSGjE8OYvgeam2Fw12dcdlDipLZBF33KkjH5HqCBOw2r6ABjbxs XNpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793396; x=1792398196; 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=wrGgJRxfvckrAU7r760vA2zhmoEopAmIopsny2HpFJ0=; b=PPEy7HWRK9h/UrAbUdRmJdhuRFEigPFrDFZEfZEPOlbpH693Nkywub0HW6SsU6kRYY BdA5cd1MkqI8UoikNMKcw7445tHsN68ooKnOUimeAThEtxjqS2XV30bxN1AMO/gUNqPC YqieGiWxlSaNb0bfK0i07LC6amQuDjpWB7Uu6IEqVS4S5ap4TOA+zuerdllkZQHQSYQM dicRUOHcU2I4gSUKx267sU0KbnJ8KJj124yeWiPXg18ft92TW6vSOs5evSycWJEXMPAH 5nIaOVkrtJ7g7I9D9zCEl8uILBE20Iz+MseCmnBDmV6b877qYYNbjyKf0Ow7cqlRSCbn qllg== X-Gm-Message-State: AFq9FYLftqyEzq9kxet/OZQ/Zb+oYu/GafV2Z0P6eCu+N15olgBzmHB+ 6NxWmWnJ3l2yMG9Lk8vZZz+AYlA3DYB1SAThmUpcp9ArbW+JRKyV7O1+F8XbvRLaLS06nhcyDQE fk1QLyQ== X-Gm-Gg: AYBFou0yR0unxg7LhDDf5iOVUopywMDnv2DvIFldAozquq1hgxO0IHAVuR7Q1zQ+y9C IDgOizOSWja6X8xf383qJrjFinKxr3ihgP61hVyVrmrIJiwVRaJqV/pufTYaNthLfEI1+B3df9K dXge0nA9spgCYiKckPvPkXEF4Yh88mDXQPhGkJpvxuuiv578yg9cYJkrX2yEFfNXSx+B1Uqfrjv 1oDnnJxacSCx8bhGk4M+OS7u/DxLuRbYn2T3v8K0pajfA3suRbesDQYMxdH01i9LrW+kGi8FE37 0jo+q7R6nWvjlB8hOV2fOOoLY2TNdFWqv8cqEnCtftju6l0sdHzEfIneJwF5av34GaPMYBlPgu2 y3+iie8V9udQZEzqIZijvOJmaxd+muf2pbZw+fImprkfQ393ARQ4EROMxW+zToZzET+pqUuT1Xd PuWR3buFc9QoerQMicvEtGkcrexVKpvVWzOSqTxMZizbEJ1F1hlvaKreRKuo5mVOP/iajhQNvJg 8XqY+5jWUcopzNBKSVWwl8lDuiEmSrgdV58kqj8V2MnGZ4oJapqrZ99apahEvpNzGPvOnQv7Zc= X-Received: by 2002:a05:600c:a011:b0:49e:6581:7baf with SMTP id 5b1f17b1804b1-4a18e447d8bmr157832805e9.2.1791793395599; Mon, 12 Oct 2026 01:23:15 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:23:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 08/15] x86/PVH: split pvh_setup_acpi() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791793396-508CDCFC-0C559DAB/10/78276251493 X-purgate-type: spam X-purgate-size: 10375 All E820 manipulations want to happen before the initrd is placed, or else pvh_steal_ram() may steal from the tail part of it. As a second step, split placing ACPI data from actually populating it. To reuse size calculations and limit churn, convert pvh_setup_acpi_{madt,xsdt}() to two-pass functions: The 1st pass merely reserves space, while the 2nd pass actually populates information. While altering the copying of the RSDP pointer into Dom0's start-info, add a BUILD_BUG_ON() making sure field sizes actually match up. Fixes: 1d74282c455f ("x86: setup PVHv2 Dom0 ACPI tables") Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -920,8 +920,9 @@ static int __init pvh_setup_acpi_madt(st int rc; /* Count number of interrupt overrides in the MADT. */ - acpi_table_parse_madt(ACPI_MADT_TYPE_INTERRUPT_OVERRIDE, - acpi_count_intr_ovr, UINT_MAX); + if ( !*addr ) + acpi_table_parse_madt(ACPI_MADT_TYPE_INTERRUPT_OVERRIDE, + acpi_count_intr_ovr, UINT_MAX); /* Calculate the size of the crafted MADT. */ size = sizeof(*madt); @@ -929,6 +930,22 @@ static int __init pvh_setup_acpi_madt(st size += sizeof(*intsrcovr) * acpi_intr_overrides; size += sizeof(*x2apic) * d->max_vcpus; + if ( !*addr ) + { + /* Reserve space to place the new MADT in guest memory space. */ + if ( pvh_steal_ram(d, size, 0, GB(4), addr) ) + { + printk("Unable to steal guest RAM for MADT\n"); + return -ENOMEM; + } + + /* Mark this region as E820_ACPI. */ + if ( pvh_add_mem_range(d, *addr, *addr + size, E820_ACPI) ) + printk("Unable to add MADT region to memory map\n"); + + return 0; + } + madt = xzalloc_bytes(size); if ( !madt ) { @@ -991,17 +1008,6 @@ static int __init pvh_setup_acpi_madt(st madt->header.checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, madt), size); /* Place the new MADT in guest memory space. */ - if ( pvh_steal_ram(d, size, 0, GB(4), addr) ) - { - printk("Unable to steal guest RAM for MADT\n"); - rc = -ENOMEM; - goto out; - } - - /* Mark this region as E820_ACPI. */ - if ( pvh_add_mem_range(d, *addr, *addr + size, E820_ACPI) ) - printk("Unable to add MADT region to memory map\n"); - rc = hvm_copy_to_guest_phys(*addr, madt, size, d->vcpu[0]); if ( rc ) { @@ -1116,6 +1122,22 @@ static int __init pvh_setup_acpi_xsdt(st */ size += num_tables * sizeof(xsdt->table_offset_entry[0]); + if ( !*addr ) + { + /* Reserve space to place the new XSDT in guest memory space. */ + if ( pvh_steal_ram(d, size, 0, GB(4), addr) ) + { + printk("Unable to find guest RAM for XSDT\n"); + return -ENOMEM; + } + + /* Mark this region as E820_ACPI. */ + if ( pvh_add_mem_range(d, *addr, *addr + size, E820_ACPI) ) + printk("Unable to add XSDT region to memory map\n"); + + return 0; + } + xsdt = xzalloc_bytes(size); if ( !xsdt ) { @@ -1179,17 +1201,6 @@ static int __init pvh_setup_acpi_xsdt(st xsdt->header.checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, xsdt), size); /* Place the new XSDT in guest memory space. */ - if ( pvh_steal_ram(d, size, 0, GB(4), addr) ) - { - printk("Unable to find guest RAM for XSDT\n"); - rc = -ENOMEM; - goto out; - } - - /* Mark this region as E820_ACPI. */ - if ( pvh_add_mem_range(d, *addr, *addr + size, E820_ACPI) ) - printk("Unable to add XSDT region to memory map\n"); - rc = hvm_copy_to_guest_phys(*addr, xsdt, size, d->vcpu[0]); if ( rc ) { @@ -1205,18 +1216,18 @@ static int __init pvh_setup_acpi_xsdt(st return rc; } -static int __init pvh_setup_acpi(struct domain *d, paddr_t start_info) +struct acpi_info { + paddr_t madt; + paddr_t xsdt; + paddr_t rsdp; +}; + +static int __init pvh_place_acpi( + struct domain *d, + struct acpi_info *info) { - unsigned long pfn, nr_pages; - paddr_t madt_paddr, xsdt_paddr, rsdp_paddr; unsigned int i; int rc; - struct acpi_table_rsdp *native_rsdp, rsdp = { - .signature = ACPI_SIG_RSDP, - .revision = 2, - .length = sizeof(rsdp), - }; - /* Scan top-level tables and add their regions to the guest memory map. */ for( i = 0; i < acpi_gbl_root_table_list.count; i++ ) @@ -1239,6 +1250,8 @@ static int __init pvh_setup_acpi(struct /* Identity map ACPI e820 regions. */ for ( i = 0; i < d->arch.nr_e820; i++ ) { + unsigned long pfn, nr_pages; + if ( d->arch.e820[i].type != E820_ACPI && d->arch.e820[i].type != E820_NVS ) continue; @@ -1267,32 +1280,49 @@ static int __init pvh_setup_acpi(struct } } - rc = pvh_setup_acpi_madt(d, &madt_paddr); + rc = pvh_setup_acpi_madt(d, &info->madt); if ( rc ) return rc; - rc = pvh_setup_acpi_xsdt(d, madt_paddr, &xsdt_paddr); + rc = pvh_setup_acpi_xsdt(d, info->madt, &info->xsdt); if ( rc ) return rc; - /* Craft a custom RSDP. */ - native_rsdp = acpi_os_map_memory(acpi_os_get_root_pointer(), sizeof(rsdp)); - if ( !native_rsdp ) + if ( pvh_steal_ram(d, sizeof(struct acpi_table_rsdp), 0, GB(4), + &info->rsdp) ) { - printk("Failed to map native RSDP\n"); + printk("Unable to allocate guest RAM for RSDP\n"); return -ENOMEM; } - memcpy(rsdp.oem_id, native_rsdp->oem_id, sizeof(rsdp.oem_id)); - acpi_os_unmap_memory(native_rsdp, sizeof(rsdp)); - rsdp.xsdt_physical_address = xsdt_paddr; - /* - * Calling acpi_tb_checksum here is a layering violation, but - * introducing a wrapper for such simple usage seems overkill. - */ - rsdp.checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, &rsdp), - ACPI_RSDP_REV0_SIZE); - rsdp.extended_checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, &rsdp), - sizeof(rsdp)); + + /* Mark this region as E820_ACPI. */ + if ( pvh_add_mem_range(d, info->rsdp, + info->rsdp + sizeof(struct acpi_table_rsdp), + E820_ACPI) ) + printk("Unable to add RSDP region to memory map\n"); + + return 0; +} + +static int __init pvh_setup_acpi( + struct domain *d, + struct acpi_info *info, + paddr_t start_info) +{ + int rc; + struct acpi_table_rsdp *native_rsdp, rsdp = { + .signature = ACPI_SIG_RSDP, + .revision = 2, + .length = sizeof(rsdp), + }; + + rc = pvh_setup_acpi_madt(d, &info->madt); + if ( rc ) + return rc; + + rc = pvh_setup_acpi_xsdt(d, info->madt, &info->xsdt); + if ( rc ) + return rc; /* * Place the new RSDP in guest memory space. @@ -1302,19 +1332,27 @@ static int __init pvh_setup_acpi(struct * the native RSDT, and should not be used for the Dom0 kernel's boot * purposes (we keep it visible for post boot access). */ - if ( pvh_steal_ram(d, sizeof(rsdp), 0, GB(4), &rsdp_paddr) ) + native_rsdp = acpi_os_map_memory(acpi_os_get_root_pointer(), sizeof(rsdp)); + if ( !native_rsdp ) { - printk("Unable to allocate guest RAM for RSDP\n"); + printk("Failed to map native RSDP\n"); return -ENOMEM; } + memcpy(rsdp.oem_id, native_rsdp->oem_id, sizeof(rsdp.oem_id)); + acpi_os_unmap_memory(native_rsdp, sizeof(rsdp)); + rsdp.xsdt_physical_address = info->xsdt; - /* Mark this region as E820_ACPI. */ - if ( pvh_add_mem_range(d, rsdp_paddr, rsdp_paddr + sizeof(rsdp), - E820_ACPI) ) - printk("Unable to add RSDP region to memory map\n"); + /* + * Calling acpi_tb_checksum here is a layering violation, but + * introducing a wrapper for such simple usage seems overkill. + */ + rsdp.checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, &rsdp), + ACPI_RSDP_REV0_SIZE); + rsdp.extended_checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, &rsdp), + sizeof(rsdp)); /* Copy RSDP into guest memory. */ - rc = hvm_copy_to_guest_phys(rsdp_paddr, &rsdp, sizeof(rsdp), d->vcpu[0]); + rc = hvm_copy_to_guest_phys(info->rsdp, &rsdp, sizeof(rsdp), d->vcpu[0]); if ( rc ) { printk("Unable to copy RSDP into guest memory\n"); @@ -1322,9 +1360,11 @@ static int __init pvh_setup_acpi(struct } /* Copy RSDP address to start_info. */ + BUILD_BUG_ON(sizeof(info->rsdp) != + sizeof_field(struct hvm_start_info, rsdp_paddr)); rc = hvm_copy_to_guest_phys(start_info + offsetof(struct hvm_start_info, rsdp_paddr), - &rsdp_paddr, + &info->rsdp, sizeof_field(struct hvm_start_info, rsdp_paddr), d->vcpu[0]); if ( rc ) @@ -1361,6 +1401,7 @@ int __init dom0_construct_pvh(const stru struct elf_binary elf; struct e820entry *orig_e820; unsigned int nr_orig_e820; + struct acpi_info acpi = {}; int rc; printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id); @@ -1414,6 +1455,13 @@ int __init dom0_construct_pvh(const stru return rc; } + rc = pvh_place_acpi(d, &acpi); + if ( rc ) + { + printk("Failed to place Dom0 ACPI tables: %d\n", rc); + return rc; + } + rc = pvh_populate_p2m(d, orig_e820, nr_orig_e820); if ( rc ) { @@ -1437,7 +1485,7 @@ int __init dom0_construct_pvh(const stru return rc; } - rc = pvh_setup_acpi(d, start_info); + rc = pvh_setup_acpi(d, &acpi, start_info); if ( rc ) { printk("Failed to setup Dom0 ACPI tables: %d\n", rc); From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:24:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:24:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445945.1661830 (Exim 4.92) (envelope-from ) id 1xGBKL-0002lR-9R; Mon, 12 Oct 2026 08:24:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445945.1661830; Mon, 12 Oct 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 1xGBKL-0002lK-6G; Mon, 12 Oct 2026 08:24:09 +0000 Received: by outflank-mailman (input) for mailman id 1445945; Mon, 12 Oct 2026 08:24:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBKJ-0002k9-Ud for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:24:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBKJ-004glY-B8 for xen-devel@lists.xenproject.org; Mon, 12 Oct 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 6acc9926-2eae-0a2a0a5409dd-0a2a45099e60-2 for ; Mon, 12 Oct 2026 10:24:07 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc9927-be1a-0a2a45090019-d1558036ccf8-3 for ; Mon, 12 Oct 2026 10:24:07 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a168355946so13047745e9.0 for ; Mon, 12 Oct 2026 01:24: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-4a18be964dfsm267989555e9.7.2026.10.12.01.24.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:24: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=1791793447; x=1792398247; 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=7K5SMf732bv3GcurztUVEeK+Xsb62UgCzDIrcbeQvYU=; b=eE9vAin7MtsAdJAuz9Uq+kWVWLzO2IVy70C9sothNiSHBosUuiE1aAAPRgMl3JPYeE VZNgNQEQ/0LCrkSu9Ur7RafMeAtMiYbpVM8F9BeOZAvDHBMKjl/QV6D6tji7BZmUwjc2 W5AlYW7t/WgHsGp9/ocvD9n32O5V10tr4Xtwko8erwA7z1mjtakAHojWpLQXMehS5A16 H2ZgcM38UGGNDnfT0U2mURujRMUymcuYjwoNzDEfqA2dK3pVOVS5P1zgQV7otYPYIFtq jO6i2QCXDPIuvOKYGTGXurGbZ6aC0m/M+MX8qDLyXgiLHNxtiaKCvhyhQZ+YiLdSlniU /G9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793447; x=1792398247; 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=7K5SMf732bv3GcurztUVEeK+Xsb62UgCzDIrcbeQvYU=; b=D4Lh8cZcg7ONR7VtkK6EsmdQchOqnO+sMLyrSVHqjETkKhsrPKLTVJ0BUXQc04sZoh djc1B++9sDveuU5dkBZZpIZt5yoG8/VuQtYG6LD1v8ZFpfMHN5K+9oQr/oxoZmfbq2ht hKyK4g+rRJ7b2mFGRUr+4mZZy2OF5mEXRnzpgaYKWyhISNFZn2W2hw78YKxHsL0VF3eQ G8jwRd3mCF3cGoW9pW50IrD14FtM5gdHk7ZsCW6V5BtQrNKC/U12K9Cz8aMaLTVNauL0 gl2QmgnYNuZtU8SbotEI+S6VI4akLbVcHD9zo5dhCknJmUKF7OWfqykM/ius2Dp4o1Uw PvpA== X-Gm-Message-State: AFq9FYLhZCIOxxeuRRzELPPpJFVP5x4fR8ulfcwoGhpd+UZd9HfmdGBj 4JOFlCX0Pvt8+KeNOFaPmiwnx5vdTyIAHKO88v6g1CqgjUH0bufVoa6MCMaRwOWpwKLv3YnSZ+V HR7hoMw== X-Gm-Gg: AYBFou03cbSBFzLq2FiDBA/hV8wRuKrIbOvHpgtccmGbYaVOG9uUkBRDPjSNinwMFZd 75b2+K05sh66OCYW3heQajTtiOyGw6T/5qROOFTeVoZm383d/pum8sgAWWyJnjB6zjQ8B/EtOHz f70i0fxfVX7YIdCEyrWd/G4HBL00tFT831q8nhzmrJSRlNYsF/O97LJB8xlZ/tzJ6weBO9M6+XK hqj/vbccFseIUmmeX3w9+6Gc8zI6+kAVQkE/ZWVBPTrCDHuFd2g7skzIJ+p+a09Yyw/ryhWh3D3 uHIhXQ0+pfWn4qo4FphniTbPJ26ZQv+zpEk3w6jO6vimKyjerfe6b6hnNfvx8H27NB7sQTr7cK6 trZ0646HqBR0OBgVjtsUsWl7iGNHxnB/AxrAvj+FTeHRscywvalUVthEUKPfVP2JnI7dnahFmRY CzaFSJsVN7ZQTNS1DlgtYjgdNQwhc63g71dqIbYempuEJYxDKJLMTc8qrXLQEEHNqmS9/qKjb+G WMb5ZRd28oMoeMe8EG53ZRbndHEkXRTfZrgUKUqiqAmr9GbEQTlXcpylhlQ7zxPfs6xnUj4 X-Received: by 2002:a05:600c:a112:b0:4a1:9663:7633 with SMTP id 5b1f17b1804b1-4a1966379f7mr80180095e9.11.1791793446614; Mon, 12 Oct 2026 01:24:06 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:24:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 09/15] x86/PVH: split pvh_setup_vmx_realmode_helpers() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791793447-FDC6D034-51FCC69A/10/78276251493 X-purgate-type: spam X-purgate-size: 5911 All E820 manipulations want to happen before the initrd is placed, or else pvh_steal_ram() may steal from the tail part of it. While this is currently suitably ordered, mapping the initrd directly into Dom0 will want to happen ahead of pvh_populate_p2m(). Hence as a third step, split placing VMX data (if needed at all) from actually populating it. Also move the invocation of pvh_setup_vmx_realmode_helpers() out of pvh_populate_p2m(). Make it unconditional as well, instead bailing from the function when pvh_place_vmx_realmode_helpers() wasn't called. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -268,26 +268,30 @@ static int __init pvh_add_mem_range(stru return 0; } -static int __init pvh_setup_vmx_realmode_helpers(struct domain *d) +struct vmx_info { + paddr_t tss; + gfn_t identpt; +}; + +static int __init pvh_place_vmx_realmode_helpers( + struct domain *d, + struct vmx_info *info) { - uint32_t rc, *ident_pt; - mfn_t mfn; paddr_t gaddr; - struct vcpu *v = d->vcpu[0]; /* - * Steal some space from the last RAM region below 4GB and use it to - * store the real-mode TSS. It needs to be aligned to 128 so that the - * TSS structure (which accounts for the first 104b) doesn't cross - * a page boundary. + * Steal some space from the last RAM region below 4GB to store the + * real-mode TSS. It needs to be aligned to 128 so that the TSS + * structure (which accounts for the first 104b) doesn't cross a page + * boundary. */ if ( !pvh_steal_ram(d, HVM_VM86_TSS_SIZE, 128, GB(4), &gaddr) ) { - if ( hvm_copy_to_guest_phys(gaddr, NULL, HVM_VM86_TSS_SIZE, v) != - HVMTRANS_okay ) - printk("Unable to zero VM86 TSS area\n"); d->arch.hvm.params[HVM_PARAM_VM86_TSS_SIZED] = VM86_TSS_UPDATED | ((uint64_t)HVM_VM86_TSS_SIZE << 32) | gaddr; + + info->tss = gaddr; + if ( pvh_add_mem_range(d, gaddr, gaddr + HVM_VM86_TSS_SIZE, E820_RESERVED) ) printk("Unable to set VM86 TSS as reserved in the memory map\n"); @@ -302,12 +306,41 @@ static int __init pvh_setup_vmx_realmode return -ENOMEM; } + if ( pvh_add_mem_range(d, gaddr, gaddr + PAGE_SIZE, E820_RESERVED) ) + printk("Unable to set identity page tables as reserved in the memory map\n"); + + d->arch.hvm.params[HVM_PARAM_IDENT_PT] = gaddr; + info->identpt = _gfn(PFN_DOWN(gaddr)); + + return 0; +} + +static int __init pvh_setup_vmx_realmode_helpers( + const struct domain *d, + const struct vmx_info *info) +{ + uint32_t rc, *ident_pt; + mfn_t mfn; + struct vcpu *v = d->vcpu[0]; + + /* Bail if no space needed reserving in the first place. */ + if ( gfn_eq(info->identpt, _gfn(0)) ) + return 0; + + /* Store the real-mode TSS, if space for it was successfully stolen. */ + if ( info->tss ) + { + if ( hvm_copy_to_guest_phys(info->tss, NULL, HVM_VM86_TSS_SIZE, v) != + HVMTRANS_okay ) + printk("Unable to zero VM86 TSS area\n"); + } + /* * Identity-map page table is required for running with CR0.PG=0 * when using Intel EPT. Create a 32-bit non-PAE page directory of * superpages. */ - ident_pt = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)), + ident_pt = map_domain_gfn(p2m_get_hostp2m(d), info->identpt, &mfn, 0, &rc); if ( ident_pt == NULL ) { @@ -317,9 +350,6 @@ static int __init pvh_setup_vmx_realmode write_32bit_pse_identmap(ident_pt); unmap_domain_page(ident_pt); put_page(mfn_to_page(mfn)); - d->arch.hvm.params[HVM_PARAM_IDENT_PT] = gaddr; - if ( pvh_add_mem_range(d, gaddr, gaddr + PAGE_SIZE, E820_RESERVED) ) - printk("Unable to set identity page tables as reserved in the memory map\n"); return 0; } @@ -481,18 +511,6 @@ static int __init pvh_populate_p2m( } } - if ( using_vmx() && !paging_mode_shadow(d) && !vmx_unrestricted_guest(v) ) - { - /* - * Since Dom0 cannot be migrated, we will only setup the - * unrestricted guest helpers if they are needed by the current - * hardware we are running on. - */ - rc = pvh_setup_vmx_realmode_helpers(d); - if ( rc ) - return rc; - } - if ( opt_dom0_verbose ) print_order_stats(d); @@ -1402,6 +1420,7 @@ int __init dom0_construct_pvh(const stru struct e820entry *orig_e820; unsigned int nr_orig_e820; struct acpi_info acpi = {}; + struct vmx_info vmx = {}; int rc; printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id); @@ -1462,6 +1481,22 @@ int __init dom0_construct_pvh(const stru return rc; } + /* + * Since Dom0 cannot be migrated, only set up the unrestricted guest + * helpers if they are needed by the hardware we are running on. + */ + if ( using_vmx() && !paging_mode_shadow(d) && + /* + * TODO: Unrestricted Guest should be a domain property, not a vCPU + * one. + */ + !vmx_unrestricted_guest(d->vcpu[0]) ) + { + rc = pvh_place_vmx_realmode_helpers(d, &vmx); + if ( rc ) + return rc; + } + rc = pvh_populate_p2m(d, orig_e820, nr_orig_e820); if ( rc ) { @@ -1492,6 +1527,10 @@ int __init dom0_construct_pvh(const stru return rc; } + rc = pvh_setup_vmx_realmode_helpers(d, &vmx); + if ( rc ) + return rc; + if ( opt_dom0_verbose ) { printk("Dom%u memory map:\n", d->domain_id); From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:24:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:24:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445951.1661839 (Exim 4.92) (envelope-from ) id 1xGBKx-0003Dk-IM; Mon, 12 Oct 2026 08:24:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445951.1661839; Mon, 12 Oct 2026 08:24: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 1xGBKx-0003Dd-FY; Mon, 12 Oct 2026 08:24:47 +0000 Received: by outflank-mailman (input) for mailman id 1445951; Mon, 12 Oct 2026 08:24:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBKw-0003DS-Fu for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:24:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBKv-004h4N-Sb for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:24:45 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9948-8faa-0a2a0a5109dd-0a2a4502bf3c-32 for ; Mon, 12 Oct 2026 10:24:45 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc994d-6ca4-0a2a45020019-d155802bc418-3 for ; Mon, 12 Oct 2026 10:24:45 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a018792ab3so13389395e9.0 for ; Mon, 12 Oct 2026 01:24: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-4a18bf15691sm265454305e9.6.2026.10.12.01.24.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:24: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=1791793485; x=1792398285; 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=KDxjiJoC7Zfxqe0fOfGwbY9xr+haAUaY8IesLtAlI3I=; b=WzYHTfezot9xOniBwkGTdIWRTwepyGYS326zvaFzLYTztLCHXK9pX1ES76hgfAYAoB gIGgMWJw7OQHWS/okTHJEcVBWU/tPc4ByMvwR4/7y+dkPj/0ELeY+HpdkywMmpWTSEDL D7AZgaGsffxZCEqEoHb+Ma8dZXZgKvW0O4tpXvN7KE3iuFYj+K93Qv4+n4p2OjmCerDU HP8xCLjR+GOs7cPvvvLhc/8rBU2NuyxuoDplA4wBs/TwRubPfBz4F+6BBfnhFCH0iFOm HzDYT/MKIlGj2ddy8SRbUxgwGYdCwBB1GnoQThQnxeyx3HliXoTaQjY2S9OO3IYy32sj OffA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793485; x=1792398285; 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=KDxjiJoC7Zfxqe0fOfGwbY9xr+haAUaY8IesLtAlI3I=; b=S59UFyzTTbVQhfjuML+HlSQjOjLzzDGq4pwutVFdO3ncL5nXXXojE0+oIvjADRQTwz ciUwZRVKJBJH4ehahG2DVcy8bVWYjV0e2pjpL+m9f6zQDme3gssYP/xzn/lCSYqnQk07 HhkxRBAKEO3BMRapHBEgrYyw7WaDKA2GRa7XBg/mabqu5Rt9hdrYoiQfD+ys7Of6jPjZ 5XywX1M0jjPCA2hZWKb7qtvw8iiVi90FJD3W/B4NLREn3WtFQGL+RH58L5B1LQzlLX2N 9q4rwDFvEfOGhuG3WrVjYK4ELdrz53vyjLD/N5MNCkRXhd/kRpLZG+KciYPab8/fZ8CS CUgw== X-Gm-Message-State: AFq9FYIaMgMmW1d7JLWDyhxLkBs+QYk3DapfbfVMas1stHDkmZYhejEm NpNmwUKF7rNbiTEJ/tYUcEaiOQoLdKoN6Lk9D3qtOlkIa2j12UxPv8a0dfBrqvRCxz+2loysjlw 8piHcYw== X-Gm-Gg: AYBFou02O3G3+pPpQHya7R5crOKJRlWOekFVqcltVSqWO9tp0nRfS6/wwMVLg0jfeq3 2xRqKxftf8N2+jGuRVtAnVEBnMBmdJoJoW7hlPL3jmXBKYUVSZiCBHXDIicxWH5jmMf9ojO4QTt zakDMFy6S+3lgwMz7Azufvog9yL9iyG5u7avWryUk8ujJ8AJb28j6wSm9nIfRAm8ktAQh9wy1w2 A9JdvHv2BKHgcFEaMHzbLugR3diJa3ju6T47/v51vty2G0mD5FFFXSZc65iBEAOk2oQmeUj7hb8 tUPrKOr+A8JKTgcchsMb6WMrRAjOnvykeo0hxh2wNn3CKc+djQgDw/cQ0u7z0CsYuX+D5GBwhq5 SyeobQS9P63giSSIMtSnDXFW8T+hq03dLuWGpMD0+HunG5p7xdVcb5xunNg2XgIiJDIN7jRaTs8 CP9roazGO7rwQXYIHOpJMERtG19tv43qdReBusLg2+Gm0FU+zSYKv6syv01fg7TF33Tkfs0XvI1 IcCEhP3124tT3Nt6+87vISiGvoamjU+QDfm8aDA9dcd5pg7MDX7a8NxXl3tf60= X-Received: by 2002:a05:600c:46cf:b0:4a1:7e1f:21bc with SMTP id 5b1f17b1804b1-4a18e4d6636mr169211865e9.29.1791793483815; Mon, 12 Oct 2026 01:24:43 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:24:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 10/15] x86/PVH: convert find_memory() to using a rangeset From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1791793485-30BC02AC-52595182/10/78276251493 X-purgate-type: spam X-purgate-size: 3172 Subsequently we will need to exclude a 2nd range here. To avoid complicating the logic when it needs to cover two ranges, follow the suggestion left in a code comment and convert to using a rangeset. Suggested-by: Xenia Ragiadakou Signed-off-by: Jan Beulich --- The Suggested-by: is based on the respective commit's S-o-b. I didn't go hunt for whether this may have been suggested in review of that patch. --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -518,14 +518,38 @@ static int __init pvh_populate_p2m( #undef MB1_PAGES } +struct mem_info { + size_t size; + paddr_t addr; +}; + +static int cf_check __init _find_memory( + unsigned long s, unsigned long e, void *data) +{ + struct mem_info *info = data; + + if ( e + 1 - s >= info->size ) + { + info->addr = s; + return 1; + } + + return 0; +} + static paddr_t __init find_memory( const struct domain *d, const struct elf_binary *elf, size_t size) { - paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; - paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, - PAGE_SIZE); + struct rangeset *ram = rangeset_new(NULL, NULL, 0); + struct mem_info info = { + .size = size, + .addr = INVALID_PADDR, + }; unsigned int i; + if ( !ram ) + return INVALID_PADDR; + /* * The memory map is sorted and all RAM region starts are aligned to * page boundaries. @@ -542,26 +566,22 @@ static paddr_t __init find_memory( ASSERT(IS_ALIGNED(start, PAGE_SIZE)); - /* - * NB: Even better would be to use rangesets to determine a suitable - * range, in particular in case a kernel requests multiple heavily - * discontiguous regions (which right now we fold all into one big - * region). - */ - if ( end <= kernel_start || start >= kernel_end ) - { - /* No overlap, just check whether the region is large enough. */ - if ( end - start >= size ) - return start; - } - /* Deal with the kernel already being loaded in the region. */ - else if ( kernel_start > start && kernel_start - start >= size ) - return start; - else if ( kernel_end < end && end - kernel_end >= size ) - return kernel_end; + if ( start < end && + rangeset_add_range(ram, start, end - 1) != 0 ) + return INVALID_PADDR; } - return INVALID_PADDR; + /* Remove the kernel range, rounded to page boundaries. */ + if ( rangeset_remove_range(ram, (paddr_t)elf->dest_base & PAGE_MASK, + ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, + PAGE_SIZE) - 1) != 0 ) + return INVALID_PADDR; + + rangeset_report_ranges(ram, MB(1), -1, _find_memory, &info); + + rangeset_destroy(ram); + + return info.addr; } static bool __init check_load_address( From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:25:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:25:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445955.1661847 (Exim 4.92) (envelope-from ) id 1xGBLM-0003d3-PL; Mon, 12 Oct 2026 08:25:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445955.1661847; Mon, 12 Oct 2026 08: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 1xGBLM-0003cw-MU; Mon, 12 Oct 2026 08:25:12 +0000 Received: by outflank-mailman (input) for mailman id 1445955; Mon, 12 Oct 2026 08:25:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBLL-0003ck-TK for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:25:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBLL-00Dncs-8k for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:25:11 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9967-bab6-0a2a0a5309dd-0a2a45049832-0 for ; Mon, 12 Oct 2026 10:25:11 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc9967-b57f-0a2a45040019-d155802da4dc-3 for ; Mon, 12 Oct 2026 10:25:11 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a16c1608faso20791475e9.0 for ; Mon, 12 Oct 2026 01:25: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-4a18bf1358asm276719295e9.4.2026.10.12.01.25.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:25: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=1791793511; x=1792398311; 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=EL4bFrGDS8fVRKtmEPWhtKmCO7uYd5KlpOWgxi3uTDQ=; b=IuGQ4uWM/yhYt1Q0n9v7ZXuyU6H5InPr/Bzo68sDnTxCajgKzrzMi7t25B+soBWuHH ZDMqiWKwjrBGgaIMLERtSqFcqTTwFOj10/nSkyPYah9reCCWGc7/OV3eq+CuSapt1Rl0 LFCJFxtndi5e31NE2q6TyKkwn/5JitJxHfUB7vQIhqu2ZortmHg5ZitbGzeF/0Lck8B/ lv+rJQv7EBThXKSbCNb04D0h9ZHZBR8i1j/PorLysNNDetvmuR722A7fUVisVq7/vlEs s/Ygaml65FlxV93JW+570jGpqqqm6c+ahWCa+pxRz4o5Zc1EtzeRQXfNmeWKdSxbw4v/ nRZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793511; x=1792398311; 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=EL4bFrGDS8fVRKtmEPWhtKmCO7uYd5KlpOWgxi3uTDQ=; b=i/UWegh8QWKPp9+zCWtyIxHP6b8BX436bgrutjToGytgjxhdcx4tliCGsUCLeWnH+C mmlf6Zgd9gWZxMLzyXlF2EjoOZKVRKVb1oQnJii0aDA5MFAIZwp1aaASCgc7QiWYnBir HboiGw1XUuTXvBiVvm72p9AxV1xfOzXTarN3RxCNeFgY+3xpJxb2kkxBf1dI+glEq1l4 hTA7PwVv7cQyt9567G2MZdGzj4zMh3W58Ur1uqPO02SIjZCC/5M8As5alcFBDn9PGCkf uRsYfoC8IzNlULja7cs9Qk5IRfiO0Gv018FlovTcSuJwBMcds8RWZJTec4VIcYYXFwSQ wUEw== X-Gm-Message-State: AFq9FYLJDqBivlt+LfckuxbT6kCv45KuXnZAqctCDWbzu/T+/i9ZZq/B SgPx58qmdH6z/XtzB+kYpsjdARmoGCjEmwpNOei1qNTvIw1H07nhoHxNZOf5gRTg7QzQbHPM38w bQyybdw== X-Gm-Gg: AYBFou33xF4WSTkG8s6S+Kw6tcT1JDZK0s4HXhjIkTwJMP40oPwXSW0meb4UV+3B9xf yjT5701TRw5HBKzZ+oA9paRl9NSxBSt5yLWrWX0r81apUcbraEh2Sv0qiGrEjPKBmzB/TW3GYa5 8QLxThmiAdzgwmFi5Wq+TfoV2WluKRJ25ChEtIM2mLwHKDkbTWX7RHtFyMuW2AtxqIcbFbpJSOs d5KWieSVgsJ0/IeMOrj6t1V5AmQbpXY4gXm4s9yVMrl3MTxaEFZ0gRJKxQniBdQVFgokUx0pXU4 z8c1ayKYOa70pkzw/rIhewMpQ1CNONv3HQlO92tp+j4EqHBi0mtS3fvdM99sTNSALTKqwIWfCB7 /PnnOZKphtBSMuK96y0S9nBj3Ln8R87+B6EwiAa7dMYoGcLwECbnFesSQRQnR8rACXz0JUfOL4w 0XDG2bGn0LOJ9UhRXwMKhUkJXmuEpsQy8tQl1olyUZeX3wSz9AyEuFmDjssY2mdZdCikQxUq+Kn dDhjGdMKCNthNorNWQ+RWT4jCad8MvGcQ5fokQAu48USvKFdU7C2o6hSgZzDbf/ X-Received: by 2002:a05:600c:4708:b0:4a1:88df:8a2a with SMTP id 5b1f17b1804b1-4a18e4a6ea5mr168845315e9.13.1791793510456; Mon, 12 Oct 2026 01:25:10 -0700 (PDT) Message-ID: <78cd46cc-84ed-46df-96c9-26ce97ed0da0@suse.com> Date: Mon, 12 Oct 2026 10:25:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791793511-C0EDEB50-373112A0/10/78276251493 X-purgate-type: spam X-purgate-size: 14924 Our present handling of initrd is problematic in particular when the initrd is huge, and when at the same time "dom0_mem=" isn't in use to significantly shrink Dom0's memory (from the default). In that case, insufficient memory may exist for pvh_populate_p2m() to succeed (because initrd memory can be freed only after copying). Make an attempt to map the blob (including headroom) into Dom0 instead, thus also saving the copying operation. With __start_xen() having arranged for a larger than necessary blob, that mapping can typically be done with superpage mappings. Reported-by: Marek Marczykowski-Górecki Signed-off-by: Jan Beulich --- Is there a need to prune (scrub) the headroom space? Why does find_memory() go upwards, while find_kernel_memory() goes downwards? And why do we use the lowest part of the region found by find_memory() rather than the highest part? --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -450,7 +450,9 @@ static void __init pvh_init_p2m(struct d static int __init pvh_populate_p2m( struct domain *d, const struct e820entry *e820, - unsigned int nr_e820) + unsigned int nr_e820, + unsigned long initrd_start, + unsigned long initrd_end) { struct vcpu *v = d->vcpu[0]; unsigned int i; @@ -468,7 +470,12 @@ static int __init pvh_populate_p2m( addr = PFN_DOWN(e820[i].addr); size = PFN_DOWN(e820[i].size); - rc = pvh_populate_memory_range(d, addr, size); + if ( addr + size <= initrd_start || addr >= initrd_end ) + rc = pvh_populate_memory_range(d, addr, size); + else + rc = pvh_populate_memory_range(d, addr, initrd_start - addr) + ?: pvh_populate_memory_range(d, initrd_end, + addr + size - initrd_end); if ( rc ) return rc; @@ -518,6 +525,43 @@ static int __init pvh_populate_p2m( #undef MB1_PAGES } +static int __init pvh_map_initrd( + struct domain *d, const struct boot_module *initrd, + paddr_t initrd_start, unsigned int order) +{ + for ( paddr_t ga = initrd_start, ma = initrd->start; + ga < initrd_start + initrd->size; + ga += PAGE_SIZE << order, ma += PAGE_SIZE << order ) + { + int rc = p2m_add_page(d, gaddr_to_gfn(ga), maddr_to_mfn(ma), + order, p2m_ram_rw); + + if ( rc ) + { + printk("Failed to map initrd: [%#lx,%#lx): %d\n", + PFN_DOWN(ga), PFN_DOWN(ga) + (1UL << order), rc); + + /* + * Best effort rollback: The range will be replaced anyway by the + * subsequent pvh_populate_p2m(). + */ + while ( ga > initrd_start ) + { + ga -= PAGE_SIZE << order; + ma -= PAGE_SIZE << order; + p2m_remove_page(d, gaddr_to_gfn(ga), maddr_to_mfn(ma), order); + order_stats[order]--; + } + + return rc; + } + + order_stats[order]++; + } + + return 0; +} + struct mem_info { size_t size; paddr_t addr; @@ -538,7 +582,10 @@ static int cf_check __init _find_memory( } static paddr_t __init find_memory( - const struct domain *d, const struct elf_binary *elf, size_t size) + const struct domain *d, + const struct elf_binary *elf, + const struct hvm_modlist_entry *initrd, + size_t size) { struct rangeset *ram = rangeset_new(NULL, NULL, 0); struct mem_info info = { @@ -577,6 +624,13 @@ static paddr_t __init find_memory( PAGE_SIZE) - 1) != 0 ) return INVALID_PADDR; + /* Remove the mapped initrd range (if any), rounded to page boundaries. */ + if ( initrd->paddr && + rangeset_remove_range(ram, initrd->paddr, + ROUNDUP(initrd->paddr + initrd->size, + PAGE_SIZE) - 1) != 0 ) + return INVALID_PADDR; + rangeset_report_ranges(ram, MB(1), -1, _find_memory, &info); rangeset_destroy(ram); @@ -689,6 +743,70 @@ static bool __init check_and_adjust_load return true; } +static paddr_t __init find_initrd_memory( + const struct domain *d, + const struct elf_binary *elf, + const struct boot_module *initrd, + size_t align, + paddr_t limit) +{ + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, + PAGE_SIZE); + unsigned long initrd_size = ROUNDUP(initrd->size, PAGE_SIZE); + unsigned long initrd_len = initrd_size - initrd->arch.headroom; + + if ( !IS_ALIGNED(initrd->start | initrd_size, align) ) + return INVALID_PADDR; + + /* + * The memory map is sorted. Search backwards to find the highest + * suitable address. + */ + for ( unsigned int i = d->arch.nr_e820; i--; ) + { + paddr_t start = d->arch.e820[i].addr; + paddr_t end = start + d->arch.e820[i].size; + + if ( d->arch.e820[i].type != E820_RAM ) + continue; + + if ( end > limit ) + continue; + + start = MAX(ROUNDUP(start, align), MB(1)); + end = ROUNDDOWN(end, align); + + /* Don't use memory below 1MB, as it could overwrite BDA/EBDA/IBFT. */ + if ( end <= MB(1) ) + break; + + if ( end <= initrd_size ) + break; + + if ( end - initrd_size <= start ) + continue; + + /* + * NB: Even better would be to use rangesets to determine a suitable + * range, in particular in case a kernel requests multiple heavily + * discontiguous regions (which right now we fold all into one big + * region). + */ + if ( end <= kernel_start || end - initrd_len >= kernel_end ) + return end - initrd_size; /* No overlap. */ + + /* Deal with the kernel already being loaded in the region. */ + if ( kernel_end < end && end - kernel_end >= initrd_len ) + return end - initrd_size; + if ( kernel_start > start && + ROUNDDOWN(kernel_start, align) - start >= initrd_size ) + return ROUNDDOWN(kernel_start, align) - initrd_size; + } + + return INVALID_PADDR; +} + static int __init pvh_place_kernel( const struct boot_domain *bd, struct elf_binary *elf, @@ -744,9 +862,93 @@ static int __init pvh_place_kernel( return 0; } +static void __init pvh_place_initrd( + const struct boot_domain *bd, + const struct elf_binary *elf, + struct hvm_modlist_entry *mod, + paddr_t *blob_start, + paddr_t *blob_end) +{ + struct domain *d = bd->d; + struct boot_module *initrd = bd->initrd; + struct boot_module try = *initrd; + unsigned long initrd_len = + initrd ? initrd->size - initrd->arch.headroom : 0; + size_t align = 1UL << L3_PAGETABLE_SHIFT; + int rc; + + *blob_start = INVALID_PADDR; + *blob_end = 0; + + if ( !initrd_len ) + return; + + mod->size = initrd_len; + + /* + * As we promise to place below 4G whatever fits there, make a first pass + * limiting permitted addresses. If we can't fit it there, fall back to + * placing above 4G. + */ + for ( paddr_t limit = GB(4); ; ) + { + paddr_t start; + + *blob_start = find_initrd_memory(d, elf, &try, align, limit); + if ( *blob_start != INVALID_PADDR ) + break; + + if ( align == PAGE_SIZE ) + { + if ( !(limit + 1) ) + return; + + limit = -1; + align = 1UL << L3_PAGETABLE_SHIFT; + try = *initrd; + continue; + } + + align >>= PAGETABLE_ORDER; + + start = ROUNDDOWN(try.start + try.arch.headroom, align); + if ( start > try.start ) + { + /* Free (part of) and reduce headroom. */ + try.arch.headroom -= start - try.start; + try.size -= start - try.start; + try.start = start; + } + } + + /* Free unused headroom, if any. */ + if ( try.start > initrd->start ) + { + init_domheap_pages(initrd->start, try.start); + *initrd = try; + } + + rc = pvh_map_initrd(d, initrd, *blob_start, get_order_from_bytes(align)); + if ( rc ) + { + printk("Failed to map initrd @ %#lx: %d\n", *blob_start, rc); + return; + } + + rc = assign_pages(maddr_to_page(initrd->start), + PFN_UP(initrd->size), d, dom0_memflags); + if ( rc ) + panic("%pd: cannot assign initrd RAM: %d\n", d, rc); + + mod->paddr = *blob_start + initrd->arch.headroom; + *blob_end = *blob_start + initrd->size; + initrd->arch.released = true; +} + static int __init pvh_load_kernel( const struct boot_domain *bd, struct elf_binary *elf, + struct hvm_modlist_entry *mod, paddr_t *start_info_addr) { struct domain *d = bd->d; @@ -756,9 +958,8 @@ static int __init pvh_load_kernel( size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0; const char *initrd_cmdline = NULL; size_t extra_space; - paddr_t last_addr; + paddr_t last_addr, initrd_start = 0; struct hvm_start_info start_info = { 0 }; - struct hvm_modlist_entry mod = { 0 }; struct vcpu *v = d->vcpu[0]; int rc; @@ -775,15 +976,18 @@ static int __init pvh_load_kernel( /* * Find a RAM region big enough (and that doesn't overlap with the loaded - * kernel) in order to load the initrd and the metadata. Note it could be - * split into smaller allocations, done as a single region in order to - * simplify it. + * kernel) in order to load the initrd (if it wasn't mapped directly above) + * and the metadata. Note it could be split into smaller allocations, done + * as a single region in order to simplify it. */ extra_space = sizeof(start_info); if ( initrd ) { - size_t initrd_space = elf_round_up(elf, initrd_len); + size_t initrd_space = 0; + + if ( !mod->paddr ) + initrd_space = elf_round_up(elf, initrd_len); if ( initrd->arch.cmdline_pa ) { @@ -795,21 +999,24 @@ static int __init pvh_load_kernel( initrd_space += strlen(initrd_cmdline) + 1; if ( initrd_space ) - extra_space += ROUNDUP(initrd_space, PAGE_SIZE) + sizeof(mod); + extra_space += ROUNDUP(initrd_space, PAGE_SIZE) + sizeof(*mod); + else if ( mod->paddr ) + extra_space += sizeof(*mod); else initrd = NULL; } extra_space += elf_round_up(elf, cmdline_len); - last_addr = find_memory(d, elf, extra_space); + last_addr = find_memory(d, elf, mod, extra_space); if ( last_addr == INVALID_PADDR ) { - printk("Unable to find a memory region to load initrd and metadata\n"); + printk("Unable to find a memory region to %s metadata\n", + mod->paddr ? "put" : "load initrd and"); return -ENOMEM; } - if ( initrd != NULL ) + if ( initrd && !mod->paddr ) { rc = hvm_copy_to_guest_phys(last_addr, __va(initrd->start + initrd->arch.headroom), @@ -820,28 +1027,29 @@ static int __init pvh_load_kernel( return rc; } - mod.paddr = last_addr; - mod.size = initrd_len; + initrd_start = last_addr; last_addr += elf_round_up(elf, initrd_len); - if ( initrd_cmdline ) - { - size_t len = strlen(initrd_cmdline) + 1; - - rc = hvm_copy_to_guest_phys(last_addr, initrd_cmdline, len, v); - if ( rc ) - { - printk("Unable to copy module command line\n"); - return rc; - } - mod.cmdline_paddr = last_addr; - last_addr += len; - } - last_addr = ROUNDUP(last_addr, PAGE_SIZE); } /* Free temporary buffers. */ free_boot_modules(); + if ( initrd_cmdline ) + { + size_t len = strlen(initrd_cmdline) + 1; + + rc = hvm_copy_to_guest_phys(last_addr, initrd_cmdline, len, v); + if ( rc ) + { + printk("Unable to copy module command line\n"); + return rc; + } + mod->cmdline_paddr = last_addr; + last_addr = ROUNDUP(last_addr + len, PAGE_SIZE); + } + else if ( initrd && !mod->paddr ) + last_addr = ROUNDUP(last_addr, PAGE_SIZE); + rc = hvm_copy_to_guest_phys(last_addr, bd->cmdline, cmdline_len, v); if ( rc ) { @@ -859,7 +1067,10 @@ static int __init pvh_load_kernel( if ( initrd != NULL ) { - rc = hvm_copy_to_guest_phys(last_addr, &mod, sizeof(mod), v); + if ( !mod->paddr ) + mod->paddr = initrd_start; + + rc = hvm_copy_to_guest_phys(last_addr, mod, sizeof(*mod), v); if ( rc ) { printk("Unable to copy guest modules\n"); @@ -867,7 +1078,7 @@ static int __init pvh_load_kernel( } start_info.modlist_paddr = last_addr; start_info.nr_modules = 1; - last_addr += sizeof(mod); + last_addr += sizeof(*mod); } start_info.magic = XEN_HVM_START_MAGIC_VALUE; @@ -1441,6 +1652,8 @@ int __init dom0_construct_pvh(const stru unsigned int nr_orig_e820; struct acpi_info acpi = {}; struct vmx_info vmx = {}; + struct hvm_modlist_entry initrd = {}; + paddr_t blob_start, blob_end; int rc; printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id); @@ -1517,7 +1730,10 @@ int __init dom0_construct_pvh(const stru return rc; } - rc = pvh_populate_p2m(d, orig_e820, nr_orig_e820); + pvh_place_initrd(bd, &elf, &initrd, &blob_start, &blob_end); + + rc = pvh_populate_p2m(d, orig_e820, nr_orig_e820, + PFN_DOWN(blob_start), PFN_UP(blob_end)); if ( rc ) { printk("Failed to setup Dom0 physical memory map\n"); @@ -1526,7 +1742,7 @@ int __init dom0_construct_pvh(const stru xvfree(orig_e820); - rc = pvh_load_kernel(bd, &elf, &start_info); + rc = pvh_load_kernel(bd, &elf, &initrd, &start_info); if ( rc ) { printk("Failed to load Dom0 kernel\n"); From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:25:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:25:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445960.1661857 (Exim 4.92) (envelope-from ) id 1xGBLq-00046R-5f; Mon, 12 Oct 2026 08:25:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445960.1661857; Mon, 12 Oct 2026 08:25: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 1xGBLq-00046I-26; Mon, 12 Oct 2026 08:25:42 +0000 Received: by outflank-mailman (input) for mailman id 1445960; Mon, 12 Oct 2026 08:25:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBLp-000463-5q for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:25:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBLo-005Nw8-Ik for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:25:40 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9982-8faa-0a2a0a5109dd-0a2a4505d08c-14 for ; Mon, 12 Oct 2026 10:25: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 6acc9984-4cb1-0a2a45050019-d1558035cd23-3 for ; Mon, 12 Oct 2026 10:25:40 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a022fee0caso13416615e9.1 for ; Mon, 12 Oct 2026 01:25: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-4a18bf2caf4sm299209375e9.10.2026.10.12.01.25.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:25: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=1791793540; x=1792398340; 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=nPflYh9iV2cqTwtU0Ycr8SkIvuVGwONc8rRZZ7gFcoo=; b=aagVS14P1v3Hc2rxFb0qERnxKHZQtTtzDjyCMfqSd9inlQQswgfHRlQ8jlSofMTmvn evCyLSN5apamWDMD+wV5h0V0wnL9whEI1dexq0QowttFZefZiJHQZ03w/UmIuYahSehr e4feCf694tQOHWo9UVA/FOUmgL+8w7wQe06AICkUrj4iKIWzicDU5UmKNfSnSfGkFE3V 42owcxHrxxqZ5+FPWq2fihm9OtmjSttgtE+lg9pSLKpPsmRr+YO+vmsF0G/zIgR6q2SV w61CZRh4YwgCQx+BEXVXIpj7zzdCd6xopFJ0+ccj2e2B3HEuIN6UDnhFqoRgzeUU9DXe 2dCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793540; x=1792398340; 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=nPflYh9iV2cqTwtU0Ycr8SkIvuVGwONc8rRZZ7gFcoo=; b=l0co/xxlPd4hIHGlXHPRcAt4hadai1UXfNXEJqqqbtEDPTOwZViFLNVH+m29GWTlos 9rZ+/5BSfc/uilWxdqI1Jb7mTZcJU+HgZYwRs+wbP6Wq5pgpFAsbhDnAXgsYoboLsOTC X1KzMFXhJG6IW2qJmgE0oUQW7siMOKVy/6Imuf0dK1awy03MLYdCBgwZxFcveXaKbuRI o40ogT1zGmNdZwzMMa0tk5/VDjGH9SRsPLJ10a3y6SXRJBxL8xfv1FXuMBZGZA51QLcs 12VRnmPv0zdF+F4zRaUtCZhh9Fw/s56JLOHFSNO14v+tktDy02mBn0lUC6ll3bLdKkYK tyIQ== X-Gm-Message-State: AFq9FYKzIsnumIWuth1b8n0963P1DY+emCYGIn1IOZj/A/L7HLdFrFmD 1LG7dIj3k3YfrmetaesjpWomy8yHdjhipyvgSYoC91eKsUIimfHzfGhEoJRxMMjZuPA+FNzhd1o TI6t7HQ== X-Gm-Gg: AYBFou2Yul8iZjTpPP6rvasbjpWB6IRCiM4gm9uIa0snd0Y4aE3vPuUckDRbZp0i8bt wuhI7YE1ZQdQz5+5ythsH9dFJ2XOXj7s7mJgerekNYWnIJXy3Jx+d1Wkhou0+lOUganO96MAOdR DIp4/xJDtB2fFPCA/PL5jXaas+xjxm76wFDPyWE88r4agfNp6HuZHCEG/S2SFUom/ZcMTER3BE1 yf0bRIulKkfWj0GfgoTDVi3612+1/Eor9CxxWDhOpElnM0NL4UEf61kPu6NyZAQ8nqbFwx2BnDN xSgTmK6hqnA+MV05THZw8UfPlu8fT5rNWlCppGLCHBKnSBJiEj/9K5eaiWUgiQK3M6w5qf7BYKE /yxgSxLmAEglDpDavthyDqENx+/JrXTXv6VK8mDK3boi13d8ii0t0Z7lQtMbGq2KKK0SWe6w8TO UYQJrRnZW5+qc80s8lxoRZFffWkP0VgX4yZE3QLDRY/F8Hac6n5iJR4lOiDkwA7+JdcPJJfzvE9 AD2NtGvS0yf1fP3XuaJBylhBg+M7/fOqk5eo3qdFe1oCdAuwj/p8VB5T6nGaAQNj2QpTJp6 X-Received: by 2002:a05:600c:354a:b0:49c:d019:70c5 with SMTP id 5b1f17b1804b1-4a18e3ef23cmr156159795e9.0.1791793539659; Mon, 12 Oct 2026 01:25:39 -0700 (PDT) Message-ID: <032c1cb0-55b8-489d-bcf4-4d4c14a590ae@suse.com> Date: Mon, 12 Oct 2026 10:25:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 12/15] x86/PVH: heed the kernel in pvh_steal_ram() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791793540-F58AE2A1-475A7483/10/78276251493 X-purgate-type: spam X-purgate-size: 5992 While the function working downwards will typically result in no conflict with the kernel range, there's no guarantee of that. Fixes: 1d74282c455f ("x86: setup PVHv2 Dom0 ACPI tables") Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -186,8 +186,12 @@ static int __init pvh_populate_memory_ra /* Steal RAM from the end of a memory region. */ static int __init pvh_steal_ram(struct domain *d, unsigned long size, unsigned long align, paddr_t limit, + const struct elf_binary *elf, paddr_t *addr) { + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, + PAGE_SIZE); unsigned int i = d->arch.nr_e820; /* @@ -203,6 +207,11 @@ static int __init pvh_steal_ram(struct d continue; *addr = (entry->addr + entry->size - size) & ~(align - 1); + + /* Avoid kernel range, if this is the region it lives in. */ + if ( *addr < kernel_end && *addr + size > kernel_start ) + *addr = (kernel_start - size) & ~(align - 1); + if ( *addr < entry->addr || /* Don't steal from the low 1MB due to the copying done there. */ *addr < MB(1) ) @@ -275,6 +284,7 @@ struct vmx_info { static int __init pvh_place_vmx_realmode_helpers( struct domain *d, + const struct elf_binary *elf, struct vmx_info *info) { paddr_t gaddr; @@ -285,7 +295,7 @@ static int __init pvh_place_vmx_realmode * structure (which accounts for the first 104b) doesn't cross a page * boundary. */ - if ( !pvh_steal_ram(d, HVM_VM86_TSS_SIZE, 128, GB(4), &gaddr) ) + if ( !pvh_steal_ram(d, HVM_VM86_TSS_SIZE, 128, GB(4), elf, &gaddr) ) { d->arch.hvm.params[HVM_PARAM_VM86_TSS_SIZED] = VM86_TSS_UPDATED | ((uint64_t)HVM_VM86_TSS_SIZE << 32) | gaddr; @@ -300,7 +310,7 @@ static int __init pvh_place_vmx_realmode printk("Unable to allocate VM86 TSS area\n"); /* Steal some more RAM for the identity page tables. */ - if ( pvh_steal_ram(d, PAGE_SIZE, PAGE_SIZE, GB(4), &gaddr) ) + if ( pvh_steal_ram(d, PAGE_SIZE, PAGE_SIZE, GB(4), elf, &gaddr) ) { printk("Unable to find memory to stash the identity page tables\n"); return -ENOMEM; @@ -1157,7 +1167,10 @@ static int __init cf_check acpi_set_intr return 0; } -static int __init pvh_setup_acpi_madt(struct domain *d, paddr_t *addr) +static int __init pvh_setup_acpi_madt( + struct domain *d, + const struct elf_binary *elf, + paddr_t *addr) { struct acpi_table_madt *madt; struct acpi_table_header *table; @@ -1182,7 +1195,7 @@ static int __init pvh_setup_acpi_madt(st if ( !*addr ) { /* Reserve space to place the new MADT in guest memory space. */ - if ( pvh_steal_ram(d, size, 0, GB(4), addr) ) + if ( pvh_steal_ram(d, size, 0, GB(4), elf, addr) ) { printk("Unable to steal guest RAM for MADT\n"); return -ENOMEM; @@ -1337,8 +1350,11 @@ static bool __init pvh_acpi_xsdt_table_a strncmp(sig, ACPI_SIG_FACS, ACPI_NAME_SIZE)); } -static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr, - paddr_t *addr) +static int __init pvh_setup_acpi_xsdt( + struct domain *d, + paddr_t madt_addr, + const struct elf_binary *elf, + paddr_t *addr) { struct acpi_table_xsdt *xsdt; struct acpi_table_header *table; @@ -1374,7 +1390,7 @@ static int __init pvh_setup_acpi_xsdt(st if ( !*addr ) { /* Reserve space to place the new XSDT in guest memory space. */ - if ( pvh_steal_ram(d, size, 0, GB(4), addr) ) + if ( pvh_steal_ram(d, size, 0, GB(4), elf, addr) ) { printk("Unable to find guest RAM for XSDT\n"); return -ENOMEM; @@ -1473,6 +1489,7 @@ struct acpi_info { static int __init pvh_place_acpi( struct domain *d, + const struct elf_binary *elf, struct acpi_info *info) { unsigned int i; @@ -1529,15 +1546,15 @@ static int __init pvh_place_acpi( } } - rc = pvh_setup_acpi_madt(d, &info->madt); + rc = pvh_setup_acpi_madt(d, elf, &info->madt); if ( rc ) return rc; - rc = pvh_setup_acpi_xsdt(d, info->madt, &info->xsdt); + rc = pvh_setup_acpi_xsdt(d, info->madt, elf, &info->xsdt); if ( rc ) return rc; - if ( pvh_steal_ram(d, sizeof(struct acpi_table_rsdp), 0, GB(4), + if ( pvh_steal_ram(d, sizeof(struct acpi_table_rsdp), 0, GB(4), elf, &info->rsdp) ) { printk("Unable to allocate guest RAM for RSDP\n"); @@ -1565,11 +1582,11 @@ static int __init pvh_setup_acpi( .length = sizeof(rsdp), }; - rc = pvh_setup_acpi_madt(d, &info->madt); + rc = pvh_setup_acpi_madt(d, NULL, &info->madt); if ( rc ) return rc; - rc = pvh_setup_acpi_xsdt(d, info->madt, &info->xsdt); + rc = pvh_setup_acpi_xsdt(d, info->madt, NULL, &info->xsdt); if ( rc ) return rc; @@ -1707,7 +1724,7 @@ int __init dom0_construct_pvh(const stru return rc; } - rc = pvh_place_acpi(d, &acpi); + rc = pvh_place_acpi(d, &elf, &acpi); if ( rc ) { printk("Failed to place Dom0 ACPI tables: %d\n", rc); @@ -1725,7 +1742,7 @@ int __init dom0_construct_pvh(const stru */ !vmx_unrestricted_guest(d->vcpu[0]) ) { - rc = pvh_place_vmx_realmode_helpers(d, &vmx); + rc = pvh_place_vmx_realmode_helpers(d, &elf, &vmx); if ( rc ) return rc; } From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:26:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:26:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445965.1661866 (Exim 4.92) (envelope-from ) id 1xGBMD-0004dU-Bq; Mon, 12 Oct 2026 08:26:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445965.1661866; Mon, 12 Oct 2026 08:26: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 1xGBMD-0004dN-8a; Mon, 12 Oct 2026 08:26:05 +0000 Received: by outflank-mailman (input) for mailman id 1445965; Mon, 12 Oct 2026 08:26:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBMC-0004bx-8c for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:26:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBMB-00B9Um-Li for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:26:03 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9997-2eae-0a2a0a5409dd-0a2a450aaf64-8 for ; Mon, 12 Oct 2026 10:26:03 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc999b-f2d2-0a2a450a0019-d1558030dc5a-3 for ; Mon, 12 Oct 2026 10:26:03 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a16aaf2067so19667845e9.0 for ; Mon, 12 Oct 2026 01:26: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-4a18bf2caf4sm299236925e9.10.2026.10.12.01.26.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:26: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: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=1791793563; x=1792398363; 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=gbCqWsCuxEY5XIFrNsxca019l5IysgC/aX8g/IMX/Vc=; b=ejrPi7yNprjNkkaUc7fC4Ub2CCgzigCpjaIFGKL/tjp5isbfv2Q80Kc+BE0b2n5v4u qnQOvqyQGVzkrxsYB+q/Sw8eaYKvZY1MzNjcjap1bnKdCQxgvxQTEwhclLQ0hXYAd9Hx YAvh/rO0Z9yNTSaOE+Pnq8c6t02nTRuFaFcILsrkt1H9l2RvnROWcdjeMZvK1CY8nlyx HbyY4vGnNLQTqquxnKeBu8gwNEPpMJAUe/TV7yx2QhBqNw3sH7OrkBBbnYJbJ8TPcS6N o56S4nlNAGJlCbPJEj+RKS9aD3uVxffdKTMs6YXDKANBGBSKoMBpx9SRDSGAjyl6wAK/ JbQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793563; x=1792398363; 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=gbCqWsCuxEY5XIFrNsxca019l5IysgC/aX8g/IMX/Vc=; b=Df6VIwxegJHPEXV7MOgKf2afOtp1GJYRZRT/dZASsDGHYA31Pmukkj2vDzRNdrfZYR d0wknU4Ci0MsJTJHgtrItuhrc1L9vlZBJBjjbS37SUZ4M0KYQuG3vSXZNODC3JVXp/GM UWMs41Thw0+UM3sZeq3uAYiL+g+JaUPYtyyMrjMqGNaNi1wOC/Yhp+a2VCq6u/D+S+Jv kKnUoFJHtyLczBSbw/Q/S7lByR1HhEYDZX+qzfw26s/G8d8ZAGBadA5aYCr7bAim1o9W BN1n5sbW9dEcdXvyxtCdo4Sg6668xcQi9d9EuVpPkclLCJXKKjEBw1oTwp4Yl9HOqiwY CIUA== X-Gm-Message-State: AFq9FYKxTGayj35mDleY/Nql0/iV5LmHzrf19pkBKlwhAF0VCyMwoDhF LktbrQHOHbfE2l2yFJIJC1U8+ec+r+qm6YBBGeMb2vwkWTFeHad/JyEPVNTPFT+CBE4xA0ATU7R Njeaa/Q== X-Gm-Gg: AYBFou0L3RfBF5rH/VWK/Q9XKM9O9zIv65LE6AQulhPJjL7dELcLwOZe2KQaVZbBPIb 6mDkWrUSdE+W3w6BvvCehzkR22HkvSZgltlrGFDl1HvI/o8oG6K6F6FJ4BlgLvGyBuAVY9DyEDX IMe8Qy/lkItsIwvc/NcXGOQUvMnotjFUrG/ddGcZYB6wIowGbspJDIV/ZovfF7S7p+LNyLkLMOS 2DyboUr0ORPC64vSuA5x9VF3nxvv8z/T7cQ3hubXbJhaR/8Qk4zLImAHOlwDNRIK1tC9FimQqSb RJ9UJxn6dpvzcT+UgVKXbkGx5okSKEzFrDYFpbtANIIqbggi91i3JgAX3MIHm5kANyma1AtNjci 96ksngsv9EX30oeRTkWCJqz7libUiAwH5pi73yAyn5qM7UfOi/nt3/u46phSCdlf5z274vXPoMq zNNgurBytCgCJrve6VwTBth01xNpH+oHtNYxF8ehsOEkpXjK2jxKvVJ0LRyG9U5i8v42rFpVySt NiFtar2iz0iJ56oY6dIhUQzldanuy1YuD30LBT2wkfd1ktkUhvzn2P4OYNquQQ= X-Received: by 2002:a05:600c:609a:b0:4a1:7108:c2b6 with SMTP id 5b1f17b1804b1-4a18e4effabmr161479985e9.31.1791793562962; Mon, 12 Oct 2026 01:26:02 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:26:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 13/15] x86/PVH: prefer smaller E820 regions for stealing from From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791793563-58FC6CFC-A7FF35A4/10/78276251493 X-purgate-type: spam X-purgate-size: 2429 Nibbling from the end of large regions tends to split full 2Mb (or even full 1Gb) ranges, which Dom0 may otherwise be able to use superpage mappings for (when, like Linux, it e.g. has a direct-map). Signed-off-by: Jan Beulich --- Instead of comparing original sizes, we may want to compare remaining sizes. That may (slightly) further increase the risk of successive steals not ending up adjacent, though. There is the (pre-existing and purely theoretical at this point) risk of (entry->addr + entry->size - size) underflowing. Do we think we need to cover that remote case? --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -192,6 +192,7 @@ static int __init pvh_steal_ram(struct d paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, PAGE_SIZE); + struct e820entry *good = NULL; unsigned int i = d->arch.nr_e820; /* @@ -202,26 +203,35 @@ static int __init pvh_steal_ram(struct d while ( i-- ) { struct e820entry *entry = &d->arch.e820[i]; + paddr_t res; if ( entry->type != E820_RAM || entry->addr + entry->size > limit ) continue; - *addr = (entry->addr + entry->size - size) & ~(align - 1); + res = (entry->addr + entry->size - size) & ~(align - 1); /* Avoid kernel range, if this is the region it lives in. */ - if ( *addr < kernel_end && *addr + size > kernel_start ) - *addr = (kernel_start - size) & ~(align - 1); + if ( res < kernel_end && res + size > kernel_start ) + res = (kernel_start - size) & ~(align - 1); - if ( *addr < entry->addr || + if ( res < entry->addr || /* Don't steal from the low 1MB due to the copying done there. */ - *addr < MB(1) ) + res < MB(1) ) continue; - entry->size = *addr - entry->addr; - return 0; + if ( !good || good->size > entry->size ) + { + good = entry; + *addr = res; + } } - return -ENOMEM; + if ( !good ) + return -ENOMEM; + + good->size = *addr - good->addr; + + return 0; } /* NB: memory map must be sorted at all times for this to work correctly. */ From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:26:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:26:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445970.1661874 (Exim 4.92) (envelope-from ) id 1xGBMY-00054I-IP; Mon, 12 Oct 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 1445970.1661874; Mon, 12 Oct 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 1xGBMY-00054B-FY; Mon, 12 Oct 2026 08:26:26 +0000 Received: by outflank-mailman (input) for mailman id 1445970; Mon, 12 Oct 2026 08:26:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBMW-00051n-Oj for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:26:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBMW-00B9bw-5V for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:26:24 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc99af-2eae-0a2a0a5409dd-0a2a4506cd1e-2 for ; Mon, 12 Oct 2026 10:26:24 +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 6acc99af-195a-0a2a45060019-d155dd2cd05c-3 for ; Mon, 12 Oct 2026 10:26:24 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48afe0081a6so1083685f8f.2 for ; Mon, 12 Oct 2026 01:26: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 ffacd0b85a97d-48db9abce2fsm18374605f8f.33.2026.10.12.01.26.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:26: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=1791793583; x=1792398383; 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=3Fk8ubxGACynMKa2lozxkb2C5OaTEVTs40otMwFTXqk=; b=aOcG8Aq4+bzIRntKvjo82UdKnLklVy9vTQkYrj0HYIEBB37fQD985JVANwpLyLIn+M wu8C++5kCkyB5aQAniE3WHLBmEsJoWD0Eal/oZ1TiQndQNUIF75Y72MTfP38ZXZwIe4p FjubqEnvv42bQN6hBZ+POel9DpkEahcrtRzRt1qyvYlwqi1oK0cr1m4r3FhHE/GDos/3 kWcIhFJ7deGcer810yG1MB6ClkmFqD8IjzwTPlDAeRrH+g2kpvTasJ7zDZJfADMrW91S 0ZcxG0qIUs5hrptnO/7GfjQsXkUdcIuEVN/o3pwr6iwWrXoSasjrpcbY7tosvGvB/WpG MTeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793583; x=1792398383; 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=3Fk8ubxGACynMKa2lozxkb2C5OaTEVTs40otMwFTXqk=; b=xZwiy3KQ1dBlQ7dFlhfdgnPaRyDFoQoQjX3b278cjCk7ybOuGxUDmMPMIMcHDctHDm qGiyVjKxdMroVRrwqdaM9ce8dKVLpP3kt4pgqXgc7Th0Eyv45yaH1K28iy1egkEyccuP 9fOGard7RbL/SogtGIFTfyhrZqkZJBbV3q1M7mU2hAHc3++43lsBYm1DhdtqgcVTeEzu /ctg7Il6KlFey5jEM8K2rCJnpU92lckIB3WvBrOs+yd9FqeRxsRyEvcQrl6EorR6+DUk tkW0Jbzx3J0GKzJEhaE7UwAEGOEYhcfpGrs7WO8qgOMUcdUKBXGyN8o+zr7kN4/HCFMq Bk5g== X-Gm-Message-State: AFq9FYKNQWfXLZb8mvRxOG8gSWtry21yCzoGo0cjQTRMnMqavoKDbKWk YfW7GWBmTUIqRNm7n6PbfrkaOhx48icYJMOktAXA3VQvKOAgw/3dxXbgE+BqilZz1k0dV+Tp3l9 ftgGcwg== X-Gm-Gg: AYBFou1GoWN8L9qze9zA/6daT2LLa+DPzKKNtwxh8jrKhB0gXqeTdt2gN9Q4cL60M9T phXM/VBHDCykLci3XIyY4xosLDoqSZILjQP5aqujezHCM5paEIvUUxp9Sv82m85UVK044eo1yh1 U0AY1EnMK4MLN+ScFfmiB9twEHSI8g31KvRtQQs4DHt88c3J/w3Su50d4q+QQUCdcE6spAF0xTZ CskG/Xbr5Qa7cfojTNli1MV+ISti6BrQ6NgFYy1KjcZDmdxQzuwsPjA4oVFWwpJAFuyBlWWLAq2 mfj0ItTa7sea6gdKpgITWyn5cm6XiuRlEHaM6YnsYvnUrDdaD9/W1sUg4an9JtXCR1F8NhZ3zrn 3vMaGWq4atuV34HBq/NOixP8SIPtF6jFYa17oD7IDbwzYHqhwnA0AKIlpbbxylol4dC9ZRR5pix FocYPnytAxhPyAF4mbAWAVbgpJQ9vr9otuR30OXje87KbHngCebUQvipwUHXMiBpeYOJHwW17z2 L3/D7k47mTI8Hv/x91tUW9CM8oR/qZz4YvmvEwDuInaYGRcuSCX59pwDgV3M6k= X-Received: by 2002:a05:6000:151:b0:487:21be:dcc6 with SMTP id ffacd0b85a97d-48dbaae53b4mr12788221f8f.21.1791793583338; Mon, 12 Oct 2026 01:26:23 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:26:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 14/15] x86/PVH: log Dom0's E820 map earlier From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1791793584-FCC0777B-F215BB58/10/78276251493 X-purgate-type: spam X-purgate-size: 2038 Do this as soon as it's final. For debug builds also mark it final, with assertions put in place to make sure it won't further be altered. (For a release build such further altering isn't the end of the world normally, so the situation is left alone there.) Switch to using %pd while moving the code up. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -46,6 +46,9 @@ */ #define HVM_VM86_TSS_SIZE 265 +/* Marker set once Dom0's E820 isn't supposed to change anymore */ +static bool __initdata e820_finalized; + static unsigned int __initdata acpi_intr_overrides; static struct acpi_madt_interrupt_override __initdata *intsrcovr; @@ -195,6 +198,8 @@ static int __init pvh_steal_ram(struct d struct e820entry *good = NULL; unsigned int i = d->arch.nr_e820; + ASSERT(!e820_finalized); + /* * Alignment 0 should be set to 1, so it doesn't wrap around in the * calculations below. @@ -241,6 +246,8 @@ static int __init pvh_add_mem_range(stru struct e820entry *map; unsigned int i; + ASSERT(!e820_finalized); + for ( i = 0; i < d->arch.nr_e820; i++ ) { uint64_t rs = d->arch.e820[i].addr; @@ -1759,6 +1766,13 @@ int __init dom0_construct_pvh(const stru pvh_place_initrd(bd, &elf, &initrd, &blob_start, &blob_end); + if ( opt_dom0_verbose ) + { + printk("%pd memory map:\n", d); + print_e820_memory_map(d->arch.e820, d->arch.nr_e820); + e820_finalized = true; + } + rc = pvh_populate_p2m(d, orig_e820, nr_orig_e820, PFN_DOWN(blob_start), PFN_UP(blob_end)); if ( rc ) @@ -1794,12 +1808,6 @@ int __init dom0_construct_pvh(const stru if ( rc ) return rc; - if ( opt_dom0_verbose ) - { - printk("Dom%u memory map:\n", d->domain_id); - print_e820_memory_map(d->arch.e820, d->arch.nr_e820); - } - return 0; } From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:27:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:27:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445978.1661883 (Exim 4.92) (envelope-from ) id 1xGBN5-0005hi-UW; Mon, 12 Oct 2026 08:26:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445978.1661883; Mon, 12 Oct 2026 08: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 1xGBN5-0005hb-Rv; Mon, 12 Oct 2026 08:26:59 +0000 Received: by outflank-mailman (input) for mailman id 1445978; Mon, 12 Oct 2026 08:26:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBN5-0005gJ-47 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:26:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBN4-00B9lk-Gr for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:26:58 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc99cb-2eae-0a2a0a5409dd-0a2a4502a292-18 for ; Mon, 12 Oct 2026 10:26:58 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc99d2-6ca4-0a2a45020019-d155802fd4ab-3 for ; Mon, 12 Oct 2026 10:26:58 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a02667ccebso10434985e9.0 for ; Mon, 12 Oct 2026 01:26: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 ffacd0b85a97d-48db9acc936sm18062413f8f.44.2026.10.12.01.26.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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=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=1791793618; x=1792398418; 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=QQBVOxw25q4egEqsMoJm6AFAF/6zt2nS86ied2+T6eQ=; b=AFLLHhCX1Op1dAcSlnYJhgKmdfTDNau4dcRMBIF84+1OG58x7u+vDvkHq/JAmbZbuc IT1TNE+zTTyvynCG1iFlFr9QNMz8CMd27Y8jffgfOgP1SsbNc6OV3QQv48gpWN9eALxF MExq7HNqYlDl1XoomYXrQFOSKLTXRj4hqMoSkVuMI7I7ywv9Xu8RyCfiPxwfeEwjK/yP eVITTkxvbpKicGE9fD40vxGf7LjyFspblp+2Rq7mm+AweI0+4fZG6/SzXjIo5XNF9PyD Vhiqq4qi1KCDCHhMMV7FH7bfC/pis8yMo2TjE4Eb+5OEqc4eHhz4XREMTxNW12v3uMb+ G5Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793618; x=1792398418; 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=QQBVOxw25q4egEqsMoJm6AFAF/6zt2nS86ied2+T6eQ=; b=1ghn6CGrtOnLbOdCxpS/SpgmI9gpnB91KhXaiR6XIA96GoSYbUKb9oCnN6n7LTcRsp 8XjN7OVQQd302X+5KhY20L8luUcsBtau1kz84qoqZMD49IDTpZJQM0NAfZsNRjJaFTwT wUCe6LOT7SRBVfpfKw6ksYd/3IaCBKDXG8Zo0dEHrEInGe4cmwhGUgQxQpti4GIaDkIH Zv/Wimh0BLUqNJ6Q9+cx6cS+X3fBD8UNZGL5AIrt03MZC3xiFTHb9FrQ93BJbe6zvuHH JXuQCDS++2e/nXYmsuKKlRbjQouaWT2xydLuAc1UkzHijGe5EBArV0oIIGaJJT56AlSz jXzA== X-Gm-Message-State: AFq9FYKyFqrXSmI3rEjpGIOu+y7u6A1ziqtCW8OuT7beQscs1AF4BQTD Mkbbr5h7unEe+x7kkxEiTdnnHKueJMbc8Mp9DL/mMPcrTV42gI7eFcmsojwqb5h9SMq5rA3CW+i QLYKyDQ== X-Gm-Gg: AYBFou31MWfy110gjLPm4XLEdSLByL6/y9tCwDWme54OvlyZ3wuwGf6+mQ5M4Q1zLtO tEJ+XGIo85GQkO0g3zZvlXHoQjQtkHxHDXH4895TSX/1cGiiIcKrjUD+KRpYZx3ocm7bTvwN5Xf QvKFhbBRxzEgP+uk3zCHUs8lwVcm1s74pKhnNkSyqcLGfJ85OAk/BvAPdG1AFOHRZ/tq0AurP0G TMcBOZN3qPf8HDwLtlUo1gpnnEtTesndg14/+J2N59eGOw7KpKj1TeA1fD6sAiZaNC8YA1ZK6Gs Fjll+0/h/8fdA8iclqm7PWPzsGBpRdvme80hIitz8Qr8mJiUM280LdCqOYzx7WW62WbWcco+7ZQ I1wwcUsSH9AeFos+A80wgKyDFea/G/kErFcX5B8HgHizz0lfK5EPjvAf9roib/+3UP0YIgQvKZY r46k4CSA1W4t6hd/Rx/0YPlBcnrzGc9cPIzqJEr2+DQKVqQrW0wiurB/uRYfI7MMoUahYVDJXIF okxcXWwYpZ631PSKtf7FG9vd3Fj62wHSMQc2zKbAwLyr1Ui6Lvm0GcHsIfqPA== X-Received: by 2002:a05:600d:4452:20b0:4a1:90d7:88a8 with SMTP id 5b1f17b1804b1-4a190d7891emr105478065e9.25.1791793617885; Mon, 12 Oct 2026 01:26:57 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:26:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 15/15] x86/PVH: simplify writing of Dom0's RSDP From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1791793618-307C22AC-EDB727F3/10/78276251493 X-purgate-type: spam X-purgate-size: 2878 Now that we establish where the RSDP is to live before actually loading the kernel (and writing start-info there) we can simply hand the pointer there, eliminating the need for the (fragile) separate write to the field out of pvh_setup_acpi(). Signed-off-by: Jan Beulich --- Alternatively we could move start_info to the top-level function, have pvh_load_kernel() and pvh_setup_acpi() fill what need filling, and do the write from the top-level function. Yet it looks to me as if this was more churn for little extra gain. --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -976,7 +976,8 @@ static int __init pvh_load_kernel( const struct boot_domain *bd, struct elf_binary *elf, struct hvm_modlist_entry *mod, - paddr_t *start_info_addr) + paddr_t *start_info_addr, + paddr_t rsdp) { struct domain *d = bd->d; struct boot_module *initrd = bd->initrd; @@ -1110,6 +1111,7 @@ static int __init pvh_load_kernel( start_info.magic = XEN_HVM_START_MAGIC_VALUE; start_info.flags = SIF_PRIVILEGED | SIF_INITDOMAIN; + start_info.rsdp_paddr = rsdp; rc = hvm_copy_to_guest_phys(last_addr, &start_info, sizeof(start_info), v); if ( rc ) { @@ -1587,10 +1589,7 @@ static int __init pvh_place_acpi( return 0; } -static int __init pvh_setup_acpi( - struct domain *d, - struct acpi_info *info, - paddr_t start_info) +static int __init pvh_setup_acpi(struct domain *d, struct acpi_info *info) { int rc; struct acpi_table_rsdp *native_rsdp, rsdp = { @@ -1642,20 +1641,6 @@ static int __init pvh_setup_acpi( return rc; } - /* Copy RSDP address to start_info. */ - BUILD_BUG_ON(sizeof(info->rsdp) != - sizeof_field(struct hvm_start_info, rsdp_paddr)); - rc = hvm_copy_to_guest_phys(start_info + - offsetof(struct hvm_start_info, rsdp_paddr), - &info->rsdp, - sizeof_field(struct hvm_start_info, rsdp_paddr), - d->vcpu[0]); - if ( rc ) - { - printk("Unable to copy RSDP address to start info\n"); - return rc; - } - return 0; } @@ -1783,7 +1768,7 @@ int __init dom0_construct_pvh(const stru xvfree(orig_e820); - rc = pvh_load_kernel(bd, &elf, &initrd, &start_info); + rc = pvh_load_kernel(bd, &elf, &initrd, &start_info, acpi.rsdp); if ( rc ) { printk("Failed to load Dom0 kernel\n"); @@ -1797,7 +1782,7 @@ int __init dom0_construct_pvh(const stru return rc; } - rc = pvh_setup_acpi(d, &acpi, start_info); + rc = pvh_setup_acpi(d, &acpi); if ( rc ) { printk("Failed to setup Dom0 ACPI tables: %d\n", rc); From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:29:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:29:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445989.1661894 (Exim 4.92) (envelope-from ) id 1xGBP7-0006Pb-A8; Mon, 12 Oct 2026 08:29:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445989.1661894; Mon, 12 Oct 2026 08: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 1xGBP7-0006PU-6T; Mon, 12 Oct 2026 08:29:05 +0000 Received: by outflank-mailman (input) for mailman id 1445989; Mon, 12 Oct 2026 08:29:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBP6-0006PO-NB for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:29:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBP5-00DoR1-TC for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:29:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9a47-8faa-0a2a0a5109dd-0a2a4504dba8-30 for ; Mon, 12 Oct 2026 10:29:03 +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 6acc9a4f-b57f-0a2a45040019-d155dd35f034-3 for ; Mon, 12 Oct 2026 10:29:03 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48afe75f055so1506721f8f.2 for ; Mon, 12 Oct 2026 01:29: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-48db9abdaa5sm18862209f8f.35.2026.10.12.01.29.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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=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=1791793743; x=1792398543; 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=znjWW0/oQ4fsgLFtWk9f6KjTuG5blZFy/mXpEL21xFU=; b=S622oHZO9O1mPXQaG/jH9B0PStRYjPWKNGIf8gqpMKiF/jPk/PtCTJlvSx4d3oimMP UH5vkBHiQre1tGmxRwPglVboPOl+0XRmIIMQTk+dDu8sFRELIyomK7iBT/KhjrwpTEXT rjoBYV/r5sLOY3twSpWqvTpcHMbNHRXyKaFcJ8VrxpboR/9+hIsIrRi+lBAgHHkMfnna dsBdOoxtWWvtWcIhb83i+I+ceR4xutMRiPE2+pplXUJJF6L375lmdIMtxxK4TIWOBBcL cmFOlQ5syLxZAI0qotdtd+hKPTkUSWjWClihj8G0Lt6XrOZEMcqNnabjBlvW1H2NYnY8 1lOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791793743; x=1792398543; 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=znjWW0/oQ4fsgLFtWk9f6KjTuG5blZFy/mXpEL21xFU=; b=jz8dhAVcyOyPHroO6Qx+nvIrXX7912VCk0Ci5hFJbNCKpYhrE2kt+USXKiY6KwCOTy j2y/0tPdnGaEFMKwTDm0aN+CEfAvguYut7YUraAjzkm8syTThWopYnSlDU+3eGVUZAIr 6N6gdbLDwTzF2UEPuWY/DEU9N7/AIEFPDSkT06ZXK32T8XMjDqRqJL9mC8Rb4V3H0tZc kgIrfHjzD1i1VsixeFtcHzauRSYkhCYnja+LwI2shgidts02ajkJ6i0w8ld8geXOV8R+ Fy0wvrLYk0p+lZIqcNsSAscuU1DreHPNH2fTSGHCvOPq3oRpI/mdonWiRV9tvUdFx95D eLCQ== X-Gm-Message-State: AFq9FYKYOeRqiMJhrIjzzghlkn3R2r6xWGtNfTZ/lg3TOaUBuRo/GTdK Pe8sI50/fW+U77f99Maujec0VOXVbrr7P3SY8KDdIvofmY5Cg467nwv84o/2f+gcYSf2H0Ihg4V 52q0klA== X-Gm-Gg: AYBFou003c5+xm4aeqbxKelQvBYcqVwwe92eAAlKYlN1T88DQjsuht/RuDo1uXrXifr SMEplG50FQcKz7ODpvhhMb0vOPSpVmQW+6iqsyLY5h/QO1RLdxjzySkZMutx8+F/wrIJLDiCB+K k7irTlpLkMnmcYlxq4v2mLxdD/uJ1nwHFDro2BgzYMA2SL8hsw98EoB2yeO/DLaIghnNP1Q2Uew Kuw/QrNHAEN89mrBTgQXnLYTbb9S5Bv9sdv/eHYmjUC7uGGqaeysimwev1GLTckdhdPwkU3EjMn Co2D/cZBno+dS2BKuyVDMfssYASaShj43Ibhm/uK9azauz+zPSApNVRHNQ/biYpKQetq2S/leFu coXTKSMRWaEMc6UZE7rK3ZCkZ2ccC1GlpDgiWCwI7Pvyvilo4mTqgzzo/84zCDqO1OB4g1SPkwF M29AJGr9qiL49U+c2ImAXCfOzBxZMzW7zyMYnM6xlunF4GwUNzPnTBnpYOKxCerMypwhCSiPjwr ItX6Di/ZCo+6Ms1GdzzAdFU20hc/YkUUbD/H+7uRsa7hUN6CAjsUfvHbG4MqeY= X-Received: by 2002:a05:6000:4a1b:b0:48b:a4b:5a27 with SMTP id ffacd0b85a97d-48dbaceab84mr15144582f8f.49.1791793743188; Mon, 12 Oct 2026 01:29:03 -0700 (PDT) Message-ID: <98d47bfd-4e8a-40e6-8570-5109bb1d4267@suse.com> Date: Mon, 12 Oct 2026 10:29:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/15] x86: PVH Dom0 loading rework From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791793743-C26CAB50-8A5CA11A/10/78276251493 X-purgate-type: spam X-purgate-size: 1152 On 12.10.2026 10:17, Jan Beulich wrote: > The primary goal is to accommodate large initrd-s without requiring people > to restrict Dom0's memory just for that. Other issues are being addressed > as well, though, and some cleanup is done, in part even outside of the main > target area of this series. > > 01: EFI: guard against oversized modules > 02: PV: make better use of assign_pages() > 03: setup: break out E820_RAM accumulation > 04: setup: special treatment of initrd for PVH Dom0 > 05: PVH: split pvh_load_kernel() > 06: PVH: keep a copy of Dom0's initial E820 map > 07: PVH: lift E820 alignment requirement > 08: PVH: split pvh_setup_acpi() > 09: PVH: split pvh_setup_acpi() As can be seen from the actual patch title, this was a copy-and-paste mistake of mine. Really: 09: PVH: split pvh_setup_vmx_realmode_helpers() Jan > 10: PVH: convert find_memory() to using a rangeset > 11: PVH: try to map initrd directly into Dom0 > 12: PVH: heed the kernel in pvh_steal_ram() > 13: PVH: prefer smaller E820 regions for stealing from > 14: PVH: log Dom0's E820 map earlier > 15: PVH: simplify writing of Dom0's RSDP From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:34:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:34:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445996.1661902 (Exim 4.92) (envelope-from ) id 1xGBUF-0008Jy-Qi; Mon, 12 Oct 2026 08:34:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445996.1661902; Mon, 12 Oct 2026 08:34: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 1xGBUF-0008Jr-Nj; Mon, 12 Oct 2026 08:34:23 +0000 Received: by outflank-mailman (input) for mailman id 1445996; Mon, 12 Oct 2026 08:34:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBUE-0008Jl-5w for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:34:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBUC-00DprD-S8 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:34:20 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9b8a-e002-0a2a0a5209dd-0a2a4501e37e-34 for ; Mon, 12 Oct 2026 10:34:20 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc9b8c-5984-0a2a45010019-d1558029bc36-3 for ; Mon, 12 Oct 2026 10:34:20 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a171b677d2so9103405e9.0 for ; Mon, 12 Oct 2026 01:34: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-4a19303d4a8sm111092365e9.2.2026.10.12.01.34.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01:34: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: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=1791794060; x=1792398860; 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=vKrzVRURgsqxMnlxn6tsEXwvnxfCko5owfMEa5IQtSM=; b=WKNMrZP4HUVxJpu9IvKSALDwIVnoZdjTXc9rSwqGlKovUemz7psFvJq+dI/MNJzK34 voNYZ9BUWz2ou0PXgDWLcyg+Qu1DRpBAWJZ0996FZiCOJp176lZcFNek+Ct9KVCcB2MG A8vXpgLX9k8GJliWXZK3RgJjgwd+9IAdjrHRqXAe4mNjJyWjH/HCPasEAdCOQ+Z6SlPK enR6tZxYhGWC3DTugimFF6U3XER6XsmCkFIjkVkYxcj8Fyv75m+mRoFd01pIpKOkT+hK cYYW8L+Dt8fiJWUH5Fby34q2k/UA8D95cvJzJvxyji1jrBrf0sFXhAa1HbTUg5Oa/pHe zwkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791794060; x=1792398860; 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=vKrzVRURgsqxMnlxn6tsEXwvnxfCko5owfMEa5IQtSM=; b=C99LyeVIIaYj+fnylSYjljA+18krX6cPEYuyWrgvIf5V3tp8PZTUvowUNOHTuh6f/H IJdKlxM6wXjc3Z9xDnPewsrd28Bc66A0PTIDNHlmXFTw7YiV8SgR3irQsk44GrP6/uaK YdH9UkXt8lE0mqrmqf9hBdzclf65lkwR7+yLnqghKBX3NvuImKX8mNHxK5OMU4NlWNkQ DxWvk5yqLLtl/lgwJIHNefYt9JwMPvHbE5jAe6qHiHwWAKqcPJRWw3N+iQD5Ee7HRHMu KPw/2ISkV68M7P/r0b42Nd3kds/hEqJhPUI1NsEZna2qclvkPsIxuJQxx4yq1nTFIwKI UR6A== X-Gm-Message-State: AFq9FYLv6CqVS2VEcO0VHvNAWABZk0MJNFo5RgOT6FPTlyyOli7dQTr4 fVug8TMe2TYcygwmWjPleAfmSxRBKcSevZRwemY7GWgXY+8wYkAcfwTZSGAyvak1vq0GptclBRB q1XKeBg== X-Gm-Gg: AYBFou1BUOE2W0evuiw8wsInD5sDmBVJO3UrNqYoS3FwNppp9czNdGb8eqDqs14POxL kj/OknFjGfbV6YQEJ2GKAl2vovryYQbuxnR9FYAVAKX0voUvEwHNt3k0ky/8yVJ3W2GS+R7THBA F5fuptZG6BeT0FV86tJTbhhBai4tXpkOtUT8wDcBiejkHvfiiY4cKICbGIYDzb9zQtiQc3Zuphu mngZxv8XXssRp2f/VmAYsgE5MxwkeP7zPLXkP4Lsj0wHgqMkPfK+e9DO7cFqTQIFQpVeYENkrXV RWhtbi8TeiATHrMewEQiDMYtMi87vEyhpsz2/V0FqyWr3T3BG0nSGERYIDjtUHciWQ6Yl+xyqmb FvD2SUGhpUocDgdbKuie0FvnmF33TfYIv7HNJpKYRgQ6sS6AOha3PDdW7cfkX1hSIGzZHDHJc5S c5ZbLOGC+JPGL56nErvnorVuiZ3SB4X2owFUhmkOsWX2MJqhAtj5+FFOCMJZNpl1iQOnymQowFx 0uxoTo06DOh0CK/lc1sbhl3xywXc82d6zirCE784buViKJ+eo+IjYOOOFWQ21AG3AqJCN57 X-Received: by 2002:a05:600c:e557:20b0:49f:dd9f:6038 with SMTP id 5b1f17b1804b1-4a18e4bff94mr103407215e9.25.1791794060036; Mon, 12 Oct 2026 01:34:20 -0700 (PDT) Message-ID: <56cdf5c7-2a2f-4d46-91ed-ba0a361ea649@suse.com> Date: Mon, 12 Oct 2026 10:32:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cannot boot PVH dom0 with big initrd To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: Content-Language: en-US Cc: xen-devel 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/1791794060-BEA66757-44AAA372/10/78276251493 X-purgate-type: spam X-purgate-size: 1446 On 13.02.2026 05:02, Marek Marczykowski-Górecki wrote: > After fixing the xhci crash, I hit another issue - booting with 236MB > initrd doesn't work, I get: > > (XEN) [ 3.151856] *** Building a PVH Dom0 *** > ... > (XEN) [ 3.593940] Unable to allocate memory with order 0! > (XEN) [ 3.597110] Failed to setup Dom0 physical memory map > (XEN) [ 3.599884] > (XEN) [ 3.602482] **************************************** > (XEN) [ 3.605272] Panic on CPU 0: > (XEN) [ 3.607928] Could not construct d0 > (XEN) [ 3.610692] **************************************** > (XEN) [ 3.613463] > (XEN) [ 3.616035] Reboot in five seconds... > (XEN) [ 8.626565] Resetting with ACPI MEMORY or I/O RESET_REG. > > Full console log: https://gist.github.com/marmarek/c9dbc87bf07b76f2899781755762f565 > > If I skip initrd, then it boots just fine (but dom0 is not happy about > that). 164MB initrd failed too, but 13MB started ok. > Just in case, I tried skipping XHCI console, but it didn't change > anything. You may want to give [1] a try, minimally up to patch 11 (patches 01 and 02 are unrelated, so could be omitted as well). > Interestingly, this appear to have worked on Xen 4.19.3. If so, then - judging from the changes which needed making - only out of luck. Jan [1] https://lists.xen.org/archives/html/xen-devel/2026-10/msg00491.html From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:43:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:43:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446002.1661912 (Exim 4.92) (envelope-from ) id 1xGBci-0002VB-J7; Mon, 12 Oct 2026 08:43:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446002.1661912; Mon, 12 Oct 2026 08:43: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 1xGBci-0002V3-FJ; Mon, 12 Oct 2026 08:43:08 +0000 Received: by outflank-mailman (input) for mailman id 1446002; Mon, 12 Oct 2026 08:43:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGBch-0002Ux-Ey for xen-devel@lists.xen.org; Mon, 12 Oct 2026 08:43:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBcg-008j8D-70 for xen-devel@lists.xen.org; Mon, 12 Oct 2026 10:43:06 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9d97-bab6-0a2a0a5309dd-0a2a450ba330-0 for ; Mon, 12 Oct 2026 10:43:03 +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 6acc9d97-b7e8-0a2a450b0019-d1558029f194-3 for ; Mon, 12 Oct 2026 10:43:03 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a140e7405dso19174015e9.3 for ; Mon, 12 Oct 2026 01: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 5b1f17b1804b1-4a18bea0f1csm395457535e9.9.2026.10.12.01.43.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 01: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: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=1791794583; x=1792399383; darn=lists.xen.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=C5MU5s8GjKUuc/tujX6IkCZkv91mwkdLwUwTaQKBEdU=; b=M0987V5K2ZnmuuTJKJRWVfCqBwqBMIOTme2Fn/MVAXM+aagQYbTBM9V7CVX+2vm1mQ KvIQ4PVbEsw+3TX091KlPhRGWMD7RrGRtgU7Sj+L6fIMo9CoIOgyyEriNULooXzKra4r tNxQeTWw1YMFYWyGp364kEsDGK/d4NycTOCN5c9plXI9iViooLiIBKv8fCrj7zWb+vK7 oney2VH3Z/xjezt36PE0duq4ArRtdTfeo7qBW/MUZuUIZ36rvb2vVb1R037yz+I2Y/WK 7zgeuz4Tk47cdpEc0nH8bqbsBhxQpVbBngLWt5pff7dP8GSpAdtP/7K10CI5hWP5YveH f16A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791794583; x=1792399383; 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=C5MU5s8GjKUuc/tujX6IkCZkv91mwkdLwUwTaQKBEdU=; b=CHi/ma0TfChLMnby7uSbTKm9WU1JDNuqPVriCZedV957dfaBXj4eivIXQdt4mX0Vsb aA2wG4VS5JHdVeeeJGzSI7D807NL9uJJdwUfr1bXY5aukw/Vo0SKchmaMTjOa3cvtYFz 8mjUS0GzP6EdxXf30k/Dwf1OTY9v7TzyL0SI2GUR50pnQAGUbcHuAuX2p8arOPxSC2Uq 3ZfZ3HokERuvCOSiujg6GGDxpkpR4KgYm0bLPuTrPKNbSUPHogaaZnTE8lizEUOUO2i1 t70h38ujUIt6AzUdgz+WZwJ/lFyAwProoQyvDp1Mu1XKsMYZzkswX7ux199s4C8ZXK9B M3sA== X-Gm-Message-State: AFq9FYK+ceD3wWQkWWrShKKJ8FUwFbV+ZdDDgBO4k0P174G6HopOe5Cm nS8T8vy+DA/38FX/wrZQVDHHsf+zZUFChh7kv5HzcVpckJEe/PXio7UuyDYgKfo4EA== X-Gm-Gg: AYBFou0ndO4MRt5ENyY7fmN3Ve5a2aHDMNc2art/v/r724oYwp6zIj1uZyXmaFmWsdn jhjffMaBXhoKoZlolt06tP+RCvNCWOox2mjZPB4KAMkWX1y3cWsGfqoxr88tyarGEd5RfZ6EjiX OmrpiyA+wdHD+ygJo/83IEKvjI8WpYLTZ4tljm5jXVfBK/rPr9HIP0sq4rBuSbyb8H05Ou2ymW6 cNURpLnWDpQuQQwGs7K9IVBMu4LF605RWyqKV59DKaia0kt8Xk62ck7Tc0e2P8Ye+f4XM/zpRL0 peA1mev+/+EOEDW8mxZGNYbA+07gdDC6dYLeb6UHZ2S62Ats6KiCIBAb2fHpCMRn+Jqhi1FpbOo Ug28l/4gYg0HAG3LF8hd0+Zdu/0Q16qpz11nw0DDe4ab30yidvVsOJ33avKioWw/pf82XiWiURe wYPB85CWVZxEowJeATR9W9wwOZF+7JofiMd0aykQTOsaPBY+hDXZPps22gYaIZVHyoIUJtLQq7m lX6gjWCxz0TLIZn/hd3TMU0cyb3/t7nK74NlgWLoHtEb6dG4lCIlv9YGf/S3BA= X-Received: by 2002:a05:600c:c092:b0:4a1:9831:a69c with SMTP id 5b1f17b1804b1-4a19831a9f7mr60949015e9.30.1791794582789; Mon, 12 Oct 2026 01:43:02 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 10:43:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen Dom0 fails to boot with "nvme.poll_queues=24" and "dom0_max_vcpus=6 dom0_vcpus_pin" To: Egon Ojamaa References: Content-Language: en-US Cc: "xen-devel@lists.xen.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791794583-1ACDF9EA-64A2D17E/10/78276251493 X-purgate-type: spam X-purgate-size: 2267 On 09.10.2026 05:41, Egon Ojamaa wrote: > Hello, Real human writing, not AI here ;) Good to know such can still happen. > #### Problem: > > Booting Xen hypervisor with Linux Dom0. > GRUB loads, Xen kernel messages load up to "Using 6 CPU" > > # From this point: > Next screen goes black and stays blank for 10+minutes. > Have to force reboot and choose non XEN kernel booting option via GRUB. > > # From this point expected behaviour without bug: > Next screen goes black and stays so for 30-70sec and Dom0 kernel messages appear, > Next login is possible and system is running, "xl info" and other xl commands function. > > #### Cause: > I spent 2 days rebooting to narrow this down.. > > This happens if we set both settings same time: > NVME io polling and XEN kernel CPU limits, via default grub configs: > > GRUB_CMDLINE_LINUX_DEFAULT="nvme.poll_queues=24" > > # Can also be set via /mnt/oldroot/etc/modprobe.d/nvme.conf > # For proper polling setup nvme.io_poll=1 should also be set, > # but symptom already appears if we set only nvme.poll_queues=24 > > and > > GRUB_CMDLINE_XEN_DEFAULT="dom0_max_vcpus=6 dom0_vcpus_pin" Did you isolate which of the two options it actually is that causes the problem, or whether it needs to be both together? Also, is 6 a necessary (exact) precondition to the issue occurring? > Sadly not my personal system, so I can not do further heavy testing on it. > io polling does give very good performance boost to Gen5 NVME, and even Gen4. > Sad we cant use it, as CPU pinning is more important for XEN hypervizor system. > > This has been also reported to launchpad.net: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270 As was meanwhile also indicated in that report: What's completely missing here, but very likely necessary for further analysis, are logs. That may also help establishing whether it's the kernel (driver) that's hung, or whether the system as a whole (i.e. Xen) is stuck. If nothing else in the log has any indication either way, issuing a debug key (for starters just 'h', later maybe others) may help telling one from the other. If issuing debug keys isn't possible anymore, try adding "watchdog" to the Xen command line. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 08:49:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 08:49:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446009.1661920 (Exim 4.92) (envelope-from ) id 1xGBiZ-0003OU-94; Mon, 12 Oct 2026 08:49:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446009.1661920; Mon, 12 Oct 2026 08:49: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 1xGBiZ-0003ON-5p; Mon, 12 Oct 2026 08:49:11 +0000 Received: by outflank-mailman (input) for mailman id 1446009; Mon, 12 Oct 2026 08:49:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGBiX-0003OE-NH for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 08:49:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGBiW-00EfJt-Gn for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:49:08 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acc9f00-8faa-0a2a0a5109dd-0a2a450995a8-16 for ; Mon, 12 Oct 2026 10:49:07 +0200 Received: from [52.101.85.66] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acc9f02-be1a-0a2a45090019-346555420c39-3 for ; Mon, 12 Oct 2026 10:49:07 +0200 Received: from BLAPR03CA0039.namprd03.prod.outlook.com (2603:10b6:208:32d::14) by LV5PR12MB9780.namprd12.prod.outlook.com (2603:10b6:408:304::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.21; Mon, 12 Oct 2026 08:49:02 +0000 Received: from IA0PEPF0000003B.namprd03.prod.outlook.com (2603:10b6:208:32d:cafe::1c) by BLAPR03CA0039.outlook.office365.com (2603:10b6:208:32d::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.19 via Frontend Transport; Mon, 12 Oct 2026 08:49:02 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by IA0PEPF0000003B.mail.protection.outlook.com (10.167.249.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 12 Oct 2026 08:49:02 +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.53; Mon, 12 Oct 2026 03:48:56 -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.53; Mon, 12 Oct 2026 03:48:56 -0500 Received: from [10.27.77.50] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 12 Oct 2026 03:48:53 -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=CWUZcZVp0sMQtzGGn+2cmzYOyhmv4pVWKH52gmWgpzwq3Dcn2q73kgzYsaWByE7KI1Rkr2YcNHp9T51MeyWTYh0x8Er+3yKfVZ9c1b/8DaKi1CmhA9/SMORuE1PVf5kKbsYgBtwaoKdv65r8E3Kmsww2CzFe+mm7+HwYUhC0+ktbVySG22vvvLZIBihA9o2rHVbp4V+XbI/kV6f8LAzIf9qTLjRm5lAwJfmn7qnN0aq0jj0loxXq71BxoR7DEi6oJrFRKTDIgyb/PKTImLFN/GnZakzeitPl53ZLolMVolXe8MdaXWRlUNv4PUOWMPaQKQzUc+wCHbeXwivfnODZmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oCR1mn7eIpteDAuy0Pd6JjVVXFIuKedDakhSMcIovI8=; b=KsXYyiNcB4OABuYLiHvpegVluhJBka6L8at3rYdfD9nLLNpvUtO3vhwh4XwHoI7Sge1gmK7L4B8OhQUR4u1fhyHmi2UwirRROcYCxPUMiAdG2SLdbh3Tl8d7gGBEEDdemMEkZqVoM2kpOSGjlH29q/U7KpS5ztEIOciql/j1igYUTdwO195YDw/jEgCl26Yf9XRyEqfWDDZwp9+pvGcHhssnWQf2FIgF3wRkuoDgY2VRGz/RYeuySdK41uuKwe5qCNfP4ygZWh7Djw24fdh3ZpEVMfcM/cVIkpEyu4So7gRaBNY+Xu3+N8288edzQIdgf3YKWCEjtSyTPu/mmGbmRg== 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=oCR1mn7eIpteDAuy0Pd6JjVVXFIuKedDakhSMcIovI8=; b=yLzQVDTSW9GP3+xQNozWWRTLdmkS9I0X71s3P7wiGz2VfkRb0jo5A2134B2rscbPUF3AALzGZvVjQ/VdXuRpAFrthyfz/Zafj7Zf61HTb4aJqGhwOApEQFzaxrT9O1XklceF6Cav5DGccDH/91D1ghRqypuJmmsRDpmKI1iVrd4= 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: <482b2414-affc-4f43-bdbb-8a7a012d542d@amd.com> Date: Mon, 12 Oct 2026 10:48:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Sanity test specified domain's memory for being a multiple of a page size To: Alejandro Vallejo , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261007124813.177940-1-michal.orzel@amd.com> <45cb2679-c79e-4d67-abaf-a4fe8e5ddc51@amd.com> <9600e1ea-d85c-4c59-abf9-bb90b1e8cd72@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: IA0PEPF0000003B:EE_|LV5PR12MB9780:EE_ X-MS-Office365-Filtering-Correlation-Id: 7d615455-b1a6-4a7e-bfd0-08df283daa20 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|23010399003|376014|82310400026|10067099003|261009223027099003|11063799006|4143699003|18002099003|22082099003|56012099006; X-Microsoft-Antispam-Message-Info: VIzeSloXBnTcEYa8ulfV6NCH8gFz/NW+Igx58j1/Aw2H20+sIjk4Pt+fbxJBw/Po7GPbi2T9YhAUTZinzfIN45xOs4kYPFuYaHi2rWAfUXrBRjocx2Z5RcsPAyUCS4WxucfsfLVroVKT5IM35PTdybeiGuNBWwhim4HQ+VDG07E+B2TA5bfo4nasY7qEBReE58ItbMgslPrL69cxMzE9j31vdZNu6iInSkS8FqkyJUocK8XRbDt1mQ2yvicnJJS77gbw2B2DlHZqVFBbWF11ucqk2n96hopCqFgKYqDcgmvdgW++/l/5vKA5ouDv5wt1KlQ07N0z0aAAGqKqsJE6A/ZdMPSScswM6YpI6XO7arWJrP9gcYuF51Q/FcO/dUqcrRSM9ljRrpYeP0sFXRbA8gnQVT6RaZC3H9VbB6CkZ9rfELchcAiJ4BO6LfKo5SKlVl393SWJVqKmsF2oe5cbUcGWCmY97Z6fJqLwRZfD8MuaM4cVe0X7OiNq56hT2YjFtrWKwE5tO2b6vnzE3pJ0lAc+4D1AV43mVHPMqSPAFMOGqcPZiW5TS8JGRuabt/sp21dfE9+vl0/WThz8Q10x4uRw07fFl+AKKGHApnuDhxFaV0vVDAc0r8TIJbTvt9vNQk37Lo49LKjRpadAXJ8//oVOONvWCF5PoMpjj4FhsNnP0VeLjbK1Ytph+TYxNrkoM+RWA6ZTXxnSD7jsywMfIw== 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)(1800799024)(23010399003)(376014)(82310400026)(10067099003)(261009223027099003)(11063799006)(4143699003)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: vsFy8deMAoK0AsFubMBDifhKHd2JsIRM/qJQI+A53GgiTx0CMuXHVpm/VTm55pOPDjFXgWshwRcwTctmFOGayflKoRgY8He1feroQ2t+oM4Y/oUAMy6I9awmYTABuFHolTXxAcwrFD1vUswXsvb/5EfjQROBeFgrvyMJ1zu98YhJbd3mngosYnIu61QZvAuNipY6dlYDZvSdCHyMCfq1W/56uKbfW8yLZZzDU8HEbR99NVUgkOwvbwshzC2cl5cAwa8fCI4dKHOHxW/1wJ2WLgFt2LtnecMgE3ktTQu5/wtOLOZIDFMdtGmz3kKUE1hgIRy+Io1glIFIE3EfRSHpkQn2r/kDzJ2HqeadfjJ4+wGAIB7Dr15xLnmH8IDuBkkMT0BGavYGIWbkZO2Zr5nHLEZXQu9Cm3dvgcYwKNtwLmFi9ZxMQoECQvNMuGncTKP9 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2026 08:49:02.1843 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7d615455-b1a6-4a7e-bfd0-08df283daa20 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: IA0PEPF0000003B.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR12MB9780 X-purgate-ID: tlsNG-bad1c0/1791794947-BC6CA034-A96C8BE6/0/0 X-purgate-type: clean X-purgate-size: 3848 On 09-Oct-26 10:27, Alejandro Vallejo wrote: > On Wed Oct 7, 2026 at 4:31 PM CEST, Orzel, Michal wrote: >> >> >> On 07-Oct-26 16:21, Alejandro Vallejo wrote: >>> On Wed Oct 7, 2026 at 4:11 PM CEST, Orzel, Michal wrote: >>>> >>>> >>>> On 07-Oct-26 15:40, Alejandro Vallejo wrote: >>>>> On Wed Oct 7, 2026 at 2:48 PM CEST, Michal Orzel wrote: >>>>>> We require memory to allocate for a domain as RAM to be a multiple of a >>>>>> page size. However, we neither document this nor sanity test. Specifying >>>>>> memory size that does not conform to this requirement fails the domain >>>>>> memory allocation in the non-obvious way that is difficult to parse for >>>>>> the user (printing over-allocation messages followed by the panic that Xen >>>>>> could not allocate the requested amount of memory). >>>>>> >>>>>> While there, fix indentation from tabs to spaces for "memory" parameter in >>>>>> booting.txt. >>>>>> >>>>>> Signed-off-by: Michal Orzel >>>>>> --- >>>>>> docs/misc/arm/device-tree/booting.txt | 4 ++-- >>>>>> docs/misc/xen-command-line.pandoc | 5 +++-- >>>>>> xen/arch/arm/domain_build.c | 6 ++++++ >>>>>> xen/common/device-tree/dom0less-build.c | 7 +++++++ >>>>>> 4 files changed, 18 insertions(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt >>>>>> index bcb06bc796bf..7dfac2062a37 100644 >>>>>> --- a/docs/misc/arm/device-tree/booting.txt >>>>>> +++ b/docs/misc/arm/device-tree/booting.txt >>>>>> @@ -155,8 +155,8 @@ with the following properties: >>>>>> >>>>>> - memory >>>>>> >>>>>> - A 64-bit integer specifying the amount of kilobytes of RAM to >>>>>> - allocate to the guest. >>>>>> + A 64-bit integer specifying the amount of kilobytes of RAM to >>>>>> + allocate to the guest. Must be a multiple of 4KB (the page size). >>>>> >>>>> nit: s/KB/KiB >>>> Is it? I don't think it matters at all seeing the number of occurrences in the code. >>>> >>>>> >>>>> But page size isn't always 4KiB on all ports. PowerPC has 64KiB pages. >>>>> IMO, 4KB shouldn't be here or elsewhere in documentation. >>>> This is Arm doc and on Arm we only support 4KB at the moment. User should not >>>> need to dig into the code to check what is the page size. It's better imo to >>>> give this information right away and change in the future when we add support >>>> for 16 and 64KB pages on Arm. >>> >>> This is already the only reference the other ports have for dom0less. >>> The document shouldn't be here since the movement of dom0less to common >>> code, but the side effect of it is that this no longer an arm-only reference. >>> >>> I won't be annoying about moving the doc on this patch because that's a >>> separate matter, but not adding more easily avoidable debt seems >>> warranted. >> I don't quite understand your reasoning. If you worry about dom0less != Arm, >> then on that basis HAS_DOM0LESS is selected only for Arm and RISCV where >> PAGE_SIZE is 4KB. I don't think I'm introducing any doubt here. I can remove the >> 4KB mentioning from the docs if you really insist but at least for me it's >> clearer for the user to know right away what's the requirement for the size. > > It's a small adjustment to make the documentation truly generic. And > prevents the pgsz == 4KiB assumption from spreading further. Many docs > are spawned from copying other docs. > > If you're so strongly against, that's fine; it's not incorrect today. > I still think the 4K should be gone, but if don't want to block the > patch on such silly things. Fine, I'll remove 4KB mentioning from the docs. > > Reviewed-by: Alejandro Vallejo Thanks. I'll handle the changes on commit. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Oct 12 09:20:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 09:20:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446031.1661960 (Exim 4.92) (envelope-from ) id 1xGCCq-0001Yt-S7; Mon, 12 Oct 2026 09:20:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446031.1661960; Mon, 12 Oct 2026 09:20: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 1xGCCq-0001Ym-PX; Mon, 12 Oct 2026 09:20:28 +0000 Received: by outflank-mailman (input) for mailman id 1446031; Mon, 12 Oct 2026 09:20:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGCCp-0001Yg-Kb for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:20:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGCCm-00E1bq-Sf for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:20:24 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acca656-8faa-0a2a0a5109dd-0a2a450ae754-16 for ; Mon, 12 Oct 2026 11:20:24 +0200 Received: from [209.85.208.41] (helo=mail-ed1-f41.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acca658-f2d2-0a2a450a0019-d155d029c8ad-3 for ; Mon, 12 Oct 2026 11:20:24 +0200 Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-6aa9164072cso2345368a12.2 for ; Mon, 12 Oct 2026 02:20:24 -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-6b179e001ebsm4818360a12.33.2026.10.12.02.20.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 02:20: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=1791796824; x=1792401624; 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=RRZHuiyjVsALp4+EaJw5EmjOztVvZ52iaBmxwTpxoAs=; b=pyIKhah7E2q8RcfV8W0IM3MYrxS0qA+5VJV4YXbnrYtZsPyEO7bpx0ZB6H3jKB3X6I NBxGlGz+d1ui401BYvGJTKfhE2UqseW7IgNPacuIjxqUnMTo1W2S7+3lkIU7iLdnn+ac 8ofMgBEyWiJuSZiUATYpim/tTqIXxaAA8JDq42EyRuTf7OJ6YAelKq3c00G+DLZ+D6wD T/2YG45iUbyjqdOKeyicVkAVv+9I5IjhTC/7G1x1U5sN37Lq2HRY2V0MeKCStZ7MqqIa HxYx0yOmVPtytWNI7j7bA+iw3JucTW5/RWKevN2ftiuSY09L3qjXfC+Ko1Y7KnYGZbg6 FVqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791796824; x=1792401624; 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=RRZHuiyjVsALp4+EaJw5EmjOztVvZ52iaBmxwTpxoAs=; b=X0JVnLp4nFknGSEV8hUki091MMnp0lGHRTpKED9fwDowEGOkD5mt3YQOfVVtGbHhI3 f4rbqqsNA51Mk5LHUz09EQj3AvrqxdIubQbPa5aFTHmhEAgXR66rf/NUK+C4oAnvWEXj JLleZ0iotmDJeIT25gc2cF1+ip9Tre7hb3Yofu3ZrFcRDlvgTqIWkL2cVKUVdqnViJ5s vD6ksWPxNndH6l7/GdnxVvXjCskmQ1lZMYlpd2YZSWG4yJHQ/KE9qI0vkYauVHsARzTh ZF55xfQcMF1YhpAgnqsLaIKOqcF2CExB40nPchpqrpNq1Lw7lOFPkifyRpO2CTiNItQg 9KmQ== X-Forwarded-Encrypted: i=1; AKwUvBxNoQBgHUTcNKva93faUjIDVH0MefcgZOS4hvwgvYywAnOdpRSWhXz9F42qMSxt35QeuqFUGRV0rHc=@lists.xenproject.org X-Gm-Message-State: AFq9FYITC9HAVFtAzqmODWrMpDHjh68P2GkA0Vt2gF3nEAwm4Ufk9v/U zF8L0P/zDwptoPBwQahw19wGvObP5K4taZfsxombWucgfMPTzaT6xOpw X-Gm-Gg: AYBFou0oLEUDeHqPqr/PIkIIhHALCsNHzMgC59P9S/HDO2yw3U8Ps1BaAdUo9uEw2gD OptPEA6l6TPKjG+QQs0ZUTXqiIhOmDa4d2KtWqIS+clckuD5PxdaNoPPYpo2nVbdqv/1yJL8MrJ D1UW/r5VUDWxDrup0LwSjHhQqY0Y2sFxZXqvheUJu87GYzUijph5U9xI0oSZDlE64CnqP+2vlbS Sm3/Nq5dj10tPaF0rpb8Genzi7yDO7tq02p5cC4xrK62BGa8vd3G8BPdV+YYKsoiI5+oAnsWXyo /3I4g3kuacbdbt1Cjcn9F5Sxmn4pG9fvOJ0amU1de0mlqA5Xn4tqUGdKsMMyddaZ/2kxFM53PqY j97c+mkUpwmiMMk+yUV2H03MIRQAjuJvy1YfOGDntPMm+dWCSFPR8vvEGPLvu2GguhTFJBYBYWM rtW16Q5cWo1Ly89FTgy6nFtTI8pdUDZT5AGZM4TRz7FhVCrwX7YG5iratafEXiVa7UVp/cI1Uhx VVxnDHezRKVijKNTPwJ7zZHKhrD+uwfjfjpQ+Jsy3624V9KHw== X-Received: by 2002:a05:6402:321d:b0:6aa:f198:4e39 with SMTP id 4fb4d7f45d1cf-6b17c294025mr8126477a12.44.1791796824153; Mon, 12 Oct 2026 02:20:24 -0700 (PDT) Message-ID: <1a6cdfbf-8116-48ca-b2cb-567e39fabe4f@gmail.com> Date: Mon, 12 Oct 2026 11:20:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE To: Zhang Zheng , xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791796824-51AC4CFC-D16074E7/10/73395122804 X-purgate-type: spam X-purgate-size: 4097 On 10/10/26 5:14 AM, Zhang Zheng wrote: > XScale-compatible UARTs require UART_IER_UUE to remain set. Probe the > bit during setup and preserve it when enabling receive interrupts, so > the xscale/PXA UART remains operational after ns16550 takes over. > > Signed-off-by: Zhang Zheng > --- > xen/drivers/char/ns16550.c | 12 +++++++++++- > xen/include/xen/8250-uart.h | 1 + > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index cdda28879e..c174465059 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -64,6 +64,7 @@ static struct ns16550 { > bool intr_works; > bool force_polling; > bool dw_usr_bsy; > + bool xscale; > #ifdef NS16550_PCI > /* PCI card parameters. */ > bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > /* No interrupts. */ > ns_write_reg(uart, UART_IER, 0); > > + uart->xscale = false; > + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > + { > + ns_write_reg(uart, UART_IER, UART_IER_UUE); > + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > + uart->xscale = true; > + } > + This probe only checks whether IER bit 6 is writable, which isn't specific to XScale. On UARTs with an EFR (e.g. ST16C650, TI TL16C752, Exar XR17V35x) the upper IER bits become writable once EFR[4] (ECB) is set, and bit 6 is then the RTS interrupt enable. If ECB is already set when the probe runs, it would report XScale, and the driver would then keep the RTS interrupt enabled. Could the flag be derived from the compatible in ns16550_uart_dt_init() instead, the same way dw_usr_bsy is? uart->xscale = dt_device_is_compatible(dev, "intel,xscale-uart"); That compatible would also need adding to ns16550_dt_match[]. The SpacemiT K1 nodes, for example, have no "ns16550a" fallback. > /* Handle the DesignWare 8250 'busy-detect' quirk. */ > handle_dw_usr_busy_quirk(uart); > > @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) > UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); > > /* Enable receive interrupts. */ > - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); > + ns_write_reg(uart, UART_IER, > + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); It seems like not all cases are covered. For example, ns16550_interrupt() writes 0 to IER when it switches to polling, which would turn off the UART on XScale. Am I missing something? If not then something like: static void ns_write_ier(const struct ns16550 *uart, uint8_t ier) { if ( uart->xscale ) ier |= UART_IER_UUE; ns_write_reg(uart, UART_IER, ier); } would be needed, used in ns16550_setup_preirq(), ns16550_setup_postirq() and ns16550_interrupt(). ns16550_start_tx()/ns16550_stop_tx() do a read-modify-write of IER, so they read UUE back from the register and write it out again unchanged. They therefore work correctly without the wrapper. They could be switched to ns_write_ier() as well for consistency, but that isn't strictly necessary and likely could be left in way it looks like now. ~ Oleksii > } > > if ( uart->irq >= 0 ) > diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h > index d13352940c..358d264698 100644 > --- a/xen/include/xen/8250-uart.h > +++ b/xen/include/xen/8250-uart.h > @@ -42,6 +42,7 @@ > #define UART_IER_ETHREI 0x02 /* tx reg. empty */ > #define UART_IER_ELSI 0x04 /* rx line status */ > #define UART_IER_EMSI 0x08 /* MODEM status */ > +#define UART_IER_UUE 0x40 /* UART unit enable (XScale/PXA) */ > > /* Interrupt Identification Register */ > #define UART_IIR_NOINT 0x01 /* no interrupt pending */ From xen-devel-bounces@lists.xenproject.org Mon Oct 12 09:27:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 09:27:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446038.1661971 (Exim 4.92) (envelope-from ) id 1xGCJY-0002FW-IX; Mon, 12 Oct 2026 09:27:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446038.1661971; Mon, 12 Oct 2026 09: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 1xGCJY-0002FP-EY; Mon, 12 Oct 2026 09:27:24 +0000 Received: by outflank-mailman (input) for mailman id 1446038; Mon, 12 Oct 2026 09:27:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGCJX-0002FJ-7F for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 09:27:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGCJW-008rzM-Jm for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:27:22 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acca7f4-8faa-0a2a0a5109dd-0a2a450c89c6-30 for ; Mon, 12 Oct 2026 11:27:22 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acca7fa-f479-0a2a450c0019-d1558035a899-3 for ; Mon, 12 Oct 2026 11:27:22 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4980fe6b3beso19322955e9.0 for ; Mon, 12 Oct 2026 02:27:22 -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-4a18bf1358asm280466585e9.4.2026.10.12.02.27.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 02:27: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:From: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=1791797242; x=1792402042; 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+R+Ozgj8ePuSD4uGVGZV2JHC5UGWebd97SVsY/IAlM=; b=ft2EWqTjqNh2hTr5PM+vrcfk96c8ioZaSeOOwdtp7EMU9fJOj+EO6wukL1jcjtJtpJ LXb/DLoTSOOJ9jHf8Oj75o56wZRznwREGAiEru/8q+rjk2D1j0hc1UIiRYcHrBkisB3s CZCBqWd1JDnw/9FnH7KuIm/wMQ1TCEzMvJme2WOU/EpGb9lDJ9NGMHkZuk/PXgK8sVXO iHWuw04fAdQbiNeDmrCYl31sG75/gK4TxlHxLqUfU6tLkyBGx/8eGca1VRmW2jEd52GL 26imIIgmY9jYOe9vNhiw+mlBk/tYVpuHJ2MZlvT2zeRg9T8gARQ67u+PAYszG6Cgp2UY OJCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791797242; x=1792402042; 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+R+Ozgj8ePuSD4uGVGZV2JHC5UGWebd97SVsY/IAlM=; b=Dfzknew8OxTzxaCw8Xl3vO/WTf0iwv3qlWaQHRZ9oZdxwlN39gUIlomOYg/v109EPJ sonYXZOUeyRD/ujyB0DcxnU1rftBFZ62TS5pWsl6+z/+P8GlkReWnEgS0X4yZjCm7EhD fQw+yaMtDW6X1Rx8ohxySND5qitkTgMSCaLYwh63XhK/1b2yjw+aSW37C3pDyD7+ImZ8 z2TdrKTYW+Zut0SZGJ1BukVyr714TwGgUmnu4iQ95ID/rRUdUrGXgYVMSjAXWJwuMpD9 BTK8l3dqhDA5Gc8Vpu/YgL+Y80WKcNzU2Dy0plqO2rk2Y12J7lKQGk/GvwLhDMX8bslD N9wg== X-Gm-Message-State: AFq9FYJCb2LScLsw8JCEUto1b042GeNepVJZbGrYMafuHaDxm8Q7tAim 1NBqHxBdflwr9811nlIl36ANh5eSVD5GP/xJCYHqkZBVynsERbdgMuxI X-Gm-Gg: AYBFou3xliskcOG/A9Jb7xy35VYBLuB5u9aGaPqmEFIb57RVy56g6WbdJ1Mn/0Hqfx3 YD41fZI6XQKh3E8GqweSCaGDqFrhXB5VivZ8kqY8R9gmklNX6/wP5t6lhatpLQqvR3g40fbDp1K GHZW7xhpRUblMhguZ4UUImkNx6aLj4IZVaezAOpF9+kyIJi2Oy2+gfpOCHKgmVJFTp39NqvgaIg KMX1aTSjHIkX3dWx92udmAZyuE2ctkGCKcfnR5s02/r3pJnuJLMaUZSJpoue+QQfQzyUTq5q756 ZDvEhwmX+A2nK2cGma2GOMhTP/GY9RZwcIYeSFlH7fkx/DIIalE4Uj9KohHyoj0BVjEbWH+elG5 cyaXdoF7ua+aVXLQDwwL94105ncKmIjXSl+4UUmCrh4kK/mr3DN6NqTtN9VVRbA9AytzSRpcckz 5Uu0E92pabxzz8eyO2U6HOrExFVWiA4M+BZjUB/TQ0QwK27Y6MuID48YZHHqExMR0LYLshK0km1 VYiVNhqANRyjgu0JkiaU1d0GprFJRYtvcYT5sowmTRRLHZZwQ== X-Received: by 2002:a05:600c:a011:b0:49e:6581:7baf with SMTP id 5b1f17b1804b1-4a18e447d8bmr161117315e9.2.1791797241821; Mon, 12 Oct 2026 02:27:21 -0700 (PDT) Message-ID: <8b6d4953-07a8-4ba1-90d9-351032c95814@gmail.com> Date: Mon, 12 Oct 2026 11:27:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE To: Baptiste Le Duc , Zhang Zheng Cc: xen-devel@lists.xenproject.org, 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: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <1791670290.8631fc262581453bbf619ec5b2062170.1a127df076400080d7@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791670290.8631fc262581453bbf619ec5b2062170.1a127df076400080d7@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1791797242-76EDAA5B-C6E2FF19/10/73395122804 X-purgate-type: spam X-purgate-size: 3052 On 10/11/26 12:11 AM, Baptiste Le Duc wrote: >> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c >> index 593d208483..953d166314 100644 >> --- a/xen/drivers/char/ns16550.c >> +++ b/xen/drivers/char/ns16550.c >> @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) >> /* No interrupts. */ >> ns_write_reg(uart, UART_IER, 0); > Do we know of a UART where UUE reads back as 1 whatever is written? I > could not find any such hardware, so I am not sure the check is needed > but it might be wrong. If not, then we could drop this write but if so, > then I propose to move it in a dedicated function: > > ``` > static bool ns_is_xscale(const struct ns16550 *uart) > { > /* > * We're going to explicitly set the UUE bit to 0 before > * trying to write and read a 1 just to make sure it's not > * already a 1 and maybe locked there before we even start. > */ > ns_write_reg(uart, UART_IER, 0); > > if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) { > /* Now we are in a 0 state */ > ns_write_reg(uart, UART_IER, UART_IER_UUE); > if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > return true; > } > return false; > } > ``` >> + uart->xscale = false; >> + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > > >> + { >> + ns_write_reg(uart, UART_IER, UART_IER_UUE); >> + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) >> + uart->xscale = true; >> + } >> + >> /* Handle the DesignWare 8250 'busy-detect' quirk. */ >> handle_dw_usr_busy_quirk(uart); >> >> @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) >> UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); >> >> /* Enable receive interrupts. */ >> - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); >> + ns_write_reg(uart, UART_IER, >> + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); >> > Every IER write has to keep UUE on an XScale UART, otherwise the UART is > switched off. Open-coding the ternary at each call site makes it easy > for a future caller to forget. Would it be better to add a helper, e.g.: > > static void ns_write_ier(const struct ns16550 *uart, unsigned int val) > { > ns_write_reg(uart, UART_IER, > uart->xscale ? val | UART_IER_UUE : val); > } We could avoid ternary operator here: static void ns_write_ier(const struct ns16550 *uart, unsigned int val) { ns_write_reg(uart, UART_IER, val | (UART_IER_UUE & -(unsigned int)uart->xscale)); } but it is less readable... ~ Oleksii > > and use it for all futures IER writes? > > Thanks for contributing! > From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:13:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:13:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446055.1662011 (Exim 4.92) (envelope-from ) id 1xGD1f-0001MS-0l; Mon, 12 Oct 2026 10:12:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446055.1662011; Mon, 12 Oct 2026 10:12: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 1xGD1e-0001ML-UI; Mon, 12 Oct 2026 10:12:58 +0000 Received: by outflank-mailman (input) for mailman id 1446055; Mon, 12 Oct 2026 10:12:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGD1d-0001MF-L7 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:12:57 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGD1d-00000001hAA-25iW for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:12:57 +0000 Received: from mail-lj1-f182.google.com ([209.85.208.182]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGD1c-000000086UU-3J1j for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:12:57 +0000 Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-3a98fc80925so12137751fa.0 for ; Mon, 12 Oct 2026 03:12: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" 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=w0KJ3I7EbRo6QxuQIXiqkb7Ghk6+lH8PEiyu3fRgGr4=; b=xOz4B7DCgiTFXVFa/qadMEsmW2 UXPt+RQ+pOKoG8C5ogYBwBluLf2HraROKFknacQF4sWcJHc5Rypdrf/KxuVBQksG9atGddTVlQV4w ChI+3Pa40PMMxYuRzdLMNlbsl7OgKqtwF+pzkmGmcC01hiV/VPT7Ong+44y1WGBzlJc0=; X-Gm-Message-State: AFq9FYJYOJ4XX8hBehvgacw39h7Kf9iBB1OjBp6LTKDiGnWF3zZGtLga M9ylu6MzS64aJqbo7zLE4AA0AHh+TEbTFl9EbIkZ3RFNkQ+X/xgh1kplXsGFZdYzBC0WvVPIEKt aatQQoi7tq3HRwUhM+AeXJp9AybDP0RQ= X-Received: by 2002:a05:651c:a20f:10b0:3a9:8408:8c5f with SMTP id 38308e7fff4ca-3a9c54b827emr13297491fa.10.1791799976013; Mon, 12 Oct 2026 03:12:56 -0700 (PDT) MIME-Version: 1.0 References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> In-Reply-To: From: George Dunlap Date: Mon, 12 Oct 2026 11:12:44 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8buKSKVzS7zce6lcxZ4SvaTlMZTEKwR0yLQYoJP2uD1bOezoDqexnlkKU Message-ID: Subject: Re: [PATCH 01/15] x86/EFI: guard against oversized modules To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski , Daniel Smith Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Re-sending from @xenproject.org, since my other email bounced] On Mon, Oct 12, 2026 at 9:19=E2=80=AFAM Jan Beulich wro= te: > > x86/EFI: guard against oversized modules Nit: This repeats the subject line. `git am` of this has two identical lin= es. > module_t's mod_end field (which we repurpose to hold a module's size) > cannot hold values 4Gb and up. Don't let truncation go silently. > > Signed-off-by: Jan Beulich With the repeated subject line fixed: Reviewed-by: George Dunlap From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:15:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:15:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446060.1662019 (Exim 4.92) (envelope-from ) id 1xGD3n-0001sc-Az; Mon, 12 Oct 2026 10:15:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446060.1662019; Mon, 12 Oct 2026 10:15: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 1xGD3n-0001sV-88; Mon, 12 Oct 2026 10:15:11 +0000 Received: by outflank-mailman (input) for mailman id 1446060; Mon, 12 Oct 2026 10:15:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGD3k-0001sP-RN for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:15:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGD3j-003ziU-Ko for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:15:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accb312-e002-0a2a0a5209dd-0a2a450a8f0e-42 for ; Mon, 12 Oct 2026 12:15:07 +0200 Received: from [40.107.162.80] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accb32a-f2d2-0a2a450a0019-286ba250b6fe-3 for ; Mon, 12 Oct 2026 12:15:07 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by VI6PPFBC76E4C1C.eurprd03.prod.outlook.com (2603:10a6:808:1::38c) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.16; Mon, 12 Oct 2026 10:15:05 +0000 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292%6]) with mapi id 15.21.0496.019; Mon, 12 Oct 2026 10:15: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=DASIu5pBHbQ+nhKw4HjPq1KtenWnWr4ZYE8lryuPQXgegxMtB7pGfqDtkDjTR7bg7M3UqSt4WExhY4ZO5vJvHlBgfBEZDfhamaI8uKZucmwjlsdHJRUwFFT2Wj5yGCjiMkPtC3jRZM9ie/ocF/dVsyMB0iBbOt0V1BExMR3lKbvaqfFn52ksurjZsqHwluuGBvw46Ed+0QLtJnZPqRS0gN3bLYW7As9W9T4zEOvl1HIYe3Bq4ICkRIE4RpmlAzsHo/NIhobwFBOBPiWEuEkqUCfBXctK4Y0irlXqgvP8/9ptfEz2Kr6D7ODgU1S4zLPYXiMGnyxXdd41XHX/BF5fYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XdSVHxmzLHDAE4+2UJMx+JXYC1Wuqrav4CgAXIvbqtY=; b=Y0iZRtAeFHZSpp1D9vDSJ6QU9VOv+goVZMgmcsWRl5fu7WAZziTiRoIGTn+5ju0FHKgo1+rc1nXsZHR8Bc/+OHxTmRphk/rZf/v4NBEEl4WcOaQ7rozCkjcCNvwxVXMk2ofsUk+bVk1rbCK/4t+ZSXXfJJYUJXOj67cRXkrbjrIuqIoJpPWZPAKhdZ0QgIgt+t+ACNIkEU3jVMbvbXPir4c6eE/fLRuNh3+srGVnMI8jTMf3OYgAjsvT/OK4wOHCOnnmCP/hJRJ1Fw1tVQPaOlONOU9vmKdDw1OmIfqATALS9Ew3xCLfU15Qu/hzPKJ7R+gi6ae5v/9lk/4YtzkV6g== 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=XdSVHxmzLHDAE4+2UJMx+JXYC1Wuqrav4CgAXIvbqtY=; b=fi+sIlEYDYmrbUxTP6E/S7+HLQkrWu1vLQvj+35wezXXh8gv66IoGIJGUKXAW9OHT3IR/AJP2hSu2TT+OmIo3YhrfI1Ku3c4fH9luqYkh8ZX8lCt8e7lmD4UQAIfDT6Z5P+VF6BakSg5pyuJ6fYx2ZVwBioq/plXKKYuhvqnVaNBkf23f7TlER8X8Iy/qoezW86Zb9ij3/ue8SBYQnHdHhz3TF5QyQ50xn53OVRHntN/Nc0lAms/jAc2hKQwiXxMmjLaTrV1o2g5ZORQpbOaWtp0aZKbp+RzQnnBrLOkNaDniX0vbhF95fnYIcylGiIOUcHnyFfEv7J0eec1HhTSoA== From: Sergiy Kibrik To: "xen-devel@lists.xenproject.org" CC: Sergiy Kibrik , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" , Andrew Cooper , Michal Orzel , Jan Beulich , Alejandro Vallejo Subject: [PATCH v4] common: dom0less-bindings: introduce XSM labels Thread-Topic: [PATCH v4] common: dom0less-bindings: introduce XSM labels Thread-Index: AQHdWjKML/KTfuhVBE60GMkd6tz7+A== Date: Mon, 12 Oct 2026 10:15:04 +0000 Message-ID: <20261012101453.949907-1-Sergiy_Kibrik@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: AS8PR03MB9192:EE_|VI6PPFBC76E4C1C:EE_ x-ms-office365-filtering-correlation-id: df1829bd-def3-4238-712c-08df2849af75 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|18002099003|11063799006|10067099003|56012099006|38070700021|6133799003|261009223027099003; x-microsoft-antispam-message-info: TF5ze+4vjmVJ/SuDBHBdjcpDQjcsZbPylR5B7irq0gGWvGs7elKtZyf4vlA0OQwIltD1C620G8+RRHMbnihTRaIl1v3xMam5kHYVDWcYjzvdPszEEf6Z7LnII5LKsmU4TYnKwRMiizi8Zo4GOoibB7RPBnugaHgXTkCogkcdQTq8tHA+mhnIyfDqePRxF+ufe6I2fPXeBI9Gjj2YIdCenxKav82CpihkbqnUUiQXkJYOHQbycSkJKqFwPXiNgMx31/0EvIBVjw1LWnwZZAoLGTlumJpFM0MFpqRbkD2RGRYuwk3H+H81BXd5hETFiqdrp1LkEYKr1jayZ2ZGDNW8ZzcwPxWOAvf9/bkkmJ92Nb5/gbAthP+mybwULVeb6hC9/B7rp/C/cQUejg05woYUSH4dFfCr6MKbfKkldPincjEERr7OgOOhC+6YzsZ7h81n2gkLmvEeKTNByivqDZASStCdqLGQWq6UDuGo+FZyqGvARrLlKHTMdeusG+8boHIpnO7VQwtAm1xnByvxQrgTg+v5zZ+SGFTDosm2I3uL3MItHcMcbOGp5WP6xhbEL+9TtMUXePHU2/6uZTkYLF1dAwbeWpBVbJ4XPqDrroK/Sor6tBpBatTNxpmTV0JGbIorpDk0g1k79qrshyOaD8drZrRaVjvDafkk7ppz+p2N6rzJgP/NLOkCtAy7V5TlFrdXMSsXgaGJu+sF9AcWQQcJXOAqMKfjw7L6DUe5TI0H380= 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)(366016)(376014)(23010399003)(1800799024)(18002099003)(11063799006)(10067099003)(56012099006)(38070700021)(6133799003)(261009223027099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?d01aU3BhMU16WUI3QVhaQllwc0FWUnQ0aEM5WlhkK1d5K2ZaL1Bjb09sZlV3?= =?utf-8?B?di83NVFic2xYNnYyQzdXaFBNVTFvOVllbklMNHdMQ1QxWjhxTkdaVldwaUtF?= =?utf-8?B?aGhaK09QMDdMZm1YeVBoZ1R5V0tTMzRFakRQRUI0UjVyWTQvUTFybU4rdXh3?= =?utf-8?B?WFQyT2pTSWNxUHJkUThuSHVIVm15R3dVbDVIdncwRmMxU203S2xVNW8yMzlE?= =?utf-8?B?M1I4Mzh1NHNCa3lXd3VQTGtpWGUzMGVYTjBGS2l5b1loWlZibmF5RXptSEZU?= =?utf-8?B?Q0J0Z25GU3VMbld4Y1QxbUhRYW1tclRhcDBlYnBCUzVSSERiQWxiZUx6Zjh5?= =?utf-8?B?dlEydEhtR09wZmExMjNoN3FXUWxrR0F0M00xeit5eFUxdkFITkRKcG9GT28r?= =?utf-8?B?YWVQR2ZrY0lyU1gvTkMzL3MzMXpmdURXaEIrZ1lVbXY0N0swWnlzYXhsbVpE?= =?utf-8?B?emZDUFJ6TG9lY3E3dytrU0dRU1M1TlZ4d0k5bVZxemZwSmltdGJpL0VqYzkr?= =?utf-8?B?Y25GTG4wNmk3Yml1a05pQ3UyMEhOQVJRTmhZcjU5VlZxdW5ialV2a05aS2Jn?= =?utf-8?B?K0NUTEJoY0tHVEhsdUM4UXpacGkrYlFlY2wwRk15bnUwdDdER2JDY0sxNms1?= =?utf-8?B?ZE5NVitNelQ4WWp3cTFqRXFxQ2RqVG5QWGpHdWNhR2ZSR1FFd1BkVUY2NnF6?= =?utf-8?B?Y1p1S3FaZ1RRdThjQUZ6bndyZFZpUUxKUjJEdmNlVGU2U254WWJXR1p5cjA5?= =?utf-8?B?b09xeHd5U0NCUWY5dytIL1plSlp2WlBTUFA5eUl5VzBkaWJBL0U2bWJSL1Ey?= =?utf-8?B?U25CN3ZVRHlmL1g1YWIvMjgvTkNqbXpRWnlLOU9SL1Zza0czM1VMTktFeDhI?= =?utf-8?B?SFh6RG5qZUVRTUdtNDYwdVNQQ2RTZU5ZckZsTlIza0JDTnZHMnVRWUFreFhp?= =?utf-8?B?VG1GNkVxTC9mYUZkVk8wZTU4SWxqSTVjOXk5Sk9hWDBrcXN4WFRaOWZPNUlT?= =?utf-8?B?aG9BbGRBSDJhbytzNkJrU0RIczZGSG04ZXJlSWJFWUtKeG56Um9EVTlScWlG?= =?utf-8?B?TjBuTEpnRFhEcnB4cWNiNEhDelJxTjlHQ2R6S1FhVXduSC9iNi9aMDYwbkcy?= =?utf-8?B?QW5KQjdBVW0xSWJ6SnFVdXJBbzBJNjQ2em95OXNudFplVlplYW9vdVZvczFB?= =?utf-8?B?UXIzSUwvR25HRytneDlGdFVhVWdSWXpDdFFQZDB5Y0t4VktsUzF2cG1PWEpo?= =?utf-8?B?aC9OaWVnb2Q0enp5d05BTkMzeURnd0FMa3RpcXpwbjY0OXZQUjJja05qTVZ0?= =?utf-8?B?dGRIRE96SWZYOGZBTkNxa1JuL21DNVVwcEYydXVPbkdBZTZ2RXVlSU1IcTdh?= =?utf-8?B?WXlmYS8yMVQzUldqUVVXOFcrcUx4ZEg5QTFIM3FXZWYwL1phZjZhc2dZR1lz?= =?utf-8?B?YWRJOUNWL2t1TnBPNXptZlZXYTJoU2owa3JRM0dtWFV0cnhFWTRzczBNWHJ3?= =?utf-8?B?dG5XdUxJQVZXdURHbVRjb25MbWhEVnBGclRXb0pSMG5wY1JVZGdGaVk4czdk?= =?utf-8?B?SVlGT1pYd2RLWGd6RWxYa0NQTEFMV0ppYzBjL0lkVGxNcERyY1k5eWtkQWZC?= =?utf-8?B?NFZ0OSt3VVk5Rkx3Sk44bEIyNjVyU0lhTitIVjhDZU1FNFdzZzRKcjhzTHpO?= =?utf-8?B?aDkzZUdCd0UxKzlTQk15dXJtR1RBREt3NzhKcStmVjFLclpiMGZMM2xzdldY?= =?utf-8?B?N1hrZWJITXVYZTg2MytEYm5CNVdFUTVCOXhaNFp1ZFp6eUpudjl4Sm4vbHlS?= =?utf-8?B?UFU4QjVna0tTa1F6dituVFRmWnQyVmpSRG52R0RVdUdPTUlGY1N4TGliQzRi?= =?utf-8?B?aEkyenVpaUF1R1JsWDRBZFNuOHZGL25Cd0E4SkJoT1dIQlpyakRiN0tiMUx3?= =?utf-8?B?cE01aStCWEplTU9oYnpCRytWSEE0VVdzaDdOQzNISUpBRkxCRjZYZE5DUE1y?= =?utf-8?B?anRKZndRbjdpRmtyRlJXaWV0Y3FDc3hFeDNCL0tKQm93bE1jdDErWUtYYmU0?= =?utf-8?B?amRtZFdDTXdqdStQTVZWYWc4d0VYZFZVcURISmtuRitlS1ZIcDdwTS81Smow?= =?utf-8?B?QXV2bUVVMEZiUmhJRHBsR0dNM2hPWlJiQitFMkhPNDFBUCsyeGt0dzYwTVpq?= =?utf-8?B?cFhBVmpsS0J0bXVvQWVja2MzdWxLa2NWSS9Pc3pOdzRuUU9kZVBhMzY0aXVz?= =?utf-8?B?MUUyMEplTS9SamprYlBlUmptdjFEZExxTWx5UWRKelVENUZ3SkhGNm80Y2ZK?= =?utf-8?B?bDFmVGZYcVF0L0VVM1djZUV6bGtJcHNDL3dqczE3bjQwMlNZWUpHZz09?= Content-Type: text/plain; charset="utf-8" Content-ID: <57DC008872D7FA4A91EA4C4DB9B4B4A0@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: df1829bd-def3-4238-712c-08df2849af75 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2026 10:15:05.0756 (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: EQrbKrXGSy34hvzqjXvPSziLt0QFnh0I41Rgm63l9infQ3M+Kr+qcq0WSLBXcy2jfkUeEYfSODcJRpgy3XwUow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI6PPFBC76E4C1C X-purgate-ID: tlsNG-4011c0/1791800107-585CBCFC-40E506E7/10/78276251493 X-purgate-type: spam X-purgate-size: 7768 QWRkICJzZWNsYWJlbCIgcHJvcGVydHkgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHNlY3VyaXR5IGxh YmVsIGZvciBhIGRvbWFpbg0Kd2hlbiBYU00gRmxhc2sgaXMgZW5hYmxlZCwgc2ltaWxhciB0byB4 bCBjb25maWd1cmF0aW9uIGZpbGVzLg0KDQpDdXJyZW50bHkgZ3Vlc3QgZG9tYWluIGNhbid0IGJl IGNyZWF0ZWQgYnkgWGVuIGluIGRvbTBsZXNzIGNvbmZpZ3VyYXRpb24gd2hlbg0KRmxhc2sgaXMg ZW5hYmxlZCwgYXMgZG9tYWluIGlzIGFzc2lnbmVkICJzeXN0ZW1fdTpzeXN0ZW1fcjp1bmxhYmVs ZWRfdCIgbGFiZWwNCmJ5IGRlZmF1bHQsIHdoaWNoIEZsYXNrIGRlbmllcyB0byBjcmVhdGUgYWNj b3JkaW5nIHRvIGN1cnJlbnQgcG9saWN5Lg0KDQpCZWNhdXNlIGNvZGUgZnJvbSBvdXRzaWRlIG9m IGZsYXNrIGNhbid0IGRpcmVjdGx5IGV4ZWN1dGUgaXRzIGludGVybmFsIEFQSQ0KYSBuZXcgWFNN IGhvb2sgbG9va3VwX3NpZCgpIGludHJvZHVjZWQgYXMgcGFydCBvZiBYU00gQVBJIGV4cG9zZWQN CnRvIHJlc3Qgb2YgWGVuLg0KDQpTaWduZWQtb2ZmLWJ5OiBTZXJnaXkgS2licmlrIDxTZXJnaXlf S2licmlrQGVwYW0uY29tPg0KQ0M6IERhbmllbCBQLiBTbWl0aCA8ZHBzbWl0aEBhcGVydHVzc29s dXRpb25zLmNvbT4NCkNDOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t Pg0KQ0M6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQpDQzogSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KQ0M6IEFsZWphbmRybyBWYWxsZWpvIDxhbGVqYW5kcm8u Z2FyY2lhdmFsbGVqb0BhbWQuY29tPg0KLS0tDQpjaGFuZ2VzIGluIHY0Og0KIC0gaW50cm9kdWNl IFhTTSBob29rIGBsb29rdXBfc2lkYA0KIC0gYXQgU0lEIGxvb2t1cCByZXR1cm4gZXJyb3IgaWYg c2VjdXJpdHkgc2VydmVyIG5vdCBpbml0aWFsaXplZA0KIC0gZG9jdW1lbnQgcGFuaWMgaWYgRFRT IHByb3BlcnR5IGlzIHVzZWQgYW5kIEZMQVNLIGRpc2FibGVkDQogLSBwZXIgTWljaGFsJ3MgcmVx dWVzdCBwYW5pYyBpZiBGTEFTSyBkaXNhYmxlZCBpcyBsZWZ0IHVuY2hhbmdlZA0KY2hhbmdlcyBp biB2MzoNCiAtIHBhbmljIGlmIGBzZWNsYWJlbGAgcHJvcGVydHkgZm91bmQgYnV0IEZMQVNLIGlz IGRpc2FibGVkDQpjaGFuZ2VzIGluIHYyOg0KIC0gYWRkICYgdXNlIGZsYXNrX2NvbnRleHRfdG9f c2lkKCkgd3JhcHBlcg0KLS0tDQogZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4 dCAgICAgIHwgOCArKysrKysrKw0KIHhlbi9jb21tb24vZGV2aWNlLXRyZWUvZG9tMGxlc3MtYmlu ZGluZ3MuYyB8IDcgKysrKysrKw0KIHhlbi9pbmNsdWRlL3hzbS9kdW1teS5oICAgICAgICAgICAg ICAgICAgICB8IDcgKysrKysrKw0KIHhlbi9pbmNsdWRlL3hzbS9ob29rcy5oICAgICAgICAgICAg ICAgICAgICB8IDIgKysNCiB4ZW4veHNtL2ZsYXNrL2hvb2tzLmMgICAgICAgICAgICAgICAgICAg ICAgfCA3ICsrKysrKysNCiA1IGZpbGVzIGNoYW5nZWQsIDMxIGluc2VydGlvbnMoKykNCg0KZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQgYi9kb2NzL21p c2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0DQppbmRleCBiY2IwNmJjNzk2Li4yYTY5ZDI1 MzdkIDEwMDY0NA0KLS0tIGEvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0K KysrIGIvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KQEAgLTM0NSw2ICsz NDUsMTIgQEAgd2l0aCB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6DQogICAgIG5vdCBwYXNzZWQu IFRoaXMgY29uZmlndXJhdGlvbiByZXF1aXJlcyBzdGF0aWMgYWxsb2NhdGlvbiAoeGVuLHN0YXRp Yy1tZW0pDQogICAgIGFuZCBkaXJlY3QgbWFwcGluZyAoZGlyZWN0LW1hcCkuDQogDQorLSBzZWNs YWJlbA0KKw0KKyAgICBBIHN0cmluZyBwcm9wZXJ0eSBzcGVjaWZ5aW5nIGFuIFhTTSBzZWN1cml0 eSBsYWJlbCB0byB0aGlzIGRvbWFpbi4gRG9tYWlucw0KKyAgICB3aWxsIGJlIGNsYXNzaWZpZWQg 4oCcdW5sYWJlbGVk4oCdIGlmIHRoaXMgcHJvcGVydHkgbm90IHNwZWNpZmllZC4NCisgICAgTm90 ZTogYm9vdCB3aWxsIGZhaWwgaWYgdGhpcyBwcm9wZXJ0eSBpcyBwcmVzZW50IGJ1dCBGTEFTSyBp cyBkaXNhYmxlZC4NCisNCiBVbmRlciB0aGUgInhlbixkb21haW4iIGNvbXBhdGlibGUgbm9kZSwg b25lIG9yIG1vcmUgc3ViLW5vZGVzIGFyZSBwcmVzZW50DQogZm9yIHRoZSBEb21VIGtlcm5lbCBh bmQgcmFtZGlzay4NCiANCkBAIC00MjIsNiArNDI4LDcgQEAgY2hvc2VuIHsNCiAgICAgICAgIG1l bW9yeSA9IDwwIDEzMTA3Mj47DQogICAgICAgICBjcHVzID0gPDI+Ow0KICAgICAgICAgdnBsMDEx Ow0KKyAgICAgICAgc2VjbGFiZWwgPSAic3lzdGVtX3U6c3lzdGVtX3I6ZG9tVV90IjsNCiANCiAg ICAgICAgIHZjcHUwIHsNCiAgICAgICAgICAgICBjb21wYXRpYmxlID0gInhlbix2Y3B1IjsNCkBA IC00NTMsNiArNDYwLDcgQEAgY2hvc2VuIHsNCiAgICAgICAgICNzaXplLWNlbGxzID0gPDB4MT47 DQogICAgICAgICBtZW1vcnkgPSA8MCA2NTUzNj47DQogICAgICAgICBjcHVzID0gPDE+Ow0KKyAg ICAgICAgc2VjbGFiZWwgPSAic3lzdGVtX3U6c3lzdGVtX3I6ZG9tVV90IjsNCiANCiAgICAgICAg IG1vZHVsZUAweDRjMDAwMDAwIHsNCiAgICAgICAgICAgICBjb21wYXRpYmxlID0gIm11bHRpYm9v dCxrZXJuZWwiLCAibXVsdGlib290LG1vZHVsZSI7DQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9k ZXZpY2UtdHJlZS9kb20wbGVzcy1iaW5kaW5ncy5jIGIveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9k b20wbGVzcy1iaW5kaW5ncy5jDQppbmRleCA0MWQ3MmQwZDU4Li5iMDNjZWUwZThjIDEwMDY0NA0K LS0tIGEveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1iaW5kaW5ncy5jDQorKysgYi94 ZW4vY29tbW9uL2RldmljZS10cmVlL2RvbTBsZXNzLWJpbmRpbmdzLmMNCkBAIC0xMSw2ICsxMSw4 IEBADQogI2luY2x1ZGUgPHB1YmxpYy9ib290ZmR0Lmg+DQogI2luY2x1ZGUgPHB1YmxpYy9kb21j dGwuaD4NCiANCisjaW5jbHVkZSA8eHNtL3hzbS5oPg0KKw0KIGludCBfX2luaXQgcGFyc2VfZG9t MGxlc3Nfbm9kZShzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHN0cnVjdCBib290X2RvbWFpbiAqYmQpDQogew0KQEAgLTIxLDYgKzIz LDcgQEAgaW50IF9faW5pdCBwYXJzZV9kb20wbGVzc19ub2RlKHN0cnVjdCBkdF9kZXZpY2Vfbm9k ZSAqbm9kZSwNCiAgICAgYm9vbCBoYXNfZHRiID0gZmFsc2U7DQogICAgIGJvb2wgaW9tbXUgPSBm YWxzZTsNCiAgICAgY29uc3QgY2hhciAqZG9tMGxlc3NfaW9tbXUgPSBOVUxMOw0KKyAgICBjb25z dCBjaGFyICp4c21sYWJlbCA9IE5VTEw7DQogDQogICAgIGlmICggIWR0X2RldmljZV9pc19jb21w YXRpYmxlKG5vZGUsICJ4ZW4sZG9tYWluIikgKQ0KICAgICAgICAgcmV0dXJuIC1FTk9FTlQ7DQpA QCAtMTQxLDUgKzE0NCw5IEBAIGludCBfX2luaXQgcGFyc2VfZG9tMGxlc3Nfbm9kZShzdHJ1Y3Qg ZHRfZGV2aWNlX25vZGUgKm5vZGUsDQogICAgICAgICBwYW5pYygiJ2xsYy1jb2xvcnMnIGZvdW5k LCBidXQgTExDIGNvbG9yaW5nIGlzIGRpc2FibGVkXG4iKTsNCiAjZW5kaWYNCiANCisgICAgaWYg KCAhZHRfcHJvcGVydHlfcmVhZF9zdHJpbmcobm9kZSwgInNlY2xhYmVsIiwgJnhzbWxhYmVsKSAm Jg0KKyAgICAgICAgIHhzbV9sb29rdXBfc2lkKFhTTV9IT09LLCB4c21sYWJlbCwgc3RybGVuKHhz bWxhYmVsKSwgJmRfY2ZnLT5zc2lkcmVmKSApDQorICAgICAgICBwYW5pYygiSW52YWxpZCBzZWN1 cml0eSBjb250ZXh0IGZvciBkb21haW46ICVzXG4iLCB4c21sYWJlbCk7DQorDQogICAgIHJldHVy biBhcmNoX3BhcnNlX2RvbTBsZXNzX25vZGUobm9kZSwgYmQpOw0KIH0NCmRpZmYgLS1naXQgYS94 ZW4vaW5jbHVkZS94c20vZHVtbXkuaCBiL3hlbi9pbmNsdWRlL3hzbS9kdW1teS5oDQppbmRleCA2 MzMxODU5YWZhLi4wMjljZGRkNWNkIDEwMDY0NA0KLS0tIGEveGVuL2luY2x1ZGUveHNtL2R1bW15 LmgNCisrKyBiL3hlbi9pbmNsdWRlL3hzbS9kdW1teS5oDQpAQCAtODIzLDQgKzgyMywxMSBAQCBz dGF0aWMgWFNNX0lOTElORSBpbnQgeHNtX2RvbWFpbl9yZXNvdXJjZV9tYXAoDQogICAgIHJldHVy biB4c21fZGVmYXVsdF9hY3Rpb24oYWN0aW9uLCBjdXJyZW50LT5kb21haW4sIGQpOw0KIH0NCiAN CitzdGF0aWMgWFNNX0lOTElORSBpbnQgeHNtX2xvb2t1cF9zaWQoDQorICAgIFhTTV9ERUZBVUxU X0FSRyBjb25zdCBjaGFyICpjdHgsIHVpbnQzMl90IGxlbiwgdWludDMyX3QgKnNpZCkNCit7DQor ICAgIC8qIGR1bW15IHBvbGljeSBoYXMgbm8gc2VjdXJpdHkgY29udGV4dHMgKi8NCisgICAgcmV0 dXJuIC1FUEVSTTsNCit9DQorDQogI2VuZGlmIC8qIF9fWEVOX1hTTV9EVU1NWV9IX18gKi8NCmRp ZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94c20vaG9va3MuaCBiL3hlbi9pbmNsdWRlL3hzbS9ob29r cy5oDQppbmRleCBhMzMxZjVmMGU1Li4zYzFiZWYzMDUzIDEwMDY0NA0KLS0tIGEveGVuL2luY2x1 ZGUveHNtL2hvb2tzLmgNCisrKyBiL3hlbi9pbmNsdWRlL3hzbS9ob29rcy5oDQpAQCAtMTY5LDYg KzE2OSw4IEBAIFhTTV9IT09LKGludCwgYXJnb19yZWdpc3Rlcl9hbnlfc291cmNlLCBjb25zdCBz dHJ1Y3QgZG9tYWluICopDQogWFNNX0hPT0soaW50LCBhcmdvX3NlbmQsIGNvbnN0IHN0cnVjdCBk b21haW4gKiwgY29uc3Qgc3RydWN0IGRvbWFpbiAqKQ0KICNlbmRpZg0KIA0KK1hTTV9IT09LKGlu dCwgbG9va3VwX3NpZCwgY29uc3QgY2hhciAqLCB1aW50MzJfdCwgdWludDMyX3QgKikNCisNCiAj dW5kZWYgWFNNX0hPT0swDQogI3VuZGVmIFhTTV9IT09LMQ0KICN1bmRlZiBYU01fSE9PSzINCmRp ZmYgLS1naXQgYS94ZW4veHNtL2ZsYXNrL2hvb2tzLmMgYi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMN CmluZGV4IGQ2NWJhMGFlYWUuLmIxMzBmZjVlMjYgMTAwNjQ0DQotLS0gYS94ZW4veHNtL2ZsYXNr L2hvb2tzLmMNCisrKyBiL3hlbi94c20vZmxhc2svaG9va3MuYw0KQEAgLTE5NDksNiArMTk0OSwx MyBAQCBzdGF0aWMgaW50IGNmX2NoZWNrIGZsYXNrX2dldF9kb21haW5fc3RhdGUoc3RydWN0IGRv bWFpbiAqZCkNCiAgICAgcmV0dXJuIGN1cnJlbnRfaGFzX3Blcm0oZCwgU0VDQ0xBU1NfRE9NQUlO MiwgRE9NQUlOMl9fR0VUX0RPTUFJTl9TVEFURSk7DQogfQ0KIA0KK3N0YXRpYyBpbnQgZmxhc2tf bG9va3VwX3NpZChjb25zdCBjaGFyICpjdHgsIHVpbnQzMl90IGN0eF9sZW4sIHVpbnQzMl90ICpz aWQpDQorew0KKyAgICBpZiAoICFzc19pbml0aWFsaXplZCApDQorICAgICAgICByZXR1cm4gLUVB R0FJTjsNCisgICAgcmV0dXJuIHNlY3VyaXR5X2NvbnRleHRfdG9fc2lkKGN0eCwgY3R4X2xlbiwg c2lkKTsNCit9DQorDQogc3RhdGljIGNvbnN0IHN0cnVjdCB4c21fb3BzIF9faW5pdGNvbnN0X2Nm X2Nsb2JiZXIgZmxhc2tfb3BzID0gew0KICAgICAuc2V0X3N5c3RlbV9hY3RpdmUgPSBmbGFza19z ZXRfc3lzdGVtX2FjdGl2ZSwNCiAgICAgLnNlY3VyaXR5X2RvbWFpbmluZm8gPSBmbGFza19zZWN1 cml0eV9kb21haW5pbmZvLA0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:16:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:16:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446065.1662030 (Exim 4.92) (envelope-from ) id 1xGD56-0002N3-LV; Mon, 12 Oct 2026 10:16:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446065.1662030; Mon, 12 Oct 2026 10:16: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 1xGD56-0002Mw-HF; Mon, 12 Oct 2026 10:16:32 +0000 Received: by outflank-mailman (input) for mailman id 1446065; Mon, 12 Oct 2026 10:16:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGD55-0002Mq-QM for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:16:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGD55-00000001hEx-49De for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:16:31 +0000 Received: from mail-lf1-f45.google.com ([209.85.167.45]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGD55-00000008BuY-1BYk for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:16:31 +0000 Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-5bccb867d6fso1102661e87.0 for ; Mon, 12 Oct 2026 03:16: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" 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=2zy3hX2JjExXiK0ClK0TkZ335pbMgwsETmx+Gyqc998=; b=M+3yCfjbXtFy4Xh5/d2uK0InM7 fbrCtoenTERfUxUtdwLHrqbHnCFKrD1AlN0cPcJbOBzMBcfKD9EuVZD1IUnRA852LHYgXlgP7XGTE L00rudC/vGjcmndlEYqpg5sXG6Jg/4fNv/ZGpxXh8JmkYL+1fxmHpv7PhUSFCJK1OQKc=; X-Gm-Message-State: AFq9FYJvmolin2RLpcPwbiPTDTyLlQaaD8EhW/HI8cUaLgj1q2ZlpbK5 ZVbxKn8ypvVtR1n5Xo3Le4rc7K5udewSQwOfGgNFYZCsXxOi2FIdnJdERPbCMe74TZkZDQeg9dk 8Q/6ylkdVlH8BlWHccikX1X2E6oqW3EM= X-Received: by 2002:a05:6512:3989:b0:5ba:37c8:a485 with SMTP id 2adb3069b0e04-5bcde6bdfd9mr2743422e87.22.1791800190667; Mon, 12 Oct 2026 03:16:30 -0700 (PDT) MIME-Version: 1.0 References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <0c6f1d50-9eb2-44c1-aea5-c366204316e3@suse.com> In-Reply-To: <0c6f1d50-9eb2-44c1-aea5-c366204316e3@suse.com> From: George Dunlap Date: Mon, 12 Oct 2026 11:16:18 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9wbiHsAx04MRBamcM2AykAW5BSspYgTBoMIOgI29WLWeKG0m0OW06s_n8 Message-ID: Subject: Re: [PATCH 02/15] x86/PV: make better use of assign_pages() To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2026 at 9:19=E2=80=AFAM Jan Beulich wro= te: > > As of the referenced commit there's no reason to open-code the loop > anymore. With that replaced by a single call, there's then also no point > in using the local "mfn" in this code. > > Amends: 5260e8fb93f0 ("xen: re-define assign_pages and introduce a new fu= nction assign_page") > Signed-off-by: Jan Beulich Reviewed-by: George Dunlap From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:20:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:20:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446074.1662041 (Exim 4.92) (envelope-from ) id 1xGD90-00040n-4G; Mon, 12 Oct 2026 10:20:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446074.1662041; Mon, 12 Oct 2026 10:20: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 1xGD90-00040g-1b; Mon, 12 Oct 2026 10:20:34 +0000 Received: by outflank-mailman (input) for mailman id 1446074; Mon, 12 Oct 2026 10:20:33 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGD8z-00040a-39 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:20:33 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGD8y-00000001hJr-3wc3 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:20:32 +0000 Received: from mail-lj1-f179.google.com ([209.85.208.179]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGD8y-00000008Ieh-0ztF for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:20:32 +0000 Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-3a9a1ed66b9so11071041fa.2 for ; Mon, 12 Oct 2026 03:20: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" 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=7Pt+Ofwt0tmS2+oPk/E9CzhtrxJcTTP5V/Chtb4aBs4=; b=FspKBzRwIWQDoiHjtcufz2J4UC FKNu41vrytC267slrhtjg5rZu1L3KAt8Ph5FH3ssil/iUf/DbItziODNKkGVis8hDxteLUCgD/alw uzg9+VZFBXmE5ZU2SradYf6pXFJdfujhsj9GBoUl13ey7vMcwLzo9wn65Le1sEP+TEWY=; X-Gm-Message-State: AFq9FYLj23A8AieS7qjUBA+yWC9WTvdZOQF+CCsWt0JOjirUT9BYriLO JPSfXMfZ0hkRedJzNNEDbz1LpYjAZCi3ps5Y0tP6WLKv2+BHdbcP+R7GDG4A2nAlN9xkpn+W5S0 8KZKPCPGAGCN6cy1MJD872v4RCUmYMrc= X-Received: by 2002:a05:651c:19a4:b0:3a6:660d:a83b with SMTP id 38308e7fff4ca-3a9c4eba022mr25764151fa.3.1791800431481; Mon, 12 Oct 2026 03:20:31 -0700 (PDT) MIME-Version: 1.0 References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> In-Reply-To: From: George Dunlap Date: Mon, 12 Oct 2026 11:20:18 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK99Fe3TnwNGYlKC18D1KG1fimxkAmbPnrRNXB632P3xbqYnf3irgskcWSI Message-ID: Subject: Re: [PATCH 03/15] x86/setup: break out E820_RAM accumulation To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2026 at 9:20=E2=80=AFAM Jan Beulich wro= te: > > We already have two instances of this, and we're about to gain a third. > > Signed-off-by: Jan Beulich Reviewed-by: George Dunlap From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:20:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:20:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446077.1662052 (Exim 4.92) (envelope-from ) id 1xGD9K-0004Nz-CF; Mon, 12 Oct 2026 10:20:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446077.1662052; Mon, 12 Oct 2026 10: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 1xGD9K-0004Nr-7s; Mon, 12 Oct 2026 10:20:54 +0000 Received: by outflank-mailman (input) for mailman id 1446077; Mon, 12 Oct 2026 10:20:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGD9J-0004Nd-3n for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:20:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGD9I-0092lo-Gr for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:20:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accb479-8faa-0a2a0a5109dd-0a2a4503d9bc-36 for ; Mon, 12 Oct 2026 12:20:52 +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 6accb484-fae8-0a2a45030019-d1558034b487-3 for ; Mon, 12 Oct 2026 12:20:52 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a021c809e3so16844025e9.0 for ; Mon, 12 Oct 2026 03:20:52 -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-4a19f318c31sm64121385e9.3.2026.10.12.03.20.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 03:20: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=1791800452; x=1792405252; 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=VgT+fUwydFonMB/KjDSQ4h6GnJYJvqSigOfJvwJcRM4=; b=niOvr29YrBpVVtJRRN74pMSXuWXtkNvMhRq+vBA/68vTKjwJNRYfC+9k7By8A2MCF3 xSLAa7Q3s5kdBIb5hcEAjgDD0932ZZODECLzHVOKvDRSI2Ogxe2OoWEv28eLcFSv6rNE QgCbUTP0MXa8eW9BcQ5BfsF89hbNZOz/aqGyg9lEB6OqEsKB8ZSYTgfX8YFaqKN+zyb8 FvIN3b0RQwOusbVYYf1b9MsFLTU9uyInuVvNk2+WFVPgW4Mk9YWjnG6N8pH6Rl6UXGDB WH+ekEUklN1SNsOanvQbAKvveqT8Z2eK8N0jA6Sy4q0Lwofbi8Eb2gLdN4iDEUX+gM9z pSyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791800452; x=1792405252; 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=VgT+fUwydFonMB/KjDSQ4h6GnJYJvqSigOfJvwJcRM4=; b=bhOVny4ZQWR98ILz5sx5aCaNKaX6pyU9jIQucF6Uav4eM8g1Ry9GF24rJHvEJ5Ejht 3nBfQ7PQWotwqiUE9OAdoFk4kdw9KpcAvTwH2xDhEidTyKYjvVlhGUB6AgeyVPi289y3 l8Tw7m30Lb6Mp6Sfs62aAKm1X5g3UT9FycgkcgUHii44Rt+1kc6qSs1vSpz9NqH2Ihoe qbkRZGRjg68KcuByTbNPYoBd/mdUXT4CN0Ps/hO5o/n3+0U93w/WTnZ+vnQT4ZDntc5J PGp7s5khFL74kO9UqmqjSVcehXjHd5VY7tWFe//l75jNWvkkEW4/vIGSwL5IwF1+Par7 nSdQ== X-Forwarded-Encrypted: i=1; AKwUvBzj9q51P5GfFAHoeonFfXl8m02ukKqZhCsw/AQ2NARvaRJyweT8wdU9U4EJDeTdVynuX8O8K8OiurU=@lists.xenproject.org X-Gm-Message-State: AFq9FYIxWor4QxJlgxm7ktBsHIptEsY8WuckIPy81qNtZ3+6sxEK+8oY 3arvUeisM826T8QE4/z0WSCYJdPPvkhSVFNwANQC3xOqhDIi7qLPt7qz X-Gm-Gg: AYBFou3HnZ0utCHh5WuwWuaujpsGOYHA3IipUMPN+PNBQ1+0dibQ9DwQPNujsYV2W0p z+NFgPp8FxLaP6MJ7CEMoBGsmiX1sJvjkj+GC44Gu4gVGeTjruJaZhxSeIpHZz+06TsQ3TYVcUN bq8Y/yrH5yrI6iw2+iJnVrRfdqcritpmSxIezIct83QCY3h9xYAp5uv+Xqe3psnGEo6XA/JMlLz UK01kVkB8YIxvibzvSsJ5YILSpBmpCKlNa994CuIlpBMDyb6qtvD2ZHTUjow6Z5Tf8OyHBmVUAr TEs/zk8tJNCUwDCibnBoLt7WnFtsos8yrLJ2JieG+LpopddmkhUxEhFbF3aESdEHxxB6CPMuANm u17wGtITE+rE2HqroHjZOIbukyT92TqdL1S9tp4lx2/05gHRW6usqlWctDpH7TJ/PzIsCN+lo/J 76GXNB2XTI9SL4nfcsVpWSJrFtS//KG5K1wxSDK4Kf9m1ftFctDObl9ygwVJ/S8v3JJUY5/HeG3 qq96R94nFlyD6A+I11ONVuaZlqW3HJcFToBuQbDgDbb+nO6vw== X-Received: by 2002:a05:600c:34d0:b0:4a0:35c:8953 with SMTP id 5b1f17b1804b1-4a18e47aceamr173350695e9.7.1791800451475; Mon, 12 Oct 2026 03:20:51 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 12:20:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing To: Zhang Zheng , xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1791800452-6C8DD4E9-970FA18E/10/73395122804 X-purgate-type: spam X-purgate-size: 2805 On 10/10/26 5:14 AM, Zhang Zheng wrote: > An SBI console call may return before the UART finishes transmitting. > Wait for UART_LSR_TEMT before ns16550 reprograms the UART and clears its > FIFO, preserving pending early-console output and legacy SBI v0.1 support. The problem isn't really specific to SBI: anything that wrote to the UART before ns16550 takes over (firmware, a bootloader, or Xen's own early console) can leave data in the TX FIFO or the shift register. I'd describe it in those terms. > > Suggested-by: Oleksii Kurochko > Link: https://lore.kernel.org/xen-devel/8836d1e3-77c8-4447-b1ef-132620a71441@gmail.com/ > Signed-off-by: Zhang Zheng > --- > xen/drivers/char/ns16550.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index c174465059..278d38822d 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -427,6 +427,10 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) > #endif > } > > + /* Preserve output queued by firmware before taking over the UART. */ я' Could the comment say why the wait is needed at this point? Something like: /* * Output written before ns16550 takes over (e.g. by firmware or the * early console) may still be in the transmitter. Let it drain before * ns16550_setup_preirq() reprograms the line settings and resets the * FIFOs. */ > + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) > + cpu_relax(); > + IMO waiting for TEMT rather than THRE is the right choice: besides resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and LCR, which would corrupt a character still being shifted out. (Linux waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT already implies THRE.) The unbounded wait can hang early Xen boot if the UART never reports TEMT for some reason(?). Bounding the wait would make console initialization more robust, allowing boot to continue when the UART is unavailable for ( i = 0; i < 50000; i++ ) { if ( ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT ) break; udelay(10); } would need udelay() on RISC-V, which is still a BUG_ON() stub, so a separate patch would be needed for that. On x86, udelay() doesn't delay yet at this point (cpu_khz is only set by early_time_init()), so there the loop would just be an iteration count. Perhaps someone has a better idea of how to implement a timeout here. ~ Oleksii > ns16550_setup_preirq(uart); > > /* Check this really is a 16550+. Otherwise we have no FIFOs. */ From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:23:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:23:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446086.1662067 (Exim 4.92) (envelope-from ) id 1xGDC0-00056u-TL; Mon, 12 Oct 2026 10:23:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446086.1662067; Mon, 12 Oct 2026 10:23: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 1xGDC0-00056n-QY; Mon, 12 Oct 2026 10:23:40 +0000 Received: by outflank-mailman (input) for mailman id 1446086; Mon, 12 Oct 2026 10:23:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGDBz-00056h-Ly for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:23:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGDBy-00Fmmk-En for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:23:38 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accb528-8faa-0a2a0a5109dd-0a2a4509b2f0-10 for ; Mon, 12 Oct 2026 12:23:38 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accb52a-be1a-0a2a45090019-d155802ed1d3-3 for ; Mon, 12 Oct 2026 12:23:38 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a19cba5c14so10157575e9.3 for ; Mon, 12 Oct 2026 03:23: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-4a18bf31b83sm287559035e9.12.2026.10.12.03.23.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 03:23: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=1791800618; x=1792405418; 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=8ansDgR7RJt96a3kt/TMeDi3Mw9LXC4Q0H5qpIUi/wc=; b=MaRbJ87CCAN9OaH4XBpkiM+hamjTcP1XXGi2BYbkpOuwsTGDKErUbmsHMfx4ti9RDY pyTpvVzcO9rDP8lOh0qSh+nXs3VimPa76r/rqUQkmJRrRHRuavZYbNnYi9XQnMfmcv/b F8uMQy/gNyZSem7iGJcZmlTVTKt7ziHG2ENQW+pPLdhZVxaeC6MoKBWW8V2EJ0UPzcyR KswX3K5/t7BAKRQJDM1coDPoiRs9Hq60vF6/pBV1dcEBll/+IFM/Nw49c+pMnJ9K+FgK 6LibC9bzYjmkbbc48Fj50WXhM35CY+O61MJBDTcro/sb8cgVMrl3W+CcHaqgloDM3PgX ZXKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791800618; x=1792405418; 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=8ansDgR7RJt96a3kt/TMeDi3Mw9LXC4Q0H5qpIUi/wc=; b=BNANVcD3oitCj+LdGF1zK/sXD4ubX4NlXqImDYJ2a+J0Wzl6Oci552UZ1GgCrS/NWE yQuWpft+DuLdQlEaSSvPxt77bCR0K1L+/zTMMuTT+k4mzPiqNp2waieysxnFywv+DX+0 DjDwOB79SmBeANoxIsEkGaDlfSN6l8yhSSroBTcbpv7m9aCHH8v0333BCxlTm5ecDMTq /z9LzNC2VslXBnd66ydGjj5YuMtsW11Ep1wT+llFxuRaCRKHrdwJgts0pKA7SgS6sYRf zhYSeXtzaJ4nMnviTGgeUnK5w5JAIP8wnmkk7U964RR5Ikiap1YOi5vrEwKM0lj7m/1G SuNg== X-Gm-Message-State: AFq9FYIGe4r1pkwu5lw9PgfzcmsopyrEUpeLC8E8Hcy1XwHmOt0tK/4D b0SG4zhX0vKmVo3eyyIcNfWly6sbposXZmIOhKi+xzpPpmJ2JmsAtCdcxduewi7Orw== X-Gm-Gg: AYBFou3neubCpJCvzAy/XlK4/YvV2p1GPVLR9SYXBNZODfgYCFCf84OntUasypJGv/J bJGoVTjcUmHpAywEIgN7ENz2lOJL4Re345/0GbCZ+X200dU/mRDtwXFT3H/nxnRxSkooj8T5TpC bn9CaG1M0iPdqheVF/zVBRVRphxJ7GD71e4rWhqBVZ2cyiN0CisEiz7yZLVKmrBoJb85FC4rLky HaImoScd9JY0y8W/qkZyYhVb896AiqAs9hZbLWn5UGZCWVkPwL7NbUU34QaYlEcb9wuXNc8LTgG Y0F3hBoaqCDlBS5Fl7PL3ZvwzjhMj1dl1Ewlv0FNgL6xLMQwxiwGgLHBRRn0CJtTjppzITO+lQ7 Er5PevJnlXUjHymBOr/O4Sk75R73N36DRbW3bUAF2DJVDbUWYgHg+a5Wo5mvb+FZCAnfghDZtYL qJtER/q+j9QpV6V3BWZiEpDJR0FUc4GvO7OmfiOmmrYC+RlcHWzDBJuvmxbvzkJbpRPKjIS58FM K7CQHXoa/bcGpuF5pJZG45v/SCzpWCnCTAY0kyF2SiF3tz4moPWJzVQvHqIpXY= X-Received: by 2002:a05:600c:4e11:b0:4a1:7f41:b9dc with SMTP id 5b1f17b1804b1-4a18e4d67famr175900485e9.23.1791800617610; Mon, 12 Oct 2026 03:23:37 -0700 (PDT) Message-ID: <059a456c-9f84-40d3-8f88-7c9599abb04d@suse.com> Date: Mon, 12 Oct 2026 12:23:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 03/15] x86/setup: break out E820_RAM accumulation To: George Dunlap Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1791800618-FD06B034-999596D1/10/78276251493 X-purgate-type: spam X-purgate-size: 414 On 12.10.2026 12:20, George Dunlap wrote: > On Mon, Oct 12, 2026 at 9:20 AM Jan Beulich wrote: >> >> We already have two instances of this, and we're about to gain a third. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: George Dunlap Thanks, yet to double check - did you really mean to use this more private email of yours? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:32:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:32:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446114.1662160 (Exim 4.92) (envelope-from ) id 1xGDJz-0007oz-0D; Mon, 12 Oct 2026 10:31:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446114.1662160; Mon, 12 Oct 2026 10:31: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 1xGDJy-0007os-TQ; Mon, 12 Oct 2026 10:31:54 +0000 Received: by outflank-mailman (input) for mailman id 1446114; Mon, 12 Oct 2026 10:31:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGDJx-0007om-Nf for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:31:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGDJu-009aTx-RU for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:31:50 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accb70c-bab6-0a2a0a5309dd-0a2a4507b5c4-24 for ; Mon, 12 Oct 2026 12:31:50 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accb716-b4ea-0a2a45070019-d1558032c814-3 for ; Mon, 12 Oct 2026 12:31:50 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4956869750eso13551355e9.2 for ; Mon, 12 Oct 2026 03:31: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-4a18bf2e0dbsm295840355e9.11.2026.10.12.03.31.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 03:31: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=1791801110; x=1792405910; 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=D3EkwhjPwR0pwICmf55sHME9fFLTOEn62ss/srOgbW4=; b=Yp4XA8pAOPKAYXXKAF/66gMKu6ZGeIPRfOt4jRIF7eNVkEAbQcXlLAV+ZskRewV9P6 rPyrjoUBHGzLsi4yI9XUT25N7lygyJSbA+DYL+42Zrq7cFwRPhddHHn0IEmu1AsifFJS f+fXtpewe365WEkewV/zlykXYdL04/e85iRrsiri+pCWNw6in1yYugKstXjQXOWZO/9v MfQ5O3GbHtoOFUPw2WaUlWk0rLklG3y44SeS7PwavuEcdAwDj1LETV4iQ6PP1EGLVgld Lq1Jc0GfjvJBr4/Sk4hV1K8YNMkaJjCBR9J4m1GlqaE9fHg/8Sv5thU7A21dLvCrJ7ID f1QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791801110; x=1792405910; 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=D3EkwhjPwR0pwICmf55sHME9fFLTOEn62ss/srOgbW4=; b=1ejEBJtmLRz3QBYwWvJ9zg5HH+/TgbeE+xOG5VU7/WnCzP2u3ymZxXW0L6VXsi2jN7 5vyye7tkLuoPj7o5+71mykLa0GPXV9TP1qMQAKXIGnwkLoq6B9xrVEX73iX4BaB5JEYh DkjSdQ3gGSpPNndst4ipaRCKCDmQJgDpe109Pe9LrrDbkGqggt1JHNds6hroOcF2ZpuG 8M6s+ZRUhiTeFXFhTh/ILew83vpK6hW6KDQrDR5UwTlUCh1Y3W9snzEVhdLddue1AagU 20yxOEBCKbreRukNfgnOZ/BLVGuGQWJTczlA7JG+gFLm7fpahbsEQpQFJ/OMJOhHyTx3 Ve9w== X-Forwarded-Encrypted: i=1; AKwUvByFlr6W4l+VoiO8WbN7uxI9qdVDyrXKh9FTe1/254oy2KCXSi6f2izBqG4YZdSqZUAHjEcNBEmefg0=@lists.xenproject.org X-Gm-Message-State: AFq9FYIQPdm/gzVBjTi4eh5//xaM6mSlbqIj+0T0MuNdJjmnjF6AOUse TYnyednmtNJSG/LUPeiBsPglajPOH68zp/3cGo6PrCpXvbRz5wz0ZpVUWbWQcFo+7lkIsMT+70i YhZmhGg== X-Gm-Gg: AYBFou3WLunIM0acbZLu0kDF5Buhlzl02XbQEy+XgWK2IX59gSJFxaMzGsMsnzPkgff GHFnxt57XzqrsutwU3Kiw1Z0neUL7jrS0zwP9lCs/uczNsfdxnvAX9AGFZNXxnWzhCpwSqGhzEV NRGF3tVpLDWdSqBS5yY1KeQ/5aODf0W9DdN7me8KI2IyqAlZKlKWbHuN5W8WWDqt/CzVlTnUA/9 zIsZU/FfEIZumqgC9lzW0Yt0CQmRcSO31oP10VIwDXWVksWXpF9FtN3I/7nELzaH6JGotP4XftG MJFCQoYJXC1G5MttGcgxSrsntm9rO025q3vPK9Xk5CQzrWetRWcuH+ysrz8pR9oR/Yxl201ZwBz ItRt63tBInayqzk2XdaVyo46RsWWKFx6mRHUtlBGT6DGTqBU17apF347YwtS/0tFzvM4zYrvsc3 F+DdQ1PaSEfUdCG7LSC4Lm7XN8kWrHN+2QQD3IeYpidFNPYpl1/N+XW+Ts8miTCPlkLFRfz+DoR AYZSgaJz85zJvjeZIXB5e/GJM4ub0xNcievlr/vrZ4JGKXAHS6Wop9aHyHcxq4= X-Received: by 2002:a05:600c:4ecb:b0:49f:f099:6fb1 with SMTP id 5b1f17b1804b1-4a18e4adcd0mr174585275e9.15.1791801110012; Mon, 12 Oct 2026 03:31:50 -0700 (PDT) Message-ID: <293db510-108b-4fa4-976a-2f794a8cec3a@suse.com> Date: Mon, 12 Oct 2026 12:31:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/argo: make the ring copy length check overflow-safe To: Weiqi Wang Cc: WeiqiW , Jason Andryuk , "Daniel P . Smith" , "xen-devel@lists.xenproject.org" References: <20261010132845.36208-1-lukewang19@outlook.com> <0e9d573f-299a-4459-81d0-94c905c85c8e@suse.com> <313B6C1B-0F8A-45D4-9392-90116DDBFD82@postgrad.manchester.ac.uk> <56F5DC58-E7C5-4C24-996D-4D9997AA8506@postgrad.manchester.ac.uk> 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: <56F5DC58-E7C5-4C24-996D-4D9997AA8506@postgrad.manchester.ac.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1791801110-A46CAAE4-E488CB16/10/78276251493 X-purgate-type: spam X-purgate-size: 1461 On 12.10.2026 12:01, Weiqi Wang wrote: > 2026年10月12日 11:00，Weiqi Wang 写道： > > Apologies for the confusion. The two names and three addresses are all me: "Weiqi Wang" and "WeiqiW" are the same person, and lukewang19@outlook.com, lukewang19@icloud.com and weiqi.wang-2@postgrad.manchester.ac.uk are all my addresses. From now on I will use one identity for everything. > > I will resend the patch so the From header, the commit author and the Signed-off-by line all read: > > Weiqi Wang > > Please disregard the earlier Signed-off-by under the outlook address. Nothing else in the change is affected. Thank you for catching it. Thanks for clarifying. > Resent patch attached (bound len first, then compare offset against the room that is left, as you suggested). I checked it against the original guard over a grid of in-range (len, offset) pairs and found no behavioural difference, and separately confirmed the overflow case you flagged: with len close to UINT_MAX the old guard wrongly lets the request through, the new one correctly rejects it. Unlike in the original submission there suddenly is a comment. If it was a brief one, I probably wouldn't mind, but for the situation at hand it's imo too verbose. Preferably with it dropped again (which I can easily do while committing) Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:35:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:35:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446121.1662170 (Exim 4.92) (envelope-from ) id 1xGDNA-0008JW-DK; Mon, 12 Oct 2026 10:35:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446121.1662170; Mon, 12 Oct 2026 10:35: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 1xGDNA-0008JP-9x; Mon, 12 Oct 2026 10:35:12 +0000 Received: by outflank-mailman (input) for mailman id 1446121; Mon, 12 Oct 2026 10:35:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGDN8-0008JJ-Ca for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:35:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGDN7-00BZBQ-IO for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:35:09 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accb7bf-e002-0a2a0a5209dd-0a2a4503c72e-46 for ; Mon, 12 Oct 2026 12:35:09 +0200 Received: from [40.107.130.138] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accb7dd-fae8-0a2a45030019-286b828a5716-3 for ; Mon, 12 Oct 2026 12:35:09 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by PA1PR03MB11363.eurprd03.prod.outlook.com (2603:10a6:102:56b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.21; Mon, 12 Oct 2026 10:35:05 +0000 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292%6]) with mapi id 15.21.0496.019; Mon, 12 Oct 2026 10:35: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=jfv+yyoQQXxWNLMNEaTl364gTejEjng3mzk/Fze3sxpIhLBi9qPXGxYjZil2ijwL+b0JQgZ+ZYtwllza5413LY5pShoOxdEwmj4kvV/gIJwpA1IB8fCr1okn4npolEJcJTKgrjdy+nDII8OkkpSc3Y7tdHWo7BtlN2vQeCtOd82qQ/6sHnnWWSWOr/nhM/c0Qed/RS30k72jy42UZES9Vmd1iSER7slrTFCCFK3v3tBLU2+HTDc3dAwUlDGGz5jPKeGR1tpXheVzvW1i4zX98umAJIcnbJUN7C9SUM+D2hpz0tDdGjEwBp8Th99EvfHFP7J9wP0buq83LH44bnW3XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+wNqtXDBjGhsye4upC2DSzCQvfIpnWcmdwayz8TVGyo=; b=Y5QLiOT5IOHDCiDE9h2denjFbDvxZ4Lafuxgf3Feh09dyEISrHpnKKLMWTQnsGVw4oR64uSPOC8bxNpCh8irjUSMsR58mNVLqpKodh2zfbHrycSULpel6mkvyaUI6UWDBnxNfLRxqva6oX4JshNbuHTPn+9mmEIIBSGUBD+mDEguP8dtlrEXUIdEjXSMAGtzMkmBxfMzdZsID8dws7VRx2ugpY0mBlc0hYpVFj0t34zxaEoDnYnzWokZRXFhEWfsfgiqOIEweG7z0oGf3wLC3Xn0U+RBxAzDrnD2MFNmRxyXzjIvk4FbdmXUgrw4P/ZBx4PN+CAJwiALQVOc9EnXeg== 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=+wNqtXDBjGhsye4upC2DSzCQvfIpnWcmdwayz8TVGyo=; b=hVmY3JIKg64i17I1Xfh4UKfOUpCZNhRbtQFSGPGYBlQMHfq9s7zM5GQPdtslDw6/D2CQVktIxXvwZywcN0mvzFBqS1b0xg7HMKVlf7OnScV7+ibnWZjKNiU93XAqNcG4eP1Ylxl8LMAhf4Tld09DdN6ntuE72LK0vwF+XkMjoLeM8twIZh0k4zX6qOfWXWUVEWvtpvjsRVNqvxVwDTnGg3H/Gsx5thmWBrkyNaQde3ZWMCNLb522/DjWQdUiciMOaI1DB7uitlHqUiHCVlqiaJsTv4DuSwHfQdDmP0UcQoZaBkZ0gNmE3TFAWEt8SgPXDlYuXe9svLXGwKYhscAGyw== From: Sergiy Kibrik To: "xen-devel@lists.xenproject.org" CC: Sergiy Kibrik , "Daniel P. Smith" , "Daniel P . Smith" Subject: [PATCH v2] xen/xsm: flask: restore sidtab state on policy load failure Thread-Topic: [PATCH v2] xen/xsm: flask: restore sidtab state on policy load failure Thread-Index: AQHdWjVYBo9DplgOwUK4YbEqpVPTqw== Date: Mon, 12 Oct 2026 10:35:05 +0000 Message-ID: <20261012103504.964430-1-Sergiy_Kibrik@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: AS8PR03MB9192:EE_|PA1PR03MB11363:EE_ x-ms-office365-filtering-correlation-id: e8eb8d69-301e-4bf2-a2f4-08df284c7ac2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|10067099003|261009223027099003|38070700021|11063799006|18002099003|56012099006; x-microsoft-antispam-message-info: jbQw+ltm+SdFstHR3IZ+wvBjTt1FikCExtoPSAlV1oASK1fzq5rcM294okkdekVtO0JxEDbwZU5d+XMzA/61hwSQlb22QeS7ARlkyFfKl/hEVg8aZzeuI2lGWXCe07zi28lnfSgJHQOOPC+otOrqOvBp5UHdei52Vx/8hlQXRe0KrsnRuq3FlBGV+U55cVIVdl1Zhiz+MnyMt6v/exwrMwQyYNAP1Lz2slrUm4WHl0hKSgHjFSHd8r/g8xWLgWEXLaTS4UjjLyHxuL3O6/TyvaXy4IFXQCOHBEWvODob32l/5frBwSi9VVyWiSbo7QCDqS1oJqB4y5vWvEIql1HvblvIP0/N48xQL2tCB7gM534YN90vkxU3JpaYSx1BiBdAyO+Qshac8QZuG1UUdT/KpxSTS1bQAysMqz49mF2yubqsJsGUdexwCCfg3nhqDGm1/+X/SyePP8bZ3PUmxePP+fi7Cfwv0BgwCtVQxj3PTkhUK3cdXogbS567RDY+aDIV5SVVYTynzkHsloyalczBoaeH0kcY/Cs6ysbcmtJQTMQGrMXq0xnR6lbnC0RX4MauLmg06cjwiCFdzKHlXKPdBxUKMYvn60ffnLGrjXdcFqWaiu44aI1YO5oXUoNRgLdADjnJQRkcJ/vXicGCPRW4sk56ZRaEQkKPIoC6q/BlOzPfEBdVGrCr9FQ/nu8bIglkI4ezBr4b4ZDl2XPQRdltDRGRs/MT/jib8XMy4Y0Trio= 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)(23010399003)(376014)(366016)(10067099003)(261009223027099003)(38070700021)(11063799006)(18002099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?i6jZBdG5O9d3bevUVZHaPzW59h2alTDQ1I5JKup7hnU0LHuOQQR+pA5cf6?= =?iso-8859-1?Q?3ym7W4qG+Ub8/mIZu/PU5/qP0t/k6raxIDnAKyCR1U/1zSVflg4nP8vyr5?= =?iso-8859-1?Q?EXUmtMM+ox3YOMdF4iL1Ahj5QsSzMe80ysrNAddIQq4g260SNMshLxwx01?= =?iso-8859-1?Q?WSqUXYUU+nGW88Q7sx0l1ELj1gZgiSUn5GZxr5+yJH42CsgY+v235kXwNZ?= =?iso-8859-1?Q?+vBVHgifkspuEbb0w6YOY77LkR2Oz5S7oIFK2lHKIhNrz3pEw/y0oSnx2k?= =?iso-8859-1?Q?1CS8dY5XWIs/n7Rx1xfeTMfb36PZ1KWQdJX61ctD3B79JteZHeIODSAZqe?= =?iso-8859-1?Q?Y2TOoCSv7B52xaqn2XlFyINiHrmK17U80+mPMgX1CEekK3VUmal23ZQ7hx?= =?iso-8859-1?Q?metwrjkQUwg5R2dJz5NFYY/Fc86gGGMaKXeTxrX6G6xm/0VbEHP+lYIDki?= =?iso-8859-1?Q?D+lRKPndVS40qlaYVRlM0/+sBi91CfbclQRQR97AZgvuiK6jncX+aJpkcm?= =?iso-8859-1?Q?2q6WNgh5QpHWHMl2m9qg6jCzOjmzxfGcWmhcwMFmw3X0/2o6vVJlC4yrrU?= =?iso-8859-1?Q?Lyr0EhTm8z8sNxz2C67sctWMhN/PXMnmaVQRWvS53LxhqVrQ+pMAPO71Ya?= =?iso-8859-1?Q?0+Ryt9NXsO9pmB1qBsS1gqWvssBw1yh/yxom5g/ZgpiXSaaLfFf474t5Si?= =?iso-8859-1?Q?LsemM0ZM8hxKzLfnqC1NieimZV4LZp0PqBScD2bl1qy8qEoYRNWU9ZtvmF?= =?iso-8859-1?Q?S8w9mTJEDOzn1fIDPC6BP/bOmsWF00zhzCbliqkxNj7sF0SZfwIaxU7J+P?= =?iso-8859-1?Q?vs1MgALzYrsRGcBLtkFgZ9MiPwws4eCBUPu5dAcwPo7wT1MWSipXHawc8q?= =?iso-8859-1?Q?Ano7bJQBM84shCWGupwcnh06qOzynoM3F86hwKLo+LuFJh/ad4+Z/TyMYW?= =?iso-8859-1?Q?upsVtkcaWBhkms4xS8vkGB9z9yGKL3z/ZvnP/h5imPHJPx3Kkyk7RMRQnb?= =?iso-8859-1?Q?pQ+Z/w4vaHKRdxITjRaximixwfDBPn/tHwH+MAX+FCRoC23XOwhHxJ2mrn?= =?iso-8859-1?Q?QSftQNWsiTlpsDi0hq7sjsZs73ydqp4ECgVoJne53YD10oCq7VSRh/abfC?= =?iso-8859-1?Q?ZhE855RACX3jlhdTZ6ySbdtAJBI850ooanOY9lDBroKfLPvROqmhrEYl2s?= =?iso-8859-1?Q?rwGpfEshhtbXStBOnztQ4kX+yzz/DJ08mkRRHg8Vo7nakRVpmpa7VWQUUv?= =?iso-8859-1?Q?/eXLTQ4rwukFn9vdTk4tPHziDKEYjPFCNi/p/KciUiTooNXBMaOoMQSn64?= =?iso-8859-1?Q?7oIbzpDbqOSydFnD+/60yfBg/qTp57LnSDy4SpePXejZH1filIXMCFDsAB?= =?iso-8859-1?Q?Ag4tVHg5oUkFhvkRyoaR82D16usr4Tn6fwGBQcblxMeetmv/D2LGY2Sa4k?= =?iso-8859-1?Q?5r2JQpe2gfnTAdl30SHZRumPBYhKdnJk/VdbM7s+OfAck963Aq9VaoGJ/j?= =?iso-8859-1?Q?Tv20LR96/vtRtg+rjo3InsqmknMTsx4BbGJsfKhxfk2TU/aj+Nb3KslmZ0?= =?iso-8859-1?Q?lt/pCC4wHcLCSGyaWsqfmv43RR2B+3Y7bYUWSjnsYUUnZx0v4mFlZYJtCO?= =?iso-8859-1?Q?TSvg1q8F2AwnE89DFfSc3xRVfm34KPJccXWgtguOhuNCDZM3biFQiiVtOt?= =?iso-8859-1?Q?7RXe7ay588WwjgV1Eoqsc6rqQ9q2WLugpaxilkamsHIgNe3//ZYshdWRQ4?= =?iso-8859-1?Q?5H+69zGNnuEET4mF8pMfjCrywN9JjYahgVa7T0pFUfX39JD3eFjhmT4lGi?= =?iso-8859-1?Q?KmYjcWdQsw=3D=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: AS8PR03MB9192.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8eb8d69-301e-4bf2-a2f4-08df284c7ac2 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2026 10:35:05.1697 (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: kGcVEBFuNLbVFrN7IG8MTQ8PNs1TMxZoc+yLiGKp89DLfUdemEauuWmv62dTcj/rdzJEvCkamtIaYxb4KikWBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB11363 X-purgate-ID: tlsNG-33051d/1791801309-7488A4E9-8E8539EC/0/0 X-purgate-type: clean X-purgate-size: 1996 Error path of failed sidtab_map() leaves global sidtab in shutdown state an= d from that point system is unable to allocate new SIDs in sidtab_context_to_= sid(). To restore sidtab state new function sidtab_cancel_shutdown() is introduced= , which only resets shutdown flag, rewinding effect of sidtab_shutdown(). Signed-off-by: Sergiy Kibrik Acked-by: Daniel P. Smith --- changes in v2: - rename sidtab_activate() --> sidtab_cancel_shutdown() --- xen/xsm/flask/ss/services.c | 1 + xen/xsm/flask/ss/sidtab.c | 7 +++++++ xen/xsm/flask/ss/sidtab.h | 1 + 3 files changed, 9 insertions(+) diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c index 57beaafa9f..9e01e8f730 100644 --- a/xen/xsm/flask/ss/services.c +++ b/xen/xsm/flask/ss/services.c @@ -1428,6 +1428,7 @@ int security_load_policy(const void *data, size_t len= ) if ( sidtab_map(&sidtab, clone_sid, &newsidtab) ) { rc =3D -ENOMEM; + sidtab_cancel_shutdown(&sidtab); goto err; } =20 diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c index 69fc3389b3..74fafba75b 100644 --- a/xen/xsm/flask/ss/sidtab.c +++ b/xen/xsm/flask/ss/sidtab.c @@ -320,3 +320,10 @@ void sidtab_shutdown(struct sidtab *s) s->shutdown =3D 1; SIDTAB_UNLOCK(s); } + +void sidtab_cancel_shutdown(struct sidtab *s) +{ + SIDTAB_LOCK(s); + s->shutdown =3D 0; + SIDTAB_UNLOCK(s); +} diff --git a/xen/xsm/flask/ss/sidtab.h b/xen/xsm/flask/ss/sidtab.h index 0e48ec6eae..f664cbed60 100644 --- a/xen/xsm/flask/ss/sidtab.h +++ b/xen/xsm/flask/ss/sidtab.h @@ -49,5 +49,6 @@ void sidtab_hash_eval(struct sidtab *h, char *tag); void sidtab_destroy(struct sidtab *s); void sidtab_set(struct sidtab *dst, struct sidtab *src); void sidtab_shutdown(struct sidtab *s); +void sidtab_cancel_shutdown(struct sidtab *s); =20 #endif /* _SS_SIDTAB_H_ */ --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 12 10:49:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 10:49:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446128.1662178 (Exim 4.92) (envelope-from ) id 1xGDah-0001w2-Fq; Mon, 12 Oct 2026 10:49:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446128.1662178; Mon, 12 Oct 2026 10:49: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 1xGDah-0001vu-CT; Mon, 12 Oct 2026 10:49:11 +0000 Received: by outflank-mailman (input) for mailman id 1446128; Mon, 12 Oct 2026 10:49:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGDaf-0001vo-9j for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 10:49:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGDae-00EHF6-1M for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:49:08 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accbaf5-8faa-0a2a0a5109dd-0a2a4506bb02-40 for ; Mon, 12 Oct 2026 12:49:07 +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 6accbb22-195a-0a2a45060019-94a39b0c885e-3 for ; Mon, 12 Oct 2026 12:49:07 +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 69C8Kr772698669; Mon, 12 Oct 2026 03:49:02 -0700 Received: from mw6pr02cu001.outbound.protection.outlook.com (mail-westus2azon11022142.outbound.protection.outlook.com [52.101.48.142]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4h7kfdk2cs-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 12 Oct 2026 03:49:01 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by SA1PR02MB8367.namprd02.prod.outlook.com (2603:10b6:806:1f2::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.21; Mon, 12 Oct 2026 10:48: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%4]) with mapi id 15.21.0496.020; Mon, 12 Oct 2026 10:48: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=2WuatbzrDRA+zw9dJ0d6/9J0dE5mRwP8MVtGHToXS HQ=; b=qd3y1n/onbKw4GZIomuzFGQSlwb1g0rV66FqJ234O5aO74ukr4sgCVkuK 8DQIdX3FvS1YlQKFZzBXkKpeHM0aWb7Sfpvz91CwzGIY4frNs/5icGjrLGCrgMT+ wbghUJmWAFsPNe6RsUM5zWnNUI7i+2ElQFRTM1EacAc68dxyZTyyWNk7ze1urQ1k mlC50sJBcF+XvIkXJ1zbFUc4GNrS87iy45ouFWI3v5VtOzFM0/s9gMjiuQDo1qht jz3RiAWeEnV6khVgOAkWR331OMrK1uQOYRow9z6IY8T0s6a/6Kva/bV6T7uoqn+w 64/HozJm81QLzkwoHTeKO0rCM4iNA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ENL0XGGXBzsoTABX0PAFyRZxSIHIaxZgia/KfPG1RdB4t7y/VS6zBKigOM1HEGr3Vglsb99kuVqTDPN9MX2s8QXSOpTt0LLJtB65I8W0GTX5iIPJwnXYByVsEflQNScsUNuOhgJe0JTBjW7m+JCwM2kql5a4b33I6uIA03bYCO/OHIJgq6WtUwL4NS3QTxK36sFeAZP9mKOEubXOZpjC4vU9HzCIOj9bt0pr7F34Nd8/ZulSoxRiTKaxb1+qzlY7XsHlzQb8GhBF8wKewK9I5fRUiuEPHwg0NuWpW9AyGWqSC9GYCiQdzJL1hvZLlIbdPcFutSmz7BVJJdhFcZOvMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2WuatbzrDRA+zw9dJ0d6/9J0dE5mRwP8MVtGHToXSHQ=; b=rzkpZ+ctxiTWP39WGrXZXF3u2rWLYvNwWFFoBADB5rjTJ3qFnm2p1txEKHs1Eovkm7DwZBhCeGdAv/GK+1z3wExR3TOzj1z+1KBrho5pDjXgz11HsKVcspm1Zp79V2PCjNzo/KxHGw3Ta+Uul5Ywg8TI8EkPeStGq/fIlMGSKur3ta5NDfie4kwC8PYg4utTUklh20Ir/qFTC0ipYud2K2aIvDsz3AzG5RuqHPL9WlNw8uxkP/seuCQz4N/RSj9qlL78giABEx95eWCwp5hpYGGgcHYnFk1Qbhe2+OdokZaBAJLsFgVJEJTWgh9rQ6uqxmm/aPRp9bUckvB3J16ung== 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=2WuatbzrDRA+zw9dJ0d6/9J0dE5mRwP8MVtGHToXSHQ=; b=gsaOo1kIWG3fQMIvfjWkW+ZUKqDgrgAPRlQs4wj+BuunCtPLq1ncB8brPeHbLJvWo4g3rvsQtuFlrbT8T+KSGOuMmTjuINoJ+c56lDw/DFsiJHwPgiFxovmkaPmA8cuQEeL0feb7YUsjPokIrKq/N4kYTk42Quj3hLD/KvdGT8Kmt+3/DoivoxnGAJsSK5W5pKvd1zv8lz7zGQq8X1qYKGIGATyNJtOfIZ7aeaL9J6/0u14ONvMDWfa5NwdKnC7EUUDNqmxyQO6uUnzZW9rsjYo09sg8a+1GkosWljA4zSYLWPX8z0TBAiPHJXM9qA07kyDvq8PejAhSUwbVXod1mA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <3e1d30bd-0c4e-47ed-9970-6713b8295071@nutanix.com> Date: Mon, 12 Oct 2026 11:48:54 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/22] i8259: improve qdev PIC modelling (and misc fixes) 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Language: en-US In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY5PR04CA0024.namprd04.prod.outlook.com (2603:10b6:a03:1d0::34) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|SA1PR02MB8367:EE_ X-MS-Office365-Filtering-Correlation-Id: b6e83544-84e7-4e32-eff0-08df284e6bca x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|6133799003|10067099003|18002099003|22082099003|3023799007|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 2tIHwo+cbOnMCuNu32GoVRYFukmquiGmlIpQS+Wwd5HLKL6NHvz2pWyCnyUxR/dvQgWZlvYcGcAsQBQrgUBrLjIEP/KOwkFtfc8IMQAvqYzglYP6fNq79lgdrc2w7/sUbbDEniYudIo8iki0vlGWEH68XvQkbhUL2JU9+MRMyFfWtyRBIBNlCCyL/tas5edi4dedO9gp7k3CZdYIklcsR259yK2VrguGKHPWuf4LJ75Dw/23N7t8iWHBvAjtMLxm9JkE2ZuPW/cbD9R6cFUj5kzRpgxzT5tY2L8H4CbxXm/0Z3otfVyWLZbYQKEpIKybe3BGveqrJptXtk5mjwJpF6jzUuFI5gUlh0cZji/G3V0gIjbdc+KTI1lB3/MiMnSZrgvmsTGRk74/QEiuamjJEFLwmqQhS8QYYFUufRqwOb2VCxKBbNJSi+isGisUmIbiyJ3VhTpzJNuBLIzjyvp62B0IKrTnG5kDyvZh9IGCeI9qSvyWuN0awCxV9TxyqvQbhVv75m8e0rVPseZWeRP1+ynvp8BY+3Z6XMbsY7LGd3SsIj92Xxh9Uc3sCJqj4HzIvEFNB/yFzE02NSmu/PkM10CEF+wIU/Lr/g0EtmZqwRmRTS7BscH2DPnGclFLh2TmyiWn77AdtyvtrqxEBmB3mP+VK5J4+kRcIn0o3oqZ+iw= 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)(23010399003)(376014)(1800799024)(366016)(6133799003)(10067099003)(18002099003)(22082099003)(3023799007)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UjMvYWRtaEtFaEx6Qm95ZUI0MERJVDJMVG9CdmFwbE1LanZRSDIvWVZLMG9K?= =?utf-8?B?TWxtUG5OUHNLZjJhK3h0bkt3UW1wMk91MTMwbzE0REdudVdwQkxIWE0yWmV6?= =?utf-8?B?ZzFxYVNzR1Zva0hFd281SlRnZk9uUXdHNStyMi9FQW45aUwxNm5JNFkyZGMr?= =?utf-8?B?VEhFUWpJbllVTktGN1ZZdis5OWNtb3hSVjVKdHVRenhCbkNIVkRuNHZyMDM0?= =?utf-8?B?OUNWOGRMR3ZsNnNCZEduMDVIZTVodGIrQi9TbjEwcU44SDFWcDZoOVdaeEpl?= =?utf-8?B?dERIRW91MFo0cm1KOElaUWJsbjF5bTI4dThERm1vUW1DSG5uaG0zMkZZZE1Y?= =?utf-8?B?aXNzengxSVNIbzFuVTljS29DVUNyMFBzZ29rQWMzMmNUOFllejd1WFFpZzc1?= =?utf-8?B?MmJXakFWMkdCMW16WWVOelpVNkduSXZ0VmoyMFdRNkJLeXd3ejJqNzFrMVpZ?= =?utf-8?B?SC9acHpaM2I4Sld0OERJVFZXRVVxSWtya3lHcm1HUTdaM01TdnAxYVdtS2Yy?= =?utf-8?B?STFmUUV0YUJFUmozVFdhWXc0Q09IcnBWNTFOWUxMdUVMYUVZTHFmSmkrd3pS?= =?utf-8?B?MHB0WVBaYS9IMEFzeFhVUWJHNlRWbERub3c3NFBMUXlLMllJa2J1UlpVYVd1?= =?utf-8?B?UzlKelJMd2w0T053ZUd2bFVLbGEwN056LzNNbENMNE1BM0RWYXAwZUtRb3pp?= =?utf-8?B?ZnVBMmZZZG1MUFVhTitwSDNtTEFTbTF6eTd2aXdmeXNhTjAvanFRVHZHMVk4?= =?utf-8?B?cng0cUxQKzVhL2RINEUyMnlOeEY3ZlNHTnBkTDgzYnZzeHAvL0Z5Ymx3dGZ3?= =?utf-8?B?OU5RdUVKakpIQ3pTcXRHRTltUERIdXdkSHE4MXR6T1dmcWVlekEwN0xKVkRY?= =?utf-8?B?VUNNQ1plSFVBencxOFF0czBUdGxUUXF2ZWIwTjJtaEMwU3d1OVdxZUxnT25l?= =?utf-8?B?L29CMHhQZEdmV3Z6Vmc3UWQ3Zk8wZDIxdVJnVXE2MEFwQWVoQWlRbEZwOGFz?= =?utf-8?B?UWRhMEFrVG5aa3h5Q1JYaFlXWDdyRm5YMTZ2aHdoQ0FMb3dhVlpWekdUR1Iy?= =?utf-8?B?YUowRTk0RUFtKzhkNHVEZnVhMHVZT0l1ams0OXpmcE9QKzlpc043SzhKUFVN?= =?utf-8?B?M3N3aEQ2WGFjVXFMWnhJZjN6cDBZV1hIRjdOc2hsTEhuK28xSkovZkphZzFt?= =?utf-8?B?b2V4Rmo4Yjh4S2NFWm52NU5Wa0FxWmNUVGpPNElhKzBUYkJpbWovWG5DTjNR?= =?utf-8?B?bmE2elgwNHkvVCt3bk9WajJIQjRVVUkyMWV3M0o5Y0g3MkVYOW8vU3VYcDlT?= =?utf-8?B?dHVDZFE3Z3dwR3hKRTliVmdrTVNnTDk1dEJEajhkZjVQYUx4cHk3U2Zhc20w?= =?utf-8?B?UGw2TGJrV0ZDYVRWOFhYYXlySUtyb3dyM2NsMGdRNkdoSjNYRDNKZ3lXVmZV?= =?utf-8?B?ZFAzc3cxWHRTUTdLS2JId05LcUxqM1J0dysrNkdKeitkS3pQdUJPcTVteGdy?= =?utf-8?B?QzZOVTU3Rm04WEhwZ1NmYXlXUlVCQVhFZHNQK0FwanplYlJuUUlkaDdRaE16?= =?utf-8?B?d3NDdHZDT1dnZ2E4aGR3Z1BIUHhLRmJUUHU1dFFIMXZublZNc1dUdlNtNEt2?= =?utf-8?B?ZmtYNFlKRmRiRjNuTEFPdVk1WFBXRmZMMzFNTjRvaXBOTXhtSVlqQld0aTBW?= =?utf-8?B?V2tiSVJmdTFwSzhCN2xiWmRWelp2WEl1bUpsYTZBTEVMZ0U4Mmh4SmRyZW5m?= =?utf-8?B?MHUzKzJheE9NbEZDcHFMRFMzVDBHSGxLYjFIZGttOHgxbUhnbzhweE9XcW1n?= =?utf-8?B?UDRvZUcyTE5INHFZWlgrOFcyYlowbHM4SGZyTDh0am1IaEhseFJRZUs0NmhZ?= =?utf-8?B?dFVxbW1GMmpZcytYVVpyemlYT2hKNEdsL05kRE40aW5CMzBScC9nam91alFP?= =?utf-8?B?U0ZtcUh2S0JsUGgwZVJjQnYrM0ZDdjZQdXM5clNWZVF3Q3FjSkpPRmJKcDhH?= =?utf-8?B?WStHQVRURlMrQTFFSGJ2MUh4Vk03eTVZMjZ6WEtPTG5TTHVNRVpseEZ4K09n?= =?utf-8?B?RURXbVg4OEFGMkVxempwa3FkT1BOeDgyYnpZaTJPc0VxTDA1clJsS0lHWFRy?= =?utf-8?B?QTkxRzNuY2w4dXRVOWNRbkFtMWRhL0sxVFNTcjI4aVVLN2xGTmY3YjJDdWQ1?= =?utf-8?B?VW5UK3NQTjNYUnlpY3FqTm1sSVM3TUVveXpMZEVNK29hT0Y5MDBCeHhhaXNX?= =?utf-8?B?YzNTM1JUTmpCOHQwQmhqZnhzb3dlb0dnalVuQ01xQnpOZjhUS2p2ZWtCS0li?= =?utf-8?B?RG5rRVI0T0o2ZDY4elliQkN0cjRGUzZzbFJrd1JTT3dha1RkeU5PMElzQzdO?= =?utf-8?Q?MmvFGfb04kN5Dm9c=3D?= X-Exchange-RoutingPolicyChecked: A/5uju1BgF2apdBkF/odNodm9/OsEjiCixqDzjDtPmH5irqur3BhYUZNOfklgKz3+9onJLeXJqKkhZ/wvd3aUfafpYNlcp1fFjmdGMZlqdsyoCXvn7Ga2hBQzZRP+lu47cSqewm/gAwflN5Nfl08ME7N0ako6pOOi9Gx5dRD8oZq94xwSxR0vgUlbID+/Fo6xb567yb0c5iOTURcG3sucD0nqelUTLztjhjNnWs06Z7PUKKXDQQDaimcemxeNnO30AhahGAl6m0HqaQBdxbPDdoM9FADpwCllcFsG7czWXI92JR08vs/iY8tkiEbUvoyIlWJff4uf42Sxua8ugAIjQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6e83544-84e7-4e32-eff0-08df284e6bca X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2026 10:48:59.2968 (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: 9fiRkg9ilesidDQGnHPGfYALbiu9obVY+P4qCUek+NTIVy6RmgVz7z7/gRSVo1UXdW2DLCNXrNdfdiGD/Z8jChFpFYzS0+ZWMeqe1WWOHa4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR02MB8367 X-Authority-Analysis: v=2.4 cv=P7+vFSAu c=1 sm=1 tr=0 ts=6accbb1d cx=c_pps a=FtnwO7voBM5XWKbPwlLLuQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=KQXPNtfR79rSjg9_41cA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: YxEQLDjbDyeKnl-yzkjBbcPjtzpLtw7Y X-Proofpoint-GUID: YxEQLDjbDyeKnl-yzkjBbcPjtzpLtw7Y X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDEyMDA0MiBTYWx0ZWRfX2J/sI/lSgBdO 2nKWjyJoZqiJSMpmgbvo83SQR7gnbtgBy28yxZFsMUXkH2xQQPn6I54u8Mdt+3HspA78Dz5E3WD 3Iv+2QOCQwFwTk+NuxKh0I0yZTPVac7Zmr3UxhM94DLtzP2g5OoP6sQXJqntw+y9844y+SRe7yp Brm4livqnb1nD+zdazQEULxhRqcGlXgc5T1bu/1vzk+OvZ+26ek/ShtnEMbCVgYCKT9NiTb8jKX zqE1ROFdIC2CPCEXvlMvtHXMCyDEKYzpf/DJRQitySnxZRUj3ls6Saatx00b7CVtZaFJdCD2HMO Wuveu5aExUZZ0alZYilVDlDolNx1CLpJp/LpwDjSyJ2J8sYysWkSmbKOKxdY8RYA1L3RTmkj18M m6F+hd9bxnCpFWmVvbb2xPqWkJdy8AwnFFnJMndlkvJD0YlO9xd2Y8i7qan3uZtqd18eJrWjaWI bKBjvevUVXu3hq+cbDw== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDEyMDA0MiBTYWx0ZWRfX47NBYlfIANnI zLrsITh1XElj42uJWuCgzqSd3yz7SNEYxom61Y70KvsRZ3AhhU81d51R7t0OZHGGwIPTtHJ4Zn3 gAlJhZQOVb2gZ567oHikfxalHA06qw8= 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-10-12_03,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1791802147-FCE0677B-88626190/0/0 X-purgate-type: clean X-purgate-size: 3106 On 16/09/2026 11:43, Mark Cave-Ayland wrote: > 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(-) Ping? ATB, Mark. From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:12:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:12:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446138.1662187 (Exim 4.92) (envelope-from ) id 1xGDwl-0006W9-9P; Mon, 12 Oct 2026 11:11:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446138.1662187; Mon, 12 Oct 2026 11:11: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 1xGDwl-0006W2-6h; Mon, 12 Oct 2026 11:11:59 +0000 Received: by outflank-mailman (input) for mailman id 1446138; Mon, 12 Oct 2026 11:11:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGDwk-0006Vt-2t for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:11:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGDwj-00BgUY-0Z for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:11:57 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accc06f-e002-0a2a0a5209dd-0a2a4505d9cc-36 for ; Mon, 12 Oct 2026 13:11:56 +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 6accc07c-4cb1-0a2a45050019-d155dd30c86d-3 for ; Mon, 12 Oct 2026 13:11:56 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48c4d870d54so988260f8f.2 for ; Mon, 12 Oct 2026 04:11: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 ffacd0b85a97d-48db94e4018sm19213715f8f.11.2026.10.12.04.11.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 04:11: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: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=1791803516; x=1792408316; 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=WB7JnN3Pnr9p97cTZkiKT+bs6AiP8D5jZZ9qQ2uMm24=; b=XOExxaIRj86L07l2CFfMMya9akN8lid/Hhn0hp1gfTqbmKNZrLAgYGWlyQOeUZ5RTS q4F638Ric9qRbbZxOrseak5n+2iFskshhGfAZeNMNdM4oMuR7+66OYm9e6/wOQcfloTE DAa3gx3oqEuFMDixFEEs5qbdoxvmBzkp7jSTZ1YET+2IX5CrfOEEdXG0JEH4aZeI0XZo yQd4Wf/xPRWS+m8U0E2CnKOVJAr5CHZkBmzn0NHFSEau1f5OaGLBsk6w2xDQUJoBM/rF +gar1FKQn5oA+h/L7j3XfwY2wDnbuIyB3PkbubnH3Ymxvlsxwn7SASdy6Y92z7wS4mHF dPlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791803516; x=1792408316; 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=WB7JnN3Pnr9p97cTZkiKT+bs6AiP8D5jZZ9qQ2uMm24=; b=I3XUzYX3x8EJWfPZFEuH1QBgSVZ9Tfe8++mPtnW/Iwu+3L3xkf8fbgLBwpift9eKYO oo9WS07NcNXJAoYJXWLg+jdnMFWKxvj/fK/2NU9qepDOpGD1+RZtgErHWZuog6q7OIqE paoB0HQHh72RofgwBGeh4wsut5lN6k5S1v4pqNj8BeW1DZ5jB7vkFDXghBbpVHdg3jO/ ktS0E9jlEVKcgKoX2xVmSd7Uko+LlZUm5c2dZvFsVDJ7h9hSfzWcOjEadbIZ0uUfBjLf krdhbnQWWiYJ+WpTMPU/M/B74L0wdmyfZ/vEvoCYvPr28P016gHe7gp2T6YxcZ1fGaON B7gw== X-Gm-Message-State: AFq9FYKQWvvwf8CbK+9H56mjSED2qSPQSDrCEhbzegcYrojSckwK2hVI o3rkxndht7AyN1Au3pE7ss7jlN8vTnvv6Niwj8LzciPLorG0XIgTzJCKeje4Sxa9SPffwhsXxN1 ykeGcUg== X-Gm-Gg: AYBFou0yRy0gg0Z+j9REepdVN5d9ZYdD6+0C4FmTQjdeulFBZgPYkY0fEi71xtRQK7u XrwmmQt/pRPmi6ralA4mhHm9s0ff44TzrtdXlJSbNsP0feIb5zT0NMvcuABMuql322bAhQc/Skk 3A4b3FxLd7ovLj/9Czf00aCFt0B2F0lltvdPkn+wpvRS/2Kj/DUulmUATTGBbi9yxBP+Q8d0oZw T/dtHLVa44ZXpuT0PaoHqYKsfYJmJK6a9seSb/coY5vnm4kE+Tb0o3UgnDACHcSJk1mjqBrYbRT U8OArJV2Hk02mI1mLHSDhF4FvqMh+PtuK5VDXJUQE/Mlvuhqeaxzx6ueX4XiBtRePrboIlNTlp0 w6JZ1gNgGU1oi6E7dgB0lBYdwqt8dsOu0y3tfOdp3LFBqL692eM3HEWUwglrS90K4BSf9gcIjMX CpisfczY4NX3fwPjDw12HJXoCCX2slj7zosN2UHWjCIk5DO1JCK6Ucy7pofBOyewHQwBni5YzIk I7UUSxNv4MEcvvZ7xsuKO8xl2dY82gCLpDgQ4fJqnmttmkiy6k/vouPpJYKhw== X-Received: by 2002:a05:6000:1290:b0:488:83f7:633a with SMTP id ffacd0b85a97d-48dbaaf0096mr11363905f8f.28.1791803515927; Mon, 12 Oct 2026 04:11:55 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 13:11:56 +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?= , George Dunlap From: Jan Beulich Subject: [PATCH] x86: invoke xenheap_max_mfn() unconditionally Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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-c201ff/1791803516-253192A1-063D8CA9/10/78276251493 X-purgate-type: spam X-purgate-size: 1839 Calling the function only conditionally can, when highmem_start isn't set and when hotplugged memory appears above the boundary where the "short" directmap ends, result in Xenheap allocations to yield memory which isn't accessible through the "short" directmap. Accesses from PV guest context would then either fault or access guest controlled memory. With this the bifurcation done by 88e3ed61642b ("x86/NUMA: make init_node_heap() respect Xen heap limit") can also be undone: end_boot_allocator() can be called from a single place, and system_state is bumped right afterwards. Fixes: adc5afbf1c70 ("x86: support up to 16Tb") Assisted-by: Claude Opus 5.5 Reported-by: George Dunlap Signed-off-by: Jan Beulich --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1908,16 +1908,17 @@ if(j == 1/*bm->kind == BOOTMOD_RAMDISK*/ numa_initmem_init(0, raw_max_page); + if ( !highmem_start ) + xenheap_max_mfn(virt_to_mfn(HYPERVISOR_VIRT_END - 1)); + + end_boot_allocator(); + system_state = SYS_STATE_boot; + if ( max_page - 1 > virt_to_mfn(HYPERVISOR_VIRT_END - 1) ) { unsigned long lo = virt_to_mfn(HYPERVISOR_VIRT_END - 1); uint64_t mask = PAGE_SIZE - 1; - if ( !highmem_start ) - xenheap_max_mfn(lo); - - end_boot_allocator(); - /* Pass the remaining memory in (lo, max_page) to the allocator. */ for ( i = 0; i < boot_e820.nr_map; i++ ) { @@ -1936,10 +1937,6 @@ if(j == 1/*bm->kind == BOOTMOD_RAMDISK*/ init_domheap_pages(s, e); } } - else - end_boot_allocator(); - - system_state = SYS_STATE_boot; bsp_stack = cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ if ( !bsp_stack ) From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:16:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:16:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446144.1662197 (Exim 4.92) (envelope-from ) id 1xGE1O-0007CM-QR; Mon, 12 Oct 2026 11:16:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446144.1662197; Mon, 12 Oct 2026 11: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 1xGE1O-0007CF-N0; Mon, 12 Oct 2026 11:16:46 +0000 Received: by outflank-mailman (input) for mailman id 1446144; Mon, 12 Oct 2026 11:16:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGE1N-0007C9-WF for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:16:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGE1M-00F9d9-QK for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:16:44 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accc192-bab6-0a2a0a5309dd-0a2a4505b6c6-26 for ; Mon, 12 Oct 2026 13:16:44 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accc19c-4cb1-0a2a45050019-d155dd34ddc4-3 for ; Mon, 12 Oct 2026 13:16:44 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48b03f23305so1469057f8f.1 for ; Mon, 12 Oct 2026 04:16: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-48db9abda3csm20186562f8f.36.2026.10.12.04.16.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 04:16: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=1791803804; x=1792408604; 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=9GW8RSHZ7q65SmBGCALc7Bnt3JFbRru/E5/UAECuWIk=; b=JabTwVRcQSbU096AQmCBdiTYJW9FN+DynXaLHt3Q5lT+GlmYh7XILP7vz3bA6KQQzM XShCD8QmFas8XMZIL2MOuv5l/VVifdey/6BivT87RhtLLE5KpbQH9ypnCfhIba+XddRp ctLwSMCaMvC53yjMgSi1EwqpiNJtbm97EkgWXb1DrAHqbUOHXmuq+5pOr3yNK68uTo0W k/P+WAD8FoU5Xp7IPfVZRHGQNMnSwX0Kp7K4VqhSW29loa2/aPD6B5ejUf9omA4jP+3I Ad+Kcd9KjkLR1EwRXWA+94ZG//MUyIdWL/8Pv3bVx89LWOd0SZRThpMpe7zs8KdcrSmj 65jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791803804; x=1792408604; 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=9GW8RSHZ7q65SmBGCALc7Bnt3JFbRru/E5/UAECuWIk=; b=yeHMYvej+Nhe0nJ0wug4Ukgd7OWtUHpV9IBONx0OixYzhchToml2kfDs8w8i+UmtYo h84K2s2ng4DVZ0byrg4lfcN36Lv+u/DWa0ukG8ubhukE5H09lep9krXk6bB1XXCkqkFN zo6+DTLMWO+IG1FXk+h36pMWDOoEEKeBXvbAdhvS6BhkbFGB4BGGTM/wjQMrpaNcjImM R8zhpHo7kdDzWaMvyNMSgAqbfISD3wKlQapJ9V+xUSsrdcQkW9qTJup56VlXZW34s4oe FVNNmRCaZURwCiFsEacsHpHznaow+M7eEDRBwTdpuZg+Sx1V7tfwcYzZZHI4EfegcRqC eLCg== X-Forwarded-Encrypted: i=1; AKwUvBxk+vFpXOw/k0assw+8gtNmax6W3uO2OAkyYFIcz26BDHq2bG+pDlvsPcIZSVfj62Q9EHU6XxcTdIo=@lists.xenproject.org X-Gm-Message-State: AFq9FYJBXY6kTdvabYB5apJnGDsZycX0aUVncQrQEg8THcFOk/qdre2Z +NtoidNgmx9w9Dc3M32F9OnSQ5Huz1FnQDAZNVw8sXGn7TPEYJdaYJOajnUGXeL0Xw== X-Gm-Gg: AYBFou36LV/SCXgiE2BLrA3dDuXuu4iiZIpSk8cGHWwqXIL0wZzlV+p186DYsrGw/tw vlkfJS8Yp1OrVJhJXZtJhGVNJ9GobHwlFgjijrkLklj0ZvvhyGPr09IJqA2KhF43dqNewWngkNk ziFA/wI8FXrWC+SOaLyo1qZ/H/nR6xaoZsKFxE0a0dL1wjzjW/ErjIkLKzI86uSG3NtdFkwRo3g HFZDIRViyhx2zcdOpg/nGttMifxYHUrhEYOpGrcROhsZTAXEC9UQtNYubh2GPVzw+aRK8GawUH1 HwcspWpGTqqDgybSGol+Z/4VgUCG4PxG0JjfY7knsiTBGO8hl2wNz7v18JscgKR9ud5u6fNgQBr zhZv0ixjasgKebcgkFfmfoq4XvHHWw43ZM4YLJWG/rmynKpnGuice9vQs4ob1r1NpjnUAz6PLzj ozjtYsH6tykCRzBuqYGMmMZiV7tLA3FmyuYPtOR6jOjhRT5IM3LyQxHtBNixQizl0uQw0M96HWY aHg/r5NBaW0Le5Sb41qK9trfiG2kBwYgM8zPknCYBdVbSqQfm7Foo1DoC4TQq8= X-Received: by 2002:a05:6000:2913:b0:487:834:9307 with SMTP id ffacd0b85a97d-48dbacf06d8mr18489405f8f.50.1791803803714; Mon, 12 Oct 2026 04:16:43 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 13:16:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/6] x86: extend update_intpte() to support atomic get-and-update To: Kevin Lampis Cc: andrew.cooper3@citrix.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-3-kevin.lampis@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: <20261001174749.2275245-3-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791803804-F62AB2A1-4186720D/10/78276251493 X-purgate-type: spam X-purgate-size: 981 On 01.10.2026 19:47, Kevin Lampis wrote: > @@ -95,17 +102,26 @@ 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) If I'm not mistaken, nothing changes here except for the placement of the backslashes. Can such unnecessary churn please be avoided? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:19:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:19:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446150.1662206 (Exim 4.92) (envelope-from ) id 1xGE4L-0007lJ-5z; Mon, 12 Oct 2026 11:19:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446150.1662206; Mon, 12 Oct 2026 11:19: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 1xGE4L-0007lC-3C; Mon, 12 Oct 2026 11:19:49 +0000 Received: by outflank-mailman (input) for mailman id 1446150; Mon, 12 Oct 2026 11:19:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGE4J-0007l6-GZ for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:19:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGE4I-009D5F-HY for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:19:46 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accc252-8faa-0a2a0a5109dd-0a2a4509e0e6-2 for ; Mon, 12 Oct 2026 13:19:46 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accc252-be1a-0a2a45090019-d155802ecc5c-3 for ; Mon, 12 Oct 2026 13:19:46 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a168355946so14807445e9.0 for ; Mon, 12 Oct 2026 04:19: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-4a18bf135fasm248107395e9.5.2026.10.12.04.19.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 04:19: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=1791803986; x=1792408786; 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=AeUNAMg5f0KKkFa4a1Jx6LJNV9TtHqGJpEU8RCxMHdo=; b=RXO2ddQOJdgwSEeQXtU4msDWOFFsvrZrVGZDJhMKwjPhBkvxUQuhbAlaMP0tRsM0uD 4Vniqa/8mNLNNpX4O1CmowEYvUqD46H8xpZ4EXlhoT8lftOu3/qSLfOEvZ+CLgLcj/7U tGu0KbFTiSAA5qX2w6CUl0kwv1R0Z2UDPJkWQPeXzH7w1XwfTwDfwptJ6677szBRtoUO og2qjheztfLPW0zEoCg/LPPBJhHvOT1xc9ey6HcXYfdQVhM1DsRlrW7gJa+U3/avKDVQ FMNvO194Trg5qac/63Q+qMZ8HnZsUDZOz0yoC/A7SoI15KNl5HHMLNio3mNbHFTZH9yI y9qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791803986; x=1792408786; 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=AeUNAMg5f0KKkFa4a1Jx6LJNV9TtHqGJpEU8RCxMHdo=; b=Z5YhnGxQoicP89sPXHsg4KF6z5fqosvAtrQIipBT4FzF7iM+PpTSH1/zhLMQr45tyF 4g0iXtzEDq9YcdPPtnnrtcvoGsOtj/hA5UOu6c6XxY70mkPPtrf74nDGREaRhN13ftUe zMosEvwvj6HpAZikuRFMKnxIYCjIVZiHw6fszmA5c+0teuIdKmNgjYj2tL1ivQiGJFcW HKbJCYRA4hMj7Cik7xjBdbzS4H4gOBQ49/kfl7cl672v+iuI0e3OAlEe7cSp95D8E+ek /2NVIpMhW/0nenTvs06YI5Mv31LrvyQz3gj3fp9/cPuEXolMzym916l7denE0mGeHqj0 aJzA== X-Forwarded-Encrypted: i=1; AKwUvByQZjCk0k709KjXazl2SAHUAQeO0NXrBwAqxWFgHBxoGnC2+F8p0Jcl8bOpJPjSKuWGf9t4quMJtwg=@lists.xenproject.org X-Gm-Message-State: AFq9FYLDlL+xtSF5UrteggV2lPg8R8oyqoUMluwVP0bSVQOwMReVT24A 5BooLCfGcfElsxTsSCE++eZtYwCjGMFtXrTXduHnLUWDY76KKuV4QSDB2mYNiuByBA== X-Gm-Gg: AYBFou3XkI1gWC0Bgfs1V8yXMoHE6/6fYK5EilA1+V+QZASOZRQXavz/b16ovmmpAVx IgcQYwAidIdSZL1HBt31l+vKyVbgzpF9fIVY0/ogg+UKuk66111ckcubJO6emmPM3pZ0Kx9TxvC HXZHPeeKZtJO0QBlRQTBPDE6MDprNnY8ndMJthU99K6n3ZdS9tub5e2IownNmYnGut33l5eWFV+ Tkstavd5dLh7gSqlmuWeBJ6xMaESy2hDOZQutXKmJRExjo5nBaVpHbBVGJY2tesIxOZG4D5XzMn DJE8EaDeaT7tcBNh9gxh9VY1lJJW4pI36+Ld+qBuD44qLskRs5XiDYVHBp53TtdmLJgExNEZgUo zmAO4pA/JDC4xSeKkv+Puq6ZUqQIjI2V2KRQcEq/vEh70GJWw0T+9Uwc3r6hwMwxh6FyQL6gutW pqvAXEhNyGhFq1r0/lC+GfFmRs3xBOrbrNlFOFrD0qmmqs8aA1gjLZc0T6Xr5DHMFmzDSlKLNgB bVIQTl9vUu0qS1e0x5jbjjyyHZ0HzK+4Z5GrKxcN37sxN+NAUintY1AvzbV7Q== X-Received: by 2002:a05:600c:a112:b0:4a1:9663:7633 with SMTP id 5b1f17b1804b1-4a1966379f7mr87856115e9.11.1791803985787; Mon, 12 Oct 2026 04:19:45 -0700 (PDT) Message-ID: <7a517bf8-f6bd-4f59-aad0-89425ad65f9e@suse.com> Date: Mon, 12 Oct 2026 13:19:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/6] x86: extend mod_l*_entry() to optionally return the old PTE value To: Andrew Cooper Cc: teddy.astie@vates.tech, Kevin Lampis , xen-devel@lists.xenproject.org References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-4-kevin.lampis@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-bad1c0/1791803986-BDCC7034-57EED32D/10/78276251493 X-purgate-type: spam X-purgate-size: 3697 On 09.10.2026 18:25, Andrew Cooper wrote: > On 01/10/2026 6:47 pm, Kevin Lampis wrote: >> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c >> index 1ddb8b71469a..535a62139cad 100644 >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -2154,7 +2154,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; >> @@ -2215,7 +2216,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); >> + if ( ol1e_out ) >> + *ol1e_out = UPDATE_ENTRY_SWAP(l1, pl1e, ol1e, nl1e, gl1mfn, >> + pt_vcpu, update_flags); >> + else >> + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); >> + > > This is a reoccurring pattern.   Also, from the subsequent patch, this > is the caller's reoccuring pattern: > >> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index >> 535a62139cad..a2d05d6c7113 100644 --- a/xen/arch/x86/mm.c +++ >> b/xen/arch/x86/mm.c @@ -4111,6 +4111,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; @@ -4172,10 +4173,27 @@ long do_mmu_update( update_flags = >> PTE_UPDATE_PRESERVE_AD; else if ( cmd == MMU_PT_UPDATE_NO_TRANSLATE ) >> update_flags = PTE_UPDATE_NO_TRANSLATE; + else if ( cmd == >> MMU_PT_UPDATE_SWAP ) + update_flags = PTE_UPDATE_SWAP; switch ( >> page->u.inuse.type_info & PGT_type_mask ) { case PGT_l1_page_table: + >> if ( cmd == MMU_PT_UPDATE_SWAP ) + { + l1_pgentry_t ol1e; + 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; > > > Both are rather intractable as far as logic goes.   We've got > MMU_PT_UPDATE_SWAP setting flags=PTE_UPDATE_SWAP which both gets passed > in flags and expressed through the NULL-ness of of the ol?e_out pointer, > which then choses UPDATE_ENTRY() or UPDATE_ENTRY_SWAP(). > > The only thing UPDATE_ENTRY_SWAP() is doing is wrapping the return > intpte_t into a typesafe variant.  It doesn't play with PTE_UPDATE_SWAP, > so the name is misleading.  It's unfortunate that we can't wrap > UPDATE_ENTRY(), but I think we'll just have to live with that. > > I think the logic in mod_l?_entry() wants to be along these lines: > >     intpte_t old = UPDATE_ENTRY(...); >     if ( ol1e_out ) >         *ol1e_out = l1e_from_intpte(old); This would then require that all callers, ... > and the logic in do_mmu_update() wants to be along these lines: > >     { >         l1_pgentry_t ol1e; > >         rc = mod_l1_entry(..., &ol1e); ... e.g. the one here, initialize the local variable to 0. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:23:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:23:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446156.1662214 (Exim 4.92) (envelope-from ) id 1xGE7t-00011P-Ih; Mon, 12 Oct 2026 11:23:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446156.1662214; Mon, 12 Oct 2026 11:23: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 1xGE7t-00011I-G3; Mon, 12 Oct 2026 11:23:29 +0000 Received: by outflank-mailman (input) for mailman id 1446156; Mon, 12 Oct 2026 11:23:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGE7r-00011C-LG for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:23:27 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGE7r-00000001iMy-2W0s for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:23:27 +0000 Received: from mail-lj1-f173.google.com ([209.85.208.173]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGE7q-00000009sli-3eA4 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:23:27 +0000 Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-3a772ec8389so14404551fa.3 for ; Mon, 12 Oct 2026 04:23: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" 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=k77zGODMT1RCx86FZ0zs6hr4kE+0C9Sj9o8o6DfPm6A=; b=tLszVp6LYT2b8fK32kfmrEcCGU XAsGAvSM6dwLPx3ni4RQ9PBXfq3rLDIZoLzogUjUNMdre9yJ3xY1xB7GOFmL/2T7e5KQnni6O+H3w vfbUEODDbKkfMKV+LB0Qws/hm52AyAQC437GZgMXurAhmNdNcGuW0JhtG49QiPh5t0c0=; X-Gm-Message-State: AFq9FYK0jdy8fKs7oaC9LmgMe1LoDVH0TuLI/48zdOutx7/C+oYZvqDQ UHb+kzQv+n3v/Xt2MnVIf+ABxd1AwKV4aGvINDdoWT7qRI9fyfvmr7Mgd9VP0FlDbY4MrcyrNyn Un9FQyNS/FI4xQIPgwfDaNn8q9Xqmw5Y= X-Received: by 2002:a2e:be91:0:b0:3a9:707e:ad95 with SMTP id 38308e7fff4ca-3a9c53b454bmr21350931fa.11.1791804206186; Mon, 12 Oct 2026 04:23:26 -0700 (PDT) MIME-Version: 1.0 References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <125982a7-f491-4a10-98e9-d31f9f3b6444@suse.com> In-Reply-To: <125982a7-f491-4a10-98e9-d31f9f3b6444@suse.com> From: George Dunlap Date: Mon, 12 Oct 2026 12:23:14 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9WWYDp24lhIJMQbmZDJR4OqboCZjq0SbsHYP2dFu7ZYB_8PDKxtjnKICk Message-ID: Subject: Re: [PATCH 04/15] x86/setup: special treatment of initrd for PVH Dom0 To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2026 at 9:20=E2=80=AFAM Jan Beulich wro= te: > > Dealing with large initrd-s is problematic in two ways: We needlessly > copy around a large chunk of data, and our calculation of how much > memory to give Dom0 assumes the space taken by the initrd is actually > available at the time of populating Dom0's P2M. > > As a first step, make effort during early boot to try to place the initrd > in a chunk of memory that's a multiple of 1Gb (or, if not available / not > possibly going to fit, in a chunk a multiple of 2Mb in size). This may > (but generally won't) result in more copying, which we simply need to > accept. Record (and use) the extra space allocated in (as) headroom, whic= h > then needs accouting for in pvh_load_kernel(). > > Signed-off-by: Jan Beulich > --- > Not being able to check bm->kind is of course not very nice. The field is > only set quite a bit later, and that setting can - afaict - not be moved > ahead of the call to xsm_multiboot_init(). > > The bumping of mask to L3's in __start_xen() transiently breaks booting o= f > Dom0 with overly much memory assigned to it. That'll be resolved when the > headroom space is properly dealt with (consumed into Dom0, or freed). > Therefore this patch and everything up to the one adding the consuming > code want committing together, or addition of that conditional wants > delaying until that later change. I'm generally opposed to breaking bisection. I'd personally prefer an extra conditional until then, but I'd defer to the other maintainers on that (don't consider that a nack). > --- a/xen/arch/x86/include/asm/setup.h > +++ b/xen/arch/x86/include/asm/setup.h > @@ -68,4 +68,6 @@ extern bool opt_dom0_verbose; > extern bool opt_dom0_cpuid_faulting; > extern bool opt_dom0_msr_relaxed; > > +unsigned long get_dom0_size(unsigned long avail); > + > #endif > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1608,6 +1608,40 @@ void asmlinkage __init noreturn __start_ > struct boot_module *bm =3D &bi->mods[j]; > unsigned long size =3D PAGE_ALIGN(bm->arch.headroom + bm->si= ze); > > + /* > + * For PVH Dom0 try to place the initrd in a full multi-Gb (= or > + * multi-2Mb) chunk, such that assigning the pages directly = can > + * be done while still using superpage mappings. > + */ > + if ( opt_dom0_pvh && j =3D=3D 1 /* bm->kind =3D=3D BOOTMOD_R= AMDISK */ ) What if there's a microcode blob or an XSM policy here instead? > + { > + if ( get_dom0_size(nr_ram_pages()) >=3D PFN_DOWN(GB(2)) = ) > + mask =3D (1UL << L3_PAGETABLE_SHIFT) - 1; > + > + for ( ; mask > PAGE_SIZE; mask >>=3D PAGETABLE_ORDER ) > + { > + if ( !(bm->start & mask) && bm->arch.relocated ) > + break; > + > + size =3D PAGE_ALIGN(bm->size - bm->arch.headroom); > + end =3D e; > + do { > + end =3D consider_modules((s + mask) & ~mask, end= & ~mask, > + (size + mask) & ~mask, bi= ->mods, > + bi->nr_modules + relocate= d, j); > + } while ( (end & mask) && end > s ); > + > + if ( highmem_start && end > highmem_start ) > + break; > + > + size =3D (size + mask) & ~mask; > + bm->start +=3D bm->arch.headroom; > + bm->size -=3D bm->arch.headroom; > + bm->arch.headroom =3D size - PAGE_ALIGN(bm->size); > + goto move_module; > + } Every path through this block either does a 'break' or a 'goto'; so this isn't actually a for loop at all -- the 2MiB fallback can never execute. Did you forget an `if (end) { }` somewhere? As it stands, if the 1GiB pass doesn't work, it looks like we'll jump to move_module with 'end' at 0, and likely fault the copy. Also, looks like consider_modules() takes a uint32_t for size, and we round up to the nearest GiB; so if the dom0 initrd is between 3GiB and 4GiB, won't we pass 0 as a size argument, which will always fit? -George From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:24:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:24:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446161.1662224 (Exim 4.92) (envelope-from ) id 1xGE8z-0001Vt-Uj; Mon, 12 Oct 2026 11:24:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446161.1662224; Mon, 12 Oct 2026 11: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 1xGE8z-0001Vm-RT; Mon, 12 Oct 2026 11:24:37 +0000 Received: by outflank-mailman (input) for mailman id 1446161; Mon, 12 Oct 2026 11:24:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGE8y-0001VT-HZ for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:24:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGE8y-00000001iPh-30qi for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:24:36 +0000 Received: from mail-lj1-f170.google.com ([209.85.208.170]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGE8y-00000009uLw-04d2 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:24:36 +0000 Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-3a87e23860cso20658851fa.0 for ; Mon, 12 Oct 2026 04:24: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" 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=QWZy3W3yptZT0CyQ5v4gXTq83jYQjZai1yKqhMOT2XQ=; b=acRSEp6xYLmnv8d9ROqZdongyQ GYEi4DPgbXnSHWaiqA7diPdJLzaBw100xHfpYGkSGXZczmLHsPVKSQDVRvZ88aUPrQmsrSAUayz93 bpOJ5XQtu34y5ADYSadGgjQcMmIW7MT5UZgorRnj2gzotRBv726NxD0UrV9UQxdk+6ck=; X-Gm-Message-State: AFq9FYI53SzVSD1Jmc2X8Nll6xJIvH8sRVzwZmaWci4mqJPF1lo6tERC EAtzy17v7a9SZ3ADHHh3ITRNmt4cyFPxGb4Au41eZ5he5HZRHIQg6c3fYcf5WihzniR2iHPwsVW xwzDJVYFEo2iwoyXZhmSQpHZZoanVrRI= X-Received: by 2002:a2e:be87:0:b0:3a9:d2c3:5d5d with SMTP id 38308e7fff4ca-3a9d2c363b1mr11396111fa.14.1791804275330; Mon, 12 Oct 2026 04:24:35 -0700 (PDT) MIME-Version: 1.0 References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <059a456c-9f84-40d3-8f88-7c9599abb04d@suse.com> In-Reply-To: <059a456c-9f84-40d3-8f88-7c9599abb04d@suse.com> From: George Dunlap Date: Mon, 12 Oct 2026 12:24:22 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK88zxbAsd5Kktu5L20ITHul8mzziGdwftxi0oPN1g-sfb6ho2zcSbeqStE Message-ID: Subject: Re: [PATCH 03/15] x86/setup: break out E820_RAM accumulation To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2026 at 11:23=E2=80=AFAM Jan Beulich wr= ote: > > On 12.10.2026 12:20, George Dunlap wrote: > > On Mon, Oct 12, 2026 at 9:20=E2=80=AFAM Jan Beulich = wrote: > >> > >> We already have two instances of this, and we're about to gain a third= . > >> > >> Signed-off-by: Jan Beulich > > > > Reviewed-by: George Dunlap > > Thanks, yet to double check - did you really mean to use this more privat= e > email of yours? *Sigh* No, just autocomplete. Please use this one: Reviewed-by: George Dunlap From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:24:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:24:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446162.1662233 (Exim 4.92) (envelope-from ) id 1xGE9A-0001nQ-6a; Mon, 12 Oct 2026 11:24:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446162.1662233; Mon, 12 Oct 2026 11:24: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 1xGE9A-0001nF-2A; Mon, 12 Oct 2026 11:24:48 +0000 Received: by outflank-mailman (input) for mailman id 1446162; Mon, 12 Oct 2026 11:24:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGE99-0001mk-9F for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:24:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGE98-00Fxbk-MQ for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:24:46 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accc37e-bab6-0a2a0a5309dd-0a2a450b909a-4 for ; Mon, 12 Oct 2026 13:24:46 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accc37e-b7e8-0a2a450b0019-d155dd32f17b-3 for ; Mon, 12 Oct 2026 13:24:46 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48c4649b35bso1636745f8f.3 for ; Mon, 12 Oct 2026 04:24: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-48db9ac6a91sm17237676f8f.41.2026.10.12.04.24.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 04:24: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=1791804286; x=1792409086; 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=trovYTQ1qQeJdTRvV9e/YhxXnvEDm8E7HM6+VcmASq8=; b=TxT7pU8ozphOa8chxH2NvBvkHXHLfw1qy7rsme0soJ/aWhwIPPdqgc3ovX3mIm66Zc 6EvIOCnknVl3kW5PqQjkz3JQVoUXJMU7nB6tmgRXprIuii81+cJ/dErfznNa7/mHp2FM 07vK96IhGPTXM+/bEgdPN7RSPHUURobq/1NoUJWFQkskqSbz9lX0P+dXRMnBoePP492k vBaYSpddQ1jNU951YteqMb2QGQUMu0WCJi0iga8A6SK+iBO2jDdkfb0pMC9NE+YqAW1J 7XMWkth2sU94bGFc+M/X4X0jwMZQ0jt3hrYm2dUchyOLExrF7Udx6hL9lS7fbmYoMZ+q TsvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791804286; x=1792409086; 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=trovYTQ1qQeJdTRvV9e/YhxXnvEDm8E7HM6+VcmASq8=; b=CEkKiKcrF6NA0nrAmQMOVaK1qVuMiThoJoWEoT1afhMrhW9MMq6TUOT3dEPkFX4c2Q DQvGB+vDM42/39I1yKYqpMYTjsFx25JHxVoRw720jIUlv1YsAFTJJM4tE+TrlD+Qqtgq eqgyvwwgB9lmA8vGujKOL6y/Kvsz0cMZoG6hMBsJ2f6Dvhv2JpMcbPkpvK1lmHbw1Ww7 tNXgen5KQOXoVDFw25aKIMnCI1uSjI1svWD7u9+9z8VtxZvFoI6J9QY7hrCyEws6g3Yw ihzQrq3AdM01jj8OBkGLbFf3zAy32LPA/GCCE6GSu1eEFaxRV2k4LS8RLBq4TSU/Y7Iw aZvg== X-Forwarded-Encrypted: i=1; AKwUvBy7lsEciCuiI3/zRnF+oVvsqvwMRtPCfC6p2J+7ebewYEYxRraSs9C4AxVL0LVW3y+M8THPlq68GDo=@lists.xenproject.org X-Gm-Message-State: AFq9FYJkuDIIaQ6J0kzxFUY1K1A2aeXdSwtZG46mNGjmqYBhk1k2n1wJ azwMeWod8uWIHVNwlsd8TB4e/OVrrGMJ11sIQicIkUvGC+veAQGPY1GyIC7LP70VGg== X-Gm-Gg: AYBFou3sufdStdgxAkVR+TFLeJ1OyH4n7qxKVsyvBuJKxfKg0qIdgq86WZ9YT0L7IBt WeJMuWTYnEE/xlVFPLXqU7JxGi9ioakCEyOVF5k3bi4083iLgvTKjxGQ14+vmiaOrUIo4Nwenje rir4euVJoXMo0KF3J2xgy1xct2zkL/PCBuy8qQuo/A2Eirckazl7yIHIGbTnNVXhfVamLqnDSfK F9N2cEVXcyX1W9VXiQn1/uDfgh8Qrci0bdNfePthAVcARlOczey8MUWr9vg1nFcACsxyv/0iBjp ovw9zxLM/xGtztPDqFJE7sCOb7xm7qKg1HOju5d7CJfMhafh74bYRy/P0BayXa1RyOpPbiKTrNT tu6zlbmciwcXbDP0lphvlNjJDMMfqsUwjmWsbj2HFq2E2gtS5HwLVHb1DimOswybuTFhk4DhIOd r25Pb7bHbr+DSxSItirZ5gtG9YXrBc/NyNRjahoLZ1xxnh7SpEK58wGvFGHwhPJ7yjh8UsP+wgQ DtrHQE87U8h46vxRcQF3JLSi/F/rhGp8N0RStwRfUsyxo9KfDmBOBNmk27zZg== X-Received: by 2002:a05:6000:420b:b0:48c:a08:5858 with SMTP id ffacd0b85a97d-48dbaae6fa0mr15610360f8f.23.1791804285832; Mon, 12 Oct 2026 04:24:45 -0700 (PDT) Message-ID: <1c29b7f1-3cc1-45eb-b3fe-42dec36a9ba6@suse.com> Date: Mon, 12 Oct 2026 13:24:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/6] x86: extend mod_l*_entry() to optionally return the old PTE value To: Kevin Lampis Cc: andrew.cooper3@citrix.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-4-kevin.lampis@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: <20261001174749.2275245-4-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791804286-1B8D19EA-0479DBCD/10/78276251493 X-purgate-type: spam X-purgate-size: 520 On 01.10.2026 19:47, Kevin Lampis wrote: > Calling mod_l*_entry() with a valid ol*e_out pointer will do an atomic > xchg to set the new pte value and return the old pte value through the > ol*e_out pointer. If the ol*e_out pointer is NULL then old behavior is > preserved. Since you say "xchg" - as Andrew has pointed out, it would be nice for it to be a simple XCHG, but for the time being it's still a loop over CMPXCHG, isn't it? As this is somewhat relevant, I think it wants expressing correctly. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:29:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:29:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446176.1662242 (Exim 4.92) (envelope-from ) id 1xGED7-0002mX-Jy; Mon, 12 Oct 2026 11:28:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446176.1662242; Mon, 12 Oct 2026 11:28: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 1xGED7-0002mQ-Gt; Mon, 12 Oct 2026 11:28:53 +0000 Received: by outflank-mailman (input) for mailman id 1446176; Mon, 12 Oct 2026 11:28:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGED6-0002mK-Mu for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:28:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGED6-00FCNG-3c for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:28:52 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accc464-e002-0a2a0a5209dd-0a2a4507ad70-20 for ; Mon, 12 Oct 2026 13:28:48 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accc470-b4ea-0a2a45070019-d155dd36c0c7-3 for ; Mon, 12 Oct 2026 13:28:48 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48b042c0759so1291418f8f.2 for ; Mon, 12 Oct 2026 04:28: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-4a18c198134sm281873115e9.15.2026.10.12.04.28.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 04: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=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=1791804528; x=1792409328; 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=DvG4uFbxyMBQZHqSDuK9l64EmZUsssHbs9zC8VGLI9o=; b=Sg2S9mWtKV7mdrwmYHiBJPigXP3vCMYHgg3oIzyrnDfmS7KP9RpQWRrom3nih6JOrc s+hNKLAiKPkQq5HVlqjMTingAl1hqvBcZ44bEIcgvai6CwZBh79WDE9lqT/rjEiylC8l exxiOYFQqLybJzSlN1zDw+LvuWJZKU3ayjdOEfBXFdGPaBaQaULjhrr5AE5R6IZdtRbg 3nNlU2mzQPoegXOEyO7++QTRfUTK3NMypui4RuRXofRguvUoZh+Fz5+TIOzva3ySRzKv +5yx5NFMkFeBzuhlaO5N7lGUefPqIto8rlnL44woqcBcZg9XYrgtmVcGJcfdTlaYokIE oDFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791804528; x=1792409328; 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=DvG4uFbxyMBQZHqSDuK9l64EmZUsssHbs9zC8VGLI9o=; b=lydChGFfT1eSy/X8xixqzHdiN/Nxu2JR35849CD7ZDMPGWnRqm/oZQ2oU14dGrhJaL GhBI4WomD2kJTLztDyb75SxEIcb+AmiUTUEHwJovMWV+KrostZFBjKFqNVS/f17RZM/v c4nDYNTJdCDUA0QfT1sqzr4jbrMWNXb5+S8KAp8GPg1gYue9LPGxNqB6Hp9JzbT3YWBg c5ktJqJnGRV8qibw//1gbfIWbIUKvq4lo5ZebPvR1BSiUpsONln6t0qhDc1rRPK3ld/e D3THv+i5XZY0FvMO12z09qeyWCsUNrEHwl+TqyhmeQVHeR7LhuchVm8AlE62N5jh+Pt2 TTVw== X-Forwarded-Encrypted: i=1; AKwUvBxExlbav71ukyz8hezUEPj3p5tsgrW0KqBg9U0CbQE4vT5rWLd5FtOws7OXszwDiI5zmv6YOSkhhBo=@lists.xenproject.org X-Gm-Message-State: AFq9FYIX08dhjMhu+OEr7cuSeunF71CRL6yNx1rQ+nHtDI3lLe23l0L+ r5XpANV5UJfgTtmNdeI9mjLa7D70nANZZ325I++bT/ku7IQQX74A2GjBmYI2eVJZS4sASCOw7tv Obxl7Qw== X-Gm-Gg: AYBFou2pTlNnbrF6sfZ8nbuEmppbNLf5BrEw/BUjhq/kOQt6kuNZW4X6Kv6K96jOnvy N3SH9hZ/lxYSL88Ui26SyfTf6fG35kBc9wMgCMbuxaW2pNLxxvpgwv2Z9MShQUMuW/QEPxPk6PN bDoAPfQWKFpY+RY93s9+loIozuIP7YWWqCgQYlw2B9NgFyNxbpraOMOr+WNDBkMXHKOxBWL7fYg GL+juY5nec+ycM03xazRvLApDMsjdbsZTa8R/touvV5yBA2odx90glT5qJ5GQfsXAdkTOvkciCd Co+7xY7KbepScXG0GTBpVHg99uMCIatg+xBd2SA+PQPXdobSb1Q6WTVidJMd07gCkPkNM8fuv5k gAzHbc8UAa7hOxh5go18Vh11NZAyj30tLJlCLSUmJLi+1oL62vzdRAKUTSssFf/bIUHsIS+yq5q TwS4nFGTRJF0W44kvbjd+OfV8BYXch+tOSfr/c5/zrkE0LA3vyzfw8L7jRtfZWwN1TjzzezXGQP jJ2v334ySiLH2uZjMfUg9v2CbpKVlyRbCX1HwzJ2OyRFLnGEXNUqTuEIkLrEg== X-Received: by 2002:a05:600c:3b87:b0:4a0:1b15:8852 with SMTP id 5b1f17b1804b1-4a18e4a977fmr219566305e9.16.1791804527667; Mon, 12 Oct 2026 04:28:47 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 13:28:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/6] x86: extend do_mmu_update() to support returning the old PTE value To: Kevin Lampis Cc: andrew.cooper3@citrix.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261001174749.2275245-1-kevin.lampis@citrix.com> <20261001174749.2275245-5-kevin.lampis@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: <20261001174749.2275245-5-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791804528-A5AC0AE4-C630DB0C/10/78276251493 X-purgate-type: spam X-purgate-size: 749 On 01.10.2026 19:47, Kevin Lampis wrote: > --- 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 /* Update and return the old value. */ Imo "atomically" wants adding here, or else the operation isn't going to be of much value to callers (due to the lack of guarantee of atomicity). Also, spotting only now: Is there a reason the entire series wasn't Cc-ed to Roger? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:38:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:38:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446184.1662251 (Exim 4.92) (envelope-from ) id 1xGEMO-0004dE-Dh; Mon, 12 Oct 2026 11:38:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446184.1662251; Mon, 12 Oct 2026 11:38: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 1xGEMO-0004d7-AY; Mon, 12 Oct 2026 11:38:28 +0000 Received: by outflank-mailman (input) for mailman id 1446184; Mon, 12 Oct 2026 11:38:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGEMN-0004d1-5l for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:38:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGEML-005JPW-QW for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:38:25 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accc6a8-bab6-0a2a0a5309dd-0a2a450689c8-18 for ; Mon, 12 Oct 2026 13:38:25 +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 6accc6b1-195a-0a2a45060019-b9ff1c22834f-3 for ; Mon, 12 Oct 2026 13:38: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a12fe8173a00080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 11:38:21 +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 DE4C1829C7; Mon, 12 Oct 2026 13:38: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: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=E9zvfalTtocdmAjo75hbNWert3671awRKZGIvSICSpE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=btSvE9F/Rjfv8cfbBkJXFZEJDnN49aYPBnWrxMYLUnLiySUEJM4v3Q40INOXbvxIfsRmLEPSV CnsvT7jekND3iGyCTlinIGFc7Y2RlCKrSea6YZvDND3piuNg91xSAtI1MVKnjqzRwoH88RIQDxx 9wagjg44G+ThSbZ5PTohs7HhESjVocFGMcQlONNdYVOI/JN5QB6Tsail+sJ0SECk1sysjMUg8wL RUBXt01nfZaPeLem+igk7cUxe4O6AYp18f8EHD6TbxE+1uC06Ub842Q+Ymq7djLHicH+R0fbmTV YMUunGcj/y3eocjZtsTVTINSYbrFuXgwL7fBPF51BU3Q== X-Zone-Loop: e6d1793f97f050213a5a50a9e6bb93970d8088774053 x-campaign-type: default x-transaction-id: b900d876-348c-493c-9859-476cc40a7ac8 x-swg-uid: 01-d90a14ac-3275-499f-bfde-d2fe8069a942 X-Mailer: Sweego Message-ID: <1791805101.8631fc262581453bbf619ec5b2062170.1a12fe8173a00080d7@vates.tech> x-swg-bid: 1791805101.8631fc262581453bbf619ec5b2062170.1a12fe8173a00080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 12 Oct 2026 13:38:20 +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 v6 2/5] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE References: <1790597845.8631fc262581453bbf619ec5b2062170.1a0e7f2cff3000b504@vates.tech> <1790598009.8631fc262581453bbf619ec5b2062170.1a0e7f553fe000b504@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1790598009.8631fc262581453bbf619ec5b2062170.1a0e7f553fe000b504@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.e9.460c04e3df4212e.1a12fe81499.104641da1cee49dd=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791805101215 X-purgate-ID: tlsNG-16d1c6/1791805105-F70C777B-A14FDCBB/0/0 X-purgate-type: clean X-purgate-size: 2562 ---=Part.e9.460c04e3df4212e.1a12fe81499.104641da1cee49dd=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2026 at 02:19:58PM +0200, 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 Xe= n > 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 createdomai= n > 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 versi= on > becomes v3 if available, else v2, else fails=2E An explicitly request= ed > 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 i= s > dropped since setdefault() always resolves it first=2E >=20 > LIBXL_GIC_VERSION_DEFAULT keeps its name and value: xl=2Ecfg still accep= ts > "default" as the C keyword, and setdefault() resolves it to > a concrete v2/v3 before anything else can observe it=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 > Acked-by: Michal Orzel > --- > Changes in v6: > - Drop the xl=2Ecfg(5) mention of XEN_SYSCTL_physinfo > - Brace every branch of the has_v3/has_v2 if/else, not just the else > - Keep LIBXL_GIC_VERSION_DEFAULT, to not break gic_version=3D"default" > - Move has_v3/has_v2 declarations to the top > - Added Acked-by Acked-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.e9.460c04e3df4212e.1a12fe81499.104641da1cee49dd=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:51:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:51:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446195.1662261 (Exim 4.92) (envelope-from ) id 1xGEZ0-0007hM-GN; Mon, 12 Oct 2026 11:51:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446195.1662261; Mon, 12 Oct 2026 11:51: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 1xGEZ0-0007hF-CM; Mon, 12 Oct 2026 11:51:30 +0000 Received: by outflank-mailman (input) for mailman id 1446195; Mon, 12 Oct 2026 11:51:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGEYz-0007h9-9c for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:51:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGEYy-005Lve-JB for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:51:28 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accc9bf-e002-0a2a0a5209dd-0a2a4502e560-8 for ; Mon, 12 Oct 2026 13:51:28 +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 6accc9c0-6ca4-0a2a45020019-d155802df040-3 for ; Mon, 12 Oct 2026 13:51:28 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a0286c981dso15134635e9.2 for ; Mon, 12 Oct 2026 04:51: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-4a18bf15691sm277547805e9.6.2026.10.12.04.51.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 04:51: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=1791805888; x=1792410688; 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=irOwJY1JOjLr8/BHy410NgY+hsN7f/fx9vptjCrEGr0=; b=MqsfKdhPsBReH1u1kENLkh4v2VvkqxlGiWP8amJvEfrJy8NSSE0K7wW7UK2VmIMH5k 23CHFj9jwuzx94TkPl6ChFp4iC+F8GdjiaNfoTpy2QwuRpExVadc/pR+2IyrAdcttImr eJB0JrJvpjLa3iX/+yImH3rXSDHwY36Rqg/Sn5rj4kqyfuuBPeep/qt8TgekfL4LX2ON iwJoiYzZ5x+TLBldSD7q4JlOBDG7iSQwa4+nqMBzz0eExRWtUxr8D91Fpgj6cu6TuVvU 2ZFnqMUvAr2vT4fG9nyWQH9c7KqX9xAMrktJkaTOLQ4MLDjgoRUzs3Bq5vOiKWYFzcJF FuAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791805888; x=1792410688; 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=irOwJY1JOjLr8/BHy410NgY+hsN7f/fx9vptjCrEGr0=; b=Ap1T4MdyCV4AhvbBF5ADq3RyPoAMchV1celZ8jXlqgaTCWl7q9hkNhs1rUatrHtLs8 SV8p3mslOR5elSpaTBBiL6lX6XmpNHuzTlWcu9QstowCsrdTTHFLdqLZFgobPLdv8duj LIftvp23d2Gxt/W1bj0DJIrxrhUX/V7LbxsdG+fGNfdR2ay6Pcf4F6B9fdBwSlWtKzAq b/valAQl8qq9E9AXdpG3ZfnmL4urKCvDVI44K0w/1BxdP81Fh9qpsm+TE2i4AMD8Pyei 5lr6/42RKOTseDnaEFwcgmW6JEIkFxuGD1WwhVSy12h5XQgKYaOByLNcELPAwh4biEaQ u1iQ== X-Gm-Message-State: AFq9FYI9C5aVzm46gVci2TrZ+qmm2jGpYd/QHK8gtL2L5SmyZhNQjexJ 2abjHcK/xT/F3LTye6xcqLE1UmL9SUduGwqoOVAQXUINadh1/gzR59IlMx8rGdOevQ== X-Gm-Gg: AYBFou3+SFZZEXeoeuLtTEaO0I2rxeBtTXk5dpQ05UeRtUbtD1PUacyulCGRJwdvROH oJYnFONAA1OKImRRWHvcIIueEmRGaKd2BldOMt9DWB+hPuu2wDpDq9Sx+7TBRsxWrTbuV/ZxU3e fS1BcootXsffWRNMHuuA9cqFQ3eAiYNVG7idYfCPhM1LdQ8CZSNI7nfD76nKbboWynlcygH9WJg m+0Fs9poFBDrhBlg6RC7XQcC1UrBAef3sLb9razvf4ScM02KXSyUiEPmrC3WQUGx9D9Aa3eBLnx cElFS/CfcK339PvwiSTZwkXNKtEAa1JnNgM5rNxsXYBVYZspA95LRKqpQnncJBbq7KZBF251nBf oyC5keB6mmF3rP1+povr29GMXPK47UPor1SMt7ijwWIzsGA/e3weNedfi6WhVnbZQSkp2/9RVFL 1qQ9ZSk8sJBWccufzFxabCJ4874WHKbWBGJBne/4W/Xkq6tBT4Pcc0iub5Bgk2hfLxWP9mBywX0 /WRP3mMMwykKotG0lLy6cPgiKru+kQKUgkQ7oCRjUZocacpJC9ettxbKiVEbus= X-Received: by 2002:a05:600c:a016:b0:4a1:a44d:1d5 with SMTP id 5b1f17b1804b1-4a1a44d0221mr15259925e9.9.1791805887685; Mon, 12 Oct 2026 04:51:27 -0700 (PDT) Message-ID: <90fbdbb4-be0c-4916-926e-0327a73b082d@suse.com> Date: Mon, 12 Oct 2026 13:51:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/15] x86/setup: special treatment of initrd for PVH Dom0 To: George Dunlap Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <125982a7-f491-4a10-98e9-d31f9f3b6444@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/1791805888-321D72AC-914782B5/10/78276251493 X-purgate-type: spam X-purgate-size: 5025 On 12.10.2026 13:23, George Dunlap wrote: > On Mon, Oct 12, 2026 at 9:20 AM Jan Beulich wrote: >> >> Dealing with large initrd-s is problematic in two ways: We needlessly >> copy around a large chunk of data, and our calculation of how much >> memory to give Dom0 assumes the space taken by the initrd is actually >> available at the time of populating Dom0's P2M. >> >> As a first step, make effort during early boot to try to place the initrd >> in a chunk of memory that's a multiple of 1Gb (or, if not available / not >> possibly going to fit, in a chunk a multiple of 2Mb in size). This may >> (but generally won't) result in more copying, which we simply need to >> accept. Record (and use) the extra space allocated in (as) headroom, which >> then needs accouting for in pvh_load_kernel(). >> >> Signed-off-by: Jan Beulich >> --- >> Not being able to check bm->kind is of course not very nice. The field is >> only set quite a bit later, and that setting can - afaict - not be moved >> ahead of the call to xsm_multiboot_init(). >> >> The bumping of mask to L3's in __start_xen() transiently breaks booting of >> Dom0 with overly much memory assigned to it. That'll be resolved when the >> headroom space is properly dealt with (consumed into Dom0, or freed). >> Therefore this patch and everything up to the one adding the consuming >> code want committing together, or addition of that conditional wants >> delaying until that later change. > > I'm generally opposed to breaking bisection. I'd personally prefer an > extra conditional until then, but I'd defer to the other maintainers > on that (don't consider that a nack). Noted. If no-one else voices a different opinion, I'll wrap that piece of code in "#if 0". >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -1608,6 +1608,40 @@ void asmlinkage __init noreturn __start_ >> struct boot_module *bm = &bi->mods[j]; >> unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size); >> >> + /* >> + * For PVH Dom0 try to place the initrd in a full multi-Gb (or >> + * multi-2Mb) chunk, such that assigning the pages directly can >> + * be done while still using superpage mappings. >> + */ >> + if ( opt_dom0_pvh && j == 1 /* bm->kind == BOOTMOD_RAMDISK */ ) > > What if there's a microcode blob or an XSM policy here instead? Especially for the XSM policy - very good question (hence also the respective post-commit-message remark). The ucode blob we can tell, if necessary, but aiui the XSM policy we can't. I have absolutely no idea how to deal with this, and it's only because of this that I left things in this shape. >> + { >> + if ( get_dom0_size(nr_ram_pages()) >= PFN_DOWN(GB(2)) ) >> + mask = (1UL << L3_PAGETABLE_SHIFT) - 1; >> + >> + for ( ; mask > PAGE_SIZE; mask >>= PAGETABLE_ORDER ) >> + { >> + if ( !(bm->start & mask) && bm->arch.relocated ) >> + break; >> + >> + size = PAGE_ALIGN(bm->size - bm->arch.headroom); >> + end = e; >> + do { >> + end = consider_modules((s + mask) & ~mask, end & ~mask, >> + (size + mask) & ~mask, bi->mods, >> + bi->nr_modules + relocated, j); >> + } while ( (end & mask) && end > s ); >> + >> + if ( highmem_start && end > highmem_start ) >> + break; >> + >> + size = (size + mask) & ~mask; >> + bm->start += bm->arch.headroom; >> + bm->size -= bm->arch.headroom; >> + bm->arch.headroom = size - PAGE_ALIGN(bm->size); >> + goto move_module; >> + } > > Every path through this block either does a 'break' or a 'goto'; so > this isn't actually a for loop at all -- the 2MiB fallback can never > execute. > > Did you forget an `if (end) { }` somewhere? "Forget" as in "wrongly purge when purging other debugging code", as I had temporary logic there to actually also exercise the falling back to 2M and 4k. So yes, if ( end <= s ) continue; is supposed to live right after the inner loop. > Also, looks like consider_modules() takes a uint32_t for size, and we > round up to the nearest GiB; so if the dom0 initrd is between 3GiB and > 4GiB, won't we pass 0 as a size argument, which will always fit? Hmm, ugly. Since imo at some point we will want to lift the 4G restriction on initrd and kernel anyway, I think I'll slip in a prereq patch widening the function's parameter. Thank you very much for spotting both of these flaws. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 11:59:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 11:59:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446203.1662269 (Exim 4.92) (envelope-from ) id 1xGEh7-0008T3-BQ; Mon, 12 Oct 2026 11:59:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446203.1662269; Mon, 12 Oct 2026 11:59: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 1xGEh7-0008Sw-7y; Mon, 12 Oct 2026 11:59:53 +0000 Received: by outflank-mailman (input) for mailman id 1446203; Mon, 12 Oct 2026 11:59:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGEh5-0008Sq-9m for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 11:59:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGEh4-00FIOR-MX for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:59:50 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acccb99-8faa-0a2a0a5109dd-0a2a4505e4fa-46 for ; Mon, 12 Oct 2026 13:59:50 +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 6acccbb6-4cb1-0a2a45050019-d155802dac70-3 for ; Mon, 12 Oct 2026 13:59:50 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a01933b584so15705745e9.0 for ; Mon, 12 Oct 2026 04:59: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-4a19c8244edsm115716965e9.2.2026.10.12.04.59.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 04: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=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=1791806390; x=1792411190; 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=fmmpCIyDBuwvHjkLzk3Y9dfyUmxSxY9kcRGuz5iGdHE=; b=CzjAPUdx1u6yTXuWqPJa7UcGFEekMbN9LsRun2HujVz8d6iHaEgXrIWWDq7JcfzMkg FTh/5I+g/sf3Ef4qV4cvocS4VdQ7s9qEobpOZVRyA8a2/S56Mv8x0SCl9fseutdigVCG GdQAh9hHMLiDrUB5vpq75ulv8AKeMt+fWDp34qdwrpYAeB8tGPHoj32/hDRe9EhspL8t hBykFt++gjobA07qaMoqzTsbpV7nhwHgw/7/UEg1YxdOE4irdO18hbMek1T0T3PwfOpi 2xXv4WLhs2O8C2qn1UkCF5hU9EUW7PIBYntFjhW0apgmE1SU67dLZ4Hi00MZzOKTOpPU qD4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791806390; x=1792411190; 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=fmmpCIyDBuwvHjkLzk3Y9dfyUmxSxY9kcRGuz5iGdHE=; b=GrAXCpp0W/SWJ0LIC6Uiqtryn9xmPZ5gsaGC/1nAPuh/1+r3LHhoXwsQXq5Le/mkpN Ef1u3d1bnxgrkNYTzgUHDdVDgJQuUoXGmNkC0PdxqpnjaAHSrg9aITHq/RJMXqQMuPOL ZXki0vPK+LtChPaCGLLHGQI7icW9w4XUF27b6WKzA9whdYEV2etT1o8tTBZXZxzsek2v APRjk4DpyC6Q3bcaurPFycUZfxwQ12YyzhjxPywlPXXs8/Xy6D90Ch0sL+aaVI5IBT9x SUSQzI4kpxVXWHfnK1LkkXR/Nvvgkkq8vG+pI10qa1AUGK4402tqjBaAp0SW0PLXw7B4 5rfg== X-Forwarded-Encrypted: i=1; AKwUvBy3oPev3DQ6p8g2oqMwinq+pM/dgw2847OZhb0AlArCg9lRTGClELl90+qRiy0Wi6K6omOFiLFT034=@lists.xenproject.org X-Gm-Message-State: AFq9FYKQXzhWbLT3WLaG0lhymLneD/QIXtq0Zf2ovwJDJJZl6RPXx8ou 2/z0mq77m8GBnhY6KpKb2Pb2XwveL+aVliuX1ZawqCNh8Xr7OnlGWTqATmLMqHzjgg== X-Gm-Gg: AYBFou2qRqSPnIMxpo1ZWf+6PZPnpXG9cu4jH6kuoMPEwSt3pftSkas6q+h6uvzm68T JTrYwnAtjY7VnRlgQHJN0c4qxRoWH/YvfRWAuHnKPXK8K7SIvogzvgPQbs7SD6/0F6fpVJQ3OqV IlfG3R1CjO7UYt8ISBtYM61PpY4us8PtjvX/XXs5k8VyVXbFajwrATwVEuM7HKx7084zzqj+0nA mGkE7v7r6C6pegpRSyxWQHeTexoefI8naAmxKEfEMYy4G+QI/C7LcHpxPzInUvkO5qwPWFD/uUa oqnHyM40zJ4ph4H78KsBshKW4JG3mcoMqy1Z23WWfC9C6Rm7qx10Qd0ca/VChFt0sgRunX794Qu 7W2dBFQL07HGDoWD4/9yzljwXIIlsgDFPTtbQnons5vjRapJomZPv59tGD70VqNLMwsBW3FJPXi tKPTFLQ40srVBzyCCYL9UV72C2gTvB/RKFRwwCo3mJn/TROg6ZalJjkyjWCbrNhaINiCWKE/F+l g8Vk2RTD/moRF9HwYVXDyG9cHBTEI/YFmUQrXPPZhDue2ZmvlACI6fmQOsDdA== X-Received: by 2002:a05:600c:83c7:b0:4a1:698d:3044 with SMTP id 5b1f17b1804b1-4a18e493020mr171577745e9.11.1791806389941; Mon, 12 Oct 2026 04:59:49 -0700 (PDT) Message-ID: <4587c4c9-4744-4e96-bb39-d9209b973628@suse.com> Date: Mon, 12 Oct 2026 13:59:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] drivers/char: add timeout for XHCI console cable To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 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: <20261009133608.364312-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: <20261009133608.364312-1-marmarek@invisiblethingslab.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1791806390-2551A2A1-73D03860/10/78276251493 X-purgate-type: spam X-purgate-size: 1827 On 09.10.2026 15:35, Marek Marczykowski-Górecki wrote: > Do not wait indefinitely for XHCI to configure console connection. If > the cable is not plugged in, timeout after about 1s and continue boot. > If the cable is plugged in later, the console will be activated then > (see final part of dbc_ensure_running()). When timeout occurs, print a > warning message - it will be saved in the console ring buffer, to be > later retrieved from dom0, or possibly later printed when the cable is > finally connected. But, do not print the warning when waiting after > controller reset, as that may have been called from from console > dbc_putc() and printing here would result in (possibly infinite) > recursion. > > Try the timeout to be about 1s, which is way above time needed for > configuring already connected cable. But, since this part runs very > early in the Xen startup, time is not calibrated yet, and functions like > NOW() do not work yet. Use raw TSC and estimate needed time to be at > least 1s on a fast CPU (5GHz), and possibly longer on a slower one. This > is not very accurate method, but fortunately it doesn't need to be. > > This also helps with similar situation on resuming from suspend - if > cable got unplugged in the meantime, system will not hang waiting for > the console anymore. And finally, on some systems, when dom0 is also > allowed to access the USB controller, it may put the device into low > power mode that in some older controllers (for example Kaby Lake) > disables also debug capability. In such a case, adding a timeout allows > the system to resume, then dom0 can wake up the controller and Xen will > resume XHCI console. > > Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:03:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:03:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446209.1662278 (Exim 4.92) (envelope-from ) id 1xGEkh-0001q0-UG; Mon, 12 Oct 2026 12:03:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446209.1662278; Mon, 12 Oct 2026 12:03: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 1xGEkh-0001pt-RV; Mon, 12 Oct 2026 12:03:35 +0000 Received: by outflank-mailman (input) for mailman id 1446209; Mon, 12 Oct 2026 12:03:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGEkg-0001pn-U2 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:03:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGEkf-00BqU1-Ib for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:03:33 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acccc93-2eae-0a2a0a5409dd-0a2a4508c6f2-2 for ; Mon, 12 Oct 2026 14:03:33 +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 6acccc95-f659-0a2a45080019-d155dd2be41f-3 for ; Mon, 12 Oct 2026 14:03:33 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-48b0ef9c76eso1496151f8f.0 for ; Mon, 12 Oct 2026 05:03: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-48db9462ebcsm19780624f8f.8.2026.10.12.05.03.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 05:03: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=1791806613; x=1792411413; 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=g/5uWLhmc5giyZICWRpR/uieQ7PcO2wnmlPt6EKMsCk=; b=WOQbrp+A01aCK9M0yb2QKLsp6+g36cqjoReAgT2ihN0C9AF8z7738Mj7YKvEDLHz6k tposxIXuo61Gn/tFpBi8Eo592Ak7wqkBi8sPvT7zQfqVNZccelkG0jmagH/zoAtSDeqv skdbgMlbgQC/Dj0vZXQZLFALV/HRO2Q/nokCjOgSZHoWpgEvlMo83i1V6CP/mgwgHckW hTy5dLZZlRMn+7b2Pky4yNvbS8L3YvlMd2F0h664cx0w+MTFl9KHaN59LdYtf8Jrll4O Kfo5jNzK2vePfpfkJ7ZzEJAi3CUZk0tZkFP+HM175liS9q3J2abBsky7yr0V8VYgKOqK wcqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791806613; x=1792411413; 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=g/5uWLhmc5giyZICWRpR/uieQ7PcO2wnmlPt6EKMsCk=; b=dZtocQs0AwnPbpXtwGvfIElZiiEox9zFs6p0upRokAAE2nwwWYwNzEi/A2LYbOHqEw D+3cguxHwEjJ/14t1Z7uafhCOfSCBy6Y9X7zg7tVQIK9o0uzDWzLDILCWdtwCSDSOovh msWFucpyc0yDxXeJwWyCktrla19uoz2ddi2jY/aL3Mv0lZePO/20AsykwSgc+WWRfFEc oiIQLyekDa7SAHdAVXfinj1oJfGCIb1roKh9aeCawxOq66zeb0A5B1+6z8QOQv+vKvUX UY6DE/qtI3DCwWBaGCegX8i/gU2x/b65/JCuL4KS48bNSBSjs/wh5bMX4rUok/X4VS5G evmg== X-Forwarded-Encrypted: i=1; AKwUvBxD+qe2XBQVEdh2P+oKDUAFkGtPEvv72Txptup1X1Mkv5MBPueFZ17t6fDkLKxukdDyZ69PSAZ5dqU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKSSH3bW4I3ddtF3UJHOKUhwM29PSVwEBQwUOXQtoQGoJwslF7U yqZRdzNRJq8qdGRThhcVRmgXdIN0vpO+54+bKCkA+M8SGqDvL+grTuO+++Yqy/PDRQ== X-Gm-Gg: AYBFou2Fpn5sNQHQBzIabnlxxx3ms/8bePabfIcLdKNfMsX4BWYCfM+HgCckBAlm7yY h5abGKkipietXwuf2Qzsp2ut90lW74XQwULHbrYDPItnoG3yKkood4VTL5xEzNIqCxLTUbJbcbz 2aUW3/xbEuZ7nWKIlgp+QxcENCzGjX87gYqp3yozv0gvi9vkIUTof9uszQqEtyOXEB7hnzoHxRS QZd12vynVhPmlwm0RlMPNQs7Do+KPwD8HePRZ/FzXF/M9jju9PPrtEK8OFu3K/rIQhNe67CP5xS YqaLoR6+sJwgdMohdLLXkhJeo+92wtsQ3LlLduAaE6pru7YCO8ebQmvZhKj20Q2ckM0vMKdYpd5 bwDFLXMnMbd4In7mAhk53dfFx+xEzruCBtXHcGjYHvQ+rS8Wb2NO+XXRgf6qyZk0fFW8tMn02sp y0adBFPaiO8L2Q3NIQ5vdxr1VGaWexlnr+cgDQhZwZBCM/VNgZuJebymd3OEC7GJiZQBh9PEwrU Rklmg+fxP58WsXdxKyBsDK7H+tuq8L6m9XdVTipUf7wjLajUG0ws90QgYt+/A== X-Received: by 2002:adf:d002:0:b0:48a:f11a:c34a with SMTP id ffacd0b85a97d-48dbaaecf8fmr13540892f8f.52.1791806612700; Mon, 12 Oct 2026 05:03:32 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 14:03:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/svm: Sync nextrip during virtual VMRUN To: chunjie.zhu@citrix.com Cc: jason.andryuk@amd.com, roger@xenproject.org, ross.lagerwall@citrix.com, teddy.astie@vates.tech, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <0835710d-f67d-4678-ba39-4597b9c9c7f7@citrix.com> <20261010040502.96413-1-chunjie.zhu@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: <20261010040502.96413-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1791806613-D654487B-C3ED9869/10/78276251493 X-purgate-type: spam X-purgate-size: 967 On 10.10.2026 06:05, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > NextRIP is consumed on VMRUN as the return address pushed onto the > stack for injected soft exceptions/interrupts. nsvm_vmcb_prepare4vmrun() > builds n2vmcb from the virtual VMCB on every entry to the L2 guest, but > never copied this field, leaving n2vmcb->nextrip stale. Injecting an > event in this state can wedge the L2 vCPU, as the APM does not define > behaviour for a VMRUN with a garbage NextRIP. > > Nested virt is only offered on NRIPS-capable hardware, and NRIPS is > required to be advertised to L1 (see start_nested_svm()), so the L1 > hypervisor is required to keep NextRIP correct. Therefore no > conditional logic is needed here; an unconditional sync suffices. > > Suggested-by: Andrew Cooper > Signed-off-by: Chunjie Zhu Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:18:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:18:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446222.1662294 (Exim 4.92) (envelope-from ) id 1xGEzA-00046T-6H; Mon, 12 Oct 2026 12:18:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446222.1662294; Mon, 12 Oct 2026 12:18: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 1xGEzA-00046M-3X; Mon, 12 Oct 2026 12:18:32 +0000 Received: by outflank-mailman (input) for mailman id 1446222; Mon, 12 Oct 2026 12:18:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGEz8-00045B-N7 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:18:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGEz8-004OBe-3B for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:18:30 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd00b-2eae-0a2a0a5409dd-0a2a450cd424-38 for ; Mon, 12 Oct 2026 14:18:30 +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 6accd015-f479-0a2a450c0019-b9ff1c229db3-3 for ; Mon, 12 Oct 2026 14:18: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1300cbf0e00080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 12:18:24 +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 36CBF81F9C; Mon, 12 Oct 2026 14:18:23 +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=TAp6qJHwb1BuZFbptVZG/MxxPJ4OhDKCO4NoJ6+UgWU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=cDr4oayZCkIuc+WbYupfx7YnivJX2pgpzOoI85rqB0AsY2axcbY73xw87azxMi74MP7hzqO1v 05bXuraevaH5smaaBhRB5e/+2cPWO7a+w3jmkhWNpdPrfZ44wmWvHNUtzXMoBpJmmlysUvnfaKa cliN+MX+SiudoBTH5+bbcwLhpznfSE1GcFMAzQ/ibC75bU+jqqpkrws5Niqym/x8i0BDAqxKnYh zNBGiHVbT17kDy05AP7RbBiN6LMr0Oh/pJ7X9bU2GA1LInqdWcj7X4dITDvAKWwg3pJQp4qRD9f LvgIWgiHBxa2ImfQRdpEhlR3JyxGTPYYDkhrhEKm6AYA== X-Zone-Loop: b7e8b2c9174127f66944e444a5bac031074d55d6331e x-campaign-type: default x-transaction-id: b888df8e-6552-47f9-958e-12b0b573fb19 x-swg-uid: 01-638e2716-74dc-4ce9-84d9-40dda7ecdb67 X-Mailer: Sweego Message-ID: <1791807504.8631fc262581453bbf619ec5b2062170.1a1300cbf0e00080d7@vates.tech> x-swg-bid: 1791807504.8631fc262581453bbf619ec5b2062170.1a1300cbf0e00080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 12 Oct 2026 14:18:22 +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 v6 4/5] xen/arm: report clock_frequency via sysctl physinfo, not createdomain References: <1790597845.8631fc262581453bbf619ec5b2062170.1a0e7f2cff3000b504@vates.tech> <1790598010.8631fc262581453bbf619ec5b2062170.1a0e7f55818000b504@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1790598010.8631fc262581453bbf619ec5b2062170.1a0e7f55818000b504@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.f0.2dbcc85ed79f6079.1a1300cbc9a.931ebf8cee0f999d=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791807503515 X-purgate-ID: tlsNG-d25034/1791807510-028DDA5B-F667147A/0/0 X-purgate-type: clean X-purgate-size: 3637 ---=Part.f0.2dbcc85ed79f6079.1a1300cbc9a.931ebf8cee0f999d=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2026 at 02:20:00PM +0200, Julian Vetter wrote: > 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 >=20 > Expose it instead as a new arm_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 >=20 > 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 f= or > 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 >=20 > 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 > arm_clock_frequency_hz came from the DT property=2E Then libxl only emit= s > 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 >=20 > 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 >=20 > 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 >=20 > 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 >=20 > Signed-off-by: Julian Vetter > Reviewed-by: Michal Orzel > --- > Changes in v6: > - Rename arch_clock_frequency_hz to arm_clock_frequency_hz > - Drop now-redundant "# ARM only" comment on the libxl IDL entry > - Rework libxl__arch_domain_save_config() to a single exit point: fetch > physinfo up front and use "goto out" on every error path > - Move the gic_version IN/OUT -> IN comment update to the GIC_NATIVE > removal patch > - Added Reviewed-by Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.f0.2dbcc85ed79f6079.1a1300cbc9a.931ebf8cee0f999d=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:30:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:30:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446240.1662313 (Exim 4.92) (envelope-from ) id 1xGFAm-0007K7-9w; Mon, 12 Oct 2026 12:30:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446240.1662313; Mon, 12 Oct 2026 12:30: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 1xGFAm-0007K0-5X; Mon, 12 Oct 2026 12:30:32 +0000 Received: by outflank-mailman (input) for mailman id 1446240; Mon, 12 Oct 2026 12:30:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGFAk-0007Ju-P9 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:30:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFAk-00BvJ4-5a for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:30:30 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd2db-bab6-0a2a0a5309dd-0a2a450bcf4a-16 for ; Mon, 12 Oct 2026 14:30:25 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accd2e1-b7e8-0a2a450b0019-d155dd34ac02-3 for ; Mon, 12 Oct 2026 14:30:25 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48b0584ad71so947732f8f.0 for ; Mon, 12 Oct 2026 05:30: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 5b1f17b1804b1-4a18bea0f1csm413366935e9.9.2026.10.12.05.30.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 05:30: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=1791808225; x=1792413025; 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=Bpf0c153JF8o7SHWgCUHN7y0JzR+9eQ2sy7rPFy/4KM=; b=Z11/S9CtesKpOxuWINM6wKg7r8E05cOwy7BnfBiI/6n8TK2AWazxGdeU67UPL7Xb/u 26w9MCgPC7xpVGbbr+rw16qaJr1QORdTRyh500U7WqN7QOAfzZxSI2G6Jf/wqgE6WShX iIL4E3z+n5VRz/DxIezZZAwVx8BMpf5qoMBJYbcOB0Nicqs/8NO/OT6yMR9RpxBe48AH wZnx/IJr7ua2DEkx33TEfhZrewVwFI5PNRV7i7EQs2VvJh9X49kj3YR86UB2QQDGC0mW CXjvizTdDAePlgbKvhS5anEVN4diPU8GinicUC3Pbze+6aYUYqjFmXbR5lXCjY35961z 5x1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791808225; x=1792413025; 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=Bpf0c153JF8o7SHWgCUHN7y0JzR+9eQ2sy7rPFy/4KM=; b=CArxLHUW5RlveR9C4ioVsYJ0tDUow2uzaFxcHwBeVclwapHqrvydBmuCWx19APIIvQ GtADbsmcXg8WdeosvOxi+jvVGx2lnowcgXFVODre7j32A9XHkT5RR7bwWVzBIhYKUysM YIrAnybsZIFeHeInNBsK7+3TSTQL8tZPWOavwgjE310II5s6oAT7N1HFjT29uBhkIpYR ookNj2GaLw6jVMqkTZV0w5m4d9CpPvo++nRdm+ZJtk0DbLRhYDX0w2ZJbh5x73vyfBGA stRV4iJW42SoePtKRdayjPAw01IjHKX+eHuj2vFd4snQrS52LB+hB9SFVvZGr+lTvDXv LgvQ== X-Forwarded-Encrypted: i=1; AKwUvBwuziylslYwF0Gwq3ZDEONTaz6W/opKhCv6Nbaz1k97GfSxAoxnTH8LImy8me7M1pvgX+lvKUesEJs=@lists.xenproject.org X-Gm-Message-State: AFq9FYKG+DApVF6EYnjQdaeb2i5yGDMMaBfnHW2EYiSp4xHayIwVKJcC Xf23z5COTDpAcbrzp7DZpH5FWD38ssfd9eLIpQmHbZMB9G96etMTIb3o+Vi4wmXPvqRRmnfZcmM d8rojjA== X-Gm-Gg: AYBFou0cw08IuFy3ESw/WJBULDkN0GJH0Ff2lP5trVdu5eckiCYcNVpZMlNydsb0vuO 2Vpw7/NCP03KxA9pOs1amJr5IcwXD6ZBdBYtSbvJXRrjeE9wv+XyeBybl3JOpg/PJKMf7YBdNGX e1Eu+vHxFeFyDYQGald9JuiJZsuk1UWG8y25dbGR5TH4a/DWP98GSVhHovMg+MuZkGyP26ylAFf zWweWrL/adeZn3kCoMZ7nMrc93EIREUJzX3/RWAX/RRiXBUTul/oY+O7QBc1aK8nxCKMn0eRR0X U4FV+0bNwUnMQsC+fpUdxFqzuHnjXl15laZGDa3cRQcxsqNOPhqnSZTxoPvMC2mKSU4ipKXZ7e8 SVjuu3p4pnoR3GFgw3QfmSnq5SCF8lkHGPsktP9xfmthO+iYFYy3kqoN3fUG6zBr7zHAT4qvSWj ifGYRCZ4y94mjmbUhCCavkyX2U3cR29bJrPWAdhNAXK3IRMDvfAFCPf5U6t10Cp4KFtblZ+wr4+ 4owU2T+V1vuHWFkpR6zspgCEadiEpRGYC7BhlJf8E8099sQurcjBnM8838R8h8= X-Received: by 2002:a05:600c:6208:b0:4a1:698d:3042 with SMTP id 5b1f17b1804b1-4a18e493143mr162385345e9.6.1791808224905; Mon, 12 Oct 2026 05:30:24 -0700 (PDT) Message-ID: <236fed46-c64f-4bfc-86a5-2147ae34d5d9@suse.com> Date: Mon, 12 Oct 2026 14:30:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ns16550: add "auto" to scan PCI only when the default base has no UART 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> <20261009202447.852414-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: <20261009202447.852414-1-benjamin@edera.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791808225-AB0DD9EA-7B125680/10/78276251493 X-purgate-type: spam X-purgate-size: 2352 On 09.10.2026 22:24, Benjamin Leggett wrote: > On some systems the console UART is at the legacy I/O port, and on > others, such as Amazon EC2 bare metal instances, the only UART is on > PCI. "com1=...,pci" finds the PCI UART, but it prefers any PCI serial > device to the legacy port, so it is not correct on a system that has > both. No option today says "use the legacy port, and scan PCI only if > it has no UART". A deployment that boots one command line on many > kinds of machine needs exactly that. > > Add "auto" as a value in the position. With it, Xen probes > the default base as usual. Only if check_existence() fails there does > it scan PCI, as "pci" does. Without "auto", nothing changes. I've always been considering check_existence() as somewhat fragile (it's not very difficult for it to yield a false positive, especially when HAS_IOPORTS=n), which means that I'm not really convinced it can (reliably) be used for the purpose here. > @@ -1628,6 +1633,11 @@ static bool __init parse_positional(struct ns16550 *uart, char **str) > return true; > conf += 3; > } > + else if ( strncmp(conf, "auto", 4) == 0 ) > + { > + uart->pci_fallback = true; > + conf += 4; > + } > else > #endif > { What about parse_namevalue_pairs()? Once you also adjust that, you'll notice that ... > @@ -1819,7 +1829,26 @@ 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"); > + { > +#ifdef CONFIG_HAS_PCI > + if ( uart->pci_fallback ) > + { > + pci_uart_config(uart, 1 /* skip AMT */, uart - ns16550_com); > + if ( uart->ps_bdf_enable ) ... this isn't a good value to check, as it can also be set from the cmdline. Perhaps checking ->param is an alternative. > + printk("ns16550: com%u: no UART at default base, using %pp\n", > + (unsigned int)(uart - ns16550_com) + 1, Would be nice if we could get away without cast here. While out printk() still doesn't support the t modifier, aiui the z one should do here. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:32:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:32:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446246.1662321 (Exim 4.92) (envelope-from ) id 1xGFCn-0007rV-JT; Mon, 12 Oct 2026 12:32:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446246.1662321; Mon, 12 Oct 2026 12:32: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 1xGFCn-0007rO-Fv; Mon, 12 Oct 2026 12:32:37 +0000 Received: by outflank-mailman (input) for mailman id 1446246; Mon, 12 Oct 2026 12:32:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGFCm-0007rI-BH for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:32:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFCl-009Sqk-O3 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:32:35 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd362-bab6-0a2a0a5309dd-0a2a4509b29a-24 for ; Mon, 12 Oct 2026 14:32:35 +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 6accd363-be1a-0a2a45090019-b9ff1c23b22f-3 for ; Mon, 12 Oct 2026 14:32: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 1a13019aa8f00080d7.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 12:32:30 +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 0220580034; Mon, 12 Oct 2026 14:32:29 +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=v3WAVolUNBdAD/WjrQ5F8a3upMbDiOBdT+IgDDOeFKc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Tr7TnD6bJN4ymtRB6wmlBRMMlxAWKoAS8LZyI6DdYEn2YyCE7KASR3vWIhoap0FDWF0d3bxe4 SUTI1bQ3yr9REHsURd1CIp4UJJFV+jGZrrPli/Sc6jkuVnkhrom0npUbB1SFC8lngPhPvwY0NJU nPbtjgkjbSpT1D0x2goubeZdeLk91jBKCI/43JO0jL0pFHk1qRtu1b1GNKsdiPY2ahTqCSqqx3L d2vjI0x532c+wk2xfH2vwA++4M43Lvnso2rDrrIMAecMT7mVm/Khuvfs5dwlpFyldtPxAExmtGi tq0JhgEybVulAl/3v16r42XgSQfszjXo6ZcughekbAAg== X-Zone-Loop: bccb06bb912f0fbe5f9e8bc020ae44cd6eb73d810284 x-campaign-type: default x-transaction-id: 54062355-7069-4c47-9308-a4f6ad9277c3 x-swg-uid: 01-cb8a983f-a249-4b8e-971d-87fcfc9abf50 X-Mailer: Sweego Message-ID: <1791808350.8631fc262581453bbf619ec5b2062170.1a13019aa8f00080d7@vates.tech> x-swg-bid: 1791808350.8631fc262581453bbf619ec5b2062170.1a13019aa8f00080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 12 Oct 2026 14:32:29 +0200 From: Anthony PERARD To: Jason Andryuk Cc: Leigh Brown , xen-devel@lists.xenproject.org, Andrew Cooper Subject: Re: [PATCH v4 1/2] tools/hotplug/Linux: Add bridge VLAN support References: <20240517140506.8460-1-leigh@solinno.co.uk> <20240517140506.8460-2-leigh@solinno.co.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.f3.2540ef4c741cd6f.1a13019a78b.1def3c6f87db37fc=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791808350091 X-purgate-ID: tlsNG-bad1c0/1791808355-3B8D1034-07637423/0/0 X-purgate-type: clean X-purgate-size: 1629 ---=Part.f3.2540ef4c741cd6f.1a13019a78b.1def3c6f87db37fc=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, May 18, 2024 at 08:03:13AM -0400, Jason Andryuk wrote: > On Fri, May 17, 2024 at 10:05=E2=80=AFAM Leigh Brown wrote: > > > > Update add_to_bridge shell function to read the vlan parameter from > > xenstore and set the bridge VLAN configuration for the VID=2E > > > > Add additional helper functions to parse the vlan specification, > > which consists of one or more of the following: > > > > a) single VLAN (e=2Eg=2E 10)=2E > > b) contiguous range of VLANs (e=2Eg=2E 10-15)=2E > > c) discontiguous range with base, increment and count > > (e=2Eg=2E 100+10x9 which gives VLAN IDs 100, 110, =2E=2E=2E 190)=2E > > > > A single VLAN can be suffixed with "p" to indicate the PVID, or > > "u" to indicate untagged=2E A range of VLANs can be suffixed with > > "u" to indicate untagged=2E A complex example would be: > > > > vlan=3D1p/10-15/20-25u > > > > This capability requires the iproute2 bridge command to be > > installed=2E An error will be generated if the vlan parameter is > > set and the bridge command is not available=2E > > > > Signed-off-by: Leigh Brown >=20 > Reviewed-by: Jason Andryuk Acked-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.f3.2540ef4c741cd6f.1a13019a78b.1def3c6f87db37fc=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:32:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:32:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446248.1662329 (Exim 4.92) (envelope-from ) id 1xGFD7-0008Dp-Ty; Mon, 12 Oct 2026 12:32:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446248.1662329; Mon, 12 Oct 2026 12:32: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 1xGFD7-0008Di-RJ; Mon, 12 Oct 2026 12:32:57 +0000 Received: by outflank-mailman (input) for mailman id 1446248; Mon, 12 Oct 2026 12:32:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGFD7-0008DW-9C for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:32:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFD6-006Bfk-MG for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:32:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd370-8faa-0a2a0a5109dd-0a2a4506c066-32 for ; Mon, 12 Oct 2026 14:32:56 +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 6accd378-195a-0a2a45060019-b9ff1c22a20d-3 for ; Mon, 12 Oct 2026 14:32: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 1a1301a072300080d7.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 12:32:54 +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 0F98A80034; Mon, 12 Oct 2026 14:32: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: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=TRItMS2pSkRZLCpQz88uDSxTxfgiGW/RRK6HOy1TP4w=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=jT0jTtQqcuB9SnW845bpIdORa4LS73+XIF9N8fiuc24tBFFcFw+otQz7xtroYFbbFEz2SEvFJ ksu2quzTZRuCcUp0aphRZasfd76rMG/FO56Lap5aQ5AtlWoTA3TFKcaZakGTFf+nTU226dALNXw l6nt31Vvughss9XfquLwpkAWBB2634X25z8mHqCCK6oomrfTSDOraB0+BwFvXdsqHkI6GdeUP1X YW2rfYsp54HBYGdLaG7JXV3Ekua6T/HUK46/ObxGeQoctdLSCC2+zUoyMI5HyWtnAmjfwqKXjkf 8zhICHsCB7A/744dB+H8D7b8n8vwX9ezuUKDX2yybwrw== X-Zone-Loop: ea6a248fc4df45b76cc64d8f09ac81fe4f22cee01858 x-campaign-type: default x-transaction-id: 9e6f4687-d3de-4409-92a2-990a0fda0cad x-swg-uid: 01-0372ff0a-7f7f-4414-8b46-f644ff8fb406 X-Mailer: Sweego Message-ID: <1791808374.8631fc262581453bbf619ec5b2062170.1a1301a072300080d7@vates.tech> x-swg-bid: 1791808374.8631fc262581453bbf619ec5b2062170.1a1301a072300080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 12 Oct 2026 14:32:53 +0200 From: Anthony PERARD To: Jason Andryuk Cc: Leigh Brown , xen-devel@lists.xenproject.org, Andrew Cooper Subject: Re: [PATCH v4 2/2] tools/examples: Example Linux bridge VLAN config References: <20240517140506.8460-1-leigh@solinno.co.uk> <20240517140506.8460-3-leigh@solinno.co.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.f4.16c921bfbd0a5524.1a1301a057c.ecbb5b2007da3ad3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791808374140 X-purgate-ID: tlsNG-16d1c6/1791808376-F5C0F77B-171F16B7/0/0 X-purgate-type: clean X-purgate-size: 939 ---=Part.f4.16c921bfbd0a5524.1a1301a057c.ecbb5b2007da3ad3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, May 19, 2024 at 10:54:25AM -0400, Jason Andryuk wrote: > On Fri, May 17, 2024 at 10:05=E2=80=AFAM Leigh Brown wrote: > > > > Add a new directory linux-bridge-vlan with example files showing > > how to configure systemd-networkd to support a bridge VLAN > > configuration=2E > > > > Signed-off-by: Leigh Brown >=20 > The systemd network config looks like it matches the the systemd man pag= es, so: > Reviewed-by: Jason Andryuk Acked-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.f4.16c921bfbd0a5524.1a1301a057c.ecbb5b2007da3ad3=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:44:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:44:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446263.1662348 (Exim 4.92) (envelope-from ) id 1xGFOE-00025k-W3; Mon, 12 Oct 2026 12:44:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446263.1662348; Mon, 12 Oct 2026 12: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 1xGFOE-00025d-Rw; Mon, 12 Oct 2026 12:44:26 +0000 Received: by outflank-mailman (input) for mailman id 1446263; Mon, 12 Oct 2026 12:44:25 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGFOD-00025X-IY for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:44:25 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGFOD-00000001jxz-38Z3 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:44:25 +0000 Received: from mail-lf1-f45.google.com ([209.85.167.45]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGFOD-0000000CCIz-0Bpr for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:44:25 +0000 Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-5ba35c0df4fso1448778e87.0 for ; Mon, 12 Oct 2026 05: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" 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=2lakZq7nkwnKjI8o8lIDJC9hlEHtJLlkNZI0jXdhd44=; b=AOa6R6tftEzT5Q0amykelivJM2 iInfVw5BFIn2diuDkzGZxsMCnuhh3l/GjdiHYYhnD4qjLdSG4lS7Xa2uza0v18AZ109/+98sJvc5B FNHLKvpFKgaDg9tG/q9pwfyOVg/wI+lJs+CMZSFg98rBI9XJ+loXXIt1p2lSnbNb+b4A=; X-Gm-Message-State: AFq9FYLzi5JCdDae6NOH8yJhf98kHEfTJ1OFWYiF/u3MJ7HtSbSR+JQI 5f93adTKpA8Sw2RmBU7ZfPw3QqJoQ1+WYNygQTjfRSgbS/0tnD+Owtjcs8pHwPiUPwktX1bpzqd XDABUmR5CVB5ncN5BG/IA6RQCgVgefdw= X-Received: by 2002:a05:651c:a38d:10b0:3a6:65c1:425e with SMTP id 38308e7fff4ca-3a9c53b328fmr13255231fa.24.1791809064333; Mon, 12 Oct 2026 05:44:24 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-6-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Mon, 12 Oct 2026 13:44:11 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_mwRG_3QRIcdMTtObW-fQZ0bjGcOzRC3Cc-30GrriPpWqUV8YninavBjQ Message-ID: Subject: Re: [PATCH v3 05/18] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2026 at 5:32=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:38AM +0100, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > 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 before any page > > tables referencing it are built. vCPU creation is > > where the call must end up; move it there directly. > > I think it's clear from the paragraph above the call must be moved > there, there's likely no need to re-iterate that fact. > > > 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. > > Even then - we will still need to support non-ASI (PV domains) not > using a per-vCPU slot, and hence the call can't be moved as-is just > when per-vCPU support is available? > > > Signed-off-by: Roger Pau Monn=C3=A9 > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, C= laude Code:claude-opus-5-5 > > Signed-off-by: George Dunlap > > --- > > Changes in v3: > > - Rebased onto staging without the GDT/LDT conversions (for the > > HVM-only series): the capture parameters stay, as the PV GDT/LDT > > stash still uses them. > > > > 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 | 3 ++- > > xen/arch/x86/pv/domain.c | 2 +- > > xen/arch/x86/x86_64/mm.c | 2 +- > > 7 files changed, 18 insertions(+), 12 deletions(-) > > > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > > index 85cedc3d03..b670cea52b 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. > > I think the comment here is not very useful - it's not helpful that > the comment here references the previous position of the call. It > only makes sense in the context of this change, but not for someone > looking at the code after this commit has landed. I would terminate > the commit at the ":". > > The code itself looks good to me. Done, thanks. -George From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:47:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:47:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446269.1662356 (Exim 4.92) (envelope-from ) id 1xGFRM-0002fw-B1; Mon, 12 Oct 2026 12:47:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446269.1662356; Mon, 12 Oct 2026 12:47: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 1xGFRM-0002fp-8R; Mon, 12 Oct 2026 12:47:40 +0000 Received: by outflank-mailman (input) for mailman id 1446269; Mon, 12 Oct 2026 12:47:39 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGFRL-0002fj-Ej for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:47:39 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGFRL-00000001k2O-2d2a for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:47:39 +0000 Received: from mail-lf1-f41.google.com ([209.85.167.41]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGFRK-0000000CGox-3uRq for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:47:39 +0000 Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5ba3fba0080so1151261e87.1 for ; Mon, 12 Oct 2026 05: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" 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=DNV2MetkmeF8MvF17VG/nq80dt/aalgBfQjMMMOJ3l8=; b=N5ayCJNj0KBTuf+Y/Vt0+rkkVO mVkntp82osWsIX73tIameskyY+esoQtPxEP9IlsOzd0t2gzKDt7h5voq7dEBE3hubEgyPkG96aU5U kT//c9R1xizhxt8Nem2vqw514dXwKk4CbhNGPdpPJH7Nt0FX5yHMMFxo++Z+/0frpaqY=; X-Gm-Message-State: AFq9FYKm84dvXpbIUkATGuKQ/cu4KAWC4WeI5F/F8f0EIYLLqS7yQC+L YYu2HAyrrwRa2y4toiW5hdpcvMLSeBRu973DfBqe2sPA3i6+isC3aBZ5lYtKvHYwT5T3FGYR0AP WT/CAPbW1nGdPiXtQz0gBxf6ogAKXlcA= X-Received: by 2002:a05:651c:211e:b0:3a8:7db9:3b19 with SMTP id 38308e7fff4ca-3a9c51556edmr21687141fa.9.1791809258156; Mon, 12 Oct 2026 05:47:38 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-7-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Mon, 12 Oct 2026 13:47:25 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8vZTjXjtZASmlUscwzza2zzuyGoE7u4jIcNLXPrVpuz2x8l-TbL0DkOV8 Message-ID: Subject: Re: [PATCH v3 06/18] x86/spec-ctrl: introduce Address Space Isolation command line option To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2026 at 5:52=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:39AM +0100, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > Introduce the `asi=3D` command line option, and the > > opt_vcpu_pt_{hwdom,hvm} knobs plus the per-domain d->arch.vcpu_pt > > setting they control. 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. > > I would possibly avoid using "taint" above, as we have a taint > mechanism and it might create confusion in the context here. Using > ASI doesn't taint the hypervisor. Ack > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-= line.pandoc > > index b2c94ae56d..785e099c0a 100644 > > --- a/docs/misc/xen-command-line.pandoc > > +++ b/docs/misc/xen-command-line.pandoc > > @@ -202,6 +202,32 @@ 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) > > AFAICT the sparse direct map series contained support for ARM also, I > assume this is being dropped from the content pushed (at least in this > round). I think we will possibly duplicate the "asi" command line > option between architectures? Yes, I think that's the plan; there are a number of other options we duplicate. The exact options and what they mean will probably differ somewhat as well. No point asking someone trying to use ASI on ARM to filter out all the stuff about PV, shadow, and XPTI, for instance. > > +> `=3D List of [ , hvm=3D, vcpu-pt=3D | vcpu-pt=3Dhv= m=3D ]` > > + > > +> Default: `false` > > + > > +Offers control over whether the hypervisor will engage in Address Spac= e > > +Isolation, by not having potentially sensitive information permanently= mapped > > +in the VMM page-tables. Using this option might avoid the need to app= ly > > +mitigations for certain speculative related attacks, at the cost of ma= pping > > +sensitive information on-demand. It might also offer some protection = against > > +unmitigated speculation-related attacks. > > + > > +The mechanisms currently implemented apply to HVM guests, including a = PVH > > +hardware domain. PV guests, including a PV hardware domain, are unaff= ected. > > In the above you mix "guests" and "domains", I would rather use > "domains" consistently: "... apply to HVM domains, including a PVH > hardware domain ...". Same for the instances below. Ack > > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/a= sm/domain.h > > index c32dec793a..b192c86bc1 100644 > > --- a/xen/arch/x86/include/asm/domain.h > > +++ b/xen/arch/x86/include/asm/domain.h > > @@ -477,6 +477,12 @@ struct arch_domain > > /* Don't unconditionally inject #GP for unhandled MSRs. */ > > bool msr_relaxed; > > > > + /* > > + * Give each vCPU its own per-domain area (HVM only: each vCPU alr= eady > > + * runs on its own monitor table). > > + */ > > + bool vcpu_pt; > > Do we want to place this inside of an "asi" structure, and possibly > make it a single bit bitfield? I think we expect to add more boolean > ASI related options, so might be nice to have them packed together, > ie: > > /* Fine grained ASI related options. */ > struct { > bool vcpu_pt : 1; > } asi; Yes, that's nicer. A tiny bit of churn but worth it I think. Thanks, -George From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:49:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:49:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446274.1662364 (Exim 4.92) (envelope-from ) id 1xGFSl-0003KG-KK; Mon, 12 Oct 2026 12:49:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446274.1662364; Mon, 12 Oct 2026 12: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 1xGFSl-0003K9-HL; Mon, 12 Oct 2026 12:49:07 +0000 Received: by outflank-mailman (input) for mailman id 1446274; Mon, 12 Oct 2026 12:49:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGFSj-0003K1-Om for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:49:05 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGFSi-00000001k4L-2Q5A for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:49:04 +0000 Received: from mail-lj1-f182.google.com ([209.85.208.182]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGFSh-0000000CIY8-3hr7 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:49:04 +0000 Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-3a9e87ba696so5411001fa.0 for ; Mon, 12 Oct 2026 05:49: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" 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=3wUQOSxxdzxF2mncukRVGSRyY1m2K54g4QF1AUkAiWg=; b=vi6jW1x0oRJosUJiclNCYOalXo Jcdd+c4De/TuNA0kOXnn6J8ejJapIZ9Ppgd5CBK03R71Q4q9iuShtIDmF+JB53GjoFqsTj6Qpb6OW glnIScFFQXle1POBpxPLOwTGJ+SJa+8TF4n00M18DBNn0y4yIdsNiH0FJVqF84nza/X8=; X-Forwarded-Encrypted: i=1; AKwUvBxh38n1aKMZ8L0JnAxLStFW5pY1LZNaWeTzF5699o8/KEKTU6oMwW0pWVMQJ5ZYOaDVdFtx5SjKzRo=@lists.xenproject.org X-Gm-Message-State: AFq9FYKheuCXggsRZQUGqmPMDBBe7izFYKoLhRe5XOoLhq6dKM4pweky S6k+3pxzi6K50Cev1Qj6VnvBR8M8VCU4Gvd2ObxZobbBjN2m3F2f07S7CDvrXOZnjZQub+A9Og/ SkY6aZQtmzJyltsU+t/u4XUo5Jlm6/KU= X-Received: by 2002:a05:651c:510:b0:3a9:f130:6ede with SMTP id 38308e7fff4ca-3a9f1306fa2mr2353671fa.13.1791809343144; Mon, 12 Oct 2026 05:49:03 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-7-gwd@xenproject.org> <3441a775-7081-43cf-aed9-56d51658c32e@suse.com> In-Reply-To: <3441a775-7081-43cf-aed9-56d51658c32e@suse.com> From: George Dunlap Date: Mon, 12 Oct 2026 13:48:51 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-XINh4VFZkrCFzDjjYW-z_g2q1cRq1xF8_C-OcYiGR8n42Tq9zcRAwYLo Message-ID: Subject: Re: [PATCH v3 06/18] x86/spec-ctrl: introduce Address Space Isolation command line option To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Teddy Astie , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 9:24=E2=80=AFAM Jan Beulich wrot= e: > > On 07.10.2026 12:40, George Dunlap wrote: > > --- a/xen/arch/x86/spec_ctrl.c > > +++ b/xen/arch/x86/spec_ctrl.c > > @@ -86,6 +86,13 @@ bool __ro_after_init opt_bp_spec_reduce =3D true; > > > > static bool __initdata opt_ibpb_alt; > > > > +/* > > + * Give each vCPU of an HVM domain its own per-domain area (vCPU-PT). = Off by > > + * default until the feature is complete. > > + */ > > +bool __ro_after_init opt_vcpu_pt_hvm; > > +bool __ro_after_init opt_vcpu_pt_hwdom; > > I'm a little worried of this name, which doesn't distinguish PV and PVH. = Yes, > the variable name is already long-ish, yet I think inserting "pvh" is goi= ng > to help. Ack > > > @@ -487,6 +494,62 @@ static int __init cf_check parse_pv_l1tf(const cha= r *s) > > } > > custom_param("pv-l1tf", parse_pv_l1tf); > > > > +static int __init cf_check parse_asi(const char *s) > > +{ > > + const char *ss; > > + int val, rc =3D 0; > > + > > + /* Interpret 'asi' alone in its positive boolean form. */ > > + if ( *s =3D=3D '\0' ) > > + opt_vcpu_pt_hwdom =3D opt_vcpu_pt_hvm =3D true; > > + > > + do { > > + ss =3D strchr(s, ','); > > + if ( !ss ) > > + ss =3D strchr(s, '\0'); > > + > > + val =3D parse_bool(s, ss); > > + switch ( val ) > > + { > > + case 0: > > + case 1: > > + opt_vcpu_pt_hwdom =3D opt_vcpu_pt_hvm =3D val; > > + break; > > + > > + default: > > + if ( (val =3D parse_boolean("hvm", s, ss)) >=3D 0 ) > > + opt_vcpu_pt_hvm =3D val; > > + else if ( (val =3D parse_boolean("vcpu-pt", s, ss)) !=3D -= 1 ) > > + { > > + switch ( val ) > > + { > > + case 1: > > + case 0: > > + opt_vcpu_pt_hwdom =3D opt_vcpu_pt_hvm =3D val; > > + break; > > + > > + case -2: > > + s +=3D strlen("vcpu-pt=3D"); > > + if ( (val =3D parse_boolean("hvm", s, ss)) >=3D 0 = ) > > + opt_vcpu_pt_hvm =3D val; > > + else > > + default: > > + rc =3D -EINVAL; > > + break; > > While personally I like the reduced redundancy from placing case labels > like the default: one here, Misra rule 16.2 wants us to not use such. > Note that as written there's no violation, yet iirc Andrew keeps asking > for figure braces in such constructs. I think we're better off not > introducing new instances (the rule is marked clean, so with the braces > added we simply can't, unless the file is excluded from scanning). OK. Thanks, -George From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:50:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:50:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446280.1662375 (Exim 4.92) (envelope-from ) id 1xGFTr-0004nL-U0; Mon, 12 Oct 2026 12:50:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446280.1662375; Mon, 12 Oct 2026 12: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 1xGFTr-0004nD-Pc; Mon, 12 Oct 2026 12:50:15 +0000 Received: by outflank-mailman (input) for mailman id 1446280; Mon, 12 Oct 2026 12:50:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGFTp-0004n5-V4 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:50:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFTp-009WoE-8M for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:50:13 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd783-2eae-0a2a0a5409dd-0a2a450cca76-6 for ; Mon, 12 Oct 2026 14:50:13 +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 6accd784-f479-0a2a450c0019-d1558033cc4f-3 for ; Mon, 12 Oct 2026 14:50:13 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a168355946so15673185e9.0 for ; Mon, 12 Oct 2026 05:50: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-4a18ca51465sm219384325e9.4.2026.10.12.05.50.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 05:50: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=1791809412; x=1792414212; 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=yTqRGRkGGFTX8OIEWxZTEpjSEWFuMHhJLRGQIUH7L8w=; b=T7IzMNG83fln75XYjfAyLOR2XqRHGHvI6VHlkUld4XW9ZS6oPar5+i0v5Ph5PVehTO gE56SWc4QPYlR/WaT+Naib++6D54913/N98oyl9Vy/pGBGBUzjmkQqDJJ+wnHCh0gBnv egEGJ//vSjG5kjtS4hgZfP+uJG+MSQ+F9PiEvlRWYtQZ91DoSjTS2weqQ7Rd/H37jfz1 mReIOL0lqi7fRHL0CvlUPxS9zNcWG/ZnZ65uKVmCBA0yFWzXD+pqghu1Przt95JWegJB gOd6WjLoKtxtSEnZvjkk7bN0YOzsHDjF4Pe6eVZhBmOI2Uauf9Eqegrr3InojhHCBCG2 9BuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791809412; x=1792414212; 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=yTqRGRkGGFTX8OIEWxZTEpjSEWFuMHhJLRGQIUH7L8w=; b=X8SGWf0EPruqPpi/TG5Oc2p+Sv3JtW7KvbUdZ/euc6aPy6E9bRuewXTdyiM9BTuRZd d23IhqPYfNl5cTDJfLvSW00Fpql++4iViHDHEGjHjwJQqYyCZn+3UcHq8lk+SEpg5zVx EZsv8Op2YQb1XA9pNJSz6oyfpflsBlYdbkyWtE8T52pFmxmgA/NUSJU0/l28sSFUOTyd p6d7kLLM6etVFLXtEDFPx8u8XxJSVm647v83eGE7GIBhkbVFRj6+h52UCvUZhhyL+844 jZFr6LhYcszYdHdFDHPuumh8StvlhT1D5ugLyICkJS7hmdZUMNIWOK79W0LsHm2MNOkg 0xCw== X-Forwarded-Encrypted: i=1; AKwUvBx+Ep7MVB9grqXhr+SeWVdUsTa2G7VkRgFz77FtQCk/8wbzJYvsO6MYIoS6ieVApDBF3lWiOwyO4Ig=@lists.xenproject.org X-Gm-Message-State: AFq9FYJFh0QFM/epqTBVqlsbvLMTemQFb+35YniM0G2mdwnNHJ1OKceA TjLA+NjXx1n3heHJm0ajP9fAfndA01sV5N/HF62mVPrjI66mDbnOwLvpWmCM3PIq4g== X-Gm-Gg: AYBFou2APOBd5tRXFI3qon3AG9j8OL8JAq/7IvmdF8dULWn/NkQlWJcxd8QUFV7p8Hh d5KdOqVK6MTjQCRVroEbC7/q76V+oWd3L1K7a+XKM9GFJ2QqX0aDk8h+qX7bflWEiGobRq8o/2N tdjwtLo8T1bcBtvkQ3BFvK8yY+D63BNfWZ2wKbv3YcNKYTRFI/pIzIE7gbplK1Lr3FBE72KE0/D 8Gw9G4AR9qU+djGpGZmxjRyQ1GJpzRS2gYHrtEmLYpMlQplueAQ6409eNy9hjHskrpeQd6tVZxB XZj1nQajOhjyrF5yRQC94zeZEebz7U4sDbiTIL+bomA910/YIs2+ZwrY58lC9GCLg1FPOSuMAuu TrKXwJ7SFwuOYPoqU0BANQ9MdM2F8P29/c0BRZZW2JNrjz8Jhste7wyHJNI8nBEwKLTq3NzUETO fB7evfl/CtqEOLqUeiYd7j6KV0mfS51Z3KEK0kM8yBmfmQrqI+XzsCCfmdboIcsl1B9HYMwyes+ r6g4jS9BLRjzihqaOdHN0MxPgNO88PEEgrf9s6AwwD1ipZ9ijc505VuTR0k7w== X-Received: by 2002:a05:600c:4e91:b0:4a1:7ec7:a479 with SMTP id 5b1f17b1804b1-4a18e4f56bcmr187286085e9.33.1791809412453; Mon, 12 Oct 2026 05:50:12 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 14:50:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Zhang Zheng , xen-devel@lists.xenproject.org References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <1a6cdfbf-8116-48ca-b2cb-567e39fabe4f@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: <1a6cdfbf-8116-48ca-b2cb-567e39fabe4f@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1791809413-02ADCA5B-BE09CAC7/10/78276251493 X-purgate-type: spam X-purgate-size: 3324 On 12.10.2026 11:20, Oleksii Kurochko wrote: > On 10/10/26 5:14 AM, Zhang Zheng wrote: >> XScale-compatible UARTs require UART_IER_UUE to remain set. Probe the >> bit during setup and preserve it when enabling receive interrupts, so >> the xscale/PXA UART remains operational after ns16550 takes over. >> >> Signed-off-by: Zhang Zheng >> --- >> xen/drivers/char/ns16550.c | 12 +++++++++++- >> xen/include/xen/8250-uart.h | 1 + >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c >> index cdda28879e..c174465059 100644 >> --- a/xen/drivers/char/ns16550.c >> +++ b/xen/drivers/char/ns16550.c >> @@ -64,6 +64,7 @@ static struct ns16550 { >> bool intr_works; >> bool force_polling; >> bool dw_usr_bsy; >> + bool xscale; >> #ifdef NS16550_PCI >> /* PCI card parameters. */ >> bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ >> @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) >> /* No interrupts. */ >> ns_write_reg(uart, UART_IER, 0); >> >> + uart->xscale = false; >> + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) >> + { >> + ns_write_reg(uart, UART_IER, UART_IER_UUE); >> + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) >> + uart->xscale = true; >> + } >> + > > This probe only checks whether IER bit 6 is writable, which isn't > specific to XScale. On UARTs with an EFR (e.g. ST16C650, TI TL16C752, > Exar XR17V35x) the upper IER bits become writable once EFR[4] (ECB) is > set, and bit 6 is then the RTS interrupt enable. If ECB is already set > when the probe runs, it would report XScale, and the driver would then > keep the RTS interrupt enabled. > > Could the flag be derived from the compatible in ns16550_uart_dt_init() > instead, the same way dw_usr_bsy is? > > uart->xscale = dt_device_is_compatible(dev, "intel,xscale-uart"); > > That compatible would also need adding to ns16550_dt_match[]. The > SpacemiT K1 nodes, for example, have no "ns16550a" fallback. Are you suggesting that Linux'es XScale detection is flawed then, too? >> @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) >> UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); >> >> /* Enable receive interrupts. */ >> - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); >> + ns_write_reg(uart, UART_IER, >> + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); > > It seems like not all cases are covered. For example, > ns16550_interrupt() writes 0 to IER when it switches to polling, which > would turn off the UART on XScale. Am I missing something? If not then > something like: > > static void ns_write_ier(const struct ns16550 *uart, uint8_t ier) > { > if ( uart->xscale ) > ier |= UART_IER_UUE; > > ns_write_reg(uart, UART_IER, ier); > } > > would be needed, used in ns16550_setup_preirq(), ns16550_setup_postirq() Yes, the more that as per Linux'es driver source, bit 4 may also need keeping permanently set (not only for XScale, but apparently also for Tegra). Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:52:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:52:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446286.1662382 (Exim 4.92) (envelope-from ) id 1xGFVg-0005QJ-Ad; Mon, 12 Oct 2026 12:52:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446286.1662382; Mon, 12 Oct 2026 12:52: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 1xGFVg-0005QC-7n; Mon, 12 Oct 2026 12:52:08 +0000 Received: by outflank-mailman (input) for mailman id 1446286; Mon, 12 Oct 2026 12:52:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGFVf-0005Q6-AD for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:52:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFVe-005YOF-N3 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:52:06 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd7e1-bab6-0a2a0a5309dd-0a2a4503a4f6-42 for ; Mon, 12 Oct 2026 14:52:06 +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 6accd7f6-fae8-0a2a45030019-d1558032e010-3 for ; Mon, 12 Oct 2026 14:52:06 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a1635f7c89so18894795e9.2 for ; Mon, 12 Oct 2026 05:52: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-4a18d12fe04sm179315715e9.4.2026.10.12.05.52.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 05:52: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=1791809525; x=1792414325; 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=LtbRu2v2JZKLzoH50KkQK8EsMZeCKz00sehx3l4FGug=; b=e5JV9bmj+0wYz4/z2Kzx7Vi+yR1j5mT1vefJRS7DkKFNBvpUbuGhufVm9IISMeNiDh z+pAOucuvPr/Wu/QbS6Xr+6wf4NujeI+SsHcjoRDPLgojTLsLSWzJwzdBwMWZZUleOil YSGKCCJqZSDZxBF1j3tNLBCKeHY0r5rKKwkJs6nhnjaI3m18vyn62Exj1aStAo2GcLlR RGEqk0nLpuPNtSQB6aWaeQNEjSnPuhKA7f9namibLIUYrW6pGYQLvGcQ6oyVNj5zC8n/ 58fICTlJPux2WWMl8qVQU7VWkv7NgYQr7/FxQwfI29s/l2M+TYRNYmaknAVR7qSytbFo 77pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791809525; x=1792414325; 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=LtbRu2v2JZKLzoH50KkQK8EsMZeCKz00sehx3l4FGug=; b=o4ZWyyDZ7yMC3VIDGugErD/2NPxAZHfFzgl2s6EAGTPTKNf5FBDYa8xiqI1ofl7aPB PJ6rLCZPJCei78K6K6hmvyw06gvM/GjtQ2v5AQIn8sB1zJQaFUoMZ3iDv1qws64RxkF0 nzs4vTNrxasLxcdwZ4TpErNRJujD/TbTK/FSSvGXe2o9W22P9AV3lpo7o2dR4xFKb1Yc J8+huQoVDZtlcIcJQ5DmDHQMmzvNOyRCD8j7eWVPBI6lKlbJycEw3RngvDBiatLAIcTV Q8CuFZFPFGE1jWBvqcxpKCneqH3U9uk+6D5A6NsSZ5c//eX13Pw+4nhp/afoEvwy8SNS gDkw== X-Forwarded-Encrypted: i=1; AKwUvBysAyvGCfc1QBHyz2qfU63uUGj2qql7PjXs71PchU+yd2l9e2MXU1zLqCNQZzPUmEZar/Fdm7BQzY0=@lists.xenproject.org X-Gm-Message-State: AFq9FYIr0LrHkCTnO+VaRKhETgJy4/nleaoArHxABi0sVq9c8sgf6LhF lPd8okM7fZV7gv2EFQIOIMoCxan5v6lRpXCBOELVzc851G2AoPuEU5eIGNiG4VFBM6RUjKzSwFP f4IhAkg== X-Gm-Gg: AYBFou3JtQhznYq0IiwhBvn/WG5Kf/tUel7L86iSq5HA8vu61lWVqo6M8jPW1q/oIWV gB8UCQZlOBgWwCFVyjw12hA/M3AM1aI8Q7/AtolFeugeviOtUo/eAhH9mgcafnfW2PedommOuLP 1maghTbE1wrH4TF0LCWydJ5ic22F/Q8HkD3wS1cdriXUiT9JkEy2W18ubVpXWfc2JZwrjsETu4K yVxkd+4meWoJBctYicQUbUe6i6RUP6NuHJq34EQAQtgTwR9FETYZ20w9rslofL+XZnwwndtBAd9 WPXZM4kxpFT0M6bIF3v6+NKY/4Lv4rDGDwhNWOj8YhwoRTXQseDJ/jgISMsE0DCyyIt4QH4UO+Y iURqv7tr2AXrX+Wdddjc3homu2qKidYod4vPe0PChmkiM1usQgzOjJ6E3ktkLnFRrxoCdoDGiWm PcFKRo8VquGFRiziXD4YdiHx/huozcIQMO09wzAbxVDwphUrX8aU+xOP4aDNJlWjchNGrOWo//J ah4E/hTfyVETTPaU+P4tMIR+9WmzCcjYZdDkTLykjH8EM38R9Uo48z7rpBqknE= X-Received: by 2002:a05:600c:3544:b0:4a1:813f:2a57 with SMTP id 5b1f17b1804b1-4a18e4ad8fcmr163103565e9.13.1791809525498; Mon, 12 Oct 2026 05:52:05 -0700 (PDT) Message-ID: <5bc2e923-4265-484f-9236-25a56560e2c3@suse.com> Date: Mon, 12 Oct 2026 14:52:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE To: Zhang Zheng Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> 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: <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1791809526-74A894E9-4E41DD28/10/78276251493 X-purgate-type: spam X-purgate-size: 949 On 10.10.2026 05:14, Zhang Zheng wrote: > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -64,6 +64,7 @@ static struct ns16550 { > bool intr_works; > bool force_polling; > bool dw_usr_bsy; > + bool xscale; > #ifdef NS16550_PCI > /* PCI card parameters. */ > bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > /* No interrupts. */ > ns_write_reg(uart, UART_IER, 0); > > + uart->xscale = false; > + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > + { > + ns_write_reg(uart, UART_IER, UART_IER_UUE); > + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > + uart->xscale = true; > + } Linux'es detection is a little more involved, plus: It doesn't clobber the value originally present in the other 7 bits. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:57:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:57:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446295.1662392 (Exim 4.92) (envelope-from ) id 1xGFaN-00067O-Rl; Mon, 12 Oct 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 1446295.1662392; Mon, 12 Oct 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 1xGFaN-00067H-O1; Mon, 12 Oct 2026 12:56:59 +0000 Received: by outflank-mailman (input) for mailman id 1446295; Mon, 12 Oct 2026 12:56:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGFaM-000678-E3 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:56:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFaL-00GFKY-3I for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:56:57 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd913-2eae-0a2a0a5409dd-0a2a4503e690-22 for ; Mon, 12 Oct 2026 14:56:57 +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 6accd918-fae8-0a2a45030019-d1558034b1d1-3 for ; Mon, 12 Oct 2026 14:56:56 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a061a13884so16051685e9.3 for ; Mon, 12 Oct 2026 05:56: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-4a193f2c992sm201361645e9.5.2026.10.12.05.56.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 05:56: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=1791809816; x=1792414616; 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=u95/uf81bePCKi/y4LbsZNAPkynnjwYKUeGvgiq9Vls=; b=T8t6OMC/Jm3mesiyqCg3CWK3nhVmWCagpURSBU28dK3PfjtHSMvYs9aNv66jq9PTJX ENly1uwQTiIuyaS/ehohyeH3AUwo6uZFPPZ/oYq7hiphntrPL7gM8+0Gfj/HmyzMBYkQ 7XBwMhWExr665RnDPGWOC62BJ5cTQyI5DtE/4TeDqrQhByaeqLkkTAB4P1sC87uwvRfR Lk2i+8S5nHLnruV7lHOuOZbc0e0RQsCN4+O1MGuqmsnPPqh/KnRdRhqnp+op1J/XFTy2 TGyPTgCv0H6jvRNhpAYBkLqB7HSN4OUzqlAWbGmcDz0n62s6uEKKNAtf6KiXyLTUKf0h HJtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791809816; x=1792414616; 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=u95/uf81bePCKi/y4LbsZNAPkynnjwYKUeGvgiq9Vls=; b=t/Thl/2ai6CRZSVoqogyB0SW3IKqXtdpuqHX/dYyyWGIrd9RTqFBS1jgjp58RjYg+a a8FDcijqUzFCIwPIkUIxLrLpSJYQ6H7aRzdI7DbvXQFKUg7w4xQFRM5fk0R/4RjgJBuL 7fwl1dQg1hDe5yOCTpftdAX9npJXpRRDLXC07ZCN/m8tmNctHl8dw6z2h/nIar7EmSU7 JmRR6F42jZwPL/ZISiyQDd5uxAPUruyW9hPszT1W7PEC1NqcNSq+kFzTB4GJ12tMu7FK YxesedMz3zqXycHDX6qgdc68ZZM0a4Bqvoq+oEckWvXMK8M3Vb6ekl4vLYaJraaq/6RC 7SSA== X-Forwarded-Encrypted: i=1; AKwUvBxQ7GpGjQih9KFeaDa84eU3wgGIIcfSffTCqr4X5jCNoDjvjOx5Y1ka+w5n4sJE1nHzN087vKXl5AM=@lists.xenproject.org X-Gm-Message-State: AFq9FYKWfyYKxjmhDyKEGnHAGud30Ah6ESPSuvw5HAfkFA/+vp0f6HM3 faiGgcDwuEwJO0+VnGeJX4GrgTvBs1vSS7VTkuy3jetQDU2w4cWyJr/slyTugK2HkQ== X-Gm-Gg: AYBFou1KFHejTf8mmRqESyzwEiKIyqLcTO6GaDnnJmVTQRJXzmLqrtzc0kIvPJf59d/ 1VESbl8bq1M62uVpb0H2Kd03kCTkW8CxqQiDPt4LPF8HM8+xcoi0FUb1Yaz7djJ1+lDOj0eQhtQ fpuP6/TyIdkvujeo63juB609FNkSXGtJgbST4Sf42XLgxaYkBG26DEwP/rhmKaF3mfAIUPPzORz k6um7KwJhqhkB8OYhIcomkx9W1bT5NH+g7x/7B+B/7ZWHmJbhY6gDYEEzl5omfRnXO26fZ8s+Gw Uy1m10vCvqBL+OLIAw+yCjJovayXsNGKwdONda6CeY60af0ywR92wQUkRmkE0xigeNMUx5eA2Gw LSCiH4NX25ttTt3fU/USLTzEpSnPJAj2/1jgYU0uBC/bhuyuTtO4bcoihZSd151h3cx4CN1ivu/ IassfEMUvKp7EgOozdLim18xwZMyszdQVZo8w9hZBimZL/YNMbVwmM4c2ULEdVVixckhuUlEs9T lUwnRAXZzDRFKu3mMEBU1IqnLZUkElQvoXPLrRUtX5S6Gtvj9rpLOYgx8cTNU0= X-Received: by 2002:a05:600c:4e55:b0:49f:fe39:5bc8 with SMTP id 5b1f17b1804b1-4a18e49c008mr164344215e9.12.1791809816361; Mon, 12 Oct 2026 05:56:56 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 14:56:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Zhang Zheng , xen-devel@lists.xenproject.org References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> 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/1791809816-77AF14E9-D51F6DD3/10/78276251493 X-purgate-type: spam X-purgate-size: 2111 On 12.10.2026 12:20, Oleksii Kurochko wrote: > On 10/10/26 5:14 AM, Zhang Zheng wrote: >> --- a/xen/drivers/char/ns16550.c >> +++ b/xen/drivers/char/ns16550.c >> @@ -427,6 +427,10 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) >> #endif >> } >> >> + /* Preserve output queued by firmware before taking over the UART. */ > я' > Could the comment say why the wait is needed at this point? Something > like: > > /* > * Output written before ns16550 takes over (e.g. by firmware or the > * early console) may still be in the transmitter. Let it drain before > * ns16550_setup_preirq() reprograms the line settings and resets the > * FIFOs. > */ > >> + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) >> + cpu_relax(); >> + > > IMO waiting for TEMT rather than THRE is the right choice: besides > resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and > LCR, which would corrupt a character still being shifted out. (Linux > waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT > already implies THRE.) > > The unbounded wait can hang early Xen boot if the UART never reports > TEMT for some reason(?). Bounding the wait would make console > initialization more robust, allowing boot to continue when the UART is > unavailable > > for ( i = 0; i < 50000; i++ ) > { > if ( ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT ) > break; > udelay(10); > } > > would need udelay() on RISC-V, which is still a BUG_ON() stub, so a > separate patch would be needed for that. On x86, udelay() doesn't delay > yet at this point (cpu_khz is only set by early_time_init()), so there > the loop would just be an iteration count. Perhaps someone has a better > idea of how to implement a timeout here. Whatever it is, it's going to be more or less crude. See e.g. Marek's solution for a similar issue (yet to be committed): https://lists.xen.org/archives/html/xen-devel/2026-10/msg00439.html Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 12:59:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 12:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446301.1662400 (Exim 4.92) (envelope-from ) id 1xGFct-0006wJ-6F; Mon, 12 Oct 2026 12:59:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446301.1662400; Mon, 12 Oct 2026 12: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 1xGFct-0006wC-3N; Mon, 12 Oct 2026 12:59:35 +0000 Received: by outflank-mailman (input) for mailman id 1446301; Mon, 12 Oct 2026 12:59:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGFcr-0006w3-Pt for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 12:59:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFcr-00EiGp-5J for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:59:33 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd9a9-e002-0a2a0a5209dd-0a2a4505d7ca-22 for ; Mon, 12 Oct 2026 14:59:33 +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 6accd9b4-4cb1-0a2a45050019-b9ff1c23a69b-3 for ; Mon, 12 Oct 2026 14:59: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 1a130325e7700080d7.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 12:59:29 +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 1F1BA82A2E; Mon, 12 Oct 2026 14:59:29 +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=ALpgLwBmyST4wwta0BdWWvLh0x8Z6fccFcXa4ymz0Es=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=gsiR0hf40NZEEkpvJk146z2NIZwWr4atyYnn25ly40d1kYXWgALu8n8grYpaRSPe1X2ZAwnA+ al9IUEzdTUHXVM+m47lZhDc1jvYca3ORRczJOaxbZTJ6ob3gGczE1w5iZhaEKRfSin3alwbYSqE xH5R6ptLY6bq/Qd7mY4eEkPDASJuG3beVo99f4nKVfFNmkcfNQwHaqVkGbuO3TAaFF708bn0PFR 2o6mWylUKY0lLyOOtLEruEnjOO2gXg8nJrO1Qyo6jceu1Kj1SaFXiZlRKnoRVP/cV3BjU6wXtsp exahnxR+QZS5TmsbrKOdd6xneijEVCnhJolGiX22OHig== X-Zone-Loop: a3bb09e2f04204f9c9e7fc880f077833f4dc4488ce26 x-campaign-type: default x-transaction-id: 77c76d5b-63a2-4e13-89d1-ad559541ece1 x-swg-uid: 01-4804db62-a1a2-4efb-bd0f-37a6963fe0de X-Mailer: Sweego Message-ID: <1791809969.8631fc262581453bbf619ec5b2062170.1a130325e7700080d7@vates.tech> x-swg-bid: 1791809969.8631fc262581453bbf619ec5b2062170.1a130325e7700080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 12 Oct 2026 14:59:28 +0200 From: Anthony PERARD To: Jason Andryuk Cc: Olivier Lambert , xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: [PATCH] tools/libxenstat: don't lose all VIFs when dom0 has no Linux bridge References: <1791011886.8631fc262581453bbf619ec5b2062170.1a100a0936a0003f66@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.f9.12ee6d52d261336f.1a130325c41.26f1a35d09122b8b=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791809969218 X-purgate-ID: tlsNG-c201ff/1791809973-2491C2A1-2736C31C/0/0 X-purgate-type: clean X-purgate-size: 1605 ---=Part.f9.12ee6d52d261336f.1a130325c41.26f1a35d09122b8b=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 05, 2026 at 04:49:43PM -0400, Jason Andryuk wrote: > On 2026-10-03 03:17, Olivier Lambert wrote: > > xenstat_collect_networks() looks for a Linux bridge (a > > /sys/class/net/*/bridge directory) so that, with bonding, dom0 can be > > given the bridge's counters=2E When there is none, as on hosts using O= pen > > vSwitch (the XCP-ng default), routed networking or only libvirt's > > virbr0 (which is excluded on purpose), getBridge() leaves devBridge > > empty=2E strstr(iface, "") then matches every interface, and devNoBrid= ge > > is just "p", so every VIF with a standard name (vifN=2EM, vifN=2EM-emu= ) > > takes the bridge branch instead of being attached to its domain=2E Eve= ry > > domain ends up with zero networks, and xentop shows NETS 0=2E > >=20 > > Only take the bridge branch when a bridge was actually found=2E > >=20 > > Fixes: 1fd93d4f8cb8 ("xenstat: Linux dom0 statistics for case we use n= etwork bonding") > > Assisted-by: Claude-Code:claude-opus-5-5 > > Signed-off-by: Olivier Lambert >=20 > Tested-by: Jason Andryuk > Reviewed-by: Jason Andryuk Acked-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.f9.12ee6d52d261336f.1a130325c41.26f1a35d09122b8b=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:00:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:00:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446307.1662410 (Exim 4.92) (envelope-from ) id 1xGFde-0008Om-ER; Mon, 12 Oct 2026 13:00:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446307.1662410; Mon, 12 Oct 2026 13:00: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 1xGFde-0008Of-BZ; Mon, 12 Oct 2026 13:00:22 +0000 Received: by outflank-mailman (input) for mailman id 1446307; Mon, 12 Oct 2026 13:00:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGFdc-0008OP-Pc for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:00:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGFdc-00FTUn-6H for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:00:20 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accd9dd-2eae-0a2a0a5409dd-0a2a450ced44-28 for ; Mon, 12 Oct 2026 15:00:20 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accd9e4-f479-0a2a450c0019-d155dd34e5ad-3 for ; Mon, 12 Oct 2026 15:00:20 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso1067445f8f.1 for ; Mon, 12 Oct 2026 06: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 ffacd0b85a97d-48db9ac02cfsm18407157f8f.39.2026.10.12.06.00.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 06: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=1791810019; x=1792414819; 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=RJQGPJanJDXg6DbqvTSjWrKAiReORlhKwHO8IL2DMA8=; b=gQoDj5O2+Bm5JHkDHvWNq/GeZ6cUAwq+PiG2J+LFN9ouX1v3you+wkjMCObfOYLFYa t/VdPhDHP5txRRGu2ZAMqsSPl2OABDC2eOM1WieyXULBorw+LKTXuyzw3bTqh/YIaOxK i3TS80NmbEWvrTUJbYsLkySLt2eLQlQRWdoq4cYwfKMWQAUsx9rOR+22H3QtRfGvDksI DIbNJapAO5CAhQCwNjlpyxNeYo4Rs8StBKCM32cfbH3dClLn5J6WGRrjJFLseZDatwqU TQ1xMWE2gdTCAtpmkLkNwQNRGyHrJtDBsbIlAw5X4y9+PCWGgoKs+rskwubzAWbH5KOq Kh4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791810019; x=1792414819; 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=RJQGPJanJDXg6DbqvTSjWrKAiReORlhKwHO8IL2DMA8=; b=Hf4G2GV4yk3rJ+Li5rbD1+FtLd0pfGzCPqfV19sIkI2c+Ewx5Sg3zKqxpcpjAaKI/k n4q2ziFFw+dKaF71OMHp+RvJ1Gq5ly7zqbrzBefq5OSrsQi4wJSsbmnACgmHcN3a2gLO hlOF+4QwIRrKFTvqN4XNTJl0+mKH+eWcN7mzA7E26MkREETG3RbhbdB7mVQKOU7L4RO9 F9BOa9M++4uiDhAZ4wp5pyv26Ri6PSXVGN6GUsVWvSXCInxzOU6i7lxEXsCXP3+15CUi c0kqBncEXDtO8IGnCZGl9FvbHmNjSNYGRhquHxMksEpHyH3/TdSFieyDUBEZMmyeaQGB rgVA== X-Forwarded-Encrypted: i=1; AKwUvBx7eYQ+kOktWeS/CdXshNtMKuUxaNyqUkoxh6z1FFuOeSJDsC4nz0nhAQZaBMOcKqrHIRzEySy7rd0=@lists.xenproject.org X-Gm-Message-State: AFq9FYKqKAQKa1eD0ukRsnFIssqwMk9A25Ox1zJ2v8ZfKB+JqRSDr4ew zOjsLmesC+uEA8Ie+hReiIM/VQCwabViRdQKIF0eArv0REDHP/GVAdII2eomS4tYIQ== X-Gm-Gg: AYBFou2SkEqtETQ0CbLGxylsExvt9FQEAWPGVko7/a0cjrhNMPYnZV7lgIuPpcIQf2E dEbXRPa1YHAHPYoLv0zuTdP7h0D9PQF7QvwMWqx3LfIyRh+Tp02OEhKkZIBKCUXasxhCAKSSGFP Ceg11Z4bnu1Bzrq91m8sT58mS+m3LoGMWHButTIID8tZ15UoR6hTjVCHkijmWXgB1Cfrv4IIcLU 6D1CvWPM0yqvIxXp/B+taqg0CEDNdDnd7gO4lSEmjJoojYtu7yFDTf2lxOJAfdpp9L5otTBKlZ1 1PiGiHVjD97MHb8Z+ZUFK7Y9CsPSqYXQAEP/hGfxmGy612t+TGhhJwRVpkWVq7AfGp1wE88XjWT fcOxEHiKDIQgMHf9hsHScvY6bBB66OY9yziu+f4FoEEgb3lGn0nsgf7JG94xOLmak+CMruwg16/ wqx/2wrvB6jc1bcvt4MojUEo9jQh4wMGYxvBV7Knj5Z4f8cDdZ0LteD5yZRlaScdRwHwVF73Kc/ zTNmRNnSnqH4GY45x2qsKepc1A2GyAsFnq6Sm33pxcAibr/Eve8eVAO2AJ3aw== X-Received: by 2002:a5d:5d83:0:b0:48a:efed:ac97 with SMTP id ffacd0b85a97d-48dba9d326amr17562080f8f.33.1791810019466; Mon, 12 Oct 2026 06:00:19 -0700 (PDT) Message-ID: <2415e2b7-3066-450b-9917-d1267a1c2b90@suse.com> Date: Mon, 12 Oct 2026 15:00:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Zhang Zheng , xen-devel@lists.xenproject.org References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> 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/1791810020-03CD3A5B-36B47E1A/10/78276251493 X-purgate-type: spam X-purgate-size: 1284 On 12.10.2026 12:20, Oleksii Kurochko wrote: > On 10/10/26 5:14 AM, Zhang Zheng wrote: >> --- a/xen/drivers/char/ns16550.c >> +++ b/xen/drivers/char/ns16550.c >> @@ -427,6 +427,10 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) >> #endif >> } >> >> + /* Preserve output queued by firmware before taking over the UART. */ > я' > Could the comment say why the wait is needed at this point? Something > like: > > /* > * Output written before ns16550 takes over (e.g. by firmware or the > * early console) may still be in the transmitter. Let it drain before > * ns16550_setup_preirq() reprograms the line settings and resets the > * FIFOs. > */ > >> + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) >> + cpu_relax(); >> + > > IMO waiting for TEMT rather than THRE is the right choice: besides > resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and > LCR, which would corrupt a character still being shifted out. (Linux > waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT > already implies THRE.) Then again we have the .lsr_mask field. Not using it here would then call for justification in the description. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:24:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:24:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446317.1662419 (Exim 4.92) (envelope-from ) id 1xGG0y-0003WV-Ck; Mon, 12 Oct 2026 13:24:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446317.1662419; Mon, 12 Oct 2026 13:24: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 1xGG0y-0003WO-A1; Mon, 12 Oct 2026 13:24:28 +0000 Received: by outflank-mailman (input) for mailman id 1446317; Mon, 12 Oct 2026 13:24:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGG0w-0003WI-GX for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:24:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGG0v-009dv3-LV for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:24:25 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accdf88-8faa-0a2a0a5109dd-0a2a4502afa6-4 for ; Mon, 12 Oct 2026 15:24:25 +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 6accdf89-6ca4-0a2a45020019-d155dd36d10d-3 for ; Mon, 12 Oct 2026 15:24:25 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48dc202a60eso574545f8f.3 for ; Mon, 12 Oct 2026 06:24: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-48db9acf12bsm20036038f8f.46.2026.10.12.06.24.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 06:24: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:From: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=1791811464; x=1792416264; 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=SPunvD7uvZXlFujIlD9X2g1IjNA+IJBJjAf+s8sexwE=; b=BxUxH/mKg7z6OdoKUXyYWMvj14WxBZ08tseApl7zrzO7omcmSIxwr3viJSHJ1HadJq 2a8k3IvoI5phizl1kBpfRTzLKBRqjfiI7lePXVFf3bF2rUeYAZJ3VaoFM/5b9Q9uq1bM 32ev/pVsmF13Goum/UiAezK8kKzeGTIoogAwrI5Xfri597iIOPJ8p/Gd1wf0e+qkrk+k HQwWe+IvWNUe8Tcu34Eo64opsgzpTmRSVIYkBe0McWaWdRzuweZQNPPNvKLsgw8//azi CSXMLtM96TE/mMAjrVFBgGqXJfgS+Z+h+wQzOu621PBsrJEKz7fvfga7ViGd/0DXayzw B3FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791811464; x=1792416264; 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=SPunvD7uvZXlFujIlD9X2g1IjNA+IJBJjAf+s8sexwE=; b=ir+AhqwMf55BCYP1yA7ClvY/MQ06odzLVB4lyLAmarahxGV84Dn+BahCJJ851fruif Uo7JtCYu6hnbVMRcnMLYGAr08bPCWs6IQNIb+t86+zJg+UUBuORulf+kZXWOKcwwOmcb gnHHwkAR2HDkpwooTFZ9KXlK2xVkVEkTOhpiY36LbfInp5I02PpaKvLKg3JD4mlxwS1o 0Ht7uKik+yA7S9cQTqSjKoahH9UoW2+Xtt4xePRUID8+03AyEjkyKPilWW7PRhpOIpxT ysoCFFGXdzAVGwZBtyR/k6E2cS1eDSE0VvDn3BFcLwkUBPerdjRH/+pJguhCisnS4fzE jGkg== X-Forwarded-Encrypted: i=1; AKwUvBwOStS83bviEgFVGjrcKEEusd6aFqN/ucfh3r9nhOBIqOlB8k0DINwe3Ca/+dxX8n1jrcRJvs6bv6I=@lists.xenproject.org X-Gm-Message-State: AFq9FYIwvAd8jzIdUiQBu8/+fpxAJL7N4jNaEw86WR4DDRFPUcKIuzGa GyW+SIBfGvqYrPS2csYcoG2Jx4DdZ8N7v0k/S0GEZ4jXy6OVErsSfj4l X-Gm-Gg: AYBFou36CU8GHNz2CMk/L/qMiKUuC+53jkBsoIHER0eXcldfwiWmpQdrbr2HI6auKC2 Tas/wSxYZONQdWdpzk8PvYS5/AwC+8xtj3Js9mpf3yJwsUOu5ind2thUe1LyotlvYlngWctWUmV BIE5wFt23GsDClaJ0XtsRWTf2kKnUJUf2sV/YpJSWVuR1dk41Z7lXLZon0pnD98cRa8pu1nHmf4 UFUR4hc2Uo0dL+t0G/98xDybV3dJvcqdCt+yDCzj5XXOZ6+xasrOJPM31pMu1WbcudQvcFaTXGt O+3e+ajSTbql6d6r95dVinewqU3syGonxMvxxs3eLOAo6d35oyvAVhgYS9hwJ4VHpPG3TiTA/Kn 6EJ9rS8whD/3/N+HmEwRdishY5SjZzjx7Ks1oNo+X/eZRK/PZ9ft3lNbuX1pZQhWgUSIA2DBO3X owMkcQ7yzHmUGV5b5IdfJdxfe1izMd1vTR21N/q9vLML6hJR8elguin32PnufKCjwLAkTnz0LBq vNtxkGtYioGPu/pKei8IUi6cTPnkrFTOJu7w+D/lZwV037BNA== X-Received: by 2002:a05:6000:144b:b0:48c:7ac7:e59d with SMTP id ffacd0b85a97d-48dddfac1c3mr1925209f8f.34.1791811462531; Mon, 12 Oct 2026 06:24:22 -0700 (PDT) Message-ID: <5d012ec1-60f8-43b9-a1cf-1bd0d0d133ee@gmail.com> Date: Mon, 12 Oct 2026 15:24:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE To: Jan Beulich Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Zhang Zheng , xen-devel@lists.xenproject.org References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <1a6cdfbf-8116-48ca-b2cb-567e39fabe4f@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-720697/1791811465-F2EB32AC-E02BDCED/10/73395122804 X-purgate-type: spam X-purgate-size: 4509 On 10/12/26 2:50 PM, Jan Beulich wrote: > On 12.10.2026 11:20, Oleksii Kurochko wrote: >> On 10/10/26 5:14 AM, Zhang Zheng wrote: >>> XScale-compatible UARTs require UART_IER_UUE to remain set. Probe the >>> bit during setup and preserve it when enabling receive interrupts, so >>> the xscale/PXA UART remains operational after ns16550 takes over. >>> >>> Signed-off-by: Zhang Zheng >>> --- >>> xen/drivers/char/ns16550.c | 12 +++++++++++- >>> xen/include/xen/8250-uart.h | 1 + >>> 2 files changed, 12 insertions(+), 1 deletion(-) >>> >>> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c >>> index cdda28879e..c174465059 100644 >>> --- a/xen/drivers/char/ns16550.c >>> +++ b/xen/drivers/char/ns16550.c >>> @@ -64,6 +64,7 @@ static struct ns16550 { >>> bool intr_works; >>> bool force_polling; >>> bool dw_usr_bsy; >>> + bool xscale; >>> #ifdef NS16550_PCI >>> /* PCI card parameters. */ >>> bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ >>> @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) >>> /* No interrupts. */ >>> ns_write_reg(uart, UART_IER, 0); >>> >>> + uart->xscale = false; >>> + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) >>> + { >>> + ns_write_reg(uart, UART_IER, UART_IER_UUE); >>> + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) >>> + uart->xscale = true; >>> + } >>> + >> >> This probe only checks whether IER bit 6 is writable, which isn't >> specific to XScale. On UARTs with an EFR (e.g. ST16C650, TI TL16C752, >> Exar XR17V35x) the upper IER bits become writable once EFR[4] (ECB) is >> set, and bit 6 is then the RTS interrupt enable. If ECB is already set >> when the probe runs, it would report XScale, and the driver would then >> keep the RTS interrupt enabled. >> >> Could the flag be derived from the compatible in ns16550_uart_dt_init() >> instead, the same way dw_usr_bsy is? >> >> uart->xscale = dt_device_is_compatible(dev, "intel,xscale-uart"); >> >> That compatible would also need adding to ns16550_dt_match[]. The >> SpacemiT K1 nodes, for example, have no "ns16550a" fallback. > > Are you suggesting that Linux'es XScale detection is flawed then, too? I looked at it quickly and not flawed as such, but Linux uses that test only as a last-resort heuristic, which isn't how it would be used here. In Linux the bit 6 test sits at the end of autoconfig_16550a(). That only runs for ports whose type isn't known up front (legacy/PnP/PCI autoprobing), and only with CONFIG_SERIAL_8250_16550A_VARIANTS or UPF_FULL_PROBE. It also comes after the EFR probes, so ST16C65x / TL16C75x style parts are classified and return before reaching it. Even so, the comment there says "this is probably one of the Xscale platform's internal UARTs", and a part whose EFR already has ECB set would fall through the EFR check and be reported as XScale. So yes, the same corner case exists there. Where the type is known, Linux doesn't probe at all: 8250_of maps "intel,xscale-uart" to PORT_XSCALE and sets UPF_FIXED_TYPE, so autoconfig() (where it is happening the probing in a similar to suggested above way) never runs for DT ports. 8250_exar sets UPF_FIXED_TYPE as well. > >>> @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) >>> UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); >>> >>> /* Enable receive interrupts. */ >>> - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); >>> + ns_write_reg(uart, UART_IER, >>> + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); >> >> It seems like not all cases are covered. For example, >> ns16550_interrupt() writes 0 to IER when it switches to polling, which >> would turn off the UART on XScale. Am I missing something? If not then >> something like: >> >> static void ns_write_ier(const struct ns16550 *uart, uint8_t ier) >> { >> if ( uart->xscale ) >> ier |= UART_IER_UUE; >> >> ns_write_reg(uart, UART_IER, ier); >> } >> >> would be needed, used in ns16550_setup_preirq(), ns16550_setup_postirq() > > Yes, the more that as per Linux'es driver source, bit 4 may also need keeping > permanently set (not only for XScale, but apparently also for Tegra). Good point. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:25:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:25:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446322.1662428 (Exim 4.92) (envelope-from ) id 1xGG2K-00040k-Lf; Mon, 12 Oct 2026 13:25:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446322.1662428; Mon, 12 Oct 2026 13:25: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 1xGG2K-00040d-Ig; Mon, 12 Oct 2026 13:25:52 +0000 Received: by outflank-mailman (input) for mailman id 1446322; Mon, 12 Oct 2026 13:25:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGG2K-00040V-1r for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:25:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGG2J-004cIm-1R for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:25:51 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accdfcf-bab6-0a2a0a5309dd-0a2a45068df8-48 for ; Mon, 12 Oct 2026 15:25:51 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accdfde-195a-0a2a45060019-d155802da524-3 for ; Mon, 12 Oct 2026 15:25:50 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a166199820so11913405e9.1 for ; Mon, 12 Oct 2026 06:25:50 -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-4a18e48db03sm407940865e9.3.2026.10.12.06.25.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 06:25: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=1791811550; x=1792416350; 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=P9+MB/Z1Xmt/uUTQiiC8cla9bqudcNF/hHQ9kFRjU+k=; b=WvkztLeIOEJ4ucfa0Yvh+fIPKJM9QKhMe686Bz0I9Ow5Faj5OFaRDUHXy0wrk/kdni c1r7CXZB9bdCLHGbbwxxDvu4l0JACuSvv10+l5yEFuNl/rPpnPETResiAGL2I3Ada9Py I6CBmEDe5qX0C6J6s7F5ZOXUUlzzFN3BXA5YpSkzzdf1ckCD8b/rlOnNXl8qVaiBWs24 eQlI7R2f60GT7z9dlHL/+HmU6i8lsnb/tnV1ZtrvwxHeso+1qnbnQnnqfWE4U09g8MH7 JR++VVJUfypFq6hOJVAKeRq0Yy3MyQGcNjClLyAlh37R7xktMnH+T1J+6QE1G/oa4iEA Fb+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791811550; x=1792416350; 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=P9+MB/Z1Xmt/uUTQiiC8cla9bqudcNF/hHQ9kFRjU+k=; b=DCnYVsycQVR5oz8ZdiEILZ9bW3reuXgOc3fru5mZfaJSTclhbHLVu/tVzVKILfT6Hf GFOROoEr6TfYhF+4Y3RM7LoNbH5NLZTpNsscoG6jIu2oMmMTq5ss43dcxHTopXDhRkMl VZrhOocuRS9nWqW86Z309H6J+RJ4ROPHm/i2dVmnKJL8UX025+FR4WQ9hNq4nR+Nb/yB pgTHvEHTNmTot8QhlQyIET1XS/jxnFu9ppSGg5BI/kqXCkxhBIyGrz5hXKQ527k3kllv rJX/qhuCh+4UvQQb94Dyv4QQFmIYvqlE93v4a4Wwk1V20LBWeYHArUlfq4T3bZhNPHwx i+bA== X-Forwarded-Encrypted: i=1; AKwUvBwb5ukRsius8LvtpDBk54b0VyAnbGXcBwbttaNMFbXyOXEM3Ixl/7nBIaeVL13Twpw1dS40I3ppIJM=@lists.xenproject.org X-Gm-Message-State: AFq9FYLIZwMCfaen3AnhuJatdN/+HDDPGd9NB/yqCEzsfDPvT/zUHJYi do6smjntu1hvk8h0qB9bxUrxd0RefmPQANxMolqYTsgDyOT43P1HnnYU X-Gm-Gg: AYBFou2DlDTvyVROTUWukoWqtd5Xk4M2OokLpinMwfsaiVzWY7qyW87+0STd7w7v0pH VWWnZzmBPmq8Svwz5O+eQWhAfUMMQgx21w/VXhDKuZc+/NhVHGgbqQ/JKyT+OTggMPRJTMM6qNT 27ZSVvanrHcT6CoLKeSQaJxJn+rfBsa0Y0CKiXZ++flYY5MjMlUgJ7WtAUCZVtzyYXCqehTM9OZ Plb3tAuL6sfqUx8ImWisGPxeOV54hB9maM7fnfLcbZQBqN7NuKhq+uQTU72PnPUgpB4JxhKCHJT MI8z0vPF9vuGNTZ76/qsqpbRIasQRkW94LoT7BXZsvpxyPruTcqhRqplHj1lQ1u2aIY6r1FYDOL inDmYAJNc8rkNLqMlM58T4O6R+pjOWnr6WlkEI53/vC1tyszkNyDVTTL73g6p2FD1F5LTIR4lbT HhbsvndUTbuRb8Mq+ugKSzt4Jf+ZsLPc08NUIW9A/kcVtFXqlQZtb2z7YuDOwagwX7ggyUWYX3y GtVmuL8M/a72FDt1ShXjUWezuJ3tAzut5fR+sj5k1R/vgFFu41Apouy6Nt0 X-Received: by 2002:a05:600c:c10e:b0:4a1:93fd:913 with SMTP id 5b1f17b1804b1-4a193fd0ad6mr95790335e9.10.1791811550198; Mon, 12 Oct 2026 06:25:50 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 15:25:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing To: Jan Beulich Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Zhang Zheng , xen-devel@lists.xenproject.org References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> 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-16d1c6/1791811551-FD80D77B-37CD3DDC/10/73395122804 X-purgate-type: spam X-purgate-size: 2280 On 10/12/26 2:56 PM, Jan Beulich wrote: > On 12.10.2026 12:20, Oleksii Kurochko wrote: >> On 10/10/26 5:14 AM, Zhang Zheng wrote: >>> --- a/xen/drivers/char/ns16550.c >>> +++ b/xen/drivers/char/ns16550.c >>> @@ -427,6 +427,10 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) >>> #endif >>> } >>> >>> + /* Preserve output queued by firmware before taking over the UART. */ >> я' >> Could the comment say why the wait is needed at this point? Something >> like: >> >> /* >> * Output written before ns16550 takes over (e.g. by firmware or the >> * early console) may still be in the transmitter. Let it drain before >> * ns16550_setup_preirq() reprograms the line settings and resets the >> * FIFOs. >> */ >> >>> + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) >>> + cpu_relax(); >>> + >> >> IMO waiting for TEMT rather than THRE is the right choice: besides >> resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and >> LCR, which would corrupt a character still being shifted out. (Linux >> waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT >> already implies THRE.) >> >> The unbounded wait can hang early Xen boot if the UART never reports >> TEMT for some reason(?). Bounding the wait would make console >> initialization more robust, allowing boot to continue when the UART is >> unavailable >> >> for ( i = 0; i < 50000; i++ ) >> { >> if ( ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT ) >> break; >> udelay(10); >> } >> >> would need udelay() on RISC-V, which is still a BUG_ON() stub, so a >> separate patch would be needed for that. On x86, udelay() doesn't delay >> yet at this point (cpu_khz is only set by early_time_init()), so there >> the loop would just be an iteration count. Perhaps someone has a better >> idea of how to implement a timeout here. > > Whatever it is, it's going to be more or less crude. See e.g. Marek's > solution for a similar issue (yet to be committed): > https://lists.xen.org/archives/html/xen-devel/2026-10/msg00439.html I am perfectly okay with the way suggested by Marek. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:27:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:27:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446325.1662437 (Exim 4.92) (envelope-from ) id 1xGG3r-0004Uo-W8; Mon, 12 Oct 2026 13:27:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446325.1662437; Mon, 12 Oct 2026 13:27: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 1xGG3r-0004Uh-T0; Mon, 12 Oct 2026 13:27:27 +0000 Received: by outflank-mailman (input) for mailman id 1446325; Mon, 12 Oct 2026 13:27:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGG3r-0004UZ-25 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:27:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGG3q-00FYhN-F7 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:27:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce030-e002-0a2a0a5209dd-0a2a450bd6cc-46 for ; Mon, 12 Oct 2026 15:27:26 +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 6acce03d-b7e8-0a2a450b0019-b9ff1c22b595-3 for ; Mon, 12 Oct 2026 15:27: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1304beaaa00080d7.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:27:24 +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 043E8804EE; Mon, 12 Oct 2026 15:27:23 +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=EFNKMyIy5Fpjf5Xqfq4As6aZwcB1BCpuczevb8LKC/o=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=MNWiX6hglGuLFEczuspNusLnqKkVdoHc5G44R9stLsNuLpK+RYiKuAufRuFm8ugw34s+wezxB 2NBf/DOg5RokZVTZ7zsCQdGqCYhf/krgcdlg23mTISzUrYZ53p4vasqskofar2CNbtwcD9pwArL cchLMfTRYVPzcY2a0OQmLKlMdhnW4f6iPf1FeVS7y0oanaVhmEFpUY3FaqNqOUE325tQQK6RCva 8CA4ZtQRqWEnkFSGZtn8Umgi2lrG/5z9Z5pXb6Mt/KBdJnmhB7wWW0ybUKEfZ1uXq85aa4CeeJa aiPudvAeH4rXqKFYUrh7tFt/kBB2VWeJmPBMQmP4zApg== X-Zone-Loop: 441f2a207fcbe493bf92bb392b34d2789b5350fcebb8 x-campaign-type: default x-transaction-id: 87acc4cc-5b84-491b-8f9c-d6596bbb3585 x-swg-uid: 01-aa6d9334-8ca0-4a5a-b436-d3952a1b240f X-Mailer: Sweego Message-ID: <1791811644.8631fc262581453bbf619ec5b2062170.1a1304beaaa00080d7@vates.tech> x-swg-bid: 1791811644.8631fc262581453bbf619ec5b2062170.1a1304beaaa00080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 12 Oct 2026 15:27:22 +0200 From: Anthony PERARD To: Matthias Goergens Cc: xen-devel@lists.xenproject.org Subject: Re: [PATCH] tools/xentop: reject invalid --delay and --iterations arguments References: <20260805135521.790750-1-matthias.goergens@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260805135521.790750-1-matthias.goergens@gmail.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.fd.e2cc01512bd5603f.1a1304be6c6.393d4994110ca2b7=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791811643079 X-purgate-ID: tlsNG-42698a/1791811646-AB4D39EA-7B152B40/0/0 X-purgate-type: clean X-purgate-size: 2674 ---=Part.fd.e2cc01512bd5603f.1a1304be6c6.393d4994110ca2b7=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 05, 2026 at 09:55:21PM +0800, Matthias Goergens wrote: > xentop parses -d/--delay and -i/--iterations with atoi(), so invalid > input is silently accepted with surprising results: a fractional delay > such as "-d 2=2E5" is truncated to 2; "-d abc" parses as 0, which in > batch mode turns the output loop into a busy loop; "-d -1" wraps to an > effective delay of about 136 years; and "-i 0" (or any unparsable > iterations count) decrements an unsigned counter from zero, running > for about 2^32 iterations=2E atoi() also has undefined behaviour on > out-of-range input=2E >=20 > Parse both options with strtoull() instead, and reject anything that > is not a plain decimal integer in range: a sign, a fractional part, > trailing junk or overflow now produce an error and exit rather than a > silently wrong value=2E >=20 > Compatibility considerations: "--delay 0" remains accepted, since > updating as fast as possible is a plausible deliberate choice and > works today; "--iterations 0" is rejected, since running the loop > 2^32 times cannot be what the caller meant=2E The interactive 'D' > prompt already validates its input and is unchanged=2E The only > previously useful invocation this breaks is a fractional delay, which > now fails loudly instead of silently rounding down - which is the > point of the change=2E >=20 > A patch documenting the --delay truncation was posted in 2010 but > never applied: > Link: https://lore=2Ekernel=2Eorg/xen-devel/01ea26d2420e3562eb30=2E12926= 04768@chilopoda=2Euk=2Exensource=2Ecom/ >=20 > Signed-off-by: Matthias Goergens > --- > Tested by compiling with -Wall -Wextra (no new warnings) and by running > the parse helper, extracted verbatim from the patched file, against a > 19-case input matrix covering both the accepted and the rejected inputs > listed above=2E Not run against a live Xen host: the change is confined > to command line parsing, ahead of any hypervisor interaction=2E >=20 > Happy to add a CHANGELOG=2Emd entry under "Changed" if that is wanted fo= r > a tools CLI change of this size=2E No, I don't think it's necessary, this patch is just error handling, and a bit of clarification I suppose=2E Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.fd.e2cc01512bd5603f.1a1304be6c6.393d4994110ca2b7=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:36:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:36:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446339.1662447 (Exim 4.92) (envelope-from ) id 1xGGBt-0006WE-Pj; Mon, 12 Oct 2026 13:35:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446339.1662447; Mon, 12 Oct 2026 13:35: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 1xGGBt-0006W7-Kj; Mon, 12 Oct 2026 13:35:45 +0000 Received: by outflank-mailman (input) for mailman id 1446339; Mon, 12 Oct 2026 13:35:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGGBs-0006W0-8G for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:35:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGBq-006NAk-Vx for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:35:43 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce22c-2eae-0a2a0a5409dd-0a2a45028e3a-10 for ; Mon, 12 Oct 2026 15:35: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 6acce22e-6ca4-0a2a45020019-b9ff1c23961b-3 for ; Mon, 12 Oct 2026 15:35: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 1a13053793100080d7.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:35:39 +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 8041582A96; Mon, 12 Oct 2026 15:35:38 +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=Y65q1HDGpq+Awp/6IP3p7ukxpLUb7B0aWyCpKMQZG1M=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=HRMEzxSa7Z44jrj/HXZPJD7DcjD0nemjwMTCHNB1QiHTuKuuBHiXTdM3zzSiYfLUJGhZ14Xu1 w16+WZ/AYID9zKTpIz1GG9AjdFuDebtmePylSHiaa7cXj3XG0ZLChsS6mBaboa1SM6D0Hg9tR8B aBlnqZ4uiKpjK40/SKdc0EXqw/XLxvYNDs7Wy8fiEsB177wya1CSkSx7pI8xS6C260qaIfDa9x+ ISbrOx+ZIUp7/UBagcH/9ZDxOwa9XqdjZxGeBegNoyQdUB3fRnpVl2bqU0Yszjl7pK/sSwSKqDJ xaMi50qtP3q7IPiSom6AXdOdwXIm+zbpLszRjf7Pc1Aw== X-Zone-Loop: 6042c7b0bc1fce8ea1e725b98d9d74ca3d3b676f268c x-campaign-type: default x-transaction-id: 16b9a213-4e0b-4ab8-98ee-aa9ac050bdbc x-swg-uid: 01-ab7f1dbc-cd2d-46b4-92e0-c5b054c5bd53 X-Mailer: Sweego Message-ID: <1791812139.8631fc262581453bbf619ec5b2062170.1a13053793100080d7@vates.tech> x-swg-bid: 1791812139.8631fc262581453bbf619ec5b2062170.1a13053793100080d7 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 12 Oct 2026 15:35:38 +0200 From: Anthony PERARD To: Andrew Mbugua Cc: xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH] tools/console/daemon: fix log_dir memory leak in xenconsoled References: <20260813212724.2607832-1-andrewprecious388@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260813212724.2607832-1-andrewprecious388@gmail.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.fe.c59c22f6307d81e.1a130537656.7743c531264b367d=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791812138583 X-purgate-ID: tlsNG-720697/1791812142-30BC02AC-4278E72E/0/0 X-purgate-type: clean X-purgate-size: 1523 ---=Part.fe.c59c22f6307d81e.1a130537656.7743c531264b367d=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 14, 2026 at 12:27:23AM +0300, Andrew Mbugua wrote: > Valgrind reports that 21 bytes are "still reachable" from the (XEN_LOG_D= IR "/console") allocation: >=20 > HEAP SUMMARY: > in use at exit: 21 bytes in 1 blocks > total heap usage: 9 allocs, 8 frees, 4,799 bytes allocated >=20 > Since the dynamic memory allocation for the default log directory path h= appens before the process > forks into the background, the parent and intermediate processes exit du= ring daemonize() > with the memory still reachable=2E >=20 > Move the strdup() allocation down below the daemonize() block=2E This en= sures only the final > background daemon allocates the default path, matching the lifetime of t= he free(log_dir) > cleanup loop at the exit of main()=2E >=20 > With this change, Valgrind reports a clean heap summary >=20 > HEAP SUMMARY: > in use at exit: 0 bytes in 0 blocks > total heap usage: 8 allocs, 8 frees, 4,778 bytes allocated >=20 > Signed-off-by: Andrew Mbugua Reviewed-by: Anthony PERARD I'll try to remember to fix the indentation on commit=2E Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.fe.c59c22f6307d81e.1a130537656.7743c531264b367d=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:36:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:36:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446344.1662455 (Exim 4.92) (envelope-from ) id 1xGGCu-00074e-36; Mon, 12 Oct 2026 13:36:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446344.1662455; Mon, 12 Oct 2026 13: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 1xGGCu-00074X-0G; Mon, 12 Oct 2026 13:36:48 +0000 Received: by outflank-mailman (input) for mailman id 1446344; Mon, 12 Oct 2026 13:36:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGGCs-00074N-Ix for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:36:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGCr-005hPv-Kr for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:36:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce266-8faa-0a2a0a5109dd-0a2a45059436-28 for ; Mon, 12 Oct 2026 15:36:45 +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 6acce26d-4cb1-0a2a45050019-b9ff1c23a931-3 for ; Mon, 12 Oct 2026 15:36: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a13054627300080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:36:39 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 4959682A40; Mon, 12 Oct 2026 15:36:37 +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=50Mgym9OX6V13CDIzVYNCyk8IJEkPQKAgU4UfPE2DeQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=haI4p/0/lD7Z23V+98CJaMnCpPfMQURKf9eslfe1OTePCXmcJkEhsNiHHgDyLltzeSVpd8uGY v0D8xup6bnUFqLboXsoetmsv5qNUazP7mRqMgEmSme9M5Z9xe/UnILIFj9M95sCsYO6x88O3Lnp e13svS2iJgiVLrsjHcwxGCwO/7WxUEtv/0L00adDJ3GKf78OYI8te5bBQ/+zXEyrvmwhxrJqpEN ZuvRaBiLRfaxXxn+LUHnNT9AvcKDJlbgaHWX4BkQqGmZf/sNFK27UrnrhYvJzTQGCZAL3umreCQ tMbXlqBpaExTj0C+1rrr6kM3WXEwcU7hVpED8Z/ntrYA== X-Zone-Loop: 7ba81f3a49fa356b68fda4f0157d80d9facdd97fd540 x-campaign-type: default x-transaction-id: d82ce4e0-6a47-42a0-8869-9cf0a87faf8f x-swg-uid: 01-3cae287e-f71e-4278-b57f-f080bc2f5f39 X-Mailer: Sweego Message-ID: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> x-swg-bid: 1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7 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 v7 0/5] Fix ARM domcreate Date: Mon, 12 Oct 2026 15:36:30 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.ff.847a8b894d3f4814.1a130545f9f.35a900a5b2e69665=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791812198308 X-purgate-ID: tlsNG-c201ff/1791812205-F58AE2A1-26720C8B/0/0 X-purgate-type: clean X-purgate-size: 3384 ---=Part.ff.847a8b894d3f4814.1a130545f9f.35a900a5b2e69665=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Michal and Anthony, thank you for the reviews and acks! Michal, I have addressed your remaining remarks on the "xen/arm: report clock_frequency via sysctl physinfo, not createdomain" patch=2E The golang bindings are regenerated for the new arm_clock_frequency_hz physinfo field, and alloc_domaininfo() no longer references the removed clock_frequency field=2E Apart from that I have collected the Acked-by/Reviewed-by tags=2E Signed-off-by: Julian Vetter Andrew Cooper (1): ARM/sysctl: Expose the supported guest GIC modes in physinfo Julian Vetter (4): 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 | 4 +- tools/golang/xenlight/helpers=2Egen=2Ego | 2 + tools/golang/xenlight/types=2Egen=2Ego | 1 + =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 31 ++++++++ tools/libs/light/libxl=2Ec | 1 + tools/libs/light/libxl_arm=2Ec | 72 +++++++++++++++++-- tools/libs/light/libxl_types=2Eidl | 1 + tools/ocaml/libs/xc/xenctrl=2Eml | 1 - tools/ocaml/libs/xc/xenctrl=2Emli | 1 - tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 5 +- tools/python/xen/lowlevel/xc/xc=2Ec | 18 ++++- xen/arch/arm/dom0less-build=2Ec | 3 +- xen/arch/arm/domain=2Ec | 32 ++++----- xen/arch/arm/domain_build=2Ec | 3 +- xen/arch/arm/firmware/sci=2Ec | 2 +- xen/arch/arm/firmware/scmi-smc=2Ec | 2 +- xen/arch/arm/gic=2Ec | 15 ++++ 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 | 34 +++++++++ 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 +- 35 files changed, 269 insertions(+), 83 deletions(-) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.ff.847a8b894d3f4814.1a130545f9f.35a900a5b2e69665=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:42:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:42:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446351.1662464 (Exim 4.92) (envelope-from ) id 1xGGIL-0000hH-Je; Mon, 12 Oct 2026 13:42:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446351.1662464; Mon, 12 Oct 2026 13: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 1xGGIL-0000hA-Gl; Mon, 12 Oct 2026 13:42:25 +0000 Received: by outflank-mailman (input) for mailman id 1446351; Mon, 12 Oct 2026 13:42:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGGIK-0000h4-Ci for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:42:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGIJ-009ha2-M7 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:42:23 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce3b6-e002-0a2a0a5209dd-0a2a450acd4e-18 for ; Mon, 12 Oct 2026 15:42:23 +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 6acce3bf-f2d2-0a2a450a0019-b9ff1c2292e3-3 for ; Mon, 12 Oct 2026 15:42: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 1a13059877700080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:42:16 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 8272D81F5A; Mon, 12 Oct 2026 15:42: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=X+b4k+uF2NrhkeaYq3dimEX6GppPVUx53ce+alrovl4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=EmiJTD6ODpisKl3BLSMWfSbEdswZL3voKGWCX+1JgiVIt0a52tFsAJWOTpMw08f1zPCd1IhVR xwLZN3EO/gVKzXH7oyrQnPkuUQeC4sxfKE0mkv0/GkP7sFI/sWMQfcjZSkJEGu9eOtdnnH6CEXz LT773/Tq8ujXpxwHVWtLfame94cfeA3ZiDwdzkG8vc5GiW4yPcTzS4KtpzFksyIX6b/roRyMwkU EraJaoKLjfU6oV8OYFXyP1t1WPZ0dtkCqkWgOE+st2pUrYrXS6bUiMpz2sWdGxn2K9mqBEhKgc1 BMYNXgbtVjzHhSdYFbhwXr7tIXP+QGeqrBNgY7Tjoe4g== X-Zone-Loop: 1e1f175b6265e7c988b0c99d97c3225543c7be22e922 x-campaign-type: default x-transaction-id: 8ca4b632-d294-4f2d-a34d-cf94d55312fa x-swg-uid: 01-ec7289c3-3981-4fd6-94db-5c387ec94c2b X-Mailer: Sweego Message-ID: <1791812536.8631fc262581453bbf619ec5b2062170.1a13059877700080d7@vates.tech> x-swg-bid: 1791812536.8631fc262581453bbf619ec5b2062170.1a13059877700080d7 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 v7 1/5] ARM/sysctl: Expose the supported guest GIC modes in physinfo Date: Mon, 12 Oct 2026 15:42:03 +0200 In-Reply-To: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> References: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.100.558abb92fbeb9986.1a1305984eb.fd3d3a520decdccd=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791812535532 X-purgate-ID: tlsNG-4011c0/1791812543-59DDFCFC-468997AD/0/0 X-purgate-type: clean X-purgate-size: 4977 ---=Part.100.558abb92fbeb9986.1a1305984eb.fd3d3a520decdccd=- 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 Reviewed-by: Michal Orzel --- Changes in v7: - No changes=2E --- xen/arch/arm/include/asm/vgic=2Eh | 6 ++++++ xen/arch/arm/sysctl=2Ec | 29 +++++++++++++++++++++++++++++ xen/arch/arm/vgic-v2=2Ec | 5 +++++ xen/arch/arm/vgic/vgic-v2=2Ec | 5 +++++ xen/include/public/sysctl=2Eh | 2 ++ 5 files changed, 47 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=2E8de4027b9c 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,31 @@ 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); + + 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; + + default: + /* + * 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 + */ + printk_once(XENLOG_ERR "Unrecognised GIC version %d\n", + gic_hw_version()); + ASSERT_UNREACHABLE(); + 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 63d0ee062b=2E=2Ea1216d7287 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.100.558abb92fbeb9986.1a1305984eb.fd3d3a520decdccd=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:42:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:42:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446352.1662473 (Exim 4.92) (envelope-from ) id 1xGGIP-0000uJ-Qc; Mon, 12 Oct 2026 13:42:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446352.1662473; Mon, 12 Oct 2026 13: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 1xGGIP-0000uC-NR; Mon, 12 Oct 2026 13:42:29 +0000 Received: by outflank-mailman (input) for mailman id 1446352; Mon, 12 Oct 2026 13:42:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGGIN-0000tb-Mc for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:42:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGIN-009ha2-38 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:42:27 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce3b6-e002-0a2a0a5209dd-0a2a450acd4e-30 for ; Mon, 12 Oct 2026 15:42:27 +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 6acce3bf-f2d2-0a2a450a0019-b9ff1c2292e3-4 for ; Mon, 12 Oct 2026 15:42: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a130598c4300080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:42:17 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id E02D082A40; Mon, 12 Oct 2026 15:42: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=OQH8vM9AX9boPDt2rVv6oexA1hK9DmhNiTGZaa/4p6U=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=gvsTUCcPSgFRuN9Zs7HkRJ/0DdX829q20XhOPW/2RjQEavWVcGebuIRnIVDwcLenvLlZjG4LN SXxBlGFS1Bfv3byumWGNMNywzMvhV8P/GVuM/gGSYCLgPZZJ0IjTpd4XN3WPjG/EOl6xNPd0xpk xJz/5qlrehursNj+LRfcxssjw647bb1bpYfiZSCHMtxp85as+u7/o6vLiY0vFqlW8Ci+LVzobQg M1h9xFBBefyuDXSTVpvgA2mR0w3MoWrDY/HYcMVninFZe7+SzDHgh2iZk+JVL9MtlBUGATwVMO2 tamOSiOu1s9Ui/oPSzjXYzH3O5NO1eJA9zdyzpqi4VBQ== X-Zone-Loop: 0b24c2a16b9aae74f6bdebf5a5bf2e238c2887953fbb x-campaign-type: default x-transaction-id: 88a58fcc-c8f9-4fe2-b7e6-c9b8e47bbb78 x-swg-uid: 01-78aabbe3-329b-404f-8c9b-d8eea0f7bdc4 X-Mailer: Sweego Message-ID: <1791812537.8631fc262581453bbf619ec5b2062170.1a130598c4300080d7@vates.tech> x-swg-bid: 1791812537.8631fc262581453bbf619ec5b2062170.1a130598c4300080d7 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 v7 2/5] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE Date: Mon, 12 Oct 2026 15:42:04 +0200 In-Reply-To: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> References: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.101.496efd8cccc2d247.1a130598a37.9d32a5d92b62309f=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791812536887 X-purgate-ID: tlsNG-4011c0/1791812546-50CCBCFC-B234A89E/0/0 X-purgate-type: clean X-purgate-size: 8130 ---=Part.101.496efd8cccc2d247.1a130598a37.9d32a5d92b62309f=- 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 LIBXL_GIC_VERSION_DEFAULT keeps its name and value: xl=2Ecfg still accepts "default" as the C keyword, and setdefault() resolves it to a concrete v2/v3 before anything else can observe it=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 Acked-by: Michal Orzel Acked-by: Anthony PERARD --- Changes in v7: - Added Acked-by --- docs/man/xl=2Ecfg=2E5=2Epod=2Ein | 4 +- =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 21 +++++++++ tools/libs/light/libxl_arm=2Ec | 43 +++++++++++++++++-- tools/python/xen/lowlevel/xc/xc=2Ec | 18 +++++++- 4 files changed, 80 insertions(+), 6 deletions(-) diff --git a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein b/docs/man/xl=2Ecfg=2E5=2Epo= d=2Ein index d34951edb9=2E=2E8daa9be123 100644 --- a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein +++ b/docs/man/xl=2Ecfg=2E5=2Epod=2Ein @@ -3083,8 +3083,8 @@ GICv2 compatibility mode=2E =20 =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 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=2Eb9c0c820d6 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; @@ -1794,12 +1791,52 @@ int libxl__arch_domain_build_info_setdefault(libxl= __gc *gc, libxl_domain_build_info *b_i= nfo, const libxl_physinfo *physin= fo) { + bool has_v3 =3D arch_capabilities_arm_gic_v3(physinfo->arch_capabilit= ies); + bool has_v2 =3D arch_capabilities_arm_gic_v2(physinfo->arch_capabilit= ies); + /* ACPI is disabled by default */ libxl_defbool_setdefault(&b_info->acpi, false); =20 /* 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 + */ + switch (b_info->arch_arm=2Egic_version) { + case LIBXL_GIC_VERSION_DEFAULT: + 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 host"); + return ERROR_FAIL; + } + break; + + case LIBXL_GIC_VERSION_V2: + if (!has_v2) { + LOG(ERROR, "GICv2 requested but not supported on this host"); + return ERROR_FAIL; + } + break; + + default: + LOG(ERROR, "Unknown GIC version %d", b_info->arch_arm=2Egic_versi= on); + return ERROR_FAIL; + } + /* Sanitise SVE parameter */ if (b_info->arch_arm=2Esve_vl) { unsigned int max_sve_vl =3D 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.101.496efd8cccc2d247.1a130598a37.9d32a5d92b62309f=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:42:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:42:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446353.1662482 (Exim 4.92) (envelope-from ) id 1xGGIS-00018h-6L; Mon, 12 Oct 2026 13:42:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446353.1662482; Mon, 12 Oct 2026 13:42: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 1xGGIS-00018V-3X; Mon, 12 Oct 2026 13:42:32 +0000 Received: by outflank-mailman (input) for mailman id 1446353; Mon, 12 Oct 2026 13:42:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGGIR-00017j-HK for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:42:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGIQ-00A7ls-Ee for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:42:30 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce3ab-8faa-0a2a0a5109dd-0a2a45069fa8-44 for ; Mon, 12 Oct 2026 15:42:30 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acce3c6-195a-0a2a45060019-b9ff1c12ab23-3 for ; Mon, 12 Oct 2026 15:42: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a13059924000080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:42:18 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 25BC182A96; Mon, 12 Oct 2026 15:42: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=O2VTC+yP2YOt/OhkF88PAQ4v3E5ksDR5U6kM09FQen8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=OlQW1M12W1VDMcch/rBWLcdPO/h+aw38Gr7V1jE7+s7vpj3ngkMwNisUr0Gu1b+/UNbyS8Rq8 1WG+ATcMPPWv2GjqJzXeHLHaxJu3EkMRcHQYQj7Ww0dRua5Po7/BbO0f4GQGHIWHNOCIwyXjpTc KymEGhCwGEcHokTWEqKxrVB0z2m9prI9f1kHxmZ4n7aI1JadZefV1n+EOr2oUkG5nfkgMP2pv15 a2gC0zlWdJCxpVoDczEZApdyhHxgKamoLt2EDSKkg9zjW9i3cDNADgTQYwoL0Jh9vd5L152dyqG +lbJcLpSJ0DWz2bavFMc5D2lWZqfG8JruPg+JOxAs/kQ== X-Zone-Loop: 3ff3d7fa2ff6a852b65b7e85c4c49ee2af7cfeeb8f09 x-campaign-type: default x-transaction-id: 4ade6ad1-0aa6-4e76-acde-b7b0b3acdf2b x-swg-uid: 01-e5d91ea6-1626-4e55-b119-690b8605d706 X-Mailer: Sweego Message-ID: <1791812539.8631fc262581453bbf619ec5b2062170.1a13059924000080d7@vates.tech> x-swg-bid: 1791812539.8631fc262581453bbf619ec5b2062170.1a13059924000080d7 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 v7 3/5] xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from the ABI Date: Mon, 12 Oct 2026 15:42:05 +0200 In-Reply-To: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> References: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.102.c106891303bb835f.1a130598f0b.cef2ada3e5cbdbb2=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791812538123 X-purgate-ID: tlsNG-16d1c6/1791812550-1F4C977B-AB5069DD/0/0 X-purgate-type: clean X-purgate-size: 8437 ---=Part.102.c106891303bb835f.1a130598f0b.cef2ada3e5cbdbb2=- 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 Reviewed-by: Michal Orzel --- Changes in v7: - Added Reviewed-by --- CHANGELOG=2Emd | 4 ++++ xen/arch/arm/dom0less-build=2Ec | 3 ++- xen/arch/arm/domain=2Ec | 28 ++++++++++++---------------- xen/arch/arm/domain_build=2Ec | 3 ++- xen/arch/arm/gic=2Ec | 15 +++++++++++++++ xen/arch/arm/include/asm/gic=2Eh | 6 ++++++ xen/include/public/arch-arm=2Eh | 4 ++-- 7 files changed, 43 insertions(+), 20 deletions(-) diff --git a/CHANGELOG=2Emd b/CHANGELOG=2Emd index a2dd01037b=2E=2E225397f128 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=2E5678ee3fe0 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 = */ @@ -634,6 +629,7 @@ int arch_sanitise_domain_config(struct xen_domctl_crea= tedomain *config) if ( max_vcpus =3D=3D 0 ) { dprintk(XENLOG_INFO, "Unsupported GIC version\n"); + ASSERT_UNREACHABLE(); return -EINVAL; } =20 diff --git a/xen/arch/arm/domain_build=2Ec b/xen/arch/arm/domain_build=2Ec index 795b401087=2E=2E8cc5ac91f8 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 @@ -1967,7 +1968,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 0e96def2d0=2E=2Ec4bda435bd 100644 --- a/xen/arch/arm/gic=2Ec +++ b/xen/arch/arm/gic=2Ec @@ -56,6 +56,21 @@ 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: + BUG(); + } +} + 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 33dca9dcc6=2E=2E9af05da6aa 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 + */ +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=2E44c26fdc38 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 @@ -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; --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.102.c106891303bb835f.1a130598f0b.cef2ada3e5cbdbb2=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:42:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:42:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446354.1662491 (Exim 4.92) (envelope-from ) id 1xGGIX-0001QA-EQ; Mon, 12 Oct 2026 13:42:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446354.1662491; Mon, 12 Oct 2026 13:42: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 1xGGIX-0001Q3-Am; Mon, 12 Oct 2026 13:42:37 +0000 Received: by outflank-mailman (input) for mailman id 1446354; Mon, 12 Oct 2026 13:42:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGGIV-0001O7-GO for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:42:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGIU-004fuy-TS for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:42:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce3c1-2eae-0a2a0a5409dd-0a2a4501b832-34 for ; Mon, 12 Oct 2026 15:42: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 6acce3ca-5984-0a2a45010019-b9ff1c229cbf-3 for ; Mon, 12 Oct 2026 15:42: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 1a13059965e00080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:42:20 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 8759A82A40; Mon, 12 Oct 2026 15:42: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=a85r6Fs5csjfSABROt+SSPYoVpP3mVzgWm4LPVUti10=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=WgcM9hr0PHohlWrp3EoXCEvJ+xx74ctCvd717O/hLDV/42Jd/I6qpDocy8ueZ2RN6lKjGiltF hJwp2EhdQpDkalvBJEFr3ARFwIPVN8wGoC74AQsqWmBEfN/snNIeEbq0HU2EMtrijuYvOmUp9fY zTkRpD6ni5pX3WSrYn3n5enYBiClqzgmnIbbzcNJAxRc/iyUHyXl3jewzBjD9Czvs0wovESU3sn 9VrBIJZlkllaKpUGIygZwAT+F4bqYahhkK5me/EWLkTlI6lgaR5SiMv4WhaLrMdGddGatctCSPc qTg2NTV3hZ501ekzOsLdmHYlfMIv97p9kPVDaXL5esZA== X-Zone-Loop: 212d3c41c70e298f87fcf316de77e1fbd2991700bd2d x-campaign-type: default x-transaction-id: 70b243b9-2463-4ac8-beb1-1bbd3d6f5507 x-swg-uid: 01-eadd6832-b05b-431f-bd83-5d0160bbf3b7 X-Mailer: Sweego Message-ID: <1791812540.8631fc262581453bbf619ec5b2062170.1a13059965e00080d7@vates.tech> x-swg-bid: 1791812540.8631fc262581453bbf619ec5b2062170.1a13059965e00080d7 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 v7 4/5] xen/arm: report clock_frequency via sysctl physinfo, not createdomain Date: Mon, 12 Oct 2026 15:42:06 +0200 In-Reply-To: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> References: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.103.56b182b31978e00e.1a1305994ae.6681578bd2ebe370=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791812539566 X-purgate-ID: tlsNG-d62444/1791812554-BD87F757-B77BD620/0/0 X-purgate-type: clean X-purgate-size: 18846 ---=Part.103.56b182b31978e00e.1a1305994ae.6681578bd2ebe370=- 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 arm_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 arm_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 Reviewed-by: Michal Orzel Reviewed-by: Anthony PERARD --- Changes in v7: - Regenerated the golang bindings for the arm_clock_frequency_hz field - Dropped clock_frequency from alloc_domaininfo() - Added Reviewed-by --- tools/golang/xenlight/helpers=2Egen=2Ego | 2 ++ tools/golang/xenlight/types=2Egen=2Ego | 1 + =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 10 +++++++ tools/libs/light/libxl=2Ec | 1 + tools/libs/light/libxl_arm=2Ec | 29 +++++++++++++++++-- tools/libs/light/libxl_types=2Eidl | 1 + tools/ocaml/libs/xc/xenctrl=2Eml | 1 - tools/ocaml/libs/xc/xenctrl=2Emli | 1 - tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 5 +--- 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 | 14 --------- xen/include/public/domctl=2Eh | 4 +-- xen/include/public/sysctl=2Eh | 20 ++++++++++++- 18 files changed, 81 insertions(+), 38 deletions(-) diff --git a/tools/golang/xenlight/helpers=2Egen=2Ego b/tools/golang/xenli= ght/helpers=2Egen=2Ego index b0c09da910=2E=2E689e7398b1 100644 --- a/tools/golang/xenlight/helpers=2Egen=2Ego +++ b/tools/golang/xenlight/helpers=2Egen=2Ego @@ -3702,6 +3702,7 @@ x=2ECapVpmu =3D bool(xc=2Ecap_vpmu) x=2ECapGnttabV1 =3D bool(xc=2Ecap_gnttab_v1) x=2ECapGnttabV2 =3D bool(xc=2Ecap_gnttab_v2) x=2EArchCapabilities =3D uint32(xc=2Earch_capabilities) +x=2EArmClockFrequencyHz =3D uint32(xc=2Earm_clock_frequency_hz) =20 return nil} =20 @@ -3737,6 +3738,7 @@ xc=2Ecap_vpmu =3D C=2Ebool(x=2ECapVpmu) xc=2Ecap_gnttab_v1 =3D C=2Ebool(x=2ECapGnttabV1) xc=2Ecap_gnttab_v2 =3D C=2Ebool(x=2ECapGnttabV2) xc=2Earch_capabilities =3D C=2Euint32_t(x=2EArchCapabilities) +xc=2Earm_clock_frequency_hz =3D C=2Euint32_t(x=2EArmClockFrequencyHz) =20 return nil } diff --git a/tools/golang/xenlight/types=2Egen=2Ego b/tools/golang/xenligh= t/types=2Egen=2Ego index e0fd78ec03=2E=2E5a40583079 100644 --- a/tools/golang/xenlight/types=2Egen=2Ego +++ b/tools/golang/xenlight/types=2Egen=2Ego @@ -1149,6 +1149,7 @@ CapVpmu bool CapGnttabV1 bool CapGnttabV2 bool ArchCapabilities uint32 +ArmClockFrequencyHz uint32 } =20 type Connectorinfo struct { 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=2E98c7f0fdb3 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->arm_clock_frequency_hz =3D xcphysinfo=2Earm_clock_frequency= _hz; =20 GC_FREE; return 0; diff --git a/tools/libs/light/libxl_arm=2Ec b/tools/libs/light/libxl_arm= =2Ec index b9c0c820d6=2E=2E47b662ea5c 100644 --- a/tools/libs/light/libxl_arm=2Ec +++ b/tools/libs/light/libxl_arm=2Ec @@ -252,6 +252,16 @@ 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; + + libxl_physinfo_init(&info); + rc =3D libxl_get_physinfo(CTX, &info); + if (rc) { + LOG(ERROR, "failed to get physinfo"); + goto out; + } + 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; @@ -261,12 +271,25 @@ int libxl__arch_domain_save_config(libxl__gc *gc, break; default: LOG(ERROR, "Unexpected gic version %u", config->arch=2Egic_versio= n); - return ERROR_FAIL; + rc =3D ERROR_FAIL; + goto out; } =20 - state->clock_frequency =3D config->arch=2Eclock_frequency; + /* + * 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=2Earm_clock_frequency_hz; + else + state->clock_frequency =3D 0; =20 - return 0; + rc =3D 0; +out: + libxl_physinfo_dispose(&info); + + return rc; } =20 int libxl__arch_domain_create(libxl__gc *gc, diff --git a/tools/libs/light/libxl_types=2Eidl b/tools/libs/light/libxl_t= ypes=2Eidl index a7893460f0=2E=2E4284a4f577 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), + ("arm_clock_frequency_hz", uint32), ], 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/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index 4a45a31c28=2E=2E180f2fbf45 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -449,13 +449,10 @@ static value alloc_domaininfo(xc_domaininfo_t * info= ) tag =3D 0; /* tag ARM */ =20 /* xen_arm_arch_domainconfig */ - arch_config =3D caml_alloc_tuple(3); + arch_config =3D caml_alloc_tuple(2); Field(arch_config, 0) =3D Val_int(info->arch_config=2Egic_version); Field(arch_config, 1) =3D Val_int(info->arch_config=2Enr_spis); =20 - tmp =3D caml_copy_int32(info->arch_config=2Eclock_frequency); - Field(arch_config, 2) =3D tmp; - #elif defined(__i386__) || defined(__x86_64__) =20 tag =3D 1; /* tag x86 */ diff --git a/xen/arch/arm/domain=2Ec b/xen/arch/arm/domain=2Ec index 5678ee3fe0=2E=2E4ca3a3749f 100644 --- a/xen/arch/arm/domain=2Ec +++ b/xen/arch/arm/domain=2Ec @@ -714,7 +714,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 8de4027b9c=2E=2Ecc42d1b532 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->arm_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; + switch ( gic_hw_version() ) { case GIC_V2: diff --git a/xen/arch/arm/time=2Ec b/xen/arch/arm/time=2Ec index ccfb76e20f=2E=2E295afa685a 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 @@ -130,7 +131,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 @@ -146,7 +148,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 44c26fdc38=2E=2E5d15f572c7 100644 --- a/xen/include/public/arch-arm=2Eh +++ b/xen/include/public/arch-arm=2Eh @@ -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 a1216d7287=2E=2E6f9b1624ad 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 arm_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 arm_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.103.56b182b31978e00e.1a1305994ae.6681578bd2ebe370=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:42:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:42:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446355.1662500 (Exim 4.92) (envelope-from ) id 1xGGIZ-0001hF-RI; Mon, 12 Oct 2026 13:42:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446355.1662500; Mon, 12 Oct 2026 13:42: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 1xGGIZ-0001h4-O0; Mon, 12 Oct 2026 13:42:39 +0000 Received: by outflank-mailman (input) for mailman id 1446355; Mon, 12 Oct 2026 13:42:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGGIY-0001YS-8q for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:42:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGIX-00GP0q-Lk for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:42:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce3c1-2eae-0a2a0a5409dd-0a2a4501b832-48 for ; Mon, 12 Oct 2026 15:42:37 +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 6acce3ca-5984-0a2a45010019-b9ff1c229cbf-4 for ; Mon, 12 Oct 2026 15:42: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 1a130599b7500080d7.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 12 Oct 2026 13:42:21 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id BF5FB82ABB; Mon, 12 Oct 2026 15:42: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=HDu/Fw7oeKygRixM8HOEunsHyOEsS5YFjTMxW4Jmr/w=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=VvwNwPvbMu8yMw2VFlBG0Vkfvbs7vk+s7lWnt8hJyph7jK+SdavHCYHUuPBTogj2tJz82x7SE M+9Qa6bZ57Ul4WwEtgdaiJ0fDxHnCy3dUl+527A5m/xVlEZvWMvCnM3Z8teUo17ffzlQIWli9Mb OflPIaXG6ypR3VNfWYlLJCeZZ7N1cGxpZS3khg8f6Th20GVKrr54PTZ/ueBXMV4KQso6Sqj1tj1 liKcEsZLt0DQ/wTeUCA7wvAwE/ZhG1yI0+SpEnQ4dOsQMhrVCpCuGwIbiZ9HKGAD49xh4mHPF1T v/R5vUaokdGSmEHixoen64Ft6N0c9rSFQu0J7B3Du4TA== X-Zone-Loop: f91de126b8f844e3aa5de818495f828789c1b314360d x-campaign-type: default x-transaction-id: 160b10c5-2321-4789-93c5-6d90ae55376a x-swg-uid: 01-a4bd44e3-41d2-488b-ae1b-997e74e84669 X-Mailer: Sweego Message-ID: <1791812541.8631fc262581453bbf619ec5b2062170.1a130599b7500080d7@vates.tech> x-swg-bid: 1791812541.8631fc262581453bbf619ec5b2062170.1a130599b7500080d7 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 v7 5/5] xen: make config argument const Date: Mon, 12 Oct 2026 15:42:07 +0200 In-Reply-To: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> References: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.104.ec8451bfddb2c110.1a130599957.6665c0d17a0b07b8=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791812540759 X-purgate-ID: tlsNG-d62444/1791812557-1F262757-C5FEA3D5/10/78276251493 X-purgate-type: spam X-purgate-size: 8367 ---=Part.104.ec8451bfddb2c110.1a130599957.6665c0d17a0b07b8=- 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 Reviewed-by: Michal Orzel --- Changes in v7: - 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 4ca3a3749f=2E=2E34b5a85f9f 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 d94652809e=2E=2Ecfce8e91fa 100644 --- a/xen/arch/riscv/domain=2Ec +++ b/xen/arch/riscv/domain=2Ec @@ -284,7 +284,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 6ebe6c5052=2E=2E368e4deff3 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 73c54794ac=2E=2Ece1fa636db 100644 --- a/xen/include/xen/sched=2Eh +++ b/xen/include/xen/sched=2Eh @@ -772,10 +772,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.104.ec8451bfddb2c110.1a130599957.6665c0d17a0b07b8=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:48:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:48:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446378.1662508 (Exim 4.92) (envelope-from ) id 1xGGO7-0003Oi-Df; Mon, 12 Oct 2026 13:48:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446378.1662508; Mon, 12 Oct 2026 13: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 1xGGO7-0003Ob-AY; Mon, 12 Oct 2026 13:48:23 +0000 Received: by outflank-mailman (input) for mailman id 1446378; Mon, 12 Oct 2026 13:48:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGGO5-0003OT-9d for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:48:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGO4-004gvH-1s for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:48:20 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce521-e002-0a2a0a5209dd-0a2a4503a566-8 for ; Mon, 12 Oct 2026 15:48:19 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acce523-fae8-0a2a45030019-d1558033dcc3-3 for ; Mon, 12 Oct 2026 15:48:19 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a16aaf2067so23567415e9.0 for ; Mon, 12 Oct 2026 06:48: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-4a18bb6b3cbsm232843565e9.0.2026.10.12.06.48.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 06:48: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:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1791812899; x=1792417699; 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=0JJgzXibs2L8Ozots3TUohDX9JTUp65Qyaj9d4ug+z4=; b=de0qNkV7oLOHjpnKRjry7TTmpSajk+l2Ogn7eXQIdYmyLNQRn2olTHaNIxtAKnMsnw u6jV+j+gUsKqB5MkIXEIZaRjN7JpAgYvzyk5sY0c2vchWX5V8qmf1uhlMhp4i30CUew0 eBZbF9S8uzHrgKuN7gfXXtL6RbPAwQUS+GObEQ2TzT/3AzILoYQcfPdvUSzmE6QOpK/b g5mT9QJTej713dFV07UU9Y7v/xL6V+qy2hODwq2L2Q800vDUtHzCxaOQsMUp0+Zcb14x Im6W9jIPcVliYbQPY+95tiSIN8+KMOtMNCE6xBfnJJKVSZFFaEW5vcizzld+HqLA9mHc cA+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791812899; x=1792417699; 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=0JJgzXibs2L8Ozots3TUohDX9JTUp65Qyaj9d4ug+z4=; b=QhPzSaWkHrppqla5y85euRjyHq7geurU8UITnnldKVQkk3J1qSFsD5S2lOVOI9Wv1/ WJp9j+hz2irlc1d2ZKiYzib+5VtDeyM7A5GjjSPbH1o/tP3Tj863oj0pOCq6NSUTP8wf T9jD41vd4QSWNSPOMhM/uf81iEajx4JJf6Cye+mPjd1v0mdNJ1l0LjRMaH/HTp6RYU/G LEKprsp71XeXEiSaD8MOiDrGAFR6915YR9mk1C40XHSwuFEgCwV+UFG5Y8ANSqKLGqYv jUaIi5HqP/cnBuxdXmYO6MGYc1XqArNtgmFfn/IqSLGNOdQofQ+qQcXGMqeW4YMyGjQk 4ciA== X-Forwarded-Encrypted: i=1; AKwUvBx6ae9YvK+TxbMH0iqBvqwAi0ZSlLZkLrIscgR9jGPDikSN2VVd7r/jIOjEnxZyZTgTk0QtAQ3V+NI=@lists.xenproject.org X-Gm-Message-State: AFq9FYIBMy42zm+n4olTJfo6rvwKW1xuPNv82HRohb+7652VZ3fh0nL+ DhlFhvMvaXRQxgiPrFqkrRpMjeB7SMfJtNTebt+cHIvhKnQ8qrwvvNOBlVYyY0gkJQ== X-Gm-Gg: AYBFou0coHeLt3BWk3PyFf/pk3jM4Rv+3of05RvScK4f1zwd8UG6GrD+ZxB2EZaizH2 5yK8nbQ/X3AkoXDEbZofevMtL9ZDGUiPD5GgktV4r8PTgmeB/yN1ONgVul87UmjhQNF/ezMw/KK I0Nn7Jg0GZWMUizfR4gvHeVdi7qysFHlwwGfEyS15CmWib3SWvsM1zcTpTcqj1tgqWtpLISl0Mm Jw8xqYIf9EIiZolilRRcsrO2k6CyNwG6k4atWA81gBTgMG0yPDFhWCVQpjQ09rmGurZrjVo/KZi VSbDp+gn2jGdV5Ss67vIu4c4MPzZvXV8CkqAT+t0aneRwZOLaaf1l1vYPMPCNEyda31I2PszKjT TciaMKLQH/mali61Vepu2/BmlYn4qfKsTPRTN19mjrXuvXIGUIJ8DA/y+BxxNzA94fBzntlizyG kEkFseY1hyRoNKD730jO0E+d+9j4xb8x6phHXWKM3OyNs0L2f318g26b38Tjc9iscGl5XbGEChk aIWS4FLXLvUjgyxIfautQs7ARB76rlr7AjZ37BIX4RvaZTD7DFWtG7PquxfkQ== X-Received: by 2002:a05:600c:4ecb:b0:4a1:76c9:5408 with SMTP id 5b1f17b1804b1-4a18e4a510emr192106875e9.11.1791812899172; Mon, 12 Oct 2026 06:48:19 -0700 (PDT) Message-ID: <8514b7b6-cf1c-44d9-827c-675fd5a6708e@suse.com> Date: Mon, 12 Oct 2026 15:48:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@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: <20261007104051.48841-9-gwd@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1791812899-6F6C64E9-E980086C/10/78276251493 X-purgate-type: spam X-purgate-size: 5285 On 07.10.2026 12:40, George Dunlap wrote: > From: Roger Pau Monné > > Currently, only PV domains have a mapcache, which is domain-wide one. > In preparation for enabling per-vCPU mapcaches for HVM domains, split > the accounting out into a struct mapcache, embedded in struct > mapcache_domain. > > Introduce has_mapcache(), for whether a vCPU has a mapcache, and > vcpu_mapcache(), which returns the accounting for a vCPU's mapcache > and, in *dcache, the domain-wide mapcache whose lock and TLB epoch the > caller has to take into account. For now has_mapcache() is > is_pv_vcpu(), and vcpu_mapcache() always returns the domain's > accounting. map_domain_page() and unmap_domain_page() stop repeating > the is_pv_vcpu() check mapcache_current_vcpu() has made. > > Move map_domain_page()'s handling of the domain-wide lock and TLB epoch > into three helpers: mapcache_lock() takes the lock and catches up with > a wrap another vCPU caused, mapcache_new_epoch() starts a new epoch > after a wrap, and mapcache_unlock() drops the lock. A per-vCPU > mapcache can then skip them without map_domain_page() being > re-indented. > > struct mapcache_domain keeps its size (40 bytes, x86_64 debug build), > and so do the structures containing it. > > No functional change. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v3: > - New in this version, split out of "x86/hvm: introduce per-vCPU > mapcache for vCPU-PT domains" for review. > --- > xen/arch/x86/domain_page.c | 155 ++++++++++++++++++++---------- > xen/arch/x86/include/asm/domain.h | 19 ++-- > 2 files changed, 116 insertions(+), 58 deletions(-) > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > index 9119f735f5..5d90f77bed 100644 > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -18,17 +18,23 @@ > #include > #include > > +/* > + * Whether v has a mapcache: PV vCPUs (whose domain-wide mapcache may still be > + * disabled, see mapcache_domain_init()). HVM vCPUs reach everything through > + * the directmap, which covers all physical address space for them. > + */ > +static bool has_mapcache(const struct vcpu *v) > +{ > + return is_pv_vcpu(v); > +} > + > static inline struct vcpu *mapcache_current_vcpu(void) > { > struct vcpu *v = this_cpu(pgtable_vcpu); > struct vcpu *curr = current; > > - /* > - * During early boot pgtable_vcpu is not set, callers must handle NULL. > - * Non-PV domains don't have a mapcache, the directmap covers all physical > - * address space. > - */ > - if ( !v || !is_pv_vcpu(v) ) > + /* During early boot pgtable_vcpu is not set, callers must handle NULL. */ > + if ( !v || !has_mapcache(v) ) > return NULL; (For context below: The replacement of is_pv_vcpu() here is easy to follow.) > @@ -54,6 +60,55 @@ static inline struct vcpu *mapcache_current_vcpu(void) > return ACCESS_ONCE(this_cpu(pgtable_vcpu)); > } > > +/* > + * The accounting for v's mapcache: the domain's, with *dcache set so the > + * caller takes the domain-wide lock and TLB-epoch machinery into account. > + */ > +static struct mapcache *vcpu_mapcache(struct vcpu *v, > + struct mapcache_domain **dcache) > +{ > + struct domain *d = v->domain; > + > + *dcache = &d->arch.pv.mapcache; > + return &(*dcache)->cache; > +} This function only retrieves data. Can't its first parameter therefore be pointer-to-const? > @@ -74,12 +130,12 @@ void *map_domain_page(mfn_t mfn) > #endif > > v = mapcache_current_vcpu(); > - if ( !v || !is_pv_vcpu(v) ) > + if ( !v ) > return mfn_to_virt(mfn_x(mfn)); I don't quite understand why this is_pv_vcpu() is okay to drop. What mapcache_current_vcpu() returns isn't what it ran is_pv_vcpu() on. (Same in unmap_domain_page() then, obviously.) > @@ -249,15 +294,23 @@ void mapcache_domain_init(struct domain *d) > int mapcache_vcpu_init(struct vcpu *v) > { > struct domain *d = v->domain; > - struct mapcache_domain *dcache = &d->arch.pv.mapcache; > + struct mapcache_domain *dcache; > + struct mapcache *cache; > unsigned long i; > - unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; > - unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); > + unsigned int ents, nr; > > - if ( !is_pv_vcpu(v) || !dcache->inuse ) > + if ( !has_mapcache(v) ) > return 0; > > - if ( ents > dcache->entries ) > + cache = vcpu_mapcache(v, &dcache); > + if ( !cache->inuse ) > + /* Domain-wide mapcache disabled (fully direct-mapped build). */ > + return 0; While technically not wrong, this comment appears to be quite a bit forward-looking. > + ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; > + nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); Is there a reason these cannot be the initializers of their variables anymore? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:50:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:50:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446385.1662517 (Exim 4.92) (envelope-from ) id 1xGGPx-0004wt-Nz; Mon, 12 Oct 2026 13:50:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446385.1662517; Mon, 12 Oct 2026 13:50: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 1xGGPx-0004wm-LM; Mon, 12 Oct 2026 13:50:17 +0000 Received: by outflank-mailman (input) for mailman id 1446385; Mon, 12 Oct 2026 13:50:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGGPw-0004wg-DF for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:50:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGPv-005jto-Pn for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:50:15 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce58e-8faa-0a2a0a5109dd-0a2a450c90f4-36 for ; Mon, 12 Oct 2026 15:50:15 +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 6acce597-f479-0a2a450c0019-d155802cdcd9-3 for ; Mon, 12 Oct 2026 15:50:15 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a16aaf2067so23588175e9.0 for ; Mon, 12 Oct 2026 06:50: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 ffacd0b85a97d-48db9ade914sm18121261f8f.54.2026.10.12.06.50.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 06:50: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=1791813015; x=1792417815; 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=ytP0QNn9MIUxZonDK/H7HrHHAAyzmi7idecn6+c9uV0=; b=WOIgDP5Xn8n70jYuImHxINtmtdd0rFJHG2YbP06HRrsNMo5HDO45xqAdOV/yHwvvq3 KvkoHXH+CTKRr/8qfcfdE4ephYz/AmRIax6ah5/nWc7DYd0GoRJJHuTykH5u87bxobaq GXAeBpw+Ymdc9/SlEIjuIMgfWCNctpbqHfbQDslBJZGBpxX29b9cWoFkO5DXgIYal/sr 8316fnp6yhhWhlZ1oZLlY0JurlHgkljyrxlTfBVqz93bAGo1IZ+IeRSHxmDFPMIeYD/N p4ap+yFif8jWPc4s1Sf892WF9ffwjtpNcyajsTaZ2Zfmf4OcEzpinX3jEvqwNwzcIxkb NerQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791813015; x=1792417815; 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=ytP0QNn9MIUxZonDK/H7HrHHAAyzmi7idecn6+c9uV0=; b=kgOmRJqudKx0zFx3sekaLxZIuqQ+9McqQ4DbVxaBYtbdAtwASDWR+5k89A2DznxpHN Fm9GgLkLGnHlLII2yuGMEa7iV33nPruC1tjCwAXf1ucHtFYG8mqtfnU3cSAzq/Yn71TI T+ChmVXTpjpOP4sYHWbZLNYfdSc9xoYLRPBr78IB/AQ1hg2pTyrgiQmLKE1VTLI8ygxg A/BLoxzntimlyrTlE0KuzNWxDroBlmUCeDPbxfkiPhPvPknN6yqmvabpWr/K68yttZ48 lkWhYOX+NbRw1DjKCiS5xTgvKQEMe/H8GrNXkqNaCiSGqhiDIPAz4gqH9FaXNs2A2gai MZiQ== X-Gm-Message-State: AFq9FYLJxH4/2HM6r3BXHgIbKBa+D0fassf7wL1ZRsBiyXfzFP4pU3k6 fxVbstq3AFXVXdVtsgNEJoNQTdnKmp+3Y+54DJUntc+uDfEjV3W0DasI X-Gm-Gg: AYBFou2rMptVb9wl4A0VWbKAq9An5t5jw/p9/hLc1oGmTiT3hOt0saS4Ir1lhnBl1Fd ipcPU/4lLKwwppKyEgyf9r03HUmWcgoC0Dayk4MrJ7aJyxuIoxez/zxPzpeKgNFTHCU1Rr1Aa3E S6qyiNGsh2jgHokXXtl4xmbgHVGSG+16HUUg6GzRGM8JBCJUmTyAN72SllbWW5IbGwWr79C4KMl 5Z0JpyxD/o4mPrbiLzZeVkMneF/TC2ctCYspPwUbXHBeIMYYUJ242QTzgeNIjQEncM2jFONa5oh p59dM3GlHou/jzt2RZ3BBaym66HCMJHRMROhc8t2pleg0Dsg9EMsgIj00AannqeebV2CaZ9rdmj LtZvso49HkaDYybVp7igeDnIg6Tw/Vhc55DuDRAjxJ1xWCoXYFB52WnFZGMuBfgosxUl2SfG93k mxj8C2y4a40A+B8vwijTEbpzmHO2s21HqIQ8W6c7q8+lJjhd9ZGRxe+qsyM6MJXPTojChqQzbYj m+XMhGolooI67KGvtU0UbWOVWn/FbBuYpo9t4O6OgpPYSRFQw== X-Received: by 2002:a05:600c:4f46:b0:49f:cbf1:e77b with SMTP id 5b1f17b1804b1-4a18e4a5355mr229518845e9.10.1791813014741; Mon, 12 Oct 2026 06:50:14 -0700 (PDT) Message-ID: <1960669d-0a07-4bf5-9219-c079cb9d0081@gmail.com> Date: Mon, 12 Oct 2026 15:50:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 06/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: <1791194531.8631fc262581453bbf619ec5b2062170.1a10b8384c50003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791194531.8631fc262581453bbf619ec5b2062170.1a10b8384c50003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1791813015-51538A5B-646B575C/10/73395122804 X-purgate-type: spam X-purgate-size: 3681 On 10/5/26 12:01 PM, Baptiste Le Duc wrote: [...] >> diff --git a/xen/arch/riscv/include/asm/mmio.h b/xen/arch/riscv/include/asm/mmio.h >> new file mode 100644 >> index 0000000000..1bf48571a9 >> --- /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 > Should be ASM__RISCV_MMIO_H instead to be consistant with other header > files in riscv/include/asm. According to the coding style document it should be __H. I understand that some headers in RISC-V looks in the way ASM__arch_something_H only becuase they were introduced before the header guard recommendations have been updated. I think I could suggest a separate patch to rename all header guards, at least, for RISC-V to avoid such type of confusion in future. >> +#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 */ >> + bool is_write; >> + /* Store: value to write; load: value read (set by handler) */ >> + register_t data; >> +} mmio_info_t; >> + >> +enum io_state >> +{ > Style: should be directly after enum io_state. I will fix that. >> + 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. */ >> +}; >> + [...] >> +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 > The else is not necessary here, misra would call that "dead code". > Here are two suggestions: > > if ( info->is_write ) > return handler.ops->write(v, info); > > return handler.ops->read(v, info); Sure, I'll drop the else and go with the first variant in the next version. I am not too much into MISRA stuff and just for my education could you please specify what MISRA rule has been violdated here? I suppose it is because of Rule 2.2 (or 2.1?). I don't think Rule 2.2 applies here. MISRA C:2012 defines dead code as "any operation that is executed but whose removal would not affect program behaviour" (as quoted in [1], Section IV). The else doesn't introduce any such operation: both forms have the same semantics, and the read() call under the else is executed whenever is_write is false, so it is neither dead nor unreachable (Rule 2.1). FWIW, I also compared what gcc 16 generates for RISC-V: at -O0 and -Os the variants with and without the else are byte-identical, and at -O1/-O2 the only difference is which of the two calls is laid out as the fall-through path; the instructions are otherwise the same. But probably this is not the best way to verify things... Also, R2.2 is disapplied project-wide for Xen anyway (see docs/misra/deviations.rst). [1] https://arxiv.org/abs/2212.13933 > or: > > return info->is_write ? handler.ops->write(v, info) > : handler.ops->read(v, info); > If I am not confused something above then why thos option doesn't violate MISRA rule abouve 'dead code' isn't ternary operation just an equivalent to if/else? Thanks for review! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 12 13:51:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 13:51:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446390.1662526 (Exim 4.92) (envelope-from ) id 1xGGQn-0005fX-45; Mon, 12 Oct 2026 13:51:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446390.1662526; Mon, 12 Oct 2026 13: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 1xGGQn-0005fQ-12; Mon, 12 Oct 2026 13:51:09 +0000 Received: by outflank-mailman (input) for mailman id 1446390; Mon, 12 Oct 2026 13:51:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGGQl-0005e2-IG for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 13:51:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGGQk-00CA47-VZ for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:51:06 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acce5ae-2eae-0a2a0a5409dd-0a2a4507c272-40 for ; Mon, 12 Oct 2026 15:51:06 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acce5ca-b4ea-0a2a45070019-d1558032b987-3 for ; Mon, 12 Oct 2026 15:51:06 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a0e1b0681bso13794445e9.3 for ; Mon, 12 Oct 2026 06:51: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 ffacd0b85a97d-48db98c38f4sm22223312f8f.27.2026.10.12.06.51.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 06: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=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=1791813066; x=1792417866; 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=0w8o4QV823/YkzZBk4iJbx3xKAe5ngaSHAaCWR6m7iY=; b=BPDy6TJO5BCSdci7KKScn7Jba6dolu4hdrHj9smAaL6asEPTMyRM3BZqLNt6oSnWJj H8JgtQtlIbyHtlWYV4JUBJPRCZDvc8XRi1qvdtYztnmE8gEWRtnaFk1fnAoD+PWvDeQ1 yQybWLu4fGgkOlqaf/J6EdfmzP8SO/zkNO4oywsRmPLfZKqsCLXdx9betNPG+kyvtRt7 ShPuMpaHcel6HkBI/YounvVZXdZDTxJI48i/+YCSv0DXOsrqnTWzs7+KX5AKy/DxqLdl DaLu+MkXwG9KTEIQ/IgVrMpp4fakJaQRXake4D/wei+Ck34yKEs8U2WT4PItcYjrEwP3 wnGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791813066; x=1792417866; 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=0w8o4QV823/YkzZBk4iJbx3xKAe5ngaSHAaCWR6m7iY=; b=QjRo/RMzTDEkvBjbmXusmTceAYvtEI/c5RElJwP2ICaCJjaz4fxVidMb1/09EBeB+P 2+LjI4Nkkhri4//IesVHaGo9IJBkxdpaoIh13TDn0tna2X2jr/A+jlq5S+EiI/Ah+AXx 5rXCaBADeIcT8r5/1R4SNptkZtkCQMklFFRefqWu4pi4F1+G9yAyj78MV+TFh1ds0PoP faDRdVpRS97hKWf8IcRSoffLzXb5hH5qjJ7cvdihp2tDj3efCJ0YuZWLVnY89h5Dyeul dK9Ji1X7mkNX0sIDa+dC8CY8Z6jWxvbA7aoZuAkrPWhJCPRIsgdirJShOZqYNAEer9kH /I/Q== X-Gm-Message-State: AFq9FYL/Pfyx/Nyk/3tlVNkjA1LpO0svdmAtLeLzvsJAUYk4b+P+E1cc k/KestGu36w0Mqe+ZCnkH9D3ceIazfi/oVz2gkOkNtwSX1zI+LNEKX/7 X-Gm-Gg: AYBFou1vjj69Ty846nLINzfMDYy6xBKSi6GANCNGucFr20YAUOsG6kiiHll3Rqq/ufw GAzbhQJNjog57zWalqVpFs7uhRln6AkdDiyumsd7jvrmoe1Xu4A0Jr0EKNqPio9866BjgO6RfKo 97Evl7uQHebc9l2+k6QRpyo29Z3XSviL/ZcU5l1ffsUKGe5WnXgy20IdBUZSLSWCgfVtpXRGboe 2q/ob09KDjyVd/uZPr9c0Y7EfgkDepysmQYzqcMlXJ2Sz/Uku4u2vgc1NNpvpCyqyg6ml5zlNhB 2uWMW7jYx9dsDe3ZHzWh0qogb08GWfKKnrVicWlCf1WjFYr35JQHoE2FPZI2vwiF196ykG2yMUR VqHhcBl5Kup6ssPzKGCh0r6uXAaf5fSGrFPPfg76cDwAwDPGorhc9gFbLpvolt23Pl0p8fBFUuW 5fu/V0kOjBaJv1TvOIjSLCLs0+AAdw8z4OjslWnLohCtvLmBt62LERGkx/ErTEHXt/3cPbIw2YH ZXzffjt8Oodz8zpcehQihBrXm3oZjsnkYWBt7UTyk+eon+nKg== X-Received: by 2002:a05:600c:4fcb:b0:4a1:811c:8083 with SMTP id 5b1f17b1804b1-4a18e4c3600mr177734105e9.33.1791813066323; Mon, 12 Oct 2026 06:51:06 -0700 (PDT) Message-ID: <54a18241-5808-4b8d-8af1-2bab0b869047@gmail.com> Date: Mon, 12 Oct 2026 15:51:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 06/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch To: Jan Beulich , 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: <1791194531.8631fc262581453bbf619ec5b2062170.1a10b8384c50003f66@vates.tech> <8aab6ff3-512e-418a-8170-5182ae7f30dc@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8aab6ff3-512e-418a-8170-5182ae7f30dc@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791813066-352CCAE4-5773DBA8/10/73395122804 X-purgate-type: spam X-purgate-size: 607 On 10/8/26 4:57 PM, Jan Beulich wrote: > On 05.10.2026 12:01, Baptiste Le Duc 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 >> Should be ASM__RISCV_MMIO_H instead to be consistant with other header >> files in riscv/include/asm. > > No, please see the bottom of ./CODING_STYLE. It's many of the other headers > which would want updating (eventually; there's no urgency I think). I will send a separate patch for that, at least, for RISC-V. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 12 14:19:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 14:19:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446407.1662537 (Exim 4.92) (envelope-from ) id 1xGGsJ-0001nr-6Z; Mon, 12 Oct 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 1446407.1662537; Mon, 12 Oct 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 1xGGsJ-0001ni-39; Mon, 12 Oct 2026 14:19:35 +0000 Received: by outflank-mailman (input) for mailman id 1446407; Mon, 12 Oct 2026 14:19:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGGsI-0001nZ-4m for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:19:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGGsI-00000001ljI-0UOk for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:19:33 +0000 Received: from mail-lj1-f170.google.com ([209.85.208.170]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGGsH-0000000EZpx-1g6J for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:19:33 +0000 Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-3a76ac0bdafso33213981fa.1 for ; Mon, 12 Oct 2026 07: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" 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=OJpYti+KUGIKerN53VbQAQ7qCAsOUc2SuCJoTjHPgh4=; b=rNtrsZe01npOeU34mA2YgAS9gP mDgCFKKpSRhK5vZfpgtCzt+qGlxVIJPhbvPjCrcxMAuRGWi2EAO9aXAkaVRnFb2kKKRErHLOPo45m 5t6YGBzU76Ooh9+ep5pObnMAJsi8220cVh2cnN6qmnXsKCb80lbg3a6Fun/7kkqo4g0M=; X-Gm-Message-State: AFq9FYJRyh0VHG+PWOaPfs/ebjRbbgFvcBvDTRW5JHRsJzWrWxG02h2U 62tUvtfs3yyny8eFNvKvj41EhZDosUQ+WF5UE257WdhhsUUVfAsysWcaRnIhxRWchBxlvjaE4G2 6s/45gtpnTPSRZXnWt0MyJ6gF7iSbuhE= X-Received: by 2002:a05:651c:2121:b0:3a9:dd56:bc59 with SMTP id 38308e7fff4ca-3a9dd56c399mr11765121fa.13.1791814772596; Mon, 12 Oct 2026 07:19:32 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Mon, 12 Oct 2026 15:19:20 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-NUJ_k07Y-NqxnQI-MFEC6aUQa4nL0z37ZB0XtbYRj00ZdEPBt8zY31uo Message-ID: Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 9:22=E2=80=AFAM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:41AM +0100, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > Currently, only PV domains have a mapcache, which is domain-wide one. > > In preparation for enabling per-vCPU mapcaches for HVM domains, split > > the accounting out into a struct mapcache, embedded in struct > > mapcache_domain. > > > > Introduce has_mapcache(), for whether a vCPU has a mapcache, and > > vcpu_mapcache(), which returns the accounting for a vCPU's mapcache > > and, in *dcache, the domain-wide mapcache whose lock and TLB epoch the > > caller has to take into account. For now has_mapcache() is > > is_pv_vcpu(), and vcpu_mapcache() always returns the domain's > > accounting. map_domain_page() and unmap_domain_page() stop repeating > > the is_pv_vcpu() check mapcache_current_vcpu() has made. > > > > Move map_domain_page()'s handling of the domain-wide lock and TLB epoch > > into three helpers: mapcache_lock() takes the lock and catches up with > > a wrap another vCPU caused, mapcache_new_epoch() starts a new epoch > > after a wrap, and mapcache_unlock() drops the lock. A per-vCPU > > mapcache can then skip them without map_domain_page() being > > re-indented. > > > > struct mapcache_domain keeps its size (40 bytes, x86_64 debug build), > > and so do the structures containing it. > > > > No functional change. > > > > Signed-off-by: Roger Pau Monn=C3=A9 > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, C= laude Code:claude-opus-5-5 > > Signed-off-by: George Dunlap > > --- > > Changes in v3: > > - New in this version, split out of "x86/hvm: introduce per-vCPU > > mapcache for vCPU-PT domains" for review. > > --- > > xen/arch/x86/domain_page.c | 155 ++++++++++++++++++++---------- > > xen/arch/x86/include/asm/domain.h | 19 ++-- > > 2 files changed, 116 insertions(+), 58 deletions(-) > > > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > > index 9119f735f5..5d90f77bed 100644 > > --- a/xen/arch/x86/domain_page.c > > +++ b/xen/arch/x86/domain_page.c > > @@ -18,17 +18,23 @@ > > #include > > #include > > > > +/* > > + * Whether v has a mapcache: PV vCPUs (whose domain-wide mapcache may = still be > > + * disabled, see mapcache_domain_init()). HVM vCPUs reach everything = through > > + * the directmap, which covers all physical address space for them. > > I've been wondering whether there could be a way to write this comment > so that it doesn't need rewording once we switch to per-vCPU > mapcaches, as to avoid adding a comment here that will very likely be > completely re-worded by a later change in the series. However I > cannot find anything much better rather than stripping most of the > comment content. I think describing it the way it is, then changing it, makes the series or the state thereof more clear. But I'm not precious about it; we could make it something like this: /* * Whether v may use a mapcache rather than the directmap (a PV domain's * mapcache may still be disabled, see mapcache_domain_init()). */ That said, as a meta-comment: We have a limited amount of time on my contract, and also a limited amount of time before we want to check this in to the tree. Is spending our time changing non-functional intermittent git tree state really what you want to spend that time on? > > > + */ > > +static bool has_mapcache(const struct vcpu *v) > > +{ > > + return is_pv_vcpu(v); > > +} > > + > > static inline struct vcpu *mapcache_current_vcpu(void) > > { > > struct vcpu *v =3D this_cpu(pgtable_vcpu); > > struct vcpu *curr =3D current; > > > > - /* > > - * During early boot pgtable_vcpu is not set, callers must handle = NULL. > > - * Non-PV domains don't have a mapcache, the directmap covers all = physical > > - * address space. > > - */ > > - if ( !v || !is_pv_vcpu(v) ) > > + /* During early boot pgtable_vcpu is not set, callers must handle = NULL. */ > > + if ( !v || !has_mapcache(v) ) > > return NULL; > > > > /* > > @@ -54,6 +60,55 @@ static inline struct vcpu *mapcache_current_vcpu(voi= d) > > return ACCESS_ONCE(this_cpu(pgtable_vcpu)); > > } > > > > +/* > > + * The accounting for v's mapcache: the domain's, with *dcache set so = the > > + * caller takes the domain-wide lock and TLB-epoch machinery into acco= unt. > > + */ > > +static struct mapcache *vcpu_mapcache(struct vcpu *v, > > + struct mapcache_domain **dcache) > > +{ > > + struct domain *d =3D v->domain; > > + > > + *dcache =3D &d->arch.pv.mapcache; > > + return &(*dcache)->cache; > > +} > > + > > +/* > > + * The domain-wide mapcache's lock and TLB-epoch machinery, taken arou= nd > > + * allocating a slot: the domain's vCPUs share the mapcache's slots, a= nd each > > + * catches up with a wrap another one caused, flushing its TLB if it h= as not > > + * been flushed since. > > Thinking forward about how this function will end up looking when we > have per-vCPU map caches, do you maybe want to place this comment > inside the function body itself? > > I expect per-vCPU splitting will add a short-circuit at the top of the > function that will skip taking the lock or doing the flushing, and > hence the comment won't need shuffling around? Yup, we can do this. > > + */ > > +static void mapcache_lock(struct mapcache_domain *dcache, > > Maybe mapcache_enter() would be a better suited name once there's no > longer a need to take a lock for the mapcache? Just wondering, no > strong opinion really (the more that I don't even know how the code > will end up looking yet). Yeah, can do that. > > +/* A wrap has just flushed this CPU's TLB: start a new epoch. */ > > +static void mapcache_new_epoch(struct mapcache_domain *dcache, > > + struct mapcache_vcpu *vcache) > > +{ > > Since this is now a function on its own, I would possibly assert that > dcache->lock is taken on entry. > > Let me know what you think of the suggestions above, overall I think > the logic is fine. Great, thanks. -George From xen-devel-bounces@lists.xenproject.org Mon Oct 12 14:28:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 14:28:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446415.1662544 (Exim 4.92) (envelope-from ) id 1xGH0O-0003YZ-V0; Mon, 12 Oct 2026 14:27:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446415.1662544; Mon, 12 Oct 2026 14: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 1xGH0O-0003YS-Rp; Mon, 12 Oct 2026 14:27:56 +0000 Received: by outflank-mailman (input) for mailman id 1446415; Mon, 12 Oct 2026 14:27:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGH0M-0003YI-Qr for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 14:27:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGH0L-00GXKA-Ns for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 16:27:53 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accee4d-2eae-0a2a0a5409dd-0a2a450bb0fe-42 for ; Mon, 12 Oct 2026 16:27:53 +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 6accee69-b7e8-0a2a450b0019-d155dd29e12a-3 for ; Mon, 12 Oct 2026 16:27:53 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48b9d8055dfso1501533f8f.3 for ; Mon, 12 Oct 2026 07:27: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-48db94e3519sm21523365f8f.16.2026.10.12.07.27.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 07:27: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=1791815273; x=1792420073; 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=98iMOZmL2SX1z8LyBHw+Q8ZxOjErsHJ74vlNo2magzs=; b=YaCs6EXAqpYwPXyZ+L9jq8t25gMyzrQ2DAGmpXnCF6KLDcVj59t2gvE/47uMBX3bHp 2ZvS3YNPaqUcKXslPpg6XWIhmu+QLrUUc7Cd2AyoxWNvKLh/wU01VTXblHZrFDNC+mRs OHofpPJYWuLCC5ZLJmHlnHSzuMBkwBOsKgJWUk8p/pBzPqXxaFbmTMj+/ITak8PtGbUD 3zfokiCybc+xcK9X+8I+Uh1VQKtJmOeDj08eH4DXi9jpVItmWRYxRqkapwuonO7QwPmY hYC1lUnlMhuNKKJbKF6F3z5+EdvPP5jgee2xlIGBBTSHxGkuoEmBoAFzqkrc8zFUjSZs 669Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791815273; x=1792420073; 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=98iMOZmL2SX1z8LyBHw+Q8ZxOjErsHJ74vlNo2magzs=; b=JfepOf/uXeNYUiGpdLUXJyLgDXBP9NYiJJnUckAbrdz0b57sz//q4uueLrEdKBzfGw S8rmUc5snty67QAEC5/CLkfljDVbZqo7okTwX9pQgWAhyMvwa0xKBmwzrNODTPIhjgJX CZzU3bike8BFgFzOGwz9IL3AvRc7SKPhRotYuYYQVb5TdyowBu6OJKHVhRn37BUAElsY 6d0aQd79VoMVKTJxhbPIDI9PIr0PiBDkR8fGNaL/Moy9By3NAifsMa8tQC38wJyEhO/8 RA9sor6JKrygxz3bbeWUOJl2b6Ch4ZXG9UK4LmzrreAww5syNlBFaeu+PQ2v/eGVBep3 wUvQ== X-Gm-Message-State: AFq9FYJuRlFLm4rceVYm0jxRpPB9/7dpSBOGWM5qmH9vKobjp9pSAg9N BlLoyiYn/wZynNyeppZB8Zpp8AoZi0SMPWu5SBDEWgwuYBfBpirX4K5H X-Gm-Gg: AYBFou32SLD18eRhO3j4S4cXiwDnLBgC5TUmlYmY5jYXrTXDlhspoUicfB/u4/YL1WR ndS/yVDbz+jY0huooEmXH2KlqOLOvpNt8zupjct+kUlKJw2zWxvikZPpAs7Vz78b5E1C/tgB0vg u1p1J9kRodl/6VnsDIucfYbVcg8LalVJQi5a3aQeNc07U+DLpQhoOC9RDB37HOxM/KB4S15Vybr 96zF3tWHJxKp7Tz+0NunBD6+Hvr3Ms7N7zHE6An15uygGYMSrCkeqL4CgBzp5ah6xUgbqBUbEtG ZWwSVPEmL9Si10VlYJbEe8+i5nlILg8t20h6lBEYs1I2sLyA9QYXkJK51Gehc6jZs3Cv+zb4rhS oV4yLIXm70nAmqzaw3r5VAHgHTRB8M8jXbl9v6CjGWmfCRDe64+ErL7f+DGuO5Zk5Qx9U6fCtiQ iFJfWwNJKaeMgkRA9azB0RJbz2Sq1wInttdvjf1sHhx2HWmaJgVwL/1n3yQCPmPrNhJNti+YN7H V0qKH8YA0VFXi/Go1k8G+rCA1zb6RkWY+9FmIF/mT/AWcZbVQ== X-Received: by 2002:a05:6000:298e:10b0:487:2387:7c9 with SMTP id ffacd0b85a97d-48dbaadb47emr13300160f8f.14.1791815272278; Mon, 12 Oct 2026 07:27:52 -0700 (PDT) Message-ID: <54046054-0352-44a8-aedb-8221ac1a9dac@gmail.com> Date: Mon, 12 Oct 2026 16:27:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 07/39] xen/riscv: introduce CPU_NONE 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: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e56370003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e56370003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791815273-AA4DB9EA-25D18613/10/73395122804 X-purgate-type: spam X-purgate-size: 1521 On 10/5/26 4:53 PM, Baptiste Le Duc wrote: >> Introduce CPU_NONE, a CPU number which doesn't identify any physical >> CPU, to be used wherever a pCPU has to be recorded but there may be >> none. >> >> Its first user is vsfile_cpu in struct vimsic_state, which records the >> pCPU whose h/w guest interrupt file backs the vCPU's IMSIC VS-file. >> NR_CPUS has been used there as the value meaning that there is no such >> pCPU, i.e. that the s/w VS-file is in use. NR_CPUS is however an upper > Nit: It's hard to understand when reading the message why s/w is mentioning. > I'd reword it to: > ``` > NR_CPUS has been used there to mean that no h/w guest interrupt file is > attached (i.e. the vCPU uses the s/w VS-file), so there is no pCPU to > record. > ``` >> bound rather than a "no CPU" marker, and it already carries other >> meanings: hartid_to_cpuid() returns it for a hart Xen doesn't know, and >> pcpu_info[] uses it for an entry whose processor_id isn't valid yet. >> Use CPU_NONE for vsfile_cpu instead, so that the s/w VS-file case can't >> be mistaken for any of those. > Nit: Same as above, I'd prefer something like: > ``` > Use CPU_NONE for vsfile_cpu instead, so that "no h/w guest interrupt > file attached" can't be mistaken for an unknown hart or a not-yet-valid > pcpu_info[] entry. > ``` I will apply your suggestions. > > Reviewed-by: Baptiste Le Duc > Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 12 15:28:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 15:28:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446435.1662553 (Exim 4.92) (envelope-from ) id 1xGHwq-0004GX-5O; Mon, 12 Oct 2026 15:28:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446435.1662553; Mon, 12 Oct 2026 15:28: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 1xGHwq-0004GQ-2P; Mon, 12 Oct 2026 15:28:20 +0000 Received: by outflank-mailman (input) for mailman id 1446435; Mon, 12 Oct 2026 15:28:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGHwp-0004GH-Ii for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:28:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGHwo-005zik-Vj for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 17:28:18 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accfc91-8faa-0a2a0a5109dd-0a2a450b9646-6 for ; Mon, 12 Oct 2026 17:28:18 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accfc92-b7e8-0a2a450b0019-d1558034b02c-3 for ; Mon, 12 Oct 2026 17:28:18 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a0213948d3so12581655e9.2 for ; Mon, 12 Oct 2026 08:28: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-4a18bea0f1csm426231665e9.9.2026.10.12.08.28.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 08:28: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=1791818898; x=1792423698; 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=I9CZ+QPoXRZjlLdO5+Gb+JA+BVEBctyw3tli7YGGjms=; b=ea6jpWOrMan5btjb07+6Bpoha361TT6kKx/3zzK8EWjzskHqxZlZij6ZBjPfFtOw2y YwvErRBAFlWmAXQf5o1+9qEV/txSP3gN1ewaGKBV3lT4PcaHxiLIeVaPUYliAm+qje28 V+1KWipuPfj3VefFW8eu2Icsn6vv23z8KMpAD3enSDOPV4li/XBw3LZ9NZDm+aozX2rH ERxfaifKuxCXbPz5XZ4XSiJbKsU3tu1oIhCnAA2KyDOctdVghjoIX3cP/VT3C6ApvmLX v0mAyEMshnPgPGRYNh5dH4sTlEnJ0Eo+MtbTIRRRGJrAr6Gc1mf4bg7CI28EUtbYuabf l2/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791818898; x=1792423698; 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=I9CZ+QPoXRZjlLdO5+Gb+JA+BVEBctyw3tli7YGGjms=; b=rdvNj9u+zVYfdF9qITTrl+m3gounNWvEdjbxEhqKJWp57J+JQaenZKopyxz+c5G8eJ 8gTkr42usafXf0icTVqozBezSR8rHv3hNzVDaRgT+uAhsrqo7LgZCJnMgqoOQ4dR8fjO dtMdc6z4zJ1iitE3TkFrQPO62J2mvHL/PN5idOw8I3P6qWUnq+PedNDFLxA1Jx5NhxQ7 rFY45vhViJKKWirolJ/jtCHNqD7oCV0W8+IzEX5DuqtYHGAjEojssIdXkIZ+cTU+nLIf /FR0NLRm9kFvgP8N8zuE35hcgt4zsxUOpU+gd++/KjtBGC8UbdCwTXpG8TEJbXQDgma3 uf0A== X-Forwarded-Encrypted: i=1; AKwUvBwyDb+SSfbZe9eDHEDRvHsFXPMf4b8WZd3diZE/PR+3xdfHee/bJrwphzONO87E7+2x9vooGA1tocg=@lists.xenproject.org X-Gm-Message-State: AFq9FYLrnLA2kYTSfiufrYtaNXmDP2N1CmvmCtg0mN2LOiLQnM5HXN1F cMoaDnTtdRdHaAHk/tGWLRkvpAjVbIL6W0mYIfjQGYo/lwPQ9s+aSsRgxuEQL1pfow== X-Gm-Gg: AYBFou1AodopNNzG7l3ciItLSnXtoEEovozREPegU8gkkawKLc13DhBKo2My0T1GjAS H8gVXB/tmZ0Kq47i+y9Mhv0agQw9YiP9dBbE5sRgLLb8lphzapW/qSo2Dq5tMagVyXUY+jtf0dl DQkENRfSCZPBh8V1AXCJrW65zDEQ7HsB+8iaT73+EMwdKdMfasW4mfOJpz/Py1u1oTwJiXc62nv po7zzQpNieAW+PUcHOeCeKpxBghW6MpfCcSTYFF2jyTM2KhG2Fx55huWAGLl0AutOwzRQDGV9yG DFIX3TIvei1CX1R6tIfAO31XPnj/g3aTX/J32/QSSSb64qMCE7jrBzL3nhAO7rTkoMgBOoNMvb2 ef0ocE+LdBkBkOXwEIQJe2uPjncqPXLZvjAqBJgtrscMatnRUeTcL6ETg0PZu+Iz+bkZidD1JYT rL/+00YU/KaPdt4Fo5ZWy1jouHgBQmVoaMywhyTjgWVajAb6xoOwbembMEjflPUDmxP3FmxM+32 dlLUdKrBJEY4BCYhLbr/JshXB9vv+Y94C4+mtdhBMn6iJ9WdGK7xxmYqNF7C6A= X-Received: by 2002:a05:600c:c113:b0:4a1:985b:83a9 with SMTP id 5b1f17b1804b1-4a1985b87f5mr78682915e9.4.1791818897919; Mon, 12 Oct 2026 08:28:17 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 17:28:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 06/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-42698a/1791818898-A98C19EA-759207F6/10/78276251493 X-purgate-type: spam X-purgate-size: 3595 On 30.09.2026 18:18, Oleksii Kurochko wrote: > --- 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; This is a decent size structure, so I wonder whether this really wants embedding in struct domain. If it was a pointer here (with the struct dynamically allocated), the struct definition itself may not even need exposing in a header. > --- /dev/null > +++ b/xen/arch/riscv/mmio.c > @@ -0,0 +1,175 @@ > +/* 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, The first parameter here apparently wants to be named currd, much like ... > + 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; ... this variable wants to be named curr. Unless of course there are plans to not unconditionally use current here. > +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 || end <= addr ) > + return -EINVAL; I think this checking goes a little too far: It's absurd for some call site to pass NULL into this function. The other three checks are sufficiently plausible, albeit I wonder whether this wouldn't want to be an assertion then. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 15:40:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 15:40:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446445.1662563 (Exim 4.92) (envelope-from ) id 1xGI8i-0007C5-A7; Mon, 12 Oct 2026 15:40:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446445.1662563; Mon, 12 Oct 2026 15:40: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 1xGI8i-0007By-6k; Mon, 12 Oct 2026 15:40:36 +0000 Received: by outflank-mailman (input) for mailman id 1446445; Mon, 12 Oct 2026 15:40:35 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGI8h-0007Bs-B2 for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:40:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGI8g-006fpX-CJ for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 17:40:34 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6accff71-8faa-0a2a0a5109dd-0a2a45059a4a-2 for ; Mon, 12 Oct 2026 17:40:34 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6accff71-4cb1-0a2a45050019-d1558032ac0a-3 for ; Mon, 12 Oct 2026 17:40:33 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a01933b584so17837455e9.0 for ; Mon, 12 Oct 2026 08:40: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-4a190344032sm299774415e9.15.2026.10.12.08.40.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 08:40: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=1791819633; x=1792424433; 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=OHcbuaX8ZY8NhWtfaUQWJtUiZ5954j21xRi4n3rwmzo=; b=ZYfnBBGm5vexkx68h1HSjTVFKjIPj28srzK6gO6W4R4uLiwDZ5zAs7Rv88vRu4+SZK bvWPlFA7ZiRxupJXHD+9rnV1ujr2U3evhRuZC2U4gHOKZk8oZaxOCXesrtC7wijCMdhF mySw462gwKcCdzq8vYWNafu81zyoKdwyqQUfkIMf6VLdkKff7LGcY3ptk4E2pb0/87VW IyC/epPbJwlmXIEvTfA+4nnIuREn6QVQeaEEhAqeVjxtBhHTjzKsyAfsubcsp9fnVVax xMh8Wrw2qKGrJtznuXEWmV+hL22kvOoT1k3/Vxi9zBxPX5fSL64/VAU1YcH4eVZ/N6KN nS/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791819633; x=1792424433; 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=OHcbuaX8ZY8NhWtfaUQWJtUiZ5954j21xRi4n3rwmzo=; b=pa5ZCBOQOxdOR38//BqljE5ew4I1hLTLhKP7wBgi4PVo8MIy22gB/H0P1rqTyrIeU5 31vHq/0SI4IYo/tre/CdVKRM/hhEX+bHb83FkhGc/Fu49UUHOjb70AAaD6CpZsPYq4+N JistLmWYJNRmwk5TOei3PdWPZpqfLJ4ENDR6mdCVXRht0H6c2hAK1c+f1BH5cIXh0Puk K8OCcxOtg5BUjilcHyNXNnQuhmlnXrGWJcgu5VISHn4IQMCYYNakBGZoYDrkA+ia1KwE gwCnKWTWvFZEpFU8dcEK54KkW3o9lT2Se2+3bl6ryUdEvPSlx3p94oYX04a4yWsRTuyL /DuQ== X-Forwarded-Encrypted: i=1; AKwUvByfMwbSVmOcy0oGKdTajIPKaRFFr1GjxuqIfGtTwzp93Cn1rVoLFlA0LQfoURDYbnONw7X0wMuwz30=@lists.xenproject.org X-Gm-Message-State: AFq9FYKzFzjPAevv3+2rGMdmnOmYihYXA4haCH4xWz8ofhwbFvsjti6y x7akNnbC/6yoVgMumqfVN+Ca2c4zMdB3NCPOgTiWS2sOERpfm0slTCTjZ9imqozmDg== X-Gm-Gg: AYBFou1Ni6RPAnW9r0U0CsBi6Rh4rN8I1/giyejzKvyKhKndcQLD/BD2Sfk9A+MQrPN IV+pW8FL3MGh51oee6lwkjeerIXQU6Y3Ixrxe3mvlaSBFDV/cdP6cYkHT2GL8Y5C9U1fVi5VQQA nWpbsMVr8Soq97BmmA62P5Or5g9idZDS8VgcrvHmYJvz4XuRahw0qpYZjgyniEr+cRUq5PPoyLV yu+/1jRrjfBZdLiER95n+ItG0bZVwWs0/JNqxS3Rs3Rvzbg8xAiiIYEOFXw2ILj2e2N6x8mXwRq 30AjmTbDwBJiz7Yp3Xv4AvDmYWUNdBcy8Dr5bAR+Q53cQFm4TYcSxgV3jQYFmsw1T66UJyYeRGT fzoDTI0jGFJW6I2r3Ie6Ovi3nsPjtY2/COAdBPsxcUE7F970tpuczvHTf4ZVWNi4zSIDnHJfxWH 5x3/0wiycwTkXijsbmg3v66nn+rfhRpYyFaFLHA9DWl4uKWcPUq/YqSxY1WrBNbnm8YgzYA3PqU W0fu775elnPj6BBmPgOpEyv4YEqKFiRCZR4yJrKdREAPESwrdz779EYiAMaXCH+nPSgqRtkXPs= X-Received: by 2002:a05:600c:3554:b0:4a0:1b14:e283 with SMTP id 5b1f17b1804b1-4a18e43a1cemr190157205e9.1.1791819633318; Mon, 12 Oct 2026 08:40:33 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 17:40:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 07/39] xen/riscv: introduce CPU_NONE 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-c201ff/1791819633-F56AD2A1-DA91C03D/10/78276251493 X-purgate-type: spam X-purgate-size: 2134 On 30.09.2026 18:18, Oleksii Kurochko wrote: > Introduce CPU_NONE, a CPU number which doesn't identify any physical > CPU, to be used wherever a pCPU has to be recorded but there may be > none. > > Its first user is vsfile_cpu in struct vimsic_state, which records the > pCPU whose h/w guest interrupt file backs the vCPU's IMSIC VS-file. > NR_CPUS has been used there as the value meaning that there is no such > pCPU, i.e. that the s/w VS-file is in use. NR_CPUS is however an upper > bound rather than a "no CPU" marker, and it already carries other > meanings: hartid_to_cpuid() returns it for a hart Xen doesn't know, and > pcpu_info[] uses it for an entry whose processor_id isn't valid yet. Yet these could (and imo should, subsequently) entirely plausibly also be switched to CPU_NONE. IOW I don't think ... > Use CPU_NONE for vsfile_cpu instead, so that the s/w VS-file case can't > be mistaken for any of those. ... this is a plausible justification (nor in its re-written form as per Baptiste's suggestion). If you want such a distinction, you'll need separate sentinels for every one such field. > --- a/xen/arch/riscv/include/asm/config.h > +++ b/xen/arch/riscv/include/asm/config.h > @@ -136,6 +136,9 @@ > #define OPT_CONSOLE_STR "dtuart" > #define INVALID_VCPU_ID MAX_VIRT_CPUS > > +/* A CPU number which doesn't identify any physical CPU. */ > +#define CPU_NONE (~0U) > + > /* Linkage for RISCV */ > #ifdef __ASSEMBLER__ > #define CODE_FILL /* empty */ > --- a/xen/arch/riscv/include/asm/imsic.h > +++ b/xen/arch/riscv/include/asm/imsic.h > @@ -71,7 +71,7 @@ struct vimsic_state { > */ > unsigned int guest_file_id; > /* > - * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS > + * s/w IMSIC VS-file -> vsfile_cpu == CPU_NONE > * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS > */ > unsigned int vsfile_cpu; As can be seen from the comment alone, there's now the risk of CPU_NONE < NR_CPUS, at which point users of the field will be screwed. I think you want BUILD_BUG_ON(CPU_NONE < NR_CPUS); somewhere. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 15:51:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 15:51:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446456.1662572 (Exim 4.92) (envelope-from ) id 1xGIJC-0000kO-7B; Mon, 12 Oct 2026 15:51:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446456.1662572; Mon, 12 Oct 2026 15:51: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 1xGIJC-0000kH-4B; Mon, 12 Oct 2026 15:51:26 +0000 Received: by outflank-mailman (input) for mailman id 1446456; Mon, 12 Oct 2026 15:51:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGIJA-0000kB-PC for xen-devel@lists.xen.org; Mon, 12 Oct 2026 15:51:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGIJA-00FxAU-4H for xen-devel@lists.xen.org; Mon, 12 Oct 2026 17:51:24 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd01e9-2eae-0a2a0a5409dd-0a2a4502d45e-12 for ; Mon, 12 Oct 2026 17:51:24 +0200 Received: from [185.70.43.166] (helo=mail-43166.protonmail.ch) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd01fb-6ca4-0a2a45020019-b9462ba6426d-3 for ; Mon, 12 Oct 2026 17:51:24 +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:Cc:Subject:Message-ID:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1791820283; x=1792079483; bh=lhyhzQs/6WjvVNEukWWqKI2Z4VNNq8e4uRKMZdqtw3g=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=rfYJLs8xAcO2fyxYTqRpjyscDtKiD2qJ0YtaeJnRa20N+bT4o9HXFJl73w9qp5sfv ZzgQvSKelVpgIM0umwVC2rGmuL29Z7zIN6RCINJbrXSOlm5Bg9QrlIYco2pG/wkv24 cyvKykHvoWblbiF6tMSxgsuB3CGS7QVA7pZcrxQpf3KJSE6GwW2I0sI1/bO1pc1DGU cNuu8eondapk9z3vdOhwGsLCy2nKdr6+UdY+HQJ6xgC1w+T1o8ZMKPQr6MH1QEFMzo GpUPGtF6KYZMKQT7IiIDPgdICTMUGD0jEYNsEVPPzA4GZ7GHJmvoSbKioSJ2ddKY82 kCcs7kE0KsVtQ== Date: Mon, 12 Oct 2026 15:51:18 +0000 To: Jan Beulich From: Egon Ojamaa Cc: "xen-devel@lists.xen.org" Subject: Re: [BUG] Xen Dom0 fails to boot with "nvme.poll_queues=24" and "dom0_max_vcpus=6 dom0_vcpus_pin" Message-ID: In-Reply-To: References: Feedback-ID: 7420290:user:proton X-Pm-Message-ID: 21fa49fcbe3dc8836143a184b59ce036adadc948 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1791820284-F26B72AC-216DA1F7/0/0 X-purgate-type: clean X-purgate-size: 3080 Hello, I did a follow up on: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/= 2170270/comments/2 Confirms same bug on 5900x Zen3 system, ubuntu 26.04 LTS , kernel 7.0.0-38-= generic , non server MB. AFAIK, dom0_max_vcpus=3D I think can be any value. For sure happens with 6 and 12. I cant find anything in logs, so I suspect it does not boot to the point lo= gging can work properly. I tried now to get somesort of log, not sure how useful, get IPMIscreencap.= 7z : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270/+attachment/60= 08530/+files/IPMIscreencap.7z More info on comment 3: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270/comments/3 Egon O. > > Hello, Real human writing, not AI here ;) >=20 > Good to know such can still happen. >=20 > > #### Problem: > > > > Booting Xen hypervisor with Linux Dom0. > > GRUB loads, Xen kernel messages load up to "Using 6 CPU" > > > > # From this point: > > Next screen goes black and stays blank for 10+minutes. > > Have to force reboot and choose non XEN kernel booting option via GRUB. > > > > # From this point expected behaviour without bug: > > Next screen goes black and stays so for 30-70sec and Dom0 kernel messag= es appear, > > Next login is possible and system is running, "xl info" and other xl co= mmands function. > > > > #### Cause: > > I spent 2 days rebooting to narrow this down.. > > > > This happens if we set both settings same time: > > NVME io polling and XEN kernel CPU limits, via default grub configs: > > > > GRUB_CMDLINE_LINUX_DEFAULT=3D"nvme.poll_queues=3D24" > > > > # Can also be set via /mnt/oldroot/etc/modprobe.d/nvme.conf > > # For proper polling setup nvme.io_poll=3D1 should also be set, > > # but symptom already appears if we set only nvme.poll_queues=3D24 > > > > and > > > > GRUB_CMDLINE_XEN_DEFAULT=3D"dom0_max_vcpus=3D6 dom0_vcpus_pin" >=20 > Did you isolate which of the two options it actually is that causes the > problem, or whether it needs to be both together? Also, is 6 a necessary > (exact) precondition to the issue occurring? >=20 > > Sadly not my personal system, so I can not do further heavy testing on = it. > > io polling does give very good performance boost to Gen5 NVME, and even= Gen4. > > Sad we cant use it, as CPU pinning is more important for XEN hypervizor= system. > > > > This has been also reported to launchpad.net: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270 >=20 > As was meanwhile also indicated in that report: What's completely missing > here, but very likely necessary for further analysis, are logs. That may > also help establishing whether it's the kernel (driver) that's hung, or > whether the system as a whole (i.e. Xen) is stuck. If nothing else in the > log has any indication either way, issuing a debug key (for starters just > 'h', later maybe others) may help telling one from the other. If issuing > debug keys isn't possible anymore, try adding "watchdog" to the Xen > command line. >=20 > Jan > From xen-devel-bounces@lists.xenproject.org Mon Oct 12 15:56:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 15:56:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446465.1662580 (Exim 4.92) (envelope-from ) id 1xGIOV-0001Si-Pl; Mon, 12 Oct 2026 15:56:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446465.1662580; Mon, 12 Oct 2026 15:56: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 1xGIOV-0001Sb-MW; Mon, 12 Oct 2026 15:56:55 +0000 Received: by outflank-mailman (input) for mailman id 1446465; Mon, 12 Oct 2026 15:56:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGIOT-0001SU-Ut for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 15:56:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGIOS-00GmMx-Rg for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 17:56:52 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd0341-e002-0a2a0a5209dd-0a2a450b864a-8 for ; Mon, 12 Oct 2026 17:56:52 +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 6acd0343-b7e8-0a2a450b0019-d155dd33d96d-3 for ; Mon, 12 Oct 2026 17:56:51 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48afcd7ba9bso1149956f8f.3 for ; Mon, 12 Oct 2026 08:56: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-48de0ab5af7sm178390f8f.31.2026.10.12.08.56.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 08:56: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=1791820611; x=1792425411; 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=evp/RbpVN6mqSgMgL+mH/iNOasO4SmTCxt3eQ+EoJdg=; b=HiYjZsjQnJtBfUThL+pjMZJWsoiDKDMU9Vh9lNKzD8+5k0CwiQKZ9/EyhM+dlzO1H+ OapP0G2L5/cWGCwwOo3KJCqjs3S9GQ5p36p8d/+XdHAj+hlhFgF10eBG7QE40u2iN4LX 1Xr/iCCUL92M3b5t/FWLuCJW1f3a51b60deRQ13JX1NZzTYNPvng4t2Efy/HzLQo0tAH F8zKvTR8aZ7YngZwY0X7Y/WsB+TkOLYAICZQSBW6MOkaOJZbEicTakwblEa3+4psQomR Qlw55eikkzgu7p+EaN0vlO+A5IsJSBrmLNS5YkE9pcOVxda+/wshFc1dE1gP01MNsP39 CdFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791820611; x=1792425411; 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=evp/RbpVN6mqSgMgL+mH/iNOasO4SmTCxt3eQ+EoJdg=; b=cc+8R2gL4SgX8pe5zSIRBW3MhASfJcwGT2/SQ3Xe49Fqv5syHyspJ7awLKmQhttxmU cYbbNOOmXW4+m6coZF6hPQGuBqGIIw19WRGLfyqKICNejcSHVz9iYvEjc8Dyor8+fDYE jRNsj5dkoNECRulL1q32MUl7PAQD7eUHZP5qehM4xNmOFfQIfrTcpE7TrvAjXb6/Oa1X nXFg8g4aeIjfqpn6dU4NjEfJApxmch1ZrdaMBPsjPGaCGlWdIXvywm5YSpjEmbrKnnXb avlx8YY7IxYJtubi+ufxUw8S1P5ZEaIvBQk/OFnKT4jhKLITD2gr7cSo13uXck1Tv13B SPjA== X-Forwarded-Encrypted: i=1; AKwUvBw1Ga3jaSH+MjEpCERZNwvuLIzw9efp8o94kroFLsGrYPvtxBi1fGuckXVnnYUo8N8Vdd4OtV+zPLg=@lists.xenproject.org X-Gm-Message-State: AFq9FYKXGM6ZGZ9Jh+3uGd0lM91vJiHJ5YnxPGkbBdM4+K9tagLviTnQ S+GdxVDML1o4oczwcWqTCkO4xzUok8NiPxkUKG4IH5nQyqcsc/pVz+DhC8WtBHKqUw== X-Gm-Gg: AYBFou3/M4vvHTduvjwx7jzETfGcNc9E8U9ya5tWT/w6PYuSA9muk62b+lTIrqg9/XN UrS1AZlyfvoOyRNxP2H777+B9iJNR42pLPIRa2CfmQI95FeJjHTo79UzYDqlTFJwtZYXCJZt7Dv cX+MK3DXPbS++vTGQceI5NvDzZkcpIi0vY31tMoFJTAfeCiwf8IV6rG+Hs+vUsAch6zvBEeDRhq l83zatmw4cI2obhZ1dmFjHvwcr93aBJ25RXQd86ASrZ+fsZAQO3F0sKyjH97qrjfQEp4N0RGgY/ 9v5h8kaExOXbNvv3kwsUSbqLuMhtjyrxe82xjRBIsRdsK0RlAMW/YDkFCjBghm0F7xqP6yVmyf0 XQi+eAOT6KpfZQ8LfxLEmhmWxW4e76A2zIRhvf6PM98nos6SNKAcvSxi06rgkPDQh6zEda7JUQY W35GYUYvxvodFygOLEpNney8nLTifY9+9qrAlagX+g8F514nzTiTS4TdSq4cRXL+gqRtwUTORUm 4Ey5LPYl4YX71bcOD53FOzkdKry7Rp1qyIFUo/5nFUAbwEE4mCFU/kPXXy/Yg== X-Received: by 2002:a05:6000:41cc:b0:48d:bae6:d7ba with SMTP id ffacd0b85a97d-48dbae6d911mr16877470f8f.26.1791820611428; Mon, 12 Oct 2026 08:56:51 -0700 (PDT) Message-ID: Date: Mon, 12 Oct 2026 17:56:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 05/13] tools/libxl: Add support for Viridian stimer direct mode To: chunjie.zhu@citrix.com Cc: ross.lagerwall@citrix.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, xen-devel@lists.xenproject.org References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> <6e26064971c8c4a4a5edbceae0b536e60fdb02fe.1791625578.git.chunjie.zhu@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: <6e26064971c8c4a4a5edbceae0b536e60fdb02fe.1791625578.git.chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791820611-AB2DC9EA-93C6099A/10/78276251493 X-purgate-type: spam X-purgate-size: 631 On 10.10.2026 12:13, chunjie.zhu@citrix.com wrote: > From: Ross Lagerwall > > Add support to libxl for using the stimer enlightenments in direct mode. > > Signed-off-by: Ross Lagerwall > --- > 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(+) Was it an accident that this patch was included in this series? You didn't even Cc the toolstack maintainer. And your S-o-b is also missing. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 12 16:07:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 16:07:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446477.1662590 (Exim 4.92) (envelope-from ) id 1xGIZ4-0004AV-Pg; Mon, 12 Oct 2026 16:07:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446477.1662590; Mon, 12 Oct 2026 16: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 1xGIZ4-0004AO-MG; Mon, 12 Oct 2026 16:07:50 +0000 Received: by outflank-mailman (input) for mailman id 1446477; Mon, 12 Oct 2026 16:07:48 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGIZ2-0004AI-Qw for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 16:07:48 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGIZ2-00000001o3q-3XWr for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 16:07:48 +0000 Received: from mail-lj1-f178.google.com ([209.85.208.178]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGIZ2-0000000HT88-0WyR for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 16:07:48 +0000 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-3a75f960be3so18594481fa.2 for ; Mon, 12 Oct 2026 09:07: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" 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=8ncPgslNiNqkxP2CDhkltwMZWX45x9XZsA1CUpG25C0=; b=JvmuYdX03MSWNmw/kbtyIdrpa1 v2ygCQyXa49JGID7cnhM7fnU+93VZt6ExF2jXfG1qnipZM7CYRShwqTzMufW7JFipod3HJ0TdxQ6d EMXjtiBdqwi4H4DTxUCPPkJ4G5McMrwwc3H81wdcx1nN5LIQ8Vm8je6RE8cvTVl3uhCY=; X-Forwarded-Encrypted: i=1; AKwUvBz1Cyjg/bxMt+F+ecrxFQ8gNHd4c1RYMSQmledDjDTaH+1ngZvdTKp+MLD7ukpj8G2Lo8ZJrjLbKlg=@lists.xenproject.org X-Gm-Message-State: AFq9FYLo70j3mI9r90pDsHnpcG1X355g/6oYTvc5Lup+wC9BHJgNkpH/ TD7X81lyiubMXW8cpF0Zaiizay6nufdRIVxYtkgaKYRSGeTOjhgiBHbdG1d0hFMwOcfi2gEJ9JW oyTFRSz0F5KX9mo/OkPH1t4a/7M/H2fo= X-Received: by 2002:a2e:a58d:0:b0:3a9:926c:c276 with SMTP id 38308e7fff4ca-3a9c53808fcmr22686631fa.17.1791821267291; Mon, 12 Oct 2026 09:07:47 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> <8514b7b6-cf1c-44d9-827c-675fd5a6708e@suse.com> In-Reply-To: <8514b7b6-cf1c-44d9-827c-675fd5a6708e@suse.com> From: George Dunlap Date: Mon, 12 Oct 2026 17:07:34 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8XpG1UKDIhUjMyuSao_joQaIosu8BwgX2tQGdNbHdUb4nbW6hz9nsTVyY Message-ID: Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2026 at 2:48=E2=80=AFPM Jan Beulich wro= te: > > @@ -54,6 +60,55 @@ static inline struct vcpu *mapcache_current_vcpu(voi= d) > > return ACCESS_ONCE(this_cpu(pgtable_vcpu)); > > } > > > > +/* > > + * The accounting for v's mapcache: the domain's, with *dcache set so = the > > + * caller takes the domain-wide lock and TLB-epoch machinery into acco= unt. > > + */ > > +static struct mapcache *vcpu_mapcache(struct vcpu *v, > > + struct mapcache_domain **dcache) > > +{ > > + struct domain *d =3D v->domain; > > + > > + *dcache =3D &d->arch.pv.mapcache; > > + return &(*dcache)->cache; > > +} > > This function only retrieves data. Can't its first parameter therefore be > pointer-to-const? Currently that's true; but in a further patch, it may be &v->arch.mapcache.cache, which is in the vcpu structure itself, effectively stripping off the const-ness by pointing to individual fields in a struct. > > > @@ -74,12 +130,12 @@ void *map_domain_page(mfn_t mfn) > > #endif > > > > v =3D mapcache_current_vcpu(); > > - if ( !v || !is_pv_vcpu(v) ) > > + if ( !v ) > > return mfn_to_virt(mfn_x(mfn)); > > I don't quite understand why this is_pv_vcpu() is okay to drop. What > mapcache_current_vcpu() returns isn't what it ran is_pv_vcpu() on. (Same > in unmap_domain_page() then, obviously.) So mapcache_current_vcpu() is a bit weird; the actual invariant is, "Return the vcpu whose cache structure we should use if present; or NULL if there's no cache structure to check and no need to sync." So if pgtable_vcpu is HVM, return NULL and just use the raw address, because at this point in the series, both HVM and the idle domain have full directmaps; if pgtable_vcpu is PV, then maybe sync, and then return the result of the sync. That may be a PV domain with a mapcache, or an idle domain with no mapcache, but in either case you can then read cache.inuse to see if there's something there. So yes, it's a different vCPU; but it's still defined in such a way to be safe to check cache.inuse. The only possible value *change* after a sync is the idle domain; I don't think we need to do another check to make sure it's still a PV domain. In fact, there's an argument that we should modify mapcache_current_vcpu() to take pointers to dcache, and vcache, and return just cache; that gets rid of v as a local variable of map_domain_page entirely, and makes the logic ("get the cache we should use") more clean, and gets rid of one mfn_to_virt() instance. That would require some non-trivial changes, so I'd rather avoid that, but I can do it if you want. > > @@ -249,15 +294,23 @@ void mapcache_domain_init(struct domain *d) > > int mapcache_vcpu_init(struct vcpu *v) > > { > > struct domain *d =3D v->domain; > > - struct mapcache_domain *dcache =3D &d->arch.pv.mapcache; > > + struct mapcache_domain *dcache; > > + struct mapcache *cache; > > unsigned long i; > > - unsigned int ents =3D d->max_vcpus * MAPCACHE_VCPU_ENTRIES; > > - unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); > > + unsigned int ents, nr; > > > > - if ( !is_pv_vcpu(v) || !dcache->inuse ) > > + if ( !has_mapcache(v) ) > > return 0; > > > > - if ( ents > dcache->entries ) > > + cache =3D vcpu_mapcache(v, &dcache); > > + if ( !cache->inuse ) > > + /* Domain-wide mapcache disabled (fully direct-mapped build). = */ > > + return 0; > > While technically not wrong, this comment appears to be quite a bit > forward-looking. Yes; I'll drop the last bit. > > > + ents =3D d->max_vcpus * MAPCACHE_VCPU_ENTRIES; > > + nr =3D PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); > > Is there a reason these cannot be the initializers of their variables > anymore? No reason. I'll put them back. -George From xen-devel-bounces@lists.xenproject.org Mon Oct 12 16:23:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 16:23:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446487.1662598 (Exim 4.92) (envelope-from ) id 1xGInt-0007Jh-3v; Mon, 12 Oct 2026 16:23:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446487.1662598; Mon, 12 Oct 2026 16: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 1xGInt-0007Ja-0h; Mon, 12 Oct 2026 16:23:09 +0000 Received: by outflank-mailman (input) for mailman id 1446487; Mon, 12 Oct 2026 16:23:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGInr-0007IN-Lj for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 16:23:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGInq-00G11Q-JP for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 18:23:06 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd0954-e002-0a2a0a5209dd-0a2a4509803e-38 for ; Mon, 12 Oct 2026 18:23:06 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd096a-be1a-0a2a45090019-d1558034d873-3 for ; Mon, 12 Oct 2026 18:23:06 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a020e65269so13019275e9.2 for ; Mon, 12 Oct 2026 09:23:06 -0700 (PDT) Received: from andrew-B650M-DS3H.. ([102.213.49.86]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18dd15659sm197285685e9.4.2026.10.12.09.23.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2026 09: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:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791822186; x=1792426986; 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=IQE/x4hoVQgY+EdpQ1pgD1gNzudfoGE1aTGqMHPFuu8=; b=QR7wZFXFIIWIukfyDMYK4CRpfUwX8fBRPKBtDvBDr/GKEKK8pQIIpz84epbPP4jTHi LGO19brzgH1AXVhuZXU9FGhLxJBZwCLY0x4NjaTHgu+A2N6aH23QV/h6wM2Wi6GmaNuk adJbpgsaqwRYjvJB5QDV6HLvVdwkVWq4slDox+o6EUdSaZDvfz7YW9mToTumpOMc9QCX sr95hF43UCOQBwvRgt1Lb1Gt4b7tSappNwjM0c03sVBzX0xuySFVC60JFpQ/vvRanJqR 2FzEjjedFkA9MFlx7I2tKvKfE7/orXpiW/x7ZgsM3ivJOAD0WEnTmcW8zCzRcFBn4Qda Fhww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791822186; x=1792426986; 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=IQE/x4hoVQgY+EdpQ1pgD1gNzudfoGE1aTGqMHPFuu8=; b=si5DcwxjJMmcjYficKTwjuMiMYykW3MhBPgQ+ULEm0AOLphZzk8VBGt8M5eJNjQTPH FJPSs3/iyw7ByicOQmtl+uSJ6Hb1QW0ig1xYbex5QujfTDx+RCFKJ3ZQw05ajVpj1tx7 f6qUu2tH9Hg0zxI6RHT02d7y+Qv4nJDt5atSMbPZfHa1x850JWYEVDLrY8bhY16OLy6z TIbX3WGJQsP416tGSjzfqEehGQtI5RYWgFicoDX+MtbdLi+uTUCafizPZTX9pzXt+VEJ mOCk/fpvawhfpsMKm5IyNy9ljoBS24DFFc6noFhUZC6z097ZZXR54tbXfVV4/v6Vyd4A JW3Q== X-Gm-Message-State: AFq9FYKTgGyOkCoR55HP2oKqa2oV3giEIB9lF1D9AsW9s+K81qnSB7Dm HXfQ30CyZC/zxiwFmLsHe7FK1x+98vjFUUzoxFTEx5Sa8Q5RSHwF5aYJqrG3bN1R X-Gm-Gg: AYBFou1/sLzuRBM647WTM8KgZhUozu4YZxjbb7WzA58MvYVSUec/DaNXenZ0vu4U8Xq pbkH5WoXR9KTtxaod4jxuTepERBcsw6fNWYVgBCpYlAHPh9khRMxPjFtwLN7COQWor7os10sghQ KW8mquyflSczPGrML7bteEgDIHQScLPJstFVr6frLNaixIHZp16RhoFkHyOz6Fr+L2LhgQBF2K2 rMznI0u9AqrkJgX8cZF+qOtHb9uA0v4BST5JU5//+JeLP0IxAduXlOTv+28WJoH2tcQpN2Yd5sr GP4ilc/zNbAV5ZwLe8g8O6flq7LkfOHb/ps1lOKlPvibjq3Vn49KP5lDEmpFTzw25SwMk37jPI6 QcjtT17nfdrLIIfHLt2C+zM++s14KfHo4c/fGjHeSdJSf4HWDve5s7nkhhXKWf/m7UHbgGGDTDX BQ9J0U8WjO7cXdQmx/KwiE/FrujGQlPXVpDu9MSunNr3kKgPXC20JPxHUx70cj6anC0wTG9RVI8 G7oj+F7QV6IbBwv X-Received: by 2002:a05:600c:1d20:b0:49f:fd40:80fa with SMTP id 5b1f17b1804b1-4a18e4f50ecmr201060925e9.34.1791822185721; Mon, 12 Oct 2026 09:23:05 -0700 (PDT) From: Andrew Mbugua To: xen-devel@lists.xenproject.org Cc: andrew.cooper3@citrix.com, andriy.sultanov@vates.tech, guillaume.thouvenin@vates.tech, anthony.perard@vates.tech, Andrew Mbugua Subject: [PATCH] tools/oxenstored: preserve socket fds across exec live-update, document SIGTERM limit Date: Mon, 12 Oct 2026 19:22:58 +0300 Message-ID: <20261012162258.811103-1-andrewprecious388@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1791822186-3AEDE034-27FEE0B9/10/77776452383 X-purgate-type: spam X-purgate-size: 3581 Resending this patch a new after fixing mailing list spam rejection The TODO comment at connection.ml: has_extra_connection_data dates back to commit 42f0581a91 ("tools/oxenstored: Implement live update for socket connections"), which started dumping anonymous (dom0 toolstack) socket connections as "socket,fd" plus watches, but left the SIGTERM / file-based restart case unsolved: (* TODO: what about SIGTERM, should use systemd to store FDS || has_socket (* dom0 sockets not * dumped yet *) *) An fd number is only meaningful for an exec-based live-update where the fd is inherited. It cannot survive a SIGTERM/file-based restart where fd numbers from the old process are meaningless. That would require stashing the fds in systemd. Additionally, Connection.dump never cleared CLOEXEC on the socket fd (unlike DB.to_channel which does so for the listening socket), so even an exec live-update including a forced one with `live-update -F` which bypasses prevents_quit, loses the connection and restore hits "Ignoring invalid socket FD". Resolving the TODO without regressing commit 42f0581a91: - keep allowing idle sockets for exec live-update; pending partial I/O still blocks via has_in/has_out and SIGTERM clients simply reconnect. - clear CLOEXEC in Connection.dump so the dumped fd actually survives exec. - replace the TODO with a comment explaining the remaining systemd fd store future work for SIGTERM. Ive verified that make builds oxenstored cleanly Signed-off-by: Andrew Mbugua --- tools/ocaml/xenstored/connection.ml | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/tools/ocaml/xenstored/connection.ml b/tools/ocaml/xenstored/connection.ml index 37eb2444b9..e535e7cea6 100644 --- a/tools/ocaml/xenstored/connection.ml +++ b/tools/ocaml/xenstored/connection.ml @@ -435,9 +435,15 @@ let has_extra_connection_data con = let has_in = has_partial_input con in let has_out = has_output con in let has_nondefault_perms = make_perm con.dom <> con.perm in + (* Socket (dom0 toolstack) connections are dumped as "socket,fd" plus + watches by Connection.dump below. The fd number only survives an + exec-based live-update when the fd is preserved across exec (see + dump); it cannot survive a SIGTERM / file-based restart, where fd + numbers are meaningless. That case would require stashing the fds + in systemd (fd store / socket activation). Pending input/output + already blocks above, so idle sockets are safe for exec live-update + and SIGTERM clients simply reconnect. *) has_in || has_out - (* TODO: what about SIGTERM, should use systemd to store FDS - || has_socket (* dom0 sockets not * dumped yet *) *) || has_nondefault_perms (* set_target not dumped yet *) let has_transaction_data con = @@ -464,9 +470,13 @@ let dump con chan = Domain.dump dom chan; domid | None -> - let fd = con |> get_fd |> Utils.FD.to_int in - Printf.fprintf chan "socket,%d\n" fd; - -fd + let fd = con |> get_fd in + (* Keep the fd across exec so an (exec-based, possibly forced) + live-update can restore it via "socket,%d". File-based + SIGTERM/restart cannot restore fds; that needs systemd fd store. *) + Unix.clear_close_on_exec fd; + Printf.fprintf chan "socket,%d\n" (Utils.FD.to_int fd); + -(Utils.FD.to_int fd) in (* dump watches *) List.iter (fun (path, token) -> -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 12 18:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 18:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446553.1662680 (Exim 4.92) (envelope-from ) id 1xGKvk-0001T0-7c; Mon, 12 Oct 2026 18:39:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446553.1662680; Mon, 12 Oct 2026 18: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 1xGKvk-0001St-3b; Mon, 12 Oct 2026 18:39:24 +0000 Received: by outflank-mailman (input) for mailman id 1446553; Mon, 12 Oct 2026 18:39:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGKvi-0001Sn-QT for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 18:39:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGKvh-00Coqz-Fp for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 20:39:21 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd2959-e002-0a2a0a5209dd-0a2a450ac574-0 for ; Mon, 12 Oct 2026 20:39:21 +0200 Received: from [52.101.201.3] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd2957-f2d2-0a2a450a0019-3465c9036910-3 for ; Mon, 12 Oct 2026 20:39:20 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH5PR03MB7910.namprd03.prod.outlook.com (2603:10b6:610:212::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Mon, 12 Oct 2026 18:39:17 +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.0496.021; Mon, 12 Oct 2026 18:39: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=gKYdF4ApyrMbWDNMWHt+oQ2RnCw+DSnhMswZMUjYCKosHSbDe9MsH9xxA8Nz004JwC6Zd6SPgzAU3fsLyDYceizMSaL7DvNFL2NvjArKJKc04ZJ4g/zz70I+sFK3e/lQS8DGkxECYCJAQuyqIP9h/V5ugC6m4XCKTssaNAOFsO+rPVVMNqvRTVP1f3c0/XJZOXCigYcYxPoFRzMqGJj680tIG3dntC7rGKLgErAgWNBmNg3OMc515AqB9t9BMU86++W9mEHMPyPvZHX68fU2OpUNDf9LM9R6nixrwii/BnRd/NUdbzAbJh+WvHz6BAOd5qnH9et5dU3T9OU60vCVvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mKf/QlUM5hgxXVWA2vDoy6x7bPq6pBlP7IQZ9SYUQEA=; b=fBvDbQNaQEXVNeK+QxZ6sak0TE0VwCeWT9eghulMxe78MMgYKeyyzcXiVvM57KFCWMIHGh3au6kvx2JgVRu3SkYQkVYY9Lm7P7RPQmJTc8Ik9+G+LuJexIquI2gFg4hypNmPN07+V3YyiYTC++mbHfHoJEWohjkynV/3a569gSUz9bZkRrBavynX1vnh6YAlyWab3DnXLv7Ox56rSNZVfGI4LeLoThkahmieeyXO1RcrfwPJYBrTMUMtRXN7JsWlHLRIDCh7Zn+jJV0YqNOGE5p0p89QSTwA5ytJHRI/TkseltxH2HMW9GG6ju/UqY+8JlvEOHwj+dMzUEJO5SA7Iw== 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=mKf/QlUM5hgxXVWA2vDoy6x7bPq6pBlP7IQZ9SYUQEA=; b=VJPjpqkHU+8iX70LswLdnbyr9VdAFCFroyFWWrFhCjOw7P+TAuKTj/x4nP8xCZvPj5Yr6BiRqx2fux5wSIYiLZ8QiGpAGx6UDtlseMf0+e1E2hoEO8XKMmysGQctjvJ0JqghS/Lb7taPxUF2uLQggks7snuKoJKJZpzFh97oKck= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <7ebfd1f1-5f46-4aff-a695-5e103d93e41c@citrix.com> Date: Mon, 12 Oct 2026 19:39:13 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , andriy.sultanov@vates.tech, guillaume.thouvenin@vates.tech, anthony.perard@vates.tech Subject: Re: [PATCH] tools/oxenstored: preserve socket fds across exec live-update, document SIGTERM limit To: Andrew Mbugua , xen-devel@lists.xenproject.org References: <20261012162258.811103-1-andrewprecious388@gmail.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: <20261012162258.811103-1-andrewprecious388@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0451.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1aa::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH5PR03MB7910:EE_ X-MS-Office365-Filtering-Correlation-Id: cebe1fe3-829e-4fd3-cd27-08df28901ed8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|10067099003|18002099003|22082099003|3023799007|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: G4dnLXLEVOZn4jTLqV7dxN4nbwJnAz6c0Q5esygrAV8pnGRelrii4+11oIyeE4A6jOfnRb+K5yaVteX1BfLSoOUnM7LsqaAx1G/mxmMgmBOGge29zoQ096n/zTatOr5Nx9o/VmwRxgmBerpdWjN+eCh8GOxOxABjLosGAfSw0EJhFnfQl9AukgKYM+8qdBrJKZwzVf73Vyg8Jk1yFu3b5gOX/Dqyy2oy0mjOwqk2ZKorsXNrrfneW0WPnugoYixYzz55spyU2o+f4aa55J+T5T3yuF72ZFK4r7QFqXO9s/ihUp7+GharOmRBR39rGBX7ai5wZj9iX1oGYhqWxb5+oetfaRjSJGGpxj2Kid5k21fEKrxR5hfppUw4YXOKPfeDzETZojmVYyjfjc8pU8B0gwnCjVizZSnkvwvz3y2yuaDV83iqL73ZhpkA2f1c2qv61bxN9KvLGVU0ZvkZUgEJDDa9QL2AKc6q7IfZEnBEaiiEz54UVMIK5gIiloGkwEuzmziNCtVQtUdP1rTaTOFQxlvolTqbyLao0eZlE7rB02M5kcLwb6ssv44QSvabXZjLa6TJlRFtdfCXn3tUxbxJoRmLdsycAo7tGq8Xb+5kIqjRb59geuPH0ry8tK7Kq/Ib2uUjtf0+d/pOUxYR3wRLV78DJmU5YtmoXR1tVdNu3UI= 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)(18002099003)(22082099003)(3023799007)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bC9xRVpoNVJUbGpNZTNFdXdIbW9IVVAwSXF4eFllTTZDR21yaGpIM1FOclpU?= =?utf-8?B?SkgyTHBOZUorZE9tY29qSUR3U2ZiNm5heDdYQ1RvS3VWWVdtb0ZkNzNVb0k0?= =?utf-8?B?blhMT0l5T2k0MXpQWmhPU1BPUzNkUjYvMVF1RC9wbFQycTZSYkdYK3VBcWRt?= =?utf-8?B?N0swc0J6ZUltb0xoYnRHV3B4ODVWMERxek8xZG1rWnVpck8wTVlzQTFmWWNh?= =?utf-8?B?WFc5WWZxbkh3OTM4bERVSFVkVmNOSUdobTBsLzVVYmlRZnhKbS9CSGYyclI2?= =?utf-8?B?R3BsWHZQVTFGSjFFMXEwRFp6M09taUZmcXpzbCtQSXVnSDVKaXNjUHNhVjg3?= =?utf-8?B?RGxlM3hpcGE5d0l1aVJFdGFUTDlmOVlyeW5LTUhMeDAwbHA4RUNmZDdLM25h?= =?utf-8?B?d0J0RVNaRldjTFFCcFhxWXNDWTQ4ZFJIQ1RhTUpkSHh5VmZpUkNWb0VYa2Zr?= =?utf-8?B?bjhvUzUxMmhWSU9Dakt4dXJ4NXAzd29iRHRUbXFoMGRkeDljVDdpWk45akdp?= =?utf-8?B?Q1VlSGtTSEJVZFBJMUZ3WnJVbTdONjB6NzRVRjI2VmpwNCtzSnRTWk5nS1Fk?= =?utf-8?B?R2swWHZpdnE2bW9zYVNQaWwyV2FrWHRRMDlrbGtXWHd4Tzh4cDFMQ3JlV2ZE?= =?utf-8?B?SVZ6R09OYXJwNDh5SDZ0b1I3SmpEbmw5czZpM2plbklCdFNhUHRVRXhQK1oy?= =?utf-8?B?T0ZhOURHWXpnS3drSVBKWktyWXQ3a3BWc2lxT0oyR3hhYlptVE1ab1RXOWtS?= =?utf-8?B?Q2NXanJFUzNvV0JCdk42WlNON1V4ZVB3MDNWQ2h3Wko4UXU1bE85MGRaQXJP?= =?utf-8?B?VnQxVGJxVnY0Y1FuV1MyUDM4UEVTS3o2czEyalhuS3lIZ25qR2NMbnNKWXBB?= =?utf-8?B?Q3Fmcml5Njk5VCtwZExFRHhwREorVmwwVW80TVcrdUp2QzVhZnlGUmlVNkkr?= =?utf-8?B?bUJGRWtyOEJRL2Z3VHNwUlc5TXllTE5STVNtRzU4UE0vTUhxdCsyb2J5S1V0?= =?utf-8?B?VHdMbkJTdGZUbWxXRERKNzlLVHBaZDBlK0hwSUpobkd6dXNEWFBHY3BWNFhM?= =?utf-8?B?d0VjN2tXeXZCa3lhM1N2QzZtMzY3aEU4cThSL1pBQ1FjL0RMVXNneWpjSHZq?= =?utf-8?B?V3FYT0MvTjk4aDJKRW44dWEwMmJoQ21HTXk0S3RldHB4dldlNFJ2c2Erc3U2?= =?utf-8?B?aDhwUlM5L1J3MXF5cVZFVXVCUmJ2WGZ3UmVRLzFvN3hXM0J0Nkt4VytnMlNV?= =?utf-8?B?bS9LdW1mcFFNVXdRRDJaWkFTQ1hNZDZ2Zk13T2lqNW5Pc3dNQ3Q3Z3d0eFlM?= =?utf-8?B?RTVLTytzVnJvcSs2NTAvMUlTM3RnUXlLMDBqMTdRb0dxbUd4TmYreGlOU3RZ?= =?utf-8?B?UDZIZDM5RXNjUUN3S0tMU05HVzRqb0hrL2JhTk9GVE1LeThMN014U0poSUZP?= =?utf-8?B?L2VXOVhNcE9xMEJRUVhBaVFIRE02OWkydVNBTEhzNENSY2laRG1yUXdUTjdZ?= =?utf-8?B?TExUWkxLWGMwY1hPQkwvTDEwWUxYa05UenFna2FFZ3dRKzFrUVJXRVdrWE0w?= =?utf-8?B?V3BFR0p3dUE2VXdzQnp4MGN4VkNMUzMrMmd1SHlaa2cxbkZibkJQTjg2d3ov?= =?utf-8?B?QXBENTVOT0hqK2lQM1g0TDRoOHdxTzhRaCtYbm0yREtQNGxjSmNxZEFwZUcx?= =?utf-8?B?by9qei9YTnRaRE94ME1CazYyZmhUY2hyQkF4TlRWV2JzaWU5T0RrSVVCSXZ1?= =?utf-8?B?ZnB0M2U0WGx6SUp0UU0wZjYxVmIwSXVDSExYSk1saWEvTDFpZ1V2cE1hY0tl?= =?utf-8?B?KzlZTHI1azNaWFpRQ2ZudTJpVTdTQjB6bWx1VjQ0UGFUd2ozb0NjdVZCSDZn?= =?utf-8?B?TTRJVWhoNWxMbFFIZXNMTzJRTDdWd2JlalVBYldjdzFuUFVDaW5ZTlZ5ajNO?= =?utf-8?B?UE9GaFNZQWtpZEdkdGNVMXVPSHJvMTJIY1M0K0o2NFBmbFlUR2duYTVieUlY?= =?utf-8?B?bWFlRnBTVVlTNUxESExvVXdrZHVSMkhRcmdrQ3VvRS80akNyL0o3NmxkVE93?= =?utf-8?B?SXhTNjhDMnVTbzdxSDdhYUpsNVlzM3hsY1JjazFWTjZNY0t2YTJZMmFQdXMy?= =?utf-8?B?Q3lwcVU4UlpKYVVORlFwSWlhYjZxTXp1TDV3Wlh4Ti82Z1RTTG95MUZnWkpU?= =?utf-8?B?cHU3VzgvRXRXZEZ6VkFnVkMyQnNGMFFrMk40eGRPajdSajZMbXQ5S0JCeTlL?= =?utf-8?B?SWVNZUFiMnBjQjBPcDFhcWIzc2ZOTTVCSWtJZHJPMU9nQWd2K2s5cXYwYjdL?= =?utf-8?B?VFc2cUVNWmZIR0duSFE2bTZpb3Uwa1BpVTF0RTYrcUtKVElBa3NXUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cebe1fe3-829e-4fd3-cd27-08df28901ed8 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2026 18:39:16.8713 (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: dhm+APXaEyNtvYBOyQfPi03eDXPXJ2W272VT8XB3eH+lKWQVmzfCkOPVVMFgzES/2M4TbdYDweZfo0bvyk2c5iNwy86wzaaB3ab/1zMGCdw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7910 X-purgate-ID: tlsNG-4011c0/1791830361-530D9CFC-B087B0A8/10/77776452383 X-purgate-type: spam X-purgate-size: 5008 On 12/10/2026 5:22 pm, Andrew Mbugua wrote: > Resending this patch a new after fixing mailing list spam rejection For future reference, you should have [PATCH RESEND] in the subject, and this note below the --- after your Signed-off-by tag explaining why. That way, it doesn't get inserted into the commit message when your patch gets taken off the list. > > The TODO comment at connection.ml: has_extra_connection_data dates back to > commit 42f0581a91 ("tools/oxenstored: Implement live update for socket > connections"), which started dumping anonymous (dom0 toolstack) socket > connections as "socket,fd" plus watches, but left the SIGTERM / > file-based restart case unsolved: > > (* TODO: what about SIGTERM, should use systemd to store FDS > || has_socket (* dom0 sockets not * dumped yet *) *) > > An fd number is only meaningful for an exec-based live-update where the > fd is inherited. It cannot survive a SIGTERM/file-based restart > where fd numbers from the old process are meaningless. That would > require stashing the fds in systemd. It doesn't require FDS.  It requires some external store of file descriptors, e.g. systemd FDS. xenstored has to work in non-Linux environments, and IMO will never gain a dependency like this.  We already have a self-exec mechanism; a TERM/restart mechanism is just extra complexity for no benefit, as it would need distro-specific logic to help keep it's FDs around. > > Additionally, Connection.dump never cleared CLOEXEC on the socket fd > (unlike DB.to_channel which does so for the listening socket), so even > an exec live-update including a forced one with `live-update -F` > which bypasses prevents_quit, loses the connection and restore hits > "Ignoring invalid socket FD". > > Resolving the TODO without regressing commit 42f0581a91: > - keep allowing idle sockets for exec live-update; pending partial > I/O still blocks via has_in/has_out and SIGTERM clients > simply reconnect. > - clear CLOEXEC in Connection.dump so the dumped fd actually survives > exec. > - replace the TODO with a comment explaining the remaining systemd fd > store future work for SIGTERM. > > Ive verified that make builds oxenstored cleanly "I've" and full stop at the end. If all you've done is build test it, how did you identify hitting "Ignoring invalid socket FD"? For a change like this, a build test necessary but not sufficient.  If you're unable to run it, you can ask for help, but FD issues can be very subtle and this can't reasonably go in as a speculative change. > > Signed-off-by: Andrew Mbugua > --- > tools/ocaml/xenstored/connection.ml | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/tools/ocaml/xenstored/connection.ml b/tools/ocaml/xenstored/connection.ml > index 37eb2444b9..e535e7cea6 100644 > --- a/tools/ocaml/xenstored/connection.ml > +++ b/tools/ocaml/xenstored/connection.ml > @@ -435,9 +435,15 @@ let has_extra_connection_data con = > let has_in = has_partial_input con in > let has_out = has_output con in > let has_nondefault_perms = make_perm con.dom <> con.perm in > + (* Socket (dom0 toolstack) connections are dumped as "socket,fd" plus > + watches by Connection.dump below. The fd number only survives an > + exec-based live-update when the fd is preserved across exec (see > + dump); it cannot survive a SIGTERM / file-based restart, where fd > + numbers are meaningless. That case would require stashing the fds > + in systemd (fd store / socket activation). Pending input/output > + already blocks above, so idle sockets are safe for exec live-update > + and SIGTERM clients simply reconnect. *) I'm going to go out on a limb and guess this is AI generated, because it's total slop. It's a full paragraph explaining why we don't something which itself is not relevant to how the logic works in the first place.  It's a backwards step. > has_in || has_out > - (* TODO: what about SIGTERM, should use systemd to store FDS > - || has_socket (* dom0 sockets not * dumped yet *) *) > || has_nondefault_perms (* set_target not dumped yet *) > > let has_transaction_data con = > @@ -464,9 +470,13 @@ let dump con chan = > Domain.dump dom chan; > domid > | None -> > - let fd = con |> get_fd |> Utils.FD.to_int in > - Printf.fprintf chan "socket,%d\n" fd; > - -fd > + let fd = con |> get_fd in > + (* Keep the fd across exec so an (exec-based, possibly forced) > + live-update can restore it via "socket,%d". File-based > + SIGTERM/restart cannot restore fds; that needs systemd fd store. *) > + Unix.clear_close_on_exec fd; > + Printf.fprintf chan "socket,%d\n" (Utils.FD.to_int fd); > + -(Utils.FD.to_int fd) Where do these sockets come from?  What flags where they opened with? ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 12 18:58:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 18:58:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446564.1662688 (Exim 4.92) (envelope-from ) id 1xGLEW-0004e4-N3; Mon, 12 Oct 2026 18:58:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446564.1662688; Mon, 12 Oct 2026 18: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 1xGLEW-0004dx-KP; Mon, 12 Oct 2026 18:58:48 +0000 Received: by outflank-mailman (input) for mailman id 1446564; Mon, 12 Oct 2026 18:58:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGLEV-0004dr-1l for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 18:58:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGLEU-00000001r31-3zCs for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 18:58:46 +0000 Received: from mail-lj1-f173.google.com ([209.85.208.173]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGLEU-00000004IZp-12dp for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 18:58:46 +0000 Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-3a9787a15bdso18646021fa.1 for ; Mon, 12 Oct 2026 11:58: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" 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=3SkwKd9YVjIqZr1KjbBgqpe3Yw+FpjEvGaoLeOvyvgo=; b=5fKlHHRUmNw2qcfpprL/fCMDMj hD3Xf6VH4jwS6Apk0ltqpm4mBzgeYqQVNRNY6Md8RjLiEsDhTBPScTKxpVn0ssKZZofAK+DoQYFCL krKWftqdFn6Kl8TTrXqOqk5nnE+srt3wF/NwuavD7lseAj1ACkUoOVKb1MljAcQEES1Y=; X-Gm-Message-State: AFq9FYIp0/wopv+A2NfjKxb69+LgdnigL2afjbicvpvWTjJUvMZ4J4yF Mq6qXe83y4YwMXuR+gwBp5ttZSge0xKCSFRH77X9JJpUcLorE/yc9vi/eEk9wq0NkZsskOU/Ufd x3slYEnhT8r1ImeromHmSoCzHwEZ/4uM= X-Received: by 2002:a05:651c:2209:b0:3a9:d9db:61a9 with SMTP id 38308e7fff4ca-3a9d9db6beemr14716171fa.23.1791831525638; Mon, 12 Oct 2026 11:58:45 -0700 (PDT) MIME-Version: 1.0 References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <125982a7-f491-4a10-98e9-d31f9f3b6444@suse.com> <90fbdbb4-be0c-4916-926e-0327a73b082d@suse.com> In-Reply-To: <90fbdbb4-be0c-4916-926e-0327a73b082d@suse.com> From: George Dunlap Date: Mon, 12 Oct 2026 19:58:33 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK960tpMafSxDlRnZrM5CbAqGHZsLcPiyeXVqx0vn-zrGd9AyHDzDRnHUAw Message-ID: Subject: Re: [PATCH 04/15] x86/setup: special treatment of initrd for PVH Dom0 To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2026 at 12:51=E2=80=AFPM Jan Beulich wr= ote: > Thank you very much for spotting both of these flaws. Both were first spotted by Opus 5.5; I mostly filtered and verified the issues then wrote a response in my own words. I figured it would be a useful way to contribute back that wouldn't delay the ASI series too much. (And I'm a bit torn between adding "Claude noticed.." all over the place, which sounds kind of pretentious or like shilling, or not mentioning it, and making it sound like I did all the work.) -George From xen-devel-bounces@lists.xenproject.org Mon Oct 12 20:19:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 20:19:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446583.1662699 (Exim 4.92) (envelope-from ) id 1xGMUB-0007zK-Bo; Mon, 12 Oct 2026 20:19:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446583.1662699; Mon, 12 Oct 2026 20:19: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 1xGMUB-0007zD-6x; Mon, 12 Oct 2026 20:19:03 +0000 Received: by outflank-mailman (input) for mailman id 1446583; Mon, 12 Oct 2026 20:19:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGMU9-0007z7-UF for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 20:19:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGMU8-006WX7-PP for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 22:19:00 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd409d-8faa-0a2a0a5109dd-0a2a4508ecae-12 for ; Mon, 12 Oct 2026 22:19:00 +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 6acd40b4-f659-0a2a45080019-d155802ac166-3 for ; Mon, 12 Oct 2026 22:19:00 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a02753c04fso12199045e9.3 for ; Mon, 12 Oct 2026 13:19:00 -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-4a18c1e33d2sm429813235e9.0.2026.10.12.13.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2026 13: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=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=1791836340; x=1792441140; 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=PHSe4BFFNpt47LbsXpx+CBTmAcYEiYVMx1Z4+dzV7Zs=; b=p8R8VrKii856k4jU+BHZjnLJVZVrhlsBygEiTHkEbFdU/NuO8ZB9dG5UqOf1bT93Jd Z8A3vGndCGsTqFmWzlnCpWrXEk9TDmYneMc5yXkNPvD4s0RcpRrdnW5VOuqlUj04x8Me tJGR+5HAwnvTWlDIHQ7Ne/huFGOeyb5hrGYzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791836340; x=1792441140; 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=PHSe4BFFNpt47LbsXpx+CBTmAcYEiYVMx1Z4+dzV7Zs=; b=pk4VoMk+ZXaeXNgCPS+Y5vXQnaenhr++9kWWeRzeBuw5NhrVhlLA+VAwB5Fm6v4T/N ng7F+zbl+4lNhVA5qbbJsFi7+GP9GLHAo66+z1nDpePgc1wNa94uQ+54jwhw/n5Q4d2/ d3XpjjHbn1TYPYlE93wDb6XgiCp1ES4Z6VR5t0O4K5xNVoKqveVx3wNIuIEe/K7BgHKG eaeziQvXQayeFkji8S/RAJ9hlMsm5gEXO+zP2KiNG+RKsjPM97AX9FYy7YTiz+P1Cjz7 TBAI5MCeCrJB8tpv4RtUTWYWbjbU8vTKVp3qyUUQkN40uG3E1jEv54+o/LrloX0UY9Yt Gd1A== X-Gm-Message-State: AFq9FYJqJD53tm/wBYeBCFL8rQx31dGGE3TNydkPzagwFJJWWB9F0n6w CL/NyB7F/EHlmODDGgODQxr/KoYJI0pjK33qVU6GEE/5hyBHeoE+e3vkr8lJ7D/LuU4bkwVZdnk uIJKr X-Gm-Gg: AYBFou1/FNzXSJIpuZeOt6+RZxGePs/Px75/qQnlrZIg6BGkfVQMoQBvlVFx8T9QMFu nPWa5GGmCL5ZHS7/UVPZkEURL+j50O+58l+cDr/UCfryh0d9fe/hmknAGrDhUJG+GTo2eaBUV7u YUeTJprKkR4wRLJkh8yzU5PpbK+V9gNaao0Jed/eMTgjnNVfjiW1W8GM7BUz/4J+fq0Vljj0kIZ 5cBYSfw2En5qP2agHnn3qowhaVAoHxQPmMg47LyKp931qbRXP0djHYFEHD/Mb8sJQdWKRTEpGH9 j8slas1NVQwwMODn/lxYcxv83KNKqGyrGV9qmmDzWUA+MYHf+bDPkNXi2hZ4sFhItsqf4bXtGzw 6OJpI8UtJF5suRQNY0kQhectAoXrq5TvUchhHWrbAxkodsI3VlclGxGfXVQEBMgVAP4azy/RmY4 791seBUnrUG9aBiV05tHor2HjH18vmjsDIu1xlod6fdf+LlkMLbIRE9wZZ5CYV9kVgz6R89olwS gO7coeWNvlE2Embc7Qsh9thYKWWc7xamNOsQd5yLkUZShoO X-Received: by 2002:a05:600c:4ecc:b0:49c:fa21:e749 with SMTP id 5b1f17b1804b1-4a18e4d55f2mr235134845e9.31.1791836339376; Mon, 12 Oct 2026 13:18:59 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin Subject: [PATCH] tools/ocaml/libs/xs: Create FDs with the correct CLOEXEC status Date: Mon, 12 Oct 2026 21:18:57 +0100 Message-Id: <20261012201857.714448-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-c1860d/1791836340-D755C87B-C306BFB0/0/0 X-purgate-type: clean X-purgate-size: 1434 ... rather than editing them after the fact. This capability exists from Ocaml 4.05 which is also our minimum supported version. Signed-off-by: Andrew Cooper --- CC: Andrii Sultanov CC: Guillaume Thouvenin Found while reviewing the other FD handling patch. --- tools/ocaml/libs/xs/xs.ml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml index addccc80099b..a088d67a8cb6 100644 --- a/tools/ocaml/libs/xs/xs.ml +++ b/tools/ocaml/libs/xs/xs.ml @@ -155,9 +155,8 @@ exception Failed_to_connect let daemon_open () = try let sockaddr = Unix.ADDR_UNIX(daemon_socket) in - let sock = Unix.socket Unix.PF_UNIX Unix.SOCK_STREAM 0 in + let sock = Unix.socket ~cloexec:true Unix.PF_UNIX Unix.SOCK_STREAM 0 in Unix.connect sock sockaddr; - Unix.set_close_on_exec sock; make sock with _ -> raise Failed_to_connect @@ -169,8 +168,7 @@ let domain_open () = with Unix.Unix_error(_, _, _) -> "/proc/xen/xenbus" in - let fd = Unix.openfile path [ Unix.O_RDWR ] 0o550 in - Unix.set_close_on_exec fd; + let fd = Unix.openfile path [ Unix.O_RDWR; Unix.O_CLOEXEC ] 0o550 in make fd let close xsh = Xsraw.close xsh.con base-commit: 0d3bb3c98bc99ec1c84ebb3df71b6e18daebff4f -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Oct 12 20:23:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 20:23:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446590.1662707 (Exim 4.92) (envelope-from ) id 1xGMYI-00019R-PQ; Mon, 12 Oct 2026 20:23:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446590.1662707; Mon, 12 Oct 2026 20:23: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 1xGMYI-00019K-MY; Mon, 12 Oct 2026 20:23:18 +0000 Received: by outflank-mailman (input) for mailman id 1446590; Mon, 12 Oct 2026 20:23:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGMYG-00019E-Cx for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 20:23:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGMYF-00AyZD-Ly for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 22:23:15 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd4196-2eae-0a2a0a5409dd-0a2a4503ac6a-18 for ; Mon, 12 Oct 2026 22:23:15 +0200 Received: from [52.101.72.72] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd41b3-fae8-0a2a45030019-34654848c5d1-3 for ; Mon, 12 Oct 2026 22:23:15 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by VI1PR03MB6525.eurprd03.prod.outlook.com (2603:10a6:800:199::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Mon, 12 Oct 2026 20:23:12 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.021; Mon, 12 Oct 2026 20:23: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=YG4JMSfH/bnvpfs2WoTd/5WOZiXwK/RBc1KaDQG6zz+VMtRpN4UoGiuuyqKbI1mEEKW/jaLg0/XUQte2C/ZViXRbbrO2IKEecvLWjaMOvVFJHaXNFEN+KVeZec+lTquTPbFhqOY2UhkLkLUgjHw5fRfNMcN+oyVcheDLam/QxOF+IG1jdW+D61NkisvHTjrlhn4bGFjJJb+Pe1biekwLSZ6NOWGTmnVG1ahWjq4xvo/BGDgrzPg7xjS5hSLHgrFsmYY6Hz8F9KYgPBXhHVY+nNhRzal1qN+hVYwtwWu7/tewaH81uP4gcZF/iOIYXMS1BLROX6J/l1jvV780uGzKNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=md+Lhsj9yCG295s24srLu2uJb8GGrTGsiItMkltFnns=; b=Am6/+ycH4vcsTBVUti7HDvfsj3E8QoBdW4GC9lBGIsaBytBhBDibutYoEBRnwo79fIx5piL0Ve8k4+hAgiUfrBGvyz8xFytuDyeIcbjsskTab5f/IYNcy/GuXzdjNOIPetNpzdq+u8jn0jtKclRyOwvqdRw1Pcgwag/3cOHzlcGf96u+C64BHBSkV3PldHoHVnn5nd2k1BeUFaIFvFBo1pVAbA8zwjIT1Xkf7FSmSwDpCSQkJhkELpblyhNqD+LvdCtOLCutWHUviJgkoqyJZsfSa3H040myvdLStGgks2Blf92rmufjwBdhZxSdfPHRGfw5FB1SM0gIEPjfKKG7kw== 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=md+Lhsj9yCG295s24srLu2uJb8GGrTGsiItMkltFnns=; b=kIVIn4Yyfsv94B2w5h6jRBg2Cx2ZjKEe+uDgAr6qesGBR7HAdrvjgnOkPaLzAwwrfGGz3a3OMvSCspyzCRo5vb/mEBbX3JAlLGCVa9np5f8wX8jTu1/nnd+R5pAjJGvvwjRvBuqJzzqjFQ6Z2g7aUQ0I1W5jNchc8boeVjtW9NeoSs7XCzJ6fgwiJad/gBQnJoVzt3inZsJ47opzS58QQkRP12eiqcfBFWm8xdhv516KQD4Kx6x1n4Nc1gATt4UNMxbRjnE+qzO42Gk7TC45JyNYADmU+jo0NS6P8KtaFyjJx8cn1LA6CmvXlLzuLkBqHx9EO0ucYbWLWkYebWYIvg== From: Dmytro Prokopchuk1 To: Nicola Vetrini CC: "xen-devel@lists.xenproject.org" , Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v2] Eclair: scan the last xen-syms linking pass on Arm Thread-Topic: [PATCH v2] Eclair: scan the last xen-syms linking pass on Arm Thread-Index: AQHdVn8C9qte4lKYxEOXexEb5NUBWrbyYIQAgAgBfQA= Date: Mon, 12 Oct 2026 20:23:11 +0000 Message-ID: <811e7879-ff47-4c87-bb55-53262eedcd71@epam.com> References: In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|VI1PR03MB6525:EE_ x-ms-office365-filtering-correlation-id: 9aee6cbe-ab10-43be-b9c5-08df289ea353 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|42112799006|1800799024|376014|366016|18002099003|22082099003|10067099003|13003099007|3023799007|4133799003|11063799006|5023799004|4143699003|261009223027099003|38070700021|56012099006|260925022911599003|260925021311599003|260925021911599003; x-microsoft-antispam-message-info: CBuzninQ8PTwQNQ44LCwvvYuQG96XAXRHFUi4YkmSd1t/yWCjcZeRWXGaJhXRAmiSP9wcQmzjvln/FVpIc9a9+ZS0fifgHUqjyW5XIlB62p37U9+8032jaxN2qd2TgYV/msoy8lECjOwoldsXf0XQbyBLtsGlYPPdfCdKWzm3J7Xtp9Rag+rWgpNXVybpfDj0vZoHC8JvJKDkAgxioXkBTD2ADR48FrJnGV8wcQg3ud6Y3t6lfdI9uJAP75ZUnwwTH0aX0zIYbGGOQYwCKmoc4Y1R8TyD5vqcJcPmdqbXt9GZ4UJ1/FAkCz7zwyv0dFRKgUnrbd0r3x94yn/zDaJWrEW7UnD1KQNlVEequF5YSVWV9LDvLaQteRdWz83nsv6gnc4z2gr1CY4U2/zvu3kTxhvWTTddA8y24kK64AAnZnVQNX8T9FD1O8DuodsNzR8Bs4lelFhGghcARsUYsiS52v+6Yn1rEEdSWEVzclqAdpd5G6SSUFkZm6gMXyMk9tHhnK2sNlNIfxHJEFOEQSzQTy9GwQ7qWKGLUU5JL7ukfjpYVlyGwpgo7pZtw8jlhlzvHAWX3yDYKyFjsKjqdDz5syNQFyDUqBdGDGm6MShUMS3hjO0i+LArT7CH9yqqjLAPBd044JJImMijBa3GsfmcGu9rCVa+rK1zNQLR+ohgNc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(42112799006)(1800799024)(376014)(366016)(18002099003)(22082099003)(10067099003)(13003099007)(3023799007)(4133799003)(11063799006)(5023799004)(4143699003)(261009223027099003)(38070700021)(56012099006)(260925022911599003)(260925021311599003)(260925021911599003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dThNenA4VHRodDJHendMaG1WN1JSWjI5amRvYjQ5OGhhSXNIbDJxR3hNR3h3?= =?utf-8?B?V0R0RU92ZnIvQXBNUGovTkJic2lqcnBlZ21LenNlWTBjL2lVNkFRY2FVZGJJ?= =?utf-8?B?OEVRdXFKZGRSRHRWYU50VW5ibW9HanZLYUZFN1g0VVI4N01kT3NZN1QzVkxB?= =?utf-8?B?b1JJS2pWTUZNZGlMZkNLT0RvWVV4ZjdQd3A5Q0dNSjBSZ2cxV2pyTXp3eU5P?= =?utf-8?B?d3RHRExVbEo2dGFaWDBsV2I1dTdVbnVReUVVbk4xVEdHTUlTanJIc1B5WFVO?= =?utf-8?B?ekh2WE1qR3BxU3hXZ21SeWMwOEt1V1lyWk1MSHUzUkp5ZXNYNDZtckFJY1JX?= =?utf-8?B?Mm90MkRNcWN4Y1J5TmxzODc2Q0E1OGhVcnlWTzdGd0pxUTlZdUk2T3FVUXpw?= =?utf-8?B?bzRjS1BSZFZuZkhGT29lRmNuMnR3bHhZaWZNOW1ycmtjbCtwWU1qUlpmL09S?= =?utf-8?B?Z3UzNDdUQnVDT2tZMmE2STgrdWNXc3JDbGpBb1dYOUNEcU9hMkgwRjMxR3Yy?= =?utf-8?B?WElTdmluR1Uzd0tuZGNYOUJPb0NvM2Z6ZlRvcXpmTW01M2ZXM3JRZTRVUUI0?= =?utf-8?B?SlMrYytMNGNHZzZTNjJMb010eWtMQ0lDUGlBcHh4Y2oyL2orY2hPK3NkTGlm?= =?utf-8?B?bjRvQXJic3Q3Sk9KNmp6V2t3bjJFNnBud25mdnJzcy8rSm81VDNJSm0ycEJ5?= =?utf-8?B?VHdERW1hSk9ITnlndlUyeEx5SEg4Ukt4dXErbVcrbElwZ1ZrcmJpQWp0UHA4?= =?utf-8?B?RkZpUG53NkJId1ZUTzkxQVYzeGdCa2hHeVlWM3c5c2xVOVVUb0pEVkRyTGxJ?= =?utf-8?B?c3BXR1VIT1poalE1V1Q5TEpYTlVSZ2UzWmh4T3RIMVVJRk5WS2s5aXhrdmxz?= =?utf-8?B?cUtKeHZheWdGVjNpSXNDR2x5VTFZV1pFenV6ZjI0blIrVUNGYlRvWlBLT2Vo?= =?utf-8?B?K0l3L0wzZHNRNG9EcnRRTG51SWJBdFNuMzZnT3BEK0R5YzY3dUJ3SkphbTdy?= =?utf-8?B?eWZJUUtvTUNFeE9TSHBmeWMyOURIVEUraUh2Wm1OWUthN3lGMzJwZ1c0MkNW?= =?utf-8?B?TkxuZEUrOUt2UzFBMnJoWisyU2txb0diRUhKeDA4cUVMU0k2UkNSQ0tRZnd6?= =?utf-8?B?UzdIYUZ3YkhmYzBTc1QyUE1Od0R3bi93aWJOVVdoelBWRTc2c2hzVllzZGJB?= =?utf-8?B?Mjg0aEVmanFOQStZZDV0NlhFemxmYlZhTTB3QlJGZTI5OEdteFVaMkJFUzNT?= =?utf-8?B?V1ZMSjFLQTNLdWNBN3cxVkVlSXJaSlNEVkRsZ3NDTjVlZk5SUUNkL0lnT2Ra?= =?utf-8?B?Z1lTdUZUdUQ2dXR5UlowdVpIdVZ0Q1JJb2NuM0o4ZUd4ZkpUWCt2ZWNnelVI?= =?utf-8?B?TnlZVnBNU3BLUCtFSXpRNUFQVmV4RDhVbmJtMVY0OVJpd2dUbS9GNGZPVVEv?= =?utf-8?B?RmpTME8vOEhmOHhxYzFiUTk1Vndtd1hvQTlSNnVDOGt1RlVBTHVHS3A0OFJE?= =?utf-8?B?N3FJVUVZZ04zdWRqbWNDQ0IwUjRjTHEweU0yTWJoU29ZRVBPZ2U2MkZ0N0Ux?= =?utf-8?B?WGVCdVU2dmtvcWRVdlpEZCtQU0I2Vk9zekhxTGdJUlVXVGlOS3FsRkFVZVRu?= =?utf-8?B?ay9iSEcvV1pXRjNEY3NUV0xrSlNjRTJna25MWnBaNldnVmFIbWdCdzBDcGln?= =?utf-8?B?eXYwczVTRW55ZUFXVHNLTUN4bERkdncvZlpLN2JXbDdteWtIY0QvQkdKVll2?= =?utf-8?B?K1pTamZjbXdiYlV6UmZuQm1SSHF2T3cyLzRsam9IVi90T04vS2hFeGhmckFG?= =?utf-8?B?OE4yUGhXakVxb1pPSmFubnMrRVBabzhSTFdLZDRKV25PbndEUjlKVWJGeSsx?= =?utf-8?B?M21xR1RNVG5YWElvcGxyWHFVeklZN0paeldNNlFyZmhvckM5NXBzdm43dStJ?= =?utf-8?B?Vkw0YmlzWkpYWGI5Qy9ZaUJNakowRnNHQ3orZHUzK0tVK3d1aDFVQkozR3Mw?= =?utf-8?B?cGFhdVJueUZkUW9ncUUxYkdlUDJSSnFQeG9LZ2N1WUpuUVVFeVk4UHVnZlZh?= =?utf-8?B?VDJBcUhNQnkzSEY1VWxQa2dKczVFdi9US3VQSVRMMCthMVNRVlEwcUsvenZa?= =?utf-8?B?clUzWkgzWWdkMVJvd1I4dXJtV1ZjNDBpOExQR1BIZFU5WkE1a2xQSVc1Yklp?= =?utf-8?B?NnpKRmN4N3dSMFhXSVRBU3EyZzJrUEZGVzg3Sy9RNVlkbmFhdTEzb0c3c0lB?= =?utf-8?B?VG42b3BlTTVBS0g4WG9ZSVErRVh1bFZZTjVpSUN2QVB4aVROL1ZCYmFuaTRN?= =?utf-8?B?a20ySGFiZWNEbllOZnZBM3lmTFFDYm4rT2VZaTR2elMxc0I0Y3ZTSUtVOXoy?= =?utf-8?Q?9gsKuR6G5MYHZm4w=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <34E44B3D7EB39B4699651DDB560D816D@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9aee6cbe-ab10-43be-b9c5-08df289ea353 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2026 20:23:11.9647 (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: /C1r+CGw97DtUS2uV0L4+2B1TkRZMQD2qF0/TeqeTIl8BhpzFwlbfgDCRu/WGzxNMQtZm3RNxfeZhzdYYqVGZEE7cTO81CFIf8WnJBNquww= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6525 X-purgate-ID: tlsNG-33051d/1791836595-77EC24E9-A80C27A1/0/0 X-purgate-type: clean X-purgate-size: 7346 DQoNCk9uIDEwLzcvMjYgMjE6MDcsIE5pY29sYSBWZXRyaW5pIHdyb3RlOg0KPiBPbiAyMDI2LTEw LTA3IDE5OjEyLCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+PiBUaGUgaGlkZSBwYXR0ZXJu IC54ZW4tc3ltcy5bMDEzXSBsZWF2ZXMgcGFzcyAyIHZpc2libGUuIE9uIHg4Ng0KPj4gTEFTVF9M SU5LSU5HX1BBU1MgaXMgMiwgc28gdGhhdCBpcyB0aGUgZmluYWwgbGluay4gT24gQXJtDQo+PiBM QVNUX0xJTktJTkdfUEFTUyBpcyAzIGFuZCB0aGUgZmluYWwgaW1hZ2UgaXMgLnhlbi1zeW1zLjMu IFBhc3MgMiBpcw0KPj4gdXN1YWxseSBvbmx5IGEgc3ltbGluaywgc28gRWNsYWlyIHNhdyBubyBw cm9ncmFtIGxpbmsgYW5kIHJlcG9ydGVkIGV2ZXJ5DQo+PiB0cmFuc2xhdGlvbiB1bml0IGFzIHVu cmVhY2hhYmxlLg0KPj4NCj4+IEJlZm9yZSB0aGUgYW5hbHlzaXMgYnVpbGQsIHJlYWQgTEFTVF9M SU5LSU5HX1BBU1MgZnJvbSB0aGUgYXJjaGl0ZWN0dXJlDQo+PiBtYWtlZmlsZSBhbmQgdGhlIHBh c3MgbnVtYmVycyBmcm9tIHRoZSBmb3JlYWNoIGxpc3QgaW4NCj4+IHhlbi9zY3JpcHRzL01ha2Vm aWxlLmxpbmsuIEhpZGUgZXZlcnkgcGFzcyBleGNlcHQgdGhhdCBvbmUuIEFuIGVhcmxpZXINCj4+ IHBhc3MgdGhhdCBpcyBhIHJlYWwgbGluayBzdGF5cyBoaWRkZW4uDQo+Pg0KPj4gRml4ZXM6IGE0 MDFiNWM5ZGMzNSAoIkVjbGFpcjogcmUtZW5hYmxlIHNjYW5uaW5nIG9mIHRoZSAoYWxtb3N0KSBm aW5hbCANCj4+IGxpbmtpbmcgc3RlcCIpDQo+PiBTaWduZWQtb2ZmLWJ5OiBEbXl0cm8gUHJva29w Y2h1ayA8ZG15dHJvX3Byb2tvcGNodWsxQGVwYW0uY29tPg0KPj4gLS0tDQo+PiBDdXJyZW50IHBh dGNoIGlzbid0IHRlc3RlZCwgc2VudCBqdXN0IGZvciByZXZpZXcgKGlmIHRoaXMgYWNjZXB0ZWQs IA0KPj4gSSdsbCBydW4gcGlwZWxpbmUpLg0KPj4NCj4+IENoYW5nZXMgaW4gdjI6DQo+PiAtIHVw ZGF0ZSBjb21taXQgbWVzc2FnZQ0KPj4gLSBnZW5lcmF0ZSBoaWRlIHBhdHRlcm4gYmVmb3JlIGFu YWx5c2lzDQo+PiAtIHJlYWQgTEFTVF9MSU5LSU5HX1BBU1MgZnJvbSB0aGUgYXJjaCBNYWtlZmls ZSBhbmQgcGFzcyBudW1iZXJzIGZyb20gDQo+PiB0aGUgTWFrZWZpbGUubGluaw0KPj4NCj4+IExp bmsgdG8gdjE6DQo+PiBodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz8gDQo+PiB1cmw9aHR0cHMlM0ElMkYlMkZwYXRjaGV3Lm9yZyUyRlhlbiUyRjJmNjdlZjdj NDU5M2QzYWI5NGI3NWI1YjgxOWU3ZTA0NmUwNTU3OTYuMTc5MTI5MzY4MC5naXQuZG15dHJvLl81 RnByb2tvcGNodWsxJTQwZXBhbS5jb20lMkYmZGF0YT0wNSU3QzAyJTdDZG15dHJvX3Byb2tvcGNo dWsxJTQwZXBhbS5jb20lN0M5YjA1MDExMDFhZjk0MDAyMDE1NzA4ZGYyNDlkZTQ4ZiU3Q2I0MWI3 MmQwNGU5ZjRjMjY4YTY5Zjk0OWYzNjdjOTFkJTdDMSU3QzAlN0M2MzkyNjk5MzI3MDgzNzM3OTEl N0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKRmJYQjBlVTFoY0draU9uUnlkV1VzSWxZaU9pSXdM akF1TURBd01DSXNJbEFpT2lKWGFXNHpNaUlzSWtGT0lqb2lUV0ZwYkNJc0lsZFVJam95ZlElM0Ql M0QlN0MwJTdDJTdDJTdDJnNkYXRhPWdodzlsQTJGcFJvM2ZWN1A4SEJzbG1DRWJTSkIyOUF2S1RI ZGdXWmZyNnclM0QmcmVzZXJ2ZWQ9MA0KPj4gLS0tDQo+PiDCoC4uLi9lY2xhaXJfYW5hbHlzaXMv RUNMQUlSL2FuYWx5c2lzLmVjbMKgwqDCoMKgwqDCoCB8wqAgMiArLQ0KPj4gwqBhdXRvbWF0aW9u L2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHl6ZS5zaMKgIHzCoCAzICsrKw0KPj4gwqAuLi4v RUNMQUlSL2dlbmVyYXRlLXhlbi1zeW1zLXBhc3Nlcy5zaMKgwqDCoMKgwqDCoMKgIHwgMjAgKysr KysrKysrKysrKysrKysrKw0KPj4gwqAzIGZpbGVzIGNoYW5nZWQsIDI0IGluc2VydGlvbnMoKyks IDEgZGVsZXRpb24oLSkNCj4+IMKgY3JlYXRlIG1vZGUgMTAwNzU1IGF1dG9tYXRpb24vZWNsYWly X2FuYWx5c2lzL0VDTEFJUi9nZW5lcmF0ZS14ZW4tIA0KPj4gc3ltcy1wYXNzZXMuc2gNCj4+DQo+ PiBkaWZmIC0tZ2l0IGEvYXV0b21hdGlvbi9lY2xhaXJfYW5hbHlzaXMvRUNMQUlSL2FuYWx5c2lz LmVjbCBiLyANCj4+IGF1dG9tYXRpb24vZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9hbmFseXNpcy5l Y2wNCj4+IGluZGV4IGM2ZTFhN2E5NWQuLmRmMTAwNmJjYWEgMTAwNjQ0DQo+PiAtLS0gYS9hdXRv bWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHlzaXMuZWNsDQo+PiArKysgYi9hdXRv bWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHlzaXMuZWNsDQo+PiBAQCAtMzcsNyAr MzcsNyBAQCB0aGVpciBTdGFuZGFyZCBMaWJyYXJ5IGVxdWl2YWxlbnRzLiINCj4+IMKgLWRvY19i ZWdpbj0iRG8gbm90IGFuYWx5emUgaW50ZXJtZWRpYXRlIGxpbmtpbmcgYXJ0aWZhY3RzLCBhcyB0 aGV5IGRvIA0KPj4gbm90IGRpZmZlciBmcm9tIHRoZWlyIGZpbmFsDQo+PiDCoGNvdW50ZXJwYXJ0 cyBmb3IgdGhlIHB1cnBvc2VzIG9mIE1JU1JBIEMgc3RhdGljIGFuYWx5c2lzLiINCj4+IMKgLWZp bGVfdGFnKz17eGVuX2VmaV90bXAsICJeeGVuL1xcLnhlblxcLmVmaVxcLihbMDFdfGFsdFxcLi4q KSQifQ0KPj4gLS1maWxlX3RhZys9e3hlbl9zeW1zX3RtcCwgIl54ZW4vXFwueGVuLXN5bXNcXC5b MDEzXSQifQ0KPj4gKy1ldmFsX2ZpbGU9eGVuX3N5bXNfcGFzc2VzLmVjbA0KPj4gwqAtZnJhbWVz Kz17aGlkZSwgImtpbmQocHJvZ3JhbSkmJnRhcmdldCh4ZW5fc3ltc190bXB8fHhlbl9lZmlfdG1w KSJ9DQo+PiDCoC1kb2NfZW5kDQo+Pg0KPiANCj4+IGRpZmYgLS1naXQgYS9hdXRvbWF0aW9uL2Vj bGFpcl9hbmFseXNpcy9FQ0xBSVIvYW5hbHl6ZS5zaCBiLyANCj4+IGF1dG9tYXRpb24vZWNsYWly X2FuYWx5c2lzL0VDTEFJUi9hbmFseXplLnNoDQo+PiBpbmRleCAyMzU2ZmM0MDA3Li5lZjU5ZTg3 MjEyIDEwMDc1NQ0KPj4gLS0tIGEvYXV0b21hdGlvbi9lY2xhaXJfYW5hbHlzaXMvRUNMQUlSL2Fu YWx5emUuc2gNCj4+ICsrKyBiL2F1dG9tYXRpb24vZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9hbmFs eXplLnNoDQo+PiBAQCAtNzgsNiArNzgsOSBAQCBleHBvcnQgRUNMQUlSX1BST0pFQ1RfTkFNRT0i WEVOXyR7VkFSSUFOVH0tJHtTRVR9Ig0KPj4gwqBybSAtcmYgIiR7RUNMQUlSX09VVFBVVF9ESVI6 P30vKiINCj4+IMKgbWtkaXIgLXAgIiR7RUNMQUlSX0RBVEFfRElSfSINCj4+DQo+PiArIyBHZW5l cmF0ZSBoaWRlIHBhdHRlcm4uDQo+PiArIiR7U0NSSVBUX0RJUn0vZ2VuZXJhdGUteGVuLXN5bXMt cGFzc2VzLnNoIg0KPj4gKw0KPiANCj4gSSB3b3VsZCBwcmVmZXIgaXQgaW50ZWdyYXRlZCBpbiBb MV0gaW5zdGVhZCwgcnVubmluZyBpbiBwcmVwYXJlLnNoLiBBdCANCj4gbGVhc3Qgd2Uga2VlcCB0 aGVzZSBjYWxscyB0byBFQ0wgZ2VuZXJhdGlvbiBzY3JpcHRzIHRvZ2V0aGVyLg0KDQpBY2suIEkn bGwgcHJlcGFyZSB2My4NCg0KPiANCj4gWzFdIGh0dHBzOi8vZXVyMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vPyANCj4gdXJsPWh0dHBzJTNBJTJGJTJGZ2l0bGFiLmNvbSUyRnhl bi1wcm9qZWN0JTJGaGFyZHdhcmUlMkZ4ZW4lMkYtIA0KPiAlMkZibG9iJTJGc3RhZ2luZyUyRmF1 dG9tYXRpb24lMkZlY2xhaXJfYW5hbHlzaXMlMkZFQ0xBSVIlMkZnZW5lcmF0ZV9lY2wuc2glM0Zy ZWZfdHlwZSUzRGhlYWRzJmRhdGE9MDUlN0MwMiU3Q2RteXRyb19wcm9rb3BjaHVrMSU0MGVwYW0u Y29tJTdDOWIwNTAxMTAxYWY5NDAwMjAxNTcwOGRmMjQ5ZGU0OGYlN0NiNDFiNzJkMDRlOWY0YzI2 OGE2OWY5NDlmMzY3YzkxZCU3QzElN0MwJTdDNjM5MjY5OTMyNzA4NDAzMjc0JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SkZiWEIwZVUxaGNHa2lPblJ5ZFdVc0lsWWlPaUl3TGpBdU1EQXdNQ0lz SWxBaU9pSlhhVzR6TWlJc0lrRk9Jam9pVFdGcGJDSXNJbGRVSWpveWZRJTNEJTNEJTdDMCU3QyU3 QyU3QyZzZGF0YT1yb1pvTCUyQm9pcGhMOWEwaEpoT1dFOSUyRnIzTFNyWXBmJTJCT09nWlJidlo5 SE4wJTNEJnJlc2VydmVkPTANCj4gDQo+PiDCoCMgUGVyZm9ybSB0aGUgYnVpbGQgKGZyb20gc2Ny YXRjaCkgaW4gYW4gRUNMQUlSIGVudmlyb25tZW50Lg0KPj4gwqAiJHtFQ0xBSVJfQklOX0RJUn1l Y2xhaXJfZW52IiBcDQo+PiDCoMKgwqDCoCAiLWNvbmZpZ19maWxlPScke1NDUklQVF9ESVJ9L2Fu YWx5c2lzLmVjbCciIFwNCj4+IGRpZmYgLS1naXQgYS9hdXRvbWF0aW9uL2VjbGFpcl9hbmFseXNp cy9FQ0xBSVIvZ2VuZXJhdGUteGVuLXN5bXMtIA0KPj4gcGFzc2VzLnNoIGIvYXV0b21hdGlvbi9l Y2xhaXJfYW5hbHlzaXMvRUNMQUlSL2dlbmVyYXRlLXhlbi1zeW1zLXBhc3Nlcy5zaA0KPj4gbmV3 IGZpbGUgbW9kZSAxMDA3NTUNCj4+IGluZGV4IDAwMDAwMDAwMDAuLmUzNzk1ZTgyMzQNCj4+IC0t LSAvZGV2L251bGwNCj4+ICsrKyBiL2F1dG9tYXRpb24vZWNsYWlyX2FuYWx5c2lzL0VDTEFJUi9n ZW5lcmF0ZS14ZW4tc3ltcy1wYXNzZXMuc2gNCj4+IEBAIC0wLDAgKzEsMjAgQEANCj4+ICsjIS9i aW4vYmFzaA0KPj4gKw0KPj4gKyMgSGlkZSBldmVyeSB4ZW4tc3ltcyBsaW5raW5nIHBhc3MgZXhj ZXB0IExBU1RfTElOS0lOR19QQVNTLg0KPj4gKyMgVGhlIHBhc3MgbGlzdCBpcyB0aGUgZm9yZWFj aCBpbiB4ZW4vc2NyaXB0cy9NYWtlZmlsZS5saW5rLg0KPj4gKw0KPj4gK3NldCAtZQ0KPj4gKw0K Pj4gK2NkICIkKGRpcm5hbWUgIiQwIikiDQo+PiArYXJjaD0kKGVjaG8gIiR7WEVOX1RBUkdFVF9B UkNIfSIgfCBzZWQgLWUgJ3MveDg2LioveDg2LycgLWUgJ3MvYXJtLiovIA0KPj4gYXJtLycpDQo+ PiArbGFzdD0kKHNlZCAtbiAncy9eTEFTVF9MSU5LSU5HX1BBU1MgKjo9ICpcKFswLTldXCkuKi9c MS9wJyBcDQo+PiArwqDCoMKgICIuLi8uLi8uLi94ZW4vYXJjaC8ke2FyY2h9L01ha2VmaWxlIiB8 IGhlYWQgLW4gMSkNCj4+ICtwYXNzZXM9JChzZWQgLW4gJ3MvLipmb3JlYWNoIG4sXChbMC05IF0q XCkuKi9cMS9wJyBcDQo+PiArwqDCoMKgIC4uLy4uLy4uL3hlbi9zY3JpcHRzL01ha2VmaWxlLmxp bmsgfCBoZWFkIC1uIDEpDQo+PiArdGVzdCAtbiAiJHtsYXN0fSINCj4+ICt0ZXN0IC1uICIke3Bh c3Nlc30iDQo+PiAraGlkZGVuPSQocHJpbnRmICclcycgIiR7cGFzc2VzfSIgfCB0ciAtZCAiICR7 bGFzdH0iKQ0KPj4gKw0KPj4gK3ByaW50ZiAnJXNcbicgXA0KPj4gK8KgwqDCoCAiLWZpbGVfdGFn Kz17eGVuX3N5bXNfdG1wLCBcIl54ZW4vXFxcXC54ZW4tc3ltc1xcXFwuWyR7aGlkZGVufV1cJCAN Cj4+IFwifSIgXA0KPj4gK8KgwqDCoCA+eGVuX3N5bXNfcGFzc2VzLmVjbA0KPiANCg0KDQpCUiwg RG15dHJvLg== From xen-devel-bounces@lists.xenproject.org Mon Oct 12 20:49:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Oct 2026 20:49:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446599.1662716 (Exim 4.92) (envelope-from ) id 1xGMxJ-0004mR-NR; Mon, 12 Oct 2026 20:49:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446599.1662716; Mon, 12 Oct 2026 20: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 1xGMxJ-0004mK-KD; Mon, 12 Oct 2026 20:49:09 +0000 Received: by outflank-mailman (input) for mailman id 1446599; Mon, 12 Oct 2026 20:49:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGMxI-0004mE-RQ for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 20:49:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGMxH-007HmJ-7h for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 22:49:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd47c1-e002-0a2a0a5209dd-0a2a450a805c-8 for ; Mon, 12 Oct 2026 22:49:07 +0200 Received: from [52.101.69.72] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd47c2-f2d2-0a2a450a0019-34654548b54b-3 for ; Mon, 12 Oct 2026 22:49:07 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by DBAPR03MB6408.eurprd03.prod.outlook.com (2603:10a6:10:194::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Mon, 12 Oct 2026 20:49:04 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0496.021; Mon, 12 Oct 2026 20:49: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=sgLoSrNuGWodVN7wcfd1MjJsXf2h1FEGYogkZl8HmC82bB/sqrAMrGKJb60OIGaGGw03+s4O/6JUsTwwM57emJJuPdAgfTqHQWHW/6bhkrEpeY6B/yRkyfYdHk5NmYcwkXxrCY+2eTp2AQE9cc0mf3uj9rmxP6NuVAm5rg5pKOL88nIwWv4WWa5bp6EPcPyXriY3RCMS1mtg1Sb9ugxm7VcSnNP/kC8kfDkX2oRMTrPEknQGyq/C+DY/50Fmm7NiVaiT3MPIpv4hCWZzkbKYxF9OxVqIAwYIKv3JhHKyCXtO5wqQGgc2zPV74rh9RrC0d01iSFilOf96sgRxzyolLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1JMJZ3NGsj36GPx+oHzG6prpExv9HE2gV3Modk9pemg=; b=EEDujCm23notyZactZeG0asnY/7cSL9sm050ek+Nyez/HurbdGTxBeLMAweIkTPk2AoDY1jMZ810mT4ZDjv1k3jigUSMN84eYjtFWfrFQRe522ThFdY7CakYoqniEOdVbjHmZayC032sEzj2+67yreXxl4ni8HksD6TtPBc/G+GDikSSudh44z2N09RY7TbsvNkSbh0vLChR5jXedO8rTAdZOPBpt04I0zAVW1HHk817W41SKdrPcvvpEvaVTXtz7tFC/5GSRCiHULySoNsJZpnCE1C3ypqkBnH7XKtcYhpMKP6BUakYw4MLFtls8mFXnkl8V5bVBLP8l8tu4ino/A== 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=1JMJZ3NGsj36GPx+oHzG6prpExv9HE2gV3Modk9pemg=; b=GXkNyUvuedzMJhpVFi5dVUSBEprcpR9RjcwY688WLJtFpAhpcxfOaZzUXegTrJruh4MT57bHB3oNQ8H2L4+Oj/5Id6xCyBgBp9STFreiAMhTHl8+Rr17gBp2qPU00VrOh8Fpzw/0FDy2DXuIOteQrArtcvcrRGhhudkxHB5WvJGslQf7MGe6NUmHGWJsGhULaQIh28rq8IA3AWDef4IOM9MnA0GPox84TBFJf1GfSb74228uSd3bCZq0j1LoPFw8VO4ezEbnNaEbBGPWPshE/RgEn6KHFlaBO1/M9F65m5K2pqBRGJcV6kXDtU8pgaNL+N7+K3d453D0C9gHRt2zqw== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini Subject: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm Thread-Topic: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm Thread-Index: AQHdWose+3ny6aV1J0Gq+fH4413ZRA== Date: Mon, 12 Oct 2026 20:49:04 +0000 Message-ID: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|DBAPR03MB6408:EE_ x-ms-office365-filtering-correlation-id: b1f85738-2559-439d-7149-08df28a240ab x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|42112799006|366016|1800799024|23010399003|5023799004|11063799006|38070700021|56012099006|18002099003|6133799003|260925022911599003|260925021911599003|260925021311599003|261009223027099003|10067099003; x-microsoft-antispam-message-info: CBxwf3bV0Oh5/PDtZFd4wKyB/8L1h3bbEInuFZlqa7cHFKBndHaJ1DG43Xf37XTDreZydjUVuBZXWTkv+zwE+MZCoNdaWjtzSiETiTg06NInkm9SiRiOjrNK/N18Pu0doT3I+9Ydmc/7lpTdIRaQnFleq0buUsZ+TuAbd3fsQBlRTTC9PmAZTUvVn32bV/aI99z9UFwE+R0Az1yMIjyzbPg8Qki07faXU9koqaGtYHNumMsOw5eaYEkN+B5XqhgoR1kKtHXYT2qd2pArLAwzx2BgBJymZj+tFVJtuES1L8kCgB4TH9jkvs9UD9Gkn6FNB326ryQdXa4RSOxlkP3FzkKDHpo7XAbjWTNF9/2MNLjLmOc3d2pMFSZ8MtT0S7095Fp7HOnRYR6QlNmyeFTNK0MxMkYmEllzuQGUJLBt6gpCvS5cjIeMct/6SivWrr0LDE9yyCyASMxQC7zvF3WZmj668WtWlonGtgqfWC+MR+jmBSiFPH5TQ/Kb4VWSQ4r5r9IRgVXdXldhVYc5V8XU6VQuFfAe89iJVIDQg4yXRv2kHEaAhVmVvzKo6kg3pvrM2A0U3L/oiMHbsvqMMnkHQmA8mFxcZMKhwkbn5ta3pdZ9HoTRhpsW9DijFV+okTdmRM8/XTxZtfd0Ve2xkegxm3GEGFuiFrAMvfRZJo4sHtM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(42112799006)(366016)(1800799024)(23010399003)(5023799004)(11063799006)(38070700021)(56012099006)(18002099003)(6133799003)(260925022911599003)(260925021911599003)(260925021311599003)(261009223027099003)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Y83hoaX2wCr9oyZXeYmqlT3lo49ifrfB6B1MU9uLGNgx/5BRgcM3yFlqfc?= =?iso-8859-1?Q?XTOYuq21ihL8AqqhzXOTOZrZSRSz7wdGTpsGcQHUU+2+L9QKXcbf37EI4x?= =?iso-8859-1?Q?vyiJT4mtz5oQwiI0kY54X95LwGfiQ0VCK66rhDpRGVbZn3NNIBhr8CxaKE?= =?iso-8859-1?Q?XrQLac3plLbVNkuEPwM5Vq83WouN/yzRza4Yrt3kEWJimzCfds8A8nRUT4?= =?iso-8859-1?Q?oDqZQuH3/k9xZ4ZQ1FAgMo2Z46aFYzncvuh4gWI17PvMHQ3VCM/kTR+HT3?= =?iso-8859-1?Q?SsvPFROSgA0VtiE/Pn3IEbA7TJgu8xP6k5Bls0xnqIe0ck+52d4XoRGKI6?= =?iso-8859-1?Q?K9XiZ/WsTvJPvfQq5QXzNefvVHe/SLmsTZSo+6SnIIMu7ZYInMPvrK2tqt?= =?iso-8859-1?Q?cThK1ww74SL/mupKpxoBto5RmV08SSRXHvabALKtOz24CFB2yFF/yQEHWc?= =?iso-8859-1?Q?V6IJCG45PlYt2JR8WRqM4r1qB3UXfMsiMATLokrUCQloy5+pVQ4sJT2Ogb?= =?iso-8859-1?Q?7fV1vOdc//5w2To5eBRS3HRcdei9e1MTyUgwODlhCJGLDa0x/i46cX08eJ?= =?iso-8859-1?Q?LGcEmRYXROGHMkpm6IO3cS+NHzgzrdGapLxWdKFbvrj3bygx6NYmawBnMc?= =?iso-8859-1?Q?Uk3E4tXnNCiXqUcJHp5qNXS0RiYuZN0oeJTtP5lkrT21dk+FWUB56AUXnQ?= =?iso-8859-1?Q?I4pGPyADmIIj+yFMxe4QOqeGiZtmCBJIwFu9mOjf1rLfCcI8UWAP+A1TXc?= =?iso-8859-1?Q?6WVQDNvi7YomctOxaNYd9X6wtnLVOBg4XRTXomroHubzKMmZMUwnRQlyKt?= =?iso-8859-1?Q?/FNA/Pkg4NEhY+S5lJFNxKY9DdChSUb9pfwEkFPgtJ0MaUL9bFVl8SAE0n?= =?iso-8859-1?Q?yvI3mBnDk45+1DtZrn6ZY525Xu+NLxmNQ1zMBnRNbRvdjJhKRFsSq/83nZ?= =?iso-8859-1?Q?llSfQ4vMCQ9GvSIcUYRqj6vy8EW3NlSAV6vGiMphahWQGFpwNhN5fLFC0l?= =?iso-8859-1?Q?E9Ei1zNfqeTIm1wh5WGlqZKDlKhAu8Vs0wlHjtUpwNhq2BoE3GLOetHkr2?= =?iso-8859-1?Q?JdixtKnGziDh6dBXadexrDDwjGZ1jpj8AylWNTI1MlPIxx8IyqVALph4EE?= =?iso-8859-1?Q?jlNcVAze0Jo/TZY/kDN7dKlVMNI+bfFwrwJirK9EH8bZ42pHLAxrE9YhPr?= =?iso-8859-1?Q?2zjePgUAmnoAaB3+yZVIFD3/3lFnNYqNEpjC4R0pruPGAMO0ksupd0h3j4?= =?iso-8859-1?Q?u526snj7LuyYFTVJ/v2e1OXGZFJZ3RY86CF2dW5hxgSrki4deFZcrayols?= =?iso-8859-1?Q?xiaFK3hBiMOGJAXkIfUPajRCWu7renFwEEfNmLiKphP+kDguNj8Ua/X+CP?= =?iso-8859-1?Q?B/Hn+JV0bL3GinMbQcuUNaeSqh1Adw9/1Hv+duFgg1Unu9J6GDrvglOcTW?= =?iso-8859-1?Q?nUUy8pl+AdgMS72SSa/RF/KzdR+QV+u1Kyq84o1vke/j8UvFp/hLcBYCCt?= =?iso-8859-1?Q?iezLyFiBus4Xys1Sd4eIKXyoKqh0b8KhZqYZWZd7z+D/IWIq6jA367Fx3V?= =?iso-8859-1?Q?+St9qB6WLQ5ERrwtEQKcc+JxHcrdKvORy/XSAkyY++2A4O2DhrhhXVipE0?= =?iso-8859-1?Q?cblhYyAnBRqBKqYtl2rcdcrDJWZFIq5wTbDffm8YSdTE6E8dfsQHSSeB8e?= =?iso-8859-1?Q?QnfyKYr5MGqwUo1PPf7c8MmrvH5J++nwXzhNjRuYmIkbAckLqVIhwV2KlI?= =?iso-8859-1?Q?7lQKAwMna5Ej/9jknDcdXSp7FaP++vUQE/HqPQsdyutKIDLdoC4MlEhiuY?= =?iso-8859-1?Q?8ITh91QMVifNuZ0uTa7l6IhU6TF1k4Q=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1f85738-2559-439d-7149-08df28a240ab X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2026 20:49:04.4177 (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: cEDLXfLNn2MtQM6ZjzLauZG4UUoc0yt/e3j6dzTi6zRdzMGHxfBstVxOAVZZpeyidb5Ivi6qWE8rIU9sCpRspq/E1LyB08AO69XcHC/OGOc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6408 X-purgate-ID: tlsNG-4011c0/1791838147-50ECACFC-D7143245/0/0 X-purgate-type: clean X-purgate-size: 4009 The hide pattern .xen-syms.[013] leaves pass 2 visible. On x86 LAST_LINKING_PASS is 2, so that is the final link. On Arm LAST_LINKING_PASS is 3 and the final image is .xen-syms.3. Pass 2 is usually only a symlink, so Eclair saw no program link and reported every translation unit as unreachable. During analysis preparation, read LAST_LINKING_PASS from the architecture makefile and the pass numbers from the foreach list in xen/scripts/Makefile.link. Hide every pass except that one. An earlier pass that is a real link stays hidden. The generator runs from generate_ecl.sh, together with the other ECLAIR configuration scripts. Fixes: a401b5c9dc35 ("Eclair: re-enable scanning of the (almost) final link= ing step") Signed-off-by: Dmytro Prokopchuk --- Test CI pipeline: https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pi= pelines/2940065908 Changes in v3: - generate the hide pattern from generate_ecl.sh, which prepare.sh already = runs Link to v2: https://patchew.org/Xen/e73c282694e68083305d03219f983bf74a8bf494.1791392326= .git.dmytro._5Fprokopchuk1@epam.com/ Changes in v2: - update commit message - generate hide pattern before analysis - read LAST_LINKING_PASS from the arch Makefile and pass numbers from the M= akefile.link --- .../eclair_analysis/ECLAIR/analysis.ecl | 2 +- .../ECLAIR/generate-xen-syms-passes.sh | 20 +++++++++++++++++++ .../eclair_analysis/ECLAIR/generate_ecl.sh | 3 +++ 3 files changed, 24 insertions(+), 1 deletion(-) create mode 100755 automation/eclair_analysis/ECLAIR/generate-xen-syms-pas= ses.sh diff --git a/automation/eclair_analysis/ECLAIR/analysis.ecl b/automation/ec= lair_analysis/ECLAIR/analysis.ecl index c6e1a7a95d..df1006bcaa 100644 --- a/automation/eclair_analysis/ECLAIR/analysis.ecl +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl @@ -37,7 +37,7 @@ their Standard Library equivalents." -doc_begin=3D"Do not analyze intermediate linking artifacts, as they do no= t differ from their final counterparts for the purposes of MISRA C static analysis." -file_tag+=3D{xen_efi_tmp, "^xen/\\.xen\\.efi\\.([01]|alt\\..*)$"} --file_tag+=3D{xen_syms_tmp, "^xen/\\.xen-syms\\.[013]$"} +-eval_file=3Dxen_syms_passes.ecl -frames+=3D{hide, "kind(program)&&target(xen_syms_tmp||xen_efi_tmp)"} -doc_end =20 diff --git a/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh = b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh new file mode 100755 index 0000000000..e3795e8234 --- /dev/null +++ b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh @@ -0,0 +1,20 @@ +#!/bin/bash + +# Hide every xen-syms linking pass except LAST_LINKING_PASS. +# The pass list is the foreach in xen/scripts/Makefile.link. + +set -e + +cd "$(dirname "$0")" +arch=3D$(echo "${XEN_TARGET_ARCH}" | sed -e 's/x86.*/x86/' -e 's/arm.*/arm= /') +last=3D$(sed -n 's/^LAST_LINKING_PASS *:=3D *\([0-9]\).*/\1/p' \ + "../../../xen/arch/${arch}/Makefile" | head -n 1) +passes=3D$(sed -n 's/.*foreach n,\([0-9 ]*\).*/\1/p' \ + ../../../xen/scripts/Makefile.link | head -n 1) +test -n "${last}" +test -n "${passes}" +hidden=3D$(printf '%s' "${passes}" | tr -d " ${last}") + +printf '%s\n' \ + "-file_tag+=3D{xen_syms_tmp, \"^xen/\\\\.xen-syms\\\\.[${hidden}]\$\"}= " \ + >xen_syms_passes.ecl diff --git a/automation/eclair_analysis/ECLAIR/generate_ecl.sh b/automation= /eclair_analysis/ECLAIR/generate_ecl.sh index b955783904..b97fc55fd2 100755 --- a/automation/eclair_analysis/ECLAIR/generate_ecl.sh +++ b/automation/eclair_analysis/ECLAIR/generate_ecl.sh @@ -20,3 +20,6 @@ accepted_rst=3D"${ECLAIR_PROJECT_ROOT}/docs/misra/rules.r= st" =20 # Generate the list of linker-defined symbols (must be run after a Xen bui= ld) "${script_dir}/generate-linker-symbols.sh" + +# Hide every xen-syms linking pass except LAST_LINKING_PASS. +"${script_dir}/generate-xen-syms-passes.sh" --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 13 02:31:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 02:31:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446642.1662729 (Exim 4.92) (envelope-from ) id 1xGSIN-0003ha-DE; Tue, 13 Oct 2026 02:31:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446642.1662729; Tue, 13 Oct 2026 02:31: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 1xGSIN-0003hR-89; Tue, 13 Oct 2026 02:31:15 +0000 Received: by outflank-mailman (input) for mailman id 1446642; Tue, 13 Oct 2026 02:31:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGSIM-0003hL-It for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 02:31:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGSIL-00BXmE-7S for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 04:31:13 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd97b3-2eae-0a2a0a5409dd-0a2a4502b4ec-48 for ; Tue, 13 Oct 2026 04:31:13 +0200 Received: from [52.101.66.81] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd97f0-6ca4-0a2a45020019-34654251faf0-3 for ; Tue, 13 Oct 2026 04:31:13 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DBBPR03MB7131.eurprd03.prod.outlook.com (2603:10a6:10:1f4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 02:31:10 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0496.020; Tue, 13 Oct 2026 02:31: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=liuIdE0ovptn0Df0L5tXmFi11tm5mbbxLm2FoMDUE8Zx6KafqrDhO6QwKvFcTDEkifzpMJBY1WwyLJOepBIuV6Smu1+bRtxmtrbE4tkDra3mqNxJZ06Jw9E2Xk/ubjFof4eYN7oq7Jj8PYgIpxzPL/FrAydGs94MSojArvhYnf0s+ZHUoAtvxZoXRJyQYwaVJnFPKw0EIbm166gRxI092NNc+BS2se16uCbfydC4zD6eQKc9INIRBg9nBmrQnUFSHDtAsw91sReXItBKh4J/MAeljyanZdzruF81OZSy9zG/QvRg39+1eKzKZck1b76WZHrms9gEY7iEctM5p+JKFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ot9hhRh9OnXRZP4Ej2WBfGAjnd50GSuNZ4BtxnTZubQ=; b=rD1RKKTEd/AEEZ3xuSIFrGE2N+9OHpwLEVf1eHgZsRai70sJ2wQ5vGG3mqZdmFDLKeesZDl2Pe2BH0Gz2zs6mvw6FWLsX3JAsC75KGlFIQXgOCac3nlKVl4nWY12rXonfvadwHyyIqamKS9Y9IYE15Vb4CX2G4eGXTO7/ynFAwkPALO813dJm6588eOtdSVQJpiMG4Y/U2XHruk8w5ZHAXt4HxFh/11g7Kg+75nzLRZ5d+4828ca8TpongX5SCwovkpl9l7U/R60v2ujaZGUStlCDwmzsFegbzbPHAAAoNruxj/4mC83CpfatNpAnaIdcEWinyx1gHN9x+BInRZYFA== 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=ot9hhRh9OnXRZP4Ej2WBfGAjnd50GSuNZ4BtxnTZubQ=; b=PRmRUoPdQz5qV+0cRmm79r2xzZbb86tSAAwBJHXco1QDOj8nG0CxHVkgolGKrVB5AWVljK61akdvD6gTjRi6LwEN0xlzcTopM8SB/XNN8SdOAlREpCgx7dvrpmQLSEFprmDKhgQSC63c5kfp9GoNZ2XrvL+gAv3mwQzSlnA0qmtcTFp1wf71ituRm7LmcLczRwQZRFrd82iV8IasQ5SpH4gNQTGWcsxb6QAFpmvUX27SZBZXRp77uMkreyVnkaGskwkj3oDtCzcIeD0tDYn4oAhN/ylSDz61lC7lk7T+RNKP9aMHvUk5Nk1KTKsZpjfK3qjV92VihxwqfRxHgqyk3A== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Jens Wiklander Subject: Re: [PATCH v6 1/4] xen/arm: handle irq_set_type() failures Thread-Topic: [PATCH v6 1/4] xen/arm: handle irq_set_type() failures Thread-Index: AQHdUDM172HH4zh0KU2n7bf3fDWjHw== Date: Tue, 13 Oct 2026 02:31:10 +0000 Message-ID: <87se2awcuq.fsf@epam.com> References: <1cc5a52b61d3ed8176b2a12f23f284a44a8a72d8.1790699282.git.mykola_kvach@epam.com> In-Reply-To: <1cc5a52b61d3ed8176b2a12f23f284a44a8a72d8.1790699282.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Tue, 29 Sep 2026 19:54:09 +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_|DBBPR03MB7131:EE_ x-ms-office365-filtering-correlation-id: 2d98a68c-816f-4dbc-245c-08df28d20afe x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|23010399003|7416014|376014|1800799024|366016|6133799003|18002099003|22082099003|10067099003|38070700021|11063799006|4143699003|261009223027099003|56012099006; x-microsoft-antispam-message-info: tTOcxkOZYZ91UWcBN6KF6DDWRFOE/DI4f3FUllQNgDfVCvl4gAuwFuXizVBd2Cbw4SWk49+S4sg/pKdNxsSNnV17pi73smW143fvS/HHX9FkrPUSUNffU400x5tZkLdVwY/L37C/a5iYry8BiSAS4fgg1DJFZVQCMwvmzarQoyTZpJHzKRYruV7VHV1iVXhs4GTyGwZAhQ6uSZpWBRQQipUmSMAzJOiQSCDUjwi+dQEgIghaAMJnVNqVOIjXqZ3t5OG0OlJzEGWbT0uiWG0krbdBgr4g3+yilK0Qi2tsuukgip6yE0x0qBRhS41PruUiKSCdg0a+UED8g3JesuP32AXfNmibzvBR2fpb0Ipa2w1bXCeutWuLGhz5q6tlC8Z5t4nKaMVKcy5MFlHFn7Eu0rbV3YD+HuB8FbcL1aK2uHUVEdBUas+6Bfb2o93lA/yJx74fMd9F+Kgrs7QDGi/oqlbdSlaFBAtPn20jhj/zS/LQaMF9Kt4m/WOotN7LNnzf8uzJrJ1SzRqefNxpiUUR9ldWJdyNx/SqUVNmS3N8ed8u62avkAnRTN/uc5gzDe0CA4Du+U1bKdhSqP3z97YcLzgBaV5gsxORlnAx0ST5jJvmPdfbmPyWuhXLXG+lQPgYc+MSR90lrJioYt0O/il8WwK9e88JP7vlYsruNCf/cH8DubWJ+8Ymo5noQyPnJ8r2rGnleoOsHbizEni9aRn+aGu3cdCxppvpHhGfngo611I= 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)(7416014)(376014)(1800799024)(366016)(6133799003)(18002099003)(22082099003)(10067099003)(38070700021)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?YEo/eubAjZQIJMt4tfoFwKkwyAmwzl7XmEXRIIBOYQ75BZOP937yIxMc4Z?= =?iso-8859-1?Q?ahtpNHBmBdUmWl9/Q0J2YbNIi9c9UxkcELeR8483gQpsmB0q80ZZXObchk?= =?iso-8859-1?Q?EdLmgd+NCXP3yr45fYwI9ptXEYebn/zx0B8YrSk3MVycb1l9HD0jZpA1fE?= =?iso-8859-1?Q?tUHpbMciOAE6UM/QAsJIzKZhPhrfUGTxU6zkttZI1gZ69U/735CzxWaDcp?= =?iso-8859-1?Q?jDzpeQR6jxvfOHgCQrPOqQz+Iq+9WcdhlYNIcOcJ9nproSDTguA/bqqYtr?= =?iso-8859-1?Q?yRp8yngpJJeSGZmaqOXNjfBS8NeNF5p10tJybfYZRuG+8dGHnFiRZfgJWP?= =?iso-8859-1?Q?cKP/DOAI37sxLPQeAO0xCkV7Ld0Tv2/8JB9jJnoMfrL1EjeXPO7jLQZ2rg?= =?iso-8859-1?Q?x9D/T8wJQEn60B8QJHmHU8oh8IP9bdX8ptVJzrs2Bdj1pJW73vvgArkUd1?= =?iso-8859-1?Q?5VVq7JfMJ8NG5LtQkew/8zK5bOzWTdRAVJ2chvRGfF8z77wcwGnW9s4U5M?= =?iso-8859-1?Q?n97uB6ZrwWhjPOQjjZg9n0CHEtay855Mstq2UkJB3/5AGwdQOuugdO7w/0?= =?iso-8859-1?Q?0Ksk/8NRelGRzuCNA7x0KLnHv8XVOupOPy+XT8XZKagmFRTUbLT7ETBTWP?= =?iso-8859-1?Q?FqIYFxdwWGeBcpIQ/bNavNJElFESOmVOIlndPBHNhSIoYT6N2yMNj0pUWJ?= =?iso-8859-1?Q?xnNcv9pkp333b9gP+bLA6DC4LDcq0VDiORPP3pEe5A396/y2OSLz5bMl5G?= =?iso-8859-1?Q?CfXbctS98mSibwYLr/5RtpPkQBVcWDHcVWtSE+Y5DM9v5RJEYG4jZxc7u7?= =?iso-8859-1?Q?l6FoJtGPku7Po6ifk9byxSBwWaBC/7xKaFacMjvLvfsmAoBSBI5iObV+rr?= =?iso-8859-1?Q?rEvEOzez5bzuV1NfctWCYuQ6e1Z9FStVAawbJPxXik2un1CnD13KIcv53I?= =?iso-8859-1?Q?XqE8h6xm3pBzKD0zG49A+ymOFdHLa7lTM+S4iloBqQGvwBoI5hwaCoVNJK?= =?iso-8859-1?Q?8Tuh2xKTE4a6Jau2AkxBO3pjBEFNowqagnOPzO4fuAkQAnGlEnsE92ZmNr?= =?iso-8859-1?Q?bOgTtZOS5139GS2/RanlPkWS/Izo0KzTwF/eCVUkF1ZX0FqiFQV26JZ04T?= =?iso-8859-1?Q?LnLBz5pt9+Lzy9KNAhUSshlwsjZ1Ss9m1RX4YULoeBSgXPyYAbO7kL3sxF?= =?iso-8859-1?Q?2P1L9AFcDJW8RSmqpqIAnE03ARO2OjqD5CZ6jK0JkUwn0//Z8RClDCPvB8?= =?iso-8859-1?Q?CW+tvC01gDqbjSGmN/SYdbSjrR3sOfWyXZPfj+K+ek+xCOK+1URDBaaBTn?= =?iso-8859-1?Q?fSOBtzeydRTMlMfILNhGya3eG06imFdmy96JEGNeOf22bZmpwOnIE7D6sF?= =?iso-8859-1?Q?ENnuFEgMENX4vkOV0v99Pd9WFf+QHr+CILRs+937QRkF6+5cnB67ItGDnL?= =?iso-8859-1?Q?M0mWYzkmcPqDbs15AQoBi16AhhRe7kuUK/lXzIVYNByHfnXlLBVfll4LKT?= =?iso-8859-1?Q?zhEb0xxSlR1YmYYKU7oZnx1pyJRLV/kY+UV0be37zbbujWJ+Io+ELUHjGr?= =?iso-8859-1?Q?/sbPZW1uPPkO+2QhG0P7eTfYNVe6eZJVNn0hXhTbQ3VXnLuPOnQwio7XPV?= =?iso-8859-1?Q?MbB1twddf+lJTbTMPmF5nxkHH1wkevLC8K9nMbU+lRvcsgnHvhcjAyd2hk?= =?iso-8859-1?Q?059NhQQxCTIEMQ1o7vmd3wdSXUZAn5F4ZljNsoCJRvsqfSYyRmiOAZbQxn?= =?iso-8859-1?Q?nIiFfO4yXQtZFPOKA80Q1ggV2QAy6j6Jtlakc/rdtsYiu0ytzUq3GSr+UY?= =?iso-8859-1?Q?xhdhLSEWKvDAEyoouuUQSfJ3JEm1EWY=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: 2d98a68c-816f-4dbc-245c-08df28d20afe X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 02:31:10.2114 (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: BHsnS9sZiAJoAqedbd3fQkXaGdQTn+5cpGpOC/n5Udkh4IRGIBVIDN/sbF0HkjirXk5cOCnpb/XghPxWHgGCqriOKF4SS9PbFqVXRsZ+cw8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB7131 X-purgate-ID: tlsNG-720697/1791858673-672B12AC-91AB7E82/0/0 X-purgate-type: clean X-purgate-size: 9252 Hi Mykola, Mykola Kvach writes: > 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 tim= er > INTIDs only after successful trigger configuration, make GTDT parsing > failure fatal, and stop notification setup when trigger configuration > fails. Keep the NS16550 and PL011 consoles available by falling back to > polling, with a warning, if their IRQ trigger configuration fails. > > Signed-off-by: Mykola Kvach > Reviewed-by: Michal Orzel Not sure that this is a good idea to leave R-b tags if you are doing functional changes to the patches. You can have my R-b though: Reviewed-by: Volodymyr Babchuk > --- > Changes in v6: > - Fall back to polling with a warning when ACPI IRQ configuration fails > for NS16550 or PL011, preserving the console. > > 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 | 10 +++++++++- > xen/arch/arm/time.c | 18 ++++++++++++++---- > xen/drivers/char/ns16550.c | 8 +++++++- > xen/drivers/char/pl011.c | 12 ++++++++++-- > 6 files changed, 58 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_head= er *header, > /* Read from APIC table and fill up the GIC variables */ > if ( cpu_base_assigned =3D=3D 0 ) > { > + int rc; > + > + rc =3D 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 =3D processor->base_address; > csize =3D SZ_8K; > hbase =3D processor->gich_base_address; > vbase =3D processor->gicv_base_address; > gicv2_info.maintenance_irq =3D 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 =3D 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_head= er *header, > /* Read from APIC table and fill up the GIC variables */ > if ( !cpu_base_assigned ) > { > + int rc; > + > + rc =3D 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 =3D processor->base_address; > vbase =3D processor->gicv_base_address; > gicv3_info.maintenance_irq =3D 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 =3D 1; > } > else > diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c > index 186e726412..c64bc39f03 100644 > --- a/xen/arch/arm/tee/ffa_notif.c > +++ b/xen/arch/arm/tee/ffa_notif.c > @@ -407,7 +407,15 @@ void ffa_notif_init(void) > irq =3D resp.a2; > notif_sri_irq =3D irq; > if ( irq >=3D NR_GIC_SGI ) > - irq_set_type(irq, IRQ_TYPE_EDGE_RISING); > + { > + ret =3D irq_set_type(irq, IRQ_TYPE_EDGE_RISING); > + if ( ret ) > + { > + printk(XENLOG_ERR "ffa: irq_set_type irq %u failed: erro= r %d\n", > + irq, ret); > + return; > + } > + } > ret =3D request_irq(irq, 0, notif_irq_handler, "FF-A notif", NUL= L); > 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_ta= ble_header *header) > { > u32 irq_type; > struct acpi_table_gtdt *gtdt; > + int rc; > =20 > gtdt =3D container_of(header, struct acpi_table_gtdt, header); > =20 > /* Initialize all the generic timer IRQ variable from GTDT table */ > irq_type =3D acpi_get_timer_irq_type(gtdt->non_secure_el1_flags); > - irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); > + rc =3D irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); > + if ( rc ) > + return rc; > timer_irq[TIMER_PHYS_NONSECURE_PPI] =3D gtdt->non_secure_el1_interru= pt; > =20 > irq_type =3D acpi_get_timer_irq_type(gtdt->virtual_timer_flags); > - irq_set_type(gtdt->virtual_timer_interrupt, irq_type); > + rc =3D irq_set_type(gtdt->virtual_timer_interrupt, irq_type); > + if ( rc ) > + return rc; > timer_irq[TIMER_VIRT_PPI] =3D gtdt->virtual_timer_interrupt; > =20 > irq_type =3D acpi_get_timer_irq_type(gtdt->non_secure_el2_flags); > - irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); > + rc =3D irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); > + if ( rc ) > + return rc; > timer_irq[TIMER_HYP_PPI] =3D gtdt->non_secure_el2_interrupt; > =20 > return 0; > @@ -81,7 +88,10 @@ static int __init arch_timer_acpi_init(struct acpi_tab= le_header *header) > =20 > static void __init preinit_acpi_xen_time(void) > { > - acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); > + int rc =3D acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); > + > + if ( rc ) > + panic("Timer: Failed to configure interrupts from GTDT: %d\n", r= c); > } > #else > static void __init preinit_acpi_xen_time(void) { } > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index 593d208483..cdda28879e 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -1990,8 +1990,14 @@ static int __init ns16550_acpi_uart_init(const voi= d *data) > uart->reg_width =3D spcr->serial_port.access_width; > =20 > /* The trigger/polarity information is not available in spcr. */ > - irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); > uart->irq =3D spcr->interrupt; > + if ( irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH) ) > + { > + printk(XENLOG_WARNING > + "ns16550: unable to configure IRQ %u, using polling\n", > + spcr->interrupt); > + uart->irq =3D 0; > + } > =20 > uart->vuart.base_addr =3D uart->io_base; > uart->vuart.size =3D uart->io_size; > diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c > index a336241033..612d457fe0 100644 > --- a/xen/drivers/char/pl011.c > +++ b/xen/drivers/char/pl011.c > @@ -347,6 +347,7 @@ static int __init pl011_acpi_uart_init(const void *da= ta) > { > acpi_status status; > struct acpi_table_spcr *spcr =3D NULL; > + unsigned int irq; > int res; > bool sbsa; > =20 > @@ -363,10 +364,17 @@ static int __init pl011_acpi_uart_init(const void *= data) > spcr->interface_type =3D=3D ACPI_DBG2_SBSA_32); > =20 > /* trigger/polarity information is not available in spcr */ > - irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); > + irq =3D spcr->interrupt; > + if ( irq_set_type(irq, IRQ_TYPE_LEVEL_HIGH) ) > + { > + printk(XENLOG_WARNING > + "pl011: unable to configure IRQ %u, using polling\n", > + irq); > + irq =3D 0; > + } > =20 > /* TODO - mmio32 proper handling (for now set to true) */ > - res =3D pl011_uart_init(spcr->interrupt, spcr->serial_port.address, > + res =3D pl011_uart_init(irq, spcr->serial_port.address, > PAGE_SIZE, sbsa, true); > if ( res < 0 ) > { --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Oct 13 02:36:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 02:36:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446647.1662738 (Exim 4.92) (envelope-from ) id 1xGSNO-0004Id-Sn; Tue, 13 Oct 2026 02:36:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446647.1662738; Tue, 13 Oct 2026 02: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 1xGSNO-0004IW-Q9; Tue, 13 Oct 2026 02:36:26 +0000 Received: by outflank-mailman (input) for mailman id 1446647; Tue, 13 Oct 2026 02:36:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGSNN-0004IQ-TJ for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 02:36:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGSNM-000IbZ-NR for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 04:36:24 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd9907-2eae-0a2a0a5409dd-0a2a4501829e-26 for ; Tue, 13 Oct 2026 04:36:24 +0200 Received: from [52.101.69.127] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd9928-5984-0a2a45010019-3465457f80ef-3 for ; Tue, 13 Oct 2026 04:36:24 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DBBPR03MB7131.eurprd03.prod.outlook.com (2603:10a6:10:1f4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 02:36: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%4]) with mapi id 15.21.0496.020; Tue, 13 Oct 2026 02:36: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=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=omz/JBFtzmN3q6/kwgewMiiGI2qmlGAKpa6h0IfC43SwTm8mGsGBesQiXLSxIM7c0y4TwVoANV+9nRG5O5LUUBhkr5h3WFtchMen2HKEyM0wkYpJ5CWItQ7CCNOCopWQGB8788iZj1DeSDVHKOqkJm/kTJR8m0oINR9dNhl64RGqxyIf47SNEtk/ZFfEAxZZZYflMYpESH9H8h1vX4U8NRW5OLzCQPx00MfmFcT51A6l/6CnC7AyZylSBQIt6E7slHUQJgpN7k5p9UIqhJDK2YwZF87oe9SXqKyWFqO9Zpo8ILZWPLOeIvsmA92t8CA9xTodhjPEPNKRKC5xWqaS8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JPUAuZ0kYTtEPwG/2/FzO313L0dzqENwj5fDeJV7Wj4=; b=JvwbUi2LX1M2MFGKOmOkKPL5lNAr0LfmFNpNSmh15gSfGbBUgZKj7iYIYjZWEDGdxdHTp9CHYg1ds40I87acQf9jo8rMbhWibcHgmje/Tq8YDvRhgPnc+kIMlQkYbQ7dkqaiymJBKXk1SQl6Xz0VhlcOg72xCn17/IkySoXk6Fz8xtcBGIs14Vk4VBlkI5/Bn8M6q2JRuc7eGic9EsUMyuV9JC5RwYL8/QabQduoEIT9PcB2j8VfECcu7oX1EUYm+ztfUdPuGBoi+cCbxb13kYvz7rIA0L1QKcnviraN9mOxGIxyqFM0YnIXRPujIGksZWWoPU8VzORWUn2MSUQSHw== 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=JPUAuZ0kYTtEPwG/2/FzO313L0dzqENwj5fDeJV7Wj4=; b=d9fSGrDe6+scQCeB+gaoCFUSXvwS/dYUToa9WXNtsPm0RUWykOJPfViOGLOK65QqcCPMG/181HpgMunlUftsibPSVozIWg4p3vesPeCAyTqhBFzhxaEfAH/AzuNj2dd9+myOmMzYseFfvS6syDcaKDBEG/vq8pyQzdD1eoIXS2WhG5IZ0bLR/Poow/jQ+BiXRdjhJNx1XFa9cOjJPYflcNE0pOBp3wd9YsU6ngAr9kf2PAYHS83YCbwlqiQ6lmendAgIuBvvic4tj9NfcOl0lnpTeTQKLiKLOERBg7x3Sqo/0H16x0U1Ki+NyTfmAaChoUwRVTMdD3QsgTIDPNlx4A== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v4 1/4] xen/arm: its: initialize host LPI state before activating ITSes Thread-Topic: [PATCH v4 1/4] xen/arm: its: initialize host LPI state before activating ITSes Thread-Index: AQHdUEUSTD/ibdik3UGXPUfUToT1lQ== Date: Tue, 13 Oct 2026 02:36:22 +0000 Message-ID: <87jynmwcm2.fsf@epam.com> References: <0afac276107d8b2a170489950d75e611c69a599b.1790707009.git.mykola_kvach@epam.com> In-Reply-To: <0afac276107d8b2a170489950d75e611c69a599b.1790707009.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Tue, 29 Sep 2026 22:02:10 +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_|DBBPR03MB7131:EE_ x-ms-office365-filtering-correlation-id: 8df07605-0243-4fd4-3cba-08df28d2c52d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|23010399003|376014|1800799024|366016|6133799003|18002099003|22082099003|260925021311599003|260925022911599003|260925021911599003|10067099003|3023799007|38070700021|11063799006|4143699003|261009223027099003|56012099006; x-microsoft-antispam-message-info: P7U03EB38TNOTboi5mEA1qx1wLMnFxoXsolsRC+EvG80ZrWBqNf8QVEfdPhG2D33TPGofXr6+kzckFwj4dLCDorSDdawZrzR0qSgiZ5iHsE4KoiMQpsLmjV63DEd+yqiJ4GtgGy9ijlZTrN7uQnshdi6YI16eTLKaaDCmhZXTnkWh7QCS0RP6DhEcBpMEVKnVu/dAruF0+iE8YD373MWAn/A68JYVekr4+9R78/M5LZv7J9hzOJV8TGypr3F/N3/c+T3BDWb3sh2x3ldz9BdBQmhpuGuAeFw69Pv5qCW4ZqwD/l7k9HvaPArUCrDp8BV55i6SJjnhGDllzkDVWLMeJMeqaMw/f2pi9RYiU18V2sYOlpsOtmJbcsfIA/ZHTfc6ZgPvmQRJR9/3xolnrAg7ewd4+3PH6pIsw+6xuETEXWoiaY6VwxBKd9ZjoAv/KyMQ/2BMaE6g+dHel5rbhXPrgwtSURkvvXz2EBnI59OYeEetGusVSMOQct8QeubObr6QqSEIQ0hKQ/1xNkHHumn1kksvh89eCv3KIKjwRpt03yq9myE6d1zbnbw1/0MgPclL4ZhR/QgPN2SJaS4RMYUUIbXN0sygscvkJwX5oBSUCKFPsHLo1b180dIOvK+zJ4zNK5oRE+1OrwuomA+evStkxCYYbQsKgfb+5ElKlkxgZQ= 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)(1800799024)(366016)(6133799003)(18002099003)(22082099003)(260925021311599003)(260925022911599003)(260925021911599003)(10067099003)(3023799007)(38070700021)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?0mYyeq9Q250oNr8b8cH6HPjbRHFORWCRgwLfuBR5kOzUmrVQ3Kl2sBQPV6?= =?iso-8859-1?Q?7a9DURUyemcGLEUB7+XWYUX/ju3Ga99BxKaHH84kUK6DKWB9G3t8Qb/8uX?= =?iso-8859-1?Q?1Zh69sLDxDSOJESkFW8PKtKvVV2LD1lV5JzVq5znnXbXGn39SRX3Gb65W1?= =?iso-8859-1?Q?h1KeKrpxiKzgPx4qycSX19M4+4mJHCH1MzU1k8LhqDJkTOFmA2fN7sOf5D?= =?iso-8859-1?Q?Z154WtHTs/3SNSyiOsNx0x5i+QW+nKzNo+6FIHEhiq+RSVHt22zY1RS2KR?= =?iso-8859-1?Q?yQ0gEWbccca7jzfslJj5AGkVkWqBb+i2zPAOebv8A1HUFEr1r9NgOPgwwT?= =?iso-8859-1?Q?t/NtOv2Glva4K5V3grwC0ROC7FeKdThL0MuM14YjxRfsAeLCuWgTegwfEj?= =?iso-8859-1?Q?C/gUOCYPDEFQhfRaHYxCqQFTOU6ab0hKKdxhEIzdksiIAhWGCK41C6j4tP?= =?iso-8859-1?Q?ZpCW6tZygdIm2oBj87DOECoS5gsL4akWrZ59QgiuyOugMiv3TC8ltx3s2O?= =?iso-8859-1?Q?xB9I1y+ikNybn9jrn88H7rmmOEu6lg6dNW7kNsZty5yESotECGChioTgYY?= =?iso-8859-1?Q?4y4KEFuuz2rJBar/OHWHwAUh+RnTpHBTn8qPD/Za44hS5kueySeyD885Cb?= =?iso-8859-1?Q?uhFcrYC5eH81GNlbGP5gLGJl4vGM4OWSy/WeHEQJHeyWXfp9SzuwSvedJ5?= =?iso-8859-1?Q?8WQ7EgEZhDBQ57JG3QhBqmBbrumuTYE/7S3+WwTi4bSB6Cz5acm4h54fuT?= =?iso-8859-1?Q?ihjIo2BRsxtJttGxZ0QgDaaG3ii1U9JDFpw54owSHd/YsSvzcdqw9CPQ/H?= =?iso-8859-1?Q?TLNYgdQA/5P1Wl8umiffmECCM3hTpIoHWTZ6B10TyXrHmT35FP28aHxT5D?= =?iso-8859-1?Q?VBukskSyPQ6UOQboJSdPkfA0jIPcc1MzaoSOJKZRPBHv8ZCBpN6hhaUn2K?= =?iso-8859-1?Q?k0xi3uvLckhV6oKXU5jo1hdqlLo2fTYvfjIFKzbnMpByJPb6LbqmH6ksy8?= =?iso-8859-1?Q?x4RHZ8HQ1paBYH+142w5L8qVLUNexnxn58d+CTa4mGEoQVz47RW3WKvV7p?= =?iso-8859-1?Q?P0ozgpkVvL6kEVK1Wh4znoy6e1N3rEUeDvmxnLsKOnbLLHC1HFyDozs1Pq?= =?iso-8859-1?Q?cqPeWSZ0fTOBIQvAU19vV3SMDipSaDN7IO/t2ZaS/CArXImu8BEZnpDLQH?= =?iso-8859-1?Q?x7BXstPSU1wScARe21k9WWddorkJ369vPJ8kny22fb2mOATLAYCkx7BV9t?= =?iso-8859-1?Q?Tdq1y1m8i5xPu+q4dMVeICu7UVUVGhHZhTxQWPpjRxU+4UDLCo75tH5l/L?= =?iso-8859-1?Q?cYLwmxs7Ujnelr0OB5EPLL+QxzXIhBJK/wyjEQL6QvI3HQMG7jHg98eSSH?= =?iso-8859-1?Q?SFVeqT8vnL38oLzZzmFUFLk/FtdnyRHjj/FRkKhZDtGXR9aGO9NbLJqotK?= =?iso-8859-1?Q?6tfEBpjuujcZvZtEHn5dG35yQEZlu7qL9mbb6tKb2g4O2n5ChTc8Qf/KuF?= =?iso-8859-1?Q?sUhXsDrwMbegqyGvV48umDO2k1pZds/zO2v6BBLo/h2FkVTI79CzorvOL/?= =?iso-8859-1?Q?+LhXV6+2f1DO5kt7UJeW24d7xZX2BScz6D+itYUMA+14/qJE2bUUOshuDZ?= =?iso-8859-1?Q?1Xx2+2HQ871zekTe4u8nBfmliwr6ZguhRflm3KFgL6Net8NEzymqiy3c7f?= =?iso-8859-1?Q?Q1okihLIq88pO4Gtjx+pB+f2hiqyid5mpNzr6XlLCzGJ8IpILNQnNk7BIw?= =?iso-8859-1?Q?+2GAflXUoBdH3iMP7nejMyqupmFesUaytquzhTl9djnrZ16o7Ks2H1Pw22?= =?iso-8859-1?Q?5AEbFjZ3p3J9M/SqBefjiqC6VCSeczk=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: 8df07605-0243-4fd4-3cba-08df28d2c52d X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 02:36:22.5800 (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: yj8pPNqwZTYZukBK8IAuKDnfuyQl0n5bkaIZrn6FDf3UBlp1igYe4AgYKuYafN9TrXEy0gXdOaBYQ0GIXlQyI9iWaVu1B35OkZXH1YULY6E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB7131 X-purgate-ID: tlsNG-d62444/1791858984-1F66C757-83BAEC3F/0/0 X-purgate-type: clean X-purgate-size: 5996 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 Reviewed-by: Volodymyr Babchuk > --- > Changes in v4: > - Move the empty ITS list check before the preparation loop. > > 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..511e49a116 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; > @@ -1199,15 +1207,29 @@ int gicv3_its_init(void) > else > gicv3_its_acpi_init(); > =20 > + if ( list_empty(&host_its_list) ) > + return 0; > + > 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 > + 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 > 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) > =20 > if ( gic_dist_supports_lpis() ) > { > - res =3D gicv3_its_init(); > + res =3D gicv3_its_init(intid_bits); > if ( res ) > - panic("GICv3: ITS: initialization failed: %d\n", res); > - > - /* > - * Host LPI allocation uses ITS-derived memory attributes, so de= fer it > - * until after gicv3_its_init() has discovered ITS workarounds. > - */ > - if ( gicv3_its_host_has_its() ) > - { > - res =3D 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); > } > =20 > res =3D 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); > =20 > /* 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); > =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); > @@ -245,7 +245,7 @@ static inline int gicv3_lpi_init_host_lpis(unsigned i= nt host_lpi_bits) > return 0; > } > =20 > -static inline int gicv3_its_init(void) > +static inline int gicv3_its_init(unsigned int host_lpi_bits) > { > return 0; > } --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Oct 13 02:52:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 02:52:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446656.1662747 (Exim 4.92) (envelope-from ) id 1xGScq-0007GS-Aw; Tue, 13 Oct 2026 02:52:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446656.1662747; Tue, 13 Oct 2026 02:52: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 1xGScq-0007GL-8N; Tue, 13 Oct 2026 02:52:24 +0000 Received: by outflank-mailman (input) for mailman id 1446656; Tue, 13 Oct 2026 02:52:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGSco-0007GF-KB for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 02:52:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGScm-00BZr1-Gp for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 04:52:20 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd9c79-bab6-0a2a0a5309dd-0a2a4503a1e8-26 for ; Tue, 13 Oct 2026 04:52:20 +0200 Received: from [40.107.162.94] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd9cde-fae8-0a2a45030019-286ba25e2992-3 for ; Tue, 13 Oct 2026 04:52:15 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by GV2PR03MB11669.eurprd03.prod.outlook.com (2603:10a6:150:344::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 02:52:10 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0496.020; Tue, 13 Oct 2026 02: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=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=xRSR/dwMy6l/C82XgFabrzxPLxcHDpDYad7BuY8ej9LES9XloFQ3nxR5btd66w9oV2buhoGWwVKuTFq86qemoC/rF1k0JW8fyBaASAo1LXfk9eRc5D8FVmLbGC+Dv6b+DEQrgWzijMV1w7RH19ZOHhDu7cJ6lgscQQI6fzt9YNTh8Duw7Dujb7D3T4PmS33a6ztp/sDb/aQ5WQ19cUV5Fln0VgMQwkiSkSjbHEJU3jVfM4nbRmyRox1PfboBaKXWH98hSgq7OW8sIIMf+mTvE0riTudSBKYgGY3WczPNQbFeTn6iKG1UzLq6Xi+tHHdRPOIsfkMuI/qYwzoDsJTUDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fPrlI+dwHbsY7j0KZuLyjs8scp0KgJZRDLEnutWvKk8=; b=aQ/ZWgVDUQasR68XdwP5kkueA2OQw++p17iG6sbnRHyMrTiNIRkae2/aUW/AGZVIJKBCzdZzO3JHXIgCJFaX4Za7hs/l+qMIB7SyUJ5G1G0i9LQ6/Zd2heK+BhNkAlAL+U4MXfc0Xn2HimQcmKCwjz4plylAlmXkQeac41g5YENxFg8q7qjRlQU+FoxHB53Bq/Lxf/mIABqxC6NeaCgcJDFR7P3vcYXMkvXCRf2LjyEtKmqC2CX3eJvtfEPoCV/rzREHJ+75c/FKmFWzYeCsG1HqX7geHfhpd8BeXjFtLDG0jlmD6B5LCa+VQYRERmI/5riZOwnDaHSVAY1VyohaNw== 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=fPrlI+dwHbsY7j0KZuLyjs8scp0KgJZRDLEnutWvKk8=; b=jCSx1MiAcJSGi86k1OdbO8tt1MnIEFDiwYUMWaI6T8jgsvYCDaRYVf2HJ6MSsFc8TItnaGA34/qimyYrqvtqabWoC40YjfWoJVsVqqBSNLRPJ9dyF3HDVpn1xRMJrOW3xnPAUEmnCFAaw8mx9nciBHMP0GBn6kPgkmf7YcjQuiaWztN4ekyJWkbrUZUbJqDotIakjTC7gGeZ2JiUaqfJAPyKd10ZoSJKBByWNEldwOTav7vVvmvA8dcHyJhGW8xFy88SDX1TbGrJZ5BHwZl923FLpSkrZByR55VjD++e14BgBoitnquPzTgl0ngKBQLr7xFHt8dj1koCt6EX6othYA== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v4 2/4] xen/arm: its: separate ITS and host LPI quirk scopes Thread-Topic: [PATCH v4 2/4] xen/arm: its: separate ITS and host LPI quirk scopes Thread-Index: AQHdUEUVmn9fk6RBvEynggq2k9Sfvw== Date: Tue, 13 Oct 2026 02:52:10 +0000 Message-ID: <87bj8ywbvq.fsf@epam.com> References: <8f586eb079dc00fb2f4612349bf55d84bf52d105.1790707009.git.mykola_kvach@epam.com> In-Reply-To: <8f586eb079dc00fb2f4612349bf55d84bf52d105.1790707009.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Tue, 29 Sep 2026 22:02:11 +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_|GV2PR03MB11669:EE_ x-ms-office365-filtering-correlation-id: 5725fc6b-c3ff-4fc6-fde1-08df28d4f9fb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|42112799006|376014|366016|10067099003|3023799007|261009223027099003|38070700021|11063799006|4143699003|6133799003|18002099003|22082099003|56012099006; x-microsoft-antispam-message-info: O3P2sI8EuJeURncCiZRLiCfkDL/JZ7FRRxVVGRnG0rVEFEUm3zRWZLrMTPpnNwig5rBqAEwTFB3q7PUI7bSdoaP6ac52MlJTt1e7EaU8NADY7eUYwcZ49Kve4gbVpuTZp6Wz7XJcyMs9k7Qj7JTVEwOcco6xXdC4gPmzGkIOHrkRR9+qVXIi0PpyqDw8tg5EPL8gGaBj1gfLjlbjeoXjT74JFolSeR/9RuPEaGhq2DwgTFyD7KemnV8ptFuiivjCnQ9ytHKtnMtSc/wHByuIGY3ttMHu5wnWLUWUBAmOAx3d/x1Fx9L087R/csXLBlAweYtCpjQBkBAIcPtu9vLCck+4JCtA4ycOsIGYY6hn7K5Y8lD0g1ffIJ7mXvUlXyKo4urevW3jgElWyYgAB+qHxs2CxTCwNsR4qDk9hBGihztMVvCoAePH/XiAI3nJ5XOmyUKtbjF0QYd8yfl/1rPgdeswWKMsICfQ0QOzI2CmZcM28cLOP2oMolg0Y56QFfBYUDBylE9UmkY9TAGWvZUm0oTxj+YTC4Qy4h1Hi4g+f2E0kfOROd6gI88MCH8A1WGa9u/x9km56dTneBSUgT6uQ7h6gwkgGt7gy/R581rwdGxNw9AXmwz85YIbxbo8lwx2NHrtbdRZ6Xko4gE9TGBxHveaxeZrenfFTyVLOVbSbrlxXspLGnUelSuLBF5XOYgFTqR/GvGyBrlo+AB+LYThfQ== 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)(42112799006)(376014)(366016)(10067099003)(3023799007)(261009223027099003)(38070700021)(11063799006)(4143699003)(6133799003)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?RcylxPzF8tIFlAr12hjtM9uisWP4IbABQcLtKDy+Sj+CHgoWLHqDUnp5YO?= =?iso-8859-1?Q?0xnB84qu9JZ7VXG4z/n3LIpD8G/JbF/TvVMPrDsSYR2orj0Q7pVc3K0aia?= =?iso-8859-1?Q?j/e69jtEPeECNRPLMQfQa2BSj+lAieFmrAPAES+71dXJV4oHjbPUdYxE/1?= =?iso-8859-1?Q?z70Bp1g+y13tGpsjU984s/UX2fwlcZZm+UtBP5duDs7DMPwcvyFAxJGqvu?= =?iso-8859-1?Q?D9NuuJZc9ApDv3c31fVmMQESZYaNBnDjcO1/0+xC3e4zyqcRw5/a82QKEO?= =?iso-8859-1?Q?EWc5IWO2U8WHSdfdN2wiF/Mpi2sBb6nbXyJl3op7xuajDuAJ8ppMbGChXT?= =?iso-8859-1?Q?GXvjPSSvactbsYrhzK+ocjb8FW+DkZtN4WwcHQn4ZIn8W5G4ZT2iOn5ngQ?= =?iso-8859-1?Q?5bPVvhjx1QeiVwWv7R+QKJ4XS0XiCSEd+d6kz3c8kk8mnajMHxW8GlVLqu?= =?iso-8859-1?Q?0uRm+rhAz5EN3XIFogtn+WogtPoEoJdY1XcaKUiQg7j7sRPDT187zHFQE5?= =?iso-8859-1?Q?OPOHfWUPNSC3OpdIMQNYQ5ODOfb8kgeH8fODBHUINkUi5hmEqIhla/A194?= =?iso-8859-1?Q?v09A2baJY2juPshkOBdGIxds2OyuyxQwwRW+XISBsbgu7vWA3asFs9rgHe?= =?iso-8859-1?Q?CqrVSsWAgtb5NggBhV9TVqTo0NAqcElPl3Ydosw5d0ooxVAeEQbTUwwv4N?= =?iso-8859-1?Q?pYPVLTc3vmHrcX6WjRjEJ1/gg1UOzSkpb/hMTxoQPxGIY7ZOWISU3M6IFk?= =?iso-8859-1?Q?ntb2d/01N/rybIRX6bWQa7ILhs1eLA/qz9V17sK8VpIYGMTGFxFrGfMeum?= =?iso-8859-1?Q?2HXUHqZRzQgwn3W0egDwPvAlVdTGVWp0X1JilGhUkWpd7i10dK3qqOb0k5?= =?iso-8859-1?Q?vzFQ7td6LksVO6P48BUlEua41HbIrEsNnw56A2TRgz5zToydYNvEVBkVtC?= =?iso-8859-1?Q?D6w/+xyc/5wysfbSVCZFnIissjNHLx0sQ+c/tnIONf9Xf7zY1j2fZtGiQ5?= =?iso-8859-1?Q?u+t9MAVZ8Ve3y9nMJ6z0THTLqeKdPL/1z1emaMqTY8lYFbjEJCSmSu8t7p?= =?iso-8859-1?Q?CYO92z36tetm+eLw/dAW2ksbPEs7AOOHkUpMPvwkgvyKVIKCxqlqEGD3BG?= =?iso-8859-1?Q?SHHeQSgOgO7GZH0B7CkP8/vKKU83f1TXkK7MXoQmckAw1TuXKSRaKRS2Hd?= =?iso-8859-1?Q?WZeackSTh9Sog+YE5q+zKCROueuE5igLk33U1iC4oWaC0Cta38mOUqYTCq?= =?iso-8859-1?Q?aBg+GyOrQMjJSlG+LPah6KcyRNFjf4AMqXaVUQWNizhtMl0crNgfxgOrEh?= =?iso-8859-1?Q?stQk1I/XnR9C5BvKQi/G3KzCsSD84gotnbPdwy1iZy7hDzm4YbWp9GVhme?= =?iso-8859-1?Q?y5QxpYf3NiOU8RTVY01OBoEbhV3KdzPkDhgAr7wJGfx4E5xObar9LXgZSt?= =?iso-8859-1?Q?E8ZPfGzE6mrgNm1jNyJcvqPA/xoRnaVhwrVU8l6PfFtA/ay0tf06Fa6tw1?= =?iso-8859-1?Q?x+Y346J1wQLqoS8P5XDYzYe4vE4QQyt+Nt/fmXnEl9I7M8F4PPl3ZVTFXn?= =?iso-8859-1?Q?MwOYZtig0C4kgRhItAsXj0YQZTPW3H1d8tuoBXLPiW1DQBk7WxP1dz8ZDX?= =?iso-8859-1?Q?V4r5dNYQnFucUTZ79UMxLAY0nytENVkmFGOsdVhHAfHzgmw7VrXS/aaNkj?= =?iso-8859-1?Q?IRafoYWrTiAebxBoXYH65DzEoeizgl+g7pvNIB8rlMFcnpYVSSToJqHDu2?= =?iso-8859-1?Q?ErI8JcpZuqXZtmk8PW9H/6pZNbUzPHB/PKUbt2Ypw11J4OxGJszmj8ogBs?= =?iso-8859-1?Q?sdOTfThR9miwnBBR1TheHqGlIrbyYIc=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: 5725fc6b-c3ff-4fc6-fde1-08df28d4f9fb X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 02:52:10.2053 (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: pLRNhvGqkZF8ZggJAWHaXcLliZrjLIbFdpGRUKr8pjKVlCJzj9C6LScAmGTxTIzGu7YnhT1D5kdelgZ+tQFLghmeX8+E3SQrzTbxehgt3Eo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11669 X-purgate-ID: tlsNG-33051d/1791859940-77AF14E9-F6408D28/0/0 X-purgate-type: clean X-purgate-size: 21599 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 Reviewed-by: Volodymyr Babchuk > --- > Changes in v4: > - Calculate the table entry count in its_map_baser() instead of passing > it as an argument, and move the table type selection into the helper. > - Keep the ITS/LPI quirks handling comment above the shared helpers. > > 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 | 150 ++++++++++++-------------- > xen/arch/arm/gic-v3-lpi.c | 45 ++++++-- > xen/arch/arm/include/asm/gic_v3_its.h | 19 ++-- > 3 files changed, 118 insertions(+), 96 deletions(-) > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index 511e49a116..280ace0577 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,19 +424,41 @@ 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(const struct host_its *its, void __iomem *baser= eg, > + uint64_t regc) > { > uint64_t attr, reg; > unsigned int entry_size =3D GITS_BASER_ENTRY_SIZE(regc); > unsigned int pagesz =3D 2; /* try 64K pages first, then go down. = */ > + unsigned int nr_items; > 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; > + switch ( MASK_EXTR(regc, GITS_BASER_TYPE_MASK) ) > + { > + case GITS_BASER_TYPE_DEVICE: > + nr_items =3D BIT(its->devid_bits, UL); > + break; > + case GITS_BASER_TYPE_COLLECTION: > + nr_items =3D num_possible_cpus(); > + break; > + /* In case this is a GICv4, provide a (dummy) vPE table as well. */ > + case GITS_BASER_TYPE_VCPU: > + nr_items =3D 1; > + break; > + default: > + /* Ignore unimplemented and unsupported table types. */ > + return 0; > + } > + > + 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 +472,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 +570,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; > } > @@ -583,33 +591,11 @@ static int __init gicv3_its_init_single_its(struct = host_its *hw_its) > for ( i =3D 0; i < GITS_BASER_NR_REGS; i++ ) > { > void __iomem *basereg =3D hw_its->its_base + GITS_BASER0 + i * 8= ; > - unsigned int type; > =20 > reg =3D readq_relaxed(basereg); > - type =3D (reg & GITS_BASER_TYPE_MASK) >> GITS_BASER_TYPE_SHIFT; > - switch ( type ) > - { > - case GITS_BASER_TYPE_NONE: > - continue; > - case GITS_BASER_TYPE_DEVICE: > - ret =3D its_map_baser(basereg, reg, BIT(hw_its->devid_bits, = UL)); > - if ( ret ) > - return ret; > - break; > - case GITS_BASER_TYPE_COLLECTION: > - ret =3D its_map_baser(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 =3D its_map_baser(basereg, reg, 1); > - if ( ret ) > - return ret; > - break; > - default: > - continue; > - } > + ret =3D its_map_baser(hw_its, basereg, reg); > + if ( ret ) > + return ret; > } > =20 > hw_its->cmd_buf =3D its_map_cbaser(hw_its); > @@ -738,6 +724,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 +788,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 > @@ -1217,8 +1205,6 @@ int __init gicv3_its_init(unsigned int host_lpi_bit= s) > return ret; > } > =20 > - gicv3_its_validate_quirks(); > - > ret =3D gicv3_lpi_init_host_lpis(host_lpi_bits); > if ( ret ) > return ret; > 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..2a8233df54 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,10 @@ 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. */ > -uint64_t gicv3_its_get_cacheability(void); > -uint64_t gicv3_its_get_shareability(void); > -unsigned int gicv3_its_get_memflags(void); > +/* ITS/LPI quirks handling. */ > +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 Tue Oct 13 02:59:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 02:59:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446662.1662755 (Exim 4.92) (envelope-from ) id 1xGSjS-0007vE-2M; Tue, 13 Oct 2026 02:59:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446662.1662755; Tue, 13 Oct 2026 02: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 1xGSjR-0007v7-W2; Tue, 13 Oct 2026 02:59:13 +0000 Received: by outflank-mailman (input) for mailman id 1446662; Tue, 13 Oct 2026 02:59:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGSjQ-0007v1-4P for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 02:59:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGSjP-00DesR-EE for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 04:59:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd9e7d-8faa-0a2a0a5109dd-0a2a45029404-6 for ; Tue, 13 Oct 2026 04:59:11 +0200 Received: from [52.101.72.72] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd9e7f-6ca4-0a2a45020019-34654848b25b-3 for ; Tue, 13 Oct 2026 04:59:11 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by GVXPR03MB11092.eurprd03.prod.outlook.com (2603:10a6:150:2a9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 02:59: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%4]) with mapi id 15.21.0496.020; Tue, 13 Oct 2026 02:59: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=WHReWNORxjACEptDw82Gy3MH+PnU+A+4SvkphC4zF19+HMrKqbNmh3AxjgqQ9MWNWzIveFwQrDtWwYfNxHUd0bvKa7tpnoJ03Vm4BujpmpLDhPXzKZ91p+RooPcONNUJd8+OGnhDjSiraQ2ORXoJSdzIlYXMlud5gAtqSrup6b92HrXcEmMZBVMXkj4K2mUhw1buen4xH/u/EF0qj2X12BVeldiol7UPhNtiH3wYakkvim2dFUx/Z09teGhyXvOr/7saqh4V5mfZm1aGFFW/qJLo6GTlvPwzMAMC+qZ23m7DSowuFWzVAGhrYTzfx8T982g/bHkbsuiOJrZP4M5b0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4mQc2r15wOLTA8zOhQs/kKQnVWeEG1CIJ/D1gPI2Kcw=; b=jSRr6yn+S6zpXvCovOwF2EFGW1mp5JSJHQ3eiCQIBkt3aCWGRvHNePCghQiq0KnfOHw4jvOl5q/oQcYjv2367COK1YJRc0uxj+8WVNKpHPi3HHJOqV6Bvx5o3NP50/MTT/mNiNPmL5dPzeiWaXHsaOgWydRiINh5lPz+BZ0z2ZRzhbGyaLW23oJYLr/NPS3+cTJx73q9nMUPTTp8KTNWFJ0HKsBa2wZUVkO37hlJk0CQlIR0V+Lum4NZ8OEwZ7UVxkELWaAaAblmzxeqWMIK4yhi9Wz7WJqYGuI/5H12vonqUGJJlK2l53e0V/7P/bfMfhynm0YTn2NtNV+LSJYATg== 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=4mQc2r15wOLTA8zOhQs/kKQnVWeEG1CIJ/D1gPI2Kcw=; b=Q0U8tH0YwbONoWuQpLrrZV/cEeWvN6sYggaLHd1dAhhGhxHTxZnoxJ/tfq2nAG/J52B/QwjJtFKmyrgi9tHKjG06gDGDIJhNtvGpeLbi5DnzqDN/hlIq97G3WsQ4pWDSESVXtM72KQgWP6+RgUwdYzA5E08zood/WyqRDZJE7MR74u+5zQOygUKKijnALEErmCjD+LDlPjsmigq2gFS/D6SoY28i9PgZW8yfFfTBYlIiEFCxW4k2fLmkOu+RfUJ7AQeFJ67gcwt/95hQR0VGkbY2QkRDGTRavT9TKXG2oIOblGPH/H7BSHg4+8I/HeDtdl+Y8vE4mEbs5BR59+orRQ== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v4 3/4] xen/arm: its: refactor ITS quirk matching Thread-Topic: [PATCH v4 3/4] xen/arm: its: refactor ITS quirk matching Thread-Index: AQHdUEUWBir3UQDjYEWvHkcwQ5Z1KA== Date: Tue, 13 Oct 2026 02:59:05 +0000 Message-ID: <875wz6wbk6.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Tue, 29 Sep 2026 22:02:12 +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_|GVXPR03MB11092:EE_ x-ms-office365-filtering-correlation-id: 11f498ff-013c-4649-5145-08df28d5f1cd x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|42112799006|23010399003|38070700021|11063799006|56012099006|4143699003|261009223027099003|10067099003|18002099003|22082099003; x-microsoft-antispam-message-info: SN/XEY6HxB3IEw3B8duZ02q9e4Jv5fo32Kyc+pn6ZMuG77OLzB+mX0ZrmBz1NWPs83JBZbyWenS2DfrU9/wAaj75FMP+wYxDe1xh3zjgWv4xXIU2olL14ZVpb++T3ZrG/2Wydb7zIp0QKZmEh6L5GWlkNW3qnkFPxiK9xN1bJdizwo1m3hiYL3rsiSY9ZXtk9opl7Mv9KynNufsqQMPEOkSM5mhTYL5T6BO3MFHygRG/CxdjgFgZr8wSyy1CI829oIdGvD3fg+Nxb0Wlfyi9S2S/0yXAespDs2Amw63JC/TI0U0IxwY5G6VKFOzL9IVqcXIdIViZWqv0P4iRQyH71O82P/lbX9fqrEBb5sQHj0CFQjUInFibspXEvneLkNXImYsgdFMj6b5lJyQhBzWwN+C8IUTNfrDADJxhKGcHh78FqWzsmtYcgfA8PiexCYqY+aMuLLmwaDcRwrGvunMlxi9DVjAGyjOoVCYzrZy5p2zfZOr8Gc9Gzq3XYPp3MzBukAamBwk+Mt4ie/Be4znptKc75OnzXc4rSihSPk6lGLnZ2WOYFd2ReigsFuwS7FANfSVcTi3jAcOcJQzFUXGse85BQpMBCHynjziOxvuYSqB95TR1uylG2a8AWtHcm3IgX4ui1nCdPLIakkzmJ4VSUPbgdN3L2UQtesKjyxil6roxdS7rJDMmj75qo9bEkb5uHlmJnvgIp4N37z5/+RZkuZChHMgq1oH5gpvxGpfA0uk= 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)(1800799024)(376014)(42112799006)(23010399003)(38070700021)(11063799006)(56012099006)(4143699003)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ebEpedceUdDUhLWFq9P3SEEFpIC8eEyX2+2BYGb1XxCr6ie0HCImxkeEK3?= =?iso-8859-1?Q?4GuYhXij8uHPvckcrxPOaHbdu9AzqCtKcBUFxEFdK963q5b2pnfGRCwp/S?= =?iso-8859-1?Q?vI6SrXqk1JBC5kn3LT2W5D+28Fbt00lkzRELEUgEEsISKya0tM9Mt2+Zgs?= =?iso-8859-1?Q?Cei7GygoQ59qMVDLp9q+oCZlAPDEIJXzKsCZUZ8xLSP4702JcSLo2uZmWH?= =?iso-8859-1?Q?UBSqyX3KEkWW+zTX5tIotBqD4YCO/HKs/U/Zx/ykdvPBiKZzFjdBvmHol/?= =?iso-8859-1?Q?4UJJJ//hQTVP5aWTN+Mew/8MWE9HKAaY4cmmGnm1Z89oK6EFdCU+RmsYfi?= =?iso-8859-1?Q?wr5zcbIGnqiYK9uzBQwWm1gB+Wy1V0QGGAmCcm6qZiN4AocKFLZB25ohhj?= =?iso-8859-1?Q?dzBwOpxHo5NjUyKa84sFcKGsLawA9QSJvPybgU5mgsgbPchKpe0YEMZwf4?= =?iso-8859-1?Q?4L785IdrvgPvUfcFcwjjk52LXdOuIdqCpnFHODCYiBF7gOP4V14V2U+KvK?= =?iso-8859-1?Q?J/WYRaabTTMVnCal4+K9bwFzlJ4mcUGdltMKm4hrpWbfgPUS5tAnovQKUr?= =?iso-8859-1?Q?8bRblX1izWPYxuXvipzpXcg4NQOwGc+DvXqJqHATWy0KTj+9YN04DvWRKD?= =?iso-8859-1?Q?guVob9FrRe7vE8Ky3yY61HrDS0N3pRTf9/m5YfhCpWOzTZ8R00ogj2RSKH?= =?iso-8859-1?Q?ZM/iG2N/m5YM7q5Tomqifqz70kGhL2w/IiqGYYNYp97lFIiGmSAKGkB5xh?= =?iso-8859-1?Q?K1WvZJZ/YEAMd0VZxVM1/+L29EGIzql2GW6SnX8bnbUX4CHEDUDnkk1gLi?= =?iso-8859-1?Q?TTsuh8Qz3QzximgxldgTzIBLTtt5FZQZ4aB7i6gpuWtsF2VR18yxz9EZZt?= =?iso-8859-1?Q?hGwzM9k+J1U1zJkjYw+jQuKPC43WKwCLmHxVH2NjYWZGRfXk5vvzXjhd23?= =?iso-8859-1?Q?UVPjTzivgQn1DpdeGTh2EUl7HsCfGkBX9K/FoTpod3SE647NVTAxHR45OD?= =?iso-8859-1?Q?C14UgUP67V62a6UFkd/e/cNJOJwxIgiPuzoRcLOWo9w9YIb5vusSKs2U8R?= =?iso-8859-1?Q?Nif3SBHukTRDBeLT1h+sTH6Wy0FGrdNTBKwWCNtmFEXbQNYt2Bi+eFNHis?= =?iso-8859-1?Q?V0h3dymtx+s1O5aG1mjgxZ43Bd+rU5zQi0xK8WOVq1GHZcL8RIL4wIt2+d?= =?iso-8859-1?Q?NV2+0o0fhp0AQGulk+Yly6i4sD5x19Sj/sgF7QrQ1HCaJM6nlWHca2fMM8?= =?iso-8859-1?Q?gjljOKgwdCA58+VATA3K4Lz2aAY+M/rvH6CaxbQBI9U/Yeuz85PaDU61kX?= =?iso-8859-1?Q?iMD5vulIkUsH16wAoKNZjjMItdNO3bnO4ByB9twWncQd3EUyNyFbjnsHtq?= =?iso-8859-1?Q?CvEDrgRyi2SWHIBk+xyhWw8ltfKNOG7UxC3f+G9F8MbNgF5f/GXCn4kVtO?= =?iso-8859-1?Q?9QKJPj7PnmlsEzl9dBTvUle5Hjim27iMLfyQeDuYNvrpTnFbh5mEDLoJia?= =?iso-8859-1?Q?Tt0FeZ3N+70mQMIFLAJabv72nV9vJFzse1/aDy5tYjT5/iEOL2oQWNk8wY?= =?iso-8859-1?Q?vuh+iXeDBYbdXwqijwsVHP+8bD6uV+StUXA8+xgHk28qwpd9NA23Nh2Jgf?= =?iso-8859-1?Q?NqG9rfzjDdFpEOQe7iO40Qf8HCJkh4izKvb5LN5LNXJcpli8027pJYcnj6?= =?iso-8859-1?Q?D1FSE9gpA0olfpXayjp/JM9lMx3Erxpy63qoGSNQOkkUh0/X5vlQddQO4N?= =?iso-8859-1?Q?uBvkkRFREShW++TlVe9rrK/1SIogk0DyM9M1Nx7QHel0YY+tW480uYYqgt?= =?iso-8859-1?Q?BSPIieVaWRj8+MCf3oFzHx/rQTyZIoc=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: 11f498ff-013c-4649-5145-08df28d5f1cd X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 02:59:05.9193 (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: rZDOwEcPMkDRfVmJwkgjscn+c95rNwPsvebobGTLCcEYVv9huKuWkdokBSqyuL+T+Mh7dQUwX19BwOoz75JDu3CyKiawiKcPtpe5k8AU2Jw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB11092 X-purgate-ID: tlsNG-720697/1791860351-674BE2AC-E95EB5A7/0/0 X-purgate-type: clean X-purgate-size: 6057 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. Use BUG_ON() if a non-sentinel > entry has no matcher or the IIDR matcher receives no data. A broken > entry must stop Xen in both debug and release builds, as skipping a > required workaround could cause a failure later. 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 Reviewed-by: Volodymyr Babchuk > --- > Changes in v4: > - Use BUG_ON() for missing IIDR match data or a missing match callback. > - Keep the existing quirks variable name in gicv3_its_find_quirk(). > > 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 | 64 +++++++++++++++++++++++++++++++-------- > 1 file changed, 52 insertions(+), 12 deletions(-) > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index 280ace0577..43804a6c7a 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,49 @@ 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; > + > + BUG_ON(!data); > + > + 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); > +} > + > +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,17 +116,20 @@ 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; > =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++ ) > { > - if ( quirks->iidr =3D=3D (quirks->mask & iidr) ) > + BUG_ON(!quirks->match); > + > + if ( quirks->match(hw_its, quirks->data) ) > return quirks; > } > =20 > @@ -97,8 +138,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 Tue Oct 13 06:26:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 06:26:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446677.1662765 (Exim 4.92) (envelope-from ) id 1xGVxZ-00038F-CK; Tue, 13 Oct 2026 06:26:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446677.1662765; Tue, 13 Oct 2026 06:26: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 1xGVxZ-000384-7y; Tue, 13 Oct 2026 06:26:01 +0000 Received: by outflank-mailman (input) for mailman id 1446677; Tue, 13 Oct 2026 06:26:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGVxY-00037y-Bs for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 06:26:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGVxX-00Bfqe-8d for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 08:25:59 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdcef6-2eae-0a2a0a5409dd-0a2a4503dc22-0 for ; Tue, 13 Oct 2026 08:25:58 +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 6acdcef6-fae8-0a2a45030019-d1558029acfc-3 for ; Tue, 13 Oct 2026 08:25:58 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a01933b584so21919525e9.0 for ; Mon, 12 Oct 2026 23:25: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-4a18bf2343asm628836405e9.9.2026.10.12.23.25.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2026 23:25: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=1791872758; x=1792477558; 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=pPpsKBaqXYpwTdj4AMUqYlftnFOL6OAbWY290AmRxXY=; b=C+r2tqqGIUz9G30+HVRQ1TO949iOi7MigQE/0JuBMQJhj31RCLBHRmICBbIfoP/s94 kr1n6coqy1Yo+0GoV5ZET8JNBNdr71uH8EFJK4tC7LyFxkWJCjQGVXEsnoXNGPmtmUAG FrV9dRk4hXPAkY1Njv5Idfbu809haV1QHf+8oGMKUUwxK/acqEVNs3wzRH7hRaBEWWAF 0tUtdOAg+aqhMeNR7XITXeOrDaFzOofY0FZTYV3NFDKPuEMmJYSNOTn1PWOyjMx36wCu bNY2D+7Jecs1tHE3uSlADAgLhZ00mGn6spP5TOQ8va/tsKeGdCL06fpa8ib/NeEJc2SI MFrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791872758; x=1792477558; 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=pPpsKBaqXYpwTdj4AMUqYlftnFOL6OAbWY290AmRxXY=; b=nDGGLdmSPF7/GR0uY/IlGfJV+mgVqPGdf1ZBHJqZq9gXfsjd8pqqZKtSbjpRG51gy2 RX3Q6HiOOb2tznvK0Y/w+aQnqfdISFB/9KYgme6osZHluxUVseeZJQ62RohhXx7hioQT jL7E0IGuoJ83Ogg37VhpDnGiOutufgzguH82DINQRAxM+sIfzgfkXfjfSplo5xLvNNw8 0VGakUknVo7DdGO5lALNvtsD6xwn3MEQiCwp3gQh2/ss6rCjRD7U2aq5sIBBNNO39nvX W/P64nQRqvicC+4HAUiezy2yEiIdy3QvOIkFXATG143HfEH1DaCD7YsCnw8470pJ8dq4 ZpJw== X-Forwarded-Encrypted: i=1; AKwUvBx2g1hEb58TvgcqpmQt9PhGR95KF4hWtCxlzrLKxSFOIjzFr9ns6yrHXpzcPUtrjz60kI8Y0Qpb+ME=@lists.xenproject.org X-Gm-Message-State: AFq9FYJYACuNY3MehwBQwgvciVhtFrkX8lk1pgX9YIhQBh7GEQaKmP4Q 2QQ+2wlo9vxZZj71PrdlnQdW3iN4aTQfh7xTHH+sg6KO29cJKxvHgwZH8DVfTncOwA== X-Gm-Gg: AYBFou1NCHcYEduNlag+85pou1g7NwG/EpmU+5ezgUJEaRUWXRV5ncvubatpwmqf1Wo 1ua0lZShfg9JTDExC7HZTkh/qyvZrCQ9uqj+sq4JKNxAyQL8kQTUtLSeEXQ/TZzvf4dsApKIrFH fBZrKkRDU6KGIVuelOPxOB0sHSej4VeHd0ND0wk9LTM0hOIC047+eyz7UhN0l+aTSv/79j8HuYV h0/7OIl8L6oGw9EMvcVQ0zOrGL/PidyQHaWccH4loG4QMQ9r9iKx20l3LfDuyoOWYavuekdJ0+n FTKt1SZyVWvdqH0BtOv00tlmsbFrXuhGV7paahvI/3qnGRTcXn4qQhVKE2NBgToyj7qPBCLxN5u iL5+VZ5EcpuJ5GeYiva5kRhdaq6W10PopmRRk+U8HXsNigb987mg2od5aaUg30fp+nXK7XqIDvM PGhmO3amDbcTePRj6aafqPzgNQfKKdpWfeh7Cc9gYL9aeYBNsQMg5XcJQGTcm+scoOQFcyzoYO6 fqHMud8p7jFD2whwNkWB1V/4GwcGOiSCsrhgPO1Ywgyh7I6ZM+pPD9wZlbJPpEjrHwLN6uo7Q== X-Received: by 2002:a05:600c:1e0f:b0:4a0:1f51:ba2d with SMTP id 5b1f17b1804b1-4a18e4adcbamr206715175e9.22.1791872758322; Mon, 12 Oct 2026 23:25:58 -0700 (PDT) Message-ID: <43f7a948-669f-48cb-8e1f-9d1a8a98a8f5@suse.com> Date: Tue, 13 Oct 2026 08:25:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> <8514b7b6-cf1c-44d9-827c-675fd5a6708e@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/1791872758-75EFF4E9-889696D0/10/78276251493 X-purgate-type: spam X-purgate-size: 2920 On 12.10.2026 18:07, George Dunlap wrote: > On Mon, Oct 12, 2026 at 2:48 PM Jan Beulich wrote: >>> @@ -74,12 +130,12 @@ void *map_domain_page(mfn_t mfn) >>> #endif >>> >>> v = mapcache_current_vcpu(); >>> - if ( !v || !is_pv_vcpu(v) ) >>> + if ( !v ) >>> return mfn_to_virt(mfn_x(mfn)); >> >> I don't quite understand why this is_pv_vcpu() is okay to drop. What >> mapcache_current_vcpu() returns isn't what it ran is_pv_vcpu() on. (Same >> in unmap_domain_page() then, obviously.) > > So mapcache_current_vcpu() is a bit weird; the actual invariant is, > "Return the vcpu whose cache structure we should use if present; or > NULL if there's no cache structure to check and no need to sync." So > if pgtable_vcpu is HVM, return NULL and just use the raw address, I was going to say "But there's no returning of NULL there if pgtable_vcpu is HVM, at least not at this point of the series." Only then I realized that I was being confused by there being both v and curr, and neither of them being pointer-to-const (i.e. both being equal in terms of which of the two might be returned from the function, yet as a result of earlier changes neither is being returned anymore). > because at this point in the series, both HVM and the idle domain have > full directmaps; if pgtable_vcpu is PV, then maybe sync, and then > return the result of the sync. That may be a PV domain with a > mapcache, or an idle domain with no mapcache, but in either case you > can then read cache.inuse to see if there's something there. > > So yes, it's a different vCPU; but it's still defined in such a way to > be safe to check cache.inuse. The only possible value *change* after > a sync is the idle domain; I don't think we need to do another check > to make sure it's still a PV domain. Yet then - aren't the is_pv_vcpu() you drop here redundant already before this patch/series? In which case (since it's not entirely straightforward to reason about and beneficial in its own right), might it make sense to have this be a separate change, with (in particular) dedicated justification? (ISTR having thought about making a patch to this effect a little while ago - perhaps around when Roger last touched this logic -, but then deciding that something was wrong about my reasoning. That may have been a mistake, as it looks now.) > In fact, there's an argument that we should modify > mapcache_current_vcpu() to take pointers to dcache, and vcache, and > return just cache; that gets rid of v as a local variable of > map_domain_page entirely, and makes the logic ("get the cache we > should use") more clean, and gets rid of one mfn_to_virt() instance. > That would require some non-trivial changes, so I'd rather avoid that, > but I can do it if you want. Sounds entirely plausible, but can as well be done as cleanup later. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 06:45:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 06:45:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446683.1662775 (Exim 4.92) (envelope-from ) id 1xGWGX-00069K-Tn; Tue, 13 Oct 2026 06:45:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446683.1662775; Tue, 13 Oct 2026 06:45: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 1xGWGX-00069D-PJ; Tue, 13 Oct 2026 06:45:37 +0000 Received: by outflank-mailman (input) for mailman id 1446683; Tue, 13 Oct 2026 06:45:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGWGV-000691-RX for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 06:45:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGWGT-00EArs-Cr for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 08:45:33 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdd373-8faa-0a2a0a5109dd-0a2a4503875e-42 for ; Tue, 13 Oct 2026 08:45:32 +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 6acdd38c-fae8-0a2a45030019-b9ff1c22b503-3 for ; Tue, 13 Oct 2026 08:45: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a13402476c0008d8d.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 06:45:27 +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 4E78481B76; Tue, 13 Oct 2026 08:45: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: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=mGTDaqFRp7fN0dtlqckipa1Fh/q2SOXepAeLGQXobdk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=BTBqi8bysSQ7e2Fl7u3AFbqIoeXtw5hMqCsrALuQ0aw1uZhJq2zGtKz/tK7ZDnsrJJuw2dsIc 5z6OxsikbpnwLYZgUSedsF/oREhYTvewknVhgR+s7r1clv+fPjvojXk+yQLasOKBP9V9Uxy6Yse ykihcIY7eE2vJIGjP32fIK9dLRuVFAT8gICWtIePq+af4k3344C6MazOaf13S0B9c8eD2nEZ/7q XozKPGO3saeDm1c0DirrFTjuurW4Tt63IBH1Bk39Y0eqMcLpY79PTVhbI20eGT4UP8haojjNbwX RSRfNpUq7Zrp+/q2+DR4/ZaWDRKWeK+F5DMCoYNdaz4A== X-Zone-Loop: 2615201c413bce2a86b8f18ecf358ecd20b25f485752 x-campaign-type: default x-transaction-id: 418737e5-1d8f-4b4a-9eb8-83a5afe98c54 x-swg-uid: 01-8604db26-da79-4c47-b36e-d8c66de37d5d X-Mailer: Sweego Message-ID: <1791873927.8631fc262581453bbf619ec5b2062170.1a13402476c0008d8d@vates.tech> x-swg-bid: 1791873927.8631fc262581453bbf619ec5b2062170.1a13402476c0008d8d Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 13 Oct 2026 08:45:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/15] x86/PVH: split pvh_load_kernel() To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <3ff41e03-b30b-43c0-9a20-28cdd9ae30d0@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: <3ff41e03-b30b-43c0-9a20-28cdd9ae30d0@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------bsuHAIf986TnD0WdBbAynk6l" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791873926435 X-purgate-ID: tlsNG-33051d/1791873932-6FCC34E9-C2F3961B/10/78276251493 X-purgate-type: spam X-purgate-size: 5350 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bsuHAIf986TnD0WdBbAynk6l Content-Type: multipart/mixed; boundary="------------t038SVZEso0mx0M0uCUGAanD"; protected-headers="v1"; hp="clear" Message-ID: <2cbebcec-e12d-4c99-aff1-548d0a7a68c9@vates.tech> Date: Tue, 13 Oct 2026 08:45:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/15] x86/PVH: split pvh_load_kernel() To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <3ff41e03-b30b-43c0-9a20-28cdd9ae30d0@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: <3ff41e03-b30b-43c0-9a20-28cdd9ae30d0@suse.com> --------------t038SVZEso0mx0M0uCUGAanD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTIvMTAvMjAyNiDDoCAxMDoyMywgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gQWxs IEU4MjAgbWFuaXB1bGF0aW9ucyB3YW50IHRvIGhhcHBlbiBiZWZvcmUgdGhlIGluaXRyZCBp cyBwbGFjZWQuIEFzIGENCj4gZmlyc3Qgc3RlcCwgc3BsaXQgcGxhY2luZyB0aGUga2VybmVs IGZyb20gYWN0dWFsbHkgbG9hZGluZyBpdC4gVGhlbg0KPiBwbGFjZW1lbnQgb2Ygb3RoZXIg ZGF0YSAoQUNQSSwgVk1YKSBjYW4gYmUgaW5zZXJ0ZWQgYmV0d2VlbiBrZXJuZWwNCj4gcGxh Y2VtZW50IGFuZCBQMk0gcG9wdWxhdGlvbiAoZm9sbG93ZWQgYnkgdGhlIGxvYWRpbmcgb2Yg dGhlIGtlcm5lbCkuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxp Y2hAc3VzZS5jb20+DQo+IC0tLQ0KPiBJZiBuZWVkIGJlLCBtb3ZpbmcgdGhlICJlbGYiIGxv Y2FsIHZhcmlhYmxlIHRvIGRvbTBfY29uc3RydWN0X3B2aCgpIGNvdWxkDQo+IG9mIGNvdXJz ZSBmdXJ0aGVyIGJlIHNwbGl0IG9mZi4gSnVzdCB0aGF0IHRoaXMgYnkgaXRzZWxmIGRvZXNu J3QgbWFrZSBtdWNoDQo+IHNlbnNlLg0KPiANClJldmlld2VkLWJ5OiBUZWRkeSBBc3RpZSA8 dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4NCg== --------------t038SVZEso0mx0M0uCUGAanD-- --------------bsuHAIf986TnD0WdBbAynk6l 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+p0QLLz9AFAmrN04UFAwAAAAAACgkQZg+p0QLLz9BP Fgv/Yi0y9x2TmqUZ0n26wKsWr7x2rP9NTBmsgC6d/PKdZHCC+HnBQL9ki762mPvgAmo3zqVyrpRU tF809KX22V/tf7gV2Pk36C6S2gcfIOqI5lbo1zZ4nKNbouNXE2US8n1PkJBHY6IpKv4s7+krWOOl 9tBuerY0+N4JWvgcUGRiu98zysxPshJV2ptYUKcodG5EKSlsk27Zy5Am5uLXD1JT8wYqC/I5WdCm mO7Mi/rojEorH4WzEO2sRHbjizMY2EBkoDaknJrscuPzZ+y6ayz1ilhFpM696cLiQHo5PudevUNN cmMQy71lofDg2+UZisvANrHvtQkRoKM5fyG+Jv8Yh1Q0k9pwLUXmxdcrHI/PlC94PAku5SIdtTPj Gj3A8fvprByvrp2ADwlQcLHrSQwQZ/o8Pj7O17/GZV/pDHMpUTNUEnz9l9UpPYZ3sdJ0ZwgKOIs2 oHIj0sbPZHXkqxHI+hiuewqHrw9VnoNx92KaK+Z1529H34nBEyr3BcStarx5 =nw6x -----END PGP SIGNATURE----- --------------bsuHAIf986TnD0WdBbAynk6l-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 06:57:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 06:57:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446689.1662783 (Exim 4.92) (envelope-from ) id 1xGWSO-00089C-0E; Tue, 13 Oct 2026 06:57:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446689.1662783; Tue, 13 Oct 2026 06: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 1xGWSN-000895-TW; Tue, 13 Oct 2026 06:57:51 +0000 Received: by outflank-mailman (input) for mailman id 1446689; Tue, 13 Oct 2026 06:57:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGWSM-00087Y-DT for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 06:57:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGWSL-00EDWd-5b for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 08:57:49 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdd66c-e002-0a2a0a5209dd-0a2a450b8d50-2 for ; Tue, 13 Oct 2026 08:57:49 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdd66c-b7e8-0a2a450b0019-b9ff1c2397a1-3 for ; Tue, 13 Oct 2026 08:57: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1340d8f0b0008d8d.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 06:57: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 55DCD8296E; Tue, 13 Oct 2026 08:57: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: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=4fuGpePABOwGGJpKSCqm71VriePSuppL4vi1OeBS1bI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=GSlysjZ1hWuucySAotMQ0vXTdewrlDoetOogiTY79FiJbkxXAk8AFGLdpPpTDbs0UqwR702s3 ug3mpQJcZYwY5V2St0XHSJJdqWm2NMeRGCrJT6vCSftgdpzs3nXTt7j/evknht5FV3O9iyWE3ri bQEZAY9TRsXRqumRpFTXLsY2Jygt9qq++17oYCCl945Bywv0YtN0QjJ2CLiBOwLhGV1x4IkZ7NK iFBoechqzMGzuBMwInmAGbZueSDzGf0IFMP7g9r0MCsc2DNnc/Pz1TNuv+XQnzw9ViA3ijouBFJ TbhghGcAPCMVz3k4stWHP4NZg3763914EqulI0qJmigg== X-Zone-Loop: 80553471785c33cb766605be71207cb4f049ff03d06c x-campaign-type: default x-transaction-id: 1d0b6fba-37f3-42f4-95c3-e0d080ab81f9 x-swg-uid: 01-2fad12ff-d8b1-4f0d-a154-7d680d89ed38 X-Mailer: Sweego Message-ID: <1791874666.8631fc262581453bbf619ec5b2062170.1a1340d8f0b0008d8d@vates.tech> x-swg-bid: 1791874666.8631fc262581453bbf619ec5b2062170.1a1340d8f0b0008d8d Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 13 Oct 2026 08:57:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <575ec1bc-764c-4016-a584-a79e57817d9a@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: <575ec1bc-764c-4016-a584-a79e57817d9a@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Hs2EcrPLcMbZOhxY0WD1eWMb" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791874665465 X-purgate-ID: tlsNG-42698a/1791874668-A90CD9EA-3A1A6707/10/78276251493 X-purgate-type: spam X-purgate-size: 9941 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Hs2EcrPLcMbZOhxY0WD1eWMb Content-Type: multipart/mixed; boundary="------------X31SnU5nEI9RxwotPhiFAi5l"; protected-headers="v1"; hp="clear" Message-ID: Date: Tue, 13 Oct 2026 08:57:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <575ec1bc-764c-4016-a584-a79e57817d9a@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: <575ec1bc-764c-4016-a584-a79e57817d9a@suse.com> --------------X31SnU5nEI9RxwotPhiFAi5l Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTIvMTAvMjAyNiDDoCAxMDoyMywgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gcHZo X3BvcHVsYXRlX3AybSgpIG5lZWRzIHRvIHBvcHVsYXRlIFJBTSBhY2NvcmRpbmcgdG8gdGhl IGluaXRpYWwgbWFwDQo+IGVzdGFibGlzaGVkLCBwcmlvciB0byBhbnkgc3RlYWxpbmcgYnkg cHZoX3N0ZWFsX3JhbSgpLiBTdWJzZXF1ZW50bHkgdGhlDQo+IGludm9jYXRpb25zIG9mIHRo b3NlIGZ1bmN0aW9ucyB3aWxsIChuZWVkIHRvKSBtb3ZlIGFoZWFkIG9mDQo+IHB2aF9wb3B1 bGF0ZV9wMm0oKSwgc28gd2hhdCB0byBhY3Qgb24gaXMgbm8gbG9uZ2VyIERvbTAncyBtZW1v cnkgbWFwIGF0DQo+IHRoZSB0aW1lIG9mIGludm9jYXRpb24uDQo+IA0KPiBTaWduZWQtb2Zm LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IA0KPiAtLS0gYS94ZW4v YXJjaC94ODYvaHZtL2RvbTBfYnVpbGQuYw0KPiArKysgYi94ZW4vYXJjaC94ODYvaHZtL2Rv bTBfYnVpbGQuYw0KPiBAQCAtMTMsNiArMTMsNyBAQA0KPiAgICNpbmNsdWRlIDx4ZW4vbXVs dGlib290Lmg+DQo+ICAgI2luY2x1ZGUgPHhlbi9wY2kuaD4NCj4gICAjaW5jbHVkZSA8eGVu L3NvZnRpcnEuaD4NCj4gKyNpbmNsdWRlIDx4ZW4veHZtYWxsb2MuaD4NCj4gICANCj4gICAj aW5jbHVkZSA8YWNwaS9hY3RhYmxlcy5oPg0KPiAgIA0KPiBAQCAtNDEzLDcgKzQxNCwxMCBA QCBzdGF0aWMgdm9pZCBfX2luaXQgcHZoX2luaXRfcDJtKHN0cnVjdCBkDQo+ICAgICAgIH0g d2hpbGUgKCBwcmVlbXB0ZWQgKTsNCj4gICB9DQo+ICAgDQo+IC1zdGF0aWMgaW50IF9faW5p dCBwdmhfcG9wdWxhdGVfcDJtKHN0cnVjdCBkb21haW4gKmQpDQo+ICtzdGF0aWMgaW50IF9f aW5pdCBwdmhfcG9wdWxhdGVfcDJtKA0KPiArICAgIHN0cnVjdCBkb21haW4gKmQsDQo+ICsg ICAgY29uc3Qgc3RydWN0IGU4MjBlbnRyeSAqZTgyMCwNCj4gKyAgICB1bnNpZ25lZCBpbnQg bnJfZTgyMCkNCj4gICB7DQo+ICAgICAgIHN0cnVjdCB2Y3B1ICp2ID0gZC0+dmNwdVswXTsN Cj4gICAgICAgdW5zaWduZWQgaW50IGk7DQo+IEBAIC00MjEsMTUgKzQyNSwxNSBAQCBzdGF0 aWMgaW50IF9faW5pdCBwdmhfcG9wdWxhdGVfcDJtKHN0cnVjDQo+ICAgI2RlZmluZSBNQjFf UEFHRVMgUEZOX0RPV04oTUIoMSkpDQo+ICAgDQo+ICAgICAgIC8qIFBvcHVsYXRlIG1lbW9y eSBtYXAuICovDQo+IC0gICAgZm9yICggaSA9IDA7IGkgPCBkLT5hcmNoLm5yX2U4MjA7IGkr KyApDQo+ICsgICAgZm9yICggaSA9IDA7IGkgPCBucl9lODIwOyBpKysgKQ0KPiAgICAgICB7 DQo+ICAgICAgICAgICB1bnNpZ25lZCBsb25nIGFkZHIsIHNpemU7DQo+ICAgDQo+IC0gICAg ICAgIGlmICggZC0+YXJjaC5lODIwW2ldLnR5cGUgIT0gRTgyMF9SQU0gKQ0KPiArICAgICAg ICBpZiAoIGU4MjBbaV0udHlwZSAhPSBFODIwX1JBTSApDQo+ICAgICAgICAgICAgICAgY29u dGludWU7DQo+ICAgDQo+IC0gICAgICAgIGFkZHIgPSBQRk5fRE9XTihkLT5hcmNoLmU4MjBb aV0uYWRkcik7DQo+IC0gICAgICAgIHNpemUgPSBQRk5fRE9XTihkLT5hcmNoLmU4MjBbaV0u c2l6ZSk7DQo+ICsgICAgICAgIGFkZHIgPSBQRk5fRE9XTihlODIwW2ldLmFkZHIpOw0KPiAr ICAgICAgICBzaXplID0gUEZOX0RPV04oZTgyMFtpXS5zaXplKTsNCj4gICANCj4gICAgICAg ICAgIHJjID0gcHZoX3BvcHVsYXRlX21lbW9yeV9yYW5nZShkLCBhZGRyLCBzaXplKTsNCj4g ICAgICAgICAgIGlmICggcmMgKQ0KPiBAQCAtNDM4LDExICs0NDIsMTEgQEAgc3RhdGljIGlu dCBfX2luaXQgcHZoX3BvcHVsYXRlX3AybShzdHJ1Yw0KPiAgICAgICAgICAgaWYgKCBhZGRy IDwgTUIxX1BBR0VTICkNCj4gICAgICAgICAgIHsNCj4gICAgICAgICAgICAgICB1aW50NjRf dCBlbmQgPSBtaW5fdCh1aW50NjRfdCwgTUIoMSksDQo+IC0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBkLT5hcmNoLmU4MjBbaV0uYWRkciArIGQtPmFyY2guZTgyMFtpXS5z aXplKTsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGU4MjBbaV0uYWRk ciArIGU4MjBbaV0uc2l6ZSk7DQo+ICAgICAgICAgICAgICAgZW51bSBodm1fdHJhbnNsYXRp b25fcmVzdWx0IHJlcyA9DQo+ICAgICAgICAgICAgICAgICAgICBodm1fY29weV90b19ndWVz dF9waHlzKG1mbl90b19tYWRkcihfbWZuKGFkZHIpKSwNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbWZuX3RvX3ZpcnQoYWRkciksDQo+IC0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5kIC0gZC0+YXJjaC5lODIwW2ld LmFkZHIsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5k IC0gZTgyMFtpXS5hZGRyLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB2KTsNCj4gICANCj4gICAgICAgICAgICAgICBpZiAoIHJlcyAhPSBIVk1UUkFO U19va2F5ICkNCj4gQEAgLTEzNTIsNiArMTM1Niw4IEBAIGludCBfX2luaXQgZG9tMF9jb25z dHJ1Y3RfcHZoKGNvbnN0IHN0cnUNCj4gICAgICAgcGFkZHJfdCBlbnRyeSwgc3RhcnRfaW5m bzsNCj4gICAgICAgc3RydWN0IGRvbWFpbiAqZCA9IGJkLT5kOw0KPiAgICAgICBzdHJ1Y3Qg ZWxmX2JpbmFyeSBlbGY7DQo+ICsgICAgc3RydWN0IGU4MjBlbnRyeSAqb3JpZ19lODIwOw0K PiArICAgIHVuc2lnbmVkIGludCBucl9vcmlnX2U4MjA7DQo+ICAgICAgIGludCByYzsNCj4g ICANCj4gICAgICAgcHJpbnRrKFhFTkxPR19JTkZPICIqKiogQnVpbGRpbmcgYSBQVkggRG9t JWQgKioqXG4iLCBkLT5kb21haW5faWQpOw0KPiBAQCAtMTM4OSw2ICsxMzk1LDE1IEBAIGlu dCBfX2luaXQgZG9tMF9jb25zdHJ1Y3RfcHZoKGNvbnN0IHN0cnUNCj4gICANCj4gICAgICAg aW9tbXVfaHdkb21faW5pdChkKTsNCj4gICANCj4gKyAgICBucl9vcmlnX2U4MjAgPSBkLT5h cmNoLm5yX2U4MjA7DQo+ICsgICAgb3JpZ19lODIwID0geHZtYWxsb2NfYXJyYXkoc3RydWN0 IGU4MjBlbnRyeSwgbnJfb3JpZ19lODIwKTsNCj4gKyAgICBpZiAoICFvcmlnX2U4MjAgKQ0K PiArICAgIHsNCj4gKyAgICAgICAgcHJpbnRrKCJObyBtZW1vcnkgZm9yIGNvcHkgb2YgRTgy MCBtYXAgKCV1IGVudHJpZXMpXG4iLCBucl9vcmlnX2U4MjApOw0KPiArICAgICAgICByZXR1 cm4gLUVOT01FTTsNCj4gKyAgICB9DQo+ICsgICAgbWVtY3B5KG9yaWdfZTgyMCwgZC0+YXJj aC5lODIwLCBucl9vcmlnX2U4MjAgKiBzaXplb2YoKm9yaWdfZTgyMCkpOw0KPiArDQoNCkkg ZG9uJ3Qga25vdyBpZiB0aGF0IG1hdHRlcnMgbXVjaCwgYnV0IGlmIGFueXRoaW5nIGFmdGVy IA0KKHB2aF9wbGFjZV9rZXJuZWwsIHB2aF9wbGFjZV9hY3BpLCAuLi4pIGZhaWxzLCB3ZSBs ZWFrIG9yaWdfZTgyMC4NCg0KPiAgICAgICByYyA9IHB2aF9wbGFjZV9rZXJuZWwoYmQsICZl bGYsICZlbnRyeSk7DQo+ICAgICAgIGlmICggcmMgKQ0KPiAgICAgICB7DQo+IEBAIC0xMzk2 LDEzICsxNDExLDE1IEBAIGludCBfX2luaXQgZG9tMF9jb25zdHJ1Y3RfcHZoKGNvbnN0IHN0 cnUNCj4gICAgICAgICAgIHJldHVybiByYzsNCj4gICAgICAgfQ0KPiAgIA0KPiAtICAgIHJj ID0gcHZoX3BvcHVsYXRlX3AybShkKTsNCj4gKyAgICByYyA9IHB2aF9wb3B1bGF0ZV9wMm0o ZCwgb3JpZ19lODIwLCBucl9vcmlnX2U4MjApOw0KPiAgICAgICBpZiAoIHJjICkNCj4gICAg ICAgew0KPiAgICAgICAgICAgcHJpbnRrKCJGYWlsZWQgdG8gc2V0dXAgRG9tMCBwaHlzaWNh bCBtZW1vcnkgbWFwXG4iKTsNCj4gICAgICAgICAgIHJldHVybiByYzsNCj4gICAgICAgfQ0K PiAgIA0KPiArICAgIHh2ZnJlZShvcmlnX2U4MjApOw0KPiArDQo+ICAgICAgIHJjID0gcHZo X2xvYWRfa2VybmVsKGJkLCAmZWxmLCAmc3RhcnRfaW5mbyk7DQo+ICAgICAgIGlmICggcmMg KQ0KPiAgICAgICB7DQoNCg== --------------X31SnU5nEI9RxwotPhiFAi5l-- --------------Hs2EcrPLcMbZOhxY0WD1eWMb 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+p0QLLz9AFAmrN1mkFAwAAAAAACgkQZg+p0QLLz9A7 lwv+PrU33hKzJ9R+5YCBiHJTe4KIGkppG1ESmNnB7l3DUyKRbTMAme2qafcjx1jmckCS37JDVkXR FYBLZPpmUxh8TQ/P9B3JAExqf1v6u4mA9HVpHlWiYA/UAGgKpLtvY1GIxeehBhb3AgE/hUq4svBU iKUuaIho3CvQL+r+ejE7UlC5U6uiFEeEAECO//iwdMCj3Ay017NCbbKrr7AkbTFc0UmtDNKyo4dP 13nb2Vv9PUJTj2IBsL6acxCYaoLDLtFLyEwkC936wk7NHNr16Dv4w+KogNMPwjVNObz46JlIca2k r3U2IbLnTKXWA7pu1SpKg5eJYLB/mgtfDV+DalNjZrHYdAZD1bdmFK9UdXcOvZYDJ3ZBTdz52/Bm P7aL+Tn0Tsj96X7IIO67cVbG6E+xN9dPNNDjeI0K8FZoY3PdnekMLThSvN9ZTdUL8jwRYniYe5XW fseN5Q2t54gXtGmW6UH2n6kacpRaN3n/uMXpUt93B9+7d3Pb1t91cCt4pTHj =M6Ku -----END PGP SIGNATURE----- --------------Hs2EcrPLcMbZOhxY0WD1eWMb-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 07:29:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 07:29:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446697.1662795 (Exim 4.92) (envelope-from ) id 1xGWx0-0004Qj-Gc; Tue, 13 Oct 2026 07:29:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446697.1662795; Tue, 13 Oct 2026 07: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 1xGWx0-0004Qc-DO; Tue, 13 Oct 2026 07:29:30 +0000 Received: by outflank-mailman (input) for mailman id 1446697; Tue, 13 Oct 2026 07:29:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGWwy-0004QW-Nl for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 07:29:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGWwt-00EKeT-0j for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:29:28 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdddcf-2eae-0a2a0a5409dd-0a2a4508a952-16 for ; Tue, 13 Oct 2026 09:29:22 +0200 Received: from [52.101.84.73] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdddd2-f659-0a2a45080019-3465544935a7-3 for ; Tue, 13 Oct 2026 09:29:22 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by AS8PR03MB10083.eurprd03.prod.outlook.com (2603:10a6:20b:62a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 07:29:20 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.011; Tue, 13 Oct 2026 07: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=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=PauyRwQhF8JveXxIhaORRZnJMBMjoc+Gw5d5PBuXRyZJN3czVRptxOLLaxiHHpxcohj2dpVkJ9YIl4E7pgKVJdiw+vyWvIN92fjo6/MBc4TH7d6/qR/0OqGacVutF2oaJ16Wyh/C2oT+vJWgNJT3MQPghnyY5lMimsH9tR9akFLlIC/rcXm57Rkt23w8YOx1DoTPUBsGDiKjSPKd4Mj3Z616e1wIgESONA70oqvi1oG9rR2+yH3/kLTVEUfdA1jhmGddGO4cByMvuatZ2pdQ+1RfuK+kUn6p+2juX+I5EzVUKhQ0bmkeLBAt7zmAW8KyukMySI46MnZm9fI2bhUwLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ICvgrGM4OVsuwr7WIa2lr6J+OXZco05iJnrNESNsDjk=; b=iMntE/QcnlUjjz1HLGQ1nZsxMa2QaLpi2loHTVXPwNyFd9tHDbuSoQJelSTwBJmOD0qAXycNjYigXs7eYDoRq+m8TBkkAL/OfSaPKvr9s/oU4JP2yO7sLCrUYNisZY4hqE3XyUjtTD+ovWY/zJMufVUcABN9D5TaiGcrbdPju13faGuu6A5OrJCuyUjYq8R/sMumhIaL/VT8cJAiUUf3NxfWKKpf61zMC5VbVSl3bcrs3VHmAhKpU0FM8hVgm16mRUMzG3mP/2j7bYGgBeUNzc1ohgIA00LWOZOSU1jCktVJqDQT89RO/JYREByav4Vb2s2IrRzi7sH1eByANY0Jfg== 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=ICvgrGM4OVsuwr7WIa2lr6J+OXZco05iJnrNESNsDjk=; b=mEeeZNgH0GJaSjzUUtpcOCO+Qwx0a8C8vzpdi3BLjUXWLp9Hc5zecuTZ/9M6M3FLMHVqSzsydLs2XgZK2cA7E8g3pyh0BQi7R3rnjmCBtFBenuUaAlWKY8kTLI7WjUFVEPoA4huNaNYn7RlDM3PpnzB+ZsJgoX0BLG6cSxzd6LXVqNdQ9RSndowOPhB24ZW2GrRsDrpSmSQvJ8QlVt8bTD4lkngkHEusv7pTwVpGpLxz4loSHrjayQESNJL1wZE4F7OUgSLbYY4gSPx6saRserLRik+izHu/9Edh4cvX6bFWQOtJ9VnatVDOCHmm4MjJCviS/XJHqkPz7WVkYmx2xw== From: Dmytro Prokopchuk1 To: Jan Beulich , Nicola Vetrini CC: "xen-devel@lists.xenproject.org" , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation Thread-Topic: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation Thread-Index: AQHdVPs3la7Yb/mPXkSleujSDB++zbb1XiyAgAQkOoCAAZzAAA== Date: Tue, 13 Oct 2026 07:29:20 +0000 Message-ID: <0836fc6d-e2e7-4977-a0ec-c66671b75a62@epam.com> References: <5b5cccc8bbbc4c87fc99427eb4c1c413@bugseng.com> <96319798-7cf6-4905-9b1b-37bb6a41bdcd@suse.com> In-Reply-To: <96319798-7cf6-4905-9b1b-37bb6a41bdcd@suse.com> Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|AS8PR03MB10083:EE_ x-ms-office365-filtering-correlation-id: 8c630920-2dc0-482b-cf90-08df28fbb27b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|42112799006|1800799024|23010399003|4143699003|11063799006|38070700021|56012099006|18002099003|22082099003|6133799003|260925021311599003|260925021911599003|260925022911599003|261009223027099003|4133799003|10067099003; x-microsoft-antispam-message-info: QjyqzuZNK4afMnfOt6SUCHa9gRRQM5BRk5iDiLb+BlLPmN3+wsEPJUkuWx2OChnOmETBsOVJWzoTalEdCUkd/kjrCQLbYTFcsP9EnzakKrRV0vF2enThjNKSNZwX/hnW0K+oFhReN9nEB1GiZzvc9GjNXZg/6QgtNNtvngD4iYrVvAGD2CTp9KUdCj0RNDcEai5g7ogF+zzxSrZWEjapCZ4AG7zlGyUFG8XbfJO9HNxEwuYrpWVVEo9brzIa9Z31fB8HjRGjzDEj6ql+PXQiBoSlr1PiGkAgxVD8g29mYAUALJXryDgJSV0Zt5620PKrGJgFpcmT/7pyvjClo+ycwo5B+biCNVvilVdNCTwfXt/VNEF9NqL3gGT6V5OYG5Vyp/jtnPwQHiIvfnIxdhClpqI54P5a89SHXP8f+i/BuYROIZmv9jroBY7S8Esk89MlMQ0fPSH+mIp4pkj+BFtm0RBGJkJeLfxUa9sAU/J/m8y6aWOiAR4COFyLViNMH5k03LkpozfLnXlOd8aMTrbpn8Grge9EIckFRbXBwx8b8Gz7kq97l51il8c7Agg2u337YkspY3TWC4hK2crraqEHuUbbsxZ/7vfzyOo8S5kgjEyE2NorYoKz1byNrVw00S42pG1QkPnxVJbiXeMCld/5Mge+06DpeVXs2ck26yC9iTc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(42112799006)(1800799024)(23010399003)(4143699003)(11063799006)(38070700021)(56012099006)(18002099003)(22082099003)(6133799003)(260925021311599003)(260925021911599003)(260925022911599003)(261009223027099003)(4133799003)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YkhWZjM3ZXdjVHB4eTlKbVphSkxMRmszaS96K0I1ZFcyQlRtZllLM3JlVi9x?= =?utf-8?B?MnVyNzJwSjJtdXhGc214MjZjRTdzL3NDVHBDdlJqcmNqNlRzQ05paVhHM1dP?= =?utf-8?B?ek93Y0hITzBiV0JXbitYMjh4ME8rLzNNWWo0dmZnSGhLbWJMemJ1RHovc1Ez?= =?utf-8?B?NVB5ZGdySGx0cFNrV3oyUlVHNEVXdDhGUzk4WTNLSWN2d25IbWhVQUxoSWhE?= =?utf-8?B?L1RXM2dmMmh2V3dDRWpDbWgvSGpNa2h2L3p4dGRBaWxVelJaRnJGbjhGeXM2?= =?utf-8?B?WDhaSXlqTXFwQVNKcGZKUDdwNjNkUm9BWEk2VFVLRlpaOFBhcnNSeUdmWHlx?= =?utf-8?B?bmJSOEoyR3NpRkloU2tadjhObUh1d1BYOEp4TTJiR3pPUFlnR2RjUHFjT2N1?= =?utf-8?B?aWZNSEtnUG1vUmZVbWd1Z3d3Zksxd1kzc2RXVnNxbEJ1THNxZlBFOUx6VXJR?= =?utf-8?B?b09NcitRSGFUNGlOTWd0Vk8wY09wL2ltRXc2OWQ3L2FlbEhhTG9Zd21UVit6?= =?utf-8?B?ZzBEdzFxNXN2OTZKcjhlcHBwR1draWlzamcwUmQ5SVpPem5rd3R1bTZ0UTBU?= =?utf-8?B?enV1cDBuMTltSWRBNXpLeTRjQjEzRFc0RURpbDlBeHREaHI4VlBqRmJvV3hD?= =?utf-8?B?U1JKOE42N05PRVdGdjd3WEZQV1lKU0lQamxPWjF2ZEtaa2w5K0Z0cFBRcy9l?= =?utf-8?B?MG00U2dUOUxDbDhCVWlqZ2hreUhVckFmWTVWTnhWM0dSMmR3b1NNb2tUWERN?= =?utf-8?B?RTZjY0VaYmpwb25laXg3My9PWDRmWWRXRElBb2lteVVrY1hiaXdpMnJhSm05?= =?utf-8?B?TGl5Znl5Y3k0aUErOUw4MnFYNS9jVXJpcUpPVURDNytFRzVtYW1XWDRCNFVu?= =?utf-8?B?NlllMmx5MXJ2eFhvUGs4aUpYUEVYNVc5QXBZVGZ1Sjd3dG5razZnMzljMkl4?= =?utf-8?B?aUtQc0hLQTByUVpVbFdjUStvaExIbDYvVXEvMnkvVyswVSsvVFJtU0VPQUJL?= =?utf-8?B?N1ZHbSs5MDNmM1dLNmw5bFE1QTBzdDNFOWJlRS9acktpbU9qbVc4TmNUZnlz?= =?utf-8?B?QlhDejI1UGdlc1M2U3VBZnFhb2IvVzFtMHVmaGd0Y1Jqb3p1cUVRTmI1cnVm?= =?utf-8?B?dVo2ZmFkL3pDNHRSVzFvclRoZzVVanIzZmFHVml1OXV3QTNYc2JrWldITEph?= =?utf-8?B?bW5EdGF6K1hSUmFITHlTR1lkcG1ielZsU05hQ3J4VEZnOHYxZW9UVEhHVlZE?= =?utf-8?B?enV3YXpleGQySUJLM0NyTzlQbjJZZ0JhUThMYStROVl0YWhUcERKVE1MVzNu?= =?utf-8?B?U2poakRSbXJ2RXV2U2VxUmdWZDdEQU9YNFV1RHNIdTNCSVh1RkhTczNZQnoy?= =?utf-8?B?WEgrMG1DTlZ0a3ZoQ0hDaVYrUGxIYmRwQ3J6RS9kUzlha0FlM3JwN3BrUGg5?= =?utf-8?B?YStOc2dHSm1NcEllZTdZcEVHVEpOVm9odW1oZ2xPQW9tYzFUWTZKVmt0dTl1?= =?utf-8?B?dUJJUXh6WmhJbzF2QXZpK1d4UzJvOHZQM0lzWWY3V1U0bEpyNHpralFibUlm?= =?utf-8?B?NVJRV2NQZFZMdnMyTlp2UzU3RXhta3krTEYwQWhMTXJ0YzA2NTAyT3lmYS9D?= =?utf-8?B?WVlQZlc2c2tWbUxVVWRhVHVERG1aaGdtQWc3bUM1K1B2NkFJVUJFOUowSS9T?= =?utf-8?B?blBJMERPMXp3RTJDOUxYeUhXSXdGdXZYWjk2SDM4czVaQ2RHcjF5YkFuVHF6?= =?utf-8?B?cXJNVWhOS3NHYXFHMGdoZThNQ2hUWXJOZ0xBbExoNkxoYmJPeG04c3crWUVi?= =?utf-8?B?TlhtaTVmSFJXSlN6WEFrNmJJM0xNZEFSamlyUlNpUkxTbFo2TUlSK1FpMkll?= =?utf-8?B?Y29mOVc0bXUzeWFQRlVqa1lPM011L2NJeEZFR0puNlFRTGptb3RBdEs1QU5l?= =?utf-8?B?V3lIaW9ON2ptakJFdEpmaGJWZHRNWk9Udll2cDhJZ044emRLdnUyQ0ZCVzhj?= =?utf-8?B?TTAzbmt4eDRnZnJQVTdTcERYSURmUmtaanFoYVd6cTBzSDBEOXB0S3FLWXk2?= =?utf-8?B?bVoxbE5OOHRsSHdDQ0FSTEczVlA2TW9ncTh5UEg1Y0dxNDlla1hJQzJiVE1G?= =?utf-8?B?eE9FQjRGK3dhUlRsTnY5WTBOa3NCUjcvbHhLejFEbXpaWHNnY2lXdkN5c1Ru?= =?utf-8?B?SVVtQVV5OVZzQVNwcDJpSmVrOUtEaUJkV0lCYUF2RTdNSExrdnZVZFVGNmJZ?= =?utf-8?B?UjNNOW4xQXBPZHdRbndNOCtHdTVNNEVSSGJ0K0hQYjlQb1NmeitkZndGZTVS?= =?utf-8?B?Nk9LNUxGV0Y1SXBXblFzRDBhUTNLdWRaQkovRm1aV0dsd2pzcmNCZ2VPYkVx?= =?utf-8?Q?rk3ebzap11xGu4a0=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <8DC2776268D83544905A49E2C8F152A2@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c630920-2dc0-482b-cf90-08df28fbb27b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 07:29:20.5697 (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: tRn5LdwwLvLPIdY97tYAqHnKGhiKHJOqHsrMm5rLmFeb71o0DLWI8bes/t8RQ+Pioitvm7O4CMSKr7y2TQRHEZkzwyG18Ym+smDs30tz5Nk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB10083 X-purgate-ID: tlsNG-c1860d/1791876562-D4B7187B-3DADA1DE/0/0 X-purgate-type: clean X-purgate-size: 3844 DQoNCk9uIDEwLzEyLzI2IDA5OjUyLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMTAuMjAy NiAxNzozNywgTmljb2xhIFZldHJpbmkgd3JvdGU6DQo+PiBPbiAyMDI2LTEwLTA1IDIwOjU2LCBE bXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+Pj4gVGhlIFIxMS4xIHNhZmUgY2FzdCBvbmx5IG1h dGNoZWQgdm9pZCBub3JldHVybiAoKikodm9pZCAqKS4gQWNjZXB0IGFueQ0KPj4+IG5vcmV0dXJu IGZ1bmN0aW9uIHBvaW50ZXIgY29udmVydGVkIHRvIGEgY29tcGF0aWJsZSBmdW5jdGlvbiBwb2lu dGVyLg0KPj4+IGNhbm9uaWNhbCgpIGNvdmVycyB0eXBlb2YgZGVzdGluYXRpb25zLCBhbmQgY29t cGF0aWJsZV9kZWVwX3VucXVhbGlmaWVkDQo+Pj4ga2VlcHMgdGhlIHBhcmFtZXRlciBhbmQgcmV0 dXJuIHR5cGVzIGFsaWduZWQuDQo+Pj4NCj4+PiBTaWduZWQtb2ZmLWJ5OiBEbXl0cm8gUHJva29w Y2h1ayA8ZG15dHJvX3Byb2tvcGNodWsxQGVwYW0uY29tPg0KPj4+IC0tLQ0KPj4+DQo+Pj4gVGhp cyBwYXRjaCB0cmllcyB0byBjb3ZlciBib3RoIG9mIHRoZXNlOg0KPj4+DQo+Pj4gMS4gZWNsYWly OiB3aWRlbiBSMTEuMSBub3JldHVybiBjYXN0IGRldmlhdGlvbg0KPj4+IGh0dHBzOi8vcGF0Y2hl dy5vcmcvWGVuL2M2NjMyZGQ4MDVhMTE5YWNhNTRiOWQxYWUyZWVhNjhlZjljMTMzNGMuMTc5MDY3 NDM1OC5naXQuZG15dHJvLl81RnByb2tvcGNodWsxQGVwYW0uY29tLw0KPj4+DQo+Pj4gMi4gRWNs YWlyOiByZWxheCAibm9yZXR1cm4iIGZ1bmN0aW9uLXBvaW50ZXIgY29udmVyc2lvbiBkZXZpYXRp b24NCj4+PiBodHRwczovL3BhdGNoZXcub3JnL1hlbi82ZDIxMmQ2MC01YzBiLTQ5MDktOTk2ZC01 ZDZhNDkwNmI3ZTFAc3VzZS5jb20vNGNjYTU4YjYtYjU1NS00MDY0LWFhMjYtNTIwNGRjNGI5OWNj QHN1c2UuY29tLw0KPj4+DQo+Pj4gVGVzdCBDSSBwaXBlbGluZToNCj4+PiBodHRwczovL2dpdGxh Yi5jb20veGVuLXByb2plY3QvcGVvcGxlL2RpbWFwcmtwNGsveGVuLy0vcGlwZWxpbmVzLzI5MTQ4 MDI2NjcNCj4+Pg0KPj4+IFRoZSBvbmx5IG9uZSBSdWxlMTEuMSB2aW9sYXRpb24gcmVtYWlucywg d2hpY2ggaXMgY292ZXJlZCBieSB0aGlzIEphbidzDQo+Pj4gcGF0Y2g6DQo+Pj4geDg2L2tleGVj OiBhZGRyZXNzIE1pc3JhIHJ1bGUgMTEuMSB2aW9sYXRpb24gaW4gbWFjaGluZV9rZXhlY19sb2Fk KCkNCj4+Pg0KPj4NCj4+IFRoZSBjaGFuZ2UgaXRzZWxmIGlzIGZpbmUsIGJ1dCB0aGUgYXNwZWN0 IEknbSBjb25jZXJuZWQgd2l0aCBpcyB0aGUNCj4+IGZvbGxvd2luZzogaWYgeW91IGhhdmUgYSBm dW5jdGlvbiBtYXJrZWQgbm9yZXR1cm4sIHRoZSBjb21waWxlciBpcw0KPj4gZW50aXRsZWQgdG8N Cj4+IGVzc2VudGlhbGx5IHJlbW92ZSBhbnkgY29kZSBmb2xsb3dpbmcgaXQsIHNvIGluIHByaW5j aXBsZSB0aGlzIGNvdWxkIGJlDQo+PiB0aGUgY2FzZSBhbHNvIHdoZW4gaW52b2tpbmcgYSBmdW5j dGlvbiBwb2ludGVyIChpLmUuIHRoZSBjb21waWxlciBoYXMgbm8NCj4+IG9ibGlnYXRpb24gdG8g cmV0YWluIGNvZGUgYWZ0ZXIgYSBjYWxsIHRvIGEgZnVuY3Rpb24gcG9pbnRlciB0aGF0IGlzDQo+ PiBhY3R1YWxseSBhIG5vcmV0dXJuIGZ1bmN0aW9uKS4gV2hpbGUgdGhpcyBpbiBwcmFjdGljZSBt YXkgbm90IGhhcHBlbg0KPj4gb2Z0ZW4gKGUuZy4sIHRoZSBhbmFseXNpcyBkb25lIGJ5IGEgY29t cGlsZXIgaXMgcHJvYmFibHkgdG9vIHNoYWxsb3cgdG8NCj4+IGFjdHVhbGx5IGluZmVyIHBhdGhz IHdoZXJlIHRoZSBmdW5jdGlvbiBwb2ludGVyIGlzIG9ubHkgZXZlciBhc3NpZ25lZCB0bw0KPj4g bm9yZXR1cm4gZnVuY3Rpb25zIHdoZW4gaXQgaXMgY2FsbGVkKSwgaXQgaXMgc3RpbGwgbm90IGNv bXBsZXRlbHkgdHJ1ZQ0KPj4gdG8gc2F5IHRoYXQgdGhlIGJlaGF2aW9yIGlzIG5vdCBhbHRlcmVk IGJ5IGNhc3RpbmcgYXdheSBub3JldHVybi4NCj4NCj4gV2l0aCAiYmVoYXZpb3IiIGhlcmUgeW91 IG1lYW4gdGhhdCBvZiB0aGUgY29tcGlsZXI/IEJlY2F1c2UgWGVuJ3MgYmVoYXZpb3INCj4gd29u J3QgY2hhbmdlIGlmIHRoZSBjb2RlIGZvbGxvd2luZyBzdWNoIGFuIGluZGlyZWN0IGNhbGwgaXNu J3QgZWxpbWluYXRlZC4NCj4gSXQgd2lsbCAianVzdCIgYmUgdW5yZWFjaGFibGUgY29kZSB0aGVu Lg0KPg0KPiBUaGF0IHNhaWQsIC4uLg0KPg0KPj4gSSBoYXZlDQo+PiBnaXZlbiBpbiBbMV0gbXkg Ui1ieSB0byB0aGUgcHJldmlvdXMgZm9ybSBvZiB0aGlzIGRldmlhdGlvbiwgYnV0IEkNCj4+IHJl YWxpemUgdGhhdCB0aGlzIGFzcGVjdCBzaG91bGQgYmUgbWVudGlvbmVkLiBUaGlzIGlzIG9mIGNv dXJzZQ0KPj4gc3VwcG9ydGVkIGJ5IHRlc3RpbmcgYW5kIGNvZGUgY292ZXJhZ2UgZXZpZGVuY2Ug dGhhdCB0aGUgYmVoYXZpb3IgaXMNCj4+IGluZGVlZCB0aGUgc2FtZSwgb3IgYSBzdWl0YWJsZSBn dWFyYW50ZWUgZnJvbSB0aGUgY29tcGlsZXIgdmVuZG9yIHRoYXQNCj4+IHRoZSBiZWhhdmlvciBu ZXZlciBkaXZlcmdlcy4NCj4NCj4gLi4uIG1ha2luZyB0aGlzIGV4cGxpY2l0IGluIHRoZSBwYXRj aCBhbmQvb3IgZGV2aWF0aW9uIGRlc2NyaXB0aW9uIGlzIG9mDQo+IGNvdXJzZSBub3QgZ29pbmcg dG8gaHVydC4NCj4NCj4gSmFuDQoNCkhpIE5pY29sYSwgSmFuLA0KDQpUaGFuayB5b3UgZm9yIHRo ZSByZXZpZXcuDQoNCkluIHRoZSBuZXh0IHZlcnNpb24gSSB3aWxsIHVwZGF0ZSB0aGUgZGV2aWF0 aW9uIHRleHQuIFRoZSBFQ0xBSVIncw0KY29uZmlndXJhdGlvbiBzdGF5cyB1bmNoYW5nZWQuDQoN CkJSLCBEbXl0cm8NCg== From xen-devel-bounces@lists.xenproject.org Tue Oct 13 07:52:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 07:52:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446708.1662805 (Exim 4.92) (envelope-from ) id 1xGXJ2-0000Qy-AO; Tue, 13 Oct 2026 07:52:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446708.1662805; Tue, 13 Oct 2026 07:52: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 1xGXJ2-0000Qr-6a; Tue, 13 Oct 2026 07:52:16 +0000 Received: by outflank-mailman (input) for mailman id 1446708; Tue, 13 Oct 2026 07:52:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGXJ1-0000Ql-0E for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 07:52:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGXIz-00H3gi-QA for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:52:13 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acde322-2eae-0a2a0a5409dd-0a2a4509adc6-44 for ; Tue, 13 Oct 2026 09:52:13 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acde32d-be1a-0a2a45090019-d155802be491-3 for ; Tue, 13 Oct 2026 09:52:13 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a17baef589so21528735e9.0 for ; Tue, 13 Oct 2026 00:52: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-4a19f249692sm275398095e9.3.2026.10.13.00.52.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 00:52: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=1791877933; x=1792482733; 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=+gI9OG+0/oduLbqJDOQ/NiHLm3Z/shBvQAtSvRPnL9c=; b=T2bW8+d5JGlJlM1FkXVYwvKI7IPaNM3iwS2Xefru0gNYxeTFeaV2k4J6nPcmsQ4dAt y06yBtsn1rMOYrVv9cKf/lxLO7qZVNVuE7O8ugkTyFeBEOKUmuZntSCJ1Jm6CpS48/8e fc4eR7tiAIc9xcu0uM6e9Ld7Wb45y8wjMI3bLWcEFQmit6Gqw8gbbJpvclKlwrKJMl81 KaqUSpoiiHw+VmikEz+tRz8xe31H36qkxk1Sxu4bzu+rzmDq+wu4Cdz1i8LZXAJDS8mL pBpRJKYtMUUFu7h9N+HWEX2+YmJPHjTmTBbiaKjlAAX838IXUl8WbPuMuWMzdoGeo+Lq ic2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791877933; x=1792482733; 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=+gI9OG+0/oduLbqJDOQ/NiHLm3Z/shBvQAtSvRPnL9c=; b=vfxskmBGn8d3z7nza686kLcp4RFQOFlDkoamyctCuaEpZd/V4DWYVQWh7XbsXAEjxI FvT545a1PVbu1mKHyhUDFLpGqxPQxe+yc+BXpktBeJFqj9QzLyQceofIHd5tN2X1k67S fJqLvgTfAObx2kxegR3h0Ww3QKKmqtd8ylv/wqMcutMRavwGFb4ee2Iybi8grHYYCq4G zacxkJh5BWsWWK/cf/eXFz1aYgesNAiv/ejA3mhpHXgI9MBbTmhmEdmJO+1kQ3u84nMs Yrc0F6uN4xWX/ofcGSXM2TntuZBMBXFm9MrzeRB/ENjIOoYzLUDsALJmhFxk2Mje3Op5 jxaQ== X-Forwarded-Encrypted: i=1; AKwUvByDZJli4Pgv7w7Clg0h7dKxR+oFwsvAH7N6kwATgK9MnoykzdbiGi3BQ7QQupYi72+KJeNaGjdSI9M=@lists.xenproject.org X-Gm-Message-State: AFq9FYIw7zg1Mvh+ArWby7zdbiMEHUmZPtVZEXj7ASm6/ILk6jJxkpKb B3Ykj5+wOzgPJD+WOP49rgJZnf9iLLEkgX8LWsGumrQMkFCsi0FyIMGY2PzqG6uqUw== X-Gm-Gg: AYBFou1/j7gSfQ4P0LPyEP+s947IMmSIQYIWw/5BYZtcOH8FM1edWmmDZTMZVBj1ef/ ESbCR6sJSULdBOGKwb6ayNaDwsbXa5ig7XxTtlY+9phTkpWmfKBUTj25mwT+UP0XInaemZUi+6h WtKB8OIgLzQvtQYCfvvUDSJoDsuVK0gIgiAnYiemeH/V1Ha3fEiMA8h+cIeUn2xbNOAkh0nOX19 vBeCspXRodL64ASScjMfTlNfyt9uSTRarAwkhl+DFx/vjdfqn8B1wc4XUGRLJ24yS7KGPANpSWs bhW2OpVGhdZnb5R1XU+Uf8R6cOuPdPcoD15kUGou8Kk04iixO205VCBrDAeyOvTxs2SnBK2Eaxx y6eRWRgpKEG6/k4Uzc/+0giDbpeFDmawEEMooGdA/xGV0ScTxlMMSc1j365iRRQn5zsZ7qp+3wr zNavSOHP2v0wbJfYROfT0rZOkJRYWsUBcy6hTXqkA2diZX4m8VeWOQClgWidbv2pb51Fsn1Ph4N cHSLT/UcHkPtrZ37sWuG/540VvDsSsgEzWcVfpviuXo+1HWU40S7m0hGwq+Y7HH0rDGewxsDw== X-Received: by 2002:a05:600c:3f0c:b0:4a1:6517:ccf1 with SMTP id 5b1f17b1804b1-4a18e47a844mr242392065e9.9.1791877933077; Tue, 13 Oct 2026 00:52:13 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 09:52:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , 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-bad1c0/1791877933-BD0CD034-B2FCA56B/10/78276251493 X-purgate-type: spam X-purgate-size: 1025 On 12.10.2026 22:49, Dmytro Prokopchuk1 wrote: > --- /dev/null > +++ b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh You neatly use dashes in the new file's name here. Is there a reason ... > @@ -0,0 +1,20 @@ > +#!/bin/bash > + > +# Hide every xen-syms linking pass except LAST_LINKING_PASS. > +# The pass list is the foreach in xen/scripts/Makefile.link. > + > +set -e > + > +cd "$(dirname "$0")" > +arch=$(echo "${XEN_TARGET_ARCH}" | sed -e 's/x86.*/x86/' -e 's/arm.*/arm/') > +last=$(sed -n 's/^LAST_LINKING_PASS *:= *\([0-9]\).*/\1/p' \ > + "../../../xen/arch/${arch}/Makefile" | head -n 1) > +passes=$(sed -n 's/.*foreach n,\([0-9 ]*\).*/\1/p' \ > + ../../../xen/scripts/Makefile.link | head -n 1) > +test -n "${last}" > +test -n "${passes}" > +hidden=$(printf '%s' "${passes}" | tr -d " ${last}") > + > +printf '%s\n' \ > + "-file_tag+={xen_syms_tmp, \"^xen/\\\\.xen-syms\\\\.[${hidden}]\$\"}" \ > + >xen_syms_passes.ecl ... underscores are used here? Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 07:56:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 07:56:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446713.1662813 (Exim 4.92) (envelope-from ) id 1xGXNA-0000x7-Pl; Tue, 13 Oct 2026 07:56:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446713.1662813; Tue, 13 Oct 2026 07:56: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 1xGXNA-0000x0-MX; Tue, 13 Oct 2026 07:56:32 +0000 Received: by outflank-mailman (input) for mailman id 1446713; Tue, 13 Oct 2026 07:56:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGXN8-0000wu-Of for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 07:56:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGXN6-0013MA-GO for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:56:28 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acde41b-8faa-0a2a0a5109dd-0a2a4508eda8-44 for ; Tue, 13 Oct 2026 09:56:28 +0200 Received: from [40.107.130.97] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acde42b-f659-0a2a45080019-286b8261389f-3 for ; Tue, 13 Oct 2026 09:56:28 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by AS8PR03MB6709.eurprd03.prod.outlook.com (2603:10a6:20b:290::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 07:56:25 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.011; Tue, 13 Oct 2026 07:56: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=oLzn74/6tgj+8Txg9SD0IPrdo8+LalZnsV3JSVun+PyEAjdhQSlgL2MVXnNAzJbzQl0GXwGXlcyBxQjZI1QujQZj4BBhAwebhY7oJkndb/hqLTHf+Wmuqv2iMz+F6vmLbYRb7XG248eIDVNKtFwDVKSYGvPkHWu7kC7/MJo1GiRWBAsj1gXAL074fdEP4kd+iHIN04Lx3zZnAXs5aX2rHV5vABtOwTRkfJgcbMIT9zQsdXPTZ2NJRQgs/08Q+Etvj9gdvmji7wQB/NCnj7NxXpI95VwtTgzylK3fWHBXSKToGSkxrrFNvSuysQ12dJfaTWYg4HUUwqS2ZKzKKclUCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xMYMA/KwPHjEVJ8bC31LLOq6cVzWd+H96Cfq1RBleIs=; b=yALR5k4lExwFvA46Hyc7VELWGMeYp5JOejcoJCXItM40bYh3reM3Tdnni3NBLFrvMRIHVzEorHc631oOvZutvj0gVnW3yyjIHN+diqZHcrAMKg4i/7QoVsgSXTXlPzxdSO5e/WIHwY4FpsbQ6zo/3JrWqJSaViYcrB3/s5C2BTicdXPpDlFfetl12CDvZqohC5utTMMNXJQPlW6GbSsJerLgjpCSdddWegconi6mbIhcty6Xtxxgli2zqN6JOBSwYq4SFIIAsT9mfmtRBR2tG0IZ1EnaW+pUm8ZlyHchcFydqdX4Zg0hK+P0TkgJrjUQLQgFWx6sXm+fyRseieO6wQ== 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=xMYMA/KwPHjEVJ8bC31LLOq6cVzWd+H96Cfq1RBleIs=; b=kwsxzXIP14YxyINlGXItNEdKYERjVQVeU/xtg4rMlPQb6MbRka7Yl9Jx0vR+rkVEGhtvmOh0K3u/R0R6FLcjvp90YPXFhKntuXLVtqXdbn2f/wocI1FjAgrDSHT9WY/NXTSPRUl7ES/bwD7lNfq+kFvvoY0f0lFdF47QbEfLvU3OZi9w4Br6PLnDla91KWHsmtNMPxMb02eOjksa7qWvkDyeX60/IkazrvrXF5j0IyFrst8SnVIfHMPjVZKRquEoibpJO7SNNhbc44q0An/IKCOdGz2Tvc6Te6hu+wCxPWUgOwPSBzP5KaaDWNQytBv2Fr3X089ix2Q2nKHbwjiGOQ== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: [PATCH v2] automation/eclair: generalize the noreturn function-pointer deviation Thread-Topic: [PATCH v2] automation/eclair: generalize the noreturn function-pointer deviation Thread-Index: AQHdWuhYpZfkS0sLoEKj8O8bb8Y05w== Date: Tue, 13 Oct 2026 07:56:25 +0000 Message-ID: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|AS8PR03MB6709:EE_ x-ms-office365-filtering-correlation-id: 2553713c-917e-4de6-1d11-08df28ff7acc x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|42112799006|366016|23010399003|7416014|376014|10067099003|18002099003|260925022911599003|260925021911599003|260925021311599003|3023799007|11063799006|261009223027099003|38070700021|56012099006; x-microsoft-antispam-message-info: S1c8guNKyFYBDR+7jRGhnkyHqaxbHOaLFDJqFBOWRwnffXtpjO+jNBD3AHCLDxkKqXRcTUcTQos/TiywYa9qlqY8O2LQDSlm1iTs2DHznkRp/Jb+DLcjdJhSVNNNZ00jHP+nQV1MfoaHpuJBMOcnfRRD51GHS86Er+QYGVJIjT9zET3XGMi9et2eIGYcwRvHjxcmK4VxKUiYi/5NdRUxu9COHHV5Sy25QhiXufDBVKcUq727ioE6dIitEtEAXiE+GujN9J8eUJsq5juFn9nkZ19n2ABueY52dPdUnJTltrIJ4opvc4+V1ei32obx+/UVWeuEN7sAAT02icUXgL/Fl6OrhKCZ0l6wsNOtUKNO3/S6C5jotKwkWU7szlIZeNSBO/E80A9Q+eLlipD+kuVZQ2Oyg92Rg0q1rIxQAX91+4TzZ7TjsRExX1+51p3TJcXCCT0jRl/bBwkGOvVc9Ox1OXIZs5cVNkvdkv/ju/nmUm6Y785pSbfNCZ9fWcPX4mG/ncr8TBAs92kLCybLmWCE6/VBsI38jx8g1NdLTLbcEySdiy45NKcmXSEqqRQC4igLGafvkkp0aaeIgHVMHMNa1tGjxK/c8ar1khldeA9XMFUhS0821fHoYKFr9eIUn8VOWSiVJsO4t8ie1EeWnBWE79FUqs+2dSfXMaWX4AStvio= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(42112799006)(366016)(23010399003)(7416014)(376014)(10067099003)(18002099003)(260925022911599003)(260925021911599003)(260925021311599003)(3023799007)(11063799006)(261009223027099003)(38070700021)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?T2FhRjhuYkNld2x5V0llSFpSWGNrdzhUZHNIRE5uUjVTQTVBcU9hamc4TFE0?= =?utf-8?B?U01WeW9CQXlnY1pnOTJZOU1OZ2tKY3dPa0FPVk0xRHFEK05CcTlBby9URkc5?= =?utf-8?B?eDJwdG5uand0UUF0c2E3QlRIU1JFN1BycWduRzVkSlZIL1QrOHo2eklFcm9D?= =?utf-8?B?TXhEZU1GMzNhbllyWmlRV01LSEJVK01mR3NjY09wQnpWdVNCVTkwRVdWV0FP?= =?utf-8?B?clpRMEhXSy9Ra1hFSVQvTlZtS0lab01XZ0ZHVE82eFd6Tmo2TTFxSUFMVnVE?= =?utf-8?B?a0FCRFh1SmdjVkxZZW1Ycis2TGNxNldWL2ZZVzY0YXp0RzNiSEQ0c05hMDl4?= =?utf-8?B?ZmRIbVNjYmhOdHJNd0FJY3g4QlU4TUJrOFJPTVFYQk5iNlpOZkQrbHVtR0JT?= =?utf-8?B?K3JoZlA5eVZCRWFHODMxeDQ2dkltdk9ZdVdNeS9Od29XaEFnaW1qa1dCYVBL?= =?utf-8?B?d1RTZTJWMGZSUmQrL3BlSWUzN2NVaDhxZTRHbU9xOU1RY1lBMTNrczRjSjV4?= =?utf-8?B?TnhsKzZ3WVNDTmpQbjFzaVVVWE05UTEvM3U2Y0dGdEJ3eEdnZVpHc2x6QUxz?= =?utf-8?B?M3R4bncxWjVTU0F0MGg2TzVXQnFmalZNckRjZFJmNHptMGxFSjVrQ1dOUnZI?= =?utf-8?B?azZiM05ibkZaZ3JIYmZ6akFjQmZhVzl5c3BtSTR3ZFA5YjhPU28ydGNIWnpN?= =?utf-8?B?cmdyczFXQWl3TmpEbHFFaWlXcVI5TElpRWpPSUQyUGRDSENEWnEybFFwL2ZZ?= =?utf-8?B?alFiNkhmdnZXNVdqQlg5SHBtK2p4KzZxc2xESjdVU1V5cmpXQktjM3d1Z3RM?= =?utf-8?B?d0psZklhRGFnWFd3K1ExRzlnMHArem1TZ3ZVZ2VxcDAxT0VFMXpKZ0twL1hs?= =?utf-8?B?RjR6V2VWek5Fdk51TDNoOTNGNkprclMrT3VBSEFyT2toVUZTdkE3dEFXSUh0?= =?utf-8?B?dm10N2thWDBQYlhCcC80THlqTENGb2cwcjVhYjUzMDMvRklwVWJUYVg3b0hV?= =?utf-8?B?b3ViNlRIREhvWGxzTTZqT1dxZlBSQWZtcVA3MHhWdFRVMWFFVXFRT0lFbVVp?= =?utf-8?B?UDUrQ1BmNjRkelN2eWZhZkJlU04zVVNpRWFGRHBhODkyTHhIUmZQVDN5N0ZQ?= =?utf-8?B?UGpoOVpxK01ySkdISHc5S09FQ2Q0OUQrM1Ywa3hDcTNieVR0Q2h3bWMrVEIz?= =?utf-8?B?d0QrL2xjN0dZcW8zQXpnL2IzTVRCTDUvVXBTRUVnQXVES241dzVDOHRIb042?= =?utf-8?B?a1RZeE03UDlaNGpKNHlPL1g0bnB0ZG11dy9SaitMUUNqY2xKdXRmVW0xWGhK?= =?utf-8?B?MHMzQ2JuZkVoZjhreG93dnIwcG9ERThWWTRtcHJ5U1IrQlB0d3VDV1BUeDZL?= =?utf-8?B?Um9nQmZpRTBQRUt3VGNZS053cnd1eUJUQThDdmdMT3NqWStlV3FKdnMrTEI1?= =?utf-8?B?Qi93MHZZUHJMZHFSKzBjb09ZSFpESVhIRlk1b1dOaklRY1pNdzVVODhLTmEv?= =?utf-8?B?QURVSk84ZjNJL0orNlhBK29wTEpBZm9sY3lHaDNnc0M4N09WdytTeDRLZTAw?= =?utf-8?B?LzhjZmFLWXNOSlJlTitZRnpZd1RJbW5Wd2l0d2NMTk5ZemR2S3hQTGtzUUNG?= =?utf-8?B?dHozNElFNVUvR2xtZ1VQRkR2S0lGbGFrM0RoU3o1VUtYS1pyVVNDcng5VHhu?= =?utf-8?B?aXVqNXRiZ3JwSHd2N0VJdWxuSCtiZTJNUDE1aGVoZENLS3FuM0YrMEhXK04v?= =?utf-8?B?Q2QyNnJjL3FCQk5ZYjVxOXZ2VkdOMytmKzNPQWZ5UGNBUlNVTkNoQlJ3aCtn?= =?utf-8?B?OWRnT0Q3YzdrTExhb3lhbzM1Y3luQ2VhMFpFcUhPZEh3cWJRQURBY1VxaXZ6?= =?utf-8?B?VUdpT1pzSUpxMmd1ZkR5TUFncmYycFNLN240K1NHM1ViZXIrMEl3UTU2R2M0?= =?utf-8?B?TGFtUVZLdWIxazBwWDNYSnVZMERkSUswckVnclUweDBuN2pTV003ejh6bE1G?= =?utf-8?B?ckJCekZoemRaL3MwRE9aV3FGN0taNkhtdE5XWjNUYWcvMXFLQzBpeUR0d0tP?= =?utf-8?B?NFZMbG4xSCt3Um1RN1IvZ280NHJvZXVlV1RsRjg3dFltZXNORkdhMEZFMlRY?= =?utf-8?B?NThNTVlMdVlIOW9yeTBFT2pIblJkY3hLaUwvWUZ1UXJ6Rytwd3JjazVRL0lW?= =?utf-8?B?ZDJmaGdXTC9MUzFNMVViMytSa1NDdHUvN0NRczIrb0pQOW5IQTRqRVVjOHZO?= =?utf-8?B?MVdlR3NZOXpnc2h2RzVDc2tPcmprelEzMGh6ZGRWWUR2V2dUeG45SnVMRVlS?= =?utf-8?B?dGZ6MXMrVmtEcGFqSHp6OFZhSmdHQzZ5VlpBTHpoUGZkRVFKVGFqa0JmVURo?= =?utf-8?Q?eEbKpIZTQKsnIB/0=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2553713c-917e-4de6-1d11-08df28ff7acc X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 07:56:25.1655 (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: Fmd87fvHlsn1jIaFO1MoLWJ3EE1nIYu7lRYwudiRtPFt4wMFCXxLRnwnAnEm8gN4a84OgAC1FAMPmuoNP3Zr/gUU+5uIJZPTbdNfPDAPJuA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6709 X-purgate-ID: tlsNG-c1860d/1791878188-CC57487B-DF54247B/0/0 X-purgate-type: clean X-purgate-size: 6126 VGhlIFIxMS4xIHNhZmUgY2FzdCBvbmx5IG1hdGNoZWQgdm9pZCBub3JldHVybiAoKikodm9pZCAq KS4gQWNjZXB0IGFueQ0Kbm9yZXR1cm4gZnVuY3Rpb24gcG9pbnRlciBjb252ZXJ0ZWQgdG8gYSBj b21wYXRpYmxlIGZ1bmN0aW9uIHBvaW50ZXIuDQpjYW5vbmljYWwoKSBjb3ZlcnMgdHlwZW9mIGRl c3RpbmF0aW9ucywgYW5kIGNvbXBhdGlibGVfZGVlcF91bnF1YWxpZmllZA0Ka2VlcHMgdGhlIHBh cmFtZXRlciBhbmQgcmV0dXJuIHR5cGVzIGFsaWduZWQuDQoNCkRpc2NhcmRpbmcgbm9yZXR1cm4g ZG9lcyBub3QgY2hhbmdlIHRoZSBjYWxsaW5nIGNvbnZlbnRpb24uIFRoZSBmdWxsDQpyYXRpb25h bGUgaXMgaW4gZG9jcy9taXNyYS9kZXZpYXRpb25zLnJzdC4NCg0KU2lnbmVkLW9mZi1ieTogRG15 dHJvIFByb2tvcGNodWsgPGRteXRyb19wcm9rb3BjaHVrMUBlcGFtLmNvbT4NCi0tLQ0KQ0kgdGVz dCBwaXBlbGluZToNCmh0dHBzOi8vZ2l0bGFiLmNvbS94ZW4tcHJvamVjdC9wZW9wbGUvZGltYXBy a3A0ay94ZW4vLS9waXBlbGluZXMvMjk0MTM2NTI1Ng0KDQpDaGFuZ2VzIGluIHYyOg0KLSBkbyBu b3QgY2xhaW0gdGhhdCBkaXNjYXJkaW5nIG5vcmV0dXJuIGxlYXZlcyBjb21waWxlciBiZWhhdmlv ciB1bmNoYW5nZWQNCi0gd3JpdGUgdGhhdCBjb2RlIGFmdGVyIHRoZSBjYWxsIGlzIHVucmVhY2hh YmxlLCBhbmQgdGhhdCBYZW4ncyBiZWhhdmlvcg0KICBpcyB0aGUgc2FtZSAod2hldGhlciB0aGUg Y29tcGlsZXIgZGVsZXRlcyB0aGF0IGNvZGUgb3IgbGVhdmVzIGl0KQ0KDQpMaW5rIHRvIHYxOg0K aHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vZDY4YzU2NjA3NzgxYmZhODI5NzY2YWVkMzZlZWIzMWYw NjA4MGZiYy4xNzkxMjI0NjM4LmdpdC5kbXl0cm8uXzVGcHJva29wY2h1azFAZXBhbS5jb20vDQot LS0NCiBhdXRvbWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvZGV2aWF0aW9ucy5lY2wgfCAg NyArKystLS0tDQogZG9jcy9taXNyYS9kZXZpYXRpb25zLnJzdCAgICAgICAgICAgICAgICAgICAg ICAgIHwgMTAgKysrKysrLS0tLQ0KIGRvY3MvbWlzcmEvcnVsZXMucnN0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICA3ICsrKystLS0NCiAzIGZpbGVzIGNoYW5nZWQsIDEzIGluc2VydGlv bnMoKyksIDExIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEvYXV0b21hdGlvbi9lY2xhaXJf YW5hbHlzaXMvRUNMQUlSL2RldmlhdGlvbnMuZWNsIGIvYXV0b21hdGlvbi9lY2xhaXJfYW5hbHlz aXMvRUNMQUlSL2RldmlhdGlvbnMuZWNsDQppbmRleCA2Y2RiMTBhMTI5Li4yMjY3OTNmNTJlIDEw MDY0NA0KLS0tIGEvYXV0b21hdGlvbi9lY2xhaXJfYW5hbHlzaXMvRUNMQUlSL2RldmlhdGlvbnMu ZWNsDQorKysgYi9hdXRvbWF0aW9uL2VjbGFpcl9hbmFseXNpcy9FQ0xBSVIvZGV2aWF0aW9ucy5l Y2wNCkBAIC0zOTQsMTEgKzM5NCwxMCBAQCBjb25zdGFudCBleHByZXNzaW9ucyBhcmUgcmVxdWly ZWQuXCIiDQogfQ0KIC1kb2NfZW5kDQogDQotLWRvY19iZWdpbj0iVGhlIGNvbnZlcnNpb24gZnJv bSAndm9pZCBub3JldHVybiAoKikodm9pZCAqKScgdG8gJ3ZvaWQgKCopKHZvaWQgKiknIGlzIHNh ZmUNCi1iZWNhdXNlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlICdub3JldHVybicgYXR0cmlidXRlIGRv IG5vdCBhbHRlciB0aGUgY2FsbGluZyBjb252ZW50aW9uIG9yIGJlaGF2aW9yIG9mIHRoZSByZXN1 bHRpbmcgY29kZS4iDQorLWRvY19iZWdpbj0iVGhlIGNvbnZlcnNpb24gZnJvbSBhIG5vcmV0dXJu IGZ1bmN0aW9uIHBvaW50ZXIgdG8gYSBmdW5jdGlvbiBwb2ludGVyIHdpdGggYSBjb21wYXRpYmxl IHNpZ25hdHVyZSBkb2VzIG5vdCBhbHRlciB0aGUgY2FsbGluZyBjb252ZW50aW9uLiINCiAtY29u ZmlnPU1DM0EyLlIxMS4xLGNhc3RzKz17c2FmZSwNCi0gICJraW5kKGJpdGNhc3QpJiZ0byh0eXBl KHBvaW50ZXIoaW5uZXIocmV0dXJuKGJ1aWx0aW4odm9pZCkpJiZhbGxfcGFyYW0oMSwgcG9pbnRl cihidWlsdGluKHZvaWQpKSkpKSkpJiZmcm9tKGV4cHIoc2tpcCghc3ludGFjdGljKCksDQotICAg cmVmKHByb3BlcnR5KG5vcmV0dXJuKSkpKSkifSANCisgICJraW5kKGJpdGNhc3QpJiZ0byh0eXBl KGNhbm9uaWNhbChfX2Z1bmN0aW9uX3BvaW50ZXJfdHlwZXMpKSkmJmZyb20oZXhwcihza2lwKCFz eW50YWN0aWMoKSwNCisgICByZWYocHJvcGVydHkobm9yZXR1cm4pKSkpKSYmcmVsYXRpb24oY29t cGF0aWJsZV9kZWVwX3VucXVhbGlmaWVkKSJ9DQogLWRvY19lbmQNCiANCiAtZG9jX2JlZ2luPSJU aGUgY29udmVyc2lvbiBmcm9tIGEgcG9pbnRlciB0byBhbiBpbmNvbXBsZXRlIHR5cGUgdG8gdW5z aWduZWQgbG9uZyBkb2VzIG5vdCBsb3NlIGFueSBpbmZvcm1hdGlvbiwgcHJvdmlkZWQgdGhhdCB0 aGUgdGFyZ2V0IHR5cGUgaGFzIGVub3VnaCBiaXRzIHRvIHN0b3JlIGl0LiINCmRpZmYgLS1naXQg YS9kb2NzL21pc3JhL2RldmlhdGlvbnMucnN0IGIvZG9jcy9taXNyYS9kZXZpYXRpb25zLnJzdA0K aW5kZXggNmJjYzJhZGY5NS4uNDMwODExYjM5ZCAxMDA2NDQNCi0tLSBhL2RvY3MvbWlzcmEvZGV2 aWF0aW9ucy5yc3QNCisrKyBiL2RvY3MvbWlzcmEvZGV2aWF0aW9ucy5yc3QNCkBAIC0zOTIsMTAg KzM5MiwxMiBAQCBEZXZpYXRpb25zIHJlbGF0ZWQgdG8gTUlTUkEgQzoyMDEyIFJ1bGVzOg0KICAg ICAgLSBUYWdnZWQgYXMgYHNhZmVgIGZvciBFQ0xBSVIuDQogDQogICAgKiAtIFIxMS4xDQotICAg ICAtIFRoZSBjb252ZXJzaW9uIGZyb20gJ3ZvaWQgbm9yZXR1cm4gKCopKC4uLiknIHRvICd2b2lk ICgqKSguLi4pJyBpcyBzYWZlDQotICAgICAgIGJlY2F1c2UgdGhlIHNlbWFudGljcyBvZiB0aGUg J25vcmV0dXJuJyBhdHRyaWJ1dGUgZG8gbm90IGFsdGVyIHRoZSBjYWxsaW5nDQotICAgICAgIGNv bnZlbnRpb24gb3IgYmVoYXZpb3Igb2YgdGhlIHJlc3VsdGluZyBjb2RlLCBwYXJhbWV0ZXJzIGhh bmRsaW5nIHJlbWFpbg0KLSAgICAgICBjb25zaXN0ZW50Lg0KKyAgICAgLSBUaGUgY29udmVyc2lv biBmcm9tIGEgbm9yZXR1cm4gZnVuY3Rpb24gcG9pbnRlciB0byBhIGZ1bmN0aW9uIHBvaW50ZXIN CisgICAgICAgd2l0aCBhIGNvbXBhdGlibGUgc2lnbmF0dXJlIGRvZXMgbm90IGFsdGVyIHRoZSBj YWxsaW5nIGNvbnZlbnRpb24uDQorICAgICAgIFRoZSBjYWxsZWUgZG9lcyBub3QgcmV0dXJuLCBz byBjb2RlIGZvbGxvd2luZyBhIGNhbGwgdGhyb3VnaCB0aGUNCisgICAgICAgcmVzdWx0aW5nIHBv aW50ZXIgaXMgdW5yZWFjaGFibGUuIFRoZSBjb21waWxlciBtYXkgZGVsZXRlIHRoYXQNCisgICAg ICAgdW5yZWFjaGFibGUgY29kZSB3aGVuIGl0IGNhbiBzZWUgdGhlIG5vcmV0dXJuIGNhbGxlZSwg b3IgaXQgbWF5DQorICAgICAgIGxlYXZlIHRoZSBjb2RlIGluIHBsYWNlLiBYZW4ncyBiZWhhdmlv ciBpcyB0aGUgc2FtZSBpbiBlaXRoZXIgY2FzZS4NCiAgICAgIC0gVGFnZ2VkIGFzIGBzYWZlYCBm b3IgRUNMQUlSLg0KIA0KICAgICogLSBSMTEuMg0KZGlmZiAtLWdpdCBhL2RvY3MvbWlzcmEvcnVs ZXMucnN0IGIvZG9jcy9taXNyYS9ydWxlcy5yc3QNCmluZGV4IGE1OWNmMTc4MmUuLmJkMjg4YmJh MjkgMTAwNjQ0DQotLS0gYS9kb2NzL21pc3JhL3J1bGVzLnJzdA0KKysrIGIvZG9jcy9taXNyYS9y dWxlcy5yc3QNCkBAIC00MzUsOSArNDM1LDEwIEBAIG1haW50YWluZXJzIGlmIHlvdSB3YW50IHRv IHN1Z2dlc3QgYSBjaGFuZ2UuDQogICAgICAgIGFuZCBhbnkgb3RoZXIgdHlwZQ0KICAgICAgLSBB bGwgY29udmVyc2lvbnMgdG8gaW50ZWdlciB0eXBlcyBhcmUgcGVybWl0dGVkIGlmIHRoZSBkZXN0 aW5hdGlvbg0KICAgICAgICB0eXBlIGhhcyBlbm91Z2ggYml0cyB0byBob2xkIHRoZSBlbnRpcmUg dmFsdWUuIENvbnZlcnNpb25zIHRvIGJvb2wNCi0gICAgICAgYW5kIHZvaWQqIGFyZSBwZXJtaXR0 ZWQuIENvbnZlcnNpb25zIGZyb20gJ3ZvaWQgbm9yZXR1cm4gKCopKC4uLiknDQotICAgICAgIHRv ICd2b2lkICgqKSguLi4pJyBhcmUgcGVybWl0dGVkLiBDb252ZXJzaW9ucyBmcm9tIFt1bnNpZ25l ZF0gbG9uZw0KLSAgICAgICBvciAnKHZvaWQgKiknIHRvIGEgZnVuY3Rpb24gcG9pbnRlciBhcmUg cGVybWl0dGVkLg0KKyAgICAgICBhbmQgdm9pZCogYXJlIHBlcm1pdHRlZC4gQ29udmVyc2lvbnMg ZnJvbSBhIG5vcmV0dXJuIGZ1bmN0aW9uIHBvaW50ZXINCisgICAgICAgdG8gYSBmdW5jdGlvbiBw b2ludGVyIHdpdGggYSBjb21wYXRpYmxlIHNpZ25hdHVyZSBhcmUgcGVybWl0dGVkLg0KKyAgICAg ICBDb252ZXJzaW9ucyBmcm9tIFt1bnNpZ25lZF0gbG9uZyBvciAnKHZvaWQgKiknIHRvIGEgZnVu Y3Rpb24gcG9pbnRlcg0KKyAgICAgICBhcmUgcGVybWl0dGVkLg0KICAgICAgICBFeGFtcGxlOjoN CiANCiAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgZnVuY19hZGRyID0gKHVuc2lnbmVkIGxvbmcp JnNvbWVfZnVuY3Rpb247DQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Tue Oct 13 07:56:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 07:56:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446715.1662823 (Exim 4.92) (envelope-from ) id 1xGXNX-0001HV-1U; Tue, 13 Oct 2026 07:56:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446715.1662823; Tue, 13 Oct 2026 07:56: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 1xGXNW-0001HO-TT; Tue, 13 Oct 2026 07:56:54 +0000 Received: by outflank-mailman (input) for mailman id 1446715; Tue, 13 Oct 2026 07:56:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGXNV-0001FF-Ct for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 07:56:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGXNU-006tKz-G7 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:56:52 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acde43d-e002-0a2a0a5209dd-0a2a4509cf18-12 for ; Tue, 13 Oct 2026 09:56:52 +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 6acde444-be1a-0a2a45090019-d155802db904-3 for ; Tue, 13 Oct 2026 09:56:52 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a0e1b0681bso19082025e9.3 for ; Tue, 13 Oct 2026 00:56: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-48de0ac35dfsm3661870f8f.33.2026.10.13.00.56.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 00:56: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=1791878212; x=1792483012; 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=bQRzjvQmotIeLMOuxBn9grqTl/b/VFMsHTbZZ0dydQc=; b=WaWHhgiaQZJrigRdrTDkL1F3sMrPRpmdTG9ch3p/GMqvqPFoIrLfaCysn2KzeQDhyD yGJ3MtHwJ2wLwQxm0F8vOZhwvCmfJY9R8JjwU3Jp+lgMzA9nCx+iyIi4fC38RxPtx8Bp 8lwpOQphmRQ20PbQz2GqWzVvq7uSBVeclvgLeS2QuQdWwFXhcRif5BIly5czLiy5G+Xm bi9bxj5+tw4P47FzWPpE1UTAq1oMScYIa2ALhaTHUCGmSO93n1M7gv0UP41WHp+8Fsv1 O4hHAsaDiEE400UecFkpJuyeHEiMCJa4xTzSEnSNDveWoN6fKkEWqN565IP/SRMyb8F0 x9Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791878212; x=1792483012; 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=bQRzjvQmotIeLMOuxBn9grqTl/b/VFMsHTbZZ0dydQc=; b=B0e+eMPwxX8IBjdMR3HP2rCCHhI2Scc8lHm63G/fo5zafOOXrNLA+YHhPywlOtB7pj FJejAVw9lIJ2Qm77YFaKeYdn8coGtWcRs/plx5Uli5x0bNaxnoNoZBlro732zzUdGJSU In6vOIkbyqVx5ubDskw2PACwWm+S4hpDJthNIKm6hZxTAoTfKcJotEyoEfS0/rQGt63P E8ioe6CxNSUwlus1LbCQ6te5z1WJ+riiZqTRpD6/qfyQSm9jIAEdvbb7IWiOXtjSHx4V QQvz3NMCYVzqlAmjSwDdfFNS6BmstAYpTIEVNjVni7vSYMjUnH48AwZytsTbtD7FdtMz A9lw== X-Forwarded-Encrypted: i=1; AKwUvBzNGbDl1c9UebAvJ0wB6Lky7Ewdi5q2TW4qs6Syy0tlGqy8MkNWjjS/Tc7AzKx7rmifK/f7ujQcVWQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYJhUbFkvPjvM7mMNGv/08x2w0pcALPFuQNLXwNuu7nVYke4rBlY QznF/leRnCt0lV7Y9VDLxCU0SY9F8HvSPhHKtcgExzYAoRvo7isRboEoC7XUsG80OQ== X-Gm-Gg: AYBFou1zUspf6IHLLUgH1tjNeTvtFa35Up2/c1yoxlr4IgzbkdFT0AIBWEzRyuSYRbo Bn1hMHZ/80F3xYfPtz8fbEmwDc1Ygb5obXWiSOFRDWHiuFW19XX7MMD9PGCiT+WTuO9L+Jq2L8s HV5LZGJGCZzufJ6T1+zNRnHmMHHqS+FEVp/WwpTIlGLuI9PYu6niqAgAhphPwrem5CcLomj4Mtm hmiTbJiK06xxH/nCickua5PvyhV38PIfpekj3o0gD+PuwF8HNlaMQ1PGHJZ1HjCJ4h1oWLk2PMw ko1f7F3qcYdS3DJb7QyEajtYHbm4hE/UKFXy//WEaZgqLLxn2pYoEFYAqKPapUBlrVEb/2XN9Z2 4Fzgmj2TOGJ4PuhZ/6wJwayoNHRgvI3pLG9crvPDYJac+ihYElXlynlARQSCQoUccwRUSq9ycaz rf6cx/Qb+D1YdwrmY3klsqUHF/FK9W10PrnpXBFL/BSh24xB0udXdrAL3FeHpLWPJLq8KQMltQv B55xTiP2hB7HQ2ZFK8uHTxZiahLtLI/l46KTt77In7pqWT7iitDsd/RHy/SADBoV2Uw0dHB X-Received: by 2002:a05:600c:e556:10b0:4a1:93fd:8f2 with SMTP id 5b1f17b1804b1-4a193fd0a16mr115811215e9.6.1791878211874; Tue, 13 Oct 2026 00:56:51 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 09:56:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <575ec1bc-764c-4016-a584-a79e57817d9a@suse.com> <1791874666.8631fc262581453bbf619ec5b2062170.1a1340d8f0b0008d8d@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: <1791874666.8631fc262581453bbf619ec5b2062170.1a1340d8f0b0008d8d@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1791878212-BE6DA034-A1FE00F5/10/78276251493 X-purgate-type: spam X-purgate-size: 741 On 13.10.2026 08:57, Teddy Astie wrote: > Le 12/10/2026 à 10:23, Jan Beulich a écrit : >> @@ -1389,6 +1395,15 @@ int __init dom0_construct_pvh(const stru >> >> iommu_hwdom_init(d); >> >> + nr_orig_e820 = d->arch.nr_e820; >> + orig_e820 = xvmalloc_array(struct e820entry, nr_orig_e820); >> + if ( !orig_e820 ) >> + { >> + printk("No memory for copy of E820 map (%u entries)\n", nr_orig_e820); >> + return -ENOMEM; >> + } >> + memcpy(orig_e820, d->arch.e820, nr_orig_e820 * sizeof(*orig_e820)); >> + > > I don't know if that matters much, but if anything after > (pvh_place_kernel, pvh_place_acpi, ...) fails, we leak orig_e820. Yes - we're about to panic() anyway. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 08:02:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 08:02:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446734.1662836 (Exim 4.92) (envelope-from ) id 1xGXSr-0003mq-6L; Tue, 13 Oct 2026 08:02:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446734.1662836; Tue, 13 Oct 2026 08:02: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 1xGXSr-0003mj-2p; Tue, 13 Oct 2026 08:02:25 +0000 Received: by outflank-mailman (input) for mailman id 1446734; Tue, 13 Oct 2026 08:02:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGXSp-0003md-VI for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 08:02:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGXSp-007tt6-AE for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:02:23 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acde584-2eae-0a2a0a5409dd-0a2a450cd23c-42 for ; Tue, 13 Oct 2026 10:02:23 +0200 Received: from [52.101.70.90] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acde58b-f479-0a2a450c0019-3465465a9be7-3 for ; Tue, 13 Oct 2026 10:02:23 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by DU0PR03MB10185.eurprd03.prod.outlook.com (2603:10a6:10:467::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Tue, 13 Oct 2026 08:02:17 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.011; Tue, 13 Oct 2026 08:02: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=iwuNHAoOTWaZ87U75jEd5aJmljP5qoE/McafoLsoENsdi21QaX4XC3N7YHX6Mr+Hds1Tx396B94eAdQWtwF26M8uGD1zVfNLJu/hU4VfZUahMSsZyjGodcfpbJdKZa/oaXYxQ5s81NO2cUnPBrJFO3FXS7Q/8yo/e/XRx6/5BNmEfKvALnxKwNG6r1TBHTus9jy9/IR8utkoTsNrMO21fR/GYEIw9CHg2GRqVz4sn1OTg+S4EV/qcSHJLnAWZDG8KRKI9n4K+2f1xyCJO0SV6RH3YQu63L7vggW9VNpLWQTKXS/jzvSuE1HigV4SM52xwBYdUwkJz8rRcD2hbzhEUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dXrJvms2a1fUMsTZGoIsoOJgrnt9gqkfUisB09F6mIQ=; b=GYCltpehfsEOluG2AqZhcAC2eiCLJqFfDbSIV5RLrrEx/LsjKHoWMDN98wjsGF2dumw1CZYb54h430nC7Xinbf9yxeRAZL00oBoCU+wcNXrJ/wFlSU6O5wHaUn2lGYK4VNNCSa57zgs8lUk1npZgxGhqTBVto5M+P1PgRFphso8kD+caq5Z3YxCLOaL/KTQvaqWJs3PsHoR3+gaLKWUcXwk8gIxEvLupBDG6UkmIMFCw7/Lb5U4pf2dgluI+FG5ThiEOtyo4NbeGk7I4e0M12cR8Z9fWmjxCBEmc/wNXPkme4zbnUUWuuBDxYYTTKgw6gJrMTzPK9o8OlG9qo6q9Ig== 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=dXrJvms2a1fUMsTZGoIsoOJgrnt9gqkfUisB09F6mIQ=; b=Yin0wi5H262NgmGIrcoj7ME4IuXsKWpdXrHKMNlqyhT4eDCfr4kMOc0H2FvmYUvCcm629YsUtFzDnqcEgSlc7bAO2RAHfj2A3tFSatatbFajZDTIrps+MTmtw8yn47S2tQAQ666ZKpnrA/drw1GRtnZnLP4xGyB7H2DD3C5ofA/qtst/pJxBtU4HdqkdXjwj1PXCXMt3h4O1bm1No1GrAHsWoQknkpmXtkTBMPkffVh9IkIsAKwFqnC2AK8/5md3jVjtsrCBzH0DxypAtX987iOAUC0aV/RnjHvMGmpQKlvU4wFULnAAdc4ZMm98TaXcGkhdkHs2kT0UR8gQkFsjQA== From: Dmytro Prokopchuk1 To: Jan Beulich CC: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm Thread-Topic: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm Thread-Index: AQHdWose+3ny6aV1J0Gq+fH4413ZRLb7GmuAgAAC0QA= Date: Tue, 13 Oct 2026 08:02:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|DU0PR03MB10185:EE_ x-ms-office365-filtering-correlation-id: 9d1dac99-b1d1-4e26-494c-08df29004caf x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|42112799006|23010399003|1800799024|10067099003|11063799006|56012099006|5023799004|4143699003|18002099003|261009223027099003|22082099003|38070700021; x-microsoft-antispam-message-info: lQD6F1wEe5Js69Ct8PfxmkTrlBhu50+/x0PmoBWdsM1hEkPUvs88azSc5XUwuDUcs/+XTOpwY+5ROvPDqudwYdH3aRPhr+hklcHQ8AaOO3nT1pz/ErHDPHqD+9vhTWT5+DcwXqWk5o/4k9AlHELuDVKWaXCSex0FRNLThzsPX1KPXUE1Xy0AAav+OnewsEaqkU2SVbajONvwRxueB2aZJVZEr/C62lFLkaB0p/JaQDVinnsyPG9CyayPHvfcXHu90gVF+fBazYFib7uaMxRZsWj/GJGvshJz1RzEpeXcNXKbRAKvJPZQ9hs9Z6NZqhrqnq10+cXmhBFEl0z+BiB2pL3v4jEvmLky8hLQ9FcmGdePy7uuU/QLuHpsrKN1Y6AGHI+2ywp4QC1wQjUEdnCWLgbAFpIUx6EYeOhDe2vkYLpSinpPGNWiV6dm6B/81v2O7X6zTDdvCiVut0zZpjfcc+mrycJ0Fn4bS20Ei4xTmasRfn0KyHVC0N2xfKD6Rv+0XPFnYtTh3k2EwIV2XKD47TGVcI0wzV9mDS6LKiiAOlovKRW3Iqbg6hhclhmixNvKAQQFP7c/k47YdyfVh8sgEa6k5lK9FyZhWl6LAKXHVI/l1kjgX37tG7DhOf7R81JLa7+Tu+BeWIFkEwul24B/6InE0QfPYs7lUbUr7/mCKk5pRM4yQPv9Y7n4CioNrvtX8V3by/QXP6cAevvyWlc5uRC8wJ8oHRqOWG6FQ4uWjnQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(42112799006)(23010399003)(1800799024)(10067099003)(11063799006)(56012099006)(5023799004)(4143699003)(18002099003)(261009223027099003)(22082099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eEVNQmxGb0UxVWtZUXNIblhoWWFaakowSEhCdUNMSjVSRENycit3VkRFWVZn?= =?utf-8?B?YzNxcERhdTZUSWcvOWlRTllyQVJwVUp2bUNjaVd2dlZNZlQzR0ZqdG9EV0hu?= =?utf-8?B?NWx2MFZJbTBIa1J0bkN5TFpEWHhyZUZYczBtZHVBa3NwaWE2eDhaTVg2aEVI?= =?utf-8?B?dXMxMlJHOEJnb09NemRvaVkyTk1mcldUSysrUkF5L3loY01QTWRuTlF4MStq?= =?utf-8?B?TER6NTFWSkhpZXBkQW5mMjJ6d2xoeDBmQStxZHV1YjVUU2kyK3orR0tIRUw5?= =?utf-8?B?NFdNenBzSkNLZ0VPY1BTWEdwYkx4Y1pBVnU5V3pHd3hCNCtmMHJCVFJnYmZR?= =?utf-8?B?bTZ1LzBTWnUzUDVILzJseXJ2dFRFUW5DUS9EVStLTjd2ZUpZWSttL3NuTDZj?= =?utf-8?B?QUY4RWMxSEhtZlNtVFZybjRWVTBFVXVFWEYvam1JUjZ6eGlkR2R0bTRaTzVL?= =?utf-8?B?UjZ1Yk04UWRmNTRtblkrUTVNVURnUDFpM0tPY3ZQdHllajExRndMbXBsRmkr?= =?utf-8?B?emN0Y1h4eGd1VEdPd2tlTnZUQTUrZnNhelZpR21rTE51ck82MzdaMlhpbDRF?= =?utf-8?B?cjJiQXA5MUNJbGNNS3ZWOXZWZjhweXR6UnR3dWRiU3AreWVYWnVWZTlENnBS?= =?utf-8?B?SC9QT1ZHOTZxM2U5c2U2UGxBODZ0QzhEcVdwYUNSaEIxc0RYOEIwdFRCTm85?= =?utf-8?B?UGVZbEtCOW9UMmc1MlF4eGdJYktjM0pSSm9vVUVuSnR0RGgxY1B6azU1QzZj?= =?utf-8?B?d0dRaU9sbGtjYmZjWG1kWldFaDFPbitVMW54cExCdVJVTGU0QUFIZWVpU0JJ?= =?utf-8?B?MHBsUVU2ZGcrOXVqWVlOd2xCc3Uyd2Q4TWJTYkt4NDZPcDZGTlZ0VXZFY0cz?= =?utf-8?B?TC8vRU5JaUtTeFJNLzlzMFkzL25UQnVBaURnWGEwOTNDUmdXajNMNW9VS2d6?= =?utf-8?B?SkVDSjhSbWx3TVArNlBZVDZzenNJVS9PR2M5WmQ3TG1uSjlFVlpJNUhibjhN?= =?utf-8?B?T2N4VHVHUklZUUVCbnhYRmdVSkhWZVduaUdLMVc3bmQ3bVBscDFKMjNwVzll?= =?utf-8?B?VGd6eUdoL2V1WUNmeHhoSWRuV3lpbUJ1dGVPbDg3RXJpVlRDcC9SZXlCYjY5?= =?utf-8?B?amVYeXRrV0FFL29mUWU4b1ExbVBEYzlpSjJEVWxjbVRzbmJjVU1kd0NxQUFx?= =?utf-8?B?bU9MaXFpTWpSZ2VBVWVleUV6a1hBQ0NCS2hoSmorWkFrUVNpOFdsOHIvOGFv?= =?utf-8?B?MGZJaGo4b0pidTZpR3QwSzdFbkQzN1dETGgva05YU2s3eExuSkoxUHdYVlJt?= =?utf-8?B?bHh3QzFvRHdVaHBSY3pHRFJDODZ1MEplU1VqL0picXhldFBJRFVXZXZ1OThE?= =?utf-8?B?NmlYSU5sZFNyVkVFZzVkVUl1YUhlbWdsa0M2K0hEZEUzTnRLNG9jSGZVdDB0?= =?utf-8?B?OUdjU1ZMNS9TdVRIVlZoYlU4d3ZuZlM0Z3haNWlMU0tEWWRDWGxTN1pueXEy?= =?utf-8?B?M2ZJNFJGdXF0eWxGTHltdGpFbDJXSVZUTC8yS1ptOTBWbnVubmhYbEk2dDR5?= =?utf-8?B?WlBTVkg5djlvdGhnWTRONUdsdHEyaXVOUSt5UmkzQ2cwT3M3Y2xJUDI1NGtP?= =?utf-8?B?SWpuaG1IUENtMWRpazBaeUxBbkJkWUNrbXpGa21Wa3BCUzVSaHNJTG9jbStp?= =?utf-8?B?a1pyMkI4RjZJaDl2WUdTaGJVWjB3L2kvdmM3VVVvQWc5VHJOd1hyM2xoa1hJ?= =?utf-8?B?c2JNRXBYbC9ubVRWZ2YyR0lPK3VzTFdlQWpYcDJpWFlPOFNKMjFjcFE4RnM1?= =?utf-8?B?ZVhUN29jcE95NmtnTnZkZml3OXBtRTJGZ0tJd241dW5WdkxGRWltckVSdHlX?= =?utf-8?B?UllnazV5V3lkV05PSjZRa2srN2lic1I0SjE1TzVZbTB3TStCK013ZkxaZEtv?= =?utf-8?B?VmNwSkZodmZKOGlYb0NTODlUUlQvTUlQNWxWTnlqT29yekpXTUFJOHVYS1JZ?= =?utf-8?B?T1dRcU42TldPN281dlhXKzErQUpRbFFHcmxVTWQ4akRPR2lkZGY4VXBici9t?= =?utf-8?B?QXZEYW1xMXczeTZncXYzbmZDbkJkSW50ZUd5L25qUVVNbWhUbldkS20yVE0z?= =?utf-8?B?dWUrOG9MQjVOMHpGbDUwSUJudkRKeGNlNFgrWDFxYXBCYmRRNHBDOGJPT2Rq?= =?utf-8?B?NGNGdFF0SDUvMnRXTWdwZjdOL281MTZIVnVaSG4wZ3ZBaW5mOXVaNzFmUlNv?= =?utf-8?B?MjQvVCtpaVRGUVFSQkU4TVJSZ3VhMmdCTENxRnZ5ak9tZEg4WnFzSlRsdUlv?= =?utf-8?B?NUVTeGtiSUZxQTVjdjFlS0RGdmlybG1Jbk9EYzZFQkgyalpuSmtXR1QvMjlW?= =?utf-8?Q?ds8l4yXxJBt0gE64=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <5716514C834D5F49B11518E730C8E4C9@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d1dac99-b1d1-4e26-494c-08df29004caf X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 08:02:17.3162 (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: 2rvaV7etIxKG68JR697Pa3EF4/oVQp4WFdccYv5SHFQMhEwI+9pdk3N8S0o5ZfaXwHuF+5su1Jn31m8/BEiufqI/StO3XJOik5koDemCL18= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB10185 X-purgate-ID: tlsNG-d25034/1791878543-51D34A5B-C501E734/0/0 X-purgate-type: clean X-purgate-size: 1808 DQoNCk9uIDEwLzEzLzI2IDEwOjUyLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTIuMTAuMjAy NiAyMjo0OSwgRG15dHJvIFByb2tvcGNodWsxIHdyb3RlOg0KPj4gLS0tIC9kZXYvbnVsbA0KPj4g KysrIGIvYXV0b21hdGlvbi9lY2xhaXJfYW5hbHlzaXMvRUNMQUlSL2dlbmVyYXRlLXhlbi1zeW1z LXBhc3Nlcy5zaA0KPiANCj4gWW91IG5lYXRseSB1c2UgZGFzaGVzIGluIHRoZSBuZXcgZmlsZSdz IG5hbWUgaGVyZS4gSXMgdGhlcmUgYSByZWFzb24gLi4uDQo+IA0KPj4gQEAgLTAsMCArMSwyMCBA QA0KPj4gKyMhL2Jpbi9iYXNoDQo+PiArDQo+PiArIyBIaWRlIGV2ZXJ5IHhlbi1zeW1zIGxpbmtp bmcgcGFzcyBleGNlcHQgTEFTVF9MSU5LSU5HX1BBU1MuDQo+PiArIyBUaGUgcGFzcyBsaXN0IGlz IHRoZSBmb3JlYWNoIGluIHhlbi9zY3JpcHRzL01ha2VmaWxlLmxpbmsuDQo+PiArDQo+PiArc2V0 IC1lDQo+PiArDQo+PiArY2QgIiQoZGlybmFtZSAiJDAiKSINCj4+ICthcmNoPSQoZWNobyAiJHtY RU5fVEFSR0VUX0FSQ0h9IiB8IHNlZCAtZSAncy94ODYuKi94ODYvJyAtZSAncy9hcm0uKi9hcm0v JykNCj4+ICtsYXN0PSQoc2VkIC1uICdzL15MQVNUX0xJTktJTkdfUEFTUyAqOj0gKlwoWzAtOV1c KS4qL1wxL3AnIFwNCj4+ICsgICAgIi4uLy4uLy4uL3hlbi9hcmNoLyR7YXJjaH0vTWFrZWZpbGUi IHwgaGVhZCAtbiAxKQ0KPj4gK3Bhc3Nlcz0kKHNlZCAtbiAncy8uKmZvcmVhY2ggbixcKFswLTkg XSpcKS4qL1wxL3AnIFwNCj4+ICsgICAgLi4vLi4vLi4veGVuL3NjcmlwdHMvTWFrZWZpbGUubGlu ayB8IGhlYWQgLW4gMSkNCj4+ICt0ZXN0IC1uICIke2xhc3R9Ig0KPj4gK3Rlc3QgLW4gIiR7cGFz c2VzfSINCj4+ICtoaWRkZW49JChwcmludGYgJyVzJyAiJHtwYXNzZXN9IiB8IHRyIC1kICIgJHts YXN0fSIpDQo+PiArDQo+PiArcHJpbnRmICclc1xuJyBcDQo+PiArICAgICItZmlsZV90YWcrPXt4 ZW5fc3ltc190bXAsIFwiXnhlbi9cXFxcLnhlbi1zeW1zXFxcXC5bJHtoaWRkZW59XVwkXCJ9IiBc DQo+PiArICAgID54ZW5fc3ltc19wYXNzZXMuZWNsDQo+IA0KPiAuLi4gdW5kZXJzY29yZXMgYXJl IHVzZWQgaGVyZT8NCj4gDQo+IEphbg0KDQpUaGUgZ2VuZXJhdGVkIGZpbGUgZm9sbG93cyB0aGUg b3RoZXIgLmVjbCBuYW1lcyAoZS5nLiANCmxpbmtlcl9zeW1ib2xzLmVjbCkuIFRoZSBzY3JpcHQg bmFtZSBmb2xsb3dzIGdlbmVyYXRlLWxpbmtlci1zeW1ib2xzLnNoLCANCndoaWNoIGFsc28gdXNl cyBkYXNoZXMgYW5kIHdyaXRlcyBhbiAuZWNsIGZpbGUgd2l0aCB1bmRlcnNjb3Jlcy4NCg0KQlIs DQpEbXl0cm8= From xen-devel-bounces@lists.xenproject.org Tue Oct 13 08:08:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 08:08:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446741.1662844 (Exim 4.92) (envelope-from ) id 1xGXYk-0004XD-PX; Tue, 13 Oct 2026 08:08:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446741.1662844; Tue, 13 Oct 2026 08:08: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 1xGXYk-0004X6-MQ; Tue, 13 Oct 2026 08:08:30 +0000 Received: by outflank-mailman (input) for mailman id 1446741; Tue, 13 Oct 2026 08:08:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGXYj-0004X0-1s for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 08:08:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGXYh-00ETnc-RL for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:08:27 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acde6f1-e002-0a2a0a5209dd-0a2a450bb7ec-38 for ; Tue, 13 Oct 2026 10:08:27 +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 6acde6fb-b7e8-0a2a450b0019-d155dd29d5e1-3 for ; Tue, 13 Oct 2026 10:08:27 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-487049569b6so1827517f8f.1 for ; Tue, 13 Oct 2026 01:08: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-48de0aaaa05sm3283036f8f.13.2026.10.13.01.08.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 01:08: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=1791878907; x=1792483707; 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=PmYYAxqD4mSZwNf80Vz5dVtz0dj676xcDjEg1KEK44A=; b=PVEOI4tsj9xeHzdYy002C0LV1slnjyANrnh0IzFCXXkLcw8c90h4Kq2q4KIIjdblyt RMSC5eH3z8ilp2UcohKn0Lm1FgXhKGr5uYZYnWCdQuHz3qiXq11pAC5vd8SrDn+7BFuP 6nCp2vo7XHbdvxZYWwkQ45uveshq65sQL3gO2m0mxtVbxpg2VRTiWe8MWbzGJgD8ECPi vsAzU13f6gCOCLu2pU9vk5tTH4Nq8q3fZpPGReMwbXRijxj+GbJWbZAvDohMluOO2NQZ MlQwwkxo0ghBpJqa9WtI6UKYnO+8YbttGhFv5gHMU04eCnrXU1gukog3MIK50bQ33j+O niBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791878907; x=1792483707; 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=PmYYAxqD4mSZwNf80Vz5dVtz0dj676xcDjEg1KEK44A=; b=HXhIZIry3tyCcLeUDhfVDeRqIhpkkxq0ljXmEwrVh+lWYnM1hJ0fbzrs8eoB0GMNyT Jvr9YjoKiMCsDEIIZfNgdUkXU/8/XfNg/yx78j58MdYqQSr4PJmXN6JFUmKvuCwiRU4c iFuI12/KvV6u3SrvKrqvOnZJgUent4kWZrSbLg1+Vfq1hDewzOBsPACIS8wHfH1DYp2Q JiucG4nYjwA1hvC4ZT/QwPkhFzgtw1aDG4DZobe/A+j2sKk6QrB7QEp3RYOTb9mL9lSq p/C9irnRrQL9evS5dGTU9SO+5g8H1SoElscaikfYe9S7XHKLbZ095D11zNUVkW1LW70D ucFQ== X-Forwarded-Encrypted: i=1; AKwUvByzx6cfBh4uOzDCl25EKiQXEIoz7GYpWlbedcMz1JkFbid+yQzWH9ohch3BLu0Z8OxzdgkhF9CeIrA=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ7Zs7yVCgDeMyndnGctMdYTBOl7Go9bVNionYQxhdxukw8+WJg gX0NjWTssGTvVNdoD++O/YjxsTw19cC0heYPGdtS1yqN3kSM4FpVo8VL/WaYINZK/g== X-Gm-Gg: AYBFou3h2YAK7Fjcgbb61DWuc/Jb9DhxLkfuiSKaNaKWVKIOvYqvzNCBWCQWuw0O7R7 vYnbWWKlOYr5IOCh6u5Y4Ys5qky4gi/KJcnmDWse348yIalzGcRei47q5/AgBQ3uq8TFvfBUVxh lTgzrrFpBeBVz5A2FpEFi8YHzEiZCaZuCBT0EV+8DE5wTK5LGuYUTOfj4aL0LhSZQSH3H/n3zy2 E01lqDEeQ9VBpgscYml1+nvWD5nRGRtTAkidTieO/7CfGhdOube2vlQ5LC+slPaJgCaH7MhB3j0 ieADCgAjOH0J6MNR5dzyFs4qlumz8Yrrvbe+7/74DppDmxess7G2h55/zBiCYnlsOQNlmyydNOE HQq+N3Eb+hyHGrgdmGsE+QooGc3AsBlfnHu4bGeL1McD0NGYKBjVvOSrHYx32gmukqc3bdMvYkv 45OlicezpGUtyzKik2CsqfptehnENwET9zHkYvf3VuMtzj3/GyBDNf3q1bbMMp8YifcrGBPURoj jtOL66UyP3Xp34cF4HsAf0WnAE12z/SkmVF+gV0ehNFHYK7riPVbpaj/7z+gDA= X-Received: by 2002:a05:6000:4288:b0:488:6ed9:b11d with SMTP id ffacd0b85a97d-48dbacf554cmr21432930f8f.52.1791878905871; Tue, 13 Oct 2026 01:08:25 -0700 (PDT) Message-ID: <0b68d552-1d90-48d1-bc06-76caf40e61f7@suse.com> Date: Tue, 13 Oct 2026 10:08:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] automation/eclair: generalize the noreturn function-pointer deviation To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "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/1791878907-1B2DC9EA-CBFE30FB/10/78276251493 X-purgate-type: spam X-purgate-size: 2754 On 13.10.2026 09:56, Dmytro Prokopchuk1 wrote: > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -392,10 +392,12 @@ Deviations related to MISRA C:2012 Rules: > - Tagged as `safe` for ECLAIR. > > * - R11.1 > - - 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, parameters handling remain > - consistent. > + - The conversion from a noreturn function pointer to a function pointer > + with a compatible signature does not alter the calling convention. "... with noreturn omitted but an otherwise compatible signature ..." > + The callee does not return, so code following a call through the > + resulting pointer is unreachable. The compiler may delete that > + unreachable code when it can see the noreturn callee, or it may "... when it can see that all of the possible callees are noreturn, ..." > + leave the code in place. Xen's behavior is the same in either case. > - Tagged as `safe` for ECLAIR. While kind of implicit, should it perhaps be made explicit that we tolerate (deviate) such a violation of rule 2.1? > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -435,9 +435,10 @@ maintainers if you want to suggest a change. > and any other type > - 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. > + and void* are permitted. Conversions from a noreturn function pointer Nit: Take the opportunity and convert the badly formatted "void*" to match the formatting in the last sentence? (It's not quite clear to me though why that has parentheses; it would seem to me that just the quotes [and the separating blank] ought to be sufficient. My main point here obviously is that all spellings of the same thing would better be identical.) > + to a function pointer with a compatible signature are permitted. Like above, it is imo important to state that the difference between both pointers should be _only_ the "noreturn". That's lost here, just like it's lost in deviations.rst. Jan > + 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 Tue Oct 13 08:14:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 08:14:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446750.1662857 (Exim 4.92) (envelope-from ) id 1xGXef-00069p-EM; Tue, 13 Oct 2026 08:14:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446750.1662857; Tue, 13 Oct 2026 08: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 1xGXef-00069i-BO; Tue, 13 Oct 2026 08:14:37 +0000 Received: by outflank-mailman (input) for mailman id 1446750; Tue, 13 Oct 2026 08:14:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGXee-00069c-DH for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 08:14:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGXed-007x4p-Pv for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:14:35 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acde862-bab6-0a2a0a5309dd-0a2a450cb7f0-44 for ; Tue, 13 Oct 2026 10:14: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 6acde86b-f479-0a2a450c0019-d155802eb006-3 for ; Tue, 13 Oct 2026 10:14:35 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a0213948d3so16175205e9.2 for ; Tue, 13 Oct 2026 01:14: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-4a18bf2e0dbsm368550655e9.11.2026.10.13.01.14.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 01:14: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=1791879275; x=1792484075; 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=7QMy9/xrgp28NGEA86jIhdo6rJ6jivdFcahDfDNe+8I=; b=Qj+SuyZXPU4O0JrcBNdv4hdandGgHm3I9qdN5q9lvIRLmAj297i38eNTKVG9/iRFT8 iJ7m2RWb9jM8jUqaF7u3hngrBLOlSZEEWL8z585Gd9kdxjOA2yF+pLHpX5F6eWCBpfWF CxwJo+28hCPMIOzmBLi5XeXPkgAapJjf5YQyV6qfz1/ZzIPHSLWQdEkP2RDdVA6GrPJV G3oLR8qLiLJgcaFKmi95qwnxpU0C/zOPAeQ9dHKJO/jPwn1BR8ixRDEoxMlDSPSj7X9x s9zW+76A/3fTKmi5cYQUXP9kfWJgxsVsQ1ejNsgUTaKqxfKY1BFdxEw/sA5JjvbXGSRf 5Lfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791879275; x=1792484075; 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=7QMy9/xrgp28NGEA86jIhdo6rJ6jivdFcahDfDNe+8I=; b=jDPpgf6bTDT8l1gjfpd1CKKCoJpZqJyB9cYgWAIR0EpXp3m5BzFbE2GUKjEXR0tMoK s0C2gFcQALZ2exdTplhYqugUaiBKnBXx2kBc6oSKWLhxhbAXIq25uzPilkFE2AVJliNk 5qMZywhKABrpZ7URf6Cs0bb5GhhjERthGa1A8SYNE/4ujmaGUSdo0ChCzS9yuiY5evqj X4nSUk+RyBgvi6CDlzyDFmTDV83q1KdvDFXSLLXcCZd09+Y9OwP/2N0GseCLc3c6kApm BKjx7LtK2+2+uQlcQosGnBwuZKXvyN+RtzJA3uxvOcVcktXw/XlH+6tfVa2RVla7QsuT EwnQ== X-Forwarded-Encrypted: i=1; AKwUvBw9wAyMNN5KVGXqu0Zy7oppuLbDsognqsBlE0CO6C1wVG1kw3npZ03BVx0U04xM2HIFTRmQwFDlNBQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYLuSJeqL2rRynAs/s1IKfCgnrWseNAfi+NtOg3AZH2oU6ksNLY8 nxFuIyFQByQSZSz2gWy2kgQl1fb4Yg8uqaRiUm4HbBRpcyWtDexbYyQjnXNAPMJjcg== X-Gm-Gg: AYBFou00a0cfMjCkBvOEikkjgHE+GY0pZJi/jngnvdWD2tBu8wdg11twVb/6AoLNljh l4DJ/7S7Hoxvafyjvyw5xMUGWuAjPYy88sdSJJRiNucRHoySWkvpGpJbqj4VYtdQo5wLqf1ZuFH 1zP9WXunZxO5/rM9HvHiAgUfPvg+wx+C9fXqK41eUdz9vc/rkJPtTQYvDOFtPioQiBW0ewzOOhK wj+b2j4Iej4F8oZiAXoRyFP+uLGeXT6QPUjNlbWm6YtLWp5S9uDHm+GbffecelJpXx1MTUv9hkM t4wxroogFmydCRUKcQWz7846Mol7x9HVs7thDqBW6yj+PYlb5grR4mEhIqTWsa6w9TY6KMNjbQ5 Jhqh117eI5E3Jw6+uMrLP5EfOWxdyrfMi1Irdr9PJxEkM6sUJYlCjx0CEqEKpfP76MVQIIhvVg6 4a7XJniqurf85Uss9BLbVOnH5QvKPhvpra8hWOQOUFZdjLlJhdyYwxR/5iy6W6bHnOEct3i2DZr A6WgwE6sOCstjzOI2/urGr8SwHDyAwLEjXIq26oVktfYMILF6Y8WZtmRhWnZg== X-Received: by 2002:a05:600c:609b:b0:49f:ce78:356d with SMTP id 5b1f17b1804b1-4a18e4c9944mr218419915e9.30.1791879275013; Tue, 13 Oct 2026 01:14:35 -0700 (PDT) Message-ID: <171c47db-b916-4f25-8026-16a1a99dea0c@suse.com> Date: Tue, 13 Oct 2026 10:14:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , 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/1791879275-014C7A5B-1235A244/10/78276251493 X-purgate-type: spam X-purgate-size: 1770 On 13.10.2026 10:02, Dmytro Prokopchuk1 wrote: > On 10/13/26 10:52, Jan Beulich wrote: >> On 12.10.2026 22:49, Dmytro Prokopchuk1 wrote: >>> --- /dev/null >>> +++ b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh >> >> You neatly use dashes in the new file's name here. Is there a reason ... >> >>> @@ -0,0 +1,20 @@ >>> +#!/bin/bash >>> + >>> +# Hide every xen-syms linking pass except LAST_LINKING_PASS. >>> +# The pass list is the foreach in xen/scripts/Makefile.link. >>> + >>> +set -e >>> + >>> +cd "$(dirname "$0")" >>> +arch=$(echo "${XEN_TARGET_ARCH}" | sed -e 's/x86.*/x86/' -e 's/arm.*/arm/') >>> +last=$(sed -n 's/^LAST_LINKING_PASS *:= *\([0-9]\).*/\1/p' \ >>> + "../../../xen/arch/${arch}/Makefile" | head -n 1) >>> +passes=$(sed -n 's/.*foreach n,\([0-9 ]*\).*/\1/p' \ >>> + ../../../xen/scripts/Makefile.link | head -n 1) >>> +test -n "${last}" >>> +test -n "${passes}" >>> +hidden=$(printf '%s' "${passes}" | tr -d " ${last}") >>> + >>> +printf '%s\n' \ >>> + "-file_tag+={xen_syms_tmp, \"^xen/\\\\.xen-syms\\\\.[${hidden}]\$\"}" \ >>> + >xen_syms_passes.ecl >> >> ... underscores are used here? > > The generated file follows the other .ecl names (e.g. > linker_symbols.ecl). The script name follows generate-linker-symbols.sh, > which also uses dashes and writes an .ecl file with underscores. That's not very nice, but otoh not as problematic to warrant an immediate change. At the same time here your use of underscores is not only a style issue (where bad pre-existing instances should never be used as an excuse), but also weakens the connection to xen-syms: The underscore used could in principle be a surrogate for about any non-alnum character, including e.g. a dot. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:05:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:05:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446781.1662865 (Exim 4.92) (envelope-from ) id 1xGYRL-0005Do-7B; Tue, 13 Oct 2026 09:04:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446781.1662865; Tue, 13 Oct 2026 09:04: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 1xGYRL-0005Dh-4A; Tue, 13 Oct 2026 09:04:55 +0000 Received: by outflank-mailman (input) for mailman id 1446781; Tue, 13 Oct 2026 09:04:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGYRK-0005Db-DL for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:04:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGYRJ-0088ae-Me for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:04:53 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdf42d-e002-0a2a0a5209dd-0a2a45068144-24 for ; Tue, 13 Oct 2026 11:04:53 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdf435-195a-0a2a45060019-d155dd29e13d-3 for ; Tue, 13 Oct 2026 11:04:53 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48b9d8055dfso2059972f8f.3 for ; Tue, 13 Oct 2026 02:04: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-4a19f249692sm284583295e9.3.2026.10.13.02.04.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 02:04: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: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=1791882293; x=1792487093; 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=KaLuTr8HGt/pQS1uDA88fh1vUdSzddLeVHDak96yXBE=; b=Ymq0HY3d7MSS0DEOcRrfWtwhWTW2JkDOYiIHGVgpP1biz7ZtuWV8uY36jKoBtz5jfw BpJvzuRuuvxpBLBksVRZyAAaA15o++5XvhqiLSKwy60f50NBzEqUTx3sFdtMQew0P6Y2 rR8W+JRsIC8zRLze0aqFAvMsZVTD0JJ5gXoHa5On4fhkvZ8yRzJ7UdatFQ1Im52Krt6m wg8BaP1UDRanjOYxobKF9ba5gTGmcTLOZvvgFgJSFWVnLbSr8owT8daw9aqGODjpnOCn f4+uSeHpRkBpezt9kdCGaXqlNq7xVQWufI9X98sZdL7WVaK8G/6Sx3uaan+KjS49Mkef dqIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791882293; x=1792487093; 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=KaLuTr8HGt/pQS1uDA88fh1vUdSzddLeVHDak96yXBE=; b=sBZTH9QUpOGaliOz/fxEqfdKoDmifanfMYL/jgWGEfJaI8s9OddODee9CYJltrn7wC bgwLMvCYsByQlwEPkr+kDd9BfK1g/mP5iDuE7VOtJeu+8XZ/empnMcOcMyqpnzM8LQeM 53bN9xXKPLhSsKNLxt/tb7hwzI92rL6SSLCnWWZs6hiLPXKuBY25ds4jsxkmYvdSe9YA Y5nGSkZjKGJCXHSl/c2LHzsL/jR4KkqVNElBxTVRq5N+Ixu49r1pohsZcD0JV9tS5FGy R5/6nCgwSjCsTkhW9gWYukNY8VrgdGpThgruULDxaWI+p67wGCvvur4IHDyGV5S0wtDA LO+g== X-Gm-Message-State: AFq9FYIPfEcgbiy1E3BaGMlYKIIo8c8eFwabtWJ+LCE3SgK2fCRRfhfS O06RfUv3TUcIgpe1NvFM612q6tPO4XYKOa3dUlVvwmokTNiFmu83wib80Hp/exM5MqnJC0bnsmV 4KVyx9A== X-Gm-Gg: AYBFou17loqpw0Zn+GVF42wwdvdK+dA1thNZ7sEVtY7M/skMYDlUENe8T7ndtm6Z2r5 lDs+qqa0HdEJgLcGQO1i6Phzr1iukXcARJXTI2fbHJOOHE8EZkfoMu0v809ywZSJY3bWxYXlXmv vb3K6vuoDSbTF+50RNQLo00ltCcZeiC3I3qCRVpxlb3/h+UrIFUuFWFAzN4+OJxO5km91y5Q+Ws SZrZdBbihHZeHTF5eCoFs81LzzpGx+85ZnkoqqJ/XKQCQlReW5PT2um6bDzk4SLa2ZKBcBbquvR SzuxOT9NR5vUxC45NftfTGjOJDzwSEQKf6xd4aqGfY19Hu1TP2KbNgsHAOR+okldivu6X99QT3D urvNZr1sIm6mxW5PiBN0u9Zb5aLUj2Kve1jJfRqlQMpJYti6FnF/RySlFShoK+2R/C89GKb6Mxa RvCtOG0VkOrfQIxApKyKq0wb3pPdZ/ai+snFeGQtvUOO6PD94EW0lul0pSRwxCbW+Y94BMYAiMq 133A58IuLrsuFB+sXyG0CKc/noxcc2jlulyILwZbrbZXnFp/lpoMm9Dp0Fek54= X-Received: by 2002:a05:600c:609a:b0:4a1:7108:c2b6 with SMTP id 5b1f17b1804b1-4a18e4effabmr225126365e9.31.1791882292740; Tue, 13 Oct 2026 02:04:52 -0700 (PDT) Message-ID: <942facb0-c42b-4f09-9081-6cfb006c7bfc@suse.com> Date: Tue, 13 Oct 2026 11:04:50 +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/2] x86: mapcache_current_vcpu() adjustments Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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-16d1c6/1791882293-FD00977B-B11B04A1/10/78276251493 X-purgate-type: spam X-purgate-size: 177 1: constify local variables in mapcache_current_vcpu() 2: replace this_cpu() uses in mapcache_current_vcpu() The latter patch is somewhat RFC; see commentary there. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:05:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:05:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446785.1662875 (Exim 4.92) (envelope-from ) id 1xGYSD-0005gy-Ew; Tue, 13 Oct 2026 09:05:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446785.1662875; Tue, 13 Oct 2026 09:05: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 1xGYSD-0005gr-CB; Tue, 13 Oct 2026 09:05:49 +0000 Received: by outflank-mailman (input) for mailman id 1446785; Tue, 13 Oct 2026 09:05:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGYSC-0005fw-4V for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:05:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGYSB-00CGXx-39 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:05:47 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdf468-8faa-0a2a0a5109dd-0a2a4507e806-14 for ; Tue, 13 Oct 2026 11:05:47 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdf46a-b4ea-0a2a45070019-d155802cecfe-3 for ; Tue, 13 Oct 2026 11:05:47 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a1688d7769so22758605e9.0 for ; Tue, 13 Oct 2026 02:05: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-4a18d12fe04sm216034835e9.4.2026.10.13.02.05.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 02:05: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=1791882346; x=1792487146; 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=J8/RNEe1LKfSGu/L13fCO0FEseR/7iXO6dPS72xbEQc=; b=aZCKUm7eHRPW2Th12/gcAUP7wPBvhlvnXAnC1+/I/M8KEN8n9Au46RylSx1XswaeUF kgdNPgBV1Pto6zjM1nmWjRC4ctdKdQgUCglGb1BS2Xbyz33evCxu8eOXwU8E3yopJZJ8 4H3sjNJyAmYHmw1LldovUmWYj1/qJ4izgb51ViFGQy2YKuV20kYhOsHNM6FBPvq/pY8a XbJod5xWy1f9/OysnDKEt+e9rH0bd1ktprBHt6GGpNo6fusSl4iYOoFCplPWWori+Liz oVvxxcCP6rCM4N+Rrx2CYuKWw++noMhKTNQQr4WyCpE+qTVh5SdHAC77zutswDAlj8ln DEqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791882346; x=1792487146; 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=J8/RNEe1LKfSGu/L13fCO0FEseR/7iXO6dPS72xbEQc=; b=oX/tmQRzPGLHJZvda/Iy1wguRuHN64YkisB4FD1ZMiF9BBYQVtR1Cqbrmam2rpzaAr wTGONkE4yt0EEcx8DsjyNbLLKl4H0jyHnY1B6EE7ycKrHs86PzRbgcH90PtH4kzvAhdK 9LmxPe7QgOs5n+CR4MnhEUmm5+OSjJkTrHpuSXodhj1Ma3WN3OIBOcpSKH151kXNZVDC MSRiScJDND4XMCCuPHQ1ofLKMddbP/yXxEGqFmxROVqeSAD61OX/jkdwqFY+pAenEjLo WY4TfRxyAAv6aWSyiyxnNmKYUVKOTGgStep6kxd6WZvQsC6B2JhCN8++xNh+4yE6016O CJ6g== X-Gm-Message-State: AFq9FYLQMNORbDMtpSkgknUKV4Vw2QJR1BdW6twL3w7JzSOWYsR20/TF IxNn/qJiSeCV64ia/Iv0CsGrhakroj9c/KURqO9ZA3snfaSOeS3KmOGR4Ri69wSK7ZPMDsenOZN UBifnnw== X-Gm-Gg: AYBFou35/TEAWT7YA7gAMbUO/mVlF28r0n8bMfFsZ3CRspdmjZz6tBS+lr5deQX8hsb Y+i54d5QvLzr8+c2VDHU47ShBj53ci6ynj06aIMOCivOm07y2OSQcjOYjCFZFp+yBk7eIuQ+NLS rP929h/x0wwi7eBdCV9nGJ7EB/PTfHIjQUDto23jW5AxDVpkifQvPIk4tz6ppCHcsDNDuKRaIDN OCWMzn/xii7EcNlTC/KnWNsJ0fCokaEHQNsVIOo0sTORWMr3BiWMMOZVqwenoc4yM7f4l2p0Hff 6vQcuNDP0YuFl8hhRJBDU387aeexxreP5XjXHA54q7PCSGmepgPZ9xLxtPnw91ZERspWsmxEGr1 0FjUXbVBhugIzDsSBX0Z0Q9ZOXkKUqkf/W1OMRfUYhY8MJlTROIAmvy/Ppr1H6wDgMY7ejxm4/s ObcE35JNzOME92EMksH70xPLz2aAwN1ycRX6cjchxxZ9SbZQV/1gBNRomvjCcqcqNMqdZnLYRO5 i4psrJQeTRL0iSgcLEIM6M91xME7ZWG+l1QevM2hR4HFQIn+Vqm4WJcYpSriw== X-Received: by 2002:a05:600c:198c:b0:4a0:1c0e:b136 with SMTP id 5b1f17b1804b1-4a18e4cdbfbmr237371805e9.29.1791882346406; Tue, 13 Oct 2026 02:05:46 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 11:05:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/2] x86: constify local variables in mapcache_current_vcpu() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <942facb0-c42b-4f09-9081-6cfb006c7bfc@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: <942facb0-c42b-4f09-9081-6cfb006c7bfc@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791882347-35CC7AE4-8121BE56/10/78276251493 X-purgate-type: spam X-purgate-size: 1646 As of the referenced commit v won't be returned from the function anymore. Yet that was the sole reason for it to not be pointer-to-const. curr, which was introduced by that change, had no reason to be pointer-to-non- const from the start. Amends: 622c9a5ba95d ("x86/mm: accurately track which vCPU page-tables are loaded") Signed-off-by: Jan Beulich --- I was heavily tempted to also replace the smp_processor_id() at this occasion (by curr->processor). With gcc16, that leads to the function actually being inlined (in debug builds), i.e. a significant change in generated code, and a measurable increase in code size. From the function being declared "inline", that looks to have been the intention, yet then that use of "inline" doesn't quite fit our principles. The main reasoning for this as a secondary change would be: - "curr" could be dropped (instead of having const added) if code generated from ASSERT() wouldn't matter quality-wise, - if generated code quality matters there, then the unnecessary use of smp_processor_id() should matter, too. However, an adjustment along these lines may better fit in a subsequent change dealing with the repeated this_cpu() here. --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -20,8 +20,8 @@ static inline struct vcpu *mapcache_current_vcpu(void) { - struct vcpu *v = this_cpu(pgtable_vcpu); - struct vcpu *curr = current; + const struct vcpu *v = this_cpu(pgtable_vcpu); + const struct vcpu *curr = current; /* * During early boot pgtable_vcpu is not set, callers must handle NULL. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:06:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:06:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446791.1662884 (Exim 4.92) (envelope-from ) id 1xGYSv-00069z-NP; Tue, 13 Oct 2026 09:06:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446791.1662884; Tue, 13 Oct 2026 09:06: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 1xGYSv-00069s-KY; Tue, 13 Oct 2026 09:06:33 +0000 Received: by outflank-mailman (input) for mailman id 1446791; Tue, 13 Oct 2026 09:06:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGYSt-00069h-U3 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:06:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGYSt-001JZA-Ay for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:06:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdf48b-8faa-0a2a0a5109dd-0a2a4504ad52-42 for ; Tue, 13 Oct 2026 11:06:31 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdf497-b57f-0a2a45040019-d1558032ec23-3 for ; Tue, 13 Oct 2026 11:06:31 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a1688d7769so22765525e9.0 for ; Tue, 13 Oct 2026 02: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 5b1f17b1804b1-4a190344032sm357590515e9.15.2026.10.13.02.06.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 02: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: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=1791882391; x=1792487191; 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=OPUrzZTmhVKr/M+6DGPNI55GA5hLgwRu4wcXea+aI0c=; b=IJbZOOs3ZMXjcKZmdzCXE6C4Srz5gYniO3zutcPTMCd9iZ5N1MW1NckgNlIhasX098 IDZBw6uCJlYCfS39xHa/W4WnvhLUXfjKCZiZLa6sOVDIuwBz6hrv9GnczH/HUgF6kupT zQIxdM/oHIQj5zYhLx6cjDtK+DZH9Oyf0Oh5ebeirpJqTYym8E1cEr/wJsNTg44Nd8sY rf9T8COZhfribY8pgip6q45Biyl9TxyX9Ug2kZrGb66cwMtr0JsHm1u0s9+w7RC66bTH oP6VJtFmjMOTNAvKY220NpyiP4+XCcQW88VeUKkfli59FjgMHlpUmLurypW4e/Hb6jWH w04A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791882391; x=1792487191; 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=OPUrzZTmhVKr/M+6DGPNI55GA5hLgwRu4wcXea+aI0c=; b=Zo+zTtXm3dvZzehu+bGJ1IgDLXi+/y5JGS21i/2JM1e3TW/33A6+DvtaLkFCDm8tR5 cHFFf0VCVvDF5xX8MPQKpTY5SWSu9v7USJQqj8DaQWP8LZ74Kt6f23PT/iklX2RIvexo NesQrnz+vfmIq/87WPHfLSa5Z/jhDp7KFFUC+savY0HDo6zjIqpyAYM44bY4WM3THe0C l+ZhTzzVCS/AhPZ+AZOm5mFU7Nnqqim/KcsvZcpPNPTVgn+V0kbW+eHTit8pcnz8xA3y xNwPdD/adfDwLoiOrOnJ4MLsD9L6xSyb3qzzPAjdOLlpvyhYnQatbUGtNlQgakW97BxU T9ng== X-Gm-Message-State: AFq9FYKKr8za3szIANMaQg/5KzjqmTIXk9sMXxn96qTeGNiolmkgaxGS esQ/DtZgVA6LXlYe0hi3TZGd8fvj/5riRvqe+eqd4I39FodraH0YW3BNnibYCqqUd4kKhdR/uZ2 F53Bghw== X-Gm-Gg: AYBFou34LYUPdLGpNfr50yDyublVIJLNGMOQYToPR0vAp7GPg6u872hEF1xMgc1BH3X SuqK+1pgftzvvPyFUVTcSf3uOF1GGmMOrbWgXhypgXz7N9HkSyTeJwYSbQbTwalODm+V2u6Jay+ 3jWIU+lwk5l2fh5rpT0d+Tw/C+vPNBdBRLKdH5NLbqfnB2feDEiisQRry2BDcOomfmmyzKawJyh 9Mf9yKrFNvBthtbb7ufQqrDFx2DsLAdnVyBhWNrBW7Rmp70YixkpnFvb7Mgg58jekXdFlp1O3+0 DrqQV/bEgzmV3OUTnR+6xG83DyKL0Tt4SoLmRREMwKkbVpBqPJq4law4cAisfVKCYEh0nKnBwd0 p2sxCUmBuNMi4bZzsQHQRzfxcJ22g9a9LfxUKafj2ZZepj6pfXnlLXvyq+NNfCEJ7s335zrOAYX tEsE5a0ElVbx+7DpoG4om39+K8c+U5Fob0mROsJd7D8EPFS3hnJWTwAEZQuzVyxvJ/eHxzM1YGd goIICqQmgsM0M1L8DFewa4JJHHHpfpTWDEG56/fbTlPvNxeeWr2kc1QIMN5dQ== X-Received: by 2002:a05:600c:83c7:b0:4a1:7733:5102 with SMTP id 5b1f17b1804b1-4a18e4a3fc8mr222669895e9.15.1791882390595; Tue, 13 Oct 2026 02:06:30 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 11:06:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/2] x86: replace this_cpu() uses in mapcache_current_vcpu() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <942facb0-c42b-4f09-9081-6cfb006c7bfc@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: <942facb0-c42b-4f09-9081-6cfb006c7bfc@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791882391-C06DAB50-35FC6238/10/78276251493 X-purgate-type: spam X-purgate-size: 2240 We have accumulated three of them, plus a hidden similar 4th construct from smp_processor_id(). Latch the result of the latter into a local variable and use the slightly more efficient per_cpu() instead. Signed-off-by: Jan Beulich --- A 5th such construct is "current", yet to replace that we'd need to open- code both it (i.e. get_current()) and then also smp_processor_id(). I wasn't quite sure whether that would be deemed acceptable. Like indicated in the earlier patch, this similarly leads to the function actually being inlined (and hence generated code size actually growing) in gcc16 debug builds. In release builds (with older gcc) the function is being inlined no matter what. Overall, having looked at generated code differences, I'm not quite sure anymore whether the earlier observed inefficiency with repeated this_cpu() really is much of an issue (here or maybe even more generally). --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -20,7 +20,8 @@ static inline struct vcpu *mapcache_current_vcpu(void) { - const struct vcpu *v = this_cpu(pgtable_vcpu); + unsigned int cpu = smp_processor_id(); + const struct vcpu *v = per_cpu(pgtable_vcpu, cpu); const struct vcpu *curr = current; /* @@ -37,9 +38,9 @@ static inline struct vcpu *mapcache_curr * change the page tables under our feet an invalidate any in-use mapcache * entries. */ - if ( unlikely(this_cpu(curr_vcpu) != curr) ) + if ( unlikely(per_cpu(curr_vcpu, cpu) != curr) ) { - ASSERT(curr == idle_vcpu[smp_processor_id()]); + ASSERT(curr == idle_vcpu[cpu]); sync_local_execstate(); /* We must now be running on the idle page table. */ ASSERT(cr3_pa(read_cr3()) == __pa(idle_pg_table)); @@ -51,7 +52,7 @@ static inline struct vcpu *mapcache_curr * 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. */ - return ACCESS_ONCE(this_cpu(pgtable_vcpu)); + return ACCESS_ONCE(per_cpu(pgtable_vcpu, cpu)); } #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:09:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:09:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446801.1662893 (Exim 4.92) (envelope-from ) id 1xGYVW-0006nP-4d; Tue, 13 Oct 2026 09:09:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446801.1662893; Tue, 13 Oct 2026 09: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 1xGYVW-0006nH-1O; Tue, 13 Oct 2026 09:09:14 +0000 Received: by outflank-mailman (input) for mailman id 1446801; Tue, 13 Oct 2026 09:09:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGYVU-0006n5-H0 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:09:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGYVT-001K5d-Qe for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:09:11 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdf524-2eae-0a2a0a5409dd-0a2a4509db3c-46 for ; Tue, 13 Oct 2026 11:09:11 +0200 Received: from [52.101.52.18] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdf535-be1a-0a2a45090019-346534122730-3 for ; Tue, 13 Oct 2026 11:09:10 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by SA0PR12MB4462.namprd12.prod.outlook.com (2603:10b6:806:95::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 09:09:07 +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.0522.011; Tue, 13 Oct 2026 09: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" 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=dSxWjJNislUuScJEy+6UYweroQH6pNx7WL/OLyreXJPiqrOK/cCisPqt+EUoNFACmD21AR1I61jFzmE6CRSxDWtu/qS3j27YtF2hbzP7F5EFpHv8KRusx6GzZ3Oix3JrE0uUG4OCUFuVAayQuslpL31S9XgEk4f3wrqsYdmdazhRJ9zTeF5pUNdxQpfGChDcm6amchfbvWWWmzWpOyVVrXL05RbfIpnxwLbNDyfJmSyMFTcK2rfAzwINdoyqoLRnkSh+cFnVdHAOZQB10TzRk9bfC9QUKKkWLFzs8jL6glVtr944mPGF0ZiRroZH6lTP58wC9Vq/U1BtuONr5gaUoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vKsPSiNAJsut0sv62YQ7XV9ELK05TkGn7ktTCkdOCIw=; b=R8bt1f03HTBx3TCbs/pJueg/agKkeF7Ncw4gM40Y/iM0dCI8Cz7ewFzLk585XWxd6AKUpGmhvO4FjXxPpK316fqMtbn/BUuU0Usultlr3nb+faUifwH3GE/3IknS81fAQtCJOvixG5OOViBjLf2CaP2R2mWsRiOFOKRS2/hoeQXOzOQyY5izlb4JdjaOgR+7p31j9NIDZ/8rev4bgbY+ri6DkI+kWkyQzdRw2ZHWBHoN3zfgXsuYJ61aaxtw6yzCFmel0PDaX4CPPoGaVp8Sl5kjoDpk0APfVC68o0yjcSA04RIqJKxK86c49bqcyr8bQoWuyNZuPrBkjFJPnLVfnw== 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=vKsPSiNAJsut0sv62YQ7XV9ELK05TkGn7ktTCkdOCIw=; b=TZp0+hj/EbB1NUZPWyRtJ3R0v2CstBFl+U1wOaERxwLSI7BtDFISalQ0UcWZHuDmqKDHzSdfv6lF4jvBTSKCxSXsAgCShnmV+T0NKSZW3Bz7O50umdWisYzza/Y+GZ8Dr7JghEKkqBgtOxiZ5Gtpi/SmD4l+sU+7rN3yRy8dvqk= 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, 13 Oct 2026 11:09:03 +0200 Message-Id: To: "Sergiy Kibrik" , "xen-devel@lists.xenproject.org" Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" , "Daniel P. Smith" , "Andrew Cooper" , "Michal Orzel" , "Jan Beulich" Subject: Re: [PATCH v4] common: dom0less-bindings: introduce XSM labels From: "Alejandro Vallejo" X-Mailer: aerc 0.17.0 References: <20261012101453.949907-1-Sergiy_Kibrik@epam.com> In-Reply-To: <20261012101453.949907-1-Sergiy_Kibrik@epam.com> X-ClientProxiedBy: MA2P292CA0025.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::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_|SA0PR12MB4462:EE_ X-MS-Office365-Filtering-Correlation-Id: e2fd5fd6-20fc-4664-cc94-08df2909a2e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: AihD/mX6rj4YCfygwuQskKx8EYyPONluFbY0D0uIVqoq4Aw3pKGNTNcdaSk7L1NBIJ5UJE6sYNEsKhRPWL0N5M4rS5AaupjxybqTu1n4bRuPfQ4b3Ish65peeXuQmsFK8FzL0XZLpkNYOiWpehbdeMC6YT8Fv0BaMJbrv716pxZ+J5Rdhu1zh4bKCKi5b1MMnDALmtA2ikIFlvWLWOiEpQyIsdsVAz85qnK2el7T1Ly5und/yTjpVOq81U5SHsU90Ovvttnc1NLBJwaVLNaWRFeLW4k8gBOQ0hRmOwwCoxu7S6z83DCMr4On2FO+FTP+XJb1LEd69YvWQQ7RX31rsFShDtbrn3rHVCSY3zjZqZa9hSsPCZLkjh4uFEE+QwD0zS99E+Lwn+G6jxODwfjMvFMOP8Lm7i+gC5X6KcxEKhCq+vN5lW+KpQdnZMGX42dm6oHKoVScspybFD0iaph9a5MNZWbFXgD/Q2m0J8EZ0rglIdh2AUPiEKscvz8D0VNf+ePwKKyWnN/izqhCInCFgKkoe4idrAqnIa+Xqf3ds0/UcRcvaz+fknrzKspVbUSM/Nm6Wv/82E2IKU0pXDd6xBeSr3ggHAc27/O+dymaPSu4vN7WP8NvLvpfmq/iaio0CWrkTAb3FScicr4tx/xftiqurfeD0csllMitYHn47y8= 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)(366016)(1800799024)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dDVrcVlzeTlmTkVLa2o4cTRBSzRwSGkvYkNkQ0krMDdaUWR3RTVjc3RvaVA0?= =?utf-8?B?MEFjSFg1eWpaN2dkcHRQSUNxdDM1ZTMxWkZRRnhxcnhWTkcyaVgydUw3RUdV?= =?utf-8?B?bkl1dFFBU0ExS3R6L1dCdE1UWWRzWmJmM3h3bi95ZWJlY2RkUVc5ZFJZbE9l?= =?utf-8?B?aWZVai8rb0NjL2t6cTZucDJrUmZZYUtwazEvMXR2a3E2WG0yL0FoS1p3Y3dw?= =?utf-8?B?ZnhOM3g5d2xyeGFuQzJWUGpIWERRNmtpM09kdDFYR0Nzc0JTbDRoR0UwSmE2?= =?utf-8?B?bW90akxHNFp5alpPWFdDcUttcUpiZjZpaExRZ1FKejJYZGlOZHdxd2ZhaXdi?= =?utf-8?B?T2cweUxjTVp2WjJpSDd5aDlqY2hMQjEwdnFRbGtmdnFFUFR0NUZiL1QwVGIr?= =?utf-8?B?d1F4MzVieEdFWnpPdlhaS293WnZCNnhIV25ESU0waFJudFp1dFYwUHVvd3hQ?= =?utf-8?B?S1RidVBxbGdXV3c1ejJJYitGKzRiZDRrNTJZeHBZSnZnWFh4b1NRd2duTG5l?= =?utf-8?B?ZnU1dWZKYTc5cittK1E4RXd2TnBaMnZvK2hOelFkSUNDUnZBUnpCcjZabFFs?= =?utf-8?B?Q3VQTFRoZUdiY2RvWEJGQjVZTWdub3R2QnRDeExKWk9FWkNJYTltVDFvOGgr?= =?utf-8?B?eHdjTG1hUTgwWC9HTldSNUtNbGZRdVBGN0J0SG9tcmVTZElJS3pZSW83TXli?= =?utf-8?B?ZC95S0pkdDdwaVBZdklFenZLZG4vRldrbUpROFlRbVk1V0V2cndQdnNsbGIz?= =?utf-8?B?YllSVkdhQlhlQ2l0VjQrVWtqTXBoa0J6N3hkc2VKNStnWFdkdkVncW5xQXNt?= =?utf-8?B?VUY4TXFJUGdnUCtMWmxWdDNMQW04ajVDYnZWeis2TGg0eXQzM2U4U3JQWWZV?= =?utf-8?B?UmJ4QkNZTDhyNE5ZM1JZQkVyM0lBUU9UMWNQRXIrQ1M0Q2FQRmtWT2M2aC8r?= =?utf-8?B?bFFnb0lvUnBFbWQyQlBXemRPOTZPSWg4aDZ1YkU5ZlI4OVErMVc0T25BU0Fv?= =?utf-8?B?dUdwRVdKVFVFZG13MEdDdWd4Q2tleVVuS1R4RGhSY3BCL1ROZ0pDSTNoU0Jr?= =?utf-8?B?ZkNVOWNaK1lqQ0l4enE0ODROdkZSUzFFR3hIMFRxLzJoUTRTcTVhRE9DYmVm?= =?utf-8?B?Wi9RL1ZockN2VlFYeU1LVEk3QWdaeGRjc284aWVUTitZZWRHTnhqVHBmaXYv?= =?utf-8?B?RmFZUk5KOGp6VURZNFROZXBZOXlTTkdrMS9lbWNRejlVZ01nNVdVL1EwdDlI?= =?utf-8?B?RWppaGhOS2xxZy9JdllJVEpvenFob0tId0hXY2NjL0xXU1hmT1FXSGcvSFFH?= =?utf-8?B?RnRPQ2ZvSm5wZjg0N3JMZ1Q1RWk3Y2cxdXZwMDVUQkpKZUFiK3Qva2VjRTN3?= =?utf-8?B?c3hwQU41ZzFVV0tnOU4vVEFrc2ZLbUk5Umlwdlp3citaZmJpTHJOM3VnQzhB?= =?utf-8?B?THIzOTJnLzBHV202UzFNWVpGQnM2V0FWMWJaM0xGdjNRMTRjaU9vQjBua1lh?= =?utf-8?B?S3FHbDV4V2wrMFF2NHpod1VFY29aaXUzMlc0R1Fxd1MxRGRCNUVmcUZaLzli?= =?utf-8?B?bG5XWHZzSWtWTTNEVE5DKzZXZUZNUHdkVENKendPcUI5WHQwV2p1Z2Z5Zksv?= =?utf-8?B?RDBVODZIbnNpcGRnUTY1RVNkbFBIT2FaejZURC9yUW1CcHVqV243Z0xyUTdH?= =?utf-8?B?c2dIRHF6cjlrdjRaekJkYnhTN1lodnErVWFJVGRZNkFNcUdxWWJ1U2tPMWxi?= =?utf-8?B?ZU9hWUVUUnRIcEVuMGVFRkpsbUlhMC9Ja2NMaVRSYXJPbEdLTkxCUGRXYWFz?= =?utf-8?B?UndnTWhndUV3bWRYSG53ZGJtbUo5MzV1Y01Na1lTL0prdDJhdnFJWk5QblU4?= =?utf-8?B?QWhWZllLVUI4dnY5azA4dVpMajBJL1JoVGlwZkFqWFpybEUrR1lJcEF0VnBH?= =?utf-8?B?czBvVEZEa1dXTVNNNkxSRGdYTmVEVGt3aHhSZXpXTHVyZVJMdDl6MHNWWDlw?= =?utf-8?B?MVBPT2VCdkE5T2kweDV1TjA2OUFmVFFsRlNRNjlaYW9xUEIrQ0R3UzhWV3Bs?= =?utf-8?B?a1k4VFc4OWkvZ1lvL2hkbkFRR1RGTFU2T1ZLbDlHTkNzQ2VEeWkzQk14NWx5?= =?utf-8?B?bGlNTlExUU1HZVZXTXAxV1F5eTI1cXJXUnpvbmNVM0VhWDZxUzBWZTVNa1Rw?= =?utf-8?B?Q0F5RzgzZkZTK2hyZjh3czdOQ0lscWtWdzhnNXA2ZXpKZHl0OG1OOHRJNXVq?= =?utf-8?B?eVJCNXk1eE9BazRvaXpORnVsVm0rdWNhRUVzaHZqTVU4V3hWTkMrTHp3TjlC?= =?utf-8?B?ZlJFaExEWUNUV2NmSmZub3RDUzg0SE1jUzFWa3BwWm1FbzhNaHZuQT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2fd5fd6-20fc-4664-cc94-08df2909a2e1 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 09:09:07.5236 (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: 6wVzV0YpE4dyBoIeJ1rS84cH2/Ht1WKzDoWSfuOy9yymv/M6B7cX5HzXIRw6qLKZHByiWKFaGXNtzHjqcOb3oQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4462 X-purgate-ID: tlsNG-bad1c0/1791882551-FD86F034-99F256C8/10/78276251493 X-purgate-type: spam X-purgate-size: 6460 On Mon Oct 12, 2026 at 12:15 PM CEST, 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" l= abel > by default, which Flask denies to create according to current policy. > > Because code from outside of flask can't directly execute its internal AP= I > a new XSM hook lookup_sid() introduced as part of XSM API exposed > to rest of Xen. > > Signed-off-by: Sergiy Kibrik Reviewed-by: "Alejandro Vallejo" A couple of inconsequential nits below, but otherwise LGTM: > CC: Daniel P. Smith > CC: Andrew Cooper > CC: Michal Orzel > CC: Jan Beulich > CC: Alejandro Vallejo > --- > changes in v4: > - introduce XSM hook `lookup_sid` > - at SID lookup return error if security server not initialized > - document panic if DTS property is used and FLASK disabled > - per Michal's request panic if FLASK disabled is left unchanged > changes in v3: > - panic if `seclabel` property found but FLASK is disabled > 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 | 7 +++++++ > xen/include/xsm/dummy.h | 7 +++++++ > xen/include/xsm/hooks.h | 2 ++ > xen/xsm/flask/hooks.c | 7 +++++++ > 5 files changed, 31 insertions(+) > > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device= -tree/booting.txt > index bcb06bc796..2a69d2537d 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,stati= c-mem) > and direct mapping (direct-map). > =20 > +- seclabel > + > + A string property specifying an XSM security label to this domain. D= omains > + will be classified =E2=80=9Cunlabeled=E2=80=9D if this property not = specified. > + Note: boot will fail if this property is present but FLASK is disabl= ed. > + > Under the "xen,domain" compatible node, one or more sub-nodes are presen= t > for the DomU kernel and ramdisk. > =20 > @@ -422,6 +428,7 @@ chosen { > memory =3D <0 131072>; > cpus =3D <2>; > vpl011; > + seclabel =3D "system_u:system_r:domU_t"; > =20 > vcpu0 { > compatible =3D "xen,vcpu"; > @@ -453,6 +460,7 @@ chosen { > #size-cells =3D <0x1>; > memory =3D <0 65536>; > cpus =3D <1>; > + seclabel =3D "system_u:system_r:domU_t"; > =20 > module@0x4c000000 { > compatible =3D "multiboot,kernel", "multiboot,module"; > diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/devi= ce-tree/dom0less-bindings.c > index 41d72d0d58..b03cee0e8c 100644 > --- a/xen/common/device-tree/dom0less-bindings.c > +++ b/xen/common/device-tree/dom0less-bindings.c > @@ -11,6 +11,8 @@ > #include > #include > =20 > +#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 *n= ode, > bool has_dtb =3D false; > bool iommu =3D false; > const char *dom0less_iommu =3D NULL; > + const char *xsmlabel =3D NULL; > =20 > if ( !dt_device_is_compatible(node, "xen,domain") ) > return -ENOENT; > @@ -141,5 +144,9 @@ int __init parse_dom0less_node(struct dt_device_node = *node, > panic("'llc-colors' found, but LLC coloring is disabled\n"); > #endif > =20 > + if ( !dt_property_read_string(node, "seclabel", &xsmlabel) && > + xsm_lookup_sid(XSM_HOOK, xsmlabel, strlen(xsmlabel), &d_cfg->ss= idref) ) > + panic("Invalid security context for domain: %s\n", xsmlabel); > + > return arch_parse_dom0less_node(node, bd); > } > diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h > index 6331859afa..029cddd5cd 100644 > --- a/xen/include/xsm/dummy.h > +++ b/xen/include/xsm/dummy.h > @@ -823,4 +823,11 @@ static XSM_INLINE int xsm_domain_resource_map( > return xsm_default_action(action, current->domain, d); > } > =20 > +static XSM_INLINE int xsm_lookup_sid( > + XSM_DEFAULT_ARG const char *ctx, uint32_t len, uint32_t *sid) > +{ > + /* dummy policy has no security contexts */ > + return -EPERM; nit: Perhaps -ENOSYS? or something like that. It's not that any permission was violated, it's that the real version of this function is absent. > +} > + > #endif /* __XEN_XSM_DUMMY_H__ */ > diff --git a/xen/include/xsm/hooks.h b/xen/include/xsm/hooks.h > index a331f5f0e5..3c1bef3053 100644 > --- a/xen/include/xsm/hooks.h > +++ b/xen/include/xsm/hooks.h > @@ -169,6 +169,8 @@ XSM_HOOK(int, argo_register_any_source, const struct = domain *) > XSM_HOOK(int, argo_send, const struct domain *, const struct domain *) > #endif > =20 > +XSM_HOOK(int, lookup_sid, const char *, uint32_t, uint32_t *) > + > #undef XSM_HOOK0 > #undef XSM_HOOK1 > #undef XSM_HOOK2 > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c > index d65ba0aeae..b130ff5e26 100644 > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -1949,6 +1949,13 @@ static int cf_check flask_get_domain_state(struct = domain *d) > return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STA= TE); > } > =20 > +static int flask_lookup_sid(const char *ctx, uint32_t ctx_len, uint32_t = *sid) > +{ > + if ( !ss_initialized ) > + return -EAGAIN; nit: missing newline > + return security_context_to_sid(ctx, ctx_len, sid); > +} > + > static const struct xsm_ops __initconst_cf_clobber flask_ops =3D { > .set_system_active =3D flask_set_system_active, > .security_domaininfo =3D flask_security_domaininfo, Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:11:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:11:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446808.1662906 (Exim 4.92) (envelope-from ) id 1xGYXP-00007o-Ij; Tue, 13 Oct 2026 09:11:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446808.1662906; Tue, 13 Oct 2026 09:11: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 1xGYXP-00007h-G2; Tue, 13 Oct 2026 09:11:11 +0000 Received: by outflank-mailman (input) for mailman id 1446808; Tue, 13 Oct 2026 09:11:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGYXO-00007b-9u for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:11:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGYXN-008xMK-2j for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:11:09 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdf5a2-e002-0a2a0a5209dd-0a2a45019ff2-32 for ; Tue, 13 Oct 2026 11:11:09 +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 6acdf5ac-5984-0a2a45010019-b9ff1c228051-3 for ; Tue, 13 Oct 2026 11:11: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 1a134879de70008d8d.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 09:11:05 +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 858C581EFA; Tue, 13 Oct 2026 11:11: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=+SjvvlMtL5a9eP9zeBQb8gb4uYnRCp/7Hj2b8SPTJHk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=n59k1QMQzUZd1V2fXpzXwNn+JTxlbm4FuLFz/7sZ1CvqtRqTS7TVIJtSZVh2afr13B4+NJtyi xQUiG9NfpOE9GmjoMSwkvgYJQMIumCPMLA0Do3OezZUvh8uTbbYGzZsOUjsTNFANs+WX/oPxaQn YGxE7XLOKExK7uGcx9KJXaF6sV7HPmVriE5/GcFaqo+GjiHBejtiMk67MLn+9/UT5vKH5TSJVRj 1XqmdsOrIJMylWu/O9IXEjrKhHBGHCjXYIkvXNF3vmmJXNHYUj1juhANarBDTIFJwBrSBDSRd2r Np0nh4OMstXxr+xr3jrI+kvwo4rPXkTrkAVIZia8Su6Q== X-Zone-Loop: 2371ce93fe835e167258998c4f28181d99008bec2269 x-campaign-type: default x-transaction-id: f4d9c6a1-fe01-4a8a-babc-7761f9250d41 x-swg-uid: 01-128da419-58ad-458b-8cef-832b3b3831c0 X-Mailer: Sweego Message-ID: <1791882665.8631fc262581453bbf619ec5b2062170.1a134879de70008d8d@vates.tech> x-swg-bid: 1791882665.8631fc262581453bbf619ec5b2062170.1a134879de70008d8d 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] trace/vvmx: Correctly report TRC_HVM_NESTEDFLAG flag Date: Tue, 13 Oct 2026 11:09:24 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.144.dff6e87b310439ff.1a134879af1.cb07c7e5f3b46092=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791882664695 X-purgate-ID: tlsNG-d62444/1791882669-BD146757-26D6CF51/0/0 X-purgate-type: clean X-purgate-size: 2333 ---=Part.144.dff6e87b310439ff.1a134879af1.cb07c7e5f3b46092=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Currently all VMEXITs are reported as if it occured "non-nested", even when the vCPU is in "guest mode"=2E Making distinguishing "nested virt" VMEXIT to regular ones much harder=2E Fix this by adding TRC_HVM_NESTEDFLAG flag when the guest is in guest mode, matching the svm logic=2E Fixes: ??? (???) Signed-off-by: Teddy Astie --- I can't really find the commit that introduced vVMX=2E But I guess it would be the candidate for the fixes tag=2E xen/arch/x86/hvm/vmx/vmx=2Ec | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx=2Ec b/xen/arch/x86/hvm/vmx/vmx=2Ec index da657187bc=2E=2Ed13603254d 100644 --- a/xen/arch/x86/hvm/vmx/vmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vmx=2Ec @@ -4209,9 +4209,13 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_= regs *regs) __vmread(VM_EXIT_REASON, &exit_reason); =20 if ( hvm_long_mode_active(v) ) - TRACE_TIME(TRC_HVM_VMX_EXIT64, exit_reason, regs->rip, regs->rip = >> 32); + TRACE_TIME(TRC_HVM_VMX_EXIT64 | + (nestedhvm_vcpu_in_guestmode(v) ? TRC_HVM_NESTEDFLAG := 0), + exit_reason, regs->rip, regs->rip >> 32); else - TRACE_TIME(TRC_HVM_VMX_EXIT, exit_reason, regs->eip); + TRACE_TIME(TRC_HVM_VMX_EXIT | + (nestedhvm_vcpu_in_guestmode(v) ? TRC_HVM_NESTEDFLAG := 0), + exit_reason, regs->eip); =20 perfc_incra(vmexits, (uint16_t)exit_reason); =20 @@ -5025,7 +5029,8 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_= user_regs *regs) if ( unlikely(curr->arch=2Ehvm=2Evmx=2Elbr_flags & LBR_FIXUP_MASK) ) lbr_fixup(); =20 - TRACE_TIME(TRC_HVM_VMENTRY); + TRACE_TIME(TRC_HVM_VMENTRY | + (nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : = 0)); =20 __vmwrite(GUEST_RIP, regs->rip); __vmwrite(GUEST_RSP, regs->rsp); --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.144.dff6e87b310439ff.1a134879af1.cb07c7e5f3b46092=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:18:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:18:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446823.1662919 (Exim 4.92) (envelope-from ) id 1xGYdx-0001H9-8z; Tue, 13 Oct 2026 09:17:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446823.1662919; Tue, 13 Oct 2026 09: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 1xGYdx-0001H2-5j; Tue, 13 Oct 2026 09:17:57 +0000 Received: by outflank-mailman (input) for mailman id 1446823; Tue, 13 Oct 2026 09:17:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGYdw-0001Gw-M9 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:17:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGYdw-008CJI-19 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:17:56 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdf734-bab6-0a2a0a5309dd-0a2a450ba658-46 for ; Tue, 13 Oct 2026 11:17:55 +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 6acdf743-b7e8-0a2a450b0019-d1558031e003-3 for ; Tue, 13 Oct 2026 11:17:55 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a1635f7c89so27293625e9.2 for ; Tue, 13 Oct 2026 02:17: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-4a19303d518sm322254105e9.0.2026.10.13.02.17.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 02:17: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=1791883075; x=1792487875; 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=Wb+X1sF4zeDymNFCbZercNQDUON3NVbLmz8q5ryD980=; b=Ykw9sTC+rTieT35LxTn8+mR0c+eVlmtBKkLkfJsrF9t0WDKYOT17SJDfJOz2PmZVve oW+Zmq3MfsyQeQZBIa0mEvT3l0Bc6hv8K5+z4YMrFJKBwX/+Pl2zOYAusFpcBLig+ouZ A+OOOdAxNzq75MQ4wDbvVWucMa3mIiYD1ilYpaVqUzreW7vcO0oE7Pf3fy7B9aYAJGY5 G6XdGLoEhqLT0TZxkcH0MLwyzW4/XpdaM0KmEtJ9vx9xu3Je5j6FiRJJW6ZVkf/t2htU iHwUD06of0yW/ZIBNZuLZ/D1Hw3zoqM2D7Ayuo3ftFSTPuN3Kf6w3l8p3BO0/pwFAppr jSdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791883075; x=1792487875; 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=Wb+X1sF4zeDymNFCbZercNQDUON3NVbLmz8q5ryD980=; b=MSo+S1Xq6iAOg3Z3k/2dbfGmnz/SPJ/HpqzOImSFp4M2/HnCCYWtoLfTlfVeoPb+kC 6++SRyEGdAc9MrATnHq4BayeEOQKPYZw/HYZhHGxKDZ4jDtyRkgt85S/+OSRdyygiKqv +6odf0uSzhsJecX0kl8aW5G6NmfuayX9+y1uoVEeIxbjBlPjrMwR6OsWsVeqjUSekkGb A9Iv0hEf0n9fZtMFLUBTwDIPKR2pwRjlYMBCSI7jcCL5C497GXp11AUMe5q4WfgC69CA mTuubaAXE6mRlpw0bavAoiGBJcW8hvW22okEbFpa2Rbi4L5RdbKkNpbypfQncUFji2Pw paFg== X-Forwarded-Encrypted: i=1; AKwUvBxKVQAqrb2bTWEANUkaz0BAG3npgbzTYiC/D6cy4HhNNXn49eKFjm+VKPJeG6McoeCYWaCWQLjLBZk=@lists.xenproject.org X-Gm-Message-State: AFq9FYJtubaikb0wpRNWCgTWeUe4vyPmKDdvu2s02B7YaGO7Psuuh9FA ZIhZ2HMsfH35F5wlijjqfuZNmujwStDPskxfW2MmIih9XVbPhf8HHh/60z44eXSr1A== X-Gm-Gg: AYBFou0lLldR8VpyszvTRZZ4VxEy3jxEQSJCC2AWEjD6QiE478VnpQy/UQJRxnuRrFA LEsZurTaBLi97vEHPawsfCB3yG07a/PvaCFSN0gAFkPSgqZbJzGO9x3LeQC8F9lBcJmd/lg01k7 7Sy1bmyi16Ztxd7w3fd3dmP4IM+2hkjKVGO2LgkWcjU0ICD+uTs3bjTZwUqcIshQGGoKDzcmM0m 38ZWuCWnuuLQHOmtloE1Bc+4Tr0JexZMyCCxJMNv+e2Cy5joQ3A39jN4oaCr6xHTkAhc6HxgPIO elUEtibtspCqzZ8A2hgQ9/iB0mX91RmKoquL0J9eBPoyDQbGThMaTqRwgdY21ZOkmzid8B0R0hF sAU3s6uVsiPllcM2a2SwWYfKd7dLwNDKkLfSeWIK0A7+vgyIOQlxe9WYTofKZHyPCWTJnzOZFnT 8O8xAn8am24gTUw4/qyMDDF829o4nDokEpOBjZYqy87Z27iN+ZlHI+I8e0QxSkNbLgZ5G03FZBq it0TU6sXqw5HGtJcmxM7VEWPZw/G73x84U3raU++l39JcK+Hy6UU/3Lg0eI8A== X-Received: by 2002:a05:600c:8716:b0:4a1:62b8:9aa1 with SMTP id 5b1f17b1804b1-4a18e44885dmr238764075e9.2.1791883075082; Tue, 13 Oct 2026 02:17:55 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 11:17:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] common: dom0less-bindings: introduce XSM labels To: Alejandro Vallejo Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" , Andrew Cooper , Michal Orzel , Sergiy Kibrik , "xen-devel@lists.xenproject.org" References: <20261012101453.949907-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791883075-198C19EA-401DE54A/10/78276251493 X-purgate-type: spam X-purgate-size: 751 On 13.10.2026 11:09, Alejandro Vallejo wrote: > On Mon Oct 12, 2026 at 12:15 PM CEST, Sergiy Kibrik wrote: >> --- a/xen/include/xsm/dummy.h >> +++ b/xen/include/xsm/dummy.h >> @@ -823,4 +823,11 @@ static XSM_INLINE int xsm_domain_resource_map( >> return xsm_default_action(action, current->domain, d); >> } >> >> +static XSM_INLINE int xsm_lookup_sid( >> + XSM_DEFAULT_ARG const char *ctx, uint32_t len, uint32_t *sid) >> +{ >> + /* dummy policy has no security contexts */ >> + return -EPERM; > > nit: Perhaps -ENOSYS? or something like that. It's not that any > permission was violated, it's that the real version of this function is > absent. Yet then still e.g. -EOPNOTSUPP, but certainly not -ENOSYS. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:42:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:42:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446837.1662933 (Exim 4.92) (envelope-from ) id 1xGZ21-0005sq-5K; Tue, 13 Oct 2026 09:42:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446837.1662933; Tue, 13 Oct 2026 09:42: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 1xGZ21-0005si-1V; Tue, 13 Oct 2026 09:42:49 +0000 Received: by outflank-mailman (input) for mailman id 1446837; Tue, 13 Oct 2026 09:42:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZ1z-0005sc-MV for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:42:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZ1y-007I8L-Hp for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:42:46 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdfd10-2eae-0a2a0a5409dd-0a2a450ac8e8-18 for ; Tue, 13 Oct 2026 11:42:46 +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 6acdfd16-f2d2-0a2a450a0019-d155dd30e9d8-3 for ; Tue, 13 Oct 2026 11:42:46 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48bbb06e746so1594310f8f.3 for ; Tue, 13 Oct 2026 02:42: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-48de0967affsm3752255f8f.1.2026.10.13.02.42.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 02: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=1791884566; x=1792489366; 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=qxuJO6v0t7axAJy1A/2p0M1yzgOxBdQjnXoQINhCbgw=; b=gX7y0vwgv+DEB1YqOhgZeUZbS/SC939ldNqM+6k5pJFQBtIbntdevbstxi+SyJ06ER dECj2wopTVXKpqleBebYdYR+IrN7QWOxEuj95071WVEAUpkdPvV9BTwACRYWy8mKS/Bh 1KX6V6RjG285xjEHKFO/jIUHvDU2PwFTPfkhzNol9K1csXgXN2QVNF8uB8mUF7U2PVia W3xbEMqqNMUFC9ZG5AKZhwXFW0cJqIpeKOvuzgEWik7T7XEQKOH8MzEdNWBYvPt/xzdS htqFkUfU3apbuHvE3JKFbcijpahUrFtN3EeHKBDz8qAV9xKifZlLgLhywPoVLqlqF3OU vvvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791884566; x=1792489366; 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=qxuJO6v0t7axAJy1A/2p0M1yzgOxBdQjnXoQINhCbgw=; b=whl+T5CNZpPU+PG4W9WhZqZwGIIrn7WQLHjo+8N1G5HRaKwoqWVD6k7RhlCf4/Vhl2 ny+5ur55GAjNmIJ+JLc1hu5mUuAKP1xiqTqtAejjrvzemYToI9HotGkcRXZNGrsXxXKH BjhwGrf+QfVso8k2y9jh7blqisYdg4j6Mm0QX9krV+aclLphzXMWaJVlb55w7sFkicuo mucrb+g7z95XSQ07uMNc19it2W/zap2wx5cWZr9IUaYW60SFbTWKjg8PLOEPvHpJsEaA cdbzIr8LaklgtHwa9Z6p+U3DJZCaxONZ2tbr6GH1qiqw4DrXhGvrFzId1DP3DQkATdDT BlKw== X-Forwarded-Encrypted: i=1; AKwUvBxDeP+ucmU4gLTSpwH7FA8kjvB4wMe4Yr78qXF7V573FBkIcrpZhrW/9iVS6Uyoij7qIZBfIr4lJ74=@lists.xenproject.org X-Gm-Message-State: AFq9FYI4YuNl+E5C1j88xc3JnUvymf1Hat/iPAvSWeFA0G3O0/m9uP0l fWsuc5uxrJg9+a0XiBHU+xLAEA/cceu5VhEnKoG33kQzGkWFVbQKeEtsTzRAlN7u4w== X-Gm-Gg: AYBFou0OWtRZiZqyPwvhmm+J8qDW1TYWG64jYTatrHcf7AlrsEaX0tgmvDkMTmhPInv sVtEaUkC/xqQ6xLU8BZ3Oyza+lsIZtJGRAton6DFlRQqOWwYIAMgZFmxcDsjUaBFR8EUT7My9Nj bnK27ZQCewrUYmqDQvAxsG/dRsnMQdm7qx9A9dUxlu6Gx7Tc/X29FlPY7yjM5OkI6F6tTW08otC uxkVymRtEwAL+CsHzIUWV8CRQPKm7fZyaL5HOpKUUYsiJRspurJYWz194QfB3FRzvJYOGGJSNV9 vPLUc9xrMJAG8tYW7eqUimd/qx8VkvnWetTl1na9WuDL1A0kKORD6YWQmW8Or6SlkabD7sOECW5 I92UlD7fIKSrzHxVhKaj4+zhwnftjT3NHkggx3DKHffXIpD4rtTJsNb0AI9f8fyDHjyVDKeRWyk EaYHAvz89hzCt3+KH7hsCY/fKEyDtLLBaF4y1/g3rkoW+3MsVBcPOpdfB00yQwdFW05pggCmlsK KcRfFN1iwcXjitx7bqBP4qK7TEWKgAcTIfDQKjGfRKpuyMTaWULEmrKFGxj2g== X-Received: by 2002:a05:6000:260b:b0:485:8c16:a34b with SMTP id ffacd0b85a97d-48dba9dd11bmr24009612f8f.35.1791884565756; Tue, 13 Oct 2026 02:42:45 -0700 (PDT) Message-ID: <8b1e612d-395c-46ad-b327-2718dd9d83cb@suse.com> Date: Tue, 13 Oct 2026 11:42:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] trace/vvmx: Correctly report TRC_HVM_NESTEDFLAG flag To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1791882665.8631fc262581453bbf619ec5b2062170.1a134879de70008d8d@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: <1791882665.8631fc262581453bbf619ec5b2062170.1a134879de70008d8d@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791884566-526DECFC-AFCB57BD/10/78276251493 X-purgate-type: spam X-purgate-size: 1944 On 13.10.2026 11:09, Teddy Astie wrote: > Currently all VMEXITs are reported as if it occured "non-nested", Nit: s/ it / they / > even when the vCPU is in "guest mode". Making distinguishing > "nested virt" VMEXIT to regular ones much harder. Same for entries, as it looks. > Fix this by adding TRC_HVM_NESTEDFLAG flag when the guest is in guest > mode, matching the svm logic. > > Fixes: ??? (???) > Signed-off-by: Teddy Astie > --- > I can't really find the commit that introduced vVMX. But I guess it > would be the candidate for the fixes tag. For the exit aspect I'd suggest 3bafd4a90995 ("Nested VMX: VM exit handler of n2-guest"). Changes to vmx_vmenter_helper() came later, so I'd leave it at that. > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -4209,9 +4209,13 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs) > __vmread(VM_EXIT_REASON, &exit_reason); > > if ( hvm_long_mode_active(v) ) > - TRACE_TIME(TRC_HVM_VMX_EXIT64, exit_reason, regs->rip, regs->rip >> 32); > + TRACE_TIME(TRC_HVM_VMX_EXIT64 | > + (nestedhvm_vcpu_in_guestmode(v) ? TRC_HVM_NESTEDFLAG : 0), > + exit_reason, regs->rip, regs->rip >> 32); > else > - TRACE_TIME(TRC_HVM_VMX_EXIT, exit_reason, regs->eip); > + TRACE_TIME(TRC_HVM_VMX_EXIT | > + (nestedhvm_vcpu_in_guestmode(v) ? TRC_HVM_NESTEDFLAG : 0), > + exit_reason, regs->eip); SVM code uses a local boolean to avoid the separate (and now also repeated, considering the later use) nestedhvm_vcpu_in_guestmode() invocations. Thoughts towards introducing such a local here as well? (I don't quite understand why they also use nestedhvm_enabled() when setting that boolean: nestedhvm_vcpu_in_guestmode() would better return false for domains with nested not enabled.) Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:52:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:52:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446847.1662941 (Exim 4.92) (envelope-from ) id 1xGZAz-0007rZ-Vy; Tue, 13 Oct 2026 09:52:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446847.1662941; Tue, 13 Oct 2026 09:52: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 1xGZAz-0007rS-SU; Tue, 13 Oct 2026 09:52:05 +0000 Received: by outflank-mailman (input) for mailman id 1446847; Tue, 13 Oct 2026 09:52:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZAy-0007rM-DW for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:52:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZAx-007KT8-Qg for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:52:03 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdff3a-bab6-0a2a0a5309dd-0a2a4501cfb6-10 for ; Tue, 13 Oct 2026 11:51:59 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdff3e-5984-0a2a45010019-d155dd33c524-3 for ; Tue, 13 Oct 2026 11:51:59 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48b042c0728so584949f8f.1 for ; Tue, 13 Oct 2026 02:51: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-48de0bc6ddcsm4170894f8f.52.2026.10.13.02.51.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 02:51: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=1791885118; x=1792489918; 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=VW1GUPHtYzSt2OTa4PxklzBki78wWxXw5o8OcRcerk8=; b=M6Ls1BCuQsW7CzUNm1I/0G3RrXj9BKiXW++u2j2mJlEZqGAQ3gCSIJ49uJtnz29+ug x8lXDmuKan9r8ww5Ra04bgNcpBB4HTYfh+tT9FxmzY46nfzklMk23lLZxo2heZ1fFgmp y6/HVo2IzjanMqCxhkHTH5HJxhDktaintOTAAtss97FDkdXDJail6E2izsFv+pcqdBEy E03CEosqCizH00s5ZBKiRoaREc1SpQAAdsK0wnLnxlLGbuoWirAh3Dsa6pdhLXaQyn66 JTJAtMhAM4upRHG+SIICL5bmNJA3PTlWLY+Kvf/QIiUcS22cc1WWLGclFiuQjzspDlOl /E3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791885118; x=1792489918; 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=VW1GUPHtYzSt2OTa4PxklzBki78wWxXw5o8OcRcerk8=; b=u7Zv46LaRbQHep7IknX3SRbctKwfkRLIFPVNcDcphF0HozOuMqHNOP5A1Zk0Age8GL 2TIr5tZZHKjot7t63XnqCOQOWfOpOlDJe2P9KpJ0rFNuhds6Cyb2+45Sqv3VFNNimF3N F93d85KQmKFTBen3yWuWY4dYP5pNt5I7rPNSYuR5HVHKRVMFNZ4eX+ewwOmbH+J1Nakp MFy6on7CEEp/NXRAkp6NzqXY2UbI3XPxsQzayWdtLauI7CBHDHOCL5pMmHq15ujHmDFY 3F9PQbJqKY/woCH+mL0gkf0mwGKApC5gS+Z5Axdp59je+9i0g3tsvSIGpUJD2RBJSfkM U4Rw== X-Forwarded-Encrypted: i=1; AKwUvBw+kpMNvg8f0bjHJ310nFnoDZPiDmMXHdutr88MpjdC0exLiqym5VRLPSjCM3uKj3iZdu2LcfhOkpM=@lists.xenproject.org X-Gm-Message-State: AFq9FYJCHmP0FElP61UMQjUC7xXTHEBAhsLJY1eHW4BbEro00oAPf03y thbdvDmeRq47YReqURnYl/6sxumBf4jC7+7FB0DYklzSNZWnn0DpaVhHxHnDRHz3LA== X-Gm-Gg: AYBFou21An0TD24vKH05yaYN0jRB7oJjo/IU7cHe0d+wuUuzKJp9rlg6gwVANQIC8jn 7GROuwsZDio2TTJSugnsps8PYh8pCkmhqVT/L2eGydcuUy3PEQmyldt+rMgDNj4vg90gnYgE50J boLL8BpMlulzKvwv3JHzTZYtfZ4BKXeyGo4H++NcsVgw/3FX00kb+JGEBY8ITh4p6igIQ0VRAo5 GjeFKlZKsBnzHhOty4U4AA38ul5aYsYW4C7Ky/+bOHDWzOaetjtvmEQPI7KHqBlQGSD7FwmZvfc PX1ommSMZEzooioQHlzcpn4jWiCRJp+ERy+HqH5u2uuLLEtOgEuSoohV9D6+mLJ1Sf26/q4ezZC faXsbnFAvC2rl62TK/vcZrfnz7gqUCUfbtNVngS3MyANrjJiwvo+g5vjXUiuvFtJeDZN4GlaOod DxKZ5exBEGys8Aztr4V/syIoKNN9GXCijbgAzFIMXeFAb9QipZQOesWlwKa70Vh0gM9VjkZCgn0 JwG3by4RRROlRtnxI3AuxUGndn5LCo6mjI49NGYxQKmruP9r59YxMNfohIPHw== X-Received: by 2002:a5d:62d1:0:b0:488:898b:5c78 with SMTP id ffacd0b85a97d-48dbacdaa8cmr16518382f8f.29.1791885118500; Tue, 13 Oct 2026 02:51:58 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 11:51:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/13] x86/hvm: Clamp Viridian features to known set To: chunjie.zhu@citrix.com Cc: ross.lagerwall@citrix.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, xen-devel@lists.xenproject.org References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> <16057af6a0433e8cec576825b784e3316fc2c06a.1791625578.git.chunjie.zhu@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: <16057af6a0433e8cec576825b784e3316fc2c06a.1791625578.git.chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1791885119-BD67C757-24947A85/10/78276251493 X-purgate-type: spam X-purgate-size: 688 On 10.10.2026 12:13, chunjie.zhu@citrix.com wrote: > From: Ross Lagerwall > > 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 Before submitting this v2, did you check prior communication? As per [1] this patch was withdrawn. Jan [1] https://lists.xen.org/archives/html/xen-devel/2026-09/msg01511.html From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:54:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:54:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446853.1662950 (Exim 4.92) (envelope-from ) id 1xGZCu-0008QM-Cn; Tue, 13 Oct 2026 09:54:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446853.1662950; Tue, 13 Oct 2026 09: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 1xGZCu-0008QF-A9; Tue, 13 Oct 2026 09:54:04 +0000 Received: by outflank-mailman (input) for mailman id 1446853; Tue, 13 Oct 2026 09:54:02 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZCs-0008Q9-La for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:54:02 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGZCs-00000003KXH-1bwb for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:54:02 +0000 Received: from mail-lj1-f180.google.com ([209.85.208.180]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGZCr-0000000ARCe-2pRX for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:54:02 +0000 Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-3a1e9f55e03so28529701fa.1 for ; Tue, 13 Oct 2026 02:54: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" 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=Wh8VGNxDk/AeYfKU+y8mMXdp0C/7KK4Y4DxjqYCm/e0=; b=CiUu0uMUlRRyHzC21R1GW36bCr AKHNtP1VAv//Rt+7ST2MK395feYoyWacP0jaO7aigQ9bTBaZ8iD6ZaNkN/xVUw3U6ZQW9cRdvi5Uo bJXlcWcmgJ1NicJJc3viiQmb6E/6J6ta84+JNtxVdqVxe6F3X921EJL3ZjaiUxlWfRyE=; X-Forwarded-Encrypted: i=1; AKwUvBxVHQZDYxIPFD/52L9GwHdEoa/82UBrz+3yfbwmCyw/g1PDfmlnrWW8YYufsA83hY5RsdUEtuALcxM=@lists.xenproject.org X-Gm-Message-State: AFq9FYJtd6IirteN31tPi2BV/9SsAlHNYoHPVglpm2M9yYkh4Ff0cvvG oR0piAJ9fRmGcXUyl21w/5r9xHmpzcPsR3MTyx3bV536zPiMZQts7nmP1Pkt2YKC5mQYHX3+5WH nem6CAJV3AzBYEZ5dVnRrJt+WE4Croto= X-Received: by 2002:a05:651c:4ca:b0:3a9:d0fe:ec4d with SMTP id 38308e7fff4ca-3a9d0ff0b91mr21670061fa.1.1791885241003; Tue, 13 Oct 2026 02:54:01 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> <8514b7b6-cf1c-44d9-827c-675fd5a6708e@suse.com> <43f7a948-669f-48cb-8e1f-9d1a8a98a8f5@suse.com> In-Reply-To: <43f7a948-669f-48cb-8e1f-9d1a8a98a8f5@suse.com> From: George Dunlap Date: Tue, 13 Oct 2026 10:53:48 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_WPeqqoTY8JQhvQS0vPv_9Ffq258YqnWEVG2WqZsMC11NTThJRY_Es8_E Message-ID: Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 13, 2026 at 7:26=E2=80=AFAM Jan Beulich wro= te: > > On 12.10.2026 18:07, George Dunlap wrote: > > On Mon, Oct 12, 2026 at 2:48=E2=80=AFPM Jan Beulich = wrote: > >>> @@ -74,12 +130,12 @@ void *map_domain_page(mfn_t mfn) > >>> #endif > >>> > >>> v =3D mapcache_current_vcpu(); > >>> - if ( !v || !is_pv_vcpu(v) ) > >>> + if ( !v ) > >>> return mfn_to_virt(mfn_x(mfn)); > >> > >> I don't quite understand why this is_pv_vcpu() is okay to drop. What > >> mapcache_current_vcpu() returns isn't what it ran is_pv_vcpu() on. (Sa= me > >> in unmap_domain_page() then, obviously.) > > > > So mapcache_current_vcpu() is a bit weird; the actual invariant is, > > "Return the vcpu whose cache structure we should use if present; or > > NULL if there's no cache structure to check and no need to sync." So > > if pgtable_vcpu is HVM, return NULL and just use the raw address, > > I was going to say "But there's no returning of NULL there if > pgtable_vcpu is HVM, at least not at this point of the series." Only > then I realized that I was being confused by there being both v and > curr, and neither of them being pointer-to-const (i.e. both being > equal in terms of which of the two might be returned from the function, > yet as a result of earlier changes neither is being returned anymore). > > > because at this point in the series, both HVM and the idle domain have > > full directmaps; if pgtable_vcpu is PV, then maybe sync, and then > > return the result of the sync. That may be a PV domain with a > > mapcache, or an idle domain with no mapcache, but in either case you > > can then read cache.inuse to see if there's something there. > > > > So yes, it's a different vCPU; but it's still defined in such a way to > > be safe to check cache.inuse. The only possible value *change* after > > a sync is the idle domain; I don't think we need to do another check > > to make sure it's still a PV domain. > > Yet then - aren't the is_pv_vcpu() you drop here redundant already > before this patch/series? In which case (since it's not entirely > straightforward to reason about and beneficial in its own right), > might it make sense to have this be a separate change, with (in > particular) dedicated justification? (ISTR having thought about > making a patch to this effect a little while ago - perhaps around when > Roger last touched this logic -, but then deciding that something was > wrong about my reasoning. That may have been a mistake, as it looks > now.) > > > In fact, there's an argument that we should modify > > mapcache_current_vcpu() to take pointers to dcache, and vcache, and > > return just cache; that gets rid of v as a local variable of > > map_domain_page entirely, and makes the logic ("get the cache we > > should use") more clean, and gets rid of one mfn_to_virt() instance. > > That would require some non-trivial changes, so I'd rather avoid that, > > but I can do it if you want. > > Sounds entirely plausible, but can as well be done as cleanup later. I'm a bit confused about what, if any, change you're requesting here. Are you requesting a preparatory patch just removing the is_pv_vcpu(), with an argument as to why it's redundant? Or are you OK with having this cleanup work be put until later? Or do you want me to put the is_pv_vcpu() back until we feel like cleaning it up properly? Thanks, -George From xen-devel-bounces@lists.xenproject.org Tue Oct 13 09:58:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 09:58:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446859.1662959 (Exim 4.92) (envelope-from ) id 1xGZGj-0000ta-Ri; Tue, 13 Oct 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 1446859.1662959; Tue, 13 Oct 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 1xGZGj-0000tT-OS; Tue, 13 Oct 2026 09:58:01 +0000 Received: by outflank-mailman (input) for mailman id 1446859; Tue, 13 Oct 2026 09:58:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZGi-0000tN-4s for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 09:58:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZGh-00Et7S-Gc for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:57:59 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace009b-8faa-0a2a0a5109dd-0a2a450cc04a-34 for ; Tue, 13 Oct 2026 11:57:59 +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 6ace00a7-f479-0a2a450c0019-b9ff1c238bd3-3 for ; Tue, 13 Oct 2026 11:57: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 1a134b280a30008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 09:57:56 +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 150D281B76; Tue, 13 Oct 2026 11:57: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: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=tshKmaV+xywsb1zShKCMqcDk2ylft75PjoDWAgm3asU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=uG4TcqV4QWcxNUJ2n3RokwwMCej3/KshHAZ6Wa89naakpISvykSNNosAufMXufZ0+zKnECk+Q VasN+Laz0CXARVF/MS8ESpb6xsy3AQTtLL7ki6ckc1ZyGzbXK5segOlMu4gEG276kb08SKFj0Zm gEuDgvETMIkAT1cKo3NJL25Np2jy6DVjCsoUBxPwsWYQV8EbYy8OwySvh3dcS/nUhrR9Kus11VE JpGtD26HJxyjwpY0Om0yzAKxH0TdTifsdDbDJxqw0zSWW5EzI78L+3whG/o4YPFjC5c6aZttxlZ 4csRXuTUuqJKFdlOI9ZS0pfDaFx2qJcAdmYhlP5dgWFQ== X-Zone-Loop: 9f8855f2e7ae52dbc8872df14c2f14d5793caf492770 x-campaign-type: default x-transaction-id: 1c77507a-33a2-45fb-a382-55bad6157cdc x-swg-uid: 01-0e6dd9ed-dd8e-4dee-84dc-fa29366c6750 X-Mailer: Sweego Message-ID: <1791885476.8631fc262581453bbf619ec5b2062170.1a134b280a30008425@vates.tech> x-swg-bid: 1791885476.8631fc262581453bbf619ec5b2062170.1a134b280a30008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 13 Oct 2026 11:57:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] trace/vvmx: Correctly report TRC_HVM_NESTEDFLAG flag To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1791882665.8631fc262581453bbf619ec5b2062170.1a134879de70008d8d@vates.tech> <8b1e612d-395c-46ad-b327-2718dd9d83cb@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: <8b1e612d-395c-46ad-b327-2718dd9d83cb@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------X8Kr5Z5rxbTXfQI86Cxa6Atz" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791885475182 X-purgate-ID: tlsNG-d25034/1791885479-50B3DA5B-932B335C/0/0 X-purgate-type: clean X-purgate-size: 7749 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------X8Kr5Z5rxbTXfQI86Cxa6Atz Content-Type: multipart/mixed; boundary="------------g0CrHjBGwJyi0AFFeybRy0Or"; protected-headers="v1"; hp="clear" Message-ID: Date: Tue, 13 Oct 2026 11:57:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] trace/vvmx: Correctly report TRC_HVM_NESTEDFLAG flag To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1791882665.8631fc262581453bbf619ec5b2062170.1a134879de70008d8d@vates.tech> <8b1e612d-395c-46ad-b327-2718dd9d83cb@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: <8b1e612d-395c-46ad-b327-2718dd9d83cb@suse.com> --------------g0CrHjBGwJyi0AFFeybRy0Or Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTMvMTAvMjAyNiDDoCAxMTo0MiwgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g MTMuMTAuMjAyNiAxMTowOSwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiBDdXJyZW50bHkgYWxs IFZNRVhJVHMgYXJlIHJlcG9ydGVkIGFzIGlmIGl0IG9jY3VyZWQgIm5vbi1uZXN0ZWQiLA0K PiANCj4gTml0OiBzLyBpdCAvIHRoZXkgLw0KPiANCj4+IGV2ZW4gd2hlbiB0aGUgdkNQVSBp cyBpbiAiZ3Vlc3QgbW9kZSIuIE1ha2luZyBkaXN0aW5ndWlzaGluZw0KPj4gIm5lc3RlZCB2 aXJ0IiBWTUVYSVQgdG8gcmVndWxhciBvbmVzIG11Y2ggaGFyZGVyLg0KPiANCj4gU2FtZSBm b3IgZW50cmllcywgYXMgaXQgbG9va3MuDQo+IA0KPj4gRml4IHRoaXMgYnkgYWRkaW5nIFRS Q19IVk1fTkVTVEVERkxBRyBmbGFnIHdoZW4gdGhlIGd1ZXN0IGlzIGluIGd1ZXN0DQo+PiBt b2RlLCBtYXRjaGluZyB0aGUgc3ZtIGxvZ2ljLg0KPj4NCj4+IEZpeGVzOiA/Pz8gKD8/PykN Cj4+IFNpZ25lZC1vZmYtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNo Pg0KPj4gLS0tDQo+PiBJIGNhbid0IHJlYWxseSBmaW5kIHRoZSBjb21taXQgdGhhdCBpbnRy b2R1Y2VkIHZWTVguIEJ1dCBJIGd1ZXNzIGl0DQo+PiB3b3VsZCBiZSB0aGUgY2FuZGlkYXRl IGZvciB0aGUgZml4ZXMgdGFnLg0KPiANCj4gRm9yIHRoZSBleGl0IGFzcGVjdCBJJ2Qgc3Vn Z2VzdCAzYmFmZDRhOTA5OTUgKCJOZXN0ZWQgVk1YOiBWTSBleGl0IGhhbmRsZXIgb2YNCj4g bjItZ3Vlc3QiKS4gQ2hhbmdlcyB0byB2bXhfdm1lbnRlcl9oZWxwZXIoKSBjYW1lIGxhdGVy LCBzbyBJJ2QgbGVhdmUgaXQgYXQNCj4gdGhhdC4NCj4gDQoNCkxvb2tzIGdvb2QgdG8gbWUu DQoNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jDQo+PiArKysgYi94ZW4v YXJjaC94ODYvaHZtL3ZteC92bXguYw0KPj4gQEAgLTQyMDksOSArNDIwOSwxMyBAQCB2b2lk IGFzbWxpbmthZ2Ugdm14X3ZtZXhpdF9oYW5kbGVyKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpy ZWdzKQ0KPj4gICAgICAgX192bXJlYWQoVk1fRVhJVF9SRUFTT04sICZleGl0X3JlYXNvbik7 DQo+PiAgIA0KPj4gICAgICAgaWYgKCBodm1fbG9uZ19tb2RlX2FjdGl2ZSh2KSApDQo+PiAt ICAgICAgICBUUkFDRV9USU1FKFRSQ19IVk1fVk1YX0VYSVQ2NCwgZXhpdF9yZWFzb24sIHJl Z3MtPnJpcCwgcmVncy0+cmlwID4+IDMyKTsNCj4+ICsgICAgICAgIFRSQUNFX1RJTUUoVFJD X0hWTV9WTVhfRVhJVDY0IHwNCj4+ICsgICAgICAgICAgICAgICAgICAgKG5lc3RlZGh2bV92 Y3B1X2luX2d1ZXN0bW9kZSh2KSA/IFRSQ19IVk1fTkVTVEVERkxBRyA6IDApLA0KPj4gKyAg ICAgICAgICAgICAgICAgICBleGl0X3JlYXNvbiwgcmVncy0+cmlwLCByZWdzLT5yaXAgPj4g MzIpOw0KPj4gICAgICAgZWxzZQ0KPj4gLSAgICAgICAgVFJBQ0VfVElNRShUUkNfSFZNX1ZN WF9FWElULCBleGl0X3JlYXNvbiwgcmVncy0+ZWlwKTsNCj4+ICsgICAgICAgIFRSQUNFX1RJ TUUoVFJDX0hWTV9WTVhfRVhJVCB8DQo+PiArICAgICAgICAgICAgICAgICAgIChuZXN0ZWRo dm1fdmNwdV9pbl9ndWVzdG1vZGUodikgPyBUUkNfSFZNX05FU1RFREZMQUcgOiAwKSwNCj4+ ICsgICAgICAgICAgICAgICAgICAgZXhpdF9yZWFzb24sIHJlZ3MtPmVpcCk7DQo+IA0KPiBT Vk0gY29kZSB1c2VzIGEgbG9jYWwgYm9vbGVhbiB0byBhdm9pZCB0aGUgc2VwYXJhdGUgKGFu ZCBub3cgYWxzbyByZXBlYXRlZCwNCj4gY29uc2lkZXJpbmcgdGhlIGxhdGVyIHVzZSkgbmVz dGVkaHZtX3ZjcHVfaW5fZ3Vlc3Rtb2RlKCkgaW52b2NhdGlvbnMuIFRob3VnaHRzDQo+IHRv d2FyZHMgaW50cm9kdWNpbmcgc3VjaCBhIGxvY2FsIGhlcmUgYXMgd2VsbD8gKEkgZG9uJ3Qg cXVpdGUgdW5kZXJzdGFuZCB3aHkNCj4gdGhleSBhbHNvIHVzZSBuZXN0ZWRodm1fZW5hYmxl ZCgpIHdoZW4gc2V0dGluZyB0aGF0IGJvb2xlYW46DQo+IG5lc3RlZGh2bV92Y3B1X2luX2d1 ZXN0bW9kZSgpIHdvdWxkIGJldHRlciByZXR1cm4gZmFsc2UgZm9yIGRvbWFpbnMgd2l0aA0K PiBuZXN0ZWQgbm90IGVuYWJsZWQuKQ0KPiANCg0KTW9yZSBnZW5lcmFsbHksIHdlIGNhbiBj b25zaWRlciBkb2luZyBhIGJpdCBvZiByZWZhY3RvcmluZyBhcm91bmQgDQpgbmVzdGVkaHZt X3ZjcHVfaW5fZ3Vlc3Rtb2RlKClgIChsaWtlIG1ha2luZyBpdCBhIHN0YXRpYyBpbmxpbmUp LCBhcyANCml0J3MganVzdCByZXR1cm5pbmcgYHZjcHVfbmVzdGVkaHZtKHYpLm52X2d1ZXN0 bW9kZWAsIGJ1dCBoaWRkZW4gYmVoaW5kIA0KYSBmdW5jdGlvbiBjYWxsIG9mIG5lc3RlZGh2 bS5jIHNvIGl0IGNhbid0IGlubGluZS4NCg0KPiBKYW4NCg0KVGVkZHkNCg== --------------g0CrHjBGwJyi0AFFeybRy0Or-- --------------X8Kr5Z5rxbTXfQI86Cxa6Atz 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+p0QLLz9AFAmrOAKIFAwAAAAAACgkQZg+p0QLLz9BV HQv8DhAklEiQ51UXIh/PvaDghqojsxUblcxyw4LCPhN/uX2OOQRGz4wy2Rkh9II8O6waeqpeLo8j 5TDsXI4+KslFnQcuDpGjo5mbLr14H4ZBdOiW+V8o46Yy/yaFApIdXdBrJf8TARbO4MJsf81xGCV7 bKyGHL9c3+ZjkE/eAqIGjvnhiVYxlDImbBdGagVTlNk0LYutdQEfQEhdSv6DEOCX8v3BtSNDpzw7 6ciRcXKdsVnaNWJTrdyMpuK+aWy/nWHM3nADPvi/EPCN22ipeBX9RJATLXnQ+AgkemLfWi8qHF8Y fRtOCfKQOP4gjnbQUnVqLWgjKgzFDMCXZJae7MhukMkPchWWR3RTdWND1unnh09orVMKkHurNhRu B9YBd3TcXlT1VHvD6gl9Zh5Uuby5EAx7/2l9r/bsf45QWLor6LYUXIfnAbC5wgNUvGLA1HGunH/E sHmDqezSN3U4/eQqfZc1Xq5FPpuoLqPeO+Xx8kpGoqTai20W8Aq91MCN1Zdw =veep -----END PGP SIGNATURE----- --------------X8Kr5Z5rxbTXfQI86Cxa6Atz-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:01:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:01:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446866.1662972 (Exim 4.92) (envelope-from ) id 1xGZJx-0002Yp-AG; Tue, 13 Oct 2026 10:01:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446866.1662972; Tue, 13 Oct 2026 10: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 1xGZJx-0002Yi-6s; Tue, 13 Oct 2026 10:01:21 +0000 Received: by outflank-mailman (input) for mailman id 1446866; Tue, 13 Oct 2026 10:01:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZJw-0002Yb-LR for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:01:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZJv-007MuN-Uo for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:01:19 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace0169-2eae-0a2a0a5409dd-0a2a4508e124-32 for ; Tue, 13 Oct 2026 12:01:19 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace016f-f659-0a2a45080019-d1558031f16f-3 for ; Tue, 13 Oct 2026 12:01:19 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a140e7405dso31703265e9.3 for ; Tue, 13 Oct 2026 03:01: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-4a198c80cb3sm167750445e9.3.2026.10.13.03.01.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 03: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=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=1791885679; x=1792490479; 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=pIv2XFtlpp6kdQOhPGZBJOWTybPv3CvTi9JYIWsAtpg=; b=Ibj0Tv2/beFBDNJiJ/9+Bohcgiav8+VbIib5cVbHV7Bo04MAhaunpH6RpVFTL3RzBs p63gNAaK36mBa6M7fLuCRSyS2rV9QdO44uVJ5Kqfi5nE1bA9+dDYwTl63xpY6fNsEsfo PbTLIgZU3U/gM3ySzCHz9DdjXfO5C75rf1LXX0DyhaP6B0ujG2DUWmXh7zglap0FYVyz kQa/00AB2t56kkjHXO6aP5Zyk0nUsN9ntxeqxPGOb6pqeDq6feXYzYzRMLuBHGTP4Rra MtBXHHf/x2FmDaVKFIi3vlBlnsuBsQoctwoqOUftUcOJdzech/VoYxK6Eiz3BjVDpizr ZWeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791885679; x=1792490479; 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=pIv2XFtlpp6kdQOhPGZBJOWTybPv3CvTi9JYIWsAtpg=; b=x7iLBzuDMA++ZZDeKzRwCIhbierjOc6fMT4ZKccckc/noOGoN+gl7VwRX2ACGa8OZi NwjVRL5qY6xvLYJzeV1JhHknBfNQu3j4LLkJuJWVZq4EgGHWHCdKag7DStY3Fm7QxaJP CEMX8fLjwjC9DB0i/G/IW5evW7dg5iLYJA2uTIY9ZW2DYO6nfP5zqwe/UNyAKeyUiLM6 5GUOquodIheTc543k6kKiyC6AQpDP4jV9ZfWSSK8hQvrW5sINUCt3ERrYELWVn1piPJg jqvQg/3SEGkU1vbETyh7xqRWSkGuUm/FsFZmKTzmIZBrCKbYyCOT7518NStNHoM9qeRO pbiA== X-Forwarded-Encrypted: i=1; AKwUvBzW4gbipKIERn5RrPV1vIGhaXMTv4OclDemEEDxktOkeTLNznKW3UcTogFZZk7TLoMmnBQ47TsnRy0=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ5bD/szsONKjX35QKG61W6RaZgmSOrs9n0r9pD4b69O/Jw7EAp o+vSBzPiSWSYI/bKFL9yKKoJ8MLwS5ywnlaPJb0w2i9JCvYvlOWRsAoHno1UkFHQTw== X-Gm-Gg: AYBFou3l7euX8yzpL7wz13b0s0FOes7nicut/6V5UGfsWGH7/yr2UMQZuVNETiRhA9a PTZ0hcUz0NzsQ9mRoiKRvtFf2tQe2gfa5JxELqKy+F500EjvpjdzoJb1K2wHY1agLDeMkuimGGJ 0z0Kv8zOwHW6EHz9+DpXtxbZgxpAN3w4iHKfPyW7iyzqv//+qJJXNqJptW4/xpj0CtTscSxvKOL 398jhwF/qNx/ic5McUEraS+koVFBBvBqci3Rn2XS9ZbJ3Nw9xEK/8fuJtwAkW6gUqhcTKxsV8zJ 86gqTBalWx70zt5ShEMO6WCuxKY6NmeV/VDVDAQILgJDCid09qADMI+y0IH3nKpq9GYIkZa8uGY RX5yj6IxO9qPskXQ68XGtjxWwdrTP2aloKFPL84BQQbbMMgC1RN09QTn4A/LxrN3LT/T5de6iMT 2c0u2iNxtQmMwqHknPvcWLZQ7Sib8F2nLV0d+n5uWjH4uJjDiYetdQCg6KxK/H7+lBeHUk5zYgH BP4OEeu3btfQfIkrcDLy8719xle4SpSYkx4UNfkIqid7DyIJLeTiuDx1Nh4gg== X-Received: by 2002:a05:600c:3b98:b0:499:79b9:e220 with SMTP id 5b1f17b1804b1-4a18e49886amr265964215e9.10.1791885679143; Tue, 13 Oct 2026 03:01:19 -0700 (PDT) Message-ID: <775b1f5a-ec70-41e6-9926-2c817c0e0521@suse.com> Date: Tue, 13 Oct 2026 12:01:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/13] nestedsvm: Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 To: chunjie.zhu@citrix.com Cc: ross.lagerwall@citrix.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, xen-devel@lists.xenproject.org References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@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-c1860d/1791885679-D674387B-FC8A72E6/10/78276251493 X-purgate-type: spam X-purgate-size: 588 On 10.10.2026 12:13, chunjie.zhu@citrix.com wrote: > From: Ross Lagerwall > > 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 Where did Teddy's R-b go? From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:02:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:02:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446873.1662980 (Exim 4.92) (envelope-from ) id 1xGZLC-00033l-LT; Tue, 13 Oct 2026 10:02:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446873.1662980; Tue, 13 Oct 2026 10: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 1xGZLC-00033e-Ie; Tue, 13 Oct 2026 10:02:38 +0000 Received: by outflank-mailman (input) for mailman id 1446873; Tue, 13 Oct 2026 10:02:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZLB-00033W-H9 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:02:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZLA-008KqQ-U1 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:02:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace01b9-8faa-0a2a0a5109dd-0a2a4502839c-20 for ; Tue, 13 Oct 2026 12:02:36 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace01bc-6ca4-0a2a45020019-d1558033b12d-3 for ; Tue, 13 Oct 2026 12:02:36 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a061a13884so23835185e9.3 for ; Tue, 13 Oct 2026 03:02: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-4a18ca51465sm266695565e9.4.2026.10.13.03.02.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 03:02: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=1791885756; x=1792490556; 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=jnNfUjR5ts0AhBZ8/zYArDz7AA7tizmaC4J+0l6WxyM=; b=QpxbrygI1ID1cu3FF5zuOHt+bIAPFQmxbgse3FdahKRQlKi+iRKzfL7iCsL+8uo8W+ 5VSAyWBZbVj/tbvGA7lB48JRgrUusSrAqDPcx9fcNdxMbM5pTbml2SERvh2c8xt5kSlZ aUdWg4pPYoHu1T44JkdHP2jki2sSFv1iMwAGjra2w++2NMXtxtuGcw1bNIUi3r95/Tdw C2byR1T53BQnrd9CDK+4X3C/OadNHTGwQT1R9VLwWjRSMRYN5E+bRCMg8H8yr8ZlPLvq iJNXNBlDQWSO8qpx1Ul9bq1jGPjoaX1Yn9tWbKeMAv7+c2aKWV6UIy0Eqess+CSBKBpy EEWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791885756; x=1792490556; 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=jnNfUjR5ts0AhBZ8/zYArDz7AA7tizmaC4J+0l6WxyM=; b=Z8rUF6UEIumMN19fLFambGWafH66jZ1jkdVOVsuMV03H9fgLK8dsC6+S4KYFpesIY7 5TDL0+rhGh6d48U1yO7bfI5T+nvoo6KYrVHvief0bkQCBKmL2peCeD4ZHdsQdSFRSOEb AXtLNnS4Y2IDVDU77/KC9A/KTG4cxpQChkR1K6xJcHwk7njJLiCpGF2y3CQDLFj6NKkw M68JehOAKpiZfU4d2FSBAa0YvbmAW9KsFyuAK6xF+xs7820GlHtLTmOk5mvX+MqM4zeb vyP3HiJPlFxc98Xr6xZ5C8tpF2xfHOXqBTZzmNrKbPEpxieUSQkZdanNaZOaRq9niWk8 oncw== X-Forwarded-Encrypted: i=1; AKwUvByAOSZD+b0LZS0exE2FYVQ+5Md9SDzWaS+FYGBjICIHpqGWir8/FyJtzx39H7wMUUjrJsdODvxrJfI=@lists.xenproject.org X-Gm-Message-State: AFq9FYIGn/REHjT6TTD9xSHhuetAJOyuPVIpBD0ZoAi6OGmqA0uQ4ZZl /KZcaI0OqQMY1hVrSQjgokE1qb+Apj9vl0dzKyCIMQSQ+MhMxRZmmnKNM9IR4PeHvQ== X-Gm-Gg: AYBFou0gzlx3ykR85ODZ0PWqpOcMvNU7wCgOLb9Sw98j3hj6Q7VH8quTcIlF/rSwrYA OcGWOc2fmtS6p4IrgEuFOTWxGjqZgzTPo14x2LxeiXRWL92HiJwnfPXBMZsTwBpSQfshQuIPyVD ycIUpoZAtl70t2T659DQYI0JnIoJfK45owSS1FqkwxzxSQuwOg52cvQVaKr0OH7D6wZauAEtmeY 3Tadv8W28l5wtYiw2BXV8KsPXrslYLxyG3mJlkIVJf2w5e8ynGnd/DRrgrUz2xn+BphhD+jZ2+d 0VzxvhXwf9bPL4Hw3PDyY3gzwFEAEVYEoAW7xRoR7LgbrhCaKXKebuW2Y5tT44YzufYbPvnLZO1 qMh4FjAw+7FOJmVCIQ1TgDSv9/WCB1yyo5HTN+aAsNEJoXjhGuv5CjA3SruNRRUPS5T1NCfRyBo YfcPpfEwt4nc8TIQi6ZnWX8HmuQqaxs1JGbMcG6GBEj6naPOdz3+NvZEelKvGw29a3DkepaJ+i3 6/v+gxG974ouPRCBGbl6WwPHqCBcl00WTWd8+1gKAuQtm5oxHedHHHTq4DPUCNOUf59gzEk X-Received: by 2002:a05:600c:c113:b0:4a1:985b:83a9 with SMTP id 5b1f17b1804b1-4a1985b87f5mr113090375e9.4.1791885755870; Tue, 13 Oct 2026 03:02:35 -0700 (PDT) Message-ID: <8c0c3bbf-6365-4964-8454-ad545f76cde6@suse.com> Date: Tue, 13 Oct 2026 12:02:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/13] x86/nestedsvm: rework nested VMRUN/VMEXIT handling To: chunjie.zhu@citrix.com Cc: ross.lagerwall@citrix.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, xen-devel@lists.xenproject.org References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@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-720697/1791885756-668B42AC-AD50090D/10/78276251493 X-purgate-type: spam X-purgate-size: 930 On 10.10.2026 12:13, 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, and includes the nested > SVM / Viridian fixes the rework depends on. After having spotted the 3rd questionable patch in this series now (see below) I have to ask: What is this series aiming at? Mixing random changes and adding confusion by improper versioning, due to inclusion of patches which were previously submitted standalone, doesn't help. > Stephen Cheng (1): > x86/svm: require VMSAVEvirt for nested virt This patch was at v3 already. Now you're moving it back to v2. Before I go look further, may I please ask that the state of things be properly clarified here? And - meanwhile I have to assume almost the entire series is affected by this - where's your own S-o-b? Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:05:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:05:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446880.1662989 (Exim 4.92) (envelope-from ) id 1xGZNe-0003eI-5g; Tue, 13 Oct 2026 10:05:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446880.1662989; Tue, 13 Oct 2026 10: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 1xGZNe-0003eB-2i; Tue, 13 Oct 2026 10:05:10 +0000 Received: by outflank-mailman (input) for mailman id 1446880; Tue, 13 Oct 2026 10:05:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZNc-0003e3-8u for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:05:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZNb-00CpY5-I6 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:05:07 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace024a-bab6-0a2a0a5309dd-0a2a45018d68-30 for ; Tue, 13 Oct 2026 12:05:07 +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 6ace0253-5984-0a2a45010019-b9ff1c2394d1-3 for ; Tue, 13 Oct 2026 12: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a134b909b40008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 10:05:04 +0000 Received: from leducb.home (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 0D5E281E4A; Tue, 13 Oct 2026 12:05: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=Sscm7/evC3K0ZyjSu7Y8Q7r+/cdj7J5NOpocAaCZpEk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=eAn0ouypFx15xgwy8pfPDaxkL7xmko1SlpPvp7JockZbo2NmM7O8HlTQOSGXftYzcGROH/ugL JSJl2RKe9NDjo6IKF0vYc1RvCAwNPAjIdjp4p9WDQVsP8KdxzdbbNe4pUMwKCbRqBg4q+AHiQsE fRJ6Wipk/SN9nKgbB9TIK0EwOrYH+AvJbKa3FpC5xlxbiI1AtSfwvpY+nYJQd5/13RE0qJCTDGw IP3IPbCQ4tfwxdk/CVyJnGrwMoxJoDRC9V961UCd3dpLzjo2P+RbrHi/tlC9++R7Tz2jlBQHcjr W+p0Ec/36a8dm4ugIUIDiulEOlbwT8VArSu2zj5IdYDw== X-Zone-Loop: 57e8b0aa5b6422051607b787422c563ef0907dc23a26 x-campaign-type: default x-transaction-id: d73560c8-68fe-4811-8aed-fe4d251b0ec8 x-swg-uid: 01-3e70098e-0fef-4794-8274-1f4b46c94748 X-Mailer: Sweego Message-ID: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> x-swg-bid: 1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425 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: oleksii.kurochko@gmail.com, xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang Subject: [PATCH v6 0/4] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Tue, 13 Oct 2026 12:05:01 +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=1791885856; l=4990; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=GvAJeZiKTPE3ggOba4Ik7yxCWd6qpB3S9i96kryd1Ek=; b=Lsba4xe6Qf1+RUV15s/zfNxtwDxyE1MSOBqgxJzRBvWDYnogMO0o1eFqNcVGKKnWUQjP+VRGG tgwOKbNqV7EAcIQb1T9XEm0WQ14mudVjo/6mrlO5qm5LrYFzJSw6Ewt 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: 1791885903276 X-purgate-ID: tlsNG-d62444/1791885907-1D47D757-1C1704DC/10/78276251493 X-purgate-type: spam X-purgate-size: 4992 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: Probe the PTE A/D bits update scheme at boot 2: rework the A/D bits comment in p2m_set_pte_flags() 3: Fix A/D bits in Xen's page-table mappings 4. Use pte_is_valid() in pte_is_mapping() Test CI pipeline (uses the QTB framework to pexpect the console under various machine svade/svadu configs): https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2941839143 --- Changes since v5: - Replace "xen/riscv: always preset A/D bits in G-stage PTEs" with a boot time probe of the A/D update scheme (patch 1). It checks the result against the Svade/Svadu DT binding and records the probed scheme when the DT advertises neither, instead of trusting the DT alone. - Split the p2m_set_pte_flags() comment rework out into its own patch (patch 2). - Patches 3 and 4 unchanged and are waiting to be merged. - Link to v5: https://patch.msgid.link/1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech --- Changes since v4: - Drop patches merged upstream: ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"") - Collect trailers. - Rebase patches on top of staging. - Link to v4: https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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: xen-devel@lists.xenproject.org Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: Roger Pau Monné Cc: Stefano Stabellini Cc: Alistair Francis Cc: Connor Davis Cc: Oleksii Kurochko Cc: Zheng Zhang --- --- Baptiste Le Duc (4): xen/riscv: probe the PTE A/D bits update scheme at boot xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() xen/riscv: fix A/D bits in Xen's page-table mappings xen/riscv: use pte_is_valid() in pte_is_mapping() xen/arch/riscv/cpufeature.c | 97 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 1 + xen/arch/riscv/include/asm/page.h | 35 ++++++------ xen/arch/riscv/mm.c | 11 ++-- xen/arch/riscv/p2m.c | 42 ++++++-------- 5 files changed, 137 insertions(+), 49 deletions(-) --- base-commit: 2c40f10b9cc1864b2991612f44d2410e37d57ebe change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:07:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:07:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446886.1662999 (Exim 4.92) (envelope-from ) id 1xGZPq-0004CE-GJ; Tue, 13 Oct 2026 10:07:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446886.1662999; Tue, 13 Oct 2026 10: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 1xGZPq-0004C7-DH; Tue, 13 Oct 2026 10:07:26 +0000 Received: by outflank-mailman (input) for mailman id 1446886; Tue, 13 Oct 2026 10:07:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZPp-0004By-2L for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:07:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZPo-00EvYK-6M for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:07:24 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace02d0-e002-0a2a0a5209dd-0a2a4509b680-46 for ; Tue, 13 Oct 2026 12:07: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 6ace02db-be1a-0a2a45090019-b9ff1c229891-3 for ; Tue, 13 Oct 2026 12:07: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 1a134bb169d0008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 10:07:18 +0000 Received: from leducb.home (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 B4E2182990; Tue, 13 Oct 2026 12:07: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=8teWVWejhPLG6xNGLIN8xlYcoOyIlp83feFf6NZmWPw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=WBlOfhpQ+US+Yw2OYVZosa+rMrX0x4NaEbpAr5B+AkO/CtzZDP4bhbGiqjr+aNdW767+SqmrS /qVW8SAjAIKmGhbvMLQp5B0eunO62TL3gNY5CNaPhXVZQ+vOl76YMYWKD/LQjH+8M3aljQi/cu5 FgdaRRJhIX662qD0lg6YmVBhu1KGZGenyRrCr+1IqcfSo99RUrmo42fcGUhNyFDOYeP3Jm9gAGu T7XRhtMMhfMzJf5mSqYcC6rEwBJt2PCMd9fXRe80lInYvbHqIw/GrUOFn13sxPcMSy+/umrIX9Z RC/nkNrANpjwDmERm3qEbc/TheHVOhy3b7n18RpC8KSA== X-Zone-Loop: 711da3f44893e60fb7830ddb2da63de3298db7ec2e8f x-campaign-type: default x-transaction-id: 937a9762-1bc2-42aa-982b-644ce61b6688 x-swg-uid: 01-896914e9-55ab-4bc5-9b6c-be76e1224f87 X-Mailer: Sweego Message-ID: <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> x-swg-bid: 1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot Date: Tue, 13 Oct 2026 12:07:10 +0200 In-Reply-To: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1791885856; l=6663; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=OTMIVll/AQFPtyeJIuGVE8cRR2HbRSAUit0myRvwEDQ=; b=dqgWVqjSlntGy/q+e6qgOVUhs9UJGRQN3mt8zjil3THgpaFM0FusztA0PdX9zgSn3GOiC37Bo L1wkzmJcT/MCQWeat/GD4P199dIh6R/ekvD08hXi2dXCku1gA708Su0 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: 1791886037948 X-purgate-ID: tlsNG-bad1c0/1791886044-BDAC0034-D2CB0D37/0/0 X-purgate-type: clean X-purgate-size: 6665 p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when RISCV_ISA_EXT_svade is set, which today only reflects the device tree. Platforms that fault on clear A/D bits without advertising Svade, such as the HiFive Premier P550, then leave A/D clear and take guest-page faults that Xen does not handle. The device tree cannot be trusted alone to tell which scheme is in effect. Introduce probe_hw_ad_update(): map a scratch page through the FIX_MISC fixmap slot with a PTE whose A bit is clear, and read from it under an exception table fixup. The read succeeds if hardware updates A/D bits and faults otherwise. Introduce resolve_ad_scheme(), called from riscv_fill_hwcap(), to check the probe against what the device tree advertises, following the DT binding: - Svade and Svadu: if the probe faults, Svade applies. Warn that hardware updating can be used by dropping Svade from the device tree, or through SBI FWFT once Xen supports it. Otherwise hardware updating applies and nothing is needed. - Svadu only: firmware must have enabled hardware updating. Panic if the probe faults. - Svade only: the hart must not update A/D bits. Assert the probe faults. - Neither: record the probed scheme by setting RISCV_ISA_EXT_svadu or RISCV_ISA_EXT_svade. Add Svadu to the known ISA extensions so it can be told apart from Svade. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v5: - new patch, probe the A/D bits update scheme instead of trusting the device tree alone. --- xen/arch/riscv/cpufeature.c | 97 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 1 + 2 files changed, 98 insertions(+) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 3d5bbd2228..60e48652a6 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -20,6 +20,8 @@ #include #include +#include +#include #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -200,6 +202,7 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { RISCV_ISA_EXT_ENTRY(ssaia, ANY), RISCV_ISA_EXT_ENTRY(sstc, NONE), RISCV_ISA_EXT_ENTRY(svade, NONE), + RISCV_ISA_EXT_ENTRY(svadu, NONE), RISCV_ISA_EXT_ENTRY(svpbmt, NONE), }; @@ -620,6 +623,98 @@ static void __init compute_guest_isa(void) panic("Failed to build guest \"riscv,isa\" string\n"); } +static bool __init probe_hw_ad_update(void) +{ + bool updated = false; + unsigned int slot = FIX_MISC; + vaddr_t va = FIXMAP_ADDR(slot); + struct page_info *pg; + pte_t *entry, pte; + mfn_t mfn; + unsigned long tmp; + + pg = alloc_domheap_page(NULL, 0); + if ( !pg ) + return false; + + mfn = page_to_mfn(pg); + + arch_pmap_map(FIX_MISC, mfn); + entry = &xen_fixmap[slot]; + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE); + write_pte(entry, pte); + + flush_tlb_one_local(va); + + asm_inline volatile ( + "1: ld %[tmp], 0(%[va])\n" + " li %[updated], 1\n" + "2:\n" + ASM_EXTABLE(1b, 2b) + : [tmp] "=&r" (tmp), [updated] "+r" (updated) + : [va] "r" (va) + : "memory" ); + + arch_pmap_unmap(slot); + free_domheap_page(pg); + + return updated; +} + +/* + * The privileged spec allows exactly two schemes for the PTE A and D bits: + * 1) hardware sets them on access and on write. + * 2) accessing a page whose A and/or D bit is clear raises a page fault, + * so that software can set them (ratified as Svade). + * + * Hence an implementation without Svade uses the hardware scheme (1), and one + * that faults on clear A/D bits implements Svade, whether or not it says so. + * + * Svadu isn't itself a scheme: it adds menvcfg.ADUE, selecting between the + * two for S-mode and G-stage translation, and henvcfg.ADUE, doing the same + * for VS-stage translation (read-only zero when menvcfg.ADUE is zero). + * + * Rather than trusting the DTS alone, probe the scheme in effect with a read + * through a PTE whose A bit is clear, and check it against what the DTS + * advertises, as described by the DT binding. Panic on a mismatch Xen cannot + * run with, and record the probed scheme when the DTS advertises neither. + */ +static void __init 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); + bool has_hw_update = probe_hw_ad_update(); + + /* Both advertised: Svade applies until FWFT enables hardware updating. */ + if ( svade && svadu ) + { + if ( !has_hw_update ) + printk(XENLOG_WARNING + "Svade and Svadu are both advertised, but software updates A/D bits. " + "To use hardware updating, drop Svade from the DTS or use FWFT (not implemented yet)\n"); + return; + } + + /* Only Svadu advertised: firmware must have enabled hardware updating. */ + if ( svadu ) + { + if ( !has_hw_update ) + panic("Svadu is advertised but A/D bits are not updated by hardware\n"); + return; + } + + /* Only Svade advertised: the hart must not update A/D bits. */ + if ( svade ) + { + ASSERT(!has_hw_update); + return; + } + + /* Neither advertised: trust the probe. */ + __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, + riscv_isa); +} + void init_guest_isa(struct domain *d) { d->arch.isa = guest_isa; @@ -674,6 +769,8 @@ void __init riscv_fill_hwcap(void) "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " "wire up this platform's pause equivalent in cpu_relax()\n"); + 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 2973eb13a5..6fb8ad4b9c 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -42,6 +42,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 }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:07:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:07:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446887.1663008 (Exim 4.92) (envelope-from ) id 1xGZPt-0004PX-Nc; Tue, 13 Oct 2026 10:07:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446887.1663008; Tue, 13 Oct 2026 10:07: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 1xGZPt-0004PO-Ko; Tue, 13 Oct 2026 10:07:29 +0000 Received: by outflank-mailman (input) for mailman id 1446887; Tue, 13 Oct 2026 10:07:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZPs-0004Os-Rs for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:07:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZPs-009Aaq-8H for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:07:28 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace02e0-bab6-0a2a0a5309dd-0a2a4509b6f6-0 for ; Tue, 13 Oct 2026 12:07:28 +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 6ace02db-be1a-0a2a45090019-b9ff1c229891-4 for ; Tue, 13 Oct 2026 12:07: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a134bb17e50008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 10:07:19 +0000 Received: from leducb.home (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 5ADCD829EF; Tue, 13 Oct 2026 12:07: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: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=pN68Pey1130RdZLakyTwj+bcfE8E3n1QCjuI9IdiXPs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=j89Lo38WLQx9ytfDVqHF8grhDVyGtuDCDraKjZuFVJ6Fkk06tVuuMg1qT3VLTbdeKAFnxuQbZ 9geEom6ZWlZdyM7hPQ3EcC4pJYDWb6DplE6rHo9d9Yy8Jc8h0v0bwdrxqWTqv9D+QUmiqCQCvS5 3SFVqsYsb0DkPQM5rupylDAzQ2YmJN8x45l55KlaSSXR2NAkkJ0FEnCDbH5gduF5V3nLBfG5zgK qDBfrR0dbKDfRmF3KgQ8psOnM6a8xY7Emy507FlwWwtS3ISY3+uaemV1RMMIUaX5enAR9LFCmhY gwETG60tdJkgRBQld3NTJ0ruJrociMUejDD8YHYwBFkw== X-Zone-Loop: 171204e8908826c6893b23eb59e653f24e0edb637fd7 x-campaign-type: default x-transaction-id: b57b6a65-c326-4763-91bd-d423aaa69419 x-swg-uid: 01-5fd61160-5f77-427a-9f39-a4a559b14c97 X-Mailer: Sweego Message-ID: <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb17e50008425@vates.tech> x-swg-bid: 1791886039.8631fc262581453bbf619ec5b2062170.1a134bb17e50008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v6 2/4] xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() Date: Tue, 13 Oct 2026 12:07:11 +0200 In-Reply-To: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1791885856; l=4274; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=N7vS901esIjgCTP/Wrafpr20c991cunLT9Cp2otKlx0=; b=zCJI1wJWeLlTAGGTBKPedAwB/+h033hjox509aalCEBBYTx6rlkPBe3Mz18aWbfKLqBitw4Tf lHieXAyKsLPADaVa7ahkdL5OmGrSS00xK4LiGGndRpsSDgyPiyTAfRi 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: 1791886038569 X-purgate-ID: tlsNG-bad1c0/1791886048-FD86F034-8F5A8C6F/0/0 X-purgate-type: clean X-purgate-size: 4276 The comment in p2m_set_pte_flags() quotes the spec at length to describe the two A/D bits schemes, and its TODO mixes two things: why A/D are preset today (OpenSBI delegates the resulting page faults to a lower privilege mode, so Xen would take them with no handler) and what remains to be done. Summarise the two schemes as a short list. The reason for presetting A/D is not future work, so move it out of the TODO, next to the schemes. The TODO now keeps only the later work, handling these page faults instead of presetting A/D, which only concerns Svade as A/D page faults cannot happen otherwise. No functional change. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v5: - new patch, split out of "xen/riscv: always preset A/D bits in G-stage PTEs". --- xen/arch/riscv/p2m.c | 42 ++++++++++++++++-------------------------- 1 file changed, 16 insertions(+), 26 deletions(-) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 3d195294d5..b32472538e 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -591,35 +591,25 @@ static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) 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. + * A RISC-V implementation can either: + * 1) Update the 'A' and 'D' PTE bits in hardware. + * 2) Generate a page fault when 'A' and/or 'D' is clear, so that + * software can set them. * - * 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. + * (1) needs nothing more as it is handled by hardware. For (2), set 'A' + * and 'D' up front: OpenSBI delegates such page faults to a lower + * privilege mode, so they would be raised in Xen, which has no handler + * for them. * - * 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. + * TODO: Xen on RISC-V currently makes no use of the information that + * handling such page faults could provide, which would be useful + * for several use cases such as demand paging, cache-flushing + * optimizations, memory access tracking, etc. * - * 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. + * 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 the page faults that occur due to + * unset A/D bits. */ if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) e->pte |= PTE_ACCESSED | PTE_DIRTY; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:07:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:07:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446888.1663016 (Exim 4.92) (envelope-from ) id 1xGZPy-0004fN-2h; Tue, 13 Oct 2026 10:07:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446888.1663016; Tue, 13 Oct 2026 10:07: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 1xGZPx-0004fG-WD; Tue, 13 Oct 2026 10:07:34 +0000 Received: by outflank-mailman (input) for mailman id 1446888; Tue, 13 Oct 2026 10:07:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZPw-0004e9-I3 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:07:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZPv-009Aep-V8 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:07:31 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace02e2-bab6-0a2a0a5309dd-0a2a4502bb5e-10 for ; Tue, 13 Oct 2026 12:07:31 +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 6ace02e2-6ca4-0a2a45020019-b9ff1c238655-3 for ; Tue, 13 Oct 2026 12:07: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 1a134bb191b0008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 10:07:19 +0000 Received: from leducb.home (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 A8F6D82A32; Tue, 13 Oct 2026 12:07: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: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=TYcEAn0o+duldPjksK5lNbTyrPK4j1Hmo32hqY1SRSk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=VA2b1gtp2GAQWASewBEGbZPsfEe4ks3hN/NQXUHSzQup8lf4v0mhld7NlXG6U0QV+3C+SZr00 M10uizGSCR+zNlGj4NWlK63XsjiEozNhnGCkzr6btSijVirGLvSzelONLmDhirkf+3RXvPLM5cX g0ZT5VBDrpc5qfA7TDRZOTQtwfoufhdpKhBqBHsEz/QbHfpnNWyaJXkgMboanS/fgTbxlqiqQWV pZocUzWBP2z4KCfvzT7plZnR5PL1TXduc4MBZBaHGMufXaDFy/j0aTPVPVlUpXuvK2yvDP4NtZC UwsAjUsrlfD4jRI/QQlLBN/gdlu+j/dtFIQNRF15WwqQ== X-Zone-Loop: 722c9c76425bc8b00d376c4d17e734fb70d517433e60 x-campaign-type: default x-transaction-id: eee22e5f-b357-4705-83e2-143bf6c162aa x-swg-uid: 01-c900d9ae-357d-4f84-813f-5b00ff797ed5 X-Mailer: Sweego Message-ID: <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425@vates.tech> x-swg-bid: 1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v6 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings Date: Tue, 13 Oct 2026 12:07:12 +0200 In-Reply-To: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1791885856; l=7701; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Jrbvgl2ZleNh0b6oBc9NXBIKurYx2aHFGmESflVTzm4=; b=K2KCJ8ZvBka/XXVcZwJ6WwUlg89W8hgF1rfaKnGarh5pDSN7zxMGHxAzI6Taor5+19jHoob+p 4x5ienbd/1BBjA7l46J7Hp9hrOOI8hDZ+Wzn4fWI5WQe0blc/kbx/cx 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: 1791886038889 X-purgate-ID: tlsNG-720697/1791886051-31BC82AC-E4839CFC/10/73395122804 X-purgate-type: spam X-purgate-size: 7703 Xen does not handle page faults caused by clear A/D bits, so it presets them when creating PTEs. pt_update_entry() does so, but three places build leaf PTEs directly without going through it: setup_initial_mapping() (the boot page tables), check_pgtbl_mode_support() (the temporary root entry used to probe SATP mode support) and arch_pmap_map() (the fixmap). Without Svadu, all three fault on first access. For check_pgtbl_mode_support(), the fault is raised by the instruction fetch right after the SATP write, before any trap handler is set. Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in all cases for consistency with pt_update_entry() which sets it at runtime. 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 check_pgtbl_mode_support() to use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also carries A and D, a reserved PTE with A or D set would no longer be caught. Mask with the V, R and W bits explicitly instead, and factor the check out into pte_has_reserved_rwx(). Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko --- Changes since v5: - no changes, already reviewed and waiting to be merged. --- Changes since v4: - rebase on top of staging. - add a missing changes line in "Changes since v3". --- Changes since v3: - rebase patch 2/6 which modified wrong indentation. - change commit message to address review comments. - rename pte_is_reserved() to pte_has_reserved_rwx() --- Changes since v2: - add fixes commit ref. - add A/D bits to PAGE_HYPERVISOR_RO and derive PAGE_HYPERVISOR_RW/RX from it for consistency with runtime. - introduce pte_is_reserved() to factor out the reserved-encoding assert shared by pte_is_table() and pte_is_mapping(). - reword commit title --- 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 | 33 +++++++++++++++++---------------- xen/arch/riscv/mm.c | 11 +++++------ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index b465a90325..8a3e3e1e66 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -46,12 +46,12 @@ #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 | PTE_DIRTY) +#define PAGE_HYPERVISOR_RW (PAGE_HYPERVISOR_RO | PTE_WRITABLE) +#define PAGE_HYPERVISOR_RX (PAGE_HYPERVISOR_RO | PTE_EXECUTABLE) #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW /* @@ -161,31 +161,32 @@ static inline bool pte_is_valid(pte_t p) * X W R Meaning * 0 0 0 Pointer to next level of page table. * 0 0 1 Read-only page. - * 0 1 0 Reserved for future use. + * 0 1 0 Reserved for future use. [1] * 0 1 1 Read-write page. * 1 0 0 Execute-only page. * 1 0 1 Read-execute page. - * 1 1 0 Reserved for future use. + * 1 1 0 Reserved for future use. [2] * 1 1 1 Read-write-execute page. + * + * So if V=1 and W=1 then R also needs to be 1 as R = 0 is reserved for + * future use ([1], [2]). */ +static inline bool pte_has_reserved_rwx(pte_t p) +{ + return (p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) == + (PTE_VALID | PTE_WRITABLE); +} + 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(!pte_has_reserved_rwx(p)); return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID); } static inline bool pte_is_mapping(pte_t p) { - /* See pte_is_table() */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); + ASSERT(!pte_has_reserved_rwx(p)); 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 06f0406781..6f7dcd10b2 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -140,19 +140,18 @@ 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 pte_flags = PTE_LEAF_DEFAULT; + unsigned int pte_flags = PAGE_HYPERVISOR_RW; unsigned long addr = is_identity_mapping ? page_addr : virt_to_maddr(page_addr); pte_t pte_to_be_written; index = pt_index(0, page_addr); - if ( is_kernel_text(addr) || - is_kernel_inittext(addr) ) - pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) + pte_flags = PAGE_HYPERVISOR_RX; if ( is_kernel_rodata(addr) ) - pte_flags = PTE_READABLE | PTE_VALID; + pte_flags = PAGE_HYPERVISOR_RO; pte_to_be_written = paddr_to_pte(paddr, pte_flags); @@ -197,7 +196,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 Tue Oct 13 10:07:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:07:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446889.1663026 (Exim 4.92) (envelope-from ) id 1xGZQ0-0004up-BH; Tue, 13 Oct 2026 10:07:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446889.1663026; Tue, 13 Oct 2026 10:07: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 1xGZQ0-0004uZ-73; Tue, 13 Oct 2026 10:07:36 +0000 Received: by outflank-mailman (input) for mailman id 1446889; Tue, 13 Oct 2026 10:07:35 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZPz-0004pp-08 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:07:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZPy-009Aep-DA for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:07:34 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace02e2-bab6-0a2a0a5309dd-0a2a4502bb5e-28 for ; Tue, 13 Oct 2026 12:07:34 +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 6ace02e2-6ca4-0a2a45020019-b9ff1c238655-4 for ; Tue, 13 Oct 2026 12:07: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 1a134bb1a5b0008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 10:07:19 +0000 Received: from leducb.home (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 0341382990; Tue, 13 Oct 2026 12:07: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=5k7rt7koC4EV6CBmJQy3vnSMBgJHJLR/LUoGlfSBZyY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=jejmvJUPEDXqSCqrXPnlrfk9mPJk3KkOu4EGLjC5R8B077du9l3eKCsBS544a2sZBCUd7RH5e +cmfV8Xivut5t4NixJEziBOcATPnG+WRu+JV7DewkXE50WVrK+/94R5Wv8H7fxAgJQEk3DYk8I0 /X5fx29zqwSDRtEieWprB+sgaX/+QLzYaEJXxRxDneqrrFBOQM2I9AD48kW6AIVObzOLMw+WKSU 1CApmkupUfyKLE1mqmQZpY5FquwWlgXdrNqPpdlFYseuTKOH3z7Zi8uI+x7Dad50MWhRXmzUSKp 8MwCF12eZAhVyYdB+Y/ksCgj0+55eER5efMiR9EbUhbg== X-Zone-Loop: 1454c97216d3762ddaf79e6c6f693902a6d250f273eb x-campaign-type: default x-transaction-id: c70b2fee-9137-4e96-82b4-6ef1353cdc59 x-swg-uid: 01-65d51739-90a1-48ed-b085-48277a2b67d7 X-Mailer: Sweego Message-ID: <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb1a5b0008425@vates.tech> x-swg-bid: 1791886039.8631fc262581453bbf619ec5b2062170.1a134bb1a5b0008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v6 4/4] xen/riscv: use pte_is_valid() in pte_is_mapping() Date: Tue, 13 Oct 2026 12:07:13 +0200 In-Reply-To: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1791885856; l=1099; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Af/b9/pAf+eE4YvnmAH7fU3eq2R32LznKCQUe6Hiujw=; b=/uJEAa5iz79LK6RIBI68GDyEmvaDK7mfdn4I6/G2NbPF/FIZY426IdCG8Ks3wDghrVOL4Tfka VDXe0AUaihOCcirYp0uYgPX0CLzXOSG2SxCvyrQO72GaZGWwaWQBEfN 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: 1791886039210 X-purgate-ID: tlsNG-720697/1791886054-303C42AC-1C26280A/10/73395122804 X-purgate-type: spam X-purgate-size: 1101 Use pte_is_valid() instead of open-coding the PTE_VALID check. No functional change. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko --- Changes since v5: - no changes, already reviewed and waiting to be merged. --- Changes since v4: - rebase on top of staging. --- Changes since v3: - no changes. - add trailers. --- Changes since v2: - new patch. --- xen/arch/riscv/include/asm/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index 8a3e3e1e66..f9e59e61de 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -188,7 +188,7 @@ static inline bool pte_is_mapping(pte_t p) { ASSERT(!pte_has_reserved_rwx(p)); - return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); + return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); } static inline bool pte_is_superpage(pte_t p, unsigned int level) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:08:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:08:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446906.1663035 (Exim 4.92) (envelope-from ) id 1xGZRF-0006ML-Jk; Tue, 13 Oct 2026 10:08:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446906.1663035; Tue, 13 Oct 2026 10: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 1xGZRF-0006ME-Gp; Tue, 13 Oct 2026 10:08:53 +0000 Received: by outflank-mailman (input) for mailman id 1446906; Tue, 13 Oct 2026 10:08:52 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZRE-0006M6-8e for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:08:52 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGZRD-00000003Ksh-3PFF; Tue, 13 Oct 2026 10:08: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.98.2) (envelope-from ) id 1xGZRC-0000000AxZ4-3Tbo; Tue, 13 Oct 2026 10:08: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=EJ7wNjl4IBOa/oa0kfVKJ9Mqxz/Lly+NqGFPA74zNFM=; b=m2GK7ACfa+nsu5z0lyT88uacCD XtVAI/yP/J6rxWHU/MNng3Bamg6v89/Wq5APYYNEWFaPJaRqM8r8tVGAWu8IpZsql5SqjWrCGLBvc QzM+iOsTSI+6RwLjwYkFyHQpZ1oQ5h/CZNJc1e+V8vOHYK+EhHbJQxHF4+N9yRlGmPFU=; Date: Tue, 13 Oct 2026 12:08:42 +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/2] x86: constify local variables in mapcache_current_vcpu() Message-ID: References: <942facb0-c42b-4f09-9081-6cfb006c7bfc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Oct 13, 2026 at 11:05:44AM +0200, Jan Beulich wrote: > As of the referenced commit v won't be returned from the function anymore. > Yet that was the sole reason for it to not be pointer-to-const. curr, > which was introduced by that change, had no reason to be pointer-to-non- > const from the start. > > Amends: 622c9a5ba95d ("x86/mm: accurately track which vCPU page-tables are loaded") I think I recall how this ended the way it is: initially I was returning v, which was wrong because this_cpu(pgtable_vcpu) will have changed after the sync_local_execstate(). Later I adjusted the return value of the function to be this_cpu(pgtable_vcpu), but didn't made v const. > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > I was heavily tempted to also replace the smp_processor_id() at this > occasion (by curr->processor). With gcc16, that leads to the function > actually being inlined (in debug builds), i.e. a significant change in > generated code, and a measurable increase in code size. From the function > being declared "inline", that looks to have been the intention, yet then > that use of "inline" doesn't quite fit our principles. The main reasoning > for this as a secondary change would be: > - "curr" could be dropped (instead of having const added) if code > generated from ASSERT() wouldn't matter quality-wise, > - if generated code quality matters there, then the unnecessary use of > smp_processor_id() should matter, too. > However, an adjustment along these lines may better fit in a subsequent > change dealing with the repeated this_cpu() here. We might want to introduce a local cpu variable to hold curr->processor and then replace the this_cpu() with per_cpu(), together with removing the usage of smp_processor_id(). Shouldn't make the code more complicated IMO. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:12:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:12:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446919.1663043 (Exim 4.92) (envelope-from ) id 1xGZUc-00086H-2I; Tue, 13 Oct 2026 10:12:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446919.1663043; Tue, 13 Oct 2026 10: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 1xGZUb-00086A-VL; Tue, 13 Oct 2026 10:12:21 +0000 Received: by outflank-mailman (input) for mailman id 1446919; Tue, 13 Oct 2026 10:12:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZUa-000864-Cn for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:12:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZUZ-00HX1u-MR for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:12:19 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace03f4-bab6-0a2a0a5309dd-0a2a4505d850-38 for ; Tue, 13 Oct 2026 12:12:19 +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 6ace0403-4cb1-0a2a45050019-d155dd2be022-3 for ; Tue, 13 Oct 2026 12:12:19 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-48b001cd92bso1588687f8f.2 for ; Tue, 13 Oct 2026 03:12: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-48de0aaaa05sm3781551f8f.13.2026.10.13.03.12.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 03: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: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=1791886339; x=1792491139; 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=SOjpexEo/oEBsbXX+5V+KgbMtvjSKZ+/MBlYvc5Beks=; b=eSndy2VtaSNOe11mL5c4uGpIwMscLRpsOl3avjMUZnK38QCBu9w4x23Dvn725tR5Gu VswSWgpGGCgEH4QLAPCFeh5wMVGWNoEylxtJ54F/OrNZBY//He+01+BNmH9VoJ8YTXyO 4JfeA3RzIHkY7tpBEARQeryk9wgT5Mbngu8sqOUaukz5+jX0xhKoMajORU4BSACOXm2g SBcqwMTAA6yHA50e53ZVJUgkk2i3e0cA4qh9HJmpLz7chinLrW3J9umDWCUapSJxrdnA wxm5csz9+nzCottL70O2TYV53Qrq22f7fj4fow1ofvOXQdq/D+XpRZxgBJLToRW5i8V2 X2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791886339; x=1792491139; 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=SOjpexEo/oEBsbXX+5V+KgbMtvjSKZ+/MBlYvc5Beks=; b=eBmrY9A0pInj+ZIZkDYCy6LGaQUNad0dTpTbXxSWdoTTTwnbYmBvKkyuZEvamQHAdN ir49aN0K4ktVAMIN+76097aAKWgBiLv12mWheFFbYYTrc42Weh+MQd2ETHsBFm5Yoium DZJpdLFAWIU7x1AloRnGq05HsOaDVDGtQGPqlZzJoHWa/JS13AHJMz4xAjUKz0lVQTeG BqF+QrikNxz1TRw6RX6l6Icpb468IcEo0a/8rA5XvuWd6YCgjlYGfxCSH5maRZCxHg80 WLxVm3ze3YtVXgH5EzEObF5C3dMt8Ez6thgRjAzJrX6TgbeW5AO9bRTjTt42Z8Jx0aKB 9uMQ== X-Forwarded-Encrypted: i=1; AKwUvBxodUJJAdjCGITgvr8pjkXqk4o2BwdIkxd/bmYLJNnFwwwp8GwmRvu4HAOjXs5XZlxDG7oxLwCnmW0=@lists.xenproject.org X-Gm-Message-State: AFq9FYLJmEb+olUX1TNyaxd4wjSRNoKWZ/kceZY6ySj886R1OoVMxwzH 3p4npE2hEgh7LiXAc30qQ4Wl33ldEYi2lYUf/MKC5D8BMXCNpKsYbd7iyHQwxxlA+A== X-Gm-Gg: AYBFou1rQwlcwez9kANe+1eCKMz7MKfGMnrSP6M26oq27BKIC0NZ4K5olaPz/mCcVvS bwA9WwECpCtmGcy3x3VWdxh9rwJng/jtzRayS5fWgHK6/qF1UGtxi3BEIOBSecbn4MfXnN9oLt7 O80CK/NRsSFAwUigVYlptnh4HA3kA1+VZiQKnD57jBe16ZVzngsTiSJyaNoG2Ku5J33fQmzGSa8 dTglay9dxOMl3c199iTfzGona9+CY9bbk15CnB+YelHDrds/QYfghtNbihFlAsNolMS/GoT0vYQ RfOC1oIBXOHkPW6M43oEfnN661LnXdVQb9nyC3WwP58226J7v90KpdCW76Vv6xXYfYqiWTuUI9Z Jb+T6eRSUcRns6J779kX19nthFWQxXXjhvj1SoKjhEIIS/ryFtDPDwJ9XY31B0TbZC8CWWDt+zj oz12OdzD99lAMjw2TaYU1I+3CX9f3RaHzWOjwYi+cQ6yYXKSdbVEwYO/8u6wbZ79Wf4DLYQudoQ DhGOkT/0agv86gUKJINXYGViKSAEt9ej/61mEa++myiVRBRaoRZy1IR16TZ5Q== X-Received: by 2002:a05:6000:298d:20b0:48a:f404:6960 with SMTP id ffacd0b85a97d-48dbaadbf75mr17234787f8f.9.1791886339001; Tue, 13 Oct 2026 03:12:19 -0700 (PDT) Message-ID: <7fe17e71-24b3-4a9b-bc1d-1ad73bc156df@suse.com> Date: Tue, 13 Oct 2026 12:12:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/13] nestedsvm: Fix CR3 MBZ check To: chunjie.zhu@citrix.com, ross.lagerwall@citrix.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, xen-devel@lists.xenproject.org References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> <56d1229d7efc8da215272a7f03dade9e293652b7.1791625578.git.chunjie.zhu@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: <56d1229d7efc8da215272a7f03dade9e293652b7.1791625578.git.chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791886339-722AB2A1-CC89B5B1/10/78276251493 X-purgate-type: spam X-purgate-size: 911 On 10.10.2026 12:13, chunjie.zhu@citrix.com wrote: > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -354,10 +354,8 @@ 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))) ) > + ((efer & EFER_LMA) && > + (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) ) > PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3); > > valid = hvm_cr4_guest_valid_bits(v->domain); While Ross replied to Andrew's question [1], imo that should have led to commentary being added here. Jan [1] https://lists.xen.org/archives/html/xen-devel/2026-05/msg01369.html From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:15:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:15:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446926.1663052 (Exim 4.92) (envelope-from ) id 1xGZXT-0000Dc-Gv; Tue, 13 Oct 2026 10:15:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446926.1663052; Tue, 13 Oct 2026 10: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 1xGZXT-0000DV-EL; Tue, 13 Oct 2026 10:15:19 +0000 Received: by outflank-mailman (input) for mailman id 1446926; Tue, 13 Oct 2026 10:15:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZXS-0000DP-2k for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:15:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZXQ-007QAL-S2 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:15:16 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace04ad-bab6-0a2a0a5309dd-0a2a45099286-34 for ; Tue, 13 Oct 2026 12:15:16 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace04b4-be1a-0a2a45090019-d155dd29d885-3 for ; Tue, 13 Oct 2026 12:15:16 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48c4649b3aaso1692601f8f.2 for ; Tue, 13 Oct 2026 03:15: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-48de0bd1843sm4348125f8f.56.2026.10.13.03.15.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 03:15: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=1791886516; x=1792491316; 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=VFLOUoM6CJfDZd3355UbFK/8c2q4q7/qRFAfODAgJ+I=; b=cNQzaXXIFHcVHle+8GXJROBFTEjIbhyw8TFjxJeat7u9xDog2k27jolBdsWsTNFUP2 6wk9m9oQorFQdSnc9faJFz+IUAoTpPG9JX1m4PkfoP61j+9lhRZAJz9PVxzno2g5fQS7 Ufb1I0FE2xTonglQp5Xma8OLja5wajLe+UOWvlv5xvRLRQqPpDYR+Aw8peFEi59K2z6W SGE6yJTUR/PAwDo4y3RS2PodfNHcYnsJkwTnopAMQTSDPmbIPgLHPmOuNXbYJe50VEAD eJkXjospgTxIJ5GvAvPcAb7UHIaSApCLe8MvAMreoQHkK1wrs0cd2EjRYJGecvpPY7V6 jPZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791886516; x=1792491316; 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=VFLOUoM6CJfDZd3355UbFK/8c2q4q7/qRFAfODAgJ+I=; b=fYTga29PtqSvUcrT3a4U7/H3n3epog5qCngplG4/b+yzX5XmMmBS0hfTE/dmu/kpED ZJlCwJ5pbDTLYjQTAd+ihZFBM274ydTram1GX2bFaEVzmUPDH0nTQfTtT0cp3bTCCman 2ScmwQpExCyZjEKhzzlIFPv9nHhKtyjARpO6H/sjyCwJHamXLOFRSQw8kHcFNuiUam5I JmquP0LwS80w+hD6rxgFZ1nuKkqOmjaTiEYTJLRzRlN7b2u90Mu7bPwAoYjUeAL+h/Ss j0raVDLLaCjDSjoBb5y4d9TXNF092Sl3i8wj3R/zws+SAD8TRiWPjcNuxT2qqkvy6/Ds 1dHw== X-Forwarded-Encrypted: i=1; AKwUvBw2LWdKgZ1y+f5XzpdJ5fQjNcR6+8q2JU/DCrxspCy0Up+PIz2z0ELutZ7PzjFQY49qI6rXV2vAtDo=@lists.xenproject.org X-Gm-Message-State: AFq9FYKXf0y5KgktnNp+OMboZ091renDU7ZNc2Ol4jqTHtGV7YhFvPXc 9hfQgLdEFPHKZF7kGCP5OAw4men5b9spQ7amJvfe6EtW04okpW9VaT3bhiPAQ3L9Fg== X-Gm-Gg: AYBFou3GFhykXeuV/r056MxaqTlNzlDGr+/SYM2gBKyXy9WD/HjCs/GDK8hkMHuo7o9 FKyQv/xVVOKqKlYSdIR9HxtXac+tGnep8JZTlNjpIyH1vXUsTNpStKlmV+zv5y0p/q6978PYq0Q J/TAuUBqj0xlPIrZHNXfbOV/NMEl4cTKalnvHp3EseFPPGwKreiAPh46+fTsXd7VWddc5LqFHGM cU8DdWyqiD9oMIveDZ3680EjMhP1zTtchvWVy8eJROUeU4SpvD2w/F5tcwiZ9MrokyQNsWgpH3q maXqV/G7QhVuZQ2eF0Jz3K2EZw1nSP0kzp51Aio3glk9u426599Zn5horW1K/Cp3JIIQQhzwajW V1s/A1sUKArp7DyCWgrdJSpMEdDkh6ZfQF1DH5VZ8JEkwmT6JWT5pEJsxTBdafx42JVmGEEF9Ne vIZHzywEtegYm/kwG7NuiIhMwUQvq1lbmTyqp3ssi2GU9XjDwqJpmklm9JLXyGJEpAnEzbjQwi7 eK322o6tDyRtdsrnDORataM0zX+SizV/3qnKvI0Sp8cubfqwMLglUfu8JUrag== X-Received: by 2002:a05:6000:4288:b0:488:6ed9:b11d with SMTP id ffacd0b85a97d-48dbacf554cmr22077884f8f.52.1791886516131; Tue, 13 Oct 2026 03:15:16 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 12:15:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/13] nestedsvm: Adjust L2's DR intercept when adjusting L1 To: chunjie.zhu@citrix.com, ross.lagerwall@citrix.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, stephen.cheng@citrix.com, lin.liu01@citrix.com, xen-devel@lists.xenproject.org References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> <9b6e4ec9a5fd34db2071adcf8e73b0c50a1528aa.1791625578.git.chunjie.zhu@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: <9b6e4ec9a5fd34db2071adcf8e73b0c50a1528aa.1791625578.git.chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791886516-BC6CA034-40DA2FAD/10/78276251493 X-purgate-type: spam X-purgate-size: 1257 On 10.10.2026 12:13, chunjie.zhu@citrix.com wrote: > From: Ross Lagerwall > > If L2 accesses a debug register (like reading DR7) without L1 intercepting > it, it locks up the vCPU. L0 intercepts VMEXIT_DR7_READ, which disables > the intercept for L1 and then restarts L2 which re-executes the > instruction and then this repeats indefinitely. > > Disable the intercept for the current VMCB if in guest mode to reflect > what would happen if the VMCB were recreated via > nsvm_vmcb_prepare4vmrun(). > > Fixes: a59a7be91b61 ("nestedsvm: fix DRn handling") > Signed-off-by: Ross Lagerwall Andrew's comment [1] was left unaddressed. Comments on earlier versions should be dealt with, one way or another, before re-submitting. Jan > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1657,6 +1657,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( From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:15:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:15:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446927.1663062 (Exim 4.92) (envelope-from ) id 1xGZXf-0000UN-Nm; Tue, 13 Oct 2026 10:15:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446927.1663062; Tue, 13 Oct 2026 10: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 1xGZXf-0000UG-LC; Tue, 13 Oct 2026 10:15:31 +0000 Received: by outflank-mailman (input) for mailman id 1446927; Tue, 13 Oct 2026 10:15:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZXe-0000Tb-KY for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:15:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGZXe-00000003L1H-1OJL; Tue, 13 Oct 2026 10:15: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.98.2) (envelope-from ) id 1xGZXd-0000000BBKI-1RyE; Tue, 13 Oct 2026 10:15: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=NjfaseW22rn6/mrzlpo9xWsmsB4ZykF4RI68Y3e3So8=; b=lb21lDmE8IrXmk004Oi+yJ7WMB 8nU9uSipTzBwhN/gfYeLJSPUJo/0jFQVAyb0Tjt1Hq//zC+7TWuGMYJocFcxh6tSt96hS5UckbbZS R05hM+grPjW0rxAndUpzhmZq/OfgNk1rDt67m3gu+THCb6RIUpLj+rvanbcgnQlORcTg=; Date: Tue, 13 Oct 2026 12:15:27 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 2/2] x86: replace this_cpu() uses in mapcache_current_vcpu() Message-ID: References: <942facb0-c42b-4f09-9081-6cfb006c7bfc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Tue, Oct 13, 2026 at 11:06:27AM +0200, Jan Beulich wrote: > We have accumulated three of them, plus a hidden similar 4th construct > from smp_processor_id(). Latch the result of the latter into a local > variable and use the slightly more efficient per_cpu() instead. > > Signed-off-by: Jan Beulich Oh, so that's kind of what I've suggested in the previous patch. > --- > A 5th such construct is "current", yet to replace that we'd need to open- > code both it (i.e. get_current()) and then also smp_processor_id(). I > wasn't quite sure whether that would be deemed acceptable. See below, we can reorder and use the processor ID value stashed in current? > Like indicated in the earlier patch, this similarly leads to the function > actually being inlined (and hence generated code size actually growing) in > gcc16 debug builds. In release builds (with older gcc) the function is > being inlined no matter what. Overall, having looked at generated code > differences, I'm not quite sure anymore whether the earlier observed > inefficiency with repeated this_cpu() really is much of an issue (here or > maybe even more generally). I think we sometimes focus too much on this kind of micro-optimizations when the cost of the operation itself is orders of magnitude bigger than any performance difference the optimization might cause. In this case I don't think the resulting code is bad or harder to read, so I don't mind adjusting the logic. But that's a question of taste, if someone else has a preference for the original form I wouldn't change it. > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -20,7 +20,8 @@ > > static inline struct vcpu *mapcache_current_vcpu(void) > { > - const struct vcpu *v = this_cpu(pgtable_vcpu); > + unsigned int cpu = smp_processor_id(); > + const struct vcpu *v = per_cpu(pgtable_vcpu, cpu); > const struct vcpu *curr = current; Maybe you can reorder the variables here: const struct vcpu *curr = current; unsigned int cpu = curr->processor; const struct vcpu *v = per_cpu(pgtable_vcpu, cpu); So that we avoid two smp_processor_id() calls (ie: the hidden one in current). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:22:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:22:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446941.1663070 (Exim 4.92) (envelope-from ) id 1xGZec-0002kV-Du; Tue, 13 Oct 2026 10:22:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446941.1663070; Tue, 13 Oct 2026 10: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 1xGZec-0002kO-B6; Tue, 13 Oct 2026 10:22:42 +0000 Received: by outflank-mailman (input) for mailman id 1446941; Tue, 13 Oct 2026 10:22:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZeb-0002kI-BC for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:22:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZea-009DtT-Nw for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:22:40 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace066f-bab6-0a2a0a5309dd-0a2a450a8410-6 for ; Tue, 13 Oct 2026 12:22:40 +0200 Received: from [52.101.83.82] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace0670-f2d2-0a2a450a0019-34655352d1f9-3 for ; Tue, 13 Oct 2026 12:22:40 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by GV2PR03MB11212.eurprd03.prod.outlook.com (2603:10a6:150:301::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 10:22:35 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.011; Tue, 13 Oct 2026 10:22: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=LP5YT+LY/TlxlGnDvW4TIegZ6Me7DQ1+dxKPzd5bwyC1ovthYhrQvor8nO1rFItPZ1jzaQWi10dOWC+nELL7ALSDce+ht3qVO+RFHFG9txRiBkIXENw784bEw0ouzCyElAB7FK9p1o4krB639Lq/WGpSVwgD6mq1LNCEgzzZJJ0hEWBMrm8hhymSHGJxVpj2zL6CnOizRGSD6id6MgS0YxIzqn4bUlZXq2nNytJSrjfhUapHOn70PTN1qCK29Dp6UlFHiwLybRlcy2lF/dPLrkWyETlhi6F61jTMWonyWag6HV/TSp1ETBaEcmtoUlrHIaxFumegAsgChHMMWiuEzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rk7XfF5vyuKqzJnWuw8EkW1cQgLzwf8lHA1FdW5LCrw=; b=Q8SO5Qyx0w1GwnaGWPRJ9zaaPyj5HMWjd5nRj6zgqxM3XmVtdIC4QY6V4700wTse1QIlGyw9tLf1vf8qG7bc4JyX5KEnr60NUpKeWq+wbP/qo2tXgxsezmcs2FNnTqC0dRwQI2dnvs9yNyjsnRocJ+qeoTMCIw8Qc5M4U4pKHRTJ5Ah8+GIhsvSSgyrfpq5cjYkbpbouLP4BkgmRzaInNTQWi+MjjybTBNYaTmoQReXSpEUKsl5svbzgqBNpRi8lqLkKpvwAWP10kEGuOgg6tM9S40ScHgFvt2a1zEOUze3C/yVlqbDOFvV0PVyWLtqA42jPssNTTt6BZqXxJNLe4A== 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=rk7XfF5vyuKqzJnWuw8EkW1cQgLzwf8lHA1FdW5LCrw=; b=CJdpYpI/d08HXsrECOFNuXIy7oKQXmDaMzGyHKNSDn5P4+0oY18KIEgH3P6AAfWxMS/Sj+h3IPsV+hx4fhP8A4oHXEiIbSH+EgiM0U4EFvP9EbRlqf9NDaNssoJ3y2B+iGX70s82B8rCYLGFh1nOA85TW4TEH+vxTtUhgqktQjJX0qxcJD8li6+mCbPcn7PrYDvxF+XdXEPSCQBXt9j1y00116jGuSjS264JNEYnZu9XRrhnWypXi+4FjRFUCA9gG1YbDu3IoLlJ7B0TgfswjVzZ3qQcDqM60Hw1aYf8bI+Ir+WZPabNDCxb05F86rbSuwpmAestbdeboYVVPwX4QA== From: Dmytro Prokopchuk1 To: Jan Beulich CC: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2] automation/eclair: generalize the noreturn function-pointer deviation Thread-Topic: [PATCH v2] automation/eclair: generalize the noreturn function-pointer deviation Thread-Index: AQHdWuhYpZfkS0sLoEKj8O8bb8Y057b7HjgAgAAlfQA= Date: Tue, 13 Oct 2026 10:22:35 +0000 Message-ID: References: <0b68d552-1d90-48d1-bc06-76caf40e61f7@suse.com> In-Reply-To: <0b68d552-1d90-48d1-bc06-76caf40e61f7@suse.com> Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|GV2PR03MB11212:EE_ x-ms-office365-filtering-correlation-id: 02c0d847-0007-45dc-bcca-08df2913e670 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|23010399003|7416014|1800799024|376014|366016|22082099003|10067099003|18002099003|3023799007|11063799006|4143699003|38070700021|56012099006; x-microsoft-antispam-message-info: UDykJuaLRuUiW/zZipb5A7h146IvTEhYnZ4Gsp5MofndoTslxRbvWUfKYiwXKLhMEijzYH4HlAUIjI7Xt0VKubxmDtVWgqiAKlWcQGLcpneKHsIDWukPYy6/AXLujThmyCph+7QsRn6T52StMuXsqr6Ko2R28tLzM041WwMtEzbthTHYzEocah37EmmZYTm0/bN4DhGHXDRasoNI/bbOrRG0v+hFi21PhchQigLvF7lwmo6zMMhJV0AuPyYUo6FRdmthZdSZYrhuu8vpPsOHBs3mU6Lp569f6U8/6ZSxz1JM2LfrP5PxsGa3w/iq3dxrjV6XQzsFJQYfJwR0UHsb/5HGSHwrMRkNwAKvZG1P4Npu3l3jiQynPXm1Gwk3hZ66JmYRSkn5bjNRUK7h/Uzjp35tS0T/wU/xNUpp0MuFskRpTXwaW0q9ZNROMI4Cb0tKGTs8DYmkUV0a86OFDurk9Q0Q1ui5oTVqaL49tcfiJZ0ldrrGHmLrgY79jmGT22wxBVT/GYdCjH0AT2wGs6DTwz9tbgF/xKWjJr0LXg0OLKZu4RZ6hnt1U61C3/RLTjYebfNzD+67F22lHnCjI9735xfq1m1dVC6BCZtw0PW1KRKMWvJ+SVWYO9lgmCkYYg3JJP1cTTbR0LgHCaCbzn4ZDsD5/dHmKrbsA+8+Z0i8ygq1mrqcUGesKj8ocIh29Q6Sr/C48RikRu4tzrerAH8uV9mXxjRmuAoW4ytwPxBllF4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(23010399003)(7416014)(1800799024)(376014)(366016)(22082099003)(10067099003)(18002099003)(3023799007)(11063799006)(4143699003)(38070700021)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NHdENmpMdTI3bFNkMnFaaTFXbFRvOFFSaVhFT2dHS3hSb2lLdXhTSW50RFYy?= =?utf-8?B?bXRtNVpwd3k2RzQ2TmcvWHFObitDeVBrUGF0TWE3ZVNBdU4wUTlNaCttYlNp?= =?utf-8?B?SkZIVzRia0tRWE9uT1Zaam5DNHp3Tm82RzI5T2lEOUdud1M0TmtQNUZSbTc3?= =?utf-8?B?VXdXb1h2Z0hUUENTTk1CS3JteFN5QnlJVVcrcVRjR3NuaHdWVlpBdzZab3Z2?= =?utf-8?B?VkJjTkhwOXdTRVZkalIvOWJxU0FsOXJMRUxhaEd5ZDB5MDMyR0Y5QThSNXgv?= =?utf-8?B?amFaRFgzWWlKUjlzYytROFVjUVdHanhaSUcvMmVtUWE2ODV0eXZaeG13MGtT?= =?utf-8?B?Y3U1U1hHNktLNlhIR3ArZThSREM0dlRHMkZlTnRoTTVZdkczVFVWMERaRVBH?= =?utf-8?B?M2JJZDRUbzcya2ZWWjQwdDYwUCtlMHJ1NUJaTUNBUmVGeHFLbkwyUTRNMm9S?= =?utf-8?B?eitqMEhlU1I1OFhKQjNySEQ2VEhTNnFkNytNbEZuMW1MeERJclp1dFhib0lw?= =?utf-8?B?UWh3RWdsUGxoSm51Q0IvZUhrSHRWd3ZnMWx0anpZMGVrS3hZdHgxclRwN3Ny?= =?utf-8?B?T1pXVkYzNGJ1S3paRGNPaVFlZjN1WHhQRDBXNDhrSnE2M2FQRkIvazFIa2oy?= =?utf-8?B?bW4vRytUZGJua0pyNkZYakFaUi9wS3dieXNOeDEyN0xodEk5bmwxcEEvUlRS?= =?utf-8?B?QlFLaklBNHcxOW9QS1U0YTZuSDljREdodmk1VkIzMWlSMDhqVkM5YUJ3Rko4?= =?utf-8?B?RDZuRzhXWVAyaXpYYnhKdUZBRG44MkxOWWpZMVpsQnhpQ0tEUGx1b0RNRmxk?= =?utf-8?B?TFU5cUx1VTlVWS9TbUUzTHV2YlFBbnUrZ1pwYTVMM0FZT3FyS3k1R3A2bklz?= =?utf-8?B?YklWNkdxdTNEY01jYklzZ3Z2T1k1SzNzRnZyMGZjczdpQkZ4aVJKcDhVcDcx?= =?utf-8?B?cnMweXlDN29oQ1hWc1RqemwzdEpXaU1ZM05oQWx6b2lKZFpzMmwweFFvUEYr?= =?utf-8?B?Tnd0Qk1jZXJKZlBTZ3FLbUR3ZEJOaVBBb0pvRThpemdaK1BoUnM3NUQ4a3Rh?= =?utf-8?B?aTZZaFZ2V3RHSkhleEJid1hWQ0s0bStod1llL3N3elF0RFNJQ3Y2andOSDJZ?= =?utf-8?B?eXVYNnZ5UmVtY1JubGIybnpmdktvM2JEQnRPRjZ4dWdrOTl1T2pwWVI3SU54?= =?utf-8?B?eWlxcXg0Ympnbmh2QjdTU0ZsZHBsYVlXcktwN28rdzVSZUFuKzk4NVpRODFO?= =?utf-8?B?NUkybFEvVU9Rd2F1U3dJTGZOZk5KV1RmODVZSTYvbngwaEJtM1B5OWtUYTR1?= =?utf-8?B?M2Q5RzdYR3Q3VkcxdlJ1TkRSYzZyL0F3V1pERlMxVDEyQzF3M0VWdEpFZGZN?= =?utf-8?B?YzdDOGFCSS92YWduRE15Uk82MjN4bFBQK2ZRcmV4elpLdmR5L2xDQ2kwd0Ru?= =?utf-8?B?bUIvTmswTDRwK09Fc284VXhNNHZCVUxwRUdsRVltNjlVQmpoMytaN09RMlo3?= =?utf-8?B?djFPcnp2RmVkSXZLYk01VzNFWGdoa252Q1ZacG1UelU0RTFGRmtkYXBGdDA3?= =?utf-8?B?eUR1N2syK01yTkUvQWt3ZFFpVk4zUFhEaWRKZmRlZkIyWm1mL2lEQWxqbWRi?= =?utf-8?B?OGt3V0d0TFlLWXBvOFBFQUpPMzdMbWRDbDJNN0w5cUdFNmJ1a3VnOVRNbVJD?= =?utf-8?B?V2JZc1Ezc1Vwb04yOWYvY2dkbkdPZU0yM2w0YVVjRURvZ25NbCt2WXc5NHpt?= =?utf-8?B?cGFPNzEwaXFMN3MvT0ZpdEczQ3ZsNzhsaVFyTjRGM0RxQW1SVlBtRWJId2ZB?= =?utf-8?B?MVJxTnlsNmlkYjlJYlAzcDNiWGZUTmdZN2xya2t5ZnZSbXZkRHB4bEp1THJS?= =?utf-8?B?OFRmMGZGRHhYSXFnWHBtV09DYUN4VEdSRlhyQWdETTkybHVENHZYSDZ2TDBh?= =?utf-8?B?RVdmWmkxdEhhT2lEUFZzMEtTclNZckhVSEM4UjJBNmtSQTVkUnNUcnFBU2FN?= =?utf-8?B?YmZFSGR0UGFTR3JzL28wOFNFbmN2OGV1N3ZkNUJla1NsK1ZvT1E2bTFUQmh1?= =?utf-8?B?UWVocE85VW81UlA0L05YbGttNXRmdkE2bkRCYldvd0ovTlVLemE0ZDY4dXJq?= =?utf-8?B?ZGExQTZiak9RT3FTUVFjTE9xcHlHZU1NTHhYUXlxMk1MVTRVdmwvSTBVVE05?= =?utf-8?B?bUlQenJoTGJwYzg0disrYzl0WTdobkl1OFJQODhLREdOOEVtZWhiWFREYmV3?= =?utf-8?B?cWFCMXkydEFzNHAwLytDby9sOXl0WTNIdTFpN0E5TFNReURHQWJzRURrMEI1?= =?utf-8?B?SlpNaUlFR1hKek84MXYyelNmTkxoRGR4K21oY0pHRGUwdWxhL2FrYmMxS1pm?= =?utf-8?Q?riMzj0LlLTIme7FA=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02c0d847-0007-45dc-bcca-08df2913e670 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 10:22:35.6711 (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: OVf3TJuTPNviHfvy2XIsbXhNuwTbIDAx8ncJh5VGukkd5ViIagiei8R/bA7AqtN1ABt0UPj8TSWnWZKMgzsnAmCR3mwursX49pzOoJo6ToM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11212 X-purgate-ID: tlsNG-4011c0/1791886960-512C8CFC-518CC11E/0/0 X-purgate-type: clean X-purgate-size: 5026 DQoNCk9uIDEwLzEzLzI2IDExOjA4LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTMuMTAuMjAy NiAwOTo1NiwgRG15dHJvIFByb2tvcGNodWsxIHdyb3RlOg0KPj4gLS0tIGEvZG9jcy9taXNyYS9k ZXZpYXRpb25zLnJzdA0KPj4gKysrIGIvZG9jcy9taXNyYS9kZXZpYXRpb25zLnJzdA0KPj4gQEAg LTM5MiwxMCArMzkyLDEyIEBAIERldmlhdGlvbnMgcmVsYXRlZCB0byBNSVNSQSBDOjIwMTIgUnVs ZXM6DQo+PiAgICAgICAgLSBUYWdnZWQgYXMgYHNhZmVgIGZvciBFQ0xBSVIuDQo+PiAgIA0KPj4g ICAgICAqIC0gUjExLjENCj4+IC0gICAgIC0gVGhlIGNvbnZlcnNpb24gZnJvbSAndm9pZCBub3Jl dHVybiAoKikoLi4uKScgdG8gJ3ZvaWQgKCopKC4uLiknIGlzIHNhZmUNCj4+IC0gICAgICAgYmVj YXVzZSB0aGUgc2VtYW50aWNzIG9mIHRoZSAnbm9yZXR1cm4nIGF0dHJpYnV0ZSBkbyBub3QgYWx0 ZXIgdGhlIGNhbGxpbmcNCj4+IC0gICAgICAgY29udmVudGlvbiBvciBiZWhhdmlvciBvZiB0aGUg cmVzdWx0aW5nIGNvZGUsIHBhcmFtZXRlcnMgaGFuZGxpbmcgcmVtYWluDQo+PiAtICAgICAgIGNv bnNpc3RlbnQuDQo+PiArICAgICAtIFRoZSBjb252ZXJzaW9uIGZyb20gYSBub3JldHVybiBmdW5j dGlvbiBwb2ludGVyIHRvIGEgZnVuY3Rpb24gcG9pbnRlcg0KPj4gKyAgICAgICB3aXRoIGEgY29t cGF0aWJsZSBzaWduYXR1cmUgZG9lcyBub3QgYWx0ZXIgdGhlIGNhbGxpbmcgY29udmVudGlvbi4N Cj4gDQo+ICIuLi4gd2l0aCBub3JldHVybiBvbWl0dGVkIGJ1dCBhbiBvdGhlcndpc2UgY29tcGF0 aWJsZSBzaWduYXR1cmUgLi4uIg0KPiANCj4+ICsgICAgICAgVGhlIGNhbGxlZSBkb2VzIG5vdCBy ZXR1cm4sIHNvIGNvZGUgZm9sbG93aW5nIGEgY2FsbCB0aHJvdWdoIHRoZQ0KPj4gKyAgICAgICBy ZXN1bHRpbmcgcG9pbnRlciBpcyB1bnJlYWNoYWJsZS4gVGhlIGNvbXBpbGVyIG1heSBkZWxldGUg dGhhdA0KPj4gKyAgICAgICB1bnJlYWNoYWJsZSBjb2RlIHdoZW4gaXQgY2FuIHNlZSB0aGUgbm9y ZXR1cm4gY2FsbGVlLCBvciBpdCBtYXkNCj4gDQo+ICIuLi4gd2hlbiBpdCBjYW4gc2VlIHRoYXQg YWxsIG9mIHRoZSBwb3NzaWJsZSBjYWxsZWVzIGFyZSBub3JldHVybiwgLi4uIg0KPiANCj4+ICsg ICAgICAgbGVhdmUgdGhlIGNvZGUgaW4gcGxhY2UuIFhlbidzIGJlaGF2aW9yIGlzIHRoZSBzYW1l IGluIGVpdGhlciBjYXNlLg0KPj4gICAgICAgIC0gVGFnZ2VkIGFzIGBzYWZlYCBmb3IgRUNMQUlS Lg0KPiANCj4gV2hpbGUga2luZCBvZiBpbXBsaWNpdCwgc2hvdWxkIGl0IHBlcmhhcHMgYmUgbWFk ZSBleHBsaWNpdCB0aGF0IHdlIHRvbGVyYXRlDQo+IChkZXZpYXRlKSBzdWNoIGEgdmlvbGF0aW9u IG9mIHJ1bGUgMi4xPw0KDQpUbyBiZSByZXdvcmRlZCBsaWtlOg0KDQpUaGUgY29udmVyc2lvbiBm cm9tIGEgbm9yZXR1cm4gZnVuY3Rpb24gcG9pbnRlciB0byBhIGZ1bmN0aW9uIHBvaW50ZXINCndp dGggbm9yZXR1cm4gb21pdHRlZCBidXQgYW4gb3RoZXJ3aXNlIGNvbXBhdGlibGUgc2lnbmF0dXJl IGRvZXMgbm90DQphbHRlciB0aGUgY2FsbGluZyBjb252ZW50aW9uLiBUaGUgY2FsbGVlIGRvZXMg bm90IHJldHVybiwgc28gY29kZQ0KZm9sbG93aW5nIGEgY2FsbCB0aHJvdWdoIHRoZSByZXN1bHRp bmcgcG9pbnRlciBpcyB1bnJlYWNoYWJsZS4gVGhlDQpjb21waWxlciBtYXkgZGVsZXRlIHRoYXQg dW5yZWFjaGFibGUgY29kZSB3aGVuIGl0IGNhbiBzZWUgdGhhdCBhbGwNCm9mIHRoZSBwb3NzaWJs ZSBjYWxsZWVzIGFyZSBub3JldHVybiwgb3IgaXQgbWF5IGxlYXZlIHRoZSBjb2RlIGluDQpwbGFj ZS4gWGVuJ3MgYmVoYXZpb3IgaXMgdGhlIHNhbWUgaW4gZWl0aGVyIGNhc2UuIENvZGUgbGVmdCBp biBwbGFjZQ0KaXMgYSB0b2xlcmF0ZWQgdmlvbGF0aW9uIG9mIFJ1bGUgMi4xLg0KDQo+IA0KPj4g LS0tIGEvZG9jcy9taXNyYS9ydWxlcy5yc3QNCj4+ICsrKyBiL2RvY3MvbWlzcmEvcnVsZXMucnN0 DQo+PiBAQCAtNDM1LDkgKzQzNSwxMCBAQCBtYWludGFpbmVycyBpZiB5b3Ugd2FudCB0byBzdWdn ZXN0IGEgY2hhbmdlLg0KPj4gICAgICAgICAgYW5kIGFueSBvdGhlciB0eXBlDQo+PiAgICAgICAg LSBBbGwgY29udmVyc2lvbnMgdG8gaW50ZWdlciB0eXBlcyBhcmUgcGVybWl0dGVkIGlmIHRoZSBk ZXN0aW5hdGlvbg0KPj4gICAgICAgICAgdHlwZSBoYXMgZW5vdWdoIGJpdHMgdG8gaG9sZCB0aGUg ZW50aXJlIHZhbHVlLiBDb252ZXJzaW9ucyB0byBib29sDQo+PiAtICAgICAgIGFuZCB2b2lkKiBh cmUgcGVybWl0dGVkLiBDb252ZXJzaW9ucyBmcm9tICd2b2lkIG5vcmV0dXJuICgqKSguLi4pJw0K Pj4gLSAgICAgICB0byAndm9pZCAoKikoLi4uKScgYXJlIHBlcm1pdHRlZC4gQ29udmVyc2lvbnMg ZnJvbSBbdW5zaWduZWRdIGxvbmcNCj4+IC0gICAgICAgb3IgJyh2b2lkICopJyB0byBhIGZ1bmN0 aW9uIHBvaW50ZXIgYXJlIHBlcm1pdHRlZC4NCj4+ICsgICAgICAgYW5kIHZvaWQqIGFyZSBwZXJt aXR0ZWQuIENvbnZlcnNpb25zIGZyb20gYSBub3JldHVybiBmdW5jdGlvbiBwb2ludGVyDQo+IA0K PiBOaXQ6IFRha2UgdGhlIG9wcG9ydHVuaXR5IGFuZCBjb252ZXJ0IHRoZSBiYWRseSBmb3JtYXR0 ZWQgInZvaWQqIiB0byBtYXRjaA0KPiB0aGUgZm9ybWF0dGluZyBpbiB0aGUgbGFzdCBzZW50ZW5j ZT8gKEl0J3Mgbm90IHF1aXRlIGNsZWFyIHRvIG1lIHRob3VnaA0KPiB3aHkgdGhhdCBoYXMgcGFy ZW50aGVzZXM7IGl0IHdvdWxkIHNlZW0gdG8gbWUgdGhhdCBqdXN0IHRoZSBxdW90ZXMgW2FuZA0K PiB0aGUgc2VwYXJhdGluZyBibGFua10gb3VnaHQgdG8gYmUgc3VmZmljaWVudC4gTXkgbWFpbiBw b2ludCBoZXJlIG9idmlvdXNseQ0KPiBpcyB0aGF0IGFsbCBzcGVsbGluZ3Mgb2YgdGhlIHNhbWUg dGhpbmcgd291bGQgYmV0dGVyIGJlIGlkZW50aWNhbC4pDQoNCkkgd2lsbCBzcGVsbCB2b2lkKiBh cyAnKHZvaWQgKiknLg0KDQo+IA0KPj4gKyAgICAgICB0byBhIGZ1bmN0aW9uIHBvaW50ZXIgd2l0 aCBhIGNvbXBhdGlibGUgc2lnbmF0dXJlIGFyZSBwZXJtaXR0ZWQuDQo+IA0KPiBMaWtlIGFib3Zl LCBpdCBpcyBpbW8gaW1wb3J0YW50IHRvIHN0YXRlIHRoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biBib3RoDQo+IHBvaW50ZXJzIHNob3VsZCBiZSBfb25seV8gdGhlICJub3JldHVybiIuIFRoYXQn cyBsb3N0IGhlcmUsIGp1c3QgbGlrZSBpdCdzDQo+IGxvc3QgaW4gZGV2aWF0aW9ucy5yc3QuDQoN CkFuZCB0byBiZSByZXdvcmRlZCBsaWtlIGFib3ZlOg0KDQpDb252ZXJzaW9ucyBmcm9tIGEgbm9y ZXR1cm4gZnVuY3Rpb24gcG9pbnRlciB0byBhIGZ1bmN0aW9uIHBvaW50ZXIgd2l0aCANCm5vcmV0 dXJuIG9taXR0ZWQgYnV0IGFuIG90aGVyd2lzZSBjb21wYXRpYmxlIHNpZ25hdHVyZSBhcmUgcGVy bWl0dGVkLg0KDQo+IA0KPiBKYW4NCj4gDQo+PiArICAgICAgIENvbnZlcnNpb25zIGZyb20gW3Vu c2lnbmVkXSBsb25nIG9yICcodm9pZCAqKScgdG8gYSBmdW5jdGlvbiBwb2ludGVyDQo+PiArICAg ICAgIGFyZSBwZXJtaXR0ZWQuDQo+PiAgICAgICAgICBFeGFtcGxlOjoNCj4+ICAgDQo+PiAgICAg ICAgICAgICAgdW5zaWduZWQgbG9uZyBmdW5jX2FkZHIgPSAodW5zaWduZWQgbG9uZykmc29tZV9m dW5jdGlvbjsNCj4gDQoNCkRteXRyby4= From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:34:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:34:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446947.1663080 (Exim 4.92) (envelope-from ) id 1xGZpi-0004n4-De; Tue, 13 Oct 2026 10:34:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446947.1663080; Tue, 13 Oct 2026 10:34: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 1xGZpi-0004mx-AI; Tue, 13 Oct 2026 10:34:10 +0000 Received: by outflank-mailman (input) for mailman id 1446947; Tue, 13 Oct 2026 10:34:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZpg-0004mr-S8 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:34:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGZpg-00000003LIj-3y0N for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:34:08 +0000 Received: from mail-lf1-f42.google.com ([209.85.167.42]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGZpg-0000000Bliq-0p4V for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:34:08 +0000 Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5bad794b197so2910202e87.1 for ; Tue, 13 Oct 2026 03:34: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" 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=Mjvxz5NbzmCku9GWWXfGhHibEV2lIq5bV3BM5GmSTeY=; b=jH8gi1G3DIcRJFroZNLY+5sc2y x2WlyuJUdFfd9DHkZvWnsPI8eMuCDmJoph0ObYtS0OLwUSt+FS0vrfrulcJ6jQm2O7wMpJKP18vvR M2uKv1tpqjOONPH3zPy+TFlhl+8n3gYEZphWCJK3NIQ0qYhKpP0qluXwj6XLThGHW4Kg=; X-Gm-Message-State: AFq9FYKoNY3ys5J9L6YbO2IiB/OOQyCjbeGg6s1Ifkayyyim/wjab9ux FIb2l16WTlnN0YXKS1NsYt8QbUMZBX8ZyDCKKvnXThl8PHLWGuajRxXknREAh6+N9kYuF9/0qOm +bLdSA6Z9/HSeoQZ/S+kLKa9xbVNta5s= X-Received: by 2002:a05:6512:3e22:b0:5ba:36b8:ed2d with SMTP id 2adb3069b0e04-5bcde6bb70bmr4389964e87.10.1791887647289; Tue, 13 Oct 2026 03:34:07 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-11-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Tue, 13 Oct 2026 11:33:55 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-702rMXUzl7qnOKhRgGOSrmAYT9E9ReW8hll88pGFCaKSNA4hyxFaRYVI Message-ID: Subject: Re: [PATCH v3 10/18] x86/domain_page: don't unmap a mapcache entry that is not present To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 12:04=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:43AM +0100, George Dunlap wrote: > > Mappings must be torn down by the vCPU that created them, and only > > once. Have unmap_domain_page() check that the entry it is handed is > > present and bail out otherwise (ASSERT_UNREACHABLE()), rather than read > > an MFN out of an empty PTE and act on it, as a second unmap of an entry > > the first one zapped would. (A second unmap of an entry the maphash > > kept is caught, as before, only by the refcount ASSERT() in debug > > builds.) > > > > Assisted-by: Claude Code:claude-opus-5-5 > > Signed-off-by: George Dunlap > > Reviewed-by: Roger Pau Monn=C3=A9 > > > --- > > Changes in v3: > > - New in this version, split out of "x86/hvm: introduce per-vCPU > > mapcache for vCPU-PT domains" for review. > > --- > > xen/arch/x86/domain_page.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > > index f91ec8a75a..708df90a00 100644 > > --- a/xen/arch/x86/domain_page.c > > +++ b/xen/arch/x86/domain_page.c > > @@ -230,6 +230,16 @@ void unmap_domain_page(const void *ptr) > > ASSERT(cache->inuse); > > > > idx =3D PFN_DOWN(va - MAPCACHE_VIRT_START); > > + /* > > + * Mappings must be unmapped once, by the vCPU that created them. = With > > + * nothing present there is nothing to tear down: leave the hash a= nd the > > + * bitmaps alone rather than act on a stale or foreign pointer. > > The comment makes more claims that what can be checked for: there's no > check that the unmap is being done by the same vCPU that created it, > neither is easy to add one. Any mismatch like that would become more > obvious once we switch to a per-vCPU mapcache. I would possibly > reduce the comment to: > > /* Ensure the entry to unmap is populated. */ > > The commit message already have the lengthily details. The problem is that now the comment just repeats the condition of the if() statement, which an experienced developer can already read without effort; it doesn't say *why* we're doing the check. What about something like the following? /* * Sanity check: an entry that isn't present means a double or stray * unmap. Play it safe: don't act on the MFN in an empty PTE. */ Thanks, -George From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:36:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:36:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446953.1663089 (Exim 4.92) (envelope-from ) id 1xGZsF-0005Mv-T2; Tue, 13 Oct 2026 10:36:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446953.1663089; Tue, 13 Oct 2026 10:36: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 1xGZsF-0005Mo-PG; Tue, 13 Oct 2026 10:36:47 +0000 Received: by outflank-mailman (input) for mailman id 1446953; Tue, 13 Oct 2026 10:36:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZsD-0005Mi-HY for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:36:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZsC-00CaEj-Cm for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:36:44 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace09b5-8faa-0a2a0a5109dd-0a2a45098d76-10 for ; Tue, 13 Oct 2026 12:36:43 +0200 Received: from [52.101.125.110] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace09b8-be1a-0a2a45090019-34657d6e0fb3-3 for ; Tue, 13 Oct 2026 12:36:42 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TY3P286MB3732.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:3d2::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 10:36:37 +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.0522.011; Tue, 13 Oct 2026 10:36: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=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=QcYGbmoO96VmUpJFTFjA6H5tMONRxaJwN9qgi0dErZQFA6DDfPjirO0QzKt+Xrosha+4TXOFLsjIhhVdggJC4hE+u8lC6IxTB4uc317ptLTf47ensKZrRNxMFU9gNANpvMfVCVjKWnp43JUHDDGdJWxsxSnjPNYkAoGFwQLw/pQ8fJk2ZrZ+I6mAZNoUlzUtKXzCi1k8CP+V+2K7NbNzwmqqM63N6bfNbU6xNQk9IPOhkmqL0yNbbzV7X3yg1KcR3xL7+9Q3Qo5pvb21K6PGciXVAbJkLsv3qGO7djyqIILwxZ/x3+e+f8/dwGwUUNshDaJiqNdz+Y8MyJ+uEE9v7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XaL68u6SlJ4JTjioq7tV6Nt3en9lumuNxYWn57RJHxo=; b=L1LqJe3mRaoaIiGb6X93ODKT0DTF23O+jO7F9J0xjw+gRr/SlCOgwKUOnp+d66ZG5i7Av6xbe4AVuqZ/RmJWWzoSgCsNKTjaRSNKXm68gpUwlByuTR9FBZuN4MtrAd8A3Qd/AJe86sC6nspEAwg5gZx7F24VGTS69kv/dGO5w02CjHyd5hDD3ytfknGn2WFAzCI3lvZVp0Y5eKn9KFfsnWpJyJWo6cmm3d+NuxtHEb0RQ2o9kHEOIS1vWR4MLcB/gv9ni2Z66YshGYVjohmlF9Xm9F/JwjO4cbmcrLYUQD7LxmWwl2usUBqOZHCWgOmFn/131FtbdBODrz98yl63cg== 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=XaL68u6SlJ4JTjioq7tV6Nt3en9lumuNxYWn57RJHxo=; b=WTkrRboupDfPykvZM1MaJyQSszShjLXC6CKlt1ugjauqgGCT8V2CsUY776qY1DdLMz/IxjEnj9v2EFanDAwv2gwVs6Kj2aaD3e3JVI1GxvIl7YXwzI/QWw+xb2nUExLFpmJ+51Wmo2q3+jeqdqeXmY0B5+EZQ+sEZjhkP1XUims= Authentication-Results: mx.microsoft.com 1; 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 v11 0/4] xen/acpi,device-tree: Introduce generic CPU topology support for ACPI and DT Date: Tue, 13 Oct 2026 19:36:12 +0900 Message-ID: <20261013103616.121916-1-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCPR01CA0153.jpnprd01.prod.outlook.com (2603:1096:400:2b1::12) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TY3P286MB3732:EE_ X-MS-Office365-Filtering-Correlation-Id: 7f0a56c0-71d2-461f-e039-08df2915dba6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|10070799003|23010399003|366016|1800799024|56012099006|261009223027099003|10067099003|18002099003|6133799003|25016099003|29003799003|3023799007; X-Microsoft-Antispam-Message-Info: 0yyXNpKpTsyUqq1829c/lT9g1l8UUky795oW5IUQ3BVd7chDx9vfjYgn8t33hud1AoByYgzr2MgGVcWD9dqfG89meFmZrAA1xpCqegHMVOzgx30sogepGoz0zPmh3p4kDuY5yY/flGxIFUddafgG3b+v7GBvQVRXOAnr/vBW6WP/TXvwFx2wPLPMJhN0bIN2pdlxORZ6hmFL/vqSXdMmqi4K9391RyeG/ZkUEESlfdGNGsO7w+KFv7nK4B9K7XF7p/QKhD0h34bs41H/B0voxj5dw2sQzl+yDI+k+y2aZjceR/Z9yVRHhDIf7QVj2B/l1v20k0DWFotG7w5NcnObEfNq9Mu/8Ui1NmCmUqguQkKS7CLi+ulfFp1kkX/qzFT8NnULluCRlU44DFaHaIW4NHqYZN71B/2UPB8I/pg4rtUNHfYnOgYbvTKCT8e8p7STEhYQYzUnNG82TkfMk8Hn5jl+I/IbC1CoOxRm3jHHhSBXkkedmRlntrnx30irLP8bntSfyLoyhL4vxWtn0NmXFM3v1oE54wudUTXy2Qr/hFLyfSpAMuT7ZJUR8Rq3e2UDuNP8JePm4iUPJT4jAiBz9zkRVWCiEYu8tbd6kFonnQD9RmO71VNnl1hLaTcoj13RHDHvAb+Hzuq+9Eb0FF7nVtxSpO182bNszadVZzu255Q= 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)(376014)(10070799003)(23010399003)(366016)(1800799024)(56012099006)(261009223027099003)(10067099003)(18002099003)(6133799003)(25016099003)(29003799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?R8PzJMa/1qHeVfnQO0oPkGAmqG0zRUlQ4bV3eOgKUJ4SDLFgEf1nGJK0QfKX?= =?us-ascii?Q?PNTTvsvHsiR3LZQRy/GYc5W44g6AyQtG+Iahvjra18O//6R8t15HDrRa7X63?= =?us-ascii?Q?SAqEbReacO4xh9jgtezr0P9C7lG9teOqu/o9my2YFqrmaisoR5N3rdxeM0/+?= =?us-ascii?Q?3dh/3jjrgto8ijFpKkHHsyWm2AOqwq59C5xhgyisL7nVzk5DSoZHEZmByRzc?= =?us-ascii?Q?RQAtPY7opCLPRJYTMBvc3v+AXSJYPE55fTkZfk0jPFKPYYcup7fJIFW3ZPKG?= =?us-ascii?Q?rb00nfpttAbxqq/iO06myMCyAYxneuKhLFIKI1ubf/vsugYitd1WJWY4XggJ?= =?us-ascii?Q?BfwsxvclmbHF0sJ6foZ3LAcNF3ycfxePzec5SSo49sh+zBkaoHVHe5yKVqmp?= =?us-ascii?Q?I3WCFnNvAIRjgx4k6nCiSzUy0HbMqCu2sQzQKRouJxljDXDTXpTLgOZkQNKN?= =?us-ascii?Q?oRx9njSjIIqtnPT6WoAQr1Q+rrxnh4tzCNgwVpyCAQXF9KgUtG2NP/zAvoFT?= =?us-ascii?Q?mavI9bmz0ZsAERtSx6TXrPU3kLvatJyeMjX22nTQn1Nj1jtmTIS50Gm2pn2a?= =?us-ascii?Q?FxzibyeO7VaSZbxBdrXwLZ/lPJ9ij+SfPBe8cqNe1ALxLI/crPYrraiQoQhH?= =?us-ascii?Q?BjacJ5nSZA5u+f+0rNff/CAP12bp85dWye+hIxqHPiRfGHHDDz65QzXQZR6h?= =?us-ascii?Q?R5oi6URvX1fLZFssrROQVkR3ENEnURqqtvEnKPtXfjqqvhZwWAO8kDueUqOy?= =?us-ascii?Q?xlpjfgPBkYJb1PgHzebPL1DQC01tvpqMfQbMve9oL9f0BByMablSwePp0Z5t?= =?us-ascii?Q?Zd1QN/WmkUiYRLxr7eXIbDHv8t77nYOaMg87LaSIRvGuYk9ArXvEqG8DRxjF?= =?us-ascii?Q?z1ERYiLVGJdt6oCtVeeqjYLak71EW+MEoGgzfsL4h61Ice73CT9BWiT4f5cR?= =?us-ascii?Q?OD1Vk836TMtSi6jlWsl1qpOxIXx9VOgB9uFSM1jb16lWlyCZW1uKcOw8hThw?= =?us-ascii?Q?6PM5we2ksF2mKAwe9mV5LKDoZZqBgfBYzAzYnR+rDGrh+H9HLaiyH4hBqHmm?= =?us-ascii?Q?c1I+SL3UfX8tlNIwQqxkT1u4PzvlDsPPIs154KPkFkKibQs35SHVKxlm1ns4?= =?us-ascii?Q?8ZIMTnqAPmCGFnDxl5pxgxmbJmpTJL5a+WcsrcdaRSHRqAJBeapdVfjNyjcZ?= =?us-ascii?Q?+Eu4bqZkjAFLiCcEbFaEQ2j5ViPGHo0Htz58wA/4FMDeYNGQjvClkbXQDHZQ?= =?us-ascii?Q?5RycfHKTiiPALPH4X64rW/Vd0vKYc5lXM7iACnDxb2eZqDPVidYf3I4H1aE2?= =?us-ascii?Q?Q1xMH+tTTxNNQ15lRuYeKfobI2854pZPA7n8HhcgdfukmgEhc4mnafDQVlQ+?= =?us-ascii?Q?suQUd+fNCu8xWeeKCXgsD+i/9mHSJoRz0pO9eczKTJhDt4+mkYLwvzGsXkGZ?= =?us-ascii?Q?uxe4Agk97+J4m6iv4rybiOX45benxgITduTEXVBZu9PukmNfyL5eg43IWqOG?= =?us-ascii?Q?gnSiLQQ532tCqzM9P0Y+YwPT/CCgNwvdXtDUo3o2Rz3feMvmunVuj+eZOASt?= =?us-ascii?Q?wB5iDGwztmPnclgOciAFCay06WOd+Oxhhc8tS8Fm6lt2FHyogMgaByIYGHAt?= =?us-ascii?Q?ZPW3ovqhZ/vb8dPB+l70yCWVy+YHx9nNGmEEcGfilzy2Vx4Zk8FjJPfLWuwm?= =?us-ascii?Q?a6/NDm7c9cC5S+LMkgMJC/8ii2pU5ZnWKJsxqcKOXpwTsGzLhsdcqYiRDk+y?= =?us-ascii?Q?Pnnmk79gXE9nf/TisUX+SiIhB0RtWAeU8smbEMO9gmaSKUDEMg704//xNPAf?= X-MS-Exchange-AntiSpam-MessageData-1: 8baa5o2ioAeyFw== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 7f0a56c0-71d2-461f-e039-08df2915dba6 X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 10:36:36.8222 (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: KTWHJ0VZv/4GX35JOgXI9JXkuG3VJG7WCDoya8t+mQI+0u+IzIkdegZsTx3rAs+dPFpjFlmKhJHV05hG7jT9gA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY3P286MB3732 X-purgate-ID: tlsNG-bad1c0/1791887803-BE4DB034-4A9B035F/0/0 X-purgate-type: clean X-purgate-size: 13459 Hello, This patch series integrates CPU topology discovery into the Xen hypervisor for both ACPI and Device Tree platforms. Major changes in v11 include dropping the UNSUPPORTED dependency, handling unbooted CPU nodes gracefully in the Device Tree parser. Changes in v11: - When parsing the Device Tree, ignore CPU nodes if the corresponding physical CPU failed to boot, rather than treating it as an error. - Drop the dependency on UNSUPPORTED for CPU topology support. - Print an error message if memory allocation fails in init_cpu_topology(). - Fix a compilation error involving cpumask_set_cpu(). - Call map_cpu_to_dt_node() to record the CPU ID to DT node mapping only when arch_cpu_init() succeeds, or if the CPU is the boot CPU (treated as successful since the boot CPU is already up and running). - Use XENLOG_ERR as the log level for error messages emitted when DT CPU topology parsing fails. - Add ASSERT(cpu_topology) to acpi_init_cpu_topology() for consistency. - Code cleanups: * Use dt_node_name_is_equal() instead of dt_node_cmp(). * Drop redundant "ERROR:" and "WARNING:" prefixes from log messages. * Move header file includes into #ifdef / #else blocks where they are actually needed. * Adjust spacing to comply with the Xen coding style. 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 | 14 +- 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 | 69 ++++ xen/common/cpu.c | 5 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/cpu-topology.c | 417 +++++++++++++++++++++++++ xen/common/sched/credit2.c | 21 +- xen/common/sysctl.c | 1 + xen/drivers/acpi/Makefile | 1 + xen/drivers/acpi/topology.c | 343 ++++++++++++++++++++ xen/include/xen/acpi.h | 17 + xen/include/xen/cpu-topology.h | 76 +++++ xen/include/xen/dt-cpu-topology.h | 35 +++ 22 files changed, 1006 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 Tue Oct 13 10:37:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:37:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446955.1663097 (Exim 4.92) (envelope-from ) id 1xGZsV-0005bw-32; Tue, 13 Oct 2026 10:37:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446955.1663097; Tue, 13 Oct 2026 10:37: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 1xGZsV-0005bp-0V; Tue, 13 Oct 2026 10:37:03 +0000 Received: by outflank-mailman (input) for mailman id 1446955; Tue, 13 Oct 2026 10:37:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZsU-0005bS-9h for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:37:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZsT-00F0Ss-MR for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:37:01 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace09cd-8faa-0a2a0a5109dd-0a2a4502e0e8-2 for ; Tue, 13 Oct 2026 12:37:01 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace09c9-6ca4-0a2a45020019-d1558030c962-3 for ; Tue, 13 Oct 2026 12:36:57 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a018dc1f98so22207325e9.3 for ; Tue, 13 Oct 2026 03:36: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-4a19f249692sm293425625e9.3.2026.10.13.03.36.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 03:36: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=1791887817; x=1792492617; 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=B34eL7ZwM32LwTO8G0c5PwiiqLd3hFw10RyDa6j6dqM=; b=CGks6/bUzj1MWoDZA8zL7iiOGG/cDqOYNi0IQuj1YLoeQJt0L50Ir4wLnyndLWDPOp 2RQ3KjF7tf12EWNoUR2j8r6FgysO4KOolj70oWiZLShSt+XEzghK0krA6MOFSdKvEaq7 iW4UKnll4A3WD4JKRdsA3NW45gGS6YkJJipg8lCDmC2kBeczXqbx6P7riOJYzXQM1Gxm GVYwkxhrrjlYvGA7bWKNwwiAmq+IjpP+W1o/+i04AKpQRuToiVizHxEUZ4t4PE80MDAU XJWvzqt9HFXK5gsH0D5ecUyYXzprTBQ/ek08txe/3lGB+kzFAPHCO6IA0bgCopuO/KbH 8Cyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791887817; x=1792492617; 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=B34eL7ZwM32LwTO8G0c5PwiiqLd3hFw10RyDa6j6dqM=; b=VzDHNSTf0Jn0OZBjwE9NxymG1kEzC6s0AqCDPic5flmWi2VrUljZXcXRau51ReWg/t hw/T1oNA0QQ74vtRtR6sJEDwBpAZ+yxi1OwBQ/UHh7o4llmgdkUjyVnf4+QHLzgGPdhB 85hLPlDC4Q5MFFccd4f2kwUssYmMNEpD199xKca4M8eQ/FwsGRmg9AQFAjDDX67v7HWb LG/rDfg49gQ2X5lm6nSNDU//nyxSveoYuzzFXtrTq/Y5h7RvdsI2tui1R7TnybEa8oae NA1/WOyT3DZgbi85LgTNEZs1UkJZ8it15lNqU+FRRlugy4m5JHD5oEeBUt7KOK4JQiTN 6wAA== X-Forwarded-Encrypted: i=1; AKwUvBxXW4VmsBQ6/87kYbiUm9sQrxhxODJGXhgvcW4G4+/jF1QPF6QOwtVyjgbQ1kmqQKzV3hUDhSBYrFU=@lists.xenproject.org X-Gm-Message-State: AFq9FYIDthH8y+0i2DTzqWHy+feKvJOwuiYkJ5UmFHDQcbQTE7MRGuW9 68yOWWv23WbruB5GVfjpYTTg+t9k6NEqYERBFESAEmnvNsfA0Wb1bkWx3h6mH+cZLg== X-Gm-Gg: AYBFou0bkXR5qmEXLcCMTpA+eefj3Ch688qfW5w3f+MlHDYZu5AIBNVQ1uPJEGDsVCE O6x8scpzJBWFXqHn6g3QjiOe0NdnzzsaLSWMEShidFQXVcZVvYZHVUQ7X/en19Skc6FF++FS4qA pVRow3Xzw5M/vNV3N/nFGEdjKUY/UrRRVkczVVEjdfCKONKZan1H2XMNa2MGTNfmf3lWzo9Umds pdhzubpxHV7RLv2us1bfbuVS7jFmvPJGyJaW13xgHrTCS+qIa6ZuvNtEqZaLpRTkYU65pGtvBv2 yvZwtSh7nA/cyunjmHWc2kKSTAjxJ9PcWPP6cNWdkQ7rVvKTlJjYOjU9oLf7Cz0WR0JW0Jaz+r/ 2sHyM5CCqWiIIjNPlJcV/O97tg0GnM8EE9t93KPO4Xqvdo3tGeoUJpcPaKP7GJG98tO1Uxk19+x U9vo7DYvcUdUas3nIp8spHPQpwWjtV2E0U+C/DVJ6Yj2sQPfqsspGOFPN2JzJSeu+PhQLg/F5u6 YzEFqtVUUAWA/G5xP4AYIQpF6qoxNfuPfGVEDkncqfKWXDi1J8Xdu0/QerEdS8= X-Received: by 2002:a05:600c:3e0a:b0:4a0:1c10:1419 with SMTP id 5b1f17b1804b1-4a18e4cd667mr236218695e9.26.1791887816877; Tue, 13 Oct 2026 03:36:56 -0700 (PDT) Message-ID: <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> Date: Tue, 13 Oct 2026 12:36:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@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: <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1791887817-31DC92AC-1332B168/10/78276251493 X-purgate-type: spam X-purgate-size: 4668 On 13.10.2026 12:07, Baptiste Le Duc wrote: > @@ -620,6 +623,98 @@ static void __init compute_guest_isa(void) > panic("Failed to build guest \"riscv,isa\" string\n"); > } > > +static bool __init probe_hw_ad_update(void) > +{ > + bool updated = false; > + unsigned int slot = FIX_MISC; > + vaddr_t va = FIXMAP_ADDR(slot); > + struct page_info *pg; > + pte_t *entry, pte; > + mfn_t mfn; > + unsigned long tmp; > + > + pg = alloc_domheap_page(NULL, 0); > + if ( !pg ) > + return false; Why would you need a fresh page here? Can't you create a secondary mapping of a page already in use (e.g. one from Xen's .data or .bss section, or the stack page you're running on)? > + mfn = page_to_mfn(pg); > + > + arch_pmap_map(FIX_MISC, mfn); > + entry = &xen_fixmap[slot]; > + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE); > + write_pte(entry, pte); > + > + flush_tlb_one_local(va); > + > + asm_inline volatile ( > + "1: ld %[tmp], 0(%[va])\n" > + " li %[updated], 1\n" If you mapped the stack page, you could preset a variable there to 1, load from the alias mapping of that variable, and then avoid the LI altogether. > + "2:\n" > + ASM_EXTABLE(1b, 2b) > + : [tmp] "=&r" (tmp), [updated] "+r" (updated) > + : [va] "r" (va) > + : "memory" ); > + > + arch_pmap_unmap(slot); > + free_domheap_page(pg); > + > + return updated; > +} Imo you'd better check that A also was actually set in the PTE. > +/* > + * The privileged spec allows exactly two schemes for the PTE A and D bits: > + * 1) hardware sets them on access and on write. > + * 2) accessing a page whose A and/or D bit is clear raises a page fault, > + * so that software can set them (ratified as Svade). > + * > + * Hence an implementation without Svade uses the hardware scheme (1), and one > + * that faults on clear A/D bits implements Svade, whether or not it says so. > + * > + * Svadu isn't itself a scheme: it adds menvcfg.ADUE, selecting between the > + * two for S-mode and G-stage translation, and henvcfg.ADUE, doing the same > + * for VS-stage translation (read-only zero when menvcfg.ADUE is zero). > + * > + * Rather than trusting the DTS alone, probe the scheme in effect with a read > + * through a PTE whose A bit is clear, and check it against what the DTS > + * advertises, as described by the DT binding. Panic on a mismatch Xen cannot > + * run with, and record the probed scheme when the DTS advertises neither. > + */ > +static void __init 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); > + bool has_hw_update = probe_hw_ad_update(); > + > + /* Both advertised: Svade applies until FWFT enables hardware updating. */ > + if ( svade && svadu ) > + { > + if ( !has_hw_update ) > + printk(XENLOG_WARNING > + "Svade and Svadu are both advertised, but software updates A/D bits. " > + "To use hardware updating, drop Svade from the DTS or use FWFT (not implemented yet)\n"); > + return; > + } > + > + /* Only Svadu advertised: firmware must have enabled hardware updating. */ > + if ( svadu ) > + { > + if ( !has_hw_update ) > + panic("Svadu is advertised but A/D bits are not updated by hardware\n"); > + return; > + } > + > + /* Only Svade advertised: the hart must not update A/D bits. */ > + if ( svade ) > + { > + ASSERT(!has_hw_update); > + return; > + } > + > + /* Neither advertised: trust the probe. */ > + __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, > + riscv_isa); Hmm, this feels fragile. Other schemes are possible, e.g. A being updated by hardware but D being left to software. Are such truly precluded by the spec, including older versions thereof? Furthermore, probe_hw_ad_update() can (right now) return false for unrelated reasons. As a consequence, patch 2 imo also can't leave the A/D pre-setting unaltered. It perhaps needs doing unless Svadu is positively identified as present. > --- a/xen/arch/riscv/include/asm/cpufeature.h > +++ b/xen/arch/riscv/include/asm/cpufeature.h > @@ -42,6 +42,7 @@ enum riscv_isa_ext_id { > RISCV_ISA_EXT_sstc, > RISCV_ISA_EXT_svade, > RISCV_ISA_EXT_svpbmt, > + RISCV_ISA_EXT_svadu, Isn't there some sort of sorting in effect here? Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:43:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:43:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446966.1663108 (Exim 4.92) (envelope-from ) id 1xGZyN-0007qi-RT; Tue, 13 Oct 2026 10:43:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446966.1663108; Tue, 13 Oct 2026 10:43: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 1xGZyN-0007qb-Nh; Tue, 13 Oct 2026 10:43:07 +0000 Received: by outflank-mailman (input) for mailman id 1446966; Tue, 13 Oct 2026 10:43:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGZyM-0007qV-VX for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:43:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZyM-008SRk-8T for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:43:06 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace0b2e-8faa-0a2a0a5109dd-0a2a450a99c8-26 for ; Tue, 13 Oct 2026 12:43:06 +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 6ace0b39-f2d2-0a2a450a0019-d155dd33a492-3 for ; Tue, 13 Oct 2026 12:43:05 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48b02a2359aso2617005f8f.0 for ; Tue, 13 Oct 2026 03:43: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-48de0aaa9f9sm4596010f8f.19.2026.10.13.03.43.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 03:43: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=1791888185; x=1792492985; 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=qKdOjTrFDv1gnxofkiRE7WHkmPOI2o+TjSz9NKa2zTU=; b=WoNIk8BuFAipgyEvmyL0CuVjJHyrkKdY6ZSASjUlJi1KcQMAo7LfNxmO1JM5ag6d20 zs/FeVONGXIod/bSiuQIF1M2qax4TYaoikskIZ0wEJ/teCyRAe1+FC3GnVj6smpJOMth FmyLqw5zuUBPdT5AuEp7PlDBGzWY6NWaRI57WEVe+zH8hgJywm+3lIaKq9OSEvpN47Tm ub8iptSMs5daNaVNk7F4fKsOkfSoKNk0Zcz7QbSoT8YgxHtvi7izouPRFC7E4GEho6cJ vmHSw6i3aeI2OlfGkyd4O5LldY/59bsCUQOJBe1h2iPFFtLc0simvbqjkthj8hhrJias JelA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791888185; x=1792492985; 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=qKdOjTrFDv1gnxofkiRE7WHkmPOI2o+TjSz9NKa2zTU=; b=f5Wvk+RoGmVkC0zW8+H83QxDq1Np3UJOy4h7+ib+/7nf913HrXYs7f/HhGBhTmD+Rf CsWBSYpq03eguTKgtfeoMyV1P4livbnMoUX79EspgyTo1TfHJVra4a7Wew568JdoSv7P JZ10b7cnMvWGtxcWPE1mYuVqnHN6c4bGV5KWikvE4GE2CzF42sVuwflho5pGEF+9qqqe Uh2Dw7U41Pn8UpK+3xcOukWC9aXRb8XnTEFoPej8uj1iHBKTBbPhCRqpfNkJY9gfWOT+ 8P3rEAlAjZnvPKSZJ5cLrH3ycHPESU++7P40SLntW3gnjDvLj8qaPujO8ITCNgzhNatM HWgg== X-Forwarded-Encrypted: i=1; AKwUvBxz1lrLHuA2a/6BoJz/vDHA6cfFeDP1lJdWMtAbhVle4YKXuLrmuFHdMXtzUM9UYHvNs/fUv+aRKf8=@lists.xenproject.org X-Gm-Message-State: AFq9FYI3RoT4OUghCSErGh0TEvniabtXRKXtPuJm64Lfo8D2LujqXvWi Ge7CgvW3uiPHcPgMxUget0H4K0XLHlW2MINXS2iyJS/xLKxKSGOzlOwvyl2Q5B9LxA== X-Gm-Gg: AYBFou305DKKLoGt52lSufWTKlMffWTrl0bYRwELk1EBJ/hawmPELJfhhxWjbMBgAPS warbyuybrWgroJJ326Za4WAaviof9syAvQoFvY4V0ZoKcWp0NdvKzz40BeiJDeZ1I5UY+WU+WoZ 9/Orhc4NXfQyB0mGZr8GRN3PFcQA9B6wDpwXviBuOQOsoaMccY7OsEpCTCkqhuYFyHQAk2ZVpwf Ujfv6KU5KmqRjDin7kh4fBPh2kgeCo4AL2ei1YW5eiR4LsJiNtlQIGzGGydmTZ/Aad88ANZPiJS v2/qb25RM0fb2TDvoWW2mLwgAO2z0b07l1FEj0OmPKUzBWIAZmfdecABqAB4Aov2ZQO3RbtWyDT PeWsdm8mI9kGiYlyZZWIB826u35iCT9hYtWqiO7T8VDGGVLGg/x7sFWeGtS0PAG2g9wtaLxM9nh KvHnhSNxHda1+00iE8QbMcM865fo9kuXOVNvSF4dVSKheL4NSfEl2tPlrxTBnLpfxEHfkeN6Jil f0RYcSrsPApb281XX/RmID+XzP1U8CJwQT4yetlhnTKIgbF9mlo/NFP1zhjcyU= X-Received: by 2002:adf:f789:0:b0:48c:4a62:9b31 with SMTP id ffacd0b85a97d-48dba9e66femr16904139f8f.5.1791888185040; Tue, 13 Oct 2026 03:43:05 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 12:43:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425@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: <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791888185-516C6CFC-8F5E863E/10/78276251493 X-purgate-type: spam X-purgate-size: 2958 On 13.10.2026 12:07, Baptiste Le Duc wrote: > Xen does not handle page faults caused by clear A/D bits, so it presets > them when creating PTEs. pt_update_entry() does so, but three places build > leaf PTEs directly without going through it: setup_initial_mapping() (the > boot page tables), check_pgtbl_mode_support() (the temporary root entry > used to probe SATP mode support) and arch_pmap_map() (the fixmap). > > Without Svadu, all three fault on first access. For > check_pgtbl_mode_support(), the fault is raised by the instruction fetch > right after the SATP write, before any trap handler is set. > > Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build > PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in > all cases for consistency with pt_update_entry() which sets it at runtime. > > 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 check_pgtbl_mode_support() to > use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. > > pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one > of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by > masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also > carries A and D, a reserved PTE with A or D set would no longer be caught. > Mask with the V, R and W bits explicitly instead, and factor the check out > into pte_has_reserved_rwx(). > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > Reviewed-by: Oleksii Kurochko > --- > Changes since v5: > - no changes, already reviewed and waiting to be merged. I'm puzzled by this, also seen in the next patch: For one, nothing is said anywhere that patches 3 and 4 are independent of patches 1 and 2, and hence could go in ahead of those. And then, formally, neither patch is ready for committing - Oleksii's R-b isn't enough at this point. I would have ack-ed the last patch if that didn't - contextually - depend on the one here. I'm only going to ack the one here once either it is clarified that it's independent of the first two patches, or once agreement was reached on those earlier patches. (If this was independent, though, I would have expected it to have got moved to the front of the series, to disambiguate whether it may go in already.) Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:49:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:49:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446972.1663116 (Exim 4.92) (envelope-from ) id 1xGa46-0000Hh-Cd; Tue, 13 Oct 2026 10:49:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446972.1663116; Tue, 13 Oct 2026 10:49: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 1xGa46-0000Ha-9w; Tue, 13 Oct 2026 10:49:02 +0000 Received: by outflank-mailman (input) for mailman id 1446972; Tue, 13 Oct 2026 10:49:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGa44-0000HS-Fn for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:49:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGa43-00F2Y9-C9 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:48:59 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace0c9a-8faa-0a2a0a5109dd-0a2a4506cb4c-4 for ; Tue, 13 Oct 2026 12:48:59 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace0c9b-195a-0a2a45060019-d155802fa84e-3 for ; Tue, 13 Oct 2026 12:48:59 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4980fe6b3beso25280465e9.0 for ; Tue, 13 Oct 2026 03:48: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-4a190344032sm363410835e9.15.2026.10.13.03.48.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 03:48: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=1791888539; x=1792493339; 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=pO4q+8e8JSz4afh1YyM0E7DeZAMGnTAzQ14XBEXPBjQ=; b=PM37JDaBmD6RBYrNrzQaZoRbkaaFb4VOKjvAwLCdH5Pa0d+EU4Ai/Y8ROicTRkKONZ 6dDBUnIUop6/l8y2xsqGc48gQwbZoNfFM4leSNnlTmZ8wx1H8o1uFth5JDWqTPgJ4iM+ kdTjtF5FIqIIx+eAYf6hHTNqi1z2P46XG/ak5S5cfxAEZPG9rdPQb8B95ziPSdVUkYdo UddRjbfxxOcy8itqRZhAvUS4FhbRaQQNaGKD2G6u8a6yTD1dg4FdutX08+AecTyJ8WK2 7BZW049cNsbo8uLcgyHuYaMFt0OnLqjxGtuLv2gRjNJOZxcYN9rcESdrbeWRekdhEkOY RMMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791888539; x=1792493339; 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=pO4q+8e8JSz4afh1YyM0E7DeZAMGnTAzQ14XBEXPBjQ=; b=gye84zWVY7MhqvqUFEdSlwDcsWqyz623XIK/rQjmax9k0azFkzbmPhxeFh2Fh29Mj2 m+pQjXh+RpjIzJCp0NXTDa0KIVRyTV62/vmUKRlZBI7o9OixhXyyNRxBCt/Ye4acLCa5 njm+5PgrxVTDuQextJHKWw0sTxAjEpyVGxf99PePSXhmOwPWLG65oOvr0JFnC5vNhcsn FjKmwz6hrXJOAq2k43/S3yH+v5bPY2Q0yqxOn8+ayuEr2eiXJJJiMprW+y0awOqFHJMe guOcXCzXHEdkn6Br2eWDIjnA9UnjVEVFhxm1ZRLvZbhtLCEpvAzZuGMfgTFExCmeqHsE iyAg== X-Forwarded-Encrypted: i=1; AKwUvBw/bCRhdc38uhBsQtM1S9Ro/E+wr4xTkRbTkyWIQnZIr6a9eR1CTdAF6ovRIg5ax7LQKOEWQgbip3U=@lists.xenproject.org X-Gm-Message-State: AFq9FYLfejDZ6+ePyRQqF+VvuEwO+ZVTPG3rXUMzYMZ+nxjVTw8NXLsA 2vfkIK1DlfEfjQrghJZGwhrMlAdHl14OhcB+WcKCIs6+ad+5WQrctzEbpNvWEixfyw== X-Gm-Gg: AYBFou3qg3Q+TYJfQQAD2M6nugh+DrA3bx90B4a2qLGQKwog+yX+agJhywZGSmFqlrW v2Wk1XDupyJjV2qcwvjBG7ivbiiajTe4vykjpXD042rm0IBLHf0myzCAoB4GkGC+OKlDcmSejfS TdvMhrRrWB8S9obxStre8A2QFLm7ih/WHlCygyaW1jgALhwpmoEEhHjCIox9K5aiyFwOGA/WW9D uIB5gC4QEeLxcw3RBFwZJPOF1kKhs5TM7YU/s3aRUUTIA3S4DE2exMV+cNNTjyg9+ys3LNU9C+R tbgwrT03mb2APT+dFEgR2Fd15/dEKg95iOu6KuAUSqccBhdSHdmeoLCrQ9KDuNnNL4GqzrIZ+J7 0VYZmSz8vNxkcKbQdVYTEX7Mc6ke4DbhDGVunVpEZyjyjyHaA+P5eHzgyFLWEmxjvmSD22vLOsR C3HkahLPOt14gWGjtbUkytOF7B9w3IH4AmhstKY6uAVoj04VNMVCylRSzfXLqZyQWxAyF4KGjkb jpnzzmF0eA2//pjcc3qwUbw7MB9K0HxcxqJqdY63Bo+U0oJT2ajhYKTSLzWbMY= X-Received: by 2002:a05:600c:4708:b0:4a1:88df:8a2a with SMTP id 5b1f17b1804b1-4a18e4a6ea5mr242851675e9.13.1791888538657; Tue, 13 Oct 2026 03:48:58 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 12:48:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration To: Hirokazu Takahashi Cc: michal.orzel@amd.com, Mykyta_Poturai@epam.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20261013103616.121916-1-taka@valinux.co.jp> <20261013103616.121916-2-taka@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: <20261013103616.121916-2-taka@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1791888539-F647377B-447D29FE/10/78276251493 X-purgate-type: spam X-purgate-size: 2530 On 13.10.2026 12:36, 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 Imo this should have been dropped, when the covered code ... > --- > Changes in v11: > - When parsing the Device Tree, ignore CPU nodes if the corresponding > physical CPU failed to boot, rather than treating it as an error. > - Drop the dependency on UNSUPPORTED for CPU topology support. > - Print an error message if memory allocation fails in init_cpu_topology(). ... was touched at least for this change. Specifically ... > --- /dev/null > +++ b/xen/common/cpu-topology.c > @@ -0,0 +1,69 @@ > +/* 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; > + > + if ( num_possible_cpus() == 1 ) > + return; > + > + cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids); > + if ( !cpu_topology ) > + { > + printk(XENLOG_WARNING "CPU topology table allocation failed.\n"); ... for one, nit: No full stops please in log messages. And then, how can a reader of the log tell this message from ... > + 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(); > + printk(XENLOG_WARNING "CPU topology table allocation failed.\n"); ... this one? Or if the message is meant to be the same, perhaps you want to fold both printk()s (likely by way of using goto)? Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:51:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:51:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446979.1663124 (Exim 4.92) (envelope-from ) id 1xGa61-0001tF-Mn; Tue, 13 Oct 2026 10:51:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446979.1663124; Tue, 13 Oct 2026 10:51: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 1xGa61-0001t8-KA; Tue, 13 Oct 2026 10:51:01 +0000 Received: by outflank-mailman (input) for mailman id 1446979; Tue, 13 Oct 2026 10:51:00 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGa60-0001sx-J7 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:51:00 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGa60-00000003Law-0k1n; Tue, 13 Oct 2026 10:50:59 +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.98.2) (envelope-from ) id 1xGa5z-0000000CAjj-0kGY; Tue, 13 Oct 2026 10:50: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" 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=UGnq7yp0iNtd2xrhawvYlyGmXISxEngyzGb7qooGX0g=; b=x0G3+4xcpPnDqiBeAD5aWwbrh4 xAWhdKAVVrRuOsIq94kr7BUNyNoQqO8JXaBnfdeN1OMko3jt0AtDOJlz+JPuKD08/BD8GJOZbFw+Y 460xQVATWzgkxPQ+2kN0BZwbxKK4n9+PPKxGdYStqX96Rw85cRBHMO8RQl9XSOPQBJec=; Date: Tue, 13 Oct 2026 12:50:57 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Oct 12, 2026 at 03:19:20PM +0100, George Dunlap wrote: > On Thu, Oct 8, 2026 at 9:22 AM Roger Pau Monné wrote: > > > > On Wed, Oct 07, 2026 at 11:40:41AM +0100, George Dunlap wrote: > > > From: Roger Pau Monné > > > > > > Currently, only PV domains have a mapcache, which is domain-wide one. > > > In preparation for enabling per-vCPU mapcaches for HVM domains, split > > > the accounting out into a struct mapcache, embedded in struct > > > mapcache_domain. > > > > > > Introduce has_mapcache(), for whether a vCPU has a mapcache, and > > > vcpu_mapcache(), which returns the accounting for a vCPU's mapcache > > > and, in *dcache, the domain-wide mapcache whose lock and TLB epoch the > > > caller has to take into account. For now has_mapcache() is > > > is_pv_vcpu(), and vcpu_mapcache() always returns the domain's > > > accounting. map_domain_page() and unmap_domain_page() stop repeating > > > the is_pv_vcpu() check mapcache_current_vcpu() has made. > > > > > > Move map_domain_page()'s handling of the domain-wide lock and TLB epoch > > > into three helpers: mapcache_lock() takes the lock and catches up with > > > a wrap another vCPU caused, mapcache_new_epoch() starts a new epoch > > > after a wrap, and mapcache_unlock() drops the lock. A per-vCPU > > > mapcache can then skip them without map_domain_page() being > > > re-indented. > > > > > > struct mapcache_domain keeps its size (40 bytes, x86_64 debug build), > > > and so do the structures containing it. > > > > > > No functional change. > > > > > > Signed-off-by: Roger Pau Monné > > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 > > > Signed-off-by: George Dunlap > > > --- > > > Changes in v3: > > > - New in this version, split out of "x86/hvm: introduce per-vCPU > > > mapcache for vCPU-PT domains" for review. > > > --- > > > xen/arch/x86/domain_page.c | 155 ++++++++++++++++++++---------- > > > xen/arch/x86/include/asm/domain.h | 19 ++-- > > > 2 files changed, 116 insertions(+), 58 deletions(-) > > > > > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > > > index 9119f735f5..5d90f77bed 100644 > > > --- a/xen/arch/x86/domain_page.c > > > +++ b/xen/arch/x86/domain_page.c > > > @@ -18,17 +18,23 @@ > > > #include > > > #include > > > > > > +/* > > > + * Whether v has a mapcache: PV vCPUs (whose domain-wide mapcache may still be > > > + * disabled, see mapcache_domain_init()). HVM vCPUs reach everything through > > > + * the directmap, which covers all physical address space for them. > > > > I've been wondering whether there could be a way to write this comment > > so that it doesn't need rewording once we switch to per-vCPU > > mapcaches, as to avoid adding a comment here that will very likely be > > completely re-worded by a later change in the series. However I > > cannot find anything much better rather than stripping most of the > > comment content. > > I think describing it the way it is, then changing it, makes the > series or the state thereof more clear. But I'm not precious about > it; we could make it something like this: > > /* > * Whether v may use a mapcache rather than the directmap (a PV domain's > * mapcache may still be disabled, see mapcache_domain_init()). > */ > > That said, as a meta-comment: We have a limited amount of time on my > contract, and also a limited amount of time before we want to check > this in to the tree. Is spending our time changing non-functional > intermittent git tree state really what you want to spend that time > on? It's sometimes hard to know whether a comment is in an intermediate form, or in the final one, hence it's difficult to trim review to not be picky about intermittent state once the final form might be acceptable. That's why I've suggested to try to add comments in its final form (or in a form that just need expansion by later changes). I would maybe use: /* Whether the vCPU supports mapcache usage, might not be in use. */ Personally: referencing functions by name in code comments is also something that I usually try to avoid doing if possible. As the code evolves it's not unlikely for functions to change names, and we have (historically) not been very good at keeping the referencing comments up to date. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 10:55:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 10:55:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446989.1663146 (Exim 4.92) (envelope-from ) id 1xGaAQ-0002cK-A4; Tue, 13 Oct 2026 10:55:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446989.1663146; Tue, 13 Oct 2026 10:55: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 1xGaAQ-0002cD-6p; Tue, 13 Oct 2026 10:55:34 +0000 Received: by outflank-mailman (input) for mailman id 1446989; Tue, 13 Oct 2026 10:55:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGaAO-0002bz-M1 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:55:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGaAO-00000003LgC-2s2e; Tue, 13 Oct 2026 10:55: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.98.2) (envelope-from ) id 1xGaAN-0000000CJbe-2xwq; Tue, 13 Oct 2026 10:55: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-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=kdBMTAMuGu+Usd5+PjiKqTPkSr/H4FoR75WvUpHudaU=; b=0mMpz6wKV1rEgAy/m2XSX15Um3 BIs77VMeMP5XvaGjbRpKnT58vx7hAgS73/2Ls9ux3w+EqEmUqUFzvREgt4mtxA0Bt6lg/Fl+FwuW3 JlW27ClKOwm0kj3bO+4/U6LqEgyBSleq3bWrqUlQbkREEw0GAPDiYpWuQiJ0llGrrMHU=; Date: Tue, 13 Oct 2026 12:55:30 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 10/18] x86/domain_page: don't unmap a mapcache entry that is not present Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-11-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Oct 13, 2026 at 11:33:55AM +0100, George Dunlap wrote: > On Thu, Oct 8, 2026 at 12:04 PM Roger Pau Monné wrote: > > > > On Wed, Oct 07, 2026 at 11:40:43AM +0100, George Dunlap wrote: > > > Mappings must be torn down by the vCPU that created them, and only > > > once. Have unmap_domain_page() check that the entry it is handed is > > > present and bail out otherwise (ASSERT_UNREACHABLE()), rather than read > > > an MFN out of an empty PTE and act on it, as a second unmap of an entry > > > the first one zapped would. (A second unmap of an entry the maphash > > > kept is caught, as before, only by the refcount ASSERT() in debug > > > builds.) > > > > > > Assisted-by: Claude Code:claude-opus-5-5 > > > Signed-off-by: George Dunlap > > > > Reviewed-by: Roger Pau Monné > > > > > --- > > > Changes in v3: > > > - New in this version, split out of "x86/hvm: introduce per-vCPU > > > mapcache for vCPU-PT domains" for review. > > > --- > > > xen/arch/x86/domain_page.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > > > index f91ec8a75a..708df90a00 100644 > > > --- a/xen/arch/x86/domain_page.c > > > +++ b/xen/arch/x86/domain_page.c > > > @@ -230,6 +230,16 @@ void unmap_domain_page(const void *ptr) > > > ASSERT(cache->inuse); > > > > > > idx = PFN_DOWN(va - MAPCACHE_VIRT_START); > > > + /* > > > + * Mappings must be unmapped once, by the vCPU that created them. With > > > + * nothing present there is nothing to tear down: leave the hash and the > > > + * bitmaps alone rather than act on a stale or foreign pointer. > > > > The comment makes more claims that what can be checked for: there's no > > check that the unmap is being done by the same vCPU that created it, > > neither is easy to add one. Any mismatch like that would become more > > obvious once we switch to a per-vCPU mapcache. I would possibly > > reduce the comment to: > > > > /* Ensure the entry to unmap is populated. */ > > > > The commit message already have the lengthily details. > > The problem is that now the comment just repeats the condition of the > if() statement, which an experienced developer can already read > without effort; it doesn't say *why* we're doing the check. What > about something like the following? > > /* > * Sanity check: an entry that isn't present means a double or stray > * unmap. Play it safe: don't act on the MFN in an empty PTE. > */ Oh, I'm actually happy if you want to drop the comment altogether. I think the check + ASSERT_UNREACHABLE() is already clear to understand. And we expect anyone touching this code to know that a double or stray free of an entry that's not present is not a good thing. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 11:05:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 11:05:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446998.1663163 (Exim 4.92) (envelope-from ) id 1xGaK5-0004q4-D4; Tue, 13 Oct 2026 11:05:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446998.1663163; Tue, 13 Oct 2026 11:05: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 1xGaK5-0004px-A7; Tue, 13 Oct 2026 11:05:33 +0000 Received: by outflank-mailman (input) for mailman id 1446998; Tue, 13 Oct 2026 11:05:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGaK4-0004pr-4D for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:05:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGaK4-00000003LsH-0LhH; Tue, 13 Oct 2026 11:05: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.98.2) (envelope-from ) id 1xGaK3-0000000CdGs-0TE9; Tue, 13 Oct 2026 11:05: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-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=+cjGdbKpLKHdnIx9aWSVdVDtVIl50WZDJui5V4rAR4M=; b=pXRNCVZLmQ/MgALj03ZiDigP/W gNw4nFRNphmLpzatHCXHuqfSxIh1jdDULTCMa4GgZZ+uHsDZbrclo9oPjXBCoAG2kL8z4CDMVXLnG dcCphjL77FZwjVm71G1xePtRB2vTE/Ocv0tGmBn5qoyAvqn7+MHQzrKr96HkTT8h9z54=; Date: Tue, 13 Oct 2026 13:05:29 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 03/15] x86/setup: break out E820_RAM accumulation Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Oct 12, 2026 at 10:20:16AM +0200, Jan Beulich wrote: > We already have two instances of this, and we're about to gain a third. > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné > > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1007,6 +1007,17 @@ static unsigned int __init copy_bios_e82 > return n; > } > > +static unsigned long __init nr_ram_pages(void) > +{ > + unsigned long nr_pages = 0; > + > + for ( unsigned int i = 0; i < e820.nr_map; i++ ) > + if ( e820.map[i].type == E820_RAM ) > + nr_pages += e820.map[i].size >> PAGE_SHIFT; Do we want/need to ensure size is page-aligned here? AFAICT this is the sanitized memory map, so it should have all regions aligned to page boundaries. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 11:39:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 11:39:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447021.1663172 (Exim 4.92) (envelope-from ) id 1xGaqt-0001MN-T4; Tue, 13 Oct 2026 11:39:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447021.1663172; Tue, 13 Oct 2026 11: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 1xGaqt-0001MG-Px; Tue, 13 Oct 2026 11:39:27 +0000 Received: by outflank-mailman (input) for mailman id 1447021; Tue, 13 Oct 2026 11:39:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGaqs-0001MA-OT for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:39:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGaqr-000Dfq-U1 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 13:39:25 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1869-2eae-0a2a0a5409dd-0a2a4503a638-10 for ; Tue, 13 Oct 2026 13:39:25 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace186d-fae8-0a2a45030019-d155802be0e6-3 for ; Tue, 13 Oct 2026 13:39:25 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a1635f7c89so28697165e9.2 for ; Tue, 13 Oct 2026 04:39: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 5b1f17b1804b1-4a18bf1358asm362338865e9.4.2026.10.13.04.39.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 04:39: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=1791891565; x=1792496365; 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=uyPd4ETxoPO8/iFsSx9XpoUu479xw20UGesX25IrssA=; b=ANvR/ojqcm8ehpwoMYZikWVS0i+slZ5GL1Dh6X5xoeAH0pl/IQu9XkPWeJ+blUlpZO QU354YoRGUihs4TDGm1g4BmminLzh0eCdGvVZwQ8fSaLF4JhH/nK991OPGbX5ysZtIFc UoMpM5KV0l35PmFr0xhcdT+1gGvhcvGap2JhxqL06LLCIOhPVXF5zTTk+t78M0vLiGja lUv0gBjg3HfRzooYwK0qsd7nll8ZBtrKFxysNsDYSlNBvNUKYyUgXNoFdCHAOPAGuDRJ VT9yLANrFh7XU9iGfMs/Nf3KX9LYywMW8sb6egIInSI5UrnAXSYJaeT+ZFgPWjpFYcMd dGHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791891565; x=1792496365; 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=uyPd4ETxoPO8/iFsSx9XpoUu479xw20UGesX25IrssA=; b=HgDfUJXud2bDxGI6Oo7hD263T2aH718YTikt4Jx9wcSgDDiIu2HZZOMib0EqxgRmSz Rcj0/cFoVtig1EC1TBssE6bjOgvjMo8P5cCXUrHbIC0n3bK1WlEhWWPOxy8w8DnR9LWG yI8cENEr3LCYVZCQFbaW9dj++b6NL+fVnKmwMe/7TWdlPdWKnIPH6ycE83DbX93iG+z4 WVkVVJA9CfmGCkKTpEBjFGpH7yM4TTwiiZidIYnn1e6lLQNM2E+Izu9vsl/H/wqnEysq lplxT1MmuTdQp6rxZMFq0HzU0GYdsOxOoACs2fAR/p7kI5zzZocgNZqzf+QfWSRLnsB/ 8TJA== X-Gm-Message-State: AFq9FYJMN7DvCc+AV9iCJvDW/nHICmrCDb/GVkd/M2T5MC9h2p7vP50T QfRQhiXgDHd1y1fBYLesTbp6ufHboyYpHF1vrye2qBSw6EVuY24gdsO6L6YwA/22mg== X-Gm-Gg: AYBFou3CXtjvOZe7yQAFldyKXLgca2bxsKiFwu67QeXkIPk9y1WFdfpoIpgBMKv2ETL k5qd9BeZ7j7dimIme38gHnCh+JEXYyZ0TI2wN43gJvoDTWCE0M8tjQMSRiaRALquoRxu3xsgTq/ 3TsUsCkyKluhW8MP9y/4MZIOMmXQozPiC/knQBdgrXqW20dCtp1Z/yWYPiAcAHdW4ELyjZc3xVf iIOg3SPLFDds3Bnvh89+8/w1Ioo2JnOwgfzRBjNbEICpLFaGLR4jxr4y8Ow0Oc3Z5mqwgMnsDSv XPWGLK8AT0uV+DwNAVze0DzjsZ3FhG4f2j+xMoC8EG7YFDfL3LV7F1vlp3BMWJJnk3KCBK+o9p4 52sRodSZ1eKfQpJrrvCHGc4vWOO9EeaFd7vXkTzI+C9nGj6lx+vEGwSgc5RcLsNwOnMh0JtY49N /XcR4IB93mlMh3JjEwus0SpB5o4EzY0Aj6fWpyKaBnb+wiJG8n/AwX9mKCQGtBQHmSc1apIO8aT 0O3pOHDre0Eshlm6e+oUSoqVZoAxMZFjcZoIeapzHZTui8gfVEQfofE1SNoxQ== X-Received: by 2002:a05:600c:154b:b0:49c:fed6:cd3f with SMTP id 5b1f17b1804b1-4a18e4d0be2mr234485795e9.23.1791891565217; Tue, 13 Oct 2026 04:39:25 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 13:39:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 03/15] x86/setup: break out E820_RAM accumulation To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1791891565-764FC4E9-3EFAE8D6/10/78276251493 X-purgate-type: spam X-purgate-size: 1016 On 13.10.2026 13:05, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:20:16AM +0200, Jan Beulich wrote: >> We already have two instances of this, and we're about to gain a third. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Roger Pau Monné Thanks. >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -1007,6 +1007,17 @@ static unsigned int __init copy_bios_e82 >> return n; >> } >> >> +static unsigned long __init nr_ram_pages(void) >> +{ >> + unsigned long nr_pages = 0; >> + >> + for ( unsigned int i = 0; i < e820.nr_map; i++ ) >> + if ( e820.map[i].type == E820_RAM ) >> + nr_pages += e820.map[i].size >> PAGE_SHIFT; > > Do we want/need to ensure size is page-aligned here? AFAICT this is > the sanitized memory map, so it should have all regions aligned to > page boundaries. Neither user cares about an entirely exact value, so keeping things simple looks sufficient. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 11:40:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 11:40:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447025.1663181 (Exim 4.92) (envelope-from ) id 1xGasJ-0002oT-6H; Tue, 13 Oct 2026 11:40:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447025.1663181; Tue, 13 Oct 2026 11:40: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 1xGasJ-0002oM-31; Tue, 13 Oct 2026 11:40:55 +0000 Received: by outflank-mailman (input) for mailman id 1447025; Tue, 13 Oct 2026 11:40:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGasH-0002oE-M9 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:40:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGasG-007hiT-J9 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 13:40:52 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace18bc-2eae-0a2a0a5409dd-0a2a450a8ef8-12 for ; Tue, 13 Oct 2026 13:40:52 +0200 Received: from [40.93.196.11] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace18c2-f2d2-0a2a450a0019-285dc40b3eb8-3 for ; Tue, 13 Oct 2026 13:40:51 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by DS7PR12MB8232.namprd12.prod.outlook.com (2603:10b6:8:e3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 11:40:47 +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.0522.011; Tue, 13 Oct 2026 11:40: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=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=bTP8xZvPqo2YCGvhQnY8iftheeB76kVbM+NrI8QLYi/eWr+vl96cfZ0LeW0ugRMSJ672N0hhmgduc4t6eFRrLwRhLxuKN1F5UAt0mmxxqJtsHSG/EpDiIPujp7s2r+/auz5mACp3bsMxQPowQHBZbTzqoOCNhBC0a35AnWzyqmJfni0E45JKkbBjzeeAqMKTKgGIBEowllayWaHncpjDfwAmJSPBsjH1F/P3VVTCaDFdOleKpMb2/mC2j2zq1rC8iaqnUaZhgveGpJOMFNrMJnNVrHEbxskfJn9NGCjU+V5ajbdcKztQF11e/4BwEKFQpvt59U7WtNvybSfj0L5bIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=x78XjEP0pIg/q5IyayNJO4LmQYDgFMyINQZGULwqKkQ=; b=DI5qbFWGTFbFDptnd4yDsLm08yBAirhswFuwZQaa62WcykkG0/dm9bZ/RQJXVXaCZkYe550mTUnpU4h1vBK62nUGXAI+CnGUWs5XZFANNxz3IuwNp3AWQ1PJvoc70yPEiaBVts27ky6TZOgcZvdX+RAWyrV7L50492EGIbSkL8BOorQfGfF5bqOtdRQkxgZj75Z3pVu14xLHIvPTdjLSVG/X0hHtf6G+90rg0ecG3yXU/WgE6O4LHWbZmCl6qX0+xHHg+n0UVot2OJqUKy52bAxHUi5FcN0dhAMY5Z6/nOeSW6AyPWs1s2NSVsIkhqEhiGkfTtLt8PfNpjQ8Y+5SnQ== 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=x78XjEP0pIg/q5IyayNJO4LmQYDgFMyINQZGULwqKkQ=; b=jX5NlKxc4epoyeGtXBcK1wG8bQ1rTx4OU2tiY8Ow0G7uSw0zMQ8i1uX+KcgH12SDEsy68nYri9L/hmXFebGeD2CtPp75/pw54S8QpHwiPLYG9TljqGDbOLXgtqr09fs+98JKFLqHSMyW+3vYRx2GQXRTHz4MIOHDmwR+fFqAk84= 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, 13 Oct 2026 13:40:42 +0200 Message-Id: From: "Alejandro Vallejo" To: "Jan Beulich" Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Volodymyr Babchuk" , "Daniel P. Smith" , "Andrew Cooper" , "Michal Orzel" , "Sergiy Kibrik" , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v4] common: dom0less-bindings: introduce XSM labels X-Mailer: aerc 0.17.0 References: <20261012101453.949907-1-Sergiy_Kibrik@epam.com> In-Reply-To: X-ClientProxiedBy: MR1P264CA0077.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3f::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_|DS7PR12MB8232:EE_ X-MS-Office365-Filtering-Correlation-Id: 81e1690b-3160-4d79-c854-08df291ed27d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|10067099003|4143699003|11063799006|18002099003|22082099003|56012099006; X-Microsoft-Antispam-Message-Info: GG6fYQPmBJt0yYQ9M3i+1ZmWJr9J95kCIF5ZoZ5NuJvXJOxWhZZjIZXAe9v908d5t/XAtnqCei6bqpUaGgza+gECQ3VOGet5gtzbVROUgXbJ5+RigpGP4bcYQn17bl8JoeaZV6abjBWUCyS/E/dqJqCAQ+RveEOrTVtZ09i0/WWiXvLRRRlj3ell6lC8lBinnBnOyi5mTg8R/mBUojJiDe/0pDxNXlvxjCzPjeObrHcJB+hkiFW8Rl8Tbd4PxTaZrqYqdfNIcYgbYbNSry8bT+BK1Mr96FkXriw2rp9bqjCQBKup60g+WGh9ou+RkdPMJwBUVIuRiswT+Fkddp+SETbYv8LohnG0Opv/EcQvN5qF3vpdZ6r8mMhWBE6/AKyliWyB8S9vEqEa3kZhv5x1BisoV3TzRtTBvEvA6QROwkl+w4Ze2ZmQNKfwPFUKb1GjVBkgtLe/LH6T9gmVNxWlWwFd8qEgpP+GuCWfsti08gtkpCuy7AeLjUPTw+WRmKN+oU9ATQgi9Rb75jbIb6jo6vZubod4STRbRI5zz0Sim9+6O4+H6iNcpofnFGOJ0br2V/iBTeaY++1ZpbWQp1jNypWKL+se9as5h5RzVVlPT4MfTJziFW+cL9binhEmpjo3cvkQJOfG3tPVosTlCJTcFDgxTSmvzf5v4yqMedaMM90= 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)(10067099003)(4143699003)(11063799006)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NGZtcmdCSGFRL3ZOSW5OUlY2ZTlQRWk4d1pCZzNrNjRjRGgxbDF2S3d1b0tQ?= =?utf-8?B?WkE0RjNCQjJxazAvc05mT0pXVm9GNDA0TGVmUEdLeU8vbFBBa0tTYXZhQ3ZV?= =?utf-8?B?cjIrYnVZZHNYV055TWFpTi9VSWVBWDFic2RmOVplUHA4SjZDL3hXYlFKWUUr?= =?utf-8?B?c1dINncraXdGZzBpRFkrN0thNVBsQWN1b3h6TEVONDh0MGJZZWp4QUI5Z1Bi?= =?utf-8?B?UjBXTHZ6c0NpblNPczdXWDJ4SlFKRWdzSnBqUHBvV3JYcDJtS3NNb2g5cmJw?= =?utf-8?B?MExtUEI3UGFrMzhLSEhtREFNZGtZWVNiZytDSmJQTVBaV2pVTHJtSmhwT3py?= =?utf-8?B?SC93L2tCVmFjelJPUi9QV1ltUlhZeXoycXR5RjdRUHRKU3AxODBRSjkwQW9F?= =?utf-8?B?VGNXTzhWRkJEL3g2d0xacE9VMlcwZ0tKWUFMaERlNitYSTEvUWFaS010UGVQ?= =?utf-8?B?T3F0N3puNEVHdHZDUjYzRE5SY0tLbTBtRUt4VTZnSStxR2ttay9GZWxNeity?= =?utf-8?B?bEhOK2ZHYndCVjhlSVVOa3RHd2NxbE5QVWlmTW9VcmVkKyszbS9CamYyMndn?= =?utf-8?B?bW1XMmI5aTZJKzNUSFBoNTAyaElVUjJXYUQ5eERPRGhNVUFDQ21GYURrVytB?= =?utf-8?B?czRyVG5oWmxFaGNNYW9FdnJJOEg4U2lUczZ2cW1TdGpZZ00ydmV2c1hhY0RI?= =?utf-8?B?QnN2NEYwYmQ2TkNUVnFpVk5xSEtsRGNxTTFRQTVDcmt3U2lHZW5FbGZneFI3?= =?utf-8?B?RVFDSDVRbUpOcDAxN0tLcDNyUnJsTG8vSkJpQXI0ZmJzY3g2TDZlakVzS2tD?= =?utf-8?B?b2hhUFdCYi8xeHBMdEFTMVBPMGFTN0pjdE1lcnRCcHRoa2RsRjlrcXVqQ1FH?= =?utf-8?B?aWRhNXJ1VXBQbWdzYUhXdHVFc09BZWpNbStseFZtZFBYYUtGU2F5VXVWOWFw?= =?utf-8?B?NzFYNURZU3NVSjRBZzdSOFZmc0NDUFpZS2x0OWY5Q21NQ0xlaTdXMlhMdDNR?= =?utf-8?B?bVNTb1JIaFVyS3puZ2VyM0ZJVnc1V3VaK0VEQW5sTWtqYlBwZmcrcEF6R0dD?= =?utf-8?B?YmFaSmFpdDlMUWpobHFPa3dKRUVMMUtSM1h0MTh2R05BOGdIZW9sR1VSSHpJ?= =?utf-8?B?cFhGbDdwYlczU2hIYUMyaEFPUXpVNEdSV2VaZWp5Q2wrWS81cThiVGlrYmNo?= =?utf-8?B?cC8zeG5UK3BFSE90TUEwVHhocTBENTdxdE5jeGFHVm8vM01LMk90d1owTzFP?= =?utf-8?B?Vml2TTdlTUdLeVl6ZE5xK2VnWVJFL3UyazQ0ckJlT3FkRWJaVlErazZlcXJM?= =?utf-8?B?a3NFeFBSajhDNzJlVE0zWnJPQzFRMkxDbCtRNHJmTW5HVW5VUnNoUit1N0xv?= =?utf-8?B?Z0JNTFJTWk5PZTZMdnZiWXlIZ0RwdUc5dEQ5UFhTNHl4THZMK2hLVXRKR0lD?= =?utf-8?B?QTJkem1RVFFaYW5LOEpkdDVBMlc0TUhSejNNNng1NTArUFJWb0s2N3FQcWFm?= =?utf-8?B?ZHB6aDFDVmUyRGI1bXlnOHUxSncxbUNZcnpvcjBJTXY3S0F0dlF4ODFlWnpI?= =?utf-8?B?OThvZ05QOEVXczBJWDkzL2d3WjNPYk56d04rb1NGMU5wQ2gyUkFYcitiZG9w?= =?utf-8?B?d1MzQVBDam1IcTJaM3hiVU1qRVozTmk3U2pVVUs2cGdqcHArTlg4aEZtS092?= =?utf-8?B?eEFmUWM4b2YxK2ZRYys5NVlHa3JEMG8rb2dLb1ZpRUF2bnpBd2o3UkNRU3Zr?= =?utf-8?B?MEUvVjNGRVd0L2JxRmtwSVJVTGNwWWFrVDBOZzFLV1lSR1ptcWFENFV6QnFp?= =?utf-8?B?ZXpoS3FtLzZhSUFGaERCSFA3enBMUG41bTE3WE1WQXRSRDV5alpHT0RqQkQv?= =?utf-8?B?V1ZScHhxS2Iwd05YQm85MUhaTVkwelMwS2xKLzA1eWk4QW9tdVdqa2lGc3BF?= =?utf-8?B?R1pCNnZmajRJem5DSFhlMGRrSmtMa0JSc0kxZC9GU0NFdTR4RTBHYU4raEJo?= =?utf-8?B?SjhmcHllenV0UlB6RnNRTzdNRHkvV3NGaDNKODdNeC9hYUpXL0NlY2xKeTdW?= =?utf-8?B?Y29HQk5GbTlRLytSOWcyZVVXcEZNUm5wQ2k4YWx3Q0RlQ1pUcW1YWmYvamZj?= =?utf-8?B?R1NydXI0b0FxY0hsUVFlRk5KR0lPeEFJazY1bTM0R3YvMkFoemx4V3o5U0JO?= =?utf-8?B?cVB3UUI1M2d0cDZzREUzdjhwT0t5Z2R4ZFp5WmpiVnNKM1BWdnd6YnlLNVV1?= =?utf-8?B?d0YzNHVoVXFITGZuUi9va3ZadzFZVEtDVjVXVE14QXVhN0thWUQ5Y1c1SmJw?= =?utf-8?B?eHZqVVRXSEJJTDdMYzB6b3kzWXFPL3JqZUgrNklZMHNGZmdDRFNtQT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81e1690b-3160-4d79-c854-08df291ed27d X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 11:40:46.8383 (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: R8YXGjzlpNhtcgVVjCyqyCm57x42gGDwQ41pP1k+aCFaY4oj/fidNXe13eg3I1VZyUV1sMZWiBasiUXbbtCnzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8232 X-purgate-ID: tlsNG-4011c0/1791891652-51CC3CFC-AFA69896/0/0 X-purgate-type: clean X-purgate-size: 1153 On Tue Oct 13, 2026 at 11:17 AM CEST, Jan Beulich wrote: > On 13.10.2026 11:09, Alejandro Vallejo wrote: > > On Mon Oct 12, 2026 at 12:15 PM CEST, Sergiy Kibrik wrote: > >> --- a/xen/include/xsm/dummy.h > >> +++ b/xen/include/xsm/dummy.h > >> @@ -823,4 +823,11 @@ static XSM_INLINE int xsm_domain_resource_map( > >> return xsm_default_action(action, current->domain, d); > >> } > >> =20 > >> +static XSM_INLINE int xsm_lookup_sid( > >> + XSM_DEFAULT_ARG const char *ctx, uint32_t len, uint32_t *sid) > >> +{ > >> + /* dummy policy has no security contexts */ > >> + return -EPERM; > >=20 > > nit: Perhaps -ENOSYS? or something like that. It's not that any > > permission was violated, it's that the real version of this function is > > absent. > > Yet then still e.g. -EOPNOTSUPP, but certainly not -ENOSYS. That'd also be ok. It would be helpful if there was a guide under docs/ in which we state what each of our errnos are meant to be in Xen terms. ENOSYS/EOPNOTSUPP are great examples of such mixed usage that it's disheartening trying to reverse engineer the policy from their use. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Oct 13 11:46:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 11:46:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447035.1663191 (Exim 4.92) (envelope-from ) id 1xGaxx-0003N4-Qi; Tue, 13 Oct 2026 11:46:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447035.1663191; Tue, 13 Oct 2026 11: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 1xGaxx-0003Mw-Ms; Tue, 13 Oct 2026 11:46:45 +0000 Received: by outflank-mailman (input) for mailman id 1447035; Tue, 13 Oct 2026 11:46:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGaxw-0003Mq-D4 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:46:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGaxv-007jFx-LJ for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 13:46:43 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1a18-e002-0a2a0a5209dd-0a2a4509e4b8-30 for ; Tue, 13 Oct 2026 13:46:43 +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 6ace1a21-be1a-0a2a45090019-a237832fc970-3 for ; Tue, 13 Oct 2026 13:46:41 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 0CC4F4EE0237; Tue, 13 Oct 2026 13:46: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; 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=1791892001; b=ZDwOWxz8c5Y4cae5MnGwmJNevFbdLAQSYENXLD0dRxPnS9WFLbYoHbbZbjE/x8oULRvi vovuKbAs45uSSR0xYbmwTRgT2POWNSIbh50u1K4toGNFDG36zxC3zx1BqCRvN81RGYzAX qh8+xE/AJhLM3M8xyKOgczeOzPwlkeH+Ibi72u8+yhEaalfuQdZuXNUlCN9GsKM+SbGXa hvp2Ue3nAh5CBkta2aORZ4uKyjdKOAcvScQCdZzMTM3cXO1FabDUq4TW4iwLLo/1PfB03 GaSNQhD82CNkfiT+cxcjjo/EFrxkSbsgNtB065g7fmrVWMZGDVAc/N7oTV1239qLmYH3H ToX8LRskreut3e3r0QcrdqPxpf19aROsR3hE8LtWNpG0Dc7mK+5CFl2u8IwyF7mAUCdiS 8aDEANuBsG/THWfs+6RuMiPNMVR/DqutjzY+seHlEMuUUUpnhfnBLHwFm/pfBF5OPyrLX mgxF55VyJMBmu9jen5UHDW2TYnfNbdd1s9BzdPuYOIA0tiaMctLHMWzzFUQBmaDeNzrSk Wv+t++TNJiRnv5GQDrN6YYa0p5i6ycujfWKM9EvYrHt3Gcad/9qU/Hd277neutyhYJNlW 52yzU4gX4BMAtjudPs9qxepdlRllZrl3x5nfjEE59BOJgs01zIOCoO9hVi8JUjU= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1791892001; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=0aFJGHn6IXliAaZZ218UHdsSPfPzBsMF6hxm+/N3Td8=; b=0smyOpQDTfDMiBA2rqPDXnaVl5IjvFXJfMfl1a5epufHcRbS1tCCYLjhNcI6sogVuWDy qAnXPDaCDGxvs+vk+G6YOJ4d36eYhZKpNWbK4wFR5UsZwZw8Df3gJytoh0CMeIs0ZoS07 x10hSK2ScVUetpAIAI6KFnFqxY+bAJGg9fMuG565gO/i2A008o0uFcRnH65V1YjxHcGbk 0DoTTk5IZi47zf90tBFvX1g/c4BxWgfcybCDcVL9mDNwLAMt47ObX/8A6Uu0/VfLmVfOx YvXAqo0nNrcHfQbA/dju4iEY3Q88CDzx3AoxyGiXpUvIPHQWFhXFF5aUBMxhak31l8Mp7 G/Vu315zeBfZopu23GKFgDL/oHktSAlvQtCd04rLT7XfOcZ4vXYLK9U11lT+wkUILtfA5 EJn1Q3eGOrIlmibhO604VdJPn7w0euBldu9r6V218kg+OowayO/Odp9GTFU/meuriKnvt t5yrwC2EMlvy9Nll60yjCcmY1IUQs3ld+qQuAR6ecdSUikzdhb+nBswbY2wwIqMuOdL8V khp/mdcx13kIWVnI/6lrLLUoSvbexFrDl5odVym9u8cEgW9twqnZ++WcamrvEos4+X/nb DBA0kc3HyPUizTyRMkTNt/GvBPPA5EIFAKzRBKrGhDYb1yw9GOOxHUuoPW+CwMI= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 13 Oct 2026 13:46:41 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Dmytro Prokopchuk1 Subject: Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation In-Reply-To: <96319798-7cf6-4905-9b1b-37bb6a41bdcd@suse.com> References: <5b5cccc8bbbc4c87fc99427eb4c1c413@bugseng.com> <96319798-7cf6-4905-9b1b-37bb6a41bdcd@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/1791892001-BDCC7034-DA8BD8C2/0/0 X-purgate-type: clean X-purgate-size: 3248 On 2026-10-12 08:52, Jan Beulich wrote: > On 09.10.2026 17:37, Nicola Vetrini wrote: >> On 2026-10-05 20:56, Dmytro Prokopchuk1 wrote: >>> The R11.1 safe cast only matched void noreturn (*)(void *). Accept >>> any >>> noreturn function pointer converted to a compatible function pointer. >>> canonical() covers typeof destinations, and >>> compatible_deep_unqualified >>> keeps the parameter and return types aligned. >>> >>> Signed-off-by: Dmytro Prokopchuk >>> --- >>> >>> This patch tries to cover both of these: >>> >>> 1. eclair: widen R11.1 noreturn cast deviation >>> https://patchew.org/Xen/c6632dd805a119aca54b9d1ae2eea68ef9c1334c.1790674358.git.dmytro._5Fprokopchuk1@epam.com/ >>> >>> 2. Eclair: relax "noreturn" function-pointer conversion deviation >>> https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com/4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com/ >>> >>> Test CI pipeline: >>> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2914802667 >>> >>> The only one Rule11.1 violation remains, which is covered by this >>> Jan's >>> patch: >>> x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() >>> >> >> The change itself is fine, but the aspect I'm concerned with is the >> following: if you have a function marked noreturn, the compiler is >> entitled to >> essentially remove any code following it, so in principle this could >> be >> the case also when invoking a function pointer (i.e. the compiler has >> no >> obligation to retain code after a call to a function pointer that is >> actually a noreturn function). While this in practice may not happen >> often (e.g., the analysis done by a compiler is probably too shallow >> to >> actually infer paths where the function pointer is only ever assigned >> to >> noreturn functions when it is called), it is still not completely true >> to say that the behavior is not altered by casting away noreturn. > > With "behavior" here you mean that of the compiler? Because Xen's > behavior > won't change if the code following such an indirect call isn't > eliminated. > It will "just" be unreachable code then. > > That said, ... > I was more worried about the other direction: code that is expected to be executed by the developer that is instead removed by the compiler, with (rightfully) no diagnostic. Clearly if code is not removed it would be unreachable, but such that a static analysis tool or compiler will likely not diagnose, precisely because the attribute is dropped, so there may be missing diagnostics. >> I have >> given in [1] my R-by to the previous form of this deviation, but I >> realize that this aspect should be mentioned. This is of course >> supported by testing and code coverage evidence that the behavior is >> indeed the same, or a suitable guarantee from the compiler vendor that >> the behavior never diverges. > > ... making this explicit in the patch and/or deviation description is > of > course not going to hurt. > > Jan -- 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 Tue Oct 13 11:52:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 11:52:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447046.1663200 (Exim 4.92) (envelope-from ) id 1xGb3V-0005Cy-HU; Tue, 13 Oct 2026 11:52:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447046.1663200; Tue, 13 Oct 2026 11:52: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 1xGb3V-0005Cr-Dm; Tue, 13 Oct 2026 11:52:29 +0000 Received: by outflank-mailman (input) for mailman id 1447046; Tue, 13 Oct 2026 11:52:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGb3U-0005Cl-N6 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:52:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGb3U-0010G8-3s for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 13:52:28 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1b73-8faa-0a2a0a5109dd-0a2a450ba9c2-38 for ; Tue, 13 Oct 2026 13:52:28 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace1b7b-b7e8-0a2a450b0019-d155dd2ee9d8-3 for ; Tue, 13 Oct 2026 13:52:27 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48bbb06e746so1674924f8f.3 for ; Tue, 13 Oct 2026 04:52: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-48de0bc51c1sm4673046f8f.46.2026.10.13.04.52.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 04:52: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=1791892347; x=1792497147; 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=mg8gq59D07iMmlfoqNuyO9BPROaJRpOjbqvOhXjy8uA=; b=fK9PWkF1CdhRVLj8Fls0hgGfz5xarj97Dw4WDluuy2oWqZEuark6RRHFsLPdoyK7o4 2PoH6usBQoCQOaKhMplYYNX1FuHIEIK3DMn4nITFHCDn6gp3U59jwvLSBCckEryNCqHN o1q34/CQjBBxNqOcMUNTqjl0Y2m2d2A+r2UNlxtg2P1g9NfQxp35mqIoXy0bMgbojxl4 569/6M5CSp5Fe5G2Nim/lLP9ag7fLogKL9wPZXmCL+GWHMvUO7AmnZc2EBxTsW8IOsAS JrOZa2H8AOwDrEYVkHHsjU40X1uPb0pa5ng0HBNTZg9c8rwN1m7Z72R0o9yK7maNlTNY R22g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791892347; x=1792497147; 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=mg8gq59D07iMmlfoqNuyO9BPROaJRpOjbqvOhXjy8uA=; b=QJ+YFxcmcrzRVCmwexyjPTx6nrDGgwiU7PHpKog2Ky68GR5bcFDoJMesW9NLuVf8yN P/iZHdXjWtR0neatiK7xcb+lmim2zFJV3czymo73Yb8am52eUwjefsnyYxSFGX73AmzL qyItV+1gPW/AAX374xipWAj/2JptxhEaTsCMYQR4GBx2mZu7ALhmwKfar6qkpoUkd1Ez nIJC62v59D2InMGU+Dpto2SJKbrH8+Xu7IR2OTwhi1KU8zIFUO94jdIHiHPwe2Aq0xWc fhfH5f3DGr6wQ1SUT+4DGSUAnnjFAkMhrdDYdXUfFhAgl1VsaQmaMWxJQK1ZK7o3hJe5 Lg/g== X-Gm-Message-State: AFq9FYJvbfeM6zn/WvRn2C22a5dxMER8N7ooSyKzEJJwRzPsz5Ui87AJ 9uyvLPHmS0bvoUXckKWkQxoNzz7FFDk36IQsZTxU0KrNWl1l+jjDqbXWT0EcaArlMg== X-Gm-Gg: AYBFou11Qbxb1G6CMMoHU8zifL/sOPGbW7BfKHJxzTTDafcV2K7KTQVCVOxbOXd2kCz vB7Psdsmr61YHeBA+Gb0qLLpl6Ff7zrg3VyRU9jgaqQWUghx5wq1CvVUPCHKvOq3V10U/Xzp2J9 cJ7kzmkx6V/U7qSJLBYpdLQnM2wokRGfhW34Qe377IFNiXik199OqSmKNUQQz7Xvu+OIL11FcCK o/9M8dtYF6rMIbwxViYc5AElVMBiMcZ0B7kUxQCbBG6+asPhaH3F4ZX5vwlpXcN/SuRBgBsiYBt Dt7odNJfnNTtg8ppWBf2XkigAJFBzc4zTepS2WmhG9419P/6qv1Pcm2fpe+8bSybUqu1aKPSp9S vjohWST5Ydp8HkF9hGQhxLs+fkL+bMo6ZEFkHis83s16RO+A3baoEk4IEQ34Y2vKHPOWhjwfWH0 np2kcAn42Xq9PYtCEl/MgyipQOhkJ0nW4CEOT3kf7mGbs8wArTTe4Yf6xlZEiE/4UvXZzLe/GE4 HznoxkyowsVcrgI7xHDFodACvLfwVwoDVAPRdRVcz0vQ5UR61ZFhyGbiRpVpw== X-Received: by 2002:a5d:5888:0:b0:48d:df2c:64fe with SMTP id ffacd0b85a97d-48ddf2c6c20mr6947785f8f.41.1791892346437; Tue, 13 Oct 2026 04:52:26 -0700 (PDT) Message-ID: <9e587bff-7fb9-416e-a4b6-6cb13ec39a6a@suse.com> Date: Tue, 13 Oct 2026 13:52:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86: replace this_cpu() uses in mapcache_current_vcpu() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <942facb0-c42b-4f09-9081-6cfb006c7bfc@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-42698a/1791892347-ABCD79EA-5EFEA39B/10/78276251493 X-purgate-type: spam X-purgate-size: 3043 On 13.10.2026 12:15, Roger Pau Monné wrote: > On Tue, Oct 13, 2026 at 11:06:27AM +0200, Jan Beulich wrote: >> We have accumulated three of them, plus a hidden similar 4th construct >> from smp_processor_id(). Latch the result of the latter into a local >> variable and use the slightly more efficient per_cpu() instead. >> >> Signed-off-by: Jan Beulich > > Oh, so that's kind of what I've suggested in the previous patch. > >> --- >> A 5th such construct is "current", yet to replace that we'd need to open- >> code both it (i.e. get_current()) and then also smp_processor_id(). I >> wasn't quite sure whether that would be deemed acceptable. > > See below, we can reorder and use the processor ID value stashed in > current? > >> Like indicated in the earlier patch, this similarly leads to the function >> actually being inlined (and hence generated code size actually growing) in >> gcc16 debug builds. In release builds (with older gcc) the function is >> being inlined no matter what. Overall, having looked at generated code >> differences, I'm not quite sure anymore whether the earlier observed >> inefficiency with repeated this_cpu() really is much of an issue (here or >> maybe even more generally). > > I think we sometimes focus too much on this kind of > micro-optimizations when the cost of the operation itself is orders of > magnitude bigger than any performance difference the optimization > might cause. Well, any improvement we can reasonably (and safely) make counts. Even if not measurable performance-wise, it may still make a difference (also in power consumption) when accumulated over long enough a period. > In this case I don't think the resulting code is bad or harder to > read, so I don't mind adjusting the logic. But that's a question of > taste, if someone else has a preference for the original form I > wouldn't change it. I'll give it some time for comments to that (or any other) effect. >> --- a/xen/arch/x86/domain_page.c >> +++ b/xen/arch/x86/domain_page.c >> @@ -20,7 +20,8 @@ >> >> static inline struct vcpu *mapcache_current_vcpu(void) >> { >> - const struct vcpu *v = this_cpu(pgtable_vcpu); >> + unsigned int cpu = smp_processor_id(); >> + const struct vcpu *v = per_cpu(pgtable_vcpu, cpu); >> const struct vcpu *curr = current; > > Maybe you can reorder the variables here: > > const struct vcpu *curr = current; > unsigned int cpu = curr->processor; > const struct vcpu *v = per_cpu(pgtable_vcpu, cpu); The use of curr->processor in the remark in patch 1 was safe afaict. I'm not fully sure the one here would be safe: It would require thorough auditing of scheduler code to be sure, I think. (I don't _think_ ->processor would be altered from a remote CPU, but I'm not entirely certain.) > So that we avoid two smp_processor_id() calls (ie: the hidden one in > current). Strictly speaking there's none hidden in current. That accesses a different cpu_info field. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 11:57:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 11:57:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447052.1663208 (Exim 4.92) (envelope-from ) id 1xGb7t-0005tv-0z; Tue, 13 Oct 2026 11:57:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447052.1663208; Tue, 13 Oct 2026 11: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 1xGb7s-0005to-Td; Tue, 13 Oct 2026 11:57:00 +0000 Received: by outflank-mailman (input) for mailman id 1447052; Tue, 13 Oct 2026 11:57:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGb7r-0005ti-VU for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:57:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGb7r-007lal-84 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 13:56:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1c8b-8faa-0a2a0a5109dd-0a2a450995aa-0 for ; Tue, 13 Oct 2026 13:56:59 +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 6ace1c8a-be1a-0a2a45090019-d1558035a9aa-3 for ; Tue, 13 Oct 2026 13:56:59 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49e73611928so30711415e9.1 for ; Tue, 13 Oct 2026 04: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-4a18c85009csm280040665e9.2.2026.10.13.04.56.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 04:56: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=1791892618; x=1792497418; 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=Yo727WvnGhExRxgrLCwn3w6kydndywV/v9mdbK8SEqM=; b=g7RC44AvQeV+N7H32O+qXg7Z48T9v0+5i4v4y/qF40OVS0kM9+gwSYZ6eRMdZRig/M jf08EtoipRxcfGDwAUUrY/NPa5jD1t1Q2E3vKdrG+eWOYeaL3wn/JITPfxY69eh3ixUz qCjfzKXYmh6HybHXClebQsJ73dalrmQooGTcOKngTlh87yYiBFGZM0zYrYeY4Vv9eqkT EL+vmVTuS1I4Btq2r7unqpEcr7WRqFB2Wu7f/eBN4sHKJIVQd7aeRiE0Mg2/mdCoK1t3 G3z3nlvYYXxbUwfsQwapRb0cNao3xKsliuVD5TbMzyATjow4XFV+aQuCpJlOsamHYypq hY1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791892618; x=1792497418; 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=Yo727WvnGhExRxgrLCwn3w6kydndywV/v9mdbK8SEqM=; b=NopJqWNr7vL7zfxb7wgyIBsR8PEMqEotQZSDOn+V89DgvI+sTNwGXsEoZc9lGVJN1c gpJzmrUbQ/lRiqAsR+Nkbh7JqVbr9ELE9oWBWwdHwVQrofETBcjcZrP4brtnYHW6Klpu RMgN8JSnlCmX7mr4o7vh0c0Go/8G97HYWSugaetPK+zPu21873WN53xKR+plGG0/onD0 T51GZL9cwaOg9Bl3gRBlycYE5uz8dSz0TX4DMV8A7SBkyzcrPSaLpsFI9bd/oRFKmfi6 cSFkMt0kuRFhX3pvB/PHhGS4J/4i6kO2WBHWoOGbcjfbj8FttYleTQz8iM5DtVQJDA81 a22g== X-Forwarded-Encrypted: i=1; AKwUvBywbcYXCKZXYfEWiXVq+A4COfY2OQd9cLTm70HhsuTt6ak7zkS3xeyA4xpOXTJ7SzusHgOFFXwoGGc=@lists.xenproject.org X-Gm-Message-State: AFq9FYIlH7/umgTNiw2Z7uQBdEemAAbTT/TxC9pUserzLuB5+KDMI0yQ GDjVpELLN4GqNfRM2BMVSv6MTP3+nXM6NJZiFS8qYDZ+fn0QxQqhncefsgmBnoLFuA== X-Gm-Gg: AYBFou38EpmqWfMBDWVOsE//TD89BFdUsBZpKwxrlifG5gZN/bG/er7AbY7QoCnqRUg 5rtFRoru8v84zFDJyGbM94e2CIqf7FlnUUnfSCS1h6O79IVT/TDoI+7Uq+pwaGUjheb24rxSBN2 8W6dcHOH/qNCbZG+poPiEr6UYoAMYQ3Ah/nesnel2RnyqHzyPxKKTcLfT1mjbSOQZWTS9Uhdesr 4fuyc31hN/2LU0TamsbpaQp/6kHePtWgI5xH8+anSPKkYqmTZxIN8W7s78v/CIjcb71VxkRrsUT MWfcdr01bqOoCQpb1nb80c0lyxT6ZRLLZVVzTNn6p24VIY3NEls8AClQnFOVBKpBGyqz8eb5Q4R ZrkwCaYu2WeUjyqXkSpRDqbbOFkWRiBRMwcycRrNOuP+qndPU9SF4+rgJK+CZ7Hii+CoIPDmf3W iCTrGNGtF/lrC97UTUweVRfwJgJ2macey8ysVUuS0Crm7AV1SY/8TsyFjoOM3MBrwdrt1W7jd0P ClKVUkTKNH/15mh8Qr/RBM2nZ+11VEWXBeEvTzZavZ4401ypMsC6YUfSItDlA== X-Received: by 2002:a05:600c:5254:b0:4a0:20b4:ba93 with SMTP id 5b1f17b1804b1-4a18e4aa11dmr250270595e9.16.1791892618512; Tue, 13 Oct 2026 04:56:58 -0700 (PDT) Message-ID: <71f51ddc-3034-4501-b532-e76eb9f898ba@suse.com> Date: Tue, 13 Oct 2026 13:56:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> <8514b7b6-cf1c-44d9-827c-675fd5a6708e@suse.com> <43f7a948-669f-48cb-8e1f-9d1a8a98a8f5@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/1791892619-FCE14034-97A8858A/10/78276251493 X-purgate-type: spam X-purgate-size: 4062 On 13.10.2026 11:53, George Dunlap wrote: > On Tue, Oct 13, 2026 at 7:26 AM Jan Beulich wrote: >> >> On 12.10.2026 18:07, George Dunlap wrote: >>> On Mon, Oct 12, 2026 at 2:48 PM Jan Beulich wrote: >>>>> @@ -74,12 +130,12 @@ void *map_domain_page(mfn_t mfn) >>>>> #endif >>>>> >>>>> v = mapcache_current_vcpu(); >>>>> - if ( !v || !is_pv_vcpu(v) ) >>>>> + if ( !v ) >>>>> return mfn_to_virt(mfn_x(mfn)); >>>> >>>> I don't quite understand why this is_pv_vcpu() is okay to drop. What >>>> mapcache_current_vcpu() returns isn't what it ran is_pv_vcpu() on. (Same >>>> in unmap_domain_page() then, obviously.) >>> >>> So mapcache_current_vcpu() is a bit weird; the actual invariant is, >>> "Return the vcpu whose cache structure we should use if present; or >>> NULL if there's no cache structure to check and no need to sync." So >>> if pgtable_vcpu is HVM, return NULL and just use the raw address, >> >> I was going to say "But there's no returning of NULL there if >> pgtable_vcpu is HVM, at least not at this point of the series." Only >> then I realized that I was being confused by there being both v and >> curr, and neither of them being pointer-to-const (i.e. both being >> equal in terms of which of the two might be returned from the function, >> yet as a result of earlier changes neither is being returned anymore). >> >>> because at this point in the series, both HVM and the idle domain have >>> full directmaps; if pgtable_vcpu is PV, then maybe sync, and then >>> return the result of the sync. That may be a PV domain with a >>> mapcache, or an idle domain with no mapcache, but in either case you >>> can then read cache.inuse to see if there's something there. >>> >>> So yes, it's a different vCPU; but it's still defined in such a way to >>> be safe to check cache.inuse. The only possible value *change* after >>> a sync is the idle domain; I don't think we need to do another check >>> to make sure it's still a PV domain. >> >> Yet then - aren't the is_pv_vcpu() you drop here redundant already >> before this patch/series? In which case (since it's not entirely >> straightforward to reason about and beneficial in its own right), >> might it make sense to have this be a separate change, with (in >> particular) dedicated justification? (ISTR having thought about >> making a patch to this effect a little while ago - perhaps around when >> Roger last touched this logic -, but then deciding that something was >> wrong about my reasoning. That may have been a mistake, as it looks >> now.) >> >>> In fact, there's an argument that we should modify >>> mapcache_current_vcpu() to take pointers to dcache, and vcache, and >>> return just cache; that gets rid of v as a local variable of >>> map_domain_page entirely, and makes the logic ("get the cache we >>> should use") more clean, and gets rid of one mfn_to_virt() instance. >>> That would require some non-trivial changes, so I'd rather avoid that, >>> but I can do it if you want. >> >> Sounds entirely plausible, but can as well be done as cleanup later. > > I'm a bit confused about what, if any, change you're requesting here. > Are you requesting a preparatory patch just removing the is_pv_vcpu(), > with an argument as to why it's redundant? Or are you OK with having > this cleanup work be put until later? Or do you want me to put the > is_pv_vcpu() back until we feel like cleaning it up properly? Now the confusion is on my side: Aren't what you suggested as further cleanup and the dropping of the is_pv_vcpu() independent? If it had been just your first question, I would have said "yes, if possible". But the following question starting with "Or" is irritating. Yes, that _other_ cleanup work can (as I thought you also suggested) be deferred. Putting back the is_pv_vcpu() isn't really necessary, as long as their removal can be properly justified. (Hence why I think that would be better as a separate change.) Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 11:58:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 11:58:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447058.1663220 (Exim 4.92) (envelope-from ) id 1xGb8w-0006VO-9u; Tue, 13 Oct 2026 11:58:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447058.1663220; Tue, 13 Oct 2026 11:58: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 1xGb8w-0006VH-7L; Tue, 13 Oct 2026 11:58:06 +0000 Received: by outflank-mailman (input) for mailman id 1447058; Tue, 13 Oct 2026 11:58:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGb8v-0006V2-85 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 11:58:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGb8u-001ree-L3 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 13:58:04 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1cc4-8faa-0a2a0a5109dd-0a2a4503a3aa-36 for ; Tue, 13 Oct 2026 13:58:04 +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 6ace1ccc-fae8-0a2a45030019-b9ff1c128637-3 for ; Tue, 13 Oct 2026 13:58: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 1a1352076650008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 11:58: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 8EFB4827DA; Tue, 13 Oct 2026 13:58: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=jlH5NbqAOH1MTnY6GYHY4LB8qfq/5ty+AI5nIqMo93o=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=fWAupGOBej2Oy0rSg1ncrIqO3LuvR/AkisgAaxdOMDYxRz/gBL8Udy0geSGqRapF+A2eKEEXR wyErLrvkNxpS/GTd76tW/aMrgVrOS+3t8rHlKtysZn61k0hUzPK5SNdgKx8SciFfu7wjJfaLQHV dAxcJFkAVdwNzMjW6zPZu7sOIhao6kgsNnJNpth2LjwkQdOIEalNNqHuub0ruBMxzLfGM0q5OC1 tnH1YHKucSLydNOsav6jTtDYbMskUKKhOie4dkrRx4PIrRBjctf1rmGDb5IoPop8Aci44QAltP6 biDCaMZvWVw4liLVjD2B1H0LS9CUB9zIZgE3V9buARfg== X-Zone-Loop: af9a13719ebc29d1a885dc2cc64fa44cc7e17218230a x-campaign-type: default x-transaction-id: d9e15f8d-2ad5-47c7-84ee-4a013b031c97 x-swg-uid: 01-cab0f3a3-358c-4c44-8454-e1310414f82b X-Mailer: Sweego Message-ID: <1791892682.8631fc262581453bbf619ec5b2062170.1a1352076650008425@vates.tech> x-swg-bid: 1791892682.8631fc262581453bbf619ec5b2062170.1a1352076650008425 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 v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org In-Reply-To: <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> Date: Tue, 13 Oct 2026 13:57:56 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791892676; l=4006; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=+LcknYPnhKs9gYEONHko0QbEaF3wRIXTL8NmWlffUJg=; b=b7uC8eD3TLUwg8FLHW/GudOM5cxIAHTZwnDCZi3IYcXB+qvnYzEZ7F8zqx9H2yNB9tIvBK2j4 bz9Fj4yGLcaBkP8JtiUEDJz1vpek4ocToIukmScjeW4CT8rTmE2PIE+ 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: 1791892681780 X-purgate-ID: tlsNG-33051d/1791892684-766FB4E9-FAB8AC6D/0/0 X-purgate-type: clean X-purgate-size: 4006 On 2026-10-13 12:36 +0200, Jan Beulich wrote: > On 13.10.2026 12:07, Baptiste Le Duc wrote: > > @@ -620,6 +623,98 @@ static void __init compute_guest_isa(void) > > panic("Failed to build guest \"riscv,isa\" string\n"); > > } > > > > +static bool __init probe_hw_ad_update(void) > > +{ > > + bool updated = false; > > + unsigned int slot = FIX_MISC; > > + vaddr_t va = FIXMAP_ADDR(slot); > > + struct page_info *pg; > > + pte_t *entry, pte; > > + mfn_t mfn; > > + unsigned long tmp; > > + > > + pg = alloc_domheap_page(NULL, 0); > > + if ( !pg ) > > + return false; > > Why would you need a fresh page here? Can't you create a secondary mapping > of a page already in use (e.g. one from Xen's .data or .bss section, or the > stack page you're running on)? You're right, I will map the current stack page. > > > + mfn = page_to_mfn(pg); > > + > > + arch_pmap_map(FIX_MISC, mfn); > > + entry = &xen_fixmap[slot]; > > + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE); > > + write_pte(entry, pte); > > + > > + flush_tlb_one_local(va); > > + > > + asm_inline volatile ( > > + "1: ld %[tmp], 0(%[va])\n" > > + " li %[updated], 1\n" > > If you mapped the stack page, you could preset a variable there to 1, load > from the alias mapping of that variable, and then avoid the LI altogether. Yes mapping the stack page appears to be the best way. > > > + "2:\n" > > + ASM_EXTABLE(1b, 2b) > > + : [tmp] "=&r" (tmp), [updated] "+r" (updated) > > + : [va] "r" (va) > > + : "memory" ); > > + > > + arch_pmap_unmap(slot); > > + free_domheap_page(pg); > > + > > + return updated; > > +} > > Imo you'd better check that A also was actually set in the PTE. Right, I will do that. > > > + > > + /* Neither advertised: trust the probe. */ > > + __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, > > + riscv_isa); > > Hmm, this feels fragile. Other schemes are possible, e.g. A being updated > by hardware but D being left to software. Are such truly precluded by the > spec, including older versions thereof? Furthermore, probe_hw_ad_update() > can (right now) return false for unrelated reasons. Since 1.10 the spec lists exactly two schemes, and each one covers A and D together: either a clear A (or a clear D on a store) raises a page fault, or hardware sets the corresponding bit(s). A-bit being set by hardware while D is left to software isn't one of them. Before 1.10, the hardware must set the two bits. Therefore, there is not other schemes possible. > As a consequence, patch 2 imo also can't leave the A/D pre-setting unaltered. > It perhaps needs doing unless Svadu is positively identified as present. I agree it is more robust to preset A/D bits unless Svadu is truly identified, i.e. advertised in the DTS (without Svade) and confirmed by probe_hw_ad_update(). The worst case then becomes the probe failing for an unrelated reason on hardware which does update A/D: we'd preset A/D needlessly, which is harmless, as hardware only writes the PTE when a bit is clear. To sum up, and to avoid unnecessary respins, would you be fine with: 1) Keeping the probe as it is, with your remarks addressed (map stack page). 2) Presetting A/D bits unless Svadu is truly identified as above. > > > --- a/xen/arch/riscv/include/asm/cpufeature.h > > +++ b/xen/arch/riscv/include/asm/cpufeature.h > > @@ -42,6 +42,7 @@ enum riscv_isa_ext_id { > > RISCV_ISA_EXT_sstc, > > RISCV_ISA_EXT_svade, > > RISCV_ISA_EXT_svpbmt, > > + RISCV_ISA_EXT_svadu, > > Isn't there some sort of sorting in effect here? No, as it is mentioned in the docstring that: * New extensions should just be added to the bottom, rather than added * alphabetically, in order to avoid unnecessary shuffling. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:02:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:02:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447066.1663230 (Exim 4.92) (envelope-from ) id 1xGbD6-0008EX-Vv; Tue, 13 Oct 2026 12:02:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447066.1663230; Tue, 13 Oct 2026 12:02: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 1xGbD6-0008EQ-SI; Tue, 13 Oct 2026 12:02:24 +0000 Received: by outflank-mailman (input) for mailman id 1447066; Tue, 13 Oct 2026 12:02:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGbD4-0008E1-Ty for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:02:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbD4-00FHrU-AV for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:02:22 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1dcc-8faa-0a2a0a5109dd-0a2a4504b27c-24 for ; Tue, 13 Oct 2026 14:02:22 +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 6ace1dcd-b57f-0a2a45040019-b9ff1c2293e7-3 for ; Tue, 13 Oct 2026 14:02: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a135245ff60008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 12:02:18 +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 098D482A53; Tue, 13 Oct 2026 14:02: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: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=vH4ryhxHfjpxScZaR+5GHwUz3vel3IrdJ29Pjj07wag=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=O8dyIsjWwEi6ggWBJIXSuMVyGHi2wEMA9c0GogfYlfiX30fppMBc2GbkU8gJtvtzWD6aeVAh5 YD35k29joE8lINrKNsqHL48ErkwWliq/wGn/CvVk6zm7dmY1FmGe9RkSZp+07H2enf2e4yN6Zu0 z/zEOczbKKbJquicf6VSC41+B05kKlpBkmZPeh4ZcDPaNyMboOHO5SUSjZ+pgEJnZ/hDRwdbZd+ 5K2t+ckY0nDJNxoWNOh667qO/P/Y34na9xqY+5qiToGZ6S6z1ambX8XSZzRA/6eRjhd0XIRkJCq /zxd92nqj7y6iSQD2gZ+8mkMXChbPEk5dmftzaa2Y/pA== X-Zone-Loop: 31308d98c1f42c3f49b93cf9198d3ef3754626494cd8 x-campaign-type: default x-transaction-id: dbffd92a-cd62-47a1-a25b-0d1feaacf644 x-swg-uid: 01-3c070210-9773-48a7-8d16-670b0725eaa4 X-Mailer: Sweego Message-ID: <1791892938.8631fc262581453bbf619ec5b2062170.1a135245ff60008425@vates.tech> x-swg-bid: 1791892938.8631fc262581453bbf619ec5b2062170.1a135245ff60008425 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 v6 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org In-Reply-To: References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425@vates.tech> Date: Tue, 13 Oct 2026 14:02:12 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791892932; l=3302; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=E73gw/8OOuaTvII//aH+XeLD9kXOIetzLop9Zywi2ps=; b=Cfh0Y+fitdviDMxZHimArV9ZKpf87tX9LsiD6beaoFGsvF6PieJUoh9A2RS/D+bxtPmhVBa8c BUj99m3foMiAkMHELwAXUH454kFlgICs7o3dbjp1bfvwUKB9J7l5knO 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: 1791892938226 X-purgate-ID: tlsNG-ebf023/1791892942-C3EC6B50-94130788/10/73395122804 X-purgate-type: spam X-purgate-size: 3302 On 2026-10-13 12:43 +0200, Jan Beulich wrote: > On 13.10.2026 12:07, Baptiste Le Duc wrote: > > Xen does not handle page faults caused by clear A/D bits, so it presets > > them when creating PTEs. pt_update_entry() does so, but three places build > > leaf PTEs directly without going through it: setup_initial_mapping() (the > > boot page tables), check_pgtbl_mode_support() (the temporary root entry > > used to probe SATP mode support) and arch_pmap_map() (the fixmap). > > > > Without Svadu, all three fault on first access. For > > check_pgtbl_mode_support(), the fault is raised by the instruction fetch > > right after the SATP write, before any trap handler is set. > > > > Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build > > PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in > > all cases for consistency with pt_update_entry() which sets it at runtime. > > > > 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 check_pgtbl_mode_support() to > > use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. > > > > pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one > > of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by > > masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also > > carries A and D, a reserved PTE with A or D set would no longer be caught. > > Mask with the V, R and W bits explicitly instead, and factor the check out > > into pte_has_reserved_rwx(). > > > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") > > Assisted-by: Claude:claude-opus-5 > > Signed-off-by: Baptiste Le Duc > > Reviewed-by: Oleksii Kurochko > > --- > > Changes since v5: > > - no changes, already reviewed and waiting to be merged. > > I'm puzzled by this, also seen in the next patch: For one, nothing is said > anywhere that patches 3 and 4 are independent of patches 1 and 2, and > hence could go in ahead of those. And then, formally, neither patch is > ready for committing - Oleksii's R-b isn't enough at this point. I would > have ack-ed the last patch if that didn't - contextually - depend on the > one here. I'm only going to ack the one here once either it is clarified > that it's independent of the first two patches, or once agreement was > reached on those earlier patches. (If this was independent, though, I > would have expected it to have got moved to the front of the series, to > disambiguate whether it may go in already.) Sorry I wasn't aware of that. I will put the last patch first in the next revision as it is independent of the other ones. Thanks for clarifying. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:06:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:06:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447071.1663238 (Exim 4.92) (envelope-from ) id 1xGbHI-0000Lz-EM; Tue, 13 Oct 2026 12:06:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447071.1663238; Tue, 13 Oct 2026 12:06: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 1xGbHI-0000Ls-Bp; Tue, 13 Oct 2026 12:06:44 +0000 Received: by outflank-mailman (input) for mailman id 1447071; Tue, 13 Oct 2026 12:06:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbHH-0000Lm-Sn for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:06:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbHE-001u1N-4B for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:06:40 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1ec7-2eae-0a2a0a5409dd-0a2a450c893c-48 for ; Tue, 13 Oct 2026 14:06:40 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace1ecf-f479-0a2a450c0019-a237832fb17e-3 for ; Tue, 13 Oct 2026 14:06:39 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id AD9634EE0237; Tue, 13 Oct 2026 14:06: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; 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=1791893199; b=V1TF2EXv5vT7Q0myfCBCID59r2MrQOSh/TWYkXfegRISN3rC7HdUcE+yTdXSOYBPR6Fo KEFSvVYORZsjhdeu66W/N9l/zHl5lHSBaDWMI8YXrvU8sONuZz0EGvxbue0IRBlbMWMXg oHVtqveU5FfqEs21v/ZvVkPsfLpa/vIkzv2aLimLlw7fr2ct2uwBGAo6hqCn03/XQjHxa zAsoLysC3rp5VWLzkFnT5+ahegcub7Tja3RKbwP47TptXrTgoM4RiJqSFL1dIZvs8dZjS Z+18BBGmspFX6+LLp2GcpcJwl2kvhzNIstOwviG7GLIADEITwQJH5buxc8Wr2IzPmi2gw UOthybB55kPkp/FeDbHNQF+KmCUs3u1xmWvJazbpytsvqpZRt2jPosF9MlDh8ng6lqKBd jk+AITOSxJ0CA3RWeEdrQ/uO5G38IJ0FR/L8F/vrH8FZkEUnPb1cUjqyJq58WjgsQBQSb nkb19YinBNIP2cxLkFsJiXjZOgl2kU4r403ESC2XOgPDv4t/WQx2Xh/vZbm64T6FAmGcq uTXMoUL8s4qcldWEqmB0hoqE51FH/vlzhI+yFHlArhwnazkYe9CQZDlDVgEJl7UOKtbwX 85cHh3KwH2bpXIctC6qt8jZePawlPo1K0ySkrlD5DIECeBo3/hC8I/lFBgM0ixY= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1791893199; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=Jqzi0kVZQgqe1ar74UQa/SvZKO0ouJTQ816MdMn1KmQ=; b=B3deMNOS4Hnl07HClA4BB9CzbkASKajgGCiNhsbzoIC+DxoArB46KgFgmfTxTwvfHGtN yFMT7Za2vKlqJysOZ3jRBOS+Arkwv3t8aBBKxPKSAMXN80fA5kLDqTgFLpTGpbEtZNgnS MTJqy/Y3x+yZ2vYej1MKCKcklHuJqdehsk7wRJIt0+qrUHx1O/bm6nUqkrpXxcY255APU NWxVC/OvGUZLpFHDMenIBAGOwe/8SUXlzo7tvKievVJ69IUrXtd4q6zlxym4d/lj7qDm3 yIuu92OUF76s1nvcX0lILB0T7b7If5p0pjeU8bYjJ6uq4wYlQEcMxTXOO4GqmYXMk5X2q SsB6Jo2TfXsqqTgaKveXMVxVf9laruQT0sMFw875fTWNMYPLSrLYha7CvUvdMl4XHWfuu I44dSoxIyE2b0Ow+EXOke3+VCHeG33OG9hw+o+e2GNe/otjTGGhHF7EaqrVsQxA7btW+g Kh6Mj0AqoWMJK92ICAe3/03Fl9QbUEc2QRMCtTwl9khqYJGR7pjLL7IhtX8TLmRWoWtay Mp4Mc54jfCuZmTOuS/JMasyhl0k5AEXqRJsi5NLR7iZYzF0bevW+oJbU4Vv/j9u6RqCbI 9LTuuXfQ7Xq6raDZ+K8sDpisvwVffX6Pzs4NKkK5bchw9hHzqKOXkvbXM/bf9qM= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 13 Oct 2026 14:06:39 +0200 From: Nicola Vetrini To: Dmytro Prokopchuk1 Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm In-Reply-To: References: 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-d25034/1791893200-01CC3A5B-D54C4CBA/0/0 X-purgate-type: clean X-purgate-size: 4445 On 2026-10-12 22:49, Dmytro Prokopchuk1 wrote: > The hide pattern .xen-syms.[013] leaves pass 2 visible. On x86 > LAST_LINKING_PASS is 2, so that is the final link. On Arm > LAST_LINKING_PASS is 3 and the final image is .xen-syms.3. Pass 2 is > usually only a symlink, so Eclair saw no program link and reported > every > translation unit as unreachable. > > During analysis preparation, read LAST_LINKING_PASS from the > architecture > makefile and the pass numbers from the foreach list in > xen/scripts/Makefile.link. Hide every pass except that one. An earlier > pass that is a real link stays hidden. The generator runs from > generate_ecl.sh, together with the other ECLAIR configuration scripts. > > Fixes: a401b5c9dc35 ("Eclair: re-enable scanning of the (almost) final > linking step") > Signed-off-by: Dmytro Prokopchuk Acked-by: Nicola Vetrini Thanks for spotting and fixing this! > --- > Test CI pipeline: > https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2940065908 > > Changes in v3: > - generate the hide pattern from generate_ecl.sh, which prepare.sh > already runs > > Link to v2: > https://patchew.org/Xen/e73c282694e68083305d03219f983bf74a8bf494.1791392326.git.dmytro._5Fprokopchuk1@epam.com/ > > Changes in v2: > - update commit message > - generate hide pattern before analysis > - read LAST_LINKING_PASS from the arch Makefile and pass numbers from > the Makefile.link > --- > .../eclair_analysis/ECLAIR/analysis.ecl | 2 +- > .../ECLAIR/generate-xen-syms-passes.sh | 20 +++++++++++++++++++ > .../eclair_analysis/ECLAIR/generate_ecl.sh | 3 +++ > 3 files changed, 24 insertions(+), 1 deletion(-) > create mode 100755 > automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > > diff --git a/automation/eclair_analysis/ECLAIR/analysis.ecl > b/automation/eclair_analysis/ECLAIR/analysis.ecl > index c6e1a7a95d..df1006bcaa 100644 > --- a/automation/eclair_analysis/ECLAIR/analysis.ecl > +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl > @@ -37,7 +37,7 @@ 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\\.([01]|alt\\..*)$"} > --file_tag+={xen_syms_tmp, "^xen/\\.xen-syms\\.[013]$"} > +-eval_file=xen_syms_passes.ecl > -frames+={hide, "kind(program)&&target(xen_syms_tmp||xen_efi_tmp)"} > -doc_end > > diff --git > a/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > new file mode 100755 > index 0000000000..e3795e8234 > --- /dev/null > +++ b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh > @@ -0,0 +1,20 @@ > +#!/bin/bash > + > +# Hide every xen-syms linking pass except LAST_LINKING_PASS. > +# The pass list is the foreach in xen/scripts/Makefile.link. > + > +set -e > + > +cd "$(dirname "$0")" > +arch=$(echo "${XEN_TARGET_ARCH}" | sed -e 's/x86.*/x86/' -e > 's/arm.*/arm/') > +last=$(sed -n 's/^LAST_LINKING_PASS *:= *\([0-9]\).*/\1/p' \ > + "../../../xen/arch/${arch}/Makefile" | head -n 1) > +passes=$(sed -n 's/.*foreach n,\([0-9 ]*\).*/\1/p' \ > + ../../../xen/scripts/Makefile.link | head -n 1) > +test -n "${last}" > +test -n "${passes}" > +hidden=$(printf '%s' "${passes}" | tr -d " ${last}") > + > +printf '%s\n' \ > + "-file_tag+={xen_syms_tmp, > \"^xen/\\\\.xen-syms\\\\.[${hidden}]\$\"}" \ > + >xen_syms_passes.ecl > diff --git a/automation/eclair_analysis/ECLAIR/generate_ecl.sh > b/automation/eclair_analysis/ECLAIR/generate_ecl.sh > index b955783904..b97fc55fd2 100755 > --- a/automation/eclair_analysis/ECLAIR/generate_ecl.sh > +++ b/automation/eclair_analysis/ECLAIR/generate_ecl.sh > @@ -20,3 +20,6 @@ > accepted_rst="${ECLAIR_PROJECT_ROOT}/docs/misra/rules.rst" > > # Generate the list of linker-defined symbols (must be run after a Xen > build) > "${script_dir}/generate-linker-symbols.sh" > + > +# Hide every xen-syms linking pass except LAST_LINKING_PASS. > +"${script_dir}/generate-xen-syms-passes.sh" -- 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 Tue Oct 13 12:10:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:10:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447078.1663247 (Exim 4.92) (envelope-from ) id 1xGbLH-00027Q-Si; Tue, 13 Oct 2026 12:10:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447078.1663247; Tue, 13 Oct 2026 12:10: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 1xGbLH-00027J-Q3; Tue, 13 Oct 2026 12:10:51 +0000 Received: by outflank-mailman (input) for mailman id 1447078; Tue, 13 Oct 2026 12:10:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGbLG-00027D-VZ for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:10:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbLG-007pFh-Cb for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:10:50 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace1fb8-e002-0a2a0a5209dd-0a2a450a8d7e-40 for ; Tue, 13 Oct 2026 14:10:50 +0200 Received: from [40.93.194.11] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace1fc7-f2d2-0a2a450a0019-285dc20b77f2-3 for ; Tue, 13 Oct 2026 14:10:49 +0200 Received: from PH3PEPF000040A2.namprd05.prod.outlook.com (2603:10b6:518:1::56) 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.472.15; Tue, 13 Oct 2026 12:10:42 +0000 Received: from SN1PEPF000397B3.namprd05.prod.outlook.com (2a01:111:f403:f90f::3) by PH3PEPF000040A2.outlook.office365.com (2603:1036:903:49::3) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Tue, 13 Oct 2026 12:10:42 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF000397B3.mail.protection.outlook.com (10.167.248.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Tue, 13 Oct 2026 12:10: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.53; Tue, 13 Oct 2026 07:10:35 -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.53; Tue, 13 Oct 2026 07:10:35 -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.53 via Frontend Transport; Tue, 13 Oct 2026 07:10: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=VWiisakxXyALZBFvNOKJ1ZZwTiCW271071s8NPnDAGF+e+1Y9b4jHZwZ0LcFfRvceaf8rdr/m8Bll/FxvQWFoW+ylljA/mDslHLoMd586+dHb20V/zFrkVb49SlW6ruN5OkWkIlVVn3TQxVPlArQzjUkhIkEy9sBqT4i72wirP8KidJwh6ynDe6QjzuAZt4BNNwDMgKIMsEIMD0NDUGIV3eHhjB3ZUCSsfPWuQzI4lPokVUpqis9sHKhUKX6nJudBUzeJ8kSkyG3ViWWn4eu/g4kHzTzxp8KF5LA9bANT8y1CnIqu+YfSN/rBzop4huTa0RFqBsXGVELnfblYsnipA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FlfHM9JD6FexhY6VBGhDaWriCWiJrXXLaCiMRaaNwh0=; b=g5GwaeZrRVZuessWNof4nMJgsc1eGvhZF9JXnsiiFsHlbnKPOD+YXcljqXqI/albqWdKPwz1jKYo7wZpXCAhfQqm2zo0wq9PfH09OMv06xoDvZnzoC4jiR4TbqyAF6B8cwrR18RxHFDB1gcFhmKj7iok6kbm5qfrmsJDMXjSLKGPm8lzs9seOT5vQuHevVhFyxGqV1uIL8Br6xSi6z57rocDDy6ChMCgO8jL76eVmjcOB2/pmSJu9iqZrKM74XXQY+fyVMPD5LbDo1EB9oUr3im1+BnJEigA4KO8F/nLEfT4V0HqZGhO9lAkyxjkEq/hJE6kNAUGPt2s9SSggtoRmA== 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=FlfHM9JD6FexhY6VBGhDaWriCWiJrXXLaCiMRaaNwh0=; b=C1Y60ZG8PW6+mx3+T7x2nBlGQ+NHQDBdR33K7X9fwYixgf9RrmiMnqSZj+w+RdCapba0r8RB2Y2ixINVfjBeUM/g1czb7oqXOGqeJsl1/132wrgXR1JWz/T1Ry5RGwEaiJptTNiZb2vVLQ4/DjCGr+5UXtzuOGhPjdOuP0DGmNM= 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: <132a2374-bdd7-465b-bb33-92be961c4393@amd.com> Date: Tue, 13 Oct 2026 14:10:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] 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 , Jan Beulich , Alejandro Vallejo References: <20261012101453.949907-1-Sergiy_Kibrik@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261012101453.949907-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: SN1PEPF000397B3:EE_|BL3PR12MB6572:EE_ X-MS-Office365-Filtering-Correlation-Id: e003c522-0bde-41cd-83d0-08df2923005c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|82310400026|1800799024|36860700016|376014|6133799003|10067099003|22082099003|18002099003|56012099006|261009223027099003|11063799006; X-Microsoft-Antispam-Message-Info: YxukH5kK51cxaIZg1shz8tDKq7OXP5FjJ2j2VpXFHKbcRGs+JDZZFdLR8B3q6yWlgDyqPGJpKnFq7zx1ds6OAu/y6XobCvFeJY25AfzwnnAcWsqUqJaEoONa4TcVwCuS5LWB2s5qkBNrVqysIOonASXlIF0Ja8z9v2SyZR9NuIY1G46Db8FGuo47cPhqk+8CFZ0RmwO2qCyG7E78H9yfenSLF+sU3C+fzBxXmC0znkXwk36LESpwlg1aQPuHAEWP9izpxwCt4i8Ym3Ss/UZnLGjK4XUb53MUCKr27WNwmX9RlTyj8tjzRmEMclgjblQmntKAQgEu3pIfZzMb7QgIdo/S7/tkWe/XXhmzNeNiFqWicVLUDQ2JYLbtpO98+eTowvl6L9vzHfjFeOcGT/WGVwaYf/YJfqj/7hScpeEhpwWwCuBCLzS90/QdYi8P58Gr+h+3UKKZcTLt6FfknPnCt6ex47YlR1gErO9VLI/c8YRP1a17YiPNuUbNt71/G9HmXBDerW7DI3Y0F1jEV/BiBh9AeF5XjvelCah1bztmZUKJibR5VnusL2KVZLOBBD/erIokLtk87if0kpEMDuh/bjls4N5ch1ghTl1GsoXfDcpzoE48eZJkcXVMjIxcQeWR9SSiJ/ku/xmfsgtyRsAsrH9diQjP/55QxuXU+/nyQ+6afSAFeIN7+liqtZQsxu+MX9waemb8kxHP/o/PMwmd5w== 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)(36860700016)(376014)(6133799003)(10067099003)(22082099003)(18002099003)(56012099006)(261009223027099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: LxhCnkI2yU3lgrM+AxGH2DVV0fXRLOMpsJjBJVzxehFx5K1+ot4csmKOreIGi2t0GiJT872+ngyoIyfyDtAVfP3mw5SEOJzL6s36GtZqUvZAARafahdil2y92uxXqeuBbbLASXumxqTkTBDESbtWaWjfIViyESW9SSFYAwQ5Uabw1ZyntM9O9X/ZA44Nma7LDMschPIpUz1p07MWKKhJOalmLmPuQDM50U66bgD7YYsaA3/DN4o0PnVTmWJchzzsuys8f250NOd1rjzR+weTGGUHL7/oY5Vz7MBuChWJXeCYxBMl2V02gePbJDEj5SGx29T36b7Gv3u6b85HrM1LaSQcBFJ7t4w+Xw8GU5qk54YioDe5xKvwIa2h4oyiedAK6DaPNUhNsnDAtXZJA0vACvVORNKjAWDoDfGv5OEVfAOwvLejIWvnSC5m4VFMYJd+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 12:10:41.5890 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e003c522-0bde-41cd-83d0-08df2923005c 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: SN1PEPF000397B3.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-4011c0/1791893449-51EC2CFC-82DE1360/10/78276251493 X-purgate-type: spam X-purgate-size: 5099 On 12-Oct-26 12:15, 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 XSM hook lookup_sid() introduced as part of XSM API exposed > to rest of Xen. > > Signed-off-by: Sergiy Kibrik > CC: Daniel P. Smith > CC: Andrew Cooper > CC: Michal Orzel > CC: Jan Beulich > CC: Alejandro Vallejo Please move the CC: lines below the --- so that they don't end up in the commit message. > --- > changes in v4: > - introduce XSM hook `lookup_sid` > - at SID lookup return error if security server not initialized > - document panic if DTS property is used and FLASK disabled > - per Michal's request panic if FLASK disabled is left unchanged > changes in v3: > - panic if `seclabel` property found but FLASK is disabled > 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 | 7 +++++++ > xen/include/xsm/dummy.h | 7 +++++++ > xen/include/xsm/hooks.h | 2 ++ > xen/xsm/flask/hooks.c | 7 +++++++ > 5 files changed, 31 insertions(+) > > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt > index bcb06bc796..2a69d2537d 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. Domains > + will be classified “unlabeled” if this property not specified. NIT: Use regular ASCII quotes. Also, s/property not/property is not/ > + Note: boot will fail if this property is present but FLASK is disabled. > + > 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..b03cee0e8c 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 *xsmlabel = NULL; Please drop a dead assignment. > > if ( !dt_device_is_compatible(node, "xen,domain") ) > return -ENOENT; > @@ -141,5 +144,9 @@ int __init parse_dom0less_node(struct dt_device_node *node, > panic("'llc-colors' found, but LLC coloring is disabled\n"); > #endif > > + if ( !dt_property_read_string(node, "seclabel", &xsmlabel) && > + xsm_lookup_sid(XSM_HOOK, xsmlabel, strlen(xsmlabel), &d_cfg->ssidref) ) xsm_lookup_sid returns an error code that we could print on panic message. Please do so. > + panic("Invalid security context for domain: %s\n", xsmlabel); > + > return arch_parse_dom0less_node(node, bd); > } > diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h > index 6331859afa..029cddd5cd 100644 > --- a/xen/include/xsm/dummy.h > +++ b/xen/include/xsm/dummy.h > @@ -823,4 +823,11 @@ static XSM_INLINE int xsm_domain_resource_map( > return xsm_default_action(action, current->domain, d); > } > > +static XSM_INLINE int xsm_lookup_sid( > + XSM_DEFAULT_ARG const char *ctx, uint32_t len, uint32_t *sid) > +{ We need XSM_ASSERT_ACTION as the top level comment requires. With the changes above: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:25:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:25:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447096.1663258 (Exim 4.92) (envelope-from ) id 1xGbZ2-0004A6-6H; Tue, 13 Oct 2026 12:25:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447096.1663258; Tue, 13 Oct 2026 12:25: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 1xGbZ2-00049z-2F; Tue, 13 Oct 2026 12:25:04 +0000 Received: by outflank-mailman (input) for mailman id 1447096; Tue, 13 Oct 2026 12:25:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbZ0-00049t-Es for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:25:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbYz-00DHHK-RD for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:25:01 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace230c-2eae-0a2a0a5409dd-0a2a450a97fa-44 for ; Tue, 13 Oct 2026 14:25:01 +0200 Received: from [52.101.62.50] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace231b-f2d2-0a2a450a0019-34653e32925b-3 for ; Tue, 13 Oct 2026 14:25:01 +0200 Received: from SJ0PR03CA0188.namprd03.prod.outlook.com (2603:10b6:a03:2ef::13) by CY5PR12MB6276.namprd12.prod.outlook.com (2603:10b6:930:f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 12:23:56 +0000 Received: from CO1PEPF00012E81.namprd03.prod.outlook.com (2603:10b6:a03:2ef:cafe::7b) by SJ0PR03CA0188.outlook.office365.com (2603:10b6:a03:2ef::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Tue, 13 Oct 2026 12:23:55 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF00012E81.mail.protection.outlook.com (10.167.249.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Tue, 13 Oct 2026 12:23: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.53; Tue, 13 Oct 2026 07:23:49 -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.53 via Frontend Transport; Tue, 13 Oct 2026 07:23: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=rJTMp4rafzZ/nEvcx9nP1IzeioOp8Ms89qvP85vPzmkln9iYfobzGaO8lS+L+VwovTVkqaTn/sViYGAOCfd2qza5I63TPLdkubJMXjlqnPnsMi37xkHBzsnMDXdESucs5FSkCRb6zd2/5P9ulG+dD0ujl5M0gORNqqPWZWmK+twO0SEMTPwJqUywXb+T+sa1wpWj8o9GCFib6qf3WG4G/E+AyaeXmYJTRerpJAQ9jvB8iziX3jaf3WKBVY6PLc9ibTZCzfdUrnSnRzAZqzidda5gPFC5s7dFT9WeTHNVVestwj/GgTrjIVLgKKuNn7eNMgYLKuJ0pVl7WCVj9SyU4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1MV+J66FUncJRlCASOx9QYe8gbX+W2R4uu+cGPHcPQ4=; b=ZaBF+PFtrAQZJaO7Ri2UAk7E2wvb7Fr13GDAGL3jd+Raw/US8t+SeWlc3jDUpCiUC89a9X+4gbZ1W+vJvtQ3XI1d+efjEFqHUH5ue70MclGph9K7E7vVjTHwZF09/8frT0E6D4r3FZqEk1R/30GqCFQ+zSQEzYu8o/qEZx+NPMLp79cQAptHB/0/SRZCElSjdckQCWgc8Qdh+NNDFv82N1WxkWNHf5vNaH7/tR3BgPUs+1vEhE/CNANsU5b4iLVbu1WEFc3L8B56P/m3Iemb6sikF8646wrEZvi6i1xrVgGtXoILCCAtJN7aPiORAfKNtlMl2DUlIyS8pHowN5mYkg== 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=1MV+J66FUncJRlCASOx9QYe8gbX+W2R4uu+cGPHcPQ4=; b=W7Nay17ivo5FLOxzZYbxDdMA6gD/N0va4DQFS1oaAtoZGuoU3SydYatZ3HNcYtUEcxctqAt+O9CC+SFds29yY8z5pOoV9z0SYMy/sgLTDNJqKDQVBBaxUeURKl9n0muU/rGxxI6/uSUhOmN5LsuDbVfN7orgOrKM6hmV0DFn2xU= 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: <2482f3cc-e9b6-48d9-b8d5-a463feb82dfa@amd.com> Date: Tue, 13 Oct 2026 14:23:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 0/5] Fix ARM domcreate 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: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF00012E81:EE_|CY5PR12MB6276:EE_ X-MS-Office365-Filtering-Correlation-Id: 78a4f7e5-1be8-4361-0c10-08df2924d98f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|23010399003|82310400026|36860700016|56012099006|11063799006|261009223027099003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: S1t96G7mS1lerRVrywf90sL2g4x+8z6jHrwS5CGWadaeCaz9mdWlhLAaxD43kbCzVmimHxOU6w4TdBchPoowSdGjO+JyPaJ5VhXBqeK/EodpskrMg4oJn59eFWskzUPU/uESsmOZelswRvfGRAebINcAQCwoCY9xXg+tvS4KFIMvp1hOLzcBCSNeyvjG4l6BQThSo8h8AoyIID4eZNVHNT2Gj4sbyhFRzYgTXfaot4gE4g33W8G/waI0qzMGYD/SJ1kE9/+G53jWZ+wSSFi5EmRFZgD1AiVT5/jRt2fBsUoNdEluYrXv/uHgVt6Tm2dyXh0ijykOsvEFapnRjGWCfbBpqzQ7AvCbAHDu1yve+VjVgK4Qbac0tgXJrQHnGM8ha1s4xJF2pxc3yazrltt4rM7TScup8WIVjCzpUuW90nYj0FA9SNXMPbqA8VHnO+2/hmX3RVrrnHs4D8ozPVvwlsJMXKHbQx9zVtK64duCWQ6SWP6Q+Gdx98fclyI8k2BQlrm9YY5tQgdo9Q5kgQGpYnG3lb82gYLc0vVEuTRb0+YvrVNvJhgO9XL+UVVUmEQgUAQI9w8qzcMA/BpEDnkz4vxSZiTuPvSHZsy6dnf1dnxDHDwMYzG5tjqL5KInDQBlgKilABox4x1VRoAIA7VbCoJVBxxAuI7fnBRr28DwQt14VGojEAgO45h5IgKCwP61qxnmFjwQpgkU0sB8lHrSbg== 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)(7416014)(23010399003)(82310400026)(36860700016)(56012099006)(11063799006)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: v+JPuMNDAcJ9p+TyYmxKQvHsSxdrXYegd67O3xoIs7NNPwTYz6mkntYcmQNfo9CKS6nGguFKOvgitOsMrlO6/Lb65CjXT/DtPsOHuRfN23XK1z1d4jNWBm/2mntyRoUyZ76wlW28u0vXoEepY0B6dWRwHomg+Z28/7D06uBC1HdvoT+J7iv1YrUQzkH31S4R57v0CGSs2yfhcvcpSi05vxFUbN9dz96JrPcYvXWyuy2uIiJ97sOLE5+77QF0I08Zq5zJyLaHNhztRTnYhbXWGdDIkbWqdR9kMtdLmHpGuzcl4QOww02a+gwL586coDL6NlXp7tkaMvqcBJOoC15zQxfOljwDCxEuSbUexCvXUYzgPcUTL3b+HrqxdRQR8vlnyMTF1me8yXcDNoWy4cc9o4zLYucF1AbWu9AjWz0IIxWqeBr1+oyKp9ZYjG95ADfr X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 12:23:55.4128 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 78a4f7e5-1be8-4361-0c10-08df2924d98f 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: CO1PEPF00012E81.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6276 X-purgate-ID: tlsNG-4011c0/1791894301-59BC0CFC-041A249E/0/0 X-purgate-type: clean X-purgate-size: 3359 On 12-Oct-26 15:36, Julian Vetter wrote: > Hello Michal and Anthony, > thank you for the reviews and acks! Michal, I have addressed your > remaining remarks on the "xen/arm: report clock_frequency via sysctl > physinfo, not createdomain" patch. The golang bindings are regenerated > for the new arm_clock_frequency_hz physinfo field, and > alloc_domaininfo() no longer references the removed clock_frequency > field. Apart from that I have collected the Acked-by/Reviewed-by tags. > > Signed-off-by: Julian Vetter I was about to commit the series but I found out that some tests like test-mem-claim and possibly others still pass gic_version=0 which will cause the domain creation to fail. You need to update the tests. > > Andrew Cooper (1): > ARM/sysctl: Expose the supported guest GIC modes in physinfo > > Julian Vetter (4): > 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 Here you are still missing tags from e.g. RISCV I think. ~Michal > > CHANGELOG.md | 4 ++ > docs/man/xl.cfg.5.pod.in | 4 +- > tools/golang/xenlight/helpers.gen.go | 2 + > tools/golang/xenlight/types.gen.go | 1 + > .../include/xen-tools/arm-arch-capabilities.h | 31 ++++++++ > tools/libs/light/libxl.c | 1 + > tools/libs/light/libxl_arm.c | 72 +++++++++++++++++-- > tools/libs/light/libxl_types.idl | 1 + > tools/ocaml/libs/xc/xenctrl.ml | 1 - > tools/ocaml/libs/xc/xenctrl.mli | 1 - > tools/ocaml/libs/xc/xenctrl_stubs.c | 5 +- > tools/python/xen/lowlevel/xc/xc.c | 18 ++++- > xen/arch/arm/dom0less-build.c | 3 +- > xen/arch/arm/domain.c | 32 ++++----- > xen/arch/arm/domain_build.c | 3 +- > xen/arch/arm/firmware/sci.c | 2 +- > xen/arch/arm/firmware/scmi-smc.c | 2 +- > xen/arch/arm/gic.c | 15 ++++ > xen/arch/arm/include/asm/firmware/sci.h | 6 +- > xen/arch/arm/include/asm/gic.h | 6 ++ > xen/arch/arm/include/asm/time.h | 7 +- > xen/arch/arm/include/asm/vgic.h | 6 ++ > xen/arch/arm/include/asm/vtimer.h | 3 +- > xen/arch/arm/sysctl.c | 34 +++++++++ > xen/arch/arm/time.c | 9 ++- > xen/arch/arm/vgic-v2.c | 5 ++ > xen/arch/arm/vgic/vgic-v2.c | 5 ++ > xen/arch/arm/vtimer.c | 4 +- > xen/arch/ppc/stubs.c | 2 +- > xen/arch/riscv/domain.c | 2 +- > xen/arch/x86/domain.c | 16 ++--- > xen/include/public/arch-arm.h | 18 +---- > xen/include/public/domctl.h | 4 +- > xen/include/public/sysctl.h | 22 +++++- > xen/include/xen/sched.h | 5 +- > 35 files changed, 269 insertions(+), 83 deletions(-) > From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:28:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:28:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447103.1663276 (Exim 4.92) (envelope-from ) id 1xGbcS-0004tg-Uk; Tue, 13 Oct 2026 12:28:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447103.1663276; Tue, 13 Oct 2026 12:28: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 1xGbcS-0004sr-Oz; Tue, 13 Oct 2026 12:28:36 +0000 Received: by outflank-mailman (input) for mailman id 1447103; Tue, 13 Oct 2026 12:28:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbcR-0004oV-4U; Tue, 13 Oct 2026 12:28:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbcQ-00FMeE-HP; Tue, 13 Oct 2026 14:28:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace23ec-bab6-0a2a0a5309dd-0a2a4501bdb4-6 for ; Tue, 13 Oct 2026 14:28:34 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace23f0-5984-0a2a45010019-6882d725c4a6-3 for ; Tue, 13 Oct 2026 14:28:34 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbcM-00000003NGC-2C5h; Tue, 13 Oct 2026 12:28:30 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbcM-0000000F8M0-0z6F; Tue, 13 Oct 2026 12:28: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; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 514 v2 (CVE-2026-79607) - Xenstore: Guests can crash xenstored during Live Update Message-Id: Date: Tue, 13 Oct 2026 12:28:30 +0000 X-purgate-ID: tlsNG-d62444/1791894514-1F66C757-68071524/0/0 X-purgate-type: clean X-purgate-size: 5581 --=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-79607 / XSA-514 version 2 Xenstore: Guests can crash xenstored during Live Update UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= During Xenstore live update the state record for a Xenstore watch with specified watch depth is written with two bytes missing. This results in an inconsistent state when reading the state back in the new Xenstore, causing a crash of Xenstore or wrong Xenstore data. IMPACT ====== An unprivileged guest can cause the Xenstore service to crash or to get corrupted during a live update of Xenstore, causing a DoS of the host regarding further domain administration actions. VULNERABLE SYSTEMS ================== Only systems running Xen 4.22 are vulnerable. Systems running Xen 4.21 or older are not vulnerable. Only systems running C xenstore either as daemon or as stubdom are vulnerable. Systems running oxenstored are not vulnerable. MITIGATION ========== Not doing a live update of Xenstore avoids the vulnerability. Switching to oxenstored avoids the vulnerability. CREDITS ======= This issue was discovered by Andrii Sultanov of Vates. 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. xsa514.patch xen-unstable - Xen 4.22.x $ sha256sum xsa514* 8774d9b45db75851560db70a9be06d5e379311bd3042d9049bc29456e141ae7d xsa514.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. Not doing a live update of Xenstore as a mitigation is permitted. Switching to oxenstored is not permitted, as this is a guest visible configuration change. 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/4UyVfoK9kFAmrOIa8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZB5YH+wf2251Z1DOOtQcCB1LV9vsunIaEGd5l7pHdIZ3a 3j9A6r/KGc+RtSgDB9TWCMgjKLbBfwivOxBHHhxjhejsfnUKUJNryJFLn86plFdu VRrdk5pHmypNgb9mCf3KQ8BQputnuAu36QuIlw3F5z5XAanmyurT1QJKV0RXLrQF J3ROkGAGYp6gHhPDBFwCi/dWE/I1PRfvi53oyPPflj2kAh3DPwycpPQV0JZommjC ljh1uvyPMnwr76nnh5e4LmismWa9Gks/p3BQuF01w3Prj/vR4wRxLEMCPjhK6xV6 PLcKgrt+DGn/xwj7fEdaAVlXyh4YcxQlmUWHzaNm94Knq+8= =BuOZ -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa514.patch" Content-Disposition: attachment; filename="xsa514.patch" Content-Transfer-Encoding: base64 RnJvbSA2ODE2M2U3MzI5OTQ5ZjUwOWQ2MGMyMzllMDRlNWVkN2YwYzZiYzBlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6 IEZyaSwgMTggU2VwIDIwMjYgMTI6MjU6MDcgKzAyMDAKU3ViamVjdDogW1BBVENIXSB0b29scy94 ZW5zdG9yZWQ6IGZpeCBsaXZlIHVwZGF0ZSB3aXRoIHdhdGNoZXMgc3BlY2lmeWluZwogZGVwdGgK CkR1ZSB0byBhIHR5cG8gdGhlIHN0YXRlIHJlY29yZCBmb3IgYSB3YXRjaCBzcGVjaWZ5aW5nIGEg ZGVwdGggaXMKd3JpdHRlbiBvbmx5IHBhcnRpYWxseS4gSW5zdGVhZCBvZiB1c2luZyB0aGUgY29y cmVjdCBsZW5ndGggb2YgdGhlCnhzX3N0YXRlX3dhdGNoX2V4dCBzdHJ1Y3R1cmUgb25seSB0aGUg bGVuZ3RoIG9mIHRoZSB4c19zdGF0ZV93YXRjaApzdHJ1Y3R1cmUgd2FzIHVzZWQgd2hlbiB3cml0 aW5nIHRoZSBkYXRhLgoKRml4IHRoYXQgYnkgdXNpbmcgdGhlIGNvcnJlY3QgbGVuZ3RoLgoKVGhp cyBpcyBYU0EtNTE0IC8gQ1ZFLTIwMjYtNzk2MDcKCkZpeGVzOiBkYjk4ZGUxMjBjYjggKCJ0b29s cy94ZW5zdG9yZWQ6IGFkZCBkZXB0aCBpbmZvcm1hdGlvbiB0byB3YXRjaGVzIikKUmVwb3J0ZWQt Ynk6IEFuZHJpaSBTdWx0YW5vdiA8YW5kcml5LnN1bHRhbm92QHZhdGVzLnRlY2g+ClNpZ25lZC1v ZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4KLS0tCiB0b29scy94ZW5zdG9y ZWQvd2F0Y2guYyB8IDIgKy0KIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxl dGlvbigtKQoKZGlmZiAtLWdpdCBhL3Rvb2xzL3hlbnN0b3JlZC93YXRjaC5jIGIvdG9vbHMveGVu c3RvcmVkL3dhdGNoLmMKaW5kZXggYzE0M2U2ZmJjZi4uNzA5N2FiMGIwZCAxMDA2NDQKLS0tIGEv dG9vbHMveGVuc3RvcmVkL3dhdGNoLmMKKysrIGIvdG9vbHMveGVuc3RvcmVkL3dhdGNoLmMKQEAg LTM1NCw3ICszNTQsNyBAQCBjb25zdCBjaGFyICpkdW1wX3N0YXRlX3dhdGNoZXMoRklMRSAqZnAs IHN0cnVjdCBjb25uZWN0aW9uICpjb25uLAogCQkJcmV0dXJuICJEdW1wIHdhdGNoIHN0YXRlIGVy cm9yIjsKIAogCQlpZiAod2F0Y2gtPmRlcHRoID49IDApIHsKLQkJCWlmIChmd3JpdGUoJnN3ZSwg c2l6ZW9mKHN3KSwgMSwgZnApICE9IDEpCisJCQlpZiAoZndyaXRlKCZzd2UsIHNpemVvZihzd2Up LCAxLCBmcCkgIT0gMSkKIAkJCQlyZXR1cm4gIkR1bXAgd2F0Y2ggc3RhdGUgZXh0IGVycm9yIjsK IAkJfSBlbHNlIHsKIAkJCWlmIChmd3JpdGUoJnN3LCBzaXplb2Yoc3cpLCAxLCBmcCkgIT0gMSkK LS0gCjIuNTUuMAoK --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:28:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:28:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447107.1663315 (Exim 4.92) (envelope-from ) id 1xGbcX-0005oE-V4; Tue, 13 Oct 2026 12:28:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447107.1663315; Tue, 13 Oct 2026 12:28: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 1xGbcX-0005ns-R9; Tue, 13 Oct 2026 12:28:41 +0000 Received: by outflank-mailman (input) for mailman id 1447107; Tue, 13 Oct 2026 12:28:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbcV-0005hb-LM; Tue, 13 Oct 2026 12:28:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbcV-00DIG6-2E; Tue, 13 Oct 2026 14:28:39 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace23ef-2eae-0a2a0a5409dd-0a2a4505bd54-26 for ; Tue, 13 Oct 2026 14:28:39 +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 6ace23f5-4cb1-0a2a45050019-6882d725d400-3 for ; Tue, 13 Oct 2026 14:28:38 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbcR-00000003NGX-1oab; Tue, 13 Oct 2026 12:28:35 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbcR-0000000F8S9-0jrW; Tue, 13 Oct 2026 12:28: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; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 515 v2 (CVE-2026-79608) - x86/AMD: ineffectual Zenbleed workaround Message-Id: Date: Tue, 13 Oct 2026 12:28:35 +0000 X-purgate-ID: tlsNG-c201ff/1791894518-720AA2A1-ABEF8E1F/0/0 X-purgate-type: clean X-purgate-size: 6623 --=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-79608 / XSA-515 version 2 x86/AMD: ineffectual Zenbleed workaround UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The workaround for XSA-433 (Zenbleed, CVE-2023-20593) was later re-worked to better integrate with other manipulations of the same MSR. In this rework an inverted conditional was introduced, resulting in the workaround to not be applied when needed and vice versa. For more details, see: http://xenbits.xen.org/xsa/advisory-433.html IMPACT ====== An attacker can exploit this bug to read data from different contexts on the same core. Examples of such data includes key material, cypher and plaintext from the AES-NI instructions, or the contents of REP-MOVS instructions, commonly used to implement memcpy(). VULNERABLE SYSTEMS ================== Xen versions 4.19.4 and onwards, 4.20.3 and onwards, 4.21.1 and onwards, and 4.22 are affected. Xen versions 4.18, minor versions 4.19.3 and earlier, minor versions 4.20.2 and earlier, and 4.21.0 are not affected. The vulnerability can only be leveraged on systems running out-of-date microcode. Microcode fixing Zenbleed was published in late 2023. Updated firmware subseqeuent to this, or e.g. updated amd-ucode from linux-firmware (for the subset of CPUs covered by linux-firmware) are not vulnerable. The original issue and hence the applicability of the workaround is specific to the AMD Zen2 microarchitecture. AMD do not believe that other microarchitectures are affected. MITIGATION ========== This issue can be mitigated by disabling AVX, either by booting Xen with `cpuid=no-avx` on the command line, or by specifying `cpuid="host:avx=0"` in the vm.cfg file of all untrusted VMs. However, this will come with a significant impact on the system and is not recommended for anyone able to deploy the microcode or patch described below. CREDITS ======= This issue was discovered by Sashiko + Opus 5.0 and diagnosed as a security issue by George Dunlap. 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. xsa515.patch xen-unstable - Xen 4.19.x $ sha256sum xsa515* d54c5f5443209e523c1d1b456063d105792058d402513bc1e56246b5938de6d8 xsa515.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches 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 altering exposure of AVX 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/4UyVfoK9kFAmrOIhsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZKrYIAIKTxPm+Rvb9K2SvRJoHgjFDGTG0OxXqWFDjPnUR DKTx/URFmXCFT4PCGuAearWnkw25x0e80TdNfCrdHxDJzENSCcmb+5iIuM8nUtgo hMwNON4YUWn0GhBe3fcgAdlmxwWfhIJZHWt0LDrZrO9Nr21hmgVhvzME2VtH0EkA Yafi6ZixVwheA48w2to1cBjx27J5XucmvFoMgSRfW40YhpCmWDLDMv1F0vwxioyy vWVrk7pfYEj8n/hiap2MoI/pTDD6PruF+lWsO1fzHFwZHcUPOU+rV/elfEAA027E rRVsxob58ljY1IH/sMYOmSm7OQaGjau0kS7vC9kXtm7lmBQ= =NxYd -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa515.patch" Content-Disposition: attachment; filename="xsa515.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KU3ViamVjdDog eDg2L2FtZDogRml4IGludmVydGVkIGNvbmRpdGlvbiBpbiB6ZW5ibGVlZF91c2VfY2hpY2tlbmJp dCgpCgpUaGUgaWRlbnRpZmllZCBjb21taXQgaW52ZXJ0ZWQgdGhlIGNvbmRpdGlvbiB1bmRlciB3 aGljaCBYZW4gY2hvb3Nlcwp0byBzZXQgdGhlIFplbmJsZWVkIGNoaWNrZW5iaXQuCgpVbmRvIHRo YXQsIGFuZCBsZWF2ZSBhIGJldHRlciBjb21tZW50IGV4cGxhaW5pbmcgd2h5LgoKRm91bmQgYnkg QUkgcmV2aWV3IG9mIHRoZSByZWZlcmVuY2VkIGNvbW1pdC4KClRoaXMgaXMgWFNBLTUxNSAvIENW RS0yMDI2LTc5NjA4LgoKRml4ZXM6IGQwYzc1ZGM0YzAyOCAoIng4Ni9hbWQ6IEZpeCByYWNlIGVk aXRpbmcgREVfQ0ZHIikKQXNzaXN0ZWQtYnk6IFNhc2hpa28gKyBPcHVzIDUuMApSZXBvcnRlZC1i eTogR2VvcmdlIER1bmxhcCA8ZHVubGFwZ0B1bWljaC5lZHU+ClNpZ25lZC1vZmYtYnk6IEFuZHJl dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdS9h bWQuYyBiL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKaW5kZXggNzA3ODNjOWEwYWYwLi4xNDg4ODZm ZTJlYTEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKKysrIGIveGVuL2FyY2gv eDg2L2NwdS9hbWQuYwpAQCAtODg3LDcgKzg4NywxMiBAQCBzdGF0aWMgYm9vbCB6ZW5ibGVlZF91 c2VfY2hpY2tlbmJpdCh2b2lkKQogICAgICAgICByZXR1cm4gaXNfemVuMl91YXJjaCgpOwogICAg IH0KIAotICAgIHJldHVybiAodWludDhfdCljdXJyX3JldiA+PSBmaXhlZF9yZXY7CisgICAgLyoK KyAgICAgKiBaZW5ibGVlZCBjYW4gYmUgbWl0aWdhdGVkIGJ5IGRpc2FibGluZyBGbG9hdGluZy1Q b2ludAorICAgICAqIE1vdi1FbGltaW5hdGlvbiwgYnV0IHRoaXMgaXMgZXhwZW5zaXZlLiAgT25s eSBkbyBzbyB3aGVuIHdlCisgICAgICogZG9uJ3QgaGF2ZSBhIGZpeCBpbiBtaWNyb2NvZGUuCisg ICAgICovCisgICAgcmV0dXJuICh1aW50OF90KWN1cnJfcmV2IDwgZml4ZWRfcmV2OwogfQogCiB2 b2lkIGFtZF9pbml0X2RlX2NmZyhjb25zdCBzdHJ1Y3QgY3B1aW5mb194ODYgKmMpCg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:28:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:28:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447114.1663356 (Exim 4.92) (envelope-from ) id 1xGbcg-0006vF-Dl; Tue, 13 Oct 2026 12:28:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447114.1663356; Tue, 13 Oct 2026 12:28: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 1xGbcg-0006u1-2f; Tue, 13 Oct 2026 12:28:50 +0000 Received: by outflank-mailman (input) for mailman id 1447114; Tue, 13 Oct 2026 12:28:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbce-0006mQ-CS; Tue, 13 Oct 2026 12:28:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbcd-00FMjl-P8; Tue, 13 Oct 2026 14:28:47 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace23fc-8faa-0a2a0a5109dd-0a2a450c98b0-2 for ; Tue, 13 Oct 2026 14:28:47 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace23fe-f479-0a2a450c0019-6882d725d970-3 for ; Tue, 13 Oct 2026 14:28:47 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbcZ-00000003NGs-3ddL; Tue, 13 Oct 2026 12:28:43 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbcZ-0000000F8jX-2Ydd; Tue, 13 Oct 2026 12:28: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 Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 516 v2 (CVE-2026-79609) - x86: XPTI may break on huge-memory systems Message-Id: Date: Tue, 13 Oct 2026 12:28:43 +0000 X-purgate-ID: tlsNG-d25034/1791894527-51538A5B-1D0D221A/0/0 X-purgate-type: clean X-purgate-size: 42044 --=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-79609 / XSA-516 version 2 x86: XPTI may break on huge-memory systems UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= XPTI (Xen Page Table Isolation) was introduced to mitigate Meltdown (CVE-2017-5754, one aspect of XSA-254). This involves copying 64-bit PV guest page table entries from guest-chosen root page tables to the Xen- chosen one which is in actual use by hardware. To read the guest root page table, the directmap is used. PV guests, however, have a directmap which may not cover all memory; in particular this is the case if any memory extends beyond the 5 TiB (CONFIG_BIGMEM=y: 3.5 TiB) address boundary. IMPACT ====== A 64-bit PV guest may be able to elevate its privilege to that of the host. It is also possible for them to observe information pertaining to other guests, or to cause Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS ================== All versions of Xen with the XPTI work backported to are affected. In upstream these are Xen 4.7.5 and onwards, Xen 4.8.3 and onwards, Xen 4.9.2 and onwards, Xen 4.10.1 and onwards, and all major releases from 4.11 onwards. Only 64-bit PV guests can leverage the vulnerability. HVM and PVH guests cannot leverage the vulnerability. 32-bit PV guests haven't been security supported anymore. Only x86 systems are affected. Arm systems are not affected. Only systems with RAM above the 5 TiB (CONFIG_BIGMEM=y: 3.5 TiB) boundary are affected. Systems with no RAM above the 5 TiB (CONFIG_BIGMEM=y: 3.5 TiB) boundary are not affected. MITIGATION ========== Not running 64-bit PV guests will avoid the vulnerability. The "mem=" hypervisor command line option may be used to limit the amount of memory Xen is going to use. That would be "mem=5T" for the CONFIG_BIGMEM=n case and "mem=3584G" for the CONFIG_BIGMEM=y one. CREDITS ======= This issue was discovered by George Dunlap. 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. xsa516.patch xen-unstable - Xen 4.19.x xsa516-4.18.patch Xen 4.18.x xsa516-4.17.patch Xen 4.17.x $ sha256sum xsa516* aff590335eed173a2f67375829a25682983cacf14ff170d25e636533552ecaa8 xsa516.patch 06b818ca56dff7ccc1f4842e9977a0eee283c516959980c85cf9d54d1c0abdb0 xsa516-4.17.patch 09d87137da9d5065227c808a1150cdbb878ae05785d6929de0754184313546fa xsa516-4.18.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/4UyVfoK9kFAmrOIjwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ0LoH/Ap814NnaDiHkPGqPWg0/N8gEJmPgUvSXXsjI8gb t+aLjuG3tI6j12jWtohBj67RiDAYWc3mAaqr7c9tb1Bi24IyenZIf8gAvkS72sUi Hl4WPCMcmgp0xM8s9b1peep5XTSVH1s+xDLGmBx21jXhoop1IJ5Na9VV2PcX50MJ assI8h4VE9xAYnMzMbd14IzbGXWylAZLdJYLGBoI06X7eZvPNPUvkktJaMqmSJgS IeJuUKK8pb5AFlefSxzcu007olRLhXxQrbkKXbwnyS+ZXI9r02hh8njPUTy8p/PG sLS5NNIHalXlxIOtQ20H+Hbi0n80nKn2T3ctjsKkmBGUioU= =KASN -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa516.patch" Content-Disposition: attachment; filename="xsa516.patch" Content-Transfer-Encoding: base64 RnJvbTogR2VvcmdlIER1bmxhcCA8Z3dkQHhlbnByb2plY3Qub3JnPgpTdWJqZWN0OiB4ODYvcHY6 IG1hcCBlYWNoIHZDUFUncyByb290IHBhZ2UgdGFibGUgaW4gaXRzIHBlci1kb21haW4gYXJlYQoK Rm9yIFhQVEkgZW5hYmxlZCBWTXMsIHJlc3RvcmVfYWxsX2d1ZXN0KCkgY29waWVzIG1vc3Qgb2Yg dGhlIGFjdGl2ZSBMNApwYWdldGFibGUgaW50byB0aGUgcGVyLUNQVSByb290X3BndC4gIFRoZSBM NCBpcyByZWFkIHZpYSB0aGUKZGlyZWN0bWFwLgoKVW5mb3J0dW5hdGVseSwgdGhlcmUgd2FzIG5v IGFjY291bnRpbmcgZm9yIHRoZSBmYWN0IHRoYXQgUFYgZ3Vlc3RzCmhhdmUgc2hvcnQgZGlyZWN0 bWFwcy4gIEZvciBhbiBMNCBsaXZpbmcgYmV5b25kIHRoZSA1VCBib3VuZGFyeSAoMy41VApmb3Ig Q09ORklHX0JJR01FTSksIFhlbiB3aWxsIGNvcHkgYXJiaXRyYXJ5IGRhdGEgZnJvbSBndWVzdC1j b250cm9sbGVkCnZpcnR1YWwgYWRkcmVzcyBzcGFjZSBpbnRvIHRoZSBwZXItQ1BVIHJvb3RfcGd0 LCBpbnN0ZWFkIG9mIHRoZQppbnRlbmRlZCBMNC4KClhlbiBoYXMgcGVyLWRvbWFpbiBtYXBwaW5n cyBmb3IgdGhlIExEVCBhbmQgR0RULCB3aXRoIHR3byBwYWdlcwpyZXNlcnZlZCBmb3IgWGVuJ3Mg dXNlIGluIHRoZSBHRFQgYnV0IG9ubHkgb25lIGluIHVzZS4gIFJldXNlIEdEVCBwYWdlCjE1IHRv IG1hcCB0aGUgZWZmZWN0aXZlIEw0LiAgVGhlIEdEVCBsaW1pdCBrZWVwcyBpbXBsaWNpdCBhY2Nl c3NlcyBvdXQKb2YgdGhpcyBwYWdlLgoKV2UgdXBkYXRlIHRoaXMgbWFwcGluZyBpbiBtYWtlX2Ny MygpLCB0aGUgb25seSBwbGFjZSBhIG5vbi1lbXB0eSB2YWx1ZQpvZiB2LT5hcmNoLmNyMyBpcyB3 cml0dGVuIGludG8gYSBndWVzdCdzIHZjcHUgc3RydWN0LCBmb3IgdHdvIHJlYXNvbnMuCkZpcnN0 IGlzIHJlZmVyZW5jZSBjb3VudGluZzogdGhpcyBtYWtlcyBpdCBlYXNpZXIgdG8gYXJndWUgdGhh dCB0aGUKcmVmZXJlbmNlIGZvciB2LT5hcmNoLmNyMyBpdHNlbGYgY292ZXJzIHRoZSByZWZlcmVu Y2UgZm9yIHRoZSBtYXBwaW5nLgoKU2Vjb25kbHksIHRoaXMgZ3VhcmFudGVlcyB0aGF0IGFsbCB1 cGRhdGVzLCBldmVuIHVwZGF0ZXMgbWFkZSBpbgpzaGFkb3cgbW9kZSwgcmVzdWx0IGluIGFuIHVw ZGF0ZSB0byB0aGUgbWFwcGluZy4gIER1cmluZyBsaXZlCm1pZ3JhdGlvbiwgaXQncyBwb3NzaWJs ZSBmb3IgZ3Vlc3RfZ2V0X2VmZl9rZXJuX2wxZSgpIHRvIHJlc3VsdCBpbiBhCm1vZGlmaWVkIHZh bHVlIG9mIHYtPmFyY2guY3IzIChza2V0Y2ggYmVsb3cpOyBwbGFjaW5nIHRoZSBtYXBwaW5nCnVw ZGF0ZSBhdCBtYWtlX2NyMygpIGNhdGNoZXMgdGhpcywgd2hpbGUgb3RoZXIgY2FuZGlkYXRlIGxv Y2F0aW9ucwpsaWtlIHdyaXRlX3B0YmFzZSgpIGFuZCB0b2dnbGVfZ3Vlc3RfbW9kZSgpIGRvbid0 LgoKTm90ZSB0aGF0IHdlIGludHJvZHVjZSB0aGUgaWRlYSBvZiBhbiAiZWZmZWN0aXZlIEw0IiBo ZXJlLCB0byBtZWFuCiJndWVzdCBMNCBhZnRlciBhbnkgdHJhbnNmb3JtYXRpb25zIjogWFBUSSBj b3BpZXMgZWl0aGVyIHRoZSBhY3R1YWwKZ3Vlc3QgTDQgaWYgbm90IHNoYWRvd2VkLCBvciB0aGUg c2hhZG93IEw0ICh0cmFuc2Zvcm1lZCkgaWYgc2hhZG93ZWQuCgpTa2V0Y2g6IGd1ZXN0X2dldF9l ZmZfa2Vybl9sMWUoKSBoYXMgYSBwYWlyIG9mIHRvZ2dsZV9ndWVzdF9wdCgpIGNhbGxzCndoaWNo IGhhcHBlbiBpZiB0aGUgZ3Vlc3QgaXMgaW4gdXNlciBtb2RlLiAgRHVyaW5nIGxpdmUgbWlncmF0 aW9uLCBhCmxvZy1kaXJ0eSBjbGVhbiB3aWxsIGRvIGEgZG9tYWluX3BhdXNlIGFuZCB0aGVuIGNh bGwKc2hhZG93X2Jsb3dfdGFibGVzKCksIHVucGlubmluZyB0aGUgc2hhZG93IG9mIHRoZSBndWVz dCB1c2VyIHJvb3QKcGFnZXRhYmxlLiAgQWZ0ZXIgZXhlY3V0aW9uIHJlc3VtZXMsIHRoZSBmaXJz dCB0b2dnbGVfZ3Vlc3RfcHQoKSBjb3VsZAp0aGVuIGNhdXNlIHRoYXQgcGFnZSB0byBiZWNvbWUg dW5zaGFkb3dlZC4gIFRoZSBzZWNvbmQKdG9nZ2xlX2d1ZXN0X3B0KCkgd291bGQgdGhlbiByZS1z aGFkb3cgaXQsIHBvc3NpYmx5IHdpdGggYSBkaWZmZXJlbnQKYmFja2luZyBzaGFkb3cgcGFnZS4K ClRoaXMgaXMgWFNBLTUxNiAvIENWRS0yMDI2LTc5NjA5LgoKRml4ZXM6IDU3ODRkZTNlMjA2NyAo Ing4NjogTWVsdGRvd24gYmFuZC1haWQgYWdhaW5zdCBtYWxpY2lvdXMgNjQtYml0IFBWIGd1ZXN0 cyIpCkFzc2lzdGVkLWJ5OiBDbGF1ZGUgQ29kZTpjbGF1ZGUtZmFibGUtNS0xClNpZ25lZC1vZmYt Ynk6IEdlb3JnZSBEdW5sYXAgPGd3ZEB4ZW5wcm9qZWN0Lm9yZz4KUmV2aWV3ZWQtYnk6IEphbiBC ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KLS0tCgpDaGFuZ2VzIGluIHY0OgotIFJld29yZGVk IHRoZSBwdl91bm1hcF9lZmZfcm9vdF9wdCgpIGNvbW1lbnQgYW5kIHRoZSBsaWZldGltZSBub3Rl CiAgYmVsb3cuICBUaGUgd2luZG93IGhhcyBleGFjdGx5IHYtPmFyY2guY3IzJ3MgdmFsaWRpdHk6 IGluIHNoYWRvdyBtb2RlCiAgYm90aCBuYW1lIHRoZSB0b3AtbGV2ZWwgc2hhZG93IGFmdGVyIHNo YWRvd190ZWFyZG93bigpIGhhcyByZWxlYXNlZAogIGl0LCB1bnRpbCB2Y3B1X2Rlc3Ryb3lfcGFn ZXRhYmxlcygpIGNsZWFycyB0aGVtLCBhbmQgbm90aGluZyB1c2VzCiAgZWl0aGVyIGJ5IHRoZW4u ICBUaGUgZWFybGllciB3b3JkaW5nIGNsYWltZWQgbW9yZS4KLSBUd2Vha2VkIGNvbW1pdCBtZXNz YWdlIHdvcmRpbmcgcmUgc2tldGNoIHRvIG1ha2UgaXQgY2xlYXIgaXQncyBub3QgYSByYWNlCi0g UmV3b3JrZWQgImxhc3QgcGFnZSBvZiBHRFQiIGNvbW1lbnQgdG8gYmUgbW9yZSB0ZWNobmljYWxs eSBhY2N1cmF0ZQoKKEEgcGF0Y2ggbWFya2VkIHYzIHdhcyBzZW50IGVycm9uZW91c2x5LikKCkNo YW5nZXMgaW4gdjIgKG9mIHNlY3VyaXR5QCBwb3N0aW5nKToKLSBNZXJnZWQgaXNfcHZfZG9tYWlu KCkgY29uZGl0aW9uIGluIG1ha2VfY3IzKCkKLSBVc2UgS0IoNjQpIGFzIHJlcXVlc3RlZCBkdXJp bmcgcmV2aWV3Ci0gQlVJTERfQlVHX09OKCkgbm93IGV4cHJlc3NlZCB3aXRoIExBU1RfUkVTRVJW RURfR0RUX0JZVEUgYXMKICByZXF1ZXN0ZWQgZHVyaW5nIHJldmlldwotIFN3aXRjaGVkIHRvICJQ Vl9FRkZfUk9PVF9QVCIgdG8gc3BlY2lmeSB0aGF0IHRoaXMgaXMgYWZ0ZXIgcG90ZW50aWFsCiAg c2hhZG93IHRyYW5zZm9ybWF0aW9ucwotIFRyaW1tZWQgZG93biB0aGUgY29tbWl0IG1lc3NhZ2Us IGNsYXJpZmllZCBtYWtlX2NyMygpIHJhdGlvbmFsZS4KClJlbGF0aXZlIHRvIHY1OgotIFRoZSB3 aW5kb3cgaXMgdGhlIHNwYXJlIEdEVCBwYWdlIGFmdGVyIFhlbidzIHJlc2VydmVkIHJhbmdlIHJh dGhlcgogIHRoYW4gYSBuZXcgc3ViLWFyZWE6IG5vIGFsbG9jYXRpb24gKHYyJ3MgYXJyYXkgZHJl dyBhIDMyeAogIG92ZXItYWxsb2NhdGlvbiByZW1hcmspIGFuZCBub3RoaW5nIHRvIGNyZWF0ZSBv ciB0ZWFyIGRvd24gcGVyIHZDUFUuCi0gVGhlIHJlZnJlc2ggaXMgaW4gbWFrZV9jcjMoKSwgd2hp Y2ggZXZlcnkgcm9vdCBjaGFuZ2UgcGFzc2VzIHRocm91Z2gsCiAgc2hhZG93IG1vZGUgaW5jbHVk ZWQsIGluc3RlYWQgb2Ygd3JpdGVfcHRiYXNlKCkgcGx1cyB0aGUgdG9nZ2xlLgotIFRoZSB3aW5k b3cgaXMgY2xlYXJlZCBpbiB2Y3B1X2Rlc3Ryb3lfcGFnZXRhYmxlcygpIGFsb25nc2lkZQogIHYt PmFyY2guY3IzLCBzbyBpdCBoYXMgZXhhY3RseSB2LT5hcmNoLmNyMydzIHZhbGlkaXR5LgotIFRo ZSBlbnRyeS5TIGNvbXB1dGF0aW9uIGtlZXBzIHRoZSB2MiBzaGFwZTsgdGhlIG1hcHBpbmcgc3Rh eXMKICByZWFkLW9ubHksIGFzIHN1Z2dlc3RlZCBvbiB2Mi4KLSBCdWlsZC10aW1lIGNoZWNrcyBw aW4gdGhlIHdpbmRvdyB0byB0aGUgcmVzZXJ2ZWQgcmFuZ2UuCkl0IGFwcGxpZXMgb24gaXRzIG93 biB0byBjdXJyZW50IHN0YWdpbmcsIHVzaW5nIHRoZSBwZXItdkNQVSBHRFQgTDEKdGFibGUgWGVu IGFscmVhZHkga2VlcHMuCi0tLQogeGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NvbmZpZy5oIHwg MjMgKysrKysrKysrKysrKystLQogeGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2Rlc2MuaCAgIHwg MTAgKysrKysrKwogeGVuL2FyY2gveDg2L21tLmMgICAgICAgICAgICAgICAgIHwgNDUgKysrKysr KysrKysrKysrKysrKysrKysrKysrKystLQogeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0 cy5jIHwgIDEgKwogeGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TICAgICAgIHwgIDcgKysrKy0K IDUgZmlsZXMgY2hhbmdlZCwgODEgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYg LS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY29uZmlnLmggYi94ZW4vYXJjaC94ODYv aW5jbHVkZS9hc20vY29uZmlnLmgKaW5kZXggMWIyODM0OWE0Mi4uMGMwMDRlZGM2NiAxMDA2NDQK LS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NvbmZpZy5oCisrKyBiL3hlbi9hcmNoL3g4 Ni9pbmNsdWRlL2FzbS9jb25maWcuaApAQCAtMjQ5LDExICsyNDksMzAgQEAgZXh0ZXJuIHVuc2ln bmVkIGxvbmcgeGVuX3BoeXNfc3RhcnQ7CiAjZGVmaW5lIEdEVF9MRFRfVklSVF9TVEFSVCAgICAg ICBQRVJET01BSU5fVklSVF9TTE9UKDApCiAjZGVmaW5lIEdEVF9MRFRfVklSVF9FTkQgICAgICAg ICAoR0RUX0xEVF9WSVJUX1NUQVJUICsgKEdEVF9MRFRfTUJZVEVTIDw8IDIwKSkKIAotLyogVGhl IGFkZHJlc3Mgb2YgYSBwYXJ0aWN1bGFyIFZDUFUncyBHRFQgb3IgTERULiAqLworLyoKKyAqIFRo ZSBhZGRyZXNzIG9mIGEgcGFydGljdWxhciBWQ1BVJ3MgR0RUIG9yIExEVDsgZWFjaCBpcyB0aGUg YXJjaGl0ZWN0dXJhbAorICogbWF4aW11bSBvZiA2NGsuCisgKi8KKyNkZWZpbmUgR0RUX1ZJUlRf U0laRSAgICAgICAgS0IoNjQpCiAjZGVmaW5lIEdEVF9WSVJUX1NUQVJUKHYpICAgIFwKICAgICAo UEVSRE9NQUlOX1ZJUlRfU1RBUlQgKyAoKHYpLT52Y3B1X2lkIDw8IEdEVF9MRFRfVkNQVV9WQV9T SElGVCkpCiAjZGVmaW5lIExEVF9WSVJUX1NUQVJUKHYpICAgIFwKLSAgICAoR0RUX1ZJUlRfU1RB UlQodikgKyAoNjQqMTAyNCkpCisgICAgKEdEVF9WSVJUX1NUQVJUKHYpICsgR0RUX1ZJUlRfU0la RSkKKworLyoKKyAqIFRoZSB2Q1BVJ3MgZWZmZWN0aXZlIHJvb3QgcGFnZSB0YWJsZSwgbWFwcGVk IHJlYWQtb25seSBpbiB0aGUgbGFzdAorICogcGFnZSBvZiBpdHMgR0RUOiB0aGUgcGFnZSBhZnRl ciBYZW4ncyByZXNlcnZlZCByYW5nZSwgYmV5b25kIHRoZQorICogR0RUIGxpbWl0IFhlbiBsb2Fk cyAoTEFTVF9SRVNFUlZFRF9HRFRfQllURSksIHNvIG5vIHNlbGVjdG9yIGNhbgorICogcmVhY2gg aXQuICAiRWZmZWN0aXZlIiBpcyB0aGUgcm9vdCBwYWdlIHRhYmxlIHRoZSB2Q1BVIGlzIG1lYW50 IHRvCisgKiBydW4gb24gYWZ0ZXIgYW55IHRyYW5zZm9ybWF0aW9uOiB0aGUgZ3Vlc3QncyBvd24s IG9yIGl0cyBzaGFkb3cKKyAqIHVuZGVyIHNoYWRvdyBwYWdpbmcuICBYUFRJIGRvZXMgbm90IHRy YW5zZm9ybSBpdCBmdXJ0aGVyIGJ1dCBjb3BpZXMKKyAqIGZyb20gaXQ6IHRoZSBleGl0IHBhdGgg cmVhZHMgdGhlIGd1ZXN0LXZpc2libGUgTDQgc2xvdHMgZnJvbSBoZXJlLgorICogQWRkaW5nIGEg cmVzZXJ2ZWQgR0RUIHBhZ2Ugd291bGQgbWVhbiBtb3ZpbmcgdGhlIHdpbmRvdyBvdXQgb2YgdGhl CisgKiBHRFQgZmlyc3Q7IHB2X21hcF9lZmZfcm9vdF9wdCgpIGNoZWNrcyB0aGUgbGF5b3V0IGF0 IGJ1aWxkIHRpbWUuCisgKi8KKyNkZWZpbmUgUFZfRUZGX1JPT1RfUFRfUEFHRSAgICAoRklSU1Rf UkVTRVJWRURfR0RUX1BBR0UgKyAxKQorI2RlZmluZSBQVl9FRkZfUk9PVF9QVF9PRkZTRVQgIChQ Vl9FRkZfUk9PVF9QVF9QQUdFIDw8IFBBR0VfU0hJRlQpCisjZGVmaW5lIFBWX0VGRl9ST09UX1BU KHYpICAgICAgKEdEVF9WSVJUX1NUQVJUKHYpICsgUFZfRUZGX1JPT1RfUFRfT0ZGU0VUKQogCiAv KiBtYXBfZG9tYWluX3BhZ2UoKSBtYXAgY2FjaGUuIFRoZSBzZWNvbmQgcGVyLWRvbWFpbi1tYXBw aW5nIHN1Yi1hcmVhLiAqLwogI2RlZmluZSBNQVBDQUNIRV9WQ1BVX0VOVFJJRVMgICAgKENPTkZJ R19QQUdJTkdfTEVWRUxTICogQ09ORklHX1BBR0lOR19MRVZFTFMpCmRpZmYgLS1naXQgYS94ZW4v YXJjaC94ODYvaW5jbHVkZS9hc20vZGVzYy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2Rl c2MuaAppbmRleCBkY2JkYWMzZmY3Li43Y2JiOWE3MzM2IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94 ODYvaW5jbHVkZS9hc20vZGVzYy5oCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9kZXNj LmgKQEAgLTYsNiArNiwxNiBAQAogLyoKICAqIFhlbiByZXNlcnZlcyBhIG1lbW9yeSBwYWdlIG9m IEdEVCBlbnRyaWVzLgogICogTm8gZ3Vlc3QgR0RUIGVudHJpZXMgZXhpc3QgYmV5b25kIHRoZSBY ZW4gcmVzZXJ2ZWQgYXJlYS4KKyAqCisgKiBUaGUgcGFnZSBhZnRlciB0aGUgcmVzZXJ2ZWQgYXJl YSwgdGhlIGxhc3Qgb2YgdGhlIEdEVCdzIDY0aywgaXMgdGhlCisgKiBQViBlZmZlY3RpdmUgcm9v dC10YWJsZSB3aW5kb3cgKFBWX0VGRl9ST09UX1BUX1BBR0UsIGNvbmZpZy5oKToKKyAqIGJleW9u ZCB0aGUgR0RUIGxpbWl0IFhlbiBsb2FkcyAoTEFTVF9SRVNFUlZFRF9HRFRfQllURSksIHNvIG5v CisgKiBzZWxlY3RvciByZWFjaGVzIGl0LiAgWGVuIHVzZXMgb25seSBhIGZldyBvZiB0aGUgcmVz ZXJ2ZWQgcGFnZSdzCisgKiA1MTIgc2xvdHMsIHNvIG1vcmUgWGVuIGRlc2NyaXB0b3JzIG5ldmVy IG5lZWQgYW5vdGhlciBwYWdlOyBpZiBvbmUKKyAqIHdlcmUgbmVlZGVkIHJlZ2FyZGxlc3MsIHRo ZSB3aW5kb3cgd291bGQgaGF2ZSB0byBtb3ZlIG91dCBvZiB0aGUKKyAqIEdEVCBmaXJzdCAoaW50 byBhIHBlci1kb21haW4gc3ViLWFyZWEgb2YgaXRzIG93biksIGFzIHRoaXMgaXMgdGhlCisgKiBH RFQncyBsYXN0IHBhZ2UuICBwdl9tYXBfZWZmX3Jvb3RfcHQoKSBjaGVja3MgdGhlIGxheW91dCBh dCBidWlsZAorICogdGltZS4KICAqLwogI2RlZmluZSBOUl9SRVNFUlZFRF9HRFRfUEFHRVMgICAx CiAjZGVmaW5lIE5SX1JFU0VSVkVEX0dEVF9CWVRFUyAgIChOUl9SRVNFUlZFRF9HRFRfUEFHRVMg KiBQQUdFX1NJWkUpCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0uYyBiL3hlbi9hcmNoL3g4 Ni9tbS5jCmluZGV4IGIxNTg3NDI0MDguLmY0Yjg3ZWQ1ZWMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNo L3g4Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5jCkBAIC01MTAsMTMgKzUxMCw1MiBAQCB2 b2lkIHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgc3Ry dWN0IGRvbWFpbiAqZCwKICAgICBucnNwaW5fdW5sb2NrKCZkLT5wYWdlX2FsbG9jX2xvY2spOwog fQogCisvKgorICogTWFwIEBtZm4gcmVhZC1vbmx5IGF0IHYncyBQVl9FRkZfUk9PVF9QVCgpIHdp bmRvdy4gIFRoZSB3aW5kb3cgbGl2ZXMgaW4KKyAqIHYncyBwZXItZG9tYWluIGFyZWEsIHNvIHYg bmVlZCBub3QgYmUgY3VycmVudDsgdGhlIGxvY2FsIGZsdXNoIGlzIGZvcgorICogd2hlbiBpdCBp cywgd2l0aCBpdHMgb3duIHBhZ2UgdGFibGVzIGxvYWRlZC4KKyAqLworc3RhdGljIHZvaWQgcHZf bWFwX2VmZl9yb290X3B0KGNvbnN0IHN0cnVjdCB2Y3B1ICp2LCBtZm5fdCBtZm4pCit7CisgICAg LyoKKyAgICAgKiBUaGUgd2luZG93IG11c3QgbGllIGJleW9uZCB0aGUgR0RUIGxpbWl0IFhlbiBs b2Fkcywgc28gdGhhdCBubworICAgICAqIHNlbGVjdG9yIHJlYWNoZXMgaXQsIGFuZCB3aXRoaW4g dGhlIEdEVCdzIDY0ay4KKyAgICAgKi8KKyAgICBCVUlMRF9CVUdfT04oUFZfRUZGX1JPT1RfUFRf T0ZGU0VUIDw9IExBU1RfUkVTRVJWRURfR0RUX0JZVEUpOworICAgIEJVSUxEX0JVR19PTihQVl9F RkZfUk9PVF9QVF9PRkZTRVQgKyBQQUdFX1NJWkUgPiBHRFRfVklSVF9TSVpFKTsKKworICAgIGwx ZV93cml0ZShwdl9nZHRfcHRlcyh2KSArIFBWX0VGRl9ST09UX1BUX1BBR0UsCisgICAgICAgICAg ICAgIGwxZV9mcm9tX21mbihtZm4sIF9fUEFHRV9IWVBFUlZJU09SX1JPKSk7CisgICAgZmx1c2hf dGxiX29uZV9sb2NhbChQVl9FRkZfUk9PVF9QVCh2KSk7Cit9CisKKy8qCisgKiBDbGVhciB0aGUg d2luZG93LiAgSXRzIGxpZmV0aW1lIGlzIHYtPmFyY2guY3IzJ3M6IG1ha2VfY3IzKCkgd3JpdGVz IGl0CisgKiB3aGVyZXZlciB2LT5hcmNoLmNyMyBpcyBzZXQsIGFuZCB2Y3B1X2Rlc3Ryb3lfcGFn ZXRhYmxlcygpIGNsZWFycyBpdCB3aGVyZQorICogdi0+YXJjaC5jcjMgaXMgemVyb2VkLiAgSW4g c2hhZG93IG1vZGUgYm90aCBuYW1lIGEgdG9wLWxldmVsIHNoYWRvdywgd2hpY2gKKyAqIHNoYWRv d190ZWFyZG93bigpIHJlbGVhc2VzIGJlZm9yZSB0aGF0IHBvaW50OyBub3RoaW5nIHVzZXMgZWl0 aGVyIG9uY2UgdGhlCisgKiB2Q1BVIGNhbiBubyBsb25nZXIgcnVuLgorICovCitzdGF0aWMgdm9p ZCBwdl91bm1hcF9lZmZfcm9vdF9wdChjb25zdCBzdHJ1Y3QgdmNwdSAqdikKK3sKKyAgICBsMWVf d3JpdGUocHZfZ2R0X3B0ZXModikgKyBQVl9FRkZfUk9PVF9QVF9QQUdFLCBsMWVfZW1wdHkoKSk7 CisgICAgZmx1c2hfdGxiX29uZV9sb2NhbChQVl9FRkZfUk9PVF9QVCh2KSk7Cit9CisKIHZvaWQg bWFrZV9jcjMoc3RydWN0IHZjcHUgKnYsIG1mbl90IG1mbikKIHsKICAgICBzdHJ1Y3QgZG9tYWlu ICpkID0gdi0+ZG9tYWluOwogCiAgICAgdi0+YXJjaC5jcjMgPSBtZm5feChtZm4pIDw8IFBBR0Vf U0hJRlQ7Ci0gICAgaWYgKCBpc19wdl9kb21haW4oZCkgJiYgZC0+YXJjaC5wdi5wY2lkICkKLSAg ICAgICAgdi0+YXJjaC5jcjMgfD0gZ2V0X3BjaWRfYml0cyh2LCBmYWxzZSk7CisKKyAgICBpZiAo IGlzX3B2X2RvbWFpbihkKSApCisgICAgeworICAgICAgICBpZiAoIGQtPmFyY2gucHYucGNpZCAp CisgICAgICAgICAgICB2LT5hcmNoLmNyMyB8PSBnZXRfcGNpZF9iaXRzKHYsIGZhbHNlKTsKKwor ICAgICAgICBpZiAoIGQtPmFyY2gucHYueHB0aSApCisgICAgICAgICAgICBwdl9tYXBfZWZmX3Jv b3RfcHQodiwgbWZuKTsKKyAgICB9CiB9CiAKIHZvaWQgd3JpdGVfcHRiYXNlKHN0cnVjdCB2Y3B1 ICp2KQpAQCAtMzIyNCw2ICszMjYzLDggQEAgaW50IHZjcHVfZGVzdHJveV9wYWdldGFibGVzKHN0 cnVjdCB2Y3B1ICp2KQogICAgICAgICByZXR1cm4gcmM7CiAKICAgICB2LT5hcmNoLmNyMyA9IDA7 CisgICAgaWYgKCBpc19wdl9kb21haW4odi0+ZG9tYWluKSAmJiB2LT5kb21haW4tPmFyY2gucHYu eHB0aSApCisgICAgICAgIHB2X3VubWFwX2VmZl9yb290X3B0KHYpOwogCiAgICAgLyoKICAgICAg KiBHZXQgdGhlIHRvcC1sZXZlbCBndWVzdCBwYWdlOyBlaXRoZXIgdGhlIGd1ZXN0X3RhYmxlIGl0 c2VsZiwgZm9yCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZzZXRzLmMg Yi94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1vZmZzZXRzLmMKaW5kZXggYmFmMjY2YWI4MC4uMDU0 OWZkNWU4ZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCisr KyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwpAQCAtODIsNiArODIsNyBAQCB2 b2lkIF9fZHVtbXlfXyh2b2lkKQogCiAjdW5kZWYgT0ZGU0VUX0VGCiAKKyAgICBPRkZTRVQoVkNQ VV9pZCwgc3RydWN0IHZjcHUsIHZjcHVfaWQpOwogICAgIE9GRlNFVChWQ1BVX3Byb2Nlc3Nvciwg c3RydWN0IHZjcHUsIHByb2Nlc3Nvcik7CiAgICAgT0ZGU0VUKFZDUFVfZG9tYWluLCBzdHJ1Y3Qg dmNwdSwgZG9tYWluKTsKICAgICBPRkZTRVQoVkNQVV92Y3B1X2luZm8sIHN0cnVjdCB2Y3B1LCB2 Y3B1X2luZm9fYXJlYS5tYXApOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRy eS5TIGIveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCmluZGV4IDU5OTUzYzlmNTIuLmJhMTc1 YmRlN2MgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUworKysgYi94ZW4v YXJjaC94ODYveDg2XzY0L2VudHJ5LlMKQEAgLTIwMCw5ICsyMDAsMTQgQEAgRlVOQ19MT0NBTChy ZXN0b3JlX2FsbF9ndWVzdCkKICAgICAgICAgbW92YWJzICRQQUREUl9NQVNLICYgUEFHRV9NQVNL LCAlcnNpCiAgICAgICAgIG1vdmFicyAkRElSRUNUTUFQX1ZJUlRfU1RBUlQsICVyY3gKICAgICAg ICAgYW5kICAgJXJzaSwgJXJkaQotICAgICAgICBhbmQgICAlcjksICVyc2kKICAgICAgICAgYWRk ICAgJXJjeCwgJXJkaQorCisgICAgICAgIC8qIEVmZmVjdGl2ZSByb290IHBhZ2UgdGFibGUgaXMg bWFwcGVkIGF0IFBWX0VGRl9ST09UX1BUKHYpICovCisgICAgICAgIG1vdiAgIFZDUFVfaWQoJXJi eCksICVlc2kKKyAgICAgICAgc2hsICAgJEdEVF9MRFRfVkNQVV9WQV9TSElGVCwgJXJzaQorICAg ICAgICBtb3ZhYnMgJEdEVF9MRFRfVklSVF9TVEFSVCArIFBWX0VGRl9ST09UX1BUX09GRlNFVCwg JXJjeAogICAgICAgICBhZGQgICAlcmN4LCAlcnNpCisKICAgICAgICAgbW92ICAgJFJPT1RfUEFH RVRBQkxFX0ZJUlNUX1hFTl9TTE9ULCAlZWN4CiAgICAgICAgIG1vdiAgIHJvb3RfdGFibGVfb2Zm c2V0KFNIX0xJTkVBUl9QVF9WSVJUX1NUQVJUKSo4KCVyc2kpLCAlcjgKICAgICAgICAgbW92ICAg JXI4LCByb290X3RhYmxlX29mZnNldChTSF9MSU5FQVJfUFRfVklSVF9TVEFSVCkqOCglcmRpKQo= --=separator Content-Type: application/octet-stream; name="xsa516-4.17.patch" Content-Disposition: attachment; filename="xsa516-4.17.patch" Content-Transfer-Encoding: base64 RnJvbTogR2VvcmdlIER1bmxhcCA8Z3dkQHhlbnByb2plY3Qub3JnPgpTdWJqZWN0OiB4ODYvcHY6 IG1hcCBlYWNoIHZDUFUncyByb290IHBhZ2UgdGFibGUgaW4gaXRzIHBlci1kb21haW4gYXJlYQoK Rm9yIFhQVEkgZW5hYmxlZCBWTXMsIHJlc3RvcmVfYWxsX2d1ZXN0KCkgY29waWVzIG1vc3Qgb2Yg dGhlIGFjdGl2ZSBMNApwYWdldGFibGUgaW50byB0aGUgcGVyLUNQVSByb290X3BndC4gIFRoZSBM NCBpcyByZWFkIHZpYSB0aGUKZGlyZWN0bWFwLgoKVW5mb3J0dW5hdGVseSwgdGhlcmUgd2FzIG5v IGFjY291bnRpbmcgZm9yIHRoZSBmYWN0IHRoYXQgUFYgZ3Vlc3RzCmhhdmUgc2hvcnQgZGlyZWN0 bWFwcy4gIEZvciBhbiBMNCBsaXZpbmcgYmV5b25kIHRoZSA1VCBib3VuZGFyeSAoMy41VApmb3Ig Q09ORklHX0JJR01FTSksIFhlbiB3aWxsIGNvcHkgYXJiaXRyYXJ5IGRhdGEgZnJvbSBndWVzdC1j b250cm9sbGVkCnZpcnR1YWwgYWRkcmVzcyBzcGFjZSBpbnRvIHRoZSBwZXItQ1BVIHJvb3RfcGd0 LCBpbnN0ZWFkIG9mIHRoZQppbnRlbmRlZCBMNC4KClhlbiBoYXMgcGVyLWRvbWFpbiBtYXBwaW5n cyBmb3IgdGhlIExEVCBhbmQgR0RULCB3aXRoIHR3byBwYWdlcwpyZXNlcnZlZCBmb3IgWGVuJ3Mg dXNlIGluIHRoZSBHRFQgYnV0IG9ubHkgb25lIGluIHVzZS4gIFJldXNlIEdEVCBwYWdlCjE1IHRv IG1hcCB0aGUgZWZmZWN0aXZlIEw0LiAgVGhlIEdEVCBsaW1pdCBrZWVwcyBpbXBsaWNpdCBhY2Nl c3NlcyBvdXQKb2YgdGhpcyBwYWdlLgoKV2UgdXBkYXRlIHRoaXMgbWFwcGluZyBpbiBtYWtlX2Ny MygpLCB0aGUgb25seSBwbGFjZSBhIG5vbi1lbXB0eSB2YWx1ZQpvZiB2LT5hcmNoLmNyMyBpcyB3 cml0dGVuIGludG8gYSBndWVzdCdzIHZjcHUgc3RydWN0LCBmb3IgdHdvIHJlYXNvbnMuCkZpcnN0 IGlzIHJlZmVyZW5jZSBjb3VudGluZzogdGhpcyBtYWtlcyBpdCBlYXNpZXIgdG8gYXJndWUgdGhh dCB0aGUKcmVmZXJlbmNlIGZvciB2LT5hcmNoLmNyMyBpdHNlbGYgY292ZXJzIHRoZSByZWZlcmVu Y2UgZm9yIHRoZSBtYXBwaW5nLgoKU2Vjb25kbHksIHRoaXMgZ3VhcmFudGVlcyB0aGF0IGFsbCB1 cGRhdGVzLCBldmVuIHVwZGF0ZXMgbWFkZSBpbgpzaGFkb3cgbW9kZSwgcmVzdWx0IGluIGFuIHVw ZGF0ZSB0byB0aGUgbWFwcGluZy4gIER1cmluZyBsaXZlCm1pZ3JhdGlvbiwgaXQncyBwb3NzaWJs ZSBmb3IgZ3Vlc3RfZ2V0X2VmZl9rZXJuX2wxZSgpIHRvIHJlc3VsdCBpbiBhCm1vZGlmaWVkIHZh bHVlIG9mIHYtPmFyY2guY3IzIChza2V0Y2ggYmVsb3cpOyBwbGFjaW5nIHRoZSBtYXBwaW5nCnVw ZGF0ZSBhdCBtYWtlX2NyMygpIGNhdGNoZXMgdGhpcywgd2hpbGUgb3RoZXIgY2FuZGlkYXRlIGxv Y2F0aW9ucwpsaWtlIHdyaXRlX3B0YmFzZSgpIGFuZCB0b2dnbGVfZ3Vlc3RfbW9kZSgpIGRvbid0 LgoKTm90ZSB0aGF0IHdlIGludHJvZHVjZSB0aGUgaWRlYSBvZiBhbiAiZWZmZWN0aXZlIEw0IiBo ZXJlLCB0byBtZWFuCiJndWVzdCBMNCBhZnRlciBhbnkgdHJhbnNmb3JtYXRpb25zIjogWFBUSSBj b3BpZXMgZWl0aGVyIHRoZSBhY3R1YWwKZ3Vlc3QgTDQgaWYgbm90IHNoYWRvd2VkLCBvciB0aGUg c2hhZG93IEw0ICh0cmFuc2Zvcm1lZCkgaWYgc2hhZG93ZWQuCgpTa2V0Y2g6IGd1ZXN0X2dldF9l ZmZfa2Vybl9sMWUoKSBoYXMgYSBwYWlyIG9mIHRvZ2dsZV9ndWVzdF9wdCgpIGNhbGxzCndoaWNo IGhhcHBlbiBpZiB0aGUgZ3Vlc3QgaXMgaW4gdXNlciBtb2RlLiAgRHVyaW5nIGxpdmUgbWlncmF0 aW9uLCBhCmxvZy1kaXJ0eSBjbGVhbiB3aWxsIGRvIGEgZG9tYWluX3BhdXNlIGFuZCB0aGVuIGNh bGwKc2hhZG93X2Jsb3dfdGFibGVzKCksIHVucGlubmluZyB0aGUgc2hhZG93IG9mIHRoZSBndWVz dCB1c2VyIHJvb3QKcGFnZXRhYmxlLiAgQWZ0ZXIgZXhlY3V0aW9uIHJlc3VtZXMsIHRoZSBmaXJz dCB0b2dnbGVfZ3Vlc3RfcHQoKSBjb3VsZAp0aGVuIGNhdXNlIHRoYXQgcGFnZSB0byBiZWNvbWUg dW5zaGFkb3dlZC4gIFRoZSBzZWNvbmQKdG9nZ2xlX2d1ZXN0X3B0KCkgd291bGQgdGhlbiByZS1z aGFkb3cgaXQsIHBvc3NpYmx5IHdpdGggYSBkaWZmZXJlbnQKYmFja2luZyBzaGFkb3cgcGFnZS4K ClRoaXMgaXMgWFNBLTUxNiAvIENWRS0yMDI2LTc5NjA5LgoKRml4ZXM6IDU3ODRkZTNlMjA2NyAo Ing4NjogTWVsdGRvd24gYmFuZC1haWQgYWdhaW5zdCBtYWxpY2lvdXMgNjQtYml0IFBWIGd1ZXN0 cyIpCkFzc2lzdGVkLWJ5OiBDbGF1ZGUgQ29kZTpjbGF1ZGUtZmFibGUtNS0xClNpZ25lZC1vZmYt Ynk6IEdlb3JnZSBEdW5sYXAgPGd3ZEB4ZW5wcm9qZWN0Lm9yZz4KUmV2aWV3ZWQtYnk6IEphbiBC ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz bS9jb25maWcuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY29uZmlnLmgKQEAgLTI5 NiwxMSArMjk2LDMwIEBAIGV4dGVybiB1bnNpZ25lZCBsb25nIHhlbl9waHlzX3N0YXJ0OwogI2Rl ZmluZSBHRFRfTERUX1ZJUlRfU1RBUlQgICAgICAgUEVSRE9NQUlOX1ZJUlRfU0xPVCgwKQogI2Rl ZmluZSBHRFRfTERUX1ZJUlRfRU5EICAgICAgICAgKEdEVF9MRFRfVklSVF9TVEFSVCArIChHRFRf TERUX01CWVRFUyA8PCAyMCkpCiAKLS8qIFRoZSBhZGRyZXNzIG9mIGEgcGFydGljdWxhciBWQ1BV J3MgR0RUIG9yIExEVC4gKi8KKy8qCisgKiBUaGUgYWRkcmVzcyBvZiBhIHBhcnRpY3VsYXIgVkNQ VSdzIEdEVCBvciBMRFQ7IGVhY2ggaXMgdGhlIGFyY2hpdGVjdHVyYWwKKyAqIG1heGltdW0gb2Yg NjRrLgorICovCisjZGVmaW5lIEdEVF9WSVJUX1NJWkUgICAgICAgIEtCKDY0KQogI2RlZmluZSBH RFRfVklSVF9TVEFSVCh2KSAgICBcCiAgICAgKFBFUkRPTUFJTl9WSVJUX1NUQVJUICsgKCh2KS0+ dmNwdV9pZCA8PCBHRFRfTERUX1ZDUFVfVkFfU0hJRlQpKQogI2RlZmluZSBMRFRfVklSVF9TVEFS VCh2KSAgICBcCi0gICAgKEdEVF9WSVJUX1NUQVJUKHYpICsgKDY0KjEwMjQpKQorICAgIChHRFRf VklSVF9TVEFSVCh2KSArIEdEVF9WSVJUX1NJWkUpCisKKy8qCisgKiBUaGUgdkNQVSdzIGVmZmVj dGl2ZSByb290IHBhZ2UgdGFibGUsIG1hcHBlZCByZWFkLW9ubHkgaW4gdGhlIGxhc3QKKyAqIHBh Z2Ugb2YgaXRzIEdEVDogdGhlIHBhZ2UgYWZ0ZXIgWGVuJ3MgcmVzZXJ2ZWQgcmFuZ2UsIGJleW9u ZCB0aGUKKyAqIEdEVCBsaW1pdCBYZW4gbG9hZHMgKExBU1RfUkVTRVJWRURfR0RUX0JZVEUpLCBz byBubyBzZWxlY3RvciBjYW4KKyAqIHJlYWNoIGl0LiAgIkVmZmVjdGl2ZSIgaXMgdGhlIHJvb3Qg cGFnZSB0YWJsZSB0aGUgdkNQVSBpcyBtZWFudCB0bworICogcnVuIG9uIGFmdGVyIGFueSB0cmFu c2Zvcm1hdGlvbjogdGhlIGd1ZXN0J3Mgb3duLCBvciBpdHMgc2hhZG93CisgKiB1bmRlciBzaGFk b3cgcGFnaW5nLiAgWFBUSSBkb2VzIG5vdCB0cmFuc2Zvcm0gaXQgZnVydGhlciBidXQgY29waWVz CisgKiBmcm9tIGl0OiB0aGUgZXhpdCBwYXRoIHJlYWRzIHRoZSBndWVzdC12aXNpYmxlIEw0IHNs b3RzIGZyb20gaGVyZS4KKyAqIEFkZGluZyBhIHJlc2VydmVkIEdEVCBwYWdlIHdvdWxkIG1lYW4g bW92aW5nIHRoZSB3aW5kb3cgb3V0IG9mIHRoZQorICogR0RUIGZpcnN0OyBwdl9tYXBfZWZmX3Jv b3RfcHQoKSBjaGVja3MgdGhlIGxheW91dCBhdCBidWlsZCB0aW1lLgorICovCisjZGVmaW5lIFBW X0VGRl9ST09UX1BUX1BBR0UgICAgKEZJUlNUX1JFU0VSVkVEX0dEVF9QQUdFICsgMSkKKyNkZWZp bmUgUFZfRUZGX1JPT1RfUFRfT0ZGU0VUICAoUFZfRUZGX1JPT1RfUFRfUEFHRSA8PCBQQUdFX1NI SUZUKQorI2RlZmluZSBQVl9FRkZfUk9PVF9QVCh2KSAgICAgIChHRFRfVklSVF9TVEFSVCh2KSAr IFBWX0VGRl9ST09UX1BUX09GRlNFVCkKIAogLyogbWFwX2RvbWFpbl9wYWdlKCkgbWFwIGNhY2hl LiBUaGUgc2Vjb25kIHBlci1kb21haW4tbWFwcGluZyBzdWItYXJlYS4gKi8KICNkZWZpbmUgTUFQ Q0FDSEVfVkNQVV9FTlRSSUVTICAgIChDT05GSUdfUEFHSU5HX0xFVkVMUyAqIENPTkZJR19QQUdJ TkdfTEVWRUxTKQotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZGVzYy5oCisrKyBiL3hl bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9kZXNjLmgKQEAgLTYsNiArNiwxNiBAQAogLyoKICAqIFhl biByZXNlcnZlcyBhIG1lbW9yeSBwYWdlIG9mIEdEVCBlbnRyaWVzLgogICogTm8gZ3Vlc3QgR0RU IGVudHJpZXMgZXhpc3QgYmV5b25kIHRoZSBYZW4gcmVzZXJ2ZWQgYXJlYS4KKyAqCisgKiBUaGUg cGFnZSBhZnRlciB0aGUgcmVzZXJ2ZWQgYXJlYSwgdGhlIGxhc3Qgb2YgdGhlIEdEVCdzIDY0aywg aXMgdGhlCisgKiBQViBlZmZlY3RpdmUgcm9vdC10YWJsZSB3aW5kb3cgKFBWX0VGRl9ST09UX1BU X1BBR0UsIGNvbmZpZy5oKToKKyAqIGJleW9uZCB0aGUgR0RUIGxpbWl0IFhlbiBsb2FkcyAoTEFT VF9SRVNFUlZFRF9HRFRfQllURSksIHNvIG5vCisgKiBzZWxlY3RvciByZWFjaGVzIGl0LiAgWGVu IHVzZXMgb25seSBhIGZldyBvZiB0aGUgcmVzZXJ2ZWQgcGFnZSdzCisgKiA1MTIgc2xvdHMsIHNv IG1vcmUgWGVuIGRlc2NyaXB0b3JzIG5ldmVyIG5lZWQgYW5vdGhlciBwYWdlOyBpZiBvbmUKKyAq IHdlcmUgbmVlZGVkIHJlZ2FyZGxlc3MsIHRoZSB3aW5kb3cgd291bGQgaGF2ZSB0byBtb3ZlIG91 dCBvZiB0aGUKKyAqIEdEVCBmaXJzdCAoaW50byBhIHBlci1kb21haW4gc3ViLWFyZWEgb2YgaXRz IG93biksIGFzIHRoaXMgaXMgdGhlCisgKiBHRFQncyBsYXN0IHBhZ2UuICBwdl9tYXBfZWZmX3Jv b3RfcHQoKSBjaGVja3MgdGhlIGxheW91dCBhdCBidWlsZAorICogdGltZS4KICAqLwogI2RlZmlu ZSBOUl9SRVNFUlZFRF9HRFRfUEFHRVMgICAxCiAjZGVmaW5lIE5SX1JFU0VSVkVEX0dEVF9CWVRF UyAgIChOUl9SRVNFUlZFRF9HRFRfUEFHRVMgKiBQQUdFX1NJWkUpCi0tLSBhL3hlbi9hcmNoL3g4 Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5jCkBAIC01MjMsMTMgKzUyMyw1MiBAQCB2b2lk IHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhCiAgICAgc3Bpbl91bmxvY2soJmQt PnBhZ2VfYWxsb2NfbG9jayk7CiB9CiAKKy8qCisgKiBNYXAgQG1mbiByZWFkLW9ubHkgYXQgdidz IFBWX0VGRl9ST09UX1BUKCkgd2luZG93LiAgVGhlIHdpbmRvdyBsaXZlcyBpbgorICogdidzIHBl ci1kb21haW4gYXJlYSwgc28gdiBuZWVkIG5vdCBiZSBjdXJyZW50OyB0aGUgbG9jYWwgZmx1c2gg aXMgZm9yCisgKiB3aGVuIGl0IGlzLCB3aXRoIGl0cyBvd24gcGFnZSB0YWJsZXMgbG9hZGVkLgor ICovCitzdGF0aWMgdm9pZCBwdl9tYXBfZWZmX3Jvb3RfcHQoY29uc3Qgc3RydWN0IHZjcHUgKnYs IG1mbl90IG1mbikKK3sKKyAgICAvKgorICAgICAqIFRoZSB3aW5kb3cgbXVzdCBsaWUgYmV5b25k IHRoZSBHRFQgbGltaXQgWGVuIGxvYWRzLCBzbyB0aGF0IG5vCisgICAgICogc2VsZWN0b3IgcmVh Y2hlcyBpdCwgYW5kIHdpdGhpbiB0aGUgR0RUJ3MgNjRrLgorICAgICAqLworICAgIEJVSUxEX0JV R19PTihQVl9FRkZfUk9PVF9QVF9PRkZTRVQgPD0gTEFTVF9SRVNFUlZFRF9HRFRfQllURSk7Cisg ICAgQlVJTERfQlVHX09OKFBWX0VGRl9ST09UX1BUX09GRlNFVCArIFBBR0VfU0laRSA+IEdEVF9W SVJUX1NJWkUpOworCisgICAgbDFlX3dyaXRlKHB2X2dkdF9wdGVzKHYpICsgUFZfRUZGX1JPT1Rf UFRfUEFHRSwKKyAgICAgICAgICAgICAgbDFlX2Zyb21fbWZuKG1mbiwgX19QQUdFX0hZUEVSVklT T1JfUk8pKTsKKyAgICBmbHVzaF90bGJfb25lX2xvY2FsKFBWX0VGRl9ST09UX1BUKHYpKTsKK30K KworLyoKKyAqIENsZWFyIHRoZSB3aW5kb3cuICBJdHMgbGlmZXRpbWUgaXMgdi0+YXJjaC5jcjMn czogbWFrZV9jcjMoKSB3cml0ZXMgaXQKKyAqIHdoZXJldmVyIHYtPmFyY2guY3IzIGlzIHNldCwg YW5kIHZjcHVfZGVzdHJveV9wYWdldGFibGVzKCkgY2xlYXJzIGl0IHdoZXJlCisgKiB2LT5hcmNo LmNyMyBpcyB6ZXJvZWQuICBJbiBzaGFkb3cgbW9kZSBib3RoIG5hbWUgYSB0b3AtbGV2ZWwgc2hh ZG93LCB3aGljaAorICogc2hhZG93X3RlYXJkb3duKCkgcmVsZWFzZXMgYmVmb3JlIHRoYXQgcG9p bnQ7IG5vdGhpbmcgdXNlcyBlaXRoZXIgb25jZSB0aGUKKyAqIHZDUFUgY2FuIG5vIGxvbmdlciBy dW4uCisgKi8KK3N0YXRpYyB2b2lkIHB2X3VubWFwX2VmZl9yb290X3B0KGNvbnN0IHN0cnVjdCB2 Y3B1ICp2KQoreworICAgIGwxZV93cml0ZShwdl9nZHRfcHRlcyh2KSArIFBWX0VGRl9ST09UX1BU X1BBR0UsIGwxZV9lbXB0eSgpKTsKKyAgICBmbHVzaF90bGJfb25lX2xvY2FsKFBWX0VGRl9ST09U X1BUKHYpKTsKK30KKwogdm9pZCBtYWtlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwgbWZuX3QgbWZuKQog ewogICAgIHN0cnVjdCBkb21haW4gKmQgPSB2LT5kb21haW47CiAKICAgICB2LT5hcmNoLmNyMyA9 IG1mbl94KG1mbikgPDwgUEFHRV9TSElGVDsKLSAgICBpZiAoIGlzX3B2X2RvbWFpbihkKSAmJiBk LT5hcmNoLnB2LnBjaWQgKQotICAgICAgICB2LT5hcmNoLmNyMyB8PSBnZXRfcGNpZF9iaXRzKHYs IGZhbHNlKTsKKworICAgIGlmICggaXNfcHZfZG9tYWluKGQpICkKKyAgICB7CisgICAgICAgIGlm ICggZC0+YXJjaC5wdi5wY2lkICkKKyAgICAgICAgICAgIHYtPmFyY2guY3IzIHw9IGdldF9wY2lk X2JpdHModiwgZmFsc2UpOworCisgICAgICAgIGlmICggZC0+YXJjaC5wdi54cHRpICkKKyAgICAg ICAgICAgIHB2X21hcF9lZmZfcm9vdF9wdCh2LCBtZm4pOworICAgIH0KIH0KIAogdm9pZCB3cml0 ZV9wdGJhc2Uoc3RydWN0IHZjcHUgKnYpCkBAIC0zMjEzLDYgKzMyNTIsOCBAQCBpbnQgdmNwdV9k ZXN0cm95X3BhZ2V0YWJsZXMoc3RydWN0IHZjcHUKICAgICAgICAgcmV0dXJuIHJjOwogCiAgICAg di0+YXJjaC5jcjMgPSAwOworICAgIGlmICggaXNfcHZfZG9tYWluKHYtPmRvbWFpbikgJiYgdi0+ ZG9tYWluLT5hcmNoLnB2LnhwdGkgKQorICAgICAgICBwdl91bm1hcF9lZmZfcm9vdF9wdCh2KTsK IAogICAgIC8qCiAgICAgICogR2V0IHRoZSB0b3AtbGV2ZWwgZ3Vlc3QgcGFnZTsgZWl0aGVyIHRo ZSBndWVzdF90YWJsZSBpdHNlbGYsIGZvcgotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1v ZmZzZXRzLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCkBAIC03Niw2 ICs3Niw3IEBAIHZvaWQgX19kdW1teV9fKHZvaWQpCiAKICN1bmRlZiBPRkZTRVRfRUYKIAorICAg IE9GRlNFVChWQ1BVX2lkLCBzdHJ1Y3QgdmNwdSwgdmNwdV9pZCk7CiAgICAgT0ZGU0VUKFZDUFVf cHJvY2Vzc29yLCBzdHJ1Y3QgdmNwdSwgcHJvY2Vzc29yKTsKICAgICBPRkZTRVQoVkNQVV9kb21h aW4sIHN0cnVjdCB2Y3B1LCBkb21haW4pOwogICAgIE9GRlNFVChWQ1BVX3ZjcHVfaW5mbywgc3Ry dWN0IHZjcHUsIHZjcHVfaW5mbyk7Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwor KysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKQEAgLTE3Myw5ICsxNzMsMTQgQEAgcmVz dG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIG1vdmFicyAkUEFERFJfTUFTSyAmIFBBR0VfTUFTSywg JXJzaQogICAgICAgICBtb3ZhYnMgJERJUkVDVE1BUF9WSVJUX1NUQVJULCAlcmN4CiAgICAgICAg IGFuZCAgICVyc2ksICVyZGkKLSAgICAgICAgYW5kICAgJXI5LCAlcnNpCiAgICAgICAgIGFkZCAg ICVyY3gsICVyZGkKKworICAgICAgICAvKiBFZmZlY3RpdmUgcm9vdCBwYWdlIHRhYmxlIGlzIG1h cHBlZCBhdCBQVl9FRkZfUk9PVF9QVCh2KSAqLworICAgICAgICBtb3YgICBWQ1BVX2lkKCVyYngp LCAlZXNpCisgICAgICAgIHNobCAgICRHRFRfTERUX1ZDUFVfVkFfU0hJRlQsICVyc2kKKyAgICAg ICAgbW92YWJzICRHRFRfTERUX1ZJUlRfU1RBUlQgKyBQVl9FRkZfUk9PVF9QVF9PRkZTRVQsICVy Y3gKICAgICAgICAgYWRkICAgJXJjeCwgJXJzaQorCiAgICAgICAgIG1vdiAgICRST09UX1BBR0VU QUJMRV9GSVJTVF9YRU5fU0xPVCwgJWVjeAogICAgICAgICBtb3YgICByb290X3RhYmxlX29mZnNl dChTSF9MSU5FQVJfUFRfVklSVF9TVEFSVCkqOCglcnNpKSwgJXI4CiAgICAgICAgIG1vdiAgICVy OCwgcm9vdF90YWJsZV9vZmZzZXQoU0hfTElORUFSX1BUX1ZJUlRfU1RBUlQpKjgoJXJkaSkK --=separator Content-Type: application/octet-stream; name="xsa516-4.18.patch" Content-Disposition: attachment; filename="xsa516-4.18.patch" Content-Transfer-Encoding: base64 RnJvbTogR2VvcmdlIER1bmxhcCA8Z3dkQHhlbnByb2plY3Qub3JnPgpTdWJqZWN0OiB4ODYvcHY6 IG1hcCBlYWNoIHZDUFUncyByb290IHBhZ2UgdGFibGUgaW4gaXRzIHBlci1kb21haW4gYXJlYQoK Rm9yIFhQVEkgZW5hYmxlZCBWTXMsIHJlc3RvcmVfYWxsX2d1ZXN0KCkgY29waWVzIG1vc3Qgb2Yg dGhlIGFjdGl2ZSBMNApwYWdldGFibGUgaW50byB0aGUgcGVyLUNQVSByb290X3BndC4gIFRoZSBM NCBpcyByZWFkIHZpYSB0aGUKZGlyZWN0bWFwLgoKVW5mb3J0dW5hdGVseSwgdGhlcmUgd2FzIG5v IGFjY291bnRpbmcgZm9yIHRoZSBmYWN0IHRoYXQgUFYgZ3Vlc3RzCmhhdmUgc2hvcnQgZGlyZWN0 bWFwcy4gIEZvciBhbiBMNCBsaXZpbmcgYmV5b25kIHRoZSA1VCBib3VuZGFyeSAoMy41VApmb3Ig Q09ORklHX0JJR01FTSksIFhlbiB3aWxsIGNvcHkgYXJiaXRyYXJ5IGRhdGEgZnJvbSBndWVzdC1j b250cm9sbGVkCnZpcnR1YWwgYWRkcmVzcyBzcGFjZSBpbnRvIHRoZSBwZXItQ1BVIHJvb3RfcGd0 LCBpbnN0ZWFkIG9mIHRoZQppbnRlbmRlZCBMNC4KClhlbiBoYXMgcGVyLWRvbWFpbiBtYXBwaW5n cyBmb3IgdGhlIExEVCBhbmQgR0RULCB3aXRoIHR3byBwYWdlcwpyZXNlcnZlZCBmb3IgWGVuJ3Mg dXNlIGluIHRoZSBHRFQgYnV0IG9ubHkgb25lIGluIHVzZS4gIFJldXNlIEdEVCBwYWdlCjE1IHRv IG1hcCB0aGUgZWZmZWN0aXZlIEw0LiAgVGhlIEdEVCBsaW1pdCBrZWVwcyBpbXBsaWNpdCBhY2Nl c3NlcyBvdXQKb2YgdGhpcyBwYWdlLgoKV2UgdXBkYXRlIHRoaXMgbWFwcGluZyBpbiBtYWtlX2Ny MygpLCB0aGUgb25seSBwbGFjZSBhIG5vbi1lbXB0eSB2YWx1ZQpvZiB2LT5hcmNoLmNyMyBpcyB3 cml0dGVuIGludG8gYSBndWVzdCdzIHZjcHUgc3RydWN0LCBmb3IgdHdvIHJlYXNvbnMuCkZpcnN0 IGlzIHJlZmVyZW5jZSBjb3VudGluZzogdGhpcyBtYWtlcyBpdCBlYXNpZXIgdG8gYXJndWUgdGhh dCB0aGUKcmVmZXJlbmNlIGZvciB2LT5hcmNoLmNyMyBpdHNlbGYgY292ZXJzIHRoZSByZWZlcmVu Y2UgZm9yIHRoZSBtYXBwaW5nLgoKU2Vjb25kbHksIHRoaXMgZ3VhcmFudGVlcyB0aGF0IGFsbCB1 cGRhdGVzLCBldmVuIHVwZGF0ZXMgbWFkZSBpbgpzaGFkb3cgbW9kZSwgcmVzdWx0IGluIGFuIHVw ZGF0ZSB0byB0aGUgbWFwcGluZy4gIER1cmluZyBsaXZlCm1pZ3JhdGlvbiwgaXQncyBwb3NzaWJs ZSBmb3IgZ3Vlc3RfZ2V0X2VmZl9rZXJuX2wxZSgpIHRvIHJlc3VsdCBpbiBhCm1vZGlmaWVkIHZh bHVlIG9mIHYtPmFyY2guY3IzIChza2V0Y2ggYmVsb3cpOyBwbGFjaW5nIHRoZSBtYXBwaW5nCnVw ZGF0ZSBhdCBtYWtlX2NyMygpIGNhdGNoZXMgdGhpcywgd2hpbGUgb3RoZXIgY2FuZGlkYXRlIGxv Y2F0aW9ucwpsaWtlIHdyaXRlX3B0YmFzZSgpIGFuZCB0b2dnbGVfZ3Vlc3RfbW9kZSgpIGRvbid0 LgoKTm90ZSB0aGF0IHdlIGludHJvZHVjZSB0aGUgaWRlYSBvZiBhbiAiZWZmZWN0aXZlIEw0IiBo ZXJlLCB0byBtZWFuCiJndWVzdCBMNCBhZnRlciBhbnkgdHJhbnNmb3JtYXRpb25zIjogWFBUSSBj b3BpZXMgZWl0aGVyIHRoZSBhY3R1YWwKZ3Vlc3QgTDQgaWYgbm90IHNoYWRvd2VkLCBvciB0aGUg c2hhZG93IEw0ICh0cmFuc2Zvcm1lZCkgaWYgc2hhZG93ZWQuCgpTa2V0Y2g6IGd1ZXN0X2dldF9l ZmZfa2Vybl9sMWUoKSBoYXMgYSBwYWlyIG9mIHRvZ2dsZV9ndWVzdF9wdCgpIGNhbGxzCndoaWNo IGhhcHBlbiBpZiB0aGUgZ3Vlc3QgaXMgaW4gdXNlciBtb2RlLiAgRHVyaW5nIGxpdmUgbWlncmF0 aW9uLCBhCmxvZy1kaXJ0eSBjbGVhbiB3aWxsIGRvIGEgZG9tYWluX3BhdXNlIGFuZCB0aGVuIGNh bGwKc2hhZG93X2Jsb3dfdGFibGVzKCksIHVucGlubmluZyB0aGUgc2hhZG93IG9mIHRoZSBndWVz dCB1c2VyIHJvb3QKcGFnZXRhYmxlLiAgQWZ0ZXIgZXhlY3V0aW9uIHJlc3VtZXMsIHRoZSBmaXJz dCB0b2dnbGVfZ3Vlc3RfcHQoKSBjb3VsZAp0aGVuIGNhdXNlIHRoYXQgcGFnZSB0byBiZWNvbWUg dW5zaGFkb3dlZC4gIFRoZSBzZWNvbmQKdG9nZ2xlX2d1ZXN0X3B0KCkgd291bGQgdGhlbiByZS1z aGFkb3cgaXQsIHBvc3NpYmx5IHdpdGggYSBkaWZmZXJlbnQKYmFja2luZyBzaGFkb3cgcGFnZS4K ClRoaXMgaXMgWFNBLTUxNiAvIENWRS0yMDI2LTc5NjA5LgoKRml4ZXM6IDU3ODRkZTNlMjA2NyAo Ing4NjogTWVsdGRvd24gYmFuZC1haWQgYWdhaW5zdCBtYWxpY2lvdXMgNjQtYml0IFBWIGd1ZXN0 cyIpCkFzc2lzdGVkLWJ5OiBDbGF1ZGUgQ29kZTpjbGF1ZGUtZmFibGUtNS0xClNpZ25lZC1vZmYt Ynk6IEdlb3JnZSBEdW5sYXAgPGd3ZEB4ZW5wcm9qZWN0Lm9yZz4KUmV2aWV3ZWQtYnk6IEphbiBC ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz bS9jb25maWcuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY29uZmlnLmgKQEAgLTI5 NiwxMSArMjk2LDMwIEBAIGV4dGVybiB1bnNpZ25lZCBsb25nIHhlbl9waHlzX3N0YXJ0OwogI2Rl ZmluZSBHRFRfTERUX1ZJUlRfU1RBUlQgICAgICAgUEVSRE9NQUlOX1ZJUlRfU0xPVCgwKQogI2Rl ZmluZSBHRFRfTERUX1ZJUlRfRU5EICAgICAgICAgKEdEVF9MRFRfVklSVF9TVEFSVCArIChHRFRf TERUX01CWVRFUyA8PCAyMCkpCiAKLS8qIFRoZSBhZGRyZXNzIG9mIGEgcGFydGljdWxhciBWQ1BV J3MgR0RUIG9yIExEVC4gKi8KKy8qCisgKiBUaGUgYWRkcmVzcyBvZiBhIHBhcnRpY3VsYXIgVkNQ VSdzIEdEVCBvciBMRFQ7IGVhY2ggaXMgdGhlIGFyY2hpdGVjdHVyYWwKKyAqIG1heGltdW0gb2Yg NjRrLgorICovCisjZGVmaW5lIEdEVF9WSVJUX1NJWkUgICAgICAgIEtCKDY0KQogI2RlZmluZSBH RFRfVklSVF9TVEFSVCh2KSAgICBcCiAgICAgKFBFUkRPTUFJTl9WSVJUX1NUQVJUICsgKCh2KS0+ dmNwdV9pZCA8PCBHRFRfTERUX1ZDUFVfVkFfU0hJRlQpKQogI2RlZmluZSBMRFRfVklSVF9TVEFS VCh2KSAgICBcCi0gICAgKEdEVF9WSVJUX1NUQVJUKHYpICsgKDY0KjEwMjQpKQorICAgIChHRFRf VklSVF9TVEFSVCh2KSArIEdEVF9WSVJUX1NJWkUpCisKKy8qCisgKiBUaGUgdkNQVSdzIGVmZmVj dGl2ZSByb290IHBhZ2UgdGFibGUsIG1hcHBlZCByZWFkLW9ubHkgaW4gdGhlIGxhc3QKKyAqIHBh Z2Ugb2YgaXRzIEdEVDogdGhlIHBhZ2UgYWZ0ZXIgWGVuJ3MgcmVzZXJ2ZWQgcmFuZ2UsIGJleW9u ZCB0aGUKKyAqIEdEVCBsaW1pdCBYZW4gbG9hZHMgKExBU1RfUkVTRVJWRURfR0RUX0JZVEUpLCBz byBubyBzZWxlY3RvciBjYW4KKyAqIHJlYWNoIGl0LiAgIkVmZmVjdGl2ZSIgaXMgdGhlIHJvb3Qg cGFnZSB0YWJsZSB0aGUgdkNQVSBpcyBtZWFudCB0bworICogcnVuIG9uIGFmdGVyIGFueSB0cmFu c2Zvcm1hdGlvbjogdGhlIGd1ZXN0J3Mgb3duLCBvciBpdHMgc2hhZG93CisgKiB1bmRlciBzaGFk b3cgcGFnaW5nLiAgWFBUSSBkb2VzIG5vdCB0cmFuc2Zvcm0gaXQgZnVydGhlciBidXQgY29waWVz CisgKiBmcm9tIGl0OiB0aGUgZXhpdCBwYXRoIHJlYWRzIHRoZSBndWVzdC12aXNpYmxlIEw0IHNs b3RzIGZyb20gaGVyZS4KKyAqIEFkZGluZyBhIHJlc2VydmVkIEdEVCBwYWdlIHdvdWxkIG1lYW4g bW92aW5nIHRoZSB3aW5kb3cgb3V0IG9mIHRoZQorICogR0RUIGZpcnN0OyBwdl9tYXBfZWZmX3Jv b3RfcHQoKSBjaGVja3MgdGhlIGxheW91dCBhdCBidWlsZCB0aW1lLgorICovCisjZGVmaW5lIFBW X0VGRl9ST09UX1BUX1BBR0UgICAgKEZJUlNUX1JFU0VSVkVEX0dEVF9QQUdFICsgMSkKKyNkZWZp bmUgUFZfRUZGX1JPT1RfUFRfT0ZGU0VUICAoUFZfRUZGX1JPT1RfUFRfUEFHRSA8PCBQQUdFX1NI SUZUKQorI2RlZmluZSBQVl9FRkZfUk9PVF9QVCh2KSAgICAgIChHRFRfVklSVF9TVEFSVCh2KSAr IFBWX0VGRl9ST09UX1BUX09GRlNFVCkKIAogLyogbWFwX2RvbWFpbl9wYWdlKCkgbWFwIGNhY2hl LiBUaGUgc2Vjb25kIHBlci1kb21haW4tbWFwcGluZyBzdWItYXJlYS4gKi8KICNkZWZpbmUgTUFQ Q0FDSEVfVkNQVV9FTlRSSUVTICAgIChDT05GSUdfUEFHSU5HX0xFVkVMUyAqIENPTkZJR19QQUdJ TkdfTEVWRUxTKQotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZGVzYy5oCisrKyBiL3hl bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9kZXNjLmgKQEAgLTYsNiArNiwxNiBAQAogLyoKICAqIFhl biByZXNlcnZlcyBhIG1lbW9yeSBwYWdlIG9mIEdEVCBlbnRyaWVzLgogICogTm8gZ3Vlc3QgR0RU IGVudHJpZXMgZXhpc3QgYmV5b25kIHRoZSBYZW4gcmVzZXJ2ZWQgYXJlYS4KKyAqCisgKiBUaGUg cGFnZSBhZnRlciB0aGUgcmVzZXJ2ZWQgYXJlYSwgdGhlIGxhc3Qgb2YgdGhlIEdEVCdzIDY0aywg aXMgdGhlCisgKiBQViBlZmZlY3RpdmUgcm9vdC10YWJsZSB3aW5kb3cgKFBWX0VGRl9ST09UX1BU X1BBR0UsIGNvbmZpZy5oKToKKyAqIGJleW9uZCB0aGUgR0RUIGxpbWl0IFhlbiBsb2FkcyAoTEFT VF9SRVNFUlZFRF9HRFRfQllURSksIHNvIG5vCisgKiBzZWxlY3RvciByZWFjaGVzIGl0LiAgWGVu IHVzZXMgb25seSBhIGZldyBvZiB0aGUgcmVzZXJ2ZWQgcGFnZSdzCisgKiA1MTIgc2xvdHMsIHNv IG1vcmUgWGVuIGRlc2NyaXB0b3JzIG5ldmVyIG5lZWQgYW5vdGhlciBwYWdlOyBpZiBvbmUKKyAq IHdlcmUgbmVlZGVkIHJlZ2FyZGxlc3MsIHRoZSB3aW5kb3cgd291bGQgaGF2ZSB0byBtb3ZlIG91 dCBvZiB0aGUKKyAqIEdEVCBmaXJzdCAoaW50byBhIHBlci1kb21haW4gc3ViLWFyZWEgb2YgaXRz IG93biksIGFzIHRoaXMgaXMgdGhlCisgKiBHRFQncyBsYXN0IHBhZ2UuICBwdl9tYXBfZWZmX3Jv b3RfcHQoKSBjaGVja3MgdGhlIGxheW91dCBhdCBidWlsZAorICogdGltZS4KICAqLwogI2RlZmlu ZSBOUl9SRVNFUlZFRF9HRFRfUEFHRVMgICAxCiAjZGVmaW5lIE5SX1JFU0VSVkVEX0dEVF9CWVRF UyAgIChOUl9SRVNFUlZFRF9HRFRfUEFHRVMgKiBQQUdFX1NJWkUpCi0tLSBhL3hlbi9hcmNoL3g4 Ni9tbS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS5jCkBAIC01MDUsMTMgKzUwNSw1MiBAQCB2b2lk IHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhCiAgICAgc3Bpbl91bmxvY2soJmQt PnBhZ2VfYWxsb2NfbG9jayk7CiB9CiAKKy8qCisgKiBNYXAgQG1mbiByZWFkLW9ubHkgYXQgdidz IFBWX0VGRl9ST09UX1BUKCkgd2luZG93LiAgVGhlIHdpbmRvdyBsaXZlcyBpbgorICogdidzIHBl ci1kb21haW4gYXJlYSwgc28gdiBuZWVkIG5vdCBiZSBjdXJyZW50OyB0aGUgbG9jYWwgZmx1c2gg aXMgZm9yCisgKiB3aGVuIGl0IGlzLCB3aXRoIGl0cyBvd24gcGFnZSB0YWJsZXMgbG9hZGVkLgor ICovCitzdGF0aWMgdm9pZCBwdl9tYXBfZWZmX3Jvb3RfcHQoY29uc3Qgc3RydWN0IHZjcHUgKnYs IG1mbl90IG1mbikKK3sKKyAgICAvKgorICAgICAqIFRoZSB3aW5kb3cgbXVzdCBsaWUgYmV5b25k IHRoZSBHRFQgbGltaXQgWGVuIGxvYWRzLCBzbyB0aGF0IG5vCisgICAgICogc2VsZWN0b3IgcmVh Y2hlcyBpdCwgYW5kIHdpdGhpbiB0aGUgR0RUJ3MgNjRrLgorICAgICAqLworICAgIEJVSUxEX0JV R19PTihQVl9FRkZfUk9PVF9QVF9PRkZTRVQgPD0gTEFTVF9SRVNFUlZFRF9HRFRfQllURSk7Cisg ICAgQlVJTERfQlVHX09OKFBWX0VGRl9ST09UX1BUX09GRlNFVCArIFBBR0VfU0laRSA+IEdEVF9W SVJUX1NJWkUpOworCisgICAgbDFlX3dyaXRlKHB2X2dkdF9wdGVzKHYpICsgUFZfRUZGX1JPT1Rf UFRfUEFHRSwKKyAgICAgICAgICAgICAgbDFlX2Zyb21fbWZuKG1mbiwgX19QQUdFX0hZUEVSVklT T1JfUk8pKTsKKyAgICBmbHVzaF90bGJfb25lX2xvY2FsKFBWX0VGRl9ST09UX1BUKHYpKTsKK30K KworLyoKKyAqIENsZWFyIHRoZSB3aW5kb3cuICBJdHMgbGlmZXRpbWUgaXMgdi0+YXJjaC5jcjMn czogbWFrZV9jcjMoKSB3cml0ZXMgaXQKKyAqIHdoZXJldmVyIHYtPmFyY2guY3IzIGlzIHNldCwg YW5kIHZjcHVfZGVzdHJveV9wYWdldGFibGVzKCkgY2xlYXJzIGl0IHdoZXJlCisgKiB2LT5hcmNo LmNyMyBpcyB6ZXJvZWQuICBJbiBzaGFkb3cgbW9kZSBib3RoIG5hbWUgYSB0b3AtbGV2ZWwgc2hh ZG93LCB3aGljaAorICogc2hhZG93X3RlYXJkb3duKCkgcmVsZWFzZXMgYmVmb3JlIHRoYXQgcG9p bnQ7IG5vdGhpbmcgdXNlcyBlaXRoZXIgb25jZSB0aGUKKyAqIHZDUFUgY2FuIG5vIGxvbmdlciBy dW4uCisgKi8KK3N0YXRpYyB2b2lkIHB2X3VubWFwX2VmZl9yb290X3B0KGNvbnN0IHN0cnVjdCB2 Y3B1ICp2KQoreworICAgIGwxZV93cml0ZShwdl9nZHRfcHRlcyh2KSArIFBWX0VGRl9ST09UX1BU X1BBR0UsIGwxZV9lbXB0eSgpKTsKKyAgICBmbHVzaF90bGJfb25lX2xvY2FsKFBWX0VGRl9ST09U X1BUKHYpKTsKK30KKwogdm9pZCBtYWtlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwgbWZuX3QgbWZuKQog ewogICAgIHN0cnVjdCBkb21haW4gKmQgPSB2LT5kb21haW47CiAKICAgICB2LT5hcmNoLmNyMyA9 IG1mbl94KG1mbikgPDwgUEFHRV9TSElGVDsKLSAgICBpZiAoIGlzX3B2X2RvbWFpbihkKSAmJiBk LT5hcmNoLnB2LnBjaWQgKQotICAgICAgICB2LT5hcmNoLmNyMyB8PSBnZXRfcGNpZF9iaXRzKHYs IGZhbHNlKTsKKworICAgIGlmICggaXNfcHZfZG9tYWluKGQpICkKKyAgICB7CisgICAgICAgIGlm ICggZC0+YXJjaC5wdi5wY2lkICkKKyAgICAgICAgICAgIHYtPmFyY2guY3IzIHw9IGdldF9wY2lk X2JpdHModiwgZmFsc2UpOworCisgICAgICAgIGlmICggZC0+YXJjaC5wdi54cHRpICkKKyAgICAg ICAgICAgIHB2X21hcF9lZmZfcm9vdF9wdCh2LCBtZm4pOworICAgIH0KIH0KIAogdm9pZCB3cml0 ZV9wdGJhc2Uoc3RydWN0IHZjcHUgKnYpCkBAIC0zMTk3LDYgKzMyMzYsOCBAQCBpbnQgdmNwdV9k ZXN0cm95X3BhZ2V0YWJsZXMoc3RydWN0IHZjcHUKICAgICAgICAgcmV0dXJuIHJjOwogCiAgICAg di0+YXJjaC5jcjMgPSAwOworICAgIGlmICggaXNfcHZfZG9tYWluKHYtPmRvbWFpbikgJiYgdi0+ ZG9tYWluLT5hcmNoLnB2LnhwdGkgKQorICAgICAgICBwdl91bm1hcF9lZmZfcm9vdF9wdCh2KTsK IAogICAgIC8qCiAgICAgICogR2V0IHRoZSB0b3AtbGV2ZWwgZ3Vlc3QgcGFnZTsgZWl0aGVyIHRo ZSBndWVzdF90YWJsZSBpdHNlbGYsIGZvcgotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2FzbS1v ZmZzZXRzLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCkBAIC03Niw2 ICs3Niw3IEBAIHZvaWQgX19kdW1teV9fKHZvaWQpCiAKICN1bmRlZiBPRkZTRVRfRUYKIAorICAg IE9GRlNFVChWQ1BVX2lkLCBzdHJ1Y3QgdmNwdSwgdmNwdV9pZCk7CiAgICAgT0ZGU0VUKFZDUFVf cHJvY2Vzc29yLCBzdHJ1Y3QgdmNwdSwgcHJvY2Vzc29yKTsKICAgICBPRkZTRVQoVkNQVV9kb21h aW4sIHN0cnVjdCB2Y3B1LCBkb21haW4pOwogICAgIE9GRlNFVChWQ1BVX3ZjcHVfaW5mbywgc3Ry dWN0IHZjcHUsIHZjcHVfaW5mb19hcmVhLm1hcCk7Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQv ZW50cnkuUworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKQEAgLTE3Myw5ICsxNzMs MTQgQEAgcmVzdG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIG1vdmFicyAkUEFERFJfTUFTSyAmIFBB R0VfTUFTSywgJXJzaQogICAgICAgICBtb3ZhYnMgJERJUkVDVE1BUF9WSVJUX1NUQVJULCAlcmN4 CiAgICAgICAgIGFuZCAgICVyc2ksICVyZGkKLSAgICAgICAgYW5kICAgJXI5LCAlcnNpCiAgICAg ICAgIGFkZCAgICVyY3gsICVyZGkKKworICAgICAgICAvKiBFZmZlY3RpdmUgcm9vdCBwYWdlIHRh YmxlIGlzIG1hcHBlZCBhdCBQVl9FRkZfUk9PVF9QVCh2KSAqLworICAgICAgICBtb3YgICBWQ1BV X2lkKCVyYngpLCAlZXNpCisgICAgICAgIHNobCAgICRHRFRfTERUX1ZDUFVfVkFfU0hJRlQsICVy c2kKKyAgICAgICAgbW92YWJzICRHRFRfTERUX1ZJUlRfU1RBUlQgKyBQVl9FRkZfUk9PVF9QVF9P RkZTRVQsICVyY3gKICAgICAgICAgYWRkICAgJXJjeCwgJXJzaQorCiAgICAgICAgIG1vdiAgICRS T09UX1BBR0VUQUJMRV9GSVJTVF9YRU5fU0xPVCwgJWVjeAogICAgICAgICBtb3YgICByb290X3Rh YmxlX29mZnNldChTSF9MSU5FQVJfUFRfVklSVF9TVEFSVCkqOCglcnNpKSwgJXI4CiAgICAgICAg IG1vdiAgICVyOCwgcm9vdF90YWJsZV9vZmZzZXQoU0hfTElORUFSX1BUX1ZJUlRfU1RBUlQpKjgo JXJkaSkK --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:28:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:28:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447120.1663395 (Exim 4.92) (envelope-from ) id 1xGbcl-00082h-8k; Tue, 13 Oct 2026 12:28:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447120.1663395; Tue, 13 Oct 2026 12:28: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 1xGbck-00080O-Ec; Tue, 13 Oct 2026 12:28:54 +0000 Received: by outflank-mailman (input) for mailman id 1447120; Tue, 13 Oct 2026 12:28:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbci-0007Kx-05; Tue, 13 Oct 2026 12:28:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbch-00FMox-CS; Tue, 13 Oct 2026 14:28:51 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace2401-bab6-0a2a0a5309dd-0a2a4509de3a-6 for ; Tue, 13 Oct 2026 14:28:51 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace2402-be1a-0a2a45090019-6882d725a2c4-3 for ; Tue, 13 Oct 2026 14:28:51 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbce-00000003NHL-0WzF; Tue, 13 Oct 2026 12:28:47 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbcd-0000000F8nY-3bRd; Tue, 13 Oct 2026 12:28: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; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 517 v2 (CVE-2026-79610) - grant-table: double version change race Message-Id: Date: Tue, 13 Oct 2026 12:28:47 +0000 X-purgate-ID: tlsNG-bad1c0/1791894531-FD469034-5AEEE705/0/0 X-purgate-type: clean X-purgate-size: 7295 --=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-79610 / XSA-517 version 2 grant-table: double version change race UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= XSA-501 was about issues with v1 -> v2 and v2 -> v1 changes racing certain other grant table operations. Sadly a v2 -> v1 -> v2 change has yet another effect which wasn't accounted for: During the first change, status pages would be freed. During the second change they would be allocated again. Hence across the full pair of change the addresses of the status pages may change, rendering stale previously calculated pointers into the status array. IMPACT ====== An unprivileged guest may be able to elevate its privileges to that of the host. Information leaks and Denial of Service (DoS) are possible as well. VULNERABLE SYSTEMS ================== All Xen versions from 4.0 onwards are vulnerable. Xen versions 3.4 and earlier are not vulnerable. Only x86 guests permitted to use grant table version 2 interfaces can leverage this vulnerability. On Arm, grant table v2 use is explicitly unsupported. Only multi-vCPU guests can leverage this vulnerability. Xen versions 4.13 and newer offer a way to build Xen without grant table support. Such hypervisors (CONFIG_GRANT_TABLE turned off) are not vulnerable. MITIGATION ========== Using the "gnttab=max-ver:1" hypervisor command line option will avoid the vulnerability. Using the "max_grant_version=1" guest configuration option for guests will also avoid the vulnerability. CREDITS ======= This issue was discovered by Claude Opus and diagnosed as a security issue by Teddy Astie of Vates. 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. xsa517.patch xen-unstable - Xen 4.17.x $ sha256sum xsa517* 0f114af84cd925f8bc69b26386e2e4a95a52f947bc400f961a9e1ba46c0a2e05 xsa517.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches 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 restricting the available grant table version 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/4UyVfoK9kFAmrOIlkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZAGUH/3wERoCBP6lIwfFmIMiAcqVVctqz6/8OgplQEp8A inNRPR8Avx++0lt4AdERiNYy3xwxGAZzJsxYC3ipCaHvMwOmm11DiMX5yuhvefNw TJxWaWut2QmF0Vi0G4acvvlfslb9JA9quEgLDzF/2dMiyHzTL4xvdeJ5OR5zXAoD hexjk0DCSDcYRHnD0OautofMGTaBaGJVHz08uRNkz3gOxumAeKnxmfelF8QgnTb3 jRYIt5z+Kye8oXZ0uTVY86YR7YbuiaHAJx1YZzceyfaVjJzvS8ZsTFt2CXshcex8 33fw3iQnY9ImA/NC11y4OLt8F8nb+Ge2Cge98wBt8NPSoBc= =SAIu -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa517.patch" Content-Disposition: attachment; filename="xsa517.patch" Content-Transfer-Encoding: base64 RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0OiBnbnR0YWI6IGFk ZHJlc3MgZmFsbG91dCBmcm9tIFhTQS01MDEKCkEgdjEgLT4gdjIgY2hhbmdlIGlzbid0IHRoZSBv bmx5IHNjZW5hcmlvIHdoZXJlICJzdGF0dXMiIG1heSBnbyBzdGFsZSBpbgptYXBfZ3JhbnRfcmVm KCkuIEFjcm9zcyBhIHYyIC0+IHYxIC0+IHYyIGNoYW5nZSB0aGUgc3RhdHVzIHBhZ2VzIHdvdWxk CmhhdmUgYmVlbiBmcmVlZCBhbmQgcmUtcG9wdWxhdGVkLCBwb3NzaWJseSBjaGFuZ2luZyB0aGUg cGFnZXMgdXNlZCBmb3IgdGhlCmFycmF5LiBDaGVjayB0aGUgcG9pbnRlciBhZ2FpbnN0IHRoZSBl eHBlY3RlZCB2ZXJzaW9uLWRlcGVuZGVudCB2YWx1ZS4KClRoaXMgaXMgWFNBLTUxNyAvIENWRS0y MDI2LTc5NjEwLgoKRml4ZXM6IDk2ZGZlYjQxNzc0YSAoImdudHRhYjogY29wZSB3aXRoIHZlcnNp b24gY2hhbmdlcyByYWNpbmcgb3RoZXIgb3BlcmF0aW9ucyIpCkFzc2lzdGVkLWJ5OiBDbGF1ZGUK UmVwb3J0ZWQtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPgpTaWduZWQt b2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJldmlld2VkLWJ5OiBUZWRk eSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4KLS0tCnYyOiBBZGQgcGFyZW50aGVzZXMg YXJvdW5kIHRoZSB8fCBleHByZXNzaW9uLgoKLS0tIGEveGVuL2NvbW1vbi9ncmFudF90YWJsZS5j CisrKyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwpAQCAtMTM1MCwxMyArMTM1MCwxOSBAQCBt YXBfZ3JhbnRfcmVmKAogCiAgICAgZ3JhbnRfcmVhZF9sb2NrKHJndCk7CiAKLSAgICBpZiAoIHVu bGlrZWx5KGV2YWx1YXRlX25vc3BlYygocmd0LT5ndF92ZXJzaW9uID09IDEpICE9Ci0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0YXR1cyA9PSAmc2hhaC0+ZmxhZ3MpKSkgKQor ICAgIC8qCisgICAgICogQWZ0ZXIgYSB2MSAtPiB2MiBjaGFuZ2UgYmVoaW5kIG91ciBiYWNrcyAi cmVmIiBtYXkgbm93IGJlIG91dCBvZgorICAgICAqIGJvdW5kcy4gIFdoaWxlIGFmdGVyIGEgdjIg LT4gdjEgLT4gdjIgY2hhbmdlICJyZWYiIHdvdWxkIHN0aWxsIGJlCisgICAgICogc3VpdGFibHkg Ym91bmRlZCwgdGhlIHVuZGVybHlpbmcgc3RhdHVzIHBhZ2UgbWF5IGhhdmUgbW92ZWQuCisgICAg ICovCisgICAgaWYgKCBldmFsdWF0ZV9ub3NwZWMocmd0LT5ndF92ZXJzaW9uID09IDEKKyAgICAg ICAgICAgICAgICAgICAgICAgICA/IHN0YXR1cyAhPSAmc2hhaC0+ZmxhZ3MKKyAgICAgICAgICAg ICAgICAgICAgICAgICA6IChyZWYgPj0gbnJfZ3JhbnRfZW50cmllcyhyZ3QpIHx8CisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3RhdHVzICE9ICZzdGF0dXNfZW50cnkocmd0LCByZWYpKSkg KQogICAgIHsKICAgICAgICAgLyoKLSAgICAgICAgICogQWZ0ZXIgYSB2MSAtPiB2MiBjaGFuZ2Ug YmVoaW5kIG91ciBiYWNrcyAicmVmIiBtYXkgbm93IGJlIG91dCBvZgotICAgICAgICAgKiBib3Vu ZHMuICBSZWNhbGN1bGF0ZSBpdCwgYnV0IG9ubHkgZm9yIHJlc2VydmVkIGVudHJpZXMuICBPdGhl cnMKLSAgICAgICAgICogd2lsbCBoYXZlIGJlZW4gY2xlYXJlZCBhbnl3YXkgYnkgdGhlIHZlcnNp b24gY2hhbmdlLgorICAgICAgICAgKiBSZWNhbGN1bGF0ZSBzdGF0dXMsIGJ1dCBvbmx5IGZvciBy ZXNlcnZlZCBlbnRyaWVzLiAgT3RoZXJzIHdpbGwKKyAgICAgICAgICogaGF2ZSBiZWVuIGNsZWFy ZWQgYW55d2F5IGJ5IHRoZSB2ZXJzaW9uIGNoYW5nZShzKS4KICAgICAgICAgICovCiAgICAgICAg IGlmICggcmVmIDwgR05UVEFCX05SX1JFU0VSVkVEX0VOVFJJRVMgKQogICAgICAgICAgICAgc3Rh dHVzID0gZXZhbHVhdGVfbm9zcGVjKHJndC0+Z3RfdmVyc2lvbiA9PSAxKQo= --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:29:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:29:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447132.1663426 (Exim 4.92) (envelope-from ) id 1xGbcq-0000jO-LM; Tue, 13 Oct 2026 12:29:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447132.1663426; Tue, 13 Oct 2026 12:29: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 1xGbcp-0000h9-W6; Tue, 13 Oct 2026 12:29:00 +0000 Received: by outflank-mailman (input) for mailman id 1447132; Tue, 13 Oct 2026 12:28:58 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbcm-0008PB-KU; Tue, 13 Oct 2026 12:28:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbcl-00DIPB-Vs; Tue, 13 Oct 2026 14:28:55 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace2403-2eae-0a2a0a5409dd-0a2a4501ece6-14 for ; Tue, 13 Oct 2026 14:28:55 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace2406-5984-0a2a45010019-6882d7259974-3 for ; Tue, 13 Oct 2026 14:28:55 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbci-00000003NHh-2Uhh; Tue, 13 Oct 2026 12:28:52 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbci-0000000F8xP-1Sbi; Tue, 13 Oct 2026 12:28: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; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 518 v2 (CVE-2026-79611) - VMX: VMentry failure with branch tracing and blocked states Message-Id: Date: Tue, 13 Oct 2026 12:28:52 +0000 X-purgate-ID: tlsNG-d62444/1791894535-1E664757-CCC5F802/0/0 X-purgate-type: clean X-purgate-size: 13424 --=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-79611 / XSA-518 version 2 VMX: VMentry failure with branch tracing and blocked states UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= For XSA-308 logic was introduced, as VMX VMEntry checks do not like the exact combination of state which occurs when #DB in intercepted, Single Stepping is active, and blocked by STI/MovSS is active, despite this being a legitimate state to be in. The resulting VMEntry failure is fatal to the guest. Sadly there is another special sub-case of the above, with branch tracing enabled. In that case the prior adjustment would still cause a VMentry failure, as before fatal to the guest. IMPACT ====== HVM/PVH guest userspace code may be able to crash the guest, resulting in a guest Denial of Service. VULNERABLE SYSTEMS ================== All versions of Xen are affected. Only systems supporting VMX hardware virtual extensions (Intel, VIA or Zhaoxin CPUs) are affected. Arm as well as AMD and Hygon systems are unaffected. Only HVM/PVH guests are affected. PV guests cannot leverage the vulnerability. MITIGATION ========== Running only PV guests will avoid this vulnerability. Running HVM guests on only AMD or Hygon hardware will also avoid this vulnerability. CREDITS ======= This issue was discovered by Claude Opus and diagnosed as a security issue by Teddy Astie of Vates. 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. xsa518.patch xen-unstable - Xen 4.21.x xsa518-4.20.patch Xen 4.20.x - Xen 4.17.x $ sha256sum xsa518* a703af59b22f1e47543af0668c8715b4e4011ba4fc05fd8b94bf05503dce88ef xsa518.patch a1a1b3548166e051f62a0759af5df8d365f524ae52f4bbbe642d45692a1f8bde xsa518-4.20.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. -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIooMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZTOUIAMMapd/RMFzQxmwdwICbmj2zDnEWutkzQyV0bMMK Ui2VleXQ7pDWH5OEfDNl6644Gs6x4zB9lrTZFubAFvXjqNUk9C3QxU6LOlV0RQAq a96/glbPhXhOONdn1K5DuJq35sKjhGdsy8B+Ati+IGPstT8bGytrz+CVbdR1bnLb 3XvnRHqFSEHoQxejE/aRXpRw4k1HHD5wFQ/WfvgOEKYj+Ghjm+KE2sNhcahxxFf4 ys8v9JWBKhnLAe+mJIiMPGiKmX5uUVl6HhdX6SjTHuzzbsmITF3VOwsnHZR9vLn1 BqUwLG/uQKes4LRinfOA5RrOMt/q/ChjXPw2x6IZZJLjHVk= =hyph -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa518.patch" Content-Disposition: attachment; filename="xsa518.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KU3ViamVjdDog eDg2L3ZteDogUmV3b3JrICNEQiBpbnRlcmNlcHQgbG9naWMgdG8gZml4IFZNRW50cnkgZmFpbHVy ZSB3aXRoIEJURgoKVGhlIGNvbnNpc3RlbmN5IGNoZWNrcyBpbiBlZmZlY3Qgd2hlbiBCbG9ja2Vk LWJ5LVNUSS9Nb3ZTUyBhcmUgYWN0aXZlIGluY2x1ZGVzCkRFQlVHQ1RMLkJURiB0b28uICBUYWtl IHRoaXMgaW50byBhY2NvdW50IHdoZW4gZWRpdGluZyBQRU5ESU5HX0RCRy5CUy4KClRoaXMgZW5k cyB1cCBuYXJyb3dpbmcgdGhlIGNhc2VzIHdoZXJlIFBFTkRJTkdfREJHIGlzIG1vZGlmaWVkLiAg UmV3b3JrIHRoZQpjb21tZW50IHRvIGJlIG1vcmUgcHJlY2lzZS4KClRoaXMgaXMgWFNBLTUxOCAv IENWRS0yMDI2LTc5NjExLgoKRml4ZXM6IDFkM2ViODI1OTgwNCAoIng4Ni92dHg6IFdvcmsgYXJv dW5kIFNpbmdsZVN0ZXAgKyBTVEkvTW92U1MgVk1FbnRyeSBmYWlsdXJlcyIpClJlcG9ydGVkLWJ5 OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4KU2lnbmVkLW9mZi1ieTogQW5k cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRlZGR5IEFzdGllIDx0ZWRk eS5hc3RpZUB2YXRlcy50ZWNoPgotLS0KIHhlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jIHwgNDEg KysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAx OCBpbnNlcnRpb25zKCspLCAyMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94 ODYvaHZtL3ZteC92bXguYyBiL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jCmluZGV4IDYyMzc2 MjNhNGMxNi4uOTdkZDM3ZGQ3Y2U0IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC92 bXguYworKysgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYwpAQCAtNDM5NiwzMyArNDM5Niwy OCBAQCB2b2lkIGFzbWxpbmthZ2Ugdm14X3ZtZXhpdF9oYW5kbGVyKHN0cnVjdCBjcHVfdXNlcl9y ZWdzICpyZWdzKQogICAgICAgICAgICAgICogV2UgaW50ZXJjZXB0ICNEQiB1bmNvbmRpdGlvbmFs bHkgdG8gd29yayBhcm91bmQgQ1ZFLTIwMTUtODEwNCAvCiAgICAgICAgICAgICAgKiBYU0EtMTU2 IChndWVzdC1rZXJuZWwgaW5kdWNlZCBob3N0IERvUykuCiAgICAgICAgICAgICAgKgotICAgICAg ICAgICAgICogU1RJL01vdlNTIHNoYWRvd3MgYmxvY2svZGVmZXIgaW50ZXJydXB0cy9leGNlcHRp b25zIChleGFjdAotICAgICAgICAgICAgICogZGV0YWlscyBhcmUgY29tcGxpY2F0ZWQgYW5kIHBv b3JseSBkb2N1bWVudGVkKS4gIERlYnVnCi0gICAgICAgICAgICAgKiBleGNlcHRpb25zIGRlbGF5 ZWQgZm9yIGFueSByZWFzb24gYXJlIHN0b3JlZCBpbiB0aGUKLSAgICAgICAgICAgICAqIFBFTkRJ TkdfREJHX0VYQ0VQVElPTlMgZmllbGQuCisgICAgICAgICAgICAgKiBNb3N0IHNvdXJjZXMgb2Yg I0RCIGFjY3VtdWF0ZSBzdGF0dXMgaW4gUEVORElOR19EQkcsIHdoaWNoIGFyZQorICAgICAgICAg ICAgICogdGhlbiBkaXNwYXRjaGVkIGluIHByaW9yaXR5IG9yZGVyIHByaW9yIHRvIGZldGNoaW5n IHRoZSBuZXh0CisgICAgICAgICAgICAgKiBpbnN0cnVjdGlvbi4gIFdoZW4gdGhlICNEQiBpbnRl cmNlcHQgdHJpZ2dlcnMsIFBFTkRJTkdfREJHIGlzIDAKKyAgICAgICAgICAgICAqIHdpdGggdGhl IHN0YXR1cyBiaXRzIGhhdmluZyBtb3ZlZCBpbnRvIEVYSVRfUVVBTElGSUNBVElPTi4KICAgICAg ICAgICAgICAqCi0gICAgICAgICAgICAgKiBUaGUgZmFsbGluZyBlZGdlIG9mIFBFTkRJTkdfREJH IGNhdXNlcyAjREIgdG8gYmUgZGVsaXZlcmVkLAotICAgICAgICAgICAgICogcmVzdWx0aW5nIGlu IGEgVk1FeGl0LCBhcyAjREIgaXMgaW50ZXJjZXB0ZWQuICBUaGUgVk1DUyBzdGlsbAotICAgICAg ICAgICAgICogcmVwb3J0cyBibG9ja2VkLWJ5LVNUSS9Nb3ZTUy4KKyAgICAgICAgICAgICAqIEF0 IGFueSBwb2ludCBpZiBCbG9ja2VkLWJ5LVNUSS9Nb3ZTUyBhcmUgYWN0aXZlLCBleHRyYSBWTUVu dHJ5CisgICAgICAgICAgICAgKiBjb25zaXN0ZW5jeSBjaGVja3MgYXJlIGFwcGxpZWQsIGNyb3Nz LWNoZWNraW5nIEVGTEFHUy5URiwKKyAgICAgICAgICAgICAqIFBFTkRJTkdfREJHLkJTIGFuZCBE RUJVR0NUTC5CVEYuICBUaGVzZSBjb25zaXN0ZW5jeSBjaGVja3MKKyAgICAgICAgICAgICAqIGFw cGx5IHRvIEFjdGl2aXR5LXN0YXRlLUhMVCB0b28sIGJ1dCBYZW4gZG9lc24ndCBzdXBwb3J0IHRo aXMuCiAgICAgICAgICAgICAgKgotICAgICAgICAgICAgICogVGhlIFZNRW50cnkgY2hlY2tzIHdo ZW4gRUZMQUdTLlRGIGlzIHNldCBkb24ndCBsaWtlIGEgVk1DUyBpbgotICAgICAgICAgICAgICog dGhpcyBzdGF0ZS4gIERlc3BpdGUgYSAjREIgcXVldWVkIGluIFZNRU5UUllfSU5UUl9JTkZPLCB0 aGUKLSAgICAgICAgICAgICAqIHN0YXRlIGlzIHJlamVjdGVkIGFzIERSNi5CUyBpc24ndCBwZW5k aW5nLiAgRml4IHRoaXMgdXAuCisgICAgICAgICAgICAgKiBUaGUgVk1DUyBzdGF0ZSBhdCB0aGUg cG9pbnQgb2YgI0RCIGludGVyY2VwdCBkb2VzIG5vdCBzYXRpc2Z5CisgICAgICAgICAgICAgKiB0 aGUgY29uc2lzdGVuY3kgY2hlY2tzLiAgSW4gdGhlIGNhc2UgdGhhdCBhIFNpbmdsZVN0ZXAgc2hv dWxkCisgICAgICAgICAgICAgKiBiZSBwZW5kaW5nLCBmaWxsIFBFTkRJTkdfREJHIGJhY2sgaW4g dG8gc2F0aXNmeSB0aGUgY29uc2l0ZW5jeQorICAgICAgICAgICAgICogY2hlY2suCiAgICAgICAg ICAgICAgKi8KLSAgICAgICAgICAgIGlmICggdW5saWtlbHkocmVncy0+ZWZsYWdzICYgWDg2X0VG TEFHU19URikgKQorICAgICAgICAgICAgaWYgKCB1bmxpa2VseShyZWdzLT5lZmxhZ3MgJiBYODZf RUZMQUdTX1RGKSAmJgorICAgICAgICAgICAgICAgICAodm1yZWFkKEdVRVNUX0lOVEVSUlVQVElC SUxJVFlfSU5GTykgJgorICAgICAgICAgICAgICAgICAgKFZNWF9JTlRSX1NIQURPV19TVEkgfCBW TVhfSU5UUl9TSEFET1dfTU9WX1NTKSkgJiYKKyAgICAgICAgICAgICAgICAgISh2bXJlYWQoR1VF U1RfSUEzMl9ERUJVR0NUTCkgJiBJQTMyX0RFQlVHQ1RMTVNSX0JURikgKQogICAgICAgICAgICAg ewotICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgaW50X2luZm87Ci0KLSAgICAgICAgICAg ICAgICBfX3ZtcmVhZChHVUVTVF9JTlRFUlJVUFRJQklMSVRZX0lORk8sICZpbnRfaW5mbyk7Ci0K LSAgICAgICAgICAgICAgICBpZiAoIGludF9pbmZvICYgKFZNWF9JTlRSX1NIQURPV19TVEkgfCBW TVhfSU5UUl9TSEFET1dfTU9WX1NTKSApCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAg ICAgICAgICB1bnNpZ25lZCBsb25nIHBlbmRpbmdfZGJnOwotCi0gICAgICAgICAgICAgICAgICAg IF9fdm1yZWFkKEdVRVNUX1BFTkRJTkdfREJHX0VYQ0VQVElPTlMsICZwZW5kaW5nX2RiZyk7Ci0g ICAgICAgICAgICAgICAgICAgIF9fdm13cml0ZShHVUVTVF9QRU5ESU5HX0RCR19FWENFUFRJT05T LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVuZGluZ19kYmcgfCBEUl9TVEVQKTsK LSAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgQVNTRVJUKHZtcmVhZChHVUVTVF9Q RU5ESU5HX0RCR19FWENFUFRJT05TKSA9PSAwKTsKKyAgICAgICAgICAgICAgICBfX3Ztd3JpdGUo R1VFU1RfUEVORElOR19EQkdfRVhDRVBUSU9OUywgWDg2X0RSNl9CUyk7CiAgICAgICAgICAgICB9 CiAKICAgICAgICAgICAgIGlmICggIXYtPmRvbWFpbi0+ZGVidWdnZXJfYXR0YWNoZWQgKQo= --=separator Content-Type: application/octet-stream; name="xsa518-4.20.patch" Content-Disposition: attachment; filename="xsa518-4.20.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KU3ViamVjdDog eDg2L3ZteDogUmV3b3JrICNEQiBpbnRlcmNlcHQgbG9naWMgdG8gZml4IFZNRW50cnkgZmFpbHVy ZSB3aXRoIEJURgoKVGhlIGNvbnNpc3RlbmN5IGNoZWNrcyBpbiBlZmZlY3Qgd2hlbiBCbG9ja2Vk LWJ5LVNUSS9Nb3ZTUyBhcmUgYWN0aXZlIGluY2x1ZGVzCkRFQlVHQ1RMLkJURiB0b28uICBUYWtl IHRoaXMgaW50byBhY2NvdW50IHdoZW4gZWRpdGluZyBQRU5ESU5HX0RCRy5CUy4KClRoaXMgZW5k cyB1cCBuYXJyb3dpbmcgdGhlIGNhc2VzIHdoZXJlIFBFTkRJTkdfREJHIGlzIG1vZGlmaWVkLiAg UmV3b3JrIHRoZQpjb21tZW50IHRvIGJlIG1vcmUgcHJlY2lzZS4KClRoaXMgaXMgWFNBLTUxOCAv IENWRS0yMDI2LTc5NjExLgoKRml4ZXM6IDFkM2ViODI1OTgwNCAoIng4Ni92dHg6IFdvcmsgYXJv dW5kIFNpbmdsZVN0ZXAgKyBTVEkvTW92U1MgVk1FbnRyeSBmYWlsdXJlcyIpClJlcG9ydGVkLWJ5 OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4KU2lnbmVkLW9mZi1ieTogQW5k cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IFRlZGR5IEFzdGllIDx0ZWRk eS5hc3RpZUB2YXRlcy50ZWNoPgoKLS0tIGEveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMKKysr IGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMKQEAgLTQyODEsMjYgKzQyODEsMzAgQEAgdm9p ZCBhc21saW5rYWdlIHZteF92bWV4aXRfaGFuZGxlcihzdHJ1YwogICAgICAgICAgICAgICogV2Ug aW50ZXJjZXB0ICNEQiB1bmNvbmRpdGlvbmFsbHkgdG8gd29yayBhcm91bmQgQ1ZFLTIwMTUtODEw NCAvCiAgICAgICAgICAgICAgKiBYU0EtMTU2IChndWVzdC1rZXJuZWwgaW5kdWNlZCBob3N0IERv UykuCiAgICAgICAgICAgICAgKgotICAgICAgICAgICAgICogU1RJL01vdlNTIHNoYWRvd3MgYmxv Y2svZGVmZXIgaW50ZXJydXB0cy9leGNlcHRpb25zIChleGFjdAotICAgICAgICAgICAgICogZGV0 YWlscyBhcmUgY29tcGxpY2F0ZWQgYW5kIHBvb3JseSBkb2N1bWVudGVkKS4gIERlYnVnCi0gICAg ICAgICAgICAgKiBleGNlcHRpb25zIGRlbGF5ZWQgZm9yIGFueSByZWFzb24gYXJlIHN0b3JlZCBp biB0aGUKLSAgICAgICAgICAgICAqIFBFTkRJTkdfREJHX0VYQ0VQVElPTlMgZmllbGQuCisgICAg ICAgICAgICAgKiBNb3N0IHNvdXJjZXMgb2YgI0RCIGFjY3VtdWF0ZSBzdGF0dXMgaW4gUEVORElO R19EQkcsIHdoaWNoIGFyZQorICAgICAgICAgICAgICogdGhlbiBkaXNwYXRjaGVkIGluIHByaW9y aXR5IG9yZGVyIHByaW9yIHRvIGZldGNoaW5nIHRoZSBuZXh0CisgICAgICAgICAgICAgKiBpbnN0 cnVjdGlvbi4gIFdoZW4gdGhlICNEQiBpbnRlcmNlcHQgdHJpZ2dlcnMsIFBFTkRJTkdfREJHIGlz IDAKKyAgICAgICAgICAgICAqIHdpdGggdGhlIHN0YXR1cyBiaXRzIGhhdmluZyBtb3ZlZCBpbnRv IEVYSVRfUVVBTElGSUNBVElPTi4KICAgICAgICAgICAgICAqCi0gICAgICAgICAgICAgKiBUaGUg ZmFsbGluZyBlZGdlIG9mIFBFTkRJTkdfREJHIGNhdXNlcyAjREIgdG8gYmUgZGVsaXZlcmVkLAot ICAgICAgICAgICAgICogcmVzdWx0aW5nIGluIGEgVk1FeGl0LCBhcyAjREIgaXMgaW50ZXJjZXB0 ZWQuICBUaGUgVk1DUyBzdGlsbAotICAgICAgICAgICAgICogcmVwb3J0cyBibG9ja2VkLWJ5LVNU SS9Nb3ZTUy4KKyAgICAgICAgICAgICAqIEF0IGFueSBwb2ludCBpZiBCbG9ja2VkLWJ5LVNUSS9N b3ZTUyBhcmUgYWN0aXZlLCBleHRyYSBWTUVudHJ5CisgICAgICAgICAgICAgKiBjb25zaXN0ZW5j eSBjaGVja3MgYXJlIGFwcGxpZWQsIGNyb3NzLWNoZWNraW5nIEVGTEFHUy5URiwKKyAgICAgICAg ICAgICAqIFBFTkRJTkdfREJHLkJTIGFuZCBERUJVR0NUTC5CVEYuICBUaGVzZSBjb25zaXN0ZW5j eSBjaGVja3MKKyAgICAgICAgICAgICAqIGFwcGx5IHRvIEFjdGl2aXR5LXN0YXRlLUhMVCB0b28s IGJ1dCBYZW4gZG9lc24ndCBzdXBwb3J0IHRoaXMuCiAgICAgICAgICAgICAgKgotICAgICAgICAg ICAgICogVGhlIFZNRW50cnkgY2hlY2tzIHdoZW4gRUZMQUdTLlRGIGlzIHNldCBkb24ndCBsaWtl IGEgVk1DUyBpbgotICAgICAgICAgICAgICogdGhpcyBzdGF0ZS4gIERlc3BpdGUgYSAjREIgcXVl dWVkIGluIFZNRU5UUllfSU5UUl9JTkZPLCB0aGUKLSAgICAgICAgICAgICAqIHN0YXRlIGlzIHJl amVjdGVkIGFzIERSNi5CUyBpc24ndCBwZW5kaW5nLiAgRml4IHRoaXMgdXAuCisgICAgICAgICAg ICAgKiBUaGUgVk1DUyBzdGF0ZSBhdCB0aGUgcG9pbnQgb2YgI0RCIGludGVyY2VwdCBkb2VzIG5v dCBzYXRpc2Z5CisgICAgICAgICAgICAgKiB0aGUgY29uc2lzdGVuY3kgY2hlY2tzLiAgSW4gdGhl IGNhc2UgdGhhdCBhIFNpbmdsZVN0ZXAgc2hvdWxkCisgICAgICAgICAgICAgKiBiZSBwZW5kaW5n LCBmaWxsIFBFTkRJTkdfREJHIGJhY2sgaW4gdG8gc2F0aXNmeSB0aGUgY29uc2l0ZW5jeQorICAg ICAgICAgICAgICogY2hlY2suCiAgICAgICAgICAgICAgKi8KICAgICAgICAgICAgIGlmICggdW5s aWtlbHkocmVncy0+ZWZsYWdzICYgWDg2X0VGTEFHU19URikgKQogICAgICAgICAgICAgewotICAg ICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgaW50X2luZm87CisgICAgICAgICAgICAgICAgdW5z aWduZWQgbG9uZyBpbnRfaW5mbywgZGVidWdjdGw7CiAKICAgICAgICAgICAgICAgICBfX3ZtcmVh ZChHVUVTVF9JTlRFUlJVUFRJQklMSVRZX0lORk8sICZpbnRfaW5mbyk7CisgICAgICAgICAgICAg ICAgX192bXJlYWQoR1VFU1RfSUEzMl9ERUJVR0NUTCwgJmRlYnVnY3RsKTsKIAotICAgICAgICAg ICAgICAgIGlmICggaW50X2luZm8gJiAoVk1YX0lOVFJfU0hBRE9XX1NUSSB8IFZNWF9JTlRSX1NI QURPV19NT1ZfU1MpICkKKyAgICAgICAgICAgICAgICBpZiAoIChpbnRfaW5mbyAmIChWTVhfSU5U Ul9TSEFET1dfU1RJIHwgVk1YX0lOVFJfU0hBRE9XX01PVl9TUykpICYmCisgICAgICAgICAgICAg ICAgICAgICAhKGRlYnVnY3RsICYgSUEzMl9ERUJVR0NUTE1TUl9CVEYpICkKICAgICAgICAgICAg ICAgICB7CiAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgcGVuZGluZ19kYmc7CiAK --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:29:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:29:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447150.1663462 (Exim 4.92) (envelope-from ) id 1xGbd0-0002Ju-EH; Tue, 13 Oct 2026 12:29:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447150.1663462; Tue, 13 Oct 2026 12:29: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 1xGbcz-0002GG-8r; Tue, 13 Oct 2026 12:29:09 +0000 Received: by outflank-mailman (input) for mailman id 1447150; Tue, 13 Oct 2026 12:29:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbcq-0000nW-RN; Tue, 13 Oct 2026 12:29:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbcq-00DITf-6H; Tue, 13 Oct 2026 14:29:00 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace2403-e002-0a2a0a5209dd-0a2a45068954-36 for ; Tue, 13 Oct 2026 14:29:00 +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 6ace240a-195a-0a2a45060019-6882d725cdac-3 for ; Tue, 13 Oct 2026 14:28:59 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbcm-00000003NI2-19nM; Tue, 13 Oct 2026 12:28:56 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbcm-0000000F959-03cI; Tue, 13 Oct 2026 12:28: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; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 519 v2 (CVE-2026-102699,CVE-2026-102702) - Arm: multiple issues with GNTTABOP_cache_flush Message-Id: Date: Tue, 13 Oct 2026 12:28:56 +0000 X-purgate-ID: tlsNG-16d1c6/1791894540-FE27077B-ECA0CA4B/0/0 X-purgate-type: clean X-purgate-size: 25558 --=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-102699,CVE-2026-102702 / XSA-519 version 2 Arm: multiple issues with GNTTABOP_cache_flush UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= 1) XSA-437 (CVE-2023-34321) addressed issues with overflows in calculations involved in guests flushing caches through GNTTABOP_cache_flush. Unfortunately the fix there introduced a calculation which may underflow, resulting in a loop which would - at least on 64-bit Arm - take excessively long, and which would likely eventually crash the hypervisor. This is CVE-2026-102699. 2) GNTTABOP_cache_flush may be issued on memory mapped from another domain using the grant table interface. However there was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory. This is CVE-2026-102702. IMPACT ====== A malicious unprivileged guest may crash the hypervisor, causing a Denial of Service (DoS) affecting the entire host, or corrupt memory belonging to another domain. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable. Only Arm systems are vulnerable. x86 systems are not vulnerable. MITIGATION ========== There is no known mitigation. CREDITS ======= CVE-2026-102699 was discovered by Leonid Komarianskyi of EPAM. It was later independently reported by Ayan Kumar Halder of AMD. CVE-2026-102702 was found by the security team while looking at the surrounding code. 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. xsa519-?.patch xen-unstable - Xen 4.21.x xsa519-4.20-?.patch Xen 4.20.x - Xen 4.17.x $ sha256sum xsa519* 3abfe7776402ba82d54b72163427694055cc3a5a729fd50a15af58699fef7903 xsa519-1.patch 6f09a24c5c793570e290ec853220099c617e372d96b93f938439ac4a18191dd2 xsa519-2.patch 1ed852f7e22fafe75e278dc913377fda5b0b73c8af51fe872684eb5b0bcb9597 xsa519-4.20-1.patch df5ba864761f3274df817fa362e234afb4b5e3f95b47daf25a307ac3d922aab6 xsa519-4.20-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/4UyVfoK9kFAmrOIrAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ9ccIALBHbUY7GDoW1oFxKSpvrFFzwdSeq+yR7Y+cnBy7 6j9ehJE2zC1qLqHy0MQjFcmdSvdm/1Qy4CZ+cZgKtOMCeOvV8OwA6QkuHV5fch0f 2wHq71u/9p7wWhsILb9EHaUHBFNXiQ+joahKPyX4FHwz2aCB+aodqCRMsvk0Kd7K PSX4FotvGHSfgxrdzP6oLPOrmvVwy91ienOabE7QMTW2anghDIFVfjycYuebfXxF S+d7ciAcHdd72fOhM/wVlXZohslxw14ESJYZMUOvha8godQjPwCtT/A/SDc/k0Et 98xImFp4NU9W4Pk42eS+JUs3KNLWFapzVePRQ0Ku80Ia6wg= =xgyt -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa519-1.patch" Content-Disposition: attachment; filename="xsa519-1.patch" Content-Transfer-Encoding: base64 RnJvbTogTGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4K U3ViamVjdDogeGVuL2FybTogRml4IHNpemUgdW5kZXJmbG93IGluIGludmFsaWRhdGVfZGNhY2hl X3ZhX3JhbmdlKCkKCldoZW4gdGhlIHN0YXJ0IGFkZHJlc3MgaXMgbm90IGNhY2hlbGluZSBhbGln bmVkLCB0aGUgYnl0ZXMgY292ZXJlZCBieQp0aGUgZmlyc3QsIHBhcnRpYWwgY2FjaGVsaW5lIGFy ZSBzdWJ0cmFjdGVkIGZyb20gJ3NpemUnLiBOb3RoaW5nIGNoZWNrcwp0aGF0IHRoZSByZWdpb24g YWN0dWFsbHkgZXh0ZW5kcyBiZXlvbmQgdGhhdCBjYWNoZWxpbmUsIHNvIGlmIGl0IGRvZXMKbm90 LCB0aGUgdW5zaWduZWQgc3VidHJhY3Rpb24gdW5kZXJmbG93cyBhbmQgdGhlIGxvb3AgdGhhdCBm b2xsb3dzIHdhbGtzCnByYWN0aWNhbGx5IHRoZSBlbnRpcmUgYWRkcmVzcyBzcGFjZS4KCkZvciBl eGFtcGxlLCB3aXRoIGEgNjQtYnl0ZSBjYWNoZWxpbmUsIHAgPSAweDQwMDAwMDAxIGFuZCBzaXpl ID0gMToKCiAgICBwICYgY2FjaGVsaW5lX21hc2sgICAgIC0+IDEsIHNvIHRoZSBwYXJ0aWFsIGhl YWQgaXMgdGFrZW4KICAgIHNpemUgLT0gNjQgLSAxICAgICAgICAgLT4gMSAtIDYzIHVuZGVyZmxv d3MgdG8gMHhmZmZmZmZmZmZmZmZmZmMyCgpJbnN0ZWFkIG9mIGEgc2luZ2xlICJkYyBjaXZhYyIg YXQgMHg0MDAwMDAwMCwgdGhlIGxvb3AgdGhlbiBydW5zCjI4ODIzMDM3NjE1MTcxMTc0MyB0aW1l cywgaXNzdWluZyAiZGMgaXZhYyIgZnJvbSAweDQwMDAwMDQwIHVwd2FyZHMuCkludmFsaWRhdGlu ZyB3aXRob3V0IGNsZWFuaW5nIGRpc2NhcmRzIGRpcnR5IGNhY2hlbGluZXMsIHNvIHRoaXMKY29y cnVwdHMgd2hhdGV2ZXIgaXMgbWFwcGVkIGFsb25nIHRoZSB3YXkgdW50aWwgWGVuIHRha2VzIGEg ZGF0YSBhYm9ydC4KCk1vcmVvdmVyLCBfY2FjaGVfZmx1c2goKSBpbiBjb21tb24vZ3JhbnRfdGFi bGUuYywgcmVhY2hhYmxlIGZyb20gYSBndWVzdAp2aWEgR05UVEFCT1BfY2FjaGVfZmx1c2gsIGJv dW5kcyAnb2Zmc2V0JyBhbmQgJ2xlbmd0aCcgYWdhaW5zdCB0aGUgcGFnZQpzaXplIGJ1dCByZXF1 aXJlcyBubyBhbGlnbm1lbnQsIHNvIEdOVFRBQl9DQUNIRV9JTlZBTCB3aXRoIG9mZnNldCA9IDEK YW5kIGxlbmd0aCA9IDEgaXMgZW5vdWdoIHRvIHRyaWdnZXIgdGhpcy4gTm90ZSB0aGF0IHRoZSBw YWdlIG1heSBiZWxvbmcKdG8gYSBkaWZmZXJlbnQgZG9tYWluICh0aGUgZCAhPSBvd25lciBwYXRo KSwgc28gdGhlIGRhdGEgYmVpbmcgZGlzY2FyZGVkCmlzIG5vdCBuZWNlc3NhcmlseSB0aGUgY2Fs bGVyJ3Mgb3duLgoKVGhlIHN1YnRyYWN0aW9uIGRhdGVzIGJhY2sgdG8gdGhlIGZpeCBmb3IgWFNB LTQzNywgc28gdGhpcyBpcyBhIHJlZ3Jlc3Npb24KaW4gdGhhdCBjaGFuZ2UuCgpGaXggdGhpcyBi eSBkZXRlY3RpbmcgdGhlIHVuZGVyZmxvdyBpbnN0ZWFkIG9mIGxldHRpbmcgaXQgaGFwcGVuOiBp ZiB0aGUKcmVnaW9uIGVuZHMgaW5zaWRlIHRoZSBmaXJzdCBjYWNoZWxpbmUsIHRoZXJlIGlzIG5v dGhpbmcgbGVmdCB0byBmbHVzaAphbmQgdGhlIGZ1bmN0aW9uIGJhaWxzIG91dCByaWdodCBhZnRl ciBjbGVhbmluZyBpdC4gUGFydGlhbGx5IGNvdmVyZWQKY2FjaGVsaW5lcyBhcmUgc3RpbGwgY2xl YW5lZCBhcyB3ZWxsIGFzIGludmFsaWRhdGVkLCBzbyB0aGF0IGRhdGEgb3V0c2lkZQpvZiB0aGUg cmVnaW9uIGlzIG5vdCBkaXNjYXJkZWQuCgpBZGRpdGlvbmFsbHksIGRyb3AgJ2lkeCcgYW5kIGFk dmFuY2UgJ3AnIGRpcmVjdGx5IGluc3RlYWQuIEl0IHNpbXBsaWZpZXMKdGhlIGxvZ2ljIHdoaWxl IHVzaW5nIGZld2VyIHZhcmlhYmxlcyBhbmQgbGVzcyBhcml0aG1ldGljLgoKTm90ZSB0aGF0IHRo ZSBwYXJ0aWFsIGhlYWQgaXMgbm93IGNsZWFuZWQgdXNpbmcgdGhlIHVuYWxpZ25lZCBzdGFydCBv ZiB0aGUKcmVnaW9uIGluc3RlYWQgb2YgdGhlIHN0YXJ0IG9mIGl0cyBjYWNoZWxpbmUuIFRoaXMg aXMgcGVybWl0dGVkIGJ5IHRoZQphcmNoaXRlY3R1cmU7IHRoZSBBcm0gQVJNIChEREkgMDQ4Nykg c3RhdGVzOgoKICAiV2hlbiBhIERDIGluc3RydWN0aW9uIHJlcXVpcmVzIGFuIGFkZHJlc3MgYXJn dW1lbnQgdGhpcyB0YWtlcyB0aGUgZm9ybQogIG9mIGEgNjQtYml0IHJlZ2lzdGVyIHRoYXQgaG9s ZHMgdGhlIFZBIGFyZ3VtZW50LiBObyBhbGlnbm1lbnQKICByZXN0cmljdGlvbnMgYXBwbHkgZm9y IHRoaXMgYWRkcmVzcy4iCgpUaGUgc2FtZSBhcHBsaWVzIG9uIEFybTMyLgoKQWxzbywgc3dpdGNo IHRoZSBhc20oKSBpbiB0aGUgbG9vcCB0byBhc21faW5saW5lLCBsaWtlIHRoZSBuZWlnaGJvdXJp bmcKb25lczogdGhlIHdyYXBwZXIgZXhwYW5kcyB0byBhIHNpbmdsZSBpbnN0cnVjdGlvbiB3aXRo IGEgdHJhaWxpbmcKc2VtaWNvbG9uLCB3aGljaCBHQ0MgY291bnRzIGFzIHR3byBzdGF0ZW1lbnRz LCBvdmVyZXN0aW1hdGluZyB0aGUgc2l6ZQpvZiB0aGUgZnVuY3Rpb24gd2hlbiBkZWNpZGluZyB3 aGV0aGVyIHRvIGlubGluZSBpdC4KClRoaXMgaXMgQ1ZFLTIwMjYtMTAyNjk5LCBwYXJ0IG9mIFhT QS01MTkuCgpGaXhlczogOWEyMTZlOTJkZTlmICgieGVuL2FybTogcGFnZTogSGFuZGxlIGNhY2hl IGZsdXNoIG9mIGFuIGVsZW1lbnQgYXQgdGhlIHRvcCBvZiB0aGUgYWRkcmVzcyBzcGFjZSIpClNp Z25lZC1vZmYtYnk6IExlb25pZCBLb21hcmlhbnNreWkgPGxlb25pZF9rb21hcmlhbnNreWlAZXBh bS5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJldmll d2VkLWJ5OiBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3JnPgoKZGlmZiAtLWdpdCBhL3hlbi9h cmNoL2FybS9pbmNsdWRlL2FzbS9wYWdlLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vcGFn ZS5oCmluZGV4IDkwMTAwYTk2ZGZkYS4uNmRhNDc0NTczNmEyIDEwMDY0NAotLS0gYS94ZW4vYXJj aC9hcm0vaW5jbHVkZS9hc20vcGFnZS5oCisrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9w YWdlLmgKQEAgLTE2OCw3ICsxNjgsNyBAQCBzdGF0aWMgaW5saW5lIHNpemVfdCByZWFkX2RjYWNo ZV9saW5lX2J5dGVzKHZvaWQpCiBzdGF0aWMgaW5saW5lIGludCBpbnZhbGlkYXRlX2RjYWNoZV92 YV9yYW5nZShjb25zdCB2b2lkICpwLCB1bnNpZ25lZCBsb25nIHNpemUpCiB7CiAgICAgc2l6ZV90 IGNhY2hlbGluZV9tYXNrID0gZGNhY2hlX2xpbmVfYnl0ZXMgLSAxOwotICAgIHVuc2lnbmVkIGxv bmcgaWR4ID0gMDsKKyAgICB1bnNpZ25lZCBsb25nIHBhcnRpYWxfaGVhZDsKIAogICAgIGlmICgg IXNpemUgKQogICAgICAgICByZXR1cm4gMDsKQEAgLTE3OCwyMyArMTc4LDM1IEBAIHN0YXRpYyBp bmxpbmUgaW50IGludmFsaWRhdGVfZGNhY2hlX3ZhX3JhbmdlKGNvbnN0IHZvaWQgKnAsIHVuc2ln bmVkIGxvbmcgc2l6ZSkKIAogICAgIGRzYihzeSk7ICAgICAgICAgICAvKiBTbyB0aGUgQ1BVIGlz c3VlcyBhbGwgd3JpdGVzIHRvIHRoZSByYW5nZSAqLwogCi0gICAgaWYgKCAodWludHB0cl90KXAg JiBjYWNoZWxpbmVfbWFzayApCisgICAgLyoKKyAgICAgKiBBIGNhY2hlbGluZSBvbmx5IHBhcnRp YWxseSBjb3ZlcmVkIGJ5IHRoZSByZWdpb24gaGFzIHRvIGJlIGNsZWFuZWQgYXMKKyAgICAgKiB3 ZWxsIGFzIGludmFsaWRhdGVkLCBzbyB0aGF0IGRhdGEgbGl2aW5nIG91dHNpZGUgb2YgdGhlIHJl Z2lvbiBpcyBub3QKKyAgICAgKiBkaXNjYXJkZWQuCisgICAgICovCisgICAgcGFydGlhbF9oZWFk ID0gKHVpbnRwdHJfdClwICYgY2FjaGVsaW5lX21hc2s7CisgICAgaWYgKCBwYXJ0aWFsX2hlYWQg KQogICAgIHsKLSAgICAgICAgc2l6ZSAtPSBkY2FjaGVfbGluZV9ieXRlcyAtICgodWludHB0cl90 KXAgJiBjYWNoZWxpbmVfbWFzayk7Ci0gICAgICAgIHAgPSAodm9pZCAqKSgodWludHB0cl90KXAg JiB+Y2FjaGVsaW5lX21hc2spOworICAgICAgICB1bnNpZ25lZCBsb25nIHJlbSA9IGRjYWNoZV9s aW5lX2J5dGVzIC0gcGFydGlhbF9oZWFkOworCiAgICAgICAgIGFzbV9pbmxpbmUgdm9sYXRpbGUg KAogICAgICAgICAgICAgX19jbGVhbl9hbmRfaW52YWxpZGF0ZV9kY2FjaGVfb25lKDApIDo6ICJy IiAocCkgKTsKLSAgICAgICAgcCArPSBkY2FjaGVfbGluZV9ieXRlczsKKyAgICAgICAgcCArPSBy ZW07CisKKyAgICAgICAgLyogVGhlIHJlZ2lvbiBtYXkgZW5kIHdpdGhpbiB0aGlzIGNhY2hlbGlu ZSwgbGVhdmluZyBub3RoaW5nIHRvIGRvLiAqLworICAgICAgICBpZiAoIF9fYnVpbHRpbl91c3Vi bF9vdmVyZmxvdyhzaXplLCByZW0sICZzaXplKSApCisgICAgICAgICAgICBnb3RvIGRvbmU7CiAg ICAgfQogCiAgICAgZm9yICggOyBzaXplID49IGRjYWNoZV9saW5lX2J5dGVzOwotICAgICAgICAg ICAgaWR4ICs9IGRjYWNoZV9saW5lX2J5dGVzLCBzaXplIC09IGRjYWNoZV9saW5lX2J5dGVzICkK LSAgICAgICAgYXNtIHZvbGF0aWxlIChfX2ludmFsaWRhdGVfZGNhY2hlX29uZSgwKSA6IDogInIi IChwICsgaWR4KSk7CisgICAgICAgICAgICBwICs9IGRjYWNoZV9saW5lX2J5dGVzLCBzaXplIC09 IGRjYWNoZV9saW5lX2J5dGVzICkKKyAgICAgICAgYXNtX2lubGluZSB2b2xhdGlsZSAoX19pbnZh bGlkYXRlX2RjYWNoZV9vbmUoMCkgOiA6ICJyIiAocCkpOwogCisgICAgLyogUGFydGlhbCB0YWls IG11c3QgYmUgY2xlYW5lZCBhcyB3ZWxsLiAqLwogICAgIGlmICggc2l6ZSA+IDAgKQogICAgICAg ICBhc21faW5saW5lIHZvbGF0aWxlICgKLSAgICAgICAgICAgIF9fY2xlYW5fYW5kX2ludmFsaWRh dGVfZGNhY2hlX29uZSgwKSA6OiAiciIgKHAgKyBpZHgpICk7CisgICAgICAgICAgICBfX2NsZWFu X2FuZF9pbnZhbGlkYXRlX2RjYWNoZV9vbmUoMCkgOjogInIiIChwKSApOwogCisgZG9uZToKICAg ICBkc2Ioc3kpOyAgICAgICAgICAgLyogU28gd2Uga25vdyB0aGUgZmx1c2hlcyBoYXBwZW4gYmVm b3JlIGNvbnRpbnVpbmcgKi8KIAogICAgIHJldHVybiAwOwo= --=separator Content-Type: application/octet-stream; name="xsa519-2.patch" Content-Disposition: attachment; filename="xsa519-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KU3ViamVjdDog eGVuL2dudHRhYjogUHJldmVudCBHTlRUQUJPUF9jYWNoZV9mbHVzaCBmcm9tIGNvcnJ1cHRpbmcg Uk8gZ3JhbnRzCgpHcmFudHMgY2FuIGJlIG9mZmVyZWQgcmVhZC1vbmx5IGJ5IHRoZSBvd25pbmcg ZG9tYWluLiAgV2hpbGUgYSBkb21haW4gbWFwcGluZwphIFJPIGdyYW50IG1heSBoYXZlIGEgbmVl ZCB0byBpbnZhbGlkYXRlIHRoZSBjYWNoZSwgaXQgbXVzdCBub3QgbW9kaWZ5IHRoZQpvdGhlci1n dWVzdHMgZGF0YSB3aGlsZSBkb2luZyBzby4gIEZvcmNlLXVwZ3JhZGUgdG8gYSBjbGVhbiBvcGVy YXRpb24gaW4gdGhpcwpjYXNlLgoKVGhpcyBpcyBDVkUtMjAyNi0xMDI3MDIsIHBhcnQgb2YgWFNB LTUxOS4KCkZpeGVzOiAxOGU4ZDIyZmU3NTAgKCJpbnRyb2R1Y2UgR05UVEFCT1BfY2FjaGVfZmx1 c2giKQpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu Y29tPgpSZXZpZXdlZC1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu b3JnPgoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYyBiL3hlbi9jb21tb24v Z3JhbnRfdGFibGUuYwppbmRleCA4ODkyNjUzY2VkNzAuLjAzZTkxOWZkMjQyNCAxMDA2NDQKLS0t IGEveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jCisrKyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUu YwpAQCAtOTgzLDYgKzk4MywxMyBAQCBzdGF0aWMgc3RydWN0IGFjdGl2ZV9ncmFudF9lbnRyeSAq Z3JhbnRfbWFwX2V4aXN0cyhjb25zdCBzdHJ1Y3QgZG9tYWluICpsZCwKIAogICAgIHJldHVybiBF UlJfUFRSKC1FSU5WQUwpOwogfQorCitzdGF0aWMgYm9vbCBncmFudF9tYXBfaXNfcm8oc3RydWN0 IGFjdGl2ZV9ncmFudF9lbnRyeSAqYWN0KQoreworICAgIEFTU0VSVChzcGluX2lzX2xvY2tlZCgm YWN0LT5sb2NrKSk7CisKKyAgICByZXR1cm4gKGFjdC0+cGluICYgKEdOVFBJTl9oc3R3X21hc2sg fCBHTlRQSU5fZGV2d19tYXNrKSkgPT0gMDsKK30KICNlbmRpZiAvKiBDT05GSUdfSEFTX0dSQU5U X0NBQ0hFX0ZMVVNIICovCiAKIHVuaW9uIG1hcHRyYWNrX25vZGUgewpAQCAtMzU5Nyw3ICszNjA0 LDcgQEAgZ250dGFiX3N3YXBfZ3JhbnRfcmVmKFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oZ250dGFi X3N3YXBfZ3JhbnRfcmVmX3QpIHVvcCwKIH0KIAogI2lmZGVmIENPTkZJR19IQVNfR1JBTlRfQ0FD SEVfRkxVU0gKLXN0YXRpYyBpbnQgX2NhY2hlX2ZsdXNoKGNvbnN0IGdudHRhYl9jYWNoZV9mbHVz aF90ICpjZmx1c2gsIGdyYW50X3JlZl90ICpjdXJfcmVmKQorc3RhdGljIGludCBfY2FjaGVfZmx1 c2goZ250dGFiX2NhY2hlX2ZsdXNoX3QgKmNmbHVzaCwgZ3JhbnRfcmVmX3QgKmN1cl9yZWYpCiB7 CiAgICAgc3RydWN0IGRvbWFpbiAqZCwgKm93bmVyOwogICAgIHN0cnVjdCBwYWdlX2luZm8gKnBh Z2U7CkBAIC0zNjQ4LDYgKzM2NTUsMjQgQEAgc3RhdGljIGludCBfY2FjaGVfZmx1c2goY29uc3Qg Z250dGFiX2NhY2hlX2ZsdXNoX3QgKmNmbHVzaCwgZ3JhbnRfcmVmX3QgKmN1cl9yZWYKICAgICAg ICAgICAgIHB1dF9wYWdlKHBhZ2UpOwogICAgICAgICAgICAgcmV0dXJuIGFjdCA/IFBUUl9FUlIo YWN0KSA6IDE7CiAgICAgICAgIH0KKworICAgICAgICAvKgorICAgICAgICAgKiBJZiB0aGUgZ3Jh bnQgbWFwcGluZyBpcyByZWFkLW9ubHksIGl0IG11c3QgYmUgY2xlYW5lZCBhcyB3ZWxsIGFzCisg ICAgICAgICAqIGludmFsaWRhdGVkLiAgSW52YWxpZGF0aW9uIHdpdGhvdXQgY2xlYW5pbmcgbWF5 IG1vZGlmeSBtZW1vcnkgdGhlCisgICAgICAgICAqIGdyYW50ZXIgaXMgZXhwZWN0aW5nIG5vdCB0 byBjaGFuZ2UuCisgICAgICAgICAqCisgICAgICAgICAqIEl0IGlzIGhpZ2hseSB1bmxpa2VseSBi dXQgbGVnYWwgdG8gaGF2ZSBtdWx0aXBsZSBncmFudCBtYXBwaW5ncyBvZgorICAgICAgICAgKiBk aWZmZXJpbmcgcmVhZC1vbmx5LW5lc3MuICBJZiBhIHJlYWQtd3JpdGUgZ3JhbnQgbWFwcGluZyBp cyBmb3VuZAorICAgICAgICAgKiBmaXJzdCwgdGhlbiBpdCdzIGZpbmUgdG8gaW52YWxpZGF0ZSB3 aXRob3V0IGNsZWFuLgorICAgICAgICAgKgorICAgICAgICAgKiBJZiBhIHJlYWQtb25seSBncmFu dCBtYXBwaW5nIGlzIGZvdW5kIGZpcnN0LCBhIGxhdGVyIHJlYWQtd3JpdGUKKyAgICAgICAgICog bWFwcGluZyBjb3VsZCBiZSBtaXNzZWQuICBBc3N1bWUgdGhhdCB0aGUgcmVhZC1vbmx5IG1hcHBp bmcgaXMgdGhlCisgICAgICAgICAqIG9ubHkgbWFwcGluZy4gIFRoZSBjb3N0IGlzIGEgY2xlYW4g b2YgdXAgdG8gNGssIHdoaWxlIHRoZSBzYXZpbmcgaXMKKyAgICAgICAgICogbm90IHJlcXVpcmlu ZyB0aGUgc2VhcmNoIG9mIGdyYW50IG1hcHMgdG8gYmUgZXhoYXVzdGl2ZSBpbiBvcmRlciB0bwor ICAgICAgICAgKiBzcG90IGEgY29ybmVyLWNhc2UgZXhwZWN0ZWQgbm90IHRvIGV4aXN0IGluIHBy YWN0aWNlLgorICAgICAgICAgKi8KKyAgICAgICAgaWYgKCBncmFudF9tYXBfaXNfcm8oYWN0KSAp CisgICAgICAgICAgICBjZmx1c2gtPm9wIHw9IEdOVFRBQl9DQUNIRV9DTEVBTjsKICAgICB9CiAK ICAgICB2ID0gbWFwX2RvbWFpbl9wYWdlKG1mbik7Cg== --=separator Content-Type: application/octet-stream; name="xsa519-4.20-1.patch" Content-Disposition: attachment; filename="xsa519-4.20-1.patch" Content-Transfer-Encoding: base64 RnJvbTogTGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4K U3ViamVjdDogeGVuL2FybTogcGFnZTogZml4IHNpemUgdW5kZXJmbG93IGluIGludmFsaWRhdGVf ZGNhY2hlX3ZhX3JhbmdlKCkKCldoZW4gdGhlIHN0YXJ0IGFkZHJlc3MgaXMgbm90IGNhY2hlbGlu ZSBhbGlnbmVkLCB0aGUgYnl0ZXMgY292ZXJlZCBieQp0aGUgZmlyc3QsIHBhcnRpYWwgY2FjaGVs aW5lIGFyZSBzdWJ0cmFjdGVkIGZyb20gJ3NpemUnLiBOb3RoaW5nIGNoZWNrcwp0aGF0IHRoZSBy ZWdpb24gYWN0dWFsbHkgZXh0ZW5kcyBiZXlvbmQgdGhhdCBjYWNoZWxpbmUsIHNvIGlmIGl0IGRv ZXMKbm90LCB0aGUgdW5zaWduZWQgc3VidHJhY3Rpb24gdW5kZXJmbG93cyBhbmQgdGhlIGxvb3Ag dGhhdCBmb2xsb3dzIHdhbGtzCnByYWN0aWNhbGx5IHRoZSBlbnRpcmUgYWRkcmVzcyBzcGFjZS4K CkZvciBleGFtcGxlLCB3aXRoIGEgNjQtYnl0ZSBjYWNoZWxpbmUsIHAgPSAweDQwMDAwMDAxIGFu ZCBzaXplID0gMToKCiAgICBwICYgY2FjaGVsaW5lX21hc2sgICAgIC0+IDEsIHNvIHRoZSBwYXJ0 aWFsIGhlYWQgaXMgdGFrZW4KICAgIHNpemUgLT0gNjQgLSAxICAgICAgICAgLT4gMSAtIDYzIHVu ZGVyZmxvd3MgdG8gMHhmZmZmZmZmZmZmZmZmZmMyCgpJbnN0ZWFkIG9mIGEgc2luZ2xlICJkYyBj aXZhYyIgYXQgMHg0MDAwMDAwMCwgdGhlIGxvb3AgdGhlbiBydW5zCjI4ODIzMDM3NjE1MTcxMTc0 MyB0aW1lcywgaXNzdWluZyAiZGMgaXZhYyIgZnJvbSAweDQwMDAwMDQwIHVwd2FyZHMuCkludmFs aWRhdGluZyB3aXRob3V0IGNsZWFuaW5nIGRpc2NhcmRzIGRpcnR5IGNhY2hlbGluZXMsIHNvIHRo aXMKY29ycnVwdHMgd2hhdGV2ZXIgaXMgbWFwcGVkIGFsb25nIHRoZSB3YXkgdW50aWwgWGVuIHRh a2VzIGEgZGF0YSBhYm9ydC4KCk1vcmVvdmVyLCBfY2FjaGVfZmx1c2goKSBpbiBjb21tb24vZ3Jh bnRfdGFibGUuYywgcmVhY2hhYmxlIGZyb20gYSBndWVzdAp2aWEgR05UVEFCT1BfY2FjaGVfZmx1 c2gsIGJvdW5kcyAnb2Zmc2V0JyBhbmQgJ2xlbmd0aCcgYWdhaW5zdCB0aGUgcGFnZQpzaXplIGJ1 dCByZXF1aXJlcyBubyBhbGlnbm1lbnQsIHNvIEdOVFRBQl9DQUNIRV9JTlZBTCB3aXRoIG9mZnNl dCA9IDEKYW5kIGxlbmd0aCA9IDEgaXMgZW5vdWdoIHRvIHRyaWdnZXIgdGhpcy4gTm90ZSB0aGF0 IHRoZSBwYWdlIG1heSBiZWxvbmcKdG8gYSBkaWZmZXJlbnQgZG9tYWluICh0aGUgZCAhPSBvd25l ciBwYXRoKSwgc28gdGhlIGRhdGEgYmVpbmcgZGlzY2FyZGVkCmlzIG5vdCBuZWNlc3NhcmlseSB0 aGUgY2FsbGVyJ3Mgb3duLgoKVGhlIHN1YnRyYWN0aW9uIGRhdGVzIGJhY2sgdG8gdGhlIGZpeCBm b3IgWFNBLTQzNywgc28gdGhpcyBpcyBhIHJlZ3Jlc3Npb24KaW4gdGhhdCBjaGFuZ2UuCgpGaXgg dGhpcyBieSBkZXRlY3RpbmcgdGhlIHVuZGVyZmxvdyBpbnN0ZWFkIG9mIGxldHRpbmcgaXQgaGFw cGVuOiBpZiB0aGUKcmVnaW9uIGVuZHMgaW5zaWRlIHRoZSBmaXJzdCBjYWNoZWxpbmUsIHRoZXJl IGlzIG5vdGhpbmcgbGVmdCB0byBmbHVzaAphbmQgdGhlIGZ1bmN0aW9uIGJhaWxzIG91dCByaWdo dCBhZnRlciBjbGVhbmluZyBpdC4gUGFydGlhbGx5IGNvdmVyZWQKY2FjaGVsaW5lcyBhcmUgc3Rp bGwgY2xlYW5lZCBhcyB3ZWxsIGFzIGludmFsaWRhdGVkLCBzbyB0aGF0IGRhdGEgb3V0c2lkZQpv ZiB0aGUgcmVnaW9uIGlzIG5vdCBkaXNjYXJkZWQuCgpBZGRpdGlvbmFsbHksIGRyb3AgJ2lkeCcg YW5kIGFkdmFuY2UgJ3AnIGRpcmVjdGx5IGluc3RlYWQuIEl0IHNpbXBsaWZpZXMKdGhlIGxvZ2lj IHdoaWxlIHVzaW5nIGZld2VyIHZhcmlhYmxlcyBhbmQgbGVzcyBhcml0aG1ldGljLgoKTm90ZSB0 aGF0IHRoZSBwYXJ0aWFsIGhlYWQgaXMgbm93IGNsZWFuZWQgdXNpbmcgdGhlIHVuYWxpZ25lZCBz dGFydCBvZiB0aGUKcmVnaW9uIGluc3RlYWQgb2YgdGhlIHN0YXJ0IG9mIGl0cyBjYWNoZWxpbmUu IFRoaXMgaXMgcGVybWl0dGVkIGJ5IHRoZQphcmNoaXRlY3R1cmU7IHRoZSBBcm0gQVJNIChEREkg MDQ4Nykgc3RhdGVzOgoKICAiV2hlbiBhIERDIGluc3RydWN0aW9uIHJlcXVpcmVzIGFuIGFkZHJl c3MgYXJndW1lbnQgdGhpcyB0YWtlcyB0aGUgZm9ybQogIG9mIGEgNjQtYml0IHJlZ2lzdGVyIHRo YXQgaG9sZHMgdGhlIFZBIGFyZ3VtZW50LiBObyBhbGlnbm1lbnQKICByZXN0cmljdGlvbnMgYXBw bHkgZm9yIHRoaXMgYWRkcmVzcy4iCgpUaGUgc2FtZSBhcHBsaWVzIG9uIEFybTMyLgoKVGhpcyBp cyBDVkUtMjAyNi0xMDI2OTksIHBhcnQgb2YgWFNBLTUxOS4KCkZpeGVzOiA5YTIxNmU5MmRlOWYg KCJ4ZW4vYXJtOiBwYWdlOiBIYW5kbGUgY2FjaGUgZmx1c2ggb2YgYW4gZWxlbWVudCBhdCB0aGUg dG9wIG9mIHRoZSBhZGRyZXNzIHNwYWNlIikKU2lnbmVkLW9mZi1ieTogTGVvbmlkIEtvbWFyaWFu c2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFtLmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVs aWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KUmV2aWV3ZWQtYnk6IEp1bGllbiBHcmFsbCA8anVsaWVu QHhlbi5vcmc+CgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3BhZ2UuaCBi L3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9wYWdlLmgKaW5kZXggNjlmODE3ZDFlNjhhLi5lMjYx MDRhMjFlMTAgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9wYWdlLmgKKysr IGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3BhZ2UuaApAQCAtMTYyLDcgKzE2Miw3IEBAIHN0 YXRpYyBpbmxpbmUgc2l6ZV90IHJlYWRfZGNhY2hlX2xpbmVfYnl0ZXModm9pZCkKIHN0YXRpYyBp bmxpbmUgaW50IGludmFsaWRhdGVfZGNhY2hlX3ZhX3JhbmdlKGNvbnN0IHZvaWQgKnAsIHVuc2ln bmVkIGxvbmcgc2l6ZSkKIHsKICAgICBzaXplX3QgY2FjaGVsaW5lX21hc2sgPSBkY2FjaGVfbGlu ZV9ieXRlcyAtIDE7Ci0gICAgdW5zaWduZWQgbG9uZyBpZHggPSAwOworICAgIHVuc2lnbmVkIGxv bmcgcGFydGlhbF9oZWFkOwogCiAgICAgaWYgKCAhc2l6ZSApCiAgICAgICAgIHJldHVybiAwOwpA QCAtMTcyLDIxICsxNzIsMzQgQEAgc3RhdGljIGlubGluZSBpbnQgaW52YWxpZGF0ZV9kY2FjaGVf dmFfcmFuZ2UoY29uc3Qgdm9pZCAqcCwgdW5zaWduZWQgbG9uZyBzaXplKQogCiAgICAgZHNiKHN5 KTsgICAgICAgICAgIC8qIFNvIHRoZSBDUFUgaXNzdWVzIGFsbCB3cml0ZXMgdG8gdGhlIHJhbmdl ICovCiAKLSAgICBpZiAoICh1aW50cHRyX3QpcCAmIGNhY2hlbGluZV9tYXNrICkKKyAgICAvKgor ICAgICAqIEEgY2FjaGVsaW5lIG9ubHkgcGFydGlhbGx5IGNvdmVyZWQgYnkgdGhlIHJlZ2lvbiBo YXMgdG8gYmUgY2xlYW5lZCBhcworICAgICAqIHdlbGwgYXMgaW52YWxpZGF0ZWQsIHNvIHRoYXQg ZGF0YSBsaXZpbmcgb3V0c2lkZSBvZiB0aGUgcmVnaW9uIGlzIG5vdAorICAgICAqIGRpc2NhcmRl ZC4KKyAgICAgKi8KKyAgICBwYXJ0aWFsX2hlYWQgPSAodWludHB0cl90KXAgJiBjYWNoZWxpbmVf bWFzazsKKyAgICBpZiAoIHBhcnRpYWxfaGVhZCApCiAgICAgewotICAgICAgICBzaXplIC09IGRj YWNoZV9saW5lX2J5dGVzIC0gKCh1aW50cHRyX3QpcCAmIGNhY2hlbGluZV9tYXNrKTsKLSAgICAg ICAgcCA9ICh2b2lkICopKCh1aW50cHRyX3QpcCAmIH5jYWNoZWxpbmVfbWFzayk7CisgICAgICAg IHVuc2lnbmVkIGxvbmcgcmVtID0gZGNhY2hlX2xpbmVfYnl0ZXMgLSBwYXJ0aWFsX2hlYWQ7CisK ICAgICAgICAgYXNtIHZvbGF0aWxlIChfX2NsZWFuX2FuZF9pbnZhbGlkYXRlX2RjYWNoZV9vbmUo MCkgOiA6ICJyIiAocCkpOwotICAgICAgICBwICs9IGRjYWNoZV9saW5lX2J5dGVzOworICAgICAg ICBwICs9IHJlbTsKKworICAgICAgICAvKiBUaGUgcmVnaW9uIG1heSBlbmQgd2l0aGluIHRoaXMg Y2FjaGVsaW5lLCBsZWF2aW5nIG5vdGhpbmcgdG8gZG8uICovCisgICAgICAgIHNpemUgLT0gcmVt OworICAgICAgICBpZiAoIHNpemUgPiByZW0gKSAvKiB1bmRlcmZsb3cgKi8KKyAgICAgICAgICAg IGdvdG8gZG9uZTsKICAgICB9CiAKICAgICBmb3IgKCA7IHNpemUgPj0gZGNhY2hlX2xpbmVfYnl0 ZXM7Ci0gICAgICAgICAgICBpZHggKz0gZGNhY2hlX2xpbmVfYnl0ZXMsIHNpemUgLT0gZGNhY2hl X2xpbmVfYnl0ZXMgKQotICAgICAgICBhc20gdm9sYXRpbGUgKF9faW52YWxpZGF0ZV9kY2FjaGVf b25lKDApIDogOiAiciIgKHAgKyBpZHgpKTsKKyAgICAgICAgICAgIHAgKz0gZGNhY2hlX2xpbmVf Ynl0ZXMsIHNpemUgLT0gZGNhY2hlX2xpbmVfYnl0ZXMgKQorICAgICAgICBhc20gdm9sYXRpbGUg KF9faW52YWxpZGF0ZV9kY2FjaGVfb25lKDApIDogOiAiciIgKHApKTsKIAorICAgIC8qIFBhcnRp YWwgdGFpbCBtdXN0IGJlIGNsZWFuZWQgYXMgd2VsbC4gKi8KICAgICBpZiAoIHNpemUgPiAwICkK LSAgICAgICAgYXNtIHZvbGF0aWxlIChfX2NsZWFuX2FuZF9pbnZhbGlkYXRlX2RjYWNoZV9vbmUo MCkgOiA6ICJyIiAocCArIGlkeCkpOworICAgICAgICBhc20gdm9sYXRpbGUgKF9fY2xlYW5fYW5k X2ludmFsaWRhdGVfZGNhY2hlX29uZSgwKSA6IDogInIiIChwKSk7CiAKKyBkb25lOgogICAgIGRz YihzeSk7ICAgICAgICAgICAvKiBTbyB3ZSBrbm93IHRoZSBmbHVzaGVzIGhhcHBlbiBiZWZvcmUg Y29udGludWluZyAqLwogCiAgICAgcmV0dXJuIDA7Cg== --=separator Content-Type: application/octet-stream; name="xsa519-4.20-2.patch" Content-Disposition: attachment; filename="xsa519-4.20-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KU3ViamVjdDog eGVuL2dudHRhYjogUHJldmVudCBHTlRUQUJPUF9jYWNoZV9mbHVzaCBmcm9tIGNvcnJ1cHRpbmcg Uk8gZ3JhbnRzCgpHcmFudHMgY2FuIGJlIG9mZmVyZWQgcmVhZC1vbmx5IGJ5IHRoZSBvd25pbmcg ZG9tYWluLiAgV2hpbGUgYSBkb21haW4gbWFwcGluZwphIFJPIGdyYW50IG1heSBoYXZlIGEgbmVl ZCB0byBpbnZhbGlkYXRlIHRoZSBjYWNoZSwgaXQgbXVzdCBub3QgbW9kaWZ5IHRoZQpvdGhlci1n dWVzdHMgZGF0YSB3aGlsZSBkb2luZyBzby4gIEZvcmNlLXVwZ3JhZGUgdG8gYSBjbGVhbiBvcGVy YXRpb24gaW4gdGhpcwpjYXNlLgoKVGhpcyBpcyBDVkUtMjAyNi0xMDI3MDIsIHBhcnQgb2YgWFNB LTUxOS4KCkZpeGVzOiAxOGU4ZDIyZmU3NTAgKCJpbnRyb2R1Y2UgR05UVEFCT1BfY2FjaGVfZmx1 c2giKQpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu Y29tPgpSZXZpZXdlZC1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu b3JnPgoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYyBiL3hlbi9jb21tb24v Z3JhbnRfdGFibGUuYwppbmRleCBjMGNhNGYzMDU3NTAuLjIwNmYxZWQ2N2EyOCAxMDA2NDQKLS0t IGEveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jCisrKyBiL3hlbi9jb21tb24vZ3JhbnRfdGFibGUu YwpAQCAtOTgzLDYgKzk4MywxMyBAQCBzdGF0aWMgc3RydWN0IGFjdGl2ZV9ncmFudF9lbnRyeSAq Z3JhbnRfbWFwX2V4aXN0cyhjb25zdCBzdHJ1Y3QgZG9tYWluICpsZCwKICAgICByZXR1cm4gRVJS X1BUUigtRUlOVkFMKTsKIH0KIAorc3RhdGljIGJvb2wgZ3JhbnRfbWFwX2lzX3JvKHN0cnVjdCBh Y3RpdmVfZ3JhbnRfZW50cnkgKmFjdCkKK3sKKyAgICBBU1NFUlQoc3Bpbl9pc19sb2NrZWQoJmFj dC0+bG9jaykpOworCisgICAgcmV0dXJuIChhY3QtPnBpbiAmIChHTlRQSU5faHN0d19tYXNrIHwg R05UUElOX2RldndfbWFzaykpID09IDA7Cit9CisKIHVuaW9uIG1hcHRyYWNrX25vZGUgewogICAg IHN0cnVjdCB7CiAgICAgICAgIC8qIFJhZGl4IHRyZWUgc2xvdCBwb2ludGVycyB1c2UgdHdvIG9m IHRoZSBiaXRzLiAqLwpAQCAtMzU5NSw3ICszNjAyLDcgQEAgZ250dGFiX3N3YXBfZ3JhbnRfcmVm KFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oZ250dGFiX3N3YXBfZ3JhbnRfcmVmX3QpIHVvcCwKICAg ICByZXR1cm4gMDsKIH0KIAotc3RhdGljIGludCBfY2FjaGVfZmx1c2goY29uc3QgZ250dGFiX2Nh Y2hlX2ZsdXNoX3QgKmNmbHVzaCwgZ3JhbnRfcmVmX3QgKmN1cl9yZWYpCitzdGF0aWMgaW50IF9j YWNoZV9mbHVzaChnbnR0YWJfY2FjaGVfZmx1c2hfdCAqY2ZsdXNoLCBncmFudF9yZWZfdCAqY3Vy X3JlZikKIHsKICAgICBzdHJ1Y3QgZG9tYWluICpkLCAqb3duZXI7CiAgICAgc3RydWN0IHBhZ2Vf aW5mbyAqcGFnZTsKQEAgLTM2NDYsNiArMzY1MywyNCBAQCBzdGF0aWMgaW50IF9jYWNoZV9mbHVz aChjb25zdCBnbnR0YWJfY2FjaGVfZmx1c2hfdCAqY2ZsdXNoLCBncmFudF9yZWZfdCAqY3VyX3Jl ZgogICAgICAgICAgICAgcHV0X3BhZ2UocGFnZSk7CiAgICAgICAgICAgICByZXR1cm4gYWN0ID8g UFRSX0VSUihhY3QpIDogMTsKICAgICAgICAgfQorCisgICAgICAgIC8qCisgICAgICAgICAqIElm IHRoZSBncmFudCBtYXBwaW5nIGlzIHJlYWQtb25seSwgaXQgbXVzdCBiZSBjbGVhbmVkIGFzIHdl bGwgYXMKKyAgICAgICAgICogaW52YWxpZGF0ZWQuICBJbnZhbGlkYXRpb24gd2l0aG91dCBjbGVh bmluZyBtYXkgbW9kaWZ5IG1lbW9yeSB0aGUKKyAgICAgICAgICogZ3JhbnRlciBpcyBleHBlY3Rp bmcgbm90IHRvIGNoYW5nZS4KKyAgICAgICAgICoKKyAgICAgICAgICogSXQgaXMgaGlnaGx5IHVu bGlrZWx5IGJ1dCBsZWdhbCB0byBoYXZlIG11bHRpcGxlIGdyYW50IG1hcHBpbmdzIG9mCisgICAg ICAgICAqIGRpZmZlcmluZyByZWFkLW9ubHktbmVzcy4gIElmIGEgcmVhZC13cml0ZSBncmFudCBt YXBwaW5nIGlzIGZvdW5kCisgICAgICAgICAqIGZpcnN0LCB0aGVuIGl0J3MgZmluZSB0byBpbnZh bGlkYXRlIHdpdGhvdXQgY2xlYW4uCisgICAgICAgICAqCisgICAgICAgICAqIElmIGEgcmVhZC1v bmx5IGdyYW50IG1hcHBpbmcgaXMgZm91bmQgZmlyc3QsIGEgbGF0ZXIgcmVhZC13cml0ZQorICAg ICAgICAgKiBtYXBwaW5nIGNvdWxkIGJlIG1pc3NlZC4gIEFzc3VtZSB0aGF0IHRoZSByZWFkLW9u bHkgbWFwcGluZyBpcyB0aGUKKyAgICAgICAgICogb25seSBtYXBwaW5nLiAgVGhlIGNvc3QgaXMg YSBjbGVhbiBvZiB1cCB0byA0aywgd2hpbGUgdGhlIHNhdmluZyBpcworICAgICAgICAgKiBub3Qg cmVxdWlyaW5nIHRoZSBzZWFyY2ggb2YgZ3JhbnQgbWFwcyB0byBiZSBleGhhdXN0aXZlIGluIG9y ZGVyIHRvCisgICAgICAgICAqIHNwb3QgYSBjb3JuZXItY2FzZSBleHBlY3RlZCBub3QgdG8gZXhp c3QgaW4gcHJhY3RpY2UuCisgICAgICAgICAqLworICAgICAgICBpZiAoIGdyYW50X21hcF9pc19y byhhY3QpICkKKyAgICAgICAgICAgIGNmbHVzaC0+b3AgfD0gR05UVEFCX0NBQ0hFX0NMRUFOOwog ICAgIH0KIAogICAgIHYgPSBtYXBfZG9tYWluX3BhZ2UobWZuKTsK --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:29:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:29:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447164.1663492 (Exim 4.92) (envelope-from ) id 1xGbd8-0003j7-9C; Tue, 13 Oct 2026 12:29:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447164.1663492; Tue, 13 Oct 2026 12:29: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 1xGbd6-0003ee-B2; Tue, 13 Oct 2026 12:29:16 +0000 Received: by outflank-mailman (input) for mailman id 1447164; Tue, 13 Oct 2026 12:29:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbct-0001Do-CN; Tue, 13 Oct 2026 12:29:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbcs-009dD9-Oe; Tue, 13 Oct 2026 14:29:02 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace2403-2eae-0a2a0a5409dd-0a2a4501ece6-32 for ; Tue, 13 Oct 2026 14:29:02 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace240d-5984-0a2a45010019-6882d725a7a2-3 for ; Tue, 13 Oct 2026 14:29:02 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbcq-00000003NIa-0fu4; Tue, 13 Oct 2026 12:28:59 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbcp-0000000F9FM-3n4i; Tue, 13 Oct 2026 12:28: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; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 520 v2 (CVE-2026-102700) - gnttab: cache-flush handling may cause page reference leak Message-Id: Date: Tue, 13 Oct 2026 12:28:59 +0000 X-purgate-ID: tlsNG-d62444/1791894542-BEA66757-1FED5286/0/0 X-purgate-type: clean X-purgate-size: 4719 --=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-102700 / XSA-520 version 2 gnttab: cache-flush handling may cause page reference leak UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= With its original introduction, GNTTAB_cache_flush was made available uniformly. XSA-232 (CVE-2017-14318) then covered an omitted NULL pointer check, yet the addition of that check failed to adjust the subsequent error path. That error path fails to drop a page reference in case the specified page is owned by a special system domain (DOM_IO and DOM_COW are system domains which can have memory pages assigned to them.) IMPACT ====== The most likely outcome is Denial of Service (DoS) of either Domain 0 (then likely affecting the entire host) or of another domain. VULNERABLE SYSTEMS ================== Xen versions 4.5 through 4.20 are affected. Xen versions 4.21 and newer as well as 4.4 and older are not affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered independently by Andrew Cooper of Citrix and Yehyeong Lee. 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. xsa520.patch Xen 4.20.x - Xen 4.17.x $ sha256sum xsa520* e6814fe4a77d38f83c7bf3b92e8d24a0d95508572b845c622985e7021338cca9 xsa520.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/4UyVfoK9kFAmrOItgMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZw3AIALH4pnPt5g51TX1HIUUjtyqxK9j6IyFtYgHqptRA XTaZAD+NlU9R97SKGG8/YkMwdIDOQ43HE0sjJpARScQbCXcoq781yf4U1xbuy56z prClo+bFT61BnbJnzpQuhmZ1kfPYhqqeYSEsm9TUj6g1Z3j2oq45aISrgyDJgsRJ /t8Reelp/kFhQHql7Bt7uRy0xYTHcYuN56dGDAJJ1MsExsbEdLW4hgIcTjBkD04A 29MSv3j1WlCpWSCIEs27dzJv3i5mrcp1hSXfDo84NYMzxEY9FRcSGPNaGiG0/5pG gRe67qr5htHW8rYiTjJRc2b/Sp6D1f7+QThqcq010NwdrzE= =v0su -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa520.patch" Content-Disposition: attachment; filename="xsa520.patch" Content-Transfer-Encoding: base64 RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0OiBnbnR0YWI6IHBy b3Blcmx5IGRyb3AgcGFnZSByZWYgb24gYSBHTlRUQUJfY2FjaGVfZmx1c2ggZXJyb3IgcGF0aAoK T3JkaW5hcnkgZG9tYWlucyBhbHdheXMgaGF2ZSBhIGdyYW50IHRhYmxlLiBTeXN0ZW0gZG9tYWlu cyBkb24ndCwgYnV0IHRoZXkKYWxzbyBkb24ndCBub3JtYWxseSAib3duIiBwYWdlcyAtIGV4Y2Vw dCBmb3IgRE9NX0lPIGFuZCBET01fQ09XIG9uIHg4Ni4KClRoaXMgaXMgWFNBLTUyMCAvIENWRS0y MDI2LTEwMjcwMC4KClJlcG9ydGVkLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0Bj aXRyaXguY29tPgpSZXBvcnRlZC1ieTogWWVoeWVvbmcgTGVlIDx5aGxlZUBpc3NsYWIua29yZWEu YWMua3I+ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCi0t LSBhL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYworKysgYi94ZW4vY29tbW9uL2dyYW50X3RhYmxl LmMKQEAgLTM2MjQsNiArMzYyNCw4IEBAIHN0YXRpYyBpbnQgX2NhY2hlX2ZsdXNoKGNvbnN0IGdu dHRhYl9jYWMKICAgICBvd25lciA9IHBhZ2VfZ2V0X293bmVyX2FuZF9yZWZlcmVuY2UocGFnZSk7 CiAgICAgaWYgKCAhb3duZXIgfHwgIW93bmVyLT5ncmFudF90YWJsZSApCiAgICAgeworICAgICAg ICBpZiAoIG93bmVyICkKKyAgICAgICAgICAgIHB1dF9wYWdlKHBhZ2UpOwogICAgICAgICByY3Vf dW5sb2NrX2RvbWFpbihkKTsKICAgICAgICAgcmV0dXJuIC1FUEVSTTsKICAgICB9Cg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:29:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:29:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447195.1663527 (Exim 4.92) (envelope-from ) id 1xGbdI-0005eS-F1; Tue, 13 Oct 2026 12:29:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447195.1663527; Tue, 13 Oct 2026 12:29: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 1xGbdG-0005XD-Mo; Tue, 13 Oct 2026 12:29:26 +0000 Received: by outflank-mailman (input) for mailman id 1447195; Tue, 13 Oct 2026 12:29:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbcx-000207-KN; Tue, 13 Oct 2026 12:29:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbcw-00DIaV-Tv; Tue, 13 Oct 2026 14:29:06 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace2401-e002-0a2a0a5209dd-0a2a4503a296-40 for ; Tue, 13 Oct 2026 14:29:06 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace2411-fae8-0a2a45030019-6882d725a7b0-3 for ; Tue, 13 Oct 2026 14:29:06 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGbct-00000003NJD-2Axv; Tue, 13 Oct 2026 12:29:03 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.98.2) (envelope-from ) id 1xGbct-0000000F9PF-18JY; Tue, 13 Oct 2026 12:29: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; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.515 (Entity 5.515) 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 521 v2 (CVE-2026-102701) - tapdisk: Out-of-bounds access in tap_ctl_connect_xenblkif() Message-Id: Date: Tue, 13 Oct 2026 12:29:03 +0000 X-purgate-ID: tlsNG-33051d/1791894546-77EC24E9-556037BB/0/0 X-purgate-type: clean X-purgate-size: 6574 --=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-102701 / XSA-521 version 2 tapdisk: Out-of-bounds access in tap_ctl_connect_xenblkif() UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Tapdisk is a userspace xen-blkback implementation used by the XAPI toolstack. During connection, multi-page rings may be negotiated between the frontend and backend. Tapdisk had no boundary check on the size requested by the frontend, and assumed it did not exceed 8. IMPACT ====== A buggy or malicious guest can cause a stack overflow in tapdisk, potentially leading to code execution. Tapdisk normally runs as root. VULNERABLE SYSTEMS ================== All versions of tapdisk are vulnerable. MITIGATION ========== There are no mitigations. CREDITS ======= This issue was discovered by Claude Opus and diagnosed as a security issue by Teddy Astie of Vates. RESOLUTION ========== Applying the attached patch resolves this issue. xsa521.patch blktap master $ sha256sum xsa521* 72ece150e9d0836f217f3382c8dc76cd51bffbe4b7610c00f219b90e5600cbc5 xsa521.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/4UyVfoK9kFAmrOIvgMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZgdgIAKXTyop/90HNxeBpRVbYP2vrPCm2YBMzoc3YtxdM 0wWdbFvUptHWnzypCWuUGJWq8ZFf4lInnkJrj0sJ9te+OSQDqcfwTMEQuDWzBM08 lQ27H0kcum3rble2V2CFCK4uOoLYwOYX/bA5vCeGiiPQcUU3m++6IoAMaRY7G2V7 RTNJmNCtbGiC7l3ExUX9KxnFCSaX9gL99YkygybBecSsjJhdlGZj7pzvJtomv1sC fVSAFmXkivLGKX8TXQdj/48xmdqNSIQgYbdSdyZgGjmy7bxIgxB576FHwlN/fzf7 ZzpeEO8yZTFWeCJCKZavvjsq/7u2vxUtpoL3c81vSKWCOLc= =w1aW -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa521.patch" Content-Disposition: attachment; filename="xsa521.patch" Content-Transfer-Encoding: base64 RnJvbTogVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+ClN1YmplY3Q6IEVuc3Vy ZSBwYXNzZWQgcmluZy1wYWdlLW9yZGVyIGlzIHZhbGlkCgpUaGUgY3VycmVudCBsb2dpYyBhY2Nl cHRzIGFueSBndWVzdCBwcm92aWRlZCByaW5nIG9yZGVyLCB3aGljaCBjYW4gY2F1c2UgYQpzdGFj ayBvdmVyZmxvdyBpbiB0YXBfY3RsX2Nvbm5lY3RfeGVuYmxraWYoKSBhcyB0YXBkaXNrX21lc3Nh Z2VfYmxraWY6OmdyZWYKY2FuIG9ubHkgc3RvcmUgOCBncmFudCByZWZlcmVuY2VzLCB5ZXQgb3Jk ZXIgbWF5IGJlIGxhcmdlciB0aGFuIDMuCgpGaXggdGhpcyBieSBjaGVja2luZyB0aGF0IHJpbmcg b3JkZXIgdmFsdWVzIGlzIGluIFswLi4zXSByYW5nZS4gIEFsc28gY2xhcmlmeQp0aGUgZ3JlZiBh cnJheSBzaXplIGluIHRhcGRpc2tfbWVzc2FnZV9ibGtpZiAoZml4ZXMgVE9ETykuCgpUaGlzIGlz IFhTQS01MjEgLyBDVkUtMjAyNi0xMDI3MDEuCgpTaWduZWQtb2ZmLWJ5OiBUZWRkeSBBc3RpZSA8 dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4KUmV2aWV3ZWQtYnk6IFJvc3MgTGFnZXJ3YWxsIDxyb3Nz LmxhZ2Vyd2FsbEBjaXRyaXguY29tPgpUZXN0ZWQtYnk6IEFsZXggQnJldHQgPGFsZXguYnJldHRA Y2l0cml4LmNvbT4KCmRpZmYgLS1naXQgYS9jb250cm9sL3RhcC1jdGwteGVuLmMgYi9jb250cm9s L3RhcC1jdGwteGVuLmMKaW5kZXggZjA5Yjc2ZWE4MjU1Li4zN2RmZjA2NjIzYmYgMTAwNjQ0Ci0t LSBhL2NvbnRyb2wvdGFwLWN0bC14ZW4uYworKysgYi9jb250cm9sL3RhcC1jdGwteGVuLmMKQEAg LTQ1LDYgKzQ1LDggQEAKICNpbmNsdWRlIDxzdHJpbmcuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4K IAorI2luY2x1ZGUgInhlbl9ibGtpZi5oIgorI2luY2x1ZGUgImRlYnVnLmgiCiAjaW5jbHVkZSAi dGFwLWN0bC5oIgogI2luY2x1ZGUgImNvbXBpbGVyLmgiCiAjaW5jbHVkZSAidXRpbC5oIgpAQCAt NTgsNyArNjAsOSBAQCB0YXBfY3RsX2Nvbm5lY3RfeGVuYmxraWYoY29uc3QgcGlkX3QgcGlkLCBj b25zdCBkb21pZF90IGRvbWlkLCBjb25zdCBpbnQgZGV2aWQsCiAgICAgdGFwZGlza19tZXNzYWdl X3QgbWVzc2FnZTsKICAgICBpbnQgaSwgZXJyOwogCi0JbWVtc2V0KCZtZXNzYWdlLCAwLCBzaXpl b2YobWVzc2FnZSkpOworICAgIEFTU0VSVChvcmRlciA+PSAwICYmIG9yZGVyIDw9IE1BWF9SSU5H X1BBR0VfT1JERVIpOworCisgICAgbWVtc2V0KCZtZXNzYWdlLCAwLCBzaXplb2YobWVzc2FnZSkp OwogICAgIG1lc3NhZ2UudHlwZSA9IFRBUERJU0tfTUVTU0FHRV9YRU5CTEtJRl9DT05ORUNUOwog ICAgIG1lc3NhZ2UuY29va2llID0gbWlub3I7CiAKZGlmZiAtLWdpdCBhL2luY2x1ZGUvdGFwZGlz ay1tZXNzYWdlLmggYi9pbmNsdWRlL3RhcGRpc2stbWVzc2FnZS5oCmluZGV4IDQ4OTAxN2NhNjkw OS4uNzIzMWExNGQzMDFjIDEwMDY0NAotLS0gYS9pbmNsdWRlL3RhcGRpc2stbWVzc2FnZS5oCisr KyBiL2luY2x1ZGUvdGFwZGlzay1tZXNzYWdlLmgKQEAgLTM0LDYgKzM0LDggQEAKICNpbmNsdWRl IDxpbnR0eXBlcy5oPgogI2luY2x1ZGUgPHN5cy90eXBlcy5oPgogCisjaW5jbHVkZSAieGVuX2Js a2lmLmgiCisKIC8qCiAgKiBUT0RPIFRoaXMgaXMgcXVpdGUgc21hbGwgc2luY2Ugd2UgZG9uJ3Qg YWxsb3cgcGF0aCBiaWdnZXIgdGhhbiAyNTYgY2hhcnMuIElmCiAgKiB3ZSBldmVyIGluY3JlYXNl IHRoaXMsIG1ha2Ugc3VyZSB0YXBkaXNrX21lc3NhZ2VfdCBzdHJ1Y3R1cmVzIGFyZSBub3QKQEAg LTEzNSw5ICsxMzcsOCBAQCB0eXBlZGVmIHN0cnVjdCB0YXBkaXNrX21lc3NhZ2VfYmxraWYgewog CiAJLyoqCiAJICogR3JhbnQgcmVmZXJlbmNlcyBmb3IgdGhlIHNoYXJlZCByaW5nLgotCSAqIFRP RE8gV2h5IDggc3BlY2lmaWNhbGx5PwogCSAqLwotCXVpbnQzMl90IGdyZWZbOF07CisJdWludDMy X3QgZ3JlZltNQVhfUklOR19QQUdFU107CiAKIAkvKioKIAkgKiBOdW1iZXIgb2YgcGFnZXMgaW4g dGhlIHJpbmcsIGV4cHJlc3NlZCBhcyBhIHBhZ2Ugb3JkZXIuCmRpZmYgLS1naXQgYS90YXBiYWNr L2Zyb250ZW5kLmMgYi90YXBiYWNrL2Zyb250ZW5kLmMKaW5kZXggMjQzZjg0MjUyZGQ2Li45ODZm NDU2NDdiZjYgMTAwNjQ0Ci0tLSBhL3RhcGJhY2svZnJvbnRlbmQuYworKysgYi90YXBiYWNrL2Zy b250ZW5kLmMKQEAgLTExOSw2ICsxMTksMTIgQEAgY29ubmVjdF90YXAodmJkX3QgKiBjb25zdCBk ZXZpY2UpCiAgICAgICAgICAgICAgICAgIiVkIiwgJm9yZGVyKSkKICAgICAgICAgb3JkZXIgPSAw OwogCisgICAgaWYgKG9yZGVyIDwgMCB8fCBvcmRlciA+IE1BWF9SSU5HX1BBR0VfT1JERVIpIHsK KyAgICAgICAgV0FSTihkZXZpY2UsICJmcm9udC1lbmQgYXNrZWQgZm9yIGFuIGludmFsaWQgcmlu ZyBvcmRlcjogJWRcbiIsIG9yZGVyKTsKKyAgICAgICAgZXJyID0gRUlOVkFMOworICAgICAgICBn b3RvIG91dDsKKyAgICB9CisKICAgICAgbnJfcGFnZXMgPSAxIDw8IG9yZGVyOwogCiAgICAgaWYg KCEoZ3JlZiA9IGNhbGxvYyhucl9wYWdlcywgc2l6ZW9mKGdyYW50X3JlZl90KSkpKSB7Cg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:37:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:37:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447781.1663625 (Exim 4.92) (envelope-from ) id 1xGbkq-00083c-14; Tue, 13 Oct 2026 12:37:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447781.1663625; Tue, 13 Oct 2026 12:37: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 1xGbkp-00083V-Uh; Tue, 13 Oct 2026 12:37:15 +0000 Received: by outflank-mailman (input) for mailman id 1447781; Tue, 13 Oct 2026 12:37:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGbkp-00083P-7a for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:37:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbko-00DJqI-Jq for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:37:14 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace25ef-bab6-0a2a0a5309dd-0a2a4501ba7e-38 for ; Tue, 13 Oct 2026 14:37:14 +0200 Received: from [209.85.208.49] (helo=mail-ed1-f49.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace25fa-5984-0a2a45010019-d155d031c8db-3 for ; Tue, 13 Oct 2026 14:37:14 +0200 Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-6aa9164072cso4169884a12.2 for ; Tue, 13 Oct 2026 05:37: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 4fb4d7f45d1cf-6b1c6df3794sm2284214a12.32.2026.10.13.05.37.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 05:37: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=1791895034; x=1792499834; 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=/QrB9/Ew6Sxj4YNHE/qGuA6q1KlvGkxTi9ld3Z9JK2g=; b=aojU7Gzyj3zvq9UdDP6ZIIrgyRjFAMgueGj4awS3+IIf+hSagfLnGkAhcCKUH5jlJA bgAHiX24sqiFqHgIrTn/uBsPkDbSZhC1eDsaK+khWgGz3syOTwffeK2kL8c+1KyStD7l 9UrgIlCsXtFULUfp6pFsx32SUZlWlsA8/5tO0HPnOJ9XrfOcCh28XWojxOXR9UKl0YNK mnqn9MFBNd5Bu29kjBM3lPJv2qnUDqrLr3TNMeGXzrLrTpryGCtX95d5i+Sxql0pKHzX gLfDbSrg8eLmtjbRAaLEOfO6kkMPJRz/EvXSWP1116yfk7Mk3a+z+7ZPzGwnH0YYktSx iy6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791895034; x=1792499834; 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=/QrB9/Ew6Sxj4YNHE/qGuA6q1KlvGkxTi9ld3Z9JK2g=; b=0ooGEAmEsCDdwTSd0YFVjrIQR4GT1vlXYhBbnxDjobhOF8ZtAgMZrPKSi3DIAVkA2J M3wv8LNqOOSQ7ROgsfwsmNi/qfvW1LV2F8QPaJgvwV6FVizyDsfe7sOGcyueiFEvKDPr Bk358e9edNXbulQdJvA2oWLPzAkfkRJo+Bx7kIwMDNxw/bnY8/MoB6u+tO+I9o5zA+GF wnCBVz6NgTi95viQye1ds9iZCVIcr3kF9iEN4mY52UnRytqzCtKa5/Ehan6GA61LwbX8 2cjuzk5mBmN6BmpUmQGc6XDixMK+Nj5W7EZ+mUUn1jriZhg2VkLHDqxOjWVDLhmzeVZo lp+A== X-Gm-Message-State: AFq9FYLg5f1707fWJoPMurzqfx6Ir0tX+d0GLNixO6TE27a8jaa1DZ0r O+RO3UpVhikYP8Cob+haIFqLiXQ2gr6NR7EO7ADiNRyQt8yNS4sIpvppznC4BUc/0g== X-Gm-Gg: AYBFou1yDqAp187GG0yyTQzrSArEblFIk499qDcH8q9KgEJ2JgG3d3alrkNRqVAxihF aoZB9whdY93C+YgRuwVyo6EEws5GGoMSjFIp/Yu5eGk/julIHhM+VKoRCSuLVSVKvppo41gw+GC nhMKsqVxdHImy0G5JPik6UE8BGk6K8nhiSinKeeKwGr1UuFRKHw4blOA+yX/yLHx1Br/yq/lVV2 THIm4E+U9KySPa85IRmVBtYbpKTvN/3lthqbwhIcmaIA+ereBxqu1/6as8CI+B7AwlQarH0yMKU X+h5hBxZk8LMrhrN6Cog/TZKLPbHoXZj2EnLn2lskWZgL/ioaaWVFACfjEbp/cwo/GbbnZ+xNce gQIJuxn2ngwsiVFNaGVG5+NMTgv4/VFm2Pm8s47tIte2fepqLEn2QdYte2Ovsdy+7IHoamSXcAn Xf991ybo4yOrbxA5sFzOmSYZWIIaysFVqa7ELXInbLSthX1V2YVZ3sShgkjojq1vkXeedQYZpSC m4qcA+/6zl/ClpE2PAEOJ+aIHQ2c1YNb0AiQ5FN0XKam0nL3dBmtzAy7W+HZA== X-Received: by 2002:a05:6402:2351:b0:6b1:b626:5bd9 with SMTP id 4fb4d7f45d1cf-6b1b6265e2fmr5235342a12.0.1791895033213; Tue, 13 Oct 2026 05:37:13 -0700 (PDT) Message-ID: <870ae4c3-9776-49b0-bb62-5db71c9f6192@suse.com> Date: Tue, 13 Oct 2026 14:37:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Dmytro Prokopchuk1 References: <5b5cccc8bbbc4c87fc99427eb4c1c413@bugseng.com> <96319798-7cf6-4905-9b1b-37bb6a41bdcd@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-d62444/1791895034-BFE68757-28CCB2C8/10/78276251493 X-purgate-type: spam X-purgate-size: 2935 On 13.10.2026 13:46, Nicola Vetrini wrote: > On 2026-10-12 08:52, Jan Beulich wrote: >> On 09.10.2026 17:37, Nicola Vetrini wrote: >>> On 2026-10-05 20:56, Dmytro Prokopchuk1 wrote: >>>> The R11.1 safe cast only matched void noreturn (*)(void *). Accept >>>> any >>>> noreturn function pointer converted to a compatible function pointer. >>>> canonical() covers typeof destinations, and >>>> compatible_deep_unqualified >>>> keeps the parameter and return types aligned. >>>> >>>> Signed-off-by: Dmytro Prokopchuk >>>> --- >>>> >>>> This patch tries to cover both of these: >>>> >>>> 1. eclair: widen R11.1 noreturn cast deviation >>>> https://patchew.org/Xen/c6632dd805a119aca54b9d1ae2eea68ef9c1334c.1790674358.git.dmytro._5Fprokopchuk1@epam.com/ >>>> >>>> 2. Eclair: relax "noreturn" function-pointer conversion deviation >>>> https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com/4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com/ >>>> >>>> Test CI pipeline: >>>> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2914802667 >>>> >>>> The only one Rule11.1 violation remains, which is covered by this >>>> Jan's >>>> patch: >>>> x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() >>>> >>> >>> The change itself is fine, but the aspect I'm concerned with is the >>> following: if you have a function marked noreturn, the compiler is >>> entitled to >>> essentially remove any code following it, so in principle this could >>> be >>> the case also when invoking a function pointer (i.e. the compiler has >>> no >>> obligation to retain code after a call to a function pointer that is >>> actually a noreturn function). While this in practice may not happen >>> often (e.g., the analysis done by a compiler is probably too shallow >>> to >>> actually infer paths where the function pointer is only ever assigned >>> to >>> noreturn functions when it is called), it is still not completely true >>> to say that the behavior is not altered by casting away noreturn. >> >> With "behavior" here you mean that of the compiler? Because Xen's >> behavior >> won't change if the code following such an indirect call isn't >> eliminated. >> It will "just" be unreachable code then. >> >> That said, ... > > I was more worried about the other direction: code that is expected to > be executed by the developer that is instead removed by the compiler, > with (rightfully) no diagnostic. Clearly if code is not removed it would > be unreachable, but such that a static analysis tool or compiler will > likely not diagnose, precisely because the attribute is dropped, so > there may be missing diagnostics. Hmm, interesting. The noreturn attribute isn't visible at call sites anyway, so I don't quite see how that would be any more unexpected than for a normal (direct) function call. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 12:52:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 12:52:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447824.1663675 (Exim 4.92) (envelope-from ) id 1xGbza-0004Ju-Nc; Tue, 13 Oct 2026 12:52:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447824.1663675; Tue, 13 Oct 2026 12:52: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 1xGbza-0004Jn-JT; Tue, 13 Oct 2026 12:52:30 +0000 Received: by outflank-mailman (input) for mailman id 1447824; Tue, 13 Oct 2026 12:52:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGbzY-0004Jh-Oy for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:52:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGbzX-00DNiH-DX for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:52:27 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace2986-8faa-0a2a0a5109dd-0a2a4503af26-20 for ; Tue, 13 Oct 2026 14:52:27 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace298b-fae8-0a2a45030019-a237832fb85a-3 for ; Tue, 13 Oct 2026 14:52:27 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id E902E4EE0235; Tue, 13 Oct 2026 14:52: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; 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=1791895947; b=X+FmH2uirVzikP3bCv1p01jalAUJEHtotz/+Wm6DfROPkLkj/E1kFwOqPWGF+bD0Pz0Z 2qy2eQ4x5MqgzC09YYAFcIjhNaEfsZjD+pzOGWk7WMicxo3LPcCz8GBjTIR0f4lSxYha/ /jKM0MfW6kXooJ22WMWoTBqYoIlHGlmKM8Bh97K1YroewO2SuZANjmZHOVc1M2VJXQuzb l7vnkgf19sikQW4rHObgWCyCYbII5TbLHmh/R1MF1aZ1scDmEbVSKyZODg1wwAyR4r75u GTl5wGwyI08dJ1GaRFj1kMpcOgN9HlxG/C+xLt5Uk4mirNPzi5E92KaQxtPKJdTmMLi6R AdMJuKJ06mNaiNCGFKZsOL/Gvq1gEiZk2nJ/kUqLaDnHhxSMAjCdJU72pCHS2evGQAMJ9 zjHFUC0zzGy0ha9wOMcac4g0wDASFXXOkMqmSBSk0k200UjDIWWK336Tc/39XiMQFzgFt +czrelyKqlSnau4zEaPmRTRg/Tsoh0zIM2pc8IPAL1hVjAkBBp0Im94wcBnD0uBTehRnW fkDAv5U0JptDtD/bczePyHpAvvFA1reCEDfejQr76Vn/n8mFtYnBywJsV6hpzldPeXWNI dSHToifjiJdt6nmnz48FH4i0l0QiTVVWnb6kHFpk4tANWLAjdJ9epeBzeGA577g= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1791895947; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=Scx/D5lEEBOI7l8XQtkdHK7+kkeAjqtP4oi5wrvXWfA=; b=eXnMag59LyfBjMOtSLanfDiecS4VEZjD2Qn6DnE/AxXu+aZyoaofvxEJxQBiDpyBG0Cv E55GB1w03ufez3wtjbNjxhWmAz7ZjX6UuvqBkFHPs0SK+9BblvBIwHnAj3D3RVValYATm 6+IRyLyflDBaVcmXdCB4Ts9yEw5FvAv/Uh5vjbrHSTCw20qMSRcuSbEk9MUfkWagvYka7 UoRrYY6lWmYinLda5hvFLBIRg7gnfO2avuNOlK6xCnYKGYK7ub4sE88cC6aMKM31de8lC AKEbcOeXzd9mY8uRHCVacFjxszr4RtR0H2XDj4PHDELnUZqVi7ZSwvE1kVB44Y9cNt9o6 v7ebBiPxQAOEB3obTVZ783R0sjiS1nzODkwzlnhnIUF00z8jSzjnnTScdJ/OK67T76wdF v2RLRo94sCHiLbwO1zEkMgyXTcakijLuAAcNUvv0rmmwPBai+rOGJ1l0CJ+GPAA3su5zS TSaQ8m1HsFB5KIWiFtdN9cnJpk1/b/I4Kdvf1X50VH8C3ocaQObd039/NDue3ib+f12Bc HSLTy3F+luJ9Mr8wAUDnxy/vAradN3JZ9TUaFctyfBMF2Hr789BTAR6vAI11UVk3hDFGw keRGQ83XFTHmBjSnQdYVSkv9jRckr+jFqG7svvB+yXEsNtm5wDqzzdFLQBqn08s= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 13 Oct 2026 14:52:26 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Dmytro Prokopchuk1 Subject: Re: [PATCH] automation/eclair: generalize the noreturn function-pointer deviation In-Reply-To: <870ae4c3-9776-49b0-bb62-5db71c9f6192@suse.com> References: <5b5cccc8bbbc4c87fc99427eb4c1c413@bugseng.com> <96319798-7cf6-4905-9b1b-37bb6a41bdcd@suse.com> <870ae4c3-9776-49b0-bb62-5db71c9f6192@suse.com> Message-ID: <615008ea29f7dc71625800694c785f9d@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-33051d/1791895947-760FE4E9-2421FDDD/0/0 X-purgate-type: clean X-purgate-size: 3842 On 2026-10-13 14:37, Jan Beulich wrote: > On 13.10.2026 13:46, Nicola Vetrini wrote: >> On 2026-10-12 08:52, Jan Beulich wrote: >>> On 09.10.2026 17:37, Nicola Vetrini wrote: >>>> On 2026-10-05 20:56, Dmytro Prokopchuk1 wrote: >>>>> The R11.1 safe cast only matched void noreturn (*)(void *). Accept >>>>> any >>>>> noreturn function pointer converted to a compatible function >>>>> pointer. >>>>> canonical() covers typeof destinations, and >>>>> compatible_deep_unqualified >>>>> keeps the parameter and return types aligned. >>>>> >>>>> Signed-off-by: Dmytro Prokopchuk >>>>> --- >>>>> >>>>> This patch tries to cover both of these: >>>>> >>>>> 1. eclair: widen R11.1 noreturn cast deviation >>>>> https://patchew.org/Xen/c6632dd805a119aca54b9d1ae2eea68ef9c1334c.1790674358.git.dmytro._5Fprokopchuk1@epam.com/ >>>>> >>>>> 2. Eclair: relax "noreturn" function-pointer conversion deviation >>>>> https://patchew.org/Xen/6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com/4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com/ >>>>> >>>>> Test CI pipeline: >>>>> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2914802667 >>>>> >>>>> The only one Rule11.1 violation remains, which is covered by this >>>>> Jan's >>>>> patch: >>>>> x86/kexec: address Misra rule 11.1 violation in >>>>> machine_kexec_load() >>>>> >>>> >>>> The change itself is fine, but the aspect I'm concerned with is the >>>> following: if you have a function marked noreturn, the compiler is >>>> entitled to >>>> essentially remove any code following it, so in principle this could >>>> be >>>> the case also when invoking a function pointer (i.e. the compiler >>>> has >>>> no >>>> obligation to retain code after a call to a function pointer that is >>>> actually a noreturn function). While this in practice may not happen >>>> often (e.g., the analysis done by a compiler is probably too shallow >>>> to >>>> actually infer paths where the function pointer is only ever >>>> assigned >>>> to >>>> noreturn functions when it is called), it is still not completely >>>> true >>>> to say that the behavior is not altered by casting away noreturn. >>> >>> With "behavior" here you mean that of the compiler? Because Xen's >>> behavior >>> won't change if the code following such an indirect call isn't >>> eliminated. >>> It will "just" be unreachable code then. >>> >>> That said, ... >> >> I was more worried about the other direction: code that is expected to >> be executed by the developer that is instead removed by the compiler, >> with (rightfully) no diagnostic. Clearly if code is not removed it >> would >> be unreachable, but such that a static analysis tool or compiler will >> likely not diagnose, precisely because the attribute is dropped, so >> there may be missing diagnostics. > > Hmm, interesting. The noreturn attribute isn't visible at call sites > anyway, so I don't quite see how that would be any more unexpected than > for a normal (direct) function call. > For a direct function call the prototype would hopefully be visible, so it's easier to diagnose. For function pointers the prototype may not be visible, but a static analyzer can in principle do an over-approximation of all the possible function pointers that may be bound at that call site and derive their attributes from declaration(s). In any case, an argument for allowing the deviation may be that code coverage on tests shows that the compiler does the expected thing on the tested configuration: where code is expected not to be removed, it is indeed preserved and reached, and vice versa. -- 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 Tue Oct 13 13:48:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 13:48:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447910.1663855 (Exim 4.92) (envelope-from ) id 1xGcrZ-0005if-ED; Tue, 13 Oct 2026 13:48:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447910.1663855; Tue, 13 Oct 2026 13:48: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 1xGcrZ-0005iY-Bg; Tue, 13 Oct 2026 13:48:17 +0000 Received: by outflank-mailman (input) for mailman id 1447910; Tue, 13 Oct 2026 13:48:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGcrY-0005iS-Ft for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 13:48:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGcrY-00000003PO1-235p; Tue, 13 Oct 2026 13:48: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.98.2) (envelope-from ) id 1xGcrX-0000000HR2C-24ev; Tue, 13 Oct 2026 13:48: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=8A5W41pXzvY68nzpH7b8XvE3dy9RwW8LbQInY1wdP1c=; b=U+WWr6nY9wemN0m1rvHffEIKWH PIC4DLUTWnIBjsWnRDgH/HSQmA47EPBO3orbPIOPppGFQgcyGA+DOcLec5B9/xmuuZaZDTe2EkLcF F7tYKGeRzaa48dV9KmwzzZRPFY82xrsus9K0mCqXMSrT6dIA2vTQ3BARwZ3yBuaaFNgM=; Date: Tue, 13 Oct 2026 15:48:10 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <575ec1bc-764c-4016-a584-a79e57817d9a@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <575ec1bc-764c-4016-a584-a79e57817d9a@suse.com> On Mon, Oct 12, 2026 at 10:21:55AM +0200, Jan Beulich wrote: > pvh_populate_p2m() needs to populate RAM according to the initial map > established, prior to any stealing by pvh_steal_ram(). Subsequently the > invocations of those functions will (need to) move ahead of > pvh_populate_p2m(), so what to act on is no longer Dom0's memory map at > the time of invocation. But (most of?) the uses of pvh_steal_ram() expect to access the stolen RAM, and hence using pvh_steal_ram() ahead of pvh_populate_p2m() is not a present use-case? I assume you have a further use-case for pvh_steal_ram() that wants to steal a range before it's populated, which might be worth mentioning here, to add a bit more context? > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > > #include > > @@ -413,7 +414,10 @@ static void __init pvh_init_p2m(struct d > } while ( preempted ); > } > > -static int __init pvh_populate_p2m(struct domain *d) > +static int __init pvh_populate_p2m( > + struct domain *d, > + const struct e820entry *e820, > + unsigned int nr_e820) > { > struct vcpu *v = d->vcpu[0]; > unsigned int i; > @@ -421,15 +425,15 @@ static int __init pvh_populate_p2m(struc > #define MB1_PAGES PFN_DOWN(MB(1)) > > /* Populate memory map. */ > - for ( i = 0; i < d->arch.nr_e820; i++ ) > + for ( i = 0; i < nr_e820; i++ ) > { > unsigned long addr, size; > > - if ( d->arch.e820[i].type != E820_RAM ) > + if ( e820[i].type != E820_RAM ) > continue; > > - addr = PFN_DOWN(d->arch.e820[i].addr); > - size = PFN_DOWN(d->arch.e820[i].size); > + addr = PFN_DOWN(e820[i].addr); > + size = PFN_DOWN(e820[i].size); > > rc = pvh_populate_memory_range(d, addr, size); > if ( rc ) > @@ -438,11 +442,11 @@ static int __init pvh_populate_p2m(struc > if ( addr < MB1_PAGES ) > { > uint64_t end = min_t(uint64_t, MB(1), > - d->arch.e820[i].addr + d->arch.e820[i].size); > + e820[i].addr + e820[i].size); > enum hvm_translation_result res = > hvm_copy_to_guest_phys(mfn_to_maddr(_mfn(addr)), > mfn_to_virt(addr), > - end - d->arch.e820[i].addr, > + end - e820[i].addr, > v); > > if ( res != HVMTRANS_okay ) > @@ -1352,6 +1356,8 @@ int __init dom0_construct_pvh(const stru > paddr_t entry, start_info; > struct domain *d = bd->d; > struct elf_binary elf; > + struct e820entry *orig_e820; > + unsigned int nr_orig_e820; > int rc; > > printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id); > @@ -1389,6 +1395,15 @@ int __init dom0_construct_pvh(const stru > > iommu_hwdom_init(d); > > + nr_orig_e820 = d->arch.nr_e820; > + orig_e820 = xvmalloc_array(struct e820entry, nr_orig_e820); > + if ( !orig_e820 ) > + { > + printk("No memory for copy of E820 map (%u entries)\n", nr_orig_e820); For some of the printks during dom0 PVH construction we already print the domain (%pd), and I think it would be good to print it here also. Some not-yet-upstream uses (hyperlaunch) create several domains using this logic, it would be good to easily spot which domain triggered the errors. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 14:27:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 14:27:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447947.1663889 (Exim 4.92) (envelope-from ) id 1xGdTH-0003re-EP; Tue, 13 Oct 2026 14:27:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447947.1663889; Tue, 13 Oct 2026 14: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 1xGdTH-0003rX-BJ; Tue, 13 Oct 2026 14:27:15 +0000 Received: by outflank-mailman (input) for mailman id 1447947; Tue, 13 Oct 2026 14:27:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGdTF-0003rQ-T0 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:27:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGdTF-0099Kh-9v for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:27:13 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace3fbd-e002-0a2a0a5209dd-0a2a450ce95a-16 for ; Tue, 13 Oct 2026 16:27:13 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace3fc0-f479-0a2a450c0019-d155802fad2b-3 for ; Tue, 13 Oct 2026 16:27:13 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a16af2a232so24596145e9.1 for ; Tue, 13 Oct 2026 07:27: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-4a1a1feb78csm192807965e9.0.2026.10.13.07.27.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 07:27: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=1791901632; x=1792506432; 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=akbDdWRD+d5yo/stLZ0cw5wRznLEdWpmoEQlhxtS5w4=; b=K3mvMbXoUgPO4+Rk3nfilZPIXPEmZfRwnfkxiUJg1GX22tFLXY3BTh1/XHzJmHd2Lc 3L8fq3kL5XxDaV4oY/ja5XgzVlEFjmKrqkX9qVw071kb92kUocmCr43tX9cynjKFTvDd wxTj7vackTGkrIDmUgTZCk2LeHZNFxLcx2kjgK3PB5I19OsSNmfTwNts5LF2h1DGAH2a /komayehikDDFGWBpF8k1x62x++/Lnfwyg2C3/Rznj/dRNn08+MXHYfELAtf7dJ7UW7J mYigF5SxjzXmdou54zNQ7ebZJN0qFuqNcQnQlZSB4fOyHtsai7Y+y+v0VKrJB8/KFnp9 JVOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791901632; x=1792506432; 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=akbDdWRD+d5yo/stLZ0cw5wRznLEdWpmoEQlhxtS5w4=; b=Qmb3OiiN663Dm7BjnbHBZpZR8Qr38JU4LnGMHe2Q+IXGBIkAiaYKOoeSb+dGPrPpvS RN2FwrP5YVpOVC1k3VtfWapQIUGCsCHGM6r4mvOP1oPc2R0YJnnQ9JGCNbHrSAGHqok9 RAgv/ZmA3G9OwPsH23KKAaitZQLqtxVZxXWiZjmfhwn9j74rdD9HaGTPREz7zIqAsAYQ J+rny9uUIgvnQ+M6TE2m586tll0AyauUbuo1IF3zfoR09BNw8S0NnWCYkPHb/wiO2XPP IZE6BqXaMVpxJpdWPiIk6t7eHRGz8byCOGBURi5UZvn4YkLZSSme5xLv/nxpHpM/rFWf ikSQ== X-Forwarded-Encrypted: i=1; AKwUvBweLP+EkiCJ74zi1qS68n+ZiiP5Da3c44PZN35pXDK/gY1Jl/jstVlvHiv2p2Z80qPMu0MPYjBLlM0=@lists.xenproject.org X-Gm-Message-State: AFq9FYLUi+WpyHSbYsY+nsvUtFzULKcjOFyHOeQ2iWSGc/jE/Oa9sE2K 1AsIsS3U+EWEXHHvbXUAAVpngVFru2AME6nEId3ZNzvTecGzJO+kaxW3rwwcbK67vg== X-Gm-Gg: AYBFou1bpExwhcye6u9FafdqUi32zySCi+hjENcvGrzXsRUbNpwZAffENiBiEWGaY84 GvB0La/conm3xoq7VdlKHBuF0g2rLITIOMdcADV9BPpTQDT5Mmg9oRVvU8HDBa4X+D2O/kMaM0V efmOpwZgy+lRLGHWZSpjLF+WgL8muo/ZpdneSEwnn4g30lngyGfYL1nB1ZltBFA5ZeMQg0uuugQ FgbT9qmm7dHT6K56EFzZbxtJpQCgh4jeEju8dx8BwjBncSitSWZKMXSUOZXz0qUqzOLdbuxmChe omH7CIV2HE4CztYztqknzJtFShCyYOF208DiAfTVf6HxWpPNOo2jaVufshCNIjF9kFrm2guYYaR Epvhi/2LNrsdXC/XZ4wXkvD/D3rOERYYlsyyipdzzwtVIG7NuhsUfxtPcwzxelxJa2m1lHT0jNR RaB1plSwopPPeCuWVTeHcv8lNlAGXmlZ70xwt0+/eJpqoEfGV2Yaw4kDFz8MfRDIqDD0/dqmh1R oXUd0B2pYNFHZnjZxy0IgifwtB60z3O1AD7+8l5SZes70i+bH3sCSZilHTj+Aaa X-Received: by 2002:a05:600c:83c7:b0:4a1:698d:3044 with SMTP id 5b1f17b1804b1-4a18e493020mr249319875e9.11.1791901632356; Tue, 13 Oct 2026 07:27:12 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 16:27:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6] 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: <5d6d418ef2c89c706e220d38f230a351d4266d66.1790779581.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: <5d6d418ef2c89c706e220d38f230a351d4266d66.1790779581.git.abdelkareem.abdelsaamad@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1791901633-52331A5B-25A680F4/10/78276251493 X-purgate-type: spam X-purgate-size: 3333 On 30.09.2026 17:50, Abdelkareem Abdelsaamad wrote: > --- 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, true); > gdprintk(XENLOG_ERR, "invalid VMCB state:\n"); > svm_vmcb_dump(__func__, vmcb); > domain_crash(v->domain); This is the kind of use that we're seeing for a function doing full checking. The two pre-existing uses, otoh, are getting too expensive with more checking added. Therefore what we (the x86 maintainers) think is there needs to be a split: Only checks that need doing ahead of VMRUN should be done there. All other checks should be done only for diagnostic purposes after a failed VMRUN. > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -327,6 +327,70 @@ 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 Encrypted State (SEV-ES). > + */ > + case X86_EXC_BP: > + return !vmcb_get_sev_es(vmcb); For this it would, btw, be helpful if the testing table also had an entry for #BP. > + /* > + * 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 Event Injection. > + */ > + case X86_EXC_OF: > + if ( vmcb_get_sev_es(vmcb) ) > + return false; > + fallthrough; > + 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; > + } As said before - this wants to check the live CR4 value of the guest, not what it may in principle enable there. While it looks like Andrew doesn't fully agree with me here (because that's not how hardware behaves), I can only point out that the way he wants it (deriving from the raw policy), it would result in behavior changing for a guest migrating from a Naples host to a Genoa one. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 14:31:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 14:31:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447955.1663898 (Exim 4.92) (envelope-from ) id 1xGdXl-0005Xb-Vh; Tue, 13 Oct 2026 14:31:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447955.1663898; Tue, 13 Oct 2026 14: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 1xGdXl-0005XU-Sp; Tue, 13 Oct 2026 14:31:53 +0000 Received: by outflank-mailman (input) for mailman id 1447955; Tue, 13 Oct 2026 14:31:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGdXk-0005XO-1e for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:31:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGdXj-00A336-AX for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:31:51 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace40d6-2eae-0a2a0a5409dd-0a2a4507df2e-8 for ; Tue, 13 Oct 2026 16:31:51 +0200 Received: from [52.101.69.98] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace40d6-b4ea-0a2a45070019-346545621ffc-3 for ; Tue, 13 Oct 2026 16:31:51 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by ZR6PR03MB911381.eurprd03.prod.outlook.com (2603:10a6:910:cf::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Tue, 13 Oct 2026 14:31:49 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.011; Tue, 13 Oct 2026 14:31: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=cgx1x790IPBdiAKuOqWzN3noTh0IGfl8x6HEEh74FM5X4WUg3xP7SX6u5gaRt7jM9t9Bx3Iy/BUd9ycKTBi1VdgEHyvcLBeQ0LWpPrLpoYV6IynXdopWhAjavRCyXSIUPZYyfy1qZHsB7CcUINNp3fzuMsWaCsdGpBGRCRerm9I08i1arjktn2hgrOBvepxdtRoAUxqBcXpKwndGFhNG0k5F75v/kVnDOc/OAvdtiVmaYXxRS+cWMVOwiQE3msEwHVz+35/lZe/PNsE/aJ56DFTVbrQTzx/nXS6eJGdEhOFWJylUkDcGNDIuFHMPNxGPhAWPhJDE3Iv8bfGWp/0SFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b3Uhm2zvsPCAbaSM0CKwi4QtczOfzsFD9QcZ3PO/kHQ=; b=Jc4ShCWlDwyF6/ppK3eiUbIs9HjLhw6XtcBZlpUkO7y/2lIqw7LvGhbQTpBhNXmA75oCjfPLbKNErcnGWTTafLlLrh9YBKQkhiczrs+6UkxYOnhB+iqiWgvWQ2SFAlagHZoXrympiIo0cQ1PXy/FRZkkZPB5lLyH/trYVG7B92A6jHdBd5TxZUK0yhpnTPuDoPxgVaaPQRoQ3EAP9yY/mxvQWO9y8heOyQzKrINxMSsLwURuKouaU6IstoiWpA53+/yc13gQoZ/nARUoAVw6v7JXeoa6NUGxEaIY4NB4b93bmYLACoCMHcJmFvwqg9mGWj1JXuIsRLMojlkmwnqhWg== 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=b3Uhm2zvsPCAbaSM0CKwi4QtczOfzsFD9QcZ3PO/kHQ=; b=rfYrKrRi8Xc5i/NdsbGzAuhO/D5iWExj4gqgKzLVYvv4gHqHI7J+vREiHFdZoS8efV8cRFX9Egg0ZLedNHXPifzwBVyVhQNz/nRJkIbi6oWMeDVmbOtYqJdOycvVy9HjLLsXhHm2ow8amTXKrwD9LYLZ+hemuBahmsHUIxYNWPGWjFMwYmCnjAm1Pe78tXmK6ZM/NjVYnFfKHFlFtVo3b4a4PnDMLzPyQQ+z+E8n8belsYBo0RNXxUhSvxiwdXaOdU8WHxQnJwOAm+TGvm9vuF349yo1Km9Zv18IQwlLKTiNiLdrabcdJTZvvh4TRXlDABnoeLJxwSD/6jmOZEJ/6A== From: Dmytro Prokopchuk1 To: Nicola Vetrini , Andrew Cooper , Jbeulich CC: Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8 Thread-Topic: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8 Thread-Index: AQHdT/FUuEZ9j2ZjeEWRZmF5vcrM7rblkEmAgAAVJICAAARVgIAALQ0AgALNOoCABURJgIANtvMA Date: Tue, 13 Oct 2026 14:31:49 +0000 Message-ID: <5d4ea9f2-6340-4c3d-a8d1-a43171e73bf7@epam.com> References: <4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro_prokopchuk1@epam.com> <0a286fe9-2133-4f28-8fab-59f4e51d1484@suse.com> <446354d93ae04a07b86d7293705d7e46@bugseng.com> <0373fcc0-5bc9-4140-a2c9-52a31c7e42b5@suse.com> <2a8557d7ba88e95ec75148ff180ae0a0@bugseng.com> In-Reply-To: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|ZR6PR03MB911381:EE_ x-ms-office365-filtering-correlation-id: 801b30e3-905f-4fa0-8a6f-08df2936b7aa x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|42112799006|1800799024|23010399003|11063799006|4143699003|38070700021|18002099003|22082099003|56012099006|6133799003|261009223027099003|4133799003|3023799007|10067099003; x-microsoft-antispam-message-info: mqzb8uPzYdCCf9gfixImM9gnHaKxaREsT1WHnYJUKMH1p9tI4YoD2YpN7P0TZXn7jPrwTWjWfXVh++8ry0QHip6PI6ScrlsguHZpQJQGRFEpLYcSR+sulMyAOm0+tKWUCQZxXto50xneTPS1XyykEfUWHTpc5K3XLh6mp9G09SHpw15SxzfJ7diT+O5uP8N5oQxq0lVCWfHnFcidMTsDxOyPDs7cPQ38rSTIVn6HGoc3mkxft0iuLNEaHgASVWTkjtdXAxhOIYMt2MmuFkpjuaJesSlo25prlrJOSvkWVYeVnPrAotXypuau9YD2EgAqNvWckQ32gC59O41CTs3ZpKQA0uRQzMFlB+53k5j4iAebslf/HNIj+qeaXzxpzlXPVfP4GtIhSdMaP5WsJn1N4Hd0z9xKTjhBBiRkp7wl3tp8HO+KzIpuE+BEhpQnB45T9H/CgKhHqLExRZLUIEgbuOvwzhrK+wDgm6bl+a6iD1BhP5lxo28bHdlxG57XwUg9dggsTfCug3e+Z/oncaND5iQZpl7VxbSGzeGnK8HySRxdzatNbaJA3JKpusMln2cJR9DeiNcmXSEyPsf2uWQy6PHyLly3KXnDZkDU4Lj0qcGF+qZndYwx+Mva/guoxeR6AvS5oLpk8oqdYsnFL3lEcLPKgQwPrTwQcB+vO54Oo0k= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(42112799006)(1800799024)(23010399003)(11063799006)(4143699003)(38070700021)(18002099003)(22082099003)(56012099006)(6133799003)(261009223027099003)(4133799003)(3023799007)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dnRqUUgrb1hUTTdGL1BSTTFyZkd4d1hObTJoMnFUdElYdUJReUtjd1drampy?= =?utf-8?B?RXBZQy8yUGtGT09ZRGNCOXlmOEhPc1pmSS9qZmJKbm1oTEdFOUxXWmNEWVNq?= =?utf-8?B?aUxmTVJvTXVXc3FjMWhpaDBBUzNCQTZTYWg2NGZuanU0N05nMnZWenNIQXBU?= =?utf-8?B?eFBpdEo1dVhabGh6UnRaSkFxTmp0YVh5NnltVGg4R2RZY0pFT3ZlTGR2V2Yx?= =?utf-8?B?UzIraUN4TDBreHVuV2ZUSDFSZXM2akpmU2Izd3NsTlpkclkvd1BQYVRaSC8w?= =?utf-8?B?dnlucm02djR5dzdOcWZNS0FHVExGTExIMi9wd0tXWlNybHAwQ3h1OFhaNDJM?= =?utf-8?B?aTlPcXkxdGZxSWZHOGhVQzB4NDRwU2UvTXM2N0s3YmlrN09SQ1htNmNHLzJ6?= =?utf-8?B?NXkxVHY5RnVtMHp4dkFYT0RDaVM0VG13VktZWWdVTC9qQU9iRUJKWE1INnY3?= =?utf-8?B?eVZ5dlU3UmNMYS9PNWZ3ZTVyaGo1d2J5T2NkMllsd3dVdVZHSHFvejl5d1hR?= =?utf-8?B?UFlJeFVMRmozRksyazZIMzQwSXBhaGxVQWtjd1JPdkVFZDZkeDVNbjlhU2c1?= =?utf-8?B?Yi9zZlpncnV3YUtIUnRzcytSNHlqOUY1ZWQ1by9mYVFueU9GZERqL25mT0dl?= =?utf-8?B?TVRyeUgyVkcrY1ArODJ1WDJLZW9DZm5aQUtrelhHTGdyVXMzOCtMNWYxSXlm?= =?utf-8?B?UzQ3NzNvbDBIS1JxN1dYNVBwN2FUbGhYeFR2K1pqQXZERGZZZGJZNGh3cUJN?= =?utf-8?B?NVZFdU1oaW1LU3cxM2xndHZ5QmZCM3gyempkVWZJRFAxZWxJdjJTSXBpdlJP?= =?utf-8?B?ZEpDQlFyMHV3NlM3S3FGQkx6WXZJN0FOUzFCL1F1bUpYYU42WGFGeWdMVkh2?= =?utf-8?B?QzRTRlZvWW0ycUwzY1J4R3BxN3FsUGxIRUV5Zkl3Y2RMN3FBZFJjME5pT01v?= =?utf-8?B?MlliZ3hZdURIMU5NUENrSmp0alFPN1lZUDA4YUlpY04xNkkzWkE1Tkk5V3dZ?= =?utf-8?B?QWZGU01WVDJSdXdXMW80WkU0cXUvclZPZnlrZlhvb1E2eXphU3FEL2g1NkIw?= =?utf-8?B?cUpTSHhPUGh6WkQ1ZWZnUUVKSnlSZ3JiVUhidWNwN08yQWJLRGJtNmp0M1FH?= =?utf-8?B?Rmdmd0NxeGdmMXdwRXJmWUtQSUZpdGdDUk5sWWdzdXh4d01SNlhzU01IOEFJ?= =?utf-8?B?NGx1NjJEOHg3ZW5xV3dvN3gybDYraGpOMGVYZjBpdHA2ZXQ0TnZybEVnSzVD?= =?utf-8?B?STNJTWNoTStYa0x4MXV6ekUwaGpjYlNES2NCVkhRRzdjYWt4L01GN3hzNEwx?= =?utf-8?B?WkRyZ0dBTVNFaS8rcmZubVcwb1lGTmpXSDYwdzJDcHBsblFDZ0FhK0FtWGh1?= =?utf-8?B?M21TWnlmdTFIQVZPWkloVHlVb3hpbkh1T1BUWVZnTGh6d0FZY1BHVjBaSVZT?= =?utf-8?B?aDdUa1BwbDFJME4rMDArYkxlNG5hQ2hNOWlKZzJVbFFvUEZuMzgybVErM0R4?= =?utf-8?B?NWxRM0thNGhHS25kbE1kc0RRSkE3amp1MS9uU1RZaXZBZElYOVpkTjIrTFIr?= =?utf-8?B?cUdpeTBKWDZNUEZyVnhBeUFPeUZBZHI1WmZDdld3RFdRSm5XVVEzU3c2Vi9v?= =?utf-8?B?dTlhMVNCZFA3ZlJaUXlpL21yL1gxa29ncHFVdkN5U2tjWDc1TGYvRGdvRnR5?= =?utf-8?B?WFdtQm5oQ013aVpuQmhrWlc0dUQyMEZObUI5ZjhEOHVkSnRsMHJKUXI0c3VN?= =?utf-8?B?eW4zcW41eWoyQ3lBSVBSSTk5M2o3VDNjVDYzbit0NnQ0dTRqTjNMenh0Wktu?= =?utf-8?B?SHk3cE9jYmJoYXZnaUJvZkJJdmZlREZndVNFZTUyOGdNQzMrS0N3NnBoNlBh?= =?utf-8?B?VmVrV0dLT1RYdnhUUkNvaVhYcG1hemY2NUo0ajVTc0JaV3pJaFdSanAwUTZS?= =?utf-8?B?Q0gvRWY2OHlkOEZyRkFVNzM0TFQrRDBza0c0SUVoSUozU1lHbUNWck5DaUc0?= =?utf-8?B?ODc1NGRkMVIxRGtJaG9JOVByWlhLalpwMWFibGo4em5BZmFCeEwwamh4Kysz?= =?utf-8?B?RXZmeGV6T3RmVERJS3lRSGlwVUpWeXYzWk1Ic21uR2VPb2I0bGJueGR1YWdt?= =?utf-8?B?dGxSM0ErQXVJYXdSMDlIaWFQRWJuZDFJd2FuSlByeVRlNjRkV1VHVEFJYVli?= =?utf-8?B?bmJYTGNEbTZQeExWbytqdFgvNGk1SUhSdEFQM09DTVJ1UHhqaXMwZmNDVWw4?= =?utf-8?B?cGE5bWRRaXQ2bGxKYlM3TS94UEtIWXlJc1BkS0FVZTJWdStWemZvNkNBcDNV?= =?utf-8?B?ZXVGb0JnM2JMb21IQWlIMnlUakw5ZUJ5M2ZlWGtVVzIvOXJnUmp4dXRjblFa?= =?utf-8?Q?5lZ8fp/pWd4TCbls=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <610BC2F2C5CB874082808713A41E1EBC@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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 801b30e3-905f-4fa0-8a6f-08df2936b7aa X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2026 14:31:49.6209 (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: Y4BR+CyJnkUfIyjdd1SU+lp4NMiUrtvrO2pShryKrbcLK9PyQ8tA43KS5QN0250VexepiMShmfg9fU+sJTQJrhdr+GDNwyJ+pIxh0c28frk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR03MB911381 X-purgate-ID: tlsNG-ef75cf/1791901911-378D1AE4-9BB82858/0/0 X-purgate-type: clean X-purgate-size: 5806 DQoNCk9uIDEwLzUvMjYgMDA6MDUsIE5pY29sYSBWZXRyaW5pIHdyb3RlOg0KPiBPbiAyMDI2LTEw LTAxIDE0OjM5LCBBbmRyZXcgQ29vcGVyIHdyb3RlOg0KPj4gT24gMjkvMDkvMjAyNiA2OjUyIHBt LCBOaWNvbGEgVmV0cmluaSB3cm90ZToNCj4+PiBPbiAyMDI2LTA5LTI5IDE3OjExLCBKYW4gQmV1 bGljaCB3cm90ZToNCj4+Pj4gT24gMjkuMDkuMjAyNiAxNjo1NiwgTmljb2xhIFZldHJpbmkgd3Jv dGU6DQo+Pj4+PiBPbiAyMDI2LTA5LTI5IDE1OjQwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+ PiBPbiAyOS4wOS4yMDI2IDExOjAzLCBEbXl0cm8gUHJva29wY2h1azEgd3JvdGU6DQo+Pj4+Pj4+ IGJzZWFyY2goKSwgbWVtY2hyKCksIG1lbWNocl9pbnYoKSwgc3RyY2hyKCksIHN0cnBicmsoKSwg c3RycmNocigpIA0KPj4+Pj4+PiBhbmQNCj4+Pj4+Pj4gc3Ryc3RyKCkgYWxsIGFjY2VwdCBhIGNv bnN0IHBvaW50ZXIvb2JqZWN0IGJ1dCByZXR1cm4gYSBub24tY29uc3QNCj4+Pj4+Pj4gcG9pbnRl cg0KPj4+Pj4+PiB0byB0aGUgbWF0Y2hlZCBlbGVtZW50IG9yIGJ5dGUsIG1hdGNoaW5nIHRoZWly IHN0YW5kYXJkIEMgbGlicmFyeQ0KPj4+Pj4+PiBpbnRlcmZhY2VzLiBUaGUgY29uc3QgcXVhbGlm aWVyIGlzIGRlbGliZXJhdGVseSBzdHJpcHBlZCBzbyB0aGF0DQo+Pj4+Pj4+IGNhbGxlcnMNCj4+ Pj4+Pj4gc2VhcmNoaW5nIGEgbm9uLWNvbnN0IG9iamVjdCBnZXQgYmFjayBhIG11dGFibGUgcG9p bnRlciB0byBpdC4gDQo+Pj4+Pj4+IEZpeGluZw0KPj4+Pj4+PiB0aGlzIHdvdWxkIHJlcXVpcmUg Y2hhbmdpbmcgdGhlIHB1YmxpYyBBUEksIHNvIGRvY3VtZW50IHRoZXNlIA0KPj4+Pj4+PiB1c2Vz IGFzDQo+Pj4+Pj4+IGRldmlhdGlvbnMgaW5zdGVhZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVXBkYXRl IGRvY3MvbWlzcmEvcnVsZXMucnN0IHRvIG5vdGUgdGhhdCB0aGlzIGNsYXNzIG9mIGRvdWJsZS11 c2UNCj4+Pj4+Pj4gbGlicmFyeSBmdW5jdGlvbnMgaXMgZGV2aWF0ZWQgb24gYSBwZXItZnVuY3Rp b24gYmFzaXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNpZ25lZC1vZmYtYnk6IERteXRybyBQcm9rb3Bj aHVrIDxkbXl0cm9fcHJva29wY2h1azFAZXBhbS5jb20+DQo+Pj4+Pj4NCj4+Pj4+PiBXaGVuIEkg cHJlcGFyZWQgbXkgMTEuOCBzZXJpZXMgWzFdLCBJIHdhcyB3b25kZXJpbmcgd2hldGhlciB3ZSAN Cj4+Pj4+PiBuZWVkIHRvDQo+Pj4+Pj4gZ28NCj4+Pj4+PiBhcyBmYXIgYXMgZGV2aWF0aW5nIHRo ZXNlLiBTaW5jZSB3ZSBub3cgdW5pZm9ybWx5IHRha2UgZ2NjNSBhcyANCj4+Pj4+PiBtaW5pbXVt DQo+Pj4+Pj4gYmFzZWxpbmUsIHRoZXJlIGlzIChhdCBsZWFzdCBpbiB0aGVvcnkpIHRoZSBvcHRp b24gb2YgdXNpbmcNCj4+Pj4+PiBfR2VuZXJpYyB0bw0KPj4+Pj4+IGNvdmVyIHRoZSBkdWFsLXVz ZS4gT25lIHF1ZXN0aW9uIHRoZXJlIGlzIHdoZXRoZXIgRWNsYWlyIHdvdWxkDQo+Pj4+Pj4gcmVj b2duaXplDQo+Pj4+Pj4gc3VjaCAtIE5pY29sYT8gQWZ0ZXIgYWxsLCBsb29raW5nIGF0IGUuZy4g Z2xpYmMncyBpbXBsZW1lbnRhdGlvbiwgdGhlDQo+Pj4+Pj4gZnVuY3Rpb25zIHRoZW1zZWx2ZXMg cmVtYWluICJ1bnNhZmUiIHRoZXJlOyBpdCdzIGEgbWFjcm8gd3JhcHBpbmcgDQo+Pj4+Pj4gdGhl bQ0KPj4+Pj4+IHdoaWNoIHB1dHMgdGhlIGxvc3QgcXVhbGlmaWVyIGJhY2suDQo+Pj4+Pg0KPj4+ Pj4gQ291bGQgeW91IHByb3ZpZGUgYSBjb25jcmV0ZSBleGFtcGxlPw0KPj4+Pg0KPj4+PiBGcm9t IGdsaWJjIDIuNDM6DQo+Pj4+DQo+Pj4+ICMgZGVmaW5lIF9fZ2xpYmNfY29uc3RfZ2VuZXJpYyhQ VFIsIENUWVBFLCBDQUxMKcKgwqDCoCBcDQo+Pj4+IMKgIF9HZW5lcmljICgwID8gKFBUUikgOiAo dm9pZCAqKSAxLMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+PiDCoMKgwqDCoMKgwqDCoCBj b25zdCB2b2lkICo6IChDVFlQRSkgKENBTEwpLMKgwqDCoMKgwqDCoMKgIFwNCj4+Pj4gwqDCoMKg wqDCoMKgwqAgZGVmYXVsdDogQ0FMTCkNCj4+Pj4NCj4+Pj4gd2hpbGUgdGhlIGRlY2xhcmF0aW9u cyBzdGlsbCBhcmUgZS5nLg0KPj4+Pg0KPj4+PiBleHRlcm4gdm9pZCAqbWVtY2hyIChjb25zdCB2 b2lkICpfX3MsIGludCBfX2MsIHNpemVfdCBfX24pDQo+Pj4+IMKgwqDCoMKgwqAgX19USFJPVyBf X2F0dHJpYnV0ZV9wdXJlX18gX19ub25udWxsICgoMSkpOw0KPj4+Pg0KPj4+PiAoYW5kIGhlbmNl IHRoZSBpbXBsZW1lbnRhdGlvbiBzdGlsbCAtIG5lY2Vzc2FyaWx5IC0gY2FzdHMgYXdheQ0KPj4+ PiBjb25zdC1uZXNzKS4NCj4+Pj4NCj4+Pg0KPj4+IE9rLCB3aWxsIGxvb2sgaW50byB0aGF0DQo+ Pg0KPj4gV2UgYXJlIGdvaW5nIHRvIGhhdmUgdG8gZGV2aWF0ZSB0aGUgaW1wbGVtZW50YXRpb24s IGV2ZW4gaWYgd2UgYXJlIHVzaW5nDQo+PiBfR2VuZXJpYygpIHRvIGZvcmNlIGNvbnN0LWNvcnJl Y3QgYmVoYXZpb3VyIGZyb20gdGhlIGNhbGxlcnMuDQo+Pg0KPj4gV2UgY291bGQgZHVwbGljYXRl IHRoZSBmdW5jdGlvbnMsIGJ1dCB0aGVyZSdzIGEgZGlmZmVyZW50IHJ1bGUgYWJvdXQNCj4+IHRo YXQuwqAgV2UgY2FuJ3QgdXNlIEVMRiBhbGlhc2luZyB0cmlja3MgYmVjYXVzZSB0aGF0IGJyZWFr cyBzb2Z0d2FyZQ0KPj4gdHlwZS1oYXNoaW5nIHRlY2huaXF1ZXMgZm9yIGNvbnRyb2wtZmxvdyBp bnRlZ3JpdHkuDQo+Pg0KPiANCj4gWWVhaC4gVGhlIGludGVybmFsIGNhc3QgaXMgY2xlYXJseSBz dGlsbCBzaWduYWxlZCBieSBFQ0xBSVIsIHJlZ2FyZGxlc3MgDQo+IG9mIHRoZSBzdXJyb3VuZGlu ZyBjb250ZXh0LiBUaGF0IGJlaW5nIHNhaWQsIHRoZSB0cmljayBpcyBxdWl0ZSBuaWNlIGFuZCAN Cj4gaXQgd291bGQgYWN0dWFsbHkgYmUgYSBzdHJvbmdlciBhcmd1bWVudCBmb3IgYSBkZXZpYXRp b24gaW4gbXkgb3BpbmlvbjogDQo+IGl0IG1pdGlnYXRlcyB0aGUgcmlzayBwb2ludGVkIG91dCBi eSB0aGUgTUlTUkEgcnVsZSBhdCB0aGUgY2FsbHNpdGVzLiBJdCANCj4gaXMgYWxzbyB0cnVlIHRo YXQgdGhlIEMyMyBzaWduYXR1cmUgaXMgYSBsb3QgbmljZXIgaW4gdGVybXMgb2YgdHlwaW5nIFsx XS4NCj4gDQo+IFRoZXJlJ3MgYSBzbGlnaHQgZnJpY3Rpb24gd2l0aCBNSVNSQSBDIFJ1bGUgMjMu NSAoIkEgZ2VuZXJpYyBzZWxlY3Rpb24gDQo+IHNob3VsZCBub3QgZGVwZW5kIG9uIGltcGxpY2l0 IHBvaW50ZXIgdHlwZSBjb252ZXJzaW9uIikgZnJvbSBNSVNSQSANCj4gQzoyMDEyIEFtZW5kbWVu dCAzIGZvciB0aGUgbm9uLWNvbnN0IGlucHV0IGNhc2UsIGJlY2F1c2UgdGhlIHR5cGUgb2YgdGhl IA0KPiBjb250cm9sbGluZyBleHByZXNzaW9uIGNvdWxkIG1hdGNoIGVpdGhlciBhbHRlcm5hdGl2 ZSBkZXBlbmRpbmcgb24gdGhlIA0KPiBjb250ZXh0LCBidXQgdGhhdCdzIG5vdCBhIHN0cm9uZyBj b25jZXJuIChBZHZpc29yeSBydWxlLCBubyBhc3NvY2lhdGVkIFVCKS4NCj4gDQo+IFsxXSBodHRw czovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz8gDQo+IHVybD1odHRw cyUzQSUyRiUyRmVuLmNwcHJlZmVyZW5jZS5jb20lMkZjJTJGc3RyaW5nJTJGYnl0ZSUyRm1lbWNo ciZkYXRhPTA1JTdDMDIlN0NkbXl0cm9fcHJva29wY2h1azElNDBlcGFtLmNvbSU3QzM0MDJjNzFj MzRhODQ0ZmRmYWVkMDhkZjIyNWIzZDc3JTdDYjQxYjcyZDA0ZTlmNGMyNjhhNjlmOTQ5ZjM2N2M5 MWQlN0MxJTdDMCU3QzYzOTI2NzQ0NzUzMDc1NjA1MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhl eUpGYlhCMGVVMWhjR2tpT25SeWRXVXNJbFlpT2lJd0xqQXVNREF3TUNJc0lsQWlPaUpYYVc0ek1p SXNJa0ZPSWpvaVRXRnBiQ0lzSWxkVUlqb3lmUSUzRCUzRCU3QzAlN0MlN0MlN0Mmc2RhdGE9ME5N MmZ0c2JFZzk4d0djaTd6Yk55eSUyQm9FU3ZQJTJCcWZVNyUyQno1T1FLbk5jYyUzRCZyZXNlcnZl ZD0wDQo+IA0KDQpDb21iaW5pbmcgYWxsIGNvbW1lbnRzIGFuZCBhbnN3ZXJzIEkgc2VlIHRoZSBu ZXh0IHN0ZXBzIHRvIHRoaXMgcGF0Y2g6DQoNCi0gZHJvcCBtZW1jaHJfaW52KCkgZnJvbSB0aGUg ZGV2aWF0aW9uDQotIGFuY2hvciB0aGUgZmlsZSBwYXR0ZXJucyBhcyBeLi4uJHx8Xi4uLiQNCi0g Z3JvdXAgdGhlIHhlbi9saWIgZmlsZXMgdG9nZXRoZXINCi0gbmFycm93IHRoZSBqdXN0aWZpY2F0 aW9uIHRvIHRoZSBjYXN0cyBpbiB0aGUgZnVuY3Rpb24gYm9kaWVzLg0KDQpBbnkgc3VnZ2VzdGlv bnM/DQoNCg0KQlIsIERteXRyby4NCg== From xen-devel-bounces@lists.xenproject.org Tue Oct 13 14:33:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 14:33:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447959.1663907 (Exim 4.92) (envelope-from ) id 1xGdYt-00064r-Aw; Tue, 13 Oct 2026 14:33:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447959.1663907; Tue, 13 Oct 2026 14:33: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 1xGdYt-00064k-8L; Tue, 13 Oct 2026 14:33:03 +0000 Received: by outflank-mailman (input) for mailman id 1447959; Tue, 13 Oct 2026 14:33:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGdYs-00064c-E5 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:33:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGdYr-008INE-QC for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:33:01 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace4118-8faa-0a2a0a5109dd-0a2a450bc4bc-24 for ; Tue, 13 Oct 2026 16:33:01 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace411d-b7e8-0a2a450b0019-b9ff1c23a9dd-3 for ; Tue, 13 Oct 2026 16:33: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 1a135ae53690008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 13 Oct 2026 14:32: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 7CCCE82AC1; Tue, 13 Oct 2026 16:32: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=175D5jhR8LtrrcoaZGhXaKt7LAOn7bOeuXP10amTjjE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=V66Ltl40876c1KfT4Bp+4/naw+gKqQlh2yYohMkq/Zq4VSc+aAYGj+dhf+22O4+x/014R0ejH 8zmWG8GP3neN/if8OLTVYFqzqCKhmZze4JlGgTx7SPdYl4dtIR1O5qc50saRZ/gt8W+Mp2k+uSo vAVYglLphC/65v0bDUN9wqdLlSyUR2eGqLVlc1M+yHnhBpUMSnlBHSOdwGdgRpbkB80yRdI2Xrs EQNPpkBTEHL42JOOROWw45UwFgN4COS/qsYbzUQge6NvPCKQCNxtkppJXy4/oPkthMxVDL60YEq oltwS8mzvlxdKellXrP2azKf2NZO+J9OU1OL+huJuT2Q== X-Zone-Loop: c75b45008d7691d0b5408dbf61df685e69bafffc4208 x-campaign-type: default x-transaction-id: 779fd0da-9d66-426b-9910-c8154a516f25 x-swg-uid: 01-df09542c-2016-486a-8dd4-063ce9fcde7d X-Mailer: Sweego Message-ID: <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> x-swg-bid: 1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425 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 v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org In-Reply-To: <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> Date: Tue, 13 Oct 2026 16:32:52 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791901973; l=1903; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=qcFkZYCkTx0zYutf6aDU8vl9CZ5fXy72ZTfR1yp5ikU=; b=s9xFap/Vzo0m6qL7bXgeSnjzYZDodSmWO2DfznTNjVzLZB238C6n1WM8jvHeo3rdtC5v6OtFC lBmRYh03nJlB6OKmds6AcirqpfMkTUccYYuvORr8jR8cwR5A4Mwp00J 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: 1791901978709 X-purgate-ID: tlsNG-42698a/1791901981-A88C99EA-4C61047D/0/0 X-purgate-type: clean X-purgate-size: 1903 On 2026-10-13 12:36 +0200, Jan Beulich wrote: > On 13.10.2026 12:07, Baptiste Le Duc wrote: > > @@ -620,6 +623,98 @@ static void __init compute_guest_isa(void) > > panic("Failed to build guest \"riscv,isa\" string\n"); > > } > > > > +static bool __init probe_hw_ad_update(void) > > +{ > > + bool updated = false; > > + unsigned int slot = FIX_MISC; > > + vaddr_t va = FIXMAP_ADDR(slot); > > + struct page_info *pg; > > + pte_t *entry, pte; > > + mfn_t mfn; > > + unsigned long tmp; > > + > > + pg = alloc_domheap_page(NULL, 0); > > + if ( !pg ) > > + return false; > > Why would you need a fresh page here? Can't you create a secondary mapping > of a page already in use (e.g. one from Xen's .data or .bss section, or the > stack page you're running on)? > > > + mfn = page_to_mfn(pg); > > + > > + arch_pmap_map(FIX_MISC, mfn); > > + entry = &xen_fixmap[slot]; > > + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE); > > + write_pte(entry, pte); > > + > > + flush_tlb_one_local(va); > > + > > + asm_inline volatile ( > > + "1: ld %[tmp], 0(%[va])\n" > > + " li %[updated], 1\n" > > If you mapped the stack page, you could preset a variable there to 1, load > from the alias mapping of that variable, and then avoid the LI altogether. > > > + "2:\n" > > + ASM_EXTABLE(1b, 2b) > > + : [tmp] "=&r" (tmp), [updated] "+r" (updated) > > + : [va] "r" (va) > > + : "memory" ); > > + > > + arch_pmap_unmap(slot); > > + free_domheap_page(pg); > > + > > + return updated; > > +} > > Imo you'd better check that A also was actually set in the PTE. If I check that A was set, can I drop the "updated" variable? The A bit would tell us more than whether the load succeeded. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 13 14:53:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 14:53:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447979.1663944 (Exim 4.92) (envelope-from ) id 1xGdsV-0001Pc-2x; Tue, 13 Oct 2026 14:53:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447979.1663944; Tue, 13 Oct 2026 14:53: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 1xGdsV-0001PV-0N; Tue, 13 Oct 2026 14:53:19 +0000 Received: by outflank-mailman (input) for mailman id 1447979; Tue, 13 Oct 2026 14:53:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGdsT-0001PP-Fn for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:53:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGdsS-00A7a3-LD for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:53:16 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace45d7-8faa-0a2a0a5109dd-0a2a45089c80-4 for ; Tue, 13 Oct 2026 16:53:16 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace45d9-f659-0a2a45080019-d155dd2ce4f1-3 for ; Tue, 13 Oct 2026 16:53:13 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48b0ef9c76eso2468932f8f.0 for ; Tue, 13 Oct 2026 07:53: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-48de0acb1ebsm5826169f8f.44.2026.10.13.07.53.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 07:53: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=1791903193; x=1792507993; 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=vuBU24Y/Ww/MLNIdbrH0LlUn8ynZUHhtY0QckEh4Mzs=; b=ULELQRJB3x52gspxlmqzwJlt2C6s/VWTA1fMW0Se2g0Z046uPPno5GCFfi4Yzcd7po LPuOv9FIZdWaRoRVMDkLkGWhg/LYyCOhfjNG4pyrCQ4jCH1iP5R5xEdY1OmufExL2G8b yRYJTwgp1nnrVIekFKvYxJQSuHgKXZFPwzMnY8Q7pQihMkOXkEtUfOLrhDgEvRZL55nz EKsIBlpYuXBBYqXOPYMhkBCCeBfXLdU2+DuqcdNmb5G59pu8w05EjBpuqaXYIsGKLRe7 URTTijY+IB44Du4h44hSoxpbWPA69wF896Rig48+2kAnv5AndZbwXCjlDn7Qa88aXukJ 1S2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791903193; x=1792507993; 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=vuBU24Y/Ww/MLNIdbrH0LlUn8ynZUHhtY0QckEh4Mzs=; b=fVZ2QF0XkDBeD1MzmlLIuYMZB2wiO4nzpIKpXYNlGdSROMQN/tsEPl5uKcBziuaELW 2A2Us9fmVmugevZI+l+d+7KCzT98ruJEckbJFZxMtKNTpz+ORRrtT3RMi803H7AH0s5K WLkaVYwKfiXJcoEcg9Zy5ghPpJ0unsUv2T9PLCfMgCOmbOEZIvhm7Cy4ckXWjcGYK3QL Q6HA0eVCoirpxgzuEB3QBN6U/cWbsbW6IJ0yLe7jJMUL5KUYfuBmseWbaCOlmB7+lGJP wzNO9B7pYQywgGBhgcKID1OnqTcznB7UVubWb77mimVG9tpcevUTLxDWRCidLubDhL83 ivrg== X-Gm-Message-State: AFq9FYLZMPTHc80Zv1RywG3Ze1r1G9X1y9bwnM/5K/e0qz3gNaAgS2Wo HgmhkIAFhX+Xo2TnpER0fRpWSZQ7+Vz9F4uU9F1ovGBeqX1XEO3J8mesK9AmRZMBNA== X-Gm-Gg: AYBFou0i622JqKQ5g4mC5d4Oy6VTlWUpMLbdO30XXRvC16xQCiNvuasVIhn0e7aJCc8 9Jbi9SIVzSExQJGvshiI2SHFKFcC/WeZO/nj/n5L1XPvGGl95u7Mx5adbbJsD4ER+4Qevu4Gi98 +1mha8v9klOY8pGG/38G5BckeGQwTa1lktLl+Pi7j9nrAlCKYHdsEam27Rzs690dw90CW5VLPA9 +oYFD9M/D16m7cLihHDrJHxFUI//nE01MBtAgJmYw/9HX13wihJtDBIfFXH8weceI5qA8xHAPlU KspxqKj6XE2r56OEMzgcJA9D2tglS9cICywIGKOkE8RxmJ76qK1Ho9CLxkv3T4f1Q0XgW33BzGr z/Ah/jgs7/F8b9bhUxiniE9zhXEzLhayHBvoCut47M2BjoHM0bjHL4Km42w1FOxCmKsVZG311xk FMTE+OJ3ZFC1Hqk/ONelYruwAnIjQut11vsio4z3prX9OeZyXG1EKz4pox+1koIiqYINFFJr6I8 P6CMT/eSaLkrh2ZfaWYxV5JxP4jIafJD2cN3rBAlwi2TuVUSTRFr7asn1HnXg== X-Received: by 2002:a5d:644a:0:b0:486:f42f:6860 with SMTP id ffacd0b85a97d-48dbaaefc28mr18457544f8f.56.1791903192427; Tue, 13 Oct 2026 07:53:12 -0700 (PDT) Message-ID: <5756a0b2-9480-4f31-ab0a-e23fd0ee080b@suse.com> Date: Tue, 13 Oct 2026 16:53:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <575ec1bc-764c-4016-a584-a79e57817d9a@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/1791903193-CC37587B-DF6A9724/10/78276251493 X-purgate-type: spam X-purgate-size: 1771 On 13.10.2026 15:48, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:21:55AM +0200, Jan Beulich wrote: >> pvh_populate_p2m() needs to populate RAM according to the initial map >> established, prior to any stealing by pvh_steal_ram(). Subsequently the >> invocations of those functions will (need to) move ahead of >> pvh_populate_p2m(), so what to act on is no longer Dom0's memory map at >> the time of invocation. > > But (most of?) the uses of pvh_steal_ram() expect to access the stolen > RAM, and hence using pvh_steal_ram() ahead of pvh_populate_p2m() is > not a present use-case? > > I assume you have a further use-case for pvh_steal_ram() that wants to > steal a range before it's populated, which might be worth mentioning > here, to add a bit more context? I thought that I'm saying just that already with "Subsequently ...". All that logic needs splitting: Obtain a range ahead of populating, access the range only afterwards. >> @@ -1389,6 +1395,15 @@ int __init dom0_construct_pvh(const stru >> >> iommu_hwdom_init(d); >> >> + nr_orig_e820 = d->arch.nr_e820; >> + orig_e820 = xvmalloc_array(struct e820entry, nr_orig_e820); >> + if ( !orig_e820 ) >> + { >> + printk("No memory for copy of E820 map (%u entries)\n", nr_orig_e820); > > For some of the printks during dom0 PVH construction we already print > the domain (%pd), and I think it would be good to print it here also. > Some not-yet-upstream uses (hyperlaunch) create several domains using > this logic, it would be good to easily spot which domain triggered the > errors. Can do, sure. That'll be a little inconsistent then for a while; maybe I should add a patch adjusting all printk()s I didn't otherwise touch. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 14:59:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 14:59:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447987.1663953 (Exim 4.92) (envelope-from ) id 1xGdyZ-0002HU-M9; Tue, 13 Oct 2026 14:59:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447987.1663953; Tue, 13 Oct 2026 14: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 1xGdyZ-0002HN-JK; Tue, 13 Oct 2026 14:59:35 +0000 Received: by outflank-mailman (input) for mailman id 1447987; Tue, 13 Oct 2026 14:59:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGdyY-0002HH-Lh for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 14:59:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGdyY-00000003Qk8-2C1i; Tue, 13 Oct 2026 14:59:34 +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.98.2) (envelope-from ) id 1xGdyX-000000024eW-2K8I; Tue, 13 Oct 2026 14:59: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" 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=Azj8TpXYKgknYBcUzdSrDKjtvSbs0uZmnlMiUen+Wyk=; b=vK9Zt8PnkgNjPeL4pXMtyd1hJo JpVZ1jmMuCMzMpzYVln8t9dOGWvjoWYAlgA6c6aJeua/lltHeVTpnhqq5WZtq9drmR9fa8Y/PW0kq V6Bek/qvaz7EtG9AnWMaxCxBG8tBdn+8QkXaSCjLaeYgqu8oavoVbWZX1C9icuMJB+mI=; Date: Tue, 13 Oct 2026 16:59:31 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 07/15] x86/PVH: lift E820 alignment requirement Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Mon, Oct 12, 2026 at 10:22:28AM +0200, Jan Beulich wrote: > Before reordering things (to move in particular pvh_steal_ram() > invocations ahead of the pvh_populate_p2m() one) drop an undue (and as it > turns out unnecessary) assumption: find_memory() doesn't really depend on > E820 regions to end on page boundaries. > > Signed-off-by: Jan Beulich > --- > Really the assumption towards the start of regions doesn't look to be > relevant either, yet I thought I'd limit the change to the minimum needed. > (In fact the statement immediately ahead of the assertion arranges for > page alignment, so the check is dubious altogether.) > > We also could consider whether kernel_end really needs rounding up to a > page boundary: Technically there's no need, but the question is whether it > would be a good idea to have the tail of the kernel region share a page > with metadata (or, as things still are at this point of the series, the > initrd). I think it would a bad idea to have this kind of page-sharing. The guest might use NX for metadata page-tables (ie: initrd), so it sharing a page with the kernel could be problematic. > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -365,6 +365,9 @@ static __init void pvh_setup_e820(struct > * that's the minimum granularity of the 2nd stage translation. Since > * the p2m code uses PAGE_ORDER_4K internally, also use it here in > * order to prevent this code from getting out of sync. > + * > + * Note that this is only for pvh_populate_p2m(). Subsequent uses of > + * pvh_steal_ram() will break the length part. Maybe because I'm too familiar with this code, but the previous comment mentioning the 4K alignment being required for the 2nd stage translation kind of implies this is the reason for it? I guess you want to make it clear there is no further logic depending on that alignment. > */ > start = ROUNDUP(entry->addr, PAGE_SIZE << PAGE_ORDER_4K); > end = (entry->addr + entry->size) & > @@ -506,8 +509,8 @@ static paddr_t __init find_memory( > unsigned int i; > > /* > - * The memory map is sorted and all RAM regions starts and sizes are > - * aligned to page boundaries. > + * The memory map is sorted and all RAM region starts are aligned to > + * page boundaries. > */ > for ( i = 0; i < d->arch.nr_e820; i++ ) > { > @@ -519,7 +522,7 @@ static paddr_t __init find_memory( > > start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1)); > > - ASSERT(IS_ALIGNED(start, PAGE_SIZE) && IS_ALIGNED(end, PAGE_SIZE)); > + ASSERT(IS_ALIGNED(start, PAGE_SIZE)); I would remove this altogether - as you noticed start is clearly aligned by the code in the line just above. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:08:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:08:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1447997.1663962 (Exim 4.92) (envelope-from ) id 1xGe7X-0004Fj-Gj; Tue, 13 Oct 2026 15:08:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1447997.1663962; Tue, 13 Oct 2026 15:08: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 1xGe7X-0004Fc-D3; Tue, 13 Oct 2026 15:08:51 +0000 Received: by outflank-mailman (input) for mailman id 1447997; Tue, 13 Oct 2026 15:08:49 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGe7V-0004ER-NY for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:08:49 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGe7V-00000003Qvw-2d6l; Tue, 13 Oct 2026 15:08:49 +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.98.2) (envelope-from ) id 1xGe7U-00000002NA6-2fym; Tue, 13 Oct 2026 15:08: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" 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=zrMIdH8hBmD1+odGiJwmQINQWdwA3ihIbKHe38IxbyU=; b=Q0bsAVvztm0x6B88FBmc5FntT4 zP0RuHGU5dZfwuRbm8rHa9XhJqWZijqlEDNVMvG2tIrRcOLAyixA48CIqk4Zf/A7efUYCyyLR3hfH Qjd694sqDfBU2smZW7uy/9z3yMBpRchdi51sBp7bajHvK4N7pq3hTMQbqWVA8T9HQI/o=; Date: Tue, 13 Oct 2026 17:08:46 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 06/15] x86/PVH: keep a copy of Dom0's initial E820 map Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <575ec1bc-764c-4016-a584-a79e57817d9a@suse.com> <5756a0b2-9480-4f31-ab0a-e23fd0ee080b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5756a0b2-9480-4f31-ab0a-e23fd0ee080b@suse.com> On Tue, Oct 13, 2026 at 04:53:11PM +0200, Jan Beulich wrote: > On 13.10.2026 15:48, Roger Pau Monné wrote: > > On Mon, Oct 12, 2026 at 10:21:55AM +0200, Jan Beulich wrote: > >> pvh_populate_p2m() needs to populate RAM according to the initial map > >> established, prior to any stealing by pvh_steal_ram(). Subsequently the > >> invocations of those functions will (need to) move ahead of > >> pvh_populate_p2m(), so what to act on is no longer Dom0's memory map at > >> the time of invocation. > > > > But (most of?) the uses of pvh_steal_ram() expect to access the stolen > > RAM, and hence using pvh_steal_ram() ahead of pvh_populate_p2m() is > > not a present use-case? > > > > I assume you have a further use-case for pvh_steal_ram() that wants to > > steal a range before it's populated, which might be worth mentioning > > here, to add a bit more context? > > I thought that I'm saying just that already with "Subsequently ...". All > that logic needs splitting: Obtain a range ahead of populating, access > the range only afterwards. OK, it wasn't obviously clear from the message. I would possibly explicitly mention that it's just the allocation that's moved ahead, the access must be kept after pvh_populate_p2m(). > >> @@ -1389,6 +1395,15 @@ int __init dom0_construct_pvh(const stru > >> > >> iommu_hwdom_init(d); > >> > >> + nr_orig_e820 = d->arch.nr_e820; > >> + orig_e820 = xvmalloc_array(struct e820entry, nr_orig_e820); > >> + if ( !orig_e820 ) > >> + { > >> + printk("No memory for copy of E820 map (%u entries)\n", nr_orig_e820); > > > > For some of the printks during dom0 PVH construction we already print > > the domain (%pd), and I think it would be good to print it here also. > > Some not-yet-upstream uses (hyperlaunch) create several domains using > > this logic, it would be good to easily spot which domain triggered the > > errors. > > Can do, sure. That'll be a little inconsistent then for a while; maybe > I should add a patch adjusting all printk()s I didn't otherwise touch. It's kind of inconsistent already, see for example the messages at the top of dom0_construct_pvh(). I won't request that you fix the existing ones, but it would be better if new additions print the domain as part of the message. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:13:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:13:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448006.1663971 (Exim 4.92) (envelope-from ) id 1xGeBf-0005tb-VA; Tue, 13 Oct 2026 15:13:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448006.1663971; Tue, 13 Oct 2026 15: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 1xGeBf-0005tU-SK; Tue, 13 Oct 2026 15:13:07 +0000 Received: by outflank-mailman (input) for mailman id 1448006; Tue, 13 Oct 2026 15:13:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGeBe-0005tO-8G for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:13:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGeBd-002TVt-DI for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:13:05 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace4a80-8faa-0a2a0a5109dd-0a2a4503b990-2 for ; Tue, 13 Oct 2026 17:13:05 +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 6ace4a81-fae8-0a2a45030019-d1558032a5f7-3 for ; Tue, 13 Oct 2026 17:13:05 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a1af482519so6057835e9.1 for ; Tue, 13 Oct 2026 08:13: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-4a18bea0f1csm534357255e9.9.2026.10.13.08.13.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 08:13: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=1791904385; x=1792509185; 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=S8bGDKcmFJN/P6emYCz6cM3orxP/FzSRMb/dLvTdpyk=; b=SsQCacplTF++Y9FxstkGxePGpgxp2QWSnyvT/OXLgEzz502Aa2uqjYSVvRMROLj2qr 0RkUkEI0dyYeC4Jruqzr32E9uImIeXwVE1+HxjEJyQBfruoqqOWSa7yW4XLWdD4MJE88 j6vLGSy7Lxn8X4/alJztXg8kfOWwOmSN/fgawiSJavFZjmty46d4C//aMNxMdxvznM10 EnAUJfWnbJwNhMsP9Rufc5LuQepWMK9A5sCnKJRFkaEY0QTBgPnARBAcPRxPXvHRQWKM HC8vNbgJFAWE0sUumAmIg4IOzEg3wEALAaEUEPhBhpIFz8lHyE0I2S6dPHsAJYopfHpt hxIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791904385; x=1792509185; 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=S8bGDKcmFJN/P6emYCz6cM3orxP/FzSRMb/dLvTdpyk=; b=d2AfQFMts5JrkqGHy0r9eVPrBkElngrdWbsKNxSpJae+GxZt/CObkw774/VMg8hvmF wAYwXMtCk0Z/TurBS+f9ZQIyc7DBEh+GFyBR8ksLqKpmwJTz2XxLibDEGo3w9s0+gEGt OQlqFiOWi9uxk9DF0HOnsrf4frhpVWY3wxIr7AMteK8LE6L3sjCfQPprcQ2wUBLOrMSf Vz12nJrwqKQu03Pov5/OHA3wOSd1XroWjopPiY3xYiSl8E/fAjdZqkVg4HKlZb6/hwQ7 VirAGjSrLxVu8sPz4Q1uubghipzty0p34YaNsYsvmi+hwDrYzAPuGnWgsdDFUn9B3uum 1d9g== X-Gm-Message-State: AFq9FYI5WmoIqWD6kYY3OcD5fpLLLs0jkCNFjKd+OCr/1oidqm1YZ1wF /MyL51FktoREQvGBklZxe2E7xmcedKoiX+vo4XtqGcEigR17O+nn7jGrYOyzMw0ySA== X-Gm-Gg: AYBFou0LV1tFJpJeLycA2NY8rYRNXiDGF/7gEHdHx9Olg8p6Oi8braWuQSy2XW5snJT OKzq+9fSB6XqdwPT1mftiz8KOebkPmqLHIhKBKZDOGaSs2KUwdSu66tYAWU9blkfVdkXL9+jMRM 3Mxbp/msUc+jJs3ICtAS0ZDmcq02xXdvHBZb5nYW+uAr0poqX8k+u7m/myU4H2fbG05YCilexDS dbjoOIvYEv1BiLBJLT7PiKwXZNzNN2bdQkVw6A1mDzDFSOP1fTF8uis2eF9jFD5vT36F5gDHehc EX7Pj7Lkz4d/bP79aYucRfxg7X0bZ2PR2t2yGhx+38pX+mj9LD5sO51VfsFyQKVBnETO53L00qv 197HVSinM6odolibt64DyXN+JhIUSk1Ov5hgd5j4x+wuaFJu2Doc1jorzx7DLU/BatKK5ZtGp/c Qq98uY5FKfYkLeJWhJ45yd70uHbbIk0IuDes05nE43vduGxzQds2MwwpIsQtPTjC9zzsAb5wjCB q8yPV31yDYN8GP9RA1juagQHSTAAAwSnnuIrAwdNEQezFiET6zVDG8PlcfaQ8A= X-Received: by 2002:a05:600c:3146:b0:4a0:34a:588c with SMTP id 5b1f17b1804b1-4a18e4a7cb9mr254138635e9.14.1791904384553; Tue, 13 Oct 2026 08:13:04 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 17:13:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 07/15] x86/PVH: lift E820 alignment requirement To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1791904385-6E2D04E9-B9939B82/10/78276251493 X-purgate-type: spam X-purgate-size: 3560 On 13.10.2026 16:59, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:22:28AM +0200, Jan Beulich wrote: >> Before reordering things (to move in particular pvh_steal_ram() >> invocations ahead of the pvh_populate_p2m() one) drop an undue (and as it >> turns out unnecessary) assumption: find_memory() doesn't really depend on >> E820 regions to end on page boundaries. >> >> Signed-off-by: Jan Beulich >> --- >> Really the assumption towards the start of regions doesn't look to be >> relevant either, yet I thought I'd limit the change to the minimum needed. >> (In fact the statement immediately ahead of the assertion arranges for >> page alignment, so the check is dubious altogether.) >> >> We also could consider whether kernel_end really needs rounding up to a >> page boundary: Technically there's no need, but the question is whether it >> would be a good idea to have the tail of the kernel region share a page >> with metadata (or, as things still are at this point of the series, the >> initrd). > > I think it would a bad idea to have this kind of page-sharing. The > guest might use NX for metadata page-tables (ie: initrd), so it > sharing a page with the kernel could be problematic. Okay, will not pursue this then. >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -365,6 +365,9 @@ static __init void pvh_setup_e820(struct >> * that's the minimum granularity of the 2nd stage translation. Since >> * the p2m code uses PAGE_ORDER_4K internally, also use it here in >> * order to prevent this code from getting out of sync. >> + * >> + * Note that this is only for pvh_populate_p2m(). Subsequent uses of >> + * pvh_steal_ram() will break the length part. > > Maybe because I'm too familiar with this code, but the previous > comment mentioning the 4K alignment being required for the 2nd stage > translation kind of implies this is the reason for it? I guess you > want to make it clear there is no further logic depending on that > alignment. To me it seemed as if the other comments / assumptions were (at least in part) building on what's said here. I.e. yes, I meant to verbally break any such connections people may have memorized. If you think I'm going too far with this comment addition - getting rid of it again is easy. >> @@ -506,8 +509,8 @@ static paddr_t __init find_memory( >> unsigned int i; >> >> /* >> - * The memory map is sorted and all RAM regions starts and sizes are >> - * aligned to page boundaries. >> + * The memory map is sorted and all RAM region starts are aligned to >> + * page boundaries. >> */ >> for ( i = 0; i < d->arch.nr_e820; i++ ) >> { >> @@ -519,7 +522,7 @@ static paddr_t __init find_memory( >> >> start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1)); >> >> - ASSERT(IS_ALIGNED(start, PAGE_SIZE) && IS_ALIGNED(end, PAGE_SIZE)); >> + ASSERT(IS_ALIGNED(start, PAGE_SIZE)); > > I would remove this altogether - as you noticed start is clearly > aligned by the code in the line just above. Will do. I kept this part because it wasn't really the first time round that I had noticed the check being pointless. I.e. there still was that chance that I might have been missing something. Alternatively I could drop the ROUNDUP() from the assignment of start. Else I think the comment ahead of the loop may want altering further. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:18:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448011.1663980 (Exim 4.92) (envelope-from ) id 1xGeGh-0006hU-Jz; Tue, 13 Oct 2026 15:18:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448011.1663980; Tue, 13 Oct 2026 15:18: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 1xGeGh-0006hN-HM; Tue, 13 Oct 2026 15:18:19 +0000 Received: by outflank-mailman (input) for mailman id 1448011; Tue, 13 Oct 2026 15:18:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGeGg-0006hH-7U for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:18:18 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGeGg-00000003R6B-0phX; Tue, 13 Oct 2026 15:18:17 +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.98.2) (envelope-from ) id 1xGeGf-00000002fpb-0rYJ; Tue, 13 Oct 2026 15:18: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=VwgG761bOOp97QQD14h/MFuJjQoVe+hzCUaTx729ri0=; b=YgdOWLyHusiGoUYvzIC7xLzrG0 VhLkOkAbWS8ezgH67pWLc6593bLprGzZHvmrw+G7FUItaVGUIoIQhnL6LltBahVI3V/w69+xIRUj1 BfcKRkS96ZTj7WEcqoLn/bSlslfOGSVSqr6/QgnaWAOjdNo59BYwhqoDAlA99NCSeRaI=; Date: Tue, 13 Oct 2026 17:18:15 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Dmytro Prokopchuk1 Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: [PATCH v2] vPCI: resolve MISRA R10.1 boolean arithmetic type violation Message-ID: References: <7549daf9e0de3420198913f6f91c16c929a31834.1791404375.git.dmytro_prokopchuk1@epam.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7549daf9e0de3420198913f6f91c16c929a31834.1791404375.git.dmytro_prokopchuk1@epam.com> On Wed, Oct 07, 2026 at 08:39:52PM +0000, Dmytro Prokopchuk1 wrote: > MISRA C Rule 10.1 states: "Operands shall not be of an inappropriate > essential type". > > bar_write() and guest_mem_bar_write() added the boolean 'hi' to a > pointer difference when printing the ignored BAR index. These handlers > are registered only for the memory BAR registers, so print > (reg - PCI_BASE_ADDRESS_0) / 4 instead. The expression has type > unsigned int, so use %u. > > No functional changes. > > Suggested-by: Roger Pau Monné > Signed-off-by: Dmytro Prokopchuk Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:24:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:24:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448030.1664016 (Exim 4.92) (envelope-from ) id 1xGeMX-00008K-E1; Tue, 13 Oct 2026 15:24:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448030.1664016; Tue, 13 Oct 2026 15:24: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 1xGeMX-00008A-BQ; Tue, 13 Oct 2026 15:24:21 +0000 Received: by outflank-mailman (input) for mailman id 1448030; Tue, 13 Oct 2026 15:24:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGeMW-00007z-AH for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:24:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGeMV-001fYm-CJ for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:24:19 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace4cfd-8faa-0a2a0a5109dd-0a2a4506cd6e-24 for ; Tue, 13 Oct 2026 17:24:19 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace4d23-195a-0a2a45060019-d155802fa4c7-3 for ; Tue, 13 Oct 2026 17:24:19 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a16c1608faso40751225e9.0 for ; Tue, 13 Oct 2026 08:24: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-4a18e48db03sm533044085e9.3.2026.10.13.08.24.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 08:24: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:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1791905059; x=1792509859; 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=wfzD61GjKLYFbsWNF7jULFxbpAX1jF6qoMbPq1vMzg4=; b=QXcVIOuEaVTohG6iRDFLjLjgIedIMMhNU/fZLfd6JMEPCqRZcfJpkTLX+lzgn4OBIz 4fsmdV0ePV4p5BZc7H38BQmXvsjtXFpAUDpDOIqyZjGHnneHUzAA1uuhmTzHvWGC8cBg 34j2c68HQtp65qOfpDBcJ057bWUdHDnxlqKlJWoe0EHbsy2o/sYQh4ynOAaflowdj1L3 unBEQmBMiwMGTMt8u2kT1Rm4XZWBncGSwKwDuhTpJHrHJQef5d1oy+vSo5J6jYm4ldSu Pl3B506m1FvJDlZknWSF/vPLS2NdoLlRr7sG1Ky+UkC4e2vN9Q+5pFLYWIeA7ETxM+Bh joIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791905059; x=1792509859; 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=wfzD61GjKLYFbsWNF7jULFxbpAX1jF6qoMbPq1vMzg4=; b=i4lEzoAddhnauZzg39Oshb6TkM319I7AvvXbUkxAdccWW0Gp6WuCnVQ24U94QhUqaN JiJQI0ahC6ESbKrzLea+6SjreXjoPEZnsRgwlc6mIZLtT+jkKrWZNbmAdGtimMVs6wc2 0KfiWt1fYorE78neLOZnD1pW3YQVajj25OOGsiDhypJDahXXntSoxDqFd/hdAEkGx/eD DZ1xhRK67cp6Fxht8otlggGzM5IiVBAarFSGfdan5k55nIx4nt0Ivp0Bq4/79JK8GHCQ KjE9D3b3iPIDYG/hvOHhr7GT8zabeii950iKd/5RCEJMfL9j04U0k/sfomSbNa8AHNmD +ahw== X-Forwarded-Encrypted: i=1; AKwUvByoK7OvDzIMxpQiSBvuR20eOgx7cNC2oF35VV0PY0Cxh7/aLe1gahX51sk2V4SIHJohjOxNiVVm+Ko=@lists.xenproject.org X-Gm-Message-State: AFq9FYLmebAasAs5zLi6KzOaPtglOgZ0otvUclJ2WMgX+gKrs/byGUfW FM8WjmsdxixblGRFvd6nTHEY12vLSKpJW34YH3AniDKhjEivEMxkJaK1Yvv4qDPySg== X-Gm-Gg: AYBFou30QehWPL+kic7C4/2HVhzf7q2LPWBb7uPJlTyhFZ0hmNzI1/DSU5ODNPEHH3E RuDnTnRRAxWK0whDYPm5ncFwhLwC5Ao0vQ4vTuVSfErLM4xuUTXc7ZCHth6qWiyUgXF+UMmig6a S66fs4JSeD2SmTeJL1qpogI6Ltygt5EqysiuxZVBJQFkEAxYv5vpww1+wW92L6+wS+0zFZMVT8c mZ6PVRPh2MecFZUHOdTUHGlxxqT44ygISbp4A1Jd5goJiBPjSjZjswQAVa3q3V2HEM57GZUcO8K 5V0209QB4gsDqa2qTKiyQEqj4gK4r78INg1kWpdcmW0Qtb51QLc6Ag6T3/E5RZFVss13nDL/d/q KJpivawti49H7k9sMMVSks7DXRFHM4qPbFKAYhzx1ft0RUwgcvissTedI5HGFuEw8YgwdUnomXf cDHu5pLzvkor08WUHUr9OFDZS7p1wVzxdUu58c8RGlL7fXlD5e4TEiuHBUABESj1j/StpxKyWF6 6q3GVPmDazXshXkVjAvPYlC0bYw7PyEjdgZjwP04CC37UjGRcubD9YsUThofIE= X-Received: by 2002:a05:600c:83cf:b0:4a1:ac66:604b with SMTP id 5b1f17b1804b1-4a1ac666a65mr46600395e9.1.1791905058579; Tue, 13 Oct 2026 08:24:18 -0700 (PDT) Message-ID: <9baeae94-edfb-44f9-9d45-dca32f0d0ed1@suse.com> Date: Tue, 13 Oct 2026 17:24:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791892682.8631fc262581453bbf619ec5b2062170.1a1352076650008425@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: <1791892682.8631fc262581453bbf619ec5b2062170.1a1352076650008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1791905059-FE27077B-E56DA481/10/78276251493 X-purgate-type: spam X-purgate-size: 4357 On 13.10.2026 13:57, Baptiste Le Duc wrote: > On 2026-10-13 12:36 +0200, Jan Beulich wrote: >> On 13.10.2026 12:07, Baptiste Le Duc wrote: >>> @@ -620,6 +623,98 @@ static void __init compute_guest_isa(void) >>> panic("Failed to build guest \"riscv,isa\" string\n"); >>> } >>> >>> +static bool __init probe_hw_ad_update(void) >>> +{ >>> + bool updated = false; >>> + unsigned int slot = FIX_MISC; >>> + vaddr_t va = FIXMAP_ADDR(slot); >>> + struct page_info *pg; >>> + pte_t *entry, pte; >>> + mfn_t mfn; >>> + unsigned long tmp; >>> + >>> + pg = alloc_domheap_page(NULL, 0); >>> + if ( !pg ) >>> + return false; >> >> Why would you need a fresh page here? Can't you create a secondary mapping >> of a page already in use (e.g. one from Xen's .data or .bss section, or the >> stack page you're running on)? > You're right, I will map the current stack page. >> >>> + mfn = page_to_mfn(pg); >>> + >>> + arch_pmap_map(FIX_MISC, mfn); >>> + entry = &xen_fixmap[slot]; >>> + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE); >>> + write_pte(entry, pte); >>> + >>> + flush_tlb_one_local(va); >>> + >>> + asm_inline volatile ( >>> + "1: ld %[tmp], 0(%[va])\n" >>> + " li %[updated], 1\n" >> >> If you mapped the stack page, you could preset a variable there to 1, load >> from the alias mapping of that variable, and then avoid the LI altogether. > Yes mapping the stack page appears to be the best way. >> >>> + "2:\n" >>> + ASM_EXTABLE(1b, 2b) >>> + : [tmp] "=&r" (tmp), [updated] "+r" (updated) >>> + : [va] "r" (va) >>> + : "memory" ); >>> + >>> + arch_pmap_unmap(slot); >>> + free_domheap_page(pg); >>> + >>> + return updated; >>> +} >> >> Imo you'd better check that A also was actually set in the PTE. > Right, I will do that. >> >>> + >>> + /* Neither advertised: trust the probe. */ >>> + __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, >>> + riscv_isa); >> >> Hmm, this feels fragile. Other schemes are possible, e.g. A being updated >> by hardware but D being left to software. Are such truly precluded by the >> spec, including older versions thereof? Furthermore, probe_hw_ad_update() >> can (right now) return false for unrelated reasons. > Since 1.10 the spec lists exactly two schemes, and each one covers A and > D together: either a clear A (or a clear D on a store) raises a page > fault, or hardware sets the corresponding bit(s). A-bit being set by > hardware while D is left to software isn't one of them. Before 1.10, the > hardware must set the two bits. Therefore, there is not other schemes > possible. >> As a consequence, patch 2 imo also can't leave the A/D pre-setting unaltered. >> It perhaps needs doing unless Svadu is positively identified as present. > I agree it is more robust to preset A/D bits unless Svadu is truly > identified, i.e. advertised in the DTS (without Svade) and confirmed by > probe_hw_ad_update(). The worst case then becomes the probe failing for > an unrelated reason on hardware which does update A/D: we'd preset A/D > needlessly, which is harmless, as hardware only writes the PTE when a > bit is clear. > > To sum up, and to avoid unnecessary respins, would you be fine with: > 1) Keeping the probe as it is, with your remarks addressed (map stack page). (... and verify A bit was set). > 2) Presetting A/D bits unless Svadu is truly identified as above. Yes. Assuming Oleksii also agrees. >>> --- a/xen/arch/riscv/include/asm/cpufeature.h >>> +++ b/xen/arch/riscv/include/asm/cpufeature.h >>> @@ -42,6 +42,7 @@ enum riscv_isa_ext_id { >>> RISCV_ISA_EXT_sstc, >>> RISCV_ISA_EXT_svade, >>> RISCV_ISA_EXT_svpbmt, >>> + RISCV_ISA_EXT_svadu, >> >> Isn't there some sort of sorting in effect here? > No, as it is mentioned in the docstring that: > * New extensions should just be added to the bottom, rather than added > * alphabetically, in order to avoid unnecessary shuffling. I see. Yet I wonder: What shuffling would we need to be afraid of? Always inserting at the bottom increases the risk of patch conflicts. Furthermore single-letter extensions can't be inserted at the bottom anyway. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:28:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:28:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448036.1664025 (Exim 4.92) (envelope-from ) id 1xGeQ7-0000qO-SR; Tue, 13 Oct 2026 15:28:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448036.1664025; Tue, 13 Oct 2026 15: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 1xGeQ7-0000qH-PY; Tue, 13 Oct 2026 15:28:03 +0000 Received: by outflank-mailman (input) for mailman id 1448036; Tue, 13 Oct 2026 15:28:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGeQ6-0000qB-6J for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:28:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGeQ5-00ADZ1-JM for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:28:01 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace4df6-8faa-0a2a0a5109dd-0a2a4505b9d0-36 for ; Tue, 13 Oct 2026 17:28:01 +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 6ace4e01-4cb1-0a2a45050019-d155802cc83d-3 for ; Tue, 13 Oct 2026 17:28:01 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4956869750eso23509715e9.2 for ; Tue, 13 Oct 2026 08:28: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-4a18be964dfsm365369895e9.7.2026.10.13.08.27.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 08:27: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=1791905281; x=1792510081; 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=N+adB/lSV5aRZCnfxRM1GINh1x+YdY7V7O2gRyvNPaA=; b=L8240Eduu8Gu5V6jZkS+7Nb0cPkYcVezSVpIy15ASfY+ckZ2+kuL/bGwBL/QFOvvw7 rNV28VSVHz4gdX0LDUrlmuxxmHhQYTTy/spm1+n1sRIEe2RztZ6Vs1Or6pjwd3o8vUzd X+Z6gWorKaM0rGLD7MGA+RVn2ySbNw6tXWABZqIFnmmj/wh9gk2H7yB5ou5mgXB3AFs+ QoUMqcIspMUbBlmadiyRsHFPigBUmC2DwmEkSZSjPgX8XwV+FCQu3TNLkH+YACDocP1b VtIzBrDgn5FmSgc4OEMrlfWd/wePPgXCbOpZv4S3aoH5p9Q6tebvQFGTGZnpxLFuRNWZ GqDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791905281; x=1792510081; 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=N+adB/lSV5aRZCnfxRM1GINh1x+YdY7V7O2gRyvNPaA=; b=DeUT5QTa8Z8Yy/+6vqlsEuzpp8m9Ou6JOZwy5OLv17paWPr+WlmXMB4tZaTIfXkq8D da80PL2q6krhb66TTPS8LDh/uj0PxoQDA7mt3bmuKANUiE8t2REVJyywgla/BlTaLf5X V3XV6GBGC5WO4KuzLGX86ltrzVR9Tz089oXBwzseyouaG4INuOezTC9ScS8nzNie4IPf ts7yhycTEN6YSnfoON5AZRPvRdgSC94LNnOkuQrOKsOidxb1rdDyUmglCMngniihBqGr IJg+iIrZvsziNpMlC5e6B2oVPcQukcBh20IP2xSHV5sui7YknFwgC1Ql8qxa2YuUwh41 /56Q== X-Forwarded-Encrypted: i=1; AKwUvBw7Ck4MJd1zLpiE91u4jJrJLxVbMbaeUjI/A61NUfw+T/ImelpX6VkqELUM1gtDCOCkZwAOh16fFYI=@lists.xenproject.org X-Gm-Message-State: AFq9FYLNePhpVUUbU7acVaf6xgk5wR9glJnJyFb/RtvPvTxo7XcQrZ99 layp7JsmPqu2I/V9Zw/Q1YS7JKn9ClKlKW9eGyV1X8C6E95lGZxGxJVR8IucX45sY8CVVO0h1WJ SWors2Q== X-Gm-Gg: AYBFou2BRYdDAXQkBXBelhK8Y6U0E78tvNUGaJCfVHu0TqD3LHtaoC2b0dQhOOh6Fv5 Yxs6/2EPx1tFkbw0dg7OEszx+cD22KdzQRySUyJrIWzCJHDkw8u4QsODEuw6z77QziZ4mbtB9JD WcWqU1ldMprDBHgWwm3EEaZ0Irn3mJAXQTXWnOWRU6WojQ1/L0S79jMig8OFqud8PwfBg4gDKh8 gNHI5BGz/B0mBPzILVLO6NUDcuO3FlNz30xA5FOSrlcVFpov8Sjey2JuOsuzl3ybfULk/QD0mRu Bc/V0qnkTyCrqC5On+ybza0Te61WRZdYxGbU44PbSmdesat8CoAc7Jz9cW1o2yIF6mxiWgWL2bn 0SEObbp+8kSvO7uScGXqFr9J3UcKDdUJcUWlCCkjYqcLMVoTuSUNC2i3aTPhFuIf1xo8X2thikN JrIykgZYsU6UQiLm0qc4gsibtAJV89brRmIA5Bka13G91aEBKO2oiP0U26VDzyzfm0GV0eEAb9D 6N4ie59LvlwVNllMvUgHW5XsG2nVWBqbCaS2O6lc7iLGg+AHYA8uNUD7MdffVp7KnO6ki3czA== X-Received: by 2002:a05:600c:3494:b0:49c:fa20:cc00 with SMTP id 5b1f17b1804b1-4a18e4c3f24mr262227495e9.23.1791905280781; Tue, 13 Oct 2026 08:28:00 -0700 (PDT) Message-ID: <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> Date: Tue, 13 Oct 2026 17:27:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@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: <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791905281-73EB92A1-7C75966D/10/78276251493 X-purgate-type: spam X-purgate-size: 2238 On 13.10.2026 16:32, Baptiste Le Duc wrote: > On 2026-10-13 12:36 +0200, Jan Beulich wrote: >> On 13.10.2026 12:07, Baptiste Le Duc wrote: >>> @@ -620,6 +623,98 @@ static void __init compute_guest_isa(void) >>> panic("Failed to build guest \"riscv,isa\" string\n"); >>> } >>> >>> +static bool __init probe_hw_ad_update(void) >>> +{ >>> + bool updated = false; >>> + unsigned int slot = FIX_MISC; >>> + vaddr_t va = FIXMAP_ADDR(slot); >>> + struct page_info *pg; >>> + pte_t *entry, pte; >>> + mfn_t mfn; >>> + unsigned long tmp; >>> + >>> + pg = alloc_domheap_page(NULL, 0); >>> + if ( !pg ) >>> + return false; >> >> Why would you need a fresh page here? Can't you create a secondary mapping >> of a page already in use (e.g. one from Xen's .data or .bss section, or the >> stack page you're running on)? >> >>> + mfn = page_to_mfn(pg); >>> + >>> + arch_pmap_map(FIX_MISC, mfn); >>> + entry = &xen_fixmap[slot]; >>> + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE); >>> + write_pte(entry, pte); >>> + >>> + flush_tlb_one_local(va); >>> + >>> + asm_inline volatile ( >>> + "1: ld %[tmp], 0(%[va])\n" >>> + " li %[updated], 1\n" >> >> If you mapped the stack page, you could preset a variable there to 1, load >> from the alias mapping of that variable, and then avoid the LI altogether. >> >>> + "2:\n" >>> + ASM_EXTABLE(1b, 2b) >>> + : [tmp] "=&r" (tmp), [updated] "+r" (updated) >>> + : [va] "r" (va) >>> + : "memory" ); >>> + >>> + arch_pmap_unmap(slot); >>> + free_domheap_page(pg); >>> + >>> + return updated; >>> +} >> >> Imo you'd better check that A also was actually set in the PTE. > > If I check that A was set, can I drop the "updated" variable? The A bit > would tell us more than whether the load succeeded. Hmm, I'm inclined to suggest to check both. There's one aspect to consider that I didn't think of earlier: On x86, for example, the bit corresponding to A can also be set speculatively (the bit corresponding to D cannot iirc). If the same is permitted on RISC-V, it cannot be the A bit that you use for probing. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:40:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:40:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448047.1664039 (Exim 4.92) (envelope-from ) id 1xGec2-0003wE-UZ; Tue, 13 Oct 2026 15:40:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448047.1664039; Tue, 13 Oct 2026 15:40: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 1xGec2-0003w5-RX; Tue, 13 Oct 2026 15:40:22 +0000 Received: by outflank-mailman (input) for mailman id 1448047; Tue, 13 Oct 2026 15:40:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGec0-0003vn-RB for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:40:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGec0-00FwiY-7o for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:40:20 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace50a2-2eae-0a2a0a5409dd-0a2a450c9942-42 for ; Tue, 13 Oct 2026 17:40:20 +0200 Received: from [74.125.224.50] (helo=mail-yx1-f50.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace50e3-f479-0a2a450c0019-4a7de032bc53-3 for ; Tue, 13 Oct 2026 17:40:20 +0200 Received: by mail-yx1-f50.google.com with SMTP id 956f58d0204a3-677b5148acaso3022512d50.0 for ; Tue, 13 Oct 2026 08:40: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=linaro.org header.i="@linaro.org" 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=1791906018; cv=none; d=google.com; s=arc-20260327; b=CqMTZ7sDpFpRCnHkATqMJL4aktC9DlG3zllXW5NqAAtOfedtCBw61r3fmaOsQATEba h0fTWqIUmj+v1StGBf7gUywTsQuvbtETnoINFgHnZfwWrGT905EqLyRp1mhqpgpic6PC 2zxcr7uRJdFKl0dlnWUO7N7Yc90luZTWtHYGJ0Ud0fFRmLNmceE0tQXCfC6X1Mtz5M55 NN/rE6VD1z7IMAqNnpURPnAkNWJepVS4DTk2/WQvjqzuKPFIX9KRSdGmGhll1RU4lU7U HjACbvj/jJHY6czH1Ze28deH6X4I1mjQdLAWzFXvHsCnlqF0qyKw5Rap4lcFYl6gxobX j4uQ== 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=7nlBlArFve0HJmN8yN8NWx2yCMMfhH01nmfaIpVhzEU=; fh=UMniVy577JGlzHgVgeG3Qryg5FlMJg4uPMhLeeNfZfM=; b=T4P/cRSzROIFXTP6sLvuzBTF4VcWP4Jz66hpMKB7TJWBq3hURTSZF7bxAXSjpIHH37 iow98wfqEf+KsVQn1eN4EyR66csuV1mB9y+T/l4co0wIWsiwUbXnV8WRmqpEuqg9cgf4 nB4lxE4Flg0homNRL7Ao4PhtKDP14Sn4TlqjOs9pxGbKO9+EB4/YSx+G8XjaDSWApb/c 34kYlJ0rVB9IurCIQtv16fK7eOcLnd3Ekpq9rypuNDmEa/wT9cWQ/iTZGDmu6tKyhTDb i/qnbpmorKjKjYxjDukeap+QD52V46X4cD69Te+OiyeL+BTFkiNxJY7sTxQsXPRsCvPK I5cQ==; 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=1791906018; x=1792510818; 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=7nlBlArFve0HJmN8yN8NWx2yCMMfhH01nmfaIpVhzEU=; b=ZcbYL8+pjsLG66oLh3yW3iZlzTMLaIFeRuXWQSmNmDZo/p7U2w83SdspIC4vocJNQP 1KJLDVq2zxbPbmpaBJCNCp569WJJ3Ge9WYGv/ZXlbKsFPNEO3ZjW7CmLfL6Z1D9pQUZd K9AJKMitPZeQWu+TyeDb6dYCYMH6YEB+2RYY/oXb25yKWuPVEhiEnH0WoQ0baVPTFB24 /Hba9BYVfH2ib2UDhdLjk7wKRWul875mStQ3NGQsOAgmgyelyrAKplZUQph8YWp/Toqa I5bJFRntZJNvBhKvlQxQrf56MazvQSPhA1dtzaRHGuEaqQFjCE69Z0st2ZekFFxs3ZuF nPZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791906018; x=1792510818; 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=7nlBlArFve0HJmN8yN8NWx2yCMMfhH01nmfaIpVhzEU=; b=DD0FeusKAcAgTeW575tU3QUE5EBzaAu7df+xrktvqvr2X2NxqRhLeqKrqcspEezQ8I vqQM/l0K+tqBZn2iuvqve0pBY5UWopXgfVDVnLO45MTnPzdkPFJaF/df7I15bUnhN64F kjwMAIydEi/LUfsdewLgdooUMfbcc6rEp67elEfEEUjqbWzOkl3wjSdd3UmTxgQ36o1e s9egZSuQIdh5MLaeJwkhsbS19NBbA18jxRZip9+1j6K9cpM0k8EatSp0MW3IGxg+rAq1 6jeHeT3a4rXgn99jkcB8PfgfPOA41L7IJqDZql+MpT6Q6TF+ZNrx0lsiendgAdjtUQKk SWvA== X-Forwarded-Encrypted: i=1; AKwUvBx8WY0C6dQ3O9WyoENYHdGnMZlVkDoWoCZsrcf+l2bgJDpKcY6GCQFzYzEiWVXbi9Lxf20rKADRCqk=@lists.xenproject.org X-Gm-Message-State: AFq9FYLkcz5yuZ7U7ujGoug7a9JrxkB2Zcgq8zpHAKenFgxsR5cT+7jd Sj3TBj++MJsODNLwi7z6YzP/XqfuRX0DpLxVpn26Kuc3FOd/TLO6nwGrnqGQktop3gKrE4qY5k6 owVWwxBuCXnTyMqrauGbVQtZYYMdnqKouPJz31AtmBw== X-Gm-Gg: AYBFou12Cjzbh8aFf+gFQNY6j+yX+NmFKXyuj2lMjUO3/RgLasBR3VaioeftWWHMadh /urjP3W3rS/5GgwKsC0SmWGXif8xAtFkfggwB9tzf3uzZWHNnUQwlev6fIMLnrFKdzZXD3drLu1 WhcaPsqhV1OgTsUcyrd7xaKpM4A0munBbRuCMC2G1Zbt4qnPRSgxX901pUMeSuLoaiGgH6zFzLf HZ5Vn6RwxzPADYXUh4DWrUBvqwLk/owuzF6eHVuoiJfiwj8JUZ4kBpr5WeYMNs/+FaOLGFHOoEf dJke5GyotfdqB0YSqShb2kzNMSwLWqKM6Ra35Kjt4FV/KCFfaqhg22Xg8nX2DtG9Ba16Cltea+8 Vsl6O1PV0SY2dZ2K8C/BO+obWvgSsvsfMPIcab1g= X-Received: by 2002:a05:690e:4091:b0:677:a99a:8107 with SMTP id 956f58d0204a3-6793628b68cmr4386999d50.105.1791906018426; Tue, 13 Oct 2026 08:40:18 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-2-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-2-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:40:06 +0100 X-Gm-Features: AclHuK-87uWTjw6PP9kfFnc6AhLREEHYfbaenIc_Hyv-azDLMNc0Tk_TV4qrG5Y Message-ID: Subject: Re: [PATCH 01/22] i8259_internal.h: rename PIC_COMMON to I8259_COMMON To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1791906020-50B3DA5B-EE3F22CF/0/0 X-purgate-type: clean X-purgate-size: 328 On Wed, 16 Sept 2026 at 11:45, Mark Cave-Ayland wrote: > > This is to emphasise that child types of PIC_COMMON are all instances of an > an 8259 PIC. > > Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:40:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:40:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448050.1664049 (Exim 4.92) (envelope-from ) id 1xGeca-0004Na-9H; Tue, 13 Oct 2026 15:40:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448050.1664049; Tue, 13 Oct 2026 15: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 1xGeca-0004NO-5V; Tue, 13 Oct 2026 15:40:56 +0000 Received: by outflank-mailman (input) for mailman id 1448050; Tue, 13 Oct 2026 15:40:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGecZ-0004N7-EA for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:40:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGecY-00DVoj-RI for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:40:54 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5105-bab6-0a2a0a5309dd-0a2a4501cb40-2 for ; Tue, 13 Oct 2026 17:40:54 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5105-5984-0a2a45010019-d15580acc418-3 for ; Tue, 13 Oct 2026 17:40:54 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-885cf67963eso24236967b3.0 for ; Tue, 13 Oct 2026 08:40: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-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1791906053; cv=none; d=google.com; s=arc-20260327; b=qE3QfvjlupPJLD9azoSmCBQMMiXRgdDvryL6FbHKEVwGJHv+fbodAxoYiGN6Cximgo mxDrIdXRxiTG4J6g0K8oc7I8g/6qbhKtOWW13uQSMbHfl74rrY3a0jos1+PniJwdldnd 46COmwYIFnyxnMP42ueCplv1u2JNfB7MSw43NSQ6TzAxGF1w42g51X9XL7wZ4rQJjyUz 0NM3c+sG1D8tQkHBXzJ8BvT4KvarL2nHh3qwOg3R4y5MP7XR7ReaZE3376kmRTWzd3Ib kQ5FwxI+plvJii6ThGIZSovLaHKrNLTWqUxwD6PL9iQph0Skz7aMLH3TlE2HWg28oUbn JpWw== 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=Xl4zRxtbD4rZ1QPQ9stJXKNnuMepND9L/DXbpKoF8Eg=; fh=fgQKDctxAI5TI6zXWYRConjB89fdqUcvPsob07+javM=; b=boBTgFZJvo0VtFtXmE+nkO2EvzcenmzDet9i+68BxQ+aqjhlKgqckL6TsAnaorVlWn JdteeQQ1bnIU2SNILzo5c5VIjnHRJwXph5CLczRMJyCrqi/2wyVDXNgaJ4cYk2irFJN9 /CsgPBt5uqwyGfY+N3efihdaYdo2893dlViNqj01Wmm7a4HOhmWLS3hnpUGSq7mA5F1p JFyvkuP8k5QyfaBHN/QI5b9i7vOR/P5hh89IcJiTNC8vXwGv1WKd4I6dTyqQh3d8HOhL QVBBxszYwqpotpZlCOYee7S1BvywXW7UL16abVdbgUk+mEbLG9iyCaRdE3/O7g7JUIn9 rc4g==; 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=1791906053; x=1792510853; 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=Xl4zRxtbD4rZ1QPQ9stJXKNnuMepND9L/DXbpKoF8Eg=; b=CjVAqVjTE1FGtkOEvdEyaWlJUkMxC8B4IJTPoiFKX0wzLO4pMipKSm1GmiiWwha3Ma M8nB7fNiBg7ImuOACF4A5eGyw1FZ/oS4gKpS9TWdXkKVu6CMpUP50RBV7Dtal/C9bxFc Kzo9RUucCka2WHqv5sAuR2BDieYc8yvN6Zi1fLqFiIfIWt6r16l/qnFxaaR8/mKSzTUD NYOxDFkrNqSSBO38IH0qiz/P+w9vj2wBfBGwF+cFxVXlAsXzH2hqO+CcfWOxWbLwlyUa SD0C1KdxjQXT7rRVUDW/b8DuuLKzeq8EvTA2Rn9iGSKipxOpBNJAZO5r8bvX9W9OdrtR WmKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791906053; x=1792510853; 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=Xl4zRxtbD4rZ1QPQ9stJXKNnuMepND9L/DXbpKoF8Eg=; b=wstv/rVZs9NOMv4SmdM/PObwQW4TijxLaULmmI4MrcLCr4vfpJx0UqwUF87VjQwFQq zpvThxkGcO1QNhCGQb7YrKNtw8xTkJSgAswJqX8VEZ5Ls+88oqpZRY7XB58VhnvLa72J 4GsHy+nhg8f1B1/a0tVcJKtwHyo5z2u6b/lZZa/KxD1ozs1eATHnV0K0Ua9OIF4mnrHj ULHSYOKr1TlsQEUzZs5MINbdgIc/bOEue22jSEXEQ+HPYkmYjI3tLdz1CmtP+HRDMfQq sRq0BX+9SjGj9JKCettHH2yOkJB9Rk/YI+Jm2Mo0Ck/A1gZ7/YcFIwtl/P7NlTZXkwUv XEvQ== X-Forwarded-Encrypted: i=1; AKwUvBz7T82A8TFLoVUR3yVsixz6dl7aXkXqUI9b0Qi0ZfvGXOJcF0V4uHVr29Raf1OGqBMmmZph4bKr3Zo=@lists.xenproject.org X-Gm-Message-State: AFq9FYKdzi8ebX+99gM7VQIt3UUdmOzdIjyKBH134No1uCZttwpubSyR rscCk8vXAcWBwB2j1xM+ws3N2EblqdZA3+g7V0X1FeVaotHNLR9/hwucmYOGfjXEImWwyAVs5zs BjPq3rnYa7kH+Ai0lj1IMtS38G5QBU/LrLFmCK3Al2Q== X-Gm-Gg: AYBFou06NXKNCSqNKcpRBd0TujoBSXu3La3bHQRGD4sQGr3pTatc/G+GIXBu7gCHcB5 9sUwYaiFdwawmPqZgFM4kdbqIO/gJ3Ap0+NOfyc3qVaaj8kN5sjsIvUCVj8tz1hQgCOuvopHgyc x478tZA379F/jYAK0qEecIgbySga4ZmPs2c8thPc9tzKW6vRvnwQhXfYkQMEwOhX1Y/k9xXRCqz HnqC74WwbAXNB1ozjIDuxCQs9dhZ1v2Txt5L9xD0r6kIWDvgg0Ivl12HbtSKdkez8ZOWf5zIjvt OdP4RCJDDYvv7el1yGL8oM53bSWJsrtE6/naWOgXOmsfCrC8ot3/xXQZUosgcGECJkdB6xuGRHD 2/0AbQ3rBaW6saetjOSidOdEI8o+9W320Gco/hbk= X-Received: by 2002:a05:690c:e145:b0:8a8:7fda:15db with SMTP id 00721157ae682-8b07edb0b40mr36974837b3.22.1791906053032; Tue, 13 Oct 2026 08:40:53 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-4-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-4-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:40:40 +0100 X-Gm-Features: AclHuK8SESetnPbkPIzW7fzFCm5Cs0Lztvlg79zYn30l_K_hxeD1jY48AGkU2b4 Message-ID: Subject: Re: [PATCH 03/22] i8259_internal.h: rename PICCommonState to I8259CommonState To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d62444/1791906054-1D272757-849B1037/0/0 X-purgate-type: clean X-purgate-size: 574 On Wed, 16 Sept 2026 at 11:47, Mark Cave-Ayland wrote: > > 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(-) > Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:41:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:41:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448056.1664057 (Exim 4.92) (envelope-from ) id 1xGedW-0004wt-Ib; Tue, 13 Oct 2026 15:41:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448056.1664057; Tue, 13 Oct 2026 15: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 1xGedW-0004wm-FF; Tue, 13 Oct 2026 15:41:54 +0000 Received: by outflank-mailman (input) for mailman id 1448056; Tue, 13 Oct 2026 15:41:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGedV-0004wR-5p for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:41:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGedU-00Dt7I-BY for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:41:52 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5140-8faa-0a2a0a5109dd-0a2a45099946-0 for ; Tue, 13 Oct 2026 17:41:52 +0200 Received: from [74.125.224.42] (helo=mail-yx1-f42.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace513f-be1a-0a2a45090019-4a7de02ad886-3 for ; Tue, 13 Oct 2026 17:41:52 +0200 Received: by mail-yx1-f42.google.com with SMTP id 956f58d0204a3-679334baa1fso2484681d50.2 for ; Tue, 13 Oct 2026 08: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=linaro.org header.i="@linaro.org" 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=1791906111; cv=none; d=google.com; s=arc-20260327; b=XwbcBF1Bws5FjXCER3tsRaCyHIft3F0RKHimi9hz9k+RrcMSKg6t7b/sGXYHL/9jd2 jTC8pLXvG+JNOgufjln7CwX/b/O/fb+Z6YMcyjqmHn9oXCaxR29uZdNj9sTAEEOkSgvE DAiftet27bNDVxRkmJjGP3Rv75AkFHE/xSbLRCAHmczBi3ezRSK92XTcLyN8poPaUNVg lXhiXVqvmQopsn6kN4B3eBt1UmZuiC9YermmNYizjusoj2Ik196BI6hVYZD58phPtyDU UtZhZlMnMboKJxb8hF6beSExdN0a9O8Y+BG9Uz1M68zoWVm7GdcYvl6sKurElS4lSnJW cvVg== 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=/y32TPfvpVgGIoKvh7+P09B6jQ5P/y+ctFLf2J9HI1g=; fh=lXrDPzAEzj0Gw8S2EQqZ7WoXPo/Bne6vsqMMHnhZ57w=; b=TL+si3Di72tZNt1Xn6PSNR2t2/PIe2+1b4d8KzxLtLSw89fLYsTG0GxueGDQyVnFym 4H3l0FKnvK2BlseEVs0J1mxTwVZZUm/Bw4+Z8P86NL7YOsOoTRCi0kaD5cnEb4vTndLu jQFDNgkVxspG22YVHneXyHvb3V0ZFBAbfUBK9GDR7juVQOVa79nkutp1H+iJpYMZ76G4 h5XXL2uzqOKs97agXhfAaCcX4ApCTIJ1/X2I+KkY2tcuGsypYQ6yizPDTx5Q2L6witNu P2vRBIn4OW1k5Y6P8mroJNT0hXa5HjzPTug9x9PJSD6MnXX1Q67XDRz2lORjDDKs4qHV 7B2w==; 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=1791906111; x=1792510911; 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=/y32TPfvpVgGIoKvh7+P09B6jQ5P/y+ctFLf2J9HI1g=; b=lLIIjwL14tLNcLCyuQBKZmfPtVkin4WaVM59X22yiU8a9rd4muWmE5MBiR7Nqj/rSc OMlrRMQNzTe0rO6jf8v5gzoeNjxWgxYgnMqDx/14J0v8XDre5YdqUNE3chHtvqiYSqcC cbl8agZrnPL77aCQPN2kb7fMw+5nWTPtTCmNMWp0E3wOq83lcdl6W9Vbmkg9wKpOuCYV S1XG2q3iBNIppxjRQW+YOx6/NNwHBblIDs3qRlQaB+fB5/VWnybZZ4acclrcb4hrur9U 5va8Hr7HeE7Jsnz2DFZ524k0YhzCLLYrlu3tA7+y/hwNx+lg1hS0r4RFSTU6TubTTlww JSLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791906111; x=1792510911; 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=/y32TPfvpVgGIoKvh7+P09B6jQ5P/y+ctFLf2J9HI1g=; b=IWI8i81nVJ1/wp6gS7gkf8arW50TBIAqt21grMv9GSKM4GvpwFNZ0gSNX2SjkNw8La c+iWkOblCLoawBftmneyifzam7yenO8RJoOq3Ru9yfDHjQHbs9XadRE+8c5d0KbEUSmq N6R8/CpQppFDh3mOSEHooRt4Q76oYk4ZV+CjZA2BWnUL4TPCtE5cj6GSfJbW/RdfTE/7 Ph4FpGdwLEFWphXm9RurQSMWV3m5KLFSwkwldiy+vJzX6+idMiZ0MiW/9Pkmev8Tz+lU BfPYbvRmoEjpYHKQWze54tKXmU+OkBCouAZgVrMhhgYyPzb2abiEZxHMVZeI95Vm2XtB aUoQ== X-Forwarded-Encrypted: i=1; AKwUvByTBjkl2JDzDXmE0VOJar17r66+2qTD31ji2xSoM5Pu0KNqAwZbd2ZIk7HtoOYwNIZhh6u5defMShs=@lists.xenproject.org X-Gm-Message-State: AFq9FYKIsClldoUtQ4ykneC1B70hJqa2guKODgfpd+luTRKZcj5pyNSQ aU6YvFWIukW4Lgyr3PAMjfKIRNlVLZlB3sIrOlQKF5KvYUNLbpsWb0s4neNTJrmR0DnxtpiXSmk 2I+O4lRrlrqmf7oLm1+pLWE+oZGlBUNqHQy6bKWHP7A== X-Gm-Gg: AYBFou0gQrYce6exmTtpCpK4q+Jt0GXtVtFsWG/1khG1VcaE4zUnrgeMsXBhPbmjuKN OoEKn/OuTxtIhhsMO1KYAcuxU/B8hpkQRJvfJKNB+lw0vlMhQmhGPqq2Krp4diGhkU8o+z4TCMw MaX1LxWPII2gjq+biqXcaRlFstsh02L6ajSozOIItLfs/4NYsuZCd92+Vewei//7cF89lCjVzfo ldgXohJjIOsytQIXYT8kz1tYxQ2eIjJM4PPoEe78c85Zy4SogrY+EJiOEe0lWS40Aluor3edM5N r2UQMKvYzPL46Tfs/wQTDkNzbRSNmtT478kEqDzxoEcenqObt296HWzjRJPHKvj+p1f5yVTpY1W YxiOj4YccH5Wa8K2Ss26SypZ/WzzQ4bhRuoe7+oo= X-Received: by 2002:a05:690e:148b:b0:672:99e0:ebfe with SMTP id 956f58d0204a3-67936346e62mr3002172d50.150.1791906110511; Tue, 13 Oct 2026 08:41:50 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-3-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-3-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:41:36 +0100 X-Gm-Features: AclHuK__b2UbCjZFZDrffJnvH_-1ukAWp5TaM48C8WqZ5JfCRPxpvF1PnMp4eNs Message-ID: Subject: Re: [PATCH 02/22] i8259_internal.h: rename TYPE_I8259_COMMON to i8259-common To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-bad1c0/1791906112-BD6C2034-FB1F0002/0/0 X-purgate-type: clean X-purgate-size: 555 On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland wrote: > > 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(-) Reviewed-by: Peter Maydell (I checked that we don't use the typename in a vmstate struct name, so renaming won't accidentally break migration compat) thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:42:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:42:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448060.1664066 (Exim 4.92) (envelope-from ) id 1xGedy-0005Lu-Oo; Tue, 13 Oct 2026 15:42:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448060.1664066; Tue, 13 Oct 2026 15:42: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 1xGedy-0005Ln-MM; Tue, 13 Oct 2026 15:42:22 +0000 Received: by outflank-mailman (input) for mailman id 1448060; Tue, 13 Oct 2026 15:42:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGedx-0005KM-Jl for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:42:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGedx-001hrE-0e for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:42:21 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace514d-bab6-0a2a0a5309dd-0a2a4503a784-12 for ; Tue, 13 Oct 2026 17:42:20 +0200 Received: from [209.85.128.179] (helo=mail-yw1-f179.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace515b-fae8-0a2a45030019-d15580b3d5f9-3 for ; Tue, 13 Oct 2026 17:42:20 +0200 Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-888cbacf70eso36769887b3.1 for ; Tue, 13 Oct 2026 08:42: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=linaro.org header.i="@linaro.org" 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=1791906139; cv=none; d=google.com; s=arc-20260327; b=JKXaZ3pR9xxQAnZ93xSHXgVNLyvzrzQnM6ErjCFwjw+SELYtjxJdeL2cCTTMlpyJTy x1x8p1YWxBp0MMU7/xFy45dBtHoG1Wbx0z9Ym5Bu2rIUI0wF3BsXL7+3Esiq0bnxBqJY LC25xUO/yFiqyzTpROC6M48x6mtTDr6rSWz4yDDLyd8UA+9959iV9jB1NC4nD/yozUSO 0HGZGROtpvUMYjSRNE/k8y0KSGc4cx4bt8zpPzOcLAhhvsJWnqJa5jwWQi8ibLpOBWtI wkcaMHfaYOQTvrvQ97SzMIfGEM+Z8JZzlmfcak1zmZjLdJL0qMXIoVZgaP0JQ7EuvcZ9 w0qQ== 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=Rm0LyYlJ+YzNGdvtjIb3BVxriPsy574YHZ4IY77q+sA=; fh=1z0eNiLUr5Ed0zexgTkBekzCx/6ZMToTOzssRSDUExM=; b=QKiL4G+7c+1D8lK1PQDj1ddc9rUrstXQUhepq9dtW+m9H15YUva0VJMx+2nzKoCPLq mrg09AZwpFe1J+5nbPS51RqPNYgiZYnRJxcLjYzhMd/JZKOLyXFk74y4IgFU5hY9Ix3r 1ZXuD+xW1iB6w5cfpmYbpobBzPtF0uvdsLynKJU45C2Cf6iuSjvfYa+TcuvEL/reNuxF +yn1ZnqVvEsGfazWeKYEvjsPAhHAO8VT2vjj9zgkh7iw2ZlWtzTgAD1LffRejYGX1JSa N872R3bgHa1O1Cu+3FGKNe4mV9X7BW/3uuBmi3YvmknPBjd03QwYdB2iLgJRCVMQSytr +Rkg==; 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=1791906139; x=1792510939; 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=Rm0LyYlJ+YzNGdvtjIb3BVxriPsy574YHZ4IY77q+sA=; b=CWpslIwxz/9jQtgmekiwyYup3MDVLtwLjbhpkUtilcXW177k/Hd/GbK0feRKKo/R3+ xJzvOX7j6ufii0gbYxC3lL61NpWHqTcd05JyAvpD0OgjGBhYWTbL+9dIm41jGYCaRdq9 imOJ5G9LhEQTFddEAlxy9HqCpzlfv3Nkpn40HC2vC+lnvM2MjOkq/7/8/nIHelta3FQZ t0gr+642QB7yFuR4IgJGo9hQusrlqVrBP/B8eDBuMAcdAodKxlJ9o/EV8nPTHPQsxP5A HzrlnUIl46NgcoOVS5PqDjdMVJOZ4tO1igWOcTynH3F2COn88XpYTm2SD3OxFOEERZAk NQgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791906139; x=1792510939; 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=Rm0LyYlJ+YzNGdvtjIb3BVxriPsy574YHZ4IY77q+sA=; b=YDe4OHIRX/SffYO2e01QdM0wBbj9bR5P6ka9VNDKK7WRTIW4ntkmZBHUyqC2ntca/9 ARWUVBzdKTs1B4FxKwgzMMhqCbqn9F/FxSuohqDvf9lgHw2foOl62XCuSeFt/BO3YAfk X2ahUEBjpSnE5nOrNr4S2ckGy6CZ+yFpj8bXJmUmi4uYFzOqv6EyC+XaB1KZCaLDKv1w VWdB80ihmHLYwwh3GGqaQ4DVPCm3zguszVnyjdHrOGAvRhYs+W9+uIH54Xdk9bCfynZK iZy01bNzOSdbLtqtLHlvEDQpwkmU7mpTyGdwBzkY0tZKZoNzw5UiV5ge4wUm7flSdYuN CIgA== X-Forwarded-Encrypted: i=1; AKwUvBy/Xyh0PF5m4amMisK13j/ui/da73km7ELgE1oimxJ/e/etcfrNESqfrUoo64Yb5QhXLfgwfjxipTI=@lists.xenproject.org X-Gm-Message-State: AFq9FYJN4rAsodki8jCNHPNl5e3ZPXDmhZQu6zwpV2rbZFj9XmMthnhZ OcUVa/WShdP4Z0ypxqSFinkKV6ieNQFvpElGyyH6S8XjMDD/DTOVrQRCwr2C58DtUwR31ZjTF/r MZMPtB7iGLXmTMwYmoG60WjxTn2+aDseuJtcmA82Zfw== X-Gm-Gg: AYBFou2SOObp0uzIjk+xbqSO4y9lAAnLKAwXOdnAxC7mu2/SM9r6Y2npy0XOEJncrku c3bD+x4Y1QfFLCsjjAz5vqKkSlJJ2DUw7A8t4zf7+zz7nNfzAVZbmP/fbqchJ2Siw52IFSoaNlB wUJmFsUKuSvxhw5h1PsxHe54I4UWVQ5bJxvQpT5/mIGuJPGG/4dp/zgGzeR5aUTZXexqHQHV1zN +aVICp8mizDCLez+sKpzfbjMpeeT7rbIuw5UnarkZ9gflZUn7VTRk2LEkTB740PhGN6KMG6ZBBn deuCu3ggUuvKW50NF8tcCI3LOSSD46r4EWwqsZl0I0HGLzjXE9FuEhUKonLcXSJTjZwXFGDymow 7oEFhg6KJp33GcDbtGskATWrw98O1slvwkw8SrH4= X-Received: by 2002:a05:690c:3685:b0:87a:c454:6d67 with SMTP id 00721157ae682-8b07ee526b0mr38663537b3.52.1791906139243; Tue, 13 Oct 2026 08:42:19 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-5-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-5-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:42:07 +0100 X-Gm-Features: AclHuK9bqSLzLVQB4VCGAk6mL6XXtifWp7anaSaKyJr9Tn_7wu7r2UfWe3SiG8s Message-ID: Subject: Re: [PATCH 04/22] i8259_internal.h: rename PICCommonClass to I8259CommonClass To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-33051d/1791906140-6F4C74E9-423DB5A6/0/0 X-purgate-type: clean X-purgate-size: 470 On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland wrote: > > 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(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:48:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:48:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448079.1664110 (Exim 4.92) (envelope-from ) id 1xGek3-0006VU-Oy; Tue, 13 Oct 2026 15:48:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448079.1664110; Tue, 13 Oct 2026 15: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 1xGek3-0006VN-M8; Tue, 13 Oct 2026 15:48:39 +0000 Received: by outflank-mailman (input) for mailman id 1448079; Tue, 13 Oct 2026 15:48:38 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGek2-0006VH-06 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:48:38 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGek2-00000003RcM-0kZ3 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:48:37 +0000 Received: from mail-lj1-f182.google.com ([209.85.208.182]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGek1-00000003a53-1vCf for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:48:37 +0000 Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-3a9c92ae2baso25722701fa.3 for ; Tue, 13 Oct 2026 08:48: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" 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=b1gLppnw973pyALDGv3yX2duTrhwU3is9vl2LGizV84=; b=0dWUp4U5Rl10I/rAYKqrR3PbJn akr6I8tyadazB2vPs5r4zYOmErV8HGaVSFJ9gIpOpqDNHb9T0dPdhvI0hX3IrCh9OU9pCuUfXtsz3 xCaOo5fVS3RBExrvkV0ao7KCuXU5Zv/Kw0P9hxdqmbkopaT0w7+eraW2sNFkQ5+1+VcI=; X-Forwarded-Encrypted: i=1; AKwUvBw03+nZ5o+fcE7PUcQJkKJMWJ2aiJZr21AV4eCJvPULxBk/CV7aPxTKysXsIS+hAQNsRLo1Bd/DcnU=@lists.xenproject.org X-Gm-Message-State: AFq9FYLcBLT+v/KiRZeunYN1Di4nkFGEtJM82v7YeyfzM0ngMeu2Bzrl RCGlpxmCo6JwJP5Scxxfz/0hCSL3BWwre1YTqAEaCwpRyjbYSJrcNFnvC0Wdkx2JBTdJKpCObzR BzAzRCMRLLZi1c9LJJZMEM2JeYquHtmg= X-Received: by 2002:a2e:be25:0:b0:3a9:7d11:a790 with SMTP id 38308e7fff4ca-3a9c56f09aamr34192141fa.21.1791906516525; Tue, 13 Oct 2026 08:48:36 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-9-gwd@xenproject.org> <8514b7b6-cf1c-44d9-827c-675fd5a6708e@suse.com> <43f7a948-669f-48cb-8e1f-9d1a8a98a8f5@suse.com> <71f51ddc-3034-4501-b532-e76eb9f898ba@suse.com> In-Reply-To: <71f51ddc-3034-4501-b532-e76eb9f898ba@suse.com> From: George Dunlap Date: Tue, 13 Oct 2026 16:48:23 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_qBAlEjSkNMx6DoTYKTB_F5w96JoVxjOCe2kNFohYEcIujYaZPGzfR6mw Message-ID: Subject: Re: [PATCH v3 08/18] x86/domain_page: prepare the mapcache for per-vCPU accounting To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 13, 2026 at 12:57=E2=80=AFPM Jan Beulich wr= ote: > > On 13.10.2026 11:53, George Dunlap wrote: > > On Tue, Oct 13, 2026 at 7:26=E2=80=AFAM Jan Beulich = wrote: > >> > >> On 12.10.2026 18:07, George Dunlap wrote: > >>> On Mon, Oct 12, 2026 at 2:48=E2=80=AFPM Jan Beulich wrote: > >>>>> @@ -74,12 +130,12 @@ void *map_domain_page(mfn_t mfn) > >>>>> #endif > >>>>> > >>>>> v =3D mapcache_current_vcpu(); > >>>>> - if ( !v || !is_pv_vcpu(v) ) > >>>>> + if ( !v ) > >>>>> return mfn_to_virt(mfn_x(mfn)); > >>>> > >>>> I don't quite understand why this is_pv_vcpu() is okay to drop. What > >>>> mapcache_current_vcpu() returns isn't what it ran is_pv_vcpu() on. (= Same > >>>> in unmap_domain_page() then, obviously.) > >>> > >>> So mapcache_current_vcpu() is a bit weird; the actual invariant is, > >>> "Return the vcpu whose cache structure we should use if present; or > >>> NULL if there's no cache structure to check and no need to sync." So > >>> if pgtable_vcpu is HVM, return NULL and just use the raw address, > >> > >> I was going to say "But there's no returning of NULL there if > >> pgtable_vcpu is HVM, at least not at this point of the series." Only > >> then I realized that I was being confused by there being both v and > >> curr, and neither of them being pointer-to-const (i.e. both being > >> equal in terms of which of the two might be returned from the function= , > >> yet as a result of earlier changes neither is being returned anymore). > >> > >>> because at this point in the series, both HVM and the idle domain hav= e > >>> full directmaps; if pgtable_vcpu is PV, then maybe sync, and then > >>> return the result of the sync. That may be a PV domain with a > >>> mapcache, or an idle domain with no mapcache, but in either case you > >>> can then read cache.inuse to see if there's something there. > >>> > >>> So yes, it's a different vCPU; but it's still defined in such a way t= o > >>> be safe to check cache.inuse. The only possible value *change* after > >>> a sync is the idle domain; I don't think we need to do another check > >>> to make sure it's still a PV domain. > >> > >> Yet then - aren't the is_pv_vcpu() you drop here redundant already > >> before this patch/series? In which case (since it's not entirely > >> straightforward to reason about and beneficial in its own right), > >> might it make sense to have this be a separate change, with (in > >> particular) dedicated justification? (ISTR having thought about > >> making a patch to this effect a little while ago - perhaps around when > >> Roger last touched this logic -, but then deciding that something was > >> wrong about my reasoning. That may have been a mistake, as it looks > >> now.) > >> > >>> In fact, there's an argument that we should modify > >>> mapcache_current_vcpu() to take pointers to dcache, and vcache, and > >>> return just cache; that gets rid of v as a local variable of > >>> map_domain_page entirely, and makes the logic ("get the cache we > >>> should use") more clean, and gets rid of one mfn_to_virt() instance. > >>> That would require some non-trivial changes, so I'd rather avoid that= , > >>> but I can do it if you want. > >> > >> Sounds entirely plausible, but can as well be done as cleanup later. > > > > I'm a bit confused about what, if any, change you're requesting here. > > Are you requesting a preparatory patch just removing the is_pv_vcpu(), > > with an argument as to why it's redundant? Or are you OK with having > > this cleanup work be put until later? Or do you want me to put the > > is_pv_vcpu() back until we feel like cleaning it up properly? > > Now the confusion is on my side: Aren't what you suggested as further > cleanup and the dropping of the is_pv_vcpu() independent? If it had > been just your first question, I would have said "yes, if possible". > But the following question starting with "Or" is irritating. Yes, > that _other_ cleanup work can (as I thought you also suggested) be > deferred. > > Putting back the is_pv_vcpu() isn't really necessary, as long as > their removal can be properly justified. (Hence why I think that would > be better as a separate change.) I've added a new patch. -George From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:52:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:52:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448088.1664119 (Exim 4.92) (envelope-from ) id 1xGeo0-0008Jt-76; Tue, 13 Oct 2026 15:52:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448088.1664119; Tue, 13 Oct 2026 15: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 1xGeo0-0008Jm-4e; Tue, 13 Oct 2026 15:52:44 +0000 Received: by outflank-mailman (input) for mailman id 1448088; Tue, 13 Oct 2026 15:52:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGeny-0008Jg-SS for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:52:42 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGeny-00000003Rgr-3ZDr; Tue, 13 Oct 2026 15:52:42 +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.98.2) (envelope-from ) id 1xGenx-00000003hGn-3PiW; Tue, 13 Oct 2026 15:52: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=bbqIHxEuhtBWwZ6mOUDTm5ir4iWLuI8EVwb/Fcu67tU=; b=hv/RmbguXABsqZTtx9S6znnMwG fuH2dSOqBTeMOmQjlsO6RyA0ZIpOWrvNqTPm4mTxBFiXc/TE7bxMZ9sCw/vWAuOT4hr3WNvEFqsN0 YbPtBE17yoS0i1cdEzKXJk6MkQT1YPpxVLtOWxeteJHxVfc7S+92pS2Go40G5WEG+7rE=; Date: Tue, 13 Oct 2026 17:52:40 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 08/15] x86/PVH: split pvh_setup_acpi() Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Mon, Oct 12, 2026 at 10:23:16AM +0200, Jan Beulich wrote: > All E820 manipulations want to happen before the initrd is placed, or else > pvh_steal_ram() may steal from the tail part of it. As a second step, > split placing ACPI data from actually populating it. Would it be less intrusive to duplicate the memory map (like it's done in a change ahead of this one), and subtract the kernel and initrd region from that memory map, then use it as the basis for pvh_steal_ram()? We could adjust/replace pvh_add_mem_range() so it allows changing regions from RAM to other types. That would seem to be less churn overall. Maybe you did already consider this and found further problem with this approach that I'm failing to see? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:55:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:55:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448094.1664128 (Exim 4.92) (envelope-from ) id 1xGeqF-0000Xi-M6; Tue, 13 Oct 2026 15:55:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448094.1664128; Tue, 13 Oct 2026 15: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 1xGeqF-0000Xb-JR; Tue, 13 Oct 2026 15:55:03 +0000 Received: by outflank-mailman (input) for mailman id 1448094; Tue, 13 Oct 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 1xGeqE-0000XV-Tv for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:55:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGeqE-002ZlD-2X for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:55:02 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace544e-8faa-0a2a0a5109dd-0a2a4504d2aa-24 for ; Tue, 13 Oct 2026 17:55:02 +0200 Received: from [209.85.128.181] (helo=mail-yw1-f181.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5453-b57f-0a2a45040019-d15580b5d068-3 for ; Tue, 13 Oct 2026 17:55:00 +0200 Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-87ab6e5f91eso20189957b3.2 for ; Tue, 13 Oct 2026 08:54: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=linaro.org header.i="@linaro.org" 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=1791906899; cv=none; d=google.com; s=arc-20260327; b=XKhBcxyA0VLq25NAA/P3IKLEPFKJ+5N8YvJ/v+1qG4dHRjpPfPfR3GYWn2rnU59JYG nfROq1rCI7YM5FQ/uKcVmJ4jrySQIGGIVQzGcVGLnbeEVhrw22G4xrW4vPPs3gpbuEri /dI4aLPCT5uRDBpD+wEVBx8vDJv9/pWfsadir/NfOuFwkVhDmDHDHjt1Dpw8FaizuiJD +/5ltRjeXur4QkAdh2MwgNSi/6i9lPfrdbfmZSdg0ksy0wPwoa+97t5Zn6cbtmMkqsd1 PPqozjXyinP4EaKiZtwRu6LT3V2Hf3Tu3Zj/9AKGdnrGtmKhlLbsXqthYh95mCmt2Eek Ya2Q== 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=xUX7O0hyhnzIaBL4GI7Fs2xl6p868YhCKfTy7miSTVE=; fh=O8iawPLS+ehX6UAPcVgqxNWbNsAxaElMVazIf4YE99A=; b=QjvF40ipFq3tFAQVHJin7CWaeGsKT5JZZeWiLpA258JrpPTIu+hic7X0zMnL6Tj/hD BCIuQzSuXs8BYAlvpliZLFUIRt+u965paTxL3D9LUHgRjQ+9tTUb4lx/fO+J+gBC4fva oUKO15p14x9xA3E29GPG/N69TDrQDoFqTeyxpd2t3uGs0crp7o4Yq20/3PuswEmHPkdm 6lEN23DBl8GapecbF/X/xhzxeyc/Vv/kKQcth9fbF7bTBCEY+0Vx1I8KfEV2ExLOWJ1U kEodpcW3F1opPNIVRk2EIO81u1EJypgHyzE1sxdYB2dLWHuGzTvZz3yUwObE6XS5P6oT a5UQ==; 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=1791906899; x=1792511699; 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=xUX7O0hyhnzIaBL4GI7Fs2xl6p868YhCKfTy7miSTVE=; b=XCfx68Exjy69HoyC4Q/+tWXP875riZDfC2JX+y1ErMETZ11IL47/UfbIEFN/cQYNO/ ilCpZmJH3FG/XXaPdaJnuSmm8QFohHloQctG1halNj8fcG93KPriOpHH3jU8cMTHQSgz eDlA5qXVy4qe6PYBBD/ohR63PQCA9bs6meKw3ojw+1dBc62ikTIC2+HQXheB2+IjySpL pd+sbSmAZ+1vCz/JV1V8yMquFUdECiyfvU5FXxMVtNdJAPyzdyWTkRljmPLHLCeUCclL yMYUzPFLmPdRVfF8XPV4bnENTHgbKQn29WPAk3a2f+XjAel7EsMerLCNT2PmL+Ou9vIR khjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791906899; x=1792511699; 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=xUX7O0hyhnzIaBL4GI7Fs2xl6p868YhCKfTy7miSTVE=; b=2fhCjfWIsLktvjfXvSf4pHh49aM8fnfRNrluJFprV6XZsKulH68yOU6XuBH7xV5F0x Io0LPMlai83GX0oHo08ID6dL8KoT5+7v5TBbA2j5c1goGXMpctuW8mrfTCTGr9EOJBwE F3zrEppALIjEpx/TJvXO9mV7hmyA3VvcloriONO+O/+vmUdV3pIdj+4J2NOxgBFNwuOt AmQKgZYy3MOlD3vTBePN6z+olFpUsvO8et0Gbhw6Ne7VpzpAfVbbRRYSPu5dStzMEZQq I3W0fM6jSJggPMFdcsTChBpOSQ+6+3QKecDb+Y6md/RfePp2ORYn9167JeJxuERvK04V 9YdA== X-Forwarded-Encrypted: i=1; AKwUvBzMuh4J1aGv6blvWOEJYJRasN5ooYXkRbtePDLfaUvfBBkIPpCwF5MxK/SLLzjlwe/nLzAcdlnqgOA=@lists.xenproject.org X-Gm-Message-State: AFq9FYJTwY70Z4a22LkNQAzUOS4RN7Gklygo34GAzrKBAV7LFCVzxAfO 0BY45TBVgeA9VYLXXEdM/KGj2b4iuReeStg+tdyeOcbw6VJyiAYQhPP9DmfJ2AUQgYRJQOCWCio lBAiHW7IwuhdaLQ1zbyh5keqctk0uHT9A8FwTn01dWw== X-Gm-Gg: AYBFou24YAySuEuEeRS+Ull3JRS2zHMtap0OguJaqA62S13B/tLMQM6GuOxlAbGTtRt qnga0yVs0a84k8OCiCKxiQijw2DG1G/wHF9A20oWDZQ/+8xUPWwIN+o0ibgs33IeIN+/eiMTHvf /8g92qH490H4FDWae2MGYoFHDOVNGT6JgiAxPsBaTRea+eNO8nRvwjFRQmuUUchRpjl/4LKGyBe V+PDCSjcdcwU+iTrXwDVGbgKQx744b1+JwNDA4quUQXcddVGNNsprYNg3KqspkbRM+qS1QfmS66 hpilyvWh55h2PdOUyJoACJORPppPYKI8+YMjVi5pRc3Ow76pQE6FZvSjbatily7AV0bRCogF42A kIqiNxO4sGuCsB6qKVSjxhwcRv/pTyK7aoMgrKhE= X-Received: by 2002:a05:690c:c510:b0:8b0:b0d1:fc47 with SMTP id 00721157ae682-8b0b0d20337mr16623687b3.60.1791906898640; Tue, 13 Oct 2026 08:54:58 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-6-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-6-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:54:46 +0100 X-Gm-Features: AclHuK8tx9cc1Chrkd1VlgBGe_Zyl8Wqsg8OPvfvGLJ1IUyuXdLtJM5RjrH8d_0 Message-ID: Subject: Re: [PATCH 05/22] i8259.c: move parent_realize from PICClass to I8259CommonClass To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1791906900-502E4B50-DCAA0EBD/0/0 X-purgate-type: clean X-purgate-size: 1483 On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland wrote: > > 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 This is one of those things where I think we're not 100% consistent about whether we think the parent_realize field should go in the child class struct or the parent class struct. The name "parent_realize" implies it ought to be in the child struct, though, and I think we do that more often than we put it in the parent class. This also makes some kind of separation-of-concerns sense too: it's the child that knows (a) that it exists at all and that (b) it wants to have a realize method that will mean it needs to chain back to the parent. The docs for device_class_set_parent_realize() claim the parent realize ptr is stored "usually in the instance structure" which I think is just completely wrong. I could be persuaded otherwise. As usual with QOM/qdev, I'm mostly interested in (a) consistency and (b) documenting what the "right thing" is. Realize, reset and unrealize are the three methods where QOM's lack of convenient support for "child implementation of method will need to chain to parent impl" is most awkward. thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:55:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:55:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448099.1664138 (Exim 4.92) (envelope-from ) id 1xGer2-0000zb-Ue; Tue, 13 Oct 2026 15:55:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448099.1664138; Tue, 13 Oct 2026 15: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 1xGer2-0000zU-RS; Tue, 13 Oct 2026 15:55:52 +0000 Received: by outflank-mailman (input) for mailman id 1448099; Tue, 13 Oct 2026 15:55:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGer2-0000zO-4k for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:55:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGer1-00DYXO-Hm for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:55:51 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace546a-e002-0a2a0a5209dd-0a2a450ca220-46 for ; Tue, 13 Oct 2026 17:55:51 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5486-f479-0a2a450c0019-d15580acec26-3 for ; Tue, 13 Oct 2026 17:55:51 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8a83d2706fdso885077b3.0 for ; Tue, 13 Oct 2026 08:55: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=linaro.org header.i="@linaro.org" 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=1791906950; cv=none; d=google.com; s=arc-20260327; b=srQi02Z8KiK3lAYnnpE3Diq5RAwFxAi0b0zp+dYOwlOhUu/sdXzdDL7abBC9wU7Akj wuxqHPrFgtOygwXYE/9ZmLMa1Bl8GB7RoKRFYbSJV3X4yO43Dt/YQWQKwVumcAxwydhS ikqlEKkW0A70Imz7uivgE3wVaDMW4TKYgcJYJlP1isgdXBwavrNWl6DMy41qUktF2Rx4 xWIPzc4mQUyDyuBtkGBvRcH0Jkdtcq/n4BWSf4Ya/7P8I36H7RZGsBEoccLN8PUt5ZWx hoYYc5uMYCg5QFTd9QYjeIiL4JEp1OU0B4cs5dpGnLEMEwgPZOnj3Ec5CxAtgV+NTYMR jhag== 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=sTgxmuTcgGn5AYnFZDK43ztyH8Gx3aWrWj8nhRhWJTw=; fh=bpFCTF2CjiTLxWTYBhOv/HXVUp10iE4KIRBQOeOiWwI=; b=Q4ZYJgGITDSPpO6tcjN5fm1oX5C7pvLUov9tLyy/vGrDuiWEoPvwk36Q5l2ZvF/RmA jS92easqsaW4FSfEZhpkV5D7wRrfASTg1CcZfTxaabXZ5xDFjiQvokQpt2Q48nWJVNjz PqCncRRVHb4R225YLhetgTag5ikLQs3FugFs71wEKBrWR5kEgMLF4INwwLl4PGOxQbMj hQJ2OJ0JQOOgouw1L7g/0hfZqIw29596LPIjCo0JJ8a96hcSuxCQ9PN26x2sAQJX0Mmz u4FV+cljO+iVrFvP3Qc55+nECQdJNTETZ99C8bk4NP3/lRH4BHHvUQQqp6NE3mt+haJ5 NU2A==; 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=1791906950; x=1792511750; 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=sTgxmuTcgGn5AYnFZDK43ztyH8Gx3aWrWj8nhRhWJTw=; b=Q8V6quUA7Jt+hPL19V5efiUc5p6v+eVcofVszh/hmH7rPTbrsJFvk3C0txx0M9PZgi p2ne7QB5d8BStngFCAmrCpjwZFspiq9kZAM4YaiCWvH2G1oBoy/BiKswwHNW/wF6B34k +OyhKS8vSiOzf6x3EMnnOmALdQNdbn7ns04B0KYunKNdx9KM+0KiiQ5QgdGY17Ejy9b1 bMH2wj7PRPAGDviWJsBeU1tO1DOCTSSB/O5bqqWE9JKJS9hYW2mNByZlkmPxnlTI5/By YocYluvsMiIV3sX+TnX+nKu/jD87zbLnYRFvdTeojZTic7Yt1vxPIgdbd2GvhG3l/QBE yKJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791906950; x=1792511750; 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=sTgxmuTcgGn5AYnFZDK43ztyH8Gx3aWrWj8nhRhWJTw=; b=yHY5atSIVN1eVj4JJSbeAzsiTMHZ9S/yT/fEDss8dLaglNKFxupwbz1P2M2ppc14di OpZYQOWrNwDvxVdcx8XF1zejjqUT+BPaVQ+cx5IAnsWxzZx+I1xMPw5TZJsU/MfKY8yf Kv7Z4/4dmeUhhGy87Ef6McJXcqH4skzLBVcjmnuZMVBsZQWYBYOxF5K4WPLraxSI9q45 sNlQDv6uczwlNVsv/joKcrv5GYZbUHCRRFfVED4vOBBxIB6iD6OwSZjQsqOIqTQifNZu jwuQUByCdJfO8YawexW4KHjuul/fubXl6fiulWA7Rq5jdyVj3SzOictQxo0GeNKxwj5e OKMw== X-Forwarded-Encrypted: i=1; AKwUvBzyzRFsCBxdopV1qXrnZAtIaYO0aFHMsYLi47TR+dK9cnt+hw5/2qLtNwN1Co8MSllJrF2AEDeCIQw=@lists.xenproject.org X-Gm-Message-State: AFq9FYIP7ueLRiAjA+GbeJ4I5lf/qIoUf0l0cp85gClvTKoX1cYXr+yB ltLTdAW/GLCo3J5FERf2XwGAs8PForsFBAKFBTUEUeYCCIufm9CcD0QZFYlNQ5L3ZCN9ClaIhLd ZozNsauMDASnBnL+wvg/eRj4OvB2mCgqRDbNk1HC4tjrgEZEE0zAo5fw= X-Gm-Gg: AYBFou08Sr0KEFgjTRAeqTaVhLxNOClya2Rf6WdDSK51Z435kesCoMvUatHD4IaPpTb 7QBOBOFc74Bl+zpgXtXEYb3hJOsjqz3IMBPR4lavDIsVCW1ZrzAI7/buQpBOuLWSd6A/0ccjwaK svnhsewOweka1DVacPJ8YkkKbkbkPMauXrtSJDyROJT1R3zjfqLBtfISVgeHaSdwIALR7T7RVfK cFyMn3yZnXdaiXETot0DQRdFSCBZBJUOCDx5cYNwxMUgzzHyvbNg1loD2ikix2k+8kyhSYpnUHU F8BT9pPd1dUqmadalNgrbJJ7CfWNRQpK7paExa7o0P3j+l8DMUMUzoOpul++ql40qbgS0sTbIlX tI7PnpFOhYbMX0WiZtqhwenBQ+xwtcr4MLSwJHtM= X-Received: by 2002:a05:690c:6601:b0:854:819:64c9 with SMTP id 00721157ae682-8b07edb5ea4mr42017507b3.30.1791906949876; Tue, 13 Oct 2026 08:55:49 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-8-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-8-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:55:38 +0100 X-Gm-Features: AclHuK9Q8ujVK1Qm61IAieZOwWt08FK4q6LtqNYYH834z9PQmll0ML6FC0JdYeA Message-ID: Subject: Re: [PATCH 07/22] i8259_common.c: use i8259/i8259_common prefix for functions To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1791906951-76ADCA5B-1108CEC2/0/0 X-purgate-type: clean X-purgate-size: 578 On Wed, 16 Sept 2026 at 11:51, Mark Cave-Ayland wrote: > > 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(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:58:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:58:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448106.1664148 (Exim 4.92) (envelope-from ) id 1xGett-0001oU-AZ; Tue, 13 Oct 2026 15:58:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448106.1664148; Tue, 13 Oct 2026 15: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 1xGett-0001oN-6t; Tue, 13 Oct 2026 15:58:49 +0000 Received: by outflank-mailman (input) for mailman id 1448106; Tue, 13 Oct 2026 15:58:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGetr-0001oH-DD for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:58:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGetq-00FzTD-QH for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:58:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5528-8faa-0a2a0a5109dd-0a2a4501d994-14 for ; Tue, 13 Oct 2026 17:58:46 +0200 Received: from [209.85.128.175] (helo=mail-yw1-f175.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5535-5984-0a2a45010019-d15580afd99b-3 for ; Tue, 13 Oct 2026 17:58:46 +0200 Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-8ae8607e8afso21157637b3.3 for ; Tue, 13 Oct 2026 08:58: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=linaro.org header.i="@linaro.org" 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=1791907125; cv=none; d=google.com; s=arc-20260327; b=AZFl+RK2gBK39j6p4BFB/NcJCrGhe5qpEKKkeGTP3HhrThS+WIMkSrs6n9ucwImm0B GBoXGx9ZFAhxppHHUqZFB7M2u+QYBTcGoCWnyrHqBS3P1gMmNFHvPfyO/cW2kVULXpMu u//4Ov3iP9XHpTIC89U8lGdzV6oXJKGbdq23M5YiC7y367DKQ9wlmaeuESOtQt3njeVe r1XAfBaIUhdmZnFLB2WBLfk7vKTMls23U4dGyq39d4Ijhh6pVIUIsVVeNDbKauF+0nlZ ES1GNYh3+uBdV57GgfsrzP8TWH4s1q0attfoh+CUUe4NjdlexD1r+lgTGO9m1WQa7ZQQ Lbbw== 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=DZuhEJteCjiBcxYMsQ5/Kb0n1Eh3plqb2K4/0ypuhTg=; fh=CAgUrIXa0DSX39LmKILE0T8Wu6Oin3YfOZR8uLe6iJQ=; b=qJipOsmNn9sjvVh+KcF6OSrkmf5tcIm8aZ572lg/zoOg724kXbFbV/SWZOqLIQvjWT pSdadYPggwABGwpUyf+/5O3M/DWfWZPmc75YAc/Et5TLAFQj++NT6W71cKwSbuRvnJU2 DlF5GbpI06dsHUc07fH3G3O6fm9v0yuKY6nX2z2W0HlxS1PyIUSEn6lVlLhcH9dKa+ml cx4ewFrP96hDkwrcyYn97vkAax4gOmQDuW13WZD0ayu12wVIuWIycvPLixdQgPmtMkGB nsQj99hDbTAQSuiPm1bfOCoZ9d0BgHH9EZKLDI16lRO2THnsDG3AvN11G7h+oSYjJIB/ QK4A==; 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=1791907125; x=1792511925; 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=DZuhEJteCjiBcxYMsQ5/Kb0n1Eh3plqb2K4/0ypuhTg=; b=OYegPcyEYyjUQm9bNz0Tul+ULOb+Ar2dIT2vt+LGesQJYE3NBBsLLmh9oE2dGYQElj hFDs+aAfhAO8BCqFgL4X/6/OeWWfKq8nNOkFiUV5NyBvk6AnF/dGPl+NnJr8ibyiUAex YyKJj7x7iKgfWhYDZrrOgh3g9ekVa2FsTblQtTShuQntNvAaPFRHrtuGreBIEZlfhQuq uvo41hte7HvazGsgONxiGgvAv/+rJfJrJV8s7sXsbcu+33WhI6jpsCRJ4e31Fm9//4Sp 3vucAHOTksLyx7QRicr6NM+ptvo7+s9OQuW3PNlZU25ImLbcNsbi6Fp9OhO3y/EQ0UYK BSxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791907125; x=1792511925; 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=DZuhEJteCjiBcxYMsQ5/Kb0n1Eh3plqb2K4/0ypuhTg=; b=NHSYF2kXNxZkshjpEDTWgmyNqF1OcX5agkLbcVBdNvOtfCYe4ppE6Qzqp2xPERY6ZH I6jr+E5zhfhKtUnNkC8SbCuY/Fu6uUuTciJQAHdWNZbz3ctbZnrUWuOEKpnC9+T3r0OM w8a3iU8XCMBT3arXrN2zMNWkPocCpJkCo5hobX+Zjn22XpGa9JDohoVXBAHkKh0XZTeY A4OTD0Z8KpYefM2L039gDXNod+AuU5DnfUuApJ+NRUjxoqZeYX3GyuuSq1qupTY9JSK1 zDx/5LDm6CtBchQUQbJvtTF51JyAysCXG2sfNkElqnYx/iSFGAPicvtzYE21dpaPKSLg dPbA== X-Forwarded-Encrypted: i=1; AKwUvBzOOA5yKm6Y7wB9wDBGY+iYT3tBj5dJmIsL8qgYn2ytWsPFAXwv/e6xXo+OgGqbAmnP0ALCnHdPa0U=@lists.xenproject.org X-Gm-Message-State: AFq9FYLtHkPQxlfdDBh+NlozWFdpa0Mt8YatQ8Qw5724p22LeTQ3xLeY n11ZcipTPi08PwX0xTYpIv5iQnOSpaaEa4XFXNZFiVdRvHja7b4tYvyNuJHVSY9RFa0RivCbTGZ p8l6Uc2rZgbO3Bd15PRzhcb+mnrreb3Q0yXtqXh3MSQ== X-Gm-Gg: AYBFou3YV7/K2IyRg+x4G+ZUT4/96LedJA/OX/49by3/Ew+44F0bQ8X/WiGBPujJhfe Trrb4b3m8N+toop7M5qOirGsK1xXwsQ1itLy10eipdfCp2LRbSn3bDIb4j808HN3dmLZhipDta1 0eBUkcv1lsQVJAWpZsCPVHUDyR8shqLLROtotOmAu/fFeGbbH2vHQjPbGANjg4kUx/TScGOeZuW oqGJ9ubvHFu+wxBXxdMIuB0nc8f5avMUJGTZisaVAEo4DKONZk/CrJR7BBTkTrFn2+9ZhY39YR+ ls3m40UgW97tPv2TJ7Y6Qr2i9sew+Xfty/t/G1XuwVUiGKjMj+Bgk9fA49N0jyXZNlVJ8djSoTI 3ELUKNpp6XVQwo7wbsL9ryCNUtjKL1pfmIS4Ew3Q= X-Received: by 2002:a05:690c:c50e:b0:8b0:a496:9e9f with SMTP id 00721157ae682-8b0a496a4d5mr20751777b3.16.1791907125130; Tue, 13 Oct 2026 08:58:45 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-9-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-9-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:58:33 +0100 X-Gm-Features: AclHuK-vJ3MrY9cM47TQWMRigAS6YCJDLH3ew8EymvifUYmGc29Q40zWzPPbrec Message-ID: Subject: Re: [PATCH 08/22] i8259.c: use i8259 prefix for functions To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d62444/1791907126-BCB45757-D98024FD/0/0 X-purgate-type: clean X-purgate-size: 674 On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland wrote: > > This ensures consistency with our normal QOM-based naming convention. > > Signed-off-by: Mark Cave-Ayland > FIXME: rename trace events? I recommend removing FIXME comments before posting patches, it avoids the possibility of reviewers suggesting you do the extra work :-) I don't believe we make any claims about stability of trace event names, so we could rename them. Should be a separate patch if we do, though. For this patch and with the FIXME line removed, Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 15:59:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 15:59:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448108.1664156 (Exim 4.92) (envelope-from ) id 1xGeuH-0002Db-H4; Tue, 13 Oct 2026 15:59:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448108.1664156; Tue, 13 Oct 2026 15:59: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 1xGeuH-0002DT-Dt; Tue, 13 Oct 2026 15:59:13 +0000 Received: by outflank-mailman (input) for mailman id 1448108; Tue, 13 Oct 2026 15:59:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGeuF-0002DB-OI for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:59:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGeuE-00AIKQ-D0 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:59:10 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5536-e002-0a2a0a5209dd-0a2a450c80d6-34 for ; Tue, 13 Oct 2026 17:59:10 +0200 Received: from [209.85.128.179] (helo=mail-yw1-f179.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace554d-f479-0a2a450c0019-d15580b3ecc6-3 for ; Tue, 13 Oct 2026 17:59:10 +0200 Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-8a83d2706fdso931247b3.0 for ; Tue, 13 Oct 2026 08:59: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=linaro.org header.i="@linaro.org" 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=1791907149; cv=none; d=google.com; s=arc-20260327; b=dXEXXCSI65zZbHCT5c20vQ9MK+67JcG/ODpMxoMee0jC3lpMZ3zCcxPkQj+5YHni/A GXgcyN0vULCkgYiUzNH72YiYQ26REHpQLmfi7ku8Vo418YcO1yFJUtqjv7fn5tBEe1RG TFFhQoCeHyUNWmW4UUVYYx/EFxB6ahW/Sw3DftSYOpa0GQBjmu4sMQ3BoosuacxmYof2 +oU3/iwzLYx7J0ZF4GIRmmDGq8wKhyfo76t4SBUI1Uvjh/eO8IDZq3ZAn0c+n8TRuA93 vnroRTU2F/0r5LwVdRhIn9JdcHVH+BNbCBzfTTMShd9vkHkit+/Sm1wNxjYZ5E7S8+OA 4VfQ== 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=FJNmQg65EL7s7OyNY6H0dUpsRkuSOaX4owUg57y7TK8=; fh=QBnQ43fOX7gX7to+3sXCJcXhqNugz3SU7PVDJOm0b4w=; b=G6kD6b7N6CSJkVkfGhMlfJp8Llxo/gemRMXxmzz4Y04no35/XnDfcQc7pWrzMEgUxw XQtfCH+qRR+dYLSRu1q5ukSeRyobWkr+Hrn1CkGy0+lFmjK9QTAaA0LN9kQwvcJD+cNF ZPNrrD0RVwu6CC0IQXLG9vQd9hATOGMAaaOW/CxMrchPxeT95SCbjdBruWIAClcA9LiI jGpL7GvlLKostqYRNYiDRN5NR1uNibnV0jQkWllKIipXyWw+o8tpGHhjpyyWZu8VP8N9 BNjvCklzem9KAC6MI8I5gIvdLupWBpXHS7+poFZlb4SToiUGeS1kYenMV0XRz/RYv8Vz ve1w==; 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=1791907149; x=1792511949; 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=FJNmQg65EL7s7OyNY6H0dUpsRkuSOaX4owUg57y7TK8=; b=N0sOYdKw084jUVmiLoqkghU3MgIKtCjB8JHqzn/DBpTYLgNTuH9XR4RCCiiwa4oCWN MdXtU5ZQG3/+6o0t4TVE5LYB3O2ZAHG+HEKJnhvPW/PbIoLPNCsbokodkivenbyBrAwh RpWyhMhEE8XBt8kCM6F3/2nF83KfHyd9//EOCswzF5VnUOsLbCrMYKDfrmKzCNT8NXRt eOA5QaHGZ47HpBSSB7D1RGnvtWOSdczFZeVGPkKUoGWoDjippuABEm/oN7iNm/9pe5l4 qVa79YnTNVKemUjCVXJvCTZ9EseqM1vb6BwigeqgYE5cNFiEMIJVjUdA9Q0X1qwQHaAM 4NKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791907149; x=1792511949; 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=FJNmQg65EL7s7OyNY6H0dUpsRkuSOaX4owUg57y7TK8=; b=fEvUMLGxT/5+6R7C4vkWTBKrdkuyR5w75ZbCbm4XDWsdWwO6yAQRPhZE8ocxWHRgtF i+zPdtm6oHXs/en8+rvqPDcHFieEezTjmudbEGnR4pLwwULa3pS7gu5JujSKvCRdGFHm uivn36vG3GfWNf3UGgYxVUe1HV64mg0ts95+DA7K8jzC8IVI4s/DDJHIgcDtSnUeBrn5 H4/F64cSizQTr9wuScvZMBUx0YvbYG3AhZbjmO9mBbZgxrRUUltzva1+fUulqxAr8I9F JcofqT6nTKXwnlnnps6jBCGtzRVKuuYPEDFUPOQ7jZifR0jKmhnQYD+x05zKTRwQjmiU dE9A== X-Forwarded-Encrypted: i=1; AKwUvBw/ps01XCuEZeQbvNc15f9o7D0rgL+IWc9rBsQQi3f+uQe/bb6O9MzGv6sNHaNpazVgV76Kqtwnv/g=@lists.xenproject.org X-Gm-Message-State: AFq9FYI8UwyJ3BJCwwNfqtYoWO/kImXHh24S4VNC0QCuyMtES8aBWw2S 7Fs/5pFbN939Rx35woLsxtsSWE23C+7QAz10Ng2zkLr771pNOEQJjhd3cqIUMwFFq8ZT28S/7FK WQwwbiMSpZcdGzT6alfuDlU61EKFtUzl8x++X5+h7+w== X-Gm-Gg: AYBFou1F2DwaKvwlhRVpUDceYztoxLKyjsFQvx1399RHv9i0O6hVwGLPew8hXoFchfv tl9f0sLl1VsXtWb5/lpglvoVGmZAMh5ohEHYWQ27xMZ/TMgwja7yxzmAATF9I7sCecZJjOLCdDa d94cgO4gDOb+iiU1V2gsdoTqasoSXfaI+2JV2YY6z2RESLZ92VL49CJ3lC1jFZQjl7NMoe62pV9 v65pR6fuo9cOqxQnPEiN6Nq2QLq6ZWYUnRr/JPOzTUy+or+sYX1ph/L/o4YH9YTdDilW8Nlbh7c Y+O/nTsxwbYMSlPcDvn4rd1OK/LkGhvuhBjg9UMoQzaHTQFTJUr61rYUOS0TRX5aGNV5Qv7DNdU uO0vMIhh+WxFH1blNEc9OiufcZ585MzIjTwQj+3E= X-Received: by 2002:a05:690c:a78a:b0:87e:2404:45fc with SMTP id 00721157ae682-8b07ee0119bmr25300217b3.53.1791907148775; Tue, 13 Oct 2026 08:59:08 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-10-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-10-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:58:56 +0100 X-Gm-Features: AclHuK9l7BoKCi9zhsOGKWUFSW56RXKgiiWtviGpuEUGHICMhXY_rAt3MbM6dI4 Message-ID: Subject: Re: [PATCH 09/22] kvm/i8259.c: use kvm_i8259 prefix for functions To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1791907150-00ACCA5B-151AF0AA/0/0 X-purgate-type: clean X-purgate-size: 419 On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland wrote: > > 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(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:00:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:00:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448116.1664166 (Exim 4.92) (envelope-from ) id 1xGev2-0002tc-QH; Tue, 13 Oct 2026 16:00:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448116.1664166; Tue, 13 Oct 2026 16:00: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 1xGev2-0002tV-L7; Tue, 13 Oct 2026 16:00:00 +0000 Received: by outflank-mailman (input) for mailman id 1448116; Tue, 13 Oct 2026 15:59:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGev1-0002tH-6J for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 15:59:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGev0-00AIb8-JL for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:59:58 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5556-8faa-0a2a0a5109dd-0a2a450ad9aa-18 for ; Tue, 13 Oct 2026 17:59:58 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace557d-f2d2-0a2a450a0019-d15580aca418-3 for ; Tue, 13 Oct 2026 17:59:58 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8ac8a2ac52bso31826237b3.0 for ; Tue, 13 Oct 2026 08:59: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=linaro.org header.i="@linaro.org" 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=1791907197; cv=none; d=google.com; s=arc-20260327; b=jm/3FKAaE73Tx3V8Yi7gqDpBT3Y46x3dPKAjBejyf29th2G3KzQzg9w32UNFrx1LiB 5RV83kA7ZmEP3pJwglzZeWcQIerdc2jHPOPxk/TBs/aH7/seBe84ElF2s5FZ12MO9haf lwT0Tf0QI03vDM/54Uz+HC+vSb3DIc9sau+8aw1AhzzY2l1ikcG2CKcC9G8jPlSt4KCv tY1Tmo1PgQ3JUoccdDJgr2GUybPUUYuJPWu42L/J/FNUEIupqyy4/eQlUcHBxCHGO/hw ie92tS6i/Qf/MViBC1XGTEclJ0oG2eIp3UKcWN3dcnlGTwXOGqafDB5tMi/ELGNQWscD 4Tkg== 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=zdyX4MUR5OiHaBAfMH/AdP6QjGz5HJgdPnXErxafrT4=; fh=EceZd/VnO6gjtEVcql+ldXI3bOs/YoD+sPeIV2aI29Y=; b=QX4IWduaY55wKJcEBmrdTdsUf3tZ/Fm5zq26QTq/xsBqI5vRKx3FhdE8tcZHZ0WpEe 8T+35yfROCJmm2SWYb4BAwILFgJUjL7xeFrLNHfHhW+PSztMQkTdem3uOBwuf4Neq4QE gV1n7SJtBO9wc3nF/kfXavDhIPFIqV40TAw2Wh1CZBYPAt5b9iuJ4dU7z2cVR1cGz26Y EvMYUIHPGRNQNGgft3CkGXUG1iJutajTsxJ5Wf5cS645+JHJb/BB5fNuO2bWW1j0fSn5 6ZAT0fAR9IYxVQATsRdWzGR1joaiWGlJF/TOMUr+SrfypEe3Wm6RhOqwkwaTmvnsuveC 8Y3g==; 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=1791907197; x=1792511997; 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=zdyX4MUR5OiHaBAfMH/AdP6QjGz5HJgdPnXErxafrT4=; b=xeqzkb9QhzoNNJiWMJY+qIZKXj1XOxaEgBY7FO2wbCKKTApYQKhAPhNuT3btvUNVpm BIsXlD9/0GBljSaiRj/3AUMeQ1zQue+cyGiRQdmFSjXFp+GUy4s6U0wMU8CrgI7PHzQt 11RlpyXIXXbwyAG7muB6FUWbZeIjaIxjij0+RNf2A6WFDNVnXFQAgntEbvQk513FeDsB xMd1TD50rMi4tHRZ898m8C30FSNeLAcBenwfiM0RXmJaO3oja91IWXwKcP2gcxvSROIN Qf1NhknNHsba/0ke5t1KtseeIqtaR2Xbx8MCwWDpLUCcgqflMVMg5OE90GEPYEXXANDj 3Y4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791907197; x=1792511997; 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=zdyX4MUR5OiHaBAfMH/AdP6QjGz5HJgdPnXErxafrT4=; b=K/FZixi5zrIPpEHlt3yxrs0lFEzA66l6YNh39j7bFhR5vXLqGF0RxD+jK4pv6mpOow NPiiod7XjKSU3CbCHWB60FEmI0S23pKjr7ueFjmiF0UPYqnBcaLcyBdtkbzT46B7Nk/B Bl9tIPk6Hx+eIqdUROrjNo6hRFz56Sqh0j46KmlX2YKbOL2HgZe1oSOzsrD2DOeEQo04 nxda+3OYcQ/rbIIF+DskrNMEi+5KI9bmY+1KYGnAEjR3Uo9BvdeqbG4w/euF0leMCkQ5 87B4dOf6vsgSiKjHotQOeaFCrnLZRRTisXJMpQZfuJdpeSg0hh5m3ABtF++o6pJ3/zkj xuRQ== X-Forwarded-Encrypted: i=1; AKwUvBywTvh9TzHyE8+6OszVlE74s9HQSqa56n0p8WsKpMFJg1I3Lw2fx6xcpEoYlykoHYFQSnrI+Ca0K5o=@lists.xenproject.org X-Gm-Message-State: AFq9FYLNV7QmGchrVVLHTLMZdCBfkasSOBA5T7zQ6rrSF5qooyUYKG0R 8ZW0a+ukQanfZe/I5Gc0kQ/2ADKe7R1rG0YDYsqOSQU1RENwpKClB3IY4fSstOhAj7dqgodRMPG wjCqrqTG2f4I1yZbqRVBXd2teeKLCQX27bB/lQ3zTcA== X-Gm-Gg: AYBFou0NRQpUr9KafISNa2IpHwNPLZ4OdWyQ+MHvqWKyfI4HXwWLHBQ1dsWOJJul64Y Ddb2cYi/yMdQvhEY9w99Z84uKDt8ehY/sXZQDi4EcSAWMB/bEj4xY+IBTSAS/0m5lrWv3iJ112k Rr2xyWkEJD+YUCGSf5GGuBDvNvDStBIU8omy3cN4ePYpGuUX+4DjElxkkJPwklx26q7jWrhLihr NGSuS4JdymKSkzZYZQH0GyzAHubTP0pk6tQ576K4BYq8Rv7S38sCIgTRh6ulzAkrIDPoEGfBriA f6i1H2yvzd2tNWbb0RS0RpWgKecikGcTqN0BsDhQdzAeOsc0ZmWj2d09XmI5seGXFizPQa9I3zh bZeUhsVde+Er90xDVNA/4buUxiLl/hn9lzikKWuM= X-Received: by 2002:a05:690c:9e:b0:8a9:a1e9:2665 with SMTP id 00721157ae682-8b07d3c4195mr46197787b3.6.1791907194410; Tue, 13 Oct 2026 08:59:54 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-11-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-11-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 16:59:42 +0100 X-Gm-Features: AclHuK9me7UkpYql-63m348NYt-T3nReypZ14DzPdifhqRdkrWKep_ta3klwqT8 Message-ID: Subject: Re: [PATCH 10/22] i8259_common.c: convert to use DEFINE_TYPES() macro To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-4011c0/1791907198-593C4CFC-F50D824E/0/0 X-purgate-type: clean X-purgate-size: 353 On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland wrote: > > Signed-off-by: Mark Cave-Ayland > --- > hw/intc/i8259_common.c | 29 +++++++++++++---------------- > 1 file changed, 13 insertions(+), 16 deletions(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:00:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:00:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448120.1664174 (Exim 4.92) (envelope-from ) id 1xGevR-0004iq-2z; Tue, 13 Oct 2026 16:00:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448120.1664174; Tue, 13 Oct 2026 16: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 1xGevQ-0004ij-W8; Tue, 13 Oct 2026 16:00:24 +0000 Received: by outflank-mailman (input) for mailman id 1448120; Tue, 13 Oct 2026 16:00:24 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGevQ-0004iZ-JY for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:00:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGevP-000yhe-WB for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:00:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5591-2eae-0a2a0a5409dd-0a2a4508d520-30 for ; Tue, 13 Oct 2026 18:00:23 +0200 Received: from [209.85.128.169] (helo=mail-yw1-f169.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5596-f659-0a2a45080019-d15580a9ec40-3 for ; Tue, 13 Oct 2026 18:00:23 +0200 Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-8a83d2706fdso947947b3.0 for ; Tue, 13 Oct 2026 09:00: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=linaro.org header.i="@linaro.org" 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=1791907222; cv=none; d=google.com; s=arc-20260327; b=I3H1Wor1ScfVnfbtbPTFbqNxq+ao8dKTHEMW2AhIm29E7qVQl1sSbrjpFPKi31j41n vfT0fJDOPRrItVXwL/7yDGLWTI0Yf6h1E8tOz/t6pT7YYDecEtAuVMnkQa29meZh262f DVvQSh1cDiXKkwl3DADsrcKcpFeBAuSzwU/uht8Xb3bM1m8/drq3utzKNknNOoYxkbUw N8fWgT9S7tfP6/m3gta1N7KIwriTPGu12umTOTCJwjqmMlWITWtsDCGNLlXbajA5n7L2 OXRgk5V8XapjAY3HD43w05NmI2NAfbgQE0epWwLuECXmm8pRIIdeqizUxWkZu/52YXVc +pjA== 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=xMzfDdWo0ZbobwvhYL+QfEr7jkf7L5HHwABc9Q/vj60=; fh=UfaV0313vnAlL0q1w8uoJRrumOziW5kRMpDHlk9MDXs=; b=kW+vFkPg6S3rSmuZq850TiX045uP6kDr2fKZ8xFSswwZwieOk7H8qyQ5tEEdUuPrEF Nf83K9owBBCWoejWz5dSZYr6UzMEz1wvhxo9HjsviKoeFQtXtH/8TuGC0FYoc68WtazF tAvAx5GEJgH2PiUxUzH/CcOfNpRrvTpenb3f+vWsJ0WArTx36G7iqpn+e0FG0TpxcWjI tUbqnbfJJO402RU5V09Am96Nb4CDdT87Kb1FPGDf9PxBx4INf3KPZiWL+wRbyF2NDg7r pr7NEFIZB/FVi8tkrIHL95zJzlEsTuB0pcH0h7R1y87xw3p6DVd0B2PlDjuwjLRIFsAG YlLg==; 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=1791907222; x=1792512022; 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=xMzfDdWo0ZbobwvhYL+QfEr7jkf7L5HHwABc9Q/vj60=; b=oYOb1l+BeCmkM7eq0f8ES/yYBdMh00JEl3Ut9+BhX6+V0lSFStcGM09QIYjVTXh7Ag dxC2/ib4RYGevcUUJko/Wx1Rj33mv9CeixZHtrM8J3Joob+7jitCrv6X5um3H5xp9Ekh m4LpmkkXhHyDXYtl7WAFY5U+2LYnOdNjJGJnM1d1SQhul10IxL7pvVTinUM3Cv8byW6W 3EBj78GNF7dtnAZ75iY2N/wNX9EDg8EHt1pejUzGNANJtt+U4pR4Mom/VDRAMAAGdlGc FWpWYWlNmjuCAfugCptCtZprtF4bZEIbZAtvDj6oc4Knp/6hWrCc7DxFni7SbcUyQuMK sXfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791907222; x=1792512022; 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=xMzfDdWo0ZbobwvhYL+QfEr7jkf7L5HHwABc9Q/vj60=; b=mexvlotHfPPsUu36ybJT+KqpWexk4KlL9s/xVNuQTlPkzmh6Qq1DKV95TKOuRsXpFr m3drYXwsnM8xr79Oc4gugn12wiU6kmGx0zt2AXP7fSZGT+bp8ueaX4K3t1gQ1BW7lOMj SAdjbAt73wA3/9F3/ORnKF/9GdAx+U1q6TTJ6EF07apTJpATKZPzu3ZJVhNkiSDCn9BH ZSJ8bIgxLuKIiDPIr9YzUguHEV6MO0hWD+PqsE+TSTZf5+G+ctDjMj/ToE9Wqt4Soc0L 86pmSPAx79TS22uS29YrDK+oWnGmYktx9x1nKnOUToj3LcvNuSizK/Xuw64x9qCrCpOf +MLQ== X-Forwarded-Encrypted: i=1; AKwUvBxbQr3lyPXLZwZr/OE20FGwVdt2ZwDhVxGdWyBuzEUbB7kFj3i46ynbUZfwq64K6CpkHXOCO9xPJlg=@lists.xenproject.org X-Gm-Message-State: AFq9FYI/lRzi7CWSpc3reaPPsAFRXfOJNieafSZSHNy3t+zqrpNc0ffp wlP/yQLH1Jzv3vhkWVNReG2oX6A07gjpk6iN2Pdv6WAn9vjNpFAW5RfRj5GRTW0wMxWouRPFdsN Ir4bRz2W/TSFHj5ADpyC5KR0oU4j/2tAblIrNX7JoPw== X-Gm-Gg: AYBFou3MPsLkZJCcUALiS9viddY+zc5op8Dg2tNCUOLLAp9l1ieRHfo1K1KIuXIkpH3 KgS4lU6CMKsTQol5cDOIjDM6lkaytO1iDmFDtlxAOsHcuoQE2dzaCSDhwgYG/WvfAJBwBrZ+ODg v9cVRGGWY6Ow7Z8o5zc9UTutTmwoAefE7AusxMDx9UNqRMYyi7skWQni1QPBaoq1M10BQ23Cp4M vrRS59aeqthEQr5SwpzrhqTypC57wRI8npQh9lUig57S8ArS1g+FlclzJiBSlq7Cq82np0ciTie 1Xv+ldD2JEUQJRMyPa/U+8ilgUJE8SupU2V06wgxgvElglL5r5Tjja/yw1ULwKH3zkl0WrMVARc lMezP0+ubpncaLNu5mnZ7PZKcWOTTDyrg+oTw+l8= X-Received: by 2002:a05:690c:288:b0:8b0:9e24:4005 with SMTP id 00721157ae682-8b09e245129mr22462247b3.48.1791907221988; Tue, 13 Oct 2026 09:00:21 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-12-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-12-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 17:00:07 +0100 X-Gm-Features: AclHuK_b1CfMObf1rI66LJo21oLhOivp2sgnhibZnkzpTZtnhEkqg-xP9NavG9E Message-ID: Subject: Re: [PATCH 11/22] i8259.c: convert to use DEFINE_TYPES() macro To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c1860d/1791907223-CDD4887B-BC3244B3/0/0 X-purgate-type: clean X-purgate-size: 333 On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland wrote: > > Signed-off-by: Mark Cave-Ayland > --- > hw/intc/i8259.c | 17 +++++++---------- > 1 file changed, 7 insertions(+), 10 deletions(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:00:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:00:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448123.1664182 (Exim 4.92) (envelope-from ) id 1xGevg-0005ET-97; Tue, 13 Oct 2026 16:00:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448123.1664182; Tue, 13 Oct 2026 16:00: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 1xGevg-0005EK-67; Tue, 13 Oct 2026 16:00:40 +0000 Received: by outflank-mailman (input) for mailman id 1448123; Tue, 13 Oct 2026 16:00:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGeve-0005Dl-Pc for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:00:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGeve-008WkP-6J for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:00:38 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace559d-e002-0a2a0a5209dd-0a2a450cd706-22 for ; Tue, 13 Oct 2026 18:00:38 +0200 Received: from [74.125.224.47] (helo=mail-yx1-f47.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace55a5-f479-0a2a450c0019-4a7de02fd023-3 for ; Tue, 13 Oct 2026 18:00:37 +0200 Received: by mail-yx1-f47.google.com with SMTP id 956f58d0204a3-67921b515a7so2678896d50.2 for ; Tue, 13 Oct 2026 09:00: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=linaro.org header.i="@linaro.org" 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=1791907236; cv=none; d=google.com; s=arc-20260327; b=koivntNkOowzuv544DAAEpb3XgyVi1l0po8hTVD+G1SY+q/RVBhp2SayxDLlCmeAUd 2BjynnST7m2HunF7GQjFlJ5j4SXXgsu58Iad6818hdRVm693v+5XVb4JgxO50+XrtvaZ aclNdMBfUiAWjk3Ymbwun+iBuAqgwmj6BmSZzBQbELVRtr25ZIcR+aY3nhAzW6P2chJH mE3TuTho39xVPDUAwnm0ezuZbtzHqmwemdyY7wI/Cvjz512LYtcvjfGSC+As28S7YUxq dfu23y3UATXebj9lJwDY2Kaa75K7AkT45mkjyV7b1U57WH4OytY7+tCq9iS8a3z9VpB+ wvIw== 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=D/uivC4tktPPj9uqDCsidcrW7/PSmgccuKFkXyRWMQc=; fh=x6rj9lFMFJuq5x1BqHla6RtYZiIhpudS9nqr8q6YR+Y=; b=e7dhzz0dbJcrno5Il2D3AFN5aLyRjm6+WdiNugjFxcGG5YOvUUHLhEbbEpFovP/kqT siIYTA9ueUoIovgeUFGl97lAzCpbXXN7HDkpx1YcaLlsd5Rx/xVjj2JxWSxJZVW8m+jQ Vo1rbeuwbroJ1JZ+K3taYHifYkfAX2vSJBLbMJEkjKVQO1qtJTE6f2H5J0CSsSpcC6fp Kk/ardkiBbz29lB1iZV87tsvz8YIlK+ZLS9kGlpZHG/tOTnjP7ZaT70PAfFtk/mX96VH UteX5nOuBN91RaX3UEDYItQ9UIqep1KgcTCmsotbEEtg0Yrk/g1mjjuD0gPeP4Qd5wpq mc1Q==; 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=1791907236; x=1792512036; 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=D/uivC4tktPPj9uqDCsidcrW7/PSmgccuKFkXyRWMQc=; b=gpgabEIPWaKQ4N5H38jbVGD+FE5pjWwKeFw4q6YXXybYsSApei0pOfrEn3ThLZRFL3 +G7pqPiO7lA6QgcWzm2nqIWpEaLU9+s9By3IfYDJ6XO2o6lSAjy0HmAUf0jXxmMolrKJ is+nQe4Gs7ZUx9764nj2PLWvG1WaKg/bqNq/ezMM4ZHN+Zyw1i8P567xsVPrbN8GzIlP nmZndOr33liyQ45fE5pUEHf+UpsofkmpHPY1KC9Wosybe3PZdTFVWG/zn8lI8uNCQfSF P4YzDF7enP9xRb3FVy+XPg2e3QCiIXQiskNU8En4yexVUO0sSXAXNy0yqc9RgMCogo6B 1xmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791907236; x=1792512036; 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=D/uivC4tktPPj9uqDCsidcrW7/PSmgccuKFkXyRWMQc=; b=GAw4zAwjpfa4C9GIBht5UULz9t+Lk1VKlt4fG9+mjiZ1j+NdUdbWF571YftKczGZ0I dN4mHfm5iXUMs9JgLdOYoWS06WsMQZY9AMakKO7b9RBa/mujGZoVsFstuMDE/8EORfZK uZJHex1r6MY7SD/Dl6XripKlLxWyKlQQJWzYEju/dDs1yj227rFidhUuEx7IrAwNV4QP /O03zhZgkwxV9zYllTtwK6HtkTDpDUZ6pUZx6xNDr9ORNYW81Re2eK+GuI0fseCUqSRe VXGeGK5fCkpfn+msKAzrXs/DxKdDjfG23O5ha8bY1bFzKk8Kje70iLzZQpxba5vtMJFu MMEg== X-Forwarded-Encrypted: i=1; AKwUvBx7mscdulRWbMuE24+dhPoMD1Hf9qrLVLt7tGZ0ZZcewDUukEgFEJtxyRVQA+4ElTXCeg1vqxNBOV4=@lists.xenproject.org X-Gm-Message-State: AFq9FYK5UkwXNb/JDywhfN+7UXjABRCprq9+ZDI1UkSNXTWfkkqipb/z ALVdWf5iNoHsy3mqP5HBkzDVfVF+yaWS+QJzI72Gge6Id2/7CRaw2NFT38+yibbepLOkatJzvBJ KikmoiiJHRkypRuJD9+H0ne2tKSv8wjNVY/F446OeXw== X-Gm-Gg: AYBFou0P0j3Tno2G6C3MeImrq1ANLTDdk9v4g1rXHMmAUF7vvokVL6oOaOPolvUpGY1 Ar5Aleez5u6KX5zBX/jOKaCn8qFdUgxUlYAJRRTErxj6lRPTQ+XKVarTeOswxLFIDmbX5RQ29p1 M09HYCIPzJPr6FCvumZKa6A7Ph6NTfSgo8YBEfSUVEj0E4H+5UsyMO4dSZxLMksWtOvtEhVrQIo CL2pMEvoucKlpHe/EBMJGEaMpJyNdUIdiahnEOrM8IQHKkY3yLxCLbZTa3du9bSFWdI80rXSF+F rTAQARIkpg9+VbK0pEkqQIS6H3yljc6WEh7yO+F+3t0dvJGHwvJlBylGjG/CBnwGXjM3vybV/qD Wj2Ien+sUU35FARegISIwy9PR/bhTm78GlG1WQ9E= X-Received: by 2002:a05:690e:4893:20b0:677:d251:ccd9 with SMTP id 956f58d0204a3-679362827bemr3036296d50.48.1791907236209; Tue, 13 Oct 2026 09:00:36 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-13-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-13-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 17:00:24 +0100 X-Gm-Features: AclHuK9oncqSnpk2WtX0BIztDFi6jgbDUd4jevuwU9CNMC7v0XFSzmKBIWC2eE8 Message-ID: Subject: Re: [PATCH 12/22] kvm/i8259.c: convert to use DEFINE_TYPES() macro To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1791907238-022C0A5B-80BF1D6A/0/0 X-purgate-type: clean X-purgate-size: 340 On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland wrote: > > Signed-off-by: Mark Cave-Ayland > --- > hw/i386/kvm/i8259.c | 17 +++++++---------- > 1 file changed, 7 insertions(+), 10 deletions(-) > Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:04:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:04:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448137.1664192 (Exim 4.92) (envelope-from ) id 1xGeza-0006AP-Q4; Tue, 13 Oct 2026 16:04:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448137.1664192; Tue, 13 Oct 2026 16:04: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 1xGeza-0006AI-MO; Tue, 13 Oct 2026 16:04:42 +0000 Received: by outflank-mailman (input) for mailman id 1448137; Tue, 13 Oct 2026 16:04:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGezZ-0006AC-Ic for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:04:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGezY-00G0rQ-Qn for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:04:40 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5694-8faa-0a2a0a5109dd-0a2a45039e26-12 for ; Tue, 13 Oct 2026 18:04:40 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5698-fae8-0a2a45030019-d155802eb1a5-3 for ; Tue, 13 Oct 2026 18:04:40 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a061a13884so27627605e9.3 for ; Tue, 13 Oct 2026 09:04: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-4a18bbbdd75sm288269005e9.1.2026.10.13.09.04.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 09:04: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=1791907480; x=1792512280; 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=BunnkNB1gTMoRua6fKKaK15LnDOzwmyq7eAoBBwjfg4=; b=CzDatNtCVUlqpn/txqCSX1moRrvzDddijIQNcys9LybzJ28sCtBrTndWlOb4YNbCro faMUKyxxd8Os6zJrr2Scanjyel1UnV8xDRIFGqf/b6jnLjdhasjnPd6aZI1iixfsTHXC +r/QmctrLRiMQGVP2vzTYN9uUqHxg6UPpneq3Vpp3DfeZCtyvpqE9ve+BjNd/pNanQQ5 3QrZ/saorhvwfj+tqI1iH0KTbcEAxr6k2JB/w6xtWmssvUs74NH/qMD2h63dxYaeMs11 w0XsoK0md/Eyjuo0wSFh1+BCpAEPqzGBY5JIdJTnrKi1rEljJ3G1UEuPw3KjEibtU/uI c3tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791907480; x=1792512280; 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=BunnkNB1gTMoRua6fKKaK15LnDOzwmyq7eAoBBwjfg4=; b=2ci8liEjTz8mR2cZMMr0GG15056Si1rEmD0lgAOizrmsqap8gwze3jbhOkjC8+b+jc 8IZzVigKcqOwsS+jOJncXq1r039rWaFYXtyZBcNXNvMiQxwXgFfoCUHfdi5RFYoQ1tPJ LnZm2Y5S1fsdmJOZV6n6FMH6O3y/jSfnm0IgeuvZOge4X7CfwawlCTSnBrWEIQ3gsJmD MUDZvA+RwsD8/iBnX7tBmXQsaNUSmPFAWQCzljArIy0Qma39vUIByoPAqHk1+c+2uoZB 1+gReH+jPe1R5O7yqNmg2Fed7Lg4zafHD3ViogxdgQDg2tsYW2ZjLNNpTq6/cJx1beBL JCzg== X-Gm-Message-State: AFq9FYIcvPo3ksCk5iVCifBYjhzuICaEjBpM5EX1nM53k/61VNwCYyYk gKiKqxFV8G8/cz/FIXi91XtKS0rXYxaNOD/s0gqa2LqMBn5+E6wfPRr5n2HffeB5BQ== X-Gm-Gg: AYBFou2f9wSBPCy9WFqTADptqbKoPwXcc2KK+CudXLI0wGUpJT/wz+kwsKxqUyARO4Y jWc9cXvPvVx/aZgz8hw409DzcNAljh0dbIF1yFqnz874B+S1L7/cLUDG+UuneLtSQZMrfe5+QPT mqPK/oGcoyv9RwwWx4eFGWFbEB4MjEVBTYXG4jpiGYsibeD3qM8xoe2tR6tPtiavfdXCWgt6a/t QU1LoGg+1puizAtazECQds8BkWCktY+d8HVpd+VVwHi8xbO4lqOLS4+J+6BuxtvL6VQrjKQ+WqZ upC8Rl5Y8E5S2RkCHtG1NW0SFQMWhMv7spcCNvYbuGRrHr2Okh3MnkPYNdY7RsvgGId+Utu6nsl hJGkD5JEzVi/z0Il8KZrexB5uWerAptxSu4OqgTqaTC7Mw8tSHP45KBf91kaJt0pULlhTh9FM+M z6qFLBEQP1Y7flt8OHKtqpTSI+090lEEJKdxp21SMgU26Y+kGykWOVf3g0AoYORYW916iwdhabT CeuFqaJuvLSdETHlYB8O1dckOaIQcbO6k8RK9hzhPSrdRKG9KNgSdmUdpti2cs= X-Received: by 2002:a05:600c:630f:b0:4a1:9f59:ee7 with SMTP id 5b1f17b1804b1-4a19f5911f4mr128827115e9.0.1791907479983; Tue, 13 Oct 2026 09:04:39 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 18:04:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/15] x86/PVH: split pvh_setup_acpi() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1791907480-6D8D54E9-70BDA573/10/78276251493 X-purgate-type: spam X-purgate-size: 1650 On 13.10.2026 17:52, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:23:16AM +0200, Jan Beulich wrote: >> All E820 manipulations want to happen before the initrd is placed, or else >> pvh_steal_ram() may steal from the tail part of it. As a second step, >> split placing ACPI data from actually populating it. > > Would it be less intrusive to duplicate the memory map (like it's done > in a change ahead of this one), and subtract the kernel and initrd > region from that memory map, then use it as the basis for > pvh_steal_ram()? > > We could adjust/replace pvh_add_mem_range() so it allows changing > regions from RAM to other types. That would seem to be less churn > overall. Maybe you did already consider this and found further > problem with this approach that I'm failing to see? No, I didn't try that route. In fact despite the order now this patch (and maybe also the VMX one) pre-dates the E820-copying one. The one aspect I consider problematic with the suggested alternative is that then two E820 maps need updating: The one with kernel (not sure about initrd; see below) subtracted out, and the one we actually mean to hand to Dom0. As to overall churn: I'm not sure which one would cause less. Certainly the patch here would remain largely unaltered, as the splitting is going to be necessary no matter what. As to initrd: That one wants to go last, as it has no constraints on placement. If there's not enough space below 4G, we just put it above. The same isn't true for ACPI or VMX data (albeit for the latter I haven't checked in how far placing below 4G is strictly necessary). Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:07:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:07:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448143.1664200 (Exim 4.92) (envelope-from ) id 1xGf1q-0006fg-4O; Tue, 13 Oct 2026 16:07:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448143.1664200; Tue, 13 Oct 2026 16:07: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 1xGf1q-0006fZ-1M; Tue, 13 Oct 2026 16:07:02 +0000 Received: by outflank-mailman (input) for mailman id 1448143; Tue, 13 Oct 2026 16:07:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGf1n-0006fT-Sx for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:07:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGf1n-001lgY-2O for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:06:59 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace571f-2eae-0a2a0a5409dd-0a2a4506c378-12 for ; Tue, 13 Oct 2026 18:06:59 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5721-195a-0a2a45060019-d1558030a99d-3 for ; Tue, 13 Oct 2026 18:06:57 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49e73611928so32791145e9.1 for ; Tue, 13 Oct 2026 09:06:57 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376946.centertel.pl. [37.47.103.179]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18bf3e044sm360372855e9.14.2026.10.13.09.06.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 09:06: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: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=1791907617; x=1792512417; 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=X8Bt47MDCPiiwpSOAjVfijshONvTSqNNKyc8YgzblPo=; b=hSmJcqw/lzj6hYlQLtQ3h4JKaOHBirwXb7zdYoirWMt0spqk6Hp6fYOGtDlL7qb6gm zB/ns33b51Cxwpml1iWt8AkIL4Wj5YlxVTTKDOTezTSoKtVKoYUaPR6j5CjkGu3BuH86 dTGt4yWMKEFCKi+GBcnF2Cl2OTHFMFMXudvVSM6/arBLqJGAHGStDrkOKHEUZV2smVgI s1V6LE8D1y+XpJETyjA3xgVeFsGtPolDLrlSCx2RvXt+BcNrf0x0PdV25u4XCRfbHlZU 5jh0W9DkWlF+VFHY1/K/sA1ViMOWYG+fsBwhEweQUej9SJDR0xjxGeDeOr/Knjo7F2rK liMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791907617; x=1792512417; 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=X8Bt47MDCPiiwpSOAjVfijshONvTSqNNKyc8YgzblPo=; b=aYTipIwClp8KTcgm5micWFCZqBLjnqn5OIe3CVRkofuid/j+2wgsURNd0sA/3TcVEf qu9sveoJ7F9XkPubHJBzFa+R3xfVRGFmnghrt2TIIlVoGHwytOz9zYYwSninmprcAGZy 40VuioARSeBmM5uCSvxPMpbbvkU0iH/SLsPBuj7USPN1p9ZG37OJGuEfXY7KS8k0DnyU xdxftgRm3OSJURkhqsdKBPLYUm9XeJc86U/gkA0Y2XfiY1z65sZP6rHYriqGlqvhh/7f bxQ9Xo1i6SYx62JQJvKNpuYv+lU+qXJnkKEjQOL5a6335RVLlEOCtj4m4htHjsP/Tuz+ am1Q== X-Gm-Message-State: AFq9FYKhdec+1eOKMsy0aCpOIJ5wCdm+2ojjWW9/JFgyjfmGcHHKWods 1cGuzrmJLCUr7pdyxSPQVwZLfnB41nli9nYwK7hs7O6TfcpA6LG93VcR X-Gm-Gg: AYBFou39+fIyPLod2n2m2BslogakEbCEsKpGXCF5BSx5BqJP9y5a52zWy7An7M49gaR V4Qc5WxaHD7tvryV4meiO5cPd/RLgCq5/HDcwFcSJmn1q26llIcBstvoy1jQW+Tm8sIxVEPwS0o l/+gj4cEaipfIYTx/YQixxDdkSyh2mN/9OFW2dZtl1uCC5AP6B/vCAen0+yV8w0muN9+ITpHvGm SzbIIG1wmkRpVo2KysQzqrwnEnR0q10twhccUz3JBYiKIbfHHepBGr+3vopqTz78NAneyzJZIG4 xGIVPcmaRTbE2sCsQx5rGBLfXHYUuDPVXKpkgKInacChLejeLCehGy6sEuTxlKQGZZpgwabouB2 08wiZm0u4JY6cA65rXOHrjj1t+V5Gp/SElg3/CnoWUnve3dCC6NqACIFAQ+WmJyBf8qyY51uDuW h0oNlu4nZsc1SizWXPxpScE6uDyGL+T8OhNlr/NFvwjHCaTzps0C1zNw2r9+kN9fJpRMeb3/ETL Z1OIFL9091BbzBKkJ3g3NZFUUXsrrULxdvD2ULz X-Received: by 2002:a05:600c:3e0b:b0:49f:fbad:29ae with SMTP id 5b1f17b1804b1-4a18e4b1311mr245828605e9.17.1791907616965; Tue, 13 Oct 2026 09:06:56 -0700 (PDT) Message-ID: Date: Tue, 13 Oct 2026 18:06:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v3 08/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: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e58370003f66@vates.tech> Content-Language: en-US In-Reply-To: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e58370003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1791907618-F4E0677B-80014A46/10/73395122804 X-purgate-type: spam X-purgate-size: 32646 On 10/5/26 4:53 PM, Baptiste Le Duc wrote: >> 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. >> >> Register the vAPLIC range with the MMIO dispatch and emulate the accesses: >> - reads and writes are masked with the domain's authorised interrupt >> bitmap, so that a guest can neither observe nor affect interrupts it >> does not own; >> - target registers are shadowed per source, so that a guest reads back >> what it wrote. The h/w register instead gets the hart index and guest >> interrupt file of the pCPU the target vCPU's interrupt file lives on, >> as the APLIC uses these fields directly to compute the MSI address. As >> long as the target vCPU has no h/w guest interrupt file, only the >> shadow copy is updated; >> - only MSI delivery mode is emulated: target writes made while the >> guest's domaincfg.DM is clear are ignored. >> >> Delegation (APLIC_SOURCECFG_D) is not yet supported. >> >> Co-developed-by: Romain Caritey >> Signed-off-by: Oleksii Kurochko > Co-developed-by: needs a matching Signed-off-by: from Romain right after > it. I will contact Romain and ask for his Signed-off-by. [...] >> --- a/xen/arch/riscv/aplic-priv.h >> +++ b/xen/arch/riscv/aplic-priv.h >> @@ -47,4 +47,6 @@ struct aplic_priv { >> */ >> extern unsigned int guest_aplic_num_sources; >> >> +uint32_t aplic_msi_target_gen(const struct vcpu *v, 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 17c96177a3..febc451760 100644 >> --- a/xen/arch/riscv/aplic.c >> +++ b/xen/arch/riscv/aplic.c >> @@ -16,6 +16,7 @@ >> #include >> #include >> #include >> +#include > Nit: sorts before . Applied. > >> #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,137 @@ 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: > Sorry but as I already mentioned before, Hart Index is equal to (g << lhxw) | h > I think it is a miss as you explained this later correctly .... > > I would propose this: > ``` > * The physical address of an outgoing MSI is calculated by bitwise ORing a > * Base Physical Page Number (Base PPN) with the group number (g), the > * hart number relative to the group (h) and, for a supervisor-level > * interrupt domain, the Guest Index: > ``` Hm, I think that probably I applied something incorrectly from your prev. suggestion. I will re-apply what you suggested here. > >> + * >> + * ( 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. > ... here >> + * - 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 >> + * 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_index(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_hw_read_reg(unsigned int offset) >> +{ >> + unsigned long flags; >> + uint32_t val; >> + >> + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); > Nit: the parentheses around offset < aplic.size aren't needed: > ASSERT(offset < aplic.size && IS_ALIGNED(offset, sizeof(uint32_t))); > >> + >> + spin_lock_irqsave(&aplic.lock, flags); >> + val = readl((const 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))); > Same here. So from correctness point of view there is no need for the parentheses around offset < aplic.size, I agree with that. Usually in other places such parentheses are presented (for stylistic). Considering your Nit just above do you want me know to remove the parentheses? If not, I am okay to keep them. [...] >> +/* >> + * 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.sources[irqn].target); >> +} >> + >> +static inline uint32_t generate_auth_mask(const struct domain *currd, > Nit: inline in a .c file isn't needed, the compiler decides anyway. Agree, I will drop it. >> + 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)\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; > > With that, every access with addr >= APLIC_CTRL_REGION_OFFSET_MASK > aliases onto the same control region: e.g. an access to > GUEST_APLIC_S_BASE + 0x4000 (idelivery of IDC 0) ends up in the > APLIC_DOMAINCFG case, and a store there rewrites domaincfg. Good point. From the guest's point of view, accesses from base + 0x4000 up to the end of the region advertised in the DT (at least base + 0x7fff) are legal. As vAPLIC supports only MSI delivery mode for now, it has no IDC structures, so generally we shouldn't report to guest that it range to guest I think or make it at least read-only zero. > > It also silently relies on GUEST_APLIC_S_BASE being 16 KiB aligned. Indeed. The spec only requires the control region to be "aligned to a 4-KiB address boundary", so e.g. a base of 0xd001000 would be valid, but with the mask an access to base + 0 would then be decoded as offset 0x1000 rather than domaincfg. > > The AIA spec ("Memory-mapped control region for an interrupt domain") > says IDC structures start at 0x4000 and are only needed for direct > delivery mode, and that all other bytes of the control region are > reserved and read-only zero, writes to them being ignored. So I'd expect > something like: > > const paddr_t offset = addr - vaplic->regs_start; Agreed, computing the offset by subtraction is better. I think offset can stay unsigned int, though, as it is always below regs_size, which is unsigned int itself. > > Then read/write out of control region would go to "default:" case. I will do read-only zeros instead of default as it is what AIA spec suggest to do in such cases. > and APLIC_CTRL_REGION_OFFSET_MASK could go away. Agreed, I'll drop it. > >> + uint32_t auth_mask; >> + unsigned int i; >> + >> + ASSERT(curr == current); >> + >> + switch ( offset ) >> + { >> + case APLIC_DOMAINCFG: >> + *out = vaplic->regs.domaincfg; >> + >> + 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_SETIPNUM: >> + case APLIC_CLRIPNUM: >> + case APLIC_SETIENUM: >> + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: >> + case APLIC_CLRIENUM: >> + case APLIC_SETIPNUM_LE: >> + /* >> + * Based on the RISC-V AIA spec a read of these registers >> + * always returns zero >> + */ >> + *out = 0; >> + >> + return true; >> + >> + 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; > genmsi (0x3000) isn't covered by any case, so an access to it ends up > in default: and faults while in MSI delivery mode it isn't read-only zero: > Hart Index and EIID behave as in a target register, and Busy is > read-only. I would suggest to add a dedicated switch case: > > ``` > case APLIC_GENMSI: > *out = vaplic_is_msi_mode(currd) ? vaplic->regs.genmsi : 0; > > return true; > ``` > With a new helper vaplic_is_msi_mode -> bool that could also be used in > write counterpart and a new genmsi field in vaplic->regs. > > If we assume the guest will never try to read genmsi then it is okay but > it might worth to at least mention it somewhere. It wasn't implemented because there is no user of it in Linux, which, I agree, isn't a good argument. Also, really injecting an MSI into the guest requires some extra functionality. I've implemented it for the s/w interrupt file support, and it could be re-used here. I am not sure it is a good idea to emulate genmsi the way you suggested for now. Take, as an example, Xen's own sync function, which uses genmsi as the AIA spec describes for synchronizing a hart with the APLIC: 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(); } If a guest did the same, aplic_genmsi_barrier() wouldn't get stuck with the emulation you suggested, as Busy would always read as zero, but the guest would then wait forever in: while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) cpu_relax(); because Xen would never inject the MSI into the guest. So I see two options: 1. Accept for now that a guest trying to use genmsi gets crashed. (current behaviour) 2. Introduce genmsi emulation now. It shouldn't be too hard, as almost all of the needed functionality already exists in the s/w interrupt file support series. Probably for now it would be fine to go with 1 + some TODO comment: + /* + * TODO: emulate genmsi. A write to it has to send an extempore MSI to + * the target vCPU, and a guest typically waits for that MSI to become + * pending in its interrupt file. Just recording the written value would + * leave such a guest waiting forever, so until genmsi is emulated, an + * access to it is treated as an unhandled one, which gets the domain + * crashed. + */ + case APLIC_GENMSI: default: But I will check how big will be diff if to introduce genmsi emulation now and if it isn't too big I wll introduce emulation now. >> + 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; > > Same aliasing issue as in vaplic_emulate_load(), here with the write > going to the aliased register. Agreed. Will fix that. > >> + >> + ASSERT(curr == current); >> + >> + switch ( offset ) >> + { >> + case APLIC_DOMAINCFG: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + >> + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | >> + (value & APLIC_DOMAINCFG_WMASK); > APLIC_DOMAINCFG_WMASK includes DM, so a guest writing DM=0 reads 0 back > and assumes direct delivery mode is in effect. However, only MSI > delivery is emulated: there are no IDC structures, and with DM=0 the > target handling below drops the write, so the guest just stops getting > interrupts. > > DM is WARL, so an MSI-only APLIC is expected to keep it at 1 whatever > is written, which is how software figures out that direct mode isn't > available. Can't we do the same here, as is already done for BE? > I.e. drop DM from APLIC_DOMAINCFG_WMASK, and OR APLIC_DOMAINCFG_DM in > here and in domain_vaplic_init(). That would also justify sizing the > region at APLIC_MIN_SIZE (see my comment on regs_size at the end). Generally, I agree with your suggestion, and this is how it was done in earlier versions. I then moved away from it, as I thought that with DM hardwired to 1 there would be an issue with the following initialization code in the Linux kernel: /* Disable all interrupts */ for (i = 0; i <= priv->nr_irqs; i += 32) writel(-1U, priv->regs + APLIC_CLRIE_BASE + (i / 32) * sizeof(u32)); /* Set interrupt type and default priority for all interrupts */ for (i = 1; i <= priv->nr_irqs; i++) { writel(0, priv->regs + APLIC_SOURCECFG_BASE + (i - 1) * sizeof(u32)); writel(APLIC_DEFAULT_PRIORITY, priv->regs + APLIC_TARGET_BASE + (i - 1) * sizeof(u32)); } /* Clear APLIC domaincfg */ writel(0, priv->regs + APLIC_DOMAINCFG); Linux doesn't check domaincfg at this point and writes APLIC_DEFAULT_PRIORITY to the target registers whatever DM is, i.e. in the direct delivery mode format, although an APLIC supporting MSI delivery mode only is legal from the spec's point of view (writing 1 to a target register in MSI delivery mode probably wouldn't hurt, though). This confused me, so for a while I allowed DM to be 0, with a warning for a target register written while DM is 0 (missing that such a write is then ignored). Looking at it again, the Linux code is fine from h/w point of view: it makes source i inactive by writing 0 to sourcecfg[i] right before writing target[i], and target[i] is read-only zero while source i is inactive, so that write is ignored whatever the delivery mode. Also, I have to admit that write to target[i] in such case doesn't make too much sense... So I'll take your suggestions and, in addition, make target[i] read-only zero while source i is inactive, as the spec requires (vAPLIC doesn't do that at the moment). That makes the code above safe with DM hardwired to 1, and is worth having anyway. >> + >> + return true; >> + } >> + >> + 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 ) >> + { >> + gdprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); >> + >> + 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 >> + * 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; >> + >> + break; >> + >> + 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_SETIPNUM: >> + case APLIC_CLRIPNUM: >> + case APLIC_SETIENUM: >> + case APLIC_CLRIENUM: >> + case APLIC_SETIPNUM_LE: >> + if ( !value || !AUTH_IRQ_BIT(currd, value) ) >> + return true; >> + >> + break; >> + >> + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + /* >> + * 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; >> + >> + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) >> + { >> + struct vaplic_source *src = &vaplic->regs.sources[srcn]; >> + struct vcpu *target_vcpu; > target_vcpu is only read, so this can be const struct vcpu *. Agree, i will do it const. > >> + unsigned int guest_hart_idx = >> + MASK_EXTR(value, APLIC_TARGET_HART_IDX); >> + unsigned long flags; >> + struct vimsic_state *vimsic_state; >> + >> + 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; >> + } >> + >> + vimsic_state = target_vcpu->arch.vimsic_state; >> + >> + /* >> + * 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. >> + */ >> + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) >> + { >> + printk_once(XENLOG_WARNING >> + "%pd: vAPLIC target guest index != 0 is unsupported\n", >> + currd); >> + >> + return true; >> + } >> + >> + /* >> + * src->lock keeps the stored copy and the h/w register updated >> + * as a pair. >> + */ >> + spin_lock_irqsave(&src->lock, flags); >> + >> + write_atomic(&src->target, value); >> + >> + /* IRQs are already off under src->lock. */ >> + read_lock(&vimsic_state->vsfile_lock); >> + >> + /* >> + * The h/w register names the hart and the guest interrupt file >> + * MSIs are sent to, and there is none of either until the target >> + * vCPU is given a h/w guest interrupt file. The stored copy >> + * reaches the h/w at that point. >> + * >> + * TODO: once s/w guest interrupt files are supported, a vCPU using >> + * one still needs its MSIs, so the h/w register will have to be >> + * written for it too, pointing at an interrupt file Xen receives >> + * them in on the vCPU's behalf. >> + */ >> + if ( vimsic_state->vsfile_cpu != CPU_NONE ) >> + aplic_hw_write_reg(offset, >> + aplic_msi_target_gen(target_vcpu, value)); > > The comment above says the stored copy reaches the h/w once the vCPU gets > a h/w guest interrupt file, but nothing in this patch does that: it only > happens with vaplic_reconfigure_target(), added by "xen/riscv: introduce > vaplic_reconfigure_target()" and called from imsic_vsfile_move() by > "xen/riscv: remap interrupts to new IMSIC VS-file". At this commit a > target written before the first attach never reaches the h/w. What about the case domain has 2 vCPU and second vCPU hasn't been brought up but a guest decided to use it as a target vCPU then domain_vcpu() will return someting not NULL and we will get here with h/w file not really attached for now. Normally it shouldn't happen but technically "bad" guest driver could try to do that. > >> + >> + read_unlock(&vimsic_state->vsfile_lock); >> + >> + spin_unlock_irqrestore(&src->lock, flags); >> + >> + return true; >> + } >> + >> + /* printk_once(), as a guest could otherwise flood the log. */ >> + printk_once(XENLOG_WARNING >> + "%pd: vAPLIC direct delivery mode isn't supported\n", >> + currd); >> + >> + return true; >> + } >> + >> + default: >> + fail: >> + gdprintk(XENLOG_WARNING, >> + "Unhandled APLIC write at offset %#x (value %#x)\n", offset, >> + value); > Nit: now that the arguments wrap, put offset on its own line as well. Will do. > >> + >> + return false; > So in this function you are assuming the guest will never try to write > genmsi. Is it expected? so a guest accessing it faults. Linux doesn't > use it today, but the spec defines it in MSI delivery mode. Could it at > least get an explicit case (reads as zero, writes ignored, with a TODO > about extempore MSI injection) rather than relying on guests never > touching it? As I mentioned above I will do or at least TODO or provide a separate patch to emulate it. > >> + } >> + >> + aplic_hw_write_reg(offset, value); >> + >> + return true; >> +} >> + >> static int __init cf_check vaplic_make_domu_dt_node(struct kernel_info *kinfo) >> { >> struct domain *d = kinfo->bd.d; >> @@ -95,6 +403,56 @@ static const struct vintc_init_ops __initconstrel init_ops = { >> .make_domu_dt_node = vaplic_make_domu_dt_node, >> }; >> >> +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, >> + mmio_info_t *info) > > Jan asked in v1 to rename the parameter to curr once ASSERT(v == > current) is added. Same for vaplic_mmio_write(). Thanks for noticing that, missed that. I will fix that. > >> +{ >> + uint32_t val; >> + >> + ASSERT(v == current); >> + >> + if ( info->len != sizeof(uint32_t) || >> + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) >> + { >> + gdprintk(XENLOG_DEBUG, >> + "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n", >> + info->gpa, info->len); >> + return IO_ABORT; > Please drop the "VAPLIC:" prefix, gdprintk() already says where the > message comes from. Also a blank line before the return, as you do > elsewhere in the file. Agree, not too much sense in the prefix here. I will drop it. > >> + } >> + >> + if ( !vaplic_emulate_load(v, info->gpa, &val) ) >> + return IO_ABORT; >> + >> + /* APLIC registers are 32-bit; zero-extend to the guest register width. */ >> + info->data = val; >> + >> + return IO_HANDLED; >> +} >> + >> +static enum io_state cf_check vaplic_mmio_write(struct vcpu *v, >> + const mmio_info_t *info) >> +{ >> + ASSERT(v == current); >> + >> + if ( info->len != sizeof(uint32_t) || >> + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) >> + { >> + gdprintk(XENLOG_DEBUG, >> + "VAPLIC: unaligned/wrong-width write gpa=%"PRIpaddr" len=%u\n", >> + info->gpa, info->len); >> + return IO_ABORT; > Same here. > >> + } >> + >> + if ( !vaplic_emulate_store(v, info->gpa, info->data) ) >> + return IO_ABORT; >> + >> + return IO_HANDLED; >> +} >> + >> +static const struct mmio_handler_ops vaplic_mmio_ops = { >> + .read = vaplic_mmio_read, >> + .write = vaplic_mmio_write, >> +}; >> + >> static const struct vintc_ops vintc_ops = { >> .vcpu_init = vcpu_imsic_init, >> .vcpu_deinit = vcpu_imsic_deinit, >> @@ -103,6 +461,8 @@ static const struct vintc_ops vintc_ops = { >> int domain_vaplic_init(struct domain *d) >> { >> struct vaplic *vaplic = xvzalloc(struct vaplic); >> + unsigned int i; >> + int rc; >> >> if ( !vaplic ) >> return -ENOMEM; >> @@ -123,7 +483,28 @@ 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.sources = xvzalloc_array(struct vaplic_source, >> + d->arch.vintc->nr_virqs); >> + if ( !vaplic->regs.sources ) >> + { >> + domain_vaplic_deinit(d); >> + >> + return -ENOMEM; >> + } >> + >> + for ( i = 0; i < d->arch.vintc->nr_virqs; i++ ) >> + spin_lock_init(&vaplic->regs.sources[i].lock); >> + >> + vaplic->regs_start = GUEST_APLIC_S_BASE; >> + vaplic->regs_size = APLIC_SIZE(d->max_vcpus); > > The vAPLIC only supports MSI delivery (msi-parent → vIMSIC, no direct > mode emulated), so no IDC structures are needed and APLIC_MIN_SIZE is > enough. To make that explicit I'll also hardwire domaincfg.DM to 1 > (WARL), so the guest can't select a mode the region doesn't back. > Agree. I think it should be here APLIC_SIZE(0) (with probable renaming an arugment of APLIC_SIZE to make things more clear) and in one more place and as I confirmed above I think it also make sense to set DM to 1 always. Thanks. ~ Oleskii From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:17:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:17:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448153.1664210 (Exim 4.92) (envelope-from ) id 1xGfBp-0000vH-4I; Tue, 13 Oct 2026 16:17:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448153.1664210; Tue, 13 Oct 2026 16:17: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 1xGfBp-0000vA-1A; Tue, 13 Oct 2026 16:17:21 +0000 Received: by outflank-mailman (input) for mailman id 1448153; Tue, 13 Oct 2026 16:17:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfBn-0000v4-6a for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:17:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGfBm-00DbSs-Cj for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:17:18 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace597f-bab6-0a2a0a5309dd-0a2a4503a6ac-44 for ; Tue, 13 Oct 2026 18:17:18 +0200 Received: from [209.85.128.169] (helo=mail-yw1-f169.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace598d-fae8-0a2a45030019-d15580a9ad6a-3 for ; Tue, 13 Oct 2026 18:17:18 +0200 Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-8b094046a7aso7213487b3.1 for ; Tue, 13 Oct 2026 09:17: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=linaro.org header.i="@linaro.org" 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=1791908237; cv=none; d=google.com; s=arc-20260327; b=jSFskG7/Eidg5xl82PQDmZ15kC/RqgtICMGkc3RkW2+uuvfhatgsU0rZzkiA59MAOf U8y/PGSb0uu6lh+fStidezaEszBywVEQOMPOndJhoVwRlcxi2AnsntKRLb7u6HcqPcPB fC10rdF6/uRv45VXDewfalDWX0QxtDN0Mw+4gDNVHNzGs6wIwq4M8VviyyXT1BWD69lK EgAn1xLGtfS9luOBCwmyDyNNVhropZz/7B6+LSvc5dGkkYSPgirM4TzzCVnbf8zGwcis jZpZXfgj07+jhG65fzT/tjG9HPpcDqQv9kBwY2OPl3hXFvKHB5NBX2khRENZTLS12cKu F1+Q== 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=kgoBvoAdxeg9Tf8BY5zhua20aW3N8dGlw1G/CJAK2no=; fh=bSCDREc9/ThEBdDmIG26m9PQ/qB+dVzPJRz0Wak6Nvo=; b=S+hidvdsjVpEFV86ahhM1c4xV4sEFBxtyKLy57bB3Q3DQaTJpYQNDnC3BpD7V9wxB6 BeRKiS6IqWr7MyUSMlsUL8g7K67u66FPCVIi8XgqdqfGkf9O6rYXq3LeGwC1oHJa70yJ cykOXS5VFNU814ufl5XYP0up2O3DIHH9rkRKb0HprAB87lM5PtGXErW6238FWbudQYYt m8se0De3xS89LULzN7RKYmHb6Jv2sQRmISFnJx4ZN/UpeMrFGXfQkzalfR7329d2J/g6 Gv8LJ8KwYMMLLMO14eckC4fckzgkVjARp3SGKxkhV6QuP68vfESLs95/64cStRLro+md DFOQ==; 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=1791908237; x=1792513037; 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=kgoBvoAdxeg9Tf8BY5zhua20aW3N8dGlw1G/CJAK2no=; b=bML32fv4FwbWmQQr9LA5rdOhyXhv0S3RyMmGiWMrOQ5F+nT5/pQoysr2DODKO8F0Uy Ko4s2loVPLm6ncqCJ3CM46M85kqi6WnpHMmcvpZI3gkmB1xSW3t+rrYlkFDDIwTy5wfr lSToIbqnE9/iD0wl3Umufoapfn4IkBJ0hfi7KVdLXx56VlE3m8F+e4KKvE5HFXL2FLIJ Lq7C+IXGZ+gUBok60u4Sb20uY6/FGOOxY+1vwWVyurSUx60+tZ57x3XNM908bNzDvysf e3xzQ4eDFpb8t2/ihGFCbADUahwJZHUMg/mDwr0CTNhIcgogeBBbA3rx37yyLIxRm9Ul d46A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791908237; x=1792513037; 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=kgoBvoAdxeg9Tf8BY5zhua20aW3N8dGlw1G/CJAK2no=; b=wrwaSImCCJkrf79qxngFo5nwFdOwkDBlfesagI0/88uHuanppUz4rGuXX8B4oLrwWG 8K+pXbmiNCRxDlT5K3Pn4YtGVXUFiDKXJB6nSD57/wQwBqrKh0oUzia1yt/esiEc5Dmn Kj07bTSbcf4Tq9DLxeaH6RtanLCrNZucfUQikdjmCs1vqc6CHx5D0WdPZ98afa0E9eTd ds13VQYGlTyS/KrzAULe+6e7lTk1WVYNghtbr9+BOwLikqgJ9tpJYtDrrRES/8ErdGqS YWdhHq97L7NuqeYMqu5W9iwuAhCjG2jwYKu3AovwzxlpQZqAwXzigH71Iu/Xp9rw5WF9 XK/A== X-Forwarded-Encrypted: i=1; AKwUvBxyfYOc+hgVNWkHATojHn/qbhRwTy6b8Pht7bc3PX8Y5aCz/BJlI4Jwv2va9VJlnm2R/P7OTvN+WXI=@lists.xenproject.org X-Gm-Message-State: AFq9FYI6cRndCB7UpOGVJdKNqnf0NxnvC7mLiQS8pn42RKC3L1Uvo6pK TdgLJXbBfs21HLH4erzlLIogJgvTfHsTtqrVRKv/L7Y/4eelMO0mRIHrlBmrpTy+jzTM2G+XFfZ xEkQ8TQLfPkv+XhrfvrdQOXooDbaM4adi+Gg7IZATZw== X-Gm-Gg: AYBFou3m3GnJz7eMoPnNhwkGUF7q8Scy7gbK5kyzjDKEAyUtN0ZoUvjME/Xl2tYZ7dh 3x4Ns+3cLqC8vwLlzCd3biV8eFuyfT/zYiJmIsR2DEH1VlCCpmYy9iKLfkZHyPZm3Vdzz8MxokC yrbiltR2aUysbtevNAtCWVpxg4nyNIACEY0b740bRM3ywVBrfCQLPHbKWpIn6pSzo7M/dUYRggI FfnTreNlNll6QLEPQse6xdr5R25vDUmvUB5usjr1mEiAkWo81lxGILHGnjd24t7otv1w7bL7y4+ /vpuS2sezUU5Mm/portqgA7OQDPReheqBBOyFJgFmRUFGSnyct0VsdieFm0JUtd4RvyFHpBk7VW gy/Bh6oWQzvlPamiEVqscYymGI2y8fNTRZSHj51c= X-Received: by 2002:a05:690c:a1cb:b0:891:faab:ff1e with SMTP id 00721157ae682-8b07ec9b9c9mr32688387b3.4.1791908236645; Tue, 13 Oct 2026 09:17:16 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-14-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-14-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 17:17:04 +0100 X-Gm-Features: AclHuK-dBFJEqC_er2SVrafwbd048DTjYp8TESdTJHeoIpTuqcihJui1eCKi-p0 Message-ID: Subject: Re: [PATCH 13/22] i8259.c: introduce TYPE_I8259_PIC device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-33051d/1791908238-6F4C74E9-3970A1AE/0/0 X-purgate-type: clean X-purgate-size: 2138 On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland wrote: > > 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]; This allocates only enough space for the common base class's instance struct, but later we do an object_initialize_child() of the child class. If the child class's state struct is ever bigger than the common class, this will break. > 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, Devices that directly inherit from TYPE_DEVICE are awkward, because they never get reset. Conviently this device doesn't currently need a reset method, but still, is this a good idea? > + .class_init = i8259_pic_class_init, > + .instance_init = i8259_pic_init, > + .instance_size = sizeof(I8259PICState), > + }, > }; > > DEFINE_TYPES(i8259_type_infos) -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:18:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:18:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448158.1664220 (Exim 4.92) (envelope-from ) id 1xGfDK-0001k9-Ff; Tue, 13 Oct 2026 16:18:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448158.1664220; Tue, 13 Oct 2026 16: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 1xGfDK-0001k2-Bk; Tue, 13 Oct 2026 16:18:54 +0000 Received: by outflank-mailman (input) for mailman id 1448158; Tue, 13 Oct 2026 16:18:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfDJ-0001ju-46 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:18:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGfDI-00Dynw-HC for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:18:52 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace59d8-bab6-0a2a0a5309dd-0a2a4504c65c-40 for ; Tue, 13 Oct 2026 18:18:52 +0200 Received: from [209.85.128.176] (helo=mail-yw1-f176.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace59eb-b57f-0a2a45040019-d15580b0b8eb-3 for ; Tue, 13 Oct 2026 18:18:52 +0200 Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-8ad98c3fb15so24732427b3.2 for ; Tue, 13 Oct 2026 09:18: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=linaro.org header.i="@linaro.org" 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=1791908331; cv=none; d=google.com; s=arc-20260327; b=fe9kZjPuCY0UfDjK/wNzCko0DXjyV27uG6t0b3Xmqm4gT5NYIu4wo85C/M4oSkJpq0 K7SM2A3KGHk4/Itj2XTj+POwwtexrNs8D/KGFTgrvSjNvfV82BKYvN4ivSg9+7Ld3Iiq b7e/dnmtiBzV40MmlLbT1/YjQKk0Xthh//9VwKYnMcx4uBO/yPFC7Krb0drAbzFy89/g g+fBbO6NA7hHXBTKj8CuTJzdrYyMnQmxq/FpJ+aDhthY0TeIC8sQzqoqMVfupz5tbtJ3 95qdO/yneZS6Qhz3EZ63GDdOvkvXudO/ZGVp47DOT8hl8G/rwnY8h7aRmn+QIdIVgQIL nVsw== 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=uSFyrq7MF/+dr64UynPLy/FZzbgropuXsz8I5b5n0xU=; fh=VwtwRxvmUGcZ/TBb85CG3vKSYMtkrE5D9a3D4QmDid8=; b=d1thSJROmq01LiwHHHbt3zryrNL8E8nie+QQ9pDzU0uegdVY3msQfVL0Dx6DXiMI9k f9t16+B2Zr1DMGb0CKu3TVlD2BTsACkvNDuYcgXPEcbebr/bVEPXbQQjmDHn3TtZbN6i xELd0ZQnReZZN4M6KmtjqvArU0qRBD8lgAHzaKmcOlb5/eF5zriPTYBt5Iiz7aRkl46a /KHgUMQyrHFXcOd5aOG4mbYuG4OIhlsDRD3r6jF0ji3rdqOgW3OgzCNdAaSKmKugMkRU qvv0Is6CxkWo4p8yte/QTL1w8LUd8J/RB9X08OLaT2jkoy2sDPuCOhLg8sWJ56wAWTfr LjWQ==; 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=1791908331; x=1792513131; 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=uSFyrq7MF/+dr64UynPLy/FZzbgropuXsz8I5b5n0xU=; b=tC90V3WlLwYeJeJWJ02q+Nuy64TRoUgIfN3bliC0LJFbUQPzjftRdyfpf8Gf8ptv6g csUGKddNlNAJ3l7jZXLzT0UJ21KTwIxrGx5MnVxVuJi7rmJFvlgUGVGTlXT5TlgaMHOb +T3NI1U3kc2E7V6+zGKBF+E9xp+mdDqVGsm41rk9DOjokMuT/MH16Bv2+8GmEKW1RhnM 7IHAfTvELZ3hFaIVbCAJQp+vslHKmNlRecDUO3IHmwDbcLk7WrlOzCnl1z9rgStqSs9q QTCk7d/g6GGxwM+Vi7H4wHy/CC5umP6PYfIJH7cowPpDGTR4y9r8bt5hMZWCPoIb5Of/ wrKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791908331; x=1792513131; 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=uSFyrq7MF/+dr64UynPLy/FZzbgropuXsz8I5b5n0xU=; b=ixh+DTgR15QO3McDwxp6MfMUGLnR5Ru9cksaoCm/FGWbvrkZBpCP3rZNPUxxh09Qd5 k5I19EwGFew8CUaTgAgK9qPS2ROawWOmHtYVt33k+RCquEBssse+JC1aWQ6k1eG/m9Ca MdTor2RIQ1oYpDSwNH5r/6STDX0iF/AsjI0bdcnzNXiiZ7D5YIPUtbLAQ2+QDhZ9FhKs CuSHIINkV26F/bYmX3uYKjD2ESnWzZFwkGFRBrkA9OAhpUh75QboVGCjBPoLrobox839 0wlYntcAUgL/FzV95kGYSkn54R8uzxygITEEcCpWCJTZHBkduwdHmyHlvZb/GLNNkMaW oXrw== X-Forwarded-Encrypted: i=1; AKwUvBzVxFLHVkaYs+1OCbLFIYuSa+2N4ONTvWBDfKc94TPi2h40/GPdw09Nghnz/juJOkYZFwXfUBSxoJc=@lists.xenproject.org X-Gm-Message-State: AFq9FYIzWFV61tIzkJYLY3/HWhJ0elIeT7rI7DL3S+lx6rz+HJPG9DyN MBK7TRKQyiElRX9c0ZmA0Tm9JVQtXt1uXIBrBxEOa+f1yVrYUIFRhAhF+LYQqla7kX2I/PW3pPm bxq0NtbO0wKqb/i+k8vSA83FQ3O+qp5Xi5DijBr3euQ== X-Gm-Gg: AYBFou36io+MklXo7rQmdMmtiyEv1jP5R8bv7Z3q5BIanwQ48LCK5Hzi0iEvkwVi/ka 0Zf/mCgMQMP+bcPdrlgcOICwGU3s6YuDPhRknFsjOyFOFBYNbQLhH0CvBSuh8XfCtSH3XKWtQMh wi9dxZtMJbcg4Gh/tNBkx7hinPYzpnUM1SulI6i8BmHbO4ybalk3KkVXgLHA/h9b0xYDWElmjmT ZlhwriZ0s3cxUsumE815yTZevgptDNqd8l8iB4j5A7jVI9jlHuVEd6kQjXoSe+Ot3cv6XR10wTq EoW0V+AjkOfzc+0pS3gZCy5OeSxaPOwQSY0dJpt9z3cvS7ntXSh9hdygXPiI2srr9rFuU2duQax bRlsUwdXiYUyC5Zb874PcFIbVuZeUiHJZ3dAPZf0= X-Received: by 2002:a05:690c:dc7:b0:8b0:ad5b:d485 with SMTP id 00721157ae682-8b0ad5be51emr22293767b3.41.1791908330676; Tue, 13 Oct 2026 09:18:50 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-15-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-15-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 17:18:38 +0100 X-Gm-Features: AclHuK9Uj62eefTNn2tV-70nIiu-sZcGTBekM1cKcu4c-u_DW2QPHqh2o45UiIc Message-ID: Subject: Re: [PATCH 14/22] i8259.c: properly cascade secondary i8259 from primary i8259 To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1791908332-520D5B50-D0870180/0/0 X-purgate-type: clean X-purgate-size: 1000 On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland wrote: > > 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)); We just added this line in the previous patch, so we might as well squash this change into the previous one I think. -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:23:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:23:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448165.1664228 (Exim 4.92) (envelope-from ) id 1xGfHi-00040e-VS; Tue, 13 Oct 2026 16:23:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448165.1664228; Tue, 13 Oct 2026 16: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 1xGfHi-00040X-Sh; Tue, 13 Oct 2026 16:23:26 +0000 Received: by outflank-mailman (input) for mailman id 1448165; Tue, 13 Oct 2026 16:23:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfHh-00040R-BT for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:23:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGfHg-008ZOf-C6 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:23:24 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5af9-2eae-0a2a0a5409dd-0a2a4505a12e-8 for ; Tue, 13 Oct 2026 18:23:24 +0200 Received: from [209.85.128.182] (helo=mail-yw1-f182.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5afb-4cb1-0a2a45050019-d15580b6d815-3 for ; Tue, 13 Oct 2026 18:23:24 +0200 Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-8b05bf699easo23469577b3.2 for ; Tue, 13 Oct 2026 09:23: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=linaro.org header.i="@linaro.org" 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=1791908602; cv=none; d=google.com; s=arc-20260327; b=rYCXK0WW4ZntzZT8ddwfpm3NP8hvFo8CypjaHbcQU+quFqP63BuoacHYmiSLTC50Nj vkzahpHUVGmI1o8pG2aCiCgD8q1NuToxvY5WOR/XtowOr6EIr47l5e7mpSG0wlbDw5Wk sYzBL5LYZ1jv2UTfeWyZHjacA3xs2an+v745J/KkgwTWLhkoFCq1l30fzJpCZE9kGPxV PExcxsA6T2j6yxZvJ3CbSJ+5zlSbqUONtbhdd3792P88I3EZfNDx6W/fVbMRTDUQcQE6 8fq0LKE6f1MWYcKuWDSv993EYzKUdWXqqUxkwBrNE7AOWhsK0kfSkNAUIxtzn1yUhUTo kFfw== 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=0aU3xZ0O9qtDwjPihhb4Xe3w0i2uTKvAQPFqDUeHH/o=; fh=EPCCytDeP3vLQ7g2MfIU1KePKPlwz1O+yDAB06rI5ws=; b=EbwsBrFUWY7XrUoLvMd58Lw7ZYzC5YWQrg/qzVoWieXP0McpB0MMimKLADXI6WQncF QlZy+7y0hJ1N/oHDQQ2LurqJKX+j9tMTK54x0gK9E2DthEsVvBggJ0dt8mYKDDcYR1pZ sHBg9BEu3qRIGUA0qVZscOiZUA5KA17ooht9RL0qo4ol1MU6mAVDo4/Jlstw1AeKP0jW elgFNORy7JpCmPDXPzt3IQiaWoSZreobuejyoJcMS0BoZci2c6hHtnSQA0yddZl4pnS1 sd8RcC9yfXbKYAZ/ajbbzyk5zDHSH9SscJmW0CEe2YTkaOPlPnauc9V/+cqJagVCjMui OCTg==; 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=1791908602; x=1792513402; 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=0aU3xZ0O9qtDwjPihhb4Xe3w0i2uTKvAQPFqDUeHH/o=; b=hwcUntctFOa2h6wqomvRibUqPXytRFBuC0+eHBQYDDJLqrhFEk3MRPJPHt8tCwIo+f n3gyYtDKuK9CtEo6Fx32WFem7hZBrfNHdRSRR5y3uX87JixQTdpnpC6TxTfDL/evJo1G Pu9D5/HYR64vWaOCOGEzHBOZC30/rds9kCnCAJL1xTnRh+SRLAgWl08GVTP+LNdIUuGa rerzrCpRwkS5K5eVtKOA+Jb0vXr22jng/W6WNFArkFGLbONKTXQqUiAmknPFRpmS1ps0 ZpJbyry1gWArPsh+ZWxo7PGp+Wtq05jXd1Av4OG1o6Oj70xouaecgof/40Fk/7/TrH+b x+1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791908602; x=1792513402; 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=0aU3xZ0O9qtDwjPihhb4Xe3w0i2uTKvAQPFqDUeHH/o=; b=M0Sg1ph8C0ylFVqhNcV1FC1+0WhbcDcnNBxwhkCAJHxo/Hhf8aXZDMqaU7Cxb5xObg 9RFDk4vTrftT3g/OM58IPooIAHyCbwUUcgtpQfdEkiM1yBhLdSjy31J+ITP/w32FVhEM uHiNSH4VRqz0XrEwDVNjQxRS+J/V1Hv+I9xYWhOXlnmFFRch0xn0zJQs+nPlx3LFdNNx ugoF74LrJ0e8J+6AHYf/wcme/rWXj8f9UNb0L64vBdvWPGKIQhA5XCEXjHFgrSxnt/hF DG6DzWYsXLXgoLoKO04fQAWhAxiXTFl0F+IbwxoGRdeLzDsthgGSQOqEGeSQ90PtYdUW eI/w== X-Forwarded-Encrypted: i=1; AKwUvBy+xoEq1Fq7RJtcCUb/+heJEixy/mBi+ZfBDJAOTXyF8JHyT64YBMSXirBneKc81rra5CPb2UDxTIQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYLTr9SLlt9sQ+fVG8dDmGuPg9NG1IiCiA39odcKv4UWKUJy6qvr LyGE8pfWmm+W+rMPoRcTLNlZJDnQEcwoGyAF7K9wqFZscW+FwNHsxsHfvHGMzAbA+bgexderUuG IfpE+PpkIvW2NT39oJ4QetkEBTh7s1GtGRjRTnA+Q7Q== X-Gm-Gg: AYBFou27wG/BurZ3QDGtzdWUra/bUQU+ZXgr/dDAaaM3qLNepdeMn/SMolSTvpBV9Zc QoRVI3yLCwezcSt9hYs4c2v9b6vw/Uj6wp2E4VpWh/el6iTzGpm2+3T0RwTJZWsdmZyySlcde46 LuxFCW5imKe+d0uk0vYoJCmZdZXDzwnw7fbQP+dkEuKjNZA6cNReLl8I2VEpEQVvN3vw97lfLsC igKsrknkv0Krg1rC+esEVhViNjCrdMTYdJ4sW4SQK+UezfQTanlm2F1sEjr8Sr7DoV5Bj2fzgjl 9Dgg088EGasH15Ir5omLipc3yhefmaE2j1v+TtYcmhFUMhjg3QnRsr0t2CfoDnmdwNJ6Uv1sKkH kx+/hlV0T3Qb6rs4r/gby7rxk6B0vmRWLb5+ytMg= X-Received: by 2002:a05:690c:64c9:b0:873:5c6b:a303 with SMTP id 00721157ae682-8b07ee3497fmr39132687b3.49.1791908601818; Tue, 13 Oct 2026 09:23:21 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-20-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-20-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 17:23:08 +0100 X-Gm-Features: AclHuK-MjIAggBsDJMxmpzNkKaRTjLSJqxxUvhq9jeMG2XLDgmhSjMKS0aBvJ8k Message-ID: Subject: Re: [PATCH 19/22] i8259: move InterruptStatsProviderClass get_statistics() from i8259 to PIC To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c201ff/1791908604-72CB02A1-09D21F41/0/0 X-purgate-type: clean X-purgate-size: 768 On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland wrote: > > 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: > Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:23:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:23:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448166.1664237 (Exim 4.92) (envelope-from ) id 1xGfHr-0004Da-5m; Tue, 13 Oct 2026 16:23:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448166.1664237; Tue, 13 Oct 2026 16:23: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 1xGfHr-0004DT-2P; Tue, 13 Oct 2026 16:23:35 +0000 Received: by outflank-mailman (input) for mailman id 1448166; Tue, 13 Oct 2026 16:23:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfHq-0004DL-6T for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:23:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGfHq-00000003SlZ-1Vhp for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:23:34 +0000 Received: from mail-yx1-f41.google.com ([74.125.224.41]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGfHp-00000004WfH-2jkz for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:23:34 +0000 Received: by mail-yx1-f41.google.com with SMTP id 956f58d0204a3-67921b515a6so2413568d50.1 for ; Tue, 13 Oct 2026 09:23: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" 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=s6uEOKcMzohNhGkt1Fr81Jumh96m8F/BTpz62rtwgwE=; b=xIelQXDCnodtrsx1Xhm1T3Nowj XV2b7kggwyyjU+BodMt72yYLIjD4tKpBl35oMXSfH6FCtE6p+k6IFIpqP4g5O3xF/GCzGPhQyhL7p YUdhELZyl5CwWRG2k2RfAL16EZCkl8v3PZ6YTde4sXlXPjg+4csCGJRbDG5Gl5j962hg=; X-Gm-Message-State: AFq9FYKdCJmvOVCkLy1rY10wr5TRalG5QNwnsM5GLkOUdLTMBDnQneKT OUY/h3Ws0jNU3bb2mWIeRGzth1Qd/kYWVrGCzg0gdiU8GOztlv3fgyaywBWVUhORNs8IvJmDAyw sNjATS2x7iwW+yLQ+/7edeHtvUNJyb4U= X-Received: by 2002:a05:690e:43cf:b0:671:631:785c with SMTP id 956f58d0204a3-679360662eamr2435293d50.57.1791908613721; Tue, 13 Oct 2026 09:23:33 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-12-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Tue, 13 Oct 2026 17:23:20 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8LsJ0STSPjLMN7gImzbgWt9u8z0q8MgEoQx6XLgwfF-7rNynB3R26w4hc Message-ID: Subject: Re: [PATCH v3 11/18] x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 2:56=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > Unlike a domain-wide mapcache, a per-vCPU one cannot, by design, > > borrow slots from other vCPUs: MAPCACHE_VCPU_ENTRIES (16) is the most > > single-page mappings such a vCPU can hold at once, interrupt handlers' > > included, and one more hits the BUG_ON() in map_domain_page(). The PoD > > zero-page sweep held up to 16 on top of its callers' until "x86/PoD: ma= p > > one page at a time in p2m_pod_zero_check()". > > Is it really the best approach to keep the same limit? As you note, > with the mapcache being per-vcpu the limit of 16 active mappings is > going to be strictly enforce, which it wasn't before. > > The per-vcpu mapcache area is a whole L1 page-directory (it cannot be > smaller), so that's 512 entries per-vcpu, of which we limit ourselves > to 16. > > Can we consider using bigger per-vcpu mapcaches, maybe 512 is overkill > for the bitmap sizes, but using greater than 16 will likely avoid > frequent TLB flushes to re-use the entries. Maybe 64 entries, so the > bitmap is still a single unsigned long on 64bit arches. Note that > declare bitmap will already use at least an unsigned long for the > bitmap itself. Yes, I think that's a good idea. I'd thought about extending the mapcaches since they'd be now per-vCPU, but didn't want to change two things at once; but we're already changing 2 things at once by taking away the overflow mechanism. 64 bits is a good number, given that we've got anunsigned long "bitmap" anyway. > > @@ -191,7 +207,12 @@ void *map_domain_page(mfn_t mfn) > > } > > BUG_ON(idx >=3D cache->entries); > > > > - /* /Second/, flush TLBs. */ > > + /* > > + * /Second/, flush TLBs. A per-vCPU mapcache needs a local fl= ush > > + * only: its entries are never _PAGE_GLOBAL, and this vCPU's > > + * page-tables can only have been loaded on another pCPU via > > + * switch_cr3_cr4(), which flushes non-global mappings. > > + */ > > Shouldn't the above comment be inside of mapcache_new_epoch()? It's a > bit disconnected from the code here, as apparently there's no > different handling here between per-domain and per-vcpu mapcaches. Ack > > > perfc_incr(domain_page_tlb_flush); > > flush_tlb_local(); > > mapcache_new_epoch(dcache, vcache); > > @@ -313,11 +334,19 @@ int mapcache_vcpu_init(struct vcpu *v) > > return 0; > > > > cache =3D vcpu_mapcache(v, &dcache); > > - if ( !cache->inuse ) > > + if ( !dcache ) > > + { > > + /* Per-vCPU bitmaps are a word each: they live in the vCPU its= elf. */ > > + cache->inuse =3D v->arch.mapcache.inuse; > > + cache->garbage =3D v->arch.mapcache.garbage; > > Well, the size of the bitmap is set to 16 bits, but due to the usage of > DECLARE_BITMAP() the underlying type is unsigned long, so it's > effectively using 64 bits (a quad). I'll adjust the comment. -George From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:26:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:26:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448181.1664245 (Exim 4.92) (envelope-from ) id 1xGfL6-00053t-IJ; Tue, 13 Oct 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 1448181.1664245; Tue, 13 Oct 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 1xGfL6-00053m-Fc; Tue, 13 Oct 2026 16:26:56 +0000 Received: by outflank-mailman (input) for mailman id 1448181; Tue, 13 Oct 2026 16:26:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfL4-00053g-OK for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:26:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGfL4-00G4P5-5I for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:26:54 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5bc9-e002-0a2a0a5209dd-0a2a450bb0c4-8 for ; Tue, 13 Oct 2026 18:26:54 +0200 Received: from [209.85.128.181] (helo=mail-yw1-f181.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5bcd-b7e8-0a2a450b0019-d15580b5ac3f-3 for ; Tue, 13 Oct 2026 18:26:53 +0200 Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-8726acc5eadso24297607b3.0 for ; Tue, 13 Oct 2026 09:26: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=linaro.org header.i="@linaro.org" 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=1791908812; cv=none; d=google.com; s=arc-20260327; b=ATbktG6+tw+meNWDiT1JJIaiBsg1SnUCURcbYeKkpYNbzckOmfFJMPF2HhnfwG1gpW wxhZxHhCbZX3TYceshSqa4o8KG1N2ErURmfIOBgkW+hNyIzlrTzeK+laocwKgU6v84PJ ik2tIoo7etis8wsIeQvBqNSHIYAE/YhRARcp5ZZdB+ElGBqlc7PO0Km3fs4U/nCzgWvJ 1WcXeyA+XXycLxMEmGVpRNNASshIxB8DzpO1TDhR8iVYCISjmsV0juH+ZrBLhkRAREUn 5lprpetpWVunPEm/l9DeWkLtFcqXKLkN9hbefgFo2iiO0Av8S0fq/wnJbLFG6bcKqNM1 9/Dg== 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=lfW0nUOSaRUIuZAH3PPaoOxVv0uganAcfQGMmdwJiqI=; fh=9VMul4XEbI4AZThU/pUXmxEzBjQG999I7MjlUiUptPs=; b=GMEDKwkl8zMfWRj5DpDxXSFdsFg4T83BRkcMiyDyE1xDvgW5qbl/AmmVzucq1FfFWA KWz3yyFeI0Dm2N19xiOLbxRLzcLXml/5M9G1sLavBvekxXsxH5Mc6HpMm3klwcKWPGDx tJD/ffATRDRJYACBqBQdjSPylPmgpg2BCDEaLQThH8Y+IYAr4szX7lXB+LgazrXoKZYr fF/UkOi/qV1CdefUpLSVCL+AJZ9N14u1zTQUCheJlfpxerMvv1GJfVNQWzFfTuvmiyX1 XXgOhT1RWgLvcGV5WQmTaUx1mt64Pez6SBDgM3RXUUJRDnLZvVKLSsdRtUaOs/PFtpKu HsPQ==; 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=1791908812; x=1792513612; 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=lfW0nUOSaRUIuZAH3PPaoOxVv0uganAcfQGMmdwJiqI=; b=kNovbmlIm13kSlVsqTlGmVbVYdLMA6Q7xxWlpI8vjjOV4A4Y1D1ldCGSCgJOANmYbH AR2Ix6FoaS69GIlPl5JUmofIBDOi9++gCpXWAcWhVfRuxW2Nu9xK3b0dx1lese1jEvIv /HSRaCbFVsg2n2iGUPg5UkYDFE/L1jCze8ciXJz4aQ4m7pHG/pBnH6VVkHjZXWguld4D Zg12SqrjGhdEJV7I7lpOjtp8jcP1zeeN7I2VAHy6MeQQnEJF9ikaHHi1R53FDShwdW7p Gw6mg/8Ecbzhonnj5GZWBYr86NH3hY//SZbfyiLEaULCqvJuIfoFGTs+wqnQDiUwwpzD ZmnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791908812; x=1792513612; 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=lfW0nUOSaRUIuZAH3PPaoOxVv0uganAcfQGMmdwJiqI=; b=Z0cCT36ejORszgOwRa/TJDe9SwF8MEYJd7dEVKHsn/R3huSPVq6nfXn5kldo9M9O4k 5KI9Ku12LRuhxOpu6ZDXW4YfzVaWoj7YMkN7nSzc8bUeIJccNx0pC35ayjj8ejzrQJUh 2tJMmHfIBJwL7OHtcdhSt1hYvt4IO58Z+CWwT5AGcil5ffnunumHvtay9C+9X0OSb3h9 JKTNqWYrG6vjHdCMnlcGYxVvvcYCDdp67hFr3SUWnaZ3PvMwCppKNVnhRie4REhbqnrm p+fqZ5M2Q9v9Rf3Q5PLD/ooeIfmdFsuKzV2GKJ/30Iuifo5y7mxXyfuAARH9xDYYcKFn mmuA== X-Forwarded-Encrypted: i=1; AKwUvBzb14xX7/y92GUTF0HhVbbzFWBHYpY5uZtxpBXTAJUgxawkoDKSWCK5+wwo2QSD/lD6/MsLToRcZxY=@lists.xenproject.org X-Gm-Message-State: AFq9FYL7Sea5Za3+D7i/YYNwSMpM6vt7P/sEKJX81RO5jK9DU66Va5U7 Xaqw5Abd3wXB/u1cPI9LbymEJOiu+pgCZKMeIZRdnjOcytd2e07fL3FGatY+ZL1bJGxlQUAt9Nr RlU1ePa2/We7/6Xcbz6UiMqgIqfMzKjZ6+sPmMLg4NQ== X-Gm-Gg: AYBFou3gkaO/3JpBG2ceEtxU7eQ7hP7WZOlc+LMDcqfp2C4me8b7qGu7/2G6XxexoVj 6xnQTJeG9kqP/Y5fZL4TcBdg6BxbOR9910CXioK86tYvhkS/+ZhdWVTei/G+LjdprF94pYYPPcN mtE+BASbIoNk5so62biAozAXWC65ue/ja/rQryR5PB2Z2n6jOqxRLziRKNROyy+rkv2Zcy6TG5d 0frfBwKmH/Ks/X7drOXLa6AQEgRV9M4ANGUWpqO8T80qIlxCAOpjj5YdfpL6NzJ/tgZEvZno6HV XkBBGS6k3l26Im3YHL9LDrXF8OLFSrWA6X9h0TU4E0rA0tr6wlm+sa1GHX1qjTzrNCx9K4P3xPD h/oVtw/KnW00brqmvfWuS8IphmBY9xHFVzPR6C4o= X-Received: by 2002:a05:690c:e3cd:b0:8b0:ad62:19aa with SMTP id 00721157ae682-8b0ad6230f0mr19157117b3.33.1791908812379; Tue, 13 Oct 2026 09:26:52 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-21-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-21-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 17:26:41 +0100 X-Gm-Features: AclHuK9LMqtW-CAAZ3xrwGlJrfDwYU71aDjAnimvRogO_6sdanZdfIn2PpOI6Zc Message-ID: Subject: Re: [PATCH 20/22] i8259.c: switch isa_pic from I8259CommonState to I8259PICState To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-42698a/1791908814-1AEDE9EA-5F644D85/0/0 X-purgate-type: clean X-purgate-size: 964 On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland wrote: > > 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 > --- Reviewed-by: Peter Maydell (That isa_pic global is kind of ugly; in an ideal world the callers would have a pointer to the PIC they cared about rather than relying on there being exactly one in the system...) thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:29:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:29:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448187.1664255 (Exim 4.92) (envelope-from ) id 1xGfNW-00060k-1V; Tue, 13 Oct 2026 16:29:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448187.1664255; Tue, 13 Oct 2026 16:29: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 1xGfNV-00060d-UZ; Tue, 13 Oct 2026 16:29:25 +0000 Received: by outflank-mailman (input) for mailman id 1448187; Tue, 13 Oct 2026 16:29:24 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfNU-00060P-EB for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:29:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGfNT-001oJf-GX for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:29:23 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5c58-bab6-0a2a0a5309dd-0a2a450b9c24-16 for ; Tue, 13 Oct 2026 18:29:23 +0200 Received: from [209.85.128.170] (helo=mail-yw1-f170.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5c62-b7e8-0a2a450b0019-d15580aac90e-3 for ; Tue, 13 Oct 2026 18:29:23 +0200 Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-8ab38a051aaso25228897b3.3 for ; Tue, 13 Oct 2026 09:29: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=linaro.org header.i="@linaro.org" 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=1791908962; cv=none; d=google.com; s=arc-20260327; b=O2dfiuxpdKwluCw/PBHCErVYzmxJpNTylN6I4W+1dtfzgXUQuqk9lwNFmY7azc/jDR tf9AkgL4A1pqpFR6fm8i+CAr0sJFirnBU5U8lFeB/7v2cPgvxbSvOk815PUr//Pu48Ob xVyapa7X44UI4HiMa+eWzoJr8y85AEAmOfRRHp2U7InAfHphtpfjf+wlOrJua0i9Vzch LpXU0P50/BVLezXJdx/fJdNSshrVyTpEtKL3tUClgp8T+FcG0jX2CbU7PWtirh6iROpo HueVET0Lhc/oBXr0CcancZdywGVhQU5OhdboE1PU39nUX7zf/88Dv792Xw7Hqmmo95s3 005Q== 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=jXo9q1ZmZcN51gvyAI6giPbieASxcFI/Rz78Tc/rF4k=; fh=soxJElAlokBxb0qXlToTWx+nLUSaWOMvgPaeVh3fGx8=; b=mW9pfk8bDz7ey1bAQ5MjmKfvm1F85E+Loa1nc6XBb0JTTxQ6DUxx4CMfx7g2RNU06Y rpGxZt6gNb1/u4pCVRQ/Qgm93qgocuSdwJ/w2VrJfoJqJKTQonfU0ZxrqBNhLHfjiuFs vtN8DNMqli3S3VXwEb8PVAkRiIGPSsjuWLw6CCotIlMI8BoTQsi2LOfbMDTiXMGC5903 X7mQydqnfKuB/xBHxZ1k+cV/j1nQyC73Ps7cstYw6yYCZYns0NnUjVYigERCv+L0vu+/ wHLhPj50Td/uHXPpZwmmNYg6r4CWOZUqHp8jcTPDk7veNkkdGBUC9+30Jh8t0qZh915o LPHQ==; 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=1791908962; x=1792513762; 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=jXo9q1ZmZcN51gvyAI6giPbieASxcFI/Rz78Tc/rF4k=; b=dUPCRbkbVGnQgh56hdz9PnC/FzbqZzGNjxKgnaXZEUBVS4zEWdrg32WoS5Fg9GUnHJ kgXm78l0mV2uXws6JQ6lk6K/RHzLQby0I8MfWIbKxojKS1QsbprqyjugctMfNee8gsYQ bKaL+F4NAoe0k5NQFwHyrERNOo1/Ja/YHVNyRVXBKFbQyHABgHaY+DuvqSwYPJ0xBEh1 PBn0o8xF70X2PrGmCz/n8pRCE4KFAWu7n0HwpDzXEcX3ouH8+pP88cXL8TvT3IPgdhJM cAqjHy6aFrMVwvYxtPJKzKu5Uq10O0Iksp21TLFy1pZeXZqSmV6P+qrNqKQVW9o7RZdc 9miA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791908962; x=1792513762; 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=jXo9q1ZmZcN51gvyAI6giPbieASxcFI/Rz78Tc/rF4k=; b=cTl9IAqXMWIyqbrcqFKpn3PEG0U3jv9etLR4Vl3SBpwYVtrTOQQUcdsf5/gdBkO0Jl vzhgLEEOBOkabSXp7ggDMNwC5UD5nVcqNoJ05yocmEJfAnpqNXU+ZYGF4mZYVbaO1Zop NdjIPjLRN2ev7aPUH6+4+mMQtCk/990JVNjBabXrA58fEUNrAemFDhO/LAEBEQf6xx43 Mcw9GEYMuNcXIOWWdrxbtSvTvCNKm/7LrrQBBg2l5SaQOvdKQSzczIFRPmYKHkElvA3i jJyjBZunaenyhc5f53ODHNVKhfdsqS+lhmz5qVaN72vYpqpNJRPR/pvvejW2eRvF0ePT HdlQ== X-Forwarded-Encrypted: i=1; AKwUvBwQ6PvVTvM709WUJPLz7Gcgg5ETVypGZ2eJHveiGMd7OVFUjMBtzrxPpnBI0MObbbbtOECeohlNl7w=@lists.xenproject.org X-Gm-Message-State: AFq9FYJOsHbGRUdCQ0ZMJfu5yuBnFkK0pwEI8inrwGYbHh9Hu5tNP2ob vDQxoUU+iOcSOdpwyHgyINemY11kG0CTRlfCgCf+wlIUqAua5wa8ZbMIXWYw0nCzPSZMl+vawFP Y3INmplbgBgJOaGGqx7bUPxZRcCCGXqQbHtO5plkwYw== X-Gm-Gg: AYBFou35IJhzH2NT30TylvCT/MpGw2qfC04/sqWKXrlxV2rqPDDPEM6w/dGPmwbuMG0 b6LFCZmUlrG+ONeZ2nHKZnzeSuC+K9n8M5zlF6aHvdxFhngb9jCznCzwrHJpF3QfhFMK5uc/niG i6amdEwQ3djtowbKiIc3F80aOJ5U4JOg+Q3vRR9boLS/eJtCcAQZqgPAsWl77y3+rMiHb88x49u TwOzOLFvLxUvMcfru0aPwnJPf7OggyOd4fL6LC7lYxhzKykYcuOwJqyHIUMcwhHnMEP8+2tenQ/ q1anVKpvCeJYZucI9EAGfy+/3aXo2Byya5ccSDL7CnCUvpCeGDJK+7TzcGR9/yrP/To0g8ey61Q sp79NFcPr+QSkmYLO/jt6JqFlhK+m14ezcT0Th+w= X-Received: by 2002:a05:690c:e1d9:10b0:8ae:dfee:cd30 with SMTP id 00721157ae682-8b07ee80677mr32738227b3.56.1791908961569; Tue, 13 Oct 2026 09:29:21 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-22-mark.caveayland@nutanix.com> In-Reply-To: <20260916104435.600211-22-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 13 Oct 2026 17:29:10 +0100 X-Gm-Features: AclHuK-eFYommmfqG_nkwY0m20Dw4f51-5ZNktl8ml0khtEb6QlSNypivh2nwj4 Message-ID: Subject: Re: [PATCH 21/22] i8259_common.c: remove static irq_count and irq_level variables To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-42698a/1791908963-1AAD89EA-03191650/0/0 X-purgate-type: clean X-purgate-size: 1568 On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland wrote: > > 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 > 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]; > }; > 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 > }; Would it make sense for these two types to have a common base class (where the stats stuff could then live)? AIUI they're both intending to provide the same interface ("pair of i8259 devices cascaded together in the way that x86 does it"). -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 13 16:44:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 16:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448200.1664264 (Exim 4.92) (envelope-from ) id 1xGfcG-0002Oe-8q; Tue, 13 Oct 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 1448200.1664264; Tue, 13 Oct 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 1xGfcG-0002OX-5W; Tue, 13 Oct 2026 16:44:40 +0000 Received: by outflank-mailman (input) for mailman id 1448200; Tue, 13 Oct 2026 16:44:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfcF-0002OR-Aa for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 16:44:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGfcE-00Des8-Gs for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 18:44:38 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace5fe1-8faa-0a2a0a5109dd-0a2a4502d328-26 for ; Tue, 13 Oct 2026 18:44:38 +0200 Received: from [40.107.200.14] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace5ff4-6ca4-0a2a45020019-286bc80e0ccb-3 for ; Tue, 13 Oct 2026 18:44:37 +0200 Received: from CH0P221CA0032.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11d::11) by PH8PR12MB6795.namprd12.prod.outlook.com (2603:10b6:510:1c6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 16:44:28 +0000 Received: from BN2PEPF00004FBD.namprd04.prod.outlook.com (2603:10b6:610:11d:cafe::8e) by CH0P221CA0032.outlook.office365.com (2603:10b6:610:11d::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 13 Oct 2026 16:44:24 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF00004FBD.mail.protection.outlook.com (10.167.243.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Tue, 13 Oct 2026 16:44:24 +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.53; Tue, 13 Oct 2026 11:44: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=MrGnZ77sr1KDPlTWPWSMe1LL2p0aHf6paT9wlYNwQsOLbbgSzLOyDOM4EvHlD4vKpYtS2X58rbGgU0cqEPH+cB07FOQFEEqmoGKTHmeURbBmfA9qSOt6MYUOswsJk7aHRFFBMHw4DsNhW4PxKMBMz63HQkKM1Yga3JxO4uOhlVLcG9bGlKCUtMw3o0H/j1UHa7jcbrx+m/3jQDdkj3SSjrOkqBWGo/dy8HtCaMU7Qd7vmGDeXs+N4L+DyMaID4S3X54j4rfKtsVS9g0UrtCAPcfJSvILQA32/QHzo8If9w55NtW90Skz1X2IbAsYnzegupJApeM+cZFw7QqR2N0oKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wZwU6Sjg+jgCW0wNM7COHOGNdp+jY+I3apDmc7RdrcU=; b=fHbflLCx1kSXhC4gWW21uBMK8IxhsSoDGBwfpOgodJKY2gJi/Z142bhuCTS4EH13jWqsSZvPv17b76Ns1ug76A2yhxkHJSpQYLsJ13cZ0kTySoyEkAlu1e+njZcZn+3MGDikoUNjlHWxlENpi7tGVkyCA/oxaW+V2RuQrFPIwdWZbBZ+thFdyWT6Mp6XKrF0VSEKlKaCH9UYd9bGMowrEwsWQI7IycRk0fEal/qR0P1MDb1xVFlIi43FMEBnwruD6uvzdFXGNaaEpfRCRvym3YvN5RpEPVkOPdgmgez8TmMU1J8kt1iuCFuS2rK1ENAspFq2Jk52wcEOI+WBcbPQCw== 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=wZwU6Sjg+jgCW0wNM7COHOGNdp+jY+I3apDmc7RdrcU=; b=mnn8DOHHGqPk98xu4hGJj/WeFLdBIRFvfgGG7JebJLuYArolmS8u/7ITOlAKBir+5nB62YDaadD+2JfOeywqrP05xi83Jg4KmvEZ3YWJfvwKpWqKp+vD8SC8N5N3KOsBIo3hzteYEPwVQgEgji2ATuhQkpsOAUKdTBfa2AN2p5o= 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 From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/hvm: Fix UB on defensive default case in handle_pio() Date: Tue, 13 Oct 2026 18:43:56 +0200 Message-ID: <20261013164404.361893-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: BN2PEPF00004FBD:EE_|PH8PR12MB6795:EE_ X-MS-Office365-Filtering-Correlation-Id: 44ce009c-4117-4e15-94d7-08df29493d46 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700016|23010399003|1800799024|6133799003|18002099003|10067099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: sCLjz16AISPYJWJgK5BaixiZ3NyaDSfXF7JtmOGkFxetTRVHmJNNmtHC6bcME4OvS8JsqHXbj+RgNgqUOSCfGJpXFghWbWXFIndxRtwQ5H3i/sV5cnQYbWCEkY+cuLHTLJ4Ds4IHQcxsTUr2r8go+QGk302vOfwjHmnuMWMjJz6bzaw4jhbJZ3cK9WpgACVuT7RaoJ1AtaeCAJEn6Y9HGZcftwmW1LDW+K2jMq6mS1jrIGrV/BCU+oIrnDQUDph2+S2siivVRZiraMLV31kMv6+enGvIlHC7s2A7zdXzAY37ItfBI2vNb7cmeIkWW6riZAd6hkSGYh7GN2Wz6z6RcNc56q8fAkDb7iZlWV9gQcQtko35qGnnpdbkJvD+l9wc8jcrlwiXqF5zYZSGvP8PxLQbLThO6SML1Ova9Rs+Obvq7NoCeDxmQ8qUmErlWZLLOlAjnnms6NxrSwdPedRUu2XWe8Ey4KaDMYY8DlQK81ckjto4QHTpNvkkXDeh9dn19z781FSDii+vthEcKiRooquijRcV/kziBJI0ndehNfV7U293L1B2LNhrl/FmabA4yFNVS+ltz3DgSs1C+gGSuaHFz1m/2y+e1LkGXUNdGjY5D9r1drEYuQlDMtEDU4A9c+76C+JtRWER0c1eOo+opXYyYkfLWO+nCA3tdE+pZyyFahNtHY+Y/iRcUa5y0RgWuB7MgzIxbgPVK/co4PqXXw== 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)(376014)(36860700016)(23010399003)(1800799024)(6133799003)(18002099003)(10067099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: eiCZqVBeq9998rvvY7Ty+yEFTJ4ctj+GXJ5b6CXfioM+wHFkw6I27ueIgSfDdopJJ1gfDnLfbFHvzEUm82ML/67MmgQUiHzJ9u+ujw+kBWFvzzrOWQ8G246r0d4RGcO7eAI83Uuh9jZa6egDElu7rYHs5w9uFeQi+dD6tLP82UQV217V5fmFChvG6aKJB5/HMKN418vZfWckUXOz/S7rBuZiHeTl8fnuaTelvWzGqN7og2EihwMWGlyLg3iECFUfPNoot1a+O3KI6vC7/x5rOXjLnwZlVIvVyb8Frw2Zp82RZM5Ztne+Wqj7NmCHLbv6DAIR2lpYD4eQa3BknMWrm0D0Vv0hBymXVpPMDigDgiIcVpaaucRiQBVCpXcZjh2zDjn41wVbvNSPBSSA82cPOYJNgjxoSk3ASVu9gI2ymLpr10f5rtduFxJ1PhVGvmE+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 16:44:24.6814 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 44ce009c-4117-4e15-94d7-08df29493d46 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: BN2PEPF00004FBD.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6795 X-purgate-ID: tlsNG-720697/1791909878-313CC2AC-1D9EEF2C/0/0 X-purgate-type: clean X-purgate-size: 1081 There's a potential 32bit left-shift (when size is 4) to a 32bit value, which would trigger UB and tickle UBSAN the wrong way. Shifting right an all-ones mask fixes the issue. Fixes: 4609fc8eb04e ("x86/hvm: Improve error information in handle_pio()") Signed-off-by: Alejandro Vallejo --- xen/arch/x86/hvm/io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c index 912e55d416..91cc2e1dcb 100644 --- a/xen/arch/x86/hvm/io.c +++ b/xen/arch/x86/hvm/io.c @@ -135,7 +135,7 @@ bool handle_pio(uint16_t port, unsigned int size, int dir) default: gprintk(XENLOG_ERR, "Unexpected PIO status %d, port %#x %s 0x%0*x\n", rc, port, dir == IOREQ_WRITE ? "write" : "read", - size * 2, data & ((1u << (size * 8)) - 1)); + size * 2, data & (UINT32_MAX >> (32 - size * 8))); domain_crash(curr->domain); return false; } base-commit: 6b30eca0e388e5aaa4319c647a777d703d7ee752 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 13 19:08:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 19:08:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448261.1664302 (Exim 4.92) (envelope-from ) id 1xGhqn-0005xs-Bd; Tue, 13 Oct 2026 19:07:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448261.1664302; Tue, 13 Oct 2026 19:07: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 1xGhqn-0005xl-8U; Tue, 13 Oct 2026 19:07:49 +0000 Received: by outflank-mailman (input) for mailman id 1448261; Tue, 13 Oct 2026 19:07:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGhql-0005xf-BD for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 19:07:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGhqk-00Dwie-4P for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 21:07:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace8169-8faa-0a2a0a5109dd-0a2a4501dddc-42 for ; Tue, 13 Oct 2026 21:07:46 +0200 Received: from [202.12.124.159] (helo=fhigh-b8-smtp.messagingengine.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace8180-5984-0a2a45010019-ca0c7c9f9bc3-3 for ; Tue, 13 Oct 2026 21:07:45 +0200 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id 0E6237A0074 for ; Tue, 13 Oct 2026 15:07:44 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Tue, 13 Oct 2026 15:07:44 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 13 Oct 2026 15:07:41 -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=fm2 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=fm2 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=fm2; t=1791918463; x=1792004863; bh=j+6JrncPQugIRbAHvnMoTmELLkm5bzQJ kwF5sPXA5bg=; b=ahS6WWEH0n70Yt/dYTeGAXMUaHqBdnx8Mwz2p19Wq1JQ6nJ1 Kfs8A4JLzEbxNmnBVYeParset2CkN+da7PY+W6dCKnGl49mtlQPDNnWDKS5+7sXX 2zH4kgZ2RXzOU7aE+TINifv7mA01RdaHWMX+JgZqAiAt1CT67f02vthmvGLYrW62 TaBtJwqFFfpKArY7HGCgQqfraW20+1el4S6x5OhCmXSjDToaspHEaF2xLN8v61+h 4mKD4WRKrVh8yH5NahvJFvmDJxX4iuTEPqec2VSRPvvj+oU5bJLwcILKoFwWyNF7 0h4pt982/wNvv8yQ4QLBnswEgJ3jrqIHlI1JVA== 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= fm2; t=1791918463; x=1792004863; bh=j+6JrncPQugIRbAHvnMoTmELLkm5 bzQJkwF5sPXA5bg=; b=P5LbKjeQjjfBnfkfr5xBWFVBRpCvWZ4qlpAgKfbbDyp8 L51cExA8rTv8mYM+149hdjcseuybqYK6Aw5ubiU9ccAVvXDt/Pya+6BGnWhbTMYK IdhYD20525EiJ0XE5k+N8Yb7NnNwwa3Hz42Yw87d4MzPH6NVt17xJWHH1pyHI6Q6 psMbbCTFZPUKVc6OWDM/zq+W2/EuVZBRfWkOkcxs8KelA09ch8id5kFlyWOR0afo 2y68qFsG3Wy7yVVOdHFFXF48nmjc8wI/i2rkExqth45+skgo2dOEY+EeST+khAul s3VQEWgTODZWFjirsLdXrHQPDQ7+oLXzQ2uF9HGbYg== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=sign d=invisiblethingslab.com a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1791918463; d=invisiblethingslab.com; mf=PG1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20+; rt=PHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZz4=; s=fm2:rsa-sha256:K5Y5/SYygJ46gVOqnDgiy4m3Nx61ZWDIlrq7++sWMIIrDtX cawve0N1eUnbgMRtJG3Dm1xkFKNc2zydQmJNID8TydMa82Bnz/MuL7LtJ0OPGZ41 FJ9uaMMiXGuWPLY0+ddq17tPFr4I0Vd97ewqttUNKSuQXkCOMMDKHawsQsjsVTnZ 2aR9arNZE+HnYBuYHuwGDiaXtd+FJpUv1zsupe0bxUooR8QBMGSeJlL/SxDcSdCC lXa9qkdZSZ6Po00FfSORG44T+JCzVW8Ju3wsGp7CuFsmpYIvD0i50aNWGBRmAL5v Tmb+JXD8raCvcgHG4973XG6X9K+ZpR6qOsgUYmw==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=mi-m=1; hc=10; hn=cc,content-transfer-encoding,content-type,date,feedback-id, from,message-id,mime-version,subject,to; Message-Instance: m=1; h=sha256:73l1Ga0o0c+clrHXa1CkAoNDM/NtGOoKGPETbFU8Z68=:bVE4G8hqzCRTYNdA708j92bGUfnemoEIKiTSYwVgltQ=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGqNqXzjZ+lWuvAX0utJ4EiLSJCWj3QM1sVHAz5MjIqkJEkHoWqKRp6ha2Rr6iGko tdsisdUkikWSKYeB0pvLlJUXo7VPi9znZlR2se2TRtnWXjHxLlToz5AKTY3tdJfdMzP6uh W8uLTUON9+8cTKZoIkFtDAV8NCUkYq/L89dzXBr516nFXcj1MRag5IFTwkzIHAmoNSrcrh JjoLr+qJY6mYTd3RFAbcZNEw9WllWOq+EBWPELEcwJ5dxGzs6xoEZvWHIcke2qu70Sm503 /eIwHiMj/gybIOmBGsrcdW0k2srd99r9aDFVoJmbX2p+buxxhHHPzZBEscoNkAIsoXt6Js y8Sxa+K075D1/iUUK+dx1jsKy8HnsuL7h2r0yUkC5Gx+Cc/ew2qggZ47XH9WBT8Bo9IgTh vUTQTKLEZZNcvXxAB/Ghk4UU+gVX0lzRqP2NZuxJDfSAg3KakpaFnVbljeqJ3D0926XAhE UoBe9mZOv2uj4mK+WdQbDBuDjlDNKOa4v+QXTy+2yZGbN/ttuxY7l6BZHo0SDaZdagOiPE 3uq9g7cWreiKfoPYMkUmA7xVSkr+KfHCP3zmgcpirepAf1Z4taShHEH3BVWJ4lJjt7RcUg cdmBkD0i0eoZ5MyE3hGmm9lqGYa0GsyypPNrMp5oIocScQQTgaFsa5pM15wA X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] drivers/char: Add several newer PCI IDs for Intel LPSS Date: Tue, 13 Oct 2026 21:07:31 +0200 Message-ID: <20261013190735.365024-1-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1791918466-C4558757-F3CCDFF3/0/0 X-purgate-type: clean X-purgate-size: 4986 Include PCI IDs of UART ports on Intel RPL - PTL. Based on Linux driver and hwdata, they all share the same parameters. Signed-off-by: Marek Marczykowski-Górecki --- I tested it on MTL, but given Linux driver handles them uniformly, I assume others work too. The list gets quite long, would it be preferred to have a macro to reduce (at least similar) entries to one-liners? In Linux driver it looks this way: /* MTL-P */ { PCI_VDEVICE(INTEL, 0x7e25), .driver_data = (kernel_ulong_t)&bxt_uart_info }, { PCI_VDEVICE(INTEL, 0x7e26), .driver_data = (kernel_ulong_t)&bxt_uart_info }, ... --- xen/drivers/char/ns16550.c | 132 +++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index cdda28879e66..be388c8e6582 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -1245,6 +1245,138 @@ static const struct ns16550_config __initconst uart_config[] = .dev_id = 0x7adc, .param = param_intel_lpss }, + /* Intel Corp. RPL-S LPSS PCI UART #0 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7a28, + .param = param_intel_lpss + }, + /* Intel Corp. RPL-S LPSS PCI UART #1 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7a29, + .param = param_intel_lpss + }, + /* Intel Corp. RPL-S LPSS PCI UART #2 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7a5c, + .param = param_intel_lpss + }, + /* Intel Corp. LNL-M LPSS PCI UART #0 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xa825, + .param = param_intel_lpss + }, + /* Intel Corp. LNL-M LPSS PCI UART #1 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xa826, + .param = param_intel_lpss + }, + /* Intel Corp. LNL-M LPSS PCI UART #2 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xa852, + .param = param_intel_lpss + }, + /* Intel Corp. MTL-P LPSS PCI UART #0 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7e25, + .param = param_intel_lpss + }, + /* Intel Corp. MTL-P LPSS PCI UART #1 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7e26, + .param = param_intel_lpss + }, + /* Intel Corp. MTL-P LPSS PCI UART #2 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7e52, + .param = param_intel_lpss + }, + /* Intel Corp. MTP-S LPSS PCI UART #0 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7f28, + .param = param_intel_lpss + }, + /* Intel Corp. MTP-S LPSS PCI UART #1 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7f29, + .param = param_intel_lpss + }, + /* Intel Corp. MTP-S LPSS PCI UART #2 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7f5c, + .param = param_intel_lpss + }, + /* Intel Corp. MTP-S LPSS PCI UART #3 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0x7f5d, + .param = param_intel_lpss + }, + /* Intel Corp. NVL-H LPSS PCI UART #0 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xd325, + .param = param_intel_lpss + }, + /* Intel Corp. NVL-H LPSS PCI UART #1 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xd326, + .param = param_intel_lpss + }, + /* Intel Corp. NVL-H LPSS PCI UART #2 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xd352, + .param = param_intel_lpss + }, + /* Intel Corp. PTL-H LPSS PCI UART #0 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xe325, + .param = param_intel_lpss + }, + /* Intel Corp. PTL-H LPSS PCI UART #1 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xe326, + .param = param_intel_lpss + }, + /* Intel Corp. PTL-H LPSS PCI UART #2 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xe352, + .param = param_intel_lpss + }, + /* Intel Corp. PTL-P LPSS PCI UART #0 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xe425, + .param = param_intel_lpss + }, + /* Intel Corp. PTL-P LPSS PCI UART #1 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xe426, + .param = param_intel_lpss + }, + /* Intel Corp. PTL-P LPSS PCI UART #2 */ + { + .vendor_id = PCI_VENDOR_ID_INTEL, + .dev_id = 0xe452, + .param = param_intel_lpss + }, /* WCH CH382 2S1P */ { .vendor_id = PCI_VENDOR_ID_WCHIC, -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 13 20:38:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 20:38:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448289.1664309 (Exim 4.92) (envelope-from ) id 1xGjGD-0003g0-H9; Tue, 13 Oct 2026 20:38:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448289.1664309; Tue, 13 Oct 2026 20:38: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 1xGjGD-0003ft-EV; Tue, 13 Oct 2026 20:38:09 +0000 Received: by outflank-mailman (input) for mailman id 1448289; Tue, 13 Oct 2026 20:38:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGjGB-0003fl-Bk for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 20:38:07 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGjGB-00000003XLE-1vcw for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 20:38:07 +0000 Received: from mail-lf1-f54.google.com ([209.85.167.54]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGjGA-0000000CeAI-30wb for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 20:38:07 +0000 Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5b8b3c8c4bbso387253e87.0 for ; Tue, 13 Oct 2026 13: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" 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=X8jUnhSjU960ugbfAM3avX9djEIDKqR0sPMbSEsat6Y=; b=CL5/r5zEB4PrjoLn1q0+5X8hjz tMrnpMyIwQgde4fkCxp5viiCnXIdO5grMYWCbCZzefeDj3ijVdRoaWWjMexiyr521mBSw3Y7vksag miYn+sMDThivegD4eMb9fk+7ta6LzR910PgbPhKH/jTT1bcL+xYlLHRKI3nwNTmR4VlU=; X-Gm-Message-State: AFq9FYKnmrsrBifioN4wmxnEFbChKNnATbt+BtnSbyl076v796ZN965P pAAT9EJG9rCYW6YZMzMZgYC6z+tnOwx30bHw7o3CURe/eAj6C3oxF6xE2QmIKoYNHd+4l5OgTe1 SNphC2bjR0+RXROpkFPho1UcpwDGVaco= X-Received: by 2002:a05:6512:31d2:b0:5b8:f1d6:554c with SMTP id 2adb3069b0e04-5bcdd4f052emr4081786e87.12.1791923885986; Tue, 13 Oct 2026 13:38:05 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-13-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Tue, 13 Oct 2026 21:37:53 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9ru_Vuw8LnsQeQ4GUTA_2weuQ1ff1Ki5O-2hJNv2qvy07GMM5kT4-sJng Message-ID: Subject: Re: [PATCH v3 12/18] x86/mm: let Xen's page-table walker operate on a given root To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 3:59=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:45AM +0100, George Dunlap wrote: > > map_pages_to_xen() and modify_xen_mappings() maintain Xen's own mapping= s, > > walking from idle_pg_table, whose Xen slots every other root page-table > > copies. A later patch introduces a second directmap hierarchy: page > > tables for the directmap virtual address range that some guest contexts > > use in place of idle_pg_table's. It needs the same maintenance at the > > same virtual addresses. > > I assume that "second directmap hierarchy" refers to the sparse > directmap approach? Yes. Should I change it to "a second, sparse directmap hierarchy"? I think raising that we're going to be maintaining parallel hierarchies is important. > > Give virt_to_xen_l{3,2,1}e() the L4 to walk from, and move the bodies o= f > > map_pages_to_xen() and modify_xen_mappings() into map_pages_in() and > > modify_mappings_in(), which take the root as well. The public function= s > > pass idle_pg_table. The EFI runtime-services page-tables mirror > > idle_pg_table's L4 entries only, so a newly allocated L3 is propagated > > to them only when the root is idle_pg_table. > > > > TLB flushing is unaffected: it is by virtual address, and the same > > addresses are mapped in either hierarchy. > > The virtual address space is just part of it, so far > map_pages_to_xen() has been doing global TLB flushes, because all CPUs > used the same page-tables for the Xen slots that map_pages_to_xen() > modifies. With the change to pass different L4, there's also the > assumption that the Xen slots on those L4 will be different, and hence > not all CPUs might need flushing? > > Maybe I'm thinking ahead too much - but if this is going to be used to > manage the sparse directmap we might want to avoid IPIs to CPUs that > are running with the full directmap when the sparse one is changed, > as those are useless. Yes; changes to both "views" (e.g., map_pages_to_xen()) still need to flush on all CPUs; but changes only to the sparse "view" (e.g., removing pages on free_xenheap_pages()) could send an IPI only to CPUs with the sparse view running on it. We could keep a cpumask with which CPUs currently have sparse directmaps loaded, and only IPI those. That said, maintaining the cpumask isn't free; it would cause some cacheline bouncing as vCPUs are scheduled in and out; and since the idle vCPU has the full directmap, even a system with all "normal" domains using the sparse map would still need to update it constantly. Not sure how often free_xenheap_pages() happens, but if it's not very frequent, it might not be worth the cache consistency overhead (and the extra complication). I'd leave this as a potential future improvement. -George From xen-devel-bounces@lists.xenproject.org Tue Oct 13 20:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 20:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448300.1664318 (Exim 4.92) (envelope-from ) id 1xGjRd-0005eb-Jv; Tue, 13 Oct 2026 20:49:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448300.1664318; Tue, 13 Oct 2026 20: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 1xGjRd-0005eU-Gr; Tue, 13 Oct 2026 20:49:57 +0000 Received: by outflank-mailman (input) for mailman id 1448300; Tue, 13 Oct 2026 20:49:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGjRc-0005eO-UC for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 20:49:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGjRc-001WtP-BG for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:49:56 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace9904-bab6-0a2a0a5309dd-0a2a450b950e-44 for ; Tue, 13 Oct 2026 22:49:56 +0200 Received: from [209.85.128.182] (helo=mail-yw1-f182.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace996e-b7e8-0a2a450b0019-d15580b6a9d1-3 for ; Tue, 13 Oct 2026 22:49:51 +0200 Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-8ae9bc9a2fcso43360157b3.1 for ; Tue, 13 Oct 2026 13:49:50 -0700 (PDT) Received: from StolidWingnut.localdomain ([174.80.170.224]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b07f25141dsm48837417b3.40.2026.10.13.13.49.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2026 13:49: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=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=1791924589; x=1792529389; 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=MXbNAe5TbgxJKCM2vYO3nk3BjSGUJWEFuyRNOjRKIEw=; b=cbtEynWHK0jCzj75NZRlzWWxEGZiqtmRU5k95rtA1FWAC/Pyc5w3kvG8hnU79Adwov qhzqPh1lVWtTlzHJpmRV7HZZPct1V4TB0DHBN1BALuIFP84jk04ycbUKsqsWmIa4kY23 j53ttb+7fn0Tl7IsmHRD52O/DNwI8bUeJ7x1ddgZuD0deuhohx2MnTWaNZSrMyByD0Wk HNLvz9qILWZjVRfQeemsEG/C5e5wtT8Ko1iJX0eMLPQiRh6K6CRRqoSWhcY05E/vO1Gy IwLYCp8xF4r2mjM6W1t9neB2VVjGhYk6I5aZA8bqytmGxymK3JbbaAXqfkU/V1THu7xV 0VJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791924589; x=1792529389; 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=MXbNAe5TbgxJKCM2vYO3nk3BjSGUJWEFuyRNOjRKIEw=; b=bIS9kU4QSYFsVRbpys7jIjrU7XR19QpY5RfbOUWL+Vi6gKbNWLWq75Xr7TIeZL8KAP EBon6hRjUCyn7QIqFFh2Wa4c5uRMPP36gtABhX4253J3HdKPV1kNYWz+lcMSyWKlP8FR Yfv5YbEZpeFBlqq95bWdlYHqDepoEt2C7hOq8R1N8T9/QdpWuLGghPl+mnpHiaHozLRx 8IViijy5Iwlfj9FVjmX73hyPzu1RMmmqiKRU2qnZ6Mfq5tXo9gT9alnCURMXIgAiZam8 5aU7invrttxqDxT9sVi+w3A4H9BFeXCp71jOkWhXEWA3XxP5rnH1Pqfn+3TKvDDX3N+c 7TFw== X-Gm-Message-State: AFq9FYIfUTk8pYA9McOApm5a1vXHBU8rz6JbfVAs40UyLH7UfH2IUMQd 68jnxVlSQ7Uxt2ZWJkCquUiFusl0dE8ib68iqc9+s2KF8I6F9ZXpYv2Q/AVs/blfYS3Y3lQ4Fni 8uQPSWao= X-Gm-Gg: AYBFou0ovsHt+6Akl777IcncIKe+xW/FOtJi1tUYjFzB8mog1AWsF39fxyj7IiSMXcq BoWGVit5pDQ0pqj3/iDfKpQbjyRqUgpQJ7rigNhEEdPd6vzPonp8WEbxulgHeuBoM/GvH+fBpIB 98aX8TjKkw8YTHaXdwDC028gk6e91+trKt4rPP4CuX055UgbUBdOx5cQMMI9AwV6tL+v0Ponypa 3dp/Ik5/rxnVJXp6Kxtbqa7zxGGm2QfU9loa7LBYQ9mTWhZb7gdI0pBMII1dydj5ju7ZrRwpTkV +to09KnvxFNXJhsi32rjehiuvGXPqhGF/CZOFmFpu6p+FaoHWYQQSge52Pdh84MfS/E1xc7YSF5 GJKDP3qu4l9afcVdrPgKH3uKSOPcUrJNjtVY37sn3Czn1OrDO85x+ZpJWzpriKz1ylJTzoiosD0 fvsRQ/yNo2I/w8vEt75F2OHSYCUu7AufT4l5Onmuscs/PIuT+ASUllzxbFjC5AedRqTZsojAGHk ebGrboGxX8oriLxpHk7k6FYwGs= X-Received: by 2002:a05:690c:5886:b0:87f:32fa:aa08 with SMTP id 00721157ae682-8b07ed55c46mr36684497b3.14.1791924589251; Tue, 13 Oct 2026 13:49:49 -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 "auto" to scan PCI only when the default base has no UART Date: Tue, 13 Oct 2026 16:49:46 -0400 Message-ID: <20261013204946.1980090-1-benjamin@edera.io> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261009202447.852414-1-benjamin@edera.io> References: <20261009202447.852414-1-benjamin@edera.io> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1791924596-18AC89EA-FF93D8A0/0/0 X-purgate-type: clean X-purgate-size: 8281 On some systems the console UART is at the legacy I/O port, and on others, such as Amazon EC2 bare metal instances, the only UART is on PCI. "com1=...,pci" finds the PCI UART, but it prefers any PCI serial device to the legacy port, so it is not correct on a system that has both. No option today says "use the legacy port, and scan PCI only if it has no UART". A deployment that boots one command line on many kinds of machine needs exactly that. Add "auto" as a value in the position, and as "dev=auto". With it, Xen probes the default base as usual. Only if check_existence() fails there does it scan PCI, as "pci" does. Without "auto", nothing changes. The decision rests on check_existence(), which until now reported an MMIO base as present without testing it. Make it return -1 for a base that it cannot probe, so that callers can tell "no UART" apart from "not probed". The HAS_IOPORTS=n branch returns -1 too, for the same reason, although it is not reachable today: the function is x86-only, and x86 always selects HAS_IOPORTS. Existing behavior does not change, as -1 is still non-zero, but "auto" now refuses a base that cannot be probed. The decision therefore always comes from the I/O port probe, and with nothing at the port, reads return 0xff and the IER test fails. The scan runs only when the command line asks for it, at the same point in boot as "pci" and "amt". There is no console yet, but the scan is not silent: it logs the device that it picked, and PARSE_ERR() logs a failure. Both messages go to the console ring, and console_init_preirq() replays the ring to each console that comes up, VGA included. Only a hang or a crash inside the scan goes unreported, as with "pci" and "amt" today. To limit what an unexpected scan can touch, "auto" only considers devices that are in uart_config[]. A serial-class device without built-in parameters is skipped before its BARs are sized, so a firmware that misreports the legacy port cannot move com1 to an arbitrary plug-in card. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Benjamin Leggett --- docs/misc/xen-command-line.pandoc | 9 ++++-- xen/drivers/char/ns16550.c | 46 ++++++++++++++++++++++++++++--- 2 files changed, 48 insertions(+), 7 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index a6f08463d1..6fff62800f 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -357,7 +357,7 @@ ACPI indicating none to be there. ### com1 (x86) ### com2 (x86) -> `= [/][,[DPS][,[|pci|amt][,[|msi][,[][,[]]]]]]` +> `= [/][,[DPS][,[|pci|amt|auto][,[|msi][,[][,[]]]]]]` Both option `com1` and `com2` follow the same format. @@ -387,6 +387,9 @@ Both option `com1` and `com2` follow the same format. avoiding Intel AMT devices. * `amt` indicated that Xen should scan the PCI bus for the UART, including Intel AMT devices if present. +* `auto` indicates that Xen should use the default I/O base if a UART + responds there, and otherwise scan the PCI bus for the UART as `pci` + does, but only for devices with built-in parameters in Xen. A typical setup for most situations might be `com1=115200,8n1` @@ -411,9 +414,9 @@ The accepted name keywords for name=value pairs are: * `clock-hz`- accepts large integers to setup UART clock frequencies. Do note - these values are multiplied by 16. * `data-bits` - integer between 5 and 8 -* `dev` - accepted values are `pci` OR `amt`. If this option +* `dev` - accepted values are `pci`, `amt` OR `auto`. If this option is used to specify if the serial device is pci-based. The io_base - cannot be specified when `dev=pci` or `dev=amt` is used. + cannot be specified when `dev=pci`, `dev=amt` or `dev=auto` is used. * `io-base` - accepts integer which specified IO base port for UART registers * `irq` - IRQ number to use * `parity` - accepted values are same as positional parameters diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index cdda28879e..56de4d50fb 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -66,6 +66,7 @@ static struct ns16550 { bool dw_usr_bsy; #ifdef NS16550_PCI /* PCI card parameters. */ + bool pci_fallback; /* if =1, scan PCI if io_base has no UART */ 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; @@ -727,6 +728,7 @@ static int __init parse_parity_char(int c) return 0; } +/* Returns 1 if a UART answers at io_base, 0 if none does, -1 if untestable. */ static int __init check_existence(struct ns16550 *uart) { unsigned char status, scratch, scratch2, scratch3; @@ -737,9 +739,9 @@ static int __init check_existence(struct ns16550 *uart) * if we're getting MMIO UARTs, the arch code knows what it's doing. */ if ( uart->io_base >= 0x10000 ) - return 1; + return -1; #else - return 1; /* Everything is MMIO */ + return -1; /* Everything is MMIO */ #endif pci_serial_early_init(uart); @@ -1321,6 +1323,10 @@ pci_uart_config(struct ns16550 *uart, bool skip_amt, unsigned int idx) } } + /* Keep "auto" off unknown devices, including their BARs. */ + if ( uart->pci_fallback && i == ARRAY_SIZE(uart_config) ) + continue; + if ( port_idx >= param->max_ports ) { idx -= param->max_ports; @@ -1628,6 +1634,11 @@ static bool __init parse_positional(struct ns16550 *uart, char **str) return true; conf += 3; } + else if ( strncmp(conf, "auto", 4) == 0 ) + { + uart->pci_fallback = true; + conf += 4; + } else #endif { @@ -1745,6 +1756,11 @@ static bool __init parse_namevalue_pairs(char *str, struct ns16550 *uart) pci_uart_config(uart, 0, uart - ns16550_com); dev_set = true; } + else if ( strncmp(param_value, "auto", 4) == 0 ) + { + uart->pci_fallback = true; + dev_set = true; + } else PARSE_ERR_RET("Unknown device type %s\n", param_value); break; @@ -1785,6 +1801,7 @@ static void __init ns16550_parse_port_config( { char com_console_options[128]; char *str; + int present; /* No user-specified configuration? */ if ( (conf == NULL) || (*conf == '\0') ) @@ -1818,8 +1835,29 @@ static void __init ns16550_parse_port_config( PARSE_ERR("%d stop bits are unsupported.", uart->stop_bits); 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"); + present = check_existence(uart); +#ifdef CONFIG_HAS_PCI + if ( uart->pci_fallback && present < 0 ) + PARSE_ERR("\"auto\" needs a base that can be probed"); +#endif + if ( !present ) + { +#ifdef CONFIG_HAS_PCI + if ( uart->pci_fallback ) + pci_uart_config(uart, 1 /* skip AMT */, uart - ns16550_com); + + /* + * A failed scan puts back the rejected base, and check_existence() + * can't test an MMIO BAR, so only ->param says that a device was + * found. + */ + if ( uart->pci_fallback && uart->param && check_existence(uart) ) + printk("ns16550: com%zd: no UART at default base, using %pp\n", + uart - ns16550_com + 1, &uart->pci_device); + else +#endif + PARSE_ERR("16550-compatible serial UART not present"); + } /* Register with generic serial driver. */ serial_register_uart(uart - ns16550_com, &ns16550_driver, uart); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:40:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448331.1664354 (Exim 4.92) (envelope-from ) id 1xGlAV-000789-TO; Tue, 13 Oct 2026 22:40:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448331.1664354; Tue, 13 Oct 2026 22: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 1xGlAV-000781-QX; Tue, 13 Oct 2026 22:40:23 +0000 Received: by outflank-mailman (input) for mailman id 1448331; Tue, 13 Oct 2026 22:40:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3U7POagcKCVI2B80yBC08805y.w86Hy7-xyFy552CDC.Hy79B83ywD.8B0@flex--irogers.bounces.google.com>) id 1xGlAU-00075Q-NB for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:40:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlAU-00Egyf-47 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:40:22 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3U7POagcKCVI2B80yBC08805y.w86Hy7-xyFy552CDC.Hy79B83ywD.8B0@flex--irogers.bounces.google.com>) id 6aceb34f-2eae-0a2a0a5409dd-0a2a4508863a-6 for ; Wed, 14 Oct 2026 00:40:22 +0200 Received: from [74.125.82.197] (helo=mail-dy1-f197.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3U7POagcKCVI2B80yBC08805y.w86Hy7-xyFy552CDC.Hy79B83ywD.8B0@flex--irogers.bounces.google.com>) id 6aceb354-f659-0a2a45080019-4a7d52c5e4ef-3 for ; Wed, 14 Oct 2026 00:40:21 +0200 Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-35c5aef2a74so1454375eec.0 for ; Tue, 13 Oct 2026 15:40: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=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=1791931220; x=1792536020; 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=4r3hXDLd6Bqk9XmcFR/JS5uHIdkPs2TN+2FSnsngXIE=; b=v2BCIsZXqZkc3e2l1NKlbMzOHnzFe1G88P7l7HKXL3KDTEeQftWRY3qe63dnfQMD97 Jg3LFGXvaDFAmSWf1GI/+JIA/c9/cm7ozOwD137EUqVCOvTvISFU0CoBaJP1GLe8YVSo 7r3ZMCuJ3GHfoP1CNONqSU8CZCjxoNUfm5wyajEs6W2ZnCQgSWYb0vDKUY7pIvzfNxRw i1NvxKVKSaitlMKY7MjO1ZJoSDLInDEFXMOFzHLOUBbFcw0prtUL3OCcRHvOrzVlvsva +fXeYwQ9DVfg0q+tr5yiv2dHwbcryE5KlZq5LjXaEbIgJR7TDvzXsrihvPKE6jzFInLo 1kkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931220; x=1792536020; 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=4r3hXDLd6Bqk9XmcFR/JS5uHIdkPs2TN+2FSnsngXIE=; b=Y/i6o1SrLfOpWWHkGOgoQgOCwXjHm7bcTd2QRYlniTdiQHsj9/xLnWTg3+5wIAZNbg PLhVaG4rEBA4HqPmlxAniIMdni7Kx3ygUyGZyeuKdYR7KhS3yIAJzbr1C+U3aA5zjyaJ kT6g5RaPOeu9O6MZLM2IRVH1EV9UnSOCw4kTUc4i/zjRQGpECmRGB0wTc2ju168BUV4D dkGKIAgvByI8KHj+qdopKlWr2bVhmanG5Yg1shtHm8D+JKl2JUNxJWm6a5PAzYWesgc1 0BRT+A0kfzjq55dtmM1+1SlYbX/cFZvoHinSqacRTguhIbtUM0XIC0lPRjkNMKhAwtie QPHw== X-Forwarded-Encrypted: i=1; AKwUvBxeIS9i68ku7ymrzMmrGuBp+CKUI5HzMlJZA304zgQDwvsaP0k85VzLWcDkPbZb4X+rjCuX8rd7DtQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYIt5EMTF94E8MI/MsGyk0oWzWv+Y+06mufzFn0cmtFYuClrJBUs 8urQt1TeR/hZ9scQZ7nA/4305DXQpVTswe6gyR3+GPTSAnKbYCmiNK25LdNhQ1Xj5UsoGZa0sb8 63gcFxsgs1g== X-Received: from dyu6.prod.google.com ([2002:a05:693c:8106:b0:352:94e:a8c9]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7301:71a8:b0:358:f717:ff61 with SMTP id 5a478bee46e88-358f717ff90mr13337962eec.6.1791931219210; Tue, 13 Oct 2026 15:40:19 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:38 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-4-irogers@google.com> Subject: [PATCH 03/11] sh: sq: Add missing kobject release callback to ktype_percpu_entry From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c1860d/1791931221-D6D4087B-A52753D5/0/0 X-purgate-type: clean X-purgate-size: 1096 In sq_dev_add(), sq_kobject[cpu] is dynamically allocated with kzalloc_obj() and initialized with ktype_percpu_entry. When sq_dev_remove() calls kobject_put(kobj), the kobject is never freed because ktype_percpu_entry lacks a .release callback. Provide a sq_kobj_release() callback that calls kfree(kobj). Fixes: d7c30c682a27 ("sh: Store Queue API rework.") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- arch/sh/kernel/cpu/sh4/sq.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/sh/kernel/cpu/sh4/sq.c b/arch/sh/kernel/cpu/sh4/sq.c index 908a8e09113b..f33864958487 100644 --- a/arch/sh/kernel/cpu/sh4/sq.c +++ b/arch/sh/kernel/cpu/sh4/sq.c @@ -331,7 +331,13 @@ static const struct sysfs_ops sq_sysfs_ops = { .store = sq_sysfs_store, }; +static void sq_kobj_release(struct kobject *kobj) +{ + kfree(kobj); +} + static struct kobj_type ktype_percpu_entry = { + .release = sq_kobj_release, .sysfs_ops = &sq_sysfs_ops, .default_groups = sq_sysfs_groups, }; -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:40:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448330.1664346 (Exim 4.92) (envelope-from ) id 1xGlAT-0006uV-Nn; Tue, 13 Oct 2026 22:40:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448330.1664346; Tue, 13 Oct 2026 22:40: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 1xGlAT-0006uN-Je; Tue, 13 Oct 2026 22:40:21 +0000 Received: by outflank-mailman (input) for mailman id 1448330; Tue, 13 Oct 2026 22:40:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3ULPOagcKCU8z85xv89x55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--irogers.bounces.google.com>) id 1xGlAS-0006ok-1k for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:40:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlAR-00Eh2E-F4 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:40:19 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3ULPOagcKCU8z85xv89x55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--irogers.bounces.google.com>) id 6aceb34b-e002-0a2a0a5209dd-0a2a4504ec56-10 for ; Wed, 14 Oct 2026 00:40:19 +0200 Received: from [74.125.82.198] (helo=mail-dy1-f198.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3ULPOagcKCU8z85xv89x55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--irogers.bounces.google.com>) id 6aceb351-b57f-0a2a45040019-4a7d52c6ad83-3 for ; Wed, 14 Oct 2026 00:40:19 +0200 Received: by mail-dy1-f198.google.com with SMTP id 5a478bee46e88-3552883bd19so4648261eec.1 for ; Tue, 13 Oct 2026 15:40: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: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=1791931217; x=1792536017; 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=qdtOvNbLAOJ9idJnmqNXkxs2lXj3bNW1pL8KRmE6mUU=; b=Wz7acxh6o+z2wyEmHNrLoz1mE/INm8whAF5mARrCcpSvDitm7A7TieK924Ma7cMQ13 BIY+hAorqX28OlYgJRIz7Os40GccznSYbtPOFQTLW0HJagD5OQn4taaM/kiN43kCx+oS VWv8yge+Fzt0fk2BKeg6z/tq2okunylh1pOOUWN6NcjBsAu1yxiurSUL+pgviWmITXtQ LbInEW4s9pSLjFVIrA6qrB1eRrcMQWAeDCWk1V1jFuaIEPeZQbD62vhqYj57tPZxA2u/ bF0lo5ZoEEWUz4QD05gASUo9xkr7gPc0MO+CpaVbKkLmnjFzMmKC4LsGdc++lAbsNdZH eVuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931217; x=1792536017; 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=qdtOvNbLAOJ9idJnmqNXkxs2lXj3bNW1pL8KRmE6mUU=; b=M4zO9ayC0adcdQUH32AseCsdHLvbwMQjDEA3bsVnF5FwGKIewGdp3aOQ4TKPMc3S1m 94wn8H0YisQEg6AwuGUkOQ8eexLDWuHBPitpLFgGOGcaMQAgg8D0Vc1jxdd8xHJZSb3X d0Sz8upIMpvmnh5rtWEH6bFr0P9slH8JCjFcfmuFqxwBDozDXMJImiu5+05H3Pev5DJU KjnlqXmVSoNtIu5flfL5pCd/fBvm/F9fXmYYcsLjQDj25y+8PVbFTnCiMdkPZBV1GY/b /ZiBCcfqZiJn2Kp38lp95hLObYaNxUdO/90GBOcNTpHYIBcxUw0HhbKzpf2SvaAVLxxK ZO/A== X-Forwarded-Encrypted: i=1; AKwUvBzIbaBBe5ChsCkaLEom4BXs57CQGGT2bQudqsrtLNyfHmOFKmRrFf/N8zH9r5D4QYYEYscXCS9R47I=@lists.xenproject.org X-Gm-Message-State: AFq9FYJXAI6wOOAmVTcrkvwfJZpIY5PL3P3ntX6C12falr0H3dC8ujxh AYoXoE20Ll7Z3pEhn1KR7DWKg3yPDyGJxSTJeHM3KHQB7eRnP58NTZvPLU1/r/NIu+lU5u9w/D/ eJhJ0EsHm7g== X-Received: from dycrm16.prod.google.com ([2002:a05:693c:2a10:b0:358:f250:485f]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:693c:4141:20b0:35c:8d1f:5634 with SMTP id 5a478bee46e88-35c8d1f58e8mr4713972eec.12.1791931216820; Tue, 13 Oct 2026 15:40:16 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:37 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-3-irogers@google.com> Subject: [PATCH 02/11] powerpc/secvar: Add missing kobject release callback to secvar_ktype From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1791931219-C10DDB50-FCBCE6D1/0/0 X-purgate-type: clean X-purgate-size: 1324 In add_var(), a struct kobject is dynamically allocated with kzalloc_obj() and initialized with secvar_ktype. If kobject_add() or sysfs_create_file() fails, kobject_put(kobj) is called to clean up. However, secvar_ktype does not define a .release callback, which results in a memory leak of kobj (and a pr_debug warning in kobject_cleanup() when CONFIG_DEBUG_KOBJECT_RELEASE is enabled). Provide a secvar_release() callback that calls kfree(kobj). Fixes: bd5d9c743d38 ("powerpc: expose secure variables to userspace via sysfs") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- arch/powerpc/kernel/secvar-sysfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/kernel/secvar-sysfs.c b/arch/powerpc/kernel/secvar-sysfs.c index 395399bbab2c..f3f6ac25ea78 100644 --- a/arch/powerpc/kernel/secvar-sysfs.c +++ b/arch/powerpc/kernel/secvar-sysfs.c @@ -126,7 +126,13 @@ static const struct attribute_group secvar_attr_group = { }; __ATTRIBUTE_GROUPS(secvar_attr); +static void secvar_release(struct kobject *kobj) +{ + kfree(kobj); +} + static const struct kobj_type secvar_ktype = { + .release = secvar_release, .sysfs_ops = &kobj_sysfs_ops, .default_groups = secvar_attr_groups, }; -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:40:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448328.1664328 (Exim 4.92) (envelope-from ) id 1xGlAQ-0006V7-5S; Tue, 13 Oct 2026 22:40:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448328.1664328; Tue, 13 Oct 2026 22:40: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 1xGlAQ-0006V0-2c; Tue, 13 Oct 2026 22:40:18 +0000 Received: by outflank-mailman (input) for mailman id 1448328; Tue, 13 Oct 2026 22:40:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3TLPOagcKCUsv41tr45t11tyr.p1zAr0-qr8ryyv565.Ar0241wrp6.14t@flex--irogers.bounces.google.com>) id 1xGlAO-0006Ut-9o for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:40:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlAN-003MCl-Je for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:40:15 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3TLPOagcKCUsv41tr45t11tyr.p1zAr0-qr8ryyv565.Ar0241wrp6.14t@flex--irogers.bounces.google.com>) id 6aceb32c-8faa-0a2a0a5109dd-0a2a45028124-14 for ; Wed, 14 Oct 2026 00:40:15 +0200 Received: from [74.125.82.198] (helo=mail-dy1-f198.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3TLPOagcKCUsv41tr45t11tyr.p1zAr0-qr8ryyv565.Ar0241wrp6.14t@flex--irogers.bounces.google.com>) id 6aceb34e-6ca4-0a2a45020019-4a7d52c6bc56-3 for ; Wed, 14 Oct 2026 00:40:15 +0200 Received: by mail-dy1-f198.google.com with SMTP id 5a478bee46e88-30bcb065bfdso6715948eec.0 for ; Tue, 13 Oct 2026 15:40: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=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:Mime-Version:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1791931213; x=1792536013; darn=lists.xenproject.org; h=content-type:cc:to:from:subject:message-id:mime-version:date:from :to:cc:subject:date:message-id:reply-to:content-type; bh=6CWZGGdh7JOQ6UqV1gxmMbPkjK0LPv1nbOU26QpmZ10=; b=C8fvNosO2IgQu0e5orrRxXymtHE8QjkmVwVLKfu8B9YcnJIKvbSwDqEMUkprtpea38 8MeSNUha/jNCh1Nx1KL9tHdJSF+r/cGgSlNaO0mcD8FaT3h7r40Qps23jJDtUNZKNgsA hqIn6rgSmAiUjov0hk3uiOoP+4Q0nap72DpjSk1eaywNTKgDhFX1wdGqOtF/NaAkryUw 5yEQGxASURBK9EcCzNQnTC6+38RbZ4SE8GxMtnJ1OpGwLaCjlJwMzBUlKwyPHlVHU5u1 P/RYDh253vNgtweiZE+r2CjdzIZ5q5DH3YRo9PLLVg8RhXTogXN26AXheW2Jz16n8BUg uHKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931213; x=1792536013; h=content-type:cc:to:from:subject:message-id:mime-version:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6CWZGGdh7JOQ6UqV1gxmMbPkjK0LPv1nbOU26QpmZ10=; b=sqqEHPRSNvKrGaDp1wMaUp1VbFaWW1sabcVtnI5E9so8qwVPcV/FG717nJkn2kFYsz eBhO7B/N5wi2iucq+Mh7eNOrN2+mnIoKsEy+RuRoENDJbAKLk7B9XqvvEwZEaxVQ/qwE 9Horv/ZT9L5x9tKogbAZ02babd643Zq9qFF9InLyXAJvakfE20+MRBxd9LbXiiURQw3U EkHc2a0X+g6CnQx1o0EhINkPbW6pD3uEzhmSDV2vljV4/zL2wBwKReuUvdpkPH85dat0 7Dgy+7dEwrFcChVjw2nMq0zf+qs5LceDmSLxlcV/PewqPHb4NjEmuGzBnzXmZxVu40ZV +RYg== X-Forwarded-Encrypted: i=1; AKwUvByl1B22Cr9P8ynjzo1yJF0HnymSxwIEMk7fNnRj83fB3iqaoLU5uUahO4R67RpQH7sR0il++HxKqHA=@lists.xenproject.org X-Gm-Message-State: AFq9FYIngwcylbWZo5OPtq3qREN4yy1Cj5K74WdpjFA+aDvhD5b3uiW/ b2mhqQiupifo42+lGIt4vuOXzlDxuT8lfta83b+wXkekIp/mK3grWT+FjLOo0flkG4kQtjnqh7P 3Votuy1VXyA== X-Received: from dlak14.prod.google.com ([2002:a05:701b:290e:b0:14e:f9ab:6f83]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:701b:2309:b0:153:7a27:b89 with SMTP id a92af1059eb24-16a5ed4008cmr22709999c88.21.1791931212336; Tue, 13 Oct 2026 15:40:12 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:35 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-1-irogers@google.com> Subject: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-720697/1791931215-30DC12AC-E5852568/0/0 X-purgate-type: clean X-purgate-size: 4246 Clang supports the 'require_explicit_initialization' attribute on struct fields to enforce that the field is explicitly initialized when an aggregate object is constructed, emitting -Wuninitialized-explicit-init (enabled by default) if the field is omitted. Following discussion at the Linux Plumbers Conference [1], this series introduces __require_explicit_initialization in include/linux/compiler_attributes.h and applies it to struct kobj_type::release. As Documentation/core-api/kobject.rst notes: "One important point cannot be overstated: every kobject must have a release() method, and the kobject must persist (in a consistent state) until that method is called. If these constraints are not met, the code is flawed." Annotating struct kobj_type::release caught 30 struct kobj_type definitions across the tree that omitted .release: - Patches 2-10 fix 10 struct kobj_type definitions where dynamically allocated kobjects, ksets, or enclosing structures were either leaked on kobject_put() or freed prematurely before kobject release (risking a use-after-free when CONFIG_DEBUG_KOBJECT_RELEASE=y). - Patch 11 annotates struct kobj_type::release with __require_explicit_initialization and explicitly sets .release = NULL (with explanatory comments) on the remaining legacy struct kobj_type definitions whose kobjects are static, per-CPU, or embedded in devm- or parent-managed structures. [1] https://lpc.events/event/20/contributions/2392/ Ian Rogers (11): Compiler Attributes: Add __require_explicit_initialization macro powerpc/secvar: Add missing kobject release callback to secvar_ktype sh: sq: Add missing kobject release callback to ktype_percpu_entry cpufreq: Initialize kobj_type release callback in ondemand and conservative governors ACPI: CPPC: Free cpc_desc in kobject release callback dlm: Free dlm_ls in kobject release callback xen/sys-hypervisor: Add release callback to hyp_sysfs_kobj_type s390/sclp_mem: Allocate struct sclp_mem dynamically and add kobject release ubifs: sysfs: Use kset_create_and_add() for ubifs_kset drm/amdkfd: Free queue in procfs_queue_type kobject release callback kobject: Require explicit initialization of struct kobj_type::release Documentation/conf.py | 1 + arch/arm64/kernel/cpuinfo.c | 2 + arch/powerpc/kernel/secvar-sysfs.c | 6 ++ arch/sh/kernel/cpu/sh4/sq.c | 6 ++ drivers/acpi/cppc_acpi.c | 39 +++++----- drivers/acpi/sysfs.c | 2 + drivers/cpufreq/cpufreq_conservative.c | 5 +- drivers/cpufreq/cpufreq_governor.c | 3 +- drivers/cpufreq/cpufreq_governor.h | 1 + drivers/cpufreq/cpufreq_ondemand.c | 5 +- drivers/dma/ioat/sysfs.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c | 4 + drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 ++- drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 5 +- drivers/infiniband/hw/hfi1/sysfs.c | 2 + drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 2 + drivers/parisc/pdc_stable.c | 2 + drivers/power/supply/ab8500_fg.c | 2 + drivers/s390/char/sclp_mem.c | 73 +++++++++---------- drivers/soc/hisilicon/kunpeng_hccs.c | 6 ++ .../fbdev/omap2/omapfb/dss/display-sysfs.c | 2 + .../fbdev/omap2/omapfb/dss/manager-sysfs.c | 2 + .../fbdev/omap2/omapfb/dss/overlay-sysfs.c | 2 + drivers/xen/sys-hypervisor.c | 6 ++ fs/dlm/lockspace.c | 19 +++-- fs/erofs/sysfs.c | 4 + fs/f2fs/sysfs.c | 6 ++ fs/ocfs2/cluster/masklog.c | 2 + fs/ubifs/sysfs.c | 24 ++---- include/linux/compiler_attributes.h | 11 +++ include/linux/kobject.h | 2 +- scripts/checkpatch.pl | 1 + tools/lib/python/kdoc/xforms_lists.py | 1 + 33 files changed, 170 insertions(+), 90 deletions(-) -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:40:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:40:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448329.1664338 (Exim 4.92) (envelope-from ) id 1xGlAR-0006hV-CD; Tue, 13 Oct 2026 22:40:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448329.1664338; Tue, 13 Oct 2026 22: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 1xGlAR-0006hM-8n; Tue, 13 Oct 2026 22:40:19 +0000 Received: by outflank-mailman (input) for mailman id 1448329; Tue, 13 Oct 2026 22:40:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3TrPOagcKCU0x63vt67v33v0t.r31Ct2-stAt00x787.Ct2463ytr8.36v@flex--irogers.bounces.google.com>) id 1xGlAQ-0006Uz-7S for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:40:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlAP-00Eh2E-Ka for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:40:17 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3TrPOagcKCU0x63vt67v33v0t.r31Ct2-stAt00x787.Ct2463ytr8.36v@flex--irogers.bounces.google.com>) id 6aceb32a-e002-0a2a0a5209dd-0a2a450aad78-28 for ; Wed, 14 Oct 2026 00:40:17 +0200 Received: from [74.125.82.72] (helo=mail-dl1-f72.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3TrPOagcKCU0x63vt67v33v0t.r31Ct2-stAt00x787.Ct2463ytr8.36v@flex--irogers.bounces.google.com>) id 6aceb350-f2d2-0a2a450a0019-4a7d5248c5d5-3 for ; Wed, 14 Oct 2026 00:40:17 +0200 Received: by mail-dl1-f72.google.com with SMTP id a92af1059eb24-149e8e8ad71so3594487c88.1 for ; Tue, 13 Oct 2026 15:40: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=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=1791931215; x=1792536015; 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=zS2ZTWNtYHltA9QytinDsw+p3+JtthDKSkNq3q9AYXg=; b=SfPMoWpAKToL5KgIcxm2RTKYwGmMW0vvpqEas6+GdoYFynDMW93aakJnFPrnroA6lR 3E+fQc0SJuX69NrNuTjUoIjKy2maySYE5uDzBTXkn/LOsd872FsSd1i8+a8cG1KY5JoF tYRrm42wPSPnRGqyL+6vyQkZ/ASlMG2RFX4/m/wA91Abqsm8FZMoKm3bB8rA3lxd9XTj Njg9V/sukCQZUh8d4lD11Q00d+xihuG4G4zLaU41TxLNEGzvuTGY4fKFJEbpgoqY++pE lqZOToNhYqS+EgRz0ftf+4cbGV8V++dFMjPFzcU4L8g82mgJluDzsgjynGv7y5dw3bOh v5rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931215; x=1792536015; 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=zS2ZTWNtYHltA9QytinDsw+p3+JtthDKSkNq3q9AYXg=; b=i8MsDqL9nH20jlGJnwSR4qOFXXW9zUPHEnmGfgD4plLeJW1ltC7Kl0y+xKFKtUUohK 0QwttXDIB4Fx2MlICXag/2fgpzw2sDUJtbHtvaai1nFVriNNwA+E5RbeMoB4FUgTSLG5 pEexI2huT5hpDQRsg5YD6ygzahI0bDT3XOwfLAEa/nLUCRKHE9OIWkB7BcqXNYElD+WB Ay0ldmi3zpZ7W3uKLJ9TTY+TWwAI6d+9oUH/d6M8v5MDIgfRaKXLa7ZbXiIfQ9T96SNG ZutvbObK6ENQEIlSyVuE8qmIi8PYnUnJzNUs4w28WO5fIadouS183DayDQ4lcEhGk2eP 3bSA== X-Forwarded-Encrypted: i=1; AKwUvBwGZCgKNC0kp+b8S1nkxGffhWNbEzyYd42AvqQ0FZmRz7SiHTaCA+s1AS89n0ovEvH3d49IA8UhAqU=@lists.xenproject.org X-Gm-Message-State: AFq9FYJTLDI14SXx6wMXesQJtLAsb2rR5SPby/0NZ2NJEbYctAZR7nRJ cDzPU8NsYu/gXGuB2kxQo1fjkMC7nx5shkkmWQwM7qThih6Q8DPpL21bnl4K58AuihAHoPei8ig wb/BiTqEebw== X-Received: from dlbvs3.prod.google.com ([2002:a05:7022:3f03:b0:16a:e18b:92ba]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:701b:4553:20b0:166:9e0d:3b56 with SMTP id a92af1059eb24-16a6384d0c8mr17137930c88.38.1791931214565; Tue, 13 Oct 2026 15:40:14 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:36 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-2-irogers@google.com> Subject: [PATCH 01/11] Compiler Attributes: Add __require_explicit_initialization macro From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-4011c0/1791931217-518C5CFC-AA7675FC/0/0 X-purgate-type: clean X-purgate-size: 3637 Clang supports the 'require_explicit_initialization' attribute on struct fields to indicate that a field must be initialized explicitly by the user when the object is constructed. When an aggregate initializer or uninitialized variable omits an annotated field, Clang emits a -Wuninitialized-explicit-init warning (enabled by default). Add the __require_explicit_initialization macro to include/linux/compiler_attributes.h (which is included by include/linux/compiler_types.h and include/linux/compiler.h) so kernel structs with error-prone initialization (such as mandatory callbacks or cleanup handlers) can enforce explicit initialization at compile time, as discussed at the Linux Plumbers Conference. Also teach Sphinx (Documentation/conf.py), kernel-doc (tools/lib/python/kdoc/xforms_lists.py), and checkpatch.pl about the new attribute macro. Link: https://lpc.events/event/20/contributions/2392/ Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- Documentation/conf.py | 1 + include/linux/compiler_attributes.h | 11 +++++++++++ scripts/checkpatch.pl | 1 + tools/lib/python/kdoc/xforms_lists.py | 1 + 4 files changed, 14 insertions(+) diff --git a/Documentation/conf.py b/Documentation/conf.py index 5ab26ce89daf..3e5cb9ca0970 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -203,6 +203,7 @@ c_id_attributes = [ "__noreturn", "__packed", "__pure", + "__require_explicit_initialization", "__section", "__always_unused", "__maybe_unused", diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h index 476c4c560d17..60522ab80c5a 100644 --- a/include/linux/compiler_attributes.h +++ b/include/linux/compiler_attributes.h @@ -322,6 +322,17 @@ */ #define __pure __attribute__((__pure__)) +/* + * Optional: not supported by gcc + * + * clang: https://clang.llvm.org/docs/AttributeReference.html#require-explicit-initialization + */ +#if __has_attribute(__require_explicit_initialization__) +# define __require_explicit_initialization __attribute__((__require_explicit_initialization__)) +#else +# define __require_explicit_initialization +#endif + /* * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-section-function-attribute * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-section-variable-attribute diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 8a7787d228a6..4a3ae6b0100a 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -6871,6 +6871,7 @@ sub process { "noreturn" => "__noreturn", "packed" => "__packed", "pure" => "__pure", + "require_explicit_initialization" => "__require_explicit_initialization", "section" => "__section", "used" => "__used", "weak" => "__weak" diff --git a/tools/lib/python/kdoc/xforms_lists.py b/tools/lib/python/kdoc/xforms_lists.py index e3dda2fe8a53..32066fbbe763 100644 --- a/tools/lib/python/kdoc/xforms_lists.py +++ b/tools/lib/python/kdoc/xforms_lists.py @@ -36,6 +36,7 @@ class CTransforms: (CMatch("CRYPTO_MINALIGN_ATTR"), ""), (CMatch("__private"), ""), (CMatch("__rcu"), ""), + (CMatch("__require_explicit_initialization"), ""), (CMatch("____cacheline_aligned_in_smp"), ""), (CMatch("____cacheline_aligned"), ""), (CMatch("__cacheline_group_(?:begin|end)"), ""), -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:40:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:40:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448336.1664364 (Exim 4.92) (envelope-from ) id 1xGlAh-0007Xm-4K; Tue, 13 Oct 2026 22:40:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448336.1664364; Tue, 13 Oct 2026 22:40: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 1xGlAh-0007Xb-19; Tue, 13 Oct 2026 22:40:35 +0000 Received: by outflank-mailman (input) for mailman id 1448336; Tue, 13 Oct 2026 22:40:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3XrPOagcKCV0DMJB9MNBJJBG9.7JHS9I-89Q9GGDNON.S9IKMJE97O.JMB@flex--irogers.bounces.google.com>) id 1xGlAg-0007WY-71 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:40:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlAf-00Eh2E-KD for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:40:33 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3XrPOagcKCV0DMJB9MNBJJBG9.7JHS9I-89Q9GGDNON.S9IKMJE97O.JMB@flex--irogers.bounces.google.com>) id 6aceb35a-e002-0a2a0a5209dd-0a2a450bd1da-10 for ; Wed, 14 Oct 2026 00:40:33 +0200 Received: from [74.125.82.200] (helo=mail-dy1-f200.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3XrPOagcKCV0DMJB9MNBJJBG9.7JHS9I-89Q9GGDNON.S9IKMJE97O.JMB@flex--irogers.bounces.google.com>) id 6aceb360-b7e8-0a2a450b0019-4a7d52c8bdd3-3 for ; Wed, 14 Oct 2026 00:40:33 +0200 Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-33c35f5ca6cso7840779eec.1 for ; Tue, 13 Oct 2026 15:40: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=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=1791931231; x=1792536031; 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=E3db36lwsPWQArDIHzP6eqDHTacNJpd6D0FMiQjZlVc=; b=kB3ric9bZZKCJLDWJEBGQf40QadbfDOVFWIFp5iKE4kkW8ly1Aq0nfu+FYraj8H/La hpUjkR+UutJ0CXsCHpY9nEgBbrWpcSZZPlb3pNwzebf4I7bwQLMVR+WPbNj1J2nCFF2M GmiSC/y88xDFEZjWXcgbXzaguAWe1kbBGUxWKnlTnUzNk0plOr8WnUYFN1+52ei7lMrD 39RXacg4MorsGHWO1eV4eX9HrXeK2CUxl69goX44xTSmBHJRRj8UFTWLLAH/agaPAxFf 6RKOfCUakn169RZQb5KYm+SsioJIcgHepjDdviDWTuAUiFpZ4jNc3Xlm6Jrf0bMjYAop lGfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931231; x=1792536031; 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=E3db36lwsPWQArDIHzP6eqDHTacNJpd6D0FMiQjZlVc=; b=Vg7ORvOB6aIzR2UrqO3uEfYmfn5a2KHgQCdO+uVWC5aALdF1x9Eev9dTHAFEBMyi3o wZdryshXnPEAiT4mRePM5d3eFNeG8kPYgPrEgniGJLS2GA5W37MUKe9ojRgnwcLtSigW T8t869MwEJmtZQ1Ca2Tn9viH42f8hlpRqU+bjBiMgN1a7D4erLIZ+GbLO2RNPxLlN5AV cHPt8+9jwApjWKRR0eeNzstbjIu4ftvbHBq31TmJVgbjZDewBD+ewltxj26ooZOuBCCT TpXbvQcw3XBkLT682hFjgPuED/S/KE/tJ3XZrdQnBOX4w4HN7cYZ6jCZrWkJq95T9qNR BbxQ== X-Forwarded-Encrypted: i=1; AKwUvBzHEAt94h9uMqtwHL4Dj/KMS+6aPr9DgeSP6GsA7r837xKiYj53inVktvqtskIk2QyunBNBGz+v7uc=@lists.xenproject.org X-Gm-Message-State: AFq9FYJELABkKD8wGLbXDqi2rdSt7s0I+xOP8W4sW3zGJK0cCPGG/ip8 JQ6Ja533injx+3UUVNpzIee50B4tRHAuNNXSSQXiUulY1i5CFTRhYuRbyY3HMjrs0eUZ9tq4lfQ 7z8JUnvl25w== X-Received: from dybmd37.prod.google.com ([2002:a05:7301:1825:b0:351:1da6:c2e7]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7301:78cb:b0:351:515b:4e85 with SMTP id 5a478bee46e88-3537e088bd7mr19706222eec.16.1791931230851; Tue, 13 Oct 2026 15:40:30 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:43 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-9-irogers@google.com> Subject: [PATCH 08/11] s390/sclp_mem: Allocate struct sclp_mem dynamically and add kobject release From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-42698a/1791931233-184CB9EA-E98CBEF7/0/0 X-purgate-type: clean X-purgate-size: 5639 sclp_init_mem() allocated a single array of struct sclp_mem with kzalloc_objs() and registered each embedded kobject using a kobj_type without a .release callback. Allocate each struct sclp_mem individually with kzalloc_obj() instead and add sclp_mem_release() to free it. Fixes: ff18dcb19aab ("s390/sclp: Add support for dynamic (de)configuration of memory") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- drivers/s390/char/sclp_mem.c | 73 +++++++++++++++++------------------- 1 file changed, 34 insertions(+), 39 deletions(-) diff --git a/drivers/s390/char/sclp_mem.c b/drivers/s390/char/sclp_mem.c index 6df1926d4c62..f7c161e0d836 100644 --- a/drivers/s390/char/sclp_mem.c +++ b/drivers/s390/char/sclp_mem.c @@ -49,11 +49,6 @@ struct sclp_mem { #endif }; -struct sclp_mem_arg { - struct sclp_mem *sclp_mems; - struct kset *kset; -}; - struct assign_storage_sccb { struct sccb_header header; u16 rn; @@ -304,7 +299,15 @@ static ssize_t sclp_memmap_on_memory_store(struct kobject *kobj, struct kobj_att return rc ? rc : count; } +static void sclp_mem_release(struct kobject *kobj) +{ + struct sclp_mem *sclp_mem = container_of(kobj, struct sclp_mem, kobj); + + kfree(sclp_mem); +} + static const struct kobj_type ktype = { + .release = sclp_mem_release, .sysfs_ops = &kobj_sysfs_ops, }; @@ -321,36 +324,40 @@ static struct attribute_group sclp_mem_attr_group = { .attrs = sclp_mem_attrs, }; -static int sclp_create_mem(struct sclp_mem *sclp_mem, struct kset *kset, - unsigned int id, bool config, bool memmap_on_memory) +static int sclp_create_mem(struct kset *kset, unsigned int id, bool config, + bool memmap_on_memory) { + struct sclp_mem *sclp_mem; int rc; + sclp_mem = kzalloc_obj(*sclp_mem); + if (!sclp_mem) + return -ENOMEM; sclp_mem->memmap_on_memory = memmap_on_memory; sclp_mem->config = config; #ifdef CONFIG_KASAN sclp_mem->early_shadow_mapped = config; #endif sclp_mem->id = id; - kobject_init(&sclp_mem->kobj, &ktype); - rc = kobject_add(&sclp_mem->kobj, &kset->kobj, "memory%d", id); - if (rc) + rc = kobject_init_and_add(&sclp_mem->kobj, &ktype, &kset->kobj, + "memory%d", id); + if (rc) { + kobject_put(&sclp_mem->kobj); return rc; - return sysfs_create_group(&sclp_mem->kobj, &sclp_mem_attr_group); + } + rc = sysfs_create_group(&sclp_mem->kobj, &sclp_mem_attr_group); + if (rc) { + kobject_put(&sclp_mem->kobj); + return rc; + } + return 0; } static int sclp_create_configured_mem(struct memory_block *mem, void *argument) { - struct sclp_mem *sclp_mems; - struct sclp_mem_arg *arg; - struct kset *kset; - unsigned int id; + struct kset *kset = argument; - id = mem->dev.id; - arg = (struct sclp_mem_arg *)argument; - sclp_mems = arg->sclp_mems; - kset = arg->kset; - return sclp_create_mem(&sclp_mems[id], kset, id, true, false); + return sclp_create_mem(kset, mem->dev.id, true, false); } static void __init align_to_block_size(unsigned long *start, @@ -368,8 +375,7 @@ static void __init align_to_block_size(unsigned long *start, *size = size_align; } -static int __init sclp_create_standby_mems_merged(struct sclp_mem *sclp_mems, - struct kset *kset, u16 rn) +static int __init sclp_create_standby_mems_merged(struct kset *kset, u16 rn) { unsigned long start, size, addr, block_size; static u16 first_rn, num; @@ -394,7 +400,7 @@ static int __init sclp_create_standby_mems_merged(struct sclp_mem *sclp_mems, goto skip_add; for (addr = start; addr < start + size; addr += block_size) { id = addr / block_size; - rc = sclp_create_mem(&sclp_mems[id], kset, id, false, + rc = sclp_create_mem(kset, id, false, mhp_supports_memmap_on_memory()); if (rc) break; @@ -405,45 +411,34 @@ static int __init sclp_create_standby_mems_merged(struct sclp_mem *sclp_mems, return rc; } -static int __init sclp_create_standby_mems(struct sclp_mem *sclp_mems, struct kset *kset) +static int __init sclp_create_standby_mems(struct kset *kset) { struct memory_increment *incr; int rc = 0; list_for_each_entry(incr, &sclp_mem_list, list) { if (incr->standby) - rc = sclp_create_standby_mems_merged(sclp_mems, kset, incr->rn); + rc = sclp_create_standby_mems_merged(kset, incr->rn); if (rc) return rc; } - return sclp_create_standby_mems_merged(sclp_mems, kset, 0); + return sclp_create_standby_mems_merged(kset, 0); } static int __init sclp_init_mem(void) { - const unsigned long block_size = memory_block_size_bytes(); - unsigned int max_sclp_mems; - struct sclp_mem *sclp_mems; - struct sclp_mem_arg arg; struct kset *kset; int rc; - max_sclp_mems = roundup(sclp.rnmax * sclp.rzm, block_size) / block_size; - /* Allocate memory for all blocks ahead of time. */ - sclp_mems = kzalloc_objs(struct sclp_mem, max_sclp_mems); - if (!sclp_mems) - return -ENOMEM; kset = kset_create_and_add("memory", NULL, firmware_kobj); if (!kset) return -ENOMEM; /* Initial memory is in the "configured" state already. */ - arg.sclp_mems = sclp_mems; - arg.kset = kset; - rc = for_each_memory_block(&arg, sclp_create_configured_mem); + rc = for_each_memory_block(kset, sclp_create_configured_mem); if (rc) return rc; /* Standby memory is "deconfigured". */ - return sclp_create_standby_mems(sclp_mems, kset); + return sclp_create_standby_mems(kset); } static void __init insert_increment(u16 rn, int standby, int assigned) -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:40:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:40:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448337.1664372 (Exim 4.92) (envelope-from ) id 1xGlAm-0007tN-AS; Tue, 13 Oct 2026 22:40:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448337.1664372; Tue, 13 Oct 2026 22: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 1xGlAm-0007tG-7i; Tue, 13 Oct 2026 22:40:40 +0000 Received: by outflank-mailman (input) for mailman id 1448337; Tue, 13 Oct 2026 22:40:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3Y7POagcKCWIIROGERSGOOGLE.COMXEN-DEVELLISTS.XENPROJECT.ORG@flex--irogers.bounces.google.com>) id 1xGlAk-0007pR-SP for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:40:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlAk-009GuA-2U for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:40:38 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3Y7POagcKCWIIROGERSGOOGLE.COMXEN-DEVELLISTS.XENPROJECT.ORG@flex--irogers.bounces.google.com>) id 6aceb34e-8faa-0a2a0a5109dd-0a2a4509c84a-12 for ; Wed, 14 Oct 2026 00:40:38 +0200 Received: from [74.125.82.70] (helo=mail-dl1-f70.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3Y7POagcKCWIIROGERSGOOGLE.COMXEN-DEVELLISTS.XENPROJECT.ORG@flex--irogers.bounces.google.com>) id 6aceb364-be1a-0a2a45090019-4a7d5246c420-3 for ; Wed, 14 Oct 2026 00:40:37 +0200 Received: by mail-dl1-f70.google.com with SMTP id a92af1059eb24-1663fb7e005so4564876c88.0 for ; Tue, 13 Oct 2026 15:40: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=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=1791931236; x=1792536036; 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=5eLIAAx2L+9DvCRKYW0jDBbtdiyv3jUNIhafttj/B0g=; b=WVfjU86RK8GWjB2A/gzsaiso4A+6/lpvBTmjDqf9xL/Jo1Yf3xtV1qdwwC16D9v95N 3WBf9pGGAKr1f15dS/OGqx2D6FAVDTUepiAW3o+S8VLIobLDnQ3YOK8GOPBCQokSnGEM aKkvHoiznv9cioAXQAhNyZMMevlFPSH9wctxnJCq4LCeM5nSPHLYd5K6CZVDxwk59NeR eXxNhJ8t2VnN8DehSJhxapF96YxV7BbinPz5FTdjOYgkoyERRlRMqzKNEV/r7M7YdakE /eSq73Ay9yFv5AogZDZlETMDncH1cr/dcloTNwfK0B5LDHDrLsg5wGgmaG5vGbaxtVdx T04Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931236; x=1792536036; 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=5eLIAAx2L+9DvCRKYW0jDBbtdiyv3jUNIhafttj/B0g=; b=s2OpxmNm6VhYRfulJ3RFitgOojvkNhopJxisotRipOx3cfxxPM6b9e5QhsLGnAm63B aZcEPD1WIjdFGi9E58X68PKzvPTiZ5t2Q8mbMxdDJ7v4UQ90Rq5jmFMVB5YAvwJaz2vJ +59ucrm0O6os8SLVUX51drP6feRUsn1UwrFNRXpgoe93xrNS1sc0GzpHN25r5XG1GaIb hlh4mknT7Y5ND8TCG6KPrHdhaLSRkCwfMYVc55atJIe1OkGkJItXchRsBWPwHP9p1dlq bMTHp1jVjJNH4Iv5vBT12tIbqhwznns1WDyRAzd4S19H9Rsl5ysYIk7mzOupMwIK9sXh Y2uQ== X-Forwarded-Encrypted: i=1; AKwUvBw32FTv72yeIZ/4UJkJRzZ35A6JXZbGjr+n/fKzym+0+cjt825gqv8oR85tBp4r1MLLadcB31yCa/8=@lists.xenproject.org X-Gm-Message-State: AFq9FYLPhwBiEsPv7VOFVB2pZw6U7yvM5bl4HHGgf75Q/2IEtl1LKLGr QAU4MeVLhE6V+RMOLSrfR0+1Rj9mBqFN4vYKBuxXItO6y+4Zhx5cn9FFNQgnGEP2Og8HpBopV4O btHKNxpaXyQ== X-Received: from dlbuu9.prod.google.com ([2002:a05:7022:7e89:b0:16c:bd18:1ee2]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:701b:231b:b0:165:55e2:2d69 with SMTP id a92af1059eb24-16a640fcc35mr21018967c88.46.1791931235508; Tue, 13 Oct 2026 15:40:35 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:45 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-11-irogers@google.com> Subject: [PATCH 10/11] drm/amdkfd: Free queue in procfs_queue_type kobject release callback From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-bad1c0/1791931238-BDEC6034-B6F97FF2/0/0 X-purgate-type: clean X-purgate-size: 2469 struct queue embeds a struct kobject (q->kobj) for procfs entries, but procfs_queue_type had no .release callback and uninit_queue() freed q immediately after kfd_procfs_del_queue() called kobject_put(&q->kobj). With CONFIG_DEBUG_KOBJECT_RELEASE=y, this causes a use-after-free. Add kfd_procfs_queue_release() to free struct queue from the kobject release callback, change kfd_procfs_del_queue() to only remove the kobject from sysfs via kobject_del(), and drop the final reference in uninit_queue() via kobject_put(). Fixes: 6d220a7e7971 ("drm/amdkfd: Add queue information to sysfs") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 ++++++++-- drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 5 ++++- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 0a7c1900da95..6099cb893573 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -510,7 +510,15 @@ static const struct sysfs_ops procfs_queue_ops = { .show = kfd_procfs_queue_show, }; +static void kfd_procfs_queue_release(struct kobject *kobj) +{ + struct queue *q = container_of(kobj, struct queue, kobj); + + kfree(q); +} + static const struct kobj_type procfs_queue_type = { + .release = kfd_procfs_queue_release, .sysfs_ops = &procfs_queue_ops, .default_groups = procfs_queue_groups, }; @@ -550,7 +558,6 @@ int kfd_procfs_add_queue(struct queue *q) if (ret < 0) { pr_warn("Creating proc//queues/%u failed", q->properties.queue_id); - kobject_put(&q->kobj); return ret; } @@ -699,7 +706,6 @@ void kfd_procfs_del_queue(struct queue *q) return; kobject_del(&q->kobj); - kobject_put(&q->kobj); } int kfd_process_create_wq(void) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c index 15eeaaebbbcd..8d1afc5b47e2 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c @@ -83,7 +83,10 @@ int init_queue(struct queue **q, const struct queue_properties *properties) void uninit_queue(struct queue *q) { - kfree(q); + if (q && q->kobj.state_initialized) + kobject_put(&q->kobj); + else + kfree(q); } #if IS_ENABLED(CONFIG_HSA_AMD_SVM) -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:40:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:40:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448341.1664383 (Exim 4.92) (envelope-from ) id 1xGlAo-0008Dp-Oz; Tue, 13 Oct 2026 22:40:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448341.1664383; Tue, 13 Oct 2026 22: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 1xGlAo-0008Dh-KP; Tue, 13 Oct 2026 22:40:42 +0000 Received: by outflank-mailman (input) for mailman id 1448341; Tue, 13 Oct 2026 22:40:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3ZbPOagcKCWQKTQIGTUIQQING.EQOZGP-FGXGNNKUVU.ZGPRTQLGEV.QTI@flex--irogers.bounces.google.com>) id 1xGlAn-00081Z-5T for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:40:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlAm-00B3QV-Aq for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:40:40 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3ZbPOagcKCWQKTQIGTUIQQING.EQOZGP-FGXGNNKUVU.ZGPRTQLGEV.QTI@flex--irogers.bounces.google.com>) id 6aceb354-bab6-0a2a0a5309dd-0a2a45079202-4 for ; Wed, 14 Oct 2026 00:40:40 +0200 Received: from [74.125.82.200] (helo=mail-dy1-f200.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3ZbPOagcKCWQKTQIGTUIQQING.EQOZGP-FGXGNNKUVU.ZGPRTQLGEV.QTI@flex--irogers.bounces.google.com>) id 6aceb366-b4ea-0a2a45070019-4a7d52c8e5bc-3 for ; Wed, 14 Oct 2026 00:40:40 +0200 Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-35a4d2e39acso1187992eec.1 for ; Tue, 13 Oct 2026 15:40: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=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=1791931238; x=1792536038; 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=KZW0TlkuVx1/ay444vuidlpbLOf1N6NgoBIEapd0snM=; b=FdWe65DHrRV7jMip3Af0+/uOE3PGOX1fD6nmURiP/oZq4XfADqTxl36S15/11/d8e2 d7BqlSz8tuGHGD9Sy74aX4qNj3NF96tFZ4bQCXZ7nn5mSN+4gHsbEZZEAsbPLJ5XYYbB clQTdafouVBnnMJ5qDXSseHtYA7HRnJKJkmjW+jyCIEfH2qACPpBkD93HW50A3nJh2tX PbqUIGGj9dzbMOnCBEtRKgBhRXxDhHlDAwcTQ+MguTwcYKq8a8f3WD/o10kUqOXHzNTJ y+1TX0XoCq4TrMwflNfblh4jxlTapW+wHBRQiMMP2EpY4by/Y20EcEbJLfTXbnFCxYVD WIUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931238; x=1792536038; 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=KZW0TlkuVx1/ay444vuidlpbLOf1N6NgoBIEapd0snM=; b=TbpTXTU5Mpi2X2SsihbAX7LQLmr+4yQHAXpx/oows/GFNa3yAxo0A8fAEg98euI7sp XYz+OV6aw4h0hQcuK2uyZw0MyHE+tgvOiZ7pFpYWAVKrNBjxNWR4NLS4RnmQ0Dn90tZ8 W6JSm3yDLjiUKhR19nGrGTr9/gZOKEsUsttunvA9d1td0HD4X06g6ag+ugzafZmUrUAJ 66Q6PaNxc3+l/rRxL2sTVOJLCIELWCHKXpRa01lpWHVq2C8JQ2CMtaj1T4oYS7Cx7QXu mQ8NlUutTzskfWBXEflgnnmzhUTrgym6LDNkAPVfZDp0cp8bSFgJu1+vJnFM+WjCPmzJ yWDQ== X-Forwarded-Encrypted: i=1; AKwUvBx0xoQKKLzcFXyMKfsNj3J2Zn0QypiUefkDc41Y+tB+20aT9D77GoEiB/pyIcE1qPzD/BgR3j1m0G8=@lists.xenproject.org X-Gm-Message-State: AFq9FYI1al5Q4W1tnU0ApKcXcfOiX6qiy8ofqT4Q/3yOmJI9kNRRYcUk ZAX4pVdXVTGZTsz1UR2y8a2lVRvUERC9mD6IO4j9CRtFJC5UO7jnRh0r/+VJmya1dst4sGxICAn ay1Qi1TXb6g== X-Received: from dly17-n1.prod.google.com ([2002:a05:701b:2051:10b0:168:6cd7:1061]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:b0d4:b0:141:4a06:ad6f with SMTP id a92af1059eb24-16a5dfd5d8cmr22211984c88.8.1791931237569; Tue, 13 Oct 2026 15:40:37 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:46 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-12-irogers@google.com> Subject: [PATCH 11/11] kobject: Require explicit initialization of struct kobj_type::release From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ef75cf/1791931240-A58C1AE4-A8021C84/0/0 X-purgate-type: clean X-purgate-size: 13043 Documentation/core-api/kobject.rst states: "One important point cannot be overstated: every kobject must have a release() method, and the kobject must persist (in a consistent state) until that method is called. If these constraints are not met, the code is flawed. Note that the kernel will warn you if you forget to provide a release() method. Do not try to get rid of this warning by providing an "empty" release function." Annotate struct kobj_type::release with __require_explicit_initialization so the compiler diagnoses any struct kobj_type initializer that omits .release. For the remaining legacy struct kobj_type definitions where the kobject is static, per-CPU, or embedded inside a devm- or parent-managed structure rather than freed by kobject_put(), explicitly initialize .release = NULL with a comment documenting why no release callback is provided. Link: https://lpc.events/event/20/contributions/2392/ Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- arch/arm64/kernel/cpuinfo.c | 2 ++ drivers/acpi/sysfs.c | 2 ++ drivers/dma/ioat/sysfs.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c | 4 ++++ drivers/infiniband/hw/hfi1/sysfs.c | 2 ++ drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 2 ++ drivers/parisc/pdc_stable.c | 2 ++ drivers/power/supply/ab8500_fg.c | 2 ++ drivers/soc/hisilicon/kunpeng_hccs.c | 6 ++++++ drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c | 2 ++ drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c | 2 ++ drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c | 2 ++ fs/erofs/sysfs.c | 4 ++++ fs/f2fs/sysfs.c | 6 ++++++ fs/ocfs2/cluster/masklog.c | 2 ++ include/linux/kobject.h | 2 +- 16 files changed, 43 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c index 45c63f3d75c5..ab78efdb13f5 100644 --- a/arch/arm64/kernel/cpuinfo.c +++ b/arch/arm64/kernel/cpuinfo.c @@ -309,6 +309,8 @@ const struct seq_operations cpuinfo_op = { static const struct kobj_type cpuregs_kobj_type = { + /* info->kobj is embedded in per-CPU cpu_data; cpuid_cpu_offline() only calls kobject_del(). */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops, }; diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index dd4a99f09efe..7534d3f305ba 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -972,6 +972,8 @@ static struct attribute *hotplug_profile_attrs[] = { ATTRIBUTE_GROUPS(hotplug_profile); static const struct kobj_type acpi_hotplug_profile_ktype = { + /* hotplug->kobj is embedded in static struct acpi_scan_hotplug objects. */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops, .default_groups = hotplug_profile_groups, }; diff --git a/drivers/dma/ioat/sysfs.c b/drivers/dma/ioat/sysfs.c index e796ddb5383f..7fdd0ca36b98 100644 --- a/drivers/dma/ioat/sysfs.c +++ b/drivers/dma/ioat/sysfs.c @@ -167,6 +167,8 @@ static const struct attribute *const ioat_attrs[] = { ATTRIBUTE_GROUPS(ioat); const struct kobj_type ioat_ktype = { + /* ioatdma_chan is allocated via devm_kzalloc() rather than freed by kobject_put(). */ + .release = NULL, .sysfs_ops = &ioat_sysfs_ops, .default_groups = ioat_groups, }; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c index b15af318784b..0477468f12ae 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c @@ -789,6 +789,8 @@ static const struct sysfs_ops xcp_cfg_res_sysfs_ops = { }; static const struct kobj_type xcp_cfg_res_sysfs_ktype = { + /* xcp_res is embedded in struct amdgpu_xcp_cfg rather than freed individually by kobject_put(). */ + .release = NULL, .sysfs_ops = &xcp_cfg_res_sysfs_ops, .default_groups = xcp_cfg_res_sysfs_groups, }; @@ -1053,6 +1055,8 @@ static const struct attribute_group amdgpu_xcp_attrs_group = { }; static const struct kobj_type xcp_sysfs_ktype = { + /* xcp is embedded in struct amdgpu_xcp_mgr rather than freed individually by kobject_put(). */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops, }; diff --git a/drivers/infiniband/hw/hfi1/sysfs.c b/drivers/infiniband/hw/hfi1/sysfs.c index 372cfd13dc61..33b26650069d 100644 --- a/drivers/infiniband/hw/hfi1/sysfs.c +++ b/drivers/infiniband/hw/hfi1/sysfs.c @@ -608,6 +608,8 @@ static const struct sysfs_ops sde_sysfs_ops = { }; static struct kobj_type sde_ktype = { + /* sdma_engine is embedded in the dd->per_sdma array rather than freed by kobject_put(). */ + .release = NULL, .sysfs_ops = &sde_sysfs_ops, }; diff --git a/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c b/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c index fdb63a8fb997..234d8d9532aa 100644 --- a/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c +++ b/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c @@ -245,6 +245,8 @@ static struct attribute *usnic_ib_qpn_default_attrs[] = { ATTRIBUTE_GROUPS(usnic_ib_qpn_default); static struct kobj_type usnic_ib_qpn_type = { + /* usnic_ib_qp_grp is embedded in RDMA core-managed struct usnic_ib_qp_grp. */ + .release = NULL, .sysfs_ops = &usnic_ib_qpn_sysfs_ops, .default_groups = usnic_ib_qpn_default_groups, }; diff --git a/drivers/parisc/pdc_stable.c b/drivers/parisc/pdc_stable.c index 16f4496bca95..6d972c965c1e 100644 --- a/drivers/parisc/pdc_stable.c +++ b/drivers/parisc/pdc_stable.c @@ -484,6 +484,8 @@ ATTRIBUTE_GROUPS(paths_subsys); /* Specific kobject type for our PDC paths */ static const struct kobj_type ktype_pdcspath = { + /* pdcspath_entry instances are static; lifetime is not controlled by kobject_put(). */ + .release = NULL, .sysfs_ops = &pdcspath_attr_ops, .default_groups = paths_subsys_groups, }; diff --git a/drivers/power/supply/ab8500_fg.c b/drivers/power/supply/ab8500_fg.c index e6b5efdf5dc9..206ee2e392fb 100644 --- a/drivers/power/supply/ab8500_fg.c +++ b/drivers/power/supply/ab8500_fg.c @@ -2531,6 +2531,8 @@ static struct attribute *ab8500_fg_attrs[] = { ATTRIBUTE_GROUPS(ab8500_fg); static const struct kobj_type ab8500_fg_ktype = { + /* fg_kobject is embedded in devm-allocated struct ab8500_fg; ab8500_fg_sysfs_exit() only calls kobject_del(). */ + .release = NULL, .sysfs_ops = &ab8500_fg_sysfs_ops, .default_groups = ab8500_fg_groups, }; diff --git a/drivers/soc/hisilicon/kunpeng_hccs.c b/drivers/soc/hisilicon/kunpeng_hccs.c index 0cc2953d59a5..5d083d2b72ca 100644 --- a/drivers/soc/hisilicon/kunpeng_hccs.c +++ b/drivers/soc/hisilicon/kunpeng_hccs.c @@ -1038,6 +1038,8 @@ static struct attribute *hccs_port_default_attrs[] = { ATTRIBUTE_GROUPS(hccs_port_default); static const struct kobj_type hccs_port_type = { + /* hccs_port_info is allocated via devm_kcalloc() rather than freed by kobject_put(). */ + .release = NULL, .sysfs_ops = &hccs_comm_ops, .default_groups = hccs_port_default_groups, }; @@ -1110,6 +1112,8 @@ static struct attribute *hccs_die_default_attrs[] = { ATTRIBUTE_GROUPS(hccs_die_default); static const struct kobj_type hccs_die_type = { + /* hccs_die_info is allocated via devm_kcalloc() rather than freed by kobject_put(). */ + .release = NULL, .sysfs_ops = &hccs_comm_ops, .default_groups = hccs_die_default_groups, }; @@ -1213,6 +1217,8 @@ static struct attribute *hccs_chip_default_attrs[] = { ATTRIBUTE_GROUPS(hccs_chip_default); static const struct kobj_type hccs_chip_type = { + /* hccs_chip_info is allocated via devm_kcalloc() rather than freed by kobject_put(). */ + .release = NULL, .sysfs_ops = &hccs_comm_ops, .default_groups = hccs_chip_default_groups, }; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c index ae937854403b..3d787245f5b5 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c @@ -304,6 +304,8 @@ static const struct sysfs_ops display_sysfs_ops = { }; static struct kobj_type display_ktype = { + /* dssdev->kobj is embedded in struct omap_dss_device and zeroed in display_uninit_sysfs(). */ + .release = NULL, .sysfs_ops = &display_sysfs_ops, .default_groups = display_sysfs_groups, }; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c index 1b644be5fe2e..cf816e83e903 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c @@ -496,6 +496,8 @@ static const struct sysfs_ops manager_sysfs_ops = { }; static struct kobj_type manager_ktype = { + /* mgr->kobj is embedded in static managers[] and zeroed in dss_manager_kobj_uninit(). */ + .release = NULL, .sysfs_ops = &manager_sysfs_ops, .default_groups = manager_sysfs_groups, }; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c index 1da4fb1c77b4..9aa16b3dee5e 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c @@ -429,6 +429,8 @@ static const struct sysfs_ops overlay_sysfs_ops = { }; static struct kobj_type overlay_ktype = { + /* ovl->kobj is embedded in static overlays[]; dss_overlay_kobj_uninit() only calls kobject_del(). */ + .release = NULL, .sysfs_ops = &overlay_sysfs_ops, .default_groups = overlay_sysfs_groups, }; diff --git a/fs/erofs/sysfs.c b/fs/erofs/sysfs.c index dfcec9376cd5..588d541e1713 100644 --- a/fs/erofs/sysfs.c +++ b/fs/erofs/sysfs.c @@ -238,6 +238,8 @@ static const struct kobj_type erofs_sb_ktype = { static const struct kobj_type erofs_ktype = { .default_groups = erofs_groups, .sysfs_ops = &erofs_attr_ops, + /* erofs_root is a static struct kset; lifetime is not controlled by kobject_put(). */ + .release = NULL, }; static struct kset erofs_root = { @@ -247,6 +249,8 @@ static struct kset erofs_root = { static const struct kobj_type erofs_feat_ktype = { .default_groups = erofs_feat_groups, .sysfs_ops = &erofs_attr_ops, + /* erofs_feat is a static struct kobject; lifetime is not controlled by kobject_put(). */ + .release = NULL, }; static struct kobject erofs_feat = { diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c index 811e350a1430..a66cef927c62 100644 --- a/fs/f2fs/sysfs.c +++ b/fs/f2fs/sysfs.c @@ -1653,6 +1653,8 @@ static const struct kobj_type f2fs_sb_ktype = { static const struct kobj_type f2fs_ktype = { .sysfs_ops = &f2fs_attr_ops, + /* f2fs_kset is a static struct kset; lifetime is not controlled by kobject_put(). */ + .release = NULL, }; static struct kset f2fs_kset = { @@ -1667,6 +1669,8 @@ static const struct sysfs_ops f2fs_feat_attr_ops = { static const struct kobj_type f2fs_feat_ktype = { .default_groups = f2fs_feat_groups, .sysfs_ops = &f2fs_feat_attr_ops, + /* f2fs_feat is a static struct kobject; lifetime is not controlled by kobject_put(). */ + .release = NULL, }; static struct kobject f2fs_feat = { @@ -1681,6 +1685,8 @@ static const struct sysfs_ops f2fs_tune_attr_ops = { static const struct kobj_type f2fs_tune_ktype = { .default_groups = f2fs_tune_groups, .sysfs_ops = &f2fs_tune_attr_ops, + /* f2fs_tune is a static struct kobject; lifetime is not controlled by kobject_put(). */ + .release = NULL, }; static struct kobject f2fs_tune = { diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c index 563881ddbf00..e476fa7ffea6 100644 --- a/fs/ocfs2/cluster/masklog.c +++ b/fs/ocfs2/cluster/masklog.c @@ -147,6 +147,8 @@ static const struct sysfs_ops mlog_attr_ops = { static struct kobj_type mlog_ktype = { .default_groups = mlog_default_groups, .sysfs_ops = &mlog_attr_ops, + /* mlog_kset is a static struct kset; lifetime is not controlled by kobject_put(). */ + .release = NULL, }; static struct kset mlog_kset = { diff --git a/include/linux/kobject.h b/include/linux/kobject.h index 55e37a5d405e..e65331717e03 100644 --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -114,7 +114,7 @@ void kobject_get_ownership(const struct kobject *kobj, kuid_t *uid, kgid_t *gid) char *kobject_get_path(const struct kobject *kobj, gfp_t flag); struct kobj_type { - void (*release)(struct kobject *kobj); + void (*release)(struct kobject *kobj) __require_explicit_initialization; const struct sysfs_ops *sysfs_ops; const struct attribute_group **default_groups; const struct kobj_ns_type_operations *(*child_ns_type)(const struct kobject *kobj); -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:42:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:42:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448360.1664391 (Exim 4.92) (envelope-from ) id 1xGlCU-0001Lk-61; Tue, 13 Oct 2026 22:42:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448360.1664391; Tue, 13 Oct 2026 22:42: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 1xGlCU-0001Ld-3B; Tue, 13 Oct 2026 22:42:26 +0000 Received: by outflank-mailman (input) for mailman id 1448360; Tue, 13 Oct 2026 22:42:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3VbPOagcKCVQ4DA20DE2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--irogers.bounces.google.com>) id 1xGlCT-0001LU-6n for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:42:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlCS-00GmGX-GR for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:42:24 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3VbPOagcKCVQ4DA20DE2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--irogers.bounces.google.com>) id 6aceb3a0-bab6-0a2a0a5309dd-0a2a450294c8-28 for ; Wed, 14 Oct 2026 00:42:24 +0200 Received: from [74.125.82.200] (helo=mail-dy1-f200.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3VbPOagcKCVQ4DA20DE2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--irogers.bounces.google.com>) id 6aceb356-6ca4-0a2a45020019-4a7d52c8cd33-3 for ; Wed, 14 Oct 2026 00:40:24 +0200 Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-35d4538fd74so1600997eec.1 for ; Tue, 13 Oct 2026 15:40: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=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=1791931222; x=1792536022; 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=qCnJ2cyf9mW8BNAz5Pcwsubr4iCDZba2S/P+mHJ/PnA=; b=vxc8wDk2AAiRnpHb/BA4v1H9q1W7PT0vplt5rDBjmuY7tGPDW6WVbAwQE8O8iIXDZ6 ac7UqD7gSxswO0jMit0Exz+17VJTOp5Q8/BeNFdQX3WaMVL6C7VFBaUtZ3AhvjIfGebN 7+gWylfY3EGkvK7Ry2E1ZS6eOrOb/5kpuhoOwO09LXxQc4SAK0HNuh4UNpf3aRLEHdoK IBtVAFiaWmTQgSaOUfMh5Ir/Syl+GdWCH2njz3hmQe9zgiAUoiwE7seepFiXL22f9d0J U5YeYqGjOlijXrT5m4dsX+VlWPgkRSsBPPtFlE6568DAULT/N2EJG17FEWpheEJeaX5P OiNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931222; x=1792536022; 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=qCnJ2cyf9mW8BNAz5Pcwsubr4iCDZba2S/P+mHJ/PnA=; b=wLlXk2ZiKwJ4JOEA+/8AG5f4HKZnMv4MMtBwUlvruQAJpaBPlvzEel6Wuu14lQFBnw P02RfKWwKGx9k0ALHe6ydPgEM41o1nYWDwLsj3zAfugjjpUP4cgNqXia768p6UolReGX +7NkZxLEEbGftoihMz5TbRKwsOWJJyKtaWj066OluTKty6tntB7rd/ZxuLv5bCwrMeMf ztAHsf6KHUF8WDGGTzDunQLeHk5msGp8DnOfYrUBAwoglzYcvrs0JwELpE0OAM1T/ych Kr/IZFpGylE5W9kAbEz5VXALeOjdWKPMT4Lf0g36xmrLwF85KEALS3xnXgk/pei3Il7g sp/Q== X-Forwarded-Encrypted: i=1; AKwUvBzKQQxv9YmxTbn5EhZImF4lkYW4BeXBcNoDP6yekz6acLzpasj43PSu7/VZBS7IY0UfomawVRTq620=@lists.xenproject.org X-Gm-Message-State: AFq9FYKxZwAwdA88r8qUWYvzFYcbTjreWpELu3GOXpSs3pKisy1uxeHv mtohlmQEpXFtbSn5YZLoK15wuDoa8wOFsQXWs2Nz87T+dCgjWzWsFZ05VashzgrxB2zOjnLzpsG pzQDQmv6RjA== X-Received: from dybsc14.prod.google.com ([2002:a05:7301:4b0e:b0:351:7270:d79a]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7300:f60a:b0:359:2edc:e1d8 with SMTP id 5a478bee46e88-3592edcf44bmr18703370eec.5.1791931221247; Tue, 13 Oct 2026 15:40:21 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:39 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-5-irogers@google.com> Subject: [PATCH 04/11] cpufreq: Initialize kobj_type release callback in ondemand and conservative governors From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-720697/1791931224-F32B12AC-4502ED77/0/0 X-purgate-type: clean X-purgate-size: 3423 Export cpufreq_dbs_data_release() and set .kobj_type.release in the ondemand and conservative governors so their gov_attr_set kobjects have a valid release callback, matching cpufreq_ governor_dbs. This prepares for annotating struct kobj_type::release with __require_explicit_initialization. Fixes: c4435630361d ("cpufreq: governor: New sysfs show/store callbacks for governor tunables") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- drivers/cpufreq/cpufreq_conservative.c | 5 ++++- drivers/cpufreq/cpufreq_governor.c | 3 ++- drivers/cpufreq/cpufreq_governor.h | 1 + drivers/cpufreq/cpufreq_ondemand.c | 5 ++++- 4 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c index 0b32ae28ec85..38c3bd5bf75a 100644 --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -316,7 +316,10 @@ static void cs_limits(struct cpufreq_policy *policy) static struct dbs_governor cs_governor = { .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"), - .kobj_type = { .default_groups = cs_groups }, + .kobj_type = { + .release = cpufreq_dbs_data_release, + .default_groups = cs_groups, + }, .gov_dbs_update = cs_dbs_update, .alloc = cs_alloc, .free = cs_free, diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 710d93ec89b5..97b64985927d 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -404,7 +404,7 @@ static void free_policy_dbs_info(struct policy_dbs_info *policy_dbs, gov->free(policy_dbs); } -static void cpufreq_dbs_data_release(struct kobject *kobj) +void cpufreq_dbs_data_release(struct kobject *kobj) { struct dbs_data *dbs_data = to_dbs_data(to_gov_attr_set(kobj)); struct dbs_governor *gov = dbs_data->gov; @@ -412,6 +412,7 @@ static void cpufreq_dbs_data_release(struct kobject *kobj) gov->exit(dbs_data); kfree(dbs_data); } +EXPORT_SYMBOL_GPL(cpufreq_dbs_data_release); int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) { diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h index 73b8ed7cfaae..c03d067f42eb 100644 --- a/drivers/cpufreq/cpufreq_governor.h +++ b/drivers/cpufreq/cpufreq_governor.h @@ -148,6 +148,7 @@ static inline struct dbs_governor *dbs_governor_of(struct cpufreq_policy *policy } /* Governor callback routines */ +void cpufreq_dbs_data_release(struct kobject *kobj); int cpufreq_dbs_governor_init(struct cpufreq_policy *policy); void cpufreq_dbs_governor_exit(struct cpufreq_policy *policy); int cpufreq_dbs_governor_start(struct cpufreq_policy *policy); diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index 9942dbb38dae..7386d043c665 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -374,7 +374,10 @@ static struct od_ops od_ops = { static struct dbs_governor od_dbs_gov = { .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("ondemand"), - .kobj_type = { .default_groups = od_groups }, + .kobj_type = { + .release = cpufreq_dbs_data_release, + .default_groups = od_groups, + }, .gov_dbs_update = od_dbs_update, .alloc = od_alloc, .free = od_free, -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:44:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:44:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448371.1664401 (Exim 4.92) (envelope-from ) id 1xGlEV-00020R-IF; Tue, 13 Oct 2026 22:44:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448371.1664401; Tue, 13 Oct 2026 22:44: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 1xGlEV-00020K-E9; Tue, 13 Oct 2026 22:44:31 +0000 Received: by outflank-mailman (input) for mailman id 1448371; Tue, 13 Oct 2026 22:44:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3WrPOagcKCVk9IF75IJ7FF7C5.3FDO5E-45M5CC9JKJ.O5EGIFA53K.FI7@flex--irogers.bounces.google.com>) id 1xGlEU-00020D-Jz for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:44:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlEU-00A5rG-0n for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:44:30 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3WrPOagcKCVk9IF75IJ7FF7C5.3FDO5E-45M5CC9JKJ.O5EGIFA53K.FI7@flex--irogers.bounces.google.com>) id 6aceb441-e002-0a2a0a5209dd-0a2a45088676-14 for ; Wed, 14 Oct 2026 00:44:30 +0200 Received: from [74.125.82.70] (helo=mail-dl1-f70.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3WrPOagcKCVk9IF75IJ7FF7C5.3FDO5E-45M5CC9JKJ.O5EGIFA53K.FI7@flex--irogers.bounces.google.com>) id 6aceb35b-f659-0a2a45080019-4a7d5246b457-3 for ; Wed, 14 Oct 2026 00:40:29 +0200 Received: by mail-dl1-f70.google.com with SMTP id a92af1059eb24-1665200f4c2so4837740c88.0 for ; Tue, 13 Oct 2026 15: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=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=1791931227; x=1792536027; 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=zqg4bcg4yTM1CSL1NV7gzxaOXxYgsDcagY96onRKZWw=; b=ms5bfVUokn/E9shSpIVEquBlyHDO3H6U557K4fDoPMX/Y41ASH4zgjhqt2MXom7goS UpQoOXtIEz9Kv/BMVzxIBBJ9bgwRSTSn+bge2L4i5zLWSSm1SE7L6zb64/iGchM1f8cV OwmaMM/aKfz5P48uHEw5TWgpCEU4GhOCCHJ2AxH2Ro+3owFGIBNjCOooiwdZ9mCQ9O+i bN8XFf+V6VwslGZ7AYaWJzjRRSch3osrdCHgZQw58Lc/0SqwBdiXd7XaFDWKjFEghqfx barHaAIrpMSPn3jUMBmfNk3ve1zvZtNgYEHza1Xx1FWqkhSAkOQRNNgse5rKjKJjAXBI s0FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931227; x=1792536027; 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=zqg4bcg4yTM1CSL1NV7gzxaOXxYgsDcagY96onRKZWw=; b=tQ/AHJ+X1JmodoU3R3CU9RN3qEt7SpBy5M33D4hX8JNQ813cq8cYstkD2Z+n6FEzA8 ghzwsaOy7HhIi+AytAfpFOCIfnmdbow4IG19c+1DnFL43wQ53Zg+3LD7dapJzoOikFQM h9RAH7y3ECMPiNoz+CPGb4bl3dEJp7GKIMnaJ4A6MxwWd35A2IOaWd8EhOMY5poNYVZf 6YqKUBa5An8Wo0WrhO+BhLwWRCRFGdfVJAu8MImIVX+t9AekAHlf4/ffNRXzFaMOkZuH WRHFSLQUeIsKTA50AmS7V+BUwFLNyODa0F8LIerbtA7tJjwI1l5N0JTf8wnECo0PRr0/ smaA== X-Forwarded-Encrypted: i=1; AKwUvByxGH8I8rjXLOwXPH5kLPJIOY68jSM34PLtQ1pZxPDyuEuIaOeBMYKf5xNcHx7lhmTO5E8CGK6nQKE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJX5zMTNLYyt3SukTQkWm8MqWWVFEiakeDuWH3At2p8uQEBo6+R yTyJlRkkVeN0k1NYUb+k7ZV6e4pTSaH6zvD4SPVxXvyaxIgfk3Y7VPYsqmjHA8Sys5zIC/3iZzS VjG73zdynTg== X-Received: from dldyq19-n1.prod.google.com ([2002:a05:701b:4553:10b0:164:47f8:a96a]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:701b:4286:10b0:144:c128:4c4b with SMTP id a92af1059eb24-16a5e49c474mr18578865c88.36.1791931226644; Tue, 13 Oct 2026 15:40:26 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:41 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-7-irogers@google.com> Subject: [PATCH 06/11] dlm: Free dlm_ls in kobject release callback From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c1860d/1791931229-D437587B-6D81C9D5/0/0 X-purgate-type: clean X-purgate-size: 2861 struct dlm_ls embeds a struct kobject (ls_kobj), but dlm_ktype lacked a .release callback and dlm freed the lockspace structure directly via kfree(ls). With CONFIG_DEBUG_KOBJECT_RELEASE=y, freeing ls before the kobject release runs causes a use-after-free. Add dlm_ls_release() to free struct dlm_ls when the last reference to ls_kobj is dropped, use kobject_del() in release_lockspace(), and drop the final kobject reference in free_lockspace(). Fixes: 3514faca19a6 ("kobject: remove struct kobj_type from struct kset") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- fs/dlm/lockspace.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/fs/dlm/lockspace.c b/fs/dlm/lockspace.c index a9c98b4f378f..1d226b27d8e6 100644 --- a/fs/dlm/lockspace.c +++ b/fs/dlm/lockspace.c @@ -179,7 +179,15 @@ static const struct sysfs_ops dlm_attr_ops = { .store = dlm_attr_store, }; +static void dlm_ls_release(struct kobject *kobj) +{ + struct dlm_ls *ls = container_of(kobj, struct dlm_ls, ls_kobj); + + kfree(ls); +} + static struct kobj_type dlm_ktype = { + .release = dlm_ls_release, .default_groups = dlm_groups, .sysfs_ops = &dlm_attr_ops, }; @@ -355,7 +363,7 @@ static void free_lockspace(struct work_struct *work) */ rhashtable_free_and_destroy(&ls->ls_rsbtbl, rhash_free_rsb, NULL); - kfree(ls); + kobject_put(&ls->ls_kobj); } static int new_lockspace(const char *name, const char *cluster, @@ -436,6 +444,8 @@ static int new_lockspace(const char *name, const char *cluster, atomic_set(&ls->ls_count, 0); init_waitqueue_head(&ls->ls_count_wait); ls->ls_flags = 0; + ls->ls_kobj.kset = dlm_kset; + kobject_init(&ls->ls_kobj, &dlm_ktype); if (ops && dlm_config.ci_recover_callbacks) { ls->ls_ops = ops; @@ -567,9 +577,7 @@ static int new_lockspace(const char *name, const char *cluster, wait_event(ls->ls_recover_lock_wait, test_bit(LSFL_RECOVER_LOCK, &ls->ls_flags)); - ls->ls_kobj.kset = dlm_kset; - error = kobject_init_and_add(&ls->ls_kobj, &dlm_ktype, NULL, - "%s", ls->ls_name); + error = kobject_add(&ls->ls_kobj, NULL, "%s", ls->ls_name); if (error) goto out_recoverd; kobject_uevent(&ls->ls_kobj, KOBJ_ADD); @@ -615,7 +623,6 @@ static int new_lockspace(const char *name, const char *cluster, rhashtable_destroy(&ls->ls_rsbtbl); out_lsfree: kobject_put(&ls->ls_kobj); - kfree(ls); out: module_put(THIS_MODULE); return error; @@ -759,7 +766,7 @@ static int release_lockspace(struct dlm_ls *ls, unsigned int release_option) dlm_delete_debug_file(ls); - kobject_put(&ls->ls_kobj); + kobject_del(&ls->ls_kobj); xa_destroy(&ls->ls_recover_xa); kfree(ls->ls_recover_buf); -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:44:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:44:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448372.1664408 (Exim 4.92) (envelope-from ) id 1xGlEd-0002Gg-Qq; Tue, 13 Oct 2026 22:44:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448372.1664408; Tue, 13 Oct 2026 22:44: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 1xGlEd-0002GZ-Nq; Tue, 13 Oct 2026 22:44:39 +0000 Received: by outflank-mailman (input) for mailman id 1448372; Tue, 13 Oct 2026 22:44:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3YLPOagcKCV8FOLDBOPDLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--irogers.bounces.google.com>) id 1xGlEc-0002Fs-K6 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:44:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlEc-00A5xn-17 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:44:38 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3YLPOagcKCV8FOLDBOPDLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--irogers.bounces.google.com>) id 6aceb441-e002-0a2a0a5209dd-0a2a45088676-20 for ; Wed, 14 Oct 2026 00:44:38 +0200 Received: from [74.125.82.71] (helo=mail-dl1-f71.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3YLPOagcKCV8FOLDBOPDLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--irogers.bounces.google.com>) id 6aceb364-f659-0a2a45080019-4a7d5247b464-3 for ; Wed, 14 Oct 2026 00:40:37 +0200 Received: by mail-dl1-f71.google.com with SMTP id a92af1059eb24-1665200f4c2so4837985c88.0 for ; Tue, 13 Oct 2026 15:40: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=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=1791931235; x=1792536035; 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=gurzTkqqRagMZrBgJFBCVz7i93uSa3r8+lp0iuHqO9A=; b=BWmFxJzxUz7vC/efRk6VrtLsD1knKxkdFUm98UWWO2X9S6/2hE6fPjgmbxczbbMEd3 7mYQG2/huk1DrZMOchPbMN5147owBZ0irLigfn6JJsQbbtsS/OmjZuOxTYkM9Ch+R9PA 6SFB99UDSykCWXLmaD+1CRwvjasfHSityTg3WrlWtSGsBPo7ZAJryacqyJ3Td1Jajxb0 nIG7uul4U8URZduDqlhRwOmlmR1jNkUz4nl9C/TmZW+5w1/41aL/kd2S8MIbip+ZafNg NwzGjLvywEO/WnsPCCFxk8VJFLtnoynIlA0lLRoMEoEUE8uz6RUZyu+xjAb/w7ojrHP7 b8mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931235; x=1792536035; 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=gurzTkqqRagMZrBgJFBCVz7i93uSa3r8+lp0iuHqO9A=; b=vEgaGaRBOGmvR/6FNsVfpIy6oC3LbhiPid5+D7CbMDz2p/Tym6J11AXFT4kWUIlf9q 4rfh7uIt8z/jaH/S75Mcb/l1yAHsr1yXtRyW1mCCc5JX1viOU62DQAk3FJ5l/oE0AN8q F8V3Dao6x8sR8hfANt6ESKrSOR7styqgTUJPua1rFX5ZEu0Dep7HXIzpIBmtbFiIqJ1q Py26U0xs0TNYkAkDu8OhpXlJgNXp8Wc+DzvlVqRZoOA6FDwRHBjjOoBXwzGPBY6Yb2Uq oB/g03MET3dW5YyqXTob6GflJ82a2lrCJim4H+fZN9gGaVMv/ya+h1aZLvw68A/iUvUc 8tuw== X-Forwarded-Encrypted: i=1; AKwUvByFU4nCELaGfp3bqznzeBZ205oWcXC7dgE0kmtQeGG/ElMvrtIcFlEfBmXH7x/5DQ0IUTgF+5BTqXs=@lists.xenproject.org X-Gm-Message-State: AFq9FYIfh1L1jzA3czagOnww7LBFnDG3SQ+Q7XqEES/xjGfMsH6e/PNE 8rr5NKHC+0q4gzSujW8PoaO4tD4PDGSg2jwYLoIK4zoc9mzEeKO/DWHIVBnnuBjJDJGtL0EXW9F +B1kcg3NUig== X-Received: from dleg6-n1.prod.google.com ([2002:a05:701b:4306:10b0:160:bb23:390d]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:701b:4586:20b0:169:b1b1:1445 with SMTP id a92af1059eb24-16a5dbfe73dmr17947821c88.31.1791931232672; Tue, 13 Oct 2026 15:40:32 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:44 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-10-irogers@google.com> Subject: [PATCH 09/11] ubifs: sysfs: Use kset_create_and_add() for ubifs_kset From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c1860d/1791931237-CDD4887B-2C610901/0/0 X-purgate-type: clean X-purgate-size: 1991 ubifs_kset was a static struct kset using a custom ubifs_ktype that had no default_groups and no .release callback. With CONFIG_DEBUG_KOBJECT_RELEASE=y, unloading the ubifs module while delayed kobject release is pending causes a use-after-free on the static kset. Replace the static ubifs_kset and empty ubifs_ktype with a dynamically allocated kset via kset_create_and_add(). Fixes: 203a55f04f66 ("ubifs: Fix memory leak in ubifs_sysfs_init()") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- fs/ubifs/sysfs.c | 24 +++++++----------------- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/fs/ubifs/sysfs.c b/fs/ubifs/sysfs.c index dbf967dcf26e..e20931e3a62f 100644 --- a/fs/ubifs/sysfs.c +++ b/fs/ubifs/sysfs.c @@ -80,13 +80,7 @@ static const struct kobj_type ubifs_sb_ktype = { .release = ubifs_sb_release, }; -static const struct kobj_type ubifs_ktype = { - .sysfs_ops = &ubifs_attr_ops, -}; - -static struct kset ubifs_kset = { - .kobj = {.ktype = &ubifs_ktype}, -}; +static struct kset *ubifs_kset; int ubifs_sysfs_register(struct ubifs_info *c) { @@ -107,7 +101,7 @@ int ubifs_sysfs_register(struct ubifs_info *c) goto out_free; } - c->kobj.kset = &ubifs_kset; + c->kobj.kset = ubifs_kset; init_completion(&c->kobj_unregister); ret = kobject_init_and_add(&c->kobj, &ubifs_sb_ktype, NULL, @@ -139,18 +133,14 @@ void ubifs_sysfs_unregister(struct ubifs_info *c) int __init ubifs_sysfs_init(void) { - int ret; + ubifs_kset = kset_create_and_add("ubifs", NULL, fs_kobj); + if (!ubifs_kset) + return -ENOMEM; - kobject_set_name(&ubifs_kset.kobj, "ubifs"); - ubifs_kset.kobj.parent = fs_kobj; - ret = kset_register(&ubifs_kset); - if (ret) - kset_put(&ubifs_kset); - - return ret; + return 0; } void ubifs_sysfs_exit(void) { - kset_unregister(&ubifs_kset); + kset_unregister(ubifs_kset); } -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:45:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:45:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448380.1664417 (Exim 4.92) (envelope-from ) id 1xGlFS-0002zK-2n; Tue, 13 Oct 2026 22:45:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448380.1664417; Tue, 13 Oct 2026 22: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 1xGlFR-0002zD-W3; Tue, 13 Oct 2026 22:45:29 +0000 Received: by outflank-mailman (input) for mailman id 1448380; Tue, 13 Oct 2026 22:45:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3V7POagcKCVY6FC42FG4CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--irogers.bounces.google.com>) id 1xGlFQ-0002yv-H0 for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:45:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlFP-00EJzO-JP for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:45:27 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3V7POagcKCVY6FC42FG4CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--irogers.bounces.google.com>) id 6aceb42c-2eae-0a2a0a5409dd-0a2a450c859e-48 for ; Wed, 14 Oct 2026 00:45:27 +0200 Received: from [74.125.82.200] (helo=mail-dy1-f200.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3V7POagcKCVY6FC42FG4CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--irogers.bounces.google.com>) id 6aceb359-f479-0a2a450c0019-4a7d52c8bc93-3 for ; Wed, 14 Oct 2026 00:40:26 +0200 Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-30bcb065bfdso6716197eec.0 for ; Tue, 13 Oct 2026 15:40: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-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=1791931225; x=1792536025; 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=wbjJdHqZPRkvVZnH2yPkFa6V1wQ6/MdT39yYoogCQX4=; b=SmS32V5OWk4jGARU3BEnixrfw5uMJpcDHtjupdonA4HcAja2tq7SNQm3E9w1Sn27Yi gORg7K3yP+UOGbCopymG/cIJzSmAD0EuN53Zp71TrhOf0zj1c0C9pb8hA3izi0sP7URm l8OTrGmT+RGGwji9AnbnIkWw0hIaN8xHobamGJJNt2D3ysr95ma5YddyjxbNOTwCZMm2 wWgFHqtNqj+e1QnlWv7eZZ50zfzflDyM4JIbL/XI/fWngHf2qhbhgto3CvYh3TiEqJPa 6Tuc7JA8T7DdCym4u81jjAcM0Ukxb7kCWan69sNHg1XMrcqZiDNBcEbZfC/r5EXaszl7 6kEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931225; x=1792536025; 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=wbjJdHqZPRkvVZnH2yPkFa6V1wQ6/MdT39yYoogCQX4=; b=Be8NFsdX3h7uWapkrBR/bSzurIqeY2XaIruahMCPxA5N9hbEXdAXlwUx1p5DaJDFXB RPSmLU4zndbW3mNEgCMEWs1t1wHuKAsyKk20DjORGckfBlNzczBUEWqwi6Hths/nvK9P /8AxgFImaDhzdnjBbactY8G/rvaNvbv7a4TB29NTaO1E6yzw3Ni2dfJw/lpK2E/cg/Mo pAGNIkVe/0NDH0a+HfBmqEx8/xPV4DBA6rLSqTa8XHBmRwtbkibvIoR1qO/TdWPMQ1Ov X0p+sRseRXzig9CrRpgDtX5um6y540ijPtbnOn2jsiek+0z8emDJMSFD4TGeCseELnzB cXUg== X-Forwarded-Encrypted: i=1; AKwUvBxPJp45cYCm9qSMKBQog5g/ucSv6ANqUCKlwgVi2iNYRGvQUge4K7tA4xy90IA3UhtYD+hA2blGtwM=@lists.xenproject.org X-Gm-Message-State: AFq9FYJiDCSyVsURYDr2P4DT+yr6O1rVA7fuPTSdEjSeWhqwxoXfo6pm OqhFTjDVvHmiGwa8FP3i0fhrFJJhQ4FGyj4DjugYUJfKjmJpDVNnt1eeAphPesSa79KNb5+4C1/ FuN+IVcViYg== X-Received: from dyr27.prod.google.com ([2002:a05:693c:401b:b0:359:e5f1:14fb]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7301:470e:b0:35c:73ca:a1e0 with SMTP id 5a478bee46e88-35c73caae65mr4317399eec.15.1791931223446; Tue, 13 Oct 2026 15:40:23 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:40 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-6-irogers@google.com> Subject: [PATCH 05/11] ACPI: CPPC: Free cpc_desc in kobject release callback From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1791931227-772D8A5B-4B46A7DF/13/0 X-purgate-type: clean X-purgate-size: 3453 cpc_desc_ptr embeds a struct kobject that is registered in sysfs via kobject_init_and_add(), but cppc_ktype lacked a .release callback and acpi_cppc_processor_exit() freed cpc_ptr immediately after kobject_put(). With CONFIG_DEBUG_KOBJECT_RELEASE=y, this causes a use-after-free when kobject_delayed_cleanup() runs on freed memory. Move the sys_mem_vaddr unmapping and kfree(cpc_ptr) into a new cppc_release() callback on cppc_ktype, and initialize the kobject on allocation so kobject_put() handles cleanup in all paths. Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- drivers/acpi/cppc_acpi.c | 39 ++++++++++++++++++--------------------- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index fef54fcd00b7..2a80404f85d3 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -297,7 +297,22 @@ static struct attribute *cppc_attrs[] = { }; ATTRIBUTE_GROUPS(cppc); +static void cppc_release(struct kobject *kobj) +{ + struct cpc_desc *cpc_ptr = to_cpc_desc(kobj); + unsigned int i; + + for (i = 2; i < cpc_ptr->num_entries; i++) { + void __iomem *addr = cpc_ptr->cpc_regs[i - 2].sys_mem_vaddr; + + if (addr) + iounmap(addr); + } + kfree(cpc_ptr); +} + static const struct kobj_type cppc_ktype = { + .release = cppc_release, .sysfs_ops = &kobj_sysfs_ops, .default_groups = cppc_groups, }; @@ -799,6 +814,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) ret = -ENOMEM; goto out_buf_free; } + kobject_init(&cpc_ptr->kobj, &cppc_ktype); /* First entry is NumEntries. */ cpc_obj = &out_obj->package.elements[0]; @@ -1001,11 +1017,9 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) /* Plug PSD data into this CPU's CPC descriptor. */ per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr; - ret = kobject_init_and_add(&cpc_ptr->kobj, &cppc_ktype, &cpu_dev->kobj, - "acpi_cppc"); + ret = kobject_add(&cpc_ptr->kobj, &cpu_dev->kobj, "acpi_cppc"); if (ret) { per_cpu(cpc_desc_ptr, pr->id) = NULL; - kobject_put(&cpc_ptr->kobj); goto out_free; } @@ -1013,14 +1027,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) return 0; out_free: - /* Free all the mapped sys mem areas for this CPU */ - for (i = 2; i < cpc_ptr->num_entries; i++) { - void __iomem *addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; - - if (addr) - iounmap(addr); - } - kfree(cpc_ptr); + kobject_put(&cpc_ptr->kobj); out_buf_free: kfree(output.pointer); @@ -1037,8 +1044,6 @@ EXPORT_SYMBOL_GPL(acpi_cppc_processor_probe); void acpi_cppc_processor_exit(struct acpi_processor *pr) { struct cpc_desc *cpc_ptr; - unsigned int i; - void __iomem *addr; int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, pr->id); if (pcc_ss_id >= 0 && pcc_data[pcc_ss_id]) { @@ -1056,15 +1061,7 @@ void acpi_cppc_processor_exit(struct acpi_processor *pr) if (!cpc_ptr) return; - /* Free all the mapped sys mem areas for this CPU */ - for (i = 2; i < cpc_ptr->num_entries; i++) { - addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; - if (addr) - iounmap(addr); - } - kobject_put(&cpc_ptr->kobj); - kfree(cpc_ptr); } EXPORT_SYMBOL_GPL(acpi_cppc_processor_exit); -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 13 22:45:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Oct 2026 22:45:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448381.1664428 (Exim 4.92) (envelope-from ) id 1xGlFW-0003DZ-Bi; Tue, 13 Oct 2026 22:45:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448381.1664428; Tue, 13 Oct 2026 22: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 1xGlFW-0003DS-73; Tue, 13 Oct 2026 22:45:34 +0000 Received: by outflank-mailman (input) for mailman id 1448381; Tue, 13 Oct 2026 22:45:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3XLPOagcKCVsBKH97KL9HH9E7.5HFQ7G-67O7EEBLML.Q7GIKHC75M.HK9@flex--irogers.bounces.google.com>) id 1xGlFU-0003CO-QL for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 22:45:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGlFU-00Gmem-5K for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 00:45:32 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3XLPOagcKCVsBKH97KL9HH9E7.5HFQ7G-67O7EEBLML.Q7GIKHC75M.HK9@flex--irogers.bounces.google.com>) id 6aceb48c-bab6-0a2a0a5309dd-0a2a450cdc52-0 for ; Wed, 14 Oct 2026 00:45:32 +0200 Received: from [74.125.82.197] (helo=mail-dy1-f197.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3XLPOagcKCVsBKH97KL9HH9E7.5HFQ7G-67O7EEBLML.Q7GIKHC75M.HK9@flex--irogers.bounces.google.com>) id 6aceb35e-f479-0a2a450c0019-4a7d52c5ccc8-3 for ; Wed, 14 Oct 2026 00:40:31 +0200 Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-3580c07911eso9020099eec.0 for ; Tue, 13 Oct 2026 15: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=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=1791931229; x=1792536029; 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=SzuEQJa4uF6wSn0s7ZpxNvjcEHFt9KB4NkbiARikmlQ=; b=FzkhHr/FJ1gI/lJccZ4WlqGOBNhVB+JzECBpvhgYLDSw8O1fErtS0a7gULcVQAjmA/ kc56ThccM6WrMMyViXcXz/teDGtJfBK4Q5FuTePJrYnmsxOR1jVlEuxMDVl30a6UnhlS o3zYa92V3c4ZaHp/xdY+9vwk82TrcHQj7uZ9IvISPL5hL9rfCsBkLIAWFyQl9yPXSAKZ 35ur5vd7x0FX8Z7RYFqcEMbMdU83ssyv+70JwFyV2yWnKvvzziA/wRGHyEmqSMTJPDUr k6AhFdEHSMbKC9pwKKImM6RgWzjC6V2MkuOczq9bkOVhs5R0RaucjOC/Vn7hMoqNtv94 E84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791931229; x=1792536029; 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=SzuEQJa4uF6wSn0s7ZpxNvjcEHFt9KB4NkbiARikmlQ=; b=VncM2+dxgcYmPzP5QVJK/uN/VnJNjD2fSBX6awWsBjLeiFvSbKYD/6N312s9fI0b+R z68pMw38bOnqLiBc4LQwB2x9ou/cTeINuYoni/HFkZc4+RJqpXH/64XfLbpl0060uvEy rPZsofzWCqz5+rmmRzYVHqwEVfv32hxJSrm2ka/3U9efH+fAJuk/KOGAQ2TsedZvW0ZB UZcF2yoohIG3GLhbXsQkIwfovY6iZ+NXq8mtZCdJJEkoaUu7ZVP+aAAssAeFa1Se6IWD se4mtKdcKz1xBvSIZGKNPvR5niuOF/LrR5xSAXQc5cD6MHKlZjj6/v1d7KcjdUfzbKEq EDkg== X-Forwarded-Encrypted: i=1; AKwUvBzVMDJx3uWxp04n5ov8R5oFkEaZtSacHaCaHzvww9ANcNG+5m2hLRLJ3PK/hySGIbP2xLCTmp19GTg=@lists.xenproject.org X-Gm-Message-State: AFq9FYKfuXQtr2GgHXHbUV6myCbq5TfvMpFIOKDLgOhWxFwWIA/Xj41E fiVxAt6HIiThuGs/jKTzudC+UsgmOa7Krcu1SXQo5HwjxwzM/1bALN06dpJHHSQ5thcR6p5Fi+k oF1YTESEHlg== X-Received: from dybmf44.prod.google.com ([2002:a05:7301:92c:b0:358:41fa:f46f]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7300:c8c2:b0:35a:8dad:6724 with SMTP id 5a478bee46e88-35a8dad7ec8mr9213311eec.22.1791931228757; Tue, 13 Oct 2026 15:40:28 -0700 (PDT) Date: Tue, 13 Oct 2026 15:39:42 -0700 In-Reply-To: <20261013223946.1836757-1-irogers@google.com> Mime-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261013223946.1836757-8-irogers@google.com> Subject: [PATCH 07/11] xen/sys-hypervisor: Add release callback to hyp_sysfs_kobj_type From: Ian Rogers To: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1791931231-022C0A5B-ABF9157D/13/0 X-purgate-type: clean X-purgate-size: 1197 hypervisor_init() in drivers/base/hypervisor.c creates hypervisor_kobj with kobject_create_and_add() (which allocates a dynamic kobject using dynamic_kobj_ktype), and hypervisor_subsys_init() in drivers/xen/sys-hypervisor.c then overwrites hypervisor_kobj->ktype with &hyp_sysfs_kobj_type, which had no .release callback. Add hyp_sysfs_release() calling kfree(kobj) to preserve the dynamic kobject release behavior. Fixes: cff7e81b3dd7 ("xen: add /sys/hypervisor support") Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Ian Rogers --- drivers/xen/sys-hypervisor.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c index 91923242a5ae..0e8a2cd69fd6 100644 --- a/drivers/xen/sys-hypervisor.c +++ b/drivers/xen/sys-hypervisor.c @@ -659,7 +659,13 @@ static const struct sysfs_ops hyp_sysfs_ops = { .store = hyp_sysfs_store, }; +static void hyp_sysfs_release(struct kobject *kobj) +{ + kfree(kobj); +} + static const struct kobj_type hyp_sysfs_kobj_type = { + .release = hyp_sysfs_release, .sysfs_ops = &hyp_sysfs_ops, }; -- 2.56.0.385.gd3acb90ef8-goog From xen-devel-bounces@lists.xenproject.org Wed Oct 14 04:25:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 04:25:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448431.1664437 (Exim 4.92) (envelope-from ) id 1xGqXy-0007Be-Qy; Wed, 14 Oct 2026 04:24:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448431.1664437; Wed, 14 Oct 2026 04:24: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 1xGqXy-0007BT-Lr; Wed, 14 Oct 2026 04:24:58 +0000 Received: by outflank-mailman (input) for mailman id 1448431; Wed, 14 Oct 2026 04:24:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGqXx-0007BN-4j for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 04:24:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGqXu-00EsXK-IY for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 06:24:54 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf0401-8faa-0a2a0a5109dd-0a2a450ae62e-16 for ; Wed, 14 Oct 2026 06:24:54 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf0414-f2d2-0a2a450a0019-cddcb4835410-3 for ; Wed, 14 Oct 2026 06:24:53 +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 69DLb8eD1403322 for ; Wed, 14 Oct 2026 04:24:52 GMT Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4h9psk30q2-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 14 Oct 2026 04:24:51 +0000 (GMT) Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2df8d1e91c9so74354835ad.0 for ; Tue, 13 Oct 2026 21:24:51 -0700 (PDT) Received: from [10.133.33.242] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3ac63279277sm860530a91.1.2026.10.13.21.24.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 21:24: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=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= R/YWOWusTmnn9Tx8/iLnPWjpANYDhhlrDY+RymDC9lQ=; b=mfBIXI1uLAOYHNpx M+pskrgQQbpJj/+60jNFLzZFxHw2r6RDPCnEYQak0C68FqNpjyua8eynX8SGcd1Y 2J1k4+K/t/BHMHnNSVt94VWd+zjp21ADu/+gT5GHSxkze+TVoAJ8ZcEJUegyUcj3 l02tjV+K80HtT6WpkHCz8hJA1pNAkGFI0embeDgtOOxCvfUQQ4c9lcW5zqnNjbim +IIDJbRdlgftjP27N4Ac7M+zpCtJs+D/UR8kPP45vYPVDrD5gR3xqxJhNmnwyIgi K4kI1TWbCLNx+Vt70sIiD4gGFEtC25wsPGiQD9gMthErtmViPMA3SxZL1fMU3msx O1ZOMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1791951891; x=1792556691; 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/YWOWusTmnn9Tx8/iLnPWjpANYDhhlrDY+RymDC9lQ=; b=IShNjmIN6fQMs2vtEdRfpAfYcpDwhfWaPM3itOnmj6QOvEveWPqIEjVslvE3CANiW5 2cEaC1a6dKbh071XTSCc0CYNvdLvxzzb6nttmD5XBixQU5QJ6HFs6RI4pw6CcKHpzCo/ Wpa3G98BWQFZwAmddK/Khs9ubTAjMq9iWJFgQMJhbqQliu76EISBFm34RBbdXtFffKEr lE3aH8JggfqOPkcebTWGtddp+nr/m7R1Isc9fHFzvQyVRC7Fo4w6yrf//rCQcjqkKpQq 9yuMaEQm9TgepkZbRbeDgIH2hqmtPTmW4okH3gcugYSsIwX6kBZekRLNMoTl2hcgr/Im OuXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791951891; x=1792556691; 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/YWOWusTmnn9Tx8/iLnPWjpANYDhhlrDY+RymDC9lQ=; b=AfrGvcE6MjISLDtNAekCVwcvnQRfXB3prHbudRtq5gURG0n/+f7KCC3BkhzMqKHlbM D7Z8mpqvm0HnGGMo7UOklQ6Ex2Syfea3ohxFNfIVf5c8W9qSfLLiqOG+5jw0d1L7ocaf rTZ/tZOzG0hf/ZywrWxkBoQsGCeCQqORB3SnSIZzVEol9II6uju7Ss9nwvKIkJ8BgF+v LLyDNNewaLVSDrZ4JevjqlqmhRMmpWo8qxRpU7YXZohkwyar7Xg4zgpPkzBuurpmFLzF Jqso9eBm45Z390lSOJK7h1Wtixn1VDsbUdbYd4ibBvqXp/C/jWDAI6i26zjvWEkhJIZb HrSQ== X-Forwarded-Encrypted: i=1; AKwUvBwbkZVaRFNFhG+Rvc5JgcNO1KdjLJ5bUpJoC/oQ3aC7bUCzdwZ+UrxpPyMI4XMbI1pCmWd9Wjpp3yM=@lists.xenproject.org X-Gm-Message-State: AFq9FYLygfbK7lBGScb0D9p8CFxo/jPCBz1GSRnrofy/KInDlvrUhy0Y m2Q8BR2Z6WDrzmrAQr4uj3o1ILr3aKcgTbVCXj1vbkpQ93VjiPIBGExEAgOcqOxRUz7PpyH+nC2 gQFQcEx8FMha3vfVSLkkJbYHz66/3r/9wijDzMJMCpHlbw56dYi7euzwL9YrFuVIIX327bQ== X-Gm-Gg: AYBFou1+7JdBfPUk9DExev8SaocqhITNGJJ1CJzf9i0ZlkVXUdbpQnJZTWg043Pwqja xipbqm3YX1u7XDp96hJ7tKLpZroSlt5cU2ayp1xrO8IPoXMrFQ/99WNIqzFvubbUraI5USbuFDi v6i8wquXrUi89FCu7EFgmsNmfrWVj0zO/BxpB8EKUZfFzL7dooN7eJn7t/vwRf4ig/DYrA9CiKz mBi/lVpmg+8LkH46snNMXLZzZBvBfBq98vWhz7JUgvfz6RzqEHwffx9zr5Yipeldch25nx4tZGh 0pMOxYmSjJr8PpBxQAIDuLRUlTKDgXJmU9Mp1o7ujbhneHHdEgzrKS3J7j/zqIH90jdMZ0hhjtk H40TpfH51p1tIx9h5FUcr8Y6fyhaK+IueXIGD6N9eXp+cBmsJ8USLtwEE9BjCvIuMQvS8lMya X-Received: by 2002:a17:90b:35cc:b0:3a5:147a:3b63 with SMTP id 98e67ed59e1d1-3ab3a33db36mr12329615a91.8.1791951890972; Tue, 13 Oct 2026 21:24:50 -0700 (PDT) X-Received: by 2002:a17:90b:35cc:b0:3a5:147a:3b63 with SMTP id 98e67ed59e1d1-3ab3a33db36mr12329579a91.8.1791951890405; Tue, 13 Oct 2026 21:24:50 -0700 (PDT) Message-ID: <252e86f2-9663-4ac7-a19e-6056b44e769b@oss.qualcomm.com> Date: Wed, 14 Oct 2026 12:24:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/11] cpufreq: Initialize kobj_type release callback in ondemand and conservative governors To: Ian Rogers , Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, zhongqiu.han@oss.qualcomm.com References: <20261013223946.1836757-1-irogers@google.com> <20261013223946.1836757-5-irogers@google.com> Content-Language: en-US From: Zhongqiu Han In-Reply-To: <20261013223946.1836757-5-irogers@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: 99P3Ue4wtp5Hzn7sr8smj9ZVeXDwhRk6 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDAxNyBTYWx0ZWRfX7DobZX0hAuie JiTiRmD5RnxUU2ULZ67OCCH9CFfLW6w1hqXt/tGNuwtgSwqjXYm03Soi4uSUY2kI0cUboKNxTk7 sc51GgaFdxYqdoyvLW5SC1JNKVCsi3E= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDAxNyBTYWx0ZWRfX9V9DU2yfwaAT 5VOPr59BthPlFQCnTYjJ9IVzX7ZUz1KiIXFEBWIm1d7+j6POoKjS2y3tE03sezKp+6fXlcyqugv wtsTGXVP3MRqjdMwsH0RJzIOUL+AsopqxyPvqJf797gDlAjnOzBIvXATT3LjJ7f2U2siPWiksEr 9CnfQliOHS0h/AADuenWQrcYz6s790oc/UrgqfTrRgC62P/jYTigSEDpjyYPh1uyHw/Up2Z+QZo wQkvNa5BzYXEzOmFaXEM6CyX599fW+3k65F3ZSXeybuZ+0McUi/Jg1Ricg06iCR/73kNU2ZABw9 0UpHxwpwQk/aoZLC6X2I01xdmukbWAtcIUGu69beo5NED0brBhCWMFu5a4sCWwWrVXlz95d0RMA v4jQGWkGYi6uKq51C+wrJAhGkmmHSmGM/O2fkt4M66vkK/VdizQ3hqCd7xfarLeu22R5iDainjo 2WQWxBZM6FS0j9OtPiw== X-Authority-Analysis: v=2.4 cv=cbJHPXDM c=1 sm=1 tr=0 ts=6acf0414 cx=c_pps a=JL+w9abYAAE89/QcEU+0QA==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=1XWaLZrsAAAA:8 a=Stt4M9KXtKJ5ZbChFzoA:9 a=QEXdDO2ut3YA:10 a=324X-CrmTo6CU4MGRt3R:22 X-Proofpoint-GUID: 99P3Ue4wtp5Hzn7sr8smj9ZVeXDwhRk6 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 lowpriorityscore=0 phishscore=0 adultscore=0 impostorscore=0 suspectscore=0 spamscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610080000 definitions=main-2610140017 X-purgate-ID: tlsNG-4011c0/1791951894-506CECFC-FD4478FE/0/0 X-purgate-type: clean X-purgate-size: 5044 Hi Ian, Thanks a lot for the patch. On 10/14/2026 6:39 AM, Ian Rogers wrote: > Export cpufreq_dbs_data_release() and set .kobj_type.release in the > ondemand and conservative governors so their gov_attr_set kobjects have > a valid release callback, matching cpufreq_ governor_dbs. Commit a85ee6401a47 ("cpufreq: governor: Use kobject release() method to free dbs_data") has already addressed the missing release callback issue(it adds the missing cpufreq_dbs_data_release() function.), with its Fixes tag pointing to c4435630361d. Besides, "matching cpufreq_ governor_dbs." seems to be a typo? > > This prepares for annotating struct kobj_type::release with > __require_explicit_initialization. It would be better to use "cpufreq: governor:" as the subject prefix. > > Fixes: c4435630361d ("cpufreq: governor: New sysfs show/store callbacks for governor tunables") Since a85ee6401a47 ("cpufreq: governor: Use kobject release() method to free dbs_data") has already fixed the missing release callback issue, current cpufreq patch 4/11 seems to only move the release callback initialization to the static initializer in preparation for 11/11. The same callback is already set at runtime in cpufreq_dbs_governor_init(), so there is no functional change or bug fix here. Should we drop the Fixes tag? So, at least for cpufreq, the issue described in the cover letter doesn't seem to exist, right? "Patches 2-10 fix 10 struct kobj_type definitions where dynamically allocated kobjects, ksets, or enclosing structures were either leaked on kobject_put() or freed prematurely before kobject release" > Assisted-by: Antigravity:gemini-3.1-pro > Signed-off-by: Ian Rogers > --- > drivers/cpufreq/cpufreq_conservative.c | 5 ++++- > drivers/cpufreq/cpufreq_governor.c | 3 ++- > drivers/cpufreq/cpufreq_governor.h | 1 + > drivers/cpufreq/cpufreq_ondemand.c | 5 ++++- > 4 files changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c > index 0b32ae28ec85..38c3bd5bf75a 100644 > --- a/drivers/cpufreq/cpufreq_conservative.c > +++ b/drivers/cpufreq/cpufreq_conservative.c > @@ -316,7 +316,10 @@ static void cs_limits(struct cpufreq_policy *policy) > > static struct dbs_governor cs_governor = { > .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"), > - .kobj_type = { .default_groups = cs_groups }, > + .kobj_type = { > + .release = cpufreq_dbs_data_release, > + .default_groups = cs_groups, > + }, Nit: In that case, may I know can we also remove the following runtime assignment from cpufreq_dbs_governor_init() as below: gov->kobj_type.release = cpufreq_dbs_data_release; > .gov_dbs_update = cs_dbs_update, > .alloc = cs_alloc, > .free = cs_free, > diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c > index 710d93ec89b5..97b64985927d 100644 > --- a/drivers/cpufreq/cpufreq_governor.c > +++ b/drivers/cpufreq/cpufreq_governor.c > @@ -404,7 +404,7 @@ static void free_policy_dbs_info(struct policy_dbs_info *policy_dbs, > gov->free(policy_dbs); > } > > -static void cpufreq_dbs_data_release(struct kobject *kobj) > +void cpufreq_dbs_data_release(struct kobject *kobj) > { > struct dbs_data *dbs_data = to_dbs_data(to_gov_attr_set(kobj)); > struct dbs_governor *gov = dbs_data->gov; > @@ -412,6 +412,7 @@ static void cpufreq_dbs_data_release(struct kobject *kobj) > gov->exit(dbs_data); > kfree(dbs_data); > } > +EXPORT_SYMBOL_GPL(cpufreq_dbs_data_release); > > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) > { > diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h > index 73b8ed7cfaae..c03d067f42eb 100644 > --- a/drivers/cpufreq/cpufreq_governor.h > +++ b/drivers/cpufreq/cpufreq_governor.h > @@ -148,6 +148,7 @@ static inline struct dbs_governor *dbs_governor_of(struct cpufreq_policy *policy > } > > /* Governor callback routines */ > +void cpufreq_dbs_data_release(struct kobject *kobj); > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy); > void cpufreq_dbs_governor_exit(struct cpufreq_policy *policy); > int cpufreq_dbs_governor_start(struct cpufreq_policy *policy); > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c > index 9942dbb38dae..7386d043c665 100644 > --- a/drivers/cpufreq/cpufreq_ondemand.c > +++ b/drivers/cpufreq/cpufreq_ondemand.c > @@ -374,7 +374,10 @@ static struct od_ops od_ops = { > > static struct dbs_governor od_dbs_gov = { > .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("ondemand"), > - .kobj_type = { .default_groups = od_groups }, > + .kobj_type = { > + .release = cpufreq_dbs_data_release, > + .default_groups = od_groups, > + }, > .gov_dbs_update = od_dbs_update, > .alloc = od_alloc, > .free = od_free, -- Thx and BRs, Zhongqiu Han From xen-devel-bounces@lists.xenproject.org Wed Oct 14 05:37:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 05:37:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448445.1664446 (Exim 4.92) (envelope-from ) id 1xGrfc-0002nl-TO; Wed, 14 Oct 2026 05:36:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448445.1664446; Wed, 14 Oct 2026 05: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 1xGrfc-0002ne-Pz; Wed, 14 Oct 2026 05:36:56 +0000 Received: by outflank-mailman (input) for mailman id 1448445; Wed, 14 Oct 2026 05:36:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGrfa-0002nX-HT for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 05:36:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGrfX-00HW0V-P7 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 07:36:51 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf14c8-bab6-0a2a0a5309dd-0a2a450ac172-44 for ; Wed, 14 Oct 2026 07:36:49 +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 6acf14f0-f2d2-0a2a450a0019-aceafc1f9d74-3 for ; Wed, 14 Oct 2026 07:36:49 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 8D84B407C1; Wed, 14 Oct 2026 05:36:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B60E01F000FF; Wed, 14 Oct 2026 05: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=korg header.d=linuxfoundation.org header.i="@linuxfoundation.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1791956207; bh=20IeJwlfbHOwAOqBybbPglj4DioVDbfCTggyOUmG6AM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Qh2L+lns+TC45tZ3ta2Bf3sHpQuD7ArGYrxTnkjJVsISJDd215cAUFX7buojC10XX PxZbUFGpn526urHl9iW1zA+jq+Q49VIAoWCaSVIjSYQA+Pdp0aIxZO/l3JMBTZ5a0o W38eNJtQMa+oY0XJ4+Fg38TXLC108OEL5jmzsnVI= Date: Wed, 14 Oct 2026 07:36:41 +0200 From: Greg Kroah-Hartman To: Ian Rogers Cc: "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release Message-ID: <2026101425-why-boring-4f2d@gregkh> References: <20261013223946.1836757-1-irogers@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261013223946.1836757-1-irogers@google.com> X-purgate-ID: tlsNG-4011c0/1791956209-5A5DBCFC-BD1C7D6D/0/0 X-purgate-type: clean X-purgate-size: 1795 On Tue, Oct 13, 2026 at 03:39:35PM -0700, Ian Rogers wrote: > Clang supports the 'require_explicit_initialization' attribute on struct > fields to enforce that the field is explicitly initialized when an > aggregate object is constructed, emitting -Wuninitialized-explicit-init > (enabled by default) if the field is omitted. > > Following discussion at the Linux Plumbers Conference [1], this series > introduces __require_explicit_initialization in > include/linux/compiler_attributes.h and applies it to > struct kobj_type::release. Cool, sorry I missed that talk. > As Documentation/core-api/kobject.rst notes: > "One important point cannot be overstated: every kobject must have a > release() method, and the kobject must persist (in a consistent state) > until that method is called. If these constraints are not met, the code > is flawed." > > Annotating struct kobj_type::release caught 30 struct kobj_type > definitions across the tree that omitted .release: > - Patches 2-10 fix 10 struct kobj_type definitions where dynamically > allocated kobjects, ksets, or enclosing structures were either leaked on > kobject_put() or freed prematurely before kobject release (risking a > use-after-free when CONFIG_DEBUG_KOBJECT_RELEASE=y). > - Patch 11 annotates struct kobj_type::release with > __require_explicit_initialization and explicitly sets .release = NULL > (with explanatory comments) on the remaining legacy struct kobj_type > definitions whose kobjects are static, per-CPU, or embedded in devm- or > parent-managed structures. Sounds great, but let's fix up the users before adding the attribute. Looks like some of these need another version so it might take a bit of time to get them all merged. thanks, greg k-h From xen-devel-bounces@lists.xenproject.org Wed Oct 14 06:16:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 06:16:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448456.1664478 (Exim 4.92) (envelope-from ) id 1xGsI9-0001S7-Ue; Wed, 14 Oct 2026 06:16:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448456.1664478; Wed, 14 Oct 2026 06:16: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 1xGsI9-0001S0-Rh; Wed, 14 Oct 2026 06:16:45 +0000 Received: by outflank-mailman (input) for mailman id 1448456; Wed, 14 Oct 2026 06:16:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGsI8-0001Ru-6v for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 06:16:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGsI7-00FUfQ-5q for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:16:43 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf1e33-2eae-0a2a0a5409dd-0a2a4508d438-36 for ; Wed, 14 Oct 2026 08:16:43 +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 6acf1e4a-f659-0a2a45080019-d1558032c476-3 for ; Wed, 14 Oct 2026 08:16:43 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a018792ab3so30410105e9.0 for ; Tue, 13 Oct 2026 23:16: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-4a190344032sm431262495e9.15.2026.10.13.23.16.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 23:16: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=1791958602; x=1792563402; 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=0c8IdlqqkdayqULr8G37+0RkkILvk5tcc5RQ6p3d6mA=; b=Nn3lAwizGUmVlStPOASh60yYkkE+7rs5mNoNPo0dlfe5G2YDhoyhgdCzeKHSHAxa8C x9O6ybkgJnQkmT8ITznwXGBVx+Kg1TsUhq7yZcTtVucqvz6ckzXl92hLRMngKGtvwrAg AnIxfAR3BPOF3qO3LDodRM6wq4HXkNLYTLNTu5T0r5xK0HyC6rCk1Wc47ai4P/vGSOia YUpoRpSqtD++OlL2Ohhv4luiCLRhkBgy4Md5mE09hfu4RbeHp1Dq05easXI8yQXMQZx+ aBNoKQX7y600cmN8BqU6W1jPLoM6s4gQwve/Z4YIkIBDdgGOOFBiZ2Tx2IbSdM7IA3gc 9KgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791958602; x=1792563402; 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=0c8IdlqqkdayqULr8G37+0RkkILvk5tcc5RQ6p3d6mA=; b=SrOcr4ekoGhkv+hoYmpfmf+xCP6iyuTwu5y6bAg4UtuRH0eC3BTqgibDNZtvMEE5UI iUqx9n3BXon5Gc8iji5D66n0/uC8nuOzbOIu91kHMlnhNtf34e+yOFjk/iIffWK/oLBU T6DllQFqLoleKoUeuJLycQgkP51Dgkb1kPC2TKlNsHk+EtrrdPq+TcLdX5L+0gSKHmN3 Ktl+KZT5zbs1zVY/KpdW+UJBeBZpzg4XAqYbmYWo7pJlW0yaSvKxMFrspPxINdQ0kP53 60fpS20ta9xNaqKWhq+NGh445Vxn7LPVnxnohSW8BKPwRpNwfJxY11AF9yeoOXteDSRE /0vA== X-Gm-Message-State: AFq9FYJT99SgCI4GSTGu6EpY2jEiY546vYl29kDOh8wbECvSGXOYpp0q 15E+7klHpU5dmZg7dnjXQ+T0p1EGp8/a4VO96dKZqkKIwvwOZ8jqZZdioHFKBsASYA== X-Gm-Gg: AYBFou0Z3DRV8tNIIcLAojK3UTaBKAgfAF3p3r9/kbQDKhtyyqUFS/U4+J41KP6hytH yWZc/nsqmRpuUZCG8YJ+u+5kOgPjPT5Kjq8/PBIhod7oQ88Pjs5FSTEcLlbzV8Iw449uSlBHAsz by1G/BQExycOXyfAc0YisLjdfJfnfOMBovhUlDb9KGdZCO+KSCWcZ5VaBql77G+nQmIoFJd1bFN wRSoam7QznnY8psybDBi6S3MxDdWG2XPJqUrYlym1X0ex3Tq7zXTcU3gCQPJ7DPwpeOy6DLj6Ks SymlQjNRwlGtBs+TfuUS/c1LVI4aTe7tuF6w3EBTeJhGZn5xJTIbxsyqwWKcOIm1e/vOF1GYofs 7Ksb/PLTX+lQg4rbvQFjhMgs3yyUnS29HpNnBR6WYYXRuCvIwquOyKxKzc2bw3ISKIxSUBsXWyB 9s/7px6EAhIiLBSA2ddVVm2ow3HDP1NieN2ILrIYk4Witmvou1/zIjeUK6NxjQ68gp39Y6NFvI6 dosL+AEu1L8G3E7kP3bLK7NVhEX6QZmgCFfDG1p8+hLXeWp7GPfoUp3eBheIP1yd1jOVREoBg== X-Received: by 2002:a05:600c:8218:b0:49f:ffdc:939d with SMTP id 5b1f17b1804b1-4a18e49d9f5mr281627095e9.9.1791958602413; Tue, 13 Oct 2026 23:16:42 -0700 (PDT) Message-ID: <6428c5da-0289-41ee-835c-ae5def434c52@suse.com> Date: Wed, 14 Oct 2026 08:16:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/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: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e58370003f66@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: 7bit X-purgate-ID: tlsNG-c1860d/1791958603-D4D7087B-8C2D511D/10/78276251493 X-purgate-type: spam X-purgate-size: 1726 On 13.10.2026 18:06, Oleksii Kurochko wrote: > On 10/5/26 4:53 PM, Baptiste Le Duc wrote: >>> 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. >>> >>> Register the vAPLIC range with the MMIO dispatch and emulate the accesses: >>> - reads and writes are masked with the domain's authorised interrupt >>> bitmap, so that a guest can neither observe nor affect interrupts it >>> does not own; >>> - target registers are shadowed per source, so that a guest reads back >>> what it wrote. The h/w register instead gets the hart index and guest >>> interrupt file of the pCPU the target vCPU's interrupt file lives on, >>> as the APLIC uses these fields directly to compute the MSI address. As >>> long as the target vCPU has no h/w guest interrupt file, only the >>> shadow copy is updated; >>> - only MSI delivery mode is emulated: target writes made while the >>> guest's domaincfg.DM is clear are ignored. >>> >>> Delegation (APLIC_SOURCECFG_D) is not yet supported. >>> >>> Co-developed-by: Romain Caritey >>> Signed-off-by: Oleksii Kurochko >> Co-developed-by: needs a matching Signed-off-by: from Romain right after >> it. > > I will contact Romain and ask for his Signed-off-by. Just to mention: Co-developed-by: can mean many things. We haven't been insisting on matching S-o-b before. Plus if there was an S-o-b, why would there want/need to be Co-developed-by: as well? Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 06:21:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 06:21:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448462.1664487 (Exim 4.92) (envelope-from ) id 1xGsMi-0003FX-FV; Wed, 14 Oct 2026 06:21:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448462.1664487; Wed, 14 Oct 2026 06:21: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 1xGsMi-0003FQ-CS; Wed, 14 Oct 2026 06:21:28 +0000 Received: by outflank-mailman (input) for mailman id 1448462; Wed, 14 Oct 2026 06:21:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGsMg-0003FK-DN for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 06:21:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGsMf-003Kz5-Q8 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:21:25 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf1f5b-e002-0a2a0a5209dd-0a2a450bc210-24 for ; Wed, 14 Oct 2026 08:21:25 +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 6acf1f65-b7e8-0a2a450b0019-d1558035c8a7-3 for ; Wed, 14 Oct 2026 08:21:25 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4956869750eso26399655e9.2 for ; Tue, 13 Oct 2026 23:21: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 5b1f17b1804b1-4a19f249692sm405268785e9.3.2026.10.13.23.21.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 23:21: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=1791958885; x=1792563685; 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=noYBIJiktNRyqfUuXS8gQRRDHhRezXm9D75uOzMy6mQ=; b=e15LNspGX8j2dCSgbN5lRPJriNth4hopbwUA/FxFl9cdAsBiwcrg9JM7m3qHx5ng5f 3YiEkhrA2GOsmI2VpOk8DHlZQWalWYw1BP/VyWZjsFJTwKsjr/CrgeGqvdxeUtWpD6Oc W3+14zftZhvdQNgkj/3pXwgLC9oog6DmeisEkdyUAkX31i+qjheioVq9qFMzzlCEXv4+ gjlU1tA8Ip1TjKkiItooMAASwT4VlhP5vkJpytAnNc10fivfCHkjlCy+9FyDMUZd8iRZ v7zbsPySgKrx3lFpBkIetEqAgU+2Jgc1lfj7jGcAxsw3hfNt9ZtFTv9rGVEkF8+9LllD 0frQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791958885; x=1792563685; 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=noYBIJiktNRyqfUuXS8gQRRDHhRezXm9D75uOzMy6mQ=; b=gbh9XhamGJXXOcCH9wVNrbhx8PM8R9xOpTWu2OcT0m+stDDT8bO3cXHjnWFj2zcja2 Al0M6iHNaT8f/dh2GGnULXDrdGXW7V/eEkiFMehZi2xPlG75Ne4uvcaq6G3rqBsh7tRM Sbb18wqpT9L+fP/08w550csSmBkqUso8rUY7qsDTgKe7Wg9qm+zrsK0i6BWSv1HA97lR d1bvConXwyI64fwwlHG8F0TdDZD1GC7Vhb5H95lm/PO59OUFpaKQTmuvNYpNP9JTcS8E B680778Qennk5oVFuZVfNAihC0Q2mS8q1s/DPxzPjTOaOwSdOkMeR9v2591CZZWO+9oH UAkg== X-Forwarded-Encrypted: i=1; AKwUvBxC1mZP1g7M9kuANpF3fMjK1jHONUMh9YY2X5Bj73axBSwlVpiWVOyfan0y6pVi3NKZRDqJGcT9Z1g=@lists.xenproject.org X-Gm-Message-State: AFq9FYKSYSe1gqAoIwpwQ6kIfk9dfxH65Xza4n7WRX3dKXte873kmQJ5 qfQ87ASlZlTwdCH/uEy0XtaCcOw4bbSFxYqnbGUmYz4s68ykDlWNLhuaaAA7b99wYg== X-Gm-Gg: AYBFou3A+aChnY2pK2OueBjd382pgrXCKlU16B9/fSPALuNZ/sMqtTAD7M9lYgMJ70I ypYlRv2CSdgY6FsjT+Si+7kyMIArC7lQi/+c8iKnzQ7/NahXff6w48rQyawj09EzDh8KjEh9FF1 xaxmgWnCvrOkSbzjvJIxn/csszByc28hEimnuisfx058kmeEAPe4yfGQaEvN5lbNePZX0EqUcal CKk4oAtjIZh9CcbQRkVKNwvZ4ZACfquB5Jk/Pn/h8R9jiVLtRoaaPAQC50k9qa2FyRm7tyRb/M5 tTj8Ihol3qUagp0dFgEavocECbC1hkFKcKfY+h8dVtZylaibPE5fCBJO4s+SDUrkaW+LxsBTKpA 5KXG/MDVyfrWubN6+xM9kioO3CUBpB3sOEZ76aeJZFp+LOFvQz20+DMasyrvYtUONoGnQNOvf16 VUi1XLFUx/a/G5CLbom0uARYPoia67/wIapqPC7BOndaxuWFnZtOVcu0iyuWTWA98ZsW7+RaZbN M21acHH38aPXrm2OhikyHlbkbyOd8VesbmkJG4/UyXiGeSxo4Um7fnDfdT9+DXO X-Received: by 2002:a05:600c:6207:b0:49f:ff73:9971 with SMTP id 5b1f17b1804b1-4a18e4aff66mr283175425e9.18.1791958885195; Tue, 13 Oct 2026 23:21:25 -0700 (PDT) Message-ID: Date: Wed, 14 Oct 2026 08:21:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ns16550: add "auto" to scan PCI only when the default base has no UART 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> <20261009202447.852414-1-benjamin@edera.io> <236fed46-c64f-4bfc-86a5-2147ae34d5d9@suse.com> <87bj8xs54e.fsf@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: <87bj8xs54e.fsf@edera.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1791958885-184CB9EA-3732733C/10/78276251493 X-purgate-type: spam X-purgate-size: 1925 On 13.10.2026 22:44, Benjamin Leggett wrote: > Jan Beulich writes: > >> On 09.10.2026 22:24, Benjamin Leggett wrote: >>> On some systems the console UART is at the legacy I/O port, and on >>> others, such as Amazon EC2 bare metal instances, the only UART is on >>> PCI. "com1=...,pci" finds the PCI UART, but it prefers any PCI serial >>> device to the legacy port, so it is not correct on a system that has >>> both. No option today says "use the legacy port, and scan PCI only if >>> it has no UART". A deployment that boots one command line on many >>> kinds of machine needs exactly that. >>> >>> Add "auto" as a value in the position. With it, Xen probes >>> the default base as usual. Only if check_existence() fails there does >>> it scan PCI, as "pci" does. Without "auto", nothing changes. >> >> I've always been considering check_existence() as somewhat fragile (it's >> not very difficult for it to yield a false positive, especially when >> HAS_IOPORTS=n), which means that I'm not really convinced it can (reliably) >> be used for the purpose here. > > How do you feel about making the retval for check_existence() work like so: > - 1: a UART answered the probe at io_base. > - 0: the probe ran, and no UART answered. > - -1: the function cannot probe this base, so it did not test it. > > and returning the -1 in cases that would spuriously return 1 and be > "false positives" today, so we don't try to probe something we > shouldn't? > > That at least covers the cases I can see, including the HAS_IOPORTS one. > > e.g. `if auto && -1` -> we bail with "can't probe" Makes sense, yet I wonder: Why did you raise the question here if 5 min later you send a new version of the patch anyway? And btw - that patch can't possibly be v1 anymore, yet it neither says which version it is, nor what has changed from the earlier version. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 06:46:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 06:46:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448469.1664501 (Exim 4.92) (envelope-from ) id 1xGskq-00073o-AT; Wed, 14 Oct 2026 06:46:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448469.1664501; Wed, 14 Oct 2026 06:46: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 1xGskq-00073h-6R; Wed, 14 Oct 2026 06:46:24 +0000 Received: by outflank-mailman (input) for mailman id 1448469; Wed, 14 Oct 2026 06:46:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGsko-00073Z-2k for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 06:46:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGskm-00Ayl9-BL for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:46:20 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf253a-2eae-0a2a0a5409dd-0a2a4509a8f0-12 for ; Wed, 14 Oct 2026 08:46:19 +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 6acf253b-be1a-0a2a45090019-d1558033e45b-3 for ; Wed, 14 Oct 2026 08:46:19 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a17baef589so4983075e9.0 for ; Tue, 13 Oct 2026 23:46: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-4a18bea1021sm386381625e9.10.2026.10.13.23.46.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2026 23:46: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:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1791960379; x=1792565179; 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=LqBOqFLs/eV4H9jqZg5HZ9qpSspn1YA3+yTesdco6z0=; b=DvrTTYcEjr5VCiNsA0PFrJLjld7ktYnt25+8bzpYFoiRx4mkpvzkBwJmDkD+ZciomW 7hpl0EYPoXGY4ygNKhVhUEmu66kEW2djVL5w9epCuay56BOeZDSvIw7yFQHRznETwE9R 7FS43UWr+2hniFH2znLIOC63Lgd7lrTY+T72VZmorIbsZtwHCicuu+v9J/X9ZO2xTm+/ mJnWrjGcwaXTwrpUpc1/ebuj5s9hGyc2C/Gt458aWJD7yGh+QlViOsd423ubhuyFI/+a 2/V7lK6GY+gZeHSJnlT8A7acEnggXl2giWRABG3c4sr8/T8QOF2pDoE2vmQmfCzWgB99 Axxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791960379; x=1792565179; 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=LqBOqFLs/eV4H9jqZg5HZ9qpSspn1YA3+yTesdco6z0=; b=ymszlTjEUl3SzXCUBslrwoakVD3a/9K/76myGqsG8mLh2iHv8UhLI1v6z9ufCT6W1B NyBQq2hPK3bdJmuoMxHP/ujliJxE9mB56tej0Dx5+QYpOM8NwwwMsS/5EiQbfmAHDreA Xrekmv+RuDpwHDmnsRMg8MY52ktkeyjWHLvkDm2hJy+DnVAMidY2C+uOD4mbcQupzBnN 4mddGPvgE0S2Nnmgt/g4h8lWZ2D8VOzqHPXpbQiG9vw4uBqiqv4nWaIVysKIzlQhDUbu 76tZwRur3MZX7nCJjzxPhQZhDcmKX8xRa/25EiSq60poy3fyValv64w6XAMI8jwoUY5d xK5w== X-Forwarded-Encrypted: i=1; AKwUvBxDJAJ2gclHYFLQW9lfSpWSLKgyNMdxtHYf3qI8KeqYLaMNzXcIgN9Mb5pQ56oo3YrcCMInBnztXA8=@lists.xenproject.org X-Gm-Message-State: AFq9FYKC1UBBvFlnOmI5pAihCOhaqzaJbejGc+myyLAlbxQiVmgh1b57 xEf2jEk3fZtumZeVl/CcReR4wEBngwpNEq2cFd0Zgs+FO8V69EL5vY257L/5p0N1Ow== X-Gm-Gg: AYBFou2USnFJnQmv+pUg0MFLE5BiEwSk9+5jJ/0v6jE8JFjcwVcryuG/SY8PMDto3Oy WjgtUEkk+7ZSZq8KnXwy79M//fLzmNi2wtvQojDkJEJP+Ya7lGRdINZWYEtbmmH5rBFvjI5J9PT ZL5IiPB0z+4/ycv7g8EJgY9nZ36WYxgZ5IN2YxwtihGop84Ui7W7JMgvVYb3iytYhbR6c2yLbed yflaBPjhviI9d2WyDq9g3WyYKTlm79fzYdj7pc2fhjM+7xwUO+i9WFsoRZhBA8Cs/IVC0ZHHqmF d1+L5llhI70XY31YCXJRgwkg2K3gFtsLx/J1ke4gXhcVj5pKMcAnEMyDWLXklFU/nD7WIzrRpTI wxjiL4beq4bi1/vqa3RWB87xb29syCoeDk2+5JEMDAZsebMzw4uUnz9aRGaOy2TPlRPmSgR8G+c 18c6iRLUKUjWdN0dbvRn3UwJ3DESbIsP4hKrGA8IlMhurSjaumNq2VKCNtrxP4tW9UzmNLIirn5 T3X77T3tWl0Zpcyr0sgq3JqRiA05Mbh0L36fJaiW7NDGBcdXnERM0Xpn1Mwfw== X-Received: by 2002:a05:600c:1549:b0:4a0:25c:8af2 with SMTP id 5b1f17b1804b1-4a18e491051mr328938875e9.17.1791960379395; Tue, 13 Oct 2026 23:46:19 -0700 (PDT) Message-ID: <4eb23457-0831-4cd1-af39-b4ad182f33f2@suse.com> Date: Wed, 14 Oct 2026 08:46:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ns16550: add "auto" to scan PCI only when the default base has no UART 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: <20261009202447.852414-1-benjamin@edera.io> <20261013204946.1980090-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: <20261013204946.1980090-1-benjamin@edera.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791960379-BE8D9034-DC01EC5D/10/78276251493 X-purgate-type: spam X-purgate-size: 4115 On 13.10.2026 22:49, Benjamin Leggett wrote: > @@ -737,9 +739,9 @@ static int __init check_existence(struct ns16550 *uart) > * if we're getting MMIO UARTs, the arch code knows what it's doing. > */ > if ( uart->io_base >= 0x10000 ) > - return 1; > + return -1; > #else > - return 1; /* Everything is MMIO */ > + return -1; /* Everything is MMIO */ > #endif While this addresses my main concern towards false positives, the rest of this function is still weak enough that I'm unconvinced it can be used for the new purpose here. I wonder what others think. > @@ -1785,6 +1801,7 @@ static void __init ns16550_parse_port_config( > { > char com_console_options[128]; > char *str; > + int present; > > /* No user-specified configuration? */ > if ( (conf == NULL) || (*conf == '\0') ) > @@ -1818,8 +1835,29 @@ static void __init ns16550_parse_port_config( > PARSE_ERR("%d stop bits are unsupported.", uart->stop_bits); > 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"); > + present = check_existence(uart); > +#ifdef CONFIG_HAS_PCI > + if ( uart->pci_fallback && present < 0 ) > + PARSE_ERR("\"auto\" needs a base that can be probed"); This, imo, is a misleading / unhelpful message. "auto" sits in the place where a base would be specified, i.e. suggesting that a base is needed when auto- detection was requested is odd. Furthermore, it is an implementation shortcoming that devices accessed via MMIO aren't probed. Maybe "\"auto\" doesn't cope with MMIO-based devices" or some such? Yet then - this isn't about the to-be-auto-probed device anyway, it's about the data that was put in by early arch startup code. > +#endif > + if ( !present ) > + { > +#ifdef CONFIG_HAS_PCI > + if ( uart->pci_fallback ) > + pci_uart_config(uart, 1 /* skip AMT */, uart - ns16550_com); > + > + /* > + * A failed scan puts back the rejected base, and check_existence() > + * can't test an MMIO BAR, so only ->param says that a device was > + * found. > + */ > + if ( uart->pci_fallback && uart->param && check_existence(uart) ) Don't you want to check for > 0 here? Yet then the comment looks to suggest you deliberately want to accept -1 here as well. (The comment wants further adjustment anyway, as "... only ->param says ..." contradicts your use of check_existence().) > + printk("ns16550: com%zd: no UART at default base, using %pp\n", > + uart - ns16550_com + 1, &uart->pci_device); > + else > +#endif > + PARSE_ERR("16550-compatible serial UART not present"); > + } > > /* Register with generic serial driver. */ > serial_register_uart(uart - ns16550_com, &ns16550_driver, uart); I think this wants doing with just a single #ifdef, it at all possible. Not having actually tried it in practice (and leaving aside the other questions above), something like present = check_existence(uart); #ifdef CONFIG_HAS_PCI if ( present <= 0 && uart->pci_fallback ) { if ( present < 0 ) PARSE_ERR("\"auto\" needs a base that can be probed"); else { pci_uart_config(uart, 1 /* skip AMT */, uart - ns16550_com); /* * A failed scan puts back the rejected base, and check_existence() * can't test an MMIO BAR, so only ->param says that a device was * found. */ if ( uart->param && check_existence(uart) ) { printk("ns16550: com%zd: no UART at default base, using %pp\n", uart - ns16550_com + 1, &uart->pci_device); present = 1; } } } #endif if ( !present ) PARSE_ERR("16550-compatible serial UART not present"); may do. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 07:01:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 07:01:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448477.1664510 (Exim 4.92) (envelope-from ) id 1xGsyx-0002Tj-Hh; Wed, 14 Oct 2026 07:00:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448477.1664510; Wed, 14 Oct 2026 07: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 1xGsyx-0002Tc-EF; Wed, 14 Oct 2026 07:00:59 +0000 Received: by outflank-mailman (input) for mailman id 1448477; Wed, 14 Oct 2026 07:00:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGsyw-0002TW-PV for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 07:00:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGsyv-004IBs-SF for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:00:57 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf28a9-8faa-0a2a0a5109dd-0a2a450bb65e-4 for ; Wed, 14 Oct 2026 09:00:57 +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 6acf28a9-b7e8-0a2a450b0019-d1558031b597-3 for ; Wed, 14 Oct 2026 09:00:57 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a180fbeef5so33649355e9.1 for ; Wed, 14 Oct 2026 00:00: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-4a18bf135fasm373082645e9.5.2026.10.14.00.00.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 00:00: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=1791961257; x=1792566057; 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=+cHPWvU8QOywGgl3wB33A3xCPcasAradKrbFRfKRYVU=; b=gcyDBgNw7Fc7IUgUZOj8zvx42TYMsTlNF1YFMI7POUAkCk7LA7hmj9vZpNZ4+//pD1 QH0QTLGoVHaOdjvaFT5PjNYH8f2i8ZP3bZICnEQzyf3BuGDv8sSOA73lfl/wCnWWfesA HGZAuNnovhSnSTHjXRtIJ7fqAmSWXYjFPLj2zP6zuy247O1hHq1uTRIyxF89OiH4fUgv 5wLgMLJsTpCdLj2y/JLP09RYDMJVPw0fDmtJbmURNznFiKqjHsBvYfjeeZaLm1W0PjuA AN9cX8LlKyvOt4EbTFmLQdJ3vI7ojPTQ7qTgyNz4+jTZAJ8U7+RFWPUUOZnHbUphW9Ws gP7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791961257; x=1792566057; 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=+cHPWvU8QOywGgl3wB33A3xCPcasAradKrbFRfKRYVU=; b=cGzfkKtW3xNDfm4yQ5wOiqdXQ7O9vZe6q0XaY6/NiaALIeeZeeC2nkNKqqgOenDvLW qSrI2pI65J12bArASEgAausRbaNNG6MXszj8LZ8P/09EEkz5+WfTfJwQbd5l/IFUHATN ka/TBKRsp7bwKxOUGNNfmLbR2xrqColIHay+30k5Rr8vJt+qzPd5MAz/KWd/n7fwefT/ 0lVds90AZrutsKGlgOGdFUriAmLYEYnpspe1AELD8f34kyU87lcdMLnrvX4O4Q29OiF/ tNgjJBlCAW7TpmzeRiPyhV1WweF+s76DXbG1CzZp8wVdp2ZC64VWmEKfTI5HRGT6DSxw vhrA== X-Forwarded-Encrypted: i=1; AKwUvByOHLXAoK/AlSk4uEAE1++fuUKp3XiHn+qdq9B5SEV/HCwh/PM8NltJZyWOTWXSCcYkCA1G7eSNKHk=@lists.xenproject.org X-Gm-Message-State: AFq9FYKd8a4l+pYiV9ExpKT+brbmaJv6NsLLE0xK3cf8rgkalWaKhtSd Z2xpfhIPNQBPGiLcaph8gs/EO6kCYoEHT69h+/MYfbw/ki54xTol0spj6knx+Aj58g== X-Gm-Gg: AYBFou1jfiTrP1e4emfG9zDKfbHeEt3lhqTn4P4sBUw2Rz0pY46jQB+pZii8aWJjTLT XwbUsZd6ac+h3oMjC7dFz3dnFh+qk78In0xnyRh4bVpRV//yW3DyHvtxwu/KoJ2qewnJ9lW3Hc5 4J5k1FqVimSuJdt0esOeV9vlrGi0eXE5ReDpVDcFTrlkr4G2Hr2+ofgau4xsPgrinmu9ywdX70K C60S+BaJT3aC4iUN1s8YCOWMTffumnOhDdy/YVzfqrrIHzLhNrb1/V+t78yAd4+MmdNpQLXqMRS rBzYgifus09UBefYeoufpYiZJrx+LKCpVaPYzOHLr35m3vykVutWAoyou3DPJtrmCwhDfkt3+Qj mmRC0J5OrdDQJ+1c0nhFElW6AR5erBMUlDf7phGbNLsoVWnqHgM59vYul6VfeTrjfi3cQeqX5ec aDNjYwQeWYosXY/1jx5djfWVY5N+8xdkjPpG4uX6VK5/m1E5qU7382SirJ6FuuReNMJ3ggt0Y25 CTsPEDB6BCloVZg0dZQ6Ma8Hq+v1dleLi6LmxGlonrF9k7SKNevdmVZub6LGg== X-Received: by 2002:a05:600c:4fcb:b0:4a1:811c:8083 with SMTP id 5b1f17b1804b1-4a18e4c3600mr292058985e9.33.1791961254025; Wed, 14 Oct 2026 00:00:54 -0700 (PDT) Message-ID: <05f2677a-977d-410f-a150-e24981faea32@suse.com> Date: Wed, 14 Oct 2026 09:00:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drivers/char: Add several newer PCI IDs for Intel LPSS To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 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: <20261013190735.365024-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: <20261013190735.365024-1-marmarek@invisiblethingslab.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1791961257-1A8D99EA-CDC70FB7/10/78276251493 X-purgate-type: spam X-purgate-size: 1155 On 13.10.2026 21:07, Marek Marczykowski-Górecki wrote: > Include PCI IDs of UART ports on Intel RPL - PTL. Based on Linux driver > and hwdata, they all share the same parameters. > > Signed-off-by: Marek Marczykowski-Górecki Acked-by: Jan Beulich albeit imo better with the subject prefix changed to drivers/ns16550 or just ns16550. > --- > I tested it on MTL, but given Linux driver handles them uniformly, I > assume others work too. > > The list gets quite long, would it be preferred to have a macro to > reduce (at least similar) entries to one-liners? In Linux driver it > looks this way: > /* MTL-P */ > { PCI_VDEVICE(INTEL, 0x7e25), .driver_data = (kernel_ulong_t)&bxt_uart_info }, > { PCI_VDEVICE(INTEL, 0x7e26), .driver_data = (kernel_ulong_t)&bxt_uart_info }, > ... Yes, with a bloat like this it may be nice to get volume shrunk down. In a follow-on patch, perhaps. I also notice the Linux driver has uses of bxt_uart_info beyond the set we have plus what is being added here (not the least, considering the identifier, BXT itself). Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 07:15:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 07:15:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448486.1664522 (Exim 4.92) (envelope-from ) id 1xGtCb-00052t-Mw; Wed, 14 Oct 2026 07:15:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448486.1664522; Wed, 14 Oct 2026 07:15: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 1xGtCb-00052l-Jo; Wed, 14 Oct 2026 07:15:05 +0000 Received: by outflank-mailman (input) for mailman id 1448486; Wed, 14 Oct 2026 07:15:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGtCa-00052f-Gh for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 07:15:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGtCZ-00C7Sb-Ha for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:15:03 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf2be4-2eae-0a2a0a5409dd-0a2a4501e748-48 for ; Wed, 14 Oct 2026 09:15:03 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf2bf7-5984-0a2a45010019-d155dd31d452-3 for ; Wed, 14 Oct 2026 09:15:03 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48c02782159so2252464f8f.0 for ; Wed, 14 Oct 2026 00:15: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-48de72c7e36sm4538867f8f.37.2026.10.14.00.15.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 00:15: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=1791962103; x=1792566903; 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=bxNzIOA0qyzKYDaLspqJVplnLUKtqE5X6BfHkmcsHtQ=; b=OgZLMl1jMn2bM7RVnwdzsQ9jaH0XvSA+V3M5Hjdy0yTNkD7u05DgF/1+aG9jg78m7v sU8CdPA8IUue18wPtbL1BBESM8tHMDMNLOhh6+Ps2YsuAwBFyssVR3BXxfHWTnt4YeiQ gz5Df5KikZ316PFLshKNMPkgMRMqg3v4L6VJqTUd7f1qectTMNHR2h8EAJPFXVkzYidi eDt25JmZMpSZsS/r12SW3bNELX2syLFUjMmVGF28bHGM++YpUIy1S2BWRsvoWC93+47c vPBDwYXeAppW9dWXGuYeiH4VpH1APKO4cijkIPl+/QJN+FgEkTO6UH9xAV+p7VYKMeiV 7RKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791962103; x=1792566903; 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=bxNzIOA0qyzKYDaLspqJVplnLUKtqE5X6BfHkmcsHtQ=; b=2AiVzAw8GYRN2wNTqBQZdmXkdp5HKxBWmNXngXShXaZdNF5/+bG+NsmDQiJ0mj6f4b 4k6o4qxzzMsD9+gzjJZSA91w/hGvs4xEHBsgtXONs1ukBKmbPH7TFD5SsLGkiTUWfubH 8ks97lq8FO90dsVXdXbyI+IcsfW2hbgPNNiIqk4lkV/NkiCgoF8zhKE9FzyD3xnhu6IP pZFH32YnVDlrlDF8TSy1loOhj0klelGLMPZaGPH+atKq0p1cgMQ1lq00xzcYhhsxErPM CHDDKIAoHEBowtvt400ZxhAGYKvj5YiTxdBcyTAfI8Sdb4yGb4HwHSkXUOj/DzBCnDhY hGTA== X-Forwarded-Encrypted: i=1; AKwUvBxucwYu9Qa1msiZqphRmIeW/EtJPgRRN/qbXyBtp/sB9RuxVjxb1isdIWIb2kcFs56vUmn3Lj6BotI=@lists.xenproject.org X-Gm-Message-State: AFq9FYJJXp18WZaHy8cSnxNxLZTeQAn7SXoqU7UwHuWgDnygWbV4J0fT m9OBTo5EF5Y/Q9+ptywCQuGLJl0GJg5KUXK+nsUKAaKuHQxXHriKp02LPuyjeAlbwQ== X-Gm-Gg: AYBFou3PySMUKTlY02ceprH3BO6OPS90L1IhRL+sH5ejeJYxudIWgmB7wDE7mlFH7Sv /VTkNACDluIQa+MbZphNFNREVK8gRGYnOgqNodA6eOa4+jpSEqapzGUvoE2mtBXLaK1uJFGOlQb ZTt+m+kpj7Zq41X2g5fFCwlFgrA0p0F0oJC/URiN0HRNSpC+lFmlXSxkevwnB0Mej8HFJKmD26U QgcrSjmUQPHjN8X05Uh9PM6n7LhmDOBrIKD44nEjSbFzCoLGiqpgHjLAuyIL8u2EF9+HbrzdzpT 2S/03ZhmYw8qWUGSvj9VkIymmETOvIfHuU2g18/S9sQViX0uj37WH9D5UMBI5LT+6kr1fl9id71 bRzLMxyHOTalXWf1awlH+KR6s8c9BNIhZEg55vMfQ5vitXtEHJ7rCENonzo6yslxJocTfFfLzzI tTWmwWQz1z9ICb7vq4URPzIp0sh2OpXNlYEYch6mEs7qWMH3hI5VgRtRlYv1zOuTchyJ3SMJGNS pBfvTHBe2v/fxUZS/ARw0zmTcI/1d8GKBgCFm+3h140dyahMX3mkkFjY2qxQQ== X-Received: by 2002:a5d:5f50:0:b0:48b:50e:5dc6 with SMTP id ffacd0b85a97d-48dbacda8edmr31931882f8f.34.1791962102667; Wed, 14 Oct 2026 00:15:02 -0700 (PDT) Message-ID: <2117afc1-dd75-42e2-80d6-f87b06902554@suse.com> Date: Wed, 14 Oct 2026 09:15:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/hvm: Fix UB on defensive default case in handle_pio() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261013164404.361893-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: <20261013164404.361893-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1791962103-BC95A757-CAFD034D/10/78276251493 X-purgate-type: spam X-purgate-size: 434 On 13.10.2026 18:43, Alejandro Vallejo wrote: > There's a potential 32bit left-shift (when size is 4) to a 32bit value, > which would trigger UB and tickle UBSAN the wrong way. Shifting right an > all-ones mask fixes the issue. > > Fixes: 4609fc8eb04e ("x86/hvm: Improve error information in handle_pio()") > Signed-off-by: Alejandro Vallejo Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Oct 14 07:27:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 07:27:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448493.1664530 (Exim 4.92) (envelope-from ) id 1xGtOb-0007Il-Ns; Wed, 14 Oct 2026 07:27:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448493.1664530; Wed, 14 Oct 2026 07:27: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 1xGtOb-0007Ie-LG; Wed, 14 Oct 2026 07:27:29 +0000 Received: by outflank-mailman (input) for mailman id 1448493; Wed, 14 Oct 2026 07:27:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGtOa-0007IY-0N for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 07:27:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGtOZ-00B7RP-DN for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:27:27 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf2ed8-e002-0a2a0a5209dd-0a2a4505a39a-12 for ; Wed, 14 Oct 2026 09:27:26 +0200 Received: from [40.93.198.36] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf2edd-4cb1-0a2a45050019-285dc62482bf-3 for ; Wed, 14 Oct 2026 09:27:26 +0200 Received: from PH7PR12MB5685.namprd12.prod.outlook.com (2603:10b6:510:13c::22) by CY1PR12MB9557.namprd12.prod.outlook.com (2603:10b6:930:fe::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Wed, 14 Oct 2026 07:27:18 +0000 Received: from PH7PR12MB5685.namprd12.prod.outlook.com ([fe80::ce69:cfae:774d:a65c]) by PH7PR12MB5685.namprd12.prod.outlook.com ([fe80::ce69:cfae:774d:a65c%3]) with mapi id 15.21.0522.011; Wed, 14 Oct 2026 07:27: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=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=FISzAHiyNbFXskWG/Ho8O80P7g35WBz16PT4/am950CgFDmdHqgRRvhedZDNRhdkYv28T23UNg7oXsXvjpXFeFp56GimBLpvTn4F2t7JrNqMlcEQOApIcYSrN2zMkTHHCb8o+c40x4gKRMhpYmulRN8r/S2c5IGmG0MBLZJUFlhB5IyoLXl9Q1zAsh0RqRYlS5FJf9M50LfF5gp+1qVW14xgWX0R/E0RD0qGQSVh7Q9A6tOBbmBjHUFFKjUDSEBS0xdEBIZ9GY+++HC+2ZtvbpA36+/xNpSZGgyITkb7fvjKDvybzsVus4C/MprWBKxSDUngK1D1Lj5G6DA9WTVB3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cdegQbfVYb7rxAdhJuisV8UafP7vtVKjc+m8LO/6j2g=; b=pu6QGJoh/56Lb1POVcPzfnJEIfJr0wus/q0S8WmhKbkN+62J+KhwPPqnJ3LGAJIEIwJlg0vGUobIS5NJmh2N9TOW2ue9hyn2Z674roWq0B8bn5xrxrKwdtOwt6yrIy3qVWzIM2L0xyv0D11hFVtOwW5T0wNsv7FnFlbxGWFbEVsXa4pA8Ss4XiPwhfVRU7JV0rkEUvPehLFtlBVzSiDmG6zDbRIES3uf7xFSgqZIjCw6koTdb0CnlrZbg4Xjf/NAr1aka8Zo6bpBFjEohmRxqtG7eXO00vkZyY5VlG1zpyZt+/Rr7GNwt5/qewZ0MODMA/1Inc9cOcxB8NoTZQGVhQ== 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=cdegQbfVYb7rxAdhJuisV8UafP7vtVKjc+m8LO/6j2g=; b=sAFOQ5PXqZaWSun2nl3bjv0V6n8jV+j3ysNCff7Myus6Ss6iIUMhY0DRMHPlKq3NgGbEG47gVVAELNy3xE5OF7lBSYxBHiYVpOzAGhmV1kN71ZOZwF6s2sbOcNRvN6hRTDq8BkIfKO+Rg0fxN3CQnVR8k6mQsDkEfyqHVZdf8m0= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <4154bb7d-c97a-402b-979a-0f49d7a02c53@amd.com> Date: Wed, 14 Oct 2026 09:27:06 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/11] Compiler Attributes: Add __require_explicit_initialization macro To: Ian Rogers , Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor Cc: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20261013223946.1836757-1-irogers@google.com> <20261013223946.1836757-2-irogers@google.com> Content-Language: en-US From: =?UTF-8?Q?Christian_K=C3=B6nig?= In-Reply-To: <20261013223946.1836757-2-irogers@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0327.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:eb::11) To PH7PR12MB5685.namprd12.prod.outlook.com (2603:10b6:510:13c::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH7PR12MB5685:EE_|CY1PR12MB9557:EE_ X-MS-Office365-Filtering-Correlation-Id: 41e289b2-7011-4388-a159-08df29c493bc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7416014|23010399003|56012099006|11063799006|4143699003|261009221227099003|261009223027099003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: BdC3OWiE215+NFZJKX+JRn/yJtBkqqprUiCnha4t5KMYNF49oIdBwAYRi5wxOcsQ1sWQH+Qhcl4te21euxRgP1H6RqN89sZG6HVaDYD4lL2fu0hEDDbHTekwYfAypN6i+nPVzQSsA6X+Vtoo9I9xRUPkm+gLkaxVm9rWOVoTjJY23USSMb8FH4Ooxjzf2etLU/BBQ8fUb1nSJ0K/P0jWBishZQfDFNNz5EjjJg9ctul7zw3+GPOw8GGQGeZiet1XePOj8QRwfzr9frlFox1TqNtjDFhJz284KRYInuJl0MYYQMF40w4dlgakZ49HD3bzByLpck+pm8LlBt15XNve8CrL0vK/dRKYBKTOtaF8Y/XTGyslLZTFAiTri3kSAciGuzY54FOobZa75FW0gxOIAYoyPQnslbORp0TeD8ylPOzXP1Dq49CH890BlZhnce0wHsE4pMmwodrs6LruRZindtAYO8j0CkvFQZ2/zfaBcZn9ZaJAj7xK9hmmss4PHSWvxQNg7vS/mhu2GCWQO9mZQ/9EAWJndH7EUbtk8PV+tNL5eVdIqjwXb7hOC/clRHNoZHBgWsN4CgMLZdtLT4egUf6pLiIRKfWSgWPboNWevc5zXrv2F0dsvwll6dIys/yY X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5685.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014)(23010399003)(56012099006)(11063799006)(4143699003)(261009221227099003)(261009223027099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q1I0S1dyeTBoWFhsbzNHS3RoVVNISG44WThsVENqZEF6WlpDWlp3WmZkY3hY?= =?utf-8?B?cUhHTmN1bXg1VlM2QWFyYnVEaUNqN3lzZzFWVUNyM1NUZXlxTTNrR3U5bEZa?= =?utf-8?B?a2d5YmphWEwvQzN4enNyWi9EQkVuVzltYjhEdXBqbEFWRGh6ZmFqTlBJeExC?= =?utf-8?B?RWo1WmRhQldMSkNKSHF1MVEzbm1oQmV0dVhDMk9vN2xqeEw4OGdYa1pNMlpI?= =?utf-8?B?MkgzSjZwYkhUSHE2QkNMYkhFWFladWxmZFY0MllLUllUbmRlaGhWemJ6cXk1?= =?utf-8?B?K01FRzQwOUJsTnNIRXB6S1ZtMjhyb1RJZVRKUnNkbXVPL2FNaVpKQncydVox?= =?utf-8?B?U1lWbG1IY1V1d1BSSEUwZHUycW9KblhQL2pLUjgyQTJjU29nYTU1VUlvbzhx?= =?utf-8?B?RHA5eHErWEI5b0xoWk9jSE81M296QlozSnBkYnB5dTVqU0c0TzczbUM2MFNr?= =?utf-8?B?bUZETjJiTDM5c2p1WWtTbHJlaXQrb2lUYVdJZEgrc29MRllzbGhzNlJDMWIv?= =?utf-8?B?T3RJQVhjUFE0dVRSWE9NenlMWjVhdVlSaWRGdlJyS0o5RnFhbmxCWUpmbFN4?= =?utf-8?B?bGlDTEJxQ1gweWJrdm5OdEJqT2tzejlRVlArdzI5bks2MU5JTmRxS3pQY2pi?= =?utf-8?B?YndQRHhSNDJjWmZkYUlkemxha0pxSVFocTlxMzhMSVE2dFdOOGRocTNTTDE1?= =?utf-8?B?eVlzWEpLaHVTdWtjeE83eGQwY01KeFdvSVNwVG1pWnpOWUhnN1lLUG4vendI?= =?utf-8?B?bWFRSEM1UWpJd3JwQm05M3FLRFBkdjFuZTN5ZXFpTjJ4eEpzb2Y2K3ExVThX?= =?utf-8?B?eS9OVzFWQ3I1T3BrbmpYeFNFVWMwQk55cVhnQWNJQUN2SzBpK2owTVM5RHdn?= =?utf-8?B?KzVRbjYwc1VQQzlxRWRzVXAwWk1kOEh5R2dYSmNtUlFaOGRTdGRpemZjMEto?= =?utf-8?B?UHI4bzV6NE1FdFdUMnBjZDJrVWIwb3ZLSWw5c2tiVWpvWnFHcXp1dE15c25q?= =?utf-8?B?RVV1NlNRY2N1b3hndUNyTmM2YlVyOHZiVVZtT1o3ckNHSW1PcVVtS0p0dEI2?= =?utf-8?B?a0VxWWQzc2czNlpDZTFZay83emgvejZoclVJK2k2Rnhpa0FOMXQxam84OUwr?= =?utf-8?B?ZUJyNmxDMXNJTTEvT1hHdDRVUjhHT1ZmblBTVzY0aVVadFpFSFJrN0JIRDVY?= =?utf-8?B?ZCsrMW9KRmZVTXcwK3hucVNpSFAxTDh3cllwV0lhR2wrR0xNWGY2bkFIeTF0?= =?utf-8?B?MjVlajA2VllCSUowcGNQa1QxcmhFL1FlNGptQThjelUwTmRwaUVoNTFoYWJv?= =?utf-8?B?WUdtaXlKSE9jd3J2eVhkRFVsSFZORkhWZ2J1enZ5T3FMZldNYWk0YS9tQllE?= =?utf-8?B?ZkdibW4yZ1VGWVh0K3p2Q3E3RVBndll3RWNrN2QvUEt5ZFcyU3RKWVZWbHZv?= =?utf-8?B?VS9iVDA1VTRTVkFjWkEzVTU1VzFINXJWTW1aUnp0Y1gxSnNibHpZSUtzYkhm?= =?utf-8?B?eGkrcnhWZ21sbWcrU3E2S1dsZkFhVGxmY1YvU29kbnFBUlRXUVh3UkhXbDB2?= =?utf-8?B?bVpFWUdrY2t3dTFJbE5qRmFjTVplZncreXNNQ3lIZitWQmdrdVk1QytpZVRF?= =?utf-8?B?MVptMXlxbERhb3pQUk4zcTBDZU5yL091bmFvbDlnQ1JnNDhUaE1FSWw2NU5Y?= =?utf-8?B?bFV0QTliYmlMdTZoWU9ZUnBvK242aERMSnlKVTdjZGwwTUVUeHVmTUJRczZt?= =?utf-8?B?ejVReSt1UUEzaXFMdmZHOWpHQmdkNzZDdzRpUkRLSml5UitoWS9MNGJpMllo?= =?utf-8?B?S05SUm1WUVNlM2oxdEJvUDdYYkw4cVVOZEFsSFp1NElRWjJlb2hiRXlFVXZm?= =?utf-8?B?S3hJK2RHUmpWMHBjZmNQNGFyWURERzc4dDhqYlBNcDZzSXVzZTdKbkRYLytp?= =?utf-8?B?bjE1U3pYNFRxQ3pCeURKdTlKYjlDMjdFcVZ1MmRXYWFYSGNjc202NjNvaFc5?= =?utf-8?B?bWhwMFgwZFFvalcvK29tRXN1ZTRwUUprMlludG84VWFYNE9manVFTlRLdG95?= =?utf-8?B?UlVRbGZzeE8yazFjcjRXTHZiK1hwSVAxV3RFVGFsYlIvUHpjODR3WW9WVGFT?= =?utf-8?B?a0xJcGpSdXBpSFdtajBOUVc5NTV5MElDSUpnMEpOalFUbnMrcElYeHVEcUlh?= =?utf-8?B?V0NEenIyLzJtUFVrcHJiN2VIQW9zK3RLcWVpRWo4ejltVW9oWE8rU2xuVjIv?= =?utf-8?B?N1hUZUNFTDU1N01SUnhyV1BXZ1JGallORXRRZ3NocUFkbE9zVkcwNGNIMVND?= =?utf-8?Q?hrqF6gI8LVp4KZy4bx?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41e289b2-7011-4388-a159-08df29c493bc X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5685.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 07:27:18.1391 (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: EPCX3t4rIs/vo7QVV+VbzZJKjMFIcuzUma/vpFm4ZHQP4jkDSIXRKWx/DcFcaCPG X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9557 X-purgate-ID: tlsNG-c201ff/1791962846-F54AC2A1-B94A9B66/0/0 X-purgate-type: clean X-purgate-size: 4470 On 10/14/26 00:39, Ian Rogers wrote: > Clang supports the 'require_explicit_initialization' attribute on struct > fields to indicate that a field must be initialized explicitly by the > user when the object is constructed. When an aggregate initializer or > uninitialized variable omits an annotated field, Clang emits a > -Wuninitialized-explicit-init warning (enabled by default). > > Add the __require_explicit_initialization macro to > include/linux/compiler_attributes.h (which is included by > include/linux/compiler_types.h and include/linux/compiler.h) so kernel > structs with error-prone initialization (such as mandatory callbacks or > cleanup handlers) can enforce explicit initialization at compile time, > as discussed at the Linux Plumbers Conference. Oh yes please! That is so nice to have, I have like halve a dozen use cases for this in the stuff I'm maintaining just of hand :D I'm not an expert for compiler interaction so I can't really review this patch, but please leave me a note when that is merged. Thanks a lot for that, Christian. > > Also teach Sphinx (Documentation/conf.py), kernel-doc > (tools/lib/python/kdoc/xforms_lists.py), and checkpatch.pl about the new > attribute macro. > > Link: https://lpc.events/event/20/contributions/2392/ > Assisted-by: Antigravity:gemini-3.1-pro > Signed-off-by: Ian Rogers > --- > Documentation/conf.py | 1 + > include/linux/compiler_attributes.h | 11 +++++++++++ > scripts/checkpatch.pl | 1 + > tools/lib/python/kdoc/xforms_lists.py | 1 + > 4 files changed, 14 insertions(+) > > diff --git a/Documentation/conf.py b/Documentation/conf.py > index 5ab26ce89daf..3e5cb9ca0970 100644 > --- a/Documentation/conf.py > +++ b/Documentation/conf.py > @@ -203,6 +203,7 @@ c_id_attributes = [ > "__noreturn", > "__packed", > "__pure", > + "__require_explicit_initialization", > "__section", > "__always_unused", > "__maybe_unused", > diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h > index 476c4c560d17..60522ab80c5a 100644 > --- a/include/linux/compiler_attributes.h > +++ b/include/linux/compiler_attributes.h > @@ -322,6 +322,17 @@ > */ > #define __pure __attribute__((__pure__)) > > +/* > + * Optional: not supported by gcc > + * > + * clang: https://clang.llvm.org/docs/AttributeReference.html#require-explicit-initialization > + */ > +#if __has_attribute(__require_explicit_initialization__) > +# define __require_explicit_initialization __attribute__((__require_explicit_initialization__)) > +#else > +# define __require_explicit_initialization > +#endif > + > /* > * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-section-function-attribute > * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-section-variable-attribute > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl > index 8a7787d228a6..4a3ae6b0100a 100755 > --- a/scripts/checkpatch.pl > +++ b/scripts/checkpatch.pl > @@ -6871,6 +6871,7 @@ sub process { > "noreturn" => "__noreturn", > "packed" => "__packed", > "pure" => "__pure", > + "require_explicit_initialization" => "__require_explicit_initialization", > "section" => "__section", > "used" => "__used", > "weak" => "__weak" > diff --git a/tools/lib/python/kdoc/xforms_lists.py b/tools/lib/python/kdoc/xforms_lists.py > index e3dda2fe8a53..32066fbbe763 100644 > --- a/tools/lib/python/kdoc/xforms_lists.py > +++ b/tools/lib/python/kdoc/xforms_lists.py > @@ -36,6 +36,7 @@ class CTransforms: > (CMatch("CRYPTO_MINALIGN_ATTR"), ""), > (CMatch("__private"), ""), > (CMatch("__rcu"), ""), > + (CMatch("__require_explicit_initialization"), ""), > (CMatch("____cacheline_aligned_in_smp"), ""), > (CMatch("____cacheline_aligned"), ""), > (CMatch("__cacheline_group_(?:begin|end)"), ""), > -- > 2.56.0.385.gd3acb90ef8-goog > From xen-devel-bounces@lists.xenproject.org Wed Oct 14 08:08:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 08:08:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448528.1664556 (Exim 4.92) (envelope-from ) id 1xGu2U-0006Kh-FM; Wed, 14 Oct 2026 08:08:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448528.1664556; Wed, 14 Oct 2026 08:08: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 1xGu2U-0006KZ-AV; Wed, 14 Oct 2026 08:08:42 +0000 Received: by outflank-mailman (input) for mailman id 1448528; Wed, 14 Oct 2026 08:08:41 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGu2T-0006KR-HS for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:08:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGu2T-00000004xGB-1i4O; Wed, 14 Oct 2026 08:08: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.98.2) (envelope-from ) id 1xGu2S-0000000G6eA-1nBC; Wed, 14 Oct 2026 08:08: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" 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=3djcjpkpAu5d/9PzQpp1g4S+4TmcMMHCf6SBTYc29VE=; b=q0URrB2paTDxa5A1nZZ+50qyxo tmYH4bUKTnjaAFblVmWaIpZrINfRHU/q6MYumG9r8o5NS15+nD3RRtWdhmMRZ1jPTL8c68RVOUWvt nmCqXk9UXkeSKfGgGeiu0vQQ0ZUZcPjyUqO271JEGYQnqBS1R3l7SIiIEVfHzlp4BOtI=; Date: Wed, 14 Oct 2026 10:08:36 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v3 12/18] x86/mm: let Xen's page-table walker operate on a given root Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-13-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Oct 13, 2026 at 09:37:53PM +0100, George Dunlap wrote: > On Thu, Oct 8, 2026 at 3:59 PM Roger Pau Monné wrote: > > > > On Wed, Oct 07, 2026 at 11:40:45AM +0100, George Dunlap wrote: > > > map_pages_to_xen() and modify_xen_mappings() maintain Xen's own mappings, > > > walking from idle_pg_table, whose Xen slots every other root page-table > > > copies. A later patch introduces a second directmap hierarchy: page > > > tables for the directmap virtual address range that some guest contexts > > > use in place of idle_pg_table's. It needs the same maintenance at the > > > same virtual addresses. > > > > I assume that "second directmap hierarchy" refers to the sparse > > directmap approach? > > Yes. Should I change it to "a second, sparse directmap hierarchy"? I > think raising that we're going to be maintaining parallel hierarchies > is important. I think that would be clearer. > > > > Give virt_to_xen_l{3,2,1}e() the L4 to walk from, and move the bodies of > > > map_pages_to_xen() and modify_xen_mappings() into map_pages_in() and > > > modify_mappings_in(), which take the root as well. The public functions > > > pass idle_pg_table. The EFI runtime-services page-tables mirror > > > idle_pg_table's L4 entries only, so a newly allocated L3 is propagated > > > to them only when the root is idle_pg_table. > > > > > > TLB flushing is unaffected: it is by virtual address, and the same > > > addresses are mapped in either hierarchy. > > > > The virtual address space is just part of it, so far > > map_pages_to_xen() has been doing global TLB flushes, because all CPUs > > used the same page-tables for the Xen slots that map_pages_to_xen() > > modifies. With the change to pass different L4, there's also the > > assumption that the Xen slots on those L4 will be different, and hence > > not all CPUs might need flushing? > > > > Maybe I'm thinking ahead too much - but if this is going to be used to > > manage the sparse directmap we might want to avoid IPIs to CPUs that > > are running with the full directmap when the sparse one is changed, > > as those are useless. > > Yes; changes to both "views" (e.g., map_pages_to_xen()) still need to > flush on all CPUs; but changes only to the sparse "view" (e.g., > removing pages on free_xenheap_pages()) could send an IPI only to CPUs > with the sparse view running on it. We could keep a cpumask with > which CPUs currently have sparse directmaps loaded, and only IPI > those. > > That said, maintaining the cpumask isn't free; it would cause some > cacheline bouncing as vCPUs are scheduled in and out; and since the > idle vCPU has the full directmap, even a system with all "normal" > domains using the sparse map would still need to update it constantly. > Not sure how often free_xenheap_pages() happens, but if it's not very > frequent, it might not be worth the cache consistency overhead (and > the extra complication). I'd leave this as a potential future > improvement. Worth adding a TODO comment somewhere about the fact that map_pages_to_xen() is likely doing too many flushes when used to manage the sparse directmap. Without going into the more complex approach of tracking which CPUs are running with the sparse directmap, we could do batch flushes in add_to_sparse_view() for example, as the flush could be pulled out of the map_pages_in() loop. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 08:09:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 08:09:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448534.1664566 (Exim 4.92) (envelope-from ) id 1xGu2n-0006bq-La; Wed, 14 Oct 2026 08:09:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448534.1664566; Wed, 14 Oct 2026 08:09: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 1xGu2n-0006bj-He; Wed, 14 Oct 2026 08:09:01 +0000 Received: by outflank-mailman (input) for mailman id 1448534; Wed, 14 Oct 2026 08:08:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGu2l-0006bA-OD for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:08:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGu2l-003hVM-0P for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:08:59 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf3890-e002-0a2a0a5209dd-0a2a4503a012-22 for ; Wed, 14 Oct 2026 10:08:58 +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 6acf3896-fae8-0a2a45030019-d1558029e1fe-3 for ; Wed, 14 Oct 2026 10:08:54 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49d0da752ffso5653495e9.3 for ; Wed, 14 Oct 2026 01:08:54 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376522.centertel.pl. [37.47.102.11]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1b2ec47fcsm38910815e9.1.2026.10.14.01.08.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 01: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=1791965334; x=1792570134; 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=oHtnfi/QXYLgIRnE/C+8e3VzskbBZapSOenViY62pAU=; b=Xpt9P10f2QRkqQoxJolivLUjlkulKzft1JYpJC3rLa3sfA8tW+ogiJiOCwF6m6QVX/ +VTQ5KQ3j6Gckcz7/P7hnt83GRXxoq//QAnzPrTsKh5UIu521NpkjGPQ+9oXS1n59hrI /upMzVpGeV7DNrmmvNTPOtZJDmx/SUwFKoYRADUzTParX12UigSASSMJqGN3gAo+ufey 2eB3M+apchEqk/M3Hgg54WcDBZzl1L+Omb8YqJSMLBDK+A4Jm/UrblOoJ3B9xluEAUlE 2lgNWWPCvMGQUZzoyxH3igG2wWKJWqCK5/qBMeJN0P85NzTEXdea4QscA9C11/3WNe1H sFUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791965334; x=1792570134; 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=oHtnfi/QXYLgIRnE/C+8e3VzskbBZapSOenViY62pAU=; b=VdIdT6vPPG52DwAPM2PZf099x0qdZL3Vx/yKC69OAc36X4tDbiwd7ja1ybYSkhcqo5 Ilj9oxu4VvGjSDEcoJ/3azl3Ib6Kq6DxhI/m/kfZOsOH9ye7nAxLOhqgjW/MueNIEz8y AOklzCzRMkiUcRvg8HMWAOwh1KwifGoqiQFEpaCn9VR/IX4w7pAYh1qYDl7/3A2joewU SEhoBqd1cePlJbQF9D/nD68eu+Kj5Grj6yugEf56GowcYQhoSS3cZnlzFQ+hCR1Diar/ h+YzvVKMObAth2+aOMTsJ/LAgbbl70aspOhmFNAa9QXrcvJVStJfduV3pdD1Y6kyrnEs Eyng== X-Forwarded-Encrypted: i=1; AKwUvBxLrJWvqUEVDbVzSly+JTetw1pTIRzWge5t3S7mWhc+5As4+SEsa2f7oeGZisLzoPpIUcXQ+7HemvM=@lists.xenproject.org X-Gm-Message-State: AFq9FYIfSs+UOseFtN8H371jjWM+I+19omXrEyOsdQXK9mDAOzSmLXSB ZdbPCOFxDIyI6PC/0CxGGl8i/aPR0AUrvuyB7aP4+XlU9YLUeLRhcole X-Gm-Gg: AYBFou17kvYym08OSMWbxgj08Nc0rM2hN0m20zXFSQ5d/mxJyNO+7Av17AU4PmEjTbb JjcDxHr4M8ywXZ84j8kLUUloMDXgO67WKwX5AGxxCeRMVK8f7COyvOC2gnbdxp3I1gpF938r9X+ iPtxeq6iV2Qkbzo8zBnN6AgwfSoUyeDZ7lwlDuhh3ncvS1WkYZucanok/gDxXphb0yrR+OxPvov V+xzDLi3UgnYfiGqB7TtNkuEDV+R/Ul6h5qQBUEAChuyCXR13wTk94cFC0jGGjcdvIPqzX5NkbZ DoAKBlo1Qk50HO0lm0rof/hLjcSgp4x6dfiM1Tvy2+rdmQAGSyHspw3AMN9MGIzF5EEvozri3B0 1XjXnufUcnWvLOHpIys5vHU9EUJ0k98Nv4L3Gf5H/AHGALqnF1By+9noXqRQiDYupi3+tzjnOAK QJEHvS6GZzH14CaRoYTjpAd3EfEqUmgrnr8v6/IsxU71JTcR1XPCIojW8Ah0byp6sSqIFP6n11K 5/5BhZdbf9ohZNfTWWIKLN088wavZUfWceCfC4APaScFm/kIA== X-Received: by 2002:a05:600c:a01:b0:49f:ce72:e931 with SMTP id 5b1f17b1804b1-4a18e4fe3e1mr313493505e9.35.1791965334222; Wed, 14 Oct 2026 01:08:54 -0700 (PDT) Message-ID: <9c4e88bd-fc86-4958-b35d-15b769b8fbd1@gmail.com> Date: Wed, 14 Oct 2026 10:08:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Jan Beulich , Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791892682.8631fc262581453bbf619ec5b2062170.1a1352076650008425@vates.tech> <9baeae94-edfb-44f9-9d45-dca32f0d0ed1@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <9baeae94-edfb-44f9-9d45-dca32f0d0ed1@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1791965334-75C804E9-03E7FB90/10/73395122804 X-purgate-type: spam X-purgate-size: 2824 On 10/13/26 5:24 PM, Jan Beulich wrote: >>>> --- a/xen/arch/riscv/include/asm/cpufeature.h >>>> +++ b/xen/arch/riscv/include/asm/cpufeature.h >>>> @@ -42,6 +42,7 @@ enum riscv_isa_ext_id { >>>> RISCV_ISA_EXT_sstc, >>>> RISCV_ISA_EXT_svade, >>>> RISCV_ISA_EXT_svpbmt, >>>> + RISCV_ISA_EXT_svadu, >>> Isn't there some sort of sorting in effect here? >> No, as it is mentioned in the docstring that: >> * New extensions should just be added to the bottom, rather than added >> * alphabetically, in order to avoid unnecessary shuffling. > I see. Yet I wonder: What shuffling would we need to be afraid of? Always > inserting at the bottom increases the risk of patch conflicts. Furthermore > single-letter extensions can't be inserted at the bottom anyway. None, really. The comment was copied from Linux together with the first version of this code, where the IDs were plain macros with explicit values: #define RISCV_ISA_EXT_SSTC 27 #define RISCV_ISA_EXT_SVINVAL 28 ... With such definitions an alphabetical insertion means renumbering every following line, which is the "shuffling" the comment refers to (see Linux commit dac8bf14bb49 "riscv: hwcap: Don't alphabetize ISA extension IDs"). When the IDs were converted to enum riscv_isa_ext_id, the comment was kept as is, although the reason for it went away: the values are assigned by the compiler and nothing depends on them. So I think the comment should be updated: drop the "add to the bottom" part (together with the leftover "macros" wording) and say that multi-letter extensions follow the same order as riscv_isa_ext[], above which the ordering rules are already described. Something like: --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -8,13 +8,13 @@ #include /* - * These macros represent the logical IDs of each multi-letter RISC-V ISA - * extension and are used in the ISA bitmap. The logical IDs start from - * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single - * letter extensions and are used in enum riscv_isa_ext_id. + * Logical IDs of RISC-V ISA extensions, used as bit positions in the ISA + * bitmap. * - * New extensions should just be added to the bottom, rather than added - * alphabetically, in order to avoid unnecessary shuffling. + * Single-letter extensions use IDs below RISCV_ISA_EXT_BASE and are sorted + * alphabetically. Multi-letter extensions start from RISCV_ISA_EXT_BASE and + * follow the same order as riscv_isa_ext[] (see the ordering rules described + * above it). */ #define RISCV_ISA_EXT_BASE 26 Accordingly, svadu will go between svade and svpbmt, both in the enum and in riscv_isa_ext[]. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 08:50:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 08:50:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448574.1664598 (Exim 4.92) (envelope-from ) id 1xGugP-00050h-QU; Wed, 14 Oct 2026 08:49:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448574.1664598; Wed, 14 Oct 2026 08: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 1xGugP-00050a-Ng; Wed, 14 Oct 2026 08:49:57 +0000 Received: by outflank-mailman (input) for mailman id 1448574; Wed, 14 Oct 2026 08:49:56 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGugO-00050T-4Q for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:49:56 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGugO-00000004yLV-13z1 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:49:56 +0000 Received: from mail-lf1-f47.google.com ([209.85.167.47]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGugN-0000000H8od-2K2u for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 08:49:55 +0000 Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-5bc18f54abbso133232e87.1 for ; Wed, 14 Oct 2026 01:49: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" 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=JcDMnuQpktz698RJ/CJldjEk6LxEUKbWbG3FlUsHpJY=; b=Ge8luVwHCSk80BMvTgqC30QlZe UQIRaI1a3nhYwU5ylh1OZIHWFJqn82wdP3Y8r98pPCaV69EjM68KvjXswOlrAq8+bmWIMgMNX7ieN 2JrhZBhKUuDTbNOhtFrNcKTGNP05u2navQGtdE3KfF8AYbh27JfWBH5EAM6+qK96M+Ho=; X-Gm-Message-State: AFq9FYI6dsw4vvmYzOb+n9GF9+BP0dQ5japQ7Iz1Bl2NvajwUsrif4VQ HLGQba/xmiblL18j9+N2obL6WRmYjQye1JALNjUg6BTvaAROIhqIZY4dGwQFx6dBxFS/szVLSoG 3Hq+9Xg+2QPg4dUZKmFOquPqg3u8TYg0= X-Received: by 2002:a05:6512:628d:b0:5bc:ebbc:c80d with SMTP id 2adb3069b0e04-5bcebbcc878mr3531004e87.4.1791967794848; Wed, 14 Oct 2026 01:49:54 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-13-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Wed, 14 Oct 2026 09:49:40 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_ud9BInWEapUAdSO_maBGZHxdQplk44_XiTcX7sNLH6RWNArqzNbs0hTI Message-ID: Subject: Re: [PATCH v3 12/18] x86/mm: let Xen's page-table walker operate on a given root To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 14, 2026 at 9:08=E2=80=AFAM Roger Pau Monn=C3=A9 wrote: > > > The virtual address space is just part of it, so far > > > map_pages_to_xen() has been doing global TLB flushes, because all CPU= s > > > used the same page-tables for the Xen slots that map_pages_to_xen() > > > modifies. With the change to pass different L4, there's also the > > > assumption that the Xen slots on those L4 will be different, and henc= e > > > not all CPUs might need flushing? > > > > > > Maybe I'm thinking ahead too much - but if this is going to be used t= o > > > manage the sparse directmap we might want to avoid IPIs to CPUs that > > > are running with the full directmap when the sparse one is changed, > > > as those are useless. > > > > Yes; changes to both "views" (e.g., map_pages_to_xen()) still need to > > flush on all CPUs; but changes only to the sparse "view" (e.g., > > removing pages on free_xenheap_pages()) could send an IPI only to CPUs > > with the sparse view running on it. We could keep a cpumask with > > which CPUs currently have sparse directmaps loaded, and only IPI > > those. > > > > That said, maintaining the cpumask isn't free; it would cause some > > cacheline bouncing as vCPUs are scheduled in and out; and since the > > idle vCPU has the full directmap, even a system with all "normal" > > domains using the sparse map would still need to update it constantly. > > Not sure how often free_xenheap_pages() happens, but if it's not very > > frequent, it might not be worth the cache consistency overhead (and > > the extra complication). I'd leave this as a potential future > > improvement. > > Worth adding a TODO comment somewhere about the fact that > map_pages_to_xen() is likely doing too many flushes when used to > manage the sparse directmap. Without going into the more complex > approach of tracking which CPUs are running with the sparse directmap, > we could do batch flushes in add_to_sparse_view() for example, as the > flush could be pulled out of the map_pages_in() loop. Yes, I've got a bunch of optimizations queued up after key things are moved out of the xenheap. -George From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:00:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:00:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448584.1664607 (Exim 4.92) (envelope-from ) id 1xGuqP-0007nT-N7; Wed, 14 Oct 2026 09:00:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448584.1664607; Wed, 14 Oct 2026 09:00: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 1xGuqP-0007nM-Js; Wed, 14 Oct 2026 09:00:17 +0000 Received: by outflank-mailman (input) for mailman id 1448584; Wed, 14 Oct 2026 09:00:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGuqO-0007mB-MP for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:00:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGuqN-00CWVx-Ru for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:00:15 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf449a-8faa-0a2a0a5109dd-0a2a45049174-36 for ; Wed, 14 Oct 2026 11:00:15 +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 6acf449e-b57f-0a2a45040019-b9ff1c239e79-3 for ; Wed, 14 Oct 2026 11:00: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 1a139a403a30008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 09:00: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 D40F482BF2; Wed, 14 Oct 2026 11:00: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=XXowHLoZh4TfTGECTeluWWTaMFsjynTrx6h3dkdiLSI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=W0B4iLv4m+IFzB6/J4IzLuPeD/6n/Nhx+WB0TAVceZEdZWO+RTug55geyXMucQEIN1/wM181l ++ef1MlP3vjTejWxUuaFgmhp8v4h7+w5NqffyS3CFon626HJZg511CvgmFzvWOzkXBs7cwsYnJo V361vpogZg/HaJDvWdNpdgwIWA/CdIkxrwoLVAEoYEXPImBIVfJ77G/ai4dSaXdFjd/h9bbGSrI VaCzeuEp6GJ9PN2VhYLol4M0uAMmwxmSXGa4CYURDNaOGycTq5V25L+udrCk4cHVoGIceX2KPgQ gb/ULlzjlRNpip1YwLmNvJLmhUST4BvRpZNVV91orK1g== X-Zone-Loop: 752f73b49701283243a206b11d07df9070e8665d5622 x-campaign-type: default x-transaction-id: b888fb5e-d719-44df-a45d-5074a3d36995 x-swg-uid: 01-2029318e-aa59-4a5f-af2f-387bc64cc13e X-Mailer: Sweego Message-ID: <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> x-swg-bid: 1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425 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 v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org In-Reply-To: <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> Date: Wed, 14 Oct 2026 11:00:06 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791968406; l=2393; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=4ItqVLdhaWZFGWFnlugwFQ9YmsESGshmfNl3KSyou5E=; b=XUEcQVAkHwowNKl9YiJbxD7d+Bv5WrYWi9xMdgA8w+BIkG6UKYCBPPfn6opONE03yC/55fbwW GcUQYGTINWCClAyFRVMhOAM8Mf/H5bOxIwGxB74xYeDuErWGxeR2Qu4 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: 1791968412075 X-purgate-ID: tlsNG-ebf023/1791968415-C30CDB50-2DFB3E49/0/0 X-purgate-type: clean X-purgate-size: 2393 > >>> + "2:\n" > >>> + ASM_EXTABLE(1b, 2b) > >>> + : [tmp] "=&r" (tmp), [updated] "+r" (updated) > >>> + : [va] "r" (va) > >>> + : "memory" ); > >>> + > >>> + arch_pmap_unmap(slot); > >>> + free_domheap_page(pg); > >>> + > >>> + return updated; > >>> +} > >> > >> Imo you'd better check that A also was actually set in the PTE. > > > > If I check that A was set, can I drop the "updated" variable? The A bit > > would tell us more than whether the load succeeded. > > Hmm, I'm inclined to suggest to check both. Then I'd rather probe D than A, since D, unlike A, cannot be set speculatively (spec: "updates to the D bit, resulting from an explicit store, must be exact (i.e., non-speculative)"). The result would then be: return updated && d_set; with a warning (or panic()?) on updated && !d_set, which the spec doesn't allow (spec: "the access must not be performed before the PTE update is globally visible"). Furthermore, if I understood your earlier suggestion correctly, you'd like the A/D bits to be preset in p2m_set_pte_flags() unless Svadu is in use: if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) e->pte |= PTE_ACCESSED | PTE_DIRTY; However, when both Svade and Svadu are advertised, Svade is in effect until Svadu is enabled via FWFT (perfectly legit), so this condition would skip the preset and the first access would fault. I see two ways to address this: 1) Keep checking Svade: if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) e->pte |= PTE_ACCESSED | PTE_DIRTY; After resolve_ad_scheme(), the Svade bit is set in every case where software has to preset the A/D bits. The only imprecise case is both extensions advertised with hardware updating already enabled by firmware, where presetting A/D is unnecessary but harmless. 2) Record the probe result in a global, e.g. static bool __ro_after_init hw_ad_update; and use: if ( !hw_ad_update ) e->pte |= PTE_ACCESSED | PTE_DIRTY; This is exact in all cases, at the cost of a new global that mostly duplicates what resolve_ad_scheme() already records in the ISA bitmap. I discussed with Oleksii and we are fine with either. What do you prefer? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:03:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:03:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448589.1664617 (Exim 4.92) (envelope-from ) id 1xGutG-0008K8-3z; Wed, 14 Oct 2026 09:03:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448589.1664617; Wed, 14 Oct 2026 09:03: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 1xGutG-0008K1-0O; Wed, 14 Oct 2026 09:03:14 +0000 Received: by outflank-mailman (input) for mailman id 1448589; Wed, 14 Oct 2026 09:03:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGutE-0008Jo-UU for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:03:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGutE-000dg9-BF for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:03:12 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf4549-8faa-0a2a0a5109dd-0a2a4506b91a-42 for ; Wed, 14 Oct 2026 11:03:12 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf4550-195a-0a2a45060019-d155dd30c148-3 for ; Wed, 14 Oct 2026 11:03:12 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48c411d6615so2766813f8f.3 for ; Wed, 14 Oct 2026 02:03:12 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376522.centertel.pl. [37.47.102.11]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0bd1843sm10568917f8f.56.2026.10.14.02.03.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 02:03: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=1791968592; x=1792573392; 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=qFZf3SeEqV4vS2tiBTpNp50PMhb6+wCohlTRSNADBas=; b=Wpgi+2Mj5x2h3buDxt9Jt6z+3USe+o+qKPWc71NuUBMu8Co2sO5QLcfK/iQtQt/lRn 2VDWX4UhiNR9U/BcgKocikS9/mQ933XHGqVSOHpTvcjYEpPKonANG8Fwn1YNTNy6Byk/ ayLSnbQWD1Tb8kbhYO/i6fIYqVgZtVuwOhUshyDEHUaaL04JsuDXaahLuBHrGFkg8BxN 9qTM5ABxD/IM9jt7S71Q2UhLhF0McXF4OH+An+8EZuQPy6IbLV8TI8XMk9lkRDsg/sVN vwyUjrgl9ZT9i5GIgx9XPHYiHzXZ9QHw+TzGzMx8dqaKQe/Wgip8RgGEenlOx45I7KSo RA9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791968592; x=1792573392; 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=qFZf3SeEqV4vS2tiBTpNp50PMhb6+wCohlTRSNADBas=; b=lypZ8uX4Gvj6k9flpV8CrVFmJXrZgck6pJTwc4M+CAMsGZUxULV0W3LGU0uUPEEN2z DYbiv0XX0OjcfCm0Jao3fPoPY/zgaJqTghR1W5YwqgPvbsQfZg20OxCXEncrNYzQH6Wr 7dEX7OvoM0KDftvmkZiFW1JKxRgy/dvONJRhXf7YqpsaxROTnqYYX/+EFHz6Pp8xELtw AflrYyo/NdoXSZHl3U9dduDJo7dfH4vZpRRwMxVNoc8PogQGLQzacLVD6GSXKhS555Mw pyhM6i+MLf2C9a5ULIQmQnse5XdrIer+GcUpAi9qHnNwsO7EZqcBlH9ZbeaMaQrVwVdc B/Gg== X-Forwarded-Encrypted: i=1; AKwUvByoClCSNrO9ifvauUdaQ9sF1VZlhEhRwDlCakP4PYyfXY60Mb+sSI1qOSPbR5tQjwUe/+/BMrw9n0M=@lists.xenproject.org X-Gm-Message-State: AFq9FYLp5nYJnFvRxTOLzLLwIDsOLvYk+E+DbN6YLR8d6LO/cwbE11+2 oGuvZcoqTLrie6Gfnb9yMnDECFfT9RaaFkZW9L1Y1sOvfVscsq7fhFQA X-Gm-Gg: AYBFou2WbmujzvnZmhQsjvh7YuQa1DSdtxwo143RUoM/ojyxdoCx+7WQN44UyAp2QNw DNadt588tvZVwOuzzuUUDxnts3DzhfNRjaOC4hvsRRNPcdlFI4dO5kMsIWPcYibzrpAhGeX3Q77 apmvED97KW78JPmpjvdCgA8ssvcEURhhbHtUxC7HJGlsN0pKe9SdfbECxhaeg4Rpou7m5mR/WWR b5UObHxXNntzFyaRCmQd8v4RmQ5gcH8CDRmlTlkguVQ+rlUCMLXIor7j6gkt3Z/13KAGzHtyFTe qOEg92+rVfRxnRut+eoMPSS3k/ej/5/vQ4BetmlKSKI2HyK2KuUeIHapVQGVmngNJP4CQhd+vTp VLRD4sqCwZC+FQ/jyfWHoaEbyt59B65/8pTGiHPhoRRFZN5UmoGtiHZa+FkWUBLYvArSpRzCuE5 GIM4dETHAgAoLvkWuBuUoBQjH+1fgQL5+v0aYBz3CD9CVwj82qyg1p0bDw9BfN0qC/ZU3AkDBYa pBkIKHFuEog/rgEvv1qBepW11jmUjsMvBitRWs= X-Received: by 2002:adf:e190:0:b0:48d:bfd5:79c with SMTP id ffacd0b85a97d-48dbfd507e6mr31333252f8f.42.1791968591700; Wed, 14 Oct 2026 02:03:11 -0700 (PDT) Message-ID: <16f55cfa-9767-41d0-9084-8683cb09a496@gmail.com> Date: Wed, 14 Oct 2026 11:03:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1791968592-FEE7677B-DE1FDD22/10/73395122804 X-purgate-type: spam X-purgate-size: 4247 On 10/13/26 12:07 PM, Baptiste Le Duc wrote: > +static bool __init probe_hw_ad_update(void) > +{ > + bool updated = false; > + unsigned int slot = FIX_MISC; > + vaddr_t va = FIXMAP_ADDR(slot); > + struct page_info *pg; > + pte_t *entry, pte; > + mfn_t mfn; > + unsigned long tmp; > + > + pg = alloc_domheap_page(NULL, 0); > + if ( !pg ) > + return false; > + > + mfn = page_to_mfn(pg); > + > + arch_pmap_map(FIX_MISC, mfn); Do we need the arch_pmap_map() call here? The PTE it writes is overwritten right below by write_pte() (and the TLB flush is repeated too), so effectively only its ASSERT(!pte_is_valid(*entry)) remains. Also, IIUC, arch_pmap_{map,unmap}() are the arch backend of the common PMAP infrastructure and are meant for the FIX_PMAP_* slots handed out by pmap_map(); FIX_MISC isn't one of them. Accessing xen_fixmap[] directly is fine here, as set_fixmap() can't be used (map_pages_to_xen() always sets A and D), but then I'd do the same for the unmapping ...: > + entry = &xen_fixmap[slot]; > + pte = pte_from_mfn(mfn, PTE_VALID | PTE_READABLE); > + write_pte(entry, pte); > + > + flush_tlb_one_local(va); > + > + asm_inline volatile ( > + "1: ld %[tmp], 0(%[va])\n" > + " li %[updated], 1\n" > + "2:\n" > + ASM_EXTABLE(1b, 2b) > + : [tmp] "=&r" (tmp), [updated] "+r" (updated) > + : [va] "r" (va) > + : "memory" ); > + > + arch_pmap_unmap(slot); ... I.e. write_pte(entry, (pte_t){}) followed by flush_tlb_one_local(va). > + free_domheap_page(pg); > + > + return updated; > +} Also: > + asm_inline volatile ( > + "1: ld %[tmp], 0(%[va])\n" > + " li %[updated], 1\n" > + "2:\n" > + ASM_EXTABLE(1b, 2b) > + : [tmp] "=&r" (tmp), [updated] "+r" (updated) > + : [va] "r" (va) > + : "memory" ); Since the loaded value isn't needed, how about loading into the zero register (the load still has to raise any exception) and using plain asm goto? That needs no CONFIG_CC_HAS_ASM_GOTO_OUTPUT conditional (as I originally wanted to suggest), as there are no outputs, and both tmp and the LI go away. Together with accessing xen_fixmap[] directly and using stack page instead of allocation of new page (I assume something like this was suggested by Jan B.), something like this: static bool __init probe_hw_ad_update(void) { vaddr_t va = FIXMAP_ADDR(FIX_MISC); pte_t *entry = &xen_fixmap[FIX_MISC]; bool updated = false; ASSERT(!pte_is_valid(*entry)); /* * Any page in use will do, so alias the stack page this code runs on, * with A clear: the read below either faults or has A set by hardware. */ write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(&va)), PTE_VALID | PTE_READABLE)); flush_tlb_one_local(va); asm_inline goto ( "1: ld zero, 0(%[va])\n" ASM_EXTABLE(1b, %l[out]) : : [va] "r" (va) : "memory" : out ); updated = read_pte(entry).pte & PTE_ACCESSED; out: write_pte(entry, (pte_t){}); flush_tlb_one_local(va); return updated; } One things which I also would like to note about: > + asm_inline volatile ( > + "1: ld %[tmp], 0(%[va])\n" > + " li %[updated], 1\n" > + "2:\n" > + ASM_EXTABLE(1b, 2b) Note that in staging do_trap() consults the exception table only for CAUSE_ILLEGAL_INSTRUCTION, so on hardware which faults on a clear A bit the load page fault ends up in do_unexpected_trap() and hence die(), rather than in the fixup. This is addressed by "xen/riscv: look up the exception table for any trap taken in Xen context" from the vINTC series, so this series depends on it; please mention that in the cover letter or at least something like that will be needed for now if i am not confusing something: break; } + fallthrough; + case CAUSE_LOAD_PAGE_FAULT: if ( fixup_exception(cpu_regs) ) break; ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:10:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:10:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448598.1664624 (Exim 4.92) (envelope-from ) id 1xGuzr-0001K3-SG; Wed, 14 Oct 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 1448598.1664624; Wed, 14 Oct 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 1xGuzr-0001JU-P7; Wed, 14 Oct 2026 09:10:03 +0000 Received: by outflank-mailman (input) for mailman id 1448598; Wed, 14 Oct 2026 09:10:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGuzq-0000qc-5X for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:10:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGuzp-00G4Hp-2w for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:10:01 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf46cd-8faa-0a2a0a5109dd-0a2a4505921a-34 for ; Wed, 14 Oct 2026 11:10:00 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf46e8-4cb1-0a2a45050019-d1558031a40e-3 for ; Wed, 14 Oct 2026 11:10:00 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a16c1608faso50089825e9.0 for ; Wed, 14 Oct 2026 02:10: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 5b1f17b1804b1-4a1b481b7f8sm39555305e9.3.2026.10.14.02.09.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 02:09: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=1791969000; x=1792573800; 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=rSsE83eP0Lgqnp8ps3bURT9k8cekl+eczWy5FLgxgf8=; b=AriuEIsM6us9pRvB5qlLEWb7qsL+vsGbCFo9LoJNm4/sv87JPOnbRBXchZVB1raNhE HBf2WMBF2YWligtq66eeJwIEOSPRt5pQYqcTSxHtGn8LVB+v9ZEUuDC4Cm9XbFP7r8nW XCmegZx1xkTfrbrsrsbRNrh9JppDSWzOqsb8mM8dHDarzBscUZn3DZLdLGTcpX/1CxTg fdeyryxuHxCJheyfuW9LakVru7dbBaeF+Q5opyXgyH9SJfgCryzpaNB6+27eL8ZvMdNm TADMGOI1DpOLFlOLsoV8X7qWDpi3feQx2MIZLoon81XRcfBahVQ6JlRt+CQw8/vSte+T uD1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791969000; x=1792573800; 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=rSsE83eP0Lgqnp8ps3bURT9k8cekl+eczWy5FLgxgf8=; b=vI5cAN44RWjcfe+TRVtJQRijCgAYxNCP752lCGPILGonViHhE29RL4Kr+5Qx/x2cmg TJA/D4qDLCV1pxprfvqmYllWUsxVrcLYLfS/DjdpvS8gq3E4pFaAcjcD8RRasDRMs+JK RDeMu2w2SCP4Bax33rnu5+ZCCiEd7LiFbqqmgaskWAqyj6Yo66yjaGJu2teIaSuflih7 uHO1DETQHTaWhd2YYY2q7u116fgU80o39ZpSVN6QIc89WzIFyqyzbvmCCBqleP3V+DRv RVTDLU/ljHQkrzwp+unfAolhqLbtHEA5X+7n00YixN2aeT8sHXuuchtrA/sD5BUOlTTE NVVw== X-Forwarded-Encrypted: i=1; AKwUvBzNsn7hAq9tvHtqqXKI/l6d5DboD5ge7fXLGAJIUJAOn1KqEetIuRHHHFopOi1tvEyFK8MdnY5EjtM=@lists.xenproject.org X-Gm-Message-State: AFq9FYIunx3nJQ9hPVwcthatrTszeOkg4roW3V+Vsy29ImiKi4faeL/v D39atmv4LJ19PyFXRx+Iv+hY1X476VkhM0UZOkpOy3G6fTeArDuYqeZbXMmdITh6bg== X-Gm-Gg: AYBFou2JLo/iGkFW85xFeC/bK/JBEdPvWNxBHV7CMwUfhJ++4IAHhYcMkcb+lWKMKyf HMpyg6HBG6Pq8G07R+rFxKbPh75o58xdX5WViXHwLxt9rBWDbv1quEBdyQ+b6Sw6FX3HbzToLDV 1zFTvFF+nVOUoBIgolgZlAiC/eUv2BmHlVU9qOrZKYk0ld3ipeRtmsmsv2NDPhjx+HwoxfluxRr iov7EYO+Rgholg5seDqCkMuDhTH++wPjY+BWx1k73okKsEOEy6VjHnT2mT1+Mw3rbfLYYzmT3df F/cTUn9FBhDSIBvW73CDtEztHeBxCuCsW+pQPwYnXARWS0C67nT8hLFEox9DvalzzxNdHX3k5ri bS5cNl14H4iWHAccdYX+CGLpvcU5LcxrUkZtOBcQO6Sht9vgt8EedCyjAbPTHuMbw3tA4JGNVFD +q+qYWNYfGF+ilF84dNM3+zt66e/nh745hY880Fbf3XePX8yN4dxDSu8rMv3elb/9axhwOFlMjr u+Nip9LLZL5FOpm/BXQtglMggSB3xqPjyitYiGF/RdKQ2qliquyqqLSy2Cia3M= X-Received: by 2002:a05:600c:5254:b0:4a0:20b4:ba93 with SMTP id 5b1f17b1804b1-4a18e4aa11dmr308160795e9.16.1791969000241; Wed, 14 Oct 2026 02:10:00 -0700 (PDT) Message-ID: Date: Wed, 14 Oct 2026 11:09:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@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: <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791969000-F6AB72A1-B7FDE20D/10/78276251493 X-purgate-type: spam X-purgate-size: 3039 On 14.10.2026 11:00, Baptiste Le Duc wrote: >>>>> + "2:\n" >>>>> + ASM_EXTABLE(1b, 2b) >>>>> + : [tmp] "=&r" (tmp), [updated] "+r" (updated) >>>>> + : [va] "r" (va) >>>>> + : "memory" ); >>>>> + >>>>> + arch_pmap_unmap(slot); >>>>> + free_domheap_page(pg); >>>>> + >>>>> + return updated; >>>>> +} >>>> >>>> Imo you'd better check that A also was actually set in the PTE. >>> >>> If I check that A was set, can I drop the "updated" variable? The A bit >>> would tell us more than whether the load succeeded. >> >> Hmm, I'm inclined to suggest to check both. > Then I'd rather probe D than A, since D, unlike A, cannot be set > speculatively (spec: "updates to the D bit, resulting from an explicit store, > must be exact (i.e., non-speculative)"). The result would > then be: > > return updated && d_set; > > with a warning (or panic()?) on updated && !d_set, which the spec > doesn't allow (spec: "the access must not be performed before the PTE update is > globally visible"). > > Furthermore, if I understood your earlier suggestion correctly, you'd > like the A/D bits to be preset in p2m_set_pte_flags() unless Svadu is > in use: > > if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > However, when both Svade and Svadu are advertised, Svade is in effect > until Svadu is enabled via FWFT (perfectly legit), so this condition > would skip the preset and the first access would fault. In which case it would need to be if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) e->pte |= PTE_ACCESSED | PTE_DIRTY; albeit I have to admit that permitting two contradicting extensions to be exposed at the same time is irritating. > I see two ways to address this: > > 1) Keep checking Svade: > > if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > After resolve_ad_scheme(), the Svade bit is set in every case where > software has to preset the A/D bits. The only imprecise case is both > extensions advertised with hardware updating already enabled by > firmware, where presetting A/D is unnecessary but harmless. > > 2) Record the probe result in a global, e.g. > > static bool __ro_after_init hw_ad_update; > > and use: > > if ( !hw_ad_update ) > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > This is exact in all cases, at the cost of a new global that mostly > duplicates what resolve_ad_scheme() already records in the ISA bitmap. > > I discussed with Oleksii and we are fine with either. What do you prefer? As to 1), see above. For 2), while maybe okay, I think we're better off not deriving too much from probing. Whatever can be (reliably) derived from what the platform description says should be preferred imo. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:31:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:31:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448619.1664634 (Exim 4.92) (envelope-from ) id 1xGvKU-0005ZR-Hs; Wed, 14 Oct 2026 09:31:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448619.1664634; Wed, 14 Oct 2026 09: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 1xGvKU-0005ZK-ES; Wed, 14 Oct 2026 09:31:22 +0000 Received: by outflank-mailman (input) for mailman id 1448619; Wed, 14 Oct 2026 09:31:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGvKS-0005ZE-PR for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:31:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGvKS-00000004zBf-3JrG; Wed, 14 Oct 2026 09:31: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.98.2) (envelope-from ) id 1xGvKR-00000000Zuj-3KsW; Wed, 14 Oct 2026 09:31: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=uqlkspI5h3a7q80iQ4A4lXYxdBNbl2qBw0pCXIrI0mU=; b=LFj/gZcAczwCAQJ676PPv7aK/V NDejSZb9QeiVdmU00GBIofvo/R7kMxZfEAvE7C3cu5ZTGjnGRjvHbI/2wZCSKuD1yX3HF6Ten9Znn wQM27ly/Cp0mfqwhuDEQ1H8qY384HC3D1JbLA9UzzLYM1nL72gKpArBKkuuBqwXccadI=; Date: Wed, 14 Oct 2026 11:31:18 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 08/15] x86/PVH: split pvh_setup_acpi() Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Oct 13, 2026 at 06:04:37PM +0200, Jan Beulich wrote: > On 13.10.2026 17:52, Roger Pau Monné wrote: > > On Mon, Oct 12, 2026 at 10:23:16AM +0200, Jan Beulich wrote: > >> All E820 manipulations want to happen before the initrd is placed, or else > >> pvh_steal_ram() may steal from the tail part of it. As a second step, > >> split placing ACPI data from actually populating it. > > > > Would it be less intrusive to duplicate the memory map (like it's done > > in a change ahead of this one), and subtract the kernel and initrd > > region from that memory map, then use it as the basis for > > pvh_steal_ram()? > > > > We could adjust/replace pvh_add_mem_range() so it allows changing > > regions from RAM to other types. That would seem to be less churn > > overall. Maybe you did already consider this and found further > > problem with this approach that I'm failing to see? > > No, I didn't try that route. In fact despite the order now this patch > (and maybe also the VMX one) pre-dates the E820-copying one. The one > aspect I consider problematic with the suggested alternative is that > then two E820 maps need updating: The one with kernel (not sure about > initrd; see below) subtracted out, and the one we actually mean to hand > to Dom0. > > As to overall churn: I'm not sure which one would cause less. Certainly > the patch here would remain largely unaltered, as the splitting is > going to be necessary no matter what. I'm possibly missing something, but the splitting won't be strictly necessary? We could do: * Populate p2m * Place kernel * Place ACPI (also VMX metadata) * Place initrd There's no need to split the ACPI between allocation and placement, and we could place the kernel just after having populated the p2m. However we then need to keep a separated memory map (or rangeset?) to signal available memory in the p2m. It would require changes to pvh_steal_ram() and pvh_add_mem_range(), won't won't require splitting ACPI allocation vs loading. We would also need to split the VMX stuff out of pvh_populate_p2m(), but that doesn't seem overly complicated; the logic is already isolated at the tail of the function. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:38:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:38:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448627.1664644 (Exim 4.92) (envelope-from ) id 1xGvRh-0006bF-79; Wed, 14 Oct 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 1448627.1664644; Wed, 14 Oct 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 1xGvRh-0006b8-2r; Wed, 14 Oct 2026 09:38:49 +0000 Received: by outflank-mailman (input) for mailman id 1448627; Wed, 14 Oct 2026 09:38:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGvRf-0006Zx-LJ for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:38:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGvRf-00000004zKD-2wfF; Wed, 14 Oct 2026 09:38:47 +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.98.2) (envelope-from ) id 1xGvRe-00000000lG7-2zdI; Wed, 14 Oct 2026 09:38: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" 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=kC0UHRoom6bNbAsITqxVGNMRutUqVopLCO5sqKYshd0=; b=oULrsqCnHKVTVpArqc4km4m6GZ 5WsKJU8Awlb0KLB+eJNDwZc6YELAI/aRNawGMzvDmYWvUOb3ECATwdEf2lUClktvkckz3ChBSIjTU s0h5VqWMisEK308AN8gPQkKmcYriv7pahcfqrn2ATDn82JvHOLwTf3h9JiaVf49a3z74=; Date: Wed, 14 Oct 2026 11:38:45 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 09/15] x86/PVH: split pvh_setup_vmx_realmode_helpers() Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Mon, Oct 12, 2026 at 10:24:07AM +0200, Jan Beulich wrote: > All E820 manipulations want to happen before the initrd is placed, or else > pvh_steal_ram() may steal from the tail part of it. While this is > currently suitably ordered, mapping the initrd directly into Dom0 will > want to happen ahead of pvh_populate_p2m(). Hence as a third step, split > placing VMX data (if needed at all) from actually populating it. > > Also move the invocation of pvh_setup_vmx_realmode_helpers() out of > pvh_populate_p2m(). Make it unconditional as well, instead bailing from > the function when pvh_place_vmx_realmode_helpers() wasn't called. I'm overall happy with the idea of moving pvh_setup_vmx_realmode_helpers() out of pvh_populate_p2m(), however I would much rather prefer for us to keep two memory maps (the real one in the domain struct), plus a temporary one that signals used memory, rather than doing allocation vs placement in two steps. Having to add custom {acpi,vmx}_info structures for each metadata we want to place seems strictly worse than keeping two memory maps. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:43:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:43:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448634.1664652 (Exim 4.92) (envelope-from ) id 1xGvVm-0008S0-KI; Wed, 14 Oct 2026 09:43:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448634.1664652; Wed, 14 Oct 2026 09:43: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 1xGvVm-0008Rt-Hp; Wed, 14 Oct 2026 09:43:02 +0000 Received: by outflank-mailman (input) for mailman id 1448634; Wed, 14 Oct 2026 09:43:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGvVk-0008Rn-JE for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:43:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGvVj-00Cgpv-L6 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:42:59 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf4e8b-8faa-0a2a0a5109dd-0a2a4506b9fa-34 for ; Wed, 14 Oct 2026 11:42:59 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf4ea3-195a-0a2a45060019-d155dd29bcc3-3 for ; Wed, 14 Oct 2026 11:42:59 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48c45111bebso2332602f8f.0 for ; Wed, 14 Oct 2026 02:42: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-48de0ac5257sm11123474f8f.42.2026.10.14.02.42.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 02:42: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=1791970979; x=1792575779; 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=iSnrYC24nG3N2fHsNW9YC2B7oN5YY7daUst/rkcOfBM=; b=fcMv/9JJkytR2SwlWHDG6N5BLPhZRlIQrkqe4W6l9XpJ8i5YCIxXX8ASM/MWouLXGq 4Bwsw0HXhaCpUTPTyhjD/qitHXI8mQsVWcBk/mNcG5CUbQQRP5FeHM/8dAL+plUFi2bn MDmO9B7MUK8gZDvIpPfhpiJCPdvIAOp5MsH8tLMSqm2+m4lg0i71ZpmD2TusuDpXnj0Z 8zaEJ7xGTbO5nOn80Aw5L2O0ETIFKVyv/MtcOpd4ugPeZZ3PbYMavwDEvwf0E9g/6iAk yTkj4gEj+U1+3cw3lQAWYsYszStYNrBZd1RLWKKbU36nEtuQFsdsXfJ/b7AVzpzPpVmv Wfcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791970979; x=1792575779; 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=iSnrYC24nG3N2fHsNW9YC2B7oN5YY7daUst/rkcOfBM=; b=mOmeV8Ts+gvaX/rpfgSpGKjNhDGUpEwio4hjMe0mCKvl7RI+YHM/n7SYTys21UvcV5 HIbcSGame5vPlUPuHrm1gRlO9YsXYYxLcwDwN6lKoV3sDJsMLkNvUYV2Q5u+Yq3Yn+Ut uxjUpjabgiuCGUNd8y2hiTzDkXgrxGbL/6TtwRVOflKLgC0A/38uC0YwQXqv+rtbEJbN UVYIX/Nzq7ijEObmOdnUA1KcF9eabgtAOo/a19NoKxu7yyve5UVw9A8d/JLcowr+1U6y zQluSfsvA4ogSlTrGu5QEnQfP2wFMkEJAv+dwuVQblJKa1iHrxhBJmtDrNauTgF5HAUs HFtg== X-Gm-Message-State: AFq9FYLljfLZ2mZt1T2DC5r8d0elItGZ2HCARm6tcHjHOqQrITfLeZiw wfKAT3Y15v7XsoNimrOhlSZNL2BPc9nMKPFCyA7V94Y7YzZIzKcORazxGZRw4yv6ug== X-Gm-Gg: AYBFou1G4le7aP7YvyTQRw+vEEsw/L6NA1KV1v7VTGRmto3yaYSqybKdWrr+AEGZ+VL 04rkfWrwncQQc0KRcuqnbIWSU03HxLmMS+XaOPZWK5Y0/POQtfbmxmbALYcNB8piWeTrn4DY6Pm Ct/Gdq15sji9feWdYqLchsP6+Cp8/xdZLi1sKF7/a44OErRBnjgqQuIdJpC+sFaOEwVAv7C3LIY stxqWGqKLq9rQxrdZ3N9PsgU513WFCo/SJVPcv9LZbw9S8NpuZoH483oUicEEAvpzI91jDDg6A9 Vs/xXJf7eQZiD0HcDi/t3LcZhKHllJOx7db0MpI4f2PoIAo5/xagd7ME9clVYBmk77RSY/H+oW4 Cy56b9AJ5QhQow/l5fS0X0aV9k4fqNZKQtuo5EAzL44t+ufaRnelhTsXloH/bPrlJW0C2feEle8 XUJs1hSaYcJicvYvu0rBZsR8LuSvOkfG3zRjx9NpcDqE/UJxdqJI6f2fpMChibp7s2lD7xzZr31 Aqav39MlA9Celjqcfj4IywlopxrYYInMTUNhTU80R6QQlwvh/AHWs60yB1zmg== X-Received: by 2002:a05:6000:400d:b0:48b:10c8:2183 with SMTP id ffacd0b85a97d-48dbacdd2afmr27620958f8f.32.1791970978859; Wed, 14 Oct 2026 02:42:58 -0700 (PDT) Message-ID: <791be732-4c7d-417a-8557-4f82ef62d0c0@suse.com> Date: Wed, 14 Oct 2026 11:42:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/15] x86/PVH: split pvh_setup_acpi() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1791970979-F74C977B-3ABA8696/10/78276251493 X-purgate-type: spam X-purgate-size: 2502 On 14.10.2026 11:31, Roger Pau Monné wrote: > On Tue, Oct 13, 2026 at 06:04:37PM +0200, Jan Beulich wrote: >> On 13.10.2026 17:52, Roger Pau Monné wrote: >>> On Mon, Oct 12, 2026 at 10:23:16AM +0200, Jan Beulich wrote: >>>> All E820 manipulations want to happen before the initrd is placed, or else >>>> pvh_steal_ram() may steal from the tail part of it. As a second step, >>>> split placing ACPI data from actually populating it. >>> >>> Would it be less intrusive to duplicate the memory map (like it's done >>> in a change ahead of this one), and subtract the kernel and initrd >>> region from that memory map, then use it as the basis for >>> pvh_steal_ram()? >>> >>> We could adjust/replace pvh_add_mem_range() so it allows changing >>> regions from RAM to other types. That would seem to be less churn >>> overall. Maybe you did already consider this and found further >>> problem with this approach that I'm failing to see? >> >> No, I didn't try that route. In fact despite the order now this patch >> (and maybe also the VMX one) pre-dates the E820-copying one. The one >> aspect I consider problematic with the suggested alternative is that >> then two E820 maps need updating: The one with kernel (not sure about >> initrd; see below) subtracted out, and the one we actually mean to hand >> to Dom0. >> >> As to overall churn: I'm not sure which one would cause less. Certainly >> the patch here would remain largely unaltered, as the splitting is >> going to be necessary no matter what. > > I'm possibly missing something, but the splitting won't be strictly > necessary? > > We could do: > > * Populate p2m > * Place kernel > * Place ACPI (also VMX metadata) > * Place initrd The goal is to directly map the initrd. That direct-mapping (or at least the determination of where it is to go) needs to happen before populating the (rest of) the P2M (as otherwise this would populate the respective part of the P2M). Else we'll continue to see the problem that Marek reported. That is: * Place kernel * Place ACPI (maybe VMX metadata) * Place initrd (possibly direct-mapping it) * Populate P2M * Load kernel and initrd * Fill ACPI (maybe VMX metadata) (Of course the order of the latter two items doesn't matter much.) Even if we didn't direct-map the initrd along with placing it, we'd still need to tell populate_p2m() to skip that region. I.e. the split between placing and loading/filling would remain. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:49:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:49:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448645.1664680 (Exim 4.92) (envelope-from ) id 1xGvc2-00012v-FQ; Wed, 14 Oct 2026 09:49:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448645.1664680; Wed, 14 Oct 2026 09:49: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 1xGvc2-00012o-CO; Wed, 14 Oct 2026 09:49:30 +0000 Received: by outflank-mailman (input) for mailman id 1448645; Wed, 14 Oct 2026 09:49:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGvc1-00012h-1z for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:49:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGvbz-00BdJE-TU for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:49:27 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5027-e002-0a2a0a5209dd-0a2a45088460-2 for ; Wed, 14 Oct 2026 11:49:27 +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 6acf5027-f659-0a2a45080019-d155dd2bdcad-3 for ; Wed, 14 Oct 2026 11:49:27 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-48c5358fc28so209950f8f.0 for ; Wed, 14 Oct 2026 02:49: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-48de0aaaa3fsm10990523f8f.10.2026.10.14.02.49.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 02:49: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=1791971367; x=1792576167; 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=powhFUt6aUOaxtz8n1hnkKFVk4k525ZIqn92/0ErDSw=; b=Xh81RxzxUFdkVN4JC1WhcD2BpREH5UAzZCVEk+Ac7xVBs5AHesidvfmBt9GU0ITvmP 57oS17PRT8H3uGlQrhixfu+7pd1G3PUiLCevANw6SROcqQ7bGBlM8viehO99FH4Vbz46 GVmAY1B78VIVREpsGz/m3nhJTh4eDk5ueBtrrv4zv+n6UVRdnpIb4xDwY0BuLITr1diS vLrHy0JK3nD1qMmhbh7RrQ4OQdxNzqSjlQoF/n8UQR5+dztnHu4FAP45LSFqQzQ3MfEP dpv6zj0qLXkpauoXSMKcejHSpEdRp6w4Xf/3Y0AT0hVPLV7BtqrJv1VRgUJzbwjXTtMr YtyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791971367; x=1792576167; 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=powhFUt6aUOaxtz8n1hnkKFVk4k525ZIqn92/0ErDSw=; b=pIbnpPkwZ5tHAkZyicTrGVK0ZZvQQ0EUuWKVSL/ckyQXbUm9OnugrrjUst7DrjnBWa jT91bwuCVaSWZYDc6x12nDywfwLTXFqXIht1qnUyUbk0HTydvIqpVBD4iUIlKCUkIySu p6/+vMyNPXZQ+VnqWaixsww3ZrVl8O003/IjGTGONWP3/ODKsjfo5Uv5Oxnql3CTGtEh +qCFegsrvcQKRXK51E+jqKMUskDo0strTgqmAm+LIRlZHcHw13c+x3fOVtAlDb2oKBtK 765IMOs7usshUUgO7ycWWZpgbb1mgVm9BhNrg8XrV9NNzvwrLQTBflnx0lYQ3NKzWfO5 22gQ== X-Gm-Message-State: AFq9FYLEH8vx3n1HVsyp+ILzqaEstxxi9qHunfkwvY39rXIGIpNih+bC iMi2AyTkmAZN6mZvdm4xOuXNPeD98Uro7YYogb5EwTds7Vdo5foR6p1imEOhy3Wg6w== X-Gm-Gg: AYBFou2dz84eYcVf38yGYIMbU0dWmTIS3vdd1/ltozQuhGH8+EQrjsyEgbwFY2Q6pHr sPhoe+eYd6HxkJ6PPTSPiokc0PPViXF5ZLwHRFrqrZGPiv2AjD4kZYPLEeXCkO5jASbTsXVeY6p sU5NDJbsZQokMNumfvIQrEGOzViMJrzzxyA48jHYToI0I2+ZRB7G3/rot/YIu4QhoRCn181x3Sj SkjcSJ1s1c3gwJsprxtGV9Z0mNo4Md7kfRcorTrRHIH/Diszz/Nn5PG5/HOv31v31/Y1YIH/GQo jZfqgpkqBqfXWNbewHQwfAi+TgqWugi/+vKIwyW2OpnSHC6i55gWolTiw5FE/YJqQa5OrNq0IU5 BY/APRTZwRE+ZJE11vdU+wrJr07+pDN8qo/CuWk//g9wXcqpJZt6Zg8VUHgXTqAJW1sFNT/pRAy yovzv+jEbwZycMS/Pj1KlNeHKV5Lwu0bSGVJPTj9LrdLhrr5iBHJH0Q4CaaLI6qg/rEZlaPjymu SgAejThacxBebz12HIg7Qeme/IQTEozq4EprWa6yvckhPGeACIKBEk437NdtQ== X-Received: by 2002:a05:6000:25f2:b0:488:5d44:6680 with SMTP id ffacd0b85a97d-48dbacdc419mr29320275f8f.36.1791971367200; Wed, 14 Oct 2026 02:49:27 -0700 (PDT) Message-ID: <3c1cfedb-abe5-4e5a-9d18-cb4323b6d699@suse.com> Date: Wed, 14 Oct 2026 11:49:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/15] x86/PVH: split pvh_setup_vmx_realmode_helpers() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1791971367-CCB7187B-ADC16EDE/10/78276251493 X-purgate-type: spam X-purgate-size: 1788 On 14.10.2026 11:38, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:24:07AM +0200, Jan Beulich wrote: >> All E820 manipulations want to happen before the initrd is placed, or else >> pvh_steal_ram() may steal from the tail part of it. While this is >> currently suitably ordered, mapping the initrd directly into Dom0 will >> want to happen ahead of pvh_populate_p2m(). Hence as a third step, split >> placing VMX data (if needed at all) from actually populating it. >> >> Also move the invocation of pvh_setup_vmx_realmode_helpers() out of >> pvh_populate_p2m(). Make it unconditional as well, instead bailing from >> the function when pvh_place_vmx_realmode_helpers() wasn't called. > > I'm overall happy with the idea of moving > pvh_setup_vmx_realmode_helpers() out of pvh_populate_p2m(), however I > would much rather prefer for us to keep two memory maps (the real one > in the domain struct), plus a temporary one that signals used memory, > rather than doing allocation vs placement in two steps. Having to > add custom {acpi,vmx}_info structures for each metadata we want to > place seems strictly worse than keeping two memory maps. Hmm, that's unfortunate: I see it the other way around. I also can't seem to be able to see how the order of operations (as listed in the reply on the ACPI patch sub-thread) could be changed to accommodate what you want. There's one basic ordering requirement: We need to know where the initrd is to go ahead of populating the P2M. Yet among kernel, ACPI, and initrd the latter is what has the least constraints on placement. Hence before determining where the initrd is to go, we need to determine where to put kernel and ACPI tables (as said elsewhere, I'm not finally certain about VMX metadata). Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:54:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:54:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448654.1664689 (Exim 4.92) (envelope-from ) id 1xGvgp-0002kd-39; Wed, 14 Oct 2026 09:54:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448654.1664689; Wed, 14 Oct 2026 09:54: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 1xGvgp-0002kW-0D; Wed, 14 Oct 2026 09:54:27 +0000 Received: by outflank-mailman (input) for mailman id 1448654; Wed, 14 Oct 2026 09:54:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGvgn-0002kP-PK for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:54:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGvgn-003Jde-66 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:54:25 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf513a-2eae-0a2a0a5409dd-0a2a4502cf2a-34 for ; Wed, 14 Oct 2026 11:54:25 +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 6acf5151-6ca4-0a2a45020019-d155802cdc3a-3 for ; Wed, 14 Oct 2026 11:54:25 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a16aaf2067so9692605e9.0 for ; Wed, 14 Oct 2026 02:54:25 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376522.centertel.pl. [37.47.102.11]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1b4819302sm35053245e9.3.2026.10.14.02.54.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 02:54: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=1791971664; x=1792576464; 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=OzK/nVaKZPju4MTg1Y762hYvdX/ZiI9PRkm+3bvsvPk=; b=kG/8iCm2rekOTgu47Vz5gqo2BX85PWRDSxga+u1RSw4sXEQBDqwRJrzg7F+GSOe4RH vGSNzsTCFUmsTQgKCBa5f0GQ899mnJGdjGbI1OPPMRHyq0/W4GwPMlu5TkNgV5/6hhg/ KDoV+8MUwUWIoBaHmEMUFjcM0IjJ9iiqMy53+ovrToK6aUiZeP/sMeoCu2aXvvIPC6j3 tnKqDjpPJ724q5ZELKJmVcQpyWEy0/mK2db+/e1601O+VqWFjmHBb3ofoTpucwODTycJ ff+tq4iAB7YRnVJm928i1Z+rsREJRmTuuouq3znUg2giBspiQ6yNMUD1zO3Wf+91Sjuv ga4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791971664; x=1792576464; 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=OzK/nVaKZPju4MTg1Y762hYvdX/ZiI9PRkm+3bvsvPk=; b=EaTfgnVG7dTsJNIIwZHno4ONYeKEvBFl53baL/cpKb2JnzyASx2N+tz0CH+Y+j59Lt /1JiARCAM/ZdwiqerUxNNAtN2sDrkWOK0r2H8Y33xOV8UFBcjPti30klNHifVK/dA2M7 vgOM+I+y+oo+Dv7lwJWReTG6WvUsUDxbDD/jDwYPwen9K1s6VRZxXcdoqErpwr5oPbH7 1AmDfCboEpF0dOiJQF4720OcH8NBByI413oC8YxVK1uOk0/5UZ0t+Zvtz/y/kF5NV8JB Jmxc+23A0cBYfjfZINIIhcYjVROc3joPP0WqL4AfKXAv2k9yZd8bX1DNxxXmjtczOzm4 +hpQ== X-Forwarded-Encrypted: i=1; AKwUvBzYZULbFXhaMrEgKCuy1O0DCBzDHAwY5WVYpvd5jd0Juiu2abDy3YA5iKBgXvj2/vft9rBNU6iHHwM=@lists.xenproject.org X-Gm-Message-State: AFq9FYKpTaVdSkLPAg50DtaDTlySsyyx50hPNtClRj3VxN0HUVyIjGee CSnFIzc2XUcuakg3i8nVGXJpUsFi+ZeNPTVTcyFVek7tK3h1fcKyS2Ou X-Gm-Gg: AYBFou0pXVvdxbNEV8w+f5hdV1H860b/Qwi8NYT0eip7xHgadL0jeLSrWkvdc9vF0cP QbQf30+ymmDTAlJrCjhLcw4NakufxTGGH1ThaYDjyqezqR5w1wC/N1BtUl6KiTjscFwR1uv5YEN yBrBKbbacFu/K5bpvGNme6LRODGAo+E5COisnCfu7e1h7xA009VBnVjYw06+LmWPvHXzNNx4h9M 4sbXvnY2Uv3pw5wPMx13N+oOPSZ3GZHB2wpBYUwMbwsv8I40AReqOZhFV0ceB8vI8KL+4hXGpGt cbiFI0wcXDV7iMGypdXnQheZ6apfscv4Xaiv15BCB2rzrAnhC3bIK5ptUVl9Y0RJCv1hvFhVibl pavFzKi61XtM+xQZRSaFMtD2vtKXTPB7Ae0eeB3PB7Xlx9GMTvZ9+nOcgFnINHyisXpwk3Mow1X 7L/zWxJf8TDDH3XL2Njo5kqAZdgti7fefJy/nKjwvwRE2i55rVz1dHDBPxEhfJ8oodhk87BOTUB fnDR6dapgasE+kPmYWreGGSjdWY6EysaKwd5dqLPyKIANLCPX0= X-Received: by 2002:a05:600c:3111:b0:4a0:159b:d2a2 with SMTP id 5b1f17b1804b1-4a18e4e14e8mr287529445e9.29.1791971664538; Wed, 14 Oct 2026 02:54:24 -0700 (PDT) Message-ID: <3b1335dc-01ab-4bac-917e-e6b198e7f4d0@gmail.com> Date: Wed, 14 Oct 2026 11:54:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Jan Beulich , Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@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-720697/1791971665-F3EBB2AC-2A5C0300/10/73395122804 X-purgate-type: spam X-purgate-size: 4136 On 10/14/26 11:09 AM, Jan Beulich wrote: > On 14.10.2026 11:00, Baptiste Le Duc wrote: >>>>>> + "2:\n" >>>>>> + ASM_EXTABLE(1b, 2b) >>>>>> + : [tmp] "=&r" (tmp), [updated] "+r" (updated) >>>>>> + : [va] "r" (va) >>>>>> + : "memory" ); >>>>>> + >>>>>> + arch_pmap_unmap(slot); >>>>>> + free_domheap_page(pg); >>>>>> + >>>>>> + return updated; >>>>>> +} >>>>> >>>>> Imo you'd better check that A also was actually set in the PTE. >>>> >>>> If I check that A was set, can I drop the "updated" variable? The A bit >>>> would tell us more than whether the load succeeded. >>> >>> Hmm, I'm inclined to suggest to check both. >> Then I'd rather probe D than A, since D, unlike A, cannot be set >> speculatively (spec: "updates to the D bit, resulting from an explicit store, >> must be exact (i.e., non-speculative)"). The result would >> then be: >> >> return updated && d_set; >> >> with a warning (or panic()?) on updated && !d_set, which the spec >> doesn't allow (spec: "the access must not be performed before the PTE update is >> globally visible"). >> >> Furthermore, if I understood your earlier suggestion correctly, you'd >> like the A/D bits to be preset in p2m_set_pte_flags() unless Svadu is >> in use: >> >> if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) >> e->pte |= PTE_ACCESSED | PTE_DIRTY; >> >> However, when both Svade and Svadu are advertised, Svade is in effect >> until Svadu is enabled via FWFT (perfectly legit), so this condition >> would skip the preset and the first access would fault. > > In which case it would need to be > > if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || > !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > albeit I have to admit that permitting two contradicting extensions to > be exposed at the same time is irritating. > >> I see two ways to address this: >> >> 1) Keep checking Svade: >> >> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) >> e->pte |= PTE_ACCESSED | PTE_DIRTY; >> >> After resolve_ad_scheme(), the Svade bit is set in every case where >> software has to preset the A/D bits. The only imprecise case is both >> extensions advertised with hardware updating already enabled by >> firmware, where presetting A/D is unnecessary but harmless. >> >> 2) Record the probe result in a global, e.g. >> >> static bool __ro_after_init hw_ad_update; >> >> and use: >> >> if ( !hw_ad_update ) >> e->pte |= PTE_ACCESSED | PTE_DIRTY; >> >> This is exact in all cases, at the cost of a new global that mostly >> duplicates what resolve_ad_scheme() already records in the ISA bitmap. >> >> I discussed with Oleksii and we are fine with either. What do you prefer? > > As to 1), see above. For 2), while maybe okay, I think we're better off > not deriving too much from probing. Whatever can be (reliably) derived from > what the platform description says should be preferred imo. Option 1 looks okay to me. Also, it seems then we could simplify resolve_ad_scheme() to: /* * p2m_set_pte_flags() presets the A/D bits unless only Svadu is advertised, * as per the DT binding that is the only case in which hardware updating is * guaranteed to be enabled (by firmware, via menvcfg.ADUE). Check that it * really is, and fall back to presetting A/D otherwise: a hart which faults * on clear A/D bits implements Svade, whether or not it says so. */ static void __init resolve_ad_scheme(void) { if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) || riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) return; if ( !probe_hw_ad_update() ) { printk(XENLOG_WARNING "Svadu is advertised but A/D bits aren't updated by hardware, presetting them\n"); __set_bit(RISCV_ISA_EXT_svade, riscv_isa); } } ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 09:59:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 09:59:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448660.1664698 (Exim 4.92) (envelope-from ) id 1xGvm3-0003hK-KH; Wed, 14 Oct 2026 09:59:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448660.1664698; Wed, 14 Oct 2026 09:59: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 1xGvm3-0003hD-He; Wed, 14 Oct 2026 09:59:51 +0000 Received: by outflank-mailman (input) for mailman id 1448660; Wed, 14 Oct 2026 09:59:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGvm2-0003h7-6V for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 09:59:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGvm0-0044ov-3p for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:59:48 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5292-8faa-0a2a0a5109dd-0a2a4509af1a-8 for ; Wed, 14 Oct 2026 11:59:48 +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 6acf5293-be1a-0a2a45090019-d155dd30cd0a-3 for ; Wed, 14 Oct 2026 11:59:47 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48c14a06c95so3062828f8f.1 for ; Wed, 14 Oct 2026 02:59:47 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376522.centertel.pl. [37.47.102.11]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0ab506bsm11606688f8f.27.2026.10.14.02.59.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 02:59: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: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=1791971987; x=1792576787; 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=Y/rd2s6vNeSV1St8vt21X3prAbokQGGVQQUKPiDr6Uk=; b=CjLdElRqCcLGKypBlXJGM3zTDzb6cVDxX7T3uU0ShMiZCs5+IRgIT6an+UcDib11VU Nv3dYSwkZeEDYI45hdCvuAdfRxfm7+oAmfJc6F/d1AND+n7/238UcpAD6viEZ2QAU85E Ct7dxuKS1IKxtwzXpjlsCxL004h0ROh0kR0CmPltqeyaShh7Ht9af3o8Os9Sk7e1Lnsk nF8cOuLKbjHWtj3IVebEV5/zsAl5FFhJa+oumJOIWItJNM9eq7o0ji+O6kIuqkapbCQU 2Dn/aSFA94M1G2aiI19CKT4FJAI5UgVF5WFN3MnL+LTZw1MkXbvyTbs4qde/xUIAV7mp qWiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791971987; x=1792576787; 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=Y/rd2s6vNeSV1St8vt21X3prAbokQGGVQQUKPiDr6Uk=; b=LInShmzRVkjnW2dNU0YDXMK/tENJORUfqtFM1OPco2SYlKaPXxeu+5Mf63hqKfn+wW qTm7/S+JEAOzo2oMxS8Wgae1cs0FeW3KpWgHuACOX06oFqHuAjT9+UQLDG+UIZg4hTFs ZXog+cDwenhoArjnKoKPloSE7+Y4xvkthBIZmZq/Dl4qxUHZRKF4XDLommX1Z8du7KAj 1bhkoFSTl5Pm4XH1ByD/bB8NlfZm7CcRJgFdokALQAmLQuIeeyh8XLCZ/A1uS4SHogbf 4Hw1a38rUvJJoMA8Ia8ZyFsX2M2uQV8gmt6sSzXutczdRem5asa1kbFLzowDLh1knIsP +KAA== X-Forwarded-Encrypted: i=1; AKwUvBy4QZS1edLpfRA2f7LYmICRCPFcoQSjGI4xnTouZ329Td9C1eiKElOf/C9IgRxVaFOemF5butSy70c=@lists.xenproject.org X-Gm-Message-State: AFq9FYL5Mj+nwUH51gndlrYb/uqXArptdFmm6WeVueEc0QiQd/c9RCd6 7Lg9TpwxLSCiwYiNV6OX4Avx1rwzqq3r7x7qmRqymRkbr+2Enz+KSysS X-Gm-Gg: AYBFou0pIZqo+KjzM2Oo50Mia6HiC0zOxxJIqMZhGWkLsdvZyc/A2WxL2zIfNfm8JB6 KHr0sqz9OjFZ7N9mHf1ms7oLtY3uCfc5H3tgElXHJazLhGxJoROITC8Ukf07b0l4ZEFXpxSUdt4 Ln6872wSGY2BIdVYOa+nJcEh8KDMMFqeKd5IJrOUjCOqblY/PqUd2Kb5NJcko7HTimP5SVEkK4G 5KxPzJ60eNriVhbQDPTk9UXeDH1iN+ASaRpt6k9p5saB36my/krzC4y6awUBWReYKrKTLtHFfoS 3lRZF4OpqO5Nk4uO2Eci4VtFndCnTQpyILV24hi9BNjg5Mco09hFOBR7G0jhLmur6mBbus2MnJX cK+AkZa0F3jkNOUA9e9ckH/+h12UTYkBqbOYUx8IkWwoyBdCEPI6TEyIp0op+uP0XS405ch4LzL ngxOVuwYGioEBvdGhT/T/XMEtCf+V/qBSkvHhy+nnd5tKgD1j62GNJl6xCy30eVsPLKjq/Fd4qr C0Z2wbwebJEIAi+KubGSGGLXmJBc7BXT4lmXD8= X-Received: by 2002:a05:6000:24c4:b0:48b:1c:d6e1 with SMTP id ffacd0b85a97d-48dbace386bmr29056878f8f.43.1791971987477; Wed, 14 Oct 2026 02:59:47 -0700 (PDT) Message-ID: <3e9e986b-f996-4154-93c1-a07b1f432e71@gmail.com> Date: Wed, 14 Oct 2026 11:59:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791971988-FD06B034-090ECB05/10/73395122804 X-purgate-type: spam X-purgate-size: 2195 On 10/13/26 12:07 PM, Baptiste Le Duc wrote: > Xen does not handle page faults caused by clear A/D bits, so it presets > them when creating PTEs. pt_update_entry() does so, but three places build > leaf PTEs directly without going through it: setup_initial_mapping() (the > boot page tables), check_pgtbl_mode_support() (the temporary root entry > used to probe SATP mode support) and arch_pmap_map() (the fixmap). > > Without Svadu, all three fault on first access. For > check_pgtbl_mode_support(), the fault is raised by the instruction fetch > right after the SATP write, before any trap handler is set. > > Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build > PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in > all cases for consistency with pt_update_entry() which sets it at runtime. > > 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 check_pgtbl_mode_support() to > use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. > > pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one > of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by > masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also > carries A and D, a reserved PTE with A or D set would no longer be caught. > Mask with the V, R and W bits explicitly instead, and factor the check out > into pte_has_reserved_rwx(). > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") I think I missed to mentioned that before, sorry: arch_pmap_map() was introduced by f89e1a170299 ("xen/riscv: introduce asm/pmap.h header"), so perhaps add a 2nd Fixes: tag. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 10:04:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 10:04:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448667.1664708 (Exim 4.92) (envelope-from ) id 1xGvqT-0005TV-4y; Wed, 14 Oct 2026 10:04:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448667.1664708; Wed, 14 Oct 2026 10:04: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 1xGvqT-0005TN-1W; Wed, 14 Oct 2026 10:04:25 +0000 Received: by outflank-mailman (input) for mailman id 1448667; Wed, 14 Oct 2026 10:04:23 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGvqR-0005TH-3P for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:04:23 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGvqR-00000004zsg-0hB6 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:04:22 +0000 Received: from mail-lf1-f50.google.com ([209.85.167.50]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGvqQ-00000001NCQ-1mjt for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:04:22 +0000 Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5ba3b1199f6so3519212e87.3 for ; Wed, 14 Oct 2026 03:04: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" 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=lVXr+Y5h+UxL9oAD7lAjVkU/fK4+zwKXtYToq+b5Ysc=; b=eugLahXt5Tv++s7ohn1yH+e4zF 2Q6cLcTpeXG7YsECYc6fd22pVIo4OGrg4m3SX9rWA86wvaRVHhnxqC96foRfZoYBzGLPqyoN9S44B cJuNFmqvXwMTx/2GmPpbBY12yszIbCHxvWoPmpM+keo09yxPEejqNO+bZqg8TvgO3q0U=; X-Gm-Message-State: AFq9FYIbU89Mfm7gHzZoS6AHdiCWJuGaKBW0v0nJIzKlwq9BhbTJFU9f JSJ1xoSLpCQT2DiEaE/iT47XPIgQ5B6D1SVLiYXIRw8TOBMp8x2Ste/kOhnGDe3ZLPHPCEZZb9d NLN6ODqlvorOk2NoUL/pAaJivBtlids0= X-Received: by 2002:a05:6512:10d3:b0:5b8:99b1:fa26 with SMTP id 2adb3069b0e04-5bcde6c08b5mr6248030e87.30.1791972261673; Wed, 14 Oct 2026 03:04:21 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-14-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Wed, 14 Oct 2026 11:04:09 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8jBD1CXRqHTTU1zizhSob1lZUzhYClMG0wecr_hpkWdKahJHqhi3c86JE Message-ID: Subject: Re: [PATCH v3 13/18] x86/mm: build and maintain a sparse view of the directmap To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 7:02=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > - xenheap allocations are added, and taken out again before the pages > > are freed. If that fails the pages stay mapped, and are leaked with > > a warning rather than reused (the same reasoning as in "xen/page_all= oc: > > Add a path for xenheap when there is no direct map" of the directmap > > removal series); > > I would probably remove this last sentence, it doesn't add any > meaningful information. I assume you mean the parenthetical referring to the other patch -- I agree= . > > - memory handed to the heap later (boot modules, .init, memory > > hot-add) is taken out, and is not handed over if that fails; > > - a PV dom0's initrd, assigned to dom0 in place, is taken out; > > I assume dom0 kernel memory is freed, and it doesn't need the same > kind of special handling the initrd needs due to it being assigned in > place. Yes, that's correct. > > alloc_xenheap_pages() accepts pages still awaiting scrubbing > > (MEMF_no_scrub). That is harmless while the directmap maps all memory > > anyway, but the sparse view would make such a page's contents, a dying > > domain's data for instance, reachable from every context on it until > > overwritten. With a sparse view configured, arch_xenheap_needs_scrub() > > makes xenheap allocations scrub those pages first, as domain heap > > allocations do; clean pages need nothing extra. > > There's another possible issue here I think: even when requesting > scrubbed pages the allocator can decide to scrub them in-place, > mapping them using map_domain_page(). Could this also cause concern, > as Xen is mapping possibly sensitive data in a context that's not > supposed to access it, even if just for the scrubbing. But for HVM domains with per-vCPU mappings, it's only mapped on the pCPU that's doing the scrubbing, which is in the Xen context; no other vCPU of the domain can access it, and by the time we return to the guest, it's been scrubbed. So this is only a limitation for PV domains with ASI enabled; and the real solution there is to give them per-vCPU mapcaches as well. Probably is worth noting the limitation somewhere; the only reliable solution apart from vcpu_pt would be to scrub on free. I'll add a note here. > > arch_mfns_in_directmap() says whether an MFN range is reachable through > > the directmap; it now answers for every context, so false once a sparse > > view is configured. Its one caller, init_node_heap(), then keeps a NUM= A > > node's heap metadata in the xenheap instead of carving it out of the > > node's memory through the directmap: carved out of a range handed to th= e > > heap, it would be left out of the sparse view, which every heap > > allocation needs it in. > > > > The sparse view is built only when some guest type is to use it, which > > nothing can request yet: this patch changes nothing on its own. > > Is it worth mentioning that modify_xen_mappings_lite() doesn't need > adjustment because it only deals with virtual addresses in the > XEN_VIRT_{START,END} range, and those are cloned in the sparse > directmap view? Yes, I think so; I'll add a sentence to that effect. > > Assisted-by: Claude Code:claude-opus-5-5 > > Signed-off-by: George Dunlap > > --- > > Changes in v3: > > - New in this version. > > --- > > xen/arch/x86/Kconfig | 1 + > > xen/arch/x86/Makefile | 1 + > > xen/arch/x86/include/asm/mm.h | 17 +- > > xen/arch/x86/include/asm/sparse-directmap.h | 63 +++ > > xen/arch/x86/mm.c | 128 +++++- > > xen/arch/x86/pv/dom0_build.c | 4 + > > xen/arch/x86/setup.c | 4 + > > xen/arch/x86/sparse-directmap.c | 424 ++++++++++++++++++++ > > xen/common/Kconfig | 18 + > > xen/common/page_alloc.c | 41 +- > > xen/include/xen/mm.h | 35 ++ > > 11 files changed, 722 insertions(+), 14 deletions(-) > > create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h > > create mode 100644 xen/arch/x86/sparse-directmap.c > > I have to admit reviewing this 1K line diff is challenging. I've > tried my best, but it's likely I've missed stuff. We could try to break it down, but it's already pretty well broken down: That is, there are three logical changes (Introduce hooks and their stubs, add mm.c helpers, add sparse-directmap.c with the real hooks) , but they're not intermingled. A series of three patches would be basically exactly the same hunks as the single patch, just spread out. I think the main thing that makes this hard to read in patch form is having a full file, sparse-directmap.c, introduced: You're not used to reading source code like that with no highlighting and plusses in front of it. Applying the series to a tree and looking at the file in your normal editor might make it easier. But for the same reason, breaking it down into three would be pretty easy; let me know if you want me to do that. > > +bool __ro_after_init opt_sparse_dmap_pv; > > +bool __ro_after_init opt_sparse_dmap_hvm; > > Do we need an extra opt_sparse_dmap_dom0? So that dom0 can opt-out > independently of everything else? Yes; as you noted, this is currently added in patch 18. I'll add all the knobs here. > > +/* Root of the sparse view: only ever walked and copied from, never lo= aded. */ > > +static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIE= S]; > > +l4_pgentry_t *__ro_after_init sparse_dmap_root; > > + > > +/* > > + * Before the sparse view is built: the MFN ranges handed to the heap,= which > > + * it leaves out, and the xenheap allocations made meanwhile (heap met= adata of > > + * NUMA nodes), which it puts back. > > Explicitly mentioning NUMA node metadata is likely to go out of date, > as changing that logic will most likely forget to update the comment > here. Yes, this comment has already been cut down for the next version. > > +static int add_to_sparse_view(l4_pgentry_t *root, unsigned long mfn, > > + unsigned long nr) > > +{ > > + unsigned long va =3D (unsigned long)mfn_to_virt(mfn); > > + unsigned long end =3D va + (nr << PAGE_SHIFT); > > + > > + while ( va < end ) > > + { > > + pte_attr_t flags; > > + unsigned long n; > > + mfn_t m =3D xen_mapping_lookup(idle_pg_table, va, &flags, &n); > > + int rc; > > Since you are fetching the mfn from the idle (non-sparse) page-tables, > don't you want to check it matches the mfn passed as the function > parameter? Hmm, if the PTE for mfn_to_virt(mfn) in the full directmap doesn't contain mfn, something's gone terribly wrong; definitely not safe to continue executing Xen. We could certainly add an ASSERT(); if it actually happened in production, we'd want to BUG(), but that seems so unlikely, I'm not sure it's worth the extra conditional. I'll add an ASSERT() here; it's easy enough to change to a BUG_ON() if we decide we want it there. > > +static int __init cf_check cmp_mfn_range(const void *a, const void *b) > > +{ > > + const struct mfn_range *l =3D a, *r =3D b; > > + > > + return l->s < r->s ? -1 : l->s > r->s; > > The last arm of this ternary operator is doing an implicit conversion > from boolean to integer, I think that's not fine MISRA-wise? Yes, I'll change it to return explicit integers, as cmp_node() does. > > + /* > > + * The full directmap, leaf by leaf, minus the ranges added to the > > + * heap. Leaves come in address order, which is MFN order in the > > + * directmap, so the cursor into the sorted (and disjoint) heap > > + * ranges only moves forward. > > + */ > > + for ( va =3D SPARSE_DMAP_START, j =3D 0; va < SPARSE_DMAP_END; ) > > + { > > + pte_attr_t flags; > > + unsigned long n, s, e; > > + mfn_t m =3D xen_mapping_lookup(idle_pg_table, va, &flags, &n); > > + > > + n =3D min(n, (SPARSE_DMAP_END - va) >> PAGE_SHIFT); > > + if ( mfn_eq(m, INVALID_MFN) ) > > + { > > + va +=3D n << PAGE_SHIFT; > > + continue; > > + } > > + > > + for ( s =3D mfn_x(m), e =3D s + n; s < e; ) > > + { > > + unsigned long upto =3D e; > > + > > + while ( j < nr_early_heap && early_heap[j].e <=3D s ) > > + j++; > > + if ( j < nr_early_heap && early_heap[j].s <=3D s ) > > + { > > + s =3D min(e, early_heap[j].e); > > + continue; > > + } > > + if ( j < nr_early_heap ) > > + upto =3D min(e, early_heap[j].s); > > + > > + if ( map_pages_in(sparse_l4, va + ((s - mfn_x(m)) << PAGE_= SHIFT), > > + _mfn(s), upto - s, flags) ) > > Why use map_pages_in() directly here, instead of add_to_sparse_view()? Because add_to_sparse_view() does a PT walk to get the flags; but we already have the flags. > > > + panic("Sparse directmap: out of memory\n"); > > + mapped +=3D upto - s; > > + s =3D upto; > > The above logic is complicated to follow, maybe some simple comments > will help. I didn't comment it because IME this sort of tight algorithmic data structure walk isn't really made much better with comments; there's no getting around the need to brute-force grok what's happening. I'll see what I can do though. It's worth saying that 1) this is the *sort* of bug that Claude is good at catching, and this patch has had multiple rounds of review 2) a bug here has a high probability of causing a crash later, and none have been observed. One thing on the TODO list was to add a sparse-directmap audit debug key, to make sure that nothing in the heap (and not the xenheap) is in the sparse directmap. > > + /* > > + * Now add back in ranges from the heap which were allocated to > > + * the xenheap. > > + */ > > + for ( i =3D 0; i < nr_early_xenheap; i++ ) > > + { > > + unsigned long nr =3D early_xenheap[i].e - early_xenheap[i].s; > > + > > + if ( add_to_sparse_view(sparse_l4, early_xenheap[i].s, nr) ) > > + panic("Sparse directmap: out of memory\n"); > > + mapped +=3D nr; > > + } > > + > > + sparse_dmap_root =3D sparse_l4; > > This logic involves a fair amount of calls to map_pages_in(), I think > there will be no flushes in this case, because we are strictly > populating the page-tables, and hence the old PTE will always be > non-present. Worth confirming, otherwise we might need some TLB flush > avoidance, as doing TLB flushes makes no sense here, the page-tables > are not in use. At this point the other CPUs are not up, so there are no IPIs; at most a local flush when a table collapses into a superpage. -George From xen-devel-bounces@lists.xenproject.org Wed Oct 14 10:52:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 10:52:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448725.1664761 (Exim 4.92) (envelope-from ) id 1xGwaX-0006O7-Ei; Wed, 14 Oct 2026 10:52:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448725.1664761; Wed, 14 Oct 2026 10: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 1xGwaX-0006O0-Bn; Wed, 14 Oct 2026 10:52:01 +0000 Received: by outflank-mailman (input) for mailman id 1448725; Wed, 14 Oct 2026 10:52:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGwaW-0006Nu-1a for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:52:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwaV-000zxu-EX for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:51:59 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5ecb-bab6-0a2a0a5309dd-0a2a4508af28-40 for ; Wed, 14 Oct 2026 12:51:59 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf5ecf-f659-0a2a45080019-d155dd29e51f-3 for ; Wed, 14 Oct 2026 12:51:59 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso202320f8f.1 for ; Wed, 14 Oct 2026 03:51:59 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376522.centertel.pl. [37.47.102.11]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0514ab1sm14639482f8f.0.2026.10.14.03.51.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 03:51: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=1791975119; x=1792579919; 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=pJ40mdVF2h3U99L6LSkoNg9S+JOxwfRKomS8IAjHB+w=; b=HNAGVhK6Vc1SEerQUM9v79gRy469quGojFQrLpOEGLZSH23W76HrTbLX7aREcXkyp4 eY0moBlRY+97Z8yuiWbuYehDz2R6N6Qd6ak8qRS7iXzZ9Jq1L3/fSquLigKcG7hMshJ1 u4QREP9rRr+m9SA13JuksOO/3xeRIoYXF9/208P6l4A6nKXGTYxcFPn+ZZcvZmsTkNFd uVV8mHXy6aHIBr3iya+yhR+CFy/vTZLj0hDJHM+sUkV0GHWu8SWkjXGV0WgGtlDQhsOl VeZiVsugyLTM7cE9N4BUUTg6f+3miKwblv4/5kql6PjKAzsvkvjbSXsaNW3fr6Ben3/0 eSHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791975119; x=1792579919; 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=pJ40mdVF2h3U99L6LSkoNg9S+JOxwfRKomS8IAjHB+w=; b=sDV9XRKidAdFJCzgMNmMUzVlIOfEC83VyvvkLq0jlld26zk5zbgFVAIZ5Alv7z0Ai+ YkN6DGHI/WOCBnkn7nfeHW2r5ZLhK7v4+MIMxiN+OmSihOmuBPc4vT4VbuA9tAi1nsbx 5TjdtuHgxs2dTzoBe8QgbLBJEK6GIV4zkwY/XlzZQmKLZpTjdmY4P5zds3IRfL9POP6U mYjjWGooLvOK27/BZB+ejWUQaMX2my1cXeBx65DxTscIzsFrWZh9mpRFyKcAi/7DPTxR tcqRacbMc+UQFykJvxfRRyGLx60OHUIgB0bqXUkgDS109PCt/pHgauPv5ZhTuwtN1AkZ 1NSA== X-Forwarded-Encrypted: i=1; AKwUvBwb43EtF0/wb4F3/ovZqjzKlFElB+FkCYv3YwZHBhF3w9fG9SYd/V+6/6vq2Om3OJJjXN4WF0BPEec=@lists.xenproject.org X-Gm-Message-State: AFq9FYK+3i5PLMF0F+LBVxfGB8wDBJvyiyOCoQl+ZJxPtV3JpYhPbtyg l3D2JGKVSM2Mfq3B+oPS84aTVrTFPkZ4lfyaRHpobY5l70/MRIXerWrW X-Gm-Gg: AYBFou1zSSFPJHYvO3BLvCcXPC3sNuBIzxvoszx3WyUCqLgHNQJ6FHHr4IYAd9NsPfi fdCvng7Ezj2Grcid3TrCRkJxUtlschpLkNcNRTv4Cz3EiyEFGcSDNLwCVGd+ADbDp1I/is5nRO4 puSRR9adrXLnUW15xvJhELMJsQ6Kf3Hp/3wbF+ndZ2+UN20JQ66siJ0YJgCqdYXwBlOquMLEtEI cIvle1Ggyhy7bkX4rK/gIuBh6F2NpdQS/KjAGFIoihuKMaDEOn0Tp3TFcRVSD5h0YHMUebtepoi UgoChTIwtrvzKRu6TUNRvZCM/K/fccQyRSsakQKTIW3HSPvBrqvlMngiJs0KOgEF1MuF0TPOnuA wfgdwPpSEdX2S50061Cfu9pUb7p99wZqS1l3/MLHKomXCbEBOQHo602/eDCARWbCtYNnCumT0rP NCEV4irjI44bYAV59R5C7VkE7rpbS7Cmziq3NZYBPMc7IgDB1i+E3ZTsXe//wUTXwN9e7O6R1Br VaZEy/hPcCj63dTIHBQmW+r+2pJLSTj0/8notc= X-Received: by 2002:a5d:6346:0:b0:488:8a3d:b58a with SMTP id ffacd0b85a97d-48dbaaed83fmr22972310f8f.53.1791975118646; Wed, 14 Oct 2026 03:51:58 -0700 (PDT) Message-ID: <66fd20a7-4849-48b9-8030-9154c5100301@gmail.com> Date: Wed, 14 Oct 2026 12:51:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 06/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-c1860d/1791975119-CED4087B-BE7263B3/10/73395122804 X-purgate-type: spam X-purgate-size: 4646 On 10/12/26 5:28 PM, Jan Beulich wrote: > On 30.09.2026 18:18, Oleksii Kurochko wrote: >> --- 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; > > This is a decent size structure, so I wonder whether this really wants > embedding in struct domain. If it was a pointer here (with the struct > dynamically allocated), the struct definition itself may not even need > exposing in a header. Makes sense. I'll make it a pointer allocated in domain_io_init(), with struct vmmio (along with MAX_IO_HANDLER and struct mmio_handler) moved into mmio.c (as they then will be used only there), so that doesn't need anymore. > >> --- /dev/null >> +++ b/xen/arch/riscv/mmio.c >> @@ -0,0 +1,175 @@ >> +/* 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, > > The first parameter here apparently wants to be named currd, much like ... With having vmmio member of arch_domain struct declared as pointer then here it could be const struct domain *currd. > >> + 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; > > ... this variable wants to be named curr. Unless of course there are > plans to not unconditionally use current here. Indeed, both always refer to current. I'll rename them to currd and curr (and make currd a pointer to const while at it). > >> +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 || end <= addr ) >> + return -EINVAL; > > I think this checking goes a little too far: It's absurd for some call site > to pass NULL into this function. The other three checks are sufficiently > plausible, albeit I wonder whether this wouldn't want to be an assertion > then. Agreed, NULL ops can be dropped. As the callbacks always come from a static ops structure, I'll turn their check into an ASSERT(). I'd keep end <= addr as a run-time check though, as the region bounds may be computed (e.g. from max_vcpus) rather than being constants, and the overlap check below relies on addr + size not wrapping. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:00:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:00:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448740.1664771 (Exim 4.92) (envelope-from ) id 1xGwix-0008SF-7b; Wed, 14 Oct 2026 11:00:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448740.1664771; Wed, 14 Oct 2026 11:00: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 1xGwix-0008S8-3Z; Wed, 14 Oct 2026 11:00:43 +0000 Received: by outflank-mailman (input) for mailman id 1448740; Wed, 14 Oct 2026 11:00:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwiv-0008S2-Gh for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:00:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwiu-0012XH-Sr for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:00:40 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf60cd-e002-0a2a0a5209dd-0a2a4509b648-34 for ; Wed, 14 Oct 2026 13:00:40 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf60d7-be1a-0a2a45090019-94a39b0cc20a-3 for ; Wed, 14 Oct 2026 13:00:40 +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 69EAYIpM3386605; Wed, 14 Oct 2026 04:00:29 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021136.outbound.protection.outlook.com [52.101.52.136]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4ha83mr1ux-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 04:00:29 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by SA0PR02MB7209.namprd02.prod.outlook.com (2603:10b6:806:da::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Wed, 14 Oct 2026 11:00: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%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 11:00: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="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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=KBYwAnvbdjNZHrkxbLQynUxu0Z0J9UzLCBTZRqdFF 5c=; b=ZCvj6MyY5YRo75xXDgkwaGWKjbXwUd3k50Y/6wkxdA9UHJynPvx8SIq3M AcfsTSVFAmSfDQB0fxuqb4joz9Wqq1lBh/m7eenU1UFIW152MrbeKw+gb0K1TvdK OVpbir4G4v8dWnrwnW4vPdFrHSIFVXbZGMpDPH1q3RSyjkRp2As6+qfxRXLlBPdN 9mJGb+aaMpqps7EJf5xr5z8WlTLHFUgNN3OK0tvpam1MWbmYbOGEOhMeVbpGaTJZ oyhBhGlmy/UeDwUD9NIQ4DklO2ObW10kW0xxwK0JENGiWMb9IzJUXSKo2eOmns3I bm4II56aNcl3ym2+ILd+aryf+1+dA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=g4bWWI57XD9154dtvNxnToPF3bQynN+iuZxOwZgHDmfkgwwEvxpHz+JvWlu6S6GSTCNi8bNmx0KYBc5BYZGf1Mb4+fbgm9vZTqLvpld8JmKfbygzUgfbXmGF9iui11JZTO7lAvZuScfql0faAXT6fc8MF19Lr3j25vbBl/JSaCWLiOITW94l7DjndBT8A6oiWjBGestw9frKBmAke2q6VBZwWZZ18Jy5g2UMOsn2WEZrAgDc0HNS9oqAW8qa9uFCyMeWVSlUlF2hAEZuK9PEHvlkxFukXKwi2bQMI6RWKPF9sHpcFWtx0E2aS8DFTLD/vCjI0UMpZjQn5eLDcNhwIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KBYwAnvbdjNZHrkxbLQynUxu0Z0J9UzLCBTZRqdFF5c=; b=HwHiKPNKC4AmWnJdBPpfSbXhO4spWR0gYzbhA/HeJ3VvuIjyAFanMJFUNsRgA6MklziFw4aC0oct5VWfgEoKId0o1FYlAWYB7otbLb0tiIDhZy0GpTF59lzBnOCCGM03wAPFLyQQTCkuBFuSiXX0WGrlmEITaQQGxqs95vWJJxba2Vi9Zj2J2e/QL5aTRafbP4XVAGE1ZnoqPYCxfzalCzm55xqjk7ai1Aq2zX1+LCb72GQM8V5uBhB4+mSlXMg5+GxH+IeV+3og9HWdikjUiCpKyhJqH+bGECs88PiaCW6aMSSHzZ9CxDUJR00NhAx1yI7lsZAmSWSzMsxITShdfw== 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=KBYwAnvbdjNZHrkxbLQynUxu0Z0J9UzLCBTZRqdFF5c=; b=BZPlhfzlms1Fj6R89nM/H4nFV0BY09r8rX7pksyfymY8PW2ZCAlvNUktpBzX4dbElLpsuGe2welHFZcK91YvnRNqxS5VEY48t0UtSwywEG5QixohA2Bgm5Rx8mw5Xj+dXgDGIDvWUlop7ZpD3Psp9vIwyxEM0Cp56HK8vy1qmHClf63BNlHw3dVshmyAL3dgf3zrtcniC5cSFsg5P3koiiBBllgxNbTQgGkAQtpcz4rtnqeXgAvIK75+7acaCXtHcQHRVL1Xl3FYLSMMsQsTF2I+VLat+pSYBY3X2szuY+x5rh/5l1eDxKMk1uCi4TOLCht8C+UFpaB20Ah5owcHEg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <876b66cd-0ea6-4943-9a0e-c0abf2ad6e26@nutanix.com> Date: Wed, 14 Oct 2026 12:00:20 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/22] i8259.c: move parent_realize from PICClass to I8259CommonClass To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-6-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY5PR03CA0009.namprd03.prod.outlook.com (2603:10b6:a03:1e0::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_|SA0PR02MB7209:EE_ X-MS-Office365-Filtering-Correlation-Id: 46173ebc-b5be-4608-0704-08df29e25a46 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|56012099006|4143699003|261009223027099003|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: ZGJBoQWpFqccJUT4Ppb8RB4+eirfTMzvJG7otdwjLLdHeNJ89Euwywez+eVLKBCtZAi7YPJ1ntI7o3psMbRBX4RoAyqR2Fu4X49W/bSzUKNU8/waLta+q1HJjUXTmsRNOi2P4CDrig1hua0r/XhWT3MaagtppmRs8JkvFTG+9jitHoqfU6dMAwjP3UMqk4WAbLFCyc+MiXciVqFXbopSsdTSRvpl872JUv81NUunl0CqmY61KCaFk9koy/uEYlseADyE7UKu6PXlKEd2WK61SDQcMrYRCr3E1y4M6j3aHjN78UUTNL2X9iOdKL1zc+PUyBpS/iI8wGR+TG2eeid7BkYvsDDzfNBAaPvJLrSrn9LXaqxr3K+wHlBKv00r3zYExPt7tbtzhuBU7pmZx4mdOH27W8FRbM17KasfesGGwmB6MC7DKPLg13+11Fks/ZaIpCY4M2QQ7eJEQzcaZYBMf7KlWGYjHMtyUIHT0Dc9MyHqeoPLefNsPLgJFlZTdn1gjjgHqKXhxKv/iHgLPSIkiwFmupA+Y0HxaPHZntNB2BTFv9uqVXTa5s9QN+EXdcJB69uRXZrbTotQibkmvEoFXrUGeKHMdx4NdJkvqFcnwg3I21FEiH/wtk+QLHn8b8nRGPrfpJRPp5WZT17Tvg2QYk/bbBdQhgAUyLnq/dXChJ8= 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)(376014)(1800799024)(366016)(23010399003)(56012099006)(4143699003)(261009223027099003)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZmRZUUNuSGJHL0FnVnVBWmduYTNtQjRlZjV3RjNPMEt1WFVSWm9pNUxPT3NG?= =?utf-8?B?L0s4TjhUMFg0djBxOU14NDY2UlNEcWQ3b3VJSHlFRlBpY2lwTkdGK3Y0NFpU?= =?utf-8?B?SmdzNnF2cy8zUWFYUGVRYXJ6Y0l4VmMrTCtoSW5TUzFsczdvU29sSEhMWGpF?= =?utf-8?B?TDFZRFE3WGxFY0IrNkZIMzAyZjBpclI4cENFUWVBRTYwL0dhbTlwVDdEaXpJ?= =?utf-8?B?VHIwb2FhWERnWDN5UGgyWmVUbUlCRm1rejhZRnpCWEdGYy85VVM0TTJkYU9n?= =?utf-8?B?ckFkVksyN2tuK3Vhd2l2ZWJNYWNwUStRczV4VVU5Z1g0cDVaOVF4UG8zNG41?= =?utf-8?B?Zkgya0xlRlkyTVUxTTJndFFWMnpnejM4Nm81NGx3OHRDSDVhVHAyaHNXTkM1?= =?utf-8?B?dC83N2xGaDRHNTR1NloyT1JnR24wcElXOHdNK2tIMUQ3SnNhT2c1WkpxMjhm?= =?utf-8?B?c2k1WXlSNEV0OFBJSzV4U3VtbWI1SHVEQnJaRi9EM3ZRTHZMa3NNQzBWb3FH?= =?utf-8?B?RlB3WXNXeGpuYmg4bWRxN21EbnE2cXZHQnNqclhSeGVVclhFYnZ2NFJ3dGFu?= =?utf-8?B?WlNWUkdvWlNyeXYvUjRUNlE2ZjFNMSs0VlkrRjFqdGdiQ1FTM1d3dkgrYUs1?= =?utf-8?B?aG5FcmpGUUxQa2VUQ1IzNHpteGN5WmdXcHFXa2pCZ1dVMDFHSHVMbXg5VDc1?= =?utf-8?B?ZmZpK2VpTWVJQ2QvYzh5V0Nwd29rTFljZ3hjUDJTMmY5YXBOV0o3TjRuWmQy?= =?utf-8?B?UndNNjg5bXdxYzk5bUExR0RPMUFQRUZxZW5NL2g4Vm84cVBsZVVCK2x5QVZO?= =?utf-8?B?Y0dNbWszZEczUzBtM2FBUkI2OEJySHBOMElaa2FJR014K281c25oRVZrUUxy?= =?utf-8?B?bWVzOWdFU0xQV0U4NnFFYzUycWVSeDJMYWMrb2xoNjNTUTJacUVFQ2syVEQ2?= =?utf-8?B?TkRNZ2R3TEpTYTZYdEhtYkdleVM0VzExSCtOcXB4U3JKdTNmVVdUQ1ZvY3la?= =?utf-8?B?VlU3dGRiSG5DakVPQ3NseklZR3JwbjkrbTlJRFl4UTh2eHR6RnZ3cTFjU3hZ?= =?utf-8?B?YjlpRmxNUWUxNm0ybnZnN1hzTUsxcXRsTUl2YU4rTjJEK3lLTGdESXhGRGZr?= =?utf-8?B?NW52SkM2bnl5eHIvaGJTUE1rdEgyNEpMaC9ZT3RheVZDR3hQSVZUNXBjTC9a?= =?utf-8?B?eTB4VFlYTjUxMHZwM1NZUFRWMnV0OXRiei8rU2hoZFlJUDJEaEEzaVhPa1hz?= =?utf-8?B?b0E2QzloSnhsVjVpcDNBRFZDcm9rMmhrRUJXMm9hcDBTeWZDKzR0R1M4NEVx?= =?utf-8?B?MElmL3ZpMENIZFRLYXQ4NDRhSDh5Ymlickp5dHBxRHp4TXN2MFV5VkluWU5O?= =?utf-8?B?Y2J3TWlQMXZFTDd1RTVqV0lsT25lTGVoc1lWNkVpMlBPRTRJNlJMWXlZYlRX?= =?utf-8?B?TTB5bG9kK2xCZmIzaDQvWWFpdVl6VllKU3lJZVpHNGx1S3BhVURSMTdSNjFT?= =?utf-8?B?dFJHN3Fyb0VrOEhoS1VodlNtVXJtRXA0SjAwek1Uanh2UldWcUJDRE9rTzAv?= =?utf-8?B?ZURHbUNWUmVwMkFkenZRMnV2cXNxb1BaeXZONDR6SEgrMXpwVmMyN1luczlP?= =?utf-8?B?N3B2a2c0MkVnQ0Nqblo4MzFpLzkrNysvUHJDdWk2ODVEVDNwQmxOUkFYa3dH?= =?utf-8?B?SzFNWEF6VG1aOHBwUUZLbG85M0ZaazhHSEhPczJ4MUgrT0hCTkRDVEJWcHZB?= =?utf-8?B?TU9vNXJFcTJ3SnJaYTRsNDRoNXp6ZjdyckIrN09XY0k2RDdUQTFFSUc5eDBh?= =?utf-8?B?Z2JFbnJlNkRHYnp5R1lKRE9wQmsxajhSVkxpWXpqUFpscW4ybm85Ly81eUth?= =?utf-8?B?b3VqR3E1VGtucnU5SmFGNU9vZW96bCtZRlRQSHRHbnltWGVnSzYzRWhhdnp5?= =?utf-8?B?WEpiWWp6UlEvTXg3bllJeHA0VUpnWG4vZk1DWjZYUjRmdU1BRnlBdnVQdlFH?= =?utf-8?B?dWtRTit2eXl6VnZhQ1JxUHJPOHdpRDc2aVBjOFNFZkVlMy9KY2ZtVXBuaUU0?= =?utf-8?B?T0J1YTZiSDlKdjZzbk9BRjVwUFdQS2tQK2wxOEdCYVEvd2N5MHg2QjF5NTBH?= =?utf-8?B?S05iUFljdE1vaVZoaEw0WDFpUlIzdUlEWjRsSDVVUzBpNTU1T1ZnVDJOT3NS?= =?utf-8?B?S0hjaUJSbnMwMjJmQld1MTZBU2NnVGlCMldEMlZUK3BCcEdjK1hEMjhKSGlH?= =?utf-8?B?MjFVc0dXZ1J4bVd1NVd0djluUDlLZFlnMGxQSDFSOUQ5WkpNL2llWHpMb2ky?= =?utf-8?B?end4V0plMVQzOTNFbjArQnBIZXFlWHREa3V1S0hVSzNadll1T3NHTlcvdXhi?= =?utf-8?Q?uZX3lOiB9B733pvg=3D?= X-Exchange-RoutingPolicyChecked: RbPrNdZzokPsxfoE4xoClneC+ueTp4BOLoiQpQk24Q+FCfthhcfww2I17x8hoaASBdMhV6tsG0YliCpXy9mk2z03uAP8EOmP2OTQcCqU+JPER60WoK1zOWGh1QQhZ2tJ/xyYVicArcwIcJUDtsFe2Z7V/y9+pD/2hmKqGIiEZjqXY2EOgrCIJWcWSL+IfMEtAACzjUtYB/v+B0r55dq2tIZ0yIs9BzA1hMA78Js1i/Yr6B/8SHp9lUaahwVg8MtnykukW4SCHwZiDS852Cac52qGqxm3rzNlseJJnwDhCHFZibJ+RSX+ONbtcdDD7YiZbuwl9a1mAWG/n83vHgNS1A== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 46173ebc-b5be-4608-0704-08df29e25a46 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 11:00:27.0385 (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: 0xEKrK3SZEXoCaFyx0G3qYt9Z2nU+BDhSJYYcAJaMWV8diXf92DAznul3fhICzi8Q4/JOBRKl8Rs70dwIpr5UBVRIARB+4GGQjmP18JinjI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR02MB7209 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA0MyBTYWx0ZWRfXyK9tZ3oJPo5Y Kk1Ri7VXXRv5fd+kC5sCU+MVxuNRuGVULnKRfw0vk1t5c/d37YxaY3yW9plQI0QR7b8C8skP4oL wFscrb7qtdgMYmguuN+koRtRUMMQwJI= X-Authority-Analysis: v=2.4 cv=BroIUoX5 c=1 sm=1 tr=0 ts=6acf60cd cx=c_pps a=IN/ktsHfyviFoRwGlsjPrQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=AWkEWHTIOsQDqs_bE0YA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA0MyBTYWx0ZWRfX4mB5yBKYqrBj zkpcQpITlq6z1EZyycJbv//wstKprYEHXnabH9D5REj3lylTw+okT4tbRuE3aI8F7zFuTP22y0E Mo3g2jF/wUlMhOo8JvNgsawZaZTCWN5Tn56G6UW1LgRwciYZaXMbmzizyWatGd0qGBIE7XYqtmV oAJulbqnIKI5rR07z/v7Res7hoFhe2aeUgFEHkqwry4fKuVNmWwbK5J0MHoQ20shnu6qmWNklrL 4vTQ7jKmtzvpZew8E4puz8HPbXIqI6l9gb3i4s04CCp04yJLTm6mHEe9JPgkGDjZDk8q9Y06l1Z qRy0z+AIOk0YIYZzJt5yZsg6POJewph5+eWmYbDjbBFt8N32Vr5LcNi3AQNdM/l0nt+7nw2Qaei +jZXxrTRsbvoDizgr1HzMKVOOf8Ls6KiU4vWN6IrUoijFaeKc3gJH97bsZSQzY51VE3CmOwh5jW 5O+vb6OGj36qBQTHLRA== X-Proofpoint-ORIG-GUID: L4g0Y_Yz4cX-YoZfZ-mr8Wb7Mn1wRLGw X-Proofpoint-GUID: L4g0Y_Yz4cX-YoZfZ-mr8Wb7Mn1wRLGw 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-bad1c0/1791975640-BD8C1034-5ADB8581/0/0 X-purgate-type: clean X-purgate-size: 1948 On 13/10/2026 16:54, Peter Maydell wrote: > On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland > wrote: >> >> 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 > > This is one of those things where I think we're not 100% consistent > about whether we think the parent_realize field should go in the > child class struct or the parent class struct. The name "parent_realize" > implies it ought to be in the child struct, though, and I think we > do that more often than we put it in the parent class. This also > makes some kind of separation-of-concerns sense too: it's the child > that knows (a) that it exists at all and that (b) it wants to have a > realize method that will mean it needs to chain back to the parent. > > The docs for device_class_set_parent_realize() claim the parent > realize ptr is stored "usually in the instance structure" which > I think is just completely wrong. > > I could be persuaded otherwise. As usual with QOM/qdev, I'm > mostly interested in (a) consistency and (b) documenting what the > "right thing" is. Realize, reset and unrealize are the three > methods where QOM's lack of convenient support for "child > implementation of method will need to chain to parent impl" > is most awkward. Yeah it's a tricky one. This patch was really just refactoring what was already there, but I'm open to moving it into the instance if you think that is better. I agree with your point about the child instance being the one that knows it needs to chain back to the parent. I'll have an experiment and if it looks good, I'll move it to the instance in v2. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:01:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:01:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448746.1664778 (Exim 4.92) (envelope-from ) id 1xGwjm-0000UO-Fh; Wed, 14 Oct 2026 11:01:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448746.1664778; Wed, 14 Oct 2026 11:01: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 1xGwjm-0000UH-Cp; Wed, 14 Oct 2026 11:01:34 +0000 Received: by outflank-mailman (input) for mailman id 1448746; Wed, 14 Oct 2026 11:01:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwjk-0000U2-KY for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:01:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwjk-00136U-12 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:01:32 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6104-bab6-0a2a0a5309dd-0a2a450bbe4a-14 for ; Wed, 14 Oct 2026 13:01:31 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf610a-b7e8-0a2a450b0019-94a39b0c813a-3 for ; Wed, 14 Oct 2026 13:01:31 +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 69E8Bfbw3105948; Wed, 14 Oct 2026 04:01:26 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021101.outbound.protection.outlook.com [52.101.52.101]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4h9nym2uv8-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 04:01:26 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by SA0PR02MB7209.namprd02.prod.outlook.com (2603:10b6:806:da::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Wed, 14 Oct 2026 11:01: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%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 11:01: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="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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=/h5X6ade0D1KIgeNMgTJgrE+TeCtanc/wn/Z6/pSn Ho=; b=QlSMOEG23qfShfEShRW/RaP+lfjAagXsF1d48LnulJPlxSMqY5kg4xNSu ADKx+auj/Cd6zt7iuU1YpFPAMLaHT+xZD/992ycQpYVqMHno1o1ilSoa97RGIHL7 118/xrf1gNSOyMcnZnrBRC6F3qzN9JKQEW1deEiyedVDXd9V0jzuXIEqJONtNEWB nGmjK0Qz6GB8xJQLf0abfhkehkLt5E9zfmnglDbc98l5Ud8Ydb+2skz/OZahGRob pE9RXkf/i5dvKOc6HUfDuqI+qQcICAjmYr1HzgGulHOq99sjCzDOaKbYd7ipETgv Tg1FhkWtO3Q3txlXbcwC/kMimFtjQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Edg7kCsQctUWad08IM+inWPJzAThecjhyFfxB78R9JcIMoUk/yPkq4w84qw5z0aSwZLTlq+mfiJSJ3SJuyzLtMvIgBkizLng4C0uD3a/WFRBcO7gnROrr+71P7HZ60fGgFchGY3BZmpoghJrW5uZiA7QuTKbaNZqD21736Ptj7gseSWF+7U8iDBN93txHrDwGLSQ4b4wtvIo3flfUajg9YFBgjOPCox0e/fKHXj2so5AQ+6RaQp3YFgE4YFcQL/r7Bwlc7bs+QgNZx31UsoSWsAyYTgrOeM2tByEXudTpsNZmcrgBD2b7fOB7ii0HiUmQGQ4Pakb4fUF0xtnOxzrtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/h5X6ade0D1KIgeNMgTJgrE+TeCtanc/wn/Z6/pSnHo=; b=o7aIYXF7q7lFnkNiXV6VBInmUOkqDbsokZXBjLiVlszNeUKpRBIkQDpNpmRarTfRYzUOG5Q40tB0uLyNeRNODSFTekCU/7xgy0t3eqs0OXWum69Syl6PEMMg4wk5KQmVxRZblTXO2TKacbdolu7jtOTVJa/xiEsQm+NnufD3RhJ9Q31Tki7r/onYCmq8OLtm36Of0AhOXSd2J3OoJeLddpoodOmDIOUHvQ60DrD5PoN5DVtnnsYAEOoV5z29TZiDu7++F107CE+uocPK5WpUKLdmwTa4//2EP/0xlSDbWJ8xaRjM0P45yKyri5VNfS3CcjlqmeNSNQviPQeqd4NuZg== 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=/h5X6ade0D1KIgeNMgTJgrE+TeCtanc/wn/Z6/pSnHo=; b=jcZskxjl4Z76EDAkMGlyZEdmqxXMA4I4pAUWVhrug5bura3gRhJ9Nzk0x/IWydTX2qO2YqyJoIk6zzVsFRWsDrHjCEqzJ4E+jhIKA5CxAbfxqRSeLvc3Dt/26qA366ey79uz9cQiZADI3oQH1aae5ZDpNXe+Q54T0Uo9tzCd+LbneyYl2U2eCgUqVrgv5zfh31ub/U+Wa4gripOmvNZfuTkmaKlqQxOzJQbiVMd/PqzBQbg4YFASauCLqvxs81NfoR1BThvComNiiWiwn2TJfk6yXj6QrBsMI0ja4ukL8D7A8B3ng1NJvN4BgV/zTQvvqVgnpt8rijLuMsc7HZYWAA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <64f44dfe-2a44-46a0-8dd9-53d1a1aaecaa@nutanix.com> Date: Wed, 14 Oct 2026 12:01:20 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/22] i8259.c: use i8259 prefix for functions To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-9-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY5PR03CA0013.namprd03.prod.outlook.com (2603:10b6:a03:1e0::23) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|SA0PR02MB7209:EE_ X-MS-Office365-Filtering-Correlation-Id: fab1b8e9-0b62-4999-4069-08df29e27cd7 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|56012099006|4143699003|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: TM3B1roEPsFmcC7jxz7zUAzAK6OnPrRC2IBJHaPW3e55awn68AFK7IdG1ZGORRnaAMiuOYMIE9xVd2y/JlvGsLyUF4DsDIxphPGlJY/FzbIEr1aJfuKQBjh/Cf07YzXQ/BI2D4EXT3raQWTWBoVhr2HsLk/bNPta0W6rIHsLikeKekFujCIqA5CpXKGYeYI+sf+61TTHjfQDKOXEBfu43tX0EnTHpilhR1vXbQsw87Dji+OYPKl8ZWmyMPvSv8MNpFHpY7pL6JavEXRSYt3IwirjOXwWk7qeZJH+P6d7+VFXaj5gwbzhtoSaV9X/P6LI0hpHbqlQYa4Xs/1VR7DuUGBi+4MM9VlmrV/wq1roECsE0hwwwMUpdbYn6fqmfRVsUHuwphHKmQh7n0koq0LP1jMEH+YEV3QDymY3S09YlwH/haKeWsoLx8DOodiXo06WRAeSfxOP9bn/EBwaNifR/6fLbLkwE7mafka17vDOoIB4F5Lhq/ngnaFKDvSrlLFx0V4rnhoeG6OfFEgQri7Xr0WZFvX26xRZ5vrr7yLk6PfCePUxCNDnh8NiPxwuGmD5C/cE93MvK88/FzRV4jG8aDjVli0DOxZpTuDwkNBOnys411h/+phuFFdsXkdzulWr7gmrg+BlRFtCBV6zLTKtvUGrtV66ikb8OD5AFoPlLds= 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)(376014)(1800799024)(366016)(23010399003)(56012099006)(4143699003)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z1N3ZlhkdmtYdmhtSWJiUnZ2SGIveVppRk0vazhpdkZyNnpMTFk1eHEwaHRr?= =?utf-8?B?MENoTHlaS1RFbXB0SVMzSVRUekpadXIveHRaV0J6cVBnZXJYczRBTmg3ZGZR?= =?utf-8?B?UEdpY0gvQ2lSUXo1anFoWDRZN0l3QnpZSHhvSXRseUIxUEIyYWsyQ1c0ek5o?= =?utf-8?B?TlZXS29QbW5lU3BlSTFGekh6V0Y2YmZsMWZMWm56dnVZck5CalBnZ0dWb3Iv?= =?utf-8?B?dkdYNVoweG43OUhoYnJaU2ZVempLYW1HTlQ3dkx5RndXYlRrOERjb2thTVJh?= =?utf-8?B?NjVtWFFsMTVsaDMrTTdEWjF0UTJFenc4WHBnY3h5b2ZmZlpxU1ZEcTJPc0py?= =?utf-8?B?TkRRcWY5Yjg3bzh0bVM5d21KUUxENjBqMmt6ejlKekVTa29TSVFITjlYc0hR?= =?utf-8?B?Vmp1RFRhNlh4YXdaUVg1UVc0MjBnbEdSQmQzRlBQTm1vZW53NWpxYUQwa1V3?= =?utf-8?B?RUs0dVl6ZGRiaVRNL0E4Q3dBZ3dhYWZUWmtvZUJTUGRFc1JrSmlUczJGelNz?= =?utf-8?B?YXNDRklOS0JMMmxiajVBS2Y2TzhmUkM2ZWJ4L0MreXZwTkpIOUVrNmdPY0JR?= =?utf-8?B?RXNVV2dPTlF3Rit4K0JnY283dExweWlaUXpqMkladEVuWFB2VG5hL2NCSGhN?= =?utf-8?B?NmNkMlR4em1Jb3RZaDVYaE85cUNNYjJqdVdydERYc0hBQkVUeWVpb1Z3LzJ3?= =?utf-8?B?T0JXMVJLK3E3cWRBRTBvQTNpK3lFblgzYlB6ZkgvL2JJOE9uR2hoMm1JSnpo?= =?utf-8?B?aUlETm51YzVhQ29iQXdCY0wrUGVIa2JRNmZycEd3cElDamt0TTNSbnZKclJi?= =?utf-8?B?VURPTklsZjRRLzFtanBhZ1VDWkFTWk56Z1VVZlplVVQ5NGdQaW9QN0JBVG5F?= =?utf-8?B?UjlmeTlrL0QvOU1JbklxT0pMcUlMZStQd25TckhUVmZTRWNzQk9xR1JHTitt?= =?utf-8?B?NlhPM001amExa2Y3VkY4K1RoSHRCamFMUm5SUE1JRDh0eExQek5tK0EwTkF4?= =?utf-8?B?cHdRcVhkaXZQR3ZrS1hOZXEwVHZXOXVtaURlcHNpdFowWThvK1l0dUhGenRy?= =?utf-8?B?c2lmNEVvNXV6dE81Vm5zY3owU1l1eEc1MFNwb3JyNFl1bzVCeU9lcTRaWTBn?= =?utf-8?B?eXBIUEp5UWJ5MjdhSHVKc0lrdUJvMjhCWS96eW1DSkwwaTRvKzk0dzgrU2sw?= =?utf-8?B?a3F6WGVtZEN6WEhaR1o1MExYdVdSSjVWUjM1SVJ0TjVRRS9rWFA2dS96NWQ4?= =?utf-8?B?WXczRDRWb2hqVXdodjRzVzhLb1JoZzJaVnp6Z2FKZW4xM2xBdXFybW51NU1x?= =?utf-8?B?UUhTZVA0S1ROZjNzM0NuRkpPQ0g2RGt1T05FVDFWTk9uSXc3WXBhM2NYMUg4?= =?utf-8?B?RGxaN3lPT25mS0tXY2xNRUQ2dXRMZExSeUFnQzVXMVZIa3BUekJ2TzFiakp6?= =?utf-8?B?L3pzZGxQWU5BQ0ZRNGtCcHZZazJsYm5saW5yVGxQL3Z2VmdMUmdJK1BHM25V?= =?utf-8?B?SHU2RC9JZlhMVmFUREtlaVB5cENOUFpMeGllUzFkakRVQUxRRHhDMEIxZEx5?= =?utf-8?B?NUpRZzNjbkdwQ1NqcEk2MDZ1WDNnZ3RiMjRIb1FTZCtuTVZqRWhxd1l3L3RX?= =?utf-8?B?SXpYa3ZFRmlUb1M2TUVXcnJnQnIzQ0NKaXFENzlMOEwvcUs4OEFnOXExOXFV?= =?utf-8?B?eThKbUJLTUVyLzBUWDVEVldYem5pSGp5QjgwWUI2eXpYMDEwRGR0cHBVL0JI?= =?utf-8?B?MWlmY0xEKzNCYzRKQkU3QXJzeEFvenR2N3hvYWJmWmQrSFdSNWRqSEYxSkxN?= =?utf-8?B?a2J6UW5jUWJiSjRBSU81NjdzYjFNUXE2WnhYTlc4UDdieFdXVEFEMGxxVksy?= =?utf-8?B?eDY5QnE3SFowUVM5ZHF3Vk9GUnVuck13M2p3anlJb0l0Vis0ek1XZ2pPd0lR?= =?utf-8?B?SGN2R0JtNTNsUkJTNkFvcW5aTFFBbnJTVGhjY2psL05PcEYzSUZLR0tUTE9p?= =?utf-8?B?WHB1K1NLYlhOM0NSblVzVEJ6dGl5VGQ1ZTJTNThJTHlnOXplT3ZKQjIwSHk2?= =?utf-8?B?K3hCaExJeHJsQ21ONHloNU5aNXAweU9KMGZDZ2s5WWZodTR3NmdqZDFCeGhj?= =?utf-8?B?V2I3a0xEUU1LTmFpOUUzVmNDZzc0eW1PdnVMRFlYQVpjRnEzeDdlSG1MUHR1?= =?utf-8?B?Qk9mb2hBTDNFU0ZmaDg5dWxSQndiZjljMTR5UnpCemIrQXJQL0d1NG9Cd3ZD?= =?utf-8?B?L29pR3dCOXZoa0ROS1lqZVVPckpBZkZFc3N1WWZ6aWhXOEZZWGdrdVZsWlZD?= =?utf-8?B?VnArL1NrQk5PWitMa25GZnhEUjl4YnBlSVJsZXlYYXdHbzVZU2Y2Ly9PUmNK?= =?utf-8?Q?mSSrJVLXPFYfpXMM=3D?= X-Exchange-RoutingPolicyChecked: oRSjGyR2IkFO1q2vHhELQO2L5c8riDPZys9Fjvo4t+yFjPcfikitb6MPPE11t/VFVXeG+YM+sYYzH+M6kyv5838GrsiWGpfu4TDz4ALn0EaBDnYmf1Qd/Gvy0rTuFWuV/8XbvJY79PoQ65BvxGs3FhDdUHqJ7MLXKmS2hQ49Yhsu0rnBjC5e8yQuPgNYMQCi9fkVZ3MrLAyU/gJBCqA2e1GMSAE4c4wldgumgtYBcMH1HoZazcGKI8M2uVkY9UIBonww6t2UQRdsoBxmh7iScSX70S8l/6qAas0p1WlNQdIbYezeu3OYIGEKAgBFAYhr70o2jOo/gDU36yHu8AM0Dw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fab1b8e9-0b62-4999-4069-08df29e27cd7 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 11:01:24.5951 (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: xT7mI8jsGJlPxIljHguUyhCZ+N8925DKfYt1uQ3RAyVaUEbm5pu0gr6bpW4qoypRXohQfRPqVJl5VZJ5CAamiJsSlaYt9drkulTiXpGVYN0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR02MB7209 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA0MyBTYWx0ZWRfXyu8/JglFJp+f HZaEd0NWJ0rNcoZSAc3wYh3tmtuHiiQaZCIlC2J7sDm+btpiqM44X0HqLHXa+36CWr/0b67RXH4 BoXYx++/uCpYrv6xAnelsz4rHDc200ayhBW71muf7pj6URumIHTW9mSlxwqrF5bgsD95F0+adLK QpTmcB/H8LWIjlNebty2d5EwIra+k266IooF5uoQcAIyrCPYUq70CZG+pEJwdwZA3WU19SPeYkc nxZLZfkMcIQavmP917+XHhcLnP+gCdDlE8mXOQs1Wl4E6b+SboX+3vVB5WnS5mHanaiaBzZvys2 eR8wVVKXVUAy0e8EHx71YFGastkUdTSFQC/Tc3a6RHx18TWgXdjNV8O+PGYjnRQkhxEaoQz3Ntn vMUhq6UEZVJcmUEWQybt0W9GIQXJ56HpEF6zHOQmHbkFCBxIGKbm7gYqRAIlL6Fsgp3p1ImtaWr RkT1VZNVxEGaotYqNEg== X-Proofpoint-ORIG-GUID: 42QwuES6200Ydmh-CpijHrmnnDXYbpYb X-Proofpoint-GUID: 42QwuES6200Ydmh-CpijHrmnnDXYbpYb X-Authority-Analysis: v=2.4 cv=OIuyTiaB c=1 sm=1 tr=0 ts=6acf6106 cx=c_pps a=3cYuoP5kWG2k1oDcrssWdQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=VlnWKJzpNakxCJ2wiJAA:9 a=QEXdDO2ut3YA:10 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA0MyBTYWx0ZWRfXxcVNmcaxvyRK TCHB+WwDD6anKREk+sJcGuV/8utMT+YhkugqLOT2Q21YSqxg3wTsPOmXmzrL3fxe0sUVhlHaEHa DxJAqgjSwe9vV11KVmFUs9JitwO+Nhg= 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1791975691-1A8D99EA-21761222/0/0 X-purgate-type: clean X-purgate-size: 825 On 13/10/2026 16:58, Peter Maydell wrote: > On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland > wrote: >> >> This ensures consistency with our normal QOM-based naming convention. >> >> Signed-off-by: Mark Cave-Ayland >> FIXME: rename trace events? > > I recommend removing FIXME comments before posting patches, it avoids > the possibility of reviewers suggesting you do the extra work :-) Ooops, sorry about that :) > I don't believe we make any claims about stability of trace event > names, so we could rename them. Should be a separate patch if we do, > though. Okay I'll rename the trace event to match in v2. > For this patch and with the FIXME line removed, > Reviewed-by: Peter Maydell ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:06:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:06:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448757.1664787 (Exim 4.92) (envelope-from ) id 1xGwoo-0001RH-3r; Wed, 14 Oct 2026 11:06:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448757.1664787; Wed, 14 Oct 2026 11:06: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 1xGwoo-0001RA-1B; Wed, 14 Oct 2026 11:06:46 +0000 Received: by outflank-mailman (input) for mailman id 1448757; Wed, 14 Oct 2026 11:06:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwon-0001Pz-Ga for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:06:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwom-005B2j-5u for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:06:44 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6238-bab6-0a2a0a5309dd-0a2a45099116-28 for ; Wed, 14 Oct 2026 13:06:44 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf6243-be1a-0a2a45090019-a0658309d5ac-3 for ; Wed, 14 Oct 2026 13:06:43 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id D34A583C97CD; Wed, 14 Oct 2026 07:06:09 -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, teddy.astie@vates.tech, Abdelkareem Abdelsaamad Subject: [PATCH] x86/emulator: Add Linear Address Space Separation (LASS) support Date: Wed, 14 Oct 2026 11:59:49 +0100 Message-ID: <3e42ad91a038fe21b09f2bb7b6b8a47e1c8d6718.1791973459.git.abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1791976003-3ACDF034-2C26A34C/0/0 X-purgate-type: clean X-purgate-size: 7286 Linear Address Space Separation (LASS) is an architectural security feature that is intended to prevent cross userspace/kernelspace memory boundary access with the CPU hardware support. Unlike the related mode-based paging protections such as the Supervisor Mode Access Prevention (SMAP) and the Supervisor Mode Execution Prevention (SMEP), LASS provides the efficient mechanism to guard against the cross memory boundary accesses without traversing the paging structures. This provides a more efficient guarding mechanism against the class of malicious software attacks that relies on paging-based timing information, see (1) for more information. Enlighten the x86 instruction emulator to comply with the hardware Intel's CPU support for the LASS. The LASS violation check logic is adapted from the reviewed logic in the Linux KVM mailing list (2) for the LASS violation checks. [1] https://cdrdv2-public.intel.com/774990/architecture-instruction-set-extensions-programming-reference.pdf [2] https://lwn.net/ml/linux-kernel/20230913124227.12574-16-binbin.wu@linux.intel.com/ --- Testing: - With A virtual machine setup with installing the fedora rawhide/f45 development branch which is based on the Linux kernel 7.1, I verified the following test cases 1- Using the Xen Server, I enabled the lass cpu fetaure. Running the command grep 'lass' /proc/cpuinfo is successfully reporting and verifying lass is supported by the guest kernel. 2- On the setup guest, I wrote the following code to verify the kernelspace linear address access from userspace is prevented with #GP. Disabling lass from the guest and commenting the FEP is rather reporting #PF. int main(void){ char usrspace_buf[16] = {0}; char* usrspace = usrspace_buf; char* kernspace = (char*) 0xffff800000000000; asm volatile ( ".byte 0x0f, 0x0b, 0x78, 0x65, 0x6e\n\t" "rep movsb" : "+S" (usrspace), "+D" (kernspace) : "c" (16) : "memory" ); return 0; } 3- On the setup guest, I wrote the following kernel module to verify the userspace linear address access from the kernelspace is prevented with #GP. Disabling lass from the guest is rather reprting #PF. Executing the code with commentted Forced Emulation Prefix (FEP) and the lass feature enabled is reporting #GP. #include #include MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("Testing Module for Intel's LASS Xen Trap"); static int __init my_module_init(void){ char* usrspace = (char*) 0x00007ffffffffd00; char* kernspace = kzalloc(16, GFP_KERNEL); if (!kernspace) { pr_err("Memory allocation failed\n"); return -ENOMEM; } asm volatile ( ".byte 0x0f, 0x0b, 0x78, 0x65, 0x6e\n\t" "rep movsb" : "+S" (usrspace), "+D" (kernspace) : "c" (16) : "memory" ); return 0; } static void __exit my_module_exit(void){ pr_info("my module "); } module_init(my_module_init); module_exit(my_module_exit); 4- On the setup guest, I wrote the following code to verify the implicit system (spervisor) address access from userspace is not prevented with #GP. #include #define XEN_FEP ".byte 0x0f, 0x0b, 0x78, 0x65, 0x6e\n\t" int main() { asm volatile (XEN_FEP "mov %[sel], %%fs" :: [sel] "r" (15*8+3)); return 0; } 5- CI tests: https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2946430503 --- xen/arch/x86/hvm/hvm.c | 73 ++++++++++++++++++++++++++++++++---------- 1 file changed, 56 insertions(+), 17 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index ef9c7cd057..3477d62d43 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -2557,6 +2557,40 @@ int hvm_set_cr4(unsigned long value, bool may_defer) return X86EMUL_OKAY; } +static bool is_lass_violation(struct vcpu *v, unsigned long addr, + unsigned long size, + enum hvm_access_type access_type, + bool is_implicit_supervisor_access) +{ + const bool is_supervisor_address = !!(addr & (1ULL << 63)); + + if ( !(v->arch.hvm.guest_cr[4] & X86_CR4_LASS) || !hvm_long_mode_active(v) ) + return false; + + if ( !is_implicit_supervisor_access && hvm_get_cpl(v) == 3 ) + return is_supervisor_address; + + /* + * In the subsequent logic, we are emulating a verified supervisor + * access LASS check. + */ + + if ( access_type != hvm_access_insn_fetch ) + { + if ( !(v->arch.hvm.guest_cr[4] & X86_CR4_SMAP) ) + return false; + + if ( !is_implicit_supervisor_access && + guest_cpu_user_regs()->eflags & X86_EFLAGS_AC ) + return false; + } + + if ( size && !((addr + size - 1) & (1ULL << 63)) ) + return true; + + return !is_supervisor_address; +} + bool hvm_vcpu_virtual_to_linear( struct vcpu *v, enum x86_segment seg, @@ -2602,26 +2636,31 @@ bool hvm_vcpu_virtual_to_linear( if ( max(offset, last_byte) >> 16 ) goto out; } - else if ( hvm_long_mode_active(v) && - (is_x86_system_segment(seg) || active_cs->l) ) + else if ( hvm_long_mode_active(v) ) { - /* - * User segments are always treated as present. System segment may - * not be, and also incur limit checks. - */ - if ( is_x86_system_segment(seg) && - (!reg->p || (offset + bytes - !!bytes) > reg->limit) ) - goto out; + if ( (is_x86_system_segment(seg) || active_cs->l) ) + { + /* + * User segments are always treated as present. System segment may + * not be, and also incur limit checks. + */ + if ( is_x86_system_segment(seg) && + (!reg->p || (offset + bytes - !!bytes) > reg->limit) ) + goto out; - /* - * LONG MODE: FS, GS and system segments: add segment base. All - * addresses must be canonical. - */ - if ( seg >= x86_seg_fs ) - addr += reg->base; + /* + * LONG MODE: FS, GS and system segments: add segment base. All + * addresses must be canonical. + */ + if ( seg >= x86_seg_fs ) + addr += reg->base; + + last_byte = addr + bytes - !!bytes; + if ( !is_canonical_address((long)addr < 0 ? addr : last_byte) ) + goto out; + } - last_byte = addr + bytes - !!bytes; - if ( !is_canonical_address((long)addr < 0 ? addr : last_byte) ) + if ( is_lass_violation(v, addr, bytes, access_type, is_x86_system_segment(seg)) ) goto out; } else -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:09:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:09:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448773.1664797 (Exim 4.92) (envelope-from ) id 1xGwr7-0002Kh-FV; Wed, 14 Oct 2026 11:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448773.1664797; Wed, 14 Oct 2026 11: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 1xGwr7-0002Ka-Cg; Wed, 14 Oct 2026 11:09:09 +0000 Received: by outflank-mailman (input) for mailman id 1448773; Wed, 14 Oct 2026 11:09:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwr6-0002KU-HH for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:09:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwr5-00CzCV-SW for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:09:07 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf62c5-8faa-0a2a0a5109dd-0a2a4507bfa8-48 for ; Wed, 14 Oct 2026 13:09:07 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf62d1-b4ea-0a2a45070019-94a39b0c7b84-3 for ; Wed, 14 Oct 2026 13:09:07 +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 69E8Mm3M3222478; Wed, 14 Oct 2026 04:09:02 -0700 Received: from sj2pr03cu001.outbound.protection.outlook.com (mail-westusazon11022094.outbound.protection.outlook.com [52.101.43.94]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4h9qsxth28-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 04:09:02 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by SA1PR02MB8672.namprd02.prod.outlook.com (2603:10b6:806:1ff::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Wed, 14 Oct 2026 11:09:00 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 11:09: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=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=ceUQZb/+uXyAFG6dehWJW59UQ6BGwcQSh+PNJeRoX Ok=; b=ylr4m+KzGyp5utofvPE19Lr/Nl302DEWXnGKlBXC0wXaEbSb5U3f8XsE5 3UrXv3iZKNjIR0PlEs7v/fZYbLFhcIh+xMN2rneN+EF5dmunkRpQuC0px396/Jhx EJRDonToHcTWTJ2zsDEmb/XvTKiqWbfr5Vd++eByJr4PAfwQIUFIAUcOdG4r3gRn 0PAT2AFmcRiwq+1Fy8vjNY1aCsDRVdbLJn8GKm+7ofF40V/8lkTBerEruYsLAiak unHPgZ4H9w4/NWA5MtMtrhGnf6fzPfHfm0J/uwXyHWDd3diqEJHcMn/c8BKAgEUO hDpwDt6z0rXawNmFjAX4kxwqDs+zg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZRCYMtkI2WQae9s7qEjNjDDL++K95zWEmMuBCzwqq2Hb1YpS2gycrfhh7E0Wevqh4D/nYN6LRYHhuF5AEErduPgW37aY0td0QnCjPtZ8uHz2YZ1bPGbjdIEl5mhcpDyQp1t2Fc23ebk/qveaR3bcOAhG/mdbC5njeq3NNAE4dYqi1xDvE9zePsIeV8I8/rIwZq/szAMPKgABwLNPj31rSguH5A1dQU7mBdA0SwoJqjyLF4d/Msazx97Dc7A3dVCaQl6iPw21ylXaSh17LCzJaFBMTD85ZgiHAXNS4ntfND5svZ197yFpcPFJV81IKp/JH7/qKuyl1+Sh9ge/hhpIzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ceUQZb/+uXyAFG6dehWJW59UQ6BGwcQSh+PNJeRoXOk=; b=Ayg5++xZJ7Y82Stbj4a6kuYLzQaDPK5Us/mCQNC/0q3M1xjh6nY7IXDnYIuQEFFUfb0ymzxo9QQD+O5fYLbMAbeiSqufLgVMf7fGKAYOFKEoJOPHvkd2uyaWN0PlNWkFPGXLJzSQK/Xbg7r0bQc4vdHRPVm+Hs0MsA3z0UfbZDAoMV9i+xvHlBbyJ3ylsN09nNonZ3LSRB3XjgjCcOKN8ZFkX6ATfpn4XzS5+CKoy65O4cCy6DOyC2ExXOWcXbcdIFZ0duZptDYfWwFyuMkAQFMOTnbqnl/98oIj9n+xrIWgmgekvXRO71mr6PzsNzonMtuTPW79j0x+i0aXtGPjFg== 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=ceUQZb/+uXyAFG6dehWJW59UQ6BGwcQSh+PNJeRoXOk=; b=vfAeEfxkjEdLL5PcSk8wTtQfz1u0TdaRwhmSOGWd08vjHfK3jZNoX6F6akujDSGINchpZytdmGiisgDTWJERPYXZHWeLRzwbm8xcRPjFIbbfwx2w6rd4vYLCHptwC/ISZYhIpjoA+/dZKA8qcuqfyOwa8m4PCoBcDz10TfTUI8VjpFHYopL8JwETYd5Ws64bZNaJcxWirXxgqDjDE/u+MmVrjVt/DosdElmCpYEpFCQ/a/8pXW9/zIU48L1rX17S3nXWCrG9w2nndVdrYVS63D+7KCxArt4oapjIpnQEZgavNSjQUWLb2xP9ASb+TmouBQmQDJNJE/9rp3fOF8Ybmw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: Date: Wed, 14 Oct 2026 12:08:55 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 13/22] i8259.c: introduce TYPE_I8259_PIC device To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-14-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY5PR03CA0028.namprd03.prod.outlook.com (2603:10b6:a03:1e0::38) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|SA1PR02MB8672:EE_ X-MS-Office365-Filtering-Correlation-Id: f66841c3-b061-417a-0567-08df29e38c6e x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|18002099003|22082099003|10067099003|4143699003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: HjLh7jhzegQVsBLL20qCabp9QDW52mQPzl6qfFqadYGIw3SVglsTU+pj6VSfsWQgqMZXiXVrq22jsx8dkQdrj62EyViw3mneLz1rdcpBKBcyWHZ818oSH48s3xJVmnDE56tcmNlVoSbPN0dtWbzSGWtdp4tCfV3x5Kv+oC5YXEa2WTtt0Ka1itNDHGR+70vt2zi9vZfDIDlLZpRwINpiuGPbpbxODtoS/zsthQXWjU3qsx+8tlkzBciD8d4dUMjEhrHsJKAPgIMgh84R8/wfeJEdMnVGOtS1IiNni9A1fNDQSxeNuvR6e00K/0tQDvra8qw0DJYsOA7EBvNzunnxMHCUy0yGGY8fmFwTRFavo1CBhaQJyHy1XaB1oU6ltY3PnCtZ0p68l5WC0fsdYiRNcOtfVOEU2k9EoCiU40NLrk9taK6UBTEYJ2FvmXeCO+36SJ7fyglU3piu8gYeqI8SWlVgFs3gLT6zMkAp/n+VPE3tpHKdaF2wSWQpaKS6DRUFEw8q2RPHZsx3JsS5Fbl3Yc4tYXxjb3vPgoU6rxiB2AF1i4yb55GoglMOKgs3ZZylDTuj9mz0lA3YEse/WYtDZE5fdu6i3oAl6Q+g+29qH1xm3YdeH3aq9qz5nsI8J17awu2gpYp53jBMF2os6xLh2HTtq0odaLuj1PnwoFUDBjk= 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)(376014)(1800799024)(23010399003)(366016)(6133799003)(18002099003)(22082099003)(10067099003)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bktYVU1nbXAvUDdPYmxyNmhzZ1BiUmJ1bHdDQ2Evc09JY3JpR0dhVHhzKzY3?= =?utf-8?B?aEx2QTNoWDBUeXFaUVpucXI2ZUdLNC9DdkpXOFYyYzR4S0s1M2VnZndtenVS?= =?utf-8?B?M2M3U2dOdVVKbjB1WHBKc0tYdUVXNjBRWnRpdjBBMTBjQ0tLNWdERTk1UWJ3?= =?utf-8?B?K2pMdkQvTjMxYVI2MHp6V2RpNXFPZWE0T2JOTDRibzZ6VmZTMFcwYzBmRzFF?= =?utf-8?B?Z1RIa1Jqa2I5NFZCN0NxYUF1OWZuT3JUM2wvc29IU0orTlhhWjNCUFJRSFRZ?= =?utf-8?B?Y1JJM2hRMy9JeElraWREdjgyNUMxM2ZCalZzYTJrV3kzYXJOLzVaK3pSNldG?= =?utf-8?B?bkwzd21jNW1QVTZXQWVJbnJobHg2dlNTbnlRMVRtQWwxVnpYTWlDVk04Wmd3?= =?utf-8?B?THdOb0ZqZ2RQRDd6cHFsY2FZU2UxSS8zODlxTUl2SzNqQUFGLzM4aVlSckJB?= =?utf-8?B?Qnh3ZFpBamdiUjVVbXZpK0FvTnZvVUpqbUZhVzh2MDF4RlJGMzhrcGRFUXkr?= =?utf-8?B?Sk1WalRpVWJ2ZUpjemdtOGlxS3BOK0grdU9NOU5MV1hoamRCbHNSQmZ3RFdu?= =?utf-8?B?NEcxQTdKSTZnWnkveFNBRE5PWUwwa2tkWnRqdktXamQvS0hPYXE1Q2RxMW54?= =?utf-8?B?MG5SSG9RSVVhN1U4ODFKc0t1YkExTkVFSWs5WUNHcFpZYllHdXRIbmNZMUds?= =?utf-8?B?MWo1djc2LzVUcDRxQTdjV0s3dXh2bHRLd2szVTVxek8wK2FWZGtjaEliZkVo?= =?utf-8?B?cFUvVitmVE5uRENqWDhNVFdHdVl2emExTyt4SDdSY0FRL0w2TStwVndOWW5i?= =?utf-8?B?b0tyK1RYSzZkNGladjNnaUhyTzdMZ0o2MXVLS3F2L05FYVhQaGdQeW12VDBK?= =?utf-8?B?UExoRzRoaUQxME1WT3pYRHJIczFzNjA4eWhCQ1FiczZlZ1hXZkFZcG01a1hH?= =?utf-8?B?bnZUckN0YUFjR2NsM2ZOOElKZVlsakV4SVhQVHlFRU0rcnBFS0ZRV2tHWGNw?= =?utf-8?B?bVJTTkIzUlVLaTM5dmRwTUdyMkNodjdVSDhxV1FzaXNHZlVXVU1ud2xPVzVv?= =?utf-8?B?K1dMcWg0amRMa2V5YWlqZ3VPWGJiTGM2dDBmdnpVRytFYWt4UUo5dUxwd0JB?= =?utf-8?B?VEcwTjR1ZDN6UG9uN0gwWlZWS2E0WUJTZEJPeWg2RXdqT2ttdCtxYzRsOHRX?= =?utf-8?B?SjVBaGM3NngvRVpWSkMwaU9kS1hKeGZrcjBSRW1kTlhUbmpuMTgvS21PbFVi?= =?utf-8?B?T05yQ0VYaTIwOWZ4RGw3aU5yV1lDWk1yU0VTS29mQlU3R3RYS215SDdPYy9i?= =?utf-8?B?d0xKQjFOVDVodmhBdm01NlNzaERsZHNMbEJwandLdGlwREhMRTlmR2l2TnVm?= =?utf-8?B?eWpza3VndEJyS0s5YzZkemFpc1F0RzBWQTl4YVNaQXBTbHp3WUtoTlJnYzF4?= =?utf-8?B?L2ZzblhRQ1VZelUyYit5U21Eb216a2x6Kzh3dGc4cHlYRXpkUGpST0ZHUXJn?= =?utf-8?B?dE91WDhnMGtlQjE5YUEycHZmY0RYZEtVUEhXYSs0Q01vT3FtdTQxN3EvSjBp?= =?utf-8?B?cDhKaThpMGdMVTd0VWp5OWdYZnpHYnNOeC8wK3ZMUEdRbmhHQ0tVYkZTK3Rm?= =?utf-8?B?cmxBU3hQK3pCVmdrQWErZ1p3ZVFPZU52UTBHbXZjenF5djYzYVlWSFBvUWNw?= =?utf-8?B?OHBqV3llYTZFY2xvSFlBYm5ETjc3WE16OUV6YmZ1b0srMW1iMVBxaVpqaEs0?= =?utf-8?B?YlBNVFJTdzBPV1c0NVpqUHhZTW5PendnV3hDVi92cHdaZDVwY3hnTWxZL1Iv?= =?utf-8?B?KzFFUWRIWURKamhQcjhDajhBcUIwWi9iaXdlQkRwcFZyTU8zRHBsQUx6bFlQ?= =?utf-8?B?U3o0Wm56SWpRcDVEdXlEMWNTSW9ka284NTlUNDdPSnJBTXl6a3dSNTRJdkt5?= =?utf-8?B?bG02QkNjaUc3TnRZUFRWNnJkYXpCVFdoQ3V5QlMyclhsNnZTMUtsOE9BRG1s?= =?utf-8?B?QzlyaWZrUDNIQXhMZHNmTGFRZ0FIMUNSeGtYb0o2RWJKZGVIZjZXMnc5REdQ?= =?utf-8?B?TWwxMkhMZ0RxcHBrQjVPZThTdXJybllsTmpNNW01Q2ZLN0tGckcrclFGUlNq?= =?utf-8?B?RWkzK1d0N1VLNVVweUVDUFpoSkdXU2ticGVRS0JDYTJwVWFqQWg0N0Nma3hE?= =?utf-8?B?VTVpT01rWThtejFjWkdiazVFTWVHblpxY01ENDdhOVV6VkUxaXI2akRYRWtq?= =?utf-8?B?T0RzNjh0TTc2KzBEQTgvRndBZnIzWlFiZDA5TjFCcC9GQXBTWW4ydkRjaS8z?= =?utf-8?B?ZWYvdWNDMnllZm5QNjd4OUpPYWR4YWo4MXVUTzN5NnA3aEphUnhkRXp6MnRI?= =?utf-8?Q?iXuNHn4dQi6bwG8g=3D?= X-Exchange-RoutingPolicyChecked: QFHEPuem7pTLVYjV66CSzeAKEdAjeEtAixGAZC/uHlQCf+fbxtykyzlLEx5PlkBeMbKBuBy9m5FQCWvzwjkxe00Hd0FrwHue6k/SqwLjSUJUZY/RdghttKG2dNvqAqalLNYd+T0tkwNVOW1zy5i1xTR4OnnNcBXxAbPYVZu8wlSr/7DS0VxwXgaYFeVUbs0NQdYBuoYm9GMrmis/yttC2TAx41Ihko/5iAnFUcefHGe3+W5jpfksDN5m0E8A1YGjO8wh0rEhv1mUU/VVihLTmrbRr8GdRd/MYGouXSEdU2rwCyga8FYHds4k7rF2YTzIMbhQlRyZxUD52JM87LZGww== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f66841c3-b061-417a-0567-08df29e38c6e X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 11:09:00.2340 (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: Db4D5J+ml4jt604Mx//K2UXYPcjeEbtZ7IOMh4cpD3fbPS2CsC+ISM8gBAVNpaD1ynoWE91jYE8+alDaWCA8bXpjlLzbvSE0vnj6+pQLKMg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR02MB8672 X-Proofpoint-GUID: 8xa-p4iMcHw0axHyTo0eEvtH_V9ZlgPS X-Authority-Analysis: v=2.4 cv=OeYNnRTY c=1 sm=1 tr=0 ts=6acf62ce cx=c_pps a=13WRnYNq68uQF2pe1ZmaJw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=aSKH6cZiDhi615JTPwYA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: 8xa-p4iMcHw0axHyTo0eEvtH_V9ZlgPS X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA0NCBTYWx0ZWRfX6wNEDceETEl/ aNAxfKNBxtDexxKEJkqlVhPFblYmUtm0yEvZUhIwq0rb/HhyLI7cMmZiPAT+Bqm33kBvWcXSyvb 1kG78wlBU1v2TzYSKHGPeu81cRNBIm/pMsUQ9Qg+RiEkNOrTFKMSx7U2wGKwTCn9fkiVCh8Lb5L 4mRcTFDac5FLri4Tzsx1G9oNcsnNjweYSsP8z8xwJ/j8kYbl038lsnidqhps7dQxKQsZFpVR9RG GLCzHjhYV67ypwMQgrPfzTHGhjQ1X9RmXhhRIyJcGxqDWIIy4es+rdErvg49RNj+AiS1aIeFDQP 62F59uEPDCT3RXEkisQiUq2HTmQSrGKW5WU4PvW0FWsofrnBWnUXv2u5okVXhtVUYUdOYUBm0Vu 6npTH+ZIQrVEd0FilzIIKLOkt+EARAD9geYKPkNqvkZgjEUgTrkx7jcNC+1bvmAIgwp5CwJXP2G o3NxpgrArQk2tz72PTA== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA0NCBTYWx0ZWRfX0E2wFliSYCXS wGJnEscOYPLlDBH6678XaCzUZ4BL8mE+swJn25Uq2VKaj7j++L2QtVpI1dLbrzcLcjTBfAafHo/ 2SVmq3DYqSjrAY1180CRyzDPrpIm5v0= 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1791976147-A60C5AE4-C304881E/0/0 X-purgate-type: clean X-purgate-size: 3025 On 13/10/2026 17:17, Peter Maydell wrote: > On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland > wrote: >> >> 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]; > > This allocates only enough space for the common base class's > instance struct, but later we do an object_initialize_child() > of the child class. If the child class's state struct is > ever bigger than the common class, this will break. That's true. In theory this should be something like I8259State, however I didn't think it was worth adding a specific OBJECT_DECLARE_SIMPLE_TYPE() if there were no extra fields. I did quickly check that if this happens, then the assert() in object_initialize() fires so if this did happen then we'd find out really quickly. >> 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, > > Devices that directly inherit from TYPE_DEVICE are awkward, > because they never get reset. Conviently this device doesn't > currently need a reset method, but still, is this a good idea? In this case I think it's correct, because the PIC device in this case is a container for 2 cascaded i8259s which are connected separately to the ISA bus. Therefore each i8259 will have its reset triggered via a reset of the ISA bus. The container itself can't exist on the ISA bus because it would then appear as a separate device which doesn't make sense in this case. >> + .class_init = i8259_pic_class_init, >> + .instance_init = i8259_pic_init, >> + .instance_size = sizeof(I8259PICState), >> + }, >> }; >> >> DEFINE_TYPES(i8259_type_infos) > > -- PMM ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:14:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:14:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448785.1664805 (Exim 4.92) (envelope-from ) id 1xGwvq-0004DV-0P; Wed, 14 Oct 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 1448785.1664805; Wed, 14 Oct 2026 11:14: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 1xGwvp-0004DO-U9; Wed, 14 Oct 2026 11:14:01 +0000 Received: by outflank-mailman (input) for mailman id 1448785; Wed, 14 Oct 2026 11:14:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGwvp-0004DI-12 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:14:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwvo-00D0Ei-E4 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:14:00 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf63f7-e002-0a2a0a5209dd-0a2a4508e2a0-0 for ; Wed, 14 Oct 2026 13:13:59 +0200 Received: from [40.93.194.63] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf63f6-f659-0a2a45080019-285dc23f18ef-4 for ; Wed, 14 Oct 2026 13:13:59 +0200 Received: from BN9PR03CA0596.namprd03.prod.outlook.com (2603:10b6:408:10d::31) by SA0PR12MB7090.namprd12.prod.outlook.com (2603:10b6:806:2d5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.15; Wed, 14 Oct 2026 11:13:52 +0000 Received: from BN1PEPF00006001.namprd05.prod.outlook.com (2603:10b6:408:10d:cafe::62) by BN9PR03CA0596.outlook.office365.com (2603:10b6:408:10d::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Wed, 14 Oct 2026 11:13:49 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN1PEPF00006001.mail.protection.outlook.com (10.167.243.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Wed, 14 Oct 2026 11:13:49 +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.53; Wed, 14 Oct 2026 06:13: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.53; Wed, 14 Oct 2026 06:13: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.53 via Frontend Transport; Wed, 14 Oct 2026 06:13: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=VW/aXjU7g/zxSGYE/AnkqvAZYfia8taqqHRFIUZCuAR4jXRGD9zm9P0GpyDTgAjORthsMEZzQVGLlGLTHkdvqF7ityJwxBwIcB+6H+hYcepCbRFGbAEC4lB+QpZ+U5VQkwvFriaq8XdvBseivrIoWvknpI667p8vGrFHEdrwB2dWbucYv8Cc1uvTlDrV/XwXiZI+vny3aqAXF8A7YHvZv0gP93VzhuJ7+cauDIBXGaBXmF+eb7FiJBbgI3zFyxuDX+jCLPzyznoW/89cVz0GQ+iz2YLFBKj4lTEaSPVkK7jw3+euU4YmA8purUkoSxrEoiM10MsGi9uw9vqCd0xK1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QG0iiK5AHSkN91Yj6j7J15cv20E7oo64Eit3FfQ24K8=; b=E9i8k3dkuFdJpu4zKiiCcXIUKSpyUWO//RCQwbicSrMU62qKgFig2z670CaRS+ZAjdY4xPAqhDUGG6NzIBy2lbNUvaQL9CkwDrg/8tp2eYk6zCsTflIYyCP4/PLwxPaKrX7edm1+0kHzt7kJOuZN3yoUpgE2NaRdvLlB7QMZ4GdHpuuSv2cXhSRhOurBXeCTPlP1TOJnwUudGAq1cpt9fV1zfMufT3aSQmQ9MplEF9uy9a/1M/VnZqtzmW2NiZS2eA9PA+73dsz8TB1rAfEnbNH1mWfffH0bdsaRQRaCmsvzp6Fn9gfaqZZg/scBWMYsjwnADe05+BFaszxIpQvXTA== 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=QG0iiK5AHSkN91Yj6j7J15cv20E7oo64Eit3FfQ24K8=; b=ghl9oZ9BFJJ3HVP1oZVSe5nbO0WncJaBEMsD8h94eQWGQ5PAlqS5W6UIDvH3J3hOUr5gki1FgDOMFLI7oeN2J2yONt7hgl8/M1uyIBHnxTvsRD5wcFQexCippMI33h8C4YC6iN0Xi6cwx7Wr081f8Pwe1vtcrTWYUSPP7oLKe6E= 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: <4e820fd2-6ed3-49bc-a41b-58af36790f62@amd.com> Date: Wed, 14 Oct 2026 13:13:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/device-tree: add a helper to dump an FDT in DTS-like format To: Oleksii Kurochko , References: <20261012073442.15819-1-oleksii.kurochko@gmail.com> <20261012073442.15819-3-oleksii.kurochko@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261012073442.15819-3-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00006001:EE_|SA0PR12MB7090:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e0a0124-b48b-44d7-b42d-08df29e43930 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|82310400026|1800799024|36860700016|18002099003|6133799003|22082099003|10067099003|261009223027099003|3023799007|4143699003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: 13Yb2yyFousUQH6Fq+X9bMjKkoO8/DKD+XrVlUWYPlQKAoiAXQexEEdSbvGygHgiDUQF3iGe7ZhuEVlmCeRNSnZysSJRIcv3byJT/woNeRcTssPqrwUu6gYfxXsQIrAd2qiW56WA4/fvsNXcdJFT/MJLP4VZlmMfrptoGdm9xNHHGpnuY07WDjhiOHWstaH4G6j4qZQQH63OB1+gXtY2bkgjqzgUV11EindTuPOWkhmdIygccrSDfNU47sJTI913fPEvnv6dZqg1Pi8FSNiYhztjkbjNhrvdvCbdba+wOXfMKkNj1rqNdJHsDAYYJp1Lv3GesoZ33EYN/9yeha7+r8Exh+G6K0buApX4/h2CiwB/0YFPzTL0g5H0zjm75jUWUNRuDwJn5BAAxrZMtcBk/dEi8N97wiWZTRhw/KWltDxSVOgjkdJFJKoRoqhVWdHl7JIjhnIdIqz1Y1C22qDuGfLsLrJAcxkDCj1L1UT425ue7317TVE6gHE5m42AuQDsnOlWpn/RgIuhoV94pzVGDklG+xfiYTi6WJ8Q4vXS+oEj6Ts0Krn75Gy/kEYtYguifUYkiKjrdkYJL+8btyU00uDYVrSbOczbUA4ReCKOFo4HGYvPCUTwgs0BiRRsF5NvDG06yYN2yYEHnCuSmZZKzzT0w8Fx/3Q7y2pqr/Uw8qQB9JinnTp41sAUI5ND7SCFCElL+oh7UVFVJoBtD33sWw== 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)(82310400026)(1800799024)(36860700016)(18002099003)(6133799003)(22082099003)(10067099003)(261009223027099003)(3023799007)(4143699003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 2E5eNqQMKbjVEinhkeLDBa2qVEXTZI3D+R5sFV9EJda4JqFg54y3qBo/RRwt+qlXt1BnHl720RdUlSN+7qhVqzg4j7ZvcTYIfQOex+GsLkNchrF8VJukX3vzu4VL1+FGI6BQaEOQ89rnL6ktxmXXwV1MydtBP+74EjSV9kmvHQLvFfMXMCLB5iqqluVxCmwVzI4EWL4Vtnu91gj6Ffml47fLsa3C1JohQ1J7Qr1eQ3LzNFs8ic8/w+wIzXD4/pUcQvAY/aHQUyPeUX+2pWizgnLIliiwgAlGFozu63oLwQKqqac9IsVf8nkhv6PX4EfkOx8uri0PFMkXSUwDMgRptahUtR9jC1dGoSDa6tGGQ+XcsqtXtRtxYh3dzXVPTWAHRB3OS27eOd7gPm3pLWeMD8v7roIrU55nBn79iF0/wxI4n3PVLjjQp/t1W2ZXX8tP X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 11:13:49.8253 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3e0a0124-b48b-44d7-b42d-08df29e43930 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: BN1PEPF00006001.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7090 X-purgate-ID: tlsNG-c1860d/1791976439-CF35D87B-E8468E7F/10/73395122804 X-purgate-type: spam X-purgate-size: 6190 On 12-Oct-26 09:34, Oleksii Kurochko wrote: > The device tree Xen builds for dom0/hwdom or for a dom0less domain is > only ever consumed by the guest, so a mistake in it surfaces as an > obscure failure inside the domain, far away from the code which > produced the tree. > > Add device_tree_dump(). The output follows dtc's format so that a dump > can be diffed against the source DTS or fed back to dtc; the value > formatting heuristics are ported from dtc's utilfdt_print_data() for > that reason. The walk itself goes through libfdt rather than decoding > the tag stream by hand as dtc's fdtdump does. > > Dumping a whole tree is only useful while debugging and costs both code > size and a lot of console output, so it is put under its own option, > CONFIG_DEVICE_TREE_DUMP. It is separate from CONFIG_DEVICE_TREE_DEBUG > because the generated tree is often all that is needed, without the rest > of the device tree debug messages. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v2: > - Dump the device tree generated for dom0/hwdom as well. > - Put the dump under its own CONFIG_DEVICE_TREE_DUMP instead of > CONFIG_DEVICE_TREE_DEBUG. > - Pass the domain to device_tree_dump() and print the "Device tree for" > header from it. > - Combine isprint() with isascii(), as Xen's isprint() also accepts > the characters 0xa0-0xff, unlike the one dtc uses. > - Update the commit message. > --- > --- > xen/Kconfig.debug | 10 ++ > xen/arch/arm/domain_build.c | 2 + > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/dom0less-build.c | 3 + > xen/common/device-tree/fdt-dump.c | 185 ++++++++++++++++++++++++ > xen/include/xen/bootfdt.h | 16 ++ > 6 files changed, 217 insertions(+) > create mode 100644 xen/common/device-tree/fdt-dump.c > > diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug > index d900d926c555..45cff9dbc467 100644 > --- a/xen/Kconfig.debug > +++ b/xen/Kconfig.debug > @@ -98,6 +98,16 @@ config DEVICE_TREE_DEBUG > logged in the Xen ring buffer. > If unsure, say N here. > > +config DEVICE_TREE_DUMP > + bool "Dump generated device trees" > + depends on DEVICE_TREE_PARSE > + help > + The device tree Xen generates for dom0/hwdom and for each dom0less > + domain is printed on the Xen console in a DTS-like format. > + The dump is logged at debug level, so on a non-debug build it is > + only shown with "loglvl=all". That's not correct. loglvl="debug" is enough. That said, I don't find it particularly necessary for the second part of the sentence to be part of the help message. If you want to keep it, fix the loglvl. > + If unsure, say N here. > + > config SCRUB_DEBUG > bool "Page scrubbing test" > default DEBUG > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 72d531618045..6a20af23e1bb 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -1705,6 +1705,8 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) > if ( ret < 0 ) > goto err; > > + device_tree_dump(d, kinfo->fdt); > + > return 0; > > err: > diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile > index 9036e455d66a..730d202349eb 100644 > --- a/xen/common/device-tree/Makefile > +++ b/xen/common/device-tree/Makefile > @@ -6,6 +6,7 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o > obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o > obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-bindings.init.o > obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o > +obj-$(CONFIG_DEVICE_TREE_DUMP) += fdt-dump.init.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o > obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o > obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index fcbeb8adbd73..24a9c6b1e3e1 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -1,5 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > +#include > #include > #include > #include > @@ -587,6 +588,8 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > if ( ret < 0 ) > goto err; > > + device_tree_dump(d, kinfo->fdt); > + > return 0; > > err: > diff --git a/xen/common/device-tree/fdt-dump.c b/xen/common/device-tree/fdt-dump.c > new file mode 100644 > index 000000000000..296ae0d90d12 > --- /dev/null > +++ b/xen/common/device-tree/fdt-dump.c > @@ -0,0 +1,185 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +/* > + * Dump a flattened device tree blob in a DTS-like format. > + * > + * is_printable_string() and print_value() are derived from > + * util_is_printable_string() and utilfdt_print_data() in the device tree > + * compiler (dtc). > + * > + * Copyright 2011 The Chromium Authors, All Rights Reserved. > + * Copyright 2008 Jon Loeliger, Freescale Semiconductor, Inc. > + * util_is_printable_string contributed by > + * Pantelis Antoniou > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Deeper nodes are still printed, but not indented any further. */ > +#define DUMP_MAX_INDENT_DEPTH 32 > + > +/* Indentation, in characters, of a node at depth @depth. */ > +static int __init indent_of(int depth) > +{ > + return 2 * min(depth, DUMP_MAX_INDENT_DEPTH); Can we use 4 spaces instead of 2 here and in print_properties() call. It does look more readable IMO and matches the indentation (1 tab = 4 spaces) of dtc when converting dtb to dts. Other than that: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:20:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:20:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448794.1664816 (Exim 4.92) (envelope-from ) id 1xGx1x-0006Cb-Oa; Wed, 14 Oct 2026 11:20:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448794.1664816; Wed, 14 Oct 2026 11:20: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 1xGx1x-0006CU-Ku; Wed, 14 Oct 2026 11:20:21 +0000 Received: by outflank-mailman (input) for mailman id 1448794; Wed, 14 Oct 2026 11:20:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGx1w-0006CO-Cf for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:20:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGx1v-004Ik5-Eb for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:20:19 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf656e-e002-0a2a0a5209dd-0a2a450aa8fe-20 for ; Wed, 14 Oct 2026 13:20:18 +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 6acf6571-f2d2-0a2a450a0019-94a397448c2c-3 for ; Wed, 14 Oct 2026 13:20:18 +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 69E8TiRw2946660; Wed, 14 Oct 2026 04:20:07 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021093.outbound.protection.outlook.com [52.101.52.93]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4h9nyc2u6a-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 04:20:07 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by SA2PR02MB7595.namprd02.prod.outlook.com (2603:10b6:806:146::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Wed, 14 Oct 2026 11:20:05 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 11:20: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=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=9G1oHx++AsRUyAnm9JfLfQ3ACBQlv8s0MfhoGIffC 3I=; b=zb/BUoh05e9ygC/7GzDqbl5kAgq8HeBcE8wCtMBrWfGHE35lMGGD3s1UR ZAWbUdtx5tfatyUC8FcDAoR/PtOpzHcmAWMRKwt6pWunSLSsJrN2rUCjIfsk3QiZ 6tMLwAJh1dn2ldLdl5B4XkKJ2U3ZMukCO32e0vRudey/jf9uQalXb4j2kvsF+uUw PnQ8ibY4o1gmtD6uhnI0ug7HhZYsH8G4LjKvxY4vJphfIMFvaWO/3wzhPNTzNSOt sC5FTfRxvC1HIcH25NVpPhEBO8/pDvyfeUyzQG8ctNKxCABFr/6WcVKjNEN4Ks9y VloKhERrvGqinv7hjMNvBMfzl3N4w== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tZjwySkG4ekKFxP0NB5Fe5kWNZhtApcSOWAfrdJhtHa200xR5khrZu3SV0pP8Bv2YkRb3cmVd42ttqkvMJgoQYWTfVoiX5gBLGj7j3etdljgSmqFtYHC4IxvqJ2iKgcbJhaxktb41IDzjCuoQhSScL8HxCn+XIAoxG3U4odageQIFTeZXSBRGr8D3ik0Lf3T/uP6RZ7lK39aBOYWmzSm176SLOlM6AY91mufbOFn4dA+ZjmyfgLrow5pq5Q9tdvx5uXuV4HaXeEoZvcT7KzCZu5enFJC77VHoVUY82+YeSaEKSy0lOr95ARLGTETKQVhRmdaUNQ/zqZBO/gGoGlFwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9G1oHx++AsRUyAnm9JfLfQ3ACBQlv8s0MfhoGIffC3I=; b=eaKGIOSR9acKQ5J7s8jZrPoz2T8VZafyMQx3r/MKJivUx3xQpUcACQpKCaVrRd8M5/OaO0s3o9C5u2gdfSSvoqWSyg3oa0LHGfUduOnYv7A+1N9Ss2Ym36kQFKYruNWjIxI8lhVMQjzM0qpGk/LafnAiGRt5hYstDMwqwagVk/i8sDFLrnjbkRIkZ7yi2IZ0NQ8pwbd6gOMP/8pS0DTBw8wOhquUcX45TkFMU2ZZ3RuYVae/3S4wO0yL2KZ4JZbVJXWU7JQ6DDtODqbyjlsYl0vRr0jS2VQAfH8Lzo3Oxs9Upumi/2b0oqgR6Fa9PxVglqswAIw46amUGoR+0de5xg== 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=9G1oHx++AsRUyAnm9JfLfQ3ACBQlv8s0MfhoGIffC3I=; b=qQox8pQOhlPDCFwQEvaZErWcycU+EW5b6FskV4ne3IpfqLabVNfDdbLmsXsXUAsWjTzcfOK95ECKddHP6YVcNQOe0/V0D2B/Tr2J1AaVHdoLIX0Ir3y+4gtoPsYaGDWoxg/l9WQoN5DbwlK8f4iZ79PX5NCVyxcMGDszekCD3og+IePswcQPoVxDoC0odaMSJY5dGuDouyffYQhfPDBqQMa/Fz6Z+4XTqVuEwhezA3NO4gbw5h7NbArJ1T1PCvpqUClvzmKuYzSWbv9QW1B7K8Hnp7/cv3QNTEcLQtDHZlaoznZbRInr+7gvblZG5+gK8R73tXDQr2p9liEpdU+pzw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <0148737f-834a-4e7a-8e7f-7fff2ffaa90b@nutanix.com> Date: Wed, 14 Oct 2026 12:20:00 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 14/22] i8259.c: properly cascade secondary i8259 from primary i8259 To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-15-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR05CA0097.namprd05.prod.outlook.com (2603:10b6:a03:334::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_|SA2PR02MB7595:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f45a804-5eb5-4351-4433-08df29e5190a x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|56012099006|4143699003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: 1zr7SWps9KcmcjfGaLxsS8ayPjihytxRXsR2MJ8tvK6flcepdTAoM4fAX1N/i+PvbSyEwuSE4X0SxncEIXOO8zNQsZ4MSWCOK+Jjib2Tx2GVLFBj7Vg9dx676FLlk1NRpPUZeHsURO+2OmL6bv7dCP86NVU0MRXOEsTOeFdg0C0Qhpo+eICq1YfZT75CsO1Zguac7hH8s+GnzzMPaRhROErUS9mfoFDgJe//kO5CwmLI9rdU5+zsKPpteJOZtWUBwHtG0AFwZY6ZmO8W7EJLEI/wHT1FgCwAMK8o5tC+K0cuHQCW5krRsNfjrCA+wDEFKsLh6cxDFbbnI+FpHtajIWkSFdsrjLikeX7OOXvMSRAhJrdJAIOodBMoMXEiZH7sW7YCu/Gh00Hv+tVbVJr7YCI8fVv/lC+kRz9NseDsax1ZIEq0puz5YTuXJOpH0xWG7VlJeYlmyxFWyUDqiD8MwKcZOHsFgG0qQC2yr5bHQsz4ruCU7nllCY2eXgDvJRXNqZV1q2sqLno3lmesLHVwGk6p5CtQcfrtOtE/aAhXp3A5AjG+Hhf/esKltHBjmh8ehDxY/UHKwU3PKjy9sLxJcRfwwm42WpdUteAqu3uOftMEIDWZVB7jWy4DetoQxGlb 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)(376014)(366016)(1800799024)(23010399003)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TE42U0RIdGorQytaNktDOVp6VVhyNXAvdG12NFVxUFVwUzJBTjdLU1dhRDJZ?= =?utf-8?B?Vnp5eUFvZnQ2MjlBckI1aDlnNnJkNVlKYXNBK3l1Rmh1RlFLMXFsWngzcHhM?= =?utf-8?B?YWtBRnR5enhuTlRlb1cvQlZuc1BFdmZhTng2YkFvZjJQbWpOQWVJdkhZS3Bh?= =?utf-8?B?Vy9MYjFxSUxvOHRlSWVHN3hCQlI0d3lLK0xwNnprelE4YXVKTE9tQm1ON3o3?= =?utf-8?B?WGtScFUwOTljY0NQdTZ5TTcwcE5ZeldXbWNVcWY2QUtUMHVtMU5uWW9YNjM4?= =?utf-8?B?bjRCdG5DR3BkWE56RnRxTXg3RS81UWg0R0pMeUxyOFpiQnA2TndXQ3ExNW1P?= =?utf-8?B?K3Bvc3RkcmJZVHhYODBWR3JjWWI3NmlGR0ZzU2JqZTluNEkxbGFmOEpuVGQw?= =?utf-8?B?L2x0WjA3eTdwYUp2VWZYTkNzTi9hN1hCWjN3STk3Z2tKd3JTYVVSU0JQQXJw?= =?utf-8?B?alY5Wk5UWk4wbzlLMjRrc1JRSlhHS2EzalREajZYWGVyZk9SUHFaVGRHV2JG?= =?utf-8?B?L0JqeStncjUyNFlyMTJ5QXN5S29zUlA1ZlZydjVsWHRTS1BFa2Z6YkhjeHlr?= =?utf-8?B?ZXBRNkI1MlpuMDg2VnZzdk5sWFJQSjduN21VZnUwZXd4dytsMHB1WXo0VFRv?= =?utf-8?B?bEVKeEp1TjVvTkRoeWdnMklVaUZpcll0cnYzRTE1MVBxVkcxWDU2dkkwUHdr?= =?utf-8?B?UllMcG1mam1rRHJpbmRzOFZKYURaWkxPeDZpYWhaWk9KQUZzTEl2RjVFcE1q?= =?utf-8?B?K1psUEpZR0plcW41ajJxUzU3LzR3MFdxSmZuTDVWSWd1eW4ybVRmcCtXR3oy?= =?utf-8?B?cVFVSWFnY3BwQWNndWVRZTduWXliQmJsK3drblZxV3NMc2w3N1hURmRWNGpS?= =?utf-8?B?UVV4QkJ2OGNYM015OFNQaTRQZ0hxNk1TR2pBZk5zOTBiUFg2RDR5Ti83bWVO?= =?utf-8?B?S01XQysxbGt5RGxaYzhOdHNPd0FsVWU0SHp4OVRCV2RtWG5jSlJmeVhYbTk4?= =?utf-8?B?UGxBNE04UlhjQ2VGUGpscUYrMERPcVlhYk9zZnVBcUw1SkZHQjFESGZHb0dG?= =?utf-8?B?WkN6dnU5VGdEWnpyNlVxZkdkajBrL0F0UWhUMVZBWWVhN2FCb0lUWlY4R2Vh?= =?utf-8?B?bDZBRnFONHQwK0xZS0ltV041YjdvQitjdncybmxHUFhxcVBqd1hrbnZDOFdm?= =?utf-8?B?L3hUbGVsdkVVUlFoYnRWdGpmVitVVFZDbSs3QXYyMUpxNU9lMEJ5ekhEMEV0?= =?utf-8?B?K2k0d1BKVEZYMFdlUXVYVWU1eHVnYVhXVDhLT2ZFeHdpdWllVWltWkM3bkhQ?= =?utf-8?B?WEdkcnhhUVhhUjV1NXdRTEdYSUNpdDNIVEZuZ3R2NW1NNjUzYjdsUEd0dmNK?= =?utf-8?B?b295bEt3NGttbHlOQkdYWmVkeXdpUjAwZFJ5Qzc0dCticERtcmNUWVcrRTRD?= =?utf-8?B?V0tCcitRaFd2b0JTcFo0bUR1Ly9pVk5UK0JCZWNLbk45bVNwUzdYNzNnbjFl?= =?utf-8?B?REp5S21mOFdSNjRSVS9HVVVUR01VRiswQkhjeTI1cGlKMm1wZ0VYRjNjL3hL?= =?utf-8?B?aTJPWlhZN2FEbnkwSFFJcXhxSnBXTGd3eGEvaHBEaGVJeW1mamVVc0cvZXda?= =?utf-8?B?Mk96UW9xT2NvT3RmTDVHV2hXZWQ4M1dKVEs2czJkS3lIS3VEdWk4RktjVEt6?= =?utf-8?B?SWZyREthb0lqM0lyeFJveHRQdUJaZG1kRUduNDFhTHlWZElRL1I2NEdkRXdM?= =?utf-8?B?Qjd4a0dNaGx2RHZOempIYTA3VzBrT0pvMmxybmswTVI4TnVpWkdjd3FQbHJw?= =?utf-8?B?TUJZRk9QVktkYWdZR1RTQlBtNWRVQ0wxNW9BNDMvNnpXL0daT1NQTFRVMFhQ?= =?utf-8?B?eE5MVUwxYytKZWJvSzc0KzEvZmNhN0NOcFFFWUMzUzFpTUh0UGNZNmVWT2Y1?= =?utf-8?B?bFNldUxkUnZRZmg2cjkyMXZzenBKNGRWeUFKbzNXa080Rjhrb1RIdGY5Y0lq?= =?utf-8?B?NmRqaElEWUIwNnhja1Zna1kydStHUWNTNTBIWHdKMGR4ZGlMcFpid3FDV2xn?= =?utf-8?B?d250UVc5MHpCUUJ0ZU5YYlQvU0ppalpkK1Q1M2NHL1dwTlA0ZlZDd1ZOZGZa?= =?utf-8?B?L0U5eFdLRXZmTm9CejY5TmQvSE5KVGNMK3ZqbW93WHRybVhYeVMzTDZ5SXFl?= =?utf-8?B?blhyeTZuSjM4MUIzdWxOV1E0bVFmQ1E2alJhOXoraXZTT0lEMjRHK0NZektr?= =?utf-8?B?d09DVno4UjRWalNmWVhpQkVmVHNicWlwdUJQNGNIclJoRGYzRWg3M3Q3T3pt?= =?utf-8?B?SnVubEhhODVRMHZ2YjNrcUxySzdjL0FhV0tqNUVQM3hISW9WNW9ZVmxlUXJS?= =?utf-8?Q?Mp+6quXXDrOIjNE8=3D?= X-Exchange-RoutingPolicyChecked: twpkzLsb8MeZ+0gi84GmlT5z94lG9wku9yR9b4B55b4MxPGRFMkG/XBm16oOQ/28TmtOgE5fVaOlkLc1BWavIfHHnekklGgGYi3fipwZfSXktxMNUvY5Tv5o6FDShh2Trr1MIvwpmi4Mhk02p5aLxtiXmCdxGftnOzmbJtJKJRuREhKanvfr+j6038K6GOPBaNWWv50IfeB8PSMn83W1nI12IrvKbtauPfs1+YCVtUExPoPJasn8ALvgVHptq/kUh6Vw9/3pZQ0o54Hhjjv0iE/VT4utcWCTe7BMFj/Fnmhpk25/aNPK1Lw6scQxy6DoBM8TePk9x2YhzKDpaXFcBA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f45a804-5eb5-4351-4433-08df29e5190a X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 11:20:05.5080 (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: Vh3CFQeXIOHHupXpgV3g4KhEVchaDUuGDdksrI1k0jndx4VR1DQNpVFOvrGTvyMyH2efEmc/O2wloi6PFtDruesFk+EUYSTPbK9WVkgwA8Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR02MB7595 X-Proofpoint-ORIG-GUID: ewlGalHfs7RKopyvwJPNgPQ5G3j585PM X-Proofpoint-GUID: ewlGalHfs7RKopyvwJPNgPQ5G3j585PM X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA0NSBTYWx0ZWRfX0G37NHKgZiow De1K1D8e7+N2HJGC9Ql/DCLWhubFLXS9ETEduv8x2fM39wiOQzSwH10S1DK9mPgPz/QvlW1RgH+ zBkoyoxQOO94IwilxNW8XMg1UlPi9KqNaK/+3LtTphwnn1UOYYjcOFdutZeLzvZ5q/OhxMgGFfC 5stONwVn1FE6L017WZDqZw4XhKL7sDmHSjqaplv2uKnJHxlaYuLVqQPKeIDHfgVOe27oFhpC0kx o1lfldh30Y3rHvsUa4nzyc7KlsibrptiIuQYJJxHWPD7nekxSjd82EBM++vfVOyCluAKx53+k/M 5iED0yy5Gg6bFtu8j1eOaQrtrGrQBLIqbGV8CuaDcFIfmN5XuQffwKX3TNrzu0SFoduvx9ZtjYl LLs/ScyFyamRuytY796wjHSx4vIUwRvucGXVxyrrH5bN/Nletiwba4ybs1jNaHSvaEF3I+YirQu 5uJQpMymm/DKjm+nEkw== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA0NSBTYWx0ZWRfX23W66UiiWhn0 LrFXSxPnTV2lf1kNWocZflV22RooMkCQakm1AW2uuhwolK4C8tYJHl9bdKyRALO3mRrCcRIkw6Y vEFqy/pv+F6lO2zrL3zAAcJT9Ia97Kw= X-Authority-Analysis: v=2.4 cv=Uq/2pOwB c=1 sm=1 tr=0 ts=6acf6567 cx=c_pps a=0scnO40TN6uu9waSdQKTQg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=H7MLjYanAAAA:8 a=64Cc0HZtAAAA:8 a=_J14Gd7pdz6F-6QAQxIA:9 a=QEXdDO2ut3YA:10 a=bgSlMGY6Cwri7Y-TTqhu: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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-4011c0/1791976818-510C9CFC-BC8DBDED/0/0 X-purgate-type: clean X-purgate-size: 1650 On 13/10/2026 17:18, Peter Maydell wrote: > On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland > wrote: >> >> 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)); > > We just added this line in the previous patch, so we might as well > squash this change into the previous one I think. The reason for having this in a separate commit is because it is technically a behaviour change. Before this commit, an interrupt from the secondary PIC would *always* raise the passed interrupt, whereas on real hardware it is possible to disable interrupts from the secondary PIC by masking the relevant input on the primary PIC [1]. Since real hardware works this way then I would argue that this is fixing an existing bug, but I thought it was worth having as a separate commit just to be sure. ATB, Mark. [1] https://wiki.osdev.org/8259_PIC#Masking From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:22:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:22:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448801.1664824 (Exim 4.92) (envelope-from ) id 1xGx43-0006lf-32; Wed, 14 Oct 2026 11:22:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448801.1664824; Wed, 14 Oct 2026 11: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 1xGx42-0006lY-Vh; Wed, 14 Oct 2026 11:22:30 +0000 Received: by outflank-mailman (input) for mailman id 1448801; Wed, 14 Oct 2026 11:22:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGx41-0006lN-M1 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:22:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGx40-00D1iE-Us for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:22:28 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf65e9-e002-0a2a0a5209dd-0a2a4508a9d2-26 for ; Wed, 14 Oct 2026 13:22:28 +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 6acf65f3-f659-0a2a45080019-94a39b0c495e-3 for ; Wed, 14 Oct 2026 13:22:28 +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 69EAYIrZ3386605; Wed, 14 Oct 2026 04:22:24 -0700 Received: from mw6pr02cu001.outbound.protection.outlook.com (mail-westus2azon11022128.outbound.protection.outlook.com [52.101.48.128]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4ha83mr3g5-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 04:22:23 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by SA2PR02MB7595.namprd02.prod.outlook.com (2603:10b6:806:146::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Wed, 14 Oct 2026 11:22:19 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 11:22: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=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=UntIQfcG69Yt7u5iVkMIcsZ3ycgkHq/G3KI1rc32G QY=; b=BqGloufSmgUFn7ahaGnx6UG4FjmEvnalPeUmGnNUetdK9Wu48p0zwW0l9 cvRGaBNNngcZyZOiPZvK3kr4JpT2+pz3X8IQlTTlc5jyLL7CQW0G6twsOCcRSZ5c KCT/83/oEv17K/IJ8jbEofkLCkzIXpQnY9breO0F7Tt2C6voVWAAmDN7dk6AkGSB 2YmGSwGhv52S32zKB9thTaGbnHcKAmkQGCovvINALt4zqRnWeoNhIKfeIjJtM8TU ZknOFhbC7/b1Iye4jELdnJBDTjAyYY86VUWBTTrF+IOLHkth8Owo/0hyMH0cFkdv SuZHhQ7ua7QcAhmDM7YfMdMEYWdiQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZVsweAuqoYydf6q2FqQCJ37fkFvnTaxBtijuERGV2KJRPmcn/+ll+36+1EwDL9a6Giny5zYPqsYDp9eWHQNu3LYl7WRZX5ddIi6bJ2a09x//PZAVmu13Y7FUett1c3EmxsfUzhMrKMSam79xh6g6BocJJNpSkcLxP+blzF6OSZZuSarNP7vjJbg87u+blLng4/8R9SI5444Qp3shFdKIEBmpmbI1xlgR9sq2eCKJKrsHG8ylLqPTdNjRCiD/itV7diMjdWBL9x2zPLrLjiPcF+MMQQlxgILSd5J5lFQNpdllUVb5h7FUWLIXVCo++KzTafZ8vYT6E1suEbz5dOP0sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UntIQfcG69Yt7u5iVkMIcsZ3ycgkHq/G3KI1rc32GQY=; b=GRVMEeKRrQWlIPSjnCUiIkg+SsWm6UGNsyEXuZdDU9SMUojj75R+J/eaA39IPKJ9bnNnkpb3fjveArKPabfRq4132W//q932OeAw+7Ms8WmrWmKa2qmMLgDcgbHh2d36yPR9Rs+OoXSQrKPY9YTfLFnELw/cNiIS745IFh/NJJtqcgDbC+dBU1bvfw6Szt3L1ZPQTZS8XNdj6S2llWDtzkpDXTPkswD4ztlrT5N61bG82GWfaqxwxSHG3diGMAfY7W41ZYJuDCZBden406a+OMWXTvvNIyARpnPU5j3uYhQLep7ICQcu6eI0ZvHrew+3TvEVG9KmQPI9ozLjlBVnrQ== 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=UntIQfcG69Yt7u5iVkMIcsZ3ycgkHq/G3KI1rc32GQY=; b=mrWyZHsZPZylhcODNQ87NxeZDVtBFtgFp/6EImj7x7aGuom6aybNsxGV47ngGYyV4KsZrh3ioGbxLB/3maFJ/o+DdUi0MqN0DRXCvUB8jo0PO6mPbuM101Oj7yovh5cN6C2QU8hIzY61Y6pH73/Z2uVKcBsltc+TvOM0ylYdHVZutkAvH0rgmrXcNJTCzzc5IprdrdmO1DHA3fuNonXvfrJ9ge/2UUtGJ/7XZb9bWd2lxfUzDiRJPBAPI7FJddxwWDJ6IwOd39MfI16JI09maK1RBPj9mnYeOEvhwxIQHgY6PfTFQLA1cX2rYZgdEzaNKNwYkR3rYUTghj3OQiIrKQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: Date: Wed, 14 Oct 2026 12:22:15 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 20/22] i8259.c: switch isa_pic from I8259CommonState to I8259PICState To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-21-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR05CA0119.namprd05.prod.outlook.com (2603:10b6:a03:334::34) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|SA2PR02MB7595:EE_ X-MS-Office365-Filtering-Correlation-Id: ff002fc7-40fc-4c1e-9d0d-08df29e56900 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|56012099006|4143699003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: /mdbVpV0JpoXmAb2RFY3hrzuqX3Xlg/B4ChwbuX75S+i6DerfGil0XUmPDXgODVtAAqj6C8hO/PFDcLrUDheT3UIDJhX/plEVe/J0uRTsQH8Vl+jzBjslqSHJPW4FNj1bg0uFBUTeFDAr8gQgA3PZWT0XEf1i4+CqSqa00Sn3p+rNU4qtO3UKsouVE9qWEuUe0+V/WZ+XDbBNBDXtB1kY89g1r+QXMI/uxwdYh1R7eZwYKbz9Rp6ddq01HRLtkThvoE2yKkdK6XTEIKWbmUsATmwlTgkUzKEgn3kjokCjktxXdK1RDplXKCGPKjEFE7VF5O+/xy8zj7er2wWY+i3jZFob+lwpl+Dd6Fq+pk1dproppyl9oKI612Qdwsm8vn6QA+gL4vHo+bBouOFy7rGxT6pucaUY27HetXGrbp/mjNWqcdg21aJuIxAWSSY3klPZPNU/KIuDjoT55fTlbawBad/YCUsqhZQjkQ7ryRrBU2ofUaugmfPbgAivPtazdMaO0vYivsIa8qd9Paq9q93Tlr4EdY6Hu/Ph6mqkjRJQ8q0IRsiZ9HH65L8CJtKfC/ZxQYLLOE7/zPMMGtmIhr5XPzbnAZ+2WKWGVa1MOvIjmBSW/vM+BlGJTFx4tQtC8snfrN/n6IRqir7gXPW6p+99lZwFRKUTKYpiWsvXn2YXgM= 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)(376014)(366016)(1800799024)(23010399003)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V0lzY3FCOTltVmhQeHdHYTRsOGhvdy8xQ01MUWcyNWpJZDhvck1DOWhqYmZC?= =?utf-8?B?YjdJdmpVQ1NSYURHK29wb213TDhwbkYvcFpiTlhzbWRNaXRIamgxU0JjRm1V?= =?utf-8?B?UWJqaUJIWDVKeElZaHZkbVlhMko2cVJrN3RIc3RRNnNRYWNsSzE4Yk0vS2sx?= =?utf-8?B?c3dPZkxuOUV0enJsLys0YzZmSWJlNmVBczc1eXUzQmVvN3FxSTZtamZTdzNa?= =?utf-8?B?dzk2cllINVRVUkQvams2SHNjSGdyMk5MZ0FlMEZUMUIyR0dUUkVJcEFOOHlm?= =?utf-8?B?UDl4L21XQmhjOTBUN010QzZvOEFaNm9jdno1R3BXYW41UmZ5ODNSNDJ5R1dn?= =?utf-8?B?Tm1PZFBiWVhveEMxU04wTzJBaHZXODZEdjNVTTRhNCsxQ3dkamdCN1AwV2pn?= =?utf-8?B?Z3ZRcHVmSWM5MUpzTkhJOEhodC9wdEtFMUl1ekxCaFlNdHJVR0U1cTBsczJl?= =?utf-8?B?QjcvNkZYbWhmV2hxV0E3RlRVNmJBWXlYVktvellnNHpxRmJ0Um4rRVoxSWtF?= =?utf-8?B?WWZMUWlobzZmb0ZPcTJBdmlIUEpZVlo0dmZIQXdEZ1Q5a1BmU2hhMHk1NEJ6?= =?utf-8?B?NHhHWGdDd2E3RG5OSFFFbTN1TzlTV2JzTGFrcnVOTXE2Z3lkZEJFWnlQT1NO?= =?utf-8?B?Vk1XbFg4T2xhayswdVFTbzNxalV2cTN2d2xFWlI5dVBNZUZwUVhUZktNRDZm?= =?utf-8?B?VTRua0M0allSTzFwOHYvUy9qS3hQNWZtcjJnb0NSWk1SUk9TTjhLNEU1WTF1?= =?utf-8?B?QXdHTysrdDJWWnBoNHVZeFJhN0JMWk4rdVErVjFIV2JRc2hFZ05TRm9FRGNK?= =?utf-8?B?djBzdlFGejliVWVPRjZQbWEyajc5NEw3VHBTd3NodWdmdy92NVJ2dUd3MFI0?= =?utf-8?B?MlQ1UlQxZVZoRVZqK0Jrc3B2bDVXeU1SbkhXM25TeE1VMC94UlF5Z1B4K1BB?= =?utf-8?B?b2ZLMmYxNVoycm1MejVkaTZWdVJzK0JjdFFhaHJGZWJMeUdZVy9Pd1V3c3ZW?= =?utf-8?B?ai81T0FGU2tySUtQSkk0QkFGc1R2b295NVlLeEVQV1BXNTdOWCtvTVl4WjVm?= =?utf-8?B?L2ZldldxM01SUHEvcUFLN0VZQlc2VWZBbHh5U0Z4SUwyMkZndWNGVWNMQzNp?= =?utf-8?B?b3lmZkpVQ0FmcjV2WjBtNVJRNGN2SXFMeVVBMkFUNEVIQi9nU1dyNnR3Tzd0?= =?utf-8?B?NDNxVXhQNnpleDh3NmJqN253S3o4cVJ5RWhKa0swR3crZ2gzcThKZ0xON2ZU?= =?utf-8?B?eDViUEViRW5pQ3ZpN29pRnNWNUcrRlhBTTh2ZjlJYzdqc2RzMnJBMjZIcTRt?= =?utf-8?B?T0wyWDhWc3M0MmM2TE1mRGlCV0hKazZvUjZxTnhrWGFZdjQ3Q2duNm4vT0dv?= =?utf-8?B?QVRMcDhkUXFMMndhVkJ4SkxiNU02SU1kMkV4N1p0N2svNWt4bUprUGVsblhu?= =?utf-8?B?V2V4UVFFdUlxTmhYNzQ1SjdDanNWRHpVaDlOb25zLzNzc3YwRm16MUR3aUNF?= =?utf-8?B?bE5PN2tYc3B5RGZSYkxneXpMTi9IQ0M5RURYNUV1V0puNzFxbEdGdFZWc3Nu?= =?utf-8?B?eTVXVy9SeGMvZmNNeEkyWncrMU5jV3dlb0xhdldLNjU4TGVGdC9Db3JxQ294?= =?utf-8?B?SUcrSGFMU1VUTyt1SDViSEkybEd0N01LRFBaOHBCc1VBNHF2WEZWSVBDR0Qy?= =?utf-8?B?c0tNZGh5d3NyM3pUa3I4S3Z4SDdpS2J4K09iOEs0T0lpZERXSGd4dzF5eC9T?= =?utf-8?B?T3BkLzRiZ0JFYVl1a1J3TFpTY2kyL1FBeXFaRC9QcmVpL1pBejZTdWNIRDlj?= =?utf-8?B?b2diem5uS3E5bGdRYmI1MkVzTThVdHUvUnlaUzlCTWM4RFBoWWpZN0orUFVj?= =?utf-8?B?c3k1allGQ1FZcnhISG1najhJZkFDbDRSWjBPRnBDVWxwQlFnNkRHYW52cUM5?= =?utf-8?B?RW43WEtFTXpYbE9zVE5Ib1gxTVJvUUlFYlJBNGtXdUV4SU5ld3pNK2NlcU95?= =?utf-8?B?YXM4Nm9Nbmp2a2tFeWo0WUpCdTFtcjdtVU1MTWxDMGZWc09pQU5GcnIrZGhk?= =?utf-8?B?TllCREpKUVdMRU1OV0hvR3RSSGlseW4xcS9LT2t6Y25UZFlaZlRldVMycGhC?= =?utf-8?B?YUdyTVdtWWdKOWxpTFBBeS91RGRFSUZSM282M0ljeUdGM1FqM0RHUnRnTlRC?= =?utf-8?B?YzROeEdabGFzQ2dvaFgxZEYzelRDSnVyeGNsNXljMXZhZzdkZ1RuY2V3ekgy?= =?utf-8?B?RGFRZm5mb0U0TWI3andJaFhUWlBOaXZuSSs2TXgyWlJ3Y3VNNzVMeDN1WVlT?= =?utf-8?B?Zmt2dEFjOHRCQlFIdXRRMDQzakFWOUkzNXdEbituYy85TUhSaG1aYmxyUW40?= =?utf-8?Q?79A7NTN83y4P4YAc=3D?= X-Exchange-RoutingPolicyChecked: 0T3v1sRxGngYg4lVFn+5vuZsnsdNsnAgE6aWHkIU+/wHe0rRzTdW2Zw3Nybu0fMdAb43uwzNPx/ziwlhNJZL1UrJyt+Gj44aYEdVgVkLETn9rE4eVruvucUqwWu7nZltfAyKyZSA4kIX96cTTB13yP6lt16pNLVNtqCCncTkOhadXLzWWqppOj5hPqfsHv/CfbL7b46sfl/g+HUQpVi+NJHPeGkC3zWoBWmoF4pDRfDOcFUgFNBVN7unnwYamIolP9ShkkS3bZcQdijI6V7DuO1nq1AJj3EUOj4xL6fTPMZJuff0PV4ZBLyOXl8XKtHtjrDDWfRlFEnZ99l5xTZ85w== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff002fc7-40fc-4c1e-9d0d-08df29e56900 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 11:22:19.7537 (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: EF26cXjKQS+gqaD7NPZWrDn4LEkovLoWq363xUxAeV4m63y+esgsaXvsRh7KHPz83Yw0ft3YU+LbqXZsH6BToMZLXJ5hJciA38aXal+cCrQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR02MB7595 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA0NSBTYWx0ZWRfX7AGoJLee5MsM xn/ff4R9P9vYQjyeEi/jcDWSM9s042NkrF53Roya7boAbxuwrGWdxAcF6FS8iW6QrLFCh/0/7wn w6Z2arOeiKF+WTvnA/DfsJx/za/OhvI= X-Authority-Analysis: v=2.4 cv=BroIUoX5 c=1 sm=1 tr=0 ts=6acf65ef cx=c_pps a=YH7lkWZYaMs4szCCOGs1MA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=u4KNI37tBQhSRKA6Y0EA:9 a=QEXdDO2ut3YA:10 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA0NSBTYWx0ZWRfXxD6Kbnxx7nX5 xbvHX91OV1qUTzw532RnIEHGENN9Fi5HpEhx8kAZSkJcBscExK6sgIwGUyC1Sb83Lti0dnBYGuP fQ6M2aNcmtKiTIT8q4AcvtljReuo7ZbR8V4wo9Cmy152T+cmhX/3WNtmPVN9w+3lXuFgNhZhuYd GkiqCCsOKhmTGnWm+iZItfyI9yoRGhv1spBAIxHiEIJTatGozYhqFHPNcjTeCf9IbD3u3zCtLNY z2R7KUOr3U3TCDVs8NWStV+b9N+igA0tjyD4nagM/AudfC9pUk2SbRxTwdivtocXAN/zIC2G+aQ oYLppq1FzuGeTq+cWfQCj0sf5/XWCH6ZjQXeaM9FbekMD1ZQKx55u+ehv1Ip9iwFQ+qKbKywmWk BdN96f6DZpD/nMrmwzCDP1TenH6HAt4gei/9H6YW8GV7w4mSfP/daWnCL7idgICGkBq8+IehDgy Zh/q1W0HrFYCxNN242A== X-Proofpoint-ORIG-GUID: T9GUL-4qYX6fW2DGlM3He4xezAoJSspX X-Proofpoint-GUID: T9GUL-4qYX6fW2DGlM3He4xezAoJSspX 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1791976948-CE74387B-8D53989C/0/0 X-purgate-type: clean X-purgate-size: 1193 On 13/10/2026 17:26, Peter Maydell wrote: > On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland > wrote: >> >> 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 >> --- > > Reviewed-by: Peter Maydell > > (That isa_pic global is kind of ugly; in an ideal world the callers > would have a pointer to the PIC they cared about rather than relying > on there being exactly one in the system...) That was actually one of the ultimate aims of this series, however I submitted the 8259 changes separately to avoid sending a much larger series :) ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:24:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:24:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448812.1664833 (Exim 4.92) (envelope-from ) id 1xGx65-0007MK-EO; Wed, 14 Oct 2026 11:24:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448812.1664833; Wed, 14 Oct 2026 11: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 1xGx65-0007MC-Ap; Wed, 14 Oct 2026 11:24:37 +0000 Received: by outflank-mailman (input) for mailman id 1448812; Wed, 14 Oct 2026 11:24:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGx62-0007M6-W1 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:24:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGx62-0017M6-CZ for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:24:34 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6667-2eae-0a2a0a5409dd-0a2a45078e38-26 for ; Wed, 14 Oct 2026 13:24:34 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf6670-b4ea-0a2a45070019-94a39b0c04e4-3 for ; Wed, 14 Oct 2026 13:24:33 +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 69E7wOr93014631; Wed, 14 Oct 2026 04:24:29 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020143.outbound.protection.outlook.com [52.101.46.143]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4h9pvvtrww-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 04:24:29 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by SA2PR02MB7595.namprd02.prod.outlook.com (2603:10b6:806:146::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Wed, 14 Oct 2026 11:24: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%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 11:24: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="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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=5Y42nFX1SuoOHfoLk9XCJ3MgIlx+bFXAwAy9V4CsU ow=; b=lqhwuCkK6/Vzv9Y57U+pnEB09yphxefHBQGnBnG2UYU5ZO/Z2BPAspADP EU1jeE8c+feeuYFPU8Tf+FZ52B7FTgWUyO8wGwxYsQGVq0NfRj0ypPZ6j3zkQJev opcQz7rr28B5b+vzkiZ4oop2vD0yyu9DSHh3mL0E8F2GzsJe4porCIksdf69lZrf ABYTpZ1800J7RCnCMvT9p0QYL4zz7+mGQjaSLsVLve2HnrQkIRPpIot30DqdcbiT chp3eU1ZTb9n4gaPUZrJRRm2SZ9FJ1r8Ja7mBh1FYLZjtYh39dNCyOdVGnDFhfIi yJc/YIxq+iwH5IE3WhX22mUcrax3w== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UCnQJtU4oJx/P6P5towLLsFKmKBSCv0qErSwC+FmP54QmB+m6L37KUJJ1zEwipnRrhDh5epxPPJ1dxQM7bs/Knw5mwJqmPpQjC2xhctd2ZHjqgQrCrCpWezMK/K0mrpAdAzUDbOLIorrrq7Vf/GwfGG2N0zWvRHC91c4auaEHYHaIxzPOSNj11h5yGhG21+hpRnU8ccPulHt4MdCG/ZK/ey6mMs7bx/oINEQBX0gOnkPQgQTuqCtXtAofn5KefG8/CXXusU3XDHicS6qaT6R8wfOMdjGSXhzgYnyVrU+7vuRcOho2/F0YdOjt7WmD85w2P6t0xK/rPO5vz+kVAdCKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5Y42nFX1SuoOHfoLk9XCJ3MgIlx+bFXAwAy9V4CsUow=; b=qLRB5O2r9K7k/bn/4rk5JUozlVHaBZ7BwY29Nx0Tl8zQqdogjE0mG4kxJ33SS49o6290H9A6ergXv/4WWyBRaDlTE/LuziB+j0e56WYfw4nCUCNf6hWwa0PHIplrFqIGPtVymOh5/qvFguYmGQwaF5Uuqkth6MRGwMwo8XwmoFuX8jULMZIGD6Gdmfdt6lhmcTwD6CYr0f4uydjxfq+ZOueZQHzNi6OSKi1qljBZ7+XObHj1JQcX0u0+AMd/g8uDA1dx3AHvWJbbL5GVTrPmqG4eNTJDq1mmp9ltXe9ScCP8+FwqRya69JFzZSyI7aVCU3p15+gNwNDJXqRiuNRp5Q== 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=5Y42nFX1SuoOHfoLk9XCJ3MgIlx+bFXAwAy9V4CsUow=; b=XBN1le++cY/jyeNoToMQM5GYc9jMUTg0tOqrEQMCjDTH4e0Ir120VWqYq3LA97DaunKlT+Sqhg6GDKupujSclEmwp2TBGeT+zsYh6SCnZ71Nz1YwFe9DMpkEZqlhTEfAdCdT0G/XaWNvZr7FBbSSuZkZoetFIYiLLGJV8FKtMdILnFxxD1/Er/Fj13UAmkWADphrgG+TPNf0rAvRSjsgJjivFl645a2+lIaAdnmu4JNGU2aMD2LvDPcNYZPzPVIL0GlnwwN6mGCSAqfZ84y/BMGlkzcSJkebbMHQmVvL54Zbe0du6SWFVw4ihgPjfdJMDVyd0Vjs39K3ZQmkVKS9Sw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: Date: Wed, 14 Oct 2026 12:24:21 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 21/22] i8259_common.c: remove static irq_count and irq_level variables To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-22-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR05CA0113.namprd05.prod.outlook.com (2603:10b6:a03:334::28) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|SA2PR02MB7595:EE_ X-MS-Office365-Filtering-Correlation-Id: 0fd87a39-f822-43d3-166b-08df29e5b4f8 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|56012099006|4143699003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: uaHJyyUXSUfZlFH7aNbf2LjuExN6gAtXrsj2CP9xkNUlwtCyPKkTxUftkj9d4rc5Y4qQXK4pFqawet/ibsN+kEOMJARw2OFThjHeq3Wkhxmn3KEhkV9t2iIFHQpNhXdAKGAQoDh5dPSM8ev9bHOWoHeDdXzShatU3KF9LaYPH8MwpWaDVYf7E/eUFbjYZ8/8Z9BX+oCp3JiuqYEP+7SMZeo3udo61UbyzjAatrObMLELFT4ickHeJyO8z+Rt9WC7gFezJjTZyuxAmv1ViKf08bfMBDU7JIW6yrCBo2xTJ8PMobnQwkqU5qxTk5rYyCqiK2u2kZdZA96lvc2SRDlzwT39cE5PbK4K8Vx66eadVHbehtq+kdnEgawFHCydoRuzovLQ7RRmh9Is79b3hTfHO2FpBXPx6+f25rJNG7XcdehiwZJp6PyFnU2hjhGGH3oO+Iii/AZufx75TlSbZzYzHcAGc/iyY1yuEFyUGt+5V7vbM3qrF/qO8B7A8bFjejWa5jcyXQCFFJSsrWmcoTj6/Q+Fw3D9tX31Dnqo2p69BSE5ni4+DVERw3QUxXGQJWkMDAXR6z08UtadctS9jN/4lenO6w5bU6KCGOj7ERAkQp9ovvmtmnjj+f+niJdtBrJt/ix2BFAy3JqHyeslweUjeR8EXxT1KMahcw/n8aXKNMg= 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)(376014)(366016)(1800799024)(23010399003)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VDNQZmxYTDlic0JKL1NFVE5WWW1NbERNQXk0MGlRMnpRN1ppcE1pMzgydVBi?= =?utf-8?B?cVBXcWxNY2RrcDhTUlM0bkVvMVhWdTJ5WXhkVFNGaklDcnRJeGo5VHh6bER0?= =?utf-8?B?U2czN0NyWmMvMmtWTmUrU0NpNFJxUThEM0N4bi8zT1hGVFJ0aGRmR3Nia3E4?= =?utf-8?B?bThtcFl1TzJlcWV5eGx5UU1UUlpyaFhncXBZTnBjSDV0bWNWUTZ1dEN5OXI0?= =?utf-8?B?N1dQejBQRDNyZklnSjNidzBDZTBYKzZYY3g4L1lSdEk2MDdHa0FyR0JEdnB0?= =?utf-8?B?MHVwb3BoMllqYVRKc2NQRjFmeFJWMCszeXRKTnpTbThaZ2VIbEtmMTUvMy8r?= =?utf-8?B?M3dQU3daNzVWaU1ZQ3pEeVAxd0NYVjFlamxxR3VCNjBQVGlpMmkzdEsrRUJJ?= =?utf-8?B?VThCRUhIcEJORVdJMldaMWZuQlNXTEs2VFAwc1dnMjlORG9HR3YxaXMwbTNS?= =?utf-8?B?akI5RVlwZkRwUDBqSURRM3VzMVVpeC84ZGs2TVNXNEFQcHU4Rk9CRkdhNld4?= =?utf-8?B?SDUyTnNjdTlhdmk4TzJWSGhCeXlNZjlWSms3TzBNSWZPZ0Y2RHVNZkRQL21Q?= =?utf-8?B?YjFiN3lZWXFBMWplVGwzcW9KK2Ird0FpelQybUp0b1gvOEY2WnBjZGdPQnVF?= =?utf-8?B?RzB1QmpCYlpzYnBxMGpFMVVnNXl6NWdCd1RvQTY5emp1TGpPVndTQzlwTHRh?= =?utf-8?B?cXFvOERaMTc2M2lqSDR1VDNWTEkwT1B6VTAvZm1tVlQwMzB2cVA2QzJBSGJp?= =?utf-8?B?RGRCRnJUelVkWXp1cEZtaEFIZ3JvSk5HOXRKcFlaQmkzUnMvTDRxanQwWW1G?= =?utf-8?B?b2tXcHc1TXdCaTlTVCtVejBFL0d6YksvWmFNZHhxbVI1S1FhZEFyWjZWTkJP?= =?utf-8?B?aXdCSWo4MmxHcU4xVnkwb3FSdkc2WDRlcExhTXZ0MmVGSUtZcWczZGtIMFlz?= =?utf-8?B?UkF6NjhSTzR2UldzSlpQdVV5Q1JVZFlOQ3RScjJTdkIzWXRIVllBd21NK2JJ?= =?utf-8?B?ZENBcGFvbG9Fa3dKVDBLMnk4ZTZzT2libGkxdytaa1ptUTVuajF6RXJya1RH?= =?utf-8?B?djBDMWgrdGNldExqNGFrZFFTUStwRGErbU1xc3JDQ0svVW5XeFR0eFFGTm8y?= =?utf-8?B?YThyUjl2V2NYSDZEdk9rd2xMaFNuOHRlMUZxaE1wem4ybTFpbzVNVW1jcDRM?= =?utf-8?B?Zk5BOE1IZHlFRThROFNRVUlrbWVOMW1CR3JUcFhmeXRWSkFhYzFCcHpSeFJT?= =?utf-8?B?MXVhQzUyYzdhZVJwQUNDcFFPbHNHbHhLdDhYSVdMZTlSNzBrcEVyOW9oOGRF?= =?utf-8?B?c2JkQ09nZnBDeSt3dXdOK0t4NWJLMzlWVDlZZGNNV1ZUZ3pQWnUvRHlrOHpJ?= =?utf-8?B?VEoyZHl4ZC91ZmU4RmtzaHlmbzdPL216WU5YSm1TSDN5Um1Rc1ZpNktlMUdZ?= =?utf-8?B?UmFJdXRhNUxsL0JGckVDekw1RUJITHFoU0tiMGJBSUNzeFRLVnRYT1lRSU95?= =?utf-8?B?bHlRNzgzKyt1TG9vekxxK2x5MkxVVTYzVXpPOUg2MndhRE44Zlg1dlk2MEMr?= =?utf-8?B?TldKVkRHczhDQ1NMQ3NReHl5alhIYnZVRkwrUkc1cHdjd1FjUVQvb041MTho?= =?utf-8?B?ZTlWZXluZ1Z5MWYwNzV0WXM5bk9vVjdUVFlBQnNNbmZWOWFYdWxYRk5NV05h?= =?utf-8?B?a09YU2xvTDJsUTNCVkJyQWFCVEhhRkhpbkFBR1J3cVBUV2ZDSWttNzdhamdH?= =?utf-8?B?c3JnT3dYamk4Q0JkWTFFTm1ZS0pPc2VCdWZTVDFmWWQ5SVREQ09neVdEUm1l?= =?utf-8?B?Vjd3M1A5cGIySjMxeFQxdUlsLytGeXh3aHkxK3BseHBBL1pwK09ZNllyakxZ?= =?utf-8?B?anluSDN5Z0xOdExvTzZmWkd6RUFZYzdBVXpHUzUvWVkvL25tV2V3NmZmNTV3?= =?utf-8?B?TUk2WDd5cGlrMWNLUm1oWUsxN2EvU1AxRGpIaE9TVDNtaHd2Ujlrejhaa3Nu?= =?utf-8?B?ZDI1YldqRHVrL0MyT09kYU9EdzZFek5xRnpDejU5L2NrUUhiT2FjeTJ2TzNJ?= =?utf-8?B?ZUhUcFBlSEpSRGplWkFuLy96TkIyeXpmc2puNzZPMTVsZ2E3a1VEa3hnVXRv?= =?utf-8?B?a0VWRlozYm9saWlqT1FCSjJIR1JJUlgwSENyalVSbkdVQ3FHQ0JTc3p6Vzc3?= =?utf-8?B?MWlDUEFuSGhzMjFjbnI5c1oxSUZzVm8rVzZsRERpcnhLQnFZK0VqQVFQNDdU?= =?utf-8?B?cmErYlNpdUFzS3BtUUZSWmRYZmlrSkFWM0hlSDl2TXMvSWhGQkU3US8vTWsx?= =?utf-8?B?Y0VnNzRGK3RNRzZxQ1g3OEFEbTAwNEJ3eTJLZWNHRDJrQysreHV4dlhSV1px?= =?utf-8?Q?Si87uoJaOpcPSv2E=3D?= X-Exchange-RoutingPolicyChecked: yPWX5CL9CYlPg2jIIJoEQmSIkPg0EQTeLPep03EZ2rQNO2eXxbrXYmQR87lKJ0KTHIctEixBdW1h7N1wWE7V2nXUfjra8QU0xBz5sMZ5EDZ4lTmQ8nyOGvDVYKIZQTimYBuGOqWYKm1YH0CTYbsIE/fKCr2BrvhQY3t8Ch675nLGc5lGWZHB0Sah/5FVNJE8a0Nex2GUrbiYb8yZIY33FFefMmObvAR7gAnD/YRlt29iCKWzh2HFSd2NaHqNCLZnvqkfNwlySVRd+RtTitXnw9PFX5cEeUO7JOfsW2fZjs4Hk/iw8viuBPvVgi9gHhQJL2cUTfaWth9GesqxVS4+Rg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0fd87a39-f822-43d3-166b-08df29e5b4f8 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 11:24:27.2679 (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: hyi9viHEsH5h8QkvCq1evxOPmMVLaqkwXu6qn4UsrNKB+N0y83WSC/nQWfhg9l7hZQhRfv2Ff8tVhDUwpo7FaIK9SC2yQOBAwm3WRYsO7LU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR02MB7595 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA0NSBTYWx0ZWRfX8nFt4J/MhYLs YD9l8Gm+qdV466ZG33U6LTNLI+9ozj7Txs7443tL2ZwjWo6ezcKuzOL4fvajkUkp//PW4p1L4Ee kmGLnCR0OZ7s8RhiDJe4joVpUaQxcaY= X-Authority-Analysis: v=2.4 cv=dfgVTnXe c=1 sm=1 tr=0 ts=6acf666d cx=c_pps a=XSy6xVanZX0hR9uvxkBJyg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=YTpg2wbwm77mjifCQ_kA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: Qoz3gkV64PytRdUnL2AFpZViDOtsa9C1 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA0NSBTYWx0ZWRfXyMcvyY9JuAwB FcmojvORGZpXLDjPN1kHG61ENMKb4fIYEUrj5YCSXGkYUy8oKeLgo6rNeDofSGUPXcErhUcQf5h UsHFXwvkMgHTyxIgtLro4clcv7C8Q07DLTv/ZnlrcZuchRTOLGghvGbcscFyVNyFesvph6jYFO3 lFM2p9CnPx9fGMQCUKFRnxglSPgYZ5AKZUNm9GeHMuC1toENKuvaCgTZuHcgzc8Pxe2pHi/FIuC J9NV30dBltlyuRMy2N3wHIGgTx9IpR3TvjyK2cvQqCb4JWuIv2dGgVP4yB8NkgE9DywmUkmsMfI 4sLq7jR9QAgZs2h/sDJAQv3ggtveZh5m5xxXbcgDfsYjzCLAYinD2dJjtipHBSsL9M2Uvn1emHm +cDTpIRt+Cx9hWYX9uZiPOwduYZb4fFmRWBAPO6jZvwjz7TE9JKEzsUw1iEbchGxzsKFYgvKkBi mw7ObwTHdH+NdZp1F4w== X-Proofpoint-GUID: Qoz3gkV64PytRdUnL2AFpZViDOtsa9C1 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1791977074-A7CD7AE4-B0AD4E1E/0/0 X-purgate-type: clean X-purgate-size: 1997 On 13/10/2026 17:29, Peter Maydell wrote: > On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland > wrote: >> >> 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 > >> 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]; >> }; > > >> 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 >> }; > > Would it make sense for these two types to have a common base > class (where the stats stuff could then live)? AIUI they're > both intending to provide the same interface ("pair of i8259 > devices cascaded together in the way that x86 does it"). I did consider this in development since it would avoid the duplication here (and potentially in both realize() methods), but wasn't sure the extra complexity of the object hierarchy was worth it. However since you've also raised the idea, I'll have a look at this and add it to v2 if it looks good. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:29:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:29:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448819.1664842 (Exim 4.92) (envelope-from ) id 1xGxAW-00008e-1o; Wed, 14 Oct 2026 11:29:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448819.1664842; Wed, 14 Oct 2026 11:29: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 1xGxAV-00008X-VM; Wed, 14 Oct 2026 11:29:11 +0000 Received: by outflank-mailman (input) for mailman id 1448819; Wed, 14 Oct 2026 11:29:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGxAU-00008Q-OX for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:29:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxAU-00Bv14-1c for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:29:10 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf677d-bab6-0a2a0a5309dd-0a2a4502d1b8-20 for ; Wed, 14 Oct 2026 13:29:09 +0200 Received: from [74.125.82.174] (helo=mail-dy1-f174.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf6784-6ca4-0a2a45020019-4a7d52ae9e28-3 for ; Wed, 14 Oct 2026 13:29:09 +0200 Received: by mail-dy1-f174.google.com with SMTP id 5a478bee46e88-35159e0092aso446333eec.2 for ; Wed, 14 Oct 2026 04:29: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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1791977348; cv=none; d=google.com; s=arc-20260327; b=Uj5rfTIRTdHTmQmz5l2RGtvJXZBoiv0SLPAAG8cN8boW67AJFfKXfe6hgXzgR1FeVR pB0ir/fI3O6doonB3Nxi8Q2WGHe6nff2XscRpsW/+Ul4Hw+5uOxDdOa1QQ+1AtDMGW/t YNpNP9Ys5c0qK8EA4mZz1rKX5emzoiK4Yn2RIPyBt5GaTBUXy474Cfh2RNEHVxRu5jmI M8Li5g0Gvb5wgMbMbPZn9n9DzxsJWtpIRMRuL2wYhT38uS2pLODBgkIdqXrOohqQYlM2 4rNHahWseb2IzTBfrYfd+l3dhIzA0XGXgjVIFsNxw5XjOh76BgbkVMesKQDGaqrdrmuw 5Rjw== 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=xWJCwZOmpC49YtbA7QzlowrBvokYI4WD90uvALsrwIA=; fh=yPtcoeQFsAo9lXGb61vAWgz6GoL9BIq2U4FsndOWfJY=; b=WAR8VeJOC6B67SX7XZ1e+VsRytDCC5h+u3ujDRdoVL0TglG2vOpGTRDSEunJV8Em17 31v0o42w1SCaj5o1OfPOJ+XGSqjOhPhXqxeu6JL4p3coawVjqlIdxc9m3c/Bz9gUsBXm 6xvNJdKy4SuXtlM0o8c412qwCtyo5uWKW/1iWau2zwJm7yq7xdO2r/9BhaDJELrAa6mY B2x5MdVrVIpcdHaNT4nYhJsXAmRhstknGkGZcH4ATd9fC/4Yh4yoetgTsmxjrbTWK2uy cwj2YgTa6+s69QZKupOk51xhZFjG8f4JYLyqbHFHtll7EnYX3jv/Dfll0vrejA9JhDxK Cyqg==; 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=1791977348; x=1792582148; 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=xWJCwZOmpC49YtbA7QzlowrBvokYI4WD90uvALsrwIA=; b=iKXvaElS6gELKlFMETwsfU1oTqjFOQoINlVHKfdhRJw3E1d7YedgRlO3nNpcKi+nxp CobuJkmEW+b/53QmiuNh4OZ6IFNRAtGy63r/1Ghm6y5n7nEircIr7pzISvv5rhTo11Q6 75/24ogH3g+bob4xYp1JcMTepLVUS4mNrPHhH6TKntFCQhbtsrR4zvkHkyEjofjK87kZ N2zoENZw0PC5zX+Gaj4S+d01tsX90PLvfFde1BfAtq+PGL1duWRUKSWIQu8r4FMtIpNe 5/jgPn5lvTYNUhLMZ34xQdC1zuxQKmc/KCqM3uWSwmoFB2JP7OeUo/ZzZVdWc5I/dhrP OE2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791977348; x=1792582148; 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=xWJCwZOmpC49YtbA7QzlowrBvokYI4WD90uvALsrwIA=; b=TomNf663ui3W5gH6jc/vhQXFNlfDsA91SUbwluHd6U6YPwJpuLcs0m2SKiFkN59qD1 zNNm/bfej72aayawJszz/Eew+CAvBwWJinLB3ZdxiqcLMJMSVNMCfUfTKsZ2b0oBP05F g8AtSBWRB83pFg9lRyGdPaQZR2csA7VdIJ8wee31KSuYSIMIravg51RYNFS0Yr3+X1G+ DEySR8yob8k+gikCKn6ZGkW13E5dAzwV1FYXO6pWTzwTVDoWTy7dC6V+KEK7ncPaf2Dr BUJ0GO3At9bGoPGmABICc8O+oiNSmNsERjSRW/s333+yl2NSpXoNupUiVI5T/o8Pyd8z jl8A== X-Forwarded-Encrypted: i=1; AKwUvBztRoRBu22gzbn7j5svpD0xGM2ZouOWbwSHX9U7VVLiDkYvZ2K69c+pe6t6SOITPGLiNVA9bI5iFMU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKP5BUjtwiP+3IE7yYsemgu8AGtP4eA60RAWZ1WU74wJ3t7yDmQ XhVJdbHirHpU2KPLUlmIp4R/NOjVmq1YtW+YUbxDW95AY/xCbKHU0iEOaY7WFNZlOCn/GGAWqII ww59q4WgdUIkVEeM4CVG7t/B6X5bUBM4= X-Gm-Gg: AYBFou2mKEIocMrD+ih1FzhlsWu6mlDtvPUwAR8FyBMzA5cBVI7MLJOpbQBSR+CTBRa tcfmy5EvcBbH/LbzopFiZypgT9LZA7YSqgtC0FF9l1fZwh5hd7a5pwlEh0AuYNOIssrKTdZv8wc v3g33AxKzZoaVK25Rh5M+isTMimGpWYDf1ys0vviCwKuVqaqU2HCYiyY2RJooPlN9xsstjEb5j4 RUAryCgySIX2mXwnUjemdVxGvpJvPkXwIVoeASg8WdbtPjiC88oauZjQi8saPouSSsBKVq8av/S uIGbgmeDhJX63uUgIbGgiS2MLmRwoSolRzcQmb1mpmdRd6xTXlIVJZXkcE9rgQq5NoTw6BxUuFn YVtJauC0BbSMEYznUwKKsMRgBvkOjbZoI3cE511+mr91uKOBEV9cH4ye8D9PFA2KKeuzn2oVxph WvdYyEeSoFfu4jtHg4P+OpfViogg1rDGQTAqb3QU+P5NPonpek3tE= X-Received: by 2002:a05:693c:6215:b0:35b:cb8a:8ce7 with SMTP id 5a478bee46e88-35bcb8a919dmr14326600eec.1.1791977347656; Wed, 14 Oct 2026 04:29:07 -0700 (PDT) MIME-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> <20261013223946.1836757-2-irogers@google.com> In-Reply-To: <20261013223946.1836757-2-irogers@google.com> From: Miguel Ojeda Date: Wed, 14 Oct 2026 13:28:55 +0200 X-Gm-Features: AclHuK8qVHO7HVQy6LgzcUgjYcQf3EimC6SJcN58PVqcWVdOf6T45eXZNeTLsEY Message-ID: Subject: Re: [PATCH 01/11] Compiler Attributes: Add __require_explicit_initialization macro To: Ian Rogers Cc: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1791977349-F18AC2AC-FCD3F2C6/0/0 X-purgate-type: clean X-purgate-size: 933 On Wed, Oct 14, 2026 at 12:40=E2=80=AFAM Ian Rogers wr= ote: > > +/* > + * Optional: not supported by gcc > + * > + * clang: https://clang.llvm.org/docs/AttributeReference.html#require-ex= plicit-initialization > + */ > +#if __has_attribute(__require_explicit_initialization__) > +# define __require_explicit_initialization __attribute__((__require_expl= icit_initialization__)) > +#else > +# define __require_explicit_initialization > +#endif The LPC slides mention Clang 14+, but from a quick test in Compiler Explorer and a `git log --grep` on the LLVM repository to confirm, it seems the attribute was introduced in Clang 20+, no? If that is correct, then it is not available in all LLVM versions we support (LLVM 17+), so we should add: * Optional: only supported since clang >=3D 20.0 With that: Acked-by: Miguel Ojeda Thanks! Cheers, Miguel From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:35:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:35:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448832.1664850 (Exim 4.92) (envelope-from ) id 1xGxGY-00021R-Ks; Wed, 14 Oct 2026 11:35:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448832.1664850; Wed, 14 Oct 2026 11:35: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 1xGxGY-00021K-IG; Wed, 14 Oct 2026 11:35:26 +0000 Received: by outflank-mailman (input) for mailman id 1448832; Wed, 14 Oct 2026 11:35:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGxGX-00021E-9i for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:35:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxGW-004LBc-Fa for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:35:24 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf68f0-2eae-0a2a0a5409dd-0a2a4506b1ec-28 for ; Wed, 14 Oct 2026 13:35:24 +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 6acf68fc-195a-0a2a45060019-d155dd33b0d4-3 for ; Wed, 14 Oct 2026 13:35:24 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48af4d4e61fso2898082f8f.2 for ; Wed, 14 Oct 2026 04:35:24 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376522.centertel.pl. [37.47.102.11]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de7268680sm5316489f8f.25.2026.10.14.04.35.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 04:35: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=1791977724; x=1792582524; 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=DZNoVYsYeZeqjLqjz1WArRhWgrfldUwyfuLmQBHBv1U=; b=Ib3D+r+J5/7dgd1zBGtJBUYBZTW5hW0XGHPr6bORefONrerr5P3qsdplX0oXZxVCEg 4CKjEjLWQEWe8uJGLUNZMj8Cak7kxz85AgtSRSwXxJw/jpypux1KCP8mvUc009s0CvOd rdlQwiYkftksvtAY4ijFC7YcgeJyX6gT/Thp7vfOHmw3VtNcdRdd8WdOOBGG8EAU4iB5 3k2B2HFIWtvPK1IX1ecLgLD3R2z6i6ZNNsjjsc0v9ZhAYymdKIq7g847pjHLVU/jww+N Cjc9ZXgJWFcQRHt57nfRieCqMhB6+F1505B1XX9S2C7Wrhoq17PMR8btWG8P3ZxSnT+u NBNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791977724; x=1792582524; 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=DZNoVYsYeZeqjLqjz1WArRhWgrfldUwyfuLmQBHBv1U=; b=DnXT2VJtvMhXHJXkE5K6/MZ9YOd8pqX50qu/96ze5EHTHUQXPLzIqDpNB/T7ZeOHbW P85Zdgj7/LkuTnWSeb/1Hrqt1LOw2RnL0YWpa/45SQFesRv/y88yaLxmE0xoEMmxRm8a NMHgaHqGd/UOoB3PnRCvXc3G9VsYB5sDcwD9+DhydvASiU67MWpck4TlsH/lYQwiZwc9 tnE++isS1X4msKD32p4tbzLPLcHPHxiPLmSJeZYDNE2OtWnp2AoHN7edkZgZCSXJ64FY KXld2Wox2GaS6fSclO2LspdBN4hvzsCA/IhCFNG9rUTonU0ix5xRFK1zUwPXrUghCBXS hL1Q== X-Forwarded-Encrypted: i=1; AKwUvBzJM+T4mlqX+2IwW8cFVXORzGBUUJvYrtQXZ41glT+UCa4ALfu1Gl90yheOIqWkiQ7t94EQ8H05vxQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYJHu4pJrxSOl9CCCuA/og8KYztxGi9exquFKc0SgRsqEAHftar/ GUuxnFOVdD/+jYHQS8addIpeNm9MXKMtEqdjKeJbusGsm2wvJWCgUUCO X-Gm-Gg: AYBFou0+7hUkr2JBn8xp/WbOuq3L7y/C524GVpCffpYUxDosEjYqN3VlutH7cHd2FSI qCFbLxQLBfO0a1YdQJLrplcZuntRmCl9ogVXtr2GW3U/60XaHNwa/1XHlhuP2jawmV9ZCORAWam RMdAx3oO+J9Ugwkd004I0veHW2ncLmdHIsdf0vWPE2mzF4VIExuOZHfU4VnDzy60eeaKn0h2kbm zmfHnODSwiiP2uA+qrH2a8zT8IUnsZ+KM7D7NP4ZFyBUnv+1jSCaT1S57V4Xy6hWF9ibY4SwhFK zq1ZhwhcLxtmX6BD0I0oiGDYGfm/MRbkLLk3vcEd5W62E0J4lOfnqvMFBy8Pa+pihvN6dawHe/q ZwhGQY7mMaLF7IaS24c4F8jr2LuZIhnm/ZyXym3LbZs4P37uWyXDCna4LNL0w0ZFR7cFIRdIC7U dY3dX58zEBPvImu8UGkPlG8S0oS1FVeM2j3SeM1QGUuaJVtzMwKK7mTaQx8NDJlhMNOk8OTbaKF mad/bzomnJYKs4qsN4XepU8QGRaWUES/rK9b6o= X-Received: by 2002:a05:6000:2991:10b0:488:8352:cbfd with SMTP id ffacd0b85a97d-48dbad3820bmr22819430f8f.46.1791977723837; Wed, 14 Oct 2026 04:35:23 -0700 (PDT) Message-ID: Date: Wed, 14 Oct 2026 13:35:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 07/39] xen/riscv: introduce CPU_NONE 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/1791977724-F7ECC77B-3D43769A/10/73395122804 X-purgate-type: spam X-purgate-size: 2733 On 10/12/26 5:40 PM, Jan Beulich wrote: > On 30.09.2026 18:18, Oleksii Kurochko wrote: >> Introduce CPU_NONE, a CPU number which doesn't identify any physical >> CPU, to be used wherever a pCPU has to be recorded but there may be >> none. >> >> Its first user is vsfile_cpu in struct vimsic_state, which records the >> pCPU whose h/w guest interrupt file backs the vCPU's IMSIC VS-file. >> NR_CPUS has been used there as the value meaning that there is no such >> pCPU, i.e. that the s/w VS-file is in use. NR_CPUS is however an upper >> bound rather than a "no CPU" marker, and it already carries other >> meanings: hartid_to_cpuid() returns it for a hart Xen doesn't know, and >> pcpu_info[] uses it for an entry whose processor_id isn't valid yet. > > Yet these could (and imo should, subsequently) entirely plausibly also be > switched to CPU_NONE. IOW I don't think ... > >> Use CPU_NONE for vsfile_cpu instead, so that the s/w VS-file case can't >> be mistaken for any of those. > > ... this is a plausible justification (nor in its re-written form as per > Baptiste's suggestion). Fair enough, that argument doesn't hold. Rather than leaving them for later, I'll switch hartid_to_cpuid() and pcpu_info[] over to CPU_NONE in this patch too, and justify CPU_NONE by it stating the "no pCPU" meaning explicitly instead of reusing the NR_CPUS upper bound for it. > > If you want such a distinction, you'll need separate sentinels for every > one such field. > >> --- a/xen/arch/riscv/include/asm/config.h >> +++ b/xen/arch/riscv/include/asm/config.h >> @@ -136,6 +136,9 @@ >> #define OPT_CONSOLE_STR "dtuart" >> #define INVALID_VCPU_ID MAX_VIRT_CPUS >> >> +/* A CPU number which doesn't identify any physical CPU. */ >> +#define CPU_NONE (~0U) >> + >> /* Linkage for RISCV */ >> #ifdef __ASSEMBLER__ >> #define CODE_FILL /* empty */ >> --- a/xen/arch/riscv/include/asm/imsic.h >> +++ b/xen/arch/riscv/include/asm/imsic.h >> @@ -71,7 +71,7 @@ struct vimsic_state { >> */ >> unsigned int guest_file_id; >> /* >> - * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS >> + * s/w IMSIC VS-file -> vsfile_cpu == CPU_NONE >> * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS >> */ >> unsigned int vsfile_cpu; > > As can be seen from the comment alone, there's now the risk of > CPU_NONE < NR_CPUS, at which point users of the field will be > screwed. I think you want > > BUILD_BUG_ON(CPU_NONE < NR_CPUS); > > somewhere. Indeed. I'll put it into smp_processor_id(), next to the BUG_ON(id >= NR_CPUS) which relies on it for a pcpu_info[] entry whose processor_id isn't valid yet. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:38:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:38:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448837.1664860 (Exim 4.92) (envelope-from ) id 1xGxJ1-0002qI-0u; Wed, 14 Oct 2026 11:37:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448837.1664860; Wed, 14 Oct 2026 11:37: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 1xGxJ0-0002qB-UX; Wed, 14 Oct 2026 11:37:58 +0000 Received: by outflank-mailman (input) for mailman id 1448837; Wed, 14 Oct 2026 11:37:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGxIy-0002oF-UV for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:37:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxIy-00GY0D-50 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:37:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6985-8faa-0a2a0a5109dd-0a2a4506db84-36 for ; Wed, 14 Oct 2026 13:37:56 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf6993-195a-0a2a45060019-b9ff1c1296e1-3 for ; Wed, 14 Oct 2026 13:37: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a13a3453cd0008425.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 11:37:50 +0000 Received: from [192.168.27.69] (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter) by mail2.vates.fr (Postfix) with ESMTPSA id 7A4DF81C40; Wed, 14 Oct 2026 13:37: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=bcazpVnqkdFyGQ5XMhN/ZYe7RqYqiecYYMqSrWxxu9I=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ARECPwwdJBLsv+oVD17Ar7oTedenPvDFdwGYKVJuVy5ysadzOvZVtNLUWj+ZLUcxQHG+vV1BN V7p6IGeCndXpM5ocG3mimr3w0DAi0xYkWZfyqm9qdg8BFWCj8jmzT0mRxkzXXCv/Fyx+YDuOJu/ uoRygQfiNV44l7MUM0lXpFS63QYDVg1TSaaCtQ8aBqpvXTUUUu8e/MU/5f1HxR+n2lVZNmXV/G7 mhSxciV+kWjic+TCGmoTIXQrn8JyOBN6laP64n6VD05uO3PuXQH/P4K+xBToi7pz0ymLne4331R h6B0KnUYBXliNplVAxN0k5PRr534WaJ14zJfiTVKC7Dg== X-Zone-Loop: 5ccbbaf0ed233bbc27aa51e3f4f169cb6a024cadae9a x-campaign-type: default x-transaction-id: cbe75cd9-4821-419b-9cfb-d6ff75fd1e31 x-swg-uid: 01-fee874a4-b743-474c-bde6-0621a24b9a92 X-Mailer: Sweego Message-ID: <1791977870.8631fc262581453bbf619ec5b2062170.1a13a3453cd0008425@vates.tech> x-swg-bid: 1791977870.8631fc262581453bbf619ec5b2062170.1a13a3453cd0008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 14 Oct 2026 13:37:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 0/5] Fix ARM domcreate To: "Orzel, Michal" , xen-devel@lists.xenproject.org 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: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> <2482f3cc-e9b6-48d9-b8d5-a463feb82dfa@amd.com> Content-Language: en-US From: Julian Vetter In-Reply-To: <2482f3cc-e9b6-48d9-b8d5-a463feb82dfa@amd.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.1c0.67e1c98e15f75819.1a13a34510e.93d265343ff7e2f1=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791977869587 X-purgate-ID: tlsNG-16d1c6/1791977876-F7ACA77B-5727601E/0/0 X-purgate-type: clean X-purgate-size: 3324 ---=Part.1c0.67e1c98e15f75819.1a13a34510e.93d265343ff7e2f1=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/13/26 2:28 PM, Orzel, Michal wrote: >=20 > On 12-Oct-26 15:36, Julian Vetter wrote: >> Hello Michal and Anthony, >> thank you for the reviews and acks! Michal, I have addressed your >> remaining remarks on the "xen/arm: report clock_frequency via sysctl >> physinfo, not createdomain" patch=2E The golang bindings are regenerate= d >> for the new arm_clock_frequency_hz physinfo field, and >> alloc_domaininfo() no longer references the removed clock_frequency >> field=2E Apart from that I have collected the Acked-by/Reviewed-by tags= =2E >> >> Signed-off-by: Julian Vetter > I was about to commit the series but I found out that some tests like > test-mem-claim and possibly others still pass gic_version=3D0 which will= cause the > domain creation to fail=2E You need to update the tests=2E Yes, thank you=2E I didn't see this=2E I have fixed the tests, and ran the= m=20 on a QEMU setup=2E 2 of them now pass the domain creation at least just=20 like on master (1 doesn't work on QEMU because there is no IOMMU=20 emulation?!): ``` @@@ RUN test-mem-claim Memory claims tests Free pages: 254208, Oustanding claims: 0 Created d1 Failed to populate physmap domain: 16 - Resource busy @@@ RESULT test-mem-claim rc=3D1 @@@ RUN test-paging-mempool Paging mempool tests (XEN) [ 28=2E386587] common/domain=2Ec:845: IOMMU requested but not avai= lable Skip: 22 - Invalid argument @@@ RESULT test-paging-mempool rc=3D0 @@@ RUN test-resource XENMEM_acquire_resource tests Test ARM Created d3 Failed to populate physmap domain: 16 - Resource busy @@@ RESULT test-resource rc=3D1 @@@ ALL DONE ``` But, unfortunately, these tests seem broken on ARM even on master,=20 because on ARM domains start with an empty P2M pool, and since these=20 tests call xc_domain_create() without setting the pool size first, they=20 fail on the populate physmap call=2E I'm not sure how to proceed on this= =2E=20 Should I fix these tests in their entirety or leave this for another=20 patch set? Thank you for your advice=2E >=20 >> >> Andrew Cooper (1): >> ARM/sysctl: Expose the supported guest GIC modes in physinfo >> >> Julian Vetter (4): >> 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 createdomai= n >> xen: make config argument const > Here you are still missing tags from e=2Eg=2E RISCV I think=2E >=20 > ~Michal >=20 Thank you again for pointing this out! Unfortunately neither PPC nor=20 RISC-V have a formal maintainer defined in the MAINTAINERS file, so it's= =20 actually "THE REST" responsible(s), which is also you ;-) For RISC-V I=20 have asked internally to do a review, but this will only add a=20 'Reviewed-By' not a full 'Ack'=2E So, not sure what to do about it=2E -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.1c0.67e1c98e15f75819.1a13a34510e.93d265343ff7e2f1=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 14 11:45:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 11:45:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448845.1664870 (Exim 4.92) (envelope-from ) id 1xGxQD-000569-Oq; Wed, 14 Oct 2026 11:45:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448845.1664870; Wed, 14 Oct 2026 11:45: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 1xGxQD-000562-LP; Wed, 14 Oct 2026 11:45:25 +0000 Received: by outflank-mailman (input) for mailman id 1448845; Wed, 14 Oct 2026 11:45:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGxQB-00055w-QA for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:45:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxQA-001BsC-Pj for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:45:22 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6b45-2eae-0a2a0a5409dd-0a2a45099850-44 for ; Wed, 14 Oct 2026 13:45:22 +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 6acf6b50-be1a-0a2a45090019-d155dd34c587-3 for ; Wed, 14 Oct 2026 13:45:20 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48b042c0728so933410f8f.1 for ; Wed, 14 Oct 2026 04:45:20 -0700 (PDT) Received: from [172.20.10.5] (public-gprs376522.centertel.pl. [37.47.102.11]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0ac35dfsm11655349f8f.33.2026.10.14.04.45.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 04:45: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=1791978320; x=1792583120; 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=KRNKjH5pVqXD1rzVhV2/qbL5QXfAVoAd2SGKZnnMh3k=; b=joymwXt+clKREMBdZpzVkjopM4qF9H30DRmfcCZA+M+/95kJQaE744xdrfew5Lou3o F3Bax+Ldu1mQv+Oyft4TOrL9Xnm8YEXmKL3cRQX6tCA/wEu9SgbfJbDsmExijlFX9t4C iJmB0MOl2HLOBdc54kkDtT+3o79puNEKi4YJiow391+b72xgpCaGigaJym+0UIgrZGFr PODmGNuMukXtxww88++qXYQtAe24HgKw/hgWisstVApcfE7JZq0Qv82EXLObUO9pedKP 6t6NDBxqdWzSypgFulJz2xi1EFusGhc5ZkCloSDjtf2tbYdZccAu/RUpxBaINmYyrSDz Ky/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791978320; x=1792583120; 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=KRNKjH5pVqXD1rzVhV2/qbL5QXfAVoAd2SGKZnnMh3k=; b=HJFFaDCXgD++tJsErNp794vKWYGCtk4jkSE7KoCfrtKrMwix8sJPgAGxX1xRZYW4i0 xvv8L9ir2VOijVUt9sKUt/XK66OJDhARheNhdx+AYkx7CbTk1npQET42kMbrEI4LoyzR Mw4RR8k1UwNWSB9G8zXd+88QCmyenqPCqLvkgKoRxHTI+hP1f5JxvF3MnZGaee7/jvqV vtRfj4fRGE3wuLxE9qbmpoyIhc+a+wkEPdBFt0McgXFO9lD+WfRQ/0/sifCUZL6DOJuU qp4X6IwzSoZCTaUo5X/+s3p8eCFO0YfwWGht8N1oqN3QitlRez2Csb3kvi6xt51xIQw4 jO5Q== X-Gm-Message-State: AFq9FYL5217WNwbR/4EritmsFfqBC/rnmc1wLjyDVnv3amUiVPHQO6YC /sK/4wnZAOBbZiG82cV6YNjTgRS9QUl3GRKf93N5p8fbRITpgLcC27UZ X-Gm-Gg: AYBFou0x7hbW+lqR9A/yFhZ5J8h4mys682FS7zd77dEKfAOJrE4kKF5XKHYOSP3TwSw Jr7pnVH+6ugamai2O49HBXkgkp4kF1MYi76GNEFEbT19rXEt8g+XKIx4dj/SOxVuS3LLX9Dazt1 VqpycA6/AEAP0mmZHYq4ZlfUORelo1U7JLxU7nQM/2Imi2vXUb6tNWQabhqDhxjB3FnscV9JyRa rmvGEQ37ydBweTX2gAF/UdUJn8BeuwzCl0r9b2D4zxaEJXerd5+CYsvXsZwW79VnsKkICsWDp+9 7VBSvCkOgXX/iKlDA0GkjWGSVuaRdUpp2dylcaMEPxCE9rCjjsM6GteMt1952p4EzSUYrBSveAj Um9fgs3BYRwgZG0085fnT1f8BAl3xWYjpjM1Pw7HHU9krl//U66gPKO2kPT/Bl7e10Ej8AfZw+3 eTPjFZAKauWiADiO9ob/5XNb7wuawOrGCa/OEhYqMeZlVz5yUYRG6yTlLMCiHjFdwTBH6hsE8+e BYgZHkh/VrqUvp7ThnvpVNHw+DvQILjXkovMMA= X-Received: by 2002:a05:6000:24c3:b0:48a:fb55:416c with SMTP id ffacd0b85a97d-48dbaae89d3mr26907436f8f.21.1791978319957; Wed, 14 Oct 2026 04:45:19 -0700 (PDT) Message-ID: <10748eac-05e2-454f-9baa-35f015d70135@gmail.com> Date: Wed, 14 Oct 2026 13:45:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/39] xen/riscv: implement virtual APLIC MMIO emulation To: Jan Beulich , 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: <1791212017.8631fc262581453bbf619ec5b2062170.1a10c8e58370003f66@vates.tech> <6428c5da-0289-41ee-835c-ae5def434c52@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <6428c5da-0289-41ee-835c-ae5def434c52@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1791978320-BEEDE034-794914EA/10/73395122804 X-purgate-type: spam X-purgate-size: 2356 On 10/14/26 8:16 AM, Jan Beulich wrote: > On 13.10.2026 18:06, Oleksii Kurochko wrote: >> On 10/5/26 4:53 PM, Baptiste Le Duc wrote: >>>> 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. >>>> >>>> Register the vAPLIC range with the MMIO dispatch and emulate the accesses: >>>> - reads and writes are masked with the domain's authorised interrupt >>>> bitmap, so that a guest can neither observe nor affect interrupts it >>>> does not own; >>>> - target registers are shadowed per source, so that a guest reads back >>>> what it wrote. The h/w register instead gets the hart index and guest >>>> interrupt file of the pCPU the target vCPU's interrupt file lives on, >>>> as the APLIC uses these fields directly to compute the MSI address. As >>>> long as the target vCPU has no h/w guest interrupt file, only the >>>> shadow copy is updated; >>>> - only MSI delivery mode is emulated: target writes made while the >>>> guest's domaincfg.DM is clear are ignored. >>>> >>>> Delegation (APLIC_SOURCECFG_D) is not yet supported. >>>> >>>> Co-developed-by: Romain Caritey >>>> Signed-off-by: Oleksii Kurochko >>> Co-developed-by: needs a matching Signed-off-by: from Romain right after >>> it. >> >> I will contact Romain and ask for his Signed-off-by. > > Just to mention: Co-developed-by: can mean many things. We haven't been > insisting on matching S-o-b before. Plus if there was an S-o-b, why > would there want/need to be Co-developed-by: as well? I haven't checked if it is true for Xen (my fault). I know that such rule is in Linux (https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by): ... Since Co-developed-by: denotes authorship, every Co-developed-by: must be immediately followed by a Signed-off-by: ... I've never thought in that way about S-o-b and I think I can agree with that there is no point to have Co-developed-by if there is correspondent S-o-b, i.e. S-o-b by default includes C-o-b. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 12:04:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 12:04:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448885.1664877 (Exim 4.92) (envelope-from ) id 1xGxiN-0001HL-Ks; Wed, 14 Oct 2026 12:04:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448885.1664877; Wed, 14 Oct 2026 12:04: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 1xGxiN-0001HE-Hl; Wed, 14 Oct 2026 12:04:11 +0000 Received: by outflank-mailman (input) for mailman id 1448885; Wed, 14 Oct 2026 12:04:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGxiM-0001H8-OM for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:04:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxiL-00GOyP-U5 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:04:09 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6fb2-e002-0a2a0a5209dd-0a2a4509dbc6-40 for ; Wed, 14 Oct 2026 14:04:09 +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 6acf6fb9-be1a-0a2a45090019-b9ff1c12a30f-3 for ; Wed, 14 Oct 2026 14:04: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 1a13a4c5fce0008425.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 12:04:06 +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 007CF81DF2 for ; Wed, 14 Oct 2026 14:04: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: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=lVZY4m8lq60yyKfkLI9HNVvE+A7IfZPVIooGJDCfPF4=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=TcXal8Wqn4Hqdb8FNDdZo6f1yuQ06M8ENgNWkDAAoz9sZ0vHFBjobufLVMuaJxQ++VKfaCuss PSXstVZk36CBamQZ4WitZwmij/snUFKulj96+xcIGiPBw75dCM+1uShJvrUHKGPja9UMAZxOIIB eO+FEqTjyMjEKa/11h5NpMeb+51zLdffsE8iPKYUIyI6/5XTrIL111K7qEwWzCCw+QhpCtnPVEr Mijnc5Mk9mb0y8SmA8l3PBKAB6/UyG3uOlDrzIE1tMT8VUKEcFqSghR8t2QjuDzd42XUVOHJxAr 565Xk2n33r4um2CAjzJnCK7WBT3tAxQgKMGV7QnzRy/Q== X-Zone-Loop: 2e12086df38e1b4c07fe3cf8839b59f9d48427a28f70 x-campaign-type: default x-transaction-id: 4aca05ae-54da-40e0-9f01-40b6cf0f1ed0 x-swg-uid: 01-0d082fdd-e87a-4d6b-8685-451fef1fea02 X-Mailer: Sweego Message-ID: <1791979446.8631fc262581453bbf619ec5b2062170.1a13a4c5fce0008425@vates.tech> x-swg-bid: 1791979446.8631fc262581453bbf619ec5b2062170.1a13a4c5fce0008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 14 Oct 2026 14:04:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 5/5] xen: make config argument const To: xen-devel@lists.xenproject.org References: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> <1791812541.8631fc262581453bbf619ec5b2062170.1a130599b7500080d7@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: <1791812541.8631fc262581453bbf619ec5b2062170.1a130599b7500080d7@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: 1791979444040 X-purgate-ID: tlsNG-bad1c0/1791979449-3BED6034-18812A6C/10/78276251493 X-purgate-type: spam X-purgate-size: 8299 On 10/12/26 3:44 PM, 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 LGTM on riscv. Reviewed-by: Baptiste Le Duc # riscv> --- > Changes in v7: > - No changes. > --- > xen/arch/arm/domain.c | 2 +- > xen/arch/arm/firmware/sci.c | 2 +- > xen/arch/arm/firmware/scmi-smc.c | 2 +- > xen/arch/arm/include/asm/firmware/sci.h | 6 +++--- > xen/arch/ppc/stubs.c | 2 +- > xen/arch/riscv/domain.c | 2 +- > xen/arch/x86/domain.c | 16 ++++++++-------- > xen/include/xen/sched.h | 5 ++--- > 8 files changed, 18 insertions(+), 19 deletions(-) > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 4ca3a3749f..34b5a85f9f 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -557,7 +557,7 @@ static bool v8r_el1_msa_domain_sanitise_config( > } > } > > -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config) > { > unsigned int max_vcpus; > unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap); > diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c > index aa93cda7f0..f73ed06092 100644 > --- a/xen/arch/arm/firmware/sci.c > +++ b/xen/arch/arm/firmware/sci.c > @@ -45,7 +45,7 @@ int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *config) > return cur_mediator->domain_init(d, config); > } > > -int sci_domain_sanitise_config(struct xen_domctl_createdomain *config) > +int sci_domain_sanitise_config(const struct xen_domctl_createdomain *config) > { > if ( !cur_mediator ) > return 0; > diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c > index a0cc6c6192..391df8b945 100644 > --- a/xen/arch/arm/firmware/scmi-smc.c > +++ b/xen/arch/arm/firmware/scmi-smc.c > @@ -68,7 +68,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs) > } > > static int > -scmi_smc_domain_sanitise_config(struct xen_domctl_createdomain *config) > +scmi_smc_domain_sanitise_config(const struct xen_domctl_createdomain *config) > { > if ( config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE && > config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC ) > diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include/asm/firmware/sci.h > index 485ce211c9..1d566be8e2 100644 > --- a/xen/arch/arm/include/asm/firmware/sci.h > +++ b/xen/arch/arm/include/asm/firmware/sci.h > @@ -32,7 +32,7 @@ struct sci_mediator_ops { > * it to sanitize domain SCI configuration parameters. > * Optional. > */ > - int (*domain_sanitise_config)(struct xen_domctl_createdomain *config); > + int (*domain_sanitise_config)(const struct xen_domctl_createdomain *config); > > /* > * Called during domain destruction, releases all resources, that > @@ -101,7 +101,7 @@ int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *config); > * Sanitise domain configuration parameters. > * > */ > -int sci_domain_sanitise_config(struct xen_domctl_createdomain *config); > +int sci_domain_sanitise_config(const struct xen_domctl_createdomain *config); > > /* > * Destroy SCI domain instance. > @@ -162,7 +162,7 @@ static inline int sci_domain_init(struct domain *d, > } > > 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.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) > return -EINVAL; > diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c > index a333f06119..82a289af85 100644 > --- a/xen/arch/ppc/stubs.c > +++ b/xen/arch/ppc/stubs.c > @@ -162,7 +162,7 @@ void arch_vcpu_destroy(struct vcpu *v) > BUG_ON("unimplemented"); > } > > -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config) > { > BUG_ON("unimplemented"); > } > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index d94652809e..cfce8e91fa 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -284,7 +284,7 @@ void sync_vcpu_execstate(struct vcpu *v) > /* Nothing to do -- no lazy switching */ > } > > -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config) > { > return 0; > } > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index 6ebe6c5052..368e4deff3 100644 > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -590,7 +590,7 @@ void arch_vcpu_destroy(struct vcpu *v) > ASSERT_UNREACHABLE(); > } > > -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config) > { > bool hvm = config->flags & XEN_DOMCTL_CDF_hvm; > bool hap = config->flags & XEN_DOMCTL_CDF_hap; > @@ -633,13 +633,6 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > return -EINVAL; > } > > - if ( !hvm ) > - /* > - * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear > - * for HVM guests. > - */ > - config->flags |= 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, > > spin_lock_init(&d->arch.e820_lock); > > + /* > + * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear for HVM > + * guests. > + */ > + if ( !is_hvm_domain(d) ) > + d->options |= 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.h b/xen/include/xen/sched.h > index 73c54794ac..ce1fa636db 100644 > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -772,10 +772,9 @@ static inline void domain_update_node_affinity(struct domain *d) > } > > /* > - * To be implemented by each architecture, sanity checking the configuration > - * and filling in any appropriate defaults. > + * To be implemented by each architecture, sanity checking the configuration. > */ > -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config); > +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config); > > /* > * Create a domain: the configuration is only necessary for real domain From xen-devel-bounces@lists.xenproject.org Wed Oct 14 12:05:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 12:05:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448891.1664888 (Exim 4.92) (envelope-from ) id 1xGxjP-0001lt-UO; Wed, 14 Oct 2026 12:05:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448891.1664888; Wed, 14 Oct 2026 12:05: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 1xGxjP-0001lm-QP; Wed, 14 Oct 2026 12:05:15 +0000 Received: by outflank-mailman (input) for mailman id 1448891; Wed, 14 Oct 2026 12:05:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGxjO-0001la-Iy for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:05:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxjN-001GVx-W8 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:05:14 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6ff3-e002-0a2a0a5209dd-0a2a450bb57a-38 for ; Wed, 14 Oct 2026 14:05:13 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf6ff8-b7e8-0a2a450b0019-d15580aca996-3 for ; Wed, 14 Oct 2026 14:05:13 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8ae9bc9a2fcso48056807b3.1 for ; Wed, 14 Oct 2026 05:05: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=linaro.org header.i="@linaro.org" 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=1791979512; cv=none; d=google.com; s=arc-20260327; b=h03FcXtawEAiWwo821LVcAnkM1OnTYDMYbIaNbxDI6bFKPP1fiUrQoyJW1axww4DWW V1D2JiCldLvcOOyf/P7QIrq5BqUsT0IqsDQwwg34ZNqCWjffoWd+XPTDYpXbDZAoe2yL xqtLn7GCLxEoFTiV3voFIDjgx6X6884gxCYvWotO5wK40qAcyE7loZSOZezeQBcz/W12 3kZjZ0/jlRgxAks7GkGjv/h5wvFFLtiXkd5Cpc0uVXiBkkGHZSsrxik6faP2RJMGJ9u4 qNI6eBk/C4iW06Nnh2F6Lvq9u9ACixOzRWUNiKSmfyQkJqY9KzDL0PMsujXAd+NCWDPF 09WQ== 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=M9Nyl9xH3QF3gMvTwTw/sBu2NY+4Q2lch/paE09DFwI=; fh=/uRV87p3TPAlKpbDSvWDgcJqLfiqm7CwGwR7GDFLvbY=; b=pwYkZwKMDEk6mJhHCcvT9wkC9Uw0JIdV4ya7hZELy1FOLub+Agko/S6XmCa3yCfO7B /lJwarPchwSXPxxDag+SnAJsJz5/Cgny5NDP5m7T6XzpWuZ1hnbPjcSGN/jSRU++pgC+ o0drozRywfx9J4AHMCl0G4qNcYMWpba5+bOrrOUSQOf9JGpOU+tRXcFslDCeN1fD+5Ph 36ZvYflLk1G8Na/FwdaBye3OIVKToPN1mex9jRGdbFKwAjS4IZmXs6pLZcpln/FV/48s nlXatlNnSG4x8GT9270y3coRSid4V3JyOyZEM09UoN7COoCzQ+PugroCYzkSvuagV5ff iNhA==; 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=1791979512; x=1792584312; 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=M9Nyl9xH3QF3gMvTwTw/sBu2NY+4Q2lch/paE09DFwI=; b=y90HAjs1VzzalP78dA+W1XKM8+jFdyvEFtXMMAFjopuS9sWm+tYL0ILcgqRbxF8zlQ fX5lrOrBon6qkkNiSx/mKQG5xXC/WgNZUtYJRapMA3RXwisTD3M6el3nhZlVcgB9W6I/ NOXFUyrZ0QTbLPDewHgc+Saj1+R9B81Fx3CZ0OTEd29/ktLPmWVm1yLX/lRa7soGaD1g L2i2yr3JCbnV3aMBvNjk+fuLKArwvTbKcS0Tx5E26pr2ygy4VxorxQ6rgU4ieXce08ol CY9RXDeql7oTt9aE0FMSchLMeCMBfRdrurwQH9aPum3P4jRSHZLNmLXVSnTyr8UGqxeb UT0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791979512; x=1792584312; 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=M9Nyl9xH3QF3gMvTwTw/sBu2NY+4Q2lch/paE09DFwI=; b=YOHXtWv3FH5dJc0yiJmDBNBmMJxyj68SXeTI40uh4BmNmc8Er75SXNOj2bFwgeTVXd QFvCHfozjOdP8LudaP9OkqbmG3i2jbdy6IWy+pWfYc7nm5MVMR+um2TvAiNcPSc2tGtq Q93h/xKj2uJLvBCVae7pqJEmj5Iek3G5zMyVqP9UTezcE0tUjDXb0MpRY8TOP60pCnUM /IuPj5fyYHNOrFquenDgcN9CGkYmgWIgTCkrxz5H3vOwXJ7ZmcDhYt2b5ZLpNPOpbP5A xNkyoIr1p/FSpsa/PGhy/ocaM/o4x2qD0x9G4Ngq1ZR0EjADmKxRV+TWBRiOn80XRUXt kiKg== X-Forwarded-Encrypted: i=1; AKwUvBwypD9DvUjh4aDchEYJ0Mtpi7djfW/BlyTMe8AAwafJSKFyWBKCgbcgKqHsvl4QTpW0CQfPgUil3yA=@lists.xenproject.org X-Gm-Message-State: AFq9FYK+fUoJyDDJ9JDQVKGceFnCxEZUK10xyZQnBy523xvpStT4gpZS 2E3CtqKN3fQaVcZy8D40h3RS1JuWon6Vtt0de7zzBX5QB0OKgmc9OZMjy1tLsI6/LO46ipj5IOt ltt1H5JKMDCLH8EpMNsnRWiZ4vDXr395lQPrrIr/TZg== X-Gm-Gg: AYBFou2GDJD07RjTMmtFJSZCrCJEiihdplrfV9kDuPrFMUn67AmYI1iQ/vQik/u310i maHlbk3vJJ20LGDYK8YM4xVx/EePNp8inO2Bz5PzVVBdyryYS/utX+YV34Xt1s+x1iYFTcHJXLQ LXzTFr2P74/hR0zvJrDHyOvC1YcM7beFnH4gicFhp2ELqVvZCeTbXIkrRFwc6jlDALg5x3wtnpy 7lfQeqv/IPoK9G4wJ+UWi+1XTWGSGSDWBe8RQPOb3PPINApXWcwDIuGWvdXIk1bHDPmJxpgRWqC ztrfvBZ/19VJlX52R1hVovsKY1JMBiyUvcBb+Y8CcS5XTMGF+LRxD5wmWnrFxgKQxZxm10D2CIU AYRthpq7dC5b6ijpMX/UJ4sO8BFmo7nL0KvhAnQyDrwiq9d5BzA== X-Received: by 2002:a05:690c:13:b0:8b0:a30a:7f31 with SMTP id 00721157ae682-8b0a30a9167mr33446427b3.29.1791979512090; Wed, 14 Oct 2026 05:05:12 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-14-mark.caveayland@nutanix.com> In-Reply-To: From: Peter Maydell Date: Wed, 14 Oct 2026 13:04:59 +0100 X-Gm-Features: AclHuK_fKBiA6YUTOHdzTar_zcSRcOFWB6_EBRpgQCUFNyZdpL7rStVJCTFbRZ0 Message-ID: Subject: Re: [PATCH 13/22] i8259.c: introduce TYPE_I8259_PIC device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-42698a/1791979513-AA8D99EA-9770F51D/0/0 X-purgate-type: clean X-purgate-size: 2917 On Wed, 14 Oct 2026 at 12:09, Mark Cave-Ayland wrote: > > On 13/10/2026 17:17, Peter Maydell wrote: > > > On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland > > wrote: > >> +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]; > > > > This allocates only enough space for the common base class's > > instance struct, but later we do an object_initialize_child() > > of the child class. If the child class's state struct is > > ever bigger than the common class, this will break. > > That's true. In theory this should be something like I8259State, however > I didn't think it was worth adding a specific > OBJECT_DECLARE_SIMPLE_TYPE() if there were no extra fields. I did > quickly check that if this happens, then the assert() in > object_initialize() fires so if this did happen then we'd find out > really quickly. I think that every QOM class ought to define its own instance struct, even if it doesn't contain anything beyond the base class. This means that when we do need to add a field in future we don't have to go around and find the places which currently use the parent-class struct but really want the leaf-class struct. (There are places where we don't catch mistakes like this -- for instance I think if you don't update the .instance_size in a type then that doesn't get noticed: we've had a bug or too like that). We don't write that down in https://wiki.qemu.org/Documentation/QOMConventions but we do have some similar rules about class structs that boil down to "either you're a leaf class and provide none of these things, or else you should provide them all; don't have a halfway-house 'we happen to only need X and Y but not Z right now' setup". > >> 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, > > > > Devices that directly inherit from TYPE_DEVICE are awkward, > > because they never get reset. Conviently this device doesn't > > currently need a reset method, but still, is this a good idea? > > In this case I think it's correct, because the PIC device in this case > is a container for 2 cascaded i8259s which are connected separately to > the ISA bus. Therefore each i8259 will have its reset triggered via a > reset of the ISA bus. > > The container itself can't exist on the ISA bus because it would then > appear as a separate device which doesn't make sense in this case. OK. -- PMM From xen-devel-bounces@lists.xenproject.org Wed Oct 14 12:06:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 12:06:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448898.1664897 (Exim 4.92) (envelope-from ) id 1xGxkT-0002Mn-8t; Wed, 14 Oct 2026 12:06:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448898.1664897; Wed, 14 Oct 2026 12:06: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 1xGxkT-0002Mc-4v; Wed, 14 Oct 2026 12:06:21 +0000 Received: by outflank-mailman (input) for mailman id 1448898; Wed, 14 Oct 2026 12:06:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGxkR-0002MU-Dq for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:06:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxkQ-001GyN-QX for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:06:18 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf702e-e002-0a2a0a5209dd-0a2a450cb10a-20 for ; Wed, 14 Oct 2026 14:06:18 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf7039-f479-0a2a450c0019-d15580aca582-3 for ; Wed, 14 Oct 2026 14:06:18 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8ab43af5e97so39429727b3.1 for ; Wed, 14 Oct 2026 05:06: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=linaro.org header.i="@linaro.org" 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=1791979577; cv=none; d=google.com; s=arc-20260327; b=A51KR3dAGNxtFWjtEplQqECcscBqwIS/F1L60g3SO7e/cG0dtr9HEVJ2tTqBvwLIco PVbuto4diQfk7/B04Ypc3nkrzyA2Wuet2+iwxqnvIR8IDK4Peq0+THQBNcmUobDDDu+U V8fqLeshBAUp7DG029icRIZ6Z6Qzy6l37zCBp7t2QoOJL4YV370eRXU7xROrukTOB45G 83IFHD5uL+cTJvN/FCz+pyB3xnMgR4xvKXFZLsWXkQK6gVm+VLwmWEV4Edf/GgaZj89I 2gRfvmmfF/HQ4F8bB+qVic9Oh9a/2aOLX+PfRWYcU+shtB2SYbeOlbOMyRYvAqC8eI+e vvjg== 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=d/3zqLfYuRm+7YCJo4+EtPoysMl01w41Nwru3cxg2z0=; fh=t5G37c3p/fbcuVy1NaMr51YxgmP3jVoaitBm7NEdzUI=; b=hC24GbuH92sQlfFV89BS1zopI/9iFRuCOCZHO2huiz890SNyROKjem2qv2OsuKv0Uz rj94GZ8Ze9rGmK9Kl/VuhLSb36xnims+vAqbwmpaepqUkzKF4r7hXd/SRxN59hvUBoPM be+31AxrAwSnfdUQaTYt726xARJyh+F7lFH/z+kpNlPAbVANr9uymtLSG/XzKuzg1q6e bygxNrdhznnL8UPIrqH9h4bxXy7HU0WEQbgqYA4o3dgChhKRC3ladRFssqR+nUfC/FLl a9vNMUPH4lPIqsB35DWE/h6UO3lSzH5pRHdBFCluW2Sred3LsIDNHNsRq2iPaJFDdEFg MaKA==; 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=1791979577; x=1792584377; 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=d/3zqLfYuRm+7YCJo4+EtPoysMl01w41Nwru3cxg2z0=; b=iaoN+PKjd6kyF02tImBCYSTgFbXcvblQ/WUrO9/vcz4g0JVybxvUGMkLjTWIAQ/NU1 HNJsqJL3GAE8r2FqFIBR19j7Gkth7peaybYUwbrysJkZgbFMVv5CxvpUIF39urW796FB jRnXuwi+U+hRj/1OWwFnWbtzX6WNN02Y00Pfq/5j8ao9MqXisSZtiJpZY08zp/+pX0kp y5YY2pRi9bGwIKhq34jV27mB2CIGcL/tEEbnkeWW4kDZWfp7jmRpSV0tEYgoDJcr97yK oz8HbO7CRBlGGDQGzQDsB6n8VB8xpr5A6M6MUTHiYmKNtE46G8b5+zIqTz0L8HpeusKj VN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791979577; x=1792584377; 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=d/3zqLfYuRm+7YCJo4+EtPoysMl01w41Nwru3cxg2z0=; b=tnxjmGJ5lVS5eCTTnGrg30D/8XQdf7Ar/rDPfI57GRcb5zbR3wDzTC2ybLI/C5rjiy axUADvUTwszmCmB1BRbD3zgAW3+/uIF5XWJn4Mzar2hgagsOeVd/NrIeOdQgjsbO4hj0 Qo519qIHuGalz3/6dlvFX8sUnCFuqYezA3etyEx3U3hgBfJ+gxYPAn7pyHygJwr6Tedj vR3POTzJ3ff9UUhqrF977L+mPQDrcuZr5hvGK0LWIBGQIgABwyr22CNfOaiZsFh1Cq3q xkfWlavA8ekvggPXrhzeYMlUphqUXqhdhW2fjUyRmyq1wQiqNpDhPY6ghJ1wNn9QKJQL dGAg== X-Forwarded-Encrypted: i=1; AKwUvByPpJVdxwtWNEI49oB12jUWQGHuF/p+gPGcl50N0Q97efq/JQ70skTJUjmjKRdP00HjUzvUd+p0FlA=@lists.xenproject.org X-Gm-Message-State: AFq9FYI/b6wNXMJi7ODcon2cRdsFSXZfxqmQyIFEXPlADFBwIxBRKjMD InVgxw26ziLB8FAIDlVTf4Lk17mBdtjnsbbu2tn5VLmbXhGwTkQX9CNYkjP2ydH7ZQV43hdzvSn I950XNNRRuESWEhHRyJYbJb62IulRIKa82COtmkluEwrpaFt4MNJmD2Q= X-Gm-Gg: AYBFou0WhmK4BhVKE2jUO72ukuKWw65YuzIrqCL2ltF4zSlXTMTURyYkiwOuLRdt0cL p6isiQHPLT18AKbzZXaKJNn5AOTMx5LLl7ct1lBwtLlOyFDSiE9XXjXxZP4M2n2NClvYIasK0cv Rvb+ZZx9Mte/VW/McuJhXsrpd8Bd76zfMVZR0/VKPRhjeiIId507Sw7CxgxnOco6zgWqJy5yUv1 Eq3C4G5xe4jpRyiij34qdvpNrj3Yf1utwhG3eW5r5eHGyhTBJdq2+MdoPnvGMKqGXahHZQ9SGxY kJXnBvYpQr+Y+61jv/WMjro5af5mZg6565lYF6wyndUZNdABemyA/iwrOHeOOuayPvuyZnknjSA mFnS8KS3fdiUT0VEEEUfjHHxHxA3BO7b1xz+F8W4= X-Received: by 2002:a05:690c:47c4:b0:8a7:ef2a:ff9c with SMTP id 00721157ae682-8b07ebfde3amr43167667b3.2.1791979577149; Wed, 14 Oct 2026 05:06:17 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-15-mark.caveayland@nutanix.com> <0148737f-834a-4e7a-8e7f-7fff2ffaa90b@nutanix.com> In-Reply-To: <0148737f-834a-4e7a-8e7f-7fff2ffaa90b@nutanix.com> From: Peter Maydell Date: Wed, 14 Oct 2026 13:06:05 +0100 X-Gm-Features: AclHuK8r8W29TXukvU3-Y7mDsa8VmOnEakDfcbLqZ_5sU32lHwrsaLd93jsyRyA Message-ID: Subject: Re: [PATCH 14/22] i8259.c: properly cascade secondary i8259 from primary i8259 To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1791979578-5270FA5B-111B9C03/0/0 X-purgate-type: clean X-purgate-size: 1799 On Wed, 14 Oct 2026 at 12:20, Mark Cave-Ayland wrote: > > On 13/10/2026 17:18, Peter Maydell wrote: > > > On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland > > wrote: > >> > >> 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)); > > > > We just added this line in the previous patch, so we might as well > > squash this change into the previous one I think. > The reason for having this in a separate commit is because it is > technically a behaviour change. Before this commit, an interrupt from > the secondary PIC would *always* raise the passed interrupt, whereas on > real hardware it is possible to disable interrupts from the secondary > PIC by masking the relevant input on the primary PIC [1]. OK, if it's a behaviour change that's fine. The commit message is written as if it's just a refactoring, though -- it would be helpful to spell out what the behaviour change there and that it's fixing a corner case bug. -- PMM From xen-devel-bounces@lists.xenproject.org Wed Oct 14 12:07:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 12:07:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448906.1664905 (Exim 4.92) (envelope-from ) id 1xGxlt-00031t-LF; Wed, 14 Oct 2026 12:07:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448906.1664905; Wed, 14 Oct 2026 12:07: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 1xGxlt-00031k-I3; Wed, 14 Oct 2026 12:07:49 +0000 Received: by outflank-mailman (input) for mailman id 1448906; Wed, 14 Oct 2026 12:07:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGxlr-00031a-Bn for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:07:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxlq-005Mz8-Oa for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:07:46 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7092-8faa-0a2a0a5109dd-0a2a4505e408-0 for ; Wed, 14 Oct 2026 14:07:46 +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 6acf7092-4cb1-0a2a45050019-b9ff1c22842d-3 for ; Wed, 14 Oct 2026 14:07: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 1a13a4fb0c00008425.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 12:07:43 +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 7FEED81B9A; Wed, 14 Oct 2026 14:07: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=Y8Z4go3Y5vNQSGZeTsul5O5rVoL34cRs0k0o0epOjyA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=YgFoNzclRrbzFuhaf4LLHgG580YJkbXqqwFc6wI1PdkG0xTczip5cp2LWljhJUokAwEC+nbxM A0WCpIucMBRwHVFoTHWONmnnQS8ZM/YIIdQ6w/zzBcrUOweW3k5zoO95PmcS1/VRg3Cfu1if02z AgTCgpoSTNlRbJ4+Mh/EJO4pvdLtNdYQktfz6zYHt+ehVd9UhTFk+RQ4+rFzeDZ5FXOmKHk8N2v z28D3xJJoz6uBAtsvN4ehvTPK5N8vT/3Jg9KWOdmxA6MB2PVoQ6elcq6w8FeQHBztcsZP8I69wW 0/bkb4vdbGVSL6CU6eJjreRHsh6q2M75rAMpOKToNt1w== X-Zone-Loop: df6ad2b7510c7e8090fdfa5db827d2f548c7164ef422 x-campaign-type: default x-transaction-id: 2d77eea0-aff6-40a3-bcf9-6282b33aa976 x-swg-uid: 01-9434b632-45da-4d0b-b026-b4c568c3828b X-Mailer: Sweego Message-ID: <1791979663.8631fc262581453bbf619ec5b2062170.1a13a4fb0c00008425@vates.tech> x-swg-bid: 1791979663.8631fc262581453bbf619ec5b2062170.1a13a4fb0c00008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 14 Oct 2026 14:07:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/emulator: Add Linear Address Space Separation (LASS) support To: Abdelkareem Abdelsaamad , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org References: <3e42ad91a038fe21b09f2bb7b6b8a47e1c8d6718.1791973459.git.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: <3e42ad91a038fe21b09f2bb7b6b8a47e1c8d6718.1791973459.git.abdelkareem.abdelsaamad@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------shPc4mcuG1hVQ467m1rlFl2t" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791979662654 X-purgate-ID: tlsNG-c201ff/1791979666-F68B62A1-29D0F88C/0/0 X-purgate-type: clean X-purgate-size: 16104 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------shPc4mcuG1hVQ467m1rlFl2t Content-Type: multipart/mixed; boundary="------------LslxXoHdkVmcfJKUojxZN60L"; protected-headers="v1"; hp="clear" Message-ID: <7a1e3b79-9cb1-40ba-81e4-29aacfeb4ddf@vates.tech> Date: Wed, 14 Oct 2026 14:07:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/emulator: Add Linear Address Space Separation (LASS) support To: Abdelkareem Abdelsaamad , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org References: <3e42ad91a038fe21b09f2bb7b6b8a47e1c8d6718.1791973459.git.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: <3e42ad91a038fe21b09f2bb7b6b8a47e1c8d6718.1791973459.git.abdelkareem.abdelsaamad@citrix.com> --------------LslxXoHdkVmcfJKUojxZN60L Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTQvMTAvMjAyNiDDoCAxMzowOSwgQWJkZWxrYXJlZW0gQWJkZWxzYWFtYWQgYSDDqWNy aXTCoDoNCj4gTGluZWFyIEFkZHJlc3MgU3BhY2UgU2VwYXJhdGlvbiAoTEFTUykgaXMgYW4g YXJjaGl0ZWN0dXJhbCBzZWN1cml0eSBmZWF0dXJlDQo+IHRoYXQgaXMgaW50ZW5kZWQgdG8g cHJldmVudCBjcm9zcyB1c2Vyc3BhY2Uva2VybmVsc3BhY2UgbWVtb3J5IGJvdW5kYXJ5IGFj Y2Vzcw0KPiB3aXRoIHRoZSBDUFUgaGFyZHdhcmUgc3VwcG9ydC4gVW5saWtlIHRoZSByZWxh dGVkIG1vZGUtYmFzZWQgcGFnaW5nIHByb3RlY3Rpb25zDQo+IHN1Y2ggYXMgdGhlIFN1cGVy dmlzb3IgTW9kZSBBY2Nlc3MgUHJldmVudGlvbiAoU01BUCkgYW5kIHRoZSBTdXBlcnZpc29y IE1vZGUNCj4gRXhlY3V0aW9uIFByZXZlbnRpb24gKFNNRVApLCBMQVNTIHByb3ZpZGVzIHRo ZSBlZmZpY2llbnQgbWVjaGFuaXNtIHRvIGd1YXJkDQo+IGFnYWluc3QgdGhlIGNyb3NzIG1l bW9yeSBib3VuZGFyeSBhY2Nlc3NlcyB3aXRob3V0IHRyYXZlcnNpbmcgdGhlIHBhZ2luZw0K PiBzdHJ1Y3R1cmVzLiBUaGlzIHByb3ZpZGVzIGEgbW9yZSBlZmZpY2llbnQgZ3VhcmRpbmcg bWVjaGFuaXNtIGFnYWluc3QgdGhlIGNsYXNzDQo+IG9mIG1hbGljaW91cyBzb2Z0d2FyZSBh dHRhY2tzIHRoYXQgcmVsaWVzIG9uIHBhZ2luZy1iYXNlZCB0aW1pbmcgaW5mb3JtYXRpb24s DQo+IHNlZSAoMSkgZm9yIG1vcmUgaW5mb3JtYXRpb24uIEVubGlnaHRlbiB0aGUgeDg2IGlu c3RydWN0aW9uIGVtdWxhdG9yIHRvIGNvbXBseQ0KPiB3aXRoIHRoZSBoYXJkd2FyZSBJbnRl bCdzIENQVSBzdXBwb3J0IGZvciB0aGUgTEFTUy4NCj4gDQo+IFRoZSBMQVNTIHZpb2xhdGlv biBjaGVjayBsb2dpYyBpcyBhZGFwdGVkIGZyb20gdGhlIHJldmlld2VkIGxvZ2ljIGluIHRo ZSBMaW51eA0KPiBLVk0gbWFpbGluZyBsaXN0ICgyKSBmb3IgdGhlIExBU1MgdmlvbGF0aW9u IGNoZWNrcy4NCj4gDQo+IFsxXSBodHRwczovL2NkcmR2Mi1wdWJsaWMuaW50ZWwuY29tLzc3 NDk5MC9hcmNoaXRlY3R1cmUtaW5zdHJ1Y3Rpb24tc2V0LWV4dGVuc2lvbnMtcHJvZ3JhbW1p bmctcmVmZXJlbmNlLnBkZg0KPiBbMl0gaHR0cHM6Ly9sd24ubmV0L21sL2xpbnV4LWtlcm5l bC8yMDIzMDkxMzEyNDIyNy4xMjU3NC0xNi1iaW5iaW4ud3VAbGludXguaW50ZWwuY29tLw0K PiAtLS0NCj4gVGVzdGluZzoNCj4gICAtIFdpdGggQSB2aXJ0dWFsIG1hY2hpbmUgc2V0dXAg d2l0aCBpbnN0YWxsaW5nIHRoZSBmZWRvcmEgcmF3aGlkZS9mNDUgZGV2ZWxvcG1lbnQNCj4g ICAgIGJyYW5jaCB3aGljaCBpcyBiYXNlZCBvbiB0aGUgTGludXgga2VybmVsIDcuMSwgSSB2 ZXJpZmllZCB0aGUgZm9sbG93aW5nIHRlc3QgY2FzZXMNCj4gICAgIDEtIFVzaW5nIHRoZSBY ZW4gU2VydmVyLCBJIGVuYWJsZWQgdGhlIGxhc3MgY3B1IGZldGF1cmUuIFJ1bm5pbmcgdGhl IGNvbW1hbmQNCj4gICAgICAgIGdyZXAgJ2xhc3MnIC9wcm9jL2NwdWluZm8NCj4gICAgICAg IGlzIHN1Y2Nlc3NmdWxseSByZXBvcnRpbmcgYW5kIHZlcmlmeWluZyBsYXNzIGlzIHN1cHBv cnRlZCBieSB0aGUgZ3Vlc3Qga2VybmVsLg0KPiANCj4gICAgIDItIE9uIHRoZSBzZXR1cCBn dWVzdCwgSSB3cm90ZSB0aGUgZm9sbG93aW5nIGNvZGUgdG8gdmVyaWZ5IHRoZSBrZXJuZWxz cGFjZSBsaW5lYXINCj4gICAgICAgIGFkZHJlc3MgYWNjZXNzIGZyb20gdXNlcnNwYWNlIGlz IHByZXZlbnRlZCB3aXRoICNHUC4gRGlzYWJsaW5nIGxhc3MgZnJvbSB0aGUgZ3Vlc3QNCj4g ICAgICAgIGFuZCBjb21tZW50aW5nIHRoZSBGRVAgaXMgcmF0aGVyIHJlcG9ydGluZyAjUEYu DQo+IA0KPiAgICAgICAgaW50IG1haW4odm9pZCl7DQo+ICAgICAgICAgICAgY2hhciB1c3Jz cGFjZV9idWZbMTZdID0gezB9Ow0KPiAgICAgICAgICAgIGNoYXIqIHVzcnNwYWNlID0gdXNy c3BhY2VfYnVmOw0KPiAgICAgICAgICAgIGNoYXIqIGtlcm5zcGFjZSA9IChjaGFyKikgMHhm ZmZmODAwMDAwMDAwMDAwOw0KPiANCj4gICAgICAgICAgICBhc20gdm9sYXRpbGUgKA0KPiAg ICAgICAgICAgICAgICAiLmJ5dGUgMHgwZiwgMHgwYiwgMHg3OCwgMHg2NSwgMHg2ZVxuXHQi DQo+ICAgICAgICAgICAgICAgICJyZXAgbW92c2IiDQo+ICAgICAgICAgICAgICAgIDogIitT IiAodXNyc3BhY2UpLCAiK0QiIChrZXJuc3BhY2UpDQo+ICAgICAgICAgICAgICAgIDogImMi ICgxNikNCj4gICAgICAgICAgICAgICAgOiAibWVtb3J5Ig0KPiAgICAgICAgICAgICk7DQo+ IA0KPiAgICAgICAgICAgIHJldHVybiAwOw0KPiAgICAgICAgfQ0KPiANCj4gDQo+ICAgICAz LSBPbiB0aGUgc2V0dXAgZ3Vlc3QsIEkgd3JvdGUgdGhlIGZvbGxvd2luZyBrZXJuZWwgbW9k dWxlIHRvIHZlcmlmeSB0aGUgdXNlcnNwYWNlIGxpbmVhcg0KPiAgICAgICAgYWRkcmVzcyBh Y2Nlc3MgZnJvbSB0aGUga2VybmVsc3BhY2UgaXMgcHJldmVudGVkIHdpdGggI0dQLiBEaXNh YmxpbmcgbGFzcyBmcm9tIHRoZSBndWVzdA0KPiAgICAgICAgaXMgcmF0aGVyIHJlcHJ0aW5n ICNQRi4gRXhlY3V0aW5nIHRoZSBjb2RlIHdpdGggY29tbWVudHRlZCBGb3JjZWQgRW11bGF0 aW9uIFByZWZpeA0KPiAgICAgICAgKEZFUCkgYW5kIHRoZSBsYXNzIGZlYXR1cmUgZW5hYmxl ZCBpcyByZXBvcnRpbmcgI0dQLg0KPiANCj4gICAgICAgICNpbmNsdWRlIDxsaW51eC9tb2R1 bGUuaD4NCj4gICAgICAgICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQo+IA0KPiAgICAgICAg TU9EVUxFX0xJQ0VOU0UoIkdQTCIpOw0KPiAgICAgICAgTU9EVUxFX0RFU0NSSVBUSU9OKCJU ZXN0aW5nIE1vZHVsZSBmb3IgSW50ZWwncyBMQVNTIFhlbiBUcmFwIik7DQo+IA0KPiAgICAg ICAgc3RhdGljIGludCBfX2luaXQgbXlfbW9kdWxlX2luaXQodm9pZCl7DQo+ICAgICAgICAg ICAgY2hhciogdXNyc3BhY2UgPSAoY2hhciopIDB4MDAwMDdmZmZmZmZmZmQwMDsNCj4gICAg ICAgICAgICBjaGFyKiBrZXJuc3BhY2UgPSBremFsbG9jKDE2LCBHRlBfS0VSTkVMKTsNCj4g DQo+ICAgICAgICAgICAgaWYgKCFrZXJuc3BhY2UpIHsNCj4gICAgICAgICAgICAgICAgcHJf ZXJyKCJNZW1vcnkgYWxsb2NhdGlvbiBmYWlsZWRcbiIpOw0KPiAgICAgICAgICAgICAgICBy ZXR1cm4gLUVOT01FTTsNCj4gICAgICAgICAgICB9DQo+IA0KPiAgICAgICAgICAgIGFzbSB2 b2xhdGlsZSAoDQo+ICAgICAgICAgICAgIi5ieXRlIDB4MGYsIDB4MGIsIDB4NzgsIDB4NjUs IDB4NmVcblx0Ig0KPiAgICAgICAgICAgICJyZXAgbW92c2IiDQo+ICAgICAgICAgICAgOiAi K1MiICh1c3JzcGFjZSksICIrRCIgKGtlcm5zcGFjZSkNCj4gICAgICAgICAgICA6ICJjIiAo MTYpDQo+ICAgICAgICAgICAgOiAibWVtb3J5Ig0KPiAgICAgICAgICAgICk7DQo+IA0KPiAg ICAgICAgICAgIHJldHVybiAwOw0KPiAgICAgICAgfQ0KPiANCj4gICAgICAgIHN0YXRpYyB2 b2lkIF9fZXhpdCBteV9tb2R1bGVfZXhpdCh2b2lkKXsNCj4gICAgICAgICAgICBwcl9pbmZv KCJteSBtb2R1bGUgIik7DQo+ICAgICAgICB9DQo+IA0KPiAgICAgICAgbW9kdWxlX2luaXQo bXlfbW9kdWxlX2luaXQpOw0KPiAgICAgICAgbW9kdWxlX2V4aXQobXlfbW9kdWxlX2V4aXQp Ow0KPiANCj4gICAgIDQtIE9uIHRoZSBzZXR1cCBndWVzdCwgSSB3cm90ZSB0aGUgZm9sbG93 aW5nIGNvZGUgdG8gdmVyaWZ5IHRoZSBpbXBsaWNpdCBzeXN0ZW0gKHNwZXJ2aXNvcikNCj4g ICAgICAgIGFkZHJlc3MgYWNjZXNzIGZyb20gdXNlcnNwYWNlIGlzIG5vdCBwcmV2ZW50ZWQg d2l0aCAjR1AuDQo+IA0KPiAgICAgICAgI2luY2x1ZGUgPHN0ZGlvLmg+DQo+IA0KPiAgICAg ICAgI2RlZmluZSBYRU5fRkVQICIuYnl0ZSAweDBmLCAweDBiLCAweDc4LCAweDY1LCAweDZl XG5cdCINCj4gDQo+ICAgICAgICBpbnQgbWFpbigpIHsNCj4gICAgICAgICAgICBhc20gdm9s YXRpbGUgKFhFTl9GRVAgIm1vdiAlW3NlbF0sICUlZnMiIDo6IFtzZWxdICJyIiAoMTUqOCsz KSk7DQo+ICAgICAgICAgICAgcmV0dXJuIDA7DQo+ICAgICAgICB9DQo+IA0KPiAgICAgIDUt IENJIHRlc3RzOg0KPiBodHRwczovL2dpdGxhYi5jb20veGVuLXByb2plY3QvcGVvcGxlL2Fh YmRlbHNhL3hlbi8tL3BpcGVsaW5lcy8yOTQ2NDMwNTAzDQo+IC0tLQ0KPiAgIHhlbi9hcmNo L3g4Ni9odm0vaHZtLmMgfCA3MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0t LS0tLS0tLS0NCj4gICAxIGZpbGUgY2hhbmdlZCwgNTYgaW5zZXJ0aW9ucygrKSwgMTcgZGVs ZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS9odm0uYyBi L3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMNCj4gaW5kZXggZWY5YzdjZDA1Ny4uMzQ3N2Q2MmQ0 MyAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS9odm0uYw0KPiArKysgYi94ZW4v YXJjaC94ODYvaHZtL2h2bS5jDQo+IEBAIC0yNTU3LDYgKzI1NTcsNDAgQEAgaW50IGh2bV9z ZXRfY3I0KHVuc2lnbmVkIGxvbmcgdmFsdWUsIGJvb2wgbWF5X2RlZmVyKQ0KPiAgICAgICBy ZXR1cm4gWDg2RU1VTF9PS0FZOw0KPiAgIH0NCj4gICANCj4gK3N0YXRpYyBib29sIGlzX2xh c3NfdmlvbGF0aW9uKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBsb25nIGFkZHIsDQo+ICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHNpemUsDQo+ICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnVtIGh2bV9hY2Nlc3NfdHlwZSBhY2Nl c3NfdHlwZSwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvb2wgaXNfaW1w bGljaXRfc3VwZXJ2aXNvcl9hY2Nlc3MpDQo+ICt7DQo+ICsgICAgY29uc3QgYm9vbCBpc19z dXBlcnZpc29yX2FkZHJlc3MgPSAhIShhZGRyICYgKDFVTEwgPDwgNjMpKTsNCj4gKw0KDQpX aGF0IGhhcHBlbnMgaWYgYWRkciBpcyBub3QgaW4gTEFTUyByYW5nZSwgYnV0IGFkZHIuLmFk ZHIrc2l6ZSBjcm9zc2VzIA0KaXQgKGZvciBpbnN0YW5jZSwgaWYgYWRkciBpcyAweDdGRkZG RkZGRkZGRkZGRkYgYW5kIHNpemUgaXMgMTYpID8NCg0KV2Ugd291bGQgaGF2ZSBpc19zdXBl cnZpc29yX2FkZHJlc3MgPT0gZmFsc2UsIGFzIHdlIG9ubHkgY2hlY2tlZCB0aGUgDQpzdGFy dGluZyBhZGRyZXNzLCBidXQgdGhlcmUgaXMgYSBwYXJ0IG9mIHRoZSBhY2Nlc3Mgd2l0aGlu IHRoZSBMQVNTIA0KcmFuZ2UgKHdpdGggYml0IDYzKS4NCg0KPiArICAgIGlmICggISh2LT5h cmNoLmh2bS5ndWVzdF9jcls0XSAmIFg4Nl9DUjRfTEFTUykgfHwgIWh2bV9sb25nX21vZGVf YWN0aXZlKHYpICkNCj4gKyAgICAgICAgcmV0dXJuIGZhbHNlOw0KPiArDQo+ICsgICAgaWYg KCAhaXNfaW1wbGljaXRfc3VwZXJ2aXNvcl9hY2Nlc3MgJiYgaHZtX2dldF9jcGwodikgPT0g MyApDQo+ICsgICAgICAgIHJldHVybiBpc19zdXBlcnZpc29yX2FkZHJlc3M7DQo+ICsNCj4g KyAgICAvKg0KPiArICAgICAqIEluIHRoZSBzdWJzZXF1ZW50IGxvZ2ljLCB3ZSBhcmUgZW11 bGF0aW5nIGEgdmVyaWZpZWQgc3VwZXJ2aXNvcg0KPiArICAgICAqIGFjY2VzcyBMQVNTIGNo ZWNrLg0KPiArICAgICAqLw0KPiArDQo+ICsgICAgaWYgKCBhY2Nlc3NfdHlwZSAhPSBodm1f YWNjZXNzX2luc25fZmV0Y2ggKQ0KPiArICAgIHsNCj4gKyAgICAgICAgaWYgKCAhKHYtPmFy Y2guaHZtLmd1ZXN0X2NyWzRdICYgWDg2X0NSNF9TTUFQKSApDQo+ICsgICAgICAgICAgICBy ZXR1cm4gZmFsc2U7DQo+ICsNCj4gKyAgICAgICAgaWYgKCAhaXNfaW1wbGljaXRfc3VwZXJ2 aXNvcl9hY2Nlc3MgJiYNCj4gKyAgICAgICAgICAgICBndWVzdF9jcHVfdXNlcl9yZWdzKCkt PmVmbGFncyAmIFg4Nl9FRkxBR1NfQUMgKQ0KPiArICAgICAgICAgICAgcmV0dXJuIGZhbHNl Ow0KPiArICAgIH0NCj4gKw0KPiArICAgIGlmICggc2l6ZSAmJiAhKChhZGRyICsgc2l6ZSAt IDEpICYgKDFVTEwgPDwgNjMpKSApDQo+ICsgICAgICAgIHJldHVybiB0cnVlOw0KPiArDQo+ ICsgICAgcmV0dXJuICFpc19zdXBlcnZpc29yX2FkZHJlc3M7DQo+ICt9DQoNCkknbSBub3Qg c3VyZSB0byBmb2xsb3cgdGhlIGVudGlyZSBsb2dpYw0KDQpBSVVJLCBMQVNTIHZpb2xhdGlv bnMgaGFwcGVucyB3aGVuIDoNCi0gdXNlci1tb2RlIDogQW55IGFjY2VzcyB0byBMQVNTIHJh bmdlIChiaXQgNjMgPSAxKQ0KLSBzdXBlcnZpc29yLW1vZGUgYWNjZXNzIDoNCiAgIC0gQW55 IGFjY2VzcyB0byBub24tTEFTUyByYW5nZSAoYml0IDYzID0gMCkgaWYgU01BUCAmJiAoQUM9 MCB8fCANCiJpbXBsaWNpdCBzdXBlcnZpc29yLW1vZGUgYWNjZXNzIikNCiAgIC0gQW55IGlu c3RydWN0aW9uIGZldGNoIHRvIG5vbi1MQVNTIHJhbmdlIChiaXQgNjMgPSAwKQ0KDQo+ICsN Cj4gICBib29sIGh2bV92Y3B1X3ZpcnR1YWxfdG9fbGluZWFyKA0KPiAgICAgICBzdHJ1Y3Qg dmNwdSAqdiwNCj4gICAgICAgZW51bSB4ODZfc2VnbWVudCBzZWcsDQo+IEBAIC0yNjAyLDI2 ICsyNjM2LDMxIEBAIGJvb2wgaHZtX3ZjcHVfdmlydHVhbF90b19saW5lYXIoDQo+ICAgICAg ICAgICBpZiAoIG1heChvZmZzZXQsIGxhc3RfYnl0ZSkgPj4gMTYgKQ0KPiAgICAgICAgICAg ICAgIGdvdG8gb3V0Ow0KPiAgICAgICB9DQo+IC0gICAgZWxzZSBpZiAoIGh2bV9sb25nX21v ZGVfYWN0aXZlKHYpICYmDQo+IC0gICAgICAgICAgICAgIChpc194ODZfc3lzdGVtX3NlZ21l bnQoc2VnKSB8fCBhY3RpdmVfY3MtPmwpICkNCj4gKyAgICBlbHNlIGlmICggaHZtX2xvbmdf bW9kZV9hY3RpdmUodikgKQ0KPiAgICAgICB7DQo+IC0gICAgICAgIC8qDQo+IC0gICAgICAg ICAqIFVzZXIgc2VnbWVudHMgYXJlIGFsd2F5cyB0cmVhdGVkIGFzIHByZXNlbnQuICBTeXN0 ZW0gc2VnbWVudCBtYXkNCj4gLSAgICAgICAgICogbm90IGJlLCBhbmQgYWxzbyBpbmN1ciBs aW1pdCBjaGVja3MuDQo+IC0gICAgICAgICAqLw0KPiAtICAgICAgICBpZiAoIGlzX3g4Nl9z eXN0ZW1fc2VnbWVudChzZWcpICYmDQo+IC0gICAgICAgICAgICAgKCFyZWctPnAgfHwgKG9m ZnNldCArIGJ5dGVzIC0gISFieXRlcykgPiByZWctPmxpbWl0KSApDQo+IC0gICAgICAgICAg ICBnb3RvIG91dDsNCj4gKyAgICAgICAgaWYgKCAoaXNfeDg2X3N5c3RlbV9zZWdtZW50KHNl ZykgfHwgYWN0aXZlX2NzLT5sKSApDQo+ICsgICAgICAgIHsNCj4gKyAgICAgICAgICAgIC8q DQo+ICsgICAgICAgICAgICAgKiBVc2VyIHNlZ21lbnRzIGFyZSBhbHdheXMgdHJlYXRlZCBh cyBwcmVzZW50LiAgU3lzdGVtIHNlZ21lbnQgbWF5DQo+ICsgICAgICAgICAgICAgKiBub3Qg YmUsIGFuZCBhbHNvIGluY3VyIGxpbWl0IGNoZWNrcy4NCj4gKyAgICAgICAgICAgICAqLw0K PiArICAgICAgICAgICAgIGlmICggaXNfeDg2X3N5c3RlbV9zZWdtZW50KHNlZykgJiYNCj4g KyAgICAgICAgICAgICAgICAgICghcmVnLT5wIHx8IChvZmZzZXQgKyBieXRlcyAtICEhYnl0 ZXMpID4gcmVnLT5saW1pdCkgKQ0KPiArICAgICAgICAgICAgICAgICBnb3RvIG91dDsNCj4g ICANCj4gLSAgICAgICAgLyoNCj4gLSAgICAgICAgICogTE9ORyBNT0RFOiBGUywgR1MgYW5k IHN5c3RlbSBzZWdtZW50czogYWRkIHNlZ21lbnQgYmFzZS4gQWxsDQo+IC0gICAgICAgICAq IGFkZHJlc3NlcyBtdXN0IGJlIGNhbm9uaWNhbC4NCj4gLSAgICAgICAgICovDQo+IC0gICAg ICAgIGlmICggc2VnID49IHg4Nl9zZWdfZnMgKQ0KPiAtICAgICAgICAgICAgYWRkciArPSBy ZWctPmJhc2U7DQo+ICsgICAgICAgICAgICAvKg0KPiArICAgICAgICAgICAgICogTE9ORyBN T0RFOiBGUywgR1MgYW5kIHN5c3RlbSBzZWdtZW50czogYWRkIHNlZ21lbnQgYmFzZS4gQWxs DQo+ICsgICAgICAgICAgICAgKiBhZGRyZXNzZXMgbXVzdCBiZSBjYW5vbmljYWwuDQo+ICsg ICAgICAgICAgICAgKi8NCj4gKyAgICAgICAgICAgIGlmICggc2VnID49IHg4Nl9zZWdfZnMg KQ0KPiArICAgICAgICAgICAgICAgIGFkZHIgKz0gcmVnLT5iYXNlOw0KPiArDQo+ICsgICAg ICAgICAgICBsYXN0X2J5dGUgPSBhZGRyICsgYnl0ZXMgLSAhIWJ5dGVzOw0KPiArICAgICAg ICAgICAgaWYgKCAhaXNfY2Fub25pY2FsX2FkZHJlc3MoKGxvbmcpYWRkciA8IDAgPyBhZGRy IDogbGFzdF9ieXRlKSApDQo+ICsgICAgICAgICAgICAgICAgZ290byBvdXQ7DQo+ICsgICAg ICAgIH0NCj4gICANCj4gLSAgICAgICAgbGFzdF9ieXRlID0gYWRkciArIGJ5dGVzIC0gISFi eXRlczsNCj4gLSAgICAgICAgaWYgKCAhaXNfY2Fub25pY2FsX2FkZHJlc3MoKGxvbmcpYWRk ciA8IDAgPyBhZGRyIDogbGFzdF9ieXRlKSApDQo+ICsgICAgICAgIGlmICggaXNfbGFzc192 aW9sYXRpb24odiwgYWRkciwgYnl0ZXMsIGFjY2Vzc190eXBlLCBpc194ODZfc3lzdGVtX3Nl Z21lbnQoc2VnKSkgKQ0KPiAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiAgICAgICB9DQo+ ICAgICAgIGVsc2UNCg0KVGVkZHkNCg== --------------LslxXoHdkVmcfJKUojxZN60L-- --------------shPc4mcuG1hVQ467m1rlFl2t 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+p0QLLz9AFAmrPcI0FAwAAAAAACgkQZg+p0QLLz9CS Pgv/aT6vcr7voGDmYe5DrkhdXZi9/eKZYfgd7vA/Tthr1ZMbntsVyYO4/auAmza1SH7jZlD33tfg PkLaaK/BGThEDG9hrTfo4nsQbujgrySpvNYy2RdQS8PYAdW9PpX4jbDV6aBDUMtpHqgy4rRWQ+NQ C3J6n9PqILF3BN4hhnbhzm2V4cp3fuyPVkZ+pzozcmBqfP5bCfjNT6KYqhZa/PVwI7ls0yEXQimW 0AtAm9EtIC4Ivo5dlhJWhtZe8P87pZzbSkAqgLXNR3ZSc+3U1WMqBEABCgheXBnd43RQv5VnrMSD ZKQcHx+Hj4Y6EPpNuMZO8kteL7eIvpEPHLylMrVDgBdFHsV0RlPP69CuUvTkusypMDAd8R9gCC0c 1QRxxFA6OJCwWGBg64kqcU6pAVVLSCZVlyUwY1gN6YqeI9tKCScmrkPL9v8rt3XzCu0LAehmCIhE BBC1USBi/aykeqmA4ratXwx9Osyly5vHz1aEtqPnJcnBPZJOgpy1xslOCWUU =Umxr -----END PGP SIGNATURE----- --------------shPc4mcuG1hVQ467m1rlFl2t-- From xen-devel-bounces@lists.xenproject.org Wed Oct 14 12:31:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 12:31:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448935.1664915 (Exim 4.92) (envelope-from ) id 1xGy8R-0000cA-CB; Wed, 14 Oct 2026 12:31:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448935.1664915; Wed, 14 Oct 2026 12: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 1xGy8R-0000c3-85; Wed, 14 Oct 2026 12:31:07 +0000 Received: by outflank-mailman (input) for mailman id 1448935; Wed, 14 Oct 2026 12:31:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGy8P-0000bx-FI for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:31:05 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xGy8P-000000052VO-1OVv for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:31:05 +0000 Received: from mail-lj1-f171.google.com ([209.85.208.171]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xGy8O-00000004lvl-2XPP for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:31:05 +0000 Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-3a1eb6fa0f4so42032221fa.2 for ; Wed, 14 Oct 2026 05:31: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" 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=1XoQ0iJcWS81MGA7D94FjGmXdVcFN4bgOM97NImPNq4=; b=gSAEHQKQ3SQV6o+2rKkvAdgL/Y X4PuhsWsCSEaIuN07pNqhIr0smqh1RqATKhe1tHobISXbe7OoVZ/dUKGooh70rDBs3sW/F4MCwTYl cj+DQ12FO/+WjSLs0VtoQ+Yt1Q4QTxYesff5au37qmTkrOjPpFjf0BgUWwVuVPT+ZZgs=; X-Gm-Message-State: AFq9FYJhTTWnmDRKTeH6zscLRUYr/+76UfDgn5KGMhCPFhUnRvl2/WhB 5JeSPobfINmNvvnRmhDeJvAqFIReN98+issA3fGkXT4afS0tBiDE9nKRaMIqbMVhCCjfPEz4VM1 5hKOl/fwIHUVfeQuV/fIiwXqs2MhVCjc= X-Received: by 2002:a05:651c:198f:b0:3a7:812b:d1c with SMTP id 38308e7fff4ca-3a9c4844a20mr36797111fa.0.1791981063805; Wed, 14 Oct 2026 05:31:03 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-15-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Wed, 14 Oct 2026 13:30:51 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9thxVo-ndJBU-izWzLPQObYaEocYNCCH4qOVkts_0e5UsZPX1F1bbgaE8 Message-ID: Subject: Re: [PATCH v3 14/18] x86/domain_page: key the directmap fast paths on the loaded view To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 7:51=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:47AM +0100, George Dunlap wrote: > > map_domain_page() returns directmap addresses whenever it can: for any > > MFN the directmap covers in release builds, and for vCPUs without a > > mapcache. Once guest contexts may run on the sparse view of the > > directmap, modify this to take the fast path returning the directmap > > address only when the full directmap is loaded. > > > > The release-build shortcut ahead of the vCPU lookup looks at the vCPU > > whose page-tables are loaded, without completing a lazy context > > switch: if that vCPU is not on the sparse view, its page-tables map > > the page through the directmap, and completing the switch would only > > move the CPU to the idle vCPU's page-tables, which map it too. > > > > mapcache_current_vcpu() may complete the lazy context switch > > (sync_local_execstate()) and switch us onto the idle vCPU (which has a > > full view), so check again if we can use the directmap afterwards. > > > > A vCPU on the sparse view always has a mapcache: HVM ones through > > per-vCPU page-tables, PV ones through the domain-wide mapcache, which > > mapcache_domain_init() now sets up for a domain using the sparse view i= n > > release builds too, rather than only when the directmap does not cover > > all memory. > > > > map_domain_page_global() mappings must be valid in every context: use > > vmap() for all of them once a sparse view is configured, as > > arch_mfns_in_directmap() then says. > > > > Add d->arch.sparse_dmap and sparse_dmap_active for this; nothing sets > > them yet. > > > > No functional change. > > > > Assisted-by: Claude Code:claude-opus-5-5 > > Signed-off-by: George Dunlap > > --- > > Changes in v3: > > - New in this version. > > --- > > xen/arch/x86/domain_page.c | 44 +++++++++++++++++++-- > > xen/arch/x86/include/asm/domain.h | 6 +++ > > xen/arch/x86/include/asm/sparse-directmap.h | 8 ++++ > > xen/arch/x86/sparse-directmap.c | 1 + > > 4 files changed, 56 insertions(+), 3 deletions(-) > > > > diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c > > index 0500bb9dba..48f85b670d 100644 > > --- a/xen/arch/x86/domain_page.c > > +++ b/xen/arch/x86/domain_page.c > > @@ -61,6 +61,16 @@ static inline struct vcpu *mapcache_current_vcpu(voi= d) > > return ACCESS_ONCE(this_cpu(pgtable_vcpu)); > > } > > > > +/* > > + * Whether the directmap in @v's page-tables is the sparse view, which= maps > > + * none of the heap's memory beyond the xenheap: the mapcache must ser= ve > > + * every mapping then. > > + */ > > +static bool on_sparse_dmap(const struct vcpu *v) > > +{ > > + return sparse_dmap_active && v->domain->arch.sparse_dmap; > > +} > > + > > /* > > * The accounting for v's mapcache: its own for a vCPU-PT domain, the = domain's > > * otherwise, in which case *dcache is set so the caller takes the dom= ain-wide > > @@ -142,17 +152,39 @@ void *map_domain_page(mfn_t mfn) > > > > #ifdef NDEBUG > > if ( mfn_x(mfn) <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > > - return mfn_to_virt(mfn_x(mfn)); > > + { > > + const struct vcpu *pt_vcpu =3D this_cpu(pgtable_vcpu); > > + > > + /* > > + * The page-tables loaded map @mfn through the directmap, unle= ss they > > + * carry the sparse view. Don't complete a lazy context switc= h to > > + * find out: it would only move this CPU to the idle vCPU's > > + * page-tables, which map @mfn too. > > + */ > > + if ( !pt_vcpu || !on_sparse_dmap(pt_vcpu) ) > > + return mfn_to_virt(mfn_x(mfn)); > > + } > > #endif > > > > + /* No vCPU (early boot), or no mapcache: the full directmap is loa= ded. */ > > v =3D mapcache_current_vcpu(); > > if ( !v ) > > return mfn_to_virt(mfn_x(mfn)); > > > > +#ifdef NDEBUG > > + /* The lookup may have completed a lazy switch off the sparse view= . */ > > + if ( !on_sparse_dmap(v) && > > + mfn_x(mfn) <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > > + return mfn_to_virt(mfn_x(mfn)); > > +#endif > > + > > cache =3D vcpu_mapcache(v, &dcache); > > vcache =3D &v->arch.mapcache; > > if ( !cache->inuse ) > > + { > > + ASSERT(!on_sparse_dmap(v)); > > return mfn_to_virt(mfn_x(mfn)); > > + } > > > > perfc_incr(map_domain_page_count); > > > > @@ -307,7 +339,9 @@ void mapcache_domain_init(struct domain *d) > > ASSERT(is_pv_domain(d)); > > > > #ifdef NDEBUG > > - if ( !mem_hotplug && max_page <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_E= ND - 1)) ) > > + /* Not needed when the directmap loaded for the domain covers ever= ything. */ > > + if ( !d->arch.sparse_dmap && !mem_hotplug && > > + max_page <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > > return; > > #endif > > > > @@ -392,8 +426,12 @@ void *map_domain_page_global(mfn_t mfn) > > system_state < SYS_STATE_active) || > > local_irq_is_enabled())); > > > > + /* > > + * Global mappings must hold in every context: a sparse view of th= e > > + * directmap rules the directmap out. > > + */ > > #ifdef NDEBUG > > - if ( mfn_x(mfn) <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > > + if ( arch_mfns_in_directmap(mfn_x(mfn), 1) ) > > return mfn_to_virt(mfn_x(mfn)); > > #endif > > > > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/a= sm/domain.h > > index 80415ab2c2..76a22b4040 100644 > > --- a/xen/arch/x86/include/asm/domain.h > > +++ b/xen/arch/x86/include/asm/domain.h > > @@ -499,6 +499,12 @@ struct arch_domain > > */ > > bool vcpu_pt; > > > > + /* > > + * Root page-tables carry the sparse view of the directmap, once i= t is > > + * active (see asm/sparse-directmap.h). > > + */ > > + bool sparse_dmap; > > What do you mean with "once it is active"? Either a domain is using > the sparse direct map or not, but it shouldn't have an external > dependency on anything. Or maybe I'm reading the comment the wrong > way. I've reworded it. > > +/* > > + * Set once guest contexts run on the sparse view: from then on, the r= oot > > + * page-tables of domains with d->arch.sparse_dmap carry it. > > + */ > > +extern bool sparse_dmap_active; > > Shouldn't sparse_dmap_active be opt_sparse_dmap_pv || > opt_sparse_dmap_hvm? I'm afraid I don't understand the point of > tracking whether there are domain using the sparse direct map or not, > that's already tracked by d->arch.sparse_dmap? Yeah, sparse_dmap_active was originally meant to be used to shortcut certain things when no domains were using the sparse directmap; but it hasn't turned out to be needed. I'll remove it. -George From xen-devel-bounces@lists.xenproject.org Wed Oct 14 12:53:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 12:53:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448977.1664924 (Exim 4.92) (envelope-from ) id 1xGyTS-0004aw-53; Wed, 14 Oct 2026 12:52:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448977.1664924; Wed, 14 Oct 2026 12: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 1xGyTS-0004al-0E; Wed, 14 Oct 2026 12:52:50 +0000 Received: by outflank-mailman (input) for mailman id 1448977; Wed, 14 Oct 2026 12:52:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGyTR-0004ae-41 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:52:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGyTQ-005Wdy-Gs for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:52:48 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7b1a-bab6-0a2a0a5309dd-0a2a4506d40a-10 for ; Wed, 14 Oct 2026 14:52:48 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf7b20-195a-0a2a45060019-d1558032dc77-3 for ; Wed, 14 Oct 2026 14:52:48 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a16aaf2067so12017585e9.0 for ; Wed, 14 Oct 2026 05:52: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-4a1bca808casm1553075e9.0.2026.10.14.05.52.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 05:52: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: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=1791982368; x=1792587168; 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=q/+VDWZQRxNSZfvFQaF0HGohNlNj8Digp/UjXxEXHXk=; b=DGcLsapiedF8BNI2hQ3xxVIfa7yXndSEHfs2nk5suNcKLyYfpHF1+YRWcXMKlwaSRI 6zCqKznysjZYbDrXKBlWbNGymVnK9g5HTlxpbccjrSn7VD547Pn56BYGPo/y96Ajnso7 1n2YF9Ix7ItZbrbihKXpb3Kh8l2t9C7lBXHbDSGtzWeDniTLtmemwJHndH8PGfZFphMW KqXZ2gFsI7HWR/O9mxpFpS1WZq+wmZm+DhZFM5T0uPlnb1riQwyLnS8NUlhaeMHDMdpL 0Vg98r21BXwssWkje19xKRvYO3q1GZb+uKf/EsfQGvb4Er9X/yhqQilAyNNPBEQIXFoL A7Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791982368; x=1792587168; 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=q/+VDWZQRxNSZfvFQaF0HGohNlNj8Digp/UjXxEXHXk=; b=cOVTaxuxSNLgCLBNXc+yKTeWmg3uWZkCrOEW1WTvTlSUgfMWkh1gANIfvMfABBLi9i ShaDxm3xmNnryz1yYFFDad4iRWy1ospYNgj2x9hRV1lqeGQbocdCiab051Dz56itDzHx wL2MM11G1ecVc/epcpxR7/jmEUTyzrlqhdSiEFI6jUAzi0qAtPNkAAt69jO8Xq++xhjo GO/F9sQMhPH8FrA0BYeImJ9IIydY45w+O6Q7aU3And6lr1xk7cpg6vCBBKFR/Uvq7wiI jp5jZtMqKyYOnozplxziXWGeQsZWabKQ04lwHjJnbLJeMuNKogFnL6sL+gLirD5LEVzL NI4g== X-Gm-Message-State: AFq9FYICdB7e43uIM1FeOZ+XEBaZbJy5HS88tlrXjipmCVrucw6kT7cz 6Xngqkvjv1AMP97pT05Upg5eYk4Dk2nmChlp/KM6RDFF3Vttek+awopilfSsikOamTTihBZkdaW 8c9VqwA== X-Gm-Gg: AYBFou1VdGOZ0zFYqoQJsHW6a48+zpxhOWcUBTbaQCkYn1LL6PNrMYca+/I/NXXj7Ie A0kUHMufL5K2dynYhT2IkPXNFtMLzAScqeAHsZrtxN0JjjjDLGmYnKjnRn4bGs8QeO0wC61WjSG z7A+helnU9A6bD+XPMW9D58kf5aVLR6C41yzO40YAdIDpv06g+iKU5UJXvnYQF3i3CNAutsgLmy vL6CINoridNl072zv30+/S5dOQ1B7ivq5GNiOF7XRHP8tqKdniS3lXHCep1GDOoPO3EimvLHsCp LPQTvIprwJtadvwoqijWkBA+mVmN3b79r55JbfkKRE9Ad7BDDtOGZltYiP15+2SS6RwT5XfjmEJ JBBE7oY0JQ5BTdX+wwbebAlNxWdMfgWvxp/fd3Ylox3ndgNlxQDfef+VpNJCuQZLNrwBPovJZd+ Q/3CyO9ngDkc0ohH8geQ4fAAi4LRbj7UbpH/nImkJYVmT7cv02RugaCnrf+iclugbEqQlw0qf9q d62R8Ppc8kUlNAUg/F6eE8AmNiaGjCnD9LuIHT9GbU5e+s4LXjXk0ItiDH3rWg= X-Received: by 2002:a05:600c:5391:b0:4a1:ac66:6ac8 with SMTP id 5b1f17b1804b1-4a1ac6671c7mr105488805e9.4.1791982367862; Wed, 14 Oct 2026 05:52:47 -0700 (PDT) Message-ID: <6d0acc68-9d07-4e0a-b27b-0095a51ebe42@suse.com> Date: Wed, 14 Oct 2026 14:52:45 +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] gnttab: drop bogus check from _cache_flush() Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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-16d1c6/1791982368-FE47377B-C5D80245/10/78276251493 X-purgate-type: spam X-purgate-size: 829 There's no such thing as an alive domain without ->grant_table, and system domains (on Arm) don't own any pages. The check should also not be left there "just in case", because if that check could legitimately yield "false", the page reference obtained would then need dropping on the subsequent error path (see XSA-520). Reported-by: Andrew Cooper Reported-by: Yehyeong Lee Signed-off-by: Jan Beulich --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -3637,7 +3637,7 @@ static int _cache_flush(gnttab_cache_flu page = mfn_to_page(mfn); owner = page_get_owner_and_reference(page); - if ( !owner || !owner->grant_table ) + if ( !owner ) { rcu_unlock_domain(d); return -EPERM; From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:00:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:00:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448987.1664933 (Exim 4.92) (envelope-from ) id 1xGyae-0006OB-Ql; Wed, 14 Oct 2026 13:00:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448987.1664933; Wed, 14 Oct 2026 13:00: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 1xGyae-0006O4-MG; Wed, 14 Oct 2026 13:00:16 +0000 Received: by outflank-mailman (input) for mailman id 1448987; Wed, 14 Oct 2026 13:00:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGyad-0006Ny-Lv for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:00:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGyac-004cL5-Qi for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:00:14 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7cd8-e002-0a2a0a5209dd-0a2a4503c174-44 for ; Wed, 14 Oct 2026 15:00:14 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf7cde-fae8-0a2a45030019-d155dd2cb08d-3 for ; Wed, 14 Oct 2026 15:00:14 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48af4d4e61fso2973083f8f.2 for ; Wed, 14 Oct 2026 06:00: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-48de0ac3ac5sm11855649f8f.38.2026.10.14.06.00.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 06:00: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: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=1791982814; x=1792587614; 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=ra+LfdeOwZGJ6DbxZw1ElalXSdP9PzZryiC4RNwC3rg=; b=AnvH5b3tyyZfBiTmALIuksXQmKWKZ3EgQiwSOuftt+vMN8sEkvpYY3+XDdHa7GEJf3 AFYVdu2FH5pzEkoLEK+92UOvSRtcBPTURUMyzb6bqHikyYNFkLuFScCbbHPmKeHrdO8E m2v4HNIBDH5MM+nspswTCpFwYXm9QXa7HvUM2/sgbFiPLUqhc4Hz/Qs18/nPpnhp2jd+ RZbrBrvuF4u2XBvbV4ZHCfuuuClIOMnKC9MSczjP2mzS1Vny/27k4Z74IS8alYhOOdgX lUdBpaD8m5vrzQrWmN2jEa8nwWK9DkHI+fr3/Z+jBUwz2Ia7tjWkKGty470967uGmLUf 4wTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791982814; x=1792587614; 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=ra+LfdeOwZGJ6DbxZw1ElalXSdP9PzZryiC4RNwC3rg=; b=wew1fTmsRjMGcnQnln1GFf7TdnvMrwNsLLW7SlJozzBNpInEMddU21En7gKjMqPKmE 1bipFnqejDfX7UVwRvBBUcPI5la7k184wzereoNcyfqeNcCsTNo76jNOOVeljirbAJqs wLQZ5WPBiZ7CVKvNjGIN3ngDI6hNr9sZ0DcqLorx4QeWDfU7mITd+sj5wxKdFj0M2rVu t/ruG+7vIaK9gA2mF/X4/+REYwYhPnt+qYa8T7lYKVHLAPonz5PxQPShgVu5RHybfIxV 2EMzcyNEu7hARr/jCRAU7i9H8qrlGa4zFfbS/goOHzmsoK9aTIo8rsObi2zLriN/sHBx A3oA== X-Gm-Message-State: AFq9FYLlWKUQFXKTCwY/1ZUj6kTxFyGctYxsEjDmap8QgXjSaDqD3PYj I4m+8f2vyuHd/GBgGWjHOeYqZsn+yvZoaFp93Bks872er3K8bZarK1/W1VTIkT+EkfyFxcb+G3S m65jLLQ== X-Gm-Gg: AYBFou1pdD1kF6wrsdlIMOmDIaEFiu34S/p4lHgI+VvbQ2IQarJKz1GD0rMnpgbUgkn WeQ0ysqs91h3B2jTrSuaNo1liCba4a0AbbBPVud/7MlEUu9JJFC1p13xmCwEv0pzL/XmDhPpKvQ QnVZ4bzUm9eF2yvlg+LIAXVmM6UQKfQkcq5CB8/jeYjT/kVgSf75L9C7ZDpm9oLLaB5YQHNlFVW No2cCZW/E/VxHw7nnNDWy6gUCUHkWXG/yYDvjOCj4kOEQfiWFfsoS2K6cw0dZaEheW7Hps+RYcB zonunK6he93sfzWfLXMIFYUicA6bl4+0r834CAnSRJL6MECh9lOhQwKSFv7mVX36VL8NRULm3Ox uprKnww0tK6X7PxOiqJrnEkVb9lkzZc/44vpiZZg7gFza1jEuWCcZd6+jLGFoRc9724+/c/W39V ZPtAuKst7c5cxUUzC9OYEFjh/G/HzC0qvA3Gi2IrNkbqRrbH3ueeR/MZAY5jeZ4LqyzqjzslY8c A8JBOCAp4oTjWdUR9yXkN4DlCaxp/8BAVLFUkLIbwGyNxPfz2qK2kdhlxoW0w== X-Received: by 2002:a05:6000:469c:b0:48d:b75d:30f6 with SMTP id ffacd0b85a97d-48dbad1226cmr19685163f8f.35.1791982814064; Wed, 14 Oct 2026 06:00:14 -0700 (PDT) Message-ID: <8ad3beb3-af5a-477b-af97-614edb22631a@suse.com> Date: Wed, 14 Oct 2026 15:00:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v3 0/3] "brk" allocator 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-33051d/1791982814-6DAD44E9-09C5052E/10/78276251493 X-purgate-type: spam X-purgate-size: 578 Derive for our purposes something similar to what Linux has been having for a long while. v3 is mainly for moving the logic to common code, so other arch-es can make use of it right from the start (if so desired). 1: common: introduce "brk" allocator 2: x86/EFI: replace ebmalloc() 3: xhci-dbc: use brk_alloc() On x86, to reduce padding holes, .bss.page_aligned and per-CPU data may want moving immediately ahead of __brk_start[]. Albeit then the tail of per-CPU data will all be padding space; sadly the TSS wants/needs page-aligning for XPTI purposes. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:01:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:01:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448990.1664940 (Exim 4.92) (envelope-from ) id 1xGybp-0006sK-2Q; Wed, 14 Oct 2026 13:01:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448990.1664940; Wed, 14 Oct 2026 13:01: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 1xGybo-0006sB-V0; Wed, 14 Oct 2026 13:01:28 +0000 Received: by outflank-mailman (input) for mailman id 1448990; Wed, 14 Oct 2026 13:01:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGybn-0006s3-Og for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:01:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGybm-00BSwC-Ud for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:01:26 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7d1d-e002-0a2a0a5209dd-0a2a4501804c-48 for ; Wed, 14 Oct 2026 15:01:26 +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 6acf7d26-5984-0a2a45010019-d155802ce9ec-3 for ; Wed, 14 Oct 2026 15:01:26 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49ff680331aso10989195e9.3 for ; Wed, 14 Oct 2026 06: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 ffacd0b85a97d-48de0aaa5dbsm12376317f8f.12.2026.10.14.06.01.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 06:01: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: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=1791982886; x=1792587686; 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=Ad8BiGbd56/98Ou5diYjrztGQdgtHVrz8EjnYsYECAc=; b=OXXriEbW1Pg1AHQXbpo6Wh1zF2b9o1Fn3ivVFn4LM+ldyf55Et20HIJBFcAUS0PUpZ fy2qsqd1OjYpuTMR6qmvI3sLnrYEq9uqsLN33/YU+j8dMZBwy42Y2hTmmluxWCPkwkom KXcWfqgcwG5aIv71YHVThzCvo+MC6kl2GW/vjW9dEeXHQJY7tywoiablQKISYvOkhhhz 1py5bQNoUuXx0xaL2ZZ/oWY3vHoyTzuYq7RJRiQF31fYIKOnc0YLX+/cmDWQ77nmOxF8 98w6abjXVM5A4feRPeGtZxqIloN7fIm6/N4bcQG+5dWU2o79tkZLNP6tjVqsXTFdd11h MfUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791982886; x=1792587686; 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=Ad8BiGbd56/98Ou5diYjrztGQdgtHVrz8EjnYsYECAc=; b=r5Z1efruKEOdeR5lG/t7MvWyC7bEJx0tLeq9D54Di9lyqv2kwqSsRWT7RboYHzJ2hb /+P2G3IFkp9x18qB+MZT1dsrCCPvAks0bdBQ8dxN3kN5DJ/a8zQ8C9IW1kXbarEJzEMI XbcJVBLmmWoxV4Ax/jWaGjYaIYbKKPR3Lde6uG+OTURian5vBgZmofBL8P3Hg6yZaIH+ 2ACV+o49htW83IBk0/KpYItpOP1w2+Yd6GhGgF5us6fLZeiDlPTKxJpRdR6ZSE8eohLO XtboyzR0YvilcM33HTAYYEaXK6iIAt1j5RO55gxuqCE2RiBqK2yYQF8OjFhRMeN1fa3h EAow== X-Gm-Message-State: AFq9FYKjuOsXM1RGb2ugdmbqEqAsl94KzPNmxAY0d25vTbRCdRv9YM71 F+IENXN4gkOEaMg1CadRmq2kqF5qkaeGf3YIRYVB5LucbZM+mXt/QiuEFGBfx/nu+gDBcL+nWZm bxVQl5A== X-Gm-Gg: AYBFou3L54Kw67BsWtheRm0sC8XBUWyM3wGtORtsuRGIzTIgsj8JS1H8AZARfDN4u/v RnP3yfNzd/c2IqC4cLtfw0GbuvOICXAYQPOYpAmhHlG5Kio1wbt4hg0wG/1LX8qazo7ISuUGjt6 sMTZQdaCTednJeiUHqRRxkS6RNNWaifmfyB92LYTMZdgDKgQHiPy+DbrZpYoxcd74yx9uANmqcw J4ET2JioeIScZVRrlHBwE1OQXQtnH6LxVyP4Olq4STz9wQKlUEceFai0tLS/1I8f6oTGTgOvG0Y BQqN6bgyJajHcYI7lS4521hqtW/3HdBSL/utvON5bTxcpTWePQValRHz2EDPqc9hg5nd4sSiscq eQTSDUWOfZT1IOq1XOZ42nXWaDVayKhvs9Ju6QrJ6Pf9vDi450ieR++Yo1kwblLd75Q21MSkoJX KkBOKr4LjIu2kA/x1i7NjHjKp2HhK6/YwU+BlNVGSIzjoF+WtsIc96M+fjTnfU4PyXH+ISKupZd rC6dPOqTS7FwCs4qOl0CYhQl/Ehg16pV4poSY5u7lOFStZp33jx3xWvaQxwruo= X-Received: by 2002:a05:600d:17:b0:4a1:9663:7639 with SMTP id 5b1f17b1804b1-4a196637a39mr221905375e9.34.1791982885740; Wed, 14 Oct 2026 06:01:25 -0700 (PDT) Message-ID: <4fc90702-fb9a-4f96-88f0-35bd3b4857f4@suse.com> Date: Wed, 14 Oct 2026 15:01:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 1/3] common: introduce "brk" allocator 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: <8ad3beb3-af5a-477b-af97-614edb22631a@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: <8ad3beb3-af5a-477b-af97-614edb22631a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1791982886-BF063757-E4A22E33/10/78276251493 X-purgate-type: spam X-purgate-size: 8016 ... to replace (on x86) ebmalloc(), and then to find further use(s) to allow recovering memory which is needed very early (and hence needs setting up statically), but may not fully be used (or not be used at all). Note that unlike free_ebmalloc_unused_mem(), brk_free_unused() (once other code is converted) will be able to free part of the BRK space even in the xen.efi case on x86. That would happen if BRK space extends across a 2Mb boundary, and actual use stops before that boundary. Signed-off-by: Jan Beulich --- Changing setup.c's reserve_e820_ram() uses would be cumbersome when done right here. That'll be done when ebmalloc() is replaced, and hence what's there can also simply be replaced. When linking xen.efi, GNU ld prior to 2.46 produces a base relocation for the reference to __subsystem__, which is wrong (that's an absolute symbol, after all). That does no harm for our purposes, though. --- v3: Move to common code and introduce BSS_WITH_BRK. Rename brk_get_unused_start() to brk_cease(). Add header guard to brk.h. In brk_alloc() don't calculate result too early. Add printk_once_init(), for use in brk_alloc(). Move introduction of DEFINE_BRK() here; add comment. --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -15,6 +15,7 @@ config X86 select FUNCTION_ALIGNMENT_16B select GENERIC_BUG_FRAME select HAS_ALTERNATIVE + select HAS_BRK_ALLOCATOR select HAS_COMPAT select HAS_CPUFREQ select HAS_DIT --- /dev/null +++ b/xen/arch/x86/include/asm/brk.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +#ifndef X86_BRK_H +#define X86_BRK_H + +static inline unsigned long brk_adjust_start(unsigned long start) +{ + unsigned int subsys; + + /* + * Only xen.efi will have the symbol __subsystem__ available, and it'll + * be non-zero (10) there. In ELF the symbol will be undefined, and + * hence zero will be loaded into the register. + */ + asm ( ".weak __subsystem__; mov $__subsystem__, %0" : "=r" (subsys) ); + + /* using_2M_mapping() isn't available here. */ + if ( IS_ENABLED(CONFIG_XEN_ALIGN_2M) || subsys ) + start = PAGE_ALIGN_2M(start); + + return start; +} + +#endif /* X86_BRK_H */ --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -87,6 +87,7 @@ * doing the final put_page(), and remove it from the iommu if so. */ +#include #include #include #include @@ -337,6 +338,8 @@ void __init arch_init_memory(void) efi_init_memory(); + brk_free_unused(); + #ifndef NDEBUG if ( highmem_start ) { --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -309,12 +309,7 @@ SECTIONS LLVM_COV_RW_DATA DECL_SECTION(.bss) { - __bss_start = .; - *(.bss.page_aligned*) - PERCPU_BSS - *(.bss .bss.*) - . = ALIGN(POINTER_ALIGN); - __bss_end = .; + BSS_WITH_BRK } PHDR(text) _end = . ; --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -118,6 +118,9 @@ config GENERIC_BUG_FRAME config HAS_ALTERNATIVE bool +config HAS_BRK_ALLOCATOR + bool + config HAS_COMPAT bool --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -1,6 +1,7 @@ obj-$(CONFIG_ARGO) += argo.o obj-y += bitmap.o obj-bin-$(CONFIG_SELF_TESTS) += bitops.init.o +obj-bin-$(CONFIG_HAS_BRK_ALLOCATOR) += brk.init.o obj-$(CONFIG_GENERIC_BUG_FRAME) += bug.o obj-$(CONFIG_HYPFS_CONFIG) += config_data.o obj-$(CONFIG_CORE_PARKING) += core_parking.o --- /dev/null +++ b/xen/common/brk.c @@ -0,0 +1,74 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include +#include +#include + +#if __has_include() +# include +#endif + +extern char __brk_start[]; +extern const char __bss_end[]; + +static unsigned long __initdata allocated; +static bool __initdata finished; + +void *__init brk_alloc(size_t size) +{ + void *ptr; + + if ( finished ) + return NULL; + + /* Allocations PAGE_SIZE and up will be page-aligned. */ + if ( size >= PAGE_SIZE ) + allocated = ROUNDUP(allocated, PAGE_SIZE); + + ptr = __brk_start + allocated; + + allocated += ROUNDUP(size, sizeof(void *)); + + if ( allocated > __bss_end - __brk_start ) + { + printk_once_init( + "%pS: over-sized BRK request: %zu bytes\n", + __builtin_extract_return_addr(__builtin_return_address(0)), + size); + return NULL; + } + + return ptr; +} + +unsigned long __init brk_cease(void) +{ + finished = true; + + allocated = ROUNDUP(allocated, PAGE_SIZE); + + return (unsigned long)__brk_start + allocated; +} + +void __init brk_free_unused(void) +{ + unsigned long start = brk_cease(), end = (unsigned long)__bss_end; + +#if __has_include() + start = brk_adjust_start(start); +#endif + + if ( start >= end ) + return; + + destroy_xen_mappings(start, PAGE_ALIGN_2M(end)); + + /* + * By reserving needed space early (on x86: in the E820 map), excess space + * gets freed way before we make it here. Don't free the range a 2nd time. + */ + + printk(XENLOG_INFO "Freed %lukB unused BRK memory\n", (end - start) >> 10); +} --- /dev/null +++ b/xen/include/xen/brk.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Early Boot memory allocator. + * + * Subsystems which conditionally need memory prior to the boot allocator + * (or the main heap) being set up may use DEFINE_BRK() to reserve BSS space + * in Xen. + * + * During boot, brk_alloc() allocates memory from the reserved space. Such + * allocations are good for the lifetime of Xen. Subsystems MUST NOT + * brk_alloc() more memory than they reserved. + * + * When the main heap is set up, brk allocations become unavailable. Reserved + * but unallocated space is, as far as possible, handed to the main heap, so it + * doesn't go to waste. + */ + +#ifndef XEN_BRK_H +#define XEN_BRK_H + +#include + +#define DEFINE_BRK(var, size) \ + static char __section(".bss..brk.page_aligned") __aligned(PAGE_SIZE) \ + __used var ## _brk_[size] + +void *brk_alloc(size_t size); +unsigned long brk_cease(void); +void brk_free_unused(void); + +#endif /* XEN_BRK_H */ --- a/xen/include/xen/lib.h +++ b/xen/include/xen/lib.h @@ -79,6 +79,16 @@ void vprintk(const char *fmt, va_list ar } \ }) +#define printk_once_init(fmt, args...) \ +({ \ + static bool __initdata once_; \ + if ( unlikely(!once_) ) \ + { \ + once_ = true; \ + printk(fmt, ## args); \ + } \ +}) + extern void guest_printk(const struct domain *d, const char *fmt, ...) __attribute__ ((format (printf, 2, 3))); extern void noreturn panic(const char *fmt, ...) --- a/xen/include/xen/xen.lds.h +++ b/xen/include/xen/xen.lds.h @@ -221,6 +221,18 @@ . = ALIGN(SMP_CACHE_BYTES); \ __per_cpu_data_end = .; \ +#define BSS_WITH_BRK \ + __bss_start = .; \ + *(.bss.page_aligned*) \ + PERCPU_BSS \ + *(.bss .bss.[a-zA-Z0-9_]*) \ + . = ALIGN(PAGE_SIZE); \ + __brk_start = .; \ + *(.bss..brk.page_aligned*) \ + *(.bss..brk*) \ + . = ALIGN(POINTER_ALIGN); \ + __bss_end = .; + #ifdef CONFIG_HAS_VPCI #define VPCI_ARRAY \ . = ALIGN(POINTER_ALIGN); \ From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:02:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:02:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448994.1664950 (Exim 4.92) (envelope-from ) id 1xGych-0007K6-FE; Wed, 14 Oct 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 1448994.1664950; Wed, 14 Oct 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 1xGych-0007Jz-CU; Wed, 14 Oct 2026 13:02:23 +0000 Received: by outflank-mailman (input) for mailman id 1448994; Wed, 14 Oct 2026 13:02:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGycf-0007Jl-Vy for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:02:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGycf-00CF8l-Ch for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:02:21 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7d56-2eae-0a2a0a5409dd-0a2a4506b48e-24 for ; Wed, 14 Oct 2026 15:02:21 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf7d5d-195a-0a2a45060019-d155dd35dce0-3 for ; Wed, 14 Oct 2026 15:02:21 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48c5358fc28so375890f8f.0 for ; Wed, 14 Oct 2026 06:02: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-48de0bc506asm12256603f8f.47.2026.10.14.06.02.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 06:02: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=1791982941; x=1792587741; 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=FEcDM12NwGn05VrFecyuXD7d11qyEb4DovUBu5I+7Oc=; b=Fu5u6XbSZPaQ91xW9brl8jvOVH4D3Fb/bs9H75S5sMrllTEVFlb/4iD+EtoR9ldwKl TflzftS0Md//clnVCav/Vo5B0qiqwj26sz1kMxm13+ME51t8Z8ilnq6HaQuCG4J9zCqx 0dKC3nWNQ2CI4vHiOV6o71bF3ktUyeg0A4T4Zbsc1ImO27eCYzLoq7MzYUG8w5817M0q scMeqra1idTO8ynRnb0ovMFWkRqskqfgSRWRwvdWCJIqBm2L127TGGtfaCYlYTGFulif 34Wb39et8lTGuAB3RBHhiMPBxgDOmpWDsVdSGoPoMNCtXE/xfyLHh7syLzH+ba9lx4kZ eYlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791982941; x=1792587741; 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=FEcDM12NwGn05VrFecyuXD7d11qyEb4DovUBu5I+7Oc=; b=vGkZ0b74L+gPO6GLHCDqJ9OuYd7qFrTUQ+dkponul9UROxyVJhp6+gnGRjaEP/nv4k 1iZT9tdOz5khFibMnF6BNePkckMiJO8QIIOpO+6NtF1OpU1IKTGTtkXNJdPDlmkMakFZ 0Pz9sgABcxpagNmcm2Wo7+SSmcKSJMWZXT8jlLbfQ18hMRe/wy7mWxXJJwIK5O21uMxw jHSMvtULlVDR9yMX69Ny5ShpHVCfPHbviQ7zVOLXJJtyXVlAVHXVvZw7JXt/9veW5jCk MtmM2Rq3RqZ+voIVFSjUdUd3iTRiQqopvZX5DluSpdUy1LGmfdHTgrt/ZY+Z2IvvCoN4 q0jQ== X-Gm-Message-State: AFq9FYIm8TrS28i6j7ZHL/6rbHGAvCoBf71kyrGYcJ2+Kq+OKfYPuDd/ TKnFS7kQzDromL7pQ5SKvvgV/mkMyh8lDCaV/DVJ3qrhBJ1OO97M9qBHn7xmvVSJVrEJZertZjG aDhcSzg== X-Gm-Gg: AYBFou1zEV4HnFpd/bQcuOSMOPpir1TD70tYxPQdocVvLVw/axGrDcAsWsYfqsDfJWW E8QlxDX3A4EOII8tphQcplI64JM+4qkhrOovQ0S4u82qBMOTdRgp6bzXeD1eHlj9jl+cYWarFtd 4qYSnoYEYY3Lezwhnm3Wzmr2nYPIpZqCeVmHMrHvzSYSXK6KMw6NCRBPrUd1Ug/f4lTnbIzEGzA ODvW6PdBx1NqB49OGF6Xs3zCtDg4cN08Lde7In5Htsv26dgUIjUMnapZ0f7X2RaRdBtBzHmeddJ WeaKhS8SDo4edAB6CwDJIc2WfMHBTOzSZXM7QHiFgBPaisK/ZyqMU5sfJmgOLJAKPY24mZ5kLI0 zhNuR80zcVrCwcpdF3Tej2MdN6TFz4FOmcO8H2h968yZHs2fE2qs/O4kpsnHn63zr3ovFOk1C61 9qcAvVF5FVnqYVnn/lWmnCpzqop4MwkmgayOK33X55opGZQiiBujbJfENpeLhT8Ogalkg1Qwr+I mEWst+GZiw+8eoU1BiGx0wAcq6d4fyoXoo/QIugDI7FM6aX/49mG3QVUq5rpYF3 X-Received: by 2002:a5d:6f18:0:b0:48d:f14a:9174 with SMTP id ffacd0b85a97d-48df14a925amr288746f8f.13.1791982940714; Wed, 14 Oct 2026 06:02:20 -0700 (PDT) Message-ID: Date: Wed, 14 Oct 2026 15:02:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 2/3] x86/EFI: replace ebmalloc() 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 , Marek Marczykowski , Daniel Smith References: <8ad3beb3-af5a-477b-af97-614edb22631a@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: <8ad3beb3-af5a-477b-af97-614edb22631a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1791982941-FC80577B-2F385E8C/10/78276251493 X-purgate-type: spam X-purgate-size: 11144 Use the new brk_alloc() instead, with ebmalloc() merely being a thin wrapper. Signed-off-by: Jan Beulich Reviewed-by: Marek Marczykowski-Górecki --- I'm not quite certain whether we ought to permit non-page-granular reservations. The in-memory image being somewhat larger due to possibly excessive padding isn't really a big problem, I think. --- v3: Re-base, in particular over moving of brk.c to common/. v2: Re-base. --- 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|.data.rel.ro|.data.rel.ro.*) ;; \ + .*.local|.data.rel.ro|.data.rel.ro.*|.bss..brk*) ;; \ .text|.text.*|.data|.data.*|.bss|.bss.*) \ test $$(echo $$sz | sed 's,00*,0,') != 0 || continue; \ echo "Error: size of $<:$$name is 0x$$sz" >&2; \ --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -7,6 +7,7 @@ #ifndef X86_EFI_EFI_BOOT_H #define X86_EFI_EFI_BOOT_H +#include #include #include @@ -119,6 +120,18 @@ static void __init relocate_trampoline(u reloc_trampoline64(); } +DEFINE_BRK(efi, MB(1)); + +static void *__init ebmalloc(size_t size) +{ + void *ptr = brk_alloc(size); + + if ( !ptr ) + blexit(L"Out of BRK memory\r\n"); + + return ptr; +} + static void __init place_string(u32 *addr, const char *s) { char *alloc = NULL; --- a/xen/arch/x86/efi/stub.c +++ b/xen/arch/x86/efi/stub.c @@ -41,12 +41,4 @@ void __init noreturn efi_multiboot2(EFI_ void __init efi_init_memory(void) { } -bool efi_boot_mem_unused(unsigned long *start, unsigned long *end) -{ - /* FIXME: Simplify once the call here with two NULLs goes away. */ - if ( start || end ) - *start = *end = (unsigned long)_end; - return false; -} - void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) { } --- a/xen/arch/x86/include/asm/setup.h +++ b/xen/arch/x86/include/asm/setup.h @@ -9,6 +9,8 @@ extern const char __2M_rodata_start[], _ extern char __2M_init_start[], __2M_init_end[]; extern char __2M_rwdata_start[], __2M_rwdata_end[]; +extern unsigned long brk_end; + extern unsigned long xenheap_initial_phys_start; extern uint64_t boot_tsc_stamp; --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1,6 +1,7 @@ #include #include #include +#include #include #include #include @@ -164,6 +165,8 @@ cpumask_t __read_mostly cpu_present_map; unsigned long __read_mostly xen_phys_start; +unsigned long __ro_after_init brk_end; + /* Only used in asm code and within this source file */ char asmlinkage __section(".init.bss.stack_aligned") __aligned(STACK_SIZE) cpu0_stack[STACK_SIZE]; @@ -1152,7 +1155,6 @@ void asmlinkage __init noreturn __start_ struct boot_info *bi; unsigned long raw_max_page; int i, j, bytes = 0; - unsigned long eb_start, eb_end; bool acpi_boot_table_init_done = false, relocated = false; bool vm_init_done = false; int ret; @@ -1518,7 +1520,7 @@ void asmlinkage __init noreturn __start_ /* * This needs to remain in sync with remove_xen_ranges() and the * respective reserve_e820_ram() invocation below. No need to - * query efi_boot_mem_unused() here, though. + * query brk_cease() here, though. */ xen->start = virt_to_maddr(_stext); xen->size = __2M_rwdata_end - _stext; @@ -1662,20 +1664,12 @@ void asmlinkage __init noreturn __start_ if ( !xen_phys_start ) panic("Not enough memory to relocate Xen\n"); - /* FIXME: Putting a hole in .bss would shatter the large page mapping. */ - if ( using_2M_mapping() ) - efi_boot_mem_unused(NULL, NULL); - /* This needs to remain in sync with remove_xen_ranges(). */ - if ( efi_boot_mem_unused(&eb_start, &eb_end) ) - { - if ( !reserve_e820_ram(&boot_e820, __pa(_stext), __pa(eb_start)) || - !reserve_e820_ram(&boot_e820, __pa(eb_end), __pa(__2M_rwdata_end)) ) - panic("Failed to reserve Xen in E820\n"); - } - else - if ( !reserve_e820_ram(&boot_e820, __pa(_stext), __pa(__2M_rwdata_end)) ) - panic("Failed to reserve Xen in E820\n"); + brk_end = brk_cease(); + if ( using_2M_mapping() ) + brk_end = PAGE_ALIGN_2M(brk_end); + if ( !reserve_e820_ram(&boot_e820, __pa(_stext), __pa(brk_end)) ) + panic("Failed to reserve Xen in E820\n"); /* Late kexec reservation (dynamic start address). */ kexec_reserve_area(); @@ -2272,7 +2266,6 @@ __initcall(init_xen_cap_info); int __hwdom_init remove_xen_ranges(struct rangeset *r) { - paddr_t start, end; int rc; /* S3 resume code (and other real mode trampoline code) */ @@ -2294,26 +2287,10 @@ int __hwdom_init remove_xen_ranges(struc return rc; /* hypervisor .data + .bss */ - if ( efi_boot_mem_unused(&start, &end) ) - { - ASSERT(__pa(start) >= __pa(&__2M_rwdata_start)); - rc = rangeset_remove_range(r, PFN_DOWN(__pa(&__2M_rwdata_start)), - PFN_DOWN(__pa(start) - 1)); - if ( rc ) - return rc; - ASSERT(__pa(end) <= __pa(&__2M_rwdata_end)); - rc = rangeset_remove_range(r, PFN_DOWN(__pa(end)), - PFN_DOWN(__pa(&__2M_rwdata_end) - 1)); - if ( rc ) - return rc; - } - else - { - rc = rangeset_remove_range(r, PFN_DOWN(__pa(&__2M_rwdata_start)), - PFN_DOWN(__pa(&__2M_rwdata_end) - 1)); - if ( rc ) - return rc; - } + rc = rangeset_remove_range(r, PFN_DOWN(__pa(&__2M_rwdata_start)), + PFN_DOWN(__pa(brk_end) - 1)); + if ( rc ) + return rc; return 0; } --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -321,8 +321,6 @@ void tboot_shutdown(uint32_t shutdown_ty /* if this is S3 then set regions to MAC */ if ( shutdown_type == TB_SHUTDOWN_S3 ) { - unsigned long s, e; - /* * Xen regions for tboot to MAC. This needs to remain in sync with * remove_xen_ranges(). @@ -336,16 +334,8 @@ void tboot_shutdown(uint32_t shutdown_ty g_tboot_shared->mac_regions[1].size = __2M_rodata_end - _stext; /* hypervisor .data + .bss */ g_tboot_shared->mac_regions[2].start = (uint64_t)__pa(&__2M_rwdata_start); - g_tboot_shared->mac_regions[2].size = __2M_rwdata_end - __2M_rwdata_start; - if ( efi_boot_mem_unused(&s, &e) ) - { - g_tboot_shared->mac_regions[2].size = - s - (unsigned long)__2M_rwdata_start; - g_tboot_shared->mac_regions[3].start = __pa(e); - g_tboot_shared->mac_regions[3].size = - (unsigned long)__2M_rwdata_end - e; - g_tboot_shared->num_mac_regions = 4; - } + g_tboot_shared->mac_regions[2].size = + brk_end - (unsigned long)__2M_rwdata_start; /* * MAC domains and other Xen memory --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1830,8 +1830,6 @@ void __init efi_init_memory(void) pte_attr_t prot; } *extra, *extra_head = NULL; - free_ebmalloc_unused_mem(); - if ( !efi_enabled(EFI_BOOT) ) return; --- a/xen/common/efi/ebmalloc.c +++ /dev/null @@ -1,74 +0,0 @@ -#include "efi.h" -#include -#include - -#ifdef CONFIG_ARM -/* - * TODO: Enable EFI boot allocator on ARM. - * This code can be common for x86 and ARM. - * Things TODO on ARM before enabling ebmalloc: - * - estimate required EBMALLOC_SIZE value, - * - where (in which section) ebmalloc_mem[] should live; if in - * .bss.page_aligned, as it is right now, then whole BSS zeroing - * have to be disabled in xen/arch/arm/arm64/head.S; though BSS - * should be initialized somehow before use of variables living there, - * - use ebmalloc() in ARM/common EFI boot code, - * - call free_ebmalloc_unused_mem() somewhere in init code. - */ -#define EBMALLOC_SIZE MB(0) -#else -#define EBMALLOC_SIZE MB(1) -#endif - -static char __section(".bss.page_aligned") __aligned(PAGE_SIZE) - ebmalloc_mem[EBMALLOC_SIZE]; -static unsigned long __read_mostly ebmalloc_allocated; - -/* EFI boot allocator. */ -void __init *ebmalloc(size_t size) -{ - void *ptr = ebmalloc_mem + ebmalloc_allocated; - - ebmalloc_allocated += ROUNDUP(size, sizeof(void *)); - - if ( ebmalloc_allocated > sizeof(ebmalloc_mem) ) - blexit(L"Out of static memory\r\n"); - - return ptr; -} - -bool efi_boot_mem_unused(unsigned long *start, unsigned long *end) -{ - /* FIXME: Drop once the call here with two NULLs goes away. */ - if ( !start && !end ) - { - ebmalloc_allocated = sizeof(ebmalloc_mem); - return false; - } - - *start = (unsigned long)ebmalloc_mem + PAGE_ALIGN(ebmalloc_allocated); - *end = (unsigned long)ebmalloc_mem + sizeof(ebmalloc_mem); - - return *start < *end; -} - -void __init free_ebmalloc_unused_mem(void) -{ - unsigned long start, end; - - if ( !efi_boot_mem_unused(&start, &end) ) - return; - - destroy_xen_mappings(start, end); - -#ifdef CONFIG_X86 - /* - * By reserving the space early in the E820 map, it gets freed way before - * we make it here. Don't free the range a 2nd time. - */ -#else - init_xenheap_pages(__pa(start), __pa(end)); -#endif - - printk(XENLOG_INFO "Freed %lukB unused BSS memory\n", (end - start) >> 10); -} --- a/xen/common/efi/efi-common.mk +++ b/xen/common/efi/efi-common.mk @@ -1,4 +1,4 @@ -EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o +EFIOBJ-y := boot.init.o pe.init.o runtime.o EFIOBJ-$(CONFIG_COMPAT) += compat.o CFLAGS-y += -fshort-wchar --- a/xen/common/efi/efi.h +++ b/xen/common/efi/efi.h @@ -48,10 +48,6 @@ void noreturn blexit(const CHAR16 *str); const CHAR16 *wmemchr(const CHAR16 *s, CHAR16 c, UINTN n); -/* EFI boot allocator. */ -void *ebmalloc(size_t size); -void free_ebmalloc_unused_mem(void); - const void *pe_find_section(const void *image, const UINTN image_size, const CHAR16 *section_name, UINTN *size_out); --- a/xen/include/xen/efi.h +++ b/xen/include/xen/efi.h @@ -39,7 +39,6 @@ static inline bool efi_enabled(unsigned extern bool efi_secure_boot; void efi_init_memory(void); -bool efi_boot_mem_unused(unsigned long *start, unsigned long *end); unsigned long efi_get_time(void); void efi_reset_system(bool warm); #ifndef COMPAT From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:02:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:02:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448999.1664959 (Exim 4.92) (envelope-from ) id 1xGyd8-0007mR-Nx; Wed, 14 Oct 2026 13:02:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448999.1664959; Wed, 14 Oct 2026 13:02: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 1xGyd8-0007mK-Kl; Wed, 14 Oct 2026 13:02:50 +0000 Received: by outflank-mailman (input) for mailman id 1448999; Wed, 14 Oct 2026 13:02:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGyd7-0007m2-W1 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:02:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGyd7-00CFKO-8V for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:02:49 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7d77-2eae-0a2a0a5409dd-0a2a45048820-16 for ; Wed, 14 Oct 2026 15:02:49 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf7d78-b57f-0a2a45040019-d155dd2ae46e-3 for ; Wed, 14 Oct 2026 15:02:48 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48b0ef9c76eso371429f8f.0 for ; Wed, 14 Oct 2026 06:02: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-48de0ac5265sm12597064f8f.41.2026.10.14.06.02.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 06:02: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=1791982968; x=1792587768; 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=2gMm2a7QNwXZYXz1DEn6YS019avxsFmIWcQ9BJGK0Ao=; b=JgpgByf4XX2iTWgRn28KC6AtVRz2fVCJetba/xoBfLDkBc3BePfT+8VUi/Q4dzUKVp PymubaPbK95QftOBY62emHoneBK2TMYhpkRERiq7OZYKLndp8aPqElk8IVHMZIMzSTtn gO58VqCkFXDOagu7nyyK8aSaCBdaEQb5SYCQ4v+DWaghj3eS4qlPeM+ZIQJzBM5f9paz 4FqDCePBT4+iTynKD6UXvtY1802Ed0EMvocg326ZZlSnwcXluiEWrou7GTZes45ssfFS 7DjZmmMLFfPpZlt59xduuLRgLdijxKreK7tC6XRAYUioyOwitlzRPM07e8WbGcg6LAOd n5LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791982968; x=1792587768; 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=2gMm2a7QNwXZYXz1DEn6YS019avxsFmIWcQ9BJGK0Ao=; b=xJfAZb90RzcsOx0iTRC3p2Shra11c9knFIb2LjnQypkF/8kA6PDnW7K+Y9e2SGOYtO csCavz5lmNIQ/2omMyhM0+FfuzxDNyUsJGuDzrqhSv4qLcesCkHUIYhNb/f95B8bc+hT HQRBettOsIajAu49ezd939wWK22eIfExlCWYQ7Hr+o2Zt4R+3b4g0aby2t5XJ+r7nlFo ildfOjbrZtTIEPaEIwbq6BThdYxqq/vEKKhwSqHpsm3jpIkZJ2tFYs3f7N+hXycz3HzD HroDQFXPwF7ZTGWqg1vH2DRXtgL0qXFkt7ClET1vWYoRYVorFX0N1f6XRt+thxXO+OGQ IXsA== X-Gm-Message-State: AFq9FYJllsIHHTvFJ+krZYYIO+n9XK4VIQUaEsv+6QgMXOvLvGBSElAK G4hmuONdgmANgKvqa/QvJSSZX3+WYkOvCzYNl1SZyeBFGQU2U3KMLQ8Zkwmw4///aBXXp9RpJ4o RbY/eUQ== X-Gm-Gg: AYBFou3tPXBMVGFEAfvwg7Kv1FGkhO54T2lWE3SJzbAkQeyt5P9Ko7Uqr2bU62Kba1P OC0m7TUvgdI8gWfvPP+YjckJuE7YjYmQr4lK+z7N26pyWJhqG7KPbCcxYcIitcGc5pdMHZ9Vyv8 mYEQW9OUaVIFPG9/RThjw3aF3ylAg1iIzkqe/ydIdZaKKakxtjkEG1+RLhpGsXBSf1g3xvqfUnD h0DqyqWVpwqSkUnOOjSpvkDQ72XdBXhS5dkAFtzeBkwGmMLg2zihA13vLAxoGSt9ZsIF7hmiJ80 BBWEfwszNxcXcDPy4+0+Edsvm5Kn98lChPKpAZTlc2e1WjkMHPHsUVw8vphNXtFepaKHLtXTstj en/otj5ixVXERerban18SiL8VQcpO/1lzhGIdZ5H9um/aNDOLjmCvd0qsWemzleDx226cprEMiq kV/8rX1+IWknAwtorjKgOolV86awYo0rqAy2g/wwo4eVE71fH0+9bUwTK0hxEbXkV0nutrb58yC 1yztrFaepQD3VvwTUNakSAcSbX51tEtxchWFHfAcbf6Pipgnr8tg7rrIVtMcGozQy89jsxG8A== X-Received: by 2002:a05:6000:4550:b0:48a:fd58:a7dc with SMTP id ffacd0b85a97d-48dba9beee6mr22008962f8f.12.1791982968124; Wed, 14 Oct 2026 06:02:48 -0700 (PDT) Message-ID: <6e448cc8-d733-4767-b8a2-563fd6a81350@suse.com> Date: Wed, 14 Oct 2026 15:02:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 3/3] xhci-dbc: use brk_alloc() 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?= , Marek Marczykowski References: <8ad3beb3-af5a-477b-af97-614edb22631a@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: <8ad3beb3-af5a-477b-af97-614edb22631a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1791982968-50CDFB50-B42EBD28/10/78276251493 X-purgate-type: spam X-purgate-size: 2953 This way the relatively large chunk of DMA buffers can be freed when the driver isn't in use. Signed-off-by: Jan Beulich Reviewed-by: Marek Marczykowski-Górecki --- v3: Re-base over moving of brk.c to common/. --- a/xen/drivers/char/xhci-dbc.c +++ b/xen/drivers/char/xhci-dbc.c @@ -19,6 +19,7 @@ * Copyright (c) 2019 Assured Information Security. */ +#include #include #include #include @@ -27,6 +28,7 @@ #include #include #include + #include #include #include @@ -1332,7 +1334,7 @@ static struct uart_driver dbc_uart_drive }; /* Those are accessed via DMA. */ -struct dbc_dma_bufs { +struct __aligned(PAGE_SIZE) dbc_dma_bufs { struct xhci_trb evt_trb[DBC_TRB_RING_CAP]; struct xhci_trb out_trb[DBC_TRB_RING_CAP]; struct xhci_trb in_trb[DBC_TRB_RING_CAP]; @@ -1346,8 +1348,7 @@ struct dbc_dma_bufs { * DMA-reachable by the USB controller. */ }; -static struct dbc_dma_bufs __section(".bss.page_aligned") __aligned(PAGE_SIZE) - dbc_dma_bufs; +DEFINE_BRK(xhci, sizeof(struct dbc_dma_bufs)); static int __init cf_check xhci_parse_dbgp(const char *opt_dbgp) { @@ -1424,24 +1425,33 @@ void __init xhci_dbc_uart_init(void) { struct dbc_uart *uart = &dbc_uart; struct dbc *dbc = &uart->dbc; + struct dbc_dma_bufs *dma_bufs; if ( !dbc->enable ) return; - dbc->dbc_ctx = &dbc_dma_bufs.ctx; - dbc->dbc_erst = &dbc_dma_bufs.erst; - dbc->dbc_ering.trb = dbc_dma_bufs.evt_trb; - dbc->dbc_oring.trb = dbc_dma_bufs.out_trb; - dbc->dbc_iring.trb = dbc_dma_bufs.in_trb; - dbc->dbc_owork.buf = dbc_dma_bufs.out_wrk_buf; - dbc->dbc_iwork.buf = dbc_dma_bufs.in_wrk_buf; - dbc->dbc_str = dbc_dma_bufs.str_buf; + dma_bufs = brk_alloc(sizeof(*dma_bufs)); + if ( !dma_bufs ) + { + dbc->enable = false; + printk(XENLOG_ERR "XHCI: not enough BRK space available\n"); + return; + } + + dbc->dbc_ctx = &dma_bufs->ctx; + dbc->dbc_erst = &dma_bufs->erst; + dbc->dbc_ering.trb = dma_bufs->evt_trb; + dbc->dbc_oring.trb = dma_bufs->out_trb; + dbc->dbc_iring.trb = dma_bufs->in_trb; + dbc->dbc_owork.buf = dma_bufs->out_wrk_buf; + dbc->dbc_iwork.buf = dma_bufs->in_wrk_buf; + dbc->dbc_str = dma_bufs->str_buf; if ( dbc_open(dbc) ) { iommu_add_extra_reserved_device_memory( - PFN_DOWN(virt_to_maddr(&dbc_dma_bufs)), - PFN_UP(sizeof(dbc_dma_bufs)), + PFN_DOWN(virt_to_maddr(dma_bufs)), + PFN_DOWN(sizeof(*dma_bufs)), uart->dbc.sbdf, "XHCI console"); serial_register_uart(SERHND_XHCI, &dbc_uart_driver, &dbc_uart); From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:03:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:03:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449005.1664967 (Exim 4.92) (envelope-from ) id 1xGydY-0008GW-VZ; Wed, 14 Oct 2026 13:03:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449005.1664967; Wed, 14 Oct 2026 13:03: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 1xGydY-0008GP-Sl; Wed, 14 Oct 2026 13:03:16 +0000 Received: by outflank-mailman (input) for mailman id 1449005; Wed, 14 Oct 2026 13:03:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGydX-0008Fv-BD for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:03:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGydW-00DNFf-OB for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:03:14 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7d8d-e002-0a2a0a5209dd-0a2a4508bac6-22 for ; Wed, 14 Oct 2026 15:03:14 +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 6acf7d90-f659-0a2a45080019-94a39b0cff58-3 for ; Wed, 14 Oct 2026 15:03:13 +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 69E8BftW3105948; Wed, 14 Oct 2026 06:03:05 -0700 Received: from mw6pr02cu001.outbound.protection.outlook.com (mail-westus2azon11022125.outbound.protection.outlook.com [52.101.48.125]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4h9nym34su-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 06:03:02 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by CY5PR02MB8990.namprd02.prod.outlook.com (2603:10b6:930:39::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Wed, 14 Oct 2026 13:02: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%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 13:02: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="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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=qDGlc4KIzab57tfuuVXGckOObyjamYQELX8K6xpSR Tc=; b=u13z+ITSShFY5YXw19ij7uj3fnF/axBEpukBlCyrJB9/B34H8T4zzV2r9 0qbNkiYDFgzJPDUOTJDw5VMVH1HqTQAFess/LnYy/3r0WKEePeRru1DeYDd9WWu0 /Bf6vCNVfMN7Tvwq3iOgys7CY++ZcvcCibch+7vts+mqPO7TIQs98FHY1q9VyiWW aJ950BT9gx01DISk4eZgheA1V3eZpBoVCJidBJ9tAz1T1SCzyf0igqi0+CS/zh3N CJfH8j3GYhKENvjiFxogaQIyO5yoS6LSWwC/BnpQnW2VAwojV8OAsD4B3dwUESGe 8gL31xOFLPAPTKoA+b4w7Nf0Lk+Ow== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ySknHBSwSHeRoj4V+l3Ds4EhQmhxPC4aQUzaV2+qr2abKXZtQ0USip7A5KcvZwGAK4wdJFYCM+BcwgS2qthcEKRZtYc4xIsXWdDt+Wjpn5vNzWOW1asna46jBswU6+rtaP3KXiWRul/hWOo8ngK+kQ2v/zPDeiJlfe14jHUy7J5F+PdPP9oth7OV2Ymi3inRkMC9bzNttsDzI3tQ8lWSgubpHanUB4/Mm7qNHgimVup5My2pYqE9MAYfCmga7LuatPu2PgknsEBepCb8jEdLqpdvunswXZ0jLNUILPviy8Qg4XSiMFmMJIbfDcDalmoEnT7zHCf/sG8OO4qK0Nc9xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qDGlc4KIzab57tfuuVXGckOObyjamYQELX8K6xpSRTc=; b=vAx1Ehmvxp16uZkxUXz1APg/y+IBcUt+K+1CaMZ89yK76U0zqMz23pfi9uQrox4caxZjVLsvcZPidEYPPYVyLj5u+WxB4vHdxZ5Ohwt/qlXuNpLbbV2I/ft9WQXhuLGnt/KU/7/JQJtZOsGqOOzq4hO0JpGvapxz4RQwdn9hkvUfT0xQ2cGYRo2DH9IoRmN+t2OnlZ8nXKHUpXo1WRUQUHcYS9NgpfvdsK3DIxiD/+IhL0c33JnIPYO+dMwyK9nxG63iRFkYCuBjF7B7J8GBUGDPzrcFylhplCmZSfFA+ymOFnue7yYkbo4Mbx+iK6R0vq//ULdZQhpUs60Yp9wvDg== 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=qDGlc4KIzab57tfuuVXGckOObyjamYQELX8K6xpSRTc=; b=YXZGSebN/JVJxQe5FUSG7i1JmeeDQLTqAlWS2VlVzlj3tXusbcKU5KfEmKUWW1YEdbV9nIUQruOv10tR6kBvOpx5qlatYjOhEr8ZNccB43A9RitSNWN5lKgPmwl97GiaiVueCEB8zBZUoFL4BI+mRPz+iUn0pGyNnuESENavBALqHYsLpfFA6i1bIBABVTcmKTSlEu+eGHdn2kJ3pfFg1nJfk1kHeFjHOEjHLr9UOZ+9+GvCaLlSwGq7Y7fT70EN8AwE1N86ftUL7VtbsuDAIcoiRa+O+OpIuX6QIuJLSuvG1ADEATADRKJVhxcvdifrJBIprmPxlWF80/YBoltbdQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <6ba4cc53-d32b-4b18-af34-f0bcdb8f58a7@nutanix.com> Date: Wed, 14 Oct 2026 14:02:54 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 13/22] i8259.c: introduce TYPE_I8259_PIC device To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-14-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY3PR05CA0004.namprd05.prod.outlook.com (2603:10b6:a03:254::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_|CY5PR02MB8990:EE_ X-MS-Office365-Filtering-Correlation-Id: d4308393-fb3f-46ac-9b8b-08df29f378de x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|6133799003|10067099003|22082099003|18002099003|4133799003|4143699003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: ZN+RIySVFW8i7GbMof/ZfOWqved2PPoD7wypBQymXTbkaL7604FMcWF+XiZ01yoqP1gFVQ86ty2IyxEK1/7+IZYWtlHMjqhT5GOFmFEksgtUoG4e6JlaJpmTbe5kDGFaSviUNiWZIWJU6/HmgyCebKZGAuYLzNBqnZ47hroHUrAryw7yQA34aVczTSOMBJb4ah+y20ff6TNS9mBWErTmUyO3341TDPF4zPazahfz1rKNjZDAW2LlhL4/r5OYFE90sDMlkAaCw8M2Xv8IAouBF9l2w/HaUGDN4IByuVRt9yJMwkidoFneidR9ZwwKt9pPLzos3hUqqkiKF1SXg9kL26X2+lj/jDA7wc00OjS37/PVJFN/yvSuVzVwVKzuEx3z91gRsgRV44TJP+iyHH6xgdfHukqeiuyMGOboF833YRAGAKTPm5KLi3xzJlbQZAtUFHP9cS9xkJIqUOpgya1GAb97QYLhdmsdRcmUszG4eYEsHD/hT9mEcDb15EulkYh05wsFwRTsYMKjjjZKgI86ZJ6/HYv73bWsUTLGGkKgu5xOWxTAYabJ4Qy3eLrRdSQY+bYzda3FyHjFn7hLhz/aw2BUyGKiBoL10EjJx6/Zm2LQVjFdx4zUkJhq5XgzovBg 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)(23010399003)(1800799024)(366016)(376014)(6133799003)(10067099003)(22082099003)(18002099003)(4133799003)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?REM0bERCQ0VDZXU0NWt5R1BEVFhtRWtySjJIQVNTaU94ckhmZ29aekM5YU9S?= =?utf-8?B?WkJ6MmIxU0JNeDJTSlJTbGNvaFpWWHFITGlyd2ViQVZMOC9MU1JPSGtsbklq?= =?utf-8?B?MHMrc1JqMTB4L0lVRDNEaEdvSDBlYldIRDhJQjE2TmIrNUJVSHVwck1hZWN5?= =?utf-8?B?VWpFT1c5YW5ROWVNSDRoV2dlSmtDR0MyWFh6V0pMTDVqRnI0KzRaSm9uTmhH?= =?utf-8?B?M0xOZWphR2VGYTl6Vmg3RmFIa2xQYjE2R1NPRExlT0NEdzhZN1E2SmhZaGRt?= =?utf-8?B?TTdmd1JYbkY1dXJLQUJFbkFBZXNHQjNpYWlVU1d2VGFYZEVSYjhtMWoxVDQz?= =?utf-8?B?M1ZYTWk0MHZlRWdUV29Iek9VZnVZY0xpUmxleDQ1c2ZUWnlrVU42UEVnbmE0?= =?utf-8?B?SXEwQm5uV2VSVkw5bVNmcWdUWmYzdDlXbnlJb1hZaC9QZkpaT1VEVlBpSFBy?= =?utf-8?B?SWJ2bC9CNG9ncWFFQ25wTnBPMHJQVldoMG1ZdTBrZ0ZPM2JqNXZNUW9NNzJn?= =?utf-8?B?ZVNtRytLS1lVQjMwSWlzSEE0b01OYUtBcXpUbENTZVdLb2VpWFgxUi9GcE4x?= =?utf-8?B?ZjAwT3RtSDVrdDBaUU5ubFJiS3pYRk1MRmVJcVVWUFRUMmFabWE3VUxzRHA5?= =?utf-8?B?dVVDVnd2ME15R09pK2xRZ1lsdVJKVy93OUlheStQN21UK1JXZHBQK3g2bG9X?= =?utf-8?B?Y2U3djdNb2M1R1lUT2FFNkw5L3V2cFpqa3lJMUdLRzhKR0hhc2duTW9JcTV5?= =?utf-8?B?bThNK0VJZlFVR29BNFp6SGlxeDczenB1TG4yUzhWc1h6aUVSQWNIMm5rWjdk?= =?utf-8?B?TGNNWTI5MUpMUUl5dVNJdDZ4YzdwVGc4aDhFWDVSV1paaVVNcjJKa0RYSWpZ?= =?utf-8?B?QjMva3NTeDhDWXJaL211MjdmTHI0TERLZW1kTTJCS2k4V2xYV3Y2RUtnMmFu?= =?utf-8?B?UmtRK3o3ZGtEL1REMTJYNnRhd2xYSGw4czd0aSthbDFqdGhscmtFQTVqY3k4?= =?utf-8?B?L3l6YzUvbU95NlJzamlGVkpvSUUwaytSMGhjNHRySWQ2dkpHV1pubDlOeE0w?= =?utf-8?B?cEV1cER5bUtmSEkrZUo4Tkd1Zzlpb3V5RkpqNHpQbEJFZ1JkZ3NoMjFxMXFN?= =?utf-8?B?WjJSR2ZJbUZNYVN1ditURGpaWVpTYXAxaWcxSVhXaUNaREdpdlRwOU9oN1d5?= =?utf-8?B?VEQzRkpXbHZkRU5aWkFOQlIwdFNUQVNseS9tMHU0SlYxVVU0UmZZc212SDds?= =?utf-8?B?WVNFNHByc2FLQVMzTzMwNnJFU3dLZGVyRS9qMmRNNTRhcnZ6L3NuQ1Q0K2tQ?= =?utf-8?B?ODNwYzRjbDUzN0E5SisyRTBlN3ZTWlZHdzV5SEw1am5obEpPeWdIeWZ6cXhV?= =?utf-8?B?RS9VaEdrWmpSWjVXQ2xJYXJHSDhvMURVVUhDYzlNT1lCNFYySjZiU1dHT3FN?= =?utf-8?B?OVh4V050U0h5Z0lZZDdyV1RKREdZZExYcmlCTXZ2RlVLRzBQZ1gybXZSaHZ3?= =?utf-8?B?R0JQT3BMVEk1eDVYSy83S2NWa1l2Wko0SEZ1VDZGUnJTRE9iZyt3QmVuTE5y?= =?utf-8?B?R294bHJmaElRenRkd0JNS3Q4M1NUMTErY21FN05PN3RQRGtWTzBDbFBRYklm?= =?utf-8?B?V2VrNng4WjNRakxqM0dtWHMxMVhoMWlyZTZNQVdYTzd4MHc3MzFGR3JaczUw?= =?utf-8?B?bjZ6bi9oUU5ueTJuRDMzaWRrUXowblJoNHlNK1FSaWxmM1pzekd4VjlWbW5P?= =?utf-8?B?aUVvNlkwaUtSOFlTVWFXMlRsLzh3bi9rbHByWjVUVkY1Z3cwc1c3OWhxZmhl?= =?utf-8?B?TWtaNzQ0ME9lUGxnSXZwcTgzTnBUZEg0SndST1JpQkpjTEZBSmsyTnIzZ214?= =?utf-8?B?YTlzNzBOQlVtNUgrMy8xZWY1RVUzZ1MwMG1oei9uK3lWUjlMVHFNVmdDa1BY?= =?utf-8?B?ek1ZNlNQdWxVVFd3UmlpbHVKMW5iM05QUDJIdnJyRWVqbWtqQSszbVVPM2Q5?= =?utf-8?B?d2tlSGowM0lUdmRVOW1MbmYrOWxHL1JuTVhIWTBBZkpMOHMzQjBJNDkvcTdj?= =?utf-8?B?eTVsTVBZVjhBQ21LSU5FQUVYSnBJYjA5ZXpLdkVhd2xpNm5HMXhKdTBmeWlF?= =?utf-8?B?YzlGSExNSmJ2UjgyUnFrUit1azc3RlVHZnBDMDE1SHdsZWpRWGJNWWttL3dq?= =?utf-8?B?QmVJZi82T3R2NWZvTGFwY0hpYjlEYmF2dnNJMS9qVVZFVzRVMGVPWkg1YjRV?= =?utf-8?B?Z1Q2ZVRTVlBXeVVJRkV6OHMvQkduN3lWZEJQUkw4YmxZcTJUMVJrRlllQjhV?= =?utf-8?B?cnh5dEoySVB4bm5oeXBuZ0xUN0I3MXNpWmcyWWhzODNOY2xiRnVFUWZSUTVl?= =?utf-8?Q?ATSfPCxzzxeXMkpQ=3D?= X-Exchange-RoutingPolicyChecked: e9R+OkF3PBriXHmQQNCm7ZLGCxdF8prQuqbByNmykjaBokaUhoyYGRuOXzWyACYdFdstYgua+Q2bkyor1Or6Pi/oPWxSTwMFh8zogqFSA3QK1BfdyIgNei2UL2hWFPd+Cn86r4pFyveOiRPiFg2l5RfhsOM/31mRFrgyHbfocUrVLY4d1sBUsyQjvRHD5CP+TqVfJEOg8j8+kzuznX+S6H53lgg1f+Zz9Zp1VM6BVig3dxjmFzt0dHPaTedIiH4IY/5AhryJQJ9nTkWH+uvyhI7IYcMB2W2wgZS6Y0WSWp0KMG40MMs1+3zMTT7dG2KF/pCEUGlDwXp820ydNqfLZw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d4308393-fb3f-46ac-9b8b-08df29f378de X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 13:02:59.2927 (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: 0RHBt+GOa8Tl6cFGptCPah/OmwUXy5sStUgWsSAMyeqy/je6ZcydZSlodriOIj9mU7foXFPG7bk/6lDIoaCqVNpgEW5IHazT3mWNTsEymZI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR02MB8990 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA1MSBTYWx0ZWRfX0ytvvr2/isaJ 7PZvb0eyPzxqAv3Wjt34MzLpp4KX4gr2SgrvgeXdWwPyHTaoeAGhNhlnDnLoLQ3iACvSeFBEeO5 XDDD4HB+HZ6LtBAAHDGuHYrMrGxDqe2Qwr7X/gbkfUGxiL7RGYGACirIHXuL2KOFVEWDMPA9qsk BYQqtHTUgfTfifRTHYgtwjw5rfCnb9lA6CvmbHMTQZ7MKvo5yLTUZoJchCYihI6jACUOZsLOlUv +1BFQCRNhwXmWDGfYHqgCz6d+BI3DhToOgjltAWWuxFRDbF8jwxPn8HEayYs1AvN7khmPhNiC0T NmyApAcE3PGEeJ9q1scnX2kSfK9A8p28cq+YrcKfc8E3pduukt2jiCnvEDKEJUTFNKyU4KJ8/j3 UISoSxQ/EsjCPZkYlpG6hfMVbFKLZA== X-Proofpoint-ORIG-GUID: 6aE_isPI4W8_4juOeydGyVoMAkX5V_KX X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA1MSBTYWx0ZWRfX+7TpWsvdhLN7 WJQoDJZY0vwup4hVoHqjuKICg0DUDX9JzNGMv7UDafNzRN4i76+xrMxUi6wlCmyQbYmUS+TQAna e4qO3A+G2RuzE8heaA4dTmUfHWK9u2E= X-Proofpoint-GUID: 6aE_isPI4W8_4juOeydGyVoMAkX5V_KX X-Authority-Analysis: v=2.4 cv=OIuyTiaB c=1 sm=1 tr=0 ts=6acf7d86 cx=c_pps a=qTO11YbfUBYfkhAk4rXMnw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=ID6ng7r3AAAA:8 a=UXIAUNObAAAA:8 a=64Cc0HZtAAAA:8 a=vTBCZPzhfYM-r4PNrEoA:9 a=QEXdDO2ut3YA:10 a=AkheI1RvQwOzcTXhi5f4:22 a=a1s67YnXd6TbAZZNj1wK: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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1791982994-D6D4087B-8D61B406/0/0 X-purgate-type: clean X-purgate-size: 3677 On 14/10/2026 13:04, Peter Maydell wrote: > On Wed, 14 Oct 2026 at 12:09, Mark Cave-Ayland > wrote: >> >> On 13/10/2026 17:17, Peter Maydell wrote: >> >>> On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland >>> wrote: >>>> +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]; >>> >>> This allocates only enough space for the common base class's >>> instance struct, but later we do an object_initialize_child() >>> of the child class. If the child class's state struct is >>> ever bigger than the common class, this will break. >> >> That's true. In theory this should be something like I8259State, however >> I didn't think it was worth adding a specific >> OBJECT_DECLARE_SIMPLE_TYPE() if there were no extra fields. I did >> quickly check that if this happens, then the assert() in >> object_initialize() fires so if this did happen then we'd find out >> really quickly. > > I think that every QOM class ought to define its own instance > struct, even if it doesn't contain anything beyond the base > class. This means that when we do need to add a field in future > we don't have to go around and find the places which currently > use the parent-class struct but really want the leaf-class > struct. (There are places where we don't catch mistakes like > this -- for instance I think if you don't update the > .instance_size in a type then that doesn't get noticed: > we've had a bug or too like that). > > We don't write that down in https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.qemu.org_Documentation_QOMConventions&d=DwIBaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=_sMHrUpIgbF65xjh0xd4r-zuudhThxapWCIXp0orT8OH8CbTHKgmaw4SuUcNTpeW&s=9mPS_zIx9x3FD_6cxEpVK-5JyOlynQ3bsBTf44iWLPk&e= > but we do have some similar rules about class structs that > boil down to "either you're a leaf class and provide none > of these things, or else you should provide them all; don't > have a halfway-house 'we happen to only need X and Y but > not Z right now' setup". Yes, that's fine with me. I have done it that way previously, however there are some people on-list still advocating for the approach in this series. If we decide that this is our preferred style then I think it's worth documenting in somewhere in https://qemu.readthedocs.io/en/master/devel/style.html#qemu-object-model-declarations so that we can point people (and LLMs) towards it. >>>> 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, >>> >>> Devices that directly inherit from TYPE_DEVICE are awkward, >>> because they never get reset. Conviently this device doesn't >>> currently need a reset method, but still, is this a good idea? >> >> In this case I think it's correct, because the PIC device in this case >> is a container for 2 cascaded i8259s which are connected separately to >> the ISA bus. Therefore each i8259 will have its reset triggered via a >> reset of the ISA bus. >> >> The container itself can't exist on the ISA bus because it would then >> appear as a separate device which doesn't make sense in this case. > > OK. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:19:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:19:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449042.1664977 (Exim 4.92) (envelope-from ) id 1xGytY-0003Bf-DP; Wed, 14 Oct 2026 13:19:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449042.1664977; Wed, 14 Oct 2026 13:19: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 1xGytY-0003BY-9U; Wed, 14 Oct 2026 13:19:48 +0000 Received: by outflank-mailman (input) for mailman id 1449042; Wed, 14 Oct 2026 13:19:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGytX-0003BS-6J for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:19:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGytW-00DQfe-Bn for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:19:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf8163-e002-0a2a0a5209dd-0a2a45018b24-40 for ; Wed, 14 Oct 2026 15:19:45 +0200 Received: from [52.101.193.33] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf816e-5984-0a2a45010019-3465c121ea9a-3 for ; Wed, 14 Oct 2026 15:19:45 +0200 Received: from PH5P220CA0012.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:34a::9) by CY5PR12MB6059.namprd12.prod.outlook.com (2603:10b6:930:2c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.24; Wed, 14 Oct 2026 13:19:36 +0000 Received: from CY4PEPF000392D8.namprd03.prod.outlook.com (2603:10b6:510:34a:cafe::96) by PH5P220CA0012.outlook.office365.com (2603:10b6:510:34a::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Wed, 14 Oct 2026 13:19:35 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CY4PEPF000392D8.mail.protection.outlook.com (10.167.247.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Wed, 14 Oct 2026 13:19:35 +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.53; Wed, 14 Oct 2026 08:19:28 -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.53 via Frontend Transport; Wed, 14 Oct 2026 08:19: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=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=nDvc6yct3ZyhiWrD4GBhC2d3gCuHAslkz/hcRb4FSgmr6WlXQGUyaxCEhRLE6WihWC4VgYcOqJloEoX4MbrdqgBUwnumlfgKoTteCwIHCGiHcUC6LXCuAoy/92VwecLZeZyeZE0vMOWqTdPGPEmS1OYJweDrdNEuoBEK5tHT8/QwsTXVzS4t/utzXfIA72JCu0AhIxFRPDcPAQhoTuzYbd4YHdbpVek2dJ4K39TBS9+s4dRu1fAsQzcaZviygIFTvaK4n7ahLyHq9Y9htFaWRbUClc8bq5boFWAnM6ypytAsZ8kE08xtod3P+U8q+tBcQ/NNaQ5C9tDS/YPXUavFbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p6JqJhXRW78SsZJTBP/YdbipCJKRMjtHmjWjEZeUgu0=; b=msCluKa1ryBVdSlCEkbeJ6z7Ohg4Y+44DDlPkpvLocc/jQFEWl0UgzI3wv1nB9MbJFUnKmXPAnJgajK0bxXXkg6hcysVFWh4DZToNhfK/DK2u57MCMgvMkFca6IQn6VaD5zGmvxOO5IGVe+sGbzkG1wLMb2TZ2g9G30BQB+mX4ZkRj93Ml774Fw4ujA/bEMP7Kui2hsS+eGbLHnliRKnh26HijNTT4zciuxuiiW2itLN0c/1EcLmAFAQufYsYUflESy53l3C+xsWnIey4e+0zhFW1WF4gMsJl9G3HDJu6TQq/mDXRGLrrrBnvjas+kovFAZnRoHFTaSDuGdEC1Vuug== 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=p6JqJhXRW78SsZJTBP/YdbipCJKRMjtHmjWjEZeUgu0=; b=gc9xkidNLFXV+W1HscPVaPyRmnOdkH9eCXzHRLeAbHa2D6rRzOA2PruFhdU3tNrHM7wBYSRc9fV+oSUtPjmE6wU3ENCNeK+2CtByIxo4bBiCgxg5nvQ9PTFB7q/mfJPg5HDYUpqySZ+KhIjNaOSFm2k7sRWGoLZ95vi06pto970= 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: <0d892635-2284-40bf-8b0b-3c067d49d465@amd.com> Date: Wed, 14 Oct 2026 15:19:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 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: <20261013103616.121916-1-taka@valinux.co.jp> <20261013103616.121916-2-taka@valinux.co.jp> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261013103616.121916-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: CY4PEPF000392D8:EE_|CY5PR12MB6059:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f6be8fd-1012-49bc-f6eb-08df29f5ca80 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|4143699003|11063799006|261009223027099003|260925021911599003|260925021311599003|260925022911599003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: dnR1mDnCBYnJDI/tciD0KZCOII7mFKuQ/U3K8rD3vUJSRS6J1oazpMqqRVMEL8ZW/yimYdwYVPtnavBq+JyjdfCka6IX7e4m/XX799gRt2hCmvv7LZav426dyhDp1S6v5pmlaQS2nlSCScXaVZPLFbISSdzwWKXKoVJnWoQCSEu6j2PP4nmSV/svZKj9MWL7H8wrWUoDoei7q72h6MDQoMnpiqE00B01NEvuhuUnwdMdwgZvwkJD+pGIfjlHWuIACsXNnuZ9q0/N9PClYcbXJjyOMuEWMg4DkHqE04uUSd/sJzdCMuz2O/feddDVMPZDc/y7poJX1xBZKqxVyM/Jc9Xs62tXowHOsTku9i+kfZ54oS582hNW+9lPGgCIHKCnNek7IOWDXtWWPwXlIyKzMGQVxiUIqSXM+mWhpLymi5VJNGilCNgaxNdhcE1ve2+Dl3YuriQeDqanWSCmany3jiTlGyd4Lh0oIO2jn03X84TdckUgiBviBq6WXTPuTW0i2xvogt1+1xeHq69hUI7xahYAbG/2MTH7IHvWNlvD1cCauT2iDpwCwx22WusNogLdh2X3DxJO9AarlaHjLEpZx79/RxC1A3hhrJz/brY6kj09d48UhHTrxYdpsWPYsf5dsmYe96NAkohG3hhgVLuLLX1kG6JTvr5YevQZq856EEotABkW6r7Cp8vNDkBzaT2mmUg59i0bRMEWiSa2MncyUA== 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)(1800799024)(23010399003)(7416014)(376014)(82310400026)(56012099006)(4143699003)(11063799006)(261009223027099003)(260925021911599003)(260925021311599003)(260925022911599003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Ac1AS5P+8+9bZI+RZQCBzHipr8mhlSL6JkuL/qMkGmrjy0XD32rnoySIhVCIwjOlOTw3gF2JMrX4dQv4zeAgajtkzh1au91VFxVzk8iQkj8gClFzhKUb8DC14jAw8XMJVKBy81d+bcw6Mp/K8IlDAGMcdxAiFmFYwfdmyUA78lG6ZOF7EC07c0uo00fA8ZkIt9wIlFONSduLMtpjs4YJhBNVm5X1ft1czFk+pCKR8LfBTnEHVAtHkTxE/UUDIX+K60IqLUVffvcQnGnaHw02OH2PFTce+GTsMY9T1a46NGqpEs7OYFtKwtOP2hH8RsIAemvYBqbsZycSeR5L1t0NcHOrOOZYh95PsM+cQu3OCAWbTDfXZRa2uTKa+LBNja3R68Kvm6fwK+oQj+tzaghAFZnO0VW9CJx1DOmjBrCHb70hahGX2FhyHbLg/DOQxqeh X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 13:19:35.0178 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f6be8fd-1012-49bc-f6eb-08df29f5ca80 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: CY4PEPF000392D8.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6059 X-purgate-ID: tlsNG-d62444/1791983985-BD87F757-F7F9D34C/10/78276251493 X-purgate-type: spam X-purgate-size: 16834 On 13-Oct-26 12:36, 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 v11: > - When parsing the Device Tree, ignore CPU nodes if the corresponding > physical CPU failed to boot, rather than treating it as an error. > - Drop the dependency on UNSUPPORTED for CPU topology support. > - Print an error message if memory allocation fails in init_cpu_topology(). > - Fix a compilation error involving cpumask_set_cpu(). > - Call map_cpu_to_dt_node() to record the CPU ID to DT node mapping only > when arch_cpu_init() succeeds, or if the CPU is the boot CPU (treated > as successful since the boot CPU is already up and running). > - Use XENLOG_ERR as the log level for error messages emitted when DT CPU > topology parsing fails. > - Add ASSERT(cpu_topology) to acpi_init_cpu_topology() for consistency. > - Code cleanups: > * Use dt_node_name_is_equal() instead of dt_node_cmp(). > * Drop redundant "ERROR:" and "WARNING:" prefixes from log messages. > * Move header file includes into #ifdef / #else blocks where they are > actually needed. > * Adjust spacing to comply with the Xen coding style. > > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/setup.c | 3 + > xen/arch/arm/smpboot.c | 6 + > xen/common/Kconfig | 22 ++ > xen/common/Makefile | 1 + > xen/common/cpu-topology.c | 69 +++++ > xen/common/cpu.c | 5 + > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/cpu-topology.c | 352 ++++++++++++++++++++++++++ > xen/drivers/acpi/Makefile | 1 + > xen/drivers/acpi/topology.c | 43 ++++ > xen/include/xen/acpi.h | 13 + > xen/include/xen/cpu-topology.h | 34 +++ > xen/include/xen/dt-cpu-topology.h | 35 +++ > 14 files changed, 586 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 b9c5c40678..3d0f689220 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_SHARED_INFO > select HAS_STACK_PROTECTOR > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 2cd1c021b5..c1aa06bd31 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -10,6 +10,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -375,6 +376,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 8c9072f3c1..089c997f38 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 > @@ -245,6 +247,10 @@ static void __init dt_smp_init_cpus(void) > } > else > tmp_map[i] = hwid; > + > + if ( (rc >= 0) || (i == 0) ) Please add a comment explaining the second part i.e. boot CPU may lack enable method. > + /* 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 5b289e444f..fb42f0aa8b 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 > > @@ -194,6 +197,25 @@ config VM_EVENT > config NEEDS_LIBELF > bool > > +config GENERIC_CPU_TOPOLOGY > + bool > + > +config DT_CPU_TOPOLOGY > + bool "Device tree based CPU topology support" > + depends on HAS_GENERIC_CPU_TOPOLOGY && DEVICE_TREE_PARSE > + 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" > + depends on HAS_GENERIC_CPU_TOPOLOGY && ACPI > + 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 f69d47d189..d0eb39a633 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..ce50408858 > --- /dev/null > +++ b/xen/common/cpu-topology.c > @@ -0,0 +1,69 @@ > +/* 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; > + > + if ( num_possible_cpus() == 1 ) > + return; > + > + cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids); > + if ( !cpu_topology ) > + { > + printk(XENLOG_WARNING "CPU topology table allocation failed.\n"); > + 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(); > + printk(XENLOG_WARNING "CPU topology table allocation failed.\n"); > + 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(); In a previous revision I asked to print an error (except for expected errors like -EOPNOTSUPP). > +} > + > +/* > + * 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..a62f65a41d > --- /dev/null > +++ b/xen/common/device-tree/cpu-topology.c > @@ -0,0 +1,352 @@ > +/* 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) > +{ > + 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) > + { > + 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_name_is_equal(np, name) ) > + 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 ) get_cpu_for_node can return INVALID_TOPO_ID also on malformed DTs e.g. missing phandle which you now accept. Shouldn't we return -EINVAL? > + { > + /* > + * Ignore this CPU node definition as the corresponding physical > + * CPU failed to boot. > + */ > + printk(XENLOG_INFO > + "%s: CPU for thread hasn't started\n", dt_node_name(thread)); CPU topology is initialized before bringing CPU up, so this message is incorrect and there are more than one scenarios we may end up with here. Maybe just "CPU not used by Xen: ignoring". > + return 0; This stops parsing other threads which I don't think is the right way to do it. We should just continue. > + } > + > + if ( !is_cpu_map_empty(cpu) ) > + { > + printk(XENLOG_ERR > + "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 "%s: Core has both threads and CPU\n", > + dt_node_name(core)); > + return -EINVAL; > + } > + > + if ( !is_cpu_map_empty(cpu) ) > + { > + printk(XENLOG_ERR "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 ) > + { > + /* > + * Ignore this CPU node definition as the corresponding physical > + * CPU failed to boot. > + */ > + printk(XENLOG_INFO > + "%s: CPU for leaf core hasn't started\n", dt_node_name(core)); Same wording issue. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:36:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:36:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449058.1664986 (Exim 4.92) (envelope-from ) id 1xGz9S-0006Zb-Kv; Wed, 14 Oct 2026 13:36:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449058.1664986; Wed, 14 Oct 2026 13:36: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 1xGz9S-0006ZU-I2; Wed, 14 Oct 2026 13:36:14 +0000 Received: by outflank-mailman (input) for mailman id 1449058; Wed, 14 Oct 2026 13:36:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGz9Q-0006ZO-M1 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:36:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGz9P-00BaUj-Jr for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:36:11 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf8536-2eae-0a2a0a5409dd-0a2a4503c5da-46 for ; Wed, 14 Oct 2026 15:36:11 +0200 Received: from [40.93.196.25] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf8549-fae8-0a2a45030019-285dc41969e9-3 for ; Wed, 14 Oct 2026 15:36:10 +0200 Received: from CYZPR14CA0020.namprd14.prod.outlook.com (2603:10b6:930:8f::25) by SA0PR12MB4366.namprd12.prod.outlook.com (2603:10b6:806:72::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Wed, 14 Oct 2026 13:36:05 +0000 Received: from CY7PEPF000000EF.namprd04.prod.outlook.com (2603:10b6:930:8f:cafe::b) by CYZPR14CA0020.outlook.office365.com (2603:10b6:930:8f::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 14 Oct 2026 13:36:05 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY7PEPF000000EF.mail.protection.outlook.com (10.167.247.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Wed, 14 Oct 2026 13:36:04 +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.53; Wed, 14 Oct 2026 08:35: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=Ik/n5qsDackDgQIiAfmR/UOJFDR7lQYE/08/oJ98/yfybaWkwCwxdAXbzgVIY5hVFH9elc8UmD7Chq+agMh7nsuodrFhj9lOE4ELfTBYvFgFNev/2U6LTbGYpXzMQH9Ckvm6hVJnQHdUcAM2HKa6MbXYj/QKrvfqU6ip5Vbe3nsvBZq+sqHXR8rGFuUdx4VheBQjr4oN3TlnGXsPVNwzwQ8QMdImf5/WAFqlNqRkj2ET2euG9IZ2XvB6AHOh1IOY5xq7CaroKnUIRYkGDySQwdl4C6n/wN5gpeUZyFce8OqhfJMg3ZxUm8b/Pg1lmuG6ovodWxsZIiPDmbJCBYo49A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W3uZNeXE42tXk3NhU494qyzBKaz8QrbXL/HzVkz7lhM=; b=k4/EyvcPFkgnHqqJyfHiJFl8H4/E7Fhc0il5cvpTCDZJEZrcomRhgmrNaeFY9KZPX7aEOxxDiCxG5/XHXpwNfM7XVRyvkBocfyq5rPLVuuYwJS77U87i7kuGXY/VlSHXY/Q6ckKVN+ETuL7wD++TWza6cnBBNW9FCFn+MbSgiVykOKfB6zQPQUzb29S32MQ3ZslZLEJ1hLIMhMGQFF9VKGgvcgTEIxBAaFafx1xWRxo6QM/jwjNO7NyE/pEv83AoW5u7IV7mUPYok0+F1/AvmN+M/RYxsEu/NabbCntL0KZgNHITcvsRFHmjy/xhq3yyZxKyOe2KTlS8H/H9aud6uQ== 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=W3uZNeXE42tXk3NhU494qyzBKaz8QrbXL/HzVkz7lhM=; b=xlNCTvIICulPti+n6sjSiwkpC5fRNBJxRGiFKkd+aq9mX5N1ynxSzIOWKM+j7FrdVNX6tXeOXcq44dg5Yf0lqXjUS4Df5d1xGdgf8RGHNFXqWpLkVQgNzR8CdwmufFxd6Jac9TZ8b5u/r7PjinvaMvBOCrxzo4liRs+fRTBCsGo= 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 From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/atomic: Fix UB on various atomic helpers Date: Wed, 14 Oct 2026 15:35:50 +0200 Message-ID: <20261014133551.622462-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: CY7PEPF000000EF:EE_|SA0PR12MB4366:EE_ X-MS-Office365-Filtering-Correlation-Id: 2f6d3c9a-d88d-45f9-01e3-08df29f8185a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|376014|82310400026|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: yQRDYmLBldvkpAw8QLkDvR7KI/rbD+fncwK5unLNrwT1t/zjy6kLsvodu1oYJQrOApL9Vmalk57aJ2FWRFdeuWUkT+MhcYXXk06l3q/+ncdhF7T1ABaqPnHSajaOeMXMn0BJsmWrde3Lnc+hP37d8XlTHyIbgcdlwxaCBaW2OO8AIlMYiydJJXtuSjUUn8SgkSjbTqgjbhjgne+EyKIZBZ0tzl/3IzxSkcbH+pwlPRfJ64nzZMX+T4PqoFhQw1OIWAamHJREyZ33e8fWAuIF0LBOFnIMQw3EO4LJCto1dLA057e2yYfOKS/7MtzWMihR1ys6wmFYTpb6l/bRHldoL8ityjhfxBRMPNswq7j+rKORdjrUYnERTVcseyBmolIGyliR+aFobdcTCZ0PhedbpI8THkiqQJBxRebGNS9sFWPHLFaPQWXmgHBfuCbhWiEKAbLgxTOUItebBxeyxMoeHe3oyBqxI859ADBxMWBomPIUR6yFhzrjGrC9aorN5+SZaGe5RfZlpi5BtSS2bcd/8RdeWURLIoS/9Wh+7oxg2E1u7zqfFe+9jR6xEZEAKdXBu+iDnbcGTWA+n9SMh3HHPutgozgVwMU8mh//yltzfTr7K2kz654NNpn/a1TAQSaT2quZ6/v+K8YktPCthSBb681wKLO02FfnJj9sM+GJej0RHD3ul9g4VZDo5WMlkSkBQPtGSalyuJlhDaFq3IHjgA== 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)(82310400026)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: VoC49as/xNK3Mt2bqR8z3wWVWAXXe0mgYLXSbGj8Zkf3gJmr0WxMLFbORoHVLG3sqqOS3KUP65upR1Gt4q6CeJRAjveVO4lDmZJrGWRivGLpAzCHUGwGPMtITb5kbf2R3Lb89Wyyy7JJ1pSjjmjH294Ftr1amLjE1Upityvmx0bYvRGX7qcSFXwa8o4QcWDoTYQbHKozK0S2NPdyK5IHUuHP+J6mTV5xBtuaqJdogff3NZWwXmbKYy5Hzd95GxEqcpm/BDd/t2H2Y2f11DbVWq8sDtkAmzMA78jsHjuJEYfe42/q/kzPGt2jfcmLdMjMzD4W0JGwnLkUmdd0jnF0Bcw6Zhs5OrcwANphrZCePlb15QEXdaxO64JZz7Rzuu9FptDpHW9DrcQDUHYX5LP64CI/U09ep5Q5DxhacrCs/a5PMfNNYXRF9QC7Q7oUsHrE X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 13:36:04.6195 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2f6d3c9a-d88d-45f9-01e3-08df29f8185a 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: CY7PEPF000000EF.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4366 X-purgate-ID: tlsNG-33051d/1791984970-6D2D84E9-259D62CC/0/0 X-purgate-type: clean X-purgate-size: 2256 The atomic interface is signed. There's UB if a caller adds over INT_MAX or subtracts below INT_MIN where the addition/subtraction is done in C, just like in a regular int. Make the outward facing interface respect two's complement on wraparound by round-tripping through unsigned for arithmetic. While at it, fix the while loop to have Xen style. Fixes: e0efc0738163 ("atomic: replace atomic_compareandswap() with atomic_cmpxchg()") Fixes: c98c80084d77 ("asm/atomic.h: implement missing and add common prototypes") Signed-off-by: Alejandro Vallejo --- I'd prefer to turn this into an unsigned interface, but then some callers would need changing in non-trivial ways. OTOH, one could argue the atomics merely highlight the UB already present in signed arithmetic, and thus this doesn't need fixing. I'd prefer to remove UB where possible. --- xen/arch/x86/include/asm/atomic.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/atomic.h b/xen/arch/x86/include/asm/atomic.h index ed4e09a503..8f227e0e6f 100644 --- a/xen/arch/x86/include/asm/atomic.h +++ b/xen/arch/x86/include/asm/atomic.h @@ -122,7 +122,7 @@ static inline void atomic_add(int i, atomic_t *v) static inline int atomic_add_return(int i, atomic_t *v) { - return i + arch_fetch_and_add(&v->counter, i); + return (unsigned int)i + arch_fetch_and_add(&v->counter, i); } static inline void atomic_sub(int i, atomic_t *v) @@ -135,7 +135,9 @@ static inline void atomic_sub(int i, atomic_t *v) static inline int atomic_sub_return(int i, atomic_t *v) { - return arch_fetch_and_add(&v->counter, -i) - i; + unsigned int ui = i; + + return arch_fetch_and_add(&v->counter, -ui) - ui; } static inline int atomic_sub_and_test(int i, atomic_t *v) @@ -221,8 +223,9 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u) int c, old; c = atomic_read(v); - while (c != u && (old = atomic_cmpxchg(v, c, c + a)) != c) + while ( c != u && (old = atomic_cmpxchg(v, c, (unsigned int)c + a)) != c ) c = old; + return c; } base-commit: 7168cc02f86fb069da6e7405afbf5c7a1c215b0d -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:43:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:43:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449066.1664996 (Exim 4.92) (envelope-from ) id 1xGzG0-0000CE-Dv; Wed, 14 Oct 2026 13:43:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449066.1664996; Wed, 14 Oct 2026 13:43: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 1xGzG0-0000C7-9t; Wed, 14 Oct 2026 13:43:00 +0000 Received: by outflank-mailman (input) for mailman id 1449066; Wed, 14 Oct 2026 13:42:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGzFy-0000By-Eh for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:42:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzFx-00GjWO-Dd for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:42:57 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf86d5-bab6-0a2a0a5309dd-0a2a450ac41c-32 for ; Wed, 14 Oct 2026 15:42:57 +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 6acf86e0-f2d2-0a2a450a0019-d155802ef0c8-3 for ; Wed, 14 Oct 2026 15:42:56 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a0286c981dso9144695e9.2 for ; Wed, 14 Oct 2026 06:42:56 -0700 (PDT) Received: from [172.20.10.5] (public-gprs378609.centertel.pl. [37.47.110.50]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de70079e7sm6961579f8f.11.2026.10.14.06.42.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 06:42: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=1791985376; x=1792590176; 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=sb7HbZHmKmSEPYv5vVLskDslIZvepgWW0bExtidSFNM=; b=C8jdStkxzCwT6QwoH14UBvqWI0LSsT62wnlfiCrimV+ug7vqRbPB0xh6Q/q6AwSEZx aTtcNiqGxlhk517C9sCuFcRMr0gDgJTogPZYKfpFRwDXY4hM3ihTIdcLOTEEHEMaRLJ3 mBZ4JmmNMC4VPPaxMJwjXhvqFEZuBYbv/w9sRg3idBS4Qtd6yMk1VqICkpFrABfj4d7C wchqi83+2HZ8FTWt0GKoEPlPzU25yEexcB5rFKDq6M0Rcs9wSjGNxi1iGms27WRetn5H M+q2Mi/0QlRGXzw3JVpbCkiakwvogsSyEm8JZO0XNxhNAwbXSHeR7mqbxCY9jL6/cuj3 i1dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791985376; x=1792590176; 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=sb7HbZHmKmSEPYv5vVLskDslIZvepgWW0bExtidSFNM=; b=eAJdVr78NlHu+fR0YaPT0Yj64ZQ5gDn/veTsqDjrzCqR222n/IwZ2X4FcI0Xlxx+1+ mabRNVbEKcRMPnp8WEWun93G5/ruvljZvKRZd+PNis2oQdjXH+IaSTC9bbWbQki4RHch oOdWbT0BRYR8bw1QgxU26yoCS1N8+xxoowp9TdOcEJBRHzUyc/Z/aIm2pzIV6DKqZ4Yo B26wlejLOsvboUP9KdAAqVkcaLi3uPgqWzSL1xqtAcnORbUH8iJklaWq0nM/lX5BhRmL /26jnfikRDJFPITgwx8SmInRmrX0Gnh2plKXk+95+D15EEAjjiIwKDLNBXjiMdzy9kjb OCOQ== X-Gm-Message-State: AFq9FYI/wgbB12gQ5e+wTpu+i6YYAnJM778VdC5GvpDf2yh71Z20k4rn HfgzQM5Ieen2FwKXVkwceI3nrv0UgTe79KtsHa18JzVEl6exw5noB01f X-Gm-Gg: AYBFou3CVa/Nb+zT/0PIHMx3kuisgTbMFUqDyC7p5D35QaKVcV2t7m6RZCwjWEYdhyW eMzm4bKMCl2+wEZIGoJnx9kvRNGrtruHEu9g8/JPIESZDROkAm1amYBThMYN9eUeo1rYYDv8WMN ++9cyKRWHhqUrVQiaDZ/g3sFKZ7nd1O9/lDbMADce9n6qYKVrYD85ygDKJwuyr31lsqAJZE6N1q Nhh/L2s5OsZXf9ttMsGY2PD5IjYF7Dhpvgd0Rzv/wC+15qY7bSNDNiEDuJu9z5YSdFdnF+JM1iC sgdfxM1KjRq4mE48qZA4LDyZqvskWufxpL7/IKEsXXjSKOsiW8+470wZ8+vKsDAOyic4phpupQO PgXkEvPSMTxhj7mE0NUgZWPScZFto8ACV1FYsJso7KbSy9TC8AcOF9f3OaLd8ZOTDM+yqbgYXx4 Z2K2XdAb5gAuIDlgZ9tL0FfCXW9iMtQDrygOUlPQn9tJ8xoilZKY5x96BpTNusEXggY2ZiZpkmz hAmRSqFzq3NeLZyvSg2wqxLTCGKVviiOlQyXQ8= X-Received: by 2002:a05:600c:8b09:b0:4a1:6f78:842f with SMTP id 5b1f17b1804b1-4a18e4987b8mr331719405e9.11.1791985376245; Wed, 14 Oct 2026 06:42:56 -0700 (PDT) Message-ID: Date: Wed, 14 Oct 2026 15:42:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 09/39] xen/riscv: build the target hart index via aplic_hart_index() 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: <1791277332.8631fc262581453bbf619ec5b2062170.1a11072f6480003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791277332.8631fc262581453bbf619ec5b2062170.1a11072f6480003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791985376-52EDACFC-C2693141/10/73395122804 X-purgate-type: spam X-purgate-size: 7634 On 10/6/26 11:02 AM, Baptiste Le Duc 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; >> >> - the same hart id was then used verbatim as the low hart index, and >> the group index was derived from msi[].base_addr alone. The hart >> index bits live in msi[].offset, the base address only covers the >> MMIO regset, which may hold the files of several harts. Both indices >> have to come out of base_addr + offset. >> >> aplic_hart_index() already extracts them that way, and is what the vAPLIC >> target path uses, so call it here as well and insert the result with >> MASK_INSR(APLIC_TARGET_HART_IDX) instead of a bare shift, which keeps the >> value from spilling out of the 14-bit field. This drops the last in-tree >> duplicate of the AIA hart index formula, and with it the last user of >> APLIC_TARGET_HART_IDX_SHIFT, which is removed. >> >> desc->irq is used as the EIID as is. Assert that it is a valid APLIC >> source, which also guarantees that it fits the EIID field. >> >> No functional change on a single-group platform whose hart ids match >> their CPU ids and whose IMSIC regset holds one file per hart. >> > Nit: The message is hard to follow because it describes the old code and > its bugs in the same sentences, so you never see a plain picture of what > the code did before. I would propose this: > ``` > aplic_set_irq_affinity() computes the target register value by hand: > > cpu = cpuid_to_hartid(); > group_index = ; > hart_index = cpu; > > This is wrong in three ways: > > - msi[] is indexed by logical CPU id, not by hart id. When the two > differ, the wrong CPU's interrupt file is used, or msi[] is read > out of bounds. > > - The hart id is used as the low hart index. The AIA spec defines > the low hart index as bits of the IMSIC interrupt file address, > and the two are not guaranteed to be equal. > > - The group index is taken from msi[].base_addr only. base_addr is > the start of the IMSIC MMIO region, which may hold the interrupt > files of several harts; the file of this CPU is at base_addr + > msi[].offset, and both indexes must be extracted from that > address. > > aplic_hart_index() already does this correctly and is used by the > vAPLIC target path. Use it here as well, and insert the result with > MASK_INSR(APLIC_TARGET_HART_IDX) rather than a plain shift, so it > cannot overflow the 14-bit field. APLIC_TARGET_HART_IDX_SHIFT has no > users left and is removed. > > desc->irq is written as the EIID unchanged. Assert that it is a > valid APLIC source number, which also ensures it fits in the EIID > field. > > No functional change on platforms with a single group, hart ids > equal to CPU ids, and one interrupt file per IMSIC MMIO region. > ``` Thanks, that reads much better. I'll take it. >> Fixes: d4676a1398bc ("xen/riscv: implementation of aplic and imsic operations") >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v3: >> - s/aplic_hart_field/aplic_hart_index/ (in the subject too) following the >> rename of the helper in "xen/riscv: implement virtual APLIC MMIO >> emulation". >> - Don't mask desc->irq with APLIC_TARGET_EIID. Instead, bound it by >> the APLIC source range rather than NR_IRQS, which will also have to >> cover device MSIs: add a BUILD_BUG_ON() that ARRAY_SIZE(target) fits >> the EIID field and an ASSERT() that desc->irq is a valid APLIC source >> (1..num_irqs), which also covers the target[desc->irq - 1] index. >> --- >> Changes in v2: >> - New patch. >> --- >> --- >> xen/arch/riscv/aplic.c | 33 ++++++++++-------------------- >> xen/arch/riscv/include/asm/aplic.h | 1 - >> 2 files changed, 11 insertions(+), 23 deletions(-) >> >> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c >> index febc451760..62bbcc9afa 100644 >> --- a/xen/arch/riscv/aplic.c >> +++ b/xen/arch/riscv/aplic.c >> @@ -335,9 +335,7 @@ static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask) >> static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask) >> { >> unsigned int cpu; >> - uint64_t group_index, base_ppn; >> - uint32_t hhxw, lhxw, hhxs, value; >> - const struct imsic_config *imsic = aplic.imsic_cfg; >> + uint32_t value; >> >> /* >> * TODO: Currently, APLIC is supported only with MSI interrupts. >> @@ -350,27 +348,18 @@ 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; >> + cpu = aplic_get_cpu_from_mask(mask); >> + >> /* >> - * 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. >> + * desc->irq is used as the EIID as-is, which is only valid for APLIC >> + * sources: they are numbered 1..num_irqs, with at most ARRAY_SIZE(target). >> */ >> - 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; >> - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; >> - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); >> + BUILD_BUG_ON(ARRAY_SIZE(aplic.regs->target) > >> + MASK_EXTR(~0U, APLIC_TARGET_EIID)); > Shouldn't this function belong to aplic_init() or at least in a __init > function? Moreover, this check is only relevant in case of MSI delivery > mode but I agree it worth checking as we couldn't know at build time in > which delivery we would be. > BUILD_BUG_ON() is evaluated at build time only, so there's no run-time cost wherever it is placed, and an __init function wouldn't buy anything. I'd rather keep it here, next to the ASSERT() (ASSERT(desc->irq && desc->irq <= aplic_info.num_irqs);) and the code relying on both: together they are what allows desc->irq to be used as the EIID without masking it. This function is MSI-only anyway (see the ASSERT() on domaincfg.DM above), so the check already sits in an MSI-only context, whereas moving it, for example, after the msi-parent check in aplic_init() would make it look conditional on the delivery mode, which it can't be. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:52:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:52:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449077.1665023 (Exim 4.92) (envelope-from ) id 1xGzOo-0002Wb-PV; Wed, 14 Oct 2026 13:52:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449077.1665023; Wed, 14 Oct 2026 13: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 1xGzOo-0002WU-L7; Wed, 14 Oct 2026 13:52:06 +0000 Received: by outflank-mailman (input) for mailman id 1449077; Wed, 14 Oct 2026 13:52:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGzOn-0002VZ-BC for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:52:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzOm-0045fr-H5 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:52:04 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf88fe-e002-0a2a0a5209dd-0a2a450baac6-20 for ; Wed, 14 Oct 2026 15:52:04 +0200 Received: from [40.107.208.24] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf8902-b7e8-0a2a450b0019-286bd01850eb-3 for ; Wed, 14 Oct 2026 15:52:03 +0200 Received: from BY3PR04CA0005.namprd04.prod.outlook.com (2603:10b6:a03:217::10) by MW4PR12MB7439.namprd12.prod.outlook.com (2603:10b6:303:22b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Wed, 14 Oct 2026 13:51:57 +0000 Received: from SJ1PEPF00002319.namprd03.prod.outlook.com (2603:10b6:a03:217:cafe::e) by BY3PR04CA0005.outlook.office365.com (2603:10b6:a03:217::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Wed, 14 Oct 2026 13:51:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00002319.mail.protection.outlook.com (10.167.242.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Wed, 14 Oct 2026 13:51:56 +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.53; Wed, 14 Oct 2026 08:51:48 -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.53; Wed, 14 Oct 2026 08:51:48 -0500 Received: from fedora (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Wed, 14 Oct 2026 08:51: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=RHOxZMo9JUTRvWHViujAdRJ7yPyr5hklYrNcWvMys6bCeesRJB5/KM0UROh7zmMvMGoy1htsZ7F55YSXFNtZjwdWqRTVRMwLNlBjl4OIk3L9zbxiZ0Ab3Nm04yCwltL06Fxb/Cd9yhutMF2QYe+98d3nv5pwQalAJ0EMQSVtiv79McRTC28KzTMZhbEBTBGxjfMUOqe2qcdE3vGH3D1KOz4DMMyULgfsLEeyTyQNPuDI8muUqP0dzIHCjlI2VpRCBhKFkjgDodggmo26Xxw4b+OgkkDUV3GewlLdYW1uAxdu7M1x7NeRSJnNPVl+Imwr7lnl8ymNc0iQANm8r94Qgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=F6c9/r8gSInDbB9zijROaTD3jrIXku1p1zRc+kW5mgE=; b=oNrjIwlSYGEEDEzpJxvEjUhjpG61tnMNEo/swDpzFvo9QdsDIwDuRvd1nbLQVhy4nlfgphIzpxUIKppfQLRd+lErocf5n2wyhtwYatSRozJSj66NPbgpUtW2nuTaSmII+2zIbv11I2hpBGud17/FsH6YkdhFqt597kvudHyHZ0hozKpCjC8VerHo5V2Xw26T55CBEow7sA18yhQO3U6Oco9dSmjGysirqs8zUJozLZ7cRYxkXVGWf/p/NK+XS1dcIfUionx9wUdyXm5StBr9CUUSZ2bYt3ZaNnXmZ6+aOa04kR5O6UBkbx+vI0lYrzxcKpJY/mPyQrDeO2tnVaG7Jg== 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=F6c9/r8gSInDbB9zijROaTD3jrIXku1p1zRc+kW5mgE=; b=rzuQZUGhpJOqs3jMphFv8N6uILqN5+/m2YPSkXtNR/1gWthydKfrYkir3MN9kyuFwCZmPh2jrsXshvHKlJXo8ThpCNgRnXGEheWM2/NU1tXaN5Ws/5oqQY5h883XDUfw2t1HJB840RLlFESVwrnBWZRZQSE3w9ktyhT38qKmJC4= 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 From: Jason Andryuk To: CC: Jason Andryuk , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH 2/2] SUPPORT.md: State that ATS is unsupported Date: Wed, 14 Oct 2026 09:51:43 -0400 Message-ID: <20261014135143.34220-3-jason.andryuk@amd.com> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261014135143.34220-1-jason.andryuk@amd.com> References: <20261014135143.34220-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002319:EE_|MW4PR12MB7439:EE_ X-MS-Office365-Filtering-Correlation-Id: 1542dc10-e4d9-4a0b-f090-08df29fa4fe0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|82310400026|36860700016|56012099006|11063799006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: bhio8yWOBe940fC0P2cnCVA/LXzZcIHcX3secaEbsBicllQHwvykknsb3dGna7PPJSIv4KP0xbzf3JHj2qgjeyc2q5zZ7PTJ3znzjuOPtucopTtNwkz9/O+ZSgO5VRV5dKzg24oXl/hqfN9/TxUHZN+uRRFiC2wbjyF71Izu5L7rpQptfum3xTecC1iqVD8vLVHIExhJmJ7cmB2iH1rQMvq3IGg3gzRuy61WvWdGAXUNlkgnqgtUrcqKHDcqfpsto3/oUozUgYh8aQVesANri5oOWBOrkszr3zmyAXYiBFtQHJMhmn9khMRT7sm6juanRXTDj1Bgqa/0DZTE4A/ARzli/g8kvOeXqZYMnYpOir3BtSys7ssymXEkQ3e2oB0vMYQjQ0/G9vj/f2eoTIVmj6+CDGvc3vUo4JDXD+2kA4wokgvcecrCD9LPLj96sM8rTzZaYqTmd1Xf12XIJOnqUhkeBZo8IyqnA+uHB0q4XnglXAQF6IBQetyACFDIeq6NUsYIa4PEnwwAcLWaZUU+NgZj+dSsq03o9VaJDq7gkLAcIXwnXS1q5dshPuAPhWV1nwNBDNZ1psPDIXmKYbuSV1ganaJFJoRVC+XzGfUjsDIht3bu2OxXPP2L4VBpBiqybxKwlDwEWqohtHkqRMGiOptObvLSPPbdE/ruNsuQNhXN/MhHwmfCAMH2Nw1mE9MtVABUGB3FhOY2jr1xbFCjtA== 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)(11063799006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: FJa5c1ol6mCbsLIcqgKU5mUbc1itrgCcAlzNGRRzUtxgAPDXWc6nT4J7tGvgCLGW/76EkFRqgLs37HmxC8d90JpBcyHapTt939uN66crY2C8Y7Bw8QS0H4DxW54jvYZM4jXwBO+dIoCEb5kuAhv39K5uz4JGbx4c3+DK7LgaSExkAbaiqEerFEgbHwVJyh1wi28ytjgXBnnK6fPW/1e9dM41VzvbIkbVJV39X8M7jEipkag7+VpieZdVHypoSn7C1dJHZUuLk3zmduU2a6k82iht2KD63wBX0mPwd6khmg0oKOjYywfZmhK02B2fBbPiNclzesqzAe3wUYBn+YdcB7yjo7YiA5SIco2qmJBLrlwfRGONlDgpG5rV6oKHLEB60db+FveB+CsP/VcWGwoKFGLxWhl7hGswQ3ZjrGIpgwkuETUUANCNAfPEN2ITpItR X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 13:51:56.7339 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1542dc10-e4d9-4a0b-f090-08df29fa4fe0 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: SJ1PEPF00002319.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7439 X-purgate-ID: tlsNG-42698a/1791985924-AB8D19EA-607337BE/0/0 X-purgate-type: clean X-purgate-size: 743 The command line documentation specifies that ATS is unsafe. Make it explicitly unsupported in SUPPORT.md as well. Signed-off-by: Jason Andryuk --- SUPPORT.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index eb07332462..8efab35004 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -96,6 +96,9 @@ For the Cortex A77 r0p0 - r1p0, see Errata 1508412. Status, ARM SMMUv3: Tech Preview Status, Renesas IPMMU-VMSA: Supported, not security supported +PCI Address Translation Services (ATS), enabled by the ats= command line +option, is not security supported. + ### ARM/GICv3 GICv3 is an interrupt controller specification designed by Arm. -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:52:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:52:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449075.1665004 (Exim 4.92) (envelope-from ) id 1xGzOh-00025k-77; Wed, 14 Oct 2026 13:51:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449075.1665004; Wed, 14 Oct 2026 13:51: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 1xGzOh-00025d-45; Wed, 14 Oct 2026 13:51:59 +0000 Received: by outflank-mailman (input) for mailman id 1449075; Wed, 14 Oct 2026 13:51:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGzOg-00025U-0j for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:51:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzOf-00CPBA-Dq for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:51:57 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf88ef-e002-0a2a0a5209dd-0a2a45018f5c-44 for ; Wed, 14 Oct 2026 15:51:56 +0200 Received: from [40.107.208.4] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf88fb-5984-0a2a45010019-286bd004b3ef-4 for ; Wed, 14 Oct 2026 15:51:56 +0200 Received: from SJ0PR05CA0130.namprd05.prod.outlook.com (2603:10b6:a03:33d::15) by DS5PPF016FC81DF.namprd12.prod.outlook.com (2603:10b6:f:fc00::644) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Wed, 14 Oct 2026 13:51:52 +0000 Received: from SJ5PEPF000001D5.namprd05.prod.outlook.com (2603:10b6:a03:33d:cafe::9d) by SJ0PR05CA0130.outlook.office365.com (2603:10b6:a03:33d::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Wed, 14 Oct 2026 13:51:51 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF000001D5.mail.protection.outlook.com (10.167.242.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Wed, 14 Oct 2026 13:51:51 +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.53; Wed, 14 Oct 2026 08:51:45 -0500 Received: from fedora (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Wed, 14 Oct 2026 08:51: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=Pbi09iRC1Alad0XkEFhMLWxtawn/1GsltDTQvaXUtmQUO1A7cN6/3VbsG2dWC8bzFL6aEItIzwun4FgNjy6Cw6/N93Az3bHTRn4Y3JmCYmKNJXmYdFb+egPmPV0UnOBdvoPiU8/CUDBinJTIdAItblK0ZiMG7FjpOsNAq6tVOBi/Yc8CfaneZiXFl1W/5bzPM1+zDyb+R1kdy6Lt9pQMxtU5NrF+yf22rzoMHiLb2NaWZFQN6UXCKesPe4n+tmbAu01Q1mXhyZHCt54g43FRdLLVxLeCyeEWZNFP5csNrVOfwWpdWA+kPiv//cl1FEMrJTYe805ozRkCRQITIbp2Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TAum0bynBk7VkXbGBDywK+sew5/0kT8vJpsI6r9G5SI=; b=WbAL9Q9CW2MM8p3rCvizJClY+xYg3TouIJ1/B74bP3cUEONuj5o6nIcbaywN2UQQaVQsjc5OYZ2PbyDyiHtYm74it3aRaOU3NHw7l8Ryue/2zJ0Ft/l+N+qUUHVkGjASZrdNk4yHR/Vi6bwhY8NTg3MgjFQgfUm7hYVKEvfELKFBBI/vrPEIjBMm7LCyyyw8GtmRY9YFZ++6m/xw5Gbm01lMb4IakCnGm1xoDG28o3IIMPgeNAdKx/z4BfycQ5Yvyq6Vxl6IMFFsksfPy+4RiMTAZMBywj7ep3D4jmNj+mz2GAtQ37KA/Ai8dIXg0x3BeCRWKGa3nZf/MfG2EBOVvw== 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=TAum0bynBk7VkXbGBDywK+sew5/0kT8vJpsI6r9G5SI=; b=ZhL4ssDUxWdwYzWoSuQURvsv5qVYgzY9x2kj6cHewHQOPss2VrVJ/jIyh6Q5f5hLeMfK6Sbrax70i1mu9pupTABwjJqdzvoP9N55X2ErF8Hbc6VI96b3nbnWOfQmvh0BGD+9W/AS8RclI1NjPy9q1v4n207Ja1b0Q6am2olHJR4= 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 From: Jason Andryuk To: CC: Jason Andryuk , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , "Michal Orzel" , Julien Grall , "Stefano Stabellini" Subject: [PATCH 0/2] amd-vi: ATS fix and SUPPORT.md update Date: Wed, 14 Oct 2026 09:51:41 -0400 Message-ID: <20261014135143.34220-1-jason.andryuk@amd.com> X-Mailer: git-send-email 2.56.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D5:EE_|DS5PPF016FC81DF:EE_ X-MS-Office365-Filtering-Correlation-Id: 4a713031-206f-47a3-7d42-08df29fa4cea X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|36860700016|82310400026|56012099006|11063799006|261009223027099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: K4uR+xg/mKiVEBs0B9eSkxoD5ZAcaNW2mbZ/+EEcllV+IAzbmicF+eKcTztYJgAQOZ+G3sXV09wU3DnAg98QnDKC6nzPrWwTXaEPEPqMrGdU0kToBfmN7Eph7vrXORlmX/aGpon4dZoyN5q3Gfrb+T+KH20TUz1Bzv2lU1wkMthIGKO0zPfcgmTQQ+w7S/S62Pt5qPZMZQGryAMW+X5JGawQSVvTf6Su6sq4EOkIqxkwJR0rqnD69msUPpqAC/hmwNuwCPseC7Oaw6kS7ZHfJ5qevCOfyMmEjHsmohm5uKTzyGj74B/1i0EvvWFMY7KBL1ybFtapl40s4Ox85DNp0i+f5P7ul3+eHYOmWaziLUaWmuDV1RcZGH4m8tHDDMKEiR9eB1kL2jGH59pzmkSbEVmwXHanNLhoi+6MuNKF1JpqmXjSp9eqTEDd7J0fEVsTou49RqHB7Mf44UNfCbcC/EHctR7xFP6h+hW+CKsZ8M0qu4P7J9gPA35U/yDPkGFwPMLgzLye9pSY4kJf63JdLTE0/2y5fnRpYfHIYSeiVbIh2mp9J7T22ylwijLp5s3iFCA0i+n9DmlaBeWae5L8jhQatAGCRyiDHLzuXfeOeF1HprzduaAC7wJ+bo11JxyTHPqr3y+csS/RVLg7Z4yCbFfUNX0KeLJZv/gNdvBkORvvk320URBA3DhgeGfRWf2esmN/xUvMpF7ZtZKhMZi3AA== 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)(56012099006)(11063799006)(261009223027099003)(18002099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Ppog9jrCagQt+P+fRr4XLNDAdJIv0UT5Ti83h5wACHubo6urCvibCsu4K7Gh3rNeJ1DxoLiN9s18ymXt2yaH0NGq6apKwUpLqDzPQqWQQDOb9fcWEF7Sil0gCTrs8qpA2k4XcpqoCJuR4oGqcXxPq35YIgnfOhb33T+wtEsGsEYfbMfg0i5Wx6Vxns1uezx7mvUcTOxMVOKuyHV+4WECzDdGOTlfthC8/nuN4mV1C+rQ6OzzjxzAB9R9AO+ZPRc7dVmdewFed3qutMu+OakZ6IPDLaTwvdCIP6yXsOnyIE6RDZcRMILgs4PcglosTCiS7U7JDWgsGPD/eLCKc0DkzHMwo1JnpegCaO5Y59Y1uixf/+cKDdtKQ9Q0h/AZ9kNiUnxz4kqlvVBGF0EPqLBZoJYzssZP6Sd+hd0zPB1mfD/cubOC8nrj49HEV8dYVJ+5 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 13:51:51.6362 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4a713031-206f-47a3-7d42-08df29fa4cea 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: SJ5PEPF000001D5.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF016FC81DF X-purgate-ID: tlsNG-d62444/1791985916-BD146757-2BB13F2A/0/0 X-purgate-type: clean X-purgate-size: 411 Fix a AMD IOMMU bug in ATS and update SUPPORT.md to state ATS is out of scope. Jason Andryuk (1): SUPPORT.md: State that ATS is unsupported Stefano Stabellini (1): amd-vi: set the size flag in the IOTLB page invalidation command SUPPORT.md | 3 +++ xen/drivers/passthrough/amd/iommu_cmd.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:52:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:52:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449076.1665012 (Exim 4.92) (envelope-from ) id 1xGzOl-0002Ia-Dl; Wed, 14 Oct 2026 13:52:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449076.1665012; Wed, 14 Oct 2026 13:52: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 1xGzOl-0002IR-Ae; Wed, 14 Oct 2026 13:52:03 +0000 Received: by outflank-mailman (input) for mailman id 1449076; Wed, 14 Oct 2026 13:52:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGzOk-0002I7-8m for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:52:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzOj-005hEH-LN for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:52:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf88fa-8faa-0a2a0a5109dd-0a2a4504a884-16 for ; Wed, 14 Oct 2026 15:52:01 +0200 Received: from [52.101.193.0] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf8900-b57f-0a2a45040019-3465c100edf0-3 for ; Wed, 14 Oct 2026 15:52:01 +0200 Received: from BY3PR04CA0021.namprd04.prod.outlook.com (2603:10b6:a03:217::26) by CH3PR12MB8755.namprd12.prod.outlook.com (2603:10b6:610:17e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Wed, 14 Oct 2026 13:51:56 +0000 Received: from SJ1PEPF00002319.namprd03.prod.outlook.com (2603:10b6:a03:217:cafe::11) by BY3PR04CA0021.outlook.office365.com (2603:10b6:a03:217::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Wed, 14 Oct 2026 13:51:55 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00002319.mail.protection.outlook.com (10.167.242.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Wed, 14 Oct 2026 13:51:53 +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.53; Wed, 14 Oct 2026 08:51:46 -0500 Received: from fedora (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Wed, 14 Oct 2026 08:51: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=poryjatiZUG+UBswC6xe/NFumxaJbjNRM91jIfZbWyuFvgfVhkfWlqmWKgMmGEl0IE4Kx2GF/aD0yqmSv/VhwTDxj/TqGqz9r5Qn6iIDfDZvYy1VB8ifZZRM0xDRtDWvmCQss22FdQOFUQcABSL7NyAknwjlHwH3EPZyYq4BhYmiJcmLYsFJ0mWTDXtKbVUEE7nN8Rc8mSzbqDg/jzwjveZ6m/OyFeghhVCO3r30LRhZYm1N2e0u++jzBVSLofkioLbIA33NxeuOqtNPwL/VTfD0zhLuQ5j6+hhpDatzLuTT9ZUsN407tAuZL8aVKCllIZA9TzUR+EsU1VWGE6YY7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=63JVV+iMj3kFDQfc/Papuas4qCGoPPdfcLCYLdJ7awI=; b=r4LkB8ci6jKKKMKNcf6BsdZFVbnzdUVVvPPnvoflyPC9nChgF7Wy/mEf3oJuIMIdNOzgh+SWdw/rk/zn1lUhYX5DMS2jWnXEYj5l0h0vxZ2wdqzacKGTFhaZokAa9TGCgS1NEZ5zMpluugzKkyFLDUYd6BjTyLURlh+Mb1G7lumXFwjOBaluMo5PBwA5GMG2Z79gZhFDv48zkqFa9Z2EN6A8urgf98T87LbTEhfFBgOdaDKmFvUA5zMVI3EALnNTS2UN0kCnBKyOHtWJRvm6xAuvyZun+ESHmyTz3hYR+J8xYBXo8cup7oZqERImmqEF7c3MgDuqOkwHjp3lKPLpPw== 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=63JVV+iMj3kFDQfc/Papuas4qCGoPPdfcLCYLdJ7awI=; b=ik6TINIs3ucHpmO05olDoTnY1nJwCQWZbdWhnA0Og1pe5atOJa38hUPVpCWqiPF9mZDEABEhSACWOWukxmZnSINqz75Xd95c+25WHrSrrJwWx8XkSUi/naYyN8kUAGjv45t9X8joGgFQk80SVxxjsPF8HJH1u1vkX5CQpjXpDCU= 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 From: Jason Andryuk To: CC: Stefano Stabellini , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie , "Xenia Ragiadakou" Subject: [PATCH 1/2] amd-vi: set the size flag in the IOTLB page invalidation command Date: Wed, 14 Oct 2026 09:51:42 -0400 Message-ID: <20261014135143.34220-2-jason.andryuk@amd.com> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261014135143.34220-1-jason.andryuk@amd.com> References: <20261014135143.34220-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002319:EE_|CH3PR12MB8755:EE_ X-MS-Office365-Filtering-Correlation-Id: eb5bf6e8-64b0-4474-e401-08df29fa4dff X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|82310400026|36860700016|56012099006|11063799006|261009223027099003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: OMUmvUAMUpqgZ3r7dyixh+AIWkkWWebsdZDpe/hEfmhBrTCSAdrgCVbvX6l46rA21/KaMrPLStCECRTR5stf2qtEuqq4qZOK4BPG+piQu3QvcGmaF2FkhxWvIB1uwI4oKqoj7RP8xjMd22STOtBIkkDz2n7zSBZPCgur+7K0cRDNpqtUCQI7EAs1py0gPRVqo4b3xMz0EZxnOvzkVNIT6R1j+PmRckKpyZldJpt7CK/IdYETjDqwylbG9tioHvsdpdEyN8yErJODbuggsbY2yXsPh/mwRolH6jGdrrdS4XLqOZbhGAZ1QYlFk0i9qC0rna0hNr+EmiocH1SiHNxkHtDyjO9AjgB+h42PrDbVvNiuVSirNHHXVbnXtIipwAnnps0IvSTNKxCflT3gnHiRJ/cPNoJWKLHz0kXtKgeJj9fksgV8JvBHcQrp9cNjBaeE2ssw37oF3fE1TtbeuwjxRGMT8FehJrkM0iSr/sxU207Lr4jMv2toj9GI8h0gGM3nSGG0MQlA86JFZ6UFilX6DZWmZXj0inrf3Dyfr+a2Dcl3DnaZplF2bsoGy4EcBDjHtSgphRb2zDEzSpGuXSyemwz3dlthSjcKLlgY5lZysjFSZsdH7nMWZAYKvGmFsjSVVbJJQaBTJskRUnE7DfVf5beeyi+JSUTkg2H9qhB++y+JRPFfK34+vS4wQmSBg2elUner0JHcIer+mX1tiMlOUw== 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)(11063799006)(261009223027099003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: CtKBf6oPJ5P0QrNh6L9Z9itPr/2uIOgZo2V6nAim+9TseLbQJzGddobL2x2suwR1AFvCx5YtiOXV7J3XCfWZILs3YDA7x0gI84kX+KV9CnhV9V3EqesRhvC3hDpM2RQfENnyGhMuzPOMjEHG4B7wxxkxNg0P5jx5xr+XQbBnDANHZhbmuIO2uERXOfpKIBvDfOkWFo0t/dE6YShvDrF4ikRHxwkscY+bHnE+gwDkxJAo6VNNI+p29Fc9ZyONYH+FPN7yP2gbJ6OlCsnKvW9pVxOAW665KZr/xc4bCySnIanbxo59j5t9LBJUP+Ve91laxXxY1XS3iASIHk/oz9hLQTnj4bEgK0yi9Hpo9JTI7xmFYOhx0/iHZcQEW75Uisb6C1j1YLoq9dmFi+YcmwoygyzMQcoTJWHPXdWwF1x0tj9/VoM+wGFiwv0K4Z2AwZAc X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 13:51:53.6417 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: eb5bf6e8-64b0-4474-e401-08df29fa4dff 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: SJ1PEPF00002319.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8755 X-purgate-ID: tlsNG-ebf023/1791985921-538C1B50-680456A9/10/78276251493 X-purgate-type: spam X-purgate-size: 2157 From: Stefano Stabellini The S bit of an INVALIDATE_IOTLB_PAGES command selects between the two sizes the command can name: cleared, the invalidation covers 4 Kbytes; set, it covers the range encoded by the first zero bit of the address, counting from bit 12. invalidate_iotlb_pages() builds that encoding whenever it is given a non-zero order or the all-pages address, and then passes the field's mask where set_field_in_reg_u32() expects the shift. The correct mask is 1 and the shift is 0. When mask (1) is passed for both, the value is shifted out of the field it was to occupy and the bit is left clear. i.e. (x << 1) & 1 is always 0. An endpoint holding translations of its own is therefore told to drop one page where it should have dropped a range. The rest of the range is kept in its cache after the page tables backing it have changed. Pass the shift, as the sibling INVALIDATE_IOMMU_PAGES builder does. Signed-off-by: Stefano Stabellini Reviewed-by: Xenia Ragiadakou [ Reword commit message. ] Signed-off-by: Jason Andryuk Reviewed-by: Jan Beulich --- This was submitted to the security list, but it is out of scope. Xenia reviewed internally and Jan reviewed from the security list. xen/drivers/passthrough/amd/iommu_cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c b/xen/drivers/passthrough/amd/iommu_cmd.c index 665e882a2d..abfbdf2b28 100644 --- a/xen/drivers/passthrough/amd/iommu_cmd.c +++ b/xen/drivers/passthrough/amd/iommu_cmd.c @@ -212,7 +212,7 @@ static void invalidate_iotlb_pages(struct amd_iommu *iommu, set_field_in_reg_u32(sflag, 0, IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, - IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, &entry); + IOMMU_INV_IOTLB_PAGES_S_FLAG_SHIFT, &entry); set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry, IOMMU_INV_IOTLB_PAGES_ADDR_LOW_MASK, -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:52:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:52:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449081.1665031 (Exim 4.92) (envelope-from ) id 1xGzP3-0002xe-W7; Wed, 14 Oct 2026 13:52:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449081.1665031; Wed, 14 Oct 2026 13:52: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 1xGzP3-0002xX-SU; Wed, 14 Oct 2026 13:52:21 +0000 Received: by outflank-mailman (input) for mailman id 1449081; Wed, 14 Oct 2026 13:52:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGzP2-0002wQ-L9 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:52:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzP1-004nEZ-RP for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:52:19 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf890f-2eae-0a2a0a5409dd-0a2a4501daf8-12 for ; Wed, 14 Oct 2026 15:52:19 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf8913-5984-0a2a45010019-d155dd2dc968-3 for ; Wed, 14 Oct 2026 15:52:19 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48b0946c2c2so2666092f8f.3 for ; Wed, 14 Oct 2026 06:52: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-48de72c7e36sm6598086f8f.37.2026.10.14.06.52.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 06:52: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:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1791985939; x=1792590739; 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=ezXCXUWK6SsuGyAG3eCrrjeZLo0IOueiBha//yJ648E=; b=AkOp2IbatdOIxPHvT41Tae/fGhhsDq4QfyhRF6DxOQIjmMr87lzjWrmaOOaoCf8ZWi ioIl0T9021zuM4k4+8XD3QMjctNS7T+ZWZLy/QJoT1vKhvxSZbYtCyIrB4x5zIN/x6wI v6ELOyuCVE8qN8U75lnYs6pxgE2m9rEBY322wUPC3ckYMc5IPmtoVX0U2nnwzDATAb2Z tWkVrp17ynYWNXaw4cAn8b1hz6DI7fm+EYD7FFPgR9mn+Q6Egw5dM6JquJWHaqRq2zM9 2s7m3wID4HMwyGnrNzk2Wk1KXi/MijxiaT8nigKWG1AXNpccB72anftxALSBzWhG4dbJ HyPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791985939; x=1792590739; 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=ezXCXUWK6SsuGyAG3eCrrjeZLo0IOueiBha//yJ648E=; b=vLJ5+M02njBk1kW/ukJSRX6P0KPz1uEzeQTjVopkDcnQ8wjU0NmYc66udIClGhXgip uwlZIENeqF4qvfr3z9SJ7VVwVK0y5K90+E0O1ktPCytfABLzvjSnbhksBiHXctwYyRyE WOU3fNaSKPi3/fo5Vxj1nlkoNB2cDqKDB5277Quf6Ktwyismh8HgobYm8YMhhDzAHhTk cVZnoH7kDmYKY/FOVvi1cgv2/i3r0xiun9ReTTOjfe1agzlpzt3/h9l7lSrkMcAkCe2Q avo0/30n7nb3QzN0ghbFq7IUCXt57cDXV0imaGSKAEhAwgycZdcA4tuKQopQ50VJa2di aFnQ== X-Forwarded-Encrypted: i=1; AKwUvBwCFJIkF3bEqdcBSAl/ivz6NSSHmyMn9O5C8Oy1vvkYI79izC6SuGhf8CB3+McmxVj0KS/jPFQbE6c=@lists.xenproject.org X-Gm-Message-State: AFq9FYIm78EDm54Wxw5BPYk7BEQMiQG4CyEfO/SEhKZnlZigv3PBisbl tCGpGhZPh+4mQ/OEKXAfF2KGk5igVTjQIOJBnycPM6fdmjUDL6inNuzTEzFAmgb5hg== X-Gm-Gg: AYBFou3YGr84eTyvsl0Lcv9dnvE/8UnFiRe5lmtjxv/UG0LUlysoGBfqVQ7iYev/loK WOwvUMqiAO+Hc7pLbK1F9UPWmKv9LpjzdQWdWQtAobBCi2WFwNVH4shGQyn93dbi/SRFGLxAXWn MzZnM2UMRyugicNrZx6vQvwWoz4HqfNA79xi103N8L6cTpmkoS954o7dBoO3WI194blYIPHdf+5 ujYzAe2I1q6KOttfvn+qwSh3HNX43A9sxlqKXxENURvnPmn0qUtokkSU3Q9Y6xHI+v1Osu1Cgpd BqOV7J2fOBOB8DcD7/L/Ct3uVFdO2xZ22wNOGHqjEz5mxDajvfEBvL26JnOTAGa4rVs92gzW23z IpAc5+XM6qsoTymZ/KLtzT2JOd3AVYCUABkyMMqAdfgK5qLBnfHgbBzj+eK3j8VDL1/EaA5IYY2 pA6LLxruPGDsnrZvlz7ZWBtbgn7q+WjnGiE5h8L8nW+f73i4c3omaiJVfSeWQ1QnBjkrjNUQI6W j/wMlecj7za4AwSl4SpdRPtzT1f93hGbT9PGFnlmJ6aROu/WWiTQWBqI21La9KlYvve2uBD X-Received: by 2002:a05:6000:2dc1:b0:488:8850:50ec with SMTP id ffacd0b85a97d-48de2b4d7e5mr10736800f8f.46.1791985938638; Wed, 14 Oct 2026 06:52:18 -0700 (PDT) Message-ID: <6de1f79c-2e2b-4794-8eba-ad7ac224d24d@suse.com> Date: Wed, 14 Oct 2026 15:52:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/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: 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-d62444/1791985939-1D67C757-82538338/10/78276251493 X-purgate-type: spam X-purgate-size: 13595 On 30.09.2026 18:18, Oleksii Kurochko wrote: > --- 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 > @@ -58,6 +65,12 @@ > #define APLIC_SOURCECFG_SM_EDGE_FALL 0x5 > #define APLIC_SOURCECFG_SM_LEVEL_HIGH 0x6 > #define APLIC_SOURCECFG_SM_LEVEL_LOW 0x7 > +/* > + * 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) You don't drop any bits here; that would happen at the use site of this constant. The comment would better be worded accordingly. (The comment a few lines up, for APLIC_DOMAINCFG_WMASK, is better in this regard.) > @@ -89,6 +102,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 direct delivery mode (domaincfg.DM = 0) */ > +#define APLIC_TARGET_IPRIO GENMASK(7, 0) > +#define APLIC_TARGET_IPRIO_DEFAULT 1U With this overlap of bits with EEID, should that one gain a similar comment? > @@ -98,6 +114,24 @@ > #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) As previously indicated (perhaps in other contexts): Pairs of masks and shifts are almost always ambiguous. Hence why we have MASK_EXTR() and MASK_INSR(), requiring only a mask: The shift value can be derived from the mask. > --- 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,313 @@ 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.sources[irqn].target); > +} I wonder whether in cases like this one, where you work with guest controlled array indexes, you wouldn't be better off using array_{access,index}_nospec() right away. > +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_DOMAINCFG: > + { > + struct vaplic *vaplic = to_vaplic(currd); In vaplic_emulate_load() you have this at function scope? Why do you do it differently here, despite there being at least one more instance later in the function? With this moved, the oddly placed (yet still style conforming) figure braces also wouldn't be needed. > + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | > + (value & APLIC_DOMAINCFG_WMASK); > + > + return true; > + } > + > + 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 ) > + { > + gdprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); > + > + 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 > + * 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; > + > + break; > + > + 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_SETIPNUM: > + case APLIC_CLRIPNUM: > + case APLIC_SETIENUM: > + case APLIC_CLRIENUM: > + case APLIC_SETIPNUM_LE: > + if ( !value || !AUTH_IRQ_BIT(currd, value) ) > + return true; > + > + break; > + > + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + /* > + * 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; > + > + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) > + { > + struct vaplic_source *src = &vaplic->regs.sources[srcn]; > + struct vcpu *target_vcpu; > + unsigned int guest_hart_idx = > + MASK_EXTR(value, APLIC_TARGET_HART_IDX); > + unsigned long flags; > + struct vimsic_state *vimsic_state; > + > + 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; > + } > + > + vimsic_state = target_vcpu->arch.vimsic_state; > + > + /* > + * 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. > + */ > + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) > + { > + printk_once(XENLOG_WARNING > + "%pd: vAPLIC target guest index != 0 is unsupported\n", > + currd); > + > + return true; > + } > + > + /* > + * src->lock keeps the stored copy and the h/w register updated > + * as a pair. > + */ > + spin_lock_irqsave(&src->lock, flags); > + > + write_atomic(&src->target, value); > + > + /* IRQs are already off under src->lock. */ > + read_lock(&vimsic_state->vsfile_lock); > + > + /* > + * The h/w register names the hart and the guest interrupt file > + * MSIs are sent to, and there is none of either until the target > + * vCPU is given a h/w guest interrupt file. The stored copy > + * reaches the h/w at that point. > + * > + * TODO: once s/w guest interrupt files are supported, a vCPU using > + * one still needs its MSIs, so the h/w register will have to be > + * written for it too, pointing at an interrupt file Xen receives > + * them in on the vCPU's behalf. > + */ > + if ( vimsic_state->vsfile_cpu != CPU_NONE ) > + aplic_hw_write_reg(offset, > + aplic_msi_target_gen(target_vcpu, value)); > + > + read_unlock(&vimsic_state->vsfile_lock); > + > + spin_unlock_irqrestore(&src->lock, flags); > + > + return true; > + } > + > + /* printk_once(), as a guest could otherwise flood the log. */ > + printk_once(XENLOG_WARNING > + "%pd: vAPLIC direct delivery mode isn't supported\n", > + currd); > + > + return true; > + } > + > + default: > + fail: > + gdprintk(XENLOG_WARNING, > + "Unhandled APLIC write at offset %#x (value %#x)\n", offset, > + value); > + > + return false; > + } > + > + aplic_hw_write_reg(offset, value); I continue to struggle with this passing through of writes (reads are passed through as well, but at least those don't alter state). Aren't different guests going to interfere with their writes to setip, clrip, setie, clrie, and apparently also {set,clr}i{p,e}num? > @@ -95,6 +403,56 @@ static const struct vintc_init_ops __initconstrel init_ops = { > .make_domu_dt_node = vaplic_make_domu_dt_node, > }; > > +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, > + mmio_info_t *info) > +{ > + uint32_t val; > + > + ASSERT(v == current); > + > + if ( info->len != sizeof(uint32_t) || > + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) > + { > + gdprintk(XENLOG_DEBUG, > + "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n", > + info->gpa, info->len); > + return IO_ABORT; > + } > + > + if ( !vaplic_emulate_load(v, info->gpa, &val) ) > + return IO_ABORT; > + > + /* APLIC registers are 32-bit; zero-extend to the guest register width. */ > + info->data = val; How do you know info->data has the size of registers as seen by guests? Plus, how does this matter anyway? You reject info->len being other than 4, which means the originating insn will necessarily have been a 4-byte load. What happens to the upper bits (if there are any) depends on the behavior of the insn that's being emulated, not on what you do here when storing into info->data. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 13:58:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 13:58:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449102.1665039 (Exim 4.92) (envelope-from ) id 1xGzUi-0004Si-MM; Wed, 14 Oct 2026 13:58:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449102.1665039; Wed, 14 Oct 2026 13:58: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 1xGzUi-0004Sb-Je; Wed, 14 Oct 2026 13:58:12 +0000 Received: by outflank-mailman (input) for mailman id 1449102; Wed, 14 Oct 2026 13:58:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGzUh-0004SV-Kh for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:58:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzUg-00DYWb-UR for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:58:10 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf8a60-8faa-0a2a0a5109dd-0a2a4504e1f6-46 for ; Wed, 14 Oct 2026 15:58:10 +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 6acf8a71-b57f-0a2a45040019-94a39b0cb9fa-3 for ; Wed, 14 Oct 2026 15:58:10 +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 69E7wO9p3014631; Wed, 14 Oct 2026 06:58:05 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021074.outbound.protection.outlook.com [52.101.52.74]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4h9pvvu4jp-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 06:58:05 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DS4PR02MB11308.namprd02.prod.outlook.com (2603:10b6:8:2fb::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Wed, 14 Oct 2026 13:58: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%4]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 13:58: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="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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=bMjWdRXxtjv4GFn65tABCCzXTinBZVZXyMVJ/CljQ 8U=; b=qJ931WmHysASO20LE0mdkczIdZS04aLfWroSJOM1t62oVDD3Nng0Aztxy QLBoElTXNr1ms7x4PI5oHBBi7w10kl1m3FggBNW7WeEzDpVSY6cEMqmiTBQ6ICTW 7ft17K4O9bzEt/Dhs78zivRbK29y7GAJmwEQ8CvVdZH4HiI5SjPbxSkQ+NubF/I0 GX89BxR03AR0XXucTCxZADxJsNySFGgjMnn7KwnWUzEOpVXwpZtQEMwPHf4sHwPL moBp2sLDgpqTe5Xf57d7TEhQObrbLR07w5zQ6KjOrxeVKv+R13BxqA4Add0mJAWS BwS5ZlKyAKbRMaZl6GBnQbQKM7wdw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hYgWnoniDCEscDx4VTpjnlnVamlYOf9HMMxYEXg77J5FcleCSZr1zNRyX3LYxLfsAqfvyI0y8wQzYJcuTfxDLb24RRtUjWxB0au2O2wQ3LKxVZYOSATxO19oz495GbyvcX+Q7B4QsZL7NrzrZyxN6bQaFSduSnYyMfkKGFSwbfRLa5Ark2ERRYZLDdLvFswuHtCYkeN+0ROeOOaK5F7HJzpAaXG8Ub7Ce2KQ+ciIFEMr1Pzg0iSitRGppUeYPQBw3oSUZRw6y9/Sq76r0wmQlxxxDfsNXe8+gHQt5u+1n8RWvqcV3vWb+/z0ZXkF8WJiu7owIDQ3v1ZOy/lLFTUMQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bMjWdRXxtjv4GFn65tABCCzXTinBZVZXyMVJ/CljQ8U=; b=PpAaXgFmIXluqyDOwb+6ons4wGSNxgrXPM1RcBit0KMkSFmFdeNTZFKk/CCarZN8a6M7Zt+tD4c+X/rfUF9kjkcRy/nsuiH4W/coRuFVWD4yfTutY/BxVu26fmbFYQxaKii0whkEbKQ67w6MXz66Cl+gDCzUSGW7O7Tt2Pf2ccH6TgMzbrFm1C8KpCSX3YfcaYaGyJKbiiaUjDQW9AJSn+Au6LNci+wX3TF8yi4NN0chkqt3f9E04hOyPGAPg3ZyiPTVUVC9qExSX/YI2ktvGNu6qUSOpG1Nbgd71cn9poxLPwL4jLhpLmXiQJfevZilHsBVMFPLJxFusRKWLoz3IA== 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=bMjWdRXxtjv4GFn65tABCCzXTinBZVZXyMVJ/CljQ8U=; b=prlflYA5xKbQXY4uXcpyrpWa3MeoRN4GB0FIK0Ve/RX42SAZe9BSoJYv1Fpz/9xeCrnrQTpYWC1zPwrbhdUtfXIzDP7Ky3w1qaxCnAmiIChvqyhLvRDzlJyLcU/Gv57Lt+wZPDfeU8p7y2w+tj4m/Ns8oozYzCbhzdFmqaLJjIzp/Q6KDhon+vBjTGiBo2qXJxC/Iuakc5U75C12evuhaVCx348DZCAfH3zHT7f8MRU8h6d9lxUlKLYfe1IVnBI6PeOQmERtMCWaV7bPr9EzFi0wTrXGTNfxPwfaP8NAP3oGPuX7taiAT186y/xHJtud+I88d6YdnoO8Tnns817yZA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: Date: Wed, 14 Oct 2026 14:57:57 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/22] i8259.c: move parent_realize from PICClass to I8259CommonClass From: Mark Cave-Ayland To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-6-mark.caveayland@nutanix.com> <876b66cd-0ea6-4943-9a0e-c0abf2ad6e26@nutanix.com> Content-Language: en-US In-Reply-To: <876b66cd-0ea6-4943-9a0e-c0abf2ad6e26@nutanix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR03CA0210.namprd03.prod.outlook.com (2603:10b6:a03:2ef::35) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DS4PR02MB11308:EE_ X-MS-Office365-Filtering-Correlation-Id: e4d88314-ac09-45cf-0f59-08df29fb2a6f x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|10067099003|18002099003|22082099003|261009223027099003|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: DiFS4kpry1GkAWUTN2v56O5lYV0OrhIJ6fixToVLMqjTdjkUCrTia2rIHJ27aTmRakIadydFcvxpxGkPsr5HYx1y/rPNEqbak4ffVOmmbiSiAWolc3XciWM/tfzAQ1n9tDSu1sjE2a70TJKGl7EkvUkMLqN7xvzLFkL6O1rDCVhlARb+g7sJj72RZXkYmw82MNARCwmubWJK+EDUw7Tskm/AVVK8jprfswGpDFff3TtaGLe5bMuS6bKolW4kTjAOYf8wZ8WetmMywwGDb5/3gOVbmwrZfe66sFXj+jHGigb2g2MAm6jiY5m8swh1y8Y4dmvNjqHuqDUi31FfX9Ywi7wJitYCckhsT8KY97BYL9KQIfZRt/+kR6pL5G+alwlhRCeT0dXJTfUbtJm8nI5P7uQqnge4LQWbH7E+BQk+SLhu0uKWPgO6PeFPX2V7G1MXb7lRdFEDIdXaMh1TcD+yNMUhIrSbIBNSWL1VL9z4U4iVl2g/GFwxqBRXiyAKWlATPeHwCy1+f7kGImg4U2b1GxXMoBwaKq8tcqtCgVDndj9tZLccgopdQGxSLFGObXEoGBEdrckh7eOxubSuUF3fpirqWHmUTNdWKlZOn2+3Ohw60BDiSzLAdJTwZSzG1BkswXjB5pFFJ5N6I7AaCt2CcnR9WM/4T1vdZCwdx8yGcOg= 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)(23010399003)(376014)(1800799024)(366016)(10067099003)(18002099003)(22082099003)(261009223027099003)(4143699003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eXQ2MUxuQlVJTFlkZTZ4WW9hQTY3MXdZY3VFUitvMXBjRzUxclNuNDVycTFS?= =?utf-8?B?cm5RNXM3U1FmUHRLWDk1dHU3QmtTOFBhajdKM1lGMjlvTHdIT1QyODlOSFdm?= =?utf-8?B?cUpKSTNsS2g2NFRhRzAzUThJZ0NtMFdkVkw5eHF0QTFyUWx0bGxRd1A2RVJp?= =?utf-8?B?TkQ0aHltdkRHQnFibmRUcmZjc3RZZkUrcUdMQnloVlpDZ1dxWjBjM29RdFJL?= =?utf-8?B?bnBvMTRkTmpvaFNyYWt6UFk1azMxYVF5OFdNeWJEeXJ2VDVTVXF3aCtDREdB?= =?utf-8?B?YzVHbFBjZE1hd3FMYkJobTBKRHF0NGxneGZkcjBPa25qd2VPNVdNYTd3TGFM?= =?utf-8?B?dk5zTUcxZ2srbEwvQ2lVWitGUVgzTVh1MDFJZkJOalo1azIrSDRaYWErL0RH?= =?utf-8?B?cGpUekRXTXJKVnVSS1hlOG9IMzUrZXF4TDMvMk0vVVJoTFNxQW0rbkNza1Nt?= =?utf-8?B?Z0pLbTJFOXpwY2lTQ2RGdHFUYnBrTDh4L1lFUWs0NUdKakZUblEzNFRRbjgw?= =?utf-8?B?QXcxaG1SbGsvb2lYUmhEZXFjT09mUXkyblFTZXNwNjAwUEpFc0ZPR3JDZ2pN?= =?utf-8?B?NVVVWGFteithSG5pUE5vUHVNVlVNUWFHOWVQUnRQNFFVVzFTbGhmSTNIa1Fh?= =?utf-8?B?MkN1c0h5UzhtTW4zUWJweEV1NjRTWjFlWTNJek95cUUyS3FjOXhycGtvMmZy?= =?utf-8?B?UllsSytsY2RUY0d6MnpqbDlkT0ZLYnZxY0pGLzNRTG5CQmVBTlM3Y25nOTMy?= =?utf-8?B?V1pxTmNnQk9ET2U1QkJxSkNjWFhJeXYycXhKTHBhOHNSUDFzWkszZnJzSlRq?= =?utf-8?B?VXdEanBuSS9sUjRRYUtsdWdBUlZXSWdVcGdFVllTTVJGRkRVUXV5QnROOUUz?= =?utf-8?B?cWgxcjBzRUlnQ0d5ZUxWakdTeGoyL013dEI0YnRWVVJGL2FrVzBBSU9DZHY2?= =?utf-8?B?Ui9LeW80M0RMTCthclU4QkpZOFRNUm93R3NkNWd4YnQzUVB6RWE4UUVhVXp0?= =?utf-8?B?U1dTNm0zYU11aTUwaEFNVFNFYzRsRjJoUDJvdHIvTEJRZDVndGdPcDVzZDhN?= =?utf-8?B?TUROanEzblUrNWRURFlaSmxrS1c4Z0tlYW9kZGpOcmMvckhObjM5aUJYdGRk?= =?utf-8?B?eTdTQ1dUU2lVa0VZYUhneW83cGRoRHNOYTRWamtXZ25lNnU3d0ZBT3VBZDRX?= =?utf-8?B?T2xTOFNzdlVVb2N4US94b3pVd0VRSFBVQ2dPV0lWcWtEZ0pycW9ndDl5N3Uw?= =?utf-8?B?NnVqcGZKWjJtRmZpL3Q3ekZtdDBsTkdDa0NOYW1TcW0xTkRycWVPOGJuQUdl?= =?utf-8?B?cEVuWHprS3JlVE9NQnJtNmNGUHhkTnptTklXMFpqUk9IZ0l0b0NhbHQySk1V?= =?utf-8?B?Q1Y5U1F6am9rcTRia01JUkQ1VjB6OUJDb2pCMkhNbVJubjIyQ3dGbHhKQWN5?= =?utf-8?B?dUNBd3BBQUFlOFBHVjVuUitOakNHNGZTQUpXZ1JRZzhNQjhPY0kyWmtDVzlQ?= =?utf-8?B?dlFtazExSjRLcTdSL2FWcHhoaW9pL0FpS1htY1RqWDgrVnVoQkozUUZabHVi?= =?utf-8?B?NmIwb1p5Uk1RWUVFOE1EZTdycjU0bGtLL3RKaDZDalY0MEtLNWYrQWlmWmRu?= =?utf-8?B?VFRocjFkRFVteGFnT0FMQ3NvcDhDeU1kVUVod25ydGd2Vkl3YzFVZEFscVpF?= =?utf-8?B?QitDNTJYN1hvdG1VMjN1NUY5eVNUOWg5bUxQeFpmMFFTZjQ5NVdieWsycUJJ?= =?utf-8?B?cWxRTW5SUTRjd3N4SUQrWmR2SVdwclBZamVVaUVTR3ZXM05iR3dlSytxRm8w?= =?utf-8?B?VDJrSEpRNG9NWjFlVnVicjlTd2FWQmpUb0U1UzFkSmR3c244QVVvL2lpNGhZ?= =?utf-8?B?eTdXQlY2b2tSSlpuZVQvNlBFVUNEZ3JQUXlPaWtndGtsL096UklOYWQrWi9i?= =?utf-8?B?bUxMZmZpak5nQ3QyVHZoQ3RYSmVrV2l0VlhSUFRCa1NNeURydU8xTERmTmJs?= =?utf-8?B?MDBoR05BdXdRQlhucVptRjRDQlVsSDM3UjBYSy9LU3drdUhmb09YUXMwN1FI?= =?utf-8?B?c0VWTzQrT3BXQjVCSlNDemxsOFNDS0VkZlhTQXBEak55V3JmQWhnQVh6QzVB?= =?utf-8?B?YlhFbkk5Ri91VlpzT1doU0lWeDdRU1ozWlJBaVRRZks0UnF6aEtmdWg4dXlM?= =?utf-8?B?dVBuNXZjZU8zZngzM005d0pmY0psbDQ3aGZrKy9RWEZJZTk3U1dDN08wdWlO?= =?utf-8?B?amV2Ui8wSVE3clk4eXg2NEVhdjczdVlveG1Mc1cydHQrNkVMM1kyVlZXRm1G?= =?utf-8?B?cGJ2Z3VrSGs2QndVS2Y3NVRKQjMraWdSYVdjR2pzeUF5QTlaUUptellmc3Zk?= =?utf-8?Q?Y+akJqVJcVcCJQcU=3D?= X-Exchange-RoutingPolicyChecked: HsefsZCZT0YDPVzxWznzQTyeLmtq3EkxY++FAmAgE4D1RBCOExgIntOvJFv0te4zjmvm/2ii5UAmHMdSU3PeTmWq4kKRwCjBD7UT99+9kScdPeNUVmFzpBGbiTop6cGyiBLFZql6I5vTcsGp0iFeh0LXan1voDUAbdYRSOtIZsc3d/684ts7FdHIa3t0bKjA3nt6fWu9m3qj446AARcaZ2XTrO3npvyj+bCIxkK8CPm081jSXcj8keAlhmt8eTJxquaaaD8+GgxpqiiPm3o1U+uslw5alMkZVJ/vRN91q1FNkZBle5b01bIyDvFEXuqNQdJ72K4+a8noLP5ziNb+nA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e4d88314-ac09-45cf-0f59-08df29fb2a6f X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 13:58:03.7332 (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: 1zzzIxIe6kZSPa/ZUous/AMhsfwdbppoYtpvsw7R9u9lOSuHUnC7JGL3pocfBG2zXG8MYlBt+EOscpkRM7NnY1alJiPFM7B3zemTywpWOvo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR02MB11308 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA1NSBTYWx0ZWRfX9GzzQXRgQJV2 hOxZSvxT8CZPBSRbFIoZqQ+KRbW9qMt5ou66054SZ9u+UBVAiRFKDYbWtA5xPW0Qh4J0Dm/aC2r DC4W8C5Lg/4fJKQ/zbhkhFV0D0dmacA= X-Authority-Analysis: v=2.4 cv=dfgVTnXe c=1 sm=1 tr=0 ts=6acf8a6d cx=c_pps a=b/aSlx19e507fu+kRueGxg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=bD7yre_yaOKMDD93RBsA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: WWEwIOaM9Ilu-JSXUqNjNVxZXw3aVIx4 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA1NSBTYWx0ZWRfX9/JFe+Qn0YG8 rDvXLsMPKMLMSPbPuj4tcMuug8eO3xtIz4SWTrMhm3RRbKuRPWUZcooJv/bVC5RChkAULI1eDqJ pZLCM3fx49A2YmJhj4oeoDz7ZbhFIRWXQ92q404dfzv27DlFK/PDvjxbPB9LdO9k9cU3yfc4N/L SZvccj+MdvImEiwNzd6nNu1aFjwVMUEqiGwSXsyvGSPp5n5phtjbIpMYD0a5M4rhq094V4HGdo/ 0c5oWgNtgu1oLtxrl3axkKZacteLi8F3yNlS8j/M2Lu4IfW/wJWja4VqFuciXkhqJK25AKosAYU hYerJ07XXV7s0GpIFGg7AcgAUGgGxfJismkJQ7M2q4BdvfOKyRtTtlOJDeFJC1maLTyYN2yKNcL wBfseGTqVdqPFCEJD2Vecg5tb8u0T2kVcdp7I+y9/yxa4bAs2Ftn/TyyFMyvVxK7R6QvIK13e9m YgOJMn3wc4iRxmzuVzA== X-Proofpoint-GUID: WWEwIOaM9Ilu-JSXUqNjNVxZXw3aVIx4 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1791986290-524CBB50-CF23DF18/0/0 X-purgate-type: clean X-purgate-size: 2380 On 14/10/2026 12:00, Mark Cave-Ayland wrote: > On 13/10/2026 16:54, Peter Maydell wrote: > >> On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland >> wrote: >>> >>> 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 >> >> This is one of those things where I think we're not 100% consistent >> about whether we think the parent_realize field should go in the >> child class struct or the parent class struct. The name "parent_realize" >> implies it ought to be in the child struct, though, and I think we >> do that more often than we put it in the parent class. This also >> makes some kind of separation-of-concerns sense too: it's the child >> that knows (a) that it exists at all and that (b) it wants to have a >> realize method that will mean it needs to chain back to the parent. >> >> The docs for device_class_set_parent_realize() claim the parent >> realize ptr is stored "usually in the instance structure" which >> I think is just completely wrong. >> >> I could be persuaded otherwise. As usual with QOM/qdev, I'm >> mostly interested in (a) consistency and (b) documenting what the >> "right thing" is. Realize, reset and unrealize are the three >> methods where QOM's lack of convenient support for "child >> implementation of method will need to chain to parent impl" >> is most awkward. > Yeah it's a tricky one. This patch was really just refactoring what was > already there, but I'm open to moving it into the instance if you think > that is better. I agree with your point about the child instance being > the one that knows it needs to chain back to the parent. > > I'll have an experiment and if it looks good, I'll move it to the > instance in v2. I did a search over the codebase and checked all references to DeviceRealize, and they are all stored in QOM classes and make use of device_class_set_parent_realize(). So for now I think we can say it is the documentation for device_class_set_parent_realize() that is wrong, and I will leave it this way in v2 of the series. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 14 14:03:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 14:03:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449112.1665048 (Exim 4.92) (envelope-from ) id 1xGzZZ-0006Hv-7O; Wed, 14 Oct 2026 14:03:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449112.1665048; Wed, 14 Oct 2026 14: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 1xGzZZ-0006Ho-4H; Wed, 14 Oct 2026 14:03:13 +0000 Received: by outflank-mailman (input) for mailman id 1449112; Wed, 14 Oct 2026 14:03:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGzZX-0006Hi-MU for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:03:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzZW-004p7n-Sb for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:03:10 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf8b9c-e002-0a2a0a5209dd-0a2a45068362-10 for ; Wed, 14 Oct 2026 16:03:10 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf8b9c-195a-0a2a45060019-d155dd36cc3d-3 for ; Wed, 14 Oct 2026 16:03:09 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48c4207ac26so3920471f8f.0 for ; Wed, 14 Oct 2026 07:03: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-48de0aaaa3fsm12387294f8f.10.2026.10.14.07.03.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 07:03: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=1791986588; x=1792591388; 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=MzesA1TjVBQoe30CWqEdg0oqAxt64RgmXVRAhfJfcw0=; b=YR/ktzN81uOuTYJCj3i4Fuws/oXfNtwazAF0A3QypaAcMnQQixf74VnLfGdERmPcEl W4zezshKenfc6f6JKcWenV71BeKNYJEyrspIpF6KqqC2+lrStjaDSiJ83BBXnR311PVh zFZx/knJoGp9GpiCTNGbYRSKoIulhbDeFrFkI3l0qwLSVVs5h5CgqOMtjyNSWYoV06PR v/9TnIQDhXiRGNMtnCmBESJ5TqK6VcuJyXveILIXYpJUTaeFeybhawx1Mm7033Sag1gt ael5/5ITEubGpNgSQgIlkrgRKHsXSOV5OrhJ5VmP2+Z7YY8MWQ5mGj3Mq/LCmVVVu3Jj 7v4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791986588; x=1792591388; 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=MzesA1TjVBQoe30CWqEdg0oqAxt64RgmXVRAhfJfcw0=; b=u/gaD3q4kxotJO0e+6oRtyWQAKLl8rSSjY/YX1q16F3MxIqddDIumTmYYCwyOAu14O dkH7Bz4e/MzaT7pCey+TpmqEL4Id5UsCpzYAEXG2fVudbPhdzBx8QsmwQIee0SJfWROZ vIGpc9uSi0zUvzenAuz5A0UD+AWpzCbJ/P/LCKzms28IIJ4yMlr/m0hNpCXki29cveUW fRAtJDtbA4+tFr8evlE4eFvhD/Aa7YCyOJyMIsB+im2hs8UqkOSU1Lf9M0hazfhXPMAi zmsUksLqmUGz1TF4Kt1EJjfHG27jIAtEgVGp+ncKg/8/4wWl5rwdBYFVBrftrYBc8h5f AiHQ== X-Forwarded-Encrypted: i=1; AKwUvBzjIeYcgLk1xj9bBkdTARssrkXS3ZklJZIj6NI3Fh98bufjZNcGOoekQLCh6NhgAmQPg4P7XOtddO8=@lists.xenproject.org X-Gm-Message-State: AFq9FYL8ylovMPMaR03lo0nHp7dVZgxr2e+W5eD2hZUCfAyj8YFxn+X/ oE6xHYAMtwGDPX28FrB1E475zAZkBku8FeXQEayoyDyp9FJ7rT3ixLaJ/Mi/lTobAw== X-Gm-Gg: AYBFou3yh0aFFjzxxrWrE4ab5gSkt+v4/ucRVbUrEaJBAgxL/DJv+JsTFa849Io2unz s76M5wsoyTrh6ryLsMX64OR3LXxeGRxNzAuJZsKlOdLvvN6zDZUaAxEW5Nw8TMWpTzEa7goUYXb VVuzy1fLf0FBlZ8PsAcOVM9feGBNKtCFiB5hXFmqMTkH9JzSz8sLRcJE+qVQ/I8EbucXJg9OQUJ OruTHPwkLtbCWnu8XbqUdCEDbP3zg6WyywTaiTka4WDnnlegagCGad+W9MfPOgydEf+JoZU3eDl zY6W8rgNlC5fkSny+WbE2POHOgi0Ss+zvJ4S3DiNW9ZbaNlIwWHz55WJ6bi+qCQKvWNVo9z00Yc 4TYAbWRlgBoecgKXEXkb6onYLQfE9htyTt+12ERYsjnZN729FYXX9vSJGKnutUniVo3WwkF+lkY prQ6BkF/wFprv6SHkXb5pgxQuVi1xrGcbDez2WGA4La8qwGw2z0GEe0Bc+pOsWLjH5PXzsvQX+g MwApR1ur+dUCpuuTBcqSBy1x+sua38F1w2SlN/KLJMuG2engDJpOLcaq5otEk1yTAv6LPmr X-Received: by 2002:adf:f307:0:b0:48c:54c0:4cf1 with SMTP id ffacd0b85a97d-48dbaadd3e5mr23647661f8f.9.1791986588535; Wed, 14 Oct 2026 07:03:08 -0700 (PDT) Message-ID: <27c8f0bb-4c59-4605-ac61-9a3e5434fc64@suse.com> Date: Wed, 14 Oct 2026 16:03:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 09/39] xen/riscv: build the target hart index via aplic_hart_index() 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-16d1c6/1791986589-FDA0C77B-91848352/10/78276251493 X-purgate-type: spam X-purgate-size: 1136 On 30.09.2026 18:18, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -335,9 +335,7 @@ static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask) > static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask) > { > unsigned int cpu; > - uint64_t group_index, base_ppn; > - uint32_t hhxw, lhxw, hhxs, value; > - const struct imsic_config *imsic = aplic.imsic_cfg; > + uint32_t value; > > /* > * TODO: Currently, APLIC is supported only with MSI interrupts. > @@ -350,27 +348,18 @@ 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; > + cpu = aplic_get_cpu_from_mask(mask); Any reason this can't be the initializer of the variable? There is a related assertion in between, but as long as the variable isn't otherwise used ahead of that, such ordering if fine afaict. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 14 14:05:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 14:05:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449121.1665058 (Exim 4.92) (envelope-from ) id 1xGzc8-0006wK-Jc; Wed, 14 Oct 2026 14:05:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449121.1665058; Wed, 14 Oct 2026 14:05: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 1xGzc8-0006wD-GU; Wed, 14 Oct 2026 14:05:52 +0000 Received: by outflank-mailman (input) for mailman id 1449121; Wed, 14 Oct 2026 14:05:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xGzc7-0006w7-RS for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:05:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGzc7-00CRsc-8R for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:05:51 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf8c31-8faa-0a2a0a5109dd-0a2a450aebb0-48 for ; Wed, 14 Oct 2026 16:05:51 +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 6acf8c3e-f2d2-0a2a450a0019-d1558035e5f4-3 for ; Wed, 14 Oct 2026 16:05:50 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a1682bff3cso4616625e9.1 for ; Wed, 14 Oct 2026 07:05:50 -0700 (PDT) Received: from [172.20.10.5] (public-gprs378609.centertel.pl. [37.47.110.50]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1bcf3c8b8sm3707235e9.10.2026.10.14.07.05.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 07:05: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=1791986750; x=1792591550; 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=FFJJL+9AqxcnZpFPPjUKvHI8vqTS8pUG9i6dcJfjtco=; b=HfgxHG60p2sxSkSp1arBoTwqsJXmAP94KL0tHUvE7DRD1dKzYIamB/eXq2/PjMew6j SvMnmYMCciFW4vtSG5EaF/0nHkv0qcqRDBjHUeaCCWl6H/YmnjIa/uy7S5lDX5nb93tI IqOO+SnnYoFX3E9xCFXUmzPomuv8ZrBJoa4Xyr1hW+VYDahUQfjV9dF2no8fZGKJmkaJ L1rrtZtaSKB1bIrFWt75s9rXAgP05mzpNREuqwSaWUB7tJc2YpkAwzy/kBy7zwLAd5fN gCTlf1v2n8vQTrSTe/Gp3o3ZPXOSbf+3d+U4iRDVSflvcBUj6h0UnEm4OdsdbFROXl2Y GZ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791986750; x=1792591550; 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=FFJJL+9AqxcnZpFPPjUKvHI8vqTS8pUG9i6dcJfjtco=; b=zkjHlxVpYm2b5qwuO1zQuVFPexopXvkCBzgCfU7G3X62RLcxHRutvLjIA5kL8c3YfO umTGcVtfnngJ2V8C3IuSXitT8km0v1ypfdBbtoR4Kl1iEt/GZbqJ2yQi9gQw/ag34AvQ XOwy1cKP01P7LFb979+W/hEYbFodNqMDbdoxzUov9p58UlA5lxMXNYOPM5IcpOzZG0QA Bpy0U96QyCVnZ1qTyJZ/vwp9jA43WGBq7LkJfkW/nMuuH+MjoqaHBe9KDqDfLVcOPn34 FF0d2T1Osg8hgN+PUtneSWJqi2cmwVsljBnb+IEO7Ebp8MtPcfHVH7+YzjX/sNJh4A7b QRfQ== X-Gm-Message-State: AFq9FYKxHVGvcgv4DSnMu9cqnWn9gmroy1RvvabVFsIrJZ2wQmPR4eCL wFy5wm15aWgxcmiDVp2/Lat5SugtuT6PXHsw2/HM4WSoj2/mtwc72Imy X-Gm-Gg: AYBFou3bFTY7s4uiig/fdBBX4zl8NyOuPBJk774Ycd7WSE+RUX+ivsiOlulCfCUlXVa Bq9+VumQT8uzWwjXUu54FrPMAhjsM+vvYXV1W1DYh8xZOx7w3arH5KRhIClRJshnoSmGHHL+aPm SDu936yryQs9Q0FTbDmRuoMu11yIjiE255SM4OdKKxpFIzmBMFvOmlzZH6JviKTc6x99T0BPWy2 IicVBdGFj9Z2uD/+fnUZb9Cfhz/UyEes4NCxirJ3Khl+rxzOjAtQJe6zierQt1oFR8nQO0n/M8W rVmlOLfC7FYAuxotfJQ1wNBhr6Rn0HPdNe31X/C3xV2UbGG1AjTgxfUVsZOmUmrwJpJIIkg3fna 2Iq7GhKpXw1UcdsPEKQ9vAENcjmJSur/n1qpomYFPGBMhzKGA5+o4x0jcVIZBeRpH0ShXSfiq1V meCQl6BL/CK8hSRTJJYeH720wE/68PBBM9hh55Z3uDPDmUHvZFezMGTGKJdfb+SL3X8fRNu5UjG vUdfP+SuzwMZRf3yQ5ZbL0ALdAkgVdF7u3Tzxk= X-Received: by 2002:a05:600c:c16f:b0:49f:cbf1:e765 with SMTP id 5b1f17b1804b1-4a18e3ef314mr305314675e9.0.1791986749968; Wed, 14 Oct 2026 07:05:49 -0700 (PDT) Message-ID: <9ac3fdbe-9f3b-4abd-ab8d-7e252a7cf809@gmail.com> Date: Wed, 14 Oct 2026 16:05:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 11/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: <6e539cc5ded7f62c4347781785af714840893184.1790779209.git.oleksii.kurochko@gmail.com> <1791305420.8631fc262581453bbf619ec5b2062170.1a1121f8fef0003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791305420.8631fc262581453bbf619ec5b2062170.1a1121f8fef0003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791986750-536D6CFC-5EC1067A/10/73395122804 X-purgate-type: spam X-purgate-size: 8399 [...] >> diff --git a/xen/arch/riscv/include/asm/csr.h b/xen/arch/riscv/include/asm/csr.h >> index a5cb24c863..aad82c6a6d 100644 >> --- a/xen/arch/riscv/include/asm/csr.h >> +++ b/xen/arch/riscv/include/asm/csr.h >> @@ -40,6 +40,13 @@ >> csr_write(csr ## H, v_ >> 32); \ >> }) >> >> +#define csr_read64(csr) \ >> +({ \ >> + uint64_t v_ = csr_read(csr ## H); \ > This violates Misra 20.12 rule (docs/misra/rules.rst) as we use macro > parameter `csr` as an operand of ##, while it could be expanded as a > macro (e.g. csr_read64(CSR_HENVCFG)). To avoid MISRA violation, if i understand it correctly, I will do the following: +#define csr_read64(name) \ +({ \ + uint64_t v_ = csr_read(CSR_ ## name ## H); \ + \ + (v_ << 32) | csr_read(CSR_ ## name); \ and ... >> + \ >> + (v_ << 32) | csr_read(csr); \ >> +}) >> + >> /* >> * 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, >> @@ -72,6 +79,12 @@ >> (void)csr ## H; \ >> csr_read(csr); \ >> }) >> + >> +#define csr_read64(csr) \ >> +({ \ >> + (void)csr ## H; \ > Same as above. ... the following here: +#define csr_read64(name) csr_read(CSR_ ## name) >> + csr_read(csr); \ >> +}) >> #endif [...] >> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c >> index de25607247..02e7f6364f 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 p2m_vmid_switch_to(). 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); >> } >> >> @@ -1504,16 +1513,110 @@ void p2m_ctxt_switch_from(struct vcpu *p) >> * VMID, world-switch code should zero vsatp, then swap hgatp, then >> * finally write the new vsatp value what will be done in >> * p2m_ctxt_switch_to(). >> - * Note, that also HGATP update could happen in p2m_handle_vmenter(). >> */ >> p->arch.vsatp = csr_swap(CSR_VSATP, 0); >> >> /* >> - * Nothing to do with HGATP as it will be update in p2m_ctxt_switch_to() >> - * or/and in p2m_handle_vmenter(). >> + * Nothing to do with HGATP as it will be updated in >> + * p2m_ctxt_switch_to(). >> */ >> } >> >> +/* >> + * 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. The hart also keeps its place in the owner'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. >> + * >> + * TODO: nothing resets hgatp_owner when its domain is destroyed, so a hart >> + * which stays idle from the domain's last run until it is freed is >> + * left with a dangling pointer. Once domain_relinquish_resources() >> + * tears down the p2m, it has to reset hgatp_owner of every hart still >> + * pointing at the domain (cmpxchg() against d), i.e. before the RCU >> + * grace period of domain_destroy() and so before the domain is freed. >> + */ >> +static DEFINE_PER_CPU(struct domain *, hgatp_owner); >> + >> +/* >> + * Update this hart's place in the dirty_cpumask of the domains involved and >> + * claim a VMID for n. Must be called before HGATP is pointed at n's p2m, as >> + * it is written with the VMID claimed here. >> + */ >> +static void p2m_vmid_switch_to(struct vcpu *n) >> +{ >> + unsigned int cpu = smp_processor_id(); >> + struct domain *owner = this_cpu(hgatp_owner); >> + bool need_flush; >> + >> + ASSERT(!is_idle_vcpu(n)); >> + >> + if ( owner != n->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. >> + * >> + * This has to precede the VMID claim below, so that n gets a VMID of >> + * the new generation. >> + */ >> + if ( owner ) >> + { >> + vmid_flush_hart(); >> + >> + cpumask_clear_cpu(cpu, owner->dirty_cpumask); >> + } >> + >> + /* >> + * Mark this hart in the incoming domain's dirty_cpumask before HGATP >> + * is pointed at its p2m: from that write on the hart may cache the >> + * p2m's translations, so p2m_tlb_flush() must already reach it. >> + */ >> + cpumask_set_cpu(cpu, n->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) = n->domain; >> + } >> + >> + /* >> + * 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. >> + */ > So if I understand correctly, we are setting generation to 0 to mark the > vCPU that it is coming from other hart right? Yes, at least that is the case this code deals with. Strictly speaking, generation 0 just invalidates the vCPU's VMID, so that a new one is claimed on the next VM entry; vmid_flush_vcpu() could be used wherever that is needed, coming from another hart being one such case. > Nit: If it's the case I may simplify the comment to: > /* > * VMIDs and generations are per hart, so a pair issued on another hart > * may match this hart's generation by coincidence. Reset the generation > * to 0, which no hart ever uses, so that a fresh VMID is claimed from > * this hart's pool. > */ > Looks good to me, I'll take it. >> + if ( n->arch.last_cpu != cpu ) >> + vmid_flush_vcpu(n); >> > Nit: I had to read this a couple of times to get why the guest entry is too > late. "makes HGATP live" doesn't say what happens once it is: if it's > because of speculation filling the TLB with G-stage entries tagged with > the VMID in HGATP, like you explained in the commit message then it may I thought that having "HGATP live" would be clear. > worth spell out: > > /* > * Claim the VMID before the caller writes HGATP rather than on guest > * entry: from that write on, speculation may fill the TLB with this > * domain's G-stage entries tagged with that VMID. A stale VMID may > * already have been re-issued to a vCPU of another domain, which would > * then hit these entries. > */ > Indeed, that's clearer. I'll take your wording. Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 14:31:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 14:31:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449145.1665067 (Exim 4.92) (envelope-from ) id 1xH00H-0004Vr-HB; Wed, 14 Oct 2026 14:30:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449145.1665067; Wed, 14 Oct 2026 14: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 1xH00H-0004Vk-EJ; Wed, 14 Oct 2026 14:30:49 +0000 Received: by outflank-mailman (input) for mailman id 1449145; Wed, 14 Oct 2026 14:30:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH00F-0004Us-IC for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:30:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH00E-004vZg-VJ for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:30:46 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf9209-8faa-0a2a0a5109dd-0a2a4505e786-28 for ; Wed, 14 Oct 2026 16:30:46 +0200 Received: from [40.93.198.0] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf9211-4cb1-0a2a45050019-285dc6006ed2-3 for ; Wed, 14 Oct 2026 16:30:46 +0200 Received: from MN2PR20CA0065.namprd20.prod.outlook.com (2603:10b6:208:235::34) by LV2PR12MB5896.namprd12.prod.outlook.com (2603:10b6:408:172::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Wed, 14 Oct 2026 14:30:34 +0000 Received: from BN2PEPF00004FBE.namprd04.prod.outlook.com (2603:10b6:208:235:cafe::96) by MN2PR20CA0065.outlook.office365.com (2603:10b6:208:235::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Wed, 14 Oct 2026 14:30:34 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF00004FBE.mail.protection.outlook.com (10.167.243.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Wed, 14 Oct 2026 14:30:34 +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.53; Wed, 14 Oct 2026 09:30:27 -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.53 via Frontend Transport; Wed, 14 Oct 2026 09:30: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=ncvDzXR+skiQCl6QrbYAf/nZ36wxxOsveBM01SKSdyw+2dYkTuXYs300vNvWgBnay9TDuGkVyqykjvLyzk4GnfJJFWn1aEPAdq+vpFA3WLCtGHqgD7VqO4R/NdIg8Z05zXm8gvly/f4TeG/0Iy7A685Zm4JASOXhELB8vj1ldECkuCSrlMFvdI+ycx+AxsT+lYaRCskadSuoYRslxdZzc5kK9MkLb+m/dkvbkXHeWLqLlvG/WsgW40Rq8WaKP7pSjwlnU/RKknwNNjWLt18U63/La7kxqL8LTMoVzOsN2JU6y/pdiKt8ZDzKLFt/q+9EYpjBkMMTOg3B/5o85VAxNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ioc7bLvwFb/grCV/t3XLkmmTzee6JtBXWFbcR1bznHw=; b=GlkhGyjKeP75O6Jj9J+vS64hiHxOkkzIWy7kv839gRl7JE2Cgoo8aox94hn8XYxr8Fjo7pFotebGWmFrIP5kHG1zDKMZ2XU9P3zKBivo+aOOK37wUJj5OiePLhJ+H4dzZYNCL+HG5RZDNNgLG9jEW3A73p1dqHfbdVtdHEoccv98GiEBORIcQ6zWMM/dt/qxU42Jn/Gyj3OokTkTQnH4aVjE5toclb4hg/5NOUtwOLaH98Tflx7CXw6qAV5rMstjNoJ59T8ozpKiZI6xbEqOXCgVSytvWwjONqWZMJRmdev32w/f6+msA0w3MtHBYnbTADR9gmyZHsfV0UXe2u+dbg== 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=ioc7bLvwFb/grCV/t3XLkmmTzee6JtBXWFbcR1bznHw=; b=WuOwJDXmxK6yc5umfU/WfW1aj6mGfhA+dtkaMSdnyoTy4Blrg8TfA7G4a4n1EEn2NAHOKoVc9cwrAFLtbtCO8hLgDa5vUkaTsaCSY1UiNfjiOqFEUybsQPYFs9g8jLw5Ufyx1PbqfF0UfYFigHSDqlYhs0JzEbc9rFYDj55l2n8= 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: Wed, 14 Oct 2026 16:30:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 0/5] Fix ARM domcreate 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: <1791812199.8631fc262581453bbf619ec5b2062170.1a13054627300080d7@vates.tech> <2482f3cc-e9b6-48d9-b8d5-a463feb82dfa@amd.com> <1791977870.8631fc262581453bbf619ec5b2062170.1a13a3453cd0008425@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1791977870.8631fc262581453bbf619ec5b2062170.1a13a3453cd0008425@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF00004FBE:EE_|LV2PR12MB5896:EE_ X-MS-Office365-Filtering-Correlation-Id: e7dfa392-0153-466b-4f16-08df29ffb528 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|36860700016|82310400026|56012099006|11063799006|4143699003|261009223027099003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: degR1IknP/gqNumEe2KXym7CDt7VnY9DiiGJm2Hs7vXfTadGbtYJPVwOVtE2KFMapmMUzR2YfvS5KiKZLkvzbwBnJKy7QUhmQ15zJ3uQnAwuh4YWL62xMqzJNwrRTrLKccwfmaMzOTPs7O1KhVWpwLnscnBLMpUd9MOJ/DJD/m6UYpMtZoERyw/X81yJYTugYTU2z5fjyXLpto78SrIr4WwbOahHJ0s1PkKtXRMb7Vg8ONmf1aWQyG5AaA9OZPd613o32blQJlJR9QYwrqg0HXIQWUZ0coJAPWx/uHMVvkY4S2IQ8cJIYVoz6aayGOBvk2guTJPX0KtbrKblfSPHCQgA19rLtrvKha2HOzQdqApxyJ3P8jn59/uLjgt7bkdlQtYJT2f8lu6tyGfCdHVNgBiF3VVt1eIghHkrfI9Dy3mTr4xofa0cur9xl9qCycTr+nMv5DTGsrMgIbKqPN7soJs+QdIwuIKFgCnDCGQNQqnBbnrQOw+hfvtfbY4ASXa7egCkjCLujUoKASjRu0Z36qBIP39J4941JBPa2F4hlCTv0yj5ZiWSLNePXbXo5nD/hNK3kBVmK68YnC8cNDShBjNhbDfKcPdHuUBrLD1YV2YLhydLz2i3ARgYpE7ajo5kvl4yeq3+FJuAmtNX9Thb1TSk1i1oHD68r35IJ3m42jvGTKaXDh/Vvc+mZu3xcACBkaOwNBxTOk0LkPDECb1TWg== 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)(1800799024)(23010399003)(36860700016)(82310400026)(56012099006)(11063799006)(4143699003)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: mPteq/opef/wEd5u8q7HFFHLVYPsSiH4+1F6dLAwSA1+dEkL9NtbEDIMUeQ5Ux9SUz1f+oq4UWxDVlRJU23eiq+UYUN1zCw7bE62dT1pNqLDKCLt/jTQV6gZf36CQqAj9slqMtHchBPqwg1qe0G9BrRL0D8f6aaZuUBNqQTe2ekWlQP/6HE7BjL+lMi/FHgOe4tCAgOJEnRYgPjQdAhWsuLG3NsOIUk3AFFE663P3fv1jehb8LoushX/fCzELlW8ktZFUOa4Cp8rhbvru+W+IqdrxXBdh5YNjzmEgq1oMCTNXdqjU4jarJuO8AZfCKGU56DY4HuMWFYF3QFv+y7Pw3/42RnVm6JaxaEjJh5xZ0ENlGX498Mou4CH7JlKK4inyDGJesKUNILGQ7bhmlMemTAhnf3GFH770JbJ6GsOLoZXPJTFHY45S+vZtj3l4POZ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 14:30:34.2167 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e7dfa392-0153-466b-4f16-08df29ffb528 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: BN2PEPF00004FBE.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5896 X-purgate-ID: tlsNG-c201ff/1791988246-F6EB12A1-2A5F8DFA/0/0 X-purgate-type: clean X-purgate-size: 3242 On 14-Oct-26 13:37, Julian Vetter wrote: > On 10/13/26 2:28 PM, Orzel, Michal wrote: >> >> On 12-Oct-26 15:36, Julian Vetter wrote: >>> Hello Michal and Anthony, >>> thank you for the reviews and acks! Michal, I have addressed your >>> remaining remarks on the "xen/arm: report clock_frequency via sysctl >>> physinfo, not createdomain" patch. The golang bindings are regenerated >>> for the new arm_clock_frequency_hz physinfo field, and >>> alloc_domaininfo() no longer references the removed clock_frequency >>> field. Apart from that I have collected the Acked-by/Reviewed-by tags. >>> >>> Signed-off-by: Julian Vetter >> I was about to commit the series but I found out that some tests like >> test-mem-claim and possibly others still pass gic_version=0 which will cause the >> domain creation to fail. You need to update the tests. > > Yes, thank you. I didn't see this. I have fixed the tests, and ran them > on a QEMU setup. 2 of them now pass the domain creation at least just > like on master (1 doesn't work on QEMU because there is no IOMMU > emulation?!): > > ``` > @@@ RUN test-mem-claim > Memory claims tests > Free pages: 254208, Oustanding claims: 0 > Created d1 > Failed to populate physmap domain: 16 - Resource busy > @@@ RESULT test-mem-claim rc=1 > @@@ RUN test-paging-mempool > Paging mempool tests > (XEN) [ 28.386587] common/domain.c:845: IOMMU requested but not available > Skip: 22 - Invalid argument > @@@ RESULT test-paging-mempool rc=0 > @@@ RUN test-resource > XENMEM_acquire_resource tests > Test ARM > Created d3 > Failed to populate physmap domain: 16 - Resource busy > @@@ RESULT test-resource rc=1 > @@@ ALL DONE > ``` > > But, unfortunately, these tests seem broken on ARM even on master, > because on ARM domains start with an empty P2M pool, and since these > tests call xc_domain_create() without setting the pool size first, they > fail on the populate physmap call. I'm not sure how to proceed on this. > Should I fix these tests in their entirety or leave this for another > patch set? Thank you for your advice. In that case, no need to fix these tests in this series. > >> >>> >>> Andrew Cooper (1): >>> ARM/sysctl: Expose the supported guest GIC modes in physinfo >>> >>> Julian Vetter (4): >>> 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 >> Here you are still missing tags from e.g. RISCV I think. >> >> ~Michal >> > > Thank you again for pointing this out! Unfortunately neither PPC nor > RISC-V have a formal maintainer defined in the MAINTAINERS file, so it's > actually "THE REST" responsible(s), which is also you ;-) For RISC-V I > have asked internally to do a review, but this will only add a > 'Reviewed-By' not a full 'Ack'. So, not sure what to do about it. We usually ask Oleksii for an ack. I can see Baptiste added one, so I'm good. The series is ready to be committed. I'll do so later on this week. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 14 14:33:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 14:33:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449154.1665076 (Exim 4.92) (envelope-from ) id 1xH02r-00054Z-TB; Wed, 14 Oct 2026 14:33:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449154.1665076; Wed, 14 Oct 2026 14:33: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 1xH02r-00054S-Q2; Wed, 14 Oct 2026 14:33:29 +0000 Received: by outflank-mailman (input) for mailman id 1449154; Wed, 14 Oct 2026 14:33:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xH02q-00054M-BT for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:33:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH02p-005ppF-OR for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:33:27 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf92a8-e002-0a2a0a5209dd-0a2a4507caf0-46 for ; Wed, 14 Oct 2026 16:33:27 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf92b7-b4ea-0a2a45070019-d155802ff115-3 for ; Wed, 14 Oct 2026 16:33:27 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a140e7405dso10548865e9.3 for ; Wed, 14 Oct 2026 07:33: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-4a1bd5c748csm15835e9.12.2026.10.14.07.33.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 07:33: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=1791988407; x=1792593207; 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=m/Y28sNNN2MKpKnPvSQDvaeI1kGzroZ9VW7pAACaSVg=; b=GG4jR0AOF2auL/Ea5d5fDGcwdOrjvpmn9xpTJkKoKMseg9IWaIqVZ/G/QzhSYSIhBk L7cYvQrdiie1L3r0emsUM6cPKPSjKF9Pyr3YYUe7uycKBqZ/ugBbxLCuOfXQt0kQrDR/ QrZOIJR/TLujz+KXdamsmJqPzRAQZWypEthhHq63K7rS5aeg0YzaQZZQs+vKzdy2BrID JWg4SuclxhVtNfpUqkJ/I0y1uH2q5UCGIB2wY39vAyNBf0zFSnGgNDp4zXxLTFHQ6yqt bMRsPfiNGwUCqCT5QzwjhDZqxGPj8DJbwTuMhE6yWbYM0Fbfh5uNclyMY9wbS48qnWSR PmNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791988407; x=1792593207; 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=m/Y28sNNN2MKpKnPvSQDvaeI1kGzroZ9VW7pAACaSVg=; b=26ch/XUE1hvOBfcNU/94/WgPnSAAwiSkwWiSsKhDC+6V501d+OgtqDIkH0Q9GflykL 25skdCKnQtMpUi5VldaVBxyb/X3p9Z12i7IQ2ZHiCFebzPDDPxB5RzpaoSj1ajuONFFt sMDzgQMokqM49i5yh3cdmUj08GbdIVS5bgTMqpssK9Y9pMsfmXlSmMslmZlaR/asPmqE tdoABnTz7qf659htz9esf4qtNVkW+h/SsbCzG0lAi7MejFrXt9ZJf1k5Xb5YVbplobMX zaBGk+ujgRlSzuyQtH9E7xt5hXs0/Fi5u1uruJaEUQnbt34CwcpyKCIKpjrtqW0T/R6M +wzw== X-Forwarded-Encrypted: i=1; AKwUvByuErdTILZg6R0u4NTSXXMoc4vMl5I0SBu66fUlSChv4OG2Rv5h3TmOoZ3f8hjlghRJhpbS1gNExZY=@lists.xenproject.org X-Gm-Message-State: AFq9FYJeHDNwKlBW7WdsAComz8lZPpcgLQ5bbRt/dd0/cDj9lFzVGI0h GQ3iUAEaQlHiIP9NSMOu+RWQLT4bo1ffKbwDZ6Jc9RU4Uy2De1QGgLQ5i9QEVwg1yQ== X-Gm-Gg: AYBFou2v7Zc2BM1UF33mthiXllwMtynxo0H4n4fujx53Z/1mRGPCFpqiRdfOqqwqgNc X2VuHWZfdmPzlZCTpfBvuQmDe5KSTP9hxzKgcv6yzDH0TkUtxs+6ucGOBxvojjZlhsccHIXYwmY JimGuAsztKe5s3OVOn8AXPXf88wygXhyjSzHD32Xhv0EIEjCXhEKCE7G8lmAKGPKRYvRt9hEsog H+NCvXqXcy2gG1kn90WhDCkLiZisr4iTVjNrMCjKpf2oC70GjBZ/7NCg/rXLyItTjObafMcetnb Pa7MkCgdBgTHyUlrdMhl9s9+W3EfggHgydTppvrtQNQkhcm6YtKxQsPkuglhbuSDVTgvU/YV63W bJ4PJwhBuoeBtTKiWPbLABgR2wKKib8EJlLVQ5/lAofUUnJz/v4qTxIN/9N5Z6jnh9r+ZasthJu Yrx/mfFguxpfaU9ol9sBe3R18VVnnqZaV7WwCAVz1qSVYaNf90ke/G1pWE3Z+5dRlPE7zuaSiUa uEO62+IrPUIvxLUM8CDufiNsdAHyDx7bIOr+JXDUmOXAZmdLSlj+A/d0CTIVQR8Y1j/VBSl X-Received: by 2002:a05:600c:4ecb:b0:4a1:6916:798 with SMTP id 5b1f17b1804b1-4a18e4a3f69mr317625895e9.14.1791988407084; Wed, 14 Oct 2026 07:33:27 -0700 (PDT) Message-ID: Date: Wed, 14 Oct 2026 16:33:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/atomic: Fix UB on various atomic helpers To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261014133551.622462-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: <20261014133551.622462-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1791988407-A44CBAE4-1D11377C/10/78276251493 X-purgate-type: spam X-purgate-size: 1579 On 14.10.2026 15:35, Alejandro Vallejo wrote: > --- a/xen/arch/x86/include/asm/atomic.h > +++ b/xen/arch/x86/include/asm/atomic.h > @@ -122,7 +122,7 @@ static inline void atomic_add(int i, atomic_t *v) > > static inline int atomic_add_return(int i, atomic_t *v) > { > - return i + arch_fetch_and_add(&v->counter, i); > + return (unsigned int)i + arch_fetch_and_add(&v->counter, i); > } I'm concerned seeing this kind of change: It's merely papering over an issue in the caller. There's not going to be UB if the caller passes suitable values. And the atomic types hardly are meant to be used in contexts where overflow could occur. Furthermore different parts of the C spec say different things here [1], [2]. Hence whether overflow in signed calculations is undefined or implementation-defined doesn't become entirely clear, according to my reading. Yes, [2] is from "Conversions" when here we talk about expression results, but unsigned overflow not being UB also only follows from what's said under "Conversions". Jan [1] From "Expressions": "If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined." [2] From "Conversions" / "Arithmetic operands" / "Signed and unsigned Integers": "Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation- defined signal is raised." From xen-devel-bounces@lists.xenproject.org Wed Oct 14 14:53:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 14:53:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449171.1665085 (Exim 4.92) (envelope-from ) id 1xH0Lv-00008q-E6; Wed, 14 Oct 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 1449171.1665085; Wed, 14 Oct 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 1xH0Lv-00008j-An; Wed, 14 Oct 2026 14:53:11 +0000 Received: by outflank-mailman (input) for mailman id 1449171; Wed, 14 Oct 2026 14:53:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xH0Lt-00008d-SC for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:53:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH0Lt-004GjE-1K for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:53:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf9754-8faa-0a2a0a5109dd-0a2a4505ba40-2 for ; Wed, 14 Oct 2026 16:53:09 +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 6acf9754-4cb1-0a2a45050019-d155dd36c102-3 for ; Wed, 14 Oct 2026 16:53:08 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48c411d6615so3099198f8f.3 for ; Wed, 14 Oct 2026 07:53:08 -0700 (PDT) Received: from [172.20.10.5] (public-gprs377965.centertel.pl. [37.47.107.174]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48df0f8f624sm1190534f8f.5.2026.10.14.07.53.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 07:53: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=1791989588; x=1792594388; 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=qsXuphSkdRcAHaN/8VnmvZd3Bh6XwZaqZfIQP3tXUYs=; b=BbAd2tZHkVcB15F2Ax324VAWz8MXYaIdSJN6m75uICtk56txtGVQAAYHqCPuFkoymf ED2GFAADNK9M68zVf8TX8Zc/uz+ev26bS978ph9VPMOWT/JghbPHZhVvh+l0pUA4PVen EM6BpRk8KDqE1+Q+paWY++ADejucsgNxYOt7fXeuVLmkerHTFOrOO8Ga8OLFkiZ9ZK9U ySZxp1FHOEnBumj3nVyxmpNwt6mJvSNpQtdGfnLbec1f4Ym5AXZx6JNst1QbztEqkX+w nilgkIhzj76z/7MmhjbDfNbGH7sWZKkL1MAu2Kb9ic8tWAtTvXiJR3Ow3Kvke42K+bRM pW0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791989588; x=1792594388; 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=qsXuphSkdRcAHaN/8VnmvZd3Bh6XwZaqZfIQP3tXUYs=; b=jrG0rj+d8hOBVEiT/0W2sls6qH1kf3b54EeFj0PUPx+kA8/w8MgU+JT6PIY3+bPs3O OXBlovSqwJvfmsNFFoUn00s89+1c2UCaU5p89H03ETwAKSEWTwoDtTiSrFYlHP4NPlAl dABwohECFkdcePvS257pVXLv7Tf/Qn/UiKIafxvtrdO0aRAuH22Hd156pMz/7basC2Rj K30I5E7+txX/PyQVgSCq8UWkaLQiFX9qHJX7HFm5k5e8CA+AVJgSVaW+LSSHL9tB9BTq 4vAp4zIWMDZ4v0QMBOXi2diCnodTv+F+wzomNz7mctHPU0kxjrN72SnLLdNyxNPKjAfG 9gRQ== X-Gm-Message-State: AFq9FYJk86bqHHHv3wutIXENBmgl1U2J53VWRE4cVVFHYrkRB4i82NIR kIa2pfkMNcXP5+wdeohVwfYpwwXLKERsWpepXoqWsnkkG+VkWPrzgKvX X-Gm-Gg: AYBFou0+r4bHVmeVTI+RMou736LR60plwo1B9pWGwhyyTyvZ6a1qwnzkWFl9JLWLyt3 5+qRUdqlR4beG0xo+SBdb5NbKQeM6HuEi6DepaSIPvG5KIXyX6wUz3bh35aC1seIcMcX956pffB J+zLzOtStmd5ejubzMB1pCJPVoE0uXwtALN10oojBZCCffeQeLmZTt+RPpvnnTta+fYn5IJBuIY FvKriaWPQs8B2kCVbXrgHyGNYoHfjh3kz5fVhxEcVm+0zaZFM1QMv9d9qHLJHhlOuIuF5REn1ab nmcCpDwjUPJC6v1odBzEgJbG+HBTob3y9VuC0rFSkDdg2JR5QKHn3DmCbpTYI5Xl02CzxtfEE1c 4r87Veru+mKHWcpfjaBYsECaYBpKGwnS+DCpIZkqL6Jd7NuimkpxBCHJg49Cmo2yMzJr4JUDdn/ BFK1hse4BeHnjJozi80PJHcXXFHVzUBISW+K16Lha1LXIoP67BSwFrBkwkJmJynsgObGx4MeKTe Jh4iPg5CL9pXjxcArjTBjtGVLiecvN3I9vBhOe8Kibp3DMF52c= X-Received: by 2002:a05:6000:184e:b0:48b:174:eab1 with SMTP id ffacd0b85a97d-48dbaceb3f2mr28876540f8f.36.1791989588390; Wed, 14 Oct 2026 07:53:08 -0700 (PDT) Message-ID: <0b6b4bef-11c4-486b-8b9b-e46648b2207e@gmail.com> Date: Wed, 14 Oct 2026 16:53:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 12/39] xen/riscv: save and restore vsiselect 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: <3a454373368c507a7bf9693c6651a7749d2a86b7.1790779209.git.oleksii.kurochko@gmail.com> <1791363264.8631fc262581453bbf619ec5b2062170.1a1159231980003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791363264.8631fc262581453bbf619ec5b2062170.1a1159231980003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1791989589-F60AA2A1-CE23AEA8/10/73395122804 X-purgate-type: spam X-purgate-size: 2203 On 10/7/26 10:53 AM, Baptiste Le Duc wrote: >> 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. > Nit: I'd suggest a more tighter version that might be more clear. Feel > free to use it: > > ``` > vsiselect isn't saved/restored, yet the guest writes it directly (VS-mode > accesses to siselect go to vsiselect). After a context switch a vCPU > therefore sees the selector left by the previous vCPU on that hart: a guest > writing siselect, getting descheduled, then accessing sireg hits a register > it never selected, and it can observe another guest's selector value. > ``` > that's clearer. I'll take it. >> >> 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 > > Reviewed-by: Baptiste Le Duc Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 14:53:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 14:53:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449172.1665094 (Exim 4.92) (envelope-from ) id 1xH0Lx-0000M6-Jm; Wed, 14 Oct 2026 14:53:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449172.1665094; Wed, 14 Oct 2026 14:53: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 1xH0Lx-0000Lz-GV; Wed, 14 Oct 2026 14:53:13 +0000 Received: by outflank-mailman (input) for mailman id 1449172; Wed, 14 Oct 2026 14:53:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH0Lw-0000Lp-G8 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:53:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH0Lv-004GmY-Ss for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:53:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf9740-8faa-0a2a0a5109dd-0a2a4502cdfc-48 for ; Wed, 14 Oct 2026 16:53:11 +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 6acf9757-6ca4-0a2a45020019-b9ff1c229abb-3 for ; Wed, 14 Oct 2026 16:53: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 1a13ae728540008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 14:53:10 +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 4499480518; Wed, 14 Oct 2026 16:53:09 +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=VPGjiL5Gr7QmVv6D45rLscXsuEgvxRdXY0WeTbPWY/Q=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=eBpK81UR4xKL/52yZKrMbsjls9CTvbNhP2Dl2FF8OKyN7XWmfcnIO5yyRFUgEM50wysQIDDlc hIWPQDZb1iUQ+L4CODTaLdy9chAQMGsfuPfjWZQpKTqzvlTfyYp6ZeEVCBtg3G7FBoE6wWFKDvt sSi0KOEjwhZ0j1rjtLl2Dv0jAF+mMgImpxcCw9OKBUHWTP8//EG3UM5cQ5HVbyRR9V1vflsEFZd wQgItoBFp+gQw3fOyY5ogQi3xVp2V1TJoBY7qVIfRKhAcyH7qTOEqpNm4lYIDf2vlLMF1seDrmi ugcny1l2YA+bjDCYUe8ldCaeFB32SlhAzrec4uyBBWDg== X-Zone-Loop: 1f43e03f673d2efe885a1ff4ea9501d544451772dce6 x-campaign-type: default x-transaction-id: 075d6783-1ec9-40c1-9189-5ece103183be x-swg-uid: 01-0d089ff4-9070-444a-b30c-190f3acee227 X-Mailer: Sweego Message-ID: <1791989590.8631fc262581453bbf619ec5b2062170.1a13ae728540008425@vates.tech> x-swg-bid: 1791989590.8631fc262581453bbf619ec5b2062170.1a13ae728540008425 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 v6 3/4] xen/riscv: fix A/D bits in Xen's page-table mappings From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang In-Reply-To: <3e9e986b-f996-4154-93c1-a07b1f432e71@gmail.com> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886039.8631fc262581453bbf619ec5b2062170.1a134bb191b0008425@vates.tech> <3e9e986b-f996-4154-93c1-a07b1f432e71@gmail.com> Date: Wed, 14 Oct 2026 16:53:03 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791989584; l=2412; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=TT1RMZ8bP2u4E3+aUazbZoLn6grsUWTCaznTNJ6I1zw=; b=7r5jzq7Nv4Y/Ury374pGEZDuCtGbzaO6Z2JKrvWT1kputwlML6Ew9o/WH45VF8RqTqjQ6ibbL f1VtT5wJt1cABeUXuaSqEFGEn2lEV0UCbxN5X42YsgBXYVBpa2gO6g2 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: 1791989589481 X-purgate-ID: tlsNG-720697/1791989591-F1CAA2AC-82D09E59/0/0 X-purgate-type: clean X-purgate-size: 2412 On 2026-10-14 11:59:43+02:00, Oleksii Kurochko wrote: > On 10/13/26 12:07 PM, Baptiste Le Duc wrote: > > > Xen does not handle page faults caused by clear A/D bits, so it presets > > them when creating PTEs. pt_update_entry() does so, but three places build > > leaf PTEs directly without going through it: setup_initial_mapping() (the > > boot page tables), check_pgtbl_mode_support() (the temporary root entry > > used to probe SATP mode support) and arch_pmap_map() (the fixmap). > > > > Without Svadu, all three fault on first access. For > > check_pgtbl_mode_support(), the fault is raised by the instruction fetch > > right after the SATP write, before any trap handler is set. > > > > Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build > > PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in > > all cases for consistency with pt_update_entry() which sets it at runtime. > > > > 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 check_pgtbl_mode_support() to > > use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. > > > > pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one > > of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by > > masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also > > carries A and D, a reserved PTE with A or D set would no longer be caught. > > Mask with the V, R and W bits explicitly instead, and factor the check out > > into pte_has_reserved_rwx(). > > > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") > > I think I missed to mentioned that before, sorry: > > arch_pmap_map() was introduced by f89e1a170299 ("xen/riscv: introduce > asm/pmap.h header"), so perhaps add a 2nd Fixes: tag. Thanks, will apply this in next version. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 14 15:12:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 15:12:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449192.1665103 (Exim 4.92) (envelope-from ) id 1xH0eb-0004eF-7C; Wed, 14 Oct 2026 15:12:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449192.1665103; Wed, 14 Oct 2026 15:12: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 1xH0eb-0004e7-44; Wed, 14 Oct 2026 15:12:29 +0000 Received: by outflank-mailman (input) for mailman id 1449192; Wed, 14 Oct 2026 15:12:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xH0eZ-0004e1-JJ for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:12:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH0eY-00Dmgc-Vu for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 17:12:27 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf9bcc-e002-0a2a0a5209dd-0a2a450abb18-22 for ; Wed, 14 Oct 2026 17:12:26 +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 6acf9bd6-f2d2-0a2a450a0019-d155802de0b7-3 for ; Wed, 14 Oct 2026 17:12:22 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a1635f7c89so11270205e9.2 for ; Wed, 14 Oct 2026 08:12:22 -0700 (PDT) Received: from [172.20.10.5] (public-gprs377965.centertel.pl. [37.47.107.174]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1bcf3c382sm11443775e9.11.2026.10.14.08.12.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 08:12: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:From: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=1791990742; x=1792595542; 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=QRkvS7RKRi+QZMNgLcUHAXcqp4Bttdc3IxZTwLpajWI=; b=T+ynyPMMetwkNO9vOJ7V00ETpGDiqpEcIVWWN9iDoVYWlvqMtFnQnIzWTknW7gtNce IylG1+pb0ne6wuGUwc7uougd0egqBnsI4EAK9GY32JBz9zRuoTSM8PSBdr0YbYW86jqz 3/A8iC0Pi0kbYIwTHp0cVFMpkymXdPryP8LNvNh/ZmDxKcOghWp5Vhlf6n6v/UDaVJSu rotCBl579YjPXoEBjWFUYbd2kOCs3Wa0KqJoEf6GZjSZNV3c0ZWIdTXPhr7hQn8SF5KN o6S+N5cPKV6dVeiggE2F7uYxKM4htTtOrKQ7CZl8JGdyefj8c7ATjHM437IAiAq0LYnf 95rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791990742; x=1792595542; 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=QRkvS7RKRi+QZMNgLcUHAXcqp4Bttdc3IxZTwLpajWI=; b=KXGndU0/3eDVvgGbNz+vjgIYVgKCd/Fu4DOBerVG4rsliZUo/TGIhwEl9WxtHmBh0a VdLf2hD6+k8egyOwTDfMwL2Al6W1GOw3TS8GvnSMeYBNNUrvtEA0klQCG188K4FvsyUH LFMxeYUln1KzZjlwXl9wbbuchrErqOUYtrinNwQIDbeMYZwpc16mRVKAZXsKS66yMv7l 5+vtf9svVmWr8ptAoTzBGadcCy5P7Mf1eAM2JyI4rdWDl/4JcLOQAnnh3P24u+4ze3jW QSaD6Z1wP6fO2/ctEXcZrJ0nu0qGeJYpLPzDHbtOTg33NR1TJrzMv7mg8NvUbOJihtkw F3xA== X-Gm-Message-State: AFq9FYJlqVoCVxp4meYOdU/tAUAvaM/tuPxp3g+dCiAA8PH5va872AIG TgOwQyNMtiodCv5/KoHxUjGNv6vEiVm/DNG3m0+Ms4g50ORJzg9+ob0W X-Gm-Gg: AYBFou1DZjq+VuULvtWG9diBWjfHYV+RZr4Ruhk+0/KfAv8eNg+RPeoZIa41LqQUlZT yyZBdTsPPNUvtYaAu1unQNluRhyAMEXwoFAP6vVkpgtbyG9DXT8GFC3qfavKDd2FtGcJubvyX5v PEJ5qNFBwooiWZ3pBoO5nsyWHK9101RqyH39IMRq3tWvacL2Yz94VBQE1NGzkMr2Gvhk6XdVDeJ AEB9wvvtJaTZpNcTIqHDNQrFb61QhAvvQi9glFra6yc2SpJWd6N4WVDbmHNk6VNWgXbEyHNut20 i2Ll5brgciMGhbN5Vb2tRLhhtbXOOC9ithstYOg+1kUD1Ohm/8yCHH8OSTYR2wI1FEFVQALYn3d 8WEWYi6T5BZ9CAiMZXVnrK62yIpFhd9K26x4sPu6J++i2GdJGQpIVuUGQt90cpplNzcDDqb5qYX 5GRP/XUKpQ7+vItRCfzukfpdOmtg+TulOgLOAHerIoomtkcvtw9db+yzBqK10rFgCEac+ZOghtx tiDXJ//PFk1vJEMFPLl7+p1u3ZYQILK1VdWQoJ7 X-Received: by 2002:a05:600c:870e:b0:4a1:6dca:51e3 with SMTP id 5b1f17b1804b1-4a18e4487ccmr321387325e9.3.1791990741438; Wed, 14 Oct 2026 08:12:21 -0700 (PDT) Message-ID: <71144753-9c86-457e-a838-c19732c44ab6@gmail.com> Date: Wed, 14 Oct 2026 17:12:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 14/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: <1791453289.8631fc262581453bbf619ec5b2062170.1a11aefddb50003f66@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1791453289.8631fc262581453bbf619ec5b2062170.1a11aefddb50003f66@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1791990742-5A3DCCFC-0DC97B58/10/73395122804 X-purgate-type: spam X-purgate-size: 3399 On 10/8/26 11:54 AM, 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. Nothing reads the recorded value yet. >> >> imsic_ctxt_switch_to() has nothing to do: switching a vCPU in on the CPU >> which owns its guest interrupt file needs no IMSIC update. Only a move to >> another CPU does (a new VGEIN and a remapped file), and that isn't part of >> the context switch. > Nit: I think it could make sense to mention that if a migration happen, > it would go anyway in imsic_migrate_vcpu() before > imsic_ctxt_switch_to(). Probably it would be nice but at this moment imsic_migrate_vcpu() doesn't exist and it what I tried to cover by "Only a move to another CPU does ...". At least, for now I think that this part would be better to keep as it is now. >> >> 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 the only one vAPLIC emulates, 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 > Should add Signed-off-by Romain Caritey. > Without that, everything is ok from my side As we discussed here [1] it is fine to go without Signed-off. And it seems like where Xen is different with Linux (where C-o-b should follow by S-o-b). [1] https://lore.kernel.org/xen-devel/cover.1790779209.git.oleksii.kurochko@gmail.com/T/#m5063a41f8b824f28d3f9a5a976488b8308575d93 >> Signed-off-by: Oleksii Kurochko >> --- a/xen/arch/riscv/vaplic.c >> +++ b/xen/arch/riscv/vaplic.c >> @@ -456,6 +456,12 @@ 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, so the vAPLIC state to save > Nit: Do we want to always support only MSI delivery? If not, maybe adapt > the comment. At the moment I consider MSI delivery the only mode worth supporting: the AIA-capable platforms I'm aware of come with both APLIC and IMSIC, and with IMSIC guest interrupt files an interrupt reaches the guest without trapping into Xen, which direct delivery mode can't offer. As for the comment, I think it's fine as is, given how the members right below it are initialized: .ctxt_switch_from = imsic_ctxt_switch_from, .ctxt_switch_to = imsic_ctxt_switch_to, The imsic_ prefix makes it explicit that MSI delivery mode is assumed, and supporting direct delivery mode would mean changing these initializers anyway, so the comment wouldn't be missed then. I'd prefer to keep it as it is for now and update it once direct delivery mode needs to be supported. > > Reviewed-by: Baptiste Le Duc Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 15:21:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 15:21:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449215.1665112 (Exim 4.92) (envelope-from ) id 1xH0my-0006xT-V3; Wed, 14 Oct 2026 15:21:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449215.1665112; Wed, 14 Oct 2026 15:21: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 1xH0my-0006xM-SH; Wed, 14 Oct 2026 15:21:08 +0000 Received: by outflank-mailman (input) for mailman id 1449215; Wed, 14 Oct 2026 15:21:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH0mx-0006xG-7d for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:21:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH0mw-0053oM-F0 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 17:21:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf9ddb-bab6-0a2a0a5309dd-0a2a4502c3a0-18 for ; Wed, 14 Oct 2026 17:21:06 +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 6acf9de1-6ca4-0a2a45020019-b9ff1c228881-3 for ; Wed, 14 Oct 2026 17:21:05 +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 1a13b00ab040008425.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 15:21:01 +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 34C8581F7E; Wed, 14 Oct 2026 17:21: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-Transfer-Encoding:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=B4GGVUAtcvymBRSmcXiX7RuyDM8/lS8Cu9lVb56h/rk=; h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:feedback-id; b=aihvHZY/k+i/INLZHXMkzryI7rRGr3yy5e65KABxtUipYViyMYts6A3zJmouTeov3nToTdG+G VjKGYIKGJ6So7J7oWFTUMPT+pxTXE3IngDswEfzTWGNZRg6qBrKOurOLdC5+aSbLtFfQq2B6I4U UnbBXVExtphJRpn7XTjcRsRKCfbWz5k30BcFRjE+cOtlY6WZ7odGV/gCX3UoOOE6+YO/3IBCUsk zIgSpDkZbmbW+Q2ax227robojuSNXm4WuGIV0LLNgX+bQZNms6EaJZI/NmM8derhJtRVr1Uag6C t+WJy/+mIKMpyH5PxhX5hcapk4RXT1cws5Hv6n19Gt+A== X-Zone-Loop: 3f2c5525ebd1ae8b9d439a545c3b2be6cfd9f6dd2e46 x-campaign-type: default x-transaction-id: 3977e284-2166-4932-a032-201fdaca1f69 x-swg-uid: 01-7c506548-2a58-48b3-8e35-7c765836d63c X-Mailer: Sweego Message-ID: <1791991262.8631fc262581453bbf619ec5b2062170.1a13b00ab040008425@vates.tech> x-swg-bid: 1791991262.8631fc262581453bbf619ec5b2062170.1a13b00ab040008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH 0/1] Add myself as RISC-V reviewer Date: Wed, 14 Oct 2026 17:20:56 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791991261407 X-purgate-ID: tlsNG-720697/1791991266-F02992AC-0C0BB2BC/0/0 X-purgate-type: clean X-purgate-size: 370 Hello, I am working on Xen RISC-V and already review patches in that area, but only see them when I happen to spot them on the list. Being listed gets me CCed so that I don't miss any. Thanks in advance. Regards, Baptiste Le Duc --- Baptiste Le Duc (1): MAINTAINERS: Add myself as RISC-V reviewer MAINTAINERS | 1 + 1 file changed, 1 insertion(+) From xen-devel-bounces@lists.xenproject.org Wed Oct 14 15:22:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 15:22:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449220.1665121 (Exim 4.92) (envelope-from ) id 1xH0oT-0007Rq-8f; Wed, 14 Oct 2026 15:22:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449220.1665121; Wed, 14 Oct 2026 15:22: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 1xH0oT-0007Rj-5d; Wed, 14 Oct 2026 15:22:41 +0000 Received: by outflank-mailman (input) for mailman id 1449220; Wed, 14 Oct 2026 15:22:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xH0oR-0007Rd-Ck for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:22:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH0oQ-0054IX-PV for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 17:22:38 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf9e28-bab6-0a2a0a5309dd-0a2a45019c48-30 for ; Wed, 14 Oct 2026 17:22: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 6acf9e3e-5984-0a2a45010019-b9ff1c238475-3 for ; Wed, 14 Oct 2026 17:22: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 1a13b020f670008425.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 15:22:33 +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 76B1481BCB; Wed, 14 Oct 2026 17:22: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-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=A8sHI/yxdD7EGEEsGfldTNO4aLbKY4QxpUNwYX/+Am8=; h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id; b=pnA5kpo9/CXUiuJCuA6oDHi8SeCdyWWPEHUaQlr8ZRZxHFBttNb2wxxT3OEcbbvmI/VAT0Atj 0q10YIaq8d0WA8p18bExMGASnJffRkS3o/oAJbuKj+t2/m4wR4l91j21WkwOfjVTAckmBV4rxql xlPafnmCHJcXCHoluBOadN2mqSCUhjHad1hz1c0JVkJ8Tfle76jujyLRl3MdH1vJe2MFVIBaegU yvBWqjAuascqUArpokt33UEWF0jx4g/2mWdh5dc0lspn6Q2Wo4C8KnJpKNXZAnBEw/uX2wlu+y8 zQeJmz/sigMOgxfGbrILP2Ml+kUfcIAp8d5FsN7dWDbA== X-Zone-Loop: b6afe5d417ef7e7baa6cd5f81c1c16f1f6ac19b5a7e7 x-campaign-type: default x-transaction-id: 13774384-da68-4d3a-856e-45fff06d7ec0 x-swg-uid: 01-342cfded-2c41-49ca-879a-9089e3454714 X-Mailer: Sweego Message-ID: <1791991353.8631fc262581453bbf619ec5b2062170.1a13b020f670008425@vates.tech> x-swg-bid: 1791991353.8631fc262581453bbf619ec5b2062170.1a13b020f670008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH 1/1] MAINTAINERS: Add myself as RISC-V reviewer Date: Wed, 14 Oct 2026 17:22:27 +0200 In-Reply-To: <1791991262.8631fc262581453bbf619ec5b2062170.1a13b00ab040008425@vates.tech> References: <1791991262.8631fc262581453bbf619ec5b2062170.1a13b00ab040008425@vates.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1791991352675 X-purgate-ID: tlsNG-d62444/1791991358-BF86F757-2C7CA9F1/10/73395122804 X-purgate-type: spam X-purgate-size: 515 Signed-off-by: Baptiste Le Duc --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index c60afc93a5..b804434d52 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -517,6 +517,7 @@ F: tools/hotplug/Linux/block-drbd-probe RISCV R: Alistair Francis +R: Baptiste Le Duc R: Connor Davis R: Oleksii Kurochko S: Supported From xen-devel-bounces@lists.xenproject.org Wed Oct 14 15:23:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 15:23:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449225.1665130 (Exim 4.92) (envelope-from ) id 1xH0pP-0007vg-Hd; Wed, 14 Oct 2026 15:23:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449225.1665130; Wed, 14 Oct 2026 15: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 1xH0pP-0007vZ-Ej; Wed, 14 Oct 2026 15:23:39 +0000 Received: by outflank-mailman (input) for mailman id 1449225; Wed, 14 Oct 2026 15:23:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xH0pN-0007vL-DC for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:23:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH0pM-00Dp37-Pv for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 17:23:36 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf9e64-8faa-0a2a0a5109dd-0a2a4504beae-46 for ; Wed, 14 Oct 2026 17:23:36 +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 6acf9e78-b57f-0a2a45040019-d1558029d182-3 for ; Wed, 14 Oct 2026 17:23:36 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a19cba5c14so37173085e9.3 for ; Wed, 14 Oct 2026 08:23:36 -0700 (PDT) Received: from [172.20.10.5] (public-gprs377965.centertel.pl. [37.47.107.174]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0bc4ec6sm12496103f8f.48.2026.10.14.08.23.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2026 08: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=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Cc:From:Content-Language:References: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=1791991416; x=1792596216; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:cc: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=RHN1tRzj5hLAdzFo9vaN09pjb/mHMfirHqgNxfKsO3M=; b=FHGti8ns60xV4g1LtTpr+9qS3OiveO5+uzgAR7rSa/FihnA21LtYDAN4FQ90AFE85n lP7b4wrtqjT0Ae8FZlBHdJNtQK7574buBLy055vjxvD3TuWza1jEsg99eufHKKdfufvg DdaH0K6MEyOmt7Tn4swK3d9Z9RBNFqP/3lyP3tRwWddR3M43IhkuxbI3VxBA2bQUr/ss ByyeTiFdXLk4pg84fAJEU/Ed8Ok6T+B4NQaR7rLBDAHV2c3mmaV4ZySXiZ18CTzMCI3h 4bdMG5aKO2sg2q2AYQFHKnd6WFdbWFuO8cKTEr9yjSViA850YmRP7C25pid02mKt/Krj mKYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791991416; x=1792596216; h=content-transfer-encoding:content-type:in-reply-to:cc: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=RHN1tRzj5hLAdzFo9vaN09pjb/mHMfirHqgNxfKsO3M=; b=c2FmB6TKrQFZXht1X/3mUbf3CTUEg6ihg4Eh2/gRAuUx5vzP0oXm4Rj7xZkluw3dnM P5EBgZ92s2krQVOozo2zBGY9IV3VsfqqaZYpnDVhwgaLENLkY2smneixgWhIdBEnS46R 27qyFwJQbdc7ziaXA3S5fPM/bN0l9KDJyWgRs2rlRhdqK2HwMz2tFsV830pZfbDt6We4 s/OFz99x5VhI4scH20+vh8hfiMwhX8jUskUwbQjShms5ixP75wxNZd5dOCDyNTLQfA5c lN+xAJzG8lEszNMKf4blTONZHJnTrVA8GC0eAb/p6cYBH/ckK5FXRmae63boM6kuFMdE UV9Q== X-Gm-Message-State: AFq9FYJIkX6EhNWWY7i306D1wGtSSSSZi5VTj+opkkXFUUGHIN/vRuGA 8Pgn2xYKnmgv4fZHPykeT7bd0tPMeL0LJSmT05E0a+7ylFLc9KaqIaE9 X-Gm-Gg: AYBFou2Kx68mz0pwMRcDsADlLFU6wn2BV7JpklVjzoOhuq8ULTSfNPxleH7WPRxExjA 23lQSJF51x/BVaAoIzFTXzAkWJS08R7KLlXKUCEQOzjdmgp1hqEQ+KKrOp78Kq2V9rBlzDky6im 42mf9N9BwJwz4jK2n3g5cqrX+WrdH5BIu5keAjy++XwTGbT59Wxu9gfFLRN/A7nxzHE/yNXAHMi tBFQh46sFEcS7vPIeLcbbtHfGoXSeZyUPylV4SOirdOzl2dLqOy86Z6kbMp8kBD3pdM3CfXvU/l PbkUYZMXqNPTG1ky47uF1LLBp15nA1OXlvZaYURifyttdSGzzixBVMlfqYEe6ZLEsh+euLBVfYX EvhMsgo+d8zw+5Z3Cz+QsxI9Alyyfb3P6+yk2fB6V61K/fg7Zj9YZSjs40FA3fbZUSEDFay3edC v8TQT1Xb77R9Givl1wyuL5j9hgHYov2t+ZCydov79yGTzgJKovyYvPzyOMprCLasyskUcHQBRVy 6igyQgXZiGWHvrWNBDxlQkxV+z2PqZrKUV8r1qJvGGc61LWqsw= X-Received: by 2002:a05:600c:8b04:b0:4a0:1e37:ae41 with SMTP id 5b1f17b1804b1-4a18e4d67edmr316262695e9.24.1791991415910; Wed, 14 Oct 2026 08:23:35 -0700 (PDT) Message-ID: Date: Wed, 14 Oct 2026 17:23:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/device-tree: add a helper to dump an FDT in DTS-like format To: "Orzel, Michal" References: <20261012073442.15819-1-oleksii.kurochko@gmail.com> <20261012073442.15819-3-oleksii.kurochko@gmail.com> <4e820fd2-6ed3-49bc-a41b-58af36790f62@amd.com> Content-Language: en-US From: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org In-Reply-To: <4e820fd2-6ed3-49bc-a41b-58af36790f62@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1791991416-53EC6B50-CF226F87/10/73395122804 X-purgate-type: spam X-purgate-size: 7523 On 10/14/26 1:13 PM, Orzel, Michal wrote: > > > On 12-Oct-26 09:34, Oleksii Kurochko wrote: >> The device tree Xen builds for dom0/hwdom or for a dom0less domain is >> only ever consumed by the guest, so a mistake in it surfaces as an >> obscure failure inside the domain, far away from the code which >> produced the tree. >> >> Add device_tree_dump(). The output follows dtc's format so that a dump >> can be diffed against the source DTS or fed back to dtc; the value >> formatting heuristics are ported from dtc's utilfdt_print_data() for >> that reason. The walk itself goes through libfdt rather than decoding >> the tag stream by hand as dtc's fdtdump does. >> >> Dumping a whole tree is only useful while debugging and costs both code >> size and a lot of console output, so it is put under its own option, >> CONFIG_DEVICE_TREE_DUMP. It is separate from CONFIG_DEVICE_TREE_DEBUG >> because the generated tree is often all that is needed, without the rest >> of the device tree debug messages. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v2: >> - Dump the device tree generated for dom0/hwdom as well. >> - Put the dump under its own CONFIG_DEVICE_TREE_DUMP instead of >> CONFIG_DEVICE_TREE_DEBUG. >> - Pass the domain to device_tree_dump() and print the "Device tree for" >> header from it. >> - Combine isprint() with isascii(), as Xen's isprint() also accepts >> the characters 0xa0-0xff, unlike the one dtc uses. >> - Update the commit message. >> --- >> --- >> xen/Kconfig.debug | 10 ++ >> xen/arch/arm/domain_build.c | 2 + >> xen/common/device-tree/Makefile | 1 + >> xen/common/device-tree/dom0less-build.c | 3 + >> xen/common/device-tree/fdt-dump.c | 185 ++++++++++++++++++++++++ >> xen/include/xen/bootfdt.h | 16 ++ >> 6 files changed, 217 insertions(+) >> create mode 100644 xen/common/device-tree/fdt-dump.c >> >> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug >> index d900d926c555..45cff9dbc467 100644 >> --- a/xen/Kconfig.debug >> +++ b/xen/Kconfig.debug >> @@ -98,6 +98,16 @@ config DEVICE_TREE_DEBUG >> logged in the Xen ring buffer. >> If unsure, say N here. >> >> +config DEVICE_TREE_DUMP >> + bool "Dump generated device trees" >> + depends on DEVICE_TREE_PARSE >> + help >> + The device tree Xen generates for dom0/hwdom and for each dom0less >> + domain is printed on the Xen console in a DTS-like format. >> + The dump is logged at debug level, so on a non-debug build it is >> + only shown with "loglvl=all". > That's not correct. loglvl="debug" is enough. That said, I don't find it > particularly necessary for the second part of the sentence to be part of the > help message. If you want to keep it, fix the loglvl. I am okay to drop the second part of the sentence to be part of the help message. > >> + If unsure, say N here. >> + >> config SCRUB_DEBUG >> bool "Page scrubbing test" >> default DEBUG >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 72d531618045..6a20af23e1bb 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -1705,6 +1705,8 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) >> if ( ret < 0 ) >> goto err; >> >> + device_tree_dump(d, kinfo->fdt); >> + >> return 0; >> >> err: >> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile >> index 9036e455d66a..730d202349eb 100644 >> --- a/xen/common/device-tree/Makefile >> +++ b/xen/common/device-tree/Makefile >> @@ -6,6 +6,7 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o >> obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o >> obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-bindings.init.o >> obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o >> +obj-$(CONFIG_DEVICE_TREE_DUMP) += fdt-dump.init.o >> obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o >> obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o >> obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o >> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c >> index fcbeb8adbd73..24a9c6b1e3e1 100644 >> --- a/xen/common/device-tree/dom0less-build.c >> +++ b/xen/common/device-tree/dom0less-build.c >> @@ -1,5 +1,6 @@ >> /* SPDX-License-Identifier: GPL-2.0-only */ >> >> +#include >> #include >> #include >> #include >> @@ -587,6 +588,8 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> if ( ret < 0 ) >> goto err; >> >> + device_tree_dump(d, kinfo->fdt); >> + >> return 0; >> >> err: >> diff --git a/xen/common/device-tree/fdt-dump.c b/xen/common/device-tree/fdt-dump.c >> new file mode 100644 >> index 000000000000..296ae0d90d12 >> --- /dev/null >> +++ b/xen/common/device-tree/fdt-dump.c >> @@ -0,0 +1,185 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >> +/* >> + * Dump a flattened device tree blob in a DTS-like format. >> + * >> + * is_printable_string() and print_value() are derived from >> + * util_is_printable_string() and utilfdt_print_data() in the device tree >> + * compiler (dtc). >> + * >> + * Copyright 2011 The Chromium Authors, All Rights Reserved. >> + * Copyright 2008 Jon Loeliger, Freescale Semiconductor, Inc. >> + * util_is_printable_string contributed by >> + * Pantelis Antoniou >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* Deeper nodes are still printed, but not indented any further. */ >> +#define DUMP_MAX_INDENT_DEPTH 32 >> + >> +/* Indentation, in characters, of a node at depth @depth. */ >> +static int __init indent_of(int depth) >> +{ >> + return 2 * min(depth, DUMP_MAX_INDENT_DEPTH); > Can we use 4 spaces instead of 2 here and in print_properties() call. It does > look more readable IMO and matches the indentation (1 tab = 4 spaces) of dtc > when converting dtb to dts. Fair enough. I will introduce then DUMP_IDENT_WIDTH and use it in the correspondent places: --- a/xen/common/device-tree/fdt-dump.c +++ b/xen/common/device-tree/fdt-dump.c @@ -22,10 +22,13 @@ /* Deeper nodes are still printed, but not indented any further. */ #define DUMP_MAX_INDENT_DEPTH 32 +/* Spaces per nesting level. */ +#define DUMP_INDENT_WIDTH 4 + /* Indentation, in characters, of a node at depth @depth. */ static int __init indent_of(int depth) { - return 2 * min(depth, DUMP_MAX_INDENT_DEPTH); + return DUMP_INDENT_WIDTH * min(depth, DUMP_MAX_INDENT_DEPTH); } @@ -161,7 +164,7 @@ void __init device_tree_dump(const struct domain *d, const void *fdt) printk(XENLOG_DEBUG "%*s%s {\n", indent_of(depth), "", (depth == 0) ? "/" : (name ?: "")); - print_properties(fdt, node, indent_of(depth) + 2); + print_properties(fdt, node, indent_of(depth) + DUMP_INDENT_WIDTH); > > Other than that: > Reviewed-by: Michal Orzel Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 14 15:35:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 15:35:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449244.1665138 (Exim 4.92) (envelope-from ) id 1xH10X-0001r1-LE; Wed, 14 Oct 2026 15:35:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449244.1665138; Wed, 14 Oct 2026 15:35: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 1xH10X-0001qu-Ia; Wed, 14 Oct 2026 15:35:09 +0000 Received: by outflank-mailman (input) for mailman id 1449244; Wed, 14 Oct 2026 15:35:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH10W-0001qo-5I for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:35:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xH10W-000000055un-13Aa for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:35:08 +0000 Received: from mail-lf1-f41.google.com ([209.85.167.41]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xH10V-00000008yWK-2IgP for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:35:07 +0000 Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5b2b92065ffso751725e87.1 for ; Wed, 14 Oct 2026 08:35: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" 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=pijeZMwR9Rc08JPKbfXK+fA9Ya9hd3rJ9pW0xe7b4cw=; b=mUSju1AoPYaGxcwLa+zTecOkeY UyAdacD5jmXyu1Oozp+KoR5Rk6LsDiVzW7vEklvP+YDwE04MD9NV4N+eHihk60BTMPrsiQxPudeB9 DtkwL/5whBMZGX3n9au6vxMUwHFJf3RZ2mWRaRWEtyASzIk/5nMkRHvifjTUHdf4RlK8=; X-Gm-Message-State: AFq9FYLNDdg4Os2CmjNn7tZ5Ic10R5TZV+H3uGJjCYiELHqkWKJNSnch 0y5raBM3ODt7BRv82Zr4mOhjZkxRfeaKBz79CJUBgjgPyGhsveZAs4xCSkxUqnFwBsmxo2ynhnu Wzh7MWTpA2IBThJIobk8yyZVsnUHBTIQ= X-Received: by 2002:a05:651c:a204:20b0:3a7:812b:cfc with SMTP id 38308e7fff4ca-3a9c5362e82mr27275031fa.14.1791992106917; Wed, 14 Oct 2026 08:35:06 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-16-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Wed, 14 Oct 2026 16:34:54 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_rKXmfoec9aUc2WV0056dzsUIbSctKYJO5BdG-fW4swc_jGuU32MbLQsc Message-ID: Subject: Re: [PATCH v3 15/18] x86/mm: flush owned pages before reuse with the sparse directmap view To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 8:00=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:48AM +0100, George Dunlap wrote: > > Since d7bf1b8ea275 ("x86/mm: limit deferred TLB flushing to PV domain > > support") a page freed by its owner is flushed from TLBs before it is > > handed out again only in builds with PV support, on the premise that PV > > domains, with their (limited) control over the host MMU and over when > > flushes happen, are the only ones to leave stale entries behind. > > > > Xen's transient mappings of domain pages are another source. The > > mapcache zaps a slot when it is unmapped but defers the flush: the > > slot's translation can stay in the TLB of the CPU which used it until > > that CPU next flushes, by which time the page may have been freed and > > handed to another domain. Before "x86/hvm: introduce per-vCPU > > mapcache for vCPU-PT domains", only PV vCPUs use the mapcache, so the > > PV condition covers it. Now that the vCPUs of an HVM domain with > > per-vCPU page-tables have one as well. > > > > While the full directmap is loaded in every context, stale transient > > mappings only map what's already mapped in the full directmap. On the > > sparse view of the directmap, a stale translation of a page handed to > > another domain would keep it reachable from a context which has > > nothing to do with it. > > But if it's handed to another domain, then it also hasn't gone through > a free cycle, which is what pg->u.free.need_tlbflush covers? Sorry, the wording there is a bit imprecise; it should be "a stale translation of a page *freed and then* handed to another domain". Apart from things like steal_page(), which doesn't apply to HVM guests AFAIK, there isn't any way to hand a page to another domain, is there? I guess there's dom_cow for memory sharing; but that's experimental. We should just document that ASI + memory sharing isn't supported at the moment, and work out the details when that's wanted. > > So flush owned pages before reuse wherever a sparse view is > > configured, as before d7bf1b8ea275. In builds without PV support, > > mark_page_free() now also asks a new hook, > > arch_freed_pages_need_tlbflush(), declared with the xenheap hooks the > > sparse view already uses. x86 answers with sparse_dmap_configured(); > > without CONFIG_SPARSE_DIRECTMAP, and on other architectures, the > > answer is no. Builds with PV support flush as before, and HVM-only > > builds keep d7bf1b8ea275's saving unless a sparse view is configured, > > which nothing does until a later patch. > > I think this is not fully correct, in fact I think we need to flush > the map cache on every return to guest, otherwise you risk leaking > contents between processes running on the same vCPU (and by extension > the same physical CPU). > > We either need a flush flush before returning to guest, or we need to > invalidate every page that unmapped from the mapcache. This is a good point, but it's raising the bar significantly in terms of what kinds of attacks we're trying to defend against. Stack rubble could technically contain sensitive guest data, but is much harder to take advantage of than the full direct map, and XSAVE registers in the xenheap; so it's delayed until later. I think this is the same kind of thing: Yes, pages mapped by a hypercall may contain sensitive data relevant to other processes, but it's kind of like stack rubble: much less useful. My recommendation is that we put this off, past moving XSAVE out of the xenheap, and treat it as another level of safety. -George From xen-devel-bounces@lists.xenproject.org Wed Oct 14 15:38:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 15:38:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449253.1665148 (Exim 4.92) (envelope-from ) id 1xH144-0002dK-3J; Wed, 14 Oct 2026 15:38:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449253.1665148; Wed, 14 Oct 2026 15:38: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 1xH144-0002dD-0O; Wed, 14 Oct 2026 15:38:48 +0000 Received: by outflank-mailman (input) for mailman id 1449253; Wed, 14 Oct 2026 15:38:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH142-0002d7-Iv for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 15:38:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH141-00Ci13-SY for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 17:38:45 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfa1ef-2eae-0a2a0a5409dd-0a2a4508b214-38 for ; Wed, 14 Oct 2026 17:38:45 +0200 Received: from [40.93.196.27] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acfa203-f659-0a2a45080019-285dc41b39f2-3 for ; Wed, 14 Oct 2026 17:38:44 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by DS0PR12MB8786.namprd12.prod.outlook.com (2603:10b6:8:149::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.24; Wed, 14 Oct 2026 15:38:37 +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.0522.012; Wed, 14 Oct 2026 15:38: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=v/RN8EGAA7McmV7Dyz9Y+AMnhY3EHqRHFP4Ev1jbBHHvTptI61mJtStVEeci+cm06sEH4tPX9as24feY0gzwbGKBnWabB2C0ruPBUhy6AESxMtgXTEThTDxIarxGrum1wJV34LLVaEMQXts5AXYjXWxxMBwykW7LVITCvq89xtxEI5/Sse7hoyG7Q44c/dxzKEdvp4tVlEWizVkQyCnfMMq9vNJjZUAl3wmvZg/7OAUCM/Lj0Rfx3wLi5EPLbplbknhS9lB1XMhoGnz4G1rYvocT4pr+LGbCYCSeZU5BR1pdWCE1+rBGCW7nC1WyNMhmN/qRdiFQ8NIIZHNkbG9vVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3LSwPFSlpzghr8qm+OHlNG5Ddb+PXeY5PcnfiGoE8vw=; b=C0fur5BdICPxZiCjeSfDWldaub7Mi4ro2z61XnJoFsKK2oUcdhfDAUb4zURudMuolAAaHHDdCTfQaByv/rtDEng5TzBa6H3jR2noHefCVPY8Y08e8nf0rc8sEcsXakbI+4uJVxvcHqxTl4HQ89EElJeXAw19xFpzfRVR1v0Pse6lfIiLt4SOvnv/SoikDzk1LXpb9o9mXGgbT2Um8iLXC9ekhSk3ysjqmmMDrZOZ4KraZvuK6BGtiR3m47g0MFqnNgBgcFPafc2o9gp8IpIp2z2TZvwd3fqs/4r1Gx8FrxfL78n/W/H2hRFjjDnI+RSOAqJgH1rdnrDTySMBNRelUw== 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=3LSwPFSlpzghr8qm+OHlNG5Ddb+PXeY5PcnfiGoE8vw=; b=xQs319DR0amrPGwlKnL0iuPPDZgrf/9afNdTdGtCtvRdIRagfSl+wD3trsI3nayGvfUMs1yliaDFreP0aIgsJUeXHEOKK79+sax81tkll6iy4WSEFbNVKKt+avnYeE6YknjpAOAFmTNGCdo5LvKE7/hv07RVolAKO865RoibhYo= 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: Wed, 14 Oct 2026 17:38:33 +0200 Message-Id: Cc: "Andrew Cooper" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Teddy Astie" , Subject: Re: [PATCH] x86/atomic: Fix UB on various atomic helpers From: "Alejandro Vallejo" To: "Jan Beulich" X-Mailer: aerc 0.17.0 References: <20261014133551.622462-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-ClientProxiedBy: MR1P264CA0012.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2e::17) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|DS0PR12MB8786:EE_ X-MS-Office365-Filtering-Correlation-Id: e09288ab-b65e-43d0-f0c2-08df2a0936aa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|10067099003|4143699003|56012099006|11063799006|22082099003|261009223027099003|18002099003; X-Microsoft-Antispam-Message-Info: m4RnrH5UFS2U9eemUcBu1jB2940O8bBvkxTfM06TrU1ip89cYtaAdtkH/aw1YdMlGHObyEFY26sM7VM6UQZQc2oTbThPLYg8H1L7duvfWH/SRRredV/swWICrzU6JJgdK78BbpooNZBxBM1kYwR12OxQPPHdv+gRK88bg+GmyJDCpChjZ2yovV+XAWBJfVHjYj//We7mmnkcU78ipLCbe5BNvGZTTyfGHDXsiEAMLDb/6qoJKf2NQw30F6Hob3WIFpanIR9AcAq59V1hZ44w9QlzEq9G5n3pC80f42OsGjSIM3UAba6e1c72hHjpwdH5GQdHErL/bi5fB65g14uQ29C8fn9v5HPlrtZRdkaRRaZ9vTUVNLnhfRU+vfujfqnZjoFgr9fpyNUzSHom48vS59lBe+Cr7Bn/hNT2cjC9UuT+H022IiqBxyMM0KrQnpqHq7XVq2JeN/I8POoUZ7wl3jL3TkCtDeMiUN/Dw/p4jpua8tcbhIO30e2yw551Nfr8HDrvEGKfaE+reMe5Ybq46029HjcT/Mxr1aBeCYeikKa9rCRd+Ar8ssv/f02C1PlY5LHT8nz9IGN1wUJH1TX7W7g6pcX28aFT++G/4NNJKo5bcGwGZJhVJuVKTnE5dEuQRh3PuT7sFGSeXGuPuNtThnTQzZgEp0C7rjocERmYOGc= 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)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003)(261009223027099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZFc0b0Q4ZERuOG5pcWZsYjVaODZicFhjcmxzbmlsRVlsZU14Z0ZsMExDOFAv?= =?utf-8?B?TFFJVCtIQUVrTzFpekI0bnBTRCsxM0hQcFRBKzNMQnd1UGttSFRTelozNXBl?= =?utf-8?B?YTZ3VGpnRDBDTW5YNThzSTZTNHk3MTVTUWswc1B2NG1QbTNHbVRqTVBFcGgv?= =?utf-8?B?OHhVMThnTTc4eHZaWGgxeXN1ZCtjL2l2RWYraW5pT0NDRXBDczlua09vNUZG?= =?utf-8?B?T3gybTRGUVUzNmtaYmhvQ0RWV3Fad3FZZlJ1S3Rra0Jnbm9HU1E3ZG0xU3Vx?= =?utf-8?B?VFh2OWZnZzBTNU9vbHFYU21zTm5JNVBDb3NKa2xoNmltUXlRdHE0cnduTHd5?= =?utf-8?B?K3BUcktudGlrRERmSkQ4MGtOV2JGc0k1NEVwM1p3OUF2MEhFZ0RjYks4N0ph?= =?utf-8?B?cmdSdURWSFBFb1NkWDBsQnNCcmUwUzNveTFEWDJOanlSVThleWxDazVteXc4?= =?utf-8?B?alh2M3k0bmZlczBiMHRTR3d4elo2bFFabldUbGNicDd5ZkNpaFkwb0hZcEU5?= =?utf-8?B?RERaWnkyTTdQMk1sdm4yYWZaSjBJYy9CUUp6R3RDaDlNZTJYTUt6ODdXekw0?= =?utf-8?B?RnlZeStxSml0WGY5MVdDWHMxQ0xPZW03U05SZ0ZBMytpbmJ2VTdwZGtIbTQy?= =?utf-8?B?NkpDSE02VjVqNDRBUWxNaUJqa2k1VVNzWk1TMEhJN2Q3bE9KbUxDbWM3aTN5?= =?utf-8?B?ci9EaXNvamRNWnZTazVzcXVzOTJJUWZKck1KOFJ2eGQ5M0NwZ2ZOWmNqOVQ3?= =?utf-8?B?djJyY2RBYnJpMGtPaGVRa240c2RsRkdza3NRU09UWFVaVnpTS0wvN0dBWVJV?= =?utf-8?B?RzBRenM3ZjAzUWtOWlNBWW5ZeHhGYTU0TWE4YlNnV0U4TlZjV1pwWVRUWmt1?= =?utf-8?B?bHpBVExValZCeVptOGh4aFR5VFAzVlVaMG9RdHlRQVZBekRWM0VOSE55U2JY?= =?utf-8?B?V3UvVGcwS3ZPa1pTOEorakVqSXRjdUR1QUpUL0ZqZngxZnhuRis5RlFla2ND?= =?utf-8?B?UWJTT2tzeDV3TzZUNUlTbzhOVDZ5cEF2NGUzdFh2bTZRZWdZaUFiL1NGNG1B?= =?utf-8?B?VDVmSFFjRDFyVXFlaXNjWi94VWRuem0zc1ZnVXFzOXRhS0FmVllMSmJnN3Ey?= =?utf-8?B?dytYdHVlK1NEb1pPYjJENm4zSVhmQ01aRW83K3ZOeDd4dDhOanhRSC9qbERi?= =?utf-8?B?dzM2NGpyR3piRFlsTUcxbUxFSkE5dlpkWFBOcTJkLzlNZmRpU2hCWW1zcXhJ?= =?utf-8?B?RS9Vcm8yQlZFWHRmdmNEWHphZTRSZ1ljWmUrWFNsajRyRTRkSkFlay9VM3NO?= =?utf-8?B?L09kUllCR21tc3RTVFUxTjRwNTArSk5OaWJnbU5IZStJb1BIb1A4ZkJOMTZa?= =?utf-8?B?ZGFXUisxVGJhVmJWU3MxMmo2QlltcytsWXQwdEtDTXNOM2RnL0hhdXA4UHVy?= =?utf-8?B?cjl0cTFTb3FBYklDa1hwQ1daL0M5NmI4RFEyL2xMZjc5OWpCQTRKNnZ4UndD?= =?utf-8?B?dmx1R2RzYk5hRzZCeEltc0VlUGs3S1pWa1dKWCszUGU3NDV4d3k1ZUxjUTZY?= =?utf-8?B?Tks0TlZpbmRyZWRtVTJHaVYxbk03bHJIdDBnQ3VoSmdiYzE2b09la09RZVVk?= =?utf-8?B?R3lzSytHQzdIU3FjUnpURC90NCtmd1lLcmQxZkNqd1kvQXlxSFNleFRQU1F1?= =?utf-8?B?Q0NMbWRwSG5IaHU2N1dpaFNGNEZRQ25ZRXpGMXkybFpSV2RhWEpLRGQ3TDBv?= =?utf-8?B?dHRUQ29WTm92NFovZUxDTjZJK3A2RVZvNVdKN0JQY2lGeHJ4Uy9VbzFKY25v?= =?utf-8?B?NlM3eWJ4aUZxUVZzbXJaaEs4ZUhsRVJrRnoxVjRHTHp6VEJhSWNHb3VLWTAx?= =?utf-8?B?RkF3S0Y2LzdrWkRsSnUvckN1bC9uR3JlVVlLMTB5djFsNnd5T2dLMEZBU1lp?= =?utf-8?B?SXQvSTVNT1VPeUhLQmZtMEM4aEZwZWlmakV4TXhGSUJtT21OR1hpYzlzYUto?= =?utf-8?B?TXkrVWRVR3FsN1RjM3dVODg0NC80ZXk3alh1ejMrOUszald4a09sTGJ6Skl5?= =?utf-8?B?aUFSeW1OV3pIS0JLRE9EV1U5c3J5cnFlM2VLU3pVWU9Ucll6YmllTGtraEVP?= =?utf-8?B?ZXlWUDVITTJiS21FOXhSVDR0c2tqaCtsMHNiQzNwVTFHcEw0SmVDcVM4NGYz?= =?utf-8?B?MFRtb0ozSU1hcjlLZDJFa0ZpMzF0NVk0UVQxUDlSeEMydFluZUx6ZEl2M3oz?= =?utf-8?B?K3pyWjgzL1dTRSswVDdhRUVwWE84WUMrdmwyWWNKM1B5dnJ0ZVNnTjFCdVlw?= =?utf-8?B?bnZrcm55U2tvWHJNQVFKRWRYVjVPWGJzOUd4RlFvd2NnSXJOSjYxQT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e09288ab-b65e-43d0-f0c2-08df2a0936aa X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 15:38:37.2208 (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: 7td1J2ode6xiLUVIhY+owp/SuKrLLJ+kBwj9Acyu0OQ7HoD6XbtdLRM+KIjdwJZakQ+9x6VoWymxZuf3xUKcpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8786 X-purgate-ID: tlsNG-c1860d/1791992325-D674387B-CF82CA23/0/0 X-purgate-type: clean X-purgate-size: 1483 On Wed Oct 14, 2026 at 4:33 PM CEST, Jan Beulich wrote: > On 14.10.2026 15:35, Alejandro Vallejo wrote: > > --- a/xen/arch/x86/include/asm/atomic.h > > +++ b/xen/arch/x86/include/asm/atomic.h > > @@ -122,7 +122,7 @@ static inline void atomic_add(int i, atomic_t *v) > > =20 > > static inline int atomic_add_return(int i, atomic_t *v) > > { > > - return i + arch_fetch_and_add(&v->counter, i); > > + return (unsigned int)i + arch_fetch_and_add(&v->counter, i); > > } > > I'm concerned seeing this kind of change: It's merely papering over an > issue in the caller. There's not going to be UB if the caller passes > suitable values. And the atomic types hardly are meant to be used in > contexts where overflow could occur. > > Furthermore different parts of the C spec say different things here [1], > [2]. Hence whether overflow in signed calculations is undefined or > implementation-defined doesn't become entirely clear, according to my > reading. I won't dwell on interpreting the standard, because I only care how GCC and Clang developers interpreted it; and that's a hard trap on signed overflow with sanitisers enabled. I can live without this patch (it's just paranoia), but thinking about it some more, perhaps we ought to pass -fno-strict-overflow, like Linux does, to the compiler. This brings forward post-C23 overflow semantics and removes this whole class of UB wholesale. Here and elsewhere. Thoughts? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:25:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:25:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449293.1665157 (Exim 4.92) (envelope-from ) id 1xH1my-0003GS-Ck; Wed, 14 Oct 2026 16:25:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449293.1665157; Wed, 14 Oct 2026 16: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 1xH1my-0003GL-9u; Wed, 14 Oct 2026 16:25:12 +0000 Received: by outflank-mailman (input) for mailman id 1449293; Wed, 14 Oct 2026 16:25:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xH1mw-0003GF-5b for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:25:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH1mv-005Des-I7 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:25:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfacb6-e002-0a2a0a5209dd-0a2a4505c2f8-40 for ; Wed, 14 Oct 2026 18:25:09 +0200 Received: from [52.101.52.33] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acface3-4cb1-0a2a45050019-34653421c32a-3 for ; Wed, 14 Oct 2026 18:25:08 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA2PR03MB5785.namprd03.prod.outlook.com (2603:10b6:806:119::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Wed, 14 Oct 2026 16:25: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.0522.012; Wed, 14 Oct 2026 16:25: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=rhde1GgxnulClbazuzhpe//BITAhBY+b9EAdJ9M1JzkvBYQZWFTNMykhH3q/9tm9nQj7SYJlmgSUte3bTtuT8VRYEV+botYK9MIqAvlOu9T5cQoUkHag1FQYW+jZTCaukfMXk338o5Q8qGgbjbTmaoesaP8SxpFQ8meIc2KbfFy5A27RzV0hICMwISjTk9K+/i6p9ClwgZfwcpEpcJ7lt0+WfdGaUdyylX7/iSvvKqxF14KPfGD6dzdIis8u0u5rCI0oHHlL7b1xHmW79tebkuCFRcSYmHaGLO76sa6sNxwaSo5Z3J+T60HCMdmXgNxGmyIQyQFQjgaHlPJhZ3nxtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jXSOxE0ZUMiWAHO4dVTQ2TAdO96lp407qOfgCHqca3I=; b=Vo1RrUAYTuKI4PDKY3RVRdx8eGWCz/3R3JtnJv8UuvAgRG71URwnJNJ1zo041mY0C7djpIBbZyvoOw9prusBXlLWHCI0TyfQmJ9XHgdHFcunXYHYVNOeey2W+dxy4ZW7O9S7K6QdMydqi7d1nhUIX3US+WHkktTFUjb4pTSItfmdcwBt8vCNYEkIEr4/y10sWWxRCmz/6IWb3yFfDNHPcLVDaybfRzXotC4ffYQQ+u0xwfNHB/neUoSqHi6w3xItibwVLMkEteQX1j1XC36RUq+8HHcWrPS/waCzn7vcv+X87dUWI3hGEKuy7y5WcsQ9/pojbBGD53lYjwv2sJNSQA== 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=jXSOxE0ZUMiWAHO4dVTQ2TAdO96lp407qOfgCHqca3I=; b=ooG9oNYTOAhEYdrbv1rWLpkhSLvJeCgtWftGhpVL4DT0UWnsc4Fws0FwLjp9d/7natOzpqrdJyFf27Oc9XsoTh/1pQvNg+H6YsUguSqGTUBkAVFmhnqncUj+PxwmnnkqgzLjZcJo63y4/uQWuIJA0W7GO44h5owd74Y4COJS4BM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <8d4f9d39-f80b-43cf-91a1-033a8bca777f@citrix.com> Date: Wed, 14 Oct 2026 17:24: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] gnttab: drop bogus check from _cache_flush() To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <6d0acc68-9d07-4e0a-b27b-0095a51ebe42@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: <6d0acc68-9d07-4e0a-b27b-0095a51ebe42@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0251.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:350::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_|SA2PR03MB5785:EE_ X-MS-Office365-Filtering-Correlation-Id: 442edb3b-989e-4efc-2363-08df2a0fb1dc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|56012099006|11063799006|22082099003|6133799003|10067099003|261009223027099003|18002099003; X-Microsoft-Antispam-Message-Info: 8BWgXFCUUO9R/u8EYLOf7sWxEX+LkkEZrLHZKlQ2SZBybkha2IMnaZB72WTUb+DoqqWpisNHpMZ7KXbQSaLbous2pUPoflw+xjkbsyBxR/J299fOOZeHDQYO+jD7U+i+IxdYocL0wSnjVRSu0HXlVHtr4hRcRSFMsXsvK1lNo2WXy7XHkHYEqL6fJhvTnoIWnAAp6raGVXSKZ4fchCQKWm6dRXdYXkd57YlkA49F7+g5oSAd7t3XqcGuBmu+7iBSiTPL3VzPyaKTcPR8b7YNfI9mEMTn75LR2ObOO0EcX1hZkbW5gc+nrYchWgI1CGFMRdfWYisampP0n8jfDE/GNodo7i0shGChMB46ht09wZRQMRH9dtkuf/dE/xumO4Rntmvmj1goVrg7/ZHM8zETAU1MWen8KvOYKhw7avZE4sTA7EIyxFORRUoBxfqXogP4EiozFs/9sws1hWYwlIt08xsrNshRPN66mdMuC77G3pZ6EXpZZpbddhk5hvb2dFFSPu78LEWigldQ7wDB0RcW/DhxLfZx5/15+xJdtInPcP31cjS2QgRtZy99LqJsy6YUgTKh+YtYda57TL4SbVXUXIB1wBH2vjqrIWkFQdBcjF6+QgC1UJ00PvZDYqxaR2DVHD3ryGnahYhTg41Brsn0Ov6kkqWHvypi9YHVjgH91oA= 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)(56012099006)(11063799006)(22082099003)(6133799003)(10067099003)(261009223027099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T2ZpYW83dGNoUDhybWxDUnNQcURaZCsrMnVFL3VyVVpaU2s0NkRwek5zeHRw?= =?utf-8?B?MWs0SWlTbmhxYVZiSTRHT1p4RHFrRHNUN1JtRHBtRE9LSnBVZ0VaK0M1M0pt?= =?utf-8?B?VnVyZUR0OTI4MVR5MUk4L3ZROUovUGQyODBNaHRxNVAwN01YamhPWXlvOFc0?= =?utf-8?B?cytBN0hxeU9jQWZRVnRWNlIxQkM1bC94U0xnTG1QUjZNcDhwczJUWGtvZjlD?= =?utf-8?B?UWVrSHJCRTRPeHhjRklXOHp5QnNuRWdhaWNRZUd5TFJpaXVBbFdqVktvekZV?= =?utf-8?B?OVY4Z1dOWGFmNGNEZzBwOUhxeHJkRWZCdTVId21xaXN2Z2t0NlZ5MUJETlFT?= =?utf-8?B?Qi82VzR3WGh0MU5RVFZLc0ZnRVRXT1FNRkZGSnA3Y1NVVCtOanhmTEhVVFh1?= =?utf-8?B?S3RWMUFqV3MzSWlxNjZNVjU2Z0M2Z0ZFdXRPZllnc002Z0FNZlYvcVdqNDQ0?= =?utf-8?B?ZVBUNktZZFcwdGpTYkF4VE92MmdUM1Zzb2JLSGtQUEhJb2Z0NFBEb04vWHlx?= =?utf-8?B?cytmNnRTUnpYSlNvaGoxVFVMQU9aWXhIRTZOSzVxWXQraStuWEFlYXUxcGFG?= =?utf-8?B?cU16YjM1eHUxMHBadnN1ZXdFWnNDVnZPZW9sVVExeXJNenZoZkdycGpyZHZM?= =?utf-8?B?T1c5eDZIQmpXOW1MRFU5bVBqT1NVVk0wa1k1LzBUNkNkN2NWR2VsNS9xdnA2?= =?utf-8?B?amRIMlZFbXNEL0NnSW9ZTzlNUk9wZjA2QytNbEk4ZWE1TG0xS0did1VJUjJh?= =?utf-8?B?enpPa3Y1eENFdTBoV0ErQ05vYWhsemtNejNpY3VQdmZhTFRGVEY4ZDFlTzNo?= =?utf-8?B?azJMOGxhNld4dVpYdGVsZHFkNXBwd21NbmdaVG54eE9CQVVqYVNvUWRNVmwr?= =?utf-8?B?cW9zeHJCOEJFZHRsWFBrV0hzcVlWcTBTNDloM2xrRHo0cWl4OGV0YlF6N0xn?= =?utf-8?B?ODY1K291RFZ3ZjJha21TdnI0cDZ0blNUVlI3dlprNWZpOG51eUgxTEdzTnVT?= =?utf-8?B?amJvYThsL1ozbnJ3citpUWdpdlF1NVRPblp0TDZ3TWJNcDF4MUgvaExaSkZN?= =?utf-8?B?aitrOUpaOTJhT3FJcXJuVmQxTHhPV3FtamgyYVdkSlgyMWtMN3JaK21qeU0r?= =?utf-8?B?WlB0cGR6WG9HQjZ3VXp3Y3g1bnA3enpiVGw4WnBGVEQ3eGlwNEM4dzJ0YXJE?= =?utf-8?B?YnZ2TENsck1yQnIyb0ZXcFRhWjZ5VHY5YnlTY0YwTUluRUovdzJQa25xY1dP?= =?utf-8?B?QndYREw0UFFyRmdsY2dBYXlZWHBKRS8wWDRyd2pxM1paSUI3QVNWYmo1SlQ5?= =?utf-8?B?cC9MdmxxVzZVeUdhd0V3a1A0ZVZpdmNFT2lrWEVkT3hKSkxhYjhLcGxDOXNR?= =?utf-8?B?RkExaEl4VFE4TGtVVXcya054M2hXSmgxZDBiUlBCaXFsUGxoaTJySW5ma3py?= =?utf-8?B?NkV4RHpieE8yYnd6WkZSZUgxTFJNZE9RcUh1ZTRIRHo2eElxV0dSVnVvSm43?= =?utf-8?B?ajE2STViWnpnZk9LRkwrbHpjcDZrMmp4dE1QU0pIemtNT3dRUGovc3c3RTh2?= =?utf-8?B?S2NmMW1wT3dYVGF3OUlZZ1N5eVIxa1dnMzdzd2ZNdU9UdENPQlplWHp0bFM5?= =?utf-8?B?ejhTWkJWSkFpb0prT2I0VjJSaXo0cHV5cDhlWk9zVFFGWDhNbUd1cWJBbVlB?= =?utf-8?B?RG1sYk16MnNYa3htcTkwN3NHdUR3NVE4SUorTDhQWVUvZTBESzBIZVcrNStt?= =?utf-8?B?NnREYk5meTBqRmZ5S1NCVkVZdUFkdHloN3IydGJRLzdPZE5OQ3ladlJxSUUv?= =?utf-8?B?dUhXT0QyUi8veS9VZEZ2ZHE0blNXUmJRWUNPTWlJWjNqa21LL3o1ODB6SzVy?= =?utf-8?B?aDNFK3I0VHhleFBpWldZajRRdkhGOXpEU3krSUlLUG9UeHhOcmpwczIwbTZT?= =?utf-8?B?bVJ2cTRNV3BsNm9mdGZvYnAxcTVQbWRybHFmWEh3RWoyK2M3TzBaeWZNKzJq?= =?utf-8?B?SFhBVU54cUJza1hVSC93eXJqQkZ5eFNVUEJ0bDRHelhwVUlIc0ZxR0ZiYTFI?= =?utf-8?B?K3M4djJDbC8zNml1UHZ0emVWdURGN3JxaW5jN29JcTR0ZTFnUVZraytPeXp6?= =?utf-8?B?RzkwU0Juay9vQWNSTHFMYWx4RzhVRWxpOGJ0Q3J3TWIwVWUyaGxxSkdydlJs?= =?utf-8?B?Vko5dXhhbWVIUlNXaFlYcFNCZmQ5VE1kMk1Ka21rWUdRS01DSU9SbGx5ZDVQ?= =?utf-8?B?MjF3SzB3NGo4T0JuWk4vRS9ydnd4Kzd5dS9YeHJnV1YzWTRGaXFiV2JoaDFZ?= =?utf-8?B?YU94YkVQR0Urays4Y0VqdU9hR1N6bFc1Q0ZzRkM1UDJZc0ZkMXJpRkMvdklE?= =?utf-8?Q?3Tv+pV0+Z+ZYDzqU=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 442edb3b-989e-4efc-2363-08df2a0fb1dc X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2026 16:25:00.8811 (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: qqJa46KLUfuQOm6/bmEw0qX6bLbThrg1MZNPkmBq0yD7ZEtEH6j3U/bbQbPKaSpZpJ9bEfuh/pcjpUUj3yy7Pxn8+Kd3XxZM0nPrm7gqias= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5785 X-purgate-ID: tlsNG-c201ff/1791995109-726B52A1-799C1EA2/10/78276251493 X-purgate-type: spam X-purgate-size: 1208 On 14/10/2026 1:52 pm, Jan Beulich wrote: > There's no such thing as an alive domain without ->grant_table, and system > domains (on Arm) don't own any pages. The check should also not be left > there "just in case", because if that check could legitimately yield > "false", the page reference obtained would then need dropping on the > subsequent error path (see XSA-520). > > Reported-by: Andrew Cooper > Reported-by: Yehyeong Lee > Signed-off-by: Jan Beulich > > --- a/xen/common/grant_table.c > +++ b/xen/common/grant_table.c > @@ -3637,7 +3637,7 @@ static int _cache_flush(gnttab_cache_flu > > page = mfn_to_page(mfn); > owner = page_get_owner_and_reference(page); > - if ( !owner || !owner->grant_table ) > + if ( !owner ) > { > rcu_unlock_domain(d); > return -EPERM; Do you remember that I already posted this patch (to the security team), and you already reviewed it? I'm afraid that your commit message is hard to follow, despite knowing the details.  I already have one prepared from 3 weeks ago which I think is rather clearer to follow. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:37:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:37:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449314.1665167 (Exim 4.92) (envelope-from ) id 1xH1ye-0005m4-Gy; Wed, 14 Oct 2026 16:37:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449314.1665167; Wed, 14 Oct 2026 16:37: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 1xH1ye-0005lx-DV; Wed, 14 Oct 2026 16:37:16 +0000 Received: by outflank-mailman (input) for mailman id 1449314; Wed, 14 Oct 2026 16:37:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH1yd-0005lr-5V for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:37:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH1yc-00C7k3-IY for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:37:14 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfafb8-bab6-0a2a0a5309dd-0a2a4508e31a-6 for ; Wed, 14 Oct 2026 18:37:14 +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 6acfafb8-f659-0a2a45080019-aceafc1fb7fa-3 for ; Wed, 14 Oct 2026 18:37:14 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4A7DB4138B; Wed, 14 Oct 2026 16:37:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 258481F000C4; Wed, 14 Oct 2026 16:37: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=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=1791995832; bh=D0qFplMD3JegnW7i3iVJkwgfMDmyoOPsyHFrtj+nxBA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=n9IplbiX+93nceH23XmnKeZ5oYecY++a3sP1FSp8/eoJQHlwosXybufpa8S8KQDs4 JSOYDlE3dW0Tstqig9001fDQnyF55nygDlSOHNkJdYmGR6xIoM+nl1dQhuyjrtkVwj EuXqe73P+3VZ6BDKW7wiUBDkX32NJU8qFo902yMRcaug/7BAm5oKbDw4gxCh7LxUqC Y7NxYDYR/y/z28DqpEx8zGTH0dUYz2jKMESyevlBsADLYmloXFD5sbjroBfTPOb1YO EAaIr8VM2TPJc/hDXYqOW71XwpeyatwvwVWF6WB1T2qG0eJVVmvgIrJgOh3HFB8l/2 2qpSERGwTKhRA== Date: Wed, 14 Oct 2026 09:37:11 -0700 From: Kees Cook To: Greg Kroah-Hartman Cc: Ian Rogers , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release Message-ID: <202610140932.5F9CFCE5@keescook> References: <20261013223946.1836757-1-irogers@google.com> <2026101425-why-boring-4f2d@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2026101425-why-boring-4f2d@gregkh> X-purgate-ID: tlsNG-c1860d/1791995834-CF55C87B-2D44C7DA/0/0 X-purgate-type: clean X-purgate-size: 2457 On Wed, Oct 14, 2026 at 07:36:41AM +0200, Greg Kroah-Hartman wrote: > On Tue, Oct 13, 2026 at 03:39:35PM -0700, Ian Rogers wrote: > > Clang supports the 'require_explicit_initialization' attribute on struct > > fields to enforce that the field is explicitly initialized when an > > aggregate object is constructed, emitting -Wuninitialized-explicit-init > > (enabled by default) if the field is omitted. > > > > Following discussion at the Linux Plumbers Conference [1], this series > > introduces __require_explicit_initialization in > > include/linux/compiler_attributes.h and applies it to > > struct kobj_type::release. > > Cool, sorry I missed that talk. Yeah, I'm really liking these compile-time checks. :) > > > As Documentation/core-api/kobject.rst notes: > > "One important point cannot be overstated: every kobject must have a > > release() method, and the kobject must persist (in a consistent state) > > until that method is called. If these constraints are not met, the code > > is flawed." > > > > Annotating struct kobj_type::release caught 30 struct kobj_type > > definitions across the tree that omitted .release: > > - Patches 2-10 fix 10 struct kobj_type definitions where dynamically > > allocated kobjects, ksets, or enclosing structures were either leaked on > > kobject_put() or freed prematurely before kobject release (risking a > > use-after-free when CONFIG_DEBUG_KOBJECT_RELEASE=y). > > - Patch 11 annotates struct kobj_type::release with > > __require_explicit_initialization and explicitly sets .release = NULL > > (with explanatory comments) on the remaining legacy struct kobj_type > > definitions whose kobjects are static, per-CPU, or embedded in devm- or > > parent-managed structures. > > Sounds great, but let's fix up the users before adding the attribute. > Looks like some of these need another version so it might take a bit of > time to get them all merged. I'd really like to have the attribute available, and I've got at least one user I can apply today that don't require fix-ups (seq_file), so if Miguel is okay with it, I'd like to snag patch 1 and send it with my seq_file "first user" for this coming merge window so it's available starting with v7.4-rc1, and we don't end up needing to wait 10 weeks for other subsystems to be able to use it. And the kobj fixups can continue in parallel. Does that sounds okay? -- Kees Cook From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:37:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:37:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449320.1665175 (Exim 4.92) (envelope-from ) id 1xH1z9-0006KX-Og; Wed, 14 Oct 2026 16:37:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449320.1665175; Wed, 14 Oct 2026 16: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 1xH1z9-0006KQ-LI; Wed, 14 Oct 2026 16:37:47 +0000 Received: by outflank-mailman (input) for mailman id 1449320; Wed, 14 Oct 2026 16:37:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH1z9-0006KK-AJ for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:37:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH1z8-00CqyG-NR for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:37:46 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfafd8-2eae-0a2a0a5409dd-0a2a4506ae08-4 for ; Wed, 14 Oct 2026 18:37:46 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acfafd9-195a-0a2a45060019-aceafc1fe1f4-3 for ; Wed, 14 Oct 2026 18:37:46 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id C9B3E4094A; Wed, 14 Oct 2026 16:37:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3E201F000C4; Wed, 14 Oct 2026 16:37: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="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=1791995864; bh=ovAqcUcR1GnKTtcInlqEnrexmz1gsb8w6q2FfK1T5r4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GwrpOxogXrqhTXQ0pfmjgGMR/nhqs689d6d2T2UbxyqwEi+VJ/4ET2F3bxSsa/yCN EaglIPzBQ4qutHm/Eihe0pPBAWe+NlyY72FoJLC4Rcx8zYnrd+VBcodEifrd7JTzwT 8EqOjY6NHHc/4uGTfqT13dIP1aP05fs1tpq0wWe/LFtLEAv3fcER387/hVuHvXtsuD UxSDlOug9/2BlYA6zAYEAL+qTg5TM5momYM01f0IFfrqT1XCvpcIhwvzWCD/yfd3Rd ixvRP2r8X3I5Gfn87O/r4tNbn1q5lLdLD9Jj9tp7JpRRBzFzF6fUQnw/3GazF0kGmz Z7FdXtLFV/36A== Date: Wed, 14 Oct 2026 09:37:44 -0700 From: Kees Cook To: Miguel Ojeda Cc: Ian Rogers , Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 01/11] Compiler Attributes: Add __require_explicit_initialization macro Message-ID: <202610140937.B68C8C9AAC@keescook> References: <20261013223946.1836757-1-irogers@google.com> <20261013223946.1836757-2-irogers@google.com> 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-16d1c6/1791995866-F627077B-38CF966C/0/0 X-purgate-type: clean X-purgate-size: 1068 On Wed, Oct 14, 2026 at 01:28:55PM +0200, Miguel Ojeda wrote: > On Wed, Oct 14, 2026 at 12:40 AM Ian Rogers wrote: > > > > +/* > > + * Optional: not supported by gcc > > + * > > + * clang: https://clang.llvm.org/docs/AttributeReference.html#require-explicit-initialization > > + */ > > +#if __has_attribute(__require_explicit_initialization__) > > +# define __require_explicit_initialization __attribute__((__require_explicit_initialization__)) > > +#else > > +# define __require_explicit_initialization > > +#endif > > The LPC slides mention Clang 14+, but from a quick test in Compiler > Explorer and a `git log --grep` on the LLVM repository to confirm, it > seems the attribute was introduced in Clang 20+, no? > > If that is correct, then it is not available in all LLVM versions we > support (LLVM 17+), so we should add: > > * Optional: only supported since clang >= 20.0 > > With that: > > Acked-by: Miguel Ojeda Yup, I can confirm, I only see it with 20+ too. -- Kees Cook From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:40:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:40:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449331.1665184 (Exim 4.92) (envelope-from ) id 1xH221-00081g-52; Wed, 14 Oct 2026 16:40:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449331.1665184; Wed, 14 Oct 2026 16:40: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 1xH221-00081Z-2P; Wed, 14 Oct 2026 16:40:45 +0000 Received: by outflank-mailman (input) for mailman id 1449331; Wed, 14 Oct 2026 16:40:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH220-00081T-6B for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:40:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH21z-00E2AW-JF for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:40:43 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfb08b-8faa-0a2a0a5109dd-0a2a4509b402-0 for ; Wed, 14 Oct 2026 18:40:43 +0200 Received: from [209.85.128.175] (helo=mail-yw1-f175.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acfb08a-be1a-0a2a45090019-d15580afd448-3 for ; Wed, 14 Oct 2026 18:40:43 +0200 Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-8565d77c277so32536647b3.0 for ; Wed, 14 Oct 2026 09:40: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=linaro.org header.i="@linaro.org" 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=1791996042; cv=none; d=google.com; s=arc-20260327; b=brApiVNi2GM/ej6m9e5vu1Y4fgwUIJzBuNSK33HC0SBmHTwIAtycJENnxGycuHMGxo UwFLD/YU8PZU1jijQr+n0RCWPCxHKc05Z9SZtcGvoNFbZ7bxWrI1MrtMOlJwODp3wfD5 koGY8KDa3THVnibNIVvL+MglWF6HNzu2D1fZlFA3ZlMS+ujGmN0U5cpTZK75Fj1gUy22 SwmBokjP7i4+XCvfoFGJFOPkxYMPt/Fg8PFsATJpowL5IzUXhXXlZD9i/TO232Zm+AeD N8FMK63TgN/a9223skuuv4FcP4/S/ugzFGsdJtyg8UqPkr3zCUcaj/MXqTgmIMqXWzjk D4bQ== 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=HsE4A9PIDoSy53wyR5EU6kLVeX4AGREiYkgrJG6uiU8=; fh=UIbfyH6QNm5she87CVPUpSvCylEkXLj7ha4U0bSspuQ=; b=rIUQl6l86NSvzP37UYg1kd1VdmgNXfUhvGhw3FXQ9vu8slWx5aJxTK+Nr7PL8FlhNI 6FXkTssVvUeFqCAXRuGMtoeeTOWSgF/4+92a9RWeSYt1n9s/1C/7dSvM0hEGCF2G1G0K jEuIIIg/6uWR42LgJ9wlfYvgeqKciPmU1yK7F7pIm8VpGwzutbK7VjYLzKgtfzYJ8z45 LJU/iNLahaGapEWPQF6PTzTZANY47k2CKy8SPmbvdz82UkzjcPXpb/TrleaS3T6uQaWq HrIr0apDyxauPJLimvFTr+uEjORL6yH8ObnnDI9KQVTcbvE6vcc4C8l6y5ZbWmV/IZfC gfxw==; 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=1791996042; x=1792600842; 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=HsE4A9PIDoSy53wyR5EU6kLVeX4AGREiYkgrJG6uiU8=; b=Gbu5BuEWWjmNpHi1MX3bZztvrgzIE8qJ6G8KeuTOWDTODtUSmwld4u9EztkYvKHlFv 9gXn1k3VGoiMbOEp+x0drWAwcQiQEVRxXnkSG0MOlx6zLRDl6GFqXpatqJZIw/SgfwhP Tdgyo4nsynEqpNNrv90txbsO5OhUbKvG/31TbqdSyXp6EsmNwgOx9v+aoEnY1jWQVFuZ d0n6Mpw6lLJ+eEGTrKZHXObLV+kt+ewc898iLqdoBRxt5vFIBgHVAerrP8LCfznHg/3+ mNrAKZAJsGN6UaFRBfbVoWIL8qPdV8i+aTdR4TN/+jwRoBzt5d8y/6i/RBFbUGO+1mPp ThPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791996042; x=1792600842; 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=HsE4A9PIDoSy53wyR5EU6kLVeX4AGREiYkgrJG6uiU8=; b=Yh2FZgq7uJ4N3Pn7nLdVS5iH7U5VDjRmkPo3gkoa8PE3LLxUISLlOE8lphZutLHQYT 3p0rPhRV5NoTMCSHuqVRv6meMFrwei6HmN3OO4wm9NROapcHyYnTBE3c3Enza/800cK+ ENJryFDkSO+sLYwEs4QeBEWpCORbqHX5veYBWrBs3rh8iMnQXVEM1qdbkBlRQDRiGum2 dz3iZZ50/cZ/BpMMJJv7TNT7QW6bf02qQ5Z0rE+vb1UEirmTWbxLTARjttVhLIFfIEyX XYt0NWP7E6KN2aSOXP+7Bv0V2rOOBzXSgxFyx+MZQ64h/piiZdAd2Xr0Glpv4vrFIuNK JHSg== X-Forwarded-Encrypted: i=1; AKwUvBzlD4Xkpn+7xQ7dOiGJm+BF/siHGLkH7UcZUkZ1+WEvjJw48C7KNwP+QGrYJcS/JZk7tErOl6bJL6s=@lists.xenproject.org X-Gm-Message-State: AFq9FYKMRqx2bRa247BwLiaHbdOm939fyJMwa6om9XdlcC9XC23mUNrD NPrVjqHcq2nQ6IyssYbVwvfg9JTmXL3x3Y4wukfcENVt3vBLGKa1qKY69amlAv2Xv8WHvsbXxX5 DGCxRKxApVqqOqIHixNQa66WQ50BvtLebMKjk9UVmog== X-Gm-Gg: AYBFou18N14DCXbjmlN57B8e8sonbqlSu8w4/I/ZO168g9loZ5M7sAJ4Io+obO6ylFX x2UWPRzjYuWAtNQNuTxi+LW0HRZW5liZe4Aza8h9nqDcykvK9F3rcy5JkhzC2QWV0vdecmpfKeS Fe4S0G6mx7wMZcaYR9fokqFRtkG8c+iR6WlCU/M2VuOdPKWe0n/8QwqEfejE2/X9kR77YpEXUj/ y+MthQQDiqAeU2EvginOJUqMfBEg8TEifmSV2LZvQz4wiaS0i3kHPBo1px735hlrt5sNeXPBCnm 2kGOVLdfXrfLDFdMiRPv+ZNPOOYynZ0iM7CNFb5nFSWEDZv2y9bIqj3sWdST/MPyPytcqy1aYwL m8LN4SHAuuQg8lD2yh0rmZlt0JnukK/oob4UfKmLxRML4aLkFrg== X-Received: by 2002:a05:690c:ed6:b0:8b0:ac08:d706 with SMTP id 00721157ae682-8b0ac08e3aemr29323927b3.12.1791996041754; Wed, 14 Oct 2026 09:40:41 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-6-mark.caveayland@nutanix.com> <876b66cd-0ea6-4943-9a0e-c0abf2ad6e26@nutanix.com> In-Reply-To: From: Peter Maydell Date: Wed, 14 Oct 2026 17:40:30 +0100 X-Gm-Features: AclHuK9GKZpuJodSpbaJGGjpNEJHf1hmwnQWIYQLstVzf56ZJooPw1UCua58JCI Message-ID: Subject: Re: [PATCH 05/22] i8259.c: move parent_realize from PICClass to I8259CommonClass To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-bad1c0/1791996043-BE0C5034-DF18534F/0/0 X-purgate-type: clean X-purgate-size: 2794 On Wed, 14 Oct 2026 at 14:58, Mark Cave-Ayland wrote: > > On 14/10/2026 12:00, Mark Cave-Ayland wrote: > > > On 13/10/2026 16:54, Peter Maydell wrote: > > > >> On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland > >> wrote: > >>> > >>> 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 > >> > >> This is one of those things where I think we're not 100% consistent > >> about whether we think the parent_realize field should go in the > >> child class struct or the parent class struct. The name "parent_realize" > >> implies it ought to be in the child struct, though, and I think we > >> do that more often than we put it in the parent class. This also > >> makes some kind of separation-of-concerns sense too: it's the child > >> that knows (a) that it exists at all and that (b) it wants to have a > >> realize method that will mean it needs to chain back to the parent. > >> > >> The docs for device_class_set_parent_realize() claim the parent > >> realize ptr is stored "usually in the instance structure" which > >> I think is just completely wrong. > >> > >> I could be persuaded otherwise. As usual with QOM/qdev, I'm > >> mostly interested in (a) consistency and (b) documenting what the > >> "right thing" is. Realize, reset and unrealize are the three > >> methods where QOM's lack of convenient support for "child > >> implementation of method will need to chain to parent impl" > >> is most awkward. > > Yeah it's a tricky one. This patch was really just refactoring what was > > already there, but I'm open to moving it into the instance if you think > > that is better. I agree with your point about the child instance being > > the one that knows it needs to chain back to the parent. > > > > I'll have an experiment and if it looks good, I'll move it to the > > instance in v2. > I did a search over the codebase and checked all references to > DeviceRealize, and they are all stored in QOM classes and make use of > device_class_set_parent_realize(). So for now I think we can say it is > the documentation for device_class_set_parent_realize() that is wrong, > and I will leave it this way in v2 of the series. Yes, the *instance* part is definitely wrong. But there's still "parent class struct" vs "child class struct". This patch puts it in the parent class struct, and as I say above I kind of prefer child class struct and think we do that the most often. -- PMM From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:41:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:41:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449338.1665193 (Exim 4.92) (envelope-from ) id 1xH22v-0008Vi-CI; Wed, 14 Oct 2026 16:41:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449338.1665193; Wed, 14 Oct 2026 16: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 1xH22v-0008Vb-9k; Wed, 14 Oct 2026 16:41:41 +0000 Received: by outflank-mailman (input) for mailman id 1449338; Wed, 14 Oct 2026 16:41:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH22u-0008VK-G7 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:41:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH22t-004Xrw-Sv for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:41:39 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfb097-8faa-0a2a0a5109dd-0a2a450ab470-30 for ; Wed, 14 Oct 2026 18:41:39 +0200 Received: from [209.85.160.172] (helo=mail-qt1-f172.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acfb0c2-f2d2-0a2a450a0019-d155a0ac9040-3 for ; Wed, 14 Oct 2026 18:41:39 +0200 Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-533202fe429so1288901cf.0 for ; Wed, 14 Oct 2026 09:41: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=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=1791996098; cv=none; d=google.com; s=arc-20260327; b=OAOAO1AGIoELK0SFEyO41SduL8KlZ87ioDH/zCSiCSGYWkzGDt94RIKaoXP3o7YGHm XfHsnTTKOE8ox5r5A9Gk0s2NkYDnsWlp6LiJ2kqKG5QN0S8SSJUgDMntjs3HbTOohwBr /dqSAbQDqV1fuVDpC68U7II6Ht+LiGcmINF0KOIbGTgx5zeW3rmYYKaI1qoOjoIHHeg0 UPQ6i5G0vo0H3XH1zqKPyP/PmV+0kJs1z1Mlk4y3S3Ge0KHBYWYyNt5UaYkcGlhy6OBh 02UDbp1sXNKNJ6bCV7uRAjHaKiDMiyYyC/CtnK2VZBiePfTU8Ig3h58DrraL4fl9b06r 6ekg== 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=NIItl0pCQ/aBq2U1h8kgQBz3yZb99mdO46VMaoMNnUw=; fh=7Sl6RuB46XcB3hLo2hiDeMAC2zJfk/KndZQSgKU/DKk=; b=p08iKYvinnGnAkabL0PtJsV2R+EUuJAS7GQthfqNF80hM+X3Yw5IUS5FZX+d0Bvscr ZDlojeDy7KmD2oz2wIP7s9jCL8nezyiyeQbnmNsdgdhjCkdvpfW0fRBwWZrXE//40zXO S6pJZ9bBqTnyTlFknZynDB1tHfcP90UjNRrvlDlhXXzN3Ixl3/6ciYhP3S56hpupPksZ YOatmHx/ztl95lxI/Z/KBSvrJDv+VuzVaoM4/gwW1bUCK0KBXesjqXTa8FQd0T+jZ2Ug nP1R2N7+/eoNnS7Xq6kCcQ4vOhniHH1KbtpAxJEcxVldEWtcI8nnY7MfyUMm86JeJCWM TFCQ==; 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=1791996098; x=1792600898; 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=NIItl0pCQ/aBq2U1h8kgQBz3yZb99mdO46VMaoMNnUw=; b=mV5voZC6j/JUq6UFKEpBbYepSECknASdjXq5LiTti9+UJsz+TJjQq/qZy0/TX6dl0g xAF07Xp9NWxQIhC1sZl56T+PaFosUP9yE5vzUgJpauYzUg0xdOC1xGhfbjH073/BrR2U zWE5E54x5SHBnRTLJDui/2ocQ52z/HvvWQh53+ABzcqg+GwF6QdgKkx4dNjxMCd6B1Au xNLsiCstGZWqLJ5GONw/aa7SFr7jBYUvZtLEs2xdtjynJtTWLg8QKMDfCRGGOzyNYD/z fwGkXXTVm/No7+kvZlBVfhcXJjAm6U3nI1/3xW8o9OodmokUvN+BxCGFR4txlGPU4xTY BtOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791996098; x=1792600898; 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=NIItl0pCQ/aBq2U1h8kgQBz3yZb99mdO46VMaoMNnUw=; b=tTqETMpM0bWBtFvljkzG3uqq0rm/ibTTl04AaaSvsnTP9JYlkjphbC97sF+aKJRVi1 ktJ2NtkiwbOBXeTmCfNbRPpJSTGnfflyy6Qd0rsJCrspQkv8ln74u3dBOlFGbINUGCb3 Iao52SEoi4g/wZyMOAp06IzNO6uGoGY7QKes4gwASXHOnmCEHOLfn0Tk960dBjiIG/MT j0btanczvhZqJPmoSuNnOPwA5q0UET9k9ChSbU3+mj277wH+51h+uq3RS8dJEinsnroo ZvElOo+Pd2wWZi+WpOmLmpxf6Yzd2qSfiI7ii/Y4WltagkCH4JrOqyQ8NcBb/hFdoCPV +9Hw== X-Forwarded-Encrypted: i=1; AKwUvByb7kDELpJPA3ZceIN3Xp3wv6NlKBGq+XQb3TkmvCYQS49BX2KgmIYjYrfBXpgRev4M4wRtlo3WJ+k=@lists.xenproject.org X-Gm-Message-State: AFq9FYItkeTQqxid8BE0NpUaX584P9OQxkXiqu1ydN0Fxi55ffRxtNGg FHVIfbFob639ql7V28PrOoEvZzk1oqgJotxW02Dsy0cT1xqlxQgh9c/Y+w39fgkIBwD7GRke1Qz Au0S1SI0sQh1qJ8cbtZdP5/bdUHgrlogeYkmQT6ai X-Gm-Gg: AYBFou3ahl+GutT/4YF+45w+TDLx4kRrV74CPF4j5zUS7ycTCap7pxhtOVUqinFUgnj jilVrMcg5hWz6b4Aas9PeqZRU1URDOqGMkn0PoCx5Gy4pvyrCRo2OIntDaD4N0b6DySpgMoBmPe bT1J/QXaVIy4ZDRDH6esN9nCkoBf5Q5pC4HQL6CJ1c4DEG7CiUGW32/ztn9D9D7fULRsHzp9OUC crYkwWBCMR5j2ZyDoC9ONn/0/TYpTKNZaxlqN1SY7U9ZCBLL8da0pkMBQiYe2kr76Sllc6vj0uG QWkYkWQeTM6ZkA1MME+FW7ZyUSA8HuQBCom85qpaHBArLVxD2J9u7dvLkS9xgcgCWLxoN0ZkIWi NVSQ+aSfTAA== X-Received: by 2002:a05:622a:1108:b0:533:9746:9a86 with SMTP id d75a77b69052e-5360573c96fmr14813151cf.5.1791996097367; Wed, 14 Oct 2026 09:41:37 -0700 (PDT) MIME-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> <2026101425-why-boring-4f2d@gregkh> <202610140932.5F9CFCE5@keescook> In-Reply-To: <202610140932.5F9CFCE5@keescook> From: Ian Rogers Date: Wed, 14 Oct 2026 09:41:25 -0700 X-Gm-Features: AclHuK8_g-YOJgMR77fEpf5RTsveF4u_ERdXz6lvoN6wh_uF7KP8ZsaUSV1ti8A Message-ID: Subject: Re: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release To: Kees Cook Cc: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1791996099-595C3CFC-38BD9B84/0/0 X-purgate-type: clean X-purgate-size: 2983 On Wed, Oct 14, 2026 at 9:37=E2=80=AFAM Kees Cook wrote: > > On Wed, Oct 14, 2026 at 07:36:41AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Oct 13, 2026 at 03:39:35PM -0700, Ian Rogers wrote: > > > Clang supports the 'require_explicit_initialization' attribute on str= uct > > > fields to enforce that the field is explicitly initialized when an > > > aggregate object is constructed, emitting -Wuninitialized-explicit-in= it > > > (enabled by default) if the field is omitted. > > > > > > Following discussion at the Linux Plumbers Conference [1], this serie= s > > > introduces __require_explicit_initialization in > > > include/linux/compiler_attributes.h and applies it to > > > struct kobj_type::release. > > > > Cool, sorry I missed that talk. > > Yeah, I'm really liking these compile-time checks. :) > > > > > > As Documentation/core-api/kobject.rst notes: > > > "One important point cannot be overstated: every kobject must have = a > > > release() method, and the kobject must persist (in a consistent sta= te) > > > until that method is called. If these constraints are not met, the = code > > > is flawed." > > > > > > Annotating struct kobj_type::release caught 30 struct kobj_type > > > definitions across the tree that omitted .release: > > > - Patches 2-10 fix 10 struct kobj_type definitions where dynamically > > > allocated kobjects, ksets, or enclosing structures were either leak= ed on > > > kobject_put() or freed prematurely before kobject release (risking = a > > > use-after-free when CONFIG_DEBUG_KOBJECT_RELEASE=3Dy). > > > - Patch 11 annotates struct kobj_type::release with > > > __require_explicit_initialization and explicitly sets .release =3D = NULL > > > (with explanatory comments) on the remaining legacy struct kobj_typ= e > > > definitions whose kobjects are static, per-CPU, or embedded in devm= - or > > > parent-managed structures. > > > > Sounds great, but let's fix up the users before adding the attribute. > > Looks like some of these need another version so it might take a bit of > > time to get them all merged. > > I'd really like to have the attribute available, and I've got at least > one user I can apply today that don't require fix-ups (seq_file), so > if Miguel is okay with it, I'd like to snag patch 1 and send it with > my seq_file "first user" for this coming merge window so it's available > starting with v7.4-rc1, and we don't end up needing to wait 10 weeks for > other subsystems to be able to use it. And the kobj fixups can continue > in parallel. Does that sounds okay? I'm happy with that. I'm working to address/incorporate the other feedback for a v2 of this series, but I can drop individual patches that have already been merged. Thanks, everyone, for the positive reception in getting this landed, I plan to follow up with patch series for the other uses I found. Thanks! Ian > -- > Kees Cook From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:44:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:44:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449344.1665202 (Exim 4.92) (envelope-from ) id 1xH25j-0000gL-Ta; Wed, 14 Oct 2026 16:44:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449344.1665202; Wed, 14 Oct 2026 16:44: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 1xH25j-0000gE-QN; Wed, 14 Oct 2026 16:44:35 +0000 Received: by outflank-mailman (input) for mailman id 1449344; Wed, 14 Oct 2026 16:44:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH25i-0000g7-IH for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:44:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH25h-00E2c3-VQ for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:44:33 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfb167-bab6-0a2a0a5309dd-0a2a4501d5f4-14 for ; Wed, 14 Oct 2026 18:44:33 +0200 Received: from [74.125.82.169] (helo=mail-dy1-f169.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acfb170-5984-0a2a45010019-4a7d52a997cd-3 for ; Wed, 14 Oct 2026 18:44:33 +0200 Received: by mail-dy1-f169.google.com with SMTP id 5a478bee46e88-34c522572bfso548247eec.3 for ; Wed, 14 Oct 2026 09:44: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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1791996272; cv=none; d=google.com; s=arc-20260327; b=sgx76TeYqAHTHFJkiRXm0g8j+34/2xN2OjCIz48pLuBytqcOCfBYAVoVA3iHUerTFU XMVLm33aj/JGic/N6EkREEPVz1kgZgvHlt/AmVCfPag+0OdVClISaJFieCGile+s4hZV LSWrmCwJvHjazZvU6KAO8NvAwr+2ygdL2lhNp7tMqo0oqYx4koAXa3Rirutmpr3SAEh+ H6oy+ezJTACX+SH1O2/ggiBcd84bNKLkE6TTWoa/ZD9d464rjI/XFj0MwzYQXextsBGm w14bhyQlCkJv/lTyClsHT//GeImSqDiRuIl/IP4Q8YgoszzDn2fnKma4Uudabi6eIWfA 7f3Q== 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=lG5fR4/c9rTkKwB+dH11HXxHn5DhiwcqDirk4k17QlI=; fh=AiCmKLTLbfiF+IgaOklRbXWvoIXr7KSCud2f0JCapIA=; b=AVuDwIxAd++szmyLPr4Yb0YOPqhz8Xi8uu2NUMwfqcH1XawCdyzh4HYs0w+r6V0MO2 P49MTExAelz2LSU/W2w7Cfdb8XQPxt9blIcYsk21+skGScTzTMQSmVdquSEOE/L5PYZI CH4pIPTcSAJVkxH50VqcJwMBXthl/R52iNQ55fICI8oZvENpW/z9qTB/LPmUNWuPU8D4 on6uLrDth1Q5kEQQXK5tFIszj4LxndcUMqKiSyS+ev+BZidr5SbH14APUIGDaF0SQSD2 YdeJIVdX3Rk0RAc938o8ZHMbe/OrJX4/ffbjbrlUj9HneXX9lr818Eaiu0VV3rqU8X9n VEKw==; 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=1791996272; x=1792601072; 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=lG5fR4/c9rTkKwB+dH11HXxHn5DhiwcqDirk4k17QlI=; b=H78jwmoP6MgHCjRqkq+iNodXTO5UBTYgMkiRCDKD1Cjg0PBwvxLNsYRnFo2JuOjEtF W/br1G+7x4JwZfW8eTd6oU17MUA6cP5k3DfXt1hVhgMCI6TE6/kvKyEuPlDiW7xzVho3 IYHWTLIgkY1cfNrpUv0NEtgZwHiPm/P4gEyuqAMob6Ptglrl1KjZHn+s5dQLZp2H7bHi uW1lZbrI8bqi469+sWgHFAFMEAsvJpauomHzp5hg8dBHrrZxTB/75Eh71zliRgYAMo4f /oWrVgXqN3PCuOxzJOerX5HrpBY75eOdtwjes3JE2XAUzlU+OMOUlOGbkNk3EFrXRhNg JxwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791996272; x=1792601072; 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=lG5fR4/c9rTkKwB+dH11HXxHn5DhiwcqDirk4k17QlI=; b=GflNEkJ8/mL7PX8b9QNcKGv6NgnNM6bFDIjcLOz/IruaRPORfUSGk2j9lCLxKMMcLc 0BKgfb+Jm7+rH6BHiM44IRv3rzKJok3SA8zHF3Hf3M9RR5mZDpNwLTJ+00VAyGBSyRsZ 1Iuq/DoGJFGZej2LPXekOh0dgO96d3OC8NzUn+KD+UPPIab6y8SfTuPp0UMY6AN5I0Wx PAwgXaMZnQl8cNbSIuIeO4X1iW43e0J5owtEHGKrGqnVQ6eYiVXZpbHoC12G1R6mT9VG Mo2R08khsF3E8iy7iBCz8pI4pcYcqFwVZ5FZAJ/XIEXYMejcz98o5tw7aiKxqJYe+pOR 0Fdg== X-Forwarded-Encrypted: i=1; AKwUvBx0Biqf63+pgO4GVwhc3uwX5dFXb6TPnB2rhSlIXLnYL+c/vNiOTzR2yIOHaEYon0kukfP8suSZzL0=@lists.xenproject.org X-Gm-Message-State: AFq9FYJklLGfbH6MNgjIlcIIc6gmdw0/Pf6QF6fwNIyHR+CfjBESJU/h HIDg/iS5kVmGXGtICpRo5pmUWtmGKM0Q6HLhtBr8qBFg36ew0C0/NCVE/2QYyXJnr0Iu6NU/GJh fPh/AFRhJ9u6tT84tq5D3sXV/+xzhN7s= X-Gm-Gg: AYBFou1DFYWYwFdHcGDagA6pIqlkaWTiP5o/6tYLftcFMyyNwmhsle7uhl8dnf93FYV FjaKjGzL6O9qwpVHUjAPldc+0SWUDPiyPXOYUFXCnoEb7zXYwBc7klD+6gQzjMEX5BLqE08oYPR Lnua/VI3J4OtjeOcZTFkzbxlLJKyNad6KLTrUWQJVQDUvcRz63bjKuyda0S9jcV/dKC9+GhEdR/ hsLQHlBEbjiCMS0vHu6nGbzkuJnCHbvFK7apC1LcEc3k35PKdFQSVEOeSb7i93FJMsmRjcqGBJR UIBqWbV4+0tT3W8WAlQTZJqunaB4CIRIhx1HhO4Q0T7+PldJu926dCrq3dlbaRiymQqltccpfJn dwrgjNHgsza9v9ssdSGXWnlZ53hPX1tJECVW4dmfkGrGTfc0F3AZzbhRPf15xxKu5Jg3E4a6hYW Ebgs/Z4pR2BYz2FIrjy+8nk57iuoMFpVVz53rSUePzUghX6k7h7zo= X-Received: by 2002:a05:7301:5413:b0:358:c9f3:b055 with SMTP id 5a478bee46e88-358c9f3b260mr28158500eec.1.1791996271702; Wed, 14 Oct 2026 09:44:31 -0700 (PDT) MIME-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> <2026101425-why-boring-4f2d@gregkh> <202610140932.5F9CFCE5@keescook> In-Reply-To: <202610140932.5F9CFCE5@keescook> From: Miguel Ojeda Date: Wed, 14 Oct 2026 18:44:18 +0200 X-Gm-Features: AclHuK_d31yoge0njHjovdIQh7JfJY6W-PLjzMLBq14NjY-schAqigzEJUAQwG8 Message-ID: Subject: Re: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release To: Kees Cook , Greg Kroah-Hartman Cc: Ian Rogers , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1791996273-BFE68757-8EC13C06/0/0 X-purgate-type: clean X-purgate-size: 1132 On Wed, Oct 14, 2026 at 6:37=E2=80=AFPM Kees Cook wrote: > > I'd really like to have the attribute available, and I've got at least > one user I can apply today that don't require fix-ups (seq_file), so > if Miguel is okay with it, I'd like to snag patch 1 and send it with > my seq_file "first user" for this coming merge window so it's available > starting with v7.4-rc1, and we don't end up needing to wait 10 weeks for > other subsystems to be able to use it. And the kobj fixups can continue > in parallel. Does that sounds okay? Of course, please feel free to pick it up (with the small tweak I requested) if you have a user. And if you don't pick the user, I could still pick the first patch up through the compiler attributes tree if you and other folks want to use it after -rc1. Greg: adding the attribute itself should be safe and would unblock others that may want to "protect" themselves, without having to wait for every potential user to get fixed (but of course I agree they should get fixed -- we should not forget about them, if that is your concern). Cheers, Miguel From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:44:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449346.1665211 (Exim 4.92) (envelope-from ) id 1xH25t-0000wz-4i; Wed, 14 Oct 2026 16:44:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449346.1665211; Wed, 14 Oct 2026 16:44: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 1xH25t-0000ws-1E; Wed, 14 Oct 2026 16:44:45 +0000 Received: by outflank-mailman (input) for mailman id 1449346; Wed, 14 Oct 2026 16:44:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH25r-0000wF-RM for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:44:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH25r-00E2c3-86 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:44:43 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfb167-bab6-0a2a0a5309dd-0a2a4501d5f4-28 for ; Wed, 14 Oct 2026 18:44:43 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acfb17a-5984-0a2a45010019-d1558034d1c3-3 for ; Wed, 14 Oct 2026 18:44:43 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a19cba5c14so38176935e9.3 for ; Wed, 14 Oct 2026 09:44: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=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=1791996282; cv=none; d=google.com; s=arc-20260327; b=HEChk0KhBioVZRM/QcIEUHrR68ZEm7sraBhfpPWy9JUb29QzlKkYsAQwhIKZPgbjWG wACxGdSM1CICXLl/a9eqaDfhyeJrRb79Vh0FvL3mpf46ojY5/SQmXSMBfRkELZRK4iYt sd4xFv6RYLtjDpvjE49KnHfcL0ncs0tZmn6ZRI4kiTGieXeI6l9dGB7HoqWEnhlHaqPq l6BW6zJFw/K+IHN237hf+dDEZtw9aKGU5roJXoNCIUCpgDJFMhoBd2PWfHJw7JB6NZma DZF2/4JIQph6nP1DCmrZL5kGGxbdqpuxZJ6PYurRlQP1WojuNMouhZun5pQ33vQYfPQs q8rA== 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=hsPwLhsDZInozncTdS3m6Cc033xIb80Yu7bEmy4I9fE=; fh=L6H7EPb7hTW+cJ3+u2BMq1G6CAt6RhdOe/toZLWtnj4=; b=kux7tFmBSru57IR1eHYRELrFRTQX3Zpx2IFE5f8KRFN0caN+izdFgaOGexAJVi1Bky EN4RJvdS2qVA1GVF7NSET64XvTS86rdTRabByGH6Kl+WhIsx0juWU6V4qj4gRpGydfyz BhrEOouJftAWU1t7Cj9Eue2AGlMoPj8wjnenNn/SvvbtyRrGmMegH9XDsYttAEL2n0Am RmAWUrHGV1/8NzkCUOIkmwd1dTApWZIGxWrhggDOaL6hIfeju0GJKJityluD/QSZk0NL Kmri+SzeJW48vyOs1ImKULUH0O0s2Tm9Vm3KapgFVuA2LobRqKctFRtC0wMoqX8QPCkS gVmg==; 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=1791996282; x=1792601082; 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=hsPwLhsDZInozncTdS3m6Cc033xIb80Yu7bEmy4I9fE=; b=QZiQ5K8jQS8c949kRNpughGR9WWy4btWTYHZGNXc654GHpYaL8dHxAh4wIe0laM53f VMEnVJsRV6o86NzBY2sy20wn3BmrO9dg1glfQ3Vdw688ZCYUlhI/eEELznpt6ZL2kFn0 wHY+BYR6/cTM+625kBRC1SqZ+AIqRaUvJUeiovbpEXBKtZ8D1VIxMp1ZIlJv4e9bVCs3 JQGVANAhRE4oBuF7xLUtstqhCTtJv3+6cCD1C7PlGssQbsLvrPkt7iskv+YwzchT5CfM T8QRxxVw7T7VR9MUsNAibUP28CemzTjuzUNn7neN0R9TdIbPEOuaeFqJK4bISywJ3X7Y ND3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791996282; x=1792601082; 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=hsPwLhsDZInozncTdS3m6Cc033xIb80Yu7bEmy4I9fE=; b=CQTDmgyxTEGHqQgCACe1qC0k3tDUWeobw/vjGx8sEn2kvTNj5Gs2fzU+oP3KO3YC5R x0yHiqVsjSNFWj7mdTAv0hS6fE66Uo04KfzM/SiGp2z7CoITsG5XOEbITFEKZxg1zwSz lB3hhma/Y82jPq/sb1s2yEoN5oBrCptSOPXSz1NIzf1mVtYmDJyzDsdt6F9omRpRZwGR rGvB+41tkzxB7s797YAwV06yrS1BnpvlrDbDdeS6vIdgEAEdDvr8d3cfLXlELQ6AuImM Tr93Y2/7kOP/RL0al3JlIjwmh7DfqrErqxyebz7BG+CASgdsVMQarY5JwaDl8E0c8DFe dyuQ== X-Forwarded-Encrypted: i=1; AKwUvBxEiKWymhycGp1x7tnPaJ0kxsHzEKUp35Qe55XBLSn5Wg+ZqhaCIYm7JuETu8Rw8ItkgUElwLB2Iz0=@lists.xenproject.org X-Gm-Message-State: AFq9FYK3A9Ke5CSTPJa76ORoVHZX14qQJZXhO8DM96tmWzAHdF6Kbi6E 9o0iZQJrwSAE4j3boQ0LV9cu4NBMu3u6KqYeJPSqq1384ExKBfwjFsA7VFYFgTihGpG4dIcVYKg qilAwbFCspkIp3+1C/qJusNpC8aMxg/FXUFW5jCcm X-Gm-Gg: AYBFou2SvdscWqUXPLi5zJAr2dLxZbPY1L9krAMGz7XvJr4nBHyqLVcnNThykQwBasv C0bv/VHVjUdtubjbSG/f36hrlz1VNtlduxQitGeR2OTaP9BHMCSoupaatZpm+yXABYFpWPA1QL9 /o/FBJkodzdrhmc5PT+zQ0h3zWpm82rnSKe0nAamkWY9oEP+A6XsnYpnPk0QDC48FCJqdqR+WrK X43uumz1dNLC82ap5nu0qz7No6wQ8i8MZGKEO0jD/7VZz7DGS223QPfL1F6wkS/3a0R3J3CSSzI oiUfdJNgV5hQfJwVapRlBi10F+GDKWjWSau4x3tUlfZqzQ0FpbOQMMmev3H5Fb8MrAMyY7/EMMH xizI3v2zSzQMLsIs/+IRuG3smoDQ3Be2f4sbaDjO+XFmV9GazKC6BM4GabYhyyzLTIXHRw6pOGd Vf7KkHuDYRJ2E7J6vHNbEt8ePROJj0paW2zeWYHFw6kpb85iiQJNmb X-Received: by 2002:a05:600c:354a:b0:49c:d019:70c5 with SMTP id 5b1f17b1804b1-4a18e3ef23cmr329192565e9.0.1791996281614; Wed, 14 Oct 2026 09:44:41 -0700 (PDT) MIME-Version: 1.0 References: <20261013223946.1836757-1-irogers@google.com> <20261013223946.1836757-2-irogers@google.com> <202610140937.B68C8C9AAC@keescook> In-Reply-To: <202610140937.B68C8C9AAC@keescook> From: Nick Desaulniers Date: Wed, 14 Oct 2026 09:44:29 -0700 X-Gm-Features: AclHuK9LUe2FvddsKjj0vYiArabpm2vrSaqioSsrjl7koqqOn_VyYRh6l-6milM Message-ID: Subject: Re: [PATCH 01/11] Compiler Attributes: Add __require_explicit_initialization macro To: Kees Cook , Ian Rogers Cc: Miguel Ojeda , Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Nathan Chancellor , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1791996283-1E07B757-BF507E53/0/0 X-purgate-type: clean X-purgate-size: 1366 On Wed, Oct 14, 2026 at 9:37=E2=80=AFAM Kees Cook wrote: > > On Wed, Oct 14, 2026 at 01:28:55PM +0200, Miguel Ojeda wrote: > > On Wed, Oct 14, 2026 at 12:40=E2=80=AFAM Ian Rogers wrote: > > > > > > +/* > > > + * Optional: not supported by gcc > > > + * > > > + * clang: https://clang.llvm.org/docs/AttributeReference.html#requir= e-explicit-initialization > > > + */ > > > +#if __has_attribute(__require_explicit_initialization__) > > > +# define __require_explicit_initialization __attribute__((__require_= explicit_initialization__)) > > > +#else > > > +# define __require_explicit_initialization > > > +#endif > > > > The LPC slides mention Clang 14+, but from a quick test in Compiler > > Explorer and a `git log --grep` on the LLVM repository to confirm, it > > seems the attribute was introduced in Clang 20+, no? > > > > If that is correct, then it is not available in all LLVM versions we > > support (LLVM 17+), so we should add: > > > > * Optional: only supported since clang >=3D 20.0 > > > > With that: > > > > Acked-by: Miguel Ojeda > > Yup, I can confirm, I only see it with 20+ too. Fix up the comment and have a coin, witcher. Reviewed-by: Nick Desaulniers > > -- > Kees Cook --=20 Thanks, ~Nick Desaulniers From xen-devel-bounces@lists.xenproject.org Wed Oct 14 16:45:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 16:45:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449357.1665221 (Exim 4.92) (envelope-from ) id 1xH26R-0001ZX-EF; Wed, 14 Oct 2026 16:45:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449357.1665221; Wed, 14 Oct 2026 16:45: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 1xH26R-0001ZP-9d; Wed, 14 Oct 2026 16:45:19 +0000 Received: by outflank-mailman (input) for mailman id 1449357; Wed, 14 Oct 2026 16:45:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH26P-0001Z5-Gt for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 16:45:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH26O-006AMC-QO for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 18:45:16 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfb17c-8faa-0a2a0a5109dd-0a2a450897fa-40 for ; Wed, 14 Oct 2026 18:45:16 +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 6acfb19c-f659-0a2a45080019-b9ff1c22905d-3 for ; Wed, 14 Oct 2026 18:45: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 1a13b4dc2b50008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 14 Oct 2026 16:45: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 5761782A6A; Wed, 14 Oct 2026 18:45: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=eJ2IsZxNtYLq4D15UVisMaarAvx5i1eeBT44+IuIkLY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=mR4OnDzTWpGMkUwTOOOla+8PQADmEIKeRid7by/FY9wKP/7TTXLOI7YkISBTTwwrUof/1/JhD Ol92U75se7xV7DQ2OBwkgcWpz6OOcxXtAFrM1XbXqrxJX5JUijYUmE4KxfLiMcG4+vq2vu4lH4b jGf+VFncSqCFdEhH1YDuIRz1HtrlxjoB+wJjtXnJDtpOGC9tUBkZWR40BmapgiSepQFRy4RCJ4Z I3ZIKPRuBMGWDk8CzdUVBI//4e3OO5Om2JqmjmivaG5hiZk1hHXB+P5lz2ZS2AB0KZODy8wzVaT iVusL4VBVFxwVILZtvlS636LBHToanqGxx3uWwvLnPvg== X-Zone-Loop: fb5f1280fceee81298920fe136c0f589117817b8d174 x-campaign-type: default x-transaction-id: 6aa0b9e4-f386-490a-a017-c06356cef225 x-swg-uid: 01-0e827c5e-9033-456f-b1ea-1475779ac107 X-Mailer: Sweego Message-ID: <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> x-swg-bid: 1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425 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 v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org In-Reply-To: References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> Date: Wed, 14 Oct 2026 18:45:07 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791996308; l=1796; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=iCrnAvwrcPaAIA79U7FkKQjIY/ERt8PKItSdv5VSwQY=; b=uA8EA/lw96x5EC+Aju+TNdUE8Alxvq0OLuU2apHO2cWQopavBrhuYA5jrSxHqFtpuSjGCRjDG mtHlyxl48WkCBcwGLn4FukqR9dly7yPzXpOZrzH2LLj97TsiF9X0npd 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: 1791996313556 X-purgate-ID: tlsNG-c1860d/1791996316-CEF5F87B-8310C79A/0/0 X-purgate-type: clean X-purgate-size: 1796 On 2026-10-14 11:09:58+02:00, Jan Beulich wrote: > On 14.10.2026 11:00, Baptiste Le Duc wrote: > > In which case it would need to be > > if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || > !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > albeit I have to admit that permitting two contradicting extensions to > be exposed at the same time is irritating. > > > I see two ways to address this: > > > > 1) Keep checking Svade: > > > > if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > > > After resolve_ad_scheme(), the Svade bit is set in every case where > > software has to preset the A/D bits. The only imprecise case is both > > extensions advertised with hardware updating already enabled by > > firmware, where presetting A/D is unnecessary but harmless. > > > > 2) Record the probe result in a global, e.g. > > > > static bool __ro_after_init hw_ad_update; > > > > and use: > > > > if ( !hw_ad_update ) > > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > > > This is exact in all cases, at the cost of a new global that mostly > > duplicates what resolve_ad_scheme() already records in the ISA bitmap. > > > > I discussed with Oleksii and we are fine with either. What do you prefer? > > As to 1), see above. For 2), while maybe okay, I think we're better off Sorry, I don't fully follow the issue with 1). Compared to what you proposed, it only differs when neither Svade nor Svadu is recorded, which cannot happen as resolve_ad_scheme() runs before and always records one of the two. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 14 17:45:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 17:45:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449411.1665229 (Exim 4.92) (envelope-from ) id 1xH32H-00059w-Jc; Wed, 14 Oct 2026 17:45:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449411.1665229; Wed, 14 Oct 2026 17: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 1xH32H-00059p-GV; Wed, 14 Oct 2026 17:45:05 +0000 Received: by outflank-mailman (input) for mailman id 1449411; Wed, 14 Oct 2026 17:45:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH32F-00059j-Je for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 17:45:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH32D-00CzF5-Hy for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 19:45:02 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acfbf80-2eae-0a2a0a5409dd-0a2a4507c144-42 for ; Wed, 14 Oct 2026 19:44:59 +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 6acfbf99-b4ea-0a2a45070019-aceafc1fd094-3 for ; Wed, 14 Oct 2026 19:44:58 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7156940856; Wed, 14 Oct 2026 17:44:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 330F01F000C4; Wed, 14 Oct 2026 17:44: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=korg header.d=linuxfoundation.org header.i="@linuxfoundation.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1791999896; bh=sTxxFIiD6mgFs2UdEY1I8MyQnekZZiyPvhQw7RuhHrg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Y/JbqQJUIEWFLFscjenxW9GCe5wNUa4lKG/qtufKEMdVe8I7JjwbgDqX5hbrhnbnk g11pdaabApMfzBMkfpM3w5n1u6n4ty6P15W2DYuVy6e5rpnrYB4vdZc0i3KcsTyQQY TKLv1ClTGNe42312p3oiyQs34X3dYVxDiKaB2oxQ= Date: Wed, 14 Oct 2026 19:45:00 +0200 From: Greg Kroah-Hartman To: Miguel Ojeda Cc: Kees Cook , Ian Rogers , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release Message-ID: <2026101434-scam-padding-87a5@gregkh> References: <20261013223946.1836757-1-irogers@google.com> <2026101425-why-boring-4f2d@gregkh> <202610140932.5F9CFCE5@keescook> 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/1791999899-A54C3AE4-3C0571F8/0/0 X-purgate-type: clean X-purgate-size: 1328 On Wed, Oct 14, 2026 at 06:44:18PM +0200, Miguel Ojeda wrote: > On Wed, Oct 14, 2026 at 6:37 PM Kees Cook wrote: > > > > I'd really like to have the attribute available, and I've got at least > > one user I can apply today that don't require fix-ups (seq_file), so > > if Miguel is okay with it, I'd like to snag patch 1 and send it with > > my seq_file "first user" for this coming merge window so it's available > > starting with v7.4-rc1, and we don't end up needing to wait 10 weeks for > > other subsystems to be able to use it. And the kobj fixups can continue > > in parallel. Does that sounds okay? > > Of course, please feel free to pick it up (with the small tweak I > requested) if you have a user. > > And if you don't pick the user, I could still pick the first patch up > through the compiler attributes tree if you and other folks want to > use it after -rc1. > > Greg: adding the attribute itself should be safe and would unblock > others that may want to "protect" themselves, without having to wait > for every potential user to get fixed (but of course I agree they > should get fixed -- we should not forget about them, if that is your > concern). I agree, not a problem to add the attribute now as long as it doesn't break the build. thanks, greg k-h From xen-devel-bounces@lists.xenproject.org Wed Oct 14 19:28:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Oct 2026 19:28:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449475.1665238 (Exim 4.92) (envelope-from ) id 1xH4dq-00074n-Jw; Wed, 14 Oct 2026 19:27:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449475.1665238; Wed, 14 Oct 2026 19:27: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 1xH4dq-00074f-GU; Wed, 14 Oct 2026 19:27:58 +0000 Received: by outflank-mailman (input) for mailman id 1449475; Wed, 14 Oct 2026 19:27:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH4dp-00073U-MH for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 19:27:57 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xH4dp-00000005AgE-3NwE for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 19:27:57 +0000 Received: from mail-lj1-f178.google.com ([209.85.208.178]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xH4dp-0000000EUSq-0MJd for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 19:27:57 +0000 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-3a1eb6fa0f4so46560311fa.2 for ; Wed, 14 Oct 2026 12:27: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" 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=WnyLEFtt04rxggtuHKr5h2wVuxOKUAWXi2+hZ2wtVEc=; b=y1bp1cxLuSOWf7U7wDtaiWaxYl disFWdk5qUbWTJGSUgpcextShIDkQNWiIWyM88rI2Bs3y2NFzJBkyNKVzoYmZGulMMSdwstQGl7ZM kt1phnQv7tZ9Ijaf7qKySms99tTNbwcK16sRbza8O+ZDKr2fIs1Iz+KTG5XgugpYZ710=; X-Gm-Message-State: AFq9FYLWh9xoSXsW886qsbvdwFOFy0ONOBqeJSIh+GJMjygq63bQ4mkU jAQZkoyljZ1PU96HxJv8rq/PQhb976YGFbbmhcx9fGj1MPu4Ay+DpsRMMGzKLB84seT0jFFEEt4 s6WZpW+0Cmb2jqMGJ8opejMrubkZP67Q= X-Received: by 2002:a05:651c:1542:b0:3a6:3c86:df91 with SMTP id 38308e7fff4ca-3a9c538ca71mr49782711fa.23.1792006076121; Wed, 14 Oct 2026 12:27:56 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-17-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Wed, 14 Oct 2026 20:27:43 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8RfH5rg15TXSTm5rPlg_lDnXFTS2LZZuCfoDDOludB99THojswA9Mv0wg Message-ID: Subject: Re: [PATCH v3 16/18] x86/domain_page: keep the maphash's slots, not their mappings To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 8:09=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:49AM +0100, George Dunlap wrote: > > unmap_domain_page() keeps a recently unmapped slot in the vCPU's > > maphash (MAPHASH_ENTRIES, 8 per vCPU) for a quick remap of the same > > MFN, and leaves its PTE in place until the entry is displaced by a late= r > > unmap or reclaimed by a full cache. Until then the page stays mapped, > > although nothing refers to the mapping and the mapcache holds no > > reference to the page. A page freed meanwhile and handed to another > > domain stays mapped in the previous user's mapcache: in the vCPU's own > > area for a domain with per-vCPU page-tables, in the domain-wide area of > > a PV domain, where all of its vCPUs can reach it. > > > > While the full directmap is loaded, that reaches nothing it does not > > map anyway. On the sparse view of the directmap, Xen reaches > > domain-heap memory only through mappings made for the purpose, and a > > mapping kept in the maphash would leave another domain's page > > reachable from a context which has nothing to do with it. > > > > Keep the slot, not the mapping: unmapping the last reference zaps the > > PTE and keeps the hash entry, and a later hit maps the page again in th= e > > same slot. The slot has mapped nothing else in between, so that needs > > no flush. Reusing the slot for another page still goes through the > > garbage map, or through the replacement of a hash entry when the cache > > is full, both of which flush first. A translation of the zapped PTE > > left in a TLB is covered, for owned pages, by the flush the page > > allocator arranges before a freed page is reused wherever a sparse view > > is configured ("x86/mm: flush owned pages before reuse with the sparse > > directmap view"). > > As commented on the previous patch, I'm not convinced that's enough. > I do think we need to do a flush here, as it's not so much as the page > being used by another domain (or by Xen itself), internally the guest > might also have different contexts and we should prevent leaks between > them. Same answer as 15; this is meant to close one particular hole, not be a comprehensive closure of all holes. > > The cost is one PTE write per unmap into the maphash and per remap from > > it. A second unmap of an entry in the maphash now finds its PTE not > > present and is caught by the check unmap_domain_page() has for entries > > the first unmap zapped, rather than by the reference count's ASSERT() > > in debug builds only. > > > > The change does not depend on asi=3D or on a sparse view of the directm= ap > > being configured. PV vCPUs use the domain-wide mapcache on the default > > command line too: in debug builds for every page, in release builds for > > pages beyond the reach of the full directmap in their page-tables (5TiB= , > > 3.5TiB with CONFIG_BIGMEM). > > There's likely no need to mention again the exact conditions that make > the mapcache active for PV domains, that's IMO too verbose and doesn't > add anything of value to the reasoning here. I'll reword it, thanks. -George From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:52:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:52:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449577.1665265 (Exim 4.92) (envelope-from ) id 1xH9hi-0000G4-8T; Thu, 15 Oct 2026 00:52:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449577.1665265; Thu, 15 Oct 2026 00:52: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 1xH9hi-0000Fx-59; Thu, 15 Oct 2026 00:52:18 +0000 Received: by outflank-mailman (input) for mailman id 1449577; Thu, 15 Oct 2026 00:52:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9hh-0000FL-Bc for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:52:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9hg-000UBg-Ow for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:52:16 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0239e-8faa-0a2a0a5109dd-0a2a4502d336-12 for ; Thu, 15 Oct 2026 02:52:16 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023bf-6ca4-0a2a45020019-4a68bc043d05-3 for ; Thu, 15 Oct 2026 02:52:16 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0q9JP092045 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:14 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0q9fr092044; Wed, 14 Oct 2026 17:52:09 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Cc: Juergen Gross Date: Wed, 14 Oct 2026 15:31:21 -0700 Subject: [PATCH 2/3] tools/utils: rename "n" arguments to "key" X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-720697/1792025536-66EB32AC-D4655158/0/0 X-purgate-type: clean X-purgate-size: 2375 Date: Wed, 12 Jul 2023 23:29:59 -0700 Hopefully make it clearer to others this is the key associated with the storage value to retrieve. Signed-off-by: Elliott Mitchell --- tools/include/libxlutil.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/tools/include/libxlutil.h b/tools/include/libxlutil.h index fcbe41b15a..0ce66c2096 100644 --- a/tools/include/libxlutil.h +++ b/tools/include/libxlutil.h @@ -56,24 +56,24 @@ void xlu_cfg_destroy(XLU_Config *cfg); * ERANGE value out of range (from strtol) */ -int xlu_cfg_get_string(const XLU_Config *cfg, const char *n, +int xlu_cfg_get_string(const XLU_Config *cfg, const char *key, const char **value_r, int dont_warn); /* free/strdup version */ -int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, +int xlu_cfg_replace_string(const XLU_Config *cfg, const char *key, char **value_r, int dont_warn); -int xlu_cfg_get_long(const XLU_Config *cfg, const char *n, long *value_r, +int xlu_cfg_get_long(const XLU_Config *cfg, const char *key, long *value_r, int dont_warn); -int xlu_cfg_get_bounded_long(const XLU_Config *cfg, const char *n, long min, +int xlu_cfg_get_bounded_long(const XLU_Config *cfg, const char *key, long min, long max, long *value_r, int dont_warn); -int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, +int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *key, libxl_defbool *value_r, int dont_warn); -int xlu_cfg_get_list(const XLU_Config *cfg, const char *n, +int xlu_cfg_get_list(const XLU_Config *cfg, const char *key, XLU_ConfigList **list_r /* may be 0 */, int *entries_r /* may be 0 */, int dont_warn); /* there is no need to free *list_r; lifetime is that of the XLU_Config */ -int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n, +int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *key, libxl_string_list *sl, int dont_warn); const char *xlu_cfg_get_listitem(const XLU_ConfigList *list, int entry); /* xlu_cfg_get_listitem cannot fail, except that if entry is -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:52:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:52:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449574.1665256 (Exim 4.92) (envelope-from ) id 1xH9hc-0008RW-2K; Thu, 15 Oct 2026 00:52:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449574.1665256; Thu, 15 Oct 2026 00:52: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 1xH9hb-0008RO-Us; Thu, 15 Oct 2026 00:52:11 +0000 Received: by outflank-mailman (input) for mailman id 1449574; Thu, 15 Oct 2026 00:52:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9hb-0008RD-Cs for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:52:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9ha-000UBg-QD for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:52:10 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad02340-8faa-0a2a0a5109dd-0a2a4506a8a2-42 for ; Thu, 15 Oct 2026 02:52:10 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023b9-195a-0a2a45060019-4a68bc044b22-3 for ; Thu, 15 Oct 2026 02:52:10 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0q2DA092040 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:08 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0q2Ue092039; Wed, 14 Oct 2026 17:52:02 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Cc: Juergen Gross Date: Wed, 14 Oct 2026 15:31:21 -0700 Subject: [PATCH 1/3] tools/utils: cleanup formatting of libxlutil.h X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-16d1c6/1792025530-F5C0F77B-A8F2EEBB/0/0 X-purgate-type: clean X-purgate-size: 4301 Date: Mon, 10 Jul 2023 15:55:30 -0700 Some arguments included a name, but not all did. Now use "cfg" for all uses of XLU_Config * and "list" for uses of XLU_ConfigList *. Also fix some spaces missing from xlu_cfg_get_defbool()'s prototype. Rename the "b" argument of xlu_cfg_get_defbool() to "value_r". Similar to other functions this is where the returned value is stored. Signed-off-by: Elliott Mitchell --- tools/include/libxlutil.h | 22 +++++++++++----------- tools/libs/util/libxlu_cfg.c | 6 +++--- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/tools/include/libxlutil.h b/tools/include/libxlutil.h index 4dd3c5e92b..fcbe41b15a 100644 --- a/tools/include/libxlutil.h +++ b/tools/include/libxlutil.h @@ -40,12 +40,12 @@ XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename); /* report_filename is copied; report is saved and must remain valid * until the Config is destroyed. */ -int xlu_cfg_readfile(XLU_Config*, const char *real_filename); -int xlu_cfg_readdata(XLU_Config*, const char *data, int length); +int xlu_cfg_readfile(XLU_Config *cfg, const char *real_filename); +int xlu_cfg_readdata(XLU_Config *cfg, const char *data, int length); /* If these fail, then it is undefined behaviour to call xlu_cfg_get_... * functions. You have to just xlu_cfg_destroy. */ -void xlu_cfg_destroy(XLU_Config*); +void xlu_cfg_destroy(XLU_Config *cfg); /* All of the following print warnings to "report" if there is a problem. @@ -56,26 +56,26 @@ void xlu_cfg_destroy(XLU_Config*); * ERANGE value out of range (from strtol) */ -int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r, - int dont_warn); +int xlu_cfg_get_string(const XLU_Config *cfg, const char *n, + const char **value_r, int dont_warn); /* free/strdup version */ int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r, int dont_warn); -int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r, +int xlu_cfg_get_long(const XLU_Config *cfg, const char *n, long *value_r, int dont_warn); -int xlu_cfg_get_bounded_long(const XLU_Config*, const char *n, long min, +int xlu_cfg_get_bounded_long(const XLU_Config *cfg, const char *n, long min, long max, long *value_r, int dont_warn); -int xlu_cfg_get_defbool(const XLU_Config*, const char *n, libxl_defbool *b, - int dont_warn); +int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, + libxl_defbool *value_r, int dont_warn); -int xlu_cfg_get_list(const XLU_Config*, const char *n, +int xlu_cfg_get_list(const XLU_Config *cfg, const char *n, XLU_ConfigList **list_r /* may be 0 */, int *entries_r /* may be 0 */, int dont_warn); /* there is no need to free *list_r; lifetime is that of the XLU_Config */ int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n, libxl_string_list *sl, int dont_warn); -const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry); +const char *xlu_cfg_get_listitem(const XLU_ConfigList *list, int entry); /* xlu_cfg_get_listitem cannot fail, except that if entry is * out of range it returns 0 (not setting errno) */ diff --git a/tools/libs/util/libxlu_cfg.c b/tools/libs/util/libxlu_cfg.c index 874f5abfb9..87ac8c4b41 100644 --- a/tools/libs/util/libxlu_cfg.c +++ b/tools/libs/util/libxlu_cfg.c @@ -328,15 +328,15 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n, dont_warn); } -int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, libxl_defbool *b, - int dont_warn) +int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, + libxl_defbool *value_r, int dont_warn) { int ret; long l; ret = xlu_cfg_get_long(cfg, n, &l, dont_warn); if (ret) return ret; - libxl_defbool_set(b, !!l); + libxl_defbool_set(value_r, !!l); return 0; } -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:52:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:52:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449573.1665247 (Exim 4.92) (envelope-from ) id 1xH9hX-0008Dv-TN; Thu, 15 Oct 2026 00:52:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449573.1665247; Thu, 15 Oct 2026 00:52: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 1xH9hX-0008Dn-O5; Thu, 15 Oct 2026 00:52:07 +0000 Received: by outflank-mailman (input) for mailman id 1449573; Thu, 15 Oct 2026 00:52:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9hW-0008Cc-3M for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:52:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9hV-0072MM-5f for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:52:05 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0234b-e002-0a2a0a5209dd-0a2a4507b636-28 for ; Thu, 15 Oct 2026 02:52:04 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023b3-b4ea-0a2a45070019-4a68bc04e448-3 for ; Thu, 15 Oct 2026 02:52:04 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0puCm092025 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:02 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0pu9p092024; Wed, 14 Oct 2026 17:51:56 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Cc: Juergen Gross Date: Wed, 14 Oct 2026 15:31:21 -0700 Subject: [PATCH 0/3] Some cleanup of tools utility library X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-ef75cf/1792025524-A7AD0AE4-E0BB0A62/0/0 X-purgate-type: clean X-purgate-size: 588 These have been hanging around in my repository for a while. The original submission pass got bungled and other things came up. Simply some small bits of formatting cleanup. Elliott Mitchell (3): tools/utils: cleanup formatting of libxlutil.h tools/utils: rename "n" arguments to "key" tools/utils: remove old declaration of xlu__cfg_yyparse() tools/include/libxlutil.h | 26 +++++++++++++------------- tools/libs/util/libxlu_cfg.c | 6 +++--- tools/libs/util/libxlu_cfg_i.h | 6 ------ 3 files changed, 16 insertions(+), 22 deletions(-) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:52:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:52:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449583.1665274 (Exim 4.92) (envelope-from ) id 1xH9hp-0000a7-Fe; Thu, 15 Oct 2026 00:52:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449583.1665274; Thu, 15 Oct 2026 00:52: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 1xH9hp-0000a0-Be; Thu, 15 Oct 2026 00:52:25 +0000 Received: by outflank-mailman (input) for mailman id 1449583; Thu, 15 Oct 2026 00:52:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9hn-0000Yn-UQ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:52:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9hn-000UBc-BZ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:52:23 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad023c7-2eae-0a2a0a5409dd-0a2a4506da4e-0 for ; Thu, 15 Oct 2026 02:52:23 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023c5-195a-0a2a45060019-4a68bc04f339-3 for ; Thu, 15 Oct 2026 02:52:22 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qFrK092053 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:20 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qFxA092052; Wed, 14 Oct 2026 17:52:15 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Cc: Juergen Gross Date: Wed, 14 Oct 2026 15:31:21 -0700 Subject: [PATCH 3/3] tools/utils: remove old declaration of xlu__cfg_yyparse() X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-16d1c6/1792025543-F627077B-C982B6B3/0/0 X-purgate-type: clean X-purgate-size: 892 Date: Wed, 26 Jul 2023 21:09:21 -0700 This was added at b104c3762dc. Appears this was fixed in the intervening decade. Otherwise this could have been an issue from using advanced features of Bison. Now this appears unnecessary. Signed-off-by: Elliott Mitchell --- tools/libs/util/libxlu_cfg_i.h | 6 ------ 1 file changed, 6 deletions(-) diff --git a/tools/libs/util/libxlu_cfg_i.h b/tools/libs/util/libxlu_cfg_i.h index 4217f5b28d..3717b9460c 100644 --- a/tools/libs/util/libxlu_cfg_i.h +++ b/tools/libs/util/libxlu_cfg_i.h @@ -42,12 +42,6 @@ void xlu__cfgl_lexicalerror(CfgParseContext*, char const *msg); void xlu__cfgl_likely_python(CfgParseContext *ctx); - - -/* Why oh why does bison not declare this in its autogenerated .h ? */ -int xlu__cfg_yyparse(CfgParseContext *ctx); - - #endif /*LIBXLU_CFG_I_H*/ /* -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:52:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:52:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449588.1665283 (Exim 4.92) (envelope-from ) id 1xH9hv-0000vE-MT; Thu, 15 Oct 2026 00:52:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449588.1665283; Thu, 15 Oct 2026 00:52: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 1xH9hv-0000v4-JR; Thu, 15 Oct 2026 00:52:31 +0000 Received: by outflank-mailman (input) for mailman id 1449588; Thu, 15 Oct 2026 00:52:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9ht-0000t7-Se for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:52:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9ht-0072MM-9i for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:52:29 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0234b-e002-0a2a0a5209dd-0a2a4507b636-30 for ; Thu, 15 Oct 2026 02:52:29 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023cb-b4ea-0a2a45070019-4a68bc0480b7-3 for ; Thu, 15 Oct 2026 02:52:29 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qLIO092064 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:26 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qL3H092063; Wed, 14 Oct 2026 17:52:21 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Cc: Juergen Gross Date: Wed, 14 Oct 2026 15:31:49 -0700 Subject: [PATCH 0/5] Some cleanup of libxl JSON handling X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-ef75cf/1792025549-A5CC7AE4-BE8C7A0A/0/0 X-purgate-type: clean X-purgate-size: 1832 Another batch which has been hanging around for a while and never submitted. Here the observation is most of the data passed to the JSON libraries aren't modified. Marking the arguments to the functions as constant is correct and makes the API rather similar to the one used for "SXP". Once that is done some more merging is possible. There seems to be a bit of a difference in how the interface for libjson-c is formatted versus the libyajl variant. I've left it similar to how it appeared to be done, but that looks a bit odd. If there is a desire for linebreaks and indentation feel free. This has been rebased for the new libjson-c library. Only difference was needing to add some duplicate hunks for the new library. Elliott Mitchell (5): tools/libxl: Mark pointer args of many functions constant tools/xl: Mark libxl_domain_config * arg of printf_info_*() const tools/libxl: Tiny optimization of libxl__mac_is_default() tools/xl: Rename printf_info()/list_domains_details() to dump_by_...() tools/xl: Merge down debug/dry-run section of create_domain() tools/include/libxl_json.h | 38 ++++++++++++++++--------------- tools/libs/light/gentypes.py | 12 +++++----- tools/libs/light/libxl_cpuid.c | 7 +++--- tools/libs/light/libxl_internal.c | 8 +++---- tools/libs/light/libxl_internal.h | 18 +++++++-------- tools/libs/light/libxl_json.c | 33 ++++++++++++++------------- tools/libs/light/libxl_nocpuid.c | 4 ++-- tools/xl/xl.h | 13 +++++++---- tools/xl/xl_info.c | 33 +++++++++++++++------------ tools/xl/xl_misc.c | 2 +- tools/xl/xl_sxp.c | 6 ++--- tools/xl/xl_vmcontrol.c | 14 +----------- 12 files changed, 95 insertions(+), 93 deletions(-) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:52:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:52:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449603.1665292 (Exim 4.92) (envelope-from ) id 1xH9i3-0001W9-0o; Thu, 15 Oct 2026 00:52:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449603.1665292; Thu, 15 Oct 2026 00:52: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 1xH9i2-0001Vz-Ra; Thu, 15 Oct 2026 00:52:38 +0000 Received: by outflank-mailman (input) for mailman id 1449603; Thu, 15 Oct 2026 00:52:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9i0-0001Np-Uv for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:52:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9i0-000UBc-C2 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:52:36 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0237f-2eae-0a2a0a5409dd-0a2a45019930-48 for ; Thu, 15 Oct 2026 02:52:36 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023d2-5984-0a2a45010019-4a68bc04381d-3 for ; Thu, 15 Oct 2026 02:52:36 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qR49092077 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:33 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qRkH092076; Wed, 14 Oct 2026 17:52:27 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <52487ef2d0f13d5d1e92d6fcfd8ec0f057bd1e90.1792017109.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Cc: Juergen Gross Date: Wed, 14 Oct 2026 15:31:49 -0700 Subject: [PATCH 1/5] tools/libxl: Mark pointer args of many functions constant X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-d62444/1792025556-C5540757-8CA1C62D/0/0 X-purgate-type: clean X-purgate-size: 18820 Date: Fri, 18 Dec 2020 13:37:44 -0800 Anything *_is_empty(), *_is_default(), or *_gen_json() is going to be examining the pointed to thing, not modifying it. This potentially results in higher-performance output. This also allows spreading constants further, allowing more checking and security. Signed-off-by: Elliott Mitchell --- tools/include/libxl_json.h | 38 ++++++++++++++++--------------- tools/libs/light/gentypes.py | 12 +++++----- tools/libs/light/libxl_cpuid.c | 7 +++--- tools/libs/light/libxl_internal.c | 4 ++-- tools/libs/light/libxl_internal.h | 18 +++++++-------- tools/libs/light/libxl_json.c | 33 ++++++++++++++------------- tools/libs/light/libxl_nocpuid.c | 4 ++-- 7 files changed, 60 insertions(+), 56 deletions(-) diff --git a/tools/include/libxl_json.h b/tools/include/libxl_json.h index c130e88a5e..3b03fdc04a 100644 --- a/tools/include/libxl_json.h +++ b/tools/include/libxl_json.h @@ -33,29 +33,31 @@ #define _hidden #endif _hidden int libxl__uint64_gen_jso(json_object **jso_r, uint64_t val); -_hidden int libxl_defbool_gen_jso(json_object **jso_r, libxl_defbool *p); -_hidden int libxl_uuid_gen_jso(json_object **jso_r, libxl_uuid *p); -_hidden int libxl_mac_gen_jso(json_object **jso_r, libxl_mac *p); -_hidden int libxl_bitmap_gen_jso(json_object **jso_r, libxl_bitmap *p); -_hidden int libxl_cpuid_policy_list_gen_jso(json_object **jso_r,libxl_cpuid_policy_list *p); -_hidden int libxl_string_list_gen_jso(json_object **jso_r,libxl_string_list *p); -_hidden int libxl_key_value_list_gen_jso(json_object **jso_r, libxl_key_value_list *p); -_hidden int libxl_hwcap_gen_jso(json_object **jso_r, libxl_hwcap *p); -_hidden int libxl_ms_vm_genid_gen_jso(json_object **jso_r, libxl_ms_vm_genid *p); +_hidden int libxl_defbool_gen_jso(json_object **jso_r, const libxl_defbool *p); +_hidden int libxl_uuid_gen_jso(json_object **jso_r, const libxl_uuid *p); +_hidden int libxl_mac_gen_jso(json_object **jso_r, const libxl_mac *p); +_hidden int libxl_bitmap_gen_jso(json_object **jso_r, const libxl_bitmap *p); +_hidden int libxl_cpuid_policy_list_gen_jso(json_object **jso_r, const libxl_cpuid_policy_list *p); +_hidden int libxl_string_list_gen_jso(json_object **jso_r, const libxl_string_list *p); +_hidden int libxl_key_value_list_gen_jso(json_object **jso_r, const libxl_key_value_list *p); +_hidden int libxl_hwcap_gen_jso(json_object **jso_r, const libxl_hwcap *p); +_hidden int libxl_ms_vm_genid_gen_jso(json_object **jso_r, const libxl_ms_vm_genid *p); #endif #if defined(HAVE_LIBYAJL) yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val); -yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p); -yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p); -yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p); -yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, libxl_bitmap *p); +yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, const libxl_defbool *p); +yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, const libxl_uuid *p); +yajl_gen_status libxl_mac_gen_json(yajl_gen hand, const libxl_mac *p); +yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, const libxl_bitmap *p); yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand, - libxl_cpuid_policy_list *p); -yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p); + const libxl_cpuid_policy_list *p); +yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, + const libxl_string_list *p); yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand, - libxl_key_value_list *p); -yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p); -yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, libxl_ms_vm_genid *p); + const libxl_key_value_list *p); +yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, const libxl_hwcap *p); +yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, + const libxl_ms_vm_genid *p); #endif #include <_libxl_types_json.h> diff --git a/tools/libs/light/gentypes.py b/tools/libs/light/gentypes.py index 47bca4bc57..7defc47554 100644 --- a/tools/libs/light/gentypes.py +++ b/tools/libs/light/gentypes.py @@ -763,7 +763,7 @@ if __name__ == '__main__': ty.make_arg("p"), ku.keyvar.type.make_arg(ku.keyvar.name))) if ty.json_gen_fn is not None: - f.write("%schar *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p"))) + f.write("%schar *%s_to_json(libxl_ctx *ctx, const %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p"))) if ty.json_parse_fn is not None: f.write("%sint %s_from_json(libxl_ctx *ctx, %s, const char *s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) if isinstance(ty, idl.Enumeration): @@ -795,9 +795,9 @@ if __name__ == '__main__': for ty in [ty for ty in types if ty.json_gen_fn is not None]: if opt_libjsonc: # Always hide JSON generators base on json-c - f.write("%sint %s_gen_jso(json_object **jso_r, %s);\n" % ("_hidden ", ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) + f.write("%sint %s_gen_jso(json_object **jso_r, const %s);\n" % ("_hidden ", ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) else: - f.write("%syajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) + f.write("%syajl_gen_status %s_gen_json(yajl_gen hand, const %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) f.write("\n") f.write("""#endif /* %s */\n""" % header_json_define) @@ -902,19 +902,19 @@ if __name__ == '__main__': for ty in [t for t in types if t.json_gen_fn is not None]: if opt_libjsonc: - f.write("int %s_gen_jso(json_object **jso_r, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) + f.write("int %s_gen_jso(json_object **jso_r, const %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) f.write("{\n") f.write(libxl_C_type_gen_jso(ty, "p")) f.write("}\n") f.write("\n") else: - f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) + f.write("yajl_gen_status %s_gen_json(yajl_gen hand, const %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))) f.write("{\n") f.write(libxl_C_type_gen_json(ty, "p")) f.write("}\n") f.write("\n") - f.write("char *%s_to_json(libxl_ctx *ctx, %s)\n" % (ty.typename, ty.make_arg("p"))) + f.write("char *%s_to_json(libxl_ctx *ctx, const %s)\n" % (ty.typename, ty.make_arg("p"))) f.write("{\n") if opt_libjsonc: f.write(libxl_C_type_to_json(ty, "p", fn_ptr_type="libxl__gen_json_callback", fn_suffix="_gen_jso")) diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c index 14f08df33a..40a188bfb1 100644 --- a/tools/libs/light/libxl_cpuid.c +++ b/tools/libs/light/libxl_cpuid.c @@ -16,7 +16,7 @@ #include -int libxl__cpuid_policy_is_empty(libxl_cpuid_policy_list *pl) +int libxl__cpuid_policy_is_empty(const libxl_cpuid_policy_list *pl) { return !*pl || (!libxl_cpuid_policy_list_length(pl) && !(*pl)->msr); } @@ -549,7 +549,7 @@ static const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" }; */ #ifdef HAVE_LIBJSONC -int libxl_cpuid_policy_list_gen_jso(json_object **jso_r, libxl_cpuid_policy_list *pl) +int libxl_cpuid_policy_list_gen_jso(json_object **jso_r, const libxl_cpuid_policy_list *pl) { libxl_cpuid_policy_list policy = *pl; struct xc_xend_cpuid *cpuid; @@ -667,7 +667,7 @@ out: #ifdef HAVE_LIBYAJL yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand, - libxl_cpuid_policy_list *pl) + const libxl_cpuid_policy_list *pl) { libxl_cpuid_policy_list policy = *pl; struct xc_xend_cpuid *cpuid; diff --git a/tools/libs/light/libxl_internal.c b/tools/libs/light/libxl_internal.c index d70cfed7d8..cd99d249bf 100644 --- a/tools/libs/light/libxl_internal.c +++ b/tools/libs/light/libxl_internal.c @@ -333,7 +333,7 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac) return 0; } -_hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b) +_hidden int libxl__compare_macs(const libxl_mac *a, const libxl_mac *b) { int i; @@ -345,7 +345,7 @@ _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b) return 0; } -_hidden int libxl__mac_is_default(libxl_mac *mac) +_hidden int libxl__mac_is_default(const libxl_mac *mac) { return (!(*mac)[0] && !(*mac)[1] && !(*mac)[2] && !(*mac)[3] && !(*mac)[4] && !(*mac)[5]); diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h index b65e0064b9..a070112836 100644 --- a/tools/libs/light/libxl_internal.h +++ b/tools/libs/light/libxl_internal.h @@ -2021,9 +2021,9 @@ struct libxl__xen_console_reader { /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */ _hidden int libxl__parse_mac(const char *s, libxl_mac mac); /* compare mac address @a and @b. 0 if the same, -ve if ab */ -_hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b); +_hidden int libxl__compare_macs(const libxl_mac *a, const libxl_mac *b); /* return true if mac address is all zero (the default value) */ -_hidden int libxl__mac_is_default(libxl_mac *mac); +_hidden int libxl__mac_is_default(const libxl_mac *mac); /* init a recursive mutex */ _hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock); @@ -4543,7 +4543,7 @@ _hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid, #define LIBXL__DEFBOOL_STR_DEFAULT "" #define LIBXL__DEFBOOL_STR_FALSE "False" #define LIBXL__DEFBOOL_STR_TRUE "True" -static inline int libxl__defbool_is_default(libxl_defbool *db) +static inline int libxl__defbool_is_default(const libxl_defbool *db) { return !db->val; } @@ -4638,22 +4638,22 @@ int libxl__random_bytes(libxl__gc *gc, uint8_t *buf, size_t len); #include "_libxl_types_internal_private.h" /* This always return false, there's no "default value" for hw cap */ -static inline int libxl__hwcap_is_default(libxl_hwcap *hwcap) +static inline int libxl__hwcap_is_default(const libxl_hwcap *hwcap) { return 0; } -static inline int libxl__string_list_is_empty(libxl_string_list *psl) +static inline int libxl__string_list_is_empty(const libxl_string_list *psl) { return !libxl_string_list_length(psl); } -static inline int libxl__key_value_list_is_empty(libxl_key_value_list *pkvl) +static inline int libxl__key_value_list_is_empty(const libxl_key_value_list *pkvl) { return !libxl_key_value_list_length(pkvl); } -int libxl__cpuid_policy_is_empty(libxl_cpuid_policy_list *pl); +int libxl__cpuid_policy_is_empty(const libxl_cpuid_policy_list *pl); /* Portability note: a proper flock(2) implementation is required */ typedef struct { @@ -4787,12 +4787,12 @@ void* libxl__device_list(libxl__gc *gc, const libxl__device_type *dt, void libxl__device_list_free(const libxl__device_type *dt, void *list, int num); -static inline bool libxl__timer_mode_is_default(libxl_timer_mode *tm) +static inline bool libxl__timer_mode_is_default(const libxl_timer_mode *tm) { return *tm == LIBXL_TIMER_MODE_DEFAULT; } -static inline bool libxl__string_is_default(char **s) +static inline bool libxl__string_is_default(char *const *s) { return *s == NULL; } diff --git a/tools/libs/light/libxl_json.c b/tools/libs/light/libxl_json.c index 68f36901c2..38c27a9f4b 100644 --- a/tools/libs/light/libxl_json.c +++ b/tools/libs/light/libxl_json.c @@ -139,7 +139,7 @@ yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str) * YAJL generators for builtin libxl types. */ #ifdef HAVE_LIBJSONC -int libxl_defbool_gen_jso(json_object **jso_r, libxl_defbool *db) +int libxl_defbool_gen_jso(json_object **jso_r, const libxl_defbool *db) { *jso_r = json_object_new_string(libxl_defbool_to_string(*db)); if (!*jso_r) @@ -150,7 +150,7 @@ int libxl_defbool_gen_jso(json_object **jso_r, libxl_defbool *db) #ifdef HAVE_LIBYAJL yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, - libxl_defbool *db) + const libxl_defbool *db) { return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db)); } @@ -203,7 +203,7 @@ int libxl__bool_parse_json(libxl__gc *gc, const libxl__json_object *o, } #ifdef HAVE_LIBJSONC -int libxl_uuid_gen_jso(json_object **jso_r, libxl_uuid *uuid) +int libxl_uuid_gen_jso(json_object **jso_r, const libxl_uuid *uuid) { char buf[LIBXL_UUID_FMTLEN+1]; snprintf(buf, sizeof(buf), LIBXL_UUID_FMT, LIBXL_UUID_BYTES((*uuid))); @@ -216,7 +216,7 @@ int libxl_uuid_gen_jso(json_object **jso_r, libxl_uuid *uuid) #ifdef HAVE_LIBYAJL yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, - libxl_uuid *uuid) + const libxl_uuid *uuid) { char buf[LIBXL_UUID_FMTLEN+1]; snprintf(buf, sizeof(buf), LIBXL_UUID_FMT, LIBXL_UUID_BYTES((*uuid))); @@ -234,7 +234,7 @@ int libxl__uuid_parse_json(libxl__gc *gc, const libxl__json_object *o, } #ifdef HAVE_LIBJSONC -int libxl_bitmap_gen_jso(json_object **jso_r, libxl_bitmap *bitmap) +int libxl_bitmap_gen_jso(json_object **jso_r, const libxl_bitmap *bitmap) { json_object *jso; int i; @@ -267,7 +267,7 @@ out: #ifdef HAVE_LIBYAJL yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, - libxl_bitmap *bitmap) + const libxl_bitmap *bitmap) { yajl_gen_status s; int i; @@ -322,7 +322,7 @@ int libxl__bitmap_parse_json(libxl__gc *gc, const libxl__json_object *o, } #ifdef HAVE_LIBJSONC -int libxl_key_value_list_gen_jso(json_object **jso_r, libxl_key_value_list *pkvl) +int libxl_key_value_list_gen_jso(json_object **jso_r, const libxl_key_value_list *pkvl) { libxl_key_value_list kvl = *pkvl; json_object *jso; @@ -358,7 +358,7 @@ out: #ifdef HAVE_LIBYAJL yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand, - libxl_key_value_list *pkvl) + const libxl_key_value_list *pkvl) { libxl_key_value_list kvl = *pkvl; yajl_gen_status s; @@ -421,7 +421,7 @@ int libxl__key_value_list_parse_json(libxl__gc *gc, const libxl__json_object *o, } #ifdef HAVE_LIBJSONC -int libxl_string_list_gen_jso(json_object **jso_r, libxl_string_list *pl) +int libxl_string_list_gen_jso(json_object **jso_r, const libxl_string_list *pl) { libxl_string_list l = *pl; json_object *jso; @@ -453,7 +453,7 @@ out: #endif #ifdef HAVE_LIBYAJL -yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl) +yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, const libxl_string_list *pl) { libxl_string_list l = *pl; yajl_gen_status s; @@ -508,7 +508,7 @@ int libxl__string_list_parse_json(libxl__gc *gc, const libxl__json_object *o, } #ifdef HAVE_LIBJSONC -int libxl_mac_gen_jso(json_object **jso_r, libxl_mac *mac) +int libxl_mac_gen_jso(json_object **jso_r, const libxl_mac *mac) { char buf[LIBXL_MAC_FMTLEN+1]; snprintf(buf, sizeof(buf), LIBXL_MAC_FMT, LIBXL_MAC_BYTES((*mac))); @@ -520,7 +520,7 @@ int libxl_mac_gen_jso(json_object **jso_r, libxl_mac *mac) #endif #ifdef HAVE_LIBYAJL -yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *mac) +yajl_gen_status libxl_mac_gen_json(yajl_gen hand, const libxl_mac *mac) { char buf[LIBXL_MAC_FMTLEN+1]; snprintf(buf, sizeof(buf), LIBXL_MAC_FMT, LIBXL_MAC_BYTES((*mac))); @@ -538,7 +538,7 @@ int libxl__mac_parse_json(libxl__gc *gc, const libxl__json_object *o, } #ifdef HAVE_LIBJSONC -int libxl_hwcap_gen_jso(json_object **jso_r, libxl_hwcap *p) +int libxl_hwcap_gen_jso(json_object **jso_r, const libxl_hwcap *p) { json_object *jso; int i; @@ -568,7 +568,7 @@ out: #ifdef HAVE_LIBYAJL yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, - libxl_hwcap *p) + const libxl_hwcap *p) { yajl_gen_status s; int i; @@ -608,7 +608,7 @@ int libxl__hwcap_parse_json(libxl__gc *gc, const libxl__json_object *o, } #ifdef HAVE_LIBJSONC -int libxl_ms_vm_genid_gen_jso(json_object **jso_r, libxl_ms_vm_genid *p) +int libxl_ms_vm_genid_gen_jso(json_object **jso_r, const libxl_ms_vm_genid *p) { json_object *jso; int i; @@ -638,7 +638,8 @@ out: #endif #ifdef HAVE_LIBYAJL -yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, libxl_ms_vm_genid *p) +yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, + const libxl_ms_vm_genid *p) { yajl_gen_status s; int i; diff --git a/tools/libs/light/libxl_nocpuid.c b/tools/libs/light/libxl_nocpuid.c index ce334633b3..35c465b329 100644 --- a/tools/libs/light/libxl_nocpuid.c +++ b/tools/libs/light/libxl_nocpuid.c @@ -14,7 +14,7 @@ #include "libxl_internal.h" -int libxl__cpuid_policy_is_empty(libxl_cpuid_policy_list *pl) +int libxl__cpuid_policy_is_empty(const libxl_cpuid_policy_list *pl) { return 1; } @@ -50,7 +50,7 @@ int libxl_cpuid_policy_list_gen_jso(json_object **jso_r, libxl_cpuid_policy_list #ifdef HAVE_LIBYAJL yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand, - libxl_cpuid_policy_list *pcpuid) + const libxl_cpuid_policy_list *pcpuid) { return 0; } -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:52:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:52:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449612.1665302 (Exim 4.92) (envelope-from ) id 1xH9i8-0001uE-Bz; Thu, 15 Oct 2026 00:52:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449612.1665302; Thu, 15 Oct 2026 00: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 1xH9i8-0001u4-7I; Thu, 15 Oct 2026 00:52:44 +0000 Received: by outflank-mailman (input) for mailman id 1449612; Thu, 15 Oct 2026 00:52:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9i7-0001qU-2P for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:52:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9i6-000U9c-Ft for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:52:42 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad023d8-bab6-0a2a0a5309dd-0a2a4505dea4-6 for ; Thu, 15 Oct 2026 02:52:42 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023d9-4cb1-0a2a45050019-4a68bc04ca60-3 for ; Thu, 15 Oct 2026 02:52:42 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qYHR092086 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:40 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qYhQ092085; Wed, 14 Oct 2026 17:52:34 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <6bd9ae49a7b834d2d38fbebb48f20615860cc1c4.1792017109.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Wed, 14 Oct 2026 15:31:49 -0700 Subject: [PATCH 2/5] tools/xl: Mark libxl_domain_config * arg of printf_info_*() const X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-c201ff/1792025562-F52A32A1-25373472/0/0 X-purgate-type: clean X-purgate-size: 2776 Date: Fri, 18 Dec 2020 13:32:33 -0800 With libxl having gotten a lot more constant, now printf_info_sexp() and printf_info_one_json() can add consts. May not be particularly important, but it is best to mark things constant when they are known to be so. Signed-off-by: Elliott Mitchell --- tools/xl/xl.h | 2 +- tools/xl/xl_info.c | 4 ++-- tools/xl/xl_sxp.c | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index 7b75f9a493..dcd77d1ec4 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -308,7 +308,7 @@ typedef enum { DOMAIN_RESTART_SUSPENDED, /* Domain suspended - keep looping */ } domain_restart_type; -extern void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE *fh); +extern void printf_info_sexp(int domid, const libxl_domain_config *d_config, FILE *fh); extern void apply_global_affinity_masks(libxl_domain_type type, libxl_bitmap *vcpu_affinity_array, unsigned int size); diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c index 98fc879e63..9540384beb 100644 --- a/tools/xl/xl_info.c +++ b/tools/xl/xl_info.c @@ -63,7 +63,7 @@ static int maybe_printf(const char *fmt, ...) #ifdef HAVE_LIBJSONC static int printf_info_one_json(json_object **jso_r, int domid, - libxl_domain_config *d_config) + const libxl_domain_config *d_config) { json_object *jso = NULL; json_object *jso_config = NULL; @@ -108,7 +108,7 @@ out: #elif defined(HAVE_LIBYAJL) static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid, - libxl_domain_config *d_config) + const libxl_domain_config *d_config) { yajl_gen_status s; diff --git a/tools/xl/xl_sxp.c b/tools/xl/xl_sxp.c index 4383ad177a..d2347e401a 100644 --- a/tools/xl/xl_sxp.c +++ b/tools/xl/xl_sxp.c @@ -26,13 +26,13 @@ /* In general you should not add new output to this function since it * is intended only for legacy use. */ -void printf_info_sexp(int domid, libxl_domain_config *d_config, FILE *fh) +void printf_info_sexp(int domid, const libxl_domain_config *d_config, FILE *fh) { int i; libxl_dominfo info; - libxl_domain_create_info *c_info = &d_config->c_info; - libxl_domain_build_info *b_info = &d_config->b_info; + const libxl_domain_create_info *c_info = &d_config->c_info; + const libxl_domain_build_info *b_info = &d_config->b_info; fprintf(fh, "(domain\n\t(domid %d)\n", domid); fprintf(fh, "\t(create_info)\n"); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:53:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:53:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449644.1665311 (Exim 4.92) (envelope-from ) id 1xH9iX-0002w4-J4; Thu, 15 Oct 2026 00:53:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449644.1665311; Thu, 15 Oct 2026 00: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 1xH9iX-0002vv-FS; Thu, 15 Oct 2026 00:53:09 +0000 Received: by outflank-mailman (input) for mailman id 1449644; Thu, 15 Oct 2026 00:53:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9iW-0002vF-6x for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:53:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9iV-000UIK-KP for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:53:07 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad023ef-bab6-0a2a0a5309dd-0a2a4503aaa6-2 for ; Thu, 15 Oct 2026 02:53:07 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023f2-fae8-0a2a45030019-4a68bc0495c6-3 for ; Thu, 15 Oct 2026 02:53:07 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qxOo092124 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:53:05 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qxYi092123; Wed, 14 Oct 2026 17:52:59 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Wed, 14 Oct 2026 15:32:24 -0700 Subject: [PATCH 0/3] Minor cleanup of create_domain() X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-33051d/1792025587-77AC44E9-239EDCAC/0/0 X-purgate-type: clean X-purgate-size: 790 Something which has annoyed me for a long while decided to get in front of me again. As such getting some cleanup done as the start of addressing that annoyance. This is some minor cleanup related to create_domain(). First is simply a bit of precursor Makefile cleanup. Next two are things which can be done earlier in the function and really look like they should be. Elliott Mitchell (3): tools/xl: use Make variable to retrieve xl object filename list tools/xl: free loaded configuration data earlier in create_domain() tools/xl: move some logic needed only once earlier in create_domain() tools/xl/Makefile | 2 +- tools/xl/xl_vmcontrol.c | 36 +++++++++++++++++------------------- 2 files changed, 18 insertions(+), 20 deletions(-) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:53:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:53:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449655.1665319 (Exim 4.92) (envelope-from ) id 1xH9id-0003Gp-PU; Thu, 15 Oct 2026 00:53:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449655.1665319; Thu, 15 Oct 2026 00:53: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 1xH9id-0003Gi-MD; Thu, 15 Oct 2026 00:53:15 +0000 Received: by outflank-mailman (input) for mailman id 1449655; Thu, 15 Oct 2026 00:53:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9ic-0003F3-BC for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:53:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9ib-0072MM-OS for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:53:13 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0234b-e002-0a2a0a5209dd-0a2a4507b636-42 for ; Thu, 15 Oct 2026 02:53:13 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023f8-b4ea-0a2a45070019-4a68bc04534c-3 for ; Thu, 15 Oct 2026 02:53:13 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0r6x2092129 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:53:11 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0r65D092128; Wed, 14 Oct 2026 17:53:06 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Tue, 13 Oct 2026 20:15:00 -0700 Subject: [PATCH 1/3] tools/xl: use Make variable to retrieve xl object filename list X-Spam-Status: No, score=1.2 required=10.0 tests=DATE_IN_PAST_12_24, KHOP_HELO_FCRDNS,T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-ef75cf/1792025593-A48C9AE4-4BEB20D2/0/0 X-purgate-type: clean X-purgate-size: 841 Irrelevant now, but $^ potentially makes the Makefile more maintainable. Hopefully some future author finds this valuable. --- tools/xl/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/xl/Makefile b/tools/xl/Makefile index e4eed8be13..8fbd4ae778 100644 --- a/tools/xl/Makefile +++ b/tools/xl/Makefile @@ -34,7 +34,7 @@ $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs i all: xl xl: $(XL_OBJS) - $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) $(LDLIBS_libxenutil) $(LDLIBS_libxenlight) $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(XEN_JSON_LIBS) $(APPEND_LDFLAGS) + $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS_libxenutil) $(LDLIBS_libxenlight) $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(XEN_JSON_LIBS) $(APPEND_LDFLAGS) .PHONY: install install: all -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:53:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:53:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449665.1665328 (Exim 4.92) (envelope-from ) id 1xH9iq-0003uE-1U; Thu, 15 Oct 2026 00:53:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449665.1665328; Thu, 15 Oct 2026 00:53: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 1xH9ip-0003u5-Uh; Thu, 15 Oct 2026 00:53:27 +0000 Received: by outflank-mailman (input) for mailman id 1449665; Thu, 15 Oct 2026 00:53:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9io-0003pi-Bz for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:53:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9in-000UBg-Ns for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:53:25 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0239e-8faa-0a2a0a5109dd-0a2a4502d336-42 for ; Thu, 15 Oct 2026 02:53:25 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad02404-6ca4-0a2a45020019-4a68bc04ec6b-3 for ; Thu, 15 Oct 2026 02:53:25 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0rI90092143 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:53:23 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0rIQu092142; Wed, 14 Oct 2026 17:53:18 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <92156ced183670bbbcb2d3f9e2dca4d12f37ee7c.1792017144.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Mon, 12 Oct 2026 18:03:49 -0700 Subject: [PATCH 3/3] tools/xl: move some logic needed only once earlier in create_domain() X-Spam-Status: No, score=0.9 required=10.0 tests=DATE_IN_PAST_24_48, KHOP_HELO_FCRDNS,T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-720697/1792025605-317CA2AC-8EA945BF/0/0 X-purgate-type: clean X-purgate-size: 2519 The value of dom_info->console_autoconnect isn't going to change if a domain is rebooted. Nor does this logic need the lock to be held. As such moving this earlier makes sense. The policy domain is set once and then never changed. Similar to above simply move before the reboot start point. Signed-off-by: Elliott Mitchell --- tools/xl/xl_vmcontrol.c | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c index 76c2a07ee8..ae7985122f 100644 --- a/tools/xl/xl_vmcontrol.c +++ b/tools/xl/xl_vmcontrol.c @@ -717,7 +717,8 @@ int create_domain(struct domain_create *dom_info) int restore_fd = -1; int restore_fd_to_close = -1; int send_back_fd = -1; - const libxl_asyncprogress_how *autoconnect_console_how; + const libxl_asyncprogress_how *autoconnect_console_how = NULL; + libxl_asyncprogress_how autoconnect_console_how_buf; int notify_pipe[2] = { -1, -1 }; struct save_file_header hdr; uint32_t domid_soft_reset = INVALID_DOMID; @@ -921,6 +922,19 @@ int create_domain(struct domain_create *dom_info) if (dryrun_only) goto out; + if (dom_info->console_autoconnect) { + if (libxl_pipe(ctx, notify_pipe)) { + ret = ERROR_FAIL; + goto error_out; + } + autoconnect_console_how_buf.callback = autoconnect_console; + autoconnect_console_how_buf.for_callback = ¬ify_pipe[1]; + autoconnect_console_how = &autoconnect_console_how_buf; + } + + if (!libxl_domid_valid_guest(d_config.c_info.domid)) + d_config.c_info.domid = domid_policy; + start: assert(domid == INVALID_DOMID); @@ -938,22 +952,6 @@ start: } } - libxl_asyncprogress_how autoconnect_console_how_buf; - if ( dom_info->console_autoconnect ) { - if (libxl_pipe(ctx, notify_pipe)) { - ret = ERROR_FAIL; - goto error_out; - } - autoconnect_console_how_buf.callback = autoconnect_console; - autoconnect_console_how_buf.for_callback = ¬ify_pipe[1]; - autoconnect_console_how = &autoconnect_console_how_buf; - }else{ - autoconnect_console_how = 0; - } - - if (!libxl_domid_valid_guest(d_config.c_info.domid)) - d_config.c_info.domid = domid_policy; - if ( restoring ) { libxl_domain_restore_params params; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:55:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:55:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449695.1665337 (Exim 4.92) (envelope-from ) id 1xH9kg-0005IN-Bo; Thu, 15 Oct 2026 00:55:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449695.1665337; Thu, 15 Oct 2026 00:55: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 1xH9kg-0005IG-8L; Thu, 15 Oct 2026 00:55:22 +0000 Received: by outflank-mailman (input) for mailman id 1449695; Thu, 15 Oct 2026 00:55:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9ke-0005H5-Ls for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:55:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9kd-0072aV-Vv for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:55:19 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad02470-bab6-0a2a0a5309dd-0a2a450399e6-6 for ; Thu, 15 Oct 2026 02:55:19 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023fe-fae8-0a2a45030019-4a68bc04c2dc-3 for ; Thu, 15 Oct 2026 02:53:19 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0rCts092135 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:53:17 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0rC1i092134; Wed, 14 Oct 2026 17:53:12 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Tue, 13 Oct 2026 19:16:41 -0700 Subject: [PATCH 2/3] tools/xl: free loaded configuration data earlier in create_domain() X-Spam-Status: No, score=1.2 required=10.0 tests=DATE_IN_PAST_12_24, KHOP_HELO_FCRDNS,T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-33051d/1792025599-756834E9-5B50BEB9/0/0 X-purgate-type: clean X-purgate-size: 940 Rather than waiting for just before return, release the memory sooner. This potentially reduces process size due to be reused sooner. Also ensures it never gets into the daemon process. --- tools/xl/xl_vmcontrol.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c index 93766f631b..76c2a07ee8 100644 --- a/tools/xl/xl_vmcontrol.c +++ b/tools/xl/xl_vmcontrol.c @@ -853,6 +853,8 @@ int create_domain(struct domain_create *dom_info) parse_config_data(config_source, config_data, config_len, &d_config); } + free(config_data); + if (!dom_info->ignore_global_affinity_masks) { libxl_domain_build_info *b_info = &d_config.b_info; @@ -1200,8 +1202,6 @@ out: libxl_domain_config_dispose(&d_config); - free(config_data); - console_child_report(child_console); if (deathw) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:55:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:55:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449707.1665345 (Exim 4.92) (envelope-from ) id 1xH9l8-0005su-JU; Thu, 15 Oct 2026 00:55:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449707.1665345; Thu, 15 Oct 2026 00: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 1xH9l8-0005sk-Fu; Thu, 15 Oct 2026 00:55:50 +0000 Received: by outflank-mailman (input) for mailman id 1449707; Thu, 15 Oct 2026 00:55:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9l8-0005sc-3b for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:55:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9l7-000UVg-Gv for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:55:49 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad02494-2eae-0a2a0a5409dd-0a2a4509e4e2-4 for ; Thu, 15 Oct 2026 02:55:49 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023df-be1a-0a2a45090019-4a68bc045099-3 for ; Thu, 15 Oct 2026 02:52:49 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qeZr092095 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:47 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qeeU092094; Wed, 14 Oct 2026 17:52:40 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <3fbe613739d1fb39f25b249b8a1c20b1dabfb568.1792017109.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Cc: Juergen Gross Date: Wed, 14 Oct 2026 15:31:49 -0700 Subject: [PATCH 3/5] tools/libxl: Tiny optimization of libxl__mac_is_default() X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-bad1c0/1792025569-3A0C5034-912BB028/0/0 X-purgate-type: clean X-purgate-size: 954 Date: Fri, 18 Dec 2020 14:45:02 -0800 This should result in fewer branch instructions and a small performance gain. Signed-off-by: Elliott Mitchell --- tools/libs/light/libxl_internal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libs/light/libxl_internal.c b/tools/libs/light/libxl_internal.c index cd99d249bf..b5b4825619 100644 --- a/tools/libs/light/libxl_internal.c +++ b/tools/libs/light/libxl_internal.c @@ -347,8 +347,8 @@ _hidden int libxl__compare_macs(const libxl_mac *a, const libxl_mac *b) _hidden int libxl__mac_is_default(const libxl_mac *mac) { - return (!(*mac)[0] && !(*mac)[1] && !(*mac)[2] && - !(*mac)[3] && !(*mac)[4] && !(*mac)[5]); + return !((*mac)[0] | (*mac)[1] | (*mac)[2] | + (*mac)[3] | (*mac)[4] | (*mac)[5]); } _hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:56:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:56:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449726.1665354 (Exim 4.92) (envelope-from ) id 1xH9mD-0006bq-S1; Thu, 15 Oct 2026 00:56:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449726.1665354; Thu, 15 Oct 2026 00:56: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 1xH9mD-0006bj-PE; Thu, 15 Oct 2026 00:56:57 +0000 Received: by outflank-mailman (input) for mailman id 1449726; Thu, 15 Oct 2026 00:56:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9mC-0006bZ-BI for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:56:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9mB-000f30-OX for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:56:55 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad024ba-2eae-0a2a0a5409dd-0a2a45069a8a-10 for ; Thu, 15 Oct 2026 02:56:55 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023e6-195a-0a2a45060019-4a68bc049865-3 for ; Thu, 15 Oct 2026 02:52:55 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qlqs092107 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:53 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qluB092106; Wed, 14 Oct 2026 17:52:47 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <3e16e6a2e11afff7bf2f309bdb98ffaf5278cdd6.1792017109.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Wed, 14 Oct 2026 15:31:49 -0700 Subject: [PATCH 4/5] tools/xl: Rename printf_info()/list_domains_details() to dump_by_...() X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-16d1c6/1792025575-F7ECC77B-634584A7/13/0 X-purgate-type: clean X-purgate-size: 6085 Date: Thu, 17 Dec 2020 17:42:42 -0800 printf_info()/list_domains_details() had been serving fairly similar purposes. Increase their consistency (add file-handle and output_format arguments to list_domains_details(), reorder arguments) and then rename to better reflect their functionality. Both were simply outputting full domain information. As this is more of a dump operation, "dump" is a better name. Signed-off-by: Elliott Mitchell --- tools/xl/xl.h | 11 ++++++++--- tools/xl/xl_info.c | 29 +++++++++++++++++------------ tools/xl/xl_misc.c | 2 +- 3 files changed, 26 insertions(+), 16 deletions(-) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index dcd77d1ec4..7fd33db800 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -308,13 +308,18 @@ typedef enum { DOMAIN_RESTART_SUSPENDED, /* Domain suspended - keep looping */ } domain_restart_type; +extern void dump_by_config(enum output_format output_format, + FILE *fh, + const libxl_domain_config *d_config, + int domid); +extern void dump_by_dominfo_list(enum output_format output_format, + FILE *fh, + const libxl_dominfo info[], + int nb_domain); extern void printf_info_sexp(int domid, const libxl_domain_config *d_config, FILE *fh); extern void apply_global_affinity_masks(libxl_domain_type type, libxl_bitmap *vcpu_affinity_array, unsigned int size); -void printf_info(enum output_format output_format, - int domid, - libxl_domain_config *d_config, FILE *fh); #define XL_GLOBAL_CONFIG XEN_CONFIG_DIR "/xl.conf" #define XL_LOCK_FILE XEN_LOCK_DIR "/xl" diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c index 9540384beb..46bba4bb54 100644 --- a/tools/xl/xl_info.c +++ b/tools/xl/xl_info.c @@ -144,9 +144,10 @@ out: } #endif -void printf_info(enum output_format output_format, - int domid, - libxl_domain_config *d_config, FILE *fh) +void dump_by_config(enum output_format output_format, + FILE *fh, + const libxl_domain_config *const d_config, + int domid) { if (output_format == OUTPUT_FORMAT_SXP) return printf_info_sexp(domid, d_config, fh); @@ -540,7 +541,10 @@ static void list_domains(bool verbose, bool context, bool claim, bool numa, libxl_physinfo_dispose(&physinfo); } -static void list_domains_details(const libxl_dominfo *info, int nb_domain) +void dump_by_dominfo_list(enum output_format output_format, + FILE *fh, + const libxl_dominfo info[], + int nb_domain) { libxl_domain_config d_config; @@ -556,11 +560,11 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain) #endif #ifdef HAVE_LIBJSONC - if (default_output_format == OUTPUT_FORMAT_JSON) { + if (output_format == OUTPUT_FORMAT_JSON) { jso = json_object_new_array(); } #elif defined(HAVE_LIBYAJL) - if (default_output_format == OUTPUT_FORMAT_JSON) { + if (output_format == OUTPUT_FORMAT_JSON) { hand = libxl_yajl_gen_alloc(NULL); if (!hand) { fprintf(stderr, "unable to allocate JSON generator\n"); @@ -580,7 +584,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain) &d_config, NULL); if (rc) continue; - if (default_output_format == OUTPUT_FORMAT_JSON) { + if (output_format == OUTPUT_FORMAT_JSON) { #ifdef HAVE_LIBJSONC json_object *jso_value; rc = printf_info_one_json(&jso_value, info[i].domid, &d_config); @@ -590,7 +594,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain) s = printf_info_one_json(hand, info[i].domid, &d_config); #endif } else - printf_info_sexp(info[i].domid, &d_config, stdout); + printf_info_sexp(info[i].domid, &d_config, fh); libxl_domain_config_dispose(&d_config); #ifdef HAVE_LIBJSONC if (rc) @@ -601,7 +605,7 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain) #endif } - if (default_output_format == OUTPUT_FORMAT_JSON) { + if (output_format == OUTPUT_FORMAT_JSON) { #ifdef HAVE_LIBJSONC buf = json_object_to_json_string_ext(jso, JSON_C_TO_STRING_PRETTY); if (!buf) @@ -616,11 +620,12 @@ static void list_domains_details(const libxl_dominfo *info, int nb_domain) goto out; #endif - puts(buf); + fputs(buf, fh); + fputc('\n', fh); } out: - if (default_output_format == OUTPUT_FORMAT_JSON) { + if (output_format == OUTPUT_FORMAT_JSON) { #ifdef HAVE_LIBJSONC json_object_put(jso); #elif defined(HAVE_LIBYAJL) @@ -701,7 +706,7 @@ int main_list(int argc, char **argv) } if (details) - list_domains_details(info, nb_domain); + dump_by_dominfo_list(default_output_format, stdout, info, nb_domain); else list_domains(verbose, context, false /* claim */, numa, cpupool, info, nb_domain); diff --git a/tools/xl/xl_misc.c b/tools/xl/xl_misc.c index f0167e1603..bcf178762b 100644 --- a/tools/xl/xl_misc.c +++ b/tools/xl/xl_misc.c @@ -341,7 +341,7 @@ int main_config_update(int argc, char **argv) parse_config_data(filename, config_data, config_len, &d_config); if (debug || dryrun_only) - printf_info(default_output_format, -1, &d_config, stdout); + dump_by_config(default_output_format, stdout, &d_config, -1); if (!dryrun_only) { fprintf(stderr, "setting dom%u configuration\n", domid); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 00:57:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 00:57:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449729.1665364 (Exim 4.92) (envelope-from ) id 1xH9mK-0006sg-6n; Thu, 15 Oct 2026 00:57:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449729.1665364; Thu, 15 Oct 2026 00: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 1xH9mK-0006sZ-2x; Thu, 15 Oct 2026 00:57:04 +0000 Received: by outflank-mailman (input) for mailman id 1449729; Thu, 15 Oct 2026 00:57:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xH9mI-0006rS-Fg for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 00:57:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xH9mH-000f30-T4 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 02:57:01 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad024ba-2eae-0a2a0a5409dd-0a2a45069a8a-16 for ; Thu, 15 Oct 2026 02:57:01 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad023ec-195a-0a2a45060019-4a68bc04542d-3 for ; Thu, 15 Oct 2026 02:53:01 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69F0qrGs092119 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 14 Oct 2026 20:52:59 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69F0qrJX092118; Wed, 14 Oct 2026 17:52:53 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <5907d797c6ba6eda80058d52bfdad9eb7ee4e441.1792017109.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Wed, 14 Oct 2026 15:31:49 -0700 Subject: [PATCH 5/5] tools/xl: Merge down debug/dry-run section of create_domain() X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-16d1c6/1792025581-FC80577B-95CC9C0A/0/0 X-purgate-type: clean X-purgate-size: 1387 Date: Thu, 17 Dec 2020 17:42:42 -0800 create_domain()'s use of printf_info_sexp() could be merged down to a single dump_by_config(), do so. This results in an extra JSON dictionary in output, but I doubt that is an issue for dry-run or debugging output. Signed-off-by: Elliott Mitchell --- tools/xl/xl_vmcontrol.c | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c index 93766f631b..bfd87e6aef 100644 --- a/tools/xl/xl_vmcontrol.c +++ b/tools/xl/xl_vmcontrol.c @@ -899,19 +899,7 @@ int create_domain(struct domain_create *dom_info) if (debug || dryrun_only) { FILE *cfg_print_fh = (debug && !dryrun_only) ? stderr : stdout; - if (default_output_format == OUTPUT_FORMAT_SXP) { - printf_info_sexp(-1, &d_config, cfg_print_fh); - } else { - char *json = libxl_domain_config_to_json(ctx, &d_config); - if (!json) { - fprintf(stderr, - "Failed to convert domain configuration to JSON\n"); - exit(1); - } - fputs(json, cfg_print_fh); - free(json); - flush_stream(cfg_print_fh); - } + dump_by_config(default_output_format, cfg_print_fh, &d_config, -1); } -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 01:25:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 01:25:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449777.1665373 (Exim 4.92) (envelope-from ) id 1xHADj-0005HQ-BK; Thu, 15 Oct 2026 01:25:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449777.1665373; Thu, 15 Oct 2026 01:25: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 1xHADj-0005HI-66; Thu, 15 Oct 2026 01:25:23 +0000 Received: by outflank-mailman (input) for mailman id 1449777; Thu, 15 Oct 2026 01:25:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHADh-0005HC-3Q for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 01:25:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHADg-006AoR-DI for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 03:25:20 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad02b23-2eae-0a2a0a5409dd-0a2a45048f8e-44 for ; Thu, 15 Oct 2026 03:25:19 +0200 Received: from [52.101.229.73] (helo=TY3P286CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad02b7c-b57f-0a2a45040019-3465e54904be-3 for ; Thu, 15 Oct 2026 03:25:18 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by OSCP286MB4572.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:325::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 01:25:14 +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.0522.012; Thu, 15 Oct 2026 01:25: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=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=j5Hcp7Nb2JRvB8ydLUdDt52I7VWAlKGlKVJAz1KeBBU7o56thKsXvhWOPLo8LbTVtt4O+tWjx8OaCi2jM1KUX3jjMRoYMQqIb6wlhkBsnK1ZfauHHZYfoFiXJw+30gy+NmWKbuJlaCScgOBpA+sWjQg9AkuJu/uGinz7EKRf43GfKajovMrsa+IrmSyoPuT5od7cpqMar7Ho0IdH2hCIo7t/UdW5QjJ9uV0ZColA4vnVPUIIwpgAAe0cApNnmQlx7Duxe+diI9N8Y1s1nW3Wi3oQKqxu2ySNHEHQuGXTvPaJJkIUc6hNzGUJ3620cjruy8WUhSoFgWWA8pwPLJ3w0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=abFzb1SzuGcSHh3a/H/YTeiolw1uiygo8nLnU8Pc5Ns=; b=EnSVRldm+GTs+SXqdZ/5hdc5GcE666cOgtjoP0V0JR/36G3oEbw9O0xEDxK9MJZjyhN3BcCLR3Ujo+4nG+onRwy2tY6uGRw1EpHNB5pXmAgYgzxBkJWGy2uEcwLRpyJWjz8FR/7oojtY4IgRhbsPb7VWjYg5pz1GUCcBdzCq9Y3GU09km2Tm+2hAFNDBkgr16MPuthPj/Hs6nitGFY+wKURFwMKHzafL46OYwde2KggoNO+w1UwwCYdNEszxND4muitYOQ4tO9eSWyJkOXfKJSrMEKmwpFT75eWkLAGWRM9bb4hc5oi1kTKCfDFQrq6XDL+vB6Zi6S3R88Wu4tkHsQ== 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=abFzb1SzuGcSHh3a/H/YTeiolw1uiygo8nLnU8Pc5Ns=; b=ZK4C8ijq10bLtMHuzYXNn8JyZQ3SQbVfgqkGz9EWT0YlXOiF1CNRA4iLkJR/m/c/4Elh423DNiPYwgAx7kh2P8ptWZrBS11uQQ0zyWpaePw9tLEZ0clal0IlF7GFrkpv+7ABsVtUCI5k9lyFR43Kx0XQjdsg7U4GFHL2Gc+Jhhw= 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 v11 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Topic: [PATCH v11 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Index: AQHdWv7FBR3TH740A0acT806Ikcnyrb9B02AgADESSA= Date: Thu, 15 Oct 2026 01:25:13 +0000 Message-ID: References: <20261013103616.121916-1-taka@valinux.co.jp> <20261013103616.121916-2-taka@valinux.co.jp> <0d892635-2284-40bf-8b0b-3c067d49d465@amd.com> In-Reply-To: <0d892635-2284-40bf-8b0b-3c067d49d465@amd.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP 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=valinux.co.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OS9P286MB7222:EE_|OSCP286MB4572:EE_ x-ms-office365-filtering-correlation-id: 93314076-ae8b-410a-ac1b-08df2a5b29bd x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|23010399003|366016|38070700021|56012099006|4143699003|261009223027099003|10067099003|22082099003|18002099003|6133799003|260925021911599003|260925022911599003|260925021311599003; x-microsoft-antispam-message-info: vEiXhddAiGowYA50gc3/O3CJlTy7yHHUIdn0yX7Vp/WJzwbriCgEPFdLdQv978g6of86hKPF8o8ywnZ3/6KF/HT+20EcCJO+dKOHKMRgqXV/Aby9EmCYSaYOftPnKxz6rmJcqBAP2+bjFZneNwNYI23FTd8DLye4iVlmUhcDOmE4/QOeKrvQPd87fVhbSTj9QaPtLYsfwhxUdgjN3qxzLEF0es4skymDafLK+bEqxQe4co73Ensx6rFi/71R50pohub3wLD6t+IZdDsdNRSjIeoX1R3V9884xLu1C3qK2JY2LV+5XNbSlO133FU2SEsr3mWO3m1hC5ISM27c71q/BGLspx7v2lpvBQ3o9B7ivqKGcBDH2Ivk11Lb5etfriRfEkAWkqctKou7nOaatozZAi9Mx0j7SeL52yqK1TpExEbSBVmrc0SGdEJIZzYLHtKs7FUMIBVR1OSBj/lXT2RW2OH0uQlHsiBzw6qvm0F8w1l1VyI3gIxsbScMVcA49q5uFTivU4YmF5XrD7BDBldn6DWk33p4zr9GqnyjYidCNiTuZVBf6DczYZdcKO8+gJ5bzLGgm8AHjHbi19LtY/I0nTL3o1RuYOvLj83Iw8xEJEAYJ2fS6zyj8ytrKZblqqjk/0gZJCr+tsuSKwIrzrNqdWI8YL40NwYjVzkz+tmTml8kpegIv7TwUaq8teeLTDjP1lf9VSsKFZsOGsrP1wtDjgWhB2tlqEQhbLnl4OjjCyI= 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)(23010399003)(366016)(38070700021)(56012099006)(4143699003)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003)(260925021911599003)(260925022911599003)(260925021311599003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?V3JoWCtEZkR3ekZCaFAvelFFOERsV3huUi9YK1BTWVRYVHBURXpxT2FWeS82?= =?utf-8?B?OFBDTjFOckRSOEdlbTVYQ0VRK1ZRL00zRDlpNkpuRVRyL0RRS2UzdVRvUTEw?= =?utf-8?B?aXY4UkVnamZzWHQrQVNRRlh3VkFnVElSNGN1c0UvTW5KUDhmaE9YdzMxcXlj?= =?utf-8?B?VklTdEdlMzBxMHdvZzU0TWJ0MWU0U00weGZVeklyR05pMDFXcTNzNk1hbWtI?= =?utf-8?B?Qm1hZlFFeXI3WjNXdWc2Zk56OThlR29kZmNEZWNYbFlRSFJWYXBDUms1N1kw?= =?utf-8?B?allhcmVpcUZTQ0tWMllZQlZEamc1eWxxTzZ5QjIxejV6K1Y0TG50M3dCZzZt?= =?utf-8?B?Vk82NzdkTkFPVm9uR0U1Mjdxd05RblNEc2hpS0tCTExqQURGZXRiWkI3Qmh5?= =?utf-8?B?VzlGSUROMDVmZ0cxdEt4VUliaUpKWUNPUEh6UXc1R0t3RUlwaXY2TldHaHI4?= =?utf-8?B?dURSM2RPS3pxSHhIbHNVMFI0eGRuL1M0b1pFZFFhL0xIYTdISzJ5bldpVVB4?= =?utf-8?B?U1dhSVZOWnBCbUcxUzFFYTFuNDJYeTVKVFl6WkdyU0FCdVc3dS9ueEhvaTdw?= =?utf-8?B?b3ZKbk93TXRweXFOdlp1RHZ1c1FTanRGZmY5VlY2b2d4OVBsdVlaVDVRcWRP?= =?utf-8?B?ck9ZamFOMFpkSmFaRWQvMDNQYWlHbnZTM0pSNG11M2xINnpXR1B4VjQwTDV1?= =?utf-8?B?MDRuSlh4Vnl6alZ4Z0Z2ZzFOYWVGWHFoYUxYYXQ5dkJyYWY0SnBxbGhaMVRp?= =?utf-8?B?OG0zM1dVQWNZaEpIYVI0YW1GWm0zSXNMMHBJU212Qlo5Y2ttRlhGTlArQzhp?= =?utf-8?B?QWlLZnpBcTRQME9nT3hZZVQ5ZDV5S2pIRGV5VnZ4YXZXcWliQVFTSXpGY1NB?= =?utf-8?B?YllrejlRRDNaZGExaXI2UUpqaTJvbmZDRVRXM3k0clRQUlFrTTdvckZyaXZx?= =?utf-8?B?bDR6ZVl3ZDFxR2VUMmdwZ1ZmMG1DRkJvMldxSHV3U0VoTXJRdzFZMFlVWXY0?= =?utf-8?B?U0Qvbkw2Q2VSOHZSK1JvNjlyWUtoT2J5QjFjR2o5azc1UElPc0o1UzVPd2RL?= =?utf-8?B?ZVJ0R0RtZjc4UHJxWG9TT2NhT0hSR2s2cXdtQ2FRMmQyYzNNRDNRYTBIUHRO?= =?utf-8?B?SnExVDBySjdISm1hZlpFME1ybXN1ZnFnS0k4d3FKeVZSeW4raUVBRFZXRExi?= =?utf-8?B?aEdjZERxTmxjaVZlY0d1Yjl2R3JSdjlaaUVvTTFrUllEdHBQaVhCMHpmTzVZ?= =?utf-8?B?eWE2cXJ0VUpUM1U3eGFleG5lY09GblU5UU13TVdGdDhFU2ZsYWFnSzdlSWhV?= =?utf-8?B?ZWZQS3NEQVB1MjNNdVAxVmlLcHJBd0tSSXRaaXpEOUFKZUM3N1c1cVVuMXpP?= =?utf-8?B?aEFZbmNCOVVlMkw4K0NJTmhTVk9BY2c3bnV5WG0ySGFNWXZ5R0lBaDVwTFpI?= =?utf-8?B?Z25jWTdPVDhQL2NLVWFhVTBaLzMwN1hGd0pKZ29BZlJsR2dIYXBmSi94bTBO?= =?utf-8?B?bXFWR0E1MXVzZGZmM1JQNU5HS1p4M0VBSS8zN3dybDJjZ3R3N0ZuZFc0bzQr?= =?utf-8?B?SjhrYWgyMzJCRUQvYU1VRnhxOHdPYS9rNGhNS05HY1A3c05YR1M1ZGlwQkds?= =?utf-8?B?aXJWeEVLcGJUL3JLYkUwQ3ZZWkdKWVJGcXdZM3dkMEpZL3RFV2xCMVVtSCs3?= =?utf-8?B?d1JBUGxkZnBoU0ZQMk44WFFsK09OazZxbDdDN29pRzlLekpJRm0rY3NFMVFE?= =?utf-8?B?WjlyWUlnRGp1Z0U5bHdqa2pmNFFMNUFsVml6SjlRSU9NbkZvVG9TVFgzWkIw?= =?utf-8?B?LzVKTkpaUmRlV3RYUnlsY1ZIUGRVL3NZRjdPejQ0TVhQdExIM0VRZmROaGNy?= =?utf-8?B?QW0xcnEra3dLSmJGV1kzZEMvblRYVXZVdWVLZmtXUExJL1RCQm9WVytFWGdZ?= =?utf-8?B?RFdNc2NTaVdqV2VmRlBzcHlUV3lUcVN6QjcvSzhXSnBIZUNsdUh4VTZzaGNa?= =?utf-8?B?K2t6VkVNL0c1VUxmUWtHNG9ha2dKSDhzQytodlRGZWxnamtsNnJmQU9KQjFx?= =?utf-8?B?K0lxVWsxMnJDUWRkdFVMbTV0QzdJT2NiZzlrNFZlUm1uRWhxdlZOTTExbHhH?= =?utf-8?B?cWxuODdTcVpBMWVEeXFmWkVSOWFoak1QZk5ZaFhwc0hOZEMzdXpEenN6YTgz?= =?utf-8?B?YW1HS0o0eFRpRFBSZUlQeFQ1djBUVmVKTnE0dzIvWnJ2c0haUzZzUW85MlZD?= =?utf-8?B?TmZRaVF1R0JYUVFZT0pLVHFNQkpxZTlsVDNwdjZMTjd3N2wzeTRsVHZ1cXF5?= =?utf-8?Q?oBMFD4S69nSQLefuL5?= 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: 93314076-ae8b-410a-ac1b-08df2a5b29bd X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2026 01:25:14.0085 (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: ArmDIrdyGbe3cL1cGWXsf9WoYsQxdz1lLVozdy76OrfhVK+LyICylMvZUCup9xLc1ZKKjZkf1uOZ7L8gG68TIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSCP286MB4572 X-purgate-ID: tlsNG-ebf023/1792027519-583C0B50-83D5CB0C/0/0 X-purgate-type: clean X-purgate-size: 7432 SGkgTWljaGFsLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNCj4gPiBAQCAtMjQ1LDYg KzI0NywxMCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgZHRfc21wX2luaXRfY3B1cyh2b2lkKQ0KPiA+ ICAgICAgICAgIH0NCj4gPiAgICAgICAgICBlbHNlDQo+ID4gICAgICAgICAgICAgIHRtcF9tYXBb aV0gPSBod2lkOw0KPiA+ICsNCj4gPiArICAgICAgICBpZiAoIChyYyA+PSAwKSB8fCAoaSA9PSAw KSApDQo+IFBsZWFzZSBhZGQgYSBjb21tZW50IGV4cGxhaW5pbmcgdGhlIHNlY29uZCBwYXJ0IGku ZS4gYm9vdCBDUFUgbWF5IGxhY2sgZW5hYmxlDQo+IG1ldGhvZC4NCg0KT2theS4gSSB3aWxsIGFk ZCBhIGNvbW1lbnQuDQoNCj4gPiArICAgICAgICAgICAgLyogUGFzcyB0aGUgaW5mbyB0byBkdF9p bml0X2NwdV90b3BvbG9neSgpICovDQo+ID4gKyAgICAgICAgICAgIG1hcF9jcHVfdG9fZHRfbm9k ZShpLCBjcHUpOw0KPiA+ICAgICAgfQ0KDQoNCj4gPiBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9N YWtlZmlsZSBiL3hlbi9jb21tb24vTWFrZWZpbGUNCj4gPiBpbmRleCBmNjlkNDdkMTg5Li5kMGVi MzlhNjMzIDEwMDY0NA0KPiA+IC0tLSBhL3hlbi9jb21tb24vTWFrZWZpbGUNCj4gPiArKysgYi94 ZW4vY29tbW9uL01ha2VmaWxlDQo+ID4gQEAgLTUsNiArNSw3IEBAIG9iai0kKENPTkZJR19HRU5F UklDX0JVR19GUkFNRSkgKz0gYnVnLm8NCj4gPiAgb2JqLSQoQ09ORklHX0hZUEZTX0NPTkZJRykg Kz0gY29uZmlnX2RhdGEubw0KPiA+ICBvYmotJChDT05GSUdfQ09SRV9QQVJLSU5HKSArPSBjb3Jl X3Bhcmtpbmcubw0KPiA+ICBvYmoteSArPSBjcHUubw0KPiA+ICtvYmotJChDT05GSUdfR0VORVJJ Q19DUFVfVE9QT0xPR1kpICs9IGNwdS10b3BvbG9neS5pbml0Lm8NCj4gPiAgb2JqLSQoQ09ORklH X0RFQlVHX1RSQUNFKSArPSBkZWJ1Z3RyYWNlLm8NCj4gPiAgb2JqLSQoQ09ORklHX0hBU19ERVZJ Q0VfVFJFRV9ESVNDT1ZFUlkpICs9IGRldmljZS5vDQo+ID4gIG9iai0kKGZpbHRlci1vdXQgJChD T05GSUdfWDg2KSwkKENPTkZJR19BQ1BJKSkgKz0gZGV2aWNlLm8NCj4gPiBkaWZmIC0tZ2l0IGEv eGVuL2NvbW1vbi9jcHUtdG9wb2xvZ3kuYyBiL3hlbi9jb21tb24vY3B1LXRvcG9sb2d5LmMNCj4g PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPiA+IGluZGV4IDAwMDAwMDAwMDAuLmNlNTA0MDg4NTgN Cj4gPiAtLS0gL2Rldi9udWxsDQo+ID4gKysrIGIveGVuL2NvbW1vbi9jcHUtdG9wb2xvZ3kuYw0K PiA+IEBAIC0wLDAgKzEsNjkgQEANCj4gPiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQ TC0yLjAtb25seSAqLw0KPiA+ICsNCj4gPiArI2luY2x1ZGUgPHhlbi9hY3BpLmg+DQo+ID4gKyNp bmNsdWRlIDx4ZW4vY3B1LXRvcG9sb2d5Lmg+DQo+ID4gKyNpbmNsdWRlIDx4ZW4vY3B1bWFzay5o Pg0KPiA+ICsjaW5jbHVkZSA8eGVuL2R0LWNwdS10b3BvbG9neS5oPg0KPiA+ICsjaW5jbHVkZSA8 eGVuL2luaXQuaD4NCj4gPiArI2luY2x1ZGUgPHhlbi94dm1hbGxvYy5oPg0KPiA+ICsNCj4gPiAr c3RhdGljIHZvaWQgX19pbml0IGZyZWVfdG9wb2xvZ3lfdGFibGUodm9pZCkNCj4gPiArew0KPiA+ ICsgICAgdW5zaWduZWQgaW50IGNwdTsNCj4gPiArDQo+ID4gKyAgICBmb3IgKCBjcHUgPSAwOyBj cHUgPCBucl9jcHVfaWRzOyBjcHUrKyApDQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgZnJlZV9j cHVtYXNrX3ZhcihjcHVfdG9wb2xvZ3lbY3B1XS50aHJlYWRfc2libGluZyk7DQo+ID4gKyAgICAg ICAgZnJlZV9jcHVtYXNrX3ZhcihjcHVfdG9wb2xvZ3lbY3B1XS5jb3JlX3NpYmxpbmcpOw0KPiA+ ICsgICAgICAgIGZyZWVfY3B1bWFza192YXIoY3B1X3RvcG9sb2d5W2NwdV0uY2x1c3Rlcl9zaWJs aW5nKTsNCj4gPiArICAgIH0NCj4gPiArDQo+ID4gKyAgICBYVkZSRUUoY3B1X3RvcG9sb2d5KTsN Cj4gPiArfQ0KPiA+ICsNCj4gPiArdm9pZCBfX2luaXQgaW5pdF9jcHVfdG9wb2xvZ3kodm9pZCkN Cj4gPiArew0KPiA+ICsgICAgdW5zaWduZWQgaW50IGNwdTsNCj4gPiArICAgIGludCByZXQ7DQo+ ID4gKw0KPiA+ICsgICAgaWYgKCBudW1fcG9zc2libGVfY3B1cygpID09IDEgKQ0KPiA+ICsgICAg ICAgIHJldHVybjsNCj4gPiArDQo+ID4gKyAgICBjcHVfdG9wb2xvZ3kgPSB4dnphbGxvY19hcnJh eShzdHJ1Y3QgY3B1X3RvcG9sb2d5LCBucl9jcHVfaWRzKTsNCj4gPiArICAgIGlmICggIWNwdV90 b3BvbG9neSApDQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5H ICJDUFUgdG9wb2xvZ3kgdGFibGUgYWxsb2NhdGlvbiBmYWlsZWQuXG4iKTsNCj4gPiArICAgICAg ICByZXR1cm47DQo+ID4gKyAgICB9DQo+ID4gKw0KPiA+ICsgICAgZm9yICggY3B1ID0gMDsgY3B1 IDwgbnJfY3B1X2lkczsgY3B1KysgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGlmICggIXph bGxvY19jcHVtYXNrX3ZhcigmY3B1X3RvcG9sb2d5W2NwdV0udGhyZWFkX3NpYmxpbmcpIHx8DQo+ ID4gKyAgICAgICAgICAgICAhemFsbG9jX2NwdW1hc2tfdmFyKCZjcHVfdG9wb2xvZ3lbY3B1XS5j b3JlX3NpYmxpbmcpIHx8DQo+ID4gKyAgICAgICAgICAgICAhemFsbG9jX2NwdW1hc2tfdmFyKCZj cHVfdG9wb2xvZ3lbY3B1XS5jbHVzdGVyX3NpYmxpbmcpICkNCj4gPiArICAgICAgICB7DQo+ID4g KyAgICAgICAgICAgIGZyZWVfdG9wb2xvZ3lfdGFibGUoKTsNCj4gPiArICAgICAgICAgICAgcHJp bnRrKFhFTkxPR19XQVJOSU5HICJDUFUgdG9wb2xvZ3kgdGFibGUgYWxsb2NhdGlvbiBmYWlsZWQu XG4iKTsNCj4gPiArICAgICAgICAgICAgcmV0dXJuOw0KPiA+ICsgICAgICAgIH0NCj4gPiArICAg IH0NCj4gPiArDQo+ID4gKyAgICBpZiAoIGFjcGlfZGlzYWJsZWQgKQ0KPiA+ICsgICAgICAgIHJl dCA9IGR0X2luaXRfY3B1X3RvcG9sb2d5KCk7DQo+ID4gKyAgICBlbHNlDQo+ID4gKyAgICAgICAg cmV0ID0gYWNwaV9pbml0X2NwdV90b3BvbG9neSgpOw0KPiA+ICsNCj4gPiArICAgIC8qIEZyZWUg dGhlIENQVSB0b3BvbG9neSB0YWJsZSBpZiBpbml0aWFsaXphdGlvbiBmYWlscy4gKi8NCj4gPiAr ICAgIGlmICggcmV0ICE9IDAgKQ0KPiA+ICsgICAgICAgIGZyZWVfdG9wb2xvZ3lfdGFibGUoKTsN Cj4gSW4gYSBwcmV2aW91cyByZXZpc2lvbiBJIGFza2VkIHRvIHByaW50IGFuIGVycm9yIChleGNl cHQgZm9yIGV4cGVjdGVkIGVycm9ycw0KPiBsaWtlIC1FT1BOT1RTVVBQKS4NCg0KTXkgaW50ZW50 aW9uIGlzIHRvIGF2b2lkIGR1cGxpY2F0ZSBtZXNzYWdlcyBiZWNhdXNlIGR0X2luaXRfY3B1X3Rv cG9sb2d5KCkgYW5kDQphY3BpX2luaXRfY3B1X3RvcG9sb2d5KCkgYWxyZWFkeSBlbWl0IGRldGFp bGVkIGVycm9yIGxvZ3MgdXBvbiBmYWlsdXJlLg0KDQo+ID4gK3N0YXRpYyBpbnQgX19pbml0IHBh cnNlX2NvcmUoY29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpjb3JlLA0KPiA+ICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBzb2NrZXRfaWQsDQo+ID4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IGNsdXN0ZXJfaWQsDQo+ID4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IGNvcmVfaWQpDQo+ID4gK3sN Cj4gPiArICAgIGJvb2wgbGVhZiA9IHRydWU7DQo+ID4gKyAgICB1bnNpZ25lZCBpbnQgdGhyZWFk X2lkOw0KPiA+ICsgICAgdW5zaWduZWQgaW50IGNwdTsNCj4gPiArDQo+ID4gKyAgICBmb3IgKCB0 aHJlYWRfaWQgPSAwOyA7IHRocmVhZF9pZCsrICkNCj4gPiArICAgIHsNCj4gPiArICAgICAgICBj b25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnRocmVhZDsNCj4gPiArICAgICAgICBjaGFyIG5h bWVbMjBdOw0KPiA+ICsNCj4gPiArICAgICAgICBzbnByaW50ZihuYW1lLCBzaXplb2YobmFtZSks ICJ0aHJlYWQldSIsIHRocmVhZF9pZCk7DQo+ID4gKyAgICAgICAgdGhyZWFkID0gZHRfZmluZF9j aGlsZF9ub2RlX2J5X25hbWUoY29yZSwgbmFtZSk7DQo+ID4gKw0KPiA+ICsgICAgICAgIGlmICgg IXRocmVhZCApDQo+ID4gKyAgICAgICAgICAgIGJyZWFrOw0KPiA+ICsNCj4gPiArICAgICAgICBs ZWFmID0gZmFsc2U7DQo+ID4gKyAgICAgICAgY3B1ID0gZ2V0X2NwdV9mb3Jfbm9kZSh0aHJlYWQp Ow0KPiA+ICsNCj4gPiArICAgICAgICBpZiAoIGNwdSA9PSBJTlZBTElEX1RPUE9fSUQgKQ0KPiBn ZXRfY3B1X2Zvcl9ub2RlIGNhbiByZXR1cm4gSU5WQUxJRF9UT1BPX0lEIGFsc28gb24gbWFsZm9y bWVkIERUcyBlLmcuIG1pc3NpbmcNCj4gcGhhbmRsZSB3aGljaCB5b3Ugbm93IGFjY2VwdC4gU2hv dWxkbid0IHdlIHJldHVybiAtRUlOVkFMPw0KDQpPa2F5LiANCg0KPiA+ICsgICAgICAgIHsNCj4g PiArICAgICAgICAgICAgLyoNCj4gPiArICAgICAgICAgICAgICogSWdub3JlIHRoaXMgQ1BVIG5v ZGUgZGVmaW5pdGlvbiBhcyB0aGUgY29ycmVzcG9uZGluZyBwaHlzaWNhbA0KPiA+ICsgICAgICAg ICAgICAgKiBDUFUgZmFpbGVkIHRvIGJvb3QuDQo+ID4gKyAgICAgICAgICAgICAqLw0KPiA+ICsg ICAgICAgICAgICBwcmludGsoWEVOTE9HX0lORk8NCj4gPiArICAgICAgICAgICAgICAgICAgICIl czogQ1BVIGZvciB0aHJlYWQgaGFzbid0IHN0YXJ0ZWRcbiIsIGR0X25vZGVfbmFtZSh0aHJlYWQp KTsNCj4gQ1BVIHRvcG9sb2d5IGlzIGluaXRpYWxpemVkIGJlZm9yZSBicmluZ2luZyBDUFUgdXAs IHNvIHRoaXMgbWVzc2FnZSBpcyBpbmNvcnJlY3QNCj4gYW5kIHRoZXJlIGFyZSBtb3JlIHRoYW4g b25lIHNjZW5hcmlvcyB3ZSBtYXkgZW5kIHVwIHdpdGggaGVyZS4gTWF5YmUganVzdCAiQ1BVDQo+ IG5vdCB1c2VkIGJ5IFhlbjogaWdub3JpbmciLg0KDQpZb3UgYXJlIHJpZ2h0LiANCg0KPiA+ICsg ICAgICAgICAgICByZXR1cm4gMDsNCj4gVGhpcyBzdG9wcyBwYXJzaW5nIG90aGVyIHRocmVhZHMg d2hpY2ggSSBkb24ndCB0aGluayBpcyB0aGUgcmlnaHQgd2F5IHRvIGRvIGl0Lg0KPiBXZSBzaG91 bGQganVzdCBjb250aW51ZS4NCg0KWW91IGFyZSByaWdodC4NCg0KPiA+ICsgICAgZWxzZSBpZiAo IGxlYWYgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIC8qDQo+ID4gKyAgICAgICAgICogSWdu b3JlIHRoaXMgQ1BVIG5vZGUgZGVmaW5pdGlvbiBhcyB0aGUgY29ycmVzcG9uZGluZyBwaHlzaWNh bA0KPiA+ICsgICAgICAgICAqIENQVSBmYWlsZWQgdG8gYm9vdC4NCj4gPiArICAgICAgICAgKi8N Cj4gPiArICAgICAgICBwcmludGsoWEVOTE9HX0lORk8NCj4gPiArICAgICAgICAgICAgICAgIiVz OiBDUFUgZm9yIGxlYWYgY29yZSBoYXNuJ3Qgc3RhcnRlZFxuIiwNCj4gZHRfbm9kZV9uYW1lKGNv cmUpKTsNCj4gU2FtZSB3b3JkaW5nIGlzc3VlLg0KDQpPa2F5Lg0KDQpUaGFua3MsDQpIaXJva2F6 dSBUYWthaGFzaGkuDQo= From xen-devel-bounces@lists.xenproject.org Thu Oct 15 03:22:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 03:22:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449800.1665383 (Exim 4.92) (envelope-from ) id 1xHC34-0006Sr-7a; Thu, 15 Oct 2026 03:22:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449800.1665383; Thu, 15 Oct 2026 03:22: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 1xHC34-0006Sg-1B; Thu, 15 Oct 2026 03:22:30 +0000 Received: by outflank-mailman (input) for mailman id 1449800; Thu, 15 Oct 2026 03:22:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHC32-0006Sa-2h for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 03:22:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHC30-00FBFv-Sh for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 05:22:26 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0469c-8faa-0a2a0a5109dd-0a2a4502907a-32 for ; Thu, 15 Oct 2026 05:22:24 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad046ed-6ca4-0a2a45020019-9fe2fb15c156-3 for ; Thu, 15 Oct 2026 05:22:24 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowABnOu7nRtBqrYPoCg--.185S2; Thu, 15 Oct 2026 11:22:16 +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, 15 Oct 2026 11:22:34 +0800 From: Zhang Zheng To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <1791670290.8631fc262581453bbf619ec5b2062170.1a127df076400080d7@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1791670290.8631fc262581453bbf619ec5b2062170.1a127df076400080d7@vates.tech> X-CM-TRANSID:qwCowABnOu7nRtBqrYPoCg--.185S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCryxWr4fWr4fXF4ftFyrZwb_yoW5Xw1Upr W8KF9Yyrs7tr18C3s0q3W2qFsIgFn3Za4akrWfGa9xZr4DJr40kFyUXFW3Gr4Duw18JF18 uFWDArykGFZ8ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvlb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACI402YVCY1x02628vn2kIc2xK xwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJV W8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF 1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6x IIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvE x4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvj DU0xZFpf9x07b8kskUUUUU= X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-720697/1792034544-66AB52AC-637016BA/0/0 X-purgate-type: clean X-purgate-size: 3250 On Sun, Oct 11, 2026 at 12:11:27AM +0200, Baptiste Le Duc wrote: > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > > index 593d208483..953d166314 100644 > > --- a/xen/drivers/char/ns16550.c > > +++ b/xen/drivers/char/ns16550.c > > @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > > /* No interrupts. */ > > ns_write_reg(uart, UART_IER, 0); > Do we know of a UART where UUE reads back as 1 whatever is written? I > could not find any such hardware, so I am not sure the check is needed > but it might be wrong. If not, then we could drop this write but if so, > then I propose to move it in a dedicated function: > > ``` > static bool ns_is_xscale(const struct ns16550 *uart) > { > /* > * We're going to explicitly set the UUE bit to 0 before > * trying to write and read a 1 just to make sure it's not > * already a 1 and maybe locked there before we even start. > */ > ns_write_reg(uart, UART_IER, 0); > > if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) { > /* Now we are in a 0 state */ > ns_write_reg(uart, UART_IER, UART_IER_UUE); > if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > return true; > } > return false; > } > ``` I agree with Oleksii's suggestion that the XScale quirk should be derived from the Device Tree compatible for DT-described UARTs. Therefore, I think will drop this register probe then. > > + uart->xscale = false; > > + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > > > > + { > > + ns_write_reg(uart, UART_IER, UART_IER_UUE); > > + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > > + uart->xscale = true; > > + } > > + > > /* Handle the DesignWare 8250 'busy-detect' quirk. */ > > handle_dw_usr_busy_quirk(uart); > > > > @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) > > UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); > > > > /* Enable receive interrupts. */ > > - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); > > + ns_write_reg(uart, UART_IER, > > + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); > > > Every IER write has to keep UUE on an XScale UART, otherwise the UART is > switched off. Open-coding the ternary at each call site makes it easy > for a future caller to forget. Would it be better to add a helper, e.g.: > > static void ns_write_ier(const struct ns16550 *uart, unsigned int val) > { > ns_write_reg(uart, UART_IER, > uart->xscale ? val | UART_IER_UUE : val); > } > > and use it for all futures IER writes? > > Thanks for contributing! > > -- > Baptiste Le Duc Agreed. I will add an `ns_write_ier()` helper and use it for all IER write paths, including `ns16550_setup_preirq()`, `ns16550_setup_postirq()`, and `ns16550_interrupt()`. Thanks for pointing this out. Zhang From xen-devel-bounces@lists.xenproject.org Thu Oct 15 03:43:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 03:43:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449826.1665391 (Exim 4.92) (envelope-from ) id 1xHCNl-0003Ud-ND; Thu, 15 Oct 2026 03:43:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449826.1665391; Thu, 15 Oct 2026 03: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 1xHCNl-0003UW-KO; Thu, 15 Oct 2026 03:43:53 +0000 Received: by outflank-mailman (input) for mailman id 1449826; Thu, 15 Oct 2026 03:43:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHCNk-0003UQ-Fj for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 03:43:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHCNj-006O3p-7o for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 05:43:51 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad04b6d-2eae-0a2a0a5409dd-0a2a450ba33e-26 for ; Thu, 15 Oct 2026 05:43:50 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad04bf3-b7e8-0a2a450b0019-9fe2fb15a0e0-3 for ; Thu, 15 Oct 2026 05:43:50 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowAB3TvLuS9Bq1uDoCg--.1414S2; Thu, 15 Oct 2026 11:43:43 +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, 15 Oct 2026 11:44:00 +0800 From: Zhang Zheng To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <1a6cdfbf-8116-48ca-b2cb-567e39fabe4f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a6cdfbf-8116-48ca-b2cb-567e39fabe4f@gmail.com> X-CM-TRANSID:qwCowAB3TvLuS9Bq1uDoCg--.1414S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCFWDWr13Zr43AF15Jr17Awb_yoWruF4DpF W8KFnYyFZrtr10k3sIq3WUuFW0gan7Xa4akr4fG3y7Zr1ktr18uFyjqFy3J3Wvvr4ktF4j 9F4jvryUJ398ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvlb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACI402YVCY1x02628vn2kIc2xK xwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJV W8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF 1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6x IIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvE x4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvj DU0xZFpf9x07b8kskUUUUU= X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-42698a/1792035830-ABCD79EA-3DC71FCC/0/0 X-purgate-type: clean X-purgate-size: 4896 On Mon, Oct 12, 2026 at 11:20:22AM +0200, Oleksii Kurochko wrote: > > > On 10/10/26 5:14 AM, Zhang Zheng wrote: > > XScale-compatible UARTs require UART_IER_UUE to remain set. Probe the > > bit during setup and preserve it when enabling receive interrupts, so > > the xscale/PXA UART remains operational after ns16550 takes over. > > > > Signed-off-by: Zhang Zheng > > --- > > xen/drivers/char/ns16550.c | 12 +++++++++++- > > xen/include/xen/8250-uart.h | 1 + > > 2 files changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > > index cdda28879e..c174465059 100644 > > --- a/xen/drivers/char/ns16550.c > > +++ b/xen/drivers/char/ns16550.c > > @@ -64,6 +64,7 @@ static struct ns16550 { > > bool intr_works; > > bool force_polling; > > bool dw_usr_bsy; > > + bool xscale; > > #ifdef NS16550_PCI > > /* PCI card parameters. */ > > bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > > @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > > /* No interrupts. */ > > ns_write_reg(uart, UART_IER, 0); > > + uart->xscale = false; > > + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > > + { > > + ns_write_reg(uart, UART_IER, UART_IER_UUE); > > + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > > + uart->xscale = true; > > + } > > + > > This probe only checks whether IER bit 6 is writable, which isn't > specific to XScale. On UARTs with an EFR (e.g. ST16C650, TI TL16C752, > Exar XR17V35x) the upper IER bits become writable once EFR[4] (ECB) is > set, and bit 6 is then the RTS interrupt enable. If ECB is already set > when the probe runs, it would report XScale, and the driver would then > keep the RTS interrupt enabled. > > Could the flag be derived from the compatible in ns16550_uart_dt_init() > instead, the same way dw_usr_bsy is? > > uart->xscale = dt_device_is_compatible(dev, "intel,xscale-uart"); > > That compatible would also need adding to ns16550_dt_match[]. The > SpacemiT K1 nodes, for example, have no "ns16550a" fallback. > This UEE probe section was adapted from Linux's 8250.c `autoconfig_16550a()`. Nevertheless, I think using the Device Tree compatible is a reasonable solution, given your point that this bit may also be writable on other UARTs and could therefore result in false positives. > > /* Handle the DesignWare 8250 'busy-detect' quirk. */ > > handle_dw_usr_busy_quirk(uart); > > @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) > > UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); > > /* Enable receive interrupts. */ > > - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); > > + ns_write_reg(uart, UART_IER, > > + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); > > It seems like not all cases are covered. For example, ns16550_interrupt() > writes 0 to IER when it switches to polling, which would turn off the UART > on XScale. Am I missing something? If not then something like: > > static void ns_write_ier(const struct ns16550 *uart, uint8_t ier) > { > if ( uart->xscale ) > ier |= UART_IER_UUE; > > ns_write_reg(uart, UART_IER, ier); > } > > would be needed, used in ns16550_setup_preirq(), ns16550_setup_postirq() > and ns16550_interrupt(). > Yes, i missed that path. I will add `ns_write_ier()` and use it in `ns16550_setup_preirq()`, `ns16550_setup_postirq()`, and `ns16550_interrupt()` so that UUE is preserved on every direct IER write. > ns16550_start_tx()/ns16550_stop_tx() do a read-modify-write of IER, so > they read UUE back from the register and write it out again unchanged. > They therefore work correctly without the wrapper. They could be > switched to ns_write_ier() as well for consistency, but that isn't > strictly necessary and likely could be left in way it looks like now. > > ~ Oleksii > Agreed. Since these paths already preserve UUE, I will leave them unchanged. Thanks Zhang > > } > > if ( uart->irq >= 0 ) > > diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h > > index d13352940c..358d264698 100644 > > --- a/xen/include/xen/8250-uart.h > > +++ b/xen/include/xen/8250-uart.h > > @@ -42,6 +42,7 @@ > > #define UART_IER_ETHREI 0x02 /* tx reg. empty */ > > #define UART_IER_ELSI 0x04 /* rx line status */ > > #define UART_IER_EMSI 0x08 /* MODEM status */ > > +#define UART_IER_UUE 0x40 /* UART unit enable (XScale/PXA) */ > > /* Interrupt Identification Register */ > > #define UART_IIR_NOINT 0x01 /* no interrupt pending */ From xen-devel-bounces@lists.xenproject.org Thu Oct 15 04:41:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 04:41:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449844.1665401 (Exim 4.92) (envelope-from ) id 1xHDGs-0002gj-Oh; Thu, 15 Oct 2026 04:40:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449844.1665401; Thu, 15 Oct 2026 04:40: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 1xHDGs-0002gc-Kb; Thu, 15 Oct 2026 04:40:50 +0000 Received: by outflank-mailman (input) for mailman id 1449844; Thu, 15 Oct 2026 04:40:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHDGr-0002gW-88 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 04:40:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHDGq-005oSq-LQ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 06:40:48 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0591b-8faa-0a2a0a5109dd-0a2a450ac2bc-42 for ; Thu, 15 Oct 2026 06:40:46 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0594c-f2d2-0a2a450a0019-9fe2fb15a460-3 for ; Thu, 15 Oct 2026 06:40:46 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowAAn__JGWdBqSv7pCg--.2109S2; Thu, 15 Oct 2026 12:40:39 +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, 15 Oct 2026 12:40:56 +0800 From: Zhang Zheng To: Jan Beulich Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , 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 1/2] xen/ns16550: detect and preserve UART_IER_UUE Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <5bc2e923-4265-484f-9236-25a56560e2c3@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5bc2e923-4265-484f-9236-25a56560e2c3@suse.com> X-CM-TRANSID:qwCowAAn__JGWdBqSv7pCg--.2109S2 X-Coremail-Antispam: 1UD129KBjvJXoWruFyrGr4UuF15JF48Jr15twb_yoW8Jry7p3 yxKF1vyrsrt3W8Ca9Iq3WDZF4Sg3Z7X34SkrWfG3yfZF15ArWF9F13JFsIqF1Du3W0yF1U uF4Y9347Jas8Z37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUtVWrXwAv7VCY1x0262k0Y48FwI0_Jr 0_Gr1lYx0Ex4A2jsIE14v26F4j6r4UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vI r41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64 vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8G jcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2I x0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK 8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I 0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU2Vc_DUUUU X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-4011c0/1792039246-593C4CFC-7EA99349/0/0 X-purgate-type: clean X-purgate-size: 1369 On Mon, Oct 12, 2026 at 02:52:06PM +0200, Jan Beulich wrote: > On 10.10.2026 05:14, Zhang Zheng wrote: > > --- a/xen/drivers/char/ns16550.c > > +++ b/xen/drivers/char/ns16550.c > > @@ -64,6 +64,7 @@ static struct ns16550 { > > bool intr_works; > > bool force_polling; > > bool dw_usr_bsy; > > + bool xscale; > > #ifdef NS16550_PCI > > /* PCI card parameters. */ > > bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > > @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > > /* No interrupts. */ > > ns_write_reg(uart, UART_IER, 0); > > > > + uart->xscale = false; > > + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > > + { > > + ns_write_reg(uart, UART_IER, UART_IER_UUE); > > + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > > + uart->xscale = true; > > + } > > Linux'es detection is a little more involved, plus: It doesn't clobber the > value originally present in the other 7 bits. > > Jan I noticed that Linux saves the original IER value and clears only UUE: iersave = serial_in(up, UART_IER); serial_out(up, UART_IER, iersave & ~UART_IER_UUE); Xen clears IER immediately before this probe, so I think there is no previous IER state to preserve. So I did not add `iersave` here. From xen-devel-bounces@lists.xenproject.org Thu Oct 15 04:46:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 04:46:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449851.1665409 (Exim 4.92) (envelope-from ) id 1xHDMf-0003qh-Ah; Thu, 15 Oct 2026 04:46:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449851.1665409; Thu, 15 Oct 2026 04: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 1xHDMf-0003qZ-7h; Thu, 15 Oct 2026 04:46:49 +0000 Received: by outflank-mailman (input) for mailman id 1449851; Thu, 15 Oct 2026 04:46:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHDMe-0003qT-B4 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 04:46:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHDMd-000snF-Bx for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 06:46:47 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad05a74-8faa-0a2a0a5109dd-0a2a4502ae30-46 for ; Thu, 15 Oct 2026 06:46:45 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad05ab3-6ca4-0a2a45020019-9fe2fb15cb70-3 for ; Thu, 15 Oct 2026 06:46:45 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowABHGOytWtBqDRnqCg--.2406S2; Thu, 15 Oct 2026 12:46:39 +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, 15 Oct 2026 12:46:55 +0800 From: Zhang Zheng To: Jan Beulich Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Baptiste Le Duc , 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 2/2] xen/ns16550: drain TX before reinitializing Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> <2415e2b7-3066-450b-9917-d1267a1c2b90@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2415e2b7-3066-450b-9917-d1267a1c2b90@suse.com> X-CM-TRANSID:qwCowABHGOytWtBqDRnqCg--.2406S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ZF1UZr43Wr4DCr1DCFy8Krg_yoW8GryUpa 18K3Z8JFs7tr4UKwnFva48WFWjgFZag34UCr18X34Ivrs0gFy29rWSgFWY9F90kr48Aw1j kw42gFyfAFnYvrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBYb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUtVWrXwAv7VCY1x0262k0Y48FwI0_Jr 0_Gr1lYx0Ex4A2jsIE14v26r4UJVWxJr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAK I48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7V AKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCj r7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6x IIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAI w20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x 0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU5P-PUUUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-720697/1792039605-311CF2AC-713ECE3D/0/0 X-purgate-type: clean X-purgate-size: 1483 On Mon, Oct 12, 2026 at 03:00:19PM +0200, Jan Beulich wrote: > On 12.10.2026 12:20, Oleksii Kurochko wrote: > > On 10/10/26 5:14 AM, Zhang Zheng wrote: > >> --- a/xen/drivers/char/ns16550.c > >> +++ b/xen/drivers/char/ns16550.c > >> @@ -427,6 +427,10 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) > >> #endif > >> } > >> > >> + /* Preserve output queued by firmware before taking over the UART. */ > > я' > > Could the comment say why the wait is needed at this point? Something > > like: > > > > /* > > * Output written before ns16550 takes over (e.g. by firmware or the > > * early console) may still be in the transmitter. Let it drain before > > * ns16550_setup_preirq() reprograms the line settings and resets the > > * FIFOs. > > */ > > > >> + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) > >> + cpu_relax(); > >> + > > > > IMO waiting for TEMT rather than THRE is the right choice: besides > > resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and > > LCR, which would corrupt a character still being shifted out. (Linux > > waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT > > already implies THRE.) > > Then again we have the .lsr_mask field. Not using it here would then call > for justification in the description. > > Jan I will clarify this distinction in the commit message. Zhang From xen-devel-bounces@lists.xenproject.org Thu Oct 15 04:50:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 04:50:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449859.1665418 (Exim 4.92) (envelope-from ) id 1xHDQX-0006Dy-Pw; Thu, 15 Oct 2026 04:50:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449859.1665418; Thu, 15 Oct 2026 04: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 1xHDQX-0006Dr-N4; Thu, 15 Oct 2026 04:50:49 +0000 Received: by outflank-mailman (input) for mailman id 1449859; Thu, 15 Oct 2026 04:50:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHDQW-0006Cz-2c for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 04:50:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHDQV-003OKm-8i for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 06:50:47 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad05b9d-bab6-0a2a0a5309dd-0a2a4507af4c-6 for ; Thu, 15 Oct 2026 06:50:46 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad05ba3-b4ea-0a2a45070019-9fe2fb15d268-3 for ; Thu, 15 Oct 2026 06:50:46 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowAAn+eyeW9BqISvqCg--.26715S2; Thu, 15 Oct 2026 12:50:39 +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, 15 Oct 2026 12:50:55 +0800 From: Zhang Zheng To: Oleksii Kurochko Cc: Jan Beulich , Alistair Francis , Connor Davis , Baptiste Le Duc , 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 1/2] xen/ns16550: detect and preserve UART_IER_UUE Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <1a6cdfbf-8116-48ca-b2cb-567e39fabe4f@gmail.com> <5d012ec1-60f8-43b9-a1cf-1bd0d0d133ee@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d012ec1-60f8-43b9-a1cf-1bd0d0d133ee@gmail.com> X-CM-TRANSID:qwCowAAn+eyeW9BqISvqCg--.26715S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCFW7KrW3KF1DtFW8Jry7ZFb_yoWruFy7pF W8KFnYyrsrtr10kr9Fq3WUWFsagF1kX34akryfG34fXrn8tF18CFW2qFW7ua4vvr4vqF1U uF4jqry3WF98ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUP2b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUtVWrXwAv7VCY1x0262k0Y48FwI0_Jr 0_Gr1lYx0Ex4A2jsIE14v26r4UJVWxJr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAK I48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7V AKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMxCIbckI1I0E14v26r1Y6r17MI8I3I0E5I8C rVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8Zw CIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x02 67AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr 0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU5P- PUUUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-ef75cf/1792039846-A74D3AE4-E52286E3/0/0 X-purgate-type: clean X-purgate-size: 4999 On Mon, Oct 12, 2026 at 03:24:20PM +0200, Oleksii Kurochko wrote: > > > On 10/12/26 2:50 PM, Jan Beulich wrote: > > On 12.10.2026 11:20, Oleksii Kurochko wrote: > > > On 10/10/26 5:14 AM, Zhang Zheng wrote: > > > > XScale-compatible UARTs require UART_IER_UUE to remain set. Probe the > > > > bit during setup and preserve it when enabling receive interrupts, so > > > > the xscale/PXA UART remains operational after ns16550 takes over. > > > > > > > > Signed-off-by: Zhang Zheng > > > > --- > > > > xen/drivers/char/ns16550.c | 12 +++++++++++- > > > > xen/include/xen/8250-uart.h | 1 + > > > > 2 files changed, 12 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > > > > index cdda28879e..c174465059 100644 > > > > --- a/xen/drivers/char/ns16550.c > > > > +++ b/xen/drivers/char/ns16550.c > > > > @@ -64,6 +64,7 @@ static struct ns16550 { > > > > bool intr_works; > > > > bool force_polling; > > > > bool dw_usr_bsy; > > > > + bool xscale; > > > > #ifdef NS16550_PCI > > > > /* PCI card parameters. */ > > > > bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > > > > @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > > > > /* No interrupts. */ > > > > ns_write_reg(uart, UART_IER, 0); > > > > + uart->xscale = false; > > > > + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) > > > > + { > > > > + ns_write_reg(uart, UART_IER, UART_IER_UUE); > > > > + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) > > > > + uart->xscale = true; > > > > + } > > > > + > > > > > > This probe only checks whether IER bit 6 is writable, which isn't > > > specific to XScale. On UARTs with an EFR (e.g. ST16C650, TI TL16C752, > > > Exar XR17V35x) the upper IER bits become writable once EFR[4] (ECB) is > > > set, and bit 6 is then the RTS interrupt enable. If ECB is already set > > > when the probe runs, it would report XScale, and the driver would then > > > keep the RTS interrupt enabled. > > > > > > Could the flag be derived from the compatible in ns16550_uart_dt_init() > > > instead, the same way dw_usr_bsy is? > > > > > > uart->xscale = dt_device_is_compatible(dev, "intel,xscale-uart"); > > > > > > That compatible would also need adding to ns16550_dt_match[]. The > > > SpacemiT K1 nodes, for example, have no "ns16550a" fallback. > > > > Are you suggesting that Linux'es XScale detection is flawed then, too? > > I looked at it quickly and not flawed as such, but Linux uses that test only > as a last-resort heuristic, which isn't how it would be used here. > > In Linux the bit 6 test sits at the end of autoconfig_16550a(). That > only runs for ports whose type isn't known up front (legacy/PnP/PCI > autoprobing), and only with CONFIG_SERIAL_8250_16550A_VARIANTS or > UPF_FULL_PROBE. It also comes after the EFR probes, so ST16C65x / > TL16C75x style parts are classified and return before reaching it. > Even so, the comment there says "this is probably one of the Xscale > platform's internal UARTs", and a part whose EFR already has ECB set > would fall through the EFR check and be reported as XScale. So yes, > the same corner case exists there. > > Where the type is known, Linux doesn't probe at all: 8250_of maps > "intel,xscale-uart" to PORT_XSCALE and sets UPF_FIXED_TYPE, so > autoconfig() (where it is happening the probing in a similar to suggested > above way) never runs for DT ports. 8250_exar sets UPF_FIXED_TYPE as well. > I agree that it is better to drop the UUE probe and identify the XScale UART directly from its compatible. Zhang > > > > > > @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) > > > > UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); > > > > /* Enable receive interrupts. */ > > > > - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); > > > > + ns_write_reg(uart, UART_IER, > > > > + UART_IER_ERDAI | (uart->xscale ? UART_IER_UUE : 0)); > > > > > > It seems like not all cases are covered. For example, > > > ns16550_interrupt() writes 0 to IER when it switches to polling, which > > > would turn off the UART on XScale. Am I missing something? If not then > > > something like: > > > > > > static void ns_write_ier(const struct ns16550 *uart, uint8_t ier) > > > { > > > if ( uart->xscale ) > > > ier |= UART_IER_UUE; > > > > > > ns_write_reg(uart, UART_IER, ier); > > > } > > > > > > would be needed, used in ns16550_setup_preirq(), ns16550_setup_postirq() > > > > Yes, the more that as per Linux'es driver source, bit 4 may also need keeping > > permanently set (not only for XScale, but apparently also for Tegra). > > Good point. > > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 15 04:52:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 04:52:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449865.1665427 (Exim 4.92) (envelope-from ) id 1xHDSO-0006yL-4Q; Thu, 15 Oct 2026 04:52:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449865.1665427; Thu, 15 Oct 2026 04: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 1xHDSO-0006yE-1p; Thu, 15 Oct 2026 04:52:44 +0000 Received: by outflank-mailman (input) for mailman id 1449865; Thu, 15 Oct 2026 04:52:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHDSM-0006x3-3F for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 04:52:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHDSL-000th4-Cd for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 06:52:41 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad05bfd-e002-0a2a0a5209dd-0a2a45088e32-32 for ; Thu, 15 Oct 2026 06:52:40 +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 6ad05c15-f659-0a2a45080019-9fe2fb1598d2-3 for ; Thu, 15 Oct 2026 06:52:40 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowAB3T_MQXNBqtjTqCg--.2548S2; Thu, 15 Oct 2026 12:52:33 +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, 15 Oct 2026 12:52:50 +0800 From: Zhang Zheng To: Jan Beulich Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Baptiste Le Duc , 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 2/2] xen/ns16550: drain TX before reinitializing Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CM-TRANSID:qwCowAB3T_MQXNBqtjTqCg--.2548S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ZF1UZr43Wr4DCr1DCFy8Krg_yoW8uFW3pF WDK3ZYyr4kJr4UKw13tw18Wa1jgF93ua45Grn5X34Sv3Z0gry3KrWIqF4Y9F98AF48Jw1Y yF4F9F93ZF1YvrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBYb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUtVWrXwAv7VCY1x0262k0Y48FwI0_Jr 0_Gr1lYx0Ex4A2jsIE14v26r4UJVWxJr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAK I48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7V AKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCj r7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6x IIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAI w20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x 0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU5P-PUUUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-c1860d/1792039960-D534D87B-B169CF46/0/0 X-purgate-type: clean X-purgate-size: 2371 On Mon, Oct 12, 2026 at 02:56:56PM +0200, Jan Beulich wrote: > On 12.10.2026 12:20, Oleksii Kurochko wrote: > > On 10/10/26 5:14 AM, Zhang Zheng wrote: > >> --- a/xen/drivers/char/ns16550.c > >> +++ b/xen/drivers/char/ns16550.c > >> @@ -427,6 +427,10 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) > >> #endif > >> } > >> > >> + /* Preserve output queued by firmware before taking over the UART. */ > > я' > > Could the comment say why the wait is needed at this point? Something > > like: > > > > /* > > * Output written before ns16550 takes over (e.g. by firmware or the > > * early console) may still be in the transmitter. Let it drain before > > * ns16550_setup_preirq() reprograms the line settings and resets the > > * FIFOs. > > */ > > > >> + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) > >> + cpu_relax(); > >> + > > > > IMO waiting for TEMT rather than THRE is the right choice: besides > > resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and > > LCR, which would corrupt a character still being shifted out. (Linux > > waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT > > already implies THRE.) > > > > The unbounded wait can hang early Xen boot if the UART never reports > > TEMT for some reason(?). Bounding the wait would make console > > initialization more robust, allowing boot to continue when the UART is > > unavailable > > > > for ( i = 0; i < 50000; i++ ) > > { > > if ( ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT ) > > break; > > udelay(10); > > } > > > > would need udelay() on RISC-V, which is still a BUG_ON() stub, so a > > separate patch would be needed for that. On x86, udelay() doesn't delay > > yet at this point (cpu_khz is only set by early_time_init()), so there > > the loop would just be an iteration count. Perhaps someone has a better > > idea of how to implement a timeout here. > > Whatever it is, it's going to be more or less crude. See e.g. Marek's > solution for a similar issue (yet to be committed): > https://lists.xen.org/archives/html/xen-devel/2026-10/msg00439.html > > Jan Thanks for the pointer. I will follow Marek's approach for the bounded wait. Zhang From xen-devel-bounces@lists.xenproject.org Thu Oct 15 06:48:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 06:48:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449920.1665436 (Exim 4.92) (envelope-from ) id 1xHFGU-0006ti-S3; Thu, 15 Oct 2026 06:48:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449920.1665436; Thu, 15 Oct 2026 06:48: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 1xHFGU-0006ta-NF; Thu, 15 Oct 2026 06:48:34 +0000 Received: by outflank-mailman (input) for mailman id 1449920; Thu, 15 Oct 2026 06:48:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHFGS-0006sP-IG for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 06:48:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHFGR-0069oh-Ne for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:48:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad07726-8faa-0a2a0a5109dd-0a2a4504b5bc-44 for ; Thu, 15 Oct 2026 08:48:29 +0200 Received: from [159.226.251.25] (helo=cstnet.cn) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0773a-b57f-0a2a45040019-9fe2fb19cc26-3 for ; Thu, 15 Oct 2026 08:48:28 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-05 (Coremail) with SMTP id zQCowABXxD41d9BqQ3VxCw--.4124S2; Thu, 15 Oct 2026 14:48:22 +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, 15 Oct 2026 14:48:40 +0800 From: Zhang Zheng To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CM-TRANSID:zQCowABXxD41d9BqQ3VxCw--.4124S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw1rArWxJFWDWF4xAFyDtrb_yoW8WFW8pF WkK395tF4kKr45WwnFq3WxJw47trsxCayUCr1DJa9Fyrs8XrWxCrWfK3yagas0kr1xJw4j yF42gas7AasYvrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Eb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUtVWrXwAv7VC2z280aVAFwI0_Gr1j6F 4UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkI wI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr 0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK 67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI 8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAv wI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14 v26r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7IU5SXd5UUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-ebf023/1792046909-C20D5B50-606DFD10/0/0 X-purgate-type: clean X-purgate-size: 1767 On Mon, Oct 12, 2026 at 12:20:50PM +0200, Oleksii Kurochko wrote: > > > On 10/10/26 5:14 AM, Zhang Zheng wrote: > > An SBI console call may return before the UART finishes transmitting. > > Wait for UART_LSR_TEMT before ns16550 reprograms the UART and clears its > > FIFO, preserving pending early-console output and legacy SBI v0.1 support. > > The problem isn't really specific to SBI: anything that wrote to the UART > before ns16550 takes over (firmware, a bootloader, or Xen's own early > console) can leave data in the TX FIFO or the shift register. I'd > describe it in those terms. Agreed. > Could the comment say why the wait is needed at this point? Something > like: > > /* > * Output written before ns16550 takes over (e.g. by firmware or the > * early console) may still be in the transmitter. Let it drain before > * ns16550_setup_preirq() reprograms the line settings and resets the > * FIFOs. > */ > Thanks, I will use it in next version. > > + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) > > + cpu_relax(); > > + > > IMO waiting for TEMT rather than THRE is the right choice: besides > resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and > LCR, which would corrupt a character still being shifted out. (Linux > waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT > already implies THRE.) > Yes, I followed the Linux implementation, which waits in an unbounded loop and theck UART_LSR_BOTH_EMPTY like you said: for (;;) { status = serial8250_early_in(port, UART_LSR); if (uart_lsr_tx_empty(status)) /* checks UART_LSR_BOTH_EMPTY */ break; cpu_relax(); } So I didn't have timeout handling Zhang From xen-devel-bounces@lists.xenproject.org Thu Oct 15 07:11:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 07:11:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449931.1665444 (Exim 4.92) (envelope-from ) id 1xHFcT-0005Gv-Ke; Thu, 15 Oct 2026 07:11:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449931.1665444; Thu, 15 Oct 2026 07:11: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 1xHFcT-0005Go-Hi; Thu, 15 Oct 2026 07:11:17 +0000 Received: by outflank-mailman (input) for mailman id 1449931; Thu, 15 Oct 2026 07:11:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHFcR-0005Gc-SW for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 07:11:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHFcR-00EXaL-2D for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:11:15 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad07c7e-e002-0a2a0a5209dd-0a2a4501a3ea-22 for ; Thu, 15 Oct 2026 09:11:14 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad07c92-5984-0a2a45010019-d155dd2ae40f-3 for ; Thu, 15 Oct 2026 09:11:14 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48df54150dfso163871f8f.0 for ; Thu, 15 Oct 2026 00:11: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-48df0f99f0bsm5045190f8f.21.2026.10.15.00.11.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 00:11: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=1792048274; x=1792653074; 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=xE+iqyFAzYCLjuj8rbiRjYNJkTNSStBwiqBAIkW4BTc=; b=F9L30NGUIMbxWNqUJ+WjUieV9ysSBfaQB1Tg0wi233oQut6knyGsOQ0GugadJB86aG HOU4GXaw5TVzsJtdOIrVSY6GhFiPWDH+IwhrFuwMhjAdXyYUTJ5AsEWxlnmSWVAZh/l8 3uYnce3HJ252ASgcx9SdhzABlhAJmgTQ1xf85yr+WnD0vUST4Qgw6b1ceUDz0HPdCRPa Le2H2VJgTzrKcbdyyISYfhH5LTOTNIFpIZo/XECyV2IiQtWpH+qLBKSidqi+b8tyOEfu CwEJRA/oC54g+ji+xpu6nVM7gOgpehQq/eBGGBFa8EjJHWYgb473q3WY9odSCWL7VamX L1bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792048274; x=1792653074; 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=xE+iqyFAzYCLjuj8rbiRjYNJkTNSStBwiqBAIkW4BTc=; b=eYaYfX0gSIPttjrSZTnqBjJYfgyndEYJ2zCwvs5LJ2kMZ8aDHCF/Xo78RiLfiaGWhX ZeL3d+97dIhpThYinTDPb4euBWC6riZqxkAPxXYOihepxZSHh8pPfQ7/oImUoNVFp20m RokovWucy+g7QsGsi3VE1BBsCsHQd0eTioPM5/YaIgnzKfF/mLdVDuiQ/BnSSj2eqzh+ dGsLMZCB0yj4NMHeLozWQbQ5eKwKdu9XwhIxs6d/bx/WS2V3HrMJhqMO/uMCLbqpBRuv uEHMsLfFGwQDwByy1U8P4m/nE5BBXBVf5ofOxAjDzwn1U6xsc0aQt5LizDWCbKs+9zA8 bCCQ== X-Forwarded-Encrypted: i=1; AKwUvBwuM6C/pXDz+VKc6vA8/WwcNk4Urh5P5BlT7FFb1xWMzRsJwwWHjrJALj/6Kn7xflpfddye6E+nzJs=@lists.xenproject.org X-Gm-Message-State: AFq9FYJbuzjuipsLiPpnGReQw3g08iZqBuUGfMkJA9SHKx7oJt5Z7boJ 09itKAjeL2pS4V5oj34PL9rw5MfVdEAXRzOmI89s8DD1wa3yBpO11PaAIJvEfeKYQw== X-Gm-Gg: AYBFou3gtg6npyLXib18R1xBhxcEVtfwh/hgTCKn57/KCCcfi6bYO+oDeYdbWx0lAzH 18I2UtggRfgKfkQTduh/vlMFfIO0Hh/ZhMzbHLZawUKeRbkTqPCJgxPpFFE6Y5LUwZpLZ80KBR/ pOtOade8C1BHhWOxhumQUJUUGslXuJLDVFd2ai4LCJfTnSQ841Nz6Ui1KMu2SU9Hqlr8mPBnfP2 u2oUbT47+kdms/xsjbPBKttoiN6SB7/zkFilQ6ow/dxQE9ito72b55Y90+cle0XbjeZHmGeT80V +YkHcF+NsoezbaGZ3XylEAvBifKnXF5bEomg+25hx46Pp3cE0UnjLYSI3WKeil6mZgarHgEFBvY 0OPujEgA+BOY07woblHVSJGpS81k1v/qEOrvdddTSY0aaDNwFAPtB+NXlcF+AF1ozA08370wTIC ydZIjxsHY7oFg7XWVUnyiUfeuAI4LzxSev1i3xGMau4pjp//tQHE6a+yvgpYk42HxS3YapATSxF OG3cltce6x0bG/zIeu9itVqWbnhYniux2qXhk1DP1i7b+X5QXI/OLmhpbXeyQ== X-Received: by 2002:a05:6000:4810:b0:488:7bdc:f7f8 with SMTP id ffacd0b85a97d-48dba9d2c0bmr34400894f8f.29.1792048274319; Thu, 15 Oct 2026 00:11:14 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 09:11:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gnttab: drop bogus check from _cache_flush() To: Andrew Cooper Cc: Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <6d0acc68-9d07-4e0a-b27b-0095a51ebe42@suse.com> <8d4f9d39-f80b-43cf-91a1-033a8bca777f@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: <8d4f9d39-f80b-43cf-91a1-033a8bca777f@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792048274-BFA6E757-5819B90D/10/78276251493 X-purgate-type: spam X-purgate-size: 1439 On 14.10.2026 18:24, Andrew Cooper wrote: > On 14/10/2026 1:52 pm, Jan Beulich wrote: >> There's no such thing as an alive domain without ->grant_table, and system >> domains (on Arm) don't own any pages. The check should also not be left >> there "just in case", because if that check could legitimately yield >> "false", the page reference obtained would then need dropping on the >> subsequent error path (see XSA-520). >> >> Reported-by: Andrew Cooper >> Reported-by: Yehyeong Lee >> Signed-off-by: Jan Beulich >> >> --- a/xen/common/grant_table.c >> +++ b/xen/common/grant_table.c >> @@ -3637,7 +3637,7 @@ static int _cache_flush(gnttab_cache_flu >> >> page = mfn_to_page(mfn); >> owner = page_get_owner_and_reference(page); >> - if ( !owner || !owner->grant_table ) >> + if ( !owner ) >> { >> rcu_unlock_domain(d); >> return -EPERM; > > Do you remember that I already posted this patch (to the security team), > and you already reviewed it? I do. That was after I had made this patch, though. > I'm afraid that your commit message is hard to follow, despite knowing > the details.  I already have one prepared from 3 weeks ago which I think > is rather clearer to follow. I'm happy for you to post (and commit) yours. I just didn't want this to fall between the cracks. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 07:14:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 07:14:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449938.1665454 (Exim 4.92) (envelope-from ) id 1xHFfp-0006Mr-28; Thu, 15 Oct 2026 07:14:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449938.1665454; Thu, 15 Oct 2026 07:14: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 1xHFfo-0006Lf-VL; Thu, 15 Oct 2026 07:14:44 +0000 Received: by outflank-mailman (input) for mailman id 1449938; Thu, 15 Oct 2026 07:14:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHFfn-0006LZ-N1 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 07:14:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHFfn-007oYi-3f for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:14:43 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad07d5e-2eae-0a2a0a5409dd-0a2a4509b1f2-40 for ; Thu, 15 Oct 2026 09:14:43 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad07d62-be1a-0a2a45090019-d155dd29c5a9-3 for ; Thu, 15 Oct 2026 09:14:43 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48b042c0728so1145628f8f.1 for ; Thu, 15 Oct 2026 00:14: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-4a1bd6834dasm45027065e9.4.2026.10.15.00.14.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 00:14: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=1792048482; x=1792653282; 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=1mRqXZJUKpeeawjkn1wQSZdVK5Twfog5vr8bsXD4zME=; b=QwwfnUj1J9rTrCWl2CzNajVUJtIGj93Gw4qftG/vkqRBbktMna44ofx6cH28tZ7LTx pgHfMuRpMgwBXCPeR86Eiy0K4Cu7StU6sLvpp29MIKdv8YarEHEVrFKu1ir319KCRfNv RnxENvaj23uWQaAw0QhXw5Yz/+nj24G5ZLuPTl9/0iWVfehjujM7cga+CDSf3dwjjLij 1AQVGZqBw0WqrUjGHzoXuRt4edEyfV8xPJzA+6ndNTxoh8nfwkmTJq9pGMsjQl3pNO5c p6xCR1eGfp0TfjOh8CjwNbqRbY8B+b+xMRklw/sqZz7e+3gRsW1MQbt2Pvv4ABk0O9F7 7hFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792048482; x=1792653282; 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=1mRqXZJUKpeeawjkn1wQSZdVK5Twfog5vr8bsXD4zME=; b=Si3K4fRpQ7/WjhW5X/teqmw9kvYjLUZvXY6/Pex6ZXneW70ZKRNDETZKYIElRzD5Il ZKITJvCmzChT/2DR4pKJzY/KhMn7l9J0Z6vr0eLz68c0BORr5XsNCQUdYCU32XgQSWCQ fYNwqoUEyswadX/sWyeHZqqmUxAxEjMflXcLgtnWlBYewRRJHoCNAi+Ac0MdPeLNOX5L M3P4lwV6hlh28vRF2+pSIlgcdyLz7mSXooqrG04b0xG3PNCSny8lU4jNqznbpDQx8Lbw 1pxoLZWsvbioZzOG341KGcBTo7M3051vMX122CEtkgGwhVWjA1r99d5ldszw1fFrm/UF qZBg== X-Forwarded-Encrypted: i=1; AKwUvBxPC0UdKtiuoIeUo6i2A1LChqsUXDPovcRUvZcLE8rV/6l81gWP19k+pCVb4xSw0Ik0ZDOu7lIbMNM=@lists.xenproject.org X-Gm-Message-State: AFq9FYJiCz+McAa0zjt1dMaTMQzcKrPniJGhy7IL9hLzGa1Yiothhm8x x3zR96jBdMdrA3nRCUiJ0tJ1tF+yR5D35m5d0/26Br1I+fHv0oJnTjOIY9t0tzV9Tg== X-Gm-Gg: AYBFou2oq7Nt1Rx8jEkAeVMGWdobC8ZiU3CQNV6DWWWAqO/BqEmNgBYAVxFd6nAgN/o Quw/dCkumFbw5myZL7nl2baUPWRKQjrjJgt72PpUmoI8xAXxY/5jAxqC37Px43eIa8GL9JTmkJt eZk1/+h8zqcU8Kv9P5hgaZdF8gj5hnVOUYBpbgFDhn/2cFQXrm3QcKVeOhRY+O9SemshqVdH1V2 I1ToCWHCjdDzN/tzOskf2W9yfhnvZR38LHUM6qN1f6VY0rJkPeYUhlkpi9hvoc1sEBBWdbIlfI3 b8ubpSWHZRr8a0UHNP9lG7ZHNYqaHoVnc+mMjdXnYkODLSspQwvw0n+Dyd5v94RhqCVojNPW+10 rLkJe06iac1v9yX52D1NWCJ60ilixiXSPHWfcSpXUPdI7Tw2terwJhcCDELzc9dmDvCoaqlL/J/ +vfKFOmOAAOK6FCd3/U3PKsMMNQbKXhNYMyZ4mIQrEi1foftdihJ9slTiXMGWyLoNPdcdHN6jFQ Tqulx0NSsgE7EzhklRYP5CR9+tBugEkCAyPNhzmD3TyeptUnCEYI5WqEMuTXyRC X-Received: by 2002:a05:600c:8b58:b0:49f:bcce:13f5 with SMTP id 5b1f17b1804b1-4a18e4ca287mr333364615e9.24.1792048482424; Thu, 15 Oct 2026 00:14:42 -0700 (PDT) Message-ID: <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> Date: Thu, 15 Oct 2026 09:14:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@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: <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1792048483-BD8C1034-FAE50432/10/78276251493 X-purgate-type: spam X-purgate-size: 2138 On 14.10.2026 18:45, Baptiste Le Duc wrote: > On 2026-10-14 11:09:58+02:00, Jan Beulich wrote: >> On 14.10.2026 11:00, Baptiste Le Duc wrote: >> >> In which case it would need to be >> >> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || >> !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) >> e->pte |= PTE_ACCESSED | PTE_DIRTY; >> >> albeit I have to admit that permitting two contradicting extensions to >> be exposed at the same time is irritating. >> >>> I see two ways to address this: >>> >>> 1) Keep checking Svade: >>> >>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) >>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>> >>> After resolve_ad_scheme(), the Svade bit is set in every case where >>> software has to preset the A/D bits. The only imprecise case is both >>> extensions advertised with hardware updating already enabled by >>> firmware, where presetting A/D is unnecessary but harmless. >>> >>> 2) Record the probe result in a global, e.g. >>> >>> static bool __ro_after_init hw_ad_update; >>> >>> and use: >>> >>> if ( !hw_ad_update ) >>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>> >>> This is exact in all cases, at the cost of a new global that mostly >>> duplicates what resolve_ad_scheme() already records in the ISA bitmap. >>> >>> I discussed with Oleksii and we are fine with either. What do you prefer? >> >> As to 1), see above. For 2), while maybe okay, I think we're better off > Sorry, I don't fully follow the issue with 1). Compared to what you proposed, > it only differs when neither Svade nor Svadu is recorded, which cannot > happen as resolve_ad_scheme() runs before and always records one of the > two. Yet previously we said that recording extensions (as such, i.e. later also possibly exposing them to guests) when they weren't really advertised may not be the right thing to do. I.e. imo the probing may be used to drive Xen's internal behavior, but I'm unconvinced that it should also lead to marking extensions as available. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 07:16:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 07:16:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449942.1665464 (Exim 4.92) (envelope-from ) id 1xHFhe-0007Ae-FB; Thu, 15 Oct 2026 07:16:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449942.1665464; Thu, 15 Oct 2026 07: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 1xHFhe-0007AW-9z; Thu, 15 Oct 2026 07:16:38 +0000 Received: by outflank-mailman (input) for mailman id 1449942; Thu, 15 Oct 2026 07:16:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHFhd-0007AQ-5Z for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 07:16:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHFhc-007p92-EE for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:16:36 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad07dc2-8faa-0a2a0a5109dd-0a2a450bb02e-28 for ; Thu, 15 Oct 2026 09:16:36 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad07dd4-b7e8-0a2a450b0019-d155dd36b998-3 for ; Thu, 15 Oct 2026 09:16:36 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48dd33a7bd4so1313564f8f.3 for ; Thu, 15 Oct 2026 00:16: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-4a1bdc036a4sm55667735e9.11.2026.10.15.00.16.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 00:16: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=1792048595; x=1792653395; 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=s8/VQiu6eoAG4fmUf4GeFTK9Hkh0eoTuflUyr8fi7G0=; b=R3EMk3u1/OktDxnzuyRNX33GNhb+YkSBkmL4jVhzCJ+F1mBJAJZ+YbAcmBzYxz/haJ VdIJbpVI55hhxWH/XDBpEJAfRshtQ2Hmk86pRgA1sLAST7KAMYQ/YzzC/UQU4s9UtbX3 2+jLUP1VUAcZQRbeReD5A0ge+0Ll/4MIbzYLnRryFhX5E8bspUfEpPhNoJJRVk/zZEJA YdoqwVm9+t2SwNPzyGl78ub8yZTzHXzJn3vrA24pifxgNcIwM7DFBgFjbEqh70JKCk68 /lBekGEcdqTUMXZBf/ZISDG4CsVH5tW8+mruPYB2SUDM6TUUwyN0tnR3sUFfyriUT5jL Vq7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792048595; x=1792653395; 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=s8/VQiu6eoAG4fmUf4GeFTK9Hkh0eoTuflUyr8fi7G0=; b=VmdEZLMdPPkPLx72w669yCltpbzI5vFCB1l3mRF8KY2SSYjCWCa6uLRd2h81ulN39P a7oaYWbTFQQ6KOvSHBPtIOuVoBpEE+R84Ehc8gWLkEEd8Kd2RUAljqFi+RMc20fgcb34 zS+6qPxUBqOIXpGnPgP/1mRscXQqWob2+7aNFzbjH6YqWPmJnTijxrQIcrhtnRpDXSfu 3bw+aU4nWonh7LJMImpD5fToKacaZNLUWfB0yMv7Up33QOED49P30cx9BL3+Pepao0Xq JxlhWsxuQUMLPO1hQ96lpvrd3Stwt/1APCGuAw4umsz7LXqyzwTspOrTBs7EB8fTEvCK WH/A== X-Forwarded-Encrypted: i=1; AKwUvByWpWJAsC2jEuDN0Vna/ftAHi3iHDtyfkWbBalyl7sQEhDIGwYi2L76bB8X0C/4B2vy3jTqaInFGjk=@lists.xenproject.org X-Gm-Message-State: AFq9FYJZh+Gp9kGeH6oEgD6UP+30DxYK3+b0+nK0PhYPPTlvCP5qWbfb hlUi3vy1CjZw0L5Ut7Azgy5gdWqBX3lFpuXMJee5V56645cF+dc3A+Ex4xZJkdtJlA== X-Gm-Gg: AYBFou1s+r2hCd2u/YSFks4TUaoJAiDdTFliAPNUsUHLb9hWvauibW7i5iu6DWAgx0H kDHAs7vzB93xRbn7S2u51ziRO19HAU21hNZFUlCoKdI15vOJNylFTsCrNw9i0wGfcjz3r7tHj7y tg63sEEhqY7RD8hp+g5NYlOl6Lsf6hQoIS8T1bqlgK3g+7VyJmxJb8nnDdaQjM6A4Nf+Z2F4JVL zMSLR4qD6Oo0qmbCGhmsVez2GZT+J8kGBy4KM99vjkn5h4MZAsk8lAfqFYP/uWTv6tkiVW2iK5T Dtdll681UT7lFQ3HSfa7Wku7SO6+wrZ8suVxJi1/Bg70/CaU88JusW3x//DkMB0iCjaTFlKzZX0 YKR9CyYm/ZMVmItb+C/pM9PCrSnli5Levpvh3HjjJD28uafAAISyVvItr4P3miY8eRJlobDLJmA sMgtQm+Lbk8wGodZPHMJGlwnFvX0LFOYyXCk9QP3XlZhiAP9q/xBl6Hu22bxpUrfI2wbHgIqsu/ oqC2a/brYwbjvBAhFWRDptBYifPnn4hyz+HFhcrQLbC1GIXjS3YdPR8PC3Ylw== X-Received: by 2002:a05:600c:3ba8:b0:4a0:174:579e with SMTP id 5b1f17b1804b1-4a18e4ab221mr417286145e9.28.1792048595191; Thu, 15 Oct 2026 00:16:35 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 09:16:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/ns16550: detect and preserve UART_IER_UUE To: Zhang Zheng Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-2-zhangzheng@iscas.ac.cn> <5bc2e923-4265-484f-9236-25a56560e2c3@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-42698a/1792048596-ABED69EA-5AE9C44D/10/78276251493 X-purgate-type: spam X-purgate-size: 1520 On 15.10.2026 06:40, Zhang Zheng wrote: > On Mon, Oct 12, 2026 at 02:52:06PM +0200, Jan Beulich wrote: >> On 10.10.2026 05:14, Zhang Zheng wrote: >>> --- a/xen/drivers/char/ns16550.c >>> +++ b/xen/drivers/char/ns16550.c >>> @@ -64,6 +64,7 @@ static struct ns16550 { >>> bool intr_works; >>> bool force_polling; >>> bool dw_usr_bsy; >>> + bool xscale; >>> #ifdef NS16550_PCI >>> /* PCI card parameters. */ >>> bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ >>> @@ -352,6 +353,14 @@ static void ns16550_setup_preirq(struct ns16550 *uart) >>> /* No interrupts. */ >>> ns_write_reg(uart, UART_IER, 0); >>> >>> + uart->xscale = false; >>> + if ( !(ns_read_reg(uart, UART_IER) & UART_IER_UUE) ) >>> + { >>> + ns_write_reg(uart, UART_IER, UART_IER_UUE); >>> + if ( ns_read_reg(uart, UART_IER) & UART_IER_UUE ) >>> + uart->xscale = true; >>> + } >> >> Linux'es detection is a little more involved, plus: It doesn't clobber the >> value originally present in the other 7 bits. > > I noticed that Linux saves the original IER value and clears only UUE: > > iersave = serial_in(up, UART_IER); > serial_out(up, UART_IER, iersave & ~UART_IER_UUE); > > Xen clears IER immediately before this probe, so I think there is no previous > IER state to preserve. So I did not add `iersave` here. Oh, right, I didn't pay attention to that, despite it even being visible in patch context. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 07:45:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 07:45:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449959.1665472 (Exim 4.92) (envelope-from ) id 1xHG9d-0005oM-G6; Thu, 15 Oct 2026 07:45:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449959.1665472; Thu, 15 Oct 2026 07: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 1xHG9d-0005oF-D7; Thu, 15 Oct 2026 07:45:33 +0000 Received: by outflank-mailman (input) for mailman id 1449959; Thu, 15 Oct 2026 07:45:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHG9b-0005o7-Su for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 07:45:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHG9b-006zO3-86 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:45:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad08496-8faa-0a2a0a5109dd-0a2a4504c2cc-20 for ; Thu, 15 Oct 2026 09:45:31 +0200 Received: from [40.93.196.33] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad08499-b57f-0a2a45040019-285dc421bfbb-3 for ; Thu, 15 Oct 2026 09:45:30 +0200 Received: from BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) by PH0PR03MB5845.namprd03.prod.outlook.com (2603:10b6:510:32::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Thu, 15 Oct 2026 07:45:25 +0000 Received: from BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550]) by BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550%2]) with mapi id 15.21.0522.012; Thu, 15 Oct 2026 07:45: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=Nov+UzQCw3Y1KB1Uhr9ryjnKnufaYEY+P7I3P/bJ69jGph4D/8MJd9Hqha+Jb6W5XQ8QS9/wzkVNe7S9ZEk9Mp2RhcxaiJba8x88Z2GFlXF1tP4SbkWC8r5Le0plxQwTM+w372xxhcBEvy+61/Nj1gHbPi1kpdl0Xc9XPeSnmQQad8Z3ckupC9pmeXN+rfplyvVBvi69EM3o6L1ENeMDA6Vepy287hQnJx4qGKMmKJCyZw8QPj+IbVFw8BLMz+mmaIY1eoHQBsmH7lOQXuXf+SAUT7Ef2vnvibaKN+ccj7CrCAMdEDWZXw1xXzfynpp/PWUizEk/CFzUbQUqIChtFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5V+TveEByXy3LtetVMfKqEKKomgPXI/+10CtxBApa5c=; b=Jq4rE3Af4r/6RwACOprDikZVWqcdRrgutLCuguDLrH4ajKMzxRRYT3EzRh0DYnF63LRfMG1uJ2HhfmwwksG/CkkkqEe3w+yF0WvlOh9h0n7/SAmduee6khmwO2IEaE1BxHD0XQ83opZ2VmvRldRIDMeVpu3zyw96TYl3k5tsGInZo/z8Z2OI7NYZe8kKh0KZLSgMDPVfv27qQYuhUTffVV0zx7YlRB19E4D8IO2vxm/6Dzg/+QksXJHxlbpmtWURL1qki4+1CcRP+B8P/FBB0U3NHzP+dp2nTT79d20+qnHWOjFBHJtfIQIfT4ngcfXEpYFzL8zVV5f56XCKYL6+Gw== 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=5V+TveEByXy3LtetVMfKqEKKomgPXI/+10CtxBApa5c=; b=mx3taEmcVHl09BCpC8XdV1asEF5baNcIPtWLn4P16ikH32zKPUCis6WrkWvnwC2OMVt9kXr6jUYg6DqvNh85HX4vPW999FJMCzl5aRVNR13TVF9fi7WKZpzpLNEHjLvt0vpwBiH+WOuASt59dnhLu7/eoryZ2U7LBb4qnIQtVJA= Authentication-Results: mx.microsoft.com 1; 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: [PATCH v1] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT Date: Thu, 15 Oct 2026 15:45:12 +0800 Message-Id: <20261015074512.221777-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KL1PR01CA0152.apcprd01.prod.exchangelabs.com (2603:1096:820:149::20) To BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR03MB5315:EE_|PH0PR03MB5845:EE_ X-MS-Office365-Filtering-Correlation-Id: 5153f625-4351-4119-fd0d-08df2a9045d5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|18002099003|11063799006|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: zhZS9jG5ksqPTm+k4UdVYSzbAZ8Sg6mXjGPWCk15nN/rtjhvkR6v5fTb87uS7zaGyGSg2vA3Qyqo6DreAPgiUEcy26lAdcnTbVprrsxr18xYPs2X1P2cB/tww3E4N23/yiowL8/zKYixDE6QS7lyxVNcHxW9JELwU8B2Ik7hfBrW4B1JIrqhG7g1k4fphwl59HDk6xhooWiKsrvbcZ/B2Dz7S5Ci0cblTg4DW1Va+lmGtkt93fYBssVbO0Aq0/KbkmSN8ccdpflCk5dZaUbUaSazizbMz41hEFBMUHInEi5mT6pSTRRWCQ6FwknkI8vFVlXkLMdzacux8FqAAiSt4zPD4I9uw3ku+kkFQdkJZLyFhtW3pkYfXgiYqi2gmZcAFP96+GE20+t8jnPAdl4bQ6rr11TX1ZVBnZggt3UXs18c+WbrhTAHS459/xUc+WuNYi34ZrORw+GaEkj6ieiwL6ZVz4QQXxdlslfM7uHlpWHqDM4iJgOA9p7JDdtH89YW5pODxgl+Dp7I0EY0FyOcP6ZI0I5A93MhphbT2RTtAMM56KmMgXfiFAz4AtvkF3N+EO2dfMkawgxZCfh8ARDVFcSe/k049jvZPn5gd9VFL7CoDlk5BwtzMQ3x8/w7XS4DW86rarHrXdBGUsQWrrm7knfgV0e0N+S4IFLynM6HMlE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR03MB5315.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(18002099003)(11063799006)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?FDwBm6TDAF0CrmTcsCUlswkkrTT5lyKaLWnI5jFusVSS3DV0fRGnVkXGHLcV?= =?us-ascii?Q?hbYd6UHV0kbJ1QudHC4S/iwMzfHWQ6RHHcCtkvplbOgS7PpcWN5DcR+vB0NS?= =?us-ascii?Q?hMnhZutNAXVuEKoTKYFiadUWm6d3fQfxdjRYipVwo9U30UjWZqFPyO1yeOpL?= =?us-ascii?Q?uNrTpv+YiwKIOvTfMtGKYoPQjo43X/gtVHPKhm+630niVw20YAEXHXe3PIxb?= =?us-ascii?Q?dOa3sotU8t04j/wwsS0IlLXTVhDJsnxbfR5eEVft+nmOR0bK9BFG+67XlPb2?= =?us-ascii?Q?bDg0X2hhES6PsXf0JZuO1nvGjD5iv7JTp7fH38oHATWT+RUEN6TsznxyW9tI?= =?us-ascii?Q?y8noyby74VwyS8rCKLIJcKQWI3uXORJ/Wc5Jph+HzD4rIF5muXJnCj2YC1/a?= =?us-ascii?Q?q75aZR88F1ZkTs7SGt+72+RbiQYnanVPhNhvssaZzkoY/ctNzhSVg8CZwxxG?= =?us-ascii?Q?K+yCc5ASnf//SPhKoUW5S85APBJuu0pddcLMDfXRny1yiwbecC/4lEYJvg2E?= =?us-ascii?Q?PINd3GQlu+ErRdgmf+au5JACchV4mQmHGrYUAMsSbJ+SvRk0TFxHceSRVsVM?= =?us-ascii?Q?PG5hullO5wdKDxoi6n5v+S6mV1OaDxYuqR6tDPKqEB90h9aLNT1YcOLngP9/?= =?us-ascii?Q?tcbC7hmn/bveBh2E8vr9a17cLfxb9Y0NB8MHr5T5rKBZhwDktIwNAHywCYG9?= =?us-ascii?Q?/s8yUUUG/qvBDxESKwTrNl6RpFGaGcTO3eLQswpPX3yEC8M4UB8uCRrzyS9V?= =?us-ascii?Q?LA5PrD11HhaCVU92ajeOlnPskXGc8BcyDK8ulet6yCBLQjnHvfgzxssnRA8r?= =?us-ascii?Q?ss7m0nIheYoK6gjFLkfqs+iOmUxq7APX+9G8ulVy4WDVyAhNTt5OjFZmKYjn?= =?us-ascii?Q?8pfqHLdRWyQSb6CilBpf2A7+7fCvSn/BXa+uoMoTEMk1nZYobeK967cYv4R1?= =?us-ascii?Q?lZRwMn7qKgcpJSZP3kbLnR0hfthMGx70iwb1QDRqPle/hHs8UD4zTj59K56e?= =?us-ascii?Q?x4WuUjfHVWp3rwKEHxATOuV+HusBVZEDjBaGA7vp+ThJFRhlLmVqQWO23nAF?= =?us-ascii?Q?kMNPtzg86UVqyzom3n/xiB2mmVcuE8djYSjsa2cwzHykHZdHAGLbKtOKD1ol?= =?us-ascii?Q?BJ+dqt74GiNOtLwSqs+J9YtX6mO1cDuu6V25vy+TmvZdlDgNhfRReU4AA0q6?= =?us-ascii?Q?65eBav0aDMX64miSAqvwJM/qtym03ZJ/+JbMkfcbEwN+YnOJRWBLO3umAUE+?= =?us-ascii?Q?bd1YpD4ZIwH0CjFHqW4X/xfd/vGap/fv0lwus+QKyLJCtd/uvo9xuSq6njew?= =?us-ascii?Q?7LD+6v52TXW4XwZowQvhW2U8ZoDIj/9KQePSsUuWZ/hUD5+JdCMEuJPIBUFH?= =?us-ascii?Q?/j9onaSX16ZoQ6/Q8sVWTj47fq3rrQVMjjZ7XDQnzLKKQnlwp2+3mcQ+5dYw?= =?us-ascii?Q?8PMHu1p+HXjma3LG34/ruuqAiw5qEVGwsuPliaGCEbiAcWrYLB/oQaaFfmti?= =?us-ascii?Q?fWFq6zspSpW1oVWYCwNdlxzZtR8U734/oT5L88sT7uN7Rg4RqYDwkYvfELHx?= =?us-ascii?Q?j1Ei1o1lHTRbp8WhscOyCuqW+ljhtAxilwu3aCBdw14bU6wmMrOWC4FevuWP?= =?us-ascii?Q?93Pq2HVglRy6CEvTCLGKAWLIqRGpTxpy4CTfdErIBmRcrrPZdFENr+KPMC0T?= =?us-ascii?Q?htlROWBP0VJ3Em8TJ9oRObKJIuiCwu4SdAMpL3CaE6qu7K2DKqkM0U1g3oBU?= =?us-ascii?Q?9qhtY7Gi/A=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5153f625-4351-4119-fd0d-08df2a9045d5 X-MS-Exchange-CrossTenant-AuthSource: BY5PR03MB5315.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 07:45:24.9166 (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: FmGkAcnyvhcsTOBGZY6eGO2tTPIG1J5ccagRSr4E5+3uDRWbN/YMHdWw0sUtX7gEU/F1rZ9wEDM2lVhq46WKZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5845 X-purgate-ID: tlsNG-ebf023/1792050330-508D9B50-98E282DB/0/0 X-purgate-type: clean X-purgate-size: 1864 From: Chunjie Zhu With V_NMI_ENABLE set, the processor clears V_NMI and sets V_NMI_MASK when it takes the virtual NMI, and writes both back to the VMCB on #VMEXIT (APM vol.2 15.21.10). nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally) V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never copied back, so L1 kept seeing whatever it had last written, regardless of what happened in L2. Copy both back when L1 has enabled vNMI for its guest. Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/nestedsvm.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index faacfe007832..ecd89eb43f06 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1027,12 +1027,18 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* * 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. + * enabled in L1. With vNMI enabled, #VMEXIT also writes back V_NMI and + * V_NMI_MASK (APM vol.2 15.21.10). */ 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; + if ( ns_vmcb->_vintr.fields.vnmi_enable ) + { + ns_vmcb->_vintr.fields.vnmi_pending = n2vmcb->_vintr.fields.vnmi_pending; + ns_vmcb->_vintr.fields.vnmi_blocking = n2vmcb->_vintr.fields.vnmi_blocking; + } /* Interrupt state */ ns_vmcb->int_stat = n2vmcb->int_stat; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 07:55:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 07:55:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449970.1665482 (Exim 4.92) (envelope-from ) id 1xHGIp-0000d8-E1; Thu, 15 Oct 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 1449970.1665482; Thu, 15 Oct 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 1xHGIp-0000d1-AV; Thu, 15 Oct 2026 07:55:03 +0000 Received: by outflank-mailman (input) for mailman id 1449970; Thu, 15 Oct 2026 07:55:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHGIo-0000cv-1t for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 07:55:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHGIn-00710T-7p for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:55:01 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad086c8-e002-0a2a0a5209dd-0a2a4508d8ae-4 for ; Thu, 15 Oct 2026 09:55:01 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad086c9-f659-0a2a45080019-d155802dbc76-3 for ; Thu, 15 Oct 2026 09:54:49 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a171b677d2so30956435e9.0 for ; Thu, 15 Oct 2026 00:54:49 -0700 (PDT) Received: from [172.20.10.5] (public-gprs367967.centertel.pl. [37.47.68.160]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1bd68585csm33483945e9.4.2026.10.15.00.54.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 00:54: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=1792050889; x=1792655689; 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=2v0VaYa6VgM5i5nyb3FRlwabJ6a/tr5PRWYVlVFU0uI=; b=tL4edTBKNXU1fZ4FizMQjw76OPCCtCVk+RGQ2Hl7Uo9aBX+qf4iyrl/Y4gOzK7vnll FsULb12aR5p3dRD2ax03Bco1l8RoBNP2oafo4S/m/3itYCu9FURKsHTfHwbzrCSuA273 IsfDN0v/fPO7p/XmTrSzlDvfHgQ3BokAkVRFcSW/FR5Benj1XKpvqT7paQYSKiAGVohe o7JFuk6PfyJxR5TcxnNC8g00YOM14c7QYTXhGfufHDZY/AcyDvWnAzmZncwIQA3IPejz OQKDx7aL3yY1KWFmnxrJJVToG96THINqMR0Y86R7K+bd1QGxZE7pL0Lb6LTxzzz7IuBr TSIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792050889; x=1792655689; 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=2v0VaYa6VgM5i5nyb3FRlwabJ6a/tr5PRWYVlVFU0uI=; b=FlQC6gmRYOE34N4jVoWC2dS7H0V6KSKIY6WoMaAdsi/p54Ky3HHT736qtVnS9TnyBP jJUHhY9OMxgfjORukGu+0ni01ycr2iOq77K53EfKksmzs+zPv44NV+fpSOaQB+lGdw/D gfZKRwRMRcRVelP89H5stmmD5KmXmd3n62k2zngOYCrro/fV5YYNtGX1ONFhliPhut35 utlyz3uz3D94rqB/+sA2icXL8lhIPz6lgir1vAlUGU0TAqdzZ2AEEJoZpeKXciv76Zaf 62bzh2fDbLB6PjTYd5mGvApxb1L/Pm5kyPoXloQxolmIxUGrybDLcKB8zw4q4/DYHL/4 bMPw== X-Gm-Message-State: AFq9FYIGThoOkkhxy1JGW7weYQesPexNpFwcmUngm+LvDJacurl99xXi 5lbblo+NJWLydmw9n6z7k+EyDjO2hq4iggDaCytoRwFXfgRUeYcU38sq X-Gm-Gg: AYBFou2picscnlHrQzCKFJc4BCHpmjv9w61bwhPMtusKdUmvn32LVEOD787Qu/+74Sq Bzgpucpy6HEaHkKRh7oum5ci4Bf/sl0AZ5Fkf5KHU81XsMEB4+G2WTj+l9Cve32Bw0oIAeLdX2R M1QFnO4yR62+olhW3/t+CbZMAcV6r4MAbAcj0N25UQRjeH2tWq0nZumvIWVqqNO66EujFwLWBcy CMN9RZKOz/6jM0kB+WuV0zY4qBXBXy3VrNmaT/poFafc9mVt0N3UZRb8y7FHisFvxS79/A1BUc7 R19tIQIlShwkYpWdJuhoHGcphFxYaSSfL/a3GFKHrLitjoEA0VNRsI736gnLvTb3BhHAMhZzPaS v+vjJ7Mbk/jCIWX76Ny8vAP7IZAsy5UVZZWr53pmaRy6WJYrn2EeIbw6FjZqlmut5bPeNK/Ks3T jjTvqpNgIa52YIlX+oZ5jJKwrib5+gvusun63thmHBvTcOMUXJZG0fmOEePJv+RPMgDXd6kzKuv A5cJ0XogBo17I/LOskKWGoGYp6XoS84UiHtVmk= X-Received: by 2002:a05:600c:548e:b0:49f:f9d1:e618 with SMTP id 5b1f17b1804b1-4a18e4aa057mr370501985e9.17.1792050889005; Thu, 15 Oct 2026 00:54:49 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 09:54:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing To: Zhang Zheng Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> 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/1792050889-CC57487B-ACC55FD1/10/73395122804 X-purgate-type: spam X-purgate-size: 2074 On 10/15/26 8:44 AM, Zhang Zheng wrote: > On Mon, Oct 12, 2026 at 12:20:50PM +0200, Oleksii Kurochko wrote: >>> --- a/xen/drivers/char/ns16550.c >>> +++ b/xen/drivers/char/ns16550.c [...] >>> + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) >>> + cpu_relax(); >>> + >> >> IMO waiting for TEMT rather than THRE is the right choice: besides >> resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and >> LCR, which would corrupt a character still being shifted out. (Linux >> waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT >> already implies THRE.) >> > Yes, I followed the Linux implementation, which waits in an unbounded loop > and theck UART_LSR_BOTH_EMPTY like you said: > > for (;;) { > status = serial8250_early_in(port, UART_LSR); > if (uart_lsr_tx_empty(status)) /* checks UART_LSR_BOTH_EMPTY */ > break; > cpu_relax(); > } > > So I didn't have timeout handling >> The unbounded wait can hang early Xen boot if the UART never reports TEMT >> for some reason(?). Bounding the wait would make console initialization more >> robust, allowing boot to continue when the UART is unavailable >> >> for ( i = 0; i < 50000; i++ ) >> { >> if ( ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT ) >> break; >> udelay(10); >> } >> >> would need udelay() on RISC-V, which is still a BUG_ON() stub, so a >> separate patch would be needed for that. On x86, udelay() doesn't delay >> yet at this point (cpu_khz is only set by early_time_init()), so there >> the loop would just be an iteration count. Perhaps someone has a better >> idea of how to implement a timeout here. >> >> ~ Oleksii >> > Leaving aside the unavailability of udelay() at this point, is a timeout > considered necessary here? In the way Jan B. mentioned here: https://lore.kernel.org/xen-devel/20261010031406.2057735-1-zhangzheng@iscas.ac.cn/T/#meaf24c3bb039dc6aaecffab752d2b107581816e0 I think we still can have timeout check. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:02:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:02:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1449993.1665489 (Exim 4.92) (envelope-from ) id 1xHGPg-0004HF-Hu; Thu, 15 Oct 2026 08:02:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1449993.1665489; Thu, 15 Oct 2026 08:02: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 1xHGPg-0004H8-F6; Thu, 15 Oct 2026 08:02:08 +0000 Received: by outflank-mailman (input) for mailman id 1449993; Thu, 15 Oct 2026 08:02:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHGPf-0004H2-9L for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:02:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHGPe-00415F-Is for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:02:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad08874-2eae-0a2a0a5409dd-0a2a4502acc0-42 for ; Thu, 15 Oct 2026 10:02:06 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0887e-6ca4-0a2a45020019-d155802ab435-3 for ; Thu, 15 Oct 2026 10:02:06 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a021c809e3so47154115e9.0 for ; Thu, 15 Oct 2026 01:02: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-4a1bd640be0sm40560475e9.1.2026.10.15.01.02.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 01:02: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=1792051326; x=1792656126; 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=HR5/ecCJdWvPDP212V1F+Ibu6b1V5udx/DW9D1oSIwg=; b=epVetF46aFqXaJyglNysgKO1K315qHXkZ01KUPskqKA8iEpjCNqYyoICKgJjTjoLVQ uEqrY2J2BlRgLsKK6UFuR/NWAIcVoJOwW4GXG008kxjTQY9hQje/LDb5JFIhGfORdJEi N0BNIyX1sejd7gnzso/jfTsbz/3OtsZ/FPFziiz/J17XmCUHOzvCB7igqHjkU73jP2P2 BeVQ4UwhAu6R+LBpaTLzGRj0evkzctJWQ2aUjWIs64Bzy13C9cQirbq7yM56CKqbXjeg iBWddwst5jr03URsZZ6qfaWWs3nyr6VCxOb7XLuLBBRjlV7vsDsBhHXvPmPhIDcnasO1 pPmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792051326; x=1792656126; 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=HR5/ecCJdWvPDP212V1F+Ibu6b1V5udx/DW9D1oSIwg=; b=alXRw82/hz7o5aMUfSnBKWSS808pu/or9PWIqSVsal0zSZGjD3PNT35E05/gYtBpgl zEebh25hvb5ahvUSwoj2rjfaKuR2eL05y73pGTLFo16HcRHvixqh5vHAeglSxWbvpJsK kGV0lkEPYdTxl3msKJR0KnEVpj9G9QtlcLteztolSMR8bEt3BqAL3LjFnaae2hGnoIr4 +Q9OEX3IK26U4IdP4xHHNEEry7ks5k6auACfq3hi++juUDH+T5iEqFaGpo/uLvZXhNtQ G2GvfjPqImvwKjUIOo/30KW/ey+C+Iu8WKCT8dWsp8KOxoWQndmEqoyAFOsU4UR86pM1 E1rg== X-Forwarded-Encrypted: i=1; AKwUvByTcKwJRUb93ONHteOedJltDNXs7+gR62org6oTqXackZCjrgVztLn1033zDVEzW7inMPbQaAdKwSE=@lists.xenproject.org X-Gm-Message-State: AFq9FYLR1Gd9vgPgF8oGuPmHtRatNTdiVsfDSYMblVGFcpxZrXEs7ISW xdIPe+jQGiv6fjUuS84wUrTfUtp9XHCOUBbg9+eT3rcJpOyhOI6H8vf745qSFTjSlA== X-Gm-Gg: AYBFou3/LBTZfRmRMqSXG5LWhuXaY6QYUZgx2GqyBdtD9mr4qHyJs6TdOLfK4Ylic/a NfnaOVYB8lQYoa1cpe8Vn8rhOAAAeUyxyZiSjMN+AwmUsLloxwX0m2wVQkbIAlXz/HtnSDuY7uX 3lgMcAtGXWDcjBcOEzWzKEWQ4PT4CwqvLtrmPV2ClOHkptRkh+JldQaPWUP6oPiPVjXVMG/VZaX T7+I+cnoFZm+06aHFTq515JLoB2EKhZgy+06MfTovAls05wE29LSsE6OxUdmAU6QqydOS2zfedA B8Pkg14w6BqO8fIU5WRd007z5O/8W+wpApI92XRa71O4hug/W+CtpYBil7OcDU/VxwE5liiUEeK o9AWyAICFl2Rhu3WHpQ7/xPFBwTvve7ZpYWumPD37buvN6FwlDTmRQ5LN5JP+kPvtfNwaTxDesh 7K60NoprK5bYPwGQ7Xd1bVBrl9I+5VRYeCwEpe01fqXDFBEOMS53H5t1E9G3gv27TwkjsdZ7jYa JUOZeKbo0yZYF9KNWsjHzxA4ph18/mAX8Kq0cabMaOUY1RZXYyEJbM6xW77pJs= X-Received: by 2002:a05:600c:608d:b0:49c:cee0:e7c1 with SMTP id 5b1f17b1804b1-4a18e48d45cmr395039405e9.16.1792051325302; Thu, 15 Oct 2026 01:02:05 -0700 (PDT) Message-ID: <7973ea62-3add-44fb-86e9-28c6169ce9a3@suse.com> Date: Thu, 15 Oct 2026 10:02:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] MAINTAINERS: Add myself as RISC-V reviewer To: Baptiste Le Duc 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: <1791991262.8631fc262581453bbf619ec5b2062170.1a13b00ab040008425@vates.tech> <1791991353.8631fc262581453bbf619ec5b2062170.1a13b020f670008425@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: <1791991353.8631fc262581453bbf619ec5b2062170.1a13b020f670008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1792051326-F02992AC-55556319/10/78276251493 X-purgate-type: spam X-purgate-size: 155 On 14.10.2026 17:22, Baptiste Le Duc wrote: > Signed-off-by: Baptiste Le Duc Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:10:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:10:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450004.1665500 (Exim 4.92) (envelope-from ) id 1xHGXK-0005us-Al; Thu, 15 Oct 2026 08:10:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450004.1665500; Thu, 15 Oct 2026 08:10: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 1xHGXK-0005uM-5T; Thu, 15 Oct 2026 08:10:02 +0000 Received: by outflank-mailman (input) for mailman id 1450004; Thu, 15 Oct 2026 08:10:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHGXI-0005mS-DO for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:10:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHGXH-00Fx1X-Jl for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:09:59 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad08a55-2eae-0a2a0a5409dd-0a2a450cd3ea-6 for ; Thu, 15 Oct 2026 10:09:59 +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 6ad08a57-f479-0a2a450c0019-d1558033b0fe-3 for ; Thu, 15 Oct 2026 10:09:59 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a0213948d3so30205875e9.2 for ; Thu, 15 Oct 2026 01:09: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-4a1bd67a080sm50887665e9.3.2026.10.15.01.09.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 01: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=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=1792051799; x=1792656599; 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=ZWz/Q/e4xfTnjx1BnY66hyE1/2iihu5eJvjmWLbMfso=; b=bZuXtkYKI6myGcLUbtf4GWPA6eBmxOBRovXqCZC+aNIKkkER3KsZy8EWia46XaGpOu ao4UNOOQ69jC+gmggQvtpQNUn7cjBU2e3jodf+NGSZsKWScw9qqtZI23+BpTyhMgDzL6 H2tHN4e5Qa1pdyV+J/OJNum5zy+iJ7E6fWalQVKdzfsOlA2/OFyu5HTN6githEYEbHY4 tKR5j50TxwxHcGpk9R2vUDfZWjoGFYObStbjwH8cjg4pcwILGetONfmsnpLTrKQ5d/+H CWaEZyU/P7mDM54qgp1UmskXFh4b2WJwO+7dBIfAh9zgI4BjyCahupSiRoy+BXH7/rji KBXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792051799; x=1792656599; 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=ZWz/Q/e4xfTnjx1BnY66hyE1/2iihu5eJvjmWLbMfso=; b=WkTQSWmCN+rGccxO8R0d6fVU508hT9YI8TsBlNrBZY9MlbH86f7QKgQ6S/VJqsH57x c4fZ4fhqQuV/n1l1896QVR2eR/JDiMhNupImEVFRGCVXGijyX0QyvsL84S4O57QAefaz A99NUAw/xlTdEDTViBu77PgkDEETVDxZP7el/pSssQBe/U61gTWW+4cmuQXhhh4H5IWp yGz8jk95PtZBFbgG7UKallZs/QzfC7d8T1IRiVpjfD6q50IBe8bGrjago3cRBG0mkoC1 moS8jd9SFO2IFq2t3jLJHedQKx65/qHBEBhf2nx2gy5YWcYR4sK3KVW8VpsFC58AtuOI nhPw== X-Gm-Message-State: AFq9FYKm90BR+/n4gljMIy9EOhT6YL80o4UF3fLFwlUsmdRqFErzHkFz s+eCyvUuzDADxpYwheVsfSaO7E0xtXMtGJO04SA717gDUrb8Q9bpTflsqN7fRKJIYQ== X-Gm-Gg: AYBFou3Tai1jNERTxVLJg7CC6sKUtsF7HAb+w1mV97ExOEeJvhEPtL3N8xrz1p76EI9 WG4+c1OIydmv0ALHJxBAl464/MzzvTUaAWBz2+owY5bdNAE+PVFusPHapiN+CbOYowryZ++ydYn prUjTGqqJ0oLpWp2vw/lvz68z6tb3ygdby/2B3WsdDAK6swFQQsaEgLYZks9wTdgQug6VsfDnAV R6cIoXmDg1i5uJRwxCbaccUQkFd+70WUzmBJF8pCpf+80BuJAir/JlEQnP+x4nme0NFnmGSASAb E7MJR5PjwO4qDcuGd61Gk63Ytd9kNVAkITA6xbXaDTbMNu7EaBABsUfDKNLWrtK76dsurQCdcYl pHedXic2T8pO5tGTdy+//YAOTxAVmdxjSAy7b913pVkrjec2ja+EkoBe+kGRPmq/0t1c8TWNRhv fN+4kCSW/DqPAF+3falwVG/7myFwOnxZa0cSQBfTZpTqs892WLn05Av4VPDQ20VyGa9HDAuS995 uUW/XLERuVo3VyCw8oqFwW0XCHW1CkLDM3Bei88If+RDHf9PVwEkDvZh5W1Ig== X-Received: by 2002:a05:600c:154b:b0:4a1:6af4:c6be with SMTP id 5b1f17b1804b1-4a18e4d1c0amr344415425e9.34.1792051798419; Thu, 15 Oct 2026 01:09:58 -0700 (PDT) Message-ID: <2991b4a6-2b1d-4903-812c-819d478beffa@suse.com> Date: Thu, 15 Oct 2026 10:09:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 15/18] x86/mm: flush owned pages before reuse with the sparse directmap view To: George Dunlap Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-16-gwd@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1792051799-51F33A5B-B8738DA6/10/78276251493 X-purgate-type: spam X-purgate-size: 2111 On 14.10.2026 17:34, George Dunlap wrote: > On Thu, Oct 8, 2026 at 8:00 PM Roger Pau Monné wrote: >> >> On Wed, Oct 07, 2026 at 11:40:48AM +0100, George Dunlap wrote: >>> Since d7bf1b8ea275 ("x86/mm: limit deferred TLB flushing to PV domain >>> support") a page freed by its owner is flushed from TLBs before it is >>> handed out again only in builds with PV support, on the premise that PV >>> domains, with their (limited) control over the host MMU and over when >>> flushes happen, are the only ones to leave stale entries behind. >>> >>> Xen's transient mappings of domain pages are another source. The >>> mapcache zaps a slot when it is unmapped but defers the flush: the >>> slot's translation can stay in the TLB of the CPU which used it until >>> that CPU next flushes, by which time the page may have been freed and >>> handed to another domain. Before "x86/hvm: introduce per-vCPU >>> mapcache for vCPU-PT domains", only PV vCPUs use the mapcache, so the >>> PV condition covers it. Now that the vCPUs of an HVM domain with >>> per-vCPU page-tables have one as well. >>> >>> While the full directmap is loaded in every context, stale transient >>> mappings only map what's already mapped in the full directmap. On the >>> sparse view of the directmap, a stale translation of a page handed to >>> another domain would keep it reachable from a context which has >>> nothing to do with it. >> >> But if it's handed to another domain, then it also hasn't gone through >> a free cycle, which is what pg->u.free.need_tlbflush covers? > > Sorry, the wording there is a bit imprecise; it should be "a stale > translation of a page *freed and then* handed to another domain". > > Apart from things like steal_page(), which doesn't apply to HVM guests > AFAIK, there isn't any way to hand a page to another domain, is there? I think you're right that there isn't any. However, there is that plan of Stefano's to make steal_page() work for HVM. Their main target is PVH Dom0 iirc, so that may still be okay-ish for the purposes here. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:28:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:28:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450019.1665512 (Exim 4.92) (envelope-from ) id 1xHGpI-0001H9-NJ; Thu, 15 Oct 2026 08:28:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450019.1665512; Thu, 15 Oct 2026 08:28: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 1xHGpI-0001H2-KG; Thu, 15 Oct 2026 08:28:36 +0000 Received: by outflank-mailman (input) for mailman id 1450019; Thu, 15 Oct 2026 08:28:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHGpG-0001Gw-Ko for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:28:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHGpF-0047vJ-UJ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:28:33 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad08eae-8faa-0a2a0a5109dd-0a2a45089ab2-0 for ; Thu, 15 Oct 2026 10:28:30 +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 6ad08ead-f659-0a2a45080019-b9ff1c23b053-3 for ; Thu, 15 Oct 2026 10:28: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 1a13ead4e580008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 15 Oct 2026 08:28:27 +0000 Received: from [172.20.10.2] (132.169.185.81.rev.sfr.net [81.185.169.132]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id D86BE81CA2; Thu, 15 Oct 2026 10:28:25 +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=wnC1BNdB+PBOfJVOe3gI8WO5+075QEnPdeVVym4FUPo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=PxFiRtz17Q8/M9ZgVok+92eXq07Uz+SURCWc+EYcYTAGa9uNYOG+4DDqwcXb0leiVO81sC0A7 DYw1dp33q711pqB7KU26464KvE8OBh5nm/dP0SZjagn+MHZolSFJ9nanhJERl7Mc+XiHFx6ehMR NUXKenpBucfIE1m4k/bSn3t+VZkmfLE3NKCPL/kyOOEJ1Cpm+t6ZBSoMUYm3epR0zoa3jNC631n BZrlYQ9NxcRrMMA/4ISTmp1g88RroWwOHO5GdKAe9j42gTjL+MoqFBJiaMLe7uVnkG+4igFCRkA ByTxnLZ70LuExEJMCKA95J6Y4TkpOA84ke68Eu22fXvw== X-Zone-Loop: e22ba0327d5eb14372081d6c1e7b674f4b8ed9901273 x-campaign-type: default x-transaction-id: 00c7fc3f-ec97-41b4-8b43-94cff182763e x-swg-uid: 01-425d9119-2cb4-4e63-bbe2-e1997ab951a8 X-Mailer: Sweego Message-ID: <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> x-swg-bid: 1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425 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 v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org In-Reply-To: <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> Date: Thu, 15 Oct 2026 10:28:19 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792052899; l=2942; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=oVjKUF7fTEDd970/bPaoVV1BOOz55PBrutMhHgJQljY=; b=Mo1LmrUPSM71/CokwzZNj0ELcK17aQSXEQBbNqc54gZt09nuftq/I2M3aysZEgzj3LYAbiuy3 4kGfyxoprHfAV7T0Y0+s+79UlLUjqE3d0Rw/NbVU0sVGOEBTk01Fpez 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: 1792052906826 X-purgate-ID: tlsNG-c1860d/1792052910-D574B87B-D169B7DD/0/0 X-purgate-type: clean X-purgate-size: 2942 On 2026-10-15 09:14 +0200, Jan Beulich wrote: > On 14.10.2026 18:45, Baptiste Le Duc wrote: > > On 2026-10-14 11:09:58+02:00, Jan Beulich wrote: > >> On 14.10.2026 11:00, Baptiste Le Duc wrote: > >> > >> In which case it would need to be > >> > >> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || > >> !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > >> e->pte |= PTE_ACCESSED | PTE_DIRTY; > >> > >> albeit I have to admit that permitting two contradicting extensions to > >> be exposed at the same time is irritating. > >> > >>> I see two ways to address this: > >>> > >>> 1) Keep checking Svade: > >>> > >>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > >>> e->pte |= PTE_ACCESSED | PTE_DIRTY; > >>> > >>> After resolve_ad_scheme(), the Svade bit is set in every case where > >>> software has to preset the A/D bits. The only imprecise case is both > >>> extensions advertised with hardware updating already enabled by > >>> firmware, where presetting A/D is unnecessary but harmless. > >>> > >>> 2) Record the probe result in a global, e.g. > >>> > >>> static bool __ro_after_init hw_ad_update; > >>> > >>> and use: > >>> > >>> if ( !hw_ad_update ) > >>> e->pte |= PTE_ACCESSED | PTE_DIRTY; > >>> > >>> This is exact in all cases, at the cost of a new global that mostly > >>> duplicates what resolve_ad_scheme() already records in the ISA bitmap. > >>> > >>> I discussed with Oleksii and we are fine with either. What do you prefer? > >> > >> As to 1), see above. For 2), while maybe okay, I think we're better off > > Sorry, I don't fully follow the issue with 1). Compared to what you proposed, > > it only differs when neither Svade nor Svadu is recorded, which cannot > > happen as resolve_ad_scheme() runs before and always records one of the > > two. > > Yet previously we said that recording extensions (as such, i.e. later also > possibly exposing them to guests) when they weren't really advertised may > not be the right thing to do. I.e. imo the probing may be used to drive But we also said that platforms (such as the P550) may implement an extension without advertising it, as a RISC-V spec maintainer confirmed in [1]. [1] https://github.com/riscv/riscv-isa-manual/issues/3450#issuecomment-6076851535 > Xen's internal behavior, but I'm unconvinced that it should also lead to > marking extensions as available. Therefore, as far as I understood, you're not convinced of this: /* Neither advertised: trust the probe. */ __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, riscv_isa); If so, then, the only solution I have in mind in what I proposed in 2) with the global variable that store the result of the real probe. Am I correct? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:28:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:28:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450021.1665520 (Exim 4.92) (envelope-from ) id 1xHGpd-0001Zx-38; Thu, 15 Oct 2026 08:28:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450021.1665520; Thu, 15 Oct 2026 08:28: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 1xHGpd-0001Zo-0Q; Thu, 15 Oct 2026 08:28:57 +0000 Received: by outflank-mailman (input) for mailman id 1450021; Thu, 15 Oct 2026 08:28:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHGpb-0001ZQ-Pj for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:28:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHGpb-001cg2-6L for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:28:55 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad08ec0-e002-0a2a0a5209dd-0a2a45018e6e-14 for ; Thu, 15 Oct 2026 10:28:55 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad08ec7-5984-0a2a45010019-d155802ee518-3 for ; Thu, 15 Oct 2026 10:28:55 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a1682bff3cso8027375e9.1 for ; Thu, 15 Oct 2026 01:28:55 -0700 (PDT) Received: from fedora (public-gprs367967.centertel.pl. [37.47.68.160]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1bd5e9dd7sm36029895e9.0.2026.10.15.01.28.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 01:28: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=1792052934; x=1792657734; 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=TgX8fpX0WC/UHWq0xLpQHSFXGDe7NEPolmA1/ZDpQ14=; b=p6MAgwoRqMW/TfW3gWjMRRWnH1KkZVnlm76XBXiyXbsgWIevhhUtffLuR9Yby7hBIV d0+gaBD8NOsDBrFfUt5D7m0pFu2wmlI3D6khtwX0fM/QYOSIVj3u+q51cEhJMGFnbk0k w+aK3Vv6Z9ApL5J6tkMvkVSzs4oKgZQXW3QzKOcQzYQYUR72nMwQrO+3S2wVD1bZ1iu3 2fYtgA7EV4P0rGOscKD4fQ2MVRo+4YGT1G4yPsMMATfMTN+gCtIHsEdwBYyyVI4B5wN7 ECDrdwpj4iatydUmMYHbN11gaAA8nIvp6jKKugSQpXGEgyoyaNrYQsPIJ5NgTUAaa+p7 wOZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792052934; x=1792657734; 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=TgX8fpX0WC/UHWq0xLpQHSFXGDe7NEPolmA1/ZDpQ14=; b=IpB1ZTe61T4IRV9PPj7Eu98axkrqS85xo4RjHvn4yuXd//Tol4mlnWggVV2OKe1ixA xrRv8g/O4HolL10+yeBiyMJdFH/ty5IcH4mn9VoCruwKmdFWFvxrB5ggGR6uewFXIATM /LNpo8dojN3jFM62Fifobbu40CLrU7+APd7+x6y/RN8F2E5Fcms+mtx3PAa06AW7aGno +Ht1htAtvHi2x/ggjc6Y//y8PcQF2GujhGFjshbd87v+zzKH9+Mz4g7v45YtCAF8QR24 TNU8IlVUkXtd8E3xHnNNXjJLh/74jdDOCJ62CKAJE2U8R4Mr7xeUNmADE+dsIkf6ybHt t/FQ== X-Gm-Message-State: AFq9FYLeq8sTpfMRVLx0wSQwQFm5Q6MDKeqApRh+CP4g/LmfCMpS8wS9 XGdFhECfMsipOLBGU6OoA4osWV3coxUFtMzPIaA3LzEzS3FpGtP5M+CCfhfdTg== X-Gm-Gg: AYBFou0i5ckB+RlED5BvXfTjKMLMYlmpblzchhMkwpTeWMXVTobtITnL+OXMBXXkb+W w6dIqDey/0spKHRgGVEWqU0JyZ8Zi1GCyR/0Somc4xocrCwcrcwQx9vjoljW3Gp603FnL5mcZHZ DdisPbtZIW+2EjYpf8axk9A0XY4HAILdjQb+eGr0nwJWy/uEcA4hxuxh6os2R0LlGAhI1vRTXh9 XDQLbSdj/YejTbFOLoefj7I/vly93G2TTtKtW8FThP/EkDW3EYXXs0bxmh1b9DnBByonH6QbkRx KoyQOL7JaZ5xtC21NGFVDz3G3SpzotC5e+J/MMf5e2v3FTM0PaNf/SFzfDKrsp0g+Vz+UpfT7/6 mTtO+qZa5szI8YxNkIW/iKMfqVGwxuR4CjdQJSeMyABtriZuNrHpgLm9rTL1eEfzGltlr3H6TPM O9Vkn3153Enw3vCBqnHy0q6rGuuH+3hmhDDrMLhyMw3FwVMj3/9Pxqa6GS34ToJiVzv4wqi9RJN X8vTE6/PEN6AR91fMb9vxOeWmVqSe0Jjc/Xr1y/ X-Received: by 2002:a05:600c:8b64:b0:49d:174e:2a1e with SMTP id 5b1f17b1804b1-4a18e498851mr389949485e9.19.1792052934395; Thu, 15 Oct 2026 01:28:54 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH v3] xen/device-tree: add a helper to dump an FDT in DTS-like format Date: Thu, 15 Oct 2026 10:28:45 +0200 Message-ID: <20261015082845.19511-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-d62444/1792052935-BFA6E757-2724E578/10/73395122804 X-purgate-type: spam X-purgate-size: 11297 The device tree Xen builds for dom0/hwdom or for a dom0less domain is only ever consumed by the guest, so a mistake in it surfaces as an obscure failure inside the domain, far away from the code which produced the tree. Add device_tree_dump(). The output follows dtc's format so that a dump can be diffed against the source DTS or fed back to dtc; the value formatting heuristics are ported from dtc's utilfdt_print_data() for that reason. The walk itself goes through libfdt rather than decoding the tag stream by hand as dtc's fdtdump does. Dumping a whole tree is only useful while debugging and costs both code size and a lot of console output, so it is put under its own option, CONFIG_DEVICE_TREE_DUMP. It is separate from CONFIG_DEVICE_TREE_DEBUG because the generated tree is often all that is needed, without the rest of the device tree debug messages. Signed-off-by: Oleksii Kurochko --- CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2947342162 --- Changes in v3: - Drop the loglvl remark from the CONFIG_DEVICE_TREE_DUMP help text. - Indent the dump by 4 spaces per nesting level instead of 2. Introduce macros DUMP_INDENT_WIDTH for that. --- Changes in v2: - Dump the device tree generated for dom0/hwdom as well. - Put the dump under its own CONFIG_DEVICE_TREE_DUMP instead of CONFIG_DEVICE_TREE_DEBUG. - Pass the domain to device_tree_dump() and print the "Device tree for" header from it. - Combine isprint() with isascii(), as Xen's isprint() also accepts the characters 0xa0-0xff, unlike the one dtc uses. - Update the commit message. --- --- xen/Kconfig.debug | 9 ++ xen/arch/arm/domain_build.c | 2 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/dom0less-build.c | 3 + xen/common/device-tree/fdt-dump.c | 188 ++++++++++++++++++++++++ xen/include/xen/bootfdt.h | 16 ++ 6 files changed, 219 insertions(+) create mode 100644 xen/common/device-tree/fdt-dump.c diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug index d900d926c555..8e90209b8b65 100644 --- a/xen/Kconfig.debug +++ b/xen/Kconfig.debug @@ -98,6 +98,15 @@ config DEVICE_TREE_DEBUG logged in the Xen ring buffer. If unsure, say N here. +config DEVICE_TREE_DUMP + bool "Dump generated device trees" + depends on DEVICE_TREE_PARSE + help + The device tree Xen generates for dom0/hwdom and for each dom0less + domain is printed on the Xen console in a DTS-like format. + The dump is logged at debug level. + If unsure, say N here. + config SCRUB_DEBUG bool "Page scrubbing test" default DEBUG diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 795b40108774..9f4ef7acc743 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1705,6 +1705,8 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) if ( ret < 0 ) goto err; + device_tree_dump(d, kinfo->fdt); + return 0; err: diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile index 9036e455d66a..730d202349eb 100644 --- a/xen/common/device-tree/Makefile +++ b/xen/common/device-tree/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-bindings.init.o obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o +obj-$(CONFIG_DEVICE_TREE_DUMP) += fdt-dump.init.o obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index 2021838d3830..fcb438c50a04 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include #include @@ -587,6 +588,8 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret < 0 ) goto err; + device_tree_dump(d, kinfo->fdt); + return 0; err: diff --git a/xen/common/device-tree/fdt-dump.c b/xen/common/device-tree/fdt-dump.c new file mode 100644 index 000000000000..0f5176de8b75 --- /dev/null +++ b/xen/common/device-tree/fdt-dump.c @@ -0,0 +1,188 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Dump a flattened device tree blob in a DTS-like format. + * + * is_printable_string() and print_value() are derived from + * util_is_printable_string() and utilfdt_print_data() in the device tree + * compiler (dtc). + * + * Copyright 2011 The Chromium Authors, All Rights Reserved. + * Copyright 2008 Jon Loeliger, Freescale Semiconductor, Inc. + * util_is_printable_string contributed by + * Pantelis Antoniou + */ + +#include +#include +#include +#include +#include +#include + +/* Deeper nodes are still printed, but not indented any further. */ +#define DUMP_MAX_INDENT_DEPTH 32 + +/* Spaces per nesting level. */ +#define DUMP_INDENT_WIDTH 4 + +/* Indentation, in characters, of a node at depth @depth. */ +static int __init indent_of(int depth) +{ + return DUMP_INDENT_WIDTH * min(depth, DUMP_MAX_INDENT_DEPTH); +} + +static bool __init is_printable_string(const void *data, unsigned int len) +{ + const char *s = data; + const char *se = s + len; + + /* A zero length property, or one which isn't NUL terminated, isn't one. */ + if ( (len == 0) || (s[len - 1] != '\0') ) + return false; + + while ( s < se ) + { + const char *ss = s; + + /* + * Xen's isprint() also accepts the characters 0xa0-0xff, while the + * one dtc uses only accepts ASCII ones. + */ + while ( (s < se) && *s && isascii(*s) && isprint(*s) ) + s++; + + /* Stopped on a non printable character, or the string is empty. */ + if ( (*s != '\0') || (s == ss) ) + return false; + + s++; + } + + return true; +} + +/* + * Print the value of a property, using the same heuristics as dtc: a list of + * NUL terminated printable strings is printed as such, a value which is a + * multiple of 4 bytes as a list of cells, anything else as a byte string. + * + * The caller has already started the line (and with it selected the log + * level), so no XENLOG_* prefix may be used here. + */ +static void __init print_value(const void *data, unsigned int len) +{ + unsigned int i; + + /* Empty property, nothing to print. */ + if ( len == 0 ) + return; + + if ( is_printable_string(data, len) ) + { + const char *s = data; + const char *end = data + len; + + printk(" = "); + while ( s < end ) + { + printk("\"%s\"", s); + s += strlen(s) + 1; + if ( s < end ) + printk(", "); + } + } + else if ( IS_ALIGNED(len, sizeof(fdt32_t)) ) + { + const fdt32_t *cell = data; + + printk(" = <"); + for ( i = 0; i < len / sizeof(*cell); i++ ) + printk("%s0x%08x", i ? " " : "", fdt32_ld(&cell[i])); + printk(">"); + } + else + { + const uint8_t *byte = data; + + printk(" = ["); + for ( i = 0; i < len; i++ ) + printk("%s%02x", i ? " " : "", byte[i]); + printk("]"); + } +} + +static void __init print_properties(const void *fdt, int node, int indent) +{ + int prop; + + fdt_for_each_property_offset ( prop, fdt, node ) + { + const char *name; + const void *data; + int len; + + data = fdt_getprop_by_offset(fdt, prop, &name, &len); + if ( !data ) + { + printk(XENLOG_DEBUG "%*scouldn't read property at offset %d: %s\n", + indent, "", prop, fdt_strerror(len)); + return; + } + + printk(XENLOG_DEBUG "%*s%s", indent, "", name); + print_value(data, len); + printk(";\n"); + } + + if ( (prop < 0) && (prop != -FDT_ERR_NOTFOUND) ) + printk(XENLOG_DEBUG "%*scouldn't walk the properties: %s\n", + indent, "", fdt_strerror(prop)); +} + +void __init device_tree_dump(const struct domain *d, const void *fdt) +{ + int node, depth = 0; + /* Depth up to which nodes are open and still have to be closed. */ + int open_depth = 0; + + printk(XENLOG_DEBUG "Device tree for %pd:\n", d); + printk(XENLOG_DEBUG "/dts-v1/;\n"); + + /* + * fdt_next_node() signals the end of the subtree it was started on by + * making the depth negative, and only returns an error when the blob + * itself is malformed. + */ + for ( node = 0; (node >= 0) && (depth >= 0); + node = fdt_next_node(fdt, node, &depth) ) + { + const char *name = fdt_get_name(fdt, node, NULL); + + /* Close the nodes which aren't a parent of the current one. */ + while ( open_depth > depth ) + printk(XENLOG_DEBUG "%*s};\n", indent_of(--open_depth), ""); + + printk(XENLOG_DEBUG "%*s%s {\n", indent_of(depth), "", + (depth == 0) ? "/" : (name ?: "")); + print_properties(fdt, node, indent_of(depth) + DUMP_INDENT_WIDTH); + + open_depth = depth + 1; + } + + while ( open_depth > 0 ) + printk(XENLOG_DEBUG "%*s};\n", indent_of(--open_depth), ""); + + if ( node < 0 ) + printk(XENLOG_DEBUG "The device tree dump is incomplete: %s\n", + fdt_strerror(node)); +} + +/* + * 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/bootfdt.h b/xen/include/xen/bootfdt.h index 0e82ccea2f84..b19e0fa41a1b 100644 --- a/xen/include/xen/bootfdt.h +++ b/xen/include/xen/bootfdt.h @@ -99,6 +99,22 @@ int device_tree_for_each_node(const void *fdt, int node, device_tree_node_func func, void *data); +struct domain; + +/* + * device_tree_dump - print a device tree blob in a DTS-like format + * @d: domain the device tree was generated for. + * @fdt: flat device tree. + * + * The tree is printed at debug log level and is only meant to be used for + * debugging, so it is a no-op unless CONFIG_DEVICE_TREE_DUMP is enabled. + */ +#ifdef CONFIG_DEVICE_TREE_DUMP +void device_tree_dump(const struct domain *d, const void *fdt); +#else +static inline void device_tree_dump(const struct domain *d, const void *fdt) {} +#endif + typedef enum { BOOTMOD_XEN, BOOTMOD_FDT, base-commit: 7168cc02f86fb069da6e7405afbf5c7a1c215b0d -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:32:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:32:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450032.1665534 (Exim 4.92) (envelope-from ) id 1xHGtK-0003qm-K6; Thu, 15 Oct 2026 08:32:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450032.1665534; Thu, 15 Oct 2026 08:32: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 1xHGtK-0003qf-Fq; Thu, 15 Oct 2026 08:32:46 +0000 Received: by outflank-mailman (input) for mailman id 1450032; Thu, 15 Oct 2026 08:32:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHGtJ-0003qZ-5N for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:32:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHGtI-00G2F5-B6 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:32:44 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad08faa-bab6-0a2a0a5309dd-0a2a4505ddea-4 for ; Thu, 15 Oct 2026 10:32:43 +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 6ad08fab-4cb1-0a2a45050019-d1558035cd6d-3 for ; Thu, 15 Oct 2026 10:32:43 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a022fee0caso46959835e9.1 for ; Thu, 15 Oct 2026 01:32:43 -0700 (PDT) Received: from [172.20.10.5] (public-gprs367967.centertel.pl. [37.47.68.160]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1bd972aebsm60166815e9.1.2026.10.15.01.32.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 01:32: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=1792053163; x=1792657963; 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=gfkp/rx1NcV9zNtmUn9U9CHYh3WHt3tivqTxMiqucCo=; b=S1qinhnUANO7Nc6m9x4cTWhYMiIROPOJB+BaX7gWv9X1kmxLSqrWMkpvS6q6uAxD4M adhJLzfIEHMLy8MISVoH+H1TBM1fSrALuv80E1kaA7sdk3YioY0N6SSEDfGyFqHQX5ew w70zOks9MEur2nlTI0c+nw//rDOt/5fDY+LOuUeU0omRZHqs7nT6MqjtWnhGEXlwoKSN AhBUt1d84W/FnSIG4LIEG7uOICfkPf75KfoGpYkMCgmIpLHpfRgtp7LxyMXLLa8ou/TW mEZ56gwbWOupkdneu5Iivfgv3ypRmCDdZLfPoB0gjs5yamH4IK1EKuRBoc/LhnkKULTe lqRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792053163; x=1792657963; 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=gfkp/rx1NcV9zNtmUn9U9CHYh3WHt3tivqTxMiqucCo=; b=gYO9H5bz+grSscARDTTnwzHviTiz6B2GffWhH7Kobu0cqB3eFfkIKUHTsFUTdMzpW/ mq8GRIMhG/JIX3yHduSD1Qs23v/83sMlkCjM+TZBr7diw+KciPKgeqH4Rel+ytPS/iBz Otj5FOEjcDMHVs4ss6mUo84xP4idtGmKDnVYtSiRc/0Db/QvUuRGonORwEPquyjfZpUV PTmUOX9JGnd+VFxFxWr8Umwo9foLuZG5V0Ggycylsxgq0pjrI+dgyXVIDwRsd3PPEdOZ tkOmMXpCy0JrbQdfzbbCuWlKWTTCASGsQa8D4ZCqIWt9OmZe7UJzw1vnRt8MBKhE2Cgh CkEg== X-Forwarded-Encrypted: i=1; AKwUvBw5NX/r7sFbgjJSWdyfGsKiC1ZdkDC9Ec5wAMEefglGgm0lw7bMXObq9apvoSQbWZoF0peoJIViTns=@lists.xenproject.org X-Gm-Message-State: AFq9FYLjXly4ZwhIUGjOQiwwEhIUde/VQF0ZhEa5OmVl5rgtV3StAh9R qaQO9dluK5cEVo8HUR+lQPeao+Q9UWA35WyrDJPX6AF7IUgTeDPs3kiY X-Gm-Gg: AYBFou0lvt3l/U8yhNOvEkxoIZrZ7MzU89tds4m+D2yHruTPH5IRhBoIs3+q8HO/HS7 fNA3z/brqiHKk6SL28oVAloU1DrCkNPDpFesuTDCPgAd9AQbpNMMsNW9IEhxuMjAAzIypaMh/K9 q35Wi1Ne2MY7s0OdI4jKCTFLRdYjx6vsWDOpcz2GwfXUniJiW149lC8vbiOEFq+kEhC2f25cuR8 6AAspP306Kiwy2mJer2ffKOyf90uD6n9o99rh3+4X2pF6XFZMqrI0BQ5rMsKGkmuGePmCV9ouCr Q6pAMSwNyZVrPzC0yGF/cvVl+mAszl1Dao78vLn7LSZM6cffpI08HhfjwRuUWwXcJcbB8OSyLzx bs2PUD1c13chVehmGMsQXgJ33bJ+Y7qsWVyMZ5qEZ3DORQsqAPR3Oa9U11jXcnAGK966nXwt9XG tyBSKq9egaB8JeSJ9k9Rkp8PWLtIaPBiY9Z0fOiIBHUaKmkeEVSoFF3+mfldHiYSGus1NrCMTK6 yLygE6IxXlQppFS05eUUTDMCEOXQTRMnrx/oAo= X-Received: by 2002:a05:600c:4e4f:b0:4a1:ad27:e797 with SMTP id 5b1f17b1804b1-4a1ad27e79cmr166119235e9.6.1792053163316; Thu, 15 Oct 2026 01:32:43 -0700 (PDT) Message-ID: <107edbb0-eba9-4a4a-a1fe-f07d947d47b3@gmail.com> Date: Thu, 15 Oct 2026 10:32:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 09/39] xen/riscv: build the target hart index via aplic_hart_index() 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: <27c8f0bb-4c59-4605-ac61-9a3e5434fc64@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <27c8f0bb-4c59-4605-ac61-9a3e5434fc64@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1792053163-73ABF2A1-6C49B14D/10/73395122804 X-purgate-type: spam X-purgate-size: 1299 On 10/14/26 4:03 PM, Jan Beulich wrote: > On 30.09.2026 18:18, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/aplic.c >> +++ b/xen/arch/riscv/aplic.c >> @@ -335,9 +335,7 @@ static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask) >> static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask) >> { >> unsigned int cpu; >> - uint64_t group_index, base_ppn; >> - uint32_t hhxw, lhxw, hhxs, value; >> - const struct imsic_config *imsic = aplic.imsic_cfg; >> + uint32_t value; >> >> /* >> * TODO: Currently, APLIC is supported only with MSI interrupts. >> @@ -350,27 +348,18 @@ 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; >> + cpu = aplic_get_cpu_from_mask(mask); > > Any reason this can't be the initializer of the variable? There is a > related assertion in between, but as long as the variable isn't otherwise > used ahead of that, such ordering if fine afaict. > Agree, it could be used as initializer. I will do that. thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:41:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:41:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450040.1665542 (Exim 4.92) (envelope-from ) id 1xHH1n-0007N8-CR; Thu, 15 Oct 2026 08:41:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450040.1665542; Thu, 15 Oct 2026 08:41: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 1xHH1n-0007N1-9g; Thu, 15 Oct 2026 08:41:31 +0000 Received: by outflank-mailman (input) for mailman id 1450040; Thu, 15 Oct 2026 08:41:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHH1l-0007Mv-SW for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:41:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHH1l-006XZQ-4u for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:41:29 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad091b0-bab6-0a2a0a5309dd-0a2a45019b42-42 for ; Thu, 15 Oct 2026 10:41:28 +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 6ad091b8-5984-0a2a45010019-d1558036bc19-3 for ; Thu, 15 Oct 2026 10:41:28 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a171b677d2so31281085e9.0 for ; Thu, 15 Oct 2026 01:41: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-4a1bd993caesm110515955e9.12.2026.10.15.01.41.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 01:41: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=1792053688; x=1792658488; 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=QHnVS1PV+1kITi3vkJHQMq0po9DSd1J20l+xScx9FwM=; b=SIefwWY+VWXpVrd3vG0NSlKwjHXAiuWQA6K3KqITbQ4xCVPcicPoPQp39/txKN87nh scKTcq0+jd9oB4TCJVXbZHOq/j9mbfakL4r6MBrekzQAn5uFJXs/L40ID7CXq4Si3Rcb RO2vyo6MlGot+Q7Tau7e0MpuynEVE04ErVFfsmVvKjvsodneJEg4pjYE1n3VjpCwtuWt aZY6fVs45UaSX86h5aMdBeW7JaRiz5B4qClHifyrNcmjJPSID9YEIGYqf0i3W5/uW5TF 9QO5SClz0SbD11V3yCZTg9Nv2NJfcxB6Ci5IUqrMdGIRuo2LbZi3VQl/W4pCePMtApRI 5Htg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792053688; x=1792658488; 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=QHnVS1PV+1kITi3vkJHQMq0po9DSd1J20l+xScx9FwM=; b=U7OzLKl2LRARhas27H0oraGLHKiFlLBClfMrufaNitE400EBN/b6zX9jQs1hs82LOc rQc0eVUUXFQWnmnd70VbrSAA9GtvPXrCmByPZUdNTi30yLgwJ3mTjK/fatBv1+pwdpRv /wrUmYbhZQ9R7dKBmtUifhct4RMri0ZXOh5MN2QCfEzbQ6FYm9ScYsfS5w5tEIJ5+ZD8 oH+E2y3/26DNixZ+QRPnbAt3mfuL2gyxspFHr5e5cwHFduS531WYduCI5UEx4dXjcGx0 NilnSNf68UqY3Rakckl0b7LxFn95vseeiSDhFcwA3hpADMBwO9JivwGGVCj9duqFEB3p AGYg== X-Forwarded-Encrypted: i=1; AKwUvBxqKOceR2MZgni6dtwCorAp18oTraO4VGVdTxlT2oMo189XwfQ1lp4sDYLtrxl6Ih3GQs0nCNGq7eg=@lists.xenproject.org X-Gm-Message-State: AFq9FYIOl9d6RuxcMC+ZrxpRtfiSxaTGDZuYCDiZgT4bb/5OTwZp8lkg 1iQ9S0pV4dtkztgHYgD25h6NLyVxlcnN5XkwTofeyKf9KU31zxebjphbeOkJqyc9ww== X-Gm-Gg: AYBFou3cJFRAKvZMdMit1iLJ6MezgAk2oEVChci/mRMEDRs5K2rDXlXlTSgTWKQSJt+ cnlSgwgr+ArUHRlaktxe0vNNfucupc2et6KArLsJhHpHV8RUxYBqYRmKEVlH43SJGiS9lBD3zNv OJlHJv9auL1KSHCfSRefUJR6f2BdLgQw9SW9rTpq7k1QtFFAYR2sbOYQHMNpVPIOGeCxZ+qKH6+ d8pHIyUC00UoDckKFDINIxUZbkPgHrKSvQPXg5Crpo1pa0JKHx9g9g3KehefXhzgRBMNkriMg0d xkfKBzU+R1Qd7a369z4GrH7pHAAqOkCbp15PxVDhtFF5XQ0P7XdGwjc6daSlkFe4gj+7m6ev7E6 TQ26HJJQiFDjG3iX5U5tE0Fk8/0uEQ37TdT5zrWAGdZ0MnnFe01TUpO1Y3GnAk1EAr795RMS4kI pUlq9n7kaZEQe8E701xWqCnTdcCrqiD8JtVpch5rzD122CvRq3Xrn7LP5g3cmQFlDMT1k5r4TSt 4khDC0UcWv1zDG4YDY/IlnKxnIl6QbGbw6InbInZVKYyK5TZUvsHj7Fl0K1Z5Q= X-Received: by 2002:a05:600c:4ecc:b0:49c:fa21:e749 with SMTP id 5b1f17b1804b1-4a18e4d55f2mr408060295e9.31.1792053688137; Thu, 15 Oct 2026 01:41:28 -0700 (PDT) Message-ID: <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> Date: Thu, 15 Oct 2026 10:41:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@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: <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1792053688-C5540757-65C78283/10/78276251493 X-purgate-type: spam X-purgate-size: 3457 On 15.10.2026 10:28, Baptiste Le Duc wrote: > On 2026-10-15 09:14 +0200, Jan Beulich wrote: >> On 14.10.2026 18:45, Baptiste Le Duc wrote: >>> On 2026-10-14 11:09:58+02:00, Jan Beulich wrote: >>>> On 14.10.2026 11:00, Baptiste Le Duc wrote: >>>> >>>> In which case it would need to be >>>> >>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || >>>> !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) >>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>> >>>> albeit I have to admit that permitting two contradicting extensions to >>>> be exposed at the same time is irritating. >>>> >>>>> I see two ways to address this: >>>>> >>>>> 1) Keep checking Svade: >>>>> >>>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) >>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>> >>>>> After resolve_ad_scheme(), the Svade bit is set in every case where >>>>> software has to preset the A/D bits. The only imprecise case is both >>>>> extensions advertised with hardware updating already enabled by >>>>> firmware, where presetting A/D is unnecessary but harmless. >>>>> >>>>> 2) Record the probe result in a global, e.g. >>>>> >>>>> static bool __ro_after_init hw_ad_update; >>>>> >>>>> and use: >>>>> >>>>> if ( !hw_ad_update ) >>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>> >>>>> This is exact in all cases, at the cost of a new global that mostly >>>>> duplicates what resolve_ad_scheme() already records in the ISA bitmap. >>>>> >>>>> I discussed with Oleksii and we are fine with either. What do you prefer? >>>> >>>> As to 1), see above. For 2), while maybe okay, I think we're better off >>> Sorry, I don't fully follow the issue with 1). Compared to what you proposed, >>> it only differs when neither Svade nor Svadu is recorded, which cannot >>> happen as resolve_ad_scheme() runs before and always records one of the >>> two. >> >> Yet previously we said that recording extensions (as such, i.e. later also >> possibly exposing them to guests) when they weren't really advertised may >> not be the right thing to do. I.e. imo the probing may be used to drive > But we also said that platforms (such as the P550) may implement an > extension without advertising it, as a RISC-V spec maintainer > confirmed in [1]. > > [1] https://github.com/riscv/riscv-isa-manual/issues/3450#issuecomment-6076851535 What Andrew says there suggests to me that the behavior you observe on P550 is against the spec. That shouldn't really be the case though, as nothing was said in the spec at all until Svade and Svadu were actually introduced. An update to the spec should imo never invalidate previously conforming implementations. I guess I'll comment there. >> Xen's internal behavior, but I'm unconvinced that it should also lead to >> marking extensions as available. > > Therefore, as far as I understood, you're not convinced of this: > > /* Neither advertised: trust the probe. */ > __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, > riscv_isa); > > If so, then, the only solution I have in mind in what I proposed in 2) > with the global variable that store the result of the real probe. > Am I correct? Possibly. What I'm missing is some clarification towards the underlying principle which we want to follow not just here. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:45:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:45:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450048.1665552 (Exim 4.92) (envelope-from ) id 1xHH5A-0008He-Va; Thu, 15 Oct 2026 08:45:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450048.1665552; Thu, 15 Oct 2026 08: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 1xHH5A-0008HX-Ry; Thu, 15 Oct 2026 08:45:00 +0000 Received: by outflank-mailman (input) for mailman id 1450048; Thu, 15 Oct 2026 08:44:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHH59-0008HR-3R for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:44:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHH58-006YcF-8k for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:44:58 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad09289-2eae-0a2a0a5409dd-0a2a4504b5e6-4 for ; Thu, 15 Oct 2026 10:44:58 +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 6ad09289-b57f-0a2a45040019-d155dd2dcc61-3 for ; Thu, 15 Oct 2026 10:44:58 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48df8fe8513so81896f8f.0 for ; Thu, 15 Oct 2026 01:44: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 ffacd0b85a97d-48de09693c7sm21677051f8f.4.2026.10.15.01.44.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 01: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=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=1792053897; x=1792658697; 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=IYPnqtd+/baPeKbOuz8zkbnyzx2QS60iP2/pLZfCFQM=; b=MEQcpX8P1waYm3Q+368icXk6zqxDOWeAE6H3Lr2x/GZwH6cO0cz2p6KZk7cpB0fgwI h2lIutV9+W8wkcOPmtKbQiwIsqM3j7bmxFJQpd+aEX4+VByLLyk1Xvt58P7h1YUDKGnM vb2b+Gwd6cCWdvbsUEjFHHmF9tn6Rb3mBeXaRiRNiKAvy/riELxQF/7RAh8+Qnml6iuK Qe1S0MFMetvKNFn0sdLs+J8O0NWn0ZCrtJrqpcEzA7Rlfoi32G2aeiANSy9wXOu518Dw 8veoDlVDe1w+yzAOZMu1yBzsL+13bkY/SaMQFWi7GvNDz0igZEvRV298/J9xJus69QNZ LjVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792053897; x=1792658697; 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=IYPnqtd+/baPeKbOuz8zkbnyzx2QS60iP2/pLZfCFQM=; b=uYOhk5yHv8BOs+7NQoJE0fEIVQCIP5KhhpkGF4NPXSUM7YaQaui/C+yQ4esO4ARDS0 BaUSVBfMaXgTnuMHZVAOyjv3GL7YdF7ez8b6mCPCfS8NB/6F8y1E2OEChBejx+SGgPCX v12s65iGk2ROJoUbsoy4loAb/P9Yf/35wxNCknmP6rq3Rb42JPlmqdzmITRy/WLkgHyJ AIkZD7gz3kNwOoHpCBE1aHkga2Axx1+PPGUbzhl+lgyL25mH7gJFPoBNEIk+D/YHLyoR 7stWlEWLMfX6+ji8Kiov8qLsRGEnWZF0ICAYrsdCW7LImH2CaZVIRLQZ8Oi5gT6qKuH2 +x8Q== X-Forwarded-Encrypted: i=1; AKwUvBzwKHRnQsU3wRlohcVACtDdECcNjkuSnIfajmodlRpeiyzyQrzfnde3sVujXeeRJF3XqneSjwKB8fc=@lists.xenproject.org X-Gm-Message-State: AFq9FYIB29RWk60Eti+TLWqzYXhik1e2PXwjJCKoxbd8kKTXvaTUQ7/8 qeCyfVKBhf14ObL8NXz13A+xVd/xLL0z/3yD/NZ+yD8I1Y+a+f6CXHJdndC6/XIaxg== X-Gm-Gg: AYBFou00tnpuAUAEBthas3/DW3Yel5EQNeSTciOAiP2IB+hUW937XXWx6cRD9oWN5HI gnh9WZMQX9Zs3Rl56FMzEgS8Y8aKjMZOsIBDF1yC48qqKDl2mhanklFzaTOVcL1PcFy64VSUub9 /HqGkRAgnyngil53scd30jVSfwnEl1dbur9ECKzANFall0WAtRFtdehBpff9p8lk2Lg6ehrctpp AjMF5B/+0Te6OR11mFm8BzvDbnauti+5GDKiie18GTLJu6oahlXqJp1YhJGk2MfqDLJylpNq96q e7IHIjTMm7WxKCyv99VTOfClALvct1IXo59W9So3OHyRQfYoUuWz1GAggmB5gTqVbMu3uZom2OE K7jtA+ri5F544PJAeXfjC+hRN/DebDEHzlMzZ2fgwTSJv1/3QVoZF88wCC0ZBdYDa5iKTMZWnby CKM5xt72Q4pO8NAQxguKIP0V8z7mEBdttIb3BCTpmMuvOAQTPVNdnbA4/VEl0oll+VwKJpENbzJ 8sqqRXwqfeyf6IHH1n2edY2diKtS9HlQtYW3sLfC9ytiKmCGh8t8s5mCbJ0aQ== X-Received: by 2002:a5d:588e:0:b0:48a:fcf9:acb5 with SMTP id ffacd0b85a97d-48dba787752mr35296898f8f.2.1792053897427; Thu, 15 Oct 2026 01:44:57 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 10:44:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Jan Beulich To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@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: <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1792053898-C2CCFB50-57D91A81/10/78276251493 X-purgate-type: spam X-purgate-size: 2767 On 15.10.2026 10:41, Jan Beulich wrote: > On 15.10.2026 10:28, Baptiste Le Duc wrote: >> On 2026-10-15 09:14 +0200, Jan Beulich wrote: >>> On 14.10.2026 18:45, Baptiste Le Duc wrote: >>>> On 2026-10-14 11:09:58+02:00, Jan Beulich wrote: >>>>> On 14.10.2026 11:00, Baptiste Le Duc wrote: >>>>> >>>>> In which case it would need to be >>>>> >>>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || >>>>> !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) >>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>> >>>>> albeit I have to admit that permitting two contradicting extensions to >>>>> be exposed at the same time is irritating. >>>>> >>>>>> I see two ways to address this: >>>>>> >>>>>> 1) Keep checking Svade: >>>>>> >>>>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) >>>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>>> >>>>>> After resolve_ad_scheme(), the Svade bit is set in every case where >>>>>> software has to preset the A/D bits. The only imprecise case is both >>>>>> extensions advertised with hardware updating already enabled by >>>>>> firmware, where presetting A/D is unnecessary but harmless. >>>>>> >>>>>> 2) Record the probe result in a global, e.g. >>>>>> >>>>>> static bool __ro_after_init hw_ad_update; >>>>>> >>>>>> and use: >>>>>> >>>>>> if ( !hw_ad_update ) >>>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>>> >>>>>> This is exact in all cases, at the cost of a new global that mostly >>>>>> duplicates what resolve_ad_scheme() already records in the ISA bitmap. >>>>>> >>>>>> I discussed with Oleksii and we are fine with either. What do you prefer? >>>>> >>>>> As to 1), see above. For 2), while maybe okay, I think we're better off >>>> Sorry, I don't fully follow the issue with 1). Compared to what you proposed, >>>> it only differs when neither Svade nor Svadu is recorded, which cannot >>>> happen as resolve_ad_scheme() runs before and always records one of the >>>> two. >>> >>> Yet previously we said that recording extensions (as such, i.e. later also >>> possibly exposing them to guests) when they weren't really advertised may >>> not be the right thing to do. I.e. imo the probing may be used to drive >> But we also said that platforms (such as the P550) may implement an >> extension without advertising it, as a RISC-V spec maintainer >> confirmed in [1]. >> >> [1] https://github.com/riscv/riscv-isa-manual/issues/3450#issuecomment-6076851535 > > What Andrew says there suggests to me that the behavior you observe on P550 > is against the spec. Or wait - no, he doesn't. He said this only to the strange combination you had indicated. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450055.1665561 (Exim 4.92) (envelope-from ) id 1xHH9x-0000p5-GO; Thu, 15 Oct 2026 08:49:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450055.1665561; Thu, 15 Oct 2026 08: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 1xHH9x-0000oy-Co; Thu, 15 Oct 2026 08:49:57 +0000 Received: by outflank-mailman (input) for mailman id 1450055; Thu, 15 Oct 2026 08:49:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHH9w-0000os-IQ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:49:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHH9v-006ZYe-NX for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:49:55 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad093a7-2eae-0a2a0a5409dd-0a2a45059d64-20 for ; Thu, 15 Oct 2026 10:49:54 +0200 Received: from [159.226.251.81] (helo=cstnet.cn) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad093af-4cb1-0a2a45050019-9fe2fb51b9a8-3 for ; Thu, 15 Oct 2026 10:49:53 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-03 (Coremail) with SMTP id rQCowAD3AkGpk9BqbRbUCg--.1928S2; Thu, 15 Oct 2026 16:49:46 +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, 15 Oct 2026 16:49:52 +0800 From: Zhang Zheng To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini Subject: Re: [PATCH v2 2/2] xen/ns16550: drain TX before reinitializing Message-ID: References: <20261010031406.2057735-1-zhangzheng@iscas.ac.cn> <20261010031406.2057735-3-zhangzheng@iscas.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CM-TRANSID:rQCowAD3AkGpk9BqbRbUCg--.1928S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ZF1UuF1fZrWkKr47ur4rZrb_yoW8uFyfpF W5KFZ0kr4DJr42gw12q3WIq3y2qr15Ca4UWrn5G3ySvFWqkr45AF1agrWY9FWkZr4kJr12 yF1I9asxXw1Yvw7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvlb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jw0_WrylYx0Ex4A2jsIE14v26r4UJVWxJr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7 MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r 4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF 67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2I x0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2 z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVjvj DU0xZFpf9x07befHbUUUUU= X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-c201ff/1792054194-71EA92A1-722A38DE/0/0 X-purgate-type: clean X-purgate-size: 2338 On Thu, Oct 15, 2026 at 09:54:46AM +0200, Oleksii Kurochko wrote: > > > On 10/15/26 8:44 AM, Zhang Zheng wrote: > > On Mon, Oct 12, 2026 at 12:20:50PM +0200, Oleksii Kurochko wrote: > > > > --- a/xen/drivers/char/ns16550.c > > > > +++ b/xen/drivers/char/ns16550.c > > [...] > > > > > + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) ) > > > > + cpu_relax(); > > > > + > > > > > > IMO waiting for TEMT rather than THRE is the right choice: besides > > > resetting the FIFOs, ns16550_setup_preirq() reprograms the divisor and > > > LCR, which would corrupt a character still being shifted out. (Linux > > > waits for UART_LSR_BOTH_EMPTY, i.e. THRE | TEMT, but on a 16550 TEMT > > > already implies THRE.) > > > > > Yes, I followed the Linux implementation, which waits in an unbounded loop > > and theck UART_LSR_BOTH_EMPTY like you said: > > > > for (;;) { > > status = serial8250_early_in(port, UART_LSR); > > if (uart_lsr_tx_empty(status)) /* checks UART_LSR_BOTH_EMPTY */ > > break; > > cpu_relax(); > > } > > > > So I didn't have timeout handling > > > The unbounded wait can hang early Xen boot if the UART never reports TEMT > > > for some reason(?). Bounding the wait would make console initialization more > > > robust, allowing boot to continue when the UART is unavailable > > > > > > for ( i = 0; i < 50000; i++ ) > > > { > > > if ( ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT ) > > > break; > > > udelay(10); > > > } > > > > > > would need udelay() on RISC-V, which is still a BUG_ON() stub, so a > > > separate patch would be needed for that. On x86, udelay() doesn't delay > > > yet at this point (cpu_khz is only set by early_time_init()), so there > > > the loop would just be an iteration count. Perhaps someone has a better > > > idea of how to implement a timeout here. > > > > > > ~ Oleksii > > > > > Leaving aside the unavailability of udelay() at this point, is a timeout > > considered necessary here? > > In the way Jan B. mentioned here: https://lore.kernel.org/xen-devel/20261010031406.2057735-1-zhangzheng@iscas.ac.cn/T/#meaf24c3bb039dc6aaecffab752d2b107581816e0 > > I think we still can have timeout check. > > ~ Oleksii I saw it afterwards. Thanks. Zhang From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:58:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:58:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450064.1665569 (Exim 4.92) (envelope-from ) id 1xHHHz-0003TH-89; Thu, 15 Oct 2026 08:58:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450064.1665569; Thu, 15 Oct 2026 08: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 1xHHHz-0003TA-56; Thu, 15 Oct 2026 08:58:15 +0000 Received: by outflank-mailman (input) for mailman id 1450064; Thu, 15 Oct 2026 08:58:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHHHx-0003Ry-KD for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:58:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHHw-008Bb1-QU for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:58:12 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad09596-bab6-0a2a0a5309dd-0a2a4509af6c-38 for ; Thu, 15 Oct 2026 10:58:12 +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 6ad095a4-be1a-0a2a45090019-d155802da577-3 for ; Thu, 15 Oct 2026 10:58:12 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a1af482519so21896065e9.1 for ; Thu, 15 Oct 2026 01:58: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-48defca4013sm7523858f8f.9.2026.10.15.01.58.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 01:58: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=1792054692; x=1792659492; 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=svpR+ifPquhooBA3NqazjI5lv4fVAP9vS9RJs4wRSD0=; b=BzxnH3yDhCM+KdnfDPG5TpteqNy9VMf2ntW05L0rjILXQt0g2EVjc9kVujD4RmaenM Tmx5bynZhG0v8IFqb592UEJTJ8eKIsfjFKxhUeihkzKTLVCD94VwUlz1Xpu62usgZ76d 83PYSZvRylHaXfLwewq0Q3PdjRm2SpQWmABH2kAmkSkbNkcExW/ui/EzbkQP8Y6Ddbit 17W/fFrMwKxYAUXT/w2CLZeeCtg7jjW7jAmmIF4VD3vy0ZC51YclKVbmSVG5WAD8f1R3 5hROBpoo0RgFRBlk1kaujd33BTaoaLlsuGt/1D0n38siGbANYuxE3vk9NAG4wA5qVBB/ dGbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792054692; x=1792659492; 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=svpR+ifPquhooBA3NqazjI5lv4fVAP9vS9RJs4wRSD0=; b=DzW6tibCiZ3d72Q3Rc4MXGOPml2R9sXB7XgEoNfNt2qtbapwvj1LdqrkTiNwCF45CC Q4PcrWo5sFW6m03q7nSILdMJwrHgIThWq0IL7QvEN+eQQSQrKYdyKq0SG90RVqeOotWk FTeeJwf2DeGCcd2xM1nLE50jfhH/r72GPPeyHKPk0bk4Hcxi195Sr/EtzZI3jcHV5fV3 G7GzP+xb4xPxk/O+8cOL8LmgF0Zoe2nrin7EtCeFxrneazFo7WPuCveKBq8OkJ4ac50g 7LdO4ycYfhjzG1VI+J6w3hVbsfSJC/T79Kigrf4/QnCoSdvShFaXccNR+c2fvRsjEQJ7 D+2A== X-Forwarded-Encrypted: i=1; AKwUvByEriBhg63GfWdl3n2sIEuNp+PfjvdWJg4inQIKx1mkM620edPbb+kBrVOzimZ0nBM5RC+SKNFco88=@lists.xenproject.org X-Gm-Message-State: AFq9FYJYIGpC3uVpLL9bhTaYwiNm8bvLYlcsry7aUQGWelR3bqTlohWZ bU1VfNziiDxJHNeFaltOwQwKHGOssNN5Sn12BtRtY3yBtCBWarVTLe4Kep+SCdC+hw== X-Gm-Gg: AYBFou3Tt5O+sqKKt5rsHOOvgiksi8NKuEQeVcZ3vWR1arTLCXcNlfTli5cH71TNXlS N5aqIifIFp2wOr4JN7wv8I8FHPe0lG3x06PhkeDyn/zDx5aKzDrxXXZObQkwSCZkkLO8Pzes337 VgzMqCIEaSZ9sPE2WhXQbpX/F1bykPPPi1F3zoWbXnVrlHkSVS8iGdUFGNNbsiMPIyLnPJt3Kij s0+LQWNKES36um7GlmUGmL7HuKlnd5YpFTw0hYP1CAk8BL41o7phOubwW/qLTSOBuYCQVus4jia /nMSaw7GAzVi1F57ZE6ZClEfsAEEe7TUEmnRrENqVsQfLP/3pGyVsKfts9mTbB76XQrZ5SCxAHL vXw31rtZEdxtDvF/VC/yqtI0Uxl82xu2DHY5InrYqfgsvjzO+xL/f6JF9b29L1hdWBonHkYoCIT HEeViXUQkRllCocP4jD3A9xsy2BKI4T25V4egZ14s5MdZnUeLuZ8bfTWTc42slr8Ifg3GXHo2+X TrOSLlg0Bl5O/cYZpxALMXRKq1ohZqZOJ/XvdV7cLAx33LEkpu7/0UcfR/EVyU= X-Received: by 2002:a05:600c:58d3:b0:4a1:9388:7f40 with SMTP id 5b1f17b1804b1-4a193888295mr235604665e9.4.1792054691754; Thu, 15 Oct 2026 01:58:11 -0700 (PDT) Message-ID: <310eb5cc-cf04-42df-9005-84f1e3496156@suse.com> Date: Thu, 15 Oct 2026 10:58:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/atomic: Fix UB on various atomic helpers To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261014133551.622462-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1792054692-3AAD8034-BD1AC574/10/78276251493 X-purgate-type: spam X-purgate-size: 1885 On 14.10.2026 17:38, Alejandro Vallejo wrote: > On Wed Oct 14, 2026 at 4:33 PM CEST, Jan Beulich wrote: >> On 14.10.2026 15:35, Alejandro Vallejo wrote: >>> --- a/xen/arch/x86/include/asm/atomic.h >>> +++ b/xen/arch/x86/include/asm/atomic.h >>> @@ -122,7 +122,7 @@ static inline void atomic_add(int i, atomic_t *v) >>> >>> static inline int atomic_add_return(int i, atomic_t *v) >>> { >>> - return i + arch_fetch_and_add(&v->counter, i); >>> + return (unsigned int)i + arch_fetch_and_add(&v->counter, i); >>> } >> >> I'm concerned seeing this kind of change: It's merely papering over an >> issue in the caller. There's not going to be UB if the caller passes >> suitable values. And the atomic types hardly are meant to be used in >> contexts where overflow could occur. >> >> Furthermore different parts of the C spec say different things here [1], >> [2]. Hence whether overflow in signed calculations is undefined or >> implementation-defined doesn't become entirely clear, according to my >> reading. > > I won't dwell on interpreting the standard, because I only care how > GCC and Clang developers interpreted it; and that's a hard trap on > signed overflow with sanitisers enabled. > > I can live without this patch (it's just paranoia), but thinking about > it some more, perhaps we ought to pass -fno-strict-overflow, like Linux > does, to the compiler. This brings forward post-C23 overflow semantics > and removes this whole class of UB wholesale. Here and elsewhere. > > Thoughts? Doing so sounds dangerous for an existing code base, as in risking to hide real issues. As said in the earlier reply, atomic_t uses very likely are intended to never overflow. If there were use cases, we may need to introduce uatomic_t (the unsigned counterpart that you mentioned as an option to _convert_ to), to be used there. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 08:59:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 08:59:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450068.1665579 (Exim 4.92) (envelope-from ) id 1xHHJB-0004Ff-Gw; Thu, 15 Oct 2026 08:59:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450068.1665579; Thu, 15 Oct 2026 08:59: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 1xHHJB-0004FY-E2; Thu, 15 Oct 2026 08:59:29 +0000 Received: by outflank-mailman (input) for mailman id 1450068; Thu, 15 Oct 2026 08:59:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHHJA-0004FO-3i for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 08:59:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHJ9-00EFkk-Gt for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:59:27 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad095e8-8faa-0a2a0a5109dd-0a2a450ada92-0 for ; Thu, 15 Oct 2026 10:59:20 +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 6ad095e7-f2d2-0a2a450a0019-b9ff1c23b167-3 for ; Thu, 15 Oct 2026 10:59: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 1a13ec98bdf0008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 15 Oct 2026 08:59:18 +0000 Received: from [172.20.10.2] (132.169.185.81.rev.sfr.net [81.185.169.132]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 1A3AC81CB1; Thu, 15 Oct 2026 10:59: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=VARcOfLTeWlbOvfvhdqzsqom5lHcL9d/9E9y3iaJnfs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=RZlb0KnnDAadKhA8b15agaKx0XDNi4ZBk1JBthOIHQNeZEhOb7m2dMsKWb5g7tcPeNGUJPXv3 TBJdlbkVrTsoxU747l3tYsdBAaW1xVhGzEJIpyCGDC5hkyi72ZdpGSYz3JiGCzxgt53JqST0Rs8 F5X5srIYL9+0/O+JZMFqevZmTpmTAIF/a/zHqOn1uE7iqmV/h82Jt683H/Erhsb7mxJCbzdb4rH 1hGCzf131q2h0buvex50UGmqBgBmiiiVK7mGsr0O8JSITp7iyrr01dI8TnHc6nMuGTliY3J4FBx UU3Uyz9Nqz7RV9AFdcVLSNt48ifvrUtnoz0wuGD9Hcmg== X-Zone-Loop: 7f174ba33ab612c8c251a64cc837d4125383484e2c8a x-campaign-type: default x-transaction-id: 638795d6-5a0d-4551-9f9f-f882b3b0ff33 x-swg-uid: 01-06d03f37-6c20-496d-addf-0ef76008c835 X-Mailer: Sweego Message-ID: <1792054758.8631fc262581453bbf619ec5b2062170.1a13ec98bdf0008425@vates.tech> x-swg-bid: 1792054758.8631fc262581453bbf619ec5b2062170.1a13ec98bdf0008425 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 v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org In-Reply-To: References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> Date: Thu, 15 Oct 2026 10:59:11 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792054751; l=3155; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=YBZ+vLY6zIYYlF92kEMpiFNfDkGThWtH8Lj8Dtr5o4I=; b=icCo9yumL008xu05SLG4+E9wu+m3+U3T7UUAs44bHLvD8DhDOtg8VLg79JjWpJW2Fpx44FgiN NJ07CN4PlTKCC+4esxdJ3Mtc2B7uqtfzNBlESJtkqtxD2uhfYtCKXc9 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: 1792054757575 X-purgate-ID: tlsNG-4011c0/1792054760-50ACCCFC-144CC924/0/0 X-purgate-type: clean X-purgate-size: 3155 On 2026-10-15 10:44 +0200, Jan Beulich wrote: > On 15.10.2026 10:41, Jan Beulich wrote: > > On 15.10.2026 10:28, Baptiste Le Duc wrote: > >> On 2026-10-15 09:14 +0200, Jan Beulich wrote: > >>> On 14.10.2026 18:45, Baptiste Le Duc wrote: > >>>> On 2026-10-14 11:09:58+02:00, Jan Beulich wrote: > >>>>> On 14.10.2026 11:00, Baptiste Le Duc wrote: > >>>>> > >>>>> In which case it would need to be > >>>>> > >>>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || > >>>>> !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > >>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; > >>>>> > >>>>> albeit I have to admit that permitting two contradicting extensions to > >>>>> be exposed at the same time is irritating. > >>>>> > >>>>>> I see two ways to address this: > >>>>>> > >>>>>> 1) Keep checking Svade: > >>>>>> > >>>>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > >>>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; > >>>>>> > >>>>>> After resolve_ad_scheme(), the Svade bit is set in every case where > >>>>>> software has to preset the A/D bits. The only imprecise case is both > >>>>>> extensions advertised with hardware updating already enabled by > >>>>>> firmware, where presetting A/D is unnecessary but harmless. > >>>>>> > >>>>>> 2) Record the probe result in a global, e.g. > >>>>>> > >>>>>> static bool __ro_after_init hw_ad_update; > >>>>>> > >>>>>> and use: > >>>>>> > >>>>>> if ( !hw_ad_update ) > >>>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; > >>>>>> > >>>>>> This is exact in all cases, at the cost of a new global that mostly > >>>>>> duplicates what resolve_ad_scheme() already records in the ISA bitmap. > >>>>>> > >>>>>> I discussed with Oleksii and we are fine with either. What do you prefer? > >>>>> > >>>>> As to 1), see above. For 2), while maybe okay, I think we're better off > >>>> Sorry, I don't fully follow the issue with 1). Compared to what you proposed, > >>>> it only differs when neither Svade nor Svadu is recorded, which cannot > >>>> happen as resolve_ad_scheme() runs before and always records one of the > >>>> two. > >>> > >>> Yet previously we said that recording extensions (as such, i.e. later also > >>> possibly exposing them to guests) when they weren't really advertised may > >>> not be the right thing to do. I.e. imo the probing may be used to drive > >> But we also said that platforms (such as the P550) may implement an > >> extension without advertising it, as a RISC-V spec maintainer > >> confirmed in [1]. > >> > >> [1] https://github.com/riscv/riscv-isa-manual/issues/3450#issuecomment-6076851535 > > > > What Andrew says there suggests to me that the behavior you observe on P550 > > is against the spec. > > Or wait - no, he doesn't. He said this only to the strange combination you had > indicated. For me, he clearly answered your question before: `Implementations that trap when A/D bits are not set do implement Svade, whether or not they explicitly say they do.` -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:08:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:08:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450077.1665588 (Exim 4.92) (envelope-from ) id 1xHHRZ-0007Ay-DC; Thu, 15 Oct 2026 09:08:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450077.1665588; Thu, 15 Oct 2026 09:08: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 1xHHRZ-0007Am-AL; Thu, 15 Oct 2026 09:08:09 +0000 Received: by outflank-mailman (input) for mailman id 1450077; Thu, 15 Oct 2026 09:08:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHHRX-00078Y-Un for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:08:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHRX-00G9aN-3q for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:08:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad097f2-e002-0a2a0a5209dd-0a2a450adf16-36 for ; Thu, 15 Oct 2026 11:08:07 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad097f6-f2d2-0a2a450a0019-d155dd35c01f-3 for ; Thu, 15 Oct 2026 11:08:07 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48b042c0759so3702479f8f.2 for ; Thu, 15 Oct 2026 02:08: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-48de0ac37acsm17406299f8f.34.2026.10.15.02.08.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 02: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=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=1792055286; x=1792660086; 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=rmY6RMTwWmvPvdqvm6YNXVFC8rzWA37Z4pzMneAPBDc=; b=UXKWFvQEaF7o2vbIR+D8UfuONAA7Grt1Vu1Rq4cTQPsmQb98W/9vvccGWRpt9K6TZy wW8HPheN15RP0uwmM02fuDs6mUlp+wPegzxpiuz0LoCIRcouX4u6fUvSnN8BRAnOhQsF qP+6FVhVJPRGrP7McBikC7m/Xvk5IKzskSmbkayrIqr+1uuOUB0n5bPgNN6QSfjYK6Wn PVVK+odR3otnhvThSpQ3l7Pu2XWlqewlcFamATMTXtQlScTeexdf+hScd8KyzGiNaTw9 WVE6B6x7LMvIWQLe/SngQI1DNy/PnVanqGjOp+hn0qZuEon4MMpdGyp3rRxKgv45NJyR ZJkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792055286; x=1792660086; 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=rmY6RMTwWmvPvdqvm6YNXVFC8rzWA37Z4pzMneAPBDc=; b=prGMjBH2ARoepZNtKMhW3T43rKlce3vzT1Lgqc0IfdmkTf9bBmxHp+TaGVYwRMsG4v Nmns5YdOFRYWT4hddA6XSNEoG2xMIOVklHNxzL4tHNbqzJ1HJt8FqviMQsbGgGGIzRcF LYGLzxViWP8JrmL03gACGXiRoxfiyuCpjZOq8xWxA/n3L5mP91qs4haeT63beaqkC89d H0/cudWOYMeczuEl5l/n2HdZdq//+sfij2Diwyhi6GlDFr3NdXOSA9SV5gtXEId9MOV2 jDfiok+nRdzgeXCf4PwUKo7pSnM6jE3n79uYntcsb79wQHrwBFHdaAYO6oB9HVIZGo3T sCDg== X-Gm-Message-State: AFq9FYLB0gKlX6QG6QA0/QYm8XTZXwl8NQ3hxQK6cveP8fk2Vho9l39N 7pZ1Q2dWdexMhWIR83dCCzkMN5hpa36u+ADC6yYyKug4kcLm88hzWBy3fmPk7Cl9Usyxgxfx5Vp QwI2cmA== X-Gm-Gg: AYBFou25IpaN0XNH8HxTKpeGPII4L9crA/m9ni9FDybM7X8f6btan+IUf5yRfAXY7IM n4q8tivgCfx+0kCJ69hsJh6gdwatdmx65Ik4MzBi9L2PAV2R1t4Kgc/BMK/Gowcuu88dHKLSe9D FOoiFvi970N5Hs8Dld0Zq7DEOTpywjHiYv4MoAHQWMZKrDXBlT2uVZ9aOy+bTMeMghG71AAqX0D s9JAWlPjiINhHVkW3p/WlpgdtmMQYrLum+uc1dXv+yFg9g3sgK1HUG/MsS0h2dwllRYcU6Ckdtx mx7VwY16Wozqilj6bLE7OgsLMeTQtIUIaBUaf/bpIe71TF9CkKg8vguzYRAQ7klGqtWmhbiT3aR go8ZGwJ68TyB9Q+k0Hv+E/WMECDzfm7RyEazY0Cv6yNvN4aUZalTorYCCn4fvnwaTdYRvAafpQB TSAl80f60P/9KU0gTyiDyKVugTGEIH1//lQ9t/cTZGSgZaDgA5qv4nGs6f1dJ8qQGrIg5zIpIjc DQDZQhSGDSafCbxcSIxvKU5rgNogm1rrImILSLlbinvtPau+JD7OsTVjPJhPs50 X-Received: by 2002:a05:6000:29c3:b0:48d:c15c:94a5 with SMTP id ffacd0b85a97d-48dc15c964amr24245377f8f.14.1792055286096; Thu, 15 Oct 2026 02:08:06 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 11:08:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v4 0/3] x86: allow Kconfig control over psABI level To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk 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-4011c0/1792055287-50CCBCFC-B33B3100/10/78276251493 X-purgate-type: spam X-purgate-size: 368 As discussed in Prague. v4 drops the apparently controversial patch "build: permit Kconfig control over how to deal with unsatisfiable choices" and updates things now that gcc5 is our baseline. 1: allow Kconfig control over psABI level 2: use POPCNT for hweight() when available 3: short-circuit certain cpu_has_* when x86-64-v{2,3} are in effect Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:10:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:10:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450084.1665597 (Exim 4.92) (envelope-from ) id 1xHHTL-00086r-N2; Thu, 15 Oct 2026 09:09:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450084.1665597; Thu, 15 Oct 2026 09: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 1xHHTL-00086k-Jw; Thu, 15 Oct 2026 09:09:59 +0000 Received: by outflank-mailman (input) for mailman id 1450084; Thu, 15 Oct 2026 09:09:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHHTJ-00086Z-LS for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:09:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHTJ-006f9K-2B for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:09:57 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0985e-bab6-0a2a0a5309dd-0a2a450ab7d4-16 for ; Thu, 15 Oct 2026 11:09:56 +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 6ad09864-f2d2-0a2a450a0019-d155802ce43a-3 for ; Thu, 15 Oct 2026 11:09:56 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a17baef589so16282335e9.0 for ; Thu, 15 Oct 2026 02:09: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 ffacd0b85a97d-48de0bc50e0sm23382287f8f.49.2026.10.15.02.09.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 02:09: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=1792055396; x=1792660196; 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=FfAytH9CoSsG/4JADULfMO0l9a68bQmjhOGtCcq3NAA=; b=Qhazoehu8wvdjyV5UZzIK/akNa2WTK7B4puZhUEbYlJqYZ1WUt8YUeiVRYxcjfeQkI FdyAJbGGUUCetuFUYWfJ8gXf9Rjha0R+o5jonpI3FKpCOUlzCAQOLv5yxUhgTgRz3ZLs yeGwwg//T0hY8Q4Rrdh9xXwrg6kMJB4PSxvgH6qaWZsJL9kZohJjrWZciKZt9uyPJryF wNFV0hZdq2f/JKHHMtsq42EftVceekRKWfHZqOkNhlK4x4kjxwjqVYv5eZ+GWvK0L+ur 4YbRfRrWJbBDpuuhmAsbAUbiWCv1Ungmogdxiz9pgd6xCOLF9u+JHEaeaWhger/uzmm6 2szQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792055396; x=1792660196; 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=FfAytH9CoSsG/4JADULfMO0l9a68bQmjhOGtCcq3NAA=; b=ytFHv8V3fvTcX2UlFk1jw5ZnCWP5oRLwDfw44ueh1+WNTwN8lI3Pq1mGJwbZGOyK9r k2C0J88LaiFRWY7luFe1Bp5nNRmdQzS6fJBow2kmwT2JCXGO9ZBpE/qWm77ZiHvnbsNh 6k6MqxLnluYoak/bWH5Eran5jlhmkPB0Z3kbn2j1fzuYdcv+wnRTr8VXlWXxJrTlGPM0 Leve0ngVDvsctaz+ByvNg1X0qHlU3et0Yxa2TYSDqn9vzxrpGfa2dgO+aTQtqPJUlWvt mSGuUg0Ot0YNmeu7WWVBz1CL5YX3fsdeo5bkcBWRXNUzcgcx+gXdyslRFqg53SiFJHaB GcdA== X-Gm-Message-State: AFq9FYLljtyYKbGvwK9eXYSQljaOK8xMjFnp2ndWcA14dMAj3pnx+cRY Arqgqtpw8ABjMofXUCjKG6vP/cPxqgTciQh43SUA0IcRIkSikfLdLt205JIdPf8sbsn0yoJTITr C0LC5Xw== X-Gm-Gg: AYBFou2ynX9E8FOECapOKcuGmUp+Dm1vhyAoTMHEtMQfZFxCJV3s52FjoPKotHgEU8F 6dUIW+gJAccKsCYSF95YPalcQ7j5srecWhz5qRC0a5o7X6CWocN27ylgZvGHcrZr3c12riTgfwC 1M9HA24os9KT4hauOI87YuERTyKNdisILS9QRwJ3e+iwYQGQyGFa3EDweiafrsuJZ/Bey/BfCQ2 mKaKjeakE1d5NvFDMCQ9IDAfldIyiclH45DQaAi4Ghr3/SGNe94hH8pZL/IJVRBtPyN98gNOab9 niCpi5x/DILebyHGIJuNsY9J3m26sC8UkXseH+qXD6Em8tq2rVDTFZNRFnbwjGumdR+fUdyKULE fG+3QZ8y0qxwzU2wnUXFrCZyihtZTYLKnuJiSaAP5tdQChiIuP02kZ5nwqLPjgYtbRXciD+IK28 8VyqDfewX95dvAgNCx1caLGh1aF5myE1tZnBxlcjvND4kDz/UwTgU7xDfD0Xa1ki7unCOnOQqgz Vn6g6PuBRd/xGGWJs+BrfVMhiMu9apdTTGoemzzoad5nPNxadrFUwyMmFUVYA== X-Received: by 2002:a05:600c:818d:b0:4a1:6c79:fd31 with SMTP id 5b1f17b1804b1-4a18e483231mr358300555e9.12.1792055396258; Thu, 15 Oct 2026 02:09:56 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 11:09:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v4 1/3] x86: allow Kconfig control over psABI level to use From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk 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/1792055396-5A3DCCFC-D6A4BF8D/10/78276251493 X-purgate-type: spam X-purgate-size: 10756 Newer hardware offers more efficient and/or flexible and/or capable instructions, some of which we can make good use of in the hypervisor as well. Allow a basic way (no alternatives patching) of enabling their use. Of course this means that hypervisors thus built won't work anymore on older, less capable hardware. Since older compilers (apparently gcc10 / clang11 and older) won't recognize -march=x86-64-v2 etc, also add fallback logic passing -mpopcnt and alike explicitly. Note that in efi_arch_cpu() the filling of 7c0 and 7d0 are forward- looking; we only require 7b0, but we need to use cpuid_count() anyway. Signed-off-by: Jan Beulich --- TBD: While the added assembly code goes strictly from the CONFIG_* settings, EFI code uses the compiler provided manifest constants where available (just like the subsequent "x86: short-circuit certain cpu_has_* when x86-64-v{2,3} are in effect"). While I generally prefer it that way, this comes with a downside: If we ever started to use one of the ISA extensions in assembly code (and then keyed to the CONFIG_* settings), things could break. I don't view us doing this as very likely though, as then we'd need to have two (or more) variants of such assembly code, which we would likely want to avoid. (What I'd like to avoid is using the compiler manifest constants in assembly code: In principle we ought to filter out any -march= when constructing AFLAGS, and perhaps at least all -m... and -f... options. Compilers might rightfully complain about their use as inapplicable, much like we've seen for -Wl,... when no linking is done.) TBD: While we don't document most "cpuid=no-*" options (and hence imply their use to be unsupported), using e.g. "cpuid=no-popcnt" with a V2=y hypervisor clearly can't have the intended effect, and hence might perhaps better be flagged in some way. TBD: v2 also includes LAHF/SAHF. Since we don't use floating point and hence FPU insns, we ought to be okay not explicitly checking for it. But there is a certain amount of risk of the compiler finding some "smart" use for one or both of the insns. However, if we were to check the feature, we'd need to account for the quirk that init_amd() also works around. Whereas the baseline -> v2 step isn't much of a difference (we'll gain more there by a subsequent patch), v2 -> v3, while presumably (or shall I say hopefully) faster, yields an overall growth of .text size by (in my build) about 2k. The primary reason for this appear to be conversions of SHL-by-immediate to SHLX. The VGA output attempt in early (MB/MB2) boot code does not appear to work (anymore?). The serial output may work, but only if - without any setup in Xen - both sides agree on the serial settings (baud rate etc). Hence the feature checks added on the legacy paths are of limited use. --- v4: Correct __LZCNT__ check in efi_arch_cpu(). Drop CONFIG_UNSATISFIED_* part. Simplify logic in arch.mk, now that gcc5 is our baseline. Reduce code size in trampoline_setup. Re-base. v3: Add fallback logic and use logic from new prereq change. v2: Also cover XSAVE. Add early boot feature checking. --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -116,6 +116,36 @@ config PV_LINEAR_PT If unsure, say Y. +choice + prompt "base psABI level" + default X86_64_BASELINE + help + The psABI defines 4 levels of ISA extension sets as a coarse granular + way of identifying advanced functionality that would be uniformly + available in respectively newer hardware. While v4 is not really of + interest for Xen, the others can be selected here, making the + resulting Xen no longer work on older hardware. This option won't + have any effect if the toolchain doesn't support the distinction. + + If unsure, stick to the default. + +config X86_64_BASELINE + bool "baseline" + +config X86_64_V2 + bool "v2" + help + This enables POPCNT and CX16, besides other extensions which are of + no interest here. + +config X86_64_V3 + bool "v3" + help + This enables BMI, BMI2, LZCNT, MOVBE, and XSAVE, besides other + extensions which are of no interest here. + +endchoice + source "arch/x86/hvm/Kconfig" config XEN_SHSTK --- a/xen/arch/x86/arch.mk +++ b/xen/arch/x86/arch.mk @@ -34,6 +34,27 @@ CFLAGS += -mno-red-zone -fpic # the SSE setup for variadic function calls. CFLAGS += -mno-mmx -mno-sse $(call cc-option,$(CC),-mskip-rax-setup) +# Enable the selected baseline ABI, if supported by the compiler. +x86-64-$(CONFIG_X86_64_BASELINE) := +x86-64-$(CONFIG_X86_64_V2) := x86-64-v2 +x86-64-$(CONFIG_X86_64_V3) := x86-64-v3 + +ifneq ($(x86-64-y),) + +CFLAGS-psabi := $(call cc-option,$(CC),-march=$(x86-64-y)) + +ifneq ($(CFLAGS-psabi),) +CFLAGS += $(CFLAGS-psabi) +else +# Fall back to using the subset of -m... options that are of interest. +x86-64-v2 := -mpopcnt -mcx16 +x86-64-v3 := $(x86-64-v2) -mbmi -mbmi2 -mlzcnt -mmovbe -mxsave +CFLAGS-$(CONFIG_X86_64_V2) += $(x86-64-v2) +CFLAGS-$(CONFIG_X86_64_V3) += $(x86-64-v3) +endif # CFLAGS-psabi + +endif # x86-64-y + ifeq ($(CONFIG_INDIRECT_THUNK),y) # Compile with gcc thunk-extern, indirect-branch-register if available. CFLAGS-$(CONFIG_CC_IS_GCC) += -mindirect-branch=thunk-extern --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -136,6 +136,12 @@ multiboot2_header: #ifdef CONFIG_REQUIRE_NX .Lno_nx_msg: .asciz "ERR: Not an NX-capable CPU!" #endif +#if defined(CONFIG_X86_64_V2) || defined(CONFIG_X86_64_V3) +.Lno_x86_64_v2_msg: .asciz "ERR: Not an x86-64-v2 capable CPU!" +#endif +#ifdef CONFIG_X86_64_V3 +.Lno_x86_64_v3_msg: .asciz "ERR: Not an x86-64-v3 capable CPU!" +#endif .section .init.data, "aw", @progbits .subsection 1 /* Put data here after the page tables (in x86_64.S). */ @@ -169,9 +175,20 @@ early_error: /* Here to improve the disa jmp .Lget_vtb #ifdef CONFIG_REQUIRE_NX .Lno_nx: + pop %ecx mov $sym_offs(.Lno_nx_msg), %ecx jmp .Lget_vtb #endif +#if defined(CONFIG_X86_64_V2) || defined(CONFIG_X86_64_V3) +.Lno_x86_64_v2: + mov $sym_offs(.Lno_x86_64_v2_msg), %ecx + jmp .Lget_vtb +#endif +#ifdef CONFIG_X86_64_V3 +.Lno_x86_64_v3: + mov $sym_offs(.Lno_x86_64_v3_msg), %ecx + jmp .Lget_vtb +#endif .Lmb2_no_bs: /* * Ditto. Additionally, here there is a chance that Xen was started @@ -532,6 +549,7 @@ trampoline_setup: mov $1, %eax cpuid mov %ecx, CPUINFO_FEATURE_OFFSET(X86_FEATURE_HYPERVISOR) + sym_esi(boot_cpu_data) + mov %ecx, %edi mov $0x80000000,%eax cpuid @@ -549,6 +567,9 @@ trampoline_setup: bt $cpufeat_bit(X86_FEATURE_LM),%edx jnc .Lbad_cpu + /* Preserve %ecx for later use. */ + push %ecx + /* * Check for NX * - If Xen was compiled requiring it simply assert it's @@ -599,6 +620,36 @@ trampoline_setup: .Lno_nx: #endif + /* Restore CPUID[80000001].ecx output. */ + pop %ecx + +#if defined(CONFIG_X86_64_V2) || defined(CONFIG_X86_64_V3) + mov %edi, %eax + or $cpufeat_mask(X86_FEATURE_POPCNT) | cpufeat_mask(X86_FEATURE_CX16), %eax + cmp %edi, %eax + jne .Lno_x86_64_v2 +#endif + +#ifdef CONFIG_X86_64_V3 + mov %edi, %eax + or $cpufeat_mask(X86_FEATURE_MOVBE) | cpufeat_mask(X86_FEATURE_XSAVE), %eax + cmp %edi, %eax + jne .Lno_x86_64_v3 + bt $cpufeat_bit(X86_FEATURE_ABM), %ecx + jnc .Lno_x86_64_v3 + xor %eax, %eax + cpuid + cmp $7, %eax + jb .Lno_x86_64_v3 + mov $7, %eax + xor %ecx, %ecx + cpuid + mov %ebx, %eax + or $cpufeat_mask(X86_FEATURE_BMI1) | cpufeat_mask(X86_FEATURE_BMI2), %eax + cmp %ebx, %eax + jne .Lno_x86_64_v3 +#endif + /* Stash TSC to calculate a good approximation of time-since-boot */ rdtsc mov %eax, sym_esi(boot_tsc_stamp) --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -742,29 +742,53 @@ static void __init efi_arch_handle_modul static void __init efi_arch_cpu(void) { - uint32_t eax = cpuid_eax(0x80000000U); + uint32_t eax = cpuid_eax(0), dummy; uint32_t *caps = boot_cpu_data.x86_capability; boot_tsc_stamp = rdtsc(); - caps[FEATURESET_1c] = cpuid_ecx(1); + if ( eax ) + caps[FEATURESET_1c] = cpuid_ecx(1); + if ( eax >= 7 ) + cpuid_count(7, 0, &dummy, + &caps[FEATURESET_7b0], + &caps[FEATURESET_7c0], + &caps[FEATURESET_7d0]); + + eax = cpuid_eax(0x80000000U); if ( (eax >> 16) == 0x8000 && eax > 0x80000000U ) - { - caps[FEATURESET_e1d] = cpuid_edx(0x80000001U); + cpuid(0x80000001U, &dummy, &dummy, + &caps[FEATURESET_e1c], &caps[FEATURESET_e1d]); + + /* + * Checks here purposefully don't use cpu_has_* because they bypass + * boot_cpu_data reads if Xen was compiled with respective CONFIG_*. + */ +#define CHK(ppsym, feat) do { \ + if ( IS_ENABLED(ppsym) && \ + !boot_cpu_has(X86_FEATURE_ ## feat) ) \ + blexit(L"This build of Xen requires " #feat " support"); \ + } while ( false ) + + CHK(CONFIG_REQUIRE_NX, NX); + + /* x86-64-v2 */ + CHK(__POPCNT__, POPCNT); + CHK(CONFIG_X86_64_V2, CX16); + CHK(CONFIG_X86_64_V3, CX16); + + /* x86-64-v3 */ + CHK(__LZCNT__, ABM); + CHK(__BMI__, BMI1); + CHK(__BMI2__, BMI2); + CHK(__MOVBE__, MOVBE); + CHK(__XSAVE__, XSAVE); + +#undef CHK - /* - * This check purposefully doesn't use cpu_has_nx because - * cpu_has_nx bypasses the boot_cpu_data read if Xen was compiled - * with CONFIG_REQUIRE_NX - */ - if ( IS_ENABLED(CONFIG_REQUIRE_NX) && - !boot_cpu_has(X86_FEATURE_NX) ) - blexit(L"This build of Xen requires NX support"); - - if ( cpu_has_nx ) - trampoline_efer |= EFER_NXE; - } + if ( cpu_has_nx ) + trampoline_efer |= EFER_NXE; } static void __init efi_arch_blexit(void) From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:10:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:10:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450088.1665605 (Exim 4.92) (envelope-from ) id 1xHHTp-0001Aa-Tu; Thu, 15 Oct 2026 09:10:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450088.1665605; Thu, 15 Oct 2026 09:10: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 1xHHTp-0001AT-RI; Thu, 15 Oct 2026 09:10:29 +0000 Received: by outflank-mailman (input) for mailman id 1450088; Thu, 15 Oct 2026 09:10:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHHTp-0001AL-69 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:10:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHTo-006fO4-Iw for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:10:28 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad09882-2eae-0a2a0a5409dd-0a2a4502b82e-12 for ; Thu, 15 Oct 2026 11:10:28 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad09884-6ca4-0a2a45020019-d155dd35cc54-3 for ; Thu, 15 Oct 2026 11:10:28 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48df8fe8513so109819f8f.0 for ; Thu, 15 Oct 2026 02:10: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-4a1bd7319c6sm65192075e9.0.2026.10.15.02.10.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 02:10: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: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=1792055428; x=1792660228; 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=Pajwugmxj1oAgJF5ydgGa4DsXBBn331IhkZGgrXGYHc=; b=FMw/Y86RfncWzut8AncSoaoBsjhtH3nS+5b3TGRqP2vncDOXW1+am1Xqx0dc1TAtLK vu+ALHufVPDaXGfHcRpMqbCZZJWEA90jq/vWh9XUvcZEFdRmbSz9QGBgV6iJChbPPzpm juBUGoIBKgwIOhP8KmnqMWQE4ZdTYraPRx+vICzqlZTi8qVgggiZ+svPYlyg1rbsmSaq 0DR5zKfM/i4erxJMTnY38PrbocnCRv+fh7suPnuNSAIzVyac18TMZ6n/f9ZfuRL6mNBb WxP0rKKUfmBOpknRdBNBOSBOe9CcCOD7qizpJPliPTNdxCTy44WCVKq7WuH+H69JnGFP iv0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792055428; x=1792660228; 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=Pajwugmxj1oAgJF5ydgGa4DsXBBn331IhkZGgrXGYHc=; b=nfD39YaDdKVsSF0UsEXZLZsCXgTGkWl2MwXBgWGNwapgBSyG6PbXXpp7epmhV73FV8 rLE667eZujYxdTkbYDW9LV+NAnHRpjhbl2dSuGx3hRnPLX0HYX/Wo+myL59RCHHq6e2d ZdHZ5fSsjAwH9JElAvi6ED9poKrgS9rA7ld85WN3wVhN+JDdz72HYUbnThmPdhzB1jLN hzdkEvgo3bRojvZOFFcQ/LIx2oTqZRx2UAlNTYr/xL0mTv2QCj/+vzjikDV5qx+tdKS0 ijRKISwRE80s6mNZ/m7MJOPJZsTvr2ouqu5Gv2EP6lJAGD3JvMsnvpxK0H9tRiM9n/gm jvVg== X-Gm-Message-State: AFq9FYL9Z6tZQAkqCpzE8utD8VMMYV405zUXJ8sQ4/pEE4sxNnvGeSAZ WUd8Y0BXP5g2oETMXgRFvh8K0/NGmqVSAGntY+ElYiY61jlt5RhqlqPmyh28OW4j5xzesTtY7f3 TLoP2vg== X-Gm-Gg: AYBFou18QUk11LuRL+2WzIjCY/szpgPaqPgZ8crTE+EZZOeSM+71UdzVCaCCT2PHA3d qlrD5Dsdyfz2RYRk7eKmrMg301XqZ6KnW7cGOnvrNAFoATiEUMh8gNbp43lJxijJ0ce2PXIShqK dW5O2U8Y5TvZ9seUPBK/BetPnzAyoEwHzFK/C81DCMhGSCBHgTS1x29ZC86srnfSBFFy6JIxgpO fTUGEbpSsGEGISM4SVwf+oDcMTzCGmbSdO+1p9wTCjsdUqigEQP93g78WnXxTMiIidhqB9GdDxU pJMas5BY1WKHhVlkEHYXX2Ti+ArMvrcqofYQLheHfqBnuUs6CSVkOyQDK4Te3CwiI85NldJk7Rp 6+I4c3CqZ5v1umu+ET0MkC+ARms49jERPxgT9KAmLOcHL9obIuIGIshkJoezPxaDc3qZtP1zr7u YkI5NNvz2K0ubMRsjloDSCef/QvPIrK3BW39DFTa7bvJK0+hmsJQuSN/U5dv4Wan3+sbLdET62j cUnOEInZxzPaYI7x2wmTCg3m9uu4XUX+U1hNvr/2zDTWOUg5Up0OAmp6E0HF0k= X-Received: by 2002:a05:600c:a112:b0:4a1:9663:7633 with SMTP id 5b1f17b1804b1-4a1966379f7mr258555625e9.11.1792055425863; Thu, 15 Oct 2026 02:10:25 -0700 (PDT) Message-ID: <9e48f405-4e99-4258-921e-2948f0d6754d@suse.com> Date: Thu, 15 Oct 2026 11:10:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v4 2/3] x86: use __builtin_popcountl() for arch_hweightl() when available From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk 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/1792055428-F24B62AC-CC136329/10/78276251493 X-purgate-type: spam X-purgate-size: 764 Use the respective compiler builtin when available; no need to play any alternatives games in such configurations. Signed-off-by: Jan Beulich --- v4: Re-base (re-do). --- a/xen/arch/x86/include/asm/bitops.h +++ b/xen/arch/x86/include/asm/bitops.h @@ -500,6 +500,9 @@ static always_inline unsigned int arch_f unsigned int arch_generic_hweightl(unsigned long x); +#ifdef __POPCNT__ +#define arch_hweightl __builtin_popcountl +#else /* !__POPCNT__ */ static always_inline unsigned int arch_hweightl(unsigned long x) { unsigned int r; @@ -525,5 +528,6 @@ static always_inline unsigned int arch_h return r; } #define arch_hweightl arch_hweightl +#endif /* __POPCNT__ */ #endif /* _X86_BITOPS_H */ From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:11:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:11:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450098.1665615 (Exim 4.92) (envelope-from ) id 1xHHV0-000237-AF; Thu, 15 Oct 2026 09:11:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450098.1665615; Thu, 15 Oct 2026 09: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 1xHHV0-000230-6Y; Thu, 15 Oct 2026 09:11:42 +0000 Received: by outflank-mailman (input) for mailman id 1450098; Thu, 15 Oct 2026 09:11:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHHUz-00022u-3k for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:11:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHUy-00GA8m-Gj for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:11:40 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad098c6-bab6-0a2a0a5309dd-0a2a4504edaa-22 for ; Thu, 15 Oct 2026 11:11:40 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad098cc-b57f-0a2a45040019-d155dd2ea4bf-3 for ; Thu, 15 Oct 2026 11:11:40 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48df0fa43c5so653518f8f.0 for ; Thu, 15 Oct 2026 02:11: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-48ded185de7sm9011910f8f.31.2026.10.15.02.11.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 02: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-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=1792055500; x=1792660300; 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=s6zV7zy/jpwXP1/SxtIpDn9sHbXfLtS9AvR38rCCZyw=; b=OzIfdVEVxScS9plilewXEE4j6hNWp+66tpVXK2aB5LBVLH6tsEbqP6w2UcErP0ndeF Q4D0tYJ+IaAGrdCpLFA0OxvfCMFvyMISa2Os3WfJAixF9XV2CDFPgJCN48ZcjvymaVpO 4s2Wbav1dQ1IVgEZOAbvBmYlcN+0N05Y+3ZPFo7URojjSl6RmxD42smTKkat8Awirn9g mepv8grbySjD+fK0JPh1y3zvAG8zEVzSCl0QYSYjAA4ePEt29Dp24dfVYw+OkZriIgYJ PcQjlAVNarXy1FAosNpfBNTyXmKa+YXWrsIOSjazbpsfesxl5e51a+u7PYiOCCAPC9e3 mnkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792055500; x=1792660300; 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=s6zV7zy/jpwXP1/SxtIpDn9sHbXfLtS9AvR38rCCZyw=; b=pUKD0OsYuMfLembIIgpTjop5wBCf6GT9kq2ZiOytp+Br5XxS6awIZX9vwF3yaR1sb8 YpSAEVDJ3dVgX4JWmW//fJnH4GHNbziZ0+menbwhEr/7i11mlIC2CVKClhvV3MRYZK5h 6Iv9wGAtg3NKEuH9qVI11WrCK1AiPNt4Fyi3a4DAGnDoZvxpm81ttSiabOw5RF6ZKCqw ZaobduQ8/O204UKlEjRQq6qHV21mdpT/Sime20gCYDFiJ+yU0cFPiJk1jC91C03iIQND llLhIdqr2S1JBUbvAxbKaE6YrmBggUR0Q2A6Aqxhz+fjpYLsaDNDo/i98UJUiZnA57vs I3nQ== X-Gm-Message-State: AFq9FYKP74p2NXyiBlnd8SPFO+0vLY0eOHakQWa3ipuGqFY6GTQzQqUD vn2xa6fl/hOS2NfZgJW1EXEKLJMxQYUIWd5qiEPqyjy+NmLvy4Htybh4lZwqQQskXPXkrC7cagu +ikVTLA== X-Gm-Gg: AYBFou3FOuJTNPtiO6Otd3giqbPGnkt7gEK5pl0A75Woe6ezpZ4KW7nOcGFUNBYmPEP w9a4+ALoQSuXNe+u5J+y64hwCoUCyrF7R2rsPUSmO8CzjdJ6Ckg6cr7wgqxbUQadTA3x1jf+Gtk JH4FNZHI57yFLig/ajVw+dmqYX/ekm3qz0BFcJ3a1Yv50ASm1ad0/zBtAKVVAWFJcB/OS5DUJIn 0RJyxASH9dxJ1N16AVVwjluS45CarHQqgJGyyDcLN2PYRsfPXP/Pe9wbr8IovaFBCpnNQEtxDAk yjqdkYUVttmrybJiMyLg6faSm15KK/kGn3zurQXSSFAZ3EAMmCYR4193WXjh4PPJvpO4aH9Yhwf kUGSHKspa3CAQit5tuiGxs4H1SJvkoex5YPHyiUePKSuBDwOuBQxH2Ra+41HRpaFrcUwirEqgXi 1D5MzBiKXfo/WcoOtSz8EpzP/mgX4/Qawm2IFGGMUzX/pvRFy5sa0Yxfq5ssm/Vbl5uZCSxUs2Y eFMnjKRM9aPHLUsYYHKNGk1zlDT2TJnAmOhvPLO8FjAYUw7Wi1Cs84soN8e/O8= X-Received: by 2002:a05:6000:240d:b0:48c:55c1:fb7e with SMTP id ffacd0b85a97d-48db94743e8mr38953128f8f.11.1792055499917; Thu, 15 Oct 2026 02:11:39 -0700 (PDT) Message-ID: <18b38bd8-bc6b-4925-8880-234c7d2b9497@suse.com> Date: Thu, 15 Oct 2026 11:11:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v4 3/3] x86: short-circuit certain cpu_has_* when x86-64-v{2,3} are in effect From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk 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/1792055500-508D9B50-6FC0B8B9/10/78276251493 X-purgate-type: spam X-purgate-size: 2208 Certain fallback code can be made subject to DCE this way. Note that CX16 has no compiler provided manifest constant, so CONFIG_* are used there instead. Note also that we don't have cpu_has_movbe nor cpu_has_lzcnt (aka cpu_has_abm), and we no longer have cpu_has_{popcnt,bmi1,bmi2}. Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk --- Of course we could use IS_ENABLED(CONFIG_X86_64_V) everywhere, but as CX16 shows this isn't necessarily better than the #if/#else approach based on compiler-provided manifest symbols. While not really intended to be used that way, it looks as if we could also use IS_ENABLED(__POPCNT__) and alike if we thought this would end up neater (because of avoiding the #ifdef). We could go further and also short-circuit SSE*, AVX and alike, which we don't use outside of the emulator. This then would of course call for also having a way to select x86-64-v4. --- v4: Re-base (over dropped cpu_has_{popcnt,bmi1,bmi2}). v2: Also cover XSAVE. --- a/xen/arch/x86/include/asm/cpufeature.h +++ b/xen/arch/x86/include/asm/cpufeature.h @@ -132,11 +132,17 @@ static inline bool boot_cpu_has(unsigned #define cpu_has_monitor boot_cpu_has(X86_FEATURE_MONITOR) #define cpu_has_vmx boot_cpu_has(X86_FEATURE_VMX) #define cpu_has_eist boot_cpu_has(X86_FEATURE_EIST) -#define cpu_has_cx16 boot_cpu_has(X86_FEATURE_CX16) +#define cpu_has_cx16 (IS_ENABLED(CONFIG_X86_64_V2) || \ + IS_ENABLED(CONFIG_X86_64_V3) || \ + boot_cpu_has(X86_FEATURE_CX16)) #define cpu_has_pdcm boot_cpu_has(X86_FEATURE_PDCM) #define cpu_has_pcid boot_cpu_has(X86_FEATURE_PCID) #define cpu_has_x2apic boot_cpu_has(X86_FEATURE_X2APIC) +#ifdef __XSAVE__ +#define cpu_has_xsave true +#else #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE) +#endif #define cpu_has_avx boot_cpu_has(X86_FEATURE_AVX) #define cpu_has_rdrand boot_cpu_has(X86_FEATURE_RDRAND) #define cpu_has_hypervisor boot_cpu_has(X86_FEATURE_HYPERVISOR) From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:22:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:22:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450112.1665623 (Exim 4.92) (envelope-from ) id 1xHHev-0004wP-6B; Thu, 15 Oct 2026 09:21:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450112.1665623; Thu, 15 Oct 2026 09: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 1xHHev-0004wI-2t; Thu, 15 Oct 2026 09:21:57 +0000 Received: by outflank-mailman (input) for mailman id 1450112; Thu, 15 Oct 2026 09:21:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHHet-0004wC-8Y for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:21:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHes-001oyC-LP for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:21:54 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad09b31-8faa-0a2a0a5109dd-0a2a45029248-4 for ; Thu, 15 Oct 2026 11:21:54 +0200 Received: from [52.101.69.133] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad09b31-6ca4-0a2a45020019-3465458546f3-3 for ; Thu, 15 Oct 2026 11:21:54 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by ZR6PR03MB752061.eurprd03.prod.outlook.com (2603:10a6:910:e6::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 09:21:52 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.021; Thu, 15 Oct 2026 09:21: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=UP1epsXQJsMccEeXHjWYMrV7uzNOH/VNmqyNfny9CndNjWOm+gq+8dGygjR/x7frXa1ns7aIWFGVaB4G/N6vbQ5ZBj3wNgUjEulr2+lMU+gj7gQpU8OvcaXNxgfC69cb1pi+AwPWkrine1r7se7+XWdtFfgj2IUWMV7jpnHMT45l26jJDyDpX8/8WUo6LL4x4DWb4S2a0utnukRV7FhhB6nQPo4L3HcpL+7GPCd+DHvqcYGdZ4LlrzLdVXWE7rVWQEYwodj/c/7BThvaeN//bKi0iynLVn6vgSy0wfsQ9adUq9FwbFyYYUg94Z2RIsZ1qaIFFc8S7kUbBpSmRU78Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IUdGGyGlC1fuQOr5YIhT4OyKseeS87e5fQ3eh2GFAvI=; b=jDJN8dWSSOq8xmX4mo5kbPaCeenbEHmg8mhfzN79FTEoVYEiV6mPtZF2lzFd3HS7ypCGjIKor16zhXeiR0+M/ToATF3hTBVxZ6cDlJkhhByBmNYeZ0acDWUa2ZZO3v+YNmtJ2Fob90wi9LH5F0I/fPqBI/6VHZrlQgSxv3QvExExueqbtgy+o+2IryWOEpOYP99UoYb0yhsMPKnawsyu9u07BK4+TlN2aoQjNMC8s1IHQYgwyHTGas/6+AwqsFP4Ky8C16ezdef8vmjcaDkpSOi0GppEZcTuWJTtE0f/Y5Z2Qkj4a3jy/NprXPHu4nP+AuGLZoFws+CjScrtGeb3NQ== 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=IUdGGyGlC1fuQOr5YIhT4OyKseeS87e5fQ3eh2GFAvI=; b=PWKHYb0efXv7lTl6s+hzjNzJlylVUQw6Mi8Fe8Vsl1V6Syf1Fh5YeYZGxKvfn7B1ezNsUiogaKhZ0kFIbMNVECJk2hCk0wliyrqFvyeNuqBVcT9zTg+SBeGcF+qMFvnMWpyptOvfgjgrPyTI1nOnrhL66gwovX6YwKmPuTwaNThroABkL1Kcuo4H1f3PgOenbdFY8s0QeB/wWz24GmCp8W8+1rkSSRyc/VsBn9aV8KOjvEFI2Bf3kJGRQy/YZ+fq+DiZ1pExzorPSqFvpDlcBHNkUGPknCO3N+XZeqoj6HT6DDvkQ8tsb8DO4kcE0S4i/IhmmGXGMk6zoZv5GASYjQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <1a922652-0f3e-49f6-9ae8-ae08d65850e6@epam.com> Date: Thu, 15 Oct 2026 11:21:50 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/22] xen/arm: smmuv3: Add support for stage-1 and nested stage translation To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Bertrand Marquis , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk References: <6e45683f154be94e573a4a5e5d25c7efcc29fbe5.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Milan Djokic In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR02CA0123.eurprd02.prod.outlook.com (2603:10a6:20b:28c::20) To AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS2PR03MB9587:EE_|ZR6PR03MB752061:EE_ X-MS-Office365-Filtering-Correlation-Id: 747f364a-8dfe-4974-99bd-08df2a9dbf6e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|261009223027099003|10067099003|3023799007|11063799006|4143699003|6133799003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: mfRgZTqYs7IsUSsvBTNs1An/zRcoENlAp0+8jQhMdHIsQ5spNaSjOGSduyJrTDEuqkYG91LnD+WTEjNLH6BjPFFCCGxAmsXtGJKTE+LPzs+W514QRdj76NteJn+maaqa09gpOdcse6HvONCLw5hw4Fn72Du05bKbETGqLE8zxAgDJ7WABi9iStKxWlgXhKIKyeYhNXGuUnMbYQfTOTl8NzQbh+D0wyAPx5yqczkaUKlCgtvfiUsSd+I21tcdhcdPGwbNBdDm922Ak3wzoA9FsLlZZVzg9yNBPPtAPin5YpCKMckJNoStCMq7Nk+vII1CdUQkdYXAVjxWu0PVM3fnxm0qPqDtEU9UnMSI0l8rQCRuIgFAfumVVfE+sYKd7wB5uARFu8SXqYWTLoK14H3nL4B5++IVegktNjfFkZIvNrEAXiVOk+IHwQ+EtNQnyrLc48hLdCYO59liuuBIZXx9W/TV1ik9tW6FbvVSqjiRuO8vYXlcF3yeu6nRriUGieoK2j8UGiM9ZXkBjdb6luFbPuD9ps0pWEzDHZBhjVoEplTxxdUFXidnJR4YGnyRt/at8zh/jadEZ2uCKPozMsH/ZtpPY+kZFLBK11dbQfFFnZPox6Maurme2sq7ki71iVTLX+7kYhugFkfRnLmEUlETrQeZUQw20YWTuzLtOCA8SNk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(261009223027099003)(10067099003)(3023799007)(11063799006)(4143699003)(6133799003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bitFZEQrUHpFR2MvRFR6UnhZWi9zQ3E3a09lc2xrUzdxdE0vZVVIczd2cG1Q?= =?utf-8?B?T0pleTczNUd2bUd6Tlg3d21EVmc4TmxNbG4zRXArSThaeUJBakZ4QWdERnNv?= =?utf-8?B?UktqOFJRNC9zSW1PMnVnZnhGMjNLWjdNZUpKN0ZBUVJsYkExbHdqWXlxVHRv?= =?utf-8?B?d1JkTlJBRUFFUHR0UEx4S1BnWTRSL05JaHdpWkVRTEhESmNCWHFYY3kvL2M1?= =?utf-8?B?ZTVpMWZ2eUxoSEJld3FVNUFXNmg3cjJmVklJc0NIaG51V0pWWSs5OU9wZ2dP?= =?utf-8?B?R3N5VW0yZy9ReWo5NlNxNndjWmJLL2M4USsrWkM3RFFJRElSczdycFhNY2Y5?= =?utf-8?B?Q2V1dVBucStFUmdta3hVMFpCcVRYNlRnajNZbzFBK016cm9uMm9kWWE2MjYr?= =?utf-8?B?WjRZaUk0cFN0R2JCdXRYaWZMcmpzUHJaKzEvNnFEMzBjbi8zWHE1czZDaHVM?= =?utf-8?B?UUtVSnM4ZGlNTzZBVlU3VUVSL0hqWTJqK0VKeWZBdFJ0QU5yT0h4WDY1dTR4?= =?utf-8?B?ZnZmeGJvWjBGcDdjMkcreEYxTFFDWDZwbTl5SFRMMjVRbUNZTVJwQkJXclpl?= =?utf-8?B?T1BFQVg0OEt4cVcxcU5OaWMzTTNCZVd3Rkp2L01uaU5rdlBVbFV0NWM4NWNE?= =?utf-8?B?MTk5WkN5M0FELytCakIwdzU0RGFhbk5COVJoNWk0Q0lpSURxVXNjK0tUckQ5?= =?utf-8?B?QVNTOHJZVDdnMC9MTFZkZ2xnNndHbzJ1UEdZTktvdGlzZHRPbUN3d3IyNUNs?= =?utf-8?B?OGozdnFjRU12Nk5UeWwrNmJLb1FlSC9TRFB5T1UrUUVHd05aVmtYdWpJSER5?= =?utf-8?B?Yy9LN21WQStQZm8raGFqTU5mYkVQYk0xZzNxQ2JvSzVFOEtWMml5dkpKemZi?= =?utf-8?B?RHRpQmFESmcxWUtkYzhSNGN6REE5NVFHQUNUM21NTzBkODAyUXhXTWFnbmZ4?= =?utf-8?B?ekpoWldHKytYS3NuZThNWWJQcUIvelhVR3BVc3JOVXB3Uit2ZER4OVhFQ3do?= =?utf-8?B?YnBKZkk4dmtqMEhVUDVndFlBYUtwNTJBSUpWdnBrbzVmRUYvVjk0UWVtc1E3?= =?utf-8?B?ZHNxcFY0SVVNZXdhK3lKSmxBL01MZVNjbDlkYndtbmk1L0gwODRUQStZWlFH?= =?utf-8?B?bDBscStJcTdyY2hGV3RLeDB2aWt0b3c4eXo2UUdmTE51WTdGMG0zbjZud0FI?= =?utf-8?B?U0tkU0xaNEoxazNXa3NNc1VNZXE2RlhwU1ZVOVFDMm9DTE9XWFNhQnN3TDNu?= =?utf-8?B?eGIyZ2xTYzNGOG54MHRkTkNLdHRnUDl3M04vTjZ6LzBjVlpBZWhmWlhYa2N0?= =?utf-8?B?QjVQTTAxbFd2OFdpUkRLT0tiOHBFOTdQVjk0RmpHZVErajZOQXdsbGNhVHB4?= =?utf-8?B?ZU13MDRTV3Q0RjgrUWsvUTZ3dGpkSWpwN2V3Z1dYdDFUbzFjMlR6aFhSTyt1?= =?utf-8?B?a0hJeGFxSWEzeDhKWE5ZbzJWYWFUUTdIUGdPNkFRdEdHWUkwNTRtTE45bmpT?= =?utf-8?B?Z1VFZkU5MGROYWpKNWxHeHlNcURaZkd5SCszUk90aUZET2N0dVhrMW40WHhD?= =?utf-8?B?cXBySHNheGYrSEppc2Nlb0RFNlh2c2U0RmFwWUsrZDRDT2JXSHZla2ZKSThj?= =?utf-8?B?Rms0MUVxbXNrck8vSndITnN2cWVMZEk0TnN5anJNdnh5Ni9IaGFCRHUvWkpU?= =?utf-8?B?OGYyWktsUHk3S2dxKythWFZiaFJTTHo5K1Q1Y1dBa1h0d1NNd3BqZGJORVRB?= =?utf-8?B?eTZaVmR2cWd0QnRrOUVVY1VPQmR6UFRhZThZUE5zejhUUGU1K0ZNWlRPRFlo?= =?utf-8?B?Q2NSN2dsUDR1QmpINCs5dU92eUNBTXZ4MDF1dzBnZjYybVFiOU5kQlk2ODB3?= =?utf-8?B?T2trVnROQkhrQjV4M1Vra0JjMy90Q3cwcUQ5aWpTLzU2cmVNTmVCVlIwbkk1?= =?utf-8?B?VHRaQ3ZnTndLNGNsNnc3RWk0ajJ6bEN5Z2ViUWltWVNlNlE2bllZVG9WeXM1?= =?utf-8?B?NXg4c2owRkNzSHlqUUJGN240ditxRndtTnRwbVgxbHRHUUtOVFprQjFHdHFS?= =?utf-8?B?aW9QdC9WTFE4NnJzR01MVmgva2NyZjFWT1c0LzVxM1NWbnFwWjFLK3BPR3BG?= =?utf-8?B?SldCcGZHWVJpbDZGdldRR1J2V1pObWhWRWhWbDlLSjkrRWozNGRxWXAvZVlP?= =?utf-8?B?RENHUmg5cDBvb2c5dnpNRkhXV1hHS2cybkgxN3FPcnNvdU5teWxKQTRyKzN1?= =?utf-8?B?RWRQRGJiUkw4WW5WZzZvcGwvelhwekovcFNiSTdzSWN6d0FPMWNuTDBaWlUx?= =?utf-8?B?S0VaQVR3bFZFekZocTBtN3JqUzM4Y09teGlrMFpBeE1kZzZ5N2JLdz09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 747f364a-8dfe-4974-99bd-08df2a9dbf6e X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 09:21:52.2082 (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: HN4WSUorQeY5ovNBkg5u2ihwLqLda8wBdaPNmlC6EPKQttNfQI5FhAP0sRwbc8tiieKWIDFRoGcpQlmc5PYiqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR03MB752061 X-purgate-ID: tlsNG-720697/1792056114-674BE2AC-A76C23A4/0/0 X-purgate-type: clean X-purgate-size: 11098 Hi Oleksandr, On 10/9/26 19:37, Oleksandr Tyshchenko wrote: > [You don't often get email from olekstysh@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > On 10/7/26 03:06, Milan Djokic wrote: > > Hello Milan > >> From: Rahul Singh >> >> Xen SMMUv3 driver only supports stage-2 translation. Add support for >> Stage-1 translation that is required to support nested stage >> translation. >> >> In true nested mode, both s1_cfg and s2_cfg will coexist. >> Let's remove the union. When nested stage translation is setup, both >> s1_cfg and s2_cfg are valid. >> >> We introduce a new smmu_domain abort field that will be set >> upon guest stage-1 configuration passing. If no guest stage-1 >> config has been attached, it is ignored when writing the STE. >> >> arm_smmu_write_strtab_ent() is modified to write both stage >> fields in the STE and deal with the abort field. >> >> Signed-off-by: Rahul Singh >> Signed-off-by: Milan Djokic >> --- >> xen/drivers/passthrough/arm/smmu-v3.c | 96 +++++++++++++++++++++++---- >> xen/drivers/passthrough/arm/smmu-v3.h | 9 +++ >> 2 files changed, 93 insertions(+), 12 deletions(-) >> >> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c >> index 7162473d62..d3e88d5a55 100644 >> --- a/xen/drivers/passthrough/arm/smmu-v3.c >> +++ b/xen/drivers/passthrough/arm/smmu-v3.c >> @@ -683,8 +683,10 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, >> * 3. Update Config, sync >> */ >> u64 val = le64_to_cpu(dst[0]); >> - bool ste_live = false; >> + bool s1_live = false, s2_live = false, ste_live = false; >> + bool abort, translate = false; >> struct arm_smmu_device *smmu = NULL; >> + struct arm_smmu_s1_cfg *s1_cfg = NULL; >> struct arm_smmu_s2_cfg *s2_cfg = NULL; >> struct arm_smmu_domain *smmu_domain = NULL; >> struct arm_smmu_cmdq_ent prefetch_cmd = { >> @@ -699,30 +701,57 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, >> smmu = master->smmu; >> } >> >> - if (smmu_domain) >> - s2_cfg = &smmu_domain->s2_cfg; >> + if (smmu_domain) { >> + switch (smmu_domain->stage) { >> + case ARM_SMMU_DOMAIN_S1: >> + s1_cfg = &smmu_domain->s1_cfg; >> + break; >> + case ARM_SMMU_DOMAIN_NESTED: >> + s1_cfg = &smmu_domain->s1_cfg; >> + fallthrough; >> + case ARM_SMMU_DOMAIN_S2: >> + s2_cfg = &smmu_domain->s2_cfg; >> + break; >> + default: >> + break; >> + } >> + translate = s1_cfg || s2_cfg; >> + } >> >> if (val & STRTAB_STE_0_V) { >> switch (FIELD_GET(STRTAB_STE_0_CFG, val)) { >> case STRTAB_STE_0_CFG_BYPASS: >> break; >> + case STRTAB_STE_0_CFG_S1_TRANS: >> + s1_live = true; >> + break; >> case STRTAB_STE_0_CFG_S2_TRANS: >> - ste_live = true; >> + s2_live = true; >> + break; >> + case STRTAB_STE_0_CFG_NESTED: >> + s1_live = true; >> + s2_live = true; >> break; >> case STRTAB_STE_0_CFG_ABORT: >> - BUG_ON(!disable_bypass); >> break; >> default: >> BUG(); /* STE corruption */ >> } >> } >> >> + ste_live = s1_live || s2_live; >> + >> /* Nuke the existing STE_0 value, as we're going to rewrite it */ >> val = STRTAB_STE_0_V; >> >> /* Bypass/fault */ >> - if (!smmu_domain || !(s2_cfg)) { >> - if (!smmu_domain && disable_bypass) >> + if (!smmu_domain) >> + abort = disable_bypass; >> + else >> + abort = smmu_domain->abort; >> + >> + if (abort || !translate) { >> + if (abort) >> val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_ABORT); >> else >> val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS); >> @@ -740,7 +769,32 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, >> return; >> } >> >> + if (ste_live) { >> + /* First invalidate the live STE */ >> + dst[0] = cpu_to_le64(STRTAB_STE_0_CFG_ABORT); >> + arm_smmu_sync_ste_for_sid(smmu, sid); >> + } >> + >> + if (s1_cfg) { >> + dst[1] = cpu_to_le64( >> + FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0) | >> + FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) | >> + FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) | >> + FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH) | >> + FIELD_PREP(STRTAB_STE_1_STRW, STRTAB_STE_1_STRW_NSEL1)); >> + >> + if (smmu->features & ARM_SMMU_FEAT_STALLS && >> + !(smmu->features & ARM_SMMU_FEAT_STALL_FORCE)) >> + dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD); >> + >> + val |= (s1_cfg->s1ctxptr & STRTAB_STE_0_S1CTXPTR_MASK) | >> + FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) | >> + FIELD_PREP(STRTAB_STE_0_S1CDMAX, s1_cfg->s1cdmax) | >> + FIELD_PREP(STRTAB_STE_0_S1FMT, s1_cfg->s1fmt); >> + } >> + >> if (s2_cfg) { >> + u64 vttbr = s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK; >> u64 strtab = >> FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) | >> FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) | >> @@ -750,12 +804,19 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, >> STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2AA64 | >> STRTAB_STE_2_S2R; >> >> - BUG_ON(ste_live); >> + if (s2_live) { >> + u64 s2ttb = le64_to_cpu(dst[3]) & STRTAB_STE_3_S2TTB_MASK; >> + BUG_ON(s2ttb != vttbr); >> + } >> + >> dst[2] = cpu_to_le64(strtab); >> >> - dst[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK); >> + dst[3] = cpu_to_le64(vttbr); >> >> val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS); >> + } else { >> + dst[2] = 0; >> + dst[3] = 0; >> } >> >> if (master->ats_enabled) >> @@ -1254,8 +1315,16 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain, >> { >> int ret; >> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >> + struct arm_smmu_device *smmu = smmu_domain->smmu; >> + >> + if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S2)) >> + return 0; > > > I am not fully confident I understood all the magic here correctly, but > it appears the initial state may be broken on SMMUs without stage-2 > (stage-1-only hosts). > > Here we return early without setting a stage, and the zeroed domain has > stage-1 (enum value 0). So a new domain is left in a default stage-1 > state with no real config. The first attach then writes a live S1 STE > with s1ctxptr = 0 in arm_smmu_write_strtab_ent(), so the hardware reads > a context descriptor from physical address 0. I wonder we should default > the domain to abort. > > Could you please double-check? > Yes, this is a valid point. The first STE write shall install the incorrect configuration. I will default the domain to abort when stage-2 is not supported. > Also, it is my understanding that without stage-2 translation the > guest’s s1ctxptr and the stage-1 output address are used as host > physical addresses. The guest decides where the hardware reads and > writes. I wonder whether we should refuse this mode for non-hardware > (non-direct-mapped) domains. > Same here. I'll update the implementation to allow Stage-1-only mode only for direct-mapped domains. > Apologies if this has already been discussed. > >> >> - /* Restrict the stage to what we can actually support */ >> + /* >> + * Default to stage-2 support and initialize it. Stage-1 will be >> + * initialized during guest config attachment, if nested or stage-1 >> + * mode is required >> + */ >> smmu_domain->stage = ARM_SMMU_DOMAIN_S2; >> >> ret = arm_smmu_domain_finalise_s2(smmu_domain, master); >> @@ -2398,11 +2467,14 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) >> break; >> } >> >> + if (reg & IDR0_S1P) >> + smmu->features |= ARM_SMMU_FEAT_TRANS_S1; >> + >> if (reg & IDR0_S2P) >> smmu->features |= ARM_SMMU_FEAT_TRANS_S2; >> >> - if (!(reg & IDR0_S2P)) { >> - dev_err(smmu->dev, "no stage-2 translation support!\n"); >> + if (!(reg & (IDR0_S1P | IDR0_S2P))) { >> + dev_err(smmu->dev, "no translation support!\n"); >> return -ENXIO; >> } >> >> diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthrough/arm/smmu-v3.h >> index ab1f29f6c7..e257de6db9 100644 >> --- a/xen/drivers/passthrough/arm/smmu-v3.h >> +++ b/xen/drivers/passthrough/arm/smmu-v3.h >> @@ -197,6 +197,7 @@ >> #define STRTAB_STE_0_CFG_BYPASS 4 >> #define STRTAB_STE_0_CFG_S1_TRANS 5 >> #define STRTAB_STE_0_CFG_S2_TRANS 6 >> +#define STRTAB_STE_0_CFG_NESTED 7 >> >> #define STRTAB_STE_0_S1FMT GENMASK_ULL(5, 4) >> #define STRTAB_STE_0_S1FMT_LINEAR 0 >> @@ -549,6 +550,12 @@ struct arm_smmu_strtab_l1_desc { >> dma_addr_t l2ptr_dma; >> }; >> >> +struct arm_smmu_s1_cfg { >> + u64 s1ctxptr; >> + u8 s1fmt; >> + u8 s1cdmax; >> +}; >> + >> struct arm_smmu_s2_cfg { >> u16 vmid; >> u64 vttbr; >> @@ -669,6 +676,8 @@ struct arm_smmu_domain { >> atomic_t nr_ats_masters; >> >> enum arm_smmu_domain_stage stage; >> + bool abort; >> + struct arm_smmu_s1_cfg s1_cfg; >> struct arm_smmu_s2_cfg s2_cfg; >> >> /* Xen domain associated with this SMMU domain */ > BR, Milan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:34:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:34:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450121.1665633 (Exim 4.92) (envelope-from ) id 1xHHqj-0007aC-9l; Thu, 15 Oct 2026 09:34:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450121.1665633; Thu, 15 Oct 2026 09:34: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 1xHHqj-0007a5-78; Thu, 15 Oct 2026 09:34:09 +0000 Received: by outflank-mailman (input) for mailman id 1450121; Thu, 15 Oct 2026 09:34:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHHqh-0007Zz-7K for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:34:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHqg-007Mcx-5T for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:34:06 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad09e0a-2eae-0a2a0a5409dd-0a2a450cb75c-24 for ; Thu, 15 Oct 2026 11:34:06 +0200 Received: from [52.101.66.88] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad09e0d-f479-0a2a450c0019-346542583b48-3 for ; Thu, 15 Oct 2026 11:34:05 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by VI2PR03MB11003.eurprd03.prod.outlook.com (2603:10a6:800:299::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 09:34:02 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.021; Thu, 15 Oct 2026 09:34: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=v+nODBM/7bO3poAFFGetnFUAk01sh1PBt+GdQdzmcrW/TN93wXDJB8Xw5rOKu4yCPj2K3B585TESL6r5pmIctXnZtYQZf51sa7C5KlwX6HUinQhE1kfY1CRq46ABERDsBMGWP+sN/LXmNN4QHgzS4D4cDGv6iA3czcVx8y7RxpoVl9w7RIvs3yDLkS6AsK2eoNNVtG0lwQ+L6lNWp+cAtlE5XhYOuYC55awWJwoQcxSsWYhBsFGpGmbw/wzYeTQKrRMzhDN6mnVv9pE95PqlEIlRgG9pUlI36sehAYIiMi1VjHQTw5nZqChmapatsvOGvMii6SWdJfi4GHtN2/FZqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s8G+7gP20opyVvGfbc7rYzjyDJjT+pSHAze58KWYd8A=; b=xMjcZaFgYZOyohK6Zd5/sAL2X2+ePpz+AMmZVdOTl4Ge/K/UzzqjYmHkd0mU4tVguYGrPWZVIFSh7Z5ClgM7ImVCJ7WXP8QAnudE/aRU/qOc3JIRmHRhdPWopW+fdVy/rm19akfpfK0x40rAdBTimApaOeVQaAsl2OEnhcLqDq251em0Es/+PIXisvfI9hiCjR8or8jQZjWGJrWYqeS2421H0RkdxxYTdUP286huIi1zE5F62Du5ZVXOUnpkKxses1wpSFvyXt4wKxa827M1q5DQi44bwJJqGKKCQOm5t+Y4hdVzMyn73vhLmFQAOZXlzBOg1sF/tWyo33NKoZ36ew== 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=s8G+7gP20opyVvGfbc7rYzjyDJjT+pSHAze58KWYd8A=; b=asApyFk4mDkCSWQG4B0uBmu8qpzMvUjJiIdWJxfVw7qlrM98GyRMs2JEcA56SDKVltWEuBOcBd3SkAwG9NwrQjrRBkdx49jw7r2mWuKz1qYXbFMdsY5RwsUwyZdLtKrgwx0wudpTBw/dd8xH5KGvadv6v6rYVaR1lZ0AqZc+w94v74eqRPac+ESm3TP0A7tQ6qVjE8FwiMPHVJsRuxXXBd1vjgIJdsXO70Q6Gr8Hmu99ekuLR7cNdhrnoYpS18iBtwt5am29h3FaICI+VTGOETbvnVfSOl7xPOplqkdpB5iOnoLMYJE5Lv3qVzv5/ucha6xGrYJlK+L636rpWCwrBw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: Date: Thu, 15 Oct 2026 11:33:59 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 04/22] xen/arm: vIOMMU: add generic vIOMMU framework To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6c7570f50af7ebaae8aa709db86959dbd09e1f82.1791328190.git.milan_djokic@epam.com> <144fe444-39ef-456b-9fd4-747c0abc02c5@gmail.com> Content-Language: en-US From: Milan Djokic In-Reply-To: <144fe444-39ef-456b-9fd4-747c0abc02c5@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VIUP296CA0088.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:35c::12) To AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS2PR03MB9587:EE_|VI2PR03MB11003:EE_ X-MS-Office365-Filtering-Correlation-Id: b4e2e1c8-1dcf-4b46-df64-08df2a9f7286 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|56012099006|11063799006|4143699003|261009223027099003|260925022911599003|18002099003|10067099003|22082099003|6133799003|260925021311599003|260925021911599003; X-Microsoft-Antispam-Message-Info: rrWZ3q+QJTbUgnX5rANVqjfSGUBotelbqJk7lhma/4UEwRsAj58D5mtCa9BMNYHx/sd1mEj3e3yWqFmpOoXE59WPSa9SYcP8BMDS38XnzD/gsYy9xtcXSPl0GVJ72XOJ489xYzT0rUEcuwe6lKnki6fwyD1xWS9JDw9sJvCkOGjeKd0+ig9Jzqv7/GvlC8JONkMiBy2gUvaKMIUaMfifh7v0mgr4v6GK8rGHGWNGRDRYu07dz3qGQDud8DDI8vxr+GdtNUOafWb9FqSB/JzOI0Sdx3JS4ESLYIc84SGSqcCPLq28sMg0+zQXaWLCLnibeUjXW/ob9jt7Hj5wAcxxRtis1oJKCvH59cz1CgGhDVs9T23EXuYLE20INlYJpDSE8mxVN/KwC0izRK5Wr0clJrN/UDNLj8s2Q//vvPlobfQdeGUdsRFs8yMBAo35iSDBIcVy1qqLOlKoolO/AQmOibbZHDRJFIz2Apk5nXZ4nS8WMqcyb1NCbKctHEM+uavh1U+bpsY3xiIjpoOFZVP+KMW2yWBYd1P/MyAYUPmf93UJjdKZlAz3dbhHB0kqdpmlyHlEPWqPMBc5kGfSpx+fii8tPuZzP7+0fsa68qtEubv/8X3QfoUGXgWsoeTPEvNjUfCrwNqmN2YQm2blXi0cXgvfRgj8Vbvu/f+QlQVVEAs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(56012099006)(11063799006)(4143699003)(261009223027099003)(260925022911599003)(18002099003)(10067099003)(22082099003)(6133799003)(260925021311599003)(260925021911599003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L0htQjNiTm80MDROVEpsY1dmYTNOQWt3alRvMnMxTDA2MHlOZnp5SllXR0NR?= =?utf-8?B?eUtkNjRBRi9vaFRoQXpvaWZ0dFhHakVJYjlDQkw5WDZaSGh1WWRtdW1wL1dX?= =?utf-8?B?aFpGQWRKc1d4SEFYV2RuK3M0aVppVmR5OVp1UmZDNytIUEVILytOSjBEdXpU?= =?utf-8?B?OStJK1NISTRSaUFNSWdjdUU3Si9lT3FQYWJHVTBTY1lWN05TK1dPNFZTdTdS?= =?utf-8?B?ek5VNkU2bncwVWY2MjIrOXgvRm95ZnNCSnVRUitZT0VPVVZVa3c4b3NQdWNw?= =?utf-8?B?TGdMa2swYy9jWCszc1pkN010TXFFcjUzSWxZSHBzSG9lZFAyb0laK2huSG9E?= =?utf-8?B?RDlranp1MVB5dEs2dUdHTjk2dFZXSEp6Z0NkUXYvbEh4VmFQcGhseGdvMENV?= =?utf-8?B?eXpFNGhsbytENHEyUmVPaHBCMERaQ0dxWktCQlB3Sjlld1VvQ2lMUFZ4MDBl?= =?utf-8?B?THF5cnNKWFdvSitGNTZKQm1ZNkxJWGQweERSZStzbXFycWVCUFJrMldFNERi?= =?utf-8?B?eWpDQkpocmt6R0RQZ2R0Z040bHZmUGs0bWYzcy9NU2Zpa2N3dDhMdzJ1dHNN?= =?utf-8?B?U0FsUzUvTWV3VnFBeGRQSjlLaHlFRDN5emQ5cnl3RmVRWU1taFVnN01JNk1o?= =?utf-8?B?WDN6NjRvbHJ3RnB0cHdzM1MvU0xYeTQ1bGRTSUNtNHEyOHZGcWFoWmV0Mit6?= =?utf-8?B?VFJCTDR5UGsvdDF6NjhWY0h0MUxrTzRpZVJMOG8za2ZtYkpqNkxWYTE1a1Ja?= =?utf-8?B?a0VKNGRsNDhKU0c5M1M2M0dDWlJJM1hzTjM4QkZHQks1Nkt6bUw3WW1sUnUv?= =?utf-8?B?eDZOQnJqVE91Q1hrVU4vTzJwd3dndzFIOUE3eGlLOGhRclJ1TTJqczFiMmR3?= =?utf-8?B?NExNS3lXQ1FZQVRiVmVERHZrS1pUVFhiQ0RhZlkrV0VWdjZKWVczOU43cko2?= =?utf-8?B?cmpFMEh2ZWY1Tk42bTE1N3RDekw5SXV4NlJzeDU3M0ZUNGlTY2ovMzRDcEEy?= =?utf-8?B?TStPUUhTc1kyaXhESTIwUk1WQXNsMklRR2kyRE9sR2o2VUpIaTQyRWxJVC9E?= =?utf-8?B?UnA4RndnaFlxdUFMbDcvdEI3Y0xyN2RBN3FyektnK3EzaFJZS2V2aGxodVgw?= =?utf-8?B?dWZPNUwvOUl4d0l1YTErT2FMTTRpNXdNcDZJZitLSmdZQ3pMOVg4UlA1Y2hL?= =?utf-8?B?UUtXcldjWlo3U1F3bjhUZzVrM2FMbytqWmdXL2hZM0MxRndDaGcvRTNLQXRT?= =?utf-8?B?cmY4UVVPMXpXSm82S3VLNW5yam42YTRjazRxZDR0NGNwTjhobnBOZHZVVlBI?= =?utf-8?B?d1d0ZExyTGs2T3lzQms2bnRqMkVseGFWQm82d0hhdHFIMW0wd21JZGtCbDV6?= =?utf-8?B?L0tOVzF5OVRrVlJNODYzM0k3YjAva3ovTElzZFlzT1RmU05lbndtMkxCSGt1?= =?utf-8?B?TUVFTzVLekxnbXAxREJweUFGMFl2S1NZZTBMd3dlQjB5VVhrNC9sL1g2T0Zv?= =?utf-8?B?b2xQbGxGdlRTOEFIT2FZaHZSZ3luenpyWUsyTWk0MDE3d3JHMVg2VklrNTNz?= =?utf-8?B?bXFtREpuN1RYd1FjcFk5MjU5YzA1L3l1UVVXU05vVVlNdmdoaGFGQkZlWkR4?= =?utf-8?B?VFFCaThIYndTRjlLYWN6c0tsR2tIbnFBaGh2aGV1MVpZWXJKS2VWUnhHdzk3?= =?utf-8?B?M2VweUk4bXE3T2RxOEllaVJOR0w0OStpVkx6T0w2WDdwRXltaFBWblNweEdD?= =?utf-8?B?TkRoc2UxbERJNUNlSThucXhXK2hRY1BteXZLZG9aVDh4eFNKNEcxSGVnVUtE?= =?utf-8?B?eDZyM0laVmROR0RFMUdNVlY4SnF2VmMyMCtOQmNZWDlOck1NL01qY1piSzVv?= =?utf-8?B?QWM0SHZEeUlNTzV3SVljNkowWFFmRnB4QVBQVGVWNlZDTG0wb1lBRHdIOTlS?= =?utf-8?B?eHZYNmNSQTlJSm5oUm9YcFY4YlhidmtGcWVXaDhOcVEvMXRkSzcydzNLdXBa?= =?utf-8?B?UXZDM3diVnMyanFKbEFPbTR5Mk9hTWUvSVF6djRiUkRmTVd6SGM3eDlXSXFZ?= =?utf-8?B?YW1pL3lDQW8zTStUdzUwK2V1YXVGVUd0amk5UGZpb1hNZjExeGc3ejYvSVBV?= =?utf-8?B?ZTJuYkNWZlNpWFpUS0Rhb3ZKdzVZSklUYlJkREZDZU8wSVJzS2pOcTRDQ2VD?= =?utf-8?B?MjZBYlZaeU9KNzlWeld1VWpmei9WSVNaVTlZOXA5TWdueUp6MzI1V05jS2p1?= =?utf-8?B?eFZCNlQwbDkvU0NiMXNpRUNRRVRpeVc1bjNyRHdzNkdwbWZhTW4xSVRzS3VE?= =?utf-8?B?cjg4YzZMTWdLNnUyc1paQkRtTVhpaHFuNUhPalRucmZha3IvR1dzQT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4e2e1c8-1dcf-4b46-df64-08df2a9f7286 X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 09:34:02.0892 (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: +1Tg80XlZFapIDCF21JXUQmI+W8iZ8pCSC2lp81US/yPFmSDb6Skdehy1QFpAoiF9XRd2IOAii/VQrDY2CYFoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR03MB11003 X-purgate-ID: tlsNG-d25034/1792056846-02CDBA5B-FF87A43F/0/0 X-purgate-type: clean X-purgate-size: 11534 Hi Oleksandr, On 10/9/26 13:41, Oleksandr Tyshchenko wrote: > [You don't often get email from olekstysh@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > On 10/7/26 03:06, Milan Djokic wrote: > > Hello Milan > > >> From: Rahul Singh >> >> This patch adds basic framework for vIOMMU. >> >> Signed-off-by: Rahul Singh >> Signed-off-by: Milan Djokic >> --- >> xen/arch/arm/dom0less-build.c | 2 + >> xen/arch/arm/domain.c | 31 +++++++++++- >> xen/arch/arm/domain_build.c | 2 + >> xen/arch/arm/include/asm/viommu.h | 70 ++++++++++++++++++++++++++++ >> xen/drivers/passthrough/Kconfig | 5 ++ >> xen/drivers/passthrough/arm/Makefile | 1 + >> xen/drivers/passthrough/arm/viommu.c | 49 +++++++++++++++++++ >> xen/include/public/arch-arm.h | 6 ++- >> 8 files changed, 164 insertions(+), 2 deletions(-) >> create mode 100644 xen/arch/arm/include/asm/viommu.h >> create mode 100644 xen/drivers/passthrough/arm/viommu.c >> >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >> index 3f48f74226..f87437915e 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 >> >> @@ -369,6 +370,7 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node, >> uint32_t val; >> >> d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; >> + d_cfg->arch.viommu_type = viommu_get_type(); >> 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..5c411a2310 100644 >> --- a/xen/arch/arm/domain.c >> +++ b/xen/arch/arm/domain.c >> @@ -33,6 +33,7 @@ >> #include >> #include >> #include >> +#include >> #include >> >> #include "vuart.h" >> @@ -663,6 +664,21 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) >> return -EINVAL; >> } >> >> + if ( !(config->flags & XEN_DOMCTL_CDF_iommu) && >> + config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) >> + { >> + dprintk(XENLOG_INFO, >> + "vIOMMU requested while iommu not enabled for domain\n"); >> + return -EINVAL; >> + } > > > I might miss something, but if CONFIG_ARM_VIRTUAL_IOMMU=y and we have > SMMUv3 the dom0less domains "without passthrough" will fail to build. > > arch_parse_dom0less_node() sets viommu_type for every guest. But > CDF_iommu is only set when passthrough = "enabled" or the node has a > multiboot DTB. So a plain guest without passthrough is therefore > rejected here. > Good catch. The domain's ``viommu_type`` should be set based on both ``CDF_IOMMU`` and the detected vIOMMU. The vIOMMU should be disabled for the domain when passthrough is disabled. I will fix this. > > >> + >> + if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) >> + { >> + dprintk(XENLOG_INFO, >> + "vIOMMU type requested not supported by the platform or Xen\n"); >> + return -EINVAL; >> + } >> + >> return sci_domain_sanitise_config(config); >> } >> >> @@ -762,6 +778,9 @@ int arch_domain_create(struct domain *d, >> if ( (rc = sci_domain_init(d, config)) != 0 ) >> goto fail; >> >> + if ( (rc = domain_viommu_init(d, config->arch.viommu_type)) != 0 ) >> + goto fail; >> + >> return 0; >> >> fail: >> @@ -822,7 +841,8 @@ static void resume_ctx_reset(struct resume_info *ctx) >> void arch_domain_destroy(struct domain *d) >> { >> resume_ctx_reset(&d->arch.resume_ctx); >> - >> + if ( viommu_relinquish_resources(d) ) >> + printk(XENLOG_INFO "%pd: Domain vIOMMU teardown failed\n", d); >> tee_free_domain_ctx(d); >> /* IOMMU page table is shared with P2M, always call >> * iommu_domain_destroy() before p2m_final_teardown(). >> @@ -1058,6 +1078,7 @@ static int relinquish_memory(struct domain *d, struct page_list_head *list) >> */ >> enum { >> PROG_pci = 1, >> + PROG_viommu, >> PROG_sci, >> PROG_tee, >> PROG_xen, >> @@ -1105,6 +1126,14 @@ int domain_relinquish_resources(struct domain *d) >> if ( ret ) >> return ret; >> #endif >> + /* >> + * PCI devices may rely on the vIOMMU, so its resources >> + * should be relinquished only after the PCI devices are released. >> + */ >> + PROGRESS(viommu): >> + ret = viommu_relinquish_resources(d); >> + if (ret ) >> + return ret; >> >> PROGRESS(sci): >> ret = sci_relinquish_resources(d); >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 72d5316180..cd2e09f005 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -36,6 +36,7 @@ >> #include >> #include >> #include >> +#include >> #include >> >> #include >> @@ -1964,6 +1965,7 @@ void __init create_dom0(void) >> dom0_cfg.arch.nr_spis = vgic_def_nr_spis(); >> dom0_cfg.arch.tee_type = tee_get_type(); >> dom0_cfg.max_vcpus = dom0_max_vcpus(); >> + dom0_cfg.arch.viommu_type = viommu_get_type(); >> >> if ( iommu_enabled ) >> dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu; >> diff --git a/xen/arch/arm/include/asm/viommu.h b/xen/arch/arm/include/asm/viommu.h >> new file mode 100644 >> index 0000000000..95f82d9cf5 >> --- /dev/null >> +++ b/xen/arch/arm/include/asm/viommu.h >> @@ -0,0 +1,70 @@ >> +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ >> +#ifndef __ARCH_ARM_VIOMMU_H__ >> +#define __ARCH_ARM_VIOMMU_H__ >> + >> +#include >> +#include >> +#include >> + >> +struct viommu_ops { >> + /* >> + * Called during domain construction if toolstack requests to enable >> + * vIOMMU support. >> + */ >> + int (*domain_init)(struct domain *d); >> + >> + /* >> + * Called during domain destruction to free resources used by vIOMMU. >> + */ >> + int (*relinquish_resources)(struct domain *d); >> +}; >> + >> +struct viommu_desc { >> + /* vIOMMU domains init/free operations described above. */ >> + const struct viommu_ops *ops; >> + >> + /* >> + * ID of vIOMMU. Corresponds to xen_arch_domainconfig.viommu_type. >> + * Should be one of XEN_DOMCTL_CONFIG_VIOMMU_xxx >> + */ >> + uint8_t viommu_type; >> +}; >> + >> +#ifdef CONFIG_ARM_VIRTUAL_IOMMU >> + >> +int domain_viommu_init(struct domain *d, uint8_t viommu_type); >> +int viommu_relinquish_resources(struct domain *d); >> +uint8_t viommu_get_type(void); >> + >> +#else >> + >> +static inline uint8_t viommu_get_type(void) >> +{ >> + return XEN_DOMCTL_CONFIG_VIOMMU_NONE; >> +} >> + >> +static inline int domain_viommu_init(struct domain *d, uint8_t viommu_type) >> +{ >> + if ( likely(viommu_type == XEN_DOMCTL_CONFIG_VIOMMU_NONE) ) >> + return 0; >> + >> + return -ENODEV; >> +} >> + >> +static inline int viommu_relinquish_resources(struct domain *d) >> +{ >> + return 0; >> +} >> + >> +#endif /* CONFIG_ARM_VIRTUAL_IOMMU */ >> + >> +#endif /* __ARCH_ARM_VIOMMU_H__ */ >> + >> +/* >> + * Local variables: >> + * mode: C >> + * c-file-style: "BSD" >> + * c-basic-offset: 4 >> + * indent-tabs-mode: nil >> + * End: >> + */ >> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig >> index b413c33a4c..a92cfbea98 100644 >> --- a/xen/drivers/passthrough/Kconfig >> +++ b/xen/drivers/passthrough/Kconfig >> @@ -35,6 +35,11 @@ config IPMMU_VMSA >> (H3 ES3.0, M3-W+, etc) or Gen4 SoCs which IPMMU hardware supports stage 2 >> translation table format and is able to use CPU's P2M table as is. >> >> +config ARM_VIRTUAL_IOMMU >> + bool "Virtual IOMMU Support (UNSUPPORTED)" if UNSUPPORTED >> + help >> + Support virtual IOMMU infrastructure to implement vIOMMU. >> + >> endif >> >> config AMD_IOMMU >> diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile >> index c5fb3b58a5..c3783188e3 100644 >> --- a/xen/drivers/passthrough/arm/Makefile >> +++ b/xen/drivers/passthrough/arm/Makefile >> @@ -2,3 +2,4 @@ obj-y += iommu.o iommu_helpers.o iommu_fwspec.o >> obj-$(CONFIG_ARM_SMMU) += smmu.o >> obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o >> obj-$(CONFIG_ARM_SMMU_V3) += smmu-v3.o >> +obj-$(CONFIG_ARM_VIRTUAL_IOMMU) += viommu.o >> diff --git a/xen/drivers/passthrough/arm/viommu.c b/xen/drivers/passthrough/arm/viommu.c >> new file mode 100644 >> index 0000000000..0c0efd668e >> --- /dev/null >> +++ b/xen/drivers/passthrough/arm/viommu.c >> @@ -0,0 +1,49 @@ >> +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ >> + >> +#include >> +#include >> +#include >> + >> +#include >> + >> +/* Struct to hold the vIOMMU ops and vIOMMU type */ >> +static const struct viommu_desc __ro_after_init *cur_viommu; >> + >> +int domain_viommu_init(struct domain *d, uint8_t viommu_type) >> +{ >> + if ( viommu_type == XEN_DOMCTL_CONFIG_VIOMMU_NONE ) >> + return 0; >> + >> + if ( !cur_viommu ) >> + return -ENODEV; >> + >> + if ( cur_viommu->viommu_type != viommu_type ) >> + return -EINVAL; >> + >> + return cur_viommu->ops->domain_init(d); >> +} >> + >> +int viommu_relinquish_resources(struct domain *d) >> +{ >> + if ( !cur_viommu ) >> + return 0; >> + >> + return cur_viommu->ops->relinquish_resources(d); >> +} >> + >> +uint8_t viommu_get_type(void) >> +{ >> + if ( !cur_viommu ) >> + return XEN_DOMCTL_CONFIG_VIOMMU_NONE; >> + >> + return cur_viommu->viommu_type; >> +} >> + >> +/* >> + * Local variables: >> + * mode: C >> + * c-file-style: "BSD" >> + * c-basic-offset: 4 >> + * indent-tabs-mode: nil >> + * End: >> + */ >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h >> index 00de30b896..a1491f9cf7 100644 >> --- a/xen/include/public/arch-arm.h >> +++ b/xen/include/public/arch-arm.h >> @@ -334,6 +334,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); >> #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_PMSA 1 >> #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA 2 >> >> +#define XEN_DOMCTL_CONFIG_VIOMMU_NONE 0 >> + >> struct xen_arch_domainconfig { >> /* IN/OUT */ >> uint8_t gic_version; >> @@ -361,7 +363,9 @@ struct xen_arch_domainconfig { >> uint8_t arm_sci_type; >> /* IN */ >> uint8_t v8r_el1_msa; >> - uint16_t pad; >> + /* IN */ >> + uint8_t viommu_type; >> + uint8_t pad; >> }; >> #endif /* __XEN__ || __XEN_TOOLS__ */ >> > BR, Milan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:40:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:40:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450133.1665643 (Exim 4.92) (envelope-from ) id 1xHHwY-0001p0-VJ; Thu, 15 Oct 2026 09:40:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450133.1665643; Thu, 15 Oct 2026 09: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 1xHHwY-0001ot-Q2; Thu, 15 Oct 2026 09:40:10 +0000 Received: by outflank-mailman (input) for mailman id 1450133; Thu, 15 Oct 2026 09:40:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHHwW-0001nh-Fe for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:40:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHwV-007OTd-RF for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:40:07 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad09f76-e002-0a2a0a5209dd-0a2a45098e10-2 for ; Thu, 15 Oct 2026 11:40:07 +0200 Received: from [52.101.66.81] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad09f77-be1a-0a2a45090019-3465425145ae-3 for ; Thu, 15 Oct 2026 11:40:07 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by GV2PR03MB10950.eurprd03.prod.outlook.com (2603:10a6:150:278::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 09:40:02 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.021; Thu, 15 Oct 2026 09:40: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=F8cfpAgkHHP/T3X+kz7gspjvDn+c5xnkaKLRVfYrA0Mh06vWJEwTM9P3SNv6jIqdvzIZqundNr0vgegZLH2tKbPwoizNdG6CAA7ZFGtoTH9xVdFKsqXV2+s94o9JqzpDj6f/Q3at6UO4MSvjMRdpNTRk+TfQnuWGj5LiCbckdGH1Lf9xW6/txcfZLfDjrLLSHiyK6ybF0lSva02zk/NKO0dGaTyZWtjFz9VN+OPlpsPmWTSn5KLvgp08lT17+ogEcdOwkr2xlzoUdKueIo2zMrp5TGgxbY7ODwYJj6Se4wu+dfIGoSsrVL5h8w7ngZtO3usSvtUeQIgVsHFvkT6Gug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qLwOKCk319JEUbJ18BOpIQFKqtrtS/iFw1pAJT5wfAY=; b=n0DFJL4xGcjgP+XFRYkNsxcVzYQ1mWk8jPc89VNEghcnm1azbbDGoUAjca1DZb+XN6FwELDKmRl3YddLdQFsYpV1KBVGuy8Q0IBkiYF3H9AMLNdhJym+sFLXMap5E1Cdc9JXcz8emgqfpuXztC1KDnvhb/TO/FzZIT0guu0tfNIC7eRxFEbyjSEi/abb2nzKXq43gjcwKF6laiyNRWu8ZN4O7C5hbNDAr0L0zD5/73K/pf34iz+MhtLVGtXCaqTqQ1L+az2/cPa1T5IWtOkGoGBqj3Xf65uxFvP5iHOvtOEvp6YvDKey/ZknfkOmpFmOsfxgEkUbyPormC8OVOz8xQ== 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=qLwOKCk319JEUbJ18BOpIQFKqtrtS/iFw1pAJT5wfAY=; b=bKCuCUPyIO0krsCcCmd/m4jB5cIq1tC34kDz41OV5I3mIHaT1OUltt0pM8feLB/REO1C9U7DPwaHdEDl7+fv3EYwetWOC0JV3MyLfOHVFgMltljKRuID88wNCKTEyAwWjPgk9HaEs7KVAnsrVMWF5u0NIkzXgqDQYleinnrLhttqZ1aCU6x/WXeVIKHhDd5iPq0QexWAPEzjWjMgceCZ6FSTYeRYYJ5d8kidfLwnKbpibPqRWgWOmqiths+oniOZNI1rG78C10i6bMEyE9EKm5+/CzvC1gtXjNXurUJoDTa2SeMhv5jOtME8bo0rONNkp+VqSWki9IW52GbHhwbwjg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: Date: Thu, 15 Oct 2026 11:40:00 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 05/22] xen/arm: vsmmuv3: Add dummy support for virtual SMMUv3 for guests To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <2094abe1b6faba477e771390bf47921f80e7e0e7.1791328190.git.milan_djokic@epam.com> Content-Language: en-US From: Milan Djokic In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VIUP296CA0097.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:35c::17) To AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS2PR03MB9587:EE_|GV2PR03MB10950:EE_ X-MS-Office365-Filtering-Correlation-Id: 74db33a0-b137-4c83-5729-08df2aa0493b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|6133799003|18002099003|22082099003|260925021911599003|260925021311599003|260925022911599003|10067099003|11063799006|4143699003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: EejPYL76xHY+Sdab3ADtAENzICOm4uOCjFRwZvs3hIaWX9fcSXn/UKo2CX10hl/oQY5DM75j6nH9tKdwAN3HD+zPYSgPRQIAi6aMXIPn78YzQG0NSz6tTh4L2t+QC+cxSpHIsA4LZlhOfUocXfgXQh0jpCfYD+XKB/pOoSam87XUMpMi5XCYvmJUorT9ymmwc1VMy/8tRxmqwDDOt/cKYBUx5fDeGTmIKCi8zNpDI9AQ+EL0OWIu8yc/Pjt0rHmD4mdZikes4gxy+XIdCB6mc93SFQiQnn2Jm9pRwm/5mdf7bFcr4ZZdffgkNV6aP6BSkodKjf9ENbZFIjn3O/vbNOheg0djZsVEyy7nBx9nNXfG1MFYazTzPinbhmE70gNjn+M/cdGCIBU4tjSRAkvOKtNxibLlNLZGNzWxSgU9cL/MJhtdKRFML0m/ZsyU9ALm0hlImmDpZ+59+ut5SGFzrw7RvfS26TCzEfxvKPUz/suTY5ZhQzuUjvMbnPSvlS60SATocwC10y7S2V0B1/W2GODJxNcvAdwcG85+dHWVOcTOzo7vL3wX8KKCnRGlFKAPxouf8cQcuPvJUkf148xByNl4HElwSU7QjcruRBlkTP370HHJe9tiuvvhbP3QljNN803qRMv9rtpBccMxWgiSiZlnLhFNegtbuwrg0n9UWHA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(6133799003)(18002099003)(22082099003)(260925021911599003)(260925021311599003)(260925022911599003)(10067099003)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NkR3cFMxUWVsc1hiMUtuUDVSL3hYTE1Pb05tMDloWXNPYmVEemVoN0grb05q?= =?utf-8?B?a2R6N0F5dnBtYmdiV2oyZlh1bnhJZlNzSEFRWEpEc2M4aGIxcytUZVBNSEMr?= =?utf-8?B?bENPSU1RNjR2bU42K0Z4MktKbHI2VnpLc2I4RUNHd2VUbng4RDQwdmkwSms1?= =?utf-8?B?R2FNanFUdVRweWhtYkNzSldLYndnYUMvdUtMV2dDWW1PNWNreVhvWklXV2pO?= =?utf-8?B?NzFyYWdsRnZvc0MxbTkwcVRHbU9hajRsR1lIUVBHbG9Yd3grUCtSRnRIalIw?= =?utf-8?B?YjVkVVhJWSs5UVdEdGZ6bXcyY1dEMzRjRTM0alptTzEzS1JGK3NwSlI4ejlR?= =?utf-8?B?UnNaVnRuQThpQldGcmh0N0docDBWQjRtRkJScHJ5TnhLT0dwMFRJSWNyaklQ?= =?utf-8?B?ZitFcjFzMFdseUVKZm02UUIzVitUd21PQ2VWOWRHUnNVS0RYcjVmQlIvTUlk?= =?utf-8?B?N3Q0c2Zwa0x5WlI3Vm1paWZtMG1NV1NBOERzeERuUWppNWJrSForYW04UWVQ?= =?utf-8?B?T0VveHJaYlZ0WGxyYTdHY3RjYzNnNW15T0cwaGtqczhwdFJwT2NoMmxtTSti?= =?utf-8?B?M1lFRlR4Zm9nQlFoUC9US3g2V1EvT1F5bjRUZXRlNVNZUjhRS1pkTC9yanhN?= =?utf-8?B?amFWRXJQSkZjOEVXMnR3aVZuRUdaVkFhZ0xKcjdlVzVEODd4M1R5T0dqMS9j?= =?utf-8?B?eWh2NGVuWmdyZDdCeGdTeGkzRlNTcWVFeEk3N1VGY1YyTnptZWswcE45a1hX?= =?utf-8?B?ZjA1Zlc3Q3J3TFdyMjVYT0QramFEeXhvZjlOWWlGM1VOY2djazNLRFN4YmhG?= =?utf-8?B?R2h6dTBYQUJsaXR2QmlHQVVKVmJTOEM3VHJienptd2kvWTE2NncrVjU1YU45?= =?utf-8?B?b2hNNGFscWV0dC9saytJeExVdEdyK0lKUlRybURlejNMczJZc2ZHR1ZWWnBO?= =?utf-8?B?SWZKclJvemVGQUJjWDFDZnhMVEgwcGNsa2JXTHo2LzczVUpKblA1M3lSRGxT?= =?utf-8?B?dWs5aWVFd0tVR3BrOHQ2RnI2a04xVlJiaktoM1lKVEVUTzhtZXJPREJJNEJH?= =?utf-8?B?OU8xdE5VMGkwLzNVSDZtTE5INmFVcUlVV0p1TWlPWk5paE01c1VnZ1hSNkRB?= =?utf-8?B?V2VVTUFLN3J4S1k0NzJKQW9Yamt3KzZHRDZJb2tHZFR0NWlvQ0xqMnA5Mkd6?= =?utf-8?B?bDNPaU9RNHNNT0VKVWNMNTJnd3F3WGVuZTlNcW13b2k4UzRRV0U5bVFUK25H?= =?utf-8?B?bGx6MzNkOTJ0dCsvdmhnUm1vWHF5cXpRV3JHZUVSWkJLKzVjSkdRUldnNGd2?= =?utf-8?B?ZGdSWW1VdGpBcllRR3NocVlrTlR4cTJtYnVRK0RRbnhlSlJLeS91aHpteDRx?= =?utf-8?B?TjVVVjRXTERoRTRLWDgzZEkrSG4ranphMkVWTTcrdzBBMlZXZ3Z3a1p4SGZ3?= =?utf-8?B?MzVwczZES1NJSHUwWmQ1aEpjWVpJdGJHRDNySmJ3OEt2MlhNSHlXRElxd0Vv?= =?utf-8?B?a3ROWTA4eG9OdUt2WUI2RkZvZzBPcmh3QW9VVis5UTN5R1cyS2lqVkRVeFp5?= =?utf-8?B?c3I5M2x3bDhReFBxbTJVQXV5SHBUdUMyT1g4K2VtcittbEtVdkdIcmJmbmVv?= =?utf-8?B?QmhLdGhrRDcwbENzN3hTZ0gva3dKUUxWanRDU2dGUDdCNTJFUnZ5UWJ5ZzFV?= =?utf-8?B?a2x1V3poVndQY2FrRW5EWU9iSmdqVGptb0NJaFMyelhSRWE0SWJ0SEVkMDJZ?= =?utf-8?B?cWlMUlZxUXVIM3BiVWNuTzBnL2RkK2lRdFAyL3p5elhMQnpYeEwvTG9iNTR4?= =?utf-8?B?YlJieTNwUHdlYVlKTnJFLzFXZWdZN1lSNU1pNGx0WEw4VHEvOUZPdEN2U0F4?= =?utf-8?B?SkQzMTRDT3VpTUtOMS9YOGpFeSs4VThmL0JjVXViUDZxNHliSWc1SlNuelNk?= =?utf-8?B?UGtLVmUyZGhBL3dBVnJGQnNUclNhYUd0aHhyUG1XUnB2SzFHck82NzZXT3Z0?= =?utf-8?B?QjlpVkpreC9RRlQzRGlteHJWdGhZWTZKVDFmMUZkdzI5dGFhRTlWdEUwTm5C?= =?utf-8?B?ZkRPaVNGMnBOMFBTTnpNT0l1YUtqYTJhNk45K01OUDVJbFkrOUNQMkV0ckdy?= =?utf-8?B?NUhrN3YzcHNBNGJmYUViNncrTVphUGVNRFlIdVNjb1llOCt4bkI3VkhwZ3Bx?= =?utf-8?B?elJTcUxlcnlodFRsc2NIY3EyczZsQm9HV2YwNTVKRDRiTHBiZlNqa1BzWmd3?= =?utf-8?B?YjZydG5ubGZtdlM3QVZPQkZRZVIwaGNGZkRYa2dMZjZJWFpNakl6dDNhME0r?= =?utf-8?B?NTFKRFpHSVZmWUkyOWlYb2tjb05jVWxsbDBnMGEybzNPNkk5ZXg2QT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74db33a0-b137-4c83-5729-08df2aa0493b X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 09:40:02.3288 (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: ZDGOkdnkbmBloNzC+N878ELnBFiuCPXLtKy9talw0RdHW3mBpBwMi2E4/s0x3jza58uUuWKJ0qgiDPTP/lJljA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10950 X-purgate-ID: tlsNG-bad1c0/1792057207-3B0DD034-D96BEBEA/0/0 X-purgate-type: clean X-purgate-size: 17320 Hi Oleksandr, On 10/11/26 16:06, Oleksandr Tyshchenko wrote: > > > On 10/7/26 03:06, Milan Djokic wrote: > > Hello Milan > >> From: Rahul Singh >> >> domain_viommu_init() will be called during domain creation and will add >> the dummy trap handler for virtual IOMMUs for guests. >> >> A host IOMMU list will be created when host IOMMU devices are probed >> and this list will be used to create the IOMMU device tree node for >> dom0. For dom0, 1-1 mapping will be established between vIOMMU in dom0 >> and physical IOMMU. >> >> For domUs, the 1-N mapping will be established between domU and physical >> IOMMUs. A new area has been reserved in the arm guest physical map at >> which the emulated vIOMMU node is created in the device tree. >> >> Also set the vIOMMU type to vSMMUv3 to enable vIOMMU framework to call >> vSMMUv3 domain creation/destroy functions. >> >> Signed-off-by: Rahul Singh >> Signed-off-by: Milan Djokic >> --- >> xen/arch/arm/domain.c | 6 +- >> xen/arch/arm/include/asm/domain.h | 5 ++ >> xen/arch/arm/include/asm/viommu.h | 36 ++++++++ >> xen/drivers/passthrough/Kconfig | 8 ++ >> xen/drivers/passthrough/arm/Makefile | 1 + >> xen/drivers/passthrough/arm/smmu-v3.c | 7 ++ >> xen/drivers/passthrough/arm/viommu.c | 83 ++++++++++++++++- >> xen/drivers/passthrough/arm/vsmmu-v3.c | 118 +++++++++++++++++++++++++ >> xen/drivers/passthrough/arm/vsmmu-v3.h | 20 +++++ >> xen/include/public/arch-arm.h | 5 ++ >> 10 files changed, 287 insertions(+), 2 deletions(-) >> create mode 100644 xen/drivers/passthrough/arm/vsmmu-v3.c >> create mode 100644 xen/drivers/passthrough/arm/vsmmu-v3.h >> >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >> index 5c411a2310..003a8d45b9 100644 >> --- a/xen/arch/arm/domain.c >> +++ b/xen/arch/arm/domain.c >> @@ -672,7 +672,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) >> return -EINVAL; >> } >> >> - if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) >> + if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE && >> + config->arch.viommu_type != viommu_get_type() ) >> { >> dprintk(XENLOG_INFO, >> "vIOMMU type requested not supported by the platform or Xen\n"); >> @@ -728,6 +729,9 @@ int arch_domain_create(struct domain *d, >> >> count += domain_vpci_get_num_mmio_handlers(d); >> >> + if ( config->arch.viommu_type != XEN_DOMCTL_CONFIG_VIOMMU_NONE ) >> + count += domain_viommu_get_num_mmio_handlers(d); >> + >> if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 ) >> goto fail; >> >> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h >> index c3d2c4981f..70af0bf8b7 100644 >> --- a/xen/arch/arm/include/asm/domain.h >> +++ b/xen/arch/arm/include/asm/domain.h >> @@ -102,6 +102,11 @@ struct arch_domain >> #ifdef CONFIG_MPU >> uint8_t v8r_el1_msa; >> #endif >> + >> +#ifdef CONFIG_ARM_VIRTUAL_IOMMU >> + struct list_head viommu_list; /* List of virtual IOMMUs */ >> +#endif >> + >> } __cacheline_aligned; >> >> struct arch_vcpu >> diff --git a/xen/arch/arm/include/asm/viommu.h b/xen/arch/arm/include/asm/viommu.h >> index 95f82d9cf5..287595068b 100644 >> --- a/xen/arch/arm/include/asm/viommu.h >> +++ b/xen/arch/arm/include/asm/viommu.h >> @@ -3,9 +3,23 @@ >> #define __ARCH_ARM_VIOMMU_H__ >> >> #include >> +#include >> #include >> #include >> >> +/* data structure for each hardware IOMMU */ >> +struct host_iommu { >> + struct list_head entry; >> + /* IOMMU DT node used to establish virtual to physical IOMMU/SID mapping */ >> + const struct dt_device_node *dt_node; >> + /* Used for dom0 vIOMMU instantiation (1-1 MMIO regions mappings) */ >> + paddr_t addr; >> + /* Used for dom0 vIOMMU instantiation (1-1 MMIO regions mappings) */ >> + paddr_t size; >> + /* Used for dom0 EVTQ and GERROR interrupts (1-1 IRQ mapping) */ >> + uint32_t irq; >> +}; >> + >> struct viommu_ops { >> /* >> * Called during domain construction if toolstack requests to enable >> @@ -32,9 +46,15 @@ struct viommu_desc { >> >> #ifdef CONFIG_ARM_VIRTUAL_IOMMU >> >> +extern struct list_head host_iommu_list; >> + >> int domain_viommu_init(struct domain *d, uint8_t viommu_type); >> int viommu_relinquish_resources(struct domain *d); >> uint8_t viommu_get_type(void); >> +void add_to_host_iommu_list(paddr_t addr, paddr_t size, >> + const struct dt_device_node *node); >> +void set_cur_viommu(const struct viommu_desc *desc); >> +unsigned int domain_viommu_get_num_mmio_handlers(struct domain *d); >> >> #else >> >> @@ -56,6 +76,22 @@ static inline int viommu_relinquish_resources(struct domain *d) >> return 0; >> } >> >> +static inline void __init add_to_host_iommu_list(paddr_t addr, paddr_t size, >> + const struct dt_device_node *node) >> +{ >> + return; >> +} >> + >> +static inline unsigned int domain_viommu_get_num_mmio_handlers(struct domain *d) >> +{ >> + return 0; >> +} >> + >> +static inline void __init set_cur_viommu(const struct viommu_desc *desc) >> +{ >> + return; >> +} >> + >> #endif /* CONFIG_ARM_VIRTUAL_IOMMU */ >> >> #endif /* __ARCH_ARM_VIOMMU_H__ */ >> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig >> index a92cfbea98..40d072822f 100644 >> --- a/xen/drivers/passthrough/Kconfig >> +++ b/xen/drivers/passthrough/Kconfig >> @@ -40,6 +40,14 @@ config ARM_VIRTUAL_IOMMU >> help >> Support virtual IOMMU infrastructure to implement vIOMMU. >> >> +config VIRTUAL_ARM_SMMU_V3 >> + bool "ARM Ltd. Virtual SMMUv3 Support (UNSUPPORTED)" >> + depends on ARM_SMMU_V3 && ARM_VIRTUAL_IOMMU >> + help >> + Support for implementations of the virtual ARM System MMU architecture >> + version 3. Virtual SMMUv3 is unsupported feature and should not be used >> + in production. >> + >> endif >> >> config AMD_IOMMU >> diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile >> index c3783188e3..c8f0a5f802 100644 >> --- a/xen/drivers/passthrough/arm/Makefile >> +++ b/xen/drivers/passthrough/arm/Makefile >> @@ -3,3 +3,4 @@ obj-$(CONFIG_ARM_SMMU) += smmu.o >> obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o >> obj-$(CONFIG_ARM_SMMU_V3) += smmu-v3.o >> obj-$(CONFIG_ARM_VIRTUAL_IOMMU) += viommu.o >> +obj-$(CONFIG_VIRTUAL_ARM_SMMU_V3) += vsmmu-v3.o >> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c >> index bd0689664b..21b82eba85 100644 >> --- a/xen/drivers/passthrough/arm/smmu-v3.c >> +++ b/xen/drivers/passthrough/arm/smmu-v3.c >> @@ -93,6 +93,7 @@ >> #include >> >> #include "smmu-v3.h" >> +#include "vsmmu-v3.h" >> >> #define ARM_SMMU_VTCR_SH_IS 3 >> #define ARM_SMMU_VTCR_RGN_WBWA 1 >> @@ -2829,6 +2830,9 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev) >> list_add(&smmu->devices, &arm_smmu_devices); >> spin_unlock(&arm_smmu_devices_lock); >> >> + /* Add to host IOMMU list to initialize vIOMMU for dom0 */ >> + add_to_host_iommu_list(ioaddr, iosize, dev_to_dt(pdev)); >> + >> return 0; >> >> >> @@ -3181,6 +3185,9 @@ static __init int arm_smmu_dt_init(struct dt_device_node *dev, >> >> platform_features &= smmu->features; >> >> + /* Set vIOMMU type to SMMUv3 */ >> + vsmmuv3_set_type(); >> + >> return 0; >> } >> >> diff --git a/xen/drivers/passthrough/arm/viommu.c b/xen/drivers/passthrough/arm/viommu.c >> index 0c0efd668e..3401e4f7d9 100644 >> --- a/xen/drivers/passthrough/arm/viommu.c >> +++ b/xen/drivers/passthrough/arm/viommu.c >> @@ -2,12 +2,54 @@ >> >> #include >> #include >> +#include >> #include >> +#include >> >> #include >> >> +/* List of all host IOMMUs */ >> +LIST_HEAD(host_iommu_list); >> + >> /* Struct to hold the vIOMMU ops and vIOMMU type */ >> static const struct viommu_desc __ro_after_init *cur_viommu; >> +static bool host_iommu_list_incomplete; >> + >> +/* Common function for adding to host_iommu_list */ >> +void __init add_to_host_iommu_list(paddr_t addr, paddr_t size, >> + const struct dt_device_node *node) >> +{ >> + struct host_iommu *iommu_data; >> + int irq; >> + >> + iommu_data = xzalloc(struct host_iommu); >> + if ( !iommu_data ) >> + { >> + host_iommu_list_incomplete = true; >> + printk(XENLOG_WARNING >> + "vIOMMU: Cannot allocate memory for host IOMMU data\n"); >> + return; >> + } >> + >> + iommu_data->addr = addr; >> + iommu_data->size = size; >> + iommu_data->dt_node = node; >> + irq = platform_get_irq(node, 0); >> + if ( irq < 0 ) >> + { >> + host_iommu_list_incomplete = true; >> + printk(XENLOG_WARNING >> + "vIOMMU: disabling support because IOMMU @0x%"PRIx64 >> + " has no usable IRQ (%d)\n", addr, irq); >> + xfree(iommu_data); >> + return; >> + } >> + iommu_data->irq = irq; >> + >> + printk("vIOMMU: Found IOMMU @0x%"PRIx64"\n", addr); >> + >> + list_add_tail(&iommu_data->entry, &host_iommu_list); >> +} >> >> int domain_viommu_init(struct domain *d, uint8_t viommu_type) >> { >> @@ -33,12 +75,51 @@ int viommu_relinquish_resources(struct domain *d) >> >> uint8_t viommu_get_type(void) >> { >> - if ( !cur_viommu ) >> + if ( !cur_viommu || host_iommu_list_incomplete || >> + list_empty(&host_iommu_list) ) >> return XEN_DOMCTL_CONFIG_VIOMMU_NONE; >> >> return cur_viommu->viommu_type; >> } >> >> +void __init set_cur_viommu(const struct viommu_desc *desc) >> +{ >> + if ( cur_viommu && (cur_viommu != desc) ) >> + { >> + printk("WARNING: Cannot set vIOMMU, already set to a different value\n"); >> + return; >> + } >> + >> + cur_viommu = desc; >> +} >> + >> +unsigned int domain_viommu_get_num_mmio_handlers(struct domain *d) >> +{ >> + if ( is_hardware_domain(d) ) >> + { >> + struct host_iommu *hw_iommu; >> + int count = 0; >> + >> + /* >> + * For hardware domain, vIOMMU per pIOMMU is exposed. Number of >> + * regions required for the configuration space is equal to number of >> + * host IOMMUs. >> + */ >> + list_for_each_entry(hw_iommu, &host_iommu_list, entry) >> + { >> + count++; >> + } >> + >> + return count; >> + } >> + >> + /* >> + * For unpriviliged domains, single vIOMMU is exposed and requires one >> + * region to cover the configuration space. >> + */ >> + return 1; >> +} >> + >> /* >> * Local variables: >> * mode: C >> diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c >> new file mode 100644 >> index 0000000000..ea3b5bb34d >> --- /dev/null >> +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c >> @@ -0,0 +1,118 @@ >> +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +struct virt_smmu { >> + struct domain *d; >> + struct list_head viommu_list; >> +}; >> + >> +static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, >> + register_t r, void *priv) >> +{ >> + BUG_ON("unimplemented"); >> + return IO_HANDLED; >> +} >> + >> +static int vsmmuv3_mmio_read(struct vcpu *v, mmio_info_t *info, >> + register_t *r, void *priv) >> +{ >> + BUG_ON("unimplemented"); >> + return IO_HANDLED; >> +} >> + >> +static const struct mmio_handler_ops vsmmuv3_mmio_handler = { >> + .read = vsmmuv3_mmio_read, >> + .write = vsmmuv3_mmio_write, >> +}; >> + >> +static int vsmmuv3_init_single(struct domain *d, paddr_t addr, paddr_t size) >> +{ >> + struct virt_smmu *smmu; >> + >> + smmu = xzalloc(struct virt_smmu); >> + if ( !smmu ) >> + return -ENOMEM; >> + >> + smmu->d = d; >> + >> + register_mmio_handler(d, &vsmmuv3_mmio_handler, addr, size, smmu); >> + >> + /* Register the vIOMMU to be able to clean it up later. */ >> + list_add_tail(&smmu->viommu_list, &d->arch.viommu_list); >> + >> + return 0; >> +} >> + >> +static int domain_vsmmuv3_init(struct domain *d) >> +{ >> + int ret; >> + >> + INIT_LIST_HEAD(&d->arch.viommu_list); >> + >> + if ( is_hardware_domain(d) ) > > > Looking over other device emulations in Xen (vpl011, vgic, etc.), I see > that the host (hardware) MMIO range is also exposed to direct-mapped > domains, as there might be a non-hwdom 1:1 domain. Xen even has a > specific macro for that: domain_use_host_layout. Here, however, the > guest MMIO range will be exposed to a regular direct-mapped domain. Is > there a specific reason for that (is this intentional)? > No, this wasn't intentional. I'll update the implementation to use the host MMIO range for direct-mapped domains, consistent with the other device emulations in Xen. > >> + { >> + struct host_iommu *hw_iommu; >> + >> + list_for_each_entry(hw_iommu, &host_iommu_list, entry) >> + { >> + ret = vsmmuv3_init_single(d, hw_iommu->addr, hw_iommu->size); >> + if ( ret ) >> + return ret; >> + } >> + } >> + else >> + { >> + ret = vsmmuv3_init_single(d, GUEST_VSMMUV3_BASE, GUEST_VSMMUV3_SIZE); >> + if ( ret ) >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> +static int vsmmuv3_relinquish_resources(struct domain *d) >> +{ >> + struct virt_smmu *pos, *temp; >> + >> + /* Cope with uninitialized vIOMMU */ >> + if ( list_head_is_null(&d->arch.viommu_list) ) >> + return 0; >> + >> + list_for_each_entry_safe(pos, temp, &d->arch.viommu_list, viommu_list ) >> + { >> + list_del(&pos->viommu_list); >> + xfree(pos); >> + } >> + >> + return 0; >> +} >> + >> +static const struct viommu_ops vsmmuv3_ops = { >> + .domain_init = domain_vsmmuv3_init, >> + .relinquish_resources = vsmmuv3_relinquish_resources, >> +}; >> + >> +static const struct viommu_desc vsmmuv3_desc = { >> + .ops = &vsmmuv3_ops, >> + .viommu_type = XEN_DOMCTL_CONFIG_VIOMMU_SMMUV3, >> +}; >> + >> +void __init vsmmuv3_set_type(void) >> +{ >> + const struct viommu_desc *desc = &vsmmuv3_desc; >> + >> + set_cur_viommu(desc); >> +} >> + >> +/* >> + * Local variables: >> + * mode: C >> + * c-file-style: "BSD" >> + * c-basic-offset: 4 >> + * indent-tabs-mode: nil >> + * End: >> + */ >> diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.h b/xen/drivers/passthrough/arm/vsmmu-v3.h >> new file mode 100644 >> index 0000000000..9f4c86abd5 >> --- /dev/null >> +++ b/xen/drivers/passthrough/arm/vsmmu-v3.h >> @@ -0,0 +1,20 @@ >> +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ >> +#ifndef __ARCH_ARM_VSMMU_V3_H__ >> +#define __ARCH_ARM_VSMMU_V3_H__ >> + >> +#include >> + >> +#ifdef CONFIG_VIRTUAL_ARM_SMMU_V3 >> + >> +void vsmmuv3_set_type(void); >> + >> +#else >> + >> +static inline void __init vsmmuv3_set_type(void) >> +{ >> + return; >> +} >> + >> +#endif /* CONFIG_VIRTUAL_ARM_SMMU_V3 */ >> + >> +#endif /* __ARCH_ARM_VSMMU_V3_H__ */ >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h >> index a1491f9cf7..8863e2e457 100644 >> --- a/xen/include/public/arch-arm.h >> +++ b/xen/include/public/arch-arm.h >> @@ -335,6 +335,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); >> #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA 2 >> >> #define XEN_DOMCTL_CONFIG_VIOMMU_NONE 0 >> +#define XEN_DOMCTL_CONFIG_VIOMMU_SMMUV3 1 >> >> struct xen_arch_domainconfig { >> /* IN/OUT */ >> @@ -463,6 +464,10 @@ typedef uint64_t xen_callback_t; >> #define GUEST_GICV3_GICR0_BASE xen_mk_ullong(0x03020000) /* vCPU0..127 */ >> #define GUEST_GICV3_GICR0_SIZE xen_mk_ullong(0x01000000) >> >> +/* vsmmuv3 MMIO mappings */ >> +#define GUEST_VSMMUV3_BASE xen_mk_ullong(0x04040000) >> +#define GUEST_VSMMUV3_SIZE xen_mk_ullong(0x00020000) >> + >> /* >> * 256 MB is reserved for VPCI configuration space based on calculation >> * 256 buses x 32 devices x 8 functions x 4 KB = 256 MB > BR, Milan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:41:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:41:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450140.1665651 (Exim 4.92) (envelope-from ) id 1xHHyG-0002Zp-Bk; Thu, 15 Oct 2026 09:41:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450140.1665651; Thu, 15 Oct 2026 09: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 1xHHyG-0002Zi-8a; Thu, 15 Oct 2026 09:41:56 +0000 Received: by outflank-mailman (input) for mailman id 1450140; Thu, 15 Oct 2026 09:41:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHHyE-0002ZM-RO for xen-devel@lists.xen.org; Thu, 15 Oct 2026 09:41:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHHyE-007OzD-7x for xen-devel@lists.xen.org; Thu, 15 Oct 2026 11:41:54 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad09fdf-bab6-0a2a0a5309dd-0a2a4507aee8-38 for ; Thu, 15 Oct 2026 11:41:54 +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 6ad09fe1-b4ea-0a2a45070019-d155dd29f148-3 for ; Thu, 15 Oct 2026 11:41:53 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48c4649b35bso220144f8f.3 for ; Thu, 15 Oct 2026 02:41: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-48de0ac3ac5sm17573119f8f.38.2026.10.15.02.41.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 02: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=1792057313; x=1792662113; darn=lists.xen.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=g6cx/+bSRSzNbenAV9qMAYNJ8/wluukBmSju653PTBA=; b=eOA7+wns/st/uWIxTAx4DJHogrUu67KbOaQ1+7CNy0PddawSgcDMhGn8D3vjl+rQlM EDmhVitNQ56eq/4sPZ19NzGecSBlNW854uXlKlobLrNelXN3Eva+dBmfMQfxOUXBWVCu vH3kx/AkntrRfoc11smijAcHGqr8EWAk2z+xKpzpO3rEQcyU0Xh21uk0MEVCGNSbtNeA 6jPH2bTBsx7VsyL19Vd8aKFoyA6ei1U74EEKTR/Bdk/4zs6jOtxQzYhdQIkd3Qs2mszC rxS9Ivb2VvZo1if3TiiIQDijP+kbXntqInIW6kpJ1b5VaR0q7vaPdow6LtdJ+c2Iex/4 SDcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792057313; x=1792662113; 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=g6cx/+bSRSzNbenAV9qMAYNJ8/wluukBmSju653PTBA=; b=RRfj0iR5IkYp7oW8VeqUYjCsIkYR0O8PLl3QpjNKQ+bDl7K2QwiyDxHsO3VOmnUnQS 5VnFSwwDpGV79m1vITWxECnvIgo5G6QI/O5ZY820uHDzkjimQrnMNDnsA/fW0JppCEQj gFlK/XDl+1ajBqoGbRGT+7wdhNpyOZWlPWgzKyC3eIub0Wew0lZ4nAkgU40fb0yTPl0t X4wevK0JlFxHV1mqGXXHVPHEGeL4hrRVeWv2dVGApNzzSTo8+rrH4njbxv4UYX6r3/jr PthOiyjl9wLPi68375vIbIkG6pw8VTt6GfyxuAYyMS4onkqZkcoBkaNZaWKxdMimcjTb xFpw== X-Gm-Message-State: AFq9FYJK3RzikHFUc6tzuMOC1e2dP1XoBvjiBcJ+YhkUhk5VWx+0bSMh i5wSx5zJgc5AWn3kPjt1yaOvWR/20FtDguzzmgA7Cx18CRbKnXDo5JAtunLcTmvEaA== X-Gm-Gg: AYBFou0ALjP4ls0EiVTIVVdG7TD2/spEposLCdtoPZZpg9MA3MDZfVdfOoUkZF/bVlB ixNkzoaQTcwK3vkuWqQ90bjT1QQecOnTskOvvcARVsWD2lkH0IOsMr/tSAmVM6bXDtdG/u4tUqD O5j0iJtkWc/E2sDvo0LVi2ZaTKCd/TU9EErKkwv7l05PqrsgPKAV63BRAsvqqZ9Mshdwl79OgzO vFoYOEeN7dgCupCBIgSn7+NzPl4F2S63N87O8alUlf9n9KsEx7xjn80YNaMHgQaI+acEwCaB0TQ Uogr7UHJfj0Q9Yhzd3FuGeKmsny2AKzmCGNulH7U+j5ShAeVWrYFYgjzOegg8HYsL3Wg0sTE9cN 51hvzmA7NH3o4C7mSukEQw5dVunmpeSz+sIY1tyykV47K2o1zPas+UlpB3v6YMOQYH0UZPnWksO 7spfeyLa2wKjTdIOXHycPcP+8oNLJrqtW4PTgYrdVZzrrEFLAdpIAjpauc2pTIX7Pzh1XwNkJ/r x8IdbXB85UKMvdUnq2dpTtnP+Z7SA844Fu8FShflyUJixLf X-Received: by 2002:a05:6000:29c3:b0:48a:ffc4:72e0 with SMTP id ffacd0b85a97d-48dba7892f4mr23316461f8f.4.1792057311456; Thu, 15 Oct 2026 02:41:51 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 11:41:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen Dom0 fails to boot with "nvme.poll_queues=24" and "dom0_max_vcpus=6 dom0_vcpus_pin" To: Egon Ojamaa Cc: "xen-devel@lists.xen.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/1792057314-A76D2AE4-396A6864/10/78276251493 X-purgate-type: spam X-purgate-size: 1128 On 12.10.2026 17:51, Egon Ojamaa wrote: > I cant find anything in logs, so I suspect it does not boot to the point logging can work properly. > > I tried now to get somesort of log, not sure how useful, get IPMIscreencap.7z : > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270/+attachment/6008530/+files/IPMIscreencap.7z Judging from "nvme: `24' invalid for parameter `poll_queues'" there, "nvme.poll_queues=24" is completely irrelevant here. Following that I can't spot any other nvme messages, so I have to wonder in how far nvme matters here at all. (Needless to say that not being able to search the log, because it's all pictures, doesn't help.) The log above is, apart from early boot, only covering kernel messages. To us, the Xen ones may be more important here. I fear that without a serial console we may not be able to make much progress. If you're convinced (despite what I said above) that nvme does matter here, you may want to try getting in touch with the maintainers of the driver. Their insights or debugging advice may then allow someone here to come up with an idea. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:44:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:44:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450147.1665660 (Exim 4.92) (envelope-from ) id 1xHI0V-00034a-Mm; Thu, 15 Oct 2026 09:44:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450147.1665660; Thu, 15 Oct 2026 09: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 1xHI0V-00034T-KA; Thu, 15 Oct 2026 09:44:15 +0000 Received: by outflank-mailman (input) for mailman id 1450147; Thu, 15 Oct 2026 09:44:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHI0U-00034N-8C for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:44:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHI0T-0021c4-Du for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:44:13 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0a066-e002-0a2a0a5209dd-0a2a4505bdac-18 for ; Thu, 15 Oct 2026 11:44:13 +0200 Received: from [52.101.66.79] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0a06c-4cb1-0a2a45050019-3465424f4618-3 for ; Thu, 15 Oct 2026 11:44:13 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by GV2PR03MB10950.eurprd03.prod.outlook.com (2603:10a6:150:278::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 09:44:11 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.021; Thu, 15 Oct 2026 09:44: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=UmRnwfe+0w4BVjnvWswUk5i7CiSbLYTy4XXGVIkjhwcWTCOXdYJ2fOfw1Hbplk7AFLdgMv+/pBu0PEHWeP+kTNUlyofVZt22gH7kimXmu+7LUw8nR/Rnh5dIj5FYF1ZwKGiFCEuCYQq+j3UcBy8UgVDLImyGWNLL2D5BGh2NZEKe2zuMyjbkaNiSnxFQBcdhz7x/zJzhAVwEIsBxvYplbVnddGll/qz08YdsrNcNQ01jhvNWIB/3JKrrgVaiNNUw4WU68VT+IAsH/cNAq0WJPdM12N3hh1RT2peiyIQxqfWMMmoeoVkoLHPhsOvX6/MElAgRP2/Oe3b95lEekipvTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W6cUxlVTodAwFv/9vYCDJx4f0tguGJ1LA4TK+tsmmAw=; b=x2wYYlSg1fTwUfhaK4DGtNL/5PpBocV6+bRcI2lXYx3uI3k2RafZkIa74apAl2zn3FPo96+xhP1TRoSbAUYkMcgMEymTvSSm4uqHQ5WZMp5nSqHGNuG+I4dGPZ0CnabHx1prvZzAO5SOqUWksnUbp7FIxOguujpPVz+f/UG5lU1JpfKTF8X/eo+aFfHSX0feRBc1UWiLVVP4qDOj6bt6bdxzo2G2XXlXFRFKW5THFgz71Nj13f/lAFnnI4Svkb+2ScSV+f0wRPKoZr9otmT956R6jpe16xy8PPdNruTMBrO1i4evlxqNAeo6SbDPJX/C7EssonAqSlQPK6sn+tXc6A== 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=W6cUxlVTodAwFv/9vYCDJx4f0tguGJ1LA4TK+tsmmAw=; b=k0U56ju71qtmAYO5q/lAWVS/Z6Vhqq+nuavIfvgIqV2bjyoT/M7TRXeaEg/IVPGomnA3TsUVi7X+O+uQUS/DSvGyEtEww8TG82MsFo0x0DVO3253P5IexNqxETPI1bL1P/BKltcY6+8GQ7XJQSmu/s1m9zBSl1t2FP0pSpdFkH0oSjqBf0LkVK8ThIcPc/TudYj/ZxHQ6agHdcnEAmeJgkbJP1BOMycjWruJW9uRv6uSbz0g3n8FRAFT9+o49vq/0Ox0G+bbZU6Xty2My9mi/Wk5i7Gh2BYnP2L8B4OQACW0vREd59CBkjCPrhOLTLdNUjNfUjbjOeHwB10oxPC3eg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <865830ba-e094-4366-800b-7480bdb9e96f@epam.com> Date: Thu, 15 Oct 2026 11:44:09 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 09/22] xen/arm: vsmmuv3: Add support for cmdqueue handling To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <60e304f6-6c65-40cb-8b4b-1584e5c47272@gmail.com> Content-Language: en-US From: Milan Djokic In-Reply-To: <60e304f6-6c65-40cb-8b4b-1584e5c47272@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VIXP296CA0034.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:36e::19) To AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS2PR03MB9587:EE_|GV2PR03MB10950:EE_ X-MS-Office365-Filtering-Correlation-Id: 115f253e-c6ee-4e64-3c45-08df2aa0dd68 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|6133799003|18002099003|22082099003|10067099003|3023799007|11063799006|4143699003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: EkvqCwbIMLxEDfdpItnmr7VyqJf+15+UBjgtOmDq/iad4OmW+PPULgj+EOrZIX26PyOAwRHt13ZPRM0HO3SeWIGK1Vrnb3w/1BhvvWvnyJDVmxNgsKked75GElhprV91SGx2H3zukD+sUX9o4A9gRNrormv7kxnuE8zeRxLVxhcwY73iDDWRMmtzZ3x0n1PgQwUN3rovelisVXhLcTa0vUZeYzuWkZBYi8cqKwThZi357bscp0K4dYkZMmFo2Bf0UaagE43C86HCsERvtPTdQJQ5HQrgFXeSRa5Zg+us6sjLq7XUtqFE/oXHJSer6E6YYy9sL8ltmMxRfQEgaN1I4eFds+8VWXL3C3xqih3CYD+4NNlzQdVprNfkO3YoA13nvY8OMw1Y/SeN282Zjl888rTQ4iAWXTO+EXCaSw2URz/vlu5kJLgoqaeFCmW5p3sD7DZLeRketKhpFYQX84a8dL9j7F/4u4kGJdogVYpnG44rZneW0FHfpkVZ2ZiYd/hXAH1A5f4ZoQhu6ZxModTKUCpdMgN2Q+BlrOx2HQTagoDbIgjgz+ipB34HpXaC9BTRsbq3YRUcC3WtnFSNDhPL3A2uSuCSW3qXeY/FI0Ug4d3mjSFWDmNt7/NZyJOpTpn6TGi27SDcxy0EREY/Tlq/yaMlSEuo9gK/YN2Lp95wl2A= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(6133799003)(18002099003)(22082099003)(10067099003)(3023799007)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R2tBNDhWQ1JRLzZualJLY3VnL0U5eTVWQ2xldWM0b3F5MUd3cE9zd0lrVWlx?= =?utf-8?B?aFptTjZQT2p3c0w5dElOT2d5ODFDSzh1c0pEdGo5dGsxTHJ5RmxwdTB6ZGww?= =?utf-8?B?bklSZWQxU3dIT3RLUXhtQUNnZzRaQksybHROUTJ1YTdLRGtGbkNsczdIUDNV?= =?utf-8?B?MTFxUnpseWVPa3YvQnMvNmlVejQwbWh3WnVSeHdaM1Q0N2Z2YXJvaldPUWpJ?= =?utf-8?B?Wm1OazcyaVNzQUJQN1hHWUYweTNJdnJ4eE5WeURoRXgwWDQ1SCtRcjJ1WU9L?= =?utf-8?B?SWZZdVNuaTN4WEFyWnV6TUhOa0I0cUM3eUYzWk8vQ2NTcys4cFppak5COWNN?= =?utf-8?B?OFNReUI5VDdYUnlyQ0Z3TXVWTE5HZG1BU3RiYSttSVYzZmxVemVsUDF4WU5F?= =?utf-8?B?ZFNMVWZOZUFGVHJ5YVMrVFdhUENnSWJ5UHArWUpibWwrSkwwYSsremU1ZGVI?= =?utf-8?B?RmJRbzRWNTNqaGpWb3N5d2E1TWI1WFBjTmQ1aFAxcUtEY1JiaDJzMkQrdDdm?= =?utf-8?B?d3lLWlQ5QkhHV2J6SFdXSkZFWWZQSHhZVGxHeXBPKzgyT1pONFBhMURHWFhT?= =?utf-8?B?OGt6blZjaGNTTVVWNmdOd3NmcUVmYkZTZU1DY2hlK1FMWG9lUjBrWnRkb08r?= =?utf-8?B?T3hJZ0JnbVoxQkFSeDJmYTFyUDRjSDlqdzBSelJ1NFp6a3V5cSs2elZ4bDVP?= =?utf-8?B?b0I3TGQrd0FaMFh5c1VwNXBPb1NrcXFqZXpQekxOSERjWDd2SWc1K0tXc3h1?= =?utf-8?B?SDR2YVVFelg2QmFxZEl3UFQ4eElMTUNvd3dOSVY3YVhMaHk0c2poY2hKaEc2?= =?utf-8?B?OXpDeWc4R3BUV3QwUDhtYmZUU1NPdFVFaEhFc3NzeU1kbktYS3V3WjExcGxS?= =?utf-8?B?dzNIaW9aNGV4ZXZYZG1maGFoNjdpVHV1QUp4cTVLVXBjT1lKaWtzdjRSYVpU?= =?utf-8?B?TlZCVGs0cXc3aVpZOVhESCsvc0JxSTVuUkVYUVJqMWxsME9admIwVHA5dEtO?= =?utf-8?B?b1ZjaUV6K1hjOFBTUkZ6dGFjamJ4VFhZeHlmSnJPZEVVZ3BaVEFGU3BVV1dP?= =?utf-8?B?N2hpdnNJcjhybjVwZnFUUkI5b01ubFdwcGNsQ0g5SVhOUXRxWkFlSXdHVWR5?= =?utf-8?B?bEcySmlYdTBEUEVwRkQwVFBuNU1JUHUyUjVWZ1ZybTRIMGZkYnZNblVSRUho?= =?utf-8?B?c3Q2L1pyWTBBaWZZODA3SXpsbWdaN2VFMXBqM0pETm5xbDB6MThmaSs4ZDdi?= =?utf-8?B?MzAxczdJNGdxaFQxZmd4V1hxc2ZjTTczYzZvUmt0RmYyQzhZVU9kV0pIYTl1?= =?utf-8?B?cTVVYTRDNjA5KzBnQ3BMcFdRS3RZaVV2RUhVdUY2SXpxbEcxRFFlV2J1eStL?= =?utf-8?B?S0hFQlZjK0JYQkpTSU1qSDBxWG13UEFyaklZVjdxcVRpbnJ3V2NsdDB0dnZP?= =?utf-8?B?R2VUZ1VEOXJsb2VTWDFuMHFXTU9hRWY4YjZTcjRlbWZzalMzUkdFM1ZSd3ZT?= =?utf-8?B?cnI4WEZ6OVFlQ2JZcVRiMllWTE9PRHprZmlyVGJuQUs0WWFqak4yTXVFV0Rv?= =?utf-8?B?TWZYS2YxUHVWanhQd1EzaUdtaTI5ci9HMEUyTUFlWUwrNTVGMFN3NkVmSG9a?= =?utf-8?B?eWtvMW43WkJpTzJjMnFmc1U2ZXI1dS9CT0pvNHpCYkp3aXZUcHJNRzd3dEJM?= =?utf-8?B?R0lnUXhESmgvMVBJTlkrWjRqVFk1UHNOUmxNWjM3NHBCM3NGU1NkbkVvaTB2?= =?utf-8?B?TE9lclR6SStOVlIyaHlTSjVMemc4bVhtcCtVUXpBMjV2bXRCdDFTeHhKeG9p?= =?utf-8?B?WitqWXNzYVFRMElPbFM5SklhdU9RR1UxdWxZZVAvdFlKcXNXYzJPYnlaSzAv?= =?utf-8?B?dEgwclZCbE82T0FSRW1JQjVpSmlDeVR5bENUTkxmWHE5Szc4eDhTR2xidG15?= =?utf-8?B?M1haY29QVTd2c01QWGZzTmN3aXRLUkhrd0hMQ2JSODVlMDRmanVSdHJ5TDJF?= =?utf-8?B?Zk84TW14SWRGenRHZ2taMkZ0b3gyMEVlQ1ZDaGhFQTFPeXNKeFFUeTNwZG1W?= =?utf-8?B?UmZYQUtYWDAwWWRGUlFRVUgzcjZScU5yc040R1RFSmhOa1B6bm1MU2Q4bVNN?= =?utf-8?B?cWJ1TVVSbldlL0FMaHJINDhpWElhUlIySmQ3Sk4xRnM1NlBGNWgyODZkcnF5?= =?utf-8?B?TlV2WlhaY1pBMWFXM1dXamNTWVFmcmZubjZxOEZIZ0d4V3dkSHBuV0k4WXk2?= =?utf-8?B?ZkFXY3B1enVXS25wSXhGYW1VTHJ1QVRUY05uNGkyZU5ZRWlNU3l4MTBkQjd6?= =?utf-8?B?NnRhb1FKUytmZVZ4SzdGQzB3UEZ5czdXRzdHSlF6WXZWMzY3WmozZz09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 115f253e-c6ee-4e64-3c45-08df2aa0dd68 X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 09:44:10.8887 (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: OTOLOyIFr0el7frZjkwQoO1oFyLfJTuntps3tp1JTvG33IcaJfyDFg6/pjPTBxs5pkrksS2c4sb94yNJjaJZfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10950 X-purgate-ID: tlsNG-c201ff/1792057453-F6EB12A1-4A9708CC/0/0 X-purgate-type: clean X-purgate-size: 6905 Hi Oleksandr, On 10/10/26 18:58, Oleksandr Tyshchenko wrote: > > > On 10/7/26 03:06, Milan Djokic wrote: > > Hello Milan > >> From: Rahul Singh >> >> Add support for virtual cmdqueue handling for guests >> >> Signed-off-by: Rahul Singh >> Signed-off-by: Milan Djokic >> --- >> xen/drivers/passthrough/arm/vsmmu-v3.c | 127 +++++++++++++++++++++++++ >> 1 file changed, 127 insertions(+) >> >> diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c >> index c4fef6e8bd..10143927e7 100644 >> --- a/xen/drivers/passthrough/arm/vsmmu-v3.c >> +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c >> @@ -8,6 +8,7 @@ >> * This needs to be fully handled in the future. >> */ >> >> +#include >> #include >> #include >> #include >> @@ -33,6 +34,51 @@ >> #define SMMU_EVTQS 19 >> #define DWORDS_BYTES 8 >> >> +/* >> + * SMMUv3 command definitions >> + * Some commands are fully handled by the emulation layer, while others are >> + * currently treated as architectural no-ops because the required behavior >> + * is either implicitly guaranteed by Xen or not yet modeled explicitly. >> + * >> + * Emulation handled commands: >> + * >> + * - CMD_CFGI_STE >> + * - CMD_TLBI_NH_ASID >> + * - CMD_TLBI_NSNH_ALL >> + * - CMD_TLBI_NH_VA >> + * >> + * No-op/Implicitly handled commands: >> + * >> + * - CMD_SYNC >> + * - CMD_PREFETCH_CFG >> + * - CMD_CFGI_CD >> + * - CMD_CFGI_CD_ALL >> + * - CMD_CFGI_ALL >> + * >> + * TODO: Remaining architecture-defined commands are not supported (error >> + * produced), due to lack of support in SMMUv3 driver / emulation layer >> + * TODO: Range / per-device invalidation not supported atm >> + * TODO: Long-running command queue handling is not implemented (command >> + * consumption should be budgeted with asynchronous resumption). >> + */ >> +#define CMDQ_OP_PREFETCH_CFG 0x1 >> +#define CMDQ_OP_CFGI_STE 0x3 >> +#define CMDQ_OP_CFGI_ALL 0x4 >> +#define CMDQ_OP_CFGI_CD 0x5 >> +#define CMDQ_OP_CFGI_CD_ALL 0x6 >> +#define CMDQ_OP_TLBI_NH_ASID 0x11 >> +#define CMDQ_OP_TLBI_NH_VA 0x12 >> +#define CMDQ_OP_TLBI_NSNH_ALL 0x30 >> +#define CMDQ_OP_CMD_SYNC 0x46 >> + >> +/* Queue Handling */ >> +#define Q_BASE(q) ((q)->q_base & Q_BASE_ADDR_MASK) >> +#define Q_CONS_ENT(q) (Q_BASE(q) + Q_IDX(q, (q)->cons) * (q)->ent_size) >> +#define Q_PROD_ENT(q) (Q_BASE(q) + Q_IDX(q, (q)->prod) * (q)->ent_size) >> + >> +/* Helper Macros */ >> +#define smmu_cmd_get_command(x) FIELD_GET(CMDQ_0_OP, x) >> + >> /* virtual smmu queue */ >> struct arm_vsmmu_queue { >> uint64_t q_base; /* base register */ >> @@ -99,6 +145,83 @@ static inline bool smmu_get_evtq_enabled(struct virt_smmu *smmu) >> spin_unlock(&smmu->cr0_lock); >> >> return enabled; >> +}; >> + >> +/* Queue manipulation functions */ >> +static bool queue_empty(struct arm_vsmmu_queue *q) >> +{ >> + return Q_IDX(q, q->prod) == Q_IDX(q, q->cons) && >> + Q_WRP(q, q->prod) == Q_WRP(q, q->cons); >> +} >> + >> +static void queue_inc_cons(struct arm_vsmmu_queue *q) >> +{ >> + uint32_t cons = (Q_WRP(q, q->cons) | Q_IDX(q, q->cons)) + 1; >> + q->cons = Q_OVF(q->cons) | Q_WRP(q, cons) | Q_IDX(q, cons); >> +} >> + >> +static void dump_smmu_command(uint64_t *command) >> +{ >> + gprintk(XENLOG_ERR, "cmd 0x%02llx: %016"PRIx64" %016"PRIx64"\n", >> + smmu_cmd_get_command(command[0]), command[0], command[1]); >> +} >> +static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) >> +{ >> + struct arm_vsmmu_queue *q = &smmu->cmdq; >> + struct domain *d = smmu->d; >> + uint64_t command[CMDQ_ENT_DWORDS]; >> + paddr_t addr; >> + int ret = 0; >> + >> + if ( !smmu_get_cmdq_enabled(smmu) ) >> + return 0; >> + >> + while ( !queue_empty(q) ) >> + { > > This is unbounded loop, guest controls PROD and the advertised queue > size is big enough. Below ... > >> + int ret; >> + >> + addr = Q_CONS_ENT(q); >> + ret = access_guest_memory_by_gpa(d, addr, command, >> + sizeof(command), false); >> + if ( ret ) { >> + queue_inc_cons(q); >> + return ret; >> + } >> + >> + switch ( smmu_cmd_get_command(command[0]) ) >> + { >> + case CMDQ_OP_CFGI_STE: >> + break; >> + case CMDQ_OP_PREFETCH_CFG: >> + case CMDQ_OP_CFGI_CD: >> + case CMDQ_OP_CFGI_CD_ALL: >> + case CMDQ_OP_CFGI_ALL: >> + case CMDQ_OP_CMD_SYNC: >> + break; >> + case CMDQ_OP_TLBI_NH_ASID: >> + case CMDQ_OP_TLBI_NSNH_ALL: >> + case CMDQ_OP_TLBI_NH_VA: >> + ret = iommu_iotlb_flush_all(smmu->d, 1); > > ... TLBI does full-VMID flush and waits for the hardware. All of this > runs inside one MMIO trap with cmd_queue_lock held, so CPU could stall. > Yes, this is honestly mentioned in the design doc (Security > Considerations, Observation ...) and doc calls it future work. Yes, this > should be sorted out before driver can be treated as supported feature. > > So please treat my comment as a remark. For now, I would put a TODO > (e.g., above the while loop so it does not get forgotten. > Yes, this is a known issue. Addressing it would require significant changes to the SMMUv3 driver, so we decided to handle it separately. I'll add a TODO in the code as well. > >> + if ( !ret ) >> + break; >> + fallthrough; >> + default: >> + gdprintk(XENLOG_ERR, "vSMMUv3: unhandled command\n"); >> + dump_smmu_command(command); >> + break; >> + } >> + >> + if ( ret ) >> + { >> + gdprintk(XENLOG_ERR, >> + "vSMMUv3: command error %d while handling command\n", >> + ret); >> + dump_smmu_command(command); >> + } >> + queue_inc_cons(q); >> + } >> + >> + return ret; >> } >> >> static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, >> @@ -221,6 +344,10 @@ static int vsmmuv3_mmio_write(struct vcpu *v, mmio_info_t *info, >> reg32 = smmu->cmdq.prod; >> vreg_reg32_update(®32, r, info); >> smmu->cmdq.prod = reg32; >> + >> + if ( arm_vsmmu_handle_cmds(smmu) ) >> + gdprintk(XENLOG_ERR, "error handling vSMMUv3 commands\n"); >> + >> spin_unlock(&smmu->cmd_queue_lock); >> break; >> > BR, Milan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:48:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:48:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450155.1665669 (Exim 4.92) (envelope-from ) id 1xHI4I-0003fg-6c; Thu, 15 Oct 2026 09:48:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450155.1665669; Thu, 15 Oct 2026 09: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 1xHI4I-0003fZ-2w; Thu, 15 Oct 2026 09:48:10 +0000 Received: by outflank-mailman (input) for mailman id 1450155; Thu, 15 Oct 2026 09:48:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHI4H-0003fR-2g for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:48:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHI4G-0022FU-FX for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:48:08 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0a145-2eae-0a2a0a5409dd-0a2a450aa79a-34 for ; Thu, 15 Oct 2026 11:48:08 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0a158-f2d2-0a2a450a0019-d155dd35b492-3 for ; Thu, 15 Oct 2026 11:48:08 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48af27fe287so172543f8f.0 for ; Thu, 15 Oct 2026 02:48: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-48de0ac52d3sm17480853f8f.43.2026.10.15.02.48.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 02:48: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=1792057688; x=1792662488; 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=7y/7UezrENK+mL3tcIPSUv8DLzW7wwpglchcvQSHjRM=; b=c4kBkLg4XiExkQMW1sUF6Gz7CDyE26AugK3edaaOr/aLfgXVj+D7gxS2CD1uYvauNC Aj8KqcuSg4nLOlGMWc08ZHaX6sa0z9s4QJxEVFBTflvOsmsZI9SPpOi44F2Yc73iWD2P srqIhXc+HDZd757pFYHmNTQr0gU5x+9PKu8GGthSIPvXhZXLxfhCIJJ/H2sxpNXv/SIL NeDB17xCsH5+wha++d+k8Nll9mJoGdzgquNJUpYipyovqQnKx6Pl/tdkVjBQFndGIrwn VnLtUuhPN0O9AI5TXSYFiHxX+Lr+u697EH2VB8riwTDgkTaizJxnhHvcaXNg2tsVtQww Pc5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792057688; x=1792662488; 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=7y/7UezrENK+mL3tcIPSUv8DLzW7wwpglchcvQSHjRM=; b=cA7/mSJbQVDIBfw09Hh8dzFF6/3jfkMBXNUjnvlPN7eAo9Wf1OjrQb9Po8y02FV4W6 sy8KxpYKG7t2GX8FhJ9yrGge72HkVhboplZwzFsQZo/fMp7UQLHDvUL53/s/DITyjL6q eqH/Ji4AkKxBkk8sxx2yCdGF8I2S561RC5crANTVCOxdM50W1moJiVRecjUXCpftgHYu Sj+NHQlGhDLYpKZPkzVKG7WMFAT54ggc1vjo6RKxfNEY0K6u8Q85DEIbCDIE13omRH46 qdy8IM2zOqPhxX3eWWX5caYrBIF6uX29xodLsB8xo68Qrq3CVbiuKqPpBOh53rZRpWGH FpHA== X-Forwarded-Encrypted: i=1; AKwUvBw3upERch9JXAjCQYRQUOI8aMfM5eiZBenzmD2cZBFt4KCm8MDTY/Njrfo4LZY/A1rdme09XDustT8=@lists.xenproject.org X-Gm-Message-State: AFq9FYKypw3eBeKZa96s0+K4cR2EBC9EYuTuIPEYooRajWqPxwWpnxX5 U7/DulkqG9QCWJ+6rD5JeS6kS7DNOZFwbL+aCuWJQEoxZzNfiJ4DegaeXi34kEb4jA== X-Gm-Gg: AYBFou0iVh94b7F04OJblYXGFpFzO6KVBIq3NKi8kuU48IlEBH6tgbWE6L1EEpsN71/ 4r8q7CMo/Eic9nWsMGOrgCanlBZM7SsEZaNBInOHJzAcxLhuBMDyV81A43pud4KjitWYB2C4uCI pL+7AVR5BvQ+KnaFt6FdI+wSSlTFPM7cWArLCNzWPN+R0oVI/PCd3amhpLudCPJH1FkkaBoUPeI y9qb0fm+fPEMSrbL/zIBDFMzbuvBfIYNRQoq0NsRTZIk21AtXpHrie4rcFVgJVxLW47rIJ1vYg7 mAm8B6xVDcY5A+Sjv3RmbZbAwFnYf7BPe+nM/SFUa6+1mvI2F2ZLR6ZTBb4thtq8E1Q3kYDss5y JTDE1TKmiazUWAN7rnYLLGBj/4S306z+wXkDqNqA1cjdZuZiv8bpJ15sbNz6cQQ6Xsjkh1yceXw EdKyolMiygblO3gIi8d4YNaiMV1jzLR8muza2OpjIRsG2suGl3+pCkVz6Si2VrCO3UPY5/+7Q8O Bf3rKDNykvwk+/WfSzC5Bw57EVkT4GfbmAByA21KbPXGlYGpY0lxzGmZohkqIM= X-Received: by 2002:a05:6000:4816:b0:48a:f3c6:7bfa with SMTP id ffacd0b85a97d-48dbace50d8mr37190252f8f.52.1792057687671; Thu, 15 Oct 2026 02:48:07 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 11:48:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT 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: <20261015074512.221777-1-chunjie.zhu@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: <20261015074512.221777-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1792057688-50ECACFC-EF120E3F/10/78276251493 X-purgate-type: spam X-purgate-size: 1504 On 15.10.2026 09:45, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > With V_NMI_ENABLE set, the processor clears V_NMI and sets V_NMI_MASK when > it takes the virtual NMI, and writes both back to the VMCB on #VMEXIT > (APM vol.2 15.21.10). > > nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally) > V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never > copied back, so L1 kept seeing whatever it had last written, regardless of > what happened in L2. > > Copy both back when L1 has enabled vNMI for its guest. > > Signed-off-by: Chunjie Zhu Acked-by: Jan Beulich with ... > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -1027,12 +1027,18 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > /* > * 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. > + * enabled in L1. With vNMI enabled, #VMEXIT also writes back V_NMI and > + * V_NMI_MASK (APM vol.2 15.21.10). ... the section title used here. As said recently in other contexts, if you also want to name the section number, then that wants accompanying by the doc revision (to disambiguate). Same for the patch description, obviously, but in code comments that's yet more important. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 09:49:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 09:49:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450166.1665679 (Exim 4.92) (envelope-from ) id 1xHI61-0004Ed-Lk; Thu, 15 Oct 2026 09:49:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450166.1665679; Thu, 15 Oct 2026 09: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 1xHI61-0004EW-Hc; Thu, 15 Oct 2026 09:49:57 +0000 Received: by outflank-mailman (input) for mailman id 1450166; Thu, 15 Oct 2026 09:49:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHI60-0004EO-6D for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 09:49:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHI5z-006ngD-Bf for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:49:55 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0a1b0-e002-0a2a0a5209dd-0a2a4505c54a-38 for ; Thu, 15 Oct 2026 11:49:55 +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 6ad0a1c2-4cb1-0a2a45050019-b9ff1c12822b-3 for ; Thu, 15 Oct 2026 11:49: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a13ef7d4a80008425.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 15 Oct 2026 09:49:51 +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 A9FED80800; Thu, 15 Oct 2026 11:49: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=6RlUhvB6AHY8m8cD6GyZA12Spbn2MLCKxCBp/3ChPwM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=PRdRHQbqk2Do1cPyOIdezqMIGLv0PmjFEMFvTrytfoErgWiWEJIoxvXl/0E4GNYwK9L1U7+gc IO7MI7/N3iV3sWnxSWhYSZ25JdoN5RLtJZJfpzYiMouw5uxXK3UpmM7uu95AdPe+o1WZLpge+9c c0wfYWYLdBybtEjifSWeFQjT0fif47Ecm4h5uRuTpEqCWx0divw/UNCkSQzX3r9nms6MnuhIZTS D5FOQo0WHPyKDhhR2pO/+ffdN+EIvusMwboFHdzyp2imSBO+VuSQHEITfKFpby9LzPg8lgBdVwc gnJ7pv4fN0OoI0yYHLE+11mC8BdHZZRHVI0WdsnoNZDQ== X-Zone-Loop: 5f7294a7590bec1c131570b2680c65f1beb9c2690acb x-campaign-type: default x-transaction-id: ba6498d1-7e3f-4958-b9de-6b4ae1850cd4 x-swg-uid: 01-be0167d9-8409-4abd-b064-7ff9917f9f18 X-Mailer: Sweego Message-ID: <1792057791.8631fc262581453bbf619ec5b2062170.1a13ef7d4a80008425@vates.tech> x-swg-bid: 1792057791.8631fc262581453bbf619ec5b2062170.1a13ef7d4a80008425 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] public/vcpu: Fix incorrect VCPUOP name in register_*_phys_area comment Date: Thu, 15 Oct 2026 11:48:14 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.228.fccdf4703ccb23d3.1a13ef7d1ac.c84ef6a87e7070f4=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792057790892 X-purgate-ID: tlsNG-c201ff/1792057795-732B32A1-6BC5FAAD/0/0 X-purgate-type: clean X-purgate-size: 1498 ---=Part.228.fccdf4703ccb23d3.1a13ef7d1ac.c84ef6a87e7070f4=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This part of the comment is actually about VCPUOP_register_runstate_phys_ar= ea and not VCPUOP_register_runstate_memory_area=2E Fixes: d5df44275e7a ("domain: introduce GADDR based runstate area registra= tion alternative") Signed-off-by: Teddy Astie --- xen/include/public/vcpu=2Eh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/public/vcpu=2Eh b/xen/include/public/vcpu=2Eh index f7445ac0b0=2E=2E5aea6ca709 100644 --- a/xen/include/public/vcpu=2Eh +++ b/xen/include/public/vcpu=2Eh @@ -233,7 +233,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area= _t); * area=2E Note that as long as an area is registered by physical addres= s, the * linear address based area will not be serviced (updated) by the hyperv= isor=2E * - * Note that the area registered via VCPUOP_register_runstate_memory_area= will + * Note that the area registered via VCPUOP_register_runstate_phys_area w= ill * be updated in the same manner as the one registered via virtual addres= s PLUS * VMASST_TYPE_runstate_update_flag engaged by the domain=2E * --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.228.fccdf4703ccb23d3.1a13ef7d1ac.c84ef6a87e7070f4=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 15 10:11:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 10:11:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450190.1665686 (Exim 4.92) (envelope-from ) id 1xHIQu-0001BI-8J; Thu, 15 Oct 2026 10:11:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450190.1665686; Thu, 15 Oct 2026 10:11: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 1xHIQu-0001BB-5e; Thu, 15 Oct 2026 10:11:32 +0000 Received: by outflank-mailman (input) for mailman id 1450190; Thu, 15 Oct 2026 10:11:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHIQt-0001B5-LW for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:11:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHIQt-00FApW-2S for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:11:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0a6c3-2eae-0a2a0a5409dd-0a2a4503a8fa-48 for ; Thu, 15 Oct 2026 12:11:30 +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 6ad0a6d2-fae8-0a2a45030019-d1558031f04c-3 for ; Thu, 15 Oct 2026 12:11:30 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a0286c981dso17465585e9.2 for ; Thu, 15 Oct 2026 03:11: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-4a1bd97ef4dsm65621625e9.4.2026.10.15.03.11.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 03:11: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=1792059090; x=1792663890; 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=3wDlcm+UsGOUlIyU2aSur0r1yZnp3JNhL9jjIS/sHvw=; b=SNJuTtD/t7PsDho8Sn8MUtUAf7+qFZZKxeTxOkZxR5iizWf8P935GCZEZ1riFYZ134 hIOEJLfnaWu/3pnmJvIOfIhcV7ytHLl5UcnHZjiBy/gSUROciuhqf7VnEpBR5MD/nV/i Uzv6l4lXM6o0AXq93Rt0wFGWHstJCohX6gzarzN91oJxtckys36VMsPC/rCOf35UqdxC 47fr50/8C21sZStNYaVzUR9d2YYwAHwA0/WdRoRIh0coOiCpDNY8ii2QHI45xB6OKT+W Sn0YuU+/93O8X3tbYYu/pnimhRUHG9+JVQ/lXWBGMA0UpBhZA2rM3RbfAURCe3wYwfwD ZijA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792059090; x=1792663890; 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=3wDlcm+UsGOUlIyU2aSur0r1yZnp3JNhL9jjIS/sHvw=; b=sd7c6dbgqQv21MYmrnn9a7K/lGsuFADIeAuJt4OkOi/gGTh5oSMdIyBOf1AC3nWVIV 2sjiR53EpmEBJ8qCnU3nVVvd/f2BEpr7mDLptryzDHLNDpPDs1ihFuNQLabdkxffRW3G erGpMRl25Hme6Zj7HXafDI3N+rW1WUSdQJrrY7ZxvkhqvgdSXTsy4IvSRbnxX9xkgteu 7WAuLgZgPmBqp47TquTYjPtC4rO8fxvnuASAOfM05ZcA43sibyWF4CRINXpWvvsMbZg6 1nCpJykNga00/aXoFp3ifNOGg6c9IzyCPV/dOXe3USpWGktNaKWZ6S9KDlRpGlFyzi88 7M2A== X-Forwarded-Encrypted: i=1; AKwUvBxbbz3AmXnEKpu8XjXCmQBfnXl1RiN5PJyM5ZFqlUseYHJx02s+lCnn5LAA/AUHP0cq7PtKXzrvqJU=@lists.xenproject.org X-Gm-Message-State: AFq9FYIckTLZJgGX2CDGeGAeVjKW1EAts/OBkOx87iYqp29h8yLShyUA SMzAGMYG4qx5iyRas5a6tO2DIKg5c0bdKR/kULpDpgnGo7zT1hwpSDpnt7GYqaUL9A== X-Gm-Gg: AYBFou0ewpQ/DYijn0dBNtOlbPQqbw7FHn6lLq6eNzbaaDjmjGQGfA7LYXavD1rVcUC YGT6bGdcTEa4kfyw00YynnPqLPcyb9rTi+tY/JKqtQdC4t6Qh+OrJbB7pD9dgzkxwnI9LZudKj2 CVrvY7akxIkIuHRpBQ9sTjnK8G3x2E1Av8M3amAC8AqPeYaAt0HAoKFVmK5BKkcHcQzOCVIhc9N erP0mjZFf1E1SCFL6hU+A4CVqqwOLJgTK+naV9PSVAsUsVH3UHTPgsqJD3L1hyXpKh7cDQ3EWVT +/MeIZF+T//94dzCizXN+5SYUD0sc3t4bktlwUz/t6Ei+FEllzEo0oGQ3NxfmpbpWT8/Ns7Erv1 6gS2dbo9HwfdqPkceIvH36kaM5MFPYVcW4n2eLdMtm9jvyR4Z3YKLcMNEJegj0s5Sl14B91DBuF KRA+d4EfhGqAPFh8pA5CNf5zVij37ojL7sY1Z58oZeoXAHqrI+OikV/UQGAWC3/dcj8LY53/PvA sk+DCf/cAjhiwPurhdjVmChvnKyX9/TYVryq/+e23QBanoqUWLTt8VCoCdf2RntOi+INtUEYA== X-Received: by 2002:a05:600c:4ecb:b0:4a1:6916:798 with SMTP id 5b1f17b1804b1-4a18e4a3f69mr368823125e9.14.1792059090326; Thu, 15 Oct 2026 03:11:30 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 12:11:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] public/vcpu: Fix incorrect VCPUOP name in register_*_phys_area comment To: Teddy Astie 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: <1792057791.8631fc262581453bbf619ec5b2062170.1a13ef7d4a80008425@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: <1792057791.8631fc262581453bbf619ec5b2062170.1a13ef7d4a80008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1792059090-74E874E9-ACA8F625/10/78276251493 X-purgate-type: spam X-purgate-size: 373 On 15.10.2026 11:48, Teddy Astie wrote: > This part of the comment is actually about VCPUOP_register_runstate_phys_area > and not VCPUOP_register_runstate_memory_area. > > Fixes: d5df44275e7a ("domain: introduce GADDR based runstate area registration alternative") > Signed-off-by: Teddy Astie Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 15 10:25:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 10:25:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450207.1665696 (Exim 4.92) (envelope-from ) id 1xHIdr-000449-B3; Thu, 15 Oct 2026 10:24:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450207.1665696; Thu, 15 Oct 2026 10: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 1xHIdr-000442-8D; Thu, 15 Oct 2026 10:24:55 +0000 Received: by outflank-mailman (input) for mailman id 1450207; Thu, 15 Oct 2026 10:24:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHIdp-00043w-ME for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:24:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHIdp-007Xhp-36 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:24:53 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0a9f2-e002-0a2a0a5209dd-0a2a4506b7d8-2 for ; Thu, 15 Oct 2026 12:24:53 +0200 Received: from [40.107.209.50] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0a9f3-195a-0a2a45060019-286bd132d0d3-4 for ; Thu, 15 Oct 2026 12:24:52 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN8PR03MB5042.namprd03.prod.outlook.com (2603:10b6:408:da::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Thu, 15 Oct 2026 10:24:49 +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.0522.013; Thu, 15 Oct 2026 10:24: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=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=aRtGmX3Ty58lWncRroMh722zB+G6sBobBrtS6LxvzpJy6G8pnP+teHKFmIZmu1B/7xCvNfuunwTKwnPNgNacRMV/aUFFxiq/CNXqYgkIcOC+YVBIJweEUHA7XuSNHHVF6PGe4x7Efmp2kQFqX0q3qvGKeLnuRDU8+6FFEiUQElDFJZmO8WydwBNFIPJfgeC8hXbMXJWIuWMoPPU5iUS/sQoUgKIHuLFkiZBsdkHkJE83k/BgI4H13hXlEADRqTjT6G9+AfmfZPrlGKxs4TtPCjQ9whu3KkXn1FJNRQ1Pki+vgZJnePDyQx5hnyoNX7rG9ibKV6fQ2UK8HZk+DMHjZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9jGpdqPUhyIPQ/EBqhacEufO6gxtrXQuZjIUXpQGaj0=; b=qT9QSToq3V/Aeb+7esmwd3VealRm/eNOSQ0P6+FiYYov18e/oGyRQrmP2w3re4gIFffx/o7ecHPCfkmzvHsfJDneCecj4ksRI3e42oI3EimfMMS5Y+yNfi6ApkwbUy3WsxYGhCbSW70utn0ciWrzEWe3iok13lDwKWSdnfUJF+rORC509Ggcg6rPQ6q3be/46tVNatMhHeYL1WgV50o1VU7sPkP/94rbeuFRmw0XAsKOwUBiTADZ9r4HUQKkX0ammwIfcUtMeeS5XBxZsmFKmSCdVQbD+3rg1JWzvagYzL3Cyzap3dvplC4QCoQgjdp3T/Ll+9CZV+GWT8fEWQY41A== 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=9jGpdqPUhyIPQ/EBqhacEufO6gxtrXQuZjIUXpQGaj0=; b=nAl0vafLje9w1Brc/ZcahoSwzsNBQdpnYzv2Huj8vc7rMiqb8gUIDDTykNrzC6nyhVZHjEdjGpnY70w6/7WNgWSIRUyVITtQv6GJjQmSJMznXQKk+wxLb4vXjupAyzNhzt42V8LecaGnCDADwTnjmnTEQISqj3urCIAGbMkfxQ0= 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, 15 Oct 2026 11:24:46 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: [PATCH v1] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT To: chunjie.zhu@citrix.com, xen-devel@lists.xenproject.org References: <20261015074512.221777-1-chunjie.zhu@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: <20261015074512.221777-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0201.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::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_|BN8PR03MB5042:EE_ X-MS-Office365-Filtering-Correlation-Id: 1f7c7403-0b36-45fd-d771-08df2aa68af0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|18002099003|22082099003|10067099003|5023799004|261009223027099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: 284VhRlO8/gOSfolP1KsglshBDvoc69WAajQo83OgVfGl6M7eOxOjorMsV92NN3v4NkfUPcFWHGAiAGNbPXTUxGyfshZNt3z2S3BIlbrXhRtJERlr8AS9gU/po5SlHeRmrduZ2ulaKWIYbFF74hHGNg96jiHl1lvIqVxgvVtaHvBOcZnZf9wYOk2yvrf0CYX1d5JTZNrJdP5Mv/Z6W8xu1MkM0pmkK+IVPc0Dxmk0PBbXVKVJ6MAjFNwQ9JuqqLhtRnIKiaMxE5GjLlt9FvxE+tlbb3d7FrcOI1XqE5D9P8oITZv8oeT92vjXQ9tXOe0+peNPPFsA414G1zbt1Yq1PavH6O1FiDmS/YSv++WhjYj0jijsalIZlhuiXCtp78I5GZ1Thj0x3KOCbcVvofZMbiDkryxj/rWxYp5L5a99W7TbdXqg6MAUUDOfutMt5UyLRGxGmCvi8cXj6moIzJCZXJSEduz4uZa+yinMgP6LbYZFuINdx4QmQkPjoQvREKyANKYiUGzNCxkcqmKXGcnioLwaIrwj8Gol++RwH96wBpWGw3eJwScnk/cjqH74LB0ACg9p3I9bflde717bfh70004HaeDg6yY1QVNoAewBweEsQpJfvhYOW8kvbSVYv7EfRTmQ2r3jszkO9G+2A9IYUaj3CRXaE90td8piJNEvsA= 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)(18002099003)(22082099003)(10067099003)(5023799004)(261009223027099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?emlUaVFLdlFMWjJOSlFUZ0gyaTZCVFJXNTA1ZTNCVWZiMmpDN20vaklyUk5l?= =?utf-8?B?OFlqdHdkQ1BoQ3MrMVVLb0JGUDU0ZXNma1dNUFN3REt2c2lheGdodFdXclFa?= =?utf-8?B?anM2ZWR5NEJtelZrdXVmN1E1VUtLTWtrWGRGRElwaUNod2llenB2aG43RU5V?= =?utf-8?B?K3FjQmZldHBkRlU2cEVHalNBSmxuZUdrbjI2cVNicU9tQnduN2NTV3lRcnBH?= =?utf-8?B?dWRDTzVtbXFEbjNYQ2NabDJaV05DbWVoZFRYZzdrZnRNUURVTFFNLzU4eSto?= =?utf-8?B?aFRmUWtqRVZLVWwrZm9Yak44ejZBMVRlM2xEN1d0QXhXRloyelBvakVab1lN?= =?utf-8?B?YXMyQm5yWEwrS002ZmFwdDZXV1dZSytEeXdUNFpGL2dRWk90eGZPMmNUamlR?= =?utf-8?B?OHN4UlFyVkQ4YndVejN0MmZINXQxek9wMjdEbGxwOWJKOTR2bWhRTFRUdU5W?= =?utf-8?B?Mlp0ZEh4aDE0QVJERkVuNHdhd3ZUM2dNaytyUzJaZHJJbVpOcUZmWmNwaDJF?= =?utf-8?B?ZHJ3TUJjOTVIMDR5SHhDcVozcFpJck1XRTRZM09oaTFxUnY0UEhzN2lRbk9w?= =?utf-8?B?em9HOWN1NkZPRlVNWjMyZkJFMHpWN1dWSG5kaFhrQ0NuUXJOREpFNDMwL29v?= =?utf-8?B?dmNLanFOYVBXRzg3dGtNRm1Ka1Q2ckpqTGhueDYwZGJ0T3haY0hTNnhuSFdL?= =?utf-8?B?VlFmUlB4VzFDYThKV094ZU5vVERzRU1GZ3dXTlZpYmYzU1pQTHpDN0pUTm91?= =?utf-8?B?SiszZDJRT05VemoyZGNBekhXZXdkaWgxSXJ4T0FuMXE5Tmt5a05TVmp5N01N?= =?utf-8?B?Q2swbDRYNVdpOXUxaUhlcXRFQTVNMGJ0ZlAweWxVenFmdHFxTW9BZ0JIb0g4?= =?utf-8?B?VDRaaXJFNHJDNDVHOHc2QXVONHY5b0oycmFkYVpLMDB6dS9nWDh2aVNjSWY4?= =?utf-8?B?WEpLMkt5NktzZDErbGdHM2pFSTJLYTZza2U4ZWVTVFRJN2lsVlIwNnBTZ3VR?= =?utf-8?B?dEZyb0o3VTAyRkFCbm54MndDaG4wRkN4aDA3aklUajNjdlZKWXF4dG1WdUFo?= =?utf-8?B?bmRkTHVjVnNHSHJKakE2b1ZTTVVJd0xhbTNmZ1RrcEQvWjR3WGdkZnJGSHZi?= =?utf-8?B?SlhYRDlSTENpVFViYk1LV0dHUWwwRFBBUWN2R1hoUitCeUQrM3R2WjhkcGZK?= =?utf-8?B?TFFQbGQxNjF0WVlCT2llbmc4MmtMdUNRazlBNjBVODYzZ2NqM0V1SEppbjBy?= =?utf-8?B?Y3R3N3VoK0FNNlZQV2JuY3RFSnh5aTdzNlV3dS83OEY5UmxXcnRQM01ERE1v?= =?utf-8?B?UVcvOUQ4OFordU5DR2JmYTB5bkhPdDZ0WmZJTjFaV3lISEJYdlV6UDd1cFZL?= =?utf-8?B?S3J6bWJ6V24vREprYmNiSloxWU14Y0djaWZtK3czOWVGZmZJRjAybDNENGRZ?= =?utf-8?B?ZVVTV1pOQnZvUGNtcXNmbUY4K1FmeE03Y3Z1VytaeVExUUVETDVWTytsdllO?= =?utf-8?B?MmdvaFk2UjB1QXpZSXI1c2ZiMTh6S21HelVEeTRoVHREbGR3SnljRkdDcG5M?= =?utf-8?B?MzAzbGhaT3M4MmMzOWFrZDY5YTE2NWFvY01UQURnNHEvbzBjR2R1dGxhMFpm?= =?utf-8?B?NHcyVHJ2UVJVc0lLRnNKYXJuM1IrL3gvOWhkR3RWN09RRjQxdUhkcHdrNzB2?= =?utf-8?B?MkdjTXdXM1pkKy9oOURRZTE2bTYwSnRZQW1sUWdtUkZQYks0NWhhS3g0MVR3?= =?utf-8?B?aDNiZ1NUNHArSzZGNzBKa0s3ZGFuRjNFalh4cFgzZDloWGkyMGhwNWJEN25w?= =?utf-8?B?ek9qakF4ZU5QNUE5VllGYytiYkdBTTg0SENDVS9GeVB4MGFaQXp5K1ZjWlFw?= =?utf-8?B?ZE9xMEloSFM4SENQc1RZMmNtVGw2cmJ1eGxIUjJTNXFla2t5Tk5jenZWYmo2?= =?utf-8?B?cDJCc3pFK056dzFoS2psUWhnZDVrVUpicjZNME03SEpQUEtHemNiU0FkNHV4?= =?utf-8?B?em10cDYreXBHU3AzOUpGZGM4L3VkaUIydjNzaElLanFNVXI5NjEvSUxFemFW?= =?utf-8?B?UnhlcVRja09TUDdOOHFPVzhia2t2cXlGUTd5WFZpU3ZPSEE5V2xhSk4zdEpO?= =?utf-8?B?WW9sSXo2UmhldGpvVmI5UHk2WHhhK3FsT2VidTVpV0dNUjJmRm1CdkV2VU91?= =?utf-8?B?cFZsNFhFbXZrWnc1OXRDWjRacmJSbWFoazcrVDk0M3Q5NHYrQzUxb1ZzaE44?= =?utf-8?B?dHdXekc4NmNlNnI2SEd0V2U2N2hDR0RkM3B5WURoK0hzM2ZqMWYyRUtDMHhl?= =?utf-8?B?SkFIRndPeGVQWjJaeHQwcUQ1dFBodGtUdkkyL3hBbWpLb1dOZ0t2QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f7c7403-0b36-45fd-d771-08df2aa68af0 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 10:24:49.5696 (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: Q27qVDZUsROcPuK9Q8v7NyrwKepMTe4tmC8tnKNT+kUlttLheMb2Ur/PUx5dqmGvN9sD2ga940/slG3CzNk/ags240oVjOYwxZwYLuodf4I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB5042 X-purgate-ID: tlsNG-16d1c6/1792059893-FEA7477B-A00D30ED/0/0 X-purgate-type: clean X-purgate-size: 2409 On 15/10/2026 8:45 am, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > With V_NMI_ENABLE set, the processor clears V_NMI and sets V_NMI_MASK when > it takes the virtual NMI, and writes both back to the VMCB on #VMEXIT > (APM vol.2 15.21.10). The processor also does the opposite on IRET.   Really, what you want to say is when V_NMI_ENABLE is set, the processor manages V_NMI and V_NMI_MASK automatically, and writes both back... > > nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally) > V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never > copied back, so L1 kept seeing whatever it had last written, regardless of > what happened in L2. > > Copy both back when L1 has enabled vNMI for its guest. Fixes: 86a203ab8d38 ("x86/svm: Support vNMI on capable hardware") > Signed-off-by: Chunjie Zhu > --- > xen/arch/x86/hvm/svm/nestedsvm.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > index faacfe007832..ecd89eb43f06 100644 > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -1027,12 +1027,18 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > /* > * 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. > + * enabled in L1. With vNMI enabled, #VMEXIT also writes back V_NMI and > + * V_NMI_MASK (APM vol.2 15.21.10). > */ > 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; > + if ( ns_vmcb->_vintr.fields.vnmi_enable ) > + { > + ns_vmcb->_vintr.fields.vnmi_pending = n2vmcb->_vintr.fields.vnmi_pending; > + ns_vmcb->_vintr.fields.vnmi_blocking = n2vmcb->_vintr.fields.vnmi_blocking; > + } > > /* Interrupt state */ > ns_vmcb->int_stat = n2vmcb->int_stat; The patch is ok once the comments are sorted, but Ross has a pending patch removing the "fields" infix.  I can take care of this when committing. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 15 10:37:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 10:37:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450221.1665704 (Exim 4.92) (envelope-from ) id 1xHIq1-0006zj-Bp; Thu, 15 Oct 2026 10:37:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450221.1665704; Thu, 15 Oct 2026 10: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 1xHIq1-0006zc-94; Thu, 15 Oct 2026 10:37:29 +0000 Received: by outflank-mailman (input) for mailman id 1450221; Thu, 15 Oct 2026 10:37:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHIq0-0006zW-8T for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 10:37:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHIpz-00EcDQ-LQ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:37:27 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0ace4-e002-0a2a0a5209dd-0a2a450bb4b0-6 for ; Thu, 15 Oct 2026 12:37:27 +0200 Received: from [40.107.209.39] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0ace5-b7e8-0a2a450b0019-286bd127dda9-3 for ; Thu, 15 Oct 2026 12:37:27 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV3PR03MB7501.namprd03.prod.outlook.com (2603:10b6:408:19f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Thu, 15 Oct 2026 10:37:23 +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.0522.013; Thu, 15 Oct 2026 10:37: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=ESptemlv9OTtY9V+bMsx88dSaLOAUAkeWYtmYVIAf5Q6PrIy2yfNfoOVDea8DpkxTN1uXBsvjodqfcAt6e33GbeCL+otKOZRT/zPSxJu2eTFxhBkLy/lTvaU7dPiP9b0LSGjXVTCdML5M3R758A7c16T8qxyxovLH1VLqDBWyKmQa0SL7c4gC8MkgEYd8T2BSh7F5WbtiQ3o8e6y+D6eYoM71BeDQBU+ubHFWH2KqPQe6VJY2uiyHC4SckTpkLsPIuIl1Q1VfI3punDfSKN5rh4VTcTAmySM/fo7k8GNieQJUbLZgO+hs3M67JMzFIQKlL2Hsk01+YKBPzbk9Te7zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hjfznOE2Too69mTl2oG0BG+QegdFquffWU9s9fkMleQ=; b=YDDqdYSIl2Gy1bdLPM7Fvuw2DQhL9jr175yrYo5nGFqdt9HFAiTlG15hr+I4JogUQutpXI1C+c3vY4kmTAzevSqfyxa8QYs47GAx+GXFBRFqCXArUxuIb9dIxIEtgSu1qqdNUlghYgvdZPE00702Hd4adP78auCD5KdwiVJIr3AG+UxZEQTTehg2qP+d+GLw5NG/ucgekhjJrfTQH6NxH9UP7gyfvq1F4E4gIF3uLhrngQeMW/K2v2mK4xJFgbOnec19X/woMCUxX3EGSZa/FONgxzQ2JKuqgfUx3tmuk6TZCnZJyKyCXZTN97jkx13dRX0Mlsae5+PDwWlfY8jyzA== 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=hjfznOE2Too69mTl2oG0BG+QegdFquffWU9s9fkMleQ=; b=JgD0EkAjUe3NJTMDCywoTxktBqpOhtUROhhdjbWES8Gg4dtpr/nMlJx+d5sDVBJJiQkQEK0IIhHNxGRE/EeGe/fQu4YK4NG1Ko4S6qPuvHB5fDENJreVi6TfVf3Kw9pXLtRQA+mYJXCxx9zLFBX6g9rB/xFDUWaB0AaFEhNe1LQ= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <716a13d4-9fd8-41bf-b475-08d0747ff442@citrix.com> Date: Thu, 15 Oct 2026 11:37:19 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH v4 2/3] x86: use __builtin_popcountl() for arch_hweightl() when available To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <9e48f405-4e99-4258-921e-2948f0d6754d@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: <9e48f405-4e99-4258-921e-2948f0d6754d@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0325.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:39a::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_|LV3PR03MB7501:EE_ X-MS-Office365-Filtering-Correlation-Id: 9d785bcd-a671-497b-7921-08df2aa84c3e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|6133799003|22082099003|18002099003|10067099003|11063799006|261009223027099003|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: tJNOqcmmbeR8ta0M4hS93IPpjzVZ8NID8nqAPF+QD1VEhUuup6JYirzPIsjXNvgsIux5U2qxNM2TAqinwleO8Fsyx61zQCJITIlnLIP1eXnrk2OL4iVI7y9KspQtHsS8oPUUw9aoNu5IpC5ezwqHrNec7SOYFMWwQuodSNr/sbgAOW/DLsfDakfTILLwZ6sdsTi0BX9FGXiEoGLxHBnoqqdvBcNEhO+2CLzeFxGieCEN5F8JYWN9RVxZE6vlRNjovy/v/abfbpKhxiXTaam4s+d21KAnHpoZko9oK0aSa9feh/SZEZlz7DFQtCumLImKX7NPoyclChGK3v6ZNSflohaO4fq2NAwBd7NvYYm3gR8lXxk/EzAxnw4gQL3UdameY3MN35NRm6fLRN+B+Z0gE+748f8sqr1j0iJA2pcQILJLjJzAdCDfj6QDXPu545UOmxQuHmvmUtwpiugQ72x3aC85lnkk6dLNfv+wYS/3al/KVHjwHIY8UZmJx30O9XBe5bvskoYJvQmrjalsRo6BJ8+T1ELIGzmhHyQ+1QFsKjydNUvdgRxYTrF6ZFN0ZMaOOEM3a6ngB4a6kcjhEat1xe6IxCGX0V3telQd4ze6kR2LGXWqyzpt5aajQsSEBeZP9+6r6UmJ6PnlywfsE2kbSGNpDQ5to+FY3CtyUYuLV3M= 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)(6133799003)(22082099003)(18002099003)(10067099003)(11063799006)(261009223027099003)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L0hVU0NoSUpBaVhFVllZcU4vZEVxc0phcWRPVllRTXhOWkszV3R4MlJGeGxn?= =?utf-8?B?WkpMMFRKUXdLOUtabzVyTzhTYXNyZTBNT1pNdXovM0tPcFI3RS8vZUxVc1k3?= =?utf-8?B?WU1vckhuK0orZTlXWGpiZ2x0cHhqTlRNZ3kyM1FXeWgycDdzNXZVU082a3Y4?= =?utf-8?B?SSs0b3dDakYyZExMa0dVaFFHRUR1ZTdOSWJnSEoyRWJXZDFYS2dJaFRGUXg2?= =?utf-8?B?UUt2TEw3OStkWktkU1J6bFpEaGt4cVZhMmJNdHg0b3FSVjJScGdtS1c0K1BO?= =?utf-8?B?TmpuUVJob1ovRXhMb2lJMFlaZGkrN2VOb0lKQmNLcFlvcU1tTnpFTjZGemdh?= =?utf-8?B?VmZ3RDFKME96RGtEdmhMVmRZMlQweGVIQVJFUUtDMDRxNTFBK2VTc1UrMVFo?= =?utf-8?B?dUlhVlE3MW9sK25xM1RFNjRocDRhUG0rVTBKTWdTVDdIMktLdEFrSm9iMyth?= =?utf-8?B?eVhjMW83ZmZhK2JHZHJhbUFDUzF5bThNdUpSR1dRRE9GQXlFR3lJLzlpR1FZ?= =?utf-8?B?amszNHdnMFlsbWJZUmFTRDNHSjd4R05ZbW5nSmF6eFJqeXJYdXZZSlV4VXZo?= =?utf-8?B?Tlg1VmZNYUxadUVnbjZrcW1KenhVVC9rUzZVVTY5R0ZSWlFHbmxSUGhaYm45?= =?utf-8?B?c0NHYXM0VFpVWTJPKy9IOVBoNmkvOHRDQnZJWEYwWHRobTBjNWRZbVNLMWpF?= =?utf-8?B?NnIwcXpkMnlUODdmZllZbDYvd0lDWWdEZVdyVytSK0tnRjRqbVUrelVCZE5r?= =?utf-8?B?Z25Va1Z6b3BvS3haQkdpYmphVGR6YXlpN0U3UHNTUVlYYldiUkVtWnh6TmdQ?= =?utf-8?B?MmxXU3drZ1hjRDduM2NUaVF4NmtDSWJrbVgyZWRXUUY3SWs0OXpucjBJbkxU?= =?utf-8?B?eUtYa20relcyR1BrbzRhbU9CWHNjVU5MdFRabkVCdHlXa29tdmIrN055WE53?= =?utf-8?B?OU9sOE1OSitkRDlaSkhRRURxajd6QmRJbXVrZ1ZsM0VNdjA2S2U2Ri9CazBU?= =?utf-8?B?b2lacTFqb0VubE1QdWdVeTFyY1NqSElGVlBIZ2VJSkFnL0Q2QjgyVXBZWWx5?= =?utf-8?B?b0NyeUwrQXkyazcyMUNtRHJOYzNRUThibDhITHlhZU93RUVNdlVQR0pLbS9w?= =?utf-8?B?L1JmZ2VwYXhPbTgrYU5UZ1A0S3dlaUdsaWFrR0swUGNyazU0ekU1SXlCUlRi?= =?utf-8?B?RExrWjlPVHFqZmhqcm9TeHMvQmFCOXlFS3NseHRMc2tOZ2NMTm5EajZUMEFI?= =?utf-8?B?TDVhUjdlZm9iY1daSTRxU2VSak9YREowcTc2WWlIc2dDR0NDNENPbDMrMmF0?= =?utf-8?B?ZFNNM01OSUFvQ2pLRGVNRjd1UjFGbmNiYXVyVWhhL0dIVnVJbCsvU202Wlpk?= =?utf-8?B?bWU4V2VlVFBJRTBXa09lN0Z3cVAvL2l6QThZZGowOTBpR09hd2hnREQ2NENo?= =?utf-8?B?UDhRMHFTU0dtSys0TGs3YWYvdzFHK2MraXBvQVlrcXRvY1dJcU96TjZKSCsw?= =?utf-8?B?OGJFNEZwR1ZqdFBvYWNUa09GR2VpTWxMWlhCSUFEYjk0WXc3YlY5V2QyT3FS?= =?utf-8?B?UDRGSnhmSzhlYTJjWFZRQ3ZSaktFQTU2eG5Gc0R5Ylh5TTlacXZ5c05OVitT?= =?utf-8?B?RlU5M2x4TE1XeVRIMEFwQXVIYVRqMHp0Z0JSQmhMM2ZobzU2SllLWVZJN1NC?= =?utf-8?B?cmJjT0hqTFliL1NnQytiZktzQ2ovOWluVG44R3h1UklFUWIzSXQ2dGR1d2tF?= =?utf-8?B?YWlGbFZOMlZRL3JZNGNwWXBERGJVendpbXNITUM0dW92VUZFVmhXdUdaWGRJ?= =?utf-8?B?U3lheEFKQVpaeXlXK2ZhMVViOE10c3kzMGNid2wwZ3d4ZDlNemI4VWpjRFRN?= =?utf-8?B?R2swVHZmblVWaDdRQzNHdDBNUVFIc0UzOFpGTHFwZUx5NVlpcHh4cXRXYkFx?= =?utf-8?B?SU45TThVYWFuSjV3cVpsREhEZnNaclJTUjVWMVBCR2EyTjd2cG1IY0lzK1Vn?= =?utf-8?B?QmtGZ1p0SUhkaTZBOTIvNFRjRWVFNzIrSkNIYVRjcWk5SkNBQ3Jac1hkVVll?= =?utf-8?B?c2Fta2xNQzBGZ3JXMkk0L3RnNk93aXdYS2ZPQlF6Q0FqYzBLMUJnblNYci9W?= =?utf-8?B?UUJQekJ3MVJpWnFpdWhBRkVUeHhlUjA2SFN2ekJsYStFc0g0Z1ZOT0FKWlo3?= =?utf-8?B?VVNrbmM3RkJOYUhWUDBmOXkzMXZzZXoweFI1b0dtUXJSeWVDUWV4dTRlWGpk?= =?utf-8?B?aXhWQXBnL0Q5YjNBSm1wdEpTd01yRloxN1RVVEhBMlZFbjVXakhPWTl1amxV?= =?utf-8?B?L0VCQ2hIV1l5MjFpdnRQaHZxeFdYUTRHcS9GN1gvMVEvMjQ1MGRhQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d785bcd-a671-497b-7921-08df2aa84c3e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 10:37:23.3816 (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: QvRasK/YJIzUFXreXjSKBNb1H16ef+1N7SD+PZUTIDiJVFgCLsRzPXgjFpJd+tRprmWh7o38Be5M5Nqv2EQIkBV5tq0gukBbMjzZEFthG+0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7501 X-purgate-ID: tlsNG-42698a/1792060647-A92CC9EA-6FD1A5E9/10/78276251493 X-purgate-type: spam X-purgate-size: 1527 On 15/10/2026 10:10 am, Jan Beulich wrote: > Use the respective compiler builtin when available; no need to play any > alternatives games in such configurations. > > Signed-off-by: Jan Beulich > --- > v4: Re-base (re-do). > > --- a/xen/arch/x86/include/asm/bitops.h > +++ b/xen/arch/x86/include/asm/bitops.h > @@ -500,6 +500,9 @@ static always_inline unsigned int arch_f > > unsigned int arch_generic_hweightl(unsigned long x); > > +#ifdef __POPCNT__ > +#define arch_hweightl __builtin_popcountl > +#else /* !__POPCNT__ */ > static always_inline unsigned int arch_hweightl(unsigned long x) > { > unsigned int r; > @@ -525,5 +528,6 @@ static always_inline unsigned int arch_h > return r; > } > #define arch_hweightl arch_hweightl > +#endif /* __POPCNT__ */ > > #endif /* _X86_BITOPS_H */ > This is needlessly complex. diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h index 557cee03baeb..c38680e8888c 100644 --- a/xen/arch/x86/include/asm/bitops.h +++ b/xen/arch/x86/include/asm/bitops.h @@ -504,6 +504,10 @@ static always_inline unsigned int arch_hweightl(unsigned long x)  {      unsigned int r;   +    /* If compiled with a suitable baseline ISA. */ +    if ( IS_ENABLED(__POPCNT__) ) +        return __builtin_popcountl(x); +      /*       * arch_generic_hweightl() is written in ASM in order to preserve all       * registers, as the compiler can't see the call. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 15 11:04:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 11:04:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450243.1665714 (Exim 4.92) (envelope-from ) id 1xHJGO-00042l-GA; Thu, 15 Oct 2026 11:04:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450243.1665714; Thu, 15 Oct 2026 11: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 1xHJGO-00042e-Cz; Thu, 15 Oct 2026 11:04:44 +0000 Received: by outflank-mailman (input) for mailman id 1450243; Thu, 15 Oct 2026 11:04:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHJGM-00042Y-JV for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:04:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHJGM-008dF3-0D for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:04:42 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0b33c-e002-0a2a0a5209dd-0a2a4509e958-46 for ; Thu, 15 Oct 2026 13:04:41 +0200 Received: from [52.101.193.34] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0b348-be1a-0a2a45090019-3465c122f4f1-3 for ; Thu, 15 Oct 2026 13:04:41 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN8PR03MB4929.namprd03.prod.outlook.com (2603:10b6:408:79::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 11:02:36 +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.0522.013; Thu, 15 Oct 2026 11:02: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=qBzhzMu+Q+0hL1VZqmm4I0iE3AH655h4dCtEjr9ZFCq4WKKynX4hvAtwJRr+ydI2+qsE2x+vtbEguOmiaSg1So3nunwhJ4U9D2f7HLcUklMaln3EYnaVU4wkHVk4156n62Ozzv2ZaSgtU2wFd5obr3cCVhxMFCVDLCpxUB3Elnv63jQyYjF9ngS70SxDi066uCcImed2LvJ02k8Mb/EmKOG4u0IhYydJ97rLLOodpx0EzDdGfFmLGkjBinVo4mvqicAwx0gZ6OfR6DJzVTe9rCMkVCUyHE8/Kc9P8vYpAhJnLeSImpqu5ShvmB7tWLs145p+0mZooqxWct5dVF02Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TfUJrXhRvGh2qeFVXoPGBKATcwO46JYNDu14aBtmUQw=; b=ty18D2lgFz62c+KaS2/BHLkAxK5veNcv7cYTmGDGLPka563W7imAWpYuXRi2ErzURVQXtdetHLIVuy8GvrN4L8Nc2wn6P+m6XC88dIxQbNjTOSnExuW9PZiMDWmsLuWQnWf5idy7XB6yk8ngRcjMl4axfLlfyVqMTPVSKyIFyY3wYzIUXfUiUIvwqKW8b9F7D2Q590bwLyNSoWokIIlI2cMNcMrSxKw7NF2rjxVGTY3SIz4kHewE+V8L4wu4wFi7/DFppRmW7PxMg7rcIZROtRt5JC1Y37eMzq7O4Zr1Vd0PcLZpgxzeN4DAUz3sDgBdokbPhqInvnSWtuTCCZxSsg== 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=TfUJrXhRvGh2qeFVXoPGBKATcwO46JYNDu14aBtmUQw=; b=iK/OY8LV3HLWuzcA1FTPDhWzTTJ1bNhpO8EvQrSxBg9Lc4NCjdpm7H83j4e0AvG5/u8BvC0mgsBgVP8ehu6P8xXgDqk5YC8dgnACaBLxFR5F1BBpi93Yi6N4921aMisCHJLmGPOuELtYQh9AKG+hpa1MwYV+N0hxUF3EUIWJiNc= 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, 15 Oct 2026 12:02:32 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xenia Ragiadakou Subject: Re: [PATCH 1/2] amd-vi: set the size flag in the IOTLB page invalidation command To: Jason Andryuk , xen-devel@lists.xenproject.org References: <20261014135143.34220-1-jason.andryuk@amd.com> <20261014135143.34220-2-jason.andryuk@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: <20261014135143.34220-2-jason.andryuk@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0315.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:197::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN8PR03MB4929:EE_ X-MS-Office365-Filtering-Correlation-Id: ac75eb3d-9bfa-4496-61fc-08df2aabd216 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|10067099003|18002099003|22082099003|3023799007|4143699003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: NyUojdf7fXJkCs3SQv3ej/4y/dlGpQi2Qwxbhqf/Aez2tWnzRYfd5+DyXwsqEZPzUwNbDMiOeC8xDdUmqAreNTCJA22ed6jmYA0UVgrPpzk2sfEIwKUEQ91jGnv6BzWxVnwNHOIjWx3M8bXbC9ydNDXsjs6hmgq/Hgk/IKSbjD8YHNSjpNYjQzXZFPSwhxQ3PGKBlvORWX8dBdxp0tV/VLwNdEzn3+ImSCCP8CIMCo9PjKX/istMrx9k6dfaaLZ6FUJv/f2y4jMv1mXPeOt7412q/atYlB/WycCMqof3iZiTH4KlR1bVCunkj8k+XGMf/iDXRzjTsiKcz49q8OoX2C8c3Z6LN+ViVta1PD/Uxro3uqKdTyTRhkJ9DziXSwatodmxothag+puCU/n3vd4eO+dwNu2Q7hZEev3lS++x//iTzN/FEQNd1Tj5BXyqI7gfsl7ViZ7hd2Du9TR8cTxhRkNcpmoq6JfacPo9Ql/vOQwv74yTwFz72sGRs6XzMUiXo2QsgmD8RkrppoPqApvn5FYvisjOOhL8btJ/TEUpcSf9DCPYugd1pZplR+cduwNJBw69qTBttWjBOoiAryAu9K42CRKbw9Och4Ot3CE6lHJ1AGx5FmFamUkO2n/+0FS8gE/1BOZ0PPef+UsBqE/OanPSQLoR5isHjoA5RbLmCo= 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)(10067099003)(18002099003)(22082099003)(3023799007)(4143699003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YVREOTNQRTJJK0xEblUvNXdrL0tTZXlWRlFIUGUyS21ON2tCeGtOSmN3NStL?= =?utf-8?B?dmNsNCthcklNT3B0Y01VWHp6NGIzcmVtNzJncm9iMGtGMzlLVFNQK09WdHQv?= =?utf-8?B?UTBRSStIV0k5OG0rTE15a3ZHeDc3UzdFOHJGR2Q4bXNEWFhrbGo3MFdCUjlQ?= =?utf-8?B?M2FOdmJTNkxtZ1NuUEhyWnRHTmw2UC9qT1ROTlg5dGREZWNYM1g5MkoxbTcw?= =?utf-8?B?RDNnejhlSXZOWGR0QUJNRnlaaWRmdzlVUW5ldjNTRUdsdkRDeGhCdE9FV2tV?= =?utf-8?B?TFgvRlBQWWVyQ3VNU3llUkYwbEQxWi9Pam9uNWJsNE5SV05uNVpaditFNmdp?= =?utf-8?B?YVNqY0xreTJqbWljWG92N2lNcFhVY01lTTNKWEtQalErNDZZNFYzbVZObVRT?= =?utf-8?B?SkhBRm1hS2JDWHZCZ3VUUVRHTXduaEU0R2N3TEs2dy80NWhFWjhmeFpSSmJq?= =?utf-8?B?ZGRZbkJLdE9IWHFOd21oSzdHaFdvK090MEEwa0xZQ0ttdDNxc3JQeDJmdFY0?= =?utf-8?B?YU5MZDFaUUN2VWV3STg1K3NvVEJKTlBaZFFmb1VDbVVzV1B0VFJvdkJsVm92?= =?utf-8?B?dDlNcmcxcThVanRtdlhtelZwd3VxVDJ0YkpITmgrSFgyMTQxY2VCZ3lCNnoy?= =?utf-8?B?a0lCZGtVRnhtUzloMnhnS1lGby9HWTBIUlBaVktCNmx2b0wwaTY4a0llMmZn?= =?utf-8?B?REllQ1BDSEk2RFg4TWhISzZuS0NYOFhkSWQ4Mjd1Mng2d1dmRklUMlowZCtu?= =?utf-8?B?bVN0elpiajNrVXNlR0tHOGkvdkczL1p0elFXbFZyM0xteXRucGh6RWdzZzFC?= =?utf-8?B?UTdzQmxmeG1OVDlVaE9WMEtSMm1RaSthYVgvdTllaFBMQm02ZlZ2czhLZ0hU?= =?utf-8?B?OHk3ZDMxZ2VJK2t5NktPcFoydU9EWitZZ0R0dXpRV3hXSjZlOEhmSkpqdHZo?= =?utf-8?B?b29Vdk9Pc3pwZ29Ud2FvNWRHeWlJT2lsUFhCa2tRZmZidldXc29HL2pGc05H?= =?utf-8?B?WUFKOWNjeWZFL3FLTFpselFDb3hmR2FsamIzWWJGck8weERvS2NOZGI4cjBS?= =?utf-8?B?d1U1Q1dvaCt3Nm9Ibkk3cW1oclcxS3hER1VmR0pwcCszWTI2UDZzaEVWNkw0?= =?utf-8?B?R1Z6OWJxM0c4QzE3N053UlFvbXJqYWtlVzFKY3EvZENjK0pXK2ZsZ28vYzFJ?= =?utf-8?B?Zjc4TzFoYktqbm5GWS9LamdtcVdSU3R1cHp3TlBDOWkrSFZoK1llVU9KbUl6?= =?utf-8?B?eTJLVTJYOFZxWlVaR1RLUkRYOXpuK0Y3RzhPUXlFNUZOUjlRU1FWN0lKSzRV?= =?utf-8?B?WmEwejR1bFNwaEpwUFJtUzdIUklCbDBDQ0xseUdoNEZVeUlHRGc4eE91MUtl?= =?utf-8?B?cGRXRisyV01KTEJ0WkpuMmZWdDZHVUNORjM3c2dLczB3SlJIVmlEYnUxcjJv?= =?utf-8?B?NmtHaFQwUWoxK0tYNUtiTGpNcWRLeFMwbTJUbmFIRFZtQzkxZUxhWUdJMjYv?= =?utf-8?B?TVkyejQ2TzZheWJDRlJ1Vy9wZW1yYW95aHJHMDVoNEhtS3ZLU2dIZ0R3U3BL?= =?utf-8?B?eDlYUlIxaWMvVmhxL2d2ZWQ4dmxXdXpreWsxa3VERnNXU3c2bmZieFdPM01m?= =?utf-8?B?NWozSitJcGVGR01lenFPbzlzYW1CdFZCdzNlU0kxSFVydzhpdDk2SmFkbk11?= =?utf-8?B?OGNtRUhHZXZqOFcwZ0h1cmpOaWthdWV1eU53TnprKzJ3OGhXazAxWURRUEM0?= =?utf-8?B?cXNFdTFPRWZPTFV4RExxcCtlQjRsRmxEMEVtNUpBQW0vcXgybDVpdklPTjIw?= =?utf-8?B?ais5NmJYTU91Uk8rUUVMbkRHSU8rZlQweFNNekxZc0EvYXp4L0sxb29hYW9Q?= =?utf-8?B?Q3VrdDk1d3p0ZjFqNUM5ZG83Q3E0TnMweGRoVWRRTzdyM1U1bFh2L0hLNzlH?= =?utf-8?B?T2YrUUM3WjRFOFJrM3lPSDFPUzM1Y3NtZW9rZlF6MktCRzdxS2RNMkZyak1L?= =?utf-8?B?NHQ5ZVkxTmhCWVUzZVBkUFpOM2lqaklyd1BuQ2sxRWErSlh1dUE3MWlxbDdH?= =?utf-8?B?Zk9VUlRIYXhvbTNJZUpDYlRXSGpTYmdYcEgvak1vQ2R3WXdIQjFQdHptMWlY?= =?utf-8?B?bUN3OU1mRUVaQUgrNGpWQ2JSWVNpV21Yd3YzUXVZZWEySjRkNDlRTGt3eTNp?= =?utf-8?B?QnJNNjFxQTRNT1U1OWRSek94N2hUdGFxaGxqejQwZ1dhWmtXMkFSMEFlbTFM?= =?utf-8?B?UjFhME5jemtwRHVLMG9YTEhkMzZzODQzOGxXbDlySE9ZOUxXeGFXeENHZnZw?= =?utf-8?B?Z21rNFRwbElDcVNUdjl6eTVMWlR1WjEzdTZibFdIUHZRZkIyVWdOZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac75eb3d-9bfa-4496-61fc-08df2aabd216 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 11:02:36.3143 (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: +YyWkCwKGL461qosiLtMUGvxPsaghvJNuICBL3TSS/EMNhWHvMYmLguzZdI+68IyiLIqx+JVzAW074WEMMAMBCO3I98KcX8JaZctloS38ms= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB4929 X-purgate-ID: tlsNG-bad1c0/1792062281-3B8D1034-B2FC85A3/10/78276251493 X-purgate-type: spam X-purgate-size: 2537 On 14/10/2026 2:51 pm, Jason Andryuk wrote: > From: Stefano Stabellini > > The S bit of an INVALIDATE_IOTLB_PAGES command selects between the two > sizes the command can name: cleared, the invalidation covers 4 Kbytes; > set, it covers the range encoded by the first zero bit of the address, > counting from bit 12. invalidate_iotlb_pages() builds that encoding > whenever it is given a non-zero order or the all-pages address, and then > passes the field's mask where set_field_in_reg_u32() expects the shift. > The correct mask is 1 and the shift is 0. When mask (1) is passed for > both, the value is shifted out of the field it was to occupy and the > bit is left clear. i.e. (x << 1) & 1 is always 0. > > An endpoint holding translations of its own is therefore told to drop one > page where it should have dropped a range. The rest of the range is > kept in its cache after the page tables backing it have changed. > > Pass the shift, as the sibling INVALIDATE_IOMMU_PAGES builder does. > > Signed-off-by: Stefano Stabellini > Reviewed-by: Xenia Ragiadakou > [ Reword commit message. ] > Signed-off-by: Jason Andryuk > Reviewed-by: Jan Beulich > --- > This was submitted to the security list, but it is out of scope. Xenia > reviewed internally and Jan reviewed from the security list. > > xen/drivers/passthrough/amd/iommu_cmd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c b/xen/drivers/passthrough/amd/iommu_cmd.c > index 665e882a2d..abfbdf2b28 100644 > --- a/xen/drivers/passthrough/amd/iommu_cmd.c > +++ b/xen/drivers/passthrough/amd/iommu_cmd.c > @@ -212,7 +212,7 @@ static void invalidate_iotlb_pages(struct amd_iommu *iommu, > > set_field_in_reg_u32(sflag, 0, > IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, > - IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, &entry); > + IOMMU_INV_IOTLB_PAGES_S_FLAG_SHIFT, &entry); > > set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry, > IOMMU_INV_IOTLB_PAGES_ADDR_LOW_MASK, As said on the security list, this is probably fine for a fix wanting backporting, but can we please purge the use of set_field_in_reg_u32() entirely. It is horrible for code legibility and generated code, and very fragile for mistakes such as this. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 15 11:45:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 11:45:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450281.1665722 (Exim 4.92) (envelope-from ) id 1xHJt5-0005WS-Ba; Thu, 15 Oct 2026 11:44:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450281.1665722; Thu, 15 Oct 2026 11:44: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 1xHJt5-0005WL-8a; Thu, 15 Oct 2026 11:44:43 +0000 Received: by outflank-mailman (input) for mailman id 1450281; Thu, 15 Oct 2026 11:44:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHJt4-0005WF-3I for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:44:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHJt3-00GfYU-C8 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:44:41 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0bc9f-2eae-0a2a0a5409dd-0a2a4507e34c-18 for ; Thu, 15 Oct 2026 13:44:41 +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 6ad0bca8-b4ea-0a2a45070019-c387df83a01c-3 for ; Thu, 15 Oct 2026 13:44: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-out2.suse.de (Postfix) with ESMTPS id A20D71FCBB; Thu, 15 Oct 2026 11:44: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 6A158132C9; Thu, 15 Oct 2026 11:44: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 YgeHEqi80GpqYgAAD6G6ig (envelope-from ); Thu, 15 Oct 2026 11:44: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=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=1792064680; 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=je3r8ay2iRuWNnL7qXx74c33rLnIn1TUKUdbkrxp1Vk=; b=Mj8oUkZUz4fvByBs+2Rz0mGRl0SmUnzRkUZySscMLsYFOjQEUCywpcxcNOlEWtgIrPGF/b PbZMqOKCDa9L45nNSjI6xC+/jpwhnd3yzY9VathI4noYaFc+GKH87fzx7JqR1NLbLQcSh7 y8Tojmxi8apkQD2ciCeMWkJinS/CxJQ= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=Mj8oUkZU DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1792064680; 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=je3r8ay2iRuWNnL7qXx74c33rLnIn1TUKUdbkrxp1Vk=; b=Mj8oUkZUz4fvByBs+2Rz0mGRl0SmUnzRkUZySscMLsYFOjQEUCywpcxcNOlEWtgIrPGF/b PbZMqOKCDa9L45nNSjI6xC+/jpwhnd3yzY9VathI4noYaFc+GKH87fzx7JqR1NLbLQcSh7 y8Tojmxi8apkQD2ciCeMWkJinS/CxJQ= From: Juergen Gross To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org Subject: [GIT PULL] xen: branch for v7.4-rc1 Date: Thu, 15 Oct 2026 13:44:39 +0200 Message-ID: <20261015114439.418665-1-jgross@suse.com> X-Mailer: git-send-email 2.56.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Spam-Score: -3.01 X-Spam-Flag: NO 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)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[suse.com:+] X-Spam-Level: X-Rspamd-Queue-Id: A20D71FCBB X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-purgate-ID: tlsNG-ef75cf/1792064681-370DDAE4-A4C949D4/35/110847 X-purgate-type: clean X-purgate-size: 2124 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.4-rc1-tag xen: branch for v7.4-rc1 This time only small fixes and cleanups all over Xen related drivers. Nothing really stands out here. Thanks. Juergen arch/x86/platform/pvh/enlighten.c | 2 + drivers/block/xen-blkback/blkback.c | 7 +++ drivers/block/xen-blkfront.c | 16 ++--- drivers/pci/xen-pcifront.c | 16 +++-- drivers/scsi/xen-scsifront.c | 3 +- drivers/xen/gntdev-dmabuf.c | 4 +- drivers/xen/gntdev.c | 7 +++ drivers/xen/mcelog.c | 2 +- drivers/xen/privcmd.c | 47 ++++++-------- drivers/xen/xen-pciback/pci_stub.c | 7 ++- include/xen/interface/hvm/hvm_vcpu.h | 116 ----------------------------------- include/xen/interface/platform.h | 4 +- include/xen/interface/xen.h | 2 +- include/xen/xenbus.h | 2 +- 14 files changed, 68 insertions(+), 167 deletions(-) Abdifatah Suruur (1): xen/gntdev: prevent private mappings from becoming writable Ethan Nelson-Moore (1): xen: remove unused hvm_vcpu.h header Gui-Dong Han (1): xen/blkback: Prevent missed completion when draining I/O Hemanth Selam (1): xen: fix typos in comments Jan Beulich (1): x86/PVH: don't truncate initrd address/size Koichiro Den (1): xen/privcmd: Only claim ioreqs matching an ioeventfd Ross Lagerwall (1): xen-blkfront: Fix IO race during unplug Ruoyu Wang (1): xen/pcifront: Fix PCI device reference leak in AER handling Wentao Liang (2): xen/gntdev: Fix gntdev_dmabuf ref leak in dmabuf_exp_wait_released() xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf() Yehyeong Lee (2): xen/scsifront: check for a NULL shadow entry on a backend response xen/pcifront: check that an AER callback exists before calling it Yuchao Zhang (1): xen-blkfront: unbind irq before tearing down ring and shadow requests From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:02:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:02:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448716.1665742 (Exim 4.92) (envelope-from ) id 1xHK9o-0002Hl-ED; Thu, 15 Oct 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 1448716.1665742; Thu, 15 Oct 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 1xHK9o-0002HN-9j; Thu, 15 Oct 2026 12:02:00 +0000 Received: by outflank-mailman (input) for mailman id 1448716; Wed, 14 Oct 2026 10:45:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwTv-0004qF-11 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:45:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwTu-004CKk-Dn for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:45:10 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5d2d-bab6-0a2a0a5309dd-0a2a450aba28-44 for ; Wed, 14 Oct 2026 12:45:09 +0200 Received: from [198.175.65.10] (helo=mgamail.intel.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf5d33-f2d2-0a2a450a0019-c6af410a14be-3 for ; Wed, 14 Oct 2026 12:45:09 +0200 Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:45:07 -0700 Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by fmviesa009.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:45:07 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 14 Oct 2026 03:45:06 -0700 Received: from fmsedg901.ED.cps.intel.com (10.1.192.143) by FMSMSX903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49 via Frontend Transport; Wed, 14 Oct 2026 03:45:06 -0700 Received: from BN8PR05CU002.outbound.protection.outlook.com (52.101.57.27) by edgegateway.intel.com (192.55.55.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 14 Oct 2026 03:45:06 -0700 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com (2603:10b6:f:fc02::31) by CY8PR11MB7363.namprd11.prod.outlook.com (2603:10b6:930:86::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 14 Oct 2026 10:45:03 +0000 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f]) by DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f%5]) with mapi id 15.21.0522.012; Wed, 14 Oct 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=Intel header.d=intel.com header.i="@intel.com" header.h="From:To:CC:Subject:Date:Message-ID:References: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=1791974709; x=1823510709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2jUlPy8n+UBtePTlv1PTFS+OS1Qdz8HFuyrami2eGQg=; b=mYsxt83dFgjZ1aBgdrYFi6rTDYtS8QOhAf4tT3P5g9fnLhHoI5So6beM vQjMBLWCicdcmDUOp+ql6PiCAiRZPh4C1gWDFoDce0e2rwKanJjww7Bfi xk2dKjAsTfBQ813qBNGyg/2Gbn1i6gi4y8sNSUIkZjFRy4yV3/6F8ufwx +W2bpTKNsQqTRsO9WxCFudMEPPErGiymGvPRF96nRx4wCpXt+bQKN6fng YiWuZwTxTmA/uk4FBKPLwWGc9saD7VdC5OFHSDFd0qp7zX0naVC59uDud xiomojU03ZXuWJRioLLEXak2hjxqXiedna5I/k5v96NGUmimliWq0sJUQ Q==; X-CSE-ConnectionGUID: NGhyrSI/TpC2n6Uz3cc1MQ== X-CSE-MsgGUID: OSEsU9f+QuakCGrpZq0mCw== X-IronPort-AV: E=McAfee;i="6800,10657,11934"; a="608286" X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="608286" X-CSE-ConnectionGUID: QLvdgYIVQzybmeMBVgBORg== X-CSE-MsgGUID: i8wSYyYNSDGrjnyV0Mr3bA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="1740254" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BboCTyoPhQcpRRuxEwoLYSkt3I/RzFuN5Mq5HBf4rE/pfMQdcxp06QIR4TTniLD/Va9h9g05wk/BkKQgjJksZHgBY3+W2S9HAWQZjEfaaXUAmn2evIiD7wnX0IAJ0ugdVrTvJ7EtW3pX+arKH0YsVKD6U9HY6tmthzdkBjwO9eM5x0nmiXQUOOahBMMjzyTlKkUG4KL1/ggD3He9+/CWKWVT3C7OMO4liqlpk1kna7ApEY8lxaVJXVSiLvTNws65IhcolVXOf8P6ABgjoZSqCe+rLSbQB2DBwLjQcyj/WXGdz3b0SXT6lkC4aA+p7XMtvGEDQgtZjP8pUdbxnGPW1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2jUlPy8n+UBtePTlv1PTFS+OS1Qdz8HFuyrami2eGQg=; b=kN10kmt80wwWalmdR4ee2ulKe8DyJKWfnEphxqyoh6wWO3AiMr3zmf/IMzVdkWwh9Mr66AuQJUzXsN8Z0bY6owHH1iSSOEMNn6eZB84Z7QNp5fW798jMsf7sGCHnRxk9AGs+8ALN5F52cvRM/NUB+6Ft9UeGBhMhrEgXEDokOeIBi5ydwJ+hTs0an3Y+lStpOW8bPyWOsjPdNB0OWp1ngppGZiu5REqcorjk+e3ZRO1FQZHTbefSTa4Vot1kkfscIRmpLWQGCN3SgpzW6knjjkALoKDOOsXySeeBpEG3VrUAFJeMABtb8g4/ejtm7TeV7ln5EzzvDRRiaBJkxmt2NA== 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 From: "Loktionov, Aleksandr" To: Josef Bacik , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn CC: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , "Juergen Gross" , Stefano Stabellini , Oleksandr Tyshchenko , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , Manish Chopra , "Rahul Verma" , "GR-Linux-NIC-Dev@marvell.com" , Shahed Shaikh , "Simon Horman" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "intel-wired-lan@lists.osuosl.org" Subject: RE: [PATCH net-next v2 07/10] e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround Thread-Topic: [PATCH net-next v2 07/10] e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround Thread-Index: AQHdV2iNuC8nz2/mq0etBQaKFjGAjLb840rg Date: Wed, 14 Oct 2026 10:45:03 +0000 Message-ID: References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008-b4-pskb-pull-tail-drivers-v2-7-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-7-8f2bd9bee138@toxicpanda.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=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS4PPF7551E6552:EE_|CY8PR11MB7363:EE_ x-ms-office365-filtering-correlation-id: 3ebcb8ce-d7db-44f1-d4ff-08df29e03409 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014|23010399003|6133799003|22082099003|10067099003|38070700021|56012099006|18002099003|261009223027099003|11063799006|4143699003; x-microsoft-antispam-message-info: M5JB9lQq9e4AGL0Wyc8qCFp4qOSYsD/7VtZ/H0i49w3F5v90UFcdEcMq854yflxvOPkhY65khXSWbgVvN7aBDku7H6wzdBokakjCHAbNHPVwSLWrWW4k8Et0G6St1Ik7iU2AJdYLHG0hflvDZzs6mBunBkX4eKqfS6O3p1LkA35JbmxY6xga0MDZrG4CYY9kc88/UUuxi7HfApbqU+Qz6/prZDVvfytLKYNcleJlICRpky7fmOF40W3nRJp6ftRqfjFywSomrhgGLzKDTwAY0x8uZBYatgnRc/uuwzdYgK8kHmbp1iC/TpReLCHw+Bn3bum/28mqUWX9PH2a4PXX7fOSwM+2rJK+1ULXkmqW/ZfLJY+KxQxBoMiJ9pYDmL83/3lcCl7G9BuC3Uphi4eRBfWJVRI2nwTDFnYw60GdB4iLbAJuiRl1g0WrWwsOoS4a+ikrZ+sKnwqztlHpHXOGfEVc11cqvOFxPEnTjnN0h9Vc3d0k1eeHcxLW0iaCK0ghZRolHcCj9uIlr+1nn/Kak7qQ7qS8bSLh/1HFWArlQppBeOdv8ItoWaO7NGevq57JH3vH4da8Q+xj4wOb9/ohE+Pu94j0hGEuNeV4QEAnPKU79cXcKkUiaAkcCIvWJBXPNf4aCFLIU4ekf6XIKVhBIF9PGm1C1jqo0pTLlc7RMCb858XHV1HHx0MwmddXTkWl1+2knYUetmJnPTNi7Y+b9HOyPuPDWSuzWCRLsDzIBhU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS4PPF7551E6552.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(23010399003)(6133799003)(22082099003)(10067099003)(38070700021)(56012099006)(18002099003)(261009223027099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SU93bE4yTWRQeDREdVczTStZN0gwbWxlV0VWZjZxWmNrM1lpUC83WGNCaXdv?= =?utf-8?B?aXdFR0ExYjVmd3BkZVVXZTNmODB2Tnk5V1VmNzVFdzVVdzFWYnZ0NUVsVENT?= =?utf-8?B?NWUxcU1yL1NKK3Nlb1JyaGwrTlpJNGJWU3BYdkJzWVM1TXBnTnVTTDRXWnNF?= =?utf-8?B?N0RZcm9FWXVJeG0ya25qRXU0YkRJNjZOWU1SVmxKaS9GeHA1aW9CNXVXUDlV?= =?utf-8?B?bTB4Qnh1RVd2QndqQzRtVURiU0pCeWk1ZmJYbHUvdVBpeEJKNlViTktxVkxl?= =?utf-8?B?dGk5SVVocXZINEhQZzRoQkN0UG5ZZGlNUlVudU83eEVQNDVYMFNzUHpkN3py?= =?utf-8?B?ZHBGdWZtczNXaDNCYU5ReFB3MnZnZUYrWGFlbWZTekVWM0pLMFdXU0FZWHNX?= =?utf-8?B?VnNMQ3BQMEhKS2l4dlY0a3F1QkZZbUJUbjNvWFA4MzlhRnZ6U3c1cnhyZ3Vz?= =?utf-8?B?WUNZM1dJVEZEaktMbWR0ZzBTZkhCWGZuRHJUR1lMZGR1UFBCbzJCYjI1UXFX?= =?utf-8?B?YVNZbWpaODNDVFUvWTVNazQxY1JVK2o1QW01YTJub1hGalppeFFBQzRGcWZl?= =?utf-8?B?UW5kaXhBNlBsYWN6dG1mSVhCZnY5ODk4dFdWOEpQTXVackhWZ1RvTDdqb29S?= =?utf-8?B?d1lOQ0d1WWpXMnRYcTRwTVZFZjFvMEovY29lV3cvbmVtbXJnNFluZEtWWW9h?= =?utf-8?B?ZDR4YzF6ekpnS1ZvcWQwWjZWRDgvL3g3K3dJVHNxak53S0IvWXNDQzlzUStu?= =?utf-8?B?amxSOHBQYjVhQk1pYXpDck15Y2F0dFg4TUZpeHZKUlVWQkhzcU9hTGxWVGg1?= =?utf-8?B?SkZ5a0lKRkx4M0hPM1dhQ1BQRmU0NW0wZ091cHNlQnEzcm0vOVFXei9nUk1M?= =?utf-8?B?azRrazdMN1JMajc4RjdRekpSYWszZml5NGhvWm1EZ0ZHd2J3OUw3aG9BUkZP?= =?utf-8?B?UVdmQkd5SklBU0djQ2JsNk82YlcwaDZwODVWSlFjbWd4U2twakdCc3doRlBL?= =?utf-8?B?THVHZTBtMjVIV0VoN2VXSGJsZGhiOTNxKzdpcGVKOTlsTUhTc1Q0VzErQ0NO?= =?utf-8?B?L3BiSHFFUlQ1RGdWV09oamVQRlRTVmVZN3NYRmgxYklsSlR5N2VPMHVSd2Yv?= =?utf-8?B?eWltcC9Dc2ZjcDgwMllDYzFDcFA4L2ZVR0FXdTR0TkR6RGhod1cyQjFjUXZM?= =?utf-8?B?MUdRTEJPbDJteHVEb3pyOGd3MDVLQTlNRFZpZjRPaG1UcGdvSU5KcVBPMWtF?= =?utf-8?B?Vy9tZzJNeHlsSzRQVktpYTdXU1d2S0ZNaVNyVWZvMGg3MmRkclU2dG9PZ083?= =?utf-8?B?QlZ3R1kzc3JiQjJETk1waDlrQndmZXpVdEw1Nmx2MEZlU2Q4aXk5ZHIwQmwr?= =?utf-8?B?TjVVbEFXbkFIenhQYnMweis3ZXVRZ3MrVjRUSk9IaGs3SkZXdEhQSldvWDdO?= =?utf-8?B?a21LSVdBMXBsS05rTldMSWVldm1nMGdrS3M4VFpIY0FKMXJyUWdIS3UzWFZ6?= =?utf-8?B?OTViRkJueW04RmhsSk5JUEtZd2pMY2R3ZWR3QWFjYys5RFRBcFJRdVRubkN2?= =?utf-8?B?YThkVmpOY1MrRHY1Q0JiTU9hd3VCangydGRxbXkwK2JGUnQwTGhSWGpzTHA1?= =?utf-8?B?TjU5b3V3NUFLQW45ZGZ2dzZtWDYxQ1diQitPUE44Tm5hdXBCeXJYNTZSUlBN?= =?utf-8?B?d0RwY3JyaUUydjk2QStiODVvWGo1SDE3YzhHTmpIM2Jpcm9qNjFSMFZmcXRP?= =?utf-8?B?eUdKNkllNFJPekdFL1pnUHhpajlRSTZMYityWDJkMGVwWXdDVE96SGNPamhD?= =?utf-8?B?UDJYNk1KRmJqS1dRZVBmcXNwaU5taTYyM3lCbmVLQ2dTMnJWYUIxOTQ0UTMz?= =?utf-8?B?dS9TQy8zRjZGd2tRR0tyc0Zrb2RKZ0JWWTN5TmltK0FxMlB3TGg5dExnSGFH?= =?utf-8?B?NHpYMitWZkkrWmVWWlRocmhIN25wMGo3TnVETFE0SmpyM1ViSHI3bFMwcEl1?= =?utf-8?B?UEtxYkVJblBITnhRNjZ0d1liOEtTZG5ZeU93UVhsdENOMU1USHNoVlkwaUto?= =?utf-8?B?VmJjWnNUT0JJY1FsMW56Umo0TEh6YnJCTGRubW03K0t2dHI4Ym4xWkw2cDVx?= =?utf-8?B?VklEZ2UxRHNvYnlDK2FwVytaM2RwazNDOUJiU1F6WDFoeE9tQVdHZ29abVNL?= =?utf-8?B?QTVyWE9JWWUxR3ozZzZYL3drbktXek1VQmhXcWhHajBvYW9Jd2QxTXFnOUo5?= =?utf-8?B?ZGtLLzJtU3VFMmE2ZzVPR1lsVkg5TXEwRlAzYnhoTnhsUzdrOXp5cHIyOWdI?= =?utf-8?B?VjBSMXRjSjY1K1YySXlhbStVclZ5SlFoa250ZEU5RkE3bFNCVGdPT1pyeXF1?= =?utf-8?Q?gsVgkhviw3rsC5BQ=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: ULV2HH+oSmiDEhv73HJT9UIzN0BfCdVSWxMnyiJHd6QJPTX8Yqzqcm9O1Agaicp5CoQPKZgtgLXm0jYOqHJj16hN5OyonaomeP5diNmDXL7wqmEnTvs2fke1Ek7UGLXGC74uTPYgPkdniy28ZsAoYRFrCCxC5itGBsIz/gd3TPslgYlmjrLT1U/eCQDjU42s6tIEsgj+/BOS/aSr20WVkFmHabx2r9NTUsf/PS2Xdp8dUNjsIYCe0HLEJKMuxZ7IG23J8szyRHav1I+fKfM9woLxu73wRVodGfmYEoczfHFMdz/8xF5A2hsXLFuQ5FeGdHUm8FsMWUmJXeGRIZab4g== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS4PPF7551E6552.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ebcb8ce-d7db-44f1-d4ff-08df29e03409 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2026 10:45:03.2063 (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: 7RLoSuEMjENZvnsrNizM4HhhfF4Yahb0B9JEGYHHVAWZXM/78nQ3BbEsVPw7UDs+fFxoLH7mJJU/um3Pd0MBRsenFJfDdHtnZATDJQ1GEIM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7363 X-OriginatorOrg: intel.com X-purgate-ID: tlsNG-4011c0/1791974709-4AEDACFC-49299A5B/0/0 X-purgate-type: clean X-purgate-size: 3428 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9zZWYgQmFjaWsgPGpv c2VmQHRveGljcGFuZGEuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciA4LCAyMDI2IDEx OjAzIFBNDQo+IFRvOiBKYWt1YiBLaWNpbnNraSA8a3ViYUBrZXJuZWwub3JnPjsgUGFvbG8gQWJl bmkgPHBhYmVuaUByZWRoYXQuY29tPjsNCj4gRXJpYyBEdW1hemV0IDxlZHVtYXpldEBrZXJuZWwu b3JnPjsgRGF2aWQgUy4gTWlsbGVyDQo+IDxkYXZlbUBkYXZlbWxvZnQubmV0PjsgQW5kcmV3IEx1 bm4gPGFuZHJldytuZXRkZXZAbHVubi5jaD4NCj4gQ2M6IFNhZWVkIE1haGFtZWVkIDxzYWVlZG1A bnZpZGlhLmNvbT47IFRhcmlxIFRvdWthbg0KPiA8dGFyaXF0QG52aWRpYS5jb20+OyBNYXJrIEJs b2NoIDxtYmxvY2hAbnZpZGlhLmNvbT47IExlb24gUm9tYW5vdnNreQ0KPiA8bGVvbkBrZXJuZWwu b3JnPjsgSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPjsgU3RlZmFubyBTdGFiZWxsaW5p DQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgT2xla3NhbmRyIFR5c2hjaGVua28NCj4gPG9s ZWtzYW5kcl90eXNoY2hlbmtvQGVwYW0uY29tPjsgTmd1eWVuLCBBbnRob255IEwNCj4gPGFudGhv bnkubC5uZ3V5ZW5AaW50ZWwuY29tPjsgS2l0c3plbCwgUHJ6ZW15c2xhdw0KPiA8cHJ6ZW15c2xh dy5raXRzemVsQGludGVsLmNvbT47IE1hbmlzaCBDaG9wcmEgPG1hbmlzaGNAbWFydmVsbC5jb20+ Ow0KPiBSYWh1bCBWZXJtYSA8cmFodWx2QG1hcnZlbGwuY29tPjsgR1ItTGludXgtTklDLURldkBt YXJ2ZWxsLmNvbTsgU2hhaGVkDQo+IFNoYWlraCA8c2hzaGFpa2hAbWFydmVsbC5jb20+OyBTaW1v biBIb3JtYW4gPGhvcm1zQGtlcm5lbC5vcmc+Ow0KPiBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBs aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gcmRtYUB2Z2VyLmtlcm5lbC5v cmc7IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsgaW50ZWwtd2lyZWQtDQo+IGxhbkBs aXN0cy5vc3Vvc2wub3JnOyBKb3NlZiBCYWNpayA8am9zZWZAdG94aWNwYW5kYS5jb20+DQo+IFN1 YmplY3Q6IFtQQVRDSCBuZXQtbmV4dCB2MiAwNy8xMF0gZTEwMDBlOiB1c2UgcHNrYl9tYXlfcHVs bCgpIGluIHRoZQ0KPiA4MjU3MS8yLzMgVFNPIHdvcmthcm91bmQNCj4gDQo+IGUxMDAwX3htaXRf ZnJhbWUoKSB1c2VzIF9fcHNrYl9wdWxsX3RhaWwoKSB0byBwdWxsIHVwIHRvIDQgYnl0ZXMgb2YN Cj4gcGF5bG9hZCBpbnRvIHRoZSBoZWFkIHdoZW4gdGhlIGhlYWQgaG9sZHMgb25seSB0aGUgVFNP IGhlYWRlcnMuICBJdA0KPiBhbHJlYWR5IGNoZWNrcyB0aGUgcmVzdWx0LiAgU3dpdGNoIHRvIHBz a2JfbWF5X3B1bGwoKSwgd2hpY2ggdGFrZXMgdGhlDQo+IGxlbmd0aCB0aGUgaGVhZCBzaG91bGQg ZW5kIHVwIHdpdGggYW5kIGNoZWNrcyBpdCBhZ2FpbnN0IHRoZSBza2IsIHNvDQo+IHRoaXMgZHJp dmVyIG5vIGxvbmdlciBjYWxscyBfX3Bza2JfcHVsbF90YWlsKCkgZGlyZWN0bHkuDQo+IA0KPiBB c3Npc3RlZC1ieTogTExNDQo+IFNpZ25lZC1vZmYtYnk6IEpvc2VmIEJhY2lrIDxqb3NlZkB0b3hp Y3BhbmRhLmNvbT4NCj4gLS0tDQo+ICBkcml2ZXJzL25ldC9ldGhlcm5ldC9pbnRlbC9lMTAwMGUv bmV0ZGV2LmMgfCA0ICsrLS0NCj4gIDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDIg ZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvZXRoZXJuZXQvaW50 ZWwvZTEwMDBlL25ldGRldi5jDQo+IGIvZHJpdmVycy9uZXQvZXRoZXJuZXQvaW50ZWwvZTEwMDBl L25ldGRldi5jDQo+IGluZGV4IDg0NGYzMWFiMzdhZC4uZTIxNjg2OGUxNWNiIDEwMDY0NA0KPiAt LS0gYS9kcml2ZXJzL25ldC9ldGhlcm5ldC9pbnRlbC9lMTAwMGUvbmV0ZGV2LmMNCj4gKysrIGIv ZHJpdmVycy9uZXQvZXRoZXJuZXQvaW50ZWwvZTEwMDBlL25ldGRldi5jDQo+IEBAIC01ODU5LDgg KzU4NTksOCBAQCBzdGF0aWMgbmV0ZGV2X3R4X3QgZTEwMDBfeG1pdF9mcmFtZShzdHJ1Y3Qgc2tf YnVmZg0KPiAqc2tiLA0KPiAgCQkJdW5zaWduZWQgaW50IHB1bGxfc2l6ZTsNCj4gDQo+ICAJCQlw dWxsX3NpemUgPSBtaW5fdCh1bnNpZ25lZCBpbnQsIDQsIHNrYi0+ZGF0YV9sZW4pOw0KPiAtCQkJ aWYgKCFfX3Bza2JfcHVsbF90YWlsKHNrYiwgcHVsbF9zaXplKSkgew0KPiAtCQkJCWVfZXJyKCJf X3Bza2JfcHVsbF90YWlsIGZhaWxlZC5cbiIpOw0KPiArCQkJaWYgKCFwc2tiX21heV9wdWxsKHNr YiwgbGVuICsgcHVsbF9zaXplKSkgew0KPiArCQkJCWVfZXJyKCJwc2tiX21heV9wdWxsIGZhaWxl ZC5cbiIpOw0KPiAgCQkJCWRldl9rZnJlZV9za2JfYW55KHNrYik7DQo+ICAJCQkJcmV0dXJuIE5F VERFVl9UWF9PSzsNCj4gIAkJCX0NCj4gDQo+IC0tDQo+IDIuNTUuMA0KDQpSZXZpZXdlZC1ieTog QWxla3NhbmRyIExva3Rpb25vdiA8YWxla3NhbmRyLmxva3Rpb25vdkBpbnRlbC5jb20+DQo= From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:02:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:02:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448720.1665756 (Exim 4.92) (envelope-from ) id 1xHK9p-0002V4-4A; Thu, 15 Oct 2026 12:02:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448720.1665756; Thu, 15 Oct 2026 12:02: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 1xHK9o-0002Ry-Rn; Thu, 15 Oct 2026 12:02:00 +0000 Received: by outflank-mailman (input) for mailman id 1448720; Wed, 14 Oct 2026 10:45:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwUE-0004sL-KO for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:45:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwUE-004CRl-13 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:45:30 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5d45-8faa-0a2a0a5109dd-0a2a450ad736-8 for ; Wed, 14 Oct 2026 12:45:29 +0200 Received: from [198.175.65.9] (helo=mgamail.intel.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf5d43-f2d2-0a2a450a0019-c6af4109b23c-4 for ; Wed, 14 Oct 2026 12:45:29 +0200 Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:45:28 -0700 Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:45:28 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) 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.49; Wed, 14 Oct 2026 03:45:27 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) 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.49 via Frontend Transport; Wed, 14 Oct 2026 03:45:27 -0700 Received: from BYAPR05CU005.outbound.protection.outlook.com (52.101.85.7) by edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 14 Oct 2026 03:45:26 -0700 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com (2603:10b6:f:fc02::31) by CY8PR11MB7363.namprd11.prod.outlook.com (2603:10b6:930:86::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 14 Oct 2026 10:45:24 +0000 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f]) by DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f%5]) with mapi id 15.21.0522.012; Wed, 14 Oct 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=Intel header.d=intel.com header.i="@intel.com" header.h="From:To:CC:Subject:Date:Message-ID:References: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=1791974729; x=1823510729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/DwQejAILhC1tS+1OOtnkUe6M76OyLfY+xOAnhmEWHc=; b=JfaABrS3Jrtx7YphHBN61dmm1psoyqYCazGRsSnmeIFytVanQ1hR5eu6 J9RrKhBdpAesBywer6SJcGiTAQribCF7gPpVQvqXoBpfYiXOg5bWkL9IM 5qYboP4zAh36pkEDHVGOimPxd/2ft+VIFy4FihyBGl8EpDxja8eGpUQao 8nKPlSyV2Fm1OQ0yxHYjLFr158h9Ae1l+yUeEABRht4JcZEQnXOD1z6dA LpPMg8ln9g/WXnOf/Xn/B8BI+F/sVmOkxz7xlZYE5GQfnrwsCg5mVNvf3 Yj0KaVikjl6+y4IZ77B9/PbbMibxuXjxG5cA5TSJbz2ype4sWEaMW8Fqc w==; X-CSE-ConnectionGUID: CoAgrkP/RBa6YcUOz5k+aA== X-CSE-MsgGUID: 04KpFqXEQViBodBU+E/Vkg== X-IronPort-AV: E=McAfee;i="6800,10657,11934"; a="604372" X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="604372" X-CSE-ConnectionGUID: TDa9q9JrT5WgjRwbjJ4B7A== X-CSE-MsgGUID: AQLTh0/uSF+fy00Lmp1QCg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="1721911" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MWsTcxupqtqsOCsTY5tP/mIBW8Sh1izwpRL1DIPZB0brRjUoQ8q/yE6ULpO3NAOBolbojSXSv6pLV4/ApQMKaOsnWZ9y7I9lbHhBoEKawJ7lUkq/s8cmWC1wq0qWwGqpUC0w3jiF7DV7aTpRy+Tf2HhYDQTtzG3qOcMU8il21rTzbj1Iar4foydMd4DQJNG2jMx7eTnKnvYwFF+GG2IczD7ytxM2rz9uSMc5FpfQlutfEg2EX4pE1Z2c8t9CrDz0Y8xDIxxd8stkfHR/cHPuRLM9UseGXoqV8OtzOgFuZg226n5rEvhOZvVsluirvkoFVu/qVG3fwcAxwd8+833V9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/DwQejAILhC1tS+1OOtnkUe6M76OyLfY+xOAnhmEWHc=; b=Ss20xX+TtT+oHHVTXyKnqzUUsxgBYCdmVdPLxIYdXXeOLEmFxGPkEnjgGH3X8D/gfANv8d+A5tohNK4hEtMdkuumUOpUlAIHk/vel8wPECR05wh+V70Sg8l5/xtIbSdwmzBFZLVXFsu/htWUHx4ZqSXQG5LM4ZBQOSaSxTAeki+qqu10vNpgJOeRxM5m6Yh/zeWjZWx5NcQQvBQnT6AQiO9Zg7VGa64g4rFMlXyhBVKB75OoLYBQxmanUkxxugGvf1SeRSpFSA8afuSQekBjdrbKBHR/e4ZzJXTfQr9kG7unQy3s1avDZeBLslAhMSOwE+WAckvhHyFoK6YiPAS/eQ== 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 From: "Loktionov, Aleksandr" To: Josef Bacik , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn CC: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , "Juergen Gross" , Stefano Stabellini , Oleksandr Tyshchenko , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , Manish Chopra , "Rahul Verma" , "GR-Linux-NIC-Dev@marvell.com" , Shahed Shaikh , "Simon Horman" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "intel-wired-lan@lists.osuosl.org" Subject: RE: [PATCH net-next v2 02/10] net: ftmac100: check for failure when pulling in the RX header Thread-Topic: [PATCH net-next v2 02/10] net: ftmac100: check for failure when pulling in the RX header Thread-Index: AQHdV2iHHEYlMsgcHEGDYxV8k6LOw7b842RQ Date: Wed, 14 Oct 2026 10:45:24 +0000 Message-ID: References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008-b4-pskb-pull-tail-drivers-v2-2-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-2-8f2bd9bee138@toxicpanda.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=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS4PPF7551E6552:EE_|CY8PR11MB7363:EE_ x-ms-office365-filtering-correlation-id: ebac24e0-c59c-4ebb-7e3f-08df29e04088 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014|23010399003|3023799007|22082099003|10067099003|38070700021|56012099006|18002099003|261009223027099003|11063799006|4143699003; x-microsoft-antispam-message-info: tpyrpBoWu5HClKqW2X55wgQYeMHX7epQt4ozgiiO++QSiv+e3Trt3p5QWE92udNbKPI0fanzz/a/BKXlUXCTZqeSPFVMreZb1cpIaOkglyDPgRhchLqNC66pIkuJWjm4HrEiY1VSz3q94H0W1xOIjPAdDL1GpFu2YyLyDlS63qf4YA7ARU6tTuQoxSVgQDWiZ9n6r2YnjUXQOFh9TIkWYOqKHFcCIkHltqw68jJZPo4+B24fKFAutzJoQ12c/s9zeTjlnUMlfci5NpZs2L60hGuxJtlnejBScXtMF96ZKHj5ZXIGceknrS4FApvzLZIiFNXzDyo2KQv7evaE37R7HXRoIBGjR2BsGv7FPbSxiC6YSpmDIVe5KK6b+EkqqR7tr1EyWhqjnHD91jnMQR0NMv37I3QU9WYImUXBHfeJmxhMKHeYurj0DUO34L61E/7tjnofh5zRGxnpnKLR0JK4xh0d1mg5B+vHMlJE5oN9SVqf7G0LGpF1A8uwbA/MXqbuRfNFZB/vVs23C0oNUS0hc6wMhHbMdyEeeE7OUMChUzFVy0bMPM+h5FXTxRE9cm8IBTTC+1ePtyKXa29ZsueymFFAPvs4BX/QnmcNF7sk6pTt6YJs0QNVCAA03fAs6IhpcaD4j2lNjf8/y1RazyeHSWhudA5k2HIOXBeqjxFQ7KbWO7VbCzfgI3OMjGKHvGmrmqtj+35KdDag21mobqxy2GOKDSRbeHj+74eLxH9z2VQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS4PPF7551E6552.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(23010399003)(3023799007)(22082099003)(10067099003)(38070700021)(56012099006)(18002099003)(261009223027099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aGYvVmVaL3htYjJDQi9ZVkZyY3NXc1FiMG9xeXVVWGMxN0FmVHJSZ05tdjJZ?= =?utf-8?B?ZHFTbUZCOHdUODBEcHN1Mnd4Tyt5d0E1ZHFwcWk0VmJxN1JFTzVQRDR4YkhU?= =?utf-8?B?T3ZvMDc2NjhXRTRpWVR6UG5nRU0zNVFtZ1pIajh6YWRKK0NxQmhDbmtTL0Zq?= =?utf-8?B?NDRiNEhlb0d2R1RYSEFPMEJySitQcXdpbnlLRnFFQ1RZZEM5cysrYm1KNDEw?= =?utf-8?B?dnVVTUc0NG1jL0Q3WFRVNUtOUkhvRVNpRzZ1dUVJc1JSVDRHUDdDYnRidEJU?= =?utf-8?B?Z0x3YnZVVHNWOHlTQmpLR053U3NDV0xqNlhSc3NWTm1INWR4SGduQVBiMEtS?= =?utf-8?B?OWU3K3VtWkVFdTNFVnRVVEFBSU9SUlpJVi9OVCtVYVpHNlROQW1xRXFlSFl6?= =?utf-8?B?ZnpwSG5tVmUxSFZSSG9LN0grYWRjODk0SmxGZUJlWVE3SHNsR3l1V2l5QUg3?= =?utf-8?B?L3NobVVPb2FodXVpWUdxU2R3MUFvZ2E3TlVITG15MjZuRHhoODY4eG9abFVt?= =?utf-8?B?akFFZG8zQmh1OFNuUCtPRFdvK2ZaeE9paEZFNklldHZrb2puOTN0Ti9ONlF6?= =?utf-8?B?cHVWQUFZalVsUjVlblB5TDdXTFJBRXF6ZUZpaDlpTnNsM08rNXYrZEJ1VlR0?= =?utf-8?B?eXdrRWEySXMxZVlOZ09idHVOVU5CWWZSdGNXRHhLbjA5cGRDa2tJRlpwRmhX?= =?utf-8?B?d0x5NXZ6U1NZZjE5OUNqdmJ3WjVVSHhUZFpWdWdoMEhwVkRxOC9QY2RnU2Zy?= =?utf-8?B?aHlGVW9SY1VkZ1VWY3Q4KzdyRnE2QnVOc2RLVFR3cERVcEJNQ2JBRUhIdGhx?= =?utf-8?B?b0RsS3VOeXF0WE01SnJZK0dJclFNZ3oyUk1Zb3psNHVmWEFHdEMvTU1yVkxo?= =?utf-8?B?blU5V0pDWUVuSU1Ha2ZVckF1bDliT09pbllOa2YyemtPNnlKMERNNTV2cXEz?= =?utf-8?B?NnBLclVVNWdkbXBhVEVZYzJxM1JEdWp0M3FjMHFNWlBUa3BZUXNqUlVZVVpu?= =?utf-8?B?Rjl2dStmakFOWHRCOEhHVXBrWkJXaDBOdmZybmVzT0E3T2xqSnU0RnArVUxt?= =?utf-8?B?TjlwWnFGYXJuVTdZdmJYaXBtcllKaFdySDBGVWQzMW5oUzFlN2pqdVhiZHdH?= =?utf-8?B?bUcyR3c3dm05UTkrdnJxaXZvRnU1N1JOV0taTXo4WTQwUnc4UUVDOWdsUmQ2?= =?utf-8?B?dnhGNkEvSzZVTmpMTXlMK0d6MHY5SzJESGNNTkRrcUN0MStld042eHdlSzB0?= =?utf-8?B?R05pOG9tUU1YdUk5aEllblpLQi9tT2wvODJ5Q3ZkTzRxYk8rYURISFZCWU1n?= =?utf-8?B?cGhyWm41Qk9aV2xyVkZNT0QzUTBqQllNTWN6V3BtK2tIM3lSRThYN0V3Lzd2?= =?utf-8?B?eldQanBtOStuVkR3QnJZQ0Ruemc4MVNmYVUvT2IvNzBBWE43QXNKei9HaDlC?= =?utf-8?B?RUo5OEFrd0t3K1pCelFTeWlNSWcraEFvODQydWNabWk3R0hUeDQvUU8zTity?= =?utf-8?B?RzJJMXRzOXhYcWJ1VVo3T1hLREx5ai9xWHB5a3l2TGZ3cU5uSlk2Q1ZFZXpI?= =?utf-8?B?YitqeGpKb3p0bGlHTUcweGgzckhQbUNtSVRzZ1hZNlBZRC9kQlNnSysyZTNW?= =?utf-8?B?R3NkSHVEVkZkSzdSNnBkR0xJeE53SERlMXBnU0tmRXpmWXRwVlVjNW95UThU?= =?utf-8?B?MEE3eXh2QW1YZlp3SnJqR1lSQUpnQzZ0Ni9FL294U2cydTM0T2dJWm9qWFpN?= =?utf-8?B?WlRONjYyc2hnaHhIRXJ1bnRWdkhDK3dCMGVPS1A0Q0dudHUwM3lRRmRXTlE1?= =?utf-8?B?SDVXWHJMaERBL3VHZGFqOVN6ZFRlb0dTaGZ2V3liYzdMaG9hLzdsdXBRNks0?= =?utf-8?B?TEd0YVZWS2huTHgvV1BYU3FxZGgzSnhIbnZ6MXhDdElKVzMrY2srdUFIbk83?= =?utf-8?B?VHo1eW1yK25GRXl2enNCRFViU2dObHl1VUNIOFkvcW5OYmJHL2VaS3FuYzRh?= =?utf-8?B?V2tSQmk4NDYzaWhUNjlsN2Zmd0hpaEZKTTg0WklMUWpNY3dkOFEwckFSeXVo?= =?utf-8?B?eG9CeXdsaEhTc25KSmtQNXphaTN3R3NSRDdjQ3hpd1NkZVE0eWppSFdWcHVw?= =?utf-8?B?SEJWOGR5ODJxT1NzOGhrbllFc3pZR0dCZU85SnBMUnc2c0Q4M3JCTHVhU2ZV?= =?utf-8?B?VmFWblB3a3RvUlp2ejBHdkxFT1lOQlduRU12U2c5ZGV0WkhMc2I3aS9TaU9n?= =?utf-8?B?M1U2N2RhR0xaaVNxbE9tOGRyc3A4N01HVUpXRGczUzFiMlBVd2NjSDF6Z3N5?= =?utf-8?B?OG5CWll2dnBRcy9Xc0hNUDZZVi9vQ2RscGREQ2RYbTN4MlpEMG1Bbzlqbm5m?= =?utf-8?Q?KnNsjj4yaxBtd4ok=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: Zk8NcIyCP/eeAJnpcwIonmZajaUG/9NNt5Wok2jjqx17VPnl7BbxAyDWkPQlf2s92sNT4OCu8js2EEeQY5t7i3Yz6FzxFuztVaSYubT0LXBfkkcbuVuS6qn1X0XlL61Y/K6vaksyG9+2x8sld+qS8gdhQZh4Mujae8ZxRVAY2JOiQrWiKh5bHjyBTXWfKN2NYJ/MN3nDGI9bZssUnmCL0FyiJeMi9BM+0BfvJAPBuI7NbtMA6dSadN0tDhVr8LPkgdFhxR94c6Ij+D8+crk1VEopj+wPYOhHKXEpAcfM3Lu7KYm9ivMOUkyViWdole0l9wgvZoeHGq5GBu7YJtcAEA== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS4PPF7551E6552.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebac24e0-c59c-4ebb-7e3f-08df29e04088 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2026 10:45:24.1352 (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: 7CU+PtffOEZJI+fw5TQNWimc3e9zD5lhNnRbryhnVI3qXZAxzYWJKc6Q2QBqFhJx4DZNfjomMkEs4oRlqNT6r7rjQ16oXaGp6sGzemaDm2k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7363 X-OriginatorOrg: intel.com X-purgate-ID: tlsNG-4011c0/1791974729-50ACCCFC-0AC46F1C/0/0 X-purgate-type: clean X-purgate-size: 4250 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9zZWYgQmFjaWsgPGpv c2VmQHRveGljcGFuZGEuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciA4LCAyMDI2IDEx OjAzIFBNDQo+IFRvOiBKYWt1YiBLaWNpbnNraSA8a3ViYUBrZXJuZWwub3JnPjsgUGFvbG8gQWJl bmkgPHBhYmVuaUByZWRoYXQuY29tPjsNCj4gRXJpYyBEdW1hemV0IDxlZHVtYXpldEBrZXJuZWwu b3JnPjsgRGF2aWQgUy4gTWlsbGVyDQo+IDxkYXZlbUBkYXZlbWxvZnQubmV0PjsgQW5kcmV3IEx1 bm4gPGFuZHJldytuZXRkZXZAbHVubi5jaD4NCj4gQ2M6IFNhZWVkIE1haGFtZWVkIDxzYWVlZG1A bnZpZGlhLmNvbT47IFRhcmlxIFRvdWthbg0KPiA8dGFyaXF0QG52aWRpYS5jb20+OyBNYXJrIEJs b2NoIDxtYmxvY2hAbnZpZGlhLmNvbT47IExlb24gUm9tYW5vdnNreQ0KPiA8bGVvbkBrZXJuZWwu b3JnPjsgSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPjsgU3RlZmFubyBTdGFiZWxsaW5p DQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgT2xla3NhbmRyIFR5c2hjaGVua28NCj4gPG9s ZWtzYW5kcl90eXNoY2hlbmtvQGVwYW0uY29tPjsgTmd1eWVuLCBBbnRob255IEwNCj4gPGFudGhv bnkubC5uZ3V5ZW5AaW50ZWwuY29tPjsgS2l0c3plbCwgUHJ6ZW15c2xhdw0KPiA8cHJ6ZW15c2xh dy5raXRzemVsQGludGVsLmNvbT47IE1hbmlzaCBDaG9wcmEgPG1hbmlzaGNAbWFydmVsbC5jb20+ Ow0KPiBSYWh1bCBWZXJtYSA8cmFodWx2QG1hcnZlbGwuY29tPjsgR1ItTGludXgtTklDLURldkBt YXJ2ZWxsLmNvbTsgU2hhaGVkDQo+IFNoYWlraCA8c2hzaGFpa2hAbWFydmVsbC5jb20+OyBTaW1v biBIb3JtYW4gPGhvcm1zQGtlcm5lbC5vcmc+Ow0KPiBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBs aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gcmRtYUB2Z2VyLmtlcm5lbC5v cmc7IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsgaW50ZWwtd2lyZWQtDQo+IGxhbkBs aXN0cy5vc3Vvc2wub3JnOyBKb3NlZiBCYWNpayA8am9zZWZAdG94aWNwYW5kYS5jb20+DQo+IFN1 YmplY3Q6IFtQQVRDSCBuZXQtbmV4dCB2MiAwMi8xMF0gbmV0OiBmdG1hYzEwMDogY2hlY2sgZm9y IGZhaWx1cmUgd2hlbg0KPiBwdWxsaW5nIGluIHRoZSBSWCBoZWFkZXINCj4gDQo+IGZ0bWFjMTAw X3J4X3BhY2tldCgpIHVzZXMgX19wc2tiX3B1bGxfdGFpbCgpIHRvIHB1bGwgZWl0aGVyIHRoZSBF dGhlcm5ldA0KPiBoZWFkZXIgb3IsIGZvciBzbWFsbCBmcmFtZXMsIHRoZSB3aG9sZSBmcmFtZSBp bnRvIHRoZSBza2IgaGVhZCwgYW5kDQo+IGlnbm9yZXMgdGhlIHJldHVybiB2YWx1ZS4gIElmIHRo YXQgcHVsbCBldmVyIGZhaWxlZCwNCj4gZXRoX3R5cGVfdHJhbnMoKSB3b3VsZCBmaW5kIGxlc3Mg dGhhbiBFVEhfSExFTiBpbiB0aGUgaGVhZCBhbmQgQlVHKCkgaW4NCj4gX19za2JfcHVsbCgpLg0K PiANCj4gSXQgZG9lc24ndCBmYWlsIHRvZGF5IGJlY2F1c2UgdGhlIHNrYiBpcyBmcmVzaGx5IGFs bG9jYXRlZCwgaXNuJ3Qgc2hhcmVkDQo+IGFuZCBoYXMgcm9vbSBpbiB0aGUgaGVhZCwgYnV0IHRo YXQncyBvbmx5IHRydWUgYmVjYXVzZSBvZiBob3cgdGhpcw0KPiBkcml2ZXIgYWxsb2NhdGVzLiAg VXNlIHBza2JfbWF5X3B1bGwoKSBmb3IgdGhlIGhlYWRlciBhbmQNCj4gX19za2JfbGluZWFyaXpl KCkgZm9yIHNtYWxsIGZyYW1lcywgd2hpY2ggaXMgd2hhdCB0aGUgdHdvIHB1bGxzIGFyZQ0KPiBk b2luZywgYW5kIGRyb3AgdGhlIGZyYW1lIGlmIGVpdGhlciBmYWlscy4NCj4gDQo+IEFzc2lzdGVk LWJ5OiBMTE0NCj4gU2lnbmVkLW9mZi1ieTogSm9zZWYgQmFjaWsgPGpvc2VmQHRveGljcGFuZGEu Y29tPg0KPiAtLS0NCj4gIGRyaXZlcnMvbmV0L2V0aGVybmV0L2ZhcmFkYXkvZnRtYWMxMDAuYyB8 IDEwICsrKysrKysrLS0NCj4gIDEgZmlsZSBjaGFuZ2VkLCA4IGluc2VydGlvbnMoKyksIDIgZGVs ZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvZXRoZXJuZXQvZmFyYWRh eS9mdG1hYzEwMC5jDQo+IGIvZHJpdmVycy9uZXQvZXRoZXJuZXQvZmFyYWRheS9mdG1hYzEwMC5j DQo+IGluZGV4IDQwYmEwMDFkNGIzZi4uYTFlYjA0ZWFkMmQ4IDEwMDY0NA0KPiAtLS0gYS9kcml2 ZXJzL25ldC9ldGhlcm5ldC9mYXJhZGF5L2Z0bWFjMTAwLmMNCj4gKysrIGIvZHJpdmVycy9uZXQv ZXRoZXJuZXQvZmFyYWRheS9mdG1hYzEwMC5jDQo+IEBAIC00NjksMTUgKzQ2OSwyMSBAQCBzdGF0 aWMgYm9vbCBmdG1hYzEwMF9yeF9wYWNrZXQoc3RydWN0IGZ0bWFjMTAwDQo+ICpwcml2LCBpbnQg KnByb2Nlc3NlZCkNCj4gIAlpZiAobGVuZ3RoID4gMTI4KSB7DQo+ICAJCXNrYi0+dHJ1ZXNpemUg Kz0gUEFHRV9TSVpFOw0KPiAgCQkvKiBXZSBwdWxsIHRoZSBtaW5pbXVtIGFtb3VudCBpbnRvIGxp bmVhciBwYXJ0ICovDQo+IC0JCV9fcHNrYl9wdWxsX3RhaWwoc2tiLCBFVEhfSExFTik7DQo+ICsJ CXJldCA9IHBza2JfbWF5X3B1bGwoc2tiLCBFVEhfSExFTik7DQo+ICAJfSBlbHNlIHsNCj4gIAkJ LyogU21hbGwgZnJhbWVzIGFyZSBjb3BpZWQgaW50byBsaW5lYXIgcGFydCB0byBmcmVlIG9uZQ0K PiBwYWdlICovDQo+IC0JCV9fcHNrYl9wdWxsX3RhaWwoc2tiLCBsZW5ndGgpOw0KPiArCQlyZXQg PSAhX19za2JfbGluZWFyaXplKHNrYik7DQo+ICAJfQ0KPiAgCWZ0bWFjMTAwX2FsbG9jX3J4X3Bh Z2UocHJpdiwgcnhkZXMsIEdGUF9BVE9NSUMpOw0KPiANCj4gIAlmdG1hYzEwMF9yeF9wb2ludGVy X2FkdmFuY2UocHJpdik7DQo+IA0KPiArCWlmICh1bmxpa2VseSghcmV0KSkgew0KPiArCQluZXRk ZXYtPnN0YXRzLnJ4X2Ryb3BwZWQrKzsNCj4gKwkJa2ZyZWVfc2tiKHNrYik7DQo+ICsJCXJldHVy biB0cnVlOw0KPiArCX0NCj4gKw0KPiAgCXNrYi0+cHJvdG9jb2wgPSBldGhfdHlwZV90cmFucyhz a2IsIG5ldGRldik7DQo+IA0KPiAgCW5ldGRldi0+c3RhdHMucnhfcGFja2V0cysrOw0KPiANCj4g LS0NCj4gMi41NS4wDQoNClJldmlld2VkLWJ5OiBBbGVrc2FuZHIgTG9rdGlvbm92IDxhbGVrc2Fu ZHIubG9rdGlvbm92QGludGVsLmNvbT4NCg== From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:02:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:02:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448709.1665732 (Exim 4.92) (envelope-from ) id 1xHK9n-00029n-Sx; Thu, 15 Oct 2026 12:01:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448709.1665732; Thu, 15 Oct 2026 12:01: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 1xHK9n-00029g-QF; Thu, 15 Oct 2026 12:01:59 +0000 Received: by outflank-mailman (input) for mailman id 1448709; Wed, 14 Oct 2026 10:44:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwT5-0004nT-10 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:44:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwT4-003T8E-6m for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:44:18 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5cca-bab6-0a2a0a5309dd-0a2a4507b370-42 for ; Wed, 14 Oct 2026 12:44:16 +0200 Received: from [198.175.65.9] (helo=mgamail.intel.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf5cfe-b4ea-0a2a45070019-c6af4109b1d5-3 for ; Wed, 14 Oct 2026 12:44:16 +0200 Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:44:13 -0700 Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:44:14 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) 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.49; Wed, 14 Oct 2026 03:44:12 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49 via Frontend Transport; Wed, 14 Oct 2026 03:44:12 -0700 Received: from CH4PR04CU002.outbound.protection.outlook.com (40.107.201.49) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 14 Oct 2026 03:44:12 -0700 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com (2603:10b6:f:fc02::31) by CY8PR11MB7363.namprd11.prod.outlook.com (2603:10b6:930:86::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 14 Oct 2026 10:44:04 +0000 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f]) by DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f%5]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 10:44: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=Intel header.d=intel.com header.i="@intel.com" header.h="From:To:CC:Subject:Date:Message-ID:References: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=1791974656; x=1823510656; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oQzRNnK5vwyyQeKvdyHpRRup8MZ7y+Sp/h2zbPxwwgw=; b=Asi2sLPAbupW/2SmCaRenQtoQVLfvZoegudBgGj6kQfH5uHNh08wEvbb 7cP4SO6IBLhO7Sf5P6+C2XKWoU65oKylzlmIReRJ95bZEKneZ/qXhTo3U DKSxbc91s8quZ+JfKALKNN2SFLR/rWsAwgEVOuIE0y0wromMXOPhPOFGC Wx4buRQ9h/P45pT6KxZkkgJr1/9l7+aIWZExXAoJTH/UeqgpvbvFyOnbW QWfQlgjSAGZahdlCYdETIPjHtJcrQ1ICCLZkxpmzVqWWfsgTE/8M5EBiu JEJCJO4BZnHh/UMN/591ezI4onyqVLMM2qxElf17QVV8+jnyMtQ+cdTsm Q==; X-CSE-ConnectionGUID: KBEqPcXYSd2maPotUP22mg== X-CSE-MsgGUID: Px2VZClgRiqW0iWzehk+mw== X-IronPort-AV: E=McAfee;i="6800,10657,11934"; a="604219" X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="604219" X-CSE-ConnectionGUID: ZJs0++6JTlmwEHKsblb/2g== X-CSE-MsgGUID: af/RwsDdSiqXx/pZi6+1bw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="1721542" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jHWu3wxewyIRfdfrrjQZnhd0ls4DiKXA4xMSz73oUh8630F5LuMm1QlOrVtaMcfxtQ/TSPhFRIqWvtRzxFpPYjzXV1CDSVdlKWeii6/uGWhdA1RKG4/m2Ce782FoVPoAAb+f1PekwojvVGzg3Bcy6WbtMZX3dfbFNcl0oHMJs7zmjNHs+VZF5VvZbBPZwzENJEiLr88meCQI/8DsGtoTrTc0ngsFzmNo2jCuuipMRSekhdrkbnuqXxCFtJVWxJM67ojPVjw5A5UkY2VPgNoAD7ykbWZyEx4V/VfduSO5AvZtnEkU8brYbKlIytKkzOfFRQ3qZGpWDSvMQA0KFlARxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oQzRNnK5vwyyQeKvdyHpRRup8MZ7y+Sp/h2zbPxwwgw=; b=r1IxJFVJNOkVLAWWosFbHwdSsgUh7BJfAqn8N8NryWskzEsQbSJJO7/LZwXhRMbY7KfRKRLgzAF1zRBG3Y3esAAIHwE2hzV5MBFAsjTh6iy3hx0jQUqJMp3mumf0nFvh8h/7vL7gtvP+It8UrfTHeUhVpyJ0CdBr+kcR5hibi8vHFXDeIYYM44VpmQll1sc6tItWt90wvpBVBkvLpy1e5hiynJDnSZhCJn/F6/ZhyGoh1T6s5CvXXO73kQ1YOzkCNHzTItSBckI8S1z4b3d8bE7P7gXn4pgxGPjewScDWGVmK0ZNs1r9yAeWBAmk0ZKumb6B/0eewouk5hX+X7/Q0w== 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 From: "Loktionov, Aleksandr" To: Josef Bacik , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn CC: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , "Juergen Gross" , Stefano Stabellini , Oleksandr Tyshchenko , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , Manish Chopra , "Rahul Verma" , "GR-Linux-NIC-Dev@marvell.com" , Shahed Shaikh , "Simon Horman" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "intel-wired-lan@lists.osuosl.org" Subject: RE: [PATCH net-next v2 10/10] net: skbuff: don't reset truesize in skb_condense() if the pull fails Thread-Topic: [PATCH net-next v2 10/10] net: skbuff: don't reset truesize in skb_condense() if the pull fails Thread-Index: AQHdV2iQSwkJ8X/q3kW4y1x3MSmxj7b84vew Date: Wed, 14 Oct 2026 10:44:04 +0000 Message-ID: References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008-b4-pskb-pull-tail-drivers-v2-10-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-10-8f2bd9bee138@toxicpanda.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=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS4PPF7551E6552:EE_|CY8PR11MB7363:EE_ x-ms-office365-filtering-correlation-id: fa2586c1-0cc4-496a-db0a-08df29e0110e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014|23010399003|22082099003|10067099003|38070700021|56012099006|18002099003|11063799006|4143699003|5023799004; x-microsoft-antispam-message-info: wfkMq+tUFuF6efn7D9aqeCCJn9L34GIrjDEXG4+7XcfM0QY1temnvI3PyKh8cuZkv0dxjBhhMtnFl2R3J/UdXMPvBr9Vv97rfsXoE2yWAprjCjZ38SVsyXqGKZLpdUEorM23/8tO3Eqc4F0hhgZG9vvlo5lX++4Xf77UI4ELH8lA8+9GBdRTIBwRP+mhtQNoRZ6d4iv+CG28M9syBZvynTJButP8HrPplKHJV0O9MQBs//vV4XoN4bnxjaNMyw3sZ5luIXk4iYi7RsSu2r37Uq1jougwliWWNLagZx9E6jBn4V/ac/+Ghe4DhfhjH2sv5Z6GYCteNSElsD4CUzzhP1MAKJYTDwTiPJwwht4v4p5u7rhxYgzvEDIpf/XRR8W+lRSameucfOsF829ZvOgbOUfrk63ipl5dorK2fyf/wkjVE0PZIECuEmi04B3CkJCUOS+2grv4yFpa/uhZFEcxFjaz1I7mpAVsXv78FTtPzBnlBxT0g5jWZqrXKbManC5gYFrNKk50UEaS2GgSAWKQMaUM9fpr76w4iAlKyOqVRuQtKkuW/2qES8Z0SfHkWVoJCpV9KtvhBZQmGLcO2BeSE65BUSpY+6oKoEhEJ3pb999srhYgk67ppTT/jdviI8F+f8UWq0CKaCcmcUy4K3LIRvlpcOd0BKRO5BZJbalYMiphjp3YdbWyUpVvVCMjvuS70rRivNYlmQGIi438PYEo/ER/6YSqLf68W4qf9vrab/w= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS4PPF7551E6552.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(23010399003)(22082099003)(10067099003)(38070700021)(56012099006)(18002099003)(11063799006)(4143699003)(5023799004);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?KzhDU1hVVTQyb1JvSWRPb0hwZWVWRjIvWDIvckR0WWdYNUkxSnhMc0tFb1h0?= =?utf-8?B?SUZvcXBiRUl3MTk1ZjA2c29DNVRKeU5idGYwNnN3MHJWdUhURHNjWi9ycjkv?= =?utf-8?B?dHVzb25DTE5Talk3NkUyRDg3K3ZhS3NMY0F0Y1FWQWo3dk54L29hTEd6WVhE?= =?utf-8?B?WEdqcW0vODVUYW14aE9OY2lvUGVJTldyQXlZNlZTOUEyNGE5OEpSa3BJWlBS?= =?utf-8?B?OTVmVUdYQXdLeW5HUytqMU1SeExkSWJsbEdsZ3pUYnhmWThtYkVVNzZyVTlv?= =?utf-8?B?Zk5iY3Vxa0hER3A3dG5Za0hISjBLUUdKK0E0QVhIc2RydGtZM0EyRUorSjlL?= =?utf-8?B?aTc0c2orNlAzSkJ4WnQ4RTJKb29hM21vOElYUzFiSnZsOXdVVnVCbWcvMzBX?= =?utf-8?B?RTkrWWRGM2t1eXphUk1BcUZZei9sbGkwc0NQdy80VnpHV1REUXB5a01kVXha?= =?utf-8?B?eDVWS2diZjE0YTZ5dWl6NmFKUUwrMUoweC9KbGU2TlhCNzN5VHgxbkRIRGhQ?= =?utf-8?B?Z0w1RjlXQ3hDQ09wWE5DL1ZDVlFnQTdWbmcrcjltbGt2bm1CdzlZYnBsMFZY?= =?utf-8?B?VW12THJHR1A1NmtCbzlMUHd4ckNMVFpVN1B3WGFaZFVIaHlEaHh1UVB5NW9C?= =?utf-8?B?ZGRhUm9jNWMxMnVFaVpnbjhGdmp3dDIrUS9mUTJCSEJ5L1pnaUJpMUxZNjRU?= =?utf-8?B?MnBkOXpaS2lSRXRhSTV1VkZ3d0dxMmN3dExRZS9vQklVK2hnUDc5cnJiZTUz?= =?utf-8?B?YlhiUWE4dXdNWTI4SlY2M0R2VzVJbmw5S1ZJMDEzcUNxRjZHT1dCTFlVSERh?= =?utf-8?B?T2NVT2haclNHakV5WDJRVERQbmU5MGhHa1c0SmdvMnM2bVlPcVFyNUNCN3lo?= =?utf-8?B?N1RhTlYxOHk2SEJSbkVPMmJGaUZYbHJPTmp3M0pvWHBLbkMyMnZIK3hOOEwy?= =?utf-8?B?RnArUWlLSHlPRXpWaVJ0RXFEQm9wNFVvclBpWjh6bmtrcEtzdU9wREw5RVZM?= =?utf-8?B?NTZSTDVOSlU4RW1RQk51VGVUVGgvQmJYUGhieTZGL0NtTnN6NzM4alBDdVgv?= =?utf-8?B?SlJkMlBMdklhRmhxejBKYVptUC9KL2x4WUtBeXlXcXhRYTFlU1kvY1QxUGhD?= =?utf-8?B?c29ndTFBdHViNmlBNVF6aGtKSm9MZXJJQk9HZnpHRy95Nkh3V1c2MFRHbkhW?= =?utf-8?B?ZGlIL2M3RXBNT1NzNmxHTHFXY0VWcFY1bHFjY2s2czA3cGV2MzNpd1ZXRFU4?= =?utf-8?B?Ymk2ZGszeVFPdXp4RkRwcmFhWmhNaWRSQ1NndFBQbDUyWjV5YkhyMTNkMGdT?= =?utf-8?B?c01OYTdlZmJTV0ppdFVOaVBVbUNFcDA3WWh3d3lrL2FITStGNHIzQjB6Zit3?= =?utf-8?B?SGk4c1l0cm04RFBNd2h1VHhDTkF1ZW1meHNaOWwweU4wQnh5bjVrQkNsd091?= =?utf-8?B?Zll4RlZNakJaZE16WkJlR0VVb21BRjlrSXVwZWRvTXBJNEZlTlZzS3FrajNj?= =?utf-8?B?b3F3c0FNbWpIL05oSjBralFQalYvR0RiTkhTaFZwTVhsUmsycmxjMEJicDRr?= =?utf-8?B?R2Z4Ny84empZd0ZiVzJuSFV1QUNsTmtyK3dJbytySmIvR0tnWTBzaGdCUHRu?= =?utf-8?B?azR0bTRLeFZRdFgzZHpFdnpDanZIVEVLNWVlQ2JsZXVPNU5MY3RDVjFoaUxK?= =?utf-8?B?SEhyS3pFTlV6NTlCUGdNc3o0VEpVOWduYUQrQ2MvQ29nWENBR0NIa2lOUlRB?= =?utf-8?B?UGVjSy9rRGQ3ZGU1c2VwYXo0NWxMRWpSejdKb1BjaWZBeVBpZXNXc2lOcVRy?= =?utf-8?B?dk94TTVFcUI1OVFkdmRzUjBscWNsOEJwZEsxZUFWTDA1WFJZaGNyVkh3UCt2?= =?utf-8?B?OVJEaGk0Q1U4VHFMajRCZXJNRC9ZZmVPcE9WQWN3Szg2aFNWcHJSNXpKL3Zk?= =?utf-8?B?dHI5RGxOVVl2WmVaODllN28vZm8wbkVWQ1phRWJuYWMwM2JnV0tyRzZLbDhL?= =?utf-8?B?R1RUaHgwMGVCbE5QK1VweVZSUklxOXJqVmszRlNIek4xRkRaS2x3NnhpRzhC?= =?utf-8?B?Tzdsb05DTUJXdWZpbngxNUx3bURXLy84bUFYd3RSZEZsczBvMlVjRjJ5dDU1?= =?utf-8?B?ZVVwT1VFT0tsT1o3K0FlK1J6ZENOWUV0dllpZk92Q2MvdU0zV204dnRGK2VZ?= =?utf-8?B?bm1lQXFKMkNYMFRiOWdZZ2c1bUJaT200eHQ1dUY2WUdzMHJFWnh4bHhUNFZp?= =?utf-8?B?QWRpRUIrUjdBSWs2TEtiRW5XK3NnWW1UT2FNakpqemNJY0hLWlo3KzN4QjNZ?= =?utf-8?B?eHF5NGQyZnZuelV3VzBWMXJmYnJsRktsNTF0ZStBRTdqUzJFK25uK0w1bHVl?= =?utf-8?Q?XNGMkPP00xOpuqXo=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: ldkai9o4kbN+Ml/8B3OdNM/x5XantGxcPQ+ibKidtL9kcv/yCCKX6nYcbYGUsit5XyhuS/OGpK3mgMfQdGWxEF4U6uZgNYV7JFVi5OWBPjUuwZj0zOgNW+lYV/vp5P8l6j6TpJMxzIiRFcpy/kw1wilNkpssuJh0OSiaxIMi5+bgCTnewrZvG81mumHLbSFxvnvev+fzKcDeM03rSec+Xmis6OHXwExGy5EBEu8iaIVUedWEZ2itrjKtLhkPnpJa27GIRaluHgfLn807mEusmp46W0XMncOAG3Lj+hSqporamjewdxLYU8sdo6WSke2PTJgcXjH6FRK27EqnNWe4rw== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS4PPF7551E6552.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa2586c1-0cc4-496a-db0a-08df29e0110e X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2026 10:44:04.4943 (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: w/7TxqAfR6qtT50ndJG+m0HawjIrLeasxDXmtRp5x8uW4ybNPcjgXpaHBP7HfwfbeJnGgEqIjSYK+9kWWGFfrHHqL/IYEsU9bMajrl+Ke4c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7363 X-OriginatorOrg: intel.com X-purgate-ID: tlsNG-ef75cf/1791974656-A54C3AE4-0269C389/0/0 X-purgate-type: clean X-purgate-size: 3580 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9zZWYgQmFjaWsgPGpv c2VmQHRveGljcGFuZGEuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciA4LCAyMDI2IDEx OjAzIFBNDQo+IFRvOiBKYWt1YiBLaWNpbnNraSA8a3ViYUBrZXJuZWwub3JnPjsgUGFvbG8gQWJl bmkgPHBhYmVuaUByZWRoYXQuY29tPjsNCj4gRXJpYyBEdW1hemV0IDxlZHVtYXpldEBrZXJuZWwu b3JnPjsgRGF2aWQgUy4gTWlsbGVyDQo+IDxkYXZlbUBkYXZlbWxvZnQubmV0PjsgQW5kcmV3IEx1 bm4gPGFuZHJldytuZXRkZXZAbHVubi5jaD4NCj4gQ2M6IFNhZWVkIE1haGFtZWVkIDxzYWVlZG1A bnZpZGlhLmNvbT47IFRhcmlxIFRvdWthbg0KPiA8dGFyaXF0QG52aWRpYS5jb20+OyBNYXJrIEJs b2NoIDxtYmxvY2hAbnZpZGlhLmNvbT47IExlb24gUm9tYW5vdnNreQ0KPiA8bGVvbkBrZXJuZWwu b3JnPjsgSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPjsgU3RlZmFubyBTdGFiZWxsaW5p DQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgT2xla3NhbmRyIFR5c2hjaGVua28NCj4gPG9s ZWtzYW5kcl90eXNoY2hlbmtvQGVwYW0uY29tPjsgTmd1eWVuLCBBbnRob255IEwNCj4gPGFudGhv bnkubC5uZ3V5ZW5AaW50ZWwuY29tPjsgS2l0c3plbCwgUHJ6ZW15c2xhdw0KPiA8cHJ6ZW15c2xh dy5raXRzemVsQGludGVsLmNvbT47IE1hbmlzaCBDaG9wcmEgPG1hbmlzaGNAbWFydmVsbC5jb20+ Ow0KPiBSYWh1bCBWZXJtYSA8cmFodWx2QG1hcnZlbGwuY29tPjsgR1ItTGludXgtTklDLURldkBt YXJ2ZWxsLmNvbTsgU2hhaGVkDQo+IFNoYWlraCA8c2hzaGFpa2hAbWFydmVsbC5jb20+OyBTaW1v biBIb3JtYW4gPGhvcm1zQGtlcm5lbC5vcmc+Ow0KPiBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBs aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gcmRtYUB2Z2VyLmtlcm5lbC5v cmc7IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsgaW50ZWwtd2lyZWQtDQo+IGxhbkBs aXN0cy5vc3Vvc2wub3JnOyBKb3NlZiBCYWNpayA8am9zZWZAdG94aWNwYW5kYS5jb20+DQo+IFN1 YmplY3Q6IFtQQVRDSCBuZXQtbmV4dCB2MiAxMC8xMF0gbmV0OiBza2J1ZmY6IGRvbid0IHJlc2V0 IHRydWVzaXplIGluDQo+IHNrYl9jb25kZW5zZSgpIGlmIHRoZSBwdWxsIGZhaWxzDQo+IA0KPiBz a2JfY29uZGVuc2UoKSBwdWxscyBhbGwgb2YgdGhlIGZyYWcgZGF0YSBpbnRvIHRoZSBoZWFkIGFu ZCB0aGVuIHNldHMNCj4gdHJ1ZXNpemUgdG8gY292ZXIganVzdCB0aGUgaGVhZCwgYnV0IGl0IGln bm9yZXMgdGhlIHJldHVybiB2YWx1ZSBvZg0KPiBfX3Bza2JfcHVsbF90YWlsKCkuICBJZiB0aGUg cHVsbCBmYWlsZWQsIHRoZSBmcmFncyB3b3VsZCBzdGlsbCBiZQ0KPiBhdHRhY2hlZCBhbmQgdHJ1 ZXNpemUgd291bGQgdW5kZXJjb3VudCB0aGVtLg0KPiANCj4gSXQgY2FuJ3QgZmFpbCB0b2RheS4g IFRoZSBjYWxsZXIgaGFzIGNoZWNrZWQgdGhhdCB0aGUgaGVhZCBoYXMgcm9vbSwNCj4gdGhhdCB0 aGUgc2tiIGlzbid0IGNsb25lZCBhbmQgdGhhdCB0aGUgZnJhZ3MgYXJlIHJlYWRhYmxlLCBhbmQg cHVsbGluZw0KPiBhbGwgb2YgZGF0YV9sZW4gZWF0cyBldmVyeSBmcmFnX2xpc3Qgc2tiIHdob2xl LCBzbyBub3RoaW5nIGlzIGFsbG9jYXRlZC4NCj4gQ2hlY2sgdGhlIHJlc3VsdCBhbnl3YXkgYW5k IGxlYXZlIHRoZSBza2IgYWxvbmUgb24gZmFpbHVyZSwgc28gdGhpcw0KPiBzdGF5cyBjb3JyZWN0 IGlmIGFueSBvZiB0aGF0IGNoYW5nZXMuICBVc2UgX19za2JfbGluZWFyaXplKCksIHdoaWNoIGlz DQo+IHdoYXQgdGhpcyBwdWxsIGlzLg0KPiANCj4gQXNzaXN0ZWQtYnk6IExMTQ0KPiBTaWduZWQt b2ZmLWJ5OiBKb3NlZiBCYWNpayA8am9zZWZAdG94aWNwYW5kYS5jb20+DQo+IC0tLQ0KPiAgbmV0 L2NvcmUvc2tidWZmLmMgfCAzICsrLQ0KPiAgMSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygr KSwgMSBkZWxldGlvbigtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL25ldC9jb3JlL3NrYnVmZi5jIGIv bmV0L2NvcmUvc2tidWZmLmMgaW5kZXgNCj4gZjc5ODExOGRmMTEyLi41NTZkMzc5ODFmMGYgMTAw NjQ0DQo+IC0tLSBhL25ldC9jb3JlL3NrYnVmZi5jDQo+ICsrKyBiL25ldC9jb3JlL3NrYnVmZi5j DQo+IEBAIC03MTU4LDcgKzcxNTgsOCBAQCB2b2lkIHNrYl9jb25kZW5zZShzdHJ1Y3Qgc2tfYnVm ZiAqc2tiKQ0KPiAgCQkJcmV0dXJuOw0KPiANCj4gIAkJLyogTmljZSwgd2UgY2FuIGZyZWUgcGFn ZSBmcmFnKHMpIHJpZ2h0IG5vdyAqLw0KPiAtCQlfX3Bza2JfcHVsbF90YWlsKHNrYiwgc2tiLT5k YXRhX2xlbik7DQo+ICsJCWlmIChfX3NrYl9saW5lYXJpemUoc2tiKSkNCj4gKwkJCXJldHVybjsN Cj4gIAl9DQo+ICAJLyogQXQgdGhpcyBwb2ludCwgc2tiLT50cnVlc2l6ZSBtaWdodCBiZSBvdmVy IGVzdGltYXRlZCwNCj4gIAkgKiBiZWNhdXNlIHNrYiBoYWQgYSBmcmFnbWVudCwgYW5kIGZyYWdt ZW50cyBkbyBub3QgdGVsbA0KPiANCj4gLS0NCj4gMi41NS4wDQoNClJldmlld2VkLWJ5OiBBbGVr c2FuZHIgTG9rdGlvbm92IDxhbGVrc2FuZHIubG9rdGlvbm92QGludGVsLmNvbT4NCg== From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:02:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:02:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448714.1665737 (Exim 4.92) (envelope-from ) id 1xHK9o-0002C8-7Q; Thu, 15 Oct 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 1448714.1665737; Thu, 15 Oct 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 1xHK9o-0002Bs-18; Thu, 15 Oct 2026 12:02:00 +0000 Received: by outflank-mailman (input) for mailman id 1448714; Wed, 14 Oct 2026 10:44:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwTU-0004pi-AB for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:44:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwTT-00B1au-NG for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:44:43 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5d0f-2eae-0a2a0a5409dd-0a2a4506a344-18 for ; Wed, 14 Oct 2026 12:44:42 +0200 Received: from [192.198.163.19] (helo=mgamail.intel.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf5d18-195a-0a2a45060019-c0c6a3133af9-3 for ; Wed, 14 Oct 2026 12:44:42 +0200 Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:44:40 -0700 Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by orviesa009.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:44:40 -0700 Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) 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.49; Wed, 14 Oct 2026 03:44:39 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) 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.49 via Frontend Transport; Wed, 14 Oct 2026 03:44:39 -0700 Received: from CH4PR04CU002.outbound.protection.outlook.com (40.107.201.28) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 14 Oct 2026 03:44:39 -0700 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com (2603:10b6:f:fc02::31) by CY8PR11MB7363.namprd11.prod.outlook.com (2603:10b6:930:86::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 14 Oct 2026 10:44:31 +0000 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f]) by DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f%5]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 10: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" 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:References: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=1791974682; x=1823510682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CcSB8elyvCi+p1mtt6572P5Aq3yd8cAvJuoCNeew4eI=; b=nSmktH0ijGGDDmmkNLXG0655wvmRt8fznZgOPr7XUVhRGY5QdnZ1Oucp ggmHIYBedRHyY/wjAL+/OpcrlZl5WmAN4jAGuBpPTNCWdzu9GlEcyDSnL 7VBTdrJt+H27sIoJv9Hln7MO9bx9mml4Y6/NmzPVeB3M+Q3qI5uVS64o6 Z8EXUDQ8rEfSfg8t8m7kE5laQiZNLe1tfON8PLExr5pi4/Udoet+AILg6 qWjeIiL6MajWQL81ghESON2oh1JmdoT1IuRk2IMWqOTe777fsdPVnUbkS S4gycIeW9NrKshUTHaVw1283Yy8Gd4Zyhfhhs6RuLJ0Xfh/iYPC+h2PCR Q==; X-CSE-ConnectionGUID: SdIV9hwdQCaSRpA9iYTWsw== X-CSE-MsgGUID: RSvwCjk6QuWutq4IPtGIRA== X-IronPort-AV: E=McAfee;i="6800,10657,11934"; a="823091" X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="823091" X-CSE-ConnectionGUID: vVgPEQ3YQaiVFZPuiTPU8g== X-CSE-MsgGUID: rE0VmaGwRDWZxcbHpGxurQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="1323170" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=c7Be2v8yviWubEKFJAdIw0TKazXCP9AyRq9zTW8oaCJBcsqCnMts1/qzdk2ao2KaMisx9iESbu7qwMA6t2sBg9JOMUE9RBtG6lNG1EcFP3En2w2udoVeDfv1Sr7hjS/yuEXipPWTVo+OzjZudYngs/akCLnYbWer2BeZMe8G9/sSViYt+wcAITUHDy9hYGw3PiFH5Mj7KUJZ2Qjpyx6L/E8iwR1ztpKkpTs2Ymj3mcvk+3/Tn3ea8WWPQh2f8gDtTHqJ3GY6hxnbq15AOgKbZKvTPoR/2g54nIn9MyiM129Nd6BAaM0mL2i89hs/5h/jQDfM15GsrANgd2YjKahZqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CcSB8elyvCi+p1mtt6572P5Aq3yd8cAvJuoCNeew4eI=; b=Xg6rk3qOD6e8tBlaLzOkJttntuWIQU+Yd3InB5t1QnXQmrZ1h/AfsZBfQALgG3a4hAS7KoS2/MmFnS8BR98ER7+37aSqw4JWysI+K4couBRo+wlRHXf7+s4AAdyz0kMtDwltPGv3QMstXj24mvd+ESI85zc0etJZP34lJ8YRCKd1CAHthex58NhPVNcB1PfQzXF6JUGbkOIS9zASCqdBsg8r0G48wyMKEHZFIIDzWI1ivU6VYO8xB96B8aK+vtvlXajop4B4sQi97tvcWdfmgN2ag4uqccm1gBTDEkyDZcOWuOlPGZOQ6gMe2OF2zqQXCaj2WIFOgV+ILmGgoFduZA== 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 From: "Loktionov, Aleksandr" To: Josef Bacik , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn CC: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , "Juergen Gross" , Stefano Stabellini , Oleksandr Tyshchenko , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , Manish Chopra , "Rahul Verma" , "GR-Linux-NIC-Dev@marvell.com" , Shahed Shaikh , "Simon Horman" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "intel-wired-lan@lists.osuosl.org" Subject: RE: [PATCH net-next v2 09/10] qlcnic: use pskb_may_pull() to pull excess TX frags into the head Thread-Topic: [PATCH net-next v2 09/10] qlcnic: use pskb_may_pull() to pull excess TX frags into the head Thread-Index: AQHdV2iPhjcjoTngS0CJA/3Rchai4rb84yFw Date: Wed, 14 Oct 2026 10:44:30 +0000 Message-ID: References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008-b4-pskb-pull-tail-drivers-v2-9-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-9-8f2bd9bee138@toxicpanda.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=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS4PPF7551E6552:EE_|CY8PR11MB7363:EE_ x-ms-office365-filtering-correlation-id: 48291a1a-303a-4bf4-857c-08df29e02090 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014|23010399003|22082099003|10067099003|38070700021|56012099006|18002099003|261009223027099003|11063799006|4143699003|5023799004; x-microsoft-antispam-message-info: KtGJvRT8zuZt1rfLaGSo+JQ0woxUGJSi9DshXb8fk+xmALoNiSStLih9qUkAP2n3DNJ/zjMmA7QwcwL5172oqrN/urHLWyETRICcOTUB/yBexPF36t7tPgjCdnL2p2j1VTfTasiS9HAd+fqPp+Zna31vmuR54cIYynHQgTOV/HB8UnKLG0v2CbCmqCzAVoPXMO85f0ff1kDRsN2CbNA//yK4uOBwmfwUg57bgTyiWhPs19rm7JThlRrR31OTm4HVjdIevQQTBn9wu5YCvMJzDDQy9CBy9OAAWAW3JUv0QPEAwsVtDv/zf8TDH1oOh5D4MoH584xg7i29RlkavwbX8G3CUKThFkGwj+LBtU5tv6SjvvUOX62c0JHZkgZrXjtShGaQYS3IhuvtjA+V9u2q24+nI3fOkE+uW84SrjCQVsq537L4iP+r2uE4URlx9aZEQw8t4hUm59aSaGFfzWKO74EMP+/zHCMolloYYG+Q43J84YmM1H1qaOuYVEsDF72mc6vry0Z67/DRh8PckJ0zCRD9F8kN1Pd8QG0Lp3O0Hq3G4no+QoxAvItqDRCfZCCXEf/MIoKGEbwsxMhIXeaNidFXW8wWKUQa5GZgAq+MCW0HMoO5j6CcPXF1d5F4TS4qc6YSfII/AsoY1wsMfNQXvZssBZnV4K9Wcmr81TFVu0ts4uhY8fEL3P/6xk8A/Xu4BJtQQNoUNXPHZSPFlWV2PICuO+LNrKXPFWwvLtjG58w= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS4PPF7551E6552.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(23010399003)(22082099003)(10067099003)(38070700021)(56012099006)(18002099003)(261009223027099003)(11063799006)(4143699003)(5023799004);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VFpPUTVPWVE4REFHUnA1RGl3SzBBRkc0dHVVTzVxYjM4WklIMmxCdFc3aUFR?= =?utf-8?B?Y21sNmxYdm14K1pyWjVSeE4wdS9rdVhQdEtHcEUyZno0MDZUbm0wb1NkejRY?= =?utf-8?B?OFJubXBMdHhEdXJKZU9XM0F5bW9KWjdyWlJuRjZ3em52NHd3UGN6dGJuZU1l?= =?utf-8?B?VkRwUUtoVGtITytRZlNEM0wxRFpRZVpKTnpBUlB5Ynk1R05pYkgvbzBWcFFL?= =?utf-8?B?bUI4Z2ErOWVDdytJajVyM1Q3am9UTlo0a3Y1eTF3bUFJcXM3RE1kWW9hZzdG?= =?utf-8?B?WjVEZld0UUIvK0JLK2NZbkx6TlVBQ3RyMHZvb2h2QlM2R0hlNDMxZ2R1T1E5?= =?utf-8?B?M0Q0REVaMFkyVUlBRkFRM2RCdmhmSTIzdEZzQ1VHTXYwUlpqMTFYQjRQVmw5?= =?utf-8?B?aVNudTM4bm5JcmI5bTVXZWd0U1hwbHBpRG90bzlvREFZRGxoc2JiRFJmcDFw?= =?utf-8?B?ZnB5anF6R0dnZldPV1M0ZUUyejd2YlZrSVNhUWd1MUFScEdzalNUS2RqL0pS?= =?utf-8?B?V2crS3FwWUxlRHJNTGlOcC9PZ3BvM2xaSHI3TlUvWG4zZkZaaG1MTjlrWldC?= =?utf-8?B?dHZvdlgvRjhxanhSVnZ5aXJMOHVERE5RTUJMN0t6K1MzSWE2RXd1N0ZnMkJE?= =?utf-8?B?VldFNzNTa25SZzRZd1JyV0lkbEdCcGlPb2hvbk9TMVlDWlNONERCMmNLMmVN?= =?utf-8?B?ZW9xRGI5bDhobjVFWjRyc3JqQm9nMDRpcnN1K2d5ZnBYM3JjUFRJN09uQXpp?= =?utf-8?B?WlZVVXliTzg2TlMxTGNaS25RRlRtNDgrMHdveEJvREVuWG5QY3A1SXBJWW56?= =?utf-8?B?ZUdkTnRtL2FzVFVLdjdWbFNSays5VG5jZTRNaTUxeHFxN0hwNXVQekJJWDBC?= =?utf-8?B?KzJMUEd6MWV2b2VZL1VPcy9qTVRMeWE2MFcvbUtmUlZrN3BkZDdVdlQzejF1?= =?utf-8?B?SnV5VTdjVGFEa3JRZDhhSmFQTHRkR1lEUi9JdGpCNzlBSGdRampybHZIT00x?= =?utf-8?B?ZGN1ai9sUFNEdHExK2xBRm5mSzQzWUlVY0ZuRDVWMFU2TUpFeitzbm1YRXV3?= =?utf-8?B?SjliR2xLY2NCZm9UZDNla2RtTWlxVWU3NmtXazREclhuQlpGWTc0SWt1Z2VF?= =?utf-8?B?SFhqU09sSGlDT3pHMHJLRGxxOWlXM2JsZEZDcVZseFB5YkloTmd2cm9LOVlY?= =?utf-8?B?VmFlOFNRUGlSM3YwT0RmS0dGSWNhbWRoUU9EMHQvMm0wRjA5Vys3UDhIblpB?= =?utf-8?B?VjhRUUpOcTVkUzNGbmRPN3pZcmVaLysrRzdKSnFTNll6RDRFMUI3QjFubWE0?= =?utf-8?B?VytwUEs0ZTVObG5FN1R5YUo2SE5sWjBGQks5NEJDLy9nbXJmR0dwOXBVcW5i?= =?utf-8?B?VHdUZi9WN1JJNnVoZXNNVnhiR1RaV3VVa0p4STlQcHB2NkZVTExuNjk1VGNU?= =?utf-8?B?RkJWTFozWmFxN0ZtejFmVzFVdzRkRUx6ZTMvaEpGc1lrYXhvTGFMV1I5Y3lo?= =?utf-8?B?Ky8wVW56cm1hMmZpcXh2UFR4S0ZIWGVaMER1ZGdrcjZZcVpLL1dFQ1Q4dnBX?= =?utf-8?B?WS9ZVXR6M3NkUnNFK3MvZVNpTm5Pa0EyT3FzV0VCRjArakRlZ0xlU1p4N3V0?= =?utf-8?B?SmM2OUdHcVNiZGg2WXQvZWk5cjN5TjlyRjNLbEwrV00vYjUrYUxCSW0vMU5w?= =?utf-8?B?K3RyUEpFTFZ5L3NFakhSczliTXJ5TjhITkcwMzJMUmNnRnlkUHpqK01POE83?= =?utf-8?B?N0wrSDZhYkVKa2Nva1VCR0hCZDZ2MUM0M25remRQMjZBSUljUkgzMk14VHh3?= =?utf-8?B?V3FoZTZkdVpHR3AvdDN3WmRXNGh0YXdHbHJTZklaTHNNZGJQdDNHR0xVK0U0?= =?utf-8?B?N2dhb0NoYnIyVXQvczllb3ViSkNuUUlCbHNML1NhMWJuYzQrMEFzVlU0VHRJ?= =?utf-8?B?WThTbFEvQWxTcEQ1aXVLZmR2N1liOGdqWDA4RnNqSEFHLy9WUnpoemlzMzhy?= =?utf-8?B?SlVNZzlyQUtDMlk1RlJ0dGhqdFdNcHpINTh5ODQzd1F6RExDUmphTzRiN1Fq?= =?utf-8?B?Z052MUdsWlVNRGJ5bnFsbnFpeVpQajVmWW9CSUllMUlYbWRuR1BEdlpBSy9o?= =?utf-8?B?YU04bUt4aUNVMGk3eDJqRG1oa1FQK2hmdXJuc1dRbWdGNGNPTlNYYkNGc0Mr?= =?utf-8?B?cUVTaTBBb1pMeW1KclhEZGlPUUtBQ09xa1c1Z29mMmVQQzNZOXlzckoySTFI?= =?utf-8?B?R2J2WHN1VnhzT2JhZTZvWFlBeVhxQ0xKWnRweGFjRnlEUnFjV0s3b2lGUmhs?= =?utf-8?B?WUV3ejQ5c3ZVSlJkakIrMjNJWG1VRWJ6ek9MSVRSaGgvOW43QmwrY2RaVjF0?= =?utf-8?Q?fPhIw2YilcSxHLZI=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: vuDc7dpOLYqEKoOtmwtfDW2vKqLo5nJSNfLY2/J17u94cd97nkjx7S/KRllNDs5KF0Zcci7n1dxrlNZEMF2GRE0H/pFBz9kQtt3oJoYAfAAa2ly1Qa4QlqclNSNwvEECQzyzRSnlwx7EW0fGlfy7hqN3IwKfQUIBCfei/f/leBxWyehh5Yumc1RL7Zsu6PQNdT3jxhdjaN3hqDQDfYVcDLZMIzs9vyDBaZJklUqrYShsQWp+vwmJQCDSEArFnhHwgSySdIs9d8zILJEF9+VX+x6ykTbaWTccc7vffaMlXCTyKVspVJREedKU7DQOj8M+9MY25QQjevGVaveQl8P1sg== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS4PPF7551E6552.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48291a1a-303a-4bf4-857c-08df29e02090 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2026 10:44:30.5264 (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: zHT+TQy104Mt9/A5GSLzdLkkF2tGoqGwZsJO29KfwwtOpZkrKvOCNhiXDK3lM4b0TileJ7yXsyr+fPHQ1Dl+TOWpTYp/e92V3UbRQ+9VwUU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7363 X-OriginatorOrg: intel.com X-purgate-ID: tlsNG-16d1c6/1791974682-1F8CB77B-A467C6E1/0/0 X-purgate-type: clean X-purgate-size: 3844 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9zZWYgQmFjaWsgPGpv c2VmQHRveGljcGFuZGEuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciA4LCAyMDI2IDEx OjAzIFBNDQo+IFRvOiBKYWt1YiBLaWNpbnNraSA8a3ViYUBrZXJuZWwub3JnPjsgUGFvbG8gQWJl bmkgPHBhYmVuaUByZWRoYXQuY29tPjsNCj4gRXJpYyBEdW1hemV0IDxlZHVtYXpldEBrZXJuZWwu b3JnPjsgRGF2aWQgUy4gTWlsbGVyDQo+IDxkYXZlbUBkYXZlbWxvZnQubmV0PjsgQW5kcmV3IEx1 bm4gPGFuZHJldytuZXRkZXZAbHVubi5jaD4NCj4gQ2M6IFNhZWVkIE1haGFtZWVkIDxzYWVlZG1A bnZpZGlhLmNvbT47IFRhcmlxIFRvdWthbg0KPiA8dGFyaXF0QG52aWRpYS5jb20+OyBNYXJrIEJs b2NoIDxtYmxvY2hAbnZpZGlhLmNvbT47IExlb24gUm9tYW5vdnNreQ0KPiA8bGVvbkBrZXJuZWwu b3JnPjsgSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPjsgU3RlZmFubyBTdGFiZWxsaW5p DQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgT2xla3NhbmRyIFR5c2hjaGVua28NCj4gPG9s ZWtzYW5kcl90eXNoY2hlbmtvQGVwYW0uY29tPjsgTmd1eWVuLCBBbnRob255IEwNCj4gPGFudGhv bnkubC5uZ3V5ZW5AaW50ZWwuY29tPjsgS2l0c3plbCwgUHJ6ZW15c2xhdw0KPiA8cHJ6ZW15c2xh dy5raXRzemVsQGludGVsLmNvbT47IE1hbmlzaCBDaG9wcmEgPG1hbmlzaGNAbWFydmVsbC5jb20+ Ow0KPiBSYWh1bCBWZXJtYSA8cmFodWx2QG1hcnZlbGwuY29tPjsgR1ItTGludXgtTklDLURldkBt YXJ2ZWxsLmNvbTsgU2hhaGVkDQo+IFNoYWlraCA8c2hzaGFpa2hAbWFydmVsbC5jb20+OyBTaW1v biBIb3JtYW4gPGhvcm1zQGtlcm5lbC5vcmc+Ow0KPiBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBs aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gcmRtYUB2Z2VyLmtlcm5lbC5v cmc7IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsgaW50ZWwtd2lyZWQtDQo+IGxhbkBs aXN0cy5vc3Vvc2wub3JnOyBKb3NlZiBCYWNpayA8am9zZWZAdG94aWNwYW5kYS5jb20+DQo+IFN1 YmplY3Q6IFtQQVRDSCBuZXQtbmV4dCB2MiAwOS8xMF0gcWxjbmljOiB1c2UgcHNrYl9tYXlfcHVs bCgpIHRvIHB1bGwNCj4gZXhjZXNzIFRYIGZyYWdzIGludG8gdGhlIGhlYWQNCj4gDQo+IHFsY25p Y194bWl0X2ZyYW1lKCkgcHVsbHMgdGhlIGZyYWdzIHRoYXQgZG9uJ3QgZml0IGluIGEgVFggZGVz Y3JpcHRvcg0KPiBpbnRvIHRoZSBoZWFkIHdpdGggX19wc2tiX3B1bGxfdGFpbCgpLiAgSXQgYWxy ZWFkeSBjaGVja3MgdGhlIHJlc3VsdC4NCj4gU3dpdGNoIHRvIHBza2JfbWF5X3B1bGwoKSwgd2hp Y2ggdGFrZXMgdGhlIGxlbmd0aCB0aGUgaGVhZCBzaG91bGQgZW5kIHVwDQo+IHdpdGggYW5kIGNo ZWNrcyBpdCBhZ2FpbnN0IHRoZSBza2IsIHNvIHRoaXMgZHJpdmVyIG5vIGxvbmdlciBjYWxscw0K PiBfX3Bza2JfcHVsbF90YWlsKCkgZGlyZWN0bHkuDQo+IA0KPiBfX3Bza2JfcHVsbF90YWlsKCkg YWxzbyByZWxlYXNlcyBlbXB0eSBmcmFncywgZXZlbiB3aGVuIHRoZXJlJ3Mgbm90aGluZw0KPiB0 byBwdWxsLCBzbyBpZiB0aGUgZnJhZ3MgYmVpbmcgcHVsbGVkIGFyZSBhbGwgZW1wdHkgaXQgc3Rp bGwgZ2V0cyB0aGUNCj4gZnJhZyBjb3VudCB1bmRlciB0aGUgbGltaXQuICBwc2tiX21heV9wdWxs KCkgcmV0dXJucyBlYXJseSBpbiB0aGF0IGNhc2UsDQo+IHNvIGZvbGxvdyBpdCB3aXRoIHNrYl9k cm9wX2VtcHR5X2ZyYWdzKCkuDQo+IA0KPiBBc3Npc3RlZC1ieTogTExNDQo+IFNpZ25lZC1vZmYt Ynk6IEpvc2VmIEJhY2lrIDxqb3NlZkB0b3hpY3BhbmRhLmNvbT4NCj4gLS0tDQo+ICBkcml2ZXJz L25ldC9ldGhlcm5ldC9xbG9naWMvcWxjbmljL3FsY25pY19pby5jIHwgMyArKy0NCj4gIDEgZmls ZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gDQo+IGRpZmYgLS1n aXQgYS9kcml2ZXJzL25ldC9ldGhlcm5ldC9xbG9naWMvcWxjbmljL3FsY25pY19pby5jDQo+IGIv ZHJpdmVycy9uZXQvZXRoZXJuZXQvcWxvZ2ljL3FsY25pYy9xbGNuaWNfaW8uYw0KPiBpbmRleCA3 NjFlZjNiYzgxOTMuLmU3YWI1NTg2Nzk4YiAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy9uZXQvZXRo ZXJuZXQvcWxvZ2ljL3FsY25pYy9xbGNuaWNfaW8uYw0KPiArKysgYi9kcml2ZXJzL25ldC9ldGhl cm5ldC9xbG9naWMvcWxjbmljL3FsY25pY19pby5jDQo+IEBAIC02ODIsNyArNjgyLDggQEAgbmV0 ZGV2X3R4X3QgcWxjbmljX3htaXRfZnJhbWUoc3RydWN0IHNrX2J1ZmYgKnNrYiwNCj4gc3RydWN0 IG5ldF9kZXZpY2UgKm5ldGRldikNCj4gIAkJZm9yIChpID0gMDsgaSA8IChmcmFnX2NvdW50IC0g UUxDTklDX01BWF9GUkFHU19QRVJfVFgpOw0KPiBpKyspDQo+ICAJCQlkZWx0YSArPSBza2JfZnJh Z19zaXplKCZza2Jfc2hpbmZvKHNrYiktPmZyYWdzW2ldKTsNCj4gDQo+IC0JCWlmICghX19wc2ti X3B1bGxfdGFpbChza2IsIGRlbHRhKSkNCj4gKwkJaWYgKCFwc2tiX21heV9wdWxsKHNrYiwgc2ti X2hlYWRsZW4oc2tiKSArIGRlbHRhKSB8fA0KPiArCQkgICAgc2tiX2Ryb3BfZW1wdHlfZnJhZ3Mo c2tiLCBHRlBfQVRPTUlDKSkNCj4gIAkJCWdvdG8gZHJvcF9wYWNrZXQ7DQo+IA0KPiAgCQlmcmFn X2NvdW50ID0gMSArIHNrYl9zaGluZm8oc2tiKS0+bnJfZnJhZ3M7DQo+IA0KPiAtLQ0KPiAyLjU1 LjANCg0KUmV2aWV3ZWQtYnk6IEFsZWtzYW5kciBMb2t0aW9ub3YgPGFsZWtzYW5kci5sb2t0aW9u b3ZAaW50ZWwuY29tPg0K From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:02:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:02:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448718.1665749 (Exim 4.92) (envelope-from ) id 1xHK9o-0002O2-Os; Thu, 15 Oct 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 1448718.1665749; Thu, 15 Oct 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 1xHK9o-0002Ma-It; Thu, 15 Oct 2026 12:02:00 +0000 Received: by outflank-mailman (input) for mailman id 1448718; Wed, 14 Oct 2026 10:45:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGwU9-0004rq-QY for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 10:45:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGwU9-004CRl-7H for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:45:25 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf5d45-8faa-0a2a0a5109dd-0a2a450ad736-0 for ; Wed, 14 Oct 2026 12:45:25 +0200 Received: from [198.175.65.9] (helo=mgamail.intel.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf5d43-f2d2-0a2a450a0019-c6af4109b23c-3 for ; Wed, 14 Oct 2026 12:45:24 +0200 Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:45:22 -0700 Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2026 03:45:22 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) 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.49; Wed, 14 Oct 2026 03:45:21 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49 via Frontend Transport; Wed, 14 Oct 2026 03:45:21 -0700 Received: from BYAPR05CU005.outbound.protection.outlook.com (52.101.85.61) by edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 14 Oct 2026 03:45:21 -0700 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com (2603:10b6:f:fc02::31) by CY8PR11MB7363.namprd11.prod.outlook.com (2603:10b6:930:86::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Wed, 14 Oct 2026 10:45:13 +0000 Received: from DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f]) by DS4PPF7551E6552.namprd11.prod.outlook.com ([fe80::ac6c:1d96:c766:799f%5]) with mapi id 15.21.0522.012; Wed, 14 Oct 2026 10:45: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=Intel header.d=intel.com header.i="@intel.com" header.h="From:To:CC:Subject:Date:Message-ID:References: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=1791974725; x=1823510725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xop0M7r0e7P0bfukbeIAWui74GztOvG6zi8Sln6twnI=; b=P8+9H31zK/K+5iqW2UD/4b1nbz7C8yI/34+Y/QvsSBcUpVHEyf+wOic8 icXnn3Vbe2DR+49ZO7Z6V3Uk3jQeT9LocFYAaAYLwppJBaxLalCQeHwSE qMUMR2hlLL0W+grS4irGwqIk6y2GzxyEiMBYs/h07fV0O260RABhLe7dn cTn6LJNFyoeLubxQ+wwkYHXDIuTAJ4jCi5dk5a1ZeSx7W8e7x+QA3xbEu BwCCs9ZpIudgPkQn/MbG9lL+k3QH53PUqrjpTHk+XSHchnb4aEnSmrcXZ fMgb8A+Jh172EOibeT6FH+8TfrxHkkf4AF+0WcpQkUWSzrVtYIF6s0TRV w==; X-CSE-ConnectionGUID: VDB9Hy/ES6CAYIZwuJdiPQ== X-CSE-MsgGUID: HI7SWWWvTJ6q/QbuhJ+1Eg== X-IronPort-AV: E=McAfee;i="6800,10657,11934"; a="604350" X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="604350" X-CSE-ConnectionGUID: aXLIELklT2WMPbhKrv+xAA== X-CSE-MsgGUID: u71+VqHhS5OFrh3BzxjRCg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,157,1787036400"; d="scan'208";a="1721891" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JuKLSMKKBVAx8mDfl4Izf7QVwNyhiylTSKoEmB7/NOyQ1bY9BLSfMTwtyJvDGHo9a6pshdUJWNOA2kvbwZo079xjhZduT8DKpFNd9dRmVW4yjakZJZY7aDSQmYgfIUxANH600XkTKMInBPLjRPA7mgDYF3ihPxo2rkeZR7hMV0irbkp5THsl8A1q3TlSiTm+MYtosOsvyd+ZTojE5hy0yTXfiGQFwRElmEaBdxh8GPimffso6WtkanKUrqKdjLubKWIgQ6lUIHxr05Qi5THZqXI+nfj3DXEnQKpM3YassxLvhMq7b664jyWlDsF3lyO+WZVDVDBz7Y5JOgy/0Y6lQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xop0M7r0e7P0bfukbeIAWui74GztOvG6zi8Sln6twnI=; b=QaPFFj+iGpQUPoXgATw9WGVwAmA5sxow2l2H5ZjUc8aALWAXVO6yqs/GmPEn5+md82MGT6LOTGnBYvh3GLFu4OFj4CbZMQ2cMgxJ6pr24wDiKIJZ8OOR6jgIh90tH9AZkXAtEXU7/vbsTyTJJ0nh36KHpMZU5hPj+CNk2NIA+CBW5RUF9AlsTq8iGFJbaibBlitINbGLSt0l/V/fAqSSBYWmmaRx08n5jDS8DH3+0XYIyY695Yo8EYezsLpXpA54IlG0nG6H3rYXxehsK8Wb34L9cG0vNftvtAl+L+6znv7pG89ymNOwTQ3vl2vQ1AFszvPX1jG3XiB9aWEk2eLj7A== 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 From: "Loktionov, Aleksandr" To: Josef Bacik , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn CC: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , "Juergen Gross" , Stefano Stabellini , Oleksandr Tyshchenko , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , Manish Chopra , "Rahul Verma" , "GR-Linux-NIC-Dev@marvell.com" , Shahed Shaikh , "Simon Horman" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "intel-wired-lan@lists.osuosl.org" Subject: RE: [PATCH net-next v2 03/10] net/mlx5e: check for failure when pulling the Ethernet header after XDP Thread-Topic: [PATCH net-next v2 03/10] net/mlx5e: check for failure when pulling the Ethernet header after XDP Thread-Index: AQHdV2iJatk7MKYekE2967GwUxR+Erb841iA Date: Wed, 14 Oct 2026 10:45:13 +0000 Message-ID: References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008-b4-pskb-pull-tail-drivers-v2-3-8f2bd9bee138@toxicpanda.com> In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-3-8f2bd9bee138@toxicpanda.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=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS4PPF7551E6552:EE_|CY8PR11MB7363:EE_ x-ms-office365-filtering-correlation-id: 6ea6007a-f369-45f6-2bdf-08df29e03a0a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014|23010399003|22082099003|10067099003|38070700021|56012099006|18002099003|261009223027099003|11063799006|4143699003; x-microsoft-antispam-message-info: MvP/bmtNWmYmVAGFdbjUdaCERwu3f3YCcAvBiU0rPBca3omrn37OlslQBpscqbMX7KRvXGjC43Xub6BXT0KtN3OuHW+AM9++ZDvgJjohSPtDSd3aU9WXB9/vW4W9vE9miAB8v0QlqfPlrefy09A01xF2d+QRSrXNECeTMwYYTilnP0rYRCtp5KzB+VxOjmxSBB5TutW1FFoeh4/4MFeOf2gz3SxgV6J/bGrTMGTBVuJ0PnVIJVR8tMxY0mm7y4eAiyjCDfhU+5tvTajMY9WsQJoyx3kFg0dN/kTYLnffKYYTe6V+s67saE9UklbpbONqSYEO4Xn7uUbHwVcQb0/WEf/diNSHvs8udmM22THepguASZBU1znn100CC2bRK/fTvBaWFRrO4PxY0V2PQJhs/YcOYrI/dB2MEwIxIUU1bpIo0VAW9POn3akrqZuJkcuaxVoJ5tqy/zDrmfrQTmw9zehW5ZMNZG4uQ4rSovHuGNWIlVtf1oGlxD/rkQk0Oho+Xi/hQUgPx71stTZN68OHGARPPLXsjyqFMFiM8wrX0xlzoD6J0jF53HcIMk3Dv5rfUqYgZghzDFWFCqw++9R/NPj2icjSF+IXhYeRlnKdBN7lkQxuNYb5qkc3h9KccNc0w6YMp5ztDRoBgeyPlgI99cJGMBYEW7bUX8gDlu0dUGlgQg/SaRuRPodD8ZZTOoChnmmA5v4JGwhZvhRiU3+rRDh3PF+2HL3KOQe7POL2IDI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS4PPF7551E6552.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(23010399003)(22082099003)(10067099003)(38070700021)(56012099006)(18002099003)(261009223027099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bnpuaHdBRDNqeVlXazgzQzV5c1FwNm9BSGZaRUtmb3hRRFIxQmZzVFJ6emlT?= =?utf-8?B?ZXBnY3IzUnVSRjllZ3A4WmUwdEFBcEJmY3pHc3FDSU94WG4wRnJLNk0xb1pk?= =?utf-8?B?MCtsWHRVNHdRM2xkeVlscUN0dU5UdEkzUGhRM0ppV3M2K1ZyVU9NQmZGNnBR?= =?utf-8?B?bEYzMWMySXZOamRhZVBvMlhuVjVIbHRMQ0ZTNVVFSmlKRzY5TkphcWVGNnVK?= =?utf-8?B?K1BzREszcCsxdktIakw3SEpyMS83aGJZUTF6YitSVFVlYlJ5UVBWSE1Td3pZ?= =?utf-8?B?dVhneGNWQmVRSTV1bEp6VWRpcnZ1c24wc3dCcFpScWt3aUpiSWhNbk1SY0cr?= =?utf-8?B?WWs4TEcvYjc0VmVVakFmUkNXaDRSLzZzWkRTL0N6ZVRPeStiR1JSWlNTV0k2?= =?utf-8?B?Q2lzR2M4SnQxR0xLalpZQ3Q4RjVxVlBMMHQ0L2duOTFPRHpYNk5hVDc3YUNp?= =?utf-8?B?Y1F5Qm1ORkdneHovbTBPL3NzbEFqUnlmUWVKeDYxU3dqN241Tk51S25YcWtF?= =?utf-8?B?cnRBem5EMDZPOW9hck5wSENaRUgwa1I1YXhrVHdzcndvdFJZTzJsaGNqeTNR?= =?utf-8?B?Q3FYRFQ2NXJiUnlQcG4yUkFzUkdqRldTZzFzUkVqQnNycS9aaVpvazFxdEd0?= =?utf-8?B?akN6cVVHQnhvbFZvUytIamZpd2FONXFnRW83cWFObjI4dFRLbHF6emkzOWxL?= =?utf-8?B?eStyaTg5RFFsem9OSTM0V1FqdGVzVjljeTRoUWUzbkxLOTdqNUJQMmEyQ1JJ?= =?utf-8?B?Y0VUb0d1OU9HdVRHOXVXMHBrZ3Y4d0xJTXZJV2dJQWl1cUIvMGN0WUUxUitt?= =?utf-8?B?MkVleGdncTRFcytrL3RtMWwxWC9ZMFdiUmNycWdHL2d3cytRNEI3cHBCVmdi?= =?utf-8?B?S1lsY2tnYmFvVHVSYWVGb1kxclFJUUFabDBBMi9vSm1nNmwrZnFaUG5Uait5?= =?utf-8?B?YnZOSVBIYUNsZlVNVStsQUtNVmEzWGJjU3crNmVGMHdEbmpWeGEvQW5DU1JF?= =?utf-8?B?Ykk0WlBpT05FK3c2azJaWHlqTW1qOHVlUVNGZ0NEQmRqTU5teUpnRWtWYVYv?= =?utf-8?B?aWxuWDg5QTNJQ2FPY3lSTnp2UzdsdFlWT3F1NmpFY0kraHVFQ2JDQkdjYUR1?= =?utf-8?B?ZmJDcDE2WjNHUVhIZjR0aVY4MHJlQXkyZm1BclRzMjVIdXhUWWFqMWNBcHFK?= =?utf-8?B?NndjS3ByTU1MQVptYnhVaVFDd0xZank4blB5L0JqQ1lFT0grMk92UHhKY0pQ?= =?utf-8?B?VG5mNHdmSTR0WXRESGdnd2lnL0FSa25wTWxOUURZQmdyMWFiMFB4eFNkZHJw?= =?utf-8?B?Zi9xWUo5alNLTWFJdHpRQ3dvRVZJOXpNQTR1M0NUMTNRTitGN1dTWURPWitC?= =?utf-8?B?N2RGeTNZN1dvTkh4Z2k2aUZnTTVFeE5GdmF0d2JHV2Fab1hsak9JdHNTZ2Qy?= =?utf-8?B?SHh3VnptVzAvbjQrV2tOc3NtMHdBTUloVFJMMHhBRXdScjVWSTU0d0w0em5U?= =?utf-8?B?TTRFb1g0Wk8zUFhnM1psaUcrUmplNjFGbXo2elQxVXM3dTQ1QXhxRVJHM1Vs?= =?utf-8?B?OWRVL3VzRjRKTWx3VDNDNnVqaW9JUUVZTEU3cDdDQnJmcURzVmJCV0FQMkZE?= =?utf-8?B?K0hIKzlDOFlPQ09QMFJqSzFEWVk2K2VaT3NBTXZJYVpRbTkwV3NnWFpKV1NY?= =?utf-8?B?NlJkRTVIdG1VcGF5azNSMmRyMkN6RUhXdEgxOWJyWTBwUEZKQlJlRVJMYTRw?= =?utf-8?B?UDBiVlVhQ2dxSnMvMll5TGd2bjcyL043d0I5akF2Z2Q0QzI0U1MzNkxBeERM?= =?utf-8?B?NGd1SnEvWXZFbjJLT2dpUlZyeWY4V3g5UWZlVmFJYW1ocEIzdEJvM3hlWnhS?= =?utf-8?B?N0pVUVJVOXBkLys3Tm1keGM1MStVeUlaZldUU1dYVmZGaWxkU1VzWU8wbkhy?= =?utf-8?B?RCtIWkVFb3RMaldlblMwdmttUGs1Unhwa2xaclZHSWVXVUtlRVBDbU56dDIv?= =?utf-8?B?MDIyQ1gxRnNpQlF6blJ3aS83a3pKTTdPbThwZEV0QksvYk9KZFRNK2JyeHhq?= =?utf-8?B?V0ZUTTJZeis3OUptSkgxR1RYU2dpMlNyS3BaUFdhMEx2NWJvaFhhOW1QcUhW?= =?utf-8?B?RXo4MGJ0MVRUb3RDLzFJOGtnVE1KaGRabnRSNjBnaFVFOGdmaUxHWTNDYnA2?= =?utf-8?B?Z214NTZQWHIxbWhPaVFnN1lXa3JVV05MSHRTbnRXSzRhTEk3K2Z2ZW9HN3o1?= =?utf-8?B?a1JoOXZmNW1IUkRhV0JxUFNDd1F2U3RJa0gyQ0ltVjAxZnk5QVBwcGVZTU5X?= =?utf-8?B?cVRYb2IwNFhtMlNSZzlRUWdXb1ovMHdVblFkSHAxV1A4em1qc0duc3d2Q0sx?= =?utf-8?Q?L9VIaqPFG4HLo5xQ=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: UJ8fYqezKewW5D/7VkcJDAWFUMT1U1VEFuRGGwW57VccFdQR7xcALoqjoJ9/dxQrhlKpz6yLgJjM29qkuJYDMVpGXzjp3txw+j5KDrdnTPJhK/+6ESb1m7NgyklBijvYWnSz2+JNNwQ7FGSTyS417V71afvrcrrsEgQYjLlZ0qlNvjIIl/xkTZoTz9aTI9vZDgas1JYeOhm9YETf65PqCmj9C2/RlMx7yPjEUgOskb+68AKs/2WU0032rXFa+t9VFisQMMjLCmE+GaMn9dHlqFzUVNZxA9PoG50SGZarvXKd48leUyjuGoU2N7drKbcJq0pf7r+TYB4k/I+4lxK3Og== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS4PPF7551E6552.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ea6007a-f369-45f6-2bdf-08df29e03a0a X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2026 10:45:13.2579 (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: oNIdGqgzq7rQGT/KiUWclkMcIQ+I/Yh+XCNgVkK6kG6nQfLE1fwqP6IA/DYA/WxpH2Lc5V+hXwwGDVzV+1acKf46IJ5//4+hK4ydOwHZ4U0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7363 X-OriginatorOrg: intel.com X-purgate-ID: tlsNG-4011c0/1791974725-510C9CFC-BEF11AF8/0/0 X-purgate-type: clean X-purgate-size: 3884 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9zZWYgQmFjaWsgPGpv c2VmQHRveGljcGFuZGEuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciA4LCAyMDI2IDEx OjAzIFBNDQo+IFRvOiBKYWt1YiBLaWNpbnNraSA8a3ViYUBrZXJuZWwub3JnPjsgUGFvbG8gQWJl bmkgPHBhYmVuaUByZWRoYXQuY29tPjsNCj4gRXJpYyBEdW1hemV0IDxlZHVtYXpldEBrZXJuZWwu b3JnPjsgRGF2aWQgUy4gTWlsbGVyDQo+IDxkYXZlbUBkYXZlbWxvZnQubmV0PjsgQW5kcmV3IEx1 bm4gPGFuZHJldytuZXRkZXZAbHVubi5jaD4NCj4gQ2M6IFNhZWVkIE1haGFtZWVkIDxzYWVlZG1A bnZpZGlhLmNvbT47IFRhcmlxIFRvdWthbg0KPiA8dGFyaXF0QG52aWRpYS5jb20+OyBNYXJrIEJs b2NoIDxtYmxvY2hAbnZpZGlhLmNvbT47IExlb24gUm9tYW5vdnNreQ0KPiA8bGVvbkBrZXJuZWwu b3JnPjsgSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPjsgU3RlZmFubyBTdGFiZWxsaW5p DQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgT2xla3NhbmRyIFR5c2hjaGVua28NCj4gPG9s ZWtzYW5kcl90eXNoY2hlbmtvQGVwYW0uY29tPjsgTmd1eWVuLCBBbnRob255IEwNCj4gPGFudGhv bnkubC5uZ3V5ZW5AaW50ZWwuY29tPjsgS2l0c3plbCwgUHJ6ZW15c2xhdw0KPiA8cHJ6ZW15c2xh dy5raXRzemVsQGludGVsLmNvbT47IE1hbmlzaCBDaG9wcmEgPG1hbmlzaGNAbWFydmVsbC5jb20+ Ow0KPiBSYWh1bCBWZXJtYSA8cmFodWx2QG1hcnZlbGwuY29tPjsgR1ItTGludXgtTklDLURldkBt YXJ2ZWxsLmNvbTsgU2hhaGVkDQo+IFNoYWlraCA8c2hzaGFpa2hAbWFydmVsbC5jb20+OyBTaW1v biBIb3JtYW4gPGhvcm1zQGtlcm5lbC5vcmc+Ow0KPiBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBs aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gcmRtYUB2Z2VyLmtlcm5lbC5v cmc7IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsgaW50ZWwtd2lyZWQtDQo+IGxhbkBs aXN0cy5vc3Vvc2wub3JnOyBKb3NlZiBCYWNpayA8am9zZWZAdG94aWNwYW5kYS5jb20+DQo+IFN1 YmplY3Q6IFtQQVRDSCBuZXQtbmV4dCB2MiAwMy8xMF0gbmV0L21seDVlOiBjaGVjayBmb3IgZmFp bHVyZSB3aGVuDQo+IHB1bGxpbmcgdGhlIEV0aGVybmV0IGhlYWRlciBhZnRlciBYRFANCj4gDQo+ IFdoZW4gYW4gWERQIHByb2dyYW0gbGVhdmVzIGxlc3MgdGhhbiBFVEhfSExFTiBpbiB0aGUgbGlu ZWFyIHBhcnQgb2YgYQ0KPiBtdWx0aS1idWZmZXIgcGFja2V0LCBtbHg1ZV9za2JfZnJvbV9jcWVf bXB3cnFfbm9ubGluZWFyKCkgcHVsbHMgdGhlIHJlc3QNCj4gb2YgdGhlIEV0aGVybmV0IGhlYWRl ciBpbiBmcm9tIHRoZSBmcmFncyB3aXRoIF9fcHNrYl9wdWxsX3RhaWwoKSBhbmQNCj4gaWdub3Jl cyB0aGUgcmV0dXJuIHZhbHVlLiAgSWYgdGhhdCBwdWxsIGZhaWxzLCBldGhfdHlwZV90cmFucygp IGxhdGVyDQo+IGZpbmRzIGxlc3MgdGhhbiBFVEhfSExFTiBpbiB0aGUgaGVhZCBhbmQgQlVHKClz IGluIF9fc2tiX3B1bGwoKS4NCj4gDQo+IFVzZSBwc2tiX21heV9wdWxsKCkgaW5zdGVhZCBhbmQg ZHJvcCB0aGUgcGFja2V0IGlmIGl0IGZhaWxzLiAgUHVsbGluZw0KPiBtaW4oRVRIX0hMRU4sIHNr Yi0+bGVuKSBrZWVwcyB0b2RheSdzIGJlaGF2aW91ciBmb3IgYSBmcmFtZSBzaG9ydGVyIHRoYW4N Cj4gYW4gRXRoZXJuZXQgaGVhZGVyLg0KPiANCj4gQXNzaXN0ZWQtYnk6IExMTQ0KPiBTaWduZWQt b2ZmLWJ5OiBKb3NlZiBCYWNpayA8am9zZWZAdG94aWNwYW5kYS5jb20+DQo+IC0tLQ0KPiAgZHJp dmVycy9uZXQvZXRoZXJuZXQvbWVsbGFub3gvbWx4NS9jb3JlL2VuX3J4LmMgfCA5ICsrKysrKy0t LQ0KPiAgMSBmaWxlIGNoYW5nZWQsIDYgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkNCj4g DQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC9ldGhlcm5ldC9tZWxsYW5veC9tbHg1L2NvcmUv ZW5fcnguYw0KPiBiL2RyaXZlcnMvbmV0L2V0aGVybmV0L21lbGxhbm94L21seDUvY29yZS9lbl9y eC5jDQo+IGluZGV4IGUzZjkxNWJlZWJlMS4uYjFlMWUzMGE3N2UyIDEwMDY0NA0KPiAtLS0gYS9k cml2ZXJzL25ldC9ldGhlcm5ldC9tZWxsYW5veC9tbHg1L2NvcmUvZW5fcnguYw0KPiArKysgYi9k cml2ZXJzL25ldC9ldGhlcm5ldC9tZWxsYW5veC9tbHg1L2NvcmUvZW5fcnguYw0KPiBAQCAtMjA2 MCw5ICsyMDYwLDEyIEBAIG1seDVlX3NrYl9mcm9tX2NxZV9tcHdycV9ub25saW5lYXIoc3RydWN0 DQo+IG1seDVlX3JxICpycSwgc3RydWN0IG1seDVlX21wd19pbmZvICp3DQo+ICAJCQkJcGFnZXAt PmZyYWdzKys7DQo+ICAJCQl3aGlsZSAoKytwYWdlcCA8IGZyYWdfcGFnZSk7DQo+IA0KPiAtCQkJ aWYgKGxlbiA8IEVUSF9ITEVOKQ0KPiAtCQkJCV9fcHNrYl9wdWxsX3RhaWwoc2tiLCBtaW4oRVRI X0hMRU4gLSBsZW4sDQo+IC0JCQkJCQkJICBza2ItPmRhdGFfbGVuKSk7DQo+ICsJCQlpZiAobGVu IDwgRVRIX0hMRU4gJiYNCj4gKwkJCSAgICAhcHNrYl9tYXlfcHVsbChza2IsIG1pbihFVEhfSExF Tiwgc2tiLT5sZW4pKSkgew0KPiArCQkJCXJxLT5zdGF0cy0+YnVmZl9hbGxvY19lcnIrKzsNCj4g KwkJCQlkZXZfa2ZyZWVfc2tiX2FueShza2IpOw0KPiArCQkJCXJldHVybiBOVUxMOw0KPiArCQkJ fQ0KPiAgCQl9DQo+ICAJfSBlbHNlIHsNCj4gIAkJaWYgKHhkcF9idWZmX2hhc19mcmFncygmbXhi dWYtPnhkcCkpIHsNCj4gDQo+IC0tDQo+IDIuNTUuMA0KDQpSZXZpZXdlZC1ieTogQWxla3NhbmRy IExva3Rpb25vdiA8YWxla3NhbmRyLmxva3Rpb25vdkBpbnRlbC5jb20+DQo= From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:05:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:05:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448223.1665776 (Exim 4.92) (envelope-from ) id 1xHKDB-0004lw-Sr; Thu, 15 Oct 2026 12:05:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448223.1665776; Thu, 15 Oct 2026 12: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 1xHKDB-0004lp-PO; Thu, 15 Oct 2026 12:05:29 +0000 Received: by outflank-mailman (input) for mailman id 1448223; Tue, 13 Oct 2026 17:07:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGfyk-0007oC-2e for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 17:07:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGfyj-0017vm-CA for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 19:07:53 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace6567-8faa-0a2a0a5109dd-0a2a450cc76a-2 for ; Tue, 13 Oct 2026 19:07:53 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace6569-f479-0a2a450c0019-d1558029a499-3 for ; Tue, 13 Oct 2026 19:07:53 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a16c1608faso42045415e9.0 for ; Tue, 13 Oct 2026 10:07:53 -0700 (PDT) Received: from dev1.kernelcare.com ([2a01:4f8:172:1c85::2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a18bf1358asm379560935e9.4.2026.10.13.10.07.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2026 10:07: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=1791911273; x=1792516073; 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=gdq9VK8+Wh/mRy8KAkG8P/JTclrVTJdKPo9KBX5A3pI=; b=D76U0i41H62299wG7npSPjboQ6X5gP4mCdrBeupBCebOvi+OslYK/j39BJgTTPstBu hv2+CjXgFL5bv04GVk5aPzb+2kUEXay0Zd1Nbj2+g0qcPjiNNCMfrs3FsNMSKOMcuhcW 3g0z1XyNisxtD5Uni+8hqieud+AwAWwJo0xxCQl/g9ZUWlZfRQAPKdcG4OXB+ng+pAlL vAOhar71yYiSCCzqGHLfA2NWQE41xEX6HU7LLEkP1FRxzNnRwO79g/PxW4WXarQOmegJ plLhWgKqbHjtvzhaHPw0kJNlGg5+CGv4j1zQXSsGBd5QoZb9iEsKGd0afr6/WLMkakNK 5CzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791911273; x=1792516073; 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=gdq9VK8+Wh/mRy8KAkG8P/JTclrVTJdKPo9KBX5A3pI=; b=kYf1tRsRdTUu12zfp2HVrN5UmnfA9GUdutFgd97mHIZM4EINiAkBKBNP+hW/KHlmO/ yWCNnT3pBLksoS6VhcuD1Jb8LWD24Lx2W0hqjcMW+zU+HDPzSJxko3gHRy4wg5TV5hRX e+ks5CIQ87CCGiyL7p9AJ74tEDddyt2txW0QNGzfXC2eafR0zc+StfejX/4YlS6iS5oB Iy8W4AbrTbXzkZJxsp/FUh3yqwgogRAtYly3J21qQsaI6VIYADugEG/MZUbPsz76Xfs/ D1j4z/s3HNF+SIFU/A/wfU7SMSNecQeloQtywlTOH850RTTwl9w7+0lNmBkODVlnnxbY PY8A== X-Forwarded-Encrypted: i=1; AKwUvBzTtxNU0aa6Dd86X8jfF3JMW95vOLnM68SBTmhXJFA1jomMddKgHxo0sRm5SwzTPkd1tcuGIzWR0lY=@lists.xenproject.org X-Gm-Message-State: AFq9FYL7oHyykX0f/f9RG4J7r+okA1JzzOYbnIU4zR6JlSP6kGBSVU+z 9dzGwo4kmggWFV6nG4VxhtLFcQJp2YTHKysBaCp0XDOEhVy69QgslikJ X-Gm-Gg: AYBFou0VhvDDmaczylcwBScLV72WjJwikQxleGMFdBdmiZKBHzOn8tRkrUdUmChcKVh Hn3X9I6p/SXC6cYutdwogHclss71hxn655NL/sUXdSCSEFlC/I14cHOhjGoT4aWtZh0/Ow3nkaA 6URIo+zp+SiQudeVwQoZkuOjqV7Tc6LpcJ+mIhoZQ+YDoRUCLCROdiWWI45HZiNA7HbrDHu4CZk Q6HqhpHIf99e7eSYm1bWmPnPiCkmL1WALr63LAYjqjerhjwPIzAGT2zgNLUov/uht3wsUxgNe2C xqFg9/ruuGeL7So4FIB12NhBwAwA705fc2xSQqhtAR+/hXU2JqA+aZGDYRE3FyMI1ryUQHRuXcI EPfKFppQ64n2jQI/TdGnKXShH0xU9KllPJCfwPRXmHkKb9dKCb0HiNeG/Ws4RgRp1hlHXd9FO2P BLGZTm/dOqFdrVF7OoEumhcVgbzpylp/PkYWqbC8OTKj936ImiXQbHBpujDgMRv/jZcQ== X-Received: by 2002:a05:600c:3512:b0:49f:c5aa:9ef4 with SMTP id 5b1f17b1804b1-4a18e4913c3mr228195185e9.8.1791911272543; Tue, 13 Oct 2026 10:07:52 -0700 (PDT) From: Andrey Misiurov To: Juergen Gross , Stefano Stabellini Cc: Oleksandr Tyshchenko , Wentao Liang , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Andrey Misiurov , stable@vger.kernel.org Subject: [PATCH] xen/gntdev: fix deadlock between map ioctl and mmap Date: Tue, 13 Oct 2026 19:07:45 +0200 Message-ID: <20261013170745.583279-1-andrey.misyrov@gmail.com> X-Mailer: git-send-email 2.43.7 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1791911273-034D7A5B-9875DEDC/0/0 X-purgate-type: clean X-purgate-size: 2590 Commit 45ca1afe2fd1 ("xen/gntdev: fix error handling in ioctl") moved copy_to_user() in gntdev_ioctl_map_grant_ref() under priv->lock. A fault in copy_to_user() takes mmap_lock, while gntdev_mmap() is called with mmap_lock held and takes priv->lock: ioctl thread mmap thread mutex_lock(&priv->lock) mmap_write_lock(mm) gntdev_mmap() mutex_lock(&priv->lock) copy_to_user() faults mmap_read_lock(mm) Reproduced on Debian 6.12.111 in a Xen guest, with the ioctl argument on a MAP_PRIVATE file page that has not been written yet. sysrq-w: task:repro state:D stack:0 pid:4479 tgid:4477 ppid:1 flags:0x00000000 rwsem_down_read_slowpath+0x25c/0x480 down_read_killable+0x48/0xc0 lock_mm_and_find_vma+0x96/0x250 do_user_addr_fault+0x12d/0x620 exc_page_fault+0x7e/0x180 asm_exc_page_fault+0x26/0x30 _copy_to_user+0x36/0x50 gntdev_ioctl+0x3b9/0xa00 [xen_gntdev] __x64_sys_ioctl+0x97/0xc0 task:repro state:D stack:0 pid:4480 tgid:4477 ppid:1 flags:0x00000000 __mutex_lock.constprop.0+0x41b/0x720 gntdev_mmap+0x4d/0x330 [xen_gntdev] __mmap_region+0x697/0xb10 mmap_region+0x78/0xa0 do_mmap+0x45d/0x630 vm_mmap_pgoff+0xf8/0x1c0 Drop priv->lock before copy_to_user() again. On failure, re-take it and remove the map by index, as IOCTL_GNTDEV_UNMAP_GRANT_REF does, since another thread may have unmapped it meanwhile. Fixes: 45ca1afe2fd1 ("xen/gntdev: fix error handling in ioctl") Cc: stable@vger.kernel.org Signed-off-by: Andrey Misiurov --- drivers/xen/gntdev.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index b71f5ba..1ad0220 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -670,15 +670,19 @@ static long gntdev_ioctl_map_grant_ref(struct gntdev_priv *priv, mutex_lock(&priv->lock); gntdev_add_map(priv, map); op.index = map->index << PAGE_SHIFT; + mutex_unlock(&priv->lock); if (copy_to_user(u, &op, sizeof(op)) != 0) { - list_del(&map->next); + mutex_lock(&priv->lock); + map = gntdev_find_map_index(priv, op.index >> PAGE_SHIFT, + op.count); + if (map) + list_del(&map->next); mutex_unlock(&priv->lock); gntdev_put_map(priv, map); return -EFAULT; } - mutex_unlock(&priv->lock); return 0; } base-commit: 61b6d1df1d6234c38a6ea7e4f58e7da035ef6ab4 -- 2.43.7 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:05:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:05:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448856.1665783 (Exim 4.92) (envelope-from ) id 1xHKDC-0004oK-5n; Thu, 15 Oct 2026 12:05:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448856.1665783; Thu, 15 Oct 2026 12:05: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 1xHKDC-0004oB-0A; Thu, 15 Oct 2026 12:05:30 +0000 Received: by outflank-mailman (input) for mailman id 1448856; Wed, 14 Oct 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 1xGxW7-0007Jv-U6 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 11:51:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxW7-001D9Z-At for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 13:51:31 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf6cb5-bab6-0a2a0a5309dd-0a2a4505e6b2-28 for ; Wed, 14 Oct 2026 13:51:31 +0200 Received: from [113.46.200.220] (helo=canpmsgout05.his.huawei.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf6cbf-4cb1-0a2a45050019-712ec8dc37f4-3 for ; Wed, 14 Oct 2026 13:51:29 +0200 Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4j4Tkr1HPxz12LD9; Wed, 14 Oct 2026 19:39:32 +0800 (CST) Received: from whupemo200011.china.huawei.com (unknown [7.152.185.179]) by mail.maildlp.com (Postfix) with ESMTPS id 24D014056E; Wed, 14 Oct 2026 19:51:26 +0800 (CST) Received: from [10.174.178.46] (10.174.178.46) by whupemo200011.china.huawei.com (7.152.185.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 14 Oct 2026 19:51:21 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-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=huawei.com header.i="@huawei.com" header.h=From dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=xVlOyYaOJuVGaDfnk3Cn8S4up3VyrQrAPSaBBvMWJK4=; b=NRQ2Wyi38AJGPQbJ80NuIBLnWk6SwO8PaLyJaV87efjwedpEJ9wjoxegROCOJ8+sMuMWLGkWu Rm4/b05wv/F91TtAb5MycVTFxtVEUQvci6R9jyHnyeOMNTzXjiNJSTCZN3PILjcWfI1v2zeSqLV B62e3eM4uUujj0AqiqJDPNY= Subject: Re: [PATCH 09/11] ubifs: sysfs: Use kset_create_and_add() for ubifs_kset To: Ian Rogers , Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor CC: Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Felix Kuehling , Alex Deucher , =?UTF-8?Q?Christian_K=c3=b6nig?= , , , , , , , , , , , , , , , References: <20261013223946.1836757-1-irogers@google.com> <20261013223946.1836757-10-irogers@google.com> From: Zhihao Cheng Message-ID: <3f6e7a0d-ba41-89dd-012f-9ac24e12da9d@huawei.com> Date: Wed, 14 Oct 2026 19:51:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20261013223946.1836757-10-irogers@google.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.46] X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To whupemo200011.china.huawei.com (7.152.185.179) X-purgate-ID: tlsNG-c201ff/1791978691-720AA2A1-267BA6FF/0/0 X-purgate-type: clean X-purgate-size: 2265 在 2026/10/14 6:39, Ian Rogers 写道: > ubifs_kset was a static struct kset using a custom ubifs_ktype that > had no default_groups and no .release callback. With > CONFIG_DEBUG_KOBJECT_RELEASE=y, unloading the ubifs module while delayed > kobject release is pending causes a use-after-free on the static kset. > > Replace the static ubifs_kset and empty ubifs_ktype with a dynamically > allocated kset via kset_create_and_add(). > > Fixes: 203a55f04f66 ("ubifs: Fix memory leak in ubifs_sysfs_init()") > Assisted-by: Antigravity:gemini-3.1-pro > Signed-off-by: Ian Rogers > --- > fs/ubifs/sysfs.c | 24 +++++++----------------- > 1 file changed, 7 insertions(+), 17 deletions(-) > Tested-by: Zhihao Cheng Reviewed-by: Zhihao Cheng > diff --git a/fs/ubifs/sysfs.c b/fs/ubifs/sysfs.c > index dbf967dcf26e..e20931e3a62f 100644 > --- a/fs/ubifs/sysfs.c > +++ b/fs/ubifs/sysfs.c > @@ -80,13 +80,7 @@ static const struct kobj_type ubifs_sb_ktype = { > .release = ubifs_sb_release, > }; > > -static const struct kobj_type ubifs_ktype = { > - .sysfs_ops = &ubifs_attr_ops, > -}; > - > -static struct kset ubifs_kset = { > - .kobj = {.ktype = &ubifs_ktype}, > -}; > +static struct kset *ubifs_kset; > > int ubifs_sysfs_register(struct ubifs_info *c) > { > @@ -107,7 +101,7 @@ int ubifs_sysfs_register(struct ubifs_info *c) > goto out_free; > } > > - c->kobj.kset = &ubifs_kset; > + c->kobj.kset = ubifs_kset; > init_completion(&c->kobj_unregister); > > ret = kobject_init_and_add(&c->kobj, &ubifs_sb_ktype, NULL, > @@ -139,18 +133,14 @@ void ubifs_sysfs_unregister(struct ubifs_info *c) > > int __init ubifs_sysfs_init(void) > { > - int ret; > + ubifs_kset = kset_create_and_add("ubifs", NULL, fs_kobj); > + if (!ubifs_kset) > + return -ENOMEM; > > - kobject_set_name(&ubifs_kset.kobj, "ubifs"); > - ubifs_kset.kobj.parent = fs_kobj; > - ret = kset_register(&ubifs_kset); > - if (ret) > - kset_put(&ubifs_kset); > - > - return ret; > + return 0; > } > > void ubifs_sysfs_exit(void) > { > - kset_unregister(&ubifs_kset); > + kset_unregister(ubifs_kset); > } > From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:05:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:05:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448429.1665794 (Exim 4.92) (envelope-from ) id 1xHKDU-0005RG-Dx; Thu, 15 Oct 2026 12:05:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448429.1665794; Thu, 15 Oct 2026 12:05: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 1xHKDU-0005R7-AZ; Thu, 15 Oct 2026 12:05:48 +0000 Received: by outflank-mailman (input) for mailman id 1448429; Wed, 14 Oct 2026 03:57:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGq7Y-0002Xh-7O for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 03:57:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGq7W-002EyX-Vk for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 05:57:39 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acefd59-e002-0a2a0a5209dd-0a2a4509df06-46 for ; Wed, 14 Oct 2026 05:57:38 +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 6acefdb1-be1a-0a2a45090019-aceafc1fbad4-3 for ; Wed, 14 Oct 2026 05:57:38 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 6CF1043EF0; Wed, 14 Oct 2026 03:57:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C3921F000FF; Wed, 14 Oct 2026 03:57: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=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=1791950256; bh=krep95NG2pPtINDgFelqrvncws8jmsQoXCeuPVWJJuM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SRgdtL/aIJaMAoRljT8tn6ntILQarurAmsWGDk6qdkndvHoWveSoVAnB0UyvjQADm WCpQUGsTbogicljt6mcCEQXBnW7H+UHTB6B6pu5b2u/xkmpBsw4NUq9MJuHHExbCYS hHWM3DJjplFB+el/h/0+lpg/qAtGIVmZUYl0RYyhDuzQD3Io+ZquSOfKTth/unatkv o4miA5eS+IEsY8KBmM9Lg+PXnx7AfA+On4Gkvnf3J6DHgS0EHLp/dnJ0rr/Xdz/Gz7 JaDzfDRS8Ifx10c5Os5nWu5ggTAbh4EQoXW32fHCi5pcg3y8/5Ivm/u3t1tTv1qeHK PkS2yoZ2zQJ2g== From: "Martin K. Petersen (Oracle)" To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "James E.J. Bottomley" , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, "Martin K. Petersen" , Yehyeong Lee Cc: stable@vger.kernel.org Subject: Re: [PATCH] xen/scsifront: check for a NULL shadow entry on a backend response Date: Tue, 13 Oct 2026 23:57:26 -0400 Message-ID: <179194999395.3016381.7673052894147861823.b4-ty@b4> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261005123555.253995-1-yhlee@isslab.korea.ac.kr> References: <20261005123555.253995-1-yhlee@isslab.korea.ac.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1791950258-FD26A034-18FC21A5/0/0 X-purgate-type: clean X-purgate-size: 810 On Mon, 05 Oct 2026 21:35:54 +0900, Yehyeong Lee wrote: > scsifront_do_response() validates the rqid in a backend response against > VSCSIIF_MAX_REQS before using it to index info->shadow[], but then > dereferences the entry to test ->inflight without checking that the slot > is populated. Shadow slots are NULL before a command is submitted (the > host private area is zeroed at allocation) and are reset to NULL in > _scsifront_put_rqid() once a request completes, so an in-range rqid that > does not correspond to an outstanding request makes the frontend > dereference a NULL pointer. > > [...] Applied to 7.3/scsi-fixes, thanks! [1/1] xen/scsifront: check for a NULL shadow entry on a backend response https://git.kernel.org/mkp/scsi/c/8c8222c25577 -- Martin K. Petersen From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:05:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:05:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450302.1665800 (Exim 4.92) (envelope-from ) id 1xHKDU-0005UK-MP; Thu, 15 Oct 2026 12:05:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450302.1665800; Thu, 15 Oct 2026 12:05: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 1xHKDU-0005Tu-ID; Thu, 15 Oct 2026 12:05:48 +0000 Received: by outflank-mailman (input) for mailman id 1450302; Thu, 15 Oct 2026 11:54:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHK2e-0008SW-4O for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 11:54:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHK2d-002Icz-DN for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:54:35 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0bef6-2eae-0a2a0a5409dd-0a2a45078606-12 for ; Thu, 15 Oct 2026 13:54:34 +0200 Received: from [87.98.178.58] (helo=17.mo561.mail-out.ovh.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0befa-b4ea-0a2a45070019-5762b23aa18d-3 for ; Thu, 15 Oct 2026 13:54:34 +0200 Received: from director3.ghost.mail-out.ovh.net (unknown [10.110.58.129]) by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4j561k2PcVz60Qp for ; Thu, 15 Oct 2026 11:54:34 +0000 (UTC) Received: from ghost-submission-7ccd8bbbb6-5vnxl (unknown [10.111.174.161]) by director3.ghost.mail-out.ovh.net (Postfix) with ESMTPS id ED105C04CB; Thu, 15 Oct 2026 11:54:33 +0000 (UTC) Received: from msd.im ([37.59.142.103]) by ghost-submission-7ccd8bbbb6-5vnxl with ESMTPSA id I7lrKfm+0GqLRAAAi6cUng (envelope-from ); Thu, 15 Oct 2026 11:54:33 +0000 Received: from mail.msd.im (unknown [192.168.1.32]) (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 msd.im (Postfix) with ESMTPSA id BB7FB20088; Thu, 15 Oct 2026 13:54: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=msd001 header.d=msd.im header.i="@msd.im" header.h="Date:From:Subject:To:Cc" Authentication-Results:garm.ovh; auth=pass (GARM-103G00513f120ed-6eae-421a-bfcc-7fc479540065, 71189ECCCFDEC51F476E72D41DA47BE09842BDA6) smtp.auth=massedil@msd.im X-OVh-ClientIp:2.12.250.155 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=msd.im; s=msd001; t=1792065272; bh=fvv3/k0ooz9Ete/etMooXYP7y0WAKHQyPHKVMxH8oQY=; h=Date:From:Subject:To:Cc:From; b=JuE1SI/D2G1EZ4mYtLVLeX20O29Yiu5YrGq2Af4/Dp0XtgU4atQi0gjtnUlhGnuUY dauL2HzZct0bb3SyktnpHriAwwv0I87l24/hQJ9dMH7L9Ygj5fruFGFGcN4iRJg1Kj FKysxdm3XqyOBw3PgDxLfn/K2CzUB0y60LlobFdOkuz5sMGA+L9tnQJ7vPlfwIFRxF KU5V1j9iPSLPjYRmYlb8uQm3Y/faLQN2kH3gKojCdVzHFhrdaDRFyo+oaFdN4clLwX iLtlka7MtfHReeZEU5SGdO0pGXphzMJxR2fsHPPFgdd4Q1Rc+gEqkNHPoc9PceFu6l 4EfFr+fXLNKkw== MIME-Version: 1.0 X-Mailer: SnappyMail/2.36.4 Date: Thu, 15 Oct 2026 11:54:32 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: msd-xenproject.org@msd.im Message-ID: TLS-Required: No Subject: [BUG] libxl: `xl shutdown ""` powers off the host To: xen-devel@lists.xenproject.org Cc: anthony.perard@vates.tech, jgross@suse.com x-ovh-tracer-id: 13761311612377987032 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: dmFkZTFRz6qPYde7IaFNSXlgYqpRwqp/tFhmSwns9NJWoIbrEpE3CIu33jzvX+PUmmsVsKMP7eXP+/WtNSUBUliRzTUkdOMv14XoOPfDNTjUuo2p0zibMD7LE2KIrxUF5pkyHU1lO8edlKnLOumNuwWOYAxmXS19F05i4gXIBb775y4PcKzPD1QC8D1lgexH9Tu8pglZBGLgvG2lIB8U9ob58gqd9d+uLdpu2fU8PDn5CSN3eWFzI7VadOFEyIx9np2XqdmMrG0M1/FdykXVX1OdKTFWxBKqN0TNXDA5F2ulc1ZnxotlXy0GoLqyzfl97ASe03bJV2CSkSrF5Jg59M4VxudhmiuyG7rIj2sWSHFg76CoIUNFaPX5nkWBjVBJBcq9o+YKGo908eluuPXi6nTisrvvZdBvQBPoyG6pnltcKH7u25QqzmfoFtp+eINWLg62ToRqfMUqYg8rZS2UEIYznjWyo/rXKMxUUSXckgotj9JpSj0QTtWL3h0EzApv7oArsU9j8q0GmebBLTUZmA91TdLo+93vwrMGBEQ8Sr1MWVxptLEGuciPjxCbzJqsIzMkRw9CkuiBkECRnemym6CRPeV4zaGYBV87N5jXLmzQE45gNnElfecqMrz/9CO/ckN3ph/RRrjPTaZNFO9FgpkX0hpsJ8kx2a8DJdE5Lcyl+O2dlQ X-purgate-ID: tlsNG-ef75cf/1792065274-A7ED6AE4-91379726/0/0 X-purgate-type: clean X-purgate-size: 2685 Hi, An empty domain qualifier seems silently resolved to domain 0,=20 so=20a command such as : xl shutdown "" does not fail with an error: it shuts down dom0, which powers off the whole host. Impact ------ We ran `xl shutdown ""` on a Debian host running Xen 4.20.=20 Instead=20of printing an "invalid domain identifier" error, xl asked dom0= to shut down, and the physical server powered off, taking every guest down with it. The same input is easy to produce by accident, for example from a shell script with an unset variable: xl shutdown "$VM" # VM is empty or unset The diagnostic and patch is proposed assisted by Anthropic Claude.=20 I=20haven't tested it, it was generated when I was trying to understand i= f the shutdown behavior is normal. I just hope it will help you understanding faster. Cause (Anthropic Claude) ------------------------ In tools/libs/light/libxl_utils.c: int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, const char *name, uint32_t *domid) { int i, rv; for (i=3D0; name[i]; i++) { if (!CTYPE(isdigit, name[i])) { goto nondigit_found; } } *domid =3D strtoul(name, NULL, 10); return 0; ... With name =3D=3D "", the loop body never runs, so the string is treated a= s "all digits". strtoul("", NULL, 10) returns 0 without any error detection, and the function returns success with *domid =3D=3D 0. find_domain() in tools/xl/xl_utils.c then sees rc =3D=3D 0 and carries on with domid 0. Every xl subcommand that resolves its argument through find_domain() (destroy, reboot, pause, ...) is affected in the same way. Proposed fix (Anthropic Claude) ------------------------------- Reject the empty string up front, using the same error code as libxl_name_to_domid() already uses for an unknown name. --- a/tools/libs/light/libxl_utils.c +++ b/tools/libs/light/libxl_utils.c @@ -92,6 +92,10 @@ int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, co= nst char *name, uint32_t *domid) { int i, rv; + + if (!name[0]) + return ERROR_INVAL; + for (i=3D0; name[i]; i++) { if (!CTYPE(isdigit, name[i])) { goto nondigit_found; With this, `xl shutdown ""` prints: "" is an invalid domain identifier (rc=3D) and exits with EXIT_FAILURE, without touching dom0. (The line numbers in the hunk header are approximate; We have not built or tested the patch.) -- What do you think about it ? Regards, Msd From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:06:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:06:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445724.1665819 (Exim 4.92) (envelope-from ) id 1xHKEH-0006lF-6F; Thu, 15 Oct 2026 12:06:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445724.1665819; Thu, 15 Oct 2026 12:06: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 1xHKEH-0006l5-0v; Thu, 15 Oct 2026 12:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1445724; Sun, 11 Oct 2026 19:04:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFyq6-00044t-7B for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 19:04:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFyq5-0075vT-KQ for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 21:04:05 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acbdd72-bab6-0a2a0a5309dd-0a2a4503b008-32 for ; Sun, 11 Oct 2026 21:04:05 +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 6acbdda4-fae8-0a2a45030019-ac6904fecf58-3 for ; Sun, 11 Oct 2026 21:04:05 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id F03DE60232; Sun, 11 Oct 2026 19:04:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 435F91F0089C; Sun, 11 Oct 2026 19:04: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791745443; bh=xwkEhVzbUvjpITITmAO4h3R+R7/UDQRQJB9aMn4M6nw=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=T6j22e7NaJcS2fr8bxi+2fkNg3yrrBUkW62t0KEMPQPEPq6c0g63GVfOejKgcDELZ nmYI+TGJ0tsychweaRGXM07GIaFEB966dLGXJyiPj6MPWOn/DFHhGqWRvNFsXTA1ra 87Xeej/L81UcUVZorzjZeW51kYQGMzJcfsJTcZoB4zTKj0JyWidBNaJOJ6Ktoxn5FJ GSPMJY8QX27VBcLnNvtiLgJLQ18xB1oxYB/arUS4CmN/96Q3lt5LR2+ABSHrV4KunZ WzUvdS5XWPMRzPg/0rwoxHPa8HFmiuoRrT0YDo5ToOt5LgXojsjM/Jcx4KN/A2GZD8 uXYz9dXc4NUqA== Subject: Re: [PATCH net-next 4/9] xen/netfront: check for failure when pulling in xennet_fill_frags() From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: kuba@kernel.org, pabeni@redhat.com, edumazet@kernel.org, davem@davemloft.net, andrew+netdev@lunn.ch, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, leon@kernel.org, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, manishc@marvell.com, rahulv@marvell.com, GR-Linux-NIC-Dev@marvell.com, shshaikh@marvell.com, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Date: Sun, 11 Oct 2026 19:04:01 +0000 Message-ID: <179174544182.434549.6411289628191595001@kernel.org> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-4-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-4-9512b0fb977b@toxicpanda.com> X-sashiko-severity: High Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-33051d/1791745445-6DCD34E9-8F591169/0/0 X-purgate-type: clean X-purgate-size: 9080 Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider. Critical: 0 · High: 2 (2) · Medium: 1 · Low: 0 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [High] The patch now sends pull failures explicitly to an error path that leaks the head skb. - [High] net: xen-netfront: memory leak of head SKB on xennet_fill_frags() error path - [Medium] In xennet_fill_frags() (drivers/net/xen-netfront.c), replacing __pskb_pull_tail(skb, pull_to - skb_headlen(skb)) with… Pre-existing issues: - [High] This problem wasn't introduced by this patch, but xennet_fill_frags() (drivers/net/xen-netfront.c) reads each follow-on… - [High] This problem wasn't introduced by this patch, but in xennet_poll() (drivers/net/xen-netfront.c)… -- xen/netfront: check for failure when pulling in xennet_fill_frags() When the skb already has MAX_SKB_FRAGS frags, this patch makes xennet_fill_frags() call pskb_may_pull() instead of __pskb_pull_tail(), and it now checks the return value. The BUG_ON() on pull_to is removed. Both failure exits now share a common err label. > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c > index 2ed673649c488..6e01a883cc64a 100644 > --- a/drivers/net/xen-netfront.c > +++ b/drivers/net/xen-netfront.c > @@ -1174,18 +1174,11 @@ static int xennet_fill_frags(struct netfront_queue *queue, > > RING_COPY_RESPONSE(&queue->rx, ++cons, &rx); > > - if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS) { > - unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to; > - > - BUG_ON(pull_to < skb_headlen(skb)); > - __pskb_pull_tail(skb, pull_to - skb_headlen(skb)); > - } > - if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) { > - xennet_set_rx_rsp_cons(queue, > - ++cons + skb_queue_len(list)); > - kfree_skb(nskb); > - return -ENOENT; > - } > + if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS && > + unlikely(!pskb_may_pull(skb, NETFRONT_SKB_CB(skb)->pull_to))) > + goto err; > + if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) > + goto err; [Severity: Medium] Is pskb_may_pull() really equivalent to the old call when pull_to equals skb_headlen(skb)? pskb_may_pull_reason() returns before it reaches __pskb_pull_tail(): if (likely(len <= skb_headlen(skb))) return SKB_NOT_DROPPED_YET; The old code still called __pskb_pull_tail(skb, 0) in that case. Its pull_pages loop removes every zero-length frag, even with eat == 0: if (size <= eat) { skb_frag_unref(skb, i); eat -= size; } That lowered nr_frags and freed a slot. xennet_get_responses() accepts zero-length responses, since it only rejects status < 0 and offset + status > XEN_PAGE_SIZE. It also allows XEN_NETIF_NR_SLOTS_MIN + 1 (19) slots when the first response is at most RX_COPY_THRESHOLD bytes. Take the default MAX_SKB_FRAGS of 17, no XDP, a 64-byte first slot, non-empty slots 2-17, a zero-length slot 18 and a non-empty slot 19: slot 18: nr_frags == 17, pull 64 bytes, frags[0] consumed -> 16 zero-length slot 18 added -> 17 slot 19: nr_frags == 17, pull_to == headlen, pskb_may_pull() no-op nr_frags >= MAX_SKB_FRAGS -> goto err The old code would have dropped the zero-length frag at slot 19 and accepted the packet. A zero-length first slot gives the same result, because frags[0] is then zero-length. Are these packets now dropped and counted in rx_errors, when the old code assembled them? The commit message says "pskb_may_pull() does nothing if the head already holds pull_to bytes", but that does not match the old behaviour in this case. These drops also go through the xennet_poll() err path discussed below. [Severity: High] This is a pre-existing issue, but in xennet_poll() pull_to comes from the first slot's status. It has an upper cap but no lower bound: NETFRONT_SKB_CB(skb)->pull_to = rx->status; if (NETFRONT_SKB_CB(skb)->pull_to > RX_COPY_THRESHOLD) NETFRONT_SKB_CB(skb)->pull_to = RX_COPY_THRESHOLD; Suppose the backend sends a first slot with status below ETH_HLEN and XEN_NETRXF_more_data set, followed by non-empty slots. handle_incoming_queue() pulls only pull_to bytes and then calls eth_type_trans(): handle_incoming_queue() __pskb_pull_tail(skb, pull_to - skb_headlen(skb)) eth_type_trans() eth_skb_pull_mac() skb_pull_inline(skb, ETH_HLEN) __skb_pull() skb->len < skb->data_len -> BUG() For example, a 5-byte first slot followed by a 1000-byte slot gives len = 1005, data_len = 1000 and headlen = 5. Pulling ETH_HLEN leaves len = 991, which is less than data_len. Can a backend crash the guest this way? Should pull_to be clamped to at least ETH_HLEN? With a single short slot, skb_pull_inline() returns NULL, so this only applies when frags follow. > > skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, > skb_frag_page(nfrag), [Severity: High] This isn't a bug introduced by this patch, but xennet_fill_frags() reads each follow-on response from the shared ring a second time. It then uses offset and status without checking them again: RING_COPY_RESPONSE(&queue->rx, ++cons, &rx); ... skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, skb_frag_page(nfrag), rx.offset, rx.status, PAGE_SIZE); The only bounds check runs in xennet_get_responses(), on a separate local copy that is then thrown away: if (unlikely(rx->status < 0 || rx->offset + rx->status > XEN_PAGE_SIZE)) { RING_COPY_() does a volatile load, so this is a fresh read of memory that the backend can still write. Could a backend rewrite the slot between the check and this read? A negative status would lower skb->len and skb->data_len and store a huge frag size. An offset plus status past the page would create a frag that runs past the RX page. Commit 8446066bf8c1 was meant to make netfront read each response only once. Could the copy already validated in xennet_get_responses() be reused here? [ ... ] > @@ -1198,6 +1191,11 @@ static int xennet_fill_frags(struct netfront_queue *queue, > xennet_set_rx_rsp_cons(queue, cons); > > return 0; > + > +err: > + xennet_set_rx_rsp_cons(queue, ++cons + skb_queue_len(list)); > + kfree_skb(nskb); > + return -ENOENT; > } [Severity: High] net: xen-netfront: memory leak of head SKB on xennet_fill_frags() error path 1. Consequence: Memory leak of the main/head SKB and its data on the RX error path. Over time, an attacker triggering this error could exhaust system memory (DoS). 2. Triggering path: In xennet_poll(), a head SKB is dequeued from tmpq. It is passed to xennet_fill_frags(), which attempts to merge additional fragments. If pskb_may_pull() fails (e.g., due to memory allocation failure) or if nr_frags still exceeds MAX_SKB_FRAGS, xennet_fill_frags() returns -ENOENT without freeing the head SKB. Back in xennet_poll(), this triggers goto err, which loops over the remaining fragments in tmpq using while ((skb = __skb_dequeue(&tmpq))). This loop overwrites the skb local variable, causing the head SKB pointer to be permanently lost and leaked. 3. Reachability: High. A remote attacker could potentially send highly fragmented packets designed to exceed MAX_SKB_FRAGS to intentionally trigger this error path and exhaust memory. [Severity: High] Does this error path leak the head skb? This exit frees only nskb and leaves the partly built head skb with the caller. In xennet_poll(), the head skb has already been taken off tmpq: skb = __skb_dequeue(&tmpq); ... if (unlikely(xennet_fill_frags(queue, skb, &tmpq))) goto err; The err label there only drains tmpq, and it overwrites the local skb pointer: err: while ((skb = __skb_dequeue(&tmpq))) __skb_queue_tail(&errq, skb); The GSO failure path just above calls __skb_queue_head(&tmpq, skb) before goto err, but this path does not. The head skb is never freed or requeued. That would leak the linear buffer and the page_pool frag pages attached to the skb. These include pages moved over from earlier nskbs whose nr_frags was set to 0. The leak has existed since commit ad4f15dc2c70 (2018). However, the commit message assumes this path drops the packet ("take the error path explicitly"), and the change above sends more packets into it. Should the head skb be put back on tmpq, or freed, before goto err in xennet_poll()? -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:06:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:06:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445727.1665823 (Exim 4.92) (envelope-from ) id 1xHKEH-0006qb-Db; Thu, 15 Oct 2026 12:06:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445727.1665823; Thu, 15 Oct 2026 12:06: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 1xHKEH-0006pH-8H; Thu, 15 Oct 2026 12:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1445727; Sun, 11 Oct 2026 19:04:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFyq8-000455-So for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 19:04:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFyq7-007fhG-BJ for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 21:04:07 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acbdd67-8faa-0a2a0a5109dd-0a2a4507b238-28 for ; Sun, 11 Oct 2026 21:04:07 +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 6acbdda6-b4ea-0a2a45070019-ac6904febda2-3 for ; Sun, 11 Oct 2026 21:04:07 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id BC14D601E4; Sun, 11 Oct 2026 19:04:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4241F1F0089B; Sun, 11 Oct 2026 19:04: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791745445; bh=Ig+0+y+f6lfiozGzYQzbwtDL6sxb4GUQ6Cp/t/tcq3s=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=BZo2F/SwAn3E6EeHf7x+ECDWtVASPkWlWNzltBFSHAwoxQnOlT+nh1NASgrpE4PGO lZQJ4xmjJ39tPWzPWN99gpIMFwxDgHEVLl8vW+139XhWKJoem1PGY312qI1g10Ubhz jX2cHNndfHdZo5gAY8Nz9UtzxUb2LGjZ5ZaqGV3HG3JWhA4HpZMHhde5fFLf0wPGiv WnfkWQSQTZa3/h1B9bg3CDJ3KZnuk8xPoWmwECdRyAI7EEfq6BGXDkog+blD6JuDSL KISORjp/9xhmHxYaTyNNpF0/gThUv4mpigBSi66Ksw1rhYxCevY2lkJHqHQXsNHnPx TILMeHZD3vnCA== Subject: Re: [PATCH net-next 6/9] e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: kuba@kernel.org, pabeni@redhat.com, edumazet@kernel.org, davem@davemloft.net, andrew+netdev@lunn.ch, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, leon@kernel.org, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, manishc@marvell.com, rahulv@marvell.com, GR-Linux-NIC-Dev@marvell.com, shshaikh@marvell.com, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Date: Sun, 11 Oct 2026 19:04:03 +0000 Message-ID: <179174544385.434549.3694135096916688968@kernel.org> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-6-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-6-9512b0fb977b@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-ef75cf/1791745447-A70DDAE4-4BFD6840/0/0 X-purgate-type: clean X-purgate-size: 2458 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] After this patch, two unrelated error paths in e1000e log the same message. -- e1000e: use pskb_may_pull() in the 82571/2/3 TSO workaround This commit changes the 82571/2/3 TSO workaround in e1000_xmit_frame() to use pskb_may_pull(skb, len + pull_size) in place of a direct __pskb_pull_tail() call. With this change the driver no longer calls __pskb_pull_tail() itself. The error message printed on failure is updated to match. > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c > index 844f31ab37ad4..e216868e15cba 100644 > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > @@ -5859,8 +5859,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb, > unsigned int pull_size; > > pull_size = min_t(unsigned int, 4, skb->data_len); > - if (!__pskb_pull_tail(skb, pull_size)) { > - e_err("__pskb_pull_tail failed.\n"); > + if (!pskb_may_pull(skb, len + pull_size)) { > + e_err("pskb_may_pull failed.\n"); [Severity: Low] This isn't a bug, but this TX message now matches a message that already exists on the jumbo RX path in the same file: drivers/net/ethernet/intel/e1000e/netdev.c:e1000_clean_jumbo_rx_irq() { ... /* eth type trans needs skb->data to point to something */ if (!pskb_may_pull(skb, ETH_HLEN)) { e_err("pskb_may_pull failed.\n"); dev_kfree_skb_irq(skb); goto next_desc; } ... } e_err() expands to netdev_err(adapter->netdev, ...). The log line therefore shows only the device name, not the function or the direction. Before this patch the TX site printed "__pskb_pull_tail failed.", so the two failures could be told apart in dmesg. After it, a failed RX ETH_HLEN pull and a failed pull in the TX TSO workaround print the same line. Could the TX site use a TX-specific message instead, for example "TSO workaround pskb_may_pull failed.\n"? > dev_kfree_skb_any(skb); > return NETDEV_TX_OK; > } -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:06:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:06:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445723.1665813 (Exim 4.92) (envelope-from ) id 1xHKEG-0006iq-UO; Thu, 15 Oct 2026 12:06:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445723.1665813; Thu, 15 Oct 2026 12:06: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 1xHKEG-0006ij-Qj; Thu, 15 Oct 2026 12:06:36 +0000 Received: by outflank-mailman (input) for mailman id 1445723; Sun, 11 Oct 2026 19:04:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFyq5-00044n-CW for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 19:04:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFyq4-0075vT-3a for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 21:04:04 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acbdd86-bab6-0a2a0a5309dd-0a2a450b960c-20 for ; Sun, 11 Oct 2026 21:04:03 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acbdda2-b7e8-0a2a450b0019-ac6904fe9d92-3 for ; Sun, 11 Oct 2026 21:04:03 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id E9B66600E2; Sun, 11 Oct 2026 19:04:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6A731F0089B; Sun, 11 Oct 2026 19:03: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791745441; bh=LdxMvCC8JxkBtq+BNVpskgNv+Iemqb0CitObZkcZf3A=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=UzzUYkcxQOL0XlmelgcWjoUE8uZ5mu43l+m4m3WaR9oNIw62zCnUniB7tzEWo2BrB m/LtSCL5ygDk1oFfZBldkSOb9zcjhLNCiL0ryQ8J7LHAIrimuDA02HRyFG7gcNaeDp hJlAHlApw9NQgtB6uGiS1SdyWdNJPYYCIcokj6uBek3AWSfrNQrfwQN9yFCi/AjY1r L/H7nT8TTDqifm4cjorAwd2/DDPlx6Ti2F5nrdw4ff/R7AD535cW+u7s/elWHg0P39 JDkxuf933VY9tJJkaAlHfRXEPptQgd6XeC196sPAtXgJjdRykcwDhXBIS4gDvJqmwz RH2OwqBWE9Ddw== Subject: Re: [PATCH net-next 2/9] net/mlx5e: check for failure when pulling the Ethernet header after XDP From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: kuba@kernel.org, pabeni@redhat.com, edumazet@kernel.org, davem@davemloft.net, andrew+netdev@lunn.ch, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, leon@kernel.org, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, manishc@marvell.com, rahulv@marvell.com, GR-Linux-NIC-Dev@marvell.com, shshaikh@marvell.com, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Date: Sun, 11 Oct 2026 19:03:59 +0000 Message-ID: <179174543945.434549.12308757559903944189@kernel.org> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-2-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-2-9512b0fb977b@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-42698a/1791745443-A92CC9EA-E74BF8EF/0/0 X-purgate-type: clean X-purgate-size: 4310 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] In mlx5e_skb_from_cqe_mpwrq_nonlinear() (drivers/net/ethernet/mellanox/mlx5/core/en_rx.c), the new drop path… -- net/mlx5e: check for failure when pulling the Ethernet header after XDP This patch replaces the unchecked __pskb_pull_tail() call in mlx5e_skb_from_cqe_mpwrq_nonlinear() with pskb_may_pull(). If the pull fails, the packet is dropped. The goal is to stop eth_type_trans() from hitting BUG() in __skb_pull() when the linear part holds less than ETH_HLEN. > When an XDP program leaves less than ETH_HLEN in the linear part of a > multi-buffer packet, mlx5e_skb_from_cqe_mpwrq_nonlinear() pulls the rest > of the Ethernet header in from the frags with __pskb_pull_tail() and > ignores the return value. If that pull fails, eth_type_trans() later > finds less than ETH_HLEN in the head and BUG()s in __skb_pull(). > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > index e3f915beebe1b..b1e1e30a77e22 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > @@ -2060,9 +2060,12 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w > pagep->frags++; > while (++pagep < frag_page); > > - if (len < ETH_HLEN) > - __pskb_pull_tail(skb, min(ETH_HLEN - len, > - skb->data_len)); > + if (len < ETH_HLEN && > + !pskb_may_pull(skb, min(ETH_HLEN, skb->len))) { > + rq->stats->buff_alloc_err++; > + dev_kfree_skb_any(skb); > + return NULL; > + } [Severity: Low] Can this new drop path actually be reached? Given how the skb is built on the XDP path, it doesn't look like the pull can fail. For an skb with frags and no frag_list, these are the only failure returns in __pskb_pull_tail(): net/core/skbuff.c:__pskb_pull_tail() { ... if (!skb_frags_readable(skb)) return NULL; if (eat > 0 || skb_cloned(skb)) { if (pskb_expand_head(skb, 0, eat > 0 ? eat + 128 : 0, GFP_ATOMIC)) return NULL; } ... } The frags are always readable here because XDP and memory providers can't be used together: - dev_xdp_attach() returns -EBUSY when dev_get_min_mp_channel_count() is non-zero. - The memory provider binding code in netdev_rx_queue.c refuses when dev_xdp_prog_count() is non-zero. The skb isn't cloned either, since mlx5e_build_linear_skb() has just built it with napi_build_skb(). There is also always enough tailroom, so eat stays negative. The XDP setup earlier in this function is: linear_hr = XDP_PACKET_HEADROOM; linear_data_len = 0; linear_frame_sz = MLX5_SKB_FRAG_SZ(linear_hr + MLX5E_RX_MAX_HEAD); That leaves about 256 bytes past the linear tail, and the pull is never more than ETH_HLEN bytes. On the commit message's claim that this happens "When an XDP program leaves less than ETH_HLEN in the linear part of a multi-buffer packet", is that accurate? The driver always gives XDP an empty linear area. So the pull runs for every multi-buffer XDP_PASS packet whose program doesn't adjust the head. An XDP program also can't leave 1 to 13 bytes in the linear part, because bpf_xdp_adjust_head() rejects it: if (unlikely(data < data_start || data > xdp->data_end - ETH_HLEN)) return -EINVAL; When frags are present, bpf_xdp_adjust_tail() only changes the frags, so the linear data_end stays where it is. That means len is either 0 or at least ETH_HLEN at this point. If this change is meant as hardening, for example against later changes to linear_frame_sz, could the commit message say so? If there is a real way to make the pull fail, could the message describe it and add a Fixes: tag for the commit that added the unchecked __pskb_pull_tail()? > } > } else { > if (xdp_buff_has_frags(&mxbuf->xdp)) { -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:06:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:06:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445728.1665829 (Exim 4.92) (envelope-from ) id 1xHKEH-0006uH-PL; Thu, 15 Oct 2026 12:06:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445728.1665829; Thu, 15 Oct 2026 12:06: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 1xHKEH-0006rw-GK; Thu, 15 Oct 2026 12:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1445728; Sun, 11 Oct 2026 19:04:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFyqA-00045Y-29 for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 19:04:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFyq9-00CH6J-3i for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 21:04:09 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acbdd99-e002-0a2a0a5209dd-0a2a4501cc46-8 for ; Sun, 11 Oct 2026 21:04:09 +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 6acbdda7-5984-0a2a45010019-ac6904feb7e0-3 for ; Sun, 11 Oct 2026 21:04:08 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 8847560234; Sun, 11 Oct 2026 19:04:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CDB91F0089C; Sun, 11 Oct 2026 19:04: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791745447; bh=WuowvedJwpfz9l4BSl0jWJ9ure/QdY1u7QLk9R2KaLE=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=RjO6s4KjJvi7xkGcHN5EHGT6aPnhgDHeKBQR4KlNGg7G3veS5ERT6aUTK0AaS+4Au QseF9/l1US2IoNpmNX9S4or7ctEpEDBqd4luzSXcwVwLvWC/ob4sSqW50KbQFv8VP+ cSKMW70BgZb4peazc+WL0283hDfOSOndopEX2uDci/VjZ3T9uvQjL7oxNMNy4J6w4a ZwHUFm0MglbCCDknOMuQEuBbGKN1yCMBhv60uStpzDWgSMLVy2rZ/sdk7S2gq+AV/p +L+qnEjLswbYR/fpUhp92yCUmV+pDpVv08AfapC+huhSJ0OAdvt+J8K2Qskq7fTlCj rEvn6Jy/KogHg== Subject: Re: [PATCH net-next 7/9] netxen: use pskb_may_pull() to pull excess TX frags into the head From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: kuba@kernel.org, pabeni@redhat.com, edumazet@kernel.org, davem@davemloft.net, andrew+netdev@lunn.ch, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, leon@kernel.org, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, manishc@marvell.com, rahulv@marvell.com, GR-Linux-NIC-Dev@marvell.com, shshaikh@marvell.com, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Date: Sun, 11 Oct 2026 19:04:05 +0000 Message-ID: <179174544563.434549.2218178416870785309@kernel.org> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-7-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-7-9512b0fb977b@toxicpanda.com> X-sashiko-severity: Medium Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-d62444/1791745449-1D47D757-50357006/0/0 X-purgate-type: clean X-purgate-size: 4093 Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider. Critical: 0 · High: 0 · Medium: 1 · Low: 0 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [Medium] In netxen_nic_xmit_frame() (drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c), the new… -- netxen: use pskb_may_pull() to pull excess TX frags into the head This patch changes how netxen_nic_xmit_frame() pulls the TX frags that don't fit in a descriptor into the head. It used to call __pskb_pull_tail(skb, delta) directly. It now calls pskb_may_pull(skb, skb_headlen(skb) + delta). > diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c > index 67d9bf69f8f29..202deb64ddefb 100644 > --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c > +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c > @@ -2045,7 +2045,7 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev) > delta += skb_frag_size(frag); > } > > - if (!__pskb_pull_tail(skb, delta)) > + if (!pskb_may_pull(skb, skb_headlen(skb) + delta)) > goto drop_packet; > > frag_count = 1 + skb_shinfo(skb)->nr_frags; [Severity: Medium] Does this behave the same as the old call when delta is 0? delta is the sum of the sizes of the leading excess frags. It is 0 when every frag in frags[0 .. frag_count - NETXEN_MAX_FRAGS_PER_TX - 1] has size 0. The old __pskb_pull_tail(skb, 0) still ran the pull_pages loop. With eat == 0, every zero-size frag matched the size <= eat test: net/core/skbuff.c:__pskb_pull_tail() { ... eat = delta; k = 0; for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { int size = skb_frag_size(&skb_shinfo(skb)->frags[i]); if (size <= eat) { skb_frag_unref(skb, i); eat -= size; } else { ... } skb_shinfo(skb)->nr_frags = k; ... } So those frags were dropped, and the recomputed frag_count was back within the limit. With this patch the length passed is exactly skb_headlen(skb). That makes pskb_may_pull_reason() return early without calling __pskb_pull_tail(): include/linux/skbuff.h:pskb_may_pull_reason() { ... if (likely(len <= skb_headlen(skb))) return SKB_NOT_DROPPED_YET; ... } The skb is left unchanged, so frag_count stays above NETXEN_MAX_FRAGS_PER_TX (14), and nothing checks it again. After that: netxen_nic_xmit_frame() netxen_map_tx_skb() maps every frag, zero-length ones included netxen_set_tx_frags_len() writes the oversized frag count descriptor loop posts buffer_length[k] = 0 entries across extra cmd_desc_type0 descriptors The comment above this block says only 14 frags are supported for normal (non-TSO) packets. Could this post a descriptor chain the hardware doesn't support? When delta > 0 the two calls are equivalent, so only the delta == 0 case changes. It isn't clear whether zero-length leading frags can reach a TX driver today. Nothing on the TX path appears to rule them out, though. The commit message describes this as a direct swap: "It already checks the result. Switch to pskb_may_pull(), which takes the length the head should end up with and checks it against the skb" Would it make sense to re-check frag_count against NETXEN_MAX_FRAGS_PER_TX after the pull, and drop or linearize the skb if it is still too large? The later patch "qlcnic: use pskb_may_pull() to pull excess TX frags into the head" makes the same change in qlcnic_xmit_frame(). It looks like it has the same delta == 0 gap. -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:06:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:06:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1445731.1665833 (Exim 4.92) (envelope-from ) id 1xHKEI-00071p-1r; Thu, 15 Oct 2026 12:06:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1445731.1665833; Thu, 15 Oct 2026 12:06: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 1xHKEH-0006zY-Qq; Thu, 15 Oct 2026 12:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1445731; Sun, 11 Oct 2026 19:04:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xFyqB-000469-Od for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 19:04:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xFyqB-00CH6J-5d for xen-devel@lists.xenproject.org; Sun, 11 Oct 2026 21:04:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acbdd99-e002-0a2a0a5209dd-0a2a4501cc46-10 for ; Sun, 11 Oct 2026 21:04:11 +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 6acbdda9-5984-0a2a45010019-ac6904febc18-3 for ; Sun, 11 Oct 2026 21:04:10 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 9AE8A602C3; Sun, 11 Oct 2026 19:04:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE4261F0089B; Sun, 11 Oct 2026 19:04: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:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791745449; bh=4vxOlSiy9OgWc0Y0eZ4LnuQ00GAjNw7bsz9uahntp8s=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=CjY4UeAJxeRG+6zxZ2JMQ37NUAAJU7B0QFD0x9u4mXCWNj3x6vTki4Ex4jmP5nmTr nEldysQH5Y/i+i6Ds1cl7TMCoF4zbdO7g9CiGRvRY0SLb70r/ihN0mDoEIRqtoYn3w 2uzBXoO+p4seJUiCIHK2K9XYeWjuiQQAxemBKvKRSUv+qTLZogLvdD8pFDes31UBO/ qqqUxMv4TP2EuoPSEBNUPyElJS9DYJKkxV4am0zKNhEx33NSG7p9azBdb6wpDNxnk6 PRlz/r8bMcy04afRZ+RkwV6mpYk6jovQOrSnOeAcoCdhP2F5rRABrdly4WqTQ13wd+ m9WvDT+KPx5QA== Subject: Re: [PATCH net-next 8/9] qlcnic: use pskb_may_pull() to pull excess TX frags into the head From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: kuba@kernel.org, pabeni@redhat.com, edumazet@kernel.org, davem@davemloft.net, andrew+netdev@lunn.ch, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, leon@kernel.org, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, manishc@marvell.com, rahulv@marvell.com, GR-Linux-NIC-Dev@marvell.com, shshaikh@marvell.com, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Date: Sun, 11 Oct 2026 19:04:07 +0000 Message-ID: <179174544742.434549.15432453849443944349@kernel.org> In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-8-9512b0fb977b@toxicpanda.com> References: <20261007-b4-pskb-pull-tail-drivers-v1-8-9512b0fb977b@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-d62444/1791745451-C475B757-EDAD2C47/0/0 X-purgate-type: clean X-purgate-size: 3254 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] In qlcnic_xmit_frame() (drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:681-688), changing… -- qlcnic: use pskb_may_pull() to pull excess TX frags into the head This patch changes qlcnic_xmit_frame() so that it no longer calls __pskb_pull_tail(skb, delta) directly when a non-GSO skb has more frags than QLCNIC_MAX_FRAGS_PER_TX. It calls pskb_may_pull(skb, skb_headlen(skb) + delta) instead. The commit message presents this as an equivalent API swap. > diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c > index 761ef3bc8193a..4a81d499e51c0 100644 > --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c > +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c > @@ -682,7 +682,7 @@ netdev_tx_t qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev) > for (i = 0; i < (frag_count - QLCNIC_MAX_FRAGS_PER_TX); i++) > delta += skb_frag_size(&skb_shinfo(skb)->frags[i]); > > - if (!__pskb_pull_tail(skb, delta)) > + if (!pskb_may_pull(skb, skb_headlen(skb) + delta)) > goto drop_packet; > > frag_count = 1 + skb_shinfo(skb)->nr_frags; [Severity: Low] Is this exactly equivalent when delta is 0? delta is a byte count. It is 0 if all of the leading excess frags of a non-GSO skb with more than 14 frags are zero-length. In that case pskb_may_pull_reason() returns early and never calls __pskb_pull_tail(): include/linux/skbuff.h:pskb_may_pull_reason() { ... if (likely(len <= skb_headlen(skb))) return SKB_NOT_DROPPED_YET; ... } The old direct call to __pskb_pull_tail(skb, 0) always reached the pull_pages loop. With eat == 0, every zero-size frag matches size <= eat, so it is unreferenced and dropped from frags[]: net/core/skbuff.c:__pskb_pull_tail() { ... pull_pages: eat = delta; k = 0; for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { int size = skb_frag_size(&skb_shinfo(skb)->frags[i]); if (size <= eat) { skb_frag_unref(skb, i); eat -= size; } else { ... } skb_shinfo(skb)->nr_frags = k; ... } With the new call, nr_frags does not change. The recomputed frag_count stays above QLCNIC_MAX_FRAGS_PER_TX, and nothing checks it again. After that, qlcnic_map_tx_skb() maps every frag, including the zero-length ones. qlcnic_set_tx_frags_len() then writes this frag_count into the first descriptor. The descriptor loop programs more than 14 buffers for a non-TSO packet, which the comment above this block says the hardware does not support: /* 14 frags supported for normal packet and * 32 frags supported for TSO packet */ This needs an unusual skb layout, and no in-tree producer of it is known. Even so, could the frag_count be rechecked after the pull, or the commit message mention this difference? -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:07:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446611.1665857 (Exim 4.92) (envelope-from ) id 1xHKEo-0000Qu-IP; Thu, 15 Oct 2026 12:07:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446611.1665857; Thu, 15 Oct 2026 12:07: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 1xHKEo-0000Qn-Fd; Thu, 15 Oct 2026 12:07:10 +0000 Received: by outflank-mailman (input) for mailman id 1446611; Mon, 12 Oct 2026 21:12:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGNK5-00013d-Cl for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 21:12:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGNK3-00FncA-Td for xen-devel@lists.xenproject.org; Mon, 12 Oct 2026 23:12:39 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acd4d3b-e002-0a2a0a5209dd-0a2a450c9020-12 for ; Mon, 12 Oct 2026 23:12:39 +0200 Received: from [40.93.196.28] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acd4d45-f479-0a2a450c0019-285dc41c4ad3-3 for ; Mon, 12 Oct 2026 23:12:39 +0200 Received: from SA0PR12MB7090.namprd12.prod.outlook.com (2603:10b6:806:2d5::16) by CH0PR12MB8463.namprd12.prod.outlook.com (2603:10b6:610:187::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.25; Mon, 12 Oct 2026 21:12:29 +0000 Received: from SA0PR12MB7090.namprd12.prod.outlook.com ([fe80::de78:df30:c2e6:7adc]) by SA0PR12MB7090.namprd12.prod.outlook.com ([fe80::de78:df30:c2e6:7adc%3]) with mapi id 15.21.0472.015; Mon, 12 Oct 2026 21:12: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=HpNm3VC2BrYH141VoNprDWQ2WCaE/S1qCSO7eHebrUhiXAM7S/OzGtn5fgaCgGPh/X1HJt5NEbXVX08gkLAg9oq3M3r8eHXEpGFnDmSLv5CPJzfp27ryAFUl4ap5+VoF4w3AsJ4iFB4mNKqFXW6OvuLeOgBKXseluZTU7JRxwZdzxUNGA+TyDIoRBucqgOZqkx4H/CxoxqGSdT+cuwnScQjrA+iYwtGPVty2d9oH97H65j7amSBUqXZRirb/Xzu0iag7ZC5AjbE7deV3UX2RVFYm5iAvBaTW3Tjp5lxC4t01lnSTFNJdEJ7ryo+jRIqzlJ30mEBAgS7x8R8HSn+tkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ja9ntG+tzMYb+Vs+gsr7sUW+0KSJ9yCDv0HIuAXjetM=; b=yp1tcLPQbuSyQixDhmfUNx/rCN3NjeGYY2/bNg9Y8z/1wmwTU6r2L0Wi30VDJMJ+r4QoBJPN6RKy6yvGV73J0EYynDykp2xv36SU/a6Y5PWcH1oQynxCp8sdOWuxegUAKNXHUrZ0rxvO/IAuNGVd0B1m2XFEOPLjVhH6rRvvVeEv/Fy7B8xmg0JIXCvRlO7mHxFRu4HuzQT8c+ehAd+iAjXQniDlRjdufHYuZBp869D4FwX+5EU5Nsp/lgGefkwzP2RhmVg8x3UwDKO/uDnPaWW9OCVwoG9VuhvL3GRIGhqz7a/K8sydmvb7CRuZrNCoEWqG/W64bFSZboJ8/LYKYQ== 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=ja9ntG+tzMYb+Vs+gsr7sUW+0KSJ9yCDv0HIuAXjetM=; b=jfObQLU71JQBGpaK/e0bKE6PonycCn7Z8wtopyBhmQ+E2tUaS3bgQp0RNiluwkDMQLEuCFB4EZQF7/nhSR+NqN1bIziuSy5wYBMVQgt9xCPqIJjzrw8U2gMtH9PRn1f8NNulfGpDlKuTmtZWzC5KU1Fzy2NDq6OJtwqDA8RI6TyxMZVnJPDARV27DMmZfxuKg/6U6+ZSq0kFmQfDo7YZKtMlIzcy/3H+hkwUey/4/L2N9jCh3ux0yNye1Ax0qQ1p1FtJOm9dzRR1S9whgpxxPeRcvPv3lSa7bmfxO74QvLy5Aetz4474WEWXUAmIAph63zN8PQWqEbJGema62HvlWg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Message-ID: Date: Tue, 13 Oct 2026 00:12:11 +0300 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 2/9] net/mlx5e: check for failure when pulling the Ethernet header after XDP To: Josef Bacik , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org References: <20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com> <20261007-b4-pskb-pull-tail-drivers-v1-2-9512b0fb977b@toxicpanda.com> Content-Language: en-US From: Tariq Toukan In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-2-9512b0fb977b@toxicpanda.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PNYP287CA0016.INDP287.PROD.OUTLOOK.COM (2603:1096:c01:23d::20) To SA0PR12MB7090.namprd12.prod.outlook.com (2603:10b6:806:2d5::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA0PR12MB7090:EE_|CH0PR12MB8463:EE_ X-MS-Office365-Filtering-Correlation-Id: bec223dc-9360-4aac-46eb-08df28a5858b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|23010399003|1800799024|11063799006|56012099006|10067099003|18002099003|4143699003|22082099003|261009223027099003; X-Microsoft-Antispam-Message-Info: cjliPQprRqxIENv5FwbXIRVzl9VsWNT+uOZVP68pJbUlmNjEs8XNv86krvj+1mzxvfO1vPyXrmwvmYjiZNerEB6IyQFRCsW6T82SuZodIzP8tUqUFgbZFpWoYk+YosIeNXLlfw8g21opXHYCfv2GIU3HCItU5Fog8usPevR3tiCckg7JwO8K4DPBCSs9qOpeiq9Bav6aQ/3DdFqncYXpTvzZLdTw+SGeQb/jJzGwsJCrRATzcW6V4Ir5MhpdoOjC89cGY0C0yTWD8LBSNwHRQ7PAC+g6pL9hkEDFgFD60faDrXg8yhXni9XawEz0xlWIUX5eqATqyrQ6nUymVI/upbAxLmo4xpVAFOT1wbFqlcvZyK/YzXAkEsrrjCrwyDu71L9TXpq4isez2JxCLSaiHa7V23Skpqp46hJiFdE5b7OFyNAgcNxifof1nlIkvTQIwTCyVTMFfAj5zZWhdWwoGAiz6EGmIsB8VOsfA1siVINeq8mLAj1+vfQNHIL7I1a2L+rJNRWFM3GAMawEMdLfhr4Eg40C9UvKr7dKTS+vTzcqMux3HZ9ajColbWxWoo/ly52khzpNibL/g7eJOIQueU6iKeiV8JTxUCb/SoZ24GC88C54lWAyj3gAjhgo3erFori9SKaLMj4Z3a5cEikZM3kEpLvMQwi9RZNZ/jp6ZO8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA0PR12MB7090.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(23010399003)(1800799024)(11063799006)(56012099006)(10067099003)(18002099003)(4143699003)(22082099003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Tm1NOEZLUUpyd250ay94d1EvblZUUnovZUtDS1BJNTF1UW1CK0xUMjFDam9I?= =?utf-8?B?dFAvQ1RqSGh6amlyYm05SUUxSFBrNk81eGd4bEcyVHZZWDNaS3ZxMU5sdWJD?= =?utf-8?B?TlU5YndmNk1OZ0g1SndYNXNhTm1lV1l4dGtxalc2YzV3VVh3c2RWdVo1N084?= =?utf-8?B?d0R0amZxV1EybTh6OUhSMm8zWTNaQlNTODlmaEsrNWhqNVFla1o3MElySUxZ?= =?utf-8?B?SHQ2NTVQVTlUTWgzUmRWL0JQUTh5WVVhWXpkUWV4cGtKTWFrSXRrZ3JIakEw?= =?utf-8?B?ZEcrV0xFeEREZ0NlUXdpbENLbzNBMk9JR295KzM4ZTAzbHRlbFl3Y0F5T3Ar?= =?utf-8?B?TXIzUVJrRTNJZTlweUNKYnJ0cHZmMUFNRzM0RC9ObkJGMzRXbTZ3L2lSb1RF?= =?utf-8?B?SGNtVlRmZUY2VkwrRlE3d3Z5aUM1bzVuNmVqWWhyTVk2RU54cmJObnFBM2Zs?= =?utf-8?B?TVk3L2N4Sk9kN28ybXpYRnlxQ3E1M2hQMUJyb1JJZHREV0FrQWxOM2RqOXps?= =?utf-8?B?aGY5RkVYeWFieU1LN2ZkWWhXK3RjS3AzQXZsSGp4SEFUdlRZWEs5UE1DRTNJ?= =?utf-8?B?NGkwU04xRnNKeGJmMkREaStIcXk0REI5bmVLMkF0dW1ZMmFEUkp5dnBRaUZm?= =?utf-8?B?OU51clA1VGRzQ0d4a2Z4WUFvSGRFT0hiUjV3alk0ZFU1QnVtRGY4NHl4MG80?= =?utf-8?B?dFR0Wk8xY3l5NTVCdnlMcDJZYTZZc2VabCtwU29RUHdkaFlLSUZhWjkrOFBM?= =?utf-8?B?QmZrUXkyRDVNRXBFUXAzU2ZlSWlPTnFRTDlVNXR1YnAvUC9nNFFKMU1FUzli?= =?utf-8?B?LzV3NmxsdS83bnN5eXFacSt6T2l2YlJ4eWVCR28zWWkzOE9SQTR2MFNXT3dT?= =?utf-8?B?MmdxMWhiTEozQWhCQWh4T1pVVVhsQU0zZWR3blNrSGMrc0RKOWhjZU5jSWZM?= =?utf-8?B?Yk5GMG5qU2l3S3dWV3NWbm1mbVNqVHF0ek1lMVdNUFEvSVJISnora3IvbHhE?= =?utf-8?B?ckNLOGpaMm8yZS85emRRV05TRkdjZHFaOThqZFJTVzZDREVsWEhHUlVrU2hn?= =?utf-8?B?NVc4WlhDM29BWThmTUZzR01pbTNvTEdkRm9xeVRJQnlFRFF4L0hxa255eGRH?= =?utf-8?B?OStxWUw2dTVSekNVbFI0c2tBY0dUeWd1WXpvSHR0bjZXTjlXaGdCNXFjemhu?= =?utf-8?B?b3dOS0tTK3I4dnhHKzB4ZVdYQUFOaC9lTkdrZmVNK3JwT0NTSjhWNExYT002?= =?utf-8?B?TU9DYlBtQkNpVDJpM1VBUXd0a3l0T013Z0U2MlZlQTNPbEcxVDZRM0IxdDhV?= =?utf-8?B?dmxKdDdhejVlU1o4ZURCTTdrdTNQaVgyUFZLNVpDWC9yWFB3MG9SWTFDYnNw?= =?utf-8?B?TnFjbW41SHpWaTNXc05HbEdHb2ExOWFxK1diZ2M5TjFtbm5oY0wwaXpSWGZB?= =?utf-8?B?R1pNZW9pTVRWNWxlQ1JnNUZBdnVrTElBQW9YM2hJWFNQMHVxSjNidy9hY1cr?= =?utf-8?B?OTlGV2svQzRoQS9QcUt1ZzJGSWx3cmUvY05BQTFCaEJ3bjg5U1AySFg5S3JV?= =?utf-8?B?VTl0akZWZmlwVmlhekt2VjVmWVNhRnJXVWJqcXZLNEZDcEVwSExTSTM0N3Az?= =?utf-8?B?OExCVEFvT01hWERyekltMkNxUXRnTEsrRyt3b0QzaWlvUHByalh2cDAzdGQy?= =?utf-8?B?VG8wd0dnVUxCWDhmbjgwQUtpRWtqdWJHd2c2eDdDTVFaU0NIVEl0ZTgzVEpa?= =?utf-8?B?R0hsSFVydWVyb212K0JzcUVHSThsbmFXZTZmZXFuSFRmYVRHV2NHbllER1Ju?= =?utf-8?B?SGtJRk42c2NlWFVaVVl1MHIyVkVHOS9xbDNBck5jTmNkWDN0c3VSWDl3T3Yy?= =?utf-8?B?V3A2NFN5SGg2YVRsaTVYbW1qelUzVlFsWUNnVHB1Y04xNk5BRmdGTWFsYURk?= =?utf-8?B?ZVZWVEV6UDNqVUxBaGRIdmRTbjE1cndLMVpXTjFZN0pJTE52T09zRWdVRUVD?= =?utf-8?B?a0M4R2U0VGI2ZXFBK2JvVDJ5THFmVWZ2ZUtFL2JOcmpUOVl5UzdmMlUyZFdN?= =?utf-8?B?TnlqaVdHRnAvcnpxaitia0p0Ti85VHVtWjM4V3NvbTI3Y3l1cW9rbk5rZVZl?= =?utf-8?B?RGJ0eEdVd0Zqc0VXNllHMENZZTV2T250NEluamxRNEJIdmYrYlZqZFVZM2xC?= =?utf-8?B?ODRocUl3bEEvRmFxRE1EN3lQeTdzZDMzQW5BSGNnOGt0NmN2azFMVDVBRlNR?= =?utf-8?B?Q0hiWSsveUFOSlhJeTc4T25pVmRQek9NbWF1dS90ZThVdE51dVppMlBhZmRo?= =?utf-8?B?bUVxTkwzTS91Uy95amV1TDRaY1VVT2lYV20rMUI4Z00xSUlER3ZoUT09?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: bec223dc-9360-4aac-46eb-08df28a5858b X-MS-Exchange-CrossTenant-AuthSource: SA0PR12MB7090.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2026 21:12:28.9246 (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: u8wjkk7or7Pizk+UU9bvqv+O3BPx30Uxcw/S0X7L1JWWg9KVag9NxRDIkLF92eCMv/Z1FLOVpSnEpU6wsBBWGA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB8463 X-purgate-ID: tlsNG-d25034/1791839559-030D9A5B-829FA180/0/0 X-purgate-type: clean X-purgate-size: 1975 On 07/10/2026 21:16, Josef Bacik wrote: > When an XDP program leaves less than ETH_HLEN in the linear part of a > multi-buffer packet, mlx5e_skb_from_cqe_mpwrq_nonlinear() pulls the rest > of the Ethernet header in from the frags with __pskb_pull_tail() and > ignores the return value. If that pull fails, eth_type_trans() later > finds less than ETH_HLEN in the head and BUG()s in __skb_pull(). > > Use pskb_may_pull() instead and drop the packet if it fails. Pulling > min(ETH_HLEN, skb->len) keeps today's behaviour for a frame shorter > than an Ethernet header. > > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > index e3f915beebe1..b1e1e30a77e2 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > @@ -2060,9 +2060,12 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w > pagep->frags++; > while (++pagep < frag_page); > > - if (len < ETH_HLEN) > - __pskb_pull_tail(skb, min(ETH_HLEN - len, > - skb->data_len)); > + if (len < ETH_HLEN && > + !pskb_may_pull(skb, min(ETH_HLEN, skb->len))) { > + rq->stats->buff_alloc_err++; > + dev_kfree_skb_any(skb); > + return NULL; I understand that the real goal is the API change, not this branch. As of today, this is dead code. I'd at least mention this in the commit message. You already do so in the cover letter, but it vanishes... Something like: This can't fail today, since the head always has at least MLX5E_RX_MAX_HEAD bytes of tailroom and the skb is not cloned. > + } > } > } else { > if (xdp_buff_has_frags(&mxbuf->xdp)) { > From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:07:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446671.1665870 (Exim 4.92) (envelope-from ) id 1xHKEp-0000Zy-6Q; Thu, 15 Oct 2026 12:07:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446671.1665870; Thu, 15 Oct 2026 12:07: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 1xHKEp-0000Ys-0q; Thu, 15 Oct 2026 12:07:11 +0000 Received: by outflank-mailman (input) for mailman id 1446671; Tue, 13 Oct 2026 05:36:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGVBg-0004ns-1n for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 05:36:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGVBf-000dO6-Ec for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 07:36:31 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdc35b-8faa-0a2a0a5109dd-0a2a450cba12-14 for ; Tue, 13 Oct 2026 07:36:31 +0200 Received: from [209.85.216.43] (helo=mail-pj1-f43.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdc35d-f479-0a2a450c0019-d155d82bd831-3 for ; Tue, 13 Oct 2026 07:36:31 +0200 Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-3a0aaa0fd13so1758365a91.2 for ; Mon, 12 Oct 2026 22:36:30 -0700 (PDT) Received: from laptop ([175.157.230.130]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3ab38f4863esm22898117a91.11.2026.10.12.22.36.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 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=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=1791869789; x=1792474589; 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=31jej+zw5eC3wdks2N/0FrXz19KzIMeRP96y4F0yMqY=; b=lB5Y4BVdzKoAhMkIvOAKLK+rpLLKjqFM0LN2xkM5Q+xB/qohtXxUpe7MTDBf7GpQ/M IhFwbOWaLmS62NkTR0Mym2IpSZtaGNIHXXOex+PGf7f70Jh410OZWIQq+T8GryKKHujB aAQPlXS+O52xD5iSRuT6UpQ/K9RAktSYDPqaWfi5tFGpq4geqa+tQNJlcYLvF8i8FFGd URRUZB91MDatTz4ll0dadSCd4Q0KGbbp9HxM5QSQJjSHyjplhQAZL9WnPNSsudZmBF/F Vr2g+7AQa4p6xduTzL5GNkvc7KBxer+7uledE2asNwO+L40aE4f/whQxmBDNXszPcC5c TIWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791869789; x=1792474589; 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=31jej+zw5eC3wdks2N/0FrXz19KzIMeRP96y4F0yMqY=; b=CaCfvC9D0EIQbvz9382zSh+qHKMhV49VkhKylEQ1lbXkaTi/i7pqlmcHsNYq/cDr20 camNCQAojT09FyptdRltecnnMFfYaYs6/8s+Uusw1gFKmCd6Q4ANWjWXRIYuWwHOjsSm GFFAkPMacDrjH8MAF7QGr3hJlZXpo6uYRg7Wd278BtwTIvW9idxm7OxIAVeU12PlWyq5 fqLXzcSzY8hWf7Txf+r3ozWG9wM4RNJBHOKjzt4rVE9554foafch125h8vyh+5xvnbtZ vaS5kTmBfxXRd+atDFrH5bCBinPrMi7n1JJjtVWxhToJs7lpB+PuG4eaMXCNV8b13bRn 6gsg== X-Forwarded-Encrypted: i=1; AKwUvBxKBn9M4a1qIJ2ONYsci2gNt8QbW0DUMFdsOAMktaIw0hMZBNx2MgdnGyI7F854wvkt6gvOn4DuA0Y=@lists.xenproject.org X-Gm-Message-State: AFq9FYLmO8wKuOQboJ3b/aG1nfyrR0b696H0YtyIurEYtXBXgg5cxr2q TS4R4ZMpsPdksu8ex/h4bf8cPUCGlhNL2dvWyKOIijQSoYgI5y4pNIxpOF2/jtx3 X-Gm-Gg: AYBFou0mKsYvgyARwDjUvXf0RSueJN8qBkMjt+oI8bmBZxeRew1H/A530wJiEMRyUvl 9v7NWYaLTGZ1hnhqtcJFBSJa9mMONfhUilprLB/kLf35cXrYrcOWCAh0tNKGQCN6N37Os/nhjEQ 4vCm8PTeYK6uvln0SoYArU86ie6BXYFzPsvTatlT+tV75OXqC1IHG7/X2UpRxs6ZWVdtbO1hkvx RiK9e/S0X9ontfZz8yz03JUGn0IBmcygA4jf40sGVfm81T+Im+kNE8rlOAT3na2fFvodR26kKEb d9mP4ImxV+Co45sSBjLDHOvI/+bUPcvEe/tFFhSW+R2785vSH+X4wrHn6t5+TD8ulpjqskWMXPv 4KkC9fDfJS+COe7QyESIaeLWY5jDjcs/AtMKyQ1xhBGWxnPtJhwRxf9Z3zqzpyXa59AhWmNykDm c892/EVhOfsNb0wjmHvO1S20ofS44UTYzGZsi0Io6lDUDohWbxXb4wiFQLb3cfTEzS3NjuwmOjI 5x78nBOZMa7rkskmkG8GmrSLWG0du3igWUoeyqBBeqZfgyk6MhiC2sqsA== X-Received: by 2002:a17:90b:314e:b0:3ab:3201:310c with SMTP id 98e67ed59e1d1-3ab3a9aa90amr9458427a91.63.1791869789235; Mon, 12 Oct 2026 22:36:29 -0700 (PDT) From: Teshan Kannangara To: jgross@suse.com Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Teshan Kannangara Subject: [PATCH] xen/platform-pci: Disable device before releasing PCI regions Date: Tue, 13 Oct 2026 11:06:14 +0530 Message-ID: <20261013053614.1337340-1-tpk.teshan@gmail.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1791869791-00CCBA5B-FCF871B2/0/0 X-purgate-type: clean X-purgate-size: 1873 The probe error paths release the PCI regions before disabling the device. Documentation/PCI/pci.rst specifies that drivers should disable the device before releasing its regions to prevent devices from colliding on the same address range. Track successfully requested BARs in a bitmask and use a common cleanup path to disable the device before releasing those regions. Signed-off-by: Teshan Kannangara --- drivers/xen/platform-pci.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c index f2438232518c..a12ac57274a6 100644 --- a/drivers/xen/platform-pci.c +++ b/drivers/xen/platform-pci.c @@ -95,6 +95,7 @@ static int platform_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { int i, ret; + int requested_bars = 0; long ioaddr; long mmio_addr, mmio_len; unsigned int max_nr_gframes; @@ -115,16 +116,18 @@ static int platform_pci_probe(struct pci_dev *pdev, if (mmio_addr == 0 || ioaddr == 0) { dev_err(&pdev->dev, "no resources found\n"); ret = -ENOENT; - goto pci_out; + goto out; } ret = pci_request_region(pdev, 1, DRV_NAME); if (ret < 0) - goto pci_out; + goto out; + requested_bars |= BIT(1); ret = pci_request_region(pdev, 0, DRV_NAME); if (ret < 0) - goto mem_out; + goto out; + requested_bars |= BIT(0); platform_mmio = mmio_addr; platform_mmiolen = mmio_len; @@ -165,11 +168,8 @@ static int platform_pci_probe(struct pci_dev *pdev, if (!xen_have_vector_callback) free_irq(pdev->irq, pdev); out: - pci_release_region(pdev, 0); -mem_out: - pci_release_region(pdev, 1); -pci_out: pci_disable_device(pdev); + pci_release_selected_regions(pdev, requested_bars); return ret; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:07:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1448893.1665883 (Exim 4.92) (envelope-from ) id 1xHKEq-0000pI-0v; Thu, 15 Oct 2026 12:07:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1448893.1665883; Thu, 15 Oct 2026 12:07: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 1xHKEp-0000o2-Ob; Thu, 15 Oct 2026 12:07:11 +0000 Received: by outflank-mailman (input) for mailman id 1448893; Wed, 14 Oct 2026 12:05:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGxjk-00029M-0m for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 12:05:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGxjj-00GdSw-D4 for xen-devel@lists.xenproject.org; Wed, 14 Oct 2026 14:05:35 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acf7006-8faa-0a2a0a5109dd-0a2a4504c278-24 for ; Wed, 14 Oct 2026 14:05:35 +0200 Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acf700d-b57f-0a2a45040019-94a39c01a69c-3 for ; Wed, 14 Oct 2026 14:05:34 +0200 Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69E9waOp2016607; Wed, 14 Oct 2026 12:04:53 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 4h7dugm5g8-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 12:04:52 +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 69EAnqN23211855; Wed, 14 Oct 2026 12:04:51 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4h9q2ymp38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2026 12:04:51 +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 69EC4l5Q50397474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Oct 2026 12:04:47 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 287A32004B; Wed, 14 Oct 2026 12:04:47 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7EC8420040; Wed, 14 Oct 2026 12:04:45 +0000 (GMT) Received: from li-0f4bfd12-9554-4bfb-8b14-7ccf0f0767af.ibm.com (unknown [9.111.94.206]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS; Wed, 14 Oct 2026 12:04: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=ajZHd+qh6V9vTCXwQWUfdpmTLNkyLK ozm1g9bOoFoFc=; b=JYQ2N0nSXD/tQ/r+o3naoBOH1U+r2oPu+xjGpN+7txoDex Z0IWl63DxMAVur3sx+kmGREDCBqZc6k1HCDRjrOoEK+taOKH1OloSc9taF9O0FWY WpVjMbVUV3y+904j6Wquin+qDgUZtE0vakTE5A47rqq/xC7whZpk/bAH05j6NUMo GyNvztnXQB+E5AUtc1L0KRpmZ7LHjGzNNOr8tWNd56WpJVQz0J/T0JweCGvwVkOM 38Ai7Y5IXwL6To2w1AEdek15AbDAMLoAedQcEW17k9uz90AlYajIG2XNMhTS+zOV bWm4qcBhLuQq6bVn5TQRsfV9c0VsPZQvM+kgHPMQ== Date: Wed, 14 Oct 2026 14:04:44 +0200 From: Sumanth Korikkar To: Ian Rogers Cc: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Miguel Ojeda , Kees Cook , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Nayna Jain , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Viresh Kumar , David Teigland , Alexander Aring , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Zhihao Cheng , Felix Kuehling , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-s390@vger.kernel.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 08/11] s390/sclp_mem: Allocate struct sclp_mem dynamically and add kobject release Message-ID: References: <20261013223946.1836757-1-irogers@google.com> <20261013223946.1836757-9-irogers@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261013223946.1836757-9-irogers@google.com> X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=Cr0q4X4D c=1 sm=1 tr=0 ts=6acf6fe5 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=kj9zAlcOel0A:10 a=660iZSQnnn4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=1XWaLZrsAAAA:8 a=1KnzZOXWGbpzuJ82zDMA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-GUID: _EktMNlxNi0Zhojhx4ASfWVXd_b7DOlL X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE0MDA0NiBTYWx0ZWRfX0fUPhxARNcJa 9nS/iCLcc7dEQrcybdImltBqHci5KonN9BgYs2DYbqx1d8S2XOqe29HUtCRqWBLErMceEtiShcs 4sOis3II/pHWvCugYS8aQjzU25z5oQrs/O3mU6gDGKNdZjvK+pDPTKbfQLhBgdreLHYt/eXKSLj 8iaqk3GpEmiCS1rkaREHPfI9BfxMESceMf6fSb58kgdsHk98lVK94W4Z13ZaUDqucgF8UHsrXAF s2Mz0WmLaipai7UjCU1P9wfoh1rJSRoR35Qnnl4GViW47ZEhEXi38+rmYIbdZGaRW5Gb4NFboLC VDaNe6VnoQav6/qOqN3N/a+a+5cDALYf91XsQVsXP8nIWP35y0wihJcXC0kc0O7eYfGysmumoj8 nH3TGHAss/iHicos4JusXZh5QK06OZzsWCTSFTnMelfNV7UtEZDijv++v8M3SGrsGa+NyH77MdL 5RJO9I7QJmKjVLI0vig== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE0MDA0NiBTYWx0ZWRfXzh8XCAetvSto U4lKpTbi/IJ/4y5zYP4Ex816LutfdS+PI20y7l1acTJ0MKa2avnNDCgOzXRPOLPzbCG+UhRciiw hNFMfBzpg0MTAxSwj76JilCNvE6uZfI= X-Proofpoint-ORIG-GUID: IbMwSeABL9gn-KtBlV7Mt5gD5Rq_VQT_ 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-10-13_01,2026-10-09_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 spamscore=0 adultscore=0 priorityscore=1501 suspectscore=0 malwarescore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610080000 definitions=main-2610140046 X-purgate-ID: tlsNG-ebf023/1791979535-534C3B50-4B7EC079/0/0 X-purgate-type: clean X-purgate-size: 1250 On Tue, Oct 13, 2026 at 03:39:43PM -0700, Ian Rogers wrote: > sclp_init_mem() allocated a single array of struct sclp_mem with > kzalloc_objs() and registered each embedded kobject using a kobj_type > without a .release callback. Allocate each struct sclp_mem individually > with kzalloc_obj() instead and add sclp_mem_release() to free it. > > Fixes: ff18dcb19aab ("s390/sclp: Add support for dynamic (de)configuration of memory") > Assisted-by: Antigravity:gemini-3.1-pro > Signed-off-by: Ian Rogers Hi Ian, The entries under /sys/firmware/memory/memoryX in sclp_mem.c are permanent. They are backed by a single array allocated at boot and remain for the lifetime of the system. Memory hotplug can add or remove memory blocks under /sys/devices/system/memory/, but it does not remove these firmware entries. The /sys/firmware/memory/memoryX kobjects are never unregistered or freed, so I think there is no need for kobject_put() and no execution of a .release callback. Instead, could this follow the approach used in Patch 11 of this series? static const struct kobj_type ktype = { .release = NULL, /* Permanent firmware kobjects, never freed */ .sysfs_ops = &kobj_sysfs_ops, }; Thank you From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:07:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446669.1665863 (Exim 4.92) (envelope-from ) id 1xHKEo-0000TJ-Qp; Thu, 15 Oct 2026 12:07:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446669.1665863; Thu, 15 Oct 2026 12:07: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 1xHKEo-0000T9-Mw; Thu, 15 Oct 2026 12:07:10 +0000 Received: by outflank-mailman (input) for mailman id 1446669; Tue, 13 Oct 2026 05:35:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGVB2-0004ln-II for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 05:35:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGVAz-000dC6-3S for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 07:35:49 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6acdc31d-8faa-0a2a0a5109dd-0a2a4501b136-30 for ; Tue, 13 Oct 2026 07:35:48 +0200 Received: from [209.85.216.47] (helo=mail-pj1-f47.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6acdc333-5984-0a2a45010019-d155d82fe4ca-3 for ; Tue, 13 Oct 2026 07:35:48 +0200 Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-381b831d535so3018871a91.0 for ; Mon, 12 Oct 2026 22:35:48 -0700 (PDT) Received: from laptop ([175.157.230.130]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3ab38f5509fsm19656383a91.12.2026.10.12.22.35.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2026 22:35: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: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=1791869747; x=1792474547; 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=31jej+zw5eC3wdks2N/0FrXz19KzIMeRP96y4F0yMqY=; b=OHrUm715gA0pDQU1qXyaUS/LRfb/JKe2hwZl+rfHUngBFNvf1nckouQHI3p8KWuVQi BCHlnm6fNihYikhOvpqNIIXINREkXrwZ2hHD11mCyjbIQ39trdyo5HUwbBTn9cYmxfDR aNEI+hIVHiswHAYXDf8SQtaInpHo2tDvT4RuxHPKPD+DFFpcyj/sh/JyOk2YQzUZ1M2L VxSV1SVguQ7Fbm4sL66tke6vz6gFyedPEw9E5cFMkrrVrLbCRfZTnP31bawZSnSX6r+U /Iz4gNgdxWBfps5Y8KNINUOpY4K58xFiNAYKxYIc2fXfThIBCr7hzyUjhgV6dl3nc7Ut 3iSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791869747; x=1792474547; 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=31jej+zw5eC3wdks2N/0FrXz19KzIMeRP96y4F0yMqY=; b=rtSpTurph5BH884JViExpAmuu42GeA3FBLv0E4x1wxr3Y2xSwX8gdVSF/SQH7m6mG9 NrXeoqRTlN0sKEK1s3XJt6P+MlrFm3euf16tsqer1O3GV6s3Zg7bf19jOdBVvRERiEu+ uSxVbbIVscoF1hj1UcWPurrFtUcW23IYD4sUdnIPncPCg70LyZEaRsrL5X0ZhHFJKEog z4QdT55BdI89CcudrN1RakC28q9M4O3RSCql9WYylBcHCg7uhzkRLsS6mSl1iUEWJPAc FdBi63RZZyLFuWADOpzeXEqcQoYY1aIBAWhs8Py8OsXWeIFdvmpeRRI2Q/sRLbnnkQxB MiEQ== X-Forwarded-Encrypted: i=1; AKwUvBwkpk9LQG50bj+AHLLA54pxqQmLvSPE3pfdJZ2D2wYdZ15KaXHxEtVtod6BGbTYiMUqken/hV58ozQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYICwQKmEs2at9vHRL612L7N+tT2Kmphi5IXVPrGU5nFgGFWzHyg nK1YnjZyqoHhbjxj1mVgcc8oymgnjaEkOocEh+O7+Tbs1sjHwvQKFEqL X-Gm-Gg: AYBFou2wquvY7BoJq2oQpcTrLwzfYMf9gxo4LUIo+dQSndZD8Hp1aNxf2xVuDjeZTqb 0j396pkKdOCbmwWGZ1JQgrjG7ZnkpnTpmk9btgPvrg99NZKP2AAl7ObvZC3+RbbsSl3pQejTA/P S/m8/ObVfLNgjg7582W0GEk5xMQaMi7vDxZzo6GVOvZc7fjNexif+Ro3XBJJr6UjKdbqY5DK/2X zfiRmo4EB3HM+qSwvNYa9YUPSuUIQbmWY7JN1QIT9nQUtM7yoFCiFmlU60wD4GqFxKnFnqn/59r fjrU4ccxvtYeo9uB0w1BpF8astspbtWQ+KsyToq6D0A9SdjgiiJIgqmTI24LjBmbWhoEMeU8lXL 2cKFd+51+tZrIla1O55RixMj8gskjOF3B0tSAYVhrloiBh1sMUXheB8jk5CUf04d6QvJmw+cA/h Z7xYW85iQU4zYTJ6ElfPAaqMQQcd4z3mQGgeIjrrNzJNl2nwNEbHLITZwBCD6riQ2JBeIwvysGX QwHsuLDcY9PMdC67B7AQnn3ivekppSAdPx7hjTYxLhB/5rhVYIJIuGb X-Received: by 2002:a17:90b:4e83:b0:3ab:4f1:4f7e with SMTP id 98e67ed59e1d1-3ab3a9dfb4amr9315608a91.28.1791869746831; Mon, 12 Oct 2026 22:35:46 -0700 (PDT) From: Teshan Kannangara To: jgross@suse.com Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Teshan Kannangara Subject: [PATCH] xen/platform-pci: Disable device before releasing PCI regions Date: Tue, 13 Oct 2026 11:05:26 +0530 Message-ID: <20261013053526.1336149-1-tpk.teshan@gmail.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1791869748-BF063757-AE1F3130/0/0 X-purgate-type: clean X-purgate-size: 1873 The probe error paths release the PCI regions before disabling the device. Documentation/PCI/pci.rst specifies that drivers should disable the device before releasing its regions to prevent devices from colliding on the same address range. Track successfully requested BARs in a bitmask and use a common cleanup path to disable the device before releasing those regions. Signed-off-by: Teshan Kannangara --- drivers/xen/platform-pci.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c index f2438232518c..a12ac57274a6 100644 --- a/drivers/xen/platform-pci.c +++ b/drivers/xen/platform-pci.c @@ -95,6 +95,7 @@ static int platform_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { int i, ret; + int requested_bars = 0; long ioaddr; long mmio_addr, mmio_len; unsigned int max_nr_gframes; @@ -115,16 +116,18 @@ static int platform_pci_probe(struct pci_dev *pdev, if (mmio_addr == 0 || ioaddr == 0) { dev_err(&pdev->dev, "no resources found\n"); ret = -ENOENT; - goto pci_out; + goto out; } ret = pci_request_region(pdev, 1, DRV_NAME); if (ret < 0) - goto pci_out; + goto out; + requested_bars |= BIT(1); ret = pci_request_region(pdev, 0, DRV_NAME); if (ret < 0) - goto mem_out; + goto out; + requested_bars |= BIT(0); platform_mmio = mmio_addr; platform_mmiolen = mmio_len; @@ -165,11 +168,8 @@ static int platform_pci_probe(struct pci_dev *pdev, if (!xen_have_vector_callback) free_irq(pdev->irq, pdev); out: - pci_release_region(pdev, 0); -mem_out: - pci_release_region(pdev, 1); -pci_out: pci_disable_device(pdev); + pci_release_selected_regions(pdev, requested_bars); return ret; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:07:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1446871.1665877 (Exim 4.92) (envelope-from ) id 1xHKEp-0000gm-Mi; Thu, 15 Oct 2026 12:07:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1446871.1665877; Thu, 15 Oct 2026 12:07: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 1xHKEp-0000gF-Dm; Thu, 15 Oct 2026 12:07:11 +0000 Received: by outflank-mailman (input) for mailman id 1446871; Tue, 13 Oct 2026 10:02:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xGZKv-000317-GI for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 10:02:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xGZKu-00HUv6-Jx for xen-devel@lists.xenproject.org; Tue, 13 Oct 2026 12:02:20 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ace01a1-8faa-0a2a0a5109dd-0a2a4506cbfc-34 for ; Tue, 13 Oct 2026 12:02:20 +0200 Received: from [40.107.200.2] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ace01aa-195a-0a2a45060019-286bc80245dd-4 for ; Tue, 13 Oct 2026 12:02:19 +0200 Received: from SA0PR12MB7090.namprd12.prod.outlook.com (2603:10b6:806:2d5::16) by IA0PPFB67404FBA.namprd12.prod.outlook.com (2603:10b6:20f:fc04::be2) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 10:02:15 +0000 Received: from SA0PR12MB7090.namprd12.prod.outlook.com ([fe80::de78:df30:c2e6:7adc]) by SA0PR12MB7090.namprd12.prod.outlook.com ([fe80::de78:df30:c2e6:7adc%3]) with mapi id 15.21.0472.015; Tue, 13 Oct 2026 10: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=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=QRaKut8a9XWnL4T3t0TBkRcvdizbpoYJeB6bXyJ9HDT888S8XHBXnON3v8bxZOfhRH2oWkGk0e8i0Y6Ea4VKgVS4EIkNlv3iC/OM9A22c/9Re6H9YVYbW/7nCuJRyXYjxSYUuB6JDn4ja83H3CjZhHZY22JWuTqEHmtm8YlbtWD+fUvCpVn2Wm53DEKwGCEhDo0WTbXyJqCfY4039qFpSYYA/XLK0iHASQvS10BfpHPuIazLkUm5fI+ThDuGTUEYhWCItVBIJaU2D4lEZyHbR3q0ICvgVhQuuXvFFdvB3tlVGjAWWuElp7CZvztZCNJe2h6M1VYGw1MM1ldPHtZXNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qy3yY+PUMpUueTE2NMgzBPOfbGqmLKllDDTa+SFEff8=; b=Uu6ukrAFF6q7kfFruSgbCXeoN7KIsKKfyiC+03DsulNkvcr1Qh+a/wU3EFLbdjDRGMW7UonF9DAIaDdHUEo61/mEFfWC4/Am3tIP7hyY62WFxL7x8Zf+qfRJX/HGAHPJ8wwKjv9IYXj2LR0DXHhIqdDH3R+5F2ghi7fWkBpQJSh8tzqggAqT33kjZmMyR4aQkP0o88T8gW3zJa2mWJSVe2U8AYuvLbALoqWq9yFNGJxxItzlI8Lob3lg1BmQcTJ6I/A/VAssP51MSeeG3lDfxuKGbYjjQSQcILNroSIky1qSlGjk7BX/QKyCFS3RUMRRJalVbKeZFF5wAw7HRrjyyA== 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=qy3yY+PUMpUueTE2NMgzBPOfbGqmLKllDDTa+SFEff8=; b=qLPIBpuTgwEwKCAgw39H58bUa6naVSHxmT+onDbWszy56iY/2ven6GZpbJ2H7Q+skHsQd+zuWAjGJTuYmsazQTNaNzYzwuACofh3ZTTtsflorZLUe69SYlq16Y4RsrKKHJRNaI8v4sBoJ+rBMR448UcQs8lCD+Esl2+oTuBn66pflMqJuynyK+7VGbabInLuP37PUa5hx+ABog3fhzp1SzDkgkLZmoLxQOnKFLD5gE8MgImi9hkhYOURbnZnZFXpPcC1Stf4unrRqkC4VfaFCdmo1s8rG8WYcAR57o0l6D0WIZ8sITWaa9Nc6ZLXV7cA0q+jfPtkuZzSLtYG05jtqA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Message-ID: <5f025a06-da70-4cd9-96b4-d86f6d3ce9c4@nvidia.com> Date: Tue, 13 Oct 2026 13:02:06 +0300 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 03/10] net/mlx5e: check for failure when pulling the Ethernet header after XDP To: Josef Bacik , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008-b4-pskb-pull-tail-drivers-v2-3-8f2bd9bee138@toxicpanda.com> Content-Language: en-US From: Tariq Toukan In-Reply-To: <20261008-b4-pskb-pull-tail-drivers-v2-3-8f2bd9bee138@toxicpanda.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0230.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e9::20) To SA0PR12MB7090.namprd12.prod.outlook.com (2603:10b6:806:2d5::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA0PR12MB7090:EE_|IA0PPFB67404FBA:EE_ X-MS-Office365-Filtering-Correlation-Id: 6442062d-825f-4097-6ffb-08df29110eaf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|7416014|10067099003|22082099003|18002099003|11063799006|4143699003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: ymrZ3l7BC9mT6DTwEnN6BkRaGIRJGOVZHLv7Y+XBqOBU/8oByGeyuJSpG5bblbzfG5BQ3Yi4duCVBYOQ79+35xQ4igslKCWk81L9YR7tIoottftmADKpC6qDdgaNiHphUr2ePAMMRPevedNHrrKnewjKMPbhN9UMbAUVSF0OW7IHylx2H/fywEZR7+iW6zWQSAAI6WdpM9RWh0vfNIj5lU4yELB5fvKtM2UYe2tk1QyWPQet9sAIHcPInscDmwOPCV7ANMuidFjYjLajtl9MJ1CcJZjykaZnSMElnS403bBFv63FLkmMBBL+Mc9Q4pUhi2mrvlrOtKBiC5SqQPNSx0tIx1jJOfh9Ifdv6FzSkf9RObk/dCtwI7Brkbr1lhuh/w79PGgPqr/whzsAmHqEh9YuJM4h9D/SS0xlgBwSPdIsOrmtcWt4F8OvrHq9BbKuufirsOJ5Gge+jlxM4guTdyIc9qkPEAxRosBoDggzxemyWT+Lo03JKGqajrqXjCwEoF8fgu/Jk13MUplYP5CNcNYv3a3Cf6vd37R1eEMGUzKS4G7DmC7r+tGqvFK5UUYtx2zFJ7c77SGbS3pA1up+MW5pMeDnDiKhVQEFnvhpK35im8rRH08dtT4+jFOc6RGHQW72/rxmlM5238vy0gGKseEhZYKaPY892Xsnokj8cGg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA0PR12MB7090.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(7416014)(10067099003)(22082099003)(18002099003)(11063799006)(4143699003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QzliZGlXR0c2cHkvcThlZWF2NmRyUDlONm9nMnFUZHF5amtLNDNtcDdaN3lB?= =?utf-8?B?YUtIa3hTMlBOVmtPMkF2UXRCbWd3OHNlNHp4VkdsVTIzMlg2YXAzc1pURWF5?= =?utf-8?B?TjgvRmNFMXBPeWhLbXNtN1RIMGtpZEk0ZkdDb1N4N01qb0NHQWRBd1hiQXFp?= =?utf-8?B?c1AyM1V3RVZqYUZtemU5Q0RweDRVa2ZQaWZQdWZIdlJkMWJoV0NZTjVWdkpq?= =?utf-8?B?ajhmWm8wc2V4RytlbUJrcXBDSy9sQ3pNZFFPd2V2Ylg2LzQrUjl2M3FIdjdW?= =?utf-8?B?L25NQU5aYVgzNHBVUzlMS3owaEF0SHFadmVRS01GZ0dNS2RIR0hwc2hpMTc1?= =?utf-8?B?RXhTMTliOTc4QXUxNzI1T0h3TlNTcDQyUEpGRHZETkRwWThPK2hCRVRER1Az?= =?utf-8?B?U3NOeGZqdFYzUlV3ak00alJWenBuNUM5aTdMb3ZoQlliQW85am03VitLMkVy?= =?utf-8?B?L2kyWFFDNU93ZzJiS01JQzVYSFJuemlIMmJRdDMzZWc0aURzNnFnNmlGa1BC?= =?utf-8?B?QmlaUDlGbDlSNHNmbUs4UllqNWxuTUdEc1FKMlNUUldvaVpwcXdJTklWbTYw?= =?utf-8?B?WFNuVnBxMXE4TmtMT1pUNnN2TjV2TXJRak5HSHJlVmFYa1lSUnc5UlQwOEcy?= =?utf-8?B?RWk5dGlBNHl3M0g4NWo3RlVoajMxTmlWRHBNZUNaWTRvRGczUkwvMkhNT28w?= =?utf-8?B?bGZabXFuT1ozNHo1d1pnWFpUM1hMWHZwRVpHaUdtbnA5TzB0Y0diK2ZleDF3?= =?utf-8?B?V3RWa2lHNFZXeVBrWGhBWFhSdUp0Tjg4UWZaYWRIdmNna0dydFU3MytlNyt5?= =?utf-8?B?WmRWNGVFWVhhdW9uc2xLSUs3bXV1Y3BrdHdieHA0ZzJKbGhGMTROVGNYMFhk?= =?utf-8?B?SlZqa0FwR0JZL2N6RUEweit5ano4NU9BV1U4Z3RGeDBocjI5ZzhNUUlocUJm?= =?utf-8?B?ZUtTZ2JKS2prZlFqaHhBQy9raEpMMlVtVHJwWklKbjkvTHZmRFRCdnpIendV?= =?utf-8?B?ZFU1dDdpdlRnMlJFdDFOZ2Z6MFVIUVBDVXc2U2hSMjZudzNybm9QTE8vYlAy?= =?utf-8?B?a1huNFdaZnozWFlnYUpXcWdleU1jNmVGcTl6M0FuWEpvejRxZ3BBamRiWDZz?= =?utf-8?B?OGlMSldOdHBqRWRJckV3WnA1cE11dFNPZk5uemlSZjN3NmRIcDhlc2xiejNq?= =?utf-8?B?NHUwZHgzdlEvL3ZpSzM0UzZ2VURVZEVLVmxuQXFiZUlCclRFdk5RNW8vRG1N?= =?utf-8?B?NDNRMVIxQytRa0ZxWnFhTkNlN2hrc2x6QjcyRk5ON0NuNE9EUHhlamhYd0NY?= =?utf-8?B?V1BydTVPTjJJNVBUVFowYk0zb2hFVVJKUUozVncvZnFKUFhiWW1QRlN0MnRW?= =?utf-8?B?ZVBoRFh2YXFuYXordDc2Mm1HRkhZQ1ZjeGErYkhlRG5rYnhGck9ULzlYaFJM?= =?utf-8?B?cnhNSWpBSUNsUk5Mc09EWngwVkVyQWkwOHQ2RTg5aEJvN0FzU1B3ZndmY04r?= =?utf-8?B?R1c5ZjUrZVRMekRoZ1h5cytISk94ekFoQVpzcXU5aitDbGFrdVc1RXJXeEJF?= =?utf-8?B?VStTc1JpemcyMlNnN1NCdlZZcndyMFBaeVl5RWpSWXNtVjNmNzhYSDRuR2hl?= =?utf-8?B?VENUUGNBNmNsVE1rUWJteEJjVGUxS05rMElNcTZwT2NneDhSbVc5VkRMWXpC?= =?utf-8?B?UDFUcVprZlBsMjNQZE50NSt0M1VPaU9KYlpUaWx4cWhVam0rU2hSL0FRWmo4?= =?utf-8?B?N3ozWG9rbTROMi9mVmQ4VExGaFFmbVJWWSt6eWhqbU0yOXd0TGtRd2Z4NE9N?= =?utf-8?B?eHNBZ01PSUtlb1F5Yis0MDVNQTJRbnJtbDlNTGQ1SEhaY2VyU2FUajNRYklu?= =?utf-8?B?ZjRtQ2x3WXpIOVdKVkpqRmVFQWZMY0FxMXBSN09FZngrYUczNlI1b0V3dHJL?= =?utf-8?B?R3o0NnRZdTNXODlFd0loeklQWXdCVXhTbmVYd2U2Qko0Y1NONGpaaG5uRHM1?= =?utf-8?B?T0Zka3VGLyt5V2VHUjFFd0I4Qk00aWs4dC9ZeGFxc0JjQkdjL1djK014cmNP?= =?utf-8?B?QmtaYU96UEtQaEZIa2lrWUE0aS82K1E3UHJkcUh6WUZyZ2NjNUY2T0pnSFd0?= =?utf-8?B?dW5KUGZwaEx5T3p6ZWFheGlmTVNUOU1VZlN1Rk1DYS8zRWVqS2xtZzhBTTE1?= =?utf-8?B?V0RXQTYvdklUamtIZkxKRFRjeTlyK1NVYXJlZlQrVi9sdjMxWnRKcHg2N2tZ?= =?utf-8?B?TTFLenlad1hYQWNYRUNzS0JCeGV3VVQ3K0hNWERKVVh6a3ZFNlIwUnNsZ1k4?= =?utf-8?B?WDZNbkhKSi9IbHhhd253TWRMZ3pBWXZ0MWxkSGpKVVdpMnM3enBmdz09?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6442062d-825f-4097-6ffb-08df29110eaf X-MS-Exchange-CrossTenant-AuthSource: SA0PR12MB7090.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 10:02:14.9877 (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: bciWORfVVIrRKX1hXIJ6bGsHxUhf4C6dQSyEvolKbyLmrI63DyBiDzYAvCOGwZD/FFpUq7zBD7UWRVbHeu9riw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPFB67404FBA X-purgate-ID: tlsNG-16d1c6/1791885739-F5C0F77B-D313711E/0/0 X-purgate-type: clean X-purgate-size: 1732 On 09/10/2026 0:02, Josef Bacik wrote: > When an XDP program leaves less than ETH_HLEN in the linear part of a > multi-buffer packet, mlx5e_skb_from_cqe_mpwrq_nonlinear() pulls the rest > of the Ethernet header in from the frags with __pskb_pull_tail() and > ignores the return value. If that pull fails, eth_type_trans() later > finds less than ETH_HLEN in the head and BUG()s in __skb_pull(). > > Use pskb_may_pull() instead and drop the packet if it fails. Pulling > min(ETH_HLEN, skb->len) keeps today's behaviour for a frame shorter > than an Ethernet header. > > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > Hi, I posted relevant comments on V1. https://lore.kernel.org/all/d2d64d12-24a9-4bf1-b505-3008e0e25c40@nvidia.com/ > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > index e3f915beebe1..b1e1e30a77e2 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c > @@ -2060,9 +2060,12 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w > pagep->frags++; > while (++pagep < frag_page); > > - if (len < ETH_HLEN) > - __pskb_pull_tail(skb, min(ETH_HLEN - len, > - skb->data_len)); > + if (len < ETH_HLEN && > + !pskb_may_pull(skb, min(ETH_HLEN, skb->len))) { > + rq->stats->buff_alloc_err++; > + dev_kfree_skb_any(skb); > + return NULL; > + } > } > } else { > if (xdp_buff_has_frags(&mxbuf->xdp)) { > From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:22:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:22:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450432.1665903 (Exim 4.92) (envelope-from ) id 1xHKTy-0000iy-Oi; Thu, 15 Oct 2026 12:22:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450432.1665903; Thu, 15 Oct 2026 12:22: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 1xHKTy-0000ir-LV; Thu, 15 Oct 2026 12:22:50 +0000 Received: by outflank-mailman (input) for mailman id 1450432; Thu, 15 Oct 2026 12:22:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHKTw-0000hg-La for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:22:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHKTw-007FiC-2M for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:22:48 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0c596-8faa-0a2a0a5109dd-0a2a450bda92-14 for ; Thu, 15 Oct 2026 14:22:47 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0c597-b7e8-0a2a450b0019-d155dd2dd444-3 for ; Thu, 15 Oct 2026 14:22:47 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48c02782159so3201731f8f.0 for ; Thu, 15 Oct 2026 05:22: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-48dfa9a197csm220358f8f.27.2026.10.15.05.22.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 05:22: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=1792066967; x=1792671767; 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=od4CMuCpgRUYLBBFZ1xeREuCkvWHH3KnFW4kQOV6tU8=; b=gkhKMyf//P7GJC82ulc3C+Jm9zEAklPwBXr82CWf0Xz4U4DZ1grwCa5H8lxbHdR7SD 3+hZBY1l4/hDK1CMyKgkiS9v0CTKAXUOOYYkDaiYiqyhyh4qvvvqGSxFZO+ohvVuLGb5 GrfpX0zE5ASPCAsIJQQE+jj+5x2CvehUpZ+cuw8XU66IVCNDE5brL9Dn1LZr7CthhtCt K2bjVjUwu9NsgBTQ1Vpg9ui11eEZU2Kd5fN5oo4DJHYCdeFfBon/jLUyxd0WgJLnmZhO 0HDfXFcic6Zds6rBKZ4HEWjNUZE3OZabToYILkVJEZdtAgzQhpUip/SORwPV47hRkZhb R4kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792066967; x=1792671767; 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=od4CMuCpgRUYLBBFZ1xeREuCkvWHH3KnFW4kQOV6tU8=; b=TY5jlFl9jP9Srd77fY0kkSQnSuYJq/DWFr2PNw253baA2r/NNErlFpeujvSumRP5k/ PBD0ySof5GghS8flDBSdN8/cTk/ETNSjY9KtWOK172IbnDnveyNuqMfQcQGGEc4d1I88 wBBnytXvIDfg19Cr1gyRzOgaq3nKUZH6+J80fDju7bfYBS78ZHlLyKBcrGEk4sp71HvN tTd73jfh9brhR9HktB3tWnzvJlltkRjomG5xK+Qg11wCJWJa2U7HKJ7G8v3ZK7UXfA+Q o5PGbF0Hcfn9A8KR1lzX+7fSYmozKF3B8Pg2XV6DCtAxJ7NTAvp0CDfB5rImZ31Vvl5j 1gOQ== X-Forwarded-Encrypted: i=1; AKwUvBzNdg7b2RMcyHZ+UpxeYwxR/Ag235BJEoWj8ccEAuuY8Y97TIQ+/YKuv0BCDaihppCJvijPmKVS4wU=@lists.xenproject.org X-Gm-Message-State: AFq9FYIgfwaDEeXC6eV3CV+vV57fk6CGetjH8RrnH5JSR0YS/zK7bw8K ut0SlVRYrFZ4oY8EFJm27clONf7N2WEe0pTEDMKaJDFYrumMrY0X4lQonT6m45G8Uw== X-Gm-Gg: AYBFou2RYs5i2uBfnomr9wZ8xgs0AZAibTOS3Aj5VqtJoQOV3dPNQLr0xXUv10nH6Rf /w3Zjs/IZ8AWixcxqhyGSRI+32Ewy/billjUgpmS31w1TH5i0V4saoJxRLfm7fzVBd1ty08hjjV rwiSOkEQuBGBhEBgjP2G3MfnQb08m/RJPKPHkksU+oXqqX1eH0lfv0UCIqCfgIIDuaBOB1I4mpy 4oWN9mu8qo0DVtXG/b0pphu0Ivm6BSjMqDS6M420wFFPp10ugh5wIUrAg6t9iKyEIpQDd9Yrbgj 3sKRb0Oa9KPraXsYT/hceblMQdTjNoWgwhsjYoNYRYCY4p7QcNIKc70cuGfDjGmL1ho+20knbWm vMAC2dlDkMcMSNcKok8Yhiv19IVqrCUavNrmU74jbyhH+4R0fL3Y5ZLCVmyQUriCSvbrTR54FoE 3vGob+lQSmj7DXaM27bdpEqvXIyhmstYUaqH5ebcA+LmkYTPM7GTrs6HCoerXTuGfEYq5eVe4t9 P0ZrU9sK35DXycAGBFLn8Z8ZaEllJY8yywk0chVMnDahHFB1KtzTd1H0EvjA88= X-Received: by 2002:a05:6000:4904:b0:48a:f0cd:8712 with SMTP id ffacd0b85a97d-48dbacf4734mr39643067f8f.50.1792066967357; Thu, 15 Oct 2026 05:22:47 -0700 (PDT) Message-ID: <5a4114ad-5c5f-4da8-90ab-1fca04c9afe4@suse.com> Date: Thu, 15 Oct 2026 14:22:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/3] x86: use __builtin_popcountl() for arch_hweightl() when available To: Andrew Cooper Cc: Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , "xen-devel@lists.xenproject.org" References: <9e48f405-4e99-4258-921e-2948f0d6754d@suse.com> <716a13d4-9fd8-41bf-b475-08d0747ff442@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: <716a13d4-9fd8-41bf-b475-08d0747ff442@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792066967-1AEDE9EA-F4EA1FBD/10/78276251493 X-purgate-type: spam X-purgate-size: 1627 On 15.10.2026 12:37, Andrew Cooper wrote: > On 15/10/2026 10:10 am, Jan Beulich wrote: >> Use the respective compiler builtin when available; no need to play any >> alternatives games in such configurations. >> >> Signed-off-by: Jan Beulich >> --- >> v4: Re-base (re-do). >> >> --- a/xen/arch/x86/include/asm/bitops.h >> +++ b/xen/arch/x86/include/asm/bitops.h >> @@ -500,6 +500,9 @@ static always_inline unsigned int arch_f >> >> unsigned int arch_generic_hweightl(unsigned long x); >> >> +#ifdef __POPCNT__ >> +#define arch_hweightl __builtin_popcountl >> +#else /* !__POPCNT__ */ >> static always_inline unsigned int arch_hweightl(unsigned long x) >> { >> unsigned int r; >> @@ -525,5 +528,6 @@ static always_inline unsigned int arch_h >> return r; >> } >> #define arch_hweightl arch_hweightl >> +#endif /* __POPCNT__ */ >> >> #endif /* _X86_BITOPS_H */ >> > > This is needlessly complex. I don't mind doing it this way. (It's less complex in source then, but more complex for the compiler.) Jan > --- a/xen/arch/x86/include/asm/bitops.h > +++ b/xen/arch/x86/include/asm/bitops.h > @@ -504,6 +504,10 @@ static always_inline unsigned int > arch_hweightl(unsigned long x) >  { >      unsigned int r; >   > +    /* If compiled with a suitable baseline ISA. */ > +    if ( IS_ENABLED(__POPCNT__) ) > +        return __builtin_popcountl(x); > + >      /* >       * arch_generic_hweightl() is written in ASM in order to preserve all >       * registers, as the compiler can't see the call. > > > ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:30:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:30:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450445.1665912 (Exim 4.92) (envelope-from ) id 1xHKb0-0003Xx-F5; Thu, 15 Oct 2026 12:30:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450445.1665912; Thu, 15 Oct 2026 12:30: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 1xHKb0-0003Xq-Bs; Thu, 15 Oct 2026 12:30:06 +0000 Received: by outflank-mailman (input) for mailman id 1450445; Thu, 15 Oct 2026 12:30:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHKay-0003G9-CN for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:30:04 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHKay-00000006hin-2CXJ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:30:04 +0000 Received: from mail-lj1-f179.google.com ([209.85.208.179]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xHKax-00000005e0z-3FhW for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:30:04 +0000 Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-3a980c01033so15622331fa.3 for ; Thu, 15 Oct 2026 05:30: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" 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=3vBMeMWiS3ioV1NAkGSXr5rYMbTFgaV/MezvaVgnb9c=; b=cQ5uqwtl8Fy3KOG4dwN+bhC52o mst7Sj4ACRRzy/EvWUcpEL4dRfMgX+0RVBMpT/OgtkGEUVtI9izenQUtU8lTRDdzIBlkuGapaQjVS e2UwzX1X9ioxlEMxBZyXQk+sSh1h+f9HD3TDt+AiAOf34FOk7mczSpCkJPKXkIw3sbjU=; X-Gm-Message-State: AFq9FYKrWp/NLfo/ikxxSqHfgf896yt347y7fPhOdELoFYwDcYYaN26e w5JJQf/iGff5OT30A9gXRbmmz15gSCXs7qWQfa7nai1G0e4b5awhHGvFa++Jgrf7cPhsjS2S0i7 +gI19wa7ZW+hSHN9Au9dVDFvB0k6cI3g= X-Received: by 2002:a2e:a9a3:0:b0:3a2:f233:5c6e with SMTP id 38308e7fff4ca-3a9c515d16dmr45999451fa.6.1792067403076; Thu, 15 Oct 2026 05:30:03 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-18-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Thu, 15 Oct 2026 13:29:51 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_ShVXtfeidRAr9_-zrO0gTonddJQSrHPAbFi4M-kgGKW745GrxRiBLh_o Message-ID: Subject: Re: [PATCH v3 17/18] x86/mm: run guest contexts on the sparse directmap view To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 9, 2026 at 8:58=E2=80=AFAM Roger Pau Monn=C3=A9 wrote: > On Wed, Oct 07, 2026 at 11:40:50AM +0100, George Dunlap wrote: > > In init_xen_l4_slots(), if d->arch.sparse_dmap is set, point the > > directmap L3 at the sparse view. > > > > d->arch.sparse_dmap is decided at domain creation: PV domains all have = a > > mapcache, HVM domains need per-vCPU page-tables for one. No option ask= s > > for the sparse view yet. > > Is it strictly needed to tie the sparse directmap to having a per-vCPU > mapcache on HVM? AFAICT HVM domains could also use the classic > per-domain mapcache. They could, if it were implemented. I haven't implemented it, and didn't plan to; so until it's implemented, the sparse view needs vcpu_pt on HVM domains. > > The sparse view becomes active once dom0 is built, before it first runs= : > > dom0's construction runs on the full directmap, which it needs, and its > > root page-tables so far (a PV dom0's first L4s, a PVH dom0's monitor > > tables) are switched over then. A PV dom0 booted with dom0=3Dshadow is > > switched as well: shadow mode is enabled only later, from a tasklet, an= d > > its shadow L4s then get the sparse view from init_xen_l4_slots(), as fo= r > > any PV domain entering shadow mode. Anything built later gets the > > sparse view from init_xen_l4_slots(). The sparse view's slots are > > marked NX at activation, as the full directmap's slots are. > > Is NX worth mentioning here? The expectation is that the sparse dmap > slots will use the same attributes as the full dmap, and hence I > would focus on the differences (if any). Sure, we can drop that. > > @@ -1743,6 +1744,10 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t = l4mfn, > > (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots - > > l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); > > } > > + > > + /* The domain's contexts may run on the sparse view of the directm= ap. */ > > + if ( sparse_dmap_active && d->arch.sparse_dmap ) > > + sparse_dmap_install(l4t, short_directmap); > > Instead of doing the copy of the full directmap from the idle page > tables, and then rewriting, won't it be simpler if the copied > directmap was the correct one right away rather than doing a fixup > afterwards? Yes; I'll rewrite this. > > @@ -437,3 +439,130 @@ void __init sparse_dmap_init(void) > > > > printk(XENLOG_INFO "Sparse directmap: %lu pages mapped\n", mapped)= ; > > } > > + > > +/* > > + * Point the directmap slots of the root page-table @l4t at the sparse= view. > > + * Every slot it covers gets its L3, whatever the full directmap has t= here, > > + * so that memory added later is covered too. A PV root has guest slo= ts > > + * above; any other root loses the rest of the directmap, which the sp= arse > > + * view does not cover. > > + * > > + * Directmap mappings may be global, in either hierarchy. Translation= s of > > + * the full directmap must not remain usable on a root carrying the sp= arse > > + * view: every CR3 write which can move a CPU from the one to the othe= r goes > > + * through switch_cr3_cr4(), which flushes what the old root left in t= he TLB, > > + * global entries included, before it returns. The other CR3 writes, = which > > + * may keep global or PCID-tagged entries (_toggle_guest_pt(), XPTI's = entry > > + * and exit paths), switch between one vCPU's roots, which carry the s= ame > > + * directmap, or to XPTI's per-CPU root, which maps only this CPU's st= ack, > > + * IDT and TSS there. Removals from the sparse view flush all CPUs, g= lobal > > + * entries included. > > IMO parts of this comment are likely out of scope here. It's fine to > discuss about the flushing strategy in the commit message, however > doing so in a comment here, that's disconnected from the definitions > of switch_cr3_cr4() and _toggle_guest_pt() seems out of place. > > I would also avoid referencing function names in code comments: it's > fine to do so in the commit message, but it's likely those references > in comments will go stale as functions change names or disappear. > Commit messages are otherwise tied to a specific point in time, so the > context and the referenced functions are always accurate and it will > never go stale in the context is was committed. Yes, I've done a general pass to trim down comments. > > + */ > > +void sparse_dmap_install(l4_pgentry_t *l4t, bool pv) > > +{ > > + unsigned int i; > > + > > + ASSERT(sparse_dmap_root); > > + > > + for ( i =3D l4_table_offset(SPARSE_DMAP_START); > > + i < l4_table_offset(SPARSE_DMAP_END); i++ ) > > + l4t[i] =3D sparse_dmap_root[i]; > > + > > + if ( !pv ) > > + for ( ; i < l4_table_offset(DIRECTMAP_VIRT_END); i++ ) > > + l4t[i] =3D l4e_empty(); > > +} > > + > > +static void __init sparse_dmap_install_mfn(mfn_t mfn, bool pv) > > +{ > > + l4_pgentry_t *l4t =3D map_domain_page(mfn); > > + > > + sparse_dmap_install(l4t, pv); > > + unmap_domain_page(l4t); > > +} > > + > > +/* > > + * Let guest contexts run on the sparse view. Root page-tables built = from > > + * here on carry it (init_xen_l4_slots()); those of the domains built = so far > > + * (dom0, which has not run yet) are switched over here. Its construc= tion ran > > + * on the full directmap, and needed to. > > + */ > > +void __init sparse_dmap_activate(void) > > +{ > > + struct domain *d; > > + struct vcpu *v; > > + unsigned long va, mapped =3D 0; > > + unsigned int i, switched =3D 0; > > + > > + if ( !sparse_dmap_root ) > > + return; > > + > > + /* > > + * Nothing in the directmap is executed: as subarch_init_memory() = does > > + * for the full directmap, mark the sparse view's slots NX, before= any > > + * root page-table takes a copy of them. > > + */ > > + if ( cpu_has_nx ) > > + for ( i =3D l4_table_offset(SPARSE_DMAP_START); > > + i < l4_table_offset(SPARSE_DMAP_END); i++ ) > > + l4e_add_flags(sparse_dmap_root[i], _PAGE_NX_BIT); > > Shouldn't this be done when the sparse directmap L4 are populated, > instead of here? In the meantime, this function has been removed; NX bit is now set in sparse_dmap_init(), and the rest of the code you comment in this function has been removed. -George From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:33:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:33:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450455.1665921 (Exim 4.92) (envelope-from ) id 1xHKdy-00051l-RP; Thu, 15 Oct 2026 12:33:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450455.1665921; Thu, 15 Oct 2026 12:33: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 1xHKdy-00051e-Oc; Thu, 15 Oct 2026 12:33:10 +0000 Received: by outflank-mailman (input) for mailman id 1450455; Thu, 15 Oct 2026 12:33:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHKdy-00051Y-Ci for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:33:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHKdx-008uJA-Pc for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:33:09 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0c805-bab6-0a2a0a5309dd-0a2a450682dc-2 for ; Thu, 15 Oct 2026 14:33:09 +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 6ad0c805-195a-0a2a45060019-d1558035e90f-3 for ; Thu, 15 Oct 2026 14:33:09 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49ff680331aso22559235e9.3 for ; Thu, 15 Oct 2026 05:33: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-48de0ac37acsm18536250f8f.34.2026.10.15.05.33.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 05:33: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=1792067589; x=1792672389; 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=nvF0af+VuEpF2w4gUxax4o5sROQ0UEvX8+kiusy4yc4=; b=ReMd+vmRBBD/WzFPg+WO+Lp6fS7IDlH5bv+F/M0veom+NkZZwD6mLy71bsadu0Boi0 xGzMwUq7FV8HftzKCmqSdjcKq66EbpahzhRfdnA5PYKFywKQwonr/KtY9G74JLE3+I+B 3GVKhqKvqEhHHxczLgX031G0QLd3serPAeZX5KQO5+NlH+6AIhuB2JYK25J75L3pccMf B0iYHjn34ULiWo2/9HsEZH5dgUc1UTI8DY+hA3J9QtwAIPmDue29hysINioeKkZ1/J7g zWV28gTKrC3qUsC+GsT/dxYvsYeUfIg5KhqGPtPVWRWybxeWaYwXA3AX/C7bP5jOeTWY 82+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792067589; x=1792672389; 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=nvF0af+VuEpF2w4gUxax4o5sROQ0UEvX8+kiusy4yc4=; b=OvCn6vLi1wsef3MyWYo+cPmJ/A0L45a88lG8ICSm6S6Oe73Y5I97HJtDTM/LcAdBwE w/pVURBndXltW7RQdlMJNPClUSQH8yxFp7Flnz8wyN3IuoZVD8IYMBOIH1cgpal5/hok B1Yc7DzYXO9e41Ilg3TZC7xDBvzcZHrYMdf5JY+kTY2NnEPrHPlfFjQiPCxf6kmgo3t5 vTqdhuv2NQRD+gCdCW6X0klhrtfyIkKoMAoGxESrGgfpQUfFxMEhc6jWN6vTHkUFK8El eLKXHE74h7jASnYqZUVyc9wppEx/CejEAMjUb4iL6QWnLwPoV3vjsqoFUlBMSaST2GEH eKkA== X-Forwarded-Encrypted: i=1; AKwUvBwKejE0INitfqJcuPe2yTgucloBkoidjJlJzRWTNrLGa15SxYEMHpsjTxYcTSmzlA+1qrS3MytTUqo=@lists.xenproject.org X-Gm-Message-State: AFq9FYImgvMrWllugNhGBj9Cjcca9cbu3s1cp6H9xNlv5oZMxDwaUhYX UEwVzcHAGhuh4v7p2s/kmyp2dDrfcU0ZFbma4F0AWA3Uyj2bqdCag16rgquiq4LDpA== X-Gm-Gg: AYBFou0XVtYam64DizTZSggADy0Ez+AZHFQKTUQMXzLxl9gRfXfTmMp8tAACD78HSPD CdJEHtZytgXXmiVkR0qF9LMKEPKsa1PfXYpRYKhTEMxwrA2oOcwxGJei0/e67LrM/OpuUTyp1kM Xvo68ncOhiUYM1N7t3hKilvBOIo+BReyyJlL/gZFLygzTge99yCLvyCpim9mVxCh8Uas9K/+WyD shE7PhwihF7KylrxGhQcEbUsK/qq1wIIgaE0aaf9WE0tifjHN8rTK8OnX1ztLfams3HrUqhepFa 9Y76Teha68/dN94HxG1EJ9cq8Wg1LMYDs9OSDWTb7/0eVJpcZBcr85alFNXsQFsmk2DzL98hrLD vntfGdet5Af00c5cdzTT/pGEWxB6sjqMTKjelZp/13jZo4JZZlDx5+jPLv4gUfAE+iKFfXv8ISS fXvpAuYLnopE/gyO6QY7Dif6VHFF9rHY7k99z5tI1ggK/VM1+sx4/5OK6guMIB2GIx+0gYdoHTJ Kbd9rwWkPMRy/muXL9mbcHvX/9uRqVscnlJbfthph/9qy/wMJeig7rnKiSVs+E= X-Received: by 2002:a05:600c:8509:b0:4a1:7d9b:d4ae with SMTP id 5b1f17b1804b1-4a18e47a8cdmr359963735e9.5.1792067588776; Thu, 15 Oct 2026 05:33:08 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 14:33:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] SUPPORT.md: State that ATS is unsupported To: Jason Andryuk 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: <20261014135143.34220-1-jason.andryuk@amd.com> <20261014135143.34220-3-jason.andryuk@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: <20261014135143.34220-3-jason.andryuk@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1792067589-FD40B77B-604E36D5/10/78276251493 X-purgate-type: spam X-purgate-size: 563 On 14.10.2026 15:51, Jason Andryuk wrote: > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -96,6 +96,9 @@ For the Cortex A77 r0p0 - r1p0, see Errata 1508412. > Status, ARM SMMUv3: Tech Preview > Status, Renesas IPMMU-VMSA: Supported, not security supported > > +PCI Address Translation Services (ATS), enabled by the ats= command line > +option, is not security supported. > + > ### ARM/GICv3 > > GICv3 is an interrupt controller specification designed by Arm. Wouldn't this better go in the "x86/PCI Device Passthrough" section? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 12:55:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 12:55:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450488.1665950 (Exim 4.92) (envelope-from ) id 1xHKzK-0002l5-OU; Thu, 15 Oct 2026 12:55:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450488.1665950; Thu, 15 Oct 2026 12:55: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 1xHKzK-0002ky-Ke; Thu, 15 Oct 2026 12:55:14 +0000 Received: by outflank-mailman (input) for mailman id 1450488; Thu, 15 Oct 2026 12:55:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHKzJ-0002ks-7j for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 12:55:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHKzI-008zPA-KW for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:55:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0cd2d-bab6-0a2a0a5309dd-0a2a4503978c-14 for ; Thu, 15 Oct 2026 14:55:12 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0cd30-fae8-0a2a45030019-d155802fe96e-3 for ; Thu, 15 Oct 2026 14:55:12 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49ff680331aso22866375e9.3 for ; Thu, 15 Oct 2026 05:55: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-48de0aaaaebsm18905217f8f.14.2026.10.15.05.55.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 05:55: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=1792068912; x=1792673712; 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=2EKUabh9FMcJ3nXmTIrVl/9Lb0v92hc53ZeYGVJrSt8=; b=XtIUsBVOssKV6tFc/vd4vkk5+3qmbaS9/4W5v479yFSw3loM5722WElFr2NLAuvT5I vIcsQUwVRYM2yCvsKHgHV02OIybRYQUqaztCPQ0FI0MhYaRjIjAM/jYdRbt8G6idLkVZ X6JDKJ7mDfv/VK77ru/xrZZ3iNILVI1B0jju7NR/syCxqvA0KSLIeOqkxeoGnhNN3Mp5 oqFDzQgXJ4fFLUZxJltNQsuFjwV5FB25HpS94DAVEpdlcfkooielVkyrMcrG8H6Sc370 uByuOBVF926h0aJ2X+vNRMk6nACNK66zbUNyUABtUcmM18Tyts1xp1l3xhtYeESyWU3a ld1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792068912; x=1792673712; 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=2EKUabh9FMcJ3nXmTIrVl/9Lb0v92hc53ZeYGVJrSt8=; b=lv3RQ43py68mZcwQKFD5IcQ3fVQJzQs6NZ0kAdn0nxoQ68cPy5Lm48c+MZQwjdaU4Y k04OBPKtgdgeyV9VfOU4iSWSwRJb2hbQyMZmE0xHMtmlK/R3dGmm1LY8qu/FI07c37K1 egBvEpVrQE6Sivrov8ZcmjpvQAcvdIiGbKf7P7IUvrMxClJTN1MMVthMrY5AcT2Dj78v GeVehvZyR5oNpGug8lW8M+rIKA3wZQFpMc/Ip6MF8Z7cotQKlPFwF8H45+xAehOS7yHS C5nlo8Hifp2shE74Egvyv5eCV1J9NCUcJGhNmgiwcyVug2UGrvg99WiuDjf44khkIrb/ 4TmA== X-Forwarded-Encrypted: i=1; AKwUvBzJ2pkX4w9lI/49n7gm2OQjhF0XyiHAyl8X2GATJuNpyaGamNZIAr4GmMCL6PyK2vWCsVdCSKqv3iE=@lists.xenproject.org X-Gm-Message-State: AFq9FYKFSZUarL5U/vVwyVjUqtUJDKrtMehb7jY4WFTDIQ6haby5lg5f 40B9n0ytzYk3NxXI2hxut6RXxkTIgNQQarA+6oaJTHDV+E25uGwhHySBJBD8N1vsqg== X-Gm-Gg: AYBFou2pX1rSCs7lDRgJ4DrpiRg8qngJKzCNsqsL55ifSUcbrS0r+elkLjTMWCefdPE hcBi+lmHyeP1OCFRVGLTQjQoZI1IJl8I4PJ7ssIFxeLB9asO60a9YL+CI3Fmr25rkK8eEpuYs9k UkrArtaMGWDu3SWniKrQwRbNIZtx8gpeKhEjQv2jw0Bj4loiIoY4+8OokW4pQ3SqekJCDtbI3kf EpxlqtO6uM9x6oEKB42w0g3HU9IPJB1mIntyXritcsTG8Qye2PD+i7mR29n1ONXq7YS4U1v75Ee CJPpcWrRKw4G8gDLsWM5RoCnJKMpWUH6DWB/N3XlP+E6c9BPs3r7rHhl4P9/lyskk+BA6GatFLb AnuEB4OmN0NmZ5DrBiLDbK6PGaE+yT0nprO6qc16yi5+3dqNXD/zJYn65Dv71/H8vPzI5GHKKuk F7PG2Y9+8+0wcYzDJ/TdBaBpwMEJ9pjHaK/Q0uai+Dr8W8A/seFhmN10N1gJDSZzdn4+oPWG/0s xlHDvnU68sZlKuQsqU1TMA8zgfKAj1BoiADBsD/19LAQ39BDzuB053yLF0CMAw= X-Received: by 2002:a05:600d:82c1:b0:4a1:6a10:4dc8 with SMTP id 5b1f17b1804b1-4a1bd175fa1mr81604925e9.28.1792068911984; Thu, 15 Oct 2026 05:55:11 -0700 (PDT) Message-ID: <3d08be0a-11a3-4152-acc9-8ea66451466d@suse.com> Date: Thu, 15 Oct 2026 14:55:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] libxl: `xl shutdown ""` powers off the host To: msd-xenproject.org@msd.im Cc: anthony.perard@vates.tech, jgross@suse.com, 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-33051d/1792068912-76CF84E9-EAF7357A/10/78276251493 X-purgate-type: spam X-purgate-size: 3002 On 15.10.2026 13:54, msd-xenproject.org@msd.im wrote: > Hi, > > An empty domain qualifier seems silently resolved to domain 0, > so a command such as : > > xl shutdown "" > > does not fail with an error: it shuts down dom0, which powers off the > whole host. > > Impact > ------ > > We ran `xl shutdown ""` on a Debian host running Xen 4.20. > Instead of printing an "invalid domain identifier" error, xl asked dom0 to shut down, and the > physical server powered off, taking every guest down with it. > > The same input is easy to produce by accident, for example from a shell > script with an unset variable: > > xl shutdown "$VM" # VM is empty or unset I agree this isn't good behavior. > The diagnostic and patch is proposed assisted by Anthropic Claude. > I haven't tested it, it was generated when I was trying to understand if the shutdown behavior is normal. > I just hope it will help you understanding faster. > > > Cause (Anthropic Claude) > ------------------------ > > In tools/libs/light/libxl_utils.c: > > int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, const char *name, > uint32_t *domid) > { > int i, rv; > for (i=0; name[i]; i++) { > if (!CTYPE(isdigit, name[i])) { > goto nondigit_found; > } > } > *domid = strtoul(name, NULL, 10); > return 0; > ... > > With name == "", the loop body never runs, so the string is treated as > "all digits". strtoul("", NULL, 10) returns 0 without any error > detection, and the function returns success with *domid == 0. > find_domain() in tools/xl/xl_utils.c then sees rc == 0 and carries on > with domid 0. > > Every xl subcommand that resolves its argument through find_domain() > (destroy, reboot, pause, ...) is affected in the same way. > > > Proposed fix (Anthropic Claude) > ------------------------------- > > Reject the empty string up front, using the same error code as > libxl_name_to_domid() already uses for an unknown name. > > --- a/tools/libs/light/libxl_utils.c > +++ b/tools/libs/light/libxl_utils.c > @@ -92,6 +92,10 @@ int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, const char *name, > uint32_t *domid) > { > int i, rv; > + > + if (!name[0]) > + return ERROR_INVAL; > + > for (i=0; name[i]; i++) { > if (!CTYPE(isdigit, name[i])) { > goto nondigit_found; Instead of returning a error, this case may better be wired to also invoke libxl_name_to_domid(). Unless of course it is well-defined that domain names must be of non-zero length. I'd also suggest to go further and delete the loop. Why would we re-do what strtoul() is going to do anyway? All we need to do is pass non-NULL as its middle argument, and then look at what we get back. Care to submit an actual patch? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 13:11:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 13:11:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450510.1665958 (Exim 4.92) (envelope-from ) id 1xHLFL-0007Ew-4N; Thu, 15 Oct 2026 13:11:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450510.1665958; Thu, 15 Oct 2026 13: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 1xHLFL-0007Ep-1l; Thu, 15 Oct 2026 13:11:47 +0000 Received: by outflank-mailman (input) for mailman id 1450510; Thu, 15 Oct 2026 13:11:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHLFJ-0007Ej-IT for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:11:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHLFI-002iqT-R4 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:11:44 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0d109-bab6-0a2a0a5309dd-0a2a4504a8fa-20 for ; Thu, 15 Oct 2026 15:11:44 +0200 Received: from [52.101.193.30] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0d10e-b57f-0a2a45040019-3465c11e9d9b-3 for ; Thu, 15 Oct 2026 15:11:44 +0200 Received: from BN0PR02CA0010.namprd02.prod.outlook.com (2603:10b6:408:e4::15) by IA1PR12MB6329.namprd12.prod.outlook.com (2603:10b6:208:3e5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Thu, 15 Oct 2026 13:11:35 +0000 Received: from BN3PEPF00022BC0.namprd04.prod.outlook.com (2603:10b6:408:e4:cafe::6) by BN0PR02CA0010.outlook.office365.com (2603:10b6:408:e4::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Thu, 15 Oct 2026 13:11:35 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF00022BC0.mail.protection.outlook.com (10.167.248.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Thu, 15 Oct 2026 13:11:35 +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.53; Thu, 15 Oct 2026 08:11:29 -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.53 via Frontend Transport; Thu, 15 Oct 2026 08:11:27 -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=UNuJ+TJjBgSkVEBxh7raLlwXK7TxpCACzRzWvwxa56OcTpdCUl8Solc1iH+GU8/zNSZQlg7g/Bno/kTtBfWW6Rm/CyyQ07U/pYkyuV+R0QVmH7n1rz7lF1asm4R7veraBv/0Z8nVL7Ha9lz4iFLV3AZVapvHphPt/AM5RT1VlwQXwAERmAthINiRjJwREOHB/591jMHGVqQT5CHqehZDSkkg34a+WzFj63VudXjjBBIlxsY3WMsS4bhROv+X4PFlzTeGIKXHeFJrsed45QfU8iVT++g/UuIYahCiMWopPjlfuQCgKNnEKGQ0ps8GtYJ/7WY405f2loASRVl1nFB6Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dwKOfQRWkzCkLa5s6exp88jnOwqDkCXQ0jfB372DrfI=; b=oyiezjzj7ddCOBQL32bTaRBBRdfJc1uKl05o8u3ARL8f2POVw9p3her1rFgOGZqrnT1TLKBUTmrGAERO0vIh4ae/b/CkHfRfquDE2swr/ZiiiqSjHPn3Ozbp87MEtXCkhs79oY4HNZ26Kq4F0qLeELaawkyWTEaId85z2moIouhqFcBd7QnKULoHTj8uHZBaI2z7tTaEUWQqVahp0TvNzgjrFO918bh9RlV8abT6FdahNux87WuzPbN6Qf6mquDHrIEipdrvMJ5rfmvgJUmh4AxDJj24t8fDE4y/cV5keDoMFkgJfDfvoUIjfa28ES0Mh6sWGmhh/XPsjc3wDJi26A== 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=dwKOfQRWkzCkLa5s6exp88jnOwqDkCXQ0jfB372DrfI=; b=jdVnEVJgSOfrMfnG2jXltp9uQYxSgi5E/rYjv9590YqjqJDNDpDOEtFdaSR5N35VP18ZYNPyMhFhoR/RR96a3WAVIGAffBWSyVt8iEaGInFCcscLVGT0gKqq5ETePIKrWOB7+PIspClSUbs1T9xhKjtlmzmovaVe9O2DQJ18aMQ= 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: <1471a2e8-4798-4a91-874a-41947c825b27@amd.com> Date: Thu, 15 Oct 2026 15:11:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/device-tree: add a helper to dump an FDT in DTS-like format To: Oleksii Kurochko , CC: Andrew Cooper , Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20261015082845.19511-1-oleksii.kurochko@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261015082845.19511-1-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BC0:EE_|IA1PR12MB6329:EE_ X-MS-Office365-Filtering-Correlation-Id: 07f6ac2b-3084-49ad-b452-08df2abdd731 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|7416014|376014|36860700016|82310400026|56012099006|11063799006|261009223027099003|22082099003|10067099003|18002099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: TuiMxFOot2/NS1dFlpCuQEkhPNIHQeVmoLkyYPqyRDa27dBahK0+dP9mbKV8obUCJ2I/qBUk98CmJ3Y+mzK2pLpEeU6DRAJTRwZcP7MGUfMlYqp4axL0RkfDp16d2lCBpiC+23eWUNqxPUQIyps3mh6SiNo0BC8OSJxRi3SBHOlKeDBd2+QDFAVXSP933yz+0MBls06XxC/RX1DyIr8MSQZDRFjY2OUMGhx06EsD7WqyLl4IYVq07JHcvWpL4xEN+QJwVi+vMjZtb1Jbh8lSzSqlcin0CWHWUkfKABz5YuW+d0u7Fr8cBvwo0M9A1linFwExK6Iy4sw8mKB8mplTiFn/ydSwxCblO647negOrRAjWx7BTFE/KElJHn4W1YdaEVYyFMOJJBFk0nV06Lj8cXh5040U5KhKtda1i6T2f6N9yA05cYYdwNW16Jws6sMnTCTto1BV758OdlPdwkHmfE8Kti1He5dixN7l4u2uCuamoxu8BXFr3oTplRzoHzxwT7lzAoatrQlO1Z2lY2c08M5Hb+siucwmGxQyG+81H8br4jcS6YNI3bgreui5kXatiC0LTAW0TPXJsZFfHC1irk2X7x4vbNWTUHLm2m5R9Cbj1LjWqZimQphpzHrVI/kPxz70ivSAoFbkarbLjeszXjtr37bzjhRyVs30zZFLqDcVnymx3mq+rZz+VPfW6srHIH+nVrY0gk69RoK1maRycA== 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)(7416014)(376014)(36860700016)(82310400026)(56012099006)(11063799006)(261009223027099003)(22082099003)(10067099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: w5B3SfkkOswvUkIGnZ2MWoMkJ4vASEq5tfc0WbUy9uBkEBJjs+9Op5uTmuLNDj1ojxRXr6i8jknDer13qQSXNnSFFNU1oKTxR/6iTYrDBTzWbn84Jtc2DRdSRxdQxv7Bgx7ZzF1CXV4r2ICYmbJ82uN7hnjosiDvtVgv6BxEULqONuTSenaymtPrsalhWXxC35BsJd7ZRVuy7PT1uVeV+4olV0MF+7GTT9/zrfaCBD8yMVBtTOwh4oG1+KzLoKjg/pazF003iVSqB1/UiZDrbYeVIydDTjEQa2klIv3X7odgfPYF+Y6LAfFjPMgY1XfaPbZOHzQuxZZuzCzerKQYhpnYcV0IqAt21wwuW7+L8mK5GSjRoxla7AZgyLikRHi3rAuYw9tTd7HX3G1w5X+giFB6G/jUSQ8Ama+rKDhn8E/pdKpS5QuW2VpSL7zX2cGR X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 13:11:35.6992 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 07f6ac2b-3084-49ad-b452-08df2abdd731 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: BN3PEPF00022BC0.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6329 X-purgate-ID: tlsNG-ebf023/1792069904-583C0B50-15A99D4E/10/73395122804 X-purgate-type: spam X-purgate-size: 1092 On 15-Oct-26 10:28, Oleksii Kurochko wrote: > The device tree Xen builds for dom0/hwdom or for a dom0less domain is > only ever consumed by the guest, so a mistake in it surfaces as an > obscure failure inside the domain, far away from the code which > produced the tree. > > Add device_tree_dump(). The output follows dtc's format so that a dump > can be diffed against the source DTS or fed back to dtc; the value > formatting heuristics are ported from dtc's utilfdt_print_data() for > that reason. The walk itself goes through libfdt rather than decoding > the tag stream by hand as dtc's fdtdump does. > > Dumping a whole tree is only useful while debugging and costs both code > size and a lot of console output, so it is put under its own option, > CONFIG_DEVICE_TREE_DUMP. It is separate from CONFIG_DEVICE_TREE_DEBUG > because the generated tree is often all that is needed, without the rest > of the device tree debug messages. > > Signed-off-by: Oleksii Kurochko Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Thu Oct 15 13:17:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 13:17:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450528.1665983 (Exim 4.92) (envelope-from ) id 1xHLKv-000891-0v; Thu, 15 Oct 2026 13:17:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450528.1665983; Thu, 15 Oct 2026 13:17: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 1xHLKu-00088u-UN; Thu, 15 Oct 2026 13:17:32 +0000 Received: by outflank-mailman (input) for mailman id 1450528; Thu, 15 Oct 2026 13:17:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHLKu-00088n-Bd for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:17:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHLKt-0094OD-OK for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:17:31 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0d255-2eae-0a2a0a5409dd-0a2a450ae5f0-44 for ; Thu, 15 Oct 2026 15:17:31 +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 6ad0d26b-f2d2-0a2a450a0019-b9ff1c2293cf-3 for ; Thu, 15 Oct 2026 15:17: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a13fb5eee80008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 15 Oct 2026 13:17:30 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 3508080120; Thu, 15 Oct 2026 15:17:29 +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=jAbBj+wsBsZDd6u/2JMsKbdYrnUVx/b1Z4ZsIkWPV5E=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=noNbtlJ3i7MgFTTxo0yOWnlAFus/5ORyJZsSVtFbdi0u60w42UOohVb+gFq7dT4itFiogW3vB MqNAnN0RFhcK6wrlvbl38nWLWCWwZm5Ja+jJpYagXb8PkmsjigKQcDAtqrxP5tiQIz8S3LwpjHs 7cXwCBQLieaOwzdKQvO83qsa16ZtgmnmUCPW7L4yDsqUUaOVvt8GBxZZJe0GIlKUav1l+DQl8o/ Qi2yGhy7RJBiWUFB5G9px0SKCZB4TEG+Se+YAZ/SRKAYtqUtbMYs5Nr3/Q+eoTRu4kAb40NAhbN 9viVtVnAFcFNeWas9yuGiM/DRcsZyrmLmKGKsEpwOPDw== X-Zone-Loop: 2a2ead255c93d38a1fb26af7852a8300b078b9f58a86 x-campaign-type: default x-transaction-id: cbedb5ed-7c80-4c28-8aab-cdc95aff35ac x-swg-uid: 01-c7ca2cc6-d784-4a00-b39c-fed3b830c512 X-Mailer: Sweego Message-ID: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> x-swg-bid: 1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Doug Goldstein , Julian Vetter Subject: [PATCH 0/3] Add QEMU ARM tools-tests Date: Thu, 15 Oct 2026 15:17:23 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.241.d5e31cb4a1135668.1a13fb5ec71.9b335bfea2028a15=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792070249585 X-purgate-ID: tlsNG-4011c0/1792070251-59DDFCFC-0B55000A/0/0 X-purgate-type: clean X-purgate-size: 2241 ---=Part.241.d5e31cb4a1135668.1a13fb5ec71.9b335bfea2028a15=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Michal and Andrew, as promised the tests=2E I saw that neither of the 3 tests you mentioned failing (test-mem-claim, test-paging-mempool and test-resource) actually runs on ARM=2E So, I have fixed them in regards to my other patchset (explicitly specifying a GIC version), but I also fixed the issue with the page pool=2E Each test gained a call to xc_set_paging_mempool_size(), so they don't fail after the domain creation=2E Then I have added an entry for the CI to run these tests under QEMU in the CI=2E Andrew I have slightly modified your test-paging-mempool=2E Because, as far as I understand only the test-p2m-relocate-memory actually needs an IOMMU, all the other tests run without one=2E So, I added a check for XEN_DOMCTL_CDF_iommu and skip only that test=2E I can also leave this test set alone if you prefer and skip it in its entirety=2E The other alternative would be to start QEMU with a '-M iommu=3Dsmmuv3' and compile XEN with CONFIG_EXPERT=3Dy and CONFIG_ARM_SMMU_V3=3Dy=2E Then we could run all these tests on ARM in QEMU as well=2E But this would require some more modifications to the XEN config for those tests=2E Signed-off-by: Julian Vetter --- Julian Vetter (3): tools/tests: fix domain creation on ARM tools/tests: don't skip all of test-paging-mempool without an IOMMU automation: run tools/tests on arm64 under QEMU automation/gitlab-ci/test=2Eyaml | 23 ++++ automation/scripts/qemu-tools-tests-arm64=2Esh | 105 ++++++++++++++++++ tools/tests/mem-claim/test-mem-claim=2Ec | 15 +++ =2E=2E=2E/paging-mempool/test-paging-mempool=2Ec | 48 +++++++- tools/tests/resource/test-resource=2Ec | 21 ++++ 5 files changed, 211 insertions(+), 1 deletion(-) create mode 100755 automation/scripts/qemu-tools-tests-arm64=2Esh --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.241.d5e31cb4a1135668.1a13fb5ec71.9b335bfea2028a15=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 15 13:21:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 13:21:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450536.1665994 (Exim 4.92) (envelope-from ) id 1xHLOt-0001Yo-Hq; Thu, 15 Oct 2026 13:21:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450536.1665994; Thu, 15 Oct 2026 13: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 1xHLOt-0001Yh-DJ; Thu, 15 Oct 2026 13:21:39 +0000 Received: by outflank-mailman (input) for mailman id 1450536; Thu, 15 Oct 2026 13:21:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHLOs-0001Yb-Cw for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:21:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHLOr-002bdR-Lm for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:21:37 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0d361-e002-0a2a0a5209dd-0a2a4504d01a-2 for ; Thu, 15 Oct 2026 15:21:37 +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 6ad0d361-b57f-0a2a45040019-b9ff1c22b6af-3 for ; Thu, 15 Oct 2026 15:21: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 1a13fb9a01f0008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 15 Oct 2026 13:21:32 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 3147382B1B; Thu, 15 Oct 2026 15:21: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; 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=96wIn1uekCRs9P1gGem/hdVbYyuKamo638+EoyoEx0Y=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Sskf1gc4jRQcimJHUYWYuhK6yxZ4wofbQq1DsvsXdk2P1QPvLdxF/DjobP+MvWNqwJvL7NosC OMJScnnNFnRv20oSpUV3juqIhS2yBaB6roBLR8pXISH0+i5zHl47c9LiyGbjxIzqXRP2BEvOuGN CXnzscEECAw0KeGXg3r5zsRVT47qhv0MPjku+wSlB+33ReWaNa5vV+MINIwgONCfe/6Xpx1IYTc aMyd7mxjbSXDp734NZxBR9ZBOymXfmyIN7/DPir1U/lmY5RCuF2PF4c0ty8KqhjXqgeRfIunhyF 8xECk84OdfhoFmfRQhVaIbyN4/m6VcZOctqM+BTxce0A== X-Zone-Loop: 09c97141a24b1fbaf35086021fae41559d27390f4c0c x-campaign-type: default x-transaction-id: b9a5f416-93d6-407c-b2e1-a7364fa15895 x-swg-uid: 01-7d625f9f-cafd-4b03-b761-476a36b1c966 X-Mailer: Sweego Message-ID: <1792070492.8631fc262581453bbf619ec5b2062170.1a13fb9a01f0008425@vates.tech> x-swg-bid: 1792070492.8631fc262581453bbf619ec5b2062170.1a13fb9a01f0008425 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Doug Goldstein , Julian Vetter Subject: [PATCH 1/3] tools/tests: fix domain creation on ARM Date: Thu, 15 Oct 2026 15:21:21 +0200 In-Reply-To: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> References: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.242.9bbe1338220ab1a0.1a13fb99ddf.96ee2834d2b33a54=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792070491615 X-purgate-ID: tlsNG-ebf023/1792070497-C12DCB50-08341C57/0/0 X-purgate-type: clean X-purgate-size: 7856 ---=Part.242.9bbe1338220ab1a0.1a13fb99ddf.96ee2834d2b33a54=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The tests test-mem-claim, test-paging-mempool and test-resource create ARM domains with xen_arch_domainconfig set to zero, i=2Ee=2E, gic_version XEN_DOMCTL_CONFIG_GIC_NATIVE, which has been removed=2E Domain creation in test-mem-claim and test-paging-mempool fails, and test-resource skips its ARM configuration=2E So, pick the GIC version from the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits reported by XEN_SYSCTL_physinfo instead, the same way libxl does=2E Use GICv3 if available, else GICv2, else fail the test=2E But, even with a valid GIC version, the tests don't properly run, because ARM domains start with an empty P2M pool=2E The toolstack calls libxl__domain_set_paging_mempool_size() in libxl__arch_domain_create() to provision the page pool=2E But these tests don't go through the toolstack and call domain_create() directly=2E To fix this, call xc_set_paging_mempool_size() just like the toolstack does=2E Signed-off-by: Julian Vetter --- tools/tests/mem-claim/test-mem-claim=2Ec | 15 ++++++++ =2E=2E=2E/paging-mempool/test-paging-mempool=2Ec | 34 ++++++++++++++= ++++- tools/tests/resource/test-resource=2Ec | 21 ++++++++++++ 3 files changed, 69 insertions(+), 1 deletion(-) diff --git a/tools/tests/mem-claim/test-mem-claim=2Ec b/tools/tests/mem-cl= aim/test-mem-claim=2Ec index 69dc99cfdd=2E=2Ec21d791f0f 100644 --- a/tools/tests/mem-claim/test-mem-claim=2Ec +++ b/tools/tests/mem-claim/test-mem-claim=2Ec @@ -9,6 +9,7 @@ #include #include #include +#include #include =20 static unsigned int nr_failures; @@ -72,6 +73,13 @@ static void run_tests(void) create=2Eflags &=3D ~XEN_DOMCTL_CDF_hvm; create=2Earch=2Eemulation_flags =3D 0; } +#elif defined(__arm__) || defined(__aarch64__) + if ( arch_capabilities_arm_gic_v3(physinfo=2Earch_capabilities) ) + create=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3; + else if ( arch_capabilities_arm_gic_v2(physinfo=2Earch_capabilities) = ) + create=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2; + else + return fail(" No supported GIC version\n"); #endif =20 rc =3D xc_domain_create(xch, &domid, &create); @@ -84,6 +92,13 @@ static void run_tests(void) return fail(" Failed to set maxmem: %d - %s\n", errno, strerror(errno)); =20 +#if defined(__arm__) || defined(__aarch64__) + rc =3D xc_set_paging_mempool_size(xch, domid, MB(1)); + if ( rc ) + return fail(" Failed to set paging mempool size: %d - %s\n", + errno, strerror(errno)); +#endif + printf(" Created d%u\n", domid); =20 /* diff --git a/tools/tests/paging-mempool/test-paging-mempool=2Ec b/tools/te= sts/paging-mempool/test-paging-mempool=2Ec index 0e03e2e4a0=2E=2E020ebd5f8f 100644 --- a/tools/tests/paging-mempool/test-paging-mempool=2Ec +++ b/tools/tests/paging-mempool/test-paging-mempool=2Ec @@ -9,6 +9,7 @@ #include #include #include +#include #include =20 static unsigned int nr_failures; @@ -24,6 +25,8 @@ static xendevicemodel_handle *dh; static xenforeignmemory_handle *fh; static uint32_t domid =3D DOMID_ANY; =20 +static xc_physinfo_t physinfo; + static struct xen_domctl_createdomain create =3D { =2Eflags =3D (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap | @@ -44,7 +47,7 @@ static uint64_t default_mempool_size_bytes =3D #if defined(__x86_64__) || defined(__i386__) 256 << 12; /* Only x86 HAP for now=2E x86 Shadow needs more work=2E = */ #elif defined (__arm__) || defined(__aarch64__) - 16 << 12; + 0; #endif =20 static int test_paging_mempool_size(void) @@ -80,6 +83,14 @@ static int test_paging_mempool_size(void) * Populate the domain with some RAM=2E This will cause more of the = mempool * to be used=2E */ +#if defined(__arm__) || defined(__aarch64__) + size_bytes =3D 16 << 12; + rc =3D xc_set_paging_mempool_size(xch, domid, size_bytes); + if ( rc ) + return fail(" Fail: set mempool size: %d - %s\n", + errno, strerror(errno)); +#endif + old_size_bytes =3D size_bytes; =20 rc =3D xc_domain_setmaxmem(xch, domid, -1); @@ -274,6 +285,11 @@ static int test_p2m_relocate_memory(void) GFN_PAIR(GFN_4M - 32, 32), GFN_PAIR(GFN_4M, 32)); =20 rc =3D xendevicemodel_relocate_memory(dh, domid, 32, GFN_4M - 32, GFN= _4M); + if ( rc && (errno =3D=3D EOPNOTSUPP || errno =3D=3D ENOSYS) ) + { + printf(" Skip: %d - %s\n", errno, strerror(errno)); + return 0; + } if ( rc ) return fail(" Fail: relocate memory: %d - %s\n", errno, strerror(errno)); @@ -370,6 +386,22 @@ int main(int argc, char **argv) if ( !fh ) err(1, "xenforeignmemory_open"); =20 + rc =3D xc_physinfo(xch, &physinfo); + if ( rc ) + err(1, "Failed to obtain physinfo"); + +#if defined(__arm__) || defined(__aarch64__) + if ( arch_capabilities_arm_gic_v3(physinfo=2Earch_capabilities) ) + create=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3; + else if ( arch_capabilities_arm_gic_v2(physinfo=2Earch_capabilities) = ) + create=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2; + else + { + fail(" No supported GIC version\n"); + goto out; + } +#endif + rc =3D xc_domain_create(xch, &domid, &create); if ( rc ) { diff --git a/tools/tests/resource/test-resource=2Ec b/tools/tests/resource= /test-resource=2Ec index 236da0dcd4=2E=2E2392281f76 100644 --- a/tools/tests/resource/test-resource=2Ec +++ b/tools/tests/resource/test-resource=2Ec @@ -7,6 +7,7 @@ #include #include #include +#include #include =20 static unsigned int nr_failures; @@ -213,6 +214,16 @@ static void test_domain_configurations(void) continue; } } +#elif defined(__aarch64__) || defined(__arm__) + if ( arch_capabilities_arm_gic_v3(physinfo=2Earch_capabilities) ) + t->create=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3; + else if ( arch_capabilities_arm_gic_v2(physinfo=2Earch_capabiliti= es) ) + t->create=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2; + else + { + fail(" No supported GIC version\n"); + continue; + } #endif =20 rc =3D xc_domain_create(xch, &domid, &t->create); @@ -236,6 +247,16 @@ static void test_domain_configurations(void) goto test_done; } =20 +#if defined(__aarch64__) || defined(__arm__) + rc =3D xc_set_paging_mempool_size(xch, domid, MB(1)); + if ( rc ) + { + fail(" Failed to set paging mempool size: %d - %s\n", + errno, strerror(errno)); + goto test_done; + } +#endif + rc =3D xc_domain_populate_physmap_exact( xch, domid, ARRAY_SIZE(ram), 0, 0, ram); if ( rc ) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.242.9bbe1338220ab1a0.1a13fb99ddf.96ee2834d2b33a54=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 15 13:21:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 13:21:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450537.1666002 (Exim 4.92) (envelope-from ) id 1xHLP1-0001p1-NI; Thu, 15 Oct 2026 13:21:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450537.1666002; Thu, 15 Oct 2026 13:21: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 1xHLP1-0001or-Jr; Thu, 15 Oct 2026 13:21:47 +0000 Received: by outflank-mailman (input) for mailman id 1450537; Thu, 15 Oct 2026 13:21:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHLP0-0001oB-9g for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:21:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHLOz-00H2Lo-MV for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:21:45 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0d369-2eae-0a2a0a5409dd-0a2a4506862c-2 for ; Thu, 15 Oct 2026 15:21:45 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0d364-195a-0a2a45060019-b9ff1c12a6c9-3 for ; Thu, 15 Oct 2026 15:21: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 1a13fb9a2d20008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 15 Oct 2026 13:21:32 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id E48B380120; Thu, 15 Oct 2026 15:21: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; 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=994Z2AwKWVseJVTVA5qO9/fH1rz5FCL4yb2kHAul2yk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=b1N/fFfo6b6cDynfyBg8hW8DCVgEWd09ehjvzySyMD7E2wqE1wKTsSUypTdXFYJO3BjI6L8Ok 0YSEFTTpg4OZU8QsBa8zmqgsOUbEH96UeX6JPscjelOAJNnWOsazwqAHR7IjZa6QRm5P+sGJvBS breP2zv5jM+eiXAYCpMhxpwGVTPYggGEsg+P9aXGFa4qk86HeMws0FOD4v3PegTvOX29lEHl0nm Mb0MaQH7AfbCt5bp6AoYUG8Zw4HMm/5z1Ee0R6bXZv6zBYfOicVKSY+HTGO5PUtYMPWWKOavaRs dA+nLfaz7iCA1fV8kIKrx+08ut1NMwGyMpc3Fvs1sECQ== X-Zone-Loop: 34655567a8ecf9afa5472571a0597ec249929519557c x-campaign-type: default x-transaction-id: ac05a02e-0c3d-4c24-8924-2d725a96c0a7 x-swg-uid: 01-c861ec83-9fc3-4f5d-8c3b-4555e70dc5ad X-Mailer: Sweego Message-ID: <1792070492.8631fc262581453bbf619ec5b2062170.1a13fb9a2d20008425@vates.tech> x-swg-bid: 1792070492.8631fc262581453bbf619ec5b2062170.1a13fb9a2d20008425 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Doug Goldstein , Julian Vetter Subject: [PATCH 2/3] tools/tests: don't skip all of test-paging-mempool without an IOMMU Date: Thu, 15 Oct 2026 15:21:22 +0200 In-Reply-To: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> References: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.243.1e85d09599fae89b.1a13fb9a138.997487b0e243cbb3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792070492472 X-purgate-ID: tlsNG-16d1c6/1792070501-F6A7477B-2F7F85ED/0/0 X-purgate-type: clean X-purgate-size: 2391 ---=Part.243.1e85d09599fae89b.1a13fb9a138.997487b0e243cbb3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Commit 66c982a5d3 ("tests/paging-mempool: Extend to test P2M relocation") added XEN_DOMCTL_CDF_iommu to the test domain=2E On hosts without an IOMMU, Xen rejects the flag with -EINVAL and the whole test is skipped, including the paging mempool tests that do not depend on it=2E This is the case e=2Eg=2E for QEMU-based CI=2E Only set XEN_DOMCTL_CDF_iommu if XEN_SYSCTL_PHYSCAP_directio is reported, and skip just the relocation test otherwise=2E Signed-off-by: Julian Vetter --- tools/tests/paging-mempool/test-paging-mempool=2Ec | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/tools/tests/paging-mempool/test-paging-mempool=2Ec b/tools/te= sts/paging-mempool/test-paging-mempool=2Ec index 020ebd5f8f=2E=2Eb65a800d00 100644 --- a/tools/tests/paging-mempool/test-paging-mempool=2Ec +++ b/tools/tests/paging-mempool/test-paging-mempool=2Ec @@ -258,6 +258,12 @@ static int test_p2m_relocate_memory(void) */ printf("Test p2m memory relocation\n"); =20 + if ( !(create=2Eflags & XEN_DOMCTL_CDF_iommu) ) + { + printf(" Skip: No IOMMU, can't force continuations\n"); + return 0; + } + rc =3D xc_domain_populate_physmap_exact( xch, domid, ARRAY_SIZE(physmap), 9 /* order 2M */, 0 /* flags */, physmap); @@ -390,6 +396,14 @@ int main(int argc, char **argv) if ( rc ) err(1, "Failed to obtain physinfo"); =20 + /* + * XEN_DOMCTL_CDF_iommu is only needed to force continuations in the + * relocation test=2E Without an IOMMU, Xen rejects the flag, so drop= it + * and skip only the relocation test rather than all tests=2E + */ + if ( !(physinfo=2Ecapabilities & XEN_SYSCTL_PHYSCAP_directio) ) + create=2Eflags &=3D ~XEN_DOMCTL_CDF_iommu; + #if defined(__arm__) || defined(__aarch64__) if ( arch_capabilities_arm_gic_v3(physinfo=2Earch_capabilities) ) create=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3; --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.243.1e85d09599fae89b.1a13fb9a138.997487b0e243cbb3=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 15 13:21:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 13:21:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450538.1666011 (Exim 4.92) (envelope-from ) id 1xHLP4-00023E-2L; Thu, 15 Oct 2026 13:21:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450538.1666011; Thu, 15 Oct 2026 13:21: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 1xHLP3-000236-Ur; Thu, 15 Oct 2026 13:21:49 +0000 Received: by outflank-mailman (input) for mailman id 1450538; Thu, 15 Oct 2026 13:21:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHLP2-0001yX-IS for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:21:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHLP1-00H2NG-VP for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:21:47 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0d369-bab6-0a2a0a5309dd-0a2a4506863a-8 for ; Thu, 15 Oct 2026 15:21:47 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0d364-195a-0a2a45060019-b9ff1c12a6c9-4 for ; Thu, 15 Oct 2026 15:21: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a13fb9a6560008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 15 Oct 2026 13:21:33 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 9D40A82B1B; Thu, 15 Oct 2026 15:21: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: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=Tn8t9m1cvZ8eErG1VUqIp9xR9MpDpiXQ5lbx+uFtkS4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=mqWoI4ovIH+FA6P6x+uxVWeOrSpTArftGa6cfl1ChNQKmbubUMPo5jagpHKlao5WP/O5/rqkO c6CclcuDKj+9LGU09PEP/Q+/QH30Y6zJxHJD2xXPc6eFuNB8HcEpfGA4FUHelAQt0CLliWvzLqY OYeUWmcNM3vBrdC4/LeIQ+VdIhZpRqpPjtM8VEsmAhNwCmTnkfkIAci+rGCilvHC4sOKgA4XC9A Q4whSLVhTJ/zqU64deKNG/4hFSWrLeLflWfomeax50HXUBu3NHJ1Do8tfJYRAgLCATjGd8UqdWW pjD6Hppjf0ei3OUDh/eXqH3HxgGw/ZZdEfvW7VQYEESg== X-Zone-Loop: f25508eb7cb5979d8723953df0cf7c19a9382d65a856 x-campaign-type: default x-transaction-id: 1f2eb63c-f1ff-4eec-b7a2-39b2945b2cab x-swg-uid: 01-8ecdd480-5c83-415f-b315-504d28ebe569 X-Mailer: Sweego Message-ID: <1792070493.8631fc262581453bbf619ec5b2062170.1a13fb9a6560008425@vates.tech> x-swg-bid: 1792070493.8631fc262581453bbf619ec5b2062170.1a13fb9a6560008425 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Doug Goldstein , Julian Vetter Subject: [PATCH 3/3] automation: run tools/tests on arm64 under QEMU Date: Thu, 15 Oct 2026 15:21:23 +0200 In-Reply-To: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> References: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.244.cdffe731ec7b89e7.1a13fb9a3f1.14a6e143a9d8b062=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792070493169 X-purgate-ID: tlsNG-16d1c6/1792070507-F5A0C77B-5CEB33D9/0/0 X-purgate-type: clean X-purgate-size: 5590 ---=Part.244.cdffe731ec7b89e7.1a13fb9a3f1.14a6e143a9d8b062=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Currently the tests from tools/tests/* are only run on x86 hardware=2E So, add jobs running them in dom0 under QEMU on arm64, for both GICv2 and GICv3=2E Like qemu-smoke-dom0-arm64=2Esh, boot Xen and dom0 via U-Boot and ImageBuilder, and run them with automation/scripts/run-tools-tests=2E The JUnit output is printed on the console and extracted from the log afterwards, as there is no network access to the guest to get it=2E Signed-off-by: Julian Vetter --- automation/gitlab-ci/test=2Eyaml | 23 ++++ automation/scripts/qemu-tools-tests-arm64=2Esh | 105 +++++++++++++++++++ 2 files changed, 128 insertions(+) create mode 100755 automation/scripts/qemu-tools-tests-arm64=2Esh diff --git a/automation/gitlab-ci/test=2Eyaml b/automation/gitlab-ci/test= =2Eyaml index 96127995d7=2E=2Ef6110f764e 100644 --- a/automation/gitlab-ci/test=2Eyaml +++ b/automation/gitlab-ci/test=2Eyaml @@ -581,6 +581,29 @@ qemu-smoke-dom0-arm64-gcc-debug: - *arm64-test-needs - alpine-3=2E24-arm64-gcc-debug =20 +=2Eqemu-tools-tests-arm64: + extends: =2Eqemu-arm64 + artifacts: + paths: + - tools-tests=2Eserial + - '*=2Elog' + - tests-junit=2Exml + reports: + junit: tests-junit=2Exml + needs: + - *arm64-test-needs + - alpine-3=2E24-arm64-gcc-debug + +qemu-tools-tests-arm64-gcc-debug-gicv2: + extends: =2Eqemu-tools-tests-arm64 + script: + - =2E/automation/scripts/qemu-tools-tests-arm64=2Esh gicv2 2>&1 | tee= ${LOGFILE} + +qemu-tools-tests-arm64-gcc-debug-gicv3: + extends: =2Eqemu-tools-tests-arm64 + script: + - =2E/automation/scripts/qemu-tools-tests-arm64=2Esh gicv3 2>&1 | tee= ${LOGFILE} + qemu-smoke-dom0less-arm64-gcc: extends: =2Eqemu-arm64 script: diff --git a/automation/scripts/qemu-tools-tests-arm64=2Esh b/automation/s= cripts/qemu-tools-tests-arm64=2Esh new file mode 100755 index 0000000000=2E=2E0d82c0055a --- /dev/null +++ b/automation/scripts/qemu-tools-tests-arm64=2Esh @@ -0,0 +1,105 @@ +#!/bin/bash + +# Run the tests from tools/tests/* in dom0, under QEMU=2E +# +# Usage: qemu-tools-tests-arm64=2Esh gicv2|gicv3 + +set -ex -o pipefail + +test_variant=3D$1 + +case "${test_variant}" in + gicv2) gic_version=3D2 ;; + gicv3) gic_version=3D3 ;; + *) + echo "Unrecognised test_variant '${test_variant}'" >&2 + exit 1 + ;; +esac + +passed=3D"tools tests passed" +failed=3D"tools tests failed" + +# Dom0 rootfs +cd binaries +cp rootfs=2Ecpio=2Egz dom0-rootfs=2Ecpio=2Egz +cat xen-tools=2Ecpio=2Egz >> dom0-rootfs=2Ecpio=2Egz + +# test-local configuration +mkdir -p rootfs +cd rootfs +mkdir -p etc/local=2Ed root +cp -a =2E=2E/=2E=2E/automation/scripts/run-tools-tests root/ +echo "#!/bin/bash + +bash /etc/init=2Ed/xencommons start + +if /root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit=2Exml; then + result=3D\"${passed}\" +else + result=3D\"${failed}\" +fi + +echo '@@@ JUNIT BEGIN' +cat /tmp/tests-junit=2Exml +echo '@@@ JUNIT END' +echo \"\${result}\" +" > etc/local=2Ed/xen=2Estart +chmod +x etc/local=2Ed/xen=2Estart +find =2E | cpio -R 0:0 -H newc -o | gzip >> =2E=2E/dom0-rootfs=2Ecpio=2Eg= z +cd =2E=2E/=2E=2E + +qemu-system-aarch64 \ + -machine virtualization=3Dtrue \ + -cpu cortex-a57 -machine type=3Dvirt,gic-version=3D${gic_version} \ + -m 2048 -smp 2 -display none \ + -machine dumpdtb=3Dbinaries/virt=2Edtb + +# XXX disable pl061 to avoid Linux crash +fdtput binaries/virt=2Edtb -p -t s /pl061@9030000 status disabled + +# ImageBuilder +echo 'MEMORY_START=3D"0x40000000" +MEMORY_END=3D"0xC0000000" + +DEVICE_TREE=3D"virt=2Edtb" +XEN=3D"xen" +DOM0_KERNEL=3D"Image" +DOM0_RAMDISK=3D"dom0-rootfs=2Ecpio=2Egz" +XEN_CMD=3D"console=3Ddtuart dom0_mem=3D1024M console_timestamps=3Dboot" + +NUM_DOMUS=3D0 + +LOAD_CMD=3D"tftpb" +UBOOT_SOURCE=3D"boot=2Esource" +UBOOT_SCRIPT=3D"boot=2Escr"' > binaries/config +rm -rf imagebuilder +git clone --depth 1 https://gitlab=2Ecom/xen-project/imagebuilder=2Egit +bash imagebuilder/scripts/uboot-script-gen -t tftp -d binaries/ -c binari= es/config + + +# Run the test +rm -f tools-tests=2Eserial +export TEST_CMD=3D"qemu-system-aarch64 \ + -machine virtualization=3Dtrue \ + -cpu cortex-a57 -machine type=3Dvirt,gic-version=3D${gic_version} \ + -m 2048 -monitor none -serial stdio \ + -smp 2 \ + -no-reboot \ + -device virtio-net-pci,netdev=3Dn0 \ + -netdev user,id=3Dn0,tftp=3Dbinaries \ + -bios /usr/lib/u-boot/qemu_arm64/u-boot=2Ebin" + +export UBOOT_CMD=3D"virtio scan; dhcp; tftpb 0x40000000 boot=2Escr; sourc= e 0x40000000" +export BOOT_MSG=3D"Latest ChangeSet: " +export TEST_LOG=3D"tools-tests=2Eserial" +export PASSED=3D"${passed}|${failed}" + +=2E/automation/scripts/console=2Eexp |& sed 's/\r\+$//' + +# Extract the JUnit report from the console, dropping any interleaved Xen +# messages=2E +sed -e 's/\r\+$//' -e '1,/^@@@ JUNIT BEGIN$/d' -e '/^@@@ JUNIT END$/,$d' = \ + tools-tests=2Eserial | grep -v '^(XEN)' > tests-junit=2Exml + +grep -q "^${passed}$" <(sed 's/\r\+$//' tools-tests=2Eserial) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.244.cdffe731ec7b89e7.1a13fb9a3f1.14a6e143a9d8b062=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 15 13:30:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 13:30:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450561.1666020 (Exim 4.92) (envelope-from ) id 1xHLXO-0005n7-Po; Thu, 15 Oct 2026 13:30:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450561.1666020; Thu, 15 Oct 2026 13:30: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 1xHLXO-0005n0-N5; Thu, 15 Oct 2026 13:30:26 +0000 Received: by outflank-mailman (input) for mailman id 1450561; Thu, 15 Oct 2026 13:30:25 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHLXN-0005mu-66 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 13:30:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHLXM-0096fZ-Bz for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:30:24 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0d563-bab6-0a2a0a5309dd-0a2a4504dcde-48 for ; Thu, 15 Oct 2026 15:30:24 +0200 Received: from [40.93.196.53] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0d56b-b57f-0a2a45040019-285dc4354f6b-3 for ; Thu, 15 Oct 2026 15:30:21 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6555.namprd03.prod.outlook.com (2603:10b6:303:126::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Thu, 15 Oct 2026 13:30:16 +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.0522.013; Thu, 15 Oct 2026 13:30: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=klBkkeuZn/feOvFpDYnwJxU02+H38GKBwjb08K1X5H29hSPCPt92ohXNOUPhVXHUf1stbFRGx+OPVf0J26EdIL9AFgRxibgTFhsiVflfCeVqMzsJN/gLcOUamPYyumG8h+bWySIsaDAzuIsylJ4bw07PObCyiGCZJ/1VRObF/azR2F0sKX8g7vGQKiccTNN1+wZOPz495L3yH8Mp2qRUS2t1rhRFu0CKJXC/7OcPDeDBzv4KTzSjGFDiBGY2FSOmQtylrQhWMu0xjBo3KbVcGBCbiPkGsKIP1AgCArFGKM971wB4QlmgBZPFmydhrLV7qnC2sw8bztQgdPEA31v/6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1RsR/lMvQmPDYXn0qSwj5QEqoktfgOcyMNx0f9mYW9c=; b=KPp398s6+rKJz8jImBNYNtHgeM3sgqnz36EdMMp8mz/4T2bak6MXUkgdpPw4olLbfAc7TM8TKztfSJofbvvuPkBrsp0pZGV+8Dn/Wj7hME+gU5kmJn1RXIc36WODoJUsvs2TbtIqeTL2LPrRbNJPTn7g5p1+yTM2FPFYfrwBkuQZ+k7ayeh9M1EGJIpN8ssDz51Uv6FOlxjOsU/Yz9aU9sOvzBOPKtiBDv2RFtp3IG770sgDR42FSVn3PyzBg5KmbA8hp0yhy9NfbRV2HJYNAi7QsyAUWs4w4dk0rcG/liXHbf19j9ZmoyT1JaUq3X9ymDGYQpYqqHoDwMZwKwTkDQ== 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=1RsR/lMvQmPDYXn0qSwj5QEqoktfgOcyMNx0f9mYW9c=; b=zLuIwvZ01Vx2nyEhuWwmtTU2yWjUK2MyO0qdoM/ozDBDasTb6rdpRraDXpDIEJhGnBEl8jnIlE97zDsWdLALZ2o4IsqYwy8bYBKBP8BbWux0dVPfcynSKbkjiYtLcMl/bAySugzxXZ5cffptbRaOc5HRJY4tPXeYi9s+FDhsKuE= 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, 15 Oct 2026 14:30:12 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Doug Goldstein Subject: Re: [PATCH 1/3] tools/tests: fix domain creation on ARM To: Julian Vetter , xen-devel@lists.xenproject.org References: <1792070250.8631fc262581453bbf619ec5b2062170.1a13fb5eee80008425@vates.tech> <1792070492.8631fc262581453bbf619ec5b2062170.1a13fb9a01f0008425@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: <1792070492.8631fc262581453bbf619ec5b2062170.1a13fb9a01f0008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0500.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::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_|MW4PR03MB6555:EE_ X-MS-Office365-Filtering-Correlation-Id: 45b24f89-f526-4b80-718b-08df2ac07325 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|22082099003|18002099003|10067099003|4143699003|261009223027099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: kQ9d5QqOMkx35PY4EyGmkKvnDBJUFMPypw891tqDs1OnlX8YNQ11FSBwJxJB1dAdU0LueBFdLs65IHUCNqQsbqwIvKtV44ZHQFqLapAG3vYKpM3cesNULk15aN8iBL7kWz7FDnzofXT3K5Q8+r2vO8obJ3gDQDBVHeo/O+7d7BJW0QJpuy7HLfxqUxHC8gdYlchBro4CETeL8WJxsOl3WgUjaE7tGwaX71w24fz+RgK+ExRTXys8hoajI+WxIMa3H6XB9wq3fYYqrkixbUvNoXuqDhSYOzPZbssgNJ6lFBkadDAUmIGGu4LlLAB3a406MI6r3fU8s4+sQWRTFmZqyw+AYhRuf3NrXieQNIHB+SGeS711nXDVLv7cI1x5OAGxGC5ORaA5Xv+3LgHGUf0Gt2ILlUafXJtDKqc0m2IXEM1rUmAKwSh6nXyhEJ1ZZRnsFVcsXrqzNsquipx4KfL51aN1Ur1jaHjNe4kBv2DY0vftSW0HFZSHzCAsSkee22Bj6i8+xfxn3JAMYzwnGEncKYtaN49nWFfEIrpotgjAyCiOHy4gozdbsG06IGTEjZ5JwveY1FRxvwHKsFeoqfmewGMQO+rVbdi9UcGaeqzHp3oCwaF/7uk6jLQHDwLlkfyrtG7bYmBBz1iJx76AQFUhEWwsTihcu1r8GGTBMKynrFI= 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)(6133799003)(22082099003)(18002099003)(10067099003)(4143699003)(261009223027099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TU1EYmtoa3ZkL1lMcnZsOXU4TmsrT24vd2hSOFNzeWFORko5MURUYVcxQnlp?= =?utf-8?B?bVJBL3duVDN5M3lGbTVLSDVWdDh0Mm0xM1pKanRMZW1PZEJ6SU1PVEZSbldi?= =?utf-8?B?UlN5Z092Zm9iVnpCdHJja3R2OHh6MTdQd2xOM0pQZ0IxM2YwZDJQRWdUeHo3?= =?utf-8?B?dERzaG9LeG8rdmRyWEoxbFdEQWJ5S1I1OFZOZGxCOG00M3k2QTJhZ09qS3k2?= =?utf-8?B?UThBcVNyZ21weklHQlNySGF5SEVuZmh1RllUSWRlcHV2elZhQUZ6akg1Z0c1?= =?utf-8?B?Vkp6WWJ0di9IdDBGQjNSeWF1ZzJ5cHBONTB3byt6UlptVEhiUU1XSUlVdGlW?= =?utf-8?B?YjR5Q0JVVmsvNlYyaGJCaGR6TzQ2Zk4xRnRBSnFJa1hNYnMveW5pSFR5alVB?= =?utf-8?B?N1ZTVFdQQTM4SEZxa1pjVW0vTnVEMmdwUmhZNE9rNzZQY2l5dXhvcGtCR3Fl?= =?utf-8?B?Rmpsb2h2cWxRNkpGeTdBRjRKcWFCYndMa1hyU0NsdjI3azg4N25JeVE0MlJ4?= =?utf-8?B?N1dQOFkrazRHMGYrM0dmV2gwYmFSZHZyKzEvMVV2ZzQxQVpQM2VMZ1NtZHRF?= =?utf-8?B?MWhyd2JXU3pWSVJmMldySng2eWVNL2IwOGpheGpxbFFhaWRlS2FJZ3dxYWQ0?= =?utf-8?B?MkN2NFFGeGlFVW84amJKOEFQc1lucCtmVnE3SlZEYTE5Z3FSaVFueFNJVjdy?= =?utf-8?B?U0s5NkhaMGp0Mmg5Z3Q4Z05KclJRUFVING5IWEtQZFM2dXhYamlUVjNETzF1?= =?utf-8?B?ZlFhNUtlYVNWdUpyN2ZjL3ZiTW1rZlB5WHFESnk2MmxoWU8wRThoVzNWaXZB?= =?utf-8?B?OEY1RzNUWFVkTVlLWWNENkxnbUluRm5nWnlHTUVFcUdkc2VROVV0aHI1Z1g1?= =?utf-8?B?R2JEVXRINm1XRjgyMDViVThscUQzS0pObTRZaDYrd0NZdGFkVUpLaTUyTGVo?= =?utf-8?B?WEdORkxLdm42VUVaZ1VhMWp2TGo0eksyc1hmS05mNmpGRDBENVBqRWtvZ2hr?= =?utf-8?B?eVJqQm5rUzYzU0dzd09BVHVaVXo1ZFlkK3owUm9oeHZ5OUpySG84c2p6cTdM?= =?utf-8?B?K1lZOWhKTWZoL1J5TU45NlNCL0tHTUtzWE1KM3ltY21wVklVZmVDdWRNcFla?= =?utf-8?B?Z3pmRlJROWtnWld2eUZmc1Y5bG1rVXRPZlF4Z3NTTUY3cHRaNldvZWlUQkpU?= =?utf-8?B?bkVtRm42RVdla3AvYnZMS09FZjdOcEtPZnhERGE0RFV1VnRLZFJDYVVOY3Fm?= =?utf-8?B?SU8xejRqcEQvVG1TRVRQK1JCdU9pZnNpTkpndkhFbDNoWUdVZEZXWHZzcFJH?= =?utf-8?B?cnBlUS9sQUJQcDdKSVBIUkJ5VHN2cGtEeE1VZStyTisvSWZFR0dGcTRmZE9Q?= =?utf-8?B?aGcxQmc2SkY4ZkdpUXdOUEhxaGdwTXV6aTVma0J6cnIxeXFyWHlXdHNYNEN1?= =?utf-8?B?SlNDSFhsUTdzYlRjOHZ0ZExTZnFRa1p6MnRLdkh2ODN1aDY1RGoyRnNWVk56?= =?utf-8?B?YTRvaUthMThOV0VpYnBWbFUzcnJ4QjVrTDl1RHNGOUpXUUcyZ0QyTTN0SDRZ?= =?utf-8?B?VkJjMXhsMmtnU0FuN0ZkZGl5SG03b1NZQ29CYTJhMGhxNHA5bEdmNWRwSXBz?= =?utf-8?B?eUQ3RVVDbUdWaXlqOGUvMW9HZzBGWEZzcnkwckFZaUFqaTJ2ekMxcEw5Qldp?= =?utf-8?B?QkpxUnFFRnM0cy9iUWxiYzdRdU1qMDlHNHFCNE9oUjdFOS9PNEtveVN6NW12?= =?utf-8?B?bGpiWjJiVlFwczdqeDFIbmNwY1VMQ25vRGZTci82cVF0K1R4bzNuc1VyeTgr?= =?utf-8?B?UG9ZeERyM0FWMzVuSmNzYzdibW0wcXBxNGx5QWs4UVl1UmpMSk1RWWJLNGx4?= =?utf-8?B?ZjNQNkl0eUpBMzlpKzVxaU9TaTk0NWpHM2xEaHlCUUN5U2NCMGpCaGdnMkYr?= =?utf-8?B?QXVhSjVoaXBCY3krb2lVT1VNdXpjTFNiVDJ3bFQyb1o2Mml3c1Z4TUxBYUg1?= =?utf-8?B?elJBWE9xZkp5VlBtbjZQRXJjaDQ3ZnhIeDErMnBIRFBoT2tuSEcxeXlISTVl?= =?utf-8?B?Z3diNTk2WTMvaVJqY1o1KzhkbFpRZGpTLzBFeUt5aDRndDRYQWN3bys0TTAv?= =?utf-8?B?MWxsSytjODdzRU5QYkZNRk5udlJ0QklIVnNaYUZ1NVVqNXVvQVpoaXFrdjVM?= =?utf-8?B?Z0NaeHYwbkpSd0tCdWhtS3JGbEZXZUNLSWZBeXMzUXVCanZJcStJaVhkbmpi?= =?utf-8?B?UU5XNWRMZzdiVURXNjZsbWZtTDdpQkpwMXNwdXI5ZndvMDNxSzNmSDZBbGpF?= =?utf-8?B?UVlxMFc3aDlvRHRLcEpzaFNjR0F4ZjhoODk4OFRzVUVhVnZkeFFpZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45b24f89-f526-4b80-718b-08df2ac07325 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 13:30:16.5520 (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: iZE53mCXUvCiSEy+TU7Vo34JPPjsjDW/1ywMb0KwWLqwHeXavV4ROAoPz6QVoSUyy63saJYhDqbE1KJBCSkvm69/nb/+4IuS6Kstf2TJZlc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6555 X-purgate-ID: tlsNG-ebf023/1792071024-C12DCB50-D0CD81B1/0/0 X-purgate-type: clean X-purgate-size: 1612 On 15/10/2026 2:21 pm, Julian Vetter wrote: > The tests test-mem-claim, test-paging-mempool and test-resource create > ARM domains with xen_arch_domainconfig set to zero, i.e., gic_version > XEN_DOMCTL_CONFIG_GIC_NATIVE, which has been removed. Domain creation in > test-mem-claim and test-paging-mempool fails, and test-resource > skips its ARM configuration. > > So, pick the GIC version from the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 > capability bits reported by XEN_SYSCTL_physinfo instead, the same way > libxl does. Use GICv3 if available, else GICv2, else fail the test. > > But, even with a valid GIC version, the tests don't properly run, > because ARM domains start with an empty P2M pool. The toolstack calls > libxl__domain_set_paging_mempool_size() in libxl__arch_domain_create() > to provision the page pool. But these tests don't go through the > toolstack and call domain_create() directly. > > To fix this, call xc_set_paging_mempool_size() just like the toolstack > does. > > Signed-off-by: Julian Vetter Thanks for the patch, but I think this wants to be two patches. The GIC side of things is obvious, and is fine to go in. I'm confused by the mempool side of things however.   The mempool cannot be empty at the Xen level, even on ARM, and we do try to set it to 16 pages in one case. If there really is a difference between how x86 and ARM behave here, I suspect it's a bug in Xen.  We absolutely should not be having differences such as this exposed at the toolstack layer for things common between architectures. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450632.1666050 (Exim 4.92) (envelope-from ) id 1xHM8P-0007df-Qj; Thu, 15 Oct 2026 14:08:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450632.1666050; Thu, 15 Oct 2026 14:08: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 1xHM8P-0007dU-KP; Thu, 15 Oct 2026 14:08:41 +0000 Received: by outflank-mailman (input) for mailman id 1450632; Thu, 15 Oct 2026 14:08:40 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHM8O-0007d5-GL for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:08:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHM8N-002ujh-TG for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:08:39 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0de59-e002-0a2a0a5209dd-0a2a4501c5d8-30 for ; Thu, 15 Oct 2026 16:08:39 +0200 Received: from [52.101.65.141] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0de67-5984-0a2a45010019-3465418d2d13-3 for ; Thu, 15 Oct 2026 16:08:39 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by ZR6PR03MB911287.eurprd03.prod.outlook.com (2603:10a6:910:d7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 14:08:37 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.012; Thu, 15 Oct 2026 14:08: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=mV7sIhc4h5L1Wlk6OUAL5e3XnDnBG+fqQvvl6z4Zwtp5diKYSzSKTDmwQGfpgGQk7Xqj5Fa3H3mJEL3zKUDQkOnypCo5l9GjR14CW8KFxi9SVqmXYzkpxhlcE1OZuCGAIw5mht3KBO+Mj2xEwXpBm265vTgnBy72OsNTmSLFVRdX95b2ZB2eRYSAnQGnaB9n3G0t69TVx+hqRNfsSLPki+XnPeiVBjfDcpEVd2ag3YRZZHJ466PrmtMMTQt9tLWZumgVNYZYLVnOgIC/iKgv0/5Ycq0unuX8ZCwokfYQZDZVl3fJXrQGukZpIxNuPu+cqsF7H+KF0ac+KnWk3CgZxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5sJAo1otyMGHGq30IJWkvji4FFxlmFsmPqNW7mc0NpY=; b=RQjHkLJNiqADgWUDlDetfAX1V01MtNOrqxhqikMPDiCb6wh4i1kEnd/zn6jcpCuUirsvJhJtFlFij0wSY+fnEE3w2qZCn6nbso0MvZ5zK9CITBmxM/2hv8NOrn5dH63yL0nfji0odmRaXKuD2CIJbIiW4WSyP59O9Ys788CTi2UOLxw5AmK24E1Jp9CovGekNODDkkR4Mk+i//cbEtQ4baGNBkRjVFsaNAlI0x/znQaiy42HRL5fylpAxzfi0kOtIOdpl9MLw9wkC3Fp7Rj+tFCKE3lm1Bmvq/qN06v9MjODwBWGUM70Fr5gFtuYZWLPOZLs7XiFyf4mulxxyI3xhg== 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=5sJAo1otyMGHGq30IJWkvji4FFxlmFsmPqNW7mc0NpY=; b=ZvEbt+OzZl9LR3qJQLFOLOsGcjn7xsD8+aNXN3hQL2TJiDlFkvc3THvRvCvPtX5DYIisQkGW499lCPW4EII1rP83PNTBA5UqlKFguAKmHL28zuoF9fbIacDEj6KhxZg2Htjz6Ea6T5vk6RQIV0N5oxIBlve5GzHikM8wnQWBPzY4wj7jXqvsqs2ZGz9yzF3ctoean2U0Kjzw69UEyw5+/zDo6s5Hjgn4Wzj/Kb/nNcZ1CqfGVtXhKodtcmbGYklJ4pMloEVsNqt/rEPLnHUlXH34go4xzhjvHHndM4Y/M/D1CfLeoy9eYNW38Q0Y3Gg5IxS+71BTKnIm/dt801csiQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stewart Hildebrand , Mykyta Poturai Subject: [PATCH v4 2/5] vpci: use a local variable for the BAR rangeset Thread-Topic: [PATCH v4 2/5] vpci: use a local variable for the BAR rangeset Thread-Index: AQHdXK6s1/OTDdF9sUu0/5BIXzgIaA== Date: Thu, 15 Oct 2026 14:08:37 +0000 Message-ID: <4bce74f6f5d2fc7b58c62acfd377956a9fee8651.1792072426.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|ZR6PR03MB911287:EE_ x-ms-office365-filtering-correlation-id: 23192694-3651-4ec5-e3df-08df2ac5cec1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|38070700021|56012099006|11063799006|261009223027099003|10067099003|22082099003|18002099003; x-microsoft-antispam-message-info: 4DB9pAbOMLSqsULJhUguJJh31UUcFPJord1q4EcBi4UdpbSnicfmOqVc8/ID/0g2mKO0zd7PZHJhqE1nfUzvpTc7rRn6sIMEIwOK4jj1kVIKbzsFg/h9+Rszs0Pp8xg2GLDlIzqWIIfkjZQQl70epwFalrOfAE3LaVdBZ12K6K5ku4tqWlrPkjQ2R+QfG9HYktrAnJEYJXCbwc7jXM5XHRMOqVHBbl0tkbxZ+1BVpCmDs1+ULmEUSviqobEzqhzJL7o+oNHZ0H3T0/JfpVgKooLMx5xIgGgQrcNV6bE4Za4aUNTZXmJ62lE7FVcdLFwUK+3AQTCl2PuPM1MUO0YCf+pu6R0PxC8ziTrD/+PqBEdhVqybgUYOv/AsMQybbRUhZk6T/vSccY6upVspcOMfIG7ytguWY0i4bokLO+VuEonhy3HxFwAmbDmuM9Z9gGjV45unmmjU1hclc+iI1tol+iVVIKl9THUjQR/7a8GqB/j1Izl9eCU/aJVtY2j7IyVX2OJ767Z0VU+86bkqidNeDyh0CgzZWAJWzAPgW3fmLI17QoFLuojUxTTYl/WLaHGaci9yYmZgKcuqxum6XIMaGqatPYeNHPbAnwpliyZ66GV45LvJK+Jd7A4/WCA61iXI9SEufH1ifIsjJnOrGdRQkl0WPQEsuN50lasnHt6YQCjsi+ejFqWD5jBYtFj/b9Cx90Izy5CtLEXrhISdVitGg/tUeE+EtghiUTJ7PEds+uw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(38070700021)(56012099006)(11063799006)(261009223027099003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?M01wVGlXcFlQSXVPb2dUbG4rNGYvUm4zY3NpekhpUDNrMTNWUnpadXlXNCtI?= =?utf-8?B?SkNoYUNPdzVJQ0kyeGNJZ0tlRWR4amRwYTZleVNNTFRrNWpaNU15MnBDWlBn?= =?utf-8?B?UFluaHVhOU5LTnY2OWw1U004VEY2Nnh3cjFHd1dsaEYxTlFsQk5VTFFzdTZl?= =?utf-8?B?UW51UFkzN0hSZjNsOTZQRlN6MkR5YlNlQzhlT0RQaXZtRG12Zy9hUEo4NFV6?= =?utf-8?B?Nkk1UVVQc3N3cXR0ZHZET3FyclRMZXJuem5HWnYxSklVT1JsV3MwcGszeXRE?= =?utf-8?B?QVdtakZBU0NvMUN1dUh3cXdLb1BEa0NHczVHZjh1RENZZWozSTVIbkFoSmg3?= =?utf-8?B?NXRXUDBBdWQ1eXpuNTVoWnlGbmdTTVJxQmFLb1VaOWcyenNyMDh1aUxYb0cz?= =?utf-8?B?L3A2TzRvZmpSQ1E1MnYxbmJmNXBHa3lJNHNwbGlDT3JKWVVwcWRtZWROZXUx?= =?utf-8?B?RkkxczZobGtiT3VCcnh4THFNdjMxaXVTekxyYitCQnVVVDdMS0Z3Qy8xTlZy?= =?utf-8?B?Z3AzdUthdXYxRGFZWU0weHF4WXQvZjZoRFJDN3oxWlV3REszTytrbW11OENJ?= =?utf-8?B?QmEyTkZjY1FzZC9xcitkZDd0dGdmZFV0UWJ2d1hoMFlxb0cxbzhQQjh5ajZ0?= =?utf-8?B?RW9BUlhLdTduNFN4MDFXRHBLbTh1d1R6YUlWMDBsTHg2bWpDK2I5N21oQjZL?= =?utf-8?B?MHBkQW5kMGpuNFNlV0p5SW1TSjFWOXdTeFZMWnV0c0xIL2p5MkRnNFRsOU82?= =?utf-8?B?VEhxdUZiOUFBT3B6M1ArcW9jc09jSEQ3TFgrN29qOCtzdytGVEk0aWdaMi9z?= =?utf-8?B?MUpKM1BFc2hRUVJPTEhlaGxtVXluYU96S1VGcHNYWXhvdlRCekNUS25ETlI5?= =?utf-8?B?SjU0VWRTN2hBZkFHdVFtZktpUXFYRmFrc2planJ3KytDNktHN3NoSmRSSlBx?= =?utf-8?B?di8yQjJvL2MzVFltN2Z0ZVJYVmZhNmxndXo1K3o2bWVNQkFJKzBuRkZ3V2F0?= =?utf-8?B?WEp4QTNxcnl2MTNvclBKd1NyVWR2bUhpeWFIVUtHa1k2WUVJbFNmSzJtOHcy?= =?utf-8?B?TDk4dzNkdGhNNjNhWGR4dkFjaTZnQUsrcm15YTBMNEowcEJrL01lOEU5aHdM?= =?utf-8?B?dzJHOVpKUTB1enM4clgvSndXZmVaMGVUcHlEZ1EwNk51V0NBUUZENW1FMzhC?= =?utf-8?B?MExFRmZMN0xodFl5OHhWWnppYVpxL1lEZ0Y2a3FKa3RiOXJtUnRFMjZxakto?= =?utf-8?B?UVk2OVNWUTBMUjVWMmlyVHlSbk91SnFsaHBVOTFVVDdhM2FjSFJaU1NjWWQz?= =?utf-8?B?UmJiWm1EV052VndLWDhNOXc4Y3VyMkZXcGJGd2xBbjRrZ2RDTXMwSnRtRG9i?= =?utf-8?B?VTJSMCtCWE9WMFdFZ3FjYVA2UkpHOGdxS2ZSVFQyOW9TNmFONEFYbkMzYTFh?= =?utf-8?B?WWRTaVFLeXNaejNiOUN3bGZPTDl2WUF6UWtvbzF2WEFKRUl2Y0Fyakw1d2pG?= =?utf-8?B?MkRGSmlyUTJvdm80Y0ZpOWlBR05TRXptWm05bkJEV0ljdU41WEE5dXc0WWkx?= =?utf-8?B?d3UveWJLSkI3Ni9zamFzNWhRNDJub2RvREs0dkhrVFhFMXQvakVhajZrQ2VT?= =?utf-8?B?ZmRwdHAzNzBhN2VnamtqSUpha2paOFdUbHNPK0NTbzdiZWhDUGZYcUdscW5n?= =?utf-8?B?ckVvVG15K0VJdEJNNGRrbFZNNEw1d1dzU0RvSlArb0VLcGlNVWswMW9yZ0Vj?= =?utf-8?B?a0hxSnRIdHVlcUlLMTBGd1JQSkRKUEZydWtGVjBkTnZQcWJPR0pDNU5WL24r?= =?utf-8?B?YVkwN2dHenExVGdjL1VCRmttN1pmZVNNRzQvZkZmeVFaa3FlVTFSZGdteHo4?= =?utf-8?B?Y004OGVTYUtHUGt2Ui9nMTY4MjVkbllselZJcW0xTzlLVmVYNnA4bWlzRWJq?= =?utf-8?B?azRtcjA4SkFaYmtKamJZSm1wL2ZsOUd0Q2ZzeTRjVTgybE1BVklveEFPZTRr?= =?utf-8?B?TnlMb3JnWkVJUzBEZkl6YmpYSUNlUmpJbFovOFlVTGJRRFBGQ3B0aGpuM2s2?= =?utf-8?B?Mk9qTU1MTkJhQlVDbGc5UVdKT3ZLYmgweGJIZ2VHQzZGaUZodUdwa1hDQURr?= =?utf-8?B?WGdJbkVBVzBFb1JDREFSaGI0Mjl1enRSOVk1cEdhTmRJRVRNUmxyb0g0b0lH?= =?utf-8?B?RzZhYTlmZjEvc2RIUTk3Z1BEVTVDZlN4RlFzUmEzRFNKbEVoYzdhR1pMSEZH?= =?utf-8?B?MXZpWkxUSmJoUWIwQTR1RDhsZDArWVNBSEpqdERINGpuMEd1dktYK0xUdEky?= =?utf-8?B?UWhTNHl5cXg5U0VDTmFDR2w2dXF5RGo2bUo1dmNweUhyR2ZBN0pYcS9NQnZy?= =?utf-8?Q?cD4UpvFUesBP+Lug=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23192694-3651-4ec5-e3df-08df2ac5cec1 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2026 14:08:37.5338 (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: CCMNCErqbG3CMki3wjw8GYNmixXvn8tMmflTvfaYLhHiwcJwuW6hsynt6ZjIjINxYRWadew0L9PqoIelavQ2lA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR03MB911287 X-purgate-ID: tlsNG-d62444/1792073319-BD146757-DFA2E106/0/0 X-purgate-type: clean X-purgate-size: 9522 RnJvbTogTXlreXRhIFBvdHVyYWkgPE15a3l0YV9Qb3R1cmFpQGVwYW0uY29tPg0KDQpJbiB0aGUg QkFSICh1biltYXBwaW5nIHBhdGhzIGxhdGNoIHRoZSByYW5nZXNldCBvZiB0aGUgQkFSIGJlaW5n DQpwcm9jZXNzZWQgaW50byBhIGxvY2FsIHZhcmlhYmxlLCBpbnN0ZWFkIG9mIGRlcmVmZXJlbmNp bmcgc3RydWN0DQp2cGNpX2JhciBvbiBldmVyeSB1c2UuIFByZXBhcmF0b3J5IHdvcmsgZm9yIG1v dmluZyB0aGUgcmFuZ2VzZXRzIG91dA0Kb2Ygc3RydWN0IHZwY2lfYmFyLg0KDQpObyBmdW5jdGlv bmFsIGNoYW5nZS4NCg0KU2lnbmVkLW9mZi1ieTogTXlreXRhIFBvdHVyYWkgPG15a3l0YV9wb3R1 cmFpQGVwYW0uY29tPg0KU2lnbmVkLW9mZi1ieTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0 LmhpbGRlYnJhbmRAYW1kLmNvbT4NCi0tLQ0KdjMtPnY0Og0KKiBuZXcgcGF0Y2gsIHNwbGl0IG91 dCBvZiAidnBjaTogVXNlIHBlcnZjcHUgcmFuZ2VzIGZvciBCQVIgbWFwcGluZyIgc28NCiAgdGhh dCB0aGUgbm9uLWZ1bmN0aW9uYWwgY2h1cm4gaXMgc2VwYXJhdGUgZnJvbSB0aGUgZnVuY3Rpb25h bCBjaGFuZ2UNCi0tLQ0KIHhlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgfCA0MSArKysrKysrKysr KysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0NCiAxIGZpbGUgY2hhbmdlZCwgMjIgaW5zZXJ0 aW9ucygrKSwgMTkgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNp L2hlYWRlci5jIGIveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0KaW5kZXggYTRlNTc1YmU0ZS4u MjM0MTJiY2FmYSAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCisrKyBi L3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCkBAIC0xOTYsNiArMTk2LDcgQEAgYm9vbCB2cGNp X3Byb2Nlc3NfcGVuZGluZyhzdHJ1Y3QgdmNwdSAqdikNCiAgICAgZm9yICggaSA9IDA7IGkgPCBB UlJBWV9TSVpFKGhlYWRlci0+YmFycyk7IGkrKyApDQogICAgIHsNCiAgICAgICAgIHN0cnVjdCB2 cGNpX2JhciAqYmFyID0gJmhlYWRlci0+YmFyc1tpXTsNCisgICAgICAgIHN0cnVjdCByYW5nZXNl dCAqbWVtID0gYmFyLT5tZW07DQogICAgICAgICBzdHJ1Y3QgbWFwX2RhdGEgZGF0YSA9IHsNCiAg ICAgICAgICAgICAuZCA9IHYtPmRvbWFpbiwNCiAgICAgICAgICAgICAubWFwID0gdi0+dnBjaS5j bWQgJiBQQ0lfQ09NTUFORF9NRU1PUlksDQpAQCAtMjAzLDEwICsyMDQsMTAgQEAgYm9vbCB2cGNp X3Byb2Nlc3NfcGVuZGluZyhzdHJ1Y3QgdmNwdSAqdikNCiAgICAgICAgIH07DQogICAgICAgICBp bnQgcmM7DQogDQotICAgICAgICBpZiAoIHJhbmdlc2V0X2lzX2VtcHR5KGJhci0+bWVtKSApDQor ICAgICAgICBpZiAoIHJhbmdlc2V0X2lzX2VtcHR5KG1lbSkgKQ0KICAgICAgICAgICAgIGNvbnRp bnVlOw0KIA0KLSAgICAgICAgcmMgPSByYW5nZXNldF9jb25zdW1lX3JhbmdlcyhiYXItPm1lbSwg bWFwX3JhbmdlLCAmZGF0YSk7DQorICAgICAgICByYyA9IHJhbmdlc2V0X2NvbnN1bWVfcmFuZ2Vz KG1lbSwgbWFwX3JhbmdlLCAmZGF0YSk7DQogDQogICAgICAgICBpZiAoIHJjID09IC1FUkVTVEFS VCApDQogICAgICAgICB7DQpAQCAtMjE4LDggKzIxOSw3IEBAIGJvb2wgdnBjaV9wcm9jZXNzX3Bl bmRpbmcoc3RydWN0IHZjcHUgKnYpDQogICAgICAgICB7DQogICAgICAgICAgICAgc3Bpbl9sb2Nr KCZwZGV2LT52cGNpLT5sb2NrKTsNCiAgICAgICAgICAgICAvKiBEaXNhYmxlIG1lbW9yeSBkZWNv ZGluZyB1bmNvbmRpdGlvbmFsbHkgb24gZmFpbHVyZS4gKi8NCi0gICAgICAgICAgICBtb2RpZnlf ZGVjb2RpbmcocGRldiwgdi0+dnBjaS5jbWQgJiB+UENJX0NPTU1BTkRfTUVNT1JZLA0KLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICBmYWxzZSk7DQorICAgICAgICAgICAgbW9kaWZ5X2RlY29k aW5nKHBkZXYsIHYtPnZwY2kuY21kICYgflBDSV9DT01NQU5EX01FTU9SWSwgZmFsc2UpOw0KICAg ICAgICAgICAgIHNwaW5fdW5sb2NrKCZwZGV2LT52cGNpLT5sb2NrKTsNCiANCiAgICAgICAgICAg ICAvKiBDbGVhbiBhbGwgdGhlIHJhbmdlc2V0cyAqLw0KQEAgLTI2MCwxMyArMjYwLDE0IEBAIHN0 YXRpYyBpbnQgX19pbml0IGFwcGx5X21hcChzdHJ1Y3QgZG9tYWluICpkLCBjb25zdCBzdHJ1Y3Qg cGNpX2RldiAqcGRldiwNCiAgICAgZm9yICggaSA9IDA7IGkgPCBBUlJBWV9TSVpFKGhlYWRlci0+ YmFycyk7IGkrKyApDQogICAgIHsNCiAgICAgICAgIHN0cnVjdCB2cGNpX2JhciAqYmFyID0gJmhl YWRlci0+YmFyc1tpXTsNCisgICAgICAgIHN0cnVjdCByYW5nZXNldCAqbWVtID0gYmFyLT5tZW07 DQogICAgICAgICBzdHJ1Y3QgbWFwX2RhdGEgZGF0YSA9IHsgLmQgPSBkLCAubWFwID0gdHJ1ZSwg LmJhciA9IGJhciB9Ow0KIA0KLSAgICAgICAgaWYgKCByYW5nZXNldF9pc19lbXB0eShiYXItPm1l bSkgKQ0KKyAgICAgICAgaWYgKCByYW5nZXNldF9pc19lbXB0eShtZW0pICkNCiAgICAgICAgICAg ICBjb250aW51ZTsNCiANCi0gICAgICAgIHdoaWxlICggKHJjID0gcmFuZ2VzZXRfY29uc3VtZV9y YW5nZXMoYmFyLT5tZW0sIG1hcF9yYW5nZSwNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmRhdGEpKSA9PSAtRVJFU1RBUlQgKQ0KKyAgICAgICAgd2hpbGUg KCAocmMgPSByYW5nZXNldF9jb25zdW1lX3JhbmdlcyhtZW0sIG1hcF9yYW5nZSwgJmRhdGEpKSA9 PQ0KKyAgICAgICAgICAgICAgICAtRVJFU1RBUlQgKQ0KICAgICAgICAgew0KICAgICAgICAgICAg IC8qDQogICAgICAgICAgICAgICogSXQncyBzYWZlIHRvIGRyb3AgYW5kIHJlYWNxdWlyZSB0aGUg bG9jayBpbiB0aGlzIGNvbnRleHQNCkBAIC0zMzEsMTIgKzMzMiwxMyBAQCBpbnQgdnBjaV9tb2Rp ZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJv bV9vbmx5KQ0KICAgICBmb3IgKCBpID0gMDsgaSA8IEFSUkFZX1NJWkUoaGVhZGVyLT5iYXJzKTsg aSsrICkNCiAgICAgew0KICAgICAgICAgc3RydWN0IHZwY2lfYmFyICpiYXIgPSAmaGVhZGVyLT5i YXJzW2ldOw0KKyAgICAgICAgc3RydWN0IHJhbmdlc2V0ICptZW0gPSBiYXItPm1lbTsNCiAgICAg ICAgIHVuc2lnbmVkIGxvbmcgc3RhcnQgPSBQRk5fRE9XTihiYXItPmFkZHIpOw0KICAgICAgICAg dW5zaWduZWQgbG9uZyBlbmQgPSBQRk5fRE9XTihiYXItPmFkZHIgKyBiYXItPnNpemUgLSAxKTsN CiAgICAgICAgIHVuc2lnbmVkIGxvbmcgc3RhcnRfZ3Vlc3QgPSBQRk5fRE9XTihiYXItPmd1ZXN0 X2FkZHIpOw0KICAgICAgICAgdW5zaWduZWQgbG9uZyBlbmRfZ3Vlc3QgPSBQRk5fRE9XTihiYXIt Pmd1ZXN0X2FkZHIgKyBiYXItPnNpemUgLSAxKTsNCiANCi0gICAgICAgIGlmICggIWJhci0+bWVt ICkNCisgICAgICAgIGlmICggIW1lbSApDQogICAgICAgICAgICAgY29udGludWU7DQogDQogICAg ICAgICBpZiAoICFNQVBQQUJMRV9CQVIoYmFyKSB8fA0KQEAgLTM1NCw3ICszNTYsNyBAQCBpbnQg dnBjaV9tb2RpZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21k LCBib29sIHJvbV9vbmx5KQ0KICAgICAgICAgICAgIGNvbnRpbnVlOw0KICAgICAgICAgfQ0KIA0K LSAgICAgICAgQVNTRVJUKHJhbmdlc2V0X2lzX2VtcHR5KGJhci0+bWVtKSk7DQorICAgICAgICBB U1NFUlQocmFuZ2VzZXRfaXNfZW1wdHkobWVtKSk7DQogDQogICAgICAgICAvKg0KICAgICAgICAg ICogTWFrZSBzdXJlIHRoYXQgdGhlIGd1ZXN0IHNldCBhZGRyZXNzIGhhcyB0aGUgc2FtZSBwYWdl IG9mZnNldA0KQEAgLTM2OSw3ICszNzEsNyBAQCBpbnQgdnBjaV9tb2RpZnlfYmFycyhjb25zdCBz dHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJvbV9vbmx5KQ0KICAgICAg ICAgICAgIHJldHVybiAtRUlOVkFMOw0KICAgICAgICAgfQ0KIA0KLSAgICAgICAgcmMgPSByYW5n ZXNldF9hZGRfcmFuZ2UoYmFyLT5tZW0sIHN0YXJ0X2d1ZXN0LCBlbmRfZ3Vlc3QpOw0KKyAgICAg ICAgcmMgPSByYW5nZXNldF9hZGRfcmFuZ2UobWVtLCBzdGFydF9ndWVzdCwgZW5kX2d1ZXN0KTsN CiAgICAgICAgIGlmICggcmMgKQ0KICAgICAgICAgew0KICAgICAgICAgICAgIHByaW50ayhYRU5M T0dfR19XQVJOSU5HICJGYWlsZWQgdG8gYWRkIFslbHgsICVseF06ICVkXG4iLA0KQEAgLTM4MCwx MiArMzgyLDEyIEBAIGludCB2cGNpX21vZGlmeV9iYXJzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpw ZGV2LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHkpDQogICAgICAgICAvKiBDaGVjayBmb3Ig b3ZlcmxhcCB3aXRoIHRoZSBhbHJlYWR5IHNldHVwIEJBUiByYW5nZXMuICovDQogICAgICAgICBm b3IgKCBqID0gMDsgaiA8IGk7IGorKyApDQogICAgICAgICB7DQotICAgICAgICAgICAgc3RydWN0 IHZwY2lfYmFyICpwcmV2X2JhciA9ICZoZWFkZXItPmJhcnNbal07DQorICAgICAgICAgICAgc3Ry dWN0IHJhbmdlc2V0ICpwcmV2X21lbSA9IGhlYWRlci0+YmFyc1tqXS5tZW07DQogDQotICAgICAg ICAgICAgaWYgKCByYW5nZXNldF9pc19lbXB0eShwcmV2X2Jhci0+bWVtKSApDQorICAgICAgICAg ICAgaWYgKCByYW5nZXNldF9pc19lbXB0eShwcmV2X21lbSkgKQ0KICAgICAgICAgICAgICAgICBj b250aW51ZTsNCiANCi0gICAgICAgICAgICByYyA9IHJhbmdlc2V0X3JlbW92ZV9yYW5nZShwcmV2 X2Jhci0+bWVtLCBzdGFydF9ndWVzdCwgZW5kX2d1ZXN0KTsNCisgICAgICAgICAgICByYyA9IHJh bmdlc2V0X3JlbW92ZV9yYW5nZShwcmV2X21lbSwgc3RhcnRfZ3Vlc3QsIGVuZF9ndWVzdCk7DQog ICAgICAgICAgICAgaWYgKCByYyApDQogICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICBn cHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KQEAgLTM5NSw3ICszOTcsNyBAQCBpbnQgdnBjaV9tb2Rp ZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJv bV9vbmx5KQ0KICAgICAgICAgICAgIH0NCiAgICAgICAgIH0NCiANCi0gICAgICAgIHJjID0gcGNp X3Nhbml0aXplX2Jhcl9tZW1vcnkoYmFyLT5tZW0pOw0KKyAgICAgICAgcmMgPSBwY2lfc2FuaXRp emVfYmFyX21lbW9yeShtZW0pOw0KICAgICAgICAgaWYgKCByYyApDQogICAgICAgICB7DQogICAg ICAgICAgICAgZ3ByaW50ayhYRU5MT0dfV0FSTklORywNCkBAIC00MTQsMTIgKzQxNiwxMiBAQCBp bnQgdnBjaV9tb2RpZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3Qg Y21kLCBib29sIHJvbV9vbmx5KQ0KIA0KICAgICAgICAgZm9yICggaiA9IDA7IGogPCBBUlJBWV9T SVpFKGhlYWRlci0+YmFycyk7IGorKyApDQogICAgICAgICB7DQotICAgICAgICAgICAgY29uc3Qg c3RydWN0IHZwY2lfYmFyICpiYXIgPSAmaGVhZGVyLT5iYXJzW2pdOw0KKyAgICAgICAgICAgIHN0 cnVjdCByYW5nZXNldCAqbWVtID0gaGVhZGVyLT5iYXJzW2pdLm1lbTsNCiANCi0gICAgICAgICAg ICBpZiAoIHJhbmdlc2V0X2lzX2VtcHR5KGJhci0+bWVtKSApDQorICAgICAgICAgICAgaWYgKCBy YW5nZXNldF9pc19lbXB0eShtZW0pICkNCiAgICAgICAgICAgICAgICAgY29udGludWU7DQogDQot ICAgICAgICAgICAgcmMgPSByYW5nZXNldF9yZW1vdmVfcmFuZ2UoYmFyLT5tZW0sIHN0YXJ0LCBl bmQpOw0KKyAgICAgICAgICAgIHJjID0gcmFuZ2VzZXRfcmVtb3ZlX3JhbmdlKG1lbSwgc3RhcnQs IGVuZCk7DQogICAgICAgICAgICAgaWYgKCByYyApDQogICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICBncHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KQEAgLTQ2OSw4ICs0NzEsOSBAQCBpbnQg dnBjaV9tb2RpZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21k LCBib29sIHJvbV9vbmx5KQ0KICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IEFSUkFZ X1NJWkUoaGVhZGVyLT5iYXJzKTsgaisrKQ0KICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICBjb25zdCBzdHJ1Y3QgdnBjaV9iYXIgKmJhciA9ICZoZWFkZXItPmJhcnNbal07 DQorICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbSA9IGJhci0+bWVtOw0K IA0KLSAgICAgICAgICAgICAgICAgICAgaWYgKCAhcmFuZ2VzZXRfb3ZlcmxhcHNfcmFuZ2UoYmFy LT5tZW0sIHN0YXJ0LCBlbmQpIHx8DQorICAgICAgICAgICAgICAgICAgICBpZiAoICFyYW5nZXNl dF9vdmVybGFwc19yYW5nZShtZW0sIHN0YXJ0LCBlbmQpIHx8DQogICAgICAgICAgICAgICAgICAg ICAgICAgIC8qDQogICAgICAgICAgICAgICAgICAgICAgICAgICAqIElmIG9ubHkgdGhlIFJPTSBl bmFibGUgYml0IGlzIHRvZ2dsZWQgY2hlY2sgYWdhaW5zdA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgKiBvdGhlciBCQVJzIGluIHRoZSBzYW1lIGRldmljZSBmb3Igb3ZlcmxhcHMsIGJ1dCBu b3QNCkBAIC00ODEsNyArNDg0LDcgQEAgaW50IHZwY2lfbW9kaWZ5X2JhcnMoY29uc3Qgc3RydWN0 IHBjaV9kZXYgKnBkZXYsIHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIGJhci0+dHlwZSA9PSBWUENJX0JBUl9ST00pICkNCiAgICAgICAgICAg ICAgICAgICAgICAgICBjb250aW51ZTsNCiANCi0gICAgICAgICAgICAgICAgICAgIHJjID0gcmFu Z2VzZXRfcmVtb3ZlX3JhbmdlKGJhci0+bWVtLCBzdGFydCwgZW5kKTsNCisgICAgICAgICAgICAg ICAgICAgIHJjID0gcmFuZ2VzZXRfcmVtb3ZlX3JhbmdlKG1lbSwgc3RhcnQsIGVuZCk7DQogICAg ICAgICAgICAgICAgICAgICBpZiAoIHJjICkNCiAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICBncHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KLS0gDQoyLjU1LjAN Cg== From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450633.1666053 (Exim 4.92) (envelope-from ) id 1xHM8Q-0007fQ-0Q; Thu, 15 Oct 2026 14:08:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450633.1666053; Thu, 15 Oct 2026 14:08: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 1xHM8P-0007ey-S8; Thu, 15 Oct 2026 14:08:41 +0000 Received: by outflank-mailman (input) for mailman id 1450633; Thu, 15 Oct 2026 14:08:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHM8O-0007d6-RN for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:08:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHM8O-002ujh-87 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:08:40 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0de59-e002-0a2a0a5209dd-0a2a4501c5d8-32 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from [52.101.65.141] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0de67-5984-0a2a45010019-3465418d2d13-4 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by ZR6PR03MB911287.eurprd03.prod.outlook.com (2603:10a6:910:d7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 14:08:37 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.012; Thu, 15 Oct 2026 14:08: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=N96rvhnNYDWANp7TT3hsG9AmwjHqO868MEq056rO4nhDUivUbKjtuankdcbI4TR5xsH+8I7LU1yzd0oKqcNbKUU2ZgAbF2Hr34rT9zcncF/WleF47kRfMlHOqLTdSUW5Id907+7AggjSq8l13C0/UCQ4AaPQSUQDMsjc60EdEF1s/WqhzfI/AJgCYzRhRSg54gninzem0ZYa92J+TvndRFZHH2HP3/PF83Iip/gM254UXNMu6vp05dMNtpCJUcvJwd4tDMKPUJUYntkzlA9Y0YVmMK7cjhbn3W+IZqlMEq0PlL5oK8iFD8wSUpEssbE7W5Pi/kdCgbjOZNwPG2wDIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b1ca7KajItvwpID/5WS5RgYtGlQHEZ5y83odvhulwBI=; b=AR4om7u3n+8fqkqc9YG4kKUIRzXn2Pevu2zHr9S4iz9hj4gUdLCNO2FyOevDe4OWx9lWfl0jt/8dxWu7xBD3EU+ZX05GeFw9ukpCnMq1yb0O2nhrsErxfrSm+7uZmVEKSSbaprcdchmepSobrCNC/QEeSQhe2IQcj9sa3mHZJoa17FXE4THHoeRpdfQWrdgx4P7A/HwT2ZMQxiVfhrUWUvRKGq7C/ZWQimgNxJYJkNGKlPb8U7eQOrm4z8/4bnvLqEIdQYmDZ7WWTEq91rAIs4a78v8T/2UjwZ5Kvft76+Gy5qAPEC8abwuV+c66tmxEgPjn15ZBClpidbA95x0rFQ== 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=b1ca7KajItvwpID/5WS5RgYtGlQHEZ5y83odvhulwBI=; b=nJebMS8+lV0ugQwa4jEu90z7rEGTRHWjW7f5fK//QNYDFcUKPOG2kYrgk8fyNsgfBqo+bvZ3xOJ/Zw/xHIYUUL1oEUqkHaEnKEbvrEQklH6kCG/MyizIzekWfxcpFFiEw+c4r5CU5x8GRK/R6CGEr+gzY15iPlAB0uSkse/YO2k9p8/I/9J5KoVvsCn4I68WnbHBsJIv463x31osEMPSJFG1qaPVu6jLvsEWqu6Y9be+SeBDyAybrKh1IclAUeaf0UzNTkAgfk+5bPiVdIsLUH+/ndb3DBXSUOAtZdmjSbdM+0M/FrSuCVDAUtAqlJmNBHwmY/4j57ULL0WjcnWa/w== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Mykyta Poturai , Teddy Astie Subject: [PATCH v4 1/5] vpci: Export functions required for SR-IOV support Thread-Topic: [PATCH v4 1/5] vpci: Export functions required for SR-IOV support Thread-Index: AQHdXK6sp1g/PSZvy0KSkitWfzGo4A== Date: Thu, 15 Oct 2026 14:08:37 +0000 Message-ID: <5b2721b7213d53232ce912e4f9ce0b4e7b1b39c7.1792072426.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|ZR6PR03MB911287:EE_ x-ms-office365-filtering-correlation-id: ad4675a4-7848-43dd-eb70-08df2ac5ce8f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|38070700021|56012099006|11063799006|261009223027099003|10067099003|22082099003|18002099003; x-microsoft-antispam-message-info: Dud7XEZucm9JmmUSIG2e8+x6Jo7Gz+2oc+TB4M3FlJNO6c32DnTefbimy/d+7kRJOq15cxdZ0a0ESQl8IokkmdbecpN7kxXB1VLcoggy9fHAGn28r4/Loliy1tW6NDbNod4yfkF9y2fslOo5ugntPTxjRX52oEbpULobe6S7y+nMacP0SEuB3z8+cLtBW+w01E8Q1icMQ4O+9Ll5DfM29UjJnJDUbSRMYAunTdKnKV9xlIrOZF2YsHWy0Mpi0Im5pA8qYvmqlKrEYXFKLlL5iLLuOsyOZYh4mvngEfCr+fe/qTEpy+ovP6lYsQvEWzEZqAbJIdZevAIlMuDPRSyVptK5gdg65Yd17uoysFrI8yQJnkAfASf8lSTC1zStesXp9iRmNJnv4CAySPzvY9iviS6vru7LaOUJOu7/uzwIW/u6hEegGkPvc2q6TGyUt3vUd52wFHCApjTDa8nYjLZT5azszciz4ichzYoQ/jAowPnfIgTXT06ghZ6krVoAQmEUsf54oZJSxlUg94qYI+JGN1B2gNj+WbQbrYzMGbWUFM4KTW1/9tArtDPsDHwbqIgPVbA2qqzoOYP8/KKw96i8yTMWzXyBsxKGXvfjk+UF5byTcxuYlZZeR0y27AmOAiokJCDOq4R86iduepDw/Kt63VpZP4vX8vyvynEPtgcUNAywjvE5AUv3MvPw/Tk+2y+QHtnE2P58CjC4HWjx2nzcUy8R9m97p5meUnjf22DuURk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(38070700021)(56012099006)(11063799006)(261009223027099003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ak5jbFRkOVFyT0hVWGtqM2drVEVxMFp0NElMNkxjR0VtL3VrVTYybmdSeHpW?= =?utf-8?B?SjJhelRCaTgyL3FUNzFMWXlialpKS3QxOXkxYWtUTVV4UGdESWZZb1IwWHhI?= =?utf-8?B?bVdQbEl1Ky9XOHMxUk9WWUFYQXMyMUFjeEdOT0ZGOFM3NnYzZ2ZGSU1vc3FE?= =?utf-8?B?Z293OEoycmt2OE0ycXd4VGR6VWVha3dNbW5qN2c3dDU0bzNDNmg1T0p2bENT?= =?utf-8?B?YklkTCtUYms1SDBXL3Z6bG1JSmxrNFN2citlL2dzbEVlYWNwSWh5RFR4NlZJ?= =?utf-8?B?Z2pzU2RDMlhnWGIrWnk2R3kxbnlpVHRUbGVSN3R3WXJvQ283c29wd1M0dnVB?= =?utf-8?B?bkJHbFRCczdtZElHMXVLbDBmMFZDK09HNUJOZGNkbWI1bGxubzRMQTBmanpW?= =?utf-8?B?SnRiTUQzaUFUU3I3UE1xMktPR05qN2xPb3RuY2ZBN2xVU0dvemNwbktiNUMw?= =?utf-8?B?R2lHTkNBYVk2R1VaOGdmL2RzTDl0QmdsK0V1ckVRTkFEMndoNGNlRnBhcW5p?= =?utf-8?B?MjVrNnkwN3pFRGU2R2hQQmtmY3Y3ZmtxYkQrSHZna1o4VUZTNU1mcjgrQ1d2?= =?utf-8?B?Q0V3SVlhK1FIUVMySmpUMzk2U2lVbElvUnZVWFk2NS94MDNDckN5RkIvYzQz?= =?utf-8?B?emRHbFpRdHZ6U1p1U3FzUkQyR011RWx6OWtxRlRJT3hwQlNjSDdZdU9VSzRS?= =?utf-8?B?RFFBemcveWxwV1BsdStGK3ZKR2RXZ2ZmUmhSTjRkWVBCVHZLQmx1QS9zWXJS?= =?utf-8?B?UkFPMVlUcjAyT0kxQTQyZDB2SmladGhUdXhOVktYNHUvMEFpVG1xQnQ3RVd0?= =?utf-8?B?bm4vaDFVYUhPeFRsbFcxQUViNm9wZ1NNREV4eFY5SlNrMnhTc3pwYVdJdjk4?= =?utf-8?B?TUNHdlZNdjl1aXlMSTZkdE4wYkJCRTJXNGNQd0M0UkZDbDN2dUMwenQ1WU96?= =?utf-8?B?ZW52Tnl1Z1k4bmI5WDYxbGVFL2lUMHd3d05vZHNCckxVVk53Q2sxUlNyV2hk?= =?utf-8?B?WjQ3T1ZxM2dVdVVOZk5kaWh2SGZ5ZVNHYmtqRGVjUGNZeFA0L1Y4VG9mVXBX?= =?utf-8?B?c0UwR0JhbkVQYTRLb1pvWTBGTUZQRjllQ0FoNlh0SXUxTWVhK294K052MnhK?= =?utf-8?B?MExjS1BWaHBja3RPejI5OG05cnBnc0hxM1dDSjRyejQ1ZnMwNHROR0MrQS81?= =?utf-8?B?ZTZRdHV5UjF0b09WOEMzSnJYUENERy8zbm5UcGRlRVloUm8vbnczbEwxUjhW?= =?utf-8?B?TjhQbjZvQ1hsYk5VN2VFT1NtdG50M3VPcG1OQ1hKZDNjd2kxZUk0Z0Z3UlA0?= =?utf-8?B?V2NFcGtwZnJzWHIyYk5yaTZLMlNwblZpYy9tTDU3YS9TVENRL0ZEWW1KMHU1?= =?utf-8?B?ZEdlZUdxWWtSbVl5OUh1T2dueUlzMGpRVVFIMzlSM1NsSGFNN2x4RGhmZjE0?= =?utf-8?B?bUthMHMzd2tSRHQ1eWxBL2pjNU4rZ0FQWVlCbU4rRDYxTHhHNmVGUnYvdHFt?= =?utf-8?B?SC84K0ZCWUlJNWVITmgvdlUyR1RSbzgxR3FmTXF6NXlPei9vSmpNNE1DNlRR?= =?utf-8?B?TG53Nm54ZUFRdi9LSFZaN3NwZzZic3dSNVkyTmpYdGZKaTdZaTNpL2wxQ2Vx?= =?utf-8?B?SUVRTnBRcXl0dWRtYjQ5M05aVE1wTk1VVXBQdTZWakFKSEkxbVhYK1MyZG9W?= =?utf-8?B?NFRpcWVsMlN5OVZkcjJmcEJOR25INzRiL0p0SHlYdjlrenlpRjFYenJ1eUhO?= =?utf-8?B?VVdraU1QcGxUMmtPR29EQlo4M2k0dXJTMGtxTFZFWkhnWXpLZnljemFXZ09J?= =?utf-8?B?UEJsVXkrbTdnV2VzcUJVZzhnUytycnAyQ0k3Qy9scTRHY0w1bDBqR3ZVQXJP?= =?utf-8?B?UXNxWDVNM0JZbW5qMnB4ZHRyRDcwSGhCWEVTb0xsVkpQdC9UOVY0R2E2Vzgz?= =?utf-8?B?V2tiQkRpd3VQUmFPR0FXdFQwWXNxOTFETHZ4R3RWNEk3dnhEaC9ub2VYNFUz?= =?utf-8?B?NjNQS1kwVWllckZ4WHNra1NrUEdhQWdNZ1pOaVE4Szg4clZZMGdvZ0JyQW1E?= =?utf-8?B?eHpsbFFzcW5SUHFzbHB4dmdOM3NVUTAxWXBQSW8xckhVMXh5TDNBTlF0WDFY?= =?utf-8?B?TDh3L1l6L3VKY0JKY3l0YkNrZDJXdEZNaG9ySGxQWEpqRmRxUU03cEJNZ1Zu?= =?utf-8?B?VXM5NjlvRWtyM2o0RE83WlZzc2tLYiswaUFGTDhZdy85RzhnZWFiVkxtOXNZ?= =?utf-8?B?bGkvRk5UaW9ZQWxZUkpuSGY4cHFGK0hIbGlBcVBPMUlEMUNOeS9tWjk3Qi9j?= =?utf-8?B?eTRYb1FWNTE1TERFSzNDY3J0c0daRlZraytERXRvT1N2Z0N4OGZveDNMOXdz?= =?utf-8?Q?vlH5CB3UX+w5i+kI=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad4675a4-7848-43dd-eb70-08df2ac5ce8f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2026 14:08:37.1472 (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: HfBLOtoRBmrRdnpV5/YFbSYoxKcTyuUr7xRWb1cWTtSz6rKodFvdpQyMopnxIIIcHIAndp1vlXsiv7lhzOaYAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR03MB911287 X-purgate-ID: tlsNG-d62444/1792073320-1D272757-331BC68F/0/0 X-purgate-type: clean X-purgate-size: 9320 RnJvbTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCg0K UmVuYW1lIGFuZCBleHBvcnQgdnBjaV9tb2RpZnlfYmFycywgdnBjaV9ndWVzdF9tZW1fYmFyX3ty ZWFkLHdyaXRlfQ0KDQpTaWduZWQtb2ZmLWJ5OiBTdGV3YXJ0IEhpbGRlYnJhbmQgPHN0ZXdhcnQu aGlsZGVicmFuZEBhbWQuY29tPg0KU2lnbmVkLW9mZi1ieTogTXlreXRhIFBvdHVyYWkgPG15a3l0 YV9wb3R1cmFpQGVwYW0uY29tPg0KUmV2aWV3ZWQtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3Rp ZUB2YXRlcy50ZWNoPg0KLS0tDQp2My0+djQ6DQoqIHNxdWFzaCAidnBjaTogcmVuYW1lIGFuZCBl eHBvcnQgdnBjaV9ndWVzdF9tZW1fYmFyX3tyZWFkLHdyaXRlfSIgd2l0aA0KICAidnBjaTogcmVu YW1lIGFuZCBleHBvcnQgdnBjaV9tb2RpZnlfYmFycyINCnYyLT52MzoNCiogbW92ZSBkZWNsYXJh dGlvbiB0byBwcml2YXRlLmgNCnYxLT52Mg0KKiBDb2xsZWN0IFJCcw0KLS0tDQogeGVuL2RyaXZl cnMvdnBjaS9oZWFkZXIuYyAgfCAzNiArKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0t LS0NCiB4ZW4vZHJpdmVycy92cGNpL3ByaXZhdGUuaCB8ICA5ICsrKysrKysrKw0KIDIgZmlsZXMg Y2hhbmdlZCwgMjkgaW5zZXJ0aW9ucygrKSwgMTYgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQg YS94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jIGIveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0K aW5kZXggN2U1ZjRiOGEwMC4uYTRlNTc1YmU0ZSAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Zw Y2kvaGVhZGVyLmMNCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCkBAIC0zMDUsNyAr MzA1LDcgQEAgc3RhdGljIHZvaWQgZGVmZXJfbWFwKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2 LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHkpDQogICAgIHJhaXNlX3NvZnRpcnEoU0NIRURV TEVfU09GVElSUSk7DQogfQ0KIA0KLXN0YXRpYyBpbnQgbW9kaWZ5X2JhcnMoY29uc3Qgc3RydWN0 IHBjaV9kZXYgKnBkZXYsIHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSkNCitpbnQgdnBjaV9t b2RpZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29s IHJvbV9vbmx5KQ0KIHsNCiAgICAgc3RydWN0IHZwY2lfaGVhZGVyICpoZWFkZXIgPSAmcGRldi0+ dnBjaS0+aGVhZGVyOw0KICAgICBzdHJ1Y3QgcGNpX2RldiAqdG1wOw0KQEAgLTU0Niw3ICs1NDYs NyBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayBjbWRfd3JpdGUoDQogICAgICAgICAgKiBtZW1vcnkg ZGVjb2RpbmcgYml0IGhhcyBub3QgYmVlbiBjaGFuZ2VkLCBzbyBsZWF2ZSBldmVyeXRoaW5nIGFz LWlzLA0KICAgICAgICAgICogaG9waW5nIHRoZSBndWVzdCB3aWxsIHJlYWxpemUgYW5kIHRyeSBh Z2Fpbi4NCiAgICAgICAgICAqLw0KLSAgICAgICAgbW9kaWZ5X2JhcnMocGRldiwgY21kLCBmYWxz ZSk7DQorICAgICAgICB2cGNpX21vZGlmeV9iYXJzKHBkZXYsIGNtZCwgZmFsc2UpOw0KICAgICBl bHNlDQogICAgICAgICBwY2lfY29uZl93cml0ZTE2KHBkZXYtPnNiZGYsIHJlZywgY21kKTsNCiB9 DQpAQCAtNjExLDkgKzYxMSw5IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIGJhcl93cml0ZSgNCiAg ICAgcGNpX2NvbmZfd3JpdGUzMihwZGV2LT5zYmRmLCByZWcsIHZhbCk7DQogfQ0KIA0KLXN0YXRp YyB2b2lkIGNmX2NoZWNrIGd1ZXN0X21lbV9iYXJfd3JpdGUoY29uc3Qgc3RydWN0IHBjaV9kZXYg KnBkZXYsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25l ZCBpbnQgcmVnLCB1aW50MzJfdCB2YWwsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB2b2lkICpkYXRhKQ0KK3ZvaWQgY2ZfY2hlY2sgdnBjaV9ndWVzdF9tZW1fYmFy X3dyaXRlKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCByZWcsIHVpbnQzMl90IHZhbCwNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lkICpkYXRhKQ0KIHsNCiAgICAg c3RydWN0IHZwY2lfYmFyICpiYXIgPSBkYXRhOw0KICAgICBib29sIGhpID0gZmFsc2U7DQpAQCAt NjUzLDggKzY1Myw4IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIGd1ZXN0X21lbV9iYXJfd3JpdGUo Y29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsDQogICAgIGJhci0+Z3Vlc3RfYWRkciA9IGd1ZXN0 X2FkZHI7DQogfQ0KIA0KLXN0YXRpYyB1aW50MzJfdCBjZl9jaGVjayBndWVzdF9tZW1fYmFyX3Jl YWQoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsDQotICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgcmVnLCB2b2lkICpkYXRhKQ0KK3VpbnQz Ml90IGNmX2NoZWNrIHZwY2lfZ3Vlc3RfbWVtX2Jhcl9yZWFkKGNvbnN0IHN0cnVjdCBwY2lfZGV2 ICpwZGV2LA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln bmVkIGludCByZWcsIHZvaWQgKmRhdGEpDQogew0KICAgICBjb25zdCBzdHJ1Y3QgdnBjaV9iYXIg KmJhciA9IGRhdGE7DQogICAgIHVpbnQzMl90IHJlZ192YWw7DQpAQCAtNzE0LDEzICs3MTQsMTUg QEAgc3RhdGljIHZvaWQgY2ZfY2hlY2sgcm9tX3dyaXRlKA0KICAgICAgKiBQYXNzIFBDSV9DT01N QU5EX01FTU9SWSBvciAwIHRvIHNpZ25hbCBhIG1hcC91bm1hcCByZXF1ZXN0LCBub3RlIHRoYXQN CiAgICAgICogdGhpcyBmYWJyaWNhdGVkIGNvbW1hbmQgaXMgbmV2ZXIgZ29pbmcgdG8gYmUgd3Jp dHRlbiB0byB0aGUgcmVnaXN0ZXIuDQogICAgICAqLw0KLSAgICBlbHNlIGlmICggbW9kaWZ5X2Jh cnMocGRldiwgbmV3X2VuYWJsZWQgPyBQQ0lfQ09NTUFORF9NRU1PUlkgOiAwLCB0cnVlKSApDQor ICAgIGVsc2UgaWYgKCB2cGNpX21vZGlmeV9iYXJzKHBkZXYsDQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG5ld19lbmFibGVkID8gUENJX0NPTU1BTkRfTUVNT1JZIDogMCwNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdHJ1ZSkgKQ0KICAgICAgICAgLyoNCiAgICAgICAg ICAqIE5vIG1lbW9yeSBoYXMgYmVlbiBhZGRlZCBvciByZW1vdmVkIGZyb20gdGhlIHAybSAoYmVj YXVzZSB0aGUgYWN0dWFsDQogICAgICAgICAgKiBwMm0gY2hhbmdlcyBhcmUgZGVmZXJyZWQgaW4g ZGVmZXJfbWFwKSBhbmQgdGhlIFJPTSBlbmFibGUgYml0IGhhcw0KICAgICAgICAgICogbm90IGJl ZW4gY2hhbmdlZCwgc28gbGVhdmUgZXZlcnl0aGluZyBhcy1pcywgaG9waW5nIHRoZSBndWVzdCB3 aWxsDQogICAgICAgICAgKiByZWFsaXplIGFuZCB0cnkgYWdhaW4uIEl0J3MgaW1wb3J0YW50IHRv IG5vdCB1cGRhdGUgcm9tLT5hZGRyIGluIHRoZQ0KLSAgICAgICAgICogdW5tYXAgY2FzZSBpZiBt b2RpZnlfYmFycyBoYXMgZmFpbGVkLCBvciBmdXR1cmUgYXR0ZW1wdHMgd291bGQNCisgICAgICAg ICAqIHVubWFwIGNhc2UgaWYgdnBjaV9tb2RpZnlfYmFycyBoYXMgZmFpbGVkLCBvciBmdXR1cmUg YXR0ZW1wdHMgd291bGQNCiAgICAgICAgICAqIGF0dGVtcHQgdG8gdW5tYXAgdGhlIHdyb25nIGFk ZHJlc3MuDQogICAgICAgICAgKi8NCiAgICAgICAgIHJldHVybjsNCkBAIC04MDAsOCArODAyLDgg QEAgaW50IHZwY2lfaW5pdF9oZWFkZXIoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQogICAgIC8qDQog ICAgICAqIEZvciBEb21VcywgY2xlYXIgUENJX0NPTU1BTkRfe01BU1RFUixNRU1PUlksSU99IGFu ZCBvdGhlcg0KICAgICAgKiBEb21VLWNvbnRyb2xsYWJsZSBiaXRzIGluIFBDSV9DT01NQU5ELiBE ZXZpY2VzIGFzc2lnbmVkIHRvIERvbVVzIHdpbGwNCi0gICAgICogc3RhcnQgd2l0aCBtZW1vcnkg ZGVjb2RpbmcgZGlzYWJsZWQsIGFuZCBtb2RpZnlfYmFycygpIHdpbGwgbm90IGJlIGNhbGxlZA0K LSAgICAgKiBhdCB0aGUgZW5kIG9mIHRoaXMgZnVuY3Rpb24uDQorICAgICAqIHN0YXJ0IHdpdGgg bWVtb3J5IGRlY29kaW5nIGRpc2FibGVkLCBhbmQgdnBjaV9tb2RpZnlfYmFycygpIHdpbGwgbm90 IGJlDQorICAgICAqIGNhbGxlZCBhdCB0aGUgZW5kIG9mIHRoaXMgZnVuY3Rpb24uDQogICAgICAq Lw0KICAgICBpZiAoICFpc19od2RvbSApDQogICAgICAgICBjbWQgJj0gfihQQ0lfQ09NTUFORF9W R0FfUEFMRVRURSB8IFBDSV9DT01NQU5EX0lOVkFMSURBVEUgfA0KQEAgLTgyNCw4ICs4MjYsOSBA QCBpbnQgdnBjaV9pbml0X2hlYWRlcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiAgICAgICAgICAg ICBiYXJzW2ldLnR5cGUgPSBWUENJX0JBUl9NRU02NF9ISTsNCiAgICAgICAgICAgICByYyA9IHZw Y2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpc19od2RvbSA/IHZwY2lfaHdfcmVhZDMyDQotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA6IGd1ZXN0X21lbV9iYXJfcmVhZCwNCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGlzX2h3ZG9tID8gYmFyX3dyaXRlIDogZ3Vlc3RfbWVt X2Jhcl93cml0ZSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDogdnBjaV9ndWVzdF9tZW1fYmFyX3JlYWQsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpc19od2RvbSA/IGJhcl93cml0ZQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgOiB2cGNpX2d1ZXN0X21lbV9iYXJfd3JpdGUsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICByZWcsIDQsICZiYXJzW2ldKTsNCiAgICAgICAgICAg ICBpZiAoIHJjICkNCiAgICAgICAgICAgICAgICAgZ290byBmYWlsOw0KQEAgLTg4Myw4ICs4ODYs OSBAQCBpbnQgdnBjaV9pbml0X2hlYWRlcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiAgICAgICAg IGJhcnNbaV0ucHJlZmV0Y2hhYmxlID0gdmFsICYgUENJX0JBU0VfQUREUkVTU19NRU1fUFJFRkVU Q0g7DQogDQogICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksDQotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzX2h3ZG9tID8gdnBjaV9od19yZWFkMzIgOiBn dWVzdF9tZW1fYmFyX3JlYWQsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzX2h3 ZG9tID8gYmFyX3dyaXRlIDogZ3Vlc3RfbWVtX2Jhcl93cml0ZSwNCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaXNfaHdkb20gPyB2cGNpX2h3X3JlYWQzMg0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA6IHZwY2lfZ3Vlc3RfbWVtX2Jhcl9yZWFkLA0KKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpc19od2RvbSA/IGJhcl93cml0ZSA6IHZwY2lf Z3Vlc3RfbWVtX2Jhcl93cml0ZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVn LCA0LCAmYmFyc1tpXSk7DQogICAgICAgICBpZiAoIHJjICkNCiAgICAgICAgICAgICBnb3RvIGZh aWw7DQpAQCAtOTI2LDcgKzkzMCw3IEBAIGludCB2cGNpX2luaXRfaGVhZGVyKHN0cnVjdCBwY2lf ZGV2ICpwZGV2KQ0KICAgICAgICAgICAgIGdvdG8gZmFpbDsNCiAgICAgfQ0KIA0KLSAgICByZXR1 cm4gKGNtZCAmIFBDSV9DT01NQU5EX01FTU9SWSkgPyBtb2RpZnlfYmFycyhwZGV2LCBjbWQsIGZh bHNlKSA6IDA7DQorICAgIHJldHVybiAoY21kICYgUENJX0NPTU1BTkRfTUVNT1JZKSA/IHZwY2lf bW9kaWZ5X2JhcnMocGRldiwgY21kLCBmYWxzZSkgOiAwOw0KIA0KICBmYWlsOg0KICAgICBwY2lf Y29uZl93cml0ZTE2KHBkZXYtPnNiZGYsIFBDSV9DT01NQU5ELCBjbWQpOw0KZGlmZiAtLWdpdCBh L3hlbi9kcml2ZXJzL3ZwY2kvcHJpdmF0ZS5oIGIveGVuL2RyaXZlcnMvdnBjaS9wcml2YXRlLmgN CmluZGV4IDI5MDdmNmI0MGYuLmYwMTJmZDE2MGQgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92 cGNpL3ByaXZhdGUuaA0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS9wcml2YXRlLmgNCkBAIC0xMzgs NiArMTM4LDE1IEBAIHN0YXRpYyBpbmxpbmUgc2l6ZV90IHZtc2l4X3RhYmxlX3NpemUoY29uc3Qg c3RydWN0IHZwY2kgKnZwY2ksIHVuc2lnbmVkIGludCBucikNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOCksIDgpOw0KIH0NCiANCisvKiBN YXAvdW5tYXAgdGhlIEJBUnMgb2YgYSB2UENJIGRldmljZS4gKi8NCitpbnQgdnBjaV9tb2RpZnlf YmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJvbV9v bmx5KTsNCisNCit2b2lkIGNmX2NoZWNrIHZwY2lfZ3Vlc3RfbWVtX2Jhcl93cml0ZShjb25zdCBz dHJ1Y3QgcGNpX2RldiAqcGRldiwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bnNpZ25lZCBpbnQgcmVnLCB1aW50MzJfdCB2YWwsDQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdm9pZCAqZGF0YSk7DQorDQordWludDMyX3QgY2ZfY2hlY2sg dnBjaV9ndWVzdF9tZW1fYmFyX3JlYWQoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsDQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHJlZywg dm9pZCAqZGF0YSk7DQogI2VuZGlmIC8qIF9fWEVOX18gKi8NCiANCiAjZW5kaWYgLyogVlBDSV9Q UklWQVRFX0ggKi8NCi0tIA0KMi41NS4wDQo= From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450637.1666078 (Exim 4.92) (envelope-from ) id 1xHM8R-00083W-GW; Thu, 15 Oct 2026 14:08:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450637.1666078; Thu, 15 Oct 2026 14:08: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 1xHM8R-00081j-6E; Thu, 15 Oct 2026 14:08:43 +0000 Received: by outflank-mailman (input) for mailman id 1450637; Thu, 15 Oct 2026 14:08:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHM8P-0007dh-Th for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:08:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHM8P-002ujh-AV for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:08:41 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0de59-e002-0a2a0a5209dd-0a2a4501c5d8-42 for ; Thu, 15 Oct 2026 16:08:41 +0200 Received: from [52.101.65.141] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0de67-5984-0a2a45010019-3465418d2d13-6 for ; Thu, 15 Oct 2026 16:08:41 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by ZR6PR03MB911287.eurprd03.prod.outlook.com (2603:10a6:910:d7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 14:08:38 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.012; Thu, 15 Oct 2026 14:08: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=H7akffVPEMKMvURS8uV5kMLokeRKWHmXEaMlAmm0RV+UNy30YCJj24t9V0Vbp7XUStcQenhu2X/MFewp/Z3n1HHfYHqDl1aqInQEpz3t1MtsTCHRK0BrOhKMYG+k7GE6zU/pmw41CiDwaa0jWP3vjf4wKBYT3WiFa2b0mkcdjvAU2NzGxBhBB0MSrPcTBAgYi0hRajhnm1qTEzTw3BkyUstQz+5kx8rl/M38LcYRtIZYLZoEuaNT2UOroGOTUkwlRO18gqTS0npHypOJG4G54ezQuZaWB67NMbTA5Ms9NAJLCN1nRLFRi4o0FWX8D5vH1b/QzUML/CkvF5cCRpZo9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q709r3z1L7Vccp+eFky7K4brl1wUlRYM1lE4YWMxjYY=; b=Ijz37mfYv2ogozPyqIRkdg+0F05cQbBwxg9TOQmU9oA35C5e2u+fkvBTR6V1vudCrw+niQcdpDD/DCe84Sg9YFNGntgGUSSOrYStCGxZTZMXgh4opz8VLJieHJj1CNm7Ryjygd080823/jppiVtwfuVW63JvyLDqYqAp5UtvkeU03HvwEuHJ8u9uHPrT2G5KnDQE4rkXA7sJUd8J9B+QLN+fUEj611dvdutmZdDTPcVKjjgGPR1NFMDT0jRTR4lUGz/PuRK4FJyPjhdCCFu4xyzXV3knxd5S9xJOdhK8p1tB0pi6Q7IH6m0K/Smq1UaKsAJTlucPclIAWSG6lWyqzQ== 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=q709r3z1L7Vccp+eFky7K4brl1wUlRYM1lE4YWMxjYY=; b=ahNPwi+8Yl0FPLfJmgALJC5Y3VfTukDCvlXCE4IeodXnKk6sYnQBamPdmJobHcwk8vVEM/BP8XjvV2gWfEx3nRccn3JuyP+uQh2LrHpTuyUxaZldHCCNBM0StoCEZsrRW6p+s4tOGdC9+pFc/iDL98tIj7uD3n609WVVGUbGfidbd2dQj7CWCsY5pLP1fAovyRa1Z+nX0W+w/DTLwxl6Kut97Pcp7n/mBb3lVd6OrKZEmSzQx55dA4gUDoKvIBmFRv5fx83zJyjJzPlSnO4OYM5au96cAHcsGnVV9E+HA8k4Ce6VDdcU1LcdcgzdJWk/MhZfOKQ5a8+0V55sQq234w== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Mykyta Poturai Subject: [PATCH v4 3/5] vpci: allow queueing of mapping operations Thread-Topic: [PATCH v4 3/5] vpci: allow queueing of mapping operations Thread-Index: AQHdXK6sLIWYPlc7c0iRpur2gCm1vA== Date: Thu, 15 Oct 2026 14:08:38 +0000 Message-ID: <14cc4abdcf4c3c3d9a620cf4df3ec87e7b11bd13.1792072426.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|ZR6PR03MB911287:EE_ x-ms-office365-filtering-correlation-id: 25d45f4e-c4c7-4a5d-199a-08df2ac5cf0f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|38070700021|56012099006|11063799006|261009223027099003|10067099003|22082099003|18002099003|6133799003; x-microsoft-antispam-message-info: 6hJMR19HiWYMqKOU8wonIRjVmuLZK/zNLLBUZm/bSg/G922Wp77JO3WJUGsXv+IY1JA/IMEp2nIuKDxEem4uRMMamJfM+fZ/B1ng5/CowRA2dZC1viY73K5uZu84D05FvzmivPT52ZW2xwzSJ9Tbm/WbBxcQ668stnQFQ9eiQ+0V+BYH3VhqkThh4GayjQUhigEQl6VwsFcsGmLSkpf9+YKex21NX56/6Tr4zAL41s0xb37Wmm86U3nJuYrKob7l9/f/Siasp7rfg9e4eTwFCy/6oWMCZEMOvMn4lhybpbsgDc2VXaecoPTSHvB06CUSZUvUsYogz5ni8Tfujy95SG6ONKw4JlkxERqzQiZTn3ymKI4xHBk1W4mLNxfCK+hKEUqvHGNHswRwMCN2dw8qGL0GeoSl2js399pRMrn96ZU+UxhlArwaCGZNTJTqNqU08WFSxO2LVr1g/QT4lKW41lgutpdooIyLhfX5c+BERs7+8R6HFygRyoWwuUe14fbLyPP6SgcAqUL0u/0hjo0usRvF6jeP0fatwkGP2xmltu6GEX1B3rKyMueXkwc4DAnl2m+oMXyi2uRROPxZm9bkSliqtk9JBxniRwSbpJGynxpChkWl9NYthHe2w6KLpv+oIHt40T6ikt31ZAAtI+WAiWwl9COAzWiAUa4ESBZsYZc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(38070700021)(56012099006)(11063799006)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TmFwTGVBeEcvenM4RVIxMU9MU2ZETlZjVGtiMVh2akhoUGpiN056anNBcFpk?= =?utf-8?B?WnYwdlRMdldrWFhCMklxbVAzUVRHdEdOWFBwUzdqdFNDVUFWL3A0OGdueC82?= =?utf-8?B?VHY2Q1lwMWhrWWdvbUtDWS9oZ3Q5eS9wblZlVjVmOW1OQ3p6Z3ExOUlXRGJP?= =?utf-8?B?a0MrUlpiaG4xMU0vUEhJUmtYdWI3OEhNSzVPc0ZTak8yL3Q3RFduL3o1ZXdS?= =?utf-8?B?V3VnZFYyMDFKVk9QWnFCcHh5Q3AvaGNiZTg0SGxuTEc4T3hSdDhiT0E2cUxB?= =?utf-8?B?VVFWMFVIVUtySWJOdDVuRnZMbTc2MmFZc2wrOVpMcnZnVXRSTUpac2pyYnZS?= =?utf-8?B?dkJHZU5BOE1ZbWFtT1o2K01hTGRYRXRMSkxmbjVrQUUzVG1US0ZadE9XVjhi?= =?utf-8?B?akhYMUVMSG16eVE4RVdod1BmMFhOVXN3TkgvREJMTEF3MWhFZFJjNlIwUXFr?= =?utf-8?B?UG51b05NcmhuR0l2d3Q3VDdscXpaTFdsSktVWHpmT1BsQlNLN3dtVk40OEZG?= =?utf-8?B?aUxOcTV1R0VpSUh6dDhoVVZ4NktrTnpSazl2NW9tbnBlRks1M1VkZmpyOU4v?= =?utf-8?B?SUFrZERUcm5iV2lWUzE2NEdCWXRRZExlanZOUnFTMjNCbjVLSWVCamk5bno1?= =?utf-8?B?bjJPY1ZQd0FhQWRxZFlYcDR1MTdkbCtVdVlpdUxlcDc5cEhMbVN4ZjRVUHRU?= =?utf-8?B?bnlXWWpmSUlvQUkrQVpVY0FieHd5eUI0RnBEa1RqbXlZSjV2MVRROEhlQkdw?= =?utf-8?B?VnZiUTQ4TUJucEl4dTJGSEk5WXRURnFhMXhvSkxMNExvTFdFSmFRRUlaRE5P?= =?utf-8?B?T3hWV3diSm1lTXZtNnFJVjR4Z05QWHZOaVFtdEw5RzlldzBOZkRBQksvVG52?= =?utf-8?B?Z1hleDkrTkVjZ2h0TzBmOFN5bnBGMTJNbWIxWTlWWEx3YmRob0JKeFlIelFH?= =?utf-8?B?VGdzdGpTdE9HMnlXc0Q1Z3RTRVdoa0hTTDIxMGlZYzJxMy9NL2hITXprekV1?= =?utf-8?B?WURWdSs5Yks0Q1NhT0RHNHlkVVo3WFpoMkIvMjFOaTlhZUl0d2kwalNMdnJ6?= =?utf-8?B?U3RqR1BkTnQ2TUYwS1lrT2E4emI2ZjE4NzNBdERFNS9scXNyWmg3ZFBON3FE?= =?utf-8?B?WGRTcXB4cEVQM3QxMGIra1hTS1VJNDhudUphRFRKMDJkR2RlbEZIL3BGNis2?= =?utf-8?B?Q2pJd2hDUW5uUHROVFNzQkpEUGpwZGNUWXMvRW45MXM5YVpCK3g3NHZJemp3?= =?utf-8?B?OUVMR1BjeWh1akZ2M09oVjduSkxxUjZqQldZYW1RaEVZY3ZBYUwrTy8vaXEy?= =?utf-8?B?c0JrL3JoeDJNZVIwWUJQQ3IxSkNHaFloS0ZvSnQ0Z0g0eldhQzhqMzZiWkd5?= =?utf-8?B?TDNDT1BLODJVRGVVSTV0dmNDdXN5eTZCcU1NUWJYelU0c2ptNDNhSmVYV3o1?= =?utf-8?B?OUYwWCtZODh0dXdGdVcyVEFEVmtIRTR2N3ovUnFKdS9ERjVQQlBkWTU1QlJu?= =?utf-8?B?QU5xajd0OVJWNTk5RHNqU0s5V2lFZmRnV0N5b3NrSHRzKzNzS0E3V0RrekhR?= =?utf-8?B?c3NGVjVNRWJsZ3hWOHdUUGFFY2FyQTVQWmM2MmluWUt4UUhEcWxiWHE2THJh?= =?utf-8?B?S0pydms5WXJkNUxEUEdCRitwUGk0enU2empTamxqcEdqb1VLdGlrV0NDZWFY?= =?utf-8?B?ZzM4R2tMMC9EM3gzTGZFd0lQWjc0QSt1NXJuTW8xS093N05tL3M1WUxTdERZ?= =?utf-8?B?dEltQTlyN0cwUkxzUmlMN1cwNHFOb24yZzRzRXRjbUdqM2Nid0dqYlJsZ1Fs?= =?utf-8?B?YVBJZ1A2NFNYam15ZEo3SGgzK092dGJMS09XZ085eTl5blRLUzAzUjl6UzV5?= =?utf-8?B?K1hPTWVpN2R3VG5yMjFyR0ZtMUUyZ1k1TmJKcy9FQUVKTmFvWW5MUjBQMkln?= =?utf-8?B?aklQQXBVUWVQVElLekFOdEgybzFSbis2em5INTErZ2hGNVpaZW5LSDJ1VGtz?= =?utf-8?B?dEIwTzROaWd1ZjdCZnA1ZVU4aGpvRjBBTE9nQ3UrNEN1NFUrTUFKeEF3UzZm?= =?utf-8?B?ajVWS2txMGNoL1JHTFFKSW9Od3RHRVgxRXVvK3pTSFVhMFF2STNta04zblo2?= =?utf-8?B?bnNPYXgvZHRmazR0ZGdzeU82dnZ1Ykw5RHlha3c0TXh5TlhTYjUvK3E1Vzdz?= =?utf-8?B?Szk2aWhwdnR2dlIyM1pKN09EUmVxQ1hOK1NIMGpLUWhuMG9rbTd3VXFwbFVY?= =?utf-8?B?Q1hBYTQ3ekxydm1uSHlTQ0VvUC9xTEVPVHc3K3U2dkcrTTR5Umdldkh1dmhm?= =?utf-8?B?bmRTMGhKd281cEZWWXlwTFJKaURXZVFScGhUTmZFUDNET3FtRDNZVVYzMHZH?= =?utf-8?Q?WR+J+X1oZT/ieyyc=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25d45f4e-c4c7-4a5d-199a-08df2ac5cf0f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2026 14:08:38.0654 (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: sr9t3aXwU0OgR77P8xidWyTprnd/A/PvugxBdTZFwsBpsFvuO/ZMv+fScLOy67+j1TskLQOt57MWYOi4OhlErQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR03MB911287 X-purgate-ID: tlsNG-d62444/1792073321-BDA7E757-BC54B121/0/0 X-purgate-type: clean X-purgate-size: 26964 RnJvbTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCg0K SW50cm9kdWNlIHZQQ0kgQkFSIG1hcHBpbmcgdGFzayBxdWV1ZS4gU3RvcmUgaW5mb3JtYXRpb24g bmVlZGVkIHRvDQptYXAvdW5tYXAgQkFScyBpbiBzdHJ1Y3QgdnBjaV9tYXBfdGFzay4gQWxsb3cg cXVldWVpbmcgb2YgQkFSIG1hcC91bm1hcA0Kb3BlcmF0aW9ucyBpbiBhIGxpc3QsIHRodXMgbWFr aW5nIGl0IHBvc3NpYmxlIHRvIHBlcmZvcm0gbXVsdGlwbGUgcDJtDQpvcGVyYXRpb25zIGFzc29j aWF0ZWQgd2l0aCBzaW5nbGUgUENJIGNvbmZpZyBzcGFjZSByZWdpc3RlciBhY2Nlc3MuDQoNClRo ZSByYW5nZXNldHMgZGVzY3JpYmluZyB0aGUgcmFuZ2VzIHRvIGJlICh1biltYXBwZWQgbW92ZSBm cm9tIHN0cnVjdA0KdnBjaV9iYXIgaW50byB0aGUgdGFzay4gVGhleSBhcmUgb25seSBsaXZlIGZv ciB0aGUgZHVyYXRpb24gb2YgdGhlDQpvcGVyYXRpb24sIGFuZCBhIHNpbmdsZSBwZXItZGV2aWNl IHNldCBjYW5ub3QgZGVzY3JpYmUgbW9yZSB0aGFuIG9uZQ0KcXVldWVkIG9wZXJhdGlvbi4gQWxs b2NhdGUgdGhlbSBhbG9uZyB3aXRoIHRoZSB0YXNrIGFuZCBmcmVlIHRoZW0gb25jZQ0KdGhlIHRh c2sgaGFzIGJlZW4gcHJvY2Vzc2VkLg0KDQpUaGlzIGlzIHByZXBhcmF0b3J5IHdvcmsgZm9yIGZ1 cnRoZXIgY2hhbmdlcyB0aGF0IG5lZWQgdG8gcGVyZm9ybQ0KbXVsdGlwbGUgdW5tYXAvbWFwIG9w ZXJhdGlvbnMgYmVmb3JlIHJldHVybmluZyB0byBndWVzdC4NCg0KQXQgdGhlIG1vbWVudCwgb25s eSBhIHNpbmdsZSBvcGVyYXRpb24gd2lsbCBiZSBxdWV1ZWQuIEhvd2V2ZXIsIHdoZW4NCm11bHRp cGxlIG9wZXJhdGlvbnMgYXJlIHF1ZXVlZCwgdGhlcmUgaXMgYSBjaGVjayBpbiBtb2RpZnlfYmFy cygpIHRvDQpza2lwIEJBUnMgYWxyZWFkeSBpbiB0aGUgcmVxdWVzdGVkIHN0YXRlIHRoYXQgd2ls bCBubyBsb25nZXIgYmUNCmFjY3VyYXRlLiBSZW1vdmUgdGhpcyBjaGVjayBpbiBwcmVwYXJhdGlv biBvZiB1cGNvbWluZyBjaGFuZ2VzLg0KDQpBbWVuZHM6IDYyMmJkZDk2MjgyMiAoInZwY2kvaGVh ZGVyOiBoYW5kbGUgcDJtIHJhbmdlIHNldHMgcGVyIEJBUiIpDQpNZXNzYWdlLUlEOiA8MjAyNjA0 MDYxOTEyMDMuOTc2NjItMy1zdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NClNpZ25lZC1vZmYt Ynk6IFN0ZXdhcnQgSGlsZGVicmFuZCA8c3Rld2FydC5oaWxkZWJyYW5kQGFtZC5jb20+DQpTaWdu ZWQtb2ZmLWJ5OiBNeWt5dGEgUG90dXJhaSA8bXlreXRhX3BvdHVyYWlAZXBhbS5jb20+DQotLS0N CnYzLT52NDoNCiogZHJvcCAidnBjaTogVXNlIHBlcnZjcHUgcmFuZ2VzIGZvciBCQVIgbWFwcGlu ZyI7IHRoZSByYW5nZXNldHMgYXJlDQogIG5vdyBhbGxvY2F0ZWQgcGVyIHRhc2sgaGVyZSByYXRo ZXIgdGhhbiBwZXIgdmNwdSwgc28gdGhhdCBwYXRjaCBvbmx5DQogIGFkZGVkIGNvZGUgdGhpcyBv bmUgcmVtb3ZlZCBhZ2Fpbg0KKiBub24tZnVuY3Rpb25hbCBjaHVybiBzcGxpdCBvdXQgaW50byAi dnBjaTogdXNlIGEgbG9jYWwgdmFyaWFibGUgZm9yDQogIHRoZSBCQVIgcmFuZ2VzZXQiDQoNCnYy LT52MzoNCiogbmV3IHBhdGNoIGluIHRoaXMgc2VyaWVzLCBib3Jyb3dlZCBmcm9tIFsxXQ0KDQpb MV06IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzIwMjYwNDA2MTkxMjAzLjk3NjYyLTEtc3Rld2Fy dC5oaWxkZWJyYW5kQGFtZC5jb20vMjAyNjA0MDYxOTEyMDMuOTc2NjItMy1zdGV3YXJ0LmhpbGRl YnJhbmRAYW1kLmNvbS8NCi0tLQ0KIHhlbi9jb21tb24vZG9tYWluLmMgICAgICAgfCAgIDIgKw0K IHhlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgfCAyMzIgKysrKysrKysrKysrKysrKysrKysrKysr LS0tLS0tLS0tLS0tLS0NCiB4ZW4vZHJpdmVycy92cGNpL3ZwY2kuYyAgIHwgIDEwICstDQogeGVu L2luY2x1ZGUveGVuL3ZwY2kuaCAgICB8ICAyMSArKystDQogNCBmaWxlcyBjaGFuZ2VkLCAxNzMg aW5zZXJ0aW9ucygrKSwgOTIgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS94ZW4vY29tbW9u L2RvbWFpbi5jIGIveGVuL2NvbW1vbi9kb21haW4uYw0KaW5kZXggNmI1MjcxMzUxOC4uOGI1NDYz NWIzMyAxMDA2NDQNCi0tLSBhL3hlbi9jb21tb24vZG9tYWluLmMNCisrKyBiL3hlbi9jb21tb24v ZG9tYWluLmMNCkBAIC01MDgsNiArNTA4LDggQEAgc3RydWN0IHZjcHUgKnZjcHVfY3JlYXRlKHN0 cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCB2Y3B1X2lkKQ0KICAgICBpZiAoIGFyY2hfdmNw dV9jcmVhdGUodikgIT0gMCApDQogICAgICAgICBnb3RvIGZhaWxfc2NoZWQ7DQogDQorICAgIHZw Y2lfdmNwdV9pbml0KHYpOw0KKw0KICAgICBkLT52Y3B1W3ZjcHVfaWRdID0gdjsNCiAgICAgaWYg KCB2Y3B1X2lkICE9IDAgKQ0KICAgICB7DQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS9o ZWFkZXIuYyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCmluZGV4IDIzNDEyYmNhZmEuLjAx ODgxZTVlYjIgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jDQorKysgYi94 ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jDQpAQCAtMjMsNiArMjMsNyBAQA0KICNpbmNsdWRlIDx4 ZW4vbGliLmg+DQogI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KICNpbmNsdWRlIDx4ZW4vc29mdGly cS5oPg0KKyNpbmNsdWRlIDx4ZW4veHZtYWxsb2MuaD4NCiANCiAjaW5jbHVkZSA8eHNtL3hzbS5o Pg0KIA0KQEAgLTM1LDcgKzM2LDcgQEANCiANCiBzdHJ1Y3QgbWFwX2RhdGEgew0KICAgICBzdHJ1 Y3QgZG9tYWluICpkOw0KLSAgICBjb25zdCBzdHJ1Y3QgdnBjaV9iYXIgKmJhcjsNCisgICAgY29u c3Qgc3RydWN0IHZwY2lfYmFyX21hcCAqYmFyOw0KICAgICBib29sIG1hcDsNCiB9Ow0KIA0KQEAg LTE3NCwzMiArMTc1LDIzIEBAIHN0YXRpYyB2b2lkIG1vZGlmeV9kZWNvZGluZyhjb25zdCBzdHJ1 Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLA0KICAgICAgICAgQVNTRVJUX1VOUkVBQ0hB QkxFKCk7DQogfQ0KIA0KLWJvb2wgdnBjaV9wcm9jZXNzX3BlbmRpbmcoc3RydWN0IHZjcHUgKnYp DQorc3RhdGljIGludCB2cGNpX3Byb2Nlc3NfbWFwX3Rhc2soc3RydWN0IHZwY2lfbWFwX3Rhc2sg KnRhc2ssIHN0cnVjdCB2Y3B1ICp2KQ0KIHsNCi0gICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBk ZXYgPSB2LT52cGNpLnBkZXY7DQotICAgIHN0cnVjdCB2cGNpX2hlYWRlciAqaGVhZGVyID0gTlVM TDsNCiAgICAgdW5zaWduZWQgaW50IGk7DQorICAgIGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2 ID0gdGFzay0+cGRldjsNCiANCi0gICAgaWYgKCAhcGRldiApDQotICAgICAgICByZXR1cm4gZmFs c2U7DQotDQotICAgIHJlYWRfbG9jaygmdi0+ZG9tYWluLT5wY2lfbG9jayk7DQorICAgIEFTU0VS VChyd19pc19sb2NrZWQoJnBkZXYtPmRvbWFpbi0+cGNpX2xvY2spKTsNCiANCiAgICAgaWYgKCAh cGRldi0+dnBjaSB8fCAodi0+ZG9tYWluICE9IHBkZXYtPmRvbWFpbikgKQ0KLSAgICB7DQotICAg ICAgICB2LT52cGNpLnBkZXYgPSBOVUxMOw0KLSAgICAgICAgcmVhZF91bmxvY2soJnYtPmRvbWFp bi0+cGNpX2xvY2spOw0KLSAgICAgICAgcmV0dXJuIGZhbHNlOw0KLSAgICB9DQorICAgICAgICBy ZXR1cm4gLUVJTlZBTDsNCiANCi0gICAgaGVhZGVyID0gJnBkZXYtPnZwY2ktPmhlYWRlcjsNCi0g ICAgZm9yICggaSA9IDA7IGkgPCBBUlJBWV9TSVpFKGhlYWRlci0+YmFycyk7IGkrKyApDQorICAg IGZvciAoIGkgPSAwOyBpIDwgQVJSQVlfU0laRSh0YXNrLT5iYXJzKTsgaSsrICkNCiAgICAgew0K LSAgICAgICAgc3RydWN0IHZwY2lfYmFyICpiYXIgPSAmaGVhZGVyLT5iYXJzW2ldOw0KKyAgICAg ICAgc3RydWN0IHZwY2lfYmFyX21hcCAqYmFyID0gJnRhc2stPmJhcnNbaV07DQogICAgICAgICBz dHJ1Y3QgcmFuZ2VzZXQgKm1lbSA9IGJhci0+bWVtOw0KICAgICAgICAgc3RydWN0IG1hcF9kYXRh IGRhdGEgPSB7DQotICAgICAgICAgICAgLmQgPSB2LT5kb21haW4sDQotICAgICAgICAgICAgLm1h cCA9IHYtPnZwY2kuY21kICYgUENJX0NPTU1BTkRfTUVNT1JZLA0KKyAgICAgICAgICAgIC5kID0g cGRldi0+ZG9tYWluLA0KKyAgICAgICAgICAgIC5tYXAgPSB0YXNrLT5jbWQgJiBQQ0lfQ09NTUFO RF9NRU1PUlksDQogICAgICAgICAgICAgLmJhciA9IGJhciwNCiAgICAgICAgIH07DQogICAgICAg ICBpbnQgcmM7DQpAQCAtMjEwLDM4ICsyMDIsODggQEAgYm9vbCB2cGNpX3Byb2Nlc3NfcGVuZGlu ZyhzdHJ1Y3QgdmNwdSAqdikNCiAgICAgICAgIHJjID0gcmFuZ2VzZXRfY29uc3VtZV9yYW5nZXMo bWVtLCBtYXBfcmFuZ2UsICZkYXRhKTsNCiANCiAgICAgICAgIGlmICggcmMgPT0gLUVSRVNUQVJU ICkNCi0gICAgICAgIHsNCi0gICAgICAgICAgICByZWFkX3VubG9jaygmdi0+ZG9tYWluLT5wY2lf bG9jayk7DQotICAgICAgICAgICAgcmV0dXJuIHRydWU7DQotICAgICAgICB9DQorICAgICAgICAg ICAgcmV0dXJuIHJjOw0KIA0KICAgICAgICAgaWYgKCByYyApDQogICAgICAgICB7DQogICAgICAg ICAgICAgc3Bpbl9sb2NrKCZwZGV2LT52cGNpLT5sb2NrKTsNCiAgICAgICAgICAgICAvKiBEaXNh YmxlIG1lbW9yeSBkZWNvZGluZyB1bmNvbmRpdGlvbmFsbHkgb24gZmFpbHVyZS4gKi8NCi0gICAg ICAgICAgICBtb2RpZnlfZGVjb2RpbmcocGRldiwgdi0+dnBjaS5jbWQgJiB+UENJX0NPTU1BTkRf TUVNT1JZLCBmYWxzZSk7DQorICAgICAgICAgICAgbW9kaWZ5X2RlY29kaW5nKHBkZXYsIHRhc2st PmNtZCAmIH5QQ0lfQ09NTUFORF9NRU1PUlksIGZhbHNlKTsNCiAgICAgICAgICAgICBzcGluX3Vu bG9jaygmcGRldi0+dnBjaS0+bG9jayk7DQogDQotICAgICAgICAgICAgLyogQ2xlYW4gYWxsIHRo ZSByYW5nZXNldHMgKi8NCi0gICAgICAgICAgICBmb3IgKCBpID0gMDsgaSA8IEFSUkFZX1NJWkUo aGVhZGVyLT5iYXJzKTsgaSsrICkNCi0gICAgICAgICAgICAgICAgaWYgKCAhcmFuZ2VzZXRfaXNf ZW1wdHkoaGVhZGVyLT5iYXJzW2ldLm1lbSkgKQ0KLSAgICAgICAgICAgICAgICAgICAgIHJhbmdl c2V0X3B1cmdlKGhlYWRlci0+YmFyc1tpXS5tZW0pOw0KKyAgICAgICAgICAgIGlmICggIWlzX2hh cmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4pICkNCisgICAgICAgICAgICAgICAgZG9tYWluX2Ny YXNoKHBkZXYtPmRvbWFpbik7DQogDQotICAgICAgICAgICAgdi0+dnBjaS5wZGV2ID0gTlVMTDsN CisgICAgICAgICAgICByZXR1cm4gcmM7DQorICAgICAgICB9DQorICAgIH0NCisNCisgICAgc3Bp bl9sb2NrKCZwZGV2LT52cGNpLT5sb2NrKTsNCisgICAgbW9kaWZ5X2RlY29kaW5nKHBkZXYsIHRh c2stPmNtZCwgdGFzay0+cm9tX29ubHkpOw0KKyAgICBzcGluX3VubG9jaygmcGRldi0+dnBjaS0+ bG9jayk7DQorDQorICAgIHJldHVybiAwOw0KK30NCiANCitzdGF0aWMgdm9pZCBkZXN0cm95X21h cF90YXNrKHN0cnVjdCB2cGNpX21hcF90YXNrICp0YXNrKQ0KK3sNCisgICAgdW5zaWduZWQgaW50 IGk7DQorDQorICAgIGlmICggIXRhc2sgKQ0KKyAgICB7DQorICAgICAgICBBU1NFUlRfVU5SRUFD SEFCTEUoKTsNCisgICAgICAgIHJldHVybjsNCisgICAgfQ0KKw0KKyAgICBmb3IgKCBpID0gMDsg aSA8IEFSUkFZX1NJWkUodGFzay0+YmFycyk7IGkrKyApDQorICAgICAgICByYW5nZXNldF9kZXN0 cm95KHRhc2stPmJhcnNbaV0ubWVtKTsNCisNCisgICAgeHZmcmVlKHRhc2spOw0KK30NCisNCitz dGF0aWMgdm9pZCBjbGVhcl9tYXBfcXVldWUoc3RydWN0IHZjcHUgKnYpDQorew0KKyAgICBzdHJ1 Y3QgdnBjaV9tYXBfdGFzayAqdGFzazsNCisNCisgICAgd2hpbGUgKCAodGFzayA9IGxpc3RfZmly c3RfZW50cnlfb3JfbnVsbCgmdi0+dnBjaS50YXNrX3F1ZXVlLA0KKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB2cGNpX21hcF90YXNrLA0KKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5leHQpKSAhPSBOVUxMICkN CisgICAgew0KKyAgICAgICAgbGlzdF9kZWwoJnRhc2stPm5leHQpOw0KKyAgICAgICAgZGVzdHJv eV9tYXBfdGFzayh0YXNrKTsNCisgICAgfQ0KK30NCisNCitib29sIHZwY2lfcHJvY2Vzc19wZW5k aW5nKHN0cnVjdCB2Y3B1ICp2KQ0KK3sNCisgICAgc3RydWN0IHZwY2lfbWFwX3Rhc2sgKnRhc2s7 DQorDQorICAgIGlmICggbGlzdF9lbXB0eSgmdi0+dnBjaS50YXNrX3F1ZXVlKSApDQorICAgICAg ICByZXR1cm4gZmFsc2U7DQorDQorICAgIHJlYWRfbG9jaygmdi0+ZG9tYWluLT5wY2lfbG9jayk7 DQorDQorICAgIHdoaWxlICggKHRhc2sgPSBsaXN0X2ZpcnN0X2VudHJ5X29yX251bGwoJnYtPnZw Y2kudGFza19xdWV1ZSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHJ1Y3QgdnBjaV9tYXBfdGFzaywNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBuZXh0KSkgIT0gTlVMTCApDQorICAgIHsNCisgICAgICAgIGludCBy YyA9IHZwY2lfcHJvY2Vzc19tYXBfdGFzayh0YXNrLCB2KTsNCisNCisgICAgICAgIGlmICggcmMg PT0gLUVSRVNUQVJUICkNCisgICAgICAgIHsNCiAgICAgICAgICAgICByZWFkX3VubG9jaygmdi0+ ZG9tYWluLT5wY2lfbG9jayk7DQorICAgICAgICAgICAgcmV0dXJuIHRydWU7DQorICAgICAgICB9 DQogDQotICAgICAgICAgICAgaWYgKCAhaXNfaGFyZHdhcmVfZG9tYWluKHYtPmRvbWFpbikgKQ0K LSAgICAgICAgICAgICAgICBkb21haW5fY3Jhc2godi0+ZG9tYWluKTsNCisgICAgICAgIGxpc3Rf ZGVsKCZ0YXNrLT5uZXh0KTsNCisgICAgICAgIGRlc3Ryb3lfbWFwX3Rhc2sodGFzayk7DQogDQot ICAgICAgICAgICAgcmV0dXJuIGZhbHNlOw0KKyAgICAgICAgaWYgKCByYyApDQorICAgICAgICB7 DQorICAgICAgICAgICAgY2xlYXJfbWFwX3F1ZXVlKHYpOw0KKyAgICAgICAgICAgIGJyZWFrOw0K ICAgICAgICAgfQ0KICAgICB9DQotICAgIHYtPnZwY2kucGRldiA9IE5VTEw7DQotDQotICAgIHNw aW5fbG9jaygmcGRldi0+dnBjaS0+bG9jayk7DQotICAgIG1vZGlmeV9kZWNvZGluZyhwZGV2LCB2 LT52cGNpLmNtZCwgdi0+dnBjaS5yb21fb25seSk7DQotICAgIHNwaW5fdW5sb2NrKCZwZGV2LT52 cGNpLT5sb2NrKTsNCiANCiAgICAgcmVhZF91bmxvY2soJnYtPmRvbWFpbi0+cGNpX2xvY2spOw0K IA0KQEAgLTI0OSwxNyArMjkxLDE2IEBAIGJvb2wgdnBjaV9wcm9jZXNzX3BlbmRpbmcoc3RydWN0 IHZjcHUgKnYpDQogfQ0KIA0KIHN0YXRpYyBpbnQgX19pbml0IGFwcGx5X21hcChzdHJ1Y3QgZG9t YWluICpkLCBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCi0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgdWludDE2X3QgY21kKQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1 Y3QgdnBjaV9tYXBfdGFzayAqdGFzaykNCiB7DQotICAgIHN0cnVjdCB2cGNpX2hlYWRlciAqaGVh ZGVyID0gJnBkZXYtPnZwY2ktPmhlYWRlcjsNCiAgICAgaW50IHJjID0gMDsNCiAgICAgdW5zaWdu ZWQgaW50IGk7DQogDQogICAgIEFTU0VSVChyd19pc193cml0ZV9sb2NrZWQoJmQtPnBjaV9sb2Nr KSk7DQogDQotICAgIGZvciAoIGkgPSAwOyBpIDwgQVJSQVlfU0laRShoZWFkZXItPmJhcnMpOyBp KysgKQ0KKyAgICBmb3IgKCBpID0gMDsgaSA8IEFSUkFZX1NJWkUodGFzay0+YmFycyk7IGkrKyAp DQogICAgIHsNCi0gICAgICAgIHN0cnVjdCB2cGNpX2JhciAqYmFyID0gJmhlYWRlci0+YmFyc1tp XTsNCisgICAgICAgIHN0cnVjdCB2cGNpX2Jhcl9tYXAgKmJhciA9ICZ0YXNrLT5iYXJzW2ldOw0K ICAgICAgICAgc3RydWN0IHJhbmdlc2V0ICptZW0gPSBiYXItPm1lbTsNCiAgICAgICAgIHN0cnVj dCBtYXBfZGF0YSBkYXRhID0geyAuZCA9IGQsIC5tYXAgPSB0cnVlLCAuYmFyID0gYmFyIH07DQog DQpAQCAtMjgwLDEyICszMjEsNDggQEAgc3RhdGljIGludCBfX2luaXQgYXBwbHlfbWFwKHN0cnVj dCBkb21haW4gKmQsIGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KICAgICAgICAgfQ0KICAg ICB9DQogICAgIGlmICggIXJjICkNCi0gICAgICAgIG1vZGlmeV9kZWNvZGluZyhwZGV2LCBjbWQs IGZhbHNlKTsNCisgICAgICAgIG1vZGlmeV9kZWNvZGluZyhwZGV2LCB0YXNrLT5jbWQsIGZhbHNl KTsNCiANCiAgICAgcmV0dXJuIHJjOw0KIH0NCiANCi1zdGF0aWMgdm9pZCBkZWZlcl9tYXAoY29u c3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSkNCitz dGF0aWMgc3RydWN0IHZwY2lfbWFwX3Rhc2sgKmFsbG9jX21hcF90YXNrKGNvbnN0IHN0cnVjdCBw Y2lfZGV2ICpwZGV2LA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdWludDE2X3QgY21kLCBib29sIHJvbV9vbmx5KQ0KK3sNCisgICAgc3RydWN0IHZwY2lfbWFw X3Rhc2sgKnRhc2s7DQorICAgIHVuc2lnbmVkIGludCBpOw0KKw0KKyAgICB0YXNrID0geHZ6YWxs b2Moc3RydWN0IHZwY2lfbWFwX3Rhc2spOw0KKw0KKyAgICBpZiAoICF0YXNrICkNCisgICAgICAg IHJldHVybiBOVUxMOw0KKw0KKyAgICBmb3IgKCBpID0gMDsgaSA8IEFSUkFZX1NJWkUodGFzay0+ YmFycyk7IGkrKyApDQorICAgIHsNCisgICAgICAgIGlmICggIU1BUFBBQkxFX0JBUigmcGRldi0+ dnBjaS0+aGVhZGVyLmJhcnNbaV0pICkNCisgICAgICAgICAgICBjb250aW51ZTsNCisNCisgICAg ICAgIHRhc2stPmJhcnNbaV0ubWVtID0gcmFuZ2VzZXRfbmV3KHBkZXYtPmRvbWFpbiwgTlVMTCwN CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJBTkdFU0VURl9ub19w cmludCk7DQorDQorICAgICAgICBpZiAoICF0YXNrLT5iYXJzW2ldLm1lbSApDQorICAgICAgICB7 DQorICAgICAgICAgICAgZGVzdHJveV9tYXBfdGFzayh0YXNrKTsNCisgICAgICAgICAgICByZXR1 cm4gTlVMTDsNCisgICAgICAgIH0NCisNCisgICAgICAgIHRhc2stPmJhcnNbaV0uYWRkciA9IHBk ZXYtPnZwY2ktPmhlYWRlci5iYXJzW2ldLmFkZHI7DQorICAgICAgICB0YXNrLT5iYXJzW2ldLmd1 ZXN0X2FkZHIgPSBwZGV2LT52cGNpLT5oZWFkZXIuYmFyc1tpXS5ndWVzdF9hZGRyOw0KKyAgICB9 DQorDQorICAgIHRhc2stPmNtZCA9IGNtZDsNCisgICAgdGFzay0+cm9tX29ubHkgPSByb21fb25s eTsNCisgICAgdGFzay0+cGRldiA9IHBkZXY7DQorDQorICAgIHJldHVybiB0YXNrOw0KK30NCisN CitzdGF0aWMgdm9pZCBkZWZlcl9tYXAoc3RydWN0IHZwY2lfbWFwX3Rhc2sgKnRhc2spDQogew0K ICAgICBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJlbnQ7DQogDQpAQCAtMjk1LDkgKzM3Miw4IEBA IHN0YXRpYyB2b2lkIGRlZmVyX21hcChjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2 X3QgY21kLCBib29sIHJvbV9vbmx5KQ0KICAgICAgKiBpcyBtYXBwZWQuIFRoaXMgY2FuIGxlYWQg dG8gcGFyYWxsZWwgbWFwcGluZyBvcGVyYXRpb25zIGJlaW5nDQogICAgICAqIHN0YXJ0ZWQgZm9y IHRoZSBzYW1lIGRldmljZSBpZiB0aGUgZG9tYWluIGlzIG5vdCB3ZWxsLWJlaGF2ZWQuDQogICAg ICAqLw0KLSAgICBjdXJyLT52cGNpLnBkZXYgPSBwZGV2Ow0KLSAgICBjdXJyLT52cGNpLmNtZCA9 IGNtZDsNCi0gICAgY3Vyci0+dnBjaS5yb21fb25seSA9IHJvbV9vbmx5Ow0KKyAgICBsaXN0X2Fk ZF90YWlsKCZ0YXNrLT5uZXh0LCAmY3Vyci0+dnBjaS50YXNrX3F1ZXVlKTsNCisNCiAgICAgLyoN CiAgICAgICogUmFpc2UgYSBzY2hlZHVsZXIgc29mdGlycSBpbiBvcmRlciB0byBwcmV2ZW50IHRo ZSBndWVzdCBmcm9tIHJlc3VtaW5nDQogICAgICAqIGV4ZWN1dGlvbiB3aXRoIHBlbmRpbmcgbWFw cGluZyBvcGVyYXRpb25zLCB0byB0cmlnZ2VyIHRoZSBpbnZvY2F0aW9uDQpAQCAtMzEyLDExICsz ODgsMTcgQEAgaW50IHZwY2lfbW9kaWZ5X2JhcnMoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYs IHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSkNCiAgICAgc3RydWN0IHBjaV9kZXYgKnRtcDsN CiAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZDsNCiAgICAgY29uc3Qgc3RydWN0IHZwY2lfbXNp eCAqbXNpeCA9IHBkZXYtPnZwY2ktPm1zaXg7DQorICAgIHN0cnVjdCB2cGNpX21hcF90YXNrICp0 YXNrOw0KICAgICB1bnNpZ25lZCBpbnQgaSwgajsNCiAgICAgaW50IHJjOw0KIA0KICAgICBBU1NF UlQocndfaXNfd3JpdGVfbG9ja2VkKCZwZGV2LT5kb21haW4tPnBjaV9sb2NrKSk7DQogDQorICAg IHRhc2sgPSBhbGxvY19tYXBfdGFzayhwZGV2LCBjbWQsIHJvbV9vbmx5KTsNCisNCisgICAgaWYg KCAhdGFzayApDQorICAgICAgICByZXR1cm4gLUVOT01FTTsNCisNCiAgICAgLyoNCiAgICAgICog Q3JlYXRlIGEgcmFuZ2VzZXQgcGVyIEJBUiB0aGF0IHJlcHJlc2VudHMgdGhlIGN1cnJlbnQgZGV2 aWNlIG1lbW9yeQ0KICAgICAgKiByZWdpb24gYW5kIGNvbXBhcmUgaXQgYWdhaW5zdCBhbGwgdGhl IGN1cnJlbnRseSBhY3RpdmUgQkFSIG1lbW9yeQ0KQEAgLTMzMiw3ICs0MTQsNyBAQCBpbnQgdnBj aV9tb2RpZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBi b29sIHJvbV9vbmx5KQ0KICAgICBmb3IgKCBpID0gMDsgaSA8IEFSUkFZX1NJWkUoaGVhZGVyLT5i YXJzKTsgaSsrICkNCiAgICAgew0KICAgICAgICAgc3RydWN0IHZwY2lfYmFyICpiYXIgPSAmaGVh ZGVyLT5iYXJzW2ldOw0KLSAgICAgICAgc3RydWN0IHJhbmdlc2V0ICptZW0gPSBiYXItPm1lbTsN CisgICAgICAgIHN0cnVjdCByYW5nZXNldCAqbWVtID0gdGFzay0+YmFyc1tpXS5tZW07DQogICAg ICAgICB1bnNpZ25lZCBsb25nIHN0YXJ0ID0gUEZOX0RPV04oYmFyLT5hZGRyKTsNCiAgICAgICAg IHVuc2lnbmVkIGxvbmcgZW5kID0gUEZOX0RPV04oYmFyLT5hZGRyICsgYmFyLT5zaXplIC0gMSk7 DQogICAgICAgICB1bnNpZ25lZCBsb25nIHN0YXJ0X2d1ZXN0ID0gUEZOX0RPV04oYmFyLT5ndWVz dF9hZGRyKTsNCkBAIC0zNDMsOSArNDI1LDcgQEAgaW50IHZwY2lfbW9kaWZ5X2JhcnMoY29uc3Qg c3RydWN0IHBjaV9kZXYgKnBkZXYsIHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSkNCiANCiAg ICAgICAgIGlmICggIU1BUFBBQkxFX0JBUihiYXIpIHx8DQogICAgICAgICAgICAgIChyb21fb25s eSA/IGJhci0+dHlwZSAhPSBWUENJX0JBUl9ST00NCi0gICAgICAgICAgICAgICAgICAgICAgIDog KGJhci0+dHlwZSA9PSBWUENJX0JBUl9ST00gJiYgIWhlYWRlci0+cm9tX2VuYWJsZWQpKSB8fA0K LSAgICAgICAgICAgICAvKiBTa2lwIEJBUnMgYWxyZWFkeSBpbiB0aGUgcmVxdWVzdGVkIHN0YXRl LiAqLw0KLSAgICAgICAgICAgICBiYXItPmVuYWJsZWQgPT0gISEoY21kICYgUENJX0NPTU1BTkRf TUVNT1JZKSApDQorICAgICAgICAgICAgICAgICAgICAgICA6IChiYXItPnR5cGUgPT0gVlBDSV9C QVJfUk9NICYmICFoZWFkZXItPnJvbV9lbmFibGVkKSkgKQ0KICAgICAgICAgICAgIGNvbnRpbnVl Ow0KIA0KICAgICAgICAgaWYgKCAhcGNpX2NoZWNrX2JhcihwZGV2LCBfbWZuKHN0YXJ0KSwgX21m bihlbmQpKSApDQpAQCAtMzY4LDcgKzQ0OCw4IEBAIGludCB2cGNpX21vZGlmeV9iYXJzKGNvbnN0 IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHkpDQogICAg ICAgICAgICAgZ3ByaW50ayhYRU5MT0dfR19XQVJOSU5HLA0KICAgICAgICAgICAgICAgICAgICAg IiVwcDogY2FuJ3QgbWFwIEJBUiV1IC0gb2Zmc2V0IG1pc21hdGNoOiAlI2x4IHZzICUjbHhcbiIs DQogICAgICAgICAgICAgICAgICAgICAmcGRldi0+c2JkZiwgaSwgYmFyLT5ndWVzdF9hZGRyLCBi YXItPmFkZHIpOw0KLSAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgICAgIHJj ID0gLUVJTlZBTDsNCisgICAgICAgICAgICBnb3RvIGZhaWw7DQogICAgICAgICB9DQogDQogICAg ICAgICByYyA9IHJhbmdlc2V0X2FkZF9yYW5nZShtZW0sIHN0YXJ0X2d1ZXN0LCBlbmRfZ3Vlc3Qp Ow0KQEAgLTM3NiwxMyArNDU3LDEzIEBAIGludCB2cGNpX21vZGlmeV9iYXJzKGNvbnN0IHN0cnVj dCBwY2lfZGV2ICpwZGV2LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHkpDQogICAgICAgICB7 DQogICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19HX1dBUk5JTkcgIkZhaWxlZCB0byBhZGQgWyVs eCwgJWx4XTogJWRcbiIsDQogICAgICAgICAgICAgICAgICAgIHN0YXJ0X2d1ZXN0LCBlbmRfZ3Vl c3QsIHJjKTsNCi0gICAgICAgICAgICByZXR1cm4gcmM7DQorICAgICAgICAgICAgZ290byBmYWls Ow0KICAgICAgICAgfQ0KIA0KICAgICAgICAgLyogQ2hlY2sgZm9yIG92ZXJsYXAgd2l0aCB0aGUg YWxyZWFkeSBzZXR1cCBCQVIgcmFuZ2VzLiAqLw0KICAgICAgICAgZm9yICggaiA9IDA7IGogPCBp OyBqKysgKQ0KICAgICAgICAgew0KLSAgICAgICAgICAgIHN0cnVjdCByYW5nZXNldCAqcHJldl9t ZW0gPSBoZWFkZXItPmJhcnNbal0ubWVtOw0KKyAgICAgICAgICAgIHN0cnVjdCByYW5nZXNldCAq cHJldl9tZW0gPSB0YXNrLT5iYXJzW2pdLm1lbTsNCiANCiAgICAgICAgICAgICBpZiAoIHJhbmdl c2V0X2lzX2VtcHR5KHByZXZfbWVtKSApDQogICAgICAgICAgICAgICAgIGNvbnRpbnVlOw0KQEAg LTM5Myw3ICs0NzQsNyBAQCBpbnQgdnBjaV9tb2RpZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2Rl diAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJvbV9vbmx5KQ0KICAgICAgICAgICAgICAgICBn cHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KICAgICAgICAgICAgICAgICAgICAgICAgIiVwcDogZmFp bGVkIHRvIHJlbW92ZSBvdmVybGFwcGluZyByYW5nZSBbJWx4LCAlbHhdOiAlZFxuIiwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAmcGRldi0+c2JkZiwgc3RhcnRfZ3Vlc3QsIGVuZF9ndWVzdCwg cmMpOw0KLSAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQorICAgICAgICAgICAgICAgIGdvdG8g ZmFpbDsNCiAgICAgICAgICAgICB9DQogICAgICAgICB9DQogDQpAQCAtNDAzLDcgKzQ4NCw3IEBA IGludCB2cGNpX21vZGlmeV9iYXJzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1aW50MTZf dCBjbWQsIGJvb2wgcm9tX29ubHkpDQogICAgICAgICAgICAgZ3ByaW50ayhYRU5MT0dfV0FSTklO RywNCiAgICAgICAgICAgICAgICAgICAgICIlcHA6IGZhaWxlZCB0byBzYW5pdGl6ZSBCQVIjJXUg bWVtb3J5OiAlZFxuIiwNCiAgICAgICAgICAgICAgICAgICAgICZwZGV2LT5zYmRmLCBpLCByYyk7 DQotICAgICAgICAgICAgcmV0dXJuIHJjOw0KKyAgICAgICAgICAgIGdvdG8gZmFpbDsNCiAgICAg ICAgIH0NCiAgICAgfQ0KIA0KQEAgLTQxNCw5ICs0OTUsOSBAQCBpbnQgdnBjaV9tb2RpZnlfYmFy cyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJvbV9vbmx5 KQ0KICAgICAgICAgdW5zaWduZWQgbG9uZyBlbmQgPSBQRk5fRE9XTih2bXNpeF90YWJsZV9hZGRy KHBkZXYtPnZwY2ksIGkpICsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dm1zaXhfdGFibGVfc2l6ZShwZGV2LT52cGNpLCBpKSAtIDEpOw0KIA0KLSAgICAgICAgZm9yICgg aiA9IDA7IGogPCBBUlJBWV9TSVpFKGhlYWRlci0+YmFycyk7IGorKyApDQorICAgICAgICBmb3Ig KCBqID0gMDsgaiA8IEFSUkFZX1NJWkUodGFzay0+YmFycyk7IGorKyApDQogICAgICAgICB7DQot ICAgICAgICAgICAgc3RydWN0IHJhbmdlc2V0ICptZW0gPSBoZWFkZXItPmJhcnNbal0ubWVtOw0K KyAgICAgICAgICAgIHN0cnVjdCByYW5nZXNldCAqbWVtID0gdGFzay0+YmFyc1tqXS5tZW07DQog DQogICAgICAgICAgICAgaWYgKCByYW5nZXNldF9pc19lbXB0eShtZW0pICkNCiAgICAgICAgICAg ICAgICAgY29udGludWU7DQpAQCAtNDI3LDcgKzUwOCw3IEBAIGludCB2cGNpX21vZGlmeV9iYXJz KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHkp DQogICAgICAgICAgICAgICAgIGdwcmludGsoWEVOTE9HX1dBUk5JTkcsDQogICAgICAgICAgICAg ICAgICAgICAgICAiJXBwOiBmYWlsZWQgdG8gcmVtb3ZlIE1TSVggdGFibGUgWyVseCwgJWx4XTog JWRcbiIsDQogICAgICAgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIHN0YXJ0LCBlbmQs IHJjKTsNCi0gICAgICAgICAgICAgICAgcmV0dXJuIHJjOw0KKyAgICAgICAgICAgICAgICBnb3Rv IGZhaWw7DQogICAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAgICB9DQpAQCAtNDcxLDcgKzU1 Miw3IEBAIGludCB2cGNpX21vZGlmeV9iYXJzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1 aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHkpDQogICAgICAgICAgICAgICAgIGZvciAoIGogPSAw OyBqIDwgQVJSQVlfU0laRShoZWFkZXItPmJhcnMpOyBqKyspDQogICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCB2cGNpX2JhciAqYmFyID0gJmhlYWRl ci0+YmFyc1tqXTsNCi0gICAgICAgICAgICAgICAgICAgIHN0cnVjdCByYW5nZXNldCAqbWVtID0g YmFyLT5tZW07DQorICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbSA9IHRh c2stPmJhcnNbal0ubWVtOw0KIA0KICAgICAgICAgICAgICAgICAgICAgaWYgKCAhcmFuZ2VzZXRf b3ZlcmxhcHNfcmFuZ2UobWVtLCBzdGFydCwgZW5kKSB8fA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAvKg0KQEAgLTQ5MCw3ICs1NzEsNyBAQCBpbnQgdnBjaV9tb2RpZnlfYmFycyhjb25zdCBz dHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJvbV9vbmx5KQ0KICAgICAg ICAgICAgICAgICAgICAgICAgIGdwcmludGsoWEVOTE9HX1dBUk5JTkcsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAiJXBwOiBmYWlsZWQgdG8gcmVtb3ZlIFslbHgsICVseF06ICVk XG4iLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIHN0YXJ0 LCBlbmQsIHJjKTsNCi0gICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQorICAgICAg ICAgICAgICAgICAgICAgICAgZ290byBmYWlsOw0KICAgICAgICAgICAgICAgICAgICAgfQ0KICAg ICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgfQ0KQEAgLTUxMywxMiArNTk0LDE5IEBAIGlu dCB2cGNpX21vZGlmeV9iYXJzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1aW50MTZfdCBj bWQsIGJvb2wgcm9tX29ubHkpDQogICAgICAgICAgKiB3aWxsIGFsd2F5cyBiZSB0byBlc3RhYmxp c2ggbWFwcGluZ3MgYW5kIHByb2Nlc3MgYWxsIHRoZSBCQVJzLg0KICAgICAgICAgICovDQogICAg ICAgICBBU1NFUlQoKGNtZCAmIFBDSV9DT01NQU5EX01FTU9SWSkgJiYgIXJvbV9vbmx5KTsNCi0g ICAgICAgIHJldHVybiBhcHBseV9tYXAocGRldi0+ZG9tYWluLCBwZGV2LCBjbWQpOw0KKyAgICAg ICAgcmMgPSBhcHBseV9tYXAocGRldi0+ZG9tYWluLCBwZGV2LCB0YXNrKTsNCisgICAgICAgIGRl c3Ryb3lfbWFwX3Rhc2sodGFzayk7DQorICAgICAgICByZXR1cm4gcmM7DQogICAgIH0NCiANCi0g ICAgZGVmZXJfbWFwKHBkZXYsIGNtZCwgcm9tX29ubHkpOw0KKyAgICBkZWZlcl9tYXAodGFzayk7 DQogDQogICAgIHJldHVybiAwOw0KKw0KKyBmYWlsOg0KKyAgICBkZXN0cm95X21hcF90YXNrKHRh c2spOw0KKw0KKyAgICByZXR1cm4gcmM7DQogfQ0KIA0KIHN0YXRpYyB2b2lkIGNmX2NoZWNrIGNt ZF93cml0ZSgNCkBAIC03MzcsMTggKzgyNSw2IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIHJvbV93 cml0ZSgNCiAgICAgfQ0KIH0NCiANCi1zdGF0aWMgaW50IGJhcl9hZGRfcmFuZ2VzZXQoY29uc3Qg c3RydWN0IHBjaV9kZXYgKnBkZXYsIHN0cnVjdCB2cGNpX2JhciAqYmFyLA0KLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgaSkNCi17DQotICAgIGNoYXIgc3RyWzMyXTsN Ci0NCi0gICAgc25wcmludGYoc3RyLCBzaXplb2Yoc3RyKSwgIiVwcDpCQVIldSIsICZwZGV2LT5z YmRmLCBpKTsNCi0NCi0gICAgYmFyLT5tZW0gPSByYW5nZXNldF9uZXcocGRldi0+ZG9tYWluLCBz dHIsIFJBTkdFU0VURl9ub19wcmludCk7DQotDQotICAgIHJldHVybiAhYmFyLT5tZW0gPyAtRU5P TUVNIDogMDsNCi19DQotDQogaW50IHZwY2lfaW5pdF9oZWFkZXIoc3RydWN0IHBjaV9kZXYgKnBk ZXYpDQogew0KICAgICB1aW50MTZfdCBjbWQ7DQpAQCAtODU5LDEwICs5MzUsNiBAQCBpbnQgdnBj aV9pbml0X2hlYWRlcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiAgICAgICAgIGVsc2UNCiAgICAg ICAgICAgICBiYXJzW2ldLnR5cGUgPSBWUENJX0JBUl9NRU0zMjsNCiANCi0gICAgICAgIHJjID0g YmFyX2FkZF9yYW5nZXNldChwZGV2LCAmYmFyc1tpXSwgaSk7DQotICAgICAgICBpZiAoIHJjICkN Ci0gICAgICAgICAgICBnb3RvIGZhaWw7DQotDQogICAgICAgICByYyA9IHBjaV9zaXplX21lbV9i YXIocGRldi0+c2JkZiwgcmVnLCAmYWRkciwgJnNpemUsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKGkgPT0gbnVtX2JhcnMgLSAxKSA/IFBDSV9CQVJfTEFTVCA6IDApOw0KICAgICAg ICAgaWYgKCByYyA8IDAgKQ0KQEAgLTkxNiwxMiArOTg4LDYgQEAgaW50IHZwY2lfaW5pdF9oZWFk ZXIoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDQsIHJvbSk7DQogICAgICAgICBpZiAoIHJjICkNCiAgICAgICAgICAgICByb20tPnR5cGUgPSBW UENJX0JBUl9FTVBUWTsNCi0gICAgICAgIGVsc2UNCi0gICAgICAgIHsNCi0gICAgICAgICAgICBy YyA9IGJhcl9hZGRfcmFuZ2VzZXQocGRldiwgcm9tLCBudW1fYmFycyk7DQotICAgICAgICAgICAg aWYgKCByYyApDQotICAgICAgICAgICAgICAgIGdvdG8gZmFpbDsNCi0gICAgICAgIH0NCiAgICAg fQ0KICAgICBlbHNlIGlmICggIWlzX2h3ZG9tICkNCiAgICAgew0KZGlmZiAtLWdpdCBhL3hlbi9k cml2ZXJzL3ZwY2kvdnBjaS5jIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCmluZGV4IDllMmMy N2UzYTMuLjlhNDIyZjllYTAgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0K KysrIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCkBAIC0yNCw2ICsyNCwxMSBAQA0KIA0KICNp ZmRlZiBfX1hFTl9fDQogDQordm9pZCB2cGNpX3ZjcHVfaW5pdChzdHJ1Y3QgdmNwdSAqdikNCit7 DQorICAgIElOSVRfTElTVF9IRUFEKCZ2LT52cGNpLnRhc2tfcXVldWUpOw0KK30NCisNCiAjaWZk ZWYgQ09ORklHX0hBU19WUENJX0dVRVNUX1NVUFBPUlQNCiBzdGF0aWMgaW50IGFzc2lnbl92aXJ0 dWFsX3NiZGYoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQogew0KQEAgLTg5LDggKzk0LDYgQEAgc3Ry dWN0IHZwY2lfcmVnaXN0ZXIgKnZwY2lfZ2V0X3JlZ2lzdGVyKGNvbnN0IHN0cnVjdCB2cGNpICp2 cGNpLA0KIA0KIHZvaWQgdnBjaV9kZWFzc2lnbl9kZXZpY2Uoc3RydWN0IHBjaV9kZXYgKnBkZXYp DQogew0KLSAgICB1bnNpZ25lZCBpbnQgaTsNCi0NCiAgICAgQVNTRVJUKHJ3X2lzX3dyaXRlX2xv Y2tlZCgmcGRldi0+ZG9tYWluLT5wY2lfbG9jaykpOw0KIA0KICAgICBpZiAoICFoYXNfdnBjaShw ZGV2LT5kb21haW4pIHx8ICFwZGV2LT52cGNpICkNCkBAIC0xMTYsOSArMTE5LDYgQEAgdm9pZCB2 cGNpX2RlYXNzaWduX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiAgICAgfQ0KICAgICBz cGluX3VubG9jaygmcGRldi0+dnBjaS0+bG9jayk7DQogDQotICAgIGZvciAoIGkgPSAwOyBpIDwg QVJSQVlfU0laRShwZGV2LT52cGNpLT5oZWFkZXIuYmFycyk7IGkrKyApDQotICAgICAgICByYW5n ZXNldF9kZXN0cm95KHBkZXYtPnZwY2ktPmhlYWRlci5iYXJzW2ldLm1lbSk7DQotDQogICAgIHhm cmVlKHBkZXYtPnZwY2kpOw0KICAgICBwZGV2LT52cGNpID0gTlVMTDsNCiB9DQpkaWZmIC0tZ2l0 IGEveGVuL2luY2x1ZGUveGVuL3ZwY2kuaCBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCmluZGV4 IDg3N2FhMzkxZDEuLjI2YWExMjA1ODMgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vdnBj aS5oDQorKysgYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQpAQCAtMTksNiArMTksOCBAQA0KICAq Lw0KICNkZWZpbmUgVlBDSV9NQVhfVklSVF9ERVYgICAgICAgKFBDSV9TTE9UKH4wKSArIDEpDQog DQordm9pZCB2cGNpX3ZjcHVfaW5pdChzdHJ1Y3QgdmNwdSAqdik7DQorDQogLyogQXNzaWduIHZQ Q0kgdG8gZGV2aWNlIGJ5IGFkZGluZyBoYW5kbGVycy4gKi8NCiBpbnQgX19tdXN0X2NoZWNrIHZw Y2lfYXNzaWduX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQogDQpAQCAtNTQsNyArNTYs NiBAQCBzdHJ1Y3QgdnBjaSB7DQogICAgICAgICAgICAgdWludDY0X3QgZ3Vlc3RfYWRkcjsNCiAg ICAgICAgICAgICB1aW50NjRfdCBzaXplOw0KICAgICAgICAgICAgIHVpbnQ2NF90IHJlc2l6YWJs ZV9zaXplczsNCi0gICAgICAgICAgICBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsNCiAgICAgICAgICAg ICBlbnVtIHsNCiAgICAgICAgICAgICAgICAgVlBDSV9CQVJfRU1QVFksDQogICAgICAgICAgICAg ICAgIFZQQ0lfQkFSX0lPLA0KQEAgLTE1MiwxNCArMTUzLDI0IEBAIHN0cnVjdCB2cGNpIHsNCiAj ZW5kaWYNCiB9Ow0KIA0KLXN0cnVjdCB2cGNpX3ZjcHUgew0KKyNpZmRlZiBfX1hFTl9fDQorc3Ry dWN0IHZwY2lfbWFwX3Rhc2sgew0KICAgICAvKiBQZXItdmNwdSBzdHJ1Y3R1cmUgdG8gc3RvcmUg c3RhdGUgd2hpbGUge3VufW1hcHBpbmcgb2YgUENJIEJBUnMuICovDQotICAgIGNvbnN0IHN0cnVj dCBwY2lfZGV2ICpwZGV2Ow0KKyAgICBzdHJ1Y3QgbGlzdF9oZWFkIG5leHQ7DQorICAgIHN0cnVj dCB2cGNpX2Jhcl9tYXAgew0KKyAgICAgICAgdWludDY0X3QgYWRkcjsNCisgICAgICAgIHVpbnQ2 NF90IGd1ZXN0X2FkZHI7DQorICAgICAgICBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsNCisgICAgfSBi YXJzW0FSUkFZX1NJWkUoKChzdHJ1Y3QgdnBjaV9oZWFkZXIgKilOVUxMKS0+YmFycyldOw0KICAg ICB1aW50MTZfdCBjbWQ7DQogICAgIGJvb2wgcm9tX29ubHkgOiAxOw0KKyAgICBjb25zdCBzdHJ1 Y3QgcGNpX2RldiAqcGRldjsNCit9Ow0KKw0KK3N0cnVjdCB2cGNpX3ZjcHUgew0KKyAgICBzdHJ1 Y3QgbGlzdF9oZWFkIHRhc2tfcXVldWU7DQogfTsNCiANCi0jaWZkZWYgX19YRU5fXw0KIHZvaWQg dnBjaV9kdW1wX21zaSh2b2lkKTsNCiANCiAvKiBBcmNoLXNwZWNpZmljIHZQQ0kgTVNJIGhlbHBl cnMuICovDQpAQCAtMjA0LDYgKzIxNSw4IEBAIGJvb2wgdnBjaV9lY2FtX3JlYWQocGNpX3NiZGZf dCBzYmRmLCB1bnNpZ25lZCBpbnQgcmVnLCB1bnNpZ25lZCBpbnQgbGVuLA0KICNlbHNlIC8qICFD T05GSUdfSEFTX1ZQQ0kgKi8NCiBzdHJ1Y3QgdnBjaV92Y3B1IHt9Ow0KIA0KK3N0YXRpYyBpbmxp bmUgdm9pZCB2cGNpX3ZjcHVfaW5pdChzdHJ1Y3QgdmNwdSAqdikgeyB9DQorDQogc3RhdGljIGlu bGluZSBpbnQgdnBjaV9yZWluaXRfZXh0X2NhcGFiaWxpdGllcyhzdHJ1Y3QgcGNpX2RldiAqcGRl dikNCiB7DQogICAgIHJldHVybiAwOw0KLS0gDQoyLjU1LjANCg== From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450634.1666059 (Exim 4.92) (envelope-from ) id 1xHM8Q-0007jF-Bz; Thu, 15 Oct 2026 14:08:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450634.1666059; Thu, 15 Oct 2026 14:08: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 1xHM8Q-0007hN-2n; Thu, 15 Oct 2026 14:08:42 +0000 Received: by outflank-mailman (input) for mailman id 1450634; Thu, 15 Oct 2026 14:08:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHM8P-0007dC-7d for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:08:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHM8O-002ujh-Kl for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:08:40 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0de59-e002-0a2a0a5209dd-0a2a4501c5d8-34 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from [52.101.65.141] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0de67-5984-0a2a45010019-3465418d2d13-5 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by ZR6PR03MB911287.eurprd03.prod.outlook.com (2603:10a6:910:d7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 14:08:36 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.012; Thu, 15 Oct 2026 14:08: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=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=SGNw/MbbMqGtTOUUIYKvMkD9w0+xg/pz4LYznNgQtwLCIeWASl+7G8MJz8BKxUt7/u92i7if0rlcrOPEVY4K0iyepQywTfqUJnX2QuEKjELhUxT1Ebo7w2f7e/JTCl8hpWUfRQT4JeRdNivX7M2lBEcsuugH23oWw3FYpAu0GLRL/EgSq0RWGPuRWPqrF2OpKwD+dvoyvOINjzsRETlqrLmsjiyjHDvfzLDS8hCv07TzCOQ8yS96Y1BR8LB2/j4B6svrpupZUMdEd8Xsk4a0NzO8J+gpcAbpdEl3tr4FYuatQlqjKZ6s6F2FonhwmoF/RdNpTnQwZ4f/UAUDufpM4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fvMlPCObxLIEvCughisWjippOr1t8mmEjUTQZnihfjI=; b=vjsMnYkmUuzfoa0UxWK4mKNZiP9LyOW86fBbJXMhmazLu4XO9ClOVh3E/GmJqGdzVot0rWm1kE69TRuqUKEaIdsoQMDd02CFBps7YdsQDZkHBqpr3FkyuFnBhExccVQyCxPZwO8ht7OJMwuR3TRWcZFHyYYAnjM5rWAmqCdA1igyQ7ocwrT4hPVnSSe54VQKV6F/OybHEmYxDQGt9HAFD91NLiT7FQuULAT5vkzr7j61hlnH5E6Bs7cDTxULrEY5aPHznu4t4aPMe4AR6lwpulA0lwbcjRQcuobnliZ/A4Nk9zwnpj2GBwLGKvRMb4nCCBzju9SIqQvUpi2pWruNtw== 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=fvMlPCObxLIEvCughisWjippOr1t8mmEjUTQZnihfjI=; b=MgI9XXvDO6nPmJyU37NfCVK08MHYXxSN7t6sBTvd99IDOEH5PO2zdhgmTZaO+i9IR3bgUWz/sGY7xRMYUoofr8IUvXVCC2l8pXVyPyX80Kv9ZyyauCyoJtiSBXsiET8kH+ERfhFCwyW+s6qC68xX7yecc3kscCdHf6+Vaedl4BIBnvbrwQ1HiHLUNEDWA4Gf5PDeYuqVf+DL6lVLxyE5pLwIokhJ6gwfQ9ah1N4gmow+ye3u7T/f++eozOlMyKhDsD0hwB3KF1brXtmdrqQiD8muGnOqFEFPeBduMarFGBoGP6qictUnZvlFHUJzQX80i1U7wXhXmp4OZKCB2CanUg== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stewart Hildebrand , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , Oleksii Kurochko , Community Manager , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "Daniel P. Smith" Subject: [PATCH v4 0/5] Implement SR-IOV support for PVH Thread-Topic: [PATCH v4 0/5] Implement SR-IOV support for PVH Thread-Index: AQHdXK6rQsC6poG5A0eHd+VJtXmFsg== Date: Thu, 15 Oct 2026 14:08:36 +0000 Message-ID: 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: PAVPR03MB10102:EE_|ZR6PR03MB911287:EE_ x-ms-office365-filtering-correlation-id: 85c70419-c5ef-4149-56f2-08df2ac5ce44 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|7416014|1800799024|23010399003|38070700021|56012099006|11063799006|261009223027099003|260925022911599003|260925021311599003|10067099003|18002099003|6133799003|260925021911599003; x-microsoft-antispam-message-info: rVYJXWDhPWSHmcFdGoySDEkVJDEezYPBRDpKYOlrIIwp1RSaSK39ry74aNWw2w0JgqwBW2Wy4wNq6hUmyLKgNNScKM9rVsbJlbiGA7DuLIuW4/Z3V//O1EWkIcTdfnq3tp0UWhjlsw0HoRd4MniQ0vU6U3eTh8nGoA4LYxBlNpZ0cKUWFYzPfSF6uWD77JcEOcGM6PBBE+C2pHzQtD2YDkVBw53P12cZ9Crz2SE3TvAdfyS3CQukUMcyp7cCuX93S8xtAFeoCEQYbBBYmvSRsEkO5qHKfTo+jU6+xC4J0HsnCRtojKlAl8z5IrXeEfYBvY0XEYkUvNyTFUumSlkXOhRAOsgu1kRK1kCGhEXaUhAZ3atbkvmL8rRN1DNR7RkNlQPhxrx90/BfAgrR3tPf1BJzo7F5gJqVmjHcsDsznCh++mj6q0JUetSXhIEwJq3DMlfkEJcA2qRNuJjIKJM3/oxrIzJB3OlbkaO0I6RpMRbuIgif4Yb1cv8/RFYMGbFxVhNuGNDscQbInrmgD4qWCNqoWIS7wFVUALSn1/mdZm1cVWmsdkVn/MaEHbwIDAu07MCA4bXz9FYDvc3r1AVtuguC1SuEcLi2ZJgoOYFyXnBNvKb0fFpNj0nZL/Zip9MVzvqFlxPfRKWRg0p/J1yg4j06vzwsgLwm2tsbap9qZiU+b6/oVVh6+Z3GsrBg2BZR x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(7416014)(1800799024)(23010399003)(38070700021)(56012099006)(11063799006)(261009223027099003)(260925022911599003)(260925021311599003)(10067099003)(18002099003)(6133799003)(260925021911599003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bm5KUjluWElKQXZBa0U3blVleXZaNEgyTzNiSjBOVllCOHZ0SmJER1NGR2hR?= =?utf-8?B?aElkRHVCUWtNME5sc3dkV0lJK29QWElLczYrYnBLcnlzQVRwOTA1cHl3YXZX?= =?utf-8?B?MkVnSGhFd0Y1WUFWN0ozZ1dMVDl3NEdTMEFySjVlL0RodWdLTWoyWUMxeG9n?= =?utf-8?B?WVlxY0p6UjZZK3NnOHg4bForQmpHT1poZ29Fa0d6c2g2R1kzMStQKzZiT1c1?= =?utf-8?B?R3dxTHlJNzBLL1pybFF2Rmw2Y3FGeGV5cVVYNmdoRm9EWHI1Njc1b2MrUzUx?= =?utf-8?B?K0trQ2lVdkIvdWZFT0xvb0lKcEdhbzBQNHN2ZHYvSmtUMzVYM0g4dWZUbzh5?= =?utf-8?B?aks2YkR0NmRZMGp1L2prK1hOVXBCaWdhNU5iWW1FOHN6bkNMTkM1bjMvZXlj?= =?utf-8?B?czVTM2YzMDNJSW9Mc0RieGUyZU1RR1VlOCtiY2NwdlR5NzJDNWQ0VUNkU0tD?= =?utf-8?B?K0FDaTR2RUc5U1R5VHBzTEo1aER4WkQweDByNmg1eTFRTDhtZkt4cGV0NzNK?= =?utf-8?B?MGFuME1qdFVrQmtad0RNNUNhTTRpdHAzZlIrRXFpZWlyaUxjSFdNM3MxUC8v?= =?utf-8?B?UFh6UXRBbktLemhwS0FpWk9IcFc1YktFSkE5RXd0Unk1RkZSWE0zN3hTSDJQ?= =?utf-8?B?Sy9wK0ZnTGV2MW0zTGhyUXpvV0FzS1FuRitSMExPOU5JZGVrK08rZXA1ZlBK?= =?utf-8?B?dVhvY3VhcmNkcWJtVzArN28xTUFTWEZwVUN2bU5UeFk3ZXFXbC9JSXd0SThR?= =?utf-8?B?am94SkY5RWRGdi9Ha0RmcVJEa2xXT3BZNFIzaC9YOHJQUy9KOGlyL0ZsRVY2?= =?utf-8?B?WmRBOXZkY2JuYXcxa1FxOWJab01XNndoS2xhRFdSTlhqbzVtTHZhUlFQOTNs?= =?utf-8?B?bmh3SGp6bDFtR1R5aXRIbEo1YUlQbm9waFdyRTlvSjQ1WXdjWEtJL1Nmczdk?= =?utf-8?B?R2NIWXVtbDUrRkVQK2FYTUNINm44UEpKTmVmUDhhR0NzczEwNmdDUDBDc2d1?= =?utf-8?B?OEQxM2dqUGR0OUZHTHQ0YU8yUDlyNDlEZjFLS0QrQTFnUTRRaFhiZjA4K0t3?= =?utf-8?B?M0NxY0QxenpkZGxwNTA4cFRiU2d1OW5xT3BaU3lwOUtKUEZ1SGhteUtkNnZn?= =?utf-8?B?UWtna1dES2FibzV6c0FSd0VkTlNPZXhnTnZsU0h6QTFPRVhZR29nQVA3SHpS?= =?utf-8?B?NEVqWFpJdE5wYVNlSVczS0NJbFBzRlJIeU5JYkJpTDdHaHFqODB5ejhLSzI3?= =?utf-8?B?eHBWczJ0VWllT3VQMmxETlE2cnQ0RHpnMUprdnF1Y25DRTVwN28rNUhlOFMy?= =?utf-8?B?bzh4WkgreitpOXk0QVlIU1BxTEFSeU9IUHdSRmtHVEhlRFRrODJ2dlY4Rk9x?= =?utf-8?B?MFNnMHpmTmpWeEEvenl2c0FoNW9yY2xTTjRwZjhHS054ZTdRZjFldWt2NlNk?= =?utf-8?B?WmJqVS9CcTdBK0ZMSlluMlpkLzNmelpDWVN2TGt6ZHR1U0kyei9LWHN4ek1T?= =?utf-8?B?RXBFb2U2cEl4N2VBNGZaWVhlNkpkODY3d0t3VTQrSU5QM1dGS2x6N1ZST3BC?= =?utf-8?B?U1luWVpaTmgrVDNvc2dJK1kvUFFvTVNsZlRrZDlGdjZIWW80NENsSTZCWnlH?= =?utf-8?B?R284WmJSWG1ZSy9ieTNodjRFUzlGMXY1L1BjSGZwaStzOCtja3E3VW4zWklH?= =?utf-8?B?SDZjK1pSZ2ZIVHQvQjdhNTNMeGNIb0t0VlB1dW1ZQlN6VjVHZDlNdHV0bGVJ?= =?utf-8?B?enZWdU4wUU9CdFFnL1RPR1RscVFYUmlrelh3dHZ3dkZLaVN0Y2dRVzV2YUdq?= =?utf-8?B?cnp6NVlJR0pxMWpRR0hBQmE2YVRxY1l3SnlvRUF2RlRoTkNjM1ZXeEJCdkJs?= =?utf-8?B?MW5GTDZ4QVFyTUZXSkowSFVxNUltQ1p4L3B2Smp3S0o0WTlBUE56THVudGgv?= =?utf-8?B?emVZV3ZXUkZGcDB6ZG84NHorcDQ1THRpekJrbmZ3RmxHNnY2MnIvd2NLTFoz?= =?utf-8?B?V05OS0NlWm92Q1ZxZ1c3VlRWM3lmaVVwbzNrK21DdmVYWERyS0wxaFB6a21n?= =?utf-8?B?YjNNcUVCZmFzVnBJYWJxRkVLdW1MbjhYRFQyRkd6ZGpTVzYxVFNmdDJja2pq?= =?utf-8?B?MHdsZU5KbUR6anVWTzZIM3lIcGMzT2tkSmxHMk9KUFFMMW16cEhJcWlwQ1gx?= =?utf-8?B?a2RrMGJxaE9Ha1ErY0psZ1pOeVpRVzR4cWVRbzRrTU5oa1N1ck1GMmVoeGh2?= =?utf-8?B?VC9mSU1aTWdPYlNHUStZUThXMTVxa3V5aGZJSnhWQ2Fad092bkRoQ1BFMWhN?= =?utf-8?B?eklIQkxLVTh3eVk2SEdxbVBDQ3JRaTRpdUI5Rmcrd2kwaFdyRXI5c2FaQ3or?= =?utf-8?Q?PhSKMf9wrHWyT9ns=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85c70419-c5ef-4149-56f2-08df2ac5ce44 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2026 14:08:36.7305 (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: Zgn3MhUFwtn+YD+0lcX0xPKVYuEhj5L5+dSfepp+MckQLAcPEWkkgaGAeARzP6xP5dc6+zxP36p2n4w7u4SQIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR03MB911287 X-purgate-ID: tlsNG-d62444/1792073320-1F46D757-8784AB60/0/0 X-purgate-type: clean X-purgate-size: 3552 VGhpcyBzZXJpZXMgZW5hYmxlcyBzdXBwb3J0IGZvciBQQ0kgU1ItSU9WIGNhcGFiaWxpdHkgZm9y IFBWSCBkb21haW5zLg0KSXQgYWxsb3dzIERvbTAgdG8gZW5hYmxlIGFuZCB1c2UgU1ItSU9WIHZp cnR1YWwgZnVuY3Rpb25zIGFuZCBmb3IgdGhlc2UNCmZ1bmN0aW9ucyB0byBiZSBwYXNzZWQgdG8g Z3Vlc3RzLg0KDQpUbyBhY2hpZXZlIHRoaXMsIGFkZCBoYW5kbGVycyBmb3IgU1JJT1ZfQ09OVFJP TCByZWdpc3RlcnMgYW5kIHNpbXBsaWZpZWQNCmhhbmRsZXJzIGZvciBWRiBoZWFkZXJzLiBEb20w IGVuYWJsZXMgU1ItSU9WOyBYZW4gdGhlbiBkaXNjb3ZlcnMgdGhlIFZGcw0KaXRzZWxmLCB0ZXJt aW5hdGluZyBjb25maWcgc3BhY2UgYWNjZXNzZXMgdG8gdGhlbSBmb3IgMTAwbXMgYXMgdGhlIHNw ZWMNCnBlcm1pdHMsIGFuZCBhZGRpbmcgZWFjaCBWRiBvbiB0aGUgZmlyc3QgYWNjZXNzIHBhc3Qg dGhhdCB3aW5kb3cuIE5vDQpoeXBlcmNhbGwgZnJvbSBkb20wIGlzIGludm9sdmVkLg0KDQpDb3Jl IGZ1bmN0aW9uYWxpdHkgaXMgYmFzZWQgb24gcHJldmlvdXMgd29ya1sxXS4NCg0KVGVzdGVkIG9u IFItQ2FyIFNwaWRlciBib2FyZCB3aXRoIFNhbXN1bmcgTlZNZSBTU0QgQ29udHJvbGxlciA5ODAg YW5kIEludGVsDQpYNTUwVCBldGhlcm5ldCBjYXJkLg0KDQpbMV06IGh0dHBzOi8vbG9yZS5rZXJu ZWwub3JnL3hlbi1kZXZlbC8yMDE4MDcxNzA5NDgzMC41NDgwNi0xLXJvZ2VyLnBhdUBjaXRyaXgu Y29tLw0KDQp2My0+djQ6DQoqIHJld29yayB0aGUgc2VyaWVzIGZvciBWRiBkaXNjb3ZlcnkgaW4g WGVuDQoqIHNxdWFzaCBleHBvcnQgcGF0Y2hlcw0KKiBkcm9wICJ2cGNpOiBVc2UgcGVydmNwdSBy YW5nZXMgZm9yIEJBUiBtYXBwaW5nIjsgcmFuZ2VzZXRzIGFyZSBub3cNCiAgYWxsb2NhdGVkIHBl ciBtYXBwaW5nIHRhc2sNCiogc3BsaXQgdGhlIG5vbi1mdW5jdGlvbmFsIGNodXJuIGludG8gInZw Y2k6IHVzZSBhIGxvY2FsIHZhcmlhYmxlIGZvcg0KICB0aGUgQkFSIHJhbmdlc2V0Ig0KKiBmb2xk IHRoZSBkb2N1bWVudGF0aW9uIHBhdGNoIGludG8gImFkZCBTUi1JT1Ygc3VwcG9ydCBmb3IgUFZI IERvbTAiDQoqIHNlZSBpbmRpdmlkdWFsIHBhdGNoZXMNCg0KDQp2Mi0+djM6DQoqIHJld29yayB0 aGUgc2VyaWVzIGZvciBWRiBkaXNjb3ZlcnkgYnkgRG9tMA0KKiBkcm9wIHBjaS9pb21tdTogQ2hl Y2sgdGhhdCBJT01NVSBzdXBwb3J0cyByZW1vdmluZyBkZXZpY2VzLCBzZWUgWzJdDQoqIGRyb3Ag dnBjaTogYWRkIGEgd2FpdCBvcGVyYXRpb24gdG8gdGhlIHZwY2kgdmNwdSBwZW5kaW5nIGFjdGlv bnMNCiogYWRkIHZwY2k6IGFsbG93IHF1ZXVlaW5nIG9mIG1hcHBpbmcgb3BlcmF0aW9ucw0KKiBt aW5vciBjaGFuZ2VzIGluIGluZGl2aWR1YWwgcGF0Y2hlcw0KDQpbMl06IGh0dHBzOi8vcGF0Y2hl dy5vcmcvWGVuL2E1OWMyZGEwZDRjNzJkZWI0Mjk1MGU5YThlMzk4MmZiZGVlNjA2NjguMTc3NTU1 NTc2Ni5naXQubXlreXRhLl81RnBvdHVyYWlAZXBhbS5jb20vDQp2MS0+djI6DQoqIHJld29yayB0 aGUgc2VyaWVzIGZvciBWRiBkaXNjb3ZlcnkgaW4gWGVuDQoqIHNlcGFyYXRlIGRvYyBjaGFuZ2Vz IGludG8gdGhlIGxhc3QgcGF0Y2gNCg0KTXlreXRhIFBvdHVyYWkgKDEpOg0KICB2cGNpOiB1c2Ug YSBsb2NhbCB2YXJpYWJsZSBmb3IgdGhlIEJBUiByYW5nZXNldA0KDQpTdGV3YXJ0IEhpbGRlYnJh bmQgKDQpOg0KICB2cGNpOiBFeHBvcnQgZnVuY3Rpb25zIHJlcXVpcmVkIGZvciBTUi1JT1Ygc3Vw cG9ydA0KICB2cGNpOiBhbGxvdyBxdWV1ZWluZyBvZiBtYXBwaW5nIG9wZXJhdGlvbnMNCiAgdnBj aTogYWRkIFNSLUlPViBzdXBwb3J0IGZvciBQVkggRG9tMA0KICB2cGNpOiBhZGQgU1ItSU9WIHN1 cHBvcnQgZm9yIERvbVVzDQoNCiBDSEFOR0VMT0cubWQgICAgICAgICAgICAgICAgICB8ICAgMSAr DQogU1VQUE9SVC5tZCAgICAgICAgICAgICAgICAgICAgfCAgIDIgLQ0KIHRvb2xzL3Rlc3RzL3Zw Y2kvZW11bC5oICAgICAgIHwgICA0ICsNCiB4ZW4vY29tbW9uL2RvbWFpbi5jICAgICAgICAgICB8 ICAgMiArDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNpLmMgfCAgNDQgKysrDQogeGVuL2Ry aXZlcnMvcGNpL3BoeXNkZXYuYyAgICAgfCAgMTYgKy0NCiB4ZW4vZHJpdmVycy92cGNpL01ha2Vm aWxlICAgICB8ICAgMSArDQogeGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYyAgICAgfCAzMDkgKysr KysrKysrKystLS0tLS0tDQogeGVuL2RyaXZlcnMvdnBjaS9wcml2YXRlLmggICAgfCAgMjQgKysN CiB4ZW4vZHJpdmVycy92cGNpL3NyaW92LmMgICAgICB8IDU2OCArKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrDQogeGVuL2RyaXZlcnMvdnBjaS92cGNpLmMgICAgICAgfCAgMjQgKy0N CiB4ZW4vaW5jbHVkZS94ZW4vcGNpLmggICAgICAgICB8ICAgMyArDQogeGVuL2luY2x1ZGUveGVu L3ZwY2kuaCAgICAgICAgfCAgNDUgKystDQogMTMgZmlsZXMgY2hhbmdlZCwgOTA5IGluc2VydGlv bnMoKyksIDEzNCBkZWxldGlvbnMoLSkNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMv dnBjaS9zcmlvdi5jDQoNCi0tIA0KMi41NS4wDQo= From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450635.1666067 (Exim 4.92) (envelope-from ) id 1xHM8Q-0007u2-RC; Thu, 15 Oct 2026 14:08:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450635.1666067; Thu, 15 Oct 2026 14:08: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 1xHM8Q-0007tB-KF; Thu, 15 Oct 2026 14:08:42 +0000 Received: by outflank-mailman (input) for mailman id 1450635; Thu, 15 Oct 2026 14:08:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHM8P-0007dH-AL for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:08:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHM8O-002ujh-NQ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:08:40 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0de59-e002-0a2a0a5209dd-0a2a4501c5d8-36 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from [40.107.130.109] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0de68-5984-0a2a45010019-286b826df94d-3 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by BR0PR03MB478273.eurprd03.prod.outlook.com (2603:10a6:2c8:57::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 14:08:39 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.012; Thu, 15 Oct 2026 14:08: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=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=I122jX0I4HqJEDzAxn2gqcqc/2rZWeqAgCxY8XXUEiBPxQ/62JJ6AQL5FZrsBjzc2wx5lIzpPaUvxulzYk512zQj3sPyjasHq+0tIx/kqojC8YhGG69lNYlLO2Sc9tQjiYwFlxykS9tmlcdidGwqcC62FnuDrNBdwc8fPLlIKteSd/ydDjg69a3CSw8lBUThmYPw4/zSzpRVX6X9gPLp7HaE+5u2U51w5uf4IjiGDC7vPw4atTGTIMtrIAU8rzlzHuO2JgXQ5zG3Ral0zlZUv1a0kqeueXhd8lLEL55UqNGLef7DXCF4gzdiq8Gjo+Y+Ky6FEWSl/Mvf4IC/h9rsQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xFTVJBiBGZaYOy71IJGDHQLcbg/ldMmAczl5fkv0boE=; b=SKJjn8dyDY90YA8BIGmDPQmpbIQ0RhfLGCdpVA/Py1WQEwjOCtU84NSpItqopeN5WDMc1TqRIxjwyXizqJhSK0y54yaHAX/HjXckEp1+cPa09HzXoinSTBklVWpZg90VyLFHI+Nj3r6ELeE4MmXX1nzmQXvmiN1BXqdIJHKPhp8mh/2gvlO/8ocFdQF6rwbKI4l3xPvmmTgoo2Pk+IyqNfVryHx8Vf0p8/XB5cZDkFB2D04Uu7NlhwdBF41nczxJPtq4hijXhBRLoFi8PvNptUkZ6G5e930QoE3lKcogJN9Fm0+k28qSxvxfMybG/B6PhcY/w55rTCgg1o1ePVMudg== 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=xFTVJBiBGZaYOy71IJGDHQLcbg/ldMmAczl5fkv0boE=; b=hzTcCiRScYv+ne4rfoeiCjjqumZRLdkr5kwCXpr1GMRmSIw5+xsXtzdgi+Q8go/ZJm8l5WNd32Tp6jaY6F+u3rXTwJdn9DaCdsFPwnnjjwTyCnIuJxQ55s7FJtXn9BdHGx1SXV3b9q9/tF6+hRpFEJv4ui0SBTVxNWsvibVStoplbWfttF1ZyJcMpEVUTC+uhbt0Iw7k2NipTAblZI3uGaXsbm0rOSU6pVKlR8gKUJ1oZoAoY9jyw6xYs8efSVXl2PhmHrfy59BW6hIrdQt/MRQLSiDja5bNxtDWHGCt5Yl0GMZiz0QGgie6Ka03ZV4ivPYYqvf34dLuUZsmwhxPbQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Mykyta Poturai Subject: [PATCH v4 5/5] vpci: add SR-IOV support for DomUs Thread-Topic: [PATCH v4 5/5] vpci: add SR-IOV support for DomUs Thread-Index: AQHdXK6teWhG3WjO0kSjTx4KoVhJjw== Date: Thu, 15 Oct 2026 14:08:38 +0000 Message-ID: <8823cd01334978baea19515c35068c789d4568bb.1792072426.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|BR0PR03MB478273:EE_ x-ms-office365-filtering-correlation-id: 0d3478f7-d5a9-4d2b-7348-08df2ac5cfb6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|18002099003|22082099003|10067099003|38070700021|11063799006|261009223027099003|56012099006; x-microsoft-antispam-message-info: 3m7yIc6q0XAL2YpMXEeFXE7clPfDhhbBnIwASbkVBe3QhVm7AcW9Oe2sxu042Gkzsfhe82b/ldEQYPwJ7Vz7bKgzbSnpRox6gaGwBXePmPIR/6Airf1FN1utb0VfMLnP704Wgqz9Z9VJrnWQlLlpHT9IW9xjzI87+IRtou31wt3biYS+oEvFxNpGJOaQp9dIT7qOAomKwJNrgMQ0ScEH/oQzZs9NnIO9xWk5aFGMHS1VznHpngjxN/omEZfouPldNJf/sbw+fQiowc5NBqiOKnQb0049W0OpuSUWgRHfFzNnJCSLojGPTW35lphuMSILnG6WdDoUJoxW9Pyk9rQ95Aenml8+4EjskjBnuDgd64xIhe/ZCnY+HjK5nIFzzl3pkXowNAsAHQO97j2WIwRsKsQVeiddEWDqG6Jj/TPfq1/WtZbz99HemoHgiaKO+daQ4kR07IOBAPlml7EHTFntui41AqvpCanaChDNY7u3gr+kEi3mTuvZcLBQJVNBYwbmFjtx52WJMAUYtCeMg3YnxGMiQH9J3gj3JE+7KVs9G0EUU/r2BHtWQA8fpzdCk7Ti9OwltkzeGZiYieK3JF8hdpO5P2kB/NLe/chPjwZ/HKTlOmx7SxgHma1rAeOs1BOENwdc6YLdrw/Crijhx823+uvHPk1FRVh2hu5Kn77jG54QOuHWQbOTVia6RmY5c9YxdEmSyt7KTO7FKDv1GvSqM7kuQO533m5ubc9+fxlGjis= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(6133799003)(18002099003)(22082099003)(10067099003)(38070700021)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Uk1ScFprME9uYXdoSGYzL01ma01EZEtiL3dCSllaYU1oelIrUFF5N2dKMFZY?= =?utf-8?B?SUxOL1ZpQ3BUb3ZUK1ZvZzJDcUxsSVptOUpIa3diUlBiVWNtTzZRVnlQcnBF?= =?utf-8?B?NE9nTFR5WHo1K01ReDZtUzZvUjZBZFVnZnRnQ2NkRnFyL3JNQ2dldEFFRWpP?= =?utf-8?B?OWJXV3RzZFBxSnR2enI1N1VjdVo3RU5CdGt1WW9wZ0ppK29LUk9DbXZTN1ZH?= =?utf-8?B?ZmlqTHJEZzBVdVZLdlpDZCtsY0R3MmxDQnQ3UXFlRE1MT1VTd2YxZnY4bjFG?= =?utf-8?B?TlFvbEk1bzViU1RIcitCMHp2Qmdrd1J3L0hFT0IwSTEwWDdtZjhJWjRNbE4r?= =?utf-8?B?eXR5WW1jdGltUnI2VkdGcHo0T09zZVFDVFp0S0paRE1CZHI4QVBGOUhKRzNX?= =?utf-8?B?UVVwNDRieHcrUUVBbzNiSm1Gb042WXh1ZERES0dyZUorb0ljSVoxdlk4SUVx?= =?utf-8?B?cmpsVGNBZzAzdXR4M3VxMWttdmdESlNvWnhMajEzbWdwWjJvN01yM3c2K3By?= =?utf-8?B?NE1zN2p6U3pXcG9GczZMazVrRVpSdHg1bDhMMXJwWmVkc3dUQVB4WXpQa1lp?= =?utf-8?B?dlhnVnovWjBxUlJFMlBQKyszOUN2RzdyeHBnZTM1dmhSS0FHOGZWV29nNjl4?= =?utf-8?B?U3ZOeldNSmJBNGNzMjVPWVNHeXhHclNSeWZ2VzdiUWdUcXAwNHBscEIvN2Y0?= =?utf-8?B?WUMzak1qb1RkOFMyYzlNMkoreFhqcGZTUjNaN0t3cldoTzVyOUp6MEYyaElK?= =?utf-8?B?TlRCRjJ1TlR6RG5hcWlCRlFMTGRlOU9VQzhIbmkvVGErK1d0cEJJUkZXeURn?= =?utf-8?B?TkJEck1HTGlYblNIOGlDclVhTGk5MWdWdzN2RGRjUnFLMkoxaEtSZHowY2R4?= =?utf-8?B?ZS9JMEZ3UGhLUzJ0NS90R0ovVUNmOEJEWldscXgzbFdrUlhWNk0xN1hKdXEv?= =?utf-8?B?aWwvU0c1QjhrQVFsejErOVpKcmF0eXozdllhTU02Z2ovcjlLM0xFRUZkTk1o?= =?utf-8?B?dUFzUkUzSFNINGt6UGFWZXVhV2hyRy9mN3dMRzYyZVQyaVhwS0JmOFJzZGFH?= =?utf-8?B?ZlhzaVZnZEJ1VFBodm1DVlRwbkMwNklUNklGZWJ2bjE5bzFGSWZIQUFyN3V6?= =?utf-8?B?MDRwejJ5ZlhrK0dqdzRVL1VqZkRKcllWTmZrK3lySUpxN0k1OENpVmd0dWpE?= =?utf-8?B?NFByVFczeHhZeXlEMUpoWGQ1QVZOMmU2bkVpRmFHUHhpWklhS0gvcXlTSFZr?= =?utf-8?B?L3JzZVU1UFU2OC9XdUVNTVEyNW5Nc0JlQVNPMVl6cW9nV0NVYW5mdFk0NVI1?= =?utf-8?B?RHdLWHlEc1NSVHhSS2lpczZSM0NFZFE0WXJiM01kT1FLL3NpUVpUbnVPT1gr?= =?utf-8?B?VGY3VkVadWJ0d1JOdnNxZHEvam5zbGZFWC9IekVJVmZLUS9ISkhvUUhmRUMz?= =?utf-8?B?dDdleVlFMmh0T2s0MGtLMytYSjVNZzF0RkFLZlEvRVd3KzJIZjVSMDY0UHdk?= =?utf-8?B?UUZmTHpsU1pRNlB1ZGZCaDU5RHd6aDVzMmZPZVZadm5iaHo2ZXBrQjd2VTdi?= =?utf-8?B?NVpHNSttckR3ZlBqOUdkMGtpeWlUeVRCUXMrQ1o2ZzF6Nm5UNGlGd3lmZmhE?= =?utf-8?B?WklMTmo5SENnd2VZckdpWExQMEc5Y3lDY2FqMkkrbVNkVjR2NndBOFhpWlZz?= =?utf-8?B?TGR6MDVJVzIya2RFNkJoeVdsTE1yYmhVVWZTT0VQdzU5UHB6ZUgzdDRRYUZw?= =?utf-8?B?bWdUMWFNV0htU1NiSHB2c24yamg4ZytISVZ1eHN3d3laY2VhR2tDYnNaQ29q?= =?utf-8?B?UmtyOEYzOXRmWThycjdqbm5nZXZsL3l4ampTRkdSa2FIcjBqYlFTRDVEQVhL?= =?utf-8?B?NEhXU3RvQXVTMTRrUjhUOUFadUd6N1JJeFMxb3M1Wmh6eTNBUlpWQkhUUzYr?= =?utf-8?B?amxxMTNHR3VUalJxUm1XYlRBb1pWM1NGeFZQT21wQlRKZVRyVU5MZS95cGh5?= =?utf-8?B?UWJGVzVFZlFtemhXaTE2ejJ6MldnTGxZSlVYTGR2RDQ3WHRpeW9VcTVUTW5p?= =?utf-8?B?ZVZVR0xzM2NGbzhMVEY5VXNCK0x5SjN1NlBFcldWQ1VjL1JIZTI1R2dOQWdx?= =?utf-8?B?SUJHNFlubkZheDNlbzdkSWFqd056a1pDN0owV3ZXRlF0eTNpTzNpWnNZTGZz?= =?utf-8?B?V0dDZ0xVQlVvV2NEZWtSOG1YUnEwWWtWenZxRGJCMlhGZ3ZZVWlqbEh2N2hM?= =?utf-8?B?ZFhUbEliZkk5VmRKVUMvWmV2UW5Gall4WEE0amFpc1FKdVNvNElmWjAyblU1?= =?utf-8?B?KzM5dTJUU3hxT1dLV3BsN01oRWt5V0RaRDlsNWk3ZmFtNW5mRENlYkphOTFu?= =?utf-8?Q?YmjUX2d89WvfWLN0=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d3478f7-d5a9-4d2b-7348-08df2ac5cfb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2026 14:08:39.0118 (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: u64vVtsSwXFcA2ZIONrDKrb1psjfxSm6j8VzUgfmX9k6hdIVW6JDaBIU+Z9paiX6F7CdlXv6ugqIVCYcUY/9TA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BR0PR03MB478273 X-purgate-ID: tlsNG-d62444/1792073320-BFA6E757-24AD928F/0/0 X-purgate-type: clean X-purgate-size: 6192 RnJvbTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCg0K RW11bGF0ZSBndWVzdCBCQVIgcmVnaXN0ZXIgdmFsdWVzIGJhc2VkIG9uIFBGIEJBUiB2YWx1ZXMg Zm9yIFZGcy4NClRoaXMgYWxsb3dzIGNyZWF0aW5nIGEgZ3Vlc3QgdmlldyBvZiB0aGUgbm9ybWFs IEJBUiByZWdpc3RlcnMgYW5kIGVtdWxhdGVzDQp0aGUgc2l6ZSBhbmQgcHJvcGVydGllcyBhcyBp dCBpcyBkb25lIGR1cmluZyBQQ0kgZGV2aWNlIGVudW1lcmF0aW9uIGJ5DQp0aGUgZ3Vlc3QuDQoN CkV4cG9zZSBWSUQvRElEIGFuZCBjbGFzcy9yZXZpc2lvbiB0byB0aGUgZ3Vlc3QuDQoNCk5vdGUs IHRoYXQgVkZzIFJPTSBCQVIgaXMgcmVhZC1vbmx5IGFuZCBpcyBhbGwgemVyb3MsIGJ1dCBWRiBt YXkgcHJvdmlkZQ0KYWNjZXNzIHRvIHRoZSBQRnMgUk9NIHZpYSBlbXVsYXRpb24gYW5kIGlzIG5v dCBpbXBsZW1lbnRlZC4NCg0KTm90ZSB0aGlzIG9ubHkgcmVtb3ZlcyBvbmUgb2YgdGhlIGdhcHMg b24gdGhlIHdheSB0byB2UENJIERvbVUgc3VwcG9ydDsNClZGcyBhcmUgbm90IHVzYWJsZSBpbiBE b21VcyB1bnRpbCB0aGUgcmVzdCBvZiBpdCBpcyB1cHN0cmVhbS4gVGhlIERvbVUNCnRlc3Rpbmcg YmVoaW5kIHRoaXMgcGF0Y2ggdXNlZCBvdXQtb2YtdHJlZSB2UENJIERvbVUgcGF0Y2hlcy4NCg0K U2lnbmVkLW9mZi1ieTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1k LmNvbT4NClNpZ25lZC1vZmYtYnk6IE15a3l0YSBQb3R1cmFpIDxteWt5dGFfcG90dXJhaUBlcGFt LmNvbT4NCi0tLQ0KdjMtPnY0Og0KKiBlbXVsYXRlIFZJRC9ESUQgYWdhaW4NCiogYWRkIGEgbm90 ZSB0byBjb21taXQgbWVzc2FnZQ0KDQp2Mi0+djM6DQoqIGRvbid0IGVtdWxhdGUgVklEL0RJRCBy ZWdpc3RlcnMNCiogcmVwbGFjZSBpZmRlZiB3aXRoIElTX0VOQUJMRUQNCg0KdjEtPnYyOg0KKiBy ZW1vdmUgVkYgcmVnaXN0ZXIgaGFuZGxlcnMgY292ZXJlZCBieSBpbml0X2hlYWRlcg0KKiBzZXQg Z3Vlc3QgYWRkciB1bmNvbmRpdGlvbmFsbHkNCi0tLQ0KIHhlbi9kcml2ZXJzL3ZwY2kvc3Jpb3Yu YyB8IDY1ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0NCiAxIGZpbGUg Y2hhbmdlZCwgNjMgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCg0KZGlmZiAtLWdpdCBh L3hlbi9kcml2ZXJzL3ZwY2kvc3Jpb3YuYyBiL3hlbi9kcml2ZXJzL3ZwY2kvc3Jpb3YuYw0KaW5k ZXggNGUwOWJkZmJmZC4uMDI0YTA5OTgyMiAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kv c3Jpb3YuYw0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS9zcmlvdi5jDQpAQCAtNzksMTkgKzc5LDgw IEBAIGludCB2cGNpX3ZmX2luaXRfaGVhZGVyKHN0cnVjdCBwY2lfZGV2ICp2Zl9wZGV2KQ0KICAg ICBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGZfcGRldjsNCiAgICAgaW50IHJjID0gMDsNCiAgICAg dWludDE2X3QgY3RybDsNCisgICAgdW5zaWduZWQgaW50IHNyaW92X3BvczsNCiANCiAgICAgQVNT RVJUKHJ3X2lzX3dyaXRlX2xvY2tlZCgmdmZfcGRldi0+ZG9tYWluLT5wY2lfbG9jaykpOw0KICAg ICBBU1NFUlQodmZfcGRldi0+aW5mby5pc192aXJ0Zm4pOw0KIA0KICAgICBwZl9wZGV2ID0gdmZf cGRldi0+cGZfcGRldjsNCiAgICAgQVNTRVJUKHBmX3BkZXYpOw0KKyAgICBzcmlvdl9wb3MgPSBw Zl9wZGV2LT52cGNpLT5zcmlvdi0+cG9zOw0KIA0KICAgICByYyA9IHZmX2luaXRfYmFycyh2Zl9w ZGV2KTsNCiAgICAgaWYgKCByYyApDQogICAgICAgICByZXR1cm4gcmM7DQogDQotICAgIGN0cmwg PSBwY2lfY29uZl9yZWFkMTYocGZfcGRldi0+c2JkZiwNCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICBwZl9wZGV2LT52cGNpLT5zcmlvdi0+cG9zICsgUENJX1NSSU9WX0NUUkwpOw0KKyAgICBj dHJsID0gcGNpX2NvbmZfcmVhZDE2KHBmX3BkZXYtPnNiZGYsIHNyaW92X3BvcyArIFBDSV9TUklP Vl9DVFJMKTsNCisNCisgICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19IQVNfVlBDSV9HVUVTVF9T VVBQT1JUKSAmJg0KKyAgICAgICAgIHBmX3BkZXYtPmRvbWFpbiAhPSB2Zl9wZGV2LT5kb21haW4g KQ0KKyAgICB7DQorICAgICAgICBzdHJ1Y3QgdnBjaV9iYXIgKmJhcnMgPSB2Zl9wZGV2LT52cGNp LT5oZWFkZXIuYmFyczsNCisgICAgICAgIC8qDQorICAgICAgICAgKiBBIFZGJ3MgVmVuZG9yIGFu ZCBEZXZpY2UgSUQgcmVnaXN0ZXJzIHJlYWQgYXMgMHhmZmZmLiBUaGUgZ3Vlc3QgaGFzDQorICAg ICAgICAgKiBubyBQRiB0byBzeW50aGVzaXNlIHRoZW0gZnJvbSwgc28gdGFrZSB0aGUgdmVuZG9y IGZyb20gdGhlIFBGIGFuZA0KKyAgICAgICAgICogdGhlIGRldmljZSBmcm9tIGl0cyBTUi1JT1Yg Y2FwYWJpbGl0eS4NCisgICAgICAgICAqLw0KKyAgICAgICAgdWludDE2X3QgdmlkID0gcGNpX2Nv bmZfcmVhZDE2KHBmX3BkZXYtPnNiZGYsIFBDSV9WRU5ET1JfSUQpOw0KKyAgICAgICAgdWludDE2 X3QgZGlkID0gcGNpX2NvbmZfcmVhZDE2KHBmX3BkZXYtPnNiZGYsDQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3Jpb3ZfcG9zICsgUENJX1NSSU9WX1ZGX0RJRCk7DQor DQorICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHZmX3BkZXYtPnZwY2ksIHZwY2lfcmVh ZF92YWwsIE5VTEwsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9WRU5ET1Jf SUQsIDIsICh2b2lkICopKHVpbnRwdHJfdCl2aWQpOw0KKyAgICAgICAgaWYgKCByYyApDQorICAg ICAgICAgICAgcmV0dXJuIHJjOw0KKw0KKyAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcih2 Zl9wZGV2LT52cGNpLCB2cGNpX3JlYWRfdmFsLCBOVUxMLA0KKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQQ0lfREVWSUNFX0lELCAyLCAodm9pZCAqKSh1aW50cHRyX3QpZGlkKTsNCisg ICAgICAgIGlmICggcmMgKQ0KKyAgICAgICAgICAgIHJldHVybiByYzsNCisNCisgICAgICAgIC8q IEhhcmRjb2RlIG11bHRpLWZ1bmN0aW9uIGRldmljZSBiaXQgdG8gMCAqLw0KKyAgICAgICAgcmMg PSB2cGNpX2FkZF9yZWdpc3Rlcih2Zl9wZGV2LT52cGNpLCB2cGNpX3JlYWRfdmFsLCBOVUxMLA0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfSEVBREVSX1RZUEUsIDEsDQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICh2b2lkICopUENJX0hFQURFUl9UWVBFX05PUk1B TCk7DQorICAgICAgICBpZiAoIHJjICkNCisgICAgICAgICAgICByZXR1cm4gcmM7DQorDQorICAg ICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHZmX3BkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDMy LCBOVUxMLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfQ0xBU1NfUkVWSVNJ T04sIDQsIE5VTEwpOw0KKyAgICAgICAgaWYgKCByYyApDQorICAgICAgICAgICAgcmV0dXJuIHJj Ow0KKw0KKyAgICAgICAgZm9yICggdW5zaWduZWQgaW50IGkgPSAwOyBpIDwgUENJX1NSSU9WX05V TV9CQVJTOyBpKysgKQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIHN3aXRjaCAoIHBmX3BkZXYt PnZwY2ktPnNyaW92LT52Zl9iYXJzW2ldLnR5cGUgKQ0KKyAgICAgICAgICAgIHsNCisgICAgICAg ICAgICBjYXNlIFZQQ0lfQkFSX01FTTMyOg0KKyAgICAgICAgICAgIGNhc2UgVlBDSV9CQVJfTUVN NjRfTE86DQorICAgICAgICAgICAgY2FzZSBWUENJX0JBUl9NRU02NF9ISToNCisgICAgICAgICAg ICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcih2Zl9wZGV2LT52cGNpLCB2cGNpX2d1ZXN0X21l bV9iYXJfcmVhZCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2cGNp X2d1ZXN0X21lbV9iYXJfd3JpdGUsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUENJX0JBU0VfQUREUkVTU18wICsgaSAqIDQsIDQsICZiYXJzW2ldKTsNCisgICAgICAg ICAgICAgICAgaWYgKCByYyApDQorICAgICAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQorICAg ICAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgICAgIGRlZmF1bHQ6DQorICAgICAgICAg ICAgICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIodmZfcGRldi0+dnBjaSwgdnBjaV9yZWFkX3Zh bCwgTlVMTCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfQkFT RV9BRERSRVNTXzAgKyBpICogNCwgNCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAodm9pZCAqKTApOw0KKyAgICAgICAgICAgICAgICBpZiAoIHJjICkNCisgICAgICAg ICAgICAgICAgICAgIHJldHVybiByYzsNCisgICAgICAgICAgICAgICAgYnJlYWs7DQorICAgICAg ICAgICAgfQ0KKyAgICAgICAgfQ0KKyAgICB9DQogDQogICAgIGlmICggKHBmX3BkZXYtPmRvbWFp biA9PSB2Zl9wZGV2LT5kb21haW4pICYmIChjdHJsICYgUENJX1NSSU9WX0NUUkxfTVNFKSApDQog ICAgIHsNCi0tIA0KMi41NS4wDQo= From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450636.1666071 (Exim 4.92) (envelope-from ) id 1xHM8R-0007ww-2D; Thu, 15 Oct 2026 14:08:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450636.1666071; Thu, 15 Oct 2026 14:08: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 1xHM8Q-0007vH-R7; Thu, 15 Oct 2026 14:08:42 +0000 Received: by outflank-mailman (input) for mailman id 1450636; Thu, 15 Oct 2026 14:08:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHM8P-0007dR-Lv for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:08:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHM8P-002ujh-2V for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:08:41 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0de59-e002-0a2a0a5209dd-0a2a4501c5d8-40 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from [40.107.130.109] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0de68-5984-0a2a45010019-286b826df94d-4 for ; Thu, 15 Oct 2026 16:08:40 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by BR0PR03MB478273.eurprd03.prod.outlook.com (2603:10a6:2c8:57::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Thu, 15 Oct 2026 14:08:38 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.012; Thu, 15 Oct 2026 14:08: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=SWWOqAeBmcsp4odSEvsq55338X/th9tXZyNY8JKePhEpjpiGnOD96sd/cyk1O4GnRdsQ+MoAGChyjLJUccZFdX9Gx2AAGOeW1nXkbYfNmHnlMUNyddtWVWz+sIuiMUvZ4rTr1f5tbfipz7z0/e8tkCg+MYFlEx3zNwae7XXU+RjAw5qM+/zUTcZxxyLTAx1OxbmkvRGIudH7j1SZrjR2vaVJJ2yGlZmSBooMFxygvmLXpL/3eYpZhvwIxrG8O4Imf91ipaBbZGG4HI4WMNw0OTaG80ojJE880n0VyG41dgV76qeO+NbfKfWpt2XOv6uKjjjhtTypeDBKBxadnktlng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lutSN8JcJw/rmCOxT94t6wZYtd+HubLGqaLUO9x16O4=; b=RSG2vdRrOeJfwdqtFrLUteMSyUwE2OzTM4QPNyKirNyDzYnWsfpzXJTKRLht3LVj1r8phbA/1XBsrYfH6uSPfGIAWaaTatwwWhouMyOXGwWNL6yqTTct6aUU4kkkOBJJzWS6AuXRP1KPfYVAlnp9Y0T4CCcgjE8LJx8lE7ppRVaTKsDvULGdvNxNrrjLi6ONxfnahWgCZi2JXEHewkRFHiBHd4NoFVsFW4E6pUaFawvmkOWcVxMCNjOW/h9zxCCkZYV6Iy7IeCCps8Yl9/4yOxUityWbnBpRbiO7CKYHl9hk7II+R5kqXt/W+5fjX3ZoLc/ddTcnvyzhWJWh5c0Tkg== 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=lutSN8JcJw/rmCOxT94t6wZYtd+HubLGqaLUO9x16O4=; b=q45amoFgrmM5/TomNl6zHTQ0g8Oqe/+3fZeAAep2OAb8MsdOZOha3qSBqIBOYVoeLgBrSAk5bXwM3X9dIJnSfv8zD71PHpteSl+ZNtR4vlU5cR3mmhkR9oULjDeK42+Pz5pR8H1P3Zlg2afc2zOjHBA2/IVf/c74UNQDekdKBdVhkWb8KSMqvmTlkhEo3mwAOi3+zlSlW/UMViSYAKuWdWR9gfyjPIntltQyDdo5IFC+rMA6mkyMegUtcMKcdE1KExFSDuVOWKXT++6PGc390ISwW34iK8vfVh2IAZbck3Z60KdCjF3UoRVeTBC4Op75mIcKWXYjjssL9OOIvsI9/Q== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "Daniel P. Smith" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Mykyta Poturai Subject: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0 Thread-Topic: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0 Thread-Index: AQHdXK6sWnTwG0FjdEmPa5OC537fEg== Date: Thu, 15 Oct 2026 14:08:38 +0000 Message-ID: <103b10d012cc291906025045a2da1ce728f0bffd.1792072426.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|BR0PR03MB478273:EE_ x-ms-office365-filtering-correlation-id: 53054730-5d54-4452-a3f2-08df2ac5cf7b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|7416014|6133799003|18002099003|22082099003|260925021911599003|10067099003|260925022911599003|260925021311599003|38070700021|11063799006|261009223027099003|56012099006; x-microsoft-antispam-message-info: MBxOnS2nNAdBZqkpUwi83XU9bmJiq0pUodFuDLJgu33l/8cCMolE2GcOGUaWoQXpmA+9KRztIx2JqZD8FgxHV4kHhXSX4i0xpwfqrey9gXX9cwyBjJsbgJF7G3maV59+t7tgV7eomN59Q0OpPxILjFdFLO8jfmi9OE5uzAXX76xaaOa/dyBVevykQozVp/9piPDaabGmH68jDspZMo5FuRaN+9O7jiC6HDf4YRa7y6vqPlLamRB1IYzGRKMiNOgzruY9AY6yx0ePnVBJ3/u4TVTWhzzni43UYo6V+GjQqZzKgXdxYaeRtOCpKaXIBlfJNpu052eoJa+vRvb07bOqodmNqNFjkqZ+RrbdhGaGcwy8IYnT3Bf9XyvWeezy8Xt9J3vkjoDz02sIa2y8L5gdUHtxLexcSMkyrqDLGpq+qQvTi5AshFGzLHA/s2SLy6o6kX20SHF+0JXUFiBtv6+G4TvmnwwmjOEw7UjLpJuT6Tlubfd8SeMNqNssU8jjM+N1/sLOa+GFY4hFTCFPYcE43/iwodU6F8CIH/N4W/eoGx2r8+e/fJ7ED2T9ajHLKJR1C9ehzlzVxrDeeSVSLNlMA+lHIdes31HjRFLfDQ0+ztcR9l1IkWOIhQmMeU+cXgmcslYkfGbE/8JWC7ixRRcmPLoGcjNhk0DJAuxFq1qFqI8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(7416014)(6133799003)(18002099003)(22082099003)(260925021911599003)(10067099003)(260925022911599003)(260925021311599003)(38070700021)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?L0hMYklLSmd6WldDeGRMU3FQaEwwTXd5UWN2SStYcVIwMmxpNWFKdTdrN1Qy?= =?utf-8?B?ZEJvckYvOGo0V2RXNWFoR08zeGlZc3V0NlRpUncwZFlXOC8yc0JpeTZHWkVu?= =?utf-8?B?eWxGNzRNc2IvLzNuQTZSd09WMklMNjJVSy9QQStWRHNXV3Z3ck84OTdLQit4?= =?utf-8?B?bGJja0FobCtXb1ByR0R6U25mY1NjcDhveXlqUHkyeERFKzRtKzJ2RnpMbVlr?= =?utf-8?B?ZG1maHl6WGFYNk5DTkQzZXcxR3JHK0JzeXIrYnpQL2hKNStjNUpJTHBzWGdz?= =?utf-8?B?WWJOcHRtcE9Gcm9xRzM4Q0pxSDRGNS9SdG9ocmtTVnh2UGsvbmtJUnRPaWhP?= =?utf-8?B?TlVVWFA1SUcvdzcwazdYbFdyZ254Tk5TU3hRTHk4bXFIMDZyV29MbzBPdnA3?= =?utf-8?B?TnoycGxFcnp5bDM2bjlSNmFJNDVUeVdNelhIcFBmcmU1dUZFOThmYW53RS9m?= =?utf-8?B?T2hHKzZRdW4wcXFRU3p6VUh5bjJCMks3YWlRSmRocUZoeFJCTjdUd095ak83?= =?utf-8?B?UkphSU9kc3ozK0cyRHg5bUpPd2dtd3RkdUJJOVFGU2ZzVWtnUFVaMTRwUzAy?= =?utf-8?B?a09tSGRRUTJ4VWZKY3R4bWhBTHJ5c1p2ZytaVUl0cmdUM09tRTBvSHdrOHNJ?= =?utf-8?B?UDJpVjFZMUNZZ2kzWWFsWGtwSm9sMjdUVE8vWlRDMGU1MWd5cXZUcExhWTIy?= =?utf-8?B?U2dhdGowYngrU3JUR3Zid0R4QmQ3YWtKL3hWV09oenI1VTdPbEk3U2d4Qi82?= =?utf-8?B?WHFhOW9ncnlPUU0zUmd0TzZ1cUtKOHdYa3BWTHZSQXg5VnlYcGNYcUdUQ1c4?= =?utf-8?B?WEJHRUdUSjh1ZUV0OEgwbmZtZlp4ZG14S01JcWlUL3ZCRG5Tck9kTHRsRGhZ?= =?utf-8?B?QkpXOHJBTis4bEJUTSs2cGZhQWo4MFlVdDkrNlRjSHVrZzVoRDNzYy9pbGdP?= =?utf-8?B?T2REMkVHUGwwTFg5S0lmS3JpcUg5azF2RGowY0dvSXhSUCtxUDBkcjlwMnpl?= =?utf-8?B?Mi9NeStnWjBNWEExVCtBTW1HNVpUelI0bGJsTmlsR2hyZUR5b2tydyszY3FG?= =?utf-8?B?Ynd1V0plR2xXbWw0elVVTXRGcTU5dDVlM1QreDYyVE1HT3d4MHgzQVF5eEFt?= =?utf-8?B?Yk5oaDkwTVFCZjBqL2QrVjF6cmdEekN4ZWZ4dFZSTFhlM0l0eFM5aDdqYzB2?= =?utf-8?B?bE1maFl5QkdrcFAxNEFOMGRnTE83Y0thUld0b2NmSUhYMGEzQll6ajJ2QkFs?= =?utf-8?B?cStYSVQvTWFicUxmM2NkWnZlSGdERUttZDlPOXhNSjRUMEk4cUpKMHJaU1cv?= =?utf-8?B?Y2Z5T0IzbEpKd09DeGw0Y2dqd3RjTFd6M2VlQ0NJWmlaTTJYZGxLYnh3RlFq?= =?utf-8?B?QkE3bDlLemhUK2RnY1FsS1FObnRLTUlMc0FEMkdmb2lNVWRLZTNSY0NKUDht?= =?utf-8?B?WTFqYktyTGltVmdnVFZsamhlb05tVmUrUCthQ0duUmsvYzgrTitFTnNIOEFD?= =?utf-8?B?cWNWUmFVYXQvejFCeHdscllHUGJRVjVORWg1ZlZxYW9uS3FVZU5OMmkxa2tF?= =?utf-8?B?cUtKaE9ZQVZyRlM2RExZejc1b2VxdW9IRk9aRzl6Q3h0UWhHMnlCTzA4ZGVB?= =?utf-8?B?Zk9lVnlBOUcyWE5Rckpvcmt4engvV2FyRm5FNDNYSlFycEkxczYvSHJuVy84?= =?utf-8?B?UmZFejZFYlUvM1l6ZUhGWGNERDlScHU3ak1qOFhNUW1QRUNIYlF6R2JLUHlW?= =?utf-8?B?YnRkOFhDeklLbk5EUUdFR2VnWE04MmtuSDRhVkdyY2srV01QYjM1V3NpUGZE?= =?utf-8?B?ajBuRmdyWXRYcTJESVZwRTNNRkluanIyYTZ1bUVqRitvekNOQlVwc3VicWlG?= =?utf-8?B?NS92NFZ5V21NQlBFOVVuOTdKSUhNZDA4a2pGaW5BQkpMc2RwRkNFeWU5NGJp?= =?utf-8?B?THNSdkI4OTVBTUpWV3NTK0twbjZEeGl4dWRBcTBCVGNJNUFPOTZlUlczYWN3?= =?utf-8?B?QStSZUc4SU1nM2g0bThEREljeW1TQnBJMDFDaWJGa0xCdGRndW93K2NLeGRP?= =?utf-8?B?WGoxQnJqWFJFZEowYVkwcldhTmlJOWQzbHEwV09IMTVJT3BMQjM5OGs5WWxj?= =?utf-8?B?SWlkNG1SOHpxOXJncFAzcUFmclFhcG5lWkhPN1l3dklUVDQ1b0I2bHdhZzR2?= =?utf-8?B?SGltT2FMRkZZMTdnWkZRQnhYanhER1BmNWxCdUlxeGdXdlJvSXhOcEZKM2xP?= =?utf-8?B?UUNXT2wwN3FzQ2RueEMrRlkyU1UvMHR3SE1PTE1Ud2Nzd0pWclc0VDgyQjlO?= =?utf-8?B?WERCa21nY255TXRLTG03a3BlWUZYQ3FIUGlMendoYW5maWhsbEtiN2x6b3hJ?= =?utf-8?Q?TRoJUPRVD/Ur+suo=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <5CA0F9F913C5C0469B5643077B3C668E@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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53054730-5d54-4452-a3f2-08df2ac5cf7b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2026 14:08:38.7098 (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: 3NOYXzxC/6Ng3tUyeW3Gu1E6+9dF8TfXf0HdfQB0iqTXLQBsxHjCdniNAy1J+IPskF7Hi285JWq+ppfATO4Wow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BR0PR03MB478273 X-purgate-ID: tlsNG-d62444/1792073320-C4359757-2466F13D/0/0 X-purgate-type: clean X-purgate-size: 39624 RnJvbTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCg0K VGhpcyBjb2RlIGlzIGV4cGVjdGVkIHRvIG9ubHkgYmUgdXNlZCBieSBwcml2aWxlZ2VkIGRvbWFp bnMsDQp1bnByaXZpbGVnZWQgZG9tYWlucyBzaG91bGQgbm90IGdldCBhY2Nlc3MgdG8gdGhlIFNS LUlPViBjYXBhYmlsaXR5Lg0KDQpJbXBsZW1lbnQgYSB3cml0ZSBoYW5kbGVyIGZvciB0aGUgU1It SU9WIGNvbnRyb2wgcmVnaXN0ZXIsIHNvIFhlbiBjYW4NCmRpc2NvdmVyIHRoZSBWRnMgYSBQRiBl bmFibGVzIGFuZCBtYXAgdGhlaXIgQkFScy4gVkYgQkFScyBsaXZlIGluIHRoZQ0KUEYncyBjYXBh YmlsaXR5IGFuZCBhcmUgcmUtc2l6ZWQgb24gZXZlcnkgVkYgRW5hYmxlLCBhcyB0aGUgU3lzdGVt IFBhZ2UNClNpemUgcmVnaXN0ZXIgY2FuIGNoYW5nZSB0aGVtLiBUaGV5IGRlY29kZSBvbmx5IHdo aWxlIGJvdGggVkYgRW5hYmxlDQphbmQgVkYgTVNFIGFyZSBzZXQuDQoNClhlbiBhZGRzIHRoZSBW RnMgaXRzZWxmOiBvbiBWRiBFbmFibGUgdGhlaXIgcm91dGluZyBJRHMgYXJlIHJlY29yZGVkDQph bmQgY29uZmlnIHNwYWNlIGFjY2Vzc2VzIHRvIHRoZW0gdGVybWluYXRlZCBmb3IgMTAwbXMsIGFz IHRoZSBzcGVjDQpwZXJtaXRzOyB0aGUgZmlyc3QgYWNjZXNzIHBhc3QgdGhhdCBhZGRzIHRoZSBW Ri4gQ2xlYXJpbmcgVkYgRW5hYmxlDQpyZW1vdmVzIHRoZW0gYWdhaW4uDQoNClNpZ25lZC1vZmYt Ynk6IFN0ZXdhcnQgSGlsZGVicmFuZCA8c3Rld2FydC5oaWxkZWJyYW5kQGFtZC5jb20+DQpTaWdu ZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NClNpZ25l ZC1vZmYtYnk6IE15a3l0YSBQb3R1cmFpIDxteWt5dGFfcG90dXJhaUBlcGFtLmNvbT4NCi0tLQ0K djMtPnY0Og0KKiBhZGQgVkZzIGluIFhlbiBpbnN0ZWFkIG9mIHJlcXVpcmluZyB0aGUgaGFyZHdh cmUgZG9tYWluIHRvIHJlcG9ydA0KICB0aGVtDQoqIGRyb3AgdGhlIGVtdWxhdGVkIGNvbW1hbmQg cmVnaXN0ZXIgcmVhZCBmb3IgVkZzOyBQQ0lfQ09NTUFORF9NRU1PUlkNCiAgaXMgcmVhZC1vbmx5 IDAgb24gYSBWRiBhbmQgbXVzdCBub3QgY29udHJvbCBtYXBwaW5nDQoqIHJlcXVpcmUgVkYgRW5h YmxlIGluIGFkZGl0aW9uIHRvIE1TRSBiZWZvcmUgbWFwcGluZw0KKiBjYWNoZSB0aGUgU1ItSU9W IGNhcGFiaWxpdHkgcG9zaXRpb24gYXQgaW5pdA0KKiBhZGRyZXNzIHJldmlldyBjb21tZW50cyBv biB2Zl9pbml0X2JhcnMoKSwgaW5pdF9zcmlvdigpLA0KICBjbGVhbnVwX3NyaW92KCkgYW5kIHNp emVfdmZfYmFycygpDQoqIGNoYW5nZSBTT0Igb3JkZXINCg0KdjItPnYzOg0KKiByZXdvcmsgYWRk aW5nIFZGcyB3aXRoIG11bHRpcGxlIG1hcHBpbmcgb3BlcmF0aW9ucyBzdXBwb3J0DQoqIHN3aXRj aCBiYWNrIHRvIG5vIGxvbmdlciBhZGRpbmcgVkZzIHdpdGhpbmcgWGVuDQoqIHVzZSBwcml2YXRl LmgNCiogc3R5bGUgZml4ZXMNCiogZml4dXAgY2xlYW51cF9zcmlvdg0KKiBlbXVsYXRlIGNvbW1h bmQgcmVnaXN0ZXIgcmVhZCBmb3IgVkZzDQoNCnYxLT52MjoNCiogc3dpdGNoIHRvIFZGIGRpc2Nv dmVyeSBieSBYZW4NCiogZml4IHNlcXVlbnRpYWwgdnBjaV9tb2RpZnlfYmFycyBjYWxscw0KKiBt b3ZlIGRvY3VtZW50YXRpb24gY2hhbmdlcyB0byBhIHNlcGFyYXRlIGNvbW1pdA0KLS0tDQogQ0hB TkdFTE9HLm1kICAgICAgICAgICAgICAgICAgfCAgIDEgKw0KIFNVUFBPUlQubWQgICAgICAgICAg ICAgICAgICAgIHwgICAyIC0NCiB0b29scy90ZXN0cy92cGNpL2VtdWwuaCAgICAgICB8ICAgNCAr DQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcGNpLmMgfCAgNDQgKysrDQogeGVuL2RyaXZlcnMv cGNpL3BoeXNkZXYuYyAgICAgfCAgMTYgKy0NCiB4ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlICAg ICB8ICAgMSArDQogeGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYyAgICAgfCAgMTAgKy0NCiB4ZW4v ZHJpdmVycy92cGNpL3ByaXZhdGUuaCAgICB8ICAxNSArDQogeGVuL2RyaXZlcnMvdnBjaS9zcmlv di5jICAgICAgfCA1MDcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9k cml2ZXJzL3ZwY2kvdnBjaS5jICAgICAgIHwgIDE0ICsNCiB4ZW4vaW5jbHVkZS94ZW4vcGNpLmgg ICAgICAgICB8ICAgMyArDQogeGVuL2luY2x1ZGUveGVuL3ZwY2kuaCAgICAgICAgfCAgMjQgKy0N CiAxMiBmaWxlcyBjaGFuZ2VkLCA2MjkgaW5zZXJ0aW9ucygrKSwgMTIgZGVsZXRpb25zKC0pDQog Y3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9kcml2ZXJzL3ZwY2kvc3Jpb3YuYw0KDQpkaWZmIC0tZ2l0 IGEvQ0hBTkdFTE9HLm1kIGIvQ0hBTkdFTE9HLm1kDQppbmRleCBhMmRkMDEwMzdiLi42OWYzMTc1 MDE0IDEwMDY0NA0KLS0tIGEvQ0hBTkdFTE9HLm1kDQorKysgYi9DSEFOR0VMT0cubWQNCkBAIC0x Niw2ICsxNiw3IEBAIFRoZSBmb3JtYXQgaXMgYmFzZWQgb24gW0tlZXAgYSBDaGFuZ2Vsb2ddKGh0 dHBzOi8va2VlcGFjaGFuZ2Vsb2cuY29tL2VuLzEuMC4wLykNCiAgICAgIGFmdGVyd2FyZHMuDQog DQogIyMjIEFkZGVkDQorIC0gUENJIFNSLUlPViBpcyBzdXBwb3J0ZWQgZm9yIFBWSCBkb20wLg0K IA0KICMjIyBSZW1vdmVkDQogIC0gT24geDg2Og0KZGlmZiAtLWdpdCBhL1NVUFBPUlQubWQgYi9T VVBQT1JULm1kDQppbmRleCBlYjA3MzMyNDYyLi42MmM5ZmQ1NGU4IDEwMDY0NA0KLS0tIGEvU1VQ UE9SVC5tZA0KKysrIGIvU1VQUE9SVC5tZA0KQEAgLTE3MCw4ICsxNzAsNiBAQCB1bmV4cGVjdGVk IGJlaGF2aW9yIG9yIGlzc3VlcyBvbiBzb21lIGhhcmR3YXJlLg0KIA0KIEF0IGxlYXN0IHRoZSBm b2xsb3dpbmcgZmVhdHVyZXMgYXJlIG1pc3Npbmcgb24gYSBQVkggZG9tMDoNCiANCi0gICogUENJ IFNSLUlPVi4NCi0NCiAgICogTmF0aXZlIE5NSSBmb3J3YXJkaW5nIChubWk9ZG9tMCBjb21tYW5k IGxpbmUgb3B0aW9uKS4NCiANCiAgICogTUNFIGhhbmRsaW5nLg0KZGlmZiAtLWdpdCBhL3Rvb2xz L3Rlc3RzL3ZwY2kvZW11bC5oIGIvdG9vbHMvdGVzdHMvdnBjaS9lbXVsLmgNCmluZGV4IDM4MjEx YWZiYjguLjAxNzcwZGM4NTEgMTAwNjQ0DQotLS0gYS90b29scy90ZXN0cy92cGNpL2VtdWwuaA0K KysrIGIvdG9vbHMvdGVzdHMvdnBjaS9lbXVsLmgNCkBAIC0xMDEsNiArMTAxLDEwIEBAIHR5cGVk ZWYgdW5pb24gew0KICNkZWZpbmUgcGNpX2dldF9wZGV2KC4uLikgKCZ0ZXN0X3BkZXYpDQogI2Rl ZmluZSBwY2lfZ2V0X3JvX21hcCguLi4pIE5VTEwNCiANCisjZGVmaW5lIHBjaV92Zl9zZXR1cF9w ZW5kaW5nKC4uLikgZmFsc2UNCisjZGVmaW5lIHZwY2lfc3Jpb3ZfYWRkX3ZmKC4uLikgZmFsc2UN CisjZGVmaW5lIHZwY2lfc3Jpb3ZfZHJvcF92ZnMoLi4uKQ0KKw0KICNkZWZpbmUgdGVzdF9iaXQo Li4uKSBmYWxzZQ0KIA0KIC8qIER1bW15IG5hdGl2ZSBoZWxwZXJzLiBXcml0ZXMgYXJlIGlnbm9y ZWQsIHJlYWRzIHJldHVybiAxJ3MuICovDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvcGNpLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9wY2kuYw0KaW5kZXggNTc4NDcy ZDA2OC4uNjNkMjA3YjVkNiAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Bj aS5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9wY2kuYw0KQEAgLTMyLDYgKzMyLDcg QEANCiAjaW5jbHVkZSA8eGVuL3NvZnRpcnEuaD4NCiAjaW5jbHVkZSA8eGVuL3Rhc2tsZXQuaD4N CiAjaW5jbHVkZSA8eGVuL3ZwY2kuaD4NCisjaW5jbHVkZSA8eGVuL3h2bWFsbG9jLmg+DQogI2lu Y2x1ZGUgPHhlbi9tc2kuaD4NCiAjaW5jbHVkZSA8eHNtL3hzbS5oPg0KICNpbmNsdWRlICJhdHMu aCINCkBAIC00MCw2ICs0MSw4IEBAIHN0cnVjdCBwY2lfc2VnIHsNCiAgICAgc3RydWN0IGxpc3Rf aGVhZCBhbGxkZXZzX2xpc3Q7DQogICAgIHUxNiBucjsNCiAgICAgdW5zaWduZWQgbG9uZyAqcm9f bWFwOw0KKyAgICAvKiBCREZzIG9mIFZGcyB3aGljaCBoYXZlIGJlZW4gZW5hYmxlZCBidXQgd2hp Y2ggWGVuIGhhcyBub3QgYWRkZWQgeWV0LiAqLw0KKyAgICB1bnNpZ25lZCBsb25nICp2Zl9zZXR1 cF9tYXA7DQogICAgIC8qIGJ1czJicmlkZ2VfbG9jayBwcm90ZWN0cyBidXMyYnJpZGdlIGFycmF5 ICovDQogICAgIHNwaW5sb2NrX3QgYnVzMmJyaWRnZV9sb2NrOw0KICNkZWZpbmUgTUFYX0JVU0VT IDI1Ng0KQEAgLTEzOSw2ICsxNDIsNDcgQEAgY29uc3QgdW5zaWduZWQgbG9uZyAqcGNpX2dldF9y b19tYXAodTE2IHNlZykNCiAgICAgcmV0dXJuIHBzZWcgPyBwc2VnLT5yb19tYXAgOiBOVUxMOw0K IH0NCiANCisvKg0KKyAqIE1hcmtpbmcgaXMgc2VyaWFsaXNlZCBieSB0aGUgaGFyZHdhcmUgZG9t YWluJ3MgcGNpX2xvY2ssIHdoaWNoIHRoZSBTUi1JT1YNCisgKiBjb250cm9sIHJlZ2lzdGVyIHdy aXRlIGhhbmRsZXIgaG9sZHM7IHVubWFya2luZyBvbmx5IGNsZWFycyBhIGJpdC4NCisgKi8NCitp bnQgcGNpX3ZmX3NldHVwX2JlZ2luKHBjaV9zYmRmX3Qgc2JkZikNCit7DQorICAgIHN0cnVjdCBw Y2lfc2VnICpwc2VnID0gZ2V0X3BzZWcoc2JkZi5zZWcpOw0KKw0KKyAgICBpZiAoICFwc2VnICkN CisgICAgICAgIHJldHVybiAtRU5PREVWOw0KKw0KKyAgICBpZiAoICFwc2VnLT52Zl9zZXR1cF9t YXAgKQ0KKyAgICB7DQorICAgICAgICB1bnNpZ25lZCBpbnQgbnIgPSBQQ0lfQkRGKC0xLCAtMSwg LTEpICsgMTsNCisNCisgICAgICAgIHBzZWctPnZmX3NldHVwX21hcCA9IHh2emFsbG9jX2FycmF5 KHVuc2lnbmVkIGxvbmcsIEJJVFNfVE9fTE9OR1MobnIpKTsNCisgICAgICAgIGlmICggIXBzZWct PnZmX3NldHVwX21hcCApDQorICAgICAgICAgICAgcmV0dXJuIC1FTk9NRU07DQorICAgIH0NCisN CisgICAgc2V0X2JpdChzYmRmLmJkZiwgcHNlZy0+dmZfc2V0dXBfbWFwKTsNCisNCisgICAgcmV0 dXJuIDA7DQorfQ0KKw0KK3ZvaWQgcGNpX3ZmX3NldHVwX2VuZChwY2lfc2JkZl90IHNiZGYpDQor ew0KKyAgICBjb25zdCBzdHJ1Y3QgcGNpX3NlZyAqcHNlZyA9IGdldF9wc2VnKHNiZGYuc2VnKTsN CisNCisgICAgaWYgKCBwc2VnICYmIHBzZWctPnZmX3NldHVwX21hcCApDQorICAgICAgICBjbGVh cl9iaXQoc2JkZi5iZGYsIHBzZWctPnZmX3NldHVwX21hcCk7DQorfQ0KKw0KK2Jvb2wgcGNpX3Zm X3NldHVwX3BlbmRpbmcocGNpX3NiZGZfdCBzYmRmKQ0KK3sNCisgICAgY29uc3Qgc3RydWN0IHBj aV9zZWcgKnBzZWcgPSBnZXRfcHNlZyhzYmRmLnNlZyk7DQorDQorICAgIHJldHVybiBwc2VnICYm IHBzZWctPnZmX3NldHVwX21hcCAmJg0KKyAgICAgICAgICAgdGVzdF9iaXQoc2JkZi5iZGYsIHBz ZWctPnZmX3NldHVwX21hcCk7DQorfQ0KKw0KIHN0YXRpYyBzdHJ1Y3QgcGhhbnRvbV9kZXYgew0K ICAgICB1MTYgc2VnOw0KICAgICB1OCBidXMsIHNsb3QsIHN0cmlkZTsNCmRpZmYgLS1naXQgYS94 ZW4vZHJpdmVycy9wY2kvcGh5c2Rldi5jIGIveGVuL2RyaXZlcnMvcGNpL3BoeXNkZXYuYw0KaW5k ZXggNTY5NWMzMDBmNy4uN2MwMjc3YTdlNCAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3BjaS9w aHlzZGV2LmMNCisrKyBiL3hlbi9kcml2ZXJzL3BjaS9waHlzZGV2LmMNCkBAIC0yNiwxNSArMjYs MTUgQEAgcmV0X3QgcGNpX3BoeXNkZXZfb3AoaW50IGNtZCwgWEVOX0dVRVNUX0hBTkRMRV9QQVJB TSh2b2lkKSBhcmcpDQogICAgICAgICBpZiAoIGNvcHlfZnJvbV9ndWVzdCgmYWRkLCBhcmcsIDEp ICE9IDAgKQ0KICAgICAgICAgICAgIGJyZWFrOw0KIA0KLSAgICAgICAgcGRldl9pbmZvLmlzX2V4 dGZuID0gKGFkZC5mbGFncyAmIFhFTl9QQ0lfREVWX0VYVEZOKTsNCisgICAgICAgIC8qDQorICAg ICAgICAgKiBWaXJ0dWFsIGZ1bmN0aW9ucyBhcmUgYWx3YXlzIGRpc2NvdmVyZWQgYnkgdGhlIGh5 cGVydmlzb3IsIHNvDQorICAgICAgICAgKiB0aGV5IGRvbid0IG5lZWQgdG8gYmUgYWRkZWQgaGVy ZS4NCisgICAgICAgICAqLw0KICAgICAgICAgaWYgKCBhZGQuZmxhZ3MgJiBYRU5fUENJX0RFVl9W SVJURk4gKQ0KLSAgICAgICAgew0KLSAgICAgICAgICAgIHBkZXZfaW5mby5pc192aXJ0Zm4gPSB0 cnVlOw0KLSAgICAgICAgICAgIHBkZXZfaW5mby5waHlzZm4uYnVzID0gYWRkLnBoeXNmbi5idXM7 DQotICAgICAgICAgICAgcGRldl9pbmZvLnBoeXNmbi5kZXZmbiA9IGFkZC5waHlzZm4uZGV2Zm47 DQotICAgICAgICB9DQotICAgICAgICBlbHNlDQotICAgICAgICAgICAgcGRldl9pbmZvLmlzX3Zp cnRmbiA9IGZhbHNlOw0KKyAgICAgICAgICAgIHJldHVybiAwOw0KKw0KKyAgICAgICAgcGRldl9p bmZvLmlzX2V4dGZuID0gKGFkZC5mbGFncyAmIFhFTl9QQ0lfREVWX0VYVEZOKTsNCisgICAgICAg IHBkZXZfaW5mby5pc192aXJ0Zm4gPSBmYWxzZTsNCiANCiAjaWZkZWYgQ09ORklHX05VTUENCiAg ICAgICAgIGlmICggYWRkLmZsYWdzICYgWEVOX1BDSV9ERVZfUFhNICkNCmRpZmYgLS1naXQgYS94 ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlIGIveGVuL2RyaXZlcnMvdnBjaS9NYWtlZmlsZQ0KaW5k ZXggOTc5M2E0ZjliMC4uM2FkOWEzMWYyZCAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kv TWFrZWZpbGUNCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUNCkBAIC0xLDMgKzEsNCBA QA0KIG9iai15ICs9IGNhcC5vDQorb2JqLXkgKz0gc3Jpb3Yubw0KIG9iai15ICs9IHZwY2kubyBo ZWFkZXIubyByZWJhci5vDQogb2JqLSQoQ09ORklHX0hBU19QQ0lfTVNJKSArPSBtc2kubyBtc2l4 Lm8NCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jIGIveGVuL2RyaXZlcnMv dnBjaS9oZWFkZXIuYw0KaW5kZXggMDE4ODFlNWViMi4uYTA3ZTU0N2M2NCAxMDA2NDQNCi0tLSBh L3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVy LmMNCkBAIC02MjksOCArNjI5LDEzIEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIGNtZF93cml0ZSgN CiAgICAgICogTGV0IERvbTAgcGxheSB3aXRoIGFsbCB0aGUgYml0cyBkaXJlY3RseSBleGNlcHQg Zm9yIHRoZSBtZW1vcnkNCiAgICAgICogZGVjb2Rpbmcgb25lLiBCaXRzIHRoYXQgYXJlIG5vdCBh bGxvd2VkIGZvciBEb21VIGFyZSBhbHJlYWR5DQogICAgICAqIGhhbmRsZWQgYWJvdmUgYW5kIGJ5 IHRoZSByc3ZkcF9tYXNrLg0KKyAgICAgKg0KKyAgICAgKiBQQ0lfQ09NTUFORF9NRU1PUlkgaXMg aGFyZHdpcmVkIHRvIDAgZm9yIFZGcywgc28gZm9yIHRoZSBoYXJkd2FyZSBkb21haW4NCisgICAg ICogaXQgbXVzdCBub3QgY29udHJvbCB0aGUgbWFwcGluZzogVkYgbWVtb3J5IHNwYWNlIGlzIGVu YWJsZWQgYnkgTVNFIGluIHRoZQ0KKyAgICAgKiBQRidzIFNSLUlPViBjb250cm9sIHJlZ2lzdGVy Lg0KICAgICAgKi8NCi0gICAgaWYgKCBoZWFkZXItPmJhcnNfbWFwcGVkICE9ICEhKGNtZCAmIFBD SV9DT01NQU5EX01FTU9SWSkgKQ0KKyAgICBpZiAoICEocGRldi0+aW5mby5pc192aXJ0Zm4gJiYg aXNfaGFyZHdhcmVfZG9tYWluKHBkZXYtPmRvbWFpbikpICYmDQorICAgICAgICAgaGVhZGVyLT5i YXJzX21hcHBlZCAhPSAhIShjbWQgJiBQQ0lfQ09NTUFORF9NRU1PUlkpICkNCiAgICAgICAgIC8q DQogICAgICAgICAgKiBJZ25vcmUgdGhlIGVycm9yLiBObyBtZW1vcnkgaGFzIGJlZW4gYWRkZWQg b3IgcmVtb3ZlZCBmcm9tIHRoZSBwMm0NCiAgICAgICAgICAqIChiZWNhdXNlIHRoZSBhY3R1YWwg cDJtIGNoYW5nZXMgYXJlIGRlZmVycmVkIGluIGRlZmVyX21hcCkgYW5kIHRoZQ0KQEAgLTg5MSw2 ICs4OTYsOSBAQCBpbnQgdnBjaV9pbml0X2hlYWRlcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiAN CiAgICAgaGVhZGVyLT5ndWVzdF9jbWQgPSBjbWQ7DQogDQorICAgIGlmICggcGRldi0+aW5mby5p c192aXJ0Zm4gKQ0KKyAgICAgICAgcmV0dXJuIHZwY2lfdmZfaW5pdF9oZWFkZXIocGRldik7DQor DQogICAgIC8qIERpc2FibGUgbWVtb3J5IGRlY29kaW5nIGJlZm9yZSBzaXppbmcuICovDQogICAg IGlmICggIWlzX2h3ZG9tIHx8IChjbWQgJiBQQ0lfQ09NTUFORF9NRU1PUlkpICkNCiAgICAgICAg IHBjaV9jb25mX3dyaXRlMTYocGRldi0+c2JkZiwgUENJX0NPTU1BTkQsIGNtZCAmIH5QQ0lfQ09N TUFORF9NRU1PUlkpOw0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvcHJpdmF0ZS5oIGIv eGVuL2RyaXZlcnMvdnBjaS9wcml2YXRlLmgNCmluZGV4IGYwMTJmZDE2MGQuLjFmYWY4N2E2Mjgg MTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92cGNpL3ByaXZhdGUuaA0KKysrIGIveGVuL2RyaXZl cnMvdnBjaS9wcml2YXRlLmgNCkBAIC00NSw2ICs0NSw3IEBAIHR5cGVkZWYgc3RydWN0IHsNCiAg ICAgUkVHSVNURVJfVlBDSV9DQVBBQklMSVRZKFBDSV9FWFRfQ0FQX0lEXyMjbmFtZSwgbmFtZSwg ZmluaXQsIGZjbGVhbiwgdHJ1ZSkNCiANCiBpbnQgX19tdXN0X2NoZWNrIHZwY2lfaW5pdF9oZWFk ZXIoc3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KK2ludCBfX211c3RfY2hlY2sgdnBjaV92Zl9pbml0 X2hlYWRlcihzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQogDQogaW50IHZwY2lfaW5pdF9jYXBhYmls aXRpZXMoc3RydWN0IHBjaV9kZXYgKnBkZXYsIGJvb2wgZXh0X29ubHkpOw0KIHZvaWQgdnBjaV9j bGVhbnVwX2NhcGFiaWxpdGllcyhzdHJ1Y3QgcGNpX2RldiAqcGRldiwgYm9vbCBleHRfb25seSk7 DQpAQCAtMTQxLDYgKzE0MiwyMCBAQCBzdGF0aWMgaW5saW5lIHNpemVfdCB2bXNpeF90YWJsZV9z aXplKGNvbnN0IHN0cnVjdCB2cGNpICp2cGNpLCB1bnNpZ25lZCBpbnQgbnIpDQogLyogTWFwL3Vu bWFwIHRoZSBCQVJzIG9mIGEgdlBDSSBkZXZpY2UuICovDQogaW50IHZwY2lfbW9kaWZ5X2JhcnMo Y29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSk7 DQogDQorLyoNCisgKiBIYW5kbGUgYSBjb25maWcgc3BhY2UgYWNjZXNzIHRvIGEgVkYgd2hpY2gg aXMgZW5hYmxlZCBpbiBoYXJkd2FyZSBidXQgbm90DQorICoga25vd24gdG8gWGVuIHlldC4gIFJl dHVybnMgZmFsc2Ugd2hpbGUgdGhlIFZGIG5lZWQgbm90IHJlc3BvbmQsIGluIHdoaWNoDQorICog Y2FzZSB0aGUgYWNjZXNzIGhhcyB0byBiZSB0ZXJtaW5hdGVkLiAgTXVzdCBiZSBjYWxsZWQgd2l0 aCBubyBQQ0kgbG9jaw0KKyAqIGhlbGQsIGFzIGFkZGluZyBhIGRldmljZSBhY3F1aXJlcyB0aGVt Lg0KKyAqLw0KK2Jvb2wgdnBjaV9zcmlvdl9hZGRfdmYocGNpX3NiZGZfdCBzYmRmKTsNCisNCisv Kg0KKyAqIFJlbW92ZSB0aGUgVkZzIG9mIHRoZSBQRiB3aG9zZSBWRiBFbmFibGUgdGhlIGNvbmZp ZyBzcGFjZSB3cml0ZSBpbiBwcm9ncmVzcw0KKyAqIGhhcyBjbGVhcmVkLiAgU2FtZSBsb2NraW5n IHJlcXVpcmVtZW50IGFzIGFib3ZlLg0KKyAqLw0KK3ZvaWQgdnBjaV9zcmlvdl9kcm9wX3Zmcyh2 b2lkKTsNCisNCiB2b2lkIGNmX2NoZWNrIHZwY2lfZ3Vlc3RfbWVtX2Jhcl93cml0ZShjb25zdCBz dHJ1Y3QgcGNpX2RldiAqcGRldiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bnNpZ25lZCBpbnQgcmVnLCB1aW50MzJfdCB2YWwsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdm9pZCAqZGF0YSk7DQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZl cnMvdnBjaS9zcmlvdi5jIGIveGVuL2RyaXZlcnMvdnBjaS9zcmlvdi5jDQpuZXcgZmlsZSBtb2Rl IDEwMDY0NA0KaW5kZXggMDAwMDAwMDAwMC4uNGUwOWJkZmJmZA0KLS0tIC9kZXYvbnVsbA0KKysr IGIveGVuL2RyaXZlcnMvdnBjaS9zcmlvdi5jDQpAQCAtMCwwICsxLDUwNyBAQA0KKy8qIFNQRFgt TGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCisvKg0KKyAqIEhhbmRsZXJzIGZv ciBhY2Nlc3NlcyB0byB0aGUgU1ItSU9WIGNhcGFiaWxpdHkgc3RydWN0dXJlLg0KKyAqDQorICog Q29weXJpZ2h0IChDKSAyMDI2IENpdHJpeCBTeXN0ZW1zIFImRA0KKyAqLw0KKw0KKyNpbmNsdWRl ICJwcml2YXRlLmgiDQorDQorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KKyNpbmNsdWRlIDx4ZW4v c29mdGlycS5oPg0KKyNpbmNsdWRlIDx4ZW4vdGltZS5oPg0KKyNpbmNsdWRlIDx4ZW4vdnBjaS5o Pg0KKyNpbmNsdWRlIDx4ZW4veHZtYWxsb2MuaD4NCisNCisjaW5jbHVkZSA8eHNtL3hzbS5oPg0K Kw0KK3N0YXRpYyBpbnQgdmZfaW5pdF9iYXJzKHN0cnVjdCBwY2lfZGV2ICp2Zl9wZGV2KQ0KK3sN CisgICAgaW50IHZmX2lkeDsNCisgICAgdW5zaWduZWQgaW50IGk7DQorICAgIGNvbnN0IHN0cnVj dCBwY2lfZGV2ICpwZl9wZGV2ID0gdmZfcGRldi0+cGZfcGRldjsNCisgICAgc3RydWN0IHZwY2lf YmFyICpiYXJzID0gdmZfcGRldi0+dnBjaS0+aGVhZGVyLmJhcnM7DQorICAgIHN0cnVjdCB2cGNp X2JhciAqcGh5c2ZuX3ZmX2JhcnMgPSBwZl9wZGV2LT52cGNpLT5zcmlvdi0+dmZfYmFyczsNCisg ICAgc3RydWN0IHZwY2lfc3Jpb3YgKnNyaW92ID0gcGZfcGRldi0+dnBjaS0+c3Jpb3Y7DQorDQor ICAgIHZmX2lkeCA9IHZmX3BkZXYtPnNiZGYuc2JkZiAtIChwZl9wZGV2LT5zYmRmLnNiZGYgKyBz cmlvdi0+b2Zmc2V0KTsNCisgICAgaWYgKCB2Zl9pZHggPCAwICkNCisgICAgICAgIHJldHVybiAt RUlOVkFMOw0KKw0KKyAgICBpZiAoIHNyaW92LT5udW1fdmZzID4gMSAmJiAhc3Jpb3YtPnN0cmlk ZSApDQorICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisNCisgICAgaWYgKCBzcmlvdi0+c3RyaWRl ICkNCisgICAgew0KKyAgICAgICAgaWYgKCB2Zl9pZHggJSBzcmlvdi0+c3RyaWRlICkNCisgICAg ICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisgICAgICAgIHZmX2lkeCAvPSBzcmlvdi0+c3RyaWRl Ow0KKyAgICB9DQorDQorICAgIGlmICggdmZfaWR4ID49IHNyaW92LT5udW1fdmZzICkNCisgICAg ICAgIHJldHVybiAtRUlOVkFMOw0KKw0KKyAgICAvKg0KKyAgICAgKiBTZXQgdXAgQkFScyBmb3Ig dGhpcyBWRiBvdXQgb2YgUEYncyBWRiBCQVJzIHRha2luZyBpbnRvIGFjY291bnQNCisgICAgICog dGhlIGluZGV4IG9mIHRoZSBWRi4NCisgICAgICovDQorICAgIGZvciAoIGkgPSAwOyBpIDwgUENJ X1NSSU9WX05VTV9CQVJTOyBpKysgKQ0KKyAgICB7DQorICAgICAgICBzdHJ1Y3QgdnBjaV9iYXIg KnBmX2JhciA9ICZwaHlzZm5fdmZfYmFyc1tpXTsNCisgICAgICAgIHN0cnVjdCB2cGNpX2JhciAq YmFyID0gJmJhcnNbaV07DQorDQorICAgICAgICAvKg0KKyAgICAgICAgICogVGhlIHVwcGVyIGhh bGYgb2YgYSA2NC1iaXQgQkFSIGhvbGRzIG5vIGFkZHJlc3Mgb3Igc2l6ZSBvZiBpdHMgb3duOw0K KyAgICAgICAgICogdGhlIGhhbmRsZXJzIHJlYWNoIHRoZSBsb3dlciBoYWxmIHRocm91Z2ggaXRz IHR5cGUgYWxvbmUuDQorICAgICAgICAgKi8NCisgICAgICAgIGlmICggcGZfYmFyLT50eXBlID09 IFZQQ0lfQkFSX01FTTY0X0hJICkNCisgICAgICAgIHsNCisgICAgICAgICAgICBiYXItPnR5cGUg PSBWUENJX0JBUl9NRU02NF9ISTsNCisgICAgICAgICAgICBjb250aW51ZTsNCisgICAgICAgIH0N CisNCisgICAgICAgIGlmICggcGZfYmFyLT50eXBlICE9IFZQQ0lfQkFSX01FTTMyICYmDQorICAg ICAgICAgICAgIHBmX2Jhci0+dHlwZSAhPSBWUENJX0JBUl9NRU02NF9MTyApDQorICAgICAgICAg ICAgY29udGludWU7DQorDQorICAgICAgICBiYXItPmFkZHIgICAgICAgICA9IHBmX2Jhci0+YWRk ciArIHZmX2lkeCAqIHBmX2Jhci0+c2l6ZTsNCisgICAgICAgIGJhci0+Z3Vlc3RfYWRkciAgID0g aXNfaGFyZHdhcmVfZG9tYWluKHZmX3BkZXYtPmRvbWFpbikgPyBiYXItPmFkZHIgOiAwOw0KKyAg ICAgICAgYmFyLT5zaXplICAgICAgICAgPSBwZl9iYXItPnNpemU7DQorICAgICAgICBiYXItPnR5 cGUgICAgICAgICA9IHBmX2Jhci0+dHlwZTsNCisgICAgICAgIGJhci0+cHJlZmV0Y2hhYmxlID0g cGZfYmFyLT5wcmVmZXRjaGFibGU7DQorICAgIH0NCisNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0K K2ludCB2cGNpX3ZmX2luaXRfaGVhZGVyKHN0cnVjdCBwY2lfZGV2ICp2Zl9wZGV2KQ0KK3sNCisg ICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBmX3BkZXY7DQorICAgIGludCByYyA9IDA7DQorICAg IHVpbnQxNl90IGN0cmw7DQorDQorICAgIEFTU0VSVChyd19pc193cml0ZV9sb2NrZWQoJnZmX3Bk ZXYtPmRvbWFpbi0+cGNpX2xvY2spKTsNCisgICAgQVNTRVJUKHZmX3BkZXYtPmluZm8uaXNfdmly dGZuKTsNCisNCisgICAgcGZfcGRldiA9IHZmX3BkZXYtPnBmX3BkZXY7DQorICAgIEFTU0VSVChw Zl9wZGV2KTsNCisNCisgICAgcmMgPSB2Zl9pbml0X2JhcnModmZfcGRldik7DQorICAgIGlmICgg cmMgKQ0KKyAgICAgICAgcmV0dXJuIHJjOw0KKw0KKyAgICBjdHJsID0gcGNpX2NvbmZfcmVhZDE2 KHBmX3BkZXYtPnNiZGYsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgcGZfcGRldi0+dnBj aS0+c3Jpb3YtPnBvcyArIFBDSV9TUklPVl9DVFJMKTsNCisNCisgICAgaWYgKCAocGZfcGRldi0+ ZG9tYWluID09IHZmX3BkZXYtPmRvbWFpbikgJiYgKGN0cmwgJiBQQ0lfU1JJT1ZfQ1RSTF9NU0Up ICkNCisgICAgew0KKyAgICAgICAgcmMgPSB2cGNpX21vZGlmeV9iYXJzKHZmX3BkZXYsIFBDSV9D T01NQU5EX01FTU9SWSwgZmFsc2UpOw0KKyAgICAgICAgaWYgKCByYyApDQorICAgICAgICAgICAg cmV0dXJuIHJjOw0KKyAgICB9DQorDQorICAgIHJldHVybiByYzsNCit9DQorDQorc3RhdGljIGlu dCBtYXBfdmZzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZl9wZGV2LCB1aW50MTZfdCBjbWQpDQor ew0KKyAgICBzdHJ1Y3QgcGNpX2RldiAqdmZfcGRldjsNCisgICAgaW50IHJjOw0KKw0KKyAgICBB U1NFUlQocndfaXNfd3JpdGVfbG9ja2VkKCZwZl9wZGV2LT5kb21haW4tPnBjaV9sb2NrKSk7DQor DQorICAgIGxpc3RfZm9yX2VhY2hfZW50cnkodmZfcGRldiwgJnBmX3BkZXYtPnZmX2xpc3QsIHZm X2xpc3QpDQorICAgIHsNCisgICAgICAgIC8qIERvbid0IHRyeSB0byBjaGFuZ2UgbWFwcGluZyBp ZiBpdCBpcyBhbHJlYWR5IGluIHRoZSBjb3JyZWN0IHN0YXRlLiAqLw0KKyAgICAgICAgaWYgKCB2 Zl9wZGV2LT52cGNpLT5oZWFkZXIuYmFyc19tYXBwZWQgPT0gISFjbWQgKQ0KKyAgICAgICAgICAg IGNvbnRpbnVlOw0KKw0KKyAgICAgICAgcmMgPSB2cGNpX21vZGlmeV9iYXJzKHZmX3BkZXYsIGNt ZCwgZmFsc2UpOw0KKyAgICAgICAgaWYgKCByYyApDQorICAgICAgICB7DQorICAgICAgICAgICAg Z3ByaW50ayhYRU5MT0dfRVJSLCAiZmFpbGVkIHRvICVzIFZGICVwcDogJWRcbiIsDQorICAgICAg ICAgICAgICAgICAgICAoY21kICYgUENJX0NPTU1BTkRfTUVNT1JZKSA/ICJtYXAiIDogInVubWFw IiwNCisgICAgICAgICAgICAgICAgICAgICZ2Zl9wZGV2LT5zYmRmLCByYyk7DQorICAgICAgICAg ICAgcmV0dXJuIHJjOw0KKyAgICAgICAgfQ0KKyAgICB9DQorDQorICAgIHJldHVybiAwOw0KK30N CisNCitzdGF0aWMgdm9pZCBzaXplX3ZmX2JhcnMoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBmX3Bk ZXYsIHVuc2lnbmVkIGludCBzcmlvdl9wb3MsDQorICAgICAgICAgICAgICAgICAgICAgICAgIHVp bnQ2NF90ICp2Zl9ybGVuKQ0KK3sNCisgICAgc3RydWN0IHZwY2lfYmFyICpiYXJzID0gcGZfcGRl di0+dnBjaS0+c3Jpb3YtPnZmX2JhcnM7DQorICAgIHVuc2lnbmVkIGludCBpOw0KKyAgICBpbnQg cmMgPSAwOw0KKw0KKyAgICBBU1NFUlQocndfaXNfd3JpdGVfbG9ja2VkKCZwZl9wZGV2LT5kb21h aW4tPnBjaV9sb2NrKSk7DQorICAgIEFTU0VSVCghcGZfcGRldi0+aW5mby5pc192aXJ0Zm4pOw0K KyAgICBBU1NFUlQocGZfcGRldi0+dnBjaS0+c3Jpb3YpOw0KKw0KKyAgICAvKiBTZXQgdGhlIEJB UnMgYWRkcmVzc2VzIGFuZCBzaXplLiAqLw0KKyAgICBmb3IgKCBpID0gMDsgaSA8IFBDSV9TUklP Vl9OVU1fQkFSUzsgaSArPSByYyApDQorICAgIHsNCisgICAgICAgIHVuc2lnbmVkIGludCBpZHgg PSBzcmlvdl9wb3MgKyBQQ0lfU1JJT1ZfQkFSICsgaSAqIDQ7DQorICAgICAgICB1aW50MzJfdCBi YXI7DQorICAgICAgICB1aW50NjRfdCBhZGRyLCBzaXplOw0KKw0KKyAgICAgICAgYmFyID0gcGNp X2NvbmZfcmVhZDMyKHBmX3BkZXYtPnNiZGYsIGlkeCk7DQorDQorICAgICAgICByYyA9IHBjaV9z aXplX21lbV9iYXIocGZfcGRldi0+c2JkZiwgaWR4LCAmYWRkciwgJnNpemUsDQorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUENJX0JBUl9WRiB8DQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKChpID09IFBDSV9TUklPVl9OVU1fQkFSUyAtIDEpID8gUENJX0JBUl9MQVNUDQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDogMCkpOw0KKw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFVwZGF0ZSB2Zl9ybGVuIG9u IHRoZSBQRi4gQWNjb3JkaW5nIHRvIHRoZSBzcGVjIHRoZSBzaXplIG9mDQorICAgICAgICAgKiB0 aGUgQkFScyBjYW4gY2hhbmdlIGlmIHRoZSBzeXN0ZW0gcGFnZSBzaXplIHJlZ2lzdGVyIGlzDQor ICAgICAgICAgKiBtb2RpZmllZCwgc28gYWx3YXlzIHVwZGF0ZSBybGVuIHdoZW4gZW5hYmxpbmcg VkZzLg0KKyAgICAgICAgICovDQorICAgICAgICB2Zl9ybGVuW2ldID0gc2l6ZTsNCisNCisgICAg ICAgIGlmICggIXNpemUgKQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIGJhcnNbaV0udHlwZSA9 IFZQQ0lfQkFSX0VNUFRZOw0KKyAgICAgICAgICAgIGNvbnRpbnVlOw0KKyAgICAgICAgfQ0KKw0K KyAgICAgICAgYmFyc1tpXS5hZGRyID0gYWRkcjsNCisgICAgICAgIGJhcnNbaV0uZ3Vlc3RfYWRk ciA9IGFkZHI7DQorICAgICAgICBiYXJzW2ldLnNpemUgPSBzaXplOw0KKyAgICAgICAgYmFyc1tp XS5wcmVmZXRjaGFibGUgPSBiYXIgJiBQQ0lfQkFTRV9BRERSRVNTX01FTV9QUkVGRVRDSDsNCisN CisgICAgICAgIHN3aXRjaCAoIHJjICkNCisgICAgICAgIHsNCisgICAgICAgIGNhc2UgMToNCisg ICAgICAgICAgICBiYXJzW2ldLnR5cGUgPSBWUENJX0JBUl9NRU0zMjsNCisgICAgICAgICAgICBi cmVhazsNCisNCisgICAgICAgIGNhc2UgMjoNCisgICAgICAgICAgICBiYXJzW2ldLnR5cGUgPSBW UENJX0JBUl9NRU02NF9MTzsNCisgICAgICAgICAgICBiYXJzW2kgKyAxXS50eXBlID0gVlBDSV9C QVJfTUVNNjRfSEk7DQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICBkZWZhdWx0Og0K KyAgICAgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KKyAgICAgICAgICAgIHJjID0gMTsN CisgICAgICAgIH0NCisgICAgfQ0KK30NCisNCisvKg0KKyAqIEFjY2Vzc2VzIHRvIGEgbWFya2Vk IEJERiBhcmUgdGVybWluYXRlZCB1bnRpbCAxMDBtcyBhZnRlciBWRiBFbmFibGU7IHRoZQ0KKyAq IGZpcnN0IG9uZSBwYXN0IHRoYXQgYWRkcyB0aGUgVkYsIHdoaWNoIGNvbnRyb2xfd3JpdGUoKSBj YW5ub3QgZG8gaXRzZWxmLg0KKyAqLw0KK3N0YXRpYyBwY2lfc2JkZl90IHZmX3NiZGYoY29uc3Qg c3RydWN0IHBjaV9kZXYgKnBmX3BkZXYsIHVuc2lnbmVkIGludCBpZHgpDQorew0KKyAgICBjb25z dCBzdHJ1Y3QgdnBjaV9zcmlvdiAqc3Jpb3YgPSBwZl9wZGV2LT52cGNpLT5zcmlvdjsNCisgICAg cGNpX3NiZGZfdCBzYmRmID0gcGZfcGRldi0+c2JkZjsNCisNCisgICAgc2JkZi5iZGYgKz0gc3Jp b3YtPm9mZnNldCArIHNyaW92LT5zdHJpZGUgKiBpZHg7DQorDQorICAgIHJldHVybiBzYmRmOw0K K30NCisNCitzdGF0aWMgdm9pZCBtYXJrX3Zmcyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGZfcGRl dikNCit7DQorICAgIHN0cnVjdCB2cGNpX3NyaW92ICpzcmlvdiA9IHBmX3BkZXYtPnZwY2ktPnNy aW92Ow0KKyAgICB1bnNpZ25lZCBpbnQgaTsNCisNCisgICAgLyogVkYgT2Zmc2V0IGFuZCBWRiBT dHJpZGUgYXJlIG9ubHkgdmFsaWQgd2hpbGUgVkYgRW5hYmxlIGlzIHNldC4gKi8NCisgICAgc3Jp b3YtPm9mZnNldCA9IHBjaV9jb25mX3JlYWQxNihwZl9wZGV2LT5zYmRmLA0KKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHNyaW92LT5wb3MgKyBQQ0lfU1JJT1ZfVkZfT0ZGU0VU KTsNCisgICAgc3Jpb3YtPnN0cmlkZSA9IHBjaV9jb25mX3JlYWQxNihwZl9wZGV2LT5zYmRmLA0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyaW92LT5wb3MgKyBQQ0lfU1JJ T1ZfVkZfU1RSSURFKTsNCisgICAgc3Jpb3YtPnZmc19yZWFkeSA9IE5PVygpICsgTUlMTElTRUNT KDEwMCk7DQorDQorICAgIGZvciAoIGkgPSAwOyBpIDwgc3Jpb3YtPm51bV92ZnM7IGkrKyApDQor ICAgIHsNCisgICAgICAgIHBjaV9zYmRmX3Qgc2JkZiA9IHZmX3NiZGYocGZfcGRldiwgaSk7DQor ICAgICAgICBpbnQgcmMgPSBwY2lfdmZfc2V0dXBfYmVnaW4oc2JkZik7DQorDQorICAgICAgICBp ZiAoIHJjICkNCisgICAgICAgICAgICBncHJpbnRrKFhFTkxPR19XQVJOSU5HLCAiJXBwOiBjYW5u b3Qgc2V0IHVwIFZGICVwcDogJWRcbiIsDQorICAgICAgICAgICAgICAgICAgICAmcGZfcGRldi0+ c2JkZiwgJnNiZGYsIHJjKTsNCisgICAgfQ0KK30NCisNCitzdGF0aWMgdm9pZCB1bm1hcmtfdmZz KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZl9wZGV2KQ0KK3sNCisgICAgc3RydWN0IHZwY2lfc3Jp b3YgKnNyaW92ID0gcGZfcGRldi0+dnBjaS0+c3Jpb3Y7DQorICAgIHVuc2lnbmVkIGludCBpOw0K Kw0KKyAgICBpZiAoICFzcmlvdi0+dmZzX3JlYWR5ICkNCisgICAgICAgIHJldHVybjsNCisNCisg ICAgZm9yICggaSA9IDA7IGkgPCBzcmlvdi0+bnVtX3ZmczsgaSsrICkNCisgICAgICAgIHBjaV92 Zl9zZXR1cF9lbmQodmZfc2JkZihwZl9wZGV2LCBpKSk7DQorDQorICAgIHNyaW92LT52ZnNfcmVh ZHkgPSAwOw0KK30NCisNCisvKiBGaW5kIHRoZSBQRiB3aGljaCBoYXMgZW5hYmxlZCBAc2JkZiwg aWYgdGhhdCBWRiBpcyByZWFkeSB0byBiZSBhZGRlZC4gKi8NCitzdGF0aWMgY29uc3Qgc3RydWN0 IHBjaV9kZXYgKnJlYWR5X3BmKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIHBjaV9zYmRmX3Qgc2Jk ZikNCit7DQorICAgIHN0cnVjdCBwY2lfZGV2ICpwZGV2Ow0KKw0KKyAgICBBU1NFUlQocndfaXNf bG9ja2VkKCZkLT5wY2lfbG9jaykpOw0KKw0KKyAgICBmb3JfZWFjaF9wZGV2ICggZCwgcGRldiAp DQorICAgIHsNCisgICAgICAgIGNvbnN0IHN0cnVjdCB2cGNpX3NyaW92ICpzcmlvdiA9IHBkZXYt PnZwY2kgPyBwZGV2LT52cGNpLT5zcmlvdiA6IE5VTEw7DQorICAgICAgICB1bnNpZ25lZCBpbnQg aTsNCisNCisgICAgICAgIGlmICggIXNyaW92IHx8ICFzcmlvdi0+dmZzX3JlYWR5IHx8IE5PVygp IDwgc3Jpb3YtPnZmc19yZWFkeSApDQorICAgICAgICAgICAgY29udGludWU7DQorDQorICAgICAg ICBmb3IgKCBpID0gMDsgaSA8IHNyaW92LT5udW1fdmZzOyBpKysgKQ0KKyAgICAgICAgICAgIGlm ICggdmZfc2JkZihwZGV2LCBpKS5zYmRmID09IHNiZGYuc2JkZiApDQorICAgICAgICAgICAgICAg IHJldHVybiBwZGV2Ow0KKyAgICB9DQorDQorICAgIHJldHVybiBOVUxMOw0KK30NCisNCitib29s IHZwY2lfc3Jpb3ZfYWRkX3ZmKHBjaV9zYmRmX3Qgc2JkZikNCit7DQorICAgIHN0cnVjdCBkb21h aW4gKmQgPSBjdXJyZW50LT5kb21haW47DQorICAgIHN0cnVjdCBwY2lfZGV2X2luZm8gaW5mbyA9 IHsgLmlzX3ZpcnRmbiA9IHRydWUgfTsNCisgICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBmOw0K KyAgICBwY2lfc2JkZl90IHBmX3NiZGY7DQorICAgIG5vZGVpZF90IG5vZGU7DQorICAgIGludCBy YzsNCisNCisgICAgcmVhZF9sb2NrKCZkLT5wY2lfbG9jayk7DQorICAgIHBmID0gcmVhZHlfcGYo ZCwgc2JkZik7DQorICAgIGlmICggIXBmICkNCisgICAgew0KKyAgICAgICAgcmVhZF91bmxvY2so JmQtPnBjaV9sb2NrKTsNCisgICAgICAgIGdwcmludGsoWEVOTE9HX0RFQlVHLCAiJXBwOiBjb25m aWcgc3BhY2UgYWNjZXNzIGR1cmluZyBWRiBzZXR1cFxuIiwNCisgICAgICAgICAgICAgICAgJnNi ZGYpOw0KKyAgICAgICAgcmV0dXJuIGZhbHNlOw0KKyAgICB9DQorDQorICAgIHBmX3NiZGYgPSBw Zi0+c2JkZjsNCisgICAgaW5mby5waHlzZm4uYnVzID0gcGZfc2JkZi5idXM7DQorICAgIGluZm8u cGh5c2ZuLmRldmZuID0gcGZfc2JkZi5kZXZmbjsNCisgICAgbm9kZSA9IHBmLT5ub2RlOw0KKyAg ICByZWFkX3VubG9jaygmZC0+cGNpX2xvY2spOw0KKw0KKyAgICByYyA9IHBjaV9hZGRfZGV2aWNl KHNiZGYuc2VnLCBzYmRmLmJ1cywgc2JkZi5kZXZmbiwgJmluZm8sIG5vZGUpOw0KKyAgICBpZiAo IHJjICkNCisgICAgICAgIGdwcmludGsoWEVOTE9HX0VSUiwgIiVwcDogY2Fubm90IGFkZCBWRiAl cHA6ICVkXG4iLCAmcGZfc2JkZiwgJnNiZGYsDQorICAgICAgICAgICAgICAgIHJjKTsNCisNCisg ICAgLyoNCisgICAgICogU3RvcCB0ZXJtaW5hdGluZyBhY2Nlc3NlcyBlaXRoZXIgd2F5OiBhIFZG IHdoaWNoIFhlbiBmYWlsZWQgdG8gYWRkIGlzDQorICAgICAqIGxlZnQgZm9yIHRoZSBoYXJkd2Fy ZSBkb21haW4gdG8gcmVnaXN0ZXIuDQorICAgICAqLw0KKyAgICBwY2lfdmZfc2V0dXBfZW5kKHNi ZGYpOw0KKw0KKyAgICByZXR1cm4gdHJ1ZTsNCit9DQorDQordm9pZCB2cGNpX3NyaW92X2Ryb3Bf dmZzKHZvaWQpDQorew0KKyAgICBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJlbnQ7DQorICAgIHBj aV9zYmRmX3QgcGZfc2JkZiA9IGN1cnItPnZwY2kuZHJvcF92ZnNfcGY7DQorICAgIHN0cnVjdCBw Y2lfZGV2ICpwZiwgKnZmLCAqdG1wOw0KKw0KKyAgICBpZiAoIGxpa2VseShwZl9zYmRmLnNiZGYg PT0gfjBVKSApDQorICAgICAgICByZXR1cm47DQorDQorICAgIGN1cnItPnZwY2kuZHJvcF92ZnNf cGYuc2JkZiA9IH4wVTsNCisNCisgICAgLyoNCisgICAgICogVGhlIHVubWFwcGluZyBxdWV1ZWQg YnkgY29udHJvbF93cml0ZSgpIHN0aWxsIHJlZmVyZW5jZXMgdGhlIFZGIHBkZXZzLA0KKyAgICAg KiBzbyBpdCBoYXMgdG8gY29tcGxldGUgYmVmb3JlIHRoZXkgYXJlIGZyZWVkLg0KKyAgICAgKi8N CisgICAgd2hpbGUgKCB2cGNpX3Byb2Nlc3NfcGVuZGluZyhjdXJyKSApDQorICAgICAgICBwcm9j ZXNzX3BlbmRpbmdfc29mdGlycXMoKTsNCisNCisgICAgcGNpZGV2c19sb2NrKCk7DQorICAgIHBm ID0gcGNpX2dldF9wZGV2KE5VTEwsIHBmX3NiZGYpOw0KKyAgICBpZiAoIHBmICkNCisgICAgew0K KyAgICAgICAgbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHZmLCB0bXAsICZwZi0+dmZfbGlzdCwg dmZfbGlzdCkNCisgICAgICAgIHsNCisgICAgICAgICAgICBwY2lfc2JkZl90IHNiZGYgPSB2Zi0+ c2JkZjsNCisgICAgICAgICAgICBpbnQgcmMgPSBwY2lfcmVtb3ZlX2RldmljZShzYmRmLnNlZywg c2JkZi5idXMsIHNiZGYuZGV2Zm4pOw0KKw0KKyAgICAgICAgICAgIGlmICggcmMgKQ0KKyAgICAg ICAgICAgICAgICBncHJpbnRrKFhFTkxPR19FUlIsICIlcHA6IGNhbm5vdCByZW1vdmUgVkYgJXBw OiAlZFxuIiwNCisgICAgICAgICAgICAgICAgICAgICAgICAmcGZfc2JkZiwgJnNiZGYsIHJjKTsN CisgICAgICAgIH0NCisgICAgfQ0KKyAgICBwY2lkZXZzX3VubG9jaygpOw0KK30NCisNCitzdGF0 aWMgdm9pZCBjZl9jaGVjayBjb250cm9sX3dyaXRlKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2 LCB1bnNpZ25lZCBpbnQgcmVnLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dWludDMyX3QgdmFsLCB2b2lkICpkYXRhKQ0KK3sNCisgICAgdW5zaWduZWQgaW50IHNyaW92X3Bv cyA9IHJlZyAtIFBDSV9TUklPVl9DVFJMOw0KKyAgICBzdHJ1Y3QgdnBjaV9zcmlvdiAqc3Jpb3Yg PSBwZGV2LT52cGNpLT5zcmlvdjsNCisgICAgdWludDE2X3QgY29udHJvbCA9IHBjaV9jb25mX3Jl YWQxNihwZGV2LT5zYmRmLCByZWcpOw0KKyAgICBib29sIGVuYWJsZWQgPSBjb250cm9sICYgUENJ X1NSSU9WX0NUUkxfVkZFOw0KKyAgICBib29sIG5ld19lbmFibGVkID0gdmFsICYgUENJX1NSSU9W X0NUUkxfVkZFOw0KKyAgICAvKiBWRiBCQVJzIGRlY29kZSBvbmx5IHdoaWxlIGJvdGggVkYgRW5h YmxlIGFuZCBWRiBNU0UgYXJlIHNldC4gKi8NCisgICAgYm9vbCBkZWNvZGluZyA9IGVuYWJsZWQg JiYgKGNvbnRyb2wgJiBQQ0lfU1JJT1ZfQ1RSTF9NU0UpOw0KKyAgICBib29sIG5ld19kZWNvZGlu ZyA9IG5ld19lbmFibGVkICYmICh2YWwgJiBQQ0lfU1JJT1ZfQ1RSTF9NU0UpOw0KKyAgICBpbnQg cmM7DQorDQorICAgIEFTU0VSVCghcGRldi0+aW5mby5pc192aXJ0Zm4pOw0KKw0KKyAgICBpZiAo IG5ld19lbmFibGVkID09IGVuYWJsZWQgJiYgbmV3X2RlY29kaW5nID09IGRlY29kaW5nICkNCisg ICAgew0KKyAgICAgICAgcGNpX2NvbmZfd3JpdGUxNihwZGV2LT5zYmRmLCByZWcsIHZhbCk7DQor ICAgICAgICByZXR1cm47DQorICAgIH0NCisNCisgICAgLyogVW5tYXAgd2hpbGUgdGhlIFZGIHBk ZXZzIGFyZSBzdGlsbCBhcm91bmQgZm9yIHZwY2lfbW9kaWZ5X2JhcnMoKS4gKi8NCisgICAgaWYg KCBkZWNvZGluZyAmJiAhbmV3X2RlY29kaW5nICkNCisgICAgICAgIG1hcF92ZnMocGRldiwgMCk7 DQorDQorICAgIGlmICggZW5hYmxlZCAmJiAhbmV3X2VuYWJsZWQgKQ0KKyAgICB7DQorICAgICAg ICB1bm1hcmtfdmZzKHBkZXYpOw0KKw0KKyAgICAgICAgLyogVGhlIFZGcyBjZWFzZSB0byBleGlz dCBiZWxvdywgc28gWGVuIGhhcyB0byByZW1vdmUgdGhlbS4gKi8NCisgICAgICAgIGlmICggIWxp c3RfZW1wdHkoJnBkZXYtPnZmX2xpc3QpICkNCisgICAgICAgICAgICBjdXJyZW50LT52cGNpLmRy b3BfdmZzX3BmID0gcGRldi0+c2JkZjsNCisgICAgfQ0KKw0KKyAgICBpZiAoICFlbmFibGVkICYm IG5ld19lbmFibGVkICkNCisgICAgew0KKyAgICAgICAgc2l6ZV92Zl9iYXJzKHBkZXYsIHNyaW92 X3BvcywgZGF0YSk7DQorDQorICAgICAgICAvKg0KKyAgICAgICAgICogT25seSB1cGRhdGUgdGhl IG51bWJlciBvZiBhY3RpdmUgVkZzIHdoZW4gZW5hYmxpbmcsIHdoZW4NCisgICAgICAgICAqIGRp c2FibGluZyB1c2UgdGhlIGNhY2hlZCB2YWx1ZSBpbiBvcmRlciB0byBhbHdheXMgcmVtb3ZlIHRo ZSBzYW1lDQorICAgICAgICAgKiBudW1iZXIgb2YgVkZzIHRoYXQgd2VyZSBhY3RpdmUuDQorICAg ICAgICAgKi8NCisgICAgICAgIHNyaW92LT5udW1fdmZzID0gcGNpX2NvbmZfcmVhZDE2KHBkZXYt PnNiZGYsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcmlvdl9w b3MgKyBQQ0lfU1JJT1ZfTlVNX1ZGKTsNCisgICAgICAgIG1hcmtfdmZzKHBkZXYpOw0KKyAgICB9 DQorDQorICAgIGlmICggIWRlY29kaW5nICYmIG5ld19kZWNvZGluZyApDQorICAgIHsNCisgICAg ICAgIHJjID0gbWFwX3ZmcyhwZGV2LCBQQ0lfQ09NTUFORF9NRU1PUlkpOw0KKw0KKyAgICAgICAg aWYgKCByYyApDQorICAgICAgICAgICAgbWFwX3ZmcyhwZGV2LCAwKTsNCisgICAgfQ0KKw0KKyAg ICBwY2lfY29uZl93cml0ZTE2KHBkZXYtPnNiZGYsIHJlZywgdmFsKTsNCit9DQorDQorc3RhdGlj IGludCBjZl9jaGVjayBpbml0X3NyaW92KHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KK3sNCisgICAg dW5zaWduZWQgaW50IHBvczsNCisNCisgICAgaWYgKCBwZGV2LT5pbmZvLmlzX3ZpcnRmbiApDQor ICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisNCisgICAgcG9zID0gcGNpX2ZpbmRfZXh0X2NhcGFi aWxpdHkocGRldiwgUENJX0VYVF9DQVBfSURfU1JJT1YpOw0KKw0KKyAgICBBU1NFUlQocG9zKTsN CisNCisgICAgaWYgKCB4c21fcmVzb3VyY2Vfc2V0dXBfcGNpKFhTTV9QUklWLCBwZGV2LT5zYmRm LmJkZikgKQ0KKyAgICB7DQorICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KKyAgICAgICAgICAg ICAgICIlcHA6IFNSLUlPViBjb25maWd1cmF0aW9uIHVuc3VwcG9ydGVkIGZvciB1bnByaXYgJXBk XG4iLA0KKyAgICAgICAgICAgICAgICZwZGV2LT5zYmRmLCBwZGV2LT5kb21haW4pOw0KKyAgICAg ICAgcmV0dXJuIC1FQUNDRVM7DQorICAgIH0NCisNCisgICAgcGRldi0+dnBjaS0+c3Jpb3YgPSB4 dnphbGxvYyhzdHJ1Y3QgdnBjaV9zcmlvdik7DQorICAgIGlmICggIXBkZXYtPnZwY2ktPnNyaW92 ICkNCisgICAgICAgIHJldHVybiAtRU5PTUVNOw0KKw0KKyAgICBwZGV2LT52cGNpLT5zcmlvdi0+ cG9zID0gcG9zOw0KKw0KKyAgICAvKg0KKyAgICAgKiBXZSBuZWVkIHRvIG1vZGlmeSB2Zl9ybGVu IGluIGNvbnRyb2xfd3JpdGUgYnV0IHdlIGNhbid0IGRvIGl0IGNsZWFubHkNCisgICAgICogZnJv bSBwZGV2IGJlY2F1c2Ugd3JpdGUgY2FsbGJhY2sgb25seSBhY2NlcHRzIGNvbnN0IHBkZXYuIE1v dmluZyB2Zl9ybGVuDQorICAgICAqIGluc2lkZSBvZiBzdHJ1Y3QgdnBjaV9zcmlvdiBpcyBhbHNv IG5vdCBwb3NzaWJsZSBiZWNhdXNlIGl0IGlzIHVzZWQNCisgICAgICogYmVmb3JlIHZwY2kgaW5p dC4gU28gcGFzcyBpdCBoZXJlIGFzIGFkZGl0aW9uYWwgZGF0YSB0byBub3QgcmVxdWlyZQ0KKyAg ICAgKiBkcm9wcGluZyBjb25zdCBpbiBjb250cm9sX3dyaXRlLg0KKyAgICAgKi8NCisgICAgcmV0 dXJuIHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDE2LCBjb250cm9s X3dyaXRlLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9zICsgUENJX1NSSU9WX0NU UkwsIDIsICZwZGV2LT5waHlzZm4udmZfcmxlbik7DQorfQ0KKw0KK3N0YXRpYyBpbnQgY2ZfY2hl Y2sgY2xlYW51cF9zcmlvdihjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgYm9vbCBoaWRlKQ0K K3sNCisgICAgdW5zaWduZWQgaW50IHBvczsNCisgICAgaW50IHJjOw0KKw0KKyAgICBpZiAoICFw ZGV2LT52cGNpLT5zcmlvdiApDQorICAgICAgICByZXR1cm4gMDsNCisNCisgICAgQVNTRVJUKCFw ZGV2LT5pbmZvLmlzX3ZpcnRmbik7DQorDQorICAgIHVubWFya192ZnMocGRldik7DQorDQorICAg IGlmICggIWxpc3RfZW1wdHkoJnBkZXYtPnZmX2xpc3QpICkNCisgICAgew0KKyAgICAgICAgc3Ry dWN0IHBjaV9kZXYgKnZmX3BkZXYsICp0ZW1wOw0KKw0KKyAgICAgICAgcHJpbnRrKFhFTkxPR19X QVJOSU5HIA0KKyAgICAgICAgICAgICAgICJBdHRlbXB0aW5nIHRvIHJlbW92ZSBTUi1JT1YgUEYg JXBwIHdpdGggVkZzIHN0aWxsIHByZXNlbnQsIFZGcyB3aWxsIGJlIGZvcmNlZnVsbHkgcmVtb3Zl ZCBmaXJzdFxuIiwNCisgICAgICAgICAgICAgICAmcGRldi0+c2JkZik7DQorDQorICAgICAgICBt YXBfdmZzKHBkZXYsIDApOw0KKyAgICAgICAgbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlX3JldmVy c2UodmZfcGRldiwgdGVtcCwgJnBkZXYtPnZmX2xpc3QsIHZmX2xpc3QpDQorICAgICAgICB7DQor ICAgICAgICAgICAgcGNpX3JlbW92ZV9kZXZpY2UodmZfcGRldi0+c2JkZi5zZWcsIHZmX3BkZXYt PnNiZGYuYnVzLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZmX3BkZXYtPnNiZGYu ZGV2Zm4pOw0KKyAgICAgICAgfQ0KKyAgICB9DQorDQorICAgIHBvcyA9IHBkZXYtPnZwY2ktPnNy aW92LT5wb3M7DQorICAgIGlmICggIWhpZGUgKQ0KKyAgICB7DQorICAgICAgICBYVkZSRUUocGRl di0+dnBjaS0+c3Jpb3YpOw0KKyAgICAgICAgcmV0dXJuIDA7DQorICAgIH0NCisNCisgICAgcmMg PSB2cGNpX3JlbW92ZV9yZWdpc3RlcnMocGRldi0+dnBjaSwgcG9zICsgUENJX1NSSU9WX0NUUkws IDIpOw0KKyAgICBpZiAoIHJjICkNCisgICAgew0KKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIg IiVwZCAlcHA6IGZhaWwgdG8gcmVtb3ZlIFNSSU9WIGhhbmRsZXJzIHJjPSVkXG4iLA0KKyAgICAg ICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRmLCByYyk7DQorICAgICAgICBBU1NF UlRfVU5SRUFDSEFCTEUoKTsNCisgICAgICAgIHJldHVybiByYzsNCisgICAgfQ0KKyAgICBYVkZS RUUocGRldi0+dnBjaS0+c3Jpb3YpOw0KKw0KKyAgICAvKg0KKyAgICAgKiBVbnByaXZpbGVnZWQg ZG9tYWlucyBoYXZlIGEgZGVueSBieSBkZWZhdWx0IHJlZ2lzdGVyIGFjY2VzcyBwb2xpY3ksIG5v DQorICAgICAqIG5lZWQgdG8gYWRkIGFueSBmdXJ0aGVyIGhhbmRsZXJzIGZvciB0aGVtLg0KKyAg ICAgKi8NCisgICAgaWYgKCAhaXNfaGFyZHdhcmVfZG9tYWluKHBkZXYtPmRvbWFpbikgKQ0KKyAg ICAgICAgcmV0dXJuIDA7DQorDQorICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+dnBj aSwgdnBjaV9od19yZWFkMTYsIE5VTEwsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9z ICsgUENJX1NSSU9WX0NUUkwsIDIsIE5VTEwpOw0KKyAgICBpZiAoIHJjICkNCisgICAgICAgIHBy aW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiBmYWlsIHRvIGFkZCBTUklPViBjdHJsIGhhbmRsZXIg cmM9JWRcbiIsDQorICAgICAgICAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRldi0+c2JkZiwgcmMp Ow0KKw0KKyAgICByZXR1cm4gcmM7DQorfQ0KKw0KK1JFR0lTVEVSX1ZQQ0lfRVhUQ0FQKFNSSU9W LCBpbml0X3NyaW92LCBjbGVhbnVwX3NyaW92KTsNCisNCisvKg0KKyAqIExvY2FsIHZhcmlhYmxl czoNCisgKiBtb2RlOiBDDQorICogYy1maWxlLXN0eWxlOiAiQlNEIg0KKyAqIGMtYmFzaWMtb2Zm c2V0OiA0DQorICogdGFiLXdpZHRoOiA0DQorICogaW5kZW50LXRhYnMtbW9kZTogbmlsDQorICog RW5kOg0KKyAqLw0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jIGIveGVuL2Ry aXZlcnMvdnBjaS92cGNpLmMNCmluZGV4IDlhNDIyZjllYTAuLjc2N2ZlNWM2YzkgMTAwNjQ0DQot LS0gYS94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS92cGNp LmMNCkBAIC0yNyw2ICsyNyw3IEBADQogdm9pZCB2cGNpX3ZjcHVfaW5pdChzdHJ1Y3QgdmNwdSAq dikNCiB7DQogICAgIElOSVRfTElTVF9IRUFEKCZ2LT52cGNpLnRhc2tfcXVldWUpOw0KKyAgICB2 LT52cGNpLmRyb3BfdmZzX3BmLnNiZGYgPSB+MFU7DQogfQ0KIA0KICNpZmRlZiBDT05GSUdfSEFT X1ZQQ0lfR1VFU1RfU1VQUE9SVA0KQEAgLTQ4Niw2ICs0ODcsMTEgQEAgdWludDMyX3QgdnBjaV9y ZWFkKHBjaV9zYmRmX3Qgc2JkZiwgdW5zaWduZWQgaW50IHJlZywgdW5zaWduZWQgaW50IHNpemUp DQogICAgICAgICByZXR1cm4gZGF0YTsNCiAgICAgfQ0KIA0KKyAgICAvKiBBaGVhZCBvZiBhbnkg bG9jayBiZWluZyB0YWtlbiwgYXMgYWRkaW5nIGEgZGV2aWNlIGFjcXVpcmVzIHRoZW0uICovDQor ICAgIGlmICggdW5saWtlbHkoaXNfaGFyZHdhcmVfZG9tYWluKGQpICYmIHBjaV92Zl9zZXR1cF9w ZW5kaW5nKHNiZGYpKSAmJg0KKyAgICAgICAgICF2cGNpX3NyaW92X2FkZF92ZihzYmRmKSApDQor ICAgICAgICByZXR1cm4gZGF0YSAmICgweGZmZmZmZmZmVSA+PiAoMzIgLSA4ICogc2l6ZSkpOw0K Kw0KICAgICAvKg0KICAgICAgKiBGaW5kIHRoZSBQQ0kgZGV2IG1hdGNoaW5nIHRoZSBhZGRyZXNz LCB3aGljaCBmb3IgaHdkb20gYWxzbyByZXF1aXJlcw0KICAgICAgKiBjb25zdWx0aW5nIERvbVhF Ti4gIFBhc3N0aHJvdWdoIGV2ZXJ5dGhpbmcgdGhhdCdzIG5vdCB0cmFwcGVkLg0KQEAgLTYwNyw2 ICs2MTMsMTEgQEAgdm9pZCB2cGNpX3dyaXRlKHBjaV9zYmRmX3Qgc2JkZiwgdW5zaWduZWQgaW50 IHJlZywgdW5zaWduZWQgaW50IHNpemUsDQogICAgICAgICByZXR1cm47DQogICAgIH0NCiANCisg ICAgLyogQWhlYWQgb2YgYW55IGxvY2sgYmVpbmcgdGFrZW4sIGFzIGFkZGluZyBhIGRldmljZSBh Y3F1aXJlcyB0aGVtLiAqLw0KKyAgICBpZiAoIHVubGlrZWx5KGlzX2hhcmR3YXJlX2RvbWFpbihk KSAmJiBwY2lfdmZfc2V0dXBfcGVuZGluZyhzYmRmKSkgJiYNCisgICAgICAgICAhdnBjaV9zcmlv dl9hZGRfdmYoc2JkZikgKQ0KKyAgICAgICAgcmV0dXJuOw0KKw0KICAgICAvKg0KICAgICAgKiBG aW5kIHRoZSBQQ0kgZGV2IG1hdGNoaW5nIHRoZSBhZGRyZXNzLCB3aGljaCBmb3IgaHdkb20gYWxz byByZXF1aXJlcw0KICAgICAgKiBjb25zdWx0aW5nIERvbVhFTi4gIFBhc3N0aHJvdWdoIGV2ZXJ5 dGhpbmcgdGhhdCdzIG5vdCB0cmFwcGVkLg0KQEAgLTY4MCw2ICs2OTEsOSBAQCB2b2lkIHZwY2lf d3JpdGUocGNpX3NiZGZfdCBzYmRmLCB1bnNpZ25lZCBpbnQgcmVnLCB1bnNpZ25lZCBpbnQgc2l6 ZSwNCiAgICAgICAgIC8qIFRhaWxpbmcgZ2FwLCB3cml0ZSB0aGUgcmVtYWluaW5nLiAqLw0KICAg ICAgICAgdnBjaV93cml0ZV9odyhzYmRmLCByZWcgKyBkYXRhX29mZnNldCwgc2l6ZSAtIGRhdGFf b2Zmc2V0LA0KICAgICAgICAgICAgICAgICAgICAgICBkYXRhID4+IChkYXRhX29mZnNldCAqIDgp KTsNCisNCisgICAgLyogT25seSBvbmNlIGV2ZXJ5IGxvY2sgaGFzIGJlZW4gcmVsZWFzZWQsIGFz IHJlbW92YWwgYWNxdWlyZXMgdGhlbS4gKi8NCisgICAgdnBjaV9zcmlvdl9kcm9wX3ZmcygpOw0K IH0NCiANCiAvKiBIZWxwZXIgZnVuY3Rpb24gdG8gY2hlY2sgYW4gYWNjZXNzIHNpemUgYW5kIGFs aWdubWVudCBvbiB2cGNpIHNwYWNlLiAqLw0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9w Y2kuaCBiL3hlbi9pbmNsdWRlL3hlbi9wY2kuaA0KaW5kZXggYjdhMzUzNzFhNy4uYjkwMmM1ZTg4 OCAxMDA2NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9wY2kuaA0KKysrIGIveGVuL2luY2x1ZGUv eGVuL3BjaS5oDQpAQCAtMjI5LDYgKzIyOSw5IEBAIHZvaWQgc2V0dXBfaHdkb21fcGNpX2Rldmlj ZXMoc3RydWN0IGRvbWFpbiAqZCwNCiBpbnQgcGNpX3JlbGVhc2VfZGV2aWNlcyhzdHJ1Y3QgZG9t YWluICpkKTsNCiBpbnQgcGNpX2FkZF9zZWdtZW50KHUxNiBzZWcpOw0KIGNvbnN0IHVuc2lnbmVk IGxvbmcgKnBjaV9nZXRfcm9fbWFwKHUxNiBzZWcpOw0KK2ludCBwY2lfdmZfc2V0dXBfYmVnaW4o cGNpX3NiZGZfdCBzYmRmKTsNCit2b2lkIHBjaV92Zl9zZXR1cF9lbmQocGNpX3NiZGZfdCBzYmRm KTsNCitib29sIHBjaV92Zl9zZXR1cF9wZW5kaW5nKHBjaV9zYmRmX3Qgc2JkZik7DQogaW50IHBj aV9hZGRfZGV2aWNlKHUxNiBzZWcsIHU4IGJ1cywgdTggZGV2Zm4sDQogICAgICAgICAgICAgICAg ICAgIGNvbnN0IHN0cnVjdCBwY2lfZGV2X2luZm8gKmluZm8sIG5vZGVpZF90IG5vZGUpOw0KIGlu dCBwY2lfcmVtb3ZlX2RldmljZSh1MTYgc2VnLCB1OCBidXMsIHU4IGRldmZuKTsNCmRpZmYgLS1n aXQgYS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oIGIveGVuL2luY2x1ZGUveGVuL3ZwY2kuaA0KaW5k ZXggMjZhYTEyMDU4My4uZWVhZDk0ODdkMCAxMDA2NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi92 cGNpLmgNCisrKyBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCkBAIC00LDYgKzQsNyBAQA0KICNp ZmRlZiBDT05GSUdfSEFTX1ZQQ0kNCiANCiAjaW5jbHVkZSA8eGVuL3BjaS5oPg0KKyNpbmNsdWRl IDx4ZW4vdGltZS5oPg0KICNpbmNsdWRlIDx4ZW4vdHlwZXMuaD4NCiAjaW5jbHVkZSA8eGVuL2xp c3QuaD4NCiANCkBAIC04NCw3ICs4NSw2IEBAIHN0cnVjdCB2cGNpIHsNCiAgICAgICAgICAqIHVw b24gdG8ga25vdyB3aGV0aGVyIEJBUnMgYXJlIG1hcHBlZCBpbnRvIHRoZSBndWVzdCBwMm0uDQog ICAgICAgICAgKi8NCiAgICAgICAgIGJvb2wgYmFyc19tYXBwZWQgICAgICA6IDE7DQotICAgICAg ICAvKiBGSVhNRTogY3VycmVudGx5IHRoZXJlJ3Mgbm8gc3VwcG9ydCBmb3IgU1ItSU9WLiAqLw0K ICAgICB9IGhlYWRlcjsNCiANCiAgICAgLyogTVNJIGRhdGEuICovDQpAQCAtMTQ1LDYgKzE0NSwy MiBAQCBzdHJ1Y3QgdnBjaSB7DQogICAgICAgICB1bnNpZ25lZCBpbnQgbmJhcnM6MzsNCiAgICAg fSByZWJhcjsNCiANCisgICAgc3RydWN0IHZwY2lfc3Jpb3Ygew0KKyAgICAgICAgLyogUEYgb25s eSAqLw0KKyAgICAgICAgc3RydWN0IHZwY2lfYmFyIHZmX2JhcnNbUENJX1NSSU9WX05VTV9CQVJT XTsNCisgICAgICAgIC8qDQorICAgICAgICAgKiBXaGVuIHRoZSBWRnMgd2hpY2ggYXJlIGVuYWJs ZWQgYnV0IG5vdCBhZGRlZCB0byBYZW4geWV0IGFyZQ0KKyAgICAgICAgICogZ3VhcmFudGVlZCB0 byByZXNwb25kIHRvIGNvbmZpZyBzcGFjZSBhY2Nlc3Nlcy4gIFplcm8gaWYgdGhlcmUgYXJlDQor ICAgICAgICAgKiBub25lLg0KKyAgICAgICAgICovDQorICAgICAgICBzX3RpbWVfdCB2ZnNfcmVh ZHk7DQorICAgICAgICAvKiBSb3V0aW5nIElEIG9mZnNldCBvZiB0aGUgZmlyc3QgVkYsIGFuZCBz dHJpZGUgYmV0d2VlbiBWRnMuICovDQorICAgICAgICB1aW50MTZfdCBvZmZzZXQ7DQorICAgICAg ICB1aW50MTZfdCBzdHJpZGU7DQorICAgICAgICB1aW50MTZfdCBudW1fdmZzOw0KKyAgICAgICAg dW5zaWduZWQgaW50IHBvczsNCisgICAgfSAqc3Jpb3Y7DQorDQogI2lmZGVmIENPTkZJR19IQVNf VlBDSV9HVUVTVF9TVVBQT1JUDQogICAgIC8qIEd1ZXN0IFNCREYgb2YgdGhlIGRldmljZS4gKi8N CiAjZGVmaW5lIElOVkFMSURfR1VFU1RfU0JERiAoKHBjaV9zYmRmX3QpeyAuc2JkZiA9IH4wVSB9 KQ0KQEAgLTE2OSw2ICsxODUsMTIgQEAgc3RydWN0IHZwY2lfbWFwX3Rhc2sgew0KIA0KIHN0cnVj dCB2cGNpX3ZjcHUgew0KICAgICBzdHJ1Y3QgbGlzdF9oZWFkIHRhc2tfcXVldWU7DQorICAgIC8q DQorICAgICAqIFBGIHdob3NlIFZGcyBoYXZlIGJlZW4gZGlzYWJsZWQgYnkgdGhlIGNvbmZpZyBz cGFjZSB3cml0ZSBpbiBwcm9ncmVzcywNCisgICAgICogYW5kIHdoaWNoIFhlbiBoYXMgdG8gcmVt b3ZlIG9uY2UgdGhlIFBDSSBsb2NrcyBoYXZlIGJlZW4gZHJvcHBlZC4gIEFsbA0KKyAgICAgKiBv bmVzIHdoZW4gdGhlcmUgaXMgbm9uZS4NCisgICAgICovDQorICAgIHBjaV9zYmRmX3QgZHJvcF92 ZnNfcGY7DQogfTsNCiANCiB2b2lkIHZwY2lfZHVtcF9tc2kodm9pZCk7DQotLSANCjIuNTUuMA0K From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:19:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:19:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450678.1666106 (Exim 4.92) (envelope-from ) id 1xHMIT-0004Fh-Pd; Thu, 15 Oct 2026 14:19:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450678.1666106; Thu, 15 Oct 2026 14:19: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 1xHMIT-0004Fa-Mw; Thu, 15 Oct 2026 14:19:05 +0000 Received: by outflank-mailman (input) for mailman id 1450678; Thu, 15 Oct 2026 14:19:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHMIS-0004FS-LH for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:19:04 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHMIS-00000006jj5-3LuF for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:19:04 +0000 Received: from mail-lj1-f178.google.com ([209.85.208.178]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xHMIS-00000008rJY-0Dy6 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:19:04 +0000 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-3aaf078704fso13679021fa.1 for ; Thu, 15 Oct 2026 07:19: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" 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=EeJYuW89riBIU+1bWeO7R6JZCam/EWqrMuLTRwSHXqU=; b=xGqX1lccZeo+NVU5seEtytfcEf IWCQJk9eRyj2p+UReAatcp5XpeKR2VVR+DIPfPg85r5NKs3+qDEwtPQjDZNAYoEfzxLREvo1XJUcQ TX4s1JWJeZcScnhAlbJOJkEVxZQVlY+DkcmbIG/2w55lsCMBbk0WCnnnDFoUctRVJiRk=; X-Gm-Message-State: AFq9FYIsitsIgra6FJprfnjE37FTccsPMmXmOcHPT1XtXmCTNux0TxTk uSjSJpLtVVmLQQY7gDlhjFo6rxp0MR99V/YqW10Erdz3Q1OPkrsivcQqFzGuFePT0fCI69KJwCs JmJxP9PMYyDZrWNdD+l6grgtSXs/JTGk= X-Received: by 2002:a2e:bc28:0:b0:3a8:7ed3:fae9 with SMTP id 38308e7fff4ca-3ab147ea7c8mr347941fa.17.1792073943369; Thu, 15 Oct 2026 07:19:03 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-19-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Thu, 15 Oct 2026 15:18:50 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8iGFfXmV5q0BMKAS24IomRV2HSGaIDuGmS7Lqi_J7m3k3t2tSJE-P_fcg Message-ID: Subject: Re: [PATCH v3 18/18] x86/spec-ctrl: wire the sparse directmap view into the asi= option To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2026 at 8:21=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 07, 2026 at 11:40:51AM +0100, George Dunlap wrote: > > Let asi=3D choose which domains run on the sparse view of the directmap= , > > when the hypervisor is built with CONFIG_SPARSE_DIRECTMAP: > > > > * `asi` and `asi=3D` enable or disable the sparse view, along wi= th > > vCPU-PT, for every domain: HVM and PV guests, and the hardware > > domain, PV or PVH. HVM guests, a PVH hardware domain included, use > > the sparse view together with vCPU-PT, which gives them the mapcache > > it needs; PV guests all have one. A PV guest on the sparse view > > keeps its domain-wide mapcache and per-domain mappings: the sparse > > view separates it from other domains, not its vCPUs from each other. > > > > * `asi=3Dhvm=3D`, and new `asi=3Dpv=3D` and `asi=3Ddom0=3D= `, do > > the same for HVM or PV guests other than the hardware domain, or for > > the hardware domain, whatever its type: `asi=3D1,dom0=3D0` leaves th= e > > hardware domain out of ASI altogether. > > > > * A new `asi=3Ddirectmap=3D` selects the sparse view for all dom= ains, > > as `asi=3Dvcpu-pt=3D` selects vCPU-PT; `vcpu-pt=3D` alone leav= es the > > sparse view off. On a hypervisor built without > > CONFIG_SPARSE_DIRECTMAP the forms enabling all features leave the > > sparse view off, and `directmap=3D` is ignored with a warning. A gu= est > > type the build lacks is ignored, so that the sparse view is not buil= t > > for nothing. > > > > * Only one of XPTI and the sparse view are enabled. Enabled > > explicitly, for dom0, domUs or both, XPTI takes precedence: the PV > > domains it covers keep the full directmap, and the boot log says > > so. Left to its default, XPTI yields: it is disabled for the PV > > domains using the sparse view, with a boot-log warning where it > > would otherwise be enabled, as the sparse view does not replace it > > yet (it still maps the xenheap and Xen's stacks). Each domain's > > case is settled at its creation. > > > > The boot log gains a line with the directmap mode, "sparse" once a > > sparse view is configured and "full" otherwise, and the "ASI features > > for ..." lines, one for PV guests now among them, say which domains use > > the sparse view. > > > > Assisted-by: Claude Code:claude-opus-5-5 > > Signed-off-by: George Dunlap > > --- > > Changes in v3: > > - New in this version. > > --- > > docs/misc/xen-command-line.pandoc | 35 +++++- > > xen/arch/x86/include/asm/sparse-directmap.h | 28 ++++- > > xen/arch/x86/sparse-directmap.c | 4 +- > > xen/arch/x86/spec_ctrl.c | 130 ++++++++++++++++++-- > > 4 files changed, 171 insertions(+), 26 deletions(-) > > > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-= line.pandoc > > index 785e099c0a..0bbc8ebeff 100644 > > --- a/docs/misc/xen-command-line.pandoc > > +++ b/docs/misc/xen-command-line.pandoc > > @@ -203,7 +203,8 @@ to appropriate auditing by Xen. Argo is disabled b= y default. > > buggy or malicious other domain spamming the ring. > > > > ### asi (x86) > > -> `=3D List of [ , hvm=3D, vcpu-pt=3D | vcpu-pt=3Dhv= m=3D ]` > > +> `=3D List of [ , {pv,hvm,dom0}=3D, directmap=3D, > > +> vcpu-pt=3D | vcpu-pt=3Dhvm=3D ]` > > > > > Default: `false` > > > > @@ -214,12 +215,16 @@ mitigations for certain speculative related attac= ks, at the cost of mapping > > sensitive information on-demand. It might also offer some protection = against > > unmitigated speculation-related attacks. > > > > -The mechanisms currently implemented apply to HVM guests, including a = PVH > > -hardware domain. PV guests, including a PV hardware domain, are unaff= ected. > > +The mechanisms currently implemented are `vcpu-pt`, for HVM guests inc= luding > > +a PVH hardware domain, and `directmap`, for all guests including the h= ardware > > +domain, PV or PVH. The plain boolean enables or disables both, wherev= er they > > +apply. > > > > -* `hvm=3D` enables the features for HVM guests other than the hardware= domain, > > - which follows the whole-feature forms (the plain boolean, or an un-s= uffixed > > - `vcpu-pt=3D`). > > +* `pv=3D`, `hvm=3D` and `dom0=3D` enable the features for PV guests or= HVM guests > > + other than the hardware domain, or for the hardware domain, PV or PV= H. The > > + plain boolean does all three: `asi=3D1,dom0=3D0` leaves the hardware= domain > > + out. The forms naming no guest type (an un-suffixed `vcpu-pt=3D`, and > > + `directmap=3D`) cover the hardware domain too. > > Shouldn't this generic pv, hvm, dom0 set of values go in at the same > time that `hvm=3D` is defined? That would avoid having to re-write the > paragraph that's been added on this same series. OK. > > @@ -514,11 +570,29 @@ static int __init cf_check parse_asi(const char *= s) > > case 0: > > case 1: > > opt_vcpu_pt_hwdom =3D opt_vcpu_pt_hvm =3D val; > > + set_sparse_dmap(true, true, true, val); > > break; > > > > default: > > - if ( (val =3D parse_boolean("hvm", s, ss)) >=3D 0 ) > > + if ( (val =3D parse_boolean("pv", s, ss)) >=3D 0 ) > > + set_sparse_dmap(true, false, false, val); > > + else if ( (val =3D parse_boolean("hvm", s, ss)) >=3D 0 ) > > + { > > opt_vcpu_pt_hvm =3D val; > > + set_sparse_dmap(false, true, false, val); > > + } > > + else if ( (val =3D parse_boolean("dom0", s, ss)) >=3D 0 ) > > + { > > + opt_vcpu_pt_hwdom =3D val; > > + set_sparse_dmap(false, false, true, val); > > + } > > + else if ( (val =3D parse_boolean("directmap", s, ss)) >=3D= 0 ) > > + { > > + /* System-wide: every guest type, the hardware domain = too. */ > > + set_sparse_dmap(true, true, true, val); > > + asi_directmap_ignored =3D val && > > + !IS_ENABLED(CONFIG_SPARSE_DIRE= CTMAP); > > I think we should return error here, rather than print a warning: we > don't do this for any other command line option that's not parsed > because the required support has been compiled out. OK. Everything else I've either taken, or addressed elsewhere, I think. -George From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:57:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:57:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450756.1666173 (Exim 4.92) (envelope-from ) id 1xHMtK-0004Td-MU; Thu, 15 Oct 2026 14:57:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450756.1666173; Thu, 15 Oct 2026 14: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 1xHMtK-0004TW-IH; Thu, 15 Oct 2026 14:57:10 +0000 Received: by outflank-mailman (input) for mailman id 1450756; Thu, 15 Oct 2026 14:57:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHMtJ-0004TP-EN for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:57:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHMtI-00G4IH-RN for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:57:08 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0e9c4-e002-0a2a0a5209dd-0a2a4508c548-2 for ; Thu, 15 Oct 2026 16:57:08 +0200 Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0e9c4-f659-0a2a45080019-d155da29c92d-3 for ; Thu, 15 Oct 2026 16:57:08 +0200 Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-c3f8d72d7ceso106882966b.3 for ; Thu, 15 Oct 2026 07:57:08 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c3eda61fb26sm137336066b.69.2026.10.15.07.57.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 07: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=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=1792076228; x=1792681028; 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=IyUTAzmyclIG5Mnn77AVzYUDG8mdFz2EGhUHHeev15Q=; b=XV5HHLW3l36oCZk6KxiIzW5SPFtmiFLtunp+d5gIIla+24z9MTwoWf1dze4AbQdrDI GiEZc0UxDRVlEiymHzgs6N5eIShZ5QMMcA509l01pqmwumI+3keoKVdqoAPDY+MIlo77 n6Aw+NDF0QSqtgZb07/7mHBMUtoeAYgCFn5Ow72i3NOdJTXTCSsIhhWitAaXx8oNTUFe fVjnGdiUkuTnf/1ysxyqesRTQ8UJRt7BNucwfCehl72AZg3MLQ/SxqrwVITdywWxXV9U 1Dv/9wD79KPm3cezAfFIxnRVHiD6KvzSQLLZkIiC6SSrSzQKOuyYiKFYXKsusOZYZnP+ viQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792076228; x=1792681028; 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=IyUTAzmyclIG5Mnn77AVzYUDG8mdFz2EGhUHHeev15Q=; b=D830CYxedgHhjqXvR5C5b92TE/27Tfo+qJgGFx67Y5GzgHatiTudOFfI92+PkVwpYd 62JFvrUMZDyS77s5bZe1H19hZOxn2NFerAXyPlUVIxZ+UAIsoiP+rZIwf1feTTSwcRyY saxsAdcuzoua8GLFvilJVxg1S1nSHy4uBUc215M6ISYyva/JAiYOLbtnVtAjKMe3FVyj 2Y19S+MV0tVVhlZv0RvazUVGk8Xi9OQziYx7V4EnrYPrNbVV7lj1Z1biHXq83N4uzk38 OaAL7ua1M5ocDAH8zZIE8RmLzVXYlN34lUOAfDEcxPfVWSkSOwy0UDwqNTLc+y95iEGw c6bQ== X-Forwarded-Encrypted: i=1; AKwUvBzshutTRmqnTE9B7SWb/+5J881IhG0K7q6tT6eUEJpSVd45772mL3X5BGOeqKd2GQTgroM6DmaABpw=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ6uiw3aeSxCUdQjAXREUvg4jhvHIeM7RJeqJmCoaDLdqadmW4z 9cpz1G+T4Z2AO01Zr1OL1AO3e+RJh9Al2wTL/c8sus6ZKcz7zgLUsesO X-Gm-Gg: AYBFou1GshNTqyXm1YW3H7BZToaV06ZWmNTg1z3W8uz1r4HO2wfiVOi2cxfAP9ce69C rtv3zOgv+UgShjug4JieqSUWwCCtaftT2aC1/PgbSIWHIPe3AqQYX2BEgHLSRvD5IiyCLwtl46Q nW8wzTeMLD6tCp84eHO+4rF91yifWo2s+jNv1LlyOgPmV9Loz9djFfQj+KCVwCtUaH2UW1WcmoX eBWeL7GDbbXB54RJQ3lDv7e3DRFVWdFO7T6N++D2F31jCyn2JJp5XWl57yE1VnXLT2eD1mCadNp uTE7sdfgFfXztlRBJs4ouEj/MXPM1BPiE3iBAley8rXQItFW9d5+XKC9RfYok5m0Q3AVdMhpudC 81uMPCEfkjlUf72dqIAy1o/HKqk3fe4jMdsyN1o1FM3JmwaH6SjVxR5o49VN3bc9bg5mQ5YSeg4 USrirRUkuWSb2U3WRrYYseT2jTKByquLyT68vduGdnUv1oGygB/klMjkZh1YOdArrojNQfFtbyU nA1Z63cSiXwujnqQVg1I5y+bIHjOED8AHOrj3BcvtyV3Xc= X-Received: by 2002:a17:906:c107:b0:c16:4df6:176b with SMTP id a640c23a62f3a-c31a9d2fc30mr1966395866b.20.1792076228005; Thu, 15 Oct 2026 07:57:08 -0700 (PDT) Message-ID: Date: Thu, 15 Oct 2026 16:57:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v3 08/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: <6de1f79c-2e2b-4794-8eba-ad7ac224d24d@suse.com> Content-Language: en-US In-Reply-To: <6de1f79c-2e2b-4794-8eba-ad7ac224d24d@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1792076228-CEF5F87B-C055AC7C/10/73395122804 X-purgate-type: spam X-purgate-size: 19469 On 10/14/26 3:52 PM, Jan Beulich wrote: > On 30.09.2026 18:18, Oleksii Kurochko wrote: >> --- 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 >> @@ -58,6 +65,12 @@ >> #define APLIC_SOURCECFG_SM_EDGE_FALL 0x5 >> #define APLIC_SOURCECFG_SM_LEVEL_HIGH 0x6 >> #define APLIC_SOURCECFG_SM_LEVEL_LOW 0x7 >> +/* >> + * 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) > > You don't drop any bits here; that would happen at the use site of this > constant. The comment would better be worded accordingly. (The comment > a few lines up, for APLIC_DOMAINCFG_WMASK, is better in this regard.) Indeed. I'll reword it to describe the mask, as the comment for APLIC_DOMAINCFG_WMASK does: "The bits a write may change. All the other bits of sourcecfg[] are reserved and read as zero." > >> @@ -89,6 +102,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 direct delivery mode (domaincfg.DM = 0) */ >> +#define APLIC_TARGET_IPRIO GENMASK(7, 0) >> +#define APLIC_TARGET_IPRIO_DEFAULT 1U > > With this overlap of bits with EEID, should that one gain a similar > comment? Makes sense: GUEST_IDX and EIID exist only in MSI delivery mode, as IPRIO exists only in direct delivery mode, so I'll mark them with a similar comment. Also, these definitions aren't really related to what this patch introduces, so I'll move them, together with their use in aplic_init_hw_interrupts(), to a separate patch. > >> @@ -98,6 +114,24 @@ >> #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) > > As previously indicated (perhaps in other contexts): Pairs of masks and > shifts are almost always ambiguous. Hence why we have MASK_EXTR() and > MASK_INSR(), requiring only a mask: The shift value can be derived from > the mask. These aren't masks of fixed fields: where the group and hart indexes sit in the MSI address, and how wide they are, are runtime parameters (HHXS/LHXS/HHXW/LHXW in the spec's terms, taken here from the IMSIC DT node). What the macros call masks are right-aligned width masks, applied after the shift. To use MASK_EXTR(), a positioned mask would have to be built at runtime. Either width may be zero (a single group is the common case, and a single hart is possible), and then MASK_EXTR() would divide by zero, so every use would need a guard. IMO, it is fine to keep these macros as an exception. > >> --- 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,313 @@ 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.sources[irqn].target); >> +} > > I wonder whether in cases like this one, where you work with guest controlled > array indexes, you wouldn't be better off using array_{access,index}_nospec() > right away. Agree. In the next version I'll use array_index_nospec() here and in the other places in vaplic.c where a guest-controlled index is used after a bounds check: - AUTH_IRQ_BIT(), for the test_bit() on used_irqs[]; - generate_auth_mask(), for the used_irqs[] word picked by word_idx; - the target register write path, for sources[srcn]. It seems like array_access_nospec() doesn't fit here: it takes the bound from ARRAY_SIZE(), but used_irqs[] and sources[] are allocated per domain and bounded by nr_virqs. > >> +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_DOMAINCFG: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); > > In vaplic_emulate_load() you have this at function scope? Why do you do > it differently here, despite there being at least one more instance > later in the function? With this moved, the oddly placed (yet still > style conforming) figure braces also wouldn't be needed. Agree, there was no reason for that. In the next version vaplic is looked up once at function scope, as in vaplic_emulate_load(), so both inner instances are gone, and so are the braces of the APLIC_DOMAINCFG case. > >> + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | >> + (value & APLIC_DOMAINCFG_WMASK); >> + >> + return true; >> + } >> + >> + 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 ) >> + { >> + gdprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); >> + >> + 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 >> + * 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; >> + >> + break; >> + >> + 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_SETIPNUM: >> + case APLIC_CLRIPNUM: >> + case APLIC_SETIENUM: >> + case APLIC_CLRIENUM: >> + case APLIC_SETIPNUM_LE: >> + if ( !value || !AUTH_IRQ_BIT(currd, value) ) >> + return true; >> + >> + break; >> + >> + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + /* >> + * 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; >> + >> + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) >> + { >> + struct vaplic_source *src = &vaplic->regs.sources[srcn]; >> + struct vcpu *target_vcpu; >> + unsigned int guest_hart_idx = >> + MASK_EXTR(value, APLIC_TARGET_HART_IDX); >> + unsigned long flags; >> + struct vimsic_state *vimsic_state; >> + >> + 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; >> + } >> + >> + vimsic_state = target_vcpu->arch.vimsic_state; >> + >> + /* >> + * 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. >> + */ >> + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) >> + { >> + printk_once(XENLOG_WARNING >> + "%pd: vAPLIC target guest index != 0 is unsupported\n", >> + currd); >> + >> + return true; >> + } >> + >> + /* >> + * src->lock keeps the stored copy and the h/w register updated >> + * as a pair. >> + */ >> + spin_lock_irqsave(&src->lock, flags); >> + >> + write_atomic(&src->target, value); >> + >> + /* IRQs are already off under src->lock. */ >> + read_lock(&vimsic_state->vsfile_lock); >> + >> + /* >> + * The h/w register names the hart and the guest interrupt file >> + * MSIs are sent to, and there is none of either until the target >> + * vCPU is given a h/w guest interrupt file. The stored copy >> + * reaches the h/w at that point. >> + * >> + * TODO: once s/w guest interrupt files are supported, a vCPU using >> + * one still needs its MSIs, so the h/w register will have to be >> + * written for it too, pointing at an interrupt file Xen receives >> + * them in on the vCPU's behalf. >> + */ >> + if ( vimsic_state->vsfile_cpu != CPU_NONE ) >> + aplic_hw_write_reg(offset, >> + aplic_msi_target_gen(target_vcpu, value)); >> + >> + read_unlock(&vimsic_state->vsfile_lock); >> + >> + spin_unlock_irqrestore(&src->lock, flags); >> + >> + return true; >> + } >> + >> + /* printk_once(), as a guest could otherwise flood the log. */ >> + printk_once(XENLOG_WARNING >> + "%pd: vAPLIC direct delivery mode isn't supported\n", >> + currd); >> + >> + return true; >> + } >> + >> + default: >> + fail: >> + gdprintk(XENLOG_WARNING, >> + "Unhandled APLIC write at offset %#x (value %#x)\n", offset, >> + value); >> + >> + return false; >> + } >> + >> + aplic_hw_write_reg(offset, value); > > I continue to struggle with this passing through of writes (reads are > passed through as well, but at least those don't alter state). Aren't > different guests going to interfere with their writes to setip, clrip, > setie, clrie, and apparently also {set,clr}i{p,e}num? They shouldn't. setip, clrip, setie and clrie are write-1-to-set/clear registers: a 0 bit in the written value leaves the corresponding source untouched. Before the write is passed through, the value is masked with the sources assigned to the domain (generate_auth_mask()), so the bits of sources belonging to other domains or to Xen are written as 0 and aren't affected. {set,clr}i{p,e}num and setipnum_le take a single source number, and the write is dropped unless that source is assigned to the domain (AUTH_IRQ_BIT()). sourcecfg[] gets the same check, as it is a per-source register. domaincfg and target[] writes aren't passed through at all: domaincfg is emulated, and the h/w target[] gets a value built by Xen. This relies on a source never being assigned to more than one domain, or to both a domain and Xen, which route_irq_to_guest() refuses with: EBUSY. Interrupts are assigned only at domain construction, so the set doesn't change while the guest runs. And as virq == pirq, the bit (or number) a guest writes is also the h/w one, so no translation is needed. There is also no read-modify-write on Xen's side: a guest write is forwarded as a single 32-bit store, the only access the APLIC supports in its control region, and Xen doesn't read the h/w register first. For setip, in_clrip, setie, clrie and the *num registers, the spec defines what a write does only for the bits written as one (or for the single source named), regardless of the register's current value. So concurrent writes to the same register from Xen or from other guests, which always name disjoint sets of sources, all take effect, whatever order they reach the APLIC in. Xen's own APLIC driver only uses setienum/clrienum at runtime. I'll add a comment summarizing this above the aplic_hw_write_reg() call in vaplic_emulate_store(): + /* + * What is left is passed through to the h/w, which can affect only the + * sources assigned to currd: + * - setip, clrip, setie and clrie are write-1-to-set/clear, and the + * value was masked with currd's sources above, so the bits of the + * other sources are written as 0, which leaves them untouched; + * - {set,clr}i{p,e}num, setipnum_le and sourcecfg[] name one source, + * which was checked above to be assigned to currd. + * route_irq_to_guest() never assigns a source to more than one domain, + * or to both a domain and Xen, and as virq == pirq, no translation is + * needed either. + */ aplic_hw_write_reg(offset, value); > >> @@ -95,6 +403,56 @@ static const struct vintc_init_ops __initconstrel init_ops = { >> .make_domu_dt_node = vaplic_make_domu_dt_node, >> }; >> >> +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, >> + mmio_info_t *info) >> +{ >> + uint32_t val; >> + >> + ASSERT(v == current); >> + >> + if ( info->len != sizeof(uint32_t) || >> + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) >> + { >> + gdprintk(XENLOG_DEBUG, >> + "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n", >> + info->gpa, info->len); >> + return IO_ABORT; >> + } >> + >> + if ( !vaplic_emulate_load(v, info->gpa, &val) ) >> + return IO_ABORT; >> + >> + /* APLIC registers are 32-bit; zero-extend to the guest register width. */ >> + info->data = val; > > How do you know info->data has the size of registers as seen by guests? Plus, > how does this matter anyway? You reject info->len being other than 4, which > means the originating insn will necessarily have been a 4-byte load. What > happens to the upper bits (if there are any) depends on the behavior of the > insn that's being emulated, not on what you do here when storing into > info->data. You're right, the comment is wrong on both counts: info->data is register_t, so it has Xen's register width rather than the guest's, and it is the load emulation [1] which extends the value into the guest register, as the instruction requires (lw sign-extends, lwu zero-extends). I'll drop the comment. [1]: static int emulate_load(const struct guest_fault *gf) ... if ( !di.is_unsigned ) shift = BITS_PER_BYTE * (sizeof(info.data) - di.len); ... *guest_gpr(regs, &di) = (long)(info.data << shift) >> shift; ... And looking on that it would be more correctly to do in this way: shift = BITS_PER_BYTE * (sizeof(info.data) - di.len); ... if ( di.reg ) *guest_gpr(regs, &di) = di.is_unsigned ? (info.data << shift) >> shift : (long)(info.data << shift) >> shift; Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 15 14:59:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 14:59:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450763.1666180 (Exim 4.92) (envelope-from ) id 1xHMw2-0005Vj-5d; Thu, 15 Oct 2026 14:59:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450763.1666180; Thu, 15 Oct 2026 14:59: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 1xHMw2-0005Vc-32; Thu, 15 Oct 2026 14:59:58 +0000 Received: by outflank-mailman (input) for mailman id 1450763; Thu, 15 Oct 2026 14:59:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHMw0-0005VU-AJ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 14:59:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHMvz-005PDA-G0 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:59:55 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0ea6b-8faa-0a2a0a5109dd-0a2a45069dae-0 for ; Thu, 15 Oct 2026 16:59:55 +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 6ad0ea6b-195a-0a2a45060019-d155d033e488-3 for ; Thu, 15 Oct 2026 16:59:55 +0200 Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6b2237b596cso1811187a12.0 for ; Thu, 15 Oct 2026 07:59:55 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6b203863cb0sm2590512a12.17.2026.10.15.07.59.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 07:59: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=1792076395; x=1792681195; 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=XiC6iKf8InCNIMdR3pbpvRu5cEG3BqEmjDO3duO5XaE=; b=O/FSwEuDy6wwIWqdWvOYID/LMg+RpzmWQQTEYtyd4RH3ZcxNGrUguDQwdzMSpcywXE GkuX0zDHNhBNgcVN5Mc2r6LJ+XHPbwH/T60TC1OFyVS/Lec49yYxCtQX2dGOsoAHeY9f feMczWlNhB9q2TLC6OSC4X3jT1kBYyH431rrpUvVq1UZ5puaey831Xe2k0JtDqOwo8Ld DNVHAsNhZSguq/4ld+rESxs53ugPEX0hAki7EbuxNibyq6VmtxBbShoEtv8kv1HuS2KM F1bmbOLQflW+VBkP1UTVTsvWJkwVH3VYWTGWfJVkLxgvX70VYoHTI/AAFhEEJEPDf6DY INWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792076395; x=1792681195; 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=XiC6iKf8InCNIMdR3pbpvRu5cEG3BqEmjDO3duO5XaE=; b=g+pa80g9PkvWqwLSP8f7tHp0v87HyzZc81BjKrmhNqCSDg8//ziP4WQLZFKLcDyBYp 9Cg1lsJFv+VX2wXre4z39P7s7i3RGWwz66GYKjOU52+NXy1DF8ATCylaMS1AQCTHyk9w /u+ZHmSMDa86pomgvJY5ej63gubuLt9On6xkCuqkrWTbhMhhxtuv3LbLWS0ZsyxZXK6w kb0S/IHSzpzuR2Rw40wg2u5mZzbkwYmKG59RE1VI49kSY+dWQmntnYsWB4z3EHoYOgfr Uw7tBMfSfOk8MpEeRD5i3bdhdG9JiWkIIKrkx3C/OVCOUUqVbOdUIaf5co5+nFU9g9yx SgJQ== X-Gm-Message-State: AFq9FYI6HV+r57mlwsgwyFSc2HIkfJZlZV8ZTGEhQD8G0Mz5xo704lVG VYh7JfdH6WN8Ikl7+Zx9//JuwJddNNkdrFAL0SLdcMsXcz7t3wwNi4n8Thfv4w== X-Gm-Gg: AYBFou22r7rTkIXLmu701rIxFdlcZAvsFCcNDUzEPLP88mnk/p3K/FAxmBEnuOuPV+I KzlOAB2AWg6zZNjcePHzlQcq22vNhHFetQK8FsUH//VkIVV8hZKDmhgkF0wOOlNJj4W5jlkQMc9 QEuXcESK1EfTp5rwodiCXyp6RraA9/BU0uxwzJ0OGAqGYFRlrkJasas6vyAl6HNzTAk7QU3Chfg UcIhWzDY6+NuU9KHYW1iSeCDcJ5M/vie9/823jU4XauJ/SZmq1u1gd1/fuIJksBM3WI8hcK7yt6 /5zVgMIwIBEBjNRQUctSxYwz1UKHiLk50A8/b8AoO9YeS9BN9oHNLxyOXlJi6+LJLqO2UirLsqa t4tkzgLKymbBU4vhwxTVsV5nVpJnTdireGKXkYp3U0al3mklt8lCK8rjrtkjQ0fIhlkucuYxLWi TC/kS2/u0yes7RwxGF+NSmCC1lu0d5BqWrHNRy4GtiVHzd3I7ckzwMXopUlgaG12ePDDX7oJ5pQ q/6vUk8VbxPpfUr/fYhg05Sz3Nf0PdCUSF0euiLTDlMv5o= X-Received: by 2002:a05:6402:a0d6:b0:6ac:b861:dab3 with SMTP id 4fb4d7f45d1cf-6b17c296bf6mr14561014a12.39.1792076394815; Thu, 15 Oct 2026 07:59:54 -0700 (PDT) Message-ID: <9943b1f4-1890-4917-ae39-bf9c70fc36c7@gmail.com> Date: Thu, 15 Oct 2026 16:59:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 24/39] xen/riscv: add guest load emulation for trapped MMIO accesses 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: 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-16d1c6/1792076395-1F6C877B-5594F23E/10/73395122804 X-purgate-type: spam X-purgate-size: 3200 On 9/30/26 6:23 PM, Oleksii Kurochko wrote: > 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. This part of commit message should be updated. Suggestion look below... > > 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 > --- [...] > static int emulate_load(const struct guest_fault *gf) > { > - /* Transient, until the helpers gain their users. */ > - (void)advance_pc; > - (void)guest_xlen; > - (void)guest_gpr; > - (void)insn_fetch_faulted; > - (void)decode_ldst_insn; > + struct cpu_user_regs *regs = gf->regs; > + mmio_info_t info = { .is_write = false }; > + struct decoded_insn di = {}; > + unsigned int shift = 0; > + int rc; > > - return -EOPNOTSUPP; > + /* 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(info.data) - di.len); > + > +#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. */ > + if ( di.reg ) > + *guest_gpr(regs, &di) = (long)(info.data << shift) >> shift; It would be more correct to have here: shift = BITS_PER_BYTE * (sizeof(info.data) - di.len); ... if ( di.reg ) *guest_gpr(regs, &di) = di.is_unsigned ? (info.data << shift) >> shift : (long)(info.data << shift) >> shift; and update the commit message part "Sign extension is done here…" to: Sign and zero extension are done here rather than in the handlers: a shift pair drops whatever lies above the access width in the value read and, for a signed load, sign-extends it, so a handler need only report the value it read. > + > + advance_pc(regs, di.insn_len); > + > + return 0; > } > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 15 15:05:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 15:05:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450776.1666191 (Exim 4.92) (envelope-from ) id 1xHN1c-0007KZ-Qb; Thu, 15 Oct 2026 15:05:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450776.1666191; Thu, 15 Oct 2026 15:05: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 1xHN1c-0007KS-LZ; Thu, 15 Oct 2026 15:05:44 +0000 Received: by outflank-mailman (input) for mailman id 1450776; Thu, 15 Oct 2026 15:05:43 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHN1b-0007KM-5F for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:05:43 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHN1a-00000006kpo-46Qa; Thu, 15 Oct 2026 15:05:42 +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.98.2) (envelope-from ) id 1xHN1Z-0000000ACri-46Jz; Thu, 15 Oct 2026 15:05: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:References:Message-ID:Subject:Cc:To:From:Date; bh=ekoeJp+Wvaix5G2pnhGBd8qXUrBUo9EXrfXRdQwy/tM=; b=lvxfBU7NUoF/KANRwWYTZXW0Cb InXoBzm3TvYb21nr5SxcG9KvIaiXPDTaL+Zxz56WJhyn8oJ+A/RSncaAchQsEZISMQPory+KTD0V8 cZe75IC9GUklzX8hqKGK3KGZjw0vMSVg1D7h/VCGFXp3FaSxFf9XuKdgVJDa/1ZX0I9Y=; Date: Thu, 15 Oct 2026 17:05: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 08/15] x86/PVH: split pvh_setup_acpi() Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <791be732-4c7d-417a-8557-4f82ef62d0c0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <791be732-4c7d-417a-8557-4f82ef62d0c0@suse.com> On Wed, Oct 14, 2026 at 11:42:57AM +0200, Jan Beulich wrote: > On 14.10.2026 11:31, Roger Pau Monné wrote: > > On Tue, Oct 13, 2026 at 06:04:37PM +0200, Jan Beulich wrote: > >> On 13.10.2026 17:52, Roger Pau Monné wrote: > >>> On Mon, Oct 12, 2026 at 10:23:16AM +0200, Jan Beulich wrote: > >>>> All E820 manipulations want to happen before the initrd is placed, or else > >>>> pvh_steal_ram() may steal from the tail part of it. As a second step, > >>>> split placing ACPI data from actually populating it. > >>> > >>> Would it be less intrusive to duplicate the memory map (like it's done > >>> in a change ahead of this one), and subtract the kernel and initrd > >>> region from that memory map, then use it as the basis for > >>> pvh_steal_ram()? > >>> > >>> We could adjust/replace pvh_add_mem_range() so it allows changing > >>> regions from RAM to other types. That would seem to be less churn > >>> overall. Maybe you did already consider this and found further > >>> problem with this approach that I'm failing to see? > >> > >> No, I didn't try that route. In fact despite the order now this patch > >> (and maybe also the VMX one) pre-dates the E820-copying one. The one > >> aspect I consider problematic with the suggested alternative is that > >> then two E820 maps need updating: The one with kernel (not sure about > >> initrd; see below) subtracted out, and the one we actually mean to hand > >> to Dom0. > >> > >> As to overall churn: I'm not sure which one would cause less. Certainly > >> the patch here would remain largely unaltered, as the splitting is > >> going to be necessary no matter what. > > > > I'm possibly missing something, but the splitting won't be strictly > > necessary? > > > > We could do: > > > > * Populate p2m > > * Place kernel > > * Place ACPI (also VMX metadata) > > * Place initrd > > The goal is to directly map the initrd. That direct-mapping (or at least > the determination of where it is to go) needs to happen before populating > the (rest of) the P2M (as otherwise this would populate the respective > part of the P2M). Else we'll continue to see the problem that Marek > reported. That is: Bah, yes, sorry, I keep forgetting we must not populate the initrd region because we are directly mapping it. I find it tedious to have to first do all the allocations and then do a second call to actually copy the data, but alas, I don't see another way to deal with this. > * Place kernel > * Place ACPI (maybe VMX metadata) > * Place initrd (possibly direct-mapping it) > * Populate P2M > * Load kernel and initrd > * Fill ACPI (maybe VMX metadata) > > (Of course the order of the latter two items doesn't matter much.) > > Even if we didn't direct-map the initrd along with placing it, we'd > still need to tell populate_p2m() to skip that region. I.e. the split > between placing and loading/filling would remain. Hm, yes, the placement of the initrd blocks populating the p2m, and cannot be decided until we have positioned the ACPI stuff. I would really like to find a way to avoid this split, but I don't think it's possible. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 15 15:20:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 15:20:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450792.1666198 (Exim 4.92) (envelope-from ) id 1xHNFp-0002fL-Tv; Thu, 15 Oct 2026 15:20:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450792.1666198; Thu, 15 Oct 2026 15:20: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 1xHNFp-0002fE-R1; Thu, 15 Oct 2026 15:20:25 +0000 Received: by outflank-mailman (input) for mailman id 1450792; Thu, 15 Oct 2026 15:20:24 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHNFo-0002f7-PE for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:20:24 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHNFo-00000006l7u-3MVF; Thu, 15 Oct 2026 15:20: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.98.2) (envelope-from ) id 1xHNFn-0000000AbdR-3RYE; Thu, 15 Oct 2026 15:20: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=y/oqXhE54M41mqvopAsQBnP4IiyOrRxKOdKllmlqVYA=; b=fudTACOPFWENbsQ4HEVLkD4NoS /XlnGBT9tyvzLBkldU1HBeLEF17MNH+Xthe0dnRou60vSvGiBy0dFQL0cKVCStaXq6VEZ8KztDKNR jC9qcmQK/1sO6lI1gl8/Mo1cecCoUgjWR+j2MEaT3yucM2VyYbB4lNODlYDbT7FVlkkg=; Date: Thu, 15 Oct 2026 17:20:21 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 10/15] x86/PVH: convert find_memory() to using a rangeset Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Oct 12, 2026 at 10:24:44AM +0200, Jan Beulich wrote: > Subsequently we will need to exclude a 2nd range here. To avoid > complicating the logic when it needs to cover two ranges, follow the > suggestion left in a code comment and convert to using a rangeset. > > Suggested-by: Xenia Ragiadakou > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > The Suggested-by: is based on the respective commit's S-o-b. I didn't go > hunt for whether this may have been suggested in review of that patch. > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -518,14 +518,38 @@ static int __init pvh_populate_p2m( > #undef MB1_PAGES > } > > +struct mem_info { > + size_t size; > + paddr_t addr; > +}; > + > +static int cf_check __init _find_memory( I don't really like underscore prefixed functions, I would rather name this check_memory_range() or similar. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 15 15:32:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 15:32:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450805.1666207 (Exim 4.92) (envelope-from ) id 1xHNQy-0004pe-S9; Thu, 15 Oct 2026 15:31:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450805.1666207; Thu, 15 Oct 2026 15:31: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 1xHNQy-0004pX-PT; Thu, 15 Oct 2026 15:31:56 +0000 Received: by outflank-mailman (input) for mailman id 1450805; Thu, 15 Oct 2026 15:31:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHNQx-0004pR-S7 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:31:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHNQx-00GAH8-8q for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 17:31:55 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0f1e2-2eae-0a2a0a5409dd-0a2a4504c170-22 for ; Thu, 15 Oct 2026 17:31:55 +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 6ad0f1ea-b57f-0a2a45040019-d155dd2cc842-3 for ; Thu, 15 Oct 2026 17:31:55 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48c4d870d54so3497853f8f.2 for ; Thu, 15 Oct 2026 08:31:55 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0ac35dfsm19513354f8f.33.2026.10.15.08.31.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 08: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=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=1792078314; x=1792683114; 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=1eQDPE7EhU4VZ2xnN6vN0Gt79m18qjKFua1mtTyLiYo=; b=eKpOHsSS+SJieTD5NfQbje2G4FKQE1pY0omjfhC55xxwsEOpqtQLjOyJK4wF5SQSm8 7WacmKYWRJeBQfvlCIFE2t5rRJ6Yy0i72nx0gXSZdpe3D4aqYvUHE6MSXCKr0/OZi/ZP JwKA3nUnr41Behq8hxRoKvZpDvTj4lQOAj4NKZmp6ZKUZejAtEXB8I7/kIlw2Q7By9kj l1anf+r5S0jldj81RrXECyynwPqOAyzBOQ3pAdzeWIwd+teDZQAyQIf9I7zMfi2kjByH iFBLADeGm3erdIykhBRFOw79QwRTzWqg3jY7mCxN2Hd94HJJAbj9Mpy80PqbBunViq6M 0eFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792078314; x=1792683114; 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=1eQDPE7EhU4VZ2xnN6vN0Gt79m18qjKFua1mtTyLiYo=; b=yjH6QlxYnNimyv/sMWAuT4YtkPCvwiJ++fAOZFnB4X3lJDtzxHaOsnHBUh/4SzRcE5 TAaMg6LkRpJ1fZLXnIKJJ33UDUkcHh9fJWjxjZVo3NCGrUehiBGdMvBoZElFhXpZ4zP9 Hj+k7m/1qKGrpkglBjX7juQqafr5DTIOR/mjsiukioaxBwF5JcFS0a3hOJ8mRMPyKQlZ Gjy4KLvexDacIm6+Py1ebUn8L+g1iyDKNwABSxe8AMJdlL0/+qTGsUVurs8riUlmQUew 81TkrOGgfoULH96wlREzz9bXKfeYUnqCZNRKgo028MFgE3WUfmJpvHt/hEPFySqZ7zgh PihA== X-Forwarded-Encrypted: i=1; AKwUvBziGlSyLsBqSigHVDBB+gs9fssRDdqqVudtT3285xExFwq5/f2Kh67+CqDrWoaAgYuLpgxaV3t7iqw=@lists.xenproject.org X-Gm-Message-State: AFq9FYIk88niA5uzJV6lj2/b1+h+KDJK4SEwg/P+VROMzzZg4RAZ4J/T dMb/0dsihyZFqTWnHG2eD+Sa5rIU0b9RYY6c9mTJtxreGYXcHDipaUlI X-Gm-Gg: AYBFou2X+Bt9rq1S3g5uKdducPBDBy8h3DzSl0zsyjjEVEBn5SV7MqeH5Lit0P7304D IbTQnQq4zmJ4NXzam7Aby2kvRhhO/cgEwuTaTQCb6Yws7yR8+yX7OKtKkCPp1MKljSawgLpmc07 MULfmnm+jUlbrPHRbpCpQLN0kfQZmRFcyOKWYMyqzfXljlHmrGdht1Dv6mUOW4qNixqpHWd8NTO GpeAKP+5wXrUj+ADjZjo28fk+w/2moX+8/76Bnz8Zhk04jTW0arBdOP/bmAepq/EKMDdb11dSnP K7uOU0LW8RysFr4WElRcRxfTOpFhMm1Excfq98L9OdA1hGuM6HmJprgPwlf02F7Vpoyxj8oTBii KC3f7g7k2pPRxmslYOUvHuhi9/OvhsAAprQVJsQk4c5u6OmC0eTt+3pUAGBnJytVCWpQaseD4p5 TRdDd7stMyRuGQxYUDuwpHBAm197NGyBKUdzjhgVBHLsq4w7fT7FqIFgXSI4M2V1xnHuxuJX1RA 1dSLVW3I/hzLeu3sQ0v9Wm92EtHPCD5mt2dz/RbiCgVlX0= X-Received: by 2002:adf:e80b:0:b0:487:342:d141 with SMTP id ffacd0b85a97d-48dbaae8b8dmr28314688f8f.23.1792078314205; Thu, 15 Oct 2026 08:31:54 -0700 (PDT) Message-ID: <7b8838fc-3ff7-4628-8353-d21f418870d7@gmail.com> Date: Thu, 15 Oct 2026 17:31:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Jan Beulich , Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1792078315-C06DAB50-F63EB562/10/73395122804 X-purgate-type: spam X-purgate-size: 4812 On 10/15/26 10:41 AM, Jan Beulich wrote: > On 15.10.2026 10:28, Baptiste Le Duc wrote: >> On 2026-10-15 09:14 +0200, Jan Beulich wrote: >>> On 14.10.2026 18:45, Baptiste Le Duc wrote: >>>> On 2026-10-14 11:09:58+02:00, Jan Beulich wrote: >>>>> On 14.10.2026 11:00, Baptiste Le Duc wrote: >>>>> >>>>> In which case it would need to be >>>>> >>>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) || >>>>> !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) >>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>> >>>>> albeit I have to admit that permitting two contradicting extensions to >>>>> be exposed at the same time is irritating. >>>>> >>>>>> I see two ways to address this: >>>>>> >>>>>> 1) Keep checking Svade: >>>>>> >>>>>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) >>>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>>> >>>>>> After resolve_ad_scheme(), the Svade bit is set in every case where >>>>>> software has to preset the A/D bits. The only imprecise case is both >>>>>> extensions advertised with hardware updating already enabled by >>>>>> firmware, where presetting A/D is unnecessary but harmless. >>>>>> >>>>>> 2) Record the probe result in a global, e.g. >>>>>> >>>>>> static bool __ro_after_init hw_ad_update; >>>>>> >>>>>> and use: >>>>>> >>>>>> if ( !hw_ad_update ) >>>>>> e->pte |= PTE_ACCESSED | PTE_DIRTY; >>>>>> >>>>>> This is exact in all cases, at the cost of a new global that mostly >>>>>> duplicates what resolve_ad_scheme() already records in the ISA bitmap. >>>>>> >>>>>> I discussed with Oleksii and we are fine with either. What do you prefer? >>>>> >>>>> As to 1), see above. For 2), while maybe okay, I think we're better off >>>> Sorry, I don't fully follow the issue with 1). Compared to what you proposed, >>>> it only differs when neither Svade nor Svadu is recorded, which cannot >>>> happen as resolve_ad_scheme() runs before and always records one of the >>>> two. >>> >>> Yet previously we said that recording extensions (as such, i.e. later also >>> possibly exposing them to guests) when they weren't really advertised may >>> not be the right thing to do. I.e. imo the probing may be used to drive >> But we also said that platforms (such as the P550) may implement an >> extension without advertising it, as a RISC-V spec maintainer >> confirmed in [1]. >> >> [1] https://github.com/riscv/riscv-isa-manual/issues/3450#issuecomment-6076851535 > > What Andrew says there suggests to me that the behavior you observe on P550 What was mentioned in [1]: ``` Implementations that trap when A/D bits are not set do implement Svade, whether or not they explicitly say they do. ``` Sounds like a default behavior for our case and so Svade should be taken as a default. > is against the spec. That shouldn't really be the case though, as nothing > was said in the spec at all until Svade and Svadu were actually introduced. Actually, earlier versions of the Privileged ISA specification (e.g., v1.11 and v1.12) already explicitly described both behaviors: "Two schemes to manage the A and D bits are permitted: 1. 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. 2. When a virtual page is accessed and the A bit is clear, or is written and the D bit is clear, the implementation sets the corresponding bit(s) in the PTE. The PTE update must be atomic with respect to other accesses to the PTE, and must atomically check that the PTE is valid and grants sufficient permissions. Updates of the A bit may be performed as a result of speculation, but updates to the D bit must be exact..." What is now formalized as Svade corresponds to the first scheme (software management via page faults), while the second scheme (hardware-managed updates) became Svadu. ~ Oleksii > An update to the spec should imo never invalidate previously conforming > implementations. I guess I'll comment there. > >>> Xen's internal behavior, but I'm unconvinced that it should also lead to >>> marking extensions as available. >> >> Therefore, as far as I understood, you're not convinced of this: >> >> /* Neither advertised: trust the probe. */ >> __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, >> riscv_isa); >> >> If so, then, the only solution I have in mind in what I proposed in 2) >> with the global variable that store the result of the real probe. >> Am I correct? > > Possibly. What I'm missing is some clarification towards the underlying > principle which we want to follow not just here. > > Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 15:39:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 15:39:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450825.1666217 (Exim 4.92) (envelope-from ) id 1xHNXk-0006Ep-J3; Thu, 15 Oct 2026 15:38:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450825.1666217; Thu, 15 Oct 2026 15: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 1xHNXk-0006Ei-Fb; Thu, 15 Oct 2026 15:38:56 +0000 Received: by outflank-mailman (input) for mailman id 1450825; Thu, 15 Oct 2026 15:38:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHNXj-0006Ec-W9 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 15:38:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHNXj-00GBAt-Co for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 17:38:55 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0f368-8faa-0a2a0a5109dd-0a2a4501ab98-48 for ; Thu, 15 Oct 2026 17:38:55 +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 6ad0f38f-5984-0a2a45010019-d155dd29b0ef-3 for ; Thu, 15 Oct 2026 17:38:55 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48af4d4e61fso4016567f8f.2 for ; Thu, 15 Oct 2026 08:38:55 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0ac37acsm19609478f8f.34.2026.10.15.08.38.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 08:38: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=1792078735; x=1792683535; 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=5YK+AV1+2er6wAJ1yus0fSXYosno6BmC+IECP3KD/yQ=; b=mbuEuVP8XqXXDite00SCaOHrHCaiSoLYnCfUW2FKeMb3qUYgIF8NdDl3XlP9bxWxsr MOpbHMjeHXoEWB1g6LeM8AmiwoFAxR/ra6/rnyGtwTTiZ6OI0d8T+eZAipSp9Nvzn3bK 4O+RfkfnEnhG5JP+ZDi6y+7IxMgg2f1N5AFC/D03IYwbxZS/L5p3LPwZ7QrzvbGyZ+gn J7f4ZQowa5rJRVGhkpWDZPlUybFSqhtHjdUyg8cYp1UZtwxobAqBd0qNNDpgImv3NWnU 0rRexy8Rylczn1u82QIgGRzVIsZMnQsMLL9UmRofJz7pgDIYmFDomyqea67/AF/Ry8Wa USuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792078735; x=1792683535; 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=5YK+AV1+2er6wAJ1yus0fSXYosno6BmC+IECP3KD/yQ=; b=E9P7aOK/Bzve3FPi8Qy1Fpda/5y5to5rFhdVGh2KzRW6TcjmtW3oQdK+XEfIKE+RZq 8/KJ2YHjl9UxQo7clmds3R+g8GhTvXnrcjuRlRaK1khKaC7U/cJkfaG2/wOM2lmhCDmp imJoW1KVL9IaclFYgBDf8B0ZSD1+cHF/vmNHMWDjmxfUdUAQSyFUZ4j7tlu1E+lsT1aX sNYXWfZqyeY8+LWnnQT6oWx9OIir1AD5G9wZEq3qmnz7CasY+G3rcCiT8pST1wdtTfp/ FrorXGzMnb/4Y8t4KLskazHSkiM97zLREeizjWmHs3V3AtvKtwE2z1Z57jemSl7++MMf UPWw== X-Forwarded-Encrypted: i=1; AKwUvBz0m1rtHKZ9TRqXeXE6F1sgXWXQMioRuOrQNf6NF7FrKOXNaoLJb4E1LhIFAcj5lP7Ny+akRgJEFqU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKfF80Bm1861ljqgKBUjF08ssQxrhpOgf7Qd+2ukBjG7CkCJKSb wj3ZiA9Czz5OO8lO0nCA372OjaB7KurjU2A5/hhFbkPWQ5F284LZLvTI X-Gm-Gg: AYBFou0MDEoQjiB2Toqfl6ISbsmBoXQGpGJks73/WjMJjwvt0m5t+QmNmV9ejtSFXac iV+9VyXGEdkgeVbG9Zp3K2wPf3HEZF81NJTkqx3T/7pPm9T5Dfjf47I2jB0wewfqxw/RoNWPND7 qwy45MzVhCFVUD7Hdu65Ch0GuCOdJX/fAQVIftZcHpnqeTXBDLl3U0/XVDjTxaY+X4XYIn1UkGZ DkY/8pnDDvI7y4D95Wy2hqGseVvAGvDopIOjZpVjLHzzzIUZYZxySJKmYePV52hhSneNNzbsHxN Wo01kCJe3v7SoH0yEZOLvRv2FPu93lgUzlrhqSc0yHqejGsR5X3ENKE1zuQqxwDYdnw/j9ODris SYwbKk4AiwGcAfTeMgAgsufWb4NIe6CfZ9Y5QjItYVG3DVYycCAAiJV5xVBHu2WjmMs5362jJEH X5J3ljXc2A8NdyfbvLAkvkHiHhcD7kHyJN3cozBD5FqGTjxkEVN2+2UllxRfXYVoK13QPcYqzKu Dwgfqm3UIFJ51MuWdWO7gA/YvaX3JeFKiXmVx1OUNLs/v2BYKU9p+eewg== X-Received: by 2002:a05:6000:490a:b0:48c:490a:336b with SMTP id ffacd0b85a97d-48dba7bea0bmr37781681f8f.5.1792078734720; Thu, 15 Oct 2026 08:38:54 -0700 (PDT) Message-ID: <81ad5bb7-2300-4ac2-a999-adbb39270ddf@gmail.com> Date: Thu, 15 Oct 2026 17:38:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Jan Beulich , Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1792078735-1DA7E757-017BC4FB/10/73395122804 X-purgate-type: spam X-purgate-size: 1377 On 10/15/26 10:41 AM, Jan Beulich wrote: >>> Xen's internal behavior, but I'm unconvinced that it should also lead to >>> marking extensions as available. Could we use the probe mechanism solely to verify that the A/D bits behavior configured by the firmware matches what is advertised in the DTS? In other words, rather than automatically setting the corresponding bit in riscv_isa here ... >> Therefore, as far as I understood, you're not convinced of this: >> >> /* Neither advertised: trust the probe. */ >> __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, >> riscv_isa); >> ... based on the probe result when neither extension is advertised, we could require riscv,isa to explicitly advertise the appropriate extension. If the probe result contradicts what is advertised in the DTS, we would fail to boot and print a message asking the user to update riscv,isa accordingly. Then it seems we could cover all the cases we have and potentially will have. Am I missing something? >> If so, then, the only solution I have in mind in what I proposed in 2) >> with the global variable that store the result of the real probe. >> Am I correct? > Possibly. What I'm missing is some clarification towards the underlying > principle which we want to follow not just here. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 15 16:04:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 16:04:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450852.1666225 (Exim 4.92) (envelope-from ) id 1xHNwL-0004CH-Ho; Thu, 15 Oct 2026 16:04:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450852.1666225; Thu, 15 Oct 2026 16:04: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 1xHNwL-0004CA-FD; Thu, 15 Oct 2026 16:04:21 +0000 Received: by outflank-mailman (input) for mailman id 1450852; Thu, 15 Oct 2026 16:04:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHNwK-0004C4-CX for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:04:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHNwJ-00GFY2-PR for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 18:04:19 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0f965-bab6-0a2a0a5309dd-0a2a4505da7e-46 for ; Thu, 15 Oct 2026 18:04:19 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0f983-4cb1-0a2a45050019-d1558031cc81-3 for ; Thu, 15 Oct 2026 18:04:19 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a1ad2e2391so23885645e9.0 for ; Thu, 15 Oct 2026 09:04: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-4a1bd993caesm158643695e9.12.2026.10.15.09.04.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 09:04: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:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1792080259; x=1792685059; 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=+jyMiZ1GGN0rRgnNxkmGjWG6cimbc3Tb4W+2v5Mpeh8=; b=ROExlOLEXqC08c1QO5LUNzYkIYMXMbFfQ5y/3dwg2Rz57XxLW/VIO8kgfJh9vhbjKd gmauO953fD0rsUt71PteDsYk9JUJPt+M9u1brge9eoIfYmglZUMMZiwf5sMJ2i52ciVa tfF2vHt29UOXfPq8CyVgIc+/5Ci7WVOgUvinyp702pFEotcY48KB/ChGEwekxdPl4xaV GbwI8u6wLemOBZQ27Zi7fe1eT83nIQDQaVSQbQBzH1MCMPMXikiFo7HNTiifkyLJ3YFF HkgftqpmdYMn4IdLrsAveNpIL22loJYOtONQZYf2mncwnkWFjsPSN1sWr1+orXRCZgOR DNxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792080259; x=1792685059; 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=+jyMiZ1GGN0rRgnNxkmGjWG6cimbc3Tb4W+2v5Mpeh8=; b=ikkFAX0ZCRjqRs5DXfp5ub/1++rUCtXC+nGLdWNFMkO//eSzfR49/NQkucqOuaMN0c 9I4//1RH1OgimcGjbRFz48m4HBo4in7CiVdrQjhh5G/nchkwzk89xq/QLX30qKpAzsBc aZ7rxXJJGMecxTOfn6vAjWWJXzUJ5tB835ZqoP9Nsv2H0kaUNphEzTLLZS4YaqYHdRv0 t3X4bW2/S4WmlE+GPKrFMYfKztBTTy01EOQm4/xbuyE8ImJtqfSSWA32Pu4eqG91WLPr VZTgAQAPp5SdDgvOT6TGAj5x2EgmIZ6KXBaK+QCDE49pm81s0C9BioyVivIbhHh91aen GBfw== X-Forwarded-Encrypted: i=1; AKwUvBz93I/dMkfqenwVuqExd9qh6Su4rUiSaL1c7Glr4I9DSflAxygUAc+n0W2HvmCzg5PhZ0tOC24md44=@lists.xenproject.org X-Gm-Message-State: AFq9FYKYqU2g5qINSLifxp9d0HHIEpC5F2jeQMHV3Jhv7MRyUXd0RZ8x DcJqF/X0sVRSzfHEjk3egFPAXjEf7/Z7fl/gZAUnQ1SFp0Yz/fVr4ipAmqI5pWojyw== X-Gm-Gg: AYBFou3IltlYi4I4rrl4yvphouGFuSuH+1WycJv9wE3RXsrjd9r1+Tx1OhZuRKgT3yh oqjVZgyOCHMBme+00nIBVrxDb8I+KmPyNIq3wNH9rcXTqIhxQQRiUKYvyJsn+hwCkuvdK3HoQRP +wsMUDqq0fxWAvXeQ1RkD/2satzexrCuas7wuegoc++6vf5SPvPxwtw/nKR+Iiz6EerNbAJh9Eu 9FRY+WLgeDUmpWYEqL8pHDnOQ5Vsb54L6ARQ2XqPndc0CNQ9S6JljHwtDO4uYzxdPBPPeubQQhv HrQsnyiw26dctwtHfKSouqjhETnA4E14/4LM1fZ+Rf/0DwGuxu/OyzDQptoeQxeT7pWJuaODvTT JBdxLyzTKK7P0MYDHzKXcEBRVhOncSBE00PyZ1tjMWpfS81NPNkGnXGPy0fOf5ul9BYQcyUtu3J RsV1D+xSQBwD3mIrRcPStyhGR0DlAbOtw7z9b+OTF2U3Rlh+nLHV8Dg3kF1qM/+kJsEESnvE7H5 ZmO7M8hfFcR7OZ5ZxfpiXPlmhCQAaFbUY5OxvoWcFh0qr4ZrvmBXM+tMLpeDOc= X-Received: by 2002:a05:600c:c104:b0:4a1:96cd:2f67 with SMTP id 5b1f17b1804b1-4a196cd3240mr247982915e9.4.1792080259039; Thu, 15 Oct 2026 09:04:19 -0700 (PDT) Message-ID: <2f04c46d-f533-4eda-9bd1-8b8e100dff07@suse.com> Date: Thu, 15 Oct 2026 18:04:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Oleksii Kurochko Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> <81ad5bb7-2300-4ac2-a999-adbb39270ddf@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: <81ad5bb7-2300-4ac2-a999-adbb39270ddf@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1792080259-2551A2A1-9A9416E5/10/78276251493 X-purgate-type: spam X-purgate-size: 1172 On 15.10.2026 17:38, Oleksii Kurochko wrote: > On 10/15/26 10:41 AM, Jan Beulich wrote: >>>> Xen's internal behavior, but I'm unconvinced that it should also lead to >>>> marking extensions as available. > > Could we use the probe mechanism solely to verify that the A/D bits > behavior configured by the firmware matches what is advertised in the DTS? > > In other words, rather than automatically setting the corresponding bit > in riscv_isa here ... > > >>> Therefore, as far as I understood, you're not convinced of this: >>> >>> /* Neither advertised: trust the probe. */ >>> __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, >>> riscv_isa); >>> > > ... based on the probe result when neither extension is advertised, we > could require riscv,isa to explicitly advertise the appropriate > extension. If the probe result contradicts what is advertised in the > DTS, we would fail to boot and print a message asking the user to update > riscv,isa accordingly. That's what I suggested earlier, yet from replies I concluded it wouldn't be overly practical to have people edit DTs. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 16:04:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 16:04:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450855.1666235 (Exim 4.92) (envelope-from ) id 1xHNwu-0004cH-QN; Thu, 15 Oct 2026 16:04:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450855.1666235; Thu, 15 Oct 2026 16:04: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 1xHNwu-0004cA-NT; Thu, 15 Oct 2026 16:04:56 +0000 Received: by outflank-mailman (input) for mailman id 1450855; Thu, 15 Oct 2026 16:04:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHNws-0004WS-PZ for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:04:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHNws-003D8c-6B for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 18:04:54 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0f993-8faa-0a2a0a5109dd-0a2a4507c7ee-48 for ; Thu, 15 Oct 2026 18:04:53 +0200 Received: from [40.93.198.37] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0f9a3-b4ea-0a2a45070019-285dc625e33a-3 for ; Thu, 15 Oct 2026 18:04:53 +0200 Received: from BN0PR02CA0045.namprd02.prod.outlook.com (2603:10b6:408:e5::20) by PH0PR12MB7957.namprd12.prod.outlook.com (2603:10b6:510:281::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.24; Thu, 15 Oct 2026 16:04:47 +0000 Received: from BN2PEPF000044A0.namprd02.prod.outlook.com (2603:10b6:408:e5:cafe::82) by BN0PR02CA0045.outlook.office365.com (2603:10b6:408:e5::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Thu, 15 Oct 2026 16:04:47 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF000044A0.mail.protection.outlook.com (10.167.243.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Thu, 15 Oct 2026 16:04:47 +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.53; Thu, 15 Oct 2026 11:04: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.53; Thu, 15 Oct 2026 11:04:40 -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.53 via Frontend Transport; Thu, 15 Oct 2026 11:04: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=mpkyoIgagnXO+xx8CbsUT9+VmSWYoccOpF2ZiGG/lgHQnTGl/IZ7JUjS7K0YWeFpmipRra/v9N6+vSqiHVEeqeclkxrItYRdYTSOaA3s320lM5I5pBwWatbepAw3FXXVdTiuG5zlFAdISArD42H/p7hPrR1BhcKRIqd5CZr/fq15PuJBqIBDrrXs3n5nBybuBujW+t6O6OHuAZZ4nr3TxMZzLaI/4/aaqzCI7eBy7p8d8YMQYJ8Qah5G2aJIFuwshguvhFOVhCsR1yEyltu1o3FyTCjF3NLefnGwe4ZwfnN2dHzzIME0RKG393o42NXLhCABmqdf7rYWEQi3msYSlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XSTYvoS03r3SaiH65lY16MmrQOMD5bDUHrwKoefGOAU=; b=t2RqsX0ehH5AhVneuTjFy3LWgJEKkrYYeHApN+29g7PsZJ3u4goxPfFs1QTXE89XNquQBolJpN46HN0dTtANXAtDnbIT39B8mfLyQgmv34LSMpnSymu5dfT2BYUrk2s75oNdUaDZUAG2bdz/5M5+lBBu+nOtI2dMbB54a2Lp6rs4Gg6gucQEQhyTnVsFtyDMxEo16rv+H5faBquaM6miGZtsT8Ke9GKzrhDCkXWbupoD68j9eJm+cZfQkYerCakpIh+oswx9M4jyU8NpPuaHIzOLSOqbPRDsBiL+gpz1s+flByUoKunszLINMooQPY/CTor2KZuPq8qMAzupOSKpFg== 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=XSTYvoS03r3SaiH65lY16MmrQOMD5bDUHrwKoefGOAU=; b=BvFeIg+I5OrwUbkemDvuvp+wPr01+nEGZAbhxQKGWldu5waErE1XBdyNSfkgdHFp39D81eSOg2m7weh4sS36aWyjKfTnV+V1P0W9D2snyca4u58pHxGjUkOQKEf5avWeW906vQqTyjxVYJ8XMDm/xFVvGdbzme48KvIjBM6QF/U= 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: <960380be-818d-4699-b273-1fd7ebf0d11a@amd.com> Date: Thu, 15 Oct 2026 10:33:10 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] SUPPORT.md: State that ATS is unsupported To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , References: <20261014135143.34220-1-jason.andryuk@amd.com> <20261014135143.34220-3-jason.andryuk@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A0:EE_|PH0PR12MB7957:EE_ X-MS-Office365-Filtering-Correlation-Id: 70e4fbb9-3bb5-41c4-dd46-08df2ad608f2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|82310400026|1800799024|376014|10067099003|22082099003|18002099003|11063799006|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: knnllsfMXSCjX7oT9xT0nE4jhYeFr4XFey/3AfRUCDMWhuTQ6dtDfpp9z6OmNJPusMV5oVCbGqmTyOrYGGnhPx6TvOO6BKNymLFmUoj2KqkS5XgAET/16v7cFYFFh70W5uvZBWZM4RlfTZL7FoiuFruB7Sf/pNoKy9xtnkQ0GB6QEWL3x5ttvOVbKRLLCYHYYKSs+Op179pgstaTraCoucZ4XXVGlm48QkZo4kl93bi34ZHWT5yKdKci4mIqCh+ATyA01S6uGJHeyVFO1GfYz/zjZjQGRNgb47juTvJp8VOGKcyPt2hqemlnVClq1j987kQKFLczFWBh/TV0uK/sA05Mq0pIXqAzHcd0SLQp68K3h0jjWDfENZnTm64MW2zaWttmm0Cz/io4MePqq8a7f/N5uPCs+Gp/8mfClIugd/3DvwIvG1rPD8YjvhW+HKAn21FHb0MSqPruouOd1vF6rAqvnJXQrfU0ADmipWusiD/U4gTd6gF7GacxDM8ILt0j2UL0nKaSUSoC0qHd9dKx6lkkz5nT8OYPlQoOcPyfpiqDADscPasA2+9/MFQusihClTB0w8yGAgzOmzqDXyw2oK0JEflfSyzy/TWtalVMako6jmVOh4xssbU1e6vO1AEWIWiybiZjTLKmV/lxhKk1Vzs79lSmrN4poRL77v+ANbL+4kxRk1s1rinpkoj4JjEGQFVwPS99wvkr1h4aUsUDqg== 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)(82310400026)(1800799024)(376014)(10067099003)(22082099003)(18002099003)(11063799006)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: rKKyBa08Ctspcdg6/H4Zy7zI34FbmgYu2gw1IJ7OwV3tzjST9ZsyxfAemjqeVDPpmaDV/JOiopNo0Xk1hXHYxGl9pK8vtCHccI2DHmh25ws9oANNwffZ9pSTVcJkaamhrAfQQL1s+8kb2CymYUQOcFKqU1rDwl6sQn7miY/64Di8oQR7WNP3aEr7Em+BPejxOmUj5cLkVKrtzzdce6bLDZ4VSCuBXtZ+CVYkDIORz0ia/l/ZvL0B7GU5OFKjGMIEYTj9dqWgqsuiH5JPKdxdwxN3xmWaSROuT61GOWOiUQH93yXhXmkgqCqPj8kpx8wYzpzjOMMDWPDQR28uvVkU+tO4k68rhb6lZYIdfj+2CB8Hm1fHjolLdGZtyb1WYdw0v3ASj+nSo0oM4I0+l16kQtq8HR4n2JiySr8rgZL23F+MqEQcXIS47JlaBp8NWwbk X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 16:04:47.0989 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 70e4fbb9-3bb5-41c4-dd46-08df2ad608f2 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: BN2PEPF000044A0.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7957 X-purgate-ID: tlsNG-ef75cf/1792080293-374D3AE4-A1E80954/0/0 X-purgate-type: clean X-purgate-size: 745 On 2026-10-15 08:33, Jan Beulich wrote: > On 14.10.2026 15:51, Jason Andryuk wrote: >> --- a/SUPPORT.md >> +++ b/SUPPORT.md >> @@ -96,6 +96,9 @@ For the Cortex A77 r0p0 - r1p0, see Errata 1508412. >> Status, ARM SMMUv3: Tech Preview >> Status, Renesas IPMMU-VMSA: Supported, not security supported >> >> +PCI Address Translation Services (ATS), enabled by the ats= command line >> +option, is not security supported. >> + >> ### ARM/GICv3 >> >> GICv3 is an interrupt controller specification designed by Arm. > > Wouldn't this better go in the "x86/PCI Device Passthrough" section? I guess I thought of ATS as more of an IOMMU feature, but PCI is in the name. I'm happy to move it. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Thu Oct 15 16:22:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 16:22:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450889.1666244 (Exim 4.92) (envelope-from ) id 1xHODm-00010w-55; Thu, 15 Oct 2026 16:22:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450889.1666244; Thu, 15 Oct 2026 16:22: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 1xHODm-00010p-1r; Thu, 15 Oct 2026 16:22:22 +0000 Received: by outflank-mailman (input) for mailman id 1450889; Thu, 15 Oct 2026 16:22:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHODk-00010j-AV for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:22:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHODe-008cAN-ND for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 18:22:19 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad0fda4-e002-0a2a0a5209dd-0a2a4508d1d6-16 for ; Thu, 15 Oct 2026 18:22:14 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad0fdb5-f659-0a2a45080019-d15580acc8c7-3 for ; Thu, 15 Oct 2026 18:22:14 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8b0a28a720aso39767907b3.2 for ; Thu, 15 Oct 2026 09: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=google header.d=linaro.org header.i="@linaro.org" 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=1792081333; cv=none; d=google.com; s=arc-20260327; b=F1SgXT0EV7HM4ZukGqn8rOJ5qAzCcA11b1NeZMcQqw6qdmBeHHzYTcdEDQY7IahplP SwsFhpfXc3FpUDDvogGqXJegNRUx+P6AxKGyRqSxed7TnuADrg1zY1rp1Q0oVv1vCuMf N8DDIcnWFG+etHmYjlv02uiOYOJXm4MR0sARjv5Zms5Oz66Jc9GvLqTzPoA/n6FVqn8/ 2RbL7SQssmCHD9PuMixLcMbAm2xklDHLCcOf0gjnsnqfdcrLna0xQhZuQlJfyK0R4t/U BBbgZazVO4XuD3+gYP/1u8qUCTwNiLMcrWKsKsb81VtyG3lRZu3eUL6dEG/RfP+1Hjxt Y4xQ== 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=RQCElvh08J2BIDGN/zLgW6mGnyFT83qmeWNSYL2QSEU=; fh=GzccUDtmqNWNivxHxZY4MK4APLJJkH1THRT6PTh85Is=; b=KaIFWVVhYSRU8LJ7MgvnRT3Tz7A1ESmyZ5gRPi87S8W97dOkEv11sakkcQwB8GVUBB 5SeIAQ/hUsww5tQHX+5Fk7F3nUQDWbHreycTpfYiiyGfBZOHKY7YnU49qLgSWkm8oexP Ep4eKHz1Az6lx3WTfrV2kyxk3XPkiFDnsl268/e1lF2U5d2Rq4FUrL+S1Gf5uwy6NwOl GvTY5TXv+bjoWvkhKM93+0xKUQ8POmipS0z+JyPEaus5QsPLCo4WnVZ0i0UXmKZeXrsO nL5InK2bO8uqnwzBO39Ov/2qxv1O4IYLFjMSgb780u1e2XDKQOAyNCPJDsNosBuMvX8j ks3A==; 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=1792081333; x=1792686133; 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=RQCElvh08J2BIDGN/zLgW6mGnyFT83qmeWNSYL2QSEU=; b=UtuzWqn0QMOEWzSsRA6t9rSuKOzBwXlw5jkX7tajFinz9iwMdcsIdmHFk4+ochjYr3 pY8Xk1f8rkWB+gUtzpMxQ0iUnLa2zgEJE6Fr24APHcbz/EmWO3p1Bw+knaO3Thk1i4W6 Lz2jUTcHeWco8w31jljiCq3ZprRJle2Pb0VQx73MlicTY0ZaSvjJPT9tZUhbyHC3ch01 Gx4KPMtn1opVIYdOJqDRtyOnm505HdSjDy3w3Pafot7bF6f21ckvFxnlrfvPFdgfVdXY rXDNqNgURZRaZJKer1KoOsQcSMYEUEacIoq6b1AkPrR1lSsxkI7Vbe5xAOdcAfpIzqyc BHEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792081333; x=1792686133; 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=RQCElvh08J2BIDGN/zLgW6mGnyFT83qmeWNSYL2QSEU=; b=dDcZC8rCaIvREqRxO5kC2HTi1vCm3EbjQcxugmrwcjqAFh+tNxhsyi3yKYgeGY5PWw qLoVrWtzya9lFuwhLDYOhzs3/Z3zcoimQc4DpPXp2/Q4crnCzc1o8K0mCmzIO41zXzJ7 OefkUFwy6IYREX9P8HZ8u7Dffk/YiD+7znihm0O3SoEdVgoCOJg1FlyKydaFFdevBSoD MvnZITqpyywOJUdSrmbrbCoAM4tczUWD8ytA4lfUhGN09Vo7RvWplq7KJUQ2DxUtvwIu DOYDmwhbjBw/jJ4VrBpUY7M58CO1SEuaGd4z9OOZU7DHyPz8lR+45Vy9O9iHsEBeBYf4 v9KA== X-Forwarded-Encrypted: i=1; AKwUvBzC+7cNayxIrfdUFpMISLwIxdJ3j/wqIXUV6xNTwa6bJfp5/QPfF8L6orYPfcqAl57l7FCfEPWtjSA=@lists.xenproject.org X-Gm-Message-State: AFq9FYKxbaPsjsVXhVEjiENvhq39bO7NXj6UkoywO8aHXblUOb2q0O/G /8jaRs9G0vn/RjeezWGIU4EgUJvKMZN5HitlB/3AZYgOxDQiSxBN4wSMr5p+QiVSy5GYrjaC+ml L/1H9Df380KfDYyQVYaPjHivWM3RvwtSJNfQyCeS2Nw== X-Gm-Gg: AYBFou3WZXAnlGA+z8qFJSyZRokrBbQlrwiThdFKcEzK5276obDReCQxYzsbGLnKBjm 6iPHaYs2HmWgxih3IrI8BSZaXou8Zvu0jbVlyU6TIievFbkwGbXQ4FvO2MseTfrviyOkUdlSAx/ mxqLr7q2QpJ97Z3uF1fxjxuPdvEf4Zbc8DYYo0X4WIIfltWLeIHnExkpqmKn7NM/pO/agWBsTUW 7bLmZS4iRYPmE0lDapm4oRkAlL3AOzx2oE8CqZnIaZAjAQXJ8eV/SgM8z8gIcXCVjqR0BqaCHS+ KAGERZZww76OMR+jO+9autbQkcrwMztJTf8CrNTMrBKGy7OZCEba6iUQxluZLmR7eO+C09dKezH yI8ssp1NuUsy8Ws/Bfz2UqId+WWU9/EHsO+Qz4OA= X-Received: by 2002:a05:690c:387:b0:8b0:6866:c55f with SMTP id 00721157ae682-8b07ee4d12emr67505727b3.46.1792081332932; Thu, 15 Oct 2026 09:22:12 -0700 (PDT) MIME-Version: 1.0 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-6-mark.caveayland@nutanix.com> In-Reply-To: From: Peter Maydell Date: Thu, 15 Oct 2026 17:22:00 +0100 X-Gm-Features: AclHuK_JzHSeeixZQwFB55O2lE4YIMCEsFBYUzo_EwttzyD7LQh3FodmT7dI1cQ Message-ID: Subject: Re: [PATCH 05/22] i8259.c: move parent_realize from PICClass to I8259CommonClass To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c1860d/1792081334-D7B5987B-ED14495F/0/0 X-purgate-type: clean X-purgate-size: 7695 On Tue, 13 Oct 2026 at 16:54, Peter Maydell wrote: > > On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland > wrote: > > > > 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 > > This is one of those things where I think we're not 100% consistent > about whether we think the parent_realize field should go in the > child class struct or the parent class struct. The name "parent_realize" > implies it ought to be in the child struct, though, and I think we > do that more often than we put it in the parent class. We do, although it's a bit closer than I thought: about 50 callsites put the parent_realize pointer in the child class struct; about 25 put it in the parent class struct. So I think for new code we should prefer to follow the child-class-struct version. in child's class: hw/arm/smmu-common.c: device_class_set_parent_realize(dc, smmu_base_realize, hw/arm/smmuv3.c: device_class_set_parent_realize(dc, smmu_realize, hw/display/macfb.c: device_class_set_parent_realize(dc, macfb_nubus_realize, hw/i386/kvm/i8254.c: device_class_set_parent_realize(dc, kvm_pit_realizefn, hw/i386/kvm/i8259.c: device_class_set_parent_realize(dc, kvm_pic_realize, &kpc->parent_realize); hw/input/adb-kbd.c: device_class_set_parent_realize(dc, adb_kbd_realizefn, hw/input/adb-mouse.c: device_class_set_parent_realize(dc, adb_mouse_realizefn, hw/intc/arm_gic.c: device_class_set_parent_realize(dc, arm_gic_realize, &agc->parent_realize); hw/intc/arm_gic_kvm.c: device_class_set_parent_realize(dc, kvm_arm_gic_realize, hw/intc/arm_gicv3.c: device_class_set_parent_realize(dc, arm_gic_realize, &agc->parent_realize); hw/intc/arm_gicv3_hvf.c: device_class_set_parent_realize(dc, hvf_gicv3_realize, hw/intc/arm_gicv3_kvm.c: device_class_set_parent_realize(dc, kvm_arm_gicv3_realize, hw/intc/arm_gicv3_whpx.c: device_class_set_parent_realize(dc, whpx_gicv3_realize, hw/intc/arm_gicv5.c: device_class_set_parent_realize(dc, gicv5_realize, &gc->parent_realize); hw/intc/i8259.c: device_class_set_parent_realize(dc, pic_realize, &k->parent_realize); hw/intc/loongarch_dintc.c: device_class_set_parent_realize(dc, loongarch_dintc_realize, hw/intc/loongarch_extioi.c: device_class_set_parent_realize(dc, loongarch_extioi_realize, hw/intc/loongarch_extioi_common.c: device_class_set_parent_realize(dc, loongarch_extioi_common_realize, hw/intc/loongarch_ipi.c: device_class_set_parent_realize(dc, loongarch_ipi_realize, hw/intc/loongarch_pch_pic.c: device_class_set_parent_realize(dc, loongarch_pic_realize, hw/intc/loongarch_pic_common.c: device_class_set_parent_realize(dc, loongarch_pic_common_realize, hw/intc/loongson_ipi.c: device_class_set_parent_realize(dc, loongson_ipi_realize, hw/intc/loongson_ipi_common.c: device_class_set_parent_realize(dc, loongson_ipi_common_realize, hw/intc/pnv_xive.c: device_class_set_parent_realize(dc, pnv_xive_realize, &pxc->parent_realize); hw/intc/pnv_xive2.c: device_class_set_parent_realize(dc, pnv_xive2_realize, hw/intc/spapr_xive.c: device_class_set_parent_realize(dc, spapr_xive_realize, hw/intc/xics_pnv.c: device_class_set_parent_realize(dc, pnv_icp_realize, hw/intc/s390_flic_kvm.c: device_class_set_parent_realize(dc, kvm_s390_flic_realize, hw/nubus/nubus-virtio-mmio.c: device_class_set_parent_realize(dc, nubus_virtio_mmio_realize, hw/timer/i8254.c: device_class_set_parent_realize(dc, pit_realizefn, &pc->parent_realize); hw/virtio/virtio-pci.c: device_class_set_parent_realize(dc, virtio_pci_dc_realize, target/alpha/cpu.c: device_class_set_parent_realize(dc, alpha_cpu_realizefn, target/arm/cpu.c: device_class_set_parent_realize(dc, arm_cpu_realizefn, target/avr/cpu.c: device_class_set_parent_realize(dc, avr_cpu_realizefn, &mcc->parent_realize); target/hexagon/cpu.c: device_class_set_parent_realize(dc, hexagon_cpu_realize, target/hppa/cpu.c: device_class_set_parent_realize(dc, hppa_cpu_realizefn, target/i386/cpu.c: device_class_set_parent_realize(dc, x86_cpu_realizefn, target/loongarch/cpu.c: device_class_set_parent_realize(dc, loongarch_cpu_realizefn, target/m68k/cpu.c: device_class_set_parent_realize(dc, m68k_cpu_realizefn, target/microblaze/cpu.c: device_class_set_parent_realize(dc, mb_cpu_realizefn, target/mips/cpu.c: device_class_set_parent_realize(dc, mips_cpu_realizefn, target/or1k/cpu.c: device_class_set_parent_realize(dc, openrisc_cpu_realizefn, target/ppc/cpu_init.c: device_class_set_parent_realize(dc, ppc_cpu_realize, target/riscv/cpu.c: device_class_set_parent_realize(dc, riscv_cpu_realize, target/rx/cpu.c: device_class_set_parent_realize(dc, rx_cpu_realize, target/s390x/cpu.c: device_class_set_parent_realize(dc, s390_cpu_realizefn, target/sh4/cpu.c: device_class_set_parent_realize(dc, superh_cpu_realizefn, target/sparc/cpu.c: device_class_set_parent_realize(dc, sparc_cpu_realizefn, target/tricore/cpu.c: device_class_set_parent_realize(dc, tricore_cpu_realizefn, target/xtensa/cpu.c: device_class_set_parent_realize(dc, xtensa_cpu_realizefn, in parent's class: hw/input/lasips2.c: device_class_set_parent_realize(dc, lasips2_kbd_port_realize, hw/input/lasips2.c: device_class_set_parent_realize(dc, lasips2_mouse_port_realize, hw/input/pl050.c: device_class_set_parent_realize(dc, pl050_kbd_realize, hw/input/pl050.c: device_class_set_parent_realize(dc, pl050_mouse_realize, hw/intc/xics_spapr.c: device_class_set_parent_realize(dc, ics_spapr_realize, hw/isa/pc87312.c: device_class_set_parent_realize(dc, pc87312_realize, hw/isa/vt82c686.c: device_class_set_parent_realize(dc, via_superio_realize, hw/pci-bridge/cxl_root_port.c: device_class_set_parent_realize(dc, cxl_rp_realize, &rpc->parent_realize); hw/pci-bridge/gen_pcie_root_port.c: device_class_set_parent_realize(dc, gen_rp_realize, &rpc->parent_realize); hw/pci-host/pnv_phb.c: device_class_set_parent_realize(dc, pnv_phb_root_port_realize, hw/pci-host/pnv_phb3_msi.c: device_class_set_parent_realize(dc, phb3_msi_realize, hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power8_realize, hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power9_realize, hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power10_realize, hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power11_realize, hw/ppc/pnv_lpc.c: device_class_set_parent_realize(dc, pnv_lpc_power8_realize, hw/ppc/pnv_lpc.c: device_class_set_parent_realize(dc, pnv_lpc_power9_realize, hw/s390x/tod-kvm.c: device_class_set_parent_realize(DEVICE_CLASS(oc), kvm_s390_tod_realize, hw/virtio/vhost-user-gpio.c: device_class_set_parent_realize(dc, vgpio_realize, hw/virtio/vhost-user-i2c.c: device_class_set_parent_realize(dc, vi2c_realize, hw/virtio/vhost-user-input.c: device_class_set_parent_realize(dc, vinput_realize, hw/virtio/vhost-user-rng.c: device_class_set_parent_realize(dc, vu_rng_base_realize, hw/virtio/vhost-user-rtc.c: device_class_set_parent_realize(dc, vu_rtc_base_realize, hw/virtio/vhost-user-snd.c: device_class_set_parent_realize(dc, vu_snd_base_realize, hw/virtio/vhost-user-spi.c: device_class_set_parent_realize(dc, vspi_realize, thanks -- PMM From xen-devel-bounces@lists.xenproject.org Thu Oct 15 16:32:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 16:32:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450911.1666252 (Exim 4.92) (envelope-from ) id 1xHONN-0004Qz-33; Thu, 15 Oct 2026 16:32:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450911.1666252; Thu, 15 Oct 2026 16:32: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 1xHONM-0004Qs-WF; Thu, 15 Oct 2026 16:32:17 +0000 Received: by outflank-mailman (input) for mailman id 1450911; Thu, 15 Oct 2026 16:32:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHONM-0004Qm-HN for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:32:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHONM-00000006mrm-2SBx; Thu, 15 Oct 2026 16:32: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.98.2) (envelope-from ) id 1xHONL-0000000CBzL-2Iip; Thu, 15 Oct 2026 16:32: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=LnOJC5G478qUscKDL+0IzDiX8X/tbifTtGd4OisH0G4=; b=YqC6qRQF9FSMNZjVMjMyNa1sBR hUdKCwE2FyWbJGZ6A1g6fNjewp/GELaoyoK/RcZrEYlQ8GdyPW+b/9dzjIPFfQ3nbBZJwLDgXjhwj YjAochUlj8POGvY5kqtP/fpPzG4CbmUu3np6dwz0tVd4okA/kcUM4HwPmv42EGrGjMLg=; Date: Thu, 15 Oct 2026 18:32:13 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Marek Marczykowski Subject: Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <78cd46cc-84ed-46df-96c9-26ce97ed0da0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78cd46cc-84ed-46df-96c9-26ce97ed0da0@suse.com> On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote: > Our present handling of initrd is problematic in particular when the > initrd is huge, and when at the same time "dom0_mem=" isn't in use to > significantly shrink Dom0's memory (from the default). In that case, > insufficient memory may exist for pvh_populate_p2m() to succeed (because > initrd memory can be freed only after copying). > > Make an attempt to map the blob (including headroom) into Dom0 instead, I would use "dom0 p2m" instead of plain p2m, it's clearer IMO. > thus also saving the copying operation. With __start_xen() having arranged > for a larger than necessary blob, that mapping can typically be done with > superpage mappings. > > Reported-by: Marek Marczykowski-Górecki > Signed-off-by: Jan Beulich > --- > Is there a need to prune (scrub) the headroom space? We already populate the p2m with memory allocated with MEMF_no_scrub, so there's no reason to scrub the headroom unless we also remove the MEMF_no_scrub for p2m population. > > Why does find_memory() go upwards, while find_kernel_memory() goes > downwards? And why do we use the lowest part of the region found by > find_memory() rather than the highest part? find_memory() should probably start downwards from 4G. > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -450,7 +450,9 @@ static void __init pvh_init_p2m(struct d > static int __init pvh_populate_p2m( > struct domain *d, > const struct e820entry *e820, > - unsigned int nr_e820) > + unsigned int nr_e820, > + unsigned long initrd_start, > + unsigned long initrd_end) We already have a rangeset in find_memory() that contains the RAM regions, I think it would be better if we propagated that rangeset here as it would make the logic easier overall. We would need to initialize it earlier (as find_memory() is used after pvh_init_p2m()), but would avoid the extra logic. > { > struct vcpu *v = d->vcpu[0]; > unsigned int i; > @@ -468,7 +470,12 @@ static int __init pvh_populate_p2m( > addr = PFN_DOWN(e820[i].addr); > size = PFN_DOWN(e820[i].size); > > - rc = pvh_populate_memory_range(d, addr, size); > + if ( addr + size <= initrd_start || addr >= initrd_end ) > + rc = pvh_populate_memory_range(d, addr, size); > + else > + rc = pvh_populate_memory_range(d, addr, initrd_start - addr) > + ?: pvh_populate_memory_range(d, initrd_end, > + addr + size - initrd_end); > if ( rc ) > return rc; > > @@ -518,6 +525,43 @@ static int __init pvh_populate_p2m( > #undef MB1_PAGES > } > > +static int __init pvh_map_initrd( > + struct domain *d, const struct boot_module *initrd, > + paddr_t initrd_start, unsigned int order) > +{ > + for ( paddr_t ga = initrd_start, ma = initrd->start; > + ga < initrd_start + initrd->size; > + ga += PAGE_SIZE << order, ma += PAGE_SIZE << order ) > + { > + int rc = p2m_add_page(d, gaddr_to_gfn(ga), maddr_to_mfn(ma), > + order, p2m_ram_rw); > + > + if ( rc ) > + { > + printk("Failed to map initrd: [%#lx,%#lx): %d\n", > + PFN_DOWN(ga), PFN_DOWN(ga) + (1UL << order), rc); I would print the domain prefix. > + /* > + * Best effort rollback: The range will be replaced anyway by the > + * subsequent pvh_populate_p2m(). > + */ > + while ( ga > initrd_start ) > + { > + ga -= PAGE_SIZE << order; > + ma -= PAGE_SIZE << order; > + p2m_remove_page(d, gaddr_to_gfn(ga), maddr_to_mfn(ma), order); > + order_stats[order]--; > + } > + > + return rc; > + } > + > + order_stats[order]++; > + } > + > + return 0; > +} > + > struct mem_info { > size_t size; > paddr_t addr; > @@ -538,7 +582,10 @@ static int cf_check __init _find_memory( > } > > static paddr_t __init find_memory( > - const struct domain *d, const struct elf_binary *elf, size_t size) > + const struct domain *d, > + const struct elf_binary *elf, > + const struct hvm_modlist_entry *initrd, > + size_t size) > { > struct rangeset *ram = rangeset_new(NULL, NULL, 0); > struct mem_info info = { > @@ -577,6 +624,13 @@ static paddr_t __init find_memory( > PAGE_SIZE) - 1) != 0 ) > return INVALID_PADDR; > > + /* Remove the mapped initrd range (if any), rounded to page boundaries. */ > + if ( initrd->paddr && > + rangeset_remove_range(ram, initrd->paddr, > + ROUNDUP(initrd->paddr + initrd->size, > + PAGE_SIZE) - 1) != 0 ) > + return INVALID_PADDR; > + > rangeset_report_ranges(ram, MB(1), -1, _find_memory, &info); > > rangeset_destroy(ram); > @@ -689,6 +743,70 @@ static bool __init check_and_adjust_load > return true; > } > > +static paddr_t __init find_initrd_memory( > + const struct domain *d, > + const struct elf_binary *elf, > + const struct boot_module *initrd, > + size_t align, > + paddr_t limit) > +{ > + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; > + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, > + PAGE_SIZE); > + unsigned long initrd_size = ROUNDUP(initrd->size, PAGE_SIZE); > + unsigned long initrd_len = initrd_size - initrd->arch.headroom; > + > + if ( !IS_ALIGNED(initrd->start | initrd_size, align) ) > + return INVALID_PADDR; > + > + /* > + * The memory map is sorted. Search backwards to find the highest > + * suitable address. > + */ > + for ( unsigned int i = d->arch.nr_e820; i--; ) > + { > + paddr_t start = d->arch.e820[i].addr; > + paddr_t end = start + d->arch.e820[i].size; > + > + if ( d->arch.e820[i].type != E820_RAM ) > + continue; > + > + if ( end > limit ) > + continue; Don't you want to clamp end to limit here, ie: end = min(end, limit); Like we clamp start to be above MB(1)? We possibly want to continue if start > limit, as then there's nothing to clamp? > + > + start = MAX(ROUNDUP(start, align), MB(1)); You need to roundup after the max, ie: ROUNDUP(MAX(start, MB(1)), align); Otherwise the result might be unaligned if start > 0 and < MB(1) depending on the requested alignment. > + end = ROUNDDOWN(end, align); > + > + /* Don't use memory below 1MB, as it could overwrite BDA/EBDA/IBFT. */ > + if ( end <= MB(1) ) > + break; > + > + if ( end <= initrd_size ) > + break; > + > + if ( end - initrd_size <= start ) This should be <, otherwise an exact fit is rejected. > + continue; > + > + /* > + * NB: Even better would be to use rangesets to determine a suitable > + * range, in particular in case a kernel requests multiple heavily > + * discontiguous regions (which right now we fold all into one big > + * region). > + */ I understand that you switched find_memory() to use a rangeset because it will need to deal with two discontinuous region because of the initrd plus the kernel. However the code here could be adjusted to possibly use a rangeset from the start? I think we should find a way to pass a rangeset around with the available memory regions for the allocation functions to use. Maybe that way we could even remove the need to add a separate find_initrd_memory()? Which TBH looks like it wants to share its code with plain find_memory(). > + if ( end <= kernel_start || end - initrd_len >= kernel_end ) > + return end - initrd_size; /* No overlap. */ > + > + /* Deal with the kernel already being loaded in the region. */ > + if ( kernel_end < end && end - kernel_end >= initrd_len ) The condition in this second branch is never reached, as the if above already has the same condition: "end - initrd_len >= kernel_end". > + return end - initrd_size; > + if ( kernel_start > start && > + ROUNDDOWN(kernel_start, align) - start >= initrd_size ) > + return ROUNDDOWN(kernel_start, align) - initrd_size; > + } > + > + return INVALID_PADDR; > +} > + > static int __init pvh_place_kernel( > const struct boot_domain *bd, > struct elf_binary *elf, > @@ -744,9 +862,93 @@ static int __init pvh_place_kernel( > return 0; > } > > +static void __init pvh_place_initrd( > + const struct boot_domain *bd, > + const struct elf_binary *elf, > + struct hvm_modlist_entry *mod, > + paddr_t *blob_start, > + paddr_t *blob_end) > +{ > + struct domain *d = bd->d; > + struct boot_module *initrd = bd->initrd; > + struct boot_module try = *initrd; Looking at the line below initrd can be NULL here, and hence this should be: struct boot_module try = initrd ? *initrd : {}; Or possibly only initialize 'try' after the initrd_len check? > + unsigned long initrd_len = > + initrd ? initrd->size - initrd->arch.headroom : 0; > + size_t align = 1UL << L3_PAGETABLE_SHIFT; > + int rc; > + > + *blob_start = INVALID_PADDR; > + *blob_end = 0; > + > + if ( !initrd_len ) > + return; > + > + mod->size = initrd_len; > + > + /* > + * As we promise to place below 4G whatever fits there, make a first pass > + * limiting permitted addresses. If we can't fit it there, fall back to > + * placing above 4G. > + */ > + for ( paddr_t limit = GB(4); ; ) > + { > + paddr_t start; > + > + *blob_start = find_initrd_memory(d, elf, &try, align, limit); > + if ( *blob_start != INVALID_PADDR ) > + break; > + > + if ( align == PAGE_SIZE ) > + { > + if ( !(limit + 1) ) > + return; > + > + limit = -1; > + align = 1UL << L3_PAGETABLE_SHIFT; Aren't you possibly asking for an alignment better than what's required by the actual initrd memory? Maybe it's using 2M pages yet you request 1G alignment here. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 15 16:46:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 16:46:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450930.1666262 (Exim 4.92) (envelope-from ) id 1xHOb2-0007o1-6V; Thu, 15 Oct 2026 16:46:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450930.1666262; Thu, 15 Oct 2026 16:46: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 1xHOb2-0007nt-31; Thu, 15 Oct 2026 16:46:24 +0000 Received: by outflank-mailman (input) for mailman id 1450930; Thu, 15 Oct 2026 16:46:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHOb0-0007nn-Rr for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 16:46:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHOb0-00000006n7y-2a6u; Thu, 15 Oct 2026 16:46: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.98.2) (envelope-from ) id 1xHOaz-0000000CRnl-2YdF; Thu, 15 Oct 2026 16:46: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=DlihqTqSnpEfAse+i6ZyWsxfqMTXh85YqrsAHIEbw3E=; b=iukE6EAI0YIVh5VwL730vMeKqD sPdQJJs4qVoqZgS+Gh/sQ2TgwiFWoIZ7tJ370TBm6g2c+sWhnrs9hoNSXoZF99GkwQJVKh+z9SPKP BQeCDejhyI7ZLiSIfuwKvw+QYVUTf6iRT8zUWotBt7jh0vHZKjVvVUZ6nMR4UEhyK33c=; Date: Thu, 15 Oct 2026 18:46:20 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v3 15/18] x86/mm: flush owned pages before reuse with the sparse directmap view Message-ID: References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-16-gwd@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Oct 14, 2026 at 04:34:54PM +0100, George Dunlap wrote: > On Thu, Oct 8, 2026 at 8:00 PM Roger Pau Monné wrote: > > > > On Wed, Oct 07, 2026 at 11:40:48AM +0100, George Dunlap wrote: > > > Since d7bf1b8ea275 ("x86/mm: limit deferred TLB flushing to PV domain > > > support") a page freed by its owner is flushed from TLBs before it is > > > handed out again only in builds with PV support, on the premise that PV > > > domains, with their (limited) control over the host MMU and over when > > > flushes happen, are the only ones to leave stale entries behind. > > > > > > Xen's transient mappings of domain pages are another source. The > > > mapcache zaps a slot when it is unmapped but defers the flush: the > > > slot's translation can stay in the TLB of the CPU which used it until > > > that CPU next flushes, by which time the page may have been freed and > > > handed to another domain. Before "x86/hvm: introduce per-vCPU > > > mapcache for vCPU-PT domains", only PV vCPUs use the mapcache, so the > > > PV condition covers it. Now that the vCPUs of an HVM domain with > > > per-vCPU page-tables have one as well. > > > > > > While the full directmap is loaded in every context, stale transient > > > mappings only map what's already mapped in the full directmap. On the > > > sparse view of the directmap, a stale translation of a page handed to > > > another domain would keep it reachable from a context which has > > > nothing to do with it. > > > > But if it's handed to another domain, then it also hasn't gone through > > a free cycle, which is what pg->u.free.need_tlbflush covers? > > Sorry, the wording there is a bit imprecise; it should be "a stale > translation of a page *freed and then* handed to another domain". > > Apart from things like steal_page(), which doesn't apply to HVM guests > AFAIK, there isn't any way to hand a page to another domain, is there? > > I guess there's dom_cow for memory sharing; but that's experimental. > We should just document that ASI + memory sharing isn't supported at > the moment, and work out the details when that's wanted. > > > > So flush owned pages before reuse wherever a sparse view is > > > configured, as before d7bf1b8ea275. In builds without PV support, > > > mark_page_free() now also asks a new hook, > > > arch_freed_pages_need_tlbflush(), declared with the xenheap hooks the > > > sparse view already uses. x86 answers with sparse_dmap_configured(); > > > without CONFIG_SPARSE_DIRECTMAP, and on other architectures, the > > > answer is no. Builds with PV support flush as before, and HVM-only > > > builds keep d7bf1b8ea275's saving unless a sparse view is configured, > > > which nothing does until a later patch. > > > > I think this is not fully correct, in fact I think we need to flush > > the map cache on every return to guest, otherwise you risk leaking > > contents between processes running on the same vCPU (and by extension > > the same physical CPU). > > > > We either need a flush flush before returning to guest, or we need to > > invalidate every page that unmapped from the mapcache. > > This is a good point, but it's raising the bar significantly in terms > of what kinds of attacks we're trying to defend against. Stack rubble > could technically contain sensitive guest data, but is much harder to > take advantage of than the full direct map, and XSAVE registers in the > xenheap; so it's delayed until later. I think this is the same kind > of thing: Yes, pages mapped by a hypercall may contain sensitive data > relevant to other processes, but it's kind of like stack rubble: much > less useful. > > My recommendation is that we put this off, past moving XSAVE out of > the xenheap, and treat it as another level of safety. Up to a degree there's also a performance aspect here: when you set pg->u.free.need_tlbflush that triggers a host-wide flush on the next allocation (if needed, which is likely the case for systems running HVM-only domains). However if we do the flush on mapcahce unmap, that can be a single invlpg on the local CPU. As systems grow larger, a host-wide TLB flush is quite a bottleneck, and it also introduces interference to remote CPUs. I would rather not re-enable the usage of pg->u.free.need_tlbflush, as I think for a complete ASI solution we will need to solve this flushing TLB entries when pages are unmapped from the mapcache. I would possibly leave this with a TODO or comment somewhere. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 15 17:41:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 17:41:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1450969.1666270 (Exim 4.92) (envelope-from ) id 1xHPSI-0000sh-Tp; Thu, 15 Oct 2026 17:41:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1450969.1666270; Thu, 15 Oct 2026 17:41: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 1xHPSI-0000sa-R6; Thu, 15 Oct 2026 17:41:26 +0000 Received: by outflank-mailman (input) for mailman id 1450969; Thu, 15 Oct 2026 17:41:25 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHPSH-0000rP-Hc for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 17:41:25 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHPSH-00000006oJB-29Uj; Thu, 15 Oct 2026 17:41:25 +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.98.2) (envelope-from ) id 1xHPSG-0000000DeBz-2AsN; Thu, 15 Oct 2026 17:41: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" 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=gDZWlOoDBr+5Z1OlsEHQI+qNCfHIs2r077BENu1ZASs=; b=fqBxhd8ZkUyOI7daYHjhbvf0hc 1KmbXrJTy7s61SBgCTf1WVnYZaSuU68tEJRpAlYLv7jbLT8CkPY79/jyy56F+mQRq9Ds4UewGTY4l OcvIMTrrTggm3WKRPFZaPFG7KjhvjdlXvgNh8mWxYk3irg3o92vxU4mo917bTpeitUus=; Date: Thu, 15 Oct 2026 19:41:18 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Marek Marczykowski Subject: Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <78cd46cc-84ed-46df-96c9-26ce97ed0da0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <78cd46cc-84ed-46df-96c9-26ce97ed0da0@suse.com> On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote: > @@ -867,7 +1078,7 @@ static int __init pvh_load_kernel( > } > start_info.modlist_paddr = last_addr; > start_info.nr_modules = 1; > - last_addr += sizeof(mod); > + last_addr += sizeof(*mod); > } > > start_info.magic = XEN_HVM_START_MAGIC_VALUE; Isn't this still not properly ordered, as start_info address must strictly be below 4GB (as is passed in a CPU register with the CPU in 32bit mode), yet it is allocated last in pvh_load_kernel()? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 15 20:13:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 20:13:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451070.1666280 (Exim 4.92) (envelope-from ) id 1xHRor-0001BU-6R; Thu, 15 Oct 2026 20:12:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451070.1666280; Thu, 15 Oct 2026 20:12: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 1xHRor-0001BM-1T; Thu, 15 Oct 2026 20:12:53 +0000 Received: by outflank-mailman (input) for mailman id 1451070; Thu, 15 Oct 2026 20:12:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHRop-0001BG-28 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 20:12:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHRoo-003jaF-AA for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 22:12:50 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad13386-2eae-0a2a0a5409dd-0a2a4507acfa-38 for ; Thu, 15 Oct 2026 22:12:50 +0200 Received: from [52.101.70.120] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad133c1-b4ea-0a2a45070019-3465467884a4-3 for ; Thu, 15 Oct 2026 22:12:50 +0200 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by PR3PR03MB6361.eurprd03.prod.outlook.com (2603:10a6:102:7d::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Thu, 15 Oct 2026 20:12:46 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0496.021; Thu, 15 Oct 2026 20: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=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=Hi+0/QNQxM/aenGI+Xps+f1a1lqDPm0y7ebAbVlm2C3CHaUPuxps8bJd0kigEV9o5OsvyIenpgS/tmuvg5HLsXzbM4SW8sa841Py7JLBTQmdHVJ178eq3lhJm450swbWbQPKdQv4DX1WrTM+063J+4ngTtRYcSfSabq+74hd5Whc8pVv5a2ka9BrrwwCcL4kbeVWwqWK+ZBgnQ0NIuOosREd8lzWnws5cvtUwTk0vyhXSkAJ8QzRLgi+b4gtUv5floYzBlIKm7XWIME2jLCOA4R+J06oRarLqYaBt8J5eFjbyr996jU0EEFQxkvXxl7XXct3rupkpBL7KHOQe4ToQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hpymvdoUJNHPFdmRIppfSALpFY+nXbzKiJ1kKD67Fr4=; b=GbQl3PMwFPsLtpmqADUloYTMeqXZWFcOMABSRwTafakyO3cQEIq9ybfb/1y3gsPaTpcA+ia+hIyk9MIgQNAnOoBormqUZMyMZOdLtRvVbVpz4X8Ik2fOVuewePlz+NgNx5FXcfiTwr49gMOc9L8Ptk8bMWPfwJTk+8Mho0cDrbalGwyzBSGfIgMy2IopXtl3I6abbfb56Np+kM1OEkiMcE8V7NcfJWkD4CacPhnWaXqUsWJSjrnl4dC+cAaCsxykjpe1gHVqmkiY/w3Hff1SVzZjSHTSMM4MmRDeE2/5VdQmRKBLeAI8HAboIrjLn+UEfVtU099MOxFStEN7IZIL0Q== 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=hpymvdoUJNHPFdmRIppfSALpFY+nXbzKiJ1kKD67Fr4=; b=G7BegEVoA/yIdDivDeTcCvtiRYY0NdcJ4XQCtI51E7IlFLoU5cM0NBO+xSxUwDPmRKVZwYaOo1IZeMzrE4bJmypWyYi89qLRtiJ2r8M4Z0wVegpmzfHCVjLNGSPTZXgto7LyC8+vg5zxQlbhOb6D0DaVbe6NeXrHeMsUoPCL+JiX8ObXrl2EG4xlklJ+nseUsOQOD1dL5K6S4MGyXgcYF6ANK1mIkChwSsRd+rtiJVhUlMTTw2/J3caGvGEqFAKzfiH79yJzEhg5bWGRBjvaRYl0kTq9vhrdV+myYA95fnfTm9U7ZZ6Hm+cd8AJNncl+croR18ZaNIB9RBX+HO/GJw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <61bf8fa4-1ede-4a74-9eff-8ec8188bc1a3@epam.com> Date: Thu, 15 Oct 2026 22:12:45 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 10/22] xen/arm: vsmmuv3: Add support for command CMD_CFGI_STE To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: Content-Language: en-US From: Milan Djokic In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AS4P189CA0026.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:5db::13) To AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS2PR03MB9587:EE_|PR3PR03MB6361:EE_ X-MS-Office365-Filtering-Correlation-Id: b0bebc27-ca94-4e22-4566-08df2af8ad6c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|11063799006|56012099006|261009223027099003|4143699003|22082099003|6133799003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: 5xIy0DprifNigwPcjSmV+OFWliqi4lEt8p8EaSgRXlpANDLpyOiZeyV6sQQRyzNduJ0oQKiG7hq0h16XtPqd9GOWQv7q1ZGaVnLwIEyIPdE3sGs3BDqDqem4IliV58vxyTVlEt5k88b2UoNMfVAhznSKsDe/B5Z5iw6UZBGvFJT9Cu9FKJ54MTiipD7A7vzTFJ5aQpo7CNtfOwrk5L58We7fA/JvDj9sSAT3gqaPc0rSOuvHxp0dCtAw5VB5jHNILD8qSjqZalJHt1dc09/AGgY5mZZL1diY3Kj2s2VO3e2fZTnTUhGdJ6O5vBVpiLuTlV4e0uIGbN1Jz+IvkfRrokPnyVGOOxtDZmPmgXDxpKIzwHlcR1hX/RpSr34Lxd+zxnroYJdntAH7EV24LG7z0yHC8hJIVY2pz9D1dnml6T5gpGj/0tYLo5dS5tBpmRL9/qZu7YEHTAidPrIGiHSDNbRnsctxzZtxq/LpoxhEtb3TEWasAP4Km0Am1n0rDiV00+ZWigr9o4IAOT3XXXuqsbgshI4fxQ7xXynWl6ZmUYJ7sX7KjPNqDecsgXNGAaNQB+DHa1ORatYYpbx5KQt7MXcoE5Z6oW+7kiLIoZcnWBsyMfm2G62nt34cKg1IMfw7zevqqrHtLEe4/lWudlO1Lg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(11063799006)(56012099006)(261009223027099003)(4143699003)(22082099003)(6133799003)(18002099003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RDJ1cGlXWjFDb3hzUFV0OGlrZzNNR1hERnNvTExFRnE5RWJUNmhPR1FNZUpW?= =?utf-8?B?WmNFbU92TnltTkxFRkdxaitTTTF3UUFOUFYvY2gyVWdFRko5V2ZPOTZMcGV2?= =?utf-8?B?amxzL3lOVTBoak5NaHlkL3JQRlliY2RUMzFob3FFdksyc1FhUk9KYTJLSVBF?= =?utf-8?B?OEorV3VHdngrS2t2NWNnWm1rSGJkZHBRRXVPQjJvSFNjRUhYSzUvVWt6c05U?= =?utf-8?B?aWxjcHEzMHQ1UWwwTHV4VnNMWi9YWU1jeUpMcHIzTWNTb0R1RW5HSmJYL0F6?= =?utf-8?B?Wnp1RGNXMUp0UzZ1VTlOc3VUV3R5T3Bjd05CTFNGRzVtdzkzdHhBWENZL01D?= =?utf-8?B?SnFxZDlNdEVkM29vRktSSTAxVFlocTcrN0wzZklSdVB1MWFDa0pWK2EyV1ds?= =?utf-8?B?TGEvTHZIWlVmamtRUisxaFJZTks3OS9DdTJRQkVLelltOHRKdFpVdmhxSlpr?= =?utf-8?B?ZmROcVFlNVlkdzRFamlUZXg4T2VCNnNGeFhEUzNIK0R1Z2luVzlreVdVcFd5?= =?utf-8?B?TURmczRWT0E4WnFrVm1OZENvakNzbTdmbnJNMzJMZG1rYkdacHk4dm5xY1hh?= =?utf-8?B?UEkwYVpVcnk5N1ZMZEFjZU4xd0ljL1ZsdEJ5bks5NVU4QVUyektqcWVIY0NN?= =?utf-8?B?WTFzcDZweFFJaEVCMUtQbmkrYUk5MGZOZUNTVm8yYVhNN1NtaFd1UWRrNU5s?= =?utf-8?B?U2dhRVhqRW92ZWZRVmxQbmN4WWR1Uk51cmcySS9odGR2bnZaNnRrT0phaFY5?= =?utf-8?B?ZTg0NTJUa3RJdzFKeHFyYzhqNFFTbFRiK2xOR1prWTlzSTEvcUVMdzU4cU84?= =?utf-8?B?ckc3aHUrbTIwcnJjSkdlZkhWKzNlenJnbTF4bk00QmlleXg2M2t6N29kV0NN?= =?utf-8?B?OTVweW1RYmZrTk1RVkU2NUs5Ym5kQ0Z2MkNFb2FnSGZuT1dOVWZ2cDhoQWta?= =?utf-8?B?TzAvTGk3SXhYL1JQK2ZVaWtOUDFiVHhWeVhmWG8yZXRsdU9JRHZkZG5ZSjNz?= =?utf-8?B?eDUxSHNBZnZiRTNvMkEvSmRuOVI3N1dSUXhzNFcyMFIyVUNpWFIxeVdnVjEw?= =?utf-8?B?clVlbC8wdjllSEVtYmFuS1htaVVGWjEvV1Fyb2hqL3NPREhQQ01TK3ZxNE9V?= =?utf-8?B?enhsYXEyNEdYVy81RW5lODJ2bWlXL2NZWWtwOWpTa05QNUZoK25LbU5SaEVL?= =?utf-8?B?RDBvWnBxSzJ3Rkg3MkdQSU5HcXd0Rzl2TC93cGhNU2NoQTVUTFluYkx2TlBV?= =?utf-8?B?amJIK1VJUFVzNWVob1JvN3FidHNFZ1pIaTcwYU5RL05tK29JNDRHZ2svcUVS?= =?utf-8?B?N0FPbi92WVI0bm9uWGp0Wk9tTFFXL2s5cENqWEFSTHprdmoxOHROSlFHMGRD?= =?utf-8?B?MWtKSWdzcU5kS3BPQkxhd0FoQ0orckQxNkVuQXBiWCtvak94bnh6eEhjaEky?= =?utf-8?B?YkNWSVpuQ2dTb0JucGdKME1TV0dvbUpQTGJIL3JFbUFiYU01S001OFVrSjFD?= =?utf-8?B?b0pKQ2lpeWxrdFgvbU9PUm40VEtrZHQveEptbGZiUnJGMHh5ci91c2RkNzdk?= =?utf-8?B?UXBwYzZvcUlIaEcrc250ejNnVktNd0RHcENxNGoxZzEzRUlaYTVmK2EyVi9P?= =?utf-8?B?Nk45VDM3NG9ZdnkzRHNjM3p1MW5YNlFKNitiMzZER3hGQ0kvc0hpOFJOZUJ0?= =?utf-8?B?Y1lYOEo2clFEM3lDQ1YzTm5YZUFRSDFJVi9Bc0FlZ3Z4aXZyWEVzb3VCZFdp?= =?utf-8?B?dFUrNElIdVFnRVMxeGxMRzhtYUkrWlFQT2EvREhvb2E4NGlFZjJ3Wi8rYnJE?= =?utf-8?B?d2I2U0pFYy90bVJDbjFTZDcrMnh5QXhtQkhEWHVZQUNpME9YQi9hQ0ZNM3lQ?= =?utf-8?B?K0J5UGxmUmxEcW10UU41NHZldVM4VHNZczRkTTAvWWg1d0E4ZTJXVTVnd2lz?= =?utf-8?B?b0Yxb3ZnSGJieWwzZzVxdXVjWm5rV2E3STRWQ3hsTVhDMUM0bHZqd05qcUVL?= =?utf-8?B?eHJ2Myt1YWd3RWNRMHJHdHZDZ3RmMEZwc0pQMUYwc2hQdkdTRG1nN1ptTzVa?= =?utf-8?B?ZGtwd2RZZkQxY0V6RXI3SDdBa1N5SDNZdjNCaVd1cit2QWwzNUQwek9QVVNZ?= =?utf-8?B?UC9pQzY0UXVIRzRpMU5YcGhKeHFlV3hSWlZHSzJ1Y1hhWDZ6eHBrZXN0b1Z1?= =?utf-8?B?c1N6M0JFeWNCL1pPSSs5Qi9lWEkvRHU4bmJBdGQxZ2MvRFh6UmRNZ2lqQUpO?= =?utf-8?B?c2NYNUhpUnkrdGR0dWlydnM1Sll6ZXZMREdIU2JYNGN0VmpiZUd0VG9WaG9O?= =?utf-8?B?ZnZyVk01Rml1eGppdm1OOFg2SEFkd0I3Z1ludC9uZ25EVnZqVDh2QT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0bebc27-ca94-4e22-4566-08df2af8ad6c X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 20:12:46.1156 (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: He3YjRN7qSN93Ar8wH/h6dRpNsIwt2wrdxvnC/odqUZFv2fFp4dY9jWbfeYTztJqQpO04CKBFEOdvIa7aC5e8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6361 X-purgate-ID: tlsNG-ef75cf/1792095170-358C1AE4-81F2525F/0/0 X-purgate-type: clean X-purgate-size: 8697 Hi Oleksandr, On 10/10/26 18:14, Oleksandr Tyshchenko wrote: > > > On 10/7/26 03:06, Milan Djokic wrote: > > Hello Milan > >> From: Rahul Singh >> >> CMD_CFGI_STE is used to invalidate/validate the STE. Emulated vSMMUv3 >> driver in XEN will read the STE from the guest memory space and capture >> the Stage-1 configuration required to support nested translation. >> >> Signed-off-by: Rahul Singh >> Signed-off-by: Milan Djokic >> --- >> xen/drivers/passthrough/arm/vsmmu-v3.c | 169 +++++++++++++++++++++++++ >> 1 file changed, 169 insertions(+) >> >> diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c >> index 10143927e7..25ba734fa7 100644 >> --- a/xen/drivers/passthrough/arm/vsmmu-v3.c >> +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c >> @@ -78,6 +78,21 @@ >> >> /* Helper Macros */ >> #define smmu_cmd_get_command(x) FIELD_GET(CMDQ_0_OP, x) >> +#define smmu_cmd_get_sid(x) FIELD_GET(CMDQ_CFGI_0_SID, x) >> +#define smmu_get_ste_s1cdmax(x) FIELD_GET(STRTAB_STE_0_S1CDMAX, x) >> +#define smmu_get_ste_s1fmt(x) FIELD_GET(STRTAB_STE_0_S1FMT, x) >> +#define smmu_get_ste_s1stalld(x) FIELD_GET(STRTAB_STE_1_S1STALLD, x) >> +#define smmu_get_ste_s1ctxptr(x) FIELD_PREP(STRTAB_STE_0_S1CTXPTR_MASK, \ >> + FIELD_GET(STRTAB_STE_0_S1CTXPTR_MASK, x)) >> + >> +/* stage-1 translation configuration */ >> +struct arm_vsmmu_s1_trans_cfg { >> + paddr_t s1ctxptr; >> + uint8_t s1fmt; >> + uint8_t s1cdmax; >> + bool bypassed; /* translation is bypassed */ >> + bool aborted; /* translation is aborted */ >> +}; >> >> /* virtual smmu queue */ >> struct arm_vsmmu_queue { >> @@ -165,6 +180,159 @@ static void dump_smmu_command(uint64_t *command) >> gprintk(XENLOG_ERR, "cmd 0x%02llx: %016"PRIx64" %016"PRIx64"\n", >> smmu_cmd_get_command(command[0]), command[0], command[1]); >> } >> + >> +static int arm_vsmmu_find_ste(struct virt_smmu *smmu, uint32_t sid, >> + uint64_t *ste) >> +{ >> + paddr_t addr, strtab_base; >> + struct domain *d = smmu->d; >> + uint32_t log2size; >> + int strtab_size_shift; >> + int ret; >> + >> + spin_lock(&smmu->strtab_cfg_lock); >> + log2size = MIN(FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, smmu->strtab_base_cfg), >> + SMMU_IDR1_SIDSIZE); >> + spin_unlock(&smmu->strtab_cfg_lock); >> + >> + if ( sid >= (1U << log2size) ) >> + return -EINVAL; >> + >> + spin_lock(&smmu->strtab_cfg_lock); >> + if ( FIELD_GET(STRTAB_BASE_CFG_FMT, smmu->strtab_base_cfg) == >> + STRTAB_BASE_CFG_FMT_2LVL ) >> + { >> + int idx, max_l2_ste, span; >> + paddr_t l1ptr, l2ptr; >> + uint64_t l1std; >> + uint8_t sid_split = FIELD_GET(STRTAB_BASE_CFG_SPLIT, >> + smmu->strtab_base_cfg); >> + >> + /* >> + * Reserved SPLIT values behave as 6 according to the architecture. >> + */ >> + if ( sid_split != 0x6 && sid_split != 0x8 && sid_split != 0xA ) >> + { >> + sid_split = 0x6; >> + } >> + >> + strtab_size_shift = MAX(5, (int)log2size - sid_split - 1 + 3); >> + strtab_base = smmu->strtab_base & STRTAB_BASE_ADDR_MASK & >> + ~GENMASK_ULL(strtab_size_shift, 0); >> + spin_unlock(&smmu->strtab_cfg_lock); >> + idx = (sid >> sid_split) * STRTAB_L1_DESC_DWORDS; >> + l1ptr = (paddr_t)(strtab_base + idx * sizeof(l1std)); >> + >> + ret = access_guest_memory_by_gpa(d, l1ptr, &l1std, >> + sizeof(l1std), false); >> + if ( ret ) >> + { >> + gdprintk(XENLOG_ERR, >> + "Could not read L1PTR at 0X%"PRIx64"\n", l1ptr); >> + return ret; >> + } >> + >> + span = FIELD_GET(STRTAB_L1_DESC_SPAN, l1std); >> + >> + /* Validate SPAN against the architecturally defined range and SPLIT. */ >> + if ( !span || span > 0xB || span > sid_split + 1 ) >> + { >> + /* L2Ptr is invalid; this descriptor matches no valid STEs. */ >> + return -EINVAL; >> + } >> + >> + max_l2_ste = (1U << (span - 1)) - 1; >> + l2ptr = FIELD_PREP(STRTAB_L1_DESC_L2PTR_MASK, >> + FIELD_GET(STRTAB_L1_DESC_L2PTR_MASK, l1std)); >> + idx = sid & ((1 << sid_split) - 1); >> + if ( idx > max_l2_ste ) >> + { >> + gdprintk(XENLOG_ERR, "idx=%d > max_l2_ste=%d\n", >> + idx, max_l2_ste); >> + return -EINVAL; >> + } >> + addr = l2ptr + idx * sizeof(*ste) * STRTAB_STE_DWORDS; >> + } >> + else >> + { >> + strtab_size_shift = log2size + 5; >> + strtab_base = smmu->strtab_base & STRTAB_BASE_ADDR_MASK & >> + ~GENMASK_ULL(strtab_size_shift, 0); >> + spin_unlock(&smmu->strtab_cfg_lock); >> + addr = strtab_base + sid * sizeof(*ste) * STRTAB_STE_DWORDS; >> + } >> + ret = access_guest_memory_by_gpa(d, addr, ste, sizeof(*ste), false); >> + if ( ret ) >> + { >> + gdprintk(XENLOG_ERR, >> + "Cannot fetch pte at address=0x%"PRIx64"\n", addr); >> + return -EINVAL; >> + } >> + >> + return 0; >> +} >> + >> +static int arm_vsmmu_decode_ste(struct virt_smmu *smmu, uint32_t sid, >> + struct arm_vsmmu_s1_trans_cfg *cfg, >> + uint64_t *ste) >> +{ >> + uint64_t val = ste[0]; >> + >> + if ( !(val & STRTAB_STE_0_V) ) >> + return -EAGAIN; > > I am sorry, but I do not follow why invalid entry ... > > >> + >> + switch ( FIELD_GET(STRTAB_STE_0_CFG, val) ) >> + { >> + case STRTAB_STE_0_CFG_BYPASS: >> + cfg->bypassed = true; >> + return 0; >> + case STRTAB_STE_0_CFG_ABORT: >> + cfg->aborted = true; >> + return 0; >> + case STRTAB_STE_0_CFG_S1_TRANS: >> + break; >> + case STRTAB_STE_0_CFG_S2_TRANS: >> + gdprintk(XENLOG_ERR, "vSMMUv3 does not support stage 2 yet\n"); >> + goto bad_ste; >> + default: >> + gdprintk(XENLOG_ERR, "Invalid STE config type\n"); >> + goto bad_ste; >> + } >> + >> + cfg->s1ctxptr = smmu_get_ste_s1ctxptr(val); >> + cfg->s1fmt = smmu_get_ste_s1fmt(val); >> + cfg->s1cdmax = smmu_get_ste_s1cdmax(val); >> + if ( cfg->s1cdmax != 0 ) >> + { >> + gdprintk(XENLOG_ERR, >> + "vSMMUv3 does not support multiple context descriptors\n"); >> + goto bad_ste; >> + } >> + >> + return 0; >> + >> + bad_ste: >> + return -EINVAL; >> +} >> + >> +static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) >> +{ >> + int ret; >> + uint64_t ste[STRTAB_STE_DWORDS]; > > NIT: Looks like ste[0] is only used today (first 8 bytes), the rest is > uninitialised. > Initially, this was defined to hold the entire STE. However, since we currently use only the fields in ste[0], we can reduce it to a single 8-byte variable. >> + struct arm_vsmmu_s1_trans_cfg s1_cfg = {0}; >> + uint32_t sid = smmu_cmd_get_sid(cmdptr[0]); >> + >> + ret = arm_vsmmu_find_ste(smmu, sid, ste); >> + if ( ret ) >> + return ret; >> + >> + ret = arm_vsmmu_decode_ste(smmu, sid, &s1_cfg, ste); >> + if ( ret ) >> + return (ret == -EAGAIN ) ? 0 : ret; > > ... is treated as success an no-op. The physical STE keeps its old > guest_cfg (added by subsequent commit) after the guest invalidates it. > Could you please clarify why this is ok. Should not it become abort? > Yes, this is not handled properly. I will update the implementation to switch the domain to abort mode to prevent the hardware from using a stale STE. >> + >> + return 0; >> +} >> + >> static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) >> { >> struct arm_vsmmu_queue *q = &smmu->cmdq; >> @@ -191,6 +359,7 @@ static int arm_vsmmu_handle_cmds(struct virt_smmu *smmu) >> switch ( smmu_cmd_get_command(command[0]) ) >> { >> case CMDQ_OP_CFGI_STE: >> + ret = arm_vsmmu_handle_cfgi_ste(smmu, command); >> break; >> case CMDQ_OP_PREFETCH_CFG: >> case CMDQ_OP_CFGI_CD: > BR, Milan From xen-devel-bounces@lists.xenproject.org Thu Oct 15 20:26:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 20:26:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451086.1666289 (Exim 4.92) (envelope-from ) id 1xHS1o-0003tL-Bq; Thu, 15 Oct 2026 20:26:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451086.1666289; Thu, 15 Oct 2026 20:26: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 1xHS1o-0003tD-7C; Thu, 15 Oct 2026 20:26:16 +0000 Received: by outflank-mailman (input) for mailman id 1451086; Thu, 15 Oct 2026 20:26:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHS1n-0003t1-Ob for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 20:26:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHS1m-00Glze-RX for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 22:26:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad136dd-8faa-0a2a0a5109dd-0a2a45059ef4-16 for ; Thu, 15 Oct 2026 22:26:14 +0200 Received: from [52.101.57.68] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad136e5-4cb1-0a2a45050019-34653944e869-3 for ; Thu, 15 Oct 2026 22:26:14 +0200 Received: from DM4PR12MB6374.namprd12.prod.outlook.com (2603:10b6:8:a3::18) by DS0PR12MB6631.namprd12.prod.outlook.com (2603:10b6:8:d1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.20; Thu, 15 Oct 2026 20:26:05 +0000 Received: from DM4PR12MB6374.namprd12.prod.outlook.com ([fe80::af35:a7a6:6ca:7fcf]) by DM4PR12MB6374.namprd12.prod.outlook.com ([fe80::af35:a7a6:6ca:7fcf%5]) with mapi id 15.21.0522.011; Thu, 15 Oct 2026 20:26: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=fail header.s=selector1 header.d=amd.com header.i="@amd.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=T3FT+01/u6bliMTPcErBre6bF0mkEGYGd5FVi+ib6JpmtaPDnfyVfCj0UMu7cKjoOfptDUaXHj1HadDZE+RAGoOHmWnG0X6NASRO8UsWACGF242M46ak6tlAvjNs5cjXkXdo7jGTXQ53MSFUPKEWaan0WK54k2N4tE+t0B3M42eh9TCx1Xurz2jhP8SA6m41ha0KxbNPEnELuyv7+KCjtwP1zjk9BAqIPKhbtHao/QhHSHsLPkkA6zvZ4baNv8WYtcu2WwH9kzWvQP/taTSgXGUhFAMyVKBOSZopC/oQGaBh3TKeW8YZNJrEl2Q2yDe7fck+dP7snthc3TU05I0ukg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dIhrhRYhWiXVbuVvBbLaM2UZKoe9JP+wgs2TfqwRFiY=; b=tgzvhnelzUlGmOGlmH04oVmlXL5zzsmqZCwdIC1Z+0wWatB+ykAyg4gAUlN4NwPY5xOIFXuWAS/ltQa3fZ4eTS3RVNAE7m+qb7dM5Siq/COU5UmjCC6RObR7SyB8ojQtzISbtVxQYK/Obnhl9yGaZzq4KLhiDxTo2M+o0V2sheGBT+BHgJXYSrKoCHjgf5tI80J4VwB7EM/OXjyHMkfT8JxKAHy24KQ0NYs2DWdvrZpAovkriaJSiBGNkSuxmCmGUpZimhEIWkK/i0BmC+Tq9SNdW++yohaQVxNtxmGG759IZJseoPcbByjiKNgpQ/D4gfJGMDREGbeLn39DiTw6xg== 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=dIhrhRYhWiXVbuVvBbLaM2UZKoe9JP+wgs2TfqwRFiY=; b=1XEZfswBtRJsfrFGDbntL3y14D5qm421CEaErP5Wj+Ey213pwy9SYDTjV3veaagb+tlnxXMdn4rUAGmlVLqDHG1cakqumSs4DZrE9xchvmJg9NVtecbu0Jc/MlKYjx2VkU92ht4KW8/EA+ux4dXB2OAWNfzueGMrBaClJpnYJUc= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Date: Thu, 15 Oct 2026 16:25:45 -0400 From: Yazen Ghannam 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 , 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 =?iso-8859-1?Q?J=E4rvinen?= , 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 Subject: Re: [PATCH v4 12/13] treewide: convert rdmsrq() from a macro to an inline function Message-ID: <20261015202545.GA1335@yaz-khff2.amd.com> References: <20261008071839.2247074-1-jgross@suse.com> <20261008071839.2247074-13-jgross@suse.com> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261008071839.2247074-13-jgross@suse.com> X-ClientProxiedBy: BLAPR03CA0069.namprd03.prod.outlook.com (2603:10b6:208:329::14) To DM4PR12MB6374.namprd12.prod.outlook.com (2603:10b6:8:a3::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR12MB6374:EE_|DS0PR12MB6631:EE_ X-MS-Office365-Filtering-Correlation-Id: a2d1fad7-3215-4308-603c-08df2afa88a8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|366016|1800799024|23010399003|56012099006|11063799006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 9PfaU+CcBdAhpbx/C/NnJ62bGXvju0n9WXba5N2vYW/Bu8MXDfMOwZXmplw0TWe/Xfy9Ue5H/8Vf0eTVqpjapRKvUGEXzvPOAez22EZCKfNUj+KdHstqtOI5QpR+mSJBbcyQps8Zqll4zN8nRwe1HJ94DcT18X92JboGTixnDlCcRU9ssowbjCQ2KXa2plgNFm2pi3WQdvbO02xHhuZ2JTvnuBWrnkG7FtFsUwaZ+oykNG0zjyDQAAN+2Lrw/7auGMjcahOuw/lc5BqDgM1jPPx6ItQv3sOz5IhbK0FNYK/7Kk/CxJgKFLDYvaHdOACx7nP6cPQdkntMLVjoF8qLFcqKWV0K6F5oNaMP++PUFPnUNzUiOc19az/JMRSW4XgADu3veOrqR8ABBdRB/vRR00C765Nt3rjJDHI3NWPM5RsuVkF6lD1AfxSJNtsM4k0KakJxcl1hBJqnACTytU303aKkaKmZep3mk2OkKKYwxlRmvWIAirFvQdEn3grk6XxesUfWNVFmXfhSs+KUPUp0pplmACDruIBXnGcVTAjNLhTaGEh+ZpVT3BBOSI5tP1gsJH2WclliUW8dG/PXBMLV2QDNypOW5tb4RbstTC0+7VGKht/4TndNa+ivB1OsDDqH6E2L9Nve16nMVimFCfUy1u0ZmvIalfkwb0+NwLUdQh8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB6374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(23010399003)(56012099006)(11063799006)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?BeRIkSzZ8/fzyvoZWeb8eHGmHpJKuigV4R+vAkaFv49Fn23fQylbI0uNN3?= =?iso-8859-1?Q?fpDbggTObTiE5LxUHsG6d8QJh3CcDhsPgn64Dgga5DSrUqZ6dbs8yVEbcy?= =?iso-8859-1?Q?ToVhD7HSifFwpcnK0MYPy1IVry4tYn8lZA+J5joSdVH5SLfUDBwBy2eRSL?= =?iso-8859-1?Q?K3/cQIWz6AvC/PE6dHLxW2qN9QZkcXl5xRCYGwOOm0nmL4XWqFFwfpqw5s?= =?iso-8859-1?Q?OFFJbnp2KGlkbrws4YGlB2KUHjNch7UxIp/F2dS+fcLG5vfxg10ih3stde?= =?iso-8859-1?Q?9Rq5vvxfjFzCn80wcuPnc1PPlrxxKWTLXeAd9RoKN3tuOVJjYv8scS+hTZ?= =?iso-8859-1?Q?AcHWbhAHu7fcc2s7xp7uv8/nFOIDvqDw3XEyyrCrfu2IqSdL+FjhCUK68G?= =?iso-8859-1?Q?thi5VN46zxhXIQ1/KMiOXpU7DNwt3b/piu+Adc3ss93lPVFcKAhsYnRn8y?= =?iso-8859-1?Q?uPzLtPD2LKdq8ZqIRzMpaQW7lcK9GkQWBVzet8hs2hXdVIjkFdnmLq2Gny?= =?iso-8859-1?Q?UGRXokDl88LB83pnRC4r/sgmi40WAemQKGdfqQSbbfGUHLpiW1U+uycR9B?= =?iso-8859-1?Q?fYHure4O+uiw1/yS83SyJy1V8kLEOqJaArZsTyWw4+uxiVZ516EVhYhPJ1?= =?iso-8859-1?Q?QXrlO+gWLkVMXswJDkj4yvFLfMdCr6Uiv+T74uBUr2+CpW4w/qTmx01W09?= =?iso-8859-1?Q?uUhHaKqUBWWckgGA3s4twzSbkVwY1XW3KoUdOmhyiUIOM4byrb94SqE/+D?= =?iso-8859-1?Q?8rKoYkE44C3qslEnt724cf7x5vOEJMrrKtNIOwOuOGYu4xitLUzSWMWhmF?= =?iso-8859-1?Q?y7H08UTdyS7NtXNPUQMD5vkoi5GFPXkZk3R8MHkvwf1mOMunuyFb3dfmz0?= =?iso-8859-1?Q?/3RWD8iDcN9nSnfX+hqhmvnGY7woHILu1WaeLQtFYthZBcAqExmDQHdcAe?= =?iso-8859-1?Q?iGYIwBWVXmZJMY3+OcOJYdDd2Dx1eAZR8hHTkL/AeSjpXIJbtaYHOuuAV/?= =?iso-8859-1?Q?ZU1GpbrTW8G4MnZOtmvpaq9Nk4oIHU5b8k1R6X+mKm9d2PGEAcwRmk5B62?= =?iso-8859-1?Q?bfKAeoS9/JLRLjPB/We6a9uBmgdTnuqUHA/fm986f+qDBWeKlLaresnAVn?= =?iso-8859-1?Q?nVqOCuMGAtfhUIPQ7HDtpSgSR21Pcf/kd9eoeU/4Ptfn6DmmtZtK3hnqU5?= =?iso-8859-1?Q?7/pHXY2XbCeaV1TtTjAH86iTgQibYp1oTs+F+oYxlHwqZvRYj9s7SqOQXe?= =?iso-8859-1?Q?Wtl/Xf1PQ+3l6TY2YE2ggKOHL2M/tTnlynRy7gp+JyNsfYFZTqcQRSQXkx?= =?iso-8859-1?Q?pCow6V0A+3Uy5Cqeqo22bL9lVuvFQf98hqLQ/+bE5JZ5ucE/3KtBdoMpeS?= =?iso-8859-1?Q?FeVwfdPdamV6QbZXYQZHGtiReIicPhpwDksBlun1d45pzFgd+Froj1hqna?= =?iso-8859-1?Q?cDYR72jzbwcneD9UJ6FUscCJtZeqTzOygeRGZBShzSpySFrMAsEjYu1nOz?= =?iso-8859-1?Q?A1rB3vGau4ZoahVFx9LU1uQLzTS7HvLOVvAjaehCF1ji5AktbPY/GSnT3x?= =?iso-8859-1?Q?zrCbMeAEp4Q8zg4XraJk5DPwTcMXzl2UVoNmRpWuxsnWq371TSpnr5vu+q?= =?iso-8859-1?Q?ypy5jxoGKbUorHrN37EcT51lmFSM82PJ82WFVza/E/UxMEe/JlP7aI1JjK?= =?iso-8859-1?Q?2I4dtR0PH5kUuPw/llVJQLtxQ6V4v+94mObLpL75Fe+kyTbXKb1ddeCCsB?= =?iso-8859-1?Q?xqy8C6ss8VmSAr7ycWz5vykeg04hgUq2wZX5Ykm2C6bDSO?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2d1fad7-3215-4308-603c-08df2afa88a8 X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB6374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2026 20:26:03.4850 (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: 1ffK53pvKIyCwXArrXQKNXAfnhDhCV5QTGz8DhqUVx69qv5dR5B5maC+lw5XHl4AfIutq0lizPx9oZqw6dFEMw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6631 X-purgate-ID: tlsNG-c201ff/1792095974-F5EA92A1-D1D57535/0/0 X-purgate-type: clean X-purgate-size: 1131 On Thu, Oct 08, 2026 at 09:18:38AM +0200, 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: Rafael J. Wysocki (Intel) # ACPI, cpufreq, powercap, thermal > Acked-by: Sean Christopherson > Acked-by: Reinette Chatre # resctrl > Reviewed-by: Zhongqiu Han # cpufreq > Acked-by: Ilpo Jrvinen # pdx86 > --- Reviewed-by: Yazen Ghannam # mce, amd64_edac Thanks, Yazen From xen-devel-bounces@lists.xenproject.org Thu Oct 15 21:05:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 21:05:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451121.1666327 (Exim 4.92) (envelope-from ) id 1xHSdu-00026L-Le; Thu, 15 Oct 2026 21:05:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451121.1666327; Thu, 15 Oct 2026 21:05: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 1xHSdu-00025w-Fs; Thu, 15 Oct 2026 21:05:38 +0000 Received: by outflank-mailman (input) for mailman id 1451121; Thu, 15 Oct 2026 21:05:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHSdt-0001kL-FE for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:05:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHSds-00Gq26-SP for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 23:05:36 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad14003-bab6-0a2a0a5309dd-0a2a45089e60-30 for ; Thu, 15 Oct 2026 23:05:36 +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 6ad14020-f659-0a2a45080019-d155dd30d938-3 for ; Thu, 15 Oct 2026 23:05:36 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48afcd7ba9bso3236376f8f.3 for ; Thu, 15 Oct 2026 14:05: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-48dfd4f8bd9sm501163f8f.35.2026.10.15.14.05.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 14:05: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=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=1792098336; x=1792703136; 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=Xt9bqym88aw89T5uLaWYHXCdtcAThtYx4kEoJI0JtxQ=; b=Yezu4jY5pP/1DRjALt/mx9WcqNeWCbiN4e8jQWx0mK/AOP1ZEHV7vK/rPyhIAnNWFI wun+PzG0CjwaJa+tPGsWOb/kGUpbBwAQlnwW0s8u1QqtTIkCZWUE33mgaFr/1jCjCwld w5mSi+gsaAP0d/oIWrX34E1EG/pmlUB/zMYe8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792098336; x=1792703136; 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=Xt9bqym88aw89T5uLaWYHXCdtcAThtYx4kEoJI0JtxQ=; b=HAxoC6lTxUyktCc/EtULR3r0y3rSTUvfCPrrwqQuUQ8kzdvHTPQwJC9Bo36YLyDU4r W77DcbWemJi9AU5qpx0DNpehIu5Q6j4MZ3ZdSOYdz91EKQgQSih7h1ib5y7nb2Xz68Ev ++1GBHvcDwSF57bwittzRECgqOVwhPFr4ogpihuBGEdD1Je48pzUKyacDcPXRiyUcS6S tKUy+LRoeZZFgVpr98EO5AFmDMTSFYjKZ6p8OVK9aEn62kegmy6ggYUb4MSKuIwHNOcU QX+zJ7syYhwn6K2K7L+xUszf8MSn8kWy7IEhZlwhTRb+o8pAWI6MNeJFSc7E6B3/jgvR bFjQ== X-Gm-Message-State: AFq9FYJKdpEdRIt3EsjT+zn1exc7t5LEeDENMkNaeekQ579wiDy3sbpV jWfMOorajMI3clT9rjWdrBX72RhR54qGnz/4IgOt8EwjnZ5EkMkRtTaxnlP9tRf82v6J3Wpr1u0 ibgJ2Aew= X-Gm-Gg: AYBFou3rTCjZk0mVMxFIPVlSPsItVdQf5pGAc9ixHAOVJIOy5T9WlcrtB5NuZ3ctRdd Bwh/EVxHIvnoggSGjD7FX3ywCKuYTsFWlP1qE3OQvRphkEoHgTHXkC86/cPwmTXmskgnJiWQHFv f8WlKexvU97fGGDCwP8Rhc599jEdVhGKuWatI2fwtIowYG1JbxCExgsz9vu7cOhyvNyPEjRJOse UQ9m2frrzPQNnvqw1vskQGe4kWMvQ5ae2bl9OjP1SLm5pXxpufZKPIk/xbulp1EFlDfkHNfigx6 aaxUuHavKA6lgRZy2DE6NF7d80LxXlGpgZNFZEnwDTNcLOra3Ic8tycPo4376Uz8U81KNyFPbjy HAFAY0YpYFL0z4c5WEtSjnC6n2pRhxvPdxO5wKg+DRz8fraQLL4ILenxU7adtD2G09KxecXzZq+ PqEoUqfPN01tEnAAwHrwRUvyIP1SZ9OZuKa/p9WHlmKcV2X08iZLVwYc/yZ+SKjvsZ8AmoSoWsy imQxK9eYckLdpJF5RkHdsxGfroEFXUhZlTB7o+Ab3e5NIa2 X-Received: by 2002:a05:6000:4904:b0:48a:f0cd:8712 with SMTP id ffacd0b85a97d-48dbacf4734mr42722533f8f.50.1792098336029; Thu, 15 Oct 2026 14:05:36 -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 v4 4/5] x86/alternative: Relocate all insn-relative fields Date: Thu, 15 Oct 2026 22:05:29 +0100 Message-Id: <20261015210530.786604-5-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20261015210530.786604-1-andrew.cooper3@citrix.com> References: <20261015210530.786604-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792098336-DFAD487B-2A5D4503/10/78276251493 X-purgate-type: spam X-purgate-size: 3089 Right now, relocation of displacements is restricted to finding 0xe8/e9 as the first byte of the replacement, but this is overly restrictive. Use x86_decode_lite() to find and adjust all insn-relative fields. As with disp8's not leaving the replacemnet block, some disp32's don't either. e.g. the RSB stuffing loop. These stay unmodified. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie v4: * Rebase v3: * Rebase over the split-out of altcall. Substantially simpler. --- xen/arch/x86/alternative.c | 50 +++++++++++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c index 6b5f9c94f6dd..aa7da97f8548 100644 --- a/xen/arch/x86/alternative.c +++ b/xen/arch/x86/alternative.c @@ -341,15 +341,47 @@ static int init_or_livepatch _apply_alternatives(struct alt_instr *start, memcpy(buf, repl, a->repl_len); - /* 0xe8/0xe9 are relative branches; fix the offset. */ - if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 ) - *(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) += (long)repl - (long)orig; + /* + * Walk buf[] and adjust any insn-relative operands which leave the + * replacement block. + */ + if ( a->repl_len ) + { + uint8_t *ip = buf, *repl_end = ip + a->repl_len; + + for ( x86_decode_lite_t res; ip < repl_end; ip += res.len ) + { + int32_t *d32; + const uint8_t *target; + + res = x86_decode_lite(ip, repl_end); + + if ( res.len == 0 ) + { + printk("Alt for %ps [%*ph]\n" + " Unable to decode instruction at +%lu in alternative\n", + ALT_ORIG_PTR(a), a->repl_len, repl, ip - repl); + return -EINVAL; + } + + if ( res.rel_sz != 4 ) + continue; + + d32 = res.rel; + target = ip + res.len + *d32; + + if ( target >= buf && target <= repl_end ) + { + /* + * Target doesn't leave the replacement block. e.g. RSB + * stuffing. Leave it unmodified. + */ + continue; + } + + *d32 += (long)repl - (long)orig; + } + } a->priv = 1; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 21:05:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 21:05:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451120.1666319 (Exim 4.92) (envelope-from ) id 1xHSdu-0001sU-0X; Thu, 15 Oct 2026 21:05:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451120.1666319; Thu, 15 Oct 2026 21:05: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 1xHSdt-0001qj-OQ; Thu, 15 Oct 2026 21:05:37 +0000 Received: by outflank-mailman (input) for mailman id 1451120; Thu, 15 Oct 2026 21:05:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHSds-0001dc-Kj for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:05:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHSds-003e3Q-1l for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 23:05:36 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad13fea-2eae-0a2a0a5409dd-0a2a450b9c44-28 for ; Thu, 15 Oct 2026 23:05:36 +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 6ad1401f-b7e8-0a2a450b0019-d155dd29c165-3 for ; Thu, 15 Oct 2026 23:05:36 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48df4f540ebso707800f8f.3 for ; Thu, 15 Oct 2026 14:05: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-48dfd4f8bd9sm501163f8f.35.2026.10.15.14.05.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 14:05: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=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=1792098335; x=1792703135; 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=TQRAOxA1ogjKOw3/7hZOaSEV5B0G11dKuvdmnA2zrg4=; b=mKk+bcT7omrbQwyrXm4u/BTSJ9EI6B3Rr1lCm+Ku7PsXd4zrYKJLfN+eSerbiq0Fh8 diKDSoyP7ytmUMI9czZMYvBmqkRvdbBFX4FthEpOeBlHaOfrv6IxY7RQmPu92aCZO9vq tdbrWvaDlKgQD8ynY+HOT3XbyrMWhWy1IgHlE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792098335; x=1792703135; 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=TQRAOxA1ogjKOw3/7hZOaSEV5B0G11dKuvdmnA2zrg4=; b=BRKdYCdr0TT4ki/V3NxNOs2tDu7vmuDs4C3m8qCPmVxpRPyg4ZfUhZv4ZOzKvSBcuz bV/UyR19NXtGilGlAH3sVUWX1fZTb314TtxTsjvfOJ+CXSsZPZ/uDWFCn7XJ13mFvq4Q t1UnWRCzBsw8KNGi5V0CKrq2kAtt7J08RRbQWJvYPYN7LqnLVMHa6gIjXjYXx3OgO1aY kIgN0Ft0aESPVrFRYkWC/RH8n/x8uncwA8VhMVOxRkHmX7KqbiWrK7jpZjXfuNZxjaqj eDOwTI4dbbGwtBlvmEaDrNr9kJbohq7lsN9TJDRRZEwMiyIetP8Z8VAGb5T3MkZOdGDO kXZg== X-Gm-Message-State: AFq9FYLWpEOy1NPYdI2UMQfNxmJHUqGyoe2oxK1DLCs6cJ7pqUQ5BiiW zN4KurZyQ4ywzCiZP0QSawYBxugbqil5T9xL4r10LoHiuyUFa7J3FnxQl+K/4LkRZm3dHd59P+N kP1vBhuc= X-Gm-Gg: AYBFou1Ux5iby+LPRl6Nd45wAzo1jk2EqL9RWoKTyrfA25PeNttP8U8O6FOR7LMChd9 OSqjBqX+u/cie9eC/w5qIVzq1KimtatwKMWzP6vTcbTAerPcQMXkkZsRQB394RbZ+aU0+amJyLy IegznF9LSOa8jM3I4Yte4yUsjK6zoDTQURN1lTb+x+Ggdtmt+JpryYhWdQtmX+NQIXu5rQAlexN mJXfVZsAryetZ3c71kl1b7J9mc86LV2WZ/xbqOy6GxzUQaYTyIZ1zWy0M8S2sR0Odbc0+4aAR1H qxQiqk7YapSX072UrNerW1PnseGPwi5lEXaaaHq+z3Tq17IuQFKNMZZ3Fx+eJBujhWBFmbwGdT4 yi2300OuAwZCQCGTiQ1//czL9X3ryI/2kBcMOZMYZFvZWchC6OvIc1+gwoV/hgGcVSZtrdkXbF9 usd2rgKmNjDOXRG5nJF7bUjMA4F93bG3Jje4gx+8W341hhDFs9/9nE1WbWP4EOfKcvx4GbV3P4g lHYSzy0JccZhEvyfFCsuVCUJUh1Gins4xKynwlpZemyEf5N X-Received: by 2002:a5d:5381:0:b0:488:8931:b1b2 with SMTP id ffacd0b85a97d-48dbacdbc17mr29360393f8f.28.1792098335271; Thu, 15 Oct 2026 14:05:35 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 3/5] x86/alternative: Walk all replacements during self tests Date: Thu, 15 Oct 2026 22:05:28 +0100 Message-Id: <20261015210530.786604-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20261015210530.786604-1-andrew.cooper3@citrix.com> References: <20261015210530.786604-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792098336-AB0DD9EA-AB6A1C02/10/78276251493 X-purgate-type: spam X-purgate-size: 2976 When self tests are active, walk all alternative replacements with x86_decode_lite(). This checks that we can decode all instructions, and also lets us check that disp8's don't leave the replacement block as such a case will definitely malfunction. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie v2: * Rebase over API changes in patch 1 * Use +%lu and drop casts * Swap to CONFIG_SELF_TESTS --- xen/arch/x86/alternative.c | 52 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c index a4cadd9b0b79..6b5f9c94f6dd 100644 --- a/xen/arch/x86/alternative.c +++ b/xen/arch/x86/alternative.c @@ -16,6 +16,7 @@ #include #include #include +#include #define MAX_PATCH_LEN (255-1) @@ -578,6 +579,57 @@ static void __init _alternative_instructions(unsigned int what) void __init alternative_instructions(void) { arch_init_ideal_nops(); + + /* + * Walk all replacement instructions with x86_decode_lite(). This checks + * both that we can decode all instructions within the replacement, and + * that any near branch with a disp8 stays within the alternative itself. + */ + if ( IS_ENABLED(CONFIG_SELF_TESTS) ) + { + struct alt_instr *a; + + for ( a = __alt_instructions; + a < __alt_instructions_end; ++a ) + { + void *repl = ALT_REPL_PTR(a); + void *ip = repl, *end = ip + a->repl_len; + + if ( !a->repl_len ) + continue; + + for ( x86_decode_lite_t res; ip < end; ip += res.len ) + { + const int8_t *d8; + const void *target; + + res = x86_decode_lite(ip, end); + + if ( res.len == 0 ) + { + printk("Alt for %ps [%*ph]\n", + ALT_ORIG_PTR(a), a->repl_len, repl); + panic(" Unable to decode instruction at +%lu in alternative\n", + ip - repl); + } + + if ( res.rel_sz != 1 ) + continue; + + d8 = res.rel; + target = ip + res.len + *d8; + + if ( target < repl || target > end ) + { + printk("Alt for %ps [%*ph]\n", + ALT_ORIG_PTR(a), a->repl_len, repl); + panic(" 'JMP/Jcc disp8' at +%lu leaves alternative block\n", + ip - repl); + } + } + } + } + _alternative_instructions(ALT_INSNS); } -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 21:05:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 21:05:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451118.1666307 (Exim 4.92) (envelope-from ) id 1xHSdt-0001kO-Bp; Thu, 15 Oct 2026 21:05:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451118.1666307; Thu, 15 Oct 2026 21:05: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 1xHSdt-0001kG-8M; Thu, 15 Oct 2026 21:05:37 +0000 Received: by outflank-mailman (input) for mailman id 1451118; Thu, 15 Oct 2026 21:05:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHSdr-0001Xc-Fk for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:05:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHSdq-003e3Q-Sx for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 23:05:34 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad13ffb-2eae-0a2a0a5409dd-0a2a4503a4b8-20 for ; Thu, 15 Oct 2026 23:05:34 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1401e-fae8-0a2a45030019-d155dd29a90a-3 for ; Thu, 15 Oct 2026 23:05:34 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48dfdd431dcso13316f8f.1 for ; Thu, 15 Oct 2026 14:05: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-48dfd4f8bd9sm501163f8f.35.2026.10.15.14.05.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 14:05: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: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=1792098334; x=1792703134; 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=I7s5tVz0MwtGzZyVlACkfNL1uI1i80HieuLj+FjBvBc=; b=LsrovbqZmN4bJySFxUh2OwqTSt5LmP9VSt5Hlt7nT7y9OrA1nxMRUAKFV2Us3egD5e OOtkbHtfzOqwptnfr+yDOdNH0R/aqTpfsRwKJlIWVseur6CKWLlRXcK05x7fpB3C9D5/ NCyztAeApxrACSWLouJzhdlInB6s8D5UtUAQg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792098334; x=1792703134; 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=I7s5tVz0MwtGzZyVlACkfNL1uI1i80HieuLj+FjBvBc=; b=PRYbj+DFC3qEV8i91nMBM2BHhd6AkXuZFtPpLRW8rqjntIpA87WWM6Z3Uo5CwKR60k DCvKTAkjVe9rEGFzGKrmCP2vNGi9bKhnx/LasjimyxZoi8JJyyXA034ID1k1q1QN9mxv 6Z44dOAVFz/bFwpJ5kC3hiCc8qU16ycv6PNSQ1GPkx7sVm2kGTkpDBqJTA9122INBrpJ cK4LLJRRQ4MpUcgy8bMHdxErCW4lv3zFLl346Q/IGpPkA/FtN8zTsLIaDyjbkN37kXpl c4iznDwZbqRZ27sDD5wM7uWHCzUFCqhIK5yuHabsW2pTgHVz7kA6VCg9bZbCCoyPnxHI wMaw== X-Gm-Message-State: AFq9FYKJP+lt0isLMavCQCk+xk9LYdS7D7xQF5pr8B1Wi4j45yfwiEsq BRoqNgN9vbDKiif+gnB6vHHa+iQOeM/UrmrgZMezKNT9diggJU+E1oJFOGQd9wBNeBKaMxTZfHa J0rRl/BQ= X-Gm-Gg: AYBFou3FWeZYugf6A32ynjqqBcPKJrjNU52tWAB18Aldoe8fXWtJmMfqd2m/1qOjPzy jqrR7JGezH369Ggd/V/gYW/59KjwY8LFCqwFd2J84305vnyc1aclhnTnoT6ISne+BsZhgB5h14/ Jz/qNZ/AMzbtvsaCT3GobvUD83PISWzzo/G+UYO1sZ4E5bYo1kPhYuiLAA/aiqkXzPKLxUnDsCk IGb3GIyM/+LC9FfpyS4JPsNVeGi7/oldzdMrWsamr+BaMINk52+5B0ykq6WaX82ferOp378iGZL 6rhiudeHa/DFsg2i4VHSYLQ1UwRq2itWiIK/1VpjCy6SZsN+67z36bfkICBMkiouTiT3YaWxEkq pTN3PXRD7bmB46/RTGXQ+rorg018IY+lTigG55ch40uEIllSBQ2sht3L/sCyq2qwA5j05BRqCVB /Lyn19BlAOnIo0Tk2+DjtxpyRoP16r007/hpfB6ehwgMT3oRyB/Zqu+agPVqEalskU9chkWBIRk NmFcaHSUHrlwMxUHKc5S1WJzvHnKP7UIt2WCUmUesQlAFGy X-Received: by 2002:a05:6000:250f:b0:488:8566:9986 with SMTP id ffacd0b85a97d-48dfadf3358mr3057663f8f.2.1792098334102; Thu, 15 Oct 2026 14:05:34 -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 v4 1/5] x86/emul: Introduce x86_decode_lite() Date: Thu, 15 Oct 2026 22:05:26 +0100 Message-Id: <20261015210530.786604-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20261015210530.786604-1-andrew.cooper3@citrix.com> References: <20261015210530.786604-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/1792098334-77EC24E9-77D37672/10/78276251493 X-purgate-type: spam X-purgate-size: 14993 In order to relocate all IP-relative fields in an alternative replacement block, we need to decode the instructions enough to obtain their length and any relative fields. Full x86_decode() is far too heavyweight, so introduce a minimal form which can make several simplifying assumptions. This a mostly-complete decoder for integer instruction in the onebyte and twobyte maps. Some instructions are intentionally unrecognised, as finding them in an alternative is more likely to be a bug than intentional. Some instruction groups and prefixes are unimplemented to reduce decode complexity, as this will be a fasthpath during patching. This logic can decode all alternative blocks that exist in Xen right now. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie v4: * Optimise switch ( osize ) * Optimise SIB * Don't mention "replacement block" in function comment. v3: * Rearrange decode tables to satisfy comment requests without splitting * Recognise UDB now it's used by Xen * Fix MISRA violations * Misc other changes v2: * Switch to 0 on failure, rel_sz in bytes * Mostly complete the integer instructions; paird with userspace harness * Put in .init when !CONFIG_LIVEPATCH --- xen/arch/x86/x86_emulate/Makefile | 6 + xen/arch/x86/x86_emulate/decode-lite.c | 331 +++++++++++++++++++++++++ xen/arch/x86/x86_emulate/x86_emulate.h | 14 ++ 3 files changed, 351 insertions(+) create mode 100644 xen/arch/x86/x86_emulate/decode-lite.c diff --git a/xen/arch/x86/x86_emulate/Makefile b/xen/arch/x86/x86_emulate/Makefile index 295e602f6b86..679bddbb1584 100644 --- a/xen/arch/x86/x86_emulate/Makefile +++ b/xen/arch/x86/x86_emulate/Makefile @@ -17,3 +17,9 @@ obj-y += decode.o obj-$(CONFIG_HVM) += fpu.o obj-y += util.o obj-y += util-xen.o + +ifeq ($(CONFIG_LIVEPATCH),y) +obj-y += decode-lite.o +else +obj-bin-y += decode-lite.init.o +endif diff --git a/xen/arch/x86/x86_emulate/decode-lite.c b/xen/arch/x86/x86_emulate/decode-lite.c new file mode 100644 index 000000000000..f0ab4d38c81b --- /dev/null +++ b/xen/arch/x86/x86_emulate/decode-lite.c @@ -0,0 +1,331 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifdef __XEN__ +# include +#endif + +#include "private.h" + +#undef ModRM + +/* + * Bare minimum x86 instruction decoder to parse the alternative replacement + * instructions and locate the IP-relative references that may need updating. + * + * These are: + * - disp8/32 from near direct branches + * - RIP-relative memory references + * + * The following simplifications are used: + * - All code is 64bit, the instruction stream is well formed and safe to + * read. + * - Instruction groups and prefixes not used by Xen's current alternatives + * are not implemented in order to reduce the decode complexity. + * - Certain instructions are intentionally not recognised, when it is more + * likely for their presence to be an error than intentional. + * + * Inputs: + * @ip The position to start decoding from. + * @end End of the code block. Exceeding this is considered an error. + * + * Returns: x86_decode_lite_t + * - On failure, length of 0. + * - On success, length > 0. For rel_sz > 0, rel points at the relative + * field in the instruction stream. + */ +x86_decode_lite_t init_or_livepatch x86_decode_lite(void *ip, const void *end) +{ +#define Imm8 (1 << 0) +#define Imm (1 << 1) +#define Moffs (1 << 2) +#define Branch (1 << 5) /* Near direct branches, which have a displacement */ +#define ModRM (1 << 6) +#define Known (1 << 7) + + static const uint8_t init_or_livepatch_const onebyte[256] = { + +#define ALU_OPS(x) \ + [(x) + 0] = (Known|ModRM), \ + [(x) + 1] = (Known|ModRM), \ + [(x) + 2] = (Known|ModRM), \ + [(x) + 3] = (Known|ModRM), \ + [(x) + 4] = (Known|Imm8), \ + [(x) + 5] = (Known|Imm) + + ALU_OPS(0x00) /* ADD */, ALU_OPS(0x08) /* OR */, + ALU_OPS(0x10) /* ADC */, ALU_OPS(0x18) /* SBB */, + ALU_OPS(0x20) /* AND */, ALU_OPS(0x28) /* SUB */, + ALU_OPS(0x30) /* XOR */, ALU_OPS(0x38) /* CMP */, + +#undef ALU_OPS + + [0x50 ... 0x5f] = (Known), /* PUSH/POP %reg */ + + [0x62] = 0, /* BOUND, but also EVEX prefix, not implemented. */ + [0x63] = (Known|ModRM), /* MOVSxd */ + + [0x68] = (Known|Imm), /* PUSH $imm */ + [0x69] = (Known|ModRM|Imm), /* IMUL $imm */ + [0x6a] = (Known|Imm8), /* PUSH $imm8 */ + [0x6b] = (Known|ModRM|Imm8), /* PUSH $imm8 */ + [0x6c ... 0x6f] = (Known), /* INS/OUTS */ + [0x70 ... 0x7f] = (Known|Branch|Imm8), /* Jcc disp8 */ + [0x80] = (Known|ModRM|Imm8), /* Grp1 */ + [0x81] = (Known|ModRM|Imm), /* Grp1 */ + + [0x83] = (Known|ModRM|Imm8), /* Grp1 */ + [0x84 ... 0x8e] = (Known|ModRM), /* TEST/XCHG/MOV/MOV-SREG/LEA */ + [0x8f] = 0, /* Grp1A - POP but also XOP prefix, not implemented. */ + [0x90 ... 0x99] = (Known), /* NOP/XCHG %rAX/CLTQ/CQTO */ + + [0x9b ... 0x9f] = (Known), /* FWAIT/PUSHF/POPF/SAHF/LAHF */ + [0xa0 ... 0xa3] = (Known|Moffs), /* MOVABS */ + [0xa4 ... 0xa7] = (Known), /* MOVS/CMPS */ + [0xa8] = (Known|Imm8), /* TEST %al */ + [0xa9] = (Known|Imm), /* TEST %rAX */ + [0xaa ... 0xaf] = (Known), /* STOS/LODS/SCAS */ + [0xb0 ... 0xb7] = (Known|Imm8), /* MOV $imm8, %reg */ + [0xb8 ... 0xbf] = (Known|Imm), /* MOV $imm{16,32,64}, %reg */ + [0xc0 ... 0xc1] = (Known|ModRM|Imm8), /* Grp2 (ROL..SAR $imm8, %reg) */ + + [0xc3] = (Known), /* RET */ + [0xc4 ... 0xc5] = 0, /* LES/LDS but also VEX prefixes, not implemented. */ + [0xc6] = (Known|ModRM|Imm8), /* Grp11, Further ModRM decode */ + [0xc7] = (Known|ModRM|Imm), /* Grp11, Further ModRM decode */ + + [0xcb ... 0xcc] = (Known), /* LRET/INT3 */ + [0xcd] = (Known|Imm8), /* INT $imm8 */ + + [0xd0 ... 0xd3] = (Known|ModRM), /* Grp2 (ROL..SAR {$1,%cl}, %reg) */ + + [0xd6] = (Known), /* UDB */ + + [0xe4 ... 0xe7] = (Known|Imm8), /* IN/OUT $imm8 */ + [0xe8 ... 0xe9] = (Known|Branch|Imm), /* CALL/JMP disp32 */ + + [0xeb] = (Known|Branch|Imm8), /* JMP disp8 */ + [0xec ... 0xef] = (Known), /* IN/OUT %dx */ + + [0xf1] = (Known), /* ICEBP */ + + [0xf4] = (Known), /* HLT */ + [0xf5] = (Known), /* CMC */ + [0xf6 ... 0xf7] = (Known|ModRM), /* Grp3, Further ModRM decode */ + [0xf8 ... 0xfd] = (Known), /* CLC ... STD */ + [0xfe ... 0xff] = (Known|ModRM), /* Grp4 */ + }; + static const uint8_t init_or_livepatch_const twobyte[256] = { + [0x00 ... 0x03] = (Known|ModRM), /* Grp6/Grp7/LAR/LSL */ + + [0x0b] = (Known), /* UD2 */ + + [0x18 ... 0x1f] = (Known|ModRM), /* Grp16 (Hint Nop) */ + [0x20 ... 0x23] = (Known|ModRM), /* MOV %cr/%dr */ + + [0x30 ... 0x33] = (Known), /* WRMSR/RDTSC/RDMSR/RDPMC */ + + [0x40 ... 0x4f] = (Known|ModRM), /* CMOVcc */ + + [0x80 ... 0x8f] = (Known|Branch|Imm), /* Jcc disp32 */ + [0x90 ... 0x9f] = (Known|ModRM), /* SETcc */ + + [0xa0 ... 0xa2] = (Known), /* PUSH/POP %fs/CPUID */ + [0xa3] = (Known|ModRM), /* BT */ + [0xa4] = (Known|ModRM|Imm8), /* SHLD $imm8 */ + [0xa5] = (Known|ModRM), /* SHLD %cl */ + + [0xa8 ... 0xa9] = (Known), /* PUSH/POP %gs */ + + [0xab] = (Known|ModRM), /* BTS */ + [0xac] = (Known|ModRM|Imm8), /* SHRD $imm8 */ + [0xad ... 0xaf] = (Known|ModRM), /* SHRD %cl/Grp15/IMUL */ + + [0xb0 ... 0xb9] = (Known|ModRM), /* CMPXCHG/LSS/BTR/LFS/LGS/MOVZxx/POPCNT/UD1 */ + [0xba] = (Known|ModRM|Imm8), /* Grp8 */ + [0xbb ... 0xbf] = (Known|ModRM), /* BTC/BSF/BSR/MOVSX */ + [0xc0 ... 0xc1] = (Known|ModRM), /* XADD */ + [0xc7] = (Known|ModRM), /* Grp9 */ + [0xc8 ... 0xcf] = (Known), /* BSWAP */ + }; + + void *start = ip, *rel = NULL; + unsigned int opc, rel_sz = 0; + uint8_t b, d, rex = 0, osize = 4; + +#define OPC_TWOBYTE (1 << 8) + + /* Mutates IP, uses END. */ +#define FETCH(ty) \ + ({ \ + ty _val; \ + \ + if ( (ip + sizeof(ty)) > end ) \ + goto overrun; \ + _val = *(ty *)ip; \ + ip += sizeof(ty); \ + _val; \ + }) + + for ( ;; ) /* Prefixes */ + { + switch ( b = FETCH(uint8_t) ) + { + case 0x26: /* ES override */ + case 0x2e: /* CS override */ + case 0x36: /* DS override */ + case 0x3e: /* SS override */ + case 0x64: /* FS override */ + case 0x65: /* GS override */ + case 0xf0: /* LOCK */ + case 0xf2: /* REPNE */ + case 0xf3: /* REP */ + break; + + case 0x66: /* Operand size override */ + osize = 2; + break; + + /* case 0x67: Address size override, not implemented */ + + case 0x40 ... 0x4f: /* REX */ + rex = b; + continue; + + default: + goto prefixes_done; + } + rex = 0; /* REX cancelled by subsequent legacy prefix. */ + } + prefixes_done: + + if ( rex & REX_W ) + osize = 8; + + /* Fetch the main opcode byte(s) */ + if ( b == 0x0f ) + { + b = FETCH(uint8_t); + opc = OPC_TWOBYTE | b; + + d = twobyte[b]; + } + else + { + opc = b; + d = onebyte[b]; + } + + if ( unlikely(!(d & Known)) ) + goto unknown; + + if ( d & ModRM ) + { + uint8_t modrm = FETCH(uint8_t); + uint8_t mod = modrm >> 6; + uint8_t reg = (modrm >> 3) & 7; + uint8_t rm = modrm & 7; + + /* ModRM/SIB decode */ + if ( mod == 0 && rm == 5 ) /* RIP relative */ + { + rel = ip; + rel_sz = 4; + FETCH(int32_t); + } + else if ( mod != 3 && rm == 4 ) /* SIB */ + { + uint8_t sib = FETCH(uint8_t); + uint8_t base = sib & 7; + + if ( mod == 0 && base == 5 ) + FETCH(int32_t); + } + + if ( mod == 1 ) /* disp8 */ + FETCH(int8_t); + else if ( mod == 2 ) /* disp32 */ + FETCH(int32_t); + + /* ModRM based decode adjustements */ + switch ( opc ) + { + case 0xc7: /* Grp11 XBEGIN is a near direct branch. */ + if ( modrm == 0xf8 ) + d |= Branch; + break; + + case 0xf6: /* Grp3 TEST(s) have extra Imm8 */ + if ( reg == 0 || reg == 1 ) + d |= Imm8; + break; + + case 0xf7: /* Grp3 TEST(s) have extra Imm */ + if ( reg == 0 || reg == 1 ) + d |= Imm; + break; + } + } + + if ( d & Branch ) + { + /* + * We don't tolerate 66-prefixed call/jmp in alternatives. Some are + * genuinely decoded differently between Intel and AMD CPUs. + * + * We also don't implement APX instructions, so don't have to cope + * with JMPABS which is the first branch to have an 8-byte immediate. + */ + if ( osize < 4 ) + goto bad_osize; + + rel = ip; + rel_sz = (d & Imm8) ? 1 : 4; + } + + if ( d & (Imm | Imm8 | Moffs) ) + { + if ( d & Imm8 ) + osize = 1; + else if ( d & Moffs ) + osize = 8; + else if ( osize == 8 && !(opc >= 0xb8 && opc <= 0xbf) ) + osize = 4; + + switch ( osize ) + { + case 1: + case 2: + case 4: + case 8: + if ( ip + osize > end ) + goto overrun; + ip += osize; + break; + + default: goto bad_osize; + } + } + + return (x86_decode_lite_t){ ip - start, rel_sz, rel }; + + bad_osize: + printk(XENLOG_ERR "%s() Bad osize %u in %*ph\n", + __func__, osize, + (int)(unsigned long)(end - start), start); + return (x86_decode_lite_t){ 0, 0, NULL }; + + unknown: + printk(XENLOG_ERR "%s() Unknown opcode in %*ph <%02x> %*ph\n", + __func__, + (int)(unsigned long)(ip - 1 - start), start, b, + (int)(unsigned long)(end - ip), ip); + return (x86_decode_lite_t){ 0, 0, NULL }; + + overrun: + printk(XENLOG_ERR "%s() Decode overrun, got %*ph\n", + __func__, + (int)(unsigned long)(end - start), start); + return (x86_decode_lite_t){ 0, 0, NULL }; + +#undef FETCH +} diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h b/xen/arch/x86/x86_emulate/x86_emulate.h index 4539b14c1534..a2f9b5e2a2cf 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.h +++ b/xen/arch/x86/x86_emulate/x86_emulate.h @@ -769,4 +769,18 @@ static inline void x86_emul_reset_event(struct x86_emulate_ctxt *ctxt) ctxt->event = (struct x86_event){}; } +/* + * x86_decode_lite(). Very minimal decoder for managing alternatives. + * + * @len is 0 on error, or nonzero on success. If the instruction has a + * relative field, @rel_sz is nonzero, and @rel points at the field. + */ +typedef struct { + uint8_t len; + uint8_t rel_sz; /* bytes: 0, 1 or 4 */ + void *rel; +} x86_decode_lite_t; + +x86_decode_lite_t x86_decode_lite(void *ip, const void *end); + #endif /* __X86_EMULATE_H__ */ -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 21:05:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 21:05:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451122.1666344 (Exim 4.92) (envelope-from ) id 1xHSdw-0002a7-0t; Thu, 15 Oct 2026 21:05:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451122.1666344; Thu, 15 Oct 2026 21:05: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 1xHSdv-0002Zy-Rq; Thu, 15 Oct 2026 21:05:39 +0000 Received: by outflank-mailman (input) for mailman id 1451122; Thu, 15 Oct 2026 21:05:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHSdu-0001tY-3U for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:05:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHSdt-00Gq26-GR for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 23:05:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad14008-bab6-0a2a0a5309dd-0a2a4501da3a-22 for ; Thu, 15 Oct 2026 23:05:37 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad14021-5984-0a2a45010019-d155dd2dd085-3 for ; Thu, 15 Oct 2026 23:05:37 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48de6a62a4cso2776218f8f.2 for ; Thu, 15 Oct 2026 14:05: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-48dfd4f8bd9sm501163f8f.35.2026.10.15.14.05.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 14:05: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: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=1792098337; x=1792703137; 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=SjwuBsICIK/H/Y6+HpcAgCloLVRbw36ixgETurBOkCw=; b=Zv4Y6+tnJaPBOM4knSBXe9kwIRHvZJybRy65MYAfLgjKnQKFZIBNwmMr2HeTUAnKGy qFmTf7Clbo+S9HZs/wQst/dxskuaSjKfquk9awCb8scqaMDaLaLFk2z1HLABEi+bJ5Bj hCuUiAkwqGbi373JZf8UK7fxA0mRgTDNiF+Qc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792098337; x=1792703137; 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=SjwuBsICIK/H/Y6+HpcAgCloLVRbw36ixgETurBOkCw=; b=eYQgtWgrYbJV5UgKHHnLPWWA7FSVVgP1qyMV5X5Fn8f8v010xA+wAnlQaF5dR+fb7O 8mmNilleuCxJ4GJk4n3AwckI9lzP5TxeD8kQAh9GyidzUIDXkz0jEWvgJumvZ03IOEyy SB4P0G93x5Fac2k/LklaIn1GxC2MtMlqhYlxDjaZsnuy3pKjSGs9JQ74RZlErAlhi7xH ShKTtsKavOTcxfKTQYMRWfunhhDR8rKUaGEW9PicMheky4KcZAFz4YNUqeyg77AURcW6 rmM7elO8ETFn2A0lCllJvftZzTXlePHsSQ2mokQwUqu4Ym1RYofPMjgTLEuDvJ8II47f F0ew== X-Gm-Message-State: AFq9FYJWfO0skGiCQ2dhE7ZDejgmMVOxeBPsvIBqXmgRRm1sqaJ9vB2O yUFr8A14c4riw8GamhCk7P6zXSFa5WRmABq1Aa9g/K2KFRdhIPb/wgNR7+KwMAKtQUot0Hf543w QybBuE8U= X-Gm-Gg: AYBFou3XZvs24ACXvHD6m/PTKn0h1+qJZ7VRB0zCDNoqMIbCoMU1W/jU3v42qxHwhWX BHJi2sswBiM+0YH3u9GeUoFQGdeuwWptTmG5paST788e9B1eVatkoa19czC0NbFkiJXQoVKvl6Q i3WxS2ngIqEW3uXsrIf7QTwRxRVpcMhgDL9bjHYPIrpAk3M3gTpBpBO4TVUwR3QTj3tVySzT80O dUljBge45Sn7dA5uCvpoLgmnILE8sk/ZdVyx336cG2+16j9RcMQCW4JzQJMIy4BL+KAsCHEIe4O UxbDKu4R4a0eKOatwBOFT1tvFyWT+JTDwguf1RMZ/ffSp9LR8D7NCRXSAtitL9FlpRETZ9eJVQO vNKcN5K/0ev4PdijYw2Q5QXij+rJqvBdTmOTkxLFqDbLGb3k2/Rx12GoQWLmoIuoKwwDgNWsVTF YZe0tm/KILbyMThXUIV7KppY+Y+zu1698vyIvCbIWIp+MujbmuQzh9A6OkxyxTJViB5JLEeoxE/ bYs3XzI8CdU4OrVsBLLqyo/tjGtUqoh5eEHYCW5BSMjm2UT X-Received: by 2002:a5d:588e:0:b0:48a:fcf9:acb5 with SMTP id ffacd0b85a97d-48dba787752mr39811513f8f.2.1792098336646; Thu, 15 Oct 2026 14:05:36 -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 v4 5/5] x86/spec-ctrl: Introduce and use DO_COND_BHB_SEQ Date: Thu, 15 Oct 2026 22:05:30 +0100 Message-Id: <20261015210530.786604-6-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20261015210530.786604-1-andrew.cooper3@citrix.com> References: <20261015210530.786604-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792098337-1E27A757-1931DB85/10/78276251493 X-purgate-type: spam X-purgate-size: 4495 Now that alternatives can fix up call displacements even when they're not the first instruction of the replacement, move the SCF_entry_bhb conditional inside the replacement block. This removes a conditional branch from the fastpaths of BHI-unaffected hardware. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie --- xen/arch/x86/hvm/vmx/entry.S | 12 +++---- xen/arch/x86/include/asm/spec_ctrl_asm.h | 43 +++++++++++++----------- 2 files changed, 30 insertions(+), 25 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S index cebc70064048..76508c0de2f3 100644 --- a/xen/arch/x86/hvm/vmx/entry.S +++ b/xen/arch/x86/hvm/vmx/entry.S @@ -59,12 +59,12 @@ FUNC(vmx_asm_vmexit_handler) * Clear the BHB to mitigate BHI. Used on eIBRS parts, and uses RETs * itself so must be after we've perfomed all the RET-safety we can. */ - testb $SCF_entry_bhb, CPUINFO_scf(%rsp) - jz .L_skip_bhb - ALTERNATIVE_2 "", \ - "call clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ - "call clear_bhb_tsx", X86_SPEC_BHB_TSX -.L_skip_bhb: + .macro VMX_BHB_SEQ fn:req + DO_COND_BHB_SEQ \fn scf=CPUINFO_scf(%rsp) + .endm + ALTERNATIVE_2 "", \ + "VMX_BHB_SEQ fn=clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ + "VMX_BHB_SEQ fn=clear_bhb_tsx", X86_SPEC_BHB_TSX ALTERNATIVE "lfence", "", X86_SPEC_NO_LFENCE_ENTRY_VMX /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ diff --git a/xen/arch/x86/include/asm/spec_ctrl_asm.h b/xen/arch/x86/include/asm/spec_ctrl_asm.h index abb64ad2b7f9..780ec57f4553 100644 --- a/xen/arch/x86/include/asm/spec_ctrl_asm.h +++ b/xen/arch/x86/include/asm/spec_ctrl_asm.h @@ -92,6 +92,21 @@ .L\@_skip: .endm +.macro DO_COND_BHB_SEQ fn:req, scf=%bl +/* + * Requires SCF (defaults to %rbx), fn=clear_bhb_{loops,tsx} + * Clobbers %rax, %rcx + * + * Conditionally use a BHB clearing software sequence. + */ + testb $SCF_entry_bhb, \scf + jz .L\@_skip_bhb + + call \fn + +.L\@_skip_bhb: +.endm + .macro DO_OVERWRITE_RSB tmp=rax, xu /* * Requires nothing @@ -277,12 +292,9 @@ * Clear the BHB to mitigate BHI. Used on eIBRS parts, and uses RETs * itself so must be after we've perfomed all the RET-safety we can. */ - testb $SCF_entry_bhb, %bl - jz .L\@_skip_bhb - ALTERNATIVE_2 "", \ - "call clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ - "call clear_bhb_tsx", X86_SPEC_BHB_TSX -.L\@_skip_bhb: + ALTERNATIVE_2 "", \ + "DO_COND_BHB_SEQ clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ + "DO_COND_BHB_SEQ clear_bhb_tsx", X86_SPEC_BHB_TSX ALTERNATIVE "lfence", "", X86_SPEC_NO_LFENCE_ENTRY_PV .endm @@ -322,12 +334,9 @@ ALTERNATIVE "", __stringify(DO_SPEC_CTRL_ENTRY maybexen=1), \ X86_FEATURE_SC_MSR_PV - testb $SCF_entry_bhb, %bl - jz .L\@_skip_bhb - ALTERNATIVE_2 "", \ - "call clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ - "call clear_bhb_tsx", X86_SPEC_BHB_TSX -.L\@_skip_bhb: + ALTERNATIVE_2 "", \ + "DO_COND_BHB_SEQ clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ + "DO_COND_BHB_SEQ clear_bhb_tsx", X86_SPEC_BHB_TSX ALTERNATIVE "lfence", "", X86_SPEC_NO_LFENCE_ENTRY_INTR .endm @@ -433,13 +442,9 @@ * Clear the BHB to mitigate BHI. Used on eIBRS parts, and uses RETs * itself so must be after we've perfomed all the RET-safety we can. */ - testb $SCF_entry_bhb, %bl - jz .L\@_skip_bhb - - ALTERNATIVE_2 "", \ - "call clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ - "call clear_bhb_tsx", X86_SPEC_BHB_TSX -.L\@_skip_bhb: + ALTERNATIVE_2 "", \ + "DO_COND_BHB_SEQ clear_bhb_loops", X86_SPEC_BHB_LOOPS, \ + "DO_COND_BHB_SEQ clear_bhb_tsx", X86_SPEC_BHB_TSX lfence .endm -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 21:05:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 21:05:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451117.1666298 (Exim 4.92) (envelope-from ) id 1xHSds-0001Xv-4f; Thu, 15 Oct 2026 21:05:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451117.1666298; Thu, 15 Oct 2026 21:05: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 1xHSds-0001Xn-26; Thu, 15 Oct 2026 21:05:36 +0000 Received: by outflank-mailman (input) for mailman id 1451117; Thu, 15 Oct 2026 21:05:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHSdr-0001Xb-Ed for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:05:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHSdq-003e3Q-JU for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 23:05:34 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad14007-2eae-0a2a0a5409dd-0a2a4505d1bc-24 for ; Thu, 15 Oct 2026 23:05:34 +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 6ad1401e-4cb1-0a2a45050019-d155dd2ee9f0-3 for ; Thu, 15 Oct 2026 23:05:34 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48bbb06e746so1199061f8f.3 for ; Thu, 15 Oct 2026 14:05: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-48dfd4f8bd9sm501163f8f.35.2026.10.15.14.05.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 14:05: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=1792098334; x=1792703134; 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=1jLDJ1dB+NAtq9SWX+068kA/fTXsIbgXnYxnbgLHBbY=; b=NsAqYFLe5nhSVsAQDAuFkzLljfojpbJRO65jyoMVehc5OW9VVuREdgJ92ZIsaQo+Fj JJj+jwCCPyvDBrAmj8fVTZw3Z+AnLcryEyGOf8Y7hATt2IFWM269ue7tLnKKBG1L079H Kkp3OZ48KLOMqvrTFMWdlC70zOTzz5bnSaCM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792098334; x=1792703134; 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=1jLDJ1dB+NAtq9SWX+068kA/fTXsIbgXnYxnbgLHBbY=; b=gKiMdaQ7pXV1Xrt55cRobu1OiPDqcuL1Zm/6rJJcNeY8x3DbaVUday0AutR5ZhjLsI mUoi4BX/KKvyV+YkKfAJRC/5WQhaC68Uq7aN7iIstqOScf3XhZwxLK2JK8EhAaq5YzJz UolvvnyTT24dEjBukM7BIaEL0j5SzP+Z0losThjlng3UR0wF94MweWo/MnFSHfArSspA s8Q3IjBqKzc3unQcx06ItZctvWzo6yQ88s+5+P3Nu8y/ZKrcLVFk0dDb7qpYHAW7ySVy 1qoAD9rfU7dthBPx9zUHnO7JA2gkapohfvp7E4/4eDaLzTg1CdBdEQ6mv+LviYnHR6mq WG4g== X-Gm-Message-State: AFq9FYKYQDofJpjSMwef4LNvJQnyTmkdZQFeKTaYHP7biEZltpFqgm0r NrBLhL7lcgolAlRpO5bWgZCDKQXQt/S5QaNzkFqiWn6YvGUuXUPHa7RZZ6OgWFCa/oUY4PvtboJ cUKk4BiU= X-Gm-Gg: AYBFou14hmDdxjW7OyHD7HA8chSDFmIVaDM9BA84K0KnkTWH4FA6p78iYQtEQ0Zk9v4 xjKB15nb0U93XZVbdIK+uhwMwVbjXz6zCuliiDQkpopE53vXQvn7ePhww3rTpMGUsGcpIc1GYuD g2uIRDxGyk+3I1gaHpYqRqS0elNuV5OGMssfn87imtKWReZAUXfIXvbAlyYDSzrDedELelyo+Ud gNqKOnbuC9o6K+++WGTQlChVaOTMs48nR9mpp9rrrl8yHdqu6ertBRmv7actx1Wg/Eft2dLx8ua ya2o3J8VZg0QwSYxowDgEciWlbGR7Z6ilHOvypfwEkcWfHcEG99QynRGYW1GH5t81n1TRxRb+2i GnSXLMgY0bgdm73J/wY2vizhqeoBnBxv1PUxp0O9xQqGAx9OqcBBkxO/b56lNw5mQjr3IGG9FR1 n8NnbzyQlyHk0JsVvsl9zNugMZFfX9mn/a33aajCPcceUstqRaF/EH3llR0WvmiCPSGSbDdcFgA OnCMDdOQf04ExfdIekrMw22hGw5scJ9ICAOHdUziNe5B6wJmjiMhb+tsTA= X-Received: by 2002:a05:600d:82c1:b0:4a1:6a10:4dc8 with SMTP id 5b1f17b1804b1-4a1bd175fa1mr115844435e9.28.1792098333490; Thu, 15 Oct 2026 14:05: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 v4 0/5] x86/alternatives: Adjust all insn-relative fields Date: Thu, 15 Oct 2026 22:05:25 +0100 Message-Id: <20261015210530.786604-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/1792098334-F56AD2A1-23010FFF/0/0 X-purgate-type: clean X-purgate-size: 1785 Alternatives have had a reasonably severe restriction since their introduction. This has been the source of several bugs, and several inefficiencies particularly in the speculative safety paths. https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2952556080 Andrew Cooper (5): x86/emul: Introduce x86_decode_lite() tests/x86: Introduce a userspace test harness for x86_decode_lite() x86/alternative: Walk all replacements during self tests x86/alternative: Relocate all insn-relative fields x86/spec-ctrl: Introduce and use DO_COND_BHB_SEQ tools/tests/Makefile | 1 + tools/tests/x86-decode-lite/.gitignore | 1 + tools/tests/x86-decode-lite/Makefile | 56 ++ tools/tests/x86-decode-lite/insns.S | 711 ++++++++++++++++++++++ tools/tests/x86-decode-lite/macro-magic.h | 62 ++ tools/tests/x86-decode-lite/main.c | 113 ++++ tools/tests/x86-decode-lite/x86-emulate.h | 29 + xen/arch/x86/alternative.c | 102 +++- xen/arch/x86/hvm/vmx/entry.S | 12 +- xen/arch/x86/include/asm/spec_ctrl_asm.h | 43 +- xen/arch/x86/x86_emulate/Makefile | 6 + xen/arch/x86/x86_emulate/decode-lite.c | 331 ++++++++++ xen/arch/x86/x86_emulate/x86_emulate.h | 14 + 13 files changed, 1447 insertions(+), 34 deletions(-) create mode 100644 tools/tests/x86-decode-lite/.gitignore create mode 100644 tools/tests/x86-decode-lite/Makefile create mode 100644 tools/tests/x86-decode-lite/insns.S create mode 100644 tools/tests/x86-decode-lite/macro-magic.h create mode 100644 tools/tests/x86-decode-lite/main.c create mode 100644 tools/tests/x86-decode-lite/x86-emulate.h create mode 100644 xen/arch/x86/x86_emulate/decode-lite.c -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 21:05:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 21:05:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451119.1666313 (Exim 4.92) (envelope-from ) id 1xHSdt-0001mq-LH; Thu, 15 Oct 2026 21:05:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451119.1666313; Thu, 15 Oct 2026 21:05: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 1xHSdt-0001md-FZ; Thu, 15 Oct 2026 21:05:37 +0000 Received: by outflank-mailman (input) for mailman id 1451119; Thu, 15 Oct 2026 21:05:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHSds-0001Xs-8m for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:05:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHSdr-00Gq26-Lt for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 23:05:35 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad14003-bab6-0a2a0a5309dd-0a2a45089e60-24 for ; Thu, 15 Oct 2026 23:05:35 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1401f-f659-0a2a45080019-d155dd29dc79-3 for ; Thu, 15 Oct 2026 23:05:35 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48c5358fc28so721909f8f.0 for ; Thu, 15 Oct 2026 14:05: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-48dfd4f8bd9sm501163f8f.35.2026.10.15.14.05.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 14:05: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: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=1792098335; x=1792703135; 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=4VW67AVN3J4LJdnkkC/kdo+PQC4U/8r9vrNzku1xFB4=; b=QWfMZ5BMAvkpcI434Fxhg3SPpBAhq9eOy/AdfBGhwp0NOH/mQFJaCrSOSIVe5fUKrh 3dlinZgUYctRBW9XW8k1JTDujjhx0Pxd4F5m+IeINw76MfauJNu2ffarSS82vvgbwJ06 0ofeCCs3zJq1iNZXbYqU+z+K+mcCJbfxEiwV8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792098335; x=1792703135; 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=4VW67AVN3J4LJdnkkC/kdo+PQC4U/8r9vrNzku1xFB4=; b=OXLOCHUo4WrVC6DTCEalovNqDmdjCg09herVGtl6fEk7oytO4saTU63pA9KMIs6j2Q mPzJT6Bos/lJw6WYFkJydjxwrsg7t5ZHVjfxIGq8JiZyDppTgSzQicQpkkmAtgoEQcG5 cb5KD1lU+rPu8jEFPqw8Fxinb46B5Ynx4Xcb3fEmHVPkfNdzkhQFaR60L+1nQSMWQiQq YSu1oS8/wRd1FUOjTHFSDdlOZzrkM6hauoE0h+hij43xl+eyNCkulTtl9+AMGN3rx1nY KhZCyUaAnTOaHdvMq6E6VFwv+jW+0oqUobMAnXaUpeRr0jm5XODpc6kJjGjL1G5G56lh ++JA== X-Gm-Message-State: AFq9FYJ6ctl0CVEhwrp8VQzOI4XVjv3dJEbp1nxO21lI4lVZoGML6HhV TjeFqzAHozmSTpwFxfGeYbiZCf2gatrwxaNCCx5hPmbYOYBJ1+BBVWAUChdPomqpRtRubBtyZmU KBELXCFE= X-Gm-Gg: AYBFou0eYx7RPBgI/U3GUoP4DDhL8szcdVJsiMgP5bh2frrHzsrpEPD8VpilvziVbuY zUA+pGeajtjGTsnEKRS9dwY7XsjmCzWxehX+O6WHC7nsRc7F+PSHo9GORj99f36rIlTvpbv7F51 3tUIzF7C4DFhpMfqte0LC80++M+BPo660RJrRdi700yK3IWvmXv0IbJjhGWGHOCBFUhTcWbV/kx arV82rTLWWl2I9Dxrp6FjjE7XMFOqo9fKPhOhq/lGBlmWj2CeSNpnhIfGrJlvfyVb4c3Ywu3IYl PMLQI8aAtVX05u2B3g8Gbcx32f1NbcOrxOz5wl4usBVGJZigbVTQb0shWNeDpuQis6M0CMcez5g IvpQik4kqX6Tex2oKkCj5nzn7mZaDJvACJJpTHEh3M5+Z9ZYdXG3LgL/ztSy3R9MNIhPHLXwgff MvPk6ugDxcUB09wn23GwsP7FdQNonuxlB7IWOUomPg+30icyH47mlYxbuZBUdD23jS1nC7AXUWZ hOsAkrVpWV5WNlr7Mqu/IeYT5RUuDXnfY+bacYGv+icuq+R X-Received: by 2002:a05:6000:2503:b0:48c:7083:be67 with SMTP id ffacd0b85a97d-48dbace462emr36869264f8f.42.1792098334736; Thu, 15 Oct 2026 14:05:34 -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 v4 2/5] tests/x86: Introduce a userspace test harness for x86_decode_lite() Date: Thu, 15 Oct 2026 22:05:27 +0100 Message-Id: <20261015210530.786604-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20261015210530.786604-1-andrew.cooper3@citrix.com> References: <20261015210530.786604-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792098335-D654487B-D164D8EE/10/78276251493 X-purgate-type: spam X-purgate-size: 31293 All the interesting behaviour is in insns.S. There are 4 interesting cases; "not an instruction we tolerate", and one we do tolerate, split by no relation, disp8 or disp32. The DECL()/END() macros start and terminate the tests_*[] arrays used by C. Between DECL()/END(), a macro named _ adds an entry into the array, including a name and the length of the instruction according to the assembler, while being as visually unintrusive as possible. Plain labels are ad-hoc and there to aid legibility during disassembly. In a couple of cases, the macro named n (for name) allows for choosing a name manually, and is used for cases where the assembler doesn't like the mnemonic. Clang IAS doesn't like the convenience macro, and Binutils of around 2.30 don't like sysexitl or movsxd with a 32bit operand. As it's only Ubuntu 18.04 affected by this, skip building the harness in old environments. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie v4: * Fix %dl/%bh confusion in ModRM testing * Rebase over header rework * Uppercase some identifiers v3: * Force disable Clang IAS. It doesn't like the _ macro. * Support 32bit builds v2: * New --- tools/tests/Makefile | 1 + tools/tests/x86-decode-lite/.gitignore | 1 + tools/tests/x86-decode-lite/Makefile | 56 ++ tools/tests/x86-decode-lite/insns.S | 711 ++++++++++++++++++++++ tools/tests/x86-decode-lite/macro-magic.h | 62 ++ tools/tests/x86-decode-lite/main.c | 113 ++++ tools/tests/x86-decode-lite/x86-emulate.h | 29 + 7 files changed, 973 insertions(+) create mode 100644 tools/tests/x86-decode-lite/.gitignore create mode 100644 tools/tests/x86-decode-lite/Makefile create mode 100644 tools/tests/x86-decode-lite/insns.S create mode 100644 tools/tests/x86-decode-lite/macro-magic.h create mode 100644 tools/tests/x86-decode-lite/main.c create mode 100644 tools/tests/x86-decode-lite/x86-emulate.h diff --git a/tools/tests/Makefile b/tools/tests/Makefile index fc0ed8091510..ca4f0c707638 100644 --- a/tools/tests/Makefile +++ b/tools/tests/Makefile @@ -14,6 +14,7 @@ SUBDIRS-y += xenstore SUBDIRS-$(CONFIG_X86) += cpu-policy SUBDIRS-$(CONFIG_X86) += tsx +SUBDIRS-$(CONFIG_X86) += x86-decode-lite ifneq ($(clang),y) SUBDIRS-$(CONFIG_X86) += x86_emulator endif diff --git a/tools/tests/x86-decode-lite/.gitignore b/tools/tests/x86-decode-lite/.gitignore new file mode 100644 index 000000000000..e726b493c993 --- /dev/null +++ b/tools/tests/x86-decode-lite/.gitignore @@ -0,0 +1 @@ +test-x86-decode-lite diff --git a/tools/tests/x86-decode-lite/Makefile b/tools/tests/x86-decode-lite/Makefile new file mode 100644 index 000000000000..dc33d5fd173a --- /dev/null +++ b/tools/tests/x86-decode-lite/Makefile @@ -0,0 +1,56 @@ +XEN_ROOT = $(CURDIR)/../../.. +include $(XEN_ROOT)/tools/Rules.mk + +TARGET := + +# Clang IAS doesn't like the convenience macros we use +$(call cc-option-add,CFLAGS,CC,-no-integrated-as) + +# Binutils around 2.30 have mutually exclusive expectations of instruction +# suffix validities compared to later versions. Among the distro we test, +# this only excludes Ubuntu 18.04. +ifeq ($(shell echo 'asm(".code64;sysexitl");' | $(CC) -x c -c -o /dev/null 2>/dev/null - && echo y),y) +TARGET += test-x86-decode-lite +endif + +.PHONY: all +all: $(TARGET) + +.PHONY: run +run: $(TARGET) + ./$< + +.PHONY: clean +clean: + $(RM) -- *.o $(TARGET) $(DEPS_RM) + +.PHONY: distclean +distclean: clean + $(RM) -- *~ + +.PHONY: install +install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)/tests + $(if $(TARGET),$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN)/tests) + +.PHONY: uninstall +uninstall: + $(RM) -- $(DESTDIR)$(LIBEXEC_BIN)/$(TARGET) + +.PHONY: uninstall +uninstall: + +vpath decode-lite.c $(XEN_ROOT)/xen/arch/x86/x86_emulate + +CFLAGS += $(CFLAGS_xeninclude) -I. -I$(XEN_ROOT)/xen/arch/x86 +CFLAGS += $(APPEND_CFLAGS) + + +LDFLAGS += $(APPEND_LDFLAGS) + +%.o: Makefile + +$(TARGET): main.o insns.o decode-lite.o + $(CC) -o $@ $^ $(LDFLAGS) + +-include $(DEPS_INCLUDE) diff --git a/tools/tests/x86-decode-lite/insns.S b/tools/tests/x86-decode-lite/insns.S new file mode 100644 index 000000000000..dc017016b2d2 --- /dev/null +++ b/tools/tests/x86-decode-lite/insns.S @@ -0,0 +1,711 @@ +#include "macro-magic.h" + + .code64 + + .allow_index_reg + + .text + +DECL(tests_rel0) +modrm: + /* Mod=0, Reg=0, RM {0..f} */ + _ add %al, (%rax) + _ add %al, (%rcx) + _ add %al, (%rdx) + _ add %al, (%rbx) + _ add %al, (%rsp) /* SIB */ + /*add %al, (%rbp) RIP --> tests_rel4 */ + _ add %al, (%rsi) + _ add %al, (%rdi) + _ add %al, (%r8) + _ add %al, (%r9) + _ add %al, (%r10) + _ add %al, (%r11) + _ add %al, (%r12) /* SIB */ + /*add %al, (%r13) RIP --> tests_rel4 */ + _ add %al, (%r14) + _ add %al, (%r15) + + /* Mod=1, Reg=0, RM {0..f} */ + _ add %al, 0x01(%rax) + _ add %al, 0x01(%rcx) + _ add %al, 0x01(%rdx) + _ add %al, 0x01(%rbx) + _ add %al, 0x01(%rsp) /* SIB */ + _ add %al, 0x01(%rbp) + _ add %al, 0x01(%rsi) + _ add %al, 0x01(%rdi) + _ add %al, 0x01(%r8) + _ add %al, 0x01(%r9) + _ add %al, 0x01(%r10) + _ add %al, 0x01(%r11) + _ add %al, 0x01(%r12) /* SIB */ + _ add %al, 0x01(%r13) + _ add %al, 0x01(%r14) + _ add %al, 0x01(%r15) + + /* Mod=2, Reg=0, RM {0..f} */ + _ add %al, 0x7f000001(%rax) + _ add %al, 0x7f000001(%rcx) + _ add %al, 0x7f000001(%rdx) + _ add %al, 0x7f000001(%rbx) + _ add %al, 0x7f000001(%rsp) /* SIB */ + _ add %al, 0x7f000001(%rbp) + _ add %al, 0x7f000001(%rsi) + _ add %al, 0x7f000001(%rdi) + _ add %al, 0x7f000001(%r8) + _ add %al, 0x7f000001(%r9) + _ add %al, 0x7f000001(%r10) + _ add %al, 0x7f000001(%r11) + _ add %al, 0x7f000001(%r12) /* SIB */ + _ add %al, 0x7f000001(%r13) + _ add %al, 0x7f000001(%r14) + _ add %al, 0x7f000001(%r15) + + /* Mod=3, Reg=0, RM {0..f} */ + _ add %al, %al + _ add %al, %cl + _ add %al, %dl + _ add %al, %bl + _ add %al, %ah + _ add %al, %ch + _ add %al, %dh + _ add %al, %bh + _ add %al, %r8b + _ add %al, %r9b + _ add %al, %r10b + _ add %al, %r11b + _ add %al, %r12b + _ add %al, %r13b + _ add %al, %r14b + _ add %al, %r15b + +sib: + /* Mod=0, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */ + _ add %al, (%rax, %rax, 8) + _ add %al, (%rcx, %rax, 8) + _ add %al, (%rdx, %rax, 8) + _ add %al, (%rbx, %rax, 8) + _ add %al, (%rsp, %rax, 8) + _ add %al, ( , %rax, 8) /* "none", %rbp encoded with mod=1/2 */ + _ add %al, (%rsi, %rax, 8) + _ add %al, (%rdi, %rax, 8) + _ add %al, (%r8, %rax, 8) + _ add %al, (%r9, %rax, 8) + _ add %al, (%r10, %rax, 8) + _ add %al, (%r11, %rax, 8) + _ add %al, (%r12, %rax, 8) + _ rex.b add %al,(,%rax, 8) /* "none", %r13 encoded with mod=1/2 */ + _ add %al, (%r14, %rax, 8) + _ add %al, (%r15, %rax, 8) + + /* Mod=1, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */ + _ add %al, 0x01(%rax, %rax, 8) + _ add %al, 0x01(%rcx, %rax, 8) + _ add %al, 0x01(%rdx, %rax, 8) + _ add %al, 0x01(%rbx, %rax, 8) + _ add %al, 0x01(%rsp, %rax, 8) + _ add %al, 0x01(%rbp, %rax, 8) + _ add %al, 0x01(%rsi, %rax, 8) + _ add %al, 0x01(%rdi, %rax, 8) + _ add %al, 0x01(%r8, %rax, 8) + _ add %al, 0x01(%r9, %rax, 8) + _ add %al, 0x01(%r10, %rax, 8) + _ add %al, 0x01(%r11, %rax, 8) + _ add %al, 0x01(%r12, %rax, 8) + _ add %al, 0x01(%r13, %rax, 8) + _ add %al, 0x01(%r14, %rax, 8) + _ add %al, 0x01(%r15, %rax, 8) + + /* Mod=2, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */ + _ add %al, 0x7f000001(%rax, %rax, 8) + _ add %al, 0x7f000001(%rcx, %rax, 8) + _ add %al, 0x7f000001(%rdx, %rax, 8) + _ add %al, 0x7f000001(%rbx, %rax, 8) + _ add %al, 0x7f000001(%rsp, %rax, 8) + _ add %al, 0x7f000001(%rbp, %rax, 8) + _ add %al, 0x7f000001(%rsi, %rax, 8) + _ add %al, 0x7f000001(%rdi, %rax, 8) + _ add %al, 0x7f000001(%r8, %rax, 8) + _ add %al, 0x7f000001(%r9, %rax, 8) + _ add %al, 0x7f000001(%r10, %rax, 8) + _ add %al, 0x7f000001(%r11, %rax, 8) + _ add %al, 0x7f000001(%r12, %rax, 8) + _ add %al, 0x7f000001(%r13, %rax, 8) + _ add %al, 0x7f000001(%r14, %rax, 8) + _ add %al, 0x7f000001(%r15, %rax, 8) + + /* Mod=0, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */ + _ add %al, (%rax, %riz, 8) + _ add %al, (%rcx, %riz, 8) + _ add %al, (%rdx, %riz, 8) + _ add %al, (%rbx, %riz, 8) + _ add %al, (%rsp, %riz, 8) + _ add %al, ( , %riz, 8) /* %rbp encoded with mod=1/2 */ + _ add %al, (%rsi, %riz, 8) + _ add %al, (%rdi, %riz, 8) + _ add %al, (%r8, %riz, 8) + _ add %al, (%r9, %riz, 8) + _ add %al, (%r10, %riz, 8) + _ add %al, (%r11, %riz, 8) + _ add %al, (%r12, %riz, 8) + _ rex.b add %al,(,%riz, 8) /* %r13 encoded with mod=1/2 */ + _ add %al, (%r14, %riz, 8) + _ add %al, (%r15, %riz, 8) + + /* Mod=1, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */ + _ add %al, 0x01(%rax, %riz, 8) + _ add %al, 0x01(%rcx, %riz, 8) + _ add %al, 0x01(%rdx, %riz, 8) + _ add %al, 0x01(%rbx, %riz, 8) + _ add %al, 0x01(%rsp, %riz, 8) + _ add %al, 0x01(%rbp, %riz, 8) + _ add %al, 0x01(%rsi, %riz, 8) + _ add %al, 0x01(%rdi, %riz, 8) + _ add %al, 0x01(%r8, %riz, 8) + _ add %al, 0x01(%r9, %riz, 8) + _ add %al, 0x01(%r10, %riz, 8) + _ add %al, 0x01(%r11, %riz, 8) + _ add %al, 0x01(%r12, %riz, 8) + _ add %al, 0x01(%r13, %riz, 8) + _ add %al, 0x01(%r14, %riz, 8) + _ add %al, 0x01(%r15, %riz, 8) + + /* Mod=2, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */ + _ add %al, 0x7f000001(%rax, %riz, 8) + _ add %al, 0x7f000001(%rcx, %riz, 8) + _ add %al, 0x7f000001(%rdx, %riz, 8) + _ add %al, 0x7f000001(%rbx, %riz, 8) + _ add %al, 0x7f000001(%rsp, %riz, 8) + _ add %al, 0x7f000001(%rbp, %riz, 8) + _ add %al, 0x7f000001(%rsi, %riz, 8) + _ add %al, 0x7f000001(%rdi, %riz, 8) + _ add %al, 0x7f000001(%r8, %riz, 8) + _ add %al, 0x7f000001(%r9, %riz, 8) + _ add %al, 0x7f000001(%r10, %riz, 8) + _ add %al, 0x7f000001(%r11, %riz, 8) + _ add %al, 0x7f000001(%r12, %riz, 8) + _ add %al, 0x7f000001(%r13, %riz, 8) + _ add %al, 0x7f000001(%r14, %riz, 8) + _ add %al, 0x7f000001(%r15, %riz, 8) + + +.macro alu_ops op + _ \op %al, (%rax) + _ \op %eax, (%rax) + _ \op (%rax), %al + _ \op (%rax), %eax + _ \op $1, %al + _ \op $0x7f000001, %eax + + /* Vary osize on imm fields */ + _ data16 \op $1, %al + _ rex.w \op $1, %al + _ data16 rex.w \op $1, %al + + _ \op $0x7f01, %ax + _ \op $0x7f000001, %rax + _ data16 \op $0x7f000001, %rax +.endm + +onebyte_row_0x: + alu_ops add + alu_ops or + +onebyte_row_1x: + alu_ops adc + alu_ops sbb + +onebyte_row_2x: + alu_ops and + .code32 + _ es nop + .code64 + alu_ops sub + _ cs nop + +onebyte_row_3x: + alu_ops xor + .code32 + _ ss nop + .code64 + alu_ops cmp + _ ds nop + +/* onebyte_row_4x --> rex prefixes */ + +onebyte_row_5x: + _ push %rax + _ push %rcx + _ push %rdx + _ push %rbx + _ push %rsp + _ push %rbp + _ push %rsi + _ push %rdi + _ pop %rax + _ pop %rcx + _ pop %rdx + _ pop %rbx + _ pop %rsp + _ pop %rbp + _ pop %rsi + _ pop %rdi + +onebyte_row_6x: + /*pusha,popa,bound --> not supported */ + _ movsxd (%rax), %eax + _ movslq (%rax), %rax + _ fs nop + _ gs nop + _ data16 nop + /* addr32 --> not supported */ + _ pushq $0x7f000001 + _ pushw $0x7f01 + _ rex.w pushq $0x7f000001 + _ imul $0x7f01, %ax, %ax + _ imul $0x7f000001, %eax, %eax + _ imul $0x7f000001, %rax, %rax + _ pushq $0 + _ pushw $0 + _ rex.w pushq $0 + _ imul $0, %ax, %ax + _ imul $0, %eax, %eax + _ imul $0, %rax, %rax + _ insb + _ insw + _ insl + _ outsb + _ outsw + _ outsl + +/* onebyte_row_7x: --> Jcc disp8 */ + +onebyte_row_8x: + _ add $0, %cl /* Grp1 */ + _ data16 add $0, %cl + _ rex.w add $0, %cl + _ add $0x7f01, %cx + _ add $0x7f000001, %ecx + _ add $0x7f000001, %rcx + _ add $0, %cx + _ add $0, %ecx + _ add $0, %rcx + _ test %cl, %cl + _ test %ecx, %ecx + _ xchg %cl, %cl + _ xchg %ecx, %ecx + _ mov %cl, (%rax) + _ mov %ecx, (%rax) + _ mov (%rax), %cl + _ mov (%rax), %ecx + _ mov %cs, (%rax) + _ lea (%rax), %eax + _ mov (%rax), %cs + /*pop mem --> Grp1a, Not supported (XOP prefix adjacent) */ + +onebyte_row_9x: + _ nop + _ pause + _ xchg %ax, %ax + _ xchg %eax, %eax + _ xchg %rax, %rax + _ rex.w xchg %rax, %rax + _ cltq + _ cqto + _ wait + _ pushf + _ popf + _ sahf + _ lahf + +onebyte_row_Ax: + _ mov 0x8000000000000001, %al + _ mov 0x8000000000000001, %ax + _ mov 0x8000000000000001, %eax + _ mov 0x8000000000000001, %rax + _ mov %al, 0x8000000000000001 + _ mov %ax, 0x8000000000000001 + _ mov %eax, 0x8000000000000001 + _ mov %rax, 0x8000000000000001 + _ movsb + _ movsl + _ cmpsb + _ cmpsl + _ test $0, %al + _ test $0x80000001, %eax + _ test $0x7f000001, %rax + _ stosb + _ stosl + _ lodsb + _ lodsl + _ scasb + _ scasl + +onebyte_row_Bx: + _ mov $0, %al + _ mov $0, %cl + _ mov $0x7f01, %ax + _ mov $0x7f01, %cx + _ mov $0x7f000001, %eax + _ mov $0x7f000001, %ecx + _ mov $0x7f00000000000001, %rax + _ mov $0x7f00000000000001, %rcx + +onebyte_row_Cx: + _ rol $0, %al /* Grp2 */ + _ rol $0, %ax + _ rol $0, %eax + _ rol $0, %rax + /*ret $0 --> not supported */ + _ ret + /*les,lds --> not supported */ + _ movb $0, (%rax) /* Grp11 */ + _ movw $0, (%rax) + _ movl $0, (%rax) + _ movq $0, (%rax) + /*xbegin (Grp11) --> disp32 */ + /*enter,leave,lretq $0 --> not supported */ + _ lretq + _ int3 + _ int $0 + /*into,iret --> not supported */ + +onebyte_row_Dx: + _ rol $1, %al /* Grp2 */ + _ rol $1, %ax + _ rol $1, %eax + _ rol $1, %rax + _ rol %cl, %al + _ rol %cl, %ax + _ rol %cl, %eax + _ rol %cl, %rax + /*aam,aad --> not supported */ + n "udb" .byte 0xd6 + /*xlat,d8...df --> not supported */ + +onebyte_row_Ex: + /*loop{ne,e,},jrcxz --> not supported */ + _ in $0, %al + _ in $0, %eax + _ out %al, $0 + _ out %eax, $0 + /*call,jmp --> disp32 */ + /*ljmp --> not supported */ + /*jmp --> disp8 */ + _ in %dx, %al + _ in %dx, %eax + _ out %al, %dx + _ out %eax, %dx + +onebyte_row_Fx: + _ lock addb $0, (%rax) + n "icebp" .byte 0xf1 + _ repne nop + _ repe nop + _ hlt + _ cmc + _ test $0, %cl /* Grp3, /0 has extra Imm{8,} */ + _ not %cl + _ test $0x7f01, %cx + _ not %cx + _ test $0x7f000001, %ecx + _ not %ecx + _ test $0x7f000001, %rcx + _ not %rcx + _ clc + _ stc + _ cli + _ sti + _ cld + _ std + _ inc %cl /* Grp4 */ + _ dec %cl + _ inc %ecx /* Grp5 */ + _ dec %ecx + _ call *(%rax) + _ lcall *(%rax) + _ jmp *(%rax) + _ ljmp *(%rax) + _ push (%rax) + +twobyte_row_0x: + _ sldt (%rax) /* Grp6 */ + _ sgdt (%rax) /* Grp7 */ + _ lar (%rax), %eax + _ lsl (%rax), %eax + _ ud2a + +twobyte_row_1x: + _ prefetchnta (%rax) /* Grp16 (Hint Nop) */ + _ nopl (%rax) + +twobyte_row_2x: + _ mov %cr0, %rax + _ mov %dr0, %rax + _ mov %rax, %cr0 + _ mov %rax, %dr0 + +twobyte_row_3x: + _ wrmsr + _ rdtsc + _ rdmsr + _ rdpmc + +twobyte_row_4x: + _ cmovo (%rax), %eax + _ cmovg (%rax), %eax + +/* twobyte_row_8x: --> Jcc disp32 */ + +twobyte_row_9x: + _ seto (%rax) + _ setg (%rax) + +twobyte_row_Ax: + _ push %fs + _ pop %fs + _ cpuid + _ bt %eax, (%rax) + _ shld $0, %ax, (%rax) + _ shld $0, %eax, (%rax) + _ shld $0, %rax, (%rax) + _ shld %cl, %ax, (%rax) + _ shld %cl, %eax, (%rax) + _ shld %cl, %rax, (%rax) + _ push %gs + _ pop %gs + /*rsm --> not supported */ + _ bts %eax, (%rax) + _ shrd $0, %ax, (%rax) + _ shrd $0, %eax, (%rax) + _ shrd $0, %rax, (%rax) + _ shrd %cl, %ax, (%rax) + _ shrd %cl, %eax, (%rax) + _ shrd %cl, %rax, (%rax) + _ fxsave (%rax) /* Grp15 */ + _ imul (%rax), %eax + +twobyte_row_Bx: + _ cmpxchg %al, (%rax) + _ cmpxchg %eax, (%rax) + _ lss (%rax), %eax + _ btr %eax, (%rax) + _ lfs (%rax), %eax + _ lgs (%rax), %eax + _ movzbl (%rax), %eax + _ movzwl (%rax), %eax + _ popcnt (%rax), %eax + _ ud1 (%rax), %eax /* Grp10 */ + _ bt $0, %ax /* Grp8 */ + _ bt $0, %eax + _ bt $0, %rax + _ btc %eax, (%rax) + _ bsf (%rax), %eax + _ bsr (%rax), %eax + _ movsbl (%rax), %eax + _ movswl (%rax), %eax + +twobyte_row_Cx: + _ xadd %al, (%rax) + _ xadd %eax, (%rax) + _ cmpxchg8b (%rax) /* Grp9 */ + _ bswap %eax + _ bswap %edi + +END(tests_rel0) + +DECL(tests_rel1) +disp8: +1: + _ jo 1b + _ jno 1b + _ jb 1b + _ jae 1b + _ je 1b + _ jne 1b + _ jbe 1b + _ ja 1b + _ js 1b + _ jns 1b + _ jp 1b + _ jnp 1b + _ jl 1b + _ jge 1b + _ jle 1b + _ jg 1b + _ jmp 1b + +disp8_rex: + _ rex.w jo 1b + _ rex.w jno 1b + _ rex.w jb 1b + _ rex.w jae 1b + _ rex.w je 1b + _ rex.w jne 1b + _ rex.w jbe 1b + _ rex.w ja 1b + _ rex.w js 1b + _ rex.w jns 1b + _ rex.w jp 1b + _ rex.w jnp 1b + _ rex.w jl 1b + _ rex.w jge 1b + _ rex.w jle 1b + _ rex.w jg 1b + _ rex.w jmp 1b +END(tests_rel1) + +DECL(tests_rel4) +disp32: + _ call other_section + _ jmp other_section + _ jo other_section + _ jno other_section + _ jb other_section + _ jae other_section + _ je other_section + _ jne other_section + _ jbe other_section + _ ja other_section + _ js other_section + _ jns other_section + _ jp other_section + _ jnp other_section + _ jl other_section + _ jge other_section + _ jle other_section + _ jg other_section + _ xbegin other_section + +disp32_rex: + _ rex.w call other_section + _ rex.w jmp other_section + _ rex.w jo other_section + _ rex.w jno other_section + _ rex.w jb other_section + _ rex.w jae other_section + _ rex.w je other_section + _ rex.w jne other_section + _ rex.w jbe other_section + _ rex.w ja other_section + _ rex.w js other_section + _ rex.w jns other_section + _ rex.w jp other_section + _ rex.w jnp other_section + _ rex.w jl other_section + _ rex.w jge other_section + _ rex.w jle other_section + _ rex.w jg other_section + _ rex.w xbegin other_section + +riprel: + _ add %al, 0(%rip) + _ rex.b add %al, 0(%rip) + + _ addb $1, 0(%rip) + _ rex.b addb $1, 0(%rip) + + _ addl $0x7f000001, 0(%rip) + _ rex.b addl $0x7f000001, 0(%rip) +END(tests_rel4) + +DECL(tests_unsup) + +unsup_prefix: /* Prefixes unimplemented for simplicity. */ + _ vaddpd %zmm0, %zmm0, %zmm0 /* 0x62 EVEX */ + _ addr32 nop /* 0x67 Address size override */ + _ bextr $0, %eax, %eax /* 0x8f XOP */ + _ bextr %eax, %eax, %eax /* 0xc4 VEX3 */ + _ vaddpd %ymm0, %ymm0, %ymm0 /* 0xc5 VEX2 */ + n "jmpabs 0" .byte 0xd5, 0x00, 0xa1, 0x01, 0, 0, 0, 0, 0, 0, 0x80 /* 0xd5 REX2 */ + _ fadds (%rax) /* 0xd8 ... 0xdf ESCAPE (x87) */ + _ femms /* 0x0f,0x0e ... 0x0f 3DNOW */ + +unsup_branch: +1: + _ loopne 1b + _ loope 1b + _ loop 1b + _ jrcxz 1b + +opsize_branch: /* 66-prefixed branches are decoded differently by vendors */ + _ data16 call other_section + _ data16 jmp other_section + _ data16 jo other_section + _ data16 jno other_section + _ data16 jb other_section + _ data16 jae other_section + _ data16 je other_section + _ data16 jne other_section + _ data16 jbe other_section + _ data16 ja other_section + _ data16 js other_section + _ data16 jns other_section + _ data16 jp other_section + _ data16 jnp other_section + _ data16 jl other_section + _ data16 jge other_section + _ data16 jle other_section + _ data16 jg other_section + _ data16 xbegin other_section + +not_64bit: /* Not valid/encodable in 64bit mode */ + .code32 + _ push %es + _ pop %es + _ push %cs + _ push %ss + _ pop %ss + _ push %ds + _ pop %ds + _ daa + _ das + _ aaa + _ aas + _ pusha + _ popa + _ bound %eax, (%eax) + /*arpl %ax, %ax --> movsxd in 64bit mode */ + /* Grp1 */ + _ lcall $-1, $-1 + _ les (%eax), %eax + _ lds (%eax), %eax + _ into + _ aam $0 + _ aad $0 /* Also REX2, also not supported */ + _ ljmp $-1, $-1 + .code64 + +unsup_insn: /* Instructions that would complicated decode, or shouldn't be used */ + _ ret $0 + _ enter $0, $0 + _ leave + _ lretq $0 + _ iretq + _ xlat + _ clts + _ wbinvd + _ syscall + _ sysretl + _ invd + _ sysenter + _ sysexitl + _ rsm + +END(tests_unsup) + + /* + * For improved diagnostics, we allow some overreading of the + * instruction under test. Ensure there are good bytes to read. + */ +overread_padding: + .skip 20 + + /* This is here to cause jmps to use their disp32 form. */ + .section .text.other_section, "ax", @progbits +other_section: + int3 + + /* Mark this file as not needing executable stacks. */ + .section .note.GNU-stack, "", @progbits diff --git a/tools/tests/x86-decode-lite/macro-magic.h b/tools/tests/x86-decode-lite/macro-magic.h new file mode 100644 index 000000000000..b3c8aae39acd --- /dev/null +++ b/tools/tests/x86-decode-lite/macro-magic.h @@ -0,0 +1,62 @@ +#ifndef X86_DECODE_LITE_LINKAGE_H +#define X86_DECODE_LITE_LINKAGE_H + +#ifdef __i386__ +# define PTR_ALIGN 4 +# define PTR .long +#else +# define PTR_ALIGN 8 +# define PTR .quad +#endif + + +/* Start a 'struct test' array */ +.macro start_arr aname + .pushsection .data.rel.ro.\aname, "aw", @progbits + .globl \aname + .align PTR_ALIGN + .type \aname, STT_OBJECT +\aname: + .popsection + + /* Declare a macro wrapping \aname */ + .macro pushsection_arr + .pushsection .data.rel.ro.\aname, "aw", @progbits + .endm +.endm + +/* Macro 'n' to wrap the metadata of an instruction. Name can be different. */ +.macro n name:req insn:vararg + /* Emit the instruction, with start & end markers. */ +.Ls\@: \insn +.Le\@: + + /* Emit \name as a string. */ + .pushsection .rodata.str1, "aMS", @progbits, 1 +.Ln\@: .asciz "\name" + .popsection + + /* Emit an entry into the array. */ + pushsection_arr + PTR .Ln\@, .Ls\@, .Le\@ - .Ls\@ + .popsection +.endm + +/* Macro '_' where the name is the instruction itself. */ +.macro _ insn:vararg + n "\insn" \insn +.endm + +/* Finish a 'struct test' array */ +.macro finish_arr aname + pushsection_arr + PTR 0, 0, 0 + .size \aname, . - \aname + .popsection + .purgem pushsection_arr +.endm + +#define DECL(aname) start_arr aname +#define END(aname) finish_arr aname + +#endif /* X86_DECODE_LITE_LINKAGE_H */ diff --git a/tools/tests/x86-decode-lite/main.c b/tools/tests/x86-decode-lite/main.c new file mode 100644 index 000000000000..08e9e8ad231a --- /dev/null +++ b/tools/tests/x86-decode-lite/main.c @@ -0,0 +1,113 @@ +/* + * Userspace test harness for x86_decode_lite(). + */ +#include + +#include "x86-emulate.h" + +static unsigned int nr_failures; +#define fail(t, fmt, ...) \ +({ \ + const unsigned char *insn = (t)->ip; \ + \ + nr_failures++; \ + \ + (void)printf(" Fail '%s' [%02x", (t)->name, *insn); \ + for ( unsigned int i = 1; i < (t)->len; i++ ) \ + printf(" %02x", insn[i]); \ + printf("]\n"); \ + \ + (void)printf(fmt, ##__VA_ARGS__); \ +}) + +struct test { + const char *name; + void *ip; + unsigned long len; +}; + +extern const struct test +/* Defined in insns.S, ends with sentinel */ + tests_rel0[], /* No relocatable entry */ + tests_rel1[], /* disp8 */ + tests_rel4[], /* disp32 or RIP-relative */ + tests_unsup[]; /* Unsupported instructions */ + +static inline void run_tests(const struct test *tests, unsigned int rel_sz) +{ + printf("Test rel%u\n", rel_sz); + + for ( unsigned int i = 0; tests[i].name; ++i ) + { + const struct test *t = &tests[i]; + x86_decode_lite_t r; + + /* + * Don't end strictly at t->len. This provides better diagnostics if + * too many bytes end up getting consumed. (Because of the tests + * being one single section, this doesn't read out of bounds + * anywhere) + */ + r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20); + + if ( r.len == 0 ) + { + fail(t, " Failed to decode instruction\n"); + + if ( r.rel_sz != 0 || r.rel ) + fail(t, " Rel/sz despite no decode\n"); + + continue; + } + + if ( r.len != t->len ) + { + fail(t, " Expected length %lu, got %u\n", + t->len, r.len); + continue; + } + + if ( r.rel_sz != rel_sz ) + { + fail(t, " Expected relocation size %u, got %u\n", + rel_sz, r.rel_sz); + continue; + } + + if ( r.rel_sz && + (r.rel < t->ip || + r.rel > t->ip + t->len || + r.rel + r.rel_sz > t->ip + t->len) ) + { + fail(t, " Rel [%p,+%u) outside insn [%p,+%lu)\n", + r.rel, r.rel_sz, t->ip, t->len); + continue; + } + } +} + +static void run_tests_unsup(const struct test *tests) +{ + printf("Test unsup\n"); + + for ( unsigned int i = 0; tests[i].name; ++i ) + { + const struct test *t = &tests[i]; + x86_decode_lite_t r = x86_decode_lite(t->ip, t->ip + t->len); + + if ( r.len ) + fail(t, " Got len %u\n", r.len); + } +} + +int main(int argc, char **argv) +{ + printf("Tests for x86_decode_lite()\n"); + + run_tests(tests_rel0, 0); + run_tests(tests_rel1, 1); + run_tests(tests_rel4, 4); + run_tests_unsup(tests_unsup); + + return !!nr_failures; +} diff --git a/tools/tests/x86-decode-lite/x86-emulate.h b/tools/tests/x86-decode-lite/x86-emulate.h new file mode 100644 index 000000000000..337718869435 --- /dev/null +++ b/tools/tests/x86-decode-lite/x86-emulate.h @@ -0,0 +1,29 @@ +#ifndef X86_EMULATE_H +#define X86_EMULATE_H + +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +#define ASSERT assert + +#define printk(...) + +#define likely +#define unlikely +#define cf_check +#define init_or_livepatch +#define init_or_livepatch_const + +#include "x86_emulate/x86_emulate.h" + +#endif /* X86_EMULATE_H */ -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Oct 15 21:40:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Oct 2026 21:40:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451166.1666351 (Exim 4.92) (envelope-from ) id 1xHTBV-0002HU-Fe; Thu, 15 Oct 2026 21:40:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451166.1666351; Thu, 15 Oct 2026 21:40: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 1xHTBV-0002HN-Ct; Thu, 15 Oct 2026 21:40:21 +0000 Received: by outflank-mailman (input) for mailman id 1451166; Thu, 15 Oct 2026 21:40:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHTBU-0002HG-Sh for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:40:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHTBV-00000006skK-01w4 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:40:20 +0000 Received: from mail-lj1-f172.google.com ([209.85.208.172]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xHTBU-00000001xcY-1Bz1 for xen-devel@lists.xenproject.org; Thu, 15 Oct 2026 21:40:20 +0000 Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-3a20f06cce6so4636541fa.1 for ; Thu, 15 Oct 2026 14: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" 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=Au3j75gVr9B0AS7vjzh5COb5tkOgOOJ7meSRvMKfXUI=; b=EWOwaFGD/6XffwZYVBTg5n1GD4 yJEeDwtrkIXR89YL3C/qC9qRzF+Ga640EqaT9hEWynLre6rDWrGhE9i3G/ytgXy0JBidRagkiJabv +dl6N/nrTcj+shW0wXVpfEAwlNKHGSA8sLmuii12WBnT9DlEdHAsJv+slEPruJp4e8NI=; X-Gm-Message-State: AFq9FYKRwXkqsj5dP3ro7IwdyXi0BRHuW7mFaPM+hqQ/fwoHIBgN+URD VtuR9EaP1uF1/+ikmUszoW8dn1u/klkRXpMp/ammQOZg52ZPJOvEonQjrMDRvCa6N+76sUCvsEc tw3XLH9/N2Cy2oid+BgIo4kzeL2BuAnM= X-Received: by 2002:a05:651c:b29:b0:3a9:dba6:ae7d with SMTP id 38308e7fff4ca-3ab147d86c1mr3079061fa.15.1792100419594; Thu, 15 Oct 2026 14:40:19 -0700 (PDT) MIME-Version: 1.0 References: <20261007104051.48841-1-gwd@xenproject.org> <20261007104051.48841-16-gwd@xenproject.org> In-Reply-To: From: George Dunlap Date: Thu, 15 Oct 2026 22:40:07 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9YIGhjTbUsn3OPHbyVaBN26OezSSt4hAvpPkMl6fw7zbvVlVZDevvvMQ4 Message-ID: Subject: Re: [PATCH v3 15/18] x86/mm: flush owned pages before reuse with the sparse directmap view To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 15, 2026 at 5:46=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > On Wed, Oct 14, 2026 at 04:34:54PM +0100, George Dunlap wrote: > > On Thu, Oct 8, 2026 at 8:00=E2=80=AFPM Roger Pau Monn=C3=A9 wrote: > > > > > > On Wed, Oct 07, 2026 at 11:40:48AM +0100, George Dunlap wrote: > > > > Since d7bf1b8ea275 ("x86/mm: limit deferred TLB flushing to PV doma= in > > > > support") a page freed by its owner is flushed from TLBs before it = is > > > > handed out again only in builds with PV support, on the premise tha= t PV > > > > domains, with their (limited) control over the host MMU and over wh= en > > > > flushes happen, are the only ones to leave stale entries behind. > > > > > > > > Xen's transient mappings of domain pages are another source. The > > > > mapcache zaps a slot when it is unmapped but defers the flush: the > > > > slot's translation can stay in the TLB of the CPU which used it unt= il > > > > that CPU next flushes, by which time the page may have been freed a= nd > > > > handed to another domain. Before "x86/hvm: introduce per-vCPU > > > > mapcache for vCPU-PT domains", only PV vCPUs use the mapcache, so t= he > > > > PV condition covers it. Now that the vCPUs of an HVM domain with > > > > per-vCPU page-tables have one as well. > > > > > > > > While the full directmap is loaded in every context, stale transien= t > > > > mappings only map what's already mapped in the full directmap. On = the > > > > sparse view of the directmap, a stale translation of a page handed = to > > > > another domain would keep it reachable from a context which has > > > > nothing to do with it. > > > > > > But if it's handed to another domain, then it also hasn't gone throug= h > > > a free cycle, which is what pg->u.free.need_tlbflush covers? > > > > Sorry, the wording there is a bit imprecise; it should be "a stale > > translation of a page *freed and then* handed to another domain". > > > > Apart from things like steal_page(), which doesn't apply to HVM guests > > AFAIK, there isn't any way to hand a page to another domain, is there? > > > > I guess there's dom_cow for memory sharing; but that's experimental. > > We should just document that ASI + memory sharing isn't supported at > > the moment, and work out the details when that's wanted. > > > > > > So flush owned pages before reuse wherever a sparse view is > > > > configured, as before d7bf1b8ea275. In builds without PV support, > > > > mark_page_free() now also asks a new hook, > > > > arch_freed_pages_need_tlbflush(), declared with the xenheap hooks t= he > > > > sparse view already uses. x86 answers with sparse_dmap_configured(= ); > > > > without CONFIG_SPARSE_DIRECTMAP, and on other architectures, the > > > > answer is no. Builds with PV support flush as before, and HVM-only > > > > builds keep d7bf1b8ea275's saving unless a sparse view is configure= d, > > > > which nothing does until a later patch. > > > > > > I think this is not fully correct, in fact I think we need to flush > > > the map cache on every return to guest, otherwise you risk leaking > > > contents between processes running on the same vCPU (and by extension > > > the same physical CPU). > > > > > > We either need a flush flush before returning to guest, or we need to > > > invalidate every page that unmapped from the mapcache. > > > > This is a good point, but it's raising the bar significantly in terms > > of what kinds of attacks we're trying to defend against. Stack rubble > > could technically contain sensitive guest data, but is much harder to > > take advantage of than the full direct map, and XSAVE registers in the > > xenheap; so it's delayed until later. I think this is the same kind > > of thing: Yes, pages mapped by a hypercall may contain sensitive data > > relevant to other processes, but it's kind of like stack rubble: much > > less useful. > > > > My recommendation is that we put this off, past moving XSAVE out of > > the xenheap, and treat it as another level of safety. > > Up to a degree there's also a performance aspect here: when you set > pg->u.free.need_tlbflush that triggers a host-wide flush on the next > allocation (if needed, which is likely the case for systems running > HVM-only domains). However if we do the flush on mapcahce unmap, > that can be a single invlpg on the local CPU. As systems grow larger, > a host-wide TLB flush is quite a bottleneck, and it also introduces > interference to remote CPUs. > > I would rather not re-enable the usage of pg->u.free.need_tlbflush, as > I think for a complete ASI solution we will need to solve this > flushing TLB entries when pages are unmapped from the mapcache. I > would possibly leave this with a TODO or comment somewhere. Well leaving this undone leaves potential cross-domain data windows open. You're right, avoiding IPIs on free, is a big win; the cost is the INVLPG, and a TLB re-walk on repeated references. I'll give it a think, but probably go with your suggestion. -George From xen-devel-bounces@lists.xenproject.org Fri Oct 16 05:10:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 05:10:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451260.1666361 (Exim 4.92) (envelope-from ) id 1xHaCY-0006c5-0p; Fri, 16 Oct 2026 05:09:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451260.1666361; Fri, 16 Oct 2026 05:09: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 1xHaCX-0006bx-Rw; Fri, 16 Oct 2026 05:09:53 +0000 Received: by outflank-mailman (input) for mailman id 1451260; Fri, 16 Oct 2026 05:09:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHaCV-0006br-KW for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 05:09:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHaCU-00H28r-IP for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 07:09:50 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1b190-e002-0a2a0a5209dd-0a2a450883fa-10 for ; Fri, 16 Oct 2026 07:09:50 +0200 Received: from [52.101.62.12] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1b19c-f659-0a2a45080019-34653e0ceafa-3 for ; Fri, 16 Oct 2026 07:09:49 +0200 Received: from BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) by BN8PR03MB5090.namprd03.prod.outlook.com (2603:10b6:408:db::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 05:07:31 +0000 Received: from BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550]) by BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550%2]) with mapi id 15.21.0522.012; Fri, 16 Oct 2026 05:07: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=QB8KqD7/c/kkSd2S1GjaQzAWuaAxMNv5eKnCxgRbMBnAhgD6MEhJhBZv8zXvSEHE4zlxGaQuHM6XXFgXaAheH3AGJzNROw01Y1SrNPur75YzUzLMiGY5Uhfygvt7PzUf/6n+gVVqrucC4lTERtO8CgKLbFlsuxhhUi/PB9xK5lRsrie27Lmn/a3tSXncUKnqpT76GjptzqOTDnw3vQ/6naj4O44AsRLSjjBbFAoaqu7klm9cpN6SXjO4Xkh+Y1tSa+jcUqECU1ywdfnH3Cz66ad7L6HJLvt7olDm2DD8PTRtoLbmLmLKCIrfQLOcjkDiAvKhpM27IvuhI1JsUmBSrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i3KqU4Zic7f+WsVGd29gdNe6+S4IF+atkhQGf6BfB+o=; b=TO25cLfybF5nr8lsWaQ6+9cBJCXMeUJta0YyxdUZ4SnJOUbM+tHSfQLxWGAjNojPaCxiXJc4qR39zrFgGsiiaYHKQJ9Gvm8rW+fVNL9X64ib3xkhZzdyf/e8ni0zAgSvOtm6c7qPLDWsLvF8nOwy56bO3NgVjdlgJaf3Zd79/2jgfRTGoATK5vgEk+UPmU8pUe04rDWBS3vs9ZfdbZmvcp+Nz40fV6aoPa8cwSGLA4vzLFFkSbuz3CVdcLdCcAvtxUnzXDocYLm81w5y2Gl+nAlvqOc/4l7z5eQjE7sYmGgJyHj4lzoyIaylnefS4EyQQXIkALJUtszeF33ArLktgQ== 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=i3KqU4Zic7f+WsVGd29gdNe6+S4IF+atkhQGf6BfB+o=; b=c/1cvcKcbQwZNd7zo7OKJLnzwwxjc3DAbhHB/egV2quo1Ask8B5AkmNCl+EjZXUPIWUrcBOAlyLuZLg9hGtl5rL9nYaJDTqw6nyaU3x7KLiWGHONcIXoA6OwvlEMylggk+TjGZj2Mx6Iyl5O3+s81kRIbsdlFUFdGiNh1n1s8Ls= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: ehem+xen@m5p.com Cc: anthony.perard@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH 3/3] tools/xl: move some logic needed only once earlier in Date: Fri, 16 Oct 2026 13:07:21 +0800 Message-Id: <20261016050721.251856-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <92156ced183670bbbcb2d3f9e2dca4d12f37ee7c.1792017144.git.ehem+xen@m5p.com> References: <92156ced183670bbbcb2d3f9e2dca4d12f37ee7c.1792017144.git.ehem+xen@m5p.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: DU7P195CA0010.EURP195.PROD.OUTLOOK.COM (2603:10a6:10:54d::13) To BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR03MB5315:EE_|BN8PR03MB5090:EE_ X-MS-Office365-Filtering-Correlation-Id: a49d6aef-2640-441c-0247-08df2b43616b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|56012099006|11063799006|5023799004|261009223027099003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: j5eY9PdmYj1jS9hdjmR8eUouNJtsCmJj0bZDZcBkUk2YOUGHLlZuMIpKiICxkXyyroHjyXEnA/chux17h86WSHQYE+p8OMpNldn860xDoJSq/3E4rRajDvxlj3QULckLfZtyPMeQRibclbWCK1CTSjnmz/egx5Tyc0Wd4v5i/ftEFSrZc7irHNxmuk2CznZawSFiPGdVQk3vNDxaR2f6JYaM4rbODOhIe8TSjoSjxDwBhMTo7Sh48iHbcVMach6wqIN3n1f7eF/IQcKkNPLKmywS32kYKoMSw4KK4bkVo+RPBKhCz7MMXzaYM8l0i6lOpz2FbtZGZoY45iFCJxYJolsTBMyY51H6OekyshhSffUea3XxouxVQ/9mCyV4PbHguZE24YLWFM95ToLxASwSfPcqUMTe4JzVd5IZXjoaM6PGfVSoVpSBpx7SR5jc31UQ4tDVwweW7axZ/yCU+sboJ0if+oVj8hZEXnc+53akJ/eycDARUVQlcAbu5mWZYFqwqG+OFeSFCl2QAfosFe738yp4zynx4+62PfhwcMlZZztE6ZmBYWDY9Ujj0bi0Gc0SjMN1dslU4Hm0xVEt5+XzA+aHMjaiJBnJcE2Vjz5FEwzIldontvX435b+0EWo+s3zVBh3vxtt4i2l66GmF3BREfJYOuByGX47UByi5KfU5SA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR03MB5315.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(56012099006)(11063799006)(5023799004)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RoqtxiMmnHS/NET3bZqCn4UvbLCNT5e6QO42WgE+aPkuBl0t9iuZeRdgpk3k?= =?us-ascii?Q?cpxZmaV7unfyJ7PGbYe2owd4C6m9RlDYkvhjBAD6n0LEgvrpwyhGCY2TfCeY?= =?us-ascii?Q?RREMQb8Cn9xStWifKC5a68FgHEf7+A5preZBvUsQQ0p/MaEN9GpuWX7GYvGr?= =?us-ascii?Q?AdneZoKke5haY/Rzal+VDhhoCSGMDUmACv6TQTtADB1wEUrL2WtDau2uSAOu?= =?us-ascii?Q?1A5HcCfFa+EmfTVMZWQqQ5u4ByB/VkgCJhD9M5ACfrO9kVURtQfX4LR3z0lN?= =?us-ascii?Q?DQTrn3cUQVkey7F0sjtFPNR0vjd2/ynX5NsbYSVk+32EpHQQHSblKuRHB50V?= =?us-ascii?Q?HTYTp0KMlzsEmbIbBT04YbVSiPvjKVZsAadFrcCeaTaVGhzvcXY/0bFgW3OS?= =?us-ascii?Q?fCFRa5yCHN7rtYXuXUeVOBCV8J2MTcexsro57/QngEOHxtFglRFmauHJfoJV?= =?us-ascii?Q?xW0UR+/0gFJGAbKc5tbUBFhBA1IvL6ov/4lzB5J0a4/HmH58gL0CedLWzrIh?= =?us-ascii?Q?swXRlxzB99dJqjIUkszAxAWcEsAbXgxNfo4MgXZL8UCJRNKiItCqGGEovJER?= =?us-ascii?Q?usIbIxHlbDlwPoB9XuS55BGe3ovbf7ULa6K7sb2fvytKGk6hmTjvpM202KAP?= =?us-ascii?Q?RPUhTACAw4JJKwVkXth/dXifEiUCVYg7hD5uWHRM4JWRQBKdZ0Db2h/LkX4s?= =?us-ascii?Q?4FcTaJW6Ls2hn87++J3dQ3djAXlMnn5G8g62CpVtBtQeXg3EawgWGsaCFvfD?= =?us-ascii?Q?HTdLv1T4gwArsUWqm+rr3nKbVLZdncxaNTfAf2aUflEFG7mJVB/y0SRvE4L7?= =?us-ascii?Q?FSFsYQiYYvY2GcDhaD4TaiKdnC11vE21q55WE8ZBAY1BxMBJYk7NocWh7LQY?= =?us-ascii?Q?Rp8ptPm4JnihdgygeznoM/93hqNzwvAwcP1TzOMfGRg6tD63HFIS35uMrHs8?= =?us-ascii?Q?/PwBtZCdwk4f4jruQrJ+MumlR5zwokWZ1Zw5+DZvQSemwSIUHL5mwGEU5eh3?= =?us-ascii?Q?geSmiVPsoQrKwGEj39tgzazjst/8pmjVdgARGcmesrCm32qySQoW8lR9J+ep?= =?us-ascii?Q?0IR5ARpCkHQyV8If2Qi9omn+usO/6lhK7k+wkej8Du+ggaSDDH+O/shcVaVf?= =?us-ascii?Q?dOWSTfvfAHAluhktlB0HrapHEp9eyxrpkKXRXTByX+an8dOYJm3kzG4b0Mmq?= =?us-ascii?Q?FXW3XMAqkN+4eTEiinlFm/6vdfYL1N+XMyZuuGQ1h5bAPqDV7zmaF+Iw8w4Q?= =?us-ascii?Q?/gTKht8XDvNzNu0Esz834OcYRusQGr6JMUGKqzS6JXm7URRZWFSoo/3Y9CRV?= =?us-ascii?Q?RAACmAQkwFqoHKqRr6T83t+9Ocqcu7SHCAMXdaTm32eaG7I7DSuntDgGzOzV?= =?us-ascii?Q?1KKTy/yR3dXw/CKjVE4sWv9/SMsWvt9XFO3gyuK5rRsCypXAJEAhDyYOgi5m?= =?us-ascii?Q?59dC8rIf9d/LA4OgLCoCCVX0IfGEof1GUP4j7+3jJHLkNNC84q+32xGqH9q3?= =?us-ascii?Q?rwreQO1NGckKXonh80lVXGgsQp0oFjOHHYfJYblGLSCDaOJA5GrOsYt6NcRQ?= =?us-ascii?Q?x8GZHMMGJDzYsuGnkArAGw+Mk/5+NBwBkhqKuTn5xB30PiiWu0R/CU8o7aJc?= =?us-ascii?Q?90pB1uz2RVCg0xDx8Ojlmot4IcSxYp6z15ki4WC4+x02OIkj6vxDDh8voP1F?= =?us-ascii?Q?0LiNIE5SzWUaRjJeaFTbucUqGQjDBKphrDpCSSkohz8igVaWHzAamPDmsYQD?= =?us-ascii?Q?gxUnZCqmzw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a49d6aef-2640-441c-0247-08df2b43616b X-MS-Exchange-CrossTenant-AuthSource: BY5PR03MB5315.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 05:07:31.4899 (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: ogA4diFzsKmEtoCZBQ2j6eLUOj9oaVXm7TCQq+nO49OVrRPhkTUWgaDzlihOdHLXzKux9zYt/AabHbLrvo+gHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB5090 X-purgate-ID: tlsNG-c1860d/1792127389-D6B4187B-9DE14532/0/0 X-purgate-type: clean X-purgate-size: 3387 On Mon, Oct 12, 2026 at 06:03:49 PM, Elliott Mitchell wrote: > The value of dom_info->console_autoconnect isn't going to change if a > domain is rebooted. Nor does this logic need the lock to be held. As > such moving this earlier makes sense. > > The policy domain is set once and then never changed. Similar to above > simply move before the reboot start point. > > Signed-off-by: Elliott Mitchell > --- > tools/xl/xl_vmcontrol.c | 32 +++++++++++++++----------------- > 1 file changed, 15 insertions(+), 17 deletions(-) > > diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c > index 76c2a07ee8..ae7985122f 100644 > --- a/tools/xl/xl_vmcontrol.c > +++ b/tools/xl/xl_vmcontrol.c > @@ -717,7 +717,8 @@ int create_domain(struct domain_create *dom_info) > int restore_fd = -1; > int restore_fd_to_close = -1; > int send_back_fd = -1; > - const libxl_asyncprogress_how *autoconnect_console_how; > + const libxl_asyncprogress_how *autoconnect_console_how = NULL; > + libxl_asyncprogress_how autoconnect_console_how_buf; > int notify_pipe[2] = { -1, -1 }; > struct save_file_header hdr; > uint32_t domid_soft_reset = INVALID_DOMID; > @@ -921,6 +922,19 @@ int create_domain(struct domain_create *dom_info) > if (dryrun_only) > goto out; > > + if (dom_info->console_autoconnect) { > + if (libxl_pipe(ctx, notify_pipe)) { > + ret = ERROR_FAIL; > + goto error_out; > + } It looks like a functional regression for the reboot path. Right before "goto start;" on the guest-reboot path there is: /* * Do not attempt to reconnect if we come round again due to a * guest reboot -- the stdin/out will be disconnected by then. */ dom_info->console_autoconnect = 0; On reboot, dom_info->console_autoconnect is cleared before "goto start", but autoconnect_console_how now stays non-NULL, since it is no longer recomputed after "start:". The second create call will invoke autoconnect_console with the already-closed notify_pipe[1], and the read(notify_pipe[0]) will fail with EBADF. > + autoconnect_console_how_buf.callback = autoconnect_console; > + autoconnect_console_how_buf.for_callback = ¬ify_pipe[1]; > + autoconnect_console_how = &autoconnect_console_how_buf; > + } > + > + if (!libxl_domid_valid_guest(d_config.c_info.domid)) > + d_config.c_info.domid = domid_policy; > + > start: > assert(domid == INVALID_DOMID); > > @@ -938,22 +952,6 @@ start: > } > } > > - libxl_asyncprogress_how autoconnect_console_how_buf; > - if ( dom_info->console_autoconnect ) { > - if (libxl_pipe(ctx, notify_pipe)) { > - ret = ERROR_FAIL; > - goto error_out; > - } > - autoconnect_console_how_buf.callback = autoconnect_console; > - autoconnect_console_how_buf.for_callback = ¬ify_pipe[1]; > - autoconnect_console_how = &autoconnect_console_how_buf; > - }else{ > - autoconnect_console_how = 0; > - } > - > - if (!libxl_domid_valid_guest(d_config.c_info.domid)) > - d_config.c_info.domid = domid_policy; > - > if ( restoring ) { > libxl_domain_restore_params params; > > -- > 2.47.3 > > > From xen-devel-bounces@lists.xenproject.org Fri Oct 16 06:35:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 06:35:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451278.1666370 (Exim 4.92) (envelope-from ) id 1xHbXG-0008Tb-QV; Fri, 16 Oct 2026 06:35:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451278.1666370; Fri, 16 Oct 2026 06:35: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 1xHbXG-0008TT-N5; Fri, 16 Oct 2026 06:35:22 +0000 Received: by outflank-mailman (input) for mailman id 1451278; Fri, 16 Oct 2026 06:35:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHbXF-0008TM-N0 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 06:35:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHbXF-00A6wH-3S for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 08:35:21 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1c5a8-8faa-0a2a0a5109dd-0a2a4503de6e-4 for ; Fri, 16 Oct 2026 08:35:21 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1c5a8-fae8-0a2a45030019-d155dd2ce4df-3 for ; Fri, 16 Oct 2026 08:35:20 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48df54150dfso875922f8f.0 for ; Thu, 15 Oct 2026 23:35: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-48dfd510ba3sm2868618f8f.56.2026.10.15.23.35.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2026 23:35: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=1792132520; x=1792737320; 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=kLKAClVa90k6t9rFwCAPsMDfTA3kNX7K/zab3T8u0dI=; b=C4m86HzrBiIo6nF1o5rw9Bl8/yifhBArDiXR8mLTTdaa2SiYgAaPJYDlNTM9FEfr1u k7Rotc4pUostLO5GGHqNTTjwwltBt2yKsbFZoPmQja3ULM0wXBy3oz2pqgSHsixYdJtN TdrMVsaWb9lKMmSD5tQE1k7pTUnmK1Eam2SJ36ZhamAGzMGP2lyyE6yYj/RKt3KSnbKh dsE+3w9FZnQnuH5ROjrDoTnR0TQMQzGOL1uCfUVaQoXXOn7HeCEphF1UKVfqWq7MXO5B 0vb/2HIfZolEYB+OwKvr8BX2JgoIFto8L0KHYI4Y/w89VGA1CE9szZ6Z83XjFFeZSjqs nGlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792132520; x=1792737320; 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=kLKAClVa90k6t9rFwCAPsMDfTA3kNX7K/zab3T8u0dI=; b=i5xpgZyOqACXWYcWxrvon4zqoOQk02BAeLpH0RLJVkrlVUEY0SWYfPbB1zC/Y+v2qg q5gPMK6xaOlVNcdoUQHHa/TFF6Od+XUKV3NyITVYKpGysht9qAlOOkmmNa8xbK5NGTbu NMU4VvdzT9cnfEYQ7L09R54TQu8R80gLUSNFCuFc+zSe+nTWHMrXmjTwR1P7T+kafKFa rjty2PFTXxYyn2HFKL8m2hTF3mxeODdUesb4s7CHnlQr0Eie2m3rUv/pXQhnv6PzKfNv JU+HR/HUEHNMdn1oh82nbJ3lbnkNs7jznLUJKJr9q0cSvUFP4zsPe8oZ80Kt0VOZ48sQ 0Paw== X-Forwarded-Encrypted: i=1; AKwUvByTD9VdYl3XYWOZipzBNe7Pdx1u8l1EUc0YutIH4QeFxSLZAMnMuilcl17uLXOQvEBCvjdBzh2iiRs=@lists.xenproject.org X-Gm-Message-State: AFq9FYLQu77XqQcYAuxSSxdUxYyDoZXanOGo6z3NHDKwZV0KNsi4vdbn VmIBkmiKRSn70+8hJAT3z2RUToJlHLiR0zuUEfYdFy5vl5sHzJHWHNldXrV2AZmQTw== X-Gm-Gg: AYBFou25+CNmGpTQROpiUI9vlerUIAT3QmwDZI2Zk7T87uZ6gUI0wu2KNC9qvyjNxSF RUoo66Nm1YWniP688TQuDCVJws9dUBDyMqPukUET+QzpCcOxq+0v1JF2GzgPaMWVL6qFQUWySor seQjHBUikn4mzoMQqbr6+AYqPsPoizK5/ntBAXMh1O6xX8wzLmUmAgcufCT44Ni6sfMqWjk3wEX g2hNg+RLZlwoRFLyG2EkfFwryg+KGxbJU37tqNYqheZQ/D+fMdrKPkVJ8ikfJVcNhymY45uN5cT uVNM0CnVpWg5O4Mnw0GySJr4doV7Bjv81HUcEn937oEeYQJ0ogyaBKniEkEm7AWGB8iGhwYNaG9 i2sa7y321Tj/GG+pYdqPOf2ndJV+QCrcdSGTg1BKvnZ0Arqv73O8O9YcEOJnQAWNKemTA201Fki wFZeaEzWUq3wLz5tVdCAzaLwBnVkx4XqF2Boi8BLuqEwdnqOb2Gntw9pnWEcjIc0W52vu3SnX1h Hx1in6cjSdHMqWCzW5Zsc446l8aE48MFN7vPArGZd2//Qaexkb1UayFIMZYY4WMFRVJdAD8 X-Received: by 2002:a05:6000:2586:b0:48d:f3a4:a6aa with SMTP id ffacd0b85a97d-48df3a4a78cmr10672846f8f.35.1792132515662; Thu, 15 Oct 2026 23:35:15 -0700 (PDT) Message-ID: Date: Fri, 16 Oct 2026 08:35:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] SUPPORT.md: State that ATS is unsupported To: Jason Andryuk 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: <20261014135143.34220-1-jason.andryuk@amd.com> <20261014135143.34220-3-jason.andryuk@amd.com> <960380be-818d-4699-b273-1fd7ebf0d11a@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: <960380be-818d-4699-b273-1fd7ebf0d11a@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1792132521-764FC4E9-32E0A431/10/78276251493 X-purgate-type: spam X-purgate-size: 860 On 15.10.2026 16:33, Jason Andryuk wrote: > On 2026-10-15 08:33, Jan Beulich wrote: >> On 14.10.2026 15:51, Jason Andryuk wrote: >>> --- a/SUPPORT.md >>> +++ b/SUPPORT.md >>> @@ -96,6 +96,9 @@ For the Cortex A77 r0p0 - r1p0, see Errata 1508412. >>> Status, ARM SMMUv3: Tech Preview >>> Status, Renesas IPMMU-VMSA: Supported, not security supported >>> >>> +PCI Address Translation Services (ATS), enabled by the ats= command line >>> +option, is not security supported. >>> + >>> ### ARM/GICv3 >>> >>> GICv3 is an interrupt controller specification designed by Arm. >> >> Wouldn't this better go in the "x86/PCI Device Passthrough" section? > > I guess I thought of ATS as more of an IOMMU feature, but PCI is in the > name. I'm happy to move it. I wonder what others think; it's certainly not clear cut. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 07:06:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 07:06:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451292.1666379 (Exim 4.92) (envelope-from ) id 1xHc1T-0006pI-1w; Fri, 16 Oct 2026 07:06:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451292.1666379; Fri, 16 Oct 2026 07: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 1xHc1S-0006pB-VQ; Fri, 16 Oct 2026 07:06:34 +0000 Received: by outflank-mailman (input) for mailman id 1451292; Fri, 16 Oct 2026 07:06:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHc1R-0006o0-HR for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 07:06:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHc1Q-00ACvf-Qo for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:06:32 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1ccf8-2eae-0a2a0a5409dd-0a2a4501d032-0 for ; Fri, 16 Oct 2026 09:06:32 +0200 Received: from [52.101.85.36] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1ccf6-5984-0a2a45010019-346555242a7f-4 for ; Fri, 16 Oct 2026 09:06:32 +0200 Received: from MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) by SA3PR03MB7395.namprd03.prod.outlook.com (2603:10b6:806:39b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Fri, 16 Oct 2026 07:06:24 +0000 Received: from MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154]) by MN2PR03MB5328.namprd03.prod.outlook.com ([fe80::2d54:a272:35fa:b154%3]) with mapi id 15.21.0522.012; Fri, 16 Oct 2026 07:06: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=GB6Mq3SP2Tv3pj6r54bMCBKub5QJoleOXkcJapqzKWs4Z2Gzla+QPBiNTGAzZbt9EUUcKKc8OAvh8ayhXC1lbygVlHQc/CZhd1gmZ7kQP083ePBYhZZn5OBtqKIVaqJQEtt8607e38Urbi3/KEIXpzJr5NT/W/K3BBO/+ccZ1TMTbqrWRBqgcQJrp0r258DUrnfqCl34pTDQwv7oElfyX+JpQ1geRA/8hEckEbjeFyyZPjmo4MnO2uLFrby7KcQdGa33IPPfNhAZd8A8OjxXGhVKUcLIWdQCJVum2kgOrQHYquUEcs+mY+8pwC5qrVc8mkD2cP2svbB9xuI3ogUa/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=tCo/O8qV3DYeEsbKQVxj9TqqiACRExlHBv0HCth0tsY=; b=Wf7dqTU4lsbDn0gSO9+6FdTJSE4WX8YoaZyiLjTePWzGWyocX7sY05mKmemZBpIKlYh0xy9DyYDf4wTrY3zUAOseNoHs8lzVGzRN8u8JOkA+ARB5ID6BVBJ07LmVG9KQxYDdyCPtA8B3jUY7d5idDO85G590Uwz49W7vUxHbLqcDCYV/WPbngdxPgO0Dxr/OD30FYxb+XDmUaWzoHb36nbcradE6QMa+ufl9zl0c7eixryEJMwlzT9Q0JhY4wOn8YHj8FMr4uXVx82cQAuoZerN+aiwhBhbNF3jJ1lH83xA4/jQz4nEMA0hzDAMP9DhNY13ai+9/DvP//hAZZIP+Sw== 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=tCo/O8qV3DYeEsbKQVxj9TqqiACRExlHBv0HCth0tsY=; b=V/YlVWDnObzUZHmsudSu4IaX1GrLHL6WQ0ZRnduzBReRygFBZB0fwjqVKsnFf+PYeOoVpHkO9nvrb4Fep9KZqERb6+GlqqR1EPS51rn0mjbQgfqMbc7CRSHbjkLdkYaeYHKE4ub3BG1g1RdmpVV3c22yCuWHx+34mIaQnmjJmyI= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Cc: chunjie.zhu@citrix.com, jason.andryuk@amd.com, jbeulich@suse.com, roger@xenproject.org, teddy.astie@vates.tech Subject: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT Date: Fri, 16 Oct 2026 15:06:11 +0800 Message-Id: <20261016070611.255322-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: AM0P309CA0017.EURP309.PROD.OUTLOOK.COM (2603:10a6:20b:28f::21) To CH2PR03MB5320.namprd03.prod.outlook.com (2603:10b6:610:9a::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR03MB5328:EE_|SA3PR03MB7395:EE_ X-MS-Office365-Filtering-Correlation-Id: ad810493-2b98-4173-8416-08df2b53fb5f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|56012099006|5023799004|11063799006|261009223027099003|22082099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: teYZDP/UcJGHzUzWaFSCfkQqe42YCu0PyYtldMI5W6gOmx99VU4rZyOsNrZ9LAFzUyBut3S7FrAGQr9LUdX2mQlNMMLrMGbYxgFfpnFuUN5xdkbmKZpmoAto4/LgpSAlVT7hHGAovAO4UrczPya1GcF1PnPXRQjCehksHmYlL2PlllIUf6u1SVIbqq5qOUYPFrUAdW3ukA8zIg2UYgaJBX4Ua3HY9b+Pz5ESvhTh8vCaWQYEqPDJ8XidjiHwQMPYbA/Jq5LxiuhlWcm5k0DJRHFeqXx/votrKhpaaXwwz2fCgafqRz1LIvkCmVVzr7nShUP/j4J3v1PuQAASine2TfhNF2DDDF2A3spl4S1stFsC/XmH1kMRX01apzvwP6/2fr4jJLWrSVIsz3u4W7cozJoVTCAGF2pYrnWJsC7bXaRM3lZt4yz5Jztazc8rDXK3I8Cri9tvcv44fkVNcApV0tJs0eJuKUGZFFDt/renrCdvstRnfuKdvI6zlajO6HbeTwzXbGdaK+GAg9tO01FZJVvEQMmP1SpTF8bc3ttjKaMWkhb/AQKCdw8tdAq51CdRmy7901oLno8KHf6oiXWCoKT+EACzDLK6x6Zt3lOQ2W0Qo7mx8sqLlgQ0gVVR0wIdLDr2WNUwPQEq6V4fDZUHg8Ri1mcwL6lvELSmN7t8nxY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR03MB5328.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(56012099006)(5023799004)(11063799006)(261009223027099003)(22082099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?XOEMvDxkNvKUnAXV57f+e5ULtHcYkRpUm0LP0mrh2MTU1FSuIXy6UddbI6P5?= =?us-ascii?Q?b6eNWH7+PFm1QLwwOqVPrwqWQE7k81q2+obpkx2kAqLURJgqCHnOHM+lHru2?= =?us-ascii?Q?SVvqOaRBy5GXGNeVeLIVAkEnYq+ZUvKWz78mDnvBfYyfYC5ksYiC9CntzdZd?= =?us-ascii?Q?sxBCxozHgk2f/G7M8OLe06ymHa9WTAWGMiHIFvCzFchQaFHlTCct8L7K8RAl?= =?us-ascii?Q?7feWiMPGCh/mduR3PB8BB02AisSwkio7igUfzyeiub0GlD2bRCGFa9VYkquz?= =?us-ascii?Q?L8lh6LYmHBOmfbmoshaTwvnC4xF+LehNjY6zaY7tpF0Pexe47Rg4TcnPSo/Q?= =?us-ascii?Q?NqqkHngjibOw2Uycc8vaCcn6VJ8R3Ji7aWQZsJntKOcSg+86RHhFAjLva48Z?= =?us-ascii?Q?I5JoY/pcI0vw5xYeMu53cbSP03qczueOJx0qJ119hP18AAu6IzBgiIa0ulsq?= =?us-ascii?Q?OrzDRfi+cCPx8ibtwYCR0wcEeePX9olPtqnwVdKgBac8OfGhsz8Dvat2M3+5?= =?us-ascii?Q?ni8oByjUeCFuj7qfhaNiaee19wHKF/kjGF6zDhTJ/+cvXVS1RqIHkq043FGC?= =?us-ascii?Q?WJKfaIMWNoUsw1slRedV2lKmGUF+K51UBW2jerpfNEo4HlhIsnhzVongKKyb?= =?us-ascii?Q?BoWr9ilHYWpxGsUS0yhBLo0geI4kuvg1Wdjys0u6i18I9YKTt3AKQDBXLvMk?= =?us-ascii?Q?1cg6XGlsE/dv4lrL4nv0ExBmx35LEh3pZ9L/gK7ppsU0wEJktx2+b5Ju/eAf?= =?us-ascii?Q?JagN7+5o5JnUVc09YpPlDgrcb31YTe6aiiMi8Cgtx3WF37bJ/ttBfrMERc4Z?= =?us-ascii?Q?dm87Gyk7QxVW/sSCS5Sa3Jo9RVlFbmH/PIHOO3djd9oPYVhecbtajlF2lrAL?= =?us-ascii?Q?0cmXSGr5Mda7CoYlC/sUXjihA8YWRMLFzR0SOVco670Pumygj6mmNxNx+ZtC?= =?us-ascii?Q?R/Ix8+PthWv16uiA96+3665NpU6oLcdC7WQ+B08WpmkEd7TI03g+Zi3/agcJ?= =?us-ascii?Q?T4DXMeV41Kmq4vwauHD5R3QI9UqDJS1u1RrIax6QDxqMMjiP2JednFo6kTBt?= =?us-ascii?Q?QSNrg9SUMjmTYlpg75yLGjfgF1Osb8OHXYlu8sbmUt1GO3NFQQeyKKirf3Cu?= =?us-ascii?Q?0wIpF/pvaIWRBQpMfhuYywSXZks2I72TocbspMsFPs+/ZQYHnwla0XAnCtg/?= =?us-ascii?Q?uGQi5QlQXkoJyyGxs2n4P2eopKZHdhksKKU3mfACbFMc6sz/qLJmFZjulDdv?= =?us-ascii?Q?FoUrGefNnl4WRdSatcpWiW0Okc18V5i0IPhbJ4w95c0LSt57uYKkU7iXr59y?= =?us-ascii?Q?N7kh0PeZUyf53dDaSzkCdPSMe87tuCxNaVyue8m4jsp0pvn1uFbodYuobPHg?= =?us-ascii?Q?rvOpqUYgoJcJMLrf+10fjzYqop3czE5Mex/k6eHDVEq0jeF5qfupuCv1lljn?= =?us-ascii?Q?0f/mJa4DUqowUy1h0Bhl6pLBoC7YvImuarT3UfkjS2tLCfMVCkOhamAAf1yH?= =?us-ascii?Q?/+jeZZES4UgIr+42rKsYjkd/vU79cMTScogWeqCEw9VRMco7fJ9IjdF4CbhX?= =?us-ascii?Q?I25aXipuG5r8RLcru9prOBIFtXVFRYc62wyoWu9+k9rGbAdU0kzojQQ1nzdH?= =?us-ascii?Q?Ub41miqSFFb34aw5VAXAsk3Kdoj8atLTsrh50Ued+zVcYV31m6SSp+yzeO3g?= =?us-ascii?Q?off9dfZ95XV/uhIhvimNuoHt2dcxKgWilaWBGkTX0NqqMSdvVIFb/jUB9JAq?= =?us-ascii?Q?y0GECJtXPw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad810493-2b98-4173-8416-08df2b53fb5f X-MS-Exchange-CrossTenant-AuthSource: CH2PR03MB5320.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 07:06:24.1410 (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: TC8BdrH8ZO9pjALASpenWjQzetRZNUYGgt6GvSJUuPwqZcgXAJm27+LhvbBnZN8dlkQUZZpnH2a3p/pYrlowUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7395 X-purgate-ID: tlsNG-d62444/1792134392-1DE78757-6B76AA33/0/0 X-purgate-type: clean X-purgate-size: 2171 From: Chunjie Zhu When V_NMI_ENABLE is set, the processor manages V_NMI and V_NMI_MASK automatically (including on IRET), and writes both back to the VMCB on VMEXIT (APM vol.2 rev 3.44, "NMI Virtualization"). nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally) V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never copied back, so L1 kept seeing whatever it had last written, regardless of what happened in L2. Copy both back when L1 has enabled vNMI for its guest. Fixes: 86a203ab8d38 ("x86/svm: Support vNMI on capable hardware") Signed-off-by: Chunjie Zhu --- v2: * Reword commit message: the processor manages V_NMI/V_NMI_MASK itself. * Add Fixes: tag. * Cite APM by revision and section title. --- xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index faacfe007832..3a0afa98129e 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1027,12 +1027,19 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* * 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. + * enabled in L1. With vNMI enabled, the processor manages V_NMI and + * V_NMI_MASK itself and writes both back on #VMEXIT (APM vol.2 rev 3.44, + * "NMI Virtualization"). */ 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; + if ( ns_vmcb->_vintr.fields.vnmi_enable ) + { + ns_vmcb->_vintr.fields.vnmi_pending = n2vmcb->_vintr.fields.vnmi_pending; + ns_vmcb->_vintr.fields.vnmi_blocking = n2vmcb->_vintr.fields.vnmi_blocking; + } /* Interrupt state */ ns_vmcb->int_stat = n2vmcb->int_stat; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 07:16:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 07:16:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451298.1666388 (Exim 4.92) (envelope-from ) id 1xHcB5-0000S3-40; Fri, 16 Oct 2026 07:16:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451298.1666388; Fri, 16 Oct 2026 07:16: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 1xHcB4-0000Rv-UI; Fri, 16 Oct 2026 07:16:30 +0000 Received: by outflank-mailman (input) for mailman id 1451298; Fri, 16 Oct 2026 07:16:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHcB3-0000Rp-9C for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 07:16:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHcB3-00000008GAS-0La7; Fri, 16 Oct 2026 07:16: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.98.2) (envelope-from ) id 1xHcB2-00000006XJj-07lr; Fri, 16 Oct 2026 07:16: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=HkUfA1gBIJwe/UOsPPHoqFrKLN3+biMQ6WaM29LpIDY=; b=2F7+4ZGXvm6lvGT41kiAvO7INI fhYTiP4lItCiShV5ozWyYEjYwn51O7fuJQim4920cLGplNsyszaPKBm+r8tQOYoMXK6mPonvZqi0G IgcSjOPGAbdosu/89quERwfxluQEwx6fSZyzylrURUNRuXsuWIc+zTdoKyEAZQh7e3Pg=; Date: Fri, 16 Oct 2026 09:16:20 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 12/15] x86/PVH: heed the kernel in pvh_steal_ram() Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <032c1cb0-55b8-489d-bcf4-4d4c14a590ae@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <032c1cb0-55b8-489d-bcf4-4d4c14a590ae@suse.com> On Mon, Oct 12, 2026 at 10:25:40AM +0200, Jan Beulich wrote: > While the function working downwards will typically result in no conflict > with the kernel range, there's no guarantee of that. > > Fixes: 1d74282c455f ("x86: setup PVHv2 Dom0 ACPI tables") > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -186,8 +186,12 @@ static int __init pvh_populate_memory_ra > /* Steal RAM from the end of a memory region. */ > static int __init pvh_steal_ram(struct domain *d, unsigned long size, > unsigned long align, paddr_t limit, > + const struct elf_binary *elf, > paddr_t *addr) > { > + paddr_t kernel_start = (paddr_t)elf->dest_base & PAGE_MASK; > + paddr_t kernel_end = ROUNDUP((paddr_t)elf->dest_base + elf->dest_size, > + PAGE_SIZE); > unsigned int i = d->arch.nr_e820; > > /* > @@ -203,6 +207,11 @@ static int __init pvh_steal_ram(struct d > continue; > > *addr = (entry->addr + entry->size - size) & ~(align - 1); > + > + /* Avoid kernel range, if this is the region it lives in. */ > + if ( *addr < kernel_end && *addr + size > kernel_start ) > + *addr = (kernel_start - size) & ~(align - 1); > + > if ( *addr < entry->addr || > /* Don't steal from the low 1MB due to the copying done there. */ > *addr < MB(1) ) If you clip addr to remove the kernel range for allocation purposes you need to restore it before the `entry->size = *addr - entry->addr` adjustment. Overall I continue to think this will be much simpler if we passed around a rangeset. This series is adding a fair amount of extra code to deal with overlaps between kernel/initrd allocations vs everything else, which could be solved more easily by using a rangeset. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 16 07:24:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 07:24:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451307.1666397 (Exim 4.92) (envelope-from ) id 1xHcIh-0002Iz-O9; Fri, 16 Oct 2026 07:24:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451307.1666397; Fri, 16 Oct 2026 07: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 1xHcIh-0002Is-L9; Fri, 16 Oct 2026 07:24:23 +0000 Received: by outflank-mailman (input) for mailman id 1451307; Fri, 16 Oct 2026 07:24:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHcIf-0002Im-QF for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 07:24:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHcIf-00000008GHx-2ATv; Fri, 16 Oct 2026 07:24: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.98.2) (envelope-from ) id 1xHcIe-00000006uLu-2B1v; Fri, 16 Oct 2026 07:24: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=zX5vRCFuQdz/w9vGXgrcEsBep9Kj6oCh6lAGjzfOiWo=; b=6U3iDdABInDGKbLGdaBtSVV8GN +rIRTvU/pWEykdSh3AFGjsrfwmkXw0z7X7/sEF5Tz4yupyCMCAB0Pinh+7Iw64OFtipfBSjXS7nQu hPYfpvJKOwUfLK9dU1Ni5Kt1FTgSwoAb94TK1QZLArDDPW4N+vGxdzWCTdgKCNMG5qhE=; Date: Fri, 16 Oct 2026 09:24:18 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 14/15] x86/PVH: log Dom0's E820 map earlier Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Oct 12, 2026 at 10:26:24AM +0200, Jan Beulich wrote: > Do this as soon as it's final. For debug builds also mark it final, with > assertions put in place to make sure it won't further be altered. (For a > release build such further altering isn't the end of the world normally, > so the situation is left alone there.) > > Switch to using %pd while moving the code up. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -46,6 +46,9 @@ > */ > #define HVM_VM86_TSS_SIZE 265 > > +/* Marker set once Dom0's E820 isn't supposed to change anymore */ > +static bool __initdata e820_finalized; > + > static unsigned int __initdata acpi_intr_overrides; > static struct acpi_madt_interrupt_override __initdata *intsrcovr; > > @@ -195,6 +198,8 @@ static int __init pvh_steal_ram(struct d > struct e820entry *good = NULL; > unsigned int i = d->arch.nr_e820; > > + ASSERT(!e820_finalized); > + > /* > * Alignment 0 should be set to 1, so it doesn't wrap around in the > * calculations below. > @@ -241,6 +246,8 @@ static int __init pvh_add_mem_range(stru > struct e820entry *map; > unsigned int i; > > + ASSERT(!e820_finalized); > + > for ( i = 0; i < d->arch.nr_e820; i++ ) > { > uint64_t rs = d->arch.e820[i].addr; > @@ -1759,6 +1766,13 @@ int __init dom0_construct_pvh(const stru > > pvh_place_initrd(bd, &elf, &initrd, &blob_start, &blob_end); > > + if ( opt_dom0_verbose ) > + { > + printk("%pd memory map:\n", d); > + print_e820_memory_map(d->arch.e820, d->arch.nr_e820); > + e820_finalized = true; You want to pull setting e820_finalized out of the if body, so it's not tied to opt_dom0_verbose being set I think? The rest LGTM, so: Acked-by: Roger Pau Monné With the above change. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 16 07:34:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 07:34:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451323.1666406 (Exim 4.92) (envelope-from ) id 1xHcSq-0004F4-Kz; Fri, 16 Oct 2026 07:34:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451323.1666406; Fri, 16 Oct 2026 07:34: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 1xHcSq-0004Ew-Fx; Fri, 16 Oct 2026 07:34:52 +0000 Received: by outflank-mailman (input) for mailman id 1451323; Fri, 16 Oct 2026 07:34:51 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHcSp-0004Eq-1M for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 07:34:51 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHcSo-00000008GSU-3uFR; Fri, 16 Oct 2026 07:34:50 +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.98.2) (envelope-from ) id 1xHcSn-00000007F8N-40bs; Fri, 16 Oct 2026 07:34: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" 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=w/6ZAigQZ7rrsmqXLLBcIjrnz1DrizXf/I/CGCUSdew=; b=I+GEwE2J1I6VXTG7WTRocdsEYU kxorK31vpPwBJPnqxTSiTmb9JbEtlkZX97ILNFHdg38eW1JBWlOfurfSrdaC4xWXVyhMo5YXVFZ5s JiZIjcjfIFdMSZEGqggGQuWwraxsxNT3CrMxNJCh6C/vl3JKJ1qWl2Kl807+RJlAOX3Y=; Date: Fri, 16 Oct 2026 09:34:47 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 15/15] x86/PVH: simplify writing of Dom0's RSDP Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Oct 12, 2026 at 10:26:58AM +0200, Jan Beulich wrote: > Now that we establish where the RSDP is to live before actually loading > the kernel (and writing start-info there) we can simply hand the pointer > there, eliminating the need for the (fragile) separate write to the field > out of pvh_setup_acpi(). > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné One nit below. > --- > Alternatively we could move start_info to the top-level function, have > pvh_load_kernel() and pvh_setup_acpi() fill what need filling, and do > the write from the top-level function. Yet it looks to me as if this was > more churn for little extra gain. > > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -976,7 +976,8 @@ static int __init pvh_load_kernel( > const struct boot_domain *bd, > struct elf_binary *elf, > struct hvm_modlist_entry *mod, > - paddr_t *start_info_addr) > + paddr_t *start_info_addr, > + paddr_t rsdp) > { > struct domain *d = bd->d; > struct boot_module *initrd = bd->initrd; > @@ -1110,6 +1111,7 @@ static int __init pvh_load_kernel( > > start_info.magic = XEN_HVM_START_MAGIC_VALUE; > start_info.flags = SIF_PRIVILEGED | SIF_INITDOMAIN; > + start_info.rsdp_paddr = rsdp; > rc = hvm_copy_to_guest_phys(last_addr, &start_info, sizeof(start_info), v); > if ( rc ) > { > @@ -1587,10 +1589,7 @@ static int __init pvh_place_acpi( > return 0; > } > > -static int __init pvh_setup_acpi( > - struct domain *d, > - struct acpi_info *info, > - paddr_t start_info) > +static int __init pvh_setup_acpi(struct domain *d, struct acpi_info *info) > { > int rc; > struct acpi_table_rsdp *native_rsdp, rsdp = { > @@ -1642,20 +1641,6 @@ static int __init pvh_setup_acpi( > return rc; > } > > - /* Copy RSDP address to start_info. */ > - BUILD_BUG_ON(sizeof(info->rsdp) != > - sizeof_field(struct hvm_start_info, rsdp_paddr)); You add this BUILD_BUG_ON() in a previous patch and remove it here. Maybe it's not worth adding? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 16 08:00:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 08:00:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451339.1666416 (Exim 4.92) (envelope-from ) id 1xHcqz-00084V-GA; Fri, 16 Oct 2026 07:59:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451339.1666416; Fri, 16 Oct 2026 07:59: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 1xHcqz-00084N-Av; Fri, 16 Oct 2026 07:59:49 +0000 Received: by outflank-mailman (input) for mailman id 1451339; Fri, 16 Oct 2026 07:59:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHcqy-00084H-Is for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 07:59:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHcqx-00HXJH-Vl for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:59:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1d96d-e002-0a2a0a5209dd-0a2a4504dba4-38 for ; Fri, 16 Oct 2026 09:59:47 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1d973-b57f-0a2a45040019-d1558031cdac-3 for ; Fri, 16 Oct 2026 09:59:47 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a022fee0caso57475155e9.1 for ; Fri, 16 Oct 2026 00:59: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-4a1bd91c55bsm117316475e9.0.2026.10.16.00.59.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 00:59: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=1792137587; x=1792742387; 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=o8NVuArUAmv/9SGRoMnrbfhwmjuGlvAAFC/hUp2XQk4=; b=ZI/l8vlH9z3O+Ll5HQhOZeb+rhkPq9GsA/OwAriNClBo+TK9/umGd85wza7aj34xjh RP4BPvefJiIIBu04MMNg5s4BmOWodWX6NhWFi6pgzQ4VQxSn746C0oBQbVpHP9QHY/SW 0UdDQE0ZW1h7U4OQGYPr/BZA3+hL1y7Czr9XK0danO8FjKBGZ1Y8mfFyYX1WMLYZ054B 3+sDlnMylesgGL5gV8oZf9gh43gVnsVc5I2fdonF6i05VKhc6NerGGQ9NpCF7IjZBJIf pTtSQ48gJB4gzHf4S2w49oPpPXKklSwuLAfQTpZI2vU+VL0SeKhrDB6nq2lNaBdVOwrd FrGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792137587; x=1792742387; 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=o8NVuArUAmv/9SGRoMnrbfhwmjuGlvAAFC/hUp2XQk4=; b=a5h+S47KahzHOKCrb8ajwkr4Haiuu2TMKcaf1lCYQXeJWU5e+UXrqAcDpAGZbMWmFK 7lQl5LQWNkCHuLsiST19DVUNwaRuaEYCaO/z8ufZ1cDbX5PUl7n0bqHNGornwub/p0Uf hn3kVzi0CZwdUq0dQ75Qv3Qe2trlZROhp13NpEPRAF/yS3x1Z4eU4lCDhevzvXl9UVdC XBgNTv9oLUM0lOKCYk/o0xWfZKD4XKRs58Nz75LO0e91l320Zd9a7GTvdE821WabpzrT 3S0iLCc28UwjEhBCf1p4+i1lxADEh0h0BIPz5fQUaAfPmB+FlYLQ5p9BocFGMfBdn3ya V4ZQ== X-Forwarded-Encrypted: i=1; AKwUvByYj0AHujgEqevJHSYv5esmhu9wlthmWOqNYjGchKhaPmkuNon8Po95kPLmu+9CJewTmf9uhEiBazc=@lists.xenproject.org X-Gm-Message-State: AFq9FYLLOak/0DWG3O+RQCw0BqXa1YU3QbSXwkTxzLeXKiSQaIzExGMg eFu21gM9SL65Rx/4lCcHoozW7JFB7kPpMcB4cyb8pe2oRY4LXv5Aj57YEzXpT9BRaw== X-Gm-Gg: AYBFou2VWhQn2Yk88VX/BzD4HhoJ82xn8m0cK6nLCoGZnbyo1xFqZKi9YxoMKX4vvER it4HwMtEqDZTD+JvzRDo0ujzbs1aXz5YHRJhQWHUlRI1fF2o9ewkFL8d8d9MDU2J0dN00SRc1iY ALp9lmjWn+lVHnVzE/LsKob8q+UP2f2PmS5mr6YZMGKYDbO7Dgwtttzy/A1dqIvb4s8ocCt+IhA 27jYyvEy8oZIJsaLkbSJ4noBrSfuJ+O2JLlggiC75awBSjTLosWoWT6m8IKfLktd+Sis668hBYj lLf1CBDiYDAS/pP2UUNsjoiBmBxhGLz/3OqF7WYXkgcIgTFeTYhrVmKdJhne0qXc75vP9maBDll KLiGIEb+0vmn2sVDdCBkdlQUEhyH9Dm+WyqAxmCfD/LI5BuJKPOl2KJe+vJNuSq7ZNlbG6dpz/S AvJHYdacnfCObOO6N4cBuGFmsNAFzghq3qVVEQwgaG9WtvxKntJRg1GHWAATl5AIY65intEn6fj dXVQodP2NkGPQqc5y7rQz7NQuvPbdlqbug948lxviNdth8VSFNMy1EvUhSvFA== X-Received: by 2002:a05:600c:350b:b0:4a1:ad01:f8dc with SMTP id 5b1f17b1804b1-4a1ad01f924mr224521365e9.21.1792137586948; Fri, 16 Oct 2026 00:59:46 -0700 (PDT) Message-ID: Date: Fri, 16 Oct 2026 09:59:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT To: chunjie.zhu@citrix.com Cc: jason.andryuk@amd.com, roger@xenproject.org, teddy.astie@vates.tech, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <20261016070611.255322-1-chunjie.zhu@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: <20261016070611.255322-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1792137587-528C9B50-AF6B05C6/10/78276251493 X-purgate-type: spam X-purgate-size: 958 On 16.10.2026 09:06, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > When V_NMI_ENABLE is set, the processor manages V_NMI and V_NMI_MASK > automatically (including on IRET), and writes both back to the VMCB on > VMEXIT (APM vol.2 rev 3.44, "NMI Virtualization"). > > nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally) > V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never > copied back, so L1 kept seeing whatever it had last written, regardless of > what happened in L2. > > Copy both back when L1 has enabled vNMI for its guest. > > Fixes: 86a203ab8d38 ("x86/svm: Support vNMI on capable hardware") > Signed-off-by: Chunjie Zhu > --- > v2: > * Reword commit message: the processor manages V_NMI/V_NMI_MASK itself. > * Add Fixes: tag. > * Cite APM by revision and section title. Is there a reason my A-b was lost? Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 08:13:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 08:13:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451358.1666424 (Exim 4.92) (envelope-from ) id 1xHd40-0003Fe-Tr; Fri, 16 Oct 2026 08:13:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451358.1666424; Fri, 16 Oct 2026 08: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 1xHd40-0003FW-QS; Fri, 16 Oct 2026 08:13:16 +0000 Received: by outflank-mailman (input) for mailman id 1451358; Fri, 16 Oct 2026 08:13:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHd3y-0003EL-VR for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 08:13:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHd3y-00BUkZ-94 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:13:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1dc90-2eae-0a2a0a5409dd-0a2a45059392-18 for ; Fri, 16 Oct 2026 10:13:14 +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 6ad1dc99-4cb1-0a2a45050019-b9ff1c12898d-3 for ; Fri, 16 Oct 2026 10:13: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 1a143c59b630008425.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 08:13:06 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 2620981F66; Fri, 16 Oct 2026 10:13:05 +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=9FCW1ovmsuh4LQMziM4l8rX0n2bWAlb24SYEhSIzF4o=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=ozEX/Jv/eK15Rc6oJTBYnwzHkr3sQrs+AO6nZG+/2DTlq/pQI6cWrZKRHnhL8vvt71TuuM53f 6zrFqMaKdK/9pUQCjFTvf10YkK9xnTTrak3g5oCe08T3hyGFzt7h08p0BW81rvPPhef0dPz9m2g sz0B9yKrMRHojGhGigHnNvoSQqNNyf/qaD4ep9dqRuhRm9veAXaSLKXtqMCce0HenqoAcAfUHJz jbjr9WlR5kin9I1P/ub77E/pLvlIRGQOZM7C9jRYrWVooNaJlyu9ENMWy2RRbOx1FeogfhApuqA cPI2HlFys7OCAnYKGRCI87iDz1NhfDt6p4U3wZdgoZLA== X-Zone-Loop: 35ac006f04dbba7b25dee3612280b9204ade4af64f79 x-campaign-type: default x-transaction-id: b693572a-8234-42ee-9be8-317a5f8d3b7a x-swg-uid: 01-be1080bd-1de7-4074-a487-f667f0288d83 X-Mailer: Sweego Message-ID: <1792138386.8631fc262581453bbf619ec5b2062170.1a143c59b630008425@vates.tech> x-swg-bid: 1792138386.8631fc262581453bbf619ec5b2062170.1a143c59b630008425 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: Andrew Cooper , Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Julian Vetter Subject: [PATCH 0/1] xem/arm: populate a default P2M pool for new domains Date: Fri, 16 Oct 2026 10:12:59 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.27f.7d2f308c011a6a90.1a143c598c9.3a48100d0bacd573=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792138385614 X-purgate-ID: tlsNG-c201ff/1792138394-718AE2A1-40810A81/0/0 X-purgate-type: clean X-purgate-size: 972 ---=Part.27f.7d2f308c011a6a90.1a143c598c9.3a48100d0bacd573=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Andrew and Michal, this is a small fix on XEN side to initialize the p2m page pool when a domain is created=2E Then the call in the tests goes away again, and we "match" the behaviour of x86 (which also inits the page pool, although with more pages)=2E I only restored the call that was removed in 9c962e07fb, with the same 16 pages=2E What do you think? Signed-off-by: Julian Vetter --- Julian Vetter (1): xen/arm: populate a default P2M pool for new domains xen/arch/arm/mmu/p2m=2Ec | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.27f.7d2f308c011a6a90.1a143c598c9.3a48100d0bacd573=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 08:17:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 08:17:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451366.1666433 (Exim 4.92) (envelope-from ) id 1xHd7d-0003rx-Cy; Fri, 16 Oct 2026 08:17:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451366.1666433; Fri, 16 Oct 2026 08:17: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 1xHd7d-0003rp-8O; Fri, 16 Oct 2026 08:17:01 +0000 Received: by outflank-mailman (input) for mailman id 1451366; Fri, 16 Oct 2026 08:17:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHd7b-0003rj-VR for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 08:16:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHd7b-000bi1-8C for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:16:59 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1dd77-bab6-0a2a0a5309dd-0a2a45079aa6-10 for ; Fri, 16 Oct 2026 10:16:59 +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 6ad1dd7a-b4ea-0a2a45070019-b9ff1c23a7a9-3 for ; Fri, 16 Oct 2026 10:16: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 1a143c90ffa0008425.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 08:16:52 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id AC47E82986; Fri, 16 Oct 2026 10:16: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=lPA7fuWKSR6byGUoRsVIAsbvFGrN0S2PPt7NfGEmLLc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=lF6+1ZvUSGtgnb08nMFfS2wd3soAtIwbrrQ8f4aZn7C2/tWr4GoTGTB8xE2WXZzp0+qXWPHGQ ELNh1iBeou96ZByBDaDWWVbf2f5WiC4QKBYG6oaJolYza4aoytQIz0xPK7w4BxDmlw0eBJQJBKm DfbQZJe3ItQesf/IeMDhEZKHwTTGcbUZU43o0Z3YZtFlGInZGxqbZRyM69eE8JvEIncEvnZw0to APXiQah0SNRKF6l0hzTB8/APNLCujOt0tupIZ8NDDi8Z9oEHYyuxlP+ZeTNbU2hni6LyYMGVC5A 9QzP+fLcC/NSvBXQ61lFyTZAAjirbrX339epM9J3x7rA== X-Zone-Loop: 4452f9c131a50a54aaa10b2a811b47d306e59ab16a16 x-campaign-type: default x-transaction-id: a4e4efd4-0c41-4417-b9b6-aff07a95e354 x-swg-uid: 01-94f4a56a-9ced-46ff-8760-79218bef2b0f X-Mailer: Sweego Message-ID: <1792138612.8631fc262581453bbf619ec5b2062170.1a143c90ffa0008425@vates.tech> x-swg-bid: 1792138612.8631fc262581453bbf619ec5b2062170.1a143c90ffa0008425 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: Andrew Cooper , Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Julian Vetter Subject: [PATCH 1/1] xen/arm: populate a default P2M pool for new domains Date: Fri, 16 Oct 2026 10:16:46 +0200 In-Reply-To: <1792138386.8631fc262581453bbf619ec5b2062170.1a143c59b630008425@vates.tech> References: <1792138386.8631fc262581453bbf619ec5b2062170.1a143c59b630008425@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.282.7b75de151badd906.1a143c90d8d.9bffdebb0261bc47=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792138612109 X-purgate-ID: tlsNG-ef75cf/1792138619-36AD8AE4-4F333B4B/0/0 X-purgate-type: clean X-purgate-size: 2180 ---=Part.282.7b75de151badd906.1a143c90d8d.9bffdebb0261bc47=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Since commit 9c962e07fb ("xen/arm: Clean-up in p2m_init() and p2m_final_teardown()"), ARM domains start with an empty P2M pool=2E So, populating the physmap fails, as no page tables can be allocated until the pool is sized by, e=2Eg=2E, the toolstack=2E Restore the call to add a small default pool of 16 pages in p2m_init() again, as before 9c962e07fb=2E The hardware domain is skipped, as it doesn't allocate its P2M pages from the page pool=2E Also skip it if LLC coloring is enabled=2E The colors are only configured after domain creation, so the pool pages would be allocated with the default colors=2E Signed-off-by: Julian Vetter --- xen/arch/arm/mmu/p2m=2Ec | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/xen/arch/arm/mmu/p2m=2Ec b/xen/arch/arm/mmu/p2m=2Ec index 2cf35d8a37=2E=2Ede8dd26a72 100644 --- a/xen/arch/arm/mmu/p2m=2Ec +++ b/xen/arch/arm/mmu/p2m=2Ec @@ -3,6 +3,7 @@ #include #include #include +#include #include #include =20 @@ -1541,6 +1542,21 @@ int p2m_init(struct domain *d) if ( rc ) return rc; =20 + /* Populate 16 pages to the P2M pages pool here=2E + * + * Skip the hardware domain, which allocates its P2M pages from the h= eap, + * and LLC colored setups, as the domain's colors are only configured= after + * domain creation=2E + */ + if ( !is_hardware_domain(d) && !llc_coloring_enabled ) + { + spin_lock(&d->arch=2Epaging=2Elock); + rc =3D p2m_set_allocation(d, 16, false); + spin_unlock(&d->arch=2Epaging=2Elock); + if ( rc ) + return rc; + } + return 0; } =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.282.7b75de151badd906.1a143c90d8d.9bffdebb0261bc47=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 08:43:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 08:43:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451385.1666446 (Exim 4.92) (envelope-from ) id 1xHdWy-0000hv-Ft; Fri, 16 Oct 2026 08:43:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451385.1666446; Fri, 16 Oct 2026 08: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 1xHdWy-0000ho-CJ; Fri, 16 Oct 2026 08:43:12 +0000 Received: by outflank-mailman (input) for mailman id 1451385; Fri, 16 Oct 2026 08:43:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHdWx-0000hi-9h for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 08:43:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHdWw-0025Dk-Mg for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:43:10 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1e394-bab6-0a2a0a5309dd-0a2a45029d40-24 for ; Fri, 16 Oct 2026 10:43:10 +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 6ad1e39e-6ca4-0a2a45020019-d1558029b5f7-3 for ; Fri, 16 Oct 2026 10:43:10 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a180fbeef5so55750725e9.1 for ; Fri, 16 Oct 2026 01: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 5b1f17b1804b1-4a1cbedb6f7sm40406185e9.2.2026.10.16.01.43.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 01: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=1792140190; x=1792744990; 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=3gTSuV+PJUern7SPamPr3NuSPV+s9DhBdkBjMM8M3C0=; b=S/OE0un/R8P8UITXMBbJElVaeAmZy7wEhe/jy1HO45AYBp08r/qZpY7hHxvJ8zVNAp 1K4eJ9Eh0g2yndrH00v9nNilw1qlUi+Cizl4wCitxBYS5cQhqZ5/A3t7IxmMxggPCk4t 6sDAuhPsHjSOik+scOvKirlZwIOQxC0KehqW5zee6GdE5PEI1knIqghFWRourrvmXp2+ qx2ulj5UmMh3ayBk8hlvl5gaHnoteTrtBs+wXYyWE/7MqwtjTXlVUiSrxCw/waRaX2Ko KRi9tLD2DmjpQ/N7tQJhdgTQ/ABtveSwh3i7q4vVOp86RkJSbNQKs357i6ncRg75xvGr oryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792140190; x=1792744990; 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=3gTSuV+PJUern7SPamPr3NuSPV+s9DhBdkBjMM8M3C0=; b=EYKS8DBYBoAjBnZTgYP9LFEkuOh+VJ97ziwfiZrASYQdYOmlE3fe4T73NXrjWdu226 0CArCmIe9u32904DPM5s0djLxuTZAkcMmwP6Qda2Ta2awPeSinZ7WvQ9pW0M8g2mO+h/ ISPs1H0XNHVssg4F7vI9bti4fHWy0Lhra7dksQoGVbKrZ7bcGXg7ceFIznh8byKD2IY2 FSasvQxWHsu7wU+qnMpemv0ShCjzHuDJIry2VeTxq/R0ohynPqdgx5zcQ9z9L12ok/W+ y+h4sIXkFW8lxorX6c31/QQzMI8smAVi7eJqPM4XOdWNT/ZCUBZfL+3gOLxrOUbW7vz2 mFeQ== X-Gm-Message-State: AFq9FYIdScJlB1yQDoif15456x+vJKtzS3Vd72Eax/i2dJK1F3r7V+UM AkIx+68igJ2Rkf5zuAdy0t3cvwn41vDw4fQBnbr2AbF7LDtZZPaR7yoOxYqmPYD91Q== X-Gm-Gg: AYBFou3XiWensjqgj5tXsDMTvzQ+E1Kv0RSYs6vowGHkUAWjhIiucSjNkg7JZzE4ohO CcJ8mk9xj9fr9AZFtSe43Ud/tDQshrgWy7cBmNuq7ZbiXPcPnjhv1mmwRQBM/E+rMju2kRWg8Le ZP3RDWtZAYCCuI5K5240SsmMlxOdbm1hm0J1h65kG/Zna14baa3tllOHUXuNBF5Y1iGm7Rkv7W2 o4b28GRcdz9Ffkn2SNw7wa0dblFkuOjrUuohdtJ6tAhAvZcqAiHhTaOsqep+aJloaJsL7Fjjqn+ rIkSx+1X+k5GqlXQr7ELWsJNgncYcFrGWmFmupNKlKH1dtqHOvFttHJ9Y+sDLEWK4+ae2Wqcc7H 7F5JyBgFT6gUnvClLgTauh2y0KmTip7hRT+qXCoNUKRGjskk0pjXsWIghkyDotvcdTYM9+04Lbt 5/KoIYocqZZxtQbYGTlc7ccjflh5lgr9piGy89xejvv9z5ErfsaqObFT2pVtvs+gMqgys+DQnu8 ZoYIGMqIVS88o78dyYiAdHsgMIxPgB+E6UDg8hLo1Mfu+PzP7yV+lcmV6bzK34= X-Received: by 2002:a05:600c:820d:b0:4a1:65d2:7912 with SMTP id 5b1f17b1804b1-4a18e47b302mr389242125e9.8.1792140190005; Fri, 16 Oct 2026 01:43:10 -0700 (PDT) Message-ID: <92148677-e512-4883-b66f-dc340c2915e5@suse.com> Date: Fri, 16 Oct 2026 10:43:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 10/15] x86/PVH: convert find_memory() to using a rangeset To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1792140190-66EB32AC-3C9C7CBF/10/78276251493 X-purgate-type: spam X-purgate-size: 1222 On 15.10.2026 17:20, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:24:44AM +0200, Jan Beulich wrote: >> Subsequently we will need to exclude a 2nd range here. To avoid >> complicating the logic when it needs to cover two ranges, follow the >> suggestion left in a code comment and convert to using a rangeset. >> >> Suggested-by: Xenia Ragiadakou >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -518,14 +518,38 @@ static int __init pvh_populate_p2m( >> #undef MB1_PAGES >> } >> >> +struct mem_info { >> + size_t size; >> + paddr_t addr; >> +}; >> + >> +static int cf_check __init _find_memory( > > I don't really like underscore prefixed functions, I would rather name > this check_memory_range() or similar. A single leading underscore followed by a digit or a lower-case letter matches what is "always reserved for use as identifiers with file scope in both the ordinary and tag name spaces". I.e. I not only see nothing wrong with such a use, but I consider it actively encouraged. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 08:52:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 08:52:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451393.1666455 (Exim 4.92) (envelope-from ) id 1xHdff-0002b8-9X; Fri, 16 Oct 2026 08:52:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451393.1666455; Fri, 16 Oct 2026 08:52: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 1xHdff-0002b0-6W; Fri, 16 Oct 2026 08:52:11 +0000 Received: by outflank-mailman (input) for mailman id 1451393; Fri, 16 Oct 2026 08:52:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHdfe-0002au-Hh for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 08:52:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHdfd-00AYAA-QH for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:52:09 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1e5ae-8faa-0a2a0a5109dd-0a2a4502bfdc-30 for ; Fri, 16 Oct 2026 10:52:09 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1e5b9-6ca4-0a2a45020019-d1558035c930-3 for ; Fri, 16 Oct 2026 10:52:09 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a018dc1f98so49167985e9.3 for ; Fri, 16 Oct 2026 01:52: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 5b1f17b1804b1-4a1c8a56233sm35334595e9.0.2026.10.16.01.52.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 01:52: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=1792140729; x=1792745529; 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=he930oV89eZdh/K36YmmBzdGZKz7JS6dlw7SdepoDME=; b=aRe/ts87hewfrk3YI7q06olR8VPOllZj7vAW2gzcf5eEOjwYGD/7v/9Lp4Y9ZEmBPo wj8yxg2iOWyWNYpWvWKPfzvsFiYzXqBfD7B47TyoqzhI9eLqsXLpmiIQdSWCsuE3ZWfX cDLS+IriWr5eARqGYPDdnYOEt9uLJG20II63e8hjWz1jE4U7XZWtshqdbdBWJSE39dHA 1pgjlrQxifljDwxROEQJs4f8YNB0Cu761VRj+W/uW7JDuQhTZvVCuduhs5SQbGz+ynlD hdVwmr13Hkq4frQUs3XjQqFC4vqDpqhzh2K6zsq9DhtggZsC6YaD3EN8ECKSMVrxHbJE 2uBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792140729; x=1792745529; 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=he930oV89eZdh/K36YmmBzdGZKz7JS6dlw7SdepoDME=; b=1Rmg3fv9KAEuNgHnCendSwpZ9UEpyQB5Z6DqRa+JVxZvic1xsggQ/W/t7QCdPtbVfD H/zKM/PyUEWqydRReuWoL9o1oylySo65OfHoli6+o/F3Sr9GlAEXsIGCNWNW12Avqi8/ osY18y4emLCNNMVCyVGh9e9zIeOb/4hTzqOalSBHFIEaxEbt4LcOxkSurZUlPB7/85re Q9/8cpVhOP8jFjfK2OT+D24wGfI2wHOcyj+9SqIBVia7ONNE0Tv21lR9KZB1Tm6QUJ4N g75S8sfA1AlbbONpyrnkJd1jE/+RMJktdWrtq9lE9GjcX4P3xGi4tzOIJ3cp9zH99oqb 0czg== X-Gm-Message-State: AFq9FYJaQd+YAU4AFN4Kr1OWActGQa0lP0Az8KiCh6gKLWP9Lp/sFYQz mW4/IHV86RN1gHJ/FygtUUuIFLHsZu3UXdBA56b3khJrLPmG73/P1tKs8BpgfUKCpRgofFLFJyM oW28+AQ== X-Gm-Gg: AYBFou3rTz9k1ocXWP69yhbjGn36F6UMLfqzqeKmgW2QehQRMLgoiaKthZoEAlPqPsH Q/Iw+qbiOGrj0gFOkcjFLmAYVfr5kpCk3WpWbQUhAEt3YnIE5sXCXc3GNByv4lg3NL7ZfKyn2bl D4LO063g8x9Wixw/Mz2EOpoAZATMy11wv+mgEU9/uacPwO6xVhonZP07Hmn9VxiPLpYV8hR2u5R TFR37u4sOx6yOhS+JeMW82CW51FAG5uc2FS2rud+GdjmrD94ZV60nvVfP2hlUUMtpqkogHOJhDs qmDcyxZhQuzy0bSAi9JDrODyT0rGFtmfoLNFMiF/XJ5LK/8EyNTN8irPSQP91BUN9LPR3ajraK4 ftRT7sZJ/XL94OmN4TdBFy35FWyoU5ObAiaOjVKvhhCEZx9YIdAha8Q8eCY2P48Rsmq24AfOxwn KVXKUy935FjBjFpv2LrCwXx3kIXXHbbqLskuv5OfgHwpu97XvWoYhuKqJaYE4AslBUXPCaq4p5h IulM8crFEPyj6TbsN+aJBZb03KUn5iAjW9jxE6t/rkotG83UERds6vJ3hLziQ== X-Received: by 2002:a05:600c:1908:b0:49f:ce73:5e94 with SMTP id 5b1f17b1804b1-4a18e4dd018mr424209225e9.34.1792140729149; Fri, 16 Oct 2026 01:52:09 -0700 (PDT) Message-ID: <508b601b-0b95-4edf-a433-8fef03420c9e@suse.com> Date: Fri, 16 Oct 2026 10:52:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Marek Marczykowski References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <78cd46cc-84ed-46df-96c9-26ce97ed0da0@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/1792140729-307C22AC-5DA2DC97/10/78276251493 X-purgate-type: spam X-purgate-size: 2692 On 15.10.2026 18:32, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote: >> Our present handling of initrd is problematic in particular when the >> initrd is huge, and when at the same time "dom0_mem=" isn't in use to >> significantly shrink Dom0's memory (from the default). In that case, >> insufficient memory may exist for pvh_populate_p2m() to succeed (because >> initrd memory can be freed only after copying). >> >> Make an attempt to map the blob (including headroom) into Dom0 instead, > > I would use "dom0 p2m" instead of plain p2m, it's clearer IMO. Can do, sure. >> thus also saving the copying operation. With __start_xen() having arranged >> for a larger than necessary blob, that mapping can typically be done with >> superpage mappings. >> >> Reported-by: Marek Marczykowski-Górecki >> Signed-off-by: Jan Beulich >> --- >> Is there a need to prune (scrub) the headroom space? > > We already populate the p2m with memory allocated with MEMF_no_scrub, > so there's no reason to scrub the headroom unless we also remove the > MEMF_no_scrub for p2m population. Oh, I hadn't noticed that. Away goes the remark. >> Why does find_memory() go upwards, while find_kernel_memory() goes >> downwards? And why do we use the lowest part of the region found by >> find_memory() rather than the highest part? > > find_memory() should probably start downwards from 4G. I've added a todo item; maybe I can get this done in another patch in v2. (Further remarks will be addressed separately.) >> + /* >> + * As we promise to place below 4G whatever fits there, make a first pass >> + * limiting permitted addresses. If we can't fit it there, fall back to >> + * placing above 4G. >> + */ >> + for ( paddr_t limit = GB(4); ; ) >> + { >> + paddr_t start; >> + >> + *blob_start = find_initrd_memory(d, elf, &try, align, limit); >> + if ( *blob_start != INVALID_PADDR ) >> + break; >> + >> + if ( align == PAGE_SIZE ) >> + { >> + if ( !(limit + 1) ) >> + return; >> + >> + limit = -1; >> + align = 1UL << L3_PAGETABLE_SHIFT; > > Aren't you possibly asking for an alignment better than what's > required by the actual initrd memory? Maybe it's using 2M pages yet > you request 1G alignment here. Yes and no: I may request too much here, but the very first condition in find_initrd_memory() deals with that. When trying different variants of coding this up, doing it this way seemed like the best way. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 08:58:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 08:58:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451400.1666463 (Exim 4.92) (envelope-from ) id 1xHdlU-0003Mb-T8; Fri, 16 Oct 2026 08:58:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451400.1666463; Fri, 16 Oct 2026 08:58: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 1xHdlU-0003MU-QT; Fri, 16 Oct 2026 08:58:12 +0000 Received: by outflank-mailman (input) for mailman id 1451400; Fri, 16 Oct 2026 08:58:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHdlT-0003MM-Te for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 08:58:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHdlT-0057zy-6i for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:58:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1e719-bab6-0a2a0a5309dd-0a2a4501bb88-44 for ; Fri, 16 Oct 2026 10:58:11 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1e722-5984-0a2a45010019-d155dd2ee524-3 for ; Fri, 16 Oct 2026 10:58:11 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso1477494f8f.1 for ; Fri, 16 Oct 2026 01:58: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-4a1c8ad6451sm41982045e9.4.2026.10.16.01.58.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 01:58: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=1792141090; x=1792745890; 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=PR9lRPIG8/Y939BZAaMFoj8bjV2bIjKUE7RFR5/k+GM=; b=ZGPjoTGHYXdMJ5ntSL1spXF02/5F6kwQnLZPE2Rh/dlzVCtJYZ2g+WjoYJUZ2+QSUj izCqX74fddPlPhvGcutzjI4wi2cbmqGRBVhCNVoFwDF0K0WEw+6GScim8Rri3GXkBeRE KIbZ5JAP53e3J23YUFxfAXZvsvswP0osSscUkLo6DbsrMsiLKJIdhuUrrp7NckS4QaTz dTD4NJ9Ft69zbn8FM0bKHc/x4pvPgTSd9aHZ/Y+pfb8yTOo2n0/rQHPWU24JpD3xuL8X n5GQUJZMhj03nyTvwoRY+BZYRboAW5wUSv1Dn4qQG+ndT8zBQ2tFRYPWrHUWHJrCXcBj +qsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792141090; x=1792745890; 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=PR9lRPIG8/Y939BZAaMFoj8bjV2bIjKUE7RFR5/k+GM=; b=LP6dw467fpjHedesmXSp17NU1jBu/fMbfz6YCr2FmOthF8ByQMMlecd80dps4tv1JC ZK6Kw8153cKzOZ3WyVjQF9+s6+VsEMDf4LcqsfLRB1blt3w/300TMWTHQaCWmNVh19IS 17W1slSDhJIIp0mKOHP+7ooVDUSnCqJBCff/6W8PEsDpe7OE+NRMj/reEp9Wd1cBvfVQ j80+JDr/254bCzKNWKbj8RAr7nSqRyjs84tPHoAdawUDukEjKASKWbyk5mqKDJ1wTgbK 1V/r88rymmCgSkEngSqNk+fP2XpDUjGMSykLHduRfziMCc9u5z2h85XzgTmste4USgr4 E8eg== X-Gm-Message-State: AFq9FYIiNvqCg510zxb+w4qft6E3V6FPbGQAyH7U5N1CFfhjzm7eFuyn xo+K/AXPutisum3t73ep8SZRXXXk3gnTKpJuium5GNuSS1eczDTsJYhvwSlQzQlAqA== X-Gm-Gg: AYBFou158MZRgYzURyYKAhkL9prc87ixL99bFYIkWvezXjGzznMP4rzFOINWBaD3sKX iycJx3A1HQV+epaPqRMP63Lx/wRQmh/NX5pxpZWnEM1/3KoGLmin5+/GeR5H8+b0sGChZp+s7hz v0faw8A5P3KbNI4APWly5ENiiVZCP5IIq6cNxcAZHkAuXmAxLbT+Nf7SYSQo0dKTxV/nqA7/7V4 h2x33H/Pyf/yLw9inDNnH3Ta8nBNUqqrOlbF6Nal3GrsHBa8RQV/ATmt8k7KdKCoMSLgMBcFYyH hytpKIBm+DKdsol2n60JD5YS9iWHjAMTzM8x27IiFZAionyFgBe+2+2g9K2jEu7t48QfvtrgGv9 w1zdzgHL8QKjBQjZ8tKhas9KlFzeRs1LWe2FxAWbToMUOLHtu433cK5OOypEU6LpeIhWzwp4ah4 3KEQCgV3Eqd7ioIOh8e5mBtXHk43Vry947PinYMcKPR4/DQD07M24aenZtKN7xFX2cuk0Ct3qz5 VA8MtdV64N8xKjTSLItF1bRyPGwxh293EluPbLxkLuzkDFBtB+5waD14IrHfoE= X-Received: by 2002:a05:600c:8105:b0:4a1:714d:eed with SMTP id 5b1f17b1804b1-4a18e4841c1mr458595375e9.14.1792141090544; Fri, 16 Oct 2026 01:58:10 -0700 (PDT) Message-ID: Date: Fri, 16 Oct 2026 10:58:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Marek Marczykowski References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <78cd46cc-84ed-46df-96c9-26ce97ed0da0@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/1792141091-C4D44757-3E2987BB/10/78276251493 X-purgate-type: spam X-purgate-size: 978 On 15.10.2026 19:41, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote: >> @@ -867,7 +1078,7 @@ static int __init pvh_load_kernel( >> } >> start_info.modlist_paddr = last_addr; >> start_info.nr_modules = 1; >> - last_addr += sizeof(mod); >> + last_addr += sizeof(*mod); >> } >> >> start_info.magic = XEN_HVM_START_MAGIC_VALUE; > > Isn't this still not properly ordered, as start_info address must > strictly be below 4GB (as is passed in a CPU register with the CPU in > 32bit mode), yet it is allocated last in pvh_load_kernel()? Well. For one, this is pre-existing. With the size of the region that find_memory() needs to find greatly reduced when the initrd isn't included there, there's about zero chance that it won't find a suitable region below 4G. Once we have find_memory() go downwards from 4G, the remaining little bit of a risk will also go away. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:01:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:01:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451408.1666474 (Exim 4.92) (envelope-from ) id 1xHdox-0004yJ-D5; Fri, 16 Oct 2026 09:01:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451408.1666474; Fri, 16 Oct 2026 09:01: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 1xHdox-0004yC-7o; Fri, 16 Oct 2026 09:01:47 +0000 Received: by outflank-mailman (input) for mailman id 1451408; Fri, 16 Oct 2026 09:01:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHdov-0004y6-Ku for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:01:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHdou-009wen-Qq for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:01:44 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1e7f3-2eae-0a2a0a5409dd-0a2a450ad11e-12 for ; Fri, 16 Oct 2026 11:01:44 +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 6ad1e7f8-f2d2-0a2a450a0019-d155dd2fc47c-3 for ; Fri, 16 Oct 2026 11:01:44 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48b060ec084so3997248f8f.0 for ; Fri, 16 Oct 2026 02:01: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-4a1c8de8c58sm42241235e9.15.2026.10.16.02.01.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 02:01: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=1792141304; x=1792746104; 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=gMy3fFxT0pnvyU53pkFRWNzK567H81OB9IKHouNp6bg=; b=GfYtu9C06xRDTBJES/87JVGFmzTG7Uq6rS0xu9wkHS2NCf+e8Dnsnj0pALx+rNtvDu 9qMKbVkN6FWuupndYHavO/ntZUg+Rudjr7ts55xZSFmERyun+XWQIPeF8TiqCdaDQcOp piaTozL47b5KsIsazTr9NYmHb/9HRxTihRz44ckVxjhfAJEvaav9V+6+5ud5b2Ld+qWn g8dqAdx2ThbhRWi5rsDWXUI+Zp/nxQpK1gP05zwj+d/9xmseJBoLmMiOdyNRdHSzz2kV UYPeOv8jHpF08Elt5f69EnVkPEA5LFTArFeDedrg7NIWTcz1aeqgBcLsFm1iN9ME0lc9 vzhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792141304; x=1792746104; 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=gMy3fFxT0pnvyU53pkFRWNzK567H81OB9IKHouNp6bg=; b=iOzPwmwxvC+/dfXXdCCT8g7MyYEOrchYikg2tOrUstIsLWq1SwevESQ8790+mluEBc JWM2aHhdE3oFCJ7TDmMLbK3oB+XHl/9o4fjt9Qozin+zJ10x4YQ750b73J8aUhmN7LaQ cezp93O0FAGRmAx/oFJ51PddIWCdwQWcgISn7zQ+6BXhHvwxmFRBt1pWDhXB+212mYz5 z/t5Enuv1UuaRYBuxoc5ZMvpBIVWhEMCpILzHGCsKnLLJFp1geuzK7X2UdUQvsLjrUZd Nqqnqc2OO8k73hN2L6nxso/3BkTKZrFfcD13qKfYZmKQZ2SKJJDfaWTht70J38Lr5Q0P hPBQ== X-Gm-Message-State: AFq9FYKPcDV+jSjltB4BZ6sKAYvvSLQbjyuZfRrNjfu6W91HD0Ep//Pj QnRNSAIgL4esZYkhQGMwUT7fbD/EMt9qubv/e4ExrKO8X9iS5D8KYHZ9PN6EuGUZ2A== X-Gm-Gg: AYBFou0vd18LgG1bP/2VHLdbXylX2rAKlk6b2tpOABHPl7OUc/zRiII5GGlqO17QQKd q2GvKVymOEVO2SUI/myLlEDMbdgJ912ILWB6kwxPDaARKcPZnuYpcL+ZRzdJdjOqAGGbWiBC7v8 E/kz9DHizGO9atwch6VU2K6LAE8IKkWIa6KEgdCtaDuN8muoRnrLYbrNa3or82j85HHNXvQYbGc V/XrdN9zQwuuydgaOMH6dU5fUM/nizvgpaPYPgps5iu8msDn5ioeztTu8Zenf91Nq6MIhIY7khy CIhzxGlcpHxtkC8P0Ky36HQjudC09j8dkXp/ltjQxwiS/6eNtnAo123CIiCSlAfvTfLFHQwuo9s /ED7tCsjkR2RrXJez6RF2XNYyRQAsC3sMHtuchamIO6fyV4GZkJz+mFo1p6d9y4NM3mU+3gyM4Z PaVYxPbzPbT6r5AJYrGL788XOaYLphkhTyuw6lx+VzwGd82hciDmN7HNFmozG4B+WMkNbdpgf0n MYLsqFyscUhPINLD3KddxZ3CvCuUABjvKtR34eWnJL8+ITdxVxMY2YdU5hi7VQ= X-Received: by 2002:a05:600c:8184:b0:4a0:1c17:4fb2 with SMTP id 5b1f17b1804b1-4a18e4d854cmr419203925e9.31.1792141303958; Fri, 16 Oct 2026 02:01:43 -0700 (PDT) Message-ID: <4912ef60-b5e9-4f48-8043-97f51359e7a4@suse.com> Date: Fri, 16 Oct 2026 11:01:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 14/15] x86/PVH: log Dom0's E820 map earlier To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1792141304-593C4CFC-7522B6E8/10/78276251493 X-purgate-type: spam X-purgate-size: 2144 On 16.10.2026 09:24, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:26:24AM +0200, Jan Beulich wrote: >> Do this as soon as it's final. For debug builds also mark it final, with >> assertions put in place to make sure it won't further be altered. (For a >> release build such further altering isn't the end of the world normally, >> so the situation is left alone there.) >> >> Switch to using %pd while moving the code up. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/hvm/dom0_build.c >> +++ b/xen/arch/x86/hvm/dom0_build.c >> @@ -46,6 +46,9 @@ >> */ >> #define HVM_VM86_TSS_SIZE 265 >> >> +/* Marker set once Dom0's E820 isn't supposed to change anymore */ >> +static bool __initdata e820_finalized; >> + >> static unsigned int __initdata acpi_intr_overrides; >> static struct acpi_madt_interrupt_override __initdata *intsrcovr; >> >> @@ -195,6 +198,8 @@ static int __init pvh_steal_ram(struct d >> struct e820entry *good = NULL; >> unsigned int i = d->arch.nr_e820; >> >> + ASSERT(!e820_finalized); >> + >> /* >> * Alignment 0 should be set to 1, so it doesn't wrap around in the >> * calculations below. >> @@ -241,6 +246,8 @@ static int __init pvh_add_mem_range(stru >> struct e820entry *map; >> unsigned int i; >> >> + ASSERT(!e820_finalized); >> + >> for ( i = 0; i < d->arch.nr_e820; i++ ) >> { >> uint64_t rs = d->arch.e820[i].addr; >> @@ -1759,6 +1766,13 @@ int __init dom0_construct_pvh(const stru >> >> pvh_place_initrd(bd, &elf, &initrd, &blob_start, &blob_end); >> >> + if ( opt_dom0_verbose ) >> + { >> + printk("%pd memory map:\n", d); >> + print_e820_memory_map(d->arch.e820, d->arch.nr_e820); >> + e820_finalized = true; > > You want to pull setting e820_finalized out of the if body, so it's > not tied to opt_dom0_verbose being set I think? Hmm, yes - not quite sure what I was thinking. > The rest LGTM, so: > > Acked-by: Roger Pau Monné > > With the above change. Thanks. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:01:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:01:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451409.1666483 (Exim 4.92) (envelope-from ) id 1xHdoz-0005B7-Lw; Fri, 16 Oct 2026 09:01:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451409.1666483; Fri, 16 Oct 2026 09:01: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 1xHdoz-0005Ay-ID; Fri, 16 Oct 2026 09:01:49 +0000 Received: by outflank-mailman (input) for mailman id 1451409; Fri, 16 Oct 2026 09:01:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHdox-00055c-Rd for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:01:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xHdox-00000008If6-3CZf; Fri, 16 Oct 2026 09:01:47 +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.98.2) (envelope-from ) id 1xHdow-00000009nZx-3CSC; Fri, 16 Oct 2026 09:01: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" 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=9l6ILVn5Mwka2MpvKFVuK9IM2uahTQEpexnlA4EcNH0=; b=pZr0Qtbh9RaSk6rcqIwCdrgGXn Dura9xAhsqdKDIFCV47BaUsbK8IeX9W+/ShMF6dEJo9vW9gBmcz8ZFmF6LqrBLqg+QGP9LC8me4IU 3yQf9hknPAqFBT5Kb/GS1ZcWwzXjsGwTCInRNc1i8H5Baxp+6UMDsG5Rq9ov5ZtlFePU=; Date: Fri, 16 Oct 2026 11:01:45 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Marek Marczykowski Subject: Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <78cd46cc-84ed-46df-96c9-26ce97ed0da0@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, Oct 16, 2026 at 10:58:09AM +0200, Jan Beulich wrote: > On 15.10.2026 19:41, Roger Pau Monné wrote: > > On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote: > >> @@ -867,7 +1078,7 @@ static int __init pvh_load_kernel( > >> } > >> start_info.modlist_paddr = last_addr; > >> start_info.nr_modules = 1; > >> - last_addr += sizeof(mod); > >> + last_addr += sizeof(*mod); > >> } > >> > >> start_info.magic = XEN_HVM_START_MAGIC_VALUE; > > > > Isn't this still not properly ordered, as start_info address must > > strictly be below 4GB (as is passed in a CPU register with the CPU in > > 32bit mode), yet it is allocated last in pvh_load_kernel()? > > Well. For one, this is pre-existing. With the size of the region that > find_memory() needs to find greatly reduced when the initrd isn't > included there, there's about zero chance that it won't find a suitable > region below 4G. Once we have find_memory() go downwards from 4G, the > remaining little bit of a risk will also go away. Might be worth mentioning then, so it doesn't look like an oversight since you adjust the ACPI allocations. No strong opinion, just noticed it was left behind. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:04:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:04:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451419.1666492 (Exim 4.92) (envelope-from ) id 1xHdrL-00060I-1X; Fri, 16 Oct 2026 09:04:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451419.1666492; Fri, 16 Oct 2026 09:04: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 1xHdrK-00060B-UB; Fri, 16 Oct 2026 09:04:14 +0000 Received: by outflank-mailman (input) for mailman id 1451419; Fri, 16 Oct 2026 09:04:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHdrJ-000603-PE for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:04:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHdrJ-00AaeA-2F for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:04:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1e886-e002-0a2a0a5209dd-0a2a450a9f96-38 for ; Fri, 16 Oct 2026 11:04:12 +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 6ad1e88c-f2d2-0a2a450a0019-d155802ec56c-3 for ; Fri, 16 Oct 2026 11:04:12 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a172eb31f0so55270575e9.1 for ; Fri, 16 Oct 2026 02:04: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-4a1c8ad6252sm61190715e9.5.2026.10.16.02.04.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 02:04: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=1792141452; x=1792746252; 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=Q6TUpuvrBn9Ib3+d/1jzY2oqfFrVO2WbbWZ2t+xu0Tg=; b=Gs/i+Nu/Y7u5fVJErlxftltFj/OpFz1LI/4XRRAUXCKZ5ZGsYs8gFfB10GYu7VuRVQ 4mBjJ4nojMSUDMJSGJz8OXFfh5whXmoCKCgcySMPghGg7e61wV8mNhHP463oZKwmnDW1 hRcTwvh2JjCpmRf3dZN2LhjpezvAwFMhaZFfZp5nB0rX8EubXkH9XyzOwNdv6vYoAstp ehmp2kq4TG5E6Dro+EX7lULL9jakwpW0xn00M78QzSKp2HFJbBpbnDkEzCQfIidBrfU8 DMoaaMicdtSS2wbiUEcRNt7He35gFzl21QXkvQANZ1Z59Fiq7cdTRy7Y5L74JqQZH49/ bHVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792141452; x=1792746252; 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=Q6TUpuvrBn9Ib3+d/1jzY2oqfFrVO2WbbWZ2t+xu0Tg=; b=1zpRzTzQgbhxX++WeQNp0eqDpIoyWBfHpnAc5unMEgiOyYuRObLhHIk0jlL3pWKpeF 0b0r3ohiQp/OglcSLp9ZdDpJKm+LE6SmOkqjh9/rpxOTd6U69DdweFgXQp23biY31R7S eDBExxRZfqdvIJCWdgKVqbPvCDOPodxTf19J8nN04iJ5NgRShtupZNhhofcpHo4wRJYx nxWuU7/pt1SyWjFg2+QixtGQHDsqDx9zqGe1x9ag5OfWhj6FYIbe83iO9bql7MX2innU SKB+kPj2Dte72f2wIiYRAa0mzob8LKkTOe4zEQgK8WsIywsDM+AhmreOxaHGrdqMTRFu oTyQ== X-Gm-Message-State: AFq9FYJFtEMB0AimphQNC3Yc3jzkRRkQA10oiQLXudPrI447slCmftMA d/2LjssKA0iFcOn+E2KI1KZ9k8cWKvmk9KeXtbr5tMU+4JJrzEAZHwCREl1pee3sHPANd9dPIv7 /jPgABg== X-Gm-Gg: AYBFou1XdNCMkLVRXNPnEWrj0LEFui4c/oeIr+8qoz4bpe46JrpZb+fVd3h0Uw14DTp oDFhg8V4daYpnCNULqeEw/1fdcgqMWrBPFk0LEK433B0U4a228HTRXY/gQqsme4P/BDYH4ILNiu CJNoRxH/QB80I6kKyiwoBrV7KKq+iZNiQRp1a252h9S5JnaWJb7iIYuwNpYDabvHdxjp5tRgeLT 9pJgOJFYy+bD/md6npSwGTSQLGJ2pbz650GoMCkgCEybaHcUdR9eV+HpN6v663av19R6tQDaWFz aZRN+H3V/KpkM7Dx+UwSGrLoigwxHBGcsZzyzBMzY1pnj+pIGcAOCrKE0DNWxpb8OcDMTRHd9L7 pTLO0G8HWT5SLgN8lu53UiFEvRmRvzZ3Uu8VS4wiY8khSb+dBodFMMDjJ5upzdUAiC+cgTCzSrH ZEvHxzxf2wghkmbfaplxl68BdR/cqsiXwdy9f4nDsj02sdfiCBsTc2lV6dbmks6fBPkH//z5/D4 1UK/VF6/lyljrxip2b734SXtlxLE1QYrL7U1WN4o5CdrNZt4MKd2rYOjfj3oA== X-Received: by 2002:a05:600c:8b65:b0:49e:6683:d23c with SMTP id 5b1f17b1804b1-4a18e3ef1bdmr414743595e9.0.1792141452422; Fri, 16 Oct 2026 02:04:12 -0700 (PDT) Message-ID: <0619015c-04ab-4310-af1d-430e1b028df3@suse.com> Date: Fri, 16 Oct 2026 11:04:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 15/15] x86/PVH: simplify writing of Dom0's RSDP To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@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/1792141452-58DC7CFC-5CF778E5/10/78276251493 X-purgate-type: spam X-purgate-size: 1043 On 16.10.2026 09:34, Roger Pau Monné wrote: > On Mon, Oct 12, 2026 at 10:26:58AM +0200, Jan Beulich wrote: >> Now that we establish where the RSDP is to live before actually loading >> the kernel (and writing start-info there) we can simply hand the pointer >> there, eliminating the need for the (fragile) separate write to the field >> out of pvh_setup_acpi(). >> >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. > One nit below. > >> @@ -1642,20 +1641,6 @@ static int __init pvh_setup_acpi( >> return rc; >> } >> >> - /* Copy RSDP address to start_info. */ >> - BUILD_BUG_ON(sizeof(info->rsdp) != >> - sizeof_field(struct hvm_start_info, rsdp_paddr)); > > You add this BUILD_BUG_ON() in a previous patch and remove it here. > Maybe it's not worth adding? I can drop it. Imo it should have been there from the start, hence why I added it in the earlier patch. I can drop it again from there, sure. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:06:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:06:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451432.1666501 (Exim 4.92) (envelope-from ) id 1xHdtb-0006aZ-CA; Fri, 16 Oct 2026 09:06:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451432.1666501; Fri, 16 Oct 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 1xHdtb-0006aS-8b; Fri, 16 Oct 2026 09:06:35 +0000 Received: by outflank-mailman (input) for mailman id 1451432; Fri, 16 Oct 2026 09:06:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHdta-0006aM-3x for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:06:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHdtZ-000BF6-Gf for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:06:33 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1e915-2eae-0a2a0a5409dd-0a2a450cc7ea-22 for ; Fri, 16 Oct 2026 11:06:33 +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 6ad1e917-f479-0a2a450c0019-94a39744d558-3 for ; Fri, 16 Oct 2026 11:06:32 +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 69FMcKZV1065043; Fri, 16 Oct 2026 02:06:26 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021074.outbound.protection.outlook.com [52.101.52.74]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb7t192wn-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 02:06:26 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6529.namprd02.prod.outlook.com (2603:10b6:208:1c3::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.13; Fri, 16 Oct 2026 09:06: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 09:06: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="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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=wqZO3ODQIkCMzvMj1tQkSWaVwl48sxLNIhAsc30MO k4=; b=PmfoQ+yKNmBw3lvvgD1e3vu1dOMGs0QKpQCG31TenhzqyI6ZUgQgN71Nl rkBPf8kDKDzC7xshMilb/Klq0KGPk3oi/rY+5BCFOkHOzTXJWutKv3WDSnrLrgoc dTxujI+4kyewOCOIDJ7tBJdaPFBbVv6pKuFJ/Algu1zYoljHeoGm+o9f+3VeIqO4 SfJRaSMYy0oqGHNV5ThzyYiykbYqJO5kQgaf9ZBqMHv68tpUvc6FVM0EsZ3H2FVK CL74QQvu+iTDCmFq4bEPIQeugC1sCp6sKEhHpSJXskb57/JmUReRmhJ/NrFM8f7z 6b/DnNNLPwvz3u5uds36DPjqH1fkw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ph94Y2dKvhqhuaYFuNJ8y/o4j5Rk+BdnB5kTidRLCPmczb/Oq1e6TlkQE1tWJYTnwc26Lc+j8Z3GOrWa3rwzFihatGIXyrynyx/Bu7Q5rIicQqBhiHC5kiIWPiH1EV9Uafi1HZdLrOblg74/4bam04fkkIgtjlAU55habfRGY6ghnZQx+fYQEDJeNOo7f/mlnAhZ87w+f826o/f22O0Rkug4Y9H3EuOvP/3Ka3IQRl7cEntUGbKqVC3KQcwsBDo0STW/Pj8h9kpoadpKq1+FPnFTOImu8cyzYTD5L3JEiLM+XQI7pKdMmDFgCY52mei24tFusq+ZPhwbzrrXNvPGGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wqZO3ODQIkCMzvMj1tQkSWaVwl48sxLNIhAsc30MOk4=; b=wvFQfXx8XV9Mb48dpvk2DP4X5/8LftTCWV7J9ZmEBwZV9d/NSLwKJwNM01q6R0FpvKHJYzPc7iL5PkWnVLYzULEqturZ5TeGB/DponmtI74C259pK8tz9YdQv5aomJGnZKyf8Tw/02UjsHz3RgotuxieVBe4tOql9cJ62KqNY2DzA74D9gj4/KAdU/k0hWuO/9YtzWH8MS9l3baLOh2HaVo70ppFdgNAGJCaB2Hi1tXbe/FHf1p5KIUkZxjzf4rkjuW8IzCcdsYMzDOFjy9cSXQy7nGzGcW/w9B6F4jKSE0FdagF92S7y3sQgBFJNMzFjPjNnpvSeZPhmDIQUatbIg== 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=wqZO3ODQIkCMzvMj1tQkSWaVwl48sxLNIhAsc30MOk4=; b=Pf2QUDYY154pecVdknL5awMIspnREapzZ/X8kx8iNeGn+SmAUTC0LRlZhBA35B5dKPNjULgj3nkL8+/7ucHYeGR57ZbiD28KnzVYkd6iJoAeqO8m4LxTguJaBTLe9InfA9qbxVWCEkyw4nbnBQnwWsStwICHOiKtRbFKR+jG/rSRH1X4t7pjL4X7J+H6AYNIZARpHRzaMPqLfWBPW6/5ZByzUsyzvR7wgkAGj9d4iyVoAL9ZazzILpsPUPe19qV+NtcBxc8PsggOSU/iWglqPOD1kPkUhdwz/HMMGYL3i48+iSkT1yLLyrmmD5ZpDSoiLuR0m6uMXU0XxgVsFQoRjw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <345aa187-30b6-4726-87ed-ee49f7ce2fea@nutanix.com> Date: Fri, 16 Oct 2026 10:06:19 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/22] i8259.c: move parent_realize from PICClass to I8259CommonClass To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-6-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR13CA0171.namprd13.prod.outlook.com (2603:10b6:a03:2c7::26) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|BL0PR02MB6529:EE_ X-MS-Office365-Filtering-Correlation-Id: 23282ff1-9e36-43a1-bf91-08df2b64c0b7 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|56012099006|4143699003|261009223027099003|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: n37ktnaQMxNzYt2CUUjB5+PJK93fHOMj2aK47wM+K8ao+paPmrVePiMPuZkXZTs5U13ncE2DDU2+NPnJW5tvzlVDlM3s8gn32I7WY7CDdzwNnmimIfLde2FYhdPEKnCHC8mxknl/R7lRV/Fodtpbo/i0dSMIhhwGIIS39gfH9L7Mt8m9JaJKaq6mz496QENlqquQkap+q+kygYuFTSd+LWYXznfNvxFh58T8VCcaB8AfOe5nKVXC/ck6vW87lm3nhycxwbPwFIcT2e9qpTaCZy5CGcZmPNztDMW8UAtQ/mJGdFSTO7Q/lbn+xFyiXyyxA1vv++0kH3hb0LJ5fZJONBcijgVmKOn0paEJ9/GeqPpOzFw5LcSgf7i7ud7GCu0jsHCSwdYDxP7E8DXtRQMD4QAxyU9G5vLS6PMx7bGllrjnPjPrYDM2ez5uS8OJvmb5i5OyiQj4uz7Htsbvz4qH7zWu8Zw4b1GgmRrNYqZv94jG58N7IPdrNMLLcfb5MpEITZeis2HxqLydc3aWFzIxYR7ML0bURKS56UL+Uxmz4XoH8lP/fHQRMth/99l+tR5AiyFy5v2oYRupczjq52YTLpFV8V2VYWzP7mYYf4aPevzsOiUKsQ9VpJjolpS2X2mFovv9bltngTKBaVl7bKDm2+rnt1u/aqFL2Jl54j01g1k= 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)(376014)(1800799024)(366016)(23010399003)(56012099006)(4143699003)(261009223027099003)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a0ZnNEJ4K2FSQURQNDYvcGlKUXBmSEJHdVBkYko3dzJ5Y0JjdTlSSDQwVTlW?= =?utf-8?B?SkdiVjh2Y2w1V2NpYjlodmxGLzFUR2YwRUdoTy9nbW1VZzRPcXdnL3ozOEJG?= =?utf-8?B?d3U1Um9aV2tUWXZKT3N2dWlzQ2x4ZituUkVKMnVENldxLy95UWpWZ0djbW50?= =?utf-8?B?VUNEZEhiclpqbTFjNVBnQm9WdGNoSEZxTWozb1plbitVODFGR0IwWXpYeFkx?= =?utf-8?B?Nk1zSGxMc0VlOWhOcVcrUnVVdThuYS9FbnRTSUpJOUVyQVhxMTZpWkUreXdy?= =?utf-8?B?aWFvc3JnMytOUkdRRmhnV0dvTVA5TnMzWlRjeTkwTzllcUhpNGFIdldPRFNq?= =?utf-8?B?MGRhYjUxMjBEdUNXcUMwTTVMZGdJeHZkQ1hSWE5GVzF6Q0F5VlZlWm9VWm1u?= =?utf-8?B?WDQ0b2RPMzZ5S2h5QzNhQnlGRVBSdEhrY1hvMXhqOWdwcFpNaVIzTlBHVmhw?= =?utf-8?B?NzdhU3ZEWDZONnJPK3BkNGJWa3VSYmFDVlhFRjlLZlJuWFhBTHVkSFdSK2JU?= =?utf-8?B?TGJYemZHVUZITmQ2eUJ4bFRnWlNwVnBPNXh1eStJUWlQbitFc21SelN6OFlS?= =?utf-8?B?UUlzV3dKNGNnTE8xR0c3ZnBtRXZRRUxHYmpiNC9sZUFSWnlKMnJwTmNrOXpy?= =?utf-8?B?NVAwUHRIQW5sL3czRWZRTFBYVG5lQW9mYXN2a3lZUHcwYnJ2VExaRVpKT0hh?= =?utf-8?B?QmxuTUVKTEs0blNPM01DdlRuTFc5U2VMbzYyM2M5blZmT1FjMWNjVVMyRitL?= =?utf-8?B?UlNpd3hGNTJvdEFiYUlsS0JzbVZwMG5vOW9WR3VTSmdibldCbGNNV2NvcUVu?= =?utf-8?B?dDVXcFovRmIwc3V4L1JMcFBNUm9BZGhYYlR0WnRTSS9PcC9Wb1AzUTJGMEJq?= =?utf-8?B?Q1NLWjlIRHNlSUdacVFsL2ZyZjZuRjRvQ0FhMkM5U2RXQjQ4UUVSTlRHT2Fi?= =?utf-8?B?MFJwMENJZGtycmp5QVBJc0FHZVAzVzk3UzNrZzgzYVhaZWNzSysvTU5GZlZU?= =?utf-8?B?dzdPTzNJV0VUV0ZxU2FsZ1pmamRXUit4Uy9ZVVpoUUNqd1RMRjdGOG1EZFFN?= =?utf-8?B?dUYrYkViZ3FUZEpaeERJd3BxYWc4Z2tRRzJWZHBEMmgzZkdkRWJCb2hKTU8v?= =?utf-8?B?Vk8ycUNnUThmYnk2d01tK1lUZnFMcFpDRGlIb2dQNTdGKzhkc2padmZCck9Y?= =?utf-8?B?NFRYYTNZSzhFNkZ3UXJMMjhFVTR5L3VHS3VubHAzclE0V1NhV2N4VzJReWlH?= =?utf-8?B?eEZBa0tIUzN6TnkrcVFtbGp5bXFqOWd3elo2am1vYUd4MTFvS1dxWUErMXNm?= =?utf-8?B?dGpNVlNkY2NnYlIzYnF2ZXZqblZxV0FoY1M1S24yWWNwUkxYME5yRjg2VVkx?= =?utf-8?B?R2FYSkZ6SFJQc1d1OG5mb1AzV0I1UUJCcEpJNDFaUjU5UVFBTFBmTmZNQnA5?= =?utf-8?B?S1RBcFFHUFkvTFJwNFhrVnNwQmNYM29zY2ZnNGltM05aZkFHZXpkTVA4aCs4?= =?utf-8?B?VllGZ3FNOEhzNzFFSm50ZlZNVmdlU2x6VkxjK2pRV0NtaU5EblFjYWo3N212?= =?utf-8?B?Y2RKYU5TRFVQRHpmeUhYWFRkamo1RCtxMWhuYm1pcDRSMzZkS2V0WkY5YnRm?= =?utf-8?B?WWRJYXhidWhHN1pTWG9TUXl4c05ZUkl1ZEZRMG1wang2cUhpMEVoY2g4RXNC?= =?utf-8?B?YlZsdEtKLzdSNGpkbjlmaVMzK1hQdHc3RnEwUjMxZUpncXJKTDFteERUMEsw?= =?utf-8?B?ek1IbTBDbnIzeGh5em92d1ZaVTlacFY3ZmVBMGw3NDRseXpVWjI0YmZRejRP?= =?utf-8?B?RjdpYmFnOU9OWGFzbDJzSkZNdzdnb0xYbTgxb1ptckhONnhJRW94VldaNUNB?= =?utf-8?B?S3hjZzUrTW40ZTFoRFR4ODAvS0hVbU5IRjNXR0lwMHZmSG1JdE9LU3NSMmEr?= =?utf-8?B?WXMzcWhlVzN0UmN4L3psNnZrZDVmVUNLdGxYckd0NGhUUjc5RVF2VUxpN3Jq?= =?utf-8?B?a1U1Vlp4YmUzRXdyZDI3NWdCZ1dBeHZUVHF4Yjk5anlkRU96a2R3UGZDc2pD?= =?utf-8?B?bWFlekdnNXlTTDRFVS9lU0ZTaUlCZ1liOSsxaVZaYXhRZWNqVEN5S0RqeERS?= =?utf-8?B?Qy9TOTg5TVZIK0pkeEpLTU9KTEhoVjhvVkRBU2JLK21oTHdQQnJ6cHo4QlBx?= =?utf-8?B?TWQyVmJhVEhYRGtGM1loQmNNOUkrS3pEelZZVkQxbTdJaE5VTGh2bTJVTlhl?= =?utf-8?B?Zk5hTE81MXdadnlDS1JESm5Xb1dHcFRvZE14TzVNRkd5N2U4ekZxUEFDWGhj?= =?utf-8?B?eHRmTjUxYXJVYUNsN2pZZHptcWFrekorMHdvL2hJaFBRWVpoWVFSeTQzanNy?= =?utf-8?Q?rSQkWE8bejYYQT2o=3D?= X-Exchange-RoutingPolicyChecked: JlXi6sZo8HTR23yWqMlrBcCzXQ95HS13zsKvEvkT5j37i29jesFmhQHCb/o8+S3KzM5PmjxMUwqqVxwv4VsZEsmFsZipYwcal9omIZ9L2UV5DUiIAUMlRcrPDfKq4Qnw81Nb6/8V+iI0TZ692e5c27kzmO0txfcUXAqdnHJHvuLtIpI+XvVrNKpi+KG0tRQyjDW9rJn8BEC+t+m+5Sptqhkv2yCk0QUUuurzDKErQuO8tz75cdPAvUpcdV3z5ULak+XCyOQATDMbrLWwq1ifp04vgqeQGef95QA9nz6trGO2/bcBpoYTW1uF+R1JIk+etLdOs3kS/rHZtFNYpCumuQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23282ff1-9e36-43a1-bf91-08df2b64c0b7 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 09:06:24.4874 (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: VhqSsAaMb4s2sfuAqtFYqDjVLn+RGv/rwTY99O4VvdiEx8trdwJQQWWZHnkWpfeidtgq7xtmfjZbYianE5N96y8ct+YaCxyG9/EU9Ho09vc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6529 X-Authority-Analysis: v=2.4 cv=LsYHWXdc c=1 sm=1 tr=0 ts=6ad1e912 cx=c_pps a=b/aSlx19e507fu+kRueGxg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=KKAkSRfTAAAA:8 a=64Cc0HZtAAAA:8 a=zOK0QRzV0C4MD-MyP_wA:9 a=QEXdDO2ut3YA:10 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDAzNiBTYWx0ZWRfXxMDU593979+c Ggv1vx9yp6YpZVx/hRQtNkERF0jdqlk93zcck9+xFIBREpbk6W0nMTEZLQ65SGtZnVxkfMb6Rql dOtq+oT59pfShJn3Vj9DFzS3M8wFiFw= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDAzNiBTYWx0ZWRfX5Syw7+l02HBX j8xq4/CbIgS1SviCzGFPrA99ExOvSFO+oI1zDIsqEznnAvcahCN29ljTfIblSdudScGzOAQeqME 4k9c0lMdZ92FZZgeleqoeT3bZvSi6HhmORq7+hDlCVTAKVkDWmOT+FYS+3XRo4MK9MNpot8zC1N lUlZQay7qE5JThctQ6NrljBkdJd+d853UuSBIAaAVFWjKTkS2X+VIUfPTrTF1NV/nXHt5A2DjOW nAMmIE23lrA9z+l5ekwpR7gxn+EUf9UUIFSZXNm4PuVea1xAOUYN1jjHfOHbxMb7bLky5W7kA2T bPhJ2YnEdzXwNPKNLgCO9o0BOyTJF3q4bW98WdC6VMZK0bFvizke7pUbGFbqDCRxH2nmlnBtGBX b8SzGCInDa7iYJCSAdK9tAl4zZSbhOYo2l5/2lcpDsKHSuBGfs1z4xU3H56756Khvtyy735PXNu NjwmwQCxgsS9BHshTlA== X-Proofpoint-ORIG-GUID: oIGeMBYcHoPTLMJDunahfV3X9UJ1p9rm X-Proofpoint-GUID: oIGeMBYcHoPTLMJDunahfV3X9UJ1p9rm 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-10-14_01,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1792141593-5270FA5B-E01B4D08/0/0 X-purgate-type: clean X-purgate-size: 8326 On 15/10/2026 17:22, Peter Maydell wrote: > On Tue, 13 Oct 2026 at 16:54, Peter Maydell wrote: >> >> On Wed, 16 Sept 2026 at 11:49, Mark Cave-Ayland >> wrote: >>> >>> 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 >> >> This is one of those things where I think we're not 100% consistent >> about whether we think the parent_realize field should go in the >> child class struct or the parent class struct. The name "parent_realize" >> implies it ought to be in the child struct, though, and I think we >> do that more often than we put it in the parent class. > > We do, although it's a bit closer than I thought: about 50 callsites > put the parent_realize pointer in the child class struct; about 25 > put it in the parent class struct. So I think for new code we should > prefer to follow the child-class-struct version. > > in child's class: > > hw/arm/smmu-common.c: device_class_set_parent_realize(dc, smmu_base_realize, > hw/arm/smmuv3.c: device_class_set_parent_realize(dc, smmu_realize, > hw/display/macfb.c: device_class_set_parent_realize(dc, macfb_nubus_realize, > hw/i386/kvm/i8254.c: device_class_set_parent_realize(dc, kvm_pit_realizefn, > hw/i386/kvm/i8259.c: device_class_set_parent_realize(dc, > kvm_pic_realize, &kpc->parent_realize); > hw/input/adb-kbd.c: device_class_set_parent_realize(dc, adb_kbd_realizefn, > hw/input/adb-mouse.c: device_class_set_parent_realize(dc, > adb_mouse_realizefn, > hw/intc/arm_gic.c: device_class_set_parent_realize(dc, > arm_gic_realize, &agc->parent_realize); > hw/intc/arm_gic_kvm.c: device_class_set_parent_realize(dc, > kvm_arm_gic_realize, > hw/intc/arm_gicv3.c: device_class_set_parent_realize(dc, > arm_gic_realize, &agc->parent_realize); > hw/intc/arm_gicv3_hvf.c: device_class_set_parent_realize(dc, > hvf_gicv3_realize, > hw/intc/arm_gicv3_kvm.c: device_class_set_parent_realize(dc, > kvm_arm_gicv3_realize, > hw/intc/arm_gicv3_whpx.c: device_class_set_parent_realize(dc, > whpx_gicv3_realize, > hw/intc/arm_gicv5.c: device_class_set_parent_realize(dc, > gicv5_realize, &gc->parent_realize); > hw/intc/i8259.c: device_class_set_parent_realize(dc, pic_realize, > &k->parent_realize); > hw/intc/loongarch_dintc.c: device_class_set_parent_realize(dc, > loongarch_dintc_realize, > hw/intc/loongarch_extioi.c: device_class_set_parent_realize(dc, > loongarch_extioi_realize, > hw/intc/loongarch_extioi_common.c: > device_class_set_parent_realize(dc, loongarch_extioi_common_realize, > hw/intc/loongarch_ipi.c: device_class_set_parent_realize(dc, > loongarch_ipi_realize, > hw/intc/loongarch_pch_pic.c: device_class_set_parent_realize(dc, > loongarch_pic_realize, > hw/intc/loongarch_pic_common.c: device_class_set_parent_realize(dc, > loongarch_pic_common_realize, > hw/intc/loongson_ipi.c: device_class_set_parent_realize(dc, > loongson_ipi_realize, > hw/intc/loongson_ipi_common.c: device_class_set_parent_realize(dc, > loongson_ipi_common_realize, > hw/intc/pnv_xive.c: device_class_set_parent_realize(dc, > pnv_xive_realize, &pxc->parent_realize); > hw/intc/pnv_xive2.c: device_class_set_parent_realize(dc, pnv_xive2_realize, > hw/intc/spapr_xive.c: device_class_set_parent_realize(dc, spapr_xive_realize, > hw/intc/xics_pnv.c: device_class_set_parent_realize(dc, pnv_icp_realize, > hw/intc/s390_flic_kvm.c: device_class_set_parent_realize(dc, > kvm_s390_flic_realize, > hw/nubus/nubus-virtio-mmio.c: device_class_set_parent_realize(dc, > nubus_virtio_mmio_realize, > hw/timer/i8254.c: device_class_set_parent_realize(dc, > pit_realizefn, &pc->parent_realize); > hw/virtio/virtio-pci.c: device_class_set_parent_realize(dc, > virtio_pci_dc_realize, > target/alpha/cpu.c: device_class_set_parent_realize(dc, alpha_cpu_realizefn, > target/arm/cpu.c: device_class_set_parent_realize(dc, arm_cpu_realizefn, > target/avr/cpu.c: device_class_set_parent_realize(dc, > avr_cpu_realizefn, &mcc->parent_realize); > target/hexagon/cpu.c: device_class_set_parent_realize(dc, > hexagon_cpu_realize, > target/hppa/cpu.c: device_class_set_parent_realize(dc, hppa_cpu_realizefn, > target/i386/cpu.c: device_class_set_parent_realize(dc, x86_cpu_realizefn, > target/loongarch/cpu.c: device_class_set_parent_realize(dc, > loongarch_cpu_realizefn, > target/m68k/cpu.c: device_class_set_parent_realize(dc, m68k_cpu_realizefn, > target/microblaze/cpu.c: device_class_set_parent_realize(dc, > mb_cpu_realizefn, > target/mips/cpu.c: device_class_set_parent_realize(dc, mips_cpu_realizefn, > target/or1k/cpu.c: device_class_set_parent_realize(dc, > openrisc_cpu_realizefn, > target/ppc/cpu_init.c: device_class_set_parent_realize(dc, ppc_cpu_realize, > target/riscv/cpu.c: device_class_set_parent_realize(dc, riscv_cpu_realize, > target/rx/cpu.c: device_class_set_parent_realize(dc, rx_cpu_realize, > target/s390x/cpu.c: device_class_set_parent_realize(dc, s390_cpu_realizefn, > target/sh4/cpu.c: device_class_set_parent_realize(dc, superh_cpu_realizefn, > target/sparc/cpu.c: device_class_set_parent_realize(dc, sparc_cpu_realizefn, > target/tricore/cpu.c: device_class_set_parent_realize(dc, > tricore_cpu_realizefn, > target/xtensa/cpu.c: device_class_set_parent_realize(dc, > xtensa_cpu_realizefn, > > in parent's class: > > hw/input/lasips2.c: device_class_set_parent_realize(dc, > lasips2_kbd_port_realize, > hw/input/lasips2.c: device_class_set_parent_realize(dc, > lasips2_mouse_port_realize, > hw/input/pl050.c: device_class_set_parent_realize(dc, pl050_kbd_realize, > hw/input/pl050.c: device_class_set_parent_realize(dc, pl050_mouse_realize, > hw/intc/xics_spapr.c: device_class_set_parent_realize(dc, ics_spapr_realize, > hw/isa/pc87312.c: device_class_set_parent_realize(dc, pc87312_realize, > hw/isa/vt82c686.c: device_class_set_parent_realize(dc, via_superio_realize, > hw/pci-bridge/cxl_root_port.c: device_class_set_parent_realize(dc, > cxl_rp_realize, &rpc->parent_realize); > hw/pci-bridge/gen_pcie_root_port.c: > device_class_set_parent_realize(dc, gen_rp_realize, > &rpc->parent_realize); > hw/pci-host/pnv_phb.c: device_class_set_parent_realize(dc, > pnv_phb_root_port_realize, > hw/pci-host/pnv_phb3_msi.c: device_class_set_parent_realize(dc, > phb3_msi_realize, > hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power8_realize, > hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power9_realize, > hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power10_realize, > hw/ppc/pnv.c: device_class_set_parent_realize(dc, pnv_chip_power11_realize, > hw/ppc/pnv_lpc.c: device_class_set_parent_realize(dc, pnv_lpc_power8_realize, > hw/ppc/pnv_lpc.c: device_class_set_parent_realize(dc, pnv_lpc_power9_realize, > hw/s390x/tod-kvm.c: > device_class_set_parent_realize(DEVICE_CLASS(oc), > kvm_s390_tod_realize, > hw/virtio/vhost-user-gpio.c: device_class_set_parent_realize(dc, > vgpio_realize, > hw/virtio/vhost-user-i2c.c: device_class_set_parent_realize(dc, vi2c_realize, > hw/virtio/vhost-user-input.c: device_class_set_parent_realize(dc, > vinput_realize, > hw/virtio/vhost-user-rng.c: device_class_set_parent_realize(dc, > vu_rng_base_realize, > hw/virtio/vhost-user-rtc.c: device_class_set_parent_realize(dc, > vu_rtc_base_realize, > hw/virtio/vhost-user-snd.c: device_class_set_parent_realize(dc, > vu_snd_base_realize, > hw/virtio/vhost-user-spi.c: device_class_set_parent_realize(dc, vspi_realize, Thanks for the analysis. I agree that it makes sense to put parent_realize in the child class as opposed to the parent class, and I'll make that change to my current series. I also realise from this and your previous response that I misunderstood exactly what you mean by storing it in the instance... ATB, Mark. From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:12:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:12:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451442.1666508 (Exim 4.92) (envelope-from ) id 1xHdzT-00006i-1g; Fri, 16 Oct 2026 09:12:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451442.1666508; Fri, 16 Oct 2026 09: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 1xHdzS-00006b-VD; Fri, 16 Oct 2026 09:12:38 +0000 Received: by outflank-mailman (input) for mailman id 1451442; Fri, 16 Oct 2026 09:12:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHdzR-00006V-UE for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:12:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHdzR-007oQA-An for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:12:37 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1ea7b-bab6-0a2a0a5309dd-0a2a45059cdc-28 for ; Fri, 16 Oct 2026 11:12:37 +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 6ad1ea85-4cb1-0a2a45050019-d155dd2ced98-3 for ; Fri, 16 Oct 2026 11:12:37 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48afcfc4bf5so1114251f8f.1 for ; Fri, 16 Oct 2026 02:12: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-48dfd4f9c41sm3991412f8f.38.2026.10.16.02.12.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 02:12: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=1792141957; x=1792746757; 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=f8h6BSo7sSt2Nw41p0ugsO5choButV3zT6uwUEHEcd0=; b=LACCQHTtEaf3WMvkgxjKrRPJqGibMJF6WepfpHo/jHZ1cOJxNznsRwSZiLYoZT4FR1 ihkuF5PxiIOZorQHosxSQVn+SwlNBxRnkMbR4Q66PSA16dbTTbNmAXndLN9aY8YsA8oi TS4ilr3MsBJNnjzQwHE7quinExC/miaNB8vC57Cengkrd16NzAIVEvu2ZdTD4LRDRLd8 LLRxbap2pF0Blwk1wPWhu+Ni6s9VntClKBUnGdrS46hahBQNeY9L9AWy3WbMi+PN3s7J Tgl0ARJklP7hrg06sbIdzkoanyMvv1v4trPAkutWYzzVuBelvRC4B6Eoz3Ze2dOLd1mB +TLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792141957; x=1792746757; 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=f8h6BSo7sSt2Nw41p0ugsO5choButV3zT6uwUEHEcd0=; b=H8HKb1qCR1z0wj888tWnM6r798p12Mpn+yi3l6c3MvnpTfyeLhUrQYU7wM2gWbqHUl t/+MgWugRpu0vSj1tPphX3Xl7VPLiAW+GmDkCJGXCjBpU1yHYJX1jt4qupBJFUXapOQD T2c4ovmanr/+IwkaMVv6Bg5F62M64WIjwK0ZIjI+amU8e0i0gYGPAEhm21l81/XOUIhD 4E/Xh6DO5ppAxg6eNdQa0LaxC5je9VR0K8+CTH3Y9iJHAGXJT2NwfJeCWEEgw74cUfWR I3eT4cO76yTuM7e+m9Bzzxq729RyAn8jwJ4oNrVXpdX1+gU6wPO7+KaAVXsXhVWiTbiU XsuA== X-Gm-Message-State: AFq9FYIIB+bU21fkQ9oTqMxzQyrkayKRhPBI4lYEURuJoSqXtAApHmEO 4rWqQaFxZH9mZCMgwQrHb6VQ4/jJdZfLG2mf0DMtq+DqlgQd5qyyrCVxz4x+3GqeDA== X-Gm-Gg: AYBFou0yJo6xRkgFZF0QOYgAqPyoIH8Is+luG6mdp2E0H03ecUi2sCTRIpnA1amDhrQ UgeVIqgysnptbnbboLTvK7d8sGt0LJnHI9cIA+SNOqRNpzSGHJtIzeZ2JXjpINkGdXieIjWhXt8 PEq6vTnMljk7G+Vpb+2F+qo57TjR8hed5JSzvKWrnWlptcPnIDJwoDJCHompszMBAAxp4yT2ORH u8D5auEuzztfPu5BcLcv+5XkfC74dzv3yUgIoyd6MC2YOmmoGDrl3zJ9CglTseTF/EQbYmCGC2F tYLUBDbFdrHAX/3XvMSrepm0M/ib4N5j3hDdFAemInSl9nlC3/jdxmWez4cPPTLdb9Cl/aNHElD Og1r/RD+Fd4gCsWCpKuIV6eFpnTqOQ8RUQRC+WIlKqLhEZ2kuKb05HwTHt4Mhzc49KLOTpIfyq/ LBgNGDFKIAZa637/GYdFEO82a/eViMnCqemFU9wccNLEmJRT6a4Ox7aQcW6A0/mOKMcPo37hOYZ pbH6LM6gISott98vddalOU2dMF3Lr1GALP8pzAfq/kKC0/n5DwyA1VasK4Xpg== X-Received: by 2002:a05:6000:178f:b0:48e:223:ab06 with SMTP id ffacd0b85a97d-48e0223accemr1014876f8f.31.1792141956691; Fri, 16 Oct 2026 02:12:36 -0700 (PDT) Message-ID: <764b7c0b-1a1e-4d0a-bded-28b5e9f9e703@suse.com> Date: Fri, 16 Oct 2026 11:12:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Marek Marczykowski References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <78cd46cc-84ed-46df-96c9-26ce97ed0da0@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/1792141957-247132A1-9CB8035B/10/78276251493 X-purgate-type: spam X-purgate-size: 1547 On 16.10.2026 11:01, Roger Pau Monné wrote: > On Fri, Oct 16, 2026 at 10:58:09AM +0200, Jan Beulich wrote: >> On 15.10.2026 19:41, Roger Pau Monné wrote: >>> On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote: >>>> @@ -867,7 +1078,7 @@ static int __init pvh_load_kernel( >>>> } >>>> start_info.modlist_paddr = last_addr; >>>> start_info.nr_modules = 1; >>>> - last_addr += sizeof(mod); >>>> + last_addr += sizeof(*mod); >>>> } >>>> >>>> start_info.magic = XEN_HVM_START_MAGIC_VALUE; >>> >>> Isn't this still not properly ordered, as start_info address must >>> strictly be below 4GB (as is passed in a CPU register with the CPU in >>> 32bit mode), yet it is allocated last in pvh_load_kernel()? >> >> Well. For one, this is pre-existing. With the size of the region that >> find_memory() needs to find greatly reduced when the initrd isn't >> included there, there's about zero chance that it won't find a suitable >> region below 4G. Once we have find_memory() go downwards from 4G, the >> remaining little bit of a risk will also go away. > > Might be worth mentioning then, so it doesn't look like an oversight > since you adjust the ACPI allocations. No strong opinion, just > noticed it was left behind. I've added mention of this, but only in the remark of the patch. Really pvh_setup_cpus() may want to check for no truncation? Or the parameter type may want to change to uint32_t, with the no-truncation check then living elsewhere? Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:14:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:14:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451447.1666527 (Exim 4.92) (envelope-from ) id 1xHe0p-0000nR-HG; Fri, 16 Oct 2026 09:14:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451447.1666527; Fri, 16 Oct 2026 09:14: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 1xHe0p-0000nI-ES; Fri, 16 Oct 2026 09:14:03 +0000 Received: by outflank-mailman (input) for mailman id 1451447; Fri, 16 Oct 2026 09:14:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHe0n-0000al-Ft for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:14:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHe0m-007orE-SX for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:14:00 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1ead5-8faa-0a2a0a5109dd-0a2a4502a888-6 for ; Fri, 16 Oct 2026 11:14:00 +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 6ad1ead7-6ca4-0a2a45020019-b9ff1c22ace5-3 for ; Fri, 16 Oct 2026 11:13: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a143fd43ef0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 09:13:53 +0000 Received: from Skynet-1 (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id E867381F66; Fri, 16 Oct 2026 11:13:52 +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=jhZDJ/uRT58PcuL5wb2FP//FQDMpMS0RNO/OKYNYozc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=FILaNU+3H4nZoxUQhRtkniwx5UT5WsU6U6QNDz7VcAXF6PTb31BI1AGoz++PEuBj6ESpalNPf UVeXMFnjIGRmLzGA3W5QpsMwxS46Voq/Cv6jIgkKXHDB7qwEMnqsnHXtJAMlTd2A+8qjyEfanbq 8Tmmf8/JCiyBespiiAilsOzaaWYsD15pgbHRkbxll07g73Pbw9kbo9BfXQE79UYX2fb8ggblJq7 5VtC2/AWrFRMmpsVjWfeTMxSmqdtARkjlHaxRLOOaTz8Wj81jb2lU8j5gO5/9bgtkrubJKWnNKL 7oOAu+ykd6K5Ps3JR6Apx6ormioN3ZQw9tWautNC6Fyg== X-Zone-Loop: caecabbb661e24a69649d9d6dfcd665282f38e1d8702 x-campaign-type: default x-transaction-id: 60130833-c02c-46b2-b9ec-58b1b7bc260f x-swg-uid: 01-0dbc8a69-13ae-4a75-a2a9-efbfa3a74e93 X-Mailer: Sweego Message-ID: <1792142033.8631fc262581453bbf619ec5b2062170.1a143fd43ef0008425@vates.tech> x-swg-bid: 1792142033.8631fc262581453bbf619ec5b2062170.1a143fd43ef0008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross , Jason Andryuk Subject: [PATCH 0/3] tools/libxenstat: small fixes in the Linux network collector Date: Fri, 16 Oct 2026 09:12:56 +0000 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2a2.ec0f426ae79c724a.1a143fd408c.3006d1f093e7f4ee=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792142033040 X-purgate-ID: tlsNG-720697/1792142039-F26B72AC-178D5F58/0/0 X-purgate-type: clean X-purgate-size: 2051 ---=Part.2a2.ec0f426ae79c724a.1a143fd408c.3006d1f093e7f4ee=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable While looking at xenstat_collect_networks() for commit 0c53660c1cf3 ("tools/libxenstat: don't lose all VIFs when dom0 has no Linux bridge"), I noticed a few more issues in xenstat_linux=2Ec: - getBridge() dereferences NULL when /sys/class/net can't be opened, - after a failed /proc/net/dev header check, the next call skips the check and parses the file anyway, - parseNetDevLine() doesn't initialise all of its outputs (cleanup, no functional change intended)=2E Patches 1 and 2 may be worth backporting=2E If so, patch 1 should go along with 0c53660c1cf3: without it, the empty bridge name would make every VIF disappear instead=2E Testing: libxenstat builds with the usual tools CFLAGS (including -Werror)=2E I also tested the series on an XCP-ng 8=2E3 host (Xen 4=2E17= =2E7, Open vSwitch), applied with 0c53660c1cf3 on top of its libxenstat and loaded via LD_LIBRARY_PATH: - xentop reports the same networks and counters with and without the series, - with /sys/class/net made unavailable in a private mount namespace, xentop no longer segfaults in readdir() called from xenstat_collect_networks(), - with an invalid /proc/net/dev bind-mounted over the real one, a second xenstat_get_node() call fails again instead of parsing the file=2E Olivier Lambert (3): tools/libxenstat: don't crash when /sys/class/net can't be opened tools/libxenstat: don't skip the /proc/net/dev check after a failure tools/libxenstat: fix output initialisation in parseNetDevLine() tools/libs/stat/xenstat_linux=2Ec | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) --=20 2=2E53=2E0 -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.2a2.ec0f426ae79c724a.1a143fd408c.3006d1f093e7f4ee=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:14:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:14:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451446.1666518 (Exim 4.92) (envelope-from ) id 1xHe0o-0000az-Bq; Fri, 16 Oct 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 1451446.1666518; Fri, 16 Oct 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 1xHe0o-0000as-8E; Fri, 16 Oct 2026 09:14:02 +0000 Received: by outflank-mailman (input) for mailman id 1451446; Fri, 16 Oct 2026 09:14:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHe0m-0000ad-Jj for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:14:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHe0l-007orE-Ss for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:13:59 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1ead2-8faa-0a2a0a5109dd-0a2a45078384-22 for ; Fri, 16 Oct 2026 11:13:59 +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 6ad1ead7-b4ea-0a2a45070019-b9ff1c2290e3-3 for ; Fri, 16 Oct 2026 11:13: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a143fd4e9d0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 09:13:56 +0000 Received: from Skynet-1 (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 2477481F66; Fri, 16 Oct 2026 11:13: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=sdNcgIdN4H4UbHm09K61vzUgHpaWd/G/2LuMED6huBk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=OoZPZyl43zg/W+nrzjZXNtWEquJ817wHR52isU1d6QjpSQADU7lofQ+6/2xjNI1fgI8SWyTLP xFvqfqwBQokGMRUsfZ9Xv6xYP0UVx6zlVS15GXnms4MknSlPkRDhWuS3UIb40+PBcgFpYB37Tah kcXCx5l/thWlWei8lvT8DltCJWiyutAVMa5HN4N+LvH5sHoaP4jcYV06c/7TzTJQ2d27k+2Nd6L 0W5nvxTn3uuajvxHAH6TW8+d03AOoyJ3Wsrvzal+QBN30nZu56avBqdZjmKRkC1Q2xfWeS8z+0u kq2yThq3pUOB/hMpxHx2Qis9QZ2uLX3JG9jNeafTB1kQ== X-Zone-Loop: 547bb98680937fecdedb2f8742730cac0f7c4e2e647d x-campaign-type: default x-transaction-id: e53da2f4-b329-4410-bdf0-d0d4be742665 x-swg-uid: 01-92795d43-29ad-4cd0-a59b-e0171df22f1a X-Mailer: Sweego Message-ID: <1792142036.8631fc262581453bbf619ec5b2062170.1a143fd4e9d0008425@vates.tech> x-swg-bid: 1792142036.8631fc262581453bbf619ec5b2062170.1a143fd4e9d0008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross , Jason Andryuk Subject: [PATCH 1/3] tools/libxenstat: don't crash when /sys/class/net can't be opened Date: Fri, 16 Oct 2026 09:12:57 +0000 In-Reply-To: <20261016091259.1254879-1-olivier.lambert@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2a3.4299984cb8e203e1.1a143fd4d00.d047e9d82b55c6a9=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792142036224 X-purgate-ID: tlsNG-ef75cf/1792142039-A72DCAE4-B763E3EF/0/0 X-purgate-type: clean X-purgate-size: 1870 ---=Part.2a3.4299984cb8e203e1.1a143fd4d00.d047e9d82b55c6a9=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable getBridge() doesn't check the return value of opendir(), so readdir() and closedir() are passed a NULL pointer when /sys/class/net can't be opened, e=2Eg=2E when sysfs isn't mounted=2E As getBridge() is called on e= very network collection, the libxenstat user (xentop for instance) crashes instead of simply not finding a bridge=2E Return early in that case=2E The caller's buffer is zero-initialised, so no bridge is reported, which xenstat_collect_networks() handles since commit 0c53660c1cf3 ("tools/libxenstat: don't lose all VIFs when dom0 has no Linux bridge")=2E Fixes: 1fd93d4f8cb8 ("xenstat: Linux dom0 statistics for case we use netwo= rk bonding") Assisted-by: Claude-Code:claude-opus-5-5 Signed-off-by: Olivier Lambert --- tools/libs/stat/xenstat_linux=2Ec | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/libs/stat/xenstat_linux=2Ec b/tools/libs/stat/xenstat_l= inux=2Ec index 2a7d2f1a96=2E=2Eec627f3ef5 100644 --- a/tools/libs/stat/xenstat_linux=2Ec +++ b/tools/libs/stat/xenstat_linux=2Ec @@ -75,6 +75,9 @@ static void getBridge(const char *excludeName, char *res= ult, size_t resultLen) char tmp[512] =3D { 0 }; =20 d =3D opendir("/sys/class/net"); + if (d =3D=3D NULL) + return; + while ((de =3D readdir(d)) !=3D NULL) { if ((strlen(de->d_name) > 0) && (de->d_name[0] !=3D '=2E') && (strstr(de->d_name, excludeName) =3D=3D NULL)) { --=20 2=2E53=2E0 -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.2a3.4299984cb8e203e1.1a143fd4d00.d047e9d82b55c6a9=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:14:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:14:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451448.1666536 (Exim 4.92) (envelope-from ) id 1xHe0q-00010e-OA; Fri, 16 Oct 2026 09:14:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451448.1666536; Fri, 16 Oct 2026 09:14: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 1xHe0q-00010V-L0; Fri, 16 Oct 2026 09:14:04 +0000 Received: by outflank-mailman (input) for mailman id 1451448; Fri, 16 Oct 2026 09:14:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHe0o-0000ar-Hq for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:14:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHe0n-005NV2-Nf for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:14:01 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1ead3-2eae-0a2a0a5409dd-0a2a45038dea-40 for ; Fri, 16 Oct 2026 11:14:01 +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 6ad1ead9-fae8-0a2a45030019-b9ff1c12acc3-3 for ; Fri, 16 Oct 2026 11: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 1a143fd533b0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 09:13:57 +0000 Received: from Skynet-1 (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 5125A81F66; Fri, 16 Oct 2026 11: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: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=uhYnNuNkdI4OVcGYhDCwMvk+pCB6XSQQyZ18S7eQuTY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=KvHp9D7iOpDutFW0Vs+qrjj8acKihyjdVrFFDX1VzHN2UBrcod29LHEEtSL7HjY/GgtYHu5tj QrtL7A4jFRLgSMJKZn34+0TCWGE2t1xHPDl6G1p9/cX78BZ7kjQgcaJASVVN9TUbANLzR68Km25 YjPs3bWPX0MMsObYMhc0JBnrTUvL82Zf8flECwRTgyT7X1DdDQXftDfmt3O5mFYYEj0SEbdb5ZB c2gaRlQeSl5h10wAdAE7o86c0NCnlMdlCVL4Jan07AWq/Tapw4W6sdMT+WiBBfcIQC299m1QOEB Xf3ypcDNz6QS9XR6/QO+HvFuD8m+uGzMXyk4P63KecdA== X-Zone-Loop: 3c972a539661a259d8e17a9f2b9644256a4126755f65 x-campaign-type: default x-transaction-id: 95710d7b-63f1-4b05-a629-269811f464ec x-swg-uid: 01-4e736f70-76ae-4d8c-9ffc-b77f8137f8fc X-Mailer: Sweego Message-ID: <1792142037.8631fc262581453bbf619ec5b2062170.1a143fd533b0008425@vates.tech> x-swg-bid: 1792142037.8631fc262581453bbf619ec5b2062170.1a143fd533b0008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross , Jason Andryuk Subject: [PATCH 2/3] tools/libxenstat: don't skip the /proc/net/dev check after a failure Date: Fri, 16 Oct 2026 09:12:58 +0000 In-Reply-To: <20261016091259.1254879-1-olivier.lambert@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2a4.4d5a8078f2de9eae.1a143fd51a0.22fad48d3ee40ed4=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792142037408 X-purgate-ID: tlsNG-33051d/1792142041-6E0D14E9-CFCC008E/0/0 X-purgate-type: clean X-purgate-size: 1896 ---=Part.2a4.4d5a8078f2de9eae.1a143fd51a0.22fad48d3ee40ed4=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable xenstat_collect_networks() opens /proc/net/dev once and validates its header before using it=2E If reading the header fails, or the header isn't the expected one, an error is returned but the stream is left open in priv->procnetdev=2E The next call then finds the stream already open, skips the validation and parses the file anyway=2E Close the stream and clear the pointer on both error paths, so that the validation is done again on the next call=2E Fixes: 49839b535b78 ("Add xenstat framework=2E") Assisted-by: Claude-Code:claude-opus-5-5 Signed-off-by: Olivier Lambert --- tools/libs/stat/xenstat_linux=2Ec | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/libs/stat/xenstat_linux=2Ec b/tools/libs/stat/xenstat_l= inux=2Ec index ec627f3ef5=2E=2E97f7fa9f87 100644 --- a/tools/libs/stat/xenstat_linux=2Ec +++ b/tools/libs/stat/xenstat_linux=2Ec @@ -296,12 +296,16 @@ int xenstat_collect_networks(xenstat_node * node) if (fread(header, sizeof(PROCNETDEV_HEADER) - 1, 1, priv->procnetdev) !=3D 1) { perror("Error reading /proc/net/dev header"); + fclose(priv->procnetdev); + priv->procnetdev =3D NULL; return 0; } header[sizeof(PROCNETDEV_HEADER) - 1] =3D '\0'; if (strcmp(header, PROCNETDEV_HEADER) !=3D 0) { fprintf(stderr, "Unexpected /proc/net/dev format\n"); + fclose(priv->procnetdev); + priv->procnetdev =3D NULL; return 0; } } --=20 2=2E53=2E0 -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.2a4.4d5a8078f2de9eae.1a143fd51a0.22fad48d3ee40ed4=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 09:14:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 09:14:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451449.1666544 (Exim 4.92) (envelope-from ) id 1xHe0v-0001Gp-0o; Fri, 16 Oct 2026 09:14:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451449.1666544; Fri, 16 Oct 2026 09:14: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 1xHe0u-0001Ge-Tj; Fri, 16 Oct 2026 09:14:08 +0000 Received: by outflank-mailman (input) for mailman id 1451449; Fri, 16 Oct 2026 09:14:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHe0t-0001FH-KY for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 09:14:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHe0s-002C2b-Pu for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:14:06 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1ead4-e002-0a2a0a5209dd-0a2a450bd9f0-34 for ; Fri, 16 Oct 2026 11:14:06 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1eada-b7e8-0a2a450b0019-b9ff1c239c49-3 for ; Fri, 16 Oct 2026 11:14: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 1a143fd56420008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 09:13:58 +0000 Received: from Skynet-1 (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 1A7B381F66; Fri, 16 Oct 2026 11:13: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=Y0h9d9AY+xO7OoOXqOECfFhCUG+ubXW1o8Wb0q1tvOc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=HrUwzlBuDlhiAlv24hIOlMlqmA9JOgxRglngwKyZIMDuwZcwmOIV9N38VV0gffZo6wXbaHuUH BtSidgcj7I0WUIRqsDHSsnaPB3GohU5b9KYpVYKo0B2Psj9NLiAwgeu/+joEo9ZorjGqA3oZEBx FXd5Z3medm4dwOe5sHA3Y3iAHy0IHD/UltnCjNqplS0JfOUqR9hss0cXl/q3Mv6/KSH4ReJ6L9w nEZAPRaB8b8Wvcs6HwAtsqTREL7o8xlZ6hy7FXlto7B7p40qmr9m1IbxGwC4j77kBjQd5+EXnY2 +oTLTC6ganBW4JWcYrW+D+m1Ep4B3oCvMC+FJ1dgnXRA== X-Zone-Loop: a5276eb863d98ce58e6517cb5c60d20ed3ce81d36a17 x-campaign-type: default x-transaction-id: 2d73006d-be9d-42c9-81b1-6211e7afa71b x-swg-uid: 01-679be25c-e533-4800-b881-a399e3c6d459 X-Mailer: Sweego Message-ID: <1792142038.8631fc262581453bbf619ec5b2062170.1a143fd56420008425@vates.tech> x-swg-bid: 1792142038.8631fc262581453bbf619ec5b2062170.1a143fd56420008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross , Jason Andryuk Subject: [PATCH 3/3] tools/libxenstat: fix output initialisation in parseNetDevLine() Date: Fri, 16 Oct 2026 09:12:59 +0000 In-Reply-To: <20261016091259.1254879-1-olivier.lambert@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2a5.af34a560c5939015.1a143fd54a8.db578474bea2f8d3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792142038185 X-purgate-ID: tlsNG-42698a/1792142043-A8CCF9EA-72B728B3/0/0 X-purgate-type: clean X-purgate-size: 2086 ---=Part.2a5.af34a560c5939015.1a143fd54a8.db578474bea2f8d3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable parseNetDevLine() zeroes all the outputs it is passed before parsing the line, but *rxPackets is zeroed twice while *rxMcast isn't zeroed at all, so it would be left untouched for a line that doesn't parse=2E Also, iface is cleared with memset(iface, 0, sizeof(*iface)), which only covers the first byte=2E The function isn't told the buffer size, and an empty string is all that's needed, so write the terminator directly=2E No functional change intended: the only caller passes NULL for rxMcast=2E Assisted-by: Claude-Code:claude-opus-5-5 Signed-off-by: Olivier Lambert --- tools/libs/stat/xenstat_linux=2Ec | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/libs/stat/xenstat_linux=2Ec b/tools/libs/stat/xenstat_l= inux=2Ec index 97f7fa9f87=2E=2Eaebd848722 100644 --- a/tools/libs/stat/xenstat_linux=2Ec +++ b/tools/libs/stat/xenstat_linux=2Ec @@ -123,7 +123,7 @@ static int parseNetDevLine(char *line, char *iface, un= signed long long *rxBytes, =20 /* Initialize all variables called has passed as non-NULL to zeros */ if (iface !=3D NULL) - memset(iface, 0, sizeof(*iface)); + iface[0] =3D '\0'; if (rxBytes !=3D NULL) *rxBytes =3D 0; if (rxPackets !=3D NULL) @@ -136,10 +136,10 @@ static int parseNetDevLine(char *line, char *iface, = unsigned long long *rxBytes, *rxFifo =3D 0; if (rxFrames !=3D NULL) *rxFrames =3D 0; - if (rxPackets !=3D NULL) - *rxPackets =3D 0; if (rxComp !=3D NULL) *rxComp =3D 0; + if (rxMcast !=3D NULL) + *rxMcast =3D 0; if (txBytes !=3D NULL) *txBytes =3D 0; if (txPackets !=3D NULL) --=20 2=2E53=2E0 -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.2a5.af34a560c5939015.1a143fd54a8.db578474bea2f8d3=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 10:01:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 10:01:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451501.1666557 (Exim 4.92) (envelope-from ) id 1xHekd-00032a-FS; Fri, 16 Oct 2026 10:01:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451501.1666557; Fri, 16 Oct 2026 10: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 1xHekd-00032T-Cc; Fri, 16 Oct 2026 10:01:23 +0000 Received: by outflank-mailman (input) for mailman id 1451501; Fri, 16 Oct 2026 10:01:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHekb-00032N-ME for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:01:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHekb-0080eK-2f for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 12:01:21 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1f5ec-8faa-0a2a0a5109dd-0a2a4507c542-28 for ; Fri, 16 Oct 2026 12:01:21 +0200 Received: from [52.101.43.29] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1f5ef-b4ea-0a2a45070019-34652b1d5347-4 for ; Fri, 16 Oct 2026 12:01:20 +0200 Received: from BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) by BY1PR03MB7237.namprd03.prod.outlook.com (2603:10b6:a03:523::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 10:01:15 +0000 Received: from BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550]) by BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550%2]) with mapi id 15.21.0522.013; Fri, 16 Oct 2026 10:01: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=uDIFKJpz3Xt6IKfcacKC8WyKI6XPt3oGlTvI8Q2DZNnV/Wb+v6DtODh9k4T2J7vptSljJreSWlDXH2WWToRelGpsJD7rzKoqQjbuU2ta5zLbmHASruK9xgnJLqfsiU+csgLF8STNzAYfnX43BEDjZAgklxmYBjisYIwWkb9BM2Bwf7dPNMyq1O3troK6Z9SkRqHKtUCxB3GhSMe/FoameEQOvTy7k97th+QmS+c5dO8PhG/UBWW1cAYsZKXFrKM/8AkBcwP8PU44mEdoolGw7iO8V+XpgvI8GyVAxNrcClycr1zwR3HbCLQh4Lpp4fEzDae1S6Bw86Ec1qDuwkA2gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GAO2YY9AHIx6l0GhxAGNMXgKqS3ZHmq2VRkp8fA75yo=; b=eqSsM+bX3Azna9VgstzQ2M4vFrvY/rY4u7xh4rsNks4ln8I+ZUtdQEJGaGEAtSBljYkmiq0Dw0l6eviECHikWUYeslsroGM+tqRxeKdFg6PGZ+LhYuIRLtOQvH0j8PhQl8xDwnCVs2Svb8kgvcxQQYSeZjWDb4Gf6u1ClgqHZ4nekB4SKdDFc/E51ZNBjdKv06P9LZQWfdt4TrN/yF1g9y5A6X9ojQNIhKLZzowd97Jj4Sfi33LJGJmnVGCYz1C0zMikvwHGNJc3hShLNOtQVnmGYdb+gJJ69BD5T32qnySQjfT+0V0bMbWGT7Ewi3qW8g68xwHZxLM1pNLsra3EuA== 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=GAO2YY9AHIx6l0GhxAGNMXgKqS3ZHmq2VRkp8fA75yo=; b=G5ely/n8cpMiYyVTaQMy7G8MGgz0xlF7RSpchIVxiTxqrlYJM22JmhTMb/grKmrr0u5YVT5FQpdiLAF9/juGr9cqeyttJDQCkoLmaCWggtM+szUwa5XfH4k8snRkrYkDfKaOoU1cq9jV3ueBowtljX4lNoMsvJpkZd1S0b2mMDg= Authentication-Results: mx.microsoft.com 1; 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: [PATCH v1] x86/nestedsvm: honour L2's EFLAGS.IF when L1 clears V_INTR_MASKING Date: Fri, 16 Oct 2026 18:00:58 +0800 Message-Id: <20261016100058.268266-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0148.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:ce::14) To MN2PR03MB5328.namprd03.prod.outlook.com (2603:10b6:208:1e2::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR03MB5315:EE_|BY1PR03MB7237:EE_ X-MS-Office365-Filtering-Correlation-Id: 2e6aa66c-6330-4f2d-6b89-08df2b6c68d8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|18002099003|10067099003|261009223027099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: RbuJLMg3s0+txc0yCzGw6GeHpL4opgDNtXLhUbY4MUXzMnsB+nLt2YHsebxfabdH2MscYakjYpDIcxFN+MjJTtYH05LJvzbNAARF06cIKpHoCUqpUR3VMKugP81k2IUQTFl6TC0+QLYQ/Je9RF7OZqVd8Cg1ArwA0dzJEsg2l/Isk3UYJS6c2OxyaTMbzzNThoW2QYWADf5uMFql30MxBLjeroHYSJJkdsVdU1fWPTpCs7ABpaPND3JBlLJ7FLHC96LmoEjWenQ+xB3waTIusJdqz4rmgAFJ44sOcbjqynnY2mTWSS1s+AYpazBE3e1KWY+DVcMC0cwqpdVXdmoJe36srR8pnc1lfJgBOtCZ4A4Q2N6m2ZW25yoKXUgoyw8suv11yW4/nFqAMrxE+2qaoMh3TvvWa9q/bAzPfY6xeCYWEnsM6mZfQZwQbtHujUqQqRYEIT+BU8cy1nq7tIUAA2WVr4ED0w3wwsoKF/0VDgIonoaQ90VkY/JEtgR70aReRgK9du9w83c2YTIBboJOhl8MFSj9sxc2TN4xdQoi0bd/x1I107OT8S3/91amuJhivGlhTSPEWejc5taC87bhp4q2ktLAbV8nTzd7BJDbNmP4Ykh/dwKVqVnUjAprZ85vAq1ttLnS2xMab/ZUDep3RKnsUQP2BY41oFuPsg01+vY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR03MB5315.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(18002099003)(10067099003)(261009223027099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?nD1FSZFloOPgVLB3PnRDDji/s2cV8pc4hx8BVzYSMgwE0T1eLFIN3nQifdvY?= =?us-ascii?Q?blRa444zgDZyUHLZCigsGvy621naiT4sXDUAVl9dku42qFqqItWrxLKTHl0A?= =?us-ascii?Q?yzMm8bDiiGyMPzF1zJe6VaDRx4EZDiTNmUbo/9xaSQiGMpm9/0bgFkL/d8n1?= =?us-ascii?Q?IW2p3WOatoz7skSXoFmOXVcznEJ6LGfhl84AU5ezqeLogXoiyjXJYNP93YT9?= =?us-ascii?Q?HpQhVaxSmkvALtrdmlnuJqVwH/RAITXVtUkfkyuZ2e8C4VIUq+mBqrubUmrb?= =?us-ascii?Q?GA0YK1UYfbOkKLM4ZUqg4Z2+YXXgcVApdplB92OdHktPDqcVv6cUzJAkQfu1?= =?us-ascii?Q?SmR/atvBmJtMZ/HqwXMDcMr7y1dVRNrJyYguZTjc/kWV+TId/9aUEF0aLOG1?= =?us-ascii?Q?JuQePhWIMxbDHQE7WXI6UuEICEhfWBgK4J9ECCdVivZbVoGh+mHhLbXYofCz?= =?us-ascii?Q?rEparVC5ne+ebMC9Lgj6h2mdh+2iHQ1i4jwKY3w430TUyzXLgWLiaVZqEKsv?= =?us-ascii?Q?lKgtg0FPM80Qo4ITnWmviv74qcNHrufuVsaqSpJsdpLrYEPHik27TlVEOwHF?= =?us-ascii?Q?GT8xvZ3vDmg36xP4s6V960EQ8OaQZDtGkFsywAauV1IAqpq1p/d1Wlls/b01?= =?us-ascii?Q?Hx5D2BzvtzDFC/7TK9kAJH0KNd2bqhOmX417Fc6cNlWaIpXEUjxJrSCduwIN?= =?us-ascii?Q?2XakJftzwLoNenHDWNTIf/gGnGXUbK2EVfuDoiYz12COHi25fjrn03Uom6ng?= =?us-ascii?Q?ss0FVNyHreA78RP9JKxK5AQTz3t4ufnUK5ugRPV1BFBsgMLyGp+SxUF/GRLh?= =?us-ascii?Q?Ur5vbWXjBcyTGnlPg1Qzc7NlRqbX3PilBgqMQ3CGsNj0Cq2CNYwhbQFElJg8?= =?us-ascii?Q?04UBnViBf1UdeGI35trHtVE0gzRSprUNZpiTKKzTko5P2pEFMe4K1+tPhpsh?= =?us-ascii?Q?64LMbPGJzTeFYqNLDi68pdqgk6Yl1+ELvKQI+bTVrBYE0AD0bCgtDwCtKCBt?= =?us-ascii?Q?KkeCJO3+ZI6dznNrh1bcjAX9irKNkZUYSKWfJdiLq0lrTfyeqaLwax+5eNYR?= =?us-ascii?Q?L084vZjLZ6y9s8hoJG2J4HA9uVEkaUk7RwCJ5fm1prEizahimVp2lRYxwgVJ?= =?us-ascii?Q?C93wIgMxL4Je7ZHGQP3GmkfZiz6mTZA7bNwsCSpW6yt1XjGaBmQEL4DnPvBV?= =?us-ascii?Q?dAbl2W5FThUekb3n2MEEkFFdUCNzFHBaxeXfPkQIhF559/t2deRJJtKp5hU7?= =?us-ascii?Q?bPA09Wzy3K7Ts397JRGlK1c2bt1Jmv4jRU/5jtM3VdDSYTtFWz/XBUGYjA6g?= =?us-ascii?Q?bzFtQ2CZeSqTUDe3uXnFFE2aD9cDHd35eh37ePSg3UWpDrF9XvyQWqAAm3Vq?= =?us-ascii?Q?UmaE0mcBsgG6snRkSUc6TZkKAYZVsdzAd5mcJ+q2OaCdwbp9P99+ElttsOmo?= =?us-ascii?Q?MdSFKLkoelKXJuNFFpC51biG1vPG0DoyZaJeHuQtCaSrz2bV2A/r2UNW9TEM?= =?us-ascii?Q?6xHkWrscUPtcYU1TfQ61E0CywzJkpgXW67Te3EQUJY82SgNHTFTsPQZNmI0P?= =?us-ascii?Q?njL3FdvEHbSfcnEP1WCbg/jbnu9SWdpT5RRVrljBps68+i1Y3Grr8ZMsIDKM?= =?us-ascii?Q?HmvPE4S2RSEUh3jntvIVYWiRpC9WEryOzPWB/c3fKSdE1LqZdIHjuUYoyq98?= =?us-ascii?Q?7FlyfzJzR8aSgpDF3FqxZ+duIDcEfyPM/cZS+tsGfbpDzuW+9DaG1XSG/Tls?= =?us-ascii?Q?4hYXH/Br7Q=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e6aa66c-6330-4f2d-6b89-08df2b6c68d8 X-MS-Exchange-CrossTenant-AuthSource: MN2PR03MB5328.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 10:01:15.0192 (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: 0dvdjJvTvc/ajR7yi4I530SoWi50OfO9fMOA5Kw+p7D6yQRAIjwlurrMET9dLKahsJFVaE70kPoOcqJs7wF00A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB7237 X-purgate-ID: tlsNG-ef75cf/1792144881-36EDEAE4-2974691B/0/0 X-purgate-type: clean X-purgate-size: 1792 From: Chunjie Zhu L0 always runs L2 with V_INTR_MASKING set, so a physical interrupt exits to L0 regardless of L2's EFLAGS.IF. nsvm_intr_blocked() only blocks when L1 requested V_INTR_MASKING=1 and L1's IF was clear. With V_INTR_MASKING=0 and L2's IF clear, nestedsvm_vcpu_interrupt() would still inject VMEXIT(INTR) into L1. Per the APM (vol.2 rev 3.44 "Physical Interrupt Masking in EFLAGS"), with V_INTR_MASKING=0 L2's IF masks physical interrupts, and a masked interrupt must stay pending. Return NSVM_INTR_MASKED for external interrupts in that case. Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/nestedsvm.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index faacfe007832..a419b47eb5f6 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1514,6 +1514,17 @@ nestedsvm_vcpu_interrupt(struct vcpu *v, const struct hvm_intack intack) case hvm_intsrc_pic: case hvm_intsrc_lapic: case hvm_intsrc_vector: + /* + * Without V_INTR_MASKING, L2's EFLAGS.IF masks physical interrupts + * (APM vol.2 rev 3.44 "Physical Interrupt Masking in EFLAGS"). L0 + * always runs L2 with V_INTR_MASKING set, so the interrupt would + * otherwise exit to L0 and be forwarded to L1 even with L2's IF + * clear. Leave it pending instead. + */ + if ( !vcpu_nestedsvm(v).ns_hostflags.fields.vintrmask && + !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) ) + return NSVM_INTR_MASKED; + exitcode = VMEXIT_INTR; exitinfo2 = intack.vector; break; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 10:19:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 10:19:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451524.1666570 (Exim 4.92) (envelope-from ) id 1xHf2K-0005iW-UP; Fri, 16 Oct 2026 10:19:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451524.1666570; Fri, 16 Oct 2026 10:19: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 1xHf2K-0005iP-RT; Fri, 16 Oct 2026 10:19:40 +0000 Received: by outflank-mailman (input) for mailman id 1451524; Fri, 16 Oct 2026 10:19:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHf2J-0005hE-90 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:19:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHf2I-00AqOK-Ln for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 12:19:38 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1fa2b-e002-0a2a0a5209dd-0a2a4503ac08-34 for ; Fri, 16 Oct 2026 12:19:38 +0200 Received: from [52.101.85.54] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad1fa38-fae8-0a2a45030019-34655536c0eb-3 for ; Fri, 16 Oct 2026 12:19:38 +0200 Received: from BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) by BL1PR03MB6168.namprd03.prod.outlook.com (2603:10b6:208:319::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.17; Fri, 16 Oct 2026 10:19:34 +0000 Received: from BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550]) by BY5PR03MB5315.namprd03.prod.outlook.com ([fe80::f586:75e3:eb6a:9550%2]) with mapi id 15.21.0522.013; Fri, 16 Oct 2026 10:19: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=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=UEyQyScsI4M6146McLNi1dQI6uucGDEsQekBniIXa4wEg+50FzWRLWD/sCfPc8a52ClcNeg8zqFJCEX5/eUC/FTzkeMTwGGyLzTm3gQ16TCxY2VmVyipmGL+6hlaKKWNp2W7Usb/LTA+os1bcQB40rKMVzzYB5EXo/GqYih3nVMdmE2krftxTMc/Mjr6OP4DrBBt2qSWG5pywjaT+dq269rjgyoTvxrPxiBMhrusrGRLLNrjFzb1jgVBzB2ahpe7z5Tbfsy/XTgSTUQi+sqBO88bX8SfFjdxWgw7RRlswORJDUuykgPVrSgqFUIROGkH6y6iNPAiZnHkVTzxIbASkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SCzzjoKJ11AfYPriq5SQxXuZ6IMbihJjcTq84GOQccw=; b=rzFZGJgsjlgJQuFDtwoSN4376QRfihTzRR+731dfQtsUF7Y53sECDuDwgmqfsqXjIMmBpCcyq+6Q5kCEqWxQ8xKHxd9gQv2Xz3yfui0sUMuIiq9CChQb8IXRUfbuCElEjdfqpCnqdSGD/yHEX6OIqQj4Cmxlhx4x8EfrU9u5T8KkON9lFq/TIzzt1SbdGQGy88MAouGK+HF6kVqqZTu7yLu0/0VI39qygemGe78cywAqfxpEcqnkNbyxeaWGnPPRSLGWFx3zWtDF9kmnBDtUUBwj8p+zAkqECkoPacWdGWHF/zmeswTOhrzKcQ++Hx1fR1M9DNOHzSbPV1HUX/NFeQ== 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=SCzzjoKJ11AfYPriq5SQxXuZ6IMbihJjcTq84GOQccw=; b=j0JrCmwr7FAA0D49ULviKQ2iZ1SyVEvN8SpeT3oAbrcTtaor9bbRe+sUJybLZkRo8w/vWdkJRTIin+XO4W78WKGHjQN/4JqZgLzXoqAPPabTqofySakh1MMSor2NWROsbMilFM44Swq97hs757/8QcZpattUHRFETG1DaCAS4ZU= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: jbeulich@suse.com Cc: andrew.cooper3@citrix.com, chunjie.zhu@citrix.com, jason.andryuk@amd.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT Date: Fri, 16 Oct 2026 18:19:26 +0800 Message-Id: <20261016101926.269405-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR01CA0034.apcprd01.prod.exchangelabs.com (2603:1096:4:192::9) To BY5PR03MB5315.namprd03.prod.outlook.com (2603:10b6:a03:229::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR03MB5315:EE_|BL1PR03MB6168:EE_ X-MS-Office365-Filtering-Correlation-Id: 883ac888-5379-48a2-6ff5-08df2b6ef986 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10067099003|22082099003|18002099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: yP+bWn0JcbgNwDY+HeY5lIiFTDfpTcZxVvV5TrgtTSJqC6yajtuM8X3xg0Jv+hOrt8SEfZEn+a7zZGKFM7A/qHTPOWOK6j2LWZkdMPoa6dTOiUbhKYRr4pXsdcziOFWCmeS92qrk9ZqUdpOcqySwgV2RVzgbazbpu0CJXSi0MWsQPrgpBQXgc2DrNshsLUiiV0bOBX1I/i2JVPx2UCfVuCQxyiFjqLhCVUi7ag/Y7bA9nie+vqZ92WD1q48V72ctKYuAuiqtXfM425GW4lgDmQvW0PUcMqoJBdw5k4eOjlFFgB4EJRIXX1R4wk7L8hwBwD/QHyJ+nocqyUfTvVo7SHygv7KIWkzmmKin4shidJmDv2akfLnhPQGc5KCHJoJD7P1W5YrCrKkP61i0fefqA0wg7L6CY10ovrRq3EAPpC79UqVtWda1ey4wrzEycW4Pe8NlQvN9B9qkikyCFX0hE6iYkgfawCPcOC/xrfsKFDo7fD2NWcqjCZ2AsY6WCelb7jpxv5fO+iY9Y4LHKAPMoR973cTQCTkJTUEIfsD82UfM3S+4kTkIcC93drYtMI7Hqg66//9W8oBTwu0h0ZJu81+gflaqviYvMd9d8yEx6JV6HILiaAWGori5BbzR++5iR52XwNd8BowYawa7rd5mOOasekKcRoOALyyXooUScdA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR03MB5315.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10067099003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AKuB6jlwM/LmpmIJxh0k1ZOKKZMkpBzfCpkTCA2A4g1oKQC4tZBhGDoKqMYT?= =?us-ascii?Q?+JPnpkBy2JREiXwQ2gJBAp8pf3aPyPHfAyoaH33XkE1q4+iADW8susP1sr4A?= =?us-ascii?Q?EJaJRT4ZXXWH4Fz0HKNP1sMyyyjEVkz87aoy7TzCEYlnDxJ7xOtuITjjxPv1?= =?us-ascii?Q?Xv8HC5rAvReHa67CDjhuFjPrD0229S02ereHXRob5sTdmr85/RwQKY/RVYqc?= =?us-ascii?Q?be3Od6xyYDi+MsSWJrbhhQw9JyAzoqkPA4gM3SBevcwhSAtxrtpu2r3Oj+j5?= =?us-ascii?Q?6yakzU/sSGuP7/5p4U5Pj/35Zjz7chxwhtsVO2caHi2rjZO4j3HUhlWtcmG1?= =?us-ascii?Q?g6NHECFrfUAfQvj0qDqyPwaLAwImwXJJwhu81SLmZs0F8/n2Ch+elSJh5HVY?= =?us-ascii?Q?O1qnkK9KJ9dn89d0idCmn/LtHTNFBSX904Z38abPMlphalRb6zaAICzeFaRM?= =?us-ascii?Q?pOcxoXyEW5maHt7hUr924S7pi0lACTifU/gvHT7OvhLKhM0O5vXOf6cdTSey?= =?us-ascii?Q?jNOQ9GK1IYyqBvk30vuVwpoyMChSrH03rzz1iERY3ePXgi+Hk14Ffw1T7A5P?= =?us-ascii?Q?ChytXRG9dNbICVKWUKF+e6peZQUJ2bJdO5Nj+U0H6gnGgKFSga8sfCJw86H8?= =?us-ascii?Q?QU+qKS349r58IBOPZNmrGiMBhQ9/sCX3FDUtFGdpobQuMg0iciQsnOjU9tQQ?= =?us-ascii?Q?7+MmPfnX9ruO2j0roiGyfex3Kn5aJRc8QqmVqAxAOIGt9LWWfaQLyzAPLivS?= =?us-ascii?Q?p1x4ofCRFdYyimbk1LMC9U0+Y/gMqfuQntOL0NK3SF/IRfMOaS+abm0qXAon?= =?us-ascii?Q?oq0KkgwkIklBYfk1iC7eIfqiAF/xtW9JQZGXEBb6G+S9EOX4RTADjDgiHMhA?= =?us-ascii?Q?Ne+3kFbV0TAg2hV4WP5O/oueXf64IL3ByS+0HiDeGwcisg7cNX3weqCwMkkF?= =?us-ascii?Q?FDIoT5SwdE1cwBZsgFkcmBRp0IftyxtZS7yCFhNA1vL+OuGbrr7yLeVW9z2v?= =?us-ascii?Q?r+i+ZB5R1lT194/QR0+2qzTpPlHMvWb0hIv6jBycVtC11EQOc22cgEUPvg2J?= =?us-ascii?Q?q0U77ETvEpgzZdfCeJDa9jpD1MQgDRtMZ8M74//kpVA1N2JRLtDOJkqTlTi+?= =?us-ascii?Q?nPiJQh3V739+4ShzYT3XCO25FOhrBjz+YZcCzHB0FFNZKL3/L+2genT3RF3f?= =?us-ascii?Q?Ho3NdrZrdOFDo5IX/jIorJVS2LqmDHQU8L8kAyZezzVharCxNZj7RsS+RhX5?= =?us-ascii?Q?3TRcIzrmAFVAfbiDYSf3zbpd+kfMukSrLMUYa9JVkl6Q1buLfUUKZoamkPAR?= =?us-ascii?Q?85hNdOQw3O4Qms82OTtHXiPe1cREQW/SSFxlqTo6LgxE98xIT7FAnj/qiiM9?= =?us-ascii?Q?xYLrEz7QL4pMoTa9ATYPaYYu0dJgXyhDWucwBsGEXp+j3aiGDI+QhN1A+Dtx?= =?us-ascii?Q?pCdUfSJRZO38SNnDyh1rDLjhChwTgjhLvcx0CksfQnqyP7fg14QBUMIrurYA?= =?us-ascii?Q?LKajlo2rnHOMrvWetHAkox1bjp5p3X7R25JKQEKRRm8sJZvq39FTt7+L2Lwd?= =?us-ascii?Q?wNHhLCZBRUe7BcPXeyh/At37mtFnvD8+6MxJO73O82EmFgum0Q+6ZDE2fahj?= =?us-ascii?Q?VbqIoopaz/vItEi1UkmcmZpQl49W6piDJaSBsfoFLMa4tY9LtQYp1pZrZbf1?= =?us-ascii?Q?W0opPLVgTmTk2lY+xLJFq6RS1n9ak1Ntxtd+aijKlWThLTq6ek1nXHPdd2cm?= =?us-ascii?Q?u7kqkdOGfA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 883ac888-5379-48a2-6ff5-08df2b6ef986 X-MS-Exchange-CrossTenant-AuthSource: BY5PR03MB5315.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 10:19:34.4960 (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: FzTRmwvHpysFY7hCBPYT55c+S89X3ksIka0JZhTWUbLuU3ndCMR/BnHnAPKiwtqXDblx9JFAc5zA3K1S7Ub+eg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6168 X-purgate-ID: tlsNG-33051d/1792145978-6F0C94E9-32E603A8/10/78276251493 X-purgate-type: spam X-purgate-size: 340 On 16.10.2026 09:59, Jan Beulich wrote: > Is there a reason my A-b was lost? > > Jan Oh, sorry, that was an oversight on my part. v2 addressed your comment about the section title, so your Acked-by still applies. Andrew, could you please add it when committing? Acked-by: Jan Beulich Thanks, Chunjie From xen-devel-bounces@lists.xenproject.org Fri Oct 16 10:23:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 10:23:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451532.1666580 (Exim 4.92) (envelope-from ) id 1xHf5t-0007L8-CZ; Fri, 16 Oct 2026 10:23:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451532.1666580; Fri, 16 Oct 2026 10:23: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 1xHf5t-0007L1-9k; Fri, 16 Oct 2026 10:23:21 +0000 Received: by outflank-mailman (input) for mailman id 1451532; Fri, 16 Oct 2026 10:23:19 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHf5r-0007Ks-2G for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 10:23:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHf5q-005d1v-F0 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 12:23:18 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad1fb11-2eae-0a2a0a5409dd-0a2a45019418-30 for ; Fri, 16 Oct 2026 12:23:18 +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 6ad1fb15-5984-0a2a45010019-b9ff1c239b41-3 for ; Fri, 16 Oct 2026 12:23: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1443cb7e90008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 10:23:12 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 6691782B33; Fri, 16 Oct 2026 12:23: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=EIwNFn27oeeB1Vrvy7FJ5dLaZJdL2NDuWkIdyglqKvU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=Ig44eVE9pZ+58qo9oYBXPKR18c835lfxgDYEx6+aMFBxPMEqELLnnQNuHoEd7LkkGEryNsimL ssuC/tqVnvCJ8yJPVxexZ3EygTmRN99nE4gTA3ZpYgho72HsnKOp/kRF12axmk2e10naJE/FJDa jNaA+iaFLEn1VPFhH21LTcZWP7qjQ01EEDeri1gql0C6zePtWtd54Dpa0Ldh7ROrJDKsczboy+p CwyDiN/PzSzmP8KcqjjZqiswtF0Ahdob7YWPxo73R8YDSPKefyfphj5GXQ3pHh3Edu1/V5C8AYe L0Ejvw3L1ijMUFHw/gCKQRjQ+MJUHL01ylOLqw25opKA== X-Zone-Loop: 477319da4ae58a73404ceb02744c273941bdba5e373b x-campaign-type: default x-transaction-id: b28f0cdd-68a8-467c-9f25-95f76abd61f8 x-swg-uid: 01-adb76025-8703-475e-908d-c500b6386f73 X-Mailer: Sweego Message-ID: <1792146192.8631fc262581453bbf619ec5b2062170.1a1443cb7e90008425@vates.tech> x-swg-bid: 1792146192.8631fc262581453bbf619ec5b2062170.1a1443cb7e90008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , George Dunlap , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] xen: Use VCPUOP_register_{runstate,vcpu_time}_phys_area when available Date: Fri, 16 Oct 2026 12:22:00 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2b5.eea8caf3adaf82ca.1a1443cb515.d621e0f4827f716e=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792146191643 X-purgate-ID: tlsNG-d62444/1792146198-C4B45757-AEE1FEF6/0/0 X-purgate-type: clean X-purgate-size: 8222 ---=Part.2b5.eea8caf3adaf82ca.1a1443cb515.d621e0f4827f716e=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Updating these area can be expensive when done through virtual addresses (especially for runstate one), in particular for HVM/PVH guests=2E Xen 4=2E18 introduced physical address alternatives to address those short-commings, but they aren't used currently=2E Fix it by using these alternatives when available (when reported in XENFEAT_{runstate,vcpu_time}_phys_area, but keep the current logic in the PV case=2E Assisted-by: LLM [guidance and testing] Signed-off-by: Teddy Astie --- When using phys_area ABI, the struct is not allowed to cross a page boundary anymore, hence we need to be careful with per-cpu struct alignment=2E I've deliberately put the PV domain (!XENFEAT_auto_translated_physmap) case aside as it profits less from the physical address ABI, and it would make things more complicated as "physical address" doesn't have a obvious meaning there=2E CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: David Woodhouse CC: George Dunlap CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg arch/x86/xen/time=2Ec | 35 ++++++++++++++++++-------------- drivers/xen/time=2Ec | 24 +++++++++++++++++----- include/xen/interface/features=2Eh | 9 ++++++++ include/xen/interface/vcpu=2Eh | 17 ++++++++++++++++ 4 files changed, 65 insertions(+), 20 deletions(-) diff --git a/arch/x86/xen/time=2Ec b/arch/x86/xen/time=2Ec index 5c7822254a01=2E=2E19ace1b78ae4 100644 --- a/arch/x86/xen/time=2Ec +++ b/arch/x86/xen/time=2Ec @@ -37,6 +37,22 @@ =20 static u64 xen_sched_clock_offset __read_mostly; =20 +static int xen_register_time_area(struct pvclock_vcpu_time_info *pvti) +{ + struct vcpu_register_time_memory_area t; + bool phys =3D xen_feature(XENFEAT_vcpu_time_phys_area) && + xen_feature(XENFEAT_auto_translated_physmap); + int op =3D phys ? VCPUOP_register_vcpu_time_phys_area + : VCPUOP_register_vcpu_time_memory_area; + + if (phys) + t=2Eaddr=2Ep =3D pvti ? virt_to_phys(pvti) : ~0LLU; + else + t=2Eaddr=2Ev =3D pvti; + + return HYPERVISOR_vcpu_op(op, 0, &t); +} + /* Get the TSC speed from Xen */ static unsigned long xen_tsc_khz(void) { @@ -395,7 +411,6 @@ static u64 xen_clock_value_saved; =20 void xen_save_time_memory_area(void) { - struct vcpu_register_time_memory_area t; int ret; =20 xen_clock_value_saved =3D xen_clocksource_read() - xen_sched_clock_offse= t; @@ -403,9 +418,7 @@ void xen_save_time_memory_area(void) if (!xen_clock) return; =20 - t=2Eaddr=2Ev =3D NULL; - - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; + ret =3D xen_register_time_area(NULL); if (ret !=3D 0) pr_notice("Cannot save secondary vcpu_time_info (err %d)", ret); @@ -415,15 +428,12 @@ void xen_save_time_memory_area(void) =20 void xen_restore_time_memory_area(void) { - struct vcpu_register_time_memory_area t; int ret; =20 if (!xen_clock) goto out; =20 - t=2Eaddr=2Ev =3D &xen_clock->pvti; - - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; + ret =3D xen_register_time_area(&xen_clock->pvti); =20 /* * We don't disable VDSO_CLOCKMODE_PVCLOCK entirely if it fails to @@ -446,7 +456,6 @@ void xen_restore_time_memory_area(void) =20 static void xen_setup_vsyscall_time_info(void) { - struct vcpu_register_time_memory_area t; struct pvclock_vsyscall_time_info *ti; int ret; =20 @@ -454,9 +463,7 @@ static void xen_setup_vsyscall_time_info(void) if (!ti) return; =20 - t=2Eaddr=2Ev =3D &ti->pvti; - - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; + ret =3D xen_register_time_area(&ti->pvti); if (ret) { pr_notice("xen: VDSO_CLOCKMODE_PVCLOCK not supported (err %d)\n", ret); free_page((unsigned long)ti); @@ -469,9 +476,7 @@ static void xen_setup_vsyscall_time_info(void) * still check it in case hypervisor is buggy=2E */ if (!(ti->pvti=2Eflags & PVCLOCK_TSC_STABLE_BIT)) { - t=2Eaddr=2Ev =3D NULL; - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, - 0, &t); + ret =3D xen_register_time_area(NULL); if (!ret) free_page((unsigned long)ti); =20 diff --git a/drivers/xen/time=2Ec b/drivers/xen/time=2Ec index a2be0a4d45b0=2E=2E6b6ddc7a5822 100644 --- a/drivers/xen/time=2Ec +++ b/drivers/xen/time=2Ec @@ -19,8 +19,12 @@ #include #include =20 -/* runstate info updated by Xen */ -static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate); +/* + * Runstate info updated by Xen=2E The phys-area ABI doesn't allow it to = cross + * a page boundary; the struct is 48 bytes, so 64 is the smallest alignme= nt + * that guarantees this=2E + */ +static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate) __aligned(= 64); =20 static DEFINE_PER_CPU(u64[4], old_runstate_time); =20 @@ -152,11 +156,21 @@ u64 xen_steal_clock(int cpu) void xen_setup_runstate_info(int cpu) { struct vcpu_register_runstate_memory_area area; + unsigned int op; =20 - area=2Eaddr=2Ev =3D &per_cpu(xen_runstate, cpu); + if (xen_feature(XENFEAT_runstate_phys_area) && + xen_feature(XENFEAT_auto_translated_physmap)) + { + op =3D VCPUOP_register_runstate_phys_area; + area=2Eaddr=2Ep =3D per_cpu_ptr_to_phys(&per_cpu(xen_runstate, cpu)); + } + else + { + op =3D VCPUOP_register_runstate_memory_area; + area=2Eaddr=2Ev =3D &per_cpu(xen_runstate, cpu); + } =20 - if (HYPERVISOR_vcpu_op(VCPUOP_register_runstate_memory_area, - xen_vcpu_nr(cpu), &area)) + if (HYPERVISOR_vcpu_op(op, xen_vcpu_nr(cpu), &area)) BUG(); } =20 diff --git a/include/xen/interface/features=2Eh b/include/xen/interface/fe= atures=2Eh index 53f760378e39=2E=2Ef00144a7c790 100644 --- a/include/xen/interface/features=2Eh +++ b/include/xen/interface/features=2Eh @@ -97,6 +97,15 @@ #define XENFEAT_not_direct_mapped 16 #define XENFEAT_direct_mapped 17 =20 +/* + * Signal whether the domain is able to use the following hypercalls: + * + * VCPUOP_register_runstate_phys_area + * VCPUOP_register_vcpu_time_phys_area + */ +#define XENFEAT_runstate_phys_area 18 +#define XENFEAT_vcpu_time_phys_area 19 + #define XENFEAT_NR_SUBMAPS 1 =20 #endif /* __XEN_PUBLIC_FEATURES_H__ */ diff --git a/include/xen/interface/vcpu=2Eh b/include/xen/interface/vcpu= =2Eh index c7cc28ad8d63=2E=2Ed3858233c32f 100644 --- a/include/xen/interface/vcpu=2Eh +++ b/include/xen/interface/vcpu=2Eh @@ -203,4 +203,21 @@ struct vcpu_register_time_memory_area { }; DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_time_memory_area); =20 +/* + * Like the respective VCPUOP_register_*_memory_area, just using the "add= r=2Ep" + * field of the supplied struct as a guest physical address (i=2Ee=2E in = GFN space)=2E + * The respective area may not cross a page boundary=2E Pass ~0 to unreg= ister an + * area=2E Note that as long as an area is registered by physical addres= s, the + * linear address based area will not be serviced (updated) by the hyperv= isor=2E + * + * Note that the area registered via VCPUOP_register_runstate_phys_area w= ill + * be updated in the same manner as the one registered via virtual addres= s PLUS + * VMASST_TYPE_runstate_update_flag engaged by the domain=2E + * + * XENFEAT_{runstate,vcpu_time}_phys_area feature bits signal the availab= ility + * of these ops=2E + */ +#define VCPUOP_register_runstate_phys_area 14 +#define VCPUOP_register_vcpu_time_phys_area 15 + #endif /* __XEN_PUBLIC_VCPU_H__ */ --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2b5.eea8caf3adaf82ca.1a1443cb515.d621e0f4827f716e=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 11:16:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 11:16:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451673.1666588 (Exim 4.92) (envelope-from ) id 1xHfur-0006KV-8C; Fri, 16 Oct 2026 11:16:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451673.1666588; Fri, 16 Oct 2026 11: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 1xHfur-0006KO-5T; Fri, 16 Oct 2026 11:16:01 +0000 Received: by outflank-mailman (input) for mailman id 1451673; Fri, 16 Oct 2026 11:16:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHfup-0006KI-TP for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:16:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHfup-008Ehb-57 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:15:59 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2075d-bab6-0a2a0a5309dd-0a2a4503d292-44 for ; Fri, 16 Oct 2026 13:15:59 +0200 Received: from [40.93.196.32] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2076d-fae8-0a2a45030019-285dc420c098-3 for ; Fri, 16 Oct 2026 13:15:58 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5310.namprd03.prod.outlook.com (2603:10b6:208:1f1::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 11:15: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.0522.013; Fri, 16 Oct 2026 11:15: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=FocVU8dnxO4ezIfk4nxix62xVgzWhrfHY3Bk1SnueONH5Wp2G8n3liySSOwNd8vc32fnPHnsFvRN7a7Ef0RKgy0A9wMkZ00T9w6/GJdjqvV4ComZKp05UEfHKxJwtskspxO8UbUUuM72Zg9v5/6aswWUxPDyjNeRokQj35nv1E449ja8QVmy9rChjeNg+/21ZVmiiibyRhkS7nzNCAlostdpurCtoeixf1Yc4T8P0o44iQbChUacH3TJZE2nQuc3/U4pr1YjERpqoTeT8YLWZprq6lLzVL7Myrj5jmBoIdECKIQBjE32KrG9/L5dXtIGlwT1rMc22Z/Eb698rCqDPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IEQRgVwsP3P3JCBhOFhOC5oNvH97q3sXzg8GqkPu+sM=; b=L+nN3oJkYxzc5UP0xjvUgSIALYNinxyweqav8B3GCKKq5M09mfRssYgD/0iSLSezM7+K2EWuCQ5lJ37UsI7CwRXWPC3cdLu4tYr39zEvBDWmbPiac560rhcOHKe60JHi26nmJlnb01/jFMKTgaHOkzhykkPiGQaAv+RSYggsCKYEoXfKRt4rwP4RP6U1ZUGEkrjnqOFR5ejy4bfRmw2V1f6LgG2aTuDeAaddSSTgz0HeSUSjtCP/mpFLuinDZmjz3OklYpL9MAjp9J0zmxsqToSDLbiUdr5sRqKqilHjxiT3cZ+01aItz8Ac7sPiQu/gu5J4GTgaTTJO9juzJ+Q36g== 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=IEQRgVwsP3P3JCBhOFhOC5oNvH97q3sXzg8GqkPu+sM=; b=BuDyusoxSpxShCeG5NBWft+Ql1eZzg/f/ByMJOTizvJyprzx++mmEnLH+NC8YpIiJE7fR+ghrNiKI/ym7Q1+oQ/qbVXOKmsTcC1Nv9aK77+s+OJigezmptuXUskLMHU/aK5WypVnWAubhTsTJPB9MkPecdeW3niVgE6B/2zY0LY= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <9a8b0ae0-ec49-4af0-8e5d-1378319f2857@citrix.com> Date: Fri, 16 Oct 2026 12:15:51 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , George Dunlap , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xen: Use VCPUOP_register_{runstate,vcpu_time}_phys_area when available To: Teddy Astie , xen-devel@lists.xenproject.org References: <1792146192.8631fc262581453bbf619ec5b2062170.1a1443cb7e90008425@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: <1792146192.8631fc262581453bbf619ec5b2062170.1a1443cb7e90008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0159.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c7::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_|MN2PR03MB5310:EE_ X-MS-Office365-Filtering-Correlation-Id: e08e31ee-c612-4b4e-892a-08df2b76d860 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|7416014|6133799003|10067099003|18002099003|22082099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: GqqXAPkdwHDQCUX9TO+LTjrw2tddzD77NuAvmzbr26ZRvB79PyeEZT9KxD+g4DzwdGlkPTF8QpDZTXSanjF8b9nksJkRHsVa/yWvdsvzEOJUwZt7yrwdmK/3LNrPRWG6ckvRGoeJ2hCmAT4LELdMF0LMHzq225BoijOr9TpIY4aPMbcMeL6FP0NTA3ojE50j7+l4rT+BChFM85OJoCKuYFeQuoWZa9ebdcH1pdkFoRSSxM/u0xxNL+rXj+NMdi+oUwrbOfpcg7KIrfOkqnJfMaCqbhJNmodYcv4Sb53LHhQ+HjGSSDpS1EVLFb+wEMA4Rs91Kfk2nQsmWzDjEt2nNpuy7T11TI6A8NXx88TDn96HAuRpiqJdM43O8cG1fLYFkq6G5wDBI1KCAB1+3le9Ls4dpRW8UlejIIHOq9SIpWVFy/sKwKyWz/pz5g1lzR2Na5sGhrftD2H+qQNEPVqvIpaNb8EtkBf2dMiy9IA4kWvpPMgd6tZvPCRlVkF5E/wgqYw/HTdKcQw9VQqXQtykESDpY0Jnghft4yJqcyM6XsMVFpDaa9oicYva9QMT9k4VgMOsSKbj9x/QtZE1JjSavaV9lL2Ez5YPVX8ZNxjt/CQgJp3A8fSs8jePWvUB1Kros/UCS0orY6IJw38XjyU2wynLl4uhWvFh9JC8LjeZJL4= 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)(7416014)(6133799003)(10067099003)(18002099003)(22082099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vjl4V3orNDBOM0o2RWJzaHJrSm03c0R0MDlNbXd4THR3UHpzRlhpSUQ0bG5q?= =?utf-8?B?aysxdkh5eDJhb2hVa2M1Qm55RFl0dm5WSXJoeUVkRVJiMXBuNVNYTHd2c285?= =?utf-8?B?NmVob3dVcUprSVBhOVlEYmF2bElJV2h3VHVBdy9LT0VveTBWSTZHbXptdnRt?= =?utf-8?B?VFNJNlE4OWdJdHRjWGI3NVlCYkFhcGlLNnFVTzNVNzc1S0FMa0xTa3pCRTRu?= =?utf-8?B?K0E2YTc0UklOM2NmcDJPZ1dBdmNQbHZSbU9oQW9WeVpOV0VtNUx1dFF5cEI4?= =?utf-8?B?VTByVzh3S0swT285SnhrLy95WWM3aHBoTjFPV0RsdEE0elJjeW9YZDMwWHNG?= =?utf-8?B?L1h0UzZpblBjaTZrMU5kVWdlbEpFcmtubkgwekZlVDJNMUJYeUhVamdGNVFh?= =?utf-8?B?c2lOVDVYdEYxUEhQcjA2U2FaNnhkQ0VEbGVBRjc0T2xsc24wNWVIRkQvT2hJ?= =?utf-8?B?LzMrVldoRyt0MElZOVBzOHRGcVVXVVVFS3p5SWFmY0xaV3pUdVpLTW9YUTJE?= =?utf-8?B?RjdaUlF6blJxNXVWYWdMZWFJTnlBTldNY1Q2cVNVSkl5QUd5VEYwMXlORXB4?= =?utf-8?B?Nms5ZW9WQUtUR1BNdERiM21xL2FWQ3lSUGxxUlkxa1lUWk45Mis1MnBxVUpz?= =?utf-8?B?QUZEZDUwaEkwLy9DdStkOVFRd1lSM0E1NGxVekIvcXdBTVlGdlcvQi9peTZN?= =?utf-8?B?V2F0OGRyWlFtZWZvbGpaN0JPWXNyeDhKUDhpdWVjVkFXcWtTTmg5d1hoRUls?= =?utf-8?B?U1o1eGVnUTIxNUVvQkpBTEVyWktlYXdpbEx4cnRxS0ZGa3A1VVRRRllJbkhl?= =?utf-8?B?ZDFBbytkTGFBY0lYMXBLNnRCd3lteXdQU0NEMURmb3JyNUVVSTNiNHppTnlt?= =?utf-8?B?WWxPM3ZCR21sY0dUM1l2UUZWUmpmWjBwQUJiUFZvYU9PdC9CR2ZhRkM3ZU9E?= =?utf-8?B?MTIzMTNaU0sxdEhZVmdWVGtnYVRVWnFHcVgxbVlCemNvVUw5VkZLT2FXWGZp?= =?utf-8?B?Z3lDRVVOV2FFQ0hBQldJdi9UUXZieVdLeTN6ZG1pVkx5QmEyYVVqSmFiT3M5?= =?utf-8?B?YXdTUnpybEhBV3JOUE5keklCWjVUME85bDI3dy9JY0ExU1gxcjBQcHRlUmJH?= =?utf-8?B?ejA4aDRpV2VLZXM3dzMyb2tqLzB2QUNYUFhwbFBzVGt1TGpqZmh3TkE3ajhw?= =?utf-8?B?dmt3b0dGZHFaaFJRNTRVRWxDK3M5K1NCb2hkYzI3NDNlMGNjNlhBc0k1UWJm?= =?utf-8?B?U3JkZjZHUFRSTGkzRU02V3Y5UnRpZU9IeUh0M2k0YWVlbUZOUGV5WEJOdURl?= =?utf-8?B?T1JjNVJoMHhvZUFCVTltR0dUQVhWd2h0eFgzLzB1YkMyRFlsRU5OMjJUaXVz?= =?utf-8?B?ZXNmQ3JsKytEYVVKRk5JamZwVTRySGR0QWhGU3gxRmgxcG5JcVl3emNHUWEv?= =?utf-8?B?aVFBbGZkWjQ0RmRJWjVWczZTWG5heG8xQUZyWmFrWFNRRUZCQmJLVG81NEJy?= =?utf-8?B?UHpFT2ZmdHI0bkVSWEdWZGhHN0FkejNLQm1OeHY2bFVoTU9rK1p3MTlZbEdD?= =?utf-8?B?MW5oN0ZFbUdaTnBORFZUeWdheWpJZWpSYllJMmxaWE1ZQ3IydnQxNjZ3OTVP?= =?utf-8?B?UUpUdVNMOXdkVlM2WTd6NnloZHlscHdTbElnd1dBZGpVN09MWDVybmZ1TDdQ?= =?utf-8?B?bWNpUDRwc3dLOWorVi9ianJ1eDRQMmRhazE0Z1NSZUdjeml6WlE5empEWVBQ?= =?utf-8?B?anh6YVRQZk1IY1ZRRmx6eXUxZm92dTI5YnVKWnZIc0VYSkVoYVNVbzRDeHRK?= =?utf-8?B?YkM2Smw2MWpMcGJIOEtRaHBRV2RQYzVzczU5NWlCN05tS3N0SjJ3cDhGcVNj?= =?utf-8?B?dWRSeTMyUlhDcWgybnhQem1NdHpLNWYvUURGeTFEVWVGeGNEdnkzNGZOZG8v?= =?utf-8?B?NGhYbnFOOGMrYTRjRFJUWmY0NkVDQW5MWjJEUHNMNktNTmxoV0puK2tCcjFw?= =?utf-8?B?OWlFa3h4dUZvZnZlYS8zb0REb0g5eFlsUDZjamNEOXUyQkwwR3p6T0xHNG1D?= =?utf-8?B?NUt0VmR1YmxNQ3E1aU9va0VVYjZtVFk0QWN1VVFicjhyTUwwN0kwY3Z3YUht?= =?utf-8?B?S21jVmpKcld5RWFHUEI5aEFnZU1kQ0s4QTJYNE9oQ1dXSC92elcvaFp0c0RG?= =?utf-8?B?WFhDR0h2Zk5QRkRwODc2azV5QktJT2FwVHI3bVMzUk90aXFCaElyYnNmazlK?= =?utf-8?B?TDZ2U0VEZzhkMFdYSmZDZnpJeW9oaXgrQVR0aXpjcHJ3QkhTYk51cGZNWW13?= =?utf-8?B?YURaRUc3TnQyYlZoWlZieEJTOGoxeXBpVGRDbWZYVERncDFTTENxZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e08e31ee-c612-4b4e-892a-08df2b76d860 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 11:15:54.8052 (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: En2KOPc4A8TOwtME+EdxzmWUvEGHSK8LyHsvKYs4owTyVU4USizObDwB4CvTWJ0hlHYikPm9aubMgnu/JeKKzm5LIQirs/8jpqx1Gn5fwgg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5310 X-purgate-ID: tlsNG-33051d/1792149359-776F34E9-40B610A8/0/0 X-purgate-type: clean X-purgate-size: 4474 On 16/10/2026 11:22 am, Teddy Astie wrote: > Updating these area can be expensive when done through virtual addresses > (especially for runstate one), in particular for HVM/PVH guests. > Xen 4.18 introduced physical address alternatives to address those > short-commings, but they aren't used currently. > > Fix it by using these alternatives when available (when reported in > XENFEAT_{runstate,vcpu_time}_phys_area, but keep the current logic > in the PV case. > > Assisted-by: LLM > [guidance and testing] > Signed-off-by: Teddy Astie > --- > When using phys_area ABI, the struct is not allowed to cross a page > boundary anymore, hence we need to be careful with per-cpu struct > alignment. > > I've deliberately put the PV domain (!XENFEAT_auto_translated_physmap) > case aside as it profits less from the physical address ABI, and it > would make things more complicated as "physical address" doesn't have > a obvious meaning there. It should always have been a guest physical registration, even for PV guests. The virtual address registered with Xen doesn't exist in the user pagetables, and the way we discover that is taking a pagefault in Xen at the point we need to update things. > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > index 5c7822254a01..19ace1b78ae4 100644 > --- a/arch/x86/xen/time.c > +++ b/arch/x86/xen/time.c > @@ -37,6 +37,22 @@ > > static u64 xen_sched_clock_offset __read_mostly; > > +static int xen_register_time_area(struct pvclock_vcpu_time_info *pvti) This needs a comment explaining what's going on (by GPA, falling back to VA), including that passing NULL means unregister. > +{ > + struct vcpu_register_time_memory_area t; > + bool phys = xen_feature(XENFEAT_vcpu_time_phys_area) && > + xen_feature(XENFEAT_auto_translated_physmap); Not related to your patch, but the xen_feature() infrastructure is idiotic. It takes a bitmap from Xen, and transforms it into a u8 array of 1's or 0's. It wants storing as a proper Linux bitmap, with xen_feature() being a trivial wrapper around test_bit(), at which point the compiler will able to collapse expressions such as the one above into a single operation.  (except, you need to remove the XENFEAT_auto_translated_physmap aspect to include PV guests.) > + int op = phys ? VCPUOP_register_vcpu_time_phys_area > + : VCPUOP_register_vcpu_time_memory_area; > + > + if (phys) > + t.addr.p = pvti ? virt_to_phys(pvti) : ~0LLU; > + else > + t.addr.v = pvti; > + > + return HYPERVISOR_vcpu_op(op, 0, &t); > +} > + > /* Get the TSC speed from Xen */ > static unsigned long xen_tsc_khz(void) > { > @@ -395,7 +411,6 @@ static u64 xen_clock_value_saved; > > void xen_save_time_memory_area(void) > { > - struct vcpu_register_time_memory_area t; > int ret; > > xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset; > @@ -403,9 +418,7 @@ void xen_save_time_memory_area(void) > if (!xen_clock) > return; > > - t.addr.v = NULL; > - > - ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t); > + ret = xen_register_time_area(NULL); > if (ret != 0) > pr_notice("Cannot save secondary vcpu_time_info (err %d)", > ret); How does this work?  Answer is it doesn't, because the print message is bogus.  This is a failure to unregister the time area, not a failure to save the time value. At lest the error message wants fixing, and in a prep patch. > diff --git a/drivers/xen/time.c b/drivers/xen/time.c > index a2be0a4d45b0..6b6ddc7a5822 100644 > --- a/drivers/xen/time.c > +++ b/drivers/xen/time.c > @@ -152,11 +156,21 @@ u64 xen_steal_clock(int cpu) > void xen_setup_runstate_info(int cpu) > { > struct vcpu_register_runstate_memory_area area; > + unsigned int op; > > - area.addr.v = &per_cpu(xen_runstate, cpu); > + if (xen_feature(XENFEAT_runstate_phys_area) && > + xen_feature(XENFEAT_auto_translated_physmap)) Again, PV guests want to use phys when available. > + { > + op = VCPUOP_register_runstate_phys_area; > + area.addr.p = per_cpu_ptr_to_phys(&per_cpu(xen_runstate, cpu)); > + } > + else > + { > + op = VCPUOP_register_runstate_memory_area; > + area.addr.v = &per_cpu(xen_runstate, cpu); I'd suggest factoring out the &per_cpu(xen_runstate, cpu) calculation.  It's not free, and can't be hoisted by the compiler. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 16 11:35:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 11:35:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451685.1666597 (Exim 4.92) (envelope-from ) id 1xHgDc-0001vD-Mq; Fri, 16 Oct 2026 11:35:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451685.1666597; Fri, 16 Oct 2026 11: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 1xHgDc-0001v6-KE; Fri, 16 Oct 2026 11:35:24 +0000 Received: by outflank-mailman (input) for mailman id 1451685; Fri, 16 Oct 2026 11:35:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHgDb-0001v0-LT for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:35:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHgDb-00B3tI-08 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:35:23 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad20bf9-8faa-0a2a0a5109dd-0a2a450396fa-4 for ; Fri, 16 Oct 2026 13:35:22 +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 6ad20bfa-fae8-0a2a45030019-b9ff1c228af7-3 for ; Fri, 16 Oct 2026 13:35: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1447ec1cc0008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 11:35: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 5C3DD810D3; Fri, 16 Oct 2026 13:35: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=rCqdoei7QDft3v50+XHoD9FEzWx+F20GdvbObtj+Jpo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ea/rW1LOVZdJROksOEN+yzruUS85PAThr+P/wiixFZC0JpDvjT6HYbUxmdy6hL9YKeD665dbb Q0EtqvV60/ng2Aw3ul7EyV/u2HXqdSLEfRZEh33cgTt/tdExDooaYXpRnmyoBzwaOAoO0vjG79f IZ9IdCGrpAu0PpH0V7bjEFRo6ONOOagmbuombxCoyRTvJxmTisLb6hRXrubPLlsr50mquOHy1JZ Ukzc8qKENRoSob2vQ+Q3Ge/Dp7+GYWFdOmYHBnni4hmmoWtzErTjCrL1o0KXcKXbmeT3KTXo31F RdcZ2WA5wiWN+DdWXjx09ez/8lyckm19L4L4sNBJir/Q== X-Zone-Loop: 218d19ffa0ad5a36055a5d2944f8fa436181f37fcf54 x-campaign-type: default x-transaction-id: 20c40629-04e1-452c-b92d-8f1bafed6526 x-swg-uid: 01-145c1ab0-900a-45d3-929f-3a2f1f9b75be X-Mailer: Sweego Message-ID: <1792150520.8631fc262581453bbf619ec5b2062170.1a1447ec1cc0008425@vates.tech> x-swg-bid: 1792150520.8631fc262581453bbf619ec5b2062170.1a1447ec1cc0008425 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 v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot From: Baptiste Le Duc To: Jan Beulich Cc: Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Baptiste Le Duc In-Reply-To: <2f04c46d-f533-4eda-9bd1-8b8e100dff07@suse.com> References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> <81ad5bb7-2300-4ac2-a999-adbb39270ddf@gmail.com> <2f04c46d-f533-4eda-9bd1-8b8e100dff07@suse.com> Date: Fri, 16 Oct 2026 13:35:13 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792150514; l=4315; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=G0VZ2xZeVAh0/4el30Bh5qsA70o0dVS8ZVY02/9BGtc=; b=uwreui9yhPE86IHoa7e6dY8NXODS52Asm+PaoGBw5jTxrBTe1Zzf4wj26utBCVkEDj6Sd/JMl ilqJjM45bYuCpDr8knwgD2B6qG397bDcQ298fNe3N0TlO5DscUbThhh 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: 1792150519578 X-purgate-ID: tlsNG-33051d/1792150522-754844E9-343F06F2/0/0 X-purgate-type: clean X-purgate-size: 4315 On 2026-10-15 18:04 +0200, Jan Beulich wrote: > That's what I suggested earlier, yet from replies I concluded it wouldn't > be overly practical to have people edit DTs. > > Jan Hello Jan, Based on Andrew's answer to your question on GitHub [1], I see two options for handling a DT that doesn't advertise the scheme in effect. Please feel free to choose one. 1) Trust the probe and fix up riscv_isa on a mismatch. This avoids having people edit their DTs, and is safe as, per Andrew, the spec has only ever allowed these two schemes: /* * The privileged spec allows exactly two schemes for the PTE A and D bits: * 1) hardware sets them on access and on write. * 2) accessing a page whose A and/or D bit is clear raises a page fault, * so that software can set them (ratified as Svade). * * Hence an implementation without Svade uses the hardware scheme (1), and one * that faults on clear A/D bits implements Svade, whether or not it says so. * * Rather than trusting the DTS alone, probe the scheme in effect with a write * through a PTE whose A and D bits are clear. If the DTS does not advertise * it, replace it by the probed scheme. As the spec has only ever allowed * these two schemes, this is safe even on implementations that predate Svade * and Svadu. */ static void __init check_ad_scheme(void) { bool has_hw_scheme = probe_hw_ad_update(); const char *scheme_name = has_hw_scheme ? "Svadu" : "Svade"; enum riscv_isa_ext_id ext = has_hw_scheme ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade; /* Fix DTS in case of mismatch */ if ( !riscv_isa_extension_available(NULL, ext) ) { printk(XENLOG_WARNING "CPU implements %s but the DTS does not advertise it\n", scheme_name); __clear_bit(RISCV_ISA_EXT_svade, riscv_isa); __clear_bit(RISCV_ISA_EXT_svadu, riscv_isa); __set_bit(ext, riscv_isa); } printk(XENLOG_DEBUG "CPU is using %s A/D bits scheme\n", scheme_name); } 2) Panic on a mismatch, requiring the DT to be fixed. Same function, with the last paragraph of the comment and the check becoming: * Rather than trusting the DTS alone, probe the scheme in effect with a write * through a PTE whose A and D bits are clear, check it against what the DTS * advertises, as described by the DT binding, and panic on a mismatch. */ [...] /* The probed scheme must match the DTS. */ if ( !riscv_isa_extension_available(NULL, ext) ) panic("CPU implements %s but the DTS does not advertise it\n", scheme_name); Either way, Svade ends up set whenever the CPU faults on clear A/D bits, so p2m_set_pte_flags() only has to check Svade: /* * A RISC-V implementation can either: * 1) Update the 'A' and 'D' PTE bits in hardware. * 2) Generate a page fault when 'A' and/or 'D' is clear, so that * software can set them. * * (1) needs nothing more as it is handled by hardware. For (2), set 'A' * and 'D' up front: OpenSBI delegates such page faults to a lower * privilege mode, so they would be raised in Xen, which has no handler * for them. * * check_ad_scheme() ensures Svade is set whenever the CPU faults on * clear A/D bits. If both Svade and Svadu are advertised but the CPU * updates A/D in hardware, presetting them is harmless. * * TODO: Xen on RISC-V currently makes no use of the information that * handling such page faults could provide, which would be useful * for several use cases such as demand paging, cache-flushing * optimizations, memory access tracking, etc. * * 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 the page faults that occur due to * unset A/D bits. */ if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) e->pte |= PTE_ACCESSED | PTE_DIRTY; Thanks, Baptiste [1] https://github.com/riscv/riscv-isa-manual/issues/3450#issuecomment-6201235555 -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 16 11:53:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 11:53:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451706.1666610 (Exim 4.92) (envelope-from ) id 1xHgUZ-0004yD-39; Fri, 16 Oct 2026 11:52:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451706.1666610; Fri, 16 Oct 2026 11:52: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 1xHgUY-0004y5-WC; Fri, 16 Oct 2026 11:52:55 +0000 Received: by outflank-mailman (input) for mailman id 1451706; Fri, 16 Oct 2026 11:52:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHgUX-0004xz-Nk for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:52:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHgUX-000iAT-4O for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:52:53 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad21000-2eae-0a2a0a5409dd-0a2a4509ed34-30 for ; Fri, 16 Oct 2026 13:52:53 +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 6ad21014-be1a-0a2a45090019-b9ff1c23ac27-3 for ; Fri, 16 Oct 2026 13:52: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 1a1448ec98c0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 11:52:50 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id D2EC8810D3; Fri, 16 Oct 2026 13:52: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=e8D1AHKavCaEe2BlfpU7cYPvO/7Y0CW66h6R3HuzI+I=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=SJgBTCpKGjTRLSR3Xo9GyueZZSb/jvfK0xXeCqpHF+mwsa6uS4ExUZSebbXaDhlpIuhirSbZZ oQrjJ26c9WU/x4K4DP9vomG1kbBT7IIRsXM3ZuBRSWw7/qDi6YddfacpqNtQSzWTyIyomB67sZL 5UgorkfFHx4irEtdhRwoK+KMR0P1TR4ApzSSYVknGuaPOvabcFjoIkddRPX0a7Wi7EJfJxglUhT prEvEiTUH6iau4xPh7hDpWPXZwFacu9ermT4xD7ONqmOOgqYfbkT7vMcC6QnAPMo0Nd8/AdsEpf AdJkQrJl0LSnQJWmeTroimWswkYdOZJKYAEgMVQs5rWw== X-Zone-Loop: b3ae850f38b6d68f54ae2021e0d043f71164c428a0aa x-campaign-type: default x-transaction-id: 1fbfebc3-ae9d-4617-9651-eff6affa23bc x-swg-uid: 01-3c92c1c9-e92a-406a-8359-1620e0396462 X-Mailer: Sweego Message-ID: <1792151570.8631fc262581453bbf619ec5b2062170.1a1448ec98c0008425@vates.tech> x-swg-bid: 1792151570.8631fc262581453bbf619ec5b2062170.1a1448ec98c0008425 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Julian Vetter Subject: [PATCH] tools/ocaml: implement stub_xc_domain_create() for ARM Date: Fri, 16 Oct 2026 13:52:43 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2bc.f42a9330550d9681.1a1448ec711.e4fc43891962f8b4=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792151570194 X-purgate-ID: tlsNG-bad1c0/1792151573-3B0DD034-33B7C852/0/0 X-purgate-type: clean X-purgate-size: 2764 ---=Part.2bc.f42a9330550d9681.1a1448ec711.e4fc43891962f8b4=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andrii Sultanov stub_xc_domain_create() fails unconditionally with "Unhandled: ARM" for the ARM variant of arch_domainconfig, so no OCaml toolstack (e=2Eg=2E xenopsd) can create an ARM domain=2E To fix this, convert the two fields of xen_arm_arch_domainconfig, gic_version and nr_spis, into the corresponding fields of struct xen_arch_domainconfig and reject values that do not fit, as is already done for other parameters=2E The remaining fields (sve_vl, tee_type, arm_sci_type and v8r_el1_msa) aren't exposed to OCaml yet, so they stay zero=2E Also add a BUILD_BUG_ON() on the size of the createdomain struct, just like the x86 case, to catch future ABI changes=2E Signed-off-by: Andrii Sultanov Signed-off-by: Julian Vetter --- tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index 180f2fbf45=2E=2E5fa67cdf2f 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -257,8 +257,34 @@ CAMLprim value stub_xc_domain_create(value xch_val, v= alue wanted_domid, value co arch_domconfig =3D Field(VAL_ARCH, 0); switch ( Tag_val(VAL_ARCH) ) { - case 0: /* ARM - nothing to do */ + case 0: /* ARM - GIC version and number of SPIs in the block */ +#if defined(__arm__) || defined(__aarch64__) + { + /* Quick & dirty check for ABI changes=2E */ + BUILD_BUG_ON(sizeof(cfg) !=3D 72); + + /* Mnemonics for the named fields inside xen_arm_arch_domainconfig */ +#define VAL_GIC_VERSION Field(arch_domconfig, 0) +#define VAL_NR_SPIS Field(arch_domconfig, 1) + + intnat gic_version =3D Int_val(VAL_GIC_VERSION); + intnat nr_spis =3D Int_val(VAL_NR_SPIS); + + if ( gic_version !=3D (uint8_t)gic_version ) + caml_invalid_argument("gic_version"); + + if ( nr_spis < 0 || nr_spis !=3D (uint32_t)nr_spis ) + caml_invalid_argument("nr_spis"); + + cfg=2Earch=2Egic_version =3D gic_version; + cfg=2Earch=2Enr_spis =3D nr_spis; + +#undef VAL_NR_SPIS +#undef VAL_GIC_VERSION + } +#else caml_failwith("Unhandled: ARM"); +#endif break; =20 case 1: /* X86 - emulation flags in the block */ --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.2bc.f42a9330550d9681.1a1448ec711.e4fc43891962f8b4=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 11:55:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 11:55:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451714.1666630 (Exim 4.92) (envelope-from ) id 1xHgXQ-0005ga-4A; Fri, 16 Oct 2026 11:55:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451714.1666630; Fri, 16 Oct 2026 11: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 1xHgXQ-0005gQ-0O; Fri, 16 Oct 2026 11:55:52 +0000 Received: by outflank-mailman (input) for mailman id 1451714; Fri, 16 Oct 2026 11:55:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHgXO-0005YH-Lj for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:55:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHgXO-005irR-2Z for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:55:50 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad210b9-bab6-0a2a0a5309dd-0a2a45068da2-28 for ; Fri, 16 Oct 2026 13:55:50 +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 6ad210c5-195a-0a2a45060019-b9ff1c23b627-3 for ; Fri, 16 Oct 2026 13:55: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a14491772e0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 11:55: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 CF94D820A2; Fri, 16 Oct 2026 13:55: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=bEP1KJLvJPIye/L03+Bba3bLDuYREROjy9vT7lGKjE4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=LfbCnWvKl6W/DfpCrggrgqZh4hKb/d2ofrx4SiokHxU7Zuu8NK6uQyjO62E3nsxKfjELui6KR U7M8jnDNiX6GT7ajfB6+TVFPM2vfwd/qHfua9x2JP7ELlyly6gADQ9bsw3i/pUoVyEB8J9dWFNe ZpvqErFykTF3upezAnbzvG4Mh9UjXQk+xt5BJkyBMU5QsFWVcW74wRuwbOwD1IBT/mAKxraXOi6 9FR5bdrNg/I8Bi8R0cYWO0zaBPt7xlLU28e56Bqrl/snbDB+23K9fQhLB7bKqixOA+zXV9ErWEm 1dvMiyNb5yfE1fLvNa99R3tSut8/apk7QMQVtE3y+5SQ== X-Zone-Loop: caef1e2764d721f5ce2c10e8916a513d127bf8c32f86 x-campaign-type: default x-transaction-id: 99eea488-6124-4d29-be42-9707ab898170 x-swg-uid: 01-6ee9d462-cd79-4e63-9096-e53147192dd4 X-Mailer: Sweego Message-ID: <1792151746.8631fc262581453bbf619ec5b2062170.1a14491772e0008425@vates.tech> x-swg-bid: 1792151746.8631fc262581453bbf619ec5b2062170.1a14491772e0008425 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 3/3] tools/libxenstat: fix output initialisation in parseNetDevLine() From: Baptiste Le Duc To: Olivier Lambert Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Juergen Gross , Jason Andryuk In-Reply-To: <1792142038.8631fc262581453bbf619ec5b2062170.1a143fd56420008425@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> <1792142038.8631fc262581453bbf619ec5b2062170.1a143fd56420008425@vates.tech> Date: Fri, 16 Oct 2026 13:55:37 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792151740; l=999; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=T7e+whLdZXdyiegonGx5qOYa3D+L+vpmuvPyzAot4y8=; b=Z8VIRlDcWGY2xB5UUKvZ9ar+tewXuw8tjjWN9Y7JHYrBsm1tnNc122Rv1AcyIrA3RAwxsGhLr N7MAEyx4gBiCv0/nSfBqXltRIK57zIg8P/7YM92kFukWsX2VM57tJs8 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: 1792151745929 X-purgate-ID: tlsNG-16d1c6/1792151750-FC80577B-DD8AC354/0/0 X-purgate-type: clean X-purgate-size: 999 > parseNetDevLine() zeroes all the outputs it is passed before parsing the > line, but *rxPackets is zeroed twice while *rxMcast isn't zeroed at all, > so it would be left untouched for a line that doesn't parse. > > Also, iface is cleared with memset(iface, 0, sizeof(*iface)), which only > covers the first byte. The function isn't told the buffer size, and an > empty string is all that's needed, so write the terminator directly. > > No functional change intended: the only caller passes NULL for rxMcast. > > Assisted-by: Claude-Code:claude-opus-5-5 > Signed-off-by: Olivier Lambert > --- The subject says "fix", but the body says no functional change. Either it's a bug fix and wants a Fixes: tag, or it isn't, and then I'd use Amends: 1fd93d4f8cb8 ("xenstat: Linux dom0 statistics for case we use network bonding") and drop "fix" from the subject. Based on the changes, I think the latter. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 16 11:55:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 11:55:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451713.1666624 (Exim 4.92) (envelope-from ) id 1xHgXP-0005az-Qs; Fri, 16 Oct 2026 11:55:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451713.1666624; Fri, 16 Oct 2026 11:55: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 1xHgXP-0005ai-NK; Fri, 16 Oct 2026 11:55:51 +0000 Received: by outflank-mailman (input) for mailman id 1451713; Fri, 16 Oct 2026 11:55:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHgXO-0005YB-8g for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:55:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHgXN-001IJp-Lj for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:55:49 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad210bf-8faa-0a2a0a5109dd-0a2a450bb236-28 for ; Fri, 16 Oct 2026 13:55: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 6ad210c5-b7e8-0a2a450b0019-b9ff1c12a569-3 for ; Fri, 16 Oct 2026 13:55: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 1a14491767c0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 11:55: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 A12B581FEC; Fri, 16 Oct 2026 13:55: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=xZZNbyZ+czvI07FfZY6DzznwcrGBKtJULS1o7dY160Q=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ZguBwOmICuhHhqSPQqbv3zbAh05ttAniMnwE3VHjP/wbbTnru4BEoXHrGu2705Gljdc609OnW /6H38xO5Ab18muvwv+uIG6lTmShg2Fm+fLcH35uh7C1fmdJcO0q4CL9uY1JqachINYpvDgiMYz2 Hr/AOqTCSGSxwa3VLQYjO0XulzWQhBuyCqY/ZoycC7/OhkcqXWnoOdw8gLjX9pyy+oHeAsvVg/n 7obODvYgj1X7sBUJjJGu7CDldOCwCNl/VaMHrpV9wJc9npJuUZ9fSmNPzMmiA/v4cXkTHsFaAIk N2X/MT/pf2Dy++rcxmx5Yjn83/yk7aQ3iXvnMony+kAw== X-Zone-Loop: 4a513f3a3c8016078a54ab79659a7eee90c424f3f4a5 x-campaign-type: default x-transaction-id: f7b9289a-9ebb-462b-9379-887154be7c7a x-swg-uid: 01-a3cb9b82-db06-455f-9aa9-ee6bda0336fe X-Mailer: Sweego Message-ID: <1792151746.8631fc262581453bbf619ec5b2062170.1a14491767c0008425@vates.tech> x-swg-bid: 1792151746.8631fc262581453bbf619ec5b2062170.1a14491767c0008425 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 2/3] tools/libxenstat: don't skip the /proc/net/dev check after a failure From: Baptiste Le Duc To: Olivier Lambert Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Juergen Gross , Jason Andryuk In-Reply-To: <1792142037.8631fc262581453bbf619ec5b2062170.1a143fd533b0008425@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> <1792142037.8631fc262581453bbf619ec5b2062170.1a143fd533b0008425@vates.tech> Date: Fri, 16 Oct 2026 13:55:37 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792151740; l=686; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=1Ytk61/2hnHD2bxr52O9HptTHEIV25XZQV0sVKT6fM8=; b=EqxN5f/tuz+aOHlzZ1dY4CojTUqKXN/ppzWMkoXMg9uNRn8/XbE05XFWyF+yxcAc/SRbNQl+x drJ/ONi2pxtDJwXqxa3kTd41n/N9czsmU6KY4SuAXTYStA6AfzlVHtL 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: 1792151745742 X-purgate-ID: tlsNG-42698a/1792151749-2C39B9EA-36D2852F/0/0 X-purgate-type: clean X-purgate-size: 686 On Fri, 16 Oct 2026 09:12:58 +0000, Olivier Lambert wrote: > xenstat_collect_networks() opens /proc/net/dev once and validates its > header before using it. If reading the header fails, or the header isn't > the expected one, an error is returned but the stream is left open in > priv->procnetdev. The next call then finds the stream already open, > skips the validation and parses the file anyway. > > Close the stream and clear the pointer on both error paths, so that the > validation is done again on the next call. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 16 11:55:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 11:55:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451712.1666620 (Exim 4.92) (envelope-from ) id 1xHgXP-0005Yb-Je; Fri, 16 Oct 2026 11:55:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451712.1666620; Fri, 16 Oct 2026 11:55: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 1xHgXP-0005YU-Gs; Fri, 16 Oct 2026 11:55:51 +0000 Received: by outflank-mailman (input) for mailman id 1451712; Fri, 16 Oct 2026 11:55:49 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHgXN-0005Y5-R5 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 11:55:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHgXN-00B7RW-0z for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:55:49 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad210c4-e002-0a2a0a5209dd-0a2a4508bb66-2 for ; Fri, 16 Oct 2026 13:55:49 +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 6ad210c4-f659-0a2a45080019-b9ff1c229491-3 for ; Fri, 16 Oct 2026 13:55: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 1a14491762b0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 11:55: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 4B62781F7E; Fri, 16 Oct 2026 13:55: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=0uMpCFm7buZbVhzF2vicy8K+E1v5Wui3L8wPOuiAiTQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=iDc4WGJyB+k5B5eAnoWUWl/NdQ5PjJLxMRaBVhxP2QnShM6wzs2iENLk2QrFmPA1sviJwpB3Z QPZaXzzvGkbxJhKiZfi3oz9HSY3mbrRFwFTuKW+GnJ2Nzowi+qeYjlgXO57w8StbaQuN9zmXTPr QJ69WKCDIk8WIg+zvetolZ9DmJeih5orft3fSf5dRCx4gXVzs6NAYWuYO7dgVV1YBLm/DbTUd7g ozzXleBqXGcMmUolg18oKRGxdN8t846A0JPowXkIFZC7OOOSjzoIYISRKfaffIcZyoE0oICnlh/ B4KMh9TFuddSI4Xpy3RPrQzfHbylzytFdaH9MRP2//Nw== X-Zone-Loop: 63b887f582a4af8029abc1b4b5fcafbff874835313ba x-campaign-type: default x-transaction-id: 10c49e7c-7cb8-476a-b46e-3e2fa5ee401e x-swg-uid: 01-8aead4c8-162b-4f04-adbe-74a26ee88b23 X-Mailer: Sweego Message-ID: <1792151746.8631fc262581453bbf619ec5b2062170.1a14491762b0008425@vates.tech> x-swg-bid: 1792151746.8631fc262581453bbf619ec5b2062170.1a14491762b0008425 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 1/3] tools/libxenstat: don't crash when /sys/class/net can't be opened From: Baptiste Le Duc To: Olivier Lambert Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Juergen Gross , Jason Andryuk In-Reply-To: <1792142036.8631fc262581453bbf619ec5b2062170.1a143fd4e9d0008425@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> <1792142036.8631fc262581453bbf619ec5b2062170.1a143fd4e9d0008425@vates.tech> Date: Fri, 16 Oct 2026 13:55:37 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792151740; l=1596; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=fhar9MJDyWMvMIXdG8Yp+q2cbkS7ri5yufdQtR1u2gk=; b=6UsnZkh9A9kekyTOcJ9/PH9hUHExN5kGGabJGSeS1W44bctBTAnnDMltaRkMGB+Zw+gx/7V1a D+ll7ophuZJA6tWOFv4FloCV+gJBsZeOdBZVWXatjUrVVeHD4MVFXSJ 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: 1792151745397 X-purgate-ID: tlsNG-c1860d/1792151748-D735D87B-8E1EF807/0/0 X-purgate-type: clean X-purgate-size: 1596 > getBridge() doesn't check the return value of opendir(), so readdir() > and closedir() are passed a NULL pointer when /sys/class/net can't be > opened, e.g. when sysfs isn't mounted. As getBridge() is called on every > network collection, the libxenstat user (xentop for instance) crashes > instead of simply not finding a bridge. > > Return early in that case. The caller's buffer is zero-initialised, so > no bridge is reported, which xenstat_collect_networks() handles since > commit 0c53660c1cf3 ("tools/libxenstat: don't lose all VIFs when dom0 > has no Linux bridge"). > > Fixes: 1fd93d4f8cb8 ("xenstat: Linux dom0 statistics for case we use network bonding") > Assisted-by: Claude-Code:claude-opus-5-5 > Signed-off-by: Olivier Lambert > --- > tools/libs/stat/xenstat_linux.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/libs/stat/xenstat_linux.c b/tools/libs/stat/xenstat_linux.c > index 2a7d2f1a96..ec627f3ef5 100644 > --- a/tools/libs/stat/xenstat_linux.c > +++ b/tools/libs/stat/xenstat_linux.c > @@ -75,6 +75,9 @@ static void getBridge(const char *excludeName, char *result, size_t resultLen) > char tmp[512] = { 0 }; > > d = opendir("/sys/class/net"); > + if (d == NULL) > + return; > + We might want a message telling it failed as it's already done in the file for SYSFS_VBD_PATH. I'd propose: if (d == NULL) { perror("Error opening /sys/class/net"); return; } Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 16 12:04:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 12:04:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451737.1666646 (Exim 4.92) (envelope-from ) id 1xHgfM-0008Qu-1H; Fri, 16 Oct 2026 12:04:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451737.1666646; Fri, 16 Oct 2026 12:04: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 1xHgfL-0008Qn-Uy; Fri, 16 Oct 2026 12:04:03 +0000 Received: by outflank-mailman (input) for mailman id 1451737; Fri, 16 Oct 2026 12:04:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHgfL-0008Pc-2I for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 12:04:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHgfK-008OYn-F9 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:04:02 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad212a1-e002-0a2a0a5209dd-0a2a4509a838-46 for ; Fri, 16 Oct 2026 14:04:02 +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 6ad212b2-be1a-0a2a45090019-b9ff1c22a5ff-3 for ; Fri, 16 Oct 2026 14:04: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 1a14498f2800008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 12:03: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 BF879810D3; Fri, 16 Oct 2026 14:03: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=8CegonCPRnIDcdqQqeYqAwfUGNYDEcDqoO/Z/vNAn+8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ghAZ6qYqOueX6MoFFlePqWmC1gJdti/6JX0Nb1tZULUoU8ngSl7/0IIM5WC0jqEDlZCScsDcU OUf2rX3uNpXeP5kRuOOzUxNvKURD4WLO0twpMsoFMe0MSFAt6i1/dDrX9D8uVH/u9T3B/ZQIiXW Hm84IVlWz8LrP2ydwIUbri3QuEHjzys9EjiXbcDDHrn72lNkvRvmp2w1md31qkjwAodkP+VQTtA nlh65wimEtO8E8/Z/SXl4q3HGKL9PhUfQv3wEqS7kOuadOp/EMCoeOqIJ5U7kYQYj3dojEOENCI Mb8P41QEtZ3f6B1mtTUUqZaW4TgSpiUEPlupP3DJPkog== X-Zone-Loop: 187b9b7ac314450860fdf3cbf6813cf0a68892a55e67 x-campaign-type: default x-transaction-id: 6764cce0-239f-40bc-9612-08c977911d7f x-swg-uid: 01-2d11916c-0084-4cb8-9fd4-e5745ca1581b X-Mailer: Sweego Message-ID: <1792152236.8631fc262581453bbf619ec5b2062170.1a14498f2800008425@vates.tech> x-swg-bid: 1792152236.8631fc262581453bbf619ec5b2062170.1a14498f2800008425 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 1/3] tools/libxenstat: don't crash when /sys/class/net can't be opened From: Baptiste Le Duc To: Baptiste Le Duc Cc: Olivier Lambert , xen-devel@lists.xenproject.org, Anthony PERARD , Juergen Gross , Jason Andryuk In-Reply-To: <1792151746.8631fc262581453bbf619ec5b2062170.1a14491762b0008425@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> <1792142036.8631fc262581453bbf619ec5b2062170.1a143fd4e9d0008425@vates.tech> <1792151746.8631fc262581453bbf619ec5b2062170.1a14491762b0008425@vates.tech> Date: Fri, 16 Oct 2026 14:03:50 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792152230; l=555; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=UFvOl0JCuI5/lO+01x1fRLCuPTXzJn1Xfy4yNVhxkgE=; b=yA5po+7HmaOMdXLJgWLA3ASwfNVnB0eA4hlTPWnKqERtMe+g6xGH0OEAMsYvDCUs1kZW+mDWe 03n21n2qVrZA/zJ3eSAvKteipsbOH7E8/SdQZnyJURDLKWm3Kzbfqfi 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: 1792152235890 X-purgate-ID: tlsNG-bad1c0/1792152242-BEEDE034-CD63C806/0/0 X-purgate-type: clean X-purgate-size: 555 On 2026-10-16 13:55 +0200, Baptiste Le Duc wrote: > We might want a message telling it failed as it's already done in the > file for SYSFS_VBD_PATH. > > I'd propose: > if (d == NULL) { > perror("Error opening /sys/class/net"); > return; > } Please disregard my previous reply, it was a draft sent by mistake... Returning silently seems to be fine as missing /sys/class/net isn't fatal here. Sorry for the noise. So: Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 16 12:49:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 12:49:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451798.1666655 (Exim 4.92) (envelope-from ) id 1xHhMa-0006hq-7d; Fri, 16 Oct 2026 12:48:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451798.1666655; Fri, 16 Oct 2026 12: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 1xHhMa-0006hi-4w; Fri, 16 Oct 2026 12:48:44 +0000 Received: by outflank-mailman (input) for mailman id 1451798; Fri, 16 Oct 2026 12:48:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHhMY-0006hZ-AI for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 12:48:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHhMX-00CLd9-Hr for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:48:41 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad21d21-bab6-0a2a0a5309dd-0a2a450a92fa-26 for ; Fri, 16 Oct 2026 14:48:41 +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 6ad21d29-f2d2-0a2a450a0019-d155802fb56a-3 for ; Fri, 16 Oct 2026 14:48:41 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a180fbeef5so58116715e9.1 for ; Fri, 16 Oct 2026 05:48: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-4a1c8de7230sm55726975e9.14.2026.10.16.05.48.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 05: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=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=1792154921; x=1792759721; 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=RP2aUyToeA5O/gznKtJvOUMU63RbbldXp/RugayuiYg=; b=dd0tHl/zugQam3sA7P2DnAPDLRqBrcPmLw9WevPnsgPZ8mkqYag/GzZA6tDHvOxLNK zHaRReLP8VWHBdhBOs30H3E3tCnsAjN+P3EXnK76oxhOULjJPkfb9dGJX53lz0LPhZib 2IkPXMbir3ujP7luer7O9hT5s8vzKsP8lO1Hdnorp/i2/J27+lqkW/yX53jSNApPU0pM YE1PCpKjWSvktHiGWo72b56OJvwR5hrmuvTrokScsz26XlGXoS+6i9d8GalLby8CPrbB a6OBznMD5UO0LBqEf97Ff/+YA5a/NKC7l397i7n3aFBSr/pgirtRmxn/V+9uO8698NOE Trfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792154921; x=1792759721; 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=RP2aUyToeA5O/gznKtJvOUMU63RbbldXp/RugayuiYg=; b=XlrgN27zPiyQozZxqWggnnWfT95XrVOzzte2eatoIVPqoFwlggn/wW95R/x7NftcpO Hsro0Wuqc8ar8kF0OOHpWyXbtzA4kQ5Ud7tTkrsBh99pki0ai7nVNF/mMu3gq0TD4vru I0an0Cwz+ZVmpY006EJt8PNJBu8apuz9iTZD9TcRYzLwzywkbRClcxG3ngPTJfmICRk5 N7XvKMBGyJ40dFI6ILAeWsWW05GhnmAkune32iqBdBfeinivNS+lza/TU0eU2/c21yO+ F64aG79dBtW+aP52/2Tf3dkSdkse8w5pzlUKCq9AZDRuS8U8aqX3YZoMTckGdNbBi5Ck mYZQ== X-Forwarded-Encrypted: i=1; AKwUvByr1SFh3ORXTQCsX9BDI3PB2+HuJhQrZ51XW/y1w+CEyweqMgjO2JvOL6UosEc3gvWX4NJM1KEDNF8=@lists.xenproject.org X-Gm-Message-State: AFq9FYLHgs7OPgEx7nSuj/kspOe1i/Mwb2v389p8gODM4zVMcNw5dMSw R1PccHU4hgMH39xnQhwGWREx3t4RRFgPlZrdvA9ghvdNcb1ZUAUrs8NbQYo1Y37qjw== X-Gm-Gg: AYBFou35kn02EP+yDjNtD2rPw/C7Sk6PtZQ6yI+dzcy5gJAwwFUZVqe+AQCHcWA1nIJ mSldjDzcD3BUt29vkanyfNluBj3UH0uAwZbA4EzTrPpbZLcUZgEvP+htBG6fKHFTmxyNPlI5hVX mZKrYxpapQCDbvfUlaE/Nacm1PqO4bLqtzr+oeoTUfVeUizgt9/teXB0ahcJUaVTqPWtflEDmJc u7shjXKnF2pGAXmY1mXTHbAiF5TS3TXKZ3xU60KNptc28Ke/HtleGEFQCIV4BpWZa0Hf+1wm3/U qrnnckZ5Lz5FXZHuZLZROcJUN74zuLXtcvy6lgenTNRQLLtJmn51y0iML3eFgt4mBV543fV8efR vIlm/ljwY9t664XJB1zWi4wi0MvctxEinTwI8Mq5geAAMOJqy4B69CVHruVVU8CXiI06zLwc/OO kMEEaD7oPU1pRz0/XfX2sQt6Tm0kRaJxORVfsq90wzk8EQdlt/qmDMSIlsHOcpUeMFD4pJ3R+Dg pJhPYVwIZp2yFeicnrcBvlzso9TOg/xpUtYqM3H6e3NP485axbcVDD05pZIoRZb5+OsWTDo X-Received: by 2002:a05:600c:8105:b0:49f:fdca:c361 with SMTP id 5b1f17b1804b1-4a18e483818mr495521215e9.12.1792154920822; Fri, 16 Oct 2026 05:48:40 -0700 (PDT) Message-ID: <25337ffe-67fe-4db9-8407-2f227eebaf32@suse.com> Date: Fri, 16 Oct 2026 14:48:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc Cc: Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> <81ad5bb7-2300-4ac2-a999-adbb39270ddf@gmail.com> <2f04c46d-f533-4eda-9bd1-8b8e100dff07@suse.com> <1792150520.8631fc262581453bbf619ec5b2062170.1a1447ec1cc0008425@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: <1792150520.8631fc262581453bbf619ec5b2062170.1a1447ec1cc0008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1792154921-4B8D5CFC-B0FC25C1/10/78276251493 X-purgate-type: spam X-purgate-size: 2329 On 16.10.2026 13:35, Baptiste Le Duc wrote: > On 2026-10-15 18:04 +0200, Jan Beulich wrote: > Based on Andrew's answer to your question on GitHub [1], I see two options > for handling a DT that doesn't advertise the scheme in effect. Please > feel free to choose one. > > 1) Trust the probe and fix up riscv_isa on a mismatch. This avoids having > people edit their DTs, and is safe as, per Andrew, the spec has only ever > allowed these two schemes: > > /* > * The privileged spec allows exactly two schemes for the PTE A and D bits: > * 1) hardware sets them on access and on write. > * 2) accessing a page whose A and/or D bit is clear raises a page fault, > * so that software can set them (ratified as Svade). > * > * Hence an implementation without Svade uses the hardware scheme (1), and one > * that faults on clear A/D bits implements Svade, whether or not it says so. > * > * Rather than trusting the DTS alone, probe the scheme in effect with a write > * through a PTE whose A and D bits are clear. If the DTS does not advertise > * it, replace it by the probed scheme. As the spec has only ever allowed > * these two schemes, this is safe even on implementations that predate Svade > * and Svadu. > */ > static void __init check_ad_scheme(void) > { > bool has_hw_scheme = probe_hw_ad_update(); > const char *scheme_name = has_hw_scheme ? "Svadu" : "Svade"; > enum riscv_isa_ext_id ext = has_hw_scheme ? RISCV_ISA_EXT_svadu > : RISCV_ISA_EXT_svade; > > /* Fix DTS in case of mismatch */ > if ( !riscv_isa_extension_available(NULL, ext) ) > { > printk(XENLOG_WARNING > "CPU implements %s but the DTS does not advertise it\n", > scheme_name); > __clear_bit(RISCV_ISA_EXT_svade, riscv_isa); > __clear_bit(RISCV_ISA_EXT_svadu, riscv_isa); > __set_bit(ext, riscv_isa); > } > > printk(XENLOG_DEBUG "CPU is using %s A/D bits scheme\n", scheme_name); > } Yes, if the assumption is that this would be used only when neither extension is advertised, then I agree (taking Andrew's response into account). I'm sorry, this has been quite a bit of back and forth, but hopefully we're now all on the same page. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 12:54:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 12:54:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451809.1666666 (Exim 4.92) (envelope-from ) id 1xHhSS-0008GF-Rn; Fri, 16 Oct 2026 12:54:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451809.1666666; Fri, 16 Oct 2026 12:54: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 1xHhSS-0008G8-O0; Fri, 16 Oct 2026 12:54:48 +0000 Received: by outflank-mailman (input) for mailman id 1451809; Fri, 16 Oct 2026 12:54:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHhSR-0008G2-LE for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 12:54:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHhSQ-00BGix-Qr for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:54:46 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad21e92-8faa-0a2a0a5109dd-0a2a45039924-10 for ; Fri, 16 Oct 2026 14:54:46 +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 6ad21e96-fae8-0a2a45030019-b9ff1c2291c9-3 for ; Fri, 16 Oct 2026 14: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 1a144c773b70008425.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 12:54:44 +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 7FB9C81C51 for ; Fri, 16 Oct 2026 14:54: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: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=OFrjOydgbXbYmd2KfoPWBQuqOzqAk+vjEZYtPkE6yYk=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=QEQQ+/R2x9/OqItkW0lBrTEO0xSExxKxyupPXFChoQslFmtLf8mOizonkbO5qqsouBw1fohz4 a5tnBX2ZPxPNf6IdnXdS8k8KZ5Bn8mTABW7JWgLNgCsd8ISZsYumCywuRXnl6g/b4LftC+7Cm71 oyaXtX4FUsPwcDXRjtz9qFeJURSAJ8lK9yqMET/j67H+B7LEUwWyDoJDNLzxe/c5P/X4y0Z/Pvm QOHVW5yUusPCedURZPJRWlHXs+KKLE55YM3SRIMqWbu283wdfxr1dy2L0f6YZoQIrS1Nz3V8bwJ Wj6qTc5jgOXCXhSEiBtURj6hv7IzioItlr6JIp6Q435Q== X-Zone-Loop: 02c6435009343f1a2306fc2243c04923f85cf971622e x-campaign-type: default x-transaction-id: 47ecea21-6ce2-4cba-a1a3-e505dad5c52d x-swg-uid: 01-6d23d54f-4718-488b-9ae3-55576cbb96e7 X-Mailer: Sweego Message-ID: <1792155284.8631fc262581453bbf619ec5b2062170.1a144c773b70008425@vates.tech> x-swg-bid: 1792155284.8631fc262581453bbf619ec5b2062170.1a144c773b70008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 16 Oct 2026 14:54:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: xen-devel@lists.xenproject.org References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <1791886038.8631fc262581453bbf619ec5b2062170.1a134bb169d0008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> <81ad5bb7-2300-4ac2-a999-adbb39270ddf@gmail.com> <2f04c46d-f533-4eda-9bd1-8b8e100dff07@suse.com> <1792150520.8631fc262581453bbf619ec5b2062170.1a1447ec1cc0008425@vates.tech> <25337ffe-67fe-4db9-8407-2f227eebaf32@suse.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: <25337ffe-67fe-4db9-8407-2f227eebaf32@suse.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: 1792155283568 X-purgate-ID: tlsNG-33051d/1792155286-6F2C84E9-9213B6CE/0/0 X-purgate-type: clean X-purgate-size: 2740 On 10/16/26 2:51 PM, Jan Beulich wrote: > On 16.10.2026 13:35, Baptiste Le Duc wrote: >> On 2026-10-15 18:04 +0200, Jan Beulich wrote: >> Based on Andrew's answer to your question on GitHub [1], I see two options >> for handling a DT that doesn't advertise the scheme in effect. Please >> feel free to choose one. >> >> 1) Trust the probe and fix up riscv_isa on a mismatch. This avoids having >> people edit their DTs, and is safe as, per Andrew, the spec has only ever >> allowed these two schemes: >> >> /* >> * The privileged spec allows exactly two schemes for the PTE A and D bits: >> * 1) hardware sets them on access and on write. >> * 2) accessing a page whose A and/or D bit is clear raises a page fault, >> * so that software can set them (ratified as Svade). >> * >> * Hence an implementation without Svade uses the hardware scheme (1), and one >> * that faults on clear A/D bits implements Svade, whether or not it says so. >> * >> * Rather than trusting the DTS alone, probe the scheme in effect with a write >> * through a PTE whose A and D bits are clear. If the DTS does not advertise >> * it, replace it by the probed scheme. As the spec has only ever allowed >> * these two schemes, this is safe even on implementations that predate Svade >> * and Svadu. >> */ >> static void __init check_ad_scheme(void) >> { >> bool has_hw_scheme = probe_hw_ad_update(); >> const char *scheme_name = has_hw_scheme ? "Svadu" : "Svade"; >> enum riscv_isa_ext_id ext = has_hw_scheme ? RISCV_ISA_EXT_svadu >> : RISCV_ISA_EXT_svade; >> >> /* Fix DTS in case of mismatch */ >> if ( !riscv_isa_extension_available(NULL, ext) ) >> { >> printk(XENLOG_WARNING >> "CPU implements %s but the DTS does not advertise it\n", >> scheme_name); >> __clear_bit(RISCV_ISA_EXT_svade, riscv_isa); >> __clear_bit(RISCV_ISA_EXT_svadu, riscv_isa); >> __set_bit(ext, riscv_isa); >> } >> >> printk(XENLOG_DEBUG "CPU is using %s A/D bits scheme\n", scheme_name); >> } > > Yes, if the assumption is that this would be used only when neither extension > is advertised, then I agree (taking Andrew's response into account). I'm sorry, > this has been quite a bit of back and forth, but hopefully we're now all on the > same page. Ok thanks, great to hear. Just to not mistaken, when you said "would be used only when neither extension is advertised" it would means that in other cases where there would be a mismatch between what the DTS advertised and what the CPU actually support we should panic? > > Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 13:01:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 13:01:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451823.1666674 (Exim 4.92) (envelope-from ) id 1xHhYQ-0001az-Dx; Fri, 16 Oct 2026 13:00:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451823.1666674; Fri, 16 Oct 2026 13:00: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 1xHhYQ-0001as-BE; Fri, 16 Oct 2026 13:00:58 +0000 Received: by outflank-mailman (input) for mailman id 1451823; Fri, 16 Oct 2026 13:00:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHhYP-0001am-Ko for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:00:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHhYP-00BI3v-1G for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:00:57 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad22008-e002-0a2a0a5209dd-0a2a4503e226-2 for ; Fri, 16 Oct 2026 15:00:56 +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 6ad22008-fae8-0a2a45030019-d155802cf0ee-3 for ; Fri, 16 Oct 2026 15:00:56 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a0286c981dso29903355e9.2 for ; Fri, 16 Oct 2026 06:00: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-4a1cf05009csm40328065e9.10.2026.10.16.06.00.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 06:00: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: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=1792155656; x=1792760456; 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=+VzQasMx3AclanLA//drErojCbGFBcuIocNUtysrGL4=; b=WZ/KqLzC5ROOIOis6e4mTWHlKj+SWUsqZCa7y4II3W5VEmfaloaHpiC53Y4f8luZmi d985irvzkDoQTjfgU+uEWq0WvINe+clbFHmv7L6tbwlsZHLXC73aWvJcatcZ1534RVU+ TWTb8PbtBlA/YxE7eij+L89969m/dLA6YesHRO/Vmex929YShcTx6TnMk09f1TFKPVvy pj6MP4ggvj9Oj9K6hmTPxMmnwN2jllYphXm3Q+nx4mCYPUwYiXHTJKIW5qX2ZTPVUEDX MObB4Hp68znK/398rMnzRdWwHnT/qo+Mf9WpoyzXxdvsvId4WBpeFSU8EiftCeBJjJuJ 2Szg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792155656; x=1792760456; 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=+VzQasMx3AclanLA//drErojCbGFBcuIocNUtysrGL4=; b=HXxMw+yfAKqFu98G8GziPR8A4ayOX7FbMZLq7VvzhEQgCHcIJEnCO5LX0YXonM+9um RNIJW+/U4FY47inVNwdnwxQ8Mt+wLi+xJM6H0w3233/gkD91etb+cU9FLp4007hLLLlK NnSvouzHDO1Rlgf1qYjEqF5P5DSyNEa5qKf7tgFmkHm6auOYHmEE94otnHVpkWQQOGIR 5AJywgWUe+l4wKAUlSaa87dpqtHY1Yles72+1RfJWVN5D9EQsLaVZqDY3Q7OWtGysDIv emmMXngo5uJkEW75yGRqFBnaXboXqObswbsHPniv5GqG4T4iACnGSvDleJIOra30tVIP /rGg== X-Gm-Message-State: AFq9FYK+oau3jPtrLgrJiloMV+XXcNSqvmQMKlVlOdYZ3xKKDP9rhd3p jQRzZrhIJ31OPDZ3z8B7gMT73WjaMpILSS8GmoVMCC/vHGhqqOfgYSlU2ci103JooQT/m+z1aoy T4MHOaw== X-Gm-Gg: AYBFou1gytP/A90N0CZUdakjn2pmTRIKD66VPP6P7TfBOnAmor408nfJDn4uKf43aEK iepUVDgqFTYg+lkXUs4Bgz93Agh9T5+dDb/2OQJ3tqRj1BWJwvEzRJ3S6OXW3+IhkesbYSSc5Xw 67ma+PLSgApOqm6s2pRJaPqbKtnajQ8PICsczD0JjYYioRdwuvNreCF5tsK5JTo7WYTe27WsmNQ GTH0uih/GaOC/xCNJf5h4FuQNJTVkDvMV3YJbj1GM0ZYsaq/BR3z5+VLAQG/5+RUNBYV73KyIdY 7zGER1KCAoITen7gT98oJ5thxuSYqM+3rzFLRPGOZdnqHRL1TQ41m2LGjMRvRnfUspcFU3kK36P AZV+akqUTmzrI0Lc0rkiMlHYZRA6dr2kMb9YYHLcNW9Mf78pv1botat7NSRrBaZLQhwmcGPSI3z r7+JBM5lSLsw2ucjVkh3w6x3S5/5ulpt57IdqnW2oAlWBobJfubwvZFyGaZOMgcdOqXHvrTq1sN LDI0wpt5qdz8qsErJ4DLrZBtvxLKoQ6Lkry0GC/HnoFiMndZnXZk2IHTYalyA== X-Received: by 2002:a05:600c:8518:b0:4a1:7ecc:b23c with SMTP id 5b1f17b1804b1-4a18e49879dmr417473045e9.6.1792155656301; Fri, 16 Oct 2026 06:00:56 -0700 (PDT) Message-ID: <37a6531e-0908-4453-acf2-4174966ac4c2@suse.com> Date: Fri, 16 Oct 2026 15:00:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot To: Baptiste Le Duc References: <1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech> <21a48f53-385b-4f36-958c-cc82bf390c89@suse.com> <1791901979.8631fc262581453bbf619ec5b2062170.1a135ae53690008425@vates.tech> <7ed5d117-80d5-4862-af60-c3e0143564ea@suse.com> <1791968412.8631fc262581453bbf619ec5b2062170.1a139a403a30008425@vates.tech> <1791996314.8631fc262581453bbf619ec5b2062170.1a13b4dc2b50008425@vates.tech> <4e914f14-50ff-48a5-9f56-836913e487fb@suse.com> <1792052907.8631fc262581453bbf619ec5b2062170.1a13ead4e580008425@vates.tech> <7f5da80c-424f-49dc-8ce3-10ca2fae9f55@suse.com> <81ad5bb7-2300-4ac2-a999-adbb39270ddf@gmail.com> <2f04c46d-f533-4eda-9bd1-8b8e100dff07@suse.com> <1792150520.8631fc262581453bbf619ec5b2062170.1a1447ec1cc0008425@vates.tech> <25337ffe-67fe-4db9-8407-2f227eebaf32@suse.com> <1792155284.8631fc262581453bbf619ec5b2062170.1a144c773b70008425@vates.tech> 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: <1792155284.8631fc262581453bbf619ec5b2062170.1a144c773b70008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1792155656-6E2D04E9-6721D603/10/78276251493 X-purgate-type: spam X-purgate-size: 3032 On 16.10.2026 14:54, Baptiste Le Duc wrote: > > > On 10/16/26 2:51 PM, Jan Beulich wrote: >> On 16.10.2026 13:35, Baptiste Le Duc wrote: >>> On 2026-10-15 18:04 +0200, Jan Beulich wrote: >>> Based on Andrew's answer to your question on GitHub [1], I see two options >>> for handling a DT that doesn't advertise the scheme in effect. Please >>> feel free to choose one. >>> >>> 1) Trust the probe and fix up riscv_isa on a mismatch. This avoids having >>> people edit their DTs, and is safe as, per Andrew, the spec has only ever >>> allowed these two schemes: >>> >>> /* >>> * The privileged spec allows exactly two schemes for the PTE A and D bits: >>> * 1) hardware sets them on access and on write. >>> * 2) accessing a page whose A and/or D bit is clear raises a page fault, >>> * so that software can set them (ratified as Svade). >>> * >>> * Hence an implementation without Svade uses the hardware scheme (1), and one >>> * that faults on clear A/D bits implements Svade, whether or not it says so. >>> * >>> * Rather than trusting the DTS alone, probe the scheme in effect with a write >>> * through a PTE whose A and D bits are clear. If the DTS does not advertise >>> * it, replace it by the probed scheme. As the spec has only ever allowed >>> * these two schemes, this is safe even on implementations that predate Svade >>> * and Svadu. >>> */ >>> static void __init check_ad_scheme(void) >>> { >>> bool has_hw_scheme = probe_hw_ad_update(); >>> const char *scheme_name = has_hw_scheme ? "Svadu" : "Svade"; >>> enum riscv_isa_ext_id ext = has_hw_scheme ? RISCV_ISA_EXT_svadu >>> : RISCV_ISA_EXT_svade; >>> >>> /* Fix DTS in case of mismatch */ >>> if ( !riscv_isa_extension_available(NULL, ext) ) >>> { >>> printk(XENLOG_WARNING >>> "CPU implements %s but the DTS does not advertise it\n", >>> scheme_name); >>> __clear_bit(RISCV_ISA_EXT_svade, riscv_isa); >>> __clear_bit(RISCV_ISA_EXT_svadu, riscv_isa); >>> __set_bit(ext, riscv_isa); >>> } >>> >>> printk(XENLOG_DEBUG "CPU is using %s A/D bits scheme\n", scheme_name); >>> } >> >> Yes, if the assumption is that this would be used only when neither extension >> is advertised, then I agree (taking Andrew's response into account). I'm sorry, >> this has been quite a bit of back and forth, but hopefully we're now all on the >> same page. > Ok thanks, great to hear. Just to not mistaken, when you said "would be > used only when neither extension is advertised" it would means that in > other cases where there would be a mismatch between what the DTS > advertised and what the CPU actually support we should panic? No, what I meant was that likely we shouldn't even probe there. We don't probe other extensions; I don't see why we shouldn't trust DT here. The outlier is when DT lacks any information. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 16 13:58:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 13:58:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451930.1666767 (Exim 4.92) (envelope-from ) id 1xHiRM-0002gR-BL; Fri, 16 Oct 2026 13:57:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451930.1666767; Fri, 16 Oct 2026 13: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 1xHiRM-0002gK-8Y; Fri, 16 Oct 2026 13:57:44 +0000 Received: by outflank-mailman (input) for mailman id 1451930; Fri, 16 Oct 2026 13:57:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiRL-0002g9-7N for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 13:57:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiRK-00AmjV-Jm for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:57:42 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad22d2c-2eae-0a2a0a5409dd-0a2a4502c4d6-46 for ; Fri, 16 Oct 2026 15:57:42 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad22d54-6ca4-0a2a45020019-94a397447fdc-3 for ; Fri, 16 Oct 2026 15:57:41 +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 69GABbps2741207; Fri, 16 Oct 2026 06:57:36 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020088.outbound.protection.outlook.com [52.101.85.88]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4haxj936j4-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 06:57:36 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by CO6PR02MB8836.namprd02.prod.outlook.com (2603:10b6:303:147::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Fri, 16 Oct 2026 13:57:35 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 13:57: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=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=R2XJd+bzf7a5y0OLUtZYoxG8U9doHLHY9o2PABFAv 1Y=; b=z3KyA7uwIiLAyjP2uEh2IfdrRrZBwWFRPkDVEPPPfwTrqjw8X60L9ihr3 FbnW/O7jtd5s+Tgu1UxUmRo40KPRV0psOYwzl/HKjADbsTNecOAcm5nR9jzMxOj2 uLziYrKOzZTwzvGEEYsx5h0kVLybBn10YYQNfXairg/I/BzdbdVFR4RCWdAowOvi hpIol2WTWMI4J3ePsOoKqqHAPQJl3m6RLWpBwpd14l8TmwEs5PM0GzpwBNqFzCH3 9KaM28Q2MLoPLFm5Z48ofuAOX0dyFjqX5/wtPCpWCa+RATiye7ckVDVRDLzx1Ja2 0ZQz9+GZSEjICvLCMZBdIJZGilDxQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=etR5PrpKRnvjG9jQw9Y0d8ysZsA6rMQFjCx+YXjg5rfcLNxewRlDhwORfoBYJuChLWesQ8qkGu/01mTmQr/u2iAVYnqSpIo8nvJabqqViQpE10qfNM1fIqElR/+t6HmpGPQZoeGuQVAK+pSCYoQ/EYtSY6WxGmoWMtI9Pli1H3R2CF6zV0BQYXWurfdjhjC6yIWCJ4qQNmnqMRo27E8HSPjEagvAwvAHyN8a4I886dpN2pJ/X8w6Q39GF6ULtUNQngiEc2C+vii2MvlDW6TGFUkXca3eJ8a4glVk028ulEIEmTLmDijPlFE8YQX4x3n5DwRYyyMHDL6kO6rok3N7YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R2XJd+bzf7a5y0OLUtZYoxG8U9doHLHY9o2PABFAv1Y=; b=xM/13Dm3GnSMqpHCpgPgN3AcsRubIsrbCcAFtmn2dsJdZGZJEU6cmLcnIxZMZpRg6lbqivwUYwhQmv4GmmJKE4v8l6HnGswQrEDWvSGj0/EBivd6wZYoXNW9I6N/NArOHTA325ZhuMxs4g7xXfApYwyJ8KpDuO6gSooUdagCKRkt/ZfmW/SyHZQTb5cVoOgF+glpRL37ezccVNPIp84bNOXDk9KCr0okohfXU55V4BxJ8uJMu4Zwzrpx34rZFwvYZzmAPBfgPuQp+3uOaR5bqBR+R6vK+S7p11VeRH6skXjtlwguFVmiS5ViNvejK1RsqzHsfLWlCDWsAdKG9r7DkQ== 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=R2XJd+bzf7a5y0OLUtZYoxG8U9doHLHY9o2PABFAv1Y=; b=BfJ5ZARezjwi7wk3RDXEpW2FAMG+xWJHSYonvEFwj1nRSQ5xTkH6IqU7gmVg0RD3i2xTjosGxbx3ttQevN3aKqdj2TDBALmHNSxHpz5VpDZdHASAh0puLjk/tF02lI4zwp1k4SY+AW4BijrDDefnB6NK5B/BrdENjyTIafR7ibdisuppQNYuki4zu/RcllC2FOiuYQ/ycn7g2thWvlXe2khBp3F7rXWJE6evJRl3XUwinxZZvposUIjyg2WKt7NTmvysaPE8QSq9IRRpPY+rZKPQ84zaxFTLZjEn9S1trWnSUOANCWtIAsKqkNhK3SCKJNjYAIqRyAE9XCpKJXpqdw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: Date: Fri, 16 Oct 2026 14:57:29 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 21/22] i8259_common.c: remove static irq_count and irq_level variables To: Peter Maydell Cc: 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 References: <20260916104435.600211-1-mark.caveayland@nutanix.com> <20260916104435.600211-22-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY3PR05CA0024.namprd05.prod.outlook.com (2603:10b6:a03:254::29) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|CO6PR02MB8836:EE_ X-MS-Office365-Filtering-Correlation-Id: 48dd3b05-83e2-497d-f078-08df2b8d6e2a x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|56012099006|4143699003|22082099003|10067099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: 6EcYbohtM/CvT2NXVy3C+FBE/h2PloIn7DAJDfmLDi4ijCRKKEMS0+/LXfU+Nd/Ua9JH/SXWTxwCHVaqoJWGxC361ImQEITml1KTYk3vdUbvUxL3sm3N4ZiudRohSbhwnola4D48w5EoElHFJ/A1kUmHQPvaWoZ9BhrJqBEwzJlOUrJ7lPwD9Jra2F8bWggK1tCwf+MLknyx2JBk2x9jNURaKbC8Y8wkRL6x9JwPLteSYmH10Jbkxj2MYWPfzE4buC2hkVe1cffnp8m25DkfQawQlATnjTWJ6ClZSeUsyIfYOyf2UjMRHqUhTIZY7TOe3V/02uTquckYRZZ8M4g962FLtDFCcqy0wiShERH43e7lDpuoqzsbG0mKuzJ344QAmEYNacv4gvfB9TUs0lYMzQUCrxu/PjA6LRwGhZySOKbvfGeb3yDXLeVm8rb7yfmVZjYjALlEHZxKXoNotTAoLWt4Bz3Qpfy2yekrGqj2EUrHa+BWh/efNgoNxn5cF4qtjiaRfGIVkdqYSdZEWWj4zXpPmopzGI9RBKf0R6dlhYcHRO8G/Z9ZWw4INl6u8LKScv5ACeTjpF4JxdE4HnzNrnLpalet5CNFNBQRmicn2wacqlTG0osCxLSsDlOfBW9Mn65+v3ozOqI+BdKW8hFLQEDxh43T16JHYd17/VDvNog= 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)(23010399003)(376014)(366016)(1800799024)(56012099006)(4143699003)(22082099003)(10067099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MnJPbGp5UUIvN3FKM0NpaFpoRFh0cUdYZXpDOHN3VXFyN1A2a3J6d0hjc1Fp?= =?utf-8?B?dmVyNWFCUVAxVENCOXdWZnRJVVRBWDZ4WkJiR3dPMFNndlVJTkczQ3UwTEhs?= =?utf-8?B?NFpxT3lhd3RjT0dNQzFPRHpsODRGbzF5Ym5HUkpOV0pMZUp4Y2FNRjZZQ2Fw?= =?utf-8?B?RjkyNS9KZVZEUDNTMTJjS3cxTDhVMXlQOUVDZ3Q1UGJ0cGUyVnh0bjlBaVJ0?= =?utf-8?B?MzNEbmtEQjNldGxrdVFqWkpDc1V4eCtPOUkyVmdodnFvVzFta21CQWpyOTM2?= =?utf-8?B?eXhjRGNLRDc0M3FhZUtCeERMKzEycFVKR1c4bXNIM0hNSHAyK05GeUZSelF2?= =?utf-8?B?dXY3cDFQaEMwZDJHc1VKNUxraGM1VFBTYWNFODRCeUpscU95TThRWFI3YTR0?= =?utf-8?B?QzRDL0xYTUpxUU1DN2RWRlRKaVRnZEJFRXk2Z0QyUmFhbFJqMEVvQ3FBK1dJ?= =?utf-8?B?QmdNaGVWcVFIaEJnTTRaeHQrWndlRExlUGNhL09xeHMxaWxzQXlwUkhrd0lU?= =?utf-8?B?TThKN3pEenFRdmlaY2R1QUZpL0d0UENNUm1FL1BCdjQvTHFwL0xubWczbFF1?= =?utf-8?B?bk92LzlJQW5maTh5SHpUaWk4ZXU5Tzl4Ry9ycE9uVEl6QzY1ekNJVU91anNn?= =?utf-8?B?M3hFb1V2V0tyMnlUdlk4d1RucGFiclhJeG8vQlV2bDhXKzhiN3pDZjEzRHg0?= =?utf-8?B?SEloRHdaemxENk0wVkVQVDY3S3NxZ0RXc3BxeDJvdGV6b1pmUEVSb1d4dkpB?= =?utf-8?B?dlkrZW50ZTBncjhLZG1QV3VoN2pEYWRiU2x5TS9MREJGTUY5eUcrdEQxRmIz?= =?utf-8?B?dlhLbUpLaEVvM1FVRlczZW8xSWJqbHg1MnVReUdBU0lKajQ4T2l1UHBGUHEz?= =?utf-8?B?QWlja253SW15RVBmeVRaakVCTnNCTzliR0VoKzczY3pkSis2UU5yUEtOVjJk?= =?utf-8?B?eUY1R3c1TTRabU5JMXRMYzE2dWVrV3dkckRUVlNoRS84Lys1K3VMTWtIdVJt?= =?utf-8?B?Q2dyVUlCcnNRU2JDMElUVmpVNngybjRCQktidHBiZmtpWXRabXp2NmVlcDk4?= =?utf-8?B?THlIZ3JDcVg5R1dPQmRKMU8wL3pOOVJLcDJYRjdja1VLYS9Ka0w1N0RnNlBr?= =?utf-8?B?MEZVVW9TYWJkdTk1b3JvajJMUWZxSlMvVG9uaDhuYzhITVorVHY1cVlSTVcv?= =?utf-8?B?SkxSQXRkczBVdDRaVFFxL0t3aVRyc1hrVE15a2hXYmxsRWNzRDNNZjBTc2Rj?= =?utf-8?B?d2VLcytsNFlXbk9rSG5CaG9jVlRRc1VkZ0VHVTJnNDB2Q2JVanN5WkFYQW1V?= =?utf-8?B?NXR0MWt6NFNMZXU3MUxKWVYrZEZRcVREeWRSWU41VzFhT01OSFBkYTlPK1FU?= =?utf-8?B?K0xuMGhPQkJpb3RSNGR4alFZeWZxeVYrREFHUXAzSCsyeGh0NUQyc25YSVZX?= =?utf-8?B?VHkrdXo1VWdYbXRTbTVaeUIwNzE3SFRTRTBYV1doaWlpSTFLbW83OTRRQlo4?= =?utf-8?B?djNld0lTSjBEb083bnpUSkJCb3Zmd2E5RVhXc3R6Y0EzdmEvWGpuMWQ1U0NB?= =?utf-8?B?dEdXbXRzRUhaWXFMTUo1KzRBR0ZsRXlXKzRxZklpeXQ5S0hTSStNUTN4TFg1?= =?utf-8?B?Vld4ZENUdEQ0MTNBay9xbFZ2Rm1iZkRnSmxiRi8vRFdKWUorQkZLNGdwVGRu?= =?utf-8?B?Z0wxYWpFZkFYNG43b1dTelowcUdxaTM0MG5PVHRiRzMzT1RmclhNM2hZbDF5?= =?utf-8?B?R3JPUndSaEdKb1dkVDNkQ3lla1B4UER1NlcvQkVPdFFTVzNiSlphNTVQV2ht?= =?utf-8?B?UFNQZDE2T01XM01mRnZ3TkZ6K1Q2aVhLRWVUWWhuWE1vMjBoSU9lTXJzaXd5?= =?utf-8?B?UEs1OWNEVVhvclE4eHRCcFJJeGVlb1JrM0drcWlhVmc0UmZnWS9MdmRjVFFu?= =?utf-8?B?c0xWcURHK0gwSkVIazF1Y0Y0MEF3ckg1bktPSVRGblBSdXgwTVVjYkdWdnU1?= =?utf-8?B?WjVHMWFJM0F1WUlNcnlRalp3U1lvMVBhaU54a1FibDBTanRCSkR4WHlQSnhQ?= =?utf-8?B?dGZmeEhtaDhEVnB0QU5wL0ZhRmJxa2FOcXhBVHZvR2lWOUpVSFF1TEFoaUdr?= =?utf-8?B?TVl1TStyZmF3OGFSbmMvM1RhcTZ2RHZ2eWUvSmxiN3MvVVFxVTBGZ3RvOEpT?= =?utf-8?B?WUpGSkZ1WXhDZnFNc1JyTTBjSHJlTWtCYlVoMnhXMFd5QUVSWDQ2SC9nUWJ5?= =?utf-8?B?SUNtclcrekMwMWJBYUlMcHZFUE1xMmwvTjNRZHQwd0ZBNFdaanVWTDJzOXZP?= =?utf-8?B?R0ltTWFSdnBSRGlSR3hoazVRaHNNSmp4eFdsZHdhMlc4aGZkSGdHbVZaL3h3?= =?utf-8?Q?05HkjsvdifJWkPMg=3D?= X-Exchange-RoutingPolicyChecked: yg8R1DXX9MTVvTOYxmm/AEo0TzDu1VjFGWKWSpdgwZ3nqYgB+TrLs1zHXd0KLpZeXHE9CuXqC/Ai81y65nEzwC07kFK5kNuPxGqxKlRcOIB/JkQisjkz11lXJvQE802lQV0pfKY1VyYVxQrehRZjWgr78JlNYNJtEU25XG9OTuX2SB8Km1PsPZJr/ig9be9yQhqYek1dDEaQCZxo/gP+G9dA0XOcfh3uLXNoWGO+8gSUf/niMisu+sPUiwmNaA8ljecxdI0bWLuz6DRCAtD8lGqryQWpfK90S9IslHO+dXiDoA+zc555tqh02n+2qT+PIgV80X/6wJ8TowiycuaIFA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48dd3b05-83e2-497d-f078-08df2b8d6e2a X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 13:57:35.1287 (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: bAlio+hyug2SBUox72XezNaWf1+edFSp2sjKPEN4Kh6Y+LP1dMz5VtncQoZgn1rmgwtUb0aZ5zIBoMdToDVOOA6atyNx9BdJ39HMkUljiLA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB8836 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NSBTYWx0ZWRfX9vCOPGsVYIG6 MVR5x+2+VHW1wnScfIaUjUK7Zo1dVxQJQqLOPwHDOqx32/QdqNpImeTr0qr/cebbHEi7XnaPbMH HvlVmIOPI5XXFbi+8k06LkdPXYD1JA8= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NSBTYWx0ZWRfXwMuhjlDa9OmQ jBnW3YRs1o9Y2/nwetNglb9RFJ8qXoy6Lu7/6dtNmZFBkSJXog5i7X5fB8/nYY4FIhOzucDiKxF Mb2U8ADRIBx6W6B46cMG0l+Awa6537efIAKIBpqMyGCvw/u6XfCx8ZOdpMqJcjp1ySSeuTdHh+p u692G2ZeZyBHjRd6TxlLLz1uz16BiaUWtiIH6alaTIS82BJXeVHqLzbTcBMMb5ZZgjFyHvLX4M4 zyNzya4B+wLLkBBhv5Vj6+D1sT3AHR1n5kGOKx5UqktzRrfTew1rJTIKcVFvzqoL+/6AmVjuJY0 PIBQyFnGmeZziesBWWvv4+8UlQk0TpIjRrhH+ZLDUsmYv/p4Kv3nvLhaNhv9WERJPXXGJE9yN6l HFHPx8W7YOI600hP2qwOCyH/fEp4fvrUxU+QoaPSbvHh4QS4adc+vaku18oKu91T19fGPKX3pJI kKX3+zX2vQFawpEDD9w== X-Proofpoint-ORIG-GUID: 05mp9M7gvJ5PIVviIXvo3bxQESBWuDLa X-Authority-Analysis: v=2.4 cv=ItOL47/g c=1 sm=1 tr=0 ts=6ad22d50 cx=c_pps a=RH0axx9bUT6qb0hBLGrbHA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=YTpg2wbwm77mjifCQ_kA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: 05mp9M7gvJ5PIVviIXvo3bxQESBWuDLa 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-10-16_01,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-720697/1792159062-317CA2AC-E0445E73/0/0 X-purgate-type: clean X-purgate-size: 1889 On 13/10/2026 17:29, Peter Maydell wrote: > On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland > wrote: >> >> 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 > >> 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]; >> }; > > >> 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 >> }; > > Would it make sense for these two types to have a common base > class (where the stats stuff could then live)? AIUI they're > both intending to provide the same interface ("pair of i8259 > devices cascaded together in the way that x86 does it"). I had a go at this, however it didn't really make sense since the fields shared were minimal and the complexity of introducing another class into the hierarchy didn't seem like a win in this case. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:11:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:11:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451950.1666775 (Exim 4.92) (envelope-from ) id 1xHie8-0005cS-Ea; Fri, 16 Oct 2026 14:10:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451950.1666775; Fri, 16 Oct 2026 14: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 1xHie8-0005cL-Bk; Fri, 16 Oct 2026 14:10:56 +0000 Received: by outflank-mailman (input) for mailman id 1451950; Fri, 16 Oct 2026 14:10:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHie7-0005cD-EZ for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:10:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHie6-00BV07-KF for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:10:54 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2306a-2eae-0a2a0a5409dd-0a2a450cb6a2-14 for ; Fri, 16 Oct 2026 16:10: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 6ad2306e-f479-0a2a450c0019-b9ff1c23b6ef-3 for ; Fri, 16 Oct 2026 16:10: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 1a1450d15800008425.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 14:10:47 +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 F3D9D82A40; Fri, 16 Oct 2026 16:10: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=gBJkUV5ho5fw9C9x3CT9PH8UUlBJRTOg9GkKx559eHg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=WWRszufgCW90dF9wiQ1k16j0A3/3zzq+6OUs6dEAVEUwdXinf9dx5xzkTLvbCzQF1aZ+c1AOL IR26Mb3VaBDXq9/3i5UXupVy7DCPSVcuBJQpSy8ibi1uFGA/OfJNasb/njFwi0fc9TiBF+vwXhU S8MvBXF0VTHdDyplDEI11FfsIuKdgNXd0B6iMJkbQ+T+JVsYGTvW1RO+owIZ73GdSJM+hgeSzPV AcJUWKxxhJcpMtgz8+kYTEfzTC0FLLVT5S1sfliNEDjyEyu9sKNXsTsQF/U3j+v+rSSBzl8/2Ro /pxgzVdke38xFkpXXn0+KJuTH3iR6b1mezV440//U+zA== X-Zone-Loop: 49a95dfafa89930a156dac35b721b9f51e5c611e6039 x-campaign-type: default x-transaction-id: cfabd6ee-908c-4149-b5e5-7751808589e7 x-swg-uid: 01-cb491713-d56f-456b-bb9a-05c47928850a X-Mailer: Sweego Message-ID: <1792159847.8631fc262581453bbf619ec5b2062170.1a1450d15800008425@vates.tech> x-swg-bid: 1792159847.8631fc262581453bbf619ec5b2062170.1a1450d15800008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 16 Oct 2026 16:10:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Use VCPUOP_register_{runstate,vcpu_time}_phys_area when available To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , George Dunlap , x86@kernel.org, linux-kernel@vger.kernel.org References: <1792146192.8631fc262581453bbf619ec5b2062170.1a1443cb7e90008425@vates.tech> <9a8b0ae0-ec49-4af0-8e5d-1378319f2857@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: <9a8b0ae0-ec49-4af0-8e5d-1378319f2857@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------kvPZisEqGAMPA1eCbW4lX2b8" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792159847216 X-purgate-ID: tlsNG-d25034/1792159854-766DEA5B-F55037F8/0/0 X-purgate-type: clean X-purgate-size: 11536 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------kvPZisEqGAMPA1eCbW4lX2b8 Content-Type: multipart/mixed; boundary="------------zmNGkw5uthoDjqekfFGWrB6s"; protected-headers="v1"; hp="clear" Message-ID: <9ccd658a-e483-4b99-98c2-d90a30cf955c@vates.tech> Date: Fri, 16 Oct 2026 16:10:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Use VCPUOP_register_{runstate,vcpu_time}_phys_area when available To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , George Dunlap , x86@kernel.org, linux-kernel@vger.kernel.org References: <1792146192.8631fc262581453bbf619ec5b2062170.1a1443cb7e90008425@vates.tech> <9a8b0ae0-ec49-4af0-8e5d-1378319f2857@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: <9a8b0ae0-ec49-4af0-8e5d-1378319f2857@citrix.com> --------------zmNGkw5uthoDjqekfFGWrB6s Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTYvMTAvMjAyNiDDoCAxMzoyMCwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBP biAxNi8xMC8yMDI2IDExOjIyIGFtLCBUZWRkeSBBc3RpZSB3cm90ZToNCj4+IFVwZGF0aW5n IHRoZXNlIGFyZWEgY2FuIGJlIGV4cGVuc2l2ZSB3aGVuIGRvbmUgdGhyb3VnaCB2aXJ0dWFs IGFkZHJlc3Nlcw0KPj4gKGVzcGVjaWFsbHkgZm9yIHJ1bnN0YXRlIG9uZSksIGluIHBhcnRp Y3VsYXIgZm9yIEhWTS9QVkggZ3Vlc3RzLg0KPj4gWGVuIDQuMTggaW50cm9kdWNlZCBwaHlz aWNhbCBhZGRyZXNzIGFsdGVybmF0aXZlcyB0byBhZGRyZXNzIHRob3NlDQo+PiBzaG9ydC1j b21taW5ncywgYnV0IHRoZXkgYXJlbid0IHVzZWQgY3VycmVudGx5Lg0KPj4NCj4+IEZpeCBp dCBieSB1c2luZyB0aGVzZSBhbHRlcm5hdGl2ZXMgd2hlbiBhdmFpbGFibGUgKHdoZW4gcmVw b3J0ZWQgaW4NCj4+IFhFTkZFQVRfe3J1bnN0YXRlLHZjcHVfdGltZX1fcGh5c19hcmVhLCBi dXQga2VlcCB0aGUgY3VycmVudCBsb2dpYw0KPj4gaW4gdGhlIFBWIGNhc2UuDQo+Pg0KPj4g QXNzaXN0ZWQtYnk6IExMTQ0KPj4gW2d1aWRhbmNlIGFuZCB0ZXN0aW5nXQ0KPj4gU2lnbmVk LW9mZi1ieTogVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+DQo+PiAtLS0N Cj4+IFdoZW4gdXNpbmcgcGh5c19hcmVhIEFCSSwgdGhlIHN0cnVjdCBpcyBub3QgYWxsb3dl ZCB0byBjcm9zcyBhIHBhZ2UNCj4+IGJvdW5kYXJ5IGFueW1vcmUsIGhlbmNlIHdlIG5lZWQg dG8gYmUgY2FyZWZ1bCB3aXRoIHBlci1jcHUgc3RydWN0DQo+PiBhbGlnbm1lbnQuDQo+Pg0K Pj4gSSd2ZSBkZWxpYmVyYXRlbHkgcHV0IHRoZSBQViBkb21haW4gKCFYRU5GRUFUX2F1dG9f dHJhbnNsYXRlZF9waHlzbWFwKQ0KPj4gY2FzZSBhc2lkZSBhcyBpdCBwcm9maXRzIGxlc3Mg ZnJvbSB0aGUgcGh5c2ljYWwgYWRkcmVzcyBBQkksIGFuZCBpdA0KPj4gd291bGQgbWFrZSB0 aGluZ3MgbW9yZSBjb21wbGljYXRlZCBhcyAicGh5c2ljYWwgYWRkcmVzcyIgZG9lc24ndCBo YXZlDQo+PiBhIG9idmlvdXMgbWVhbmluZyB0aGVyZS4NCj4gDQo+IEl0IHNob3VsZCBhbHdh eXMgaGF2ZSBiZWVuIGEgZ3Vlc3QgcGh5c2ljYWwgcmVnaXN0cmF0aW9uLCBldmVuIGZvciBQ Vg0KPiBndWVzdHMuDQo+IA0KPiBUaGUgdmlydHVhbCBhZGRyZXNzIHJlZ2lzdGVyZWQgd2l0 aCBYZW4gZG9lc24ndCBleGlzdCBpbiB0aGUgdXNlcg0KPiBwYWdldGFibGVzLCBhbmQgdGhl IHdheSB3ZSBkaXNjb3ZlciB0aGF0IGlzIHRha2luZyBhIHBhZ2VmYXVsdCBpbiBYZW4gYXQN Cj4gdGhlIHBvaW50IHdlIG5lZWQgdG8gdXBkYXRlIHRoaW5ncy4NCj4gDQoNCkkgd2Fzbid0 IGF3YXJlIG9mIHRoYXQgc3BlY2lmaWMgY2FzZS4gV2lsbCB0cnkgdG8gbWFrZSB0aGUgY29k ZSANCmNvbXBhdGlibGUgd2l0aCBQViBndWVzdHMuDQoNCj4+IGRpZmYgLS1naXQgYS9hcmNo L3g4Ni94ZW4vdGltZS5jIGIvYXJjaC94ODYveGVuL3RpbWUuYw0KPj4gaW5kZXggNWM3ODIy MjU0YTAxLi4xOWFjZTFiNzhhZTQgMTAwNjQ0DQo+PiAtLS0gYS9hcmNoL3g4Ni94ZW4vdGlt ZS5jDQo+PiArKysgYi9hcmNoL3g4Ni94ZW4vdGltZS5jDQo+PiBAQCAtMzcsNiArMzcsMjIg QEANCj4+ICAgDQo+PiAgIHN0YXRpYyB1NjQgeGVuX3NjaGVkX2Nsb2NrX29mZnNldCBfX3Jl YWRfbW9zdGx5Ow0KPj4gICANCj4+ICtzdGF0aWMgaW50IHhlbl9yZWdpc3Rlcl90aW1lX2Fy ZWEoc3RydWN0IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnB2dGkpDQo+IA0KPiBUaGlzIG5l ZWRzIGEgY29tbWVudCBleHBsYWluaW5nIHdoYXQncyBnb2luZyBvbiAoYnkgR1BBLCBmYWxs aW5nIGJhY2sgdG8NCj4gVkEpLCBpbmNsdWRpbmcgdGhhdCBwYXNzaW5nIE5VTEwgbWVhbnMg dW5yZWdpc3Rlci4NCj4gDQoNCldpbGwgYWRkLCBJIGd1ZXNzIHdlIGFsc28gd2FudCB0byBt ZW50aW9uIHRoYXQgdGhpcyBkb2VzIHN0dWZmIG9uIHZDUFUgMC4NCg0KPj4gK3sNCj4+ICsJ c3RydWN0IHZjcHVfcmVnaXN0ZXJfdGltZV9tZW1vcnlfYXJlYSB0Ow0KPj4gKwlib29sIHBo eXMgPSB4ZW5fZmVhdHVyZShYRU5GRUFUX3ZjcHVfdGltZV9waHlzX2FyZWEpICYmDQo+PiAr CQkgICAgeGVuX2ZlYXR1cmUoWEVORkVBVF9hdXRvX3RyYW5zbGF0ZWRfcGh5c21hcCk7DQo+ IA0KPiBOb3QgcmVsYXRlZCB0byB5b3VyIHBhdGNoLCBidXQgdGhlIHhlbl9mZWF0dXJlKCkg aW5mcmFzdHJ1Y3R1cmUgaXMgaWRpb3RpYy4NCj4gDQo+IEl0IHRha2VzIGEgYml0bWFwIGZy b20gWGVuLCBhbmQgdHJhbnNmb3JtcyBpdCBpbnRvIGEgdTggYXJyYXkgb2YgMSdzIG9yIDAn cy4NCj4gDQo+IEl0IHdhbnRzIHN0b3JpbmcgYXMgYSBwcm9wZXIgTGludXggYml0bWFwLCB3 aXRoIHhlbl9mZWF0dXJlKCkgYmVpbmcgYQ0KPiB0cml2aWFsIHdyYXBwZXIgYXJvdW5kIHRl c3RfYml0KCksIGF0IHdoaWNoIHBvaW50IHRoZSBjb21waWxlciB3aWxsIGFibGUNCj4gdG8g Y29sbGFwc2UgZXhwcmVzc2lvbnMgc3VjaCBhcyB0aGUgb25lIGFib3ZlIGludG8gYSBzaW5n bGUgb3BlcmF0aW9uLg0KPiAoZXhjZXB0LCB5b3UgbmVlZCB0byByZW1vdmUgdGhlIFhFTkZF QVRfYXV0b190cmFuc2xhdGVkX3BoeXNtYXAgYXNwZWN0DQo+IHRvIGluY2x1ZGUgUFYgZ3Vl c3RzLikNCj4gDQoNCkxvb2tzIGdvb2QgdG8gbWUuDQoNCj4+ICsJaW50IG9wID0gcGh5cyA/ IFZDUFVPUF9yZWdpc3Rlcl92Y3B1X3RpbWVfcGh5c19hcmVhDQo+PiArCQkgICAgICA6IFZD UFVPUF9yZWdpc3Rlcl92Y3B1X3RpbWVfbWVtb3J5X2FyZWE7DQo+PiArDQo+PiArCWlmIChw aHlzKQ0KPj4gKwkJdC5hZGRyLnAgPSBwdnRpID8gdmlydF90b19waHlzKHB2dGkpIDogfjBM TFU7DQo+PiArCWVsc2UNCj4+ICsJCXQuYWRkci52ID0gcHZ0aTsNCj4+ICsNCj4+ICsJcmV0 dXJuIEhZUEVSVklTT1JfdmNwdV9vcChvcCwgMCwgJnQpOw0KPj4gK30NCj4+ICsNCj4+ICAg LyogR2V0IHRoZSBUU0Mgc3BlZWQgZnJvbSBYZW4gKi8NCj4+ICAgc3RhdGljIHVuc2lnbmVk IGxvbmcgeGVuX3RzY19raHoodm9pZCkNCj4+ICAgew0KPj4gQEAgLTM5NSw3ICs0MTEsNiBA QCBzdGF0aWMgdTY0IHhlbl9jbG9ja192YWx1ZV9zYXZlZDsNCj4+ICAgDQo+PiAgIHZvaWQg eGVuX3NhdmVfdGltZV9tZW1vcnlfYXJlYSh2b2lkKQ0KPj4gICB7DQo+PiAtCXN0cnVjdCB2 Y3B1X3JlZ2lzdGVyX3RpbWVfbWVtb3J5X2FyZWEgdDsNCj4+ICAgCWludCByZXQ7DQo+PiAg IA0KPj4gICAJeGVuX2Nsb2NrX3ZhbHVlX3NhdmVkID0geGVuX2Nsb2Nrc291cmNlX3JlYWQo KSAtIHhlbl9zY2hlZF9jbG9ja19vZmZzZXQ7DQo+PiBAQCAtNDAzLDkgKzQxOCw3IEBAIHZv aWQgeGVuX3NhdmVfdGltZV9tZW1vcnlfYXJlYSh2b2lkKQ0KPj4gICAJaWYgKCF4ZW5fY2xv Y2spDQo+PiAgIAkJcmV0dXJuOw0KPj4gICANCj4+IC0JdC5hZGRyLnYgPSBOVUxMOw0KPj4g LQ0KPj4gLQlyZXQgPSBIWVBFUlZJU09SX3ZjcHVfb3AoVkNQVU9QX3JlZ2lzdGVyX3ZjcHVf dGltZV9tZW1vcnlfYXJlYSwgMCwgJnQpOw0KPj4gKwlyZXQgPSB4ZW5fcmVnaXN0ZXJfdGlt ZV9hcmVhKE5VTEwpOw0KPj4gICAJaWYgKHJldCAhPSAwKQ0KPj4gICAJCXByX25vdGljZSgi Q2Fubm90IHNhdmUgc2Vjb25kYXJ5IHZjcHVfdGltZV9pbmZvIChlcnIgJWQpIiwNCj4+ICAg CQkJICByZXQpOw0KPiANCj4gSG93IGRvZXMgdGhpcyB3b3JrP8KgIEFuc3dlciBpcyBpdCBk b2Vzbid0LCBiZWNhdXNlIHRoZSBwcmludCBtZXNzYWdlIGlzDQo+IGJvZ3VzLsKgIFRoaXMg aXMgYSBmYWlsdXJlIHRvIHVucmVnaXN0ZXIgdGhlIHRpbWUgYXJlYSwgbm90IGEgZmFpbHVy ZSB0bw0KPiBzYXZlIHRoZSB0aW1lIHZhbHVlLg0KPiANCj4gQXQgbGVzdCB0aGUgZXJyb3Ig bWVzc2FnZSB3YW50cyBmaXhpbmcsIGFuZCBpbiBhIHByZXAgcGF0Y2guDQo+IA0KDQpZZXMu DQoNCj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi90aW1lLmMgYi9kcml2ZXJzL3hlbi90 aW1lLmMNCj4+IGluZGV4IGEyYmUwYTRkNDViMC4uNmI2ZGRjN2E1ODIyIDEwMDY0NA0KPj4g LS0tIGEvZHJpdmVycy94ZW4vdGltZS5jDQo+PiArKysgYi9kcml2ZXJzL3hlbi90aW1lLmMN Cj4+IEBAIC0xNTIsMTEgKzE1NiwyMSBAQCB1NjQgeGVuX3N0ZWFsX2Nsb2NrKGludCBjcHUp DQo+PiAgIHZvaWQgeGVuX3NldHVwX3J1bnN0YXRlX2luZm8oaW50IGNwdSkNCj4+ICAgew0K Pj4gICAJc3RydWN0IHZjcHVfcmVnaXN0ZXJfcnVuc3RhdGVfbWVtb3J5X2FyZWEgYXJlYTsN Cj4+ICsJdW5zaWduZWQgaW50IG9wOw0KPj4gICANCj4+IC0JYXJlYS5hZGRyLnYgPSAmcGVy X2NwdSh4ZW5fcnVuc3RhdGUsIGNwdSk7DQo+PiArCWlmICh4ZW5fZmVhdHVyZShYRU5GRUFU X3J1bnN0YXRlX3BoeXNfYXJlYSkgJiYNCj4+ICsJICAgIHhlbl9mZWF0dXJlKFhFTkZFQVRf YXV0b190cmFuc2xhdGVkX3BoeXNtYXApKQ0KPiANCj4gQWdhaW4sIFBWIGd1ZXN0cyB3YW50 IHRvIHVzZSBwaHlzIHdoZW4gYXZhaWxhYmxlLg0KPiANCj4+ICsJew0KPj4gKwkJb3AgPSBW Q1BVT1BfcmVnaXN0ZXJfcnVuc3RhdGVfcGh5c19hcmVhOw0KPj4gKwkJYXJlYS5hZGRyLnAg PSBwZXJfY3B1X3B0cl90b19waHlzKCZwZXJfY3B1KHhlbl9ydW5zdGF0ZSwgY3B1KSk7DQo+ PiArCX0NCj4+ICsJZWxzZQ0KPj4gKwl7DQo+PiArCQlvcCA9IFZDUFVPUF9yZWdpc3Rlcl9y dW5zdGF0ZV9tZW1vcnlfYXJlYTsNCj4+ICsJCWFyZWEuYWRkci52ID0gJnBlcl9jcHUoeGVu X3J1bnN0YXRlLCBjcHUpOw0KPiANCj4gSSdkIHN1Z2dlc3QgZmFjdG9yaW5nIG91dCB0aGUg JnBlcl9jcHUoeGVuX3J1bnN0YXRlLCBjcHUpIGNhbGN1bGF0aW9uLg0KPiBJdCdzIG5vdCBm cmVlLCBhbmQgY2FuJ3QgYmUgaG9pc3RlZCBieSB0aGUgY29tcGlsZXIuDQo+IA0KDQpEb25l IGxvY2FsbHkgZm9yIGJvdGguDQoNCj4gfkFuZHJldw0KDQpUZWRkeQ0K --------------zmNGkw5uthoDjqekfFGWrB6s-- --------------kvPZisEqGAMPA1eCbW4lX2b8 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+p0QLLz9AFAmrSMGYFAwAAAAAACgkQZg+p0QLLz9B6 Tgv+Owt7ffCxc/SWUjpf1eCga0IvVSkdu2/BBvXBYuul285DMg1u0pasZXnG+rausaMgnqCNGEsZ zTRFi5FkxD8nCalUXcSQ1kOp68BnOemCG11SuEffyVSPXNuBgbCcVjAGpJUymtG/n0jqto38MLWZ 5ulyKN7yWOSg5KdKvesXuAjGRzYmDS+YtF1NM91OFBAtpWLmD6IMov3DxScQtvNpIzbu+sR+dV7m kEkueC3U5VNs4vSCmQRJsb2mTZAm/uNAF70lHJczCVt+lA3m5WuC+/Tz3Jsjepbhv7dRIFQoePsS P5R9O8qOJvRSJhdmoTYPcrw3Eq/xSImoSAV1AqScWzeRqN9+3gdHdvg4TBzzwi3HjRI1KP0InbR0 8U+50pP3Lxbu8KngDWyd3bChWjxH6hppposyCgm5cA6X3WQpdwmUYP01/6SwG9OQS87HnG7uCObi t5ZAXZO4rAFNrJuQ16IZo0URJVplChVRnVtr+klEyZXwhvE2IthFIpHp2Zjy =VbRu -----END PGP SIGNATURE----- --------------kvPZisEqGAMPA1eCbW4lX2b8-- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:20:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:20:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451965.1666786 (Exim 4.92) (envelope-from ) id 1xHinf-0007w0-Eq; Fri, 16 Oct 2026 14:20:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451965.1666786; Fri, 16 Oct 2026 14: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 1xHinf-0007vs-9P; Fri, 16 Oct 2026 14:20:47 +0000 Received: by outflank-mailman (input) for mailman id 1451965; Fri, 16 Oct 2026 14:20:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHind-0007v1-6U for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:20:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHinc-008o8I-Cu for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:20:44 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232b2-8faa-0a2a0a5109dd-0a2a450bb1b8-32 for ; Fri, 16 Oct 2026 16:20:44 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad232ba-b7e8-0a2a450b0019-94a39b0c7af2-3 for ; Fri, 16 Oct 2026 16:20:43 +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 69GE5Db03215898; Fri, 16 Oct 2026 07:20:38 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020096.outbound.protection.outlook.com [52.101.85.96]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb045k1j9-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:20:37 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:20:35 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:20: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=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=1pCF8b60VVnDX 4UsfNMHUrQaLNz4cgQKXgiVFlnlh6c=; b=ioOLe4HZO0qzSmY4lZ++DUzeKX9ij hAb7cpn/5o8Oksyd0EvSyMwiM0AkcYTx8CV5diL6PdGWmuXA7YHa4Pdt0nWFShZK w2Z1oVBN+cjCj2mvh+WdmthF3j3kS2ImH99Tjv5Zz6GGj3SLfaoFVTyRNA1D7y03 QSxB9+WsFwZkKryCdRrvlMfuaY12JVq9DWx+JdqRtxDN2F4sKQQ5X+nc/TYmyp6h jOcxjHuhTDOteVfEl65hn3kgTiN5RGbG7ss5CNPkOmUBQggdr9gsX+hAkuDkggU5 gkhGNI71TpxcwtNcs2WoYJVRLThjlbLkjrOmBOtz2GGhq++MNHLAeiBxQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MCpvnW9rJNhZuOv30/7cJrGI0GuS8SohcuJAwsuDzFeObkN+xgfMXFS7ao6JWBrJ9DLOFx7XLVufXktcNQ7ja75jdZ6GTgw8LcmvdHMtkr+nKToMQKvVvLZ/OEEpyDibO/bLAqhP06mWxOdTJiMhLsroROOM+uxHVf/kPPgde/uwJcl8gW4JPF/5NV2xEgAjem6EMPTUbCahqp8eTeZX53vCgPYWd3CISLVh7ouoexAzwfNSQo3zWNLppBR4VN90w3zrwTRMbMXAhHuL8SQz21knmHk4OWADEu4550mLO2RB39G/hKODko5gd/PxpGxJ23Up3faK2bx5NSagWqJmcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1pCF8b60VVnDX4UsfNMHUrQaLNz4cgQKXgiVFlnlh6c=; b=drmYt43kC2pqlPepvJxSdkSnOxAUBIswyoSc5OD3BOa13g10oT5MLRoYHhH6OMFYDF23NuTke3bxEM9HqlNDKAgR3GWJ0HpTQItDdAY68FS61T2Chv3vbbUMzdyfhsx8uzEccuMfEOomMYixa/TxWNOcihefCKY8P+zlrcQy96v38lpTIN8rzkYfKfQIiiauLGPaivaD6+5nxo+BrVB02Nx/hm7RkdDAiKhepuamsShQvDcrX00ClQ4vvghzM1jf+rHUmHUgnGkr3GOQLLGzF+lo4NRMoHl/7s59qg0kyVWMWBa3SQcjjJ7B2O/v7D60vmzSysQ/6//OWTsuC7jd9Q== 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=1pCF8b60VVnDX4UsfNMHUrQaLNz4cgQKXgiVFlnlh6c=; b=XLG/okVCsgIX/asgSU5gQcl+vu3hq5LRxnQPa9CluZV5rP0rVow1gn2q9hVwfCWwEy/+6fV0gESXyS9wKxbuKY+vWYf1iN/0Wip2ndWRvEYA4bpwBuakp2+DwRJj15TiL0x/R8TVSz8CHqzHyvBWLRc/uE9lZxLmGqQRYCh6mGCfavHjuMvWjWv/y/axLxLQjTbRpbMFSk7cfrpJSpoIkApNhih973xjdRtO5HMtp2IkGNjUodAQwoR3fA224I/ieCHboKUdYcmFYpKOFHCjFtKnmljUWuldCfkNhk5jt6R+lVv6UodaG5xrlf+FjZZW4UFiS37q9DDBT8xe4Mg5fA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 00/27] i8259: improve qdev PIC modelling (and misc fixes) Date: Fri, 16 Oct 2026 15:19:06 +0100 Message-ID: <20261016142031.1204281-1-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0123.namprd13.prod.outlook.com (2603:10b6:a03:2c6::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_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 6cd89d2b-81c4-4105-0914-08df2b90a51b x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|6133799003|10067099003|3023799007|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: Gwt/yyR9Xn1Q6F39Rcwsq7FBonFdvI9/5+DTf53S+UzHBMnhxKDPJOhcGpZ50jbrcVYvau/h28rPkGFUmTvjop+3VHfx9fkIchNNIEeI79/KyniGUHrRpeNREIyaaN1m3PrApZg+74sMWMgATafrO+9UGicgUTW6HiS9qpKDYk2YcxcpUK3hvaXuC2UECpak1D6EQ6UImS8K0DI85Q1URcAhMRFmV2Hs1cyXgke/+4GKcb8Qy2Im9H51hUEuqwtsAwetI2smxivT+Y3SuQAqeQmji2Uwovfh2GezgOBabFoX/shLhU6MKNGNv2XG8k6O0TBnnfi4mya+NSj4EKlZ3DR52Bzvf7+8OJMijUEKsaardq3leCV9C6xauKX9cfRrPUvSJkndhrfl9jHV0KHdiZe2CLSIcet/2WAl4vaU72NpmiooSF09Mr+dXBE00SKN4QMnD5WtN1spNTR6q9SXtTl5HGcGj/fRAP2Melz/HdZ/+reYOCokOPzxiscYnlCbectN9w+IJsBx0P/Stluixs1e7nEiFzMSlKagSKfcm0CDqV+bDIT5G4C1gEJHz/TgkYKiokCYWbgWr+/vLS7yrbuRwKb0kMzDvYqahWR/+EtgczMKVpSJv46ffQYIR4jvvB5duIzOvRt/Qjl4h5UbDIhiSuYbJSwnu3juVg3sJzM= 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)(23010399003)(376014)(1800799024)(366016)(6133799003)(10067099003)(3023799007)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HMgbf31ucWeHhb1IcOQlsT4MLPIU17IYW0zOlmIqKLdCrTo8LSrb/b3xERxK?= =?us-ascii?Q?1y4FMSUll+n5PlD/P1XnNRSTcI1HqDVVNAK+wQ6IUCJpsb4yqPZRkhirPoDI?= =?us-ascii?Q?IKIRNU1JgsjzOWPHUDdIR/vlzxqNADMtM6vw7FZYE8dBS/f3J4Be8ryWglI5?= =?us-ascii?Q?e27NsYn0vESxw7H8vcl2odwOjKak85027NgWyor/ES8+L4Tu+jlN1H3yLQSm?= =?us-ascii?Q?OncMsV+0nDqj4JHID9791NcL1NoeNkRnCKa4LBK/wIkA7dhwJ6Wsaxfu4oDa?= =?us-ascii?Q?rgvSgetGA1sRGaTwVxRoGD5qv19CfM0woVM66YoF3v2HeUZlDA3Eb3yRAucy?= =?us-ascii?Q?Ao6HmC4+tRqqs8HoJixy+EZ+l+FyAEhRfzFcQ2Z/D0bp8y5gYKEa7RuGqVfp?= =?us-ascii?Q?QKfNP4irlc6PGGK833btX8MrcGpcSOS3puKfnUtEOxl6OZG6QjlfVAzOqhK7?= =?us-ascii?Q?RoCl87R3WdGbsGQehj2uldLDDOKeAsflvmLSkVSASp3JtiOweANi3ECfiNGl?= =?us-ascii?Q?DFCguAXT0TgsIuvqZxQPh280RmxxaW54qyuh3DopM9rMWVKr8T6GFGZ4YCYg?= =?us-ascii?Q?lKJW557W68a7G0iDQtv83ZVpEOJPVJlkLZf8uajRJo35o2ffodswrSt2poqI?= =?us-ascii?Q?KGBnmZwXGzxXIjiGu0xU+Ub2YDMs+jyzh4xxgRgezzQ1joOlW18DjrrY7QIA?= =?us-ascii?Q?VyisteF7ldGWo8UxyKUsNV7Fjk5Fu6R/Z16K76fVdjqtjFuwefKgzJy6AgY3?= =?us-ascii?Q?u+geh6Ov+WH3tKIoUHtw0XPtz29ArAREIoU6i8j58yxuUJo3IGJ+ea22vsVX?= =?us-ascii?Q?9aHbQPE6jHuaRHJ25UQxEHLOM7tVLqXzwGtaEF5dB6Lvj2uuFMQLWpHW+WOV?= =?us-ascii?Q?Pc+Wn5g42zjbqKi5yEK/q/QnKJ58HDjun8aJr4EufTe0qbIn3Nw2z+U/GI2U?= =?us-ascii?Q?U6QBFAW9l+mlFUjjT+sEk+5CKFyNpWiGXeel0oS1VtoJJN7u7rcfnbPcGNje?= =?us-ascii?Q?NOBHiQEszGkR0LD4Cy2QErpf7yV7gakqe36hpLHu3HrprkYUsseIP38KI7H4?= =?us-ascii?Q?DiAMwIVgcXfE8WbReAz5MI4OdjqxK/OBKqY7ssDG3VqCoBBdmIEV6zVzuXYY?= =?us-ascii?Q?39HBfL/4sJ0SIS+ZlTcuE2+6ueeIiCEUAe1ZzeS45ZOyQPvAcxCFFBaK5r4D?= =?us-ascii?Q?avd/3q+ZVCb/btARSXZAQhXV0CXeVPvJSiu1EwR0Qaa2VO0OcREaJWgIJjlN?= =?us-ascii?Q?xQT6CLi7o8HeQh9i1S05RCNmTqhsyexH99BM3cRnAS7TLDAqdgo8wirUEMGU?= =?us-ascii?Q?xRY3zIc6aF+y0QCpHF7eY9xraB7NC2Is6z2pcmMe1oCyGMCEdC5NJGjO2dvK?= =?us-ascii?Q?WFlrHYPsAYqbOcO7Q2HyZIFJkYF4Rvf0Tjj2KTgHxFl7YJrFaAc57ef15I/7?= =?us-ascii?Q?kifDpOpY34ZRP19wyD7KhjrZrkdquvyVSCMbgIdz3/2w5UEpEkGP0MbR5Hi8?= =?us-ascii?Q?wv+C5z5Nj5L8nu/QqBZhcj7rah4fSAwyKfh2kAVhiMP1dYcEon9Uo/2SoK5z?= =?us-ascii?Q?awJHY2Jc22e4BNw9g5pKQlEemdiVoF7iCcD6552Osr9LqraHjWxloTIQjEn0?= =?us-ascii?Q?lnQRq/eK1SUMRGtKC4I94b8EUovjmgnxi0l7PEVHFa1s+Ner/Zfnxx6znIP5?= =?us-ascii?Q?g3dsd53mjQZshzSMElzj7fcw/dPiLWsG5gYYsKfOAZbu9imwDjHvajbM2fi7?= =?us-ascii?Q?xdWX8hQYcx/g04F/ARLuZaLrI8y5REA=3D?= X-Exchange-RoutingPolicyChecked: uFu9rYW/SmGlAhjWE93KKrG9Ud1aiw5Qn46Q83Pjf1c4Xt6jhk5GH9BYQ0SiHsISTzdmMo1VJqLg5YXZw8HrzNlwgzX6sqEjjVFb7aOcus4+8JEzyfZeusJCV2ZAfqh92N/kpEARH2jB0sPi8sWlsz06h0ToFdZpRER0DpbFi981iCzmG0hbiwQKWiMXea+tVKqggTdX86H/8yulyGZNfA/uUpQHF2R8EndhlFcUjTPmDN9CHilijCl8Jo0nCd/pMesrg/LMkIOYSZACluOZQ0BT55ursQ4bYl8uJIDiWN0A2C17YJxWFOpD1nzcPtSBLviaJdhqKDHhRMIcV2fDjA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cd89d2b-81c4-4105-0914-08df2b90a51b X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:20:35.7188 (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: HIsWrrH2XUfHWRdFXxGVVAx3HB1oyJY4jW6J2Dykerxyn6myovJYiaVaLanLP+7WH4b+C2a7Wu7QCrUVo1zPRTucKPnAuJoCKzv6H55oOTA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-ORIG-GUID: cMrVKQqQ-adKoEyDWMT6HSLwpb5uuUeA X-Proofpoint-GUID: cMrVKQqQ-adKoEyDWMT6HSLwpb5uuUeA X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX0NyUuSsAqr5I wt8mQHSbc04d4uIRDd3Ch+F9A6GZH0NhOKP1EeoTwdWl7Z/M05ZU1+L+tjdEjg5znAvFA9o6D/u zaEajYsOMyX6UGozw6oIsHJIxsW5dxmUT5g60M/Gcis1STwdzPS2ZzprL45LW5hGG/qeY2S3oj1 c2cBC6LM2ENf+g0wxNL1nmO6SNzZHpgbmZPtTZuAVhhPCxeF6ro5/hAfdRaCIb1Qc39Ym42QacA Gd8cY+JtxXMlW74hAubg0uePobT1ofFJ+hBLzwBSRGOK7JVGJ1ebHDzZ1ee+c2KVnkYXuD4VGWb bfEAaZKokTszsvOdxJBrUC8iFAyGjdNqZZc/73dcUC2fEnIEwQ5bBavmpKC9MAUDFNQpOl7Dxjr ej/k/iz0e/5i3eWHFywZNWnUY+Z3zUZ1e5H1BhP/m8Q1rzQBwShJI0roJcXb92j0OionVbe6lJb ow5JwpMF4CTi8drRquw== X-Authority-Analysis: v=2.4 cv=V/ToQuni c=1 sm=1 tr=0 ts=6ad232b5 cx=c_pps a=wyQZsu7YS+H2q1uHh87QeQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=8Gc_limY6Ox-UrGOeuAA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXwz2ET+XHUGZX pjAkwu9QLU4So6dMOwEnpjyPDQJGbJriTEbFbKaCA5+HYsCar4ZZIqCP9vqNAraY1DHCYdL2elM F4oTNGYY0q9Q/lHCEqQCrF9jSI/FVdk= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792160443-18CCF9EA-5506E845/0/0 X-purgate-type: clean X-purgate-size: 3860 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 [Patches still requiring review: 5-11, 18-20, 22, 26] v2: - Rebase onto master - Add R-B tags from Peter - Remove FIXME from commit message and rename trace event in patch 13 - Introduce a separate I8259State for TYPE_I8259 and KVMI8259State for TYPE_KVM_I8259 as suggested by Peter - Keep but rename the associated classes for TYPE_I8259 and TYPE_KVM_I8259 and move the DeviceRealize function into each one, instead of keeping it in the parent class - Add patches to make variable names consistent when accessing I8259CommonState from child objects - Update the comment on patch 19 to reflect that implementing the cascaded secondary is actually a bugfix Mark Cave-Ayland (27): 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: rename PICClass to I8259Class i8259.c: introduce TYPE_I8259 device i8259.c: always use cs for I8259CommonState variables kvm/i8259.c: rename KVMPICClass to KVMI8259Class kvm/i8259.c: introduce TYPE_KVM_I8259 device kvm/i8259.c: always use cs for I8259CommonState variables i8259_common.c: always use cs for I8259CommonState variables 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 I8259State 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 | 11 +- include/hw/isa/i8259_internal.h | 19 +- include/hw/xen/xen.h | 2 +- hw/i386/kvm/i8259.c | 250 ++++++++++++----- hw/i386/pc.c | 2 +- hw/i386/xen/xen-hvm.c | 40 ++- hw/intc/i8259.c | 465 ++++++++++++++++++++------------ hw/intc/i8259_common.c | 225 +++++++--------- stubs/xen-hw-stub.c | 2 +- hw/intc/trace-events | 8 +- 10 files changed, 637 insertions(+), 387 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:20:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:20:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451966.1666793 (Exim 4.92) (envelope-from ) id 1xHinn-0008As-KH; Fri, 16 Oct 2026 14:20:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451966.1666793; Fri, 16 Oct 2026 14: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 1xHinn-0008Al-HA; Fri, 16 Oct 2026 14:20:55 +0000 Received: by outflank-mailman (input) for mailman id 1451966; Fri, 16 Oct 2026 14:20:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHinl-0008A9-MA for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:20:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHinl-003A6Q-2r for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:20:53 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232c0-2eae-0a2a0a5409dd-0a2a4507e8ee-4 for ; Fri, 16 Oct 2026 16:20:53 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad232c3-b4ea-0a2a45070019-94a39b0c2d68-3 for ; Fri, 16 Oct 2026 16:20:52 +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 69GE4wu41681723; Fri, 16 Oct 2026 07:20:46 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020081.outbound.protection.outlook.com [52.101.85.81]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hberu10ea-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:20:45 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:20:44 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:20: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=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=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFb Rs=; b=PII3KCEs6b9uknvsrQvvbUIKHz+uvKGaJ2OAIubyuTiqv4VtS4Gvi6MAh m011D6ad+VnPzP9uGgZtl6FHCiyv4tSqu0OjC6U2Blw9u78ey7THFmfpW/AujUTn wcYl84HwZyS5scuQrXJ39EJsgZuGFp4X4FZFcWFFX4moDWOLphmeR3lk0mh29D1K cen65hlna5HEvPCgfZuBjPfB+G3zcfs7qdEeNr0kcwMtD1xYjT7DPmMQvZxQOrdq 9ov1Zdoj2Pc+wVjWYmMRmPVK6DJUeYew0x526X+CSIVGi/2VrQPw2tWC/S2dJghi ouFMTY/UgrCQ2drOjQ0QTxxqmjA7w== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=E2uZtbYRoNUMycwxNg1BURdihulFX69lRzD9kmcNqChVXMlydOQ9KIWcvz2SOQh5PCwYfabEb/+y/tSQN4BUbRu1GOSEXccGz2oypYejXGkikh03kLSjSIA14v9bR2E3tPbH9nrq7kgzK6AKgDo+IfS3dmD7UnCZUDofAKkqVo8FznbwLgnLFgSKBAteq9Xc3NXHTOE+kbcN3wuNKFCAek+TTQEu4UbJdlBei+E2KrCit+UvsnJ91OG+4+jAK4pJWMMtvJLi51W6GJ3knmxCE3oDlmW0PPSp9v0Hu1OvTP71zl/kIdP47L2Ii13zAUXHGHexyX5vqsPYV5yxv932kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFbRs=; b=OFbsDlbPP75OhbXl5H4RY71uqAZ991YUT1Z5GPE0YSdQtDCgEVEbIWYO5Z4pHM+MsPJqEgiWxdyxmjgN0ZA9CqSm2sfkHSt4Tif1wwb46LObHOo4hQuZprNGetmGc/hZfp+4vxm0uWez96KdJo2z4/zW4NguZi7onlUfAjcorjQfnnUovlBS6j6BTeGEb+4nTPv/ecURxNLcM5iou93c5eP/nY0nZ0jtjjUsdCVUJWo7GeLLiN4g1v5bIiqDhr8hOK/SPxEvj38LG/E8j3eDID4VmY4EEgELj1jfUfGWUkjEhj1UEkUJwpWy11kVRXirDyJEd3XYCcDisfY4/D525Q== 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=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFbRs=; b=hJCiK9Cu37zSMnMpbb+9XUzNa0PuSg0xEPnLi2AsNL1oc/ra2SBBftT26VBxc77AkaewNxEi0RrRdz5hXvhAucTzoApPEhSCeQHswR/RlPtnYOK3mnHtURNrhPS3/TRwpQ/TJ/mGwp5rrIQ9/fAxWS3Ph8YPHwpbewiHOD7HZrF/S4z+rmLAnwAZiJxsc2EPgsjlI3iKpk/MU8rcHbWhh79JzxzoEPSwdQILfKmOq6pXkFP7ghBPke9Ov6nVBSbb8xg9XvDlf/eA0snR5EJuivGeaze992F7hvn6PdpjOCKvg0ID90zLTPZe3yZYgs2wMksKj4D7ZmQMPJcyHuw1lA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 02/27] i8259_internal.h: rename TYPE_I8259_COMMON to i8259-common Date: Fri, 16 Oct 2026 15:19:08 +0100 Message-ID: <20261016142031.1204281-3-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0076.namprd05.prod.outlook.com (2603:10b6:a03:332::21) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 28d1c3fb-64e5-4032-39f3-08df2b90aa33 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: YzyiWF3i3N6f8bFTTLDJjKuoDLjx/DZb2LGxkVg3hZERzXjQTOtgBuxPoXN3EhXNFaovswFni/zdI+kb4uszQmRWVZqoqQTTxf8nb2+k9qLv9NGo+cgiOu7U2jbIg/uhMkTszngb98F/aN2tlW0YyDCJzvEpZu/I3HQtXeSrAwVa6wfTCAMVhOQK7bWHI0NM+L0aRPIf6QiuIr1H9Src+lvku8/khZmMGZvgmdIRiHCTDi/kG9UmYRZ5Qar3hvy+JZlp3HfelYKPvoJgoZWiXTyHDHmtSMPJdfYyworghe5kNAB3bq2Rw4DbeDM1xyaqD1j13JcvJaYL892dhTrJ2tQ106RL7h70apfTiulUDWBzWQUNBuRmfTkedigiEiEqmF9kVL/vF7WGQGITQJsGHDY21951bhUR8C0oLCshqlG3RcL9IkbNbY9VmjuMgOOfFjCzn2bG4/JRD+dexFLnxKsxuoUmNAZ7vkk5OuHNdYhVrSTWsxZfrhk/7KoLpt+x+6Ov0p9VXFfrMq/QkJpDSAOQcnRmoQypiQBVfpMO3J9TR3jxYcNGseR5OO8hSq/dgP8vsdpOA8k9cU3JXTmDhRkhsaUFC0X6Mt0O/jSoxons86bAxqoV8VhO9L9THLkgGwREyQs+kEz59+veQLNpoWwnt6dd93cfbfmXhzGKDtQ= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?3HAttB6FSeDceJrbHLuoI2B9VrdLnZFTlQVl+UuU77a8SrqF5xKQmpvXrz3j?= =?us-ascii?Q?D0ZilW8gY5Qwo2tXTXhSCpPflEb9ca6aj7iriQFIKLBFkYCh9mKH4BrPStfM?= =?us-ascii?Q?u099J6fgH2c6SbQPdoR/9tG4vFCcblqC9lNVE4TFfJ9DpJr6Qrvbtoo6Yjzb?= =?us-ascii?Q?Ca2+00Z/0VgLtErOlRwk1DInXuIi2F7HDA3X0QqwwQuQTxMDm9rIQxtEtTVb?= =?us-ascii?Q?CdZNrR7jX2qkCGvsOvbb59sGLs4qeBd63zYxWhw3xrxd3pkRyfv7hc1axrVM?= =?us-ascii?Q?CTbkRti6EODCZOzXixFf1OvIqp2bG3d9OJc2oTSIUnRS/dbNK+mxepufWFAb?= =?us-ascii?Q?WsXB+cwnjBn9GOAS5IQYobm3MQuoQauU8i9Q9R+qLxh1hXrDNKHNlKNStRbu?= =?us-ascii?Q?iU/S2hFs9WGbyCuD0/Es3qiD68CmdOJqN9qTH7oBTxcFcbG78kw6ob7EupzL?= =?us-ascii?Q?FNsNs9YXxR6i5lfin3eZJW7u0GTrKNMw5mK0Uivc1M420/C3Qy1kYqDLemRx?= =?us-ascii?Q?nGB7eWkP8EJDM7xifTB4Z937VuZyWnqSyDNqFPcZh7msSAnGIl8BGUCaWQJ2?= =?us-ascii?Q?LyhveSoK8Poya0ZNgYJut0VFQci6de9IOlv/YedLNgfU3+SzjC+eo7X/GrWm?= =?us-ascii?Q?88DqlwSm2YymHiDjXZwDHXgMkFphP5r3khE/3fJg663QmTID/HtIAB16G8CP?= =?us-ascii?Q?mkQa7b9z+M7ZlZ1wyBNZbGIES3Y5DURCbJ0KKWG5pTAQGcPeEynsCgUM0z40?= =?us-ascii?Q?nDldBpNZ39CD9JceFXTnYsb3fJmHr6vCEWk/97rLVZZu5DOGp09uF9qXNgLK?= =?us-ascii?Q?8C6qr3qNJn2ktUW9UKdMiiYoqc8bTvOGh/WDk57I6EOu5RBNbaxPx+kySnB9?= =?us-ascii?Q?pwry5QNZHaNPMFJu2M975cI+KRnxvqXkR9PruyXRwRtUWg8Ztw7PffzQ7yj4?= =?us-ascii?Q?Xc60Cp7g7h5vAMW20xp/zvOU+hLCXwanc4tY/IRiO7dSnFiOLqQkApVrcbkn?= =?us-ascii?Q?mp7KA3mqMrXcECfKw2rWEeHgQLCGjrfuoXMlWnC+1aCe3SwNOx/a1iSKsy8Y?= =?us-ascii?Q?y0z9/mXtAvTUFwCtfdhEtk7670sxqBzMhqPn5+eynoolzFzKJnPOK0GbCLTD?= =?us-ascii?Q?c41Oa2DmiTW/wlAV1vF6RKCKFvyMaog2UOxkUrFE1IAS9ZFF4fqjF8skwxmR?= =?us-ascii?Q?MLPUyBDHGcGK6ZCNT3bBtWNRGKvAbK2ozOwWe5Lzr98hzcoLKuBl4t20MUQz?= =?us-ascii?Q?4PjT229hJFAUPgu8LQAWIc2Kp33N9S213xJ+bD0QtHKkFPve2pX3/Rs88ZnD?= =?us-ascii?Q?GZCx/ZQn17cCgXcRXWbff2OAT7zOSPtzNqmFCqVb3kpxJ/yHOxIy8WHass2c?= =?us-ascii?Q?mzMyjOBIo2PXlw9JVBh7mMhPdYH47hFYSoO89HhHvgcfw0Spc+pz9g+Tb1/T?= =?us-ascii?Q?1OhIy21J0eH/VVaCeGkk7bWVES4v1iStrMGKTWiW74ZCd9Stf8pk3wCfB1+A?= =?us-ascii?Q?+d97sc9juI2buC205st4B8VZAiW7E5kVYARCWww3YWzkQNLw5t/Wo5tt+tG1?= =?us-ascii?Q?nm3/DH69wWJnqoAdFv4xamyHxqz2Yl5T7/FJnQ9jRjHbB6r5m4HgwNvPsgyu?= =?us-ascii?Q?WAZJd5M2BNiblIDUmc4X9Ppk043Q4oiQzxM4bzzulwVAVPG4q8cERef0W4tg?= =?us-ascii?Q?zqfyV60VqPhSsj44pvyR1+wcy5jHfPhdGLdQ/njaBk7dmVLTMdSrAiP2cZCD?= =?us-ascii?Q?FgW8p5Y+PNE+225BTocTzU6SYWMHbW8=3D?= X-Exchange-RoutingPolicyChecked: yftx1Ge/yZ5I+i4VqgkKQs9luZGpqONkQA08MAoQa9uN/T8QAK6eymfmfJVr0IC521tzjVGAWnDKcHi04Y6KlaVPpsjAfzU2YuMO/PekpWD5mdO8u4z4luF9qiorx2+8iwW7uie5wKdOFPN1uk5FeEVe3+VpcW8ynPKF4yNvUnfKS5JRGS5rSZNOniM0OSaCr4eMP1/RQqeVaGF5nD/lkYOqS1dIEOM4krRX3PKJcFcNEbRIaoRGapnA8tIOJd5JVFL+GHIqbO1wnF5rq6rLiY7sxa2w0EMh1S+94e51NAHxGOTwFjoMTd9I8P5VNXc7bENRojgC1TJADjTbVKidLg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28d1c3fb-64e5-4032-39f3-08df2b90aa33 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:20:44.3820 (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: sFO74afNsbSXbyVnXIyOel+E/16QDQcShnDNiGWVrR1OBLaMYvHLd5VIgyvOnXoFjKYSs2aqq/BLEk5cjbHeGL7qh2g0PtjzoF/2+6HG9Os= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX8CLutU0OZCp9 h7uuhKI03jU8xNnPS5jiOz4HwA2wnmcNE7eWeeryjOQFvx/PHj/ZZGTsLwbOn6dDYne2QJDXzkR tyl/kt29NgL1NCavyXU+1M7eDdVvrUdh7aNAbbsTevqf4Mjve3d/9jloOnZRkLWxo3xhFVkyW2d zd0Yhh8KS9bep5VolRRalqpd1C8K/7XlD6uORaqU5x19Hu2TRq7n3unD2aeIA6HU0xUvEn8f8Ac 8PKg4362KY52b1iD1bBM4U2e9dCuxhFaGgalF+Osb0pdW5Pz+sa8OSczjAuInp+m08bJ/DzFfxD dl0MaB03fWqnyFUpiEYwjm/MScVWOpCQjRrOrPc3e6MfHRxhkO5dPmQ+2fp7prxHvSeiqysf6Bb XZ8T7TGrV5BdNIeYZohg/f3/RjcT5vRPLTxgpMFwmQGGCplcJ3shuBsiQGGocS3LHd6jOVOkbAM WkzFPHn4rLQU4n2YH1g== X-Proofpoint-GUID: junzSLCiSfPbYzo3Yv0gyQBxQV95Ygor X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX42bjrWxLeqn+ Cy3R0iDnohRKKzWTwT2O0f4klbJEXfAw/xfKuFYvDjemFFvDDddnTU2Io/1p1fWB5tFAHIHJ2R/ 3MJgkWnwgkycs7p+yHcfx3cqoAaM7WQ= X-Proofpoint-ORIG-GUID: junzSLCiSfPbYzo3Yv0gyQBxQV95Ygor X-Authority-Analysis: v=2.4 cv=KMLPn1Fo c=1 sm=1 tr=0 ts=6ad232bd cx=c_pps a=PrKk0R3FxLq9+u45pGB2Yw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=xWlEjtkXqD840QCPih0A:9 a=cvBusfyB2V15izCimMoJ: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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1792160453-36AD8AE4-28C24BE4/0/0 X-purgate-type: clean X-purgate-size: 749 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Fri Oct 16 14:20:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:20:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451967.1666800 (Exim 4.92) (envelope-from ) id 1xHinn-0008De-Td; Fri, 16 Oct 2026 14:20:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451967.1666800; Fri, 16 Oct 2026 14: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 1xHinn-0008DE-Nm; Fri, 16 Oct 2026 14:20:55 +0000 Received: by outflank-mailman (input) for mailman id 1451967; Fri, 16 Oct 2026 14:20:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHinl-0008AF-Qf for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:20:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHinl-001AYp-7Q for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:20:53 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad23282-bab6-0a2a0a5309dd-0a2a4509d31a-48 for ; Fri, 16 Oct 2026 16:20:52 +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 6ad232c3-be1a-0a2a45090019-94a39744248c-3 for ; Fri, 16 Oct 2026 16:20:52 +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 69GE5bUg3246539; Fri, 16 Oct 2026 07:20:41 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020087.outbound.protection.outlook.com [52.101.85.87]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4haxj93881-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:20:41 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:20:40 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:20: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=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=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomG uY=; b=cspCwhjaLFqhz6/xxAimuMhU2DquKw5pvWid1+BKnVWsw58+DSBeHl4bW f5wIxDifGU/kYcwXZ/aPHLdK86eeEh13ZU8XqmAusGUgj9V6mReattEZDDHOVrTL ryqzsVQAOOsiuB+yy0DwttdhgjBWevLFVQckbAstW5WN17sKXjzUzSqBf/Ky6xCE FUtu9fPqPvzJCF5viImex+dGyXTjxox1SJKWxm47tROSbdMZsZ15ROMq0UjPjpyP zChPV/ZTR3RklhcJcbDoYwpaAjD3DyJQW5ETYzvE9SWm6095w8ntrjApfVcKhb6t Cqz7d0+mfgRBP/uXNILIc6sz682wQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MKg9riRze/e1HBrgSUtIFXd9PGPb0fVZoy9ddQAVa1mgWnAlRmwLL169NjwpVHAzm6TiI038ew+vPlFYIbzpkX3nEZq05ebMCU9phQfM59lUD2PGPB+mR+ugsPPxw6v7TlXqLMt0+bbeEq5JhAI+xU4Oh6RGsNVNkiXGUxqP/9c7w5Aq06G6gIk37farIy3PU9hGWriUMbJFsn8RitycdSIzlsuPuP/ijRyA1DP1xqPthLSh1+n8720fxvuNfdoKzp8nMJbZOzo5hnehK/mrBXEDn0mtxF/ZVu3M0HEXOCv2N2NdPJC0f+rZ2V3m1Ersdu7FLdbIjdRzvK5HRbXr9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomGuY=; b=pl3RX1U4NzXPjPMqGZ6CPUBMMU4mRfiZuSYrdBxZ7FCMe1CNi2XGTk8NcL7iNh7XRgeBIkyQ3+2gton24Xn/c4L5GQc/cmaxnCHSD/pgKiAR9l+MoMmbV0YcYl97D0j5Q4bHxqiXtReBNSRbXW+SqJCovBDTGoJD4aG2ERcFwpXuTqw/o7A1S15d4kvGck9vub2moqqILYALFE+8dPXV4G/vE/vlc1u6WJR9W7IolnQyBXtYSlAYbA3j1lb5/047Mt0layQGxxqO0A07FAncPOQi3LKiz8AMxB/LxDibT02b2VTGOq0gV+Pp45hFuf2YGglClDd3SZmkyD/d4+g7Ow== 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=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomGuY=; b=tZqiALdlKl1PYPpl8L0SncVWel9SZdUjyf23hU02lwuAokvoENsas1UkdfZAXtFDl+BsFWwfsH5amWw/g1VrBiT+ZTh0nlzO9EYL8gu5OhcAQ7TVu7nwhcCagLPskTs8UcYKNSHmGGCidHaiuYxAlzx86JdhlVum4aQnhUl3egX3Lw5Tf32OyoWtWzGHI9so1CvK4mdsmQ5yGC0sNZ/ckIiPro24vE8xSg/+dv5ECZP1fXQlFocvb6qZYep/gqi/pwknNPmdAkbPBxBqKpvZTgYQjxvPOtRY3pjNH7UGheG6CfMhtiK1kk9HRBdnB3QaEtPM2XDP7hkSR7bRW59pOA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 01/27] i8259_internal.h: rename PIC_COMMON to I8259_COMMON Date: Fri, 16 Oct 2026 15:19:07 +0100 Message-ID: <20261016142031.1204281-2-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0013.namprd03.prod.outlook.com (2603:10b6:a03:33a::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_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 1e2b74c7-6b7b-4797-8765-08df2b90a7a5 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: vfuCGe7BHX2GPWG/Ox6careXF/FNvKLZreqbXiJeILS74sDTj77U3wTgJ4P6pi1uq/R94d2xJl2PM/BhtPxRR4DT4T9vBqWV4BrUNaPH+4nVkyDX/Rxnh4FPBrfcPWT3J1HSo2IlygixRC2Am2rbEEPvL44mhKOjoM8gOLPpbDVM9MN9kUzCos3afyybF2oPfJMvJF2h7eRFdUyz/jPIGkqbMs84Dyh8GOiIBCMqAy5/ZFDTPnKbT+jX4x020FNyIrPmfuaCGr4QJTDJpaOPcWpA+rtlD5AHcbWB7VNXPsApBGDxXpjqZF9lYidSBuKXlPGK+eHf+KIsz+hJLTsLgz0pqxF4XhWwCznYsVOYk2VFhEgKFqwRq5QZh1tc8gebShU5E4+o4qb+X5JaB34uWtf3MOLj5fFtJISh4ojKbnl4papmJXNmVVosJnZueUJuZv6fBf0rk4V+f0KRppZfyKw5G2vtQMIpDhAW0boWZqrj9mtTp2mVSwIx1UkINPAvcsAsdsLrmPx5KV385Ud8YhYIFQ54S1HKrxsVyyiusRKI/rraATky3RUufWS61HHUkjtih3/kjPea7E7rf1LETxj42d6EYvKQMqIbYPq7jrT0lAB1pjOQDbv5PQi6tZuPe0v2WojFQ3MEMWuZTaanrxFdZgFJh7i2TCTDkT87BsA= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5ZBg7NQxZFKeX/f+MimcRRmKqVXAxHCrK8eslK7WdXYSIMKTNXfIxBr+B2XG?= =?us-ascii?Q?4G+hA/0SlKxBqfBo4c6ufLPwzWjHU50CUSPbFh3bAT0pAB/DbrKgQqL9Y3mZ?= =?us-ascii?Q?GPkbhgPcCig0ClFLPR7qwmnQpptkIdRcwP7C78+Lwa994wuUjiXoK/KwVqGX?= =?us-ascii?Q?5DCrfLAzNXhUa9OfmFInOSrbxzVQEqBF87kZYdzkUpBAj4GaxoHMg59b4Dzu?= =?us-ascii?Q?0jxzW/pv/nVmzkHax/MVoHYcTEQ21G+uWSxNZRkxwqqLwTGfObX9/nFSWywb?= =?us-ascii?Q?pf6Hv7zII4KX2KaFXN9M5PBKdFoNANun9ZJHDNtEi++eahEeGStBdKEL0HvP?= =?us-ascii?Q?5ZL+Oo1HZEgf5ENc60Xt1FB7gu6zu9jv20bezwv+V4Y8M6gq/mJE9zMtzlXj?= =?us-ascii?Q?UjFeL7iIG1c0JQSqwG0OIpTi1yQfC7barIQP6FkP5r5gvh9N/VKOUVEzvnVa?= =?us-ascii?Q?lxuOve8y2S75EocVdd2wpLYNwRfrMv1nTbuLJ1fubFiUTagJR/9c/S7e0qUS?= =?us-ascii?Q?gs6Ddpk8WF0Pi9eB+o2DyfojipN7TfINFfqZjYNKkLgiEebs6MdYxdhYl8oh?= =?us-ascii?Q?ExFfFEMKFmrvSd5xf2sUp4kKYSqHhsk4cfNsNerd66o2167WzNzwqnGAGBtu?= =?us-ascii?Q?HuL7mr9FEbOBDDOYRq7VbtSuwb4V/jZHw1qVGxndsyc/mssG6P5iL0lamse4?= =?us-ascii?Q?KRYiXC1TxmsNX1zu4F03I8Rjh390ALfvAXLG+g9Ss4LvyhGr53eMu3GP1act?= =?us-ascii?Q?2ukmHOAW1heQRtbj/2/STNKLDsbIc/kYkGETwVlGNmUuFxDiZimn6wJjs999?= =?us-ascii?Q?br08/9bOA1H0pTrTAjHP5pzT0FPh28BVWlx4tYJKzceaEenG1eA0RAXmhEB6?= =?us-ascii?Q?aQFrkMxTu1ayfH2L0MxFXBAJcAEXV3owcGQNpOkBvxH0KmHu8dGWKP8fT6uP?= =?us-ascii?Q?XuI90HRX32VBq9HZrOEBA+TP+cIuijHak72kt9jUpBtNX5azeOMRdTEajgid?= =?us-ascii?Q?YNA+9LNL4tg3qNk0oM/3ney0ctGm+tcLUalXB8XRXeAFxyCNmApZOk6y4+xE?= =?us-ascii?Q?omBTmBwjgiia+vWLd0FN9+mcAvcHEnfpxiHL+MqNwUjmTXivZGOcy0LrS0VT?= =?us-ascii?Q?N8F3hEo/yyNscnL5DKU/wWfekFFXpEulQCGXfSWuFfViSNPIWgwAF2oW8WLM?= =?us-ascii?Q?T1u6pWvhXWEnwSNX2E0caNUCI0izPpfIjJhaUgQmqVfgVVLL0mAGsUAzxRtV?= =?us-ascii?Q?YvyGLnXTxMFGSjmH07O/0ajcoO51hNjWtVG+SUnxOcFdN3eCPqVekscj260E?= =?us-ascii?Q?UxuMr41FkV5FDrBHhWo+alMGG/C95FAlJpuEDsxkvQLrMu/YJmvArsD4geUG?= =?us-ascii?Q?y2pE85Y0x2OPs6Ir8hIxkAPhPRzci5euzbVtMX1BkrLp+i8xLTrxGXyeiJN4?= =?us-ascii?Q?gK9iXHZNPDamwEsd+pxu0tO9O75Mz+kJ59z5hpEiZr4XgGg4w/v5ZiHZs7fO?= =?us-ascii?Q?yROGjh7rKfJunNCYGrYllLgEb4iqg9VJODOfXdsSWKW0Ys1Cn9pPC9uo65zr?= =?us-ascii?Q?TkLMtlLC8Yx4/1i7mJCEMvWXpTTpKvP+6cxP/IV8m0zDq2RVNVCjr39eZLHo?= =?us-ascii?Q?aFCv2cJXpO/pc9ffBO8aRwqWNYJ9iBCwdwbJ4FEyXdghaukH7gcNMVz066ax?= =?us-ascii?Q?RqzxPEhuB7novliBiDKQhD/U57Bt1orOj2TnnM+QBj6kCSuZk5uHwW3xlmsn?= =?us-ascii?Q?M9c08PHhwZ47/O9nRRtJU2aZxUb1WuY=3D?= X-Exchange-RoutingPolicyChecked: WSG3TYjVdEmmWTJ4d+MgH4+Z41dH2oYJW2YCZgJCmMpoDJke9mv7orU4XaEWvkDnlK0jx1biO50Az1FC2qgjy8eDJWu/Xbp6H6dKdB1eNT5NZ+NLpCTK4MIqkq+fGkT/NGU18xkMcgfM6gob+8aocNiyaiU5ENnLOgN3bWihs3VyR1qTOQurqI6T5UF5YIptw7KwIfEjGI10I6qjACQoj6E+TbVj/9zyLKtV86AwSewBQLQz5qQM2NQpvzvnZTnzywlplYHIyZ2NgeK8QOf5z1r+c1S8ke2vTnfOmlp9/GWBjxzTBY6hotTZs0uTzxhwdGsU+WNba0/Mc5bIBbDWLg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e2b74c7-6b7b-4797-8765-08df2b90a7a5 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:20:40.1628 (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: 87vnX4P5E9ZHpkBOg/bt9LTvqWW1r6NJY7y4RDFz0MuogB4ecP5XBwmLcVM7GlyY243LZhGyRo3o1996wezQoE2fsdA00qAufLLpXez3VJU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXz14ILCBC0BDl QtqMrpaRK8JlXty0pi9Of2Eud92rUobb2RruQEe+3L3h7vmiWojRv89zxaJsXEpeVahhUQfk289 zSI28DK0k15rdk3q/HbfyqjN1djBgO4= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX8SxS9mCvK/FW hwBm1yZV38vTJR1xfG8g5hC2T9j+FIwvfkvUfFDH9KpZ6pdEEMpgcQamlp2x7e6IL2nTZnYshLk AdDjT+V77BvgTKC5Gk5yXEsgu4s/iDBLjh3+CZJbDDujeTduhxb2JC9aXnMutcMOhhgdkTnbFWr OgBsdjRaIP95TFJ/cnzf5HE8Eti3sl1ISCbWL0MvRftomBfaf0+eVZmLETSC5CDzLeJ/tHf5hEB IaBzPyvVvOJ4sgqoBdctqGUoJ0ZoKsDqqY14R/yT/UZCuwyOHwy2kVLIJZhtCgGG3DHUp2lli3g ht2a6/aMdrvdcMw4UsaHPltdRgAdgcQfsLuHfvt+Olrcq+aa9HHTq5tOeLzksH1EBaciJFpvTXI iYQhgbVjyfDoH5uY8drlAFtQp58Hnay6f8hNORWWywJvHviRBw+nKUgB4ydHYe8GeWFQZKrnjiG TVe09CMEoxhTzefhdUA== X-Proofpoint-ORIG-GUID: -MtB3VpxVJhtokg3paSY1HZSGp3V410e X-Authority-Analysis: v=2.4 cv=ItOL47/g c=1 sm=1 tr=0 ts=6ad232b9 cx=c_pps a=R61xy7Sxgg6fOHg0EL+J9A==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=XF9Y1ugsmyLceZbb4BIA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-GUID: -MtB3VpxVJhtokg3paSY1HZSGp3V410e 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-bad1c0/1792160452-BC8C9034-4AA43388/0/0 X-purgate-type: clean X-purgate-size: 6643 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Fri Oct 16 14:20:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:20:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451968.1666812 (Exim 4.92) (envelope-from ) id 1xHinr-0000Ci-6k; Fri, 16 Oct 2026 14:20:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451968.1666812; Fri, 16 Oct 2026 14:20: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 1xHinr-0000Cb-3f; Fri, 16 Oct 2026 14:20:59 +0000 Received: by outflank-mailman (input) for mailman id 1451968; Fri, 16 Oct 2026 14:20:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHinp-0000BE-KJ for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:20:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHinp-001AYp-0g for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:20:57 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232c8-bab6-0a2a0a5309dd-0a2a450cb32c-0 for ; Fri, 16 Oct 2026 16:20:56 +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 6ad232c7-f479-0a2a450c0019-94a39b0cc74a-3 for ; Fri, 16 Oct 2026 16:20:56 +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 69GE4wvO1681736; Fri, 16 Oct 2026 07:20:52 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020076.outbound.protection.outlook.com [52.101.85.76]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hberu10eh-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:20:51 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:20:50 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:20: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=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=NIlAnp4VAldnLceUySYWQNWAeTWWwprg269Vv5DQ4 Tg=; b=HO73wnsiTrg/yLKyFFRPwjkZ6FBrHf/du9JjfUW2Hv33SUUTYZctDbUBh oJmxTz0+fzgI563760BffRYVFFyfLl5wMfHQ2DR1w4ilmL1RVBb1J1R36j+HDWEn Ag0x6rsK699X1Yx4kGoQDlXsKRVHWAk7Dt1y3o1IJF7OfGyIFYw0aq6qp7UG5ejn qAD2HIiOUCXKFJtpbvMYgFUqw7WiOfonxiBGUeUwNF2/Za4rCeWHSZVqy8nt2ErT W9pLB7a99ppSknGs76fW2r5FSRrr3rCk9+E1G0KDOTEv4xoLTuu6J/iFitjji5X4 e9PJrbs/WuKS4idjUoGcsvBEbuIoQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oHc0q06T9rRmXvxShGiOPb/snPVXuCTujSJJDhimehRtn0xZNpvk/GSEjgS1pX1eYWHZnloR338groTC1wvfXzyzT/r7iFV7cdQingm9BECLeuK7tF+Ayt0/JD1MDhFy4mvZwESBQK6AWLu7kO4L84JBD3jDxoTBmHMlKvoWaqNjK67UnIpvZSfd8SwOGbYj2bak18yu/0X/gXCtVA+VGHhENIfRjvo8RBmtJiVoo5zNstUgN+WJyfBw5qNlp7sXKqwyCAxIcGZw2tElmFzpRKHNua/m3WWeAs0eEWyYkFHim1l4xUrFoDgJiGtW6nT1THNLbXqGyGI8intv/buvzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NIlAnp4VAldnLceUySYWQNWAeTWWwprg269Vv5DQ4Tg=; b=I8wTTqCMlDbA3NqpiNv69Vqn7OfC46SpQZTPh57hfLAHmd+gVs+64PkFphAUQLOHWv5qUFw8OAS5AeCJJOlSLkrTdqT3NNzVpNHiWsmiZ7/NnLBATZBiJ6SWXXRbQxHGPTfK7zPeN56SCp1CNeT+sYQzPgJN9/rvo3GxDwgUaWTJxQ6aiEVkIjISvRJZol15NBcs8Nsnm0NonS3H3pxOuMq1JajsRHSv8m7Vp5T2pRhgOeB946dGysk4MfDFJXBBPh0hd6eYTWG3Iv7mxoYyhegXuPhfBeR+5AUKCuImO9rtiXfYNVTm2o1J4QKCcdyLJA1Inf3r50DdxPXG2MQaHw== 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=NIlAnp4VAldnLceUySYWQNWAeTWWwprg269Vv5DQ4Tg=; b=GbIJEdRdZ7NX6yZWw2CTel3LputhFhILPxDvu+LDICpzEhChsjq/7VTdJbP0WRwxNBitxz1WRr8AdY1UU4xMEs5oeh+SCnFpvKxu3K22RhbZHrr7H2qWcEo0SATXwiSPBdEAdvvfCgE9I0ebvqPAjvsyFv7fGS1apdjuP6O27aUmAZALKWNqGSi12rjU/+oRpd3A1HLQNWWhNLLzNEAoK06zeumFI/aQuP8TDntiAXLj0Ez+sOkP9GP8yk191wGJh/nzj+9Y7YEw9bRtWx+wQ9c/JckWdM/j6WZrNdXQLoubcMvPg7r9M9ZdIMe0LW4+5o1gNk2QXYZmkBJy8239Eg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 03/27] i8259_internal.h: rename PICCommonState to I8259CommonState Date: Fri, 16 Oct 2026 15:19:09 +0100 Message-ID: <20261016142031.1204281-4-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0100.namprd03.prod.outlook.com (2603:10b6:a03:333::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_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: d7bfa6cb-4d4d-470c-2a14-08df2b90ad76 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|3023799007|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: Z+P3wcbxYQflMMVdqOSqvz61eLkdwyDhI7NLiLkxIOTs9NNreblc8MZxUd3kKkrnyOeyRMz3D+pDM/Ju1Q5pHLLxmnEVIfqARcSHsAaxKDW4Uvi7lozNsh9/JwsenKgW20WZyL1l7tVaGap72yp6QOlgjYMOw+6bJHgE3HR6T/gApXJoxrE1T6UnKn7t1PWu7s2eJu7jN5vbApHsxl7o0Ml1gnh+5TaIi+HYNPx674Ab3ooB4y66iqq6gsx0oNAUQsVgwKhBkvxFbvKMgBKq6hYVVbmOUfLHGcJgQCxc+cKIklthpzhWEYhFKmaTTk69/iG7MOGlnuuMg6M6q2hWV8ZbuE+in6bM1RLMiO05qUmwzUtwAuErRqSwz6M0cpJQew3dLrc23edGyrrttvjM3t2M1XR3PcCfhWXoVXgWEO4iSmVDKLW8GJW2ICjSJ86CTQSkviR3QU+H9K59EL+VcA2BW2UOpsvitXg3Sv42Zo1Dvb3dS9rSd2fnhOIUPr3VV/spAafzxuOranvo+m1CWzzUd83WFF/6yuMYkpuSXMVbpVkZ4tpz81BC+TbPgQfkThJ720WKo3fdtGQXCYmkdAIazRTrDnbL+D2Fr41wRiQwZq3B/sFofvQtFuaeLNITmOrwmh5nEsX6hM2J+7P/gh0+78X2rXEPcbkQyJI4m2I= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(3023799007)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?4Ke1GC+wQLL2D9iJJYQAG+DH6VUD+0SNclBch/C/7cqUkOsFO9140U9lsjkX?= =?us-ascii?Q?wVng0gJdGLPQZIsSrTd5v7AmHKW4MaVW7LTnK7qmiFV/t+XAP2B0CqJDxaEx?= =?us-ascii?Q?WULvrGrYDQk+dvswecqSy91hF1ol4AjkP9pyekDH0TxWKMLf2JmCM42jHWXq?= =?us-ascii?Q?NHBofo9cAN9eUw6erKAq7tfrXuT01WmWIv+4qDIrLt3VMeUkDPFVq4xK/2n/?= =?us-ascii?Q?ukgREwaZGYIlgsZaEGBWb3RF+Mn1UQ8CpNIffLL+Nh+RlRbQrjiX1nv4NxRS?= =?us-ascii?Q?Zap98MxRcZi0pn+zloYyJ+bD6eutUZ8LNXq9MS67tEfl6AEtw7qSMGhu+n/M?= =?us-ascii?Q?QntfSya0iDxLVxeZQ05YrDWPdLl0Dmzms6EeHvHZUxb4L+EYONXnoi0WNq+C?= =?us-ascii?Q?cd/w6+hNKEw4R7WYtWRBF6MwsIxNrMDTbDQZqeeGbDwvQWNsfKEdw8FmCTJx?= =?us-ascii?Q?hNcw7Q45IJiP9zcLMrFnohk/DgJQyx6Tgn0M04NIWmwWtBktJ2MoH0ofyH31?= =?us-ascii?Q?ds8EMtX7jtOBDiyxKX72bhFu6ZXecEzdB+YlyBdNIzZLUdIpR9s5N9guIq0l?= =?us-ascii?Q?we89XKHE4Q3WHeObEba0p7MJ+QYdaPhwOSElkPnw2iFmKHDCNlVEpG6cYWAH?= =?us-ascii?Q?HLccyGpawjedIf3Rq/CHOPxgFxoRPFTGna+LJFFTTZIbTLenAxD8Vy9gTi+X?= =?us-ascii?Q?Qui214vYpYwcEHHOQyzMQK6T9cVx8nmfWT0sN27FAOAy4dJT1mHRXDPNFEPW?= =?us-ascii?Q?/iLR6S4X4Mh3xfB5yrmn++bdkI2V4P6Gj7df+l0dHaPReAdKIQwIZmUZLbm4?= =?us-ascii?Q?0qAmLnoL2xIwN3KtbbaceVeeX6OwMZ9RJCSLCpOaJvv4dY/dCBxSIvSz6FED?= =?us-ascii?Q?h5XJf7FdVIQIxxKW62CH9h3u1Edbm1S+iFRqz4KaIwwyez/H5HyKBz3nayb8?= =?us-ascii?Q?jJyK4mVPjv3xjpgUDZ816eMX7AaJIpyi7oaKGpEJaXbtGh11rioDBJMElHGb?= =?us-ascii?Q?g0C6Cy06hkAdjaOjEaMfRyGOsdLSnhOyiTprqOdcW1qZu1C6eX9Nf8XMGpfR?= =?us-ascii?Q?DL9MmMLlwqYThmsHftopbbpNDWmv8gunZ2zpTpqO8ZQDMs9ZY3DW8Rruu1CT?= =?us-ascii?Q?0pVXmTSmcTkIq2UpzN38NLbpwPo3e23fSW6yLJV6I+xYy2iPUw8rWxS3vTAq?= =?us-ascii?Q?5hspYRb9Cw23we3ZpjOczBuI8Tfu8hYlT+RWs7HCJ+gAkltvU2+0asgGhxSH?= =?us-ascii?Q?DT1ZPq5sZK8r9IyxrC2Nd+NiON6czMsMWgWC1W5nGbcUsdytNErHhf2hI0zg?= =?us-ascii?Q?mY1/iU3DpAxpAM6kaQIw2bUzk2IzdXB8E23F062zpoZpXTE1l7pWLToYtJnH?= =?us-ascii?Q?yfJw005XP679VmC1eiGmHhIsDuOsrXZINfY3fusELqKNSmcMtNw00ei1yANO?= =?us-ascii?Q?A1XiAXFWErv4zQt1oo7pWHATe3cC+bmML9YDmw8D9i4HCpeKIyh7I+57OORf?= =?us-ascii?Q?bixpXF+4vjJcv4WqvdHAjTbOr0fUnuqrSgJ/z7R7z48WKKTu9nEp1+R13QhE?= =?us-ascii?Q?Nn+e4RD7MpEfCMR9tF2dJt5fJnkDobcmkH9UWthTII1p1zm+xbdC2YgFZQ/j?= =?us-ascii?Q?ZkZO+ddarMiQLgViei+iSpF9o+X6JXek6qWm8u350lyL6JbpQrRs814s18br?= =?us-ascii?Q?eoAH/A8/XpySu7RMzpqO8fSKe5+lgjl1aua+4PROXtdve+U/YFoMeQIwXpeT?= =?us-ascii?Q?1FDtp/aCwLLNlJg8DGXFaZ2t0zNlqK0=3D?= X-Exchange-RoutingPolicyChecked: XKVztMYcPftvuNC9QR6uw4bIWDSiBBpdb+1ElYSE/zyxDlVBJ4p3p+8xJHgnELsRnjqCCNJquY6uX/SwjMlGwK2e855WIuBO8EYW9xcP76mlo+UkH8OQGFqTgWjhqpFyd9gBibPffnbuRiUY+oY5HxYeuETx1jJrhVmWevyx4lZTEfQNl3XMSbZFHm8iYCOyfuJ065CMrczvXg5lkfl66rUerPuT78srO9Vp2CBdYfN9ThVKithxc3697iMsbyOVycIR9FPUouulsJlIS4w50JfIcV47TQiZxBQ0g3zd+3aXKVbx0baGhbDM4eO85xvN+q0auvInJ1hWIQzW1l2W6w== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7bfa6cb-4d4d-470c-2a14-08df2b90ad76 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:20:49.9984 (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: hXeTpwI14S6o9nztJogqIc+gNK+f0Fxt/r0EZOry+PCtfUagom8vCRX00RRj6KzcWunN/79B/VeHPyciZYZSpft/fNiCgU0YidrL5vFHlko= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXyyGl4V7kUtc4 ERQSO2msQynlhrxlQUJtnVbAE11BtdcI3A1x4WZKDWZVOWZndtbNjmAOP5aRTjJy4Cbyo76HIa6 clYVcEtYc9aKWp5GHX5WszaLowa+Vv2DxUqk4h2BLL1yKnQUA9hR9hJoRa1FinN+bEyiJnkxJaZ mPUhssRyDlgi9aKZQZEqT865e6JlFcyv4P/otLj/8ouaWTJIV+UfftjHQchYM6N1Zq0dsUPKjdX qQnzKZJpBww97sA8IPTdJ9KLV968DNpGMSGuKBiMygb9LipVdb2Ny8cfmuUxxi2ZUEODtVGIezA YSMbQaTpxEnzuTzMohQcMD4HWwirzigmHYl3NvCwa/Tm7rqpqd+5eXpfF6EYMR1ytAeSkF3fY2j 2HdBBlY0hwYtmKl8PrPxivyil/wgwv99AqdqOEdNO687rXg+v2WQCK3v5TT4uevtvtqVu+dAzm0 lZkaHo574Fz5JzJFGBg== X-Proofpoint-GUID: lW-jekKSqD5MBh2xS0uEqkzVgoQyPVlA X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX/iFMH0fkz+Mm 8Z36LMaWKpT7kpsTU4FKUU6bUt8p2wJsWCnpMu0ac992mca2+7eF3AUXNKCyFeWZkSJaEB1Js70 9sz+87rMMN5JPXi48FlfXfH/Ap5Ty+E= X-Proofpoint-ORIG-GUID: lW-jekKSqD5MBh2xS0uEqkzVgoQyPVlA X-Authority-Analysis: v=2.4 cv=KMLPn1Fo c=1 sm=1 tr=0 ts=6ad232c3 cx=c_pps a=PU2v30DqrLDYHXTVxoobRg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=01ND9n3NiX1-kDoXiQMA:9 a=cvBusfyB2V15izCimMoJ: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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1792160456-5093EA5B-B420ADF1/0/0 X-purgate-type: clean X-purgate-size: 14398 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Fri Oct 16 14:21:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451971.1666821 (Exim 4.92) (envelope-from ) id 1xHinz-0000bs-F4; Fri, 16 Oct 2026 14:21:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451971.1666821; Fri, 16 Oct 2026 14: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 1xHinz-0000bj-Bq; Fri, 16 Oct 2026 14:21:07 +0000 Received: by outflank-mailman (input) for mailman id 1451971; Fri, 16 Oct 2026 14:21:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHinx-0000Xp-Dl for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHinw-006Afq-QX for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:04 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232ce-e002-0a2a0a5209dd-0a2a4508d45c-26 for ; Fri, 16 Oct 2026 16:21:04 +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 6ad232ce-f659-0a2a45080019-94a39b0cd276-3 for ; Fri, 16 Oct 2026 16:21:03 +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 69GE5EQK3216017; Fri, 16 Oct 2026 07:20:58 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020140.outbound.protection.outlook.com [52.101.85.140]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb045k1jx-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:20:58 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:20: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:20: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=WF5AeoPHT0crPwuGB8Idx+PPfmDLai7p+PANfpaNO 44=; b=IL57ft5+FqXvY3lASfy/b5Yf1U5Y9lKzMVm06rQFaQVeQrAmTCszmOagB 5+F+qAXuhm+vsu3jyHh6fldauxCqc+GdJZa5jShG0rzaI0eeO60sTnTLdkCgLd42 twDTveUdh0Uo/vivPvThlNJD2wOQxGpvcw5jFoX/9NEg+j9vmMHswKK4QSo1M968 vE1Xu2nXxPUIH9JCgD0QTJyg6R4B5uDY6GJ5LAZ5hzYubKqcFtzMHCbWU85nMl9I yT9qKTtzsNll0PLLBqQjeXkFRGLnQlNS3/bwKBRTTsmMcUdOxGyxx3Cw6J5zxGlv qQew4dCNBauLE5unvN7SMOYt/Q1QQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dXL9dyRhNJ1+T+XDWaB9f9HfcMNGQyv7E7ahqh4vrjCTLVlqNnScEI4D3CAb3dPA5sFVW+WZL07hyPxY+5UdZJmvoMa4o6aATlMZzOr7hPsvRuBbG6wY9nIAQ2vVKR23otkxq7EXD81LgKPxP9NE3YVd0hpOkBVBjCAd6h+i5sPtXlQF/P4MDi1P9YPJXQfF9Kyu2I6snOw6UapI0XckWpmlJaRZI2KaORfWLOzRgTpg7ENf8SDdUsXrcmEv2KBTyU2OWKaRrhyfCadrF5cImV5aEJynk1nZ58w18M3qQ+EAeIzLgy415nOGa66OrkEMCImvYLqDRYrnYb3ARPMIHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WF5AeoPHT0crPwuGB8Idx+PPfmDLai7p+PANfpaNO44=; b=HhmrhqE0N7harBKkIghv9ieKYnnPbWB1LUIW8GFKIFglO0vXPDqpIonZ7qWgMEjU6HYMRNAKvwqxvrW32ho55ZQLYFv3IU4zbhQulhM173Kvdx4y/a9eAx91PFVNDhFoZtR8N6yQjllt0qbpfLwC7bAhil8u9mUeCUbqaXJZi3eP3oQsDkdnWF4n7xgzTf+gQDYUKvObUmOti4nR0WKxOgoLZd1FpXlxec/XA4Q1EvMR+eg50Is7TB/EQb5yKRHFh48Wlo65go+nFS6Ql1WUgSaKBvkLJsSdiroFO54ks1TKM0sfjoDC9aNQZ90Z+a93NgJPhjgPf45pSbn+mH5WuA== 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=WF5AeoPHT0crPwuGB8Idx+PPfmDLai7p+PANfpaNO44=; b=s8PQNfXLeRvFqPPtRUuYWa/R+2neOsbNcD6vUZ/LNgVQHg2w6dQcYQeMcXOB6O6GE+S0qOWRV+sGfc3NO1LbYHfgS4MFKR5G/3MyMWOVGE791j/X71q2ASbdXQePKA0SyXDP6Bp0s2dGWRVyJP9q0K9NFUWX1Ne0NDSQtmm1SKDe4IybsQXOdTsJbt7HVVGcmS1pbijs5Gic0SEJ09nMarJ7clG6Q6jBx557LAb7v75+Kf6nERpgYcerVf4WlEdOd2Rs0eH+cp0VHeTknz8R6dk826kv/GkNwqI6x/VDRYDLXrn23WgVSVcMIs6mfPPFziNOxfoLZI8fL8kZDbYexw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 05/27] i8259.c: rename PICClass to I8259Class Date: Fri, 16 Oct 2026 15:19:11 +0100 Message-ID: <20261016142031.1204281-6-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0341.namprd03.prod.outlook.com (2603:10b6:a03:39c::16) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 4b7f2c11-d811-49dd-fa38-08df2b90b1c3 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: zgE61EnzlnJwmGbNnQcaYqrLejX9/l7Zf1FBzmVPf5ym5NN4+yf0fSiqrKQ8wVfhe535naiKK2iOU6MXjg5LAFGVtMpCcV12uEkHc18kDOYAUdeTgRP9Wh3f8gXpq66AfoOhWZq8q8YkXv17q3YegCO6uPEGIfFvK4YVoIQ2TCAc2aZ4jeGnoxKyDCZizyZUt0DuWyQzDm5A4HRaCaGC51AzgXxnCafg/+ktU0fwe85oifQw34VXhwVwNFJl93e9uzrxH3rUKmlL/SojQQGQzGaFy0NLDPXTI3OPnBOLYWShEW1reqjwSI+kjH8HPCOK3N2bXxGm+/FnvTm5Vf9z63Cy2TtWDJj78pCAQ7amTkd5D+DDHlsPXs59hSMRf1Fg8cZOinpO35stb0wDnUC4QdX8xy34LuBiU8I6pDj+LI5Ptzf5v3HqCT8otfno9IHV3vgUT2s8C5whc+ZeUssWWP4STL1fzghP7GGes0Iu1ZtUjUepE+oSIWfsLsA3y5ORv9PAFLt96jT8wRWhMQgFXdf0kECqXomeW6INMLlf8Aqr0m/kl9CAZkqFOjeKt+ANgvJUt2ldhqRv3PJ1+JL64x1MHxJcqm8Lxv/6eSnpSp0JTYR8N5qyAfamLPv4wHC9rmTnp3rQfa5hnRmqX/AWqi5BSqOqwdi0+s4LsqZ4q5o= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/11Iwd8NePoOUtx0QFEWndPYBQH4iHjEfL7jwCwV33TNkh3S4sNGpkKkWZd1?= =?us-ascii?Q?alLehAJqCDFT0gmqeQL+RXWb9v8q7Tz8MOIn+Z5y649amLLkILoX77ptML+y?= =?us-ascii?Q?qRCgQqspgo29kINnWMly0P/7uJ+nmQ4vr12d5fMXZilnk59E8h5Sj06cC5dF?= =?us-ascii?Q?MZ9vLR9LXcpmhvEw92tBanVbzWdA8QKl7u3RjVrunEWxGe5uQXq5CXn4cbxd?= =?us-ascii?Q?ov7KsGrwrcnoMS7t/UMyh5TK9PzmZ/EXj28lF26ymKhahR6IWLtVhr6eFB18?= =?us-ascii?Q?QrLAglfT8U24e9hlA6OPhVCw5hOqwZp8V+6PBkovoGa8KdXGpCEvMuH8WLme?= =?us-ascii?Q?e2GvRRT/Ej9RpAXNdfFLeqWEBoxslmRq+byCfomccMgmvQR7Xz/0Dz1/Bm2H?= =?us-ascii?Q?a8P2sL8VUZU8zQJ/C1t23uRaX1BthILksia4JVhCDCPxWEkdnuIPrTGZYkUM?= =?us-ascii?Q?jVgXQY92drxRENIRTeLlcsLGTWiiODkr8Nphazj/BwpY7dQZaW7CjgUekxm9?= =?us-ascii?Q?ySbwN+YnOhcN9jgR7Ssu583olKrqIn1rQCWeKgth0e36LprsOoY0fNFFvJxf?= =?us-ascii?Q?xTrRBvATqwCZWT4XNwgwJOtRe2VBjN4JyhnSKCbZZjJzv5b/pICEWJS56JvB?= =?us-ascii?Q?zgdGcCCnl3/xTY4vdh7c+nLUie+aeid6NffEiM0eOgvpyjhbbZb1a9+m7Q9V?= =?us-ascii?Q?0o6OoHPoN3Y8DsjOJHHmLEZIUcVmjMdKZXtDenuW4BgBQGVck8w4NpZZ/nfD?= =?us-ascii?Q?GSHQke1zc0bj8V/jcxuy4kNzkI7rwUA7pXCh/5cCxGugVf7q7oZ3j5hgydi5?= =?us-ascii?Q?2vGL+3QUY+ZCQxcisy+zWicJBxgMkKjUXaqVCIrqJJZK24NiF8t8YDPCPklo?= =?us-ascii?Q?MFUurfJkHwAOX9Pl5us60v756LYoOvgpIZNw/5BHB2ONY7Tcv5j86cgDUHR3?= =?us-ascii?Q?lyvqxMI4L7RYyMguF5ohCqu7EUfiz2IkzJC3V1SLPjExp965UzMhAYxQ4XkP?= =?us-ascii?Q?07/ohivgAu9CRvTvlRv0w1C8Zz7Yfw8ZR+5GadUuh3LCfdvFHGNq6ZlJwtdc?= =?us-ascii?Q?iiuj0CELKIXiQkbrIpwqEKcz8cxFTxOum5mimqMqcPUJLkdKWHf/+rcdU4jJ?= =?us-ascii?Q?zWm1+1nE4/VbP5zG19c/phZj5N3dCQ0dWzmwaUvoMrqGEDDS5zinnXReaisM?= =?us-ascii?Q?uqZDToh2Yd7q09xDdFdVfoGAONrTLVext0fG8YUECKd0il4W38D7XabMP2Kp?= =?us-ascii?Q?enCAcH8sjkg2o9uNX3JA1RHiZLlWPzxg94pvCZiZ7ySfTkSzJjF7FXZ6a6LO?= =?us-ascii?Q?wKjluxmcIhK6f/+bmgOdBhI3VkD6DcKGIAo3PhdnEbZug3FbHeU/m9BH5W2B?= =?us-ascii?Q?gnhjI47ZXUieXIaNYgWzg4jvx1sVxxtsj5adcmDSnotaGiaX/WlL8vfHZH3S?= =?us-ascii?Q?SiTnZcdNRwdUmPibHH4YRfhNoHNcQfDzpJ3k04qtYgIS9RzdQ0A15cGC3g3P?= =?us-ascii?Q?cHh93pfKFAyEs921bJTg2tQ5Jlk+tUIarBc7kEwFnFDwc9+2YdsEnQxqXn2U?= =?us-ascii?Q?j+sxJ623XMSlFXimJiO0azLhjKTfB1Ca8G/npgqSQ5mHgGbe4HkIG2cmjKp4?= =?us-ascii?Q?IshruQlkq4RS9WQ3RTjqpxPR7HiI8buwetrSqqJTY/n26NxZfocRrLwbRVJw?= =?us-ascii?Q?mCJDCJtZYUOQIYEolY5OdmfAkufFGgKi4w5Z/W9JsRmtAIqGk2fNEBDLQ9zi?= =?us-ascii?Q?qCTG8A/CnWpoNzMzy7Yjx/NQZeUgNpo=3D?= X-Exchange-RoutingPolicyChecked: xkC7VepcR6NLCgyuIsbZYg3STBiuU4YbGSZDXNqxLrdgZcHVILD94rbTqCMHgR3yT+j/Tx/5e/nsuVviLO4gBGYeHu+atvCmUxayEcXpHIHxb/R48AS+cFg+tqm+X9qFZfp6TIAoy+ZcWE6WvwmhwMqMaSn2lQyhDPCSevZHOgnhYFpUASTX+GLK1wXG6Ls8y3LsW+kKgj7U/FN7ZRT+gRmMANsyH5ObQeb4eKR3tX9AGwGxEP+HLg1GqjlKPcbr6gPlCoWJqJ9k7J2/iVWL0GmEFCsaUNykw4hNvq56gmsk6NHoOJfeKUERI9a30qfCJor8z7t64Eaw1zRnfF53zQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b7f2c11-d811-49dd-fa38-08df2b90b1c3 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:20:56.8698 (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: Fqiy9Hf/UQwpDJouxNQwX6mLOohfndE/LCQXvVTLrx6AL9ntPfh8YAojms3Q0J8LZTuImQSnocX7LvdMTc9gVa8rb4kTvp1wt1+dpcqVxE8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-ORIG-GUID: bv-vv57VaUbVt5VsAORtPjcAszYEGDPv X-Proofpoint-GUID: bv-vv57VaUbVt5VsAORtPjcAszYEGDPv X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX6KLEHSq4fgdX LgM0nFwxOUvJjC+kVA4XLJQVViT147ljYYZ58SvoKiKYZN1t7R0PwlF2a19TQqVId7/wapEepPZ HsAeFkVEqZdLy6yg/DBNsKniYdfvKwuh+aHfr5lHkGupmVlUxcEfJWFQNBsNn9inDsrD4nBHKKl 6A+c8/T5hdteRbb4CLjKDa/gAr816mSVS8/56o+8nWB0wFeKVP36N5vt7FhCjCNJH0vi1sM4ZXA IhRtDPcZ4OIqchdefZUvuH3CnAct0TlpZjoyCgxBMqiDh9syJYfcb5t7dVokMHmS0Ww6aIs5nhv LMFEEaYoFwIeUAgW42UV2aQBHxm9Hyke1Bv+PrZyDAAtDzQPPwz9g2x01cycCYOBJBFFrbRv1hU 9mKt67NhfZSGl/PVF91yioTFbLwuake6ZBrFwNxFOCs/8FnrLwH9fwEeLWWH5aEtEfoeBLCXqmE XjJh5OjTW/PcwKYlt2w== X-Authority-Analysis: v=2.4 cv=V/ToQuni c=1 sm=1 tr=0 ts=6ad232ca cx=c_pps a=qT2ADiACooojDGKohgXUBA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=VZfxMas_8fVelDOVPvQA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX3IgsO0r50NJf cJdwP/Soo9Jh3cArSnNbNAVxNZPsJslTfYPliElJ1rzOCWb2Kfx1qzPxWoR4RjhzsYm8VJP9DXI LsbOlfhP6CuvPgPLdZuBX6Oa7nmD0jw= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792160463-CC37587B-F1FE5293/0/0 X-purgate-type: clean X-purgate-size: 2287 This is in preparation for its use within a QOM type presenting a single emulated 8259 PIC. Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 547e86c5f4..856075a754 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -35,15 +35,15 @@ /*#define DEBUG_IRQ_LATENCY*/ #define TYPE_I8259 "isa-i8259" -typedef struct PICClass PICClass; -DECLARE_CLASS_CHECKERS(PICClass, PIC, +typedef struct I8259Class I8259Class; +DECLARE_CLASS_CHECKERS(I8259Class, I8259, TYPE_I8259) /** - * PICClass: + * I8259Class: * @parent_realize: The parent's realizefn. */ -struct PICClass { +struct I8259Class { I8259CommonClass parent_class; DeviceRealize parent_realize; @@ -388,7 +388,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); + I8259Class *k = I8259_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, "pic", 2); @@ -398,7 +398,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 +435,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); + I8259Class *k = I8259_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_parent_realize(dc, pic_realize, &k->parent_realize); @@ -447,7 +447,7 @@ static const TypeInfo i8259_info = { .instance_size = sizeof(I8259CommonState), .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, - .class_size = sizeof(PICClass), + .class_size = sizeof(I8259Class), }; static void pic_register_types(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451972.1666830 (Exim 4.92) (envelope-from ) id 1xHio1-0000te-Rg; Fri, 16 Oct 2026 14:21:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451972.1666830; Fri, 16 Oct 2026 14:21: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 1xHio1-0000sr-OG; Fri, 16 Oct 2026 14:21:09 +0000 Received: by outflank-mailman (input) for mailman id 1451972; Fri, 16 Oct 2026 14:21:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHinz-0000bi-Eu for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiny-001Abq-Rp for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:06 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232c8-bab6-0a2a0a5309dd-0a2a450cb32c-46 for ; Fri, 16 Oct 2026 16:21:06 +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 6ad232d1-f479-0a2a450c0019-94a39b0cd23e-3 for ; Fri, 16 Oct 2026 16:21:06 +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 69GE5C4r3215871; Fri, 16 Oct 2026 07:20:56 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020114.outbound.protection.outlook.com [52.101.85.114]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb045k1ju-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:20:56 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:20: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:20: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=GTsNITGc20yNxz42lJwDN4eLhxBiwmVbhEf4oSGIB NQ=; b=hZ2oksFO8APuCWu3L2f5zZ1k9deAuiZIgapHsDmMrlE8NiTfiIWpPOZQY Ef3fU2tAAmV6E2JwkbxJmJJE7ShhimwmA4VnMkrX/uwMkBagWmMrU4xE8VnKGSmr DhHuilXpwBMdWdY5YHaknc1KqujUUYwzKqoqZ47X/g4cge1BydpOH3yumjKK5l+k t1SMR3H/u+CRqpshdPQITsdT6dB3CFjbu7pKagSdytcLd0yPA/N0F/rKyG3rEhu8 UtOFniK7UyMOQ1Gs16xaftin6XCadW3V5LAQTM/Do1760Lo0HwlJs3/4Uck/55q3 WzIBvUtLhY8r797nkJH+UxHh+avSA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PKEeACrkX44kYQU0dcQ84lGgnuClF8L+IBVBGu2HyzojVWPm4rxhw5xuJZq3g7+INnq/rfHa4E4vHW2zP1kTVkcSS7K6T/HpMyH4qvN4btoLOus8ltFJJg0ydkLe5y281/cc0wA9vQ7KVtBvI1pToQLYLwLxJuI+a5XfsdVVCJ50L4Q3Mupxn94q8gdPbWG6872j7YNmK1ON8yZYGbqi/Fp5cqKRIK2/DbbWXLrNdtivEED4aL5o2mdu66MkQzvJEHGhBVGi0G+eEe4cq0RZMWiODZMmAr8dSoRmja24UQDnxWfmmJdg0Z8CDllmJEoP+RUi34kbqgXX7Ja/Pc4Ctw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GTsNITGc20yNxz42lJwDN4eLhxBiwmVbhEf4oSGIBNQ=; b=dDumQLZ9N6g0CS3d8bPRO3VFZpW2ovNJXvQzJO/83J655w8AZ4gW8ItRZDfHQ28qiTBAnUzmuoiDw7FGH38UBA7v/YTxGqlGYvStYxLIscKFcCeh0psuWgG5CknVxMNBSRIWJtFjyWPpD4IQiEeTs/yJ2yQFiZ7YJl0LAkngwlGfYfMQFnjfuzhQTohHhMdZYj4FedXeFCjpU6fQWPdgYrk22FVg/rS2UkmSeS8gDIrTZjS7xtdHEpxipdMnvCqH9AOxc5f/0l8nGsPFmaPOYNE74cfX/SvO8/d+jFARtxU1wnQ0P82QDTqsC4bIBG7pqxy47DDhofUGKo9LBXottw== 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=GTsNITGc20yNxz42lJwDN4eLhxBiwmVbhEf4oSGIBNQ=; b=UqZsIhjwhwOZkRvhxCcZ86/OIGlVv1lQKzNe/uF5HkqZ6i9AZHwZuPiKWVGSqsg0DbQyR+VybK2ORsg7Q2MoZNO8c8InuSmpJtxcwP8Cjrt5kadZ8w9DeQtFhK7utS/nSRkjNfoAfOcKfsc1ziRbuMmdjxm8WtX6/qfopWGk+9ZXTTXCJ3eMdPKy5Lt99D6l74q/3M5xD10OqCJ1AmUDkYvOh+mngD0rpBiM3eueiUVRZJvyS5anKeixWwAIUXaAniAyuyrxlAIEdY8Kf5bcXc1ZXKR1ZBV9nbBToBqu0R23U9xDPk6pOelGmX2hpss1QkR4nbAMKkRPIqddVkSSuQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 04/27] i8259_internal.h: rename PICCommonClass to I8259CommonClass Date: Fri, 16 Oct 2026 15:19:10 +0100 Message-ID: <20261016142031.1204281-5-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ2PR07CA0003.namprd07.prod.outlook.com (2603:10b6:a03:505::26) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 70f51369-4cc0-490a-d509-08df2b90af86 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: QBuOvyghhHQYhQsGL5CNi6VJxInWJFeEjzSxT7EAlfKW01F3oYDAXk7Qu3j1Xzza7KCwdjbLHDA0FngJe+XqmreGwyJLQ6lMcOb7WkZFq7KLlxj71LnQJIYv3BzX3UVVebhzw6TCuXF4KdDbBXGwKP4XKJnrb+afksWmGJyokFqbmLYXBBahIJhz9qHSZx64KuZD3sQkVNZmtw4QqQKJBL//stfTMZbRtCYLRObFi/GzJGx3KK0R6RLTdXmZsyP+exzFFQYhRZn4SXdP7CvM5CTN6mSDAiwoNVOngNC+YppN9BD0Q6VfqiR539g+QkbMBJWx8pmCJHEtaFbYh5TOBvMJeaSWnqzBRbTV/xYBwTFeOYT6SuNH9tVzmDvPBZSs0jtND3Hu2ObTbnpYPBeP20QuO8XWAkTXgtotYn5wBdwolneHlmrc5Y6GcNnoLSuANr3AXBGZDCt43Fmpr8ruSoUazrcNtQRIGMFQqJbM6m2gCnd9yQlmo1BFUt529Pgd6p8vMNLNAZIOUrZZcRlRmDx4zRKLEpv6+prWZi5YkbHE7Abr4+4BSBU+DiawDYozeKQSpfKHyZ0tH8vue62z0OJO83HtiV5E+Cs2an1l6ez5Yquyqc8MFiKQj0k2n0Dj9KjXoinmmN8gvo5c3LKeTx8mAPFfPvyDX85eeCffkVg= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?43XnQQM6/1C87BLUYWuoOoaLBNR25c0BZAYdAXkBRFof88BPOAml5ddfLYfu?= =?us-ascii?Q?eR2LpBNF9O6kAcmz+CjBoGJH3ek13DJgml1c2YOAP1DyQt/ZphNBxiUferjJ?= =?us-ascii?Q?NnSQ9ULXj9QluNj9DNc9RsE/4SOrgNkB9whWhDGSfE3chovgg4Y/X9Yc0BT+?= =?us-ascii?Q?hD0jg+g6hdTQpYjbTVsQ9DwDGrN25bIx050DUqjQzTf4Cl2kTjV4Pu/tON1s?= =?us-ascii?Q?CE5oT+vLA2mjiUP8zH6GKUEmk9T8BSOgWIhEtBckCHPboRQSMqG8FHH6u5J/?= =?us-ascii?Q?8msoKnaLu+IOgmeoNYCmywYKvIvk7Y35w62/wUqfVtULsy4BeUxDp7G2dbr+?= =?us-ascii?Q?r6ANek/0fVgGMofvwgaXkzYWD2nhrVkjOhscA6xPRki9ZfClf99hHtrNXuek?= =?us-ascii?Q?6Et1IM8RDi6IWbzQsX1WM6UQRogNSxbff0dWsJ9Leae91H1VLWQGYN9GYL7M?= =?us-ascii?Q?diVEY9Fkg5wNk01Gpgr1cVkNjF3fdFENA6adOKfMESznb1UPbVNd2rsPMdw9?= =?us-ascii?Q?kvynp2EIZcE8FPz7FKw7C75FXEOVPY3BEK4P2hgNWMHxoqgqt2v4E/17eqQW?= =?us-ascii?Q?/TcwsP26k8EFxq2mn48g9f8+7kYfBnnr9lLUYhmgnmth4V4HxHoXWs8PZU/X?= =?us-ascii?Q?9SR0clQY6VCMeKileu53Nub5SSygZbP7h/KViUC9ZyjwRqqWxeq+OOeG7+qY?= =?us-ascii?Q?tYdfbAxPNGk4ruB0JVPBEnX1Dsg6KheF028bMivvwkmfrfFOjTC0PCdgTsQJ?= =?us-ascii?Q?JVpLOPIIQGDpXTEgtDws5CNXNfvxacRCFeIkDpzKCBVOQ/4ajSJYeZbsDFYR?= =?us-ascii?Q?yDVte9I2qMkBUFzlNRxT6hvZHCIW+GU0eYw0Rx9/X4FZCSD/mQNlM7P3EgOH?= =?us-ascii?Q?SBiWaqhaJzMMw6XsnuRM9iqpk61HJZMtgchjmgrkeENNxbivboXq5GmNQyHY?= =?us-ascii?Q?+D+I2lh1PLJQqqEtohWT1cKvHMQGkiVSymAofDNUHTDGqF8fNZdua6I0mW2y?= =?us-ascii?Q?hykcRf34chb+/ihTCyFyfXnd4S/rWlevcJ82lH9s0e+HVP6UHVSxMB/wfckc?= =?us-ascii?Q?D4k0VV3+Y1coNyojQR9tDq5fgHaQSCxoJs27YhxMP7N2w8IXynQB66BE1lc3?= =?us-ascii?Q?YqdKsxyZe7/RfrqZxQ3D2ftIKmOHpjO5MqFdm9bC2VYgHNP6sHRdsjaMLARp?= =?us-ascii?Q?PQVbTdJTYJVCPkjSK5wzEPOiP23JKg+NmOvGXOAiSzprNw5aI61naxyui/af?= =?us-ascii?Q?LKSR5EEt3Bv12+MVyzt6cM7aJ327mPmcyJPcQvOA0AFxqTH7DZieR06KrA+x?= =?us-ascii?Q?AtS8DF5OPD9ssw0xvOoYj36hDsLAvS3vXuWy83praN8qbA/cpekye5J/xhNq?= =?us-ascii?Q?uL60WgIBH2wAb76XvCMymYJ4anM2VdCntUpy98o2VkgfQBMe66omNN+uhR9g?= =?us-ascii?Q?s4AvMh3ddPEugUUDcA1cr5PRnCkD2hFP32kFMH1a3PXYC7QXIojBNqFJgVN/?= =?us-ascii?Q?hmJgIQb+LoXxupcGjBYtzZj0mznpOV6KKarJuUHy7BXf0Y3ldY9qT9EGxK4I?= =?us-ascii?Q?6QQr03cQ6NyJ0COiUqFMKVD4xAAl+ARL0bhIL68TdQE2+4Y01zi5zA/JJ0/+?= =?us-ascii?Q?Yp+SYND9OHP7EFDAesyU1yaAk/sMhtj6en4ImXt/WTHuVJzFtSbcFs10UbKI?= =?us-ascii?Q?aZyMrp6/ufJYS/b0jXSf4TE7KsO/IStJG+WH8Ncb4A/NaH7ph8j3+zj2UA9W?= =?us-ascii?Q?0TaNKoVfWwUCOBsJJPkJ2PDOTEOaqq0=3D?= X-Exchange-RoutingPolicyChecked: iwxKzO2JD8ypCN7bl7++cRKTqD/CwLWMwXHVWL8VPw6dfQDml1ycbbTRexWaL2o9AOqIHaatFK/5wbsJJoSAuDN/AOHQXghAB/SduTjoI29uQ5P79q/OVLv/ulvG77qbWnOAjsKbNH6McYtMSP7E2OrFZy8AI+dcdNYr9AAN3Ewp3I17wGCmPzcluhnobsQ7CcRm8QCXZdK2ObWB/sOk45Wev3pJ/i64D56zDNaX+MJeT+p2FaJAq6Xi1/Gyb9MbOaiPKOdTYLaYlXy5sqG0kt6fumLALOXxXRw+/BkAzS0UTVMmG8grEgGeY891zwBuU4T7w0h/rh5hJ2Yi2zvHBQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70f51369-4cc0-490a-d509-08df2b90af86 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:20:53.2877 (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: oW3A3b4UVUpnLilZUn2yhOJFOh4z+ThO3xZfDhriDgXYFpVEm9iKQjYQIo3fwpwkR5W/pMO4dUP+7XtxJcvMPhe3WMpB2BlZF7CRNdSk8II= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-ORIG-GUID: jvWUXxaD_Q9QsNvO7n45Qpegz4tyMhgo X-Proofpoint-GUID: jvWUXxaD_Q9QsNvO7n45Qpegz4tyMhgo X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX5gFwT7wyv44Y 2RH+du6E+zXblrUmRB2oFfAWzMVoNlMruBIw9HEMIhqKbbauq4tsP0UTlJyd91Qdntdi+m8Tgru yy8ee9DuMRjioHSZCtbntI+oHXXqTqPjONfNwMUIx5xmgTRcvt2RFBQSYcfiRZrf+PtKXPPMIwn 2iiYauxBvwYDLvulioSoiwb8tIo20nR2LKXWWbqHajaBHWWGpyC+85lerreAPuJDDSMgWAgWV0Y TsnDTfxQWTexFd8IR5X4K6Qk229MzBB/jSWfnbWHe2tGCT71jRA2uA0bU91waGH1viJcLZCdXO/ ZEeeP7iZigq218sGDQjhSVdxy/0AWjVB2dERYxGcH2pn8EDzQEs7bmtN/Nk6vLJM3DRS0lnXpdM 6vIH8LpPA9BgiW5ycm2VgWQ2nmqdbT0N7HGBPEoQE8vkMo373Ch5O+jwx8Wh32Erk3TT7Qi88iL SPlpHVrMadtsqCgL23g== X-Authority-Analysis: v=2.4 cv=V/ToQuni c=1 sm=1 tr=0 ts=6ad232c8 cx=c_pps a=0Uzpqe5Hikn09oORNzbshA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=qh9Ixq9Ib_qUO60TQ2wA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX3xPpqpxDH2Ku SomnvFHplVFykTh7iX+tT2G2J/Poz+KvgiLvYhPvd+pb3oG0Ng5NylfgOO0znaawVpBeZruUghL s43RsF5Rs3hfgEEkFw7ITK+DS+9TW+M= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1792160466-020C1A5B-C57FC5A3/0/0 X-purgate-type: clean X-purgate-size: 3291 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Fri Oct 16 14:21:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451974.1666839 (Exim 4.92) (envelope-from ) id 1xHio3-00018K-2o; Fri, 16 Oct 2026 14:21:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451974.1666839; Fri, 16 Oct 2026 14:21: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 1xHio2-000187-VU; Fri, 16 Oct 2026 14:21:10 +0000 Received: by outflank-mailman (input) for mailman id 1451974; Fri, 16 Oct 2026 14:21:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHio1-0000sl-Sk for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHio1-00CcOg-9a for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232b9-2eae-0a2a0a5409dd-0a2a450584d0-42 for ; Fri, 16 Oct 2026 16:21:09 +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 6ad232d3-4cb1-0a2a45050019-94a39744a9f8-3 for ; Fri, 16 Oct 2026 16:21:08 +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 69GE5Trn3245884; Fri, 16 Oct 2026 07:21:04 -0700 Received: from mw6pr02cu001.outbound.protection.outlook.com (mail-westus2azon11022077.outbound.protection.outlook.com [52.101.48.77]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4haxj93890-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:03 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:00 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=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=VvBsGWO4glzVmPvokyxe2Nx7Um1RGGQAso/hL5pwN eA=; b=FFg5CeVG+OKgNRMkGA8NQ4mFm0qcmaCJ4HnGoRwj5eEZde7P7+G20fEyU /mWhgUg7gEXT3SLg68G1pFb65F09eCOwr6Qfsz0hHYrw4aFFXsWttGwVoYXrVoBj 1GKkcHS7t169KEm/U+HikJ+lJuR1nLGsStPYN186Ddst8E2jVSLUFR1E1RtzxpPs I6OD5XGmiPWcKxOrgNmVb7nmI1cRqYuj3on9CY7Fdh2WaZ5oNAySsj4Gm00wco/p rrEfVOYfFTRGxSmCsGhoa9hjPv71FJ0R4RlIOTA8SD06WqatifltlR+yq+aSpdZc Jd+zMReC777biFzn1wEUBh8ggC85w== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tKCNWUkoAoZiZKq+siglnFjaXfbpqRYExET0dYXpe9AfAcV1n4N8su4hjs5Amu41KIRR0HxkVfx6cPaOIEnbtsPvZgeIZfnnCSk7LEgbPVywzqOpYdl+ayT3m2zOCDDCxaEcIeKZP1gCMIZ2I+Z+2wBeGt8o3/UAodAXcMqvtGeEbIBDfbR2xOVsFjXKtY2/FtYTDKiwGGMCd+Ml5Po/JOrzJS6DWT/Np16mqL2AoKIgQMQ9becGT+gGphnUg+oLxZQp4QY6+fLO1nm8J0N9IGEzNtkKOQps/iI+BZXUons/iT0h/zArRUtOMpztAjhB0ZcVNbKmyQXTWRBtZCTxPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VvBsGWO4glzVmPvokyxe2Nx7Um1RGGQAso/hL5pwNeA=; b=ZDfzwFPi3CIbDYj7rdZsOBle17mtKbunRbHjtYMCRCJK9+Hw/zhlVior/4dzj/b+6IWGnij4N9ZVZfMm+GKGEhaojxajp9LlQvCGJj82knOTks2ur7iNsWQKDfqxLLBwyk+3h7JYamG79yZR1enWhqKA8rAllLYK5Gftf7BSiIicfdAAERRPGdayM7Ly866fCgOI4b4z+lTmOpPD3YS5FsgrJHOMVv0W2aciw7QXt2GM6oSD9J25XVRYEA/C4TxTaWFg69WQanlkRT13LOamUEdh5htmAezEMf26huYCt3TJUey2U6UL4buqaXWWg3x8l4dNMTp5TT7vndRcZrM47A== 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=VvBsGWO4glzVmPvokyxe2Nx7Um1RGGQAso/hL5pwNeA=; b=qhIsngsoencFWzN7xc9csW9t8OYrNZNe0pW9HBQQYN+1/+j9aNk3lJauF3lEEvF6TUI9dfEp3WT1E20N9KYzsWqDxXnEbu1/Jbt/WqWSnfXY21D6MqqEXS4JU4HgNXPeHLfXe/RXXMqimLUsZNKpubScBg6/0FeVqSBmIiF0NawBxGIvp7qyaOksdsV1h3nIBjbDf6JerFDCFnrl6PhcnBEP+TqnoJunzg+afC0C4bRPS1Wpx9EgyiIfZRh1nhbI5AMK/Lelkb7lNjezFNR9SzbEZYt0rQUbAw8cR5UKrtnbdWVTa0xxfMmJ+YvZU/bi6xvovEu3h9PD8p2DOL3YTQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 06/27] i8259.c: introduce TYPE_I8259 device Date: Fri, 16 Oct 2026 15:19:12 +0100 Message-ID: <20261016142031.1204281-7-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0149.namprd13.prod.outlook.com (2603:10b6:a03:2c6::34) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 7d1b002f-fe0e-45a3-9c86-08df2b90b3de x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|3023799007|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 3GkPqLbrJbMyvJCWksV3LqFG38XBys+LTPXEuPoe2KFgoh2BoOqokxN2pjfc32jGbxr1SHXpvTT93xOjIYDpy67p3fHlhUkwuKZ4DUuGHh0spl56hAsR/EfURNIeP12DXbTX6ueu7uHsQaU5iKSf74uzAHhU9ZCCbRbwMwUaKoefKSl1wPJ7PUPClaHrmfH+g4ZTCz01pGbpdkOHakaoyjB8bPah8AAFbveVw5yiHQ4EjWQbMj+L8mzyK66YGb/klntH7eDB+GC4Q3aWvu4CBwCplbUg6dEKiPS4M2oKk5xSr+09gljzCQSbFhZeJNvGPjH5iPe/3XLoS2qwphpLfOvBxCqDdNlbEkS+URLdAXWRRvgEaDLlyXgUj58caLNo+Dx975pEX9LJQAzVKXo/qg3KbJHkJxIcWC7kW2qHNdtmyJ1fZq5PIjGkMR8RTMUppBQcfB014qj00xBLM28UvyyoaMMgcQWyB8nx3aSiQpWtuY4JsVrDQsD+etXpj6BLfbLgBqJnDnfba0CgKwh5IYzzLCBYj0HlsahCI3c6Lgd1GvgPoWKxssNTQiPw+p2lDl0W7XGPbYSadqBtmSN1qvDcRFpi4+wR4kvVmJO3kQXe6rW5ykPglO3vdgZJcv6DhxeASB1ZvtgdUlLu4IG2Ssjrk8IPuEiq8r6KrmvJh60= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(3023799007)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?QJ5F7sNAs3c5JqTMEVyFYm4LYEo/9iF8sWBPpKgb/xnKlcgaeewPCG4mL3U5?= =?us-ascii?Q?kodXdg0YHxfsPB+N2/RuHkWf8pqDCxwUFF5JMTiCSR0wU3kWX+Xw4sDlgFpN?= =?us-ascii?Q?CHi0PdvSxh4IA1YaqcdmRtDz83aYSI/5mCbiu1Q2Gne91zphqD2FPR0m0Mf9?= =?us-ascii?Q?0Ok0TIFJkR6T0gsMOiey7yzVYjb0L2jYlWkQHt4XfsJlRIn6Ou0QL2mlmKmh?= =?us-ascii?Q?sUlwCNM0DWFMweyvWQKZ08q7ZedL5n9Yc3Nq3u66xZS0+4emxVvsjaKpVfrC?= =?us-ascii?Q?0JiGVBNPp1Rrj4GVPG4ifuxxMZs07QrFdjEVt0m2l1UYnecgYiFjKssadrMs?= =?us-ascii?Q?AQ2xlPDY3BeC+gGhBAmxSR/48Ncq9itekO7mgTtElkoguk+XbnWp8VfGahXL?= =?us-ascii?Q?J75YsZqo2WlW1NmcNIcmAYE0a+s2g1MvaAp1pffej54Xgelc4vFU1CeUsJp5?= =?us-ascii?Q?Es+rURa2puuH7dW36nnj6fwsVfN6/hJ96Zp9pQwal99ZBnTTVsF2QHVhj+yo?= =?us-ascii?Q?f8iz6VUDYsGY+qFMxK6GNjYsb0Pp2SKdYlGQYiaWBYV0YyiIobVueg2uWbKw?= =?us-ascii?Q?1+qKx1mGYOHHSFXUAXveieh+PJOwCwAqGoYCOxPSvLQamRzbBkOSEwk76kRd?= =?us-ascii?Q?MPs7T+LJ3FbvomlTw+no9Ug6U9HZOVdMtwT7K3ohfvzKcZ3OdZrUz+R1YSE8?= =?us-ascii?Q?ZaNUjbwOe9krKnkOwvp33MlulxklPXeulpRzbD/KwawblSoXp7AQQe60aINW?= =?us-ascii?Q?Pne9QzGy96hmKwmUwvcV4jnhWj3NoM3BwR0aJrc5U65xPwOOvBF4d+jKmMuX?= =?us-ascii?Q?ezuxMAW8Uw8mbzy/CpmWoPJ3IaLKQZBOUmrNn4hUqwFA5LPtdHWemiMzMmDn?= =?us-ascii?Q?g8gfGya6PUbSkEO1QAMGYO4/fmF7pbJpEnPXaKcbbK9q/DhB7I/axZPbir8D?= =?us-ascii?Q?IX/lA6xt32/qqKiPjZ+AGd0OpuhAIiNP9f0n2XaePUHu8M6/3jgvUaawVQm+?= =?us-ascii?Q?xgt/G17c+4qRt/t582+bOFgQuQJN4cvyltSKDGldJ+1M7BvskEYOlWrjmbEL?= =?us-ascii?Q?HYueKl6nnbBJ+H4rMyAjsgPDfYh8fkaw+bd3ZSN4UKAMxVHXBTmVfMTs4Cz8?= =?us-ascii?Q?hsVOtSsz58tBr/dfOtgoKlCiqtqOrCfb6Wp/LKdZElVMMZXR8Q3LsKuZ+jtA?= =?us-ascii?Q?uw5bJZdV7zZXOgsHmFxVjZCFCUzB89kuu3lZIhlg0l7bL5xltwpU8uJdYoZG?= =?us-ascii?Q?5wXinSFfs/rD6qZzbmt410KB4XWEhq3D/tQk8o7bv8rHVCQFZjwSJqI/4lAq?= =?us-ascii?Q?piMquyBr7waT/4RFNJ0OwXTnVPTsulu4pSLN9ptppntBVrptF8agOjIcP3Mp?= =?us-ascii?Q?7iA+olLowLS5MJz82nTrlHDfmXOd56LMNS1jTO+Urvg62Km0VGWur4TinY3I?= =?us-ascii?Q?dSV/OzbJpXK9Gewnnn7I7EBokEdo4c2hZNcc6kqmg7lfqHy2EgwEf38ktozu?= =?us-ascii?Q?ZeI8l24zZn0tZZAJL9XfL/nfP3Gp8kbwW0gPOjPjnGKaBuJezL25/ipeY+M9?= =?us-ascii?Q?V0/zfMqVjbrEytfn2qLu5Y7St+Eh567jAjZurWOj9nMpLsFR6sMrhIKY1qc+?= =?us-ascii?Q?KTxXozB6xlduUx6jwzlaeaDY9m0xyBUVnSlfrg3oZ2EAUwuqov4aXCfJbu8g?= =?us-ascii?Q?miF0gBiLiU2DJfII5TVrIXyDH0zJ5fwoFIuff3hYl2lSqHyFoFSuw6ZmCMM8?= =?us-ascii?Q?IA0M7xylpcaGc1CiwTN3VlRMwnPrqoQ=3D?= X-Exchange-RoutingPolicyChecked: qjLX3P5CXEXXlU8Uwz/57+EqPtY4KBL8E++oocg053R5pna1KMQXkeNbS7nolwodKTrbnpG1R3cchwbrh7JMpalJuO3grk6vKJEFjBgmnKciI3BnAiLPtUpS1igIjZ0/QKm8fsY6L1kFw0xjOlBYRkRkQhij6Sr9mB+x++GGoKkrj6PhketIodXDvxgF2wtlhrFJTHCoy3y5j92xtt4afkkC+Qjo4AVqYOytpoXe5Da1UC1x9rUIrDiL1kMm6r+MthSAIGoyvaza63rCCER6LVPDigOT1sER2tW72kwXQOlbnQm6RNYoQRfJtQhbRa5RxZg9GRozDOCrY+kZiv2iRA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d1b002f-fe0e-45a3-9c86-08df2b90b3de X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:00.5139 (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: yhqcFWdzDQb6aRlQ6kAFow20gkf/RPBHVZxncvFbwMVYou7vp9jYTR+gAWsxYWrVek0DUchQSHg6CvuBiMFeGswsKbyAmywxyJE/cm40Vgg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX4qJbuS5FJYjO zSY/FoEPEhFpcV3ct1RRsIlH81IhU2N4tO0faRHZ75ld3ilq6Ma4nbhIuHCWdZDxk1D4TeyrtMt mnruAXTZ1ebQoskZo7ts3HrQaMUJRZo= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXymmzam89rSfM 9dXYgeNB90LA1Akbc8W+1L0sJMagiEPn1kKKmHHzDs7ZyRi/RyAi7knPCwic4+5iScGE3KyLmBb nA65dHbYtutlpegcXw7f16c9Uthsp8v7eu/6ZRo1c+uLlud8ZXnYse1R6ksp7xHlRxvLGkG8ib5 vfsaZb/N3JSrZgz/sxecpKCrP0AkdOjOumqYTQgs+hWJYKGa3IQyNztmOgnWann0627l12VvdKG 6v0duc/LO9y1d4RUWk2I1c3fQzOxmWmvPQJk05k4WsZcHbj4dezqwDt8StrY/x82N7cH9aHkoOu N0YSL5VZLQowisa6OsdwVZRqgCEW0W/U2D/Vyi5jOS5EdRHdPYDekg4/0CZGgR9oPTrEB8VfuED 7mY+5+3y6JW4UNDwsC7Jkxtcxor/3rVyW5etC9DOHez+wsVYTVesV2lyy7HaV2yKnztK6qZEle9 xKCkdxSVDQm8LolOMQQ== X-Proofpoint-ORIG-GUID: Mpch45Wwd0GRJIoTb_E0UajNookbBLbI X-Authority-Analysis: v=2.4 cv=ItOL47/g c=1 sm=1 tr=0 ts=6ad232cf cx=c_pps a=PNgX5FSHJLFuI9i88Gvv6w==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=RO_YwWr2CJXTu7lAkVcA:9 X-Proofpoint-GUID: Mpch45Wwd0GRJIoTb_E0UajNookbBLbI 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c201ff/1792160469-F60AA2A1-666F1589/0/0 X-purgate-type: clean X-purgate-size: 3892 This device represents a single emulated 8259 PIC and its associated class and ensures that we can safely embed the device within a container device. Signed-off-by: Mark Cave-Ayland --- include/hw/intc/i8259.h | 8 ++++---- hw/intc/i8259.c | 33 +++++++++++++++++++-------------- 2 files changed, 23 insertions(+), 18 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index 1921a30371..87ccd55a4d 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -3,9 +3,9 @@ /* i8259.c */ -typedef struct I8259CommonState I8259CommonState; +typedef struct I8259State I8259State; -extern I8259CommonState *isa_pic; +extern I8259State *isa_pic; /* * i8259_init() @@ -16,7 +16,7 @@ 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(I8259State *s); +int pic_read_irq(I8259State *s); #endif diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 856075a754..81827f2734 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -35,9 +35,11 @@ /*#define DEBUG_IRQ_LATENCY*/ #define TYPE_I8259 "isa-i8259" -typedef struct I8259Class I8259Class; -DECLARE_CLASS_CHECKERS(I8259Class, I8259, - TYPE_I8259) +OBJECT_DECLARE_TYPE(I8259State, I8259Class, I8259) + +struct I8259State { + I8259CommonState parent_obj; +}; /** * I8259Class: @@ -52,7 +54,7 @@ struct I8259Class { #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif -I8259CommonState *isa_pic; +I8259State *isa_pic; static I8259CommonState *slave_pic; /* return the highest priority found in mask (highest = smallest @@ -170,11 +172,12 @@ static void pic_intack(I8259CommonState *s, int irq) pic_update_irq(s); } -int pic_read_irq(I8259CommonState *s) +int pic_read_irq(I8259State *s) { + I8259CommonState *cs = I8259_COMMON(s); int irq, intno; - irq = pic_get_irq(s); + irq = pic_get_irq(cs); if (irq >= 0) { int irq2; @@ -187,16 +190,16 @@ int pic_read_irq(I8259CommonState *s) irq2 = 7; } intno = slave_pic->irq_base + irq2; - pic_intack(s, irq); + pic_intack(cs, irq); irq = irq2 + 8; } else { - intno = s->irq_base + irq; - pic_intack(s, irq); + intno = cs->irq_base + irq; + pic_intack(cs, irq); } } else { /* spurious IRQ on host controller */ irq = 7; - intno = s->irq_base + irq; + intno = cs->irq_base + irq; } #ifdef DEBUG_IRQ_LATENCY @@ -348,9 +351,11 @@ static uint64_t pic_ioport_read(void *opaque, hwaddr addr, return ret; } -int pic_get_output(I8259CommonState *s) +int pic_get_output(I8259State *s) { - return (pic_get_irq(s) >= 0); + I8259CommonState *cs = I8259_COMMON(s); + + return (pic_get_irq(cs) >= 0); } static void elcr_ioport_write(void *opaque, hwaddr addr, @@ -418,7 +423,7 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) irq_set[i] = qdev_get_gpio_in(dev, i); } - isa_pic = I8259_COMMON(dev); + isa_pic = I8259(dev); isadev = i8259_init_chip(TYPE_I8259, bus, false); dev = DEVICE(isadev); @@ -444,7 +449,7 @@ static void i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo i8259_info = { .name = TYPE_I8259, - .instance_size = sizeof(I8259CommonState), + .instance_size = sizeof(I8259State), .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, .class_size = sizeof(I8259Class), -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451990.1666847 (Exim 4.92) (envelope-from ) id 1xHioX-0002RD-Ew; Fri, 16 Oct 2026 14:21:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451990.1666847; Fri, 16 Oct 2026 14:21: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 1xHioX-0002R6-BV; Fri, 16 Oct 2026 14:21:41 +0000 Received: by outflank-mailman (input) for mailman id 1451990; Fri, 16 Oct 2026 14:21:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHioV-0002Or-O4 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHioV-008oFu-4I for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:39 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232df-e002-0a2a0a5209dd-0a2a4503ea06-32 for ; Fri, 16 Oct 2026 16:21:39 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad232f1-fae8-0a2a45030019-94a39744955a-3 for ; Fri, 16 Oct 2026 16:21:38 +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 69GE5SsA3051509; Fri, 16 Oct 2026 07:21:32 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021106.outbound.protection.outlook.com [52.101.52.106]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb7t19qru-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:32 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:30 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14: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=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=+oPkk2OhFpF/vtiHULlP+3P3BHO9YE69TRweo9UeO 9w=; b=nVHU/uZ/k6wzYeUzzKAhspVyR3gH4w8BxIgzOKadhg8ChwS5mHSCnAl79 MBQzKRDJMljEaBRYQ5gnUuwAHrLMbFzbPrFkefN0cg3NjdB+/9SfECp0cOpUNOM6 1OYt1UQZsFIQTvIpIrwdDTW9V7ASUY3BrhRxyzrQUP6WSqN4V+JaQs/ve3cIrhxD WnbNFhvQfNZXwzlppbczZVjU0vNTHhjPGggTVOxVklk/PKDSsnfu11R/CxrY72K+ wApPIZP6G8xJVkR3se+w5mD/i5cURAlLCoC/tDDm3dt923cLlhr7PlPeBgQvrbx3 qx40B8eOR2RCL2Aq7oVv5FolMjEDg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iHL4fRp+/OINWHJ2XUxKvMwx6O9MESv/01/vEyRCysHa6edqzgkZelYbuTiJKTDbcq7y6na8dJawDuTqNlnIvhizOn8ZhQ8KgmIuE3o2hEJ5c/T3mmG/WjaAqtijhxVvMEDg8yZ+JPfd83rOo441X8WTZs5feZUnF1eDTt60yAFxjf2BX/vTKzyEXF+y2+mqGnFEwZT80opa0nH3/GDpzwOt/P+dDm64Uwgw/0WUiJYrzQerHxM0GPSuUfIESGVbuW8Rn0OZjaTrxS8hpCyWG6E2AzQXj9JX+wihpUi88L8emHa/RxICguGoDlHj/bO7TzbNfwSY4wfdWkn0EEy23w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+oPkk2OhFpF/vtiHULlP+3P3BHO9YE69TRweo9UeO9w=; b=PWdKimvN5PReHp3RmfsZO9ZnFESQ2+HZWUcE9afABrRMAMx8PNmlBCIAtipgCPWylJa62CEUw3o1QHFRP0AhBK8ru4IotgjfLwe3+/lpnxvRPWfgNi5JGYUFnJM7Gxs1zKSrFdXMFM8enxgkyxDV3lQ/lUo8aSmw0D9O2/QXd39r8p0OlaFvJf/Am0C2UHkO3k8/c0Sm4LYwT0mWRFKoWYxptiU03aIBb2lClDvvHmTqSelEwzqa2inaQevlvyZGZxuegAb3T2QrO70bIlGoVuuIDBNznQTMHzfpM9fcBMLI/1Nv7vBG9t6M6Ww+rFI4LbWj9QUcEG2xP+RI3ziQTw== 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=+oPkk2OhFpF/vtiHULlP+3P3BHO9YE69TRweo9UeO9w=; b=UrmfkAlSEZ/mQMaGnQOXNlXd5Q1zXQszRTwXpaBZxn0IHHIrxmUsJA1vtAr46dolDVRYkpRXwzAx6H5x9VhqSbmQqdV5OzsRfYGhT4/Y4LFS+uuH8qSnO7IIu/9Y8obkTNSZHgW6RAw8OrfX6ekKii1delPjgMq5UsXAHQxziCPSxyIVjRW2HBsyPhiSFeGzEEQMMJoH/1/bLrvUJworA0q4RogLGzTTlr5Q17LOGbHi0mV9s10FLyqvIbq9VJDI7eqKMyBQTqcq5rFIdC9ccJ6jClCUDmfESY9tQ1yKR2NCCaxKNio1HA4ICFIHPLZkgASf+kmrONj1INSdNImuAA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 13/27] i8259.c: use i8259 prefix for functions Date: Fri, 16 Oct 2026 15:19:19 +0100 Message-ID: <20261016142031.1204281-14-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY5PR03CA0028.namprd03.prod.outlook.com (2603:10b6:a03:1e0::38) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: 424be368-939f-48db-7e1d-08df2b90c5ab x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|3023799007|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: j1Ex5O91InqcCLfAOdfnZU4BEzrn2pOGdARiJ7M/g0s8Ag6xhSp8ogu2HXCjkL0GuqRjCdMBghPmxhuqS3ARIyaa6+5zKKOCIrJ1lROev3QSovGlC+pxUx/STVyFHWUuFJUvpT1OsZfbm0qCtJGDqN5jxzQ4q4L9WYhXexUB6tKeY5cnh2KUjhVWI3hrASwqpgYe78LDDNddcWLK0n6YLWUGBW8kBq+zKgcCOSFrp2KwtZXw8lfrckVuLFurIlirkXiyqb+cISeqbLsuU4vgivmYm/xxO0W+67HUMHc513dMpvY5MDOcZ/kHbTKPRKs4bFFGIMsR5KVJj6jg5vEsz/KgOyiYFZcd5WRTtJME8iLQMbQfEaTlQYf8vIg3pgucBVxKQD4SVhtfm7i0sPe6LHYx8VI/DU3ri8HQv1jy88ol+a2Q86MyCwRQ6XKT4SFdG4rBwEK/oY6Udfo5wVYVDBBcJrpDuSaxj9u0uNCR4k+STINK/u8TTFLo4rbxl/BhZBIO5zM2uT4UsbQyJTnH1SR2UOeFiXv+kHZDX/Xqcs2y/5e/89+XB+sGGuTg/FuFelE3y5xeKdaV0spvwb5JmqH1uuW1k57CN/qZ+oG9PRbjbqzStCPxF3q2+lG9eOdw2XNrI+qu6lvMRyunp74yIGDGESEB6BQZjua0TPzw9l4= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(3023799007)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bzOPBLTtIwyiMcfg77Cm9s85fmfW2S13q5SsJSA7HOm7GSNb1RNj0dUY2NXI?= =?us-ascii?Q?S7kmVZioK/SHqgzLwHNhsATFVaM5Nd2D5zdqBhTBr00YxPjtudShvMew0Nup?= =?us-ascii?Q?bypuwLBdRmtvjUpkuzf/5P9heVaqVnlEo5ykDFpviTXvmeHsdQrdlg14c8OF?= =?us-ascii?Q?1AG+QGczhLWDD/4ecf2oW4k7hND/t0KDVdy7E6cP6VUyFDqOkjE2Jp648wbk?= =?us-ascii?Q?5PgUSqlWMadv/KVm7rqcbPiq0v3eptQW3srlxx4jeYJE2qq//R4KifQiRph3?= =?us-ascii?Q?oHSo45xOJTEATVQu/ClASG8cKTObpVWGL/ixuYww8b65ji0eTcw2THzv/nDl?= =?us-ascii?Q?+o64H+cwfvt4hO22QNc5DlXQDzdo7eNs2BPpoSzDDXRdCJpDaAB/wT6lz0AC?= =?us-ascii?Q?ODC3spfxwQItFkduPl2e7CwW5q1PojKQNOSIjGJ5BqmDMsdZ2mEd/EUXX+b3?= =?us-ascii?Q?JiLL80Mx4lgTaYggkqH24OXntwFKH29XebfILL6kzsDYkrL0jGHkkNeYBn3d?= =?us-ascii?Q?ypxpLTTeJFXfyJfhkZu3Bf4NJ4KrZWIlN5ACbGPUaoIhoG46sm0ntkjOYPlO?= =?us-ascii?Q?C/EOPdbPJmBCv72hjTyAFpl/bf5AejnNiUsRpXE8sBcmugRJurX0xMQ4WU2Q?= =?us-ascii?Q?Whq/YLeJgWLUH02mdy/LzHTWmleQaB4ZwPcjmZbAmtbvaS6ZFd8Ykioyxjc3?= =?us-ascii?Q?fXyVa1XgAf6/+QJk4olhaZ4GhjCk+bWbzlbPM+uivg0JxKBNyKLuUp1j3KUs?= =?us-ascii?Q?xqOhXxvYc4rtPtKEQOMMZ3e3aQghVX1yEtGxi6hT1S/rmHeGxWXc5YZ/Rpoy?= =?us-ascii?Q?uPV2gFoewyVHiWl6/tH4sYve9luua/FSzony0MlW/WovewNjDsKEbzoeVFdd?= =?us-ascii?Q?RFqXntwAOUKRuM/SKngVWdwMpp3jDSpUaLe5E5hjOky8sZhNQfvteN9dBHZX?= =?us-ascii?Q?QT55ArMnYwrupmIUB+lO2KPwCwPZmQ/uYkVP/Whw5xlzmzZYLZ5d9oOoohaW?= =?us-ascii?Q?kGYN0TnXxB/N8ikDjpIiJkl/uUbzhoSj4cvAWh7aP8PRLuQhM785nAIEv8IV?= =?us-ascii?Q?8q48T4zF361dFaF0ca5w5Hdn9NwhwPChHvXwV5Aht8XrTe3m6Ee/SLgOhlTn?= =?us-ascii?Q?m9VEQ60mg8XOIoMIB1IF56c4E63y4WOD6CAt2hmTeGJbTz/YZTbZYn/4gJTD?= =?us-ascii?Q?lNZB9Y3mmQvbcR11+GLz/Pgre7jwn55C0pQIPKg/ZTvhJbw+irkdoZ4jJMo+?= =?us-ascii?Q?OcuWETkFK+3tUVeF/ENmLcAPdcH+ElBpDkOiZwaIYAbAPxg4M7CddTaDtcwI?= =?us-ascii?Q?ry3FLyt+93n17ZJIImgg1J8jNae4bUlBSPRoOdt3/Ejn3gSuMa7ievSgQMeg?= =?us-ascii?Q?GhfbcCilWoH4eevArMbDSCt6kjPtdqrEN/QGX3JdjDz2DktVJBK/tkgcPPHX?= =?us-ascii?Q?3+3CPYNGdIelkz5Do560R4ZCGuRrzEZpSyq9q3vAsgYqyz5EKClzyerM/FJ+?= =?us-ascii?Q?BWxL5MBMCxJfrZGkxdSJ4ifyf8rfqIuYt1U85RH8P7Xu2+o46qEbWHPMCFzU?= =?us-ascii?Q?6K+7+Eo3qw7gKRQISFO2RC5t4brvMDUm7Hqz1Qyx6kpVgPCkcEGlPfwjEIHb?= =?us-ascii?Q?3AtBolTazzn7IGIlSc54cUMm4MNMNbrzed9JjSBogGOADS4MJK0oLE9e3+Jp?= =?us-ascii?Q?JW6TGZ2r598AhemMLOOuKVRqk+6cH9yfVSm5zfX5UWYOslfqjQnQZ99O24/8?= =?us-ascii?Q?+P5dPu9juhNt6O+EZJPZmqbk8qk+/CU=3D?= X-Exchange-RoutingPolicyChecked: ZTFXE+YVpusadaHtyUigg0DjACaxaNZn+rHOeiozzG2YArW3SNpefYR71kUw+PhiNrjYAxc3ukHkT/fzdCH8hCQg1nf6zNmHXegEpCbcUDPNbMREYmCXNIzhuP9ByUQNywX3OTkewURfM7y7ohbRyifrUc8D2yesygD1o7hQm/YEtI2z7bFZqE4eCicLJu/HfMGxffL65vpalvC1p0KBPujAlyzSfOFBHdVe9kfAoYN5CYrUnHOHrPvu4V13uZB4ldZ12R5BqXWMJZNacGAz4asxy3XEmvz/CiepVCaXf0+hdwduY138Pqm8vf3EfHk0qwdIoxmEOkZrRZeU9N8vag== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 424be368-939f-48db-7e1d-08df2b90c5ab X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:30.4876 (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: bQ+cinOpoF33AbFzib4L3bWxfF14UWZTBSmJ0Yiuzql7kfcK8my6L9j/EHmB+8d49DzZaogJbW6vCgPcqrmDRHLsNUfqvSCE9WQT6RB9jYc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Authority-Analysis: v=2.4 cv=LsYHWXdc c=1 sm=1 tr=0 ts=6ad232ec cx=c_pps a=8AR2Or5FcovIRbB7TUUKGA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=n0Z0T_akzs0uib7mm64A:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXwF9U38xxOIQ3 IUmLvf8WR4oFzzCkPn2xth+5iYhBVTaLNJ7QnDJxeqqRAZNovMrPghDz+wiKoAIwantd5FUTLT5 5un6vuQxhtkEF+RwTntdAtXiTFxvMmc= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXyBgXEhGivSi8 wYdxRL9AfQsEO3A7+YVYYmBkEFf32k1sVdGGEBi7852MEsSNyNOs0LnL9O1OjwnKsBM5Lxrcb9M BNQ+YVpNeVh9LJ1nAsQW2C4f1eBOF2Zd6N33+uLAP32fLUS8rD7Lmm3Syih9rcaUgVcB8pONbnk fDfivFr7xreWVk+jkbAUUm1sxby5Ubtte5A2HtHoa7Hg0WQTsTnW3DRLeo5DzbXZgarSQJ2Svyj pmmNFnyWHiJOz0Kq4uOa69GTf4edzOo6NlL9BwW80lurLmWYHIQtjptj1lUDenKx1myWEWF3VQ3 mHKYcojysKC5j784CKDN9Ii4lyQLE6kfXHja8f/ZHZI6G5kpqbIkK9u1kqs0zZItlnOcgt0Ky2K 2vJU9S/EvtoXe+0zpX/MSl6gZTWhV9bQ6A3OnOv+RTdiu+rsQdHeDWROK8OVnqK830CqArQuu7R TK+g2bU0Bcf0IDVDbmg== X-Proofpoint-ORIG-GUID: MQyD3F78r8y8kcFQafJ-1_OmIYvtdflG X-Proofpoint-GUID: MQyD3F78r8y8kcFQafJ-1_OmIYvtdflG 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-33051d/1792160499-772F54E9-F16CC133/0/0 X-purgate-type: clean X-purgate-size: 11620 This ensures consistency with our normal QOM-based naming convention. Also update the trace event names for those trace events that originate from a single i8259 chip. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/intc/i8259.c | 104 +++++++++++++++++++++---------------------- hw/intc/trace-events | 8 ++-- 2 files changed, 56 insertions(+), 56 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 97ecb77407..4b34e5a649 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -73,8 +73,8 @@ static int get_priority(I8259CommonState *cs, int mask) return priority; } -/* return the pic wanted interrupt. return -1 if none */ -static int pic_get_irq(I8259CommonState *cs) +/* return the i8259 wanted interrupt. return -1 if none */ +static int i8259_get_irq(I8259CommonState *cs) { int mask, cur_priority, priority; @@ -103,13 +103,13 @@ static int pic_get_irq(I8259CommonState *cs) } /* Update INT output. Must be called every time the output may have changed. */ -static void pic_update_irq(I8259CommonState *cs) +static void i8259_update_irq(I8259CommonState *cs) { int irq; - irq = pic_get_irq(cs); + irq = i8259_get_irq(cs); if (irq >= 0) { - trace_pic_update_irq(cs->master, cs->imr, cs->irr, cs->priority_add); + trace_i8259_update_irq(cs->master, cs->imr, cs->irr, cs->priority_add); qemu_irq_raise(cs->int_out[0]); } else { qemu_irq_lower(cs->int_out[0]); @@ -117,13 +117,13 @@ static void pic_update_irq(I8259CommonState *cs) } /* 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 *cs = opaque; int mask = 1 << irq; int irq_index = cs->master ? irq : irq + 8; - trace_pic_set_irq(cs->master, irq, level); + trace_i8259_set_irq(cs->master, irq, level); i8259_stat_update_irq(irq_index, level); #ifdef DEBUG_IRQ_LATENCY @@ -152,11 +152,11 @@ static void pic_set_irq(void *opaque, int irq, int level) cs->last_irr &= ~mask; } } - pic_update_irq(cs); + i8259_update_irq(cs); } /* acknowledge interrupt 'irq' */ -static void pic_intack(I8259CommonState *cs, int irq) +static void i8259_intack(I8259CommonState *cs, int irq) { if (cs->auto_eoi) { if (cs->rotate_on_auto_eoi) { @@ -169,7 +169,7 @@ static void pic_intack(I8259CommonState *cs, int irq) if (!cs->ltim && !(cs->elcr & (1 << irq))) { cs->irr &= ~(1 << irq); } - pic_update_irq(cs); + i8259_update_irq(cs); } int pic_read_irq(I8259State *s) @@ -177,24 +177,24 @@ int pic_read_irq(I8259State *s) I8259CommonState *cs = I8259_COMMON(s); int irq, intno; - irq = pic_get_irq(cs); + irq = i8259_get_irq(cs); 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(cs, irq); + i8259_intack(cs, irq); irq = irq2 + 8; } else { intno = cs->irq_base + irq; - pic_intack(cs, irq); + i8259_intack(cs, irq); } } else { /* spurious IRQ on host controller */ @@ -213,34 +213,34 @@ int pic_read_irq(I8259State *s) return intno; } -static void pic_init_reset(I8259CommonState *cs) +static void i8259_init_reset(I8259CommonState *cs) { i8259_common_reset(cs); - pic_update_irq(cs); + i8259_update_irq(cs); } -static void pic_reset(DeviceState *dev) +static void i8259_reset(DeviceState *dev) { I8259CommonState *cs = I8259_COMMON(dev); cs->elcr = 0; cs->ltim = 0; - pic_init_reset(cs); + i8259_init_reset(cs); } -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 *cs = opaque; uint32_t addr = addr64; uint32_t val = val64; int priority, cmd, irq; - trace_pic_ioport_write(cs->master, addr, val); + trace_i8259_ioport_write(cs->master, addr, val); if (addr == 0) { if (val & 0x10) { - pic_init_reset(cs); + i8259_init_reset(cs); cs->init_state = 1; cs->init4 = val & 1; cs->single_mode = val & 2; @@ -271,23 +271,23 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, if (cmd == 5) { cs->priority_add = (irq + 1) & 7; } - pic_update_irq(cs); + i8259_update_irq(cs); } break; case 3: irq = val & 7; cs->isr &= ~(1 << irq); - pic_update_irq(cs); + i8259_update_irq(cs); break; case 6: cs->priority_add = (val + 1) & 7; - pic_update_irq(cs); + i8259_update_irq(cs); break; case 7: irq = val & 7; cs->isr &= ~(1 << irq); cs->priority_add = (irq + 1) & 7; - pic_update_irq(cs); + i8259_update_irq(cs); break; default: /* no operation */ @@ -299,7 +299,7 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, case 0: /* normal mode */ cs->imr = val; - pic_update_irq(cs); + i8259_update_irq(cs); break; case 1: cs->irq_base = val & 0xf8; @@ -321,16 +321,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 *cs = opaque; int ret; if (cs->poll) { - ret = pic_get_irq(cs); + ret = i8259_get_irq(cs); if (ret >= 0) { - pic_intack(cs, ret); + i8259_intack(cs, ret); ret |= 0x80; } else { ret = 0; @@ -347,7 +347,7 @@ static uint64_t pic_ioport_read(void *opaque, hwaddr addr, ret = cs->imr; } } - trace_pic_ioport_read(cs->master, addr, ret); + trace_i8259_ioport_read(cs->master, addr, ret); return ret; } @@ -355,53 +355,53 @@ int pic_get_output(I8259State *s) { I8259CommonState *cs = I8259_COMMON(s); - return (pic_get_irq(cs) >= 0); + return (i8259_get_irq(cs) >= 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 *cs = opaque; cs->elcr = val & cs->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 *cs = opaque; return cs->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 *cs = I8259_COMMON(dev); I8259Class *k = I8259_GET_CLASS(dev); - memory_region_init_io(&cs->base_io, OBJECT(cs), &pic_base_ioport_ops, cs, + memory_region_init_io(&cs->base_io, OBJECT(cs), &i8259_base_ioport_ops, cs, "pic", 2); - memory_region_init_io(&cs->elcr_io, OBJECT(cs), &pic_elcr_ioport_ops, cs, + memory_region_init_io(&cs->elcr_io, OBJECT(cs), &i8259_elcr_ioport_ops, cs, "elcr", 1); qdev_init_gpio_out(dev, cs->int_out, ARRAY_SIZE(cs->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); } @@ -443,8 +443,8 @@ static void i8259_class_init(ObjectClass *klass, const void *data) I8259Class *k = I8259_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 = { @@ -455,9 +455,9 @@ static const TypeInfo i8259_info = { .class_size = sizeof(I8259Class), }; -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) diff --git a/hw/intc/trace-events b/hw/intc/trace-events index 7512c6e600..003924ddb4 100644 --- a/hw/intc/trace-events +++ b/hw/intc/trace-events @@ -1,11 +1,11 @@ # See docs/devel/tracing.rst for syntax documentation. # i8259.c -pic_update_irq(bool master, uint8_t imr, uint8_t irr, uint8_t padd) "master %d imr %"PRIu8" irr %"PRIu8" padd %"PRIu8 -pic_set_irq(bool master, int irq, int level) "master %d irq %d level %d" +i8259_update_irq(bool master, uint8_t imr, uint8_t irr, uint8_t padd) "master %d imr %"PRIu8" irr %"PRIu8" padd %"PRIu8 +i8259_set_irq(bool master, int irq, int level) "master %d irq %d level %d" +i8259_ioport_write(bool master, uint64_t addr, uint64_t val) "master %d addr 0x%"PRIx64" val 0x%"PRIx64 +i8259_ioport_read(bool master, uint64_t addr, int val) "master %d addr 0x%"PRIx64" val 0x%x" pic_interrupt(int irq, int intno) "irq %d intno %d" -pic_ioport_write(bool master, uint64_t addr, uint64_t val) "master %d addr 0x%"PRIx64" val 0x%"PRIx64 -pic_ioport_read(bool master, uint64_t addr, int val) "master %d addr 0x%"PRIx64" val 0x%x" # apic_common.c cpu_set_apic_base(uint64_t val) "0x%016"PRIx64 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451992.1666857 (Exim 4.92) (envelope-from ) id 1xHiod-0002pU-Mt; Fri, 16 Oct 2026 14:21:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451992.1666857; Fri, 16 Oct 2026 14:21: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 1xHiod-0002pN-J2; Fri, 16 Oct 2026 14:21:47 +0000 Received: by outflank-mailman (input) for mailman id 1451992; Fri, 16 Oct 2026 14:21:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiob-0002lO-Rk for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiob-00CcVT-85 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:45 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232ed-2eae-0a2a0a5409dd-0a2a4504ac90-34 for ; Fri, 16 Oct 2026 16:21:45 +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 6ad232f7-b57f-0a2a45040019-94a39b0c1980-3 for ; Fri, 16 Oct 2026 16:21:44 +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 69GE5MkL3333363; Fri, 16 Oct 2026 07:21:40 -0700 Received: from bn1pr04cu002.outbound.protection.outlook.com (mail-eastus2azon11020117.outbound.protection.outlook.com [52.101.56.117]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4haukukqdw-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:40 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=po3EEb9dG7/G0E+Na053cQN8h6xsnwFa0pjZGUjYe P8=; b=2jJAEPWMQRMdu3qolB1cjaxR+nOoo3Gh2CW0UE04Sm1XpwuH1L/dzEzzZ VSq0I/f5G5K13pttOGF/zoehiMcVwlyiPkh8GvVdQHKKV2NiqYct73WM5Pi6gi1Z 5SdZpF5wta9Jt0nBz2uvW/xcSv3+5lS3Nsc6+7+wh5FS4Iy46WQx1dsyNw6i/prG NgUWCdzyib7fEIqMymPYSwpOQ8ZXYxPdqfYIlm44muzv+kEMYpar3sDRjo6DNDug Pe1JkhnhLTE5Dv0CddL50nDw79ANNtrrmwAOfdXa/6ZuOL+APwwfLjLOJ+4fMCq6 JRWYfDU2LmpMetEZ1QIzcOqNVYfRg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QnvJlJFctGcQvO8cl6uWOJoAuobKE1xLc7mQeVPIxqY9jdwDUnigBwUfr/c0nKzV1fYGqnvxoyQZQ0K/q0tFPXxwjdRChgNJmIpSltAmAIDMNcYOscWzCj8MPOlcbAAGWoacLU2GVPrsUci/s4piMgUmNtDS/c7exmTdFosbpfNUTbAGSz7QKJikI4b2uixRRIrI0mU1+cxJ460zw56e7rCeABxPFPpJ4zEOiicZhl9NxA1rJbfZKaylFBsJSHAmfHzvj3C3a8NpW/+Ho58V56dXSrBHIbndQXR22c4xwnoTt0UYqvjJoko88RcXHF/qujlOkzZulXEoL6RMfTiSEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=po3EEb9dG7/G0E+Na053cQN8h6xsnwFa0pjZGUjYeP8=; b=iOc0FgQFXy5c/hXaoZzsiAXzx25XGFZG9fH6WB5ocRUZlBUN8FGcm1sZ2ZB87AKhASg1AcxuBSr88s5XPFoQySDfXF/WhfT3LnjQzlQUPRSWHtnL56CfIPbZEiLOoigOS+U4HiRap+IesJLT5VC1p13WMpGDQEH6ZgJeql5+5ED4VLGw5soyMH5Gv2IXzpPEGyeYeZsLBW0Nn1Ni+LIaGZ0lU6s+GXGkVSL5jmsYscfXsjSy4zun+ACcABRpRjc/7Y8cHFQO22lGGpaxBh9DVCfwkPImKKZdPgiE2ciFSrq8e1vD7gRnIlk58sw050mzLEH2R9tDHsAwk+yjYIbTjw== 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=po3EEb9dG7/G0E+Na053cQN8h6xsnwFa0pjZGUjYeP8=; b=sziSnpcLOUroF99ADTaVORq+z5sMZNBaRHxHDh0/p78Xd02LC5lPS9asEykgvc+EiI/r01zNjVMTzqyfczZfCIXzv36uyjt1xJ/WbH9EDRjhgBRqEKcmWLSfHtRGjZT0B4vpZ0k85tTdW2TCGTDRYoqnodXprALjwBO2TWi8d8s1x/Nah+Sx/+Pbla91hcz8wpH5iUZ5fyInnv1m7JR3smbHlShix9rpQMdAEe6psvgTu36KrQijCV2zl+U0Cm4QHQ+kzIlUtPpu7N50wCVcd0rc4Jp1A0+9Y1pe+xjN5CI8JjkDS3Enuhggd2110dvDH6YJhwWT0iaUlRr4H9WSMw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 15/27] i8259_common.c: convert to use DEFINE_TYPES() macro Date: Fri, 16 Oct 2026 15:19:21 +0100 Message-ID: <20261016142031.1204281-16-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0204.namprd13.prod.outlook.com (2603:10b6:a03:2c3::29) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: 476986ab-4b69-46fd-9f13-08df2b90cacb x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: kUXsU9uCBiee/u9yUypQJojr5dhQDxPRfDbnxbj581f0/R0bqlSPj7F9wJ3A7Hy8WLF4pIOWpf72fkVibc77sWxrGUmhH8I+RV9qug0+aM7TqFFlGwZEkeOh7Shj5LT0do239gaL5/Ydpf5tbcEQOeFkwFrtKosBt30DJ3Ja0sLCMbU5VGRAL/9HLjmMQkifUEldeCFrQmD+apIMWyNF03pCVCwKOUsdmzHpUum606N9AvxoO7n17QDo1r2/d2zPUwjy9q18RN3ItNdvuJV90i1qdbByd/50JPkRNDbdbIF/0ffTOF1RwdKyYhc6udi1fao4UOwGEtVlVkTS2Rw2UKt7T4KlUlWhLhabzfPj8XhQY2x6h91cnh3uo25Sm+JCkUtjN8NR39R/PkhZ2kxoCiKRm9nvQEgS2brIHSRKpfRuIuHC4wRSWxH7Tp9+1ED0f+aO1R6UNDCkH7h27vytOz0mJdmJQv0QZ0xw31mNpS0FDEqp28NKgPMxFbsmaxvbwW1bOgziZqnzh7VFZpMBgK320jO2WgF1ilclUrVQNiMgOyNO+tYUxDS7304f0a6DJrCbBZkQltqgibSXTZRRBP0Xnx8WxyOomov3RAEPyShZmM5/jnKMdm/gXH6Nr1RSFHRVUXAOTUiMzxVsMAbLM9p7A90R/OwJ2H6k5wm8HSU= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wdef5kK/dG0+2rn/O+kxgYfd5djpgLaQb0qIvOJ9zzAYA48TsviJePyLXqDl?= =?us-ascii?Q?yft1Xs3dXZUw3KtWylK4UAMCBcdobYZMvDqohHJayX3dsZXGglpA/SjWhHUc?= =?us-ascii?Q?GOHD6g7BsVz+Bxoj0r6k6oyFGbtY8roM4HWXWwkKzvBty/BhrTTO9CSetYr3?= =?us-ascii?Q?J1NPST35SgE3Vtn3tbBO08VNibRrWJzEskFCWmsV3bRb59yHT5Qr5H8HHiJ6?= =?us-ascii?Q?7S/gVDIeUxZzYiAkUhYXoeXaqwe4tHBX/+M1Qg6/EZO6MdkP+Zt6NU7hGbbD?= =?us-ascii?Q?VTdNL7IuTWzebkG5PxYW0y/Fy/NipL3ygXZSpu0VznQDl+HFJhpv+RiVB40r?= =?us-ascii?Q?1j+XK9Mqn+X9SGeil/gPpx9StQJB716dNoQW6X9m/Q+1LHLrahjTaNCksYjf?= =?us-ascii?Q?AboD2EbgvWSD/O9Rynv2NF8uFzBAWLeSqOl+JLT1Qf1j+99uJTJZ/qcrySSm?= =?us-ascii?Q?Iq0TSxOqaQuVzTpAWfJWrX+Tv0qd3OFv6ZRjx5sAaCyuz736dSgefWzKvLWs?= =?us-ascii?Q?Ws3E3ku9pT0DwSa3wZWZSVOctgccNbaCwnz1IZd3/5ZV/NbEiYrsX73TU3uJ?= =?us-ascii?Q?V+bTXHygpZZYD73108a0KVlA79jlLxTKS9PMcmT3bzN0Fs+Vh+ZVMx8Yt7gU?= =?us-ascii?Q?ZScz8d1eZthnKZ3+qzmPajd9PdSHNAlg8ZYpo4iaEqtu4sE8NrCtsm1oe4ei?= =?us-ascii?Q?hxKMr9dE7FK1vknqhQsshtSmh6NZv5YY4dOMl5ARJlCQM7kRC5rRrOQ9dz2I?= =?us-ascii?Q?772rsNIqVCjKDINbEYgoMl9c14oJ+9etc2YvyTwkXNUzpdqEjF6Q0xCSgHkR?= =?us-ascii?Q?U0dsVuRWGIGy1PsC4gXydNwAufKAyDIn2qnl66mFrQZ2VnGu2h13cpLmGnDV?= =?us-ascii?Q?p0hktMaEaDIrulhubmwRzM8wPjS5aMBzsF5dSbWs6YCeBFBtS/w+OYicLm2Y?= =?us-ascii?Q?NEUkPGeswETByCwfQJukZgB14SQWn4bpDqWSif2y5oghYcrdT0cKzmJs0ruw?= =?us-ascii?Q?+KJMoXbAp0IWk59hmpE4u+7Sh2Ya0pHFJUMbrk9jTH8BK9Vnn+ZXv2/cu22u?= =?us-ascii?Q?o/tCyN4iuLzWxJg5eKqGQNiBkQgYbJzGl3h6KSInjLwSPIAyM1BkvA3zYt/m?= =?us-ascii?Q?5Rwi3ghkYPYaEepE4/EV46qynofwTjDU9X/fGl5Kp/LFFnW4oq1JwItRjfZ4?= =?us-ascii?Q?J+90L5WAZ/usbNQkWTKRONis/mDsNSM8DY1A4sCs4bJESjmpWOvqgJkacWVt?= =?us-ascii?Q?1W8wLrFHKX9rl9XtNFbzgDS8CVfSdiPPzc0xvESPAjbFhqHn6o0UENZLDYyC?= =?us-ascii?Q?VDuil25XxE1zShSIT6gZRa8Fs35neleQq00leD6xlblRWBEH4ozimuwt3Fna?= =?us-ascii?Q?7s+NELzofG144BmQapZlyoKVTkPSJBMPr4y6KDSY1h019gTWVhdK0jsygA0a?= =?us-ascii?Q?YHmZnK7o7gmSWW081iTbif3Mu9JWKIT5GH2BuQfHuCdBRJxbSAPHM8c6oivC?= =?us-ascii?Q?0TGnBBCHbD9Op9jZCMK3aHt2kQtYdmHWoacp8IdPrFzgm/uDYDuhY4CxufUj?= =?us-ascii?Q?KwQpqY2x8uV2jCcLlcSSHsMp4X1NwqtwhutIVrZekJsrSlYU0gmwPTfKNh5Z?= =?us-ascii?Q?I5nhTQLBgaT/UgKYgbDhPNYJVLEZioWjgaNjMwzQq42BPaPnU8j6zOxa04S0?= =?us-ascii?Q?JEnTB2O6t0kAYtauBH4lwRT0iv1CQw99yTCm9GRB/s8zTNOH23a9eTDQBmqg?= =?us-ascii?Q?ReMeHs3fS/8HLYFhl+8fHRqgkn4yiTw=3D?= X-Exchange-RoutingPolicyChecked: oXKv5Ad3xuW1lHiWcGbKAa7M+f+qQeQH5OWe2ETqebJEtjDfvGu/UoaI6U4M4QCCLvcLqQ7EcKJB9vJd3Q2ImVRyeN8jzEoGvHff9njJNYXuaz+dxNV582EG0nQnUUOPBvVXbE+z1a6uTxEUpO2/WZdlmQirvtYcdrBZQcsHWl3d2TtmeTRZU9Yq8i+GsevtNeRMNOVxVAFsBCErv6YUQDWR0c2s2uXrHg0xMsgFoBNCP8Av0rBbj2zYNmDYrzFsSEJftUAmptn4CsR34YMTz5a4ErUuF72ZkthfpPitug54W0oZ4HF0LQccI4M+H/giOE7XBBnsdGUI7e9rDBJNhA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 476986ab-4b69-46fd-9f13-08df2b90cacb X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:38.8585 (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: GvOtc1kbvibCdr/61CNNwIPrFakpYVwe1pXOX1hcGLXdRI2a7qeYEWZFES8s8TozCH/9okryVk5ECGWLgaLhFd9kjWUAwoVopoQbRP0sOjU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX6bSPqhh2e87O UbzdbsN8qYh2y5/IqMAedm9wl1qZhgfxCPjC4baXRFf4dtu8ocVDeSnNJcgZHPouGU4cBw6QGYM LmyqGMYncHf1QrR63WHTzQ4gA8nCDTM= X-Authority-Analysis: v=2.4 cv=G+OJgNk5 c=1 sm=1 tr=0 ts=6ad232f4 cx=c_pps a=v6Z6meDQFn3ji2zknzBGMg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=bPck6Z4TT5Um9jj7BtEA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-GUID: ePNY4L1EQ_7rW3CuPYUeBCEX-HIJAeOU X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX070aBJZGe0w/ VCE5/KUF7DyzpieCvcRSV0GaLhRMW54g3bTWCmv5S2BvmAvbo9ttuJ4KKPGDKuZHyfekk1jezhM WO7MD8wIoC0qzWZqJaJQzLrI73kG6lo/ap4rKDXsp6+zdGb29WsOP23FJ6IV4OyO2H8G6yzkXS7 m1wWTuALFiQR9FCzTEN9o/ZKLktipzj968uz+yNBNiczg5oZRPXCBaVvZDoq3RySQSEDzQXbLQ+ jNEE+dx2SULy8JXqy85amkbYV0rRhu+2eC7IHBazLbwXfsbz9tEhJFDOUjMqWmuP9bo6K4QaYEr ntiJJ+8P8ILsXnDkFfO269BS69k/N4R3xhnf4AEX+DdYU/Ns8a/xuCrMjwVbmSQX+2KXzmq8h7O Tng56Vouq4wCYOLXT3FO2VQHaYtF97KYWEM8UQFyTQTUmPjfz84bBAnz3nD+ZLzCsAkfjyzzubS 8q232Lh/pLJ5QRV8+Ig== X-Proofpoint-ORIG-GUID: ePNY4L1EQ_7rW3CuPYUeBCEX-HIJAeOU 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792160505-C18D1B50-017E886F/0/0 X-purgate-type: clean X-purgate-size: 1595 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 31bd663439..09b761321a 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 Fri Oct 16 14:21:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451994.1666861 (Exim 4.92) (envelope-from ) id 1xHiod-0002s7-V3; Fri, 16 Oct 2026 14:21:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451994.1666861; Fri, 16 Oct 2026 14:21: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 1xHiod-0002rs-Qf; Fri, 16 Oct 2026 14:21:47 +0000 Received: by outflank-mailman (input) for mailman id 1451994; Fri, 16 Oct 2026 14:21:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHioc-0002le-7O for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiob-008oLT-KL for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:45 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232c8-8faa-0a2a0a5109dd-0a2a4508cb9e-22 for ; Fri, 16 Oct 2026 16:21:45 +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 6ad232f7-f659-0a2a45080019-94a39744f4b2-3 for ; Fri, 16 Oct 2026 16:21:45 +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 69GE60JU3247562; Fri, 16 Oct 2026 07:21:24 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021116.outbound.protection.outlook.com [52.101.52.116]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4haxj9389v-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:24 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:22 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=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=dsWOAxmohqRbnu8OIkKy3L5qtCU9Q47z4B6UIej1I lQ=; b=AfdKqOJTyzjIGYdIFwPAFG2Xi4UmhJE7JndCg+BzuwLe7aEZGoTbZdlYT U6tniKyQOnN6pIswCNok4bjy4X+lBcJm1uPk6qzVcraSjS7tdbA1zi/1hJFqud79 TyaJ6BjDeZIpoUndMV/UyWRcvGbzJxu8kpHa3vdn3sFgBN3Bs41Fec8TVK8CVvtJ z9Ksh/FarBYNVqEpdWV9G665L26ivP9QQAYBvstYdvvBJb7F51TdmXN23hYC9i06 LaC3uyl53VjCgg/YwwUtZlMTknQGgvdocZ3iLizKxjtw6B7BWI5aD1v6E1IableJ ZrbOwpZfHb8+OfxEvOVyFTnu1LN9A== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ISij/P50Ow7LetdTqfgnqY2l0S7UngSeXllVBUKQHxTs4QDl36kuJq993DQfjSI2aX5sd21VDynzcM2XI/WvngAVf0GQl3oBVcwi4frmp8jcY+5ez5601qQly61BoPeSNahm+jKVn3PNkoDLc1D8tJ/g8t/bzIuV7x5qHmGx0p8LzaiSWayBFIQ39nTc4V3FFrlXSAb2UZFS0XV3f4SmOYVKtjInYpiei1Wsx1ls4fhUCefB00wkcZehYxinnzzcIw/9F8Eq4tLrOiNErTbgt2brCkmpBRYlMnQX1fzsZeQIjU6z35SpCtx4DymFNb40lkQZyu+vJKrUsSK8u2yLbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dsWOAxmohqRbnu8OIkKy3L5qtCU9Q47z4B6UIej1IlQ=; b=Vx3xeHk/QJfQ7UwCt9DDHhFuq1AarygssVSzmZxQAKjZKkrbIFzZrtowxp7NSHDPiwouO83kh+7wH1Lx4zctzGwUn8p8I0pQK8fVzxT45dHGEkIaalM2/19oL2SNkon0i7lWZKrFBGYRWReivLxNensHGVtLgILjpyyLKSgqnEpd6wYr2vPQcuZeQ3CakWLWKaIbFQT8YZ/Br6Us+AVUpfu31Ia27LBUpnfZSlQ3ceU/ybwPKhDSYcWRIApkuPa2bQev/nmiLzABL7nfxua0BjsHgLo8kAsdChNTj10lR3l8i6IM5hVp+ywApEGxxAAmEircZTpsuCi/YSNRLW5vEg== 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=dsWOAxmohqRbnu8OIkKy3L5qtCU9Q47z4B6UIej1IlQ=; b=oP7bBQsxDXsiLiOQgJD/Ktqxq2cF7pfMFsFuxjh3FkIYXGcDqmcyzuj8qzSTK5wmXIH8cBXSBt2QXxNERVS8/7Rx7gkAihSmhhLyLMtRq30CJH13IzSMdjXKovRh+SrnjcmkYzmCA9vZyXSGf4nIIJrsygV9MJkmIXVeUN6Fr9n/bo/QzeIznwCrlIy3B0zVGZ14txuq4dnSHbooRtUVHrM9XHfPUhYU3VJkkxiD2leFB3UdQ2KnTJPrreZjlnf2YOjM/+uYefwIzNZqw42V7KMgSd109RHLuu8UP+sSSA/Ku6BiLWKPFrJn3BOCmyTVeERU2YffMARs+NV7iObJsw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 11/27] i8259_common.c: always use cs for I8259CommonState variables Date: Fri, 16 Oct 2026 15:19:17 +0100 Message-ID: <20261016142031.1204281-12-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0131.namprd03.prod.outlook.com (2603:10b6:a03:33c::16) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: 1b07bedf-54ff-4e0a-fa2d-08df2b90c0d1 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: vYZjL7dvl3NX4wgj8lniT8Md1rmbV5fqYKMk+5QdammVoBiipmxVOapI5DbQIPD9GTUxew1h1+GqvWYK74squV3ureRbmLfzARMauLZiMjP89O6vPAZBukRhOyT1CUwmxFAUV8b00K+bf8u1iDXfJSiigKXxuqBSM/s8M6wMovba4qkjtvPLfyFrvikL//YpeNEs+6etv3hY+ZgFr0/yDWV/9yS2NipYdY27K630dINgoLOU7S+5ULsfx12MI+rDgA6YfbljfiPZ7WWxn/8wuerlr2GUblDZMJxGgxyTTgYIrgXS3rHFr8z+AnmP83e1r4mPaZ5SnT7YGCzALCeUZ/Jl0eoDUIuqg3n5Cc0mfbQPeKqFwQ0GoEU0+xhqk2JhuK8LvtzvtcvVCQIiElAXH25tvzjd9OvJudCiVTiSz7I90JnWwPp18F/PUTdlGyzgPVMipfjD2VLXwN9JDZWDUfrcWvbb9wRGmDDH+ZYGkIR2Zt668k3hszM+9ziGD5rVMtxy7gESq3xMu0G9qk8nj2HncsYdz4jrPvDRrY2NMsPWY8Z6s22ZJSQb+nspsxDgHdhlCWFjHhhd8O+a8aQB7r2ti2ZBzwSFmZvC8KFWqBCuHH2yTCI16QF8wqh0RaMnKgVSSr3vCUFZEpLZCAR8FW0wcJS/FbY8O1l4vCdOxic= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/wMVCwbfMV1TvYqYxCZWLwkhGFgoJ0MKtJyntibnAsGaR3PC2PXF7n+fW7I4?= =?us-ascii?Q?LXHJmTPjeKdQNjRYUjVV6x12ZtOKNO0mQ7r53q8DBGPvTqQTMvWhDz7+WMOf?= =?us-ascii?Q?sfStaIkM9+mcKGwhzLlN+RH5kym6R2PxH1NIKk9kGjY71RNRAnXSjZr6d72x?= =?us-ascii?Q?WTKUw5Vxm3eAUlUfOWAWfT4le/vytRGpnIBunHPaepLNuvHfVetruk5Gca7r?= =?us-ascii?Q?+p8b3lQTxlFEPI/kG3hbqY+icPSi8+5H0WV2agR/HXhlUXHMcu6S5czXUMGu?= =?us-ascii?Q?q7BOebhO87jwZ0q98K8C3GjldUWGTyReTm9PzhDRr15dqXdXluszoiV4mmaJ?= =?us-ascii?Q?9GbjI5cTpKuCNBBg9xzFhrf3OToIkoTZHxh1Ku/O5TP87xuaUouRPFtKaqj+?= =?us-ascii?Q?ttvK2jlLmfD1usGXLzgglBWbcITL6SmiI4iwgmlKaOZ9DO1C9GCT5crnTPi7?= =?us-ascii?Q?xRgxHNOlFlnBCLsrslaGWRizPyL47JeiKbi3aU8H6Cl/67NRSfpQwAZOpQIC?= =?us-ascii?Q?IWmt/NoLfX2Od3IgXrx1fEdtH4uqt6dGZ726PTAzQ/u9xjjbqo1VoBNXHZGI?= =?us-ascii?Q?XSce6pJ+nZCyYr2jIdG4r50in/00LSM1y3TBL/2gM1+VD2oypv5qfIvRHHTu?= =?us-ascii?Q?P4UCs4H6VViXrMaR5x/q4CSXag0cqKWfY8nZdgGuCkzd1RaX5HHDZtBfMZmw?= =?us-ascii?Q?1a3/mTEHnhqe2aJsaRksJJZQy+cbss95cmk4wya2DamiweIZPGjiZObGny2u?= =?us-ascii?Q?Um+tuHT71hry2VD5FmHSXz45tpWVgAtB6q6qxIPW4ODeip0BRRU91z0CYZhx?= =?us-ascii?Q?0EfeIAEES3w0P3oCg73NR2aFqmaDuaxxUttef4rRGrWrQcQMH+j80I+tBbeR?= =?us-ascii?Q?sV40Gh8D9J/MjuD14vXns7AhbUndBYzs4aTjjKpHBdDOaFpiUzLVrenurSdz?= =?us-ascii?Q?2ifoi//TXbiutv+YevnKFXsNRigwOqtBaEt8/jGCvTouB7oOsP6nh273dtKi?= =?us-ascii?Q?fOKsiM9uz0kxiaHNWALWsV1Du7sOEgOc9yZSImQxxJ8PudETb5wvXn76+tsQ?= =?us-ascii?Q?CQOy+7tIqLU3tYqm/ekO8s3Gy2EClqzdQVDP9kePvnKJo0FrkJQseMU6tgrN?= =?us-ascii?Q?68EBr+GZjb4m5MgAooaQYqgrVrlmmffjs8DR0Xw+ey+D1ftNXe/9bNy65mT+?= =?us-ascii?Q?iQNN+giiBbWDjrCYpoLS8qMidWqrmEFXOKA6zd/UjH9TjISjrvuzS1QWfwXI?= =?us-ascii?Q?XtvOClPscP2MyAHPEcD52LHTRLnZpXU5e6fPdPTcS6ygWwTmdhd5u4qROo1G?= =?us-ascii?Q?ElgOngil2sQhyBOJ9yoXUPDDTT1v6TEreHBy2NvmJywOLGdbzPnA/7dHBByX?= =?us-ascii?Q?XRxd0dWpIyGCfIKK1x/Xw+fb5MuS+mmnlE7eCqnlnFPk6syLp/B/wLv8T1hN?= =?us-ascii?Q?BQJlVyvsb/AUrZt0ClTThZ0IMpR1xUKSbPMv1PkznmRXPaqTcLAemx83HuFc?= =?us-ascii?Q?nu2o4+zDPa0R5Z0PfwSJRqbaOh464KDRAoa7h/wuD0bXUcjJWZJ8aSAZX9IP?= =?us-ascii?Q?OucuMFSbYqOTVrUOKstdeaT7/TCMSgvBRzi+DsYr2oXk5YMttD01BkAg0/RF?= =?us-ascii?Q?y8bST6VCPnHIwYE+OFwBJ8DJGSXBEfAH+NS9Vj9CZXGgUoHPjoyivoVmTS/I?= =?us-ascii?Q?dBMGvDejRBls3CP57H7a5gUG3FhgY3XeVA3hzIYDureDlyCsZCTN1q/zPmSn?= =?us-ascii?Q?/AxS+Qc8SZVUcw/xuIwD9aCYGsIvOQo=3D?= X-Exchange-RoutingPolicyChecked: cQ70Z37VyagmqNCLYgPAW5hSXjKwLZWTBT6iHIhRvq8gusm84WjcyChirr462s0L9qxuSRmBmpt48N9yRg+sx1qyw7IMPdhUxwt67zeeDpgWe14tvtftnm8iKBKZN2yC1A3O4ewysKMfWJei7s/aFulI45kc32cXXp4ifpp/gTrF4nY58STP3BqhP6fLYRs2b+1BC0X+WWy/9jjR3qtP2bNgafTWAjPRBQt57gxK7upz7CEijKOJbMfySBBa4QKVtdVgEFsryx8dHHjj4fUtmcyfR3Pk60KFn0cTjPKKQ5jO5BPg2QaZqrmE9virWBW1lGm74OxU1pt6aqMxLbhJQw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b07bedf-54ff-4e0a-fa2d-08df2b90c0d1 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:22.3596 (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: VssWmOWAkKQkuzpSL9/aeKqq2z+bVClEJOEUlZjbYivNtdu4XeJ0Wfz+AkXF0KYzlMdOS+LIrmsyQZqOSJnAH4+rkGBOUXT5e+HZ1ebEn60= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX214Jpu7KER7K IVCJ6vs3vorFa6AjXJM7jEVZWpYvQt7taaRPfnnZuQAr70RLWTauuUTEIhuz6aPJ+66mninQg5t aa8nQr3MJ5kKOnG07WV9WpntE0ldUls= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX8V7JcSpRk3of FWn69VnTgmDIUTvnH4NqcVk9uaSjuNnqPZyjlECjzt+GRML6WLEwDxfgw8tgaeScALEPy85ACrU Q+yMKDzV1VK6gVshfHYrtLqy8PXr96cLHisc1IYtLEAcDsXrC/GJG/QALtJo+6XfKWX/EPCMydL HzLGObYK5quOmsRyI4kkkTa7VSvs6uOBMqVdyfI92ogJuY7b6a27ZWy6Kq6yNw8nbkdOzHhYpLw Pq8c5sRzwH8XX7Q63bt/d4tn2NWveyVND+Qz0iavMytETDf4vn/XLJItnqHiew8XEnt6pLM/pDy qhRezVMxvzd+aeIpQ3jKhMWMIf4hfF/fJI36EYrg3KVTM5Crx5Mqwo3TiGJwGA5tWrEWq+WfeP1 /m3oOY/luuv8Rm4b9r0+grrnzMXp7AqHLoWepBYcL0fooFmnVZcvK0kaq2brFxxh0LlS/LUpRAC 4hs+0m6OSET5biSc6Eg== X-Proofpoint-ORIG-GUID: 9BijS6P-u8FfvluJ6mff_JSI0miuWALB X-Authority-Analysis: v=2.4 cv=ItOL47/g c=1 sm=1 tr=0 ts=6ad232e4 cx=c_pps a=LbO2ZyHrMbRaCxC771SosA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=m1qT39pvC01PgN2II3AA:9 X-Proofpoint-GUID: 9BijS6P-u8FfvluJ6mff_JSI0miuWALB 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792160505-CDF4787B-5703AB7C/0/0 X-purgate-type: clean X-purgate-size: 5647 The use of consistent variable names makes it much easier to follow which fields are being accessed from I8259CommonState. Signed-off-by: Mark Cave-Ayland --- include/hw/isa/i8259_internal.h | 6 +-- hw/intc/i8259_common.c | 74 ++++++++++++++++----------------- 2 files changed, 40 insertions(+), 40 deletions(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index e039d6f067..71fdd74266 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -37,8 +37,8 @@ OBJECT_DECLARE_TYPE(I8259CommonState, I8259CommonClass, I8259_COMMON) struct I8259CommonClass { DeviceClass parent_class; - void (*pre_save)(I8259CommonState *s); - void (*post_load)(I8259CommonState *s); + void (*pre_save)(I8259CommonState *cs); + void (*post_load)(I8259CommonState *cs); }; struct I8259CommonState { @@ -70,7 +70,7 @@ struct I8259CommonState { MemoryRegion elcr_io; }; -void pic_reset_common(I8259CommonState *s); +void pic_reset_common(I8259CommonState *cs); ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master); void pic_stat_update_irq(int irq, int level); diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index ac8dc7cf00..705a28ecbf 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -33,33 +33,33 @@ static int irq_level[16]; static uint64_t irq_count[16]; -void pic_reset_common(I8259CommonState *s) +void pic_reset_common(I8259CommonState *cs) { - s->last_irr = 0; - s->irr &= s->elcr; - s->imr = 0; - s->isr = 0; - s->priority_add = 0; - s->irq_base = 0; - s->read_reg_select = 0; - s->poll = 0; - s->special_mask = 0; - s->init_state = 0; - s->auto_eoi = 0; - s->rotate_on_auto_eoi = 0; - s->special_fully_nested_mode = 0; - s->init4 = 0; - s->single_mode = 0; + cs->last_irr = 0; + cs->irr &= cs->elcr; + cs->imr = 0; + cs->isr = 0; + cs->priority_add = 0; + cs->irq_base = 0; + cs->read_reg_select = 0; + cs->poll = 0; + cs->special_mask = 0; + cs->init_state = 0; + cs->auto_eoi = 0; + cs->rotate_on_auto_eoi = 0; + cs->special_fully_nested_mode = 0; + cs->init4 = 0; + cs->single_mode = 0; /* Note: ELCR and LTIM are not reset */ } static int pic_dispatch_pre_save(void *opaque) { - I8259CommonState *s = opaque; - I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); + I8259CommonState *cs = opaque; + I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); if (info->pre_save) { - info->pre_save(s); + info->pre_save(cs); } return 0; @@ -67,26 +67,26 @@ static int pic_dispatch_pre_save(void *opaque) static int pic_dispatch_post_load(void *opaque, int version_id) { - I8259CommonState *s = opaque; - I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); + I8259CommonState *cs = opaque; + I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); if (info->post_load) { - info->post_load(s); + info->post_load(cs); } return 0; } static void pic_common_realize(DeviceState *dev, Error **errp) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); ISADevice *isa = ISA_DEVICE(dev); - isa_register_ioport(isa, &s->base_io, s->iobase); - if (s->elcr_addr != -1) { - isa_register_ioport(isa, &s->elcr_io, s->elcr_addr); + isa_register_ioport(isa, &cs->base_io, cs->iobase); + if (cs->elcr_addr != -1) { + isa_register_ioport(isa, &cs->elcr_io, cs->elcr_addr); } - qdev_set_legacy_instance_id(dev, s->iobase, 1); + qdev_set_legacy_instance_id(dev, cs->iobase, 1); } ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master) @@ -118,9 +118,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) { - I8259CommonState *s = I8259_COMMON(obj); + I8259CommonState *cs = I8259_COMMON(obj); - if (s->master) { + if (cs->master) { *irq_counts = irq_count; *nb_irqs = ARRAY_SIZE(irq_count); } else { @@ -133,22 +133,22 @@ static bool pic_get_statistics(InterruptStatsProvider *obj, static void pic_print_info(InterruptStatsProvider *obj, GString *buf) { - I8259CommonState *s = I8259_COMMON(obj); + I8259CommonState *cs = I8259_COMMON(obj); - pic_dispatch_pre_save(s); + pic_dispatch_pre_save(cs); 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, - s->priority_add, - s->irq_base, s->read_reg_select, s->elcr, - s->special_fully_nested_mode); + cs->master ? 0 : 1, cs->irr, cs->imr, cs->isr, + cs->priority_add, + cs->irq_base, cs->read_reg_select, cs->elcr, + cs->special_fully_nested_mode); } static bool ltim_state_needed(void *opaque) { - I8259CommonState *s = I8259_COMMON(opaque); + I8259CommonState *cs = I8259_COMMON(opaque); - return !!s->ltim; + return !!cs->ltim; } static const VMStateDescription vmstate_pic_ltim = { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451996.1666875 (Exim 4.92) (envelope-from ) id 1xHiog-0003Mk-CB; Fri, 16 Oct 2026 14:21:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451996.1666875; Fri, 16 Oct 2026 14:21: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 1xHiog-0003Md-9P; Fri, 16 Oct 2026 14:21:50 +0000 Received: by outflank-mailman (input) for mailman id 1451996; Fri, 16 Oct 2026 14:21:49 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiof-00038p-0D for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHioe-00BWwx-C2 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:48 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232fb-e002-0a2a0a5209dd-0a2a45039348-2 for ; Fri, 16 Oct 2026 16:21:48 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad232fb-fae8-0a2a45030019-94a39b0cd794-3 for ; Fri, 16 Oct 2026 16:21:48 +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 69GE5MK73333355; Fri, 16 Oct 2026 07:21:43 -0700 Received: from dm1pr04cu001.outbound.protection.outlook.com (mail-centralusazon11020128.outbound.protection.outlook.com [52.101.61.128]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4haukukqe3-2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:43 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:09 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=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=NJy3zo1QGJbOmTC9Nz3fMdmhP79c69OYBgxpmQByO zg=; b=0UeB+o5JVvwAIHNsTp/bwwTAtkbmqTIGkcCYXMH2oF1KW+5ZtE601mUbf qMQG/lFr05axS0orvAhw44yQStcy1KGyL5HxlFlAcsFNwHX6w8T0wE5RMpLMayAe 2gE2UwB4bicOnITPntqzbwyuU8PUbwcnm5UhZmA6OdTkPZcIPKvWR7Z3Bo9nUnCm a4T99fSM1vwjE/8beflO3TRDSbZLFOlvnlLqBmDl3fbwPYg04KceFfkOFelcLCxR hcd6Dfpt2qkU7FDyIbDhnGGa3Pz9nzwyOWOCFkLVv1uyzDP/Y47Ea3wPrWBZKF6u BylspXXHToL9ZADKs0+nOdbpQCJUQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MQ3oWxJwhM7Qpk5pMWpgYbfLduSldIv3x8R2T1mkLAyyS6/ikYmLeEp9UbbtmVFaPheDTzcj3XOILtIwr2ovjQvaofWaHS/3H4eaus2CamLxz3uK9wia/pGvbIyJp2+zXTkSc8E/qCkwslyOjy2yo98OFYY4Vr3BYKcAUSF2lG9KUGeZG+5NvdEmT0PSHr66FO3Jv8CNHVj2bmELoMgBz6v0N7fIF08Fb7luIEI2XqU7HymWNgK7duD/hgo6wTzBDoBbEPj1tgQWtnflyrkMDAE9vNGRBqarfUF4LwbVvHfcV8qYX6KeNyacLHFD4Ftt1ti5FfMvjyNioEPfmV0BVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NJy3zo1QGJbOmTC9Nz3fMdmhP79c69OYBgxpmQByOzg=; b=IzG/nmENbPwLD+VoOPjvLEJ0SJ9sH+72O3XIeiqFj7I82dzHBvVwOROi3242f9rYdV8NHQDwChw+CVjMf9vTQD8PdjeqO4XvGGA5FDMgQ+f4exx0byTsyspDHg7KpAi9Xe+G+L9mMHyUiL+5M98FXsl2zQoibOcY/Tw94S0yD9zZUshfgNPJ+Pn93bC6uRoUrOFospOrGr1PXs3d2L1qujYj1p+HmTl5GqbSHFEuK7jA70+UETWeY+TcejYOsKHZfzy45KkUQtqaeNM1bG+Ubmxd+CRhkLUAVgDe7LRhHVAzMM24b2wUV7lednYA9xOmYpjHBMXxygjjgilOaPrI1A== 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=NJy3zo1QGJbOmTC9Nz3fMdmhP79c69OYBgxpmQByOzg=; b=I2iXPb2qdYDyKMraw1+TUbpfz/Vm6rofJmMmNGTihDo4yOzenXaFZQ7wx66auG17++23dChhhLykwcEId/5NlrupudzQVWg7ufPWH22KQX+MnSxklcfPmL0A688oHbHoFa+xYLHj37LnJ+SOETLh3Ib7D00xfYuzFexJgl268mZ38Gyz/IhDmciCyF672jezrlU/QAeWTNVVMpEfnaGTbYqGSDRe31C3iZ7KPskfj5xAzL0x1rUFuNQ6tzsueXXDNqRK/mJEunouaCKVEbltLXIbkz7mZdhVEJIjwIjyuHS0RKp7t8Ek4CD5/BoBow4QnZI0tPZMYNwNzJFcaiaDSQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 08/27] kvm/i8259.c: rename KVMPICClass to KVMI8259Class Date: Fri, 16 Oct 2026 15:19:14 +0100 Message-ID: <20261016142031.1204281-9-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0102.namprd05.prod.outlook.com (2603:10b6:a03:334::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_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 33373cb9-e483-46b1-0bcd-08df2b90b90c x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: dxG6F1OPyUm8vdw1mxIx9MuDKm2OlcMJbI25AM7B9M+3t0Ts+uTzQtoiJjWKT0lMHQap4rhfCMYxUpXMGuzdneGK2lJ0iVN9fJ54xR+W/PBEakxwkzI7cvpOb/2T/4ucWbc+zxUkbQCz3dRx2mq8DwDCVUlkHsP4siJk9TGE0NLXHT/F8S6s4mNF07yhJ+zu5TOAUseD2t1VYwfAtT1EGhdBsQoPcnHaojPAbaVJhbHc1bGuYhT9A5aBMMRN5s1LghuTEFkZmnuUGtifsPD6SWXbWHDwjw51A8dSlnvEis+32eD0d+5dz7Cg1z37u52zWN2nA3VqgCKVqvvro3uIFHLRwKE/x5NgdFy2U8uwuefzvEO6h7kq+OVxDG3s+hpUFIl+AvS3xyPPS185xzwMvgzQVZSbIZOnqbPhGPQFmipRE+JBVOmenm2FjYKdJtmRONNJiCw0s2xP8hRwH7eyQNOzXkhOcVufGBB8iiy8ISDDWmshSHZa2QmO59JHW2ulKjiSzkZNHXlz30cTfhjSLkxIS85z5BPh7r2kATOzXMitMAgvgzI7f7r0aPkLnF85Po6ieXXujWmCxNEfStf/beaoaxWpPKtDoyzpEnxCgzlUmRSN8kW5RXGHPW9rUIdWQWG4sCOAMm2LgqZHRdP0z0z3MucGqerVz9eSEmO1Rc4= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(18002099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?pcDceF1y/RcQWF4yFla/XU/ejOIMte8Prx3wjVSbkdgrgj18mrD+6jdv8CgY?= =?us-ascii?Q?/1JIPFwlRpW6lSX3379JnMSGrhBRXMczeSWmlag1qHEZ3xBzLeZH9iXdx+1m?= =?us-ascii?Q?0qLF0rC1KGS3u+04W+q86UDHTvCO0OZ/JFuiMRp/QH6CrupGzYlCHZXV0PxA?= =?us-ascii?Q?ARMIMTKgsvIsB99UqM9ltgXEU9gRelPiuLcnCtlVX12m+2P18zQoCCs82FXB?= =?us-ascii?Q?XR/o1oXIZGZgWS1RtSqAccKMrnTANu6eg346Ug2JRvnF5Wa274nnfqgi/+zM?= =?us-ascii?Q?B7QHFgNKfc3IabGNKAzp1d4CYLg5XspAdx2GmO+nWMK4D2tpPjtRe+Vp63NM?= =?us-ascii?Q?WYOFjwXoaNNEdXdXarf3syMar1duDnrZvNEk0FHOCYl5G5jOto40XzmgIcrr?= =?us-ascii?Q?ZjT/FH7IU4aQBU/oLr5aEXwLjt+X4E5A2ZGZdQ/+W4xskg8T8622HLDm3YEF?= =?us-ascii?Q?EfCnBE+EW4zQ6J+fDe/O1QxbaIpsW0TMUJ6ZSVEgQ7+a8UFIGMe+qU1i6xeu?= =?us-ascii?Q?oHugqOBca+rnV20r3ilpLotNEjbGZoB7o3jHJj7IbW92z63UIAiqnP9NVOUb?= =?us-ascii?Q?UrZ/+Ee3TCUezmrkHvaRp++xC32ArxaCDbf3CxT20mvaqaB5uS1nC1pLUP+p?= =?us-ascii?Q?JhRWFnFqmlJyzCBG395Fyterbr7cOF70PD7r1KyazwQH5KiAPV2RNpqrnTUZ?= =?us-ascii?Q?IYRGoj4y1Ze2XupTXP0GfI1zqE9Iofss/BeZEBFu4lBGWWNmE6ukG7Agi03K?= =?us-ascii?Q?pbiR1bEcJ0IeSI9RTG9rAPrqZKn2lUNmevKJX8qOBsDIFgnIXK1GwfW4318d?= =?us-ascii?Q?LDEExSJgurodf/3Gh+zml1kg6jnTHLUrPq7fAdQJJvHL/9cLPRuMOtuG1W8E?= =?us-ascii?Q?Y/eF1vERdnNzZS/hVvfPrZHXxPxxoFYH830NRU7fNL/S9PoVY5bMLOyWlF/c?= =?us-ascii?Q?oLRBJQ0QE/SbrvQW8WYSiNVV1fpmzGjtW7TqDgBAYZQoIcYUwEd4NfMLadMa?= =?us-ascii?Q?rN2XS3kznezF1sta0POCJ0Rdeu6BOtpNq0Gpuw7qahycWCxDxOOwxnN9MBAN?= =?us-ascii?Q?ksWpNVc6JjThKhIbXXDgHwXmscxKDp+O6CrjsJi1+ooZm+DGRA1cAKYzONE4?= =?us-ascii?Q?S5UFq351gU9WOGVb60vfIzox5oE/bDsBza/E9fxUgQLqvmRsRt9qrzgxTnqJ?= =?us-ascii?Q?EH6GpUPcbsPt/eXhhjhPFZgAjh5czDY+lWEKcTnvBrlEB1LxgjxdFlgcO3di?= =?us-ascii?Q?aiGPWDVL6s1xclxT4Zuqvfj/rKBIVsrxOsLKThDhhvD4ywaUwsgf+dMjBl5B?= =?us-ascii?Q?+jnDLBPPR+D6vkligq+Lc1VYtwZc7DUctVYElxa0wypN0r2n5pqjltXAm0yk?= =?us-ascii?Q?rfpxsDfxHIwely4/qsQvsYDhLZwuMcV4+qolQmQTxEZMwYsJ8pN4yFw9EMIS?= =?us-ascii?Q?os/jPxS13nKWwKXNjHu5z7OHoyS0j0ZOWhc/byY2gvYUZjqWzdsnEO1Tqoei?= =?us-ascii?Q?HkYcrZ4Yo6Kiz74BI8gpW8CKBxdOsuhcs+N+nOuUE1fLHFE/a5biS7TjTV2t?= =?us-ascii?Q?flDPgzzi3mnp3TaP76V5S1wNLH66FE9+XqJhVXQqzEHYr9/4JqooOLZwMyZd?= =?us-ascii?Q?BMG9sHAxTf+O3SIdv0aCDcE2Pt0SEA7GcZn+busKzf37o42qXkAykMUpve84?= =?us-ascii?Q?1kVW9+kvN/obYcpvS+EKiLkiPrRwQvObfSZxtivjMx/9I1GH7awawlrBvNQr?= =?us-ascii?Q?+yOzaD69YJu5rChT+Ca8ZtCxuDqSN0w=3D?= X-Exchange-RoutingPolicyChecked: DxotLSV1wYoOMBc6yNX2b498simAzzY/b6GkpptsQzuKxELPQuRJ02wq295wh3hh8TKont7wSBhaYdDxIc+bOsmsp9wkGJaXk4SRFSouNfpVj3MuIz6kP5QBsWy09kqS09vkJ+1W4yHeqhQVpzh3Sl95nTFxAOGEDqTnf8QObvz7VhHVfbHnUnxl7qNLG2hqhHTxikNu/d3HOnLNxgjfsKMPio2KfmKcGCJJHlr3//u8+cOGxERbTXF4nQJucRv0raynBZn++BADYcsiN2v1OpugnDx/zcp/oZoiY2k+Ut1A3hB09UnYArEJAYMhO6v/AFPGtpfRSmwMiVWTVkTtJQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 33373cb9-e483-46b1-0bcd-08df2b90b90c X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:09.1562 (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: CcOVAGq0RjaA5g4auKjoAwpD9xleEjYgHUTzFzJQ7+04c9+1/V2ksSe3qPbRr/Z+gW1DzMCD5o/D/YtykahWcD13EAEINc6L9kUq+aVvAeA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXxiTgefN9ZXso E1acuOb9DHwNv7amlXTdsEcnch3GkzsY4EdYT3XbVIq+oByaP4DnJptlx27VhvxQJc39ET3PSzd IbwxkHk7pE1bL39KP37WfIQcdPUXpaw= X-Authority-Analysis: v=2.4 cv=G+OJgNk5 c=1 sm=1 tr=0 ts=6ad232f7 cx=c_pps a=8h7WK4dQWB09CNKj11a7yw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=7JMAGyXtUfIWgoDCk_YA:9 X-Proofpoint-GUID: JM1mcf9Op2tkbYiwHg0N6XWVK3PZkNfT X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX9yMTf9Ef71Z7 gNW1utxQvVR/cyIwy+GykxaPqdqS1s41f8t9rcG5KHv7/31ECDzXZmdrYsqPYWBPd0ETNY6xM5m iVhtF9vo0xiGtXtTIv9KRq1PpGan5Tcw+KZKlfsyTIHR1sOzISQ3aOIkwBdut/siD9WRC5KiBcY wnAOU0QyIJqhsJIq3VZUHnlvW1GR8iPIYQh6Qt5fr7Nw2ZcIg8XJ4JWUsW/rSswdlvo7dKbLLq+ hO08euZ5t5xsA9tmN0YloFjvKZqqL9+sBxKtz46U52g0QxvE0A/Oylq+055wUXRTCU6PD+n0ICV aTVu7rll7TpTVsIGbGQor8B8tFw60maHMlKJLTfMHgdQjCHmOFtL4iLHvzbtAvk0RAC02lmxSRp EqGoOmMuVXPgDwSAbUCffMb6bKG+tISizeCfabrUKelR+yi3b7cZyRoMhtwW12vSPcBEDgadGnr YTXFgIVzvp4Py3u5HTg== X-Proofpoint-ORIG-GUID: JM1mcf9Op2tkbYiwHg0N6XWVK3PZkNfT 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-33051d/1792160508-6CADC4E9-9DD7B9B6/0/0 X-purgate-type: clean X-purgate-size: 2079 This is in preparation for its use within a QOM type presenting a single KVM 8259 PIC. Signed-off-by: Mark Cave-Ayland --- hw/i386/kvm/i8259.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 68607d721d..85176dcf80 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -20,15 +20,15 @@ #include "qom/object.h" #define TYPE_KVM_I8259 "kvm-i8259" -typedef struct KVMPICClass KVMPICClass; -DECLARE_CLASS_CHECKERS(KVMPICClass, KVM_PIC, +typedef struct KVMI8259Class KVMI8259Class; +DECLARE_CLASS_CHECKERS(KVMI8259Class, KVM_I8259, TYPE_KVM_I8259) /** - * KVMPICClass: + * KVMI8259Class: * @parent_realize: The parent's realizefn. */ -struct KVMPICClass { +struct KVMI8259Class { I8259CommonClass parent_class; DeviceRealize parent_realize; @@ -123,7 +123,7 @@ 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); + KVMI8259Class *kpc = KVM_I8259_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); @@ -141,7 +141,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); + KVMI8259Class *kpc = KVM_I8259_CLASS(klass); I8259CommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); @@ -156,7 +156,7 @@ static const TypeInfo kvm_i8259_info = { .parent = TYPE_I8259_COMMON, .instance_size = sizeof(I8259CommonState), .class_init = kvm_i8259_class_init, - .class_size = sizeof(KVMPICClass), + .class_size = sizeof(KVMI8259Class), }; static void kvm_pic_register_types(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1451997.1666879 (Exim 4.92) (envelope-from ) id 1xHiog-0003Pc-NF; Fri, 16 Oct 2026 14:21:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1451997.1666879; Fri, 16 Oct 2026 14:21: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 1xHiog-0003PO-HS; Fri, 16 Oct 2026 14:21:50 +0000 Received: by outflank-mailman (input) for mailman id 1451997; Fri, 16 Oct 2026 14:21:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiof-0003Im-ND for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiof-00Aqsy-3k for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:49 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232ef-bab6-0a2a0a5309dd-0a2a45069fdc-22 for ; Fri, 16 Oct 2026 16:21:49 +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 6ad232fb-195a-0a2a45060019-94a39b0ce3f0-3 for ; Fri, 16 Oct 2026 16:21:48 +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 69GE5MK83333355; Fri, 16 Oct 2026 07:21:43 -0700 Received: from dm1pr04cu001.outbound.protection.outlook.com (mail-centralusazon11020128.outbound.protection.outlook.com [52.101.61.128]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4haukukqe3-3 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:43 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:15 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=GoegeKV1vQWnIJ04Hn9BEfV8vtJcqN917AjDT75f7 DQ=; b=PO3i9xpGX1TOzmdZrEV5nXJdi6nzUdlsYwwkcjvxbM9nWDmdmVPX/MZ47 AksHWmsUggOWTCAMwmP9AcpLj7saq2zGKUbnIz/b1baFZ/6UdjDg3hzor0vBSeWn rxA7W/ARzxnQqKtpuVFun56LJ5TpJvX98zzLXyFeHAWO23a4vwhshrWrFmSGUMhm KJdxgakVCAmo5gCOA/KI4+bnV4tTNf2yXQxr7raT38dWri2A6H8YGOAP8PzzU4iQ z4ETgoyzz5QFKTZbyEd0AvtmuS/LW0wWcig172VPsfN2gsF7/0T02gVNw4jDDhsp KXp5xeKV4ezipTaOmkFWqvnQerPtA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vyJ5VwhEadg2rI007DWrqolri3EgkbHapZk3fft0T+85CuCt3BQJe5bZgp3r+0rVtkIrXr4ZO0I9tSjZ4R1UElt3eLMFBBCYRpR/b3P7gxrgDk7g74qZoMAjXZEjB38xjzPG/CQRxP/ImIY7EZzXvjOzjHKvU2S7CDn9Ihlewl3LRjp1MBcuNzKKWK/zseQRUDGFN6qQsB14DkWdwn7UQ5X9s9lHjApBIojfH9RR4ucJYuVxFk4+CvffQ3QdGDngEAG+4qHZBZbfYNENfpAMVs0B8GSGOtXMoH/rMJpE5Yb7QKOcxGdy+tisr0eZXwCch/2V0eLPmRNMqyuO7XRocg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GoegeKV1vQWnIJ04Hn9BEfV8vtJcqN917AjDT75f7DQ=; b=jeHKAMvJ3qg3vgUAL7644nZZd3D3qvTgv8iBsL1AXYl4gezPxuFkVmnLqRvNbwANBemVdKtubPNk4CRyLSzZ57zmpRUATegAgCV8Eq0rbWcbdqvvyNXhbqpRX6Jn9bdKdZXBqgyZM493GOVeIua4DLdWsIaIiIKBBa9fE2N2JvQnJEY+4MZitLL4DsV1Mez5LujOiFBs7wyH6A/Q6LwQzEbxaip4OHT1HtpoECwwPw8lYVOlrn2puP6Npweb3EjIVX5f8snpNjlAuNeyUt5g1nQ+CEENF7fwcoJPTWd5YzQQyLccQ+j+F7mn0luHKNqKRmTyrxQ4+aUn4HaG8JC6+w== 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=GoegeKV1vQWnIJ04Hn9BEfV8vtJcqN917AjDT75f7DQ=; b=YN7VZGP6TGvVDUYSvRIfKbeC1qrtr2D3pKkEDtS3zh7pdmG+SQXfKimWgPUMeNDrkmKy2MzG6+7nMO7FUpl4W27P7Sgyck85zMgUrMzFZ0tsgx5Q3qXH+36ix7Awo22+ZscxNYWrFAdmIY4nhkSe5E9dy+kgcK/MN34pyxsMYVeux2XxBL2Eh+r9vaX3N8JMzMPiVPlaOFzby4jhdjUYVNoSJEQJVUdEh0MGqw89MQYjWy6QfvUL/jrF2NoW44yzdbPaQJknnHuzs7TzA4+poFQSXkUPfRyrDDgh124VasdcLRqwvAr3oKXM8sdzWetZA9iZQg09JC/vttH6IN71aw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 09/27] kvm/i8259.c: introduce TYPE_KVM_I8259 device Date: Fri, 16 Oct 2026 15:19:15 +0100 Message-ID: <20261016142031.1204281-10-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR04CA0016.namprd04.prod.outlook.com (2603:10b6:a03:217::21) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: d4af9134-80a9-4191-dda1-08df2b90bc1d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: 6wzZgYk7PuMphndy/F2woKoOv9nP1MWvE10kvtiZuOV+gVX8eLRPPpffEB+3jSCXMHRi7TtYxEIt7hygNVS9fl/pBNHOHlp/YxafldPI203YevEZuYBiAaCEF4D8GBOvWI1ZmXbUG2CLEIw14cpcORjlEgppoFdNXn6bgmyFIK6P8Bi9kdIoewpfooRIdci2T4zjM7Zoqnbg3ocqFGec6anrZxf7qtoPjo3SK5/8Z9QL/57/Pe9Io3PyddHCW9ylUdEc80r/EFIZPQKdnHVri32TVqkl1tRl/pvuwTny+/doBOFjR4Qb3k3GuM+LqFU5E2XTWtHwIxlm9QioxrXJtRjlKP0h9B2gJvYUzaDmCGDCnC4gwoP75haVrZiC5sLsRlgwBUEWyYVaZsqthjgwLUWqLLT8tdtiUyNXtU4uqd1npWqJhOdYBqvv9fAxiPTy6qpflE+bvg7JSaGbgSpQOzGF3ctacvWCnx6zMXeVSWyNQNx0JWhCrcgeEbgVTUdZScqHCqrfZgCFNiISbHyPhQ/l8mwXkFw1hiI247Gm5PxmOlG4tgl4aH/Itr4z++zoJbgzYoPwlosWBs64CSOnFV54qdEECaybNBsJgWkORiD6biZc5nmB5N2BGDmednB5m/+Ns38eZeMQ9UxmTJFV4xFUm86LHgt0bTdrKG59tws= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(18002099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?L3Dy39C9AfgE0qsqPGISFIYWimHk0CIdjZc/ajr9LclCbxyudKowPcKJHk4q?= =?us-ascii?Q?lIbxTvvsPYwhQPOZcRzGp1DdHXVnxAHRt8/vQPqBLiBzrrTobTK4poQRAfrb?= =?us-ascii?Q?9nWYOrvLQAhBQ8RaccbCQJIYId580ARevtOn0EZEEJVWKjURUFv5Jfz4XIIO?= =?us-ascii?Q?h5LdxE2nTPK/kQPe7GLX8gM4rmIQ4NqWRXBKfIj79/q8HTBmjf2lTZWAUCk9?= =?us-ascii?Q?9Ndrbt+G6tQa8/IlnesafV6IL1WqJ2HcbeA3U9D7TJGn9IgAmNtQ5cdwTDvq?= =?us-ascii?Q?1iuM/J+SRmjHm6S9Q18zczCM7lvA7fuRUSg6B31uH9y5GlRFoiLFY/H5JbHp?= =?us-ascii?Q?NH7mpwlceFtqrFjT3g7/RsRp0CvS1qRqKFoLymtvqjhshWIQcipWrdIGI/b7?= =?us-ascii?Q?FYG1LHhmnon4eoV61WLCVK2S1yXHuE8EnKO5IM949Y82R6+gCvNr7MEj2zzK?= =?us-ascii?Q?5oGNJGKSMM/3rSVDXav3Td7GI2pUZ6vlPRtNeYBmSTIjLE2Z+RoX2zHZJCcZ?= =?us-ascii?Q?ilpD4gzjkT+nqtVpAcNGYXXMeWMvmONtuxj0dbobTOpHmlSvJ+Dm05/MLebK?= =?us-ascii?Q?3F9hKlLvvwDBKK0EXuJ8Bl8Pd+vU6iIc5AF0aNwofIwMBfWwPPG2qSBkACGs?= =?us-ascii?Q?fKyx22+ubrATQfRPcbOYsPHGBkKgY+9iflDwzgC4CXZAYSTuvXcxUYsVfPFv?= =?us-ascii?Q?6FP9r45CMdy1OzxwA21aOMjg17nExWwgrCmb2zo0SDKpaykOg7khyZT5C8Uh?= =?us-ascii?Q?EKvoZOK2OpcryvYrLg6TixRmUW8thYpTJ3W+Y+vMFWK0/r/azGS8ReOW9wP+?= =?us-ascii?Q?0XrIq4PMo0BHHpfiBptMnlVXBdCUjB1RdDo8TNYGB3Kj+W/eq/NZlKdcjAAo?= =?us-ascii?Q?+eLA8xPF2nXYDxPGkMdegQxKpsKaMWd3gIPC1nppzRP8sHmRb0rryyPDqPtT?= =?us-ascii?Q?ouFPKbpRmm0/BI7ppY1MrsH0XhEg/2qFgxXnNze+CRwW5MaQTpcNch82EezL?= =?us-ascii?Q?AqUJ2OPtOH0ShkEyXI0vCLDP0rkmKlE1vVz/7XtqRWVsx7ZfAJnHiFoGMlyI?= =?us-ascii?Q?HgFTY9HPuuWRpMgqevz85a2uoXhxLlO30nQPdErd+6Z4tOlGR0q8zJf7uyHN?= =?us-ascii?Q?uLrfbbaNhCHVJ7R+fX4ZSsNJoMdrl1V1wmYI7pwzpss8rvb9DxbbShv0f2iC?= =?us-ascii?Q?CVMjLgWagLipvfFB/tDFEqI9qFYgC05CV9hmdxizs9lIhDrdAx7zXDVBVEgz?= =?us-ascii?Q?FlkbidACdmY6DJDurvPQj9EMH5L8xNhz3MUo11WAwECH1vxXY/nIBDKhpoL1?= =?us-ascii?Q?9qaeWRzkOwCjXPbhZM55bym7S2245oobUutvZu/z5Ae3me/eGi3CdTS2sIrg?= =?us-ascii?Q?RQWaOxjdhSZH6cnTf+/TjJxWBQ0zoJyLLY2oR3D9YT6mJNqyo6mwzWI4o2VO?= =?us-ascii?Q?HGXJaQZYDDQwlgjMOLdYCiSJaFE6gOZH9rT5vEcbJmWsWoFAwY1+a+++xMnA?= =?us-ascii?Q?DbtomktxcKQIkBs28w33oOUqIgDOKaYP6tA5ulSmY4antesF2vfrjxIG0km0?= =?us-ascii?Q?yuhPjPWxm+q//ljb5GUW7Dm4Wg3pFxHfKnUXbkOPU14Mr+mSY3l9+qDr2WkQ?= =?us-ascii?Q?cBEM7DdLR0+DRhFHgfoR842bwtNiObl5ML4iRQgFwnP+iNM4Sn64op3zNZRh?= =?us-ascii?Q?dtMxiQO2NmLlahL8Gp4CZOa6+iZTBJm7hNESgsbvMDlPt8ltKqKlVbbB3o9k?= =?us-ascii?Q?QcOcqf41IDhCkvc5RxDXyGcYNsJIur8=3D?= X-Exchange-RoutingPolicyChecked: t0EHbI/OoNNPm8DBLS50qX7xNGxehClsCXhZFZ9B7bFVAo4t6C5WZaflV/3hVhbwpgZx5yTBuuJyH10GQMKxj4tSbsZjiT+QCcPsLX5iEsMYo2HzsZnKoinozdJ5GUH/ydAGNboEQWH1UyIJeBDVLkxwnd8Owvr8rr5TdZSf2G9q+f+PkeycsbZxnlm6bJlrqPZx4FhY56SHQxFPr4brkdTqeFwbwGLF0umU9YyjbXqQlBPaOMDHlWrZzjDMPHCOAWi0ZnQAEzZDBUmmC3KD6fNv2DY9CqQ17oQ75ZRskS7Z9J7ti9mcKadRL7TP1HjzCXpGPYuxY1fZvJhQdjDS9Q== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d4af9134-80a9-4191-dda1-08df2b90bc1d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:14.2089 (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: epsMdh+/Sx9avIERamq7GSCobqJB3Uow0q67GIRdNl88W4yr1hJLnwAOz7piTt0gaKynzORYhgcjNLfuvq8lCwvDOyYaHYq4ESVHYnC4Ldo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX621WD9LNx0pS W1bjqEBQov0diufXQjjhY4nBlWX3m4n28N1jhxeG3y16MX6mKbyHfjjuzPeLsjwRORSOyZ9oFou TS+GmEAcI2wUOhHCwC4zuDJBpyOk7C8= X-Authority-Analysis: v=2.4 cv=G+OJgNk5 c=1 sm=1 tr=0 ts=6ad232f7 cx=c_pps a=8h7WK4dQWB09CNKj11a7yw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=8xmoOu93QUavKZLLyKsA:9 X-Proofpoint-GUID: taTb4rykIkdH5mIPA0dCdcY5eM4jvn1m X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX5mc7USv2Y8K2 9s6sgKs/5Pi4qGk7abAHJQ8wbK4E1mbjIICW085REXWJwl74DqxTKQjF1+61FkXkeCKe3SKnoE5 roou4cAAzkedwxodrG571bOhokixvBXzRNU0IsUfPlryOM21E7Xhg0NPCzFqqrjsjAB3Dh2g19q +mBLYgvc55io8x0Zv0sWW6PfdnNHme9QmdvFnyM5aBFBY8X+wVkR18yq9jLNghJmRgC3LGCbfW8 Gkz2ZdwFLoCzOe157+AmRrNWAW9r3RpF9IauwWDlLns5Yzf6EDABwhJmnl0bjHymfgw07N8MOP8 WhBYREGs4ksPLewC2s7XexWEoVvT5R8SbdpIdsuiUbGCdUGNUNuV2klDdMUnMLDFym/m0IGwd/d 2ngroPV1UXaSa5Lyo6OzZDhIfvnQQpKnXBUqksX7CiGfaHE6xlmVS/1j9GgSHDOYqwHpp8ln1IT eLzCtk1/UI6YaNqZc+w== X-Proofpoint-ORIG-GUID: taTb4rykIkdH5mIPA0dCdcY5eM4jvn1m 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1792160509-F72C677B-1A0DB23A/0/0 X-purgate-type: clean X-purgate-size: 1238 This device represents a single KVM 8259 PIC and its associated class and ensures that we can safely embed the device within a container device. Signed-off-by: Mark Cave-Ayland --- hw/i386/kvm/i8259.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 85176dcf80..8ae5dd39b5 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -20,9 +20,11 @@ #include "qom/object.h" #define TYPE_KVM_I8259 "kvm-i8259" -typedef struct KVMI8259Class KVMI8259Class; -DECLARE_CLASS_CHECKERS(KVMI8259Class, KVM_I8259, - TYPE_KVM_I8259) +OBJECT_DECLARE_TYPE(KVMI8259State, KVMI8259Class, KVM_I8259) + +struct KVMI8259State { + I8259CommonState parent_obj; +}; /** * KVMI8259Class: @@ -154,7 +156,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), + .instance_size = sizeof(KVMI8259State), .class_init = kvm_i8259_class_init, .class_size = sizeof(KVMI8259Class), }; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452000.1666894 (Exim 4.92) (envelope-from ) id 1xHioi-0003pt-G1; Fri, 16 Oct 2026 14:21:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452000.1666894; Fri, 16 Oct 2026 14: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 1xHioi-0003og-5Q; Fri, 16 Oct 2026 14:21:52 +0000 Received: by outflank-mailman (input) for mailman id 1452000; Fri, 16 Oct 2026 14:21:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiog-0003Nr-Kb for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiog-00CcZL-1D for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:50 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232e2-2eae-0a2a0a5409dd-0a2a45019786-38 for ; Fri, 16 Oct 2026 16:21:49 +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 6ad232fc-5984-0a2a45010019-94a39b0cf3e6-3 for ; Fri, 16 Oct 2026 16:21:49 +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 69GE5MK63333355; Fri, 16 Oct 2026 07:21:42 -0700 Received: from dm1pr04cu001.outbound.protection.outlook.com (mail-centralusazon11020128.outbound.protection.outlook.com [52.101.61.128]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4haukukqe3-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:42 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:04 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=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=svd63FWM8ezPOcqPD+qPN+weE2ncrsjkAO4QJk1oY wU=; b=DFydhXXBiNoUqUJ8fa1xVBvWZn45jOxUyFWbvXuqBUO0fdvZCf3XWv1PL eFFBLUQBZInJolYQZTw3u8WgIYHdwbnXuykvDbmmPawlx8emg8UAPc5zQ6uCzqTy n7dj1uWZ85fk2kPc8ZsI8XO7qMosj7UU2FNRMMO0cpMXYFRI9yxSW5gFJF/HYHN6 +5+cTZZ9c5y0fZdAsAMVxD9isPKrmApgvsLVcocmDf93FvbyLvfb3mfViKKchfSN rFAOMSr+MEJoTSFepiuTb5jKCoQyNsRezXvnu6tg5grRV9Wt4SsmIWsLGAFFjVcN fj0nQz+D9msvpO0LEwEHRpTjcQezA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dJ0Ucik/WbJY0ECp/LUc3fWzhj8cUWFFjcin+OgCR0YmMHD7DsZVQ2UUHcBdQq0emN2fRCmSSpdtvfyDtmMOGJP/ou6TlP2LsU/0KgzDGLCeuLVYfHLwP2cnYjwS6rvDXYBLN2yVsjq6us9AB218yN9Lzn4r31ioat7NQz7RoKX/8vwQ+NH/20fu1M9qGs8gceqTKqx7wTqrnbSWMm44fzfiCVaSPUEiegvNHm9CHidCkMDDu4J8TXbQVp6l2/Xb2RTcwtCzEF1kTasxdvbrIJmm6yOimYNFSNY4smRg0ccox1zPd8/g7j+QPQ2ksRE8bXuS2ec8MCKWGlywVK1I8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=svd63FWM8ezPOcqPD+qPN+weE2ncrsjkAO4QJk1oYwU=; b=Yvk6I8Tq1iBo0r3BddTE3JxYtR9XFAbTB7UydpJC7kd63X+C6Nt/LQU62UCI6KlBZ1qPwcqg9H3jRsvL/TfXMoxhwe2jYr1VZKTawYkkca8z4tE80QUjcsIo7ea5M8xu9wgm9OO0EyJ+aSf5wI1WDeRoal6L1N0NgSn9SfLeUVaBw2iqC0H01eHpZcK4/BiAZAikeagCVtAhK9hck5lbWGSZR6PHHmfK9IDAptVW8SJcnJ6ugYgUXvYlGew8x7EKY+gwpk41qT0p2iMPR12xvcNkvcHPAmXNPrpZROtqoVTiKosdEoXiDjwhkH19/7tXtXOnAEfVbBKXT32QzPSPrg== 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=svd63FWM8ezPOcqPD+qPN+weE2ncrsjkAO4QJk1oYwU=; b=JSnxeOocyOfp+goIvlf9AdpGJ72Rl502rTC91odWNxpGGEErnpPyQn7J5jittPaMVzZeYe7aKdIGzGh741xGLYQc23lMSCcShHRz8DlC/Lt3O85RK/lFkkGC8XV2wrg8hXfjonHBAy9bOeeX8EZglenUBHZ9kHHijWcpMmirCKX+8i2OI0euo98zyOtx0tVU6/XErL19wMxJp6RvU5vC3i/6RDHpOcVv23PdpbMX4ks9N7ii50a70ZxWzvn1mFVCxo6r/HiiaorA+X4zeTXkp/ZPkuc0xtIA5/GvlW/zuDw1/FEBDROgIurkAM7/6O2bxyKBj8U7dppX4YOtlekafg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 07/27] i8259.c: always use cs for I8259CommonState variables Date: Fri, 16 Oct 2026 15:19:13 +0100 Message-ID: <20261016142031.1204281-8-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0062.namprd05.prod.outlook.com (2603:10b6:a03:332::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_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: a0948d43-d9bd-46f1-1fe6-08df2b90b640 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|6133799003|22082099003|10067099003|3023799007|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: CsPLnfRjLNbQMopmTB5fZvif67alPJET2IBzMxeK/7y9ajUh2S5hOxAdDlFH8AONFtQzPJJKvXex2k82jHLAZQw3RxwfzEFbUG9+FWvZ+qNKHP5qGOwPfIElYRZ4DkI2moelOLLLqKoHEL9WAozBPH2FRnGFd9c1BqJGV2ME60477zaKpx3H4L3fGKeJ63Qf2myZd4PJAOrirgfmhgSZJvRUL1UPJR2WAHhI23DddpeNBx/QibUo32e61C0k7/xlcdCifyfCyL2+7FLk4k769bbr1w8/S1IEGyOxtK+SHkTJlt6RtyuxPthmJZ7aNel53wSd6hk5hW6m3Pu40RiKZcYExEtd0XIRWuM8w/4RqCZ810GR4MjJVimTZ+m9kq3RW+lSqE2C4kisRqPc3b/+qwrpI2A3bjwa6SCowCrNYqUjYNVsbsDuty2/hZzhMGDdBY/6jBL44bjyNDCiV9wDv82fXhab6LAfYJlzLqiSQK8WYK7x6bG63E59MjsK1pPOUI7aOyKRbyTHPnjmlHAsp6M/U8U0uzrtsCSk33Zcz9/5or37gaGdl1dwnhwZ+o7Tboig0USqr4NcfJnEnHrpndpXNrsp0tUQOjZcNZpBTOJwDjxlqJfmi9q6WjMLNF0UWZ3xsBdZatvVHzp038RwKqbD4aW2EO2tlNLNIb7K0Ck= 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)(23010399003)(376014)(1800799024)(366016)(6133799003)(22082099003)(10067099003)(3023799007)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?O/jKcjRbR5fUNDIN/MvW+6q4t4e7YYHLJbmIdJAzy97Yyi7m6c7/2VLeQ/0o?= =?us-ascii?Q?9leS6I17V3AQGLBjpH3/1fnJ430E6lHWTtJKp1j2KD5XF1oETh1zVtHau9S8?= =?us-ascii?Q?+nHp3wwbSeb41FXUEhPr7lNENY/qfxIUx8JdJ05Nwft6F8hbr1DndwHAhozs?= =?us-ascii?Q?doInN2k5uOAFNe36GwsI8dmvCZavAgct5MiiE7j+S7fyy8RqttBjHi7aHx2T?= =?us-ascii?Q?EK+RotudVpUblYKmhQMtOTR/tpOeDqNHTWTVy37PUKvmCXIGKLR1+2F2cttK?= =?us-ascii?Q?j/VIKDQe24XMbDwdSlFNGUgG68E6xO5rhAzUrGc0+0E4KXT/eYPpUnLjaJyC?= =?us-ascii?Q?jrl4xOJUjAuv3C782U2m49yozAtEQIChS7tpRb0tT2dxRWjX2xTAXryA4cAU?= =?us-ascii?Q?iTtEZR2QNDMh3Jg+d5I93ZYANv0Qqa7EZwRo80kjNfCBvxHtZOu/NQFy0TFe?= =?us-ascii?Q?WODvlhGxgP9CWaEGT7yoYajMu1kXGXYR7GAAHY1zgN4AK5VEeOnXdV2ePuyv?= =?us-ascii?Q?7KJ5fAk9AGvoetDoEKppaODNJU4Z5zw9gWUyeR6FqYCEmzAk8C9jO4+0w0mC?= =?us-ascii?Q?fiRYJehbrZLAgoKf16fHCP0XGuj5hOD8lXVRrjtZFgXApOpc1HHE9ZAVYgvx?= =?us-ascii?Q?ylk6cP0wZa9wURIXR9i+fwkpG7kBHqAs5XMX8qcQDjNfnbnpCvWRdtfY6zZm?= =?us-ascii?Q?rQm8fESrctVxqPDVdf2XbVab0ITn5+eWXepmwT6VIzOuEw5BrZdWUQDU7vKW?= =?us-ascii?Q?lx8FdNTFcyCYBEW5lfolQiIYqKAewKygOsbqyinpW0becSdj6jGuEp93zoZh?= =?us-ascii?Q?2dzYtfglDhiB0LD6SXSfsbqVbvBb/Lcr1BhOTUAcHPPe5w3wsVy7kewcuYAw?= =?us-ascii?Q?vRAfGDfO7+5dpnerx91b0oBiGOxrf3WbvaIOi8+5KI3Fhh4/SYwA2nfymX15?= =?us-ascii?Q?do5BXm8JHHClEQ0wx8JGg7S5nzJuv+5u8rV/jY5LX3TCdTDBtwrYXNyCqD0f?= =?us-ascii?Q?MrdnQSV3gtGaQgkTMws+x91HkcPTQ4EJYvUtpI9RdBuM7gCIp21wLdzcoQBO?= =?us-ascii?Q?Xpha07eVzYURu8CzYICpV261TvlpfOyrdrHIdY3s+0QFKyFPea/jZISBPd5u?= =?us-ascii?Q?LRG22TitQKUUEr3elaB0255y+nhDhQrGygjUJEcb8mEfQ2cGyIE7gsvbhh//?= =?us-ascii?Q?Cvkwyo2daX6+HlGOxuqWt8QksVxdEDpSx8kuBAi2k420M2I/y3f5v+xTBTqE?= =?us-ascii?Q?n8F5UkBi7ohbJj2ZxevRZhN25K/XetmggQctmqmUaYWzstDgKLXupO/eE3ft?= =?us-ascii?Q?B/3qwbX9sLkK0BR5UZjecj70BXjEFEpoO+i7kQ/JdOeTbwTQVTyNTfAFyFHn?= =?us-ascii?Q?1CQahO6KncEqPQoFJtkwUtRf/I2wKbGoVZoJtRf90gTDbxrKqRQIhsfZAYG1?= =?us-ascii?Q?NOWiqb2mkeqMhDgP/GPoSJDEQjQAH8E7i+1AsxjugLgJt0+frUO4P7SXL6hY?= =?us-ascii?Q?Daq7f2HaS/+stxgq/8Z25eLQQCTJ+xkTvwUamUnllgJUlm/KwqTlhhuySo5Q?= =?us-ascii?Q?Aj44uE5aciOJBRUhT3s5KagH4FxzjmxtGw9uIJIMv1pO5HihqzDEQrnyHj7L?= =?us-ascii?Q?dk1HP2U3M7M5DwVSre0qFeNufEqjF5B/AfGScEfYS0FCuYGQodZmCbSLWajX?= =?us-ascii?Q?neWPy0KSR5oYgDQ2LNtoS17KgeOA2aq3nKh2S5Yl7vopaWELrav9qQjW55uw?= =?us-ascii?Q?tGp/VX8HwTqxCL20VFNixhp3K+ciVzg=3D?= X-Exchange-RoutingPolicyChecked: 3RmwBOUbmoSz3VvbiQIrTvYi5bO+PNuRB3mCZfCK+M/evEjtd6kjYh+8mubViB9JwbNaszNLNATFmBaYbgjd94EmLmDwvP3Mk4m9N7bb++uVGDQxOPtcYlRBkc1TdQ7DHhQO7Dk8ZmL8BNf8vy9lD+kT0wQRNEXSLGDXP/PsjnoDb8c8isnqbfK+8v+mcNopmcfL1ZYI5tVfFH9GXeTd+5ILOoc6W/IytK90+TB8rO+vblPucDso3KnVcCxSDel1d/saWveQOkb3hVBaMd/JrVFEoCsCrHWg4XbQYpSwYNN6UqTlbi01fjJeCFgARprWZkNdMvQTIS/9DgoAy8gy2g== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0948d43-d9bd-46f1-1fe6-08df2b90b640 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:04.7960 (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: L0gNrThslOlyMy3F4yWg96d8cqINHthZU/l2H6CAIGukls3RXjLwBfmq3BsdpUJOi47TWUZZ5vQR3+n67ElXPCkNQ8vwv2uC7SLTZ1OpQfM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX4vZKa+1YxGZx WcMy5QS6sGzDmatkddoz7NiUeRUXowlbG3PjAcO12n1grwY17Cj/yAFZ+6epIBVLWuEvKKpNDYs f6KlZyUU6ULXlby5jMsGNdVDwqw1ntA= X-Authority-Analysis: v=2.4 cv=G+OJgNk5 c=1 sm=1 tr=0 ts=6ad232f6 cx=c_pps a=8h7WK4dQWB09CNKj11a7yw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=zV1iqHTY6MOlpgDiNWkA:9 X-Proofpoint-GUID: DFMP2JQtX8tPTSkUBfw37ybxcVl-xCMK X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX1L6/MWftkwbV JZ6u9Mrt/pOnKOgECdxkAYplWHEBqg4/D8QltC6dg7ObL5i7q+4xGYIh4zqssASgLJvu2zJY5dx +cOOfXBJjA+w+Y9zSDdc++SfUQvghzAHuamOm4lfg1bTBWSgbMQ8pqNl5tLEA9NA+GWXBHRwAgG lcTh6OdcyOCd35IDwiFSsocwJHNcUq47bLIUJH7ENjryOnn2aOU/QnJRD0jAoQCJr9RqkfKdayF GTjspUI1xna92rAXndJsDvagR2n+yNKx3E33Td3AvZjJq9T74/SoH5ViR4uJgUn+AKVJQs71trV Rv+PwSw0C8AwDZGiwGXvzlPX8lZKrbw3UiN9+emwmXYmFiGKDlCEl6FckJUtnEAoFmufqdW5AJC F4GPrnqVWnynN0tozHduYphH2B/LSV8axqxajX2/93XsQodydLwyoFe0CzS1eRlP1nVw07pZXwR 6MAptGL/YXFwY6oDYBg== X-Proofpoint-ORIG-GUID: DFMP2JQtX8tPTSkUBfw37ybxcVl-xCMK 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1792160509-1E664757-0AEE61DB/0/0 X-purgate-type: clean X-purgate-size: 12951 The use of consistent variable names makes it much easier to follow which fields are being accessed from I8259CommonState. Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259.c | 192 ++++++++++++++++++++++++------------------------ 1 file changed, 96 insertions(+), 96 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 81827f2734..700412df74 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -59,7 +59,7 @@ static I8259CommonState *slave_pic; /* return the highest priority found in mask (highest = smallest number). Return 8 if no irq */ -static int get_priority(I8259CommonState *s, int mask) +static int get_priority(I8259CommonState *cs, int mask) { int priority; @@ -67,63 +67,63 @@ static int get_priority(I8259CommonState *s, int mask) return 8; } priority = 0; - while ((mask & (1 << ((priority + s->priority_add) & 7))) == 0) { + while ((mask & (1 << ((priority + cs->priority_add) & 7))) == 0) { priority++; } return priority; } /* return the pic wanted interrupt. return -1 if none */ -static int pic_get_irq(I8259CommonState *s) +static int pic_get_irq(I8259CommonState *cs) { int mask, cur_priority, priority; - mask = s->irr & ~s->imr; - priority = get_priority(s, mask); + mask = cs->irr & ~cs->imr; + priority = get_priority(cs, mask); if (priority == 8) { return -1; } /* compute current priority. If special fully nested mode on the master, the IRQ coming from the slave is not taken into account for the priority computation. */ - mask = s->isr; - if (s->special_mask) { - mask &= ~s->imr; + mask = cs->isr; + if (cs->special_mask) { + mask &= ~cs->imr; } - if (s->special_fully_nested_mode && s->master) { + if (cs->special_fully_nested_mode && cs->master) { mask &= ~(1 << 2); } - cur_priority = get_priority(s, mask); + cur_priority = get_priority(cs, mask); if (priority < cur_priority) { /* higher priority found: an irq should be generated */ - return (priority + s->priority_add) & 7; + return (priority + cs->priority_add) & 7; } else { return -1; } } /* Update INT output. Must be called every time the output may have changed. */ -static void pic_update_irq(I8259CommonState *s) +static void pic_update_irq(I8259CommonState *cs) { int irq; - irq = pic_get_irq(s); + irq = pic_get_irq(cs); if (irq >= 0) { - trace_pic_update_irq(s->master, s->imr, s->irr, s->priority_add); - qemu_irq_raise(s->int_out[0]); + trace_pic_update_irq(cs->master, cs->imr, cs->irr, cs->priority_add); + qemu_irq_raise(cs->int_out[0]); } else { - qemu_irq_lower(s->int_out[0]); + qemu_irq_lower(cs->int_out[0]); } } /* 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) { - I8259CommonState *s = opaque; + I8259CommonState *cs = opaque; int mask = 1 << irq; - int irq_index = s->master ? irq : irq + 8; + int irq_index = cs->master ? irq : irq + 8; - trace_pic_set_irq(s->master, irq, level); + trace_pic_set_irq(cs->master, irq, level); pic_stat_update_irq(irq_index, level); #ifdef DEBUG_IRQ_LATENCY @@ -132,44 +132,44 @@ static void pic_set_irq(void *opaque, int irq, int level) } #endif - if (s->ltim || (s->elcr & mask)) { + if (cs->ltim || (cs->elcr & mask)) { /* level triggered */ if (level) { - s->irr |= mask; - s->last_irr |= mask; + cs->irr |= mask; + cs->last_irr |= mask; } else { - s->irr &= ~mask; - s->last_irr &= ~mask; + cs->irr &= ~mask; + cs->last_irr &= ~mask; } } else { /* edge triggered */ if (level) { - if ((s->last_irr & mask) == 0) { - s->irr |= mask; + if ((cs->last_irr & mask) == 0) { + cs->irr |= mask; } - s->last_irr |= mask; + cs->last_irr |= mask; } else { - s->last_irr &= ~mask; + cs->last_irr &= ~mask; } } - pic_update_irq(s); + pic_update_irq(cs); } /* acknowledge interrupt 'irq' */ -static void pic_intack(I8259CommonState *s, int irq) +static void pic_intack(I8259CommonState *cs, int irq) { - if (s->auto_eoi) { - if (s->rotate_on_auto_eoi) { - s->priority_add = (irq + 1) & 7; + if (cs->auto_eoi) { + if (cs->rotate_on_auto_eoi) { + cs->priority_add = (irq + 1) & 7; } } else { - s->isr |= (1 << irq); + cs->isr |= (1 << irq); } /* We don't clear a level sensitive interrupt here */ - if (!s->ltim && !(s->elcr & (1 << irq))) { - s->irr &= ~(1 << irq); + if (!cs->ltim && !(cs->elcr & (1 << irq))) { + cs->irr &= ~(1 << irq); } - pic_update_irq(s); + pic_update_irq(cs); } int pic_read_irq(I8259State *s) @@ -213,81 +213,81 @@ int pic_read_irq(I8259State *s) return intno; } -static void pic_init_reset(I8259CommonState *s) +static void pic_init_reset(I8259CommonState *cs) { - pic_reset_common(s); - pic_update_irq(s); + pic_reset_common(cs); + pic_update_irq(cs); } static void pic_reset(DeviceState *dev) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); - s->elcr = 0; - s->ltim = 0; - pic_init_reset(s); + cs->elcr = 0; + cs->ltim = 0; + pic_init_reset(cs); } static void pic_ioport_write(void *opaque, hwaddr addr64, uint64_t val64, unsigned size) { - I8259CommonState *s = opaque; + I8259CommonState *cs = opaque; uint32_t addr = addr64; uint32_t val = val64; int priority, cmd, irq; - trace_pic_ioport_write(s->master, addr, val); + trace_pic_ioport_write(cs->master, addr, val); if (addr == 0) { if (val & 0x10) { - pic_init_reset(s); - s->init_state = 1; - s->init4 = val & 1; - s->single_mode = val & 2; - s->ltim = val & 8; + pic_init_reset(cs); + cs->init_state = 1; + cs->init4 = val & 1; + cs->single_mode = val & 2; + cs->ltim = val & 8; } else if (val & 0x08) { if (val & 0x04) { - s->poll = 1; + cs->poll = 1; } if (val & 0x02) { - s->read_reg_select = val & 1; + cs->read_reg_select = val & 1; } if (val & 0x40) { - s->special_mask = (val >> 5) & 1; + cs->special_mask = (val >> 5) & 1; } } else { cmd = val >> 5; switch (cmd) { case 0: case 4: - s->rotate_on_auto_eoi = cmd >> 2; + cs->rotate_on_auto_eoi = cmd >> 2; break; case 1: /* end of interrupt */ case 5: - priority = get_priority(s, s->isr); + priority = get_priority(cs, cs->isr); if (priority != 8) { - irq = (priority + s->priority_add) & 7; - s->isr &= ~(1 << irq); + irq = (priority + cs->priority_add) & 7; + cs->isr &= ~(1 << irq); if (cmd == 5) { - s->priority_add = (irq + 1) & 7; + cs->priority_add = (irq + 1) & 7; } - pic_update_irq(s); + pic_update_irq(cs); } break; case 3: irq = val & 7; - s->isr &= ~(1 << irq); - pic_update_irq(s); + cs->isr &= ~(1 << irq); + pic_update_irq(cs); break; case 6: - s->priority_add = (val + 1) & 7; - pic_update_irq(s); + cs->priority_add = (val + 1) & 7; + pic_update_irq(cs); break; case 7: irq = val & 7; - s->isr &= ~(1 << irq); - s->priority_add = (irq + 1) & 7; - pic_update_irq(s); + cs->isr &= ~(1 << irq); + cs->priority_add = (irq + 1) & 7; + pic_update_irq(cs); break; default: /* no operation */ @@ -295,27 +295,27 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, } } } else { - switch (s->init_state) { + switch (cs->init_state) { case 0: /* normal mode */ - s->imr = val; - pic_update_irq(s); + cs->imr = val; + pic_update_irq(cs); break; case 1: - s->irq_base = val & 0xf8; - s->init_state = s->single_mode ? (s->init4 ? 3 : 0) : 2; + cs->irq_base = val & 0xf8; + cs->init_state = cs->single_mode ? (cs->init4 ? 3 : 0) : 2; break; case 2: - if (s->init4) { - s->init_state = 3; + if (cs->init4) { + cs->init_state = 3; } else { - s->init_state = 0; + cs->init_state = 0; } break; case 3: - s->special_fully_nested_mode = (val >> 4) & 1; - s->auto_eoi = (val >> 1) & 1; - s->init_state = 0; + cs->special_fully_nested_mode = (val >> 4) & 1; + cs->auto_eoi = (val >> 1) & 1; + cs->init_state = 0; break; } } @@ -324,30 +324,30 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, static uint64_t pic_ioport_read(void *opaque, hwaddr addr, unsigned size) { - I8259CommonState *s = opaque; + I8259CommonState *cs = opaque; int ret; - if (s->poll) { - ret = pic_get_irq(s); + if (cs->poll) { + ret = pic_get_irq(cs); if (ret >= 0) { - pic_intack(s, ret); + pic_intack(cs, ret); ret |= 0x80; } else { ret = 0; } - s->poll = 0; + cs->poll = 0; } else { if (addr == 0) { - if (s->read_reg_select) { - ret = s->isr; + if (cs->read_reg_select) { + ret = cs->isr; } else { - ret = s->irr; + ret = cs->irr; } } else { - ret = s->imr; + ret = cs->imr; } } - trace_pic_ioport_read(s->master, addr, ret); + trace_pic_ioport_read(cs->master, addr, ret); return ret; } @@ -361,15 +361,15 @@ int pic_get_output(I8259State *s) static void elcr_ioport_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { - I8259CommonState *s = opaque; - s->elcr = val & s->elcr_mask; + I8259CommonState *cs = opaque; + cs->elcr = val & cs->elcr_mask; } static uint64_t elcr_ioport_read(void *opaque, hwaddr addr, unsigned size) { - I8259CommonState *s = opaque; - return s->elcr; + I8259CommonState *cs = opaque; + return cs->elcr; } static const MemoryRegionOps pic_base_ioport_ops = { @@ -392,15 +392,15 @@ static const MemoryRegionOps pic_elcr_ioport_ops = { static void pic_realize(DeviceState *dev, Error **errp) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); I8259Class *k = I8259_GET_CLASS(dev); - memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, + memory_region_init_io(&cs->base_io, OBJECT(cs), &pic_base_ioport_ops, cs, "pic", 2); - memory_region_init_io(&s->elcr_io, OBJECT(s), &pic_elcr_ioport_ops, s, + memory_region_init_io(&cs->elcr_io, OBJECT(cs), &pic_elcr_ioport_ops, cs, "elcr", 1); - qdev_init_gpio_out(dev, s->int_out, ARRAY_SIZE(s->int_out)); + qdev_init_gpio_out(dev, cs->int_out, ARRAY_SIZE(cs->int_out)); qdev_init_gpio_in(dev, pic_set_irq, 8); k->parent_realize(dev, errp); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452002.1666902 (Exim 4.92) (envelope-from ) id 1xHioj-00044Q-HN; Fri, 16 Oct 2026 14:21:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452002.1666902; Fri, 16 Oct 2026 14:21: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 1xHioj-00043l-9y; Fri, 16 Oct 2026 14:21:53 +0000 Received: by outflank-mailman (input) for mailman id 1452002; Fri, 16 Oct 2026 14:21:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHioh-0003Xl-CP for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiog-00BWwx-PE for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:50 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232fb-e002-0a2a0a5209dd-0a2a45039348-8 for ; Fri, 16 Oct 2026 16:21:50 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad232fd-fae8-0a2a45030019-94a397449984-3 for ; Fri, 16 Oct 2026 16:21:50 +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 69GE58qj3551722; Fri, 16 Oct 2026 07:21:28 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021136.outbound.protection.outlook.com [52.101.52.136]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hbmjc04x2-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:28 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:26 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14: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" 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=7wm8uo+H49sktKaMqKuuL2u6+/dMUEYN+P4+MkpQf Kk=; b=J/ogjivdRZTBu4UWvb36VWwVIB4+Nb2Ybv5zPPmBlyolsmywEGDcFCfLq HbvsfBRFNVUrg6sxCvLVaRaURwFJlOj5V1mGIcfKB/ZELThlcGO+r1A96utJwhDS MZELg0v5MDbCWftRb118zf+gtJjUseYk65V6u8WQYwauhvIGfWzRnaKhTf8JsBDa AIu/cJwtPvtYhfzFZaY3wsFYHuwj+4qWNWQKVtM1byPU9jJCshUJlCfCS6UaMKfg uIUHWld/o862ZhdOQgFwrIHqYfCZN7KOR/U84mJbJPAxTQ/A6X6VGNvMLNgjdl8s YQQDskGVxQAV4bCwqq5Zk0cNzdbvA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=j5TgSb3bAmf8XW9YFkdXfORzdgb63mnvN5wHtPw1jAwvmVpKcNqZw86oHvbLNh4eqLTvd/YTJyLNV5Fyk2Zxty++YW/spW+gRxBWwZ6WB4tx76/fvLb1mnYkapNVWfgEvX/nd2UG/ZbcCI7M1sTmOKY3txE7pEDbeanRvN4l+PHmsBPcDQclV80+xoB9RMO6DrV+Dcf5tZlpSM2hMnXduwZvQhf5TYxMYdBmTyiu54mdtpJw4EN7BkVzVFe4b63zBpHaRkP/jLS0ofkBnrXkMemfthSZx0AoyT1jUkWbXZ9jW9tQZwwBrSp6/H/fqtt62y2oixvpXGvhdQe9Y0XRdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7wm8uo+H49sktKaMqKuuL2u6+/dMUEYN+P4+MkpQfKk=; b=h/IzCudwVqVesqmTmBDFuuVzplccrTV88pIKeWWSaVY14zuMRuurwVfiNdn4bRUFz0dRJfKw04p0QGZkEa27fxSl3Wa7MUYe9edDkrsUOOBbucIkYZJWoN+t+oCnjmFKYd76Qh4u09WXHqtuWRn8IsRIcKkMY2MWiE3T8VzkB8xpCuY11qrE982cCXp+zmwU6FvIoCI7uIx3VaM49seRp04aUW7+IRRlAhLc+7QhlaU2XRtI/vW//wsIymMFTZ3asoT82b+04xesXQnGGwkcnJKGrMX+dbagKUMGWMYtKyHEU+iJHbDsrOqk+SRtyvTCXIICz1Wc+QlYY54QTy8OiA== 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=7wm8uo+H49sktKaMqKuuL2u6+/dMUEYN+P4+MkpQfKk=; b=UE8se7vzaoge487CALbsKNnVea6zMYuJhom1LIrPDE5SZ2tvMWlMlR6uycnQLOpocyYe7PVdNKyhY+9EviO9FsCwijKWmsTNuLyVwUxKkDXLw8fGc++tvzS/ekadRWb6ijQxsWbKIkgr0pCOfHANXiJz+4CSg30C0tqeGfKW+Mxf364jQkjyIqkicn61WVZutrjz96z9Lq5qFm1/gCOps8oTQoN9MVhRIYIvM0O/9maNJ3GDjyT9OlnzJFwVusxtmsWB7XMivICQxo9ls7jS+kp0JlHOdHqjgKCMGQtC2F04jwmlnuFHsXM7kmsdMqb3+OFvN6j8yDT9h1L07PO7dg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 12/27] i8259_common.c: use i8259/i8259_common prefix for functions Date: Fri, 16 Oct 2026 15:19:18 +0100 Message-ID: <20261016142031.1204281-13-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0132.namprd03.prod.outlook.com (2603:10b6:a03:33c::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_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: b081d4af-9d6b-46b5-1cd5-08df2b90c34f x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 6J/TG061G/2Og8vvbzOPvbLMYwhw57cMd3mio4M+z9DHkpblpVyTGpKOaaAaJeJA1gFUOPxrMCMHPH8Ee+fCN5Fj6YUX7REqAqZ/F7nxOPv/nQsRSEGK4L2fTFSNutlRncdP1ewnf7iJ0wnkxbzZZT3qsIWnjdJmOwYpcQTZB4hQrJFJzNBSk8zr776iHGM4aID+O0kt6k4Cf34xoQo+hA53KXFFBZbdCR481HK8EiB8t/lQ0UD6q1fwNmx3hkNDcdLpED2stjfV+aDa4FgxRbAWXX1XmT7GNZpUY54+ZRDay5wHvUee953laCmyOF1I5tgNmrsM3XxYSlRA5zJDszzu0wGhPeVr1oS3qU1P7hiy1opHMZjPsGJZ8p6X/JfowOCDtpvGxx+W0Fq7VKX0RWQr8/6guZRN48Y7Wn9ZpBADIKhOcOhREJY3p/83w/mFq4uDKUFjSfdwBGZ2kxs00L4jIOn3daoFct0fZnhIBLjWAyh59tHSaTa7qtYg7+rzKNQ+x+EUndLAxF1SZeDw3wTG4mLA/4dPIYqfRyFZr3pigb3ZqSPz7+mZNQ2C9fHYEEXDK6xo8J+25HdDGdteSoaUacEKx+LVylUaaoxQNwn3R4+9+8zqn5m+0MSJk/RBypCkzngA2VpGIvPX0pVuKYSkyqk2O8kCZz4IUmwSrzw= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?whHHokDE7/7DBpY3oMtS4z9QBZf+XiU8oZShBVguabV7B5fG417/KKStXQ6M?= =?us-ascii?Q?6QjKyPI4xfHsLZh2IUSAQG5253x287XNcscJvrhlaALA/eaeBlR+cBc84XNB?= =?us-ascii?Q?VDfP5YqbawsuJUwo9niDToLB63OgOc4O7kNXZ80ysDM7aA0DBGZzMzoNzBYJ?= =?us-ascii?Q?piHDlT34KJ96wkonNp3mH375j07Rpiv+obwKmjvsv1FoCZMShtWvlg/ckm8s?= =?us-ascii?Q?Ple/RQUXAJb83TXGSFo9laLozZG4nIVtvR30rehvirco2hbMUU3TeFWAbYgH?= =?us-ascii?Q?mWbRw+0VXcIusPBWOdeFMUvmmn7RpN728+du9C5z1eHZl9U/MaJ6iTDsyrlF?= =?us-ascii?Q?mVL04r99jbU5QjPAOQ31BPHKJj16285Xt2l8uxvBYZ/aQ/I+0jXnWmu+6hWY?= =?us-ascii?Q?iM6UZrZLrr+muTFwK52r0EHxMF3xCaDbCcxWmAadjbAi/6ysABckfMsdIJEJ?= =?us-ascii?Q?82/iCvI71z+GAk/7ozLgIEI1spon/H6jJS+jZuUy9XqKL4eKf/NDrqNAiAkS?= =?us-ascii?Q?1UgF/a0NXUxx4FMOyDF3D6wmEUMWwKmooSY4mEup2rHYIFTbD0FuBWr4XKNB?= =?us-ascii?Q?tcqeHFufsRe5wsHwYtYZdMVP/KpeNNvYdwUBjoU36IjClc6yu14gCubJEYYc?= =?us-ascii?Q?KjCUtTVkc/JLQM/9QDxJu/994NhD4mBM7B+3X89KwkrrgaaMfkI4P3TbyyeU?= =?us-ascii?Q?LPGg+48eY24du3eXQYcKB/LjC8DcsSmZUQrt5MB2ojTytbtH8XdVnybkfWZU?= =?us-ascii?Q?5eccLw4bu1K7uwKy/Eoo2sL/5FuTGSaixt1dJZBptmEmEcKTEF9+AMBqyJOn?= =?us-ascii?Q?xJiL7ASt/awrqYqdH1Ck5uRbIQur+HG5XpEeKGSMmJaWLZQ69rEOIolFQgij?= =?us-ascii?Q?Hfb4hZGVh/Lk4J3ANK8dRMXReLwtWTEI4PKKqDoxURfXJmeHWdCqlmvlJbYn?= =?us-ascii?Q?1u3VNiOZTZBlr4nxC1vbe/mSnztEnCrrE3cwQUIdrfc4qCJCOKPBsqZcmF06?= =?us-ascii?Q?MDEvD1k8nMf244z0CI2fwKlRjfY/MLK8lOSOENEil7nhTygWCEi093NMhl9o?= =?us-ascii?Q?wqYCqTB7YngAhDIPmxxUS8dygbh8F/ldaez6mFs11EXWHNHygUmQ14MR9f+p?= =?us-ascii?Q?Ja8cIv+OUlXhvZXHjM38mREnrW+wHNQiinklHWpad3jmB0Yr4teZ+egKnd5Y?= =?us-ascii?Q?vcZe5cot4P7Yf23H5tkF7tqjNSlUh4RRHe3ejO1kY4St7Kpi4SmRliSPn82T?= =?us-ascii?Q?xMLtx9+ss22fkG4n8S91Lsnoojal5ii06hVnlgITwo4tBczDX/CY26Y3YxXN?= =?us-ascii?Q?GD+9HHfwfaZCshy6nXWzMBALK9NS4w1Q7re/8w9pjkYVM7q4yDLjnmWhkrcI?= =?us-ascii?Q?KdVNwBcOCNGt/tjSkgaghFI133Sg63B3gdY2jcl+sWdgKnYVshaThRZSvicQ?= =?us-ascii?Q?UualU/lCavbjMxRGGknHNcFyQqktcYJcxbu+GIzbKsoJMVUz0jDMdnKfVGTF?= =?us-ascii?Q?0JzUUncvfs9ldyqwJHfyr1exl3UQwy6QzOFTP06Vkn6/h0l1HyS330jEImxX?= =?us-ascii?Q?sSxRx/LWl8yYwumECS1U9LOl1ZVLULOtArgMAJijI/gRkTl25vrF34VFISjU?= =?us-ascii?Q?f8eqG3+wyklEiF/Mt9H3Oz3Gbjhg2qHL6oUqH1EvL11uqrm0fjxFnUSsosp/?= =?us-ascii?Q?V8vLiqYJGx911mPQ/0JXdAp4ONWA6nYH23ezshlTK3SIRZrAHITe54wcDjDJ?= =?us-ascii?Q?DlLJZMH60LrEAJrZOR1Q10uXTIm+/tI=3D?= X-Exchange-RoutingPolicyChecked: Q5mzRflAAdInlAeN/LzOtTWFtCgHz8OixnxKvVtQNDdzZH82R81JabFOwK0r6RL5xkGa20XJV3VpCx8DZ0YjJNu9aHuCCJrfrXB/wTVr5lduJYcfT46M37FZ/pZBQHxJWF11h3oYiSm7sAu1iAVe7GKs0x8TU/8B9/xN8XsSgZWe1+gTOQKDzw26NzOZ4YdiEUeSeLem/wqj8vsZoJPJddhf2TZeLozgktEPh/UUbVpzq4+zf1mkib1/2YXvAjLp0DzQ/2KFdj6MBlftv2Q4jBf5gbnZb6W/ZivDwT1u2PJ+hUMmpdt0LVpqEJcgHu0G5xArT803w9/Qk9IBiJaa5w== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b081d4af-9d6b-46b5-1cd5-08df2b90c34f X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:26.6435 (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: 52OWT8buigIxgYyDFQMwPj8EyFrppwTj4ARP8tWVxjoEWQsl1ScvYqWhcx3TVn2B+w8e8WXBqR1oGK7wmNwnWhQoFR4ihAQdvR/RBNQQ3Q4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Authority-Analysis: v=2.4 cv=dasVTnXe c=1 sm=1 tr=0 ts=6ad232e8 cx=c_pps a=IN/ktsHfyviFoRwGlsjPrQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=ox8dIxdxdu1w5TD4ToMA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX51btV2DwH9hY M8zynJTNZG+RS0mBufpa0W+3R5crP3waGo/vLGsZD43SMUN1Rd8KPO2UqaNxOq7MYFF2f7k2wIr 7h1cea1cDtg179AmWM4PV2585UM+z2BWxt3iPEhuvUnbcjQz0iiwfYAVirSmvqcPIrleN/9aE1P L/sifSMTBqr4W/QhuNpf/eP1ACGo9CnI51CRmXReVltHL4Cd7uHDyqG5xU0xJAXFs83XFgG4RFK lG8PIELYqTNoLdj1z0w1TtTwQqvv2LH3E9v97RlFFqJ8yuD+ZM1Px+VWdvTE4fNehqXKHmUw5ih uMNvfrYT9t1Qw/faWnGoKfwY+Ygzpfwu7ts304em7u9E7thzCa0NclAOMillyK7x8H/45s8VOIK uEdBl1kLZOqDqGweQAlhILGAJDTNK8UgICegf4/SOrt3n+L4Sqa+8jJGezSg2E+fG8+qfJXjBLy FG3fwHP+n0vvaAtbaoA== X-Proofpoint-GUID: 0u_bCT4tLOdJGIP2w5C4kBHRxEuLytxp X-Proofpoint-ORIG-GUID: 0u_bCT4tLOdJGIP2w5C4kBHRxEuLytxp X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX064D9u/KYzOU +Ft0DmQL30uStHFS4B6VDS07oqAgwXMHH6RFk5xKWJ+I6/s266Zwcl/uZ6v9b+SrdeO5PlK8Twe QiJ0W3GyNMV8aLo0TP8ap2WLIPojRks= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-33051d/1792160510-6F2C84E9-72A6E749/0/0 X-purgate-type: clean X-purgate-size: 8111 This ensures consistency with our normal QOM-based naming convention. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 71fdd74266..644508a44e 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -70,8 +70,8 @@ struct I8259CommonState { MemoryRegion elcr_io; }; -void pic_reset_common(I8259CommonState *cs); +void i8259_common_reset(I8259CommonState *cs); 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 86b1ffea4e..3a960e48e6 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -108,7 +108,7 @@ static void kvm_pic_reset(DeviceState *dev) I8259CommonState *cs = I8259_COMMON(dev); cs->elcr = 0; - pic_reset_common(cs); + i8259_common_reset(cs); kvm_pic_put(cs); } @@ -117,7 +117,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 700412df74..97ecb77407 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -124,7 +124,7 @@ static void pic_set_irq(void *opaque, int irq, int level) int irq_index = cs->master ? irq : irq + 8; trace_pic_set_irq(cs->master, irq, level); - pic_stat_update_irq(irq_index, level); + i8259_stat_update_irq(irq_index, level); #ifdef DEBUG_IRQ_LATENCY if (level) { @@ -215,7 +215,7 @@ int pic_read_irq(I8259State *s) static void pic_init_reset(I8259CommonState *cs) { - pic_reset_common(cs); + i8259_common_reset(cs); pic_update_irq(cs); } diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index 705a28ecbf..31bd663439 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 *cs) +void i8259_common_reset(I8259CommonState *cs) { cs->last_irr = 0; cs->irr &= cs->elcr; @@ -53,7 +53,7 @@ void pic_reset_common(I8259CommonState *cs) /* 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 *cs = opaque; I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); @@ -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 *cs = opaque; I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); @@ -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 *cs = 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 *cs = 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 *cs = I8259_COMMON(obj); - pic_dispatch_pre_save(cs); + i8259_common_dispatch_pre_save(cs); 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", cs->master ? 0 : 1, cs->irr, cs->imr, cs->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 Fri Oct 16 14:21:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452001.1666898 (Exim 4.92) (envelope-from ) id 1xHioj-0003yD-2f; Fri, 16 Oct 2026 14:21:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452001.1666898; Fri, 16 Oct 2026 14: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 1xHioi-0003x0-RX; Fri, 16 Oct 2026 14:21:52 +0000 Received: by outflank-mailman (input) for mailman id 1452001; Fri, 16 Oct 2026 14:21:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHioh-0003Uo-6w for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiog-00CcZL-JX for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:50 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232f9-2eae-0a2a0a5409dd-0a2a450a9e84-16 for ; Fri, 16 Oct 2026 16:21:50 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad232fd-f2d2-0a2a450a0019-94a39b0c0e6c-3 for ; Fri, 16 Oct 2026 16:21:50 +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 69GE5mti3125736; Fri, 16 Oct 2026 07:21:45 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021092.outbound.protection.outlook.com [52.101.52.92]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4haysxu3ct-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:45 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:43 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14: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=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=4Zzg/I05mP5n7TY2uFK7TpWDkHes0ZRgUzLc2R50k 64=; b=BsVABufdpTHxVBf1rZmKW1YXMoJ8A+fOCwwFZKC1fWCsVLEH5lFWo3zSr uVI9oD/pv1P1pTbN4azkjHP8wHFNi0PKUoTVr7ZyGw+LfxKhDHTYFdT9yKgCR0Qb smMRV5mdJ22n8p/MbjVvliuG9xJzeCdq3pXWaK2xnoc0CQGAYX5OIzzT7FDCn9NT G/vYYtuXVCPx29BjVAo8ULIU+OmOQO6eQJmRoVGZ1b8yI7aOWQ2htw4yk3Q9SR7S WqZ7WfxqPTS9ToDIX7cNN3+bldqPrB7grerlc0WwkvZAIESaTloVWznnanXAQzeh KA3/UYtgp7pc5RzRAmmn00NMSgzYg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YGHkxAcfccQJNVMIybVsJ9qBmZUuevjH/rO/7X8kRukR3GCa8MFwxAVSHzpSJ/uFKE5RVGShZVP7Dih+bWq0eDE2l145VxyP5EyHQ6OSHC+bhGfrkqruaIvNX6MX3UfjhgOf64TiVx/qmEBt+AijS5WReDC3lClA/cr5qM9RnlsfzzaMTY5hmm5WcJwzZBtG0BLfAYfqmweiquRbWlomxjC4GHw+5l9U1Y2Pn+3akTbmROAKhmvebR+iJwLI6kMbM0xf0SL6r9Msosf8N5aW4HGkHZ5IGrnpzKH6a+NyFJoSTKyY0Y5Th9ehl4crOQ2km/OgbOX01CcHokmPJvAcyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4Zzg/I05mP5n7TY2uFK7TpWDkHes0ZRgUzLc2R50k64=; b=ZeE+TUJukb9eiofgDg0MbFlhBF+MTGPPSn9uc6c/NrYoeQO5Vv+SrvQe7vYl5luoASWtrmkqs0aOHKe8rwe38MJVUnsodHOg9uuO0kgejjP+CCgkA5vyjM40VS2+7XH78UeYjYvWGeqDl4e675QXySXYqCyU1R/NWUqbkAQUp5P74BOspvnvRR/NvLmDy3uu3RbmbetT3XKabE8+ttx3dQk+egxFMpp0as5eQ7THQ4LuHkTE5SfHhdzqRts5qVTwNd6tFkj0XaNFOVLHOesrbBg6COOPX1tgKPfq4JC/FrkljBQx/6xsnFmTsNWtJSR6T41GC78ozqHYI+PWJRM5Aw== 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=4Zzg/I05mP5n7TY2uFK7TpWDkHes0ZRgUzLc2R50k64=; b=OzvHEovqkXOOdQeBpT8uql2t+FxpSZ/wJUB9b51bMzVPHEOENsxjFBSbxjb6fEdtw3YKbLJPL7WEYm9Qor5wAOURDK5+iGY51t7M1rGAtTm3ztvMyiuXktqLDVdEzeS8o3pt9+jwsaR05bmMkPoSMVwq3CxbsMdZGKaAgdO/pJj/DIdLNseft9k2H1dShNa+Bkea0gcKbxfczKLJXHBcZrxoi+9bRFH8pJPM27wW5JmaWgFDsCJ9WcPHX5SiFa3useom/m0X+MX9MJqfT40lDDyyVRe4hZXVs7OsRzbIut2SCeoX7BxDbSFOlw7cA2glf4jkFxXoNU7U5oAfEYGfTg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 16/27] i8259.c: convert to use DEFINE_TYPES() macro Date: Fri, 16 Oct 2026 15:19:22 +0100 Message-ID: <20261016142031.1204281-17-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0090.namprd05.prod.outlook.com (2603:10b6:a03:332::35) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: efe637f3-c11b-48f1-5e43-08df2b90cd7d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 0i/zb9aaJBmuKkcpNLFyiGWoOfUDVXPUrOFIbzYZt2sMlml1U6Mr/x+NpPAYzBz0LEMu37SKjv8eDVI0ET3NhsGHu6bOAuvG0blpIXnVJ89Zm4F8Fg8yyoFFkHv0mqQKjXXiW3haIY464eIK+asOdoBMlJbJLpoEVRVLth072c/Ck3gKQ9BQ3SGhTa3LI4r5hIxf2jPugC4JsksMwsddqsujiCHcljlDi5sK5Rh0mdldvs7YYbYfrEOnqKB16cvazd5raeWwuTSarpRKP2dBKKK7G2n5IZZIJp3XJ5685N1AM5/7OQg+HXk5zFxG3lRiVxTjy5Uy+5hR+oIbkpsFS9KNKavKXZ501iipjqfgbe441ql1Ol5KfkUo6gYIp0bG+UeTTdu6NmaZfyr4Gn4CiuL2sutksq8SBcGmmrNZHEUnlypJftUbnqJuntQ7k5kusP7Yh22cra75EhZPDyFyKrUITGlkej5FLg/T4cGPXyScZQx6caXViGnirs8nzBzf766F6M3eLGBsOBvnnpqoN+EVsO3N1iKYK8f01HJEOv9PBSSUTPK2ZFLxbfomsO59Z/wmgAQBbspIqjs8wwBt5GFX9lHH+YFH+MMzd/A9n0HDz3dCTx4rYgra2gsMLJ9BRdaDWXpKRSuXOie4Y1fcBUQNmq0OBw/OQlyYFLHHvNU= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9Bg9Zq4TypHhRQYyEWrusTDlAeOEeQuIGIqUaNPPRAIvLThaJn194ByGBVmA?= =?us-ascii?Q?dy395nPr04eUuZUEh3tM2U9WXtcUTZ2yQ/E+svAakmQfUl/Z/Mlu/ykzP/99?= =?us-ascii?Q?XWv2GtE0DyaVboeuPdXsK3h5jAaj2MxzynfmowlkFEjDOKkgE7b0tKBEhL8M?= =?us-ascii?Q?5RvieXjl8WWjAbGgNiMnaWc6uSuUqQG7R/93gqS+wdrvGSCbvrhR3BwEJXOc?= =?us-ascii?Q?DnIMFiQaMgQASvGI5TSSEWswcgy+kzFXVM2W3h+X5e3aCCLG6gxLyDwWvMaq?= =?us-ascii?Q?bF9OugF+HU3UyVQk9zhVANnSWZfxdK5XemUJ3EkDRmfvwehJ46rs6LTfkMiG?= =?us-ascii?Q?cv7B/D3vy0cUsU/hbnvm3nnJftUMpkMP08r0NGQTqQTWje0/vSpbMenYDhP2?= =?us-ascii?Q?Nn1/tA4zAdyPPg2/xP9WTIRZrGItvulk+TuhZQOecqeKZhAP4LR2hZ0/Pw9d?= =?us-ascii?Q?YWYDkc9fooKYlvT62pAceas4e5Rz9gl0FSUzlsr/G22zMXqg1Z8rGfO60CXV?= =?us-ascii?Q?/c/D5BAicsc+96CEBbJffBO8IOw51/4vczW3t2UM8E757130/R8IsW1pkuiT?= =?us-ascii?Q?sFczHcG70j+jZGMVSTmMJge/qYaC9L/9fDIPxGcMRMqbttaFKHAEuK69FPOL?= =?us-ascii?Q?Dc/muYcT0Yj5a9qrh0bLlZYOwEL/xbLsCg44ZqHXrNsE6GcQFjq3gjl824tL?= =?us-ascii?Q?kH3ujyHwWnRQSxyyPt4hBS7tObc80IQ3l9iFRRsBBFyKeJVcGeMO97G8ieeH?= =?us-ascii?Q?2eoo8jNGw5j2PrD8utSP68uhvZJ9A4t6Ae2EaDO5/R5EXlcQx0AoL6x0B0Hv?= =?us-ascii?Q?z9dsOue82dXCT2mhSGw47UACMxrQPXSbpTOLlTLMPavbsoyBGPIzU8mNKTeq?= =?us-ascii?Q?bbQqD3G+Pbl4Z8oYdaROAoRThaX62VD88EpuAbR6nYvVWQrUsjF4rY6JAB2l?= =?us-ascii?Q?/LumFVPgRIpv4ucxzSDRnBs46Fa22Uhx4ZyHe0uU49S24YaAcR7LQfQrgzyy?= =?us-ascii?Q?zh0G5YrSAsoWoe816rsA46gUXKM9fteaKe5nC3t58eWExrr5tiqXbR+NCJm9?= =?us-ascii?Q?H8CdhmQhdWKTq1wtXp8dVk/DD7hwRkppHfcWf7tvMgb2fX5TTxnh/zKWuvsB?= =?us-ascii?Q?cBKpjuMyWNssGeZOVrK3N/gswCs97DrA0IaAOyYqrR5sr/JGAoNxj8mkKDqe?= =?us-ascii?Q?y15AVGn4G6J4e6Ngp0Cn3LdyBpUwmr96sTWtgJxUmOy4xOyFpMNMHAS8PL86?= =?us-ascii?Q?sQ4AvyVKNZjmxNGF0ComDcjgGHehmBwABp/Cd4myUJlLoXdtG+fZ7D8oGd+g?= =?us-ascii?Q?guDEodb5qW5lNVJ3Fd6LS5SWL2L8kfAUFGR1TS4FEhyo6sX7R0Fz5R1Qx8Ux?= =?us-ascii?Q?rbxWCop7GfWrKBAxVbNyJdDj6UlL5dZN2MT1mZ+0G0s+9AXQlS0XgeMgok0E?= =?us-ascii?Q?AsRm4tPBj7+nGkT3W9hKxuZK5ML4MdNQt8d2zo0y3/+ev05cpm7fv8KGJisi?= =?us-ascii?Q?MlA2KLdt2S2ChHWzwAB1L7SZTUnqCC3z6/dBebXwEuhjcZ61G1pZsF+txrLX?= =?us-ascii?Q?8qegUKh+jOTRNIQf3+Lk5kUjIMxYuqYY1LZkMBVEenDsAwEdkK8YYYG+km0o?= =?us-ascii?Q?AYw7UPQUeOpaR9FHvGNy7RMqnS4jfQehJjoXDUiMXgDof86B6q8Vx4zCpbpH?= =?us-ascii?Q?DPUxdWfPxohqwlO2bv3afRZH9Ok7SNqVzQKZqae9Md/g4wboDMHXVYhT4ks7?= =?us-ascii?Q?HSf6JKaktfCkzW30AgPsdRKSGOCpQgg=3D?= X-Exchange-RoutingPolicyChecked: 5KpNv3oTcIuLKBsuiGXD64zFMHPSc+b6zExmRDe9I2kDiI8URLo0T+RagjBVWkO2D1FwoszGBac+oy0u+TwEVnSh+ojPHFFnBMynguVkzceDEV00kDlVM2O2uA0Wop2gpNSpw5WEjQ5FgIAt+wgyKMs63cySH+pqEB6oLGPC//29g9EgOONkt/zjz8ecWj0K7d37XIxIhx71+0OgWThR+eVXZdnW4GbwJoRrRZsUQTpwhOVhfAqi2y3Sswi3Wl4CKuWhyLAlc5IAX5CtEY6vW4GABSDx1bMD4U/jlAz42yNgdHXXaiP7B8MmhjzjboiY5NbWpsE9FjDQ31/Vm++u4A== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: efe637f3-c11b-48f1-5e43-08df2b90cd7d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:43.3944 (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: F0VcqJqdL0OWWtDDq8d6tc2fKoOghENF7Vs+hszPvquvKWQpaqyGX7AtoPjPDasjWFlVPGEijAkZk6QtRON2a6tqUeWrzb4qhn+O4GQwEDI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Proofpoint-GUID: 33B_WShAIV_5Zv9_CbVnyWwaMnhRYB2e X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX+zZ8o0q5uZ/8 82xBdkohUZVRrGmj1ob0L5VTNpzB90P5ylh6U2G/pUjEv9OH+EQxvdibvpT+8mAdnbOP1SM+QKl +FZIb4abPPEVXYuGJyDLtOltu90pEvx/6JI3W0o11aY7vNVBWyZp6Tpwkz0mDTkwwLwRugAX38r kxSVXua9wc2ZyxFErSf7g3PjUqJGFMRxcB4edKmXNqy0I4p04DyL+aeAqBK+xAU5e4k1ewzgsGQ RsT9EqYmV/YHSXibedNFZtqzdnKevn1iC+64r2t2pcAT7YPunmB+Mx9vxI4FjF1aS9S/jot1wlt YgRkN6lGE1fXjaP6WtF1MBbSvRUZH26Y3wDSuiY0RctbiRXUKWGR2A92KKLEar2s/AiR6wkVM8d zSpPUCclio/jYzdM6pQBLdGtPrAo/L1QVjPP4wr2QxgukwYWnRZLbwkELfSW93xKw2yWZ0dVB27 8H/f8TWnnnljdM8Y3Ig== X-Proofpoint-ORIG-GUID: 33B_WShAIV_5Zv9_CbVnyWwaMnhRYB2e X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX5hjKLYPA5mDq 16OwMFVQYRyVB1mLtzBl9b7Xe7JM3qykKEcPs43eCkfbM2IUYMBAK49Q+dszP5jAcwkD1SBCY70 jkra3oZefUTtTQCRmBWZPShc+FgMBnU= X-Authority-Analysis: v=2.4 cv=C/x8WgP+ c=1 sm=1 tr=0 ts=6ad232f9 cx=c_pps a=LITHeb8NCZqLQJh3dVn19Q==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=lKrOaJ4ZLGcPJhkerdAA:9 a=cvBusfyB2V15izCimMoJ: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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-4011c0/1792160510-5A3DCCFC-C3576772/0/0 X-purgate-type: clean X-purgate-size: 1193 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/intc/i8259.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 4b34e5a649..e5fa0f2e5e 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -447,17 +447,14 @@ 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, - .instance_size = sizeof(I8259State), - .parent = TYPE_I8259_COMMON, - .class_init = i8259_class_init, - .class_size = sizeof(I8259Class), +static const TypeInfo i8259_type_infos[] = { + { + .name = TYPE_I8259, + .instance_size = sizeof(I8259State), + .parent = TYPE_I8259_COMMON, + .class_init = i8259_class_init, + .class_size = sizeof(I8259Class), + }, }; -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 Fri Oct 16 14:21:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452005.1666920 (Exim 4.92) (envelope-from ) id 1xHion-0004ia-6H; Fri, 16 Oct 2026 14:21:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452005.1666920; Fri, 16 Oct 2026 14: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 1xHiom-0004iJ-Vi; Fri, 16 Oct 2026 14:21:56 +0000 Received: by outflank-mailman (input) for mailman id 1452005; Fri, 16 Oct 2026 14:21:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiol-0004dS-TC for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiol-008oLT-9m for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:55 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232fd-8faa-0a2a0a5109dd-0a2a4504a998-14 for ; Fri, 16 Oct 2026 16:21:55 +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 6ad23301-b57f-0a2a45040019-94a39b0c156c-3 for ; Fri, 16 Oct 2026 16:21:55 +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 69GE5MK93333355; Fri, 16 Oct 2026 07:21:44 -0700 Received: from dm1pr04cu001.outbound.protection.outlook.com (mail-centralusazon11020128.outbound.protection.outlook.com [52.101.61.128]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4haukukqe3-4 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:44 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by BL0PR02MB6547.namprd02.prod.outlook.com (2603:10b6:208:1c8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=rQp9h/2ajwF1qe/Mp8V/9gopdrz0ooiX8EYLWq59a vk=; b=BVZz4p1LerFy3PNcVvgEKNaK0AD0f/sJwbwBN0VGlptHvoB4A/PDV58bD w4Tsd/aPRMYJXc4hDGE2HStbESH5x2KsLd0W9/TERNPua+JbpHZYMbWFx6IoTt3P 7wS1nuqCDQz4p83TgP/xRbMEKnBrQVtAtqBAX9PmiMuzX0VhUzdQimiDFQswL1P5 lWnTPE45H28H3frpQejG4K+ZmzhI/CqMjO6qlTIHHTFvzZLRnBOOAnrvaNw5CGjE adUVX6fc86PvpHfDzEdyP1InzXvS4zJaBcpkreDtKXuACAD4oydhYNwrtdIVlkpS a/9b1t90S3fo0bJX+lAy/uV/3KdVA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ikSKsOyH1KWIZzeqXeHlCrbU2BfiT1YDv+POEnD/SHm1ZWRoJCy7lttTvW11l+J0XTQ0NlaIOLZ2dcDB6aR7aPBbexXQF11zc7nu3x/dS3yb93QIpRSqG/kewXYogFM9dvEs4Y8yF4aNTuqbxgZY4jwxFf452CHcsfy2f2jpT6zwZC3THu9Lhyrfd8GR+bPoK5yDc54S/q3CBs/uekIaLNoxITFiPs73d1mMR8H7gWQAl6BibgVY4/rE9DhV4IJIhc4y7DGPUBYJ4wHPET2Pl4R0Yl1FUcbBCB1x4gTbShBvZ7EXgtxYmWOZwKIMdUS74Zr9wtjH8iIdf+nnT6NWpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rQp9h/2ajwF1qe/Mp8V/9gopdrz0ooiX8EYLWq59avk=; b=a9OeALpQDl5dmw3N4/VmoN9IVzLuQzfolX9lbSUmn16DgJ21jdUY0mcv6mqCrfUDjSRqwKG/ZrOtB6PiCFivwygWpzCdCaHgQCb/6uoyLGfOPWQX8X/BdE4GkXQ024N+SVaXbigN2K5Kv0+COD7IDVZoS81lpH1H+JkQWOR7hMW4MI95sDlJarsefMBR4+1iE92ElUcY/oDrxNDm15zN3VlT1KzR23bWqJ0le5nLLWvbaUCwRjHUz8jsnzNWNH1T3NNXzgiV2gGs5blPgoyVaPmFvAN7UjF4XX50hzZBaPmOCFfi1bB8HSOCrKp0WvSgDGOP3PSe23WyF/FhAIpazg== 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=rQp9h/2ajwF1qe/Mp8V/9gopdrz0ooiX8EYLWq59avk=; b=VznEc69NPcS/hroBaq+pElWN5lkMo2kNZflUhgByi2Ah7wY+etfxV5XzacT6tHv9ph4RmhPz65uUprnWPYsYh9JieJA2HUsQiiSckhmhRPMYIZNy75DFlM/x33hm50YRgDrXZFg3GoN6Q8ELYdS5Br9pKwMtDnfRwAZ0OUy4N/8uSdK+mrgPChB8AWUgGc8YjqPsAvK3Yudi1jXYjs3nMm7V/oXXdOBnoBd8KvxDG9ECqf0AL3G49S466ioi5wg0invRRjKrwhvcfQfXT5Kl1lADRNp1yy7mXFvm6wYoka7dPE8WAeCWcqcaLZZH336zaRN3rOv1RKze1xracAcTFg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 10/27] kvm/i8259.c: always use cs for I8259CommonState variables Date: Fri, 16 Oct 2026 15:19:16 +0100 Message-ID: <20261016142031.1204281-11-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR05CA0021.namprd05.prod.outlook.com (2603:10b6:a03:254::26) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|BL0PR02MB6547:EE_ X-MS-Office365-Filtering-Correlation-Id: 9cb69322-591a-4a5c-8fa7-08df2b90be6a x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: h3+4dWHUokHciwAntrMGHlrzYxoniCNtGJhojn1OP2KW1Y1bWdTKXx5ScDBQfLlhnso4wQIbawdCq8zKzvI5B7EDS1ApL5e3Z6pjIdU8fn3QLx63JTJmnhCMDKLYMHmWBxHVF6p2aKPutiQuZH9gF+IoLPHp6LoRM2QOwuZerBW9WKHoJ0yfLhGl+jOdZ3fPn7ZsH6xA1y0DSnUpPLbybD+bHSbbrlw4Y499yWko3SahJezoOu36hIYvqOr/qzTHgsbAU85aYuUG7UXKjckp6TT+fV8empH1Alqxql2uMJTBCvQ2LHAlw1phneTxNtA0/7fzMv3Iu2XUzSfdglst9f0XIaZy/0azTrZD5++HWnTV2+5i3EIxi5VklDc2DbX0qdEvqOgL2ocZlU9j303xYfuG+7zvzOKmYqLYgMbV8yI/fBC2EvA3DI2W9x/JnG+ZjZBEieV2XZWeYnqdUHpAkgbe9EPWQ5qE3ZhdSVCOloES3r/shhEayPRicOrsQ4HHTObkyQtqeLOQQyHZFXtii4ND+Vx3niTVkcxAENeFQKIkgku/Kx4LdTB2F27OP6R3VhkqxY6euHpsilobpj3YR1H0s7C8tBYgGDXo+ErjGFe6XbP/FNyzwlYYsBnnBWdmm4+S9HBxnYoAyvAx9UBa2pE/TxbpxVL0/69sIvF5wtE= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?NNNscgb8dKtq3S0Poi1usa9G+LKHgzUj33tSC84e/0gIx96JRQMEMuqoOTAy?= =?us-ascii?Q?0GSWHh7cpdgQOcrfOaxTez2I61HSOtyhhGUvDQeQbabkkauBVMaI2fhZfoD0?= =?us-ascii?Q?koppSNPTDsYgmDZbgx07CG5DGMHWGCvTXmYzqL7gs5wr4zgLKKDbrPUMH1xK?= =?us-ascii?Q?G/iQzUNmsreYD5Pgf6EWtkbEEVqD76vGEQm4kLTCs3w2PS/ItqyCKLFad/ju?= =?us-ascii?Q?fTPM7pDOX07kD9/tvgq93EOdfzn6u2eP/PgHPvLzBx/z+XQbgjsUP+0cu8GK?= =?us-ascii?Q?myF+l25/TlzL2C0akRlVHKaLXpkp2LitRQ8P28iDTwRk2SjQqmBxMFNr6TDR?= =?us-ascii?Q?c7Jz6nmB9HTpe3447t6GdfRAZzGv5V2vsq+ot9z5eUln1Pv1OHmsZZg1bBA4?= =?us-ascii?Q?SoBwpv+pV6DbTH4Lh8o4cQpBSG8p7cM5Oc53wB41YxfrPFk5ZLnzDGF7orUl?= =?us-ascii?Q?lrFvecS8EONdhsexHa+h4QJEJq++lygrEvyRyhuOCqjCrkMAQC9+LO/4XyhF?= =?us-ascii?Q?joq+045BeFhI23zT6aUTOapGgADsIp+nsZtdCRQgFUOCGsgGM/siVRsSnjkD?= =?us-ascii?Q?QuyEjG6fsENH+rCnl2jCMA42jQJCMXerDb00/C83MFtSpsGPHapiMWCKlw7e?= =?us-ascii?Q?t9sPdW3TpurhrtQTiY9xT8UjngjMVYbOw988DFjL4UvDJezZMNJjxixud+x8?= =?us-ascii?Q?f/0k2LGdn0xlEAmQlUo5CEX4qLtPtRyheM0V1XvxQDe07jX/04y2om0ajMzW?= =?us-ascii?Q?5cDuVcvQ1CNYlR0FJY2EHEELsJC+YJvEbTXE6/kLd2rYLVL7VuE8aP3oCebG?= =?us-ascii?Q?G1JAVcKMjzEzfc/RaJxPY5EfG/hUpXfwjpRzP5qJAsrp2LdkobUiF9X2dRtg?= =?us-ascii?Q?8VMf7zJO38zMFHyttEmXiL3kOtLwjOkOn3Lk0tMo8hN0EqlFj2lngvYVZfwx?= =?us-ascii?Q?fQOQ/Vd/Ivkx0swFKWaog6L7x85qvZbSm9RCunpsgM0y0mgP2OyGrZFOTNJy?= =?us-ascii?Q?egfyN2DFjWWnZU+pgn6GMk89271+I5eYuvKse3khL331JnEutdmOacPLjN7o?= =?us-ascii?Q?64vRGHeUnFxSd2fxXVAFT8BG33mjVNmryWFO3HvzMTDkFcjbeMjZ8VaNQiSg?= =?us-ascii?Q?mudWJ89Ps43XIWhbxxmaJT75V1GFcTCgssKST4uFdEd/upFm3aOAbTvpTG/g?= =?us-ascii?Q?eV+CCQ5u0j/R+9qi5U8xGvrCFDu31c8aPcwsiOims3xvfBF15yxmwOUsy6i5?= =?us-ascii?Q?FnoOvrwPosQjHB7vN3C5S6fu3PvhAtkATFtBmDDiS4N6Z2jQfvLOfbAqCMU1?= =?us-ascii?Q?x5UnN4JBXAi6BQINCXuPCGEYwU8G7/AzD45JfaaomOpCT5p2edcffJ1NFYgi?= =?us-ascii?Q?x1cWxz7Brpz9QZA44tdMwuQrx3ucSlzffOualulyvfLwYRsZ/PfrHqHXW+hT?= =?us-ascii?Q?sRCuoTED63bjcshY+eF7Kwi9+vzpQeIcl7wuAd/ndsCprrFA6Sr5KPxTwh25?= =?us-ascii?Q?IlSR5TLkcTp+y47J4EuawqpCzhHH909oCLyT9A8lTkfytkLq1syTT76SiZx/?= =?us-ascii?Q?25+tZO3x36xEd3kpP2qWDvvp8ThNn130By5WnsK6TvkBOuquDsMowa4TaU9Q?= =?us-ascii?Q?TwV9Op0Zl+Mf4hPyL8kVNdsv+yyTb37tGwO52F0wWEhVK6t2vnE4ZTQVPF73?= =?us-ascii?Q?d2t/6GMcc0qZ0NSfThgdyc+QlJnLYBp7+F4QUbvVkuY4dCr+g7iXvq4BA3dz?= =?us-ascii?Q?+pBVJ0R5rlEDJggfOSld+PS5FuRKAUM=3D?= X-Exchange-RoutingPolicyChecked: EOo56rIx5CTJC554u9DZf3LHzx3+epWkAPMfAn0AI4l4meQchYxu5+xkMC1dcBoHsk4/qLO9Hp/w5/K82Ds2EmTUOAN78SZROVskZP9I8eCHmRpaSCRsghZmyU2BCUwQ2Fl1FxW69Eu1Am9SwHdctCwyW62qoUGufQ+K3NbeIac3ZYlD3r6yu72xQDT+7PSkVwZU/XtYkesrnm1RsCObalDk15mRuSXkMtNH9eS0lhtQFfmcbhdNyCRRnxN0MJB8wfHxIYGZnuWusAq262qCrTXZvfLq4dK3vpcCoQ3oBMfiUuKRr/sZcUHKSdSz0Oe8TLnKqx7o/C5ETbOkkx8W6Q== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9cb69322-591a-4a5c-8fa7-08df2b90be6a X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:18.3323 (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: 3CPyAiDUUj3XGCyDLiAftW8srhRxKFch2lhjINPQOssQd/1Ygqgp9Va3R4o9gqH42zrmSlmHAhHxi3GKPY0fCx08w+ZnvWbC+qBK1M9ERNI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB6547 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX40ymsmU7s2WA AXr0jAkO/bJYaRKBZ7lluad81MvyyinZ6fRX5cdoQCubrtk9wnKx1CAyiuo1Sm94yk+EMPalN9A Evzao9IbwFiNEe7Sam1ykxV97zdhp2Q= X-Authority-Analysis: v=2.4 cv=G+OJgNk5 c=1 sm=1 tr=0 ts=6ad232f8 cx=c_pps a=8h7WK4dQWB09CNKj11a7yw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=zNa_6NNZsa7Vo5epgMYA:9 X-Proofpoint-GUID: 8JBZLFG7-_g7VBHSOCD5LHGfV5f6xg-5 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX2hpyj0/o1IvH /0qzXsZN3qzZXIHhrPEUxfUHiefDS6Jz+cht86Au2RBZOtGpy7FKSeiaMkf5UGJJSBaW5aUzIhh zi5zZyD7jb+xyIn0EMFhSMdjh0L9nv2svTvofqG9okxJoCgXEIJss2lsWsxrUmedrzAN/8zCyZL fBpjpajLDjy+7KwSxfBbP9NG+6KbgwxM4JSidG2Z6arqG/R81cEC6FgQcSgAPOQl9a9EcnMI5v+ sKCv2A/JZF3Iu3KrBebyi+oNxTq8FjBbAGw8y8WIREWUroRPFthSlEBg5k15g6d9UgkEth9aAcG 9HRxHEzCI82COMWn+Lv6YmuZqj4Bbjx05s0a/mMBUgnY19nq8jQBOQn/0JS78wwbU6SpSSCIgvg 1jgZqwObweX6JbSSsEVIkOEFTQPoSyqzTUFHBRgBmV838BtKWSkoNidy2tughzYxIPRAvevW0BX 4OSAmtGIhP26mBsIFyw== X-Proofpoint-ORIG-GUID: 8JBZLFG7-_g7VBHSOCD5LHGfV5f6xg-5 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792160515-C30CDB50-118B43B8/0/0 X-purgate-type: clean X-purgate-size: 5245 The use of consistent variable names makes it much easier to follow which fields are being accessed from I8259CommonState. Signed-off-by: Mark Cave-Ayland --- hw/i386/kvm/i8259.c | 86 ++++++++++++++++++++++----------------------- 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 8ae5dd39b5..86b1ffea4e 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -36,13 +36,13 @@ struct KVMI8259Class { DeviceRealize parent_realize; }; -static void kvm_pic_get(I8259CommonState *s) +static void kvm_pic_get(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; int ret; - chip.chip_id = s->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; + chip.chip_id = cs->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; ret = kvm_vm_ioctl(kvm_state, KVM_GET_IRQCHIP, &chip); if (ret < 0) { fprintf(stderr, "KVM_GET_IRQCHIP failed: %s\n", strerror(-ret)); @@ -51,50 +51,50 @@ static void kvm_pic_get(I8259CommonState *s) kpic = &chip.chip.pic; - s->last_irr = kpic->last_irr; - s->irr = kpic->irr; - s->imr = kpic->imr; - s->isr = kpic->isr; - s->priority_add = kpic->priority_add; - s->irq_base = kpic->irq_base; - s->read_reg_select = kpic->read_reg_select; - s->poll = kpic->poll; - s->special_mask = kpic->special_mask; - s->init_state = kpic->init_state; - s->auto_eoi = kpic->auto_eoi; - s->rotate_on_auto_eoi = kpic->rotate_on_auto_eoi; - s->special_fully_nested_mode = kpic->special_fully_nested_mode; - s->init4 = kpic->init4; - s->elcr = kpic->elcr; - s->elcr_mask = kpic->elcr_mask; + cs->last_irr = kpic->last_irr; + cs->irr = kpic->irr; + cs->imr = kpic->imr; + cs->isr = kpic->isr; + cs->priority_add = kpic->priority_add; + cs->irq_base = kpic->irq_base; + cs->read_reg_select = kpic->read_reg_select; + cs->poll = kpic->poll; + cs->special_mask = kpic->special_mask; + cs->init_state = kpic->init_state; + cs->auto_eoi = kpic->auto_eoi; + cs->rotate_on_auto_eoi = kpic->rotate_on_auto_eoi; + cs->special_fully_nested_mode = kpic->special_fully_nested_mode; + cs->init4 = kpic->init4; + cs->elcr = kpic->elcr; + cs->elcr_mask = kpic->elcr_mask; } -static void kvm_pic_put(I8259CommonState *s) +static void kvm_pic_put(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; int ret; - chip.chip_id = s->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; + chip.chip_id = cs->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; kpic = &chip.chip.pic; - kpic->last_irr = s->last_irr; - kpic->irr = s->irr; - kpic->imr = s->imr; - kpic->isr = s->isr; - kpic->priority_add = s->priority_add; - kpic->irq_base = s->irq_base; - kpic->read_reg_select = s->read_reg_select; - kpic->poll = s->poll; - kpic->special_mask = s->special_mask; - kpic->init_state = s->init_state; - kpic->auto_eoi = s->auto_eoi; - kpic->rotate_on_auto_eoi = s->rotate_on_auto_eoi; - kpic->special_fully_nested_mode = s->special_fully_nested_mode; - kpic->init4 = s->init4; - kpic->elcr = s->elcr; - kpic->elcr_mask = s->elcr_mask; + kpic->last_irr = cs->last_irr; + kpic->irr = cs->irr; + kpic->imr = cs->imr; + kpic->isr = cs->isr; + kpic->priority_add = cs->priority_add; + kpic->irq_base = cs->irq_base; + kpic->read_reg_select = cs->read_reg_select; + kpic->poll = cs->poll; + kpic->special_mask = cs->special_mask; + kpic->init_state = cs->init_state; + kpic->auto_eoi = cs->auto_eoi; + kpic->rotate_on_auto_eoi = cs->rotate_on_auto_eoi; + kpic->special_fully_nested_mode = cs->special_fully_nested_mode; + kpic->init4 = cs->init4; + kpic->elcr = cs->elcr; + kpic->elcr_mask = cs->elcr_mask; ret = kvm_vm_ioctl(kvm_state, KVM_SET_IRQCHIP, &chip); if (ret < 0) { @@ -105,12 +105,12 @@ static void kvm_pic_put(I8259CommonState *s) static void kvm_pic_reset(DeviceState *dev) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); - s->elcr = 0; - pic_reset_common(s); + cs->elcr = 0; + pic_reset_common(cs); - kvm_pic_put(s); + kvm_pic_put(cs); } static void kvm_pic_set_irq(void *opaque, int irq, int level) @@ -124,11 +124,11 @@ 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); + I8259CommonState *cs = I8259_COMMON(dev); KVMI8259Class *kpc = KVM_I8259_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); + memory_region_init_io(&cs->base_io, OBJECT(dev), NULL, NULL, "kvm-pic", 2); + memory_region_init_io(&cs->elcr_io, OBJECT(dev), NULL, NULL, "kvm-elcr", 1); kpc->parent_realize(dev, errp); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:21:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:21:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452006.1666929 (Exim 4.92) (envelope-from ) id 1xHiop-00053o-FQ; Fri, 16 Oct 2026 14:21:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452006.1666929; Fri, 16 Oct 2026 14: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 1xHiop-00053b-8h; Fri, 16 Oct 2026 14:21:59 +0000 Received: by outflank-mailman (input) for mailman id 1452006; Fri, 16 Oct 2026 14:21:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHion-0004jH-C7 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:21:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiom-00BWwx-OY for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:56 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232ec-e002-0a2a0a5209dd-0a2a450ce658-48 for ; Fri, 16 Oct 2026 16:21:56 +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 6ad23302-f479-0a2a450c0019-94a39744bc0e-3 for ; Fri, 16 Oct 2026 16:21:56 +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 69GE5GhJ3502681; Fri, 16 Oct 2026 07:21:36 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021103.outbound.protection.outlook.com [52.101.52.103]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hbg268s3f-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:36 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=q+TiuT29Lft1Lhctk/2jJK60T8JNvSJE91lHid7oU 0g=; b=TAWdMoPoVJXiHI3OOR42lL2AyCbNBwCmxvkEmW3i7Y7aSKxheHc8bGMp1 1nIcEyTaOguDuvy8KSByACYbngWsMo4rhh9ckK8qvcM39G64ld9YvlmNRQ+4rdh4 FjhakINn2/o9m7EWhQNShbnznQtRahw2Qrz58xp7upFUnwvAaLY26l3Ij/RL16b6 SxZpgqpA5Cs4oCp4kUasDlmaitu7CbYfYyXs0dANmdphgdFgBVqKWRIZAJBKdOjN 7qoVK4LhkApVaYK+tfvSKk1rxBwNrGPtLeivZnEWZ8Odnzj9FSyZzlEWY36NXxcb Ne8oZq65uZboOtBAy2nbYWvBJFUlQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h3OAY0B0cbBNUotLesPueiuIWnV2vbikSvA1Le8TasPCuScK5ZcPkcfOwkNTAq/T6DEUVDeWN/ADC58GRxcIgbE3pisqldz491XhXrKsEeFjPnfJssUmwsoRjM/ao0zE7CRhj7Evjkk7+q0YkW5R/9Ua1GzJkmtR3VOGbFA94dGbaUh0KBBUs1ttHnpg641qcupzzNL/pXjTXYonmXpT68Bvt60hkPwjj3G2vOwRIoKXZPv+uEByIblZKYFkINNDgo67SWffEUkxOFNYhtyJrqpvibpaTHVqxc+dCd3wxXEas67w7jCLeDo+CsA9NY+e5KwxdXZk28J2wbhqT1cJ1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q+TiuT29Lft1Lhctk/2jJK60T8JNvSJE91lHid7oU0g=; b=MkWFskghrWnjMkGxpj5UJi34zgAs4oGyviWLBFKg+j8Dq5FGVbnluEaThYlvYihaxMF7VbPHOyGkN98f6KHH5rXdmFV4ClQHiXRVfzSuBWe8jYO2LX6pHweEl8cVFjeKpJqthxvPk0vFSTlgeo7r5WyfNW1hB33aDwQFoGUdi80nLJAA7CLfHU0sIrEbSIbmHz8p9hL58chMJkMjGUdKEzCHR4SfDjk/YWFVZnRc1b1UsGUNIRut2RsupyHRsK7Bq/xO1+JxQLtPWa/wfQyh0s31sqOFXTHuyOPBdSYAriWchrvs/ZWUYUSTUL0NjNfuo4ZFVtl8cmOOKM6SAqaROw== 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=q+TiuT29Lft1Lhctk/2jJK60T8JNvSJE91lHid7oU0g=; b=uOUgB2J7RPLQzsBBW1eB3iLNn3g918TC0FvKL/CPxRMe+G9udlSnogPCrgUOjwe8TsOEfXbEzbqEYHOI0bFWa5Br+wGOC/HEGL5oJVK7zMZE+4DwIW8dD3ovpN2SOGWzkf/dSWXqC+khDfCJTbcMfHxLvNJ/12jznVq6kgdv0pLxP/fKpmjfh89+aqNyx7VZJViEHInvALEJs3vCi5Us6SE1dpJ6JMElC/7HlffzEtLLgNn6EGDa+HmpedniHK+dpHwytggwIj8xqs0Qnsaeq13iILGk95AXc/YviOAqpSChDJk3mxWAuMQNVcFyzu61rpysdau4MjEyx6LQ7/DR7w== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 14/27] kvm/i8259.c: use kvm_i8259 prefix for functions Date: Fri, 16 Oct 2026 15:19:20 +0100 Message-ID: <20261016142031.1204281-15-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0293.namprd03.prod.outlook.com (2603:10b6:a03:39e::28) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: 69076bad-cc53-49cf-5817-08df2b90c81c x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 0+v8Tnc+e/mr/zY1IgJID4aAB+V/eZ2UChJZVsr5kncGUoXC/ikK/wSA/4gbUW9xU+I9nyvhI1toMM+dmWZjddv3OyrKOQreWHt5Mxn3bboxSr66ax1AIROII6chjj1eUzSuL6jWm7wuf6ZT0OZEbCBuqt/kjHO+aLvrHdL2AndqAz1x/EEoUYqxfRTv6kPtujI9NCI4dzdyw1FSuAvw8RCgOoPl4OqFWD9yvj4QhZDMSa0MTLhZ8kRqYMsArymeaBKApAGOsn8q1zG1Kk8IatMJAAP3AhDitw2MCzgkAvB6/eCn217lgn6tJkT0dTFun6eajK1YtNQ1oAmkjFRZ3lHl9F8xNV6lggidz90V8XChmL7yCP5fPIN/efR+YXpcWa8gO4M7j9AWVyojAnzl+VN9u4wAK5XTCOsEkwr/nJ8X1CCz6r6m8FCe/0aeMIIEsRqqak48F24t8GMzZ8N4W2d+A4fqSrgxgEfXQ2fmcCg6vsxvof425aWPsiAr1jiMhg63AnLQfA922hIs4PGOsS5iipKhc14MKwggE10sLsnYHuuOhUJ48Uror1okYQ094MZW+9lsVPyCQQ4t2fEIZ4wCTrrLRwZEZD6ffQO5vvlE9RT+IIqEWZVY2DNe13tTphz9Xg4v9ow7X9rdhAIRKZ8XlOvv1Mc5G/lWuqt+RHI= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ZtELg850ZJXBovopVYv9JjnMZ8QpowGqilFDmrlaHdKsB7OZHsvpEYM0cykv?= =?us-ascii?Q?b1wTUXyIdhkzrfVnfT5vzWhLXvPqRzQ/8+BZzRfN4V45XbK3hWLrCjB/WOMX?= =?us-ascii?Q?OOKXc/ADmMovrZKIl+ltjLtboC9641zt2qQ31PQskfV3b0gQvFkSKAoPPnuS?= =?us-ascii?Q?5VvgwJt97w5/OE6DY6FPkXKG0F29m3TNO4A4FJObnjDGohXlm+wWEbXEkJZ0?= =?us-ascii?Q?0cSjgTJlGMeVSNnxVKZHHrIG+hr8REVNWxMzkwNodAuNz/AqfUscn52NJUsK?= =?us-ascii?Q?ALFk5UWE0/DuqyXlYMtkdC9wouxreK5RNFtYlcsID48MD2rqFLWxfiiE6V+y?= =?us-ascii?Q?4YeP7GsIIzEYCLnCVV4Dj7imDFkLZZoxl7UDKPteT5lY/m7ag4vkXzpdp0wR?= =?us-ascii?Q?L1amlwBlouIsRIkQPInqqOaxABzkVz7zGPsSOP9Tq7NpRz5yOXeOfPZ7hZ3S?= =?us-ascii?Q?62BxNZ2jOtfgKM1XZ1eactKCfE4UZJHDCf3uWbE8DMUeLJ06o+y2OdSW+kG2?= =?us-ascii?Q?pmCHYcjEL3Eilzg5sEQrzdzhRu9zeAodFrGb30fpgLK84PYCF5Jh4PUi+BAD?= =?us-ascii?Q?5jNvIB8KN5u6XVwxolCPvAZOuPrePI1iWWJQHDZ5FpMlx/e+nLotcfs7tPCw?= =?us-ascii?Q?DMcrk7wJreFWLtihXV4MpbLNl+2SZ+OxPsAzXESp/k5BRma9qTmC4dhH0wva?= =?us-ascii?Q?ONxJLJgB5689MeAJg++0mr2jkle0CPu77twPRWmQ+TDXLAwUViLDZVFzPmx9?= =?us-ascii?Q?l/Mxz026gTAFTo3+DPVMY3uGNxhBdBjz8BWNEtJ88z/X9NrZMpkHo+cqf5kV?= =?us-ascii?Q?xzXcEQNdHWNsyzO1z9MlvSLdo1v0Hh6/ewyXUrfaANrJxppn3miC4qLb9KQH?= =?us-ascii?Q?zNldGAaauvcBU/Mjwc8tgCq0JIczKKqO4eTS3wfaTdJDI6TWUi7+Vkt9EDdo?= =?us-ascii?Q?3AfKbDuB1XhU/v1OcJ1AP4iMjdEXvwwAEyC4NuEJgm61wYUS30J0FR/pLgMe?= =?us-ascii?Q?kEXZg7MtM+Ufb+G3DQ0wIptCwGlu9IoW9yKKft/J8teGQE2J8rEPhDpZZmck?= =?us-ascii?Q?N2a9aZt2BAgu52N/v3lUbBgGX6TRF5YROBM7TdySKaZvpZLtqkn2UwLwNO6f?= =?us-ascii?Q?PqFBY4Zh3b3zXHKti8P06OWBS/40tTzf3XwLVvlL9XDfvOyXftkgEUwp4zlz?= =?us-ascii?Q?ijXdeF4tKVrGdjOqyclLZxU76fUqLc4XUZAxzldpSavhDqIrZoajB9eRosx5?= =?us-ascii?Q?Ywi7jfIkztiGPLOaP5jIVIC2+kypgwfb1himVnZrBfX72buPmQX4JgH89jjY?= =?us-ascii?Q?Z6XFcBoS+3kaTz4YiA9OQ9hwb/8lKjexXUZQQjxJZfWefiuql02TG05uFj0f?= =?us-ascii?Q?Oq710bEAPQIaqzxG96NQrpYBf0hgcjrfzDykcsFwB+lGfzLUeZD+yxtsjWHJ?= =?us-ascii?Q?yVvSlZ/mWPLR2hbScolnMaa3Zu1v4KIIOZ91BwyjoIddyZpXoeE/SUwCyZRE?= =?us-ascii?Q?Gmkt+URfUKGL7bzl0eaMZo0aPFTdIF0yRPSzyZBvAji22D2CAzlBCCvBBTrt?= =?us-ascii?Q?+bdEUrHJkIY18nqIHNY07NmDrfXNwIUJ6v3dDVnbMhibBMz+hYA5WHI8L32N?= =?us-ascii?Q?6D7x8TlNd6E3jl0/Q7YEIjmgJ+h5XqOylY7QD2Y3eB4TVnFRF0nxy+qTLcYq?= =?us-ascii?Q?OSDgu1hOQDyEnmJyy+Fzx56IaZlOtEKS7+hhfzyPP5nR2DMQYaQRBjzWGkYV?= =?us-ascii?Q?HPxK4YZUW3ddEZN/G9YLtbWZ+C0LfWg=3D?= X-Exchange-RoutingPolicyChecked: leXj+3WZvgvc9AgPwGdGo4jofV/rgPPQbfwVGc+R+tM/hIslsWCtrD7fO5LA6p0JRMFbPnis8nO60jmDpQqtuN/b9jZPN17IGO6rLEX+S3hxsuHMsz2nP+5ibcmU1FwBXX2pYvUvbdiUDZkpFU2xPJniAgzhEqLDKbfjNFg/bTudWvAv+DFtElYQwxc8IJ1sHrioct8jduNDKTHWIIQebZQqkOjs7tvuCEWE4/98kP2wHQrOBxU0Nq1Qx8K6RJf11bU7GKMNA2RU3o1sLDCoO0DcGgiy57BncCIT0HYofZVkpLLptFujO2JlJo2OMAMRXQmWWEATJa7GhcRfvTIuXw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69076bad-cc53-49cf-5817-08df2b90c81c X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:34.6125 (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: 5yzadlPVZTl/OsBDB1RyWeC7uVT9kdziyScrnfWyFTizZErd85d8fuUrAhX15dMgHvmuGMPNkDxyZrO5h4qEMt4mMBMRAG/SGnl5Nparcfs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfXxXsJu7r5mPbm HCKQBaOb7uJ9X9g4eBoQZ6JOuSgLtK1cPP1x59mOCjiub01jvVf5NZW2u9OkBKg0LvCBCpn3w9l zVH2M0LssVj7XvTKtpnkuSsoARl2I1M= X-Proofpoint-GUID: Aj3vd-vBQd-d2Fv7mFOaaFdhCoTt96YP X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX6KWC7WkBEWI8 v85l88tdXe4HuWDXV0irGxZ8eomsPpPIrggqG6Q0dfzHwhJ1VvLN7MZSPP9UD86f4Q3WNgeUUmU dIUfs6ft9t0BVaKsMZzQ2HB0NOgFUTiqcIN7u/Y4W8aIq/DuqF0LrdZAh4oRIEjb7q93C6kmf7F RqwxFnCT9FMcx7dO6KSPJayze7GMvG7iyRE2RL9Eus6gxaz0o0UUIilCkIXvipQolYAAlPdTIA1 7mH3KezkFhgYD2Q63ia7nC7m5a6DRa6qHcFOAi6sLVQKvAOXguwtcaYmPXKOspJz9WonXDzCopa nhBJXWrgEZvpP/SlMfy9UaeVbwanz/Dc7IJtEKjVtxUwDCMAh0ZXZpygJlCIg36HSdZWLIzHC3D jsJEXMzQP9VrRXk0wvyz1PczGJgwPJ5CmmJVrKSA134cV7LPbPNITe+CeSP/2wGbtRX83OLqhLL 7fw4M/PMy7LgtDAVaSA== X-Authority-Analysis: v=2.4 cv=G5OJgNk5 c=1 sm=1 tr=0 ts=6ad232f0 cx=c_pps a=yD2eIpN93qk0sgAC8tXY5g==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=1L6crL_YRTbalZ11mEUO:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=b1AWVSNg6wsnrng390EA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: Aj3vd-vBQd-d2Fv7mFOaaFdhCoTt96YP 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1792160516-772D8A5B-CA53D4D4/0/0 X-purgate-type: clean X-purgate-size: 2803 This ensures consistency with our normal QOM-based naming convention. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/i386/kvm/i8259.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 3a960e48e6..952f58be11 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -36,7 +36,7 @@ struct KVMI8259Class { DeviceRealize parent_realize; }; -static void kvm_pic_get(I8259CommonState *cs) +static void kvm_i8259_get(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -69,7 +69,7 @@ static void kvm_pic_get(I8259CommonState *cs) cs->elcr_mask = kpic->elcr_mask; } -static void kvm_pic_put(I8259CommonState *cs) +static void kvm_i8259_put(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -103,14 +103,14 @@ static void kvm_pic_put(I8259CommonState *cs) } } -static void kvm_pic_reset(DeviceState *dev) +static void kvm_i8259_reset(DeviceState *dev) { I8259CommonState *cs = I8259_COMMON(dev); cs->elcr = 0; i8259_common_reset(cs); - kvm_pic_put(cs); + kvm_i8259_put(cs); } static void kvm_pic_set_irq(void *opaque, int irq, int level) @@ -122,7 +122,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 *cs = I8259_COMMON(dev); KVMI8259Class *kpc = KVM_I8259_GET_CLASS(dev); @@ -147,10 +147,11 @@ 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, &kpc->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, + &kpc->parent_realize); + k->pre_save = kvm_i8259_get; + k->post_load = kvm_i8259_put; } static const TypeInfo kvm_i8259_info = { @@ -161,9 +162,9 @@ static const TypeInfo kvm_i8259_info = { .class_size = sizeof(KVMI8259Class), }; -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 Fri Oct 16 14:22:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:22:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452008.1666938 (Exim 4.92) (envelope-from ) id 1xHior-0005Md-CJ; Fri, 16 Oct 2026 14:22:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452008.1666938; Fri, 16 Oct 2026 14: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 1xHior-0005LN-6b; Fri, 16 Oct 2026 14:22:01 +0000 Received: by outflank-mailman (input) for mailman id 1452008; Fri, 16 Oct 2026 14:22:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiop-00057H-V2 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:22:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiop-008oQe-BN for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:21:59 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232fd-8faa-0a2a0a5109dd-0a2a4504a998-30 for ; Fri, 16 Oct 2026 16:21:59 +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 6ad23305-b57f-0a2a45040019-94a39744ac08-3 for ; Fri, 16 Oct 2026 16:21:58 +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 69GE5JgV3050717; Fri, 16 Oct 2026 07:21:52 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021114.outbound.protection.outlook.com [40.107.208.114]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb7t19qsm-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:52 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:51 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=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=Gc5sSKfDVB8R4X6fBb7T55UzLTmJFAUuEnah/iYPL cw=; b=MB37VXHSoRoJROd2319RBofU8v8zOrE5cMwgjJZY4Sy0HrtClaheOvOW6 fHR4TdgWeAWUKAowxSfzDYDI8coEyvwrUgUhIia87VLObKI/3ijLfqPGPMRyW8Ag tMDSiOqRisj9snTvBWoWzEFP0D0MdsuZk8MzsBLv1qTQ7ZBiSu8ZKbTRMbCGJcdy sZFF66n0Jhgv8Nf/zng1XVsFW4ptRCFnU+9vO8RxyLhiuHITxgSWvMt3ddM35ola iGM5kwnk6VfuZu/Ws6Trpc7HlUQxoNM1uu5/gjoL7z0foYF4zsI3/3DvMFj7oX+Y 7ElCv9YnZ9pTJ1vetewP0q9LpSApw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HjLCjhB8bNps6sVgZELr1AUFpd+BaJ0RTVsvemYt3Irw/W2FyAzpHi/Fm5u2bJotK7LejMLXjHZtuodoUFBU1CnjpT5jsnqpQkrgO6MIsRbhnK/Z6dsbR46mdTtRCU1SFEn/townh1omYfLkUFi5WcEEAui8Fxjyh29vsveGan3d2TXHy5EZSlblmidmSZDoVpizckjZvDqkJR+J24EGPS+q8kIj9FzAJpKIudX5q096xUCGS3xHkaEmjpzATBgqewxFcp78GeGdNR9WFOUZLl8ORdrV/hCxX6M3dEwq17VlPLZWbK9UBKhQGwHz7x+R4FA5Gu7SnbpvduOcf2aW5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Gc5sSKfDVB8R4X6fBb7T55UzLTmJFAUuEnah/iYPLcw=; b=MGryjAJHXdp4lyl+bKkbJEgQfvsS6+mjwvlNCKLNg7Nm54Qb5m+4p05AQElcaoK1zd8Xt2qcxnbajHu9YsrVbCGu73nfuUtP74JHrAKECnPt1cx618BE26nAXsQWVhcIB+O5g0efrsaJVCSyAnce3liTtS1NZbTf0RHKXIvf4vkAYesaDeGUE7XEECR4JdAQlWGObjTW+KOfgkLox3KwLyc2m1czSjunn0R1D1/aSyfdPJ6n9MpBnOrabdl9gj3Wu36o8RjIJ5Z3wwB7z7J2vh+gIDvvO/VODQWhDiO/Yg3oj3gQ/1j9JMQrHXd2nXHCu+euRhE+fVEt/HKR3jfgcw== 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=Gc5sSKfDVB8R4X6fBb7T55UzLTmJFAUuEnah/iYPLcw=; b=t0TsMdOi3CFTPgargNj+Tt5Y8p52wGLrlWB91qpoF7AL3wVSm2dOswd4hr4k7fjMnNaMmTTpOLkppoOqdNzczHTsIrf1KQqqEm6h1vM2C5oYvDqOENs8Awt3IyEu0gVr6+yB58sdaihh1JFs6+VCXmXx3+JJLIH6yWWMKLCOTq2gHWiy42DbXaMvfd3C1933NJ3rPDiwlnlcMmQ4khTWZdrAHTTxTNzxJyYFmZMgx7xovZ1rToyd0aYHO/junK9jDyfa8eVBsUmeIlAcMCZxl94uWL4wrWjyU2xj+R29pIZpW6MzNE5zyOosFk0KXKsQdcMfT5htgsuwENzgZQRbFQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 18/27] i8259.c: introduce TYPE_I8259_PIC device Date: Fri, 16 Oct 2026 15:19:24 +0100 Message-ID: <20261016142031.1204281-19-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0193.namprd05.prod.outlook.com (2603:10b6:a03:330::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_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: 40dd7927-25c3-46ec-06f1-08df2b90d20c x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 2im+Io+AjEikp8s9b09Eo20ptNbv2qAgRH8JvxbDddfqg+8T1gwyGmbkpd/afin+6hb9EhhAPqVixdWS9cP9Ih2tWY2o9DXXfqAGiw1qiQoxeygfUmusNTxLFYZU8SjdYEwZp2y5cXY1nMcRgvPuG1Ax4HXZlbLAX1e0LDlwnGwwWGeNfg9mmxMIN886khgsiWk9HtAj624hRodijrcqgCgtYN+yNH70Ac7+ADlKmFr7thR9zmVPLZhhX1iqKeW2qVtBalK/9BTJ49fYTnYZzfhzMUCspyrmNgbQSJPoFkcKD8Fxl1hyuQYnvlWNUzUUpZ8wqlKVCIA0IAZBzCzGWHgZ/dmuRiboJVRKf1eL+1NR/WhT8AXCw5V7FWzRHno5kEGtn1ZEpfgfepj62WA2ScMj5P8SxMTKApYPmBRKA6XL4fR2nX9j6adWiWQYpq36P4Z3h0tHhfbpKobnHzGYpg37azL6PfSyLAuEJbKbhpLIBhpv9RiXhAuDmqMtguKq89aB2TCCnAfJm1n+mV1MImniknKP6cwaUq959AxTDeu4n4oFyblzUoOH1SNnLdf06aJAITeErSF8DBTD96e+beGr9jWQpsoxdbaPPkDnwTtQsxg5obODAtJpSHeZDCMJym4vmRDu4XMccKqxXfopNrdgZ4lntEFDZuc8LdKGvj0= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?axns75zRaWZ7FU1rqabJ6Hd1iaxIv1f6aE3R5godDc0cObanGxaHbmSmrqnT?= =?us-ascii?Q?nyKeb6RMcV1XWcG0p1WdJ6cMrE5FFmZ6jzFEYQK1zdUI3ryurkgbMioFCgYw?= =?us-ascii?Q?hVTJm3jPJAZTXQiigSv1aHloS0lJg67F2WbKqX4BS8kzKvhbGOnqjwtwY1VW?= =?us-ascii?Q?EWD3MG+K1UeDIO2u+jg0kk//OarQomeeb+0loHCQ61Dyx1s9zp8qB03z+TjX?= =?us-ascii?Q?W/kYLy2dexNOCFh2gL4brgGW9XTNkj3/tv00tVig2n8C3dmyKNjFATYI2Q9m?= =?us-ascii?Q?1WEFtHxSsoik+jdT8my6mYbQ0l5XXfnQkJEDbdyoweqnWT4f95BcODstAU4J?= =?us-ascii?Q?5sQYONQDYSzwkxTX6v19xl5WEWApd2/FjDqBdL8/MVv/nSdJQiDgeHZ0z3xx?= =?us-ascii?Q?OMCMKPm8teX5BYNhlWZ5SPHQ4h+hj9IBdRxc8ZdRUkWoss/OnS2uv+u9H5ax?= =?us-ascii?Q?nLstFK7fXLbEBTVlNoddcQMDIZujBkBZO7/aEN+cNGiqz0zVWGw4/BhlgQbW?= =?us-ascii?Q?3wBbBwPADGUPuCz+FPUqfltabur4EELsCUagG/Z0+IsSRimKKKurJNtvzhmZ?= =?us-ascii?Q?UwLPEhEX674y6DsJAiaS6hZL5GjtSSSis9x2KodBKY546AIzQuLwzOW8cFWi?= =?us-ascii?Q?bXZZRI52OpaEnX4JlFzrQjjSmgoL591erE0ZzAArV/kCZKBHuOJJnBQkdysD?= =?us-ascii?Q?I5fg4vPDcAt/dIK+O6Y61SyjjEog778ZYHz4qK0YvM/6yyAQVUOaohMxxRMI?= =?us-ascii?Q?7RF/kJN+1UY/ayFyfaBR12lGxdJWbUnEQ+cSMj6JBM0lxL/u9BZhpdFMnaNM?= =?us-ascii?Q?hOPNm8CdrU2CIXMN1SegvEcokneV1n0wtLSxRRY8Gfi1RDRAFLXdAz/m6rBy?= =?us-ascii?Q?CNluauQ8l4ejuWFzhJtnrUGNRJKKaAl+MVLmd8rx3cpCT+NOw76g94zm43tx?= =?us-ascii?Q?zkCW4n4ITF7mvi8NdmUqcFnD1PJEA+yk+0vUiuSGoSpqx5EDsjGJKS4/n4M0?= =?us-ascii?Q?8ByCQYLtw+/Mn1mdBI1ROFiDvm3U1axXilQC1sdV78W/SnjSNA20zaFWgvQa?= =?us-ascii?Q?lvBMgb1t93iZB3sZGIV5tpVp+lDvs61z/AkIEUOEAWKKOxvlxbn3XfkFvAZ3?= =?us-ascii?Q?zD25Eowml4Bfa5qir9yRsZ/+bYtyy1JC0RofULtikNhdpBgMmPTU+5gEABW7?= =?us-ascii?Q?VhmE5IGORSDO2z5JTfn2olW25tXzSd5uSGxBE+FVP2YqbQ5QuB0zNTxR5RP0?= =?us-ascii?Q?bAZvEw8fDm2phlf+EYTFkrP1HvJUnyvL12i4Ql98G1o9LPJYLha8jAeBHMYP?= =?us-ascii?Q?l16S6HEhZzQv9RoSjkSprWTN0WXBA8lvUOEqg8RL7G2noXHuTSqXQqyVGJ8t?= =?us-ascii?Q?Y8QSt4+Xs6pmjp73BTvcNb/kRWQbv77NLFWaISC6ewyF7TRn49CaJSIkWaDd?= =?us-ascii?Q?tBFc//lu7mmcgbIDLw9QK/VuUaBs2TXEJAUNChWYMxvYC1k8kVTIQMA5B1+a?= =?us-ascii?Q?1dM5Wp7HDTj8yAw5+jFV7x306LMeSK48l1EgC8jec4uAAlWSmIaP3en6L2lB?= =?us-ascii?Q?ytvjtpIbaP48zf0nuYwqL1fKWMnRCJCbi/LAZp4xoT19gs19U2T5KgTrvE7s?= =?us-ascii?Q?DtWFYH6PoHSRpqFa41PtZBI69sMTLfVY8tADnqG1q9JtpWkocO9+LMiyp56z?= =?us-ascii?Q?mMZ0fLGaAboZTs86yHGocyzHggoSXUUtgBxuc0zC0DpEQ3IhywM9qGefqCTQ?= =?us-ascii?Q?ZhR/mYaeVwTP39UB8VrXIbzohh+1JFQ=3D?= X-Exchange-RoutingPolicyChecked: ha6Jy6ySwPaCxYTcItYdET/PKPPJN36B5JRytduoMyP80Rp5+zFLscs3TV7gPrOA71OL1c8WkwD3c2/MsV8X7T4+fHnRkw+rl2HG43cOEOgInhLuyFpHNS4G5i6P02PX/zv2TVWhgMFH4SXA3Eb9pRSfuVIkWwIap5HPB8kWw4eMfHJg20Pwp/WdxA+IKFX4g6Zh4stCwOii19d84NP/x+tJG5GQ8rWvzEuITVxHteNLLC3XJOiGzFsdVIME/zyI7UKxirhVjc5gvVWCB0Omshdz0VidCuUHLcz5mh7c2mZwybELDYy1s+HfTUlytIH/+382jvxVBNixauwHUQTaLg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40dd7927-25c3-46ec-06f1-08df2b90d20c X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:51.4039 (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: 2Y4pF2uzMMK8b4BBDOwiQ2skdB3JUmYjSbzKnmXobHoV9jSd6JfGbz++NdB4nvDalDBgvMuAK15XcLOiWohS2w3JOu8U50DKsrDkDqRS+PI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Authority-Analysis: v=2.4 cv=LsYHWXdc c=1 sm=1 tr=0 ts=6ad23300 cx=c_pps a=rSpWrHmMTF20an4ACDPPuA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=0XGB6JmbSUb4YdcodAIA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX3saVKKzDr71g tTSSiRWbg83XTUgAdAAnDMMqi5UwRSmBX5orLsRmTr4CyimvFM2+nQYNFqJ1qYvOp6ASoQXhcmg BOqnrh+gRgj+UGNJC+1yOLpIiQt+LUQ= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX/sLF6PR5ve2p tF4OJ830tBWd4jKr4C0tH6TE008zsyAiXw+EnebTneSD79wk1vQstD7dQn5oWPxyzNbOWWJFSQo sdAyAyuL4XVbCtth+sXwhQsTD4Phhn/oTKq0lociE8NgUurvWWMVoD0EUl+/AljL8TbLsznyKe4 1DQyI1T6ibPDF8xjDIkHr+Ru8V6gyebrZmUXQujiuPI+B9XVlLHnU/hVeDl+36dF1IL2K15Sc9+ RI7OaD63Zc16JFEw2HIkPS0Faf8R9BOilXzy7LA9msZDyhvW/2SFQXHm1AwE71LukzAx87r5REr Yjlv8pksRu6U/I1tycSa9RJXZ9K4gsKahSDPmDkMtQm1pMt+wqo5Cg3IljlbI0XebWjjymqKmOx rT0s7sEcyevEU2asQUVxa7jPTVejZu8IFcHWWRDVmzg6BdodEuIruKD/Gy0wDGTJcJbK0OCuZNV m7L43nRA9TsEoPuhr0A== X-Proofpoint-ORIG-GUID: Ne3dkg9vzRNzUPw3NtFIhLSjvSZ1uqSW X-Proofpoint-GUID: Ne3dkg9vzRNzUPw3NtFIhLSjvSZ1uqSW 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792160519-524CBB50-1D879E95/0/0 X-purgate-type: clean X-purgate-size: 5678 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 e5fa0f2e5e..bfe01067b7 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" @@ -51,6 +53,22 @@ struct I8259Class { DeviceRealize parent_realize; }; +#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; + I8259State i8259[2]; +}; + +OBJECT_DECLARE_SIMPLE_TYPE(I8259PICState, I8259_PIC) + + #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif @@ -410,30 +428,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(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(pic_obj); + pic_obj = object_resolve_path_component(OBJECT(dev), "secondary"); + slave_pic = I8259_COMMON(pic_obj); return irq_set; } @@ -447,6 +459,90 @@ 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, @@ -455,6 +551,13 @@ static const TypeInfo i8259_type_infos[] = { .class_init = i8259_class_init, .class_size = sizeof(I8259Class), }, + { + .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 Fri Oct 16 14:22:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:22:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452013.1666947 (Exim 4.92) (envelope-from ) id 1xHiox-0005u4-IR; Fri, 16 Oct 2026 14:22:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452013.1666947; Fri, 16 Oct 2026 14: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 1xHiox-0005tq-FA; Fri, 16 Oct 2026 14:22:07 +0000 Received: by outflank-mailman (input) for mailman id 1452013; Fri, 16 Oct 2026 14:22:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHiov-0005oB-Ln for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:22:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHiov-00CcZL-2A for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:22:05 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232f9-2eae-0a2a0a5409dd-0a2a450a9e84-48 for ; Fri, 16 Oct 2026 16:22:05 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2330b-f2d2-0a2a450a0019-94a39b0c2f62-3 for ; Fri, 16 Oct 2026 16:22:04 +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 69GE5C533215871; Fri, 16 Oct 2026 07:22:00 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021122.outbound.protection.outlook.com [52.101.52.122]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb045k1nt-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:00 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=TT4vyz58C9R4m1U1e99yPlvlvXTFk0taf+u089Nfd is=; b=NJv1XV6vJECxQ0/uQ+5ofclWrBaxeWlCvWPmLCHxFig7sAxjqn9j4AXtn zWCtxqCsRawOD5kGCprBJmog5XNiiEPGub33kshg/edyAljwVY/fQg6X3LEmpYBp FlEHyOO14vItoPTUMdjPj1Y2EbrDffWmnC+rdxmzyqsQfo23pIAokZT6caE26G7P YO0GzOzu+578gZqeqz7hRDGb+LGff5LWBKG2dx9N/ogdvAyTyypdSb7RBpoV/jFA 6rUZ7QNAt+/uYFaJJMjeFKdJoCElN4K8pQLQtOq0ZhsI1w6QlHRu/inWIj99YwC1 LQiGvcrIVPYEZUBaR27IuJgNJ6srA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MGip2RzjYkp/7/FJfuQb63oSNWemj7bV7U8A8o0YMzhB2L3k/yhoJRCOtFDblZjklyJXaGEkj9TaG2wAMRERc3MMp7gezWxeLQFrx6FleyzIS02+0jsOZ8UWS3mdvEL/815HRyH1T4mo3+iHeZmjB6FceNaWD081QUGMWv0GbkCZk11Jud/oOvM0qPfx2NQpVd0+JoxpbPG8wRsyVkbk4+apu2IxhhUtJqYBwliCcx95+z2IdgkiuB5RRz2OOP71pu1BuHembpLvNEc+7z+Z+nVhwmVEhX2BTrRbNkJ65d42Hf0X2h8c6QMtzKi7G/1/8gLeAeW6hw0CJfyUnRKlew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TT4vyz58C9R4m1U1e99yPlvlvXTFk0taf+u089Nfdis=; b=hGilYBgpzHkuduu8xMXMCTeIs2+h0a2w4VssgeNVykoGvye1MsBPPsecqYX+rYoLBAXRJmCiLjU5NqpmRUxxyVsNQJm79XVU0YkJPMoWJPv5BXq8AV2U7CMFXjhwLNyRou/xwzmlQUrscWfN3InUuKoN/y7JJXphZOnwdHLPdhiUSeViBYuzOEIrbhfCj+gmEuJlfP/OahWbWwEdTuf4mrJihBgB/Ud+0luYyMmVsPsBma5JslxF8lFzUbK8XohkzqTcicBL2lOeIxJRpZfUbJO+4GXKTYcdU92OjDcQ+KjQWjNaP0jBvNYr3iKpLr+4+v7WX6Dd1yLMAt/XpuSzWQ== 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=TT4vyz58C9R4m1U1e99yPlvlvXTFk0taf+u089Nfdis=; b=k2q4UdFR8+PRLh+U3jw2pJ4Ze5RaOTA9t4Xk3DCY04oc4Fa3GngLNZLVzOlS9RxYtgW9pdUw+zaNS/+5rBLszp/M8ZE1nwzbxlIR5/TPYg06bzCgZzms7UcbwyC3KU2jX+ZzgYfvGk+AEch46+sAixQkn9rWKmzY/tFCEpo35cNG91Cm5veQuvCmeAsQglqIP6X2qAJiDca7OKBoa1+7ugo6ZEHTzxvSWK7oPO3h4Wc+RT+HIt77WyOUgAOx9i/b1azbYpkDKWl/gtMmaiBC7gwkTPhqEceYs5yEWz9JvpQ7Tw/FxUwaDaQ9oTv8jO74LS3X0REWR6G48c4f5cFVOw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 20/27] kvm/i8259.c: introduce TYPE_KVM_I8259_PIC device Date: Fri, 16 Oct 2026 15:19:26 +0100 Message-ID: <20261016142031.1204281-21-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0348.namprd03.prod.outlook.com (2603:10b6:a03:39c::23) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: 5b33ccd0-7d4d-4712-3402-08df2b90d6af x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: st3Y09XUySP0rTGVtIE3kd4lyMb9QN4JbAun6ASEnooi3pLrdC5/h0Tb6tWTVqUy2gXKmLYU/eELEyi2WG2wUSGVu3CtB+6tNbFl83iqJ5lixcnLa/6zVeD6eOqYMXBWhrkbkbRgBSrVU7WYM0CpNhehK7zs6qgQnPLPNbvcdEjgMQIzacrLJ6zrLh5YeWkpO0r7M+InbJ68r05oQ09WVDgxj3v1QdVYa907Tx1N3LotFBBAO+O/ACAkM1yF6U+R5SMHsnmBb+zgsgSFihUC8rfVuaNuOv/eXqVXi6jYkh9k0RkoLX9/MWOBHP9KfhXQMavy6OMnikq8lj9JsqTs3oVWDBlBZS/w4Gvqd8aE+gTPCW+cuqqHH4O+1qx3jKs1YoKPVlD2w1zHCdHA9ldUAL9dU6mnjBcp8LnCYVrJ+Z/eQOr4U/wqNqvsIBt5npRo6sgsBmdRS+otL8PnJsPRk9S+XFc7shrPQaTh8Uf/7njJ1lPPXlcZapjWjZhsusGP81r5KqNw7u5mx3aj62egV3rNZ6VymMn3CbAxfnsw18cml+gAa9aKp+XkR/SJmj73LCTYgq87EYJdGt9JfPEpOY5ogqwG9kj2xbW6o2bmdj+OMjZynwPLfuiEFmXLAy+33AJcYRRY4abZOAaRZFMjec2yez3CrpKzpgr9lKpPKI8= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6nCdstLvjAiDqIXhzwXdlkFDWPMt2uSBrDddRSK4JvbipUR8IlG5T3h3Y6KI?= =?us-ascii?Q?cD2J5Oo1DcVhKhmGG6XhNDkos5K8esCz01cKWEfcBYMNZiIP53I75GHIlbMd?= =?us-ascii?Q?dhrnKTGWcE+b4UOOv4jAdIbhr5RMiiuoAzHXvEN9xb1nxYDlMrK2enzBJDC8?= =?us-ascii?Q?llMlhU60kgC/WnFggTErbg9/CGrCIkWZ2uWCfCkh3Fl9yUFkrObvikWHq6uf?= =?us-ascii?Q?Qt1X0KeQlcgRE/L6QnAd/W+Ydc0q0/RfckQECjBfPGDOVQQwM2SCay8M6bXs?= =?us-ascii?Q?um+K3ufmTMtqeLzCu/Na+rwEPzttyaLNlYAmwuVl1qLrnmyVtpE9RxghJOjW?= =?us-ascii?Q?a2zlbn68VxG7pZEgrPU3ns5zr+aWjaXzEuD9r9EFe9MYFmYSGvQdD2FOvoIg?= =?us-ascii?Q?CHjXjie5tnOH9g5cJMJkFzLNrOnbrqw76jJsWIbyZ7OFMbPc/1R2SnZdI8hn?= =?us-ascii?Q?Og7EUDdhMXOrzzVtr5p3T/l+yDFrRfDwuTHjEIcqRfhcLH32YyNXb7L6Z3CP?= =?us-ascii?Q?SyHagYI9wtVmGnqvBecjWtxFv4Yibc+O1eCmM8/3RJteTvQmp+t62mnQffSk?= =?us-ascii?Q?emOiQXtOcHsuHUaGa7kEHs7WLeWJAzb58yPbGMWvLEQGNoT7/ctxvue4NkRv?= =?us-ascii?Q?ZTPcuIHFM3ZIHtOwpZddxJVKD+esH1fgPFcmZ41MALzEavcfBZd5xZdTHYTQ?= =?us-ascii?Q?HfGui6yknldNvichw0gp2UU3QRS2V1yBZKo2ZuhbGnsljhaGr5kYlm/ftUBu?= =?us-ascii?Q?6ZVBz5fLz+9UrEvw6czSVNQRL42al284KKfvDjDGl/uu/6NDYA8FgzQvmWzO?= =?us-ascii?Q?pzvZ4fOQKb2HvNufJ5VcO4X8FJAH5CtD9A6ss5Fa0PV89S1nogMTDA5kGu2Y?= =?us-ascii?Q?5iwsdc14T7XUzWWc8bfaNs+nF8uNB+5g3UonWoOZ9q2GJg+9fttDDs1brPhi?= =?us-ascii?Q?tU90hMkIVUCNFt6xvbAY/DCmcG/z4CVtzmK7wPaCqrrffmMZVkhZG4NZdyYS?= =?us-ascii?Q?t4lhWJRjGEkVe9coHK8TUyMQZlOu9aSvf2Fmz63hDCX0cBZMOy/GhEZ4prGY?= =?us-ascii?Q?3E+hi9Plw1kwsTZmlPl2lpNIhiCdTRGcB3delEWKE6Zeax2zwn1e6yhZZ7s/?= =?us-ascii?Q?SFjPkvYQ0fo8nDkZer9/PnSf6MikX1X17RyGqzXwet//8vntsOUtcoBucLt0?= =?us-ascii?Q?EfKfuj5P7tEMRWMW8/Uf+Qzj7+4fo99hPU+G34wdirJheqinIe4WM1C7p3Wq?= =?us-ascii?Q?FdlIHMgV5ZNUnhlWdLLtw/T7Eo+VULX1nxIEQsNHPgf6wssr1CEKD5zJX4OP?= =?us-ascii?Q?pTalqUd+v4XAK3NWVNzHZDkrwT0lrl062VWWSVZL8D/QOJtspVrFO62TTlrE?= =?us-ascii?Q?eDRJO1tlsr6L0IAu3WXJfsL1qC7FXI/UalnklGahI/YWm9cDWKu49ZbH8oX1?= =?us-ascii?Q?yTcEyRHKSweNEk4Ce7GcC5rzgxwlGper0S6GfBHCSoLuINjIo2hgNgBAeU2e?= =?us-ascii?Q?paV//zFSqRFvrDsCjzSZhy/BcAQHGUJ6uhwAdDLGs/2GiqncFPh1kWeNsoVI?= =?us-ascii?Q?E//mzks2qyS/+16WIityz5FS2Mc+bSBPj9aw9EfQ/g55nxn2YrNjffVBFWUY?= =?us-ascii?Q?1cbA8k5M0284GQZiTtPxztnJPMyrdpQ7FQx6UI7eIsYMQtJ9hxBNwNGa8h+H?= =?us-ascii?Q?wJ0VLUIQlD4IQtEvHJHlggXaLf8uoouXZ3CDQRO1jmUyKtuC5E4vHccDGVJI?= =?us-ascii?Q?O1o7m0II2eOySLqmaOppPINmD95AGB0=3D?= X-Exchange-RoutingPolicyChecked: plOU72PLkQTm8IPZQ5ajnKGg+kubxYkS2GCPXXuHLwUHnPsdnVZTnuJB9GJJvqK0L3hvRrkcmygUk89Q3kp9g7Jn3L+OzQF2Wjwmd/8W6aqu5qCNLabtJ37XCnWIY2PPrK4dx+ZCErXs4xfBPcKitOrtxOghw3L7iXR0vXiLghb53YMIBhkl7fswjD1/GziLs9iE1aWUgkK7qRDvJxB6+eM3bZj8X5FznlYiKfQg35KJGXKJwGMLEvTUgL1S10hFgvRNPxgsPqGAUn9NbSvmmIeRKGyC6jqYPebsVh9UE19KdJWf4Qe2URJOtBIOb7JKm86bWXlNhe+Ew3ijgQtwXg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b33ccd0-7d4d-4712-3402-08df2b90d6af X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:59.0394 (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: NR1V+MWUDCFiEQSbYafF8wt1R8lPh7D4pukupB58dxyOf6WKNyH//Pas3Io+D6jqN9/j/Ce8n/UtkTSdMD8NS6CMsgnLK7zlNBLDcaS9hhA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Proofpoint-ORIG-GUID: viLeBcd4OMsDYg2Im6P29P1BHlplfyKA X-Proofpoint-GUID: viLeBcd4OMsDYg2Im6P29P1BHlplfyKA X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX/Hn4HD6mYvbp 35X333LTbTag4XOHZ2JbhTxWnD7TrH0jy8B1GVfMyCcG/ZZ97/fposnjclllN8RWwIIaQ35gDxT 5lj2GRUzl4pG4tOzyspR0HO0CYhW3IiJgeizuMHCql6tydf1C001UPcUbD+HTgZWRqqNgg3cF16 skICr50IvIlimqPAhZuAdmSFuCrFUygwYIDpMuKUEku6zd0TBeFPWE8WsWtbGBJ0pEGWD3jgoUr 7pGu4H+83Xm0yzfo5edCIPQBSpyv+J3Vu4FQqK3omyve5R35oHtRxmkgTZ0W+efD2Sy9CAh75eS HhZNli9dvjsUGFqVuujzGd3V4shcNvqOzDPn1wUeto9mjNxEK7cI6ItLTxugPpusbvrxeTYt7qC IE0xQzyzYLqlP4o/UhT1TH4iRTOGGoHjVBV+2A7AOiXvFM4L+NKa/ILLNHxs31vgCfRHzkbspdw ivBrEQEKCin5vT5XezQ== X-Authority-Analysis: v=2.4 cv=V/ToQuni c=1 sm=1 tr=0 ts=6ad23308 cx=c_pps a=83jsKCSeZiZisq1MDa3xoA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=CV9Lyex1vB-al1NDbmIA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX4/zgKiMZZSU3 ahNLmbBk4PfT0oIT0DlfbJ4U5zACHpT0KvJ3ucuwLNhBTsvSTwttkYLpcQhYVUXiPmf5/LnTP2h lnfiinCDUE0r82m965oJPNjxNuQ7Bpw= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-4011c0/1792160524-583CCCFC-352A2570/0/0 X-purgate-type: clean X-purgate-size: 4322 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 9ee23b5695..c51738dd44 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -16,7 +16,9 @@ #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" @@ -36,6 +38,18 @@ struct KVMI8259Class { DeviceRealize parent_realize; }; +#define TYPE_KVM_I8259_PIC "kvm-i8259-pic" + +struct KVMI8259PICState { + DeviceState parent_obj; + + ISABus *isabus; + KVMI8259State i8259[2]; +}; + +OBJECT_DECLARE_SIMPLE_TYPE(KVMI8259PICState, KVM_I8259_PIC) + + static void kvm_i8259_get(I8259CommonState *cs) { struct kvm_irqchip chip; @@ -135,10 +149,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) @@ -154,6 +179,59 @@ 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, @@ -162,6 +240,13 @@ static const TypeInfo kvm_i8259_type_infos[] = { .class_init = kvm_i8259_class_init, .class_size = sizeof(KVMI8259Class), }, + { + .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 Fri Oct 16 14:22:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:22:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452016.1666956 (Exim 4.92) (envelope-from ) id 1xHip1-0006Iy-7s; Fri, 16 Oct 2026 14:22:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452016.1666956; Fri, 16 Oct 2026 14: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 1xHip1-0006Il-4R; Fri, 16 Oct 2026 14:22:11 +0000 Received: by outflank-mailman (input) for mailman id 1452016; Fri, 16 Oct 2026 14:22:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHip0-0006Eu-0Y for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:22:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHioz-008oQe-Cz for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:22:09 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad232ec-8faa-0a2a0a5109dd-0a2a4502b3ba-48 for ; Fri, 16 Oct 2026 16:22:09 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2330f-6ca4-0a2a45020019-94a3974449e0-3 for ; Fri, 16 Oct 2026 16:22:09 +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 69GE5JgU3050717; Fri, 16 Oct 2026 07:21:48 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021076.outbound.protection.outlook.com [52.101.52.76]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb7t19qsb-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:48 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:47 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=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=YBENO+AVPrr9uTUjU0EffDFLvrFbeW1XWzcjaPVFV 10=; b=TSIhQLVFGwj6fbaA2GdfaEKLqGVgRqEdQYGxp300ggbHy7PcJNF36ALIO 8Kd4PAh6T4R22BMy0DQ6GNKbNLDhUZ+CypbjVhr+L0Wp5qVfcCApA4gkiQn03HxT MTS3fjLQoBQlDVT0rCxL2p2ti8a2BHgzXic4+R12AmOJQzY7EaovPwCu0FQ/KDlx ysNAAxAjGMtSIJoc7SNXJxW3h2sszQDnfXe0MLJ0c128YVl7hOJqrNY7d2LM7yCJ i5XqjVJEonWVhoUKs8XZ0QeTGbq7gtmFnMEU5yyRxQCDCmnolWWtNUoeOKLRUCPw DSI4pkDBjrPpn3acu3Xd0ijLaLtmw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iMHEqxa+8VNhEJCJ3Vu+Q1OpgfTz2olpN3De7dgGD9ewTakFPJYJm1ocRfPK9tiFB4cQpjnol0T5GBGSPHtWAJMPHSzup6TPyuTnOj2Dbds1tsW2lIxiBYP30GXhBcksu2vm7FvrBoVZ+4tfggz35AKaCqyej9in3VWnhIgeQxJrUECa8WTbPcuoSbGaN9DbM/B0pbyDNP5YO82bx6kVvF00x3sJ///c8hQQU9pLYWKERxyw/e82/xX5XV2qux/0hACUOIAUgSXpc9tjnhUPHIOvlge5TwZnAiLLP4hM1n48j0qiUVpd8kH+2Cv6FJqR7pp/nYkC0Kx8eL37biAyMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YBENO+AVPrr9uTUjU0EffDFLvrFbeW1XWzcjaPVFV10=; b=BglMhNcHuYCZCe0SsbE+KVm0/E2mhQRza/YnYsV3adpIHnd1YG3fo4YomGR7SR5zTr+a+fHnAVaKXuRby1nDjEpT2+VFZHArVZ5VDDJxGTVkpxsEZeBNhWkzW9UpD+hzlwGM7ut1Srq09noWGPhZjDj3YtF5dTm2n4tnLsDDLTeefFxQ+7PtaciRvyL1m+s5IgaqlBgP1ji0U1xLVIWJNqDxPcgZI8WWJu26WSntkLeyaFiuN/9KiUvKRZA/QLsiSfkuD+HjVSV46NwBOEMJlide5WtRPK+zJ6E9OARIs+bJJUh8vM9vpxtiGEs2r4xGUZBmM9o0iZ863ZINETvKgg== 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=YBENO+AVPrr9uTUjU0EffDFLvrFbeW1XWzcjaPVFV10=; b=y0yc5k77mP1IFuLQhsLyjjrdwnjEpScLgla58rQL3fEV4pdKCVnyzAq9IntiqCTBs5zFLfhp5KJJHwThmSCswz4DPsFZTSxrD8MRGolYzDdfOaMDujvGMMwmhHc2MHE35KSiQ98u18KLCzeyCAWchAHQMC0tnUSHtEUne4v+4nVBLZwMp9lA3HGT7j9FV7JwqkBXrb7B9Il035dD+ETxj7uI5bOirF5lqxrcrumzHIhrIM09A/ZvHH+cWci0vAyUbhhHdrFN8TdIHle9OQ90kdW2HFBXisrHaYtavGdWEfl/y/Clp6tq8v32j/0api3YBj7BLjcT8uSovAw1zaYr5A== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 17/27] kvm/i8259.c: convert to use DEFINE_TYPES() macro Date: Fri, 16 Oct 2026 15:19:23 +0100 Message-ID: <20261016142031.1204281-18-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-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_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: e2ffdc3f-0a42-4cbf-f03a-08df2b90cfc8 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|22082099003|10067099003|18002099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: ja5sO/VtfoyKEJpIDMNve6lZX4Osdl2tpjOhCf8e+pGPrwdsONADQ5148himFqhrYyPUgMhb5dMCKUI6zKXghrUNIwrxG6ZAxHp5+WuDgRYGfuIu8HlMO2lBQs6szRhYDl+l08iiWcpV8EBGhcXek8ARZLC+rivDOdktQh/dsE3KgtqPLegEIlsejdxckoeL5BpllqzPYQRNAx54OOyXysIW5zoEGIorTE1ydOClO9Wv52uemDBneFz2c13Ak2f7fZg4Oq0NEItpHWiBLQ8h95Swz9oJ1YoL2lCWtvBgwb4M5Npgbao8ve8bPoxu+fHJKxcseLxZKrrjfrBueYxH6y9sKv8BCgwmrXW2J28yffkGDVsqrBk5BDmMOyrwsRclDi8fVC2N57GDXW722evDoeiTdcnmgX3hJmQqowR4AJJQv+4fVb3mY1yR9dBbYLUAK1zxxklx8/W6nK6fvl4wLZUn1nigNIT8prDFwIs5g4Mja/VmkCyT/nOdZ3P53udeiltXFFmLkD6F822SBjh7U2Mlmntej7XFt/Cad9gR92SB3tke+zsKUbCBJsEsA4bw+ML/0QoCtqn/TYFGml3+1z9r4NUMJFtNAaRYd7Y3uTn/9r9YCxQ+1Vg8KdtOW3aX+rkkSlk5yYn+JNzXyB4NvMBxwvloQt5Ix+THxQxvsSM= 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)(23010399003)(1800799024)(366016)(376014)(22082099003)(10067099003)(18002099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ydPtBzWaeJIqLY9DLlFLnielkCW67P+MlMaSU7uWuNl4YctqctVQyZyAueMM?= =?us-ascii?Q?SN2kYgOopkt29yeBiZCd0QYh+0LvvK2zoO1fJM0Lq1E/CLmYzQvBkpq56SOP?= =?us-ascii?Q?rljBYWPy6GiXlBANRrARHou0Xw8rD+pDo/aYf5ld7x5hAWucpMLP1qQ1yq6/?= =?us-ascii?Q?sBSgQ+QOpx2Pxzy+T6f7XoIBsRR7SCuR5uCPwoVD6awc6F6I4Ahh8S89K9Q+?= =?us-ascii?Q?mkZlqGJStSIrRxJi1Bv6rwACEN4jIiXJSp7sroA1SteGw0Odm/h1/wAMEPv6?= =?us-ascii?Q?NHyNERchJAbLxvXklnrzKQmgBgze+0hv+bB1MlL03zaQCW0NVACQeL5DMN4T?= =?us-ascii?Q?cUxcDahnpqM5CsDvG7wnjNR/dOfhYS9wbViBgz2F/XaCSdlH9X5DA2LuQgZl?= =?us-ascii?Q?EWJEslN+JN02xpvSVTAmiP29LpGc3Em5r8OAaQoXQ3rASBdDSOHreYHg08E/?= =?us-ascii?Q?MFDBpHySTQeVY2qc1/1QAWxD6v1ZNClOsb5oJsL3kb9y0ktIwf/F7jrpav1X?= =?us-ascii?Q?Id2CGZPqvuGJlnAS/9P9oDcyBkCdIce3Y4TXBy0xXIv6eYYzlDz2te6um/sI?= =?us-ascii?Q?k7E5b8lKZfiQiUZIc2K8oenCUPDIfba+aUQOdt6lBW2WS1wB79vpxHKkpnEi?= =?us-ascii?Q?ZlYZjzKyyqQeIKGl9eXXIIp8kDuvuAsQ2maMs8WG0cDwZu94Q4NnMWO8VwcB?= =?us-ascii?Q?fyD3hJSrHJOFX2X9aackhkbJMYxlAbSr0z5Ho6A/0hGbcTcsGc8VOrHGv4mP?= =?us-ascii?Q?FDwbKRbAKN584Uk45ckPPtSQ2oDNblBNaxFwc2HBcpIgDY2bMdZL2H2G/hvt?= =?us-ascii?Q?hsVsb2/oVE+4LairN1kDroAHpFHXYVEQ3xCcPWwiC+bA+zSis6+0URvar7Y1?= =?us-ascii?Q?wwm8LbOTrn+oTW0gh2xTChUD7o0+Y7cScbXt8hr6bHuWq4Ae40uJGLBI8BXw?= =?us-ascii?Q?PDC/h00Puh0lgxy1WBvMCsAZ3mY7bjc/TUh8J0Fe89wBDWnxbUqivns1/URn?= =?us-ascii?Q?6o+mATT3LH3E6ocP083yfibfiNKtFZEz73OzSWHImu2luBFgo2HPDs0NE/eM?= =?us-ascii?Q?Ysweho1B1yOzzUGM92EfjlcLexgw8noEEBO6xUNdS0/OCYfl90xP2f1eDph8?= =?us-ascii?Q?Y+vDGSHiGHLbZlIzsOG8CVxCoeDhoWSFq83pZsvg1C7rNcY2/wLLBdeedKjO?= =?us-ascii?Q?hg/MBRFJuDJPEJUwemMTiE+GUtMnMnKPyHM0N+C7RqeLZCCHCrGH7KOVLiUV?= =?us-ascii?Q?C7rXIRBw/qIMf+0NhOUV/o20RDV1heZn0r1aC4YF9BFO+LRHGtjfAu2LLBue?= =?us-ascii?Q?m2yIsF9EpTWwrwPBqRIa+dxfa7pCUVamwJkFbn/w3XHbF+O8ItDWk6fStD6p?= =?us-ascii?Q?aNDCvNB0YFk9WxF7lZBiRFfEJgA4beUpYbOZOYxXVd8sF7KfWF5TGfGsfQX5?= =?us-ascii?Q?xs6u6y/fiETVM3Fkdgi/1MqVGp2zbY+UBwxn5N3hiDVTW583yvvzJ5m6nQx5?= =?us-ascii?Q?WZ3K8U0uMVGVTPLOHTN4la+R3rCtz430DjOmjLBmRjgRw7XAwSsKGrwWYxCk?= =?us-ascii?Q?5Bm8Fo1Q8KK9fdxCdXP+JlrrHN8Xmjegte6MOO1iwY3JB0mXd85pQvI/jIQQ?= =?us-ascii?Q?TN1tv4w902aGNieprhCoAAAeE8jULMZZj/rsB7gisbnd3Y9y34vPh/2pUNrc?= =?us-ascii?Q?OpjrIkb9FIosOFqVmnXeeEYicWbsqKDiOpABzKbKCNKBcfZHTJsKKTwOlq0u?= =?us-ascii?Q?kO0bUi6XYLSIBsGyKiJ9mv7kLMJmNFQ=3D?= X-Exchange-RoutingPolicyChecked: oW95PpnVf1v7XGjQKtzJoiTtd/v+Gocblzb+QbMm7iZACz1vfgXD4U79ylsMJf6OilP6qyARQsFNTPTPWsMzGKZb6pgvhd/lQ+VshH2AuWTYkaFwjaT8j9X6F9lHRc4uQNbnlmJMOhu/q9N70seexaMH86iamo49BD4jcTzute+LJnQE6Fur50vtBGG58pRSRt/r8ZWAZ0Ic8MYC+YplqwJgTN/umTNRaQEH50ECtC5MScRgB/SPFGML3q7JpubE1o6/zt69/3LlT+yMzlJBhHf1YRgRCuqZmOGRDaPDlIzEJv2qElxUuSS44ObnkC/ahgCj0sfMFrFysjeQeseaMQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2ffdc3f-0a42-4cbf-f03a-08df2b90cfc8 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:47.2107 (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: vHckLfFReYsR/AF3V+lTmUedJhJT1JHx9nCIE5by1zI2ENTuRFo8+lwIvmgCKg6he5dutnSmXOsdUrVdgBjbA4nzgIT2FzL9wUg28z2MUFg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Authority-Analysis: v=2.4 cv=LsYHWXdc c=1 sm=1 tr=0 ts=6ad232fc cx=c_pps a=iImJYxtVBKilH24NLj+lVw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=CQnoaSmAlUSJywai4vEA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX37bWWlROPu1x 4/kdC/xVyoUZXpB47kZQY4ujHZC9XdOY6IL9xs/rRJi2DinCUshhYa2zMWz7TsZLoQ9IKsXhiVN oePokq6KHoVdyYXZEK6Hu5BJ5dz35Oo= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX5//kecltZS4q Jl7T8Hocxhh1fQd0p/HLMSDlFSdqCEJM23MwFT/9fZE40DL6tQ3j+uRoStkCek4VoCsoR9DN4yo DlQeeiALDLlAtC5HNGlGnflXSa09QaDiEFZDroni5ygQmSMj4ZJKom4kQmI/fpy2uZpXwwlHrBj 3826A5/my23i/CdWYGV2wPAigpIQvL6eE5yANFMrmQ5YcoHB+Rhxh61F20MOceI1CpjDEalqNmd mgBreGk6OYXM51rDcpxGMTnAGKmQlr3T4qXv3+5oLxUhTplFYp5/CKg35fPH1OPmKDbTTVmbPuY W9RpsViTmvDpTllxyhjfn3WQz5Y6OBfOdzbNZDuUiIGvo0+MhSKfmGIHPQGjAyPYVLZ/A8XmPG+ ZVwJr1I5FOzqzhxuuEGN3aV//gP5L64Ir5ivwd9WZmlm0sMoTKBr2lpTdbSYptAQ9LlFjF/4ejJ Ucs8ttds2t1VkEkpCzw== X-Proofpoint-ORIG-GUID: IGZ_pgtczq3NalqMEMKPUJZ7An8LRvae X-Proofpoint-GUID: IGZ_pgtczq3NalqMEMKPUJZ7An8LRvae 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-720697/1792160529-66EB32AC-667E5561/0/0 X-purgate-type: clean X-purgate-size: 1232 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/i386/kvm/i8259.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 952f58be11..9ee23b5695 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -154,17 +154,14 @@ 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, - .instance_size = sizeof(KVMI8259State), - .class_init = kvm_i8259_class_init, - .class_size = sizeof(KVMI8259Class), +static const TypeInfo kvm_i8259_type_infos[] = { + { + .name = TYPE_KVM_I8259, + .parent = TYPE_I8259_COMMON, + .instance_size = sizeof(KVMI8259State), + .class_init = kvm_i8259_class_init, + .class_size = sizeof(KVMI8259Class), + }, }; -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 Fri Oct 16 14:22:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:22:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452018.1666965 (Exim 4.92) (envelope-from ) id 1xHip5-0006gq-Gm; Fri, 16 Oct 2026 14:22:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452018.1666965; Fri, 16 Oct 2026 14: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 1xHip5-0006gg-CU; Fri, 16 Oct 2026 14:22:15 +0000 Received: by outflank-mailman (input) for mailman id 1452018; Fri, 16 Oct 2026 14:22:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHip3-0006bf-RX for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:22:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHip3-00Aqww-7o for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:22:13 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2330d-bab6-0a2a0a5309dd-0a2a4504e094-32 for ; Fri, 16 Oct 2026 16:22:13 +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 6ad23313-b57f-0a2a45040019-94a39744a0c2-3 for ; Fri, 16 Oct 2026 16:22:12 +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 69GE5G7J3551949; Fri, 16 Oct 2026 07:22:08 -0700 Received: from bl0pr03cu003.outbound.protection.outlook.com (mail-eastusazon11022137.outbound.protection.outlook.com [52.101.53.137]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hbmjc04ym-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:07 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by IA1PR02MB9592.namprd02.prod.outlook.com (2603:10b6:208:3f5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 14:22:05 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:22: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=aSoQnzPVPKCptsUfYQKIegr73fefTWafbQ2RSswwh KA=; b=vkAco6d7o43f8AP4p16DppFGsnuJz4Wg0pFzvWt7LJmsl82vNRnGRaGR3 aqUytr8K6PTZVL6aM7zZ/maX3COHXMo702E06/XZiq4MJ0cmhAfudk60qvi4iVeB pYBRgHjqZNuMQFYFt2qqUMn0rn8fvORpeY4UN3ZeBopWReVh+P7qzPNJPWFEXQ89 bj07W4xMqMACBJ57Kcdh0VW8VaAQH/t2pnfPrBO5EK5xtstZnchFEBF2Veub7NQw kJWwjXqzlT47Ii+i0crAqGhkU4uN6OlOEMDIY9kbizSU/jP/65cNkeUYT3vFOoWa lzpRtsTgxdwuw23Z5NErB/bC7XSnQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KY7DLngDo8hpl0Anym4YXCv3s0cVTp7HY5x3nufUho94b2D1WdXCmu63chw+Qpx/bbGroJDhTTUYiw0mi7ihTWkZDw613QoKb+m2y5m/bAocf0s3GWSrHg5HS3Er7/y1hnvLqGJx6aEA3XXmtnM7pqxvmRXGQDkWMQOjf10sSwUJ7XxBFMc11mL4iy1IzOHV1F7U7YtcxM0VNNX7rmmjUsEpwzbIMrV1+2t748jw+Y1MDrayKqu+oB6RdBnbT5dJE2jyzgHANtFvvA09BgueMlAbE5sHBw4V0rZmZttmwnKVq4USx8iSlMHyjLFsgL6yroSV/mEigOcMvRHklyN/EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aSoQnzPVPKCptsUfYQKIegr73fefTWafbQ2RSswwhKA=; b=hh6OVtxpLFTtSFFEKtZwcrSma5psJcQhPFZKhpA3DVRHFCieSldTtd183516qN1x4e17Qe7nnDxoPLxVPiOarLeBSTmU9xyjCUSvRWrmDtzBynbKL4rncndsKhHwZrgfg7VsGKRPtughWh+w1XlwxWESDGKoFP1J/q10tzEav26xn/vv1WSWm0hW9Cno0C4poTjvGIc7TqD4obhpvTpL1ydCY3zHfl0KLh3RNprzTRltuyB/PiczVw5q4SCdrPDl72fq8Ez3dRp9dWQyb307RG98KqNFNxI6maej2VPmIQVWrY6wkmG72t0MNXwQTbUwWh1UrekSDaRyg58ZiO4Ixg== 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=aSoQnzPVPKCptsUfYQKIegr73fefTWafbQ2RSswwhKA=; b=SMuySsvMwJxnIw0Z6qAGvLJJ6YbPn82TtozZW3CY3wp88ZIzHqsUtuGQr5aXxCprKjdYF4Z0BxO/7qH/L0nid7MiCV/bcwwYdZYa1Q6Vs8rklrQ7hxBF4K0glz9y9ob1lrhHtB6+7l3kaV72QupfaCO1KWy2Atiz7AZbeg0v5CmoJVf8iTko4akWEENSVyWEn5peut0+rh2tq50OvSQdyzUzghz5XAG/Jb0vVmbRzP7Xi1A+jRm7VziwmxbR8RD2rlP86Igwzsy4L6mO5KPHW2JCSg5STc4ZpwHNGsh/JTY7QXz9MZmXbS9LU/ZlhbTjU/CrD7f2OCpKm1K8dhW5rw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 21/27] xen-hvm.c: rename xen_interrupt_controller_init() to xen_i8259_init() Date: Fri, 16 Oct 2026 15:19:27 +0100 Message-ID: <20261016142031.1204281-22-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0193.namprd13.prod.outlook.com (2603:10b6:a03:2c3::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_|IA1PR02MB9592:EE_ X-MS-Office365-Filtering-Correlation-Id: b0553bcc-60bf-4ab2-f69f-08df2b90d94e x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|261009223027099003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: MnXqs3CIcxDGUcSn9MkKNbshtP4yfSjslKriu0p10v+WnKywAKuORuRjXOEi5TbKsrw43rjc4yolrMKvGD4zRX8OmkHA8dWdtE9jDGvhiIrFla5poISGjE5oyqOImdwUyf6lkt+VicRzCpokR3/GO2rhbrlg4fCDikK4BotKVKKD/LOaOEpCG3lm+YO20J8xFKjC8/ZS24eU5ukY91C5B8lvi3BqZGrdpusV98QrdeO0BZFTS1EyZbtAYy+UIlwijvwW79BQIPM66Loko7ibeX3AH+AOso/HrdRGA32xTDSpm42t3BSZRD0MEZPZa1ZNShhFYUxXPB3W81i3Tz3ra3/stph9CK6MtEjmb+vokt3lGUqfVD/29sP32yYIujSdRfKz0CNVesSILEEnRVHsyPOj5FaHWsEk+spmwaZgwTK3bWk1pGmGgRmAiZLpkdhVlZrBd2cJggUTP5C4ESczOscdVha+etpgLsOj3G+8I5M16oY4p5SIl7U39P0Bf5i6LZInUY7lAHCNwxigvgmqyxhCz58/E5kv8+pl3mou3TRpzPgM/Tc/0OnQO31e4KqyfrqL2eaCbh0l0QrkPFtSqVD+b4tuwKYimo1dgo7+UMBJO89tGZ4xMKhOXRSmvdHtR/HtXglK4ymzw096kgrApQKqx/QeH8k1ML6YygDknM0= 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)(376014)(1800799024)(23010399003)(366016)(56012099006)(261009223027099003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bXCUn+1o1IpiNx3jsc7l0PRyalnu65mP/DnQIJJwgljUysbkmsKnX33xuOfC?= =?us-ascii?Q?yHuCevbPnKBsIyQ3esBe8gmp51yeyfJDxZIeC+QW4fQeLWEHNfxg9Q78CNKQ?= =?us-ascii?Q?B7r+QGG0z6unSG5WON68pi5xuUr0FA/1PGkVyULgD8omkyEbXRz6WoFuFolb?= =?us-ascii?Q?qJTzpuaak32sNBL00MsbcL7RJFIlv7sA6IIJQRRG2jUwrLVLYLMCOzor3Hho?= =?us-ascii?Q?u6pfTYQXwH89Q5YIpAe/xQ6eoGtSQMKjS8wOv2zCWz5E5ZjOPl2zbXBBfjz8?= =?us-ascii?Q?scSRC1c+O9Q9b5bhZmwaL9gcgWPbwIFVmQy8tsLkuiyXn2/CXoM7MEaN6TJ6?= =?us-ascii?Q?ZeeZLobu3P/PZEKzvAuz77xTbw3+WyZXBrBm/xUs4cKD5BoSUv4mm+wKXIO7?= =?us-ascii?Q?k38cVoUQFKgpt2XNuSYcB0rG0DWADqWMJfHP5Nsjo4wKNUFMxfzxtYx8FGII?= =?us-ascii?Q?nQsDd4BAyQyc67j/1NorH7SWzRe33P3svoJKgbJP5P01hZiYsLi0pNr2yjsb?= =?us-ascii?Q?F0I3kOtoS1+M37gfC7LkT3xPdaUZWqGyGGxNirNJ3W3aF+EZd3GZMoyvHiKs?= =?us-ascii?Q?Ptm6VS4QHw7nMLgYtWoDAstyrEy9uf6MwZXCtI0bX1EFrZ+BmZDEmmkxF8K8?= =?us-ascii?Q?lCkalgV+PphvMMmfaltuN7+j7FrMgfWYqU6slgqKCYKLhHprpjTiswxJrfOX?= =?us-ascii?Q?GrCzC0zJKcCU1ewlaADh/DvIuDCDy4hy9jCA1d4OlRd9D4bNrlRzMj2eajXZ?= =?us-ascii?Q?6p0aa4XpMtvCAaq3PDkmTA6CYGK7KmuDbln8WIwv7gdusaP/x4jNe4RDC4vs?= =?us-ascii?Q?GA5B9uZ3qKAiurYrm/vf/iWVjTfv7V7Zng2np1fyh5Qs2RCt/dCCXTl0ESE+?= =?us-ascii?Q?atD+XYA8nqgc6D/6IFgdrjK8CXkdSVR9LsNQIUhYPNObRv7QxB6XXq0blQOh?= =?us-ascii?Q?v3UMfv86SB8u8R8UUaitzwKKkhxu07tDXgru3msMlJLFsn8mQAZCs0UbzJcI?= =?us-ascii?Q?o6mAAi5DWT+ZzsCheRHdhBJQMEWye32j74Km8eUFXHHaWw2CpP0gRcSAewhK?= =?us-ascii?Q?fxxE0YEBQeKjBLe/UckcWzBb+RR4wiT/NRO1Kxb928VopMaD0kR7YMxi+gnl?= =?us-ascii?Q?DmmwvLpvf3aIeiVt+vAZpy+Kjh6NYLx1X/gcdJT7yu7ZqmVW7sHZ1lCMOMUC?= =?us-ascii?Q?+EgJmV/iccb+jBv+y6/OCdVoemlDQFITFrU8SNxzx7bKO+jBts1eIYCJ+PLF?= =?us-ascii?Q?5vYHJUyGzGHaIesaGujT6/RbhoagF4KYIdlaegDX85A8+Bcrz07x99HpT69s?= =?us-ascii?Q?zP9iD2VIa0kC0JNBoqOE/zDJQdbThKIeBIcdlchbX5ebYW/z63BxBOJhLqDw?= =?us-ascii?Q?PDE6rDZcv8aA6IIVIlE3fBp8Nvj4bgw/Pvii5FHjDU9gKzQBWFPxOCNzwnuC?= =?us-ascii?Q?StCrqKEN0Hw8CcD4sudWSq8Q6K1GxrFotT7KMyhPcLx8uv6vVIsLOv0JFLK3?= =?us-ascii?Q?oHidki/KUujvhCPS1QsaiyubHiC3MtG204521fpYvhBQTGxGOjdAhXUNjS/C?= =?us-ascii?Q?ryTWZYMoZnIG7hLGL9/+ADlQUmDxYkzb8WbJ8la7MPL/3APYHShUqrgGFzxO?= =?us-ascii?Q?dCHVYkZfOLpvZ9hljJzeX5vflT+UvPh2DbA7h1nq7WQo/tKUkO1b3r7oUjnV?= =?us-ascii?Q?eJQ9QA9b8bumwCAhTjnK3w2VoGnlMKENxui0Vah6wBYHEK3XoH1qaiOBqpa0?= =?us-ascii?Q?vE5MBM28w8Mhyx0UjEtduRVfkBGsFb4=3D?= X-Exchange-RoutingPolicyChecked: FX0tCw4TYGJ3DRo4NiMp+yOdaNqqbhlrnQ4W/KagyussV6cUnhoDuRHYmHucmu+x+wepGaXR1ajxylM4pK2iNohKu5sq/lKp+uPvZKFs+kglyJYxBDshmENLW8xQElewONJ7kwsXKBmXpoBaCAY+r0TcrR0j7InZZ/eVkpem1CvDfBQ8fPVfUfi14u/2PQQQgA3vAHiRScHMtK2HsjI0jrNIzCnQay2vt5fyroSJBPSCsiBptwSeLmbwG06XqjDn4/Rr3K4ZP/aaAT15zq0gaLZHbwjDK/Rzp++kc86X1HRnYu5acsLkyeV+tVSWYHN7rep9C/5uaSO0A50N3Qceqw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0553bcc-60bf-4ab2-f69f-08df2b90d94e X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:22:03.5699 (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: qjhzjaMP7tW7a/EuJp5Cf6d9yXMFvXxigQHFmkHgyl+ipz+WTazTj5A+nUiPFreONEtfpkfZDi7f4LLW/Y1dU5t6c0+BVZRYaYD8Mk2V/P8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9592 X-Authority-Analysis: v=2.4 cv=dasVTnXe c=1 sm=1 tr=0 ts=6ad23310 cx=c_pps a=XMkfF010lpKDMmMg3xIHFw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=ufYRZG4kn_nPcl-B8swA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX/15dpH6RJmRN FwwoPyPOX9/HITiYv0s9SAmwea12y6nHOPs5WLCLqe0erKxYbp8kvaKvDmonRW9nBMy27QR5cpp pLmX0WxDwxxpvTRFOQcP1KNGBxi2ZevqpM19SsOBWCjehZZlT0CdnWHCaKiYsnRoDz9BdSOyvyD 6XNq25EMCAG9UogwsTganewXa6+4A1tpQP3Bqz2KqeTk6G/8frXa11djaaN5Z8gn3I/v6Q+Kcs9 8+VwVxwj9hS++aoqr8gbGiJ8FShG7CycbY8mTXYD1GBLfEqefjUkYCzBpJlDgRmp1lGblw/ppg2 EfG+iqu8hB26a+EH5U2LGOVeCGoWnapxo2RoUgPUPxvF1uHaB9LhGmd1AyZ3jzmwRlFu4rabM9f ymqM5jPohYRYSSqPTQgnT9noVTrWTwEXnnvpFVCp/dVWul2NdJiB28RxW24rb1v3na+FAUVrGir 80C+yw3HUImqwNsQoTA== X-Proofpoint-GUID: F0rQwAs9UDk2jRV65-XabXt6yg0qkyRR X-Proofpoint-ORIG-GUID: F0rQwAs9UDk2jRV65-XabXt6yg0qkyRR X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX9blZG0h6UF/c ZtyP8XTH5atsm/y8v1dyOVzlTTjp7YGXyiNfY3ng6hsNKHbmEloQbUmsnVsXlXzbTLWL4rpO90Y LxjyP0fF3j7XTtbulMccsqcJiJ0FKyM= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792160533-520D5B50-AD54B149/0/0 X-purgate-type: clean X-purgate-size: 2252 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 Reviewed-by: Peter Maydell --- 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 2d8c87b0e3..dbfd55de30 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1167,7 +1167,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 Fri Oct 16 14:22:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:22:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452024.1666974 (Exim 4.92) (envelope-from ) id 1xHip9-0007Ev-Q2; Fri, 16 Oct 2026 14:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452024.1666974; Fri, 16 Oct 2026 14: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 1xHip9-0007Ei-Lz; Fri, 16 Oct 2026 14:22:19 +0000 Received: by outflank-mailman (input) for mailman id 1452024; Fri, 16 Oct 2026 14:22:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHip8-00074V-AX for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:22:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHip7-00CcdC-NI for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:22:17 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad23311-2eae-0a2a0a5409dd-0a2a45028bac-12 for ; Fri, 16 Oct 2026 16:22:17 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad23317-6ca4-0a2a45020019-94a39744a8d4-3 for ; Fri, 16 Oct 2026 16:22:17 +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 69GE5N4R3502701; Fri, 16 Oct 2026 07:21:56 -0700 Received: from ch1pr05cu001.outbound.protection.outlook.com (mail-northcentralusazon11020115.outbound.protection.outlook.com [52.101.193.115]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hbg268s49-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:21:56 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSVPR02MB11424.namprd02.prod.outlook.com (2603:10b6:8:352::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 14:21:55 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:21: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=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=zJLaHMP800ZLe/QLftrXKhy1QBGER7Qp7toLitf2O 64=; b=CGCdnm8T99Lr0ZjgM2T9R6laORwrKoHUw0O0cZ/EblhDAIEBl+6NgXlRg QCtexDjQCT2Ky2mOYq/NqeRL0RLhTXhj1HE/Dn3GsvIsI15zG6o1jsbSq20J90Db 3seEuU4oKy3bPxRUDQqCMI28K/6/XNmORZS45suieULSjgguO6DYQWVYSP8TcUT/ F3qvn9f3GW2HKuRK6qMvVDwcXcAEIshz2pMsiATcstMCNgGnTKKhw3hUtJcjP7N8 XTPwMw+00XIk5XaOvOY1gBfZYTe7BcMCjjMKns2koT7nO/7qVjOkMWHLv8N8FsIg yH92yMqjM+K6GvPDKvJ1tY/+j+zeg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=msLAGvLrzh3XOHIHFv1gDlfjhqJQGeYmwiu70oCinv6TKfM2Az2Ppd+3nM71Z9Zv1WosBrwqbgGBjAYmmEzeDS67QECsZgh8+fy1ToY6ulAJ67HH0zZsqVeGQU/R46DdbfhW+srrfW7W32xDMIzSbTcy6Q6O8oB9IW5oTgnXNAkjIRjF/C9GIq4iL/FEueTgAsS6lOVtdV6WBDzrOn7KdN92hmdLkRRkNELLMFNFIXjNM/RjATxjoW9+oXoxLsN4bSRQb5zRRx7rebM+HgA4DfjPMfei4aG189z69xjbX8Gbi1yL1UYRpokXMHmh2YvRTtION/jxMSBBTnjC3aRCkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zJLaHMP800ZLe/QLftrXKhy1QBGER7Qp7toLitf2O64=; b=yPd9eUoxOEy5Ikxa+wR1cAvGtFz919fXRPRw38QK3hSCNkBJTwwoWddOBjXw5i5YoM1evXuVwxQPVrGSMEmERt9z3/RRtLW8GFJPtogl17Pw0UHUFF1sZRbd6rMVtHqilFGBSTWTLg/Zck/NiPWNKebgacHCrN0HFiM/Z/ukpduPv3k39GlG3wL3jmlEEHql3DXh4gVgfku5wwWJ5FzeMSu5RDjHJjkebwXqRmfuBqcwPXJs24CLm/SJFg9cg1uIS0qgTwwmdWGzn+0xqpcd5SBKqmxYZXAHu8PfgUtGnVknqH2CHhxbOMM9OM5BU+oZvEN88S+pwUAD9Y7sYqVliA== 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=zJLaHMP800ZLe/QLftrXKhy1QBGER7Qp7toLitf2O64=; b=UTniDOq88F5464cVZKayfm9pbUK/veXSWQS12kzxnYyzv6ImU57rqtQnIog3T09LSarJV06cgeWJ7/Y4xHUyn5geHuf/FhxyMCSMuXrJA2bkYOmDOwskKtToHEo/wqrgTxYwgcFTV/4xV3emQRP6eBhQR3ialQ8t2bFSyQg1klEDG0DlMdj1iECTk2L22n8MyQFP8c9K1qhmRE04MUtu9NjwW2N3wNqf528QbTKiz15p63e+yQuPw4+YZcLp2Y9+yobdRFfdQUFK99YhKsxmWab8lAOuGryyGraEECfS7ZQ7VaPSilVkQXdrf5zBr3w2cN/mnCafY/9aAzIT35TsfQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 19/27] i8259.c: properly cascade secondary i8259 from primary i8259 Date: Fri, 16 Oct 2026 15:19:25 +0100 Message-ID: <20261016142031.1204281-20-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY5PR03CA0022.namprd03.prod.outlook.com (2603:10b6:a03:1e0::32) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSVPR02MB11424:EE_ X-MS-Office365-Filtering-Correlation-Id: 6186d3bd-a8a9-45a8-6338-08df2b90d49c x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|6133799003|22082099003|10067099003|18002099003|3023799007|56012099006; X-Microsoft-Antispam-Message-Info: J/AXQHDrD6uAKR1PJG5Rg9FAzcvcauy8cPdjHmbmrcaL8dUtuUWvXuDJ+W7PXZCqseSKxLN4L+zPJW+IlvA9BCCNFLqilOxaL9wU0b16ErH6xT3kEoyUiQlWezvJDTFBAcjPGbxS5UZM4gstL0fIFQkCBoG/RHv2qQ9yAqt51W8ukIxH8hu9oxMg28H3wzjwVpYjnbX+wTTmIEQcE8e5Zit+VDyKzsrTrh4CvzRWzPTz1CJm08ZM8NPzGddpO1k05MXf3SREpkvIJWzYpLFGyRLEQDknEaMP9OOZ1INJ8LOSR/dFPh/Gh+7CRyLVKXB0xlTrpWddqQmdsUwzG2Q6RkGHnDO6Rg+Vj9lNQANYuA+78DqRGzgPv+tozVrv4Tp76VmJGjjum8TA4GCKN1yoXXO7NtB5177sNidGxX2Dcx2AAVWq/dqdDmBcWvAD7+LpqHi5z58cI/Ltowh+5TOCe0Za1geAibMrA9yWY4RYsSP+7yXpfacB/qwVamoFra5+FSUQTg0s4p6amlPtq/DPGmdGL91QRgsw+jJMdOkEo4YdDb5layxx8Obd5sSYdBirNdStPtOsWR35xrjcPj0SMFL/ToeXkOdmzYG9oWgUgDih09ZnNraseM092P1uncPP+zOEHNcUXLy+t+AHeWmzUP2X151vng7+XBeDMAJPncc= 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)(23010399003)(1800799024)(366016)(376014)(6133799003)(22082099003)(10067099003)(18002099003)(3023799007)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?qDCaOc4q95Ron4SJodoCM/RrlFJa6t6eG6dz1yC+946HRC5eJhH/Nx5WMPtK?= =?us-ascii?Q?f17ryAzNVUvGINP0vRWFcP3eTEnr7CYFP/WzfEQ0ks3ZDGkCkFBDhX0XGH1b?= =?us-ascii?Q?qlI9Cz1qV6GSfxRu0SmlpI9j44TvaW2IN/ulcmMuRMnXyyGajMhz4iD/iXYj?= =?us-ascii?Q?IL+/ilh7X5Uyfq39IiWT/jHp+r99j+amIRPs4PvtpOnOAYHbw7wZB6DB0X9/?= =?us-ascii?Q?KYz2rHi2rydThqFDT1cPRfB+6hsX7PJaP/5apRqJOSKcQZ7V7aT67Q+cIZgJ?= =?us-ascii?Q?zh02C9SllytarMEPZlDvB1l5LRs9yqwXaO4nkn9prnpMywZwxDMnqXXkXS71?= =?us-ascii?Q?VQ80yWHR2peoWMNuwoI4ykK6bXhWd5d7Adr95uz5wuSkMUfO5oOuW04jftMM?= =?us-ascii?Q?bZ0bTumtRkr5aDCurfF8208vmZCo3QLaddL92nvXupV+bolhS/pvlRi+NER1?= =?us-ascii?Q?EdztLNOQacnu+l+6qYQRAOezreK2g+Tb7seNL74D9yLDOaDYrnkIJWZATnC4?= =?us-ascii?Q?cVNoDwrDIc2hzyU+K6SZ55dY/Zdx+LqWPpJ3kb4lKDXzWESRfUyLfJKCop2R?= =?us-ascii?Q?bUtZNYf6+GTHeQCImVdDdO/ZeYw/QPya2uaPrYxGjt8N8pvUJhxgkBkSzlYX?= =?us-ascii?Q?tYj0ZwCf4i5XI8pbNH63cvhVtUln0KaRAL9ETSXKSCn9PZO7RURoKa9PuLFg?= =?us-ascii?Q?2L/ZZOC0kjVR9GNpHfK0l9z/qkTXFqWrP9zgYdUHOtNiNfaOfOl7HvMG9Z2h?= =?us-ascii?Q?jFnBuAqgloT/33OX6dzJJwialCqy9JNQWRTZPuz/ctFPxyam4fIrnhVESHFy?= =?us-ascii?Q?OFxBuFVrZDDuyyj9lciIcBKzwlEdU9Ykhffk1vgFFKn5uJafHhqdub72khD5?= =?us-ascii?Q?/JmfP8FL1uuX0ztoQfPKyasIXjRGGfJ7CGWRzAY0XPSJ14i5LuPIhwf+8Yff?= =?us-ascii?Q?VXjLNHIcRz2nvR46xB/lcY9xJBmyafe1zpK2Rc9TS4tg+sP6XklsHqQ6cDbq?= =?us-ascii?Q?CfKgN/AsOfaiooiICEH6yHKlDurNdmzWrVMG1M8ri/qj8Nj6tguU/+2LmHgj?= =?us-ascii?Q?1hhOHmgFAuUP1wo/Hr34EBtIIiRXIJVQ9omlFafLvU9INpC9VReKiigRQHG+?= =?us-ascii?Q?s9LN4PkYa48fVdOVaXBmaNBX2K80mQNCT2zF6fkgPIG/0VPcZFNNqa3VF1dG?= =?us-ascii?Q?ZjB9mOI1Co6F5Z80JsImdZENaiOSuuQ+VAUJz6CyjsS5IAPbRmne/do7FUa0?= =?us-ascii?Q?I4KMIgeraCWLqNAunk6GAmWOLclI1oNPf8LDd0zj4gAuTBuS70aaz2cioLre?= =?us-ascii?Q?vTRaaIVTxi24O3I83n4Pa+iPbA3Imy/dHUvxR27b3+CXlWEqfC3uagdgjwFJ?= =?us-ascii?Q?56PSPEekq4G+27eMuCW7yYePCRUyEopvYYb1h2iA1DkJZrN6R2xx5tsWDlYz?= =?us-ascii?Q?/aaM3KhW4qb1JWIgC10AR9k/vTr2x6KDByooYlbqDOwUef0F5rZAcJKj4re3?= =?us-ascii?Q?i3d3dSGsq+P737fFJyD3A6/9hm3iQEunzAghXgKy+U5y5Wu5S4MijahSIPb5?= =?us-ascii?Q?SuNtta0L3YxTjqDpTIBWy0jQTZ+KcXQXkMTISa7R+dZPcb5yYXlmXbCW2zAr?= =?us-ascii?Q?yc/WUoxZ4njpNZ7E6OK48UODoBax7MGg5SU5Y3w0kA+j81BUYVLi18nHwoVk?= =?us-ascii?Q?nWPtbDYVygHWxCrIs6m4shyHukU0xHCNX50Dy7AqUmYdRG90r5W8t2XYC5Ji?= =?us-ascii?Q?1RgUcwfKXjxqCBm9GIHCBnytvgvO9xs=3D?= X-Exchange-RoutingPolicyChecked: enMb00uz3c9uBuBfLvVnTSaCmW1dQzaADCkaCkdOUvbSrns5Ytan6JtXLsIHpEI3PeWbCn5GEp7YaIQRf9vfFcAs3aacwGQqLhCPCXEfWstD3z14LNKahGCdF+OAg3mNJZHFcyECflhkxfS4lxV/aW57i0SoBM30x0OUDLVztQpmcCHXHX4vICWDIrDK+IQfdwDYm6WyOVCQ+onG3ZvQEBTXokM1oJDto+I9YqZPt0RvxqoM1PxYJSDtxi8WfVuScUYX/A/U0YdFgntZPJzgQQtyO2kIXchwKox3AICkWaA7Bl/+3VhNcaRnRZ11Tr/lxmwRLHk91F2PUpqrxi1HIQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6186d3bd-a8a9-45a8-6338-08df2b90d49c X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:21:55.3735 (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: QhlLLmABL68CLZAse4TMBcrNE4Hdkors8wv4Dgj/j2L5xjva7YNZ3mvyIK5N5+fhm+w0W408TB534a3AD/epNuQ9lA8ZF0Nrd/JkdoFtefc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR02MB11424 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX+8P3W4aKMO7z 8E9f6tmoqAhlaGkrNhbJuzr/AdlpzgKx7gzff03/cGroxhUfGyTgt0rs+vqsYa2IQHWfaLKnp0S oNCsriNZYo6PI+GDiytFiaMI1BV5YsI= X-Proofpoint-GUID: 29ctTzvAopVc6NTtCJX8QK7a7WYUy-h2 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX65lhDD62t7Hr xQ8CbwW1SBdXUts7SrpEQX8yKSTlY0Jq2otTsQRPWuOf8OeFNqKq2ojdHU9OJDugkvubiB9efnJ XkmXq4fk5nGw/A7mCLBqnUh2PwKyFa5Z3v+xmsLtwLF6GwjI7/pdJErT2YRjBjwjpyFuGDaJgp5 NmNNTMd6VnjaAohH9hKc1URHSJ+KJCtYgYm3ANbBY6WAKOZhz1lSHbZBnl1PNaPkb5DRR7CtFH1 oyGOuzdEz/QO5CuXVC7gczJm9yOZk7LV+mpwkQ+osKN7C1pw5NvVReAjv+ricz9hN+tOFJ6qert to80CNMEZLacXoFzXI6fYtahCA+6xWlKipHezmXUbregG/6thoUK1oP8OKss1A05k4UbaGwmhIx OuqUFZo7QZLwUW2/R4/DRQuoQagVp5owmIdUP3/ZPQuHzfhAGu730p9Qeo6lsI3nEFDiSs1d2VI 0xd8l/5c4kte6Fem38A== X-Authority-Analysis: v=2.4 cv=G5OJgNk5 c=1 sm=1 tr=0 ts=6ad23304 cx=c_pps a=1UxUaKSOIsEpFYfBxZ3OzQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=1L6crL_YRTbalZ11mEUO:22 a=64Cc0HZtAAAA:8 a=BYTbfossBeh0jvsGI5kA:9 X-Proofpoint-ORIG-GUID: 29ctTzvAopVc6NTtCJX8QK7a7WYUy-h2 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-720697/1792160537-F1AAD2AC-24968047/0/0 X-purgate-type: clean X-purgate-size: 1060 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. This is a bug fix since in a cascaded configuration on real hardware it is possible (although unlikely) that the cascaded input from the secondary i8259 can be masked on 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 bfe01067b7..5f90edbe60 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -519,7 +519,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 Fri Oct 16 14:22:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:22:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452025.1666978 (Exim 4.92) (envelope-from ) id 1xHipA-0007Ig-7d; Fri, 16 Oct 2026 14:22:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452025.1666978; Fri, 16 Oct 2026 14:22: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 1xHipA-0007Hy-0p; Fri, 16 Oct 2026 14:22:20 +0000 Received: by outflank-mailman (input) for mailman id 1452025; Fri, 16 Oct 2026 14:22:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHip8-00074x-Fq for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:22:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHip7-00Cce2-SS for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:22:17 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad23308-8faa-0a2a0a5109dd-0a2a45018e7a-36 for ; Fri, 16 Oct 2026 16:22:17 +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 6ad23318-5984-0a2a45010019-94a39b0c31a0-3 for ; Fri, 16 Oct 2026 16:22:17 +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 69GE5DbC3215898; Fri, 16 Oct 2026 07:22:13 -0700 Received: from cy7pr03cu001.outbound.protection.outlook.com (mail-westcentralusazon11020083.outbound.protection.outlook.com [40.93.198.83]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hb045k1pf-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:13 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by IA1PR02MB9592.namprd02.prod.outlook.com (2603:10b6:208:3f5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 14:22:11 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:22: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=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=WyA/oexDigpjp1MqIVZSX3oyJADfec6ddFmZwK/KF s4=; b=SBxmJgvx5xZXM3qjZUP5KnAN02qD8RBzw3oAeZHaq7E1Icr7c/Sndvj+c O6QU+pIPEH69DbM9JRbUnjcWPEYbY8E+tZL7swWVy9cP86RMI8DlUgsDG5n53tdr Q3SLeW5ncixnqym/jnelgNii03EU/bk7SeEm3FuH+yLABYFzVnIAYpmq9+7zYvXh Lm2EGWwdUanyabvx2zNE3koTCSdQzt2OYN/8C7DslpksLXRQUb9llQlKzE3VWrnk loLiEttlmvYwiom29lLCmGibTDeCjM94P+BoGPB0OgXERoYlc6srHqyf043EgrBD E+fnCFCZ//h1sL9fR64/nKhheYfNg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AVoPzWnpIdaOvUhn64na6QlOJ5cFty30Wmk98CA1tsurCXO+F1h8CXuHwTi3+YYfhXvQ3wo4SAotxxdBWFzOuqVx5g1h4FOKkm3l9QNAHt1S6wZRzlhEaQa4+4pNKMz925h7ZNbANCJH5NaljOpwQRl/W2Pa6GlwPHt7cPdZnsb4dA0pKoaxsQMUD5bhPhDjieAB/N/FnvA4AByZ4YZPiibhH1JnjsZ4i2magfN3FVm7cH0DlP9hIwznFrc5WP4vkmOD/5wh0ixFDBHcoP+arEfEJyyRkL86e6ks540BW5NferSlORzlFIvBqQE0dzImAtqGnBAMAT37A7r0dg+HOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WyA/oexDigpjp1MqIVZSX3oyJADfec6ddFmZwK/KFs4=; b=zOQThd3PwuSkIvrmMlZSSVdvXWJFHrnsz+fHvdRKEZGaG5ZqoTeXlfK86qOU/wlwVyAlyXpY/rXhHIoIBEczN7IKuag6F2QjsJjUopHXB7GM/QgiG0IQ4cHJOLu2LBAQfKUeU4zgZB7YX7hTISzJKswg4JIV6EPonB3dF2ChA0k+L9hzvP4S7wSmxUDeZfJhRg4C3p/Up3mU4Sh4+ivsZ966GC2uscFAIw2V99ieL6R03aPKTQhV7PlCPt+gyko0cBCfExXTCqRWji0avHCpmWMZmE+XgLF1n6LBDpghY/AdGOmm+C0shFEDvmafIoC72M/xlTBoL9M9n0jkU/HLxg== 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=WyA/oexDigpjp1MqIVZSX3oyJADfec6ddFmZwK/KFs4=; b=QByADjrZzoqlF1WdJ+gdYu3//EKAiqMoOYLBtloBwXw5yKGMrc7CC8RWnlND3LCj7ZP0s1kM9veoa4JNnFnUrrGbFRn1DaVaW3I2JLBI/409HcwXCihx/avbT62LH9vNm9suci305AqC5l1SPdrvdBjTEDjPKSeGMau+rcmXLK07wOCYmsvtdKyh06DxO0BlN2DVfUHJWwCJUxuh5M+q7+l33jvtbRagPi9k3/S4EceVGgK6RuDwDNPNrzogm5Xssugq6tzqPhZKO347Q5mxXnOXo5qGZnKSo53urj7CMYNoHxFHh7oj/olV627SqL/UMzje/3Ls/rYnuDTVVklTOw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 23/27] i8259_common.c: remove unused i8259_init_chip() function Date: Fri, 16 Oct 2026 15:19:29 +0100 Message-ID: <20261016142031.1204281-24-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0013.namprd03.prod.outlook.com (2603:10b6:a03:33a::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_|IA1PR02MB9592:EE_ X-MS-Office365-Filtering-Correlation-Id: 96844c28-9ad4-4018-37fe-08df2b90de44 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|261009223027099003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: Q7COnebCsg3z83kVbwkzUKGDwsBFAcL3mJ/kaxmaWCJr3V9Simo4bEk1egT6rFoOqviGSHfy9gHtlHrsJrOnKSllimq9wx4w9YQxL60zTQFbVh17627fU5QcFyKjmc+DuuTQLPFzgSrq10PaUgeZWmY/dk6zTgY49+Av6lDH5aGO4HMmnBCytKyJf9KqhEuty/IZm0cc1TsQHLFcgg+MO2fs89CM8f0Qhy287Ie4PDz0GMHoDK7lM3s8uqIk94De37zhMADm0+D3Vrynhw1aunZAlxQtGxapg8mVsvFfTx4MHUGjkicttX9WNhLcN15AzrrS8LrwwtyR3rRWAOBgRV5QPtLm2bfwUmN1HztJ+lMmHkCVrTLv6xY0saqpqVnT/xNDbR/tinAuQRUehgb9sd3ba6RNZ9fvWKVCC1KBgM1LwhRi82SkXjUPrNTMM9lx4xohxqJr+e/k7k3I+CR9wDRAtMNxOIMcdvuwZjSL6K05qsvOXZ8GgAT+1IHd5QnsW7b3rZDAWx58ZBRaJJIwZMhE4dnyfcspPFUtZ3VgNCDfSWcejeHnN5fw0kEWp2fhAaF7DhJG5Tj6GwI1ojKXOUzwsnHXw097xu4z2b9UKhQiTR5IpKc1Ao94sonjqeh1hS6qFep8Z2yMHzJNNsAnVZ5OVcsX0pAemKSjmG/Sku8= 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)(376014)(1800799024)(23010399003)(366016)(56012099006)(261009223027099003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?1r9g4g7/cBPL0WZlWW7OBB5FXXlA0THp1xxRcO6hZ7B8IdcLp3gpfWOcLnz8?= =?us-ascii?Q?ngqibE4sFm4rwLO2sBukq8SURqB2Wy6n9MHWObvH+apvhoT64qmKeOtBMfpS?= =?us-ascii?Q?t9pUEj8DC46PNrCXM1d2V2PRWJLTM0o7xFp5qbXT9eiyhcvnK8c/vmUi4ZJO?= =?us-ascii?Q?PGl5bVUXaa4Er5/UhCxl5FKzporPG1UUqKSP90LBJeW+rdQGRspOO9jUmIsU?= =?us-ascii?Q?sA1JrOQvaRjD7BUin6At8WOsBfZ8s5bgOAJb0plLVvXRsBULAF2OXQI6tCCX?= =?us-ascii?Q?8Xm36TF//AIFtUwYiPaNJpENDWDVsTElKN2+zroFafRCo+RGu/ei3nNq6cAu?= =?us-ascii?Q?sZfu6DYSoZm/CD8x1QtdRipHg/AV/2524X1umqpKZcTRuCZqMKnDqVXdXDPR?= =?us-ascii?Q?4vNWERVxULeJPdLoAskx8nKvq9hKFntCC3kcSNwLwaAAXcfKK9WMwDLwwKUw?= =?us-ascii?Q?9cug8fErEClOperNsqYEw/vuq+P3iIDDuDLbhXxtlovaeyGeqhSRIim0UXpn?= =?us-ascii?Q?I2oVbd+c0bgrT4qXRh7zH12NjiN6Who30kSYYTSEIZDILHQvfPVsA8+MNokb?= =?us-ascii?Q?OdAS7b6e24vAUHhap5Feendm0lXha1eGB/K0gtYUtkN2rPEewsv1TQtf7rVs?= =?us-ascii?Q?xTbWj1//EECcLao+y1yZ1Wihi7Q/573Dq8OGUZAskCuzx5RBphiPXm4LOM2x?= =?us-ascii?Q?ZkLqVT7Sxv3IwMQ005cTqdh+bm9zjq8i2ytEVqYr8WaJqI0b5xDCYHsMbrXF?= =?us-ascii?Q?XSbMH5IMaXhyvwogySRNnqAliVEJO83Kw8uSZPVOep3sv5fPOksMz8O6SBOi?= =?us-ascii?Q?va/iOyMo5uvE2y/1ogl2MVBfjYNRbOVzMDONrJKLEyuV/BI+aUtBDfEfYwCs?= =?us-ascii?Q?aFOkVr0JYoAx6pKW1f6EqDRLnyU95dLAx/s+EA+Vy3kAlo4+rwdSN7BNoNg1?= =?us-ascii?Q?BZtr8Hx9wwIlKNYXJIloxdX6EDOaeZwmYP8ZJwIVkRynLIR6twer6ZS3rHE7?= =?us-ascii?Q?r9EC2Y4L06SduUzfXMmt7q2G1oERONoqehWWdrQslJ7SFhGwBmObkEyOczZJ?= =?us-ascii?Q?Ps69sLYXJRrv64XyRPJss+HwQthMcpI3st0cycg3RXRSG2x5pZ2eiT/U5wzc?= =?us-ascii?Q?3JMkQawXmdLTBLguJoRWfp0oq7AO7RG936+ZdIQvmhNnERXXLYQc37qkUFDu?= =?us-ascii?Q?S7OHDss1xhXamxGqFkce183au3bw/i60eb4zhwDTZoays1QMsZ2Xrxh3W1Ix?= =?us-ascii?Q?5knRYCwAgvOfTlX5kkjQxxRmY5wvENyIXJ7loutIXlkDLirFEAB7w1K+Ntco?= =?us-ascii?Q?HK8i/TRio4HXDePVPRX3C5tauXStJY3I+3BYasnFSKO9TtcVzXCu3aNJGYYN?= =?us-ascii?Q?5BjIl1n2Uz6G2pTWdi/b9qiGDCoiQXnI8kiPzdYHpsle4iuus49TvzMtMZuY?= =?us-ascii?Q?MfrSvaZFoE4f4oFMB0pX1/mcdNdu7btxSBneNIZqNHmNvVFA4bPMDo4Cq8C/?= =?us-ascii?Q?OdeSGli/FyDkgoLBEoauMLCeOaKGnbE8nUu9oi2xweFj12R19cnrcPgbRfAB?= =?us-ascii?Q?T9GLHJ/8Gbh2h8DCbiS4IShW3F6mduMFKy84gHTdMJYtOcHo2i/GBk44vV6f?= =?us-ascii?Q?MwYFtOKwLhGC/mwpZ3xqKWFDX8rIn+hnY/V60eiXO7HFjjR8yVR6bv3vc5wp?= =?us-ascii?Q?O5IlQJGGHDVVnOUCmCFxM79XuUlo01hsG+yVwEHUBCTJv2NIo1p85Ul82DVM?= =?us-ascii?Q?3JS/hk413vHQ4wMmIs9vmlMYHkQLHtI=3D?= X-Exchange-RoutingPolicyChecked: 2K9/yUrrDwmP+mPI2UuTQITLmL1KV3A1zhiVxa16OUdzVxOr/9OjQoAlL52m/C8UQwBjto6JxLsBkDFynguyl0i2n7mhlXXHAFtjsqne1+QHnsUYpSOH69Qtxi69oYBcunI3I6MrA1QViFJkPGGhXeAaLULScw9GnCiBB1yNzMh34g7HnT4xuZWUQ3RmPortGyAGy4ofQhxMmPm3mFQ7KcXPjiffnQRfXOHa4tt+YopZL2kg9lY3J4eNPro/3XfNGi45wo9Edk/D42DUT7ksCJXhSUkVYSPC5P4CFm4pJl3idyWrP/wHFdf4nieyZYW8g+tUwuPSaQDSPnLk8tKYAA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96844c28-9ad4-4018-37fe-08df2b90de44 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:22:11.6876 (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: LvuMI4TcOTeJlGZ6HIK47l0hEBMv2k0KafEWGZIaGMhOpi7GvWAJKd3c+l0cDvC+gQhioPVSxkPDexMfsPd++Mc0eCXeFL8pDp5D5uMWPgY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9592 X-Proofpoint-ORIG-GUID: ZlJq7WZujRoX8SyiT5TdjBPyIii0Ju6W X-Proofpoint-GUID: ZlJq7WZujRoX8SyiT5TdjBPyIii0Ju6W X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX1roMPiOyHGdr O9iHYwYLy4F7IwiRCrbcCJYmmeiyI+aMzmFoDpgB3Y0c9gAIoHQ9/G8Myi/DSEewqNMWn9yjvW2 SjFA7jESMSjiaire3UQUe2tVlYUs7/fUHIFQF+QsFDjvfA28jBVcEU5xvb8rTXxtROVDYqbrBro Tlqt2vF3HuxZeCrWPWyJGm8rVNUI/1FSGLVuQngzu6PbbDxiVk8YH7WVNFSP/MJlPQQHlI5Tvqj 8lxgWGyd1R649A6ypjEfJx8iycEDgp1JgMLsWLwqEq9gnlcv9EGhlkDppzEnXT38nZ3mYFXwCoe a6BniUiEpRNMC/StsjRflaXXSkm9/Pmj1epcDOljpb/fRW4umU+IOoMDk01OKi5oMH4qtT9Eas2 k7hFD6ussMrN2IkNNXEPrXcmHr4Ga8V0C8kb1SIk+l5hMVnEhm7+WVuNXW83BrW8T6wPOYdoW7z gicH6EuJ5rasYxrbc4w== X-Authority-Analysis: v=2.4 cv=V/ToQuni c=1 sm=1 tr=0 ts=6ad23315 cx=c_pps a=N2BSJ/IBjBq6ipLGDtrT5w==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=fn9E0C1quIHmE1dKZfwA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX1bsxiAzDK1+J /G2VXPlINswXk0+wq0e/enWmDQO1yvfogtMVdu75wFHXJR1y8dm2Ul0qgIy+VIJmC3Rv5WA/FB6 FFXeRVtpOyVuTDlWHTLMN4YpTHZqVdg= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1792160537-C5146757-FC8C2BF4/0/0 X-purgate-type: clean X-purgate-size: 1704 This function is now unused and can be removed. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 644508a44e..dd255fac24 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -71,7 +71,6 @@ struct I8259CommonState { }; void i8259_common_reset(I8259CommonState *cs); -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 09b761321a..5fa38fbc5f 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, cs->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 Fri Oct 16 14:22:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:22:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452043.1666992 (Exim 4.92) (envelope-from ) id 1xHipM-0000L0-NU; Fri, 16 Oct 2026 14:22:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452043.1666992; Fri, 16 Oct 2026 14:22: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 1xHipM-0000Kr-K7; Fri, 16 Oct 2026 14:22:32 +0000 Received: by outflank-mailman (input) for mailman id 1452043; Fri, 16 Oct 2026 14:22:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHipL-0000CK-99 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:22:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHipK-00Ar0N-Lt for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:22:30 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2331c-bab6-0a2a0a5309dd-0a2a4507b77e-24 for ; Fri, 16 Oct 2026 16:22:30 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad23324-b4ea-0a2a45070019-94a39744421e-3 for ; Fri, 16 Oct 2026 16:22:30 +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 69GE5G7K3551949; Fri, 16 Oct 2026 07:22:09 -0700 Received: from bl0pr03cu003.outbound.protection.outlook.com (mail-eastusazon11022137.outbound.protection.outlook.com [52.101.53.137]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hbmjc04ym-2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:08 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by IA1PR02MB9592.namprd02.prod.outlook.com (2603:10b6:208:3f5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 14:22:07 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:22: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=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=bU5Vyd05eMr3Hu2NPbXOnfrUIiqH3TDDscLl/o0KZdhCeAEyf7U3Evdbs caNpomMWH3W3KRbDdtEqBS2R0mIe9V+n5Z1ZV00hQ8nb7TO41snecTq9AsklDNJm F9ayDGBJbvP2pc72lI5gpJGAbn4YLcfDB2a5WwUXMP/5Dv6Ht8qRzc8vPet/TPuV eQQwO+JWBnFuNJaOF1rvhS6B36X0u5AWlcuksDhdaLu0I9wuRflGblfPCsfbkPsJ hPHa89pO3Bbn3Gi4GHYHoXoHnBC9oA453y8hm0oGvl2FKT/4ft9h/AdrqVTTjJt3 IGmXte74XoQZk5fWmexEjQSRMmD3g== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xogJEyJAzhv2IVwibE+qP0EM1PhGPdmGP1nEEHDejLVFcbL8mP5/bDnOB3jqH60mPwBppJyiTHdiDvnq9qujdeUnO7qxw08l40VCQmDjm6P3NyiiJP5ftcbVuvsKNWWymGS3SOqioW1Fwp7w2M3Zzo0UXqdW4V+GlxHWXLugF/0z8Y8ZEB6lifQxuP32ldupxDwr4UcYwCOROG+3JMzdxEshXaaWky6OeYtStzY4cnDuIfxAOYu4vWS+tMmspLHmucvRlrIOFn1m5jC0bAeoFciq1cI5aRFaNAY/4NcwqQP0cYktj/jNn3jsYdAoJFjvERTG0b9/p3Wuols5v9fLTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-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=uz2dV//ik4ZEcr6WnkuNIE1Hc9E2ke2aWQXVmVRaTsHZm8Atxd4nwqBq1YlwZ6mUQAjuHI41GQj0lMz1Q+Kg+TSfyzslQ4U7FI83CxD19F/KOGsOwmbzNtl7Y3t2fENLis/s+pv9QZf5RAe5k3JUQv57zJ6K0UyY1+n3xs/+ynrgC7imJivUihdOM8sO32dDwZD1fYUPmcGUAT4aftgfZcIVYF1AAWYxDUXvwWLIsViadYiNFA/kqw7R+2a3cQwLpTJboXJlYhSSPsT21ZYrY2N4OZqlUFEEwd+KUp9u5jp6+MZ68ti9ahWAwcoD6A6PDFnIAjeCEUcwHvRafru/5A== 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=TjReIKquWeQvqpCVVHUEMk9tQhiTEZhvMVC9NsklYjg49/waw+U6Cx+Sf/w7svTTqDAknJOHroQSwY3fSqPqzToOUpoE0fyR76eMhQcfp+/vlct08Rf+Kc+YXsOEHotql6A1VmxQS9QTMDFnj2qRHxu+pNMhScD+mfmhAKa5Xg+gDPMrqk28fYZUK8m0Ho2vQyalcaO1uhxhQbkfLnbrkvB31by0KDNRMrUDFezt5MAXK0Sz08I32SdQXx9IY+KMTYU2BKfsEPnYx+0lwLdS6um04tFLiulcg0Gox8Z+pdtkDdJSmKAi/czB9RElkVFEMSpmiuVqoKSVD5lO9Z5ctA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 22/27] xen/xen-hvm.c: introduce TYPE_XEN_I8259_PIC device Date: Fri, 16 Oct 2026 15:19:28 +0100 Message-ID: <20261016142031.1204281-23-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0P220CA0010.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::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_|IA1PR02MB9592:EE_ X-MS-Office365-Filtering-Correlation-Id: 10889001-150b-43e7-a002-08df2b90dbb1 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|261009223027099003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: PkEVfLxaucb2zP1v959XIFKxe48X49VR79aG7G3NxBW2ltUani9cAL1AhaToC4Vy+SgEGLSfAtLYcLiyL0zU/bSMd6FITrWFQ87/riEK3ZrREu2iYtxMlhM2VdxASE3Cr/qpoL0SVWLgpZn2RfCHNXAEg+jsQXUpBBTDy1gAmUFx92dMuOb1G4nzrxQMvhFxyBl7qI1aL6VVMVaHjhOQMj/BK4AwpBJ1bQ6m7QfoYkU9k/a6x5ThP46hi/BTmqx+0ykMggUMEIi6w5wQfqKKaGdYx+L0L6BylhSPLiVDtr/QCNuxjB/JM6C3koMHaoaJ1rZyR92yv6orgkAhn2Idn+OIDxGv8MqTFO6Ka6P0s0NcvdbKo4XHDdoQh/tzWApLg3wHklNkEfSU6BCMLnquEACCbRloOHvrKMoVV/00V//rM8LaojEVx/plQPzJLtuHMFX/prLIx/LldurFx9xu4owIZmjlfAAsRttB2qZFU3R54E7CFn40ljnClHCcIgyr6xz8UFMojsk6Cd3lT2xnpXZU3qlze8Z9kERk97cpVC18/zYBsI7xjvL5W/rUUNP8kHs1uzp7W3YtRqEee7/wMPUfNDjpRKUutzBQ9uvd6OwHp7a6qEsAthpL5iQLkzZurqNeulWWokQNEHB5YIrIAEdIUgC+jvnQ9mHK/4iDM+Q= 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)(376014)(1800799024)(23010399003)(366016)(56012099006)(261009223027099003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ijjZV0wT+0F3kD/iYfXJzNcwpvhi4XLOJKV/zS5dOSp7gjoGUmCc5XAD5kyq?= =?us-ascii?Q?sja5VIJdc/0KS0N2PyF5foA4I3WZUAETsYc2nSBES0675oL/RG6Jxt5UNO3P?= =?us-ascii?Q?bdSDvr/gjFAIbLAe3nhoPofH/GMYMip0QmU2ePEORaiedxC3EumPRAObi6In?= =?us-ascii?Q?l5Z9yFBbddOCpi2nuLL9QGnruyLoqmZX4sZaj7K3QpKcgnQLC7S+n6PSFh+0?= =?us-ascii?Q?h8FjEC/dhQEEzVsUdJqUveZM+0OEEZ+SjmATbvf2YPA9hrG8WzQiKBt3lwVd?= =?us-ascii?Q?PegOZCtMfz4OgzZ3USReavsCfhiSCHia4aFPz/4/REaKYbtOA/ck6zukOp0B?= =?us-ascii?Q?fuuwaeTt2sWvnZiq2iYFsjdNadDf/KzHzod0R90RwW5ZUr6r1ZgTjzEAw330?= =?us-ascii?Q?9/y9Z1RJZvbWU6BDgdixQVp+WydNbcpS+tdUTiyWue+QV74qJbktFQYnpNs1?= =?us-ascii?Q?aQigsV18scR+sPzKGRtnXpu0h5vlRfv5X7Uo4MOCqiOta4xn+XNVur54h4Kw?= =?us-ascii?Q?UKBnSnztkI2IMjTJxA3d62jowecbfbIIH4WT49sZFjaeROq4a6lhfDb/4Fuc?= =?us-ascii?Q?YddQUgX+Bf5eynzZiH6BT+H5WV8k6C840ie8I24pdLWZvz6fX5JoJZHyi65J?= =?us-ascii?Q?HT9JuHqPjS36yotIstEyCeluN9MBzaQIhqDOjo8d9ZA6P5qK+LbtFPTxze3z?= =?us-ascii?Q?RL2+wL4eYDTJwGEZ6A9k0FHM1E0CKhe14dymiOoT2DLNyP6lCej6kLA+i1wK?= =?us-ascii?Q?y3IrrvPHIAfFKyGjvUmj8HOa8CWQggvQHScsXqTfKsSMJYEUMsdppjeocNWd?= =?us-ascii?Q?jGKIVY+orZjNziwkRWUwe8dqOxP8n26//iUN1JnW3N7ZcNL6gBDifvC9X+xe?= =?us-ascii?Q?vnKTs82+Dkuq4BIKtBAKhXcIHyUgZY5aPXBZKy19GUM+crr/QR1GFQ//P+kC?= =?us-ascii?Q?eHP2fGxD3VWFTcIU4mr0hactGwhukPDg0ix1Da3zi8LSYbm7BsCtUQb6f9Ot?= =?us-ascii?Q?QpCCqiQwm++ObR90LbrdfLjPNOF/XU9KRz4x1OGpzjdwVi+grZzW7Wo6MLyY?= =?us-ascii?Q?rAHw78pO5ufxHmrDu+lUTert6Ji7PMp335sQZ/3s4z182D94xjkX1gIJWdI0?= =?us-ascii?Q?8zNp6F0LNNpUalqG124WFX3fFVcQdr7TUHdmrjNz2/I8cwHcd3eOD13GZV6D?= =?us-ascii?Q?H7eCD5yDkhyqrNaooexYWrQpxa2OU/gFF5mTCSdg7betX/y0p3B0RnGWyCR9?= =?us-ascii?Q?ilpeG60/BPZyFMxb4Xbb1DiGL0MjIeFu0SeTbrQD66MnYVAoRYD7XlXtRBLo?= =?us-ascii?Q?TSfzgI8uh+eVXmDLyyEeBwyZGC7wgW4AFGbb+5gU3YpJ1tBX1mCRaPh6i/yq?= =?us-ascii?Q?9tC+V4l/D+L8Hd1o0TxJdo53qjsr7oiKV0Z/fMkiKEQKvOMPnZt1PwvupT0+?= =?us-ascii?Q?2XtvpjiXWH87du72Plpj+1eKutTKNqdNQA8vIgQNAFt/acJXW9N9mjTtnJMK?= =?us-ascii?Q?HozGSI9iX52z8912EHuvMILo9qXMKi9Pp5akf4+AkcQWq35znTsmf4t9l1YY?= =?us-ascii?Q?Rp2Hu0+32aqBiIa5A2n3aQcZBPcvvUHRkQJCqMDNDY+BYy81gHI3+f3Zxbxc?= =?us-ascii?Q?MFXjGXts3t5T4BXLB/H/ytzI5GwaVWJ1G4SJ6NbddJFuDxfuTmDvFttjjWrO?= =?us-ascii?Q?DeGEDIvfX1A8yN9BZJJ6FUoVylUvRr3BAfOkUTLDi4wnPzD8WBca1N32kdgJ?= =?us-ascii?Q?zBecfQoNUBAlufAr87n9UhrvTQm92Rw=3D?= X-Exchange-RoutingPolicyChecked: BErXZDCPp1FzU78zIdZzvW6AccKILXH6+PB6blu/JI++miUFsGymMw6tSymv84XI+8cNx/n+/h2IULaL40dXs8oFI64FsVkgPAGUKHerdZmr2fPiQNdNqbijc2c5P1q7S0GQWtunSoA6SAc5wKOQLrqpFhjRlG/j59H8P204rwcF8SUMAeMsUQydCZq0x8pgGFT75Rvo7YzrclX3G0y+TUVOk+O/fRhqWCeWPnzz9ErB1E5E6NZZW/hkbRyS0Lc1UGVocHZLZsPR/boIMDHzIjgBV4mUj+wAdoaTNhLW7yC50XZqkBHt7xwsyk6ZtnShkEnC/YhCkee0+jJA/y/qkg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10889001-150b-43e7-a002-08df2b90dbb1 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:22:07.1990 (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: pWiDnBG3xRLj/QXoBXJhdXO0w66Ceh45x8wJ+IWIZ2CQUf3+COUcVTWyyY+OAS4tE3kNWTu7GTzPgVdvq9pMu+MoP0NgOUpUfnOHNqWGzUs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9592 X-Authority-Analysis: v=2.4 cv=dasVTnXe c=1 sm=1 tr=0 ts=6ad23310 cx=c_pps a=XMkfF010lpKDMmMg3xIHFw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=tqVLSPGIGyqkaOPIRdYA:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX47XJvywn92Hn TjwBZsyJOG9namOQlbuGvDKkVNAs3V5QpMW//6T2jla9wOcEbt26QH5jNiux7C6gMLrWUNCi+WE XCXWgHGj4qI7hegQmsnfr6Rq4/EeW+IB4YidHe3NWG4AMCp36RBY97VJtB2vU42J3HxO8vdo7+8 EIpsyDPAC2Cv8KZ+8QPphS+kDn5fX/rz56sMH3Xs/90OyqbSAruDHT/nAzTzQ3TwYzM++mRbGXw TQJnO3QCPTlmjoH8gLek1OLEOguTU6xTobPKTYdokeV7YGbVvqsABUtfJvDBKSP3f4/x+qV3q5X ttJcBA+bjHLG5mZmd5HLwL8lwsz+jDh/Eqf4dF7fGYDs37l4wDV6Fwa8ZKsD8hPdsufgXqygGGG cj2tPGEYgPy9I2uy3798WMoLkExVZlqiqmtLleoY2wwT38I/DyIqD5JTHvB7ZWFDQnjffZ0p3Kr 3Jk2KKD6U802EGilKHA== X-Proofpoint-GUID: DkJIZ-r-yw6uhv4bJ7X1Ic5EhhPLUhqw X-Proofpoint-ORIG-GUID: DkJIZ-r-yw6uhv4bJ7X1Ic5EhhPLUhqw X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX/RR+ch8ahAsW P0M4q3nAJ9wYQZu1XCwr/Rx1+eONLzkEuQf0hHiud5TSEVZPyz3kE3Dr0JAK+nfUP0W0+eolY4S JF/sMkLncC6Hj3hbUx1VvRhAadJbV34= 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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1792160550-A44CBAE4-FED90873/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 Fri Oct 16 14:23:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:23:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452072.1667001 (Exim 4.92) (envelope-from ) id 1xHipr-0002EA-1F; Fri, 16 Oct 2026 14:23:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452072.1667001; Fri, 16 Oct 2026 14:23: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 1xHipq-0002Dy-T3; Fri, 16 Oct 2026 14:23:02 +0000 Received: by outflank-mailman (input) for mailman id 1452072; Fri, 16 Oct 2026 14:23:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHipp-0002Cu-N8 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:23:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHipp-006AtF-3X for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:23:01 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad23337-8faa-0a2a0a5109dd-0a2a4505b660-26 for ; Fri, 16 Oct 2026 16:23:00 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad23343-4cb1-0a2a45050019-94a39b0c2e2c-3 for ; Fri, 16 Oct 2026 16:23:00 +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 69GE58va1681992; Fri, 16 Oct 2026 07:22:56 -0700 Received: from dm5pr21cu001.outbound.protection.outlook.com (mail-centralusazon11021130.outbound.protection.outlook.com [52.101.62.130]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hberu10kd-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:56 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by IA1PR02MB9592.namprd02.prod.outlook.com (2603:10b6:208:3f5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 14:22:17 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:22: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=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=ziHP+FkR99iqwYK3tusXaSde8vh37ejRC7j5NAZW7 bU=; b=BDJpZ+D5fl2bnzCge47aa3Kd1YMsIzH1CqzfKsH97l5o04uWQmmbrA13R 0Mf8g2tcxatYv+bIqISS5ToXhvQRlyzkkrKih7xgTVGt228e1ks3ugq6QUJfG7r2 X7Htt1UUiPGL7tNfDrzy9zer5mKsTBYux6Ql1wzNsFQzuMeC1tJzpqsCUdnZq88w K8a5uGCt5hAMOLRxO14HnugvQjRh0n40UqOkjPx2NaasMqGdDuyKbBuOxcwcOsSU 07CjAA1FnzI+eixe+E/tX0KtJtp3Qtbzd9nb7DYvjmJTQ8Awc70ZtWDXplllFfDH KgEVWt2gH+BoSK+uOSSmQ1BaI6mDQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Q2Rur7h1PDySYewi74qnmCGEGY3oIY0KIuXiQigUWMiNC7JNhAqmLGtB0bv2hxswK/tQLGHH72+N0Z7k2RMPDxFoF2PoHHYXSBO6zfhJ55qjs6zNdD4KRKDLM6H+pDmknD9I0EyWkDZwOOB9VQKbQW3ga2CIfj+3Oo7h9zjKF0APmVJ3R9GUWufKz2lSdzRgVX3MCPIIUoY7v+yPLRFiCflVPBBfpk2mfg23V71iCkwXR9tZ9XxdHFg07lvIJHDWdBevStK4zlF8TxwSezQzmhkNpRq5rxx4viv3gEsnxkajSsXVWNy+0cZySJ5jwRnh53AE2HWXJ8PypZHoDxEy3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ziHP+FkR99iqwYK3tusXaSde8vh37ejRC7j5NAZW7bU=; b=WpB6iVs4Avpd+5jpIQQROMTCKzHjxGtkTYT8yI8o9yCEnDVgk6TpMJlCDu7LophTU1X8Mwq8YtC92dQc4oCl1trxNhBmSkwEze9aG8FKuoZh47xenZ/RqHGrTQ57qlB6KwkjBJ0QV63s5JJJ5alnJe6GPPflDa+UIrT0wIvp+VGaeLsNkAbH4tkiZYmMK+yrUH3XrAYmCQ3jI+HUDUtef6hsCAbLazlKLnfCNeCpKPuoX1RLRSpH2tCzjj1NlvHh5LNtz4XmXezRjI+RLaT288jBwqREtazj5yQONT419f5pVLjZ1QgL1W1pf0KSfo5AUW1uylNlqsBYaWdSQeirkQ== 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=ziHP+FkR99iqwYK3tusXaSde8vh37ejRC7j5NAZW7bU=; b=BR9T0uSbhJl3b67zhBEpFsQqhAC96UlwOWQtNoTOJFyt/poYWP0YHXbN9SX6rqEQ1/OPK+Z/Wd4YXVwhFL5oUjrmN/VPLSBvSUD3MShvPLDFY0ARi5vItnuu3uQIFBifxj8Wdkq/KVFQLtdhR7bORfpJYs7Bo10pMyJZO/lGkMf6GSt9c9/fRjkuzUxxYNpGOsZaYCx2dxRnDbiBSy8zqxDLTtuJwwxqVpyo/2k/r3K6uRovF0vJbP8NLeUS5/pJetrlUD5kdLVlKHpwEI0Rvnvn3ILYyNADsQPRWXcPpUMi6/zogQdzsLIsdQUAjxX4N9Glv5OgWdDu8zjnlQwaFg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 24/27] i8259: move InterruptStatsProviderClass get_statistics() from i8259 to PIC Date: Fri, 16 Oct 2026 15:19:30 +0100 Message-ID: <20261016142031.1204281-25-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY1P220CA0023.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::11) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|IA1PR02MB9592:EE_ X-MS-Office365-Filtering-Correlation-Id: b9799841-b194-49b9-1fbf-08df2b90e172 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|261009223027099003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: FTTeuAPqd5r9QrqgjwLPY4mU12Lzl2aiSSKnvQFxGAf+5PYcOfiCG0Eljkgn/q3NsosIqgrDf1BJw4DRho38E+OBM3Kc3CkPZ2vsSA6eUD6ZsytOa5aOOqirYQqgpiBvNLNGishjV63rCE+xPVVAhGBY/Bb5LqYeSD0f14zu3tQ92R3xADzN7bFrcZBFuVin6SxpqrdlckAo+9MEL1DHKo07Psu7+cCNSjrXJDQnhP00r3x+iIY3sKB23hUs95R7MWpORmpamOUEhSX0mH9tiGzIkNyQLRvP1VIKf6DysI0cTrkvCw0fGwihRGhKzVe6uV6FfZcgCTpmyacQfI83az/WLCDVf1qpnZLm4TBXFLywfqzym5Hw/JnC5y19qzRk40chxpDj8F+/6anPzRufElhduxuZPgSormDJo8XUvebVItt7SrcmaMTiKLgqvwHZ2D1Yezz5TsxCKjydXV+sQRbVvKth4g4hFpgQJzAu4Rhsc3lCDDf5E+kP3dBGbnyoyQnBntR7bCPWP01PXFnaegYAATuxm7EhImBCTm4Z0bBSr8FDqcQlkjoH+ymN1w5Zxtanebs2U/vXXDufT4it8JbuBKwuKFVVby5uPSNg9NLaZOHCxcPGVrs9YY60ATUqELRe+ZrjrjePbnb9VXo2suHZgmrQfTxalAlWBNBAv6k= 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)(376014)(1800799024)(23010399003)(366016)(56012099006)(261009223027099003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?C12UZidlEpEulCwXgv9ijkwPRRDqJOFaHppr0MORGZwmts7fLUKrTpTJzgmA?= =?us-ascii?Q?ot7Vb6ig6KJvWlbUf74udwe2H5AAmSwzEQRu3ZnHE0wry4nSOGqmqvzP9ymw?= =?us-ascii?Q?rfzFIbR1PAtctE70NTZ+b0KL8MBHfPmTQMAnGVq2lrj+7NHDV4xkStPZ7jtP?= =?us-ascii?Q?VoQGWlOSjbRhd+CYzJ1Hro/kb10q/LW88nrJdUNgaEsji9oFfXJ+v33VY3kZ?= =?us-ascii?Q?Ww69xKunOFw4V1HA7Iak/WaybSfvZdSdDvjUUDRjOIOepvDh3PQvxYh4w0lD?= =?us-ascii?Q?wj67orIkCZaBqOuQtnPJNZxHHL7sqhg/Y8O/sqHuyhZHU8lCIbdeb23QgMGJ?= =?us-ascii?Q?QqdZkhdmASkfCZEJHCi/TjIK0WFtnR/YfKtGXjzZa9wFXe0y4gEKMrACr22F?= =?us-ascii?Q?UduiD+zNpGUAM4sZgf3K0P7G8zzgZz6K6Np31My9ZW1qql+X1Z7fZ6O//nvg?= =?us-ascii?Q?0/6cvxS+ygvOign4+agu7uLpU/2DhHscXICclEJxiNXMTwvl/VDg1J431zbp?= =?us-ascii?Q?0q7ctcOW/nC55022c0LWeoLEYyhGRF18dynuj6MkWIo2TjS0rE00/ytlI1Wk?= =?us-ascii?Q?HS/UxDrnFrKhvgl9E/kdfu6lT3209h0b9EP4p/jLgamby4db79H3s4IoGq52?= =?us-ascii?Q?iKq8hYGUar/tEGWh/wO3epS89NuqVcIJRhj3nSBC0aRN8gou1d1TbQKpJU4B?= =?us-ascii?Q?mv4Xr3UnYzkCw8RYC58GgnsXSOXnJ5pyT24UGor4iPs++SXGQES+pI0F9lHE?= =?us-ascii?Q?XpC1CRDEC36rzbZa53uWfsQKYVsP13pCrg2UWuVOa4PsyN5ZO92Hw48hDlC0?= =?us-ascii?Q?e/C9V5Z/xIs3uejvMevmUC9Wq68+JPWB5Qf5tT5pZJHUq65sDPcbOuvA/SSg?= =?us-ascii?Q?1eHLeR0BxwGQ5lNkLx6ezI5uF6vdjMLudhH3L5FPJSOcxGNAGXSbGGbvqlRg?= =?us-ascii?Q?f/MYt4aqwElWkG1Tsxp4C37rGsUy4EnYHItzvAzK/DMtYmD8NWN7E18EHUM9?= =?us-ascii?Q?2fot5GZUqV8VbXag9WmYvxjqtqskKORMqtyoo+pExsI9iy1uB8KHfbxSKofz?= =?us-ascii?Q?k82pCVLBHPddjWdZTl5aIMBGFohXIZI09skWVxw0DST+xHlTULAyBje162mt?= =?us-ascii?Q?+Ie6pOcN/jZpLqhpgaPDD65A9tV7WobWtqOaf1zZGncwyIwKWTMo5idQfsC6?= =?us-ascii?Q?zHBPg3H63m2luYl1n8g4+tCYTlTbvJbZpCnXimR8gI6+grUhPDnysa4AtrNK?= =?us-ascii?Q?ndNfj9wAP0Aa2GfPF5/EEA8dN5XMBwgNb3Qw+GyWc+UiYsYozgaTx6rerBw3?= =?us-ascii?Q?IhHpQ+Fd4nzcxOaypjyL2buoaj7Wjer1TKxkZs0PE+sMvF0O0V1WmsO/fbFj?= =?us-ascii?Q?jNYq3wKvNWKsfXHZQN0A3p5H2ZfmY6t+deTN1el3sFghiIVAnbC1sZcDIO4I?= =?us-ascii?Q?Qh6tz9DXubruqr1/5Mxw27EkxKYXwofZztxbFTiaLLoj3HZCjTAlKASApRho?= =?us-ascii?Q?MhgStw4+wd3tm/WlIiu2aR8oCTFrCCZh/5IbxtwcYFfa5/ID/RKGE0M91D/s?= =?us-ascii?Q?yaquWwjYMp29isQJP/mRzM62Y+J6OU1BfzEjG0u6/t2l6xfR8640yuy3qyvf?= =?us-ascii?Q?QVH3RzRtkKwRV4b7HKU/Ljvlp1tvlQiXAasRUSU4y/jO2octB8yA5kPuM3pY?= =?us-ascii?Q?ayOkKwUHLl11Gf7yNFWFUD9mY/vmsE7DioU5SeSspeFd43Jk6FBcZXbFyEY2?= =?us-ascii?Q?9P8hte6JMNoCr3rPciNzmOd0FhDTUvg=3D?= X-Exchange-RoutingPolicyChecked: mf7gKKFnmPmPWbzvFh52vIJALLCO/UHqWtdDMQAgNpEE9JABVV7jS9k1hGym6+NJRSMcPg1a5S7IoKpxRlly6KABcvcSoHdoGGeQg/y8q+yRSuJKxP91O20EoNc0NXUGSPw3y80WZhiZUNQajUhtL6r8p7IiiCMJcLYv619qSC4dPQKbs221IvTSxqTKwrleZOORvfe4vkTkiDOgLYvPe9UuXNi0TeBjsLWkPDH4Tmso0sFookAA97ptgkS+PWRWF3ls71nz5A3e90q/qCIhYxoQD4wJ0l18yhSoPRIBTvhcLjrtp78LwhpY2oxg6+UeUWemHnR6cfkqUm0bty4hmQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9799841-b194-49b9-1fbf-08df2b90e172 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:22:16.9635 (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: ieLJutlzFNfRUzut5ESdIcaQVqcqj3CFiJuI8Uy4cLVEwojcIrOfl/RCB3FoZLAePyyKdBnce5R4VyaoKt2LlBL9R+YhkTOlvzetyKWUgUQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9592 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX2981SBWjMKmu DIwJiERFGBNgOVJ/VkVUSwBB9h1D1eRv6Fah2NVAb+hsvikY4ovGahiYG/rDgREefRMjn6Hxlgm Hx1DqrSvKXVM6sVKFvOmNS6kKU1L6/OhEuwaXawsyT+rcLN8uB1pJCK0Hkk577x8UeTBfpwnRdC zc2FUJzBjs3OaldpUsLAKwy0ywvZZXsj2udfAsTT2uX61NLGCCy/GHOMXa7TQIJAKmZ45nDSK6M FabVNubmS3i87Muxo/eSG+p+Luq9icggtj8NDyt+LsOHmq3KVB0CryYW8WUdzY1E4oKrib8gmEf V3ebcPZ1PkzZNyUqy9MzVwXspCMHAXUj1RB1ZDkjHh8I2So5gJWPIwGX+h4gyQqmxpbtTEEhojV jCnZLcoqY4nteOvihhsVbntuclRcVBEiPGzmJaiq0DoWaO/7ok9wqKVchscvuCaMdSN2FbhhFyS XGBZevq8oK0QWeUIe/Q== X-Proofpoint-GUID: VXFWM2bAgemZzatva8USUijwobgDTMul X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX0f8IOizkHlZS 5qYHu6El3erG2hD/ldQNGVud2ZntCoM0jC9TngVQ/DkNhGdpY1A9NJeFjksMYcbQqc+/Evm9tn5 8u20PWtne1PpKpOz4/NHXcjXltLX4JM= X-Proofpoint-ORIG-GUID: VXFWM2bAgemZzatva8USUijwobgDTMul X-Authority-Analysis: v=2.4 cv=KMLPn1Fo c=1 sm=1 tr=0 ts=6ad23340 cx=c_pps a=7kgNGXaSmB15KJ6u7rEBag==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=A7cMN0_0mIGH7w_oRUwA:9 a=cvBusfyB2V15izCimMoJ: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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c201ff/1792160580-F5CA82A1-FEFAA82D/0/0 X-purgate-type: clean X-purgate-size: 5964 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 Reviewed-by: Peter Maydell --- 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 87ccd55a4d..d51a7fde32 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 I8259State I8259State; @@ -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(I8259State *s); int pic_read_irq(I8259State *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 dd255fac24..2807409eff 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 c51738dd44..b56e4fced4 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -223,9 +223,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 */ @@ -246,6 +249,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 5f90edbe60..842507f9f8 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -535,9 +535,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 */ @@ -558,6 +561,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 5fa38fbc5f..684290fb2d 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 *cs = I8259_COMMON(obj); - - if (cs->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 Fri Oct 16 14:23:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:23:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452073.1667007 (Exim 4.92) (envelope-from ) id 1xHipr-0002Hv-AY; Fri, 16 Oct 2026 14:23:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452073.1667007; Fri, 16 Oct 2026 14:23: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 1xHipr-0002FE-46; Fri, 16 Oct 2026 14:23:03 +0000 Received: by outflank-mailman (input) for mailman id 1452073; Fri, 16 Oct 2026 14:23:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHipq-0002DD-1c for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:23:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHipp-001AqU-Ej for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:23:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad23343-8faa-0a2a0a5109dd-0a2a4504970e-6 for ; Fri, 16 Oct 2026 16:23:01 +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 6ad23344-b57f-0a2a45040019-94a39b0cae00-3 for ; Fri, 16 Oct 2026 16:23:01 +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 69GE58vb1681992; Fri, 16 Oct 2026 07:22:57 -0700 Received: from dm5pr21cu001.outbound.protection.outlook.com (mail-centralusazon11021130.outbound.protection.outlook.com [52.101.62.130]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hberu10kd-2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:56 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by IA1PR02MB9592.namprd02.prod.outlook.com (2603:10b6:208:3f5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 14:22: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%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14: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=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=jAxNlriqZfbJNNZh+y/GFC7hgEb92Xvhe6az2crKp S0=; b=ZnUCfq5+A2Iq4n1KdTCb2rO/6hcXxvWJgoTuC3RQFuPOLMtUSSF3NDKFa qb2PM+l0wABic5Mv4xnN9FTsFLG4a9teuW9SIcKeisU4zdADEsXaiT2mUELLlqCI gNJ2zAA32tRhZcKyXB40LPqOtnU3S4U0cViKRqxZgoUQ6uIY51IArJ9CBAD2FX1v 36eYzuLna3R9JF+028TzIjjbK5ZPolRFefc6l+UEUbSTO0fQXoxTwBzMYqH/nFGO ILboWvDQc3wPzkusueuaQAHHa0uXIox20kP9KynJ6lg2qKYf4qFYCG7o5+5qQG7p D9a4gvQiQbQyhqrz61ZEoODcHWuGw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iKSUcP18zu/1uGyjB9EKXuVoZ2ybVXS+Mnh9rDoSFyeZNsJ3yJvELHbWgF51IHntKXmMmW4l6H7goAL7w0QldzBKbwdbWXzKPLg8LaiePrtFz+BNnnNxhrnO+PF/4lKbk+kvJcNdCMVamoXSFmZ4N56IIsLyVMRdkXbpBOeuMcuK5N3kgj9Ed0OaghpjAsV0mGGSX0O6tbbAutyOqxRY3190Jtnrmmr28Lc015TnXTmpMD3NecUASQCCtyFuLpvjEZF7lx2ZWmMON3qs8UbEQiDu45YCGRxF/g7yYO0N/y4/WfzUe+n7gNysifKDchzE9S7ZWp7dLH7NKucbBtxFSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jAxNlriqZfbJNNZh+y/GFC7hgEb92Xvhe6az2crKpS0=; b=t4sP95qA/MXB9AmHP66jy/q0trOYclSaTn8YeCZ9BdoxoWMC2KV/z2NAxzqX74RnZshKhWNUO2xACVibvCqtU5Qbr2UXCiKn3vG8AhGfkrqQsLAOwZ+onUFRdGXuHJHWrScSwWKUqxWHV1sW8RDVmQh8owZSJtk7xojEuOxuZ40EGY5OqV7JY68SUH9BqGuUeqfntJVzlwVi5z/rboEcYcFkH6+oWArD/WLu1onTIS6lklY62nm06gdf4GY+P/TI39vsV7wc3JrOgo+j8T44dDFS0nOPytWX3noqtRUzuutd6w6TfvBR0THzXqiUT+KLj6lh0sVLW7P/IZwA6j72xA== 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=jAxNlriqZfbJNNZh+y/GFC7hgEb92Xvhe6az2crKpS0=; b=Xs6djbaPq4b430cIxciznJ9mkcsBy1bcpvFF8fekM2a/CktKADtBRFMXb/n3BqfUYYqIe5yipVuiCBdWrRMiNjt9gbmdfMtSqI2zaXIM1qzskxOkVNNv34QYAZFN8+/rDDJk6f/q5jLOpoiXf0R1FxLFw3ohZUCaJg4VGeNU/uYDyBzGs0PtDj/eRRWbl2j5FHca1Mu07NWtlaQM95xXZSTC2ER/c1xaGvWyQXXEiCZVRO+COW66bm2LL7MDrASLT4/SRXMpdE4DXmgW7iCC1lfq2r/dZzvuvDcJR+2vgE+ITL9V8RZQi8kpdE0rRYAjX1ieztz2ZDwsLPuVc/j6TQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 25/27] i8259.c: switch isa_pic from I8259State to I8259PICState Date: Fri, 16 Oct 2026 15:19:31 +0100 Message-ID: <20261016142031.1204281-26-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR04CA0021.namprd04.prod.outlook.com (2603:10b6:a03:217::26) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|IA1PR02MB9592:EE_ X-MS-Office365-Filtering-Correlation-Id: 8507fdd8-39eb-45af-25d8-08df2b90e3da x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|261009223027099003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: HA2YL7ronoArge5V8opli96wjP/ydTmWh3Pgzl89+DW+zbPYFMPh+7FKyRrsUD6HOLHRCi2GyksEL3kD5cVFG/7UDtT8sXHUJKb0Dh8xuybAXIUE0iBm4nWjQBR41hCZOkiw4AN6293dIeGHNiAP/IARitV6utsg986S23+FckICqKV1+ear7jQs7amm+qvHa11VkkacfHftB0WnkFJAqhKTQwbOnKR8T+ZGZn0sjAAb3YfXu7mjmt3FHVhJlwI9MM1xmStjNbCCwagH8bXx66dXQvUzxfOviS7VmCd6d0CAuTraGjC29gVUkZ2oVzhN5TaWM5VeqtRc6M0HsDk0euMXjGucwWIh48yxRNIkBH9kaKo5gEw5NyKi4hR+FIgis/zzZudhIDC3J9PQvhHbvZYpwrBA/isXzjlzR/9Xb3wtBdcOKojBsGBojB+tuLof281Pc+gFaej9YpijnIh/asy3PqkbQY1V+q4ry2oQkQq7aQlFWNCGxH5v6x/wTOtHlUEDq6VAQ5rw+/KEbrnDjcRKQskeegCbijXYHmzOvGsu2TTTPBzSy9YlPtSA37JoegQW1uZDxPAox0dZ/77zEHgtEkUV6Sf6cjWfiJfQeFHVw3hUNdMSKdZXp65JsfYrLY4gTmgt+9vKiW+e/FBZ6qOLorTXtXwBz3woxogL7yw= 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)(376014)(1800799024)(23010399003)(366016)(56012099006)(261009223027099003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+jm7+nK+wXs2sRRra+e7vT3OGXJKkB7WpayiL0I8uIQ4exuEIJaKbTjZFPe1?= =?us-ascii?Q?WhJQNSOjjs/luUxCWTlRcvIQ/R+EZUTD7cqSJGlZ+JzNCW6CnWNBo3wd/Cn/?= =?us-ascii?Q?ruTh9Xq5pHkYMil2B96OJprSnafwHCKkmjCk5Dz25cvfQTvo8DtAziBGMn4e?= =?us-ascii?Q?It/He7KVB7P/P/pRrZ+cm/aZVvIzixksQpQ+2yubPDOPcjJAseZRNS3K76S9?= =?us-ascii?Q?jCiNovvYMoZiVYI9UT/OAHGHTq4tkaf8/27F93FWpHZgq7tk+1bhzz6pz+g5?= =?us-ascii?Q?tgTCWsg8465v22HmQzjDYYJZguRfsg2BAJpEfZnVV08hqNt1a9tHI7BDu0Yc?= =?us-ascii?Q?M5jAmODoPa7OLCNj7jreghrb/sJQe/L0aIzh7puFHqJNWgbev2moAj0fuoz9?= =?us-ascii?Q?oE7Up63L4KQicuOM/9G0n7sTwZUNnDYWfzIbqxNyI6ah2JJPZyrdjmGI15tu?= =?us-ascii?Q?ORSeC+lcuN00n9lxwYmxdUqUDJtAM9YQ8zYj2VbJpZLKmbJ+7kUd/M7OwjLE?= =?us-ascii?Q?1e6C3nk/de2PoNOEIrrtUvjf/GrBs2Q5mKjpnrbH2TGE6u8dnga7bmBdEpSL?= =?us-ascii?Q?nfTfnlwr9x9yK17jVEiLu6OgApwse4T3zz4yTVYFDWBEh27/nIjhjj+rO2Lz?= =?us-ascii?Q?iysDOMWFTCYKf8Xb876tWHZv5AMK/u22m74rLwjEo0+C/5oG5sGoLceXc0tv?= =?us-ascii?Q?f1iCfDvmLtquXDA9KKv1jB3YTLoMkJECGDaXVZDLbYGjN/GeXuFbr9DElLnz?= =?us-ascii?Q?zwu8t56PyAHH+C0v72Y8Uy7hIxZyxMuzet+93jLCWlhkldo2t3sFvfqPxAbk?= =?us-ascii?Q?/55uHUQ3+iwZBaM2H7IoGboQFmBbcKbdrjMUu4mZb5n4oLZ1HqzKyBZtXuLW?= =?us-ascii?Q?qHRgTmPBKuRCWD0Sl2CLQvx6twgD/5hkbjz4SUec9OgWzx4Y4es1dI49jGOv?= =?us-ascii?Q?Y1QjuLmkYd7OgroSmWZQQhlB6e8XSu+DaQYOTjKSNs9RkraDtzng447K3V+I?= =?us-ascii?Q?Qo2FeTvbVHEWgKuk1w2BoeCLqWFNoJipFcNtnHwfqwLwkjlncDzeQEJ9mDbv?= =?us-ascii?Q?7M+cIqVtOX1PpxAwq3E6U2NSwUOwPK4CeFVamdPh4MvW9UjAsnzq+pF2Aw2y?= =?us-ascii?Q?HGj1OREj/x0JuWXI2Sv95QdzfV0XvCXo0blMRNUf2FXvCPZvY1gjBLQYUsia?= =?us-ascii?Q?wfsV0t/PPsqY/6mc7iB+soMgEv+mauk82DNPkjg27Wr+AZkfKC1GnFzWk0kC?= =?us-ascii?Q?7LRKdB/bOl2cAFS2CrzKu3B7HzXWAixLE8p54rtRhP+Whzx+HNv6YTJuvGuO?= =?us-ascii?Q?DMpeZwx8P2hOA/7HsoDCyGR8IX0HdbG1yFdjDbx67/yaB/Pp6EfRunW5pj3B?= =?us-ascii?Q?Y8X0iQvuDcfhS8SdRBBSbhE6Dd85nusw/AmOR9GxWwLfN80fadv8p+HvzK9A?= =?us-ascii?Q?UAqDH5iv66eYMQLsPyr4z8n7H0PxOxcEdoCN21MsELXseT9hqoeuwC9gUzHU?= =?us-ascii?Q?MIust7z9eEOP5snOvi2FzUPdqp1ce7GQkwfmaDCHBcUELO2Ze12C/5q7vkF3?= =?us-ascii?Q?asz+KxszXW0y7PKZ68QVsmwCK2IFCMpKmoQkqsvpa0diLgN7260ya9Q4oIW4?= =?us-ascii?Q?j7iFOW+9UydEQGCblrydigpugi5pxT1mW4wH2VkaoM0OM7GP5TAvGJ4eU60Z?= =?us-ascii?Q?Gi6b+cZe8Cga91hA2CATac23XtjFseEMRKDuYwpuJ6VO/4HHxITbT+e4wusk?= =?us-ascii?Q?xUL0GIWWJZIUbDWMG8z9EtsEyJjEOPM=3D?= X-Exchange-RoutingPolicyChecked: zplCb1zP+VSYxU+vOXUkf4ksEwgjwMb3uf90fRFCMxRbeKMGaJRp8/gWMNv4anNfZV806rgSDNx3mgmEdE+oNMfsvBT+0Njj8xtAKaRGjKTlM5YIUfJdMlvaWJi+QgzAGxgOyJZAQbaUF78GQ2ZEp2PddCEhTQ74pOEeOhwSI5aoAwxl9PT8397D93dA3glL7PNVnQN9xnRHQrjNi+vLy0pDON2P/OvcilFXr0iq3rurTeqEXXIVrgUMz/IMYCMX/AmjfbM9a3xDfith1IP4a0xNDludgitA8YY+lzOeafvSBvTEEceeFAYDhNQ/f4O2nW/8FVzEIBJgzdYd6lPtWw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8507fdd8-39eb-45af-25d8-08df2b90e3da X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:22:21.1185 (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: 125Qq7YV8ktJ9cm9iMm5PZCfdBsuJQDxii9lAXEqq1Jn5yqDGvBAPIJtV9RK9dwc9A/mCnaG4Wvy2eGrNc6+kGTQls8vgquLojS9zTvqGKs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9592 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX7EF6kXHjhQAu +8jaIHFOl+WsvQn9Orb5l0HJc0zQ5oHS646VaDAn/nFJopzOGsEn8ZgnP13xNB3tIJzc/5rz4xL kjueZlIQ/MKnz/mM5h0nm2MzlYIuix034oIzPMRLEAM4Z4/hJBip3cV4jO+WIwuKiy7RfsAu37n mEEt2OnqK3e4nPRPa81XEALsOheMKcJtJIxfmdZ5EyK09/7GmUczE5wgSrHANMBIqUjRuAUOeNU fkqReeG0IpsQdx1pLHGPhAvYzut4np89/GJ13oo3m0WKz0MXkT19EYINZu46LK5XFGg8lnqMQxx jFevMsxAQIi8He5VQ6oPXzMGEIsg4P7yVp7u0XaOqKbQQMTmnyPWxrUupcDo5vyP00GO7MZV3p7 rvgSPbSBKovcYEvtiEZsU9khhxKx8g5xlId//Q7UC8UTmqCBa2PJBI5wDTu9zwrTpwTCmenGuql NB8OI5igpXJ4/kAxzpQ== X-Proofpoint-GUID: vRTbztpDPxhynNLAonNftkGjlZ0Hv4Yk X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX/Mn5Jy+mzL75 OeE/ldX0ZM2GmQOFTsapE6TaJjeT4xRQsiEfwUBtHROD4ggthYadkqclClnPpSiMG8QPPvQVs+G 9s8syAusa1NIiTBfKk7KJIxPWXLswLw= X-Proofpoint-ORIG-GUID: vRTbztpDPxhynNLAonNftkGjlZ0Hv4Yk X-Authority-Analysis: v=2.4 cv=KMLPn1Fo c=1 sm=1 tr=0 ts=6ad23340 cx=c_pps a=7kgNGXaSmB15KJ6u7rEBag==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=Re7Oh-p8VE-n4k5LXTMA:9 a=cvBusfyB2V15izCimMoJ: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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792160581-C2CCFB50-DF39ADE5/0/0 X-purgate-type: clean X-purgate-size: 4546 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 I8259State 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 Reviewed-by: Peter Maydell --- include/hw/intc/i8259.h | 8 ++++---- hw/intc/i8259.c | 34 +++++++++++++++------------------- 2 files changed, 19 insertions(+), 23 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index d51a7fde32..4922f88d5b 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -5,9 +5,9 @@ /* i8259.c */ -typedef struct I8259State I8259State; +typedef struct I8259PICState I8259PICState; -extern I8259State *isa_pic; +extern I8259PICState *isa_pic; /* * i8259_init() @@ -18,8 +18,8 @@ extern I8259State *isa_pic; */ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in); qemu_irq *kvm_i8259_init(ISABus *bus); -int pic_get_output(I8259State *s); -int pic_read_irq(I8259State *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 842507f9f8..7c9ce2315a 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -72,8 +72,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(I8259PICState, I8259_PIC) #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif -I8259State *isa_pic; -static I8259CommonState *slave_pic; +I8259PICState *isa_pic; /* return the highest priority found in mask (highest = smallest number). Return 8 if no irq */ @@ -190,34 +189,35 @@ static void i8259_intack(I8259CommonState *cs, int irq) i8259_update_irq(cs); } -int pic_read_irq(I8259State *s) +int pic_read_irq(I8259PICState *s) { - I8259CommonState *cs = I8259_COMMON(s); + I8259CommonState *pcs = I8259_COMMON(&s->i8259[0]); + I8259CommonState *scs = I8259_COMMON(&s->i8259[1]); int irq, intno; - irq = i8259_get_irq(cs); + irq = i8259_get_irq(pcs); if (irq >= 0) { int irq2; if (irq == 2) { - irq2 = i8259_get_irq(slave_pic); + irq2 = i8259_get_irq(scs); if (irq2 >= 0) { - i8259_intack(slave_pic, irq2); + i8259_intack(scs, irq2); } else { /* spurious IRQ on slave controller */ irq2 = 7; } - intno = slave_pic->irq_base + irq2; - i8259_intack(cs, irq); + intno = scs->irq_base + irq2; + i8259_intack(pcs, irq); irq = irq2 + 8; } else { - intno = cs->irq_base + irq; - i8259_intack(cs, irq); + intno = pcs->irq_base + irq; + i8259_intack(pcs, irq); } } else { /* spurious IRQ on host controller */ irq = 7; - intno = cs->irq_base + irq; + intno = pcs->irq_base + irq; } #ifdef DEBUG_IRQ_LATENCY @@ -369,9 +369,9 @@ static uint64_t i8259_base_ioport_read(void *opaque, hwaddr addr, return ret; } -int pic_get_output(I8259State *s) +int pic_get_output(I8259PICState *s) { - I8259CommonState *cs = I8259_COMMON(s); + I8259CommonState *cs = I8259_COMMON(&s->i8259[0]); return (i8259_get_irq(cs) >= 0); } @@ -428,7 +428,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); @@ -442,10 +441,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(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 Fri Oct 16 14:23:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:23:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452074.1667019 (Exim 4.92) (envelope-from ) id 1xHips-0002ho-In; Fri, 16 Oct 2026 14:23:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452074.1667019; Fri, 16 Oct 2026 14:23: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 1xHips-0002gh-Eq; Fri, 16 Oct 2026 14:23:04 +0000 Received: by outflank-mailman (input) for mailman id 1452074; Fri, 16 Oct 2026 14:23:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHipq-0002Dj-Oj for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:23:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHipq-001AqU-5H for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:23:02 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad23343-8faa-0a2a0a5109dd-0a2a4504970e-8 for ; Fri, 16 Oct 2026 16:23:02 +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 6ad23344-b57f-0a2a45040019-94a39b0c3e22-3 for ; Fri, 16 Oct 2026 16:23:01 +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 69GE58vd1681992; Fri, 16 Oct 2026 07:22:57 -0700 Received: from dm5pr21cu001.outbound.protection.outlook.com (mail-centralusazon11021130.outbound.protection.outlook.com [52.101.62.130]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hberu10kd-4 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:57 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by IA1PR02MB9592.namprd02.prod.outlook.com (2603:10b6:208:3f5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 14:22:29 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:22: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=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=SZiLewJ31Wd7JJfgU0jxATyKUq9AnyFgswSLPaZDy F0=; b=XAtNRB/9LSRLQ03Evxm/7s0T6/VsRJo6Xx3cbP+NLbFo08mklCBriInnO /lfqsNeYQnmHZQcve4Hs1b7Fn+d9x+/v2qoTmTUCxlQ44J4PAiJbPcCveQNXtVXA XAil/ZGye+7QwwhqO5LcNpTkBZBC4KhSYsVsXCGI8LSYTND2hLG80DbVIpSSZWmO kI3CvWG4dh+LhakNiXaRUPzhF0/Dl4K3oNq9W/JotyuktMlCn6FBD43641JJREjG IsX/zBbIVM/73riqjkEac+jnpm6XOW9u2A4CPEWjphwjJrdsEh9HZfWyGclgowl8 XZB0Aq8Xzp6VDoKDt7lCMOwv8y+CA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KDmQFU+jWLuGzDPNr5gN9ie3gVpdRgnyRHRuF+4UNXkN+IP5OSHmFR+5fTYafYio8JI69JEMq3FRDvXETKwRA+r8E7bN5YCVzbATbebQSW257CTmeAtW67wHm3p/kx7EJy5ol1JlVo/Fr21/DsWsKGfvvOYLk11xzejVHbHpI7MuJ7PmcYaaOED1HkBWMK+7kr45NnTRHRMsf0A3clHjXduUaRtfC4MYn9Rt78MA/UmT1S4cCPm2n0sj4LGhRHK7kcjOk37w1rxSxb8t9+zKtvugvC0GZ4JT6doF5xyfKvbF6CwQtneYM+2KAhoHFCP3jwr2619YEdn77AWaaJWzYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SZiLewJ31Wd7JJfgU0jxATyKUq9AnyFgswSLPaZDyF0=; b=o36nG7aSfMKv3U0ayxnLRCurwYs3C1OgVmZv5MUoZ04PilzzQAzxZa56/dHdRtbI2AOPUgvvGDbzbtcKDEylakQfvTONaU/tc3DkSqz10x0j1vYzzp7Fmg45lztBnbKUFaf9wg3P1760zpZ6F/AdJa+UGICnYonE18nFHPRdN+kih/6o1LS/Aw2L1TpzhkOjSC8VsL/MFiJ3QpCSDOkH404jwCiDsenGc6BPjgwEUW6REdhaOVsZvzLjwLdybmWbLh7duCwa83d5Qh2rxY8eF8xRgQaOQqrLOdoUjiPoV650OKreg+aWT13DbazxjB9jWNEuX08onmZRqKOgZNPZXA== 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=SZiLewJ31Wd7JJfgU0jxATyKUq9AnyFgswSLPaZDyF0=; b=VoibuK915YUUpdymE5LbUi3QQtpUMzJayNz93x8fpaui2J457C8XvP3j5DDu8fc4H8s90tkhZbbPHTq2L/UE5N6mmj7zV7GIrgikuwvHG6MuJd0Y4l2dPMxfKgiu3ZgnA30IConpGLUMV2ofE4E0ZgMR87FQtyfyVTpXNYUKaxvra3M7ptTHJW5ijSA5fPvZMaXdZLKUf5vqF0eoiDha5O2kCnAyIJv6anV++LWuhJarxHc9S381etHyp3YXiD4Ec0L+YhUbbVCtATpsI0wTxGgSqV5fPGi/gbyshhOswDYVLnCN+kRjVkEt7iXzvvNuNme2JIqMCxcFw3znFfoiaw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 27/27] i8259_common.c: add missing 0x prefixes to "info pic" output Date: Fri, 16 Oct 2026 15:19:33 +0100 Message-ID: <20261016142031.1204281-28-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-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_|IA1PR02MB9592:EE_ X-MS-Office365-Filtering-Correlation-Id: 6da20008-61b1-4057-26ab-08df2b90e8ec x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|261009223027099003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: FIXPZHn6f3jc0f0EDgqQ5Fx9lhzvlYuJavuykZrk/DJJt8fOUwijRpXVrvd3p/y4TGT7s84MGF7wJrN699RoTzipG8ZQvFSeelkqixINSnK9Oby+i0LRKWFXo8TJ4fm6UtJ86B2kPj0flW7c+LyvyUoUOaABh9Od1MkcZiXIFNIehJAixdyDxG2JEIWAUGluVweXMgO9akHOZpCiyS7uyRCNoGg6f3APWUKfJfLCKJsIlioDEjq6XtXH60YQBmgmU4q02xm7g1EMlstwpN7EgOJDBvPon6bUNELeCKTzlodxxKntxyIC6pFNOw/LCo9eTijHhg5kq0+IzpOVF9L8rD7GEvrpJj7w4woJi24TiC6i+fb+bPIWFfdf9//1ukXEhOPFBY6xHnnlQlQ3CYAjiMM10Iqtbx66HCujLjwxu6G9wLvJ5vqjXc1gbS4pNf9bKGwN7RHq0cJVBsFyq1DCSmejqo5QfDaTX24av+GrbfnEMKdtGp+bURLvCKlZPNdi0eJTErvamRLFZZeqeFIMB6pydlX4Q86ik0BE+9H6qWU2oW1MUEVmI6Z9P65morTY4iSVVHF5oey3RSZ7w8dOxBaf3MMvFOC9yAifGktbL4rlO96zJ2k/4GzuC9kuXERa5vGo+e287UgACyFhuwaerlVxn1k27kuxmr9jK33e4RY= 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)(376014)(1800799024)(23010399003)(366016)(56012099006)(261009223027099003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?i0kBk5vysg6PjFV+f7Gey2WQubxq9Op0SvUN+j8rEVFGcgf7NHUCjuEA1Sh5?= =?us-ascii?Q?ONwepzBCBC5GpfXPPytTRXCuBBxIaEoEeOzdHK+D30xhbVwQbyC0PRyD7rMi?= =?us-ascii?Q?/6KPsqY+7MpQ8a//fi8gnLE6CGQp7h4Im4HdzYaZh5j4xySuaFYE1Z4IMtj+?= =?us-ascii?Q?1pzXseygcEnyOfT/YJARVhvmqHZ9F+O4/gQb1KDIsNx+fmgICd8Izia/WQo3?= =?us-ascii?Q?qxbUG6VTsxJ74t5skfXIoExfJ7ETOkjmS72LgMXcKKmBH/8/2Y96hyrK4pW7?= =?us-ascii?Q?nIP1TFVShk0fJekzyusomnVNG6YhuCJUOkqdl9GoCqU8Y/LY8qWLjo24Z7gt?= =?us-ascii?Q?cZzDs3XGbUWCwq1JUD8J8KEcaYP5snuDTonzaQKA1qAWmif51L+k/1CKuYhx?= =?us-ascii?Q?zZqCBKyZTmpLWTmIl4cgNEO0VwmHv/5SypubkiYNVKm3512m0bBsRnxsDeB4?= =?us-ascii?Q?ohGJsUwO7LIIvbWFRvNBVLIUxkBcIf7Hfpe80xkwY/enSNI9myRm3GzAv/4N?= =?us-ascii?Q?/eTsiZVqj4CceFmMAEmPVRC32IQ9xBRpKq7pYPrS+VVdHkeOJ6jAq1z5jUA6?= =?us-ascii?Q?ACAowWX9TnIakwpquvGWZa/QpahjsD8ou2pu4gwpS1N0WJ2Sfyd3FhFSQZE8?= =?us-ascii?Q?tHkHa9LDHfmTvOsRFMd4lWJ9Yps9plQy2S/Uk8ZeeegtlzA1pNHz/muqJCwj?= =?us-ascii?Q?R/2iyS0gPe1+KKxu/tVDh7FLO886rdB7ZAwm21Qjf2+aC2z4cFzMuFFbFsJ1?= =?us-ascii?Q?g+kJNhTIWWkAMBltkhlVvPJRtHbRaQXx06ZWXVdtvhbIRhWyDjlpU25Jcsu4?= =?us-ascii?Q?Ab7oDXXH1jqony/gBMMaIQ1gIYuZrZYSYuI9Q2ajQk0cSdIxx8TD6oYzemfD?= =?us-ascii?Q?qmS4ZTv+uhad0eoCoUnfu0xX6tgO/+inq0WDQMRs/azg3bekl8nPoyvd6CBN?= =?us-ascii?Q?bCV3FixCLlJ5JBsTLCBgJGRqZChjbhOV+RMMflKbqdkayrzbXms/ri5TbJVN?= =?us-ascii?Q?no5JAylAwhJu7kxAFIHTb3mPRWp7ApsX9GUecx+Lah217mfLHeTHiejzE/so?= =?us-ascii?Q?tIH2JPuFO4Fz+eWYKXe1f2unRYxSRihqZ0/MGifPIvryDvZTfVERryjJhr6U?= =?us-ascii?Q?OuBQzW8l6FTmOlLki6NZd0AUv5ma+G+UVGfbi19wLKRZxvJYAQhdODSEIKCY?= =?us-ascii?Q?a2Pzksb9yBPwuPN4O2C7kpE5DK86Zxy0fjvNLOpnpwdg4fWkcMzkx1+ZA3+T?= =?us-ascii?Q?02WCFj1fJ5RDqUzDH0Vd3nva7SHbbfUAOnTK7H5BKDueU+7Jy+tE9i35h/gR?= =?us-ascii?Q?mZtpoAMvePchY86FXIiVDgM45BTYQmVKBfrbTS7leYdLXMkG3oqA00Pa1xLw?= =?us-ascii?Q?5+vvfMeeIjWSN+XDnNXgG8a6KU+tdfnRGeR5B62T1/X3XU6TaDTDI2UHwD8t?= =?us-ascii?Q?q3apAU0ShpsYIRZEf/dUjNTM1Hnz+nJ3JE05KMvJ5NJKRIUMOEMAyZrKGwhO?= =?us-ascii?Q?rlmFxegnmlBdXBFsb6pGz682+droXz+Ln7X0lVNHxIMUwdHf0H3UIwKsmNnZ?= =?us-ascii?Q?VQ/Wu9ZEHHYKH1I/t3m333bHQTf9GJCm7CX1uNxEAFnqZwBGIWoupfMwprxv?= =?us-ascii?Q?fgG8VfHPOC52DgDh/JiFTdECJUXR7cceCPcxzlM0dAXomAPgVWzzr88FnGNH?= =?us-ascii?Q?VJGHlR1ilgYWlDxmmfAqhw9QrHFOZcIBHdmJ8AWcv6J7ZtwYVEjuX0YxE53Y?= =?us-ascii?Q?Vlb4/2KYg3zm4Es+PP/LhpKy0GOzUm4=3D?= X-Exchange-RoutingPolicyChecked: upbk43FOKl9RXBZgd4sSBFX76SvGasDL59kvThl3M/iLw+g7/yc9RNNqYx6Il+Pw4KK5SEbvrUs9kqit8NDMVEUIbBlcGVlOahzw96RnYIF6FeVWXam/2k9PkIj6a5QP5HDTBrXOvtfArguBdr4lsz4ladOajOMplty6zS0LKJR04HhXTvgizdRFF71IPnneSN6bzR0hervRPG/3IAqiRrhPaKiAf4hRZC3Tsjb90zHfHUOCKKbbq2iqh7aAhCkMIQXaTJalL6xKhDwp4SQdGlX13NTOmHnwhSg2NqlwuJ833eOE8b3y7kVaP83wSdhljMrYxP2KOZMkC4rSs53Cag== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6da20008-61b1-4057-26ab-08df2b90e8ec X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:22:29.5906 (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: WYPBHOgi9gnMQp/jgWB0Jpb4tf2n7WISnoQoCBgMkfHzHvNB0OOBcyiYIaV6ImUzraoDtXhRIfAlKadBhGlGLNM7PgPywB4lMmB6Pblxf3k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9592 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX7qrY6gitTAs9 VapZWxXlZuelrHbwqkUK90x0MZDii/S7wzpBob6W1cru26x+LVIg/+17vXOGE43K1sQiKT7UPO5 1HTdnWKAWXBefeb0yb8cMa2NOVmx4YhFJjTnhbxCBcKxeLszw1DQPttVbx1tKvoqjx/8FC2fB9C KsZ2Z/uIv5ubnc34nijf/3LHDtM4icE9i7IRDM3fXgBZKMYrDLW1wR82Crsvzjmwg2qnNQ0HX3+ 9Mq0G1Yf9+I3kGznrC+ie71mQVQ2I7btiXaeqlLDyZb5T/qR6dKvE6RfsLiyBx7pGfvrgLFV4tc 2WQ+hDlJ0/VWJIyNhC6h/KJrGN9ECtP5ln4GIdjpDtSb9yp5AARdKGhpltJXykFUp09WCLJLpuv WQudX24+6+LXiexAUKFlgXPGEcLDNWQ1a7QCD+HK8Om+7mWAP58K0gPhn2UktcRfWMfi+87wd4w aUHHS6xZw1M08lXhwQA== X-Proofpoint-GUID: I-RwfBOGEqXMbL-VfK8yVZj1OoVcTCjg X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX9yaRnql/fJq3 ESvlONZoYb2Z9Z7tifo6PRlUtdLMEKtoGfQ/7AuJXnpA7sob9c5TNRoQOfihGhlkHf1rVBjb2X2 OLjX3xtOO77fBC+ZzJRUzlh2d2MQYTQ= X-Proofpoint-ORIG-GUID: I-RwfBOGEqXMbL-VfK8yVZj1OoVcTCjg X-Authority-Analysis: v=2.4 cv=KMLPn1Fo c=1 sm=1 tr=0 ts=6ad23341 cx=c_pps a=7kgNGXaSmB15KJ6u7rEBag==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=4lKoNvaWMPz1F08twPcA:9 a=cvBusfyB2V15izCimMoJ: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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792160582-50CDFB50-C07CC4A2/0/0 X-purgate-type: clean X-purgate-size: 1201 This indicates that the specified register values are being output in hex. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 3bafd81ea7..ee325a659a 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 *cs = I8259_COMMON(obj); i8259_common_dispatch_pre_save(cs); - 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", cs->master ? 0 : 1, cs->irr, cs->imr, cs->isr, cs->priority_add, cs->irq_base, cs->read_reg_select, cs->elcr, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 14:23:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 14:23:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452075.1667028 (Exim 4.92) (envelope-from ) id 1xHipv-000351-VU; Fri, 16 Oct 2026 14:23:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452075.1667028; Fri, 16 Oct 2026 14:23: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 1xHipv-00034l-S9; Fri, 16 Oct 2026 14:23:07 +0000 Received: by outflank-mailman (input) for mailman id 1452075; Fri, 16 Oct 2026 14:23:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHipv-00030c-36 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 14:23:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHipu-00BXCg-Fv for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:23:06 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad23348-e002-0a2a0a5209dd-0a2a4506d20e-22 for ; Fri, 16 Oct 2026 16:23:06 +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 6ad23344-195a-0a2a45060019-94a39b0c3e8e-3 for ; Fri, 16 Oct 2026 16:23:01 +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 69GE58vc1681992; Fri, 16 Oct 2026 07:22:57 -0700 Received: from dm5pr21cu001.outbound.protection.outlook.com (mail-centralusazon11021130.outbound.protection.outlook.com [52.101.62.130]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hberu10kd-3 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 16 Oct 2026 07:22:57 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by IA1PR02MB9592.namprd02.prod.outlook.com (2603:10b6:208:3f5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 14:22:25 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 14:22: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=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=TF9awKXkBCrr4rHv9LgEquEb3ahubq6gRo9qNTd7t jc=; b=tJMUcPaf9dnYYkuxtxuAqABVClHLGL/F6VcPg7NBoAMLwgtG9oTrthHbr Bv2TjaCgy+00Q/Q93VqwErApr3pMJhALR+i+26xp+gcH8ETdfB4PQllt3sN4CaZH kosV4xsyyTI5PCqcWbcBlN1N4jsVfr4lTt4FfAcBgIaLZKeaVMZ73pss4jn1zNzC 0SNRojgoqoUTMPqbW+nF+N0iqGYAyPoa8OOTgA4wi0X3TfYQSGE2fOyYbdr7wbU0 KcQdcRU7LP5w0VHynR1Ina4SIoG5NgoAf/+QUnt0GPquwoL1uFktl+Up62tjnwgR GzNd1P1eN1344gSfawRt3msUj2c2Q== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mEsJUnkoqwM1Gm4DJQ+PrIDD0PLPeJepLVkK2Ks+Xg/Mw2c5i1OEsVliUAt19Fx+tFSlSzwrNwlNa4uPiObXw1QS0AP9R7/WeKryqGC8P1OsFloJ64fxiddeoMkywEDCKoLGmvf9o6/igZbVJkaaW4E/3GhEh+fL87aN01bfHfwiLn3Kc4z5I47Vlkyh7b6btWkssgcAH9vl+5ChdXLmu08eCEslmDCo9A6+QHaKHylc56i9u3swCgLtAUAgNdZfNDqumyicj+N1dKJFrTItMhZI4CpAEC6Qcu84FKyAmMdlYqHZfBQSthDUzsZHPGDEKogq9zCeqcC1qiywXq1Giw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TF9awKXkBCrr4rHv9LgEquEb3ahubq6gRo9qNTd7tjc=; b=MtV4fKv+XLOHEDbSc2QiirjqW7tXUC9Nm8vrFVZEP79/YKU9GO8zUGbhDur5QeblnCIdy+8ZjZmA/Hdfy28999H28hsYJfhVOdokHNx7txuMZQd8u6bz5LcXblNZ4VnYFral8k6qIs7dgJYf+Ipcs73yvKMH+dxOaYT27tGQ9folNkfMaSNtrS3z1TDRLWUqbkuwbz5uvK3cAbeZOUNkl50DHlNRJb+fWzswtmLNO18lTDetsffVDbC1fPQf4RDVHtvNBi/+A0liNs5QuOzPt6NRtU8XUigg3xeNBioDe0fJbY/1IQNclrVLoZfLl5ApLDaC0WEZ0+Zyf3XBcugpZQ== 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=TF9awKXkBCrr4rHv9LgEquEb3ahubq6gRo9qNTd7tjc=; b=hEltSo+/aKMEBK4Uy8SMG4KSfVuBjCu+qcuYDPPrJDJS9agUola3AhNLBG91fJ5F5k6nG0zD5UqhSnY8oYJC4WtL1EYszqJiVISP8KcIxLTH2D5cxcW6a0T1VTOUmev4D0D7EX1R62SW42jkdbEZt8MgaHBns3LphxArN7snxYeJmzj1IAz6HyDx2SldBFboLgBei6Bx/kGvNfPyF8KN5GB8n6UE8d2T/9PPrb+yJo7w9e64AhjTYa8iXnnV7LkcJ4Zkkkh/LlPytwAokYqAchmUq19Ge9+vgVpnPl+xb/M/vkaxPc+ZN9A4EkQ5MBK912HGG+r0V2ze88t339V6mg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v2 26/27] i8259_common.c: remove static irq_count and irq_level variables Date: Fri, 16 Oct 2026 15:19:32 +0100 Message-ID: <20261016142031.1204281-27-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261016142031.1204281-1-mark.caveayland@nutanix.com> References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0162.namprd05.prod.outlook.com (2603:10b6:a03:339::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_|IA1PR02MB9592:EE_ X-MS-Office365-Filtering-Correlation-Id: 6c00dfc5-7523-4ce3-3569-08df2b90e63f x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|261009223027099003|10067099003|22082099003|18002099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: 9ZmbQiGv3cuWgyNi6qCP8N+vlRBk7bujvyzZ47buzxCZc836nqPn7j9E0WWJN1uiS3uM+R9my/U/xbQT7VmTHOoJOdX9BpqtyEXMKehjvgo2Bj6o3scLFmuz9n+HTXcwdchjXVHUtXr3RX3Xb51TpdETFH7lhaCvPGQavZdljjHtx6zAKXQeWTnSkin1WOTAMZx4CH+fq4Zvmh4fP2nzPk7kNf2dyyU7iw0bETz70Y6NYdSwLfPaY7rRFrS6k9Ijjpr+Nrr3tnwkYc88ypRC8gLGm/M84+Z/8eRsCwtXEfxBczvLJ2zDeJnGCmnpwq9lTRhdojrKzS4bYMNlkr3aitaxfqPjzeglmOabmwO4Zm3eyeVrwU1bcYwZG3qZDwPQUWGcLqTV113nxSngftR9SRibjyVGAtx+HNLk9E7NhTrg366uywsqGgnhwU7kGMxyR/sB9z3ohj6D18WYqdA9Rldme2n8EeMWLeLCiL0Sx8egsVn+bKm5zSdPXC8rLoQWE0/xAhuoRHVBCP11qGltFAqQZWibTc9demyhqzMf6/AQO4csPvRVd4N9+Ptr+p+4XayJx7/SYgEcsfh5TGi85kwbjtTrweF1SkOYMJNc/VR6OyZgn5V8aAF1sOOCBSGLVLgobrLlwyBRUWOQ8xnY2kPuVfKSnDGo4XVXZZSIUXo= 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)(376014)(1800799024)(23010399003)(366016)(56012099006)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?fJj2t8g9LTrxgl4qgQjn0YBZV2X9c47xWHkL8xAS4rE5KY/3Ht7bocPHbLlT?= =?us-ascii?Q?vt6/67wVCCAJd4bOVWyFtDe19ak6xcU6kR1b/0I9W41Bd2Tx9Czkb+22WmGD?= =?us-ascii?Q?Fit/XpURJJxcmKuxQTtW4Gt22wlgjr3P6hh914NEdWjihUxgX86tlrCZGQOp?= =?us-ascii?Q?V2TUXYuvhCaHIyV1edZUl/UV4HROyoPQAVv60DVEPGPnOevRYgFmir5Lwv74?= =?us-ascii?Q?SB8OlOnrNV2MryME81jFZ6S21lcehgY5C0RfzSKSw6MnCvTisZNbHnkrCLlX?= =?us-ascii?Q?vfJFADr/e2a5P8VAetDasjjXgSSEVAXDtFsTiFJ+0a+/i2TRiIc84Y1H5Q1G?= =?us-ascii?Q?Amon87Mw7zKSzcFABusi+46oxTtTpWbNW17ozy4Np+jtP9n/MDlfIY3yaKLm?= =?us-ascii?Q?9xKgEnf1ws/S6ykAGJkvgJX4K2htWGQK4mrQLxoVp4LkB9Y0qzADgiwN9icJ?= =?us-ascii?Q?D94JVhiQ/j0xIkPDBjA6sKfMiMBgWUKYOzh7yFGzuLRY+lXcS6/uX9Z+VpD7?= =?us-ascii?Q?6h2HJBJ3sw6rXVSQuB2We9fRAaHu4T7Z1NqgIsVTSxGkHIikgyedObJ7vpN/?= =?us-ascii?Q?OC2c2cOQIE2bbqHD/CkwQS9SjEF+Z52B8Tk6VAaU19IEbzKexEjoqYgya/Z1?= =?us-ascii?Q?AN+Xic7uMdZAdw7iuh+1S4HN1qaz6P9A/PwcC+K/iP/AiyIUPjMhjBAIVQHy?= =?us-ascii?Q?mIAETV3fkt+MoXQBIz0G4AcRe+OhrZzpUU8hofGGRfxf0dWoGgyfBSGWrf4W?= =?us-ascii?Q?ejL2wB0XYDgceg1YRRsx0qSrDGttugzKpOJTRxQ0Cv+vezEmAy++lFvV1R6w?= =?us-ascii?Q?YW0UviZp41NbeM8pIuXT3sxCZv0BLjHDc6Q/Bjz1F8myziItI49d3yl66idk?= =?us-ascii?Q?jHUgib6zBF0GPa9sGCIWqp3hvF6d+6h3qNngTGL6/zLEkGDc0jktUS8qMxmq?= =?us-ascii?Q?zl+OyVudG2StqB6ZuL2vHR5PRc914o9mtwKMY/rXPAh8au4ifKqaAeArtjlB?= =?us-ascii?Q?0pj90eEEOhR3NqxPHjYKkYXAwUcIh9FjIZJsY4aTEZRYR1ZpEPrWQW8ejRBM?= =?us-ascii?Q?JSzvpsSjLpGsbKBwNJ//9Ls1agSjGbd8vcgQX0g8hdLavW/quyyQBsoU1rLm?= =?us-ascii?Q?DP51rOnfEpoRmsdsDlSA/PDiu3YtVh97VTn/hJ7yej9VOp/yLG0QoolcC5Nl?= =?us-ascii?Q?vmPEaHW/tjsWaX7LhWAWcvfvrWqFYoXwNRSSUcQVIjHX4K2CODourvrL4ah8?= =?us-ascii?Q?uonPkMdrA1b0KM06bzlvRbyrbwH2JPUcPrzJXDYkbTMRP3PWlzSzaGVTVnRP?= =?us-ascii?Q?fS7riqdm9f81gkaU10IYSm1axr0RyAsjdd4eT101h04yxjmvlhukQ7KiyKdL?= =?us-ascii?Q?N+51/2d1Xytgevx9WoAgSPZxQhkmgvWW5CPdMY5d0+fdT+KgeV3xKKQDZUHY?= =?us-ascii?Q?MiWGKjmbXjub96TnM/sOvKlfbMY3nhGTcrdKgwPk44ZkqOa8KUlGVyNh79Pr?= =?us-ascii?Q?+yULlxYhVQidu2Xr0SK1Ai8RyKr3Oq2fCjnryfWz8Kpo8YsxV4qE8khth+kv?= =?us-ascii?Q?zaYDpQto+EfmBi9DcbuPHTHCdQhYRS6s246QFPqmJTZJY+bdxyY8q0CZH68J?= =?us-ascii?Q?VaYPmB9/rby7yZ3zuLT2JioYoWj47fwRqAuvEjNiD/K3IFn8oU17fV/rq/MZ?= =?us-ascii?Q?jTpnDHG09X6DmJ2saROleSNj6Kcg4GZ7j5WUol7qy9KJMxiTUSekQA50yRYN?= =?us-ascii?Q?0FejQANGWJTHNPeBHmcYRavTQBTbrqU=3D?= X-Exchange-RoutingPolicyChecked: ToTsIdLdPu29YiBOWdz9b1IK0wHmCk0LLd84KpJKU8YiY2eFqDs/k+Pm7em4gyfVi8B+l4RiAK18P8+lAFcTX86UEjrZNuLELDph/o5Sqk7lJnEvAHvyTqjHjZTEe+0W0SjT9UqThf2ZEG2wjrCTu0Ts2MN9X/DycMumPK2R5SmOlCdwNg56uz9kG8SzyUQnI4pxWmviJdQSwzYjLeeFDOiRcdLk6X4DNXaJ2F19hycp9Higrnb6CXT1/QOxkeFZ3ilYtjYUMzQ74W2AsYdtKN29g44+2aiM923ggtuOMgDSAUIp0QRevt4mPHb0pv28LbpC0Xbckd5NxGE3xQ5sRw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c00dfc5-7523-4ce3-3569-08df2b90e63f X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 14:22:25.1030 (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: W7ZIgA8+QgO4ZFtLAcGxZvXwArbWnfXVAiL7ZXxlweJaHc/fndExXdihApKPTshXm0e0SXi8jPlPNXIv2Zjku+69Szl/mnQ3niutsatol7w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9592 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX/D/nIcdkaZDv YP0NUURKP46e6NPB3wzpdcyCcqJLLsKsdtRlL1HOoQIMYzJ69/+D1JXBgfqkKADeN/OTLEHt6bu jfa/RROWioJu6I9UrAv8Cprku6hBCCjdidcIvg26YtBnZxA/74N8azj3svwfxc92VnqWySjJz6L 8Rc3uyyQF6EPrnMq8HRRyav0vbZ7P733u+7fuF7q/z1bP9YrAxqnEGuLFf5Ub1NO5O53D0JWeTO jLfQzuvQ26o3rkm/RLhRNnlkqrPh0yCP2cbS3YArGXYPyYSUvfDSyu9jfgWVgeWYsLIpCQuniGz wNaFZFuP/7KkjO4Yo5FetB6pIcrXGGVUq21umxZT24I6a6fZytMLZUa9JhKrAb4WsxcztKZp74Q cEXeWwRj6I7nIbD0BQfnYqJIfLLJmCF4eYkTJjVGhZRGBe3i0HkzhKk8xnGAXXdZpEJ11dDOUP8 ebgLMh6ybkGu+bv2nww== X-Proofpoint-GUID: ImplHB_Y0D1bMyUUQs9ecSG5PfgMSRir X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE2MDA1NyBTYWx0ZWRfX3jc8FpGTCmyi QYqBZiqXjH0SP04CYYaR50G5tNNvB7EHqjGBmTTWTo+/3O0XCEAp033tmWwqMsfoB+ygfaPnO4H EHNFFbzSxOEaDInLAWf4V+7s75tAXmI= X-Proofpoint-ORIG-GUID: ImplHB_Y0D1bMyUUQs9ecSG5PfgMSRir X-Authority-Analysis: v=2.4 cv=KMLPn1Fo c=1 sm=1 tr=0 ts=6ad23341 cx=c_pps a=7kgNGXaSmB15KJ6u7rEBag==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=m9Rx451XjQ6kX_1OFlEA: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-10-16_02,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1792160582-1ECC577B-CE72AD47/0/0 X-purgate-type: clean X-purgate-size: 7334 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 4922f88d5b..42d6f992ac 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -20,9 +20,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 2807409eff..e0002843a1 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -70,6 +70,7 @@ struct I8259CommonState { }; void i8259_common_reset(I8259CommonState *cs); -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 b56e4fced4..3e65b243cf 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -45,6 +45,9 @@ struct KVMI8259PICState { ISABus *isabus; KVMI8259State i8259[2]; + + int irq_level[ISA_NUM_IRQS]; + uint64_t irq_count[ISA_NUM_IRQS]; }; OBJECT_DECLARE_SIMPLE_TYPE(KVMI8259PICState, KVM_I8259_PIC) @@ -117,6 +120,18 @@ static void kvm_i8259_put(I8259CommonState *cs) } } +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 *cs = I8259_COMMON(dev); @@ -129,9 +144,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); } @@ -227,7 +243,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 7c9ce2315a..8b1dd57849 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -64,14 +64,16 @@ struct I8259PICState { ISABus *isabus; IRQState i8259_primary_out_irq; I8259State 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 @@ -138,16 +140,8 @@ static void i8259_set_irq(void *opaque, int irq, int level) { I8259CommonState *cs = opaque; int mask = 1 << irq; - int irq_index = cs->master ? irq : irq + 8; trace_i8259_set_irq(cs->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 (cs->ltim || (cs->elcr & mask)) { /* level triggered */ @@ -224,7 +218,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); @@ -456,10 +450,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 684290fb2d..3bafd81ea7 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 *cs) { @@ -89,26 +87,17 @@ static void i8259_common_realize(DeviceState *dev, Error **errp) qdev_set_legacy_instance_id(dev, cs->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 Fri Oct 16 15:32:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:32:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452223.1667037 (Exim 4.92) (envelope-from ) id 1xHjuR-0003h6-Rh; Fri, 16 Oct 2026 15:31:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452223.1667037; Fri, 16 Oct 2026 15:31: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 1xHjuR-0003gz-OK; Fri, 16 Oct 2026 15:31:51 +0000 Received: by outflank-mailman (input) for mailman id 1452223; Fri, 16 Oct 2026 15:31:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHjuQ-0003gt-3M for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:31:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHjuP-008yi6-EH for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:31:49 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2435e-2eae-0a2a0a5409dd-0a2a4508dbe0-12 for ; Fri, 16 Oct 2026 17:31:49 +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 6ad24365-f659-0a2a45080019-b9ff1c12b075-3 for ; Fri, 16 Oct 2026 17:31: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 1a14557373c0008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 15:31:46 +0000 Received: from leducb (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 14ED281CA8; Fri, 16 Oct 2026 17:31: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=yLjdbl2lF5/FIxD1EtPVTSAUq8BcR+i5hBLnKj7X/8o=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=CwLrAySobp6k6fDR6XvxpKZPSc5+afWH8oAax/yGrB9uWxWxuP4qwe39ni2EuROEeghN3Jt/k umkMcLIghIhQek5JmNLTAqcJffJXIkldLACO2VvanY56qcZzHfbHWB7i3/IuyYRCEtX0RC8WZQI 3f63XzLvZ5N/pWpQ6RMQ282WpP9Z+DKIsfY+r42GzxkIlEjEe5YcTwVy5hDFpSx/O+lXTQR6uHP mBL2/REhCM3we5r+oP9Tgmlkij9oT+0MXpR2mjveM3w7CPuy3oQmnqn1I4u+cicbxbDlUPZeBL3 53meMhCZOy3NRHV0Jpu//oYSRwLeOAZvmadU9R1Lqbkg== X-Zone-Loop: 5a6e6fced1db66d9eae9ce3328264b7914250a0a250f x-campaign-type: default x-transaction-id: d5447c47-8ff9-43bd-a125-f00d22aa85ad x-swg-uid: 01-5d6425d3-a6fa-4b84-ba51-c660332a201a X-Mailer: Sweego Message-ID: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> x-swg-bid: 1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v7 0/4] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Fri, 16 Oct 2026 17:31:36 +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=1792164601; l=5030; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=vImn9Mc2oJvx6oEn1A3ySpcvzGtSwkYrOHUzCelegws=; b=PN61G0QD9G3halRnoualJ52C/3lic8BxTb2o690S/W7CtzKXZWJWyONd50o4em24DYoV1tUsY aaEQhfo7MNAAZzWHepImbOnV3SkwWGdVzArzCNSJ8jpPq1vBPtODmX0 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: 1792164705284 X-purgate-ID: tlsNG-c1860d/1792164709-CC97287B-8004DE7F/0/0 X-purgate-type: clean X-purgate-size: 5025 This series introduces bug 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: Use pte_is_valid() in pte_is_mapping() 2: Fix A/D bits in Xen's page-table mappings 3: Panic if the DTS advertises neither Svade nor Svadu 4: Rework the A/D bits comment in p2m_set_pte_flags() Test CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2956020449 --- Changes since v6: - Drop the boot time probe of the A/D update scheme and trust the device tree, as suggested by Jan. Xen now panics when the DTS advertises neither Svade nor Svadu (patch 3). - Patch 4 no longer changes when A/D are preset, it only reworks the comment, since patch 3 guarantees the DTS advertises the scheme in effect. - Reorder the series so the already reviewed patches come first. - Patch 2: add a second Fixes tag for arch_pmap_map(). - Patch 1 unchanged. - Link to v6: https://patch.msgid.link/1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech --- Changes since v5: - Replace "xen/riscv: always preset A/D bits in G-stage PTEs" with a boot time probe of the A/D update scheme (patch 1). It checks the result against the Svade/Svadu DT binding and records the probed scheme when the DT advertises neither, instead of trusting the DT alone. - Split the p2m_set_pte_flags() comment rework out into its own patch (patch 2). - Patches 3 and 4 unchanged and are waiting to be merged. - Link to v5: https://patch.msgid.link/1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech --- Changes since v4: - Drop patches merged upstream: ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"") - Collect trailers. - Rebase patches on top of staging. - Link to v4: https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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 --- Baptiste Le Duc (4): xen/riscv: use pte_is_valid() in pte_is_mapping() xen/riscv: fix A/D bits in Xen's page-table mappings xen/riscv: panic if the device tree advertises neither Svade nor Svadu xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() xen/arch/riscv/cpufeature.c | 17 +++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 +++++----- xen/arch/riscv/include/asm/page.h | 35 ++++++++++++------------- xen/arch/riscv/mm.c | 11 ++++---- xen/arch/riscv/p2m.c | 45 ++++++++++++++------------------- 5 files changed, 66 insertions(+), 55 deletions(-) --- base-commit: 7e020a4dd6ed30eb6c91a9abe2767034e2bb270a change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:33:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:33:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452229.1667045 (Exim 4.92) (envelope-from ) id 1xHjwL-0004mv-4q; Fri, 16 Oct 2026 15:33:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452229.1667045; Fri, 16 Oct 2026 15:33: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 1xHjwL-0004mo-2E; Fri, 16 Oct 2026 15:33:49 +0000 Received: by outflank-mailman (input) for mailman id 1452229; Fri, 16 Oct 2026 15:33:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHjwJ-0004mi-Tg for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:33:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHjwJ-003Lh2-Ae for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:33:47 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad243c7-8faa-0a2a0a5109dd-0a2a450cc31a-20 for ; Fri, 16 Oct 2026 17:33:47 +0200 Received: from [40.93.196.12] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad243d9-f479-0a2a450c0019-285dc40ce0ab-3 for ; Fri, 16 Oct 2026 17:33:46 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB7255.namprd03.prod.outlook.com (2603:10b6:806:2ff::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 15:33:43 +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.0522.013; Fri, 16 Oct 2026 15:33: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=k3QO1Ri0V3WjARjr9NtAVlRnbwZAHRS0Je6A7F5rbLqyFzobp6TmMLq9vNnm7UXVJ6Ouw6MxUu7EFcrujlFRxx3TnUC7NRbVUbkPk9bu8LGoOFDyLgYPEaJqPXEa8J0F3t2FuZh5msCPEslpT8TDcrNyfh+UapU3OTVLwzwyHyJuAMDU/Ky626MnYz5ekpG+5udagWrrZNk6g4bsz9AFEgasYwwslF/YttzuZOvIWGMwIYsEflQJBi6wfpgDLyyylFTwFvYra7BhpEcA9xSPllKdnLiAZPxelA61d8AEfmx+edTzxFpekqZSzF0WADAqm21JScF/Hd+EJhm01AJn9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oyYj+KdUHwwri2DLSGkjBB0QkZJnEMclY9v2hFZ1Kkk=; b=nBFLDY0y6Lz3IQlvNornENklDqFOto/QdoswuofLcxRRYll8i3hsoSmmVEDOzmqWaQxFM/JaXL3mj5CRTDvszxnnFou9Om2fiN2wWemOSBW4YH/zd6r+oA0V+jMrhjdjwwUtUMFzkyXlDXGE/uetCs2xg9W6b9C6TN7UDei7u24ye9FfA6b0vnF/EV2xVuG2jMVwowoazC48KyisfuTd4J10Lt0Nhv8PTiNZlD2ai75UoT4ZDaY4yupviZcXffQ6tO6YPIZdmFlLDEWqCaBOGW/PKWTu4wD29Vrk2XLaS1Nr3sf+Cz12FnSQcLf/jkdJLpfnausaSmd62itcwGcOQA== 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=oyYj+KdUHwwri2DLSGkjBB0QkZJnEMclY9v2hFZ1Kkk=; b=nYHmI6AizFc4y/sXJM6SW++spKfKY1NXLyRZ9QjwdQlCt1AuRoQbUz4G8j3st+dYB6/CHGybXzRkgUPnQuH3OsGP+N7ppmy8zVeAicBbnkIilRcvo2si/RS+5aInxs22bFaQTnuwoCrCHNXG16ldYYnCnnT+GTTPsxem/xbXWZM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4a387bee-cd6a-4776-ad22-b71ddea151e3@citrix.com> Date: Fri, 16 Oct 2026 16:33:38 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , George Dunlap , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xen: Use VCPUOP_register_{runstate,vcpu_time}_phys_area when available To: Teddy Astie , xen-devel@lists.xenproject.org References: <1792146192.8631fc262581453bbf619ec5b2062170.1a1443cb7e90008425@vates.tech> <9a8b0ae0-ec49-4af0-8e5d-1378319f2857@citrix.com> <1792159847.8631fc262581453bbf619ec5b2062170.1a1450d15800008425@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: <1792159847.8631fc262581453bbf619ec5b2062170.1a1450d15800008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PR3P193CA0001.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:50::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB7255:EE_ X-MS-Office365-Filtering-Correlation-Id: 6dd62101-7390-473c-4ee2-08df2b9adc5a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|23010399003|1800799024|10067099003|22082099003|18002099003|4143699003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: Aqqoe6i2DZdKyWou0GHRTb/UWxz4g0zqfAIQB15lDfXvqhcdhtsX23qErOZm0m5eqPGivSLe2o4neFmpwSq6SPZsowiZZsdO9ncOXDDJmlApFCN5rhyZMDPwt/dQXz0tkfTzY7TQpG28GfQBHNyU7uyzV0UVxu8DBmyqCIHICui0Fg243wx4C7zcmM6yQTAUVDFV0Sscavmgv8gK9G39cbrbwreMN3wN4OU0BLZwiyv9s2ArdLi7kJ8+P9XdeQkTIUMwnCQCfQ9vpSMe4Nlv/I/7/RXLzi3SttERsOMAUe47cUyGmhKrarzI9VMZgekhqCgx5z0/fCf3s6N3dCCMJQROVY7C2++OeMbNhuBUD53YIJsuBJSrsl/+iLb9lF4TqOLiuzrDR0gZVh1ZFxTnO70NeUGKSHxiGwFpwKZ5y1ybYcr8bH6ZqDeC8qUDTsduGr97FsVwMT0tVJ2+23pzz0FWSl7gzuU+GgepQ8qwv160lEAZvq32CQVvrkhicWv35T7iWq6VJ1OIyqr2FEAp1lnHIZdqHDUWWjT0ZxfVKJwpkLPmg1cYx/Uik/TsGXu7FC1GYz1kNJe4iNwP/2w9W8TnSbE3KaTvUSBzKch5dtWMRmEO/YsOyS4X2H7eczkvR8A7lNLElZy9R3vfz73yq5IGO2oo+MOsDB7i4sOm6WM= 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)(7416014)(376014)(23010399003)(1800799024)(10067099003)(22082099003)(18002099003)(4143699003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TzdsOHpmalVDLzNqWjF4ZGxjZTJybHptVDN0VjBVamJQR01aZUJ2aUdFc0Ix?= =?utf-8?B?QnhCOVZsUmRlazdtWlJjQ0t6eFlXZUJndWdMcmo0NGNJK1NpWFJSNUdQenZk?= =?utf-8?B?cUtjeUtHZWtjTEJzVHV4RnpkVjBITXVib1pkR3o4eTA0eHFyNzl3aVJPQVFl?= =?utf-8?B?OW0zL2w2ckcrWTFNektHdm1nRlpUVEJWMkdpOTBOc1Y4WHhDekZZQVFNdm15?= =?utf-8?B?S3dveEpvbTliUHJnSHB0U1lGb2Zsd2hPRE1PODN5QzlkMVZ6emJRTjJSN0Uw?= =?utf-8?B?ZUhGVTFqOGorOTN4WkdXMXhvS2tLWVh0T1VKYjI2a0t1VnEzcEFZN1ZtZ3BM?= =?utf-8?B?ZnV5TXR0NTh4SFlZK2NGUGFCMnppL3JPUExhTCtnZVR6eHpwN3ZXZEhqNnhM?= =?utf-8?B?S1h0VmNIVC9xT2I4cWxMRjdVT3NHUU15RXRUOFFUMVBUMWw2OGpCUkluRENH?= =?utf-8?B?QmVGQ2dYa1FDTThKSWh6dHFqaGhXRXNoeWNSZStDbEVmdk5QYWpTNkJzMXpJ?= =?utf-8?B?d3BPZGdsL0l5aUU0aWF5YlBmM3RUQXc3VlVxNi9BVFVxQTZpdW4xeUEyRzVy?= =?utf-8?B?NzlmNHFreEtwdFB6SFVCUmF0b1hNanhFK01TTEVMcm0wN3BtV3lEeFFpdWdC?= =?utf-8?B?NXJtaDl1bFVIK3FjTXB5UUNDTVd5aWpmais5U09wWGFVeFBFNkhXbnBoVVc1?= =?utf-8?B?QWhOTlZpWlU4dDk2NUVQemlKUVFCVjN1bUpBSVFpdG0rZ0o1dDl2dWZiRnoz?= =?utf-8?B?NWdVdVZYaHNScDY3VDVOTy9hQkp2MVNUMmtIRFFob2V6NTNDTzdtZXZhWWxV?= =?utf-8?B?YWlnamhUQXdpdFRBTDhjUldIRUR3SkV2T2t4bGlETEZpYVVLN2FjeUNCcXlW?= =?utf-8?B?VjlpWXZsZFJKQk1VMnJxck9ZbnRrK0VXUGJzT3MvRHJQT1V0WDFiM2s0N1kw?= =?utf-8?B?R0pXYzlxUEphVHRmclc0Nk5WNUhlbVE2cUlWTUc0blc3WU1QQ3U2K2RqcFRC?= =?utf-8?B?Sks5UDdORE0zZVA1QThoS2Q0NUtZVFhrNnNoaWVwTEZLM2RXN09rbis5eVp5?= =?utf-8?B?LzR2R3M2ZlZLU29PdEhGN2FIQVB4OTIzVUpNZUttM0FYSkt4WEQ3M2RsRWVi?= =?utf-8?B?NTUrN2NCc1BIWnRCcEhjZHNqYmxQVER0czFqK1R1eHBVYVNYMVlhanplaUtZ?= =?utf-8?B?Snk3MXkraUNENXhpakpNbzJjbFdZNVR3QitKTHd3QWZOcm5zY1N0bERvMDhB?= =?utf-8?B?QXRLaEkzMkozU3paWGZ1dnIvZU51bCs2Yll1MHZCNHJkVlYzU1ZYNjg3Njly?= =?utf-8?B?UytVWHJnVERaeGN2ZjB3TTlkVlpjQ3pmeDAyUmVxWFRFMU9UMW1vR2lXd2ky?= =?utf-8?B?Y2Roa3hHSjNTMkMrQzhzZVFpQWVpVGNpN2pPb2p4eG9zb0o0TTdNVEtiWHhZ?= =?utf-8?B?TnJnY05ob0JlZWUvV3Y1aUlNTmNwYkNHbzErNW9lSitEWS9qRDFqaHRQWmF1?= =?utf-8?B?WGxEVGhvYTRJenR0SFlmTlc3bEV3QmxtbnFxdEtza1gzNGY5TFI3em5JNHcz?= =?utf-8?B?QUdCR0V1aktsZ0ZORjM1blo1NFd6dGVwVS83RXRrTU1hbXdBSXhaUllIRmxK?= =?utf-8?B?bDd5MDdtUVJDTnZOT2NsNk80U1NDNWkvSHYyU0VKM2ZiSzQ0cHFyQkRoOWlN?= =?utf-8?B?YjFvcW5ZcXV2ZDhSL2NJZktFTDc5c2srVm5jYzN3MTMrR0MzbmpNUjJnLy9C?= =?utf-8?B?YTdINFZhKzBLQWxPc1RTSTZWNEphajlxKzIyeHJ4TWpXdno5RnRRMlczNXpo?= =?utf-8?B?ZXhmcUNKa25ZTFlwMWI1aHNZWGhRSzFVY2QrVXZmRUtYVzNLNDdNbDdaeTli?= =?utf-8?B?Z0oyNW5LbjM5UTFOU0dVWHZuMUhZOXo2NnJjWWhnRkZxN0Z1VFluZ0VjbDNi?= =?utf-8?B?YldJMmFQZkVIQlBIYkIzWGJjTUlMYUk0bU1sWFozUDBLRHhQNlRnNGJpL0E3?= =?utf-8?B?bEVBYkdmWEdCYnVPSGN0MkZKdHBtWVE4YXA0Ujh5cy9UcnlBeHFCQWJidW1z?= =?utf-8?B?LzhKVU9qRVZzaUo3b2JWNXR6T3Uwd0xxS3kwSkFFc3ZCYU03eXJ0L0N2Sy94?= =?utf-8?B?SUtzVVIrdWV6Q1pmN1MveE56d0lGbW5hYWd4c254R0NsMUs5RUZlSVFXVGVN?= =?utf-8?B?d001eU1IWHFYcXhHQ0plMjBXZTR4bVNhWFlSRmMzb1ZqMEVLTzBNM1VwWnMy?= =?utf-8?B?S0NnQlRabEhJcWVKMkFzaG9aZ1BVbTRSb3o1cHd1R2pBTEh3bk9DQ1RzZU4w?= =?utf-8?B?SUZ5eXF2bEVNV3JOMjhFWDdBV3V2OTlqVFR0ZXpGSnNrcXoyWCtrdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6dd62101-7390-473c-4ee2-08df2b9adc5a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 15:33:43.3566 (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: CYmCbKEtMHz0EMIHsAg41aqvI1lJLUofYvfYUjGvH1Q3fI7QGKBoJTAGOSLLNh5tJZFbgF6GSPziH2SGFfBu6gLG/kUmdGwRViiTte94MgQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7255 X-purgate-ID: tlsNG-d25034/1792164827-50520A5B-EA2D1511/0/0 X-purgate-type: clean X-purgate-size: 991 On 16/10/2026 3:10 pm, Teddy Astie wrote: > Le 16/10/2026 à 13:20, Andrew Cooper a écrit : >> On 16/10/2026 11:22 am, Teddy Astie wrote: >>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c >>> index 5c7822254a01..19ace1b78ae4 100644 >>> --- a/arch/x86/xen/time.c >>> +++ b/arch/x86/xen/time.c >>> @@ -37,6 +37,22 @@ >>>     static u64 xen_sched_clock_offset __read_mostly; >>>   +static int xen_register_time_area(struct pvclock_vcpu_time_info >>> *pvti) >> >> This needs a comment explaining what's going on (by GPA, falling back to >> VA), including that passing NULL means unregister. >> > > Will add, I guess we also want to mention that this does stuff on vCPU 0. I was puzzled at why it only ever uses vCPU 0 for time handling. Xen does allow there to be a time area per vCPU, and I have a suspicion that this might matter for older systems lacking INVARIANT_TSC. Either way, I don't suggest opening that particular can of worms now. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:34:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:34:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452234.1667054 (Exim 4.92) (envelope-from ) id 1xHjx3-0005Rd-Gs; Fri, 16 Oct 2026 15:34:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452234.1667054; Fri, 16 Oct 2026 15:34: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 1xHjx3-0005RW-E0; Fri, 16 Oct 2026 15:34:33 +0000 Received: by outflank-mailman (input) for mailman id 1452234; Fri, 16 Oct 2026 15:34:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHjx1-0005Q5-Fg for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:34:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHjx0-001rv9-Sq for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:34:30 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad243ed-e002-0a2a0a5209dd-0a2a4509811e-40 for ; Fri, 16 Oct 2026 17:34:30 +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 6ad24405-be1a-0a2a45090019-b9ff1c12a4b1-3 for ; Fri, 16 Oct 2026 17:34: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a14559a8f00008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 15:34:26 +0000 Received: from leducb (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 67A2F810D3; Fri, 16 Oct 2026 17:34:25 +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=TYkQbB24A7mbJzP5+9iAJu5opBgqk4kHWOgNAlFgWI4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=BYu+8xkDBEd7ga7nURxD7eStHZ5zN+M2DUDESW5Itfmz5dNOC3hv3+RQ9sg8ET5fALRy4Q0sS teKWAGKGbGWJYT+gSzrNfR6SHcXS390V/z3cNC3NPXNpOpN4kYn+vApeUfUF722BUYEnoUbaqx+ xCxej3O39sHewbNvHhOVFXGIeIjE00VM6bjUpbkQQDFTofHsyoBOOpZH8lWCtIX8Dm+1+n4ulTI rU6ws2dNyyNrJ5/RyGAhwFXbRThU0VgqO8nPN+ENqWvwc/IxDZs1megAlN5OUJwxqkn0M1x+Qa4 jc5Yx3yfC3H5hYq/8s1jFT1/uoH/2XsehgxyCpdGSPGg== X-Zone-Loop: a05d7fb29ecdfa93b6ef93729b99bff15f3fea3002fe x-campaign-type: default x-transaction-id: 50ac1b70-a57b-47d9-9dc3-21ae62cad52b x-swg-uid: 01-c5688111-bf24-429d-9945-ff29132c079f X-Mailer: Sweego Message-ID: <1792164866.8631fc262581453bbf619ec5b2062170.1a14559a8f00008425@vates.tech> x-swg-bid: 1792164866.8631fc262581453bbf619ec5b2062170.1a14559a8f00008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v7 1/4] xen/riscv: use pte_is_valid() in pte_is_mapping() Date: Fri, 16 Oct 2026 17:34:17 +0200 In-Reply-To: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1792164601; l=1244; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=+LzNSE69Zr30dJkU84NarchViXCqICrw6WmtSLXks6Q=; b=bNTzxbYvv9vey4JFgGuBmc1YSyU9HYVbIGJ/y6Ya5nH8owyjvbOZWlcI2n85Ep+5dFkXXT1fb 3vu3h6/sCqkCBDtGMzVZ9LLo0asg3B9sL6/G+5QlnaOTe5ypgAq6fkg 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: 1792164865623 X-purgate-ID: tlsNG-bad1c0/1792164870-3A6DA034-00595ABD/10/73395122804 X-purgate-type: spam X-purgate-size: 1246 Use pte_is_valid() instead of open-coding the PTE_VALID check. No functional change. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko --- Changes since v6: - no changes, already reviewed and waiting to be merged. --- Changes since v5: - no changes, already reviewed and waiting to be merged. --- Changes since v4: - rebase on top of staging. --- Changes since v3: - no changes. - add trailers. --- Changes since v2: - new patch. --- xen/arch/riscv/include/asm/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index b465a90325..c8bb334b85 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -187,7 +187,7 @@ static inline bool pte_is_mapping(pte_t p) /* See pte_is_table() */ ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); - return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); + return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); } static inline bool pte_is_superpage(pte_t p, unsigned int level) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:34:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:34:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452235.1667064 (Exim 4.92) (envelope-from ) id 1xHjx5-0005fl-NX; Fri, 16 Oct 2026 15:34:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452235.1667064; Fri, 16 Oct 2026 15:34: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 1xHjx5-0005fe-L1; Fri, 16 Oct 2026 15:34:35 +0000 Received: by outflank-mailman (input) for mailman id 1452235; Fri, 16 Oct 2026 15:34:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHjx4-0005eK-Sr for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:34:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHjx4-001rv9-9h for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:34:34 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad243da-e002-0a2a0a5209dd-0a2a4508c856-38 for ; Fri, 16 Oct 2026 17:34:34 +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 6ad24409-f659-0a2a45080019-b9ff1c238cfb-3 for ; Fri, 16 Oct 2026 17:34: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 1a14559aa020008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 15:34:26 +0000 Received: from leducb (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 E22A480048; Fri, 16 Oct 2026 17:34:25 +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=kd8hyu2pwxdWJMMk+8+bs2OtvVOlWK795twG5YZLGjQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=FBDfl7LnyHgbZE7QBnWIaZWnqfLu6PilyYRA1H+ll9lb4jvuGZ4n2Qpa04H8MxfM86Lb2vap4 pkngcrlJ6Gcsj2vxWjCvSNnp5XBvl5U5hcIBdu41/VFgQ45m1zzwEw05QRxlcScZqSuOkGsHS93 1h6ujJrAc61q8m/MzOR+JL6jCJJM4BcR9dyY9OUIIZEXtITp4i00Ww5sSibUmZK96XJ1xDMIgex ByQY43g1uA8CRPkoP+8zLkmnzK1sjP1sUNl7FJ1g9BhOW6bfJukhHC8xn3QN5MlbjBa6gvXzEgO +P1eYNR2c5r5Z0IPOjkptsUZvydfVeI9VbB2HK5ZqAuQ== X-Zone-Loop: 3524b98995af21cdc3e15cf19697b182d256875d8686 x-campaign-type: default x-transaction-id: fc82399a-4f1d-4a27-93e0-74ae26b0175e x-swg-uid: 01-faa53deb-8804-4052-9cd5-cde350502cd8 X-Mailer: Sweego Message-ID: <1792164866.8631fc262581453bbf619ec5b2062170.1a14559aa020008425@vates.tech> x-swg-bid: 1792164866.8631fc262581453bbf619ec5b2062170.1a14559aa020008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v7 2/4] xen/riscv: fix A/D bits in Xen's page-table mappings Date: Fri, 16 Oct 2026 17:34:18 +0200 In-Reply-To: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1792164601; l=7908; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=X3nR2IyT1QGAA88KY+QhGva03mGk51wIsZ54wFGrE0M=; b=Zf6myBrnbaP6fH0g1Vp30SbVVH/7sFrfgi4Ng3APtX75mzf91GuiRdZJydihc3DrVAGvDHWBB gFj/7EfNcCrA3INnaq2OWhm0Ahd3tmoJviFcXzHwNvDo2TWFNGNK8U6 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: 1792164866122 X-purgate-ID: tlsNG-c1860d/1792164874-CCD7087B-21287097/10/73395122804 X-purgate-type: spam X-purgate-size: 7910 Xen does not handle page faults caused by clear A/D bits, so it presets them when creating PTEs. pt_update_entry() does so, but three places build leaf PTEs directly without going through it: setup_initial_mapping() (the boot page tables), check_pgtbl_mode_support() (the temporary root entry used to probe SATP mode support) and arch_pmap_map() (the fixmap). On implementations that fault on clear A/D bits (Svade), all three fault on first access. For check_pgtbl_mode_support(), the fault is raised by the instruction fetch right after the SATP write, before any trap handler is set. Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in all cases for consistency with pt_update_entry() which sets it at runtime. 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 check_pgtbl_mode_support() to use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also carries A and D, a reserved PTE with A or D set would no longer be caught. Mask with the V, R and W bits explicitly instead, and factor the check out into pte_has_reserved_rwx(). Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") Fixes: f89e1a170299 ("xen/riscv: introduce asm/pmap.h header") Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko --- Changes since v6: - add a 2nd Fixes tag, as arch_pmap_map() was introduced by a later commit. --- Changes since v5: - no changes, already reviewed and waiting to be merged. --- Changes since v4: - rebase on top of staging. - add a missing changes line in "Changes since v3". --- Changes since v3: - rebase patch 2/6 which modified wrong indentation. - change commit message to address review comments. - rename pte_is_reserved() to pte_has_reserved_rwx() --- Changes since v2: - add fixes commit ref. - add A/D bits to PAGE_HYPERVISOR_RO and derive PAGE_HYPERVISOR_RW/RX from it for consistency with runtime. - introduce pte_is_reserved() to factor out the reserved-encoding assert shared by pte_is_table() and pte_is_mapping(). - reword commit title --- 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 | 33 +++++++++++++++++---------------- xen/arch/riscv/mm.c | 11 +++++------ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index c8bb334b85..f9e59e61de 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -46,12 +46,12 @@ #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 | PTE_DIRTY) +#define PAGE_HYPERVISOR_RW (PAGE_HYPERVISOR_RO | PTE_WRITABLE) +#define PAGE_HYPERVISOR_RX (PAGE_HYPERVISOR_RO | PTE_EXECUTABLE) #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW /* @@ -161,31 +161,32 @@ static inline bool pte_is_valid(pte_t p) * X W R Meaning * 0 0 0 Pointer to next level of page table. * 0 0 1 Read-only page. - * 0 1 0 Reserved for future use. + * 0 1 0 Reserved for future use. [1] * 0 1 1 Read-write page. * 1 0 0 Execute-only page. * 1 0 1 Read-execute page. - * 1 1 0 Reserved for future use. + * 1 1 0 Reserved for future use. [2] * 1 1 1 Read-write-execute page. + * + * So if V=1 and W=1 then R also needs to be 1 as R = 0 is reserved for + * future use ([1], [2]). */ +static inline bool pte_has_reserved_rwx(pte_t p) +{ + return (p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) == + (PTE_VALID | PTE_WRITABLE); +} + 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(!pte_has_reserved_rwx(p)); return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID); } static inline bool pte_is_mapping(pte_t p) { - /* See pte_is_table() */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); + ASSERT(!pte_has_reserved_rwx(p)); return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); } diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c index 06f0406781..6f7dcd10b2 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -140,19 +140,18 @@ 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 pte_flags = PTE_LEAF_DEFAULT; + unsigned int pte_flags = PAGE_HYPERVISOR_RW; unsigned long addr = is_identity_mapping ? page_addr : virt_to_maddr(page_addr); pte_t pte_to_be_written; index = pt_index(0, page_addr); - if ( is_kernel_text(addr) || - is_kernel_inittext(addr) ) - pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) + pte_flags = PAGE_HYPERVISOR_RX; if ( is_kernel_rodata(addr) ) - pte_flags = PTE_READABLE | PTE_VALID; + pte_flags = PAGE_HYPERVISOR_RO; pte_to_be_written = paddr_to_pte(paddr, pte_flags); @@ -197,7 +196,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 Fri Oct 16 15:34:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:34:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452237.1667073 (Exim 4.92) (envelope-from ) id 1xHjxB-0005xm-Vy; Fri, 16 Oct 2026 15:34:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452237.1667073; Fri, 16 Oct 2026 15:34: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 1xHjxB-0005xf-Sw; Fri, 16 Oct 2026 15:34:41 +0000 Received: by outflank-mailman (input) for mailman id 1452237; Fri, 16 Oct 2026 15:34:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHjxA-0005vX-Sj for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:34:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHjxA-003Lqz-99 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:34:40 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad243ee-8faa-0a2a0a5109dd-0a2a4504a44a-36 for ; Fri, 16 Oct 2026 17:34:40 +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 6ad2440f-b57f-0a2a45040019-b9ff1c22aa49-3 for ; Fri, 16 Oct 2026 17:34:39 +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 1a14559ab900008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 15:34:26 +0000 Received: from leducb (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 3A33482190; Fri, 16 Oct 2026 17:34: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: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=O1iw31PjB9Hki7H+M4S0HFTKSFv8k+gHvipzgRgmyow=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=OZmnkUWYvF3feSd5Tl5ukx2rruvo+bTBMz+L4tKmr830vPLHnr2JMqHsO2P1kM4fD736FLBn8 SF8wa34LxnvdcbgvgCw9HfD0E14ZKWqAp3i5wo6fPrLjsZK64LBdavsGWdjwtZdioZh2mYCmBDW 5PCw67rjBG7ZJYMwdfMQreKhQejRNhI+BJMyKr1blUfNJHgTH8+SeVSD3yFTjYVElceRV9UlJIo LsRCZFalT4snTSuHOMP6D2YTS1doA2kCbprdbavpuryGb7sZq6I/YkJX3DcFAONxrgcqisj60v1 Ea2j+p9wQxEbRXm8RmYD3EzA/rgp1bUda3JoRPDPRynw== X-Zone-Loop: a1d4275a7722689af0e917690b65b59ccd2a6b34a253 x-campaign-type: default x-transaction-id: 048fa238-8fcd-46f7-8ed6-243c978e7730 x-swg-uid: 01-02bef059-e6b6-4d0d-afd5-79e06264249b X-Mailer: Sweego Message-ID: <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> x-swg-bid: 1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v7 3/4] xen/riscv: panic if the device tree advertises neither Svade nor Svadu Date: Fri, 16 Oct 2026 17:34:19 +0200 In-Reply-To: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1792164601; l=4855; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=eN2ifjmoqFQ0XZBkxcJg+hlp7/mIynrnz6gDFALyBmA=; b=MkRMsAyOMvDjiwpAZycWz+p6eskCQYqqDFtDc/HEJViX5gG1h2bncKqvUspeiIUAOLudnrWln AyaXVKlJ1//DZnq8UdRy7RLVoHUTGadT3ot8xkgQb/tS69QlmHji6Zm 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: 1792164866439 X-purgate-ID: tlsNG-ebf023/1792164879-C38C1B50-C3DB94E6/10/78276251493 X-purgate-type: spam X-purgate-size: 4857 p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. The privileged spec allows exactly two schemes for updating the PTE A and D bits: hardware sets them on access and on write, or accessing a page whose A and/or D bit is clear raises a page fault so that software can set them (ratified as Svade). Every implementation uses one of them, but platforms designed before Svade and Svadu were ratified, such as the HiFive Premier P550, may advertise neither. Xen then cannot tell which scheme is in effect, so rather than guess, panic in riscv_fill_hwcap() when the device tree advertises neither Svade nor Svadu, so that the device tree gets fixed. Add Svadu to the known ISA extensions so it can be told apart from Svade. The comment above the enum asks for new extensions to go at the bottom to avoid shuffling, a leftover from Linux where the IDs were macros with explicit values. Nothing depends on the enum values, so have the comment say that multi-letter extensions follow the order of riscv_isa_ext[]. Suggested-by: Jan Beulich Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v6: - drop the probe and trust the device tree, only panic when it advertises neither Svade nor Svadu. - update the patch's title/body accordingly. - put svadu between svade and svpbmt in riscv_isa_ext_id. - rewrite the enum riscv_isa_ext_id comment. --- Changes since v5: - new patch, probe the A/D bits update scheme instead of trusting the device tree alone. --- xen/arch/riscv/cpufeature.c | 17 +++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 +++++++------ 2 files changed, 24 insertions(+), 6 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 3d5bbd2228..5406fad59b 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -200,6 +200,7 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { RISCV_ISA_EXT_ENTRY(ssaia, ANY), RISCV_ISA_EXT_ENTRY(sstc, NONE), RISCV_ISA_EXT_ENTRY(svade, NONE), + RISCV_ISA_EXT_ENTRY(svadu, NONE), RISCV_ISA_EXT_ENTRY(svpbmt, NONE), }; @@ -674,6 +675,22 @@ void __init riscv_fill_hwcap(void) "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " "wire up this platform's pause equivalent in cpu_relax()\n"); + /* + * The privileged spec allows exactly two schemes for updating the PTE A + * and D bits: + * 1) hardware sets them on access and on write; + * 2) accessing a page whose A and/or D bit is clear raises a page fault, + * so that software can set them (ratified as Svade). + * + * Every implementation uses one of them, but may predate the extensions + * and advertise neither. The device tree is then ambiguous: Xen cannot + * tell which scheme is in effect, so panic and have the device tree + * fixed. + */ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) + panic("Device tree advertises neither Svade nor Svadu, A/D bits update scheme unknown\n"); + 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 2973eb13a5..b0a23be18e 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -8,13 +8,13 @@ #include /* - * These macros represent the logical IDs of each multi-letter RISC-V ISA - * extension and are used in the ISA bitmap. The logical IDs start from - * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single - * letter extensions and are used in enum riscv_isa_ext_id. + * Logical IDs of RISC-V ISA extensions, used as bit positions in the ISA + * bitmap. * - * New extensions should just be added to the bottom, rather than added - * alphabetically, in order to avoid unnecessary shuffling. + * Single-letter extensions use IDs below RISCV_ISA_EXT_BASE and are sorted + * alphabetically. Multi-letter extensions start from RISCV_ISA_EXT_BASE and + * follow the same order as riscv_isa_ext[] (see the ordering rules described + * above it). */ #define RISCV_ISA_EXT_BASE 26 @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_ssaia, RISCV_ISA_EXT_sstc, RISCV_ISA_EXT_svade, + RISCV_ISA_EXT_svadu, RISCV_ISA_EXT_svpbmt, RISCV_ISA_EXT_MAX }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:34:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:34:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452238.1667082 (Exim 4.92) (envelope-from ) id 1xHjxF-0006Ej-7O; Fri, 16 Oct 2026 15:34:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452238.1667082; Fri, 16 Oct 2026 15:34: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 1xHjxF-0006EX-4T; Fri, 16 Oct 2026 15:34:45 +0000 Received: by outflank-mailman (input) for mailman id 1452238; Fri, 16 Oct 2026 15:34:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHjxD-0006CA-Rq for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:34:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHjxD-001ryr-8S for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:34:43 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24413-e002-0a2a0a5209dd-0a2a450485b6-0 for ; Fri, 16 Oct 2026 17:34:43 +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 6ad2440f-b57f-0a2a45040019-b9ff1c22aa49-4 for ; Fri, 16 Oct 2026 17:34: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 1a14559acd50008425.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 15:34:27 +0000 Received: from leducb (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 9E01F810D3; Fri, 16 Oct 2026 17:34: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: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=h04Hzox3zgjbpcf+0P2EnIWZow6bWEDIHK8/hqyjTPQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=RIiC+bGKoUxLYNDzQpWVyDrkkK6+9GMCXws+UuhLKgqfv/S36/sCfEbzwK539hYs8WTBmq7t5 AmkZmx6LmIM107wR8ETFOnQTuNYapP0wpornJh9DEskQrhxGYRnPCf1RAEk5oSOt/4HmzIE53Nb bkTRdB1rk0sEjMiQyRp/WSp8MT+NGpUNNRkh470z/DL494YCzmmPgs19Sh0JRHcJi0Ej2cnRIfN S2qMThBeJZ2ilQ+/hxJ//VYzraGqHr3eaKAD2VSWyvMOCiwEfMP1rgJZ1dlFLf3x3EXzo+MYOhG UAPZE4qZaC6AedElNLlvUYwUafRMuGdojC7qpv7JJ9UQ== X-Zone-Loop: ea2f99a36fef2c199ece06ad51bb652b55a3a11495b7 x-campaign-type: default x-transaction-id: 72999b38-07ea-49ed-906f-d3ed2be33771 x-swg-uid: 01-6a4943de-9800-4414-9e3c-321f373fd043 X-Mailer: Sweego Message-ID: <1792164867.8631fc262581453bbf619ec5b2062170.1a14559acd50008425@vates.tech> x-swg-bid: 1792164867.8631fc262581453bbf619ec5b2062170.1a14559acd50008425 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v7 4/4] xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() Date: Fri, 16 Oct 2026 17:34:20 +0200 In-Reply-To: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1792164601; l=4824; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Mv+v4M/J3Q6LeDzmM1l8D/JPCMBtrswouZq8wEXvjUM=; b=dB2J+ksp8OeIPnH8RGrKdlHUqguCXe/dcIi1lrJJAdqjb0IP3u21G+LDV3hlta811pHQFJUpO TB5Uuc3hsU1Bw11DcRmcoXekV/cVVKib4oMX5upC22joaEvtuw1TLCS 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: 1792164866841 X-purgate-ID: tlsNG-ebf023/1792164883-C0CDFB50-A8D8C7A8/0/0 X-purgate-type: clean X-purgate-size: 4826 The comment in p2m_set_pte_flags() quotes the spec at length to describe the two A/D bits schemes, and its TODO mixes two things: why A/D are preset today (OpenSBI delegates the resulting page faults to a lower privilege mode, so Xen would take them with no handler) and what remains to be done. Summarize the two schemes as a short list. The reason for presetting A/D is not future work, so move it out of the TODO, next to the schemes. The TODO now keeps only the later work, handling these page faults instead of presetting A/D, which only concerns Svade as A/D page faults cannot happen otherwise. Also note that presetting the A/D bits is harmless when the device tree advertises both Svade and Svadu and the platform uses hardware A/D updating. No functional change. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v6: - drop the change to preset A/D unless only Svadu is advertised, as riscv_fill_hwcap() now panics if the device tree advertises neither Svade nor Svadu. The patch only reworks the comment. - update the patch's title accordingly. --- Changes since v5: - new patch, split out of "xen/riscv: always preset A/D bits in G-stage PTEs". --- xen/arch/riscv/p2m.c | 45 +++++++++++++++++++-------------------------- 1 file changed, 19 insertions(+), 26 deletions(-) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 3d195294d5..a2d81a9c8a 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -591,35 +591,28 @@ static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) 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. + * A RISC-V implementation can either: + * 1) Update the 'A' and 'D' PTE bits in hardware. + * 2) Generate a page fault when 'A' and/or 'D' is clear, so that + * software can set them. * - * 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. + * (1) needs nothing more as it is handled by hardware. For (2), set 'A' + * and 'D' up front: OpenSBI delegates such page faults to a lower + * privilege mode, so they would be raised in Xen, which has no handler + * for them. * - * 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. + * If both Svade and Svadu are advertised and the CPU updates A/D in + * hardware, presetting them is harmless. * - * 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. + * TODO: Xen on RISC-V currently makes no use of the information that + * handling such page faults could provide, which would be useful + * for several use cases such as demand paging, cache-flushing + * optimizations, memory access tracking, etc. + * + * 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 the page faults that occur due to + * unset A/D bits. */ if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) e->pte |= PTE_ACCESSED | PTE_DIRTY; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:45:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:45:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452270.1667091 (Exim 4.92) (envelope-from ) id 1xHk7i-0002GH-8b; Fri, 16 Oct 2026 15:45:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452270.1667091; Fri, 16 Oct 2026 15: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 1xHk7i-0002GA-5b; Fri, 16 Oct 2026 15:45:34 +0000 Received: by outflank-mailman (input) for mailman id 1452270; Fri, 16 Oct 2026 15:45:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHk7g-0002Es-D4 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:45:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHk7f-001NUb-FO for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:45:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2467e-8faa-0a2a0a5109dd-0a2a45038696-40 for ; Fri, 16 Oct 2026 17:45:31 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2469b-fae8-0a2a45030019-d155802da81e-3 for ; Fri, 16 Oct 2026 17:45:31 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4980fe6b3beso7506905e9.0 for ; Fri, 16 Oct 2026 08:45:31 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1bd91c55bsm141831455e9.0.2026.10.16.08.45.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 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=1792165531; x=1792770331; 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=wBJ+Wz7x0TcRN8pGJ6i0/qelXS6Ni6K4fvhyr6lhNUM=; b=jc97AurgYj6lt1XlX5NLUKcQkJQvt6Sb/8c8720RtwIUHrFzxbxWuaf5+G+OC5TQXl htPILUy3NAAMFuxAmT4W32bM8HmD6IW11bKJKBJyg6exDWERMO7xFtYOSzB6D5hnWMT6 YEPmtKVdpVm4OJitA/b71iC9xl320Hp8B96Qc/hqvonupGdlIeW0TePdQC55h+u/aEfB Q51foiIdgRE5bjE9PoB1JQvD13Axn8jS8lO2/XwydJt6aLa02FSHkQ1qlNTSx2IAf/ca BEBRiZhKdRrJ6b+RTnPVOlqf+5KYK/RQq+ZDoZkMzdyh0jylFlWQV1qQ0sa6kb/6y9wX /+og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792165531; x=1792770331; 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=wBJ+Wz7x0TcRN8pGJ6i0/qelXS6Ni6K4fvhyr6lhNUM=; b=F+ix1sORlJArkgD0OxBGk5hNoo6upeluKV3ncsZqjByfEAyRE2hD76ZgcH3CI1zRSc biHvSwveUXfnqm00nHKgpGSDNmxW+3NviCGcWtWhitHmOhQZBWgqErdcgD6G1taA4Lsu XuDz5n62eQNRmKdI5NmTAjqJk3aojkZIeObVDW1dlxQu5aA3zFxnlfUgW4Wfjr7BGj8m WH2t7YmI0jqYlUzI5GnRrY8/dhcgDWrXaTvfWLcsAKXLMxE59jqObX/Jkm7wRjH/80/8 DHoDa6g7k5OsXQ/6NBg0yG+dpZlKxgfSu4BE0uv1B5SZMBzAG9TJTqJIFADGz6l+MUm0 nADg== X-Forwarded-Encrypted: i=1; AKwUvByqUxvz4ypKzzMWOmacGC7XqRsK2QIeVSwwgtUt0HeGVByvfjDk7AB78nkX6lP5/OiXgYN3Dy85Nhs=@lists.xenproject.org X-Gm-Message-State: AFq9FYLKpNrNA/o0RAvXqAiL4M8zlV2mo3Ti+iAO/itI6brAIKngK9pA R4PaaO4H83C/LhJ3UJ2DvJDzx9y8GG+MvQGTnG0Vh+r1zFDGwFsmyRH9 X-Gm-Gg: AYBFou3oEQfTXs0Kfj/mtJlUoMrQER+CXhzeuyWeh7zkpALydDrU89mL43+lTxwRgmj cVr6HHXLqUf9lbiVkRPXCf03ImjLq10BcNMXDLzNbrlFznRrceNYEERp4NNvQ7WznQ9ZaccA+0H 96T5r5YYYI2kYJ8ddiDKHuFnUQD425DJT3piCdjEZ7blEkYvoCfoxgCNBSsn5m43IsMwf5r3JhF cW2YLJyzL1rnadZ118CMUqmJoR3vAdJvFPM1vD++J9So3MTYNVEX+pZc3sI3fVmFkHDosTA4CDI xvapt+2D/hDk+7dmNblkHWN00BE6UBzmbvE81D4r5OB070slai9kVueTKrblHFFVrokRKsh5j7G Iji5pmpXC305lGArGQgYL/OVEDCnJESBjKCehH7fJ13zUb+MrZazT9U76W+RJQwWcFpMTx3ClAm pJZ2xWDXdMWztngdj3no6/AywDQ/vhJHTDF2H/g2ekmHrAxH88iHy3cOZZWVV3JsRcIgQr/K3LS bgxwpjHia9Y4khLLIwzSQmq4PNS5mQ8KWXGJGdGtQVr3Zc= X-Received: by 2002:a05:600c:a00f:b0:4a1:6d2d:d8bb with SMTP id 5b1f17b1804b1-4a1d760522fmr3635415e9.12.1792165530718; Fri, 16 Oct 2026 08:45:30 -0700 (PDT) Message-ID: Date: Fri, 16 Oct 2026 17:45:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/4] xen/riscv: panic if the device tree advertises neither Svade nor Svadu To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1792165531-772F54E9-1859EFD0/10/78276251493 X-purgate-type: spam X-purgate-size: 1427 On 10/16/26 5:34 PM, Baptiste Le Duc wrote: > p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when > RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. > > The privileged spec allows exactly two schemes for updating the PTE A and D > bits: hardware sets them on access and on write, or accessing a page whose > A and/or D bit is clear raises a page fault so that software can set them > (ratified as Svade). Every implementation uses one of them, but platforms > designed before Svade and Svadu were ratified, such as the HiFive Premier > P550, may advertise neither. Xen then cannot tell which scheme is in > effect, so rather than guess, panic in riscv_fill_hwcap() when the device > tree advertises neither Svade nor Svadu, so that the device tree gets > fixed. > > Add Svadu to the known ISA extensions so it can be told apart from Svade. > The comment above the enum asks for new extensions to go at the bottom to > avoid shuffling, a leftover from Linux where the IDs were macros with > explicit values. Nothing depends on the enum values, so have the comment > say that multi-letter extensions follow the order of riscv_isa_ext[]. > > Suggested-by: Jan Beulich > Assisted-by: Claude:claude-opus-5-5 > Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:47:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:47:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452278.1667099 (Exim 4.92) (envelope-from ) id 1xHk9Y-0002z5-J6; Fri, 16 Oct 2026 15:47:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452278.1667099; Fri, 16 Oct 2026 15:47: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 1xHk9Y-0002yy-G4; Fri, 16 Oct 2026 15:47:28 +0000 Received: by outflank-mailman (input) for mailman id 1452278; Fri, 16 Oct 2026 15:47:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHk9W-0002ys-A9 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:47:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHk9V-003Nn9-N3 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:47:25 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2470d-e002-0a2a0a5209dd-0a2a45039244-0 for ; Fri, 16 Oct 2026 17:47:25 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2470d-fae8-0a2a45030019-d155802ae03b-3 for ; Fri, 16 Oct 2026 17:47:25 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a1635f7c89so878175e9.2 for ; Fri, 16 Oct 2026 08:47:25 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1ce33155fsm40400185e9.4.2026.10.16.08.47.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 08:47: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=1792165645; x=1792770445; 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=jEOTIyI/7iHiVCiArbx4fo1wrJjwQQbrWcpJTd/CzYE=; b=V6RzvHcOpTF9+NIFsMj+MiBQEKgRhSh0+Ylp5an6v8roO/lErRQlhb39SOn0tG1Nsd HIw9zX7qifNu/0BduTWGCkHf00HZh7pupTlYSYVytbDNYrN67SGqFsk9oivUYwVuxCHn YHuDPlToe1pfK6GwZvS9Zj9cLGBdGNFrGU6+5BVlkPSWTNiKeVMAfx0/4K6wkC0Ibob6 M1Lw9Uhiv4HSpDXiDzDVHp3UYy9cLhKB6TJwNEUO4sxSx0LvqB4XOA4VVTHwI8a7zrvl 1UWLErrgSnpLm/DAb7Ztx3Nlkf8k7+WUOZP6dPPegbqOcz/+vgeZvG+RcTtThHrCD0IB v6ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792165645; x=1792770445; 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=jEOTIyI/7iHiVCiArbx4fo1wrJjwQQbrWcpJTd/CzYE=; b=ohF+mcQdFMiZqzLsyYlkFbWSsFO65dOPX4+7Ct2+K/p3JFqU2gPJ4RLI73EoJkunVu gimseqIG/pQDNRgLeioXBgu+XzbaSG0xeX3ayzHtMrr5PHgngYFIXdJi15koTi9KAXev nYMG3dz/Szih6VJ4Jng/ZJ1ySHsC34jhIXIj6fENCAa0C83V95G/K38V+Ol+S9SRyTdr 2/PmY9DLTXz1YybNTa2y6gHcBfp07sJpbzLPgocwbm0tPQjUXzDpXYqtawm9aMY5X98+ FvD3WpABSRGm0I9yHsGQ763vUuw4KU24hrB0ZC2KkB2e9cF/Ce7wlWBgR6odT5ic7AwD r32w== X-Forwarded-Encrypted: i=1; AKwUvBxyyY2Joc96F46g/EBo/S2OFQDUUCM4e3U8OMi10YGXyDpm9FtBow6Co37Pe/vhM4G6yp0ABrLgC3I=@lists.xenproject.org X-Gm-Message-State: AFq9FYJIbgn/YbJM0yZwkr4IXe7AUdhTWPzCLrXb/RQfcrDbFN4CTehK 0+xagr+x2AAKHIg8yCay0A4anGIy4xOR1l+oDey5T5sCnnTiPupGBX5L X-Gm-Gg: AYBFou0Req4SkvSE3D2gH2LtHdi62EzoGVdelxaWIFyW52cq06y88HllV9JZQK0Ws81 vMCqW/a5q+gFdKgNUL1EmY0LmNguCRjFWwwn8R4TgV1xl+6OGjOHPmut+wT97955fUvjLaJ0FcI 2dULWQfKaD7D6pn/gUz2/MX1/R6PUS9Bd6IqIGWen8I9LQbYCZwFvhOO1fZtKR7yw/YcGJLxE5q Np8XA+Q5ShpUZXMy3d4u2ixpSvtJ3gdCMDDOQhzqIUPp+iM/7pvJNfCzISJQfwF99lrMbz93mBK MF+/VNF8/JRk0iHhRUIsaw+uciqqtvIOMGj+dyDc/fR0+QC9vuUbT5Y5hfyDdnBAADZKtuNPhdb hWNpyPsYRPzh7cZbyMxLWzSI9zzSfT8kez6tZ41TiPkuvQm5g2vRobapjN2Y6CLSkFWYcsr+045 zrAJyOcszgcpkFV7yX4RS9VqFOyOoP3NYfUUz00kv3jLdrPxoKR1Bb7/Bko2K966VNdYEPWayMQ WjF+X00sUmlnjtUdFiMEvb5P387fEnYgsgfIVXiFFGqNx4= X-Received: by 2002:a05:600d:864c:20b0:4a1:cdd1:5144 with SMTP id 5b1f17b1804b1-4a1d7616470mr3210175e9.21.1792165645121; Fri, 16 Oct 2026 08:47:25 -0700 (PDT) Message-ID: <016b34db-7c9f-4c85-bf87-2d2d95394e98@gmail.com> Date: Fri, 16 Oct 2026 17:47:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 4/4] xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164867.8631fc262581453bbf619ec5b2062170.1a14559acd50008425@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1792164867.8631fc262581453bbf619ec5b2062170.1a14559acd50008425@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1792165645-75A814E9-69E463FF/10/73395122804 X-purgate-type: spam X-purgate-size: 1072 On 10/16/26 5:34 PM, Baptiste Le Duc wrote: > The comment in p2m_set_pte_flags() quotes the spec at length to describe > the two A/D bits schemes, and its TODO mixes two things: why A/D are preset > today (OpenSBI delegates the resulting page faults to a lower privilege > mode, so Xen would take them with no handler) and what remains to be done. > > Summarize the two schemes as a short list. The reason for presetting A/D is > not future work, so move it out of the TODO, next to the schemes. The TODO > now keeps only the later work, handling these page faults instead of > presetting A/D, which only concerns Svade as A/D page faults cannot happen > otherwise. > > Also note that presetting the A/D bits is harmless when the device > tree advertises both Svade and Svadu and the platform uses hardware > A/D updating. > > No functional change. > > Assisted-by: Claude:claude-opus-5-5 > Signed-off-by: Baptiste Le Duc LGTM: Reviewed-by: Oleksii Kurochko Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:49:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:49:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452286.1667109 (Exim 4.92) (envelope-from ) id 1xHkBP-0003kn-T4; Fri, 16 Oct 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 1452286.1667109; Fri, 16 Oct 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 1xHkBP-0003kg-QD; Fri, 16 Oct 2026 15:49:23 +0000 Received: by outflank-mailman (input) for mailman id 1452286; Fri, 16 Oct 2026 15:49:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHkBO-0003ka-K6 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:49:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkBN-006NcC-TV for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:49:21 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24770-e002-0a2a0a5209dd-0a2a4504b49e-26 for ; Fri, 16 Oct 2026 17:49:21 +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 6ad24781-b57f-0a2a45040019-d155802bddda-3 for ; Fri, 16 Oct 2026 17:49:21 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a1880e1bf1so1043185e9.1 for ; Fri, 16 Oct 2026 08:49:21 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48dfd409989sm6256682f8f.0.2026.10.16.08.49.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2026 08:49: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=1792165761; x=1792770561; 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=YOUA7dgnOp6ZkpYFCtXmRE5oNWg55i1qEiDZZmT39lQ=; b=MJXX8FOF4998zp+yXUqxctgr9kyofyUxX4K5WaYuJ2EHz9GzVICTe2ip12Lvi0R/+k rae5lRVSNFf06mq27MM8f8rld+H941Gkny1X5JoQLnpVod4j7c9+5IDph9Uh5P0EV591 DRIgbAuXkMAWGVOD0aHo78OWHoEagnpejbed4+MJyHkvJ3g9vpjEvyZpLi7H+b/E1m+I Q7z0wF8hDqtiaek6LqjdsVeX7XtYHK912l7hjdLH8XlmmY50eR/KeDm0pQRu4cOjtB8+ AB6lHPFMhG2XSxYf6u2WvtKRq/mX/VsPsFbuCZ0LyOZRoEFtH5ELL5jzAUk3QpGaZ/C9 4ncw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792165761; x=1792770561; 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=YOUA7dgnOp6ZkpYFCtXmRE5oNWg55i1qEiDZZmT39lQ=; b=TpHecEeDvKdwB8j2OwoOUGOKsbUXN+92l9hd/yDSDfWSeRk548QFiQ5wTgtCnxYMsA BmRnXKB08BnoFT6z9M8tG/EfK/ENZB3Ow9tKUaIvh2ZBOz76RFF5+1IRGsaviNDcoZT5 ZF6N3TEGn/BdAtYRpbPT88dqTbhtHRAYvvKERDEexcUyaO8s+oGglrDK8XjD99JByh5S npf2B63p49dF5AibiGCpAttqmpTzi4oGZCHBrbAwbVfkm5I7y/phWbFqrmawQdV68EDi V8UtfmpQ+He3dzlgNEVwwdT97BVAidy5bPhD0E4b/cTL+07MPslbntQ3yjd4AIHhiuI0 E7oQ== X-Forwarded-Encrypted: i=1; AKwUvBy661O2nV33MAs7s8MQOmUFfOHQc/Gtnqov4x5OnAmsvAkLDNo2mYS6js+da7ehE89O/YfdsR8QR3U=@lists.xenproject.org X-Gm-Message-State: AFq9FYL28fU4cJB/mzT0ubJtksMLFDwUu8CVsci0r4LLoxVUC+K+Dpax KElpRqViFmLIAEH2NtFWdOY/QMA0pcVYQN7Fe6xhNTdn9OBL8jvkd0ag X-Gm-Gg: AYBFou0NqhxViVDjVNvz3CAMJW9TEnwzwVr0noLJ2tLbT1qNHCk8E2WK/n90bI5CbXh a0fTofm3EdX0cOblcVzR2N8uEaSjDqlP1RHAbZDnbLZXR/pfYomyxdPoKTgx7Wo65APP0k21c0A 3Of7LK4aWwe1ZVgQztdwl/NyVzSyLraOfqStu2Bi0zX9+JwpchFI8mEmyIgAUTpMf9j9Hb7dKOQ UXa+IzV8OZe9f7pxKnW0FJ+jfW2IRbWG+0J/DdaMDmHvdBgF5PVAE2+ifXZX/mwjvfXNtmT/wvO 7zH5H99aC+FkkAs8whpDR7FfEWmlPoTxVcnmla0dOmNBRMW9F6kz4GPJpAjmcEqS/sbZywZ5bfX e2/TRwyVxIUvUe36Eyzv4Td47KMk3NV1MafuCyf4NlFBIHVkJAVGBBdlQzokEZDO1fPpKQHe9eQ 0qQNhb+hX7ccqAclvCgvUkkwB/A6VaPD8gZwy5xXlG4BRLojE9DQZPW7JJi5Owgw0tiXrkFZ42X KLWJFgnH14DSYQufjddWUgX60rtwPhKzqYV3PtcahUEfig= X-Received: by 2002:a05:600c:870b:b0:4a1:d0e4:2bc7 with SMTP id 5b1f17b1804b1-4a1d7608614mr4599435e9.15.1792165761231; Fri, 16 Oct 2026 08:49:21 -0700 (PDT) Message-ID: <68fac39b-1af7-4790-99e9-673229b1032e@gmail.com> Date: Fri, 16 Oct 2026 17:49:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/4] xen/riscv: use pte_is_valid() in pte_is_mapping() To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164866.8631fc262581453bbf619ec5b2062170.1a14559a8f00008425@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1792164866.8631fc262581453bbf619ec5b2062170.1a14559a8f00008425@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1792165761-C10DDB50-DBCDCA32/10/73395122804 X-purgate-type: spam X-purgate-size: 753 On 10/16/26 5:34 PM, Baptiste Le Duc wrote: > Use pte_is_valid() instead of open-coding the PTE_VALID check. > > No functional change. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > Reviewed-by: Oleksii Kurochko > --- > Changes since v6: > - no changes, already reviewed and waiting to be merged. > --- > Changes since v5: > - no changes, already reviewed and waiting to be merged. I don't know if it is useful but for such cases I'm using this way ...: > Changes since v5-6: > - no changes, already reviewed and waiting to be merged. ... instead of providing separate changelog items. It is saving a little bit space. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:55:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:55:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452296.1667119 (Exim 4.92) (envelope-from ) id 1xHkHH-0006vn-HZ; Fri, 16 Oct 2026 15:55:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452296.1667119; Fri, 16 Oct 2026 15: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 1xHkHH-0006vg-Dl; Fri, 16 Oct 2026 15:55:27 +0000 Received: by outflank-mailman (input) for mailman id 1452296; Fri, 16 Oct 2026 15:55:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkHG-0006va-Np for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:55:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkHG-003OzI-4l for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:55:26 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad248ee-e002-0a2a0a5209dd-0a2a4504c7e4-0 for ; Fri, 16 Oct 2026 17:55:26 +0200 Received: from [209.85.128.177] (helo=mail-yw1-f177.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad248ed-b57f-0a2a45040019-d15580b1e494-3 for ; Fri, 16 Oct 2026 17:55:25 +0200 Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-8b06c0794cfso944527b3.0 for ; Fri, 16 Oct 2026 08:55: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=linaro.org header.i="@linaro.org" 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=1792166124; cv=none; d=google.com; s=arc-20260327; b=TIiMO5lEN1dmHv0xtD+/ErNewTqPTOrt9/3Uc12JFxhsr41PnPMZqd8TawiLeIVaiR vGhTMOEPrsL8Pl7m5AsGQixphRYApKzxhx3Mk1XQVUbkoJEsSLWagXOVAgwEwexl9ehE eXrITCVEh01MJ4VJtpRFA1sy+FUzZd9qKvWIldRGC2xNH+SADMw04JuREqYhQug90v5e f/r5GT6p0P+Z3Pqs92x1q9SzFRGMeC6JMssbuiSJ31nyMnm1WgpgiXrrQSVtUjNexGi0 B+X99dIk80ciXSbAAJ/I0QfQRTGtEEfVzTveTzwVSBgQQhbSJfLevUiBfMO5lgEmBHAY cZ5Q== 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=Z0U9nhI3/BkU5LUuDW+0BzjA0KXxkCMgNCafRerAKsY=; fh=P2rKh5AIgZyvfPXtJpShNPlxk0/V+39xpTtioqp3ivQ=; b=HhPqckBE0y1QVv8WmFiYLJLUfojwu9iQYGs5SlzHlCCpSmf6tRjTI7HTnAy/KWThYk Oncw9ifVE22nInIE9kB4HPn55OFLhnuTTwiaIOn1P6cgGXfQe+hvxs4y5Bpg7DXGLYLl l2UlQgkEDVkB8wSaDvERY1+Uo/Z5t2P4kW0LfKebwW8Q+GkxeoXAK7xZEX86QmE4dip1 U9WsmFk2c0KZANE0UyTo2PAuVrLLuOTRRApldmVUrgyz8NjS2E8N9Ss4KKym0qKVqNWj j5vDOdeSh4Txm29xHtlN34EWZCzmCoccCQbZeDS519+som1+kpmUMJ6SPnuSYhYY3EfW 2Kpg==; 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=1792166124; x=1792770924; 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=Z0U9nhI3/BkU5LUuDW+0BzjA0KXxkCMgNCafRerAKsY=; b=PC2G9ePLcBnFaVaS1WgvgaKnG1epUCpjRGOWnznO5Av2tMiuVGeM/nsL2lyOT1BioF j4/px1c1DHcTBS7zSNz6z94Xz8WSLk62/7uEjehVQ/LOdKNK4iQb5WKiMC4BobATtJg1 cq+6FdTbpNk+VW9QrAIAgXNsHihPakXYfAiwtYUu374nQGTPEKwjB9AiX0OzLmrXFHpq Sp59yHlUgZNiSF/jAfmKw4YYSrpjy+/NuWOO02jRoFR4ivBgT+UdRHO2lk++duyNmSEz zKEyCjHdfvzRq39qqF2EarUE1GuGTVqXMTFIZHoJkhpnfX3rEDMKqmFoT7pZYNgCuWG9 3A6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166124; x=1792770924; 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=Z0U9nhI3/BkU5LUuDW+0BzjA0KXxkCMgNCafRerAKsY=; b=H3CpKXMQQMJxgbuNXMXMVZuDS5x9Oh1RBFmfgdpgqCYe/3qAmiDrrXFCJU+8cFtN9C rotSQUIbf4TMGgTGI8LSVydXRfyImV4sWiNYtVuUp7G8rh0CAgIkuNK21as3NdWPyUbd XnF1TTEctVUmxaYO52zGQmErup9/incnpFJhzua8XHmP8lvW4IDmFeyk/CK2yLYkgem1 W5ajh1fpRMcUziVuiKQOI1AhXG/+13t3+N3Payi1cr2kSf/6WCXhqBBBhPLrGsXZ00qV qBje4uo6UPW5VNws4gjHZR56I4aVS5rvX+FxX8M17EPlbcynGg5mVBbMLPS+9s9PK7up OjFw== X-Forwarded-Encrypted: i=1; AKwUvBxHv+iRsLJGzAkvo1fh/AfsXobAAktxURsXRmjxQWVW+gWtIOl9G5G3MnfknfReb+x042+6XfGKe6M=@lists.xenproject.org X-Gm-Message-State: AFq9FYKMMt9ZnwXmf1p9B+gyxqk35A89Wo0wVfqHG0JfDKJrjt8AR+oY dbRSgF5yiQJ80E0+DAvbvF/4qgUof1UI7D6F6oMyk1laLbeu6ffXAy4mddzuQCsefxAgCEyfkf/ B/WgAmkyuOFf+EMW05rClwOOyPT2aA9K4r6ju4WoGjg== X-Gm-Gg: AYBFou2T8AdSrqlTnA/xPT76jPHvRh7J8y+ffZQCDqvwSdRq5cTkZK2YRVPVCrh2HW1 ZigpNHAuU7vqy2/5MAJlciRSovH0B8PD5Y6ChDw41AwHrXAfUJOCQ6Cam6MCigA+x6QV3rzAcJx xb+yoTOkvSy7N8Q6BhmGjcD4jZPbQatvxaeVkcjXfq0PTCzD7nMFakJ4BMBXZ/DQAs4aoBqnGOy BAw5O0cyDg/AXtMFCrrekopIfWDfc8+ZlGrwM2NcY3AiAT5/jpZCckH8i73k1i5gsa5crKe1jN4 PMO0JY49pcVcTfYzK+eI+NhSh0/p2PgC2GmxTyt3zTElpB3V0gZZBv/gWO9KXu/Qxc4LOvkccrK wofTAvhFe/ptH9EuENNMc0uJsNvyi/9AXmx/ogp+G+a1zt7I2cfY= X-Received: by 2002:a05:690c:fd2:b0:8b0:ccc3:27d2 with SMTP id 00721157ae682-8b0f2176552mr1755087b3.29.1792166124207; Fri, 16 Oct 2026 08:55:24 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-6-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-6-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 16:55:12 +0100 X-Gm-Features: AclHuK9skk_bQb3K0JVtLihI0jZXbPpRninwyZ9Z8NqEK-mnjl_NGcwhfVRtaZs Message-ID: Subject: Re: [PATCH v2 05/27] i8259.c: rename PICClass to I8259Class To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1792166126-514D3B50-03CDE07D/0/0 X-purgate-type: clean X-purgate-size: 330 On Fri, 16 Oct 2026 at 15:22, Mark Cave-Ayland wrote: > > This is in preparation for its use within a QOM type presenting a single > emulated 8259 PIC. > > Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:56:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:56:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452305.1667128 (Exim 4.92) (envelope-from ) id 1xHkI5-0007Ti-PU; Fri, 16 Oct 2026 15:56:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452305.1667128; Fri, 16 Oct 2026 15: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 1xHkI5-0007Tb-Li; Fri, 16 Oct 2026 15:56:17 +0000 Received: by outflank-mailman (input) for mailman id 1452305; Fri, 16 Oct 2026 15:56:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkI4-0007TQ-Lc for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:56:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkI4-001P9I-2e for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:56:16 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad248f3-8faa-0a2a0a5109dd-0a2a4507c970-36 for ; Fri, 16 Oct 2026 17:56:15 +0200 Received: from [209.85.128.182] (helo=mail-yw1-f182.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2491e-b4ea-0a2a45070019-d15580b6cc9d-3 for ; Fri, 16 Oct 2026 17:56:15 +0200 Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-8b0e21048f8so977767b3.0 for ; Fri, 16 Oct 2026 08:56: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=linaro.org header.i="@linaro.org" 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=1792166174; cv=none; d=google.com; s=arc-20260327; b=EMcRtxKJB6u1vN6V12Rgo/GSZaRL5y4/Q1lpB2FrjK6hwHD3EYfV3HfkRLIZaVMwqt qpHs0w4dr1URK4NGHBjADZp/QSxRNVAlB8HOA3xr9PRCWBEIzv4t6C/DJ2cHGvzXBsWf XbNQixS7v6xn9562BZvWi8fvvb6807piTM8l/eyCQqxfKFd6UjHm2I8L0PCwFk/ApoUE B1ATgnu/uW0vGv2J0KrjUEK+su01v//rS01x4PUdoNINeIp5ZKMROj46dPLjQ8duf6sq FQ19dSR6EZgUE1fAY5I121VmO8zW6cl5Z83Zgjn0JtStuFN9CR2G9T5d2MMnYAcOdQOB pR3Q== 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=LyGTEQn8TvpSDs3sbo/pVW3eD0AVPEzIKc7OTWsb7K8=; fh=Iw0Q9aK5H2fVDFR6XeLQ1T89x2FAfz8yIySiIH8CsJ4=; b=h+LQZRlWDxauud/A1jA4l6AxkZleTB4kMx4TyKDSNiVX0lJRQ8B3FG8Sbj2hUIppgb 0kusT4zo6tnWX8800iS7rW6hdmY9iW4fZ+UFK29TigCrHTaYFpr88iSB3SqJ/ZkaSv+y Zh+lN4LKmkOjikIfx7naD73+FjdKnvBKugEdWMjziDpSTyz+iGZ9LhXzJRtHSpzDnfkT M3MiqPlPllu8wriMc4ZGssuM1Myh8TiPghYri1R55YedY+eEJEqhlfCC1Dmja3bnnXUZ nH+XlS1whZd1m8sK5bmqcrnWNVs0flpAPNTe61kMmQm9FOzgYibewQeJg4PCsE/iSKXD sW0w==; 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=1792166174; x=1792770974; 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=LyGTEQn8TvpSDs3sbo/pVW3eD0AVPEzIKc7OTWsb7K8=; b=FQOR6V5wxYd4zwBuNQY6PCH2M0KshLHANM5qVEm9j0B6+Bc/Dr9pEGu/8ioS5v1ke7 9NnSIqzZktoMQdfuLy48+z7OCanZNs83pqTqZhaJk0Y/SC//tnfeq9XbE+kfa85tJdcC V/EHkWAVMK0M12vD/K5xd9LWY5SPh8Je2ZiC8M4xKbHQ1iAoskIgFh5LuDqYGrpHIQsq Sd2VDXacqA+Li4Jb6YmBhz57f2IqJkKao5UoOslVftmI8jg6X4QQTMPLMf2KVUcqtDSA tbMkG8sO0xm25IW1Zmvb1PccSSbSmdakQs95bfW5YkuXBWCJWpjxy5JSNcLBhCyp5QmV /Tjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166174; x=1792770974; 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=LyGTEQn8TvpSDs3sbo/pVW3eD0AVPEzIKc7OTWsb7K8=; b=A24lEo3kM5jk9SfpT95NCmKwKXR7TZGTSCuOKIKkZ93du2gJVXgkTzEbF4scni1fQx 7VXArDfTiPAzGuuflmeNPZD49YLpzO/SaifFGxEbo3aRnzEVG0dLu9LmHSrDGSc6ObQY uOEoUOtx1PXOyKg3cJtqqkCvSkNp5XrsZ7ubkW9Eh2Tbkk6XS8/nZhZErTtJcHXdrx1S EamqVvjlZn8Mu4JuSwAP6sRlxGrruBtAnO6BHpt0wsxZgK96mnkHI6BA3ks4K/ZfL1px PHD1muGvpjUEd0ihbRRk6vTTAcHkwRoYyBB8xav+MeYTTvMA+eGQsHtQq+l2TtEfQC6F angg== X-Forwarded-Encrypted: i=1; AKwUvBxg/pgvMkLIbTstOuoGs4O6SQITEkqVsYw40uvEBiZqQehna78svdoevzbZI1/cEYHD7he3hDXtoYs=@lists.xenproject.org X-Gm-Message-State: AFq9FYI3Q1f6dADPjT3NXaW7tQVI/B6iE9HxKzxc+QyIsksQlcLvascw J+kdAbexvaZTD3Hev9p+KJ9PPCzvjKMEswtAcbTUDgYS35ZMCFtjsTe2fcz1vULZB1fWoHhk4I1 oFcWqfwVrJO/DlUVMKsPyZjT1w2JXLyywPGckJcB+bQ== X-Gm-Gg: AYBFou2OigGG5Q+jZ52f6jgGK/jBWFVtWuR9Fk3mrnkOcYuJ7UMYWbOEZK/aQ++QJ96 FPqKf/XdVsbqqMnv1Kok2PV32xgnwhfKk3fjexyBYP4zMmWI+70Ya+42RiKRl/Pk4s9UBbLMaAi +sbOIVTOjsoocOe8+YwiAz4ts2WXy5l5shh8O8aTd/E8XV8uszuRDcoK0n7u2DIxr31cnLmnqGe MDLLncShmDlxZKU+OYzZ5ivnIXOUS5Zwf7eqVGI71OQECIuePs3tet5mcVl9j40Hth1EkKmuKFS 3WMEaOTBNqZqDijsd2W7qQER1/zRHJ0GmXBTPHgh7Oj5U2NweSNl4auihkKYAjXTNx0V80sTeWi skeGjHkn9yx/Gjs2D73VdOYX7r4xbH9yMjD7K/r9ApZKizvkGPA== X-Received: by 2002:a05:690c:4d84:b0:8b0:8a9c:fac9 with SMTP id 00721157ae682-8b0f2170e34mr1713327b3.28.1792166174293; Fri, 16 Oct 2026 08:56:14 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-7-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-7-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 16:56:02 +0100 X-Gm-Features: AclHuK9MHRDi7s52R0estk1KzgTugvCrprtO3xo5sNZ623bTnalBpp4C5HsLsLA Message-ID: Subject: Re: [PATCH v2 06/27] i8259.c: introduce TYPE_I8259 device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ef75cf/1792166175-358C1AE4-60581A2B/0/0 X-purgate-type: clean X-purgate-size: 388 On Fri, 16 Oct 2026 at 15:21, Mark Cave-Ayland wrote: > > This device represents a single emulated 8259 PIC and its associated class and > ensures that we can safely embed the device within a container device. > > Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:56:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:56:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452312.1667136 (Exim 4.92) (envelope-from ) id 1xHkIj-00083g-4S; Fri, 16 Oct 2026 15:56:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452312.1667136; Fri, 16 Oct 2026 15:56: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 1xHkIj-00083X-1X; Fri, 16 Oct 2026 15:56:57 +0000 Received: by outflank-mailman (input) for mailman id 1452312; Fri, 16 Oct 2026 15:56:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkIh-00083J-9V for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:56:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkIg-00Cr0W-Mi for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:56:54 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2492f-2eae-0a2a0a5409dd-0a2a4507aaba-20 for ; Fri, 16 Oct 2026 17:56:54 +0200 Received: from [209.85.128.176] (helo=mail-yw1-f176.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad24945-b4ea-0a2a45070019-d15580b0cdf2-3 for ; Fri, 16 Oct 2026 17:56:54 +0200 Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-8ac4806e210so778437b3.1 for ; Fri, 16 Oct 2026 08:56: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-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1792166213; cv=none; d=google.com; s=arc-20260327; b=PtnFFlmRV6kC5m1TQveNoflaOH4jrQUz2kF7+YmjkfpKUF1jlnq0SqqoXLrWw3spt9 wZ9D9tY0rWxzfrNnwakzgqwdI4eSCr/Kn3CpkhxfCMWgdTjsL8++3kYeKof+DOX6ozsi KGSqKofVBKNNm6t3erOXklDmDW1Q4vC9a9g6NokD6VupSozZfVuOdDHNKdSbtToSKWiM 3Jg9+RyGJGGeMdXqWAzlMHlGIE9QA5f56xhmAUFp1qPDo+8RWYVk4JSwYFOUuxAjKs8C ikECu0a3p80GQEFltgojPDEilxYmXKYN5gEV7al5EO1nwACezw2wHWDRVMPULnwi1jHP jTYQ== 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=1ExK9j+YPbSPC7sfcOHKaCgU0m9CHR8eATjYSF7jCME=; fh=uyndmGwmaAdwu6L4sh5AvRorg/U5mSgxfZGhdZs0s1k=; b=iYwC8qqQwV5vZcxXCIb95yyHrhs/cONoMf7PYOcFBCaMtnuchyOF4QXVk0CkFawjJQ uZPrIuLb7NKs9GSZiU+e+zbEqGxkblEXYNlYNwVI4A9rMAv3ONSqscnqnbR/0wNrt62r eVV2YEr21FayloI43R8d+v1StAn9j/T8BHTUB+O+k94A2d0+Pstqh2CVum+a7a1uhQYv omf3vsWTHIdLN5w4JmGpWVlyQa8LaSHQAfeUvsF2jGn9w7iIUdlvd0E1yFoKi2GzsfcR dBvX7sze0rrnuuTXGzpcbgCVz1XnqzRRKK82VHbtChH2otTKq/xmQZYz7c2sBpDJD3pq ZHRw==; 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=1792166213; x=1792771013; 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=1ExK9j+YPbSPC7sfcOHKaCgU0m9CHR8eATjYSF7jCME=; b=u3bymnjtkTFtcJkHhMRMIiClX9GkY98E7jHR+Ws36G1EHXpiJJu4zJiXiFFH4fIoaf F1AIlQa2Xznf6D6UNjSksUvq+SZvaY0Z7I0G1T+Y3j3Z/UfiCn4KM5tAliSZT64lBn6z MSUpp35yORwo0mWsAeXfJbulyx88UGieIoFuqaa/XMkiAH958LJbuJkiOpKq1gURLnss Kvt+k+tvwdiy8QN+bJDIJzWsb120YxEAM6qkDVgMT/89msZS+qS5TYLI3kTeeYjdB+lL tjbT+vJ66reLq4IyGExxGJUVXRkNtbwxt8ocMkDXIdygG8yx92eHXRKvTBhPTqpeOpHy 4VFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166213; x=1792771013; 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=1ExK9j+YPbSPC7sfcOHKaCgU0m9CHR8eATjYSF7jCME=; b=MvC7fbUbKxP7f499A9fbqtcCrdIr405QxIy7+E/MbLjdHDzC/hV/0kwmieUwE3cjZK YyPajIH4R3FlTVE6hohHYW7dcBNKB4wJYCauqg/PjZJRp0W4hjwLgUaCaze0nL5hiH3V yKCdJPHSgGoOzbxaiWRBRwMTHXuoDOab6q8aKL85SqkBH14PIRDm4Qmy3D8LncHAyPwx BPm1K7pYHiwn8MilCWZ1vkRnKC60K2iIWoKRsggTsadOQng3XUOIZ3CBi0P9+AYLLlO9 yOXbqYtlEcMnZtyiJ1MwDAUU7xiPlp467K7fJU9a8ql50QUhNtjRlVcH1YLqe8bIfJJB 7kqg== X-Forwarded-Encrypted: i=1; AKwUvBzCHoOhQjZuVUoYuafMfOdWK2uDwdsarXyrT7o/4v4/rH3i83zEOgTR5Yxmu0REe1OLbEVPjY/qSfg=@lists.xenproject.org X-Gm-Message-State: AFq9FYKxCPEPhUMbJFQYpupwXeIG407DTaqmVI9eD3PqISOxM20Hm5R5 Id5ybUcvxq72V2yKtv1Kwy+xmZKaPppaBueo4BSBo59OwzJ8lKhls5chrOo2oM4/vGwtrvPEwVe p+OQl+CZ9Aqwo2067cx3gCPdHt0jWazXdTCqLMzKc+Q== X-Gm-Gg: AYBFou3DCFtZmMjZRCKMU5sNpyB3cnosGPk1Av7xg+ZFH6j8MUhgPiVmFrbRI4+STw2 IP8PBFBmw6gogeAyXmez9TObTHOeY4n49Fmlsy8qC+gBUfFlcFJisoQcEBT7DPSfqlYfLJeDloa +7ZGxQEJBG+Civd0HgEFG5M4maXWjsB/ZjgdGz8UI0tIvkO5UchxDNW/lCw5qACSczsn9BH9mUz lnIttZM9rnVchu5KtBzRgHtgsqR3nWBE6SEL0j9i7rVt+U3ljbsnoXdWAz+dkKnqYoU2fNqPMPj OZ2chyQjOyN1PCaTm917ajQo7QkWCTJ7BPTrHbeWcOCg+AznCcOQPEwyQVUBWLfIFW6/phXHNm3 +5Ezx8Sj2Ap/GZ1NwiFZ+1u5V1haGuDN6nqwxLXI= X-Received: by 2002:a05:690c:4d84:b0:8b0:8a9c:fac9 with SMTP id 00721157ae682-8b0f2170e34mr1719607b3.28.1792166212717; Fri, 16 Oct 2026 08:56:52 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-8-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-8-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 16:56:40 +0100 X-Gm-Features: AclHuK-9UgEUXtFnqP-08vQxMx1ZvtOBwk6ctyE1fo2vDL4tPgeIs4fL_WXzcUE Message-ID: Subject: Re: [PATCH v2 07/27] i8259.c: always use cs for I8259CommonState variables To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ef75cf/1792166214-342F4AE4-63EDC793/0/0 X-purgate-type: clean X-purgate-size: 497 On Fri, 16 Oct 2026 at 15:24, Mark Cave-Ayland wrote: > > The use of consistent variable names makes it much easier to follow which > fields are being accessed from I8259CommonState. > > Signed-off-by: Mark Cave-Ayland > --- > hw/intc/i8259.c | 192 ++++++++++++++++++++++++------------------------ > 1 file changed, 96 insertions(+), 96 deletions(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:57:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:57:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452314.1667145 (Exim 4.92) (envelope-from ) id 1xHkJ7-0008UW-By; Fri, 16 Oct 2026 15:57:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452314.1667145; Fri, 16 Oct 2026 15: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 1xHkJ7-0008UP-86; Fri, 16 Oct 2026 15:57:21 +0000 Received: by outflank-mailman (input) for mailman id 1452314; Fri, 16 Oct 2026 15:57:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkJ5-0008TC-KC for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:57:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkJ5-001vOS-10 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:57:19 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24950-8faa-0a2a0a5109dd-0a2a4501c174-14 for ; Fri, 16 Oct 2026 17:57:19 +0200 Received: from [209.85.128.174] (helo=mail-yw1-f174.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2495d-5984-0a2a45010019-d15580aebd92-3 for ; Fri, 16 Oct 2026 17:57:18 +0200 Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-8b0db268bd8so407037b3.1 for ; Fri, 16 Oct 2026 08: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=google header.d=linaro.org header.i="@linaro.org" 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=1792166237; cv=none; d=google.com; s=arc-20260327; b=ByhnVHo6RJyEr9Q3/HZjvjRaXPK7cF471cZU6JwAZKJqC6t8BEdqxE7HuaIbKpvR9j Qa6UT8Ni8S2BaSBEp9rXJQIx2el/AFDEwvwSYnwTQp+K5X+qM6VpUgqlg8jZYC1qucdc t4u45DyCpYWPRtjm6K+fSwlsYwU1HD4I/Gg7Kw47jam7IlgjcYjjtvKNK1uzq8nqfijq pglo8W94nt1kYP18dtc6EuGjY3wKksK8tXDpSCev1YyGm1FC1HG0UUSt22zc87QvqlTi Sza9SHX9IXXeWQ3YW5lElTairmRtR23vm1NtBa5EUstPoSlj+KTBMzgfaxuM9/vRMoCN 2nNg== 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=0Bv0jhAStudRjf0YN2Dnq1S4McAGYgpTwxwO1ue/HiM=; fh=c9o3ZVmwF0GyGlsp/xqDB+LUjxAd1O5pECNg9OnTtzk=; b=W7wmvzxZD8I+QF12G5YSC6S/g+UqdKkT72J6BorY6qH9xJVo4oa2FHlKFcfNU/Fsf6 1MmaL1HEqb/WXkTLPdgvwydPjCbrXcb9aT8TdqcVq1cGXDIZ2L3wZyCnu6dNaMgIn3qr UqSY8yiLoaUE8oBen5KUJkrN+5ql6y1CfHlSpjUB6CVxYVRslJ1UxEcIDheh4zxKaUKe 0ZcN1MsM72L/1drTB9NHBgQ0COemBaMOd8fIyZGv095kVEOEmWGXyORf5baYtedndc5H Jj3W5th5qvSHpSu/N/qxjAMUgsz+2pGNnAVy0eM7fYsAlJ6Rk4O0HmN6T9q3lNj8of7+ MlUA==; 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=1792166237; x=1792771037; 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=0Bv0jhAStudRjf0YN2Dnq1S4McAGYgpTwxwO1ue/HiM=; b=daaTAKEzwRTaVjyNzgTFVO2vuvvrPgtTcYFryaVyR+XktouQIm4AN3oeZUQn2NJn9D OH5OYFDFV8uBcHjt94cpXfsoFLxiR+dJdS74lSpTtv8B9214auvmycHYhcBV2PVLyIWQ XAcSGkH6byinDTgtzEodLnubslL97Wy90aC9GjtMyZFMqKGbk/8PXU5aOps3OVUxTBIe e8s7mJTQDR8VbP6eIHY5iAOJkeXuD0lMi92BnmHcBFKfeO10qaPuWxbhwGu0+AOy1E1K 3yRKk/6tCPfIdbpcGrs8FjTNWnNR7xyy2oeeWj5UUHMgib6U5tZGlIkbY3l+ro3HqGba PYbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166237; x=1792771037; 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=0Bv0jhAStudRjf0YN2Dnq1S4McAGYgpTwxwO1ue/HiM=; b=0XvrS+ScQt88YG8ZdbJY8pEugtPU58SdJR4tppccRBWC2tIYL1R/1WFs7j0b8Nf52d 8BddIQauFMXNVFkgosuz1y6YNpjpgy90sJVJTbO01iOKNF/2mYEDhLbdJUnm1FMpxb05 +n6FFwJ8vSREdu4bA8Fbe9412J7XNQqNTprr8Hq9l+dfQrCFocNUHAa7GzZqGemXPD5m K3HTuzoSyB7MaLwB2tUmau+GlDxIkRdFdvJAIMNQdyaPBDkWX6Fo8Hssa2Dnsbl5EtIP T/f7PrDcZGM8fnYn7ZpMOM9JWga3vVEFyS/sjxWqbJ37ZxZU5yXKaQFWGO/aKVNDufSu iqPg== X-Forwarded-Encrypted: i=1; AKwUvBzdrHHKWeqUgfxLlI/9dP1lmOlzpv5aDqRWbE7C02BuKAI8X3gpdNV0+wfA8DCxs/1VfL1DO4R8NWo=@lists.xenproject.org X-Gm-Message-State: AFq9FYIduTdz7cHc4neaW1+BqZLJX6urnxX+BjWn2+kBy/7pR76PrfdU hyapxtPGRoT7j/u72YJNEkmJDYYnPaXO/EYQjwlhnowH+mLAnPiiySYY28vQtSIszp9Nk2/4QMu cH6VI6MwsaYYwaAHNMHMGPEnO819mUO8rNbs3HGmx+A== X-Gm-Gg: AYBFou2kDXsKp/AlW9htlGYQWGi9nvoVwc018BnJ5Oj2aAFolM1bAlHiNqhUKPcUyKP fWGdMRpEQisokz45h5RQqJAcb3NMQ2Q0EJZRoUkcxfei4rcK6p/Qm0Ti0ad199ftUpGYkZ49CA+ vcs5D5jXGO9bM19T4AjXu17boupHWzqUxH6kug5mDkcJIzA4s9qg+3FBLmCLuLzJyGiVCgotBfV KP7mNyWHZM2lQMbdMosnG/5Hu6A8vaKjlJChHdv88GEukJRYrthBQ31Dg4edRr/ItkQRoBkLmCo PHN5Cktl/IPFGMP7C5tMiOUTkTy/UTCrW8Ak0TfVYh3IQ9/1nxuoqDqVLSbUGRHrprcr1noUwsk 7k4gJNxDo1L3D9QCjOA3Vpp0rnoViWez9Wpqrz+E= X-Received: by 2002:a05:690c:47ca:b0:882:31:3af9 with SMTP id 00721157ae682-8b0f2056721mr1329977b3.9.1792166237384; Fri, 16 Oct 2026 08:57:17 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-9-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-9-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 16:57:05 +0100 X-Gm-Features: AclHuK9_tRimGSW5gwJJGSJpXxB0ZYcFgojChYR8ldRgcNm1LmSPVOQJU6cjInU Message-ID: Subject: Re: [PATCH v2 08/27] kvm/i8259.c: rename KVMPICClass to KVMI8259Class To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d62444/1792166238-BE27A757-8E16AF46/0/0 X-purgate-type: clean X-purgate-size: 428 On Fri, 16 Oct 2026 at 15:22, Mark Cave-Ayland wrote: > > This is in preparation for its use within a QOM type presenting a single > KVM 8259 PIC. > > Signed-off-by: Mark Cave-Ayland > --- > hw/i386/kvm/i8259.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:57:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:57:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452318.1667153 (Exim 4.92) (envelope-from ) id 1xHkJP-0000Wz-I5; Fri, 16 Oct 2026 15:57:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452318.1667153; Fri, 16 Oct 2026 15:57: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 1xHkJP-0000Ws-FC; Fri, 16 Oct 2026 15:57:39 +0000 Received: by outflank-mailman (input) for mailman id 1452318; Fri, 16 Oct 2026 15:57:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkJO-0000VD-Ee for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:57:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkJN-001vQR-Rg for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:57:37 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24967-2eae-0a2a0a5409dd-0a2a4503ba5a-16 for ; Fri, 16 Oct 2026 17:57:37 +0200 Received: from [209.85.128.175] (helo=mail-yw1-f175.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad24970-fae8-0a2a45030019-d15580afd0df-3 for ; Fri, 16 Oct 2026 17:57:37 +0200 Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-87ab6e5f91eso820897b3.2 for ; Fri, 16 Oct 2026 08:57: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=linaro.org header.i="@linaro.org" 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=1792166256; cv=none; d=google.com; s=arc-20260327; b=diIS3SUhi4mhq24t4WKL6GnlvsVdf0GCL/8nNyYTRGKbwpsL5ndnjRYCww2AxQHk89 SP9FbZ5LYs4rRmnqIz8VTqbmAjD5e/aOxmJ5DbRbQYNz0VbvcHVwfluQA+T4dUbRrnO1 VUPh4PgAt5p6j9BmowZT22TaI9gAidHmxlw9wOdUU18bZPaDEviNEY3mDWy+HZYBMgps yamRU515AMTEpBbdVg8BEeBFGjnKvYpr39yzBiHPjl5WNITHsAhwcLp5Wrc7wmdQPFPQ feZXtKM3Vo/Vk1XPm0jSMMkoPhhF+laoPE9Nz8s71Fqk1ZeXZ7mPGdD6gdKubUglpBAC kC1w== 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=ijQiaZDakXdT2nqzYp4RwRt0IgGN4obLqR6a+at83Q0=; fh=5FhWxt4HllagTQZ/zQPCRP0iyCbcSP4W4pm4yT977FY=; b=VOWdmU+AALEE1KcUntKAoP4PIiQsQci3kJ2oPGl5JaHVC3uod796tWK8ALo1s7yiNP OaQmV8bqCFFkiqebOgFhghtpyn03Ao1WM3mvqRHtq2+rfMUqx4F6kbZ7iTWGUvgy9QP8 maHMzYk993V1eFjvjxRdWAnqewxlB7aawWITs4riWyRzPiWRctXgnPqLM1NnWB9Df2yf JMKEmpHF5zpTSsuMbaEPKOy4mqEHVYOqdhDg3JvyHrSpAksj9my+BBc3mZmX1wlcvApN +1//I2ViPwPYu2kGoWUtiwA4EB+8wEdc7yEvFKsLnZEdrdbnH8qBUrlAw9EyT6E53Ft4 J67A==; 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=1792166256; x=1792771056; 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=ijQiaZDakXdT2nqzYp4RwRt0IgGN4obLqR6a+at83Q0=; b=gU19vlHYwxQeCutmQczqH0Ob+K74ZDwkZvyP9Hmnblg2LLeVJwPtZW+fFVIYtuMNTW 6yRy5CL8x4fiUhK5oF7RIZwkNdRe1K2isvbaJUwc4x+Om47fg/CPvsKyjxJ+bUW5HSOZ nDAAP5KMS4SgcmVlqmNDjtQMw0p67LxjLACXURV/qtEhdLNGp982WTpnKaUAlafRiCsX C4ke6bmtFjTvik2ZoWvC9R/2qibu35aH05R8C5ydMbV1ymx68oU0n5gJxH0cNnT/NStX Lizwh8HlkH6NWfXqhqCxMjPEuXFvbXdbl+BHcQAB8djQo0bmgdbpZ+qZ8jle8YxzCEA5 GZ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166256; x=1792771056; 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=ijQiaZDakXdT2nqzYp4RwRt0IgGN4obLqR6a+at83Q0=; b=VIkrG1eIfIUXC2ouYdjAI4/Hi3b4kU9nKPjHkoTlaZ92qGPRcnI7vXFdfTHbiE0vZ6 QPVmVM0k0T9Q3Zk3IUu/GPsqwwe4kK7uRqfeWkv4oBd6j95MFg5P/Ua4oIZdLJFwKeMY g3n3VxrzF6AHAihpvtUQ7+krU7JROO4yJesd0MVfQYgJmH2Nz90zE8M/SuwnnvbjS6ss Wch2aMiEu/J6+UFODwzKZrcII2nLh+pTxG3vE4Hw/RNr7tdk6RnQ+9OgnwYgq1TW5DTJ zDI46W2GQg4ZnForW0CRchp7b8Fc73cOB8dPHSAFUGobBdyBHBI6CZColFy/2TfZApdZ 2U8Q== X-Forwarded-Encrypted: i=1; AKwUvBzc9Zm7K5o3Yvqkha24R7KVLVZfEFJaQtIlXntR+V5g9ytam1Y4gIHDSCpYcqIFSxIgiuXW5kgcDbQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYL7IWQ12EugAdR4L0ZjVomshvEdq8gdi0kusd2+Uw2yeFXit2VR +xgoso7wzhMPmcEWh+wHk51a9TXKDX0YyQHSACYSbpAJ8eyYTeenNMhsV5dYCznq55evzhPGp/+ BLykulJ65UXde96God1cEGCy1jnVurLaqN9CJaJjevg== X-Gm-Gg: AYBFou2wZFrUuSrx+H/4TjvSCl9ATFkH3h0GA4GqND59zMRRjnAR6vxs45wyiI74zlX mnAuO3Mlo1wx/oZlc5oQh4sn48Wkye31of5M885Y3dHVL9R2CfL+rPG/4O5Ap3uXLH4voCJr7VJ zNLDAzEfgeosx//VGodE8ZodvVjPpH9P+mCmGZFZSG+sFtoC8p6QEXEbdC4KFjsHu7cc4YjloXi PIQWWBsP1oP6WZVysEV/8qcwDypuqC+GmslW2jG2R6e2Kp2D0c73G7rSz/B5Mwj6ynpiaZkgWiz qRsViypLrs8E2eUd74WPSZy+t+o5edbcxQBrWmOmGzAIy3nJS5+cHM9fZQb4dh3eLhTHF3+TjXB pYvj4p5wUSH7ef9VomZS62yLwGH4Uw3bw7tDhdhQ= X-Received: by 2002:a05:690c:4:b0:8b0:e238:2719 with SMTP id 00721157ae682-8b0f2173795mr1870627b3.31.1792166256124; Fri, 16 Oct 2026 08:57:36 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-10-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-10-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 16:57:23 +0100 X-Gm-Features: AclHuK8uTdNG5Nsg_B8uIt7lUn78Aqvgarp82YPLfA_9V-E9zJtGNCs06m_Br8g Message-ID: Subject: Re: [PATCH v2 09/27] kvm/i8259.c: introduce TYPE_KVM_I8259 device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-33051d/1792166257-6F4C74E9-CF0FCC74/0/0 X-purgate-type: clean X-purgate-size: 485 On Fri, 16 Oct 2026 at 15:23, Mark Cave-Ayland wrote: > > This device represents a single KVM 8259 PIC and its associated class and > ensures that we can safely embed the device within a container device. > > Signed-off-by: Mark Cave-Ayland > --- > hw/i386/kvm/i8259.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:58:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:58:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452327.1667162 (Exim 4.92) (envelope-from ) id 1xHkJr-0001Aj-Od; Fri, 16 Oct 2026 15:58:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452327.1667162; Fri, 16 Oct 2026 15: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 1xHkJr-0001Ab-Lx; Fri, 16 Oct 2026 15:58:07 +0000 Received: by outflank-mailman (input) for mailman id 1452327; Fri, 16 Oct 2026 15:58:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkJq-0001AH-Ct for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:58:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkJp-00CrAj-Q7 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:58:05 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2490f-bab6-0a2a0a5309dd-0a2a450b9aec-48 for ; Fri, 16 Oct 2026 17:58:05 +0200 Received: from [74.125.224.49] (helo=mail-yx1-f49.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2498a-b7e8-0a2a450b0019-4a7de031cc04-3 for ; Fri, 16 Oct 2026 17:58:03 +0200 Received: by mail-yx1-f49.google.com with SMTP id 956f58d0204a3-6767d92cde6so195902d50.0 for ; Fri, 16 Oct 2026 08:58: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=linaro.org header.i="@linaro.org" 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=1792166282; cv=none; d=google.com; s=arc-20260327; b=jC7DPn4O7DPjXgKCiMXmw6Yay7Fg6ys8DBAiHKWxL7NgfnHlCi2fxkBHdzPwj+N5Go gedClDbR4yeDuVJSDHU8d+uw4PgregnhNy5nHg48BOHKnl5xC36Amjld1RR1AkPcnXpF cZnpAMuq1MRLdftfLCOs/3mym7HEDZmyIvs2qcij/1uK38FRI/jW8DSII+5ezIkQzWH6 x6wCkME7GCn+lUqAZBE51Jpb5IhE3u0Q5LnU1KU0Ze5+hOf1+fiJ4WRaJGJIQ4k+hVFn hn6aqNSNfkzA1ZgXl7QnM7yKe6Uws+Y5AjTQIGEvEOyhO7s2zmvpw6sY6OSaJbp162pQ ZivQ== 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=tzUyRwSvSTZpajfUFhAFqOVRPdXs1HJ0Bbm5LCt1+4M=; fh=4tquzMdfChB8RPcoYOfiXXoJPoYsnNaqVXKqxpaUGxM=; b=jOIUxR0s1INgbe6G133WqW4gshlMJvFNvggXVOyfM+WjwTZEg6IAtMu/lF2SYul8DF llYEXhSt/futiLSnrXaEk3kgHM0ZQv90Q4ghCpMh3r1QqSrUnHz1+LKvWPbg4aDFLaSN 561DmXEFjCzSL8cw8XB68h2CZ1d+5PqdDviPRpMEQUVF5tYLK6d/TLOIMq6E+zS8aII5 f0tnFGKpCqHRjJIIZzZLho/FGenDr64POOINuyHWAT/1zzV3G1vPMk9uICtNPNNVbxf2 +glAz3VoZqevAZ6bh64nRPwT3oYsy+kG41NJMx1Oa4bG/T89mMVR1ZNJ0TtFXVp6Lz7V BUFA==; 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=1792166282; x=1792771082; 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=tzUyRwSvSTZpajfUFhAFqOVRPdXs1HJ0Bbm5LCt1+4M=; b=IUi2dLZ3mWOaO9roEE0TMihnUjJJ2prP8ceCtyUAWQHodVP4Bvw8AVVBDoMXMQAI17 cq6jQdyknIY5MLZv71GwYdNzF8vFAmy6GrjqYSWS+JUHcgQ2kpT3JYW07B5NwQQgEeAb 9fF9/F1Q/t3pXzmgzm0LcpRPdl07Q+OhiArnGfCW3879upEiv1S+9nTcfhXjFrZmi6sM xf05nuh+/Z/ai0FeZahr/q9MlSLJMoh3AdLJ7mXtue7K5JRJ3hHLAddus65VI7n/tKeb A/h6vpntiFVkCx75EN6/Nc04TjqxFKtnRY9oYLzzi4y9qjvYw9VDVQaiPh5nYz8/13bu NFEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166282; x=1792771082; 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=tzUyRwSvSTZpajfUFhAFqOVRPdXs1HJ0Bbm5LCt1+4M=; b=IHeypOsvxMyy773PJ1OKog/A/GQeB7lFn7XlszIbNRMSTDJnl53d88SmeJggOLQCAb VwAqSJ5ZbdvEtTn9lJ5y+5dGg5z60nz5XjVtdoth76a8Ro3GWmAVn25r7AQHE0h4wwoH CmxyweP1CPKGW+wWZJBp/6QzOiqfP5AtRoIn5gxd2oJ2Ky2UotPFQmkxftyDsrs6AtcK ZSOoY0E1yNcboKxYHHDd6/Ch6KTMgU50am1t6eaNNV8gZsKXy7SS4AnroKdOeWngleSE Lt1hnmxkCvdhu9pdqMrcn+k7U2WPoNfogf1ppVSvqYpdSzfQWu8mRPizkd6JhjYr47FT GnTA== X-Forwarded-Encrypted: i=1; AKwUvBzDyVfsDTgzHEbYXovUQyPPduOfESJS1zxI1rCsbXmSOFWGUxKm43xAn3d67YUfXBOi6V/MUPO5hks=@lists.xenproject.org X-Gm-Message-State: AFq9FYLed0UEenYk1PBvxDu7wYlY2JtuH8hDWOC0jMHy5xToL9KKMtob XsfyuxcuKquMeKY3i0MJU4g60AVi7tB6+h814Ge6cYmysTGdjsegeXKlKJOO4eFSsNa04a+0efP ++TqeOELLB6l6pA1ylWswPdPGqa5kTN/3QVUqcsmuz8W27K8J8Y701jc= X-Gm-Gg: AYBFou0ktlR2sNYooNSkXJNpTyxDZgFAFdRGiNF79G/hGQxo0xIJo5yT2yENvTDamRD rpkLFCjAf/i1bntHTGAew98eF3Gl52uP82qxAzkkak1M7e/AdJKzPJ511EtDeri5iYlE+Zxzv3a AvjRsHiBdbkUBrmaA7+B9o8Hwtifxk3+2QY04osvLiIrdm/tLdLvyfY7igwdh2Y0/aCawT1v88n sbJtvqNx1NbpQh1Jh6s71u0Z0MhAoupb8q1s0Us+SOQjUCLyLdQOZgnf4EMdRksiw1GwoOZVl2p PDObpGiCZVfKKRHhAsVal5UYr4CloJ6XGvb1wXaCij13WtOgFCx4ysiG4s5lOM4sqCRREdZrW48 02s4xVPR2JUWGYwNoiGc5MNOjySYZQYXXd0j/Xwc= X-Received: by 2002:a05:690c:29b:b0:8b0:e680:6157 with SMTP id 00721157ae682-8b0f21966dcmr1741227b3.39.1792166282248; Fri, 16 Oct 2026 08:58:02 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-11-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-11-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 16:57:47 +0100 X-Gm-Features: AclHuK_Xg1yShmZzjS6zJOIF9yk2TdSWaMxrKLq6lygSMNlA25-z2dLMhnrPNhM Message-ID: Subject: Re: [PATCH v2 10/27] kvm/i8259.c: always use cs for I8259CommonState variables To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-42698a/1792166283-1BCD79EA-ABA1FD7E/0/0 X-purgate-type: clean X-purgate-size: 361 On Fri, 16 Oct 2026 at 15:23, Mark Cave-Ayland wrote: > > The use of consistent variable names makes it much easier to follow which > fields are being accessed from I8259CommonState. > > Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 15:58:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 15:58:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452330.1667172 (Exim 4.92) (envelope-from ) id 1xHkK5-0001Zu-W9; Fri, 16 Oct 2026 15:58:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452330.1667172; Fri, 16 Oct 2026 15:58: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 1xHkK5-0001Zn-TG; Fri, 16 Oct 2026 15:58:21 +0000 Received: by outflank-mailman (input) for mailman id 1452330; Fri, 16 Oct 2026 15:58:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkK4-0001Xp-Od for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 15:58:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkK4-003PZr-5e for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:58:20 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24971-8faa-0a2a0a5109dd-0a2a4505af9c-36 for ; Fri, 16 Oct 2026 17:58:20 +0200 Received: from [209.85.128.176] (helo=mail-yw1-f176.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2499b-4cb1-0a2a45050019-d15580b0b164-3 for ; Fri, 16 Oct 2026 17:58:20 +0200 Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-8b0d63f60bcso588307b3.3 for ; Fri, 16 Oct 2026 08:58: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=linaro.org header.i="@linaro.org" 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=1792166298; cv=none; d=google.com; s=arc-20260327; b=pp8sSzuZQJQAj7c+JmwrK6KWjZ/s9veV1kyALZVpuOOlg5zl4GmBYqg+0wMl8UbAOs o+B/0tEjXdHfTstuHOEWzgNdU6bySuUSZAFZXIyyb69x7ygEseSVLTAT3QPAMO8ooDj1 BtWqmt+zMmcUTL/uSsm9AnwUPq7obJyNdD8f9nlgjLQTuOsUImR0WYteRw3ifgWVKAnQ ien/kCuheUmldMTIK72QarPQLXPor2d5kfDU/rZ65N0mh4iXYHk5/wOJQ2Laa5GDa5MU O8LqE8QrRKTrQKcSuFqr6ifrG/ulIiPdcIchOXN3Re49c0+Nf+xjF1GcqRYrgsHJb7ti 5ZnA== 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=Z8dvB27BD00MHKhAiviavhQ6hVBZ26dTM77I+eEYzp8=; fh=FquML8VdRvAxVnP7gHASgnHHpvAOP6RQkrDjv2njwCs=; b=UVG9KtJzKAdKMZYpC9wqXwTtCabJlwAIPDdOifGqukqMMNWh6cjQBWM8frvkFcAn+F 3bBmYAHwP8cf5dy9uJrWgP5tLSepubBko/i1hLSYGUr259fX1lFRGNjT/g83amvHZpCX 7Y78XIikIb41mo4WL8PL8rGcYQbH6LzWdDnWHLu+Wu1alU7JMzfRU02DqkEfB0+eEkhC 5ruwgNKnGwhWNf8mENKmyxzEIMpZQS1YcMp3iVK1L5ubCVb8SyhiGXKLG/sW43y1iiNX ninW9lLWGF3mfc7k8JChQ7UgGby/TIB3fwnHOUlJFLgJEpJyfS26khCrvUHI7uXUImuV Mn0A==; 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=1792166298; x=1792771098; 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=Z8dvB27BD00MHKhAiviavhQ6hVBZ26dTM77I+eEYzp8=; b=UZZ6U6AGkYuY0qiEIrt7QLhGfgxk69BLCAd9cGq7I6HRGr7S8MtJCCuT5QnjyeTfME TwOEfdI0GJ0BLXe+yxtIbxESVJzD/7+AsfgubvTbxNeFGTus+nneikmZ/nLh3G5Ip2OK XT71DrFh1NQRs824RtaKsZWmTWIf/EYw3KhrYjIE8bNr22dPuJfLTsDfGrHOgjDxh24b w01Q8NFRfPT8lKxxFNbcvpVhRHZmqAXB1Sb2Qh2k9/NZosGq5XMynwD5RNoVT1FYCMvH fyKT2h2KBna9H/wKT8Xgfj1QPgz+84/F09tRWusilL5Aqxpa91fpUK43ng4iCB4T2F+M Ujyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166298; x=1792771098; 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=Z8dvB27BD00MHKhAiviavhQ6hVBZ26dTM77I+eEYzp8=; b=m/pTcIhByS4YF+vFVamXiBln0WfzCG9kLXjeT94TVoq4hLkG5JMpeE0gVNDHHVf3pz M0xsHrJf8jff1e9VIk3IgvqR/z75PbyXVYldwzUo0cvLDUSXSASwIZuzm/jsXAZ8UvJ/ WFSNjoslcUK0or6BSigB6llvkxdPF2B8kpO8Pk669c1nofrnLfqdd3Pbj8Zxy2vJfbSd C/TMhkLqmrm/WZ3Uz6uBl4F8VHyHKmDDAvpNA+/YzaQr7O0Hsv48n01pfsbJzGT5LlC2 sBHfJNo5gR8fUN86nCiHXJWlY5DfKlahiX/ZavCPJKKUCRYT+ge57Agr3dgsHhEe2Hzr HXvQ== X-Forwarded-Encrypted: i=1; AKwUvBz/iWe3z8BTziO2mAi8N+dDyOcJtSJOBevrmGlwaqyoXwr8aN3b+QnnnA07jX9ceymzb7YoNsjX+/E=@lists.xenproject.org X-Gm-Message-State: AFq9FYJhpaoQ3jhpF9ML0A2GFenjXHLOsOQ5+J8V1TWsYjWJiwYS/vBc Il0IaA+JcM2an6AErFGAWw7PlD+I/pt4KlLQAdIO+B0XbNycAsNWf7GMGU4mNAS5qZF/NDjdoAi IEYiiSVO4x4H6c1skoLMZYc4x30dZt9uwpWNlRTfr8g== X-Gm-Gg: AYBFou3cXdAdwogyYB8jX+aiBBfNzIBDi7Uf5EAPzns6HDhvbhzYjpMJx+Vdy449B4C Qr3e0kGsSlbCnHoGE4W75RkctegKKpcP/B94GvTvCvIN+rzxDDmSWCaSbKOJwCdnWspBUQ0dD1t +tq0fYBuZj7JGxAbuBh77oBjkd/Q/hfNtJ5P8rG6bsFt4je3OYXqChtSDLfSZerq5O0PqSFLYXU SpcRhNI99IhC5w0yB9vwMUW/8dinX1s5iTA6enNX5rX9sIGPrUOGom+lL3IfGXLvDFXCZjfn7Mc NPE5EFRp5DgBm0/RDQ4ib3q1DHEKPJo0hFTYhf0gOhFSGOlKIqQcR6AQsIebBjkm8DHH1Jfaq4t dPXC1S36dcfPMYpP5F+ofrF4+8dkeHk3HFrIkKKI= X-Received: by 2002:a05:690c:e15b:b0:8b0:e55b:9b71 with SMTP id 00721157ae682-8b0f206613cmr1079727b3.8.1792166298506; Fri, 16 Oct 2026 08:58:18 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-12-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-12-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 16:58:06 +0100 X-Gm-Features: AclHuK-Imydk1NavRlI1lSdQw3bHdUyOwWkdd3gQpE-QQexO367vic2GyURlIMo Message-ID: Subject: Re: [PATCH v2 11/27] i8259_common.c: always use cs for I8259CommonState variables To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c201ff/1792166300-F62AB2A1-5C936CFE/0/0 X-purgate-type: clean X-purgate-size: 546 On Fri, 16 Oct 2026 at 15:23, Mark Cave-Ayland wrote: > > The use of consistent variable names makes it much easier to follow which > fields are being accessed from I8259CommonState. > > Signed-off-by: Mark Cave-Ayland > --- > include/hw/isa/i8259_internal.h | 6 +-- > hw/intc/i8259_common.c | 74 ++++++++++++++++----------------- > 2 files changed, 40 insertions(+), 40 deletions(-) > Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:00:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:00:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452344.1667181 (Exim 4.92) (envelope-from ) id 1xHkMB-0004Le-FJ; Fri, 16 Oct 2026 16:00:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452344.1667181; Fri, 16 Oct 2026 16:00: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 1xHkMB-0004LW-BQ; Fri, 16 Oct 2026 16:00:31 +0000 Received: by outflank-mailman (input) for mailman id 1452344; Fri, 16 Oct 2026 16:00:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkM9-0004Hx-NS for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:00:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkM8-0092xZ-Rw for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:00:29 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24a1c-e002-0a2a0a5209dd-0a2a450cce3c-0 for ; Fri, 16 Oct 2026 18:00:28 +0200 Received: from [40.93.194.31] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad24a1b-f479-0a2a450c0019-285dc21f417a-4 for ; Fri, 16 Oct 2026 18:00:28 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5300.namprd03.prod.outlook.com (2603:10b6:a03:223::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 16:00: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.0522.013; Fri, 16 Oct 2026 16:00: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=PcBDWAbgtiC+cgoFsVeeAL7WsGl5HNF6JCkztcHW1RBJZVTzkRJ2Vh2AwjiQv2oB9W6NGZ1NqBAy3FIkGDFOmBFyCTHTEVxpSB5uhan5GPowQ/JbI4s3nTASXZvXMQZaoSlHiKhcxL2A4kqM3WqK002HWphpgJhjD/p1zyLcm8Qy7vkBBkprd7lOofaIQ9+ojaRxD04LXV5R5mhiCRQNLL6fiVlvG+xaUMeOmQl+Z56ZoYf5X+a+kUIphoVgQ3K0JQjZYl5XwcdFqIcz9joXEwlvgoY8n8ZOctzq43ZX5ZxlSKgqyLaGmbHthCwWwnZMWhwfzJY6/u/9HrV5WbcirQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n7KBtp4KGMqhlX2cDj/rxAha+z8H4g0ZE7sxNjdv6KU=; b=ISx0nkJVUNCB6ZK0efYFDcEZqUX7MIchLTk8V6OylQMgpwzpgWRpWZKjaYj1Fpj1FouvuZm1t+LtuT7oxfQG3XL8IzmM4SwHVtLuF9IYudxOsSyY7iIO83JNBrz4ppxaCy9cMRVpZmgEuGdv/FQ9h2RPdTeJ+to8tW/A0K+ReGqP2+Rz26DRq7+37YYzk9IoVpp/iG1BWTmcvHjpxwjrXO53UMx5RJ9spkWJtNoC4ZifkBTPnAXaRunJEAstHgVvUuQCGmXEDVGrrvWylTd44Nz0bJlFkMv4/3IeDNV1kbRGkU7e6hokObRq0f+PIhU9mMtrGPkc4Kfk4OWpyJsamw== 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=n7KBtp4KGMqhlX2cDj/rxAha+z8H4g0ZE7sxNjdv6KU=; b=cN98XAAV+9RieeD6Nv87NnejVdQRAAZYSBPNMeC710dBpy2txLtoWi6sVd4ThuXlZ3wVgq0leh9pW2X/oilKG6sikaZ8lnOzyLKNPq1UAyrZcFw263kHo24DaGLCU0xmBPRgZR5ahbwspmpjyC5T8c3Vng4jp2KoYcR8HNBLfUU= 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, 16 Oct 2026 17:00:20 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD Subject: Re: [PATCH] tools/ocaml: implement stub_xc_domain_create() for ARM To: Julian Vetter , xen-devel@lists.xenproject.org References: <1792151570.8631fc262581453bbf619ec5b2062170.1a1448ec98c0008425@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: <1792151570.8631fc262581453bbf619ec5b2062170.1a1448ec98c0008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0419.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18b::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_|BY5PR03MB5300:EE_ X-MS-Office365-Filtering-Correlation-Id: 95dab18c-87bf-432d-fcba-08df2b9e9670 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|6133799003|10067099003|22082099003|3023799007|18002099003|261009223027099003|11063799006|5023799004|56012099006; X-Microsoft-Antispam-Message-Info: gxaUcBCsuhVW7wuOPO+tVejdla4fsiG94PIL9z9Etgo41kJe6V2tAH3AgYs1XU5lF6JYhUqOATWqMQjtT1726lQsDGpCkgXAy+kjSJBSADy2ciarc3Z2z/Uf+GNjLd5KKpHGrmuLu8ODQvTfQb5+2ExTFaB/tkxYpU+8dj5YayPvbBnLA2VBjv3x10GLHFJnIR8opgz+FXJCCuSNHzgnioowDQytSGwJbxaSdA0WpmpdlwVTUt0JAP7pUDEFBPxHiH8yu+c9wSj9DzX6StrnZvaK9WO4X8pk+pfxjH8s3oFgv/1Ab9tCw/tMu2IE/u7iBQqMmdiDr0JA17jNqBx18iH0Fktjch8Iql2w13NEhOYGnwgmP/BIvBZzlvvL0EFtwfWynTwtsxPDPMXjrS6zxdcrgWYTOm7WNvDhgglAQzWoALgakhqO+NtPOMyM8/g3PfkiQLhcM7KHE9WtySzUfOC3mL9weRO8SbsnLHSP6y+UpkGJFcR9QZ5ABdByUZ731IXYweOnngZKqm1ha7Yn97H9CKChNWBZdTzkY1cOhaw/8GL5BQGzFGwphzrthwC3pjFaNO7Me4ZuAk6lfo0onHqGwonJGSfYQ77bS9l6S00WNPFS0Pj3t75kSHFETru8wD0pwih4GkWeDv5niHf7wVQYcc9dVTildkm+atSevIQ= 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)(6133799003)(10067099003)(22082099003)(3023799007)(18002099003)(261009223027099003)(11063799006)(5023799004)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZDZjSFZxMTBVcjNlQi9HSXlkTGl4ZjhDT1NhZ3BvU0t2ZFdHK2pHWkRkdkZC?= =?utf-8?B?Rm01c3hiNU9LS3kzL2xxMWx4SEsxNjc2M3B1dG1uYVpzbDdsbFRZL0h1MVJK?= =?utf-8?B?QW8xZ1hicHdFQXAxK0xxQWtJUkMwQVRlczlIU1hXUlo0YlozaENLdXFUMXdH?= =?utf-8?B?NFNleEdpem1QQy82b24zK1RTRDlVUFczRmdFZElMRElIMENWUmdsM0JwSjZq?= =?utf-8?B?b0tHemNUbHI2T0hsN0U2QjcyRFBXK3BxZGk0Yi9VUWt1MDcyZldDNXg1MUFH?= =?utf-8?B?Uk9sOFpoY2V5WXdwaldmZmcwdDBsTkZmS00wUmFFNzdpUXlDekVkT2Rnam83?= =?utf-8?B?WXp5dExpUlp6YWpRcEtySFJUQmJvYWRPMk1YaUVCYWYvakdJOVAzOWRkTThV?= =?utf-8?B?OG9MaHJHbXlvTnNCQzUrTjJDOWZROTRQenF0a2NuOTZjNzNmWHhYdjI0Ujh3?= =?utf-8?B?aUd0MGs0N29Nc3J2RFFlbDZrR1A1ZHpiZnNmSmJmeUpFMlE3bXVzQWI0U29Z?= =?utf-8?B?eUtWNHNOVUJIaFNDd1hNTnFRQWxnZENvTU5tUXN1bDU5cUNNNzNJbUxEQlda?= =?utf-8?B?cWVmcVZ2QkcrQmE3cjh2OE9uWmhpdFhDSzVTekxZOVRGSGltRUdqWFRUYThk?= =?utf-8?B?TjRyS1VYWmJPZlZ3YTR4dldGaU42SmVCM1FaOEF0R0tDS1V2VEZQLzBlZEk2?= =?utf-8?B?dDdZSXRxMXZZaWM2TWpGTTNoNEY0SitRSS9qcTJLd1JmVm1QbmlTR0loODJz?= =?utf-8?B?cnV4NWx6R1NMVXRqZHFsdEJoMDVXeUp3aml6cmRkbTd0a1lpd2R6bXl0eUVo?= =?utf-8?B?Z3ZZUFB5QzlUTkh3eVQvT1hxbEl0ajE2dndobk1BdE9WU1Q1WGlvK2FnSDBH?= =?utf-8?B?S3JZS203NHZCMVE4K25KU25WSmRlWld0clhNV3A0WVQrOWFFaTlVZTdMU20x?= =?utf-8?B?L1E1Z1o4WkZTQm9hK3VsVmFET3l3QWpKSlp3K3lsM011Y1VwZk1HWmtpRHBk?= =?utf-8?B?SjZIbkRQWTV1ZEE4L25nTytGcndxcWlwVStNcHlSSVVhMnVyeEpxQ2tQNVlB?= =?utf-8?B?dm8reTJwY1ZjaXlKV0NqZ1p3elFHeUIzOXJkOGFFWGRWTUJpL3NmR3FsVS9E?= =?utf-8?B?QmoyZFFsZ2pHK1p3ZzNVcHYrbHdGTkVFYkkzdS9MRVdld0s3ZkREQjhLSVQ3?= =?utf-8?B?SFVDYWcrN0JPRzZpdmd3a2pjZGdEdC8xWWtRTFJQOFRqdFZOck9BbzdzQmdG?= =?utf-8?B?Y29zaXBhODQ5RHNkOVg5MXVMZWhKY2llaitpVlYyeE9yUVVuRk4wUjV0WW8y?= =?utf-8?B?bzd1Rld5VnRUS0Q3VWk0UnV1SndRSTdGL09kK0MrMFBoemcwRFYveE0wQjh5?= =?utf-8?B?ODg3RXBlNXQyZ3FTVm4reTFOcStmdkRETnN5SGZjOSsvb3F0aGVWeUl1V2w5?= =?utf-8?B?QXhKSnNIbzVHanc3YkUvZ3RpRDZFcW54Zm9WSTVtNGxVUVo1djU0WDJOS3VH?= =?utf-8?B?aG5lYXhzWWhDU2hSMXpDakZGWE83Z09iWXhuajV3L0ZNN05GdEg4a3pETklB?= =?utf-8?B?SUhVODNLQkgvQ2swZVFKblNBTjAwV0V3d0hUZkVnZjdnM0JmYW51eXFYYTFN?= =?utf-8?B?M2Q3M2RKdWVnQW83a013Nk42Zi9abitmQ2tFOEMvcldwUlV6Z2dUQXNNVVoz?= =?utf-8?B?azJWOU1qMEg4N2hIdkZVZFl6Tk5acmd4ay9RMzBrUGhXNmQrbXM5Yks1aUtu?= =?utf-8?B?Vzg5YnM3QzhybDNKSTF4UFJTYzYyK2loK1BxVVBmZm8zK1VCcExCMGQyVDlB?= =?utf-8?B?bXZMcjNPZGtCNkc5VE94UnloOUZ5cG1vbnFKNmlLamt4ZlczZG1Xam5vVWZ1?= =?utf-8?B?UzI5bTBqR0dxT09xcEVhQi9sSEx1RjRKajhNNVBaWjh3U0NNa0FSSUFEeGdy?= =?utf-8?B?UTlxSWk1cHAzM0J6ZGFtUW1tNlp2bmlrNS9ZS2V5dkRHQUxDa0RtNGpublFB?= =?utf-8?B?bzg0c3M4WUtIaVJETjNnaC9HN1BoTlZ0d1U2aFQzQ1dVZ2RURVFqNEc3RW5X?= =?utf-8?B?UWN5S2NLeFNheTBlN2pJNG9yd0I3UHNBRFR6WGdSN01OZU5mdTBQNDliYzJt?= =?utf-8?B?MWR3K2ExSnMxZjhIQlBxM0U5UExhZG1kRi93UjVOMm9hTm5XcW5kOFR6RUdm?= =?utf-8?B?QjlMbm9hY1JYOGtaSmU5NVg4Q3R5Q1l1VzRhbytNMWhoV3BMelhoV3dGMGxV?= =?utf-8?B?K09tYkowK0lBVlNlWmlEdjVFMTQ3MHVHdlhuOEhrWFo0aXY4dUovRnNCblpk?= =?utf-8?B?RnZCK3lDbTlWUGRFUS9wbGJxR3Rkc2ZZbUVDTlhDWks1QUJleUJpQXA4YWZ6?= =?utf-8?Q?WpQFsIadyNop+E1Q=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95dab18c-87bf-432d-fcba-08df2b9e9670 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:00:23.9562 (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: bM/4FGHHXdrVxU9IRIgkhdFXpKKoV69vuNAm9GsYqYzmU6Vtc2b6gcHDqXLI1Jn0Vac+QgaOug87pJPIT4Xc9jK2yWj0GiTzRvIBmN1NRGQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5300 X-purgate-ID: tlsNG-d25034/1792166428-51538A5B-C673ECBF/0/0 X-purgate-type: clean X-purgate-size: 3267 On 16/10/2026 12:52 pm, Julian Vetter wrote: > From: Andrii Sultanov > > stub_xc_domain_create() fails unconditionally with "Unhandled: ARM" for > the ARM variant of arch_domainconfig, so no OCaml toolstack (e.g. > xenopsd) can create an ARM domain. > > To fix this, convert the two fields of xen_arm_arch_domainconfig, > gic_version and nr_spis, into the corresponding fields of struct > xen_arch_domainconfig and reject values that do not fit, as is already > done for other parameters. The remaining fields (sve_vl, tee_type, > arm_sci_type and v8r_el1_msa) aren't exposed to OCaml yet, so they stay > zero. type xen_arm_arch_domainconfig contains clock_frequency: int32; but you've just removed that from the hypercall. I suggest that we use the fact that this hypercall doesn't work on ARM at all to allow a minor breakage to remove that too.  It will want to be a prerequisite to this patch. > > Also add a BUILD_BUG_ON() on the size of the createdomain struct, just > like the x86 case, to catch future ABI changes. > > Signed-off-by: Andrii Sultanov > Signed-off-by: Julian Vetter > --- > tools/ocaml/libs/xc/xenctrl_stubs.c | 28 +++++++++++++++++++++++++++- > 1 file changed, 27 insertions(+), 1 deletion(-) > > diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c b/tools/ocaml/libs/xc/xenctrl_stubs.c > index 180f2fbf45..5fa67cdf2f 100644 > --- a/tools/ocaml/libs/xc/xenctrl_stubs.c > +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c > @@ -257,8 +257,34 @@ CAMLprim value stub_xc_domain_create(value xch_val, value wanted_domid, value co > arch_domconfig = Field(VAL_ARCH, 0); > switch ( Tag_val(VAL_ARCH) ) > { > - case 0: /* ARM - nothing to do */ > + case 0: /* ARM - GIC version and number of SPIs in the block */ In hindsight, I think these comments are unhelpful, because all they'll do is go stale. Other than "not supported yet", I think these ought to just be the tag names.  So, drop this to just /* ARM */. > +#if defined(__arm__) || defined(__aarch64__) > + { > + /* Quick & dirty check for ABI changes. */ > + BUILD_BUG_ON(sizeof(cfg) != 72); > + > + /* Mnemonics for the named fields inside xen_arm_arch_domainconfig */ > +#define VAL_GIC_VERSION Field(arch_domconfig, 0) > +#define VAL_NR_SPIS Field(arch_domconfig, 1) > + > + intnat gic_version = Int_val(VAL_GIC_VERSION); > + intnat nr_spis = Int_val(VAL_NR_SPIS); This particular mix is buggy (not that it's obvious; Ocaml's API hide a large number of spiketraps.) Int_val(x) is ((int)Long_val(x)) so this expression is explicitly truncating to int before widening back to long. Either use Long_val(), or a narrower type. > + > + if ( gic_version != (uint8_t)gic_version ) > + caml_invalid_argument("gic_version"); > + > + if ( nr_spis < 0 || nr_spis != (uint32_t)nr_spis ) > + caml_invalid_argument("nr_spis"); With the above, this needs to be the narrower type with:     if ( $VAR != Long_val($VAL) )         ... which is the only way to see if any bits have gone missing from the Ocaml representation.  I bet we have similar bugs elsewhere in the bindings. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:05:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:05:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452356.1667189 (Exim 4.92) (envelope-from ) id 1xHkQY-0005jh-Tk; Fri, 16 Oct 2026 16:05:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452356.1667189; Fri, 16 Oct 2026 16:05: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 1xHkQY-0005ja-Qz; Fri, 16 Oct 2026 16:05:02 +0000 Received: by outflank-mailman (input) for mailman id 1452356; Fri, 16 Oct 2026 16:05:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkQX-0005io-1x for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:05:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkQW-0094WP-EW for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:05:00 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24b04-8faa-0a2a0a5109dd-0a2a450489ec-48 for ; Fri, 16 Oct 2026 18:05:00 +0200 Received: from [209.85.128.182] (helo=mail-yw1-f182.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad24b2b-b57f-0a2a45040019-d15580b6c59e-3 for ; Fri, 16 Oct 2026 18:05:00 +0200 Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-8b0d5ddafbcso759657b3.1 for ; Fri, 16 Oct 2026 09:04: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=linaro.org header.i="@linaro.org" 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=1792166699; cv=none; d=google.com; s=arc-20260327; b=Ta62YgaI115eebM5lX/Qxg1120z8ao6tw4w/UTaNOA9UmiLhsiLnzROnaqLWYKtrIA 5T/7gx6WAfKjGDU+TMWjh7eX1fMueoXrymEeCy6IS0Huiyo4lO94R6OUOKdOezh5XtsH LizHLNvdccxOWkNoDlgfbxSqiBHAW6bDjtS07m2/kr+bUY/NoUIlGYK0XINgwu5Kp8/g SV+ubAQgWI7DhlPx7SLVuGvOEMwjmx7toaMPy7zzWIgp5DJlBYNIR9O7ts6rw5VDWKFP 6MJ+CnKoVCoR4Erecexndiny4kN/ifGFn4pyA+/64/V/2sPboqSbOfDGD7KsVGJgN+aQ cKrw== 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=oHZaaHBa8nXusX2kfKrl6y8KNB9X+UZvV+PXu8W417Y=; fh=TXQgLy/PlyK1OuK64RfFLmA4AMkVn8VTs4weE3CHUMw=; b=J3dXv7SFpw6PMOaiKxE2qeE4+psDijZ6mIkd2eYihF95bsPRVK5IQain6L/ogaUnNP ViIa0C6YCdHcMZmecpTl8G/23wjTRqkWdanWzfje202NqnOZjEo5I2leiE51cq/Gaap2 s4wMJ42JBxt7u0AiiYgu4dHOz4skJx+bEbEUtJqlFr6UFJftksuWOD+hwy3wjowOTME2 1ENSONdmLHfFmXavE6jXGgCNES4+/8MTyLHY5q3LKS9BneVlrOh+K2YSaLqZemsaNU4Q a15IA7Px/vfO8N0G7VVs+9AVRX9fY4AEJc9C/eT1NYAfERVu1GZsJO4F1a7QYgXtebW2 L0GA==; 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=1792166699; x=1792771499; 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=oHZaaHBa8nXusX2kfKrl6y8KNB9X+UZvV+PXu8W417Y=; b=tJzf9uAVd1bquP9MPxxIotz8a4zRmIsFgpECI99szQNzmjh8IOj2j7jGc9kKdlJS45 QZeVsKHS9GR3hpqM0QLTeDW8dan9tJ4vIDRYI/HyYHljBTW7HXyPuxPVLCT9IcE9YbpA MT8QN0WHvUCLC4cKKHReQB1pBMNX9sx5f5H/PR6fjN3Eu61TeANUFfOsN9qM+WpmfKUq IyfGSskfKAheU8zUcN9RoJlnk+J7qMZfg8oozvQZJ/nsBqRByfTwMVfXzDdxwFzUv+C8 C+7SUH0OTCBQVl9RYCloW8CcLKqbtrziCo0RJv1fK3gWs4Jy32lKOntPRi9EiVWnepEM bzhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166699; x=1792771499; 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=oHZaaHBa8nXusX2kfKrl6y8KNB9X+UZvV+PXu8W417Y=; b=xZEHL7CpUgGTDCn1SP0iGDQg9ec9fPa8KjSUGbBdvN5s5xiz654wkmxK2w5mH2w4vY qwFBTjsy3mXhO5qrTGHjlmpRcnNHUGo7P8Enp9jw1V1grK5acQGZIltYhdXRUd+71S3x QMHRY0jCoQSOWwUYPYcY7VUl66w2KMf/da9W857sMCmjJk3DZo64WEJm4HLre6i9RoRt NP4TuHtfr3VKg9Mrs+9nYtyjoQzCD0+BNVWhrldqFlZGEqwlWHXbbvpXaYoRzHmYQq8Y KZlwE/Xy1HG9bF2WX3R8lv3dDzV86d21tZpmx3A5JCVablMQAmkfhfMZWirUPVegABB0 iYNw== X-Forwarded-Encrypted: i=1; AKwUvBx9LCdY9s3xYWAZHMcx9GZxzMOneZxqw9f68MSAqRey4uuNvZPTSYJKcU2AOaWNYQ3tD97seZKeDbA=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ4ce2B1Qztw2cYXBoyrbDHY3gbzawu+3M4alHsq/EccdwuQP/6 P/oX2km2r60/3sJbkxXqXHDUSk9mirAZd1Is3dSjKT6ubmCD/I/iJDVSNzYcY2vliblwFoW3fw+ mdX13RR0AeBOnDSIe6vMvGZbmTj1VXcsRyNLmwdH3sw== X-Gm-Gg: AYBFou2Q0c91BIwL+p6RFYnFjfoW2TuVzCN/B71qSmoVqmbMgacmXLyn0Z5CJCaaD9w K8Q4hf/If3vX4DQdg5MMGycwlJ9XbrMTVg8SIiXSY97VOFYRr3+NVU5l13ZnWe/OLl6TCHt10xz 1SK2j/0Ypm3WRkr5TQlmtMwwM0IwYQCoGH3hXv8XAoZx+CLvu5sJKrhY+dUY8wFohDsuc/FZp4S qEgFXP/Su7xxOTJ4uAyd2vxXpmv1OO5TqFs0z7FVDzgpYCM+WsQcjQP9ZesA3aJ66tf/FK+wlgp nlD2OcJUPdZ+WKSWCsPxjRjBR/q2YTb7r+UrRC3WxVwUnDRwuiP/VBbB4zZlp1hcDIGJ2K6EyVg 8jIq7i+8tsb6tBCzU7FC43hRKF13jTB9C51uUqugnfFg0z4RsG4g= X-Received: by 2002:a05:690c:6f83:b0:8b0:e207:34b4 with SMTP id 00721157ae682-8b0f21aeb87mr1772277b3.18.1792166698679; Fri, 16 Oct 2026 09:04:58 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-20-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-20-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 17:04:46 +0100 X-Gm-Features: AclHuK85P2rMZqG6EDXy88iBDY0zAJ9NcmkQt_m8qD6NH9SZYu0OY-RxFihenIw Message-ID: Subject: Re: [PATCH v2 19/27] i8259.c: properly cascade secondary i8259 from primary i8259 To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1792166700-53AC0B50-B199EAE3/0/0 X-purgate-type: clean X-purgate-size: 2449 On Fri, 16 Oct 2026 at 15:24, Mark Cave-Ayland wrote: > > 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. > > This is a bug fix since in a cascaded configuration on real hardware it is > possible (although unlikely) that the cascaded input from the secondary i8259 > can be masked on 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 bfe01067b7..5f90edbe60 100644 > --- a/hw/intc/i8259.c > +++ b/hw/intc/i8259.c > @@ -519,7 +519,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)); Looking at this again, I'm not sure how this is a bugfix. Quoting patch 18, this is the code at this point, just for context: + 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); + } So before this patch, we connect sec_dev's gpio output 0 to s->pass_irqs[2]. The loop earlier in the code set that up: s->pass_irqs[i] = qdev_get_gpio_in(pri_dev, i); Now we have: > + qdev_connect_gpio_out(sec_dev, 0, > + qdev_get_gpio_in(pri_dev, 2)); Isn't that exactly the same thing? I think it is indeed a bit clearer to directly grab the pri_dev input rather than pulling it back out of pass_irqs[2], but I don't think there's any behaviour change here. thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:09:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:09:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452365.1667199 (Exim 4.92) (envelope-from ) id 1xHkUm-0006yW-EF; Fri, 16 Oct 2026 16:09:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452365.1667199; Fri, 16 Oct 2026 16:09: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 1xHkUm-0006yP-Av; Fri, 16 Oct 2026 16:09:24 +0000 Received: by outflank-mailman (input) for mailman id 1452365; Fri, 16 Oct 2026 16:09:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkUk-0006yJ-RA for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:09:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkUk-006ZpE-86 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:09:22 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24c21-bab6-0a2a0a5309dd-0a2a45038356-30 for ; Fri, 16 Oct 2026 18:09:22 +0200 Received: from [209.85.128.177] (helo=mail-yw1-f177.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad24c31-fae8-0a2a45030019-d15580b1c9a7-3 for ; Fri, 16 Oct 2026 18:09:22 +0200 Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-8ab38a051aaso699187b3.3 for ; Fri, 16 Oct 2026 09:09: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=linaro.org header.i="@linaro.org" 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=1792166960; cv=none; d=google.com; s=arc-20260327; b=iryzr6jeKe2FaJSRiwYMBE+0hsTZYFwwPqiesY4bXF+fCWfNjJ+n33es7Y2+cice23 zCC4xcUP58fCCKbGgVEKKXP4AD2YPUaHY7HdnsTKsSW2E3w72eD77nIrOJAF03XFokZM X/eYIctgqKX3X9wISISolpaLucJd1fGoVW6BgKhYXCpX86wDbXvrvEqKFMy843L2NkVY aBbnQMUg6QSn4hl5zbo1hWfaVBM9XL45W583qnpCAEhgCXhuOLL/WjFaPh45Og+njlFK ItaNDO/SzXP0TW0MTwA1qfJeQ5SYMMSnfr0LlIw1azpLxPjavPvWz7PhjGA+Kt90MkaI dMlw== 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=ekA2GvyEqTKTqcCmn0VyediNRRfm4eukmQVIUJ/lNz0=; fh=DBA+KqNtehNJZ86p09hJoLgUxSp2vUn/M3gdxFQrGfg=; b=GuGSrkyomRkpFv3T1FkJZjBHwgmlYI8HwMbQtkdzXuOB5vSdTvbuPNKtC0iuSPFxlV 54MokYpIV+ggnqpI32JVGzETU50viqGRkmgh4z+C6vPuz4ygD2qw1H7egcLdF0Lpq6Wh DD5R6j5CNAUkrtZdpqS2sJMGHEwyABejkiobPWaN/QxRd83a5Eiqv4MhMfIxGNLlyhEr T/0+p+LpByaupkdPDDmBX9Sb663FV1PqpFehshUaAhIt8bzKInTtCm48++OLj0AHgOy6 +b7CVYprPictDjiURdrO1tVy96RYfweEXFx8CJg4QrLY0r0C5XI015cff1E1xlgEnB2b 0kvw==; 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=1792166960; x=1792771760; 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=ekA2GvyEqTKTqcCmn0VyediNRRfm4eukmQVIUJ/lNz0=; b=Wr9cZIYRrfJjKVFXeasgDbGmb/e7YrsB35IooGI7I7vVNSw5ZFEmb2nOa0zjs9Gamn cjekdYrVhFejxSua/QHMhJ6VEbGEPnhfVxy0ywXZGyu7HGrHkMWxiU8if3ztIj0riM2f 8jlU+aS142OMZGPhXJkSO0tVv2N8+TguoK16bSypxUybUHCcnzcFNCxN0RgPQHLtDzJg orpM7yRQXI6tI8383WB87iQG6SWd/ZUFBpyONnhSQboc37n1vB+DkE0atE0Q2pR7AYbE PrLWgCbbIKR3EFn2H8wS1yj4Pjxh6Sd6iSTw5exVr83IkQ6CIhSxgqoJb+GglqL3UNCS /B8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792166960; x=1792771760; 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=ekA2GvyEqTKTqcCmn0VyediNRRfm4eukmQVIUJ/lNz0=; b=PhZx7C5+zlHgk1FiMbuoOlgLMyXvZSBCpDr2DZyEZRKagKX/BUvjbrK63y37qII9qD k0gDTha/64oCov8HgJdy0J7JwR+ngwLsYTI/cwkLWeerhbu2Sz6aGDbvlK+hQZRk8bez a9bL4Xw3XTAtHqjw6Z8F592s3kuTVTtXRZh/wYrJrdVSEPXqBUppZlt/Ns86mDtxQkQf 87uCUMrwHPfI3F7Lic7rVKbnKqeDzylLzITVVU7qBt1eRoOezTmWugnTLwG1XWLwKWpf zqYlHm6rKNyoB22ULPRmL00oLr6IwAT/wh1/wIpAOOJqHNdYC9Nj25qarZqIULxWKuuH ORNA== X-Forwarded-Encrypted: i=1; AKwUvBzM714iHu48lPAya8KrENf8vciM6liwGcbxCpXNHd6dHESnSnGwGemoxY6oezd94sEWLI07aNvV3Vw=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ6QlCLgGMwO5JNvO1JUtxvH9eAGDQoNVrd0O9ZV/zujoNt8BZZ 1VCaclPsQ/S6sPK4274rwltcc2VuRAGeJU7jHFER43tGNxUjzJHCyf7THZ+sk+UpFDiYf7mjm5I XPKfB6cwtCQmjT4oDHG+3XHA9+iyOxAx1DN5ZMOdp8Q== X-Gm-Gg: AYBFou3y2dfEPb89gugUWQMzI+rLa2/HrkB2NU53AuW4LzjvMgydEq4v3gEJfhaL8dP Gk3RIWzmbzpOlDhUfYSdzxSLkQ8o27q9izsETQCw6/SLIBpq+jFa7RWRcGRjZb6ghgUFws9DFgv 2052GcU9fcgUQldNeSTtbivPZgGHfHq8uqu0p/VfIh5yW1kTNAS0BavoeHfpKsniQ/oHqXG1uM6 kWaHpFUezOVfWU1edjn9c2dZr41cgiYpZawiETXGc8E+fcfvkhXQHMb7Kd4hxC0yobNqG5NgRW1 yAqgWOj5YhHykY3lwsrX2hb1mFjTIgXDpOjKxjrUQIYUfS0Ig7zk6PyUrTA/Ecgyes+cLl9faMk BRCM0KwxKmfYPvXhUUCe/NTBOhiwM28Agpvwn2n0uYu+eCQi9sg== X-Received: by 2002:a05:690c:4006:b0:8ae:a9c6:2740 with SMTP id 00721157ae682-8b0f2209bd6mr1304277b3.48.1792166960326; Fri, 16 Oct 2026 09:09:20 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-27-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-27-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 17:09:08 +0100 X-Gm-Features: AclHuK_xiyk2gcyOJ54yQX5SpudyGYSJxaJAyBmrPRitHx7LJDYQO8xS_rh4vqA Message-ID: Subject: Re: [PATCH v2 26/27] i8259_common.c: remove static irq_count and irq_level variables To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-33051d/1792166962-758824E9-F741EFE9/0/0 X-purgate-type: clean X-purgate-size: 570 On Fri, 16 Oct 2026 at 15:24, Mark Cave-Ayland wrote: > > 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 Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:17:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:17:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452381.1667209 (Exim 4.92) (envelope-from ) id 1xHkce-0002PX-AH; Fri, 16 Oct 2026 16:17:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452381.1667209; Fri, 16 Oct 2026 16:17: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 1xHkce-0002PQ-5P; Fri, 16 Oct 2026 16:17:32 +0000 Received: by outflank-mailman (input) for mailman id 1452381; Fri, 16 Oct 2026 16:17:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHkcd-0002PK-1v for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:17:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkcc-003SLK-Ex for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:17:30 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad24e0d-8faa-0a2a0a5109dd-0a2a4504e58c-10 for ; Fri, 16 Oct 2026 18:17:30 +0200 Received: from [209.85.128.171] (helo=mail-yw1-f171.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad24e19-b57f-0a2a45040019-d15580abed34-3 for ; Fri, 16 Oct 2026 18:17:30 +0200 Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-8871ada1a26so856637b3.1 for ; Fri, 16 Oct 2026 09:17: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=linaro.org header.i="@linaro.org" 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=1792167449; cv=none; d=google.com; s=arc-20260327; b=gQGV/E1r3AYtIYLL6gUbd9bNdlCrAigUDwDh9P2oXLAOrmG+/CoYiF8sZQ1JJ5CrKc 4HXu9L69+LGfBIC7TX1PbiJf7RThvllC2XBYnD6BlqF5T3YJVFsM/NtlgTMoDwPuwD3O KUzHJZBHtWGBOVHQ0DYAmw4wGUUwFAO/dM1f5auPP0GHIknFyYudYqCoUBUPMjT6pQv+ Fjuv29mJgcHiWglyRXt/r9Q20TpJXk7B9MxNEIHFEQlKqrfJ1yqJ4o+Wc8f0i05mUiji Vz9yl5ruccLLe24PqN+M6pfyrX0MU3qpifdwx6DVohxYLXvpFfrX6h5XElR5p6BQ7DQE teVg== 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=luEslXfElde2BGY9lnddmW44YWpRHQM8vQe1gybMur8=; fh=lcCc1/hRSstSjLJ5ejY26T3rBtTsYFltMb5RQzuuAm8=; b=Z9Se7BNMox7kcmL8Ox3EQ3sE789yDg8upgvlvkgvDr8tlXR2EHYeQNW3pN+zGMXV8o tDYBaybjGh/FZ/pN9WE4DSSGnAGYItIu2rGx30ETXuN0heH2+8L6NLuZt4cA2ZDSFdqF Ane8cfXSavioGoBrZZv60WxDxKxj+Kd0HWY1ccVwRYojQOlOP+JDz4OEdscla4QUEuvj 6C+yxSXJcxJv1xT0hN5OCRtXGDFJByWyccf+skGds4IDYRCFBdygzRDqTCl2V9FItgal 8arQvM6H9d1qxYzXf5c8ChhkDWxA0mFPgAO/8DCiwC2Pss+8UDD9KfJs1Cl14UI0OSuY viYw==; 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=1792167449; x=1792772249; 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=luEslXfElde2BGY9lnddmW44YWpRHQM8vQe1gybMur8=; b=n/uCSYZaD487bE3En94EPyYufBalIq4HkDceQuVMX+6LO4urbrOCd8e7JyTFJg4eSF 1U+XCDD2xhQ5YZfK8ET+h1xlF9kynZVIQgtKHOouvzZaEDyVJmXyTFGd/V3Wwl5eKHvo edBsvOMPOAfsHXfJjQ65vhM+0g2rKawyOcuuAyk4qp9tC7vmnd6kdt8aq8+VDLHg1VhD Fm2vjoN4W3x/nqgQEWcVyEaSmV1x4fHk6OL1WM9LT8oA+8htse5DTl8AcTCRFSvIzQjH pKkulp59XVrABCGkbw3Lq6UVFxb6JltILVYKrzRNUDjDwvx0eJMDFj8w/dvvreyUvbzJ cF8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792167449; x=1792772249; 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=luEslXfElde2BGY9lnddmW44YWpRHQM8vQe1gybMur8=; b=IzVFHrNNWgbvpVLqfXkdyvzDdnxSztAXViIk+pWcNWf5L9FakUGZccOALnXeXv2Eik N3qOlvLZEaqzfn46gnU4ypWLr0JpW0MXQ8gE/eWOgp+qO76GGZVL+woYYq6hwxmZL2m5 GpIWzTVWKyl6ED9wcaKeEVnhXhm/X2OPc/StLYSG0psIogRggabGdaFsUbyL5Fky/JDI XHvMylaa1YhDhJYMEKVGL7KSZvJQnN9qV8OOhGrQmLS3cC/BpuxAIo6CX7b2Eo5Byf3U 1aaxdCjNgOc+wUIAhsZvMQy8Evt4Q7rAf38azzwPD01O/wrZHnSX02/Nxbqx0N3y4HiG k2Ow== X-Forwarded-Encrypted: i=1; AKwUvBwcsM6PTuuHxUBZF8QLQiyUmZBDVaV3NHwQkGFWYx//QzG0+ot2pxM9eYbgvyJJOLHlRCOrFz4uGn8=@lists.xenproject.org X-Gm-Message-State: AFq9FYLAVPH3r2wwZ6YD34APZUWt2BIQLUyaUPqOxZ/Mii1nhMVwUzmx MiCQ517Hmp2jhe/4gwIkNk/SCGwl1P8v4NQzOWFGPAGDNdeGtOApIQe5c6FiMR3i5Fcy+O617q3 j8hUdrgXovlTJ+AikaWhnUZ65HYQ73eZ46fMENYip1Q== X-Gm-Gg: AYBFou0tV5kKJl1x+5XogilpSvPSYGAYKTirV1SfyJiDGf4RLKewvWe6T9Wf6uP+yOU 7Rstda21hHkKsDgD14nSOHd9DU+8wt9K7ILGopplAmFSzfVWrdwoGecV4GK4beWFL94PCswYsyd sSFuQehIRcpfoQuJl7ncuqDu8zC1jZVoyOSGZhkU+uWz6L7ZxGDTRmX10QKIKRNcl9ViLDCxHnX HhgbJ6W1ZG04dr8a0XsqMJUYa8ktCjXIU7alpBHBFxDj3rNTxR+dL1hBB00/CSI6N+g82kpvelx mKYcZpp7GQLTE0J/FCFlNeLtjO8Ti9FpBj7PyOygEUqXUOLNd8lU+HzCZPq6g/bKlGzUDJcfMTi NtIrFnI08BkV3ueaaO2xa6W/K4n3S9lTTDxGYpeyh X-Received: by 2002:a05:690c:7107:b0:8b0:e1c8:a47b with SMTP id 00721157ae682-8b0f1f1b000mr1901217b3.0.1792167448757; Fri, 16 Oct 2026 09:17:28 -0700 (PDT) MIME-Version: 1.0 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-19-mark.caveayland@nutanix.com> In-Reply-To: <20261016142031.1204281-19-mark.caveayland@nutanix.com> From: Peter Maydell Date: Fri, 16 Oct 2026 17:17:15 +0100 X-Gm-Features: AclHuK_dauIe-u55ng8KEFu7scxmNaDRrnhTUewCfR-gyxlxpOSMZ0p1OkE_lQU Message-ID: Subject: Re: [PATCH v2 18/27] i8259.c: introduce TYPE_I8259_PIC device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1792167450-C1CD7B50-5E0136F8/0/0 X-purgate-type: clean X-purgate-size: 1870 On Fri, 16 Oct 2026 at 15:23, Mark Cave-Ayland wrote: > > This device represents a PIC for an x86 machine consisting of 2 cascaded i8259 > devices wired accordingly. > > Signed-off-by: Mark Cave-Ayland > +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; > + } I'm not sure the _and_unref version is what we want here. The documentation for qdev_realize_and_unref says: * If you are embedding the device into some other QOM device and * initialized it via some variant on object_initialize_child() then * do not use this function, because that family of functions arrange * for the only reference to the child device to be held by the parent * via the child<> property, and so the reference-count-drop done here * would be incorrect. For that use case you want qdev_realize(). thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:37:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:37:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452410.1667217 (Exim 4.92) (envelope-from ) id 1xHkvX-0001NS-PW; Fri, 16 Oct 2026 16:37:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452410.1667217; Fri, 16 Oct 2026 16:37: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 1xHkvX-0001NL-Mq; Fri, 16 Oct 2026 16:37:03 +0000 Received: by outflank-mailman (input) for mailman id 1452410; Fri, 16 Oct 2026 16:37:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xHkvW-0001NF-51 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:37:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHkvV-006dcF-BC for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:37:01 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad252a4-2eae-0a2a0a5409dd-0a2a450bc9a2-14 for ; Fri, 16 Oct 2026 18:37:01 +0200 Received: from [40.93.201.6] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad252ab-b7e8-0a2a450b0019-285dc906a879-4 for ; Fri, 16 Oct 2026 18:37:01 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5166.namprd03.prod.outlook.com (2603:10b6:208:1ed::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 16:36: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.0522.013; Fri, 16 Oct 2026 16:36: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=b0YlZ+KLAH19vGhVGjje0mM9nSyLqW9NLaJaf+mwVL6s1LOTDO6nPGjkdSHt9g4du6LV/NfsNDAFirELHMSXV+ZUVif4lUsmmqKjLoDeS8tusUxP+c0NbeEMRGUw1CdEEVurb0eORnyhE+s8tu07dCi1ZVdFQGF56OmF5VJ1gY1RkHHtZVCu+dZJKv/QNIZKnf6Del+vI+ajWknWQyPQyAvNsbutd7qJtRDCtkbJINnShXNFwN2RU82y1ikF4ifTTKgQJTMhGSTgc885JXrXXJOeyn9/JE6335CESev9up34YP2dO0ymDytEJdlfIorVxOxqVywFfrF6XEpTzGpoZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qQ+KiWd7RVdspkZs+Vz/zKm2XUDqRv7uJws7Rmry7Zg=; b=s6jt+STMYNpWRPHzsCuonWYPxjEx3XKizpJufbvXNHtJV17cryg7JLLFCvTdRJmuWu5XQkRioo4/nEVVKSbEt+BNJE7Zi2MAC34QdIwxWIBVR2/VSeDAc0Utpe6LqbQOKSYPDFWyW5+gthBoZxwO2Rp09VbKS8N5rowFl+mG4X4YVYpPf4yfqe1eFLBFL1FoSGroENgSwQfBWQdji0l1sraXJ7vMQsPivO6XsHdNn6K/vNLg9VzfSu2ejL1DJzo5FcUgPqZHcI9hCpCUeFNCm0s4MDriB3FRGdFTkJmMPZz0WB/5SbNp0wDvNpUd74N7Gys87oiEClIoMual+JuWOw== 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=qQ+KiWd7RVdspkZs+Vz/zKm2XUDqRv7uJws7Rmry7Zg=; b=Mb+SKqC2GO9EwYSXPm+NlJ12xdJ1I05GFrs9CQR4tsl7q88CUNAKOmFU43ssy5SqxqZq8AoNGnT/kNB8mXKQQ8MeWmt289aU1obDCIk1ek4+yFr52mhpk7R659ReTYMDkVaK6zgTVaUedv6uSe6k5tCHlM8mv+6qL339X0mLLNM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <63025824-d15f-4697-97c0-e90d59fa813f@citrix.com> Date: Fri, 16 Oct 2026 17:36:53 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v4 3/4] x86/traps: reduce indentation in fixup_exception_return() 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: PA7P264CA0413.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:39b::25) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB5166:EE_ X-MS-Office365-Filtering-Correlation-Id: 901a8910-9d4a-49a4-f4a7-08df2ba3b19e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|11063799006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 2xELuQVUsE8OHZSkeCmpQ/gGOF/qvwwacWIAaDYdFbpAsV1EWWk7G/lXv3RiYJ/h3Pw77Z8ujMqMvZKTQvqR6hHy/dtCmIkJ31CXmYKulejW1RI/RMJy0ULp6h5LldLOeWrGL5caHFK3X4mqSa2ZUsQkpqvrI7VhAzfea95Hy7uxqecvDRwBYMT7e2MrPfnzRHF0qtgP53wrG5TUoU5G8Aqn6FlU0GH+15jcFg5EXxfy674MzIjk1AYNxiyn/P37qvNREnKORv2q5Qe3i7dGkVaEkwd/aiJAyEwFfdkTCsydaai8kRqoTpdI+fiYHiD6eeJ7x4YBF0Uw9FVeX2cY7fnj/8xmPnzjmMPb+gd6SXxPd1gqYP7U0quS+hIhVWFiBgxOn5ga5wfE3V4UlRrdzsYFjJEfvVru5qVfltV1KSJy2Xd+R/vs2fw1TS0np35A22UixMaCc2SN9LT+FJEBcz2KkxsMcMuqFIZJTnDVXuZdya5BKh0NIQRZ7Z1VdiTS6NnLJWZPDxUdwBzVmfTlIiacxnBfYs+hw3MoX5qrMKO95sG5ZIa3Jdj/0ocxBZ8XNwmujxbsxDseZ8P9s9rxu0ouL+rzh5XWJfKa6QdAE3MUT91NStPiYiOL89dv0yjAKXgjvJ7JhDrX3bpZDN+/tlrrwtaq4BBS/uX64BB6WvM= 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)(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?cFg0NGdMcVNUNzZaayttRnkrRk5waWNSU3NJQk1wTlg5UVRwS1RZQ1NsNkI0?= =?utf-8?B?bUxDaHhFaDlzYS9kMG9TMEZHcjNHRTdsVlcyQVNUR1l4WXJCdUdMTi9UaWhX?= =?utf-8?B?ZExBOExuV1FrcXA5ekhqQjMrNUMwTWZNZ2tkc0hlYXk5cFNIUUxBZUJ3VHdO?= =?utf-8?B?YkJESE5ZZ3pVN01YeC9SZ2hoVEZiRVlDZExHMUd5M0dzbEQ5c3dDdDA5cGow?= =?utf-8?B?alZhOGtyZVdKTmpLSzdRMjB6QVRiNElybFJ1TUhQa1MrbVd1T3BRMElXaktS?= =?utf-8?B?ZjZ0K1JrZU5maTlscGJlUEdEUGFuc01MeGFDUEFRd05tMEJneVZHRDZVS3A4?= =?utf-8?B?ZklYZVA0TlRNMnZ6MXhQbzFDV1dPNUNvYzV4RVlZSnlHSlNEWElUT1dmSEo5?= =?utf-8?B?YlBSZEhacWFqbk1hSmlENVl6YVNoRGlVajBiS0QxbzBINkYwcThrQkdqZXdN?= =?utf-8?B?SGRtR1MrMG1RNnhFb0FUZXBOMGZ3RENneUo4K1cvdkpvSGJvK0RXL1RicStv?= =?utf-8?B?WStrK1dlNVlyR3pabmJ1dXYwanAzTjhIWHhRbms3TXBMeElzbmtzZXVZSTMv?= =?utf-8?B?RzF2ay9QNi95RWdENHJ0NDFCRVlkdnpGZUcyMU0rMWJ3SDZ3RjRud1BNeVlm?= =?utf-8?B?WC9vQitFTVJJcFdnTXVFUm9ULy9rRW56RWQyMlJ3ZVE0UWFZdGVMMUR4bnQv?= =?utf-8?B?MWpPV3BFa1BxL3B3eHQ1Y1NWdmVkU3pjSGt3QkdkRlRMTWdhT0o5Vkd2Mmpt?= =?utf-8?B?NTJFWFlVbk40SFBHY3JuUjN2UWcwamN2clBDMFJQQzk0OTRNK0xYbFNKYnlI?= =?utf-8?B?d3MzTlZSbzZxZngySStQaDJMcVhvWEtKQ2QzdE1vcjBqMjBDN2czdXlnVWNQ?= =?utf-8?B?dXNuZHpaWG5xd2pRamIrQmF4ZDUrMkNSaWtoRVVvbU8xTEt6SGkrQk9iejRZ?= =?utf-8?B?M2dTdWk3eld5WkZZeTY1QmxuSGtpakVjb0cyZk5lVUxPdUlFV28rVTJKd0l1?= =?utf-8?B?STJVMTh0OXIwZkFpRmJKL2lEbDArTU01dC9DREJHMTk0MTRyQUhvMzVDdkNC?= =?utf-8?B?dG1JQU5YQmFBaWZNeGtVUHE3ZHBpaDNVSmhkaTVvVzk1ZGRNRXBuZmJ4QTlx?= =?utf-8?B?MFNacTBTVGYvcTlhbnJ4eWMvbnVUdXpYYmRDYnphQUMrcXVsUG11NlA2b3BI?= =?utf-8?B?Y2dwMm5zdlNkZTNpY2gwRXJUd3lIbzhBYXZUOFhhSHJwcENKdE5Ldi83Qk5E?= =?utf-8?B?bHNaTU56WVVuWjR3V0p1UmYwYzFQcU03bzJxK2JmZ0lwM0puc092M28zUzIy?= =?utf-8?B?SUNZYllPemZORDY5SFUxaDFVWS9BVlNxOXNwMWhveDlXNFltOWIweGZ2UG9L?= =?utf-8?B?M3ZyNDFQRUVKMC9CUmZ3enRVbjVQbTI0d1BWbW80WlVyMmxQWHBNWm9SZmJj?= =?utf-8?B?MDJaZFhibDlLeTN5THVXWmMyTVBMdFM4L2lMMHVuWmh1dEM0VDdqSmFobVZ0?= =?utf-8?B?ZVhUNFNHaFB3RFhtaE9wVHFub1Q1dFlqZ3NQWGg0TkpUeGdCU21yL0VsdTNV?= =?utf-8?B?SFFuN3l6aEtid21IUHRSVHB6ck9uQmd1OXh1RlBncUcyWmlOTHlRSkQwRzR3?= =?utf-8?B?V2pDMnJzWWdtczNMeVBaVW9yQTg3K2k3MkJMRkQva0VraVYwK2dXTTQwQStp?= =?utf-8?B?WENvdVJLaWg3ZDlqMGR6YlcybnlCbHhmcmV6bm5EZVp6dXdGU1VyUzNBb2Qx?= =?utf-8?B?UmNSTi9tSkZ0WDVWaWZxSS9OcEErLzRjdUZYRG5SRFZVUXJ0Z3Rjc2t3YWxK?= =?utf-8?B?ZDIzQnluSSs4MW5ZVm5oTWNiVUZPSFNFSHF2L0NRR3RYVmo1L1lBQlVjRytB?= =?utf-8?B?dkJaUmFhd3c4MjY3b1lLVmw5Mi9va2JsNFRXaEt6TWxXV1pRMVFnc2dJNlJT?= =?utf-8?B?aUI2cDB0L3hDeWNsMDZhT3RqY0c4U0FJOGJ1OFBDUkpvMVpQZXZ6U0VNbWE4?= =?utf-8?B?dSt4SVJva1l2NWdSNUFCYmN0M1M4ancyUWNBUUxqYVZEaCsrcDFrMWNsRUFL?= =?utf-8?B?cU1ZSlJUd1NmMi9kbjc5Zm5INCtiMW5lbGZNNVJNa0tJbm1CMHZhMlcwWm5j?= =?utf-8?B?QzVFUERoK1k5U1p2K1QxRjRoUitaMjF0eUU3Q012NkxGaEdXUHBiZnJlcXA4?= =?utf-8?B?SWhzZ3NHa0tnNU81c096YVRtVnB1OFl0Y24xV2FLdE9Jamk5enZLV251VHJW?= =?utf-8?B?R21iZmNWQXVoakE4WnZEUmNqeTJscERMcE9LMFRSakJZM2JqWGVJZUlOMFBZ?= =?utf-8?B?cHhUUFhPQ0RFZmpzREJQMFUvR3M3Wkx5VWNLRnFoNTVLSWl4RCtLZWtxdHBT?= =?utf-8?Q?ikCjgYn+FN1Rt0Vs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 901a8910-9d4a-49a4-f4a7-08df2ba3b19e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:36:57.1176 (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: UWkB+yWzI5MrrdjzfSUHDBN4VdPqxSWJPrjfvCx3uixIofK5IV3ROyN3A0hLf8YNtRblYykrwtE1CF+OxWBuTMWijf12JT0+ubi+cQkxMss= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5166 X-purgate-ID: tlsNG-42698a/1792168621-AA0C59EA-1BE4BB71/10/78276251493 X-purgate-type: spam X-purgate-size: 378 On 27/07/2026 11:27 am, Jan Beulich wrote: > The earlier "x86/traps: use entry_ssp in fixup_exception_return()" left > unnecessary scopes and hence unnecessarily deep indentation. While that > was intentional (to improve readabilirty of the diff), rectify this now. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:46:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:46:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452425.1667243 (Exim 4.92) (envelope-from ) id 1xHl4U-0005Ql-4E; Fri, 16 Oct 2026 16:46:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452425.1667243; Fri, 16 Oct 2026 16:46: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 1xHl4U-0005Qc-0p; Fri, 16 Oct 2026 16:46:18 +0000 Received: by outflank-mailman (input) for mailman id 1452425; Fri, 16 Oct 2026 16:46:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHl4R-000512-Oq for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:46:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHl4R-003Wv8-5U for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:46:15 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad254cb-8faa-0a2a0a5109dd-0a2a4506ca44-12 for ; Fri, 16 Oct 2026 18:46:15 +0200 Received: from [52.101.61.50] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad254d3-195a-0a2a45060019-34653d323dda-5 for ; Fri, 16 Oct 2026 18:46:14 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SN4PR03MB989476.namprd03.prod.outlook.com (2603:10b6:806:219::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 16:46:05 +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.0522.016; Fri, 16 Oct 2026 16:46: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=Kbq0hyYdMiu1S7JMCXKYft3JYLuUmr1Fv0rDoCFWmaYrvU5fY56NDsuSi2aoOfTauFNbqb+o85qcMdstJe/UWvJ6APCdQdN+FAshVpsW3GG3QBRijDq+jeciz49QqJa1Gdh4LDCd0UY80qdu3LX/M9v9IIpQvIU4snCzDNL4bwWqUzZjAZvGtf+esHkIAWimzLDdrNc5/KeIgkwDuuIbNryJwV8JhIktdstf3QHD0dii/kg8cMwfed6xBV6CY/d9fXrjhtXZlhYoYBwN+7JIpZvRt9rM138XpkNup2JwLQusN+tjjYpaENjGwpTvwGtth+GNcOy+KlvGEXAozk8GfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TrJ9orQ89zsDoJwp96G3PNFcc/ZeuhXyKMJiiCFDl3c=; b=sLW6Ozom1StIrJuL4n+2OzYNqrYrEsTSadI4y5AY7Lxjxqhm9gSLDXQYgf9rNc/KuIBRm4jEBbtJILsrJ6KMrx3850XbxOtQmF4MefNPNgGBioWN8BYTnYJxSLoW/X+aSINqUuTCb25tVBaNtmUcOteRz3CTU+wHh6wi2wXCjeuCoSyyiXOKEBJEREHl9XzlD+sNLS3B/frNp9KjLkBydu4xua83Z/IMeJDbAM5VdsLmFXrgVWBLNc5KnycOpsFQy0xQKVR30NH/CUzidikiXiazydlwhvW0w1dlk9KOSdn7rI0J9SSJ1YnNITxuzP8KhBWBY6H5ELXncUqWHm7aFQ== 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=TrJ9orQ89zsDoJwp96G3PNFcc/ZeuhXyKMJiiCFDl3c=; b=p0W9VEqbK69Z5m8n6u+hrrlF61gD7wLNJwAejDzOhKODlwljhC4PcHpfdWRuHsHf4piBf7jqFxAByD2BrYsH64MjGgERvAWW+k9Fl50SVBZJMgPouWER/A00slhmvF0NixRHd6JTD/82BRxZBRFNFC8oXPh3oN1LfL1eCgA8dEs= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v4 2/5] x86: extend mod_l*_entry() to optionally return the old PTE value Date: Fri, 16 Oct 2026 17:48:12 +0100 Message-ID: <20261016164815.3109065-3-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261016164815.3109065-1-kevin.lampis@citrix.com> References: <20261016164815.3109065-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0586.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:295::7) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|SN4PR03MB989476:EE_ X-MS-Office365-Filtering-Correlation-Id: f0b26946-4531-4df1-2d36-08df2ba4f8af X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: k6CjCL9VqK6w2ZlEVSdL5sWZi5dqZOD5zNhZRlbQMEKMGOwABAL2VyURk4W0q+Fil+JjESkAcu7wuzfY+Hh+Ol00cqfwnBsAdkj+494F+LaPqEZ5vw+3dJpE2At4WhUrXeD5FZNlQXSe6Nsoa54AOFLpyeOTiRU1Os3FJCNPslSxPMcz3EmElJt3rDPav5L7j8r27+L71Fgh9fBB+iP0rI71YluypWun0xh22u58TeX/z1LJm8evzFCnEovGZ78StJP7jSrsUNXTa8cT0QREXSu+ZFiJ6BPpjh8fuhoimMocZTw6rEY+PIBOY3M+xWN8xzcJwRFv7goY2MXhHPJeSf1wReTmETJHfNRzIBALWKxHqS2Omkg3WXRT75Tdo2HgeeVLVDDf0uf4A8OQnXAAN8UP43jkz7cjsjBLgpbPWb9XNXA9256s2sdbdALye+SynsP4R460CnTJmYvXONQVQIVDdmvPJQybw9noEml4V8ZwBAZcl+9bccSIebj1OXYRIh6mCADONAISLsxjZhYY6widh9fQUJlJV86WV8ZXXzD3fYEgJuuY6S43I6tQzDR1ccIBdhyLhSLjCcvrEN/Rl/LPynfBllniEXt+YVKZCS5q5zTIeFsToo+DRh2hdtP7hMvwUTcVpayzX7CyFLYw6WpTbF4z9u5LiQ/nwyPI3EE= 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)(376014)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6TsCPS0Sp5bwqQXGxGOqmHaQg+TATD0cpMi6XMQT1ahLlWsVAAmCuwkBbEmn?= =?us-ascii?Q?HDL+eBeyTTwtnPsST7SR/ctLZm6CL+oRaVhHi68pVE26cAtgwfPhmbQcmYiy?= =?us-ascii?Q?iJxqvZFbeS84G+cklj+0CvMPAILTbyhzv92uM1d69kUB8/i06c4djjA7FMak?= =?us-ascii?Q?J0Bg2MelWKm0Ec1iM08uw09+K4VD0O6e2dTKBt9O/gxYIk4cPfP0iXJrqgnb?= =?us-ascii?Q?w38OtRGfq3RNb1Nq7CmE9KlMtBP6m+GqQRK2dZA4FkDzTWoEgPUNdiRk8+ri?= =?us-ascii?Q?ugQGldObB1ktLZ8DdpX7hjuNiA09xkiJPZ11ii4vcwH4dcm3gzdAbqN36ZYo?= =?us-ascii?Q?xrpFiy+mARkHCIyRlOAEyc33PcLEAlgjbRKOKHT6m2mznfU8jF8MJzOXn1H6?= =?us-ascii?Q?wpVYHN3isGXPPKhBA+Lztd7yauoSezeRQkPGxLCd34CBri//MawAlLItYU0I?= =?us-ascii?Q?FPll6wgJ3zD0gXsNM70721KaITETAoZpx76MtEKZLjALE6t4/W5KWj0jQ7dP?= =?us-ascii?Q?x9fS7EY7+NhkDW763ai1HekQjo6GFYAm95ke/88FxuRo/v8258FbWPd4O8+H?= =?us-ascii?Q?0IA4GLOx04Dx4vIiZVcEBVdr2lxVKw3HqhobSlbQ/qbS4GwEvM5ygthvnAqI?= =?us-ascii?Q?zXdoogu6oYIU57X0e93acc9ozVAQMUsjNCXSsE+xCw8pPsFfCDQ1vn4mvZn7?= =?us-ascii?Q?K/Y47GEg4om/7zAdtgXVSL3atKQEarehHLkql5gKedS5nULGQGeM/yi+WZVI?= =?us-ascii?Q?9WUhJgUayeY32JA5LoqEXNvUpWGWPxig6iOj4jkL6qUkFajp2GPow6S+C3jJ?= =?us-ascii?Q?IVBQmImMvc7Vp0u3qsmd1jIZYfqi/J2wdscGqNU6OQnjUl13z7eUegePGIJe?= =?us-ascii?Q?YDcBnzVE8pmE/3XlLQjALnCW1XwLSsKT2jY9uy9AVL9NEKr/sKfFFnV5jbUe?= =?us-ascii?Q?pEah3A/EZM5tpN7+4kdrRT9ALjcY++Z82OBoXL6D64K/iYClJ9A2jrwzTiM/?= =?us-ascii?Q?bR8iNfkhQkhb5ze/mfOueUmVifoTGAU5vz0l4CwlqACL5iqUPQZJiFfzKAnd?= =?us-ascii?Q?Ep0K740POiSxLj4wfWskw/WP9SA6MNNJe3ePybz2ZZxUvOf0F5+f4BEc1t0v?= =?us-ascii?Q?YPObpVURb7ZgbDMc7CNAYF70eRUjqu3/s7e1tR2D0LgiZAPNYV+mu795bIH9?= =?us-ascii?Q?C5mIVr0nF9aWd1cU4lRwpfvhXEni0TFHsFHKftp2kNFoWVW/k6XO2F/lCyuL?= =?us-ascii?Q?6JuKxg6w2kyKd1z2p1q8bira5pH4iDFMaos5hkTgL8JMYrLG/JdWUuK8vQ1A?= =?us-ascii?Q?b3rs/ma1HapSdNesy7jk9iSK90xp44f/gHevUwIG3iXiwYbOdfzpRWgZs/v/?= =?us-ascii?Q?lyn9Cwo/cEEoq8ssCQCudubOiXSlT5PI28MgmcVE3no3E8jhchDNq3wYBwSA?= =?us-ascii?Q?Ke0I1fcxML9equtoVbdi7Ot8ii92Tf6MYO08lMspL9Dk31iouGcl69xGiIlx?= =?us-ascii?Q?W+j0a4t1kb64/vBQuRryaP0/8jJRBCM/oUHMqwLTD0Z+HtD6hfm++CGSLeY0?= =?us-ascii?Q?V+Zf/6b1kcHBi6MSFZ+aWm8fIhc91G/HNiByoizfHewjHnvRPO8qheQy6OL+?= =?us-ascii?Q?TQhGjd4/m0wQfe2sY27ikt0vd/3SC0CHbciNpggNdzPKp/tRlbPJC/yHTGzh?= =?us-ascii?Q?breTMGEKtM79a+g3ch2P1IkU5K0fFRVfc0HpS/WV4QooPqvljiW9UBLqfv/H?= =?us-ascii?Q?R83fhQxpoQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0b26946-4531-4df1-2d36-08df2ba4f8af X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:46:05.7435 (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: FZcp4ImYW30Fwc/I7rRSwL4x8ZyGNytgcmCkUEuRzoyR8UOQm0KQLuabjfuoKXEzr4U5Rv6Ez0FytbiNDjhcmQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB989476 X-purgate-ID: tlsNG-16d1c6/1792169175-F74C977B-F3376E54/0/0 X-purgate-type: clean X-purgate-size: 10844 Calling mod_l*_entry() with a valid ol*e_out pointer will do atomic CMPXCHG to set the new pte value and return the old pte value through the ol*e_out pointer. If the ol*e_out pointer is NULL then old behavior is preserved. Signed-off-by: Kevin Lampis --- Changes in v4: - Refactor how UPDATE_ENTRY is used - Update commit message to specify CMPXCHG instead of xchg Changes in v3: - Add swap to mod_l{2,3,4}_entry() Changes in v2: - UPDATE_ENTRY now returns the old pte value instead of using an out pointer --- xen/arch/x86/mm.c | 106 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 84 insertions(+), 22 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e42cd33c0d09..609c8595a487 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2193,7 +2193,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; @@ -2254,7 +2255,11 @@ 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); + intpte_t old = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, + update_flags); + if ( ol1e_out ) + *ol1e_out = l1e_from_intpte(old); + if ( page ) put_page(page); return 0; @@ -2277,14 +2282,25 @@ 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); + { + intpte_t old = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, + update_flags); + if ( ol1e_out ) + *ol1e_out = l1e_from_intpte(old); + } } else if ( pv_l1tf_check_l1e(pt_dom, nl1e) ) return -ERESTART; else - UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); + { + intpte_t old = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, + update_flags); + if ( ol1e_out ) + *ol1e_out = l1e_from_intpte(old); + } put_page_from_l1e(ol1e, pt_dom); + return rc; } @@ -2294,7 +2310,8 @@ static int mod_l2_entry(l2_pgentry_t *pl2e, l2_pgentry_t nl2e, mfn_t mfn, unsigned int update_flags, - struct vcpu *vcpu) + struct vcpu *vcpu, + l2_pgentry_t *ol2e_out) { l2_pgentry_t ol2e; struct domain *d = vcpu->domain; @@ -2325,19 +2342,33 @@ 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) ) { - UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + intpte_t old = UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, + update_flags); + if ( ol2e_out ) + *ol2e_out = l2e_from_intpte(old); + return 0; } if ( unlikely((rc = get_page_from_l2e(nl2e, mfn, d, 0)) < 0) ) return rc; - UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + { + intpte_t old = UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, + update_flags); + if ( ol2e_out ) + *ol2e_out = l2e_from_intpte(old); + } } else if ( pv_l1tf_check_l2e(d, nl2e) ) return -ERESTART; else - UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + { + intpte_t old = UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, + update_flags); + if ( ol2e_out ) + *ol2e_out = l2e_from_intpte(old); + } put_page_from_l2e(ol2e, mfn, PTF_defer); @@ -2349,7 +2380,8 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, l3_pgentry_t nl3e, mfn_t mfn, unsigned int update_flags, - struct vcpu *vcpu) + struct vcpu *vcpu, + l3_pgentry_t *ol3e_out) { l3_pgentry_t ol3e; struct domain *d = vcpu->domain; @@ -2378,7 +2410,11 @@ 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) ) { - UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + intpte_t old = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, + update_flags); + if ( ol3e_out ) + *ol3e_out = l3e_from_intpte(old); + return 0; } @@ -2387,12 +2423,22 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, return rc; rc = 0; - UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + { + intpte_t old = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, + update_flags); + if ( ol3e_out ) + *ol3e_out = l3e_from_intpte(old); + } } else if ( pv_l1tf_check_l3e(d, nl3e) ) return -ERESTART; else - UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + { + intpte_t old = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, + update_flags); + if ( ol3e_out ) + *ol3e_out = l3e_from_intpte(old); + } put_page_from_l3e(ol3e, mfn, PTF_defer); return rc; @@ -2403,7 +2449,8 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, l4_pgentry_t nl4e, mfn_t mfn, unsigned int update_flags, - struct vcpu *vcpu) + struct vcpu *vcpu, + l4_pgentry_t *ol4e_out) { struct domain *d = vcpu->domain; l4_pgentry_t ol4e; @@ -2432,7 +2479,11 @@ 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) ) { - UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + intpte_t old = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, + update_flags); + if ( ol4e_out ) + *ol4e_out = l4e_from_intpte(old); + return 0; } @@ -2441,12 +2492,22 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, return rc; rc = 0; - UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + { + intpte_t old = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, + update_flags); + if ( ol4e_out ) + *ol4e_out = l4e_from_intpte(old); + } } else if ( pv_l1tf_check_l4e(d, nl4e) ) return -ERESTART; else - UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + { + intpte_t old = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, + update_flags); + if ( ol4e_out ) + *ol4e_out = l4e_from_intpte(old); + } put_page_from_l4e(ol4e, mfn, PTF_defer); return rc; @@ -3318,7 +3379,7 @@ int new_guest_cr3(mfn_t mfn) l4e_from_mfn(mfn, (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED)), - gt_mfn, 0, curr); + gt_mfn, 0, curr, NULL); unmap_domain_page(pl4e); switch ( rc ) { @@ -4156,14 +4217,14 @@ 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: if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, - update_flags, v); + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; break; @@ -4172,7 +4233,7 @@ long do_mmu_update( if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, - update_flags, v); + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; break; @@ -4181,7 +4242,7 @@ long do_mmu_update( if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, - update_flags, v); + update_flags, v, NULL); if ( !rc ) flush_linear_pt = true; if ( !rc && pt_owner->arch.pv.xpti ) @@ -4521,7 +4582,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 Fri Oct 16 16:46:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:46:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452424.1667235 (Exim 4.92) (envelope-from ) id 1xHl4S-0005Da-ST; Fri, 16 Oct 2026 16:46:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452424.1667235; Fri, 16 Oct 2026 16:46: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 1xHl4S-0005DT-PY; Fri, 16 Oct 2026 16:46:16 +0000 Received: by outflank-mailman (input) for mailman id 1452424; Fri, 16 Oct 2026 16:46:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHl4Q-00050S-Sr for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:46:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHl4Q-003Wv8-9h for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:46:14 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad254cb-8faa-0a2a0a5109dd-0a2a4506ca44-10 for ; Fri, 16 Oct 2026 18:46:14 +0200 Received: from [52.101.61.50] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad254d3-195a-0a2a45060019-34653d323dda-4 for ; Fri, 16 Oct 2026 18:46:14 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SN4PR03MB989476.namprd03.prod.outlook.com (2603:10b6:806:219::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 16:45:58 +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.0522.016; Fri, 16 Oct 2026 16:45: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=jOoZcEMm2jGMlA4U1zHTpaodLivu6WZgfgIXWP255IjbtO7P9/xNwXqdRRo1OALVnZKNMJngOSc8+E6qwDjoyC7K8utInVC8FTXQ2SPbnHrsJD2KNiAmBHrgJOgKrSQjK2pN1WIfPT1biXlaAijj6ehelevBLVU2c3A0OnmbWANPGwIhE5KsRkMko4A1cw7kpz1BFxKI/nYt5tJ4Ueenj3X3RBAlNayLkNn4THS6BImt5+W/7VbpYBZnoXSM6AYSUMuYSYvstvmnh3PNsaTHwjSqNsM4efCw+/W69u5hUI33O10cobGYGeyhhJ461Ma0I553mzLmbf/Exp8sC9kmKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eis1qaNSuPfjas+GPjDLVyNpWEHsWLbEBEHoQsEMCHs=; b=xGUamh1TSo7wMfVeiwI/D5psjf4d1uQfWbGQwVO/voCPDquEfw6NMCJZq539iF4UFLAkxgqSVQKJe9QhFxCqDNxwIkelcUZeu1wkSqymMtCiVxy0DNZvkGBXK7lwKQubuQyUJzs7WwXKma0swebtrE5LLwlC010pJbss731nH3lF+/O3KIBPOVMyS6dq57rYWdVHOV8KHaVNEDUNK4GJkBGtq/gQjGsXKrrbT92BY2zbtvQmVP8TvW29lQ0VdTQspYz8mSxw581j2jKtpYlasbfmAzCeiyTCxwjdWAaqSlWBagVCIiXD8qfvkumKdI5QC8Wr/BcLkdpSgp7ghAWFdg== 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=eis1qaNSuPfjas+GPjDLVyNpWEHsWLbEBEHoQsEMCHs=; b=blwpMtxfA+syIjiHmaSRH54h8jXEfcOJxaChYJLa7pmlyki6vbqYYVb0XvE7WZO+M4lSLe7viWe3k2dMC7nATAVYYgaaUG6N11onkRoYcf+3+LWg1gBqLbnOkKRXabDwcmZ8okx6GkoUyhyYxkPaKCdHtfMpqIzFiNlJZ6WgRLM= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v4 1/5] x86: extend update_intpte() to support atomic get-and-update Date: Fri, 16 Oct 2026 17:48:11 +0100 Message-ID: <20261016164815.3109065-2-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261016164815.3109065-1-kevin.lampis@citrix.com> References: <20261016164815.3109065-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0555.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:33b::8) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|SN4PR03MB989476:EE_ X-MS-Office365-Filtering-Correlation-Id: 1ec3c764-16bd-4297-0961-08df2ba4f43d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: +7rG3W9t9ENts0amfRgh3VOKS+EXNSGIjI7JOM2VCM6uhTygI1eW3mrAp4FyRjeDF5Ik0vxAzCLG63ThCHomCbJY4UAlIg2mGM/c08yD3sAsPUbHSkCM1Hr4H4ABM7Ul8M45AFJbXNr+2AnxPb7WuOjrKNR3n0xd1gJoQBVEO4HyH7YzOOhG5gr1JakpqYUSZU9xqC4fBSr0P/1y22NVlmLM1ykOFMEvQuIsdXFnTJ/n4Nin0Wr7PfYLi5Ilqbv2CtJNIshjDsDoSQTGzzSs+Q3EB0qSzwA3VUKc0upOCiT3RjsPjE69OisQF+EAjp6JRsAOFv/CYoyPmQ0lw60ge7FZ8OOBcVJq11KgLszVN/8QDxYjoUAZ9VKNrpSEvQS7sLLqWHIWv45hq89bd+eP98aZcpVfjuZxA5krDOEY/NAFRzJcEs1AAR3AQrkYmZFysX2ud5fQbAdBEeTeO0HFhX6lNDILJPijkz6uteEYDr2gduWRLS8wXPjedUfwJ1q9CqIVtsZIzUQFo93s1jME6vtv85iUncSsi1d6vsyZa9sLlSiL1HnCwTVNxuhrIyfOdBIzy/+ElZO8gicQh8TDaDoJT3SfSnnYyjOhszxAorSZOYgJl1OJqiT4Xg20XJ+fA74VdtyOZrlMEz1NGqsbxw== 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)(376014)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?vgnU5TXIgTV382rL8dzEq4faKMTqxlCs+3PRuzwIr7KiLK5nEpvAmdd8hTP4?= =?us-ascii?Q?6mMBsTFZ4v8Dc3yrVLEGumIg+GvM/69Z/a+zAYmXGvqHODaaaWTCmla584ou?= =?us-ascii?Q?+I0PpyRJVctZGwhDJ4dx+L5Sgtn0kf1kTW6ohMLmVcqM5TiGky0LZ1vhSD9t?= =?us-ascii?Q?qZOzxy9zfO7fpi8I3i6ITrINYRe7uUpavjmSkGF0SBizBSCBi4lCZEYAJ+4W?= =?us-ascii?Q?w4FtzGETJZFjOM9tdxIotjmMMoIbY2cajVZy/HosGyyOH+qY5B+VXwwWnhGS?= =?us-ascii?Q?kclwLL3mZVHcWZf3+cNsI2Xy+lzrFpdujpoMU1Nx+ZXir5PTSfsLmaQHli2G?= =?us-ascii?Q?kHHk0CwFeuBY0yL4zo6hqwfg2Yy5AVYEvaWKYoloh9/+J2ZbfYgpeV7x7/F7?= =?us-ascii?Q?SMX6wokibqPnezje81spGiWj8zZYB6HxnDvXSBLqsQl8jIrfTPJZVQaxiCUy?= =?us-ascii?Q?6up0GBBuJUckLJqrzsac3bInJq1CelXprYrjURwLUOe/dIfEaoGAxOicjrwx?= =?us-ascii?Q?bVWx6Dx4sxaGBNAH55ZsJpeA3Jwu0mjSSxxwWutDHJtDjwsJ77IHl8nSo1uG?= =?us-ascii?Q?F7jftM4oXA8Hb4quiVvZTa2cT3fOIrTBYoxzm8qpYEgEUf2OO8fyH0cm5Fjv?= =?us-ascii?Q?RAOUmSecQI7wFJcQbFH0lA5B/UxEMinzbNpy0CLCr/UFQYlbwW2YKe19T5wt?= =?us-ascii?Q?XzJDgLPAGkExaDaZzWvpb/rrTLyGZRwwcbv9OD56K82kxxfS9NCKAblxS6zD?= =?us-ascii?Q?A+5CAgcXR+EznV8604kGn78y+GhI5J+SKaR2uL3E58TXPo9umvoNJt+gJPh1?= =?us-ascii?Q?X/5JPvZqALSNKvVLNw/SpRHdRH1oP8SRPC7rcdeLGzWEpzFB+UrdPu9WnU78?= =?us-ascii?Q?CdRoL/rJu9ooV6QENRBymRQmPoiiWgAPrmhdrh5r8PUIzsWVHSsueASp57g7?= =?us-ascii?Q?N1gfxE5B8Csl01GQ46dGlvOeMiWV/M02tKKbqUoDN0x26K1giMXqAg5NHRgQ?= =?us-ascii?Q?HVvzRFKm+9Lzlt2431OvyJfs29DteuwYsBOX1M+d4ZopdpiPWw4wBAYPkrup?= =?us-ascii?Q?3BAqGH6aWGSDJ4mDxpXo7whJ6yIQnVjk3RT/UHjfgya1Qd8420M6y9TwREkE?= =?us-ascii?Q?iBtvN6Np7W94sZY3Vhv7zjXmil/sg/3HnyJSccmqNP/KGbDHZasJg3icZpvg?= =?us-ascii?Q?/WOXBUlMfYI8ssrA2jCg3t397KBb5apjOfMXV+Hy1XZltvMEelZWAxZR9L5T?= =?us-ascii?Q?JlbgcyfEzdT2+kwEtkhk111xfPRCiAWcFzXyG7EsmGM32PZG8RyFqgMsPCob?= =?us-ascii?Q?6G4KJDSS/na5HY76DMwidFh3vWG/cdysfL7tYg0M4wnH5kLCl5NIPPHyuA96?= =?us-ascii?Q?WhTlvEvEmdiip3rw+HG6yUOHJtw6yA89Mjb8v3digO3uhsahfX8h8rurnGp1?= =?us-ascii?Q?hPxj44Bdcp8GfGU6GZqvpmVt2N0eSVMMKbpBQNpWRk4jb1PqQESeU8wq+LTE?= =?us-ascii?Q?WGiCtvEZNHtC4VbRoX/TP30NBx0LeKN8zz+IBnNHs4BAXzymTASfKQVJo6Um?= =?us-ascii?Q?69FoOU/0DXzbINZ0atXGBbaPyVexE5slmrlp0xdg8MMs/CyCqoux5dQyJiqA?= =?us-ascii?Q?sH7YnQX5H+MYJy4C8PbaXt1wQwuNNAfpRiROP1odorLqX502/gACCYpGqltL?= =?us-ascii?Q?NHJ+T64ADmMziX35b1aJAqJizobzTxHHjg8F0ZG3uBHeUju/aBJ72OxazCAp?= =?us-ascii?Q?XgYM6dU2/g=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ec3c764-16bd-4297-0961-08df2ba4f43d X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:45:58.2844 (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: fhgvS/q7zg2YbEBAEakLo7qKpTQBvFZBpVpLSDKRSiYJFjirKSg2sLs7fzoFKueOtd8PDGC0qJoWsu4tYzkWWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB989476 X-purgate-ID: tlsNG-16d1c6/1792169174-F7CCD77B-3C3B584C/0/0 X-purgate-type: clean X-purgate-size: 2001 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 v4: - Remove UPDATE_ENTRY_SWAP - Don't move the backslashes in UPDATE_ENTRY Changes in v3: - Return 0 in the paging_write_guest_entry() case (update_intpte) - Add UPDATE_ENTRY_SWAP to convert return value to correct type 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 | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/pv/mm.h b/xen/arch/x86/pv/mm.h index bfee0feb7b21..381a0e25b986 100644 --- a/xen/arch/x86/pv/mm.h +++ b/xen/arch/x86/pv/mm.h @@ -64,16 +64,22 @@ 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. + * If the SWAP flag is set then does an atomic swap and returns the old PTE + * value, otherwise returns 0. */ -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); + return 0; + } else #endif { @@ -95,6 +101,8 @@ static inline void update_intpte(intpte_t *p, intpte_t old, intpte_t new, old = t; } } + + return old; } /* -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:46:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:46:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452426.1667250 (Exim 4.92) (envelope-from ) id 1xHl4U-0005WR-Ig; Fri, 16 Oct 2026 16:46:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452426.1667250; Fri, 16 Oct 2026 16:46: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 1xHl4U-0005Ug-CX; Fri, 16 Oct 2026 16:46:18 +0000 Received: by outflank-mailman (input) for mailman id 1452426; Fri, 16 Oct 2026 16:46:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHl4T-0005Ey-58 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:46:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHl4S-003Wv8-ID for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:46:16 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad254cb-8faa-0a2a0a5109dd-0a2a4506ca44-14 for ; Fri, 16 Oct 2026 18:46:15 +0200 Received: from [52.101.61.50] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad254d3-195a-0a2a45060019-34653d323dda-6 for ; Fri, 16 Oct 2026 18:46:15 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SN4PR03MB989476.namprd03.prod.outlook.com (2603:10b6:806:219::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 16:46:12 +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.0522.016; Fri, 16 Oct 2026 16:46: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=YNQNZocNUBFzmhYJrFPpeqWZPIpRXTIUiw6FBJkslOrTvI5+zYvEGB1mbubjqHxDTxGvzovX/6QqHIScwQgV18w+jgZXWjlyEItRMmBpA5VaNlItU6v3en1qFIpgDVcR8pcAW7hsQBP0BIa5sER7g8BlgzP/jL/+Symld/jPDdep/MTurVDawOQR2Pjp2xAhSwvkf0bM0UwgxQObJwjh734gr86lrW5RAtVTI8prsIRQU4OpugD8viCV0lPffZM9XUWVe9eOj/GBvQnulYVLodbAq234sB8x0xzcvfR8cm37UPZ4uQZS6ESa5OI89Lk4hzmqmkz62c3CYPMEVV9dKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6mavEMVvcnQN/IdyCOyIwkBgy1KJC7/e6Fk3Q8+9/VY=; b=hZj8Lgfhrh0QqTgDwu482Y02gCqauvF3e1cZqeMkdSJ5D1IsR81MbuRT4whD4GXSUd0UfX5PhfGOgWrOBP9jpr2KjvyRFjNUcI9g0gL8DfXi1W+SXlNrCxF9er2oGAZSNjaYRXHkFp6fZ1mjIna3WWyN45Fdj5HwBUjfx18ubR6ueOEiRDNw6WkZa5co4YjTRwdi75Cwdu3Qp76PAcfpRkJhAbff8yyWBf6EiDjKQIAeqYLiMCVn4GSuwXiEq8koEUhGqS3ogeSgglotfweRBDW1uU6qoHw4J0f/LPWDmGfvIMrbEtoxmdzPCajX4+mQiYvBy0f/Eg9lEy3jCZEK/g== 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=6mavEMVvcnQN/IdyCOyIwkBgy1KJC7/e6Fk3Q8+9/VY=; b=jp1SAczfYJQGEo58bjnMCBVvYJxMFgjNryhZWd7gHCtjONFt6M2caOcota9sk8Yl/H1JuQxp73ES0/sWiM8iK8xxPfGz+ICBPw79wg3dIHqxoXW5QqZk5Adanw4BpavNrfD4fFwgb87vRPNR3+AYz0/VvhGlqousakuTRL7rZLo= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v4 3/5] x86: extend do_mmu_update() to support returning the old PTE value Date: Fri, 16 Oct 2026 17:48:13 +0100 Message-ID: <20261016164815.3109065-4-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261016164815.3109065-1-kevin.lampis@citrix.com> References: <20261016164815.3109065-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0430.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18b::21) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|SN4PR03MB989476:EE_ X-MS-Office365-Filtering-Correlation-Id: c65a21fd-69d5-4c6e-588e-08df2ba4fcca X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: pIKiSgPFJX/KMFhV/znkzKLN2hnQ7/mM3vMR1lx9K2XHdrBkREE9SSgzKHf0vsV45M6uwuuHWPHAKMtC/mpmT8lK0mUmx0mnJIk5FdA30c1tQ+GiO1gcJQJuFOiBhy7POD+AqAfjK4RxqiVP0MNDFP2WdplIQS+/0gNJPc12B6Y/9z+FZshh2AN8d3k+mCOqvMLYY03jGV4KOz6UYWkJQRZxTmpzKX1Je7kGE6OT7ZQ13yAGgL/kHedmYF+TlEUzG3n5yZjiIeyYN9GlB6WkVmJ9Ac//68m57oY5NfVTKZWv4MauBfpRB9YjZED54LEPGAbtimVz4ANICqpStRWcsR4hRo8QjIcCV/qyi8wf1RplfmuhjFVRQbJrOg94LEYcyf5QSRVFO7h2XNTgzb4APC0nI9sYB7arlSpUL/Kl522ojcxLrgVDxFgLyHpYbKbr7e4cQCjNnjtDm0tTiMcZ74AE63r/ihz9P/b6vKWOQRXoOkH/R/Ut7rS1NqLqvV/FrGnyo/7XmnbNPTiTFBIUDRl75TESgwxuh1NCOSz4isDU62b7CldrJ8SRRdKLQPK2WcvOLH2hykqCgjwkiLXTsIVbxS6IkhhMwNalrI0QaHK+IJ1FhaaLoFRv5M/sgN6s1TpSwuqGDjjUueKX6JIhGTw9d4+FAe3t75/Abnmi7TM= 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)(376014)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9ZKoNtvZXFggjBulfD/e1Z/wf7Yu/b17P9x2JEV8FKge88wdcHi6T2i7GtHp?= =?us-ascii?Q?ij8yJPfOd0n47pRqhKrfKtbhkwaoRNaKBOFK5XmPcR4b6DNdD6n9guWZUhi5?= =?us-ascii?Q?30DRKw5vu23gyU8DXi2TJLGe9rxnaK7qzzU9w40S4PQ5EfMyDRWHlfQewMpw?= =?us-ascii?Q?UFDnL3y/3zRyfEMJkFA5kA6ESm0gsO/KvPwBUaB/Ub3WQdJdfIdHjYFXCMKn?= =?us-ascii?Q?SZ0H4Ppi0G4Of1A/fx9gFli6M2AeN+QyO3MH5rCL9ZO1hF0u4M4P7FDc7oEY?= =?us-ascii?Q?1vabVz5jOv4i7pFzUGkp69kpJeOR7beLMlmup3SYlxKf+ITJ8sMoCw97hWll?= =?us-ascii?Q?l5Q6u4CGGRuQFoi33DP/KmpJk9/9jfJ7pq3hXe1gigfpuzJi2+5gc/u2PUoa?= =?us-ascii?Q?fQlAVwvig3OybOvXDe30eLsOs8vctcK8Qmaw3vrFJY/fDSOT7GSNZEoYRmCL?= =?us-ascii?Q?F3wMBed1XCh96zRqatZIB1JtIqdamJan+o1FS2U3+sZTIgTLtCvWWPni7KFu?= =?us-ascii?Q?DqQbPtLlatbkqFWGzk1V6WuF1mW5Z47h+IGhZ1jl1ixQJiTnzyFES1SZnYPc?= =?us-ascii?Q?0DQsjAIw0HBx8pDcROOEjXODrdz0vUHtqIvlrGHfgi4ONB68glYZ5uBGzsUC?= =?us-ascii?Q?mn0rijmbPfQowSULVblgh4a7NWDVe+R0vff7CfsztqiPYfNgbHg2lzB/GxIm?= =?us-ascii?Q?iMimtVWvGN3xTdBf22coAu1shi9xhu34gr7Xi4+ovZ5Vq+NZuDIBMsAfVR47?= =?us-ascii?Q?nVUeSY4G5bl48rATsdxH6TuH8xpH5YBRxNOBIU8FMJP5UjKsQ17ci3vK+N9n?= =?us-ascii?Q?4RwY/8i3IMwYAdBCbAKWm4y7kB3JLYCdWiy+vbMmy1Z6GD6s0XypMIeIHb+G?= =?us-ascii?Q?1IsCwwIf5ggcl/IkZCUd0dIUspcLI2jm9xSsYEsFRNZKwFxi4TG/jNrtsw+r?= =?us-ascii?Q?ezpVFh7kgAXXIHmcy1BA/hAL0yNyziBXkCE1SEBewLsN+mXFPUFsm5KlRn5y?= =?us-ascii?Q?NAtH4/Lr5rf8TEZzklmRbDQuSzGpagyBEkxf6cv5pgfrX2AuyhtQCowmxuQB?= =?us-ascii?Q?/8Ff1wcerlRce6qc9h61Wqn/YjfS2ksBPi+/RYmGXtIAeMUcn3c7SVb0QrGF?= =?us-ascii?Q?bZ35k80FbTxZ112BTVijQjSVaz8RvsHL06OmVU4W/jLZPVnp1PE+cex7heoO?= =?us-ascii?Q?B96rjOqHvUEvFSC9A54ibNXOf8xzOWhpYKQaM5sWNNWc45k8dvBm9ia9cLX+?= =?us-ascii?Q?0wdlJpM8bNssXt89mssNVAdr4MmTzmRFElGYJDceuBLRNRIgNOdjmfiX5h4l?= =?us-ascii?Q?vq2KaKrFaHv/OycTDgzDl4Qp+/s0AEy8veDMYUZ9STgrXx7LPguhb66rNrGr?= =?us-ascii?Q?r+NnlTd8m79IPapedKFHFZIn9JmnRHzI2gIUL5lRukZCAZL8wLCbjUVwXjsz?= =?us-ascii?Q?b9JBQv6Eu2D5ven0n26DoEDR0N7XMw/snpBKBoyIT8B64cny542XsVvxyEyh?= =?us-ascii?Q?3SSAXhzXVCVLXHCwJkMN9UWWT70vVP7ntF7usM1/XJzBny6ZnnKqdIokPYxZ?= =?us-ascii?Q?GPdE4Z9sAGSR67HBjw3HBE9fTCHMoTcobprHZ+BaQhY7ncGmYvPVWClwcRGz?= =?us-ascii?Q?yKJmvOsim5D1yEX62YSDqxS2hptLOATrM3r4C63+vZNDYfJTCv6uVGXxpa5X?= =?us-ascii?Q?Ji4LKNml73YXdtRICiNh+nhpuENu7YphAohCfXrVbkLcDluARmE68ljbhdMB?= =?us-ascii?Q?QZGSgagvfA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c65a21fd-69d5-4c6e-588e-08df2ba4fcca X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:46:12.6393 (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: Nl8mrlAF4WQEIASUXOUX0y64utX2eNRyIeE7MLFTLnbJnGY3Tvs+OOl2jqJUG44pRJ3J0SkwlE566Qo9ey2Tnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB989476 X-purgate-ID: tlsNG-16d1c6/1792169175-1FACA77B-A78B3D26/0/0 X-purgate-type: clean X-purgate-size: 6707 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 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_l*_entry -> UPDATE_ENTRY -> paging_write_guest_entry The new MMU_PT_UPDATE_SWAP call chain looks like this do_mmu_update -> mod_l*_entry -> UPDATE_ENTRY -> paging_cmpxchg_guest_entry Signed-off-by: Kevin Lampis --- Changes in v4: - Refactor how mod_l*_entry() is used Checking `if (!rc)` multiple times in a row is inelegant but reduces the diff size. Let me know if that's not the right tradeoff here. Changes in v3: - Do swap for l2, l3, l4 - Allow all values not just 0 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 --- xen/arch/x86/mm.c | 60 ++++++++++++++++++++++++++++++++++++---- xen/include/public/xen.h | 1 + 2 files changed, 56 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 609c8595a487..ab09e0703da4 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4151,6 +4151,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; @@ -4212,37 +4213,80 @@ long do_mmu_update( update_flags = PTE_UPDATE_PRESERVE_AD; else if ( cmd == MMU_PT_UPDATE_NO_TRANSLATE ) update_flags = PTE_UPDATE_NO_TRANSLATE; + else if ( cmd == MMU_PT_UPDATE_SWAP ) + update_flags = PTE_UPDATE_SWAP; switch ( page->u.inuse.type_info & PGT_type_mask ) { case PGT_l1_page_table: + l1_pgentry_t ol1e = {}; rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn, - update_flags, v, pg_owner, NULL); + update_flags, v, pg_owner, &ol1e); + + if ( !rc && cmd == MMU_PT_UPDATE_SWAP ) + { + req.val = ol1e.l1; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } break; case PGT_l2_page_table: + l2_pgentry_t ol2e = {}; + if ( unlikely(pg_owner != pt_owner) ) break; + rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, - update_flags, v, NULL); + update_flags, v, &ol2e); + + if ( !rc && cmd == MMU_PT_UPDATE_SWAP ) + { + req.val = ol2e.l2; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } + if ( !rc ) flush_linear_pt = true; break; case PGT_l3_page_table: + l3_pgentry_t ol3e = {}; + if ( unlikely(pg_owner != pt_owner) ) break; + rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, - update_flags, v, NULL); + update_flags, v, &ol3e); + + if ( !rc && cmd == MMU_PT_UPDATE_SWAP ) + { + req.val = ol3e.l3; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } + if ( !rc ) flush_linear_pt = true; break; case PGT_l4_page_table: + l4_pgentry_t ol4e = {}; + if ( unlikely(pg_owner != pt_owner) ) break; + rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, - update_flags, v, NULL); + update_flags, v, &ol4e); + + if ( !rc && cmd == MMU_PT_UPDATE_SWAP ) + { + req.val = ol4e.l4; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } + if ( !rc ) flush_linear_pt = true; if ( !rc && pt_owner->arch.pv.xpti ) @@ -4270,6 +4314,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; @@ -4279,7 +4328,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..2c403ca47ed6 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 /* Update and return the old value. */ /* * MMU EXTENDED OPERATIONS -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:46:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:46:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452423.1667226 (Exim 4.92) (envelope-from ) id 1xHl4R-00050w-JT; Fri, 16 Oct 2026 16:46:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452423.1667226; Fri, 16 Oct 2026 16:46: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 1xHl4R-00050p-GY; Fri, 16 Oct 2026 16:46:15 +0000 Received: by outflank-mailman (input) for mailman id 1452423; Fri, 16 Oct 2026 16:46:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHl4Q-00050M-05 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:46:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHl4P-003Wv8-D5 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:46:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad254cb-8faa-0a2a0a5109dd-0a2a4506ca44-8 for ; Fri, 16 Oct 2026 18:46:13 +0200 Received: from [52.101.61.50] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad254d3-195a-0a2a45060019-34653d323dda-3 for ; Fri, 16 Oct 2026 18:46:12 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SN4PR03MB989476.namprd03.prod.outlook.com (2603:10b6:806:219::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 16:45: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%3]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 16:45: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=INM0kDCZerTnLe6m6W26TSQexMG6gZRXLNbdPcNGxxbPpuswZT24kMFNCNlQqIXzvRKxJAGNA+MV1+OARDT++dEihamuLBhFkC00Juj3JQ2tIEQtasGdCSH0JyjVg1RUUGJMjxX3oQRNqOtplh6n9y+eaxkMpfvoNSNJm9cYYc6OcSx4w28/IBsqYcvxtohy/pSy85PgQ2i4lTbfXRHEn1XmGlPqZyEEjSG26SMsvuklcHpCGI9tTCxvXWeiBaafD9chH6xTJyOtxjmWqW9JrG/ZsMm1exQ78ezTGcZhbDJCz8Ao7Yx/vW9BJ8e3iOAoeHv1d7jkeKzsmdR2ryBRoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tHIgZpoR/rF2VsNF55kUcsyY2bAEOeyv2670kaX1SXQ=; b=vmR2WAU5lrRAgnyajtxskdEtzqNLgHqI5HF7MTCnAqDdN69cAL5jaKK6/Z0n+GOTRXwKG0On/ERo9mGAOHlot3MfOCgo0MA5mcrQJTJYVRWQg4w9TkcblM0SJmEi7xrxuD3bac9YdreZfEjGe7QP9SlxyYQcwcTO5/AqZp0DaxfaChry3AX0/1hlfxH749pxCkjYTJY4yfG5GMTJZq+v98jwh9r3E1VMNJ0CX3WsUWQQ98w52Ud+kyb2cT4I+0Qy1vCc/dK4biSVuYJbfcGfFnRL/eZHO1/pyVuocCzmNJCp9g6g7VYkHaw6cjEsYDMISFRJqciWS5lTrqEwLXv8aw== 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=tHIgZpoR/rF2VsNF55kUcsyY2bAEOeyv2670kaX1SXQ=; b=mGecvonSCElX4GhNORGkQeV6ZqMcBfQiHQ9obtPi3flahvFYuGufH6OGp1MZFlNIyIC3MqoKLuq9g54zEs7mQKyxB5QyzlIBdGIQuVgTcGO8QOujGM8LPeO/kTJyGF22qpcUlmHCudwXQEBrCdmtn8J3Z0DAF9B3h6lb6EkFS4Y= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v4 0/5] unmap_page_range optimisation Date: Fri, 16 Oct 2026 17:48:10 +0100 Message-ID: <20261016164815.3109065-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0039.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:152::8) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|SN4PR03MB989476:EE_ X-MS-Office365-Filtering-Correlation-Id: 4091d22a-3a90-44f5-4168-08df2ba4efd4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: QRTBmM5S55IPJQpAzCupB//45kv2lWdDSW7FMZpX9Y2UDbT9QRpkMCgjOVSGql3mjSeBULm88YLTaAvOCXm+XOvAXHGIa1nJ/pZBCFZ4Z9fLs0PN+h0qdTMiWpjF6aSWcI4rA0UK+7PgmEHQtS+nZ4nnjv2Bj+qNrYZteFtu2zmQKXgN2mpJDsWePsIC6RfWsvkA+E5W08Yyitfe6n0lGlCvlRGWrMhGiKI76AwQAs3Fb3F4Gjfy0zmxATXS+NbwDv+bypdYAqkn3wza44Z2AMuHVQk5l3iNNQ2i4HcTub/RRpYzdezbFPEYvATi4LGUOtLIZI7BpJ0zwUa1alyl64nNZHvq6h6/5GFLFBpqCRAtOdPyZSO9RPRLQoouDJJKtUTd7ojPW3o/GynTDndfj26B3p2+Dw7/tXElWkdqvm0i9uxX7PEgl2rdZjN8R9HN4oEfIyeYw1ZMk4feGA+/m91hvpFIfPtsjm7LYf8nwZdN0VFpEhPPBJLGqQST+LUHOo1qX1i10xMTpT9yjIQpvIf05xzskmWH/icCVcW26eYYzD63wGYNkf5hzBIk/MlCuTfPzluz+bzzH9iXvc5Qn0kFQRHYmImx203+Jk/cZdw= 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)(376014)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uDlGka4pKhf5l2n18QD9X2UjfQlCDDyoA+CyT8l6RTPlAIXBkCy2IipPpplO?= =?us-ascii?Q?MJS6wWR3Od/QrseaS/2lLsnlqsY3cRSavtYvL+OjroaGZmITiJgzA6yZJ/de?= =?us-ascii?Q?Uq6ldbIrhAxRVCWp+mZ9PXxr1Diry8lLlHOTwgV0qQ9nbYIKOFh1o9IrB5AD?= =?us-ascii?Q?2pFzf9Y6K+DURCGWthilfVVYjSh94y0/yrQ7BL2/AJEBar94qENjRD4VZJK+?= =?us-ascii?Q?jkA1SuHqxMDXGYvGoTJbR5W7bXcHIax/6XJHlAQSE7mYYk5NAKqMhVYCsdWC?= =?us-ascii?Q?rV8iDWf+Mh6dKqsX5awVf1Y0qPE1kr6HI5MtR55kBryb7Mjh5+DnEds6EuZ4?= =?us-ascii?Q?k8+7AIueYtyxeSJkQx0/DtiabH3yguTPoI9Suu+s6Y6a5JUCH5XO3ULiaX6m?= =?us-ascii?Q?pfe1h1IttVDiyWz3JyJFgIMGfEDlqlUFIoehc5Z3tm2LxFUC1t3vwxTrhqxf?= =?us-ascii?Q?ImVsNEd9z+JLzx8eZqJeA2QJ8SP6La/4QC355muzuVLci3BI7fieQWRo2B0K?= =?us-ascii?Q?YgUHwxmKtC0HKStUUUOZAsYlmTFpmLqPgpcrud+w/PQRgLMG8rIZxDEk8Uk1?= =?us-ascii?Q?98l6fKzaxBzQ8CPv1chfUelLJqCJ8cSJFobhWQ6KrYgSp80k1PLnCtCwvida?= =?us-ascii?Q?JC6+bE89GitPwoW9RL0CjjqJZSx/z6Z8IkxaTLVDauufSCurFF+b3rPHkR/p?= =?us-ascii?Q?s2+XfhJ6eVFVdlhhTw2KwflkqRajNtNlWp2MHf/eYcfkzzM5wZ/OkCvRmrKM?= =?us-ascii?Q?OmVVg7izWa2Qrj0nKeegyf2/UjFKVW4YJ/lQiPyatK3mMQvuvr9+yB5/0vas?= =?us-ascii?Q?PB3mJq8mRGQB2hPygt/39HPPbeKSNkFOuD6GesgR9zZ2Emsxn7DpYQ7DBaDP?= =?us-ascii?Q?vUFbjquuGKBZwD4xddsdUAs4C4iaPaBwGm0GEPGd3ZyZUCKBM89IOLtA3rgv?= =?us-ascii?Q?hB6RmtjYjtfE9miuBQoWDgvsBHaTyIzek+RE8R73HePE3zwiUpiqblD9VD5N?= =?us-ascii?Q?If+XkuQyCR/U/IVeupoEHUZdDItHjzDyhUztIvTgODwDaRChdlvdnSKvPCtr?= =?us-ascii?Q?crfnfgT4eIpSiZ6brgQkNjdoqHRarfPpGhWAKHf1j3v1/VgBPIdIgn2aO+Wr?= =?us-ascii?Q?/204DSIEs6jtb83nzKjZXDIawO7QLl/srv2N6gWqtCTHTxZoFWnZKgNzydq+?= =?us-ascii?Q?OnkN9vr+W3j3JX17qZHureQhCIA/N8i+WGlE2TS4YO6DIBswZ4NqKsqEOyGo?= =?us-ascii?Q?bce8I86Q5+t0A7KNZxjuFm2P4LyW5tihRv+99Y/ISrVoJkKCFnCazsdfYGE9?= =?us-ascii?Q?LYSWZxNzn2SFdSQqchVmjEDm9G4fO7mIiLt3DfuNUv3fuVHvWz2W0m1Mf8tb?= =?us-ascii?Q?VkRY9nR7zU2kRVAbQ97iD6thuEqIAxbKcCfIuJGQUMWcsuzZ9E/wS6oFq0N0?= =?us-ascii?Q?9NFySzFjvRMPwXa5oCtay+Om/yibGlJMpvfT9veSNQ2kzE7KRtRT4U7HoJQZ?= =?us-ascii?Q?Y2OXQEP7fZLcHTiNBdX2lc+5HPRlGgHU5zcgrOR5CFHOgVCBzEQcyYpThVrS?= =?us-ascii?Q?fDqwSkSuNY/x9alf4fqp77mETtQq7mHqJcIPg4a+zeBVCUM6REsNGnx9tP9y?= =?us-ascii?Q?UzLgvAUvx61NyqNHdCo3OvdLMhMQIPM+gzdF1Tnw2Ko02kBBpGSNOR668EpS?= =?us-ascii?Q?qOtAfBEaTkuGgRKAS4IX7Z2T5jpgdfDblY+vfAbs3h6xYwnt2dB/uDczE8FL?= =?us-ascii?Q?uQd4M6yDZA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4091d22a-3a90-44f5-4168-08df2ba4efd4 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:45:50.9861 (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: XaZtO+97eTtOHuKfmrscy6gQH5bm99GcmuJNQSdcLPZw5RZt5as6/PD6q2oTNDqoukeN7hgJmgqBj7H7U532Bw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB989476 X-purgate-ID: tlsNG-16d1c6/1792169173-F5C0F77B-8D7AE331/0/0 X-purgate-type: clean X-purgate-size: 3156 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 v4: - Review comments Changes in v3: - Extend swap to work with l2/l3/l4 PTEs and any value not just 0 - Other review comments 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(); }' Kevin Lampis (4): x86: extend update_intpte() to support atomic get-and-update x86: extend mod_l*_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/arch/x86/mm.c | 158 +++++++++++++++++++++++++++++----- xen/arch/x86/pv/mm.h | 14 ++- xen/common/kernel.c | 1 + xen/include/public/features.h | 3 + xen/include/public/xen.h | 1 + 5 files changed, 151 insertions(+), 26 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 16:46:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:46:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452430.1667263 (Exim 4.92) (envelope-from ) id 1xHl4j-0006AE-Qu; Fri, 16 Oct 2026 16:46:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452430.1667263; Fri, 16 Oct 2026 16: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 1xHl4j-0006A7-Ln; Fri, 16 Oct 2026 16:46:33 +0000 Received: by outflank-mailman (input) for mailman id 1452430; Fri, 16 Oct 2026 16:46:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHl4i-00068m-Jy for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:46:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHl4i-00BCOx-0r for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:46:32 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad254cb-2eae-0a2a0a5409dd-0a2a4502a668-34 for ; Fri, 16 Oct 2026 18:46:32 +0200 Received: from [52.101.61.1] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad254e6-6ca4-0a2a45020019-34653d019999-3 for ; Fri, 16 Oct 2026 18:46:31 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SN4PR03MB989476.namprd03.prod.outlook.com (2603:10b6:806:219::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 16:46: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%3]) with mapi id 15.21.0522.016; Fri, 16 Oct 2026 16:46: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=QsmNXOTsRFgGScYpquzDQqBEi9ewNRy6vagNB4/ZEB6vQJYynWvR0iPjoR+lpG07R4U05RXkBLOnfC/g7mbyzoUV3p7mfOI+PPk+9tFWftdims0pgvsWyOMFMizhu3D8/APoffb6vaHHBq7k88lV4oDCjAp16h7KAiLJcUzoQE5IeI5Vcr9SO8SWEg5oxKOCSNkEC76lMtCqBb8w/83fY/hTevcSITnWK0lMWXKJobJri98cgxDPQ3ZHITz8sceZbRCWbg8N2hHRhXsaBy1KYCzgGdxbAeSs0vVLSCAphAx5rl+/3a9zKuhGJ/QpBADudca/wUlwPQXfHihPN75eiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xVqOtSOUy2pB6e59N44Js2UK5JmQmOee60/HkofDur4=; b=Y3XwR6LCZby3CQyqiYPpIvHyq5KEU/Tohptm1CaqGZXrwWyJxt1ClYL2/Lq0sSIl1U4RnmfKzXkTkM6++nemmivPV6G3jCCUmgyEWHNgptNnw7lDZtcwTVbFXhIAF4ntbysiGWnq+K4/hgYX5GBnYpzQPGEjdpGzmNFMjKQGZR3kx+sr6NNsaVA+gfQXF0K6XE3xN9lYr0/7mRtJAPmdPxPT4v0DmgnzNQBLIztgwyucngaiYXleOxRxz2SEgtB6OafUTj04JqbuLD7YZgYj1beyZRVF3vCdJAOlOhIH/frT1aMtDK5jXZmEOkJz5sUZUqZrNY6Q25btqGTd+YQYmQ== 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=xVqOtSOUy2pB6e59N44Js2UK5JmQmOee60/HkofDur4=; b=lqyEXew8uPvdavnn52fq5L0TFRNxpit09shEZxZykHxhW+sW2X91GeqylckSfZTwfZULw2x0f4B4Bnva/9wzxm21Kwu7LP7dACWKnM6OS17ET+5LSnyhTaTmfyYaiS1hnrwtSPYHBbz1AeSIUKnsfoDUdLVxQDk2bF0ockHLRl4= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v4 4/5] x86: New feature flag XENFEAT_mmu_pt_update_swap. Date: Fri, 16 Oct 2026 17:48:14 +0100 Message-ID: <20261016164815.3109065-5-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261016164815.3109065-1-kevin.lampis@citrix.com> References: <20261016164815.3109065-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0194.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::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_|SN4PR03MB989476:EE_ X-MS-Office365-Filtering-Correlation-Id: 44e34282-88a9-4b98-6946-08df2ba5014d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: o9kC48xBTSySPm8LskyqlQt2qh8myWbyppis3MG1EuwuXz3P0+Y6scGxhP40CC3nam4SqqjenAgy9uuJGo7l57bmpwn1RWEusSNC/jcetkqT5cTz8FDDz9gw49Bt6i6vxAA7iM0MDE9lj1XkvqiS35cNCfjyI8t8bEw9nzNsbORqxT2RFVijvuPTD5yZpuizVnRXAe91/UNhjezB6WQT62obSrrhe84bC0Rc+l1BtsBYz3vI0r8Q4WL7THy88h+HIPJjKp6eNiKysZIieP94VYwjVKJWc38hwJ/0zld6oOHzgqjtlAnf9dzT/74XLRMuYoKoGrpP5YLcVszTE0xwW75ZZIEAkQmfFkwd135YkdFtpfYSgmcSl/gQqMjeeLUmpOylZGWrnIgFhQFMtsKFKYxdMRKfLtLJY9cdPexVgihkY8flwpzfMVdwIgvwupSo4NaJJwQ/iOdtRTfsePeU6vgLTinWZPu4Hs8/pSUsJANzzDvNlkZP1yAkELAcnzDKX8AAY1APrATuoKIZAG8voRXaUcOyUCXkwSltUbKyhixOtbkECMFgtctOwmnBhixvgCY2YLbr/bCi3YaECc7Z1e1WZ3pFMw6dg2ZGXJ+ctHVoEbfOfvHIZhr1z5ZT2vDC2l9jBCH9QGY1asJg/U7Lom5vX7qnnB/Muc2w0Mqkcco= 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)(376014)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Q0vv8Y9Zn2PcB5hmS4ElsbWqGOOTnDrmZTNi2XWyYJEGNYnwVQoIdmZzuG96?= =?us-ascii?Q?4uMG2T/Jk8yb+YWnUAJAy1OgD2wsgvHgzg9/QeKmtF/g7FvOtHQ6gLPrMWGu?= =?us-ascii?Q?YXSlRneQZLgn2jj2xnh6Tsjn9ZxnS9R8EFZ4PidE6j5BO+8ccen2GIh/aG1Z?= =?us-ascii?Q?SyPfCAqXDP2+A/0orbp0eQD8zATCrhF/bBN757ACddKyXNfFT29FiyCNtnoa?= =?us-ascii?Q?jFqhkoYsNJ1jE4qyTME6QAiOvF93/ugxCwFCyOSCFRA+yPueGCr34Uxw3au5?= =?us-ascii?Q?+nzqhIJ8ElCAyt6a+kF0zge/CuO1k6+x4MJyPj5Qo+YMINvsMnWnL3vvyDvx?= =?us-ascii?Q?/62YtrebTJZnmU+kn1Ap3Klmb20pfXhWDdHKq6qW26wlvGJ/kqNdoTB3P2N6?= =?us-ascii?Q?Iysk0Efeioq2vEZYU5yHfhu2GOI1kgqYC/1cmNcaOVrwuKh5U05+nJgU7vNh?= =?us-ascii?Q?EP9kOzdZUfZlVtbsNaGEbJ9dO/LiY92jb79CLA7YJmOCB+mzG8pI+VlQxIX1?= =?us-ascii?Q?njboFRRSZHKxjkBXjw2l8RiDoj7vNcbncSoAVxlbvQFT4du3hjWMXO8StnAK?= =?us-ascii?Q?opjYr5ciASG3e5W+LVZB42es85DeNTtyHPoM4iQmhw7b7vwx662Ej4kfGrBU?= =?us-ascii?Q?JFHUlN5q/PEMthanjSqj4hppzEOUasJTF4xy/Ks6BHmia0J0lujlq73gIxAe?= =?us-ascii?Q?eGAUpOfdIDdy0GErnj6ME51AzGOfu5zYoI77JVBmiUiiZDAVI8zRpgZku+9d?= =?us-ascii?Q?TX8d/3O5PonneH/1BVluZnRAT605bFosp97Il1o03NBR8FXzOT3+FUIIG92e?= =?us-ascii?Q?SsT+PgwtA2JFXgfhYaxnTwT8vBzuB9dy16ttskOMtKTsuXfkFyydviueXFQ+?= =?us-ascii?Q?UGBzorTD8Z+C2DZOjZ0rueTQI9JbDp7RYYykvd9jY8bthuJFptI0UMQGqy94?= =?us-ascii?Q?NLMi60Yj7GDG5Q2UiSOI3aYxmzNJEHWvCbk4sxm0Ic7CdLvIJ6OEcdVHXvIl?= =?us-ascii?Q?jhwhdVb05xM5YcMEmSjekPKHDoLERknhZpA3fgtbn2p8uhQLvXBXTr1BU4z2?= =?us-ascii?Q?/ZpvKyR5rUN3WMgBEMPwFbUM2HIPuWl3YLy2lkfzJ6lniAEKvJjudPbSJFxT?= =?us-ascii?Q?Lx41rw5gs2QZGbaG8D4fq4v6UMiY9hWavE2sjK+BvZFg1AEH1YMg2EThvtGd?= =?us-ascii?Q?qDhtnwr1aMD0kDgTrrNUicFlhBm5XU5GTCq/6xXkeUwxkc3vDPQW6nXHGiIA?= =?us-ascii?Q?tFT3JtbnnaRS5OOosmoz5Y3rdsnzMVW80NzZfc+Rpf+KazaS29SUcwaWJ0V2?= =?us-ascii?Q?/JMrvXu4NzmPk6e2gjZEr9NATDdy50jK+Fh+EI9g5W2KEjnZtzPz3Nrumz4L?= =?us-ascii?Q?5ySRe0B7xGPmIJWp3CdyPe3uNqjEpI9vmJscUfHr65Euh3FznehdfmiRIk/4?= =?us-ascii?Q?WmFXMSbTYs+ckr6Mj6bW4Ae6EwvbB+JeT2mz/LauL4eoMOozaAWRnqbCJYXb?= =?us-ascii?Q?b/BctAT9moEXJUg2DekPpSQZ71AtO48PTszDINZuP+Ns9jgapq3QXaAJu1QJ?= =?us-ascii?Q?yZ16RoLW11FdYqPoHwjdMHGoVEZRH8Hgtq1+sqdjS5k648wYrWF1xeE7TTGj?= =?us-ascii?Q?o5PZ2wOFHsFbwQabuUL3jsqQceM+i5uR8Q3Xzd6rwhmCLRGyE/O/eatKVBcE?= =?us-ascii?Q?e/YcdHl7XhZXMzTVYPUgSuCkVGppjF4DPbf7INn2InhBI3V5l4zcnAsaeg5U?= =?us-ascii?Q?x4mUBWq1Eg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44e34282-88a9-4b98-6946-08df2ba5014d X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:46:20.2210 (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: caZrALoDwRrtjvspL6MTscRuubzJFcu6Fe1H8JPbwvdcGHherm/7khr6gHU58elxYn34fDvvgA3xWvGc5pjV3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB989476 X-purgate-ID: tlsNG-720697/1792169191-F08A42AC-EF9B9C7B/0/0 X-purgate-type: clean X-purgate-size: 1305 Signed-off-by: Kevin Lampis --- xen/common/kernel.c | 1 + xen/include/public/features.h | 3 +++ 2 files changed, 4 insertions(+) diff --git a/xen/common/kernel.c b/xen/common/kernel.c index 499023fae6fd..dc3cd9c3321b 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -690,6 +690,7 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) if ( is_pv_domain(d) ) { fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) | + (1U << XENFEAT_mmu_pt_update_swap) | (1U << XENFEAT_highmem_assist) | (1U << XENFEAT_gnttab_map_avail_bits); if ( IS_ENABLED(CONFIG_PV32) && VM_ASSIST(d, pae_extended_cr3) ) 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 Fri Oct 16 16:46:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 16:46:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452431.1667270 (Exim 4.92) (envelope-from ) id 1xHl4l-0006PV-22; Fri, 16 Oct 2026 16:46:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452431.1667270; Fri, 16 Oct 2026 16:46: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 1xHl4k-0006Op-Ux; Fri, 16 Oct 2026 16:46:34 +0000 Received: by outflank-mailman (input) for mailman id 1452431; Fri, 16 Oct 2026 16:46:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHl4j-00069n-PX for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 16:46:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHl4i-00994g-Vs for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:46:32 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad254cb-2eae-0a2a0a5409dd-0a2a4502a668-36 for ; Fri, 16 Oct 2026 18:46:32 +0200 Received: from [52.101.61.1] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad254e6-6ca4-0a2a45020019-34653d019999-4 for ; Fri, 16 Oct 2026 18:46:32 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SN4PR03MB989476.namprd03.prod.outlook.com (2603:10b6:806:219::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 16:46:27 +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.0522.016; Fri, 16 Oct 2026 16:46: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=tTHSpKd4ZELmeDnuLlLLsA6bI3gAbEfLZ8b4hl55Sbaue1AX/OyikiLqczF6OJHGhW4Cl8KJPovorHizJjF1efZLGYwd1LAquNn0cleEcWNQu0uxofQtz0d4ksWaP1n6lRnXmuCsnjiAS+2eOO63QpLNfRrifV9AikpgkMfR0QyTRpTV1NbGgPJHkH6z+cr9v+Aaq9nkw9Awe5o+YmbdOttC2HPDa/FL3sw1QBZVzBVx7NJzBzueapORTLyil8jFlEttqaMPEFhyFBCUJlOJyyFkt97yCsEpxFATMC49D4L5ObxWvkuyYyNjxbdgi8G66V4Yy/lVA2OVllDPkxUypQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TzJSH5d1PozqUsLrg++wK8/emMiRnK9WBI0v3qfVBns=; b=czb9d+gaCI8q0A6rwAvhayRubnnj4NtWVLyD8YqCQ7yCALriHZWoUIXDeuP4cLqkthwUeLyqGHF3DQhi62eYIYhZe3UijY0+LVDGgffWzA84oy31qQ4iqXdV/ixKVL/qON+0y9uKix7kAUMZqoqDIuanW5ewsoEG1EdBSf0NHeK4rDusz6SjFekwjkAPPUu5PfFxuRewTSEdrgjd5oVKy7Fa2FusK+0v1HFQLV2BaU5/fBEwJOSNQMKKGcPtHj9Y3HAiqinvaZ0t3TRV9P9QqvI3vAWFLaG6iPi9G5+nlHUcEFmbSlB6NGAVolp7Os+uZLcs0bjmNwoU2JvSC1O+Dg== 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=TzJSH5d1PozqUsLrg++wK8/emMiRnK9WBI0v3qfVBns=; b=jM68RFw2WJ8WQJnOn7iEfdAlxqMIJU/l9RxXn+HWVD8cFp5geikaKEu8qahpm9ybUCvSFu6PLm4FO6cKV92DUPX7udrUtr6U3Mx0R8ByUodhiu4g7f65gnrLFZACnMBuCnnA7oiQBUs1gHmi58wVoocSGEtrNnHD3mJkK7/R8E4= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, Kevin Lampis , jgross@suse.com Subject: [PATCH Linux v4 5/5] xen: Add new Xen pv-op pte_get_and_clear Date: Fri, 16 Oct 2026 17:48:15 +0100 Message-ID: <20261016164815.3109065-6-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261016164815.3109065-1-kevin.lampis@citrix.com> References: <20261016164815.3109065-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0054.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:152::23) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|SN4PR03MB989476:EE_ X-MS-Office365-Filtering-Correlation-Id: 063f5804-c64d-43f8-3a5e-08df2ba5058f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: 2YYDyTPdRdnujixve6mIkwXPBqmevpu4lflKxhELVIxXRCEMIdnXdnouB+q4Dv6yyhYHIAb5rjx2DLPB+bJiuCEeUGiSjNoMcFggquUCrdNoDJgY8cubUAD8E5nO5T2PXw0EWPMmSR3vGQbx1BDZm2jr/T+feYyK6jrCYicxWz1tZdrzWjSAE7JhIJje43GILkmr9WxWTM+YxT9Y8/TLRtEFAhA0KBFkIOCSxHJe0cWVbqikUMp1DLhAUGwrmLfWJga3L1fFLdBgsVL0byNsbtelRnPBZsQU28iZuiVEhpzl/+8Ad99lLZwzvhOcnH0uXFpcxKs1nDaYlBeZX4/OclCY2Fyn/3yw0G8fMHqxJtqiAXN0OUWJ8wy0HiYBCaZDdUZg3KwiROCuJa9jKhwSAc3piX7L8x3CywSlgUOIx4HKyUjskWcsh5qrsr0u1FIV7Z3OKT+FOFt9LCmssXQUCj7xagIoaVMptmNYKhQE31SaWigj+peSMvHu77rJvktRVrw12VY6N+6YsJrrYYp51hSm6QRwQWdZqEXNdA5fAvNGdeeUdcAgW6hpGk/kif2l3hphWZRRgXIwnjhZSQv0CyZfjERhbDbDya9PLiudzIIrPz5pusv0y4sdyGSzOTJk97mxXUpHkmqKqgZ/sviBHQ== 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)(376014)(23010399003)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?u9qYSckP1SKjLstBDd7rj8X3mBgdEYVnfDKokHKmgKefPqAnOEMCsZfmWPBK?= =?us-ascii?Q?A+0q6VDCunVAEi7NRnyPxxljNjZzTCanpD4f/WdOyz+wX1dbel5GshxuGb8Z?= =?us-ascii?Q?SbsmLgnPusTFICO2PKsuMwSk9iBayungR6BLWrHGBO4eDGNRyjTv0ZAFm8On?= =?us-ascii?Q?fQZKK3/N9XSgcrlgWezEkOcAStTMs1YUTYewbN9c17a4h/4coJQy6mIyNgj1?= =?us-ascii?Q?5k0XYzgyInYQhN7+6dMpgwpwbHzmGg3xDHcOKcSnealPyH6lV+L77xO/lAaJ?= =?us-ascii?Q?fFx2Mbs8CSn2IVxAF6LiW69j4v0ZOsVERYZUsvntoHSkIYIVEvOhpgSc7euq?= =?us-ascii?Q?/Arjq+Z3pSpJ+3k3GuV/gmSBdHUNQexZXgd/N5Sm3ou5V8KWT6QKmnriQ7OZ?= =?us-ascii?Q?IMOnyKPF/0mUlunqFOQWIjjTcq6oze+9GJFviTbR/fxCAaxp3LfgWEppFfT/?= =?us-ascii?Q?rsojlPKPyfqOf40TkluExn63vll+Op5AJUt+3mWYd83nLY7ddX7iVG4m8jh9?= =?us-ascii?Q?iilx/CIMDqChN7wEmV2m6SJp14Tt+FlvzoMwxKOOormtjcSL5ktOxplHNYDA?= =?us-ascii?Q?mO/8vAdF2Bsk13tO/ORW6QLZtnQH/UVLNqktAxa2gQI7UGP79CccZLzilg69?= =?us-ascii?Q?KGZt00uekL2x0ESYJmL3XHCNyVNy2Hmxk8ZBJfKtcd1mysFr8PJaThYyNioQ?= =?us-ascii?Q?ushZOOeMO1DAgHbM6yd+qX2xHKJIWWd6AT84Qfbm/bgE3FgLzN97rW35XpVw?= =?us-ascii?Q?jczDt4crqOskFQD9G4x6x4G5eenC5x9+OUgIQ2EJJk5kCjcZbb5G4uncZbcA?= =?us-ascii?Q?l/U2+7ARH84FU6tf/ErDxgBf5GU5OM2JXiYYS9K4ERnzFz/UHA9Dy749VXy0?= =?us-ascii?Q?ZkUkYmHvUGihhi14PrcVV10Xf11C7OumViVK0d2MJzWJuUK5LL9Zf4Bp5LYM?= =?us-ascii?Q?EeXN+klVHmithNEn3/KFwASAIKCtjJNz2eEkki2S1AYZMsFRkyANlvoDjOf6?= =?us-ascii?Q?3T7y3gSzZNbtnDKMysaPTlDH5FTTRAP8y6Ml5J5zJVZxOshmv+za8AoJ8wgH?= =?us-ascii?Q?Y+No5NDtLPD20ueLfGBUfZSW+K8JItLtXtTZQESbDd1AUvU11j/F7E+OksOK?= =?us-ascii?Q?xtBCjRTk/dpOCAl5/ufPKNZO49ovek6gblv7YnzHW1Rqd9BMrcM+crgIwv84?= =?us-ascii?Q?GmavgyuIq6V/M15Cfmi79tvqcgVAeyMY+JlzucblWypvfE1ktYNjpmPjOaEd?= =?us-ascii?Q?bP1raOlunOPTWIDrCnAIYTqQE1QnOi/v5WVK1eQI83RrQnkZV9Q36yRS0DMB?= =?us-ascii?Q?0RQ+AyZAtzkW6t9Lg+qyY27xZ0NXzIXBxyUU3Ue6D0Ght1i4gxbeOw2rVErF?= =?us-ascii?Q?65bNeYgEe0+ienioOjh4ddtOcJjY3sRHMJyxOsipZzTuaj2ADRH3qYUYSHDJ?= =?us-ascii?Q?j9BwC9M8ehZT75yuotKGjaYhBE9yscklEsBRK/FogDhnM/O6aO/fk94qTCIi?= =?us-ascii?Q?BB4NcGD2XDtZ/1VmtrCrbOtWp7n4jVv8GXdOPKMVtREwRHRVutDByeJrk3fZ?= =?us-ascii?Q?mOjybuD0qvCzfXiqQecStkHlE47hRLPSB9pzsbg6FXgDvtu5C2wpTtGfxtlT?= =?us-ascii?Q?rxAnw9+VDeE1ZIZ8/1gbt8qJoZgpVuB+AA0c38E8BraM1P6q/Vaew6/zKo92?= =?us-ascii?Q?5MUV0mvxMVAlBSsi57tyHheRSq/IiYVyRmD2kzF6LD31okBgWRVfSXCtB0/v?= =?us-ascii?Q?9YlNfcgBfA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 063f5804-c64d-43f8-3a5e-08df2ba5058f X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 16:46:27.3521 (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: ic3y8ib3x4VjCCYRtMMKca3QGl7YReFkTMCooITUQmrMf9qOpOCo8HelDMaSyVKtpHHEh2t4Td6kUH/vKtp7dg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB989476 X-purgate-ID: tlsNG-720697/1792169192-F0AA52AC-91CB55E0/0/0 X-purgate-type: clean X-purgate-size: 5548 If Xen supports XENFEAT_mmu_pt_update_swap, use the new MMU_PT_UPDATE_SWAP instead of native_ptep_get_and_clear(). This avoids the pagetable write trapping for emulation. Signed-off-by: Kevin Lampis --- Changes in v4: - Reword the commit message Changes in v3: - Add spacing to xen_pte_get_and_clear - BUG_ON if hypercall fails - Remove extra blank line - Add documentation for MMU_PT_UPDATE_SWAP 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 | 17 +++++++++++++++++ include/xen/interface/features.h | 2 ++ include/xen/interface/xen.h | 1 + 7 files changed, 29 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..c2a7035b4848 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..a1e79672a408 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -359,6 +359,18 @@ 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 = { + .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) != 0); + + 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 +2177,11 @@ 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..64c120d8a100 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 /* Update and return the old value. */ /* * MMU EXTENDED OPERATIONS -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:05:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:05:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452476.1667280 (Exim 4.92) (envelope-from ) id 1xHlMd-0005Ot-OV; Fri, 16 Oct 2026 17:05:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452476.1667280; Fri, 16 Oct 2026 17: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 1xHlMd-0005Om-LJ; Fri, 16 Oct 2026 17:05:03 +0000 Received: by outflank-mailman (input) for mailman id 1452476; Fri, 16 Oct 2026 17:05:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlMc-0005Og-P8 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:05:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlMc-00D0TI-2a for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:05:02 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2592e-bab6-0a2a0a5309dd-0a2a450294c4-12 for ; Fri, 16 Oct 2026 19:05:01 +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 6ad2593d-6ca4-0a2a45020019-b9ff1c2383cb-3 for ; Fri, 16 Oct 2026 19: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 1a145ac82530008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:04:55 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 9CFFB823FE; Fri, 16 Oct 2026 19:04: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=bHID4gDnUBamWNl4leUplz6R8oxrYRCt+gxAc7a3dDE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=TS2e4iJrgRAk+raZd7pf7JwOhoYJpuTyMO3gs3TT2CLVFmSmU0lprfFABc0tJ2aaqSWoPa7cn 9jjfELoW1Bu5NhzSITyCnS0V3iyTb9oizvsPuGyTynnbaAbTHGJBBKljtv5zHC9nXBWi6/OKy8Y g4hTqtm/28rPwOguSEceJ8U5dus1sig9JjF0ii1NtHIKnUJB1H/+sZ74tcErmCU6tG7+Zexhqo0 u7orgtTLQ4PSDI1gY/nVH2G8/gYNmHS2HqdY5pG+QzSADBp9zlca58He1dIItigSF8Rav3jgifs GLE6ieNtJy58Mopc1potefVPDfdOaY7tkm7iOmxYI2BA== X-Zone-Loop: 69385bc52ae0e64795bad7d389470e5847e614f9a5ab x-campaign-type: default x-transaction-id: dfa0857b-8b1b-47fe-81e5-8f3d282d7bec x-swg-uid: 01-27e464c2-3b27-44ad-af42-6ea14d91da23 X-Mailer: Sweego Message-ID: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> x-swg-bid: 1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , George Dunlap , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [LINUX PATCH v2 0/8] Various improvements on runstate and vcpu_time areas + xen_features Date: Fri, 16 Oct 2026 19:04:41 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2f4.56ede8a57b9a8d0b.1a145ac7e4a.348ce0130e5b2c4b=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170294859 X-purgate-ID: tlsNG-720697/1792170301-66CB22AC-56F11A23/0/0 X-purgate-type: clean X-purgate-size: 2357 ---=Part.2f4.56ede8a57b9a8d0b.1a145ac7e4a.348ce0130e5b2c4b=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Originally worked on for AMD SEV support, but happens to be useful on its o= wn=2E >From the hypervisor, updating runstate info (and pv timer area) from virtual address is expensive=2E Moreoever, confidential computing (SEV) can't rely on guest virtual addresses=2E Xen 4=2E18 introduced VCPUOP_register_{runstate,vcpu_time}_phys_area variants that use physical addresses instead of virtual one, which can be persistenly mapped on the hypervisor instead of translated each time=2E Also refactor xen_features so that it uses a bitmap instead of one u8 per feature bit=2E CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: David Woodhouse CC: George Dunlap CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg Teddy Astie (8): x86/xen/pv: Don't setup runstate area too early xen: Refactor xen/features{=2Ec,=2Eh} xen: Add gpa conversion helpers x86/xen/time: Correct xen_save_time_memory_area() failure message x86/xen/time: Clear xen_clock mapping later x86/xen/time: Mark xen_setup_vsyscall_time_info() __init x86/xen/time: Use VCPUOP_register_{runstate,vcpu_time}_phys_area when av= ailable xen/sysfs: Honor cached xen_features instead arch/x86/include/asm/xen/page=2Eh | 22 ++++++++++++++ arch/x86/xen/enlighten_pv=2Ec | 3 -- arch/x86/xen/time=2Ec | 52 +++++++++++++++++++------------- drivers/xen/features=2Ec | 11 ++++--- drivers/xen/sys-hypervisor=2Ec | 12 +++----- drivers/xen/time=2Ec | 24 +++++++++++---- include/xen/arm/page=2Eh | 21 +++++++++++++ include/xen/features=2Eh | 10 +++--- include/xen/interface/features=2Eh | 9 ++++++ include/xen/interface/vcpu=2Eh | 17 +++++++++++ 10 files changed, 134 insertions(+), 47 deletions(-) --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2f4.56ede8a57b9a8d0b.1a145ac7e4a.348ce0130e5b2c4b=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:05:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:05:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452477.1667289 (Exim 4.92) (envelope-from ) id 1xHlMj-0005c3-Uh; Fri, 16 Oct 2026 17:05:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452477.1667289; Fri, 16 Oct 2026 17: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 1xHlMj-0005bw-Rr; Fri, 16 Oct 2026 17:05:09 +0000 Received: by outflank-mailman (input) for mailman id 1452477; Fri, 16 Oct 2026 17:05:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlMi-0005bZ-Qn for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:05:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlMi-00D0TI-68 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:05:08 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25936-bab6-0a2a0a5309dd-0a2a450b968a-8 for ; Fri, 16 Oct 2026 19: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 6ad25943-b7e8-0a2a450b0019-b9ff1c12ae97-3 for ; Fri, 16 Oct 2026 19:05: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a145ac87b70008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:04:57 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 9E39182147; Fri, 16 Oct 2026 19:04: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=LNS8Q1yMCOr9mDwjdOlitAadpYMFYRFn5edPH0JFlxM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=gg9TSsFuN50hzTeApt0OUsRANLCstXoJg1VHtp1EKMUO+6GRQulENlb3wCHdEQBJ+q3vyhRL0 A+oeKt7ZRMfbg5QPvIWHUxYfw0A7x332h3Z0YJEKemz4gq/W6Wg94zGPXTnkm0Qlnx3YQsKKGK2 9Y8HFOIr9llVPfj70y/Ow9MQqi080MUoSWk7xeHrfR2UNdmRGAwzNE6JGxxYcyVRuYgNcR9bK73 rD2lgVtsE8Cu88XbYlJbFJLd121q/44yluwavGhJY4hRaWZPw3UnaA5N9GHsAMDD4DNVtC7o71o WrTh9+NMmNG5Y4khmV5ln3IZ7jhaTcYTw0AKQmdEwA8g== X-Zone-Loop: 0b2eb03d03dc5932ad51f01d23265ac6ddfeb6ec370f x-campaign-type: default x-transaction-id: facd8506-db05-4625-8eeb-32390827f856 x-swg-uid: 01-bd9b1c2b-1969-41ec-bd22-a10fe1125bc8 X-Mailer: Sweego Message-ID: <1792170297.8631fc262581453bbf619ec5b2062170.1a145ac87b70008425@vates.tech> x-swg-bid: 1792170297.8631fc262581453bbf619ec5b2062170.1a145ac87b70008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early Date: Fri, 16 Oct 2026 19:04:42 +0200 In-Reply-To: <20261016170449.172889-1-teddy.astie@vates.tech> References: <20261016170449.172889-1-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2f5.38d6ecc2e272c00a.1a145ac8604.36ccb94a74936a8a=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170296836 X-purgate-ID: tlsNG-42698a/1792170308-A9AC09EA-D72F3974/0/0 X-purgate-type: clean X-purgate-size: 1568 ---=Part.2f5.38d6ecc2e272c00a.1a145ac8604.36ccb94a74936a8a=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is no longer required since [1]=2E At this moment of boot, per_cpu areas are not initialized, which prevents using VCPUOP_register_runstate_phys_area as per_cpu_ptr_to_phys() would misbehave in this case=2E [1] 8a22b9996b00 ("xen: drop xen_sched_clock in favour of using plain wall= clock time") --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: David Woodhouse CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg arch/x86/xen/enlighten_pv=2Ec | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/xen/enlighten_pv=2Ec b/arch/x86/xen/enlighten_pv=2Ec index 2c64b388f616=2E=2Eab3374b2f012 100644 --- a/arch/x86/xen/enlighten_pv=2Ec +++ b/arch/x86/xen/enlighten_pv=2Ec @@ -1551,9 +1551,6 @@ asmlinkage __visible void __init xen_start_kernel(st= ruct start_info *si) #endif xen_raw_console_write("about to get started=2E=2E=2E\n"); =20 - /* We need this for printk timestamps */ - xen_setup_runstate_info(0); - xen_efi_init(&boot_params); =20 /* Start the world */ --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2f5.38d6ecc2e272c00a.1a145ac8604.36ccb94a74936a8a=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452484.1667297 (Exim 4.92) (envelope-from ) id 1xHlOC-0006Lb-8s; Fri, 16 Oct 2026 17:06:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452484.1667297; Fri, 16 Oct 2026 17: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 1xHlOC-0006LU-5r; Fri, 16 Oct 2026 17:06:40 +0000 Received: by outflank-mailman (input) for mailman id 1452484; Fri, 16 Oct 2026 17:06:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOB-0006LK-GD for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlOA-006YfJ-TM for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:38 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25989-8faa-0a2a0a5109dd-0a2a4502d3c0-22 for ; Fri, 16 Oct 2026 19:06:38 +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 6ad2599e-6ca4-0a2a45020019-b9ff1c12837f-3 for ; Fri, 16 Oct 2026 19:06: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a145ae01ed0008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:34 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 6675081C51; Fri, 16 Oct 2026 19:06: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=l8T+zB36v3344Qx++zSmURQABUtrWcH120dfd9aUnx8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=QcPuc/+6oMivemImrXSV8WmFV89bKI2O92LDMmtX0DpiRcYI8O/iyD8EW26VOXqeDDD1c9Cds 2gBonlzWDX8NJB8j6fcZeKIj8JULCQf2W+MvREe5YqlCuBvM1uyExtO60M1JBB8Wc7Xk/qKvtgg PLTn2hIPw+3wLr6SpxLZht+C07saePHEY11Rl9j6QY+iu4fBFf+5vEfldN/pOE/nh6zltRL/Rs/ VP1D3QjPnDkwN9q4tphTyRULVXO/ieSqaA07+YoyYwHBoorRlO+h2Pd+8m8FEmTTPV5sZA6InEc MvVv7r1iRhsitTnL1eHTySj57NCZhI1yujuOIb9RcQoQ== X-Zone-Loop: d741cc1e6a0d17a72498b67404104773374eb146f536 x-campaign-type: default x-transaction-id: 5431cc90-504d-4912-a3c0-1cb17cfae413 x-swg-uid: 01-cc575524-0fe4-4f05-a2ec-2a0a1f9c460c X-Mailer: Sweego Message-ID: <1792170394.8631fc262581453bbf619ec5b2062170.1a145ae01ed0008425@vates.tech> x-swg-bid: 1792170394.8631fc262581453bbf619ec5b2062170.1a145ae01ed0008425 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 , Andrew Cooper , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/8] xen: Refactor xen/features{.c,.h} Date: Fri, 16 Oct 2026 19:06:07 +0200 In-Reply-To: <20261016170613.173406-2-teddy.astie@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <20261016170613.173406-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2f7.9f97d616ee87ccca.1a145ae0000.8be10a07f18f35a6=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170393601 X-purgate-ID: tlsNG-720697/1792170398-674BE2AC-1AA59D1F/0/0 X-purgate-type: clean X-purgate-size: 3060 ---=Part.2f7.9f97d616ee87ccca.1a145ae0000.8be10a07f18f35a6=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Improve various aspects of xen/features{=2Ec,=2Eh} * Use a bitmap instead of a array of u8 (effectively bool)=2E * Mark xen_setup_features as __init, as it's only called in __init paths=2E * Return bool instead of int in xen_feature() Suggested-by: Andrew Cooper Signed-off-by: Teddy Astie --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg drivers/xen/features=2Ec | 11 ++++++----- include/xen/features=2Eh | 10 ++++++---- 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/drivers/xen/features=2Ec b/drivers/xen/features=2Ec index 87f1828d40d5=2E=2Ec4a6da6419c5 100644 --- a/drivers/xen/features=2Ec +++ b/drivers/xen/features=2Ec @@ -7,6 +7,7 @@ * Copyright (c) 2006, Ian Campbell, XenSource Inc=2E */ #include +#include #include #include #include @@ -29,20 +30,20 @@ panic("Xen: feature %s not available!\n", #f); \ } =20 -u8 xen_features[XENFEAT_NR_SUBMAPS * 32] __read_mostly; +__ro_after_init DECLARE_BITMAP(xen_features, XENFEAT_NR_SUBMAPS * 32); EXPORT_SYMBOL_GPL(xen_features); =20 -void xen_setup_features(void) +void __init xen_setup_features(void) { struct xen_feature_info fi; - int i, j; + int i; =20 for (i =3D 0; i < XENFEAT_NR_SUBMAPS; i++) { fi=2Esubmap_idx =3D i; if (HYPERVISOR_xen_version(XENVER_get_features, &fi) < 0) break; - for (j =3D 0; j < 32; j++) - xen_features[i * 32 + j] =3D !!(fi=2Esubmap & 1U << j); + + bitmap_write(xen_features, fi=2Esubmap, i * 32, 32); } =20 if (xen_pv_domain()) { diff --git a/include/xen/features=2Eh b/include/xen/features=2Eh index e4cb464386a9=2E=2E8cca0741d77d 100644 --- a/include/xen/features=2Eh +++ b/include/xen/features=2Eh @@ -10,15 +10,17 @@ #ifndef __XEN_FEATURES_H__ #define __XEN_FEATURES_H__ =20 +#include +#include #include =20 -void xen_setup_features(void); +void __init xen_setup_features(void); =20 -extern u8 xen_features[XENFEAT_NR_SUBMAPS * 32]; +extern __ro_after_init DECLARE_BITMAP(xen_features, XENFEAT_NR_SUBMAPS * = 32); =20 -static inline int xen_feature(int flag) +static inline bool xen_feature(unsigned int flag) { - return xen_features[flag]; + return test_bit(flag, xen_features); } =20 #endif /* __ASM_XEN_FEATURES_H__ */ --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2f7.9f97d616ee87ccca.1a145ae0000.8be10a07f18f35a6=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452485.1667308 (Exim 4.92) (envelope-from ) id 1xHlOE-0006Yu-GL; Fri, 16 Oct 2026 17:06:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452485.1667308; Fri, 16 Oct 2026 17:06:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOE-0006Yh-CC; Fri, 16 Oct 2026 17:06:42 +0000 Received: by outflank-mailman (input) for mailman id 1452485; Fri, 16 Oct 2026 17:06:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOD-0006UT-2H for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlO7-003ZI0-FR for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:35 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2598e-2eae-0a2a0a5409dd-0a2a450bb738-18 for ; Fri, 16 Oct 2026 19:06:35 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2599b-b7e8-0a2a450b0019-b9ff1c23910b-3 for ; Fri, 16 Oct 2026 19:06: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 1a145adfbff0008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:32 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id BDCB281C51; Fri, 16 Oct 2026 19:06: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; 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=mmhDbK1YfxrKlQEC97zC2xToiisAWCT+Z+mazkCeCQ0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=I2gbsdLJkK32Xw9kjVPKBaKvtfykk+KEFOpU8r1eaGP9o95ztAtfNUaLe7GGcWoo9aqXpTWod Yf6a5fFHaSQ06VWTxw13gK4b3tWbCtvyjipGhSA18lSf/Db95Nbgx6StuuPfRD1WmBOeJhLdlme vNScOhPIELYZ4ECF+k/dhp8td7ZwcTGdtaLtpN2XgT5Wqvlv1bAr5K570GKlUnyONDflvgDGJiH qj4oUXeak75kF0KeChNn8mm6SVQxkozkERXy7uYn0YQLpBKhlzqaaDtSjqU/8Efcjkhs0BzKsp4 Cl2tYYHAjmR72wuwxG9jIqtZUFhJsgahYhV0+sV1fqeQ== X-Zone-Loop: 8c2572fbe5a69fcc666fad8bf8d5629e6a3aa37d453d x-campaign-type: default x-transaction-id: a6670906-61e6-427c-9bf2-aff06d8555af x-swg-uid: 01-0fab3c21-0372-41a5-9288-5c22785feb60 X-Mailer: Sweego Message-ID: <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@vates.tech> x-swg-bid: 1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early Date: Fri, 16 Oct 2026 19:06:06 +0200 In-Reply-To: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2f6.a84eb19d1ebebf92.1a145adf99c.d738e27dff4c8a36=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170391964 X-purgate-ID: tlsNG-42698a/1792170395-188C99EA-28A9EB3B/0/0 X-purgate-type: clean X-purgate-size: 1568 ---=Part.2f6.a84eb19d1ebebf92.1a145adf99c.d738e27dff4c8a36=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is no longer required since [1]=2E At this moment of boot, per_cpu areas are not initialized, which prevents using VCPUOP_register_runstate_phys_area as per_cpu_ptr_to_phys() would misbehave in this case=2E [1] 8a22b9996b00 ("xen: drop xen_sched_clock in favour of using plain wall= clock time") --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: David Woodhouse CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg arch/x86/xen/enlighten_pv=2Ec | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/xen/enlighten_pv=2Ec b/arch/x86/xen/enlighten_pv=2Ec index 2c64b388f616=2E=2Eab3374b2f012 100644 --- a/arch/x86/xen/enlighten_pv=2Ec +++ b/arch/x86/xen/enlighten_pv=2Ec @@ -1551,9 +1551,6 @@ asmlinkage __visible void __init xen_start_kernel(st= ruct start_info *si) #endif xen_raw_console_write("about to get started=2E=2E=2E\n"); =20 - /* We need this for printk timestamps */ - xen_setup_runstate_info(0); - xen_efi_init(&boot_params); =20 /* Start the world */ --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2f6.a84eb19d1ebebf92.1a145adf99c.d738e27dff4c8a36=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452486.1667316 (Exim 4.92) (envelope-from ) id 1xHlOF-0006mB-L9; Fri, 16 Oct 2026 17:06:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452486.1667316; Fri, 16 Oct 2026 17: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 1xHlOF-0006m0-I8; Fri, 16 Oct 2026 17:06:43 +0000 Received: by outflank-mailman (input) for mailman id 1452486; Fri, 16 Oct 2026 17:06:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOE-0006YS-6s for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlOD-006h1r-D7 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:41 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25982-bab6-0a2a0a5309dd-0a2a4508963e-30 for ; Fri, 16 Oct 2026 19:06:41 +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 6ad259a1-f659-0a2a45080019-b9ff1c238827-3 for ; Fri, 16 Oct 2026 19:06: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a145ae07870008425.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:35 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id E759C81C51; Fri, 16 Oct 2026 19:06:34 +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=+LNBhEDwwmptohY+V5OCHc4pdC+JuNZqOfMEasILLE8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=FJIEYkiMgMfTOj7wxnvX6+4dnLFAhOMtWrQNq5SRJrPDnGcTdrRWIoSvWmJu+Xqz1ffQMqjh5 pa1OHGPj0JDFa45+U7OKUzggr50+5CsHoMtQGfGdW2i8bqlqaW1HBY6ppSmvxBDETbUQxpuEnvT DzSkYMY71zUWi70uc8/UvPIUX4TI/nRE7eSX4p8cCowLJBMiqLrDzaeOl5T7lrstSTqnVjAvG+c X/paPsOqdetMQQchtsjj4hZlpdKXR0SkQuqpHVWhRFpjt2CRGcv04i+Tod/s0UJsFZ/yQX7/eXV WlAJiY0Pb0E7Em7GM6VWy6fIIM+2FWfx2R8nNCDbCu8A== X-Zone-Loop: 42c6eaefb7a3cd665a2b57a53e2b3eb98c89f49fc8d4 x-campaign-type: default x-transaction-id: 52795dc7-7d01-4842-9ebf-f59bdf2e9335 x-swg-uid: 01-8c980a6c-8af4-4346-9f01-29864c53b29e X-Mailer: Sweego Message-ID: <1792170395.8631fc262581453bbf619ec5b2062170.1a145ae07870008425@vates.tech> x-swg-bid: 1792170395.8631fc262581453bbf619ec5b2062170.1a145ae07870008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/8] xen: Add gpa conversion helpers Date: Fri, 16 Oct 2026 19:06:08 +0200 In-Reply-To: <20261016170613.173406-2-teddy.astie@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <20261016170613.173406-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2f8.d083e86f72d0a7a2.1a145ae05ea.5ac65cbb0f451376=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170395115 X-purgate-ID: tlsNG-c1860d/1792170401-D477387B-F7744114/0/0 X-purgate-type: clean X-purgate-size: 4543 ---=Part.2f8.d083e86f72d0a7a2.1a145ae05ea.5ac65cbb0f451376=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Introduce various helpers to convert between GPA and virt/paddr=2E Signed-off-by: Teddy Astie --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg arch/x86/include/asm/xen/page=2Eh | 22 ++++++++++++++++++++++ include/xen/arm/page=2Eh | 21 +++++++++++++++++++++ 2 files changed, 43 insertions(+) diff --git a/arch/x86/include/asm/xen/page=2Eh b/arch/x86/include/asm/xen/= page=2Eh index 59f642a94b9d=2E=2Ed8fc2dc24809 100644 --- a/arch/x86/include/asm/xen/page=2Eh +++ b/arch/x86/include/asm/xen/page=2Eh @@ -26,6 +26,11 @@ typedef struct xpaddr { phys_addr_t paddr; } xpaddr_t; =20 +/* Xen guest physical address */ +typedef struct xgaddr { + phys_addr_t gaddr; +} xgaddr_t; + #ifdef CONFIG_X86_64 #define XEN_PHYSICAL_MASK __sme_clr((1UL << 52) - 1) #else @@ -37,6 +42,7 @@ typedef struct xpaddr { =20 #define XMADDR(x) ((xmaddr_t) { =2Emaddr =3D (x) }) #define XPADDR(x) ((xpaddr_t) { =2Epaddr =3D (x) }) +#define XGADDR(x) ((xgaddr_t) { =2Egaddr =3D (x) }) =20 /**** MACHINE <-> PHYSICAL CONVERSION MACROS ****/ #define INVALID_P2M_ENTRY (~0UL) @@ -256,6 +262,18 @@ static inline unsigned long gfn_to_pfn(unsigned long = gfn) return mfn_to_pfn(gfn); } =20 +static inline xgaddr_t phys_to_guest(xpaddr_t phys) +{ + unsigned int offset =3D phys=2Epaddr & ~PAGE_MASK; + return XGADDR(PFN_PHYS(pfn_to_gfn(PFN_DOWN(phys=2Epaddr))) | offset); +} + +static inline xpaddr_t guest_to_phys(xgaddr_t guest) +{ + unsigned int offset =3D guest=2Egaddr & ~PAGE_MASK; + return XPADDR(PFN_PHYS(gfn_to_pfn(PFN_DOWN(guest=2Egaddr))) | offset); +} + /* Pseudo-physical <-> Bus conversion */ #define pfn_to_bfn(pfn) pfn_to_gfn(pfn) #define bfn_to_pfn(bfn) gfn_to_pfn(bfn) @@ -305,6 +323,10 @@ static inline unsigned long virt_to_pfn(const void *v= ) /* VIRT <-> GUEST conversion */ #define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v))) #define gfn_to_virt(g) (__va(gfn_to_pfn(g) << PAGE_SHIFT)) +#define virt_to_guest(v) (phys_to_guest(XPADDR(__pa(v)))) + +#define percpu_to_gaddr(v) \ + (phys_to_guest(XPADDR(per_cpu_ptr_to_phys(v)))) =20 static inline unsigned long pte_mfn(pte_t pte) { diff --git a/include/xen/arm/page=2Eh b/include/xen/arm/page=2Eh index e5c84ff28c8b=2E=2E1119bde2994c 100644 --- a/include/xen/arm/page=2Eh +++ b/include/xen/arm/page=2Eh @@ -24,8 +24,14 @@ typedef struct xpaddr { phys_addr_t paddr; } xpaddr_t; =20 +/* Xen guest physical address */ +typedef struct xgaddr { + phys_addr_t gaddr; +} xgaddr_t; + #define XMADDR(x) ((xmaddr_t) { =2Emaddr =3D (x) }) #define XPADDR(x) ((xpaddr_t) { =2Epaddr =3D (x) }) +#define XGADDR(x) ((xgaddr_t) { =2Egaddr =3D (x) }) =20 #define INVALID_P2M_ENTRY (~0UL) =20 @@ -54,6 +60,18 @@ static inline unsigned long gfn_to_pfn(unsigned long gf= n) return gfn; } =20 +static inline xgaddr_t phys_to_guest(xpaddr_t phys) +{ + unsigned int offset =3D phys=2Epaddr & ~PAGE_MASK; + return XGADDR(PFN_PHYS(pfn_to_gfn(PFN_DOWN(phys=2Epaddr))) | offset); +} + +static inline xpaddr_t guest_to_phys(xgaddr_t guest) +{ + unsigned int offset =3D guest=2Egaddr & ~PAGE_MASK; + return XPADDR(PFN_PHYS(gfn_to_pfn(PFN_DOWN(guest=2Egaddr))) | offset); +} + /* Pseudo-physical <-> BUS conversion */ static inline unsigned long pfn_to_bfn(unsigned long pfn) { @@ -82,9 +100,12 @@ static inline unsigned long bfn_to_pfn(unsigned long b= fn) pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT); \ }) #define gfn_to_virt(m) (__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT)) +#define virt_to_guest(v) (phys_to_guest(XPADDR(__pa(v)))) =20 #define percpu_to_gfn(v) \ (pfn_to_gfn(per_cpu_ptr_to_phys(v) >> XEN_PAGE_SHIFT)) +#define percpu_to_gaddr(v) \ + (phys_to_guest(XPADDR(per_cpu_ptr_to_phys(v)))) =20 /* Only used in PV code=2E But ARM guests are always HVM=2E */ static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr) --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2f8.d083e86f72d0a7a2.1a145ae05ea.5ac65cbb0f451376=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452487.1667325 (Exim 4.92) (envelope-from ) id 1xHlOH-00070V-3r; Fri, 16 Oct 2026 17:06:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452487.1667325; Fri, 16 Oct 2026 17:06: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 1xHlOH-00070K-1F; Fri, 16 Oct 2026 17:06:45 +0000 Received: by outflank-mailman (input) for mailman id 1452487; Fri, 16 Oct 2026 17:06:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOG-0006vu-HF for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlOF-006YfJ-Tz for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:43 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25989-8faa-0a2a0a5109dd-0a2a4502d3c0-28 for ; Fri, 16 Oct 2026 19:06:43 +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 6ad2599e-6ca4-0a2a45020019-b9ff1c12837f-4 for ; Fri, 16 Oct 2026 19:06: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a145ae0a4a0008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:36 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 98B7F81C51; Fri, 16 Oct 2026 19:06: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: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=PuEaAxriDCY/GSogovlT27z16bTwyhoDo4b6m7gADKw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=eG/8gq9+J3Klh0gS9QhoSf678kIvI0R/zFUuMmWqO7w9rtLHIseW1pn2BqRV5qmSjiV6g32Dq KT0xXr+pl+PitaH2munH/sern8mCGjEjneoG5mINtG2iy7c/5xFYRD9cectgT0wWCk8pu8P2eLE djNqDh8pon3Nzqwf0/7Wid9SRUcVKb5CFmmQl3+Sw/g8NFXGiCBo2Oqi1LmN6mzWL3GplaoGk2I oOUiIfYPcTL4oGXb3pUpofZYoORJRiqenTx1/Tdrt8RrpcswpgYxkWw6FpqxJs5E3tuBV3E/D3T WGRJWIpBTiRKnNgPzy5jy3ig9H8SlOThNnIGJRlbT89g== X-Zone-Loop: ec3a83c7039c0cc1b37dd70a6cdb60f2f9c14e3d589e x-campaign-type: default x-transaction-id: 6ebb36e5-740f-4d91-88cd-cfe4d4d01940 x-swg-uid: 01-4cc33359-792e-4a6a-beba-308e91ad3fef X-Mailer: Sweego Message-ID: <1792170396.8631fc262581453bbf619ec5b2062170.1a145ae0a4a0008425@vates.tech> x-swg-bid: 1792170396.8631fc262581453bbf619ec5b2062170.1a145ae0a4a0008425 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 , Andrew Cooper , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 4/8] x86/xen/time: Correct xen_save_time_memory_area() failure message Date: Fri, 16 Oct 2026 19:06:09 +0200 In-Reply-To: <20261016170613.173406-2-teddy.astie@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <20261016170613.173406-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2f9.ab99fe497216475c.1a145ae08a2.6220ae13ecb99cad=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170395810 X-purgate-ID: tlsNG-720697/1792170403-66CB22AC-4FF9EB57/0/0 X-purgate-type: clean X-purgate-size: 1731 ---=Part.2f9.ab99fe497216475c.1a145ae08a2.6220ae13ecb99cad=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We actually didn't fail to "save secondary vcpu time info" but just to unregister the mapping of it=2E Reported-by: Andrew Cooper Signed-off-by: Teddy Astie --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg arch/x86/xen/time=2Ec | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/time=2Ec b/arch/x86/xen/time=2Ec index 5c7822254a01=2E=2E2656b3a08553 100644 --- a/arch/x86/xen/time=2Ec +++ b/arch/x86/xen/time=2Ec @@ -407,8 +407,7 @@ void xen_save_time_memory_area(void) =20 ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; if (ret !=3D 0) - pr_notice("Cannot save secondary vcpu_time_info (err %d)", - ret); + pr_notice("Cannot unregister vcpu_time_info (err %d)\n", ret); else clear_page(xen_clock); } @@ -435,7 +434,7 @@ void xen_restore_time_memory_area(void) * call for a reliable timestamp=2E */ if (ret !=3D 0) - pr_notice("Cannot restore secondary vcpu_time_info (err %d)", + pr_notice("Cannot restore secondary vcpu_time_info (err %d)\n", ret); =20 out: --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2f9.ab99fe497216475c.1a145ae08a2.6220ae13ecb99cad=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452488.1667335 (Exim 4.92) (envelope-from ) id 1xHlOJ-0007G6-CG; Fri, 16 Oct 2026 17:06:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452488.1667335; Fri, 16 Oct 2026 17:06: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 1xHlOJ-0007Fz-7F; Fri, 16 Oct 2026 17:06:47 +0000 Received: by outflank-mailman (input) for mailman id 1452488; Fri, 16 Oct 2026 17:06:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOI-0007EQ-Eu for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlOH-006YfJ-S3 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:45 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25989-8faa-0a2a0a5109dd-0a2a4502d3c0-34 for ; Fri, 16 Oct 2026 19:06:45 +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 6ad2599e-6ca4-0a2a45020019-b9ff1c12837f-5 for ; Fri, 16 Oct 2026 19:06: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 1a145ae0c950008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:36 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 34B3B824A6; Fri, 16 Oct 2026 19:06: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: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=y5W1BwliK9YUSa6dvhU+A5YtDZM930XqJPobMpHuQxk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Q/6ZbcWrxNsFM8sz442xUGm/AWvdA3yo8MkTegrCvxqza5RNduQxi8mrS+/kD4Yt6jagUh0WQ /SQHUo8vxxnji+FisSuMVS+AJ3qcuj6Pta7FOkP7Niw3PZ0FFNno+ax3F9Rmx1lUxZOFVIu96eP rxvsm5oL9C03KYdEUzMp0vZ+IvzyQ3QzlyrIlxa+S/hrIV5r3pdAPJKN0OBzIr7k6njOI+lr03g 7ZMp6pHVhfeV/cnYnGyzcDLCwiNuNgB2e+wp6Nums8vyKEtbq9k4FVYfHon/UxqZYPsXyt2DU4s WmIAbFC7DVkn+4hx8/70lMIbemhu1PiC2Ca5WT+4shgw== X-Zone-Loop: 18f1680ce4ee15ca41b26b1952733d1c5580dac65def x-campaign-type: default x-transaction-id: 67a4ba8d-a0cb-48af-8209-4e4dcbfde07d x-swg-uid: 01-c084963e-5188-4fb3-8ae6-c62adc1c1ac3 X-Mailer: Sweego Message-ID: <1792170396.8631fc262581453bbf619ec5b2062170.1a145ae0c950008425@vates.tech> x-swg-bid: 1792170396.8631fc262581453bbf619ec5b2062170.1a145ae0c950008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 5/8] x86/xen/time: Clear xen_clock mapping later Date: Fri, 16 Oct 2026 19:06:10 +0200 In-Reply-To: <20261016170613.173406-2-teddy.astie@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <20261016170613.173406-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2fa.9b863a069a05174e.1a145ae0aee.a3d16faf8fcfb122=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170396398 X-purgate-ID: tlsNG-720697/1792170405-307C22AC-35AA7635/0/0 X-purgate-type: clean X-purgate-size: 2132 ---=Part.2fa.9b863a069a05174e.1a145ae0aee.a3d16faf8fcfb122=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The current logic has a corner case when both xen_save_time_memory_area() and xen_restore_time_memory_area() fails=2E In this case, the mapping is n= ever cleared and kept with previous pvclock values (invalidating the comment regarding VDSO_CLOCKMODE_PVCLOCK as the data may not have been zeroed)=2E Also convert the clear_page with a memset, there's no need to clear the entire page when we only care about 64 bytes of it=2E Fixes: 2229f70b5bbb ("x86/xen/time: setup vcpu 0 time info page") Signed-off-by: Teddy Astie --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: David Woodhouse CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg arch/x86/xen/time=2Ec | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/time=2Ec b/arch/x86/xen/time=2Ec index 2656b3a08553=2E=2E87b890691fcb 100644 --- a/arch/x86/xen/time=2Ec +++ b/arch/x86/xen/time=2Ec @@ -407,9 +407,7 @@ void xen_save_time_memory_area(void) =20 ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; if (ret !=3D 0) - pr_notice("Cannot unregister vcpu_time_info (err %d)\n", ret); - else - clear_page(xen_clock); + pr_notice("Cannot unregister vcpu_time_info (err %d)", ret); } =20 void xen_restore_time_memory_area(void) @@ -420,6 +418,7 @@ void xen_restore_time_memory_area(void) if (!xen_clock) goto out; =20 + memset(xen_clock, 0, sizeof(*xen_clock)); t=2Eaddr=2Ev =3D &xen_clock->pvti; =20 ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2fa.9b863a069a05174e.1a145ae0aee.a3d16faf8fcfb122=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452489.1667343 (Exim 4.92) (envelope-from ) id 1xHlOM-0007Ye-KS; Fri, 16 Oct 2026 17:06:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452489.1667343; Fri, 16 Oct 2026 17:06: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 1xHlOM-0007YT-Fp; Fri, 16 Oct 2026 17:06:50 +0000 Received: by outflank-mailman (input) for mailman id 1452489; Fri, 16 Oct 2026 17:06:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOL-0007Vb-5F for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlOK-003ZI0-IY for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:48 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2598e-2eae-0a2a0a5409dd-0a2a450bb738-30 for ; Fri, 16 Oct 2026 19:06:48 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad259a8-b7e8-0a2a450b0019-b9ff1c239dbf-3 for ; Fri, 16 Oct 2026 19:06: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a145ae0f160008425.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:37 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id D40FC829FC; Fri, 16 Oct 2026 19:06: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: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=VGNPS3w2CNQZ7QQsLrPRVGZhQap8j+LcTS6Svo8f2oI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=dFcJb/imoYkXw8b8n0p6xbJHqzACkLg8FUUZnqGbyuugvrCQYsl/+XwEts/QQXEnPEVTViPm7 b9CrS5xbBzDmls8VhHvpeFQVQykodlNsV/4PmHh2Slm7rhLNxbKo20PznCm+AYCjNYMTykWMRaI bhe6MPYHnvsr0ath5/MhgA0TICYPninKY+rOBIP7lDBADpjqytNEr6+U8q5IXM8GScrAVO+AAO7 zVJsbQN9RiGlHCjloOOKq8Fl//8RFo1yPfOWS7+X4X+vwDMzrVuzLG7IW9sgRSm20uml21qEZJe oPut8Lur+nFXqcddbbp7g16WlUNqohI5y8CBHuNDfkHA== X-Zone-Loop: 8d753c50b40e7a6791a7ba262acded51e21adc6eab8e x-campaign-type: default x-transaction-id: 65d4361b-6b20-4bf4-b702-2edbe38e2ea0 x-swg-uid: 01-2f82f688-109f-467f-8bd4-a35c553e2c58 X-Mailer: Sweego Message-ID: <1792170397.8631fc262581453bbf619ec5b2062170.1a145ae0f160008425@vates.tech> x-swg-bid: 1792170397.8631fc262581453bbf619ec5b2062170.1a145ae0f160008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 6/8] x86/xen/time: Mark xen_setup_vsyscall_time_info() __init Date: Fri, 16 Oct 2026 19:06:11 +0200 In-Reply-To: <20261016170613.173406-2-teddy.astie@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <20261016170613.173406-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2fb.506bd15dabbebbe5.1a145ae0d6a.a5ca2bfd03d18e1b=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170397034 X-purgate-ID: tlsNG-42698a/1792170408-1B2DC9EA-638EF5FA/0/0 X-purgate-type: clean X-purgate-size: 1350 ---=Part.2fb.506bd15dabbebbe5.1a145ae0d6a.a5ca2bfd03d18e1b=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This function is only called by xen_time_init() being itself __init=2E Signed-off-by: Teddy Astie --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg arch/x86/xen/time=2Ec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/time=2Ec b/arch/x86/xen/time=2Ec index 87b890691fcb=2E=2E0d8643cc8159 100644 --- a/arch/x86/xen/time=2Ec +++ b/arch/x86/xen/time=2Ec @@ -442,7 +442,7 @@ void xen_restore_time_memory_area(void) xen_sched_clock_offset =3D xen_clocksource_read() - xen_clock_value_save= d; } =20 -static void xen_setup_vsyscall_time_info(void) +static void __init xen_setup_vsyscall_time_info(void) { struct vcpu_register_time_memory_area t; struct pvclock_vsyscall_time_info *ti; --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2fb.506bd15dabbebbe5.1a145ae0d6a.a5ca2bfd03d18e1b=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452490.1667353 (Exim 4.92) (envelope-from ) id 1xHlOO-0007q8-Um; Fri, 16 Oct 2026 17:06:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452490.1667353; Fri, 16 Oct 2026 17:06: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 1xHlOO-0007ps-OY; Fri, 16 Oct 2026 17:06:52 +0000 Received: by outflank-mailman (input) for mailman id 1452490; Fri, 16 Oct 2026 17:06:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlON-0007hO-CJ for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlOM-003ZI0-PR for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:50 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25998-2eae-0a2a0a5409dd-0a2a45018f3e-22 for ; Fri, 16 Oct 2026 19:06:50 +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 6ad259aa-5984-0a2a45010019-b9ff1c2296c1-3 for ; Fri, 16 Oct 2026 19:06: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 1a145ae12660008425.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:38 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 6A8C182A13; Fri, 16 Oct 2026 19:06:37 +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=VS4quSyVJhh8mzjqUt+vcxd0p5YKDAPuKL8x46oLPQ4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Ngwg0LiOjRWYsTuh8be8o3VL3vm9Z6IvImBSborsP8Ck+qglz3fTuuu5HJTvRu50SxVwTpYv/ zokYXgVbAn6bgLZLqmFxB26NS1eJnnnxzjGRIMlOnaLF4oIV9o+ru8SPtSUhmBq8nfTS9Yd3giA M9qQgV6pY0cjgQ2PJ336xl4SXYS6/WtId4YcXixI9yZS7W8+uy9SZGLy7PsqPWIez4+a7tpCdbX unYX/Zt3vHrc+MenjtIe9LsU+UXB43HgyfwKzC249WUugp/nDkLw2+UuwUX981OhrTS8ldqJFa5 aBpWvTkETVGXgQbDRkxJHUeW+4uPxBVrvwcguYu1wIRg== X-Zone-Loop: 6b903ccc1841e9912c15d2cf2358dfced6715bd3f703 x-campaign-type: default x-transaction-id: 31f0c2a9-1bd0-4229-88f3-6a476471b5d9 x-swg-uid: 01-dcffddd3-b704-4a2b-8adf-68aeb56c5ca0 X-Mailer: Sweego Message-ID: <1792170398.8631fc262581453bbf619ec5b2062170.1a145ae12660008425@vates.tech> x-swg-bid: 1792170398.8631fc262581453bbf619ec5b2062170.1a145ae12660008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , George Dunlap , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 7/8] x86/xen/time: Use VCPUOP_register_{runstate,vcpu_time}_phys_area when available Date: Fri, 16 Oct 2026 19:06:12 +0200 In-Reply-To: <20261016170613.173406-2-teddy.astie@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <20261016170613.173406-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2fc.1e3869260948a3ed.1a145ae0fc6.e3537833f6f70b36=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170397638 X-purgate-ID: tlsNG-d62444/1792170410-BDE78757-EC8C4E95/0/0 X-purgate-type: clean X-purgate-size: 8806 ---=Part.2fc.1e3869260948a3ed.1a145ae0fc6.e3537833f6f70b36=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Updating these area can be expensive when done through virtual addresses (especially for runstate one), in particular for HVM/PVH guests=2E Xen 4=2E18 introduced physical address alternatives to address those short-commings, but they aren't used currently=2E Fix it by using these alternatives when available (when reported in XENFEAT_{runstate,vcpu_time}_phys_area=2E Assisted-by: LLM [guidance and testing] Signed-off-by: Teddy Astie --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: David Woodhouse CC: George Dunlap CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg For PV, this actually depends on "x86/xen/pv: Don't setup runstate area too early" When using phys_area ABI, the struct is not allowed to cross a page boundary anymore, hence we need to be careful with per-cpu struct alignment=2E v2: - Add PV domain support=2E - Clarify xen_register_time_area() - fold out &per_cpu(xen_runstate, cpu) in a separate variable --- arch/x86/xen/time=2Ec | 42 ++++++++++++++++++++------------ drivers/xen/time=2Ec | 24 +++++++++++++----- include/xen/interface/features=2Eh | 9 +++++++ include/xen/interface/vcpu=2Eh | 17 +++++++++++++ 4 files changed, 71 insertions(+), 21 deletions(-) diff --git a/arch/x86/xen/time=2Ec b/arch/x86/xen/time=2Ec index 0d8643cc8159=2E=2E5fa22925c0d5 100644 --- a/arch/x86/xen/time=2Ec +++ b/arch/x86/xen/time=2Ec @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -37,6 +38,28 @@ =20 static u64 xen_sched_clock_offset __read_mostly; =20 +/* + * Register the vcpu time info for vCPU 0 to pvti=2E + * When NULL is passed, unregister the time area instead=2E + * + * Register using physical address when available (reported by + * XENFEAT_vcpu_time_phys_area), and use virtual address otherwise=2E + */ +static int xen_register_time_area(struct pvclock_vcpu_time_info *pvti) +{ + struct vcpu_register_time_memory_area t; + bool phys =3D xen_feature(XENFEAT_vcpu_time_phys_area); + int op =3D phys ? VCPUOP_register_vcpu_time_phys_area + : VCPUOP_register_vcpu_time_memory_area; + + if (phys) + t=2Eaddr=2Ep =3D pvti ? virt_to_guest(pvti)=2Egaddr : ~0LLU; + else + t=2Eaddr=2Ev =3D pvti; + + return HYPERVISOR_vcpu_op(op, 0, &t); +} + /* Get the TSC speed from Xen */ static unsigned long xen_tsc_khz(void) { @@ -395,7 +418,6 @@ static u64 xen_clock_value_saved; =20 void xen_save_time_memory_area(void) { - struct vcpu_register_time_memory_area t; int ret; =20 xen_clock_value_saved =3D xen_clocksource_read() - xen_sched_clock_offse= t; @@ -403,25 +425,20 @@ void xen_save_time_memory_area(void) if (!xen_clock) return; =20 - t=2Eaddr=2Ev =3D NULL; - - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; + ret =3D xen_register_time_area(NULL); if (ret !=3D 0) pr_notice("Cannot unregister vcpu_time_info (err %d)", ret); } =20 void xen_restore_time_memory_area(void) { - struct vcpu_register_time_memory_area t; int ret; =20 if (!xen_clock) goto out; =20 memset(xen_clock, 0, sizeof(*xen_clock)); - t=2Eaddr=2Ev =3D &xen_clock->pvti; - - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; + ret =3D xen_register_time_area(&xen_clock->pvti); =20 /* * We don't disable VDSO_CLOCKMODE_PVCLOCK entirely if it fails to @@ -444,7 +461,6 @@ void xen_restore_time_memory_area(void) =20 static void __init xen_setup_vsyscall_time_info(void) { - struct vcpu_register_time_memory_area t; struct pvclock_vsyscall_time_info *ti; int ret; =20 @@ -452,9 +468,7 @@ static void __init xen_setup_vsyscall_time_info(void) if (!ti) return; =20 - t=2Eaddr=2Ev =3D &ti->pvti; - - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t)= ; + ret =3D xen_register_time_area(&ti->pvti); if (ret) { pr_notice("xen: VDSO_CLOCKMODE_PVCLOCK not supported (err %d)\n", ret); free_page((unsigned long)ti); @@ -467,9 +481,7 @@ static void __init xen_setup_vsyscall_time_info(void) * still check it in case hypervisor is buggy=2E */ if (!(ti->pvti=2Eflags & PVCLOCK_TSC_STABLE_BIT)) { - t=2Eaddr=2Ev =3D NULL; - ret =3D HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, - 0, &t); + ret =3D xen_register_time_area(NULL); if (!ret) free_page((unsigned long)ti); =20 diff --git a/drivers/xen/time=2Ec b/drivers/xen/time=2Ec index a2be0a4d45b0=2E=2E49e61ad905d9 100644 --- a/drivers/xen/time=2Ec +++ b/drivers/xen/time=2Ec @@ -10,6 +10,7 @@ #include #include =20 +#include #include #include =20 @@ -19,8 +20,12 @@ #include #include =20 -/* runstate info updated by Xen */ -static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate); +/* + * Runstate info updated by Xen=2E The phys-area ABI doesn't allow it to = cross + * a page boundary; the struct is 48 bytes, so 64 is the smallest alignme= nt + * that guarantees this=2E + */ +static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate) __aligned(= 64); =20 static DEFINE_PER_CPU(u64[4], old_runstate_time); =20 @@ -152,11 +157,18 @@ u64 xen_steal_clock(int cpu) void xen_setup_runstate_info(int cpu) { struct vcpu_register_runstate_memory_area area; + unsigned int op; + struct vcpu_runstate_info *cpu_runstate =3D &per_cpu(xen_runstate, cpu); + + if (xen_feature(XENFEAT_runstate_phys_area)) { + op =3D VCPUOP_register_runstate_phys_area; + area=2Eaddr=2Ep =3D percpu_to_gaddr(cpu_runstate)=2Egaddr; + } else { + op =3D VCPUOP_register_runstate_memory_area; + area=2Eaddr=2Ev =3D cpu_runstate; + } =20 - area=2Eaddr=2Ev =3D &per_cpu(xen_runstate, cpu); - - if (HYPERVISOR_vcpu_op(VCPUOP_register_runstate_memory_area, - xen_vcpu_nr(cpu), &area)) + if (HYPERVISOR_vcpu_op(op, xen_vcpu_nr(cpu), &area)) BUG(); } =20 diff --git a/include/xen/interface/features=2Eh b/include/xen/interface/fe= atures=2Eh index 53f760378e39=2E=2Ef00144a7c790 100644 --- a/include/xen/interface/features=2Eh +++ b/include/xen/interface/features=2Eh @@ -97,6 +97,15 @@ #define XENFEAT_not_direct_mapped 16 #define XENFEAT_direct_mapped 17 =20 +/* + * Signal whether the domain is able to use the following hypercalls: + * + * VCPUOP_register_runstate_phys_area + * VCPUOP_register_vcpu_time_phys_area + */ +#define XENFEAT_runstate_phys_area 18 +#define XENFEAT_vcpu_time_phys_area 19 + #define XENFEAT_NR_SUBMAPS 1 =20 #endif /* __XEN_PUBLIC_FEATURES_H__ */ diff --git a/include/xen/interface/vcpu=2Eh b/include/xen/interface/vcpu= =2Eh index c7cc28ad8d63=2E=2Ed3858233c32f 100644 --- a/include/xen/interface/vcpu=2Eh +++ b/include/xen/interface/vcpu=2Eh @@ -203,4 +203,21 @@ struct vcpu_register_time_memory_area { }; DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_time_memory_area); =20 +/* + * Like the respective VCPUOP_register_*_memory_area, just using the "add= r=2Ep" + * field of the supplied struct as a guest physical address (i=2Ee=2E in = GFN space)=2E + * The respective area may not cross a page boundary=2E Pass ~0 to unreg= ister an + * area=2E Note that as long as an area is registered by physical addres= s, the + * linear address based area will not be serviced (updated) by the hyperv= isor=2E + * + * Note that the area registered via VCPUOP_register_runstate_phys_area w= ill + * be updated in the same manner as the one registered via virtual addres= s PLUS + * VMASST_TYPE_runstate_update_flag engaged by the domain=2E + * + * XENFEAT_{runstate,vcpu_time}_phys_area feature bits signal the availab= ility + * of these ops=2E + */ +#define VCPUOP_register_runstate_phys_area 14 +#define VCPUOP_register_vcpu_time_phys_area 15 + #endif /* __XEN_PUBLIC_VCPU_H__ */ --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2fc.1e3869260948a3ed.1a145ae0fc6.e3537833f6f70b36=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:06:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:06:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452491.1667361 (Exim 4.92) (envelope-from ) id 1xHlOQ-00086N-Db; Fri, 16 Oct 2026 17:06:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452491.1667361; Fri, 16 Oct 2026 17:06: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 1xHlOQ-00085R-98; Fri, 16 Oct 2026 17:06:54 +0000 Received: by outflank-mailman (input) for mailman id 1452491; Fri, 16 Oct 2026 17:06:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlOP-0007qM-3U for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:06:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlOO-003ZI0-GV for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:06:52 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2598e-2eae-0a2a0a5409dd-0a2a450bb738-34 for ; Fri, 16 Oct 2026 19:06:52 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad259a8-b7e8-0a2a450b0019-b9ff1c239dbf-4 for ; Fri, 16 Oct 2026 19:06: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 1a145ae179d0008425.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 16 Oct 2026 17:06:39 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id E498B82A13; Fri, 16 Oct 2026 19:06:38 +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=yLIwvuu2bysJfwSI8OuwD31qYGoD1EaRqVv9VYrVG3k=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=dUTlLfLrkNIS4QhsKZvr0gqNn0wtdXE9FFGgCewAtf6cpscTW5DBASuRsIp45DK9d0oTsl+Kf oYQDXSJD8YYzrADpXlKm5tTWLcGQHH/XKNIoUAcRginHVT5+t4NQYR/O2bkVB89cQBGKdKF7c9z dqdE06VtRa/C3i/h+syxER6W97bUMRlMkzgjGrzo4WfDnZKpN3eSvb77GiLEByEnnifQhBZ++1P 4pD1vT7DHk2SwOXQeuo3gMTJUcktvbzjmV50mUM4Ok3xBbRl82UUPQ+T2qnouwCjIM0Bs3CSiAc gzNAOmMGuKmM4yuJUPXKSV18S4q3TYgQNkTULNjiEqaw== X-Zone-Loop: 9cf8136d7f5b99e25b6ffffa60f506bbd71211a931da x-campaign-type: default x-transaction-id: 7cd92e10-f6b5-4e59-988d-a37b2492d0aa x-swg-uid: 01-db896722-231d-40ab-86fc-4e5ad6ed6f9b X-Mailer: Sweego Message-ID: <1792170399.8631fc262581453bbf619ec5b2062170.1a145ae179d0008425@vates.tech> x-swg-bid: 1792170399.8631fc262581453bbf619ec5b2062170.1a145ae179d0008425 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 , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH v2 8/8] xen/sysfs: Honor cached xen_features instead Date: Fri, 16 Oct 2026 19:06:13 +0200 In-Reply-To: <20261016170613.173406-2-teddy.astie@vates.tech> References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <20261016170613.173406-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2fd.83b0da6fb57bea0e.1a145ae1581.a87c91867418418c=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792170399105 X-purgate-ID: tlsNG-42698a/1792170412-A98C19EA-D76BDCB7/0/0 X-purgate-type: clean X-purgate-size: 2480 ---=Part.2fd.83b0da6fb57bea0e.1a145ae1581.a87c91867418418c=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Currently, /sys/hypervisor/properties/features queries the xen features from the hypervisor even if it doesn't match what Linux uses itself (i=2Ee what were the features at the time of the boot)=2E For consistency when migrations are involved, report cached xen_features instead, that also avoids making hypercalls to query this information=2E Signed-off-by: Teddy Astie --- CC: Juergen Gross CC: Boris Ostrovsky CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: x86@kernel=2Eorg CC: linux-kernel@vger=2Ekernel=2Eorg I'm not sure what /sys/hypervisor/features is expected to show between what Linux considers (proposal) and what the hypervisor tells (current behavior)=2E drivers/xen/sys-hypervisor=2Ec | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/xen/sys-hypervisor=2Ec b/drivers/xen/sys-hypervisor= =2Ec index 91923242a5ae=2E=2E7786bb40b966 100644 --- a/drivers/xen/sys-hypervisor=2Ec +++ b/drivers/xen/sys-hypervisor=2Ec @@ -4,6 +4,7 @@ * Authored by: Mike D=2E Day */ =20 +#include #include #include #include @@ -15,6 +16,7 @@ =20 #include #include +#include #include #include #ifdef CONFIG_XEN_HAVE_VPMU @@ -321,15 +323,9 @@ HYPERVISOR_ATTR_RO(pagesize); =20 static ssize_t xen_feature_show(int index, char *buffer) { - ssize_t ret; - struct xen_feature_info info; - - info=2Esubmap_idx =3D index; - ret =3D HYPERVISOR_xen_version(XENVER_get_features, &info); - if (!ret) - ret =3D sprintf(buffer, "%08x", info=2Esubmap); + unsigned long submap =3D bitmap_read(xen_features, index * 32, 32); =20 - return ret; + return sprintf(buffer, "%08x", (unsigned int)submap); } =20 static ssize_t features_show(struct hyp_sysfs_attr *attr, char *buffer) --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2fd.83b0da6fb57bea0e.1a145ae1581.a87c91867418418c=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:13:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:13:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452529.1667369 (Exim 4.92) (envelope-from ) id 1xHlUI-00046Z-38; Fri, 16 Oct 2026 17:12:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452529.1667369; Fri, 16 Oct 2026 17:12: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 1xHlUI-00046S-0V; Fri, 16 Oct 2026 17:12:58 +0000 Received: by outflank-mailman (input) for mailman id 1452529; Fri, 16 Oct 2026 17:12:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlUG-00046M-SG for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:12:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHlUF-009CVE-UJ for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:12:55 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25b09-2eae-0a2a0a5409dd-0a2a45078bcc-20 for ; Fri, 16 Oct 2026 19:12:55 +0200 Received: from [52.101.48.20] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad25b15-b4ea-0a2a45070019-346530149ee3-3 for ; Fri, 16 Oct 2026 19:12:55 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by IA1PR03MB8047.namprd03.prod.outlook.com (2603:10b6:208:596::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Fri, 16 Oct 2026 17:12: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.0522.013; Fri, 16 Oct 2026 17:12: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=AtPyAfUwQM4kRZt1I2+z49Y6CCNqAjBR+Fdvka+XrrdGW3piEvIl7CQ5/rG/YHm+bLoHpLBG75jFZXfl2kBec41SP2fVOSTDKqbXhcP2xSYioPmiLdEbzZ34ZZoYkjYNqmJpwZdix6XS8EwD/UkfL8EzCbnjQC8wcH5xkMyQsU7chIgAO+66zpveM11b3+yy8XUTMkbTjhiQNW1aqajsVNGYriJOyvwcdWfsosxKDV/i+ZVzKydtpvy9QtJP3etSbscZRymO4AH4aLAXnv0+KT2ZEQrRL5MBMow94a2OkREJUgOG1c+hwCQ04+JGSSUclXtZwZ7zKk9ejoqj5oOV4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Wx3xxakn7miKY98Oiom+g8lfr96kdBrrA0yi3iCTzPY=; b=EvIgOgI30DHolmb2+brbiL3Rn30LXKdnynyo32MqFYYaOoZIqM+bfF2q9CK6Ev+3K2sA6/Wd45lTNUZJtn/4SeV1gX6uum6iHZ6OQljIITUyvkjfNXmQtM2CEnHL18o6g8z/EHRilqOuUZhzoxCmqFICb1dleuwJJ4Oi/EzCnw+gf+i6REFtmy3gkKg5Qe188AAsH0LmWv+VNQ6H8U2UpSyqkhvh9isOg8SdRZvMwECPWE34ruvZchk+nQ6Do4W9bHSTe+gYWSrQhCRZUzvfeYf94jvibILznbFDvctne7C76bvshwv2HfLgkKV/omrKI2YV4WU3i8uJfSXyoqwcLw== 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=Wx3xxakn7miKY98Oiom+g8lfr96kdBrrA0yi3iCTzPY=; b=gY6uCxi8pNg99awK6SqpLywG+Y1gZ8mr5JWeQISjynWu8RUTaJ7jDBAiBYApIoj+nNfYV2TqKJ7ipeUMaTXcXbE9ldsPk5iKq0LYIfajO/KbosipQU7iDSn0I0zZmaJW6jh3tvNX3R5dXcUCf5X0at2JGW3GYekbZDfFhizr1oE= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <78ead290-fbf6-4aa8-b918-1f53abe2dfca@citrix.com> Date: Fri, 16 Oct 2026 18:12:46 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v4 1/4] x86: record SSP at non-guest entry points To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <26f23087-e864-47de-84b9-0e3dc10dc941@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: <26f23087-e864-47de-84b9-0e3dc10dc941@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0050.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ac::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_|IA1PR03MB8047:EE_ X-MS-Office365-Filtering-Correlation-Id: 700c5bc3-adcd-453e-2661-08df2ba8b4f1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|4143699003|11063799006|56012099006|22082099003|18002099003|10067099003|261009223027099003|3023799007; X-Microsoft-Antispam-Message-Info: pPSniK7xc+55F1VjEvwYCSRLTsRU5LwbcXn6VFordkkmNCQDBn6nGGNY1hxfssTe00HzAXElkB2nI0jsWB1hS/n9Faq8ZzOD6eixF/xWtTMNePP9filELrQ/3GLZZDE2ZVhbH12gaiioW8YarfJzzJQz+qYT+K9nZptCfLKMC4wmJgHgAAsc25dcxHqLP3wT61hfEHKB8mj9/HhIfP8g6u030XgRb+DUW3UyFmGeEGKwQ96Lywxn82hUIvq/EWc1adgHu8yY8XiYOby7DkhptdrV16VRCSpIccIinTdsAUOokdq4u98Rj62vjnAms1uQA5z1g+6Z0CeigQv5WdT5s7F2Ui4t2ROCmDPyKdiJIc03+bCiPbqc/6rQc8BEFlu3aPqz3wCRRENm70SFdDAmcSALUW0S95J92qUxm2zZ/R7DohE+NSV/qe4kQdq+mZt+3oV+kvSid9123Kk4vu3HRwNM5CvIXmezYu77mqWRpUaMYj8zm4D+Zw5likgxrLmkZpou7rcjmfTVrNAs3gPIV63OZ5hAeUgBtVMiIOJnyDnQSHgc0sF+XZ0ySUQ867wOoUnm4EDyVsmwX1FZTZO2EW8BfK+A4dPdvXaJfL7y33eDqrJvX5eNHJrOYVHv4xi8gIBDtqWG83i8yGOQBPul7JmpKKRG+qIDhMjbu1Bzaq8= 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)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003)(10067099003)(261009223027099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?KysrbmNaellUQlB4OWpNbFRXWGVBbGVPVkhRZkNIVExRdm16Ylp5b3pGTytW?= =?utf-8?B?SWNYblgxN0wrMFNwNko4R0xGV1g0eUxWZERHdXVTLzJHNmJ3YW1PYVFUajVu?= =?utf-8?B?NUJjUjROdi93MXRnVHVnZjZ1UThFb2draktmcWJ3MGhlbUlWa0hSdHFJOUUv?= =?utf-8?B?cnMzTmhyNDVkM1Q0MmhKMThZcEJ4bm9aRkN5eVEvV2hhMUtGZzhqUTBKMlhL?= =?utf-8?B?MWYycmExTENoUWJudnU5Uk54eFB5c2V4WkNnZDU1ZXFjR1hxL1QxMElOdEg2?= =?utf-8?B?MUdwWVIyK1hhL0Mvbjd5eTQrQWRxTVJKZmdCUDdIY1VGSkdpbkllSnFTV2lV?= =?utf-8?B?QzJlQXFjS1p1ZFJFU210VEI0WUp2N1FLSzlaVi8zRlRiSlNnemFLbVV5ZGhn?= =?utf-8?B?R25rajF6T3dCVi96MXdpd01CSkN2T1d6WXVzNUxkOUxJbnFYUTN0NlhtQVVu?= =?utf-8?B?Q2lEcC8wYmMzd3NINm9JYWZ4ODdyeGpFRk9yTnlwMFJTeUM5MDFEUmsySHlI?= =?utf-8?B?UngrZDFLYmpxeXo1RTNyTURtVnZzdmJZQW9FcmFwVzVjaVRqVy9FL1NtQnZk?= =?utf-8?B?MHIreWdPdW9JYTBhcytOWU1ySmlTdWRQYisvdEZZZVBPS2pZYzhDUEtyUzRQ?= =?utf-8?B?b2FGdXJrVGxOWXpYYlNwYng2QXZYaWVMWE9vdDNkV1IyVW1kdmwza2dkc0Uv?= =?utf-8?B?QzJvcWdQMEtNT1VSWGhlSUNnRjdPbHNrRTczQ2d1QzJZVTk0R1liNGtmSTFp?= =?utf-8?B?M3ZMSkR1QU55OUcwaTNQU0I1VEhyYTFpMXFGL0RGa296ckFvNnFoa3FlelhZ?= =?utf-8?B?c1VMbk9sa2lVNnoxT012akpMZkVoRTRqaTB5UlVQa0lVeXo3ZmMzcXpSa25w?= =?utf-8?B?Szg0a0xnbGFrYlNOSkhkaTZzTGVnSmlGN1l1R29CTTNyN2d2ODhNdDhOTlpn?= =?utf-8?B?Qm1PZW54VHJvU0twQ1Z2RnJOS1d0THNLTGtsaTA0MTB3YWhUd2swQWh0WkRP?= =?utf-8?B?Z29YaHlUTGRpd243bDhFTjRWMWJwM0JIcnFmMTFWUDlkSSt5eU9IbUlueUxW?= =?utf-8?B?a0hhQnlZSTlVNkpiQk0yYVZlWnVpYVI1ZWdKY1BnUHZ1NUdTOHZwRTY1QUM2?= =?utf-8?B?emRqMWFPbm93OWs1UU9UL2wxUS9KcTM4RTFveHFBQW1ycFA2aENOR3hmZ09S?= =?utf-8?B?OTc4WnY0ZE1OellFSUtEQzZ5dnhLTm5BdzJJdHc2dWdiSUxYRnZ5RnFEUkxV?= =?utf-8?B?am8wemFPak41a013c1A2aGZVUGFacFpRemZWdklxTHdBcjFlNGllTitJVEZh?= =?utf-8?B?SzVqL0h3RlFRUkZOV1FZUW53aWQ4dzVWRldXb0RueXMveW42R3VFUmNBcTlo?= =?utf-8?B?TkNGZmNqcDV4cUEvMUNiOFgrNnQxUzZTRTFTdmN4TzBtQkp0N1c4TEMwMVNN?= =?utf-8?B?MHF3a2VqaVdOSjE5dWRaVE9oei95Q1ArNkNlTGc5ZjlWbnZLaTlvZlF0SzNh?= =?utf-8?B?cTJOVFJVSFpGS3VxbWR6WmhRdE1QK0h0WFJhOHdjVExOL1ltb1diMUFyNElz?= =?utf-8?B?NjBQVGc4dHRvaFh1QUdWOENqRXJUYVVDQzFKdlNubWlMWE04Z3JaeERwMjUx?= =?utf-8?B?UEhxNFB6cjlDRXdXRmFaY0FDUjM2YitmaHA2N0VPdmFxR1hKeWhXNHFnK2k1?= =?utf-8?B?T1JCTXFLaXlWZFRLa1hGTmpIY3hPMmdNQm1TYldBOGd1NEY0UUxxekVSVmM2?= =?utf-8?B?VEF2cVFYci9VZkkya0wxTmcrNlkya2lvKzlzdGl1R0pGQkFYNnhJTXJpbkNJ?= =?utf-8?B?MTJiSUdUWXF3T21ESCs0WHExYzRtMFBiTTk2dmVaT1R0dG16Wk8zTGRQTWJG?= =?utf-8?B?eklYb25Najk2Q2RqMkZUNjFzV2wyYzl1ZmJncmVKOHQ4V05YTlJ0R2xOZzFW?= =?utf-8?B?cS9DeG9nT2lDeDlicXIvNUxLb3M0bks5T0J1Uld1Zk14ekRXTFJFVlNTY0I5?= =?utf-8?B?ZW1zZ1o3azZJRGxFZ3dXbVYyNlk5OE1TR3QxSlJOeExYU1JoZW83eTlRZEtZ?= =?utf-8?B?bkpkWG9ueDBqcmJkZFhyNHUydWdRNFhZMms2YUQzeDNhTWVWYi9pRU5Gdm1M?= =?utf-8?B?ZEFzUmFPTmZCU1JFRUhScFlEOGxiQzArTUJwSmFoSzJCTmZycWJXRmpPNzZr?= =?utf-8?B?RVV4VHR3Yldhc1RXdlNEM2o3UWlQbnc5TFkzekpBcytwMjRwYUJ0UzZGbWhv?= =?utf-8?B?eFVWWSthSkYzQkhMMzZNanU4dHFXYmd5SW1HanFjQVkwZXBQMWhLWjlmREdw?= =?utf-8?B?eWF0OTdjSkF5Y2tHQWJaa3cwek95aWdWUm5nOEQ1dDNMYnY2OTByS3cxUnd0?= =?utf-8?Q?QIXrjI9X2rDaRGTc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 700c5bc3-adcd-453e-2661-08df2ba8b4f1 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 17:12:50.1030 (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: eFARwvdkqJfNhVLJ7z293oxiJC3TR2pl0GVh78q6Mone2GU7WXwpPWCNrfz7+fyTebfEqnhjsSg6gT/tsAnmlcUC0JV1RyF+HFIH5OA/DH4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8047 X-purgate-ID: tlsNG-ef75cf/1792170775-342F4AE4-1E2DCB02/0/0 X-purgate-type: clean X-purgate-size: 2571 On 27/07/2026 11:26 am, Jan Beulich wrote: > --- a/xen/arch/x86/include/asm/asm_defns.h > +++ b/xen/arch/x86/include/asm/asm_defns.h > @@ -220,9 +220,11 @@ static always_inline void stac(void) > > #ifdef __ASSEMBLER__ > /* > - * Push and clear GPRs > + * Push and clear GPRs. > + * > + * Use sites may override ssp to 0. It should never be overridden to 1. > */ > -.macro PUSH_AND_CLEAR_GPRS > +.macro PUSH_AND_CLEAR_GPRS ssp=IS_ENABLED(CONFIG_XEN_SHSTK) > push %rdi > xor %edi, %edi > push %rsi > @@ -233,6 +235,9 @@ static always_inline void stac(void) > xor %ecx, %ecx > push %rax > xor %eax, %eax > + .if \ssp > + rdsspq %rcx > + .endif > push %r8 > xor %r8d, %r8d > push %r9 > @@ -259,12 +264,18 @@ static always_inline void stac(void) > xor %r14d, %r14d > push %r15 > xor %r15d, %r15d > +#ifdef CONFIG_XEN_SHSTK > + push %rcx > +#endif > .endm I don't like the ssp= parameter here.  It's invasive at may callsites, doesn't 0 the value in all Ring3 frames anyway, and the asymmetry makes the construct fragile.  Furthermore, the manual register scheduling really isn't necessary on CPUs where it's not a NOP. I suggest having this: +#ifdef CONFIG_XEN_SHSTK +        rdsspq %rcx +        push  %rcx +#endif always filling in the value.  rdsspq is pretty close to free (frankly, I would be surprised if it wasn't subject to mov elimination in the pipeline, given how tightly coupled SSP needs to be to RSP for CALL/RET uops to work). > > /* > * POP GPRs from a UREGS_* frame on the stack. Does not modify flags. > */ > .macro POP_GPRS skip_rax=0 > +#ifdef CONFIG_XEN_SHSTK > + pop %rcx > +#endif > pop %r15 > pop %r14 > pop %r13 > --- a/xen/arch/x86/include/asm/cpu-user-regs.h > +++ b/xen/arch/x86/include/asm/cpu-user-regs.h > @@ -11,6 +11,15 @@ > */ > struct cpu_user_regs > { > +#ifdef CONFIG_XEN_SHSTK > + /* > + * This points _at_ the corresponding shadow stack frame; it is _not_ the > + * outer context's SSP. That, if the outer context has CET-SS enabled, > + * is stored in the top slot of the pointed to shadow stack. > + */ > + uint64_t entry_ssp; > +#endif This needs to say "only valid for interrupt Ring0" or so.  Even as written using the ssp= parameter, there will be a non-zero value here on some Ring3 entries. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:22:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:22:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452546.1667378 (Exim 4.92) (envelope-from ) id 1xHldS-0000Co-To; Fri, 16 Oct 2026 17:22:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452546.1667378; Fri, 16 Oct 2026 17: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 1xHldS-0000Ch-RB; Fri, 16 Oct 2026 17:22:26 +0000 Received: by outflank-mailman (input) for mailman id 1452546; Fri, 16 Oct 2026 17:22:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHldR-0000Ca-TP for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:22:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHldR-00Bv2A-95 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:22:25 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25d11-bab6-0a2a0a5309dd-0a2a4507e2be-48 for ; Fri, 16 Oct 2026 19:22:25 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad25d4f-b4ea-0a2a45070019-4a68bc04ca29-3 for ; Fri, 16 Oct 2026 19:22:24 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69GHMDWV012705 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 16 Oct 2026 13:22:18 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69GHMCOr012704; Fri, 16 Oct 2026 10:22:12 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: Fri, 16 Oct 2026 10:22:12 -0700 From: Elliott Mitchell To: chunjie.zhu@citrix.com Cc: anthony.perard@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH 3/3] tools/xl: move some logic needed only once earlier in Message-ID: References: <92156ced183670bbbcb2d3f9e2dca4d12f37ee7c.1792017144.git.ehem+xen@m5p.com> <20261016050721.251856-1-chunjie.zhu@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261016050721.251856-1-chunjie.zhu@citrix.com> X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-ef75cf/1792171345-A7ED6AE4-01232B43/0/0 X-purgate-type: clean X-purgate-size: 3547 On Fri, Oct 16, 2026 at 01:07:21PM +0800, chunjie.zhu@citrix.com wrote: > On Mon, Oct 12, 2026 at 06:03:49 PM, Elliott Mitchell wrote: > > > The value of dom_info->console_autoconnect isn't going to change if a > > domain is rebooted. Nor does this logic need the lock to be held. As > > such moving this earlier makes sense. > > > > The policy domain is set once and then never changed. Similar to above > > simply move before the reboot start point. > > > > Signed-off-by: Elliott Mitchell > > --- > > tools/xl/xl_vmcontrol.c | 32 +++++++++++++++----------------- > > 1 file changed, 15 insertions(+), 17 deletions(-) > > > > diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c > > index 76c2a07ee8..ae7985122f 100644 > > --- a/tools/xl/xl_vmcontrol.c > > +++ b/tools/xl/xl_vmcontrol.c > > @@ -717,7 +717,8 @@ int create_domain(struct domain_create *dom_info) > > int restore_fd = -1; > > int restore_fd_to_close = -1; > > int send_back_fd = -1; > > - const libxl_asyncprogress_how *autoconnect_console_how; > > + const libxl_asyncprogress_how *autoconnect_console_how = NULL; > > + libxl_asyncprogress_how autoconnect_console_how_buf; > > int notify_pipe[2] = { -1, -1 }; > > struct save_file_header hdr; > > uint32_t domid_soft_reset = INVALID_DOMID; > > @@ -921,6 +922,19 @@ int create_domain(struct domain_create *dom_info) > > if (dryrun_only) > > goto out; > > > > + if (dom_info->console_autoconnect) { > > + if (libxl_pipe(ctx, notify_pipe)) { > > + ret = ERROR_FAIL; > > + goto error_out; > > + } > > It looks like a functional regression for the reboot path. Right before > "goto start;" on the guest-reboot path there is: > > /* > * Do not attempt to reconnect if we come round again due to a > * guest reboot -- the stdin/out will be disconnected by then. > */ > dom_info->console_autoconnect = 0; > > On reboot, dom_info->console_autoconnect is cleared before "goto start", > but autoconnect_console_how now stays non-NULL, since it is no longer > recomputed after "start:". The second create call will invoke > autoconnect_console with the already-closed notify_pipe[1], and the > read(notify_pipe[0]) will fail with EBADF. Yeah, I spotted this before you sent the message, but didn't get things done before you'd sent the message. It gets worse. I'm pretty sure the patch is mostly correct, but this needed to be propogated further. The one and only consequence of the above hunk is to cause the `autoconnect_console_how = 0;` line to trigger. In turn the one and only consequence of that setting is `libxl_domain_soft_reset()` gets passed 0/NULL as its final argument. The `libxl_domain_soft_reset()` call is only done on domain reboots. Worse, `libxl_domain_soft_reset()` is *always* done on domain reboots. I've got the patch in my tree with the hunk you noticed removed and the call to `libxl_domain_soft_reset()` hard-coding the final argument as NULL. The only question is whether the comment should be preserved just before the `libxl_domain_soft_reset()` call. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 From xen-devel-bounces@lists.xenproject.org Fri Oct 16 17:34:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 17:34:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452562.1667388 (Exim 4.92) (envelope-from ) id 1xHlog-0003QJ-QW; Fri, 16 Oct 2026 17:34:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452562.1667388; Fri, 16 Oct 2026 17: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 1xHlog-0003QC-Nb; Fri, 16 Oct 2026 17:34:02 +0000 Received: by outflank-mailman (input) for mailman id 1452562; Fri, 16 Oct 2026 17:34:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHlof-0003Q6-E2 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 17:34:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHloe-003cvn-R1 for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 19:34:00 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad25ff4-e002-0a2a0a5209dd-0a2a4507adba-38 for ; Fri, 16 Oct 2026 19:34:00 +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 6ad26007-b4ea-0a2a45070019-285dc3385a3b-3 for ; Fri, 16 Oct 2026 19:34:00 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV8PR03MB7520.namprd03.prod.outlook.com (2603:10b6:408:181::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.17; Fri, 16 Oct 2026 17:33: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.0522.013; Fri, 16 Oct 2026 17:33: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=r112mYbh+/j5fwSXl8TwmywFZML6ZHXzag0ByBYG7mooRaGrfzGJW9yk/gqR8rejYWZZHIOLg2fb4B340SPVvofxSTJgITU2g2xjJx7UDFZWJ3g4GlTePY5sCA//6VPw97S7gixK8AO8zMJkgTlpYzkyI1GHZ0xXqq9Q55Qc1saO/cqG1gFT2LhkRyb4VOmOlU2Fm2cD8XPmSfp9yMRSvUoRdEaRowONHpe0VXCYJ+gqVI1BNfqBixJaw7GCY4dArhRuIPcW7EeJrDmoLC1ZZxfr1YbqP89//8wAm9jNvqUwrtanjViv6DI/7IfuhUxXdc48o15mSpDCgVjCz9DgEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rUWSZyyV/7AZ/A3H73Zg7KOcT+PeMae5CmlIKSugTtA=; b=rr06AYojrKfkSoVUSjqXQHhcZb/mMaL/yvJNbusR/CirqY5a6GIDDlBLZePRiHu6DlPkAAp3qfxc0nwhPaCOmDfZO5BZFV9SM4lElbwGO+GJ2HNfJ12YOUYezmNMFm5KXKjeNbFfzHxjdxJBE5R9DnU8EMLwooQmy7rnpZekRRMvgCfgQvvov4KMM/W8eYV+KR6oq4qnNkdX8A1yYm058ZGGaJ9x2YfZvFK1YQmiY/k7qOll1Hg1IZhVfX9ooZ6VSQz+UuLxYazSqniMFvOYwayQruHWs3DdEyiAWQBIq1wd3++rGF+PC/KVV2uwvwf7Op52cztHZYrDWDnXeMCtpQ== 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=rUWSZyyV/7AZ/A3H73Zg7KOcT+PeMae5CmlIKSugTtA=; b=Vkws04JmG92BuyTYgq87kbWX+LZM0S6P+ikq8DktuR4733CbDLXuGl1n3Fg9ZX3ACUdBWNE4TUBwPWSVZpAQGgFExApnlhn+VfcPNI+1em+VYOV/NGDFh+sI1sAgeumstaWUIUlYqU1pgWzty7vu3px0vtP6cX5hPs6+6RcChhU= 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, 16 Oct 2026 18:33:53 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early To: Teddy Astie , xen-devel@lists.xenproject.org References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@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: <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0108.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c3::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_|LV8PR03MB7520:EE_ X-MS-Office365-Filtering-Correlation-Id: e63bbcf2-8486-4d2d-da8c-08df2baba84b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|6133799003|18002099003|10067099003|22082099003|4143699003|261009223027099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: Y32QSNfpAcp1JaZajXGfLKqDOk2boDj1Wb//qirXbVhWmsvUesKNFfy453AL+AGU3FnLeo6+oHmcJ3cokQL7YIAXt2u4PcRjWWMZZ3VD+MRSGT0MXFXP9z7fKtNq0F2rPSVyaAk/5fV7y2144EsFM51DnP+fXcDI2O8TTW5VYJVKuiq8FvaqC89xHZalivKR2YREsl/6J+P+KxdU7gSY3hG9gMqxOJkRNazXq8HIt33/c4Nfkt37IoasRuR0yIBnSeGdRaIcTdo8AO4WfdrWc51dAjatWagLnAhCIo08P8YDpxDRhm/Nilv3ykTxmwdOjGt6nGu1GAaFs2HYDf6FtNrnLMvk4pPh3igLAhk+l7BH8nvMs+jvo6T75Y2hSqNAOoJbB1SUUCM2eIjGCE7ZIDHvFSESiHDDsvuNb+NTXDqLdzWZCdcJjZthMJ1P5TugsCiLaCqlr2iGmMkLQ/0q+7fVjtiyJ4F3GpygCFTcHuJdLscSiCBwAhux6ELwRNjUiMqf6PuG52y8NsQpKowxVU677MaJJ5BFkUXKtRwCeV6+2kB+iTCNAFeexjnpizPMgV57e01jMk6B7GKflJaz2k+W4GQ5U0q/eQvXW5kfZNKlDLVoHV2fF0mYQFtaYB9Y0LUuWkXvaeOcX5fb2naNC4uJWbq/UhJnUr9Qm+LZfwo= 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)(366016)(376014)(6133799003)(18002099003)(10067099003)(22082099003)(4143699003)(261009223027099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WTFrL2NuYjkrQU1sakFOVGhLNXJsbXdBMHIvRXVhTFR1UlZUQ2NyUjk2MVJI?= =?utf-8?B?OWdGMXBaZ3hndWswZURJV3BxaTFnaFc4VmhzVXBhZWxFQU1yclg1MnB5WGdU?= =?utf-8?B?aXJESmtTeS9SNlZKZVRSay9CN2VCME0vNXZPdUJjOGNudjRldFBnYmtvWldM?= =?utf-8?B?NGJQUnBVei82emJiS0hSM29JMkcvYWEvOFpWbEt0QUwvZ0VSSGZTNzNESitP?= =?utf-8?B?dmNWYm1zbTkwZHFUUFRBRUhKNHdRekdzclllTXdBd3JLai9nT0p3SUtRQ3c4?= =?utf-8?B?RDRGN0Q1eDR0K3NTKzdwT005ci9kL1JRdlJINzdxbzBhT0dpNjM5VUd3YlU5?= =?utf-8?B?bDRscmJiMUVkME1uZTFpZ0xsVWxoM0VJVmJheWtGdkJ5UlYzTW1RMjNCQzU1?= =?utf-8?B?SHc1azJiaWF6TUtiOEMzZWs1ZjFwWDRkc09aK2loaWJpSmRmNUZ1ZDNDMDhJ?= =?utf-8?B?SWNtNDRPSnhIVjREVlZuKzFzdnM1MTk2N0lmRm55YWJORzdwNHhOalZqMG5U?= =?utf-8?B?eC9SMXM1TUxXUnFVZDJYTHhKUUFMMnAvOFFra1RVSW9IdkN3bmtxbEp1YTBX?= =?utf-8?B?V1JHUjl3VjA3Ykh2OW1ZSHZlTHJMRmdoa01tcEQ3ZWdMZXhRQmhmRU5LNCts?= =?utf-8?B?UzR0eEQ4K21VMStJWjY5dWxuTU91NzJWeWpVQ25XVG94TTREY1RHOU93Tnl6?= =?utf-8?B?RGZJTDQ4N1ZlOE9tTDNDbndMdlR1bFdyNFZCeXU4RnFaTGQxNDJGaHNsVmZz?= =?utf-8?B?dzFob3pCbFMzRU1Na0h2TWg3cVNXMEJxeGxMQlZUTDV4WG83YnZSaFlCTjBa?= =?utf-8?B?RFlpRk5wZng1NHQ4cU0wZUdkUTl6anNkam1ySStPR3VRSjJ4UzRzTGsyemJ4?= =?utf-8?B?MGVFWUU2Y1VJMjZ3Y3pLQ0E2OWZESi81WUI4T2poYWhNOW42anMyVTJ1bTg5?= =?utf-8?B?RmJOcTh0UXBEbFBXNzAvRmdEa0hxNHFvV09vT1ltdG05VmxqQW0xSzMrUE9j?= =?utf-8?B?SGRYOEdlZFdkOGdJNzRmOFUzWTNxaVZYWklRL2dwVkZ0ekNhNVd3MU5kZnhp?= =?utf-8?B?K3REbUFWY1RYSWdwTC9Tb0U2QzFWaUxPSWsyRENBNjQ5N05IREZ6Zk9Xenpm?= =?utf-8?B?dE5XeE9IeU5hSzFlUEVrb2xIZDJWZmdHdHYraEl5SVNKYnZSK21wUDFVLzVq?= =?utf-8?B?L0FRY2NuS25PWlRDZnZkc0kxOFExUTNSd05uRUJ3M1pPaG9lWmRhR3REZWVs?= =?utf-8?B?dmZrNGdkOEMrTUtsclpJajhCSGwyNkExeVpWTW5rQ0g1RmYrcm52eGdZVDR6?= =?utf-8?B?YkswRTRIRjA2VnFHWDRCYkVncEdzVXNtTFgvQzc5Kzc2RlppUXcrRTBIdXFk?= =?utf-8?B?clU4bUF5N2tIWU5Vc1Awdm9VWGJYZGUrU0VLOC9tOVNHRFlCa0xhMXZ2VFZq?= =?utf-8?B?NmtWT2RuVDhkN21QUGJ1QTFEUWxKek9xRHVwNjN2dklsS1RSV1VtbmZ4a2FC?= =?utf-8?B?aVRGRmYwTkhCUCtaRVQxbDh0VlI2OFV4dnR2cGxYY05IZ1F4QnBWR1VtYnE4?= =?utf-8?B?MWlrbzRWOUc1b09WdXV0R3BSUVZVN0NaWnFiQzlqTWtSWnF5VC9lM25pdlRX?= =?utf-8?B?NGc4NUZuMytRSGRUNmlST2tjQ3FZaHFncmVaQUtlWTUrcktuSVBhcjZZN05R?= =?utf-8?B?Nk1UM016RENSVmVEd0N5SEREZjJ0QlB0MWxVWXJhcGowSWowYjZhKzNPdUx3?= =?utf-8?B?TFQybFRSbHVtQkpOV2pmd21GdmRtbG1tR1hCS1JhMHR3WjNZS3B0QmNLVlFr?= =?utf-8?B?TnlQVmFxVFFtNlZ0UXFZYmRIU3MzbmNIcTMxWG5RdjhxN3F1MjcvZHVJUVRX?= =?utf-8?B?R3Byb01aV3cwSm1rTW9iKzVRV3FTMHR1L3FUNVBpYkdJdnFWU0NaT3VEVlZq?= =?utf-8?B?VXRraW5sVE8ydGdVVkx5Mis2MmptRE1QMXR6aXBvUis0MXFVZGIwY1Mra1Fr?= =?utf-8?B?a0JzNVJpY1kvSk5kSUZjL0ozbE5GVFBYUC9UTENWY2lES1J4U0ZDblV3Yld4?= =?utf-8?B?UHVWVWcveXdZRG0wRk5JLzF3UFJ6dEdXM1JjY0JyV3o4SGhJdnhRTGZmNHI3?= =?utf-8?B?U29qbWVEVlNrUVJYTkQxcEMrTjB1bWxyVUp4VlROT0lkaWJmWVRTb2MvTkdn?= =?utf-8?B?R2lPdTJIKzg4K1R0R3ZHNE9OaU1EancvbDdmcWtjM0hsOGhCT1NUUHJaVGh2?= =?utf-8?B?eGlWTGt2K3FuTUxrSS9obEN0NndBM29BYm5LTlJiVUsvWkh3OXB5cWRiUlU4?= =?utf-8?B?cmErc1ZwdmxZZEJvckRWVzEvSGVzR0VoUC84c2J4S0xBUDRGUzFNOUxhVEgv?= =?utf-8?Q?m5ATrKNg+ke7QTMw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e63bbcf2-8486-4d2d-da8c-08df2baba84b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 17:33:57.4609 (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: S/b65zLiBz9FzPtAa1JNaHQ9/QKtzrHDNQfKdA4GeemMYY8LMI38cg23AvKfHZhLjUayKaSxImfwpAjdkw7W1OfMvLltBXJuV9y7S5PTlN0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7520 X-purgate-ID: tlsNG-ef75cf/1792172040-364DBAE4-D77BF862/0/0 X-purgate-type: clean X-purgate-size: 840 On 16/10/2026 6:06 pm, Teddy Astie wrote: > This is no longer required since [1]. > > At this moment of boot, per_cpu areas are not initialized, which prevents > using VCPUOP_register_runstate_phys_area as per_cpu_ptr_to_phys() would > misbehave in this case. This isn't really correct. The per-cpu area for the BSP is within the main image, which is why the logic functions today.  What's missing is the call to pcpu_setup_first_chunk() which tells per_cpu_ptr_to_phys() about where the BSP data is. I think you want to say: "A future change wants to use per_cpu_ptr_to_phys() in xen_setup_runstate_info(), but this call is too early.  It turns out to be no longer required since ..." > > [1] 8a22b9996b00 ("xen: drop xen_sched_clock in favour of using plain wallclock time") > --- Missing SoB. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 16 18:04:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 18:04:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452595.1667398 (Exim 4.92) (envelope-from ) id 1xHmIG-0001ka-7U; Fri, 16 Oct 2026 18:04:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452595.1667398; Fri, 16 Oct 2026 18:04: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 1xHmIG-0001kT-2a; Fri, 16 Oct 2026 18:04:36 +0000 Received: by outflank-mailman (input) for mailman id 1452595; Fri, 16 Oct 2026 18:04:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHmIE-0001kN-MX for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 18:04:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHmID-009HmJ-Rw for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 20:04:33 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2670f-8faa-0a2a0a5109dd-0a2a4509a25c-12 for ; Fri, 16 Oct 2026 20:04:33 +0200 Received: from [52.101.52.52] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad26730-be1a-0a2a45090019-34653434a3a1-3 for ; Fri, 16 Oct 2026 20:04:33 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5599.namprd03.prod.outlook.com (2603:10b6:a03:285::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.15; Fri, 16 Oct 2026 18:04:26 +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.0522.013; Fri, 16 Oct 2026 18:04: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=V7h6V3YKevzs/XIy4ARr/hZbUBuPFaeCUxzLL3FLrrEyMyzA+fnh6K4cvHyTlAqlk6GpUGEQ6OtMq8Dosyc3JFC1CLF6KpRx33u/jQx6zLpSsoNjJUPmmfOnzjvSHhBJxDvq6vSneYZCt7QkecGy0DAXhNoZ81hMn/DDLLJfOreJ+ngenG4nZifyT2i2mi2m2dS6Rj5EVvgHaLRZDvEc6oc/Q4L7BIFADhdLzZqel/YF2Xlg9uOfPQKLWPgGw1v4IarZU5Vindeo2cwfKuHN3vSPQs4eASVnRIw0KS+9fgHpPGzpiIhENUdk1bQGt1d7QR0KXWRwUWYBGXzKmQ+Cvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=abBtl774RqOVUqNHntvn78LSHF9CKxjQj+hKY6y6e24=; b=mwqpDv8/VC60TjNpb7GiNxN/MwK8CJZf2D0tQz89Np8rAH0QxgbPqdjvkfLqbvQZ3roz/NabOuiteYE35mDgBcBoW27puvHIu9OW+lYYLrfSf1jjiDf2aU0Er6mOcjuaXy1L5Je4Fk1f51j14N0/rKJG5+c2oNaLbuVP3IUM9kqM0UbUnNsuEj0E4HvWMm3QIe+T1gpImJCKgu/nZ3TkPUlkLAnhlC7pOUkdsxmM81NdyqreVTZgM2Stj7zoTGXCB6zNUnEHxhx0SUSrCYwKzsW39LRFaMeCSftLXfVGiVDJJaiVdfiNGQUx+27bJbi9FKNKlaqvgLPolq2l8bY+oA== 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=abBtl774RqOVUqNHntvn78LSHF9CKxjQj+hKY6y6e24=; b=oDn/aGdvOeQe+daZwa5w2NEW6buRfr6tNx1PUZgIi0Qv2OB2b/u+JrwKVQOpVONNwcfWii7VZXVI6PmSDU1Z1hzpgUmKuBirIDNJIyXIoEjbfu4y1sI5sPVMtIad8zeZOsRljwtyrw6lvL/day9H3v4rsn5VVluMJebvSGklWxk= 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, 16 Oct 2026 19:04:23 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early To: Teddy Astie , xen-devel@lists.xenproject.org References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0650.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:296::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_|SJ0PR03MB5599:EE_ X-MS-Office365-Filtering-Correlation-Id: 38ca53fb-c6e3-4196-192f-08df2bafea9c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|56012099006|4143699003|11063799006|261009223027099003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: wX5/QKQVAMxEUSxWYPA1qyhmg8GhIXaX3TPih3SUlTQxdp95MZXg3+Ds11qwSwa8RFGdD4NRnHiROXJyEB7FNLAjHH3uEAuTWgp6ffaI2zo8a9l6hnB8OxcFy8lVvZZ7HMrjHFvbQuS2g53+s/bdFjn3Qgup0HnT5dckwvQftJ6cHQdEjiDYYGjxzd1MjfUdBqOyawkRU0Pw8hmmJAzzx3taHwoYccvjmq8tMkq3suLdpHb9pm1MxJ/ixpB6MHOnGFfyEWfcgMZncMzupoS4ltdhh0z2sRhvFQIWNjZCUwj6YmUczxpLOSuccnOjrKGYn6oPx4M+bVglAc/GZvYQPetlM5lLDvl1OCV89XKlsm1vvHoRLzwaUjy3LtOW+gNjqrsMypsYdJLhIuMaWhyMy4Ad/sL/o1+bb6SbQAUJGK91BHByJFbfLuHYrmPG3R1NIpGKeBsjRw6aFF9Frd0i0sHjRWKlk1+Rtnyvp5mdhWzMvYiPfWXoj8ljT+FW0NgsU7Y05WATXHD6rI04rNIGH6hPKhLXkvKmRFMb85ZtKG3my+ZZmhGdW8D776qXNho5vYY0hgaX/Blk65c3gTwb2em8eVeuHTKm7f6fPfaa2u7nAqHhHUrlmOGjfZsdGspXzBSHT/y/JZXVtEtK0ZPcvhryC30+Vga1mdn7eRI62bU= 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)(56012099006)(4143699003)(11063799006)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vm15eUZMWk13bjJIUkk0eWc2TVp5cVJSNjJRam84YjNNckYvM1JLdm56SWdl?= =?utf-8?B?WTNvbDBvZ20rZ2FpZXRzNnc3YmRBcGFnZm93OFUwNjA3aWoyd1E3TjAxQnJY?= =?utf-8?B?bU54TUQwOFpibWNQcjBpL2ZmM0R0bENTamQrOXR2OEFtUXFDbjBlUGVJbTN1?= =?utf-8?B?T29odS9Ndjl5V3o5UW9GaU1hT2IvWlU4VDFwbjlFalI2Vi9XaGprcG9jRStz?= =?utf-8?B?c0tPc2lBekpWeWFpNUJkTTBwUlJ1dW15UmpwNThodnRYN2pBM2pNUjhHMTVx?= =?utf-8?B?MzZLOVBKWEpEbng3UVYyUXZDVnF3TVJaMzM1bFc2anV5WDdZdFZuNVcweGl5?= =?utf-8?B?dkwwY0JSRFlOUk1sNDFGNmtaQTNnbjRkUSt6ajU1TU5LZTAxdW51cS9xNEpC?= =?utf-8?B?MGpYakxLWjY1RUFKcm94eVE4SU9UMDBiRE5lRldTT2Iwc2NLM09IZXNWbW5u?= =?utf-8?B?cnBmUElzdW1reGFVRC8yckY4Qlo4d2h3czNqUWRMMFlVVkZ4Sktxbys5MmpN?= =?utf-8?B?SkhvbjhlY25NcDhSa3hpbWFTNEJ5d0lROVBoSWt6UGhDOEVwaldBMVJiVFBQ?= =?utf-8?B?d2twS2JETTkvNjh3RzAvcXNDSEVJQ0dYSkI1eWxOZFQ0QkU0dnRuRlh1SUpE?= =?utf-8?B?aUY0R05IV2E0SHhxbGd5c3FiR0dacy9KbkpRdFMwdHhiVnlVY0RPR0hBR2kr?= =?utf-8?B?K3J1Z3FMenJyYy9PWld6S3hPNmZ2MXdCT3ZaT3Ezd3BnT09FK0FsKytSbUpu?= =?utf-8?B?aGYxWVZteHF6S09kUzNPVjJ5S2NvdGRFcGIyWWs4UERxdWNFajY0OUxHaEw5?= =?utf-8?B?RGVEZUN2WEgxRE1zeXl2dkp1TU9tYmUzRHp4ZlQxekZGbGwyK0NoczJFMWF6?= =?utf-8?B?dFZHaWZmVlZZNCtPdXlXT08xWmkxbzJ5dlNoWTI2bHY0enhIc3hqL09oQ0RT?= =?utf-8?B?OFJVbUxmd3hlNzFkUG0ya2xkTDlURDYxak5hMFhiVFc1cmFRU3ZaZExQZndr?= =?utf-8?B?OHpjSmhiaDJsZjUyTkNuWGY4bDhCaU5ZWjhBS1pUVmFpMUhTRGxubEZUZitN?= =?utf-8?B?dVN6QkFMZnRKZC84NUdVN3FNZ3ZqVEExbXd4WDFmaHFQVUQ5eUxrbFViYnFu?= =?utf-8?B?azREMGg3d0Z3R1NkR0hRTlFabGFmTGNQTm1taXRVWGNwUHdRN2VJTFVsZGpi?= =?utf-8?B?dEpMZkhRcXY0bkkwZVlINXNzNjVDS3h5VkI2USs3bnMwSmFhcVU1Yk1FZHlG?= =?utf-8?B?UW1BbUJsdmRXVnJNOU1QQnUwUHdycm42c2ttOUhLYnF5MGVzbWdHdFVsOFFT?= =?utf-8?B?eVlVRVY0cE9KZytTb3RVcGlzTW5xYTFuVU1PM0JLSTJzaXE5MVJSQk5xTkJC?= =?utf-8?B?aHh0VjhjRzhSb0tEbmVVU3hGZmc0a3RVVFR6ZlFJME1VOHNsNjMwT054Tnor?= =?utf-8?B?Z2lQN2RnSDl1SHZhT3RkWnpSTGVNSmRKaDBvZDBSSVg0dld6cTlicTBzM2lH?= =?utf-8?B?WDdSTEV0VGExdllyZU9RY0trVHpFc205UUxFMHFCditrKzJZdWpiUld5N3di?= =?utf-8?B?ekpxZ1IyOUFXZXpVc2FUOVZKSXgwTjhkQ3paYVJTbUplTld4cmRZZWV6NWh5?= =?utf-8?B?VlJVbEVYN2dGVFdET2xwS0FobWhKQk12NmVOWjQxT0dTT2lVTmpQeG9rNEh4?= =?utf-8?B?dlNhaWVMUmN1ZmJjSCtGeXJqNlBTMmZpYUNlT1ptZ08rUkROejdUOSt4T0l1?= =?utf-8?B?czVXTjB5V29ZdEx4eVo5OGYwVW4xQmg2Q0xneWtjN01uRnI4cCt5NnJQYmRj?= =?utf-8?B?ckEvSEpnbWRNc1BZa2hhbTNibHV4b2ZZTFh1ejBoL1pqSnZwWEg3K3ZiUFFN?= =?utf-8?B?ZnU3VXJCSEVKZzI3RDhnSEhVSmxEZTd5NXVlSHZyck1JR3lSbHZxdWhidWRk?= =?utf-8?B?M1l1WmNRVkxFN3R6akpQQjNsVGsvczFZVUVjWElnRFRUVjhZNERrdzF0YnRW?= =?utf-8?B?eCtaWk8yREZGc2JEbThvNTl2NmpzYklRZzh4VklHRTZpMTVwRHFQK2tBaUFY?= =?utf-8?B?anh4R01RR1FpVzE3Q3p3cElwa3Vrdmg5d2hzQXd4anJvb0M1enZaSmRwQ2FD?= =?utf-8?B?QUZ1OUVSWlJtSElWampxaUFrSVlnWlB5Ylp6SWZBRjgrclI2QWNlc09QSWhK?= =?utf-8?B?Y2VXdU5YUzJINW9HaW5idHlpWXBZVVltYktwRzBsWXZqYTJ5dk5mS0hZQW5h?= =?utf-8?B?aE9VRTh6T054dk5nWGlpb3dCeDNFdER6RDdDUFkrZlh0YU1KMjFjUlBVcUdV?= =?utf-8?B?Z0hHS3I2WVdKcFdyazF1dFJLQVBYSlpobGRrcTk4cmhsSjJLYXUzaURGa1Vn?= =?utf-8?Q?UjXGihEg3PWUblfE=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 38ca53fb-c6e3-4196-192f-08df2bafea9c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 18:04:26.7196 (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: /M7nYzyOx56q4JFK18IOeZqG/phV4BVuOXRgXklnRfX7rVfLKG0GePfZ1hqH3CUb/SrYdSkjev3FocCpTQuQOjlm4PFH2WZhWTN6MedxF7Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5599 X-purgate-ID: tlsNG-bad1c0/1792173873-BD6C2034-680E6946/0/0 X-purgate-type: clean X-purgate-size: 1132 On 16/10/2026 6:33 pm, Andrew Cooper wrote: > On 16/10/2026 6:06 pm, Teddy Astie wrote: >> This is no longer required since [1]. >> >> At this moment of boot, per_cpu areas are not initialized, which prevents >> using VCPUOP_register_runstate_phys_area as per_cpu_ptr_to_phys() would >> misbehave in this case. > This isn't really correct. > > The per-cpu area for the BSP is within the main image, which is why the > logic functions today.  What's missing is the call to > pcpu_setup_first_chunk() which tells per_cpu_ptr_to_phys() about where > the BSP data is. > > I think you want to say: > > "A future change wants to use per_cpu_ptr_to_phys() in > xen_setup_runstate_info(), but this call is too early.  It turns out to > be no longer required since ..." > >> [1] 8a22b9996b00 ("xen: drop xen_sched_clock in favour of using plain wallclock time") >> --- > Missing SoB. > > ~Andrew But this does pose another question...   Linux only ever registers time referencing vCPU 0.  Why are the targets of the registration in the per-cpu area?  That's presumably wasted space on all APs. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 16 23:46:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Oct 2026 23:46:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1452718.1667407 (Exim 4.92) (envelope-from ) id 1xHrcs-00088p-3s; Fri, 16 Oct 2026 23:46:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1452718.1667407; Fri, 16 Oct 2026 23:46: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 1xHrcr-00088h-Tr; Fri, 16 Oct 2026 23:46:13 +0000 Received: by outflank-mailman (input) for mailman id 1452718; Fri, 16 Oct 2026 23:46:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xHrcq-00088b-Ls for xen-devel@lists.xenproject.org; Fri, 16 Oct 2026 23:46:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xHrcp-002KNF-Ua for xen-devel@lists.xenproject.org; Sat, 17 Oct 2026 01:46:11 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad2b72b-8faa-0a2a0a5109dd-0a2a4507cddc-8 for ; Sat, 17 Oct 2026 01:46:11 +0200 Received: from [40.107.162.91] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad2b743-b4ea-0a2a45070019-286ba25b1f6f-3 for ; Sat, 17 Oct 2026 01:46:11 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DU4PR03MB11084.eurprd03.prod.outlook.com (2603:10a6:10:5f1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Fri, 16 Oct 2026 23:46:09 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0522.013; Fri, 16 Oct 2026 23:46: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=eiB4Fovet63O+nFW2rvB9jfXf6ACGAxvs++fz7XQnuZY+59HjMiJNLFnyk+Cltug8UP3cK9W4Qg7zXX9g57iLpz5ZX9O7tKV7JkW0Tst6acCTDGHaJ8v28ZbAQ6fI/RR/jYfhcnxUgb5dXT1vQOL23vMeRvarvDiLAAGG4QeW50PwfQZ04iCa6F9h+ZQ/hu6J4o0w9ttwh9Z7pM98NPCZpSZZaOJjTBmEAsGGSs4c6P5XpG7Y4ujNTCYQrVO/NNxafIuZdR4+IOh6lTZWl+3LUrlDirdzYsfRJN/d9DKha7dvcPfS16ERi/myxHaBxGw7rV0zeUmMpJ+U607BJsF2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jTCy0pkM79qOAMYhPwHCq/VHMUiYVsH4lrrqGHveSG0=; b=Ot7tcpRDN2hbILdfnQcht89okkoosqQWm/EvoJ5YnNI3kN+edHS1tc0N50psE9cL+meTBMvCvxyIw/Xd6c2g7CVyJqshDuK3U4g7+gm53A8AN8SI2qMFZp5dymQEqKVKIgdXVp+epXGJr2tbeMXGbZT9HtlGxci1ZesjVQ2/7LfGd8eFpx6EZoNtTu0FFmJBvtgS61DlA69a7aCKPqvbbOe3An2kHD7otK1c1XyC1gCa6U+WeoEmE80OXJH6PKKwVzxKtYsVpuDI49nNS/871Tvt6XdhjTzJxX48EK7LbyLWFqW/vB03kle6d0LPkqkDg6xG2GwJkgQXrdY/h3B/QQ== 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=jTCy0pkM79qOAMYhPwHCq/VHMUiYVsH4lrrqGHveSG0=; b=YCT/lXUHXJ33yvPu/TBKp+hnqRtH9FxS+oeTWdP7ouJDOc8bT3ZjmppmX0yeJuTnuazQIwCKv1dRgMWrKDS6T/nL/qqv3Uko/3SX0QO250815J5LfYZ2REEzN3NWf0E7SG73Tzqx6978M2VIznu/Z79DNRRKwV5FYxqH26eWMSxK16cNIXTWEf5A6Zt4Mw8OBySIHkc3fg/4jSPymBxRo6KnPm0fYgMw3XX85BI4M6z0NT5j9kLkGMkByjAwzm1cdlWb1t203LIcn82/0TmywKSwV20jJ3Uy9K7JGeZZDnC/6WoQ7d/lyM4dMX4hkEIML8BQDaff0J2Vm7MoR3Y9Sg== From: Volodymyr Babchuk To: Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , 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: Fri, 16 Oct 2026 23:46:08 +0000 Message-ID: <87o6ctus3l.fsf@epam.com> References: <70484b3362f3b816bf4ed5f70c374c198a8a6eea.1787042017.git.mykyta_poturai@epam.com> <87bj9q84w5.fsf@epam.com> <6b106b71-cc16-420e-9466-91246fc06dc6@epam.com> In-Reply-To: <6b106b71-cc16-420e-9466-91246fc06dc6@epam.com> (Mykyta Poturai's message of "Thu, 8 Oct 2026 08:48:43 +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_|DU4PR03MB11084:EE_ x-ms-office365-filtering-correlation-id: 0f995c87-5d83-49d6-db01-08df2bdfa6a3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|1800799024|376014|23010399003|366016|6133799003|56012099006|22082099003|10067099003|18002099003|260925021311599003|260925021911599003|260925022911599003|38070700021|4143699003|261009223027099003|11063799006; x-microsoft-antispam-message-info: lM0fUpUKjNndao/QAzHfXRxEUy/2M1mAOHocj4wP+8P0Q0GJp1RaexNfONNGyWT6z2Tls/VwUUhB6jGySlHKa29FQWJ4b2cje+nt+jLoMzWl62rmWR1zjH6wZKElsI9gArCMSDgo3OhVfHAtqN9R86OKWZ7oMX5xyecfl9Bhw+1VjthxfpHE+aIUBy7DBudcuVkFTNlEQ0jl+hderudul4bYO4DzKV+zhYYMI3AJz7+KcceOmiqqifemlh9STCifqT6yiNwU8Q6cDxzoFiC4dDubMfu/QjTiVkrTfFiMR4YtEsuY1aZyAsckC1+avICO12/NfK6gr+IYQZl8wdhFR0vsbyVMhR5yOrg+DhxJNoO3sevlNGroAPb6hvtw20JBvT22bKXgIKgN9E7jd7JidG0jpezEhQJH3x9TnuedJjTzcaLuH1moN9ID2o8326TDuJ5MXYVED/jsA+drACgYct7MqmR8MVrbvvmrD4dzHeobkapxP2njr27MD/6DzBpXHPU+7TZCmLqjIKQoWguuOAu4L0v0x2iMdQRq6viLHl8lbtG41gB5TQubhUc9SzTWyDZVGZVEjrDgd2FrvNFTCgFSjCqNo7t+XUIbwC+PWkNypNtxVxwVRbqn/Z0PWRhM9sNXMBwqzusi7zfDyNUTLqHqxFtv3nQFtjRh3UEXZsSE3z240ua1FWKi+Yv948/RF3oWgdbDskC2BY/RvO2nzmWnbU1HonFdYMnMIFqMpQg= 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)(23010399003)(366016)(6133799003)(56012099006)(22082099003)(10067099003)(18002099003)(260925021311599003)(260925021911599003)(260925022911599003)(38070700021)(4143699003)(261009223027099003)(11063799006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U1lQNWdxOUp6c1gySysranpXb2dVWTBkbTdOeks4MHltaEJJR3RZQUtYN0t2?= =?utf-8?B?TExwWGNuTDBTVUM5azFhTFkxNUhBVkxPS2pGSWt2dlZjeUxtS1l2c2xTeG1U?= =?utf-8?B?MmdXWnNSVllNbTJNWTZ0OVlGQlZZbVJWd05WQjV3QnIzUEJvVHVVS0w1akpG?= =?utf-8?B?K3NMdEV2Y1RtM0pzVHVldEZBRHpqcXBlNzk2SGRxb0VuOG1kNHpndisxZjR0?= =?utf-8?B?M2dTb1poTGEzb1Rrb1N5SEtYRUdYZ0F3Q1FaMmNsWUFPR0lhblVJeWpKMEUx?= =?utf-8?B?VkhTTDAxbTZoOUpqVDNGZ0cyTWR5L2VnZ1l6b0t5RGpKNHFiQnV0QXNMbDdD?= =?utf-8?B?SDQ0ME5DWXYxTG9qNGxTS2xwMzA4b3F4eW0zdklFMnNNR3VXUUI0K2FPQVBa?= =?utf-8?B?Mm54OVc0WUpFNW1WRlBSNlZrSVVsRUNFR3ZrQ01nMHhDbzRuQ3Vyd0hpNEZ5?= =?utf-8?B?MU82ZmhCRUhUeTBHbVVtSDNmVVQ5T2RJUUpxczZRdmc1dCt2L28vTHFHSjBT?= =?utf-8?B?QVExb0IxME1FOXdYR3ZuMTF2SlplNzc2NkJTcTlST3RtUWVuNllNZm5QeXVv?= =?utf-8?B?RkloMzFRSGk3Z29TcG5qQ1hGSVExS1RBZExGaUk2V0N0Y0ZGeE90QmFzV2Qv?= =?utf-8?B?KzBZUXJNM3JheHp3blJSMGxOODFnS3RwcUlqUUFOZXhLRVNERmo2V2ttS1cx?= =?utf-8?B?TFZtQVpjOC9BRStML3ZpcVNtczUrMmNqRW9xMisxRE5PR3BqS2dpbjFaWkRY?= =?utf-8?B?Rmd3S0ZEamdCQ3QzZjNFZGtjQnJ2VmI4L1lwcWFkMkt1UG9PUWtwMzU5cHRN?= =?utf-8?B?MzhacWJ1YzhxU2YvS3M2ZjVFZGVkUTBrTDZJSzVseEFQaTdpWWZ4dDdGdWdx?= =?utf-8?B?bEd1WEN0MHpWeHRWaHYvaHU2YXZ2SXRybFVkVEo4YmwwZWYwUitGSlI3UWtx?= =?utf-8?B?YlRjU2U5NGhIVzNwWkJwZnZ3MVpPUDd3NmtySVdCNFZDcW1leDZ5c0FDbTBJ?= =?utf-8?B?TDdMTW00MHgydmZnT2lFd3c5K0VGbG9UYy9tNFNNZ0FxeDRUcDJmVFh6NGRR?= =?utf-8?B?OXRKMzZkcnNPWktpV3V4czY1TVlNcTRCYTMzN1FobEpRdXlzM2I0SFFFTmxh?= =?utf-8?B?YlA3cVI3L2xHK2FXUW0wMkhsSFlQU0dib1FoMGlUTDl0NjV3bnI1YkxEWVIv?= =?utf-8?B?UUR2M0h6OVRYWTV5bThvYm1TZG5mZTJqWFY2UXRaZEhUWlhaeklsZGo2QjMx?= =?utf-8?B?Qjc1UktnSndKdjdWNmlXVW43T2prQWQ2T3BOTzgydzBtMHJIRWlqQzBoWjRS?= =?utf-8?B?bDRrZ3MwWHJNZWRUaGdWK2xDdDEvbHBuY3gxQjNlcW54WDQzdlZVd29kemJQ?= =?utf-8?B?Q3QyTXdheGZ1RG9oZGlFNyt3dWZOZzY3RGtWdmFWbnpsY01tNWowcklNeFdX?= =?utf-8?B?RWJDMDJ4M3BFOWxWRVhYQXNCWFZNQXBYOFVOOG1hTGJJOHR4eXdINmNUdGhR?= =?utf-8?B?MGJrb2xMZSsxRXkxMjF5TFgxOE1lY2d6OSt2cmhGQXpoek10cU9ZcEVzS0tZ?= =?utf-8?B?ODRHckV0MGFTTzkrUU40RFIzbjBRTy9hQ2M3MHU5d2psek1jdEo1ZkJXRk42?= =?utf-8?B?UDdZZWhXNjl6dm1LSzdhUTJIUlNWZkhkSk5VKzlmbks5MG9kQ2w5QzBkUWJZ?= =?utf-8?B?WWpQTkNtd2JhQ3BOVTFWbzVHdFVySS9UVEZNS3NwaGNOMWE0cG9ZdmN6ckdY?= =?utf-8?B?Qm9zemJhdmJjT0ZsOThyaXltVmFMTkNiVE1wWUZjaVpEeUMwL3YyZFNUanBL?= =?utf-8?B?eW55QVpyNWNYcnlIVkdIN1AydzIyNlU5aU1oOGxhNGtsL1pXNWEwOTFuQnhK?= =?utf-8?B?MjlrdDFKcFI3dHdxazJOZC96dENqbnZPWk1SSlBzYm5QRjRwbjNzRWlJNXRu?= =?utf-8?B?QW81SVFMU0J5d0FOakhkMkYreUUxVDBNaEhJMms5Q2tRUUQ1V2tHTUlLUWIv?= =?utf-8?B?WmtGWGJSN0VodTNlTkwxdERyMXRmOVIwSU9mZDRpUmM5RGxwbUJkQ1Aya3dN?= =?utf-8?B?MXNJVFlMMUpjaTV2WnVTdXR6UUdqUE05MkZNa3RKbXEvM1lWazcyRFFWR1JO?= =?utf-8?B?ZVJaei9ha3laNDlxSGhUVkM4MnNVT0c5WjhmZ2o2VXBTaHVHbXZsMkFiWGF5?= =?utf-8?B?V0lKTWtTRWtxa0VBL3ZBa1JuUGVDV2Z4cUxhQTdBQndtWURZaXNXYTltREt2?= =?utf-8?B?TlZHNHRCYzYwd0JudVBFMUZBZTRWMnhXNWVUeHRiOEs4Ni92aTZhaEVOY0g5?= =?utf-8?B?SlJRb1BDZ0lUWjNjS3hFQTdhY21TZlpaUzBxZlR5VTVlWVRTaVI0WHBoL0pV?= =?utf-8?Q?NGn3ztwaGOed1d1w=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: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f995c87-5d83-49d6-db01-08df2bdfa6a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2026 23:46:08.2862 (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: 4nefjvrt6RFqxO59Eh/ZXxZ+1cq0qwuVflbGU1THqE14y5Gt1VvOtoORfltE+kd85Zq51QZKD9UlME6+vksQ5Akum7LdHeTfDKrrgGwPkJQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB11084 X-purgate-ID: tlsNG-ef75cf/1792194371-A4CCFAE4-04AF2808/0/0 X-purgate-type: clean X-purgate-size: 4772 SGkgTXlreXRhLA0KDQpNeWt5dGEgUG90dXJhaSA8TXlreXRhX1BvdHVyYWlAZXBhbS5jb20+IHdy aXRlczoNCg0KPiBPbiA5LzIyLzI2IDQ6MTMgQU0sIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0K Pj4gSGksDQo+PiANCj4+IE15a3l0YSBQb3R1cmFpIDxNeWt5dGFfUG90dXJhaUBlcGFtLmNvbT4g d3JpdGVzOg0KPj4gDQo+PiBJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zLCBwbGVhc2Ugc2Vl IGJlbG93DQo+PiANCj4+PiBTaWduZWQtb2ZmLWJ5OiBNeWt5dGEgUG90dXJhaSA8bXlreXRhX3Bv dHVyYWlAZXBhbS5jb20+DQo+Pj4gLS0tDQo+Pj4gdjgtPnY5Og0KPj4+ICogZml4IHR5cG9zDQo+ Pj4NCj4+PiB2Ny0+djg6DQo+Pj4gKiByZW1vdmUgc3VwcG9ydCBzdGF0dXMgdXBkYXRlDQo+Pj4g KiB1cGRhdGUgY29uZmlnIG9wdGlvbiBuYW1lDQo+Pj4NCj4+PiB2Ni0+djc6DQo+Pj4gKiBhZGQg dGVzdGluZyBhbmQgbGltaXRhdGlvbnMNCj4+Pg0KPj4+IHY1LT52NjoNCj4+PiAqIG5vIGNoYW5n ZXMNCj4+Pg0KPj4+IHY0LT52NToNCj4+PiAqIHMvc3VwcG9ydGVkL2ltcGxlbWVudGVkLw0KPj4+ ICogdXBkYXRlIFNVUFBPUlQubWQNCj4+Pg0KPj4+IHYzLT52NDoNCj4+PiAqIHVwZGF0ZSBjb25m aWd1cmF0aW9uIHNlY3Rpb24NCj4+Pg0KPj4+IHYyLT52MzoNCj4+PiAqIHBhdGNoIGludHJvZHVj ZWQNCj4+PiAtLS0NCj4+PiAgIGRvY3MvbWlzYy9jcHUtaG90cGx1Zy50eHQgfCA5OCArKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4+PiAgIDEgZmlsZSBjaGFuZ2VkLCA5 OCBpbnNlcnRpb25zKCspDQo+Pj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgZG9jcy9taXNjL2NwdS1o b3RwbHVnLnR4dA0KPj4+DQo+Pj4gZGlmZiAtLWdpdCBhL2RvY3MvbWlzYy9jcHUtaG90cGx1Zy50 eHQgYi9kb2NzL21pc2MvY3B1LWhvdHBsdWcudHh0DQo+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQN Cj4+PiBpbmRleCAwMDAwMDAwMDAwLi40ZjYwNjhkYjMwDQo+Pj4gLS0tIC9kZXYvbnVsbA0KPj4+ ICsrKyBiL2RvY3MvbWlzYy9jcHUtaG90cGx1Zy50eHQNCj4+PiBAQCAtMCwwICsxLDk4IEBADQo+ Pj4gK0NQVSBIb3RwbHVnDQo+Pj4gKz09PT09PT09PT09DQo+Pj4gKw0KPj4+ICtDUFUgaG90cGx1 ZyBpcyBhIGZlYXR1cmUgdGhhdCBhbGxvd3MgcENQVSBjb3JlcyB0byBiZSBhZGRlZCB0byBvciBy ZW1vdmVkIGZyb20gYQ0KPj4+ICtydW5uaW5nIHN5c3RlbSB3aXRob3V0IHJlcXVpcmluZyBhIHJl Ym9vdC4gSXQgaXMgaW1wbGVtZW50ZWQgb24geDg2IGFuZCBBcm02NA0KPj4+ICthcmNoaXRlY3R1 cmVzLg0KPj4+ICsNCj4+PiArSW1wbGVtZW50YXRpb24gRGV0YWlscw0KPj4+ICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+Pj4gKw0KPj4+ICtDUFUgaG90cGx1ZyBpcyBpbXBsZW1lbnRlZCB0aHJv dWdoIHRoZSBgWEVOX1NZU0NUTF9DUFVfSE9UUExVR18qYCBzeXNjdGwgY2FsbHMuDQo+Pj4gK1Ro ZSBzcGVjaWZpYyBjYWxscyBhcmU6DQo+Pj4gKw0KPj4+ICstIGBYRU5fU1lTQ1RMX0NQVV9IT1RQ TFVHX09OTElORWA6IEJyaW5ncyBhIHBDUFUgb25saW5lDQo+Pj4gKy0gYFhFTl9TWVNDVExfQ1BV X0hPVFBMVUdfT0ZGTElORWA6IFRha2VzIGEgcENQVSBvZmZsaW5lDQo+Pj4gKy0gYFhFTl9TWVND VExfQ1BVX0hPVFBMVUdfU01UX0VOQUJMRWA6IEVuYWJsZXMgU01UIHRocmVhZHMgKHg4NiBvbmx5 KQ0KPj4+ICstIGBYRU5fU1lTQ1RMX0NQVV9IT1RQTFVHX1NNVF9ESVNBQkxFYDogRGlzYWJsZXMg U01UIHRocmVhZHMgKHg4NiBvbmx5KQ0KPj4+ICsNCj4+PiArQWxsIGNvcmVzIGNhbiBiZSBkaXNh YmxlZCwgYXNzdW1pbmcgaGFyZHdhcmUgc3VwcG9ydCwgZXhjZXB0IGZvciB0aGUgYm9vdCBjb3Jl Lg0KPj4+ICtTeXNjdGwgY2FsbHMgYXJlIHJvdXRlZCB0byB0aGUgYm9vdCBjb3JlIGJlZm9yZSBk b2luZyBhbnkgYWN0dWFsIHVwL2Rvd24NCj4+PiArb3BlcmF0aW9ucyBvbiBvdGhlciBjb3Jlcy4N Cj4+PiArDQo+Pj4gK0lmIHRoZXJlIGFyZSBYZW4tYm91bmQgaW50ZXJydXB0cyBwaW5uZWQgdG8g dGhlIHBDUFUgYmVpbmcgb2ZmbGluZWQsIHRoZXkgd2lsbA0KPj4+ICtiZSBhdXRvbWF0aWNhbGx5 IG1pZ3JhdGVkIHRvIG90aGVyIG9ubGluZSBwQ1BVcy4gSW50ZXJydXB0cyB1c2VkIGJ5IGd1ZXN0 DQo+Pj4gK2RvbWFpbnMgYXJlIGhhbmRsZWQgYnkgdGhlIHNjaGVkdWxlciB3aGVuIGl0IHJlc2No ZWR1bGVzIHRoZSB2Q1BVcyB0byBhIG5ldywNCj4+PiArb25saW5lLCBwQ1BVLiBXaGVuIGEgcENQ VSBpcyBiZWluZyBvbmxpbmVkLCBzb21lIFhlbi1ib3VuZCBpbnRlcnJ1cHRzIHdpbGwgZ2V0DQo+ Pj4gK3JlZGlzdHJpYnV0ZWQgdG8gdGhlIG5ld2x5IG9ubGluZWQgcENQVSB0byBwcmV2ZW50IGlt YmFsYW5jZS4NCj4+PiArDQo+Pj4gK0lmIHBDUFUgYmVpbmcgb2ZmbGluZWQgaGFzIHNvbWUgdkNQ VXMgcGlubmVkIHRvIGl0LCB0aGV5IHdpbGwgYmUgYXV0b21hdGljYWxseQ0KPj4+ICt1bnBpbm5l ZCBhbmQgbWlncmF0ZWQgdG8gb3RoZXIgb25saW5lIHBDUFVzLg0KPj4+ICsNCj4+PiArTGltaXRh dGlvbnMNCj4+PiArLS0tLS0tLS0tLS0NCj4+PiArDQo+Pj4gK09uIEFybTY0IGNwdSBob3RwbHVn IGlzIGN1cnJlbnRseSBub3QgY29tcGF0aWJsZSB3aXRoIElUUywgZHVlIHRvIGFuIGlzc3VlIHdp dGgNCj4+PiArdGhlIHJlZGlzdHJpYnV0b3IgYXNzaWdubWVudC4NCj4+IA0KPj4gSW4gdGhpcyBj YXNlIHlvdSBwcm9iYWJseSB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0DQo+PiBDT05GSUdfQ1BVX09O TElORV9PRkZMSU5FIGlzIGluY29tcGF0aWJsZSB3aXRoIENPTkZJR19IQVNfSVRTDQo+PiANCj4+ PiArDQo+Pj4gK09uIEFybTY0IHRoZXJlIGNhbiBiZSBwcm9ibGVtcyB3aXRoIEZGQSBpZiBzZWN1 cmUgRlcgc3VwcG9ydHMgdGhlIG5vdGlmaWNhdGlvbg0KPj4+ICtBQkksIGFuZCB3aXRoIFRFRSwg YXMgYm90aCB1c2Ugbm9uLXN0YXRpYyBJUlEgYWN0aW9ucy4NCj4+IA0KPj4gQ291bGQgeW91IHBs ZWFzZSBlbGFib3JhdGUgb24gdGhpcz8gQUZBSUssIE9QLVRFRSBoYXMgb3duDQo+PiBjcHVfdXAv Y3B1X2Rvd24gY2FsbGJhY2tzLCBzbyBpdCBzaG91bGQga25vdyB3aGljaCBDUFVzIGFyZSBvbmxp bmUuDQo+DQo+IEl0J3MgbW9yZSBvZiBhIHByb2JsZW0gd2l0aCB0aGUgd2F5IGludGVycnVwdCBo YW5kbGVycyBhcmUgc2V0IHVwIGluIA0KPiBYZW4uIE15a29sYSBhbHJlYWR5IGhhcyBmaXhlcyBm b3IgaXQgaW4gYSBzZXBhcmF0ZSBzZXJpZXMsIGJ1dCBJJ20gbm90IA0KPiBob3cgdG8gYmVzdCBz eW5jIHVwIG91ciBlZmZvcnRzLg0KPg0KDQpBaCwgb2theSwgZ290IGl0LiBJIHRoaW5rIHRoYXQg aW4gdGhpcyBjYXNlIHlvdSBhbHNvIHdhbnQgdG8gbWFrZSBzdXJlDQp0aGF0IGJvdGggdGhlc2Ug ZmVhdHVyZXMgYXJlIG5vdCBlbmFibGVkIGluIHRoZSBzYW1lIHRpbWUuDQoNCi0tIA0KV0JSLCBW b2xvZHlteXI= From xen-devel-bounces@lists.xenproject.org Sun Oct 18 14:40:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 18 Oct 2026 14:40:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1453647.1667415 (Exim 4.92) (envelope-from ) id 1xIS3N-00016N-1l; Sun, 18 Oct 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 1453647.1667415; Sun, 18 Oct 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 1xIS3M-00016F-Sw; Sun, 18 Oct 2026 14:40:00 +0000 Received: by outflank-mailman (input) for mailman id 1453647; Sun, 18 Oct 2026 14:40:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIS3L-000169-Cp for xen-devel@lists.xenproject.org; Sun, 18 Oct 2026 14:39:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIS3K-006ZGb-FO for xen-devel@lists.xenproject.org; Sun, 18 Oct 2026 16:39:58 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad4da04-e002-0a2a0a5209dd-0a2a450ac0b4-26 for ; Sun, 18 Oct 2026 16:39:58 +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 6ad4da3d-f2d2-0a2a450a0019-b9ff1c23ae8d-3 for ; Sun, 18 Oct 2026 16:39: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 1a14f746f150008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 18 Oct 2026 14:39:53 +0000 Received: from Skynet-1 (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 1485281D23; Sun, 18 Oct 2026 16:39:52 +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=2c7MhbuinXrsyQ60cfFMuRsHi+omEwex80iZcKhchJw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=GwFOIDys81TLJi+tf6J5E+QkjbiYPIYwRpC8PpFQKLCltIKsRbiB4k+JaKSeZK6SvnJ7/XLMB QGKCYsfUsuTfMjglGif+fIQJq7cSf7TPoulDgvI0p6g70zr3HPWk8fOc0rfYbaRPWdOgJU5NALo Y+L46SdYj2T6ARHbiOQXZ0kEwfDoAm9RM+Hqz/DV9eipRgQfRkb/Bk52+eGmgQEgRxNHKmp1haN Dn6tA+zkT/bCziFTG8VwI/jIwhhH/kBD2B0Q8Px8VGzLNThiQnrACJ3Iq9i07SlT6aRBO6qkoJA QFLpsLLRToHY/L5l2MtMk2O8KW4cKWpj9YyhMxfUuDjg== X-Zone-Loop: b8ccee5780c948bc6ffb1cfad58aea3a0f3827287173 x-campaign-type: default x-transaction-id: ecc9e603-4fe6-476d-b78c-01499450b3eb x-swg-uid: 01-ec338487-10b8-4277-bf15-b2c89863f62b X-Mailer: Sweego Message-ID: <1792334393.8631fc262581453bbf619ec5b2062170.1a14f746f150008425@vates.tech> x-swg-bid: 1792334393.8631fc262581453bbf619ec5b2062170.1a14f746f150008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Juergen Gross , Jason Andryuk Subject: Re: [PATCH 3/3] tools/libxenstat: fix output initialisation in parseNetDevLine() Date: Sun, 18 Oct 2026 14:39:34 +0000 In-Reply-To: <1792151746.8631fc262581453bbf619ec5b2062170.1a14491772e0008425@vates.tech> References: <20261016091259.1254879-1-olivier.lambert@vates.tech> <1792142038.8631fc262581453bbf619ec5b2062170.1a143fd56420008425@vates.tech> <1792151746.8631fc262581453bbf619ec5b2062170.1a14491772e0008425@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.30a.c2e917628eab9432.1a14f746ba1.d4e487ca09f829ed=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792334392229 X-purgate-ID: tlsNG-4011c0/1792334398-510C9CFC-3CCF9484/0/0 X-purgate-type: clean X-purgate-size: 1165 ---=Part.30a.c2e917628eab9432.1a14f746ba1.d4e487ca09f829ed=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/10/2026 13:55, Baptiste Le Duc wrote: > The subject says "fix", but the body says no functional change=2E Either > it's a bug fix and wants a Fixes: tag, or it isn't, and then I'd use > Amends: 1fd93d4f8cb8 ("xenstat: Linux dom0 statistics for case we use > network bonding") and drop "fix" from the subject=2E Based on the change= s, I think the latter=2E Agreed, it isn't a bug fix: the only caller passes NULL for rxMcast, and the other two changes don't alter behaviour=2E All three come from 1fd93d4f8cb8, so Amends: fits=2E In v2 the subject will be "tools/libxenstat: clean up output initialisation in parseNetDevLine()", with the tag added=2E I'll wait a bit for other comments before sending it=2E Thanks for the review, Olivier -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.30a.c2e917628eab9432.1a14f746ba1.d4e487ca09f829ed=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 19 01:58:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 01:58:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1453941.1667425 (Exim 4.92) (envelope-from ) id 1xIcdm-0001Go-RH; Mon, 19 Oct 2026 01:58:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1453941.1667425; Mon, 19 Oct 2026 01: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 1xIcdm-0001Gd-LR; Mon, 19 Oct 2026 01:58:18 +0000 Received: by outflank-mailman (input) for mailman id 1453941; Mon, 19 Oct 2026 01:58:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIcdk-0001GX-0I for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 01:58:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIcdi-00Ex4U-VA for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 03:58:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5784d-8faa-0a2a0a5109dd-0a2a4505e946-40 for ; Mon, 19 Oct 2026 03:58:13 +0200 Received: from [52.101.228.120] (helo=OS0P286CU011.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad57932-4cb1-0a2a45050019-3465e4789371-3 for ; Mon, 19 Oct 2026 03:58:13 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by OS9P286MB6254.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:408::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.14; Mon, 19 Oct 2026 01:58: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.0522.017; Mon, 19 Oct 2026 01:58: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=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=ewUvIfwfaA/Bzs6eE4pQejIRl1J1W+PzhrDXPkedgE1/E8B5JWhYjYyIPq55q0EErRJyPtIW0EJXi1JkHITE3Dp1kjCFEw5V1+cckp8qQ8DAxpxqi7NG4ivr8x1Vp+iAHqf76XDkEmTJNCOq/lKkkQPGPUqca26SDOHavU3FoBnNKXhhokREcftXflv6WGKZPNVth3Gk9ayeH61gvf778AMJUnXQNW9r1nKgnrOOOowU7jKUtwrD9V9hH1Ai24gFoiyplHcZTDI5ndjzh+GKFXwtqy7mSkTYKWETIIzy6ByqeHBQExKyQlZeSuoUh6P4FfiHMogMvYwkAk7jt23P8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=agZnjvMikmQ79yhQ2WRHinwlYMDjvKES0ewjDk52J8o=; b=d82f48d0JhC7IDn1rYP4kFvFjNQPgy96+n9WP+PeEmdy9GwQYFSBPJ6NoygjIDYjNqYb5ykQdtE646nwG/BwNRZQV1vpBxlc+b1Tpav86y5Oa8wrJxVeEcIbFak6aGCNrPKnZ+Cxaa2p14XSof2sCweBAZ1xWP/uLczKSVlRJlxk9l3xmzxggzy+a4v1XMsXGXd6jz4SugT0RAuIWq1Qpuby3QgSnUABBwFBC9mEh3IG4QPZkADWGlFYbxb2du08GRjPf67CdTjAdlQ+wGc8xVL4qjoXUyXQYbEpRaYZV/OYlD4WpJuX3YSgfz5Eb5sTR9kzSRDC594UiIESs8oA7g== 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=agZnjvMikmQ79yhQ2WRHinwlYMDjvKES0ewjDk52J8o=; b=iSMz9Wmv8ciV4wvPyOuImtfABZm0MLZB3OT1/frVCIwXCmHAERZ2rnBIH+JxYlNjlOeTTqgMZa06RJ9VG9e4FxNfGMUJV3JA/XsAcHsBS479oKoYnxqR7TiUR8Aelqha6rmDPFDec71x2fobkZ6YVyEF1jjoMRbsiQTEVTS+tI8= Authentication-Results: mx.microsoft.com 1; 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, jbeulich@suse.com, Mykyta_Poturai@epam.com, Hirokazu Takahashi Subject: [PATCH v12 0/4] xen/acpi,device-tree: Introduce generic CPU topology support for ACPI and DT Date: Mon, 19 Oct 2026 10:57:45 +0900 Message-ID: <20261019015749.48492-1-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TY4P286CA0041.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:2b2::18) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|OS9P286MB6254:EE_ X-MS-Office365-Filtering-Correlation-Id: cba3786f-3f0b-41a7-2789-08df2d846b2c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|10070799003|23010399003|1800799024|366016|56012099006|261009223027099003|10067099003|18002099003|25016099003|6133799003|29003799003|3023799007; X-Microsoft-Antispam-Message-Info: x/6rceu44374btB6WH85y0MCLGdjNKfEK9LO9WE/Mh7Ee+wuhKUJmxEahi6P5z5kJ30H/1/NgKis7QKHpH0tMBuMYgoHQVljaWv0IUxlNsUsObYOI8gP5OaeEQ88OAavM8qJ0aeDrWm6p73EMxOFLSsaF3ADeOGLpYvet2LkhFi5cAYzSc4SqaMS66I+DUS7DZYKgZpgeZV8ideQxjXUd1/M0tJCvOlyHyGKzEDo0QV7RuQGKpZNV07ZHDqGWnjvaXolG7L9W78iHfcbPSducJYqWOaIdM5wLgsQAkkCL7j1gyGgYZ1CRJT2RN+T5YaD9J9P6pJlwaafE+7/rG24donITXjLX3EDufyakviGjFIj0GbSj2hJcGDIIqO+/Nt/Crm7nEnqJjuSgyIPJN4jt2aoHXJWaDWxMJR+1+j0HUrmaEhguU/mEB6v7EGK2vKomk9X3pHUGpIb4hWGHOVWY1X0eFTBYEFXWjUbXbG5RZxZodL/PcEj5H5EbB7L9xLkxNRoqv4/HYiJpHpN4E9XyTNLRGfOjIrg7+zK2o7CF5V58sGqYDfTaIbb1zZNa2kiURlnQkT7hJgLwISln3FhvpNcyTrFiuIbgZ1PKNU4GKLDy3xS62GsXamLEEQdQT8jINLN9H1jXqK2l08RKclNYA+5GiLc51WFaNyHaZDcW4I= 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)(376014)(10070799003)(23010399003)(1800799024)(366016)(56012099006)(261009223027099003)(10067099003)(18002099003)(25016099003)(6133799003)(29003799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?dJK8tmymqz7khr1Lxnebsh5ZIQyPHiT9ZRY9qw6pzezO+9BM4sdFVikriueN?= =?us-ascii?Q?eHNEF/uqL746pCiy7yn/+5xOr5VFEiTrWKkh8Y2ZN6JUguUENrbXVMkrA6Hg?= =?us-ascii?Q?z2o0/mctcY6WKX7oYGQPeTGMAFnf0sGKS0D5QS5ZyMj3RPMAJi3JHeCY2wia?= =?us-ascii?Q?Jl14bFTsv5Tei4cijCnta3Q4QfI0IPp5m0qOu0sS61F8v4O4RDAGZiI7SC+8?= =?us-ascii?Q?eNxA+2ycWTaAGDQTRJ1RsSStG3tDrgX4eFlKJsrGhz91I2OnmIUct+ee3RrD?= =?us-ascii?Q?JMOGP649QnJrFBxVmgX6xuFQ7Po8tIHj5RXdjIdxr2l+dSlZZeL6N1Ivjhn5?= =?us-ascii?Q?HVHw2JDTkLmFEJmedrisfkpeQ4eEfVHNJGN8ptqAr10QkjeIvYCLL9Yp6bc3?= =?us-ascii?Q?th8Tv0TcJ1dzNjhspFGYO9/CmtGm/FrYAAUUQh1nkKX8FALwFBhcb5gT4sBr?= =?us-ascii?Q?2frvZFi9VEju5aPDWBj9b3i49G3Y5/pTxMBeGALAzy6R5Tsbhm7h+tfdRqmS?= =?us-ascii?Q?899FbUg97WRA4gYTClKJSu3p8EAL/2J+efvM0XOxDSKfc+upucUIB7K3xoNw?= =?us-ascii?Q?3NiNO1nzVWJw9NmOzPa5bvaCJIh4p3xThgpLAHd0qBxTEIOwKU98jL5k3Lpz?= =?us-ascii?Q?E3KpmQcJz5IlP7+eokDWpXemzAdtPR5tRjs+RkhRHmuLGxpas70LrqB5YS8J?= =?us-ascii?Q?hBfgVxddT1ACJUDX/25ZkQnTLTgN/0wM4fzy9ABeintWyaqvdv3glWtJbxey?= =?us-ascii?Q?jxu14/5AEAyczmiOZvhIPlsGc6zQfGlLNE/6ft+yZf31+UoZBKPDQ6AiJI9T?= =?us-ascii?Q?ORPQJv2fRIb125Z+iYWnikMaacqpu1LfjJVglO6MX/1idoCwVnXwKS43FQBm?= =?us-ascii?Q?eWkmGcY3ji65AA5QbfYYDQScb+/RCAhjdwz7kAbcstd4GOf8sGyl8p++5kFc?= =?us-ascii?Q?1/QURpO7T68ne2TDzGPnd+O4DMDa8xCCV0kKnfRFLCjJRLRH5k4nagem6JTH?= =?us-ascii?Q?KifC9bSbWZVGa0ZhOqgLfj5iuUMKzt9PNLWtbXy2tM7CcYIf1Zabo1asrkfH?= =?us-ascii?Q?aZUeWCneGJYzUVyzBtHNyEzl4lKsBzEw7+TaeKzuHhtL1ZLKNE2zX2RPk0DN?= =?us-ascii?Q?+cs2qbatE+RnjQsWdteAbW5637+6/OT9G5ofi+1vB+WhN5bylkpGbvRNGvx6?= =?us-ascii?Q?QL+Nvr5fEubAG5FsEap2j4LnB0MJa087kYZlM7ojrNiDcjsSudub0wcUjG8n?= =?us-ascii?Q?K4OS/3W3AJq+fGwE4Rpf79UDAUzusafg1JzPDX6oyliI4Lp3yNGMDZQE4oVN?= =?us-ascii?Q?NXRFQbXKehFgmydIzUXXiDfOw4q5D+hwiuyfSg75KUEJkF2Wz3nO7pbahnwT?= =?us-ascii?Q?qJelOh+WnoPS3UPmnW/ZTg82rohyFSp2WWdo+RsZMCjUp9SOq7ljmbGtdQyK?= =?us-ascii?Q?q3jfcgdCmw/dpwjwXbPscElMRD7fosklEqVsa0AE0WAx7wypJ7Jz2NDhUeFg?= =?us-ascii?Q?K67m8QPnPU19Ib98FEPwgZ+q573koyq0HkcUemusae2IJD8xawuV8wxHpuSI?= =?us-ascii?Q?EPeRlEQoBYs/feGWq6m+rawnmEXoUmq/LBVH5OwsnWiltZ9mXseyEbFvCizR?= =?us-ascii?Q?lTU4pgKQ7bLH6MhQOddfsfnx4XYTXLHlHHtX73H1UgijtLqhCAkOxOrSjw9Z?= =?us-ascii?Q?1YF8H2+BgF2rwX+tieil3ORdN7BENWWGQrcSHowz/fsJijZ+jcfiNwRbAn2J?= =?us-ascii?Q?3MCLeNJD6PaM1d7+qslSWvX8dSVPVnFBMtqKhqtmLwbhfpem0pYP?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: cba3786f-3f0b-41a7-2789-08df2d846b2c X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 01:58:06.8459 (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: OMOVKdaEt7jap/bxk1JdL0Zbodpmj2FX863kGyQvOpnxbWRXcgGRpTYL836NZCLN2EzC8/Pbk3zEqkklxnzLGA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9P286MB6254 X-purgate-ID: tlsNG-c201ff/1792375093-F70B22A1-DDAB1B32/0/0 X-purgate-type: clean X-purgate-size: 14352 Hello, This is v12 of the ARM64 CPU topology discovery patch series. Changes in v12: - Error reporting for memory allocation failures in init_cpu_topology() into a single error path. - Emit an error message from init_cpu_topology() when dt_init_cpu_topology() or acpi_init_cpu_topology() returns an error, explicitly indicating that CPU topology initialization has failed. - Drop the Reviewed-by tag from patch 0001 due to changes in common/cpu-topology.c. - In dt_smp_init_cpus(), add a comment explaining that the boot core remains valid even if arch_cpu_init() fails. - dt_init_cpu_topology() returns -EINVAL if a leaf node lacks the cpu phandle property or if the target node is not a valid CPU node. - dt_init_cpu_topology() continues parsing subsequent threads instead of returning early when a referenced CPU is not tracked by Xen. - Update the log message when skipping an unmapped CPU to reflect that secondary CPUs have not yet been brought up at this stage. - Remove trailing periods from log messages. - Drop the Reviewed-by tag from patch 0001 due to changes in common/cpu-topology.c. Changes in v11: - When parsing the Device Tree, ignore CPU nodes if the corresponding physical CPU failed to boot, rather than treating it as an error. - Drop the dependency on UNSUPPORTED for CPU topology support. - Print an error message if memory allocation fails in init_cpu_topology(). - Fix a compilation error involving cpumask_set_cpu(). - Call map_cpu_to_dt_node() to record the CPU ID to DT node mapping only when arch_cpu_init() succeeds, or if the CPU is the boot CPU (treated as successful since the boot CPU is already up and running). - Use XENLOG_ERR as the log level for error messages emitted when DT CPU topology parsing fails. - Add ASSERT(cpu_topology) to acpi_init_cpu_topology() for consistency. - Code cleanups: * Use dt_node_name_is_equal() instead of dt_node_cmp(). * Drop redundant "ERROR:" and "WARNING:" prefixes from log messages. * Move header file includes into #ifdef / #else blocks where they are actually needed. * Adjust spacing to comply with the Xen coding style. 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 | 18 +- 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 | 73 +++++ xen/common/cpu.c | 5 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/cpu-topology.c | 435 +++++++++++++++++++++++++ xen/common/sched/credit2.c | 21 +- xen/common/sysctl.c | 1 + xen/drivers/acpi/Makefile | 1 + xen/drivers/acpi/topology.c | 343 +++++++++++++++++++ xen/include/xen/acpi.h | 17 + xen/include/xen/cpu-topology.h | 76 +++++ xen/include/xen/dt-cpu-topology.h | 35 ++ 22 files changed, 1032 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 Mon Oct 19 01:58:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 01:58:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1453942.1667433 (Exim 4.92) (envelope-from ) id 1xIcds-0001Te-W5; Mon, 19 Oct 2026 01:58:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1453942.1667433; Mon, 19 Oct 2026 01: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 1xIcds-0001TX-TI; Mon, 19 Oct 2026 01:58:24 +0000 Received: by outflank-mailman (input) for mailman id 1453942; Mon, 19 Oct 2026 01:58:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIcdr-0001TD-CW for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 01:58:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIcdq-00Ex5m-Pp for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 03:58:22 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad578fd-2eae-0a2a0a5409dd-0a2a4508d660-20 for ; Mon, 19 Oct 2026 03:58:22 +0200 Received: from [40.107.74.87] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad5793b-f659-0a2a45080019-286b4a578961-4 for ; Mon, 19 Oct 2026 03:58:21 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TY7P286MB5868.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:2aa::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 01:58:17 +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.0522.017; Mon, 19 Oct 2026 01: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=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=BohFSxLMmIPhVKTSnVGQzMYR66+aVTb1dMrD7oZz1tJgALUO/8onj/pCl+oY7vYRmVX1p5g6LimHSs38bvpqltxgX0y1Msf4zkBM293+TUpu08Z1rD/i2l5Z4S/cANGykXa6zvVr0pzK/kY15P5x9DD5Vo2bkGUwzzpInKEieWdrF5rUJw79lwZ+sL/LhpdXYsWuoGqUJiQa2i7XAkb3G33EFQT3Dy+lZtn2audl+u6S0yvK3JNBgQksmOI4rwp4QoOagGTP1BGkdC7OKUpK63qnd1DjhURF36vGzwqs/Bzi+P4PoYPY8i9jOXX3D8pxoD8Wqo07ArHupgVSdY4iKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wbLUHTCtbG54S4hRAg40hOyRncnRDqZtY0qv7P1x+pQ=; b=yUhKSeyCC4Mu1z1I+z83NZh8Fc7+eDa3QzuszISnp32DsN335WKaNqnG2rI4UAOPvd126V4yVynhMOM529piOxrsMoE57uvZmkiZ/SBS4Zat+aT1did2yUirfYupAvs4lYuIjYw9SL/l8XUNc5rOu8RuH6opspAdS6OjiH4h2taOG/71cxYD4lR/JS3BROyHGrgpbBhjoaARtKQIXAfaYLV/N3YMZSQ05DzpFi+Uk8gPCUOLqzg+CMUcpnKVQmbUlLSps97EEZdJT8gPRKu0fk6GCDu8jRPbiNnJQnZf6dPlInevs2nApRL4jbTtY/O6O62S0AbYWvXZKaKi4oj7Sw== 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=wbLUHTCtbG54S4hRAg40hOyRncnRDqZtY0qv7P1x+pQ=; b=no5W1r/AGKbJ3ErxiIxp/swJ6fbxg/7DlBNEn+kL2MrdaXlZJW7Yprm5W32Vzc46ZFip61bmJHBeBIQ0gkxRS8Qq2AI9Oy1pdzgD+yXkJq17dUIwOzb+KPjHKvA1cLab6WqrfHOjYrMhVoNTayzyZdjQHhTFT+e610OCzZXYWEw= Authentication-Results: mx.microsoft.com 1; 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, jbeulich@suse.com, Mykyta_Poturai@epam.com, Hirokazu Takahashi , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v12 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Date: Mon, 19 Oct 2026 10:57:46 +0900 Message-ID: <20261019015749.48492-2-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019015749.48492-1-taka@valinux.co.jp> References: <20261019015749.48492-1-taka@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: OS7PR01CA0131.jpnprd01.prod.outlook.com (2603:1096:604:24e::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_|TY7P286MB5868:EE_ X-MS-Office365-Filtering-Correlation-Id: c598b847-7bba-4158-5d35-08df2d84713e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|7416014|376014|1800799024|23010399003|366016|56012099006|260925021311599003|260925021911599003|260925022911599003|261009223027099003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: QjV2aNNbGx9ZPBpQaemSCa1Fcx7cf1siFAsaM/fZOaPOmZ/BY6iqh4qwJHVy1c0vjdzlycxSUnpGyGgGmUJK2Q6Orf0XsnzMF3YqCciWEFeIuMGegUTl5EIyVSuccCqFrotO7U+cV8Jvio3gRhwahDoxhiZQO7pOVKZ+8EREArnUrgQ3NSre3jpOHpD9N/SoYkV6MwM6c/U9RV7rt/j7YAtqFaQXG/aXvca2PLyu0yd46+xEBIGmsKyPZP48H+goH2z9WaS+T8Pk/9mvoqTqqO7lTScOIRpQL07Uhd9I+R+QwHYCXE1YwYztrUfzJHPopM/NkhVBo0SDST7oIWpzGiCqyPNKo+7D6vDhcBHJmOrLi9jnd7Dm4RUYZza3CcV3morkhvLTAddkkjVvjYmvr0nL+e9n+eAEL4zu4kSayKNm+1fo++R2YDllRqdjdl/OtAgIHlu3PsH1s5Vn8TXsFzHGVqgxVPftOP6Dz4/lVotjD2FfG+BjGlRAzECb6FcGt3VQyuS9N6b5SjmfPH0wRVRDnpXcPSo0zl30uzKTmiUlG13LpJRd9PckJAlInpl1bfsCuj2Az+gd+2PxgCRb0DKKiJKtMaHHbXstjeUEMpCgsOUtdzJk1y5Lt/6ypebVpE49D9ipsS/WXidSt2Rtc0kF1I1drKs+2fp0z4n6DUk= 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)(7416014)(376014)(1800799024)(23010399003)(366016)(56012099006)(260925021311599003)(260925021911599003)(260925022911599003)(261009223027099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?px7u8aGUqmSTqwmeijjbUmL6cY7FF5N28EMSc4sfqUiLr31V5yszVeq4nAAJ?= =?us-ascii?Q?SMJresBPxWDqUxNYjvjKXCHkjVo6829bbEau5l8g3bTpCTtwvrleSYK4eH6P?= =?us-ascii?Q?9zfgcOe7Tz3bzOQ6Cmua+zOUTN/fh54DsIFzK3SH9eTgUo5UhXTMR4SCQw3j?= =?us-ascii?Q?SwUrUZAfyBrIwCVBV92WcZ65lEKfU3DqtNsTkhqaQhwvXfx4e7SmOSzrnr6k?= =?us-ascii?Q?qjptX0SS4/UxwEjVBse6U9OZ8rS5uAHVnKdWyQJq/8NMseo8JwdAV5SzuAd/?= =?us-ascii?Q?G9dYdSymE2G0FEB+Djgib48gkt8r1WZz+7BN8cn8sPCDfEVJvm1XVhxYirrg?= =?us-ascii?Q?LsdWCz6NF9IGPpgiYC4FPKoBOryTaY9rQXzwpCNUwLeU6c7mg8BEECRc939u?= =?us-ascii?Q?CW4TO8UQRuEPmtFS1TjcIE9TxciLNV+LcNI5Gy48l0EqPjJJ4JIkw04+nnHs?= =?us-ascii?Q?Q5gCqzdn4AZCQ6ZYRoP0KPvsGMbFavCEHmk17TOp9pvnEeyzaHrLMROlfm2A?= =?us-ascii?Q?9KyVvEMCE263alXgWoa/vGgoEhuIP8wzDinnEQuts/uBURCsw+FlcUGj7VBl?= =?us-ascii?Q?1yGwFd5kGjaWYoSwX3OmzYsQZKB7TrQCKweyLD4NawHn9OLLNvFtLFUt0bvO?= =?us-ascii?Q?f+uy5tL8GDfYcEsUEu5khwg38m3brqnaHlpVoRcHzb36/S4myxifYAKGypuf?= =?us-ascii?Q?BcNrkeU2sIY2O//A2coRaV3wOQl3r5f4QTEQKY9uCURTeQn5xC7g+2gyem0f?= =?us-ascii?Q?51gx35EqYpyHvHUguf+qL5Nkvp6IzExUJjLsXy7C2Vp9F8bNeYvBXwZBunej?= =?us-ascii?Q?XfOB5aIJC6rP68KDeiwciPLCIGqYt2PiUWvpAOTDpZUlzsm9q+LTC24NwJD1?= =?us-ascii?Q?Sy5XsEMQX97Ilc4tTBB86HjKR+wjC82QUKm4IrDPIVDKSFCP2b9t1FQ0Q9Ht?= =?us-ascii?Q?jrsRLyIMf3ri28YFD0SBRWsH4COWZRbufFhFBVn0x0d5+GakXOcgYuP0g587?= =?us-ascii?Q?Rvfa36sHAjjEcg3Vt2nHylhBPc2jDY8Aj1411qXUuXkUq8XbuzOE5SfEeFV5?= =?us-ascii?Q?r5mqkUZafI0FGezKODezrIjKdYcaLI89hRt0cW7tZTXYnOzMrZOspS0u4aze?= =?us-ascii?Q?YYNoJt/vRnpxWozNIbhrvyl5SVVAn+tJlA8xZujesleYNMiRnH9WiKXaMY6Z?= =?us-ascii?Q?rFSRf5D6NI+TIGbd8Xlt94mLSVjw3S71xIFTF0cgFHZIpb2HHM7tYARwIz7l?= =?us-ascii?Q?jYcGdfLl0KoXonNvaOXCaJllrLnGhiW2NMo68O94tabzoi5wdJlfj+SGQAG9?= =?us-ascii?Q?lHwgdrRHC1yhYCPWhEZHbP6AUmc7+roOM9Jf48aID7JNERK+mBQWzoEtxmlU?= =?us-ascii?Q?SwvRuajYbRp8deJLuK6mWKv32dRjtxr1d759PsJc4mf51HHDFfgNwRXLcnqD?= =?us-ascii?Q?vIVl33CiHg2MAuH/xHbvEWsfr/ixIKHmLu0SNzf6JlAcfMpqMezRsYbexPWs?= =?us-ascii?Q?ljxubZfVVSqiJcywa2y+L+w2ril1BRkoOeOEpuEr4Q0GrAV5DFb2GmOI3fFA?= =?us-ascii?Q?sC+W11YtvQDbJUOrp6Fj75mRXgcUxMJy4zVkvs6KFHvMqdnAfUG8eV8sHTuZ?= =?us-ascii?Q?JXTqNWp6dssAKVyFzvwJ+j8QYcTEqTibXaMjVRqoHIA5MuOSwo367ZyFz07p?= =?us-ascii?Q?N2k7yhRUmSer4qZMvdeEafzf/GlyPiqsCjAHgLvE1Ud8zhyoD5Z5fceFZxxK?= =?us-ascii?Q?ODP/bLvbGNtMLwUibIjU29ub+w8sO8uvBlv2s6LWDJKqs6C2v2mR?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: c598b847-7bba-4158-5d35-08df2d84713e X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 01:58:17.0433 (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: YjKG9j/cM2jydhUFRI96hojL646URkgLX/AsnK2ERAzKmq5WzIDO7+AftV7esSXCbOqkurM1P2WXFhA9gnun7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY7P286MB5868 X-purgate-ID: tlsNG-c1860d/1792375102-DF8D587B-E872EE4F/0/0 X-purgate-type: clean X-purgate-size: 23664 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 --- Changes in v12: - Error reporting for memory allocation failures in init_cpu_topology() into a single error path. - Emit an error message from init_cpu_topology() when dt_init_cpu_topology() or acpi_init_cpu_topology() returns an error, explicitly indicating that CPU topology initialization has failed. - Drop the Reviewed-by tag from patch 0001 due to changes in common/cpu-topology.c. - In dt_smp_init_cpus(), add a comment explaining that the boot core remains valid even if arch_cpu_init() fails. - dt_init_cpu_topology() returns -EINVAL if a leaf node lacks the cpu phandle property or if the target node is not a valid CPU node. - dt_init_cpu_topology() continues parsing subsequent threads instead of returning early when a referenced CPU is not tracked by Xen. - Update the log message when skipping an unmapped CPU to reflect that secondary CPUs have not yet been brought up at this stage. - Remove trailing periods from log messages. - Drop the Reviewed-by tag from patch 0001 due to changes in common/cpu-topology.c. xen/arch/arm/Kconfig | 1 + xen/arch/arm/setup.c | 3 + xen/arch/arm/smpboot.c | 10 + xen/common/Kconfig | 22 ++ xen/common/Makefile | 1 + xen/common/cpu-topology.c | 73 +++++ xen/common/cpu.c | 5 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/cpu-topology.c | 370 ++++++++++++++++++++++++++ xen/drivers/acpi/Makefile | 1 + xen/drivers/acpi/topology.c | 43 +++ xen/include/xen/acpi.h | 13 + xen/include/xen/cpu-topology.h | 34 +++ xen/include/xen/dt-cpu-topology.h | 35 +++ 14 files changed, 612 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 b9c5c40678..3d0f689220 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_SHARED_INFO select HAS_STACK_PROTECTOR diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 2cd1c021b5..c1aa06bd31 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -10,6 +10,7 @@ #include #include +#include #include #include #include @@ -375,6 +376,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 8c9072f3c1..d34396f9b1 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 @@ -245,6 +247,14 @@ static void __init dt_smp_init_cpus(void) } else tmp_map[i] = hwid; + + /* + * Because the boot CPU (i == 0) is already running, treat it as valid + * even if arch_cpu_init() fails (e.g. due to a missing enable-method). + */ + if ( (rc >= 0) || (i == 0) ) + /* 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 5b289e444f..fb42f0aa8b 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 @@ -194,6 +197,25 @@ config VM_EVENT config NEEDS_LIBELF bool +config GENERIC_CPU_TOPOLOGY + bool + +config DT_CPU_TOPOLOGY + bool "Device tree based CPU topology support" + depends on HAS_GENERIC_CPU_TOPOLOGY && DEVICE_TREE_PARSE + 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" + depends on HAS_GENERIC_CPU_TOPOLOGY && ACPI + 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 f69d47d189..d0eb39a633 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..8c64532e28 --- /dev/null +++ b/xen/common/cpu-topology.c @@ -0,0 +1,73 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include +#include +#include + +static void __init free_topology_table(void) +{ + unsigned int cpu; + + if ( !cpu_topology ) + return; + + 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 = 0; + + if ( num_possible_cpus() == 1 ) + return; + + cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids); + + if ( cpu_topology ) + { + 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) ) + ret = -ENOMEM; + } + } + else + ret = -ENOMEM; + + if ( ret != 0 ) + printk(XENLOG_WARNING "CPU topology table allocation failed\n"); + else 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 ) + { + printk("Failed to initialize cpu topology (error %d)\n", ret); + 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 730d202349..b15b3382d2 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..bfcf153cc4 --- /dev/null +++ b/xen/common/device-tree/cpu-topology.c @@ -0,0 +1,370 @@ +/* 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) +{ + 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) + { + 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_name_is_equal(np, name) ) + 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 int __init get_cpu_for_node( + const struct dt_device_node *dt_node, unsigned int *cpu) +{ + const struct dt_device_node *cpu_node = + dt_parse_phandle(dt_node, "cpu", 0); + + if ( !cpu_node || !dt_device_type_is_equal(cpu_node, "cpu") ) + { + *cpu = INVALID_TOPO_ID; + return -EINVAL; + } + + *cpu = cpu_node_to_id(cpu_node); + + return 0; +} + +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; + int ret; + + 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; + ret = get_cpu_for_node(thread, &cpu); + if ( ret ) + { + printk(XENLOG_ERR + "%s: No CPU found for thread\n", dt_node_name(thread)); + return ret; + } + + if ( cpu == INVALID_TOPO_ID ) + { + /* + * Ignore this CPU node definition as the corresponding physical + * CPU failed to boot. + */ + printk(XENLOG_INFO + "%s: CPU for thread is unavailable\n", dt_node_name(thread)); + continue; + } + + if ( !is_cpu_map_empty(cpu) ) + { + printk(XENLOG_ERR + "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; + } + + ret = get_cpu_for_node(core, &cpu); + + if ( cpu != INVALID_TOPO_ID ) + { + if ( !leaf ) + { + printk(XENLOG_ERR "%s: Core has both threads and CPU\n", + dt_node_name(core)); + return -EINVAL; + } + + if ( !is_cpu_map_empty(cpu) ) + { + printk(XENLOG_ERR "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 ) + { + if ( ret ) + { + printk(XENLOG_ERR + "%s: No CPU found for leaf core\n", dt_node_name(core)); + return ret; + } + + /* + * Ignore this CPU node definition as the corresponding physical + * CPU failed to boot. + */ + printk(XENLOG_INFO + "%s: CPU for leaf core is unavailable\n", dt_node_name(core)); + } + + 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_ERR + "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 "%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(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..f9836447b2 --- /dev/null +++ b/xen/drivers/acpi/topology.c @@ -0,0 +1,43 @@ +/* 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; + + ASSERT(cpu_topology); + + /* + * 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..27b9bd443e --- /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 + +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY + +#include + +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..43f7b31bf6 --- /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 + +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 */ + +#include + +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 Mon Oct 19 08:02:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 08:02:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1453986.1667445 (Exim 4.92) (envelope-from ) id 1xIiKH-0003Z6-Bz; Mon, 19 Oct 2026 08:02:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1453986.1667445; Mon, 19 Oct 2026 08:02: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 1xIiKH-0003Yy-90; Mon, 19 Oct 2026 08:02:33 +0000 Received: by outflank-mailman (input) for mailman id 1453986; Mon, 19 Oct 2026 08:02:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIiKG-0003Ys-2s for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 08:02:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIiKE-002EVY-M3 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 10:02:30 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5ce8a-e002-0a2a0a5209dd-0a2a4504e462-42 for ; Mon, 19 Oct 2026 10:02:30 +0200 Received: from [40.107.130.81] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad5ce96-b57f-0a2a45040019-286b82513d5e-3 for ; Mon, 19 Oct 2026 10:02:30 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by PA4PR03MB7200.eurprd03.prod.outlook.com (2603:10a6:102:100::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 08:02:27 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 08:02: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=wZi9tE9eyt6Ww5mQRX/J4uSvX31VACoLOJ9NkJN+b17zDeDHxj0pXHg65q4XL1F49WkFWAi14eDJEnW1eZk3GEnVrBynHRMj85gI1aFCUdJ57/EgnEBlsAq/yr6VV9W8P23ExcoOVw7vKg3jb6jpYUG5MR0a+uI1WzCMTfBrrE5G5B4vWLK6jN8+6BQRPgZyOHpzJ+UASvv33wb3b9d0BZ8Ns/H2f/9KYCg76htn2Tfgyuj76M0D3P3+VSgjatBoDfYVB6tEQcw6XCDRQH463FM1BS14tMZMR7s4k/JcOYMSG5cfdwvOoNAPavqYIALluyFbfpQh+hc+dDqTjEkfIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=THqUcA+jSlE+cJXyOzAplOpsf2pkcu16YpV0TJNMB/w=; b=cHU7kJvdPF/2mmIJRpXw/SY0s/tFqHm49ZCCWZIRXO1UaUC2Ze/JUUWujt/gxBE5bsxPf1M2i33iH5O2mn132AVohDzSxrIMx8Y+CxoW6Fs4PBXeUgw0VAvLn6vXDEhiPxBSJOzFuLXKxfp+i9ALJL8XVs/QBDLpcXXEqucJHa9E5l+aMXWnqKQTiKfNXAa+3XZwTTBxVCCKF404LfQJd66OV3xnYnu6BmuvkfrmxPH0JFco3/jP2VpEnlUgkCYD5ns3hLrASFgGLSKyNAI3DLFUaMFtymF5L6VPH/swNwuKzjZ32+fBv65IteqHof4bauIF7JvgLMqmypGjz9b9Cw== 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=THqUcA+jSlE+cJXyOzAplOpsf2pkcu16YpV0TJNMB/w=; b=vWkbw+XrC75crQtHMnZDyicedjxZORgCs6x9Fk926B1k/rqh1Whd35hC1kNGf6tu0WELyrs6Emdr+fgbc7KyWR6DMws/Vibl8itW/4q7/MtnO4JQb4Ym2rToXmBjf8n5bigGtAU9+8SsqKnGe8ZH7kzPX4AC5BG7v3ExssjOtCiPdodFWrrDOxhJV/oOZHNxhwc9M65X7mpHkl89MqEXLYoGiMrIhrQhanmlmRJz8Vt/wFVzx5Sl/HwQgRi53HeLhD2HJ99qtgexywLWLcFmLz77c5faBRoDHBcL3gYovQfeo3Wm165TVUGe9wgg8z2eC+3M8hGBvdkzppgSw0H3QA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <1aa21183-2bc0-4bd1-8267-6df5c2f0594c@epam.com> Date: Mon, 19 Oct 2026 11:02:25 +0300 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] Eclair: scan the last xen-syms linking pass on Arm To: Jan Beulich Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <171c47db-b916-4f25-8026-16a1a99dea0c@suse.com> Content-Language: en-US From: Dmytro Prokopchuk In-Reply-To: <171c47db-b916-4f25-8026-16a1a99dea0c@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AS9PR0301CA0030.eurprd03.prod.outlook.com (2603:10a6:20b:468::30) To AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9SPR01MB0028:EE_|PA4PR03MB7200:EE_ X-MS-Office365-Filtering-Correlation-Id: b7fb8d84-f9a7-4133-ceca-08df2db750bc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|18002099003|10067099003|22082099003|4143699003|261009223027099003|5023799004|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: gqCkgJfqs3EWalS9YBzIWGz0JFloT0Wzvn2xY964S1onrBVfg8+08yzYfK5zJ0GFGbVCJ6q9UUagmHzqh0QHN4puMcaJyRFvzkVSMUfXz+c9dzOmGE89u7jE/S9Aq5dukd0DZSJzvNsqCV65U8XozkM2MoqNHrvxw4ePKcIySBYe7cgLZ7RGgBbasFiLDKGUA7WsWc2uYdjR5AZ4/e+uwBuBljuayxA3T61hPINtHLLKhgsuCfqSwGyMeSHzVVxddoNgBiDe74MqAhMSm8XXg9qzRZI9eF4/OzYoJMpjTR7F3tLF130JVHh+hLcZOuEDURMJXIxoVLCibHQwtphNrCWFEn8sdFDJTrmZajGxgvUeJq7SMBuH2DWa4jtjkZVEpexTXGqMuz1qa3y5D88Jq8aOqDB7GOrla99fDbp23VXEKGYK8LOVlacjP239gilr03qGMohNOAvZXoq5PNxaE4La1yVWqpCmix0wvYiAL3iZtNk9mJ7Hf4fn79tvupx5ejk1HAfIEZI1PA3Hkb/1m6RaAIy272tIzz2GBiH/wBtmF4aM5vwn4DPDRN1Phn15HHSEwZD8rYlnTQcDFFzNKBmdNi+mFT6dpjPMmStcx0moqEVdUxzzNjovSjJ0MnGmtHxxk9Jhp6s8sPz2OcRv5xUAIr5hfIBzmZMrCixvdW8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(18002099003)(10067099003)(22082099003)(4143699003)(261009223027099003)(5023799004)(11063799006)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M3FuZnNKSUw4aHNWTDN0cFlyYUJpeFZGWnkrTDM1TDVJR2d4Rk5DTXlTK0xi?= =?utf-8?B?aDBrcVcvQnp0ZHlJV3h2akJyZGtrdUxRUU5sNU81VkkyV21oeFhUamEzUzhy?= =?utf-8?B?Mjc0TGFjSW80Z1ZVRGVLaTN2RGpNSndlS0pJK3JSUnlzZVM1ZlFLZldDZHdZ?= =?utf-8?B?NFlUNXNYSkZncWVqMDdPakpFYlRzdDBjNU9XVS8vRnlJWXl2U2dTeHFGZUth?= =?utf-8?B?NUVVbzYwT05GUmo1SWc5NzJHNkFxK01POTgyNmEweHE3bldmckNaMndHVTNU?= =?utf-8?B?K0o5VEFHZkVET1ZQd2QxVWpTMzE4NFl4NXNGSXlzTEwveFlXWFQySjJhbXlk?= =?utf-8?B?cERqRk1pSmpUOGIxcUtSNDBySDZwNEg0bmxpNnhHc0ZnbmdCSUVKTXRkQnUw?= =?utf-8?B?Tm1tcUQxRm1rQzNseHZNNFgzUS9XY0ZiM3BZMVl2RXltK0lla0JWaER5UXAx?= =?utf-8?B?Nzg1Z0oybHZScmsxeTdLT2JZb01zUlRDZG84SWhkbHVRUkMrTDBqaEtuUk5Z?= =?utf-8?B?YzNBejhITU91WFpqckVsTHhId2FZMzlLRGJudEtUbzgraEpwRktYUHFPemM1?= =?utf-8?B?NzFNbXBoYll2cmJQYUhlYTBnbW1FWUNDWDd0YkQ5Zy9GanNwRGdRNjRHY1JU?= =?utf-8?B?blRtNW42Yjc2T1RaUVJET3Q1MXo3WCtZZTdtUUFHdVJnam9mVENEMklvQmlE?= =?utf-8?B?ckpuWWJQT2ZOVXVlNjV1aUUrMWNrSWNuVzdGNFFWUWdxRURkMGJzdm1aWWhQ?= =?utf-8?B?SStxMzdCK2RHYUQzRVZYRzJsbkR1QkdCK09GOVdyZlVPUTBkM3o2ZzVvdjhS?= =?utf-8?B?Yk53dHNXQThIMVE5RVA2ZHFPY2hLbm01K1BQbElCWlFHL0tJQzBPOWdGdEJZ?= =?utf-8?B?Nm9pRTcvbks1RDl6UytKUGpYWjRKcWFHRSt6dHg5ZlRPcU9aVE1DTUF4bmQ5?= =?utf-8?B?VjhTQTRkU3VmcnBiOGJkYlJ0Znoydk9TMlpKRk1SUDh2YWxVVGF4cDZNb202?= =?utf-8?B?bkRiOU8wcU9jaVVTUGFTQnFaR3RHRXFuRkVOWXVQWEFNU0FWaHdGUnA3R2Nj?= =?utf-8?B?MzBiV0JzdFJZYTFtSGlDdVVEb0swa2VZenJvelhLdWN3MmxSSFR2ek5wdlAw?= =?utf-8?B?UXVtMStmcmtCWHkwb0ZBK3dqbnBPblE1QWR6bjJaVXVaTnV3bkZwKzRpbVpY?= =?utf-8?B?UzN2em1XdVlGQU5kUVhNV1JJNmJNSGlTYUVkNnRBT0F0OFg2aG1pRE9WYWx4?= =?utf-8?B?RGEvaTlPRE5NTkZGbGxQMUY4S0wwZGlIblFVcS9sSTIreU9xWWdDN2pqZE1v?= =?utf-8?B?THdXb1VEMkJZeGFBTGU3RDJFeXFlOEttSzJiYy9DTUE4SnlaRXBHWVFxTm5k?= =?utf-8?B?cXVPTGQ3Nm01S0ZSQ1owQlNEM1c3LzRTcjFkd21mcXp4WFkvVFFzY3U2Y0l2?= =?utf-8?B?czBSdFp6OVVibkZneFpWeTh1NVR0VDBhczV6cnN2Rk9JOXNjTW9hYmtmQW1D?= =?utf-8?B?NStXQWk2VytiZnVuUEVXcVljMGhKcmlXUG5wZk5nUXhpaEw4dERsMXc0ODVm?= =?utf-8?B?Nit6cTdlTjBORlZkTi9EQkl4WGNjUkRqQ2dHendjaUtLcFV4UXM4TEEweHBv?= =?utf-8?B?UUpMUDArNFFNM0tmMmw4S0p2eU9nSG5hOTVxRXF3NXhTVEtRQkZ0Qnl3c05R?= =?utf-8?B?anVoRDZkOVZZZ0R1cFdkLy83b21KUFNTWmlkMlJrMCtaYUdmeWF4ZFRGODZE?= =?utf-8?B?aCtpTWNUYnhCZHp3TkxvbFFJM1J0K1Rsd0pmUmpRSGtPSW44b2ZlVnZXWEl1?= =?utf-8?B?Um91aWQwWU03V3FBSFpTV1hobW9FUnpCRElPU3pTOEJMcHZIVUdtZC9Oa0Vr?= =?utf-8?B?VEFiTGlRcXhPNTcyNGlzaDYvK3Jsb3U0Vmw3ZWhlc0JuL1V4cFNmR1BiTUow?= =?utf-8?B?QmhZcEpIRWZ5S0FwWkNuT2lXYXVtcGNmTDcrU1Z4WGtiNzN6aVQ1OUNsaVBB?= =?utf-8?B?dnN2YVYzUjhWOUp2a1A5UnNiUjZuem5xSkFBUWpyNjZEdlV0ZXhDUmFIcVAx?= =?utf-8?B?TGJPb2I5YXdZS1NJUlBQZzJjNVJ6RXlHNGFuMHcyTkhSY3VHQzREMndjUUZr?= =?utf-8?B?WFpNK0txOHdKTzVNeWJRVFdXeWtoY0hYYWwxdTZtTUJOMmhjUThJSTZNdlpa?= =?utf-8?B?Szh2TlNGZDlsZXY4MU44TklaSkhleUtpTm9mZG1IV2xvbW5RS3kzOFlPMnhv?= =?utf-8?B?Yk0waDFhMXp4bENweEdvUU1zbjRJNi9YWDYxM1hEaVZITG4rdTdIQ08xcGMx?= =?utf-8?B?RlZQSTREZldzbmMraEU0QjEwM3BENEY5UTh0N2FQUkhtVTRsN25MS29TaS9B?= =?utf-8?Q?FINlfGQKeK0f2zN4=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7fb8d84-f9a7-4133-ceca-08df2db750bc X-MS-Exchange-CrossTenant-AuthSource: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 08:02:26.8535 (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: qRla/xYK1saHnTWiHnOfyLqsE8xnYhUbx04tNLkjLlShGRZUwgABAfUJdEaswCvVRpNCQHlVFrKpJGtfW4vVynWFvBn2KGMs/0fhJLywbZU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7200 X-purgate-ID: tlsNG-ebf023/1792396950-C3AC0B50-18CC7395/0/0 X-purgate-type: clean X-purgate-size: 2156 On 10/13/26 11:14, Jan Beulich wrote: > On 13.10.2026 10:02, Dmytro Prokopchuk1 wrote: >> On 10/13/26 10:52, Jan Beulich wrote: >>> On 12.10.2026 22:49, Dmytro Prokopchuk1 wrote: >>>> --- /dev/null >>>> +++ b/automation/eclair_analysis/ECLAIR/generate-xen-syms-passes.sh >>> >>> You neatly use dashes in the new file's name here. Is there a reason ... >>> >>>> @@ -0,0 +1,20 @@ >>>> +#!/bin/bash >>>> + >>>> +# Hide every xen-syms linking pass except LAST_LINKING_PASS. >>>> +# The pass list is the foreach in xen/scripts/Makefile.link. >>>> + >>>> +set -e >>>> + >>>> +cd "$(dirname "$0")" >>>> +arch=$(echo "${XEN_TARGET_ARCH}" | sed -e 's/x86.*/x86/' -e 's/arm.*/arm/') >>>> +last=$(sed -n 's/^LAST_LINKING_PASS *:= *\([0-9]\).*/\1/p' \ >>>> + "../../../xen/arch/${arch}/Makefile" | head -n 1) >>>> +passes=$(sed -n 's/.*foreach n,\([0-9 ]*\).*/\1/p' \ >>>> + ../../../xen/scripts/Makefile.link | head -n 1) >>>> +test -n "${last}" >>>> +test -n "${passes}" >>>> +hidden=$(printf '%s' "${passes}" | tr -d " ${last}") >>>> + >>>> +printf '%s\n' \ >>>> + "-file_tag+={xen_syms_tmp, \"^xen/\\\\.xen-syms\\\\.[${hidden}]\$\"}" \ >>>> + >xen_syms_passes.ecl >>> >>> ... underscores are used here? >> >> The generated file follows the other .ecl names (e.g. >> linker_symbols.ecl). The script name follows generate-linker-symbols.sh, >> which also uses dashes and writes an .ecl file with underscores. > > That's not very nice, but otoh not as problematic to warrant an immediate > change. At the same time here your use of underscores is not only a style > issue (where bad pre-existing instances should never be used as an excuse), > but also weakens the connection to xen-syms: The underscore used could in > principle be a surrogate for about any non-alnum character, including e.g. > a dot. > > Jan I agree the underscores make the link to xen-syms less obvious. Since you don't see it as blocking, I'd prefer to leave the names as they are for consistency with the existing files. If you'd like to rename it (e.g. xen-syms-passes.ecl), I can do that in a follow-up. BR, Dmytro From xen-devel-bounces@lists.xenproject.org Mon Oct 19 08:09:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 08:09:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1453993.1667455 (Exim 4.92) (envelope-from ) id 1xIiQg-0004Ah-07; Mon, 19 Oct 2026 08:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1453993.1667455; Mon, 19 Oct 2026 08: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 1xIiQf-0004Aa-Tc; Mon, 19 Oct 2026 08:09:09 +0000 Received: by outflank-mailman (input) for mailman id 1453993; Mon, 19 Oct 2026 08:09:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIiQe-0004AU-Ic for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 08:09:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIiQd-000Y3j-K8 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 10:09:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5d016-2eae-0a2a0a5409dd-0a2a450a81e0-24 for ; Mon, 19 Oct 2026 10:09:07 +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 6ad5d021-f2d2-0a2a450a0019-aa0a817c6aab-3 for ; Mon, 19 Oct 2026 10:09: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-65-F_NLUpEMNv-XFrasoz7gyw-1; Mon, 19 Oct 2026 08:09:03 +0000 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 90A5B1955DAB; Mon, 19 Oct 2026 08:08:54 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9A2781800642; Mon, 19 Oct 2026 08:08:50 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id DC3D421E6A04; Mon, 19 Oct 2026 10:08:47 +0200 (CEST) Resent-To: 17746591750@163.com, graf@amazon.com, FangSheng.Huang@amd.com, michael.roth@amd.com, jamin_lin@aspeedtech.com, kane_chen@aspeedtech.com, steven_lee@aspeedtech.com, andrew@codeconstruct.com.au, palmer@dabbelt.com, foss@defmacro.it, sebastian.huber@embedded-brains.de, jiaxun.yang@flygoat.com, lizhijian@fujitsu.com, edgar.iglesias@gmail.com, jasowangio@gmail.com, leetroy@gmail.com, liwei1518@gmail.com, npiggin@gmail.com, zhangckid@gmail.com, titusr@google.com, wuhaotsh@google.com, arei.gonglei@huawei.com, berto@igalia.com, zhao1.liu@intel.com, its@irrelevant.dk, joel@jms.id.au, clg@kaod.org, conor@kernel.org, david@kernel.org, jic23@kernel.org, kbusch@kernel.org, sstabellini@kernel.org, peter.maydell@linaro.org, richard.henderson@linaro.org, lixianglai@loongson.cn, zhiwei_liu@linux.alibaba.com, maobibo@loongson.cn, zhenwei.pi@linux.dev, qemu-arm@nongnu.org, adityag@linux.ibm.com, qemu-block@nongnu.org, amachhiw@linux.ibm.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, kfting@nuvoton.com, den@openvz.org, daniel.barboza@oss.qualcomm.com, philmd@oss.qualcomm.com, pierrick.bouvier@oss.qualcomm.com, chao.liu@processmission.com, sam@rfc1149.net, kvm@vger.kernel.org, linux-cxl@vger.kernel.org, alistair.francis@wdc.com, anthony@xenproject.org, borntraeger@linux.ibm.com, brueckner@linux.ibm.com, farman@linux.ibm.com, harshpb@linux.ibm.com, iii@linux.ibm.com, jjherne@linux.ibm.com, milesg@linux.ibm.com, mjrosato@linux.ibm.com, pasic@linux.ibm.com, rathc@linux.ibm.com, xen-devel@lists.xenproject.org, luc@lmichel.fr Resent-From: Markus Armbruster Resent-Date: Mon, 19 Oct 2026 10:08:47 +0200 Resent-Message-ID: <87v76y159s.fsf@pond.sub.org> X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-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:Resent-To:Resent-From:Resent-Message-ID:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792397345; 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:resent-to: resent-from:resent-message-id:in-reply-to:in-reply-to: references:references; bh=ZapaecIeMcbF8m3IzNayfIxAgM/GC5btRJ9Thst8mm4=; b=W/gjaCuR2NYg+raTTNbjHh55j1jRCanrGEBJ8t6EsE5ydA+VLV+VZEbbTatoNmeHBv2hNj TWAHP21IKRk47ZKSPSbF5tN6Uf563Cg5yusHaBJUs1Azf4uDPhbPSg9g114YhYaloIRm9s 7gnOmDbI0rlKICV9vFH7oIxf3SPzv/c= X-MC-Unique: F_NLUpEMNv-XFrasoz7gyw-1 X-Mimecast-MFC-AGG-ID: F_NLUpEMNv-XFrasoz7gyw_1792397338 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Michael Roth , Pierrick Bouvier , Philippe =?utf-8?Q?Mathieu-Daud?= =?utf-8?Q?=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 , 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 , 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 Subject: Re: [PATCH v5 35/62] qom: convert scalar properties to QAPI-aware registration In-Reply-To: <20260911-qom-qapi-v5-35-7732a55b7760@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Fri, 11 Sep 2026 20:35:09 +0400") References: <20260911-qom-qapi-v5-0-7732a55b7760@redhat.com> <20260911-qom-qapi-v5-35-7732a55b7760@redhat.com> Date: Mon, 19 Oct 2026 09:41:59 +0200 Message-ID: <87jyne2l2w.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Lines: 46 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OEBf1xfxTIX4kYDZKg7X_Fu27dAcXbyfqGrBW-JeCms_1792397338 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1792397346-593C4CFC-A20E2AF9/0/0 X-purgate-type: clean X-purgate-size: 1675 Marc-Andr=C3=A9 Lureau writes: > Reviewed-by: Amit Machhiwal > Signed-off-by: Marc-Andr=C3=A9 Lureau [...] > 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"); > =20 > - object_class_property_add(oc, "highmem-mmio-size", "size", > + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_i= nfo, > 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 si= ze " > "for PCI MMIO"); > =20 > - object_class_property_add(oc, "virtio-mmio-transports", "uint8", > + object_class_property_add_qapi(oc, "virtio-mmio-transports", &uint8_= type_info, scripts/checkpatch.pl gripes WARNING: line over 80 characters Easy enough to avoid. Many more below. > virt_get_virtio_transports, > virt_set_virtio_transports, > NULL, NULL); [...] From xen-devel-bounces@lists.xenproject.org Mon Oct 19 08:51:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 08:51:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454001.1667465 (Exim 4.92) (envelope-from ) id 1xIj5M-00026S-V1; Mon, 19 Oct 2026 08:51:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454001.1667465; Mon, 19 Oct 2026 08: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 1xIj5M-00026L-Rh; Mon, 19 Oct 2026 08:51:12 +0000 Received: by outflank-mailman (input) for mailman id 1454001; Mon, 19 Oct 2026 08:51:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIj5M-00026F-DP for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 08:51:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIj5L-002RQL-JD for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 10:51:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5d9e9-8faa-0a2a0a5109dd-0a2a4501ab78-48 for ; Mon, 19 Oct 2026 10:51:11 +0200 Received: from [52.101.84.131] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad5d9ff-5984-0a2a45010019-34655483f7ba-3 for ; Mon, 19 Oct 2026 10:51:11 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by MA9PR03MB772455.eurprd03.prod.outlook.com (2603:10a6:250:10f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 08:51:09 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 08:51: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=yuGo0YU/tcHSyA1+s957B/hAsO0vGfeRl/adiiMrorPyFnoGMSEaakqDO8ZI6pZ9J19UjfKRAG5gGBglv7zjGRw6lGtZMxIEi/N9oelmf/vDs9VJRDysio4DuiNzwyjIRaJCVy7GlWqm9FGhYIGKZrA+mNP3kveSvGIoIZ5XQutSyDpJpmHKjVikCQQBRqYjMsW0XcB9UoICFLIOYjAeNKQte8iGbXXUnJZdgOITLngOLKv9IWstkYoPkKUPBPBe0Be6LELqoB4NuivSc9hD+2IiuAyEPOLLwGRy3bzaVN9srtJemCcgyGazo8pkzDdkkB308gqQ8cAOr43PTyJxtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Au1W/bV9kIxJexDLUZli5znRmIy8HsNAjkfS8aFPemk=; b=eKV20Xv5+rKlnQuewuiuNbWfUMhwCXsIanS/sqR4O1poKH8e+56Lclo99OZS5FXI+7Jm8mOA6P50Yzwo1fivi/cWjZEtJ+yw11Y+5CM0wcRJlJHg9guINBoqwLSfxSbTLRxem0MBUKOjGOjSYDYgHxg8CmTQaK3wG7bnEJxoR1bO52c2lxebGhhYDwTavxwE+TxdJpjeYIgkVy2Freo9QAiQPCI8Arr6JDJY/eYzL4rkmJ6DTOO/LSTkDw12Ln68coTp/5c6mU0RLlqscEdOdA0l5qBE7KOPOkJTfejxZERVt8ChJaBEBwlLjbvRllwbA/CS/VJyh4iEBEX4wKt0Ug== 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=Au1W/bV9kIxJexDLUZli5znRmIy8HsNAjkfS8aFPemk=; b=eXOxp4VWUCz0385KQ+/am913dN2gn99W/7ulDGyBwAzSPMZuqfGmyIkysiT9rovC5qIkmB+x5LDbQIxdihIAEtqKBJ1DJ2MXvFPBBZa/iXcMyt1k3LAMunaYhUY7u0BlXkgxxkVvITz4rTKOftQzjTUIvfDw/HcNd4DJBlbhucC/go6RJdhjxz6dKBaU995/lmn3DypnUTkAY3/adObBCM+ZBWJivtR6+RDXbuwXBHjtFNuoiRLyWqjzTmVLOSMniJz3rZzUxOK5CAPAFSQV/G9Og/w+yFS7diLHgSMxNP0pmo7X0xO9L1a0R3PPIrl36fZ9ttGggdijLqx+vzRKKw== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: [PATCH v3] automation/eclair: generalize the noreturn function-pointer deviation Thread-Topic: [PATCH v3] automation/eclair: generalize the noreturn function-pointer deviation Thread-Index: AQHdX6b80imhcnqS7U2zknLLHn+kXg== Date: Mon, 19 Oct 2026 08:51:09 +0000 Message-ID: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|MA9PR03MB772455:EE_ x-ms-office365-filtering-correlation-id: 396f3e49-a90a-4d55-aabc-08df2dbe1ec4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|7416014|42112799006|38070700021|56012099006|11063799006|261009223027099003|10067099003|18002099003|3023799007; x-microsoft-antispam-message-info: CKTjBLThNb4rd52vVUPww2/p/S59oXwYVFt1xVUdqnWa/bHTlzg62v2nQ3zLC8bb+uozZgM94nJvSDErT8k97XX7XYXzq4geQIU3/qUPFwcpQRkMaOtQkkBejbiQukEca7bYLKbjDntGC79aQ6HIFa1ISAREAoiUh1EV0zpmxNjCFKn+xHTJMVqUhcYcDDGMIaFI1XVIEbJuodqbWL8i9ipuMTF4MvXUe8XlAl4v/+ecUD5DxhlSwXGeMso4g+Ztk41OPbPhBzJOPZkKsCyBBeK/GTr8tQF+lVZ8+jweFCUuaEcwlkhZO8SnOwpJxPWsaDrFjakqyaCwHQ8zH0uuQvBVPYerS94B1pCHUozHec3M9rJfAzQg+h/epr2UBfmMguNhKvqxDIYAlMfVmrII2ejZ8ZfGjsDohHc4rIMzPwXysR3q6AHy6kD0rUiUWUAY4cv7JpEbuwVIuRor2/VDQ9NKWBxHK0GSE4W/ww26HRhNOeMrxcTygLrWhHknN5d0U+1NlpkU7okXb8x8oYbMV031tsYV1vo+ZHT/YpcpBOlyTcA2foL0CZQIrNf9GK1C9yjEH+up++ueoI7cMom/y6MRvzAkMjMwJMyVHy6XYe431Jd3eCeJB0ieKLcTPLc1aiTw4UKK+L2l4jIdEqEDiMYmPaprRj4+uslX9Vk2IhIav05wuSH8Dlq0Ss6C7ppj/l9J8tSMnl/xfFRPKliC7WBExPF8xJKTmrdRAn/kDio= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(7416014)(42112799006)(38070700021)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?rEh0WsI5epBPp+OchmEhQF9TZ1+eRofHxGapqvuGqve4N71BFdY92kvQuN?= =?iso-8859-1?Q?ydfezsEw76Bdsxhr1AmhkOJm1MsTq1OedQ6jmJMgIm9gk73RLIGcX7zVbf?= =?iso-8859-1?Q?u3R5dBlTyMhK9ahCuONkYVIQuP6z0PSLbQ3J7kTdC8vtz0eXm/06ldku0Z?= =?iso-8859-1?Q?tIBLdafXp/4Tr4yHkvfjdaMQxH2k3KB0ThlxqkQJuajX9rw5/GezLXnlnq?= =?iso-8859-1?Q?qd2iaC7AAon0ySIkgaCqRv/Xo3PDvGF9KtrW7Y9pr4UEJFRf9BeKs8vBY6?= =?iso-8859-1?Q?7NoEajtMnFjTuWKLSGHYSNjpWysQbRuP3jOZ/jYEM+7OsvjQqtOr7l3kH4?= =?iso-8859-1?Q?Zyi9uut+chIc0nqaVBWceoCdi/0EhRI5aFH0JPJuNcZzYgKoOWMfG/qJvW?= =?iso-8859-1?Q?ok1phKjM5pWUS7IOXwKRPnVRPfsONyLnCdSf8fYKsel/5oQW0jRpaLhiqs?= =?iso-8859-1?Q?ZAdJVjMvLCp5BcF3NIJsRuySnJiiu869xWVhOZcDfCbous5c6HTStSOXYm?= =?iso-8859-1?Q?tPCxOgLHlWES5JJI7snJgywINOGD9873tKzjcbwcNYMBusKs23dFXV6OS2?= =?iso-8859-1?Q?LeYyYsQvM42KBJcB1+ArGZYFOcW+d0F9++VHwtnQa8nNYzztxAy+fMknuC?= =?iso-8859-1?Q?S9DRzHQ+yoTvPREJAcPkf1bcFNNhiiUON4a7NDhhHJmQSOGIAjDvSDndbc?= =?iso-8859-1?Q?RLGVnPbFfyQT0AoLPMtMMcp6LSLG19Z5+HRUZ220UF5AdLsXU0UoD/leQi?= =?iso-8859-1?Q?sI5OiNOVBzhdcD5tG7E91igl6BpX65fJep/p10aYPD+Vi2G7IIAv1FBWhb?= =?iso-8859-1?Q?ljht8F+wKA4pjiriS+KHMQ7sOPgmVjdzsjSe7lI2XYAaum683zSPn4SFfn?= =?iso-8859-1?Q?dce6RJFU6wah+FldHvFzRAZ6h3ZXhpa/8pxfSmh9tr4rux1FcLguzjAXDH?= =?iso-8859-1?Q?KTZW/pQTDo5QACmklYqSV7q0eAPyoPehNIJgELcTCgorA/qjD5+xIgVzAi?= =?iso-8859-1?Q?egJN5IwEOJWolTbu8NZYPcGbrTQFQub+yIGYDR7hqt7hbRMWCPk6y1IZfD?= =?iso-8859-1?Q?epcU8I67XDjlRMLTx2Q5cEvc88NVd4lvvtGhseh9i0w/KuCWkEsQXsVWwp?= =?iso-8859-1?Q?OYqjliRfUWFWS4mNZsdx2/qi0pSmfegM1Ub6awrmO5+e555iuHU9EfNj3r?= =?iso-8859-1?Q?FedommhGhEjNulXDTF4n9K8YKm8bTxAWGXIdXPcgdMcQKvjbIP6Z0KibVl?= =?iso-8859-1?Q?HEeKLDakU43bK7Pm9m/5rpRrrX2vRSfuJEYUlaOTaehxAimlOyXA1RI8Px?= =?iso-8859-1?Q?KJBag/PAmeezo3aQvovJ+CY0aophtV0aBcB6F5o6xkW2UNyNWC8gWgu3fC?= =?iso-8859-1?Q?q97vTM2hSKWkNvPOrl4QHPTSOENH0O5dQhIfpbmuohraF/6bdvRTlnBF23?= =?iso-8859-1?Q?q2scL1oj0GMrZL/pd23i++YW6j6Yejgb4XUyTnOR9Slz/eN7EhdYWaS6du?= =?iso-8859-1?Q?wrI6iaRTEZzkoJo2FHklCLikdxy27fvUFf2q1wTjp9QfAJa1+17qOK7gwN?= =?iso-8859-1?Q?IEgoWwa7pi99QiOgaN+TCN3i0mzbPRsYD0jdMKkEd9PWJ3I8js4km3XYQ2?= =?iso-8859-1?Q?bX7GQs1rT0VLT6PxSCZtVKQ0/qBe3YRbeqOk0adtYHguQuKMoS9E5y2tOs?= =?iso-8859-1?Q?VAIj0xfERObbpzVHBk2wn3Ui7znpuUnr71glItq4O5RYsdj//1EW2Oa/Ld?= =?iso-8859-1?Q?DlMYhMyJEGYrtKT41VB0/dJFXa7sMQuPeFpqGc0pDLT/eZouXz2JaVBn5C?= =?iso-8859-1?Q?JaC+aL0ITnh/1DUYLdUFr20MxpBcIq8=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 396f3e49-a90a-4d55-aabc-08df2dbe1ec4 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2026 08:51:09.2555 (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: Dw4tdkoCv+29YXr7G4iHYVEiVx3mGMXtLX2BkNho63k9K3tHXqV9QWHtABqlV0/V3k70G9djm74Mwy7p1xMSiX2D+7KgYcPQ+u2F6DFidTc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA9PR03MB772455 X-purgate-ID: tlsNG-d62444/1792399871-BE27A757-15DCACE2/0/0 X-purgate-type: clean X-purgate-size: 4926 The R11.1 safe cast only matched void noreturn (*)(void *). Accept a conversion where noreturn is omitted and the signature is otherwise compatible. canonical() covers typeof destinations, and compatible_deep_unqualified keeps the parameter and return types aligned. Discarding noreturn does not change the calling convention. Code after the call is unreachable when every possible callee is noreturn. Leaving that code in place is a tolerated Rule 2.1 violation. The full rationale is in docs/misra/deviations.rst. Signed-off-by: Dmytro Prokopchuk --- Changes in v3: - Reworded the deviation text per Jan's review: "noreturn omitted but an otherwise compatible signature", "all of the possible callees", and a tolerated Rule 2.1 violation - rules.rst: use '(void *)' spelling Changes in v2: - do not claim that discarding noreturn leaves compiler behavior unchanged - write that code after the call is unreachable, and that Xen's behavior is the same (whether the compiler deletes that code or leaves it) --- automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +++++---- docs/misra/deviations.rst | 12 ++++++++---- docs/misra/rules.rst | 8 +++++--- 3 files changed, 18 insertions(+), 11 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/= eclair_analysis/ECLAIR/deviations.ecl index 6cdb10a129..c7a800c62f 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -394,11 +394,12 @@ constant expressions are required.\"" } -doc_end =20 --doc_begin=3D"The conversion from 'void noreturn (*)(void *)' to 'void (*)= (void *)' is safe -because the semantics of the 'noreturn' attribute do not alter the calling= convention or behavior of the resulting code." +-doc_begin=3D"The conversion from a noreturn function pointer to a functio= n +pointer with noreturn omitted but an otherwise compatible signature does +not alter the calling convention." -config=3DMC3A2.R11.1,casts+=3D{safe, - "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1= , pointer(builtin(void)))))))&&from(expr(skip(!syntactic(), - ref(property(noreturn)))))"}=20 + "kind(bitcast)&&to(type(canonical(__function_pointer_types)))&&from(expr= (skip(!syntactic(), + ref(property(noreturn)))))&&relation(compatible_deep_unqualified)"} -doc_end =20 -doc_begin=3D"The conversion from a pointer to an incomplete type to unsig= ned long does not lose any information, provided that the target type has e= nough bits to store it." diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 6bcc2adf95..76be6b3251 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -392,10 +392,14 @@ Deviations related to MISRA C:2012 Rules: - Tagged as `safe` for ECLAIR. =20 * - R11.1 - - 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, parameters handling r= emain - consistent. + - The conversion from a noreturn function pointer to a function point= er + with noreturn omitted but an otherwise compatible signature does no= t + alter the calling convention. The callee does not return, so code + following a call through the resulting pointer is unreachable. The + compiler may delete that unreachable code when it can see that all + of the possible callees are noreturn, or it may leave the code in + place. Xen's behavior is the same in either case. Code left in plac= e + is a tolerated violation of Rule 2.1. - Tagged as `safe` for ECLAIR. =20 * - R11.2 diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index a59cf1782e..5f9fe4c860 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -435,9 +435,11 @@ maintainers if you want to suggest a change. and any other type - 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. + and '(void *)' are permitted. Conversions from a noreturn function + pointer to a function pointer with noreturn omitted but an otherwis= e + compatible signature are permitted. + Conversions from [unsigned] long or '(void *)' to a function pointe= r + are permitted. Example:: =20 unsigned long func_addr =3D (unsigned long)&some_function; --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 08:59:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 08:59:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454008.1667472 (Exim 4.92) (envelope-from ) id 1xIjDL-0002px-PK; Mon, 19 Oct 2026 08:59:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454008.1667472; Mon, 19 Oct 2026 08:59: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 1xIjDL-0002pq-Mg; Mon, 19 Oct 2026 08:59:27 +0000 Received: by outflank-mailman (input) for mailman id 1454008; Mon, 19 Oct 2026 08:59:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIjDL-0002pk-12 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 08:59:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIjDK-00Aw5B-Dm for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 10:59:26 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5dbdd-bab6-0a2a0a5309dd-0a2a4504d906-46 for ; Mon, 19 Oct 2026 10:59:26 +0200 Received: from [52.101.69.87] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad5dbee-b57f-0a2a45040019-3465455754ea-3 for ; Mon, 19 Oct 2026 10:59:26 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by BESPR03MB911498.eurprd03.prod.outlook.com (2603:10a6:b10:109::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 08:59:23 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 08:59: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=DrMzcHifj+1+vbgJsrbo5ksbtEA4K4D5pSH4G7NNegBQ1eUuYekV0oiF6sMuOo8PgNi5ZkHgq9whLcS35Q/FrJE9cyP41PNqhqMPsWxb3oN0ZBqZyilwaekrdiB8v5MoIIkidmhNMB8bch99jXhQKmzla2cCT4wfhbHAg2HxDh7OV7kLourN2tE4EYzvN26UV+nz/xIYw05dOAdx9bvX2TITr7aiNzMsZU0M1zcWnIBNaRXPyF93aAQLxSJ8mvLohwdA4j8pP8eC6Q1p3vHHsJewcShKCgWIrIBNLijbcUR6fgFIGBTdIpUtTkyO8i0U/dWDG6FOhUwgs7vIjAKpYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sH4kTxF+BQMlIy/y9w/d+JkjyjOKGLMjkmkpX/++0R4=; b=B7qYRbACh9UnK81kHdgvMcZ2VPJkUbz/0wtx1ah0VuKQra0AnCVjxf/5JAjO6OANc55fTUMLpEmZcyrdq41z2CPXmIoTFLFJN4IoDo/ORzX8/9e4gRNrXxH4lLq1EyP4t/bz52rDcNj76MLYyGtbmJ5X5Y0IV67TjtgU2fD3swQngu2LAYjCeFKUp2X4Kmmi32EWVQhxYKqzOi72iOpXJc7HEEzxBD6UNBe0wb7majUG0TxYXrKYGRrUEa1CFFiEU2yCAy1tkUzRfr/JM5C5QCiuEtRfVxPEKx9qvPRp/bCOdVEe08AetDMwo8h0lXL4GHemsRKMLjGPUPr4mb3qgA== 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=sH4kTxF+BQMlIy/y9w/d+JkjyjOKGLMjkmkpX/++0R4=; b=g9VO9QMOkJeb0IYkVEi/CoaJdRyr/N7DhWcJWNEZ3RqSwHnYQDIJbY6CQ97UaLWHOkV+asvcn+ewzE+snLxm01TODnk3izPRb6lsgo0K6WjfwVAlHoLpipPE3Sts1rxhZxHArpdJQMBo4EdszltHyYaODwFQNnYJMS9okYmKWkDALjSvarjG0UA3B8LguqEg74s2Y9lwfHXmwNao3oVz7eULKfstOgdNV9Eo+MmjZnojIHRZjljo3kmc7uidwWAbMHQMyo47+D7mpmExWeVhzN7qEqWn6IGtxDZrSfCDpTmEgSov/cNN9qUFGQAKm1t3iHRqb1tgNWuVMzQwExdnOw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh Subject: [PATCH v5] xen/arm: smmuv3: Add support for removing devices Thread-Topic: [PATCH v5] xen/arm: smmuv3: Add support for removing devices Thread-Index: AQHdX6gi8viU2M73vEaKXA5NzGRTmQ== Date: Mon, 19 Oct 2026 08:59:23 +0000 Message-ID: <5bf81a2b31f182d1339e89fb65e445bc20b1a865.1792400044.git.mykyta_poturai@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: PAVPR03MB10102:EE_|BESPR03MB911498:EE_ x-ms-office365-filtering-correlation-id: 8ecbdcfa-f17f-4e5c-4aef-08df2dbf4541 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|38070700021|56012099006|260925021911599003|260925022911599003|11063799006|261009223027099003|260925021311599003|10067099003|18002099003|6133799003; x-microsoft-antispam-message-info: BNHJhPAzGAG7USU8y1b7/Hg8uj3mUp+UQtsi/SqQG/9VGALwm1SVnSe3R5mUR1XXaaYsN5uE0OgW9NtVJ4Nd+F9ZAPtLOMBxSt5zsu4HW4dL5kqwAHpYDsaeE7+GblY63UnXLOtnIdMYpKU/QD38uNA00fEqMWHz7OlrEnLBz6EqkXMd6drux8SQcFg4mzz5eJm8I83+srYfrcZHZGCatv8ftj0Ld7FxhlvxuAlxsKneNC1CiPRVgyuSrVh7Xd7n40z+UTlK3iM6U1l9lJOHltRVf6aQFFox+mCEyHtxsuN++rkentwBgx+PGwFPvmZoDGW/aZeIrQtud7KNjm9INlQxrMvwNHTMbTEqnkPNofSO5rYD8j0yUdTmM1/TZo7LWJgvu0Y1Jvt+7x70tRgN8vLDwZYS6NN0NkasjfRnqEkmhA2jvIHRriDmdrcZChrCJMfujDequzPnTLAE4BxI3iMInqt4Fxk6HAX7UwRN2yvY1O96OO6lt/elKQv0ePNfxRuIjg7LQRGO7XBDKZ+K5QsFjJL2aSB3xIZa21Bgf7s/4GAS6418zAJQlpwd4wktDcpVMK8TweecGflZhsCa9LjUYxbR/zjvdQV4i+dkk36B8XaH8mowHF8+R9Ak4X76XhER6vRH8NXpTUeZG7b83XQ9K8mccOkKPf8WK1dJ9oc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(38070700021)(56012099006)(260925021911599003)(260925022911599003)(11063799006)(261009223027099003)(260925021311599003)(10067099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?SFtcWMPcUgHq7/7o04ADry/NnF1aK6uXCVa9Z7hPWJnMI+y0+zGCJI6v23?= =?iso-8859-1?Q?rRL5DOAaSnqiW96Xfc2AZ0K64nWUau0rIZC4tcwdqCeyIdQt9nCX+JF1fi?= =?iso-8859-1?Q?Xeub4eyB/YO8VA8patxu/DmRAbugyot2tarGGic03eo+uTjw7lAoBfvQO1?= =?iso-8859-1?Q?oWs8XZCX3DgxPleOq/GbyxLmGjjblZ0xGdUWyjNrimY5AXZv2Lmf1BjWs1?= =?iso-8859-1?Q?aH4ILvluq6gGOcmGDh/4UMfPM+imCo6H+NmB0ZBbCF+sEJVUSi0ZT2UBxK?= =?iso-8859-1?Q?XluiHCrgYpCpSoXOY5f2ImcnWPy+PLSXEBNAhQTR5TS/TXEPazHyLxgoZZ?= =?iso-8859-1?Q?oZfSNtNRMSgpbiqAHJOvUQFZ1+8VW5XUgm+YdDNDvBFWmnxijD2B3PEmSc?= =?iso-8859-1?Q?6hGTSH4JZcyB2bMKRJED6sXWggWrrsPIlU1xo9W54HXVgu5iciKj/LA5d2?= =?iso-8859-1?Q?5XWa51yLYQWX3vd+ai3ZwD88dyTodu0PO5ZUqCaOzvSvTX6GiTB1OxVu/p?= =?iso-8859-1?Q?Wi8FaJ++BEmlc2Hvr6AjjgWx+aqUX74FyCtZ5FvZffhiAQKiiltzMj2FKd?= =?iso-8859-1?Q?e6WsYHVLGUOXJbUQhFPiDn3AxdKfkp0VwGd6Cw5t+/nZSqujNB1i2pqDA7?= =?iso-8859-1?Q?rQDPmkWnHr5raTPyy4enx4XsYAbXvWlA0Qm6dJH59oPGOZb4q2j1nTIf7Z?= =?iso-8859-1?Q?hSa33NILKXsGHwofUvjFtzS05c8ePiDYKwpEQrRnV2TA2VkcpFYzeGLy2h?= =?iso-8859-1?Q?BBS0OIXVXmfAHSvO8dRZTm20CHOB4E5CXyFPV4RXpRp63u7lmYQJYzIk7C?= =?iso-8859-1?Q?cCEGJWyish9EnizrttXSDjaD2dX9LI8z9aNETBp12JyHKaQ3M5+GIXSTtt?= =?iso-8859-1?Q?19qnc2ytwNdQxxo0Uf6ACJlY1+h6L5HsoyaMl9l5zcZW3qRtAuexZNGyw3?= =?iso-8859-1?Q?elWI7eMJnABWP6YSNcNROVk6oaGurhnqAzIh59uOezRDIh0wIdUm1eYtGq?= =?iso-8859-1?Q?kVgjKIEEWxpmtWZk+E6hLjDVFxmamekgTjwPnqB5SehiiQs7YfYoVF58wX?= =?iso-8859-1?Q?E/1fXkDl6FfltKHpQQaq39VJJGm2gSbtqKKoqJw3B2l1clkllQBmEUoWXM?= =?iso-8859-1?Q?a0LwtPO/C2tDgIxd940kIYVQkRiU6iEPbUIzl0OiiB+WhfreuU0UHSG9Yn?= =?iso-8859-1?Q?8gHk5PuT90Eli+NdKhiaSsk6cyOtALNHPfAaDrnDWJKOkyj3Ft6ckE+Bay?= =?iso-8859-1?Q?qc2aElYjYn8ziKXFKkR6QvfmP8S/UzH2eLg5oXk5QgA21+jkeADR6WvoBu?= =?iso-8859-1?Q?w8fdJFdEuaVssFN8gJlaLigTYsiJj1NSrISI/NcrYpOZ/Wu+65/kQeuvFh?= =?iso-8859-1?Q?JzKX1A3Lf7vHhIMgkxuDdoNFtKAgltAfVV+us6FAcUgRABH/WBJbKbuFPY?= =?iso-8859-1?Q?aJAoziquipEtuylvSIOTyARNfVV9XdCn0pHdrEFa66kJa7gbLXnesIK7mt?= =?iso-8859-1?Q?w6Zu30WEJ31xFww4KNbaLVRp8A4Vulw2pZQwglMhV/n3cNeo8NMqQbQ2i2?= =?iso-8859-1?Q?2oJbtNiPqEejBSqh076osbUL40Hz8mJcVigqMUFqEer6nGljAVRnRsEJnk?= =?iso-8859-1?Q?HY68XFViqUe8p6iuK6wQBH0It4dsWgUBcvv/FB9qqsBoBr7yeC6nbg160J?= =?iso-8859-1?Q?Fs7PvNJNCkIhClfuAm/xSmlj2VSzFpXZawBu364SsesLWhP+rRY5T5BMc1?= =?iso-8859-1?Q?FtIqGtm3BarUnatDI8CAQ+08jHA8PT9Pg7zlTn3V6q2TCHxsbjPd0Oh3v3?= =?iso-8859-1?Q?89/pgI63ng=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ecbdcfa-f17f-4e5c-4aef-08df2dbf4541 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2026 08:59:23.3451 (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: cKKDDiD33PCxtxLZHU0vKj8qMkf0YwokFsIxtGZHIB2i01rdMH1DRU5MOEQBtYEso8d1FAEbwqqTGgDoFIVavg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BESPR03MB911498 X-purgate-ID: tlsNG-ebf023/1792400366-538C1B50-84501B9C/0/0 X-purgate-type: clean X-purgate-size: 6382 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.co= m/ V4->V5: * drop dead domain lookup on the DT path * remove assert on arm_smmu_deassign_dev error * drop redundant IS_ENABLED(CONFIG_HAS_PCI) * fix indentation V3->V4: * s/u8/uint8_t/ * assert pcidevs_locked * assert deassignment is only reachable by PCI * fix build error with HAS_PCI=3Dn 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 | 72 +++++++++++++++++++++++- xen/drivers/passthrough/arm/smmu.c | 4 +- xen/include/xen/device_tree.h | 5 +- 4 files changed, 77 insertions(+), 6 deletions(-) diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthr= ough/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) } =20 /* 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/passthroug= h/arm/smmu-v3.c index bf153227db..e1af615985 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.c +++ b/xen/drivers/passthrough/arm/smmu-v3.c @@ -1493,6 +1493,75 @@ 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); =20 +static int arm_smmu_remove_device(uint8_t devfn, struct device *dev) +{ + struct arm_smmu_master *master; + struct iommu_fwspec *fwspec; + struct domain *d =3D NULL; + + fwspec =3D dev_iommu_fwspec_get(dev); + if ( !fwspec ) + return -ENODEV; + + master =3D dev_iommu_priv_get(dev); + if ( !master ) + return -ENODEV; + +#ifdef CONFIG_HAS_PCI + if ( dev_is_pci(dev) ) + { + struct pci_dev *pdev =3D dev_to_pci(dev); + + /* Ignore calls for phantom functions */ + if ( devfn !=3D pdev->devfn ) + return 0; + + ASSERT(pcidevs_locked()); + + d =3D 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 ( d ) + { + /* + * 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)); + + if ( arm_smmu_deassign_dev(d, devfn, dev) ) + dev_err(dev, "Removing anyway\n"); + } + + 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 ( dev_is_pci(dev) ) + iommu_fwspec_free(dev); + + return 0; +} + static int arm_smmu_add_device(u8 devfn, struct device *dev) { int i, ret; @@ -1571,7 +1640,7 @@ static int arm_smmu_add_device(u8 devfn, struct devic= e *dev) } =20 /* 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); } =20 dev_info(dev, "Added master device (SMMUv3 %s StreamIds %u)\n", @@ -2867,6 +2936,7 @@ static const struct iommu_ops arm_smmu_iommu_ops =3D = { .unmap_page =3D arm_iommu_unmap_page, .dt_xlate =3D arm_smmu_dt_xlate, .add_device =3D arm_smmu_add_device, + .remove_device =3D arm_smmu_remove_device, }; =20 static __init int arm_smmu_dt_init(struct dt_device_node *dev, diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/a= rm/smmu.c index d63c901551..4d2f71f152 100644 --- a/xen/drivers/passthrough/arm/smmu.c +++ b/xen/drivers/passthrough/arm/smmu.c @@ -825,7 +825,7 @@ static int arm_smmu_dt_add_device_legacy(struct arm_smm= u_device *smmu, if ( !dev_is_pci(dev) ) { /* Xen: Let Xen know that the device is protected by an SMMU */ - dt_device_set_protected(dev_node); + dt_device_set_protected(dev_node, true); } =20 for (i =3D 0; i < fwspec->num_ids; ++i) { @@ -862,7 +862,7 @@ static int arm_smmu_dt_remove_device_legacy(struct arm_= smmu_device *smmu, =20 if ( !dev_is_pci(dev) ) /* Protected by dt_host_lock and dtdevs_lock as caller holds these locks= . */ - dev_node->is_protected =3D false; + dt_device_set_protected(dev_node, false); =20 kfree(master); return 0; diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h index 06d7643622..76ae1e674a 100644 --- a/xen/include/xen/device_tree.h +++ b/xen/include/xen/device_tree.h @@ -300,9 +300,10 @@ static inline domid_t dt_device_used_by(const struct d= t_device_node *device) return device->used_by; } =20 -static inline void dt_device_set_protected(struct dt_device_node *device) +static inline void dt_device_set_protected(struct dt_device_node *device, + bool protected) { - device->is_protected =3D true; + device->is_protected =3D protected; } =20 static inline bool dt_device_is_protected(const struct dt_device_node *dev= ice) --=20 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 09:06:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 09:06:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454015.1667486 (Exim 4.92) (envelope-from ) id 1xIjKI-0004Rr-GX; Mon, 19 Oct 2026 09:06:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454015.1667486; Mon, 19 Oct 2026 09: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 1xIjKI-0004Rk-Dh; Mon, 19 Oct 2026 09:06:38 +0000 Received: by outflank-mailman (input) for mailman id 1454015; Mon, 19 Oct 2026 09:06:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIjKH-0004Re-I6 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 09:06:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIjKG-000gA7-D9 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 11:06:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5dd9b-2eae-0a2a0a5409dd-0a2a450299c8-2 for ; Mon, 19 Oct 2026 11:06:36 +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 6ad5dd9b-6ca4-0a2a45020019-b9ff1c128a67-3 for ; Mon, 19 Oct 2026 11:06: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1536999750008425.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 19 Oct 2026 09:06:31 +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 1345D80A47; Mon, 19 Oct 2026 11:06: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; 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=S9rlU3fumzPMwHOSR+1Y+kPQ1ZexeMRkIPsVGMEgYuk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=NTOulvxSiSPrStgCiQlK4aAeuJVoYrLAKYL59o8sn4gTcZvQ69cfhDrfbVrRJcoh3QLWbKs3B MgGdUWBhq/Gf2KpyRVLG+sWNc0ZTqheplKCxpB7OJX8f/3WJeZApdX9OYW6pZO1GrBxINGGwSMJ 1UVQtPd/2w8uX9aL5TfM7GZkAnXYEBraC5fXArFXRPeDiOZ0mJY1bMKkYccF5qJuNWq/RYbzT0g jQN6FWyM9D2qFZdttmfCzsjCdnovLrlQe8IPoIFh42G/9n7jtUndPcGukfYHHk1FqAniNsSPZLZ LRi2/YIio1t9qCwWMb1JgYKlwfa0OMWopR3ZyPe2VCYQ== X-Zone-Loop: 8da58021f940459d198dd400909f01bba4825d6a085c x-campaign-type: default x-transaction-id: 60070b06-a0a4-4c27-a9f2-9210e05f645a x-swg-uid: 01-a5fc6352-9387-497e-8348-b1c041fdde66 X-Mailer: Sweego Message-ID: <1792400791.8631fc262581453bbf619ec5b2062170.1a1536999750008425@vates.tech> x-swg-bid: 1792400791.8631fc262581453bbf619ec5b2062170.1a1536999750008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 19 Oct 2026 11:06:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@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="------------R0HTcQ4F0G50aXHnJOfKLM7X" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792400791261 X-purgate-ID: tlsNG-720697/1792400796-321D72AC-BE0B2258/0/0 X-purgate-type: clean X-purgate-size: 6790 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------R0HTcQ4F0G50aXHnJOfKLM7X Content-Type: multipart/mixed; boundary="------------7yW0Wscd23IA2rw5ayHl3NGg"; protected-headers="v1"; hp="clear" Message-ID: Date: Mon, 19 Oct 2026 11:06:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@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: --------------7yW0Wscd23IA2rw5ayHl3NGg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTYvMTAvMjAyNiDDoCAyMDowNCwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBP biAxNi8xMC8yMDI2IDY6MzMgcG0sIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+PiBPbiAxNi8x MC8yMDI2IDY6MDYgcG0sIFRlZGR5IEFzdGllIHdyb3RlOg0KPj4+IFRoaXMgaXMgbm8gbG9u Z2VyIHJlcXVpcmVkIHNpbmNlIFsxXS4NCj4+Pg0KPj4+IEF0IHRoaXMgbW9tZW50IG9mIGJv b3QsIHBlcl9jcHUgYXJlYXMgYXJlIG5vdCBpbml0aWFsaXplZCwgd2hpY2ggcHJldmVudHMN Cj4+PiB1c2luZyBWQ1BVT1BfcmVnaXN0ZXJfcnVuc3RhdGVfcGh5c19hcmVhIGFzIHBlcl9j cHVfcHRyX3RvX3BoeXMoKSB3b3VsZA0KPj4+IG1pc2JlaGF2ZSBpbiB0aGlzIGNhc2UuDQo+ PiBUaGlzIGlzbid0IHJlYWxseSBjb3JyZWN0Lg0KPj4NCj4+IFRoZSBwZXItY3B1IGFyZWEg Zm9yIHRoZSBCU1AgaXMgd2l0aGluIHRoZSBtYWluIGltYWdlLCB3aGljaCBpcyB3aHkgdGhl DQo+PiBsb2dpYyBmdW5jdGlvbnMgdG9kYXkuwqAgV2hhdCdzIG1pc3NpbmcgaXMgdGhlIGNh bGwgdG8NCj4+IHBjcHVfc2V0dXBfZmlyc3RfY2h1bmsoKSB3aGljaCB0ZWxscyBwZXJfY3B1 X3B0cl90b19waHlzKCkgYWJvdXQgd2hlcmUNCj4+IHRoZSBCU1AgZGF0YSBpcy4NCj4+DQo+ PiBJIHRoaW5rIHlvdSB3YW50IHRvIHNheToNCj4+DQo+PiAiQSBmdXR1cmUgY2hhbmdlIHdh bnRzIHRvIHVzZSBwZXJfY3B1X3B0cl90b19waHlzKCkgaW4NCj4+IHhlbl9zZXR1cF9ydW5z dGF0ZV9pbmZvKCksIGJ1dCB0aGlzIGNhbGwgaXMgdG9vIGVhcmx5LsKgIEl0IHR1cm5zIG91 dCB0bw0KPj4gYmUgbm8gbG9uZ2VyIHJlcXVpcmVkIHNpbmNlIC4uLiINCj4+DQo+Pj4gWzFd IDhhMjJiOTk5NmIwMCAoInhlbjogZHJvcCB4ZW5fc2NoZWRfY2xvY2sgaW4gZmF2b3VyIG9m IHVzaW5nIHBsYWluIHdhbGxjbG9jayB0aW1lIikNCj4+PiAtLS0NCj4+IE1pc3NpbmcgU29C Lg0KPj4NCj4+IH5BbmRyZXcNCj4gDQo+IEJ1dCB0aGlzIGRvZXMgcG9zZSBhbm90aGVyIHF1 ZXN0aW9uLi4uwqAgwqBMaW51eCBvbmx5IGV2ZXIgcmVnaXN0ZXJzIHRpbWUNCj4gcmVmZXJl bmNpbmcgdkNQVSAwLsKgIFdoeSBhcmUgdGhlIHRhcmdldHMgb2YgdGhlIHJlZ2lzdHJhdGlv biBpbiB0aGUNCj4gcGVyLWNwdSBhcmVhP8KgIFRoYXQncyBwcmVzdW1hYmx5IHdhc3RlZCBz cGFjZSBvbiBhbGwgQVBzLg0KPiANCg0KWWVzIGJ1dCBvbmx5IGZvciB0aGlzIGVhcmx5IFBW IGNhc2UsIHRoZXJlIGFyZSBvdGhlciBwbGFjZXMgd2hlcmUgDQp4ZW5fc2V0dXBfcnVuc3Rh dGVfaW5mbygpIGlzIGNhbGxlZCBmb3Igb3RoZXIgQVBzLg0KDQpCdXQgbG9va2luZyBhdCBp dCwgdGhlcmUgbWF5IGJlIHJlZHVuZGFudCBjYWxscyBvZiANCnhlbl9zZXR1cF9ydW5zdGF0 ZV9pbmZvKCkuDQoNCj4gfkFuZHJldw0KDQpUZWRkeQ0K --------------7yW0Wscd23IA2rw5ayHl3NGg-- --------------R0HTcQ4F0G50aXHnJOfKLM7X 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+p0QLLz9AFAmrV3ZYFAwAAAAAACgkQZg+p0QLLz9B3 KAv/VqZr1kmFNF9miMXIqBNL4H8gEOUgZ9d6YuJj9V5lkFqkFFhKFejHwSfyxc3FJWMCre3Ycwvd bThooiv++8jlpo19iQgIaZQOb1M2eXgeug+meXUkgccjx9f5S8xWKT1B4bQOzf0mV07SCyjlKmj5 EyACl7hvph8PHM0fFiPmw5OOy3EDKvgkw8YSXZMNnHMh3SZ0LRkMg/oK2DzypFlBWpPGdPVZtzFS XDEw21CutjknFF1u1JdJniELqMXmhcmua6Qx8F1GiQEJnn6eDR871vJI+nGvykLNn/9mBxQu4w+n BjzGXliVJY3Qz5YzUXnFj/aPaXyRlGRnAW5agEqelqvKquWW+0i7gM/+V7LaZPnzzpb628NOuUMI SBFmERSE0kWyCtUeExwdyUqasQOOZ7n4Teqzf0la1S1WMneZbeH2t+eZisFRrd/srtlLEAMjdKbu k/vOMEZfpGPgPxFq6r5jzm8Fzh/ohF7+emnGiQh1a9l12Do2TNlUOfhslSzy =pfB0 -----END PGP SIGNATURE----- --------------R0HTcQ4F0G50aXHnJOfKLM7X-- From xen-devel-bounces@lists.xenproject.org Mon Oct 19 09:20:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 09:20:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454023.1667499 (Exim 4.92) (envelope-from ) id 1xIjXT-0007cM-Lz; Mon, 19 Oct 2026 09:20:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454023.1667499; Mon, 19 Oct 2026 09: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 1xIjXT-0007cF-J7; Mon, 19 Oct 2026 09:20:15 +0000 Received: by outflank-mailman (input) for mailman id 1454023; Mon, 19 Oct 2026 09:20:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIjXR-0007c9-Mk for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 09:20:13 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xIjXR-00000001qOD-2JBw; Mon, 19 Oct 2026 09:20: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.98.2) (envelope-from ) id 1xIjXR-0000000AWJo-0b0K; Mon, 19 Oct 2026 09:20: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=DsMNP3oVCV+zJmeZgdlXyBn7vSmGn7A0GPS+igcZV1k=; b=sZcr+PAGzRIH73Xj9wBmFR8FFd ayo0qaaSdsGZBIDNkFrHbcalKRMuXr1j+BW81r2FqyTVb11C3O8OhzRxGAslUdg3HNMk+SXSKpL/K DHO2IFiwz//9u7K5AnrQYqnxE1eDLWycwzyWULLq4xrCDgydao0Lzk04O7RbQJpqpWCk=; Date: Mon, 19 Oct 2026 11:20:06 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Marek Marczykowski Subject: Re: [PATCH 11/15] x86/PVH: try to map initrd directly into Dom0 Message-ID: References: <1b4c2bb4-118d-497c-8d7d-f3824fd61a73@suse.com> <78cd46cc-84ed-46df-96c9-26ce97ed0da0@suse.com> <764b7c0b-1a1e-4d0a-bded-28b5e9f9e703@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <764b7c0b-1a1e-4d0a-bded-28b5e9f9e703@suse.com> On Fri, Oct 16, 2026 at 11:12:34AM +0200, Jan Beulich wrote: > On 16.10.2026 11:01, Roger Pau Monné wrote: > > On Fri, Oct 16, 2026 at 10:58:09AM +0200, Jan Beulich wrote: > >> On 15.10.2026 19:41, Roger Pau Monné wrote: > >>> On Mon, Oct 12, 2026 at 10:25:11AM +0200, Jan Beulich wrote: > >>>> @@ -867,7 +1078,7 @@ static int __init pvh_load_kernel( > >>>> } > >>>> start_info.modlist_paddr = last_addr; > >>>> start_info.nr_modules = 1; > >>>> - last_addr += sizeof(mod); > >>>> + last_addr += sizeof(*mod); > >>>> } > >>>> > >>>> start_info.magic = XEN_HVM_START_MAGIC_VALUE; > >>> > >>> Isn't this still not properly ordered, as start_info address must > >>> strictly be below 4GB (as is passed in a CPU register with the CPU in > >>> 32bit mode), yet it is allocated last in pvh_load_kernel()? > >> > >> Well. For one, this is pre-existing. With the size of the region that > >> find_memory() needs to find greatly reduced when the initrd isn't > >> included there, there's about zero chance that it won't find a suitable > >> region below 4G. Once we have find_memory() go downwards from 4G, the > >> remaining little bit of a risk will also go away. > > > > Might be worth mentioning then, so it doesn't look like an oversight > > since you adjust the ACPI allocations. No strong opinion, just > > noticed it was left behind. > > I've added mention of this, but only in the remark of the patch. Really > pvh_setup_cpus() may want to check for no truncation? Or the parameter > type may want to change to uint32_t, with the no-truncation check then > living elsewhere? I think it would indeed be best if Xen checked for truncation. Whether it's in pvh_setup_cpus() or somewhere else I don't have a strong opinion. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 09:21:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 09:21:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454027.1667507 (Exim 4.92) (envelope-from ) id 1xIjYF-00089h-1p; Mon, 19 Oct 2026 09:21:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454027.1667507; Mon, 19 Oct 2026 09:21: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 1xIjYE-00089a-VT; Mon, 19 Oct 2026 09:21:02 +0000 Received: by outflank-mailman (input) for mailman id 1454027; Mon, 19 Oct 2026 09:21:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIjYE-00089M-0V for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 09:21:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIjYD-0099zz-DH for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 11:21:01 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5e0f0-2eae-0a2a0a5409dd-0a2a450ce218-46 for ; Mon, 19 Oct 2026 11:21:01 +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 6ad5e0fd-f479-0a2a450c0019-b9ff1c22b22f-3 for ; Mon, 19 Oct 2026 11:21: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 1a15376c42b0008425.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 19 Oct 2026 09:20:54 +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 26F7182272; Mon, 19 Oct 2026 11:20: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: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=7mcOJQvRjtYGXZnA30TePasJOC/MWg9lA7dWarcXtco=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=C69geNP6QunsLf6SzkToLLcK3amuDD1lQvCyeJzab7pMYmAiiRX0ck9ngaF4dOpAY8k/drNsO oQLz5zrBbO5U1DCsdu+TvaWKTXwWAgvJHMkJpTC0mfa6D5+U+uzjOAeYrcNHD2dFYeb6eaJTRzr KJruCmKA8dmevGuuwWUTu3l+9JbGk28lTRdUQzUOI1iGjhi6DKFhECQVlakZkQ9VYnziGz96c3w czUH4Z9GEK+c9qYWC/XGi1SaRpvESc6Kz8ObYXvCTrlAJ6EswAANq7ppjQvddj/Xc5mIdwE2+Ol 8R7lbtS6ZGkU+GfEZW19EUUpLhtn2kow2ykCL31yd/Qw== X-Zone-Loop: 58708de2225ce494dca9d2ae2eca4da9bbda029755a7 x-campaign-type: default x-transaction-id: a35d3c46-2ef5-4de1-afd7-1b9208c8a490 x-swg-uid: 01-fc7e59b7-1437-48e5-9f16-67f63b6c02a5 X-Mailer: Sweego Message-ID: <1792401654.8631fc262581453bbf619ec5b2062170.1a15376c42b0008425@vates.tech> x-swg-bid: 1792401654.8631fc262581453bbf619ec5b2062170.1a15376c42b0008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 19 Oct 2026 11:20:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@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="------------LQJVOZZx3WI2pPmzX0QifgG0" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792401654342 X-purgate-ID: tlsNG-d25034/1792401661-03AD4A5B-07048F37/0/0 X-purgate-type: clean X-purgate-size: 6274 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LQJVOZZx3WI2pPmzX0QifgG0 Content-Type: multipart/mixed; boundary="------------YJUUYI5pAxmHq7q0va98g4Io"; protected-headers="v1"; hp="clear" Message-ID: <63635ebf-f189-48af-913b-300a90f7c99c@vates.tech> Date: Mon, 19 Oct 2026 11:20:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/8] x86/xen/pv: Don't setup runstate area too early To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Oleksandr Tyshchenko , David Woodhouse , x86@kernel.org, linux-kernel@vger.kernel.org References: <1792170295.8631fc262581453bbf619ec5b2062170.1a145ac82530008425@vates.tech> <1792170392.8631fc262581453bbf619ec5b2062170.1a145adfbff0008425@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: --------------YJUUYI5pAxmHq7q0va98g4Io Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTYvMTAvMjAyNiDDoCAxOTozNCwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBP biAxNi8xMC8yMDI2IDY6MDYgcG0sIFRlZGR5IEFzdGllIHdyb3RlOg0KPj4gVGhpcyBpcyBu byBsb25nZXIgcmVxdWlyZWQgc2luY2UgWzFdLg0KPj4NCj4+IEF0IHRoaXMgbW9tZW50IG9m IGJvb3QsIHBlcl9jcHUgYXJlYXMgYXJlIG5vdCBpbml0aWFsaXplZCwgd2hpY2ggcHJldmVu dHMNCj4+IHVzaW5nIFZDUFVPUF9yZWdpc3Rlcl9ydW5zdGF0ZV9waHlzX2FyZWEgYXMgcGVy X2NwdV9wdHJfdG9fcGh5cygpIHdvdWxkDQo+PiBtaXNiZWhhdmUgaW4gdGhpcyBjYXNlLg0K PiANCj4gVGhpcyBpc24ndCByZWFsbHkgY29ycmVjdC4NCj4gDQo+IFRoZSBwZXItY3B1IGFy ZWEgZm9yIHRoZSBCU1AgaXMgd2l0aGluIHRoZSBtYWluIGltYWdlLCB3aGljaCBpcyB3aHkg dGhlDQo+IGxvZ2ljIGZ1bmN0aW9ucyB0b2RheS7CoCBXaGF0J3MgbWlzc2luZyBpcyB0aGUg Y2FsbCB0bw0KPiBwY3B1X3NldHVwX2ZpcnN0X2NodW5rKCkgd2hpY2ggdGVsbHMgcGVyX2Nw dV9wdHJfdG9fcGh5cygpIGFib3V0IHdoZXJlDQo+IHRoZSBCU1AgZGF0YSBpcy4NCj4gDQo+ IEkgdGhpbmsgeW91IHdhbnQgdG8gc2F5Og0KPiANCj4gIkEgZnV0dXJlIGNoYW5nZSB3YW50 cyB0byB1c2UgcGVyX2NwdV9wdHJfdG9fcGh5cygpIGluDQo+IHhlbl9zZXR1cF9ydW5zdGF0 ZV9pbmZvKCksIGJ1dCB0aGlzIGNhbGwgaXMgdG9vIGVhcmx5LsKgIEl0IHR1cm5zIG91dCB0 bw0KPiBiZSBubyBsb25nZXIgcmVxdWlyZWQgc2luY2UgLi4uIg0KPiANCg0KUmlnaHQsIEkg d2FzIHRoaW5raW5nIHRoYXQgdGhlIHVzZSBvZiB0aGUgcGVyX2NwdSB3YXMgaW5jb3JyZWN0 IGF0IHRoaXMgDQpwb2ludC4gQnV0IHRoYXQncyBub3QgZXhhY3RseSB0aGUgaXNzdWUgaGVy ZS4NCg0KV2lsbCBhZGp1c3QgZm9yIHRoZSB2My4NCg0KPj4NCj4+IFsxXSA4YTIyYjk5OTZi MDAgKCJ4ZW46IGRyb3AgeGVuX3NjaGVkX2Nsb2NrIGluIGZhdm91ciBvZiB1c2luZyBwbGFp biB3YWxsY2xvY2sgdGltZSIpDQo+PiAtLS0NCj4gDQo+IE1pc3NpbmcgU29CLg0KPiANCj4g fkFuZHJldw0KDQpUZWRkeQ0K --------------YJUUYI5pAxmHq7q0va98g4Io-- --------------LQJVOZZx3WI2pPmzX0QifgG0 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+p0QLLz9AFAmrV4PUFAwAAAAAACgkQZg+p0QLLz9A+ OAv+N+SSLcu9nZyqRhlPZNTKNHcpXTvFUpN+Lq/1yHFL83Csyk/zYbAMBqfQuyV3h3ay2XqWeGAb aBN7kUtXIn7LXUb+O2W8YP3kdv0AAz5UFWIL/h/U3q8J2QsbQ9Wk7q7cvwgqkTsG9+D/suk4Yx6g hu4vCeM/yUuBwYGkL/EPsMYMtcDqK0EGPz7TM0ksizMhzHvIEKpvu/+xakntWvI/WKrZH8OYZOd9 QbGra0Vwz1r6YugjDbJDxSN3DwWmT9EjBv+gdN1Tp8Em0uwmFSykq1VYxspN0BVY9XyrYG+8Tomg 1WGBXjdpO9NKyOUsl9gE26zwKKVxJMuqEw0lYvDEMQRY7qdH0Yn9AAXRC1Bf+292wXDMpMfJtAUm TD1ARGD24tqV0Gooq0kRQI8yZIkrVRea6IZcmJnJg9f8C/dUssF1os+5+qTc+HOlhf59hJcRXVte POvEZtmcEA78C9sIVXmACHQWtLse7n8YwHXkoVfXyp/KLvOkMFzAONEvobFQ =T1yV -----END PGP SIGNATURE----- --------------LQJVOZZx3WI2pPmzX0QifgG0-- From xen-devel-bounces@lists.xenproject.org Mon Oct 19 09:31:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 09:31:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454037.1667518 (Exim 4.92) (envelope-from ) id 1xIjiR-0001Wf-Ux; Mon, 19 Oct 2026 09:31:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454037.1667518; Mon, 19 Oct 2026 09: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 1xIjiR-0001WY-RR; Mon, 19 Oct 2026 09:31:35 +0000 Received: by outflank-mailman (input) for mailman id 1454037; Mon, 19 Oct 2026 09:31:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIjiQ-0001WS-Q7 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 09:31:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIjiP-000lTu-U8 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 11:31:33 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5e36e-e002-0a2a0a5209dd-0a2a4506d50a-24 for ; Mon, 19 Oct 2026 11:31:33 +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 6ad5e374-195a-0a2a45060019-94a39b0c3628-3 for ; Mon, 19 Oct 2026 11:31:33 +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 69J8OtXa3169505; Mon, 19 Oct 2026 02:31:22 -0700 Received: from ch1pr05cu001.outbound.protection.outlook.com (mail-northcentralusazon11020081.outbound.protection.outlook.com [52.101.193.81]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc6j5k6kx-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 02:31:22 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by CO6PR02MB7700.namprd02.prod.outlook.com (2603:10b6:303:a7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 09:31:20 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 09:31: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=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=qT+xoMU5DdQzgmI2sVD9hkL+V19lhJieKAElBE3tG P0=; b=KpYpwDzlEtmdZbGLDhmZRQU8TbuIUXAtmafhFM+8gTpQFsWWGkAXz0Q/D 9dCocTmvZlwa/Gv7vLuKzXKceJQXpr9nBKwz4DuxP8Zogf3kgRNVRt6L4WwPvD03 UnX1uXPubsp6n2h1jbRF/1dR/K4Khwly7m6N8xwczfoca5jqTm5W0I42rhcxUaRu gQ0FkOzf7PSPoNDkWFqXUktpcLVKNUK0AYEHgcOiyfQbwxdVE+SwXFFTeFxwdsxf zxK9kYLcAEEKNikzgcw0RwX8tu5igBMbn6wgJV0ckVYehed3GrvttiSssoxad8HI 1wduwzuMGxJ0cq+OWUC1WQxZwva0g== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TSOSZDVP7nbEZHVlC3UZoYj7bOdit0x3IsBihUkehxFwZm1pjYquJQyvpAEORZy4GInArFJ54QkMzGwHFGFhn6gLVAWr/NB7iGH93sqnxV6aUlL0ADC9RnVy6SdRmf5SoLFJpUqIUIFLETiAhNPR8vUWuFH4vxrAwYuI1Ce2IWdKSFedIY0XzmPhVVrEsG67kxSHFwp/K2leP8m34C/D/K801WHY/JYNybSbb93lr9Z4atpdQPxxYHdH+2Hdlv+3ACSgYLIYq2jq3WZYdhCWhuOO+zRjYhzmXelwFeqU8Tcnt96RjN7t8VCqgT0awBPZ9j4MY+d0vkdsTwkzMaiYkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qT+xoMU5DdQzgmI2sVD9hkL+V19lhJieKAElBE3tGP0=; b=DnD/AT29JVI3tQPPghljsA7dxjvnJKv/7XqjcSKS2amu8ehDWmSmgjvgK+ukhF1EHVoM76XdJhCIJ7sK+4eHf9wv5xXJt5+0mQ83PfQSKlkmvTohHOXVqAjVXpla9lnucTbIxq4BP4HdTwb6IGeY0r3d4gsFB6UfCsOupyljTX3U+PuRwP1BMNgjnpQkW4CWkEQsfNnNxx8jJSr5jz+P2z6c3A1T6HzuYajEHNUcX50SrcNOL5VDk86xP/lVvj8sYTNUMGq5VsLNNBIo+fd7HKlCoa4sPmGEoxGQg4qHH3P7JE2ip4r8/ojIk9ycIkHZe5QCMn+jQQLrFhBqaGdInQ== 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=qT+xoMU5DdQzgmI2sVD9hkL+V19lhJieKAElBE3tGP0=; b=XMdc82Ado7BdP2ota9LZzeSUBS137/vfZP/XRwOsGPQ/lh+dHLKq1NhnUEisUblME5FH57OQCTRyPZiJNr7/vQlNI8Wwom3VLIoD+Lv66dN1GtRwUnBuzBiMKqjcGNyKmuj2xk5kKifV5Dw3diGNjRu9VPtWi1p7VTMSFC/uVFvfxdz1tG+zj1FihIG1xF0bOo0WXCFr6NKh00KnZkTkeMnyI5yOIlb1OCw29uwz0sM46eMr31fMqFDpJucphhsRLjnWxBasFiAtxxm1eJYZXHMWsHLE/c/vtn4PX5oFBIFZ9ymmeCLkvokUxYY8FGOhCpA1erNjcXdikVY3sn3sBQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <5002a7a5-3627-40bc-b0b6-404262106e3d@nutanix.com> Date: Mon, 19 Oct 2026 10:31:15 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 18/27] i8259.c: introduce TYPE_I8259_PIC device To: Peter Maydell Cc: 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 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-19-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR05CA0032.namprd05.prod.outlook.com (2603:10b6:a03:33f::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_|CO6PR02MB7700:EE_ X-MS-Office365-Filtering-Correlation-Id: f0bd79d0-e202-40a5-c955-08df2dc3bbbf 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|56012099006|6133799003|22082099003|18002099003|4143699003; X-Microsoft-Antispam-Message-Info: Q7T3qi+B766DUbt3/EKs5L8KkvtuARzXburSNK4UJylxw6ZWHLxBhBb3Fx3BT9URgk8kICUfwy/fm4uPvDWOB/tLoJPHHIQmzd5dPvn3xQ5SoS1akBlt9eFppIvxm54lkoCw6InnXFDKTyt/0aQEfK0d6rqJQBi5Xalr60MsBP9Q/t1CC1HRJf2SfX6033J8qc+Y3U1ObiHExX9jBMKH2pV3GuwowNLbx5MnqEA0VNuVrKkxXtG+U79ocwvqUPmgQHYSamp8551RIrKwq4uGLUE0ZqIAdb6YR0xd6I0fRyrMHDa78i2qiAvNqbExlKKVJLyvwslxiaOb/999LvI59mK7Xt2LAkhZsfHmi4VMLk373oKWXtLjwzNGnWJayN9EtY5g5dofIJz8rHAtufvPVpJnfNQQtc/RSFL8vZq26OEk0zGD75xGXdR4eyksyDkS/SmQ9HknaZ1zujwoBDPHnSQeKckAUnPppC6+IwbVKkeTjQ9gJLAjobcv2tXInLCs4O4XpuNk79eSJyrNXHHDUUD4iXQTOLhrPItB8HYSPNTjiK2RumGxLUpD1UoGrLv3DDteJT1xcH/UvSDSvPBndeVPF/Y7ZW6InGkllJZylxnPg8ybcfAyQWWIbODn3pgCFxBMmpqlRqfqhV1XT7fGEUdpnBlnRdGUR7HnryKPTbo= 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)(56012099006)(6133799003)(22082099003)(18002099003)(4143699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bVk2VlJCcyt3SFJBM1NGRHZXUytQaWRMUVM0T3REZkRBVXd6anRRTUJIcUNG?= =?utf-8?B?ZHY1SitIalhka2V1T0tYVDlEN245TGxDbVFJN0ZXMmwybXUwRE9ES0tRcEpp?= =?utf-8?B?d2NGUGcraExCZkdKdFZtcEQzVWNBb29ETEx1d2xmb0lOZlYrNENyRE11ZWlQ?= =?utf-8?B?SmNVMzBBN2YwWndYaXFEaFFkRk45UldxZjFMMWpjaE41SWhKeVloVUlQMmlW?= =?utf-8?B?UEJzbjFTWHNtN2VaMFViQ0lyWG00VDVQKzZXRm5Fc0JiVGxZMGVsczFHNHRE?= =?utf-8?B?L2h6OGtPcVpObjdydExITHFHY0hZMCtRZnRaeTd4c1lkZ0U4d1RKNlZWSWc1?= =?utf-8?B?c21TaTlEQlE5UStjekdraXU0RnhUYitzT1hpSGU1QWRiRXlaTVlaMVRsZExV?= =?utf-8?B?RHcrWWhuVkFzRkVJU2gvN3g2RVpGRjVJUWljWGMxZHQ0eXFIUURDQm9lYTNH?= =?utf-8?B?aGJndzdIVHdPdlFESGR6VG5oekNpbExmdzJIZEZkcWEvbWRlZGFmRVZIOWxu?= =?utf-8?B?cGtMZlB0cHV3dFR1cDhtcHBNajJKRnE4ZVNISmY1M3VHdkRicHVqdzdQUjVq?= =?utf-8?B?WmhzMTlNT1EyTDBKdUNkS09SYVZYN29TTVhFa1FUNTRmcmxPbk5UNjkvYVRG?= =?utf-8?B?Q3ZCZmxWdFZTR000eVJ1MzhiZ055QVk3YWJQOE1kbGdEdy9iK3Mrb1hwWDB3?= =?utf-8?B?MmU5bGd2OVd4K3duSXMrZjUvN1dEN093eVZsNU9lL3ViQS9CK2d6aHRONVRJ?= =?utf-8?B?WTg3ZllYbmZhTUdrTGlDL0JoTW9PSUZJZU9OeVNUT0JvVkwrckxrZVJCUThC?= =?utf-8?B?WjdnWklDV2w4UHFneHlSbmN1UVdiSUNNZENEMGpMV3czQmQ4QkxxL1lJR2VT?= =?utf-8?B?Qzh6WTNRQXY4SUFyclhsZTZ2b3JCRWs2QlNEQnpYdTdZTHhVYUppOTZPLzk5?= =?utf-8?B?QisyYVlEVFJ2WXhJNHpTV2ZvSHhPNE5aUTNDT2xoZi9zSlIvcTBTUTgrc1B0?= =?utf-8?B?MzV2SmFweEJ6ejlhUWt3ODEyMWJmVnp2eEFZaHovZlByMVp1eTdFMHFNUllD?= =?utf-8?B?QWVCd2dpSENpVWdNN2h2WitmeGFNeVp4T2o5U2lGemNQTlVoV2k5WDFrVSt5?= =?utf-8?B?Y1psT05WQ0JDZmZ2NExEckx1dWdacW11aFVtWFZrYnpXelNhSWErNFhBZzFn?= =?utf-8?B?dVhFWU5id1BQdmg3Nm0vWFU5ZUtZQ0NVTTV0MDlQRWVnL2pudm4rbjNKU1Zh?= =?utf-8?B?N1hya3EzWjFqY3lKV2lnTHVGU01Vb2xtbDFXd05Hd3ZlOWd3cnpxNlREOEVZ?= =?utf-8?B?MitaUTRDQkpzVCtEWDRjRmQ1V1lsUTAxUmZGeFN3WWhxbnc1dUd3N2lMNjdZ?= =?utf-8?B?UmJlSk9oQm9UMTVNWVR0MzFUUkpPQURNcVdzblpBOCswYU1KSTRjRytaaW8x?= =?utf-8?B?QmNJQzVQeENHMjhBT2pINit3b3lTOXVmSkFtdVlZNHNEOUdmUS9CeXZvVG5T?= =?utf-8?B?N1E3K0FEQ0FicTROK3A2cVh2Nm51M3JmWXFGbFRuYmJFZEd4d0F0SmNCOFBU?= =?utf-8?B?RXNqNlVLOXJwL1BmRlNiNnN0UlBaZ1hobUNjeTJDWjlSbWFlWVduQ1FZTW1Y?= =?utf-8?B?Z0JDZTg1VVRhS1RxRWhiNXVhQ0dqblE2TTZIMkxpdEdtNnBodWxsMTFjN1BV?= =?utf-8?B?MkJzWVlGVU9RYTIrRWNuS2ZDN0Y3L0kwL3RpWTRPdzdWeXJkOXgzemJPdlcr?= =?utf-8?B?MkFYUmpjN2l0dGE5aHFSeitsVTRsVmZ0c25LNWcyZXlWVUZtQkxjVVg1VStv?= =?utf-8?B?Q1dZdEJkRkZvZkVYZVk4NUNQQ3R1d2F5Z3VVS2tjTDcySW5Qd3ROeTBCcjZ6?= =?utf-8?B?aFRGa0t2SUowNjN3NFdySlg1N3BoakhKc1NZWVlQZ2pJOWhmTFBJQmlYaERN?= =?utf-8?B?cjloL2ZZazlqemtMZDBHZjQxSUNSeVA4MkhFbEhFaDIwM1E3UVNXR2R1bm02?= =?utf-8?B?RmF1YWFIZzJEMlc3K3daUjgrTVFQQ1N2VnNwRCtwZGhMRkU1SkRxaitpY2No?= =?utf-8?B?MU9YN0x4SDRTSk5aeEYvQVVZbjJSdXZxV0ViTDZ1ZW9YRitnSVNKSFVvdjhI?= =?utf-8?B?YTB0Sm42ZDgrMjlrNkpsUjZKU21PMGRYN2tCYVhwbGJmSktYeEhGQXd6R1Bt?= =?utf-8?B?cjVkMUQ3UHhPTU1UVjBKY3dhRU1Yc0YzcFdHeis0V1hiSGFnMnorUktYbHlK?= =?utf-8?B?VzFMdEhMRmI0MEIwSm5iV1F3WG9CVGxBSVpiSzQzSThnTXZuSU1XaXRubmZv?= =?utf-8?B?RFRPaEhKSUtRRmI0Wldra254VXh1SVAzZzRYZkRnaTRMSk9ScEI3UjJOUnZB?= =?utf-8?Q?etqeK8ZfYcN853A8=3D?= X-Exchange-RoutingPolicyChecked: I9O/itQLqObpZQYf0kQLHrPcjo3zyN36V6z13EvcdwPy1fRpoxO2kAE2pqmV93eNuHiYukPk5yK99MExHVHnoGhX/jCcjhUtHf9hGq8ERQa5xCHshD0s+NS8iK54dHfxTVhtFPQfitJ03Nwq8UPnCkCG37+FBkbO/A5it8AXRpat3MhfqJJiBMe9KEWMfDRU35GZzw327McwFgdYzjycCC846y0uEokEt7/chxNwtGhYoOh5GVQ7v4GH5q8sjswUrNiH81Pk/3ITaCPpl2UMFCnvTCWsik+iLVFi1aCjdRntdGXr5UW0Zrx4sdrjJmkKCcUjYWoWdyhdevu0oA8FYA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0bd79d0-e202-40a5-c955-08df2dc3bbbf X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 09:31:20.3097 (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: +WmI5Fc3YBR2wukl7O5/EEiKWAWTYM993LKcgR4C283ycSVw1GVCjmSu2H/8xOXgd1ZnAugD9mx/jzbChS7bymgY+dNEvyzNngB88yKHK2w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7700 X-Authority-Analysis: v=2.4 cv=S+NMU4sP c=1 sm=1 tr=0 ts=6ad5e36a cx=c_pps a=6CsdduS81u+lxnadr1BEog==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=Y7PUAx_Gt6IB--uV870A:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDAzNyBTYWx0ZWRfX7ppgsvCK6De3 Rjk+mNdbBYYtaSaUrqrTloDnqyPEGciK6X4wzXWgnl5DvGoQQolfLnGrWysGkWs8u5AtMsXD994 9B+r2GpTXrNwGrXIIHrqXF0kgYbQpWo= X-Proofpoint-GUID: NNG7sLeqspMfz8MzdHNubRPqAV8UlXkS X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDAzNyBTYWx0ZWRfXxlwGmCXrAz2k tF1rizApd/iLQv9EgcAm+C2RAub0xcMXw2Ljj+HZOMUN+xj5dJMpHbu8erM1Xyto1u78uRosa2h EIs50q5kl4Amp47gm5FKvIa+8NjekLkhHs6r86Jvm+b9yO3L3fWUP/jzS6GyyiV1Ge35e3F3Ovz 8ldenpbeaRU1Cqz7BO5Xp5IRg4bVIgJVuP+TTj8NUGjkKYnSCoKdcr7VGijsJ6WTqva62yYlhDf XDUC+FPholsYZJLA5U3aJFVtX3Zguu5maCAvJ2dSm3DzcMWyhC6foaGd6dFZvfHtw5n4rwe1Kno k+fU104uL/nlvpy677WWq96vWh/O3IKBIxn1yQ5aWhWK3Fw4xVZP/QXAPOuo2EcW6KFSTEvH86r Yh/BSqQPFqnDBecE4we8Z7/aJhSs7rLfvYNYqyhKDlFb9sjWeNHhgxgYfgh+QNOPcAhJX04yMQ7 FxaklMf8q9LZGFWqxbg== X-Proofpoint-ORIG-GUID: NNG7sLeqspMfz8MzdHNubRPqAV8UlXkS 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1792402293-FCC0777B-A56EC6CB/0/0 X-purgate-type: clean X-purgate-size: 2308 On 16/10/2026 17:17, Peter Maydell wrote: > On Fri, 16 Oct 2026 at 15:23, Mark Cave-Ayland > wrote: >> >> This device represents a PIC for an x86 machine consisting of 2 cascaded i8259 >> devices wired accordingly. >> >> Signed-off-by: Mark Cave-Ayland > >> +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; >> + } > > I'm not sure the _and_unref version is what we want here. The > documentation for qdev_realize_and_unref says: > > * If you are embedding the device into some other QOM device and > * initialized it via some variant on object_initialize_child() then > * do not use this function, because that family of functions arrange > * for the only reference to the child device to be held by the parent > * via the child<> property, and so the reference-count-drop done here > * would be incorrect. For that use case you want qdev_realize(). Yes indeed, you're right - I missed this when porting it over from the old i8259_init_chip() function. Even more amusing is that there is currently no isa_realize() function, so this is obviously the first container device being implemented for use on the ISA bus. I'll add a suitable isa_realize() function in v3. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 09:34:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 09:34:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454044.1667525 (Exim 4.92) (envelope-from ) id 1xIjl6-00023I-AC; Mon, 19 Oct 2026 09:34:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454044.1667525; Mon, 19 Oct 2026 09:34: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 1xIjl6-00023B-7a; Mon, 19 Oct 2026 09:34:20 +0000 Received: by outflank-mailman (input) for mailman id 1454044; Mon, 19 Oct 2026 09:34:19 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIjl5-000233-Ju for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 09:34:19 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xIjl5-00000001qk0-1n0l; Mon, 19 Oct 2026 09:34: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.98.2) (envelope-from ) id 1xIjl5-0000000BJAc-0BzJ; Mon, 19 Oct 2026 09:34: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=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=7tolprFTLBdJHIEY5/o5KnfiBKSnnxCUD1lV+vnqJ5E=; b=yX5HCYx6v0x5F/Rl/1+llcS5h+ CzjP0HHc/bVwc9ndYvSPIe9YmufoGFrAIKYn+g3htejQp8XplZMNpjA3r0p0EsxgDeLkz5/6izT70 fEZE9Yc7vJ4Jxgm4Uhehkbr/euz3G9QYVLUoOtf2aYA7eNXaarsCL82F4G5CY4iwe+aE=; Date: Mon, 19 Oct 2026 11:34:16 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Jason Andryuk , alejandro.garciavallejo@amd.com Subject: Re: [PATCH v4 3/3] x86: short-circuit certain cpu_has_* when x86-64-v{2,3} are in effect Message-ID: References: <18b38bd8-bc6b-4925-8880-234c7d2b9497@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <18b38bd8-bc6b-4925-8880-234c7d2b9497@suse.com> On Thu, Oct 15, 2026 at 11:11:39AM +0200, Jan Beulich wrote: > Certain fallback code can be made subject to DCE this way. Note that > CX16 has no compiler provided manifest constant, so CONFIG_* are used > there instead. Note also that we don't have cpu_has_movbe nor > cpu_has_lzcnt (aka cpu_has_abm), and we no longer have > cpu_has_{popcnt,bmi1,bmi2}. > > Signed-off-by: Jan Beulich > Reviewed-by: Jason Andryuk > --- > Of course we could use IS_ENABLED(CONFIG_X86_64_V) everywhere, but as > CX16 shows this isn't necessarily better than the #if/#else approach > based on compiler-provided manifest symbols. While not really intended > to be used that way, it looks as if we could also use > IS_ENABLED(__POPCNT__) and alike if we thought this would end up neater > (because of avoiding the #ifdef). > > We could go further and also short-circuit SSE*, AVX and alike, which we > don't use outside of the emulator. This then would of course call for > also having a way to select x86-64-v4. > --- > v4: Re-base (over dropped cpu_has_{popcnt,bmi1,bmi2}). > v2: Also cover XSAVE. > > --- a/xen/arch/x86/include/asm/cpufeature.h > +++ b/xen/arch/x86/include/asm/cpufeature.h > @@ -132,11 +132,17 @@ static inline bool boot_cpu_has(unsigned > #define cpu_has_monitor boot_cpu_has(X86_FEATURE_MONITOR) > #define cpu_has_vmx boot_cpu_has(X86_FEATURE_VMX) > #define cpu_has_eist boot_cpu_has(X86_FEATURE_EIST) > -#define cpu_has_cx16 boot_cpu_has(X86_FEATURE_CX16) > +#define cpu_has_cx16 (IS_ENABLED(CONFIG_X86_64_V2) || \ > + IS_ENABLED(CONFIG_X86_64_V3) || \ > + boot_cpu_has(X86_FEATURE_CX16)) > #define cpu_has_pdcm boot_cpu_has(X86_FEATURE_PDCM) > #define cpu_has_pcid boot_cpu_has(X86_FEATURE_PCID) > #define cpu_has_x2apic boot_cpu_has(X86_FEATURE_X2APIC) > +#ifdef __XSAVE__ > +#define cpu_has_xsave true > +#else > #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE) > +#endif > #define cpu_has_avx boot_cpu_has(X86_FEATURE_AVX) > #define cpu_has_rdrand boot_cpu_has(X86_FEATURE_RDRAND) > #define cpu_has_hypervisor boot_cpu_has(X86_FEATURE_HYPERVISOR) Alejandro (now added on Cc) is working on something that achieves the same end, but it's more transparent and doesn't require modifying individual cpu_has_ macros every time we want to short-circuit one of those. I think it would be helpful here also. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 09:57:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 09:57:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454052.1667534 (Exim 4.92) (envelope-from ) id 1xIk7H-00051F-5m; Mon, 19 Oct 2026 09:57:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454052.1667534; Mon, 19 Oct 2026 09: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 1xIk7H-000518-2m; Mon, 19 Oct 2026 09:57:15 +0000 Received: by outflank-mailman (input) for mailman id 1454052; Mon, 19 Oct 2026 09:57:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xIk7F-000512-9S for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 09:57:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIk7E-002gCA-8c for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 11:57:12 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5e96f-8faa-0a2a0a5109dd-0a2a450c8bbc-36 for ; Mon, 19 Oct 2026 11:57:11 +0200 Received: from [52.101.52.62] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad5e976-f479-0a2a450c0019-3465343e5228-3 for ; Mon, 19 Oct 2026 11:57:11 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by PH7PR12MB6468.namprd12.prod.outlook.com (2603:10b6:510:1f4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 09:57:07 +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.0522.017; Mon, 19 Oct 2026 09:57: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=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=Y/HnD1cErJqBGO/AD0qmQKY/4wrX4sxTAyBQdJM4hhzS0hxOqprgMY3a+IWKVfnJOYCIN4LOkCItQlOdwfy6hAl0pBuhTtuILR/RVMTVVtQAY4W53JhTkKG0aAWtQgWYn8Nqpv+zE+DbAvO41+0fcQDbV7x1eXglFL3e9LKMiX/BFitMw+HojzcKNf3pFLEYadrH4WXouCrjnF0WKOpoueP/1S4yFbX92twUKZYRVqdW/9cABtrylDsNeOn8NJ9rWIU5UAIgiGm4vgPspHiU6ykGig1NzoHQuftfBTSzTtThqhoWf86qOnxNfeCWvyA8WJEEhpX7wwqHyWcG+ve/wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=20Xj4+fFCJ9DxG7VWK3ia5TVuJSi01rEY7gT0dVWtFM=; b=eb8doOJGy8Eg9P+u+nE3IUe1USC/vTw3ZIuOwZlE0kTfDxNFcJzCwkMKIqmUKQTZq6dbHoIm+uLY9nDYL18yV+tS5fHiVF3cHMRk+UHgu315ITm40awb7+F7mjivV/hzdOkGaDD4hNjnMKH7jerUpo59YF7OFaFAK1iojWBV21f+drzQe7/txDtwj5yP1YWlggGzR23PmoZEjrhNj7zEv77SilcffAAgHAV2dVmJJmb1hVGHiZDHRqArVG4CzQlCUIVRsTBueKIZF4r6IBTIJ3L+WLplRHkuHmxbNTYcfOtMXZYItfkBVRYdTe/L4seKaKAklp5nmWI/7j4vVdMZPQ== 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=20Xj4+fFCJ9DxG7VWK3ia5TVuJSi01rEY7gT0dVWtFM=; b=Ge/8HdsbdFfFRduGS1sAi2SNvEz9MzVTMmKPer6I6trt1ale4PdhoEnWUYVqeH1nfA+uScA90g/vJwOxBr4jnkEVKKlQLbRjmt3jfuNUd58liiYR0kgRvHGHQ8F6+O35m1yMm3RDCyvtggmlMd22pXVH1189gtYk3TT2rZNWuk0= 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, 19 Oct 2026 11:57:03 +0200 Message-Id: To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Jan Beulich" Cc: "xen-devel@lists.xenproject.org" , "Andrew Cooper" , "Teddy Astie" , "Jason Andryuk" Subject: Re: [PATCH v4 3/3] x86: short-circuit certain cpu_has_* when x86-64-v{2,3} are in effect From: "Alejandro Vallejo" X-Mailer: aerc 0.17.0 References: <18b38bd8-bc6b-4925-8880-234c7d2b9497@suse.com> In-Reply-To: X-ClientProxiedBy: MA3P292CA0035.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::14) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|PH7PR12MB6468:EE_ X-MS-Office365-Filtering-Correlation-Id: f7f8c106-f819-42ad-a744-08df2dc755c6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|261009223027099003|10067099003|56012099006|22082099003|18002099003|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: YZLhwBUxHIpTtSf3vxjWiCXnVvAOdf1Bpy6QotQLM+iZpJ+w0pgrKSZGLOCf+9UoUgIePYx+56pC/e1PD3xR98/cav85wHBRaHESjv91GNA0ro6ymAA41ZJiKqF0NdMNVMValWfdZOXGgAGsJ4+zfA1ydlpM850SFIZeZuWsvm9vriYOk9RxDBnVnhWFI+OF20YDPAHURkkOLieuzVhpWHplYCLwoO9NcljWYx/ToLskMI8fRRVWh/Tql5FWP+Eyux4AR1lrdjbX9FRnMVVjPQmrDKN8pE2u2ByByo7xYgSgkxk7jhqz9FN5SdQJnzghRobAWiMhxpfNJ77UURd+PYKjeYv/8IlR61AxehaWh6WDaEhkkh2RFtsfFotLo8ZM5qyIM3LvaOqDrD7ewOwp0rwEjyDp4FX3vosZVGN9oBhC8id9Jee/Srk9HmRjGQ1/TbBjvjDqJAqMPh3ZuHw5PkvENQHZTQrbtkMkD75/bFTKPb4lDSKCCFd1igso6RrFYU/cde6QgsuFlnmon3XISvvTluluz1awmMUQqqtOMpkNmCymzGJQG8dL5ANKI2HPUiN8TJb/d+JizUSWrMv3s4BoUByWAVqiCkw4brvmXf4FZ9F0clA+UxaXiZT70wKhoCidelhZ4oehMqhELrjGGn1qODXhWK3kEMfkf1bjEqw= 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)(366016)(23010399003)(1800799024)(261009223027099003)(10067099003)(56012099006)(22082099003)(18002099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S3hrbmZxanRDcVdNN1JmS2wzbHZEZEZoSGxydUZINURCd0tDbkdBL3dZcEFz?= =?utf-8?B?OElIRzhCSEtmanh4OHkyT0h2dEk3czQyWFVvWm9zOTdFaVJURkxDZnRUQUVo?= =?utf-8?B?L2lIZWcxUDRxZlFkTGVrejJSbUNFeUJ3RlNTL2tCMlJFdldZd2xNdnRHRGlB?= =?utf-8?B?S0dicnpIS25lZHhjRjU3bUZMZ1J6V2NSdzNML0xabjlIU1lzZzhvaTJYWENE?= =?utf-8?B?YXFmNjFuNXJieUZDcWdYNHkxakVBbjJCeGdOVElWODQySE14RU9teXRGWm4w?= =?utf-8?B?QUxXNFFqWTA1d3lNRm52ZVJXYk8wWXo4ODNOSjZDRlNFNWpqVGpiYXErSklh?= =?utf-8?B?VEsrTnRsYkJuZGtsRyttTWFrYVBNZ3dkUXh5WmRINy9xMUgyQjNVUjJLVjA1?= =?utf-8?B?MEdVaHdmVW9Qcm9ieHBWcHFKcjQ4QXlFOXVkLzhBaGlCdVpFRE85U2FBbFVu?= =?utf-8?B?aEFCZkFDVE4zaGVaUXRncmlWUUNFbDVLbjQ2S2JZR1kxa3VTNGhyejRqUkRL?= =?utf-8?B?ZDU4dEgwSGRELytkRHA1QVNkRjVieFJLRU1zSUROT0tIaWhwK2FjcFlEL1BZ?= =?utf-8?B?bWpJNVJkUSs2VTBZOGVGSVdzSGNlc0l2SVFvcXlPZlVrT2NGSnZjekNFMHY5?= =?utf-8?B?dTdRZWduVTY2R3R0SGpmbzVJL3hJaUdJaHc3enV6QjkzcU1NQTNzbU9jMWo1?= =?utf-8?B?bDBlWm9icjc0RG41QnZwa1VHNFRlc2daWXlkdnk0SHVvVExQQzFyTzdnRDI1?= =?utf-8?B?bjAva00zbVlJWk5mWGRadThKUWNTOUFveWRXTGZqSTR5UERvT084SUdzdER4?= =?utf-8?B?LzdVTDFiUFJTWFF0cW9sSnR3Um05cE1ESjJ1S0Q1WXVScmwxMGVlOFNlUUor?= =?utf-8?B?T0EyZm9xV3prMFljdnJmNDkvbCtxb0t2TkRHcHk4MUVLMWV1VktqeS9aSjFB?= =?utf-8?B?QzZvUURkT3JCT29acUV1bmRkQ1p0dkVnZzFtSGF1MGovOTZzZk5QS2tIdWQ5?= =?utf-8?B?RVl4SFkzcjMzYzZtVVNJSVpvMFMremhRNDNKb1RGb3NZM2l6WHEyWHRCR0sv?= =?utf-8?B?WE5abjhCb3RzME1BSFlXTGl2L1ZhMU54QVQ0bTlQWTAyUHgwVUVVcGU4M3dJ?= =?utf-8?B?SkhWQ0xub1pVTU5QZndZemI5SUcyZzg1NUt0S0dIUVdEV1RtQTRqellWU1E1?= =?utf-8?B?WE9uWHJkOVZiYlZ4ZG9IMVJBWDdUell3N1owR0RLazZqVjFjeHBwb01XMUZk?= =?utf-8?B?WVVwS0VKa1FKbW0xZzNYUWlEcUVtcVpGUDh3R1hUQjYwdytjMXM0ZUJXN0Zs?= =?utf-8?B?RmUwVndhK1hJUkhWbnlLb1UzOUVYa1Y0S3piY2hKSEdTajVCT0xmQWhvaDVP?= =?utf-8?B?enNET1Nmbk1hTUtBeDZ2cDkwcnJKNjdQT2RBWjd4eGZRVjVaVVN1b1ZlN1U0?= =?utf-8?B?OVFjRndTQkpRNmVDYzd6bFBpZzduNDFMc3ZkOWJYeHZoQlpZMzI1WUJIWkQ3?= =?utf-8?B?WG9OOERDR2duRmxXNlBYWDNqWW14QkNiM09MaHNGNDk5cGF5UGUwK1p6dVpE?= =?utf-8?B?eUFxYWFNb3dvZDIzQWdkNzVWWE1Qakh2SFo1ZVNyVmw4SmhDbE5RS2pnQ1hp?= =?utf-8?B?azdDcmY1NjltdTFCNUlPc2hWbndqbXMvTWVsR3UzZ0RnMEdxVytCWE14a3hp?= =?utf-8?B?V2dMMFJ0RGYwK1lyam1ReTl6dTdqZkFydzRMcEp4UTlEMXVEaEd1NERGVzV2?= =?utf-8?B?aVZoSUZsNGNBdk9RaTlPblh1eGVZQTRYT3N2bHk0bjcwUXY1Z3UrNlJTZTB4?= =?utf-8?B?LzdlZVpQTUZkSHpIay81OStBSkcrcEM3cmJQRzd6ZVY3VUlSRXBGVFAwMGNo?= =?utf-8?B?TzJiUmNFTU9SZzNpZ0ExTndldGF1MG80TkJuKzJ5ZjRCM250SzVNTWc5RHhj?= =?utf-8?B?VGhCZlE3SGtVZUxjVVAwVkdHbDdBcGUyOFpxQUp5UnhqV3RiVlBqYW5JMXRU?= =?utf-8?B?d0w0UkR1RTE1SVJQYWVjZENFbG9WQ011bWhVS1gwbFVZZ3lwUWlJY1hTMG41?= =?utf-8?B?NGNHSDVRaTNrbmJXWmhqVTJJajNNbHRqWThKcnlNYmZ1YjJsRmczUm93M3dK?= =?utf-8?B?OGtMUzZXZnZzWHQyR1QxdkVGYkt4QlIyZ3BSbmlvOW04ajEvaVhxY2RMcDdX?= =?utf-8?B?WTRpRW40dlM5QlFXVURCTTVrQk03Z3BteTl5aURHRmExa0c5d2VtOU9xRDBN?= =?utf-8?B?dGg1cWEwcHFuc0U3SCtrOVNYR2E2YmJkOGZLWFI1SVF5VTVKM2J5MEExWWFL?= =?utf-8?B?SmhzWkwzRG16aTA0b2RRSWh2ekJaaWlDeW15VzY5QmdWRXU4NDZuQT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7f8c106-f819-42ad-a744-08df2dc755c6 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 09:57:07.2442 (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: YSxMeuSgahcDAmwVjqDXo9cfatRPPmr1EahTG+PQl9JLYBmkA/IJUW+r0R7ASBkQsIJIlc6zV7oGuBka+jvVEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6468 X-purgate-ID: tlsNG-d25034/1792403831-5270FA5B-B12CB9A0/10/78276251493 X-purgate-type: spam X-purgate-size: 3057 On Mon Oct 19, 2026 at 11:34 AM CEST, Roger Pau Monn=C3=A9 wrote: > On Thu, Oct 15, 2026 at 11:11:39AM +0200, Jan Beulich wrote: > > Certain fallback code can be made subject to DCE this way. Note that > > CX16 has no compiler provided manifest constant, so CONFIG_* are used > > there instead. Note also that we don't have cpu_has_movbe nor > > cpu_has_lzcnt (aka cpu_has_abm), and we no longer have > > cpu_has_{popcnt,bmi1,bmi2}. > >=20 > > Signed-off-by: Jan Beulich > > Reviewed-by: Jason Andryuk > > --- > > Of course we could use IS_ENABLED(CONFIG_X86_64_V) everywhere, but a= s > > CX16 shows this isn't necessarily better than the #if/#else approach > > based on compiler-provided manifest symbols. While not really intended > > to be used that way, it looks as if we could also use > > IS_ENABLED(__POPCNT__) and alike if we thought this would end up neater > > (because of avoiding the #ifdef). > >=20 > > We could go further and also short-circuit SSE*, AVX and alike, which w= e > > don't use outside of the emulator. This then would of course call for > > also having a way to select x86-64-v4. > > --- > > v4: Re-base (over dropped cpu_has_{popcnt,bmi1,bmi2}). > > v2: Also cover XSAVE. > >=20 > > --- a/xen/arch/x86/include/asm/cpufeature.h > > +++ b/xen/arch/x86/include/asm/cpufeature.h > > @@ -132,11 +132,17 @@ static inline bool boot_cpu_has(unsigned > > #define cpu_has_monitor boot_cpu_has(X86_FEATURE_MONITOR) > > #define cpu_has_vmx boot_cpu_has(X86_FEATURE_VMX) > > #define cpu_has_eist boot_cpu_has(X86_FEATURE_EIST) > > -#define cpu_has_cx16 boot_cpu_has(X86_FEATURE_CX16) > > +#define cpu_has_cx16 (IS_ENABLED(CONFIG_X86_64_V2) || \ > > + IS_ENABLED(CONFIG_X86_64_V3) || \ > > + boot_cpu_has(X86_FEATURE_CX16)) > > #define cpu_has_pdcm boot_cpu_has(X86_FEATURE_PDCM) > > #define cpu_has_pcid boot_cpu_has(X86_FEATURE_PCID) > > #define cpu_has_x2apic boot_cpu_has(X86_FEATURE_X2APIC) > > +#ifdef __XSAVE__ > > +#define cpu_has_xsave true > > +#else > > #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE) > > +#endif > > #define cpu_has_avx boot_cpu_has(X86_FEATURE_AVX) > > #define cpu_has_rdrand boot_cpu_has(X86_FEATURE_RDRAND) > > #define cpu_has_hypervisor boot_cpu_has(X86_FEATURE_HYPERVISOR) > > Alejandro (now added on Cc) is working on something that achieves the > same end, but it's more transparent and doesn't require modifying > individual cpu_has_ macros every time we want to short-circuit one of > those. I think it would be helpful here also. Yes, my cpu_has work would simplify this quite a lot, and it would effectively deprecate the ad-hoc nature of REQUIRE_NX cont-ification. I'll try sending upstream an adapted version some time early this week. Cheers, Alejandro > > Regards, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 10:09:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 10:09:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454061.1667544 (Exim 4.92) (envelope-from ) id 1xIkJ4-0006pz-5C; Mon, 19 Oct 2026 10:09:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454061.1667544; Mon, 19 Oct 2026 10:09: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 1xIkJ4-0006ps-28; Mon, 19 Oct 2026 10:09:26 +0000 Received: by outflank-mailman (input) for mailman id 1454061; Mon, 19 Oct 2026 10:09:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIkJ2-0006pm-El for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 10:09:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIkJ1-00GIx6-Co for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:09:23 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5ec49-e002-0a2a0a5209dd-0a2a450396be-26 for ; Mon, 19 Oct 2026 12:09:22 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad5ec50-fae8-0a2a45030019-94a39744e6c2-3 for ; Mon, 19 Oct 2026 12:09:22 +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 69J8QP1p3199051; Mon, 19 Oct 2026 03:09:12 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021125.outbound.protection.outlook.com [40.93.194.125]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc83eu6n9-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 03:09:11 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by CYYPR02MB9885.namprd02.prod.outlook.com (2603:10b6:930:c5::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 10:09: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.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=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= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=FgYtZhBrsAbcBpuNy4ju99GSZE6ECTVKtIgcep0SZ zU=; b=USCfJXIZkM7CvpWY6Q9yJ8THqmvN9bNOa/84B116fQkD5IbRin+lyTMKD 33eJFhfj2i3NFWFKdPeXZeLs0q5G0Gs989nLbgguy0JtBpjNbA+5BbfUA5geY7J5 knzV3wIWE8Gs5EMI4J47JT3PibG3Y22tFNmRT2HxjS8iI7gH04jSmkSGdwDlEUGc BMpLlpS4A9sRK1A+i/gTC75J/UhiTsFqUUw6UIXD0qjrufso9L2zJZlLt0m5x4fQ fyPACGAK7+l06tdasao7LgFOxrgbtf0XigjjgYpE8oN1l9H4ppazmG0V+Exhlg+X lZpkDAsE4wq7NbUIMhTYN/shPCRxQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IV/B0J+Pfgpr4r8b/fLUN5lvHRKSLxk7xl+SBTwtfBIsU2nFuGTLJNob+uCvlaDlqcrgvVCkApdOj9Noy3HSLBHKP+LeUQE6ZKfT9qoY43SYXKRMwa9LrnhUBQEcIaEKje+M1WPPOyI2OLnfUcIDWT1kKuJuzVj3rcbjY6iSDVv0r8RDpwuZkX4/+cPZvApoRxqBAsXEc1G0qz48F0zWubhH9Q46EDRNmPXTRRjCU9S893B5+s8JzJwA3QNfhDCoVqNugiWixi/0zt5Q2jafaQUqxVSfv4v01vYP8nY21ufBQ2O6DLJunIP94bFErvzRjfKBfMHuYI/I4Pe1rXPjHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FgYtZhBrsAbcBpuNy4ju99GSZE6ECTVKtIgcep0SZzU=; b=ivR6L14AAODLOlZ4Awla68f8/4/d2HTG5/mAfeBwkHr3QAEqWC/+seRprIfEZr2SjHe7pRcHUWTClfn0IrHW4GjYXFP3E9U7jPQGNXlwYtiKASREpDpgCAWl9sopEOF1PKtDRXc6INyZQTWcFmRSvbHuTUIxoICRup+FysdDw/izU4Y4u/cUdybHTklIVDgZfGPOK4/AcVLh9s5qLj0L7Fhqr2s1oYuxySFLc6frNpp8Bckf5IJU77vHNE/JyemgTDpH2n3mC7GQ9rjW6g7L+3JvR/7oySrwf2iijqvlFbPuTdkTl2mrpyGkT37EklvnYhfANA2Ns1TzGqFZaQLZPw== 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=FgYtZhBrsAbcBpuNy4ju99GSZE6ECTVKtIgcep0SZzU=; b=epmYaQGqf8F0ALVO6ZzQEYhUA7a1Gf/ThxWN6am4lzS16g+2Oe4FOEI7QwEWW5nPGjEozQLHp3dd2BltIPBtzuqX0b+LLJ6P3GXw6VuB2GwxPYQVgcFNi35GCpCB3PhRN5G6oUWkBDia46r1HbzM+zJDla/t+3tiUVo7wOQJHoBWzt0AndtXHSnWFABlbCzRbFzbL9QE0/qkK55voUFggGhq/ayrRLYL/WWRYfL+PRxl2GBiMym/TrhwkeZYLHNMtjF5Yay6xFK7ZtfHeYWwDm1GSNSWIff2+L7G9ihSrId3z+qfaZCFH6h05fqqOnhkQbcLPn4CmbWMV6fgmpcBCg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <98c6bd43-6dcf-4af8-ba20-c6fa8a349db6@nutanix.com> Date: Mon, 19 Oct 2026 11:09:03 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/27] i8259.c: properly cascade secondary i8259 from primary i8259 To: Peter Maydell Cc: 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 References: <20261016142031.1204281-1-mark.caveayland@nutanix.com> <20261016142031.1204281-20-mark.caveayland@nutanix.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR05CA0197.namprd05.prod.outlook.com (2603:10b6:a03:330::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_|CYYPR02MB9885:EE_ X-MS-Office365-Filtering-Correlation-Id: 386e0e4f-db7a-46d2-156a-08df2dc904a0 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|56012099006|4143699003|10067099003|18002099003|22082099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: UpHjh+CkQzJrMaYbtK/vVaDwZxr3WrUPv7OzevoYnHgkMt8Uoi3ftuyEei1eC/QqtI8Spsda+0I22mblQpWwkjI9Ge4Mt390eI5erKgHNZfFoCKSv/sl42FZqZDy6gYH4nYTrnR2+NEUefmMI5u74/uXAag72Jp/GtLM4wX+17rZyj2I5N0QOmkDIC5Q2gxGd2X931kuvNLTnP4HVehcz54OpXXkB1Jfa/bXxzZHl79ku1ecyXnF0Dds3EdAuf1a26ws08fj7Si+8MktF0MWAR40jcEuRZJNLQRILopgH0WgS0GIxwIaGudsU4rNc6bHEzfSngY8L9X1E8Y1jJucL7DUPDEJuVF8OyRr0RlieabkkljA0VTWxcsjOLyIqhEHifJun4GPaNedGEVETH567LgZZbMKcPTb0YkMCNzLkxRSwaVjCv8/z27hzwTwYdsVzbndvSI0wYtBKjIhuqXtq50tI7V7YLBoPv7SYQIyRzLKZjqRgjVO01EgelHrLD9fvRQKNnA5VLSEgjx6LBDQXJs7Qd5fHlkse9uo/9Ed1VOJrB3IluTS5L09dO+Hd4un0gizjl5kRK7XXT2NVq/qfnwCx1VYVwZ7jtfHMoRLFCkGyLpizpzjsrR44YQi24/38ZJ6sKrelbSFz/ayuzxvPmeXjM2f6kVn5HAyBZYYzNU= 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)(23010399003)(1800799024)(376014)(366016)(56012099006)(4143699003)(10067099003)(18002099003)(22082099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RU1mcFg3STZlcXZLVC9MU291M2VXWUlPdzlHbUFiM0dzL2phR29tbTJYS01z?= =?utf-8?B?aWRjbEUxNlFOUEo3VU5sZVJaMFBBMm95aGxFRWpwUEU3SHoxdjFSclQyakE1?= =?utf-8?B?U0NYZkkwWlJiZC9nZ0F0Mm5adWJOY1MvTzE0d3F4cSs3UHN5UlR2bUFHK1dC?= =?utf-8?B?YnF2VGdnaVlRK0c0enp4Q1dJRGJndkRSV3ZjU0JxRVpiR2NiZlR6VzN2UWYv?= =?utf-8?B?N3JXUnpBQWF4T1RQSm9KdnFOQ25YUldtUmVXYmRETTdZSnpnSlZIbXhvNUth?= =?utf-8?B?dWxQV1B0UmUrVVFpQThkNGdGM2JRcHBoSDUvcDFueUZDUm43WnRkd0ZBeS8z?= =?utf-8?B?QUFJbWdKSUdBK3F0b1RUYkRkaVpnK1JHVEd0bGI5QmNYNHhWMUZNcHlFMTNJ?= =?utf-8?B?c2RxczBOdHhhLy8wbitxZGFORDBMUmF4TTAxZk9CZklSVzJZckJSN0U0eEZ1?= =?utf-8?B?eGZqQlgxYlRJajBOM0VocDc5Q0NlNmtBQUYvSUl5VjVzV2JhTEpJRGtyZW9E?= =?utf-8?B?cW1xOG1aUUJRN1hCUHFIb28xMkJSUklSWk5WaTVpY0pJZGRXVUJSKzNENDd6?= =?utf-8?B?QXlUYWJldit5ajBkYXFGM3VSay9iVWV4bnFneDZpVUYvejVrWnFmVTRFdGM5?= =?utf-8?B?bmRSb2hJdStLa01DQ1Vjb2ZtY25qT3B3ZmFMeVd6Vmo0WUs5ejdYTklVNlRu?= =?utf-8?B?bjBJdGJpaDl2aVY0Mld2S09lY1dlbGVPU1IxdVNmaUVBQ1ZwSHZTTUVCR3Bt?= =?utf-8?B?MFdoTllNYnRHMloyZDJFNGJJeXVST1g0TVR3Nzh2MklGMGhqekhtVUlOZlly?= =?utf-8?B?cUE5b3FPRWVRMGMxRUNQS2FaU25QdEZsb0xtdXQ5U3RpYW5ZVzhuM3BDQ2Ni?= =?utf-8?B?TFhqV3lGQ2Y4UEJVOUJEbXNDZEIyVy9zNDRuVlNkc1Rtc3RHUlVTVFd6dzJk?= =?utf-8?B?V2huWHFWdk1zRXFkbm5yU3pISno3OW9QTHRRSGVYcmdUNkVOMm5PVEFFdE5x?= =?utf-8?B?RGlMV213RVdka2tyd3hvbUp5VUdoa0s2eEt0Unc5c2JEaCt0Szl0WTM5cFEz?= =?utf-8?B?MXJWZmkwS21CZnE3bnE4bjhXZVk0OHp3dUJzWU1mcmNYVUZiR2xmZXg1cXda?= =?utf-8?B?b0JaN0ZJemlXclVkaGwvWDZmZFZFdklCNXdEeUV5d2ZTbmFzN2tRUldCQ1FQ?= =?utf-8?B?TmVrYzlidkVtYkJnMGVtdTNGS05LbTNnaUtyNERVYk11UlhTb2dOV0l1RWpV?= =?utf-8?B?RXc5R1RFeTJYcEs0eWVKVmNUTzRHTnVyQWlZVjFXZkdvUFdMb202VEYxMzRV?= =?utf-8?B?YXZJZnFURHNxWDVKUWEwRUt3dVZnSVVoWFRVZFd3U0w0aHByVW5xR01ld2I0?= =?utf-8?B?L29STTk5MDZTVXM5cytnTFZrcmcveHVkUTl2bkQ4S1hvcHVtM1JzdEhJaFV2?= =?utf-8?B?SzBNUFg0ZVlDN0U3eCtBTk9rb011bi9UMWtUNWYwN1hva0ZFdTdhT1RYTjkz?= =?utf-8?B?QW0vUlNiam9nY0p5K0toZmpXclRXTG1RT01RVXRUUUpDQkFUV2kxL0c3aFZt?= =?utf-8?B?Q2J5YU4zL3o4b05kc3Y3Mm9wUkRRb1dVallDdUd4MDB0c3MxRis1SUdEcURK?= =?utf-8?B?dVRpNWc5QjFQQ05SeDhJQVI5enJYVzRHWlhSS1drazRnK0ZaR2paMmg5NlZH?= =?utf-8?B?WkpEOW5nSGY2VEdvQ2Q5TEthQkFXZVhEbG4rQTYwQjVDellNWnVuMXpyTk03?= =?utf-8?B?aWp6RVFGSmgxS1d0MzhKemVmb0hjMTVKMnZqUVpHdEdta2dTdys1ZktGWFBz?= =?utf-8?B?OXF4SWxQcldmcFZhNlI0QTE2RkJoMFVpcWMvbUtBbldiM1hMeW9EaWJwR25R?= =?utf-8?B?ckZteFhBUmNTWHJraURCa0RwdEx3bExwcVNDN2N2bTgvZHZGZGR2aUpmRnRs?= =?utf-8?B?OVpDb3dPZmtMRTNIaXdRMjNaWndGVFRCOEtCUklscVExOEsxZ0NHSVlkT2lV?= =?utf-8?B?VWdVeWk1OHlDRmpKY05DQ2ZNdE1JUE40dU81bkpDTlJsZWRFZ1l3QnhhSFVE?= =?utf-8?B?MjBPZCtRRzJVZ3d0VGNSN2hFbDRUSTR0emxoWHVpaVppR3FvMXZlNDJpYmJE?= =?utf-8?B?T3ZoOTRMVlhodVZZRXQ0TXpPY2w5Ynd4WGtJWlVLQVo3ajUwOWtaa05peVor?= =?utf-8?B?bWZ3UG9Qc0w5d1dOR3FXUkh5MDZyRUN1eUI0YXdvTEhNaXdpaGMwUW1rN1Fj?= =?utf-8?B?Q211UHpWZWVUQmluL21JVXhCRDlqdTZkK1JBazB4eUNWWURHYlhpdDFDL1dF?= =?utf-8?B?cUF6eW5pZVdTd2RuRzlKbEZHd0E1Vm13cjBxbmZxLzVKSXBibHp0bm9EcVgz?= =?utf-8?Q?A6sVRwr+Vn8Fpz9Y=3D?= X-Exchange-RoutingPolicyChecked: KiDb/WLZGaAtSo6bEZ7aLm2SfoB1n89qbGxuaRIO62PUieXOC7DIuGlSvZR/CG2evlmge+B6OqSE+SqU1Q/7b71xTyda1oTs/LK0ljBdMadBuYlrXo9wGPW/YGHD/BzGnxl5ZPc0rH+NgJB7zebaeX2iZFOT5ZkH9ll4rAxboheqz5ShmEoFSKP9OEJ+apTNrqm86VLuuEtmpXAAsKEvBDGkFb7LZAC4VU0ZKevBA3vuwAQH4EjP3dGThVYVnvwQU302qldXp9r4GyrpeKuJ+OuRjcTOGMW4I4VTzn7YyGsJRXtbPBIUsmYKKN5qhoaSizfvqa4Vz64zwbDSFa1o9Q== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 386e0e4f-db7a-46d2-156a-08df2dc904a0 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 10:09:10.0223 (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: qhYMxIV1KLrzKUNXl3hhp9r/25sj6vEua1rSuQnQ5vxrrd8u08UdyA+lJTjO2/UPzHA3A5/HNvxJtpjelr56a8Y1YqMQHZUM88xEGvWlMhQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR02MB9885 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0MCBTYWx0ZWRfX2rQ0dojWcXc0 ztUMvPTCo67pV8cPD2ZwjYq8qCWWnnWAmoWcP6q/f440ZTze6b0H/F1Or8yzOD54IigqSLjDf5Q rU+4QVPpNnfuD0+x3IbE+xFN8XpcOkvjHC9gOemEmXVBp1U5UbiYt67nv3scSga0xzZ3tCr5TPf gcY3+dWCV29l9WP0UCmAFC/U+4nxQUW4teH+rW4iW3z84TvFFWn/WgvVqxG8iDokZsMAmc+mPuh BCrzXTXSmDjdRl/n+yP0fDCFdlaT5LSvJI9F0WF0+VCgrL8alOolkCQtvwnbgjcolGLG72NmH01 ulTCByH2YR9U0/7mwPx31J3SXk+3Q2JUIukb1bkSDe4pm69P0RUs9CDt0wP0F2TW+YaHo7xT3zR mlV7NVuVxJxPyHSCGs3HJ8V/n4w+tCBdEFJZAcQyuBD1VlkQZkwTQd7bwzn0DSqEtBiPV5JuX+w OD4TmMVtIF9N4FqlKIA== X-Proofpoint-ORIG-GUID: rlpxDy7wfvcgY-NBnwhXC9mxnuLbdpnz X-Authority-Analysis: v=2.4 cv=RI8mjIi+ c=1 sm=1 tr=0 ts=6ad5ec47 cx=c_pps a=zgxwnwFdFZm2O07vxbsARg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=8yAsudsQtBc8yLAMONcA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0MCBTYWx0ZWRfXwXENvl8isCga H96EiBioNPr1mmLSM6Cx6SwaW6z1l9X1JsonoExWC5m2tcg8BrrKwdkaFhAVikM1l7zMlSFVGoO YWLkJsGG1BMiWePTjPqmhcwdGAqaZiI= X-Proofpoint-GUID: rlpxDy7wfvcgY-NBnwhXC9mxnuLbdpnz 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-33051d/1792404562-760FE4E9-FF6753C0/0/0 X-purgate-type: clean X-purgate-size: 3379 On 16/10/2026 17:04, Peter Maydell wrote: > On Fri, 16 Oct 2026 at 15:24, Mark Cave-Ayland > wrote: >> >> 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. >> >> This is a bug fix since in a cascaded configuration on real hardware it is >> possible (although unlikely) that the cascaded input from the secondary i8259 >> can be masked on 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 bfe01067b7..5f90edbe60 100644 >> --- a/hw/intc/i8259.c >> +++ b/hw/intc/i8259.c >> @@ -519,7 +519,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)); > > Looking at this again, I'm not sure how this is a bugfix. > Quoting patch 18, this is the code at this point, just > for context: > > + 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); > + } > > So before this patch, we connect sec_dev's gpio output 0 to > s->pass_irqs[2]. The loop earlier in the code set that up: > s->pass_irqs[i] = qdev_get_gpio_in(pri_dev, i); > > Now we have: > >> + qdev_connect_gpio_out(sec_dev, 0, >> + qdev_get_gpio_in(pri_dev, 2)); > > Isn't that exactly the same thing? > > I think it is indeed a bit clearer to directly grab the > pri_dev input rather than pulling it back out of > pass_irqs[2], but I don't think there's any behaviour > change here. (goes and looks) Indeed, you're right. It seems that during the upstream rebase from my dev branch I accidentally dropped the following hunk: diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 5fde3731ca..d713795ae0 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -504,6 +504,11 @@ static void i8259_pic_realize(DeviceState *dev, Error **errp) } for (i = 0; i < 8; i++) { + /* Cascaded input is not usable */ + if (i == 2) { + continue; + } + s->pass_irqs[i] = qdev_get_gpio_in(pri_dev, i); } Along with removing the isa_pic global, my other plan for the future is to drop the passing of IRQ arrays around the x86 machine so this logic should eventually disappear. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 10:41:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 10:41:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454071.1667553 (Exim 4.92) (envelope-from ) id 1xIkoA-0003bP-El; Mon, 19 Oct 2026 10:41:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454071.1667553; Mon, 19 Oct 2026 10:41: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 1xIkoA-0003bI-Br; Mon, 19 Oct 2026 10:41:34 +0000 Received: by outflank-mailman (input) for mailman id 1454071; Mon, 19 Oct 2026 10:41:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIko8-0003bA-Vg for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 10:41:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIko7-0011Wn-Ri for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:41:31 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5f3d2-2eae-0a2a0a5409dd-0a2a4507e26e-18 for ; Mon, 19 Oct 2026 12:41:31 +0200 Received: from [52.101.83.116] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad5f3db-b4ea-0a2a45070019-34655374eaef-3 for ; Mon, 19 Oct 2026 12:41:31 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by DU2PR03MB10161.eurprd03.prod.outlook.com (2603:10a6:10:49a::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 10:41:23 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 10:41: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=Ckh9JZp3HuYDz9qkxEaEbr0Jscyh76QwLJECNZ14o4OyRrqsum9mH1aPRi53iwOWR/aw9uki+yajprPvhzgaSYziX1Pk4/v6UUhXz0fQQZeK4Vq3dHyxteYn864VIp5Mn8ptabMcQuD19J0Mf14SEqQwIuorW8HIRdz8nSBt4+BmM8kdedMYoniZuf+AtG4zvvHg1TIotJBoEDvHvc6+n7ivxk+IiYjVGae2/s/fsGl9Zb32/yT1r4hzwvHEU96V5DOMOc2GxtcTOgIZLO20SB1kdAG3HOUQEOfV5zaHUQIWdwTxPirT51G3FL5fwejUtQSVCbPt/rt9CB6cU+EX9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AgZc7DRmoJl8SDlcWc+E0yzmzdlMB6ChBn2PXiXvisQ=; b=ymcAOTy/fJOoUhmYZYsnFnLPaqv9zrtqlWcwQ5hoG0TxQ/ayNEFkPTLqde5agTIQyUj6NgzEAFM/vRQVD9d0DwsnTOgjbA3zYOpK4f6WNQ0EuOuc2Dy6tPcRmLFPxVtr2x4ZZ1jjLVmEDsNqVtPM0+WaPpSHlU8Y2x91LGA9KQh94ZOxLve9NoXFDzy6iWYoNTyU/9qRTl826UxqVJpRhvtxTOLmSfTUMsE5KEi/SWfeHjMVK/vZtsP4KzY3JUCVM+jKuWQru4zu8IkQE0eLsDEPOHO8xvzVDv9+uDdQ9ty55T7S+smR1eLu+/eLZRNloL1UgjvPvJXexLZIWMD8LQ== 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=AgZc7DRmoJl8SDlcWc+E0yzmzdlMB6ChBn2PXiXvisQ=; b=eHovzT/anvZHh7F23XYkABAt2xKfvPJ4fmGppL65ouhGmHFeBJVfEoUb7S+ZjOfg2r2p9EcldShrxguXzfg7l0qjmCZleAZpJTwUtzvyuzzqL4NwIxd4G9VI67Vmr7JZpLTjYPsltMqsljd/hHPEwO69MVxn3M0dtkNeO2IiXhW70OYTVqHNWG3pQzbkLruXNRhcljWmQ2kqMGVvtTwjkP4ye9d7JCGaKldurS46AkzXbEpd6n3+Jsr2yHKIMxLG1896XHzEqaQmfsoK6cAWUSslD6e6MyjZvRcK34y0xAVWzfjqernRg0wyYKK4YAEPD6yVK9rePtb250BNfG+H5g== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: [PATCH v2] misra: deviate C library-style functions from Misra C:2012 rule 11.8 Thread-Topic: [PATCH v2] misra: deviate C library-style functions from Misra C:2012 rule 11.8 Thread-Index: AQHdX7Zi+4hiEmHl+0GmwOZnmakMGA== Date: Mon, 19 Oct 2026 10:41:23 +0000 Message-ID: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|DU2PR03MB10161:EE_ x-ms-office365-filtering-correlation-id: e0f6e066-b9e9-4b74-d22c-08df2dcd84e5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|366016|42112799006|1800799024|376014|7416014|6133799003|18002099003|10067099003|3023799007|38070700021|260925021911599003|260925021311599003|260925022911599003|261009223027099003|11063799006|56012099006; x-microsoft-antispam-message-info: ujBhuybGdrMwAHuA+4tp/Iu/LF7oj7XwdlmdfLCfNBgTxZh36kd7Blwv/HuXszaV9Zd0WYDmOeUniD9bGys6h6cEIyZM2/exOcADOZXcp4ml64LvZVaMl8Ub9jU7GmFAMc8GXjAda5VTNiKLcrLbw/1p69ZJ8bvKN737t9NFeVwy7nTgsUSGvfLAAqJyi51VsS2yquQdkvhpdrMwHEPnraKmJJSibCEpw/voKeFlCXt0JoTXTyzZ1rN/nNzTZ272UR4MBhtZW31FggPNbfnqKez0RctclFWP2bkdtu+7dUaAX1IuD+eq5sMdCwC8D/VYKZfOTDwVjZ5Hyi20FfeXyae7xzbCuqKqjM/8GU1pvG6anMDg9lKVVCmZQqi3T8VN4ddcNAqNwTGvy54OPZ7l+MV4nIi9F7v/7mLZCvqZ8b3Ko6/oRlQeJGpe6IPSWRjGcGdG8ct7/OvsRaTy/yWdZJ9KvBW7wpe5IaSSNWlXaZb92sQ0Tvg7bDQD+8RhcTzAz6V5q81P1MN7nCPrnqJIkFl6uRkxsdclaX/79woHN3gA2homUlJqUbUHiXp6HjTMIgQyRXxJQ2+z8HBRcBkDmojwv3rwMROg7VrcMPDeqE5wyeJ/cAr/4qLyrN04bwfhovzRbJSn6wNAnlhq3PfVIZ/PJXkYLw6floOS3pZzgVY= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(42112799006)(1800799024)(376014)(7416014)(6133799003)(18002099003)(10067099003)(3023799007)(38070700021)(260925021911599003)(260925021311599003)(260925022911599003)(261009223027099003)(11063799006)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?go6fMDjxn4xizDGxLkEn62c49ka9096C99uBZ/H1NwdqxkiFjm+P+4R6xv?= =?iso-8859-1?Q?zeye0l7Vk+y4vKpkFc9HMzLLk//wppiIROs/88xtC6BovXsJ5DTl15mmuF?= =?iso-8859-1?Q?0DP4h9DIDB9rZMTIdDaw67hBrjp7aXqqAzsg6rDsGcdnKTCAvUaBpjdFyv?= =?iso-8859-1?Q?r8LQ0D5/QZI5GG1vktRHu/GX4zEOWSSsKZYJjQN3qtSFA03coeSLHapXTv?= =?iso-8859-1?Q?dIdYm/DqY9Z9t0/3mFSqWKLeArWlCM8UI6AQN+Xyyq/LP7zxq54rOE2ETy?= =?iso-8859-1?Q?ylOKTWfwcOeVlME2cSxSD3ZJcoNEOEeP26xSaBKnARXCXHATwrvSj75noB?= =?iso-8859-1?Q?xK4MCkXwG6JM/DMF98XP5vObl+h0qhCkRQxfmSuEXwp6jEJWIyLZoJu9kz?= =?iso-8859-1?Q?RXoapmUy1Xc1zcK/rjgEiDicdFGAMCYLq0jJ7HmTY+mKFDi2/yUhKsLfdM?= =?iso-8859-1?Q?shgFQhWXwSTBDGbv+uej3AcPjfBdfOjFYJMxwFyAsF7bJb9+S93hoV+FFZ?= =?iso-8859-1?Q?el6deiivknpXOAU8PzN76a8CFYcuJDzp6C3HZl2JAKPLnizr5v/bBdP6K9?= =?iso-8859-1?Q?NQUV257GplY0SVe4RjH0d1Q57Z1o4WvoQdITiYB4rukOWToqSsS/eVZ13x?= =?iso-8859-1?Q?s+sTolzHNzRJaIaHijrejBygGQHGtUfxQ1BdBRWvEwM/qZk8SjoHi/a7h5?= =?iso-8859-1?Q?NDOeBN8NpGB3yMUHCNPz09XxSwWU43+Pp0V2eZjBh3Oir/W4xj6TBUQ47F?= =?iso-8859-1?Q?5I8QXJ1Nfq8fwxja99LQQa4wdTNrsM7yhoiLyTYbcJlG1NkiUMOoMUGunU?= =?iso-8859-1?Q?01LC3nC2p36A8S8nkUScQjV9FmDcI+TygZSMCc0DwsB66wSNcGo7B2CaR/?= =?iso-8859-1?Q?CNO/U4yPf9zIq+17eUzdLpJls8TlERryKuTRcfg/iNvGmxtJSpddb6qPu+?= =?iso-8859-1?Q?5kIQWUv/HABJT075iWkTvUQ7iZU/z58/J1PKLkoCBzFhGtC4WLziiaIqhr?= =?iso-8859-1?Q?LjHGqoGQy+MZKvd7mpYCih4ASLTxZySBES2M1B2gx4gM+FlOqYcagUjZI5?= =?iso-8859-1?Q?0oZNAS8/fKUArq8ygtvtFfHbxcgIKgFoKrNlVbb9DkbvyiQTIciCpWBz1L?= =?iso-8859-1?Q?X7TEBISY19P+edwkA1Kgd9U3EqiJZlFsMxOsMG2E4+tKOnzOw6XkS3dokq?= =?iso-8859-1?Q?14CF5cSu7CyAY7BVKRd4QWIz26/H0wolpExLWe0xQNo+hQm4qDZ9DslPva?= =?iso-8859-1?Q?N4rOXgXUlfzYDAaYFXRUNmpkCF7xbU/q05ry8ul745lsWXJZrWjQ/6EPTX?= =?iso-8859-1?Q?yy+za1XeTRhdv3nbfb+VTkFhiret+hDE5mimjBx9PRuwp/OihAOfqrEikH?= =?iso-8859-1?Q?TR9DZouExQ2//crlCaGpr+kFgy6Dycg57gXtsmBtPQX/6XRRU5BJKZTVGV?= =?iso-8859-1?Q?Fz/kGmZSXJWfCmFjD5zoSnK4/rhZinZ6rGLjv0oVyGgo0CbM009dEbrI2M?= =?iso-8859-1?Q?o2UhJc5DShvOD0l98703QSkmJlEoIm5GwJy4DuOVzQTmGvLTmCt0M5p062?= =?iso-8859-1?Q?MCt8aj50pd0Fns6gYSe9umrKuYPNXWsA1KADny/2PL93xtVnxV7j68HZt4?= =?iso-8859-1?Q?ekMBfcp4JZ2qX5ghtxOBHkAKT9Ad+jhuU3Y07jiPN8rVSpIvDVh7kuCmXw?= =?iso-8859-1?Q?d9WMlkT0WpRNCib3MAJ/mgYlSTbgUMpVkmaBNn6Te0x0ybpQlpdvayx2+R?= =?iso-8859-1?Q?c0jRygpRaG+dd/wu7RULYWiL8QohydyFurSuc/Atv1j2MrzIyXDYRBc8fz?= =?iso-8859-1?Q?rsW0xnb73/ZysS/M4lTW22rm9jRsIMg=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0f6e066-b9e9-4b74-d22c-08df2dcd84e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2026 10:41:23.0468 (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: 3J9wF3tCmiDrrlvBg2U3wq1ZZzqtu73kyJDqEkkAenF/wBK1ttb1FknzVuru3oFzxJpTp7RG2l0FiA3t9MRj1O+982shinWCc3rR/aortgs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB10161 X-purgate-ID: tlsNG-ef75cf/1792406491-35CC7AE4-D22EE28F/0/0 X-purgate-type: clean X-purgate-size: 4385 bsearch(), memchr(), strchr(), strpbrk(), strrchr() and strstr() all accept a const pointer/object but return a non-const pointer to the matched element or byte, matching their standard C library interfaces. The casts in these implementations strip const so that callers searching a non-const object get back a mutable pointer. Fixing this would require changing the public API, so document these uses as deviations instead. Update docs/misra/rules.rst to note that this class of double-use library functions is deviated on a per-function basis. Signed-off-by: Dmytro Prokopchuk --- Changes in v2: - dropped memchr_inv() from the deviation (not a standard function) - anchored the file patterns and grouped the xen/lib files, as suggested by Nicola - narrowed the justification to the casts in the function bodies Link to v1: https://patchew.org/Xen/4abcb11ef287170ced74935cbee60c90058c1307.1790671787= .git.dmytro._5Fprokopchuk1@epam.com/ --- automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++ docs/misra/deviations.rst | 9 +++++++++ docs/misra/rules.rst | 6 +++++- 3 files changed, 22 insertions(+), 1 deletion(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/= eclair_analysis/ECLAIR/deviations.ecl index 6cdb10a129..ed8bad0cb0 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -450,6 +450,14 @@ write or not" -config=3DMC3A2.R11.8,reports+=3D{safe,"any_area(any_loc(file(hvm_guestcop= y)&&text(^.*__hvm_copy.*HVMCOPY_to_guest doesn't modify.*$)))"} -doc_end =20 +-doc_begin=3D"Functions bsearch(), memchr(), strchr(), strpbrk(), strrchr(= ) and +strstr() accept a const pointer/object and return a non-const pointer to t= he +matched element or byte, matching their standard C library interfaces. The +casts in these implementations strip const so that a search of a non-const +object yields a mutable pointer. This use is deemed safe." +-config=3DMC3A2.R11.8,reports+=3D{safe,"any_area(any_loc(file(^xen/include= /xen/bsearch\\.h$||^xen/lib/(memchr|strchr|strpbrk|strrchr|strstr)\\.c$)))"= } +-doc_end + -doc_begin=3D"This construct is used to check if the type is scalar, and f= or this purpose the use of 0 as a null pointer constant is deliberate." -config=3DMC3A2.R11.9,reports+=3D{deliberate, "any_area(any_loc(any_exp(ma= cro(^__ACCESS_ONCE$))))" } diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 6bcc2adf95..68de2d8dd1 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -436,6 +436,15 @@ Deviations related to MISRA C:2012 Rules: readability. - Tagged as `safe` for ECLAIR. =20 + * - R11.8 + - Functions bsearch(), memchr(), strchr(), strpbrk(), strrchr() and + strstr() accept a const pointer/object and return a non-const point= er + to the matched element or byte, matching their standard C library + interfaces. The casts in these implementations strip const so that = a + search of a non-const object yields a mutable pointer. This use is + deemed safe. + - Tagged as `safe` for ECLAIR. + * - R11.9 - __ACCESS_ONCE uses an integer, which happens to be zero, as a compile time check. The typecheck uses a cast. The usage of zero or= other diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index a59cf1782e..00378c474e 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -473,7 +473,11 @@ maintainers if you want to suggest a change. * - `Rule 11.8 `_ - Required - A cast shall not remove any const or volatile qualification from th= e type pointed to by a pointer - - + - Some standard C library-style functions are inherently double-use, + accepting a const argument and returning a non-const pointer into + it so that callers searching a non-const object get back a + mutable pointer. The casts that implement this are deviated per + function. =20 * - `Rule 11.9 `_ - Required --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 11:12:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 11:12:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454087.1667571 (Exim 4.92) (envelope-from ) id 1xIlIB-0007w2-1L; Mon, 19 Oct 2026 11:12:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454087.1667571; Mon, 19 Oct 2026 11:12: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 1xIlIA-0007vv-UD; Mon, 19 Oct 2026 11:12:34 +0000 Received: by outflank-mailman (input) for mailman id 1454087; Mon, 19 Oct 2026 11:12:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIlI9-0007jY-TY for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 11:12:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIlI9-00GUuD-AW for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:12:33 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5fb1f-e002-0a2a0a5209dd-0a2a450be786-2 for ; Mon, 19 Oct 2026 13:12:33 +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 6ad5fb1f-b7e8-0a2a450b0019-94a397446978-3 for ; Mon, 19 Oct 2026 13:12:32 +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 69J8QAsv3008534; Mon, 19 Oct 2026 04:12:26 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020120.outbound.protection.outlook.com [52.101.46.120]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc5bpuhn1-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 04:12:26 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DM8PR02MB8005.namprd02.prod.outlook.com (2603:10b6:8:16::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 11:12:25 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 11:12: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=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=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomG uY=; b=OkNTFklttXeuuc5Y3B/pfAAJ8rBl6WsChImyx7mW3yoOmXGUXi0Hj2F4b tlwe5ztGgvKOW5ozWGHqrBlGlGsfVv1U49g4ChaYPBjAIkOUqzHDUR0TaPxrpHuT 0xo9PSZ5NydcNovjZXcVCPO0Z7SKhHbT1hpbA8NXD2CR3+WTX9vurI4NkU7etp+b pWbdWAeDBAEljt/Gf/LWxlms5J7ikorOOCdMcLHUNpCqiMiwkQ2xJfn19qvW8Csf zYxw7nfDXq99uNiT849o9usJ3RNxmS0H9kS0qihj2U+1JLNvKVS+kRB/y4TDAOyi /s8J7UmzLfqHYl/Eoyx6WeR1sk1oQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JhIxYVOUyWmsNfUj2QcXtA2PoMW428UVdgF2cPgkyWoUO7CUN9qQ8/K/XNdE9i6MwZHE8N8alNhBntw5K5w6h+3cvvXjD41nSMBuZ/1HITS4V+jklvgHq9V/mPfWWArEL+Mngv5bAt5D++xNXTyyKAdVoXicOQ/2ok84h7DV+zV7fi8XyscMZxg6ChE0pkBjxjKWwwUXkRPNVVU36kEEtbrFAG+9yUY1R45gsg3Fo3VXP+KLpEuMMXt4puujuYlCvGEksuVYCs29rBMZbsSNz5ASHFwPX22F6X/OVraW7CisgbOvsOOwNEecPNGZ7evwgYbO/wnhB8VTY7epGE83MA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomGuY=; b=mktz/oc4Ya+F8qeu3AMyR6Eqs29NXe4+y50NiVk3I0xl60e/XxKG+9X1GgL3Dhx9wgSzeO9dUZ9v0EWJMjdL0LfzSyPab37DCBO+thBVx/1CKqYzne9yG9CUqOtz8WGcoxsPRguFyoCm5BU8mO8y5rCJPmqFUl4D+l1v8ElkrrAwIRBCP1jM6eO73AtkL+H0QAQWO4oes6skxuZ4J9a3iIhy9+3G7l1ilIiMY7oqguCWlDneCw8ERC1iOC8Edcv9snciBiuvbjpSZ1uQ5yi6DIOC5Z/N1P3MPZBERC3iFJIDgMT0ExeUuhxX6ebv/byML0CXGHPp4rB8YghmQpcSDA== 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=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomGuY=; b=Jv2A32mmAYC8WpP/hGm3PtQp/GMkqIyGRhOmDDy91pRKl0MU2KPnpjqVmT3ybehGwbqk65MGCDfdV2WKSYYg+UiS/KEfVG609xSkk467vNHGVHN25yh9CFAWyAvJsJOjPaZSd+BzuUIQM0ea8pQXJV5ssiY4aSxvokig2g/ytOoimmgVYtnm3ALqLmAyQ8wi0lxLRA73DRh3lrYPW1UUs9Sohs64dIB25SLtyr05+/zoeOkPPVF/5Oo4HMo9Wdj8lvcXBUhbb8l5ukcWzCI+9/dMyVSbQfHbmKyktAQO8ss9eC+44hxtHLDlkc+Ang6FH12wXk0QOeOytkiOEd1dGw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 01/28] i8259_internal.h: rename PIC_COMMON to I8259_COMMON Date: Mon, 19 Oct 2026 12:10:01 +0100 Message-ID: <20261019111218.1429468-2-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019111218.1429468-1-mark.caveayland@nutanix.com> References: <20261019111218.1429468-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR05CA0008.namprd05.prod.outlook.com (2603:10b6:a03:254::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_|DM8PR02MB8005:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e104730-3a7c-4b3d-d9e7-08df2dd1da86 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|261009223027099003|10067099003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: fjOvrM3uD4lgt2ekU8sd+i39c0WSIRWqcSB82ChxRZwkY79dOt0ARb6/B6Te0iAclomYQ5flo41LXiTeI043Gjad0vO8+pZvGENdi38X4GyuVPUSWsI4NZabNvM33ABiuQTicwPKcp1It6UCzke0cTAKv3I6/eSAC73pRYxtsWqNiQG0yHcfZZJNGvoqzSLMpibYfKyISeGu75RYdSIXEAntDqms6PTvG+WE3djksAi93JmQctezlmS5iRw1gIetPlqkPMDp48X1EVIFKftmi9s99ROfH2vrqID8tgvALsFE7Pc4CaF66YKzWt3dYjEKtU47pJlqii2X97Xk1XMVp5+/MJchkN3HUHKvfQqDDxQDAcxpVyY88A69KEso6YZyavFuGigqYCi+Y5GAklAuewkMdbajAZ+QlHNAy2y7eKcr4MEIrcI6Rdra2HBUrw4rtN9prBbnxVtolcQsfYJrmlNaFMhJREZOGpqc7pRl1ScY4YFxjvzsQ7QSWz5BGIuLo9OItbwaKUWs5pxuyYpZB+MWyYLWgqzdNMC1pMBhw5eHy2Ya1pQXwqOkyzkS+o8DaEtRE/XaP8KszQPPif0lHUHsZM8TXG8NvOnJj3LF+lXe0hCRFToXPM6ziJRT2iiKiFwTz8T9hdFwsef5vkjvw/DC/BE/ZWsKU5CyXCJmew0= 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)(261009223027099003)(10067099003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tCzj4PDvdbryf88u1ZufpJjCVeV9XmHyOeK+3EAhxRBe6M33bO0oLbKOifz5?= =?us-ascii?Q?dZwYr9rhpxWCUD5QEiRkKWuG8Zm2djlqYin7fbQGpAgHbDkLuLCBMzs7HjRU?= =?us-ascii?Q?p1xwjyNalENx7LBIURxo7rTltuY5nvDztAmYu953Edi3k8sNcwxSqNBUYSHL?= =?us-ascii?Q?22ebeazcGCavzwuojAYgJUOatm93b73qAuL9NgUpACWK6j6c+j6r7X7Rj6rq?= =?us-ascii?Q?4QdLZEPjj/4ceTKZ19G9FkHEXbSQRUatnvyFhJnljwl5gk3kZaXikjdfGjvN?= =?us-ascii?Q?vfyVdgprChxJ+DzJQh5rDQULVncBEKiwcFc3El+44LBM3N6z9mgRXDY1B84A?= =?us-ascii?Q?GRLPJmVdLd1x+ovON3k4A2cyHTd3Tjt8OP6Gc1h76JkT4KAQdI4yBv8qJCm6?= =?us-ascii?Q?hudTree9PU0GfVKgpGPVYMVJy/e2UvvHA1PQoObGZBfYC4v9/Gt0pkOt0UHq?= =?us-ascii?Q?NQNDfG1LYkvn4V+c+m1leYcQoyFUvzi2sCNWKKt0nVxdvVWzjgfQo1zu58Xu?= =?us-ascii?Q?2NWFdtfeHYteBuK/IXnDhK8HZ+Z77Oc2vvSZ83XwsndPC691HM5sVh1y5Mgx?= =?us-ascii?Q?Gp8kBtMXNerB3+GSR3vfRCKpYkRTTv1qCt3tJYTEeDTZZeoubEbVH8JwMCHH?= =?us-ascii?Q?wwKRiVMklsqTj4YfpN3/gzSLC6YLFaHmHuOhUOD5VmRLUce1t6Ek1CtdSFJB?= =?us-ascii?Q?KGFinO3w9rzD4eOn4oXeajWTFSO5SUOsKCTHV7uPPOnjC1oOmlaTpckBO4tu?= =?us-ascii?Q?bXS4XvAl303kraUkXJuZe4UrVrF/0w5wYaphChO7mX/kGpn6SM1Nbxw77gQ6?= =?us-ascii?Q?q2VLGLtXR68Ra/e4fFRJ/VbnR8sL6Li46t3timbKLiRYmeFMcQRdVhMEma6T?= =?us-ascii?Q?HKksvybCF3yM4rIuID0FW1GMhz+ns3PCSWxld3ojDxV632zmBeVqeeuxi9sF?= =?us-ascii?Q?NJ16+ZM3oLm8Wg37BAR+8JMDyzXZpmYJ0s06Fc/oCegUqED3DA5Fu9nZYyKM?= =?us-ascii?Q?hkP2g2voQgKcjNAr3wTcsysrWtY/hqz9nQOe2+Qm1/X9O04Vzs63G8/UT9uy?= =?us-ascii?Q?Nhpf7TzZbefPclGhXV9PRw1lUD+Pupxqfcf2lDpZjpyQEwvAA3ISOlHi1u3F?= =?us-ascii?Q?T6ZN+oAh1XGLGwajBecaY7Kv3xgBDMM7bTkgB6GzQO+XjNxYBeZA+fRyXAPg?= =?us-ascii?Q?Q5b6e9giPQqvZ2iXQO/ZIaDIpRIrhj0rYbcV1JNqrhtDh8hrfDaqtw3AEbI8?= =?us-ascii?Q?2/ItTQyzAWAptBRoXbp258Idp8H7ONX8B+zbrAr/0Np8jsSFYKaYoW5P1n1W?= =?us-ascii?Q?6mqkeaYoyUgSXfgSrRFHCQ/AT9FFHcN8itGJyo5QfaqVDblcU2goJ0o3WBOu?= =?us-ascii?Q?T6sTTyNq67SxQN9s1RuVWPVyxMZ7T3HTjTDONCtt3ckSmZ9GuD0gNzPaJdiZ?= =?us-ascii?Q?wdV+oipFzj2Xt8ivsxM+mbfOQGoMJkDwL6UlfDxj4YzQIy4UaspcUYjC0/pz?= =?us-ascii?Q?Q+gScE/oxvN3Wjww9jcKpb9RPTwIGpXiANuUJb9CSxFjOHl1u8Ojb8K01PRU?= =?us-ascii?Q?nWJ5FwTp+QD7XGy7FonjnAfT6PZynje5JG1wZabP7AfpjsPI7HWkYmQhNUy/?= =?us-ascii?Q?wUaxWfGv3Vx3744o2Na9AhrlgXK/F2f4uBe/1SK38JTOycOMEYeuxqLnxDo6?= =?us-ascii?Q?Ikifg/XlJibwcdFdyxe4MALUuNv2ObJwBZP7oyTIyO9KvlbNvpauJWLopvy/?= =?us-ascii?Q?YzBwbR7EFDLT9sHELj//Z2fhXkrkoGU=3D?= X-Exchange-RoutingPolicyChecked: k11yPN0vA4bDcsI3sHajRhjwz0JM0KQA6+ZEO+c57MengslHgdUP72OL+GC3QgNtYENeFufOdoMFs6NBpWxxVPXv9SIyI1K8YTnPwHvFLLQnY0oK2ymti/+hdPrvWfFTJS4OFYzxgaHcrVTBMUmUkh82Auom5WVTF0gilFvBYzrn76HCH1eNkq1JxQrj+YKJxRkoVl3iojvSptJVSPLpdJU6EuN5z18F9ZZvTIyeSiSB2wtX5Ks96LYrWqq5oC1nz4HzDMm39xSgU5SeN+RsNPB+nVUajDGOwMWIxVAMW97SJ6/h9TyW5PeHR5uXy/GUuL5rrka5HjjT70HIoLVIVQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e104730-3a7c-4b3d-d9e7-08df2dd1da86 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 11:12:25.0398 (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: LDfRR1XvReOd5pKhNbNCaN1/oiP7TW3NUzJlBmEtE1AWqdnIkV94vrCIU28ovB5lTrTCYr/nJTMMq2ddPt/REWeooiJ170zJ6an9saOyEx4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR02MB8005 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0NCBTYWx0ZWRfX7EVwYBLXynPQ JDpDYSBOon1LpEeW+siqYO7/YePrIt0KFX190tds0ILmfVYz37dg4iQluhIBwJh69470yE3sQNi 6KhT7gfQ3wo8JoNBBCsbKszePMFt5oeP7FW5ETaeVq8hEDQql2GFqJjqIKm5z6Sbn1Y75iUJHnT hqMLSZJz341VYaEZ97E0F1JI5PoIBKA1ahyEahckVFVe7p9A1AITFsegmPrhDjmp4SFvWuAe8Cn 9xFiU8b1uEzWr2C9BT7f3z80bBNpxlEmzm1htFq1PUVTeGM9bxtUFmAQbc4V9bYnavv0ER8zref WfVeDWFpQlr5rT+5URcR0JdyUb7xNxil3L+ls33j8Rw+OoqnHkpAP6NMkwqLagWzroIZ59jq/a3 AP5FeZmgFYcjYz1mC6o5IG0+7THh/HULrxgri0XTSlEdTnu0n/Z113d9tz3f7xXT85TeClxpIB9 QbJiieWkLaVycXWlFkw== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0NCBTYWx0ZWRfX9KTNKqiSc3K0 XeD3IedQLdpEB0yJH8b4WWdb8lepdudj7yTCOJ28TQ/wIiPiCHEwZ+UJ2o6xXMRpLIst5c2Umke YPyBjO4V+rqcSbpyKqfx2twAmp1SFIc= X-Proofpoint-ORIG-GUID: N41GtVKNklzCsrbOtlmAMjv7LBVvMx7O X-Proofpoint-GUID: N41GtVKNklzCsrbOtlmAMjv7LBVvMx7O X-Authority-Analysis: v=2.4 cv=EKeTQFZC c=1 sm=1 tr=0 ts=6ad5fb1a cx=c_pps a=8oFNIrebv7KdPcC3sjE6Hg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=XF9Y1ugsmyLceZbb4BIA:9 a=cvBusfyB2V15izCimMoJ: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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792408353-1B8D19EA-18D58C25/0/0 X-purgate-type: clean X-purgate-size: 6643 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Mon Oct 19 11:12:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 11:12:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454088.1667580 (Exim 4.92) (envelope-from ) id 1xIlIG-00089r-Al; Mon, 19 Oct 2026 11:12:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454088.1667580; Mon, 19 Oct 2026 11:12: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 1xIlIG-00089k-7C; Mon, 19 Oct 2026 11:12:40 +0000 Received: by outflank-mailman (input) for mailman id 1454088; Mon, 19 Oct 2026 11:12:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIlIE-00088q-AX for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 11:12:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIlID-009XD9-NO for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:12:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5fb13-8faa-0a2a0a5109dd-0a2a4501a6b0-42 for ; Mon, 19 Oct 2026 13:12:37 +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 6ad5fb22-5984-0a2a45010019-94a39b0cd8ee-3 for ; Mon, 19 Oct 2026 13:12:35 +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 69J8P0Qg3169761; Mon, 19 Oct 2026 04:12:30 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020080.outbound.protection.outlook.com [52.101.46.80]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc6j5kfaa-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 04:12:30 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DM8PR02MB8005.namprd02.prod.outlook.com (2603:10b6:8:16::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 11:12:28 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 11:12: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=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=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFb Rs=; b=1mVjjHfO1kdlif0MWOWLm5e8ieFQbVcq9pdZAE/D4TA7YUt9Jp+7FXwjq 2L8xjMuLBwLKYfnyUmv3zO3L69+ANdadQS2GEOMhbaMPkqM8OT2yJX2EcDSfnXzI B3pZEiZQRO0xdMSIKtXD8uTszF8phdxO+cFmx+sYMRcMIF90t78aOrhdRtDGLl0G mgTuX4rZJ9BbZTCwjleVhnThakGA6GEJvLJrB2O/0BiO8SgVfuY93Xp2V8bf2WIL l3ASAtLs0rVzZsTaiHpkj8Zi7zRZacJZt8ISYzcvlIOoz4iemf2vdsDwSRCdarUt GX0tq571smBzngzSYW4C6JppECXDQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e/SsbMWCUlxGgPWzKmd+a32DRZyecIB2Nt73tp7rnmXz3gNOEyF8xQc5uWRw5yY0bbMl7yJU0sj5HqoBR3R3WTlg8CaFmAds2kAh6++eRfdV8Up8Dj4dYxA+zM/k82hzJfD2OXU5hADul0SmU3VmaxLfhC2LJ5vI3yCR9POS104QL9Tah8ZAyfzQR56tGy0pTnqV1xaYGjKtfftsbE5oYt9GOwWqf61BhHKGkO7gO0uLEz3XRmu4BW3IxPZmzi7oYYVjjcgSTKFINV0FvsVOSWafnbn+rr6+w0xYq6XYtnPkibyCyyD/nuDZsRanS1DnloUbLwpZS6FnhtA+bhjhtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFbRs=; b=sOJ4pTmO2AUvEzAngHEXXacolHVB9Z+OO8gFVApUz0NvNWc/ERHVSLfbDmaWExlVx0CzPzwMtw7WrfeDQ62awoOyLhzn08k3SQX9gzYlZ55xjxolL5aCZFlEgeNI3iSDtVHLvUD6ueLYeSidBtq0mNOSUApAcu9NC+sWXfmDmwun8F4gO+enAHbbpuKKO6FT1SsfjNqFV2qiQZAwACLTbrBcqdREeDTuKk0rQKr0CfRPgiKu9JXDhyw7IrxRy5m6vGRRBrn1vCjenyFzJgheE6E2iyXAbEj3gkX2DHZ0OWyLIEYv0QGAGOJgODExH8sQ6sxezOkX4gzi/f/WJ/YH8Q== 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=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFbRs=; b=UO8z96Oc3PqBv8UA/Pa8NGGc1GBh2eCnCQRV5UWu2cxjz3v/nEqekwa3EL80pEtgBPykoPWAEYjZul/P3G9Pbt8/59K7kg0GF/BU6A+1styc3pn2X3V9XAOHX9qITZnU8ZQGyrro0CXc5dAnpJV4O5U56sxwA5Cx4YA7kCj+5o+3Z4I9mNPyDC+UOowL0Hmv/iyOSRo1PSpbE7OxLXvJr7hwHFZ3qkEuyAnj7i1k91/E119thtTEDTQVj2mOwLQ46JtpDD9H+kQiyvyz96K9++9+d/kW1keZNcfF2tdmNxXNYlwmQ5kDIOzathryRr+Or/MwRgxv0cA7YNfqbeht+w== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 02/28] i8259_internal.h: rename TYPE_I8259_COMMON to i8259-common Date: Mon, 19 Oct 2026 12:10:02 +0100 Message-ID: <20261019111218.1429468-3-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019111218.1429468-1-mark.caveayland@nutanix.com> References: <20261019111218.1429468-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0092.namprd05.prod.outlook.com (2603:10b6:a03:334::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_|DM8PR02MB8005:EE_ X-MS-Office365-Filtering-Correlation-Id: 5e3bf4bd-0250-4fbb-ffe1-08df2dd1dcd1 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|261009223027099003|10067099003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 2xrAG4AnKtXg/YCQNlw8ziy2mX8C/ZNEwxCwHv0aDoTxqRqsPw8ddTKbkVJFaSgCMjgRLEUdgt032tj+4p6hja4x9SxInOfQNGcqo7E4jglQWOqfHq16ajiCG3puSH0rbvxRq+hR3DxGPpTh9jDyDfkjglurT0TxDY8E6tNMWol+rySh1I8LyFA+bICrWFURJ0IxDt/PSN7wq0FzRVIXO+Cwl9kgwhzFWBJ3Y/0is6N1yfSas3+UaAgK+qOpNp+y2gWe6rOmIZpIAIcNlfQ6K814AjaEQDpJJi19kYAASQlYIVxgh24OR+yldp92BgEoGZUyz6slby+vPKp4ljDYQZi0lA4/f5Y7P+bUB4DdYQlwaHrbw3Op82oqP3MZ2FwYnqy42kCnROX/MEUFt/ALRNfPNRB2FNcPPdaHJ/HFcw338T8RVfTOfslcmjq/SijsLQ+JQgilOt7VHHOvgbBbDHRalRlsUxILoo0Od9MZ5YWLDvngF+RD8wkbl3y/3ZEcwejnZDwTB6Tome+lOenq9C5wc+Ni7XHxOvHHjrKBWsDzoMCscMTL6vXQrlinucSA6YYmArwNiW1XdNqABfnPRcDg4ldGrPl9fPiAx+C6MyesnIRl9nLP+VJoEaSrcqe7VQRMIq50EaiYrOD0EMmqSz/xeKE6CfFDzxfBCC0+yMw= 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)(261009223027099003)(10067099003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Vgrnr+FqSHzaIq6u8kHYUqY3urQQ7ns38snt31Os9Lw7JMAxzmTa2HikGEwQ?= =?us-ascii?Q?McwVx5aCO5O66Us7eISyNoAJHMRNf/M75YEvFfOcKDL/k6Ra48pFWWKCQAtv?= =?us-ascii?Q?nLmPHcc4n+Ija0SxkBWpG6XZK9MThuXcR+F/41dwRQYVloutrlC+CXiC9rGp?= =?us-ascii?Q?DEbg2791ymezBrR8RGf9gkoDSBw+I5j0rABRfG6EMOMv48Nqc1SsiHdd4t5e?= =?us-ascii?Q?rlSPOV9kvppxDxDp74baekyjjsFYPZK3aXwkWYl5h4DHOTAy/uNri83qxhjO?= =?us-ascii?Q?NzLUQ08on5oThxEFeZBm2UX7FHgXrg18ufF0tbX8qeLOE1ZDphuEDFCi7820?= =?us-ascii?Q?iv9xdqZtq3Gq3UYQlPqqTB3nRo/FxGR973IaeaGVKLuBPx5bptwnhip68y7X?= =?us-ascii?Q?kfdX4JHLDxSJN4CKSS6hJ9w2m0HArS2SiGMBPxf9lMcNhBlIjTSrWuoydd9g?= =?us-ascii?Q?LzxW04YFT1NXnSG15eIA/HlqzsdMSZEkMUUM8e2tlfR57Yb3WHP9fZVu84c1?= =?us-ascii?Q?L3x3kxPMoPg8grwk0tDQ9kqZpdXH7C3lQpGn8lM7Cx46mz5ZA8eWKmxPA/RF?= =?us-ascii?Q?Z/K50Bg3jnUKB70cyTLIok+f6o00+PcR1/oX0jGIRdjQngMyB8H/Syi0nCjw?= =?us-ascii?Q?O7n3pk8dXdeqL92bTCCOIteQdML0U59HNMtxFagNsag9XXXsJBVSZRKuEOaq?= =?us-ascii?Q?rzP8itsLw1hsiMwNfBhCw0wb3MzAh0E1hJPZ2avCw7Ir82ABeCEvps9FTDNi?= =?us-ascii?Q?f8jDxm8fQvNXpETgA6l6R2546OyNwLkFO05oQvY18WBT/veoFiF0PIGkcRvm?= =?us-ascii?Q?5Qmi3HFJB180cI+yxg9K+kGAdhciEZ+6OklrN685TlLJNEkPrDNlCioj8ubs?= =?us-ascii?Q?Zna6pAu0O4KbBImiZy1AOWrNSclPfYF+jRypOE6mHMGCRwixU5lJCFcbv5ck?= =?us-ascii?Q?stnJ70uZtgPVPEr8o7Tdc7NRO2R5/maKIVH5PGhSCDLOGt7mq3l1V2U8Uw2F?= =?us-ascii?Q?zyMq99+HNq55YLQQh9AsoV91YiF/9dTgtVZGqx2ifmUW6gZyeI9+KKGc6RGs?= =?us-ascii?Q?KFzAXEw7yW6sLgsuMXTnPPkri7Ufj//UQmiKAD8mt7I/su4oa1CuhMyflzb+?= =?us-ascii?Q?AdWR57DzeFuDR0RpxaEhUjaJQ/ZKOq9+hZC6dr1NcyAdrIzhLy5ANraHt7dv?= =?us-ascii?Q?QWBELFzLVbYrrYbby0xe5XD2Tf+0UnZi+t+MnoALQIBCwe7sg2QkqPuzGQWr?= =?us-ascii?Q?VYR9FX1UycvxTc//yp08FcDyNPdlDCh05ilpc1bS8iZfHLCE78d+sUqKGpcc?= =?us-ascii?Q?Q7hO18bCXtHd9GIKHTfYBuhsCBT66HDFDYHifuP/NzadjOPP4/qVxT6nsNhP?= =?us-ascii?Q?ZIHCqiSrO3k5ruwg546L3eaHWr/nRhWsXmj4Pt9hz10xddtWxG+iuaKDz2Ac?= =?us-ascii?Q?9YzhyTEqsR9TQ+4dL2q5lRLhJBGJD9XA1GGCq2zFsYEeEl5wTPH54J/wKwzX?= =?us-ascii?Q?MnRyvdREsB854GZANa8HJ+aMjY9Tqrx7TQO3AOB9JJz1XIe+AFgV6yxEJtKw?= =?us-ascii?Q?RXwIdzKUu+kYjbomH8V4v/ck0Hyl4pVTZyzV6BOTuv4HPYH+6gmd36lSEPkW?= =?us-ascii?Q?J+9GxfY65Tqq2oPRG0ay5lAxLL196SOBWJDLKO495lIzxSoNdjTrFSGKJXt6?= =?us-ascii?Q?rz0AV1Fimk+6nAu5D0g56n53BCuk4jwnjqykcezqKACcafipXm2WBCSxh+WL?= =?us-ascii?Q?BedlxtehfocPEnz/2sir3Lt4/JCqihE=3D?= X-Exchange-RoutingPolicyChecked: fhdMkg6ZBdI/1XgXPQ1bTRARXem/YuHbdbdN1960C1WoH0eWpowHHGoKlc3fbkxFwRn1YI7yhy5FEgZfCOeW9zRtnA0GKbGUZejAJmKLbhxx4hUneFrQL5TOA2ndlPK42QZt6cFtyr7mJVRSFRn07jbZIfft0fY8vMi1BomwEq+dHlU66U3QNqQOQo/xBbH+1daCCWslhY4NpoNFc/9k0JGEO0mLr9DFYuOBVG1YENMKQsD9+EwZOQ6YXbZJf0Jp42bD/jA+XaC15K8fNkzCtA7S6UFkJRnnHzVCZ88R6hOn8jolQRt11+9isJigmGVH60lZZTSvB91p8pT+oW0eCQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e3bf4bd-0250-4fbb-ffe1-08df2dd1dcd1 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 11:12:28.6621 (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: o2H7OVSzN73JpyY/lpiNqOHIOJE8aydGjvLA5RppCaZLx0G0jyqAPIb+fgTSYnywQXLbDE1kDA6kZuTG02U6R6EYGyBg7CtjQPE3VUuj2Tw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR02MB8005 X-Authority-Analysis: v=2.4 cv=S+NMU4sP c=1 sm=1 tr=0 ts=6ad5fb1e cx=c_pps a=mPoTjFGc+mEQF3C7Fih31Q==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=xWlEjtkXqD840QCPih0A:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0NCBTYWx0ZWRfX1K/niHGfYva9 ZhH/dk7hINkHNPDPHtrHpoSOvKTSK9trYfrVY/A+xz9mq/frFj3Jx4U2Usza8ykeZylbTdK33iq BcES2UJhU1MNuVsixDv/qf7OGc4ikS8= X-Proofpoint-GUID: -P40TlaFi8yvXvvpa0mbHno9VH3iLt1Z X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0NCBTYWx0ZWRfX75+pxrpGZSGs ZnjK8YHfYWKJkyGTU46pr4Gr/HKiaWTUPA4bUVREGgWIwq2UwbHVJvTukuLtHD9jRlmn+o4YSBn kFo6mqRBfVEuLyPH6UgLceyup16PkkPk2/S/xroZFhE9c4AuuLgpNXaij1BKdBnpM6cFJC12lOd DCZShfa22IfhkFOJlr3ywHUgjVE5RxoHw4cEuw1AOHrnCTYeiiIFN+14AiFSNGikDDHaVR6k/4t 1XSsKw+le+GkWr85zobl6+pbQTjNYqIxJWY8AswM1YMDqZDpXW82OmGxihNnmdJZDI9Ox3rbKTF BiARXczEmqsgdPxzNgXQZHtUXVw/0gKVdja/9vkEHwIRt4b7r1pRRv2ZnG1j4Q0mTliB6BjBNBd zPld1FBIpaRsoc8Oa4nLF4TM74sVcwDhAgSKW3dZdPeftzruA5FRLCX6pHdhBlSb/NDQIwRHR6j D94LFBLp04521ltDahg== X-Proofpoint-ORIG-GUID: -P40TlaFi8yvXvvpa0mbHno9VH3iLt1Z 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1792408355-C4D44757-766EA1A7/0/0 X-purgate-type: clean X-purgate-size: 749 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Mon Oct 19 11:12:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 11:12:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454086.1667562 (Exim 4.92) (envelope-from ) id 1xIlI9-0007jg-QE; Mon, 19 Oct 2026 11:12:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454086.1667562; Mon, 19 Oct 2026 11:12: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 1xIlI9-0007jZ-NX; Mon, 19 Oct 2026 11:12:33 +0000 Received: by outflank-mailman (input) for mailman id 1454086; Mon, 19 Oct 2026 11:12:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIlI8-0007jS-Dy for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 11:12:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIlI7-009X9y-Om for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:12:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad5fb18-8faa-0a2a0a5109dd-0a2a4504e37a-30 for ; Mon, 19 Oct 2026 13:12:31 +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 6ad5fb1d-b57f-0a2a45040019-94a3974439f4-3 for ; Mon, 19 Oct 2026 13:12:30 +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 69J8QT5G3199248; Mon, 19 Oct 2026 04:12:25 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020103.outbound.protection.outlook.com [52.101.46.103]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc83eucb5-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 04:12:25 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DM8PR02MB8005.namprd02.prod.outlook.com (2603:10b6:8:16::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 11:12: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 11:12: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: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=LWqo4vu2Fg3/F WqYAXVyT0K7RwagwASf7xvte1oCHLw=; b=ueRxoakK/QJDy7w6zxsVE5/2QsFCG KgHcYWDJ6O4peuVoF1XTXUPRCDIHz5wBJ0TRmStJO7FKxdAks3BQRonHeVODbEnH AAduOGEk8ekTW9/gH5wMnH4IbQxE1fOyoZDMu7usgg6ZHnU04NECVQvFcmxM72Df GpTTJVhj2fXdjGdY0q+6JGzA75DRxqKd2zhlpAEL1Ap1s8r3ofYUp4OQxqxIR8oE MxIRt99jvtNrpW88o7p/dl8Vby1fHYRyCwqmGQfgtB0tZkybS5aUrVZCyuM5hSgG mOltQR5+A6yfPIyKYQhO6x46bIUYKDTi+AT0bg4Fs+TON52fOV/QBUXJg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fNAUSGxcUnMeQNIZmFFzx1+f1udOuKwmJIuzz+qv3TCa7+xA4B1HusjAIsGQotuw+x/z/vNMJVUmoCmN0R5zyZgumlh88H5BqV8H/W2zM+YBdy6D8YoX4/Ef304rUVe3eSEE0PfbhbMGmqS05QQgjeBUvogSll9v+MU7R1aJ1jXM/t42K/HbNpYUaqoR4QKPvbW7auVPGqwJetpRqMr49lMAQHAYux9hjBpyAy9On7yPhO+OjY/wScxd2JlFf41OLg8LWDwpN1a4EfACx5F57idJU7dlDLzXbqTmLNFSbiR3piYmYllU6mbCVzEvSMDjKxI401TG4LYvcqUPdqWZ1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LWqo4vu2Fg3/FWqYAXVyT0K7RwagwASf7xvte1oCHLw=; b=FS7y3P0qhXOXX5apTNAFFCa4D/tp+rsgVWZ+StfZ5qXmi2Piq+0l3rNaH9MgvNCFlDylsLJbSN631WMFuog/2zOWIfOKEl2uEASVwkq2Ja2BKkbmMRwZqQK6MmumGRFst/ROk0JWxrIJyd3Odp//F9lLNzVc/g4mtO1Bbk4omKenUO7Rru7A/v079C5+wWwmzg2TiyPvlgcNJH4/mK9g4llfm2vaL5w8LH84o5+/9KPbFHcZKrOs2G91oiEMYzDw83ewZW0d3waj8nrTldA2i4xtykEvwouVJ5bXVEQDi9sVBdEHe3GPJuov8cOo6B6TUuV9/L2cexuB6EKINvCJnA== 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=LWqo4vu2Fg3/FWqYAXVyT0K7RwagwASf7xvte1oCHLw=; b=gg/nJMnp6ptd+Sv8aGjKXF9rZMI5LfstWO6ZzUe4TcqoPnU2tVU891da80NCWEGmUCU8mEcgnSnCKLQWHJ/wXVffy8Y/tgYnhAB/6IbMIKyIK0oCuH351OIHYU6RoVoWtNNzB8/690TYeGlWoy1unchiFons7oQDfrCRjWX75zhsZVBeavrmZKJFbJipFpFalF7I0fmKr8FeqDfHE7FCk/gDavdlTYA0DULOcuEmYKKFAK9rv2gVHoQlVfHdIgPSV1UH/Zn8dh0q0wH/soR1OuXKCi94fdUXyliRG4VEBqAmuK4YwGIFJCD4ihjei/xV9GNRzFJ4SC0TL4x3NfoooQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 00/28] i8259: improve qdev PIC modelling (and misc fixes) Date: Mon, 19 Oct 2026 12:10:00 +0100 Message-ID: <20261019111218.1429468-1-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0134.namprd03.prod.outlook.com (2603:10b6:a03:33c::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_|DM8PR02MB8005:EE_ X-MS-Office365-Filtering-Correlation-Id: 17602d04-1b08-4c5c-d891-08df2dd1d875 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|261009223027099003|10067099003|56012099006|3023799007|6133799003|18002099003; X-Microsoft-Antispam-Message-Info: R9uoGoMANpvP88Yw44WjqOdlG4YyRZxSmkmvoJSk9wdUSCnNwIerOoHM5ZTIrOBZaDjp0cLfckdYPaMa9Hk+QPwU/Y0Nz2nb/T/j8BrHy+4z2TndC7rK8hfOR+gu96gn1QP6Gis9P8wnstuq0dLZoULOucZDfrrcO0fbZibrHg4e+5AdWHjCGX45p7osWy8t0wVdDlxn2nOhDIb9AO5E6QT8rCL6KjBZSYFxCyx9VdBibPh5JDfx7uKEFIU6xXv/a9FIthETofzH7USfmmTcDufyfzJkswASycuHny6ElalNU2B9MlvIBCX8dfLmeCx7F84rjMCvPf/UWl2a9F0AXS7A03lOhB8ML7Ex6R6/Y4oHGLr7noKxNJInqvmqu+/W+QCkMOJKeb90s7/vL6h9X3fL5XsfdKdMqCMqbr9Q/Y6Edf79W9l+kVEZe4HomEEfKsqR4WLXPczHKhXFnOBVXjtEYMKZuZIibxf2SrlUZ282DHDxJdKflvr521QTZSp14qOrCM9a0fTX3sc9mD8NYYB3mQckkLYWifRB6K0SQO13zGyOfg6fP8gGpsylnOxQs2MLd5CitXPVmDrc1oF50SvIyERjdJX8r8AmAPgWkl4eDDhQgcZbRFsB0I7Kf5tb6kvD2cpmjDm2s/tsMxA0QaaQNPe6GSyX+9sxpvoVcP4= 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)(261009223027099003)(10067099003)(56012099006)(3023799007)(6133799003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?D63ybuBuexVMfTGeSK96d8sST/NPVFrzFjZCZZBsI22kCt7FqVBIvWTT09at?= =?us-ascii?Q?OMAj/HxEbnFvAvCQhmAqCH1TU/5S8ZC5d8GYaL3YdR9EYUULLftYfm9h66La?= =?us-ascii?Q?2YXI79z3WC53FSiiSwL3O1WsTDJV97u4Uc7BxxbxQ8/qxM/d9yRWvo8EXeDc?= =?us-ascii?Q?OVfmR131ws0+1tIPMQYXu1cqGx2cKQn3iysfJRiXrl1a9BRKKnOCR5921CH9?= =?us-ascii?Q?jI35lgyG1htCBUPuCOk20fundTNbvzqwODEokDNJCNzbvetff0vnQiR8ytGr?= =?us-ascii?Q?fxUTKZKesT6iY9uhleWXqZHe6BV9PS0wXj0yJoelzHoj5gURxh7WNKOlLR/+?= =?us-ascii?Q?l9B8XXFKyMifrU31lMN3P2KicVeq4NxKJ4vIfqdAhh4dIeR9QXA/Xo3euwPl?= =?us-ascii?Q?P39pZwzIVxOVMFkHuRi/E5pM9P7azVVqtxvvGvUC0gRLKpKZ6Z8VQfbKWZgT?= =?us-ascii?Q?tTt5PPc4mCX/WSs6+sTpBgNbz7GXqnRM5jJ/2UMCGzGKuY3WH+r+nLEMJ1Ad?= =?us-ascii?Q?g3FzCZptsiVgckI8pq1tTuMsmhCOrSxnJfLiMA/mjOCt5m7PU4Lj5k7sVGMU?= =?us-ascii?Q?HCnv/wqGkv8Uxsklxr5Adlxb4B2vgna9SCEzPrximtW0/wi3M53znFbUE41g?= =?us-ascii?Q?kefj+vN64B9wLr3xjgkGflcbCbZYK9EBFguiC3KdhkHNlXhVmiMvi1I3hS6/?= =?us-ascii?Q?yZt7GCsOqY/UWurK5nu5ghee4zXi2Obk9kWyL6nMRqqU7T5NHee9JQUpug9M?= =?us-ascii?Q?b2c25TaG0Otgu8IuRU07N1dfvRRGi9vR9Uec/W+oFNTRcs76fKSNfYHU0R4t?= =?us-ascii?Q?4/+DXUMRaXQVJaM5MEoAoUeWMqj1lPh2jlTNDcLULwuFRFeX6gqC/07RppdU?= =?us-ascii?Q?sVCLIUxsvQmNnhD3IYmsIOMmrH4dSiuoI8JmLRG39nCtLpQoWl4CR9aKVj5U?= =?us-ascii?Q?sOnTGqOeRN6HJB4aXl4k67NiMKUYMK9r8lt37MLCCt/9yZthfCazDEQYDV/W?= =?us-ascii?Q?PMLlc9jBxYWCqKYLWfUBqCdoQwygyOaAGTC0lqZpHrUnmusSMW3R0+MGw95C?= =?us-ascii?Q?ZZlXldhP/iQkdErNZxU3jWMbUDU1d5VQugD5ZOcC6zd99/sDVhGw9owJ24Ie?= =?us-ascii?Q?9gq1kUhX+wPe7o2XQO/A0PzUoIwVMuq6c8XEyip9nUXwxqOg0sgK5WSo2shh?= =?us-ascii?Q?WzyK9aJBa0Ys3WKF32xwZd2ByezwxnlevbA4Qf5eqm/5Iiif0tbn6AGPkOSh?= =?us-ascii?Q?8nUSWZFdRv43oAU/LOt7zWGG5znltlWZAJmjoqhI1u6k5HpmTLLViss1SWSx?= =?us-ascii?Q?EM3ow4CJyoBPyPWt8yyoIwnlq7yRggycS+IcX+XMi50JJEt++MeB8qY+hOud?= =?us-ascii?Q?8Qx/Doaw3mEV1hdtrQ/o+Z1T8GLqDPWoBgxc6RLbBrYums0BOkJ10eTQiwH3?= =?us-ascii?Q?t2TDvDhiPi9hkAs2MYVAOhnQ1KJWnw4Tw+9Yf81z6m3aoDeoZ8P/3+/5OnbG?= =?us-ascii?Q?LxGHEMbLFK3tLUXu54Dud+Yg+4YoDyHLoEndrKOV3oSDzT/bk1G9alBDjlRm?= =?us-ascii?Q?+5sCaI9rx4cqJqVZIksUhPl1bqiSpD7RdermPqXrGzbpQYMzscD+4RQpABTH?= =?us-ascii?Q?yXC/vnAANdiroooN+XwC68kgSd8UfbtLTYCBmECAN6dQY08ebNBgOVmCCCJn?= =?us-ascii?Q?i/cZFls+yrd7XPmJ5XrKXQemaT1fcli6Do0GtRW4lsKMvuhTNXf51oB774iQ?= =?us-ascii?Q?pi1PnwyhMlms5l7ds1wnEpRmHKHUFXU=3D?= X-Exchange-RoutingPolicyChecked: HXZ0m9kjkrNJ+1wObIAcZ+1qNYWYDwYx5X4hUAPvMa4lwRz/wQb+Ql/7HOl0uaHbw0WZhcY7V1RReu348r+n0wLEqUWaoDHqgUqg0r4tc1s3P/+76bmxKq0HfXNSMuY88wtRX4uDVWb6yGDYS1k02S1qZGv5jqtqV1YZKZXuaUauDhZJgqeQ/JDGU0UZYCz2MMmBaE1HnIFF5S1ko0XbCr6Ksg8y5uucizJFXASKynLNjtjpCCvGXA4WYIu7ALS0XsTv2C1L4CQ/MyMTNtowMD6Ve4mh+aTXB8DiewRsTXO2eayIKyoS901wp75Hx26+OpvGbsrmrNDMYr8sxx6Jlg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17602d04-1b08-4c5c-d891-08df2dd1d875 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 11:12:21.5028 (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: IV0pZLRcNU00UrhDMjss/dtKuNg8127Xrmq6N15BumnfmJEpn8s7dDtVSfnzX/CdvPCMcwL20PkVKMza8pSIVUWVHFwgePYi/Yn0owFSw1k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR02MB8005 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0NCBTYWx0ZWRfX8oxvd8A3BYJ3 HzswaH8CXvxsGfOKdF09PzyEvExiHNFjQp/FFlDfhBOll7ri/ZFei84vkrZSeF4QqC9pIiPM1pB H5VDsB8iSePNyaA2nHVDZ6pMAh4dvBsrA/wXL1tdanIHmPC2J1HfAGXK+wAcht302qcfoRzbIV0 TDHCuYGo2JFLwETf6/cffzefAnVSzcJcpl/SLVMa6o6azznUftEZUAQOHt0TwIKEL668lQFmZlA OKe5Ibb3EHnzepL6g+drv78mZI/dOkg+nhKxGOwojk0Nf7mWXx/1dpoePoSRGU72HJDCyFD+6s8 IKNLDyLIjQdJYUpHHLH5Iujreg2lfeBpATqpW1N6yzFtqWcM3UAfTqA0oWw9ei9/dtO9ja7G90l GHsWZ6lz0U64g/8jdmaQv1rXdLCxbWpWBqMuM6WFfbE6fDEWG0oFst7hAh2YN7QdwdmrdG3E98+ mUCgdbz/MJY+c0u4ldg== X-Proofpoint-ORIG-GUID: UAYemdk3Ep7gHFtP9oUin9-mwWlaPQam X-Authority-Analysis: v=2.4 cv=RI8mjIi+ c=1 sm=1 tr=0 ts=6ad5fb19 cx=c_pps a=85R27yqqIDOPhBwKPsrjTg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=BA409LxbDWUx7DgykJgA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0NCBTYWx0ZWRfX4t+qBHc3TPLo oeV+fNn8xka8PX+lElxZ4HeWGprI235IEp7Of23zPqkKZPb8n+lnekm83ptzV5zvicbFlcV+ecT GEeRCsM5TWQjDWrwZBGHrNdI2S1uH8U= X-Proofpoint-GUID: UAYemdk3Ep7gHFtP9oUin9-mwWlaPQam 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792408351-516D2B50-34E0186D/0/0 X-purgate-type: clean X-purgate-size: 4301 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 25). Signed-off-by: Mark Cave-Ayland [Patches still requiring review: 18-21, 23] v3: - Rebase onto master - Add R-B tags from Peter - Introduce isa_realize() function in patch 18 and use it in patches 19 and 21 to fix refcounting for ISA devices within the PIC container device - Don't pass input IRQ 2 from the primary PIC when implementing the cascaded PIC configuration in patch 20 v2: - Rebase onto master - Add R-B tags from Peter - Remove FIXME from commit message and rename trace event in patch 13 - Introduce a separate I8259State for TYPE_I8259 and KVMI8259State for TYPE_KVM_I8259 as suggested by Peter - Keep but rename the associated classes for TYPE_I8259 and TYPE_KVM_I8259 and move the DeviceRealize function into each one, instead of keeping it in the parent class - Add patches to make variable names consistent when accessing I8259CommonState from child objects - Update the comment on patch 19 to reflect that implementing the cascaded secondary is actually a bugfix Mark Cave-Ayland (28): 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: rename PICClass to I8259Class i8259.c: introduce TYPE_I8259 device i8259.c: always use cs for I8259CommonState variables kvm/i8259.c: rename KVMPICClass to KVMI8259Class kvm/i8259.c: introduce TYPE_KVM_I8259 device kvm/i8259.c: always use cs for I8259CommonState variables i8259_common.c: always use cs for I8259CommonState variables 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 isa-bus.c: introduce isa_realize() function 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 I8259State 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 | 11 +- include/hw/isa/i8259_internal.h | 19 +- include/hw/isa/isa.h | 1 + include/hw/xen/xen.h | 2 +- hw/i386/kvm/i8259.c | 250 ++++++++++++----- hw/i386/pc.c | 2 +- hw/i386/xen/xen-hvm.c | 40 ++- hw/intc/i8259.c | 470 ++++++++++++++++++++------------ hw/intc/i8259_common.c | 225 +++++++-------- hw/isa/isa-bus.c | 5 + stubs/xen-hw-stub.c | 2 +- hw/intc/trace-events | 8 +- 12 files changed, 648 insertions(+), 387 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:05:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454122.1667594 (Exim 4.92) (envelope-from ) id 1xIm7S-0007Hc-4l; Mon, 19 Oct 2026 12:05:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454122.1667594; Mon, 19 Oct 2026 12:05: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 1xIm7S-0007HT-0H; Mon, 19 Oct 2026 12:05:34 +0000 Received: by outflank-mailman (input) for mailman id 1454122; Mon, 19 Oct 2026 12:05:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7P-0007HH-Je for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7O-00EDjg-GQ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:30 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad60775-e002-0a2a0a5209dd-0a2a450ab372-44 for ; Mon, 19 Oct 2026 14:05:29 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad60788-f2d2-0a2a450a0019-94a39b0c37fc-3 for ; Mon, 19 Oct 2026 14:05:29 +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 69J8OmWv1634637; Mon, 19 Oct 2026 05:05:24 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020079.outbound.protection.outlook.com [52.101.46.79]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8bckg8u-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:24 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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: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=LWqo4vu2Fg3/F WqYAXVyT0K7RwagwASf7xvte1oCHLw=; b=1PRPyTpkJWzcLIZhxVLc5NUeXh44y 16UwZFfYPqHbZdlivEdxo6ACaDmFee7NScf+ExbKQoIRiPCq/6Yd1CumEYnH5yeq 2UYk3CrKhxRVoSpkR5qqatBTfm9sCQHzwmJW0CHfCraPKem9p44/6I9lN+3pi7FA irY01k79+d5WybaVXI7KixE9bbbes/2V6xUmgoYqqlJpSgjrT80/Ae8ByvugsKU0 h755lYRdFOoVRslq0MeLY6AnEI4lZBNKPRZNcChoxR5oAA95tId2xEVh/wqa8FEe e2LVSr3NOdq5yLJUR4SPQJ0HeJFuLM/D3mm7D+GR5PaMqb+DKDnRgCRZg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=C6HvTu7yxQdCQtlNjujuU3McjYVKVQlJH9xlxe8A2rh/46M8VV2QpMPcLHm2mClu1CG+9ImOlkoSUt6vV3m+6D8FrV3T50gH7lKahLAORtHudQ0NcHZ4+AHaR9Z5imkY7u7vsYQ+OlRa/3KQe+6oXR2aoOxO3mbRMv9wOIgjTx+kfwZXR8pGsoGrTIagH/jVM0165ADqnVLLZ5kYNRdxzDusVC5oMcGnUd0djDU7mrqIh7FIEO01hEzzwwHajFfPmX+WmLLjuHDejcatBFEvL/kNkLWIl4lBNBKlkfvi4CoyOx97xdHLxzjinWg00kdZJUrU+SAD3nxNeuKQjwcB0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LWqo4vu2Fg3/FWqYAXVyT0K7RwagwASf7xvte1oCHLw=; b=W92iidrwes70gVoTtTWXoeMUbIbL3K1UqJ+njIZruTrkOclEgA0VR68x6AVVQNt1oxfZzk9a0wLsyyf2EZIy7nLirPAz0ELU5gAp/qoF0Pd8tX8hoSA3oPstHHQE6r5t9nsKPDBQUhB/xLtnIgfmAqLXsTp2QZ5Szj5ZPaAE9reaXb6+nYds4btcVW6ycoYgv+/eJ3QS+Uyp4V3gckGdyBEMHqe5/dzV22KOn8o7dJ4GBecjVAHzF74C2/s4y3t3m13UmcQtC2Eo6xZ/iKgM/IWiEwjhQUMvNqLSkICiGbcbNCEi/AVZXLgJMYilrh6h5kEWjXL1n9X1pEPeNA1ozg== 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=LWqo4vu2Fg3/FWqYAXVyT0K7RwagwASf7xvte1oCHLw=; b=iGjY5S7VCGpUw1jeTbcZj9cANAVQ3qFk9mo1oPqXFJAEAZZMYqKMnIKc1rfSsJnWEzNqLOjAKZeewULVWANs6ehoMmMta5wLHa9mAeJ3zltGzh5VBo7+jA9sWQvFpDzf1DE6xal1/sEEMMOqZm22o4TRt6uxJFO4z8VXvNPeUK9mESG/jF5sFA9fjzr00l5WuWekLOU/0qCMZ/Mlj+bOxO+oMQF8C0H66nLMCZ23fgiZBXk3Mp2/F9Q/wqaLxjJ14P4YwlkZCyayoA4ImDH0YhXQTU4CDDQvkPiyqDkqPKuZEhK3zihEVIMtuuwm7TUDtSnPj6YLcLJ6DRL4JwEFqA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 00/28] i8259: improve qdev PIC modelling (and misc fixes) Date: Mon, 19 Oct 2026 13:04:32 +0100 Message-ID: <20261019120517.1448687-1-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BYAPR21CA0012.namprd21.prod.outlook.com (2603:10b6:a03:114::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: ec9cea2e-1818-49d3-c2cc-08df2dd93ffe x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|18002099003|3023799007|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: /d193rn4EWwLdOPl6e1VsvnGeQQT9UB0xwQFxicPQOw+8BIWuZM7y4ZMdTLyarZKDX1eQ+coBKKiu9TIVrHo3TR0kvOCOa2L16BMOZZU3/ZIquaUUAiw1YDxloFZ6Z14TDVcp+3aVjkRruui/SjSkiF0Cm32aNmM/hKXZG31i66CMybHYbGpDTg55RKCHMstQrkG8NbIyFN/j2PPrzYaz2eyQX7xYmLEf4NzQDOPYS01eHnzJckHuYWdwk+IP1FDZn8GZZv8UcOb3pd0cRE6XAoQ24dwzkWZyFaD0RryUO08pWsTdi6B4p6lLx+VM5eQ4+kUYj1322MOopaoHeAPGl6nTmi4OYY0WQgKcTyNLYePXTZBzoWGDjDH2GNNC0oQfPwMQCHmNV+Iu+iD6xI2euIzTQ2OFrQTxKZHAvlJI0K90lSUSeoTDeu3ML640gU/TBrjff+loJqJ85nlJhKF71yHYM8E4dThwVYO5V2wSxNd5ejX+uyUwgwLlXakJCxDvb/AGnk+vltcXwCja9n9Wa+vs9EK1F3afTK1t45iSQ5OTab52KsnTdoMacJ31bd/oCqWlfuGIDrAodOSe73Vxea/QzET64GX+lphmkRbM297U4HgfjoNrcZ60qSFX4nBQrZBDyUMDgLjR1guP9imWvMHaGI3p1AFbBC2JcgBnbY= 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)(376014)(23010399003)(1800799024)(366016)(6133799003)(18002099003)(3023799007)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sffL8BzqfDEGw6j+6OMironjqIPVZvnLlfFzhCz2idfrDtzmtyaOxF9bTver?= =?us-ascii?Q?nzWJWDPtOkNnCAhrW+xBhaz8ErAbWIisNCFS7PFHiurKQD1JUvi+Cb8Mypt+?= =?us-ascii?Q?31hGtXgAV+jfc+M77ybI7iUdhi5b2dVYEkAMfFL3tLjny8goERaKz6cVOs+m?= =?us-ascii?Q?8b9taABXpoCE0WZUeQhpgltNecEZuavdiA2vb+9CzjnevQLlpfTGmufWi9mg?= =?us-ascii?Q?4xRqKmp3zTQ7yhisPY/6nyhPsnCbsnRxGSYpeO5ZeJLPzpuCSXADhWRXD9XI?= =?us-ascii?Q?y1gb5CfTQJnkzMVVKZUUp2leZ9SFX/uVjkm7t8bxvf4tZ/ZcBWadPKpfviH4?= =?us-ascii?Q?8Q9yiokucLqzzUFDiRHJBzJqPRnwS5UIGcMMrbhzH+/YPsFHhWLAzzgD2scx?= =?us-ascii?Q?RSQ8/MYyd0+RRujkRFLNEPi2evYklG3xFGO/dz9/1S65JvFRTOLkz29j3REL?= =?us-ascii?Q?wBD43JhLeZaTDB2F3+xD4LWb6RHlMkGF8Yw3WVhRYv82TEpDszn5vf7bBnJs?= =?us-ascii?Q?jFIwSMCln+Z+gB6F/l/AecV00LG1zCLh4pFekHV7wFOaAIOgN2HJ+7kIHNNt?= =?us-ascii?Q?fRuLM6sdjq+kcaeiNtqLIs64SjWC6m4hFWHXrCAkzrQ/zkhFyHzKGw8wxCgH?= =?us-ascii?Q?MpsO8FfI6EdK9Rb6mqQJ45xBFnem6t31ltFsopR3gbsdG+qzGYY5kk0ZxOxn?= =?us-ascii?Q?Y8TIiCm/9mvRFg7n8+W1Wc2ScrM7fHPlaZM8Kn5+0YFHVRrD7XCr0GqNLUQW?= =?us-ascii?Q?vOss9armeR+Ke27tYjqolnceOLB2yILiYzIZ8hQzoVMnOs2tQX0wK/YEbWgh?= =?us-ascii?Q?XReFIWGkeY4+o/t5B+13OXJNkbcyf249kQXhonR8IN1YgYKuQmR36VvPGhQ4?= =?us-ascii?Q?LNaBwBcUQeG2jUM9Pzf1p8dwO019ZOZ+qtWP5KnVJ+LwFegupjwatDzMfUg6?= =?us-ascii?Q?VXLcRlZLk5uaemZ0g+5dk0zBbdFCjeqDskeZoQRjYNa2Yh9c7Qv6S7b//4oH?= =?us-ascii?Q?8gfuiE4W1onAOTKvqR1RUqPZffbVMW0BB3DMNyM1JoBFMyv+Ssv8MRhG87qD?= =?us-ascii?Q?pbJbYlny6qs98sGQVVjrZEnc1aV0hWNEvlHtStHjL9WTbQVhb7wBuaDfy/al?= =?us-ascii?Q?aJBnIoXoWrzYJvXZfezssnww3FHKC6DC7PxRDYUBho2FP9HhcFhzCX/9hvKV?= =?us-ascii?Q?kP8hfi/3H2qIToPeHydiE8uFXSsr7AVrClW4aCJPdee+rnyb8V8+o7cA3+Fc?= =?us-ascii?Q?4Ae+Po7AyP0qErCBDqmNLHAk/NI1KZiIm/Uifwbd7oo7vxceWDspn/qz3zto?= =?us-ascii?Q?8+lQaHk1OQEHJv0qIoj/KxrOxLOdoyHouSmbZoCbuQ3tsdRYmoC/74t9C/Ve?= =?us-ascii?Q?1YZtl4QQruKA8EfW+y3XMloZemDqIYMDqsa3Py1vUyarz5D8N5WgrLYgXKSN?= =?us-ascii?Q?tW8RZ8cb552LBaliJljWLEeY/KxE5CqJXmc6pd4s9oBqi2Gj1c9cXvbTDOb+?= =?us-ascii?Q?WGJvBvPSjgTc28IATr1P69f9OLt5JVz2+EAD/LuKU+8kNveRhRVWGd+voj54?= =?us-ascii?Q?kXz62S4KQJtyDfRwsKEVr1UMQpBiM1mxY5ns4NKMcefEF1SK16wI1V1Ig3k0?= =?us-ascii?Q?gH30CmjhlCvMpTcG2HKBmjbNCQT0pPTfJFFcpZwNUF6RTUFuCgghmcXbcM5L?= =?us-ascii?Q?hZaTfEC4+oDeavQF9kqGXlmGN0DEQMVopSAkdF9tTLpPpZaYJRhnsweB8h1o?= =?us-ascii?Q?irxeUCcirKToPLEDF++HPKLhPEJN478=3D?= X-Exchange-RoutingPolicyChecked: QJ7reNk0AabXDQBZLW8iKVe2wybcFgQOlNrwBPOd20uH75sPpD6cFLNNBHraJ4lMK0LbUy6tnJA0SaKzPyuK/lQ2+zlW3mRa+3eyDlym8MmD6IkSxQx3EOin+8FhnXHEiijR+s2WzmZbtuGCpOPyW0BfgvaJIPAasjSL8jLdOGJZrIWK7Cyl/8SN9eKw7lL/HxXmI+SdIRfJMOUa2jHlfIvwwiEQcjRE1BNJMwMtABO6zACllgFO1eDeDQQzXv60CY+Jvs+lq6hrLd26g4nMeLA+0nx/iM95gyAsZ6IHj3vwjC7EM72GzAljrepL3+u4cC0Jp5C1de1EorMqWEx4WA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec9cea2e-1818-49d3-c2cc-08df2dd93ffe X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:21.6975 (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: qZZS46j0PzGGKM7A+V3um/Pu1A8SX7f4SQb6L9odgcJorz00OhJBl3qBxIA/EfHtOwtpkS+a7J3sBOAxpWDJH111CqShc7BJQCgxo9XnpCc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX13VxlJNhKCr9 JtmFtXWzclgoAEGL1XfGIVqmnP571j1noJ5BOtw+Gs6pWfCZskd2y8l77oPgW3qjHiGstzEwtr7 3JHDlGzxv4+iViGG1qhc3CdAnL718Go= X-Proofpoint-GUID: Hei_VvocpQe0tWp3NZPFWYJDaGRDJ8ch X-Authority-Analysis: v=2.4 cv=V8joQuni c=1 sm=1 tr=0 ts=6ad60784 cx=c_pps a=8R92SGvJzS8WgIKP7Y8NHg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=BA409LxbDWUx7DgykJgA:9 X-Proofpoint-ORIG-GUID: Hei_VvocpQe0tWp3NZPFWYJDaGRDJ8ch X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX+KSpNfX0Hhof e9//AHXB4GJoebOXBhEq4Wm8zWFcVBEYrJiDlLdUprduycSl6iN56hdaLI1WQzunWAydAiis1Qn VEczVrkgEKTfWBmpRW04ghKrBkJ9C5opM9M1EjdMlATkEdlHTFjmkRAqFXWOx4LYwumfOrZ6glc lgixbvk4TYBGgcafbvkE8y1WL08UuZiTnLNCbKmjR1UulibFTLqgtFhaxEu1Lmp/HCb9VhFwfmc OkXXla373pxbUZTVXGzlsXeaHoB3rXJS2YXa1yTcxk+TPvsrO4dNILC0oE8nHnR232jIZ+WqNy3 GZyMoWpEFllHRcx3NewMvTsg3YOkIl01lAqNG1NIx5zjl8uSOAf6cYnfB1CrPRmd+Mh2fQcBi+c cnXZNtvvjauUkOmYPETC2V72iQj1Hx6gwke+j+LGzKjfUJ9w70ABV6I7Sri2DsE8rR/UqwPlAjv p3qHFNkOXvNKNogByIw== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-4011c0/1792411529-524DFCFC-82400E14/0/0 X-purgate-type: clean X-purgate-size: 4301 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 25). Signed-off-by: Mark Cave-Ayland [Patches still requiring review: 18-21, 23] v3: - Rebase onto master - Add R-B tags from Peter - Introduce isa_realize() function in patch 18 and use it in patches 19 and 21 to fix refcounting for ISA devices within the PIC container device - Don't pass input IRQ 2 from the primary PIC when implementing the cascaded PIC configuration in patch 20 v2: - Rebase onto master - Add R-B tags from Peter - Remove FIXME from commit message and rename trace event in patch 13 - Introduce a separate I8259State for TYPE_I8259 and KVMI8259State for TYPE_KVM_I8259 as suggested by Peter - Keep but rename the associated classes for TYPE_I8259 and TYPE_KVM_I8259 and move the DeviceRealize function into each one, instead of keeping it in the parent class - Add patches to make variable names consistent when accessing I8259CommonState from child objects - Update the comment on patch 19 to reflect that implementing the cascaded secondary is actually a bugfix Mark Cave-Ayland (28): 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: rename PICClass to I8259Class i8259.c: introduce TYPE_I8259 device i8259.c: always use cs for I8259CommonState variables kvm/i8259.c: rename KVMPICClass to KVMI8259Class kvm/i8259.c: introduce TYPE_KVM_I8259 device kvm/i8259.c: always use cs for I8259CommonState variables i8259_common.c: always use cs for I8259CommonState variables 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 isa-bus.c: introduce isa_realize() function 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 I8259State 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 | 11 +- include/hw/isa/i8259_internal.h | 19 +- include/hw/isa/isa.h | 1 + include/hw/xen/xen.h | 2 +- hw/i386/kvm/i8259.c | 250 ++++++++++++----- hw/i386/pc.c | 2 +- hw/i386/xen/xen-hvm.c | 40 ++- hw/intc/i8259.c | 470 ++++++++++++++++++++------------ hw/intc/i8259_common.c | 225 +++++++-------- hw/isa/isa-bus.c | 5 + stubs/xen-hw-stub.c | 2 +- hw/intc/trace-events | 8 +- 12 files changed, 648 insertions(+), 387 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:05:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454124.1667610 (Exim 4.92) (envelope-from ) id 1xIm7T-0007gS-LT; Mon, 19 Oct 2026 12:05:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454124.1667610; Mon, 19 Oct 2026 12: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 1xIm7T-0007gL-Ih; Mon, 19 Oct 2026 12:05:35 +0000 Received: by outflank-mailman (input) for mailman id 1454124; Mon, 19 Oct 2026 12:05:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7S-0007Hh-8W for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7R-001Htk-LJ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:33 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6078a-8faa-0a2a0a5109dd-0a2a450893fe-12 for ; Mon, 19 Oct 2026 14:05:33 +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 6ad6078b-f659-0a2a45080019-94a3974436bc-3 for ; Mon, 19 Oct 2026 14:05:33 +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 69J8QDOq3008558; Mon, 19 Oct 2026 05:05:28 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020088.outbound.protection.outlook.com [52.101.46.88]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc5bpup5m-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:28 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFb Rs=; b=MLcqxrc5PtBIDB4M5Yn9lVF5DFlM27CAgzdxLX2JeUazegDygFVhAI1Jr 2WsXVsHI79SAzAUn/SPypny+OcOiTk6+aguI9FyX1wjJDOUOW0zG3peMTsUhgRW4 VHQxppq27kTiwLeeJso5Dk3lUnsmjzZ6V572gyFi33Gwi9kSXbgIR5Yz2ZkJYpdp /ltJ+J/4pOdq7tP1LIOsJj+fy7SjnOnICa5pKCmwKmuEQGj8/T6jyZXEJyiFwHJU o7r+BjjBp7N/7SPyrQxhZyl22iokA0ycaoHGKlrKHwtWAQQAL0mzLW3uei6O7ndg 7Mm6Z4m2d6GJkm+kESEzCdOtAqryw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=m2jTaQKWhqhTQPBUNYsU19fO4bk/6o08+3TvQZLldYFLY0hAx/bxTcNoMzb8D+dqomQF1eqnxfVjtSJSWdyChO0Nr3JMp4HhMPBDG67XCkw5q/v9IITZuUDPcojfYa/7cLv/Efi6xIxCRoPvpqqlZOStZ4SXtm1XN3z5TQacxk1MEzdVjCf+sgEK9g77gJaj+t3DiFsnrlLWyXXhs7m1Doual3KH3GzwGsqCBgr/5toCYVFLPjYV37I3AoQtQ3cVoNPKsig7X15ZmhD4fZulyWoi35d4iebxGnD/bHcmTtco9E2fb6z8qIJlhsZOQbfYXPI5efv7H3J1Ubvx2X4cwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFbRs=; b=KkTCm4fIdtMmuAUYv8iFXjE3ruyCCaGNXG91HqiJJX2Hncqds4xIbOGNlVc2i5xkJAW8QprzVisMHFPHRKIz//ZIb2o3irg4BZW7BMJt2ECoYR5A5TMDP/auUYFqfs40Av+rnAkH6yrSEqerilCeDSf7LtLynT1tR2pkkT5j+jaG07s2BEG4EU/wSWy9B8lA9iD+rTFw3Bfz89baKENYkV3JMOQ5lOomEolKVUVmjJ2mkjsWzojwJR7Y5Gf1EsKzI0bj3Q49QzRyNNTTutIGHPrFvqMtIwQ4OezczbAPPSh41wLU3QDEtwdVG42LAkewJrp+Gp1DLLKDZFnUtY4fGA== 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=TAOVXQJDaXE3btj5P/XXf0XEZfGBwKpBJnEaqxNFbRs=; b=rrr2FhDMHFGqoSRxhGp24xNpJ0sthXxLY91hT2HRihrl5hbWDLBFbzGAA+QntJW2nClKt1d7s3BD4EJw+Qn0Mc2QbD2THbeG2GpExfKQYy7UUU1L+nntRvfpWBKQRGdxtcE4P27Ui3ePGqn1YaspMkW3GooDJsFmV2F0OPRzbokt+JnqehLgUmR39sRb5Y8ZuYeDGxxSZb+fw3WPGk5q16zOgjNKn46NttcWHrrJowptV/Ej+QGlqTD7qlzmlLwpCqagzk1MBl9M0QM3Z+P8FTb9te60+LbGcjv4c2L9/1Dabje54id3h74/3O2I+czRm4iYxB5J2uBwsAzliR7LGg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 02/28] i8259_internal.h: rename TYPE_I8259_COMMON to i8259-common Date: Mon, 19 Oct 2026 13:04:34 +0100 Message-ID: <20261019120517.1448687-3-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0002.namprd03.prod.outlook.com (2603:10b6:a03:33a::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 7fe5c034-b5d2-45de-ac86-08df2dd94377 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: +nUn48g+JFHZlR5orUjhlPCFox39it8YXtjRIqMrjCGOLlvG5lHGE1IIt9vVOPmZs4mhzqnhAjEWMg9Y9+wKYm60N8OUnQcVkxIKlP4babY9mk3mcAlrdSC3M1FbHutahKl7/BgQ20lR8Jwv6D1wHOii391vY+LDZVzTfXBYTiN9kl4gkOgIa7eQJLu0W41MKCjxukPsf8f9eNyIXljzwzft8p5YI5vLsjanFjPoSlf3GDvJjVpCSRb5o4R13nSr8Pg2iG+qo0k6F/A4Gh5TDqCtm63dYJlFtXMUL2u2qSOPzFgl06j5j89Q3StQdYcQzb1TIZsD/YuTVzVl7/fbRCpKQ6W43HApBMZ3t9/ponELBhcFdJiwT7TjV4kj1e0dgEdnL7B3mgEHASvrACuIxXZC7hIUDwLN8zUNUAJBa5lTsWeCX8z/GGmEkWe87xHLkzQf7KREc1cX8W1FLtoIHEr43woJQ0JweVbi/DYi5sZINrSejLMMPRdmle7PQNg9NbK1wN8C6EHUyRB7BOjXSCVdboCuEU/jA89+QZ6ukdVFfoQRp0K8eHpbijN74+IUQyG3xX/bO5waRhcABDnSNpQYUt4qDvGj/LwgqF05nm7cIVgKDIeSr7K1UpXnM0sAAhMTEEeFvdA1X4unv7AYww5bpmoP42qsNdX/4l6WbbE= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?kG6PHnFJAVavp4lSzcLSrkv8cr6HRnaPaFyPgDBuA/yWEE3KM2gu70oKBpaa?= =?us-ascii?Q?g42hgswM4keP2nHGjyIVlAYQHSo67cnqrWg4N67zDygU6JfxE0jQLLIZyGMf?= =?us-ascii?Q?kmqFvGdIqGPyzApZqM7HTuFDNBs+NQgJ+ZzO5WWjJhWwqhCgVwlDzQyJrS7E?= =?us-ascii?Q?NMCNXLXbLBy8mGH551B5Cb72j1JOZ6q99NxQsSxIrhqF3jvu5Tm8r0Vfn0Fi?= =?us-ascii?Q?f7cVEmPIlK+RUJWTdX631mvaAfcS/JJiaY/2Y2zF2+l98Lmk9EE5xvMzM73C?= =?us-ascii?Q?PCKubCL57Tfj59/PBdYidyIDQSv0vok0wnyh2GhTpKjCA3CPM23oAdLVhCTz?= =?us-ascii?Q?1Kkv2mdN8aIZ0/AnXs6r4JwA80ZMlqXRzrx71b9w+YJ6Bh0HbS18eI7MZZ1l?= =?us-ascii?Q?TR/jw2xpPYwMDWnvsG34/S4lqX/r87YCevU8vZjM4gu6lkBIqrWzs1rrZbR/?= =?us-ascii?Q?Aq1rLI0CwxxVTxK31iTKXJ58sZ7XUQYiT6LnbHVh2gsh1dNDjibLriUDYaIh?= =?us-ascii?Q?lE3ZXuRubXKKrGWioqCUSxJnqoJJoZYgIZ0qQVdrb0h/FadIJZk0BdP8OgPV?= =?us-ascii?Q?RrgnN1/mvKlN0nC10zxihPat1KTdFpeGQ4Z37Cwh5k99j6eDq5qDDc/pa38R?= =?us-ascii?Q?Cx1htD6iCJkRFaFVCf5OXQXywb/HEXTaGAfjFMWFBrB6Dg9cHPFNHg5PcToM?= =?us-ascii?Q?pQ8t9NSibj52om8ge7zo81p1ISp9KwdHpV9pGvUxRRAdrAqpZNygZnUYHSWF?= =?us-ascii?Q?dsCMkIsn+uYIlLDe1KP0oPf9NkEmwBqZGjtUKMskSpx+Do94x/RL+/B0fBx8?= =?us-ascii?Q?RTluXZRrfmLqj4wm6G2TUWcbuqn/gpYt0BIikO3yxP+/RHxD1uTqPazplS9s?= =?us-ascii?Q?1Vbs05W7DSeIsWI/yuJzVsUI1HISyxNYnviqjzzy4F/haFscfjyKi/hOMgYz?= =?us-ascii?Q?/zzVmXPGFHqlx7hm0Hu1dLEA3ktuomdlqK3fCFYZWcioTicDdXi6G8S6E32D?= =?us-ascii?Q?zWEqtG4knCicXzYpZ06jxd+croReveKHhmSu/MnpGQ1n3oIql0jTFAAnLVZb?= =?us-ascii?Q?5c0xQcy9UGHUXbT+LMrGIpBrtaKS8kfK6CHKKy42TqLcHHawZtcP/bz2ersk?= =?us-ascii?Q?SNspqjya6y8WFijUDyE1ZJB1bxNMo1t5rO+CVrNhA7iirTIjVncqvAVtvLfj?= =?us-ascii?Q?RlI5OIHIPtOVFqIwu3PpY3ojk9AFqJE1Fq7Exo9HtASZh5vL0dPbmrre6VS/?= =?us-ascii?Q?qugVbax7E+7whP79btPSESlRUec4NSeBQbyMclOrX3ccfIzdLYs907YCv3dv?= =?us-ascii?Q?sep2vhcxlGYy2ya5nliLgoWoHiejHEGkVyRHwX4AbuzbxBpgavquBjLrbLZo?= =?us-ascii?Q?mbM1XFgYy51ncCSXqimDp/EztocdSs3ybQnFcX4eFwl4s5ybCA/pb7xP3dcz?= =?us-ascii?Q?fqZHOyFRT9oQBoN1IaLQ9Zo4ulklGsSIw2bLGs499h44Nb95PWgSWnLrGSFk?= =?us-ascii?Q?HJfJdSj5k8zDHgdSJREnCHS+ZmERnzlifLnNAgCdUSyq0095MDXr76QVcUnu?= =?us-ascii?Q?ECGCtgKvORbQOyiBbuDG/Q6ZsyPRIbffd693cNxTqnIqsb3UH3OrVnYHlZDV?= =?us-ascii?Q?NdmGY23XSmiGMYUVbKjUa+A5i7vgVK2rSYrBuYkyb0eU7zHP9moNFr6Thnsi?= =?us-ascii?Q?mGEeTDLatYUUmp90Offsv98tmf02ESoeiixH5W9dmCi1If0juNwPa6ctD5wQ?= =?us-ascii?Q?Al4ODPR7niSEiIuSvuVwVxVCsT3jJ7U=3D?= X-Exchange-RoutingPolicyChecked: M04tN2c81wlR6phRAaV7rv2SYyv1J/EvqDgzgmFUSphI5AwcM0P/wbxb4vR+m0LYY0McOGteDrwJZRrnyycBD1zdtLuCQ4k3nd052HSv92Rs88bPYYg2FeieC2fVT45ZsYnM+YBdJHweoYfelYLAhpglH2oqRFyU2mNRvvRkxcIGw1Fbq8+hIrT0KNCSZRnj8SOhVXRuNS6GaOzPAfSTHZP5r2nq2fG7j8Yg8H2RL5yjkFihBKVpgg222Ty+WC/QOOhDlxBPZ3SKezqzCHY72e08eZAa1dkCoxHXHDydZxEYIq5Dai+Wt25ILcVNkckvlB6VOfY5RyWJyfnVFHnvXg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7fe5c034-b5d2-45de-ac86-08df2dd94377 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:27.4850 (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: h4/kpMx8K1uM4cHBWTb2QTCNgGC9C+zw19DcRjvxrkRfsQOlsLdjI+IPitHrLosQzBJvsmIH6Bsc0KFikF7x3+/GxcrAEwB5n3QUfeNRkTI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX941Z9YKrlg5T gQ82tqeoe9Nvgh3vzEHs0rWMuxtc57FeRQHPueEMNEB3O1TaLVpRzulfXSxtKOERa8QIqM591SD I5aI5VtRBUHwQQ3O9AX1iyPy+RJmwk3MUwllsawZlResopYSc93jb7KCEOGfCvxRZV1shG9fyzR 91amN+iX/OVMidagVeAopLUA5Jzd+8xmhdUejSVUK1dpJOvsNac/vz5CqX7d0MYTR1q2ekAwQTQ 8hvZqBc1S7lYT3g0o6WJXkWJOuU7mP1nJWI14vjKXpfTWpohzHkTd5WBKF9y6VvGw5Gu9NBgYHw 7FApsJ/gCgRcLB7CyJIvEJcCVWDvFBk4krR/gnCX4OcQFOfmJDzSn0uhUnW9mv8gATd9jr+5FbZ D26kn7GzC3PrKpJJFeD6n+OH/JlSqyeOxLYxmgyVlogkZqtyjDnudcfD2dIdPptZ7DfIlylmoCd Nu067mZFlSU4ZuyJXmQ== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX42d+4ddb2/oO WYtsxiz04Ak+TsaSt1y18DLeq3UWOw/YxH0uMHRjiE96A9Us9RhUM4kwPCIBPaiFsRqbOaGr+Fl Z4+NEQ/sYSlHNAto1xQVkkh6o2aviwo= X-Proofpoint-ORIG-GUID: l1Zo-RvBY4hMi7oYwfBDBVailFU-bN_z X-Proofpoint-GUID: l1Zo-RvBY4hMi7oYwfBDBVailFU-bN_z X-Authority-Analysis: v=2.4 cv=EKeTQFZC c=1 sm=1 tr=0 ts=6ad60788 cx=c_pps a=XrAAyJxZ/W28UfFUt0AM7g==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=xWlEjtkXqD840QCPih0A:9 a=cvBusfyB2V15izCimMoJ: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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792411533-D5D4887B-DA9C0303/0/0 X-purgate-type: clean X-purgate-size: 749 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Mon Oct 19 12:05:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454123.1667598 (Exim 4.92) (envelope-from ) id 1xIm7S-0007Jz-Cq; Mon, 19 Oct 2026 12:05:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454123.1667598; Mon, 19 Oct 2026 12:05: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 1xIm7S-0007Jr-79; Mon, 19 Oct 2026 12:05:34 +0000 Received: by outflank-mailman (input) for mailman id 1454123; Mon, 19 Oct 2026 12:05:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7R-0007HN-Lp for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7Q-00Gfwd-RJ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:32 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad60780-bab6-0a2a0a5309dd-0a2a450b9fee-40 for ; Mon, 19 Oct 2026 14:05:32 +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 6ad6078a-b7e8-0a2a450b0019-94a3974454ec-3 for ; Mon, 19 Oct 2026 14:05:31 +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 69J8QPXa3199047; Mon, 19 Oct 2026 05:05:26 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020135.outbound.protection.outlook.com [52.101.46.135]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc83eugvn-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:25 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomG uY=; b=wKw3hf+rYbICXEZzHEeZHyxTquKXi5/VyN4jKwYsRHnYgmWF9/UvNkU79 kB2m7vihfpbr+cpfFxbdyzRyQPAo+bDjDKRXXgS6ntorIEF09iovsNoVsapbCL1M EUOVqitFSm0TuaqmUJf4SGKjHAQuHLiAENnZtQsFQyBOaOHlEnyBgUpg7nIW3Xdb GeTQSVWuW6CVF+O2REthOToFv1xVyX/JH7QtftDXsSV/5bFY8e3X3A/eLsOFAsWK EPx+8Ew8x9PLSuayhKzwLWS+IWSf5U3OgqWGG8OUZ6tuToBp1IpduAuvKSHBy4qc VVfYhV9wAnBHbqkmU4ftkBrAELbhA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WImn5HN8JGbHiwxeVwy0lVubRk5Qc6DSm/cAU0vv0AQdxL0m5x6Je/KoiClqe3JcmE67UhLealTGCgDrL6hsjzxRDOpqoKm7h87aOv46g0y++aivOwjU3jafyKgLRXqRoc9PrvfkaDExLITij64IKAPzqWM2Jji7HNwiHh5sYNCTxk0jYEFkMA0Ky8nDatcocbRhVrHdVfp8SKQv7s6/SdevAq8XZ/u8JgRr4+THQ0I35k83JwAX6SbGc5ffHrccwQqt9vEOVtvP2v67lT37RSVeI37ca9fvv5NlKQg0vQBun8XoZDxARjbGdFiBna/Mjvslxv/mM1t5Q6ZznQOGLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomGuY=; b=ro1ySFY33PruofrEMm4RzPC5AynJKaJQgY+38S4HTDnDKAGUYtQdIJ/PGBw/jKP4YpfYgKtMnviY9yTLxEcMqitFe2L1NSYlipr32twMW1cGw4Je/Tf2XK2X3afevB7CLC9HlbYXYHbEZrbLqwleieO3EItw0jw35xQ4GMgVXFMoboV//oOmdaOuUMEGcf78vuEj5TSL6mfqIAKW0LXXIsBLwQDhUzSbHF8hPtAHSC1o758ujSW/KfRLeIFY+Y8XW39bgYXAShueItIIFCTo93/MiGU7sr+AtKonQD75iC0aCX1UgF6axe2sc+MjFJkW4O6TrpVP5IcffdpHcnQ/VA== 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=aNlUrMr9q1rOFXLFDeaeQlVWwE1CMuX+2uDxxeomGuY=; b=T74/KeLC0KEsVnhatwPYqnAm6Bk3ha8HINKCrv5eIIVl4sJoVRKMu1Ow5dX9ZRNUwaW06nodw0QCf32zkRaOFdixZcnzgZCK4ZSRs6qk231Jbooi0fwCwyZl5kO9Szs0RyFnLK3CItvxYIwk/27tXNhfWDsDNE9yer/GJHD7Pt5vzgFnbBxhhAbOzzq/fsf4FSNfz8zb4cjOi4sSKABN3bj5ffXks1V4SU6VinEml+XDZL/+IFImc5hRZJ2ADrTWGTpZf4NTE4OA3pl23JhAL27+T+ctipAhWY8pHTl0a8ax8Kxh1Qw8+VFJdW+E50zfB7rGmkqvQ919bWExjN2aBg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 01/28] i8259_internal.h: rename PIC_COMMON to I8259_COMMON Date: Mon, 19 Oct 2026 13:04:33 +0100 Message-ID: <20261019120517.1448687-2-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BYAPR21CA0030.namprd21.prod.outlook.com (2603:10b6:a03:114::40) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: a7bbed3c-1cfa-40da-479c-08df2dd941bf x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: M1MRSKACszyo/qcN+0DV8vin10J7N9CU7Kx0XhVh+rvxkLjoRoo+B0gqW5KngEwzeow3+e5zgO/PE3mvfag6bQ04e+aCU5AboLgMF0cyU9eaH8FBCASorb5yHhQj8MPzTue/dMfAj9vnhNirZVpCYSvAmaUckFMcYcUB4GND2eJCo0FBlTfJ+iF19WIO9rc8RmJpP3Oc+hTgHKkHuvOApBTpXpccIUbCv4ok3Frq2lysA67Tqdn1+cWaT/TkyUIbXcOmge7uLQ3Wx5y/lCE3gvzj35yu/EJ7En94o4tfqbMbCTd+JG/psuIOOskOHyvagLSBkOKxr+ltRzHFxvnhYF3/V0YhP8m0+NVLdRKOw6tJrHdFUImDawHOZ8Kz7BUla2V4Dk6qZWNJ5xYVEbhc3trKvsywyD+fVA/qW4fuiOJd4XyfghxDfZz8vFOITof74dp/vC3yD+RkPZ5NxzwJmmyunxBaV7y9IhV0GIy2xBxdJ04TsxpElWrjgGvHq3H2c7zDikzC7FKIYC/ALTbemKKrJ0R6dcpdMsM8pTdwuUaIFw1kp7SQ4mfT3e1siHnlkXAn+IFx2N4p22xXMq3AlCSgX9JZksuhxqKuB9OE22QfHvc3q7GUUf+jK/+Rg1Ne2uvBcI90UX47qz8L3fxCUAVZjRHEynnv4Gd/P7pOMEQ= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KTVDOToqZ2Lv31fp7GNdZgsRV6D0/kx45gOkMVla5H5mmcu360yiessgNVVo?= =?us-ascii?Q?TBv0KDKL7IIt32l6J4HdsZSrtoUYJkhSYAJPHCF6Ho0bVUg9bs/tYRiiPZpp?= =?us-ascii?Q?D6f02uJLxVa2mlPSeN0NeE9/3F3HwSE6XF9ZPpOtnn6vs+scw6diMGzhBxgO?= =?us-ascii?Q?to9EMFLXh8byT018sXZp4mlX7QJta7eyrGtJ8Ng/jy2NFMCucx0k8d8oHRW4?= =?us-ascii?Q?hlUUpRj3yu0e714Qv+DhJkDaxxkWDYWy+8yECbGGOetVPRD8eQZho6JXYAyk?= =?us-ascii?Q?ef4xJoA0mT+YAnBdOyse2wnKaNU9K5vHDuKbID27WryBL4YN2LF5MapAmFgo?= =?us-ascii?Q?KXVZD1afILheL2j197dRhHzbMgiw/00/OsR0CyCValBRgzx7EwXCPyYfPRM8?= =?us-ascii?Q?GbuZfop/HKwvFsNpuJ+JCo3So4PUVnZU35ulaJUUnj0hqWCout15m4f3o8a7?= =?us-ascii?Q?AK4p+XVgHOmatMyifOi3OBh9lovP7+6d4T/SePP9JkkrtnvZKnz+morfXkfP?= =?us-ascii?Q?qHrgFK1oAHwa025Fp5eOvjJ3+kM61cVEXThquSV52tZTuU+gBDGlC1SofvwU?= =?us-ascii?Q?GurYpZcnYIqI9wceWQ7idv6hlVoydHlRPse9bKRJt7H8kGpvte0THjIOF5r1?= =?us-ascii?Q?n4IpE7vvjsvWCBIcXnoim3NEJsjccKDUOS3/wlSQGWKCxtrWBrRMUtj8MBeR?= =?us-ascii?Q?Mg97YrfQ3A9cevmU0fqgvd4ETp0c884B5mpbAjjVY2Nx/Ul8SKNsTZE7FEcO?= =?us-ascii?Q?L2lZLw7mkUlVAXR2P8/Ju3MtsRRPu5WRhvf4DbVbVi4HX2dyShX0tT1bvRx1?= =?us-ascii?Q?Gb0EqesD5oFGjSmQB5ZzO4bTBBfisDD/KH6nE0EYAvjGXJhISnjJdzr/mv0n?= =?us-ascii?Q?BY95D5eBoxhs5E54lkOYbYXLPIvuVLQ4x4Ae/Doib4IbYNnq0KWP4E33GLBH?= =?us-ascii?Q?p6GG/6NJXPQxBaab4Ufa4A9pNG4pBASBAXHq6qXqjjGik9w3hwt5al0zTKiD?= =?us-ascii?Q?LKtZuGMEZaU1Y8DrVv583mfGEL4Vxfyc/3X49xyvcf2ycHQVhPXA1w29zBCh?= =?us-ascii?Q?WkQx/VSe++Sdek+TjS9WEY8VTwn2a2sbv6A4mPhvmJKPmVnIQepsid+gbfhO?= =?us-ascii?Q?kljRKciDrKCB7isZHDomMYN2bAfSal3sRogUV30wD2w4JhULl0dcvHdcT+KI?= =?us-ascii?Q?+UOMHPcT6cHPODjO6rer+6rmPtNigySMdEL2ndi+5arRwkm3iTS7fHis4NV1?= =?us-ascii?Q?MvzpBIT65t8Om6GqYl92nte895kF+8r0m3O0Jf8m+omXo8UZ7i6jyw48N4KQ?= =?us-ascii?Q?pry96T7n1AjjpG8dvAR+5yTzG+cW0Vmej4EFi7Ij5Z6qXoygYqH4z7rjzPb1?= =?us-ascii?Q?yqMYnvsAxlTZ98QLAafN0V/vPJxIL8vZJXiwSrcwubMA92IelSoe3E/z3WFg?= =?us-ascii?Q?mJq+oO0tRQBJRETfsChXw142wTOQdPYtLmqwqRUkJaDXqnt7lGfBfhmz/PHp?= =?us-ascii?Q?7rAIVrIOUz7sU6BxGKr+VevNbFrEZd1MTJzm+vzOJ6l2yqA1+JMTXXGYzfzF?= =?us-ascii?Q?+pLutzShDy/V1bRUi/MxEmvScuYnp7+XDuGrfHr71yB53GL4tRVeskOyHdnA?= =?us-ascii?Q?/5++1kKDURNfuNFsPfTjnDl8fC2eCx5RNvotcZgqSBpSXARwVinkfa06I/XQ?= =?us-ascii?Q?aNTo3THvlM4ayMwMo/tJXvHK2zTyNlpfvFGap5X2X7hJsnlqpXEs+XbR3dVZ?= =?us-ascii?Q?VQone859Vew+9K5ztcFAViUl8R9bFTc=3D?= X-Exchange-RoutingPolicyChecked: fCKzcwsqXFkAyECvXZZgoHV5YBdAiF3E5iO/3xWxoGFzzotNUTgMUPP0fs5ONfuhSJ5aNljp3RdMbtHAu4hSPBZedFOCsK9ezBajFXD0/PD/PeE93Ta4tFBEuwQwdGWoEoasMePVoOgXx8EQnHy8QcvTO2JNa9+Slb3ZyGtEpZkOQ9TwKRaJ4BiujaJn8a3gMakUkS+HnJlErl/c+j/Q8JodpaSF/dcQ8zSm1ShVFjmTLO5a4xaC40uxJMvgAnvxNGGnCPLaBU6+4fqNWduzXC16tdylyxSJAfnvQEMIpvV03JHG68RmsJxEZesCinKaNk75E4FTJZce1Z4+FHHd8A== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7bbed3c-1cfa-40da-479c-08df2dd941bf X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:24.6334 (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: swummGCsK+yY6y2LpDP7NfnzqkOZ0sqanVFnl/n+lttp9xa+ksoJSu9B37+W8Lgag4BH6Ynjjy/JXQZ096JUts85UP6LMOmRVH7iT6aoF4g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX84O4zDndk7JN NszTuMalAtFMgOVisZXSTMRxXRElP3zquXHRKX9QCzcwe6FmWI3H70o1iLxEs3G5yLxU11cxGTt 9PwMbzczTfzLTuxYucj721k5YZ2Uj+XVcE2UxNe4Caxm3CZ3a0a4cL+pyFcf7Qt+D8QU1vtm1eM Kw/cVQev3+bv71aIIab8zN45sxHqnmhCRGUodHjpjP0kmlmlOFTclzzkFy7BQH19lYdgrlnYAQF Id2u3rSHHFPYXAIim5QffeFf8426GIHbNPmUFlV8SVIfDg0AjIVvnBCwFLxDQ5MyUSllYw6v7d8 iFmC+BBePK9K6tgSUMdoCi/BERRVgbFg1GRaLkdgbzrEIJxPOiPhQ7a4vQwdzZQRADjQGNUGKcg ZrqpiMIJIt7kLttHVOSp8o5L58BJ+GRgejPFTeFMCs2IEtNiilK8LUilED7Yw9leVDFWbHgwnVD BQGN4PkpLXR4bUGAx4Q== X-Proofpoint-ORIG-GUID: jhGA_ywVe8KoFFV2ICwQJnXyoggRRiIe X-Authority-Analysis: v=2.4 cv=RI8mjIi+ c=1 sm=1 tr=0 ts=6ad60785 cx=c_pps a=5R5l3xa2V1v4tL9kvXelng==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=XF9Y1ugsmyLceZbb4BIA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX0eHTCrPYVX2e T+jBZRzPBMDvjmOIGdRL/13sTFjZPyLEk9XU/kYrJb/wuAJ4MpIQXcsu84+eG9jwM5i5ce8QkO6 XS308QuK2CwK2OaZVCmXzaqY4Dx1lp8= X-Proofpoint-GUID: jhGA_ywVe8KoFFV2ICwQJnXyoggRRiIe 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792411532-AA2C49EA-8F3090C1/0/0 X-purgate-type: clean X-purgate-size: 6643 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Mon Oct 19 12:05:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454125.1667620 (Exim 4.92) (envelope-from ) id 1xIm7X-0007w4-Tt; Mon, 19 Oct 2026 12:05:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454125.1667620; Mon, 19 Oct 2026 12:05: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 1xIm7X-0007vs-QD; Mon, 19 Oct 2026 12:05:39 +0000 Received: by outflank-mailman (input) for mailman id 1454125; Mon, 19 Oct 2026 12:05:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7W-0007u5-3w for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7V-00EDjg-Gk for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:37 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6078f-e002-0a2a0a5209dd-0a2a450bbb9c-2 for ; Mon, 19 Oct 2026 14:05:37 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad60790-b7e8-0a2a450b0019-94a39b0c262c-3 for ; Mon, 19 Oct 2026 14:05:37 +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 69J8Osum3282318; Mon, 19 Oct 2026 05:05:32 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020102.outbound.protection.outlook.com [52.101.46.102]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc74ekjd6-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:32 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05:30 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=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=NIlAnp4VAldnLceUySYWQNWAeTWWwprg269Vv5DQ4 Tg=; b=sc+iuC6pB/C/7jDT451pALus5UcTgkRzwDkOKoglJjHB1+MpdMJu5TOLJ YikPoLcGXYYQCd3fTSvfsdgka84cL63sQKUYuvVvBYcr3p0+Bz8Q886qpHG3zwy5 MM3D1exEbo5bh9aeV3vJTCUkop/68dHvDziWx3ToHuPlLrlZsH915feS+bS1cX3Y KHTrVHEsivPL0sqVkPh0GXZI5QAuECSJ0wCuwf2oJEOtKyWzSXTpHE/IkLgmxqPb 8b5QNXtrwdpT/w4KADHH/tTq/SdsijTsraFaEukq7ie0wh5FzKYEnZMJeB+wbx3f sJk0Ok3B/7zGjsW0GL4ASxEC6slcg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Pr4JwQ/jYvxAKvszzjM7CrPE+wkuD8pNDbhOxj7wUAtqX+4cnKJoPdMXnlyiDsZKIkWI6dMu287gp4HX9LdKlTrx78cQl4cnPFKaQhd6eTe6nEHFjW1Sipu7DM5PPK25dCH35fHz6O3f8oklsHMuXqsogpmQDWzje1EehtKNBcCz30fNkdrG/PdYBvZJRVSZULnmVY6yoih6AgkqgHZvlqtKfKe1P8IIvqHcztBZZPsjjxTILzs0fTvdYt7j9WfSobRgGvLDeU+t/2+rkLHdBanwRBLvmeCBBSqFur6mmqwM1+jCVv1zWe2i8pqEXE4n6jIqK2VyLipmM30038a/tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NIlAnp4VAldnLceUySYWQNWAeTWWwprg269Vv5DQ4Tg=; b=WiKO9oWUjdQQq+CVkdensOWzjsAP/pwoPOxs+E/nfuC3RkYNpxxLEYThJrPQjMKtMdWimJJf4f/IIO7ERGwY6ELVPlK2XoyaWpNE0rAK+vQPKZnzw1vo/FdnqLjz/4A28EEbOPbrhYh1oinBPhpH4nvI2S3qRrX3qhOEVnR/yvrclgHXAWUKyOlvybuzED8aI5tlOU3Ga6CMsfEsMHmJIE8LqHyg7Db5Fu5UYU21frtVQLFUDShr+bvt5gEwY/ubt4TvxWoELp7lVpjYjyMZlFgcQDvb08QOnU0J6/OXOcKDJDby+gEWwuu/p5Yzo0ajawVS28Kp+CY16/I8m2uhZQ== 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=NIlAnp4VAldnLceUySYWQNWAeTWWwprg269Vv5DQ4Tg=; b=Upilcb1EB+cdeUXhNY2GngqT9nMiHYKNC3k8MEj0VDzs5SVp5QqGVzNNPhd5fARRCZip7tQJYegcwf6JxBcJ6YwqB3Gn7L/1Ji2/lirx8Q9DdGnChlT5/RnhlKlBc13zXZeyy8SNrV7fA40k/1ANZHyzKEqgmPdczbIsA8RjLI2QqA1gWbXxowuwiz0O51jF0iWrEqg4xexZi4Nma8pVX0v55/4h5rF9OF1yTj/mt57jdtfpBx4RAct+ZK4GXLvXsCq0CEJZ7p04gWNSzXXKztRbw49G6xtfUcJeNk4CuyjprRZrqYmLjbfrtNmibeW/OfL1hBrhpV8ur9QyjIwE9A== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 03/28] i8259_internal.h: rename PICCommonState to I8259CommonState Date: Mon, 19 Oct 2026 13:04:35 +0100 Message-ID: <20261019120517.1448687-4-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0390.namprd03.prod.outlook.com (2603:10b6:a03:3a1::35) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 6324bd82-7eb6-412c-ea14-08df2dd94553 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|3023799007|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: UgvTmgx15E28aPFlP+tpYTSYDX6QoHXnzqiGe8SIpIlAgWo32SEY1X4gEYfWgph917ovTB20v70g13v5E4KFVpb9uDDMJc2AlZuOU+c89VIUGKNpaZEFksc4brDMVyRnPko/YfTI/3XaxfYD4yRpUMCQxQeLWf2RLyksh0+5EWWrHahjfDgLLKnpM0kz8siaAMYLhFB9hyerfBOphjRBtW61nCvDo5/HmrJ61y2FiUqbGVH1JyN3ePQABLWeZLBaEkvtcQU3gKk9YT5qGSsg/OudnGKaa63VV3mL0bb9FgeFwhbJtckkE/Zd2LUbq3aJG+AHht/Bot3CFVcwf/ASpa2vYJBkAEafeAWmvmPOp022ePGjg8QGJyt7pQpk/o6y/sEPjxOoUIwTOslz6XreQMDTJJNXiB9KW1W2D/We9Ejm3FLF9RQGHb8e+eTQckBNAP8sgp+KrKUgpuW7WVPvMqLiNBvMjdATiDHJoP2dtmHf3oLb0ODyWlv6mmA+K2ZCypAfnpIVifhihDYycljJJJqk9Z4BSbutV2wH9FsSmzxSQishQL87iGdtB9/hFyg4LIfkSaH1PfJjIKcom6h4KrF+ubQ7b83z16Wj1fuu8JDDdNH+eVSCQto9XP+mf+yLXKtteNOvjGf46RaiKZhL6zS1cm6mZYlJlk3sY4WNTNc= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(3023799007)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xhGFkpbsAzjUVxzek1KSRGBiRLFmF6PTpyttsgddMNwULbSgdzoFXqcczYsz?= =?us-ascii?Q?auGz41intpATjqkrYgSdxbi6Cy+RGXHFA0JHypYQ8uFCXVkiP/yU0Iz28hlF?= =?us-ascii?Q?Ad9t/DX0XoB4ba4IuOzuPYi51AO01wN4qvmKpgHYZuUPAvzXpBGseUb1yC9H?= =?us-ascii?Q?lseTuk15/rMYt+M7t8rNYtcoDaBn2Xk3YJd0S4nKr0IsPZe12ijZYSudSSh0?= =?us-ascii?Q?gau63DQ7yaKCjx0z8r6qWmO3vaxX89nOaMN/RrbAZR+IVMQJsnkIwFiDMTyy?= =?us-ascii?Q?P6b2Rin35Lvq7DvwfhxDroRE6EZGmAgyC5pmZLljpG0K4394AGymeQbBFX+r?= =?us-ascii?Q?HC1a6pbCbYFd3mAP0pNxymQtZNR0kvv60zoHmWUYOghiSD86G7H7Vxp1NkG6?= =?us-ascii?Q?ZSPCjIDTFJELuMlqQUAmwRmQ6qiiA9sOWASQhyAEfdYOb8lMJr57eTMqd27m?= =?us-ascii?Q?owEEjN9otuQk0FbJNYmivfjqM12fxovUvBGuAgDGl9bP2T0jg4suamQSJZQb?= =?us-ascii?Q?9A+nMMigGTffWkNrh9lTzZuCsm7Ux3WmAdLZ1ZiPEOi19BiMKpY8vBHG6SOf?= =?us-ascii?Q?bgqWNUVZXkqU60I7cyw96jc7F9xNT/RAck3NRFDyD/pchl4HxPmEFCslWm0s?= =?us-ascii?Q?OLfNy0XpZKNOkHYPORkJy+Xje7VbimiMOGDqi1ZgSndQJqBt7qc/B9qDQMdc?= =?us-ascii?Q?hTDfAvWXBbgXjFWb5nlREY+g2neS3k3OjUUGW41h4t4sADuHHoiQrGcLaeWb?= =?us-ascii?Q?PnP4EoW35rbqNEtaiT8ciNeMFCCojWxwR3hrzx/fQKBeB1jLhYqKjkACnC1O?= =?us-ascii?Q?17jbXVqdTvZQMhxc66SClS36Oo5+MMlwqLZySqzH1w27/lSTEJFoL/6fB3ZO?= =?us-ascii?Q?EWubbYOwOqXcmWbv7oBdyCP0dTqTs23/d47Ou4yaV1Q79L7tAEoEl1Qs3a7q?= =?us-ascii?Q?+femLFTMTseMoz68i5AqZlX/vGju9gVR8yEIV9KGdxVTU602iFRXyrZcXtCc?= =?us-ascii?Q?sTemJtBkGR2sEzWgH9ucDTjF3xNUX+Mn5EBZMjYJxBfMBeXkUhCjzQiuocr8?= =?us-ascii?Q?C/Yx2yPk6d21GugweV+HYClmmdmsAVjJs14aKFSnJE1LuBcA3gx84z4rCrpY?= =?us-ascii?Q?d4H5Q5vV4TIvKHGEeVM3/yXrlQ29A+yavy/KkY8eEq3V0Rq6FpIYEsM0W4Xc?= =?us-ascii?Q?IT5FkybPebYp8XsUnRvIfq7UR56LaoDkM3aZKzMPm7fRQsLGYdqBw2CKABut?= =?us-ascii?Q?+8IpqIPsIFivHutrCc0OoKLllUNGuRAytcQPYF/Eyv5kJDCM6nU++OAmi7zX?= =?us-ascii?Q?dun6wmM1uTJALYb6dxKtT2IqKF+/Kq7ruRYr0SYE/azoRiXeGV2yLMXWOU3n?= =?us-ascii?Q?Q37wJYNtgbNbgqEf2C/+TWPJJlR5debiET7Nbl+m8xWXSpBjjl+18NoSo/R+?= =?us-ascii?Q?X5cioYxta5uKU9+Ydexnrj8ANt9I62nqKrq7MQ11hJW9E65SylevRAVQrCAQ?= =?us-ascii?Q?kQ0X3/G/bQr4l2/ZrI3fr0/wTRKCtZqEM3omGh92nt9dKsk62MI5B4r6OcoL?= =?us-ascii?Q?clbeytv24juBGWwv7NtTJXfiUkxzGa82YRLgvAp5zIe8Xcw1GknU5AgC+/Zc?= =?us-ascii?Q?ZKKyu9IZTWTuqMKKT95d0EiHOkd99b/T821Vm2fTgW2xYmAuPle9XU1+XUuE?= =?us-ascii?Q?4dFi8QcJ/DuDyg5jfpkJpZK6JhJnQkWV0nmqEf1Yue7ccyPEGzOE64ehUrnH?= =?us-ascii?Q?pa4f1ZaTXm3m4jHxM5Pa9LoP7YDQZyc=3D?= X-Exchange-RoutingPolicyChecked: uy5lYTDnWbKe22cVJh+MHTWYp2lnAQayfxQzYE0k3MC0f6e99zSQD/tTAvernbHgBZcQOQcT23lf4+Dl3LCqCLlH1H4ytqwvTOPjPxrMERVet1qQ0OXunvlFI6PD9l0VY136yJRaXASDCB1OaoZeJvAzCcxnRbWOAtGsd6Sekw0vIPAfS2yLLpr7XohFodAq+EeIcZnZn2i3GF0fuHzwH1Zr3GLAoINB2mnC/d/XWfuR8mlYKkE3tKRxL8+1nDaSZXW46iqiaRNHciadESaFQoCVVt3EWckqJXjhpSHjYT8hbXFnGlG7JWfbZRyXdkFG1NcizsbGwZbgju79hUcmrQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6324bd82-7eb6-412c-ea14-08df2dd94553 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:30.6875 (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: mK8eW1p31gHNCvfGMIyd4K2H6H4UdOAkmJy7zuKRBNECS1n1Fqps9Ic61APT9W+5HvKuCI0TyfsWDc+WiwIRkuR1bck3D3DKmpLNGUF+QTY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-ORIG-GUID: -cUoww93KufRABq24H3E5qvNIraHL5h6 X-Authority-Analysis: v=2.4 cv=HYGB3SE8 c=1 sm=1 tr=0 ts=6ad6078c cx=c_pps a=6N00tFO2at9SeXRP/8dOoQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=01ND9n3NiX1-kDoXiQMA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-GUID: -cUoww93KufRABq24H3E5qvNIraHL5h6 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX+jy0iXX47LIm O8PKVOEB9NTePJR9ZDP/JggIH+HkbwDVjzCbyuRx5vdyE+PZjUuwrdCZijHpAEZf3PQg35lcSho 8aWBbcnIn4pfBplU/qcu3DGAFvDimxs= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX6L2O7Km3w2ED bIweuQmEFMfUzbrqYXHnjLcZU6jFrHsIqc5PYgdfI3DrBsduy7G8wUazZjGGaJaUrdEPIVOZ0mJ o66xS9Yph5NNHxy86r88KKuKIzx7N/1qxm6h038zKpy0Jb8bmeijUXcXOYvqx7uX2KsuOLTxrwP y3NoHW3B/i6KSdCEpTBrgMdThtBkXSjKtkIpHAkWqB18pAfeypZB8Febbx676hNJKjoseHk6uED PThmGBTAGYNUcBJj5KjqssBfGMzIBXZgs8AAzkDPH34SIINK4bZ0f2bmmWviEmNFXttAY1AHih3 w+86FJcW7nw6PSMCcURjiQUtMHIDtHnP6DXMdViZc+jagc6RkyA5S/kzju/HMg+kijer1r+IQSy qTX8m35aA+WQbWHnzXs7qwsshDYamiWWL+xxBdTUOUnp7eqfq+2roZPtZzbh3Af6k7r7hPFt3Oq RDlR2MmStbrYGS7hVdg== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792411537-AAAD89EA-C7B23BBF/0/0 X-purgate-type: clean X-purgate-size: 14398 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Mon Oct 19 12:05:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454126.1667629 (Exim 4.92) (envelope-from ) id 1xIm7a-0008BQ-7J; Mon, 19 Oct 2026 12:05:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454126.1667629; Mon, 19 Oct 2026 12: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 1xIm7a-0008BC-3s; Mon, 19 Oct 2026 12:05:42 +0000 Received: by outflank-mailman (input) for mailman id 1454126; Mon, 19 Oct 2026 12:05:40 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7Y-000861-QY for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7Y-001Htk-76 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:40 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6078a-8faa-0a2a0a5109dd-0a2a450893fe-38 for ; Mon, 19 Oct 2026 14:05:39 +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 6ad60792-f659-0a2a45080019-94a39744730a-3 for ; Mon, 19 Oct 2026 14:05:39 +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 69J8QPXb3199047; Mon, 19 Oct 2026 05:05:35 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020128.outbound.protection.outlook.com [52.101.46.128]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc83eugw8-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:34 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=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=GTsNITGc20yNxz42lJwDN4eLhxBiwmVbhEf4oSGIB NQ=; b=AIr4/LndUBm4HmJM7ul+XGeaMU5cKO/EyQ3higZswTn2COwA2xPROmF2/ NLFJuARM2I5XnArsBhLUQ+0vCEfk9xGZRd5CNPaSn08HKhtYq06IxENhIBL4xyUK gtJfkgr9HEtjlwQWmGaHbP1wqL01HXSBo2ry3szsdDwAOJserTqljCvY80kXhuTE AbquMBQX16YNdiAVK3Dcie8p52SXD59a7S1bwOpNM7c4YTRCNMqohRrt+uObgwx7 IvOAHEYVttFDQRjrwTRYXspdgptvZ40477VOwMOMSwsWeHX10f61A4qVzPS1YZye QNSe5N+ivTP/TXdjn4vfkqb5Lt+TA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kNYYGKNIeO/QO2RF0m3rR2mBXCe0vKWg0oLgn7+ikThtjSS+f1ApitMP+R1KotOQD6OiDk6pvghwMA2d/SXs6Mj+BkH/E+/y3Zy0djY6CJQ/dUCZLOpy61gkttkpVnMHRt4r49OGODnGZRJNa35jdtGRWYphBM3eXuM+5i8Zz1SYqBlImJv3InEEVjWbmrTYXDT6nfVq/WOro6u0oDn1fTz1Cx005ceu3xQoTCEVqZVsMGCZVwl7fjwWr0D+otuiKa7rRq7XTytHwQ5JdeuxvFiyKybJcOtVhaJXeuGiqWlDckLOW3Rf22vpLKFV2T25SKmMPkHX2ibgCBF28oA5HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GTsNITGc20yNxz42lJwDN4eLhxBiwmVbhEf4oSGIBNQ=; b=chGuxp2u/uX0f6RHhx4K1oCFe9uX7hHxLiwvADD+hx9MyAati9yYsfoat0n9XoVBKG/Uiv0EEBbnyRMeep3r2hGaFiBla1taVUMYevzeFpbftUQXptXUkKT5G9ZDlMi2j/d4F6aFj0aVlZdSG+6ACYK57tL+9E/5MyIIuFoVi3eEqJP2IbHcYJG3x1zVliZyq8lDAW0FYzTLsCWijVNK+0nLvtHCywYhV7uA+CyMitaE/QN9e7k/7N9Nt8pS6TsHXVssCmRXT7c6eMh0CeF6TXfPCAegwWggvUD0zUMK5q6tS87aNIa8X7HKSAw5ME7wewe1hoBn/yHASEscp1y8gA== 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=GTsNITGc20yNxz42lJwDN4eLhxBiwmVbhEf4oSGIBNQ=; b=f7+ZfV1gkjdoHPLW2e8jyryXyZgqABo1KcYQPieCIo0X7qYCNqrrAyjug/dSQ4gBIRurQEiOB+XLV57Wt0ppNdGFpejC9mZxijcEEztm55dJJSDqxs3C284s7vuCy5kBfsVD9/wOIlK/tKkKMiOi76r0CrgcMbOPCAXcSp4FM05SiSAyaNaDmFZ+gb+9bDM7QiIyuwP4w+75vV9/z6oK/k7Q+DvkmJ7H6w9iCAW0+TXZ8TkX1l0YCmZeqrcwlVAG+gonWIVCCZktp80S2A16hwMkRgWd2j4BeLpct5sKpRirqJAf4PfkrS2toSXrscu1Xsiw5rbAlb5al6esCUshPg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 04/28] i8259_internal.h: rename PICCommonClass to I8259CommonClass Date: Mon, 19 Oct 2026 13:04:36 +0100 Message-ID: <20261019120517.1448687-5-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ2PR07CA0007.namprd07.prod.outlook.com (2603:10b6:a03:505::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 21fc8565-1794-4941-f297-08df2dd94743 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 9ds5idlkR0nUBu/o3Dp3dLNE6LnVxdlUlOGpi0bfXcbKcTWHWzoK8yrs1EtLCksYrr2s9sDp3Fa6mLjRvM+qwIEIdWn/wF464UJuU+2IVKOjMTww0y7sY08H71unzSBJXCDfhHqeWoUm+MA7KY76UpeDocoQ0SonKPYW4xl2r5KsdffFAFB+YETR9Cp9WLFlxJoXb/ZBgc64URjjVaG/FYI6rS05dPcYZL4WXlqmI4zgI3c7gOHL/XgM4f3LT9P7UD2ZqSx4MUoeFpkRaK6RWXLieWu98ykGAjYvA4fSVT5N3MOJXA8PJVC1fmpBWvpEOdro7ajbI9lu67cMGOaDyi4PPrtRxOKwl++mq6TqX1OWIMATzc7ASLVY62J+7NlJTGnUFhIyAy/QWEYeJaqpYyUI9MFGg17WqKvmJVKNKHxTkwrqVAV2iQheRaXdMQgSTEApEigymdl2yrs7++7Q9BLkZWyIebcYMnarLRnu/OZPZ3dGwevM7olSjkv66STLPqAq/B2a9nH139+H9WTsNCXp0E5dShIyw00iJehiNuyjwaSlUUjgNwxC1Gu6rckbqs6GZdHsmLe+Cs+6S/BPeXqPmLZ6+D+Gq2PQkOwt45MqIby02ys5nyPfgiX2yAdZDgEVN/fhwZ9ZBTn6prv0ErkbmZDaZuySieq0eAScyk0= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AGd3HmO68XxL68cdXTgf+lScNdNdfMh4WuDpeDMNt5byIr/ngQgN6xVcs+Kn?= =?us-ascii?Q?wGNq4BLKkhnLtn32hqMzlQtOtlGKs7fT+VfsBM6GPDRtJboWpCcnrv2FzdqJ?= =?us-ascii?Q?+eG9/vMBOmG7xMilc+A52zVTc09LJbwAW4fAboxJpVtWtbBxRKH7GAAxb9yR?= =?us-ascii?Q?5zYUlaZsONXp0nUym1VVW7lsm01nN6DFotaNNbOcvzr95oIEj/CYTLs+kHbL?= =?us-ascii?Q?FDedjeebzPJE+mqf1wKhhU1rLh4J9b0X44ZLE0fpCXMeXTN98ihwqlPm3rKO?= =?us-ascii?Q?8BplAKDVBrmABPEi5UHzTmFVSjrER3QCJ1yYsy2snMAY2o9o1z0tKiyDqeRH?= =?us-ascii?Q?wTsvUnbgYliQrVV+spH5vlfJlFiePPO7WiIS78OEi2valGTnXFmWDMXhO2Ws?= =?us-ascii?Q?0y5ld9ymG3e6N2hXbVjoHRtxWCRETkP4O0eIZxjg210uauuDQgVShk3G1Cik?= =?us-ascii?Q?1tjMSPLaPxFChwqMmXrLgnD557oGuXWRg357jdCiQbQcI4KS3XlvdQJm4hjg?= =?us-ascii?Q?7YruRkxDgvD4h0vAeJ6z1i7vg1ejvjFJxtjKM3rzT5VdphqCNCb7tr2YrvRw?= =?us-ascii?Q?i+ARNVNZaEqtRCAeWFUi6kSIXd5eBt/0s36nkkQ1/SUY5srQVgLnVm0Kfzwz?= =?us-ascii?Q?teJSdmhhsbxd+TDyhf9njqZl0AkHzDERQDwCfFFW5af5H5b1dGB8oBvob+wo?= =?us-ascii?Q?H59Yq3DywPCBAxYk/9TlazJ3W7X0Tc5vD5d3XH5TtBbaeVTS+VACHlkww0kX?= =?us-ascii?Q?rsGolcTccLuQRtp6yGHNGYNdCCUFbMVT9pxxiDp4WyAwRIukMxUsWaT60eDc?= =?us-ascii?Q?RRcfiyW4sYfBJ55N3pq/so+tQV9YvpOkxELHFlT2I1jhm9R2H9WvvHZbSWF2?= =?us-ascii?Q?BbTIxsaLc2qVViNfppKa8L2dYXV3AE0FG3HgWr18jdOuLKj4WFsHOq7Ju4Ye?= =?us-ascii?Q?zRZ5eCXob6Ou8sPDOvvCDBZCo49uDBjmJhW5/Qk3mbRq9El1N/lZQCXvM56g?= =?us-ascii?Q?ZR64boQFBGMzuUhbqUQutOBBEVZlpmLv/mJcS2S7WkI8udRzmMs4+isUVcvA?= =?us-ascii?Q?nwSRo41dF3jbSayqqoEI5uWCkFrlsiTDm490/1B/QMOiEWZl3rWPqFFCFwa7?= =?us-ascii?Q?S+EhpHlcmizWqxda5PBYVQiTykvbrAeeFQr1dPYj9csrsjcWCUZiFXPVqDh7?= =?us-ascii?Q?jLedps0mgukMsDJ3CYbwIZQRqbKkJp5FOmRBrkkYqNch9NxIDQ8Kr1ZQbe6t?= =?us-ascii?Q?Apivw5fiWX0bUx1eSBF14Tga89GOxlFIkLfVwZdsCXmalna4PhBs7gC6x1wk?= =?us-ascii?Q?TarG2zQRSahj+95zxS8uQeTaY9G/ptYhnXVO/ahHDOGO7Se83zInjIYTGezm?= =?us-ascii?Q?nM1+Yb6CpHBFxzJqmamZRj6yqg9egoUnRz112/XyWIvxdX4vmoZLkDJOSB18?= =?us-ascii?Q?LHEnw8YIQ5G1oYSPlmyuZhWjhTzxkAxWzB5K/Zy5/mlFvuAO9LNhtdGD17U0?= =?us-ascii?Q?cK1gOfBPpcu2IITCGYrEokQkcvATut8d5nlJUEuloeBBgq0rGmnQzx2qOL1u?= =?us-ascii?Q?hm1n/FnKmXvVs3tFrJAtjFqnBmhxiIdHbfeqLfzzjnHzg9StLgbwQyiFhVOe?= =?us-ascii?Q?VB8B9htIey5TNuG5gifHTulU51QfId9nEFb6Z8MJl6MflD6iwRCrfUeQRgKq?= =?us-ascii?Q?idUz2PtcsKA/9lwaasZSLeT/bu3KrKyacMaGndJqp8GA2/ifFN/GZKuZ0db7?= =?us-ascii?Q?nafbyCWkFh3/XX8yp3cT7ciavL8ABt8=3D?= X-Exchange-RoutingPolicyChecked: NL+NcRtx/WPEu3esGP8DKsrZd4CfGBIQT/ur5p3nHYZGQye1hKZZQQxSAV/SDXkIcOo9ROojHzwbxwnC1FQ8r7f9G5kr04LPJhf/xU6wZJceU4eB2oJoi4+1+Byudas6hFeNBLUAduz+91lXmKiW88jBBSjX0hnxi7AQT6n9iAoWyVfHHxOhNE5XvdLvIA8Z39Wy3s4/2DGCvphAsTDO5N+f3dyyGRsBM2HqZQ5nDHIjBrxPS2xpzmfvDNRqybAeJ7fsJ6zO0lzEJKmQ94vHlnZtiDsrFgzr53lkbjIUD05UtmGnDa17Pp9PM4YblqrA61rwPw/Nom191wbz1EugfQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21fc8565-1794-4941-f297-08df2dd94743 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:33.8931 (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: uHPBp6NamtXVvcAsDznit2I8I77ie1mXyNqWRpCBdWl2F5VK/VI3AGbsWK6wLwaYY6sOhaPyEjPTfzmQzUch3okjlq9kKWLeUODVFHpnVY4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXwSX+kaoFnatL AzzfSo4xoMznPWZv+j0Prxty3NIStoHfpS3pEu35gOEJtaOPf+KDjuNQtVpwg9CrHqX1bgBlb+v TZSny2ZpXrJVS309FYRPCuxDCfiGBFBIKIfdO+N/2W2icHVll7FVTLfGCYXM9vZDMiiaD1NkVMk K0jESeXO9VxiU7R6VwvPewwD3El8BoIuoh5OE09IHlpN+ABffEH/YDus+3U8MsjMCI9qB7UfFFx 0echVDEBTRiI5+CCrCWOHb0ORWF8UNJz9yszm+BbeqopSJlv3jCUvRs5quNAnhJLrpMXKCF9aE+ 1yVn5G7p9ElzmdO5UkYhtjRANogEyzPlNMCoravfa+xvn6ZdmLBJVJwgQvzD++N3uDhkzjT8iuu ozY2r13sMx9SfWVVHGTDtpPp2stk22BuE/zUqnQwengonkImVyft3no6tDLSKylY1ZV3nlOe8s0 TGncewxfeOYtPfUr7zA== X-Proofpoint-ORIG-GUID: OPzSNOkcSE3aUA07YuHtOQ_pjdw018Eg X-Authority-Analysis: v=2.4 cv=RI8mjIi+ c=1 sm=1 tr=0 ts=6ad6078e cx=c_pps a=gFm19s7yh3VV2LjzJhowOw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=qh9Ixq9Ib_qUO60TQ2wA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX/PrXe4l9dJ2s 9MfIXz4eQ0IMD14wM/LWqfHqlAcfcG7+WMaeC9z3sEVJ8hKn3ipLXlYXlYBfDUYuSmdWlHIMJ2I 0PzicdB2SmAgXOloD8wBmCF4ahLWVEs= X-Proofpoint-GUID: OPzSNOkcSE3aUA07YuHtOQ_pjdw018Eg 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792411539-D775B87B-6789E03E/0/0 X-purgate-type: clean X-purgate-size: 3291 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 Mon Oct 19 12:05:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454128.1667638 (Exim 4.92) (envelope-from ) id 1xIm7e-0008TZ-Gm; Mon, 19 Oct 2026 12:05:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454128.1667638; Mon, 19 Oct 2026 12:05: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 1xIm7e-0008TQ-CQ; Mon, 19 Oct 2026 12:05:46 +0000 Received: by outflank-mailman (input) for mailman id 1454128; Mon, 19 Oct 2026 12:05:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7c-0008Qg-HV for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7b-00EDmn-U5 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:43 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6078c-e002-0a2a0a5209dd-0a2a4504b6fe-46 for ; Mon, 19 Oct 2026 14:05:43 +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 6ad60796-b57f-0a2a45040019-94a39b0c2160-3 for ; Mon, 19 Oct 2026 14:05:43 +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 69JBnO233621692; Mon, 19 Oct 2026 05:05:39 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021124.outbound.protection.outlook.com [40.93.194.124]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hdjnwr1ed-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:39 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05:37 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=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=3vBEVX+niLMJnfCDKjUwa0/HIy/VOW1L2EsbM7q6m 2s=; b=JOArgwomCc2kjGy4J1JHcitI+uHxVu7XUiNCkWliXE7fkXpuzHmSRhvVE HByfTBIK/Plz2D6B98Wugi/RrJUZGEtSJKkVEe+g3iIDD7b6ZDYgeL/pBuQgQLnJ A/p5sk08+Ko+/CW/hNdnYbeqROrmE5ocqSKQUZifSXDIpcpqF+daOaJtHTufHsDs Ogn5kb+sV2fISZGN+UXQCzYBJSXNxBqT6Cn5Z6xLIZc8vVdf1KOOfEkkPkEPQfsh AAAEkjwIOOpeDsQUJp6ubTPoTgz808iYxYFf6v9+3fCCu5j0W9o7z5uyynibUYSK +KW/+ZkFaDh2Rm6wNn53HI3u7SUZA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=agf01a7jUf3qB0weOi972WrpYCuQig4HBqQWNp1AT6VUvuGakDzqk2WXyhk7VOFbhVy+oicgKwh6NUyJh4YIbJCLEkMJ4cvhd++mZd+x8p+4tr5w6NGTjhnkwRqHudKR5e/bDJnvt6FHfQCkRjWuvSASnK0iTXxvGlmilsbTjFuBU5Sj1nv3n6WYZAjJxyCGS1LAjhr9GYQv1w9JppInB0W3oVKtGlzBB9Yn7rsDU3G+UlMif5UPuQzCbvcBkN9k0RCx3foaYIIIP2FbCH6VnIZIBSg7MksmJrHxRkjOUS+i+DAvAZhcrwC28lWuqx4+6SBx3j1VZyDfBE/t9qaPiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3vBEVX+niLMJnfCDKjUwa0/HIy/VOW1L2EsbM7q6m2s=; b=QMwtU77merZgRFrNKCoSD6eaDOaCXePXctO49jbZF6XTEDpsMAFU1a7ZoKemMwbISmHra0Z5e/lFlDyXHzRxrBFwTKIMRWFd7kp3gpykTxdl9p6G9aQiJauLMPVMIhFDFajcM5t0MhA9rUeB4GRvSa3cp48ksrR2lyFv2TFLbPDlfHJJVyvV9Z0WS8uWRCyZs7fTonVQa4zdw9HArQwv4THhySO1S1yl81bL3jCQh9l1GMZdatO8jWIeKh7JcQj93Cdr3AxVxM92gZk4/vXP3u9eDZH9lV7Wk2J/FuMt4dUY8V+8YZcGc927i4XXihKudqN3hUUSHzwzm2MuR7BSTw== 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=3vBEVX+niLMJnfCDKjUwa0/HIy/VOW1L2EsbM7q6m2s=; b=WqqZyR+XPkeiNO7vIVQ3K0K8OFDH89mJlx0VNqrQ2kud47YHDcVC3519vN21R8lOiW89Dko7wDwId3wJSf3IjcxtSDh8AzXEpa2T3/7POCSeazO2Upbb5NMAyArGVjiaFQa/CrunHMkd2ND0eoUzPR+W+gJnH+AGDnIdcqeu22RSBnuh1oEICghKzH4TbjzOTglByXxNFWaPLTF1nD0cvVgUvt3FpqaSl4bIc3fMeevyezy+ZO8jyB0+9hUfw5nB5Bm7X24mx/z0BTX0It+Nvt89brt/EKwE35xdqpZ3w0vKoCzL3Go7eiQqXkcpasKbNisqvRJv/9Os4YudyVRYaw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 05/28] i8259.c: rename PICClass to I8259Class Date: Mon, 19 Oct 2026 13:04:37 +0100 Message-ID: <20261019120517.1448687-6-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0031.namprd13.prod.outlook.com (2603:10b6:a03:2c2::6) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 0654aeab-9d91-458f-37ab-08df2dd9493a x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: M4IU1zeVt9aVVaxIxDQwdUr69raRcSEVXW2AiZiYTIQIgbJkUTdIg50h+sEKm4De8wZSopjjd1mveQJEQb93xw1f94lCmjAffqqo3TjnDeB18hYKN0zSu2LnRCfT8Pcd3h3r6FRz3zI+7H/oMaBQ0Dt+HYf+beMwFWaaz5DAnHIF1L4zdji2Ml/nOaYKdgQFV6JKJUoFUuOmvVQjPvhOnrqLGp+1LegILPxA7eaHeqK+ukWmcCkbTZgQevShYW7d6IMH2xTLp9W+fciTXrDlUFnudSzEFYyafsFS+5FckOQnC0fBIGuBwAy/0kR8uEF4g2LepSX36/aS6U83E26/Vr9WD1kW9s1HUe0Qrod28Krk1ANzusHsyS4L3iBmkiXDe2u39dHP5cnzcp5VH22e/jX8aZJQYiU3LyETHy6hRmNiCphhtwcE/+9BSLrsO/LNprpnwmMKpuQYChOO3Y2B9oEJ8vZuYMkCyUi9g2BW++o0EVkZEv+Saj9xy4/rUyg4WqNX3UdoX3sxm8B3PPeuaAF6Hhs7tFO6jXnLm69RCoc47Di+teSqH/RFBN4RwDc6DfCKAaebGK1AAd0dVmi6fjo8wNTkA+BntIvr+0ASoi236q/uPWAMdI4P+Ub9jTA5pQ4DZIvuV2eb3mw+HMcf+ClvwaJDJHPodH4pL+rFszs= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?nuyhI64VfTzVYkMXZumy2VlOavLSN/EchtoLe3SV7/DB/39tgiXvCuDYnC5u?= =?us-ascii?Q?GMBBgioIISGvCYRJMhxlVFuVqet9tDZNM13s5kT8GAtWQJn53rahQpeOUqLs?= =?us-ascii?Q?aPaDzk9kKddNb4yOoz9cUl1SxfdrH9jkftZynUfqhyl490w6DUpL0z2Hk1Uz?= =?us-ascii?Q?G3xS8SSNberjMruS7G5lCeijb3xvWDalbA/aPlEHt2CwzeL/rf1v1Ll5WgHm?= =?us-ascii?Q?R2tDPKYgWJ3qLcK7DH0NdYAJHdP/uE+p5/0jLn6xu5GiQ2UJLRaw4xEFBvAT?= =?us-ascii?Q?uXyrHo8DCa+iv2FMTpydBl5sYP8OG1x94agtuI96/1MKV2Z1ZI5Gtm+Uerwo?= =?us-ascii?Q?okV3DDNbBT+mOt8h8EaicXS9ug1NA31ItmzNMW5nuCO9s7e+bEbkF7aCPXUv?= =?us-ascii?Q?8pcGJ4ryIVIBuv0h70ZKWFPS/leUjQ9ysiUn4bTMhEbGFT3FWla/uRcwo8YQ?= =?us-ascii?Q?kncJuLR2CyQmFJPHXMb5MC0Mmn+QNnetwvYKJqtu7lUBhYhRIejLjotj0EIc?= =?us-ascii?Q?g3X+MQsEEq4U5UV6xVnsuWxGlw5v9/VHuE0sqfPhZPm8nCNmIXBG/RKBISHg?= =?us-ascii?Q?E++jll36JxMjBDMd+bTnxZDL15QpbAVuDh0TD71fTFFJlIK2nrCB/p6pGUL+?= =?us-ascii?Q?j0Uea7xbxpPvYlBuVzJiqvrvBeIVt/FOjwiB/1eQI2G6pBRvv5tvNiXLTbpq?= =?us-ascii?Q?aJSB6quhdUZ7yWjtWG/ygY4CtvADGLuJ/q+UVyU6DQ8Wyr+ces1/aAAsDU7Q?= =?us-ascii?Q?FWdE8p5ZUMu0GxW9v0a4Qenamy1btlsfqz8nLcoYSw7OTTJNtBQU3F05vhVY?= =?us-ascii?Q?RZtOGOchla0aAi71fGbO21W46vaCxT3NMqRmUHA1Fhb0u0m3nXEzjbv6IXl8?= =?us-ascii?Q?mIlCn6jXqk3ZJ0yKTeqcWbIsPMh203+FnDhT+Od6O5Ba8qQiCf7usQwPUwQK?= =?us-ascii?Q?YDqb6Z3cpP8LX2ltcq7snTKCiXtnrN5Gnt6VJ/A+n0vBbealMzpAy6QKfGyV?= =?us-ascii?Q?IN7sn1In8Sx54K3ezHIVWX7WSAj9G99xhghOE0NxsAiJ9jBjIuen3YtM3ByH?= =?us-ascii?Q?yFNE2oJ2YBUWbBUP8p/Py9D0yGipoJqFwbKuQrpoyEkVlH55hm2Ml3bYgSb/?= =?us-ascii?Q?nGu993bW8L5jOsJ4drw4P2SsrWfrevWVOnzuAJaUWnf/gNBAQ2IDq4FA6usS?= =?us-ascii?Q?zXhCDjmPQpMnBx4CrPnAfQ5v7VCK43dsdflY7/dH6g3M1beuzgKDvWQo1DDc?= =?us-ascii?Q?QGdQA5j+1CjqU/1IjYSKZ3c2i0tGWbK4ql2qOf0sl5sjjw/BIzzc0Gudbm+F?= =?us-ascii?Q?EPaRuOjVjUZZON43/LjoNK2V1lbQsNJ/9fYJZwVCiJppL3dQ+O4nDfMQ4GpT?= =?us-ascii?Q?xJ8pW8wtduEdsu/5ap3XUmTxLxCzxxz+ReHbHqBYfWGrcu48LJwCrZanILkl?= =?us-ascii?Q?tScZ1+XCanHP/+f7c8FP6hqIArZQY01CwoApNeKwreYZPW42WhRWilemoooj?= =?us-ascii?Q?k2LMH9yX4RljIqTg6NEqN1Rzblz/aApS71KqYUv+l5+/EtqzUFU3+wPd4BsJ?= =?us-ascii?Q?a/DBWsXhscW/vFzaKi8m0dIS2c5lkMk06aV36CFHYyjuqR8oaTcSUvgWKCAx?= =?us-ascii?Q?b6bkuTMy+UKLBr31y/S7IrJsyPLZSjoqxYNe9r95ohMDDNbs13HznELZVSPR?= =?us-ascii?Q?FkofryCsoEsCZlTKeyMkNnRL7y3T1xW9JfPuZzoBPCs0UDShcswWRZ1Ia77S?= =?us-ascii?Q?n4bDf9f7JVs3vpfCTOvJLGrQDTOP+rA=3D?= X-Exchange-RoutingPolicyChecked: 3nArWL+waKjRLFufGJhe8120a1yn2gFZYqyGx7ZK8JqWlbRr9DnQNWZN7KD9Fp5DsUZAcqQceKtDOXcOuhlMXMZhTlIniGX5jN6VGfPuZj9zhQhxPOWsx3VkDK9/bhCcbHlqCIcc2vh3KOB7a6rUxn+evxWb1EGTXvVY8NUg/PrhnF2lFehf5can0ne+8lddw4bbLBJ+Gzgfqz3FxH5mewMG1lZC+3Qwi1+EPYM4WF9dvZGw4GuJCSpXtwk7lEBS0/Td8VfCSeElGqx/e8/shmdHplk+kFJLkZi44vmPcwkU28indy43jLfejbzLxIgGMlRoI8aMGgaNBHGIaEDuCw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0654aeab-9d91-458f-37ab-08df2dd9493a X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:37.0432 (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: 2SA8oyahCJtbr6Qgjdq+gqygO1aF0K7gntqBXYiv7VsaTRZ7rwLKI56p1kpemwWIzp82NpeFxT0Q2YnMGdlESgpEtPXKe6EtdlJVaVKRxpg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Authority-Analysis: v=2.4 cv=fqdJ914f c=1 sm=1 tr=0 ts=6ad60793 cx=c_pps a=MkKZ5qa7cfSD1TaEQpvYjA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=3XFHsOGY_CSE3CcXMRUA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: I-eyGOgIINqt70-PG3J-rudCgeYrypxu X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXz9rEs8dhW/O3 fgaWBfXSic8BdKVivaIV7htE4iQOv5+uMbIUXnurFcJzaeZ2XHlvgY+my5g/1Irgd+ylognTypH 0NipO7/XcNrZk2tRoh98wyJZ042NDfc= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX6D11mfmuVJX0 9cPVRuPpHcq23sJbwlEavMs5GxeALeoxRtg4boHRTvn4x9WIkx2GEWUZv0T+OQk9JeXJVNHN6SA flJIYch9Y0BG376ADX6wyAVBLKrQ9aDwvUJ3JGyyPenfuGHSoFPW/kiiu5bq5UgBnKVmko3b+uk YgE+TQt2hfDZpKhMBF/hrGOlAPJNRfzRCO2pv5/DrF7En0FEm6NxO5YyeOYOyChaCBoPxD9JKG5 F3pRSA8zJ1gj7WOv8qPzaemRi5jONhEi8LZnxU4QDRpFwpqZBnNogz7K+u7bw/77zRf37qdPjUL 1ALNXRCKRmmgJtrnZKizWEzK+lRK7223yC+hlbCCjlUaUEuXMoTv+GdTsqHIqk3iXQahffpeOYH 1t2Q67TdzTM12e1Xf2F3/W+M1enecfDaeM2sCIorGbuTHwzsKO0rFy/impvBI14eWbumYSNh5a1 Az63RkMzsBP2URxq++w== X-Proofpoint-GUID: I-eyGOgIINqt70-PG3J-rudCgeYrypxu 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792411543-C0CDFB50-5A15A95A/0/0 X-purgate-type: clean X-purgate-size: 2342 This is in preparation for its use within a QOM type presenting a single emulated 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/intc/i8259.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 547e86c5f4..856075a754 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -35,15 +35,15 @@ /*#define DEBUG_IRQ_LATENCY*/ #define TYPE_I8259 "isa-i8259" -typedef struct PICClass PICClass; -DECLARE_CLASS_CHECKERS(PICClass, PIC, +typedef struct I8259Class I8259Class; +DECLARE_CLASS_CHECKERS(I8259Class, I8259, TYPE_I8259) /** - * PICClass: + * I8259Class: * @parent_realize: The parent's realizefn. */ -struct PICClass { +struct I8259Class { I8259CommonClass parent_class; DeviceRealize parent_realize; @@ -388,7 +388,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); + I8259Class *k = I8259_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, "pic", 2); @@ -398,7 +398,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 +435,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); + I8259Class *k = I8259_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_parent_realize(dc, pic_realize, &k->parent_realize); @@ -447,7 +447,7 @@ static const TypeInfo i8259_info = { .instance_size = sizeof(I8259CommonState), .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, - .class_size = sizeof(PICClass), + .class_size = sizeof(I8259Class), }; static void pic_register_types(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:05:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454130.1667647 (Exim 4.92) (envelope-from ) id 1xIm7g-0000Kk-Ur; Mon, 19 Oct 2026 12:05:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454130.1667647; Mon, 19 Oct 2026 12:05: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 1xIm7g-0000Kb-Qw; Mon, 19 Oct 2026 12:05:48 +0000 Received: by outflank-mailman (input) for mailman id 1454130; Mon, 19 Oct 2026 12:05:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7f-0000AY-8V for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7e-001Hxp-LU for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6078d-8faa-0a2a0a5109dd-0a2a4501be3e-36 for ; Mon, 19 Oct 2026 14:05:46 +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 6ad60799-5984-0a2a45010019-94a39b0c9086-3 for ; Mon, 19 Oct 2026 14:05:46 +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 69J8P1Sl3073472; Mon, 19 Oct 2026 05:05:42 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021126.outbound.protection.outlook.com [40.93.194.126]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8hyuftb-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:41 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05:39 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=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=YGZ6jjLz+ak7jj7H3A1G8RT83dDt2Z6yz4mqrp8m0 xw=; b=slY2JDdHiyb6U1I08LRdy1Iae6Z8aJZWQKVZMD/8qSSn9yKf2RnrPfPE3 NFHySu/11fY+1cB5fK0gc2j5nxQXS8jieXllcIUxgkSDlHjDKwUqnbdx7uQi2YVs 6Q9B3DpfRg0YH4Wl6iPqo7JATMiwKh5Ucr6x6XYTYxcpbgFNly7UWDAoT3EcI9wF 4PcIG9lZ+0orOFgk82JGI7cHXVmX/Yv9EdwWlzo3GpZm3lmFwgO8KV55jRbgO2Dj nvwI5PxvfRlkEh0T9qsUC3sfakahKgP/Ci9bvCfb4VAu1kPzkLbJt12qgyjQNWI8 1NXZ068V31tbr9w12zkdKBQbAXXag== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vPNj01AzRtoXuhG+On1aEB2kxFymilYbAZJi1D+LO1Fxd5Wg8mrZhKZbIQf3bA1HJcZozpX4HlCgCBH64p9sL9ckO84zRDh5mO46qP43uDlW9tHORIvfx/NHdnP7DCDLRqcIqcXN1TrnPbCBGqUZUbGwqYi639mfbGkd00XUBAhNX3xK6ZPQGy4BhS6zwpPbb9ORa8ppH4agqnCycs+clZ2eC12xwLoEH9JBccxpM20Xblik+fZROBD5zbGH/G3f7C00xE2Tt9qB23x35WOEMZ8WQt0GqxapovJicCZgGWbfpdJqLOoSB5jc06gjJFbYLQF3ahrGsJc7bpgBMof5qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YGZ6jjLz+ak7jj7H3A1G8RT83dDt2Z6yz4mqrp8m0xw=; b=waJC1IZyy59jfo/jwV/P7f8iBuZ2ksuRm0QH7TgIBAceg61f5f7vmW8arsbLglnLPakFsa0u6rDx41GuheBUOKEvCKy/g1Ej4z+vIboE0XuGT4u6nIUoPF24/+yYgVetPlr1NlHQqGA/Ou6kOiQa0n5r4paEkv/yQEZJvIm65vt7gdagMimrSHM1feCLLwBhMNODmRNlwNlCR2+X6JzbXqxsOh/CwR3lknf8QISRdJei9O3tQYmKPx27UXkKjqll5BxxzEt8/Pm33Tv9SaCDIh5paI9DD5EBzDmUpHrHbdfmlfs5yIwjKCg3STSh/YdVx1XWIBZBqwIsdfg5eSb4hQ== 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=YGZ6jjLz+ak7jj7H3A1G8RT83dDt2Z6yz4mqrp8m0xw=; b=mm3k/k94XsCKPKA5STHduOcppR8cMiScHOW+AsexHurJQS3Z0oo7iECVPin2InyvKp6ulhdk8qOwc2SHvAiYREh2ZjOSsGXXmIezMCjdcp020KEoeYNHncaSXdgtKTAxymUomMq9ElyfAdPfOspTayom4aeHpm1WaBAqzFkMbkO24kWbwCbQIwYpxQx6EZO9FlLFNfy+VaYzxVRZCVTVoWpxDgszKyd0sig0DWSg8msfYiAzE5zPa4C7QK8RaNr/GO5BGdvprqB08HQjCCRBjfuWpotH746rH03OAFEalxEUaS6aPZLTxEFUdDGlRW/3ZMeGqUFeLsRvTyyP8QfVdg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 06/28] i8259.c: introduce TYPE_I8259 device Date: Mon, 19 Oct 2026 13:04:38 +0100 Message-ID: <20261019120517.1448687-7-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ2PR07CA0002.namprd07.prod.outlook.com (2603:10b6:a03:505::25) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 525295ea-35f0-4e80-d9e7-08df2dd94aca x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|3023799007|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: kB8zqPCyQbbDY4eNX0IA4ddah9A5qwuwBjW6te3PSRcAf5ZXKb2lCvpsttnaNyiHNUGLo4GroIbiqYlB1H6XDeL0hnpJEGBlrbWUmc7br/SaJvxK4F/5aAI2/k0r1+Y4ofMoOfD6ZKDs7pbcoHdMH8c+0oOd0W9f5fyz9JmqJ7fh3+w980WiKTibnGARJDzalM3zxsIYzZF39wRScibKCctKeny/WGBEiev6NUGKJS1Ussk8Ika6RGt5lTny6eHhes2dcHmFTO4EyfXdkchTAjFyivg1gLvO7k22ACHm57k6y1Ys+SibVPYda24FfeFcJEBexcEz8YkckWk+MwfrpS8L15E1Y95vVo4GexsvVYYd2dON9Ky0x8iqQhBTnBkjGbBM3N4WLp5t8k5suZ+2EF5y7nzDU+QRL5UYALutHGtmq7lix+o+Y+CUMWXDMZ6r18UyqaFDKFKnsC6L/rBdnEq4J4Y8m/0RwT39dezlEZi0ZhmYgXCL5muX9Xb0CBfet7wmYQqSEejnm1GMB+aVO2wkd/Z2EgpuojiIbYinJwvb3j8Q+Nu9lBNWLA2i8YxQjVcJhJDJyj7s4bbOqMe/QlMtMRtxnHAu2X/5mtQMeW6oiRd7rzOtiUEy4UsAcS7b4PILeKruRwM81Gm3seDPI9hAwVeEul8gO5VXUz/yb4U= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(3023799007)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Lmxka98ceNDtdqTcSShLiyaH0jyrryvWY6J6K3hZ+34wn54nFoCiCCl4ZAAw?= =?us-ascii?Q?VY2ac6BoO+pkUzIZWAcY/T2td1Fy+uQsD3ONPaxs1nvqt1oXlNWdOhfrF0k3?= =?us-ascii?Q?P1BSL2xd4oX+fSw3+efHlZS6cgftTigeNjV5ytXVZbYUmY3CfmSbdKiLiK5l?= =?us-ascii?Q?LSllk7wJTlQq0JH9/jyslVKSLRemaKg1SW8Col03IuqJFnn3clMwa99Y3LyK?= =?us-ascii?Q?2s/GyiGdxwNC3BsYUlaoZFMNFnq9z+fKkmqAUGtGLdJBq8C9U6qc+fPL4vLA?= =?us-ascii?Q?7LsUbATvdKfzM64uho08WVE2LqwIiVtl+nfBn1QUYSBppyqxpcDaJh705PhR?= =?us-ascii?Q?yHNJkqqjLf4aMw8bdIohspNonIER7vmcDrO9MPJ2E/9l0Y0Hq9c4OShE8L1X?= =?us-ascii?Q?QAMAYv3gTcHzs5pPeMzh7Wo7596FEJIapur5IknKgCa8Eb7d7A3g/LV06mWf?= =?us-ascii?Q?hIvbKtlekFjDBm9c0ZeeSfVkZopVVmUYJDbCdiy9fBq29SgPwM9o8E1YVauF?= =?us-ascii?Q?d3ygB9cS2PztJdhiz0FbHwZomm9jtRUBc8ByHjCYuZBVGmHQEB7PmKLnFKy1?= =?us-ascii?Q?HxTVnyoijQo3HUdzm4yXI81p3sibU76D6xtX17BBpaRYQoqg1TZVIif0ku8G?= =?us-ascii?Q?q9tKqsfP0AhJmfp0rCmWHnN8LLIk6SFYaS6EosSFoqBp+oofhv9Y4HkJPY6Q?= =?us-ascii?Q?+9iod+0mrUpaHN1ZoNFvhQQIQXRz0AZEIYd+6ta2oQHbhtuPgpuJrZ3+YS8+?= =?us-ascii?Q?/1pbObY6T4W2j9MCrlgoTjmIHZo/afiORrTbs5wkluxnSn7J96VN9dvgygRw?= =?us-ascii?Q?ng6XZy1kWimYerouQeT5EBWcaF16RqufUviDqpKJlZBjjJVSF5U/m9xY6jTP?= =?us-ascii?Q?UUITgTsGOOhqQGhOiTFT6MdyKbVnv2Z9RUFOVvHhIX96TMp12tSOx477bP5E?= =?us-ascii?Q?W0a4KLuphqbU2BI1Q5nygGYO5aJ7MvO+5vhu1OPnlxSrl8M5HbIF5UnJEaiX?= =?us-ascii?Q?EqUlPyEpFCdp5UxTv+WP2g1epDAHfr4cStzlh27fBEqqSOcu+HRgDV5vygnA?= =?us-ascii?Q?NO4+Z7ERarNyiXPYhbGK7/4d2TwrZyVzx7oZdvJ/HZGrS8t2gMC+tQV6Kpsc?= =?us-ascii?Q?U2l+FAurhK6/G3/5unDLR+j9HC6kv53p270fp0qVE0JpRWgLDMXZ6VSDuDg+?= =?us-ascii?Q?+OStdJnJ+Ws5UHH9p79mXSZUExKh/9OV33Qgz8BWRUIxNDJuRbRwHoTWoD8o?= =?us-ascii?Q?oOFl9P7WJFmMBIIY4fV701xOOrqAAE3PJfMr5CmW0OozW0U3ZMc43xadC58Q?= =?us-ascii?Q?U9PO0h29RwscT0KyGWC86Ew6hCWUsQ1j7x4DXE8NCu3Hn+jd5TtT9fGp/VL6?= =?us-ascii?Q?OLegDnO1tn/x53qKi/aX7uVzwsmXS2XAtB+0WEjjdTM7B/VeIW9UXRKD/kO+?= =?us-ascii?Q?gXmszt/M1h4A5Uc3f0GJxbyLXoWtD4iLNJGEMW7FAMPHX/rB/SGBSdIQSABa?= =?us-ascii?Q?Oug43E8u7ROEGO4xUsI7KvybgFJgokpjOydL+BF1k7meZnxsKBzYxCWA6nVW?= =?us-ascii?Q?/0wn45XNckoYBC2QM5x5iIfZ3nWiwbbugafyLCdkLVpZjxq7p5Sv0CqHH3cF?= =?us-ascii?Q?mOb9WK5ArP4BcFuQsRYeCfW7y63AdyiPJbxelNSOf1lcHKafqt+fEE+itbL/?= =?us-ascii?Q?d0NnCm68tUQ73FHH/RULT3OGXMjhITvBKd2jcfxncfDOzGT4kofkKQEVPOqU?= =?us-ascii?Q?pBXXT+A8naChHvy51p+NBbGrTnFujhQ=3D?= X-Exchange-RoutingPolicyChecked: DbHCi4orR44/yv9P3Lfd0WDTgEKEztu4hoczghI9RvHDco/3l02LtvILnb4M6wuselegc475ezCo9Ku/J74Jj5nMFRTfdHepp56k1RIIDShzEfOLdMf4cUaKfwIjSvgtxjBIjgtHYNOFEgOiGvdp5ATgqOBx9mB3NolMIH7iuPnsAesU9KCMlee7v7XiKMg9Ct2HFJRZYJkBfTOY4SRi43EIVodVZVuppHm5jicVkwkZL2OVp4rg8f5RnefLoxphCpBOr4zKWvmdpBKsE2oBaIEteKogsa7H1gwe+jTUt27M4krknakCigb4RZeyNI+0X66AKXYqnfAWbCCnb84XgQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 525295ea-35f0-4e80-d9e7-08df2dd94aca X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:39.8148 (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: 0CUHHnzwDBRch3z3tIQrntSsVJSk3xqBp/ColQt6ScJ9EzQBBwdA3g66kpuFoS6rXGinKTDAzc350i+vONxl0GVeJQp4n7zTOWzIhQCbzpM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-GUID: fETJ6sWnMpPBljEfzz3tQAM_5PC1jssB X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX37I1KdVv1TnN QKt88BesoLwIHscQIENzPILP5H4j8lRDl/KX4fXlLRQ/ulC9WtwrCXqz6fRWUf2klXwIvJrykvA Oxsn5NZZ/IIhKmtbR/RyEsDLhsYaWfI= X-Authority-Analysis: v=2.4 cv=E71YNqdl c=1 sm=1 tr=0 ts=6ad60795 cx=c_pps a=JUKW06bhoGHkwkYQWyoyLA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=RO_YwWr2CJXTu7lAkVcA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXyoVAkzyzjvOr 8otQFT8X8+ezDSLsr2T5j8C1/nUKtJTr3Yz3B2GY1R9gaEwO3zldOJFZvIpVQYwl9pQ9tfgRCNy Xm5onV6sbidBfYF8ZuWYv2ICgK1XnFtRcPLux4uv2ZAORpPFlleftyvnhmPoHPyOcDTlhhOkIWE Fzts3e7quoRg/yUL380vRmZAstNCuP23OkoTvcgj9vpmsDL4K0eg1oknZuoXwUe6ScnW2EriavL lzNhAXAL1XxRzt4hTviPJJ0s9/ZGNu/LVqOyfRb4x6Yn9SGz/wt2t7HDKrmVVkTFWCvuJLY9A2X SyLNXFHYSTGc+fPwqhmFG0eEZtnQx22czakIGhqAOXBESb1v8afjTHCYou8OFVTcNAQMKUgSslP hVrN2RgVxOcMMm/4HCKw1X683IZvlbIq4Dq+oiAs01gLyCHD2Fqui4BIYs5H890upkra6DCWWEC YM1KC/xzffLcv2pXiNA== X-Proofpoint-ORIG-GUID: fETJ6sWnMpPBljEfzz3tQAM_5PC1jssB 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1792411546-C475B757-A06D7E48/0/0 X-purgate-type: clean X-purgate-size: 3947 This device represents a single emulated 8259 PIC and its associated class and ensures that we can safely embed the device within a container device. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- include/hw/intc/i8259.h | 8 ++++---- hw/intc/i8259.c | 33 +++++++++++++++++++-------------- 2 files changed, 23 insertions(+), 18 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index 1921a30371..87ccd55a4d 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -3,9 +3,9 @@ /* i8259.c */ -typedef struct I8259CommonState I8259CommonState; +typedef struct I8259State I8259State; -extern I8259CommonState *isa_pic; +extern I8259State *isa_pic; /* * i8259_init() @@ -16,7 +16,7 @@ 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(I8259State *s); +int pic_read_irq(I8259State *s); #endif diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 856075a754..81827f2734 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -35,9 +35,11 @@ /*#define DEBUG_IRQ_LATENCY*/ #define TYPE_I8259 "isa-i8259" -typedef struct I8259Class I8259Class; -DECLARE_CLASS_CHECKERS(I8259Class, I8259, - TYPE_I8259) +OBJECT_DECLARE_TYPE(I8259State, I8259Class, I8259) + +struct I8259State { + I8259CommonState parent_obj; +}; /** * I8259Class: @@ -52,7 +54,7 @@ struct I8259Class { #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif -I8259CommonState *isa_pic; +I8259State *isa_pic; static I8259CommonState *slave_pic; /* return the highest priority found in mask (highest = smallest @@ -170,11 +172,12 @@ static void pic_intack(I8259CommonState *s, int irq) pic_update_irq(s); } -int pic_read_irq(I8259CommonState *s) +int pic_read_irq(I8259State *s) { + I8259CommonState *cs = I8259_COMMON(s); int irq, intno; - irq = pic_get_irq(s); + irq = pic_get_irq(cs); if (irq >= 0) { int irq2; @@ -187,16 +190,16 @@ int pic_read_irq(I8259CommonState *s) irq2 = 7; } intno = slave_pic->irq_base + irq2; - pic_intack(s, irq); + pic_intack(cs, irq); irq = irq2 + 8; } else { - intno = s->irq_base + irq; - pic_intack(s, irq); + intno = cs->irq_base + irq; + pic_intack(cs, irq); } } else { /* spurious IRQ on host controller */ irq = 7; - intno = s->irq_base + irq; + intno = cs->irq_base + irq; } #ifdef DEBUG_IRQ_LATENCY @@ -348,9 +351,11 @@ static uint64_t pic_ioport_read(void *opaque, hwaddr addr, return ret; } -int pic_get_output(I8259CommonState *s) +int pic_get_output(I8259State *s) { - return (pic_get_irq(s) >= 0); + I8259CommonState *cs = I8259_COMMON(s); + + return (pic_get_irq(cs) >= 0); } static void elcr_ioport_write(void *opaque, hwaddr addr, @@ -418,7 +423,7 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) irq_set[i] = qdev_get_gpio_in(dev, i); } - isa_pic = I8259_COMMON(dev); + isa_pic = I8259(dev); isadev = i8259_init_chip(TYPE_I8259, bus, false); dev = DEVICE(isadev); @@ -444,7 +449,7 @@ static void i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo i8259_info = { .name = TYPE_I8259, - .instance_size = sizeof(I8259CommonState), + .instance_size = sizeof(I8259State), .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, .class_size = sizeof(I8259Class), -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:05:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454133.1667657 (Exim 4.92) (envelope-from ) id 1xIm7k-0000eM-8i; Mon, 19 Oct 2026 12:05:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454133.1667657; Mon, 19 Oct 2026 12:05: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 1xIm7k-0000e5-3R; Mon, 19 Oct 2026 12:05:52 +0000 Received: by outflank-mailman (input) for mailman id 1454133; Mon, 19 Oct 2026 12:05:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7i-0000a0-Bh for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7h-001Hxp-OM for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:49 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad60798-8faa-0a2a0a5109dd-0a2a4503b420-24 for ; Mon, 19 Oct 2026 14:05:49 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6079c-fae8-0a2a45030019-94a39b0cdae2-3 for ; Mon, 19 Oct 2026 14:05:49 +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 69J8P2Kn3283490; Mon, 19 Oct 2026 05:05:44 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021101.outbound.protection.outlook.com [40.93.194.101]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc74ekjde-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:44 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05:43 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=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=NC5YHIoqeDTuPOLSBXYV5C5Nu9aU8ejNXoZBPcpn3 9U=; b=FRnIE8ToClMaQSjwqeHzseHxBxwQFgtMOpdVHk30nXLSmUaWZiiDhAwDf 2fh4vI6F+3AlM0HpqN6Wu5/z4wMPkKugMu4U4HtrswKUFGgIc1tjeZ4qnRUhtL3y mcCMpPDDQtYV0P57+pE7rJUo2OC2LDvqBWDXNN790vQWqiOxSNOYzNeLAQO6gsbE x4gk1Sze5o1FTtFKS0RCAveTSOBWQAj5014HRq4ZOPE/tnz9UJjgF0gH/6C4PqsM 68Gmui6L3S5jNsm0fqS05aYrsBxGNf6o+lJGK+e7v2I4mH+aGI+bowJ4/RGHhBLu tGivb+UJz1Vme4ce3h0p5Z0e7M2zg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GC79D5yJPJQBoXdpCwqWh7T8FX4ROVSChgA9Pxx8IAXalK1pO4zkSDYpXAnYGzj1kHx+QBystRfeTkT4tU0W0V3SQmr/W2gPnnT3dgl3GDxo2U1f174HEhjQHaOS49JVOysQ6pOAEEW86DBTExyWhQf4bsookxz6ZG9ybcGkRKjrFNyBlgm5nFpBoHsg26FPHr6ifd9eS+teuHr7aNiu9q0jfxI/5diWo5CSfRngk4bVbKUu1TGdeuZl3Vx3LRTqZ8fYDE7MeqqaK3MqfsBCftTDQEdEiFKX2lCrUv0um0NsTuNsgGg0SYMMZ1O77+SxGbWNy95g+DqQc4jRLbfNjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NC5YHIoqeDTuPOLSBXYV5C5Nu9aU8ejNXoZBPcpn39U=; b=AQxxJ/fsKlDXyHeOEgXSw3UW1lqrnqMSSoCtMy8EdVN8vccNmQ4Y3yD7tjjaW+9WZmrYK/R8mFNeU/UMK6SUrG7z20CWX4lB96dtP7oRn4kATWlDE7TanAuQTmNJCXBtPjs49Jp176bj3h3NJGNbp1tMNTD7TJW1orswLzGAgE5HGX8ZIEn126GjyVh9F1NSEdqpIi1g9rxGLcafvav0QcRoGSHO47kbYA28cfwnSq5IxCjHdIxsFvP3ja1AOL1JrMqxdomgAr170ROI0GO6BfwV+YWGAXJVLFvzYxYq1SQ/+Ch6hoxQGr83sekxyeSLixhs84BNAGksPszaFecQFw== 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=NC5YHIoqeDTuPOLSBXYV5C5Nu9aU8ejNXoZBPcpn39U=; b=pn9n4g/181E1gURFv2pfkYvawkYbATKfhsNiN4nAeM6fzUZ5YpNtUQCmWCjx7djbUMEQ433R4AFC6Ecy2lrEnEPb2PM8srxkUSO6uLlnn+hHafHBYqonScmIUZ+acnYngREerINlo57HsCwpCTvEuVvtPBbk2txLwG9h8+uu44H/UX4P7JskRznSYJncoT0FV3qx9ibLIuDDMefORrMYCyhl+8GYNXRiXS9jJ6ngqYzHNFxOXTYmvjDwBsH7XIXKLyQcbDo3S5beBHYBMk4l3HIThdoSPwRXuJVODCc9/Z7ORKwVBuu36JYQksXxPjk/YBGGyYj6ok0rIQ6ItAEAng== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 07/28] i8259.c: always use cs for I8259CommonState variables Date: Mon, 19 Oct 2026 13:04:39 +0100 Message-ID: <20261019120517.1448687-8-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ2PR07CA0003.namprd07.prod.outlook.com (2603:10b6:a03:505::26) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 07063558-9918-45c9-22bc-08df2dd94ca6 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|22082099003|18002099003|3023799007|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 244lBnMqn8Y+lRt36jQCrdSrC+IGROLolon3xNIfSdIItL7DabwGaxxnTG0TMyppg6pnKnniickaeOGHul4sQxN7zyi6FjakFlFzJBek2IQCcK99HWZiGa1GJPGo35HUbTP5x7AJPbDpjoG0iHStHIMo2olVyEOxim0mL6JAxuRJOqxOegJRrPNykRp9ppCaeY3YuFDqv7foJWtnIo72WzWaM4qNpQu8MUw25TIbA6LeVyja7KI5VGqYkQkwScax7jS2Io+g8PMJthzI6PhCegPXZmuiLIyvNgg7xf0t+dzSCDK3Ytcz8bAbQyvA27S2HpA/nRTGLYIouUJWxv33pjWzueUfbznG0sLT4f7pBKmlGmrznrMW2qWzH7A6+F+7b7gGer8961V65OkyehvGNJvcKEvDj6H+sAIsrWamOkiiZ2q+xt1FYkmWZnrMWjEPWAi6HpR+HA+ZCRRmkcXlebQm67hJjV9VDv6Hrjao6eIaP38xWZ7zeTNJ0r9xKsh1Ab0zsnQKD+UJbQ+UH2eb7TCMNOjRttpNiTv8MNAo+SUECTwrqjAmhrYSUIRHjB9byPPg5BcyvjC280W5f8AdK8IZfqbNo99TKxDY/ToSSL37oaB2joHwRgkX9AWddZ5FppcyT/mansICMX/0WbE01g/cZE5/AxNGFRRqROyvUF4= 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)(376014)(23010399003)(1800799024)(366016)(6133799003)(22082099003)(18002099003)(3023799007)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?8vqc64su6tj89wT0f8jbhXjdsDoDMb8+0n7xppAEYMCFd1C5avkrpZYu3ZrJ?= =?us-ascii?Q?IeW/p1v9FcE5Xq5ecFwNOiZ8f9idcsUCA0STYnVHbeAFto9p7MlbNgCNkHqQ?= =?us-ascii?Q?ad/Mjs56bqqTJgYbFJv57+12mfevzHSLG7muOrlrjKJ0gkScpb8gVp4FUoou?= =?us-ascii?Q?MGK/UAkWWuSSQlZfNnk+t3g7pC7Zd6Q+x/1fhJ2dm0YIXj9UTrdVnFBFr9VL?= =?us-ascii?Q?ak3JCHv+30Pcl9WBZC6U/6wF/0F4UMAi6wCJTLB+ajZKOFSDdwDbOLdkAkye?= =?us-ascii?Q?A4/vN4hR8mAOw3EYNYkzz4d7GpG+a+pQ2OXlexYHGFDKd7+IaLOB6mTOo2KH?= =?us-ascii?Q?wvJqW4VYGutwRy1/RgGNCmTWHV+4jXgunBzs9qJNZTWayKGnTQHgnq5eORIO?= =?us-ascii?Q?AOxv1CmzLP7EIxQbueFeMdj9ZJpvykugpFA6a9Oor+9TCzupWixVnYfFwdHz?= =?us-ascii?Q?n9R1CaeUDTidEV9NSlX6ES9oBGb0aE9E5M0EY+DSimfJgCR5Gto/7YAfyDUE?= =?us-ascii?Q?UTSwb9N9qbpWvUtWPdUpCae1VV019qBtaf5x0732wLkDkbX/DGOOaTijsHEb?= =?us-ascii?Q?3N3Jgz7uhUZbiygpBUbHV/ONQmcve42wdGFUh/CqpL/wprjJ2UO+ajqD1gl+?= =?us-ascii?Q?s738NhSui0V9Lnqf25hoeRPqRHiFq3HlaWL/68sKkhjHYfmJX68mlU9tArcS?= =?us-ascii?Q?rSCX4tmDgQvryotIry6H0K5+f/LnsWPaKOxZ2fFLeguHzKfKNVQ6ahCyCSR2?= =?us-ascii?Q?7We2lq/8HaIbmGo0t3ZfgoJUIIMHd5EnFfUlc/inIId8yp8smhlp+cEMyFxO?= =?us-ascii?Q?ed/huKhHrhXfHgayMZ1ujbzyOcswHklNib1Rfn5Zl/KdjA4VOD/EMjAKt9QU?= =?us-ascii?Q?FqzMgExA21PjQoCBHt5jGltHgLHa/vOTl8b/pLkX6grebF/4uRcHQuolAPWF?= =?us-ascii?Q?8ZI4bnyIqJkIZM2dIaIR/WeV7d6v4jzPNgOXStAJ3f/zu5up5ifPEefuG4Y8?= =?us-ascii?Q?3OCbpHGrbrfRLTtSP33YwTmAiYdGUe0u5APCH9SrGMc92FBOJZvZGy1vwU/E?= =?us-ascii?Q?6cVA0F+3rVgznfdQgSiZYZduRiAqX1PXBvPO/7i7yZwSE6Ltzv8q04geavHw?= =?us-ascii?Q?z+Vo3e+SnAiGjvsRZy+/q9gTJnkNo/A0Bwwf8HgoC2Iq1TZIaIkfNfyt6/wx?= =?us-ascii?Q?tnIUJuMYL02I+QAepptbcGLSzAyuxkvgxNxteQxk9NKfDyP4p1L5iFU7piTc?= =?us-ascii?Q?yYijokEDkyzV175afOmLdmxJhoEOQ79En5VzIa4SyGRy8AZquffD3xPDx8N/?= =?us-ascii?Q?/3aXec1CxapIOrc+gKJ6eP0S5jJ0P+/B3kI+4c1RBBJhRjaJGxVxO7IX/lIC?= =?us-ascii?Q?J75j/3wW0SIMpXXH++T3h88g0NJ4UKIP/bEo8yEuRLcTh6sF+t9U46RSpMHn?= =?us-ascii?Q?vXpq2brpDIex8s+uYuHHigBaIGlb9BY3jYOXr4TjeA433Jn/M0uy4a0ichTk?= =?us-ascii?Q?OPHrMjMQh8gF1DxxRR4Wn4whhBqJ3HhK1EqrWcIvXr9zySEtXr+Cay0s7J86?= =?us-ascii?Q?upLV/y3Ke8ie+7oeL+17hl+NSiX1olyM7SB+EkN5YouOFhve5fS1i+uK97c6?= =?us-ascii?Q?pswKP8qBQeQUExmboXzQDytuLR8yW5bC1TpwYxSvjNNZWTXKJ1eMQn33wlTU?= =?us-ascii?Q?uqu1hp+MzBtkfBXbsPrOmhXhW7eWuhzSx3byZIJ53egcDpcYAaoaIvJbAwta?= =?us-ascii?Q?EpTaWnzw/+MQ9RFLysNL2/Sbn9hlr5A=3D?= X-Exchange-RoutingPolicyChecked: x5ACcYjDWpeqlcJbkq9YQ9/y8Nv2sRC7OalSFGPokE59P6pY3PLKXLTDQSB0TFjhsDlPtAZqN+bJvxBIP1UlCEGeR9n1cXC+npxBOKk88uAUAtJ14kFwJ8InYRIDg6SGsECSbfzVHJbJesejUtiJgf/fVxvxH0wQILWUGEx4sRG6xm3wrm621HiS8v3Wk6wS/eFG1EDBz/Cvk1blDDJApR3juHUhUyEQNdVBrmx2g26yRdgsmWdn/XbZao/ewb/jwOoEWJHfD9c/hVlW6IxxC5rE+FZWS0DcntFdi6Ezbha+6wcfRLJ8uivfvqtT4CZmSIuNiztUidllVMtroz4m2Q== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07063558-9918-45c9-22bc-08df2dd94ca6 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:42.9315 (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: Wry+5EFmt0TqmLZAqbj7qMuTw6fb+uB1dcG5maJrtWhxHk2iYlxTKqAvEkcu9g81TtU8nIRh3Yrfo0wYLwJ8ovM81ZYa4rQqmRDI0zpKrkk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-ORIG-GUID: uIwzEKv8Xq8kfnRRKodO2WM-WSlOXeK0 X-Authority-Analysis: v=2.4 cv=HYGB3SE8 c=1 sm=1 tr=0 ts=6ad60798 cx=c_pps a=+kXwOJT9iXP9BgnuWAWdUA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=zV1iqHTY6MOlpgDiNWkA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-GUID: uIwzEKv8Xq8kfnRRKodO2WM-WSlOXeK0 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX66pxBqu2UxPH mNqmiyt39EFg37e2Rsv0SWq5tJX85EucWGgX1jwxcEyDtU0h+aOsP1L4sHs/QE+Owxkz2Dy4s4c vHfUTRqeGMG3iHTrFEFerlINBfTB0Pc= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX1WpSfkzR+T3b yeMAebXdKFw/lYn2tHoYifqjywXUZVNMkfy+Axc12HBY4oW0AikvpXP/rx96OlXJUbm+59Y0kjL y/W7RgL3UES2dPOXqpXOmnzVxdHrovVlcMn48bqFpO3CciXMyiJ5nkJMkRrXA+wDLItDc2ShOn6 FZZzmAccpbLwZTJLlMj4+jNcfSwR4kgSc0o3MC4rFws5nNcrrfs6cHMkWiypnTYRBIRdc+ilUaa 4ogPxwZiG6HUGuK9tMo3yZj7os5PL3G2g44JaS/9lsgmYndZVC4QHNq4zJPXcQvyfN19egVaB5S 0H3fNC8OqercdzBfOS/1XkwX8srJVUkWv1gXzfDJ4dUf4bhl+O7rE6fnY/xNjHgTiub5GKpZxg9 zLcodQ6IsYPQHZPqPOtu6JNK6fVqgMvbckiV+sIrTWDVRwNP2goTbGEu2+HPxRvtxkxDwVu75ho EzoxJU0TQDxmJnTdWDQ== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-33051d/1792411549-6CEDA4E9-36B5B5F7/0/0 X-purgate-type: clean X-purgate-size: 13006 The use of consistent variable names makes it much easier to follow which fields are being accessed from I8259CommonState. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/intc/i8259.c | 192 ++++++++++++++++++++++++------------------------ 1 file changed, 96 insertions(+), 96 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 81827f2734..700412df74 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -59,7 +59,7 @@ static I8259CommonState *slave_pic; /* return the highest priority found in mask (highest = smallest number). Return 8 if no irq */ -static int get_priority(I8259CommonState *s, int mask) +static int get_priority(I8259CommonState *cs, int mask) { int priority; @@ -67,63 +67,63 @@ static int get_priority(I8259CommonState *s, int mask) return 8; } priority = 0; - while ((mask & (1 << ((priority + s->priority_add) & 7))) == 0) { + while ((mask & (1 << ((priority + cs->priority_add) & 7))) == 0) { priority++; } return priority; } /* return the pic wanted interrupt. return -1 if none */ -static int pic_get_irq(I8259CommonState *s) +static int pic_get_irq(I8259CommonState *cs) { int mask, cur_priority, priority; - mask = s->irr & ~s->imr; - priority = get_priority(s, mask); + mask = cs->irr & ~cs->imr; + priority = get_priority(cs, mask); if (priority == 8) { return -1; } /* compute current priority. If special fully nested mode on the master, the IRQ coming from the slave is not taken into account for the priority computation. */ - mask = s->isr; - if (s->special_mask) { - mask &= ~s->imr; + mask = cs->isr; + if (cs->special_mask) { + mask &= ~cs->imr; } - if (s->special_fully_nested_mode && s->master) { + if (cs->special_fully_nested_mode && cs->master) { mask &= ~(1 << 2); } - cur_priority = get_priority(s, mask); + cur_priority = get_priority(cs, mask); if (priority < cur_priority) { /* higher priority found: an irq should be generated */ - return (priority + s->priority_add) & 7; + return (priority + cs->priority_add) & 7; } else { return -1; } } /* Update INT output. Must be called every time the output may have changed. */ -static void pic_update_irq(I8259CommonState *s) +static void pic_update_irq(I8259CommonState *cs) { int irq; - irq = pic_get_irq(s); + irq = pic_get_irq(cs); if (irq >= 0) { - trace_pic_update_irq(s->master, s->imr, s->irr, s->priority_add); - qemu_irq_raise(s->int_out[0]); + trace_pic_update_irq(cs->master, cs->imr, cs->irr, cs->priority_add); + qemu_irq_raise(cs->int_out[0]); } else { - qemu_irq_lower(s->int_out[0]); + qemu_irq_lower(cs->int_out[0]); } } /* 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) { - I8259CommonState *s = opaque; + I8259CommonState *cs = opaque; int mask = 1 << irq; - int irq_index = s->master ? irq : irq + 8; + int irq_index = cs->master ? irq : irq + 8; - trace_pic_set_irq(s->master, irq, level); + trace_pic_set_irq(cs->master, irq, level); pic_stat_update_irq(irq_index, level); #ifdef DEBUG_IRQ_LATENCY @@ -132,44 +132,44 @@ static void pic_set_irq(void *opaque, int irq, int level) } #endif - if (s->ltim || (s->elcr & mask)) { + if (cs->ltim || (cs->elcr & mask)) { /* level triggered */ if (level) { - s->irr |= mask; - s->last_irr |= mask; + cs->irr |= mask; + cs->last_irr |= mask; } else { - s->irr &= ~mask; - s->last_irr &= ~mask; + cs->irr &= ~mask; + cs->last_irr &= ~mask; } } else { /* edge triggered */ if (level) { - if ((s->last_irr & mask) == 0) { - s->irr |= mask; + if ((cs->last_irr & mask) == 0) { + cs->irr |= mask; } - s->last_irr |= mask; + cs->last_irr |= mask; } else { - s->last_irr &= ~mask; + cs->last_irr &= ~mask; } } - pic_update_irq(s); + pic_update_irq(cs); } /* acknowledge interrupt 'irq' */ -static void pic_intack(I8259CommonState *s, int irq) +static void pic_intack(I8259CommonState *cs, int irq) { - if (s->auto_eoi) { - if (s->rotate_on_auto_eoi) { - s->priority_add = (irq + 1) & 7; + if (cs->auto_eoi) { + if (cs->rotate_on_auto_eoi) { + cs->priority_add = (irq + 1) & 7; } } else { - s->isr |= (1 << irq); + cs->isr |= (1 << irq); } /* We don't clear a level sensitive interrupt here */ - if (!s->ltim && !(s->elcr & (1 << irq))) { - s->irr &= ~(1 << irq); + if (!cs->ltim && !(cs->elcr & (1 << irq))) { + cs->irr &= ~(1 << irq); } - pic_update_irq(s); + pic_update_irq(cs); } int pic_read_irq(I8259State *s) @@ -213,81 +213,81 @@ int pic_read_irq(I8259State *s) return intno; } -static void pic_init_reset(I8259CommonState *s) +static void pic_init_reset(I8259CommonState *cs) { - pic_reset_common(s); - pic_update_irq(s); + pic_reset_common(cs); + pic_update_irq(cs); } static void pic_reset(DeviceState *dev) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); - s->elcr = 0; - s->ltim = 0; - pic_init_reset(s); + cs->elcr = 0; + cs->ltim = 0; + pic_init_reset(cs); } static void pic_ioport_write(void *opaque, hwaddr addr64, uint64_t val64, unsigned size) { - I8259CommonState *s = opaque; + I8259CommonState *cs = opaque; uint32_t addr = addr64; uint32_t val = val64; int priority, cmd, irq; - trace_pic_ioport_write(s->master, addr, val); + trace_pic_ioport_write(cs->master, addr, val); if (addr == 0) { if (val & 0x10) { - pic_init_reset(s); - s->init_state = 1; - s->init4 = val & 1; - s->single_mode = val & 2; - s->ltim = val & 8; + pic_init_reset(cs); + cs->init_state = 1; + cs->init4 = val & 1; + cs->single_mode = val & 2; + cs->ltim = val & 8; } else if (val & 0x08) { if (val & 0x04) { - s->poll = 1; + cs->poll = 1; } if (val & 0x02) { - s->read_reg_select = val & 1; + cs->read_reg_select = val & 1; } if (val & 0x40) { - s->special_mask = (val >> 5) & 1; + cs->special_mask = (val >> 5) & 1; } } else { cmd = val >> 5; switch (cmd) { case 0: case 4: - s->rotate_on_auto_eoi = cmd >> 2; + cs->rotate_on_auto_eoi = cmd >> 2; break; case 1: /* end of interrupt */ case 5: - priority = get_priority(s, s->isr); + priority = get_priority(cs, cs->isr); if (priority != 8) { - irq = (priority + s->priority_add) & 7; - s->isr &= ~(1 << irq); + irq = (priority + cs->priority_add) & 7; + cs->isr &= ~(1 << irq); if (cmd == 5) { - s->priority_add = (irq + 1) & 7; + cs->priority_add = (irq + 1) & 7; } - pic_update_irq(s); + pic_update_irq(cs); } break; case 3: irq = val & 7; - s->isr &= ~(1 << irq); - pic_update_irq(s); + cs->isr &= ~(1 << irq); + pic_update_irq(cs); break; case 6: - s->priority_add = (val + 1) & 7; - pic_update_irq(s); + cs->priority_add = (val + 1) & 7; + pic_update_irq(cs); break; case 7: irq = val & 7; - s->isr &= ~(1 << irq); - s->priority_add = (irq + 1) & 7; - pic_update_irq(s); + cs->isr &= ~(1 << irq); + cs->priority_add = (irq + 1) & 7; + pic_update_irq(cs); break; default: /* no operation */ @@ -295,27 +295,27 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, } } } else { - switch (s->init_state) { + switch (cs->init_state) { case 0: /* normal mode */ - s->imr = val; - pic_update_irq(s); + cs->imr = val; + pic_update_irq(cs); break; case 1: - s->irq_base = val & 0xf8; - s->init_state = s->single_mode ? (s->init4 ? 3 : 0) : 2; + cs->irq_base = val & 0xf8; + cs->init_state = cs->single_mode ? (cs->init4 ? 3 : 0) : 2; break; case 2: - if (s->init4) { - s->init_state = 3; + if (cs->init4) { + cs->init_state = 3; } else { - s->init_state = 0; + cs->init_state = 0; } break; case 3: - s->special_fully_nested_mode = (val >> 4) & 1; - s->auto_eoi = (val >> 1) & 1; - s->init_state = 0; + cs->special_fully_nested_mode = (val >> 4) & 1; + cs->auto_eoi = (val >> 1) & 1; + cs->init_state = 0; break; } } @@ -324,30 +324,30 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, static uint64_t pic_ioport_read(void *opaque, hwaddr addr, unsigned size) { - I8259CommonState *s = opaque; + I8259CommonState *cs = opaque; int ret; - if (s->poll) { - ret = pic_get_irq(s); + if (cs->poll) { + ret = pic_get_irq(cs); if (ret >= 0) { - pic_intack(s, ret); + pic_intack(cs, ret); ret |= 0x80; } else { ret = 0; } - s->poll = 0; + cs->poll = 0; } else { if (addr == 0) { - if (s->read_reg_select) { - ret = s->isr; + if (cs->read_reg_select) { + ret = cs->isr; } else { - ret = s->irr; + ret = cs->irr; } } else { - ret = s->imr; + ret = cs->imr; } } - trace_pic_ioport_read(s->master, addr, ret); + trace_pic_ioport_read(cs->master, addr, ret); return ret; } @@ -361,15 +361,15 @@ int pic_get_output(I8259State *s) static void elcr_ioport_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { - I8259CommonState *s = opaque; - s->elcr = val & s->elcr_mask; + I8259CommonState *cs = opaque; + cs->elcr = val & cs->elcr_mask; } static uint64_t elcr_ioport_read(void *opaque, hwaddr addr, unsigned size) { - I8259CommonState *s = opaque; - return s->elcr; + I8259CommonState *cs = opaque; + return cs->elcr; } static const MemoryRegionOps pic_base_ioport_ops = { @@ -392,15 +392,15 @@ static const MemoryRegionOps pic_elcr_ioport_ops = { static void pic_realize(DeviceState *dev, Error **errp) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); I8259Class *k = I8259_GET_CLASS(dev); - memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, + memory_region_init_io(&cs->base_io, OBJECT(cs), &pic_base_ioport_ops, cs, "pic", 2); - memory_region_init_io(&s->elcr_io, OBJECT(s), &pic_elcr_ioport_ops, s, + memory_region_init_io(&cs->elcr_io, OBJECT(cs), &pic_elcr_ioport_ops, cs, "elcr", 1); - qdev_init_gpio_out(dev, s->int_out, ARRAY_SIZE(s->int_out)); + qdev_init_gpio_out(dev, cs->int_out, ARRAY_SIZE(cs->int_out)); qdev_init_gpio_in(dev, pic_set_irq, 8); k->parent_realize(dev, errp); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:05:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454134.1667665 (Exim 4.92) (envelope-from ) id 1xIm7m-0000xA-ON; Mon, 19 Oct 2026 12:05:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454134.1667665; Mon, 19 Oct 2026 12: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 1xIm7m-0000wx-Jh; Mon, 19 Oct 2026 12:05:54 +0000 Received: by outflank-mailman (input) for mailman id 1454134; Mon, 19 Oct 2026 12:05:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7k-0000eP-Bh for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7j-001NWD-OC for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:51 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad60798-bab6-0a2a0a5309dd-0a2a4508b538-30 for ; Mon, 19 Oct 2026 14:05:51 +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 6ad6079e-f659-0a2a45080019-94a39b0c2e22-3 for ; Mon, 19 Oct 2026 14:05:51 +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 69J8Oqxu1634764; Mon, 19 Oct 2026 05:05:47 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021095.outbound.protection.outlook.com [40.93.194.95]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8bckg9m-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:47 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05:46 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=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=drx0lsfaYXto4fur9J5UEnuEWZKokyx4yjlzBKisi t8=; b=sJmOHSAPXGyf8aQFmmJMhm2vbZ5+4dGgTRml2i2DqEfyJvixALKBzjerr K6CWHp+wkMlIUxhzQs1Vbg4gJft3VjInLCXHZ6VlqcaQBGsBxV/AHW25avWFvDRz OrvMqYawzaBpObco11UIuKszTc7IdCvKKkhg+6EZQdYbU6fAwmSzmw2pjjkeFuBb g1ftF6LS96cF+svYvcTy8nkUl0GNheD9zSRYW16MQ3SETMyPUAC/1YwfuhEyr4GZ rV/XIxBvQL0CgzRRmnI7Ht+10e/L/Zf7Z+6qIjjVeOmbFGtx7pygnpsdOMSTzKy8 1nuBTLQqA14A+Ve2nTxgU+GXxtt7Q== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=O6zBofYKi3dPp6X70gY6Qgw7B4IsSLZAVPDPBQ6VFRYh+auWCH3CzxjhS02YxG3iTilctrocoCkNmsSYhwQZS4AcnZF6lmURQzKTJciUtW0AcYPWpegyUYcJLrycmVxWv1iEwEDbm68CHOhzUWoV35y4PRKWkfki4OFs3yJZCqPqJZz5X616cdVR9ZvMR7TSFkeUbOzIlsZkCh/YpBFcB2FviUz0q23sfI7B9wWuxrA5OugJrAT91loPsjdETvjlPLz1BBtizhbWnwJ6dKmS7tJk1Kx47BHtyje8fDO3OQ3Amm7kNaHYdfedZ6LQPJMcPVh8WKoMJV2C3FF/vNttRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=drx0lsfaYXto4fur9J5UEnuEWZKokyx4yjlzBKisit8=; b=MRqkEWPfeSkJKYWq503Tl39CR0JQiU0sH21saAiAJAQ1AlWwZHXLnQBeZszjO5zWeNi/JKg4zg65A+oZDFWvJbXM7Mvw1qk4235ODvqShuKTd6Xs5aQ5gvwQp5v4qlQFopT3uLkMuuBPKCID8+M7gD//XqgNgUYZUKVvsG8ay9t4CUpVUBmyvzfo1eCyAZfnbVYI6s5+s5y0kE2J5qy59uwocXtRR0XJVl7e07tnu5TUkzXaUn0sYjeunuoYXmC39C3P03gwp5MbUSsm8/PIgA1GaUYl9391ZMf3kBekQnHD8u903bA7+Q1SmHa5V/O4pvgQTEakJm+fBnKQErPdFQ== 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=drx0lsfaYXto4fur9J5UEnuEWZKokyx4yjlzBKisit8=; b=L7UYfFSOSDhSP/tDSPJdHKq3YkcIlKX4c8bOPYIwJzJgx8squBo0gCaPIZgrRPE63gse36GEpPGudBREZraYnTyaibDEf8fR3kS2PUZM7zANfbicTH/BLhChDeJclyQjXHBXUfxmVVl6aIDJq85BYw+HjdHj4ppRT23CDsQl6LbBGNwx7nb0c1tSDx8sABA7AsxhLxVylpX9F7FE7ERB11Kn4lsYuwEWncz19qTYxGWW48sK6sMpYwFGTW2EfYPBshjQ4JOxtSXSjWg1zMf7x0ljDbSksy9xOXSXmqTdc1s857kReRWtdhc5Zss68Gtqjb8JhDmPMHK77qUm8rNzxw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 08/28] kvm/i8259.c: rename KVMPICClass to KVMI8259Class Date: Mon, 19 Oct 2026 13:04:40 +0100 Message-ID: <20261019120517.1448687-9-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0217.namprd13.prod.outlook.com (2603:10b6:a03:2c1::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: ba7cc0b4-95d3-4151-2fd7-08df2dd94eae x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: rAkcBHcpKFjvAbDUEiZF6ymGHrR/0oPd3ZsqwUkX9yQScvcXQ+19quMsparrZaz/dQft8AMaMHLxJLSjJj+CM4mCns1ivDENab5HAaV39HLMsi3Rht5FZLF1cWqizlM90Vsm+007aR8idphnbkglHOdXsyBtpnfN8JDC7//CM0i9bOEpm5MB+DHlL3EyP2Snx/ATo8b+1cA7VyMoy1mgmQt9DXryqZAYcJS+jAVLzqVuhX9A/C1ZjC2AMurJIZCO5cArzhnPjKe5XmQ43EF0sMIvl0XsIb1+LZcP/5zqTGTHd+ISxwz/2fSdLEhZ7wACooChrhVxp1Y+spK6tkylu9m8r1mZKI1aJb586afO7jG9ebQTbIb71AXDHGS+Z2y+mQHaDq1qbxLX9GateP9zqtRFxeVkD4s0pHVzfwvbjL0axqyzfiUooAWdOXaXciHEgUmFtRAn3wGdT8DksQTlyS/B9SqXq5/JUCVpCJMaCiJNbBuDRUxncK7jDbM4LiFCIhxy0lBnTq6+B3wHB2OFjShXF4uPnbGi84Qs5iqFTj/oGtMgZ5XfAa/ZGPHeqWq6k/LXy/1uR0o6OoVHAs0vZQuj2wjVG60Nof5bD61s3S6zYS+AKYIEAn+QkFKZScmGc/8wP2+Hpo2/aJJXxSUzFqD6aBlFIcAvh0anzAXROHs= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?idnnE6SPfbqqkUd/FAFT1rOWZRM0sTOEKM+5lrUTZ40FyWn+bohrEy7pmmwa?= =?us-ascii?Q?vEfj9VSH8GU29QT1a3A1dl+oAZs/8f+HlZw0V033kEaL8rZh0c/zIbF1ji6e?= =?us-ascii?Q?4yO18mD+tD5RJFR2fT6mG3Cl68L3XeiLhDxat6eQZV3Uj1YzpbH7Yekti2pS?= =?us-ascii?Q?77zZN/NE0JPt2l0D0NrD5Eh6LvOvxSuq83+KB+a7jCXhDAwFvQGbR1GaEiiK?= =?us-ascii?Q?PRL8FBuiL/rj1HIdQxMJ17aD2CbvniWWrwDbA4aknM8C6Io281zbQWsRYU0t?= =?us-ascii?Q?EHH9tTLY+cX1WQpf9wjX6HnRvoTKa7UjwFgb7b6f0PVUPTpaqYaTwbgCWTzb?= =?us-ascii?Q?oA91WU/Kd47pRw1rZi9crYsIC2ErU9TaxyiSLeIulCifRZ03Fx/LtcH8G0RU?= =?us-ascii?Q?NgA0is0Hln/drrv88sNUqUI/pSGNUzpnU/Xz8gzUizvsan5Byhg7vLDRuS87?= =?us-ascii?Q?j63N6nQ9kuW/J2xI6rPzWzYhJ7/u/wvb/GddZrFSZULNsvb6wUdX7fUasgKR?= =?us-ascii?Q?bMI4w35HF5q3QaPfsWRpqiiMQ3OuCxKAQbuFjT8cKwv3WwVPzGPZvNRghese?= =?us-ascii?Q?G0pHR6Xuw6hKRTeLlP+qGzO8iJTtLbYHAX4jUXu4RBpeqp/te+UtRiEU5IZr?= =?us-ascii?Q?T5NeOTGkEnnowd+/r3G984WMiqEIyHQyO3V9/JZ6ZWRQdZLuEHEJJhA6h/60?= =?us-ascii?Q?LX+Ak1M68dxn0vRa3RYVcZmdU28t1JXOZC6lCzt+k9IAh9g2ZY/S+cRK/cIT?= =?us-ascii?Q?cAsykxbVUFiXzdaeZNqaiCuwzePjOPIsnRXFvzUFeXWRICNY8IVNAEUCLMFW?= =?us-ascii?Q?d14yeq0zTqWI1JoY4uMvdMeu5HUCe1gU9mm12JG4/fuo5BLQEfP4Oq2dBbPC?= =?us-ascii?Q?OT4sueRcYG2GUELx5oBUECgIe80O5TpMmy5VT+ou0KcUSbuIazIbsSh0sGlR?= =?us-ascii?Q?T5Qd1bvWvsgCqHysSqwiX6SqWluekAkbxSMd4oQc3NTZ00tRLe7krofCIx7h?= =?us-ascii?Q?Yep+9oEv4Zl80ZeW5pW/jQzgvObqyC+OdDKqQRoqBgldgHbvxjoDP3vs8kQQ?= =?us-ascii?Q?8Q+m6RhXboW3UQAbbNophPfKWdpOq92v3MZn7Cn4hX/AA5rWneGYkBuDl6L3?= =?us-ascii?Q?CnNnowU2BNAlnFXAjKb+INbUz4lBlpGzltZ71bRxQPo1WL7Qz3NotTLlQtwO?= =?us-ascii?Q?Lr8Cz6TUzWX+jULy70OAAIjviZnL0+m+E+wtwpkwJpApG9cC8HHe3XA4gzk2?= =?us-ascii?Q?C2+Z4ivvjZDHMnZSg+D8EWuzvdUpnuj4VD6mTdVn0nNKYSPhe5oIqmDgdRDq?= =?us-ascii?Q?thlexRroW5SytE4zRTJJJAFRcUU8Og5dfZ8ZSA9BQY3eWC7ql5cnWRRGkqTt?= =?us-ascii?Q?Wgy7y7i5VmdfC6nVBj9NYHs6xEo+swtVUkZGYkYlm3BDDEXz4BWKf6+ZuD0o?= =?us-ascii?Q?dCP657DMS1KpVMExGbn55oGYwsGq/V/GlNAo6ncE77RXaSCwHb2JrL5o09Vd?= =?us-ascii?Q?A1E4f8hSSTZwHDa+mEkhHkalVpCI0NT13z6+f/7vGXnG1X0lgSDAx6c4dGaf?= =?us-ascii?Q?p90+qZp01y//HQlF0TpSP9ZF5NVGrBleRQNhtiYZA58G1PsV+TwYdIdaxCYL?= =?us-ascii?Q?VuqWc5ovmyCnFC6NVgkjrKehWc4DQIVS3niBfkcDCwnA3LTNkFZNaNNXd5JK?= =?us-ascii?Q?Jpwiwqzfkonlx9CFwOI/9NWw+srhid91zIzwJnKZqHXjo2RG8E59uawSznvh?= =?us-ascii?Q?xJ1NVcNw4bbUJStbmeSbD9X01LRqiCU=3D?= X-Exchange-RoutingPolicyChecked: gdG1vpSCGuu1COSNy1RKZ5qHpLPFhDDn2K8G+KNWEpHNt53tqtVX+Df/knCDYDQpZxK3L6rYAGZzNG2TecS+nZj3jQI2eoUMGIapBOoQ3sWh23UHWb+wKGdpY6yhdQb+BIiJnF9c2seJ/CKWqO6isPZxxeQHgSMjB7YcwWDM9lDGkQkg+09Vnc7x7ugPATqqGLzFkmaJqjAVuLgii/tOnIuqlK6Tk7+gALwSevu+Z+sLAilxM5mk8ZFXrc2HxJNg9/TZtfUynZBQiGIr5p0tz+6fUPkvKrUG4f6BGKuXaP7Xy4wQptToyhCAk/meKlkUPwy3YJCPh0BSH+/QeSKTGw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba7cc0b4-95d3-4151-2fd7-08df2dd94eae X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:46.3475 (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: kX63DMntPG+1+dfZTTdmfablt+CTcgL6iDRqMFWrXMU7SXvUVVSfTQW4yn2fbjE68LVSqp3eSCp/L4EjTfXviAsM+6gQJ0WktABk7vLZJbI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXwu/UWJZXPQ1j NIT2wIL5d1sIvsPSwwAfGOSWr9NbvfzZDZ3vKqJG0jJdyUGfz4G+h52oeSVUL33NCpTy/D4XTfP 1ua1255p1J0U81dvNhLfednB9k/yPzY= X-Proofpoint-GUID: 1NL8JWMdS3tyls2_Ymwo6JXZS_lYFP7C X-Authority-Analysis: v=2.4 cv=V8joQuni c=1 sm=1 tr=0 ts=6ad6079b cx=c_pps a=KKEi/m33+wCRTXJOHCufbA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=7JMAGyXtUfIWgoDCk_YA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: 1NL8JWMdS3tyls2_Ymwo6JXZS_lYFP7C X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXyTUTINSyfUp1 WZ+bjReQq0pS6EAyPNBaV3F4KSMKKmcoSnPVU/3Bb5Y5YIG7ad+l72meBsJCxazO7d+FIRy03Tl 402ZdviACRXTq2hsw5rvgKYY9NeE4RwDKeIy+oOOG0YFgVHTAiuRkr2kZ/Y+7I9Zw1NWKbhHd5/ E9hR0tJPXsSFT+5iiDNNW6YOlxcKD+2ulUkvDPwngKMC2LzPcno8MGADwI6myZt5/DoS3QrH7sV T6C6to32x5sTXusTXjGloKg6FdxxAZApdf+AK6iZoo96r2E4HdubB0UKVJ2ptd1vWu/o3Ylck5Q ekQHetB/XVo8OPhI7VHFwPag8MCKykCRrZD/hCkT74tI+Vu/pV1JQ5u33cbTfOXA2dj6IaDU7ra AvWG6PKjM10yDFvJHyr2TKPc2ecthiSzljFq45WeQxFWa0ASoav55N11W9TT1dL1CzC0ysfftLR Goqhjfiroo2LO3elmGg== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792411551-D497287B-78D5DAF2/0/0 X-purgate-type: clean X-purgate-size: 2134 This is in preparation for its use within a QOM type presenting a single KVM 8259 PIC. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/i386/kvm/i8259.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 68607d721d..85176dcf80 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -20,15 +20,15 @@ #include "qom/object.h" #define TYPE_KVM_I8259 "kvm-i8259" -typedef struct KVMPICClass KVMPICClass; -DECLARE_CLASS_CHECKERS(KVMPICClass, KVM_PIC, +typedef struct KVMI8259Class KVMI8259Class; +DECLARE_CLASS_CHECKERS(KVMI8259Class, KVM_I8259, TYPE_KVM_I8259) /** - * KVMPICClass: + * KVMI8259Class: * @parent_realize: The parent's realizefn. */ -struct KVMPICClass { +struct KVMI8259Class { I8259CommonClass parent_class; DeviceRealize parent_realize; @@ -123,7 +123,7 @@ 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); + KVMI8259Class *kpc = KVM_I8259_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); @@ -141,7 +141,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); + KVMI8259Class *kpc = KVM_I8259_CLASS(klass); I8259CommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); @@ -156,7 +156,7 @@ static const TypeInfo kvm_i8259_info = { .parent = TYPE_I8259_COMMON, .instance_size = sizeof(I8259CommonState), .class_init = kvm_i8259_class_init, - .class_size = sizeof(KVMPICClass), + .class_size = sizeof(KVMI8259Class), }; static void kvm_pic_register_types(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:05:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:05:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454138.1667675 (Exim 4.92) (envelope-from ) id 1xIm7q-0001IH-1z; Mon, 19 Oct 2026 12:05:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454138.1667675; Mon, 19 Oct 2026 12:05: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 1xIm7p-0001I1-SY; Mon, 19 Oct 2026 12:05:57 +0000 Received: by outflank-mailman (input) for mailman id 1454138; Mon, 19 Oct 2026 12:05:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7p-0001Ex-2s for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7o-001I13-Fe for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:56 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607a0-2eae-0a2a0a5409dd-0a2a450bdfca-16 for ; Mon, 19 Oct 2026 14:05:56 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607a3-b7e8-0a2a450b0019-94a39b0ce2f8-3 for ; Mon, 19 Oct 2026 14:05:56 +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 69JBnPVf3621740; Mon, 19 Oct 2026 05:05:50 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021097.outbound.protection.outlook.com [40.93.194.97]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hdjnwr1es-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:50 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=ScSUOPYT2VXd+Q6cH3/bep7d5eWaNHxgYFZkUb/8Z EU=; b=GTxpoa23rY2QKqWJW+wFFla1fUWhEa16jgEWLB0t5rxhydS+t2c22Ehef A4aMM+0vRZ7SrXFPshGtDPi67bSQ3YcEC1tu0senvfLVWmpUoMKIUch7d23wPBlE qYbYXuuLNZ62YMw+Z8DSHKuZzoSug1wh7bKAM/3qh49CPuEHfHJYhbSGnLYbfThT +l5MfvphorjUcVFGvt78VGLwYCFZGNH/9DhjiLn5kNsIi6M69xGALX/RWpumTEZC bY9+3x1M5Lah6t1iUpv/2Ep8o5Zm7zXsvc3xnyn5bq42oObW7qbjsMr6VU5SYXvd TVt28BOGQ/yoe4vDb4CcjpF/XDIvQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qlpz/UFe+RdS0FR6oJmhnRPpDF16mf8F3dwCcMJ6jL0VMY+HrW9zfKDJsDQiKn3zSDCCP5QLEsClQ/t1wgh5gu2EANi0RMjvhkdp6wFdRBNsPA647n3ySki23jHnYEbY0kaTNXiZsN+bSl9iOy8F1Fn/YxUiut0PCq/sGKbpJWjPeBoc6nh1Q7skH5Dn+UnuEOHVcCAF32wTe80FJ0u5tIzzA3EOsLfk12kPsldDSI+H606XIZxWcGokNevOhoSBQSlmNS21X22rybn5Faw2IkkE2gFgGW7puSQnmlh0Ye2hod/0h+rhYFZ8haXk1tInAIIr89p0+6iHZsx0nQ/M7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ScSUOPYT2VXd+Q6cH3/bep7d5eWaNHxgYFZkUb/8ZEU=; b=hoya9K247r3pUTkN+x0wOwgBRPQA6qRlOzxpA7SB/4TnO2MouETRvv7Shm5XaHaIKTWZ+8z1bRLnfvfAmf8gYUONEHemGP+fiDYfkMufiYcWoQIpNez3C2BGaCqXy3Yhh4U7wjjTBeO3EbZSqs9praGW07CJJC55niyUBro4LUqRkZM983wVwLOa5xx9ep0Wtyeg2WnQVMPhxvojEmV00BquAbBj6Jk7giYfknn6ux1rsGYta6XHmnBvdCesGSYoWQywTmk6Bcwz+G+7VNAUfT9Pr1JxospL30vrHVM0XrM734N0fHOJNLy8Sullj3LSg8u5VCeUbU4MwePc/1WpXQ== 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=ScSUOPYT2VXd+Q6cH3/bep7d5eWaNHxgYFZkUb/8ZEU=; b=MTP0mSZOPLbKHG+gps3/QtpDpuJMRpAODV+tdkqBX28/2NYmejaCuVh3gOBHhIzik0lRvpClNfm+BODg/MR5GASoK5zwvsHPz6pp9zTUXZNDRZZVru16Sx0B+oHNxpSM8TfpKZAvZndcTG849wsvzMaouqa8GNbJ55jo1ySYUqiIgALpAuBtBI3OsDpOLSfhf+WoEvzUnA3hL4tzjBiHxjf3ctMByvuq+TAy00cZC4Rq0fEhbtQid6iDMTKmtElHgHYVKDApbQDul+u66g/4+kXKDskGqb7wb8ke97TLqDFrKJiqzBqThDtGTcQYcSP7x9kqckLqCNdlR6+hlTBN0Q== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 09/28] kvm/i8259.c: introduce TYPE_KVM_I8259 device Date: Mon, 19 Oct 2026 13:04:41 +0100 Message-ID: <20261019120517.1448687-10-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0084.namprd05.prod.outlook.com (2603:10b6:a03:332::29) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 31cd589f-830a-4862-a263-08df2dd9509d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: e1RDOhTkXSoqcDiqVrXCY+ss8VN/bfmXdsVYkCxMeAd4xb4ZeoCS4TPKUhzb/E83Kle784vTyoxngGs4DwOu3/O1Qm5haWhReNACqgn7T/uxjt1+JbmiLrMK+26/ddrUqgzNKttPGNPs5vApLUZ3Wxxb47EDJ9/Ka2A9SUpcOyG/ihmQxM2E7RBPzGxQrcX5qrLNYHfpCNB/TR2I4pfuHBntdZv61t/1yRkxov1nVIjKG9Xn9V6WkMRV8VpDNxIs8R9iWyx/BmsTve8+m7vwGAx2ERzRNlU7+aYyiOUUYNblQoREBLWAUSTyPkjwOfftSR+QTQrjCxIyj95N0w13cwcLvxc+kCr4a+0ge95nCMB+NZWXeBM4tw3oPhp1MdJuO88ZM3V2V5boOXVd8N6Ly5mOQOQP8RoESV3aXV3Jhbc6IOSjvnaLs/mNmg0Qi6NZ5+QOtqSjgc83zHO7ckT4ZnSokEo8f66YS100OXbtii58Jk32XO9Bpix35s1EB+PfaDyITz45yR9Kn/Ghdb0DcbQCd+gJnNXSEebcVt4MZAJtrQ5TrdqTMedjdaAW71X+TptwYXEQQoEAEyYow5ezYXZE4fm2+Kylng6GLXZ0WKX/HEK/AOBrA4zneyr+4H0vEY8JZPGxlSUO6f/uYHqCyypYS+A3Oghe4OIQspRuvEI= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KdVg2Ci7PmXXzDj/ijXcY4a54es9kmOVrI+lYdFcI0naY4/0Ns4O5Gk1h6Q1?= =?us-ascii?Q?ObO/FdPaEtm7eW2svKqYnz3VEjdv1j5Y77XlD+ckCR/ofJVcpMFkAmYYdy0T?= =?us-ascii?Q?3fuYME3Nho6rV+AHedjeBlQ8z6J7/TmXaPsPe2qTJoseOptyVQWCNue+ZEIm?= =?us-ascii?Q?Pbs5ryybaKBg3bbORlH5KZyM9yFn+zLq5Vlib+KBhC/lIYXoFWR16aj9k/z0?= =?us-ascii?Q?isMhPTTRjsl3hKGbLUlVUp5Z2F/lvMBniANEGYEhXbVkKuQgPSO5rJxn+pUy?= =?us-ascii?Q?9y9/I0u8F7CgVO+3oZiS2lHzEKhX/ZUn35OiA03CrOVuC+7MeSKcM5qaGcDJ?= =?us-ascii?Q?TINVgkT5bmeAHxuQgUC4o38+QH+Q2LGoiP8qPaKUgGaLLSEwBXneRY/N/fwo?= =?us-ascii?Q?aXqlJZM+e0m+h96+hbpYhAz5fhbulPKl1za7wBW8zcjWoqLD9FNpxwkrLGtE?= =?us-ascii?Q?/tAbsVtLeETiUsvBa1tJfixqqpXAFn4Ag4htHWWico3pWvdwA5NHpR1tCXPd?= =?us-ascii?Q?MM/hTCE4J5/wK/K0nHC5oGWSJfkzLVx0XVC6RzXQ9EljVMBQrLjUAyKXjCtK?= =?us-ascii?Q?+banBYbGSbvug+OSLcQNktW//o8A/svhhWZigtbJ/XQalVopPuuGO6uJsrIA?= =?us-ascii?Q?BTQZvKeG8qhfzEZsKge0T4XW3P+XZ/wrTLp8aHLeZIwePbhK1xzoMi6dJCMS?= =?us-ascii?Q?Gpa/rtH6Pff5bhNXfhwx4mW6xl9E4LNNCwjY6ennmrJwBYXij2oMSYOjHz9B?= =?us-ascii?Q?B3UF3B3fmAC+9R1pByOCKyY19Z6eYDng00liLd576qiQucSusII30dD/m6No?= =?us-ascii?Q?sN55oMrMOmeTfZB5ZI04daxboketVmPOpMzEgFU5QKLGAlmEUUIRfAZLgnx0?= =?us-ascii?Q?JmG0QPaolERwc+Cv3c6957quc+aBV6sgwu9aMzMKNeMj/uschEy1mjLdgNOH?= =?us-ascii?Q?0gexlR7q9kgB1MKSGdXhQtwkAfDtAMZkoAwDmLqEOywpODr1SYJ/WG/Z9FJR?= =?us-ascii?Q?n5228KrbeMTAtZVgKExBbm+8n16lSOV4mFqM3MLU9bY3ERCGRo6RAW0onWBk?= =?us-ascii?Q?exd04Fhjer+p5qUDvAtCkmZusygk0WDe6gytzhm3buQ5JBBykeqytFI0ZHx/?= =?us-ascii?Q?oKFgUczhRSu4SbaFUjAZw5faqOCMoMIsWzsWtXILYmFtW7uqljcuBTdY7upq?= =?us-ascii?Q?zJMog06gKcd5TrcxPDanwpfA0Xi6NOC3B0J8ZSjhtI56pQgi/wia31l4JG8/?= =?us-ascii?Q?nUhyHEGAak4fx4Cv2oRqtyVTVVZiQV2hhS3WtK3lKdhy6zRPaGF/QzmDpzOo?= =?us-ascii?Q?sVQITYnecYe8iIbnjSR9OnP5QKs2aCYnRfm9W3+zuMNs47v3pQtTCwRGKB38?= =?us-ascii?Q?jJJxb8TKwZP0QXfPMMirolyI7Iav9rd8anhyDFBilbHHrnB3w86k57DImMA/?= =?us-ascii?Q?Z4qqokATEhW0kzspj0xXL9Kst8mFHFXtLRc4L96Srs0kWNm60vj8BangjSdY?= =?us-ascii?Q?NZsoQDQuDV1hm9sOT85JLBwqW3tzz6MTcBkveky9uSH23ObtN/y5x3+ADf2B?= =?us-ascii?Q?IUN9cO7qnOZYlerWYUfjT5lMiOLnOhZJGaqf2xtriFOfLxW82GZNl3f5lV3v?= =?us-ascii?Q?s9Iut1wgrZxCEBJ7uUZQQBPcdnrUDNlOn5uk3p8JtmN3WBSMJ0VSn7W3Rg2Q?= =?us-ascii?Q?WlRF5H2X9uHfR9wulm7bL7DV32C1XIWDL38mVHShXnjGzh8jOTYi6PODswu4?= =?us-ascii?Q?UA6U+qQjRSaKYeePDdo7r4yoFRy+sFo=3D?= X-Exchange-RoutingPolicyChecked: I2bJ9Ay16oOvbxnLC+/WVJtk6NK9VyV6gLSvcK9ga+4xOyN05PV1/bDmMzTwMdlqwmEdC6MhXoD5ikDVezse5zpY99B9+eCr3hYKrOA16zlrAdxiyOk8k3uuXYyEjG2dz+Fv1WkRdaVqfeecPS4Pl56o2u+ePaogt2/K4apmVSIh06jysIkVdUDSGtrtWKpqZv4o1EcaPOMscPzLb5SeW/jPR8GyCVdbirE/82rA7EXq/rkdsQMZthO8oR0rCgeoz/1SWAyWKTZK6EllRHhrOfpE53WyCvhsK/Y6hsY/j2s+Ks3q6CN4xWeAHQz7RJvClEfSNl44QIpAnfNd/s7Jmg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 31cd589f-830a-4862-a263-08df2dd9509d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:49.4515 (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: ZV83K/vTSF3iJzJcJGGmWSIkgm+EznVDzt4HSBNSMExwdeCflqJS/eqr9oWgiQXfw3dlcxcAxLkMoWMSPtfBpZ4LrDGYx1C55rxdjBET10U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Authority-Analysis: v=2.4 cv=fqdJ914f c=1 sm=1 tr=0 ts=6ad6079e cx=c_pps a=9OPjPng9tO6d8HsITUYRUQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=lKrOaJ4ZLGcPJhkerdAA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: iRUqzQHItJ1qDvR5G3MT4hV9Pw78pJhf X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX7oO6HjnoAiz3 opHmYR6ScrbajuVTfrdFJx+tbAX/z+8l3Nh0pVp8xmZMpFNKExp0N7nctPp/Oli+oReXwiqngT4 +1E54BFkOf281CtGgXnFi0y/tah7MC8= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXx/AMR5cWogcj wYnY1ypxVQ0LgxHYhNqeUPcn/IknShRF+bPAgwsqPvfcY8zfomTXvh7RcOTPy+vYsOhmBDvUTz9 BDP9/ty6jgWD6EXdpP1MHy73Hvg2b1e8SMwbbXh1YSt3lx3rUxDUKoMnu0dqS0sABRclMolzg0Z lJcRbTBrXjb25RWSi/a+aO/QkWQm2Z4lwFb+gkhKrDPGUZI6LZsIzPVb//eV+9mj921ErdeizI3 kRfSuND1CR0BzG0DLufX56CSaJInuVG9F/yZZp48RuJHX0xDk0XP247ZKT8nGypgALnrjYQiOKk p6o1KsZIxpx5kdKh4SDa+rgd0GYstm+WarGTHJl4LE5r8ILsi/MsorCipi6au74eZJf3P0zGYKp pIHJImWw/bnh9Ywenyze4E934/iBJV+GSuHkBxWExQyqNyndbkpXCpO2LIi+eJV+gQgrzdeZR7+ LTnMYR1pG4UrwLxytxA== X-Proofpoint-GUID: iRUqzQHItJ1qDvR5G3MT4hV9Pw78pJhf 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792411556-1B4D39EA-703576D8/0/0 X-purgate-type: clean X-purgate-size: 1293 This device represents a single KVM 8259 PIC and its associated class and ensures that we can safely embed the device within a container device. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/i386/kvm/i8259.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 85176dcf80..8ae5dd39b5 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -20,9 +20,11 @@ #include "qom/object.h" #define TYPE_KVM_I8259 "kvm-i8259" -typedef struct KVMI8259Class KVMI8259Class; -DECLARE_CLASS_CHECKERS(KVMI8259Class, KVM_I8259, - TYPE_KVM_I8259) +OBJECT_DECLARE_TYPE(KVMI8259State, KVMI8259Class, KVM_I8259) + +struct KVMI8259State { + I8259CommonState parent_obj; +}; /** * KVMI8259Class: @@ -154,7 +156,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), + .instance_size = sizeof(KVMI8259State), .class_init = kvm_i8259_class_init, .class_size = sizeof(KVMI8259Class), }; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:06:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454140.1667683 (Exim 4.92) (envelope-from ) id 1xIm7t-0001gL-Bl; Mon, 19 Oct 2026 12:06:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454140.1667683; Mon, 19 Oct 2026 12:06: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 1xIm7t-0001gA-6C; Mon, 19 Oct 2026 12:06:01 +0000 Received: by outflank-mailman (input) for mailman id 1454140; Mon, 19 Oct 2026 12:05:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7r-0001Z5-Kj for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:05:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7r-00EDpy-17 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:05:59 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6079d-e002-0a2a0a5209dd-0a2a4508b53e-34 for ; Mon, 19 Oct 2026 14:05:58 +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 6ad607a5-f659-0a2a45080019-94a397447d14-3 for ; Mon, 19 Oct 2026 14:05:58 +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 69J8QNNd3199044; Mon, 19 Oct 2026 05:05:54 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021138.outbound.protection.outlook.com [40.93.194.138]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc83eugxe-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:53 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12: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=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=Lbk19TW9tvFSdcp/RjK1f/3JYaD9dIFpQrVMQhJU5 8s=; b=i8Tdo1vAgYhfG3mbR5etts7AcBAYHKeKbeloDtRgjhgEzigZd+aHJLsSy 10UlsCjOijmklIhzyny+I/dhAQpoeiw0S/xwC7SOwslWNNm1gYS1KwZIEqKqUvJD 1rdMd6giSiKqpTMO9SNFn+FWzE9oGboKQn0P4/WCRAUVD0DuvxKyGWswL8yxDK2r VYp3oAFd0Bk0cp2e56TXOqTYU/Xkx1dMA/+zotiBTAiDLea3PEX047Jxmhi9pNnw I/jBm9U7qGSU+K+IUUB/OY5x0ivdoZCsmfmXtS+LAQ/8XacDE+/I44Uxz3B5tPUA LSoyxN/IzMJIeqkF6XblqLF/KRZsA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p2ABZeK4VY02s66F9otn9t1KKJdRPfvVMEZK82sxadh7sTnemga9ZNhT3hmiACeYbyuNLVWO5ZOjDjQTP4lFA4BZGPN5ARivnO841sIPr9VMj/ivWCZyQOUq9NSvlgtGw9Truh35+VeOgFXP4TrKztWFABOgE7w5xFolVR/6iamVzZND31guM5U1UGDxAhT3zabiMd9rIIOq1Z3VkEK6V33fWQRn+wmMgXJezNywU3XsH+is+/VWF0Hzh68VodjvQqPX4l/7vf4McWjQaI7+jXXqmTSzgSl1hJEosoD9tRSwli/Uyk1jWVtLA/j8DR25Z8BJq6czr3KdBbNM2Pkp2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Lbk19TW9tvFSdcp/RjK1f/3JYaD9dIFpQrVMQhJU58s=; b=bPnUhnEaGhAAUugUYPweysjAOIugxZRq1iyABbHUKYN7e5kjBQzw4KMBVplSXxZVXkZXDb/4y2GDzN98ldSN5jKl2S5D/3eS+mlebT39FlH0PEuCOeKyj1/Srhc/tWvaY6ivesJEV0SAe3D0RDlQFg66t7jwAzTT7YxyCOgbSHz0KSaCgRggAVSgC5I0TukrR2KZEV7k6ldekN51DymZ6YPadvWqkZdQqKunVGdhNd9MvzkyrtXgnU99teDlCvuVSiNukodF7x/SKp8wZGWKQXBnaPHAYAggNkLfpshpfE5aKPqiHQ+QyMvDEB4bprZ7N5tPZnAFs7QZxATumlmSuA== 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=Lbk19TW9tvFSdcp/RjK1f/3JYaD9dIFpQrVMQhJU58s=; b=Kp5gSyBf0lpmv4S5F9csTdmPMlQEppOGDvAMikHI/sk+q6MNJRNmaZOScpjAKhOeUZHMxDUBLuu2fXxLKb+I9cY+JPz0vIsvk60Uk1mVvhcWjXchZ2a8yrCzrimOvIUqeT7L4vDJ33GTtKWqrmfdoiIe6sWRExetPnEoJNT3+nmsA6lyKi9Tx+CQ0Wxt9J2ea8uwSQPczUr9ydtIs7pvHbzyvdvUWICAZIW6x1f+ev9kBj4ykQUpRHQnrCn5osTdCn+FqVqUdh4Ax8WwXVD3RWm552GeKWtPN9vxPIBkXWFnRzLNw/RJepqvnQbjYZEGjBqE4+P2A+JCBEAAcp38Ng== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 10/28] kvm/i8259.c: always use cs for I8259CommonState variables Date: Mon, 19 Oct 2026 13:04:42 +0100 Message-ID: <20261019120517.1448687-11-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0159.namprd03.prod.outlook.com (2603:10b6:a03:338::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 664d7082-eac1-4bb8-74f3-08df2dd95274 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: DNcdofC6+Eo79BdindphJBSiYJ3tQvFrM8u3qzHELnyF/9Hnw3UKKD6ia2Qk3ut3l3U0CoCduQrqT7mvF8RsuZ8ZZqo259hpnfrWLu1dDreaYYS6fTHDh1nzTTV7np7YxSrBZHDT+yZ1AeZ2LNXi/VL/R7WmDCD5LRNUCcocJeH+pm/dn0iOptDzpo/jbLD5C5ZDkziVhtl6kG1IIqJvajmlnMwDakPXq2FfPzEwXxLiSBDxXIcqERuUZPHhS+F80Bx4xWB0dGPXmH/p5DnUc3cfvzscZd3NRfGfSNwXrpZk1pYs9+oRMRm+yll0M9N9m00Rjcu8PBIOt2NYCes5jfj/ec1vuQtvAuonQ2GqktrnQxUJGhRnt3mLFRTmORGLN6vO5IXdx/v2jLUNA+z+MKAd7ItvTtzPSqDUZD0Nz68grW+ksNe1JR4r7g/lkmIanpDbR7tiEy+gwqiZECFwlIMdYqq2XDptaDIjk0wXWN67WjT12cK2HmQcYb8eYUF0Zjg92NeuF3oNgzeSaBV3KEipEjwWIS5uWnQEKkqeN4lulrudWNDtezCbOxb0+bwAOE00ivbV9pHhq/q0IS472CW9SGkGaIE68GlSjadAnmwjb9tkmxhre4KH93qx+WY3wsrhO2isyWkRRDjEjK2slb14iX5DYi5VhoSKRY+QBCY= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+FaweITFlPhTHLOScfKBf8ZBoOcxkKxxBJ7OxTIZ623OKINUhBBIZV5wYBJ+?= =?us-ascii?Q?JjAZHyvLzZn9hJ2KjHKRNXyg03RnfRh/7TrYuFkIg9UW6eMoc79a2vUxq31I?= =?us-ascii?Q?JKv63tQFAOSVLBU5WDE8XESgzKEUui459qTZy24+CuDsx9ZWzQ3bt/b09bif?= =?us-ascii?Q?Vyg61/EokMl5ZOKkI9dL9XYOlxqHGsQlOXOlzkCstHlCf6Q42WR8A3dZVYyy?= =?us-ascii?Q?h3JlptBX32q+lxUN0aPRhDwVwGwdZxjo/HAmlwp8jbHdT/M2pwHj77/XJ5Fw?= =?us-ascii?Q?oCQbwF92/EUfGb3cHMLDhzruQ3cuQMn6daSH/BChynnKbBjFTgq5pvnRw8g/?= =?us-ascii?Q?aY614XNq8t1a0U5yg5exFgru2PhhDRAoE1qkjLQL5JP0wHDv2avvozYAWBB7?= =?us-ascii?Q?T2AQPU9wv6tKraB8L1zMKKNGxf0XFDf0Ey0egI8o1Qu6Cw/ToE1EFvLNO0DR?= =?us-ascii?Q?uCX4KQjub8oKYDFloArvy4t7YFA9QVJ2fHqe6Qf8byB2Y9e92rbNyWTKDiHl?= =?us-ascii?Q?WDy4ku3uwMQotrQOUte8TdmLKD4zYjyBj0Dgo5Khfy7xvxXfTYxAE4tCw2hU?= =?us-ascii?Q?zVuTQ0Pu1ZUsCiOD+rZRDQGgwCR6hx8Fcs4JQT6jtlPVM6Xcv0Xb3izz2Hwp?= =?us-ascii?Q?Fo7HTTQh6FuaB95eliBmuBh0l3y1ohHrMT4daOh1fVh6ntTf5xV+/k4G5UW+?= =?us-ascii?Q?O4/fJMDLs7F4ccbM3rZlZKfsZMh0wjcQadlvQY9DzqNiXKKqUM6jDBU5S9J5?= =?us-ascii?Q?YFtK8odJeFTfR9hR6yNarzDoUfLxawAcIFA/pMbweSUkDuC3VJyZ8vuH2ywL?= =?us-ascii?Q?Y1rPg+gJwjKE+ROzv9y9a+33Qkj5NhvpvtXVSaj3QNRKOZzGJuX4IbtOK5Lp?= =?us-ascii?Q?V05tqpDiUp0SuOEA2NSIoVwayC/40LX412U6tp5n9jwUgP9DT0fr4oklzxUh?= =?us-ascii?Q?s47zKuNJ7hmCmnBg8noE2/X8rzoWAPMIN1ErspifZlKDgWE4IShR6ozXIeI2?= =?us-ascii?Q?2143cc1P846Ho2V/CW9BP+M+h943RvKUS7Xqg0hAYPHoyj730pOKyHcu5h2B?= =?us-ascii?Q?L9+9LOTJFPeN8jzPK2C85pKLoB7FVXSeGz7t9vhPA5FYQ2E6VBpaMM1wgDiD?= =?us-ascii?Q?HUPJ/9CHQn0LBv7cFYPxoPT6babz2+1Zv4dPbuhtv5MeoCNeXUClTxF/bcfm?= =?us-ascii?Q?M1Qkx+iJ6Gn8v0uI+PbSb8EP8tUAnKl+bB5y4CiUVuYFUEEqOL4YKBSxZ07N?= =?us-ascii?Q?AgfozprEWvIAStFzlECXhVkGlii+spUCprv1sf1kRdHfzlEstXggUlXr/yCw?= =?us-ascii?Q?DksCs/qvaX7bZdp7Xgf6gqfjlHXgdUh7XyxCGSsKgUNSdjpTTpUlZXzpSls6?= =?us-ascii?Q?peXTGPoqSxBCm95cPTG4Or+6d14yyygQMH+hw6+s/hjtiTQQu2VyWScHcw5D?= =?us-ascii?Q?0wzrISfgJ0EIJDLC9EVcOGEhcO7F5CrQucj2Pg2dM3+k9umR90x2VGUUVtF4?= =?us-ascii?Q?c6FybT6rE6ci5mvCELRZ/VdswrzE+TPcYerLduogZGRkRNs/PybTQv/QDWck?= =?us-ascii?Q?Q70BnLQ3tNg+CI+CEIKVx0XgbboxSrICHjdNUIfu3i/XmgyUM6mDX/i+UGjM?= =?us-ascii?Q?babbDc1r4XjHbIK58Eb/Mq1AyoClC35o1T9otn1OT74f5A/GHLk6rCeNqFc5?= =?us-ascii?Q?H/oliSJ46ITbyUz+0VhnvF7UV0/kLTJn1wqrl2+BX1KIsABk4irGASBs8WC1?= =?us-ascii?Q?sF89OOKr78MByjZleLBknfU4duT2lns=3D?= X-Exchange-RoutingPolicyChecked: NYoYe5ZQh+IJL3yVsorUcoK9xqjiTYJj5zCRYauQ9EDMLpdfq1bgV3XoJFXC89v/5kxJtXtPqllgLSyaYodDDelXG570rxY6l1HcdOrSAqYqzNUDhCQirQpQQ8JnsHu+H0Om/vVxOJ4DEXLoW0cr5wk7dL6kBaREkg3MLDUqmfVXLXLbTIzvlT0ay24eFCrgGHxPY+sL8sBOfSIkpH69cOb25miX93mSsVly/sQOaIuYX1i+rfJkaQfRMuWfZYcH9WiamCi8uwYpCYNiRnStKTpwQ4K1Erz3e4n5o+Brl+uGgswmEShgHNRgalw8AbDs6PZqrTYHvtcoysa2lOYnjQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 664d7082-eac1-4bb8-74f3-08df2dd95274 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:52.6814 (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: U7fQJz3xzWAj40tqIcEBFSh8J1FYOJ5H4OE4qGwe7HW8qGxTE3fhaAMwR/VE4Xs9jI/w5IAJE1RtDRjmtD0rxghhnjLRk1NQ2OoBY1LBb08= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX7ityboHlymxu Fyec8+xxXXnQJ1cFmYPFLPKAy+LK1geK2y3uqk7/SchtDUHY+2EogFOUM2oE4vjBOABZWRAUIm4 IOpfoleUkRZbt8HexgmjH37KXlUFph62FX/cqC/Jna3ETR7yLteFOR6xP5PQ8bTdt5J+qXW74eW aVNXjL8n0hspLO8lVCkF8txtT1hNV4oAs+30Kqkh4X9WUm1tFB3NND3Hj/TvarBhabxX3yR6Y7S FbVsHn7LhEIbK4jiSRUr1oVhKpm+r8PxdHKsE18hmZ47tDmn9w+rsDQhIxBV2zilzuaf6aIbp2Y L2fBZyRUjmoEr+DkeXJDwZOUjf+oz0ATTHGtReRqQtLr4O2Nxf2usPOg32fAaXDu/xJ+maoPNe3 xub62pAaYKbQZepMhf9RaLkPXhRqJCTfqWoHB5JsVeasDoYKT7JMUjzAWDi/Crnf1LuxS/zqTPY 7JnEnIWHArQ+YafXRGw== X-Proofpoint-ORIG-GUID: JEJCLSAGkLLZ8ggYXLX5mprfzN9JsT5Q X-Authority-Analysis: v=2.4 cv=RI8mjIi+ c=1 sm=1 tr=0 ts=6ad607a2 cx=c_pps a=+dppALzRPzum89W2H5IdTQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=zNa_6NNZsa7Vo5epgMYA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX/nh03BvmvOcY JIbaM1gVxRGk3E+/HrymdEik7W9iRnyG8adSTD24bMTAtVudgOuE1n9MKUWImNCJEKQEp547Wd1 7DcjM3pzo07B/O+Hp726JlV3pSDEB6M= X-Proofpoint-GUID: JEJCLSAGkLLZ8ggYXLX5mprfzN9JsT5Q 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792411558-D674387B-8AE2E1FB/0/0 X-purgate-type: clean X-purgate-size: 5300 The use of consistent variable names makes it much easier to follow which fields are being accessed from I8259CommonState. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/i386/kvm/i8259.c | 86 ++++++++++++++++++++++----------------------- 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 8ae5dd39b5..86b1ffea4e 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -36,13 +36,13 @@ struct KVMI8259Class { DeviceRealize parent_realize; }; -static void kvm_pic_get(I8259CommonState *s) +static void kvm_pic_get(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; int ret; - chip.chip_id = s->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; + chip.chip_id = cs->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; ret = kvm_vm_ioctl(kvm_state, KVM_GET_IRQCHIP, &chip); if (ret < 0) { fprintf(stderr, "KVM_GET_IRQCHIP failed: %s\n", strerror(-ret)); @@ -51,50 +51,50 @@ static void kvm_pic_get(I8259CommonState *s) kpic = &chip.chip.pic; - s->last_irr = kpic->last_irr; - s->irr = kpic->irr; - s->imr = kpic->imr; - s->isr = kpic->isr; - s->priority_add = kpic->priority_add; - s->irq_base = kpic->irq_base; - s->read_reg_select = kpic->read_reg_select; - s->poll = kpic->poll; - s->special_mask = kpic->special_mask; - s->init_state = kpic->init_state; - s->auto_eoi = kpic->auto_eoi; - s->rotate_on_auto_eoi = kpic->rotate_on_auto_eoi; - s->special_fully_nested_mode = kpic->special_fully_nested_mode; - s->init4 = kpic->init4; - s->elcr = kpic->elcr; - s->elcr_mask = kpic->elcr_mask; + cs->last_irr = kpic->last_irr; + cs->irr = kpic->irr; + cs->imr = kpic->imr; + cs->isr = kpic->isr; + cs->priority_add = kpic->priority_add; + cs->irq_base = kpic->irq_base; + cs->read_reg_select = kpic->read_reg_select; + cs->poll = kpic->poll; + cs->special_mask = kpic->special_mask; + cs->init_state = kpic->init_state; + cs->auto_eoi = kpic->auto_eoi; + cs->rotate_on_auto_eoi = kpic->rotate_on_auto_eoi; + cs->special_fully_nested_mode = kpic->special_fully_nested_mode; + cs->init4 = kpic->init4; + cs->elcr = kpic->elcr; + cs->elcr_mask = kpic->elcr_mask; } -static void kvm_pic_put(I8259CommonState *s) +static void kvm_pic_put(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; int ret; - chip.chip_id = s->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; + chip.chip_id = cs->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE; kpic = &chip.chip.pic; - kpic->last_irr = s->last_irr; - kpic->irr = s->irr; - kpic->imr = s->imr; - kpic->isr = s->isr; - kpic->priority_add = s->priority_add; - kpic->irq_base = s->irq_base; - kpic->read_reg_select = s->read_reg_select; - kpic->poll = s->poll; - kpic->special_mask = s->special_mask; - kpic->init_state = s->init_state; - kpic->auto_eoi = s->auto_eoi; - kpic->rotate_on_auto_eoi = s->rotate_on_auto_eoi; - kpic->special_fully_nested_mode = s->special_fully_nested_mode; - kpic->init4 = s->init4; - kpic->elcr = s->elcr; - kpic->elcr_mask = s->elcr_mask; + kpic->last_irr = cs->last_irr; + kpic->irr = cs->irr; + kpic->imr = cs->imr; + kpic->isr = cs->isr; + kpic->priority_add = cs->priority_add; + kpic->irq_base = cs->irq_base; + kpic->read_reg_select = cs->read_reg_select; + kpic->poll = cs->poll; + kpic->special_mask = cs->special_mask; + kpic->init_state = cs->init_state; + kpic->auto_eoi = cs->auto_eoi; + kpic->rotate_on_auto_eoi = cs->rotate_on_auto_eoi; + kpic->special_fully_nested_mode = cs->special_fully_nested_mode; + kpic->init4 = cs->init4; + kpic->elcr = cs->elcr; + kpic->elcr_mask = cs->elcr_mask; ret = kvm_vm_ioctl(kvm_state, KVM_SET_IRQCHIP, &chip); if (ret < 0) { @@ -105,12 +105,12 @@ static void kvm_pic_put(I8259CommonState *s) static void kvm_pic_reset(DeviceState *dev) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); - s->elcr = 0; - pic_reset_common(s); + cs->elcr = 0; + pic_reset_common(cs); - kvm_pic_put(s); + kvm_pic_put(cs); } static void kvm_pic_set_irq(void *opaque, int irq, int level) @@ -124,11 +124,11 @@ 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); + I8259CommonState *cs = I8259_COMMON(dev); KVMI8259Class *kpc = KVM_I8259_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); + memory_region_init_io(&cs->base_io, OBJECT(dev), NULL, NULL, "kvm-pic", 2); + memory_region_init_io(&cs->elcr_io, OBJECT(dev), NULL, NULL, "kvm-elcr", 1); kpc->parent_realize(dev, errp); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:06:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454145.1667692 (Exim 4.92) (envelope-from ) id 1xIm7w-00025h-NZ; Mon, 19 Oct 2026 12:06:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454145.1667692; Mon, 19 Oct 2026 12: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 1xIm7w-00025T-Jq; Mon, 19 Oct 2026 12:06:04 +0000 Received: by outflank-mailman (input) for mailman id 1454145; Mon, 19 Oct 2026 12:06:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7u-0001zW-VU for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7u-001I40-Bb for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:02 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607a0-2eae-0a2a0a5409dd-0a2a450bdfca-24 for ; Mon, 19 Oct 2026 14:06:02 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607a9-b7e8-0a2a450b0019-94a39b0cdcf8-3 for ; Mon, 19 Oct 2026 14:06:02 +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 69JBoEoY3623171; Mon, 19 Oct 2026 05:05:57 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021128.outbound.protection.outlook.com [40.93.194.128]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hdjnwr1ew-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:05:57 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=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=586g2KVctB5YEq0NErTXbjRn7y95bj1e9Czd5pSiT qI=; b=NOMDaUj6TNLUKWzrBHrZ3QtrS8NfNyD0AxnIzQL4N/FjFDAQ6vULHz1Kl woat3qo2ijrtTGo+H+RwbTwVDVZwsqPNCPXtMreN6BI3Msz74Nq225aMuVSsoYul xvRL21XvDE6xjLF2JuFW1utDIVDxOPfqvodXKxklMUsr+xl/qJnKGIi9Im7js2B6 1RaHlt50DxT5Fhu+0TgVW6YkngiwmpGRrrbFVLB3k79wIzHAMvHnCUfq8BoDnSs/ QJOYCaAuXpih4zLn/o4RT3KwWXl8a/DLWW1RO7RsMsdFEvLDWIxj+SZVKHd6DnAx IufHstwWyzTyNEpM+MOJPDSs1iJFQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IQqle6RULmRduOI6m908aDq0fEvcTiodHI1k84N3GTPPQSFbrRdtKSOOp1Sn5cV3Tz0vpe7NNaBptjpl+2y62URmivKdCAYzQIp+D12WA/3ESdYpSMJjzf0ygFxzoncnXoLguaJauxri1nKBZ81yzGlQyqmzYmfsWEBGEfhPGSWeHMBabEFCWaw+HJf5zbL3DTM1USylnDd4J8KW02QNBGoNgT1yTcA1AJWPVS5OvDRea4tkPUCeag58dqwuh5ENMyfCFDM9qPnF3O0L5rEHpyhq59RS4CnIbOD50hmCO4IwL2bf6HLJbJfhZ/ZZtXvAuSiYaDNNWrQApcKFnDhJAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=586g2KVctB5YEq0NErTXbjRn7y95bj1e9Czd5pSiTqI=; b=oWYNQVQp2T7W+edA73GRwOCDDeZQ7VnqcBhlLPvyE3Cr+bARK7bQBFUjZ3fNyyVhptCCVc6MRrQLIRZIxnABx+aA+NI4JRFchOmmXxop4Mdx0VVm8bTBPDwoT0EWjBRqJEoZOfRXfa1oQgJX1F5Nwd8YTs/o1kdrax4FVvjBomOIH0PMAE5iy104P7K1LtPWeQFYf1Ftu2ZYxozCWJyjqJSs1hFnUodTeqKsqJUrZrslDvqT5rJFlGOj5v0jpRLNExKD0BlfPgfISSbCoskVlTF4EI0BStVkdPSZzJ/aA6e6fL8NNSNuCouk7GN5f2bLysyruZSZzMcDf6T/VgFb+Q== 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=586g2KVctB5YEq0NErTXbjRn7y95bj1e9Czd5pSiTqI=; b=gG0EI3tT05zUWAtdCoQjGSuBInnZzuB0EjBhlW34zjNNsLQO0CaOic3mSypW6cT9GokQp60OWJTj8iNhV0SsP/OZzOZgLYSC/n9FVjvLvzRzX+mFibAdo5IqSo3ZHPgh9oKFWndoKUKBYuhA/83DtBxp3FFCYB7scQ46z9ZWMla7RO1GDY6MNNoRES/XKgBz5xl9l3k/5xPD6BeDvgZE40Ohibb/1dCbBUgxHaY9zqaXn0o1PvHaMNxEY3/R2YT996ksQNichzqpTPs4/3IBDUpn/a/9HMcGCVXdoiDX/rHAOHMgU6Dg7ARjorbKg1y6Lm3EMllJLEHVSJ7W6Ak8wQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 11/28] i8259_common.c: always use cs for I8259CommonState variables Date: Mon, 19 Oct 2026 13:04:43 +0100 Message-ID: <20261019120517.1448687-12-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY1P220CA0014.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: da3e6171-b6c2-4e4d-1791-08df2dd95451 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: vyhJ06LyuMU2h1J69pioaYcj3GTBlZj6qKwU8RjpbgZolQb5IcpDlpHSnae4+zVYuqhzaHFycKpgMCXitMfd+VloJ3kHQCujvjkvpIjxZ8FCYFpgFFyoYZotU6YuLy9ATsF6VE250UqeLVs1hzerBQtLWsqY1iOShplVRzyVzCra2OyOGpWCWySTQCF60GURGWQgfoNsp3esGuXvmHqbmSNhjdL5vg4VRh5bU4fFUh8xFOfDAcnY3VI7AZ9XdcUKPqdi7wCrfnx6IT2z5gbyVScDOwOC9wddRM99U8zIcsmAMXn5+EsSeVF6WFsP6XMpUjoAv+23W24YThKW1oX12SbNVrT/+FNpf4oaJd9GzYP5W2H+aOL9dQezy86PDhaOg4JN2S7MmehCVgKqorkSP92tDvao4+LsVkpJSsJzupyXDmBVxfHDzUxZCBbGYRnPLQauLRqGuSj3l6dixToTjv+or0NyXgcntimIzZfY145zZxRTb+DR1hVy0fblnDF1cxMcZPOprYio6jh90WitsMNuaE4CzALYIMz/j8L64z5ef2ItHyGcbvdYNa5nDjtYkeU1rXl8+jrLRa0FGFoLWKbpuI2GhH/m/alHxxSohsMQHnfRW9acPrp0w+E+/Nx+F2JHb63TVJNjuobylQxoxz06ksPiFWIWKrr4TYKVSEM= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bCTbcFQjEKd1re6ZANX+WhFneIMN91BtKIfEqY+lGL7J+Yaco+xLefDAUQvl?= =?us-ascii?Q?8YDf7Rlgg/4F+7XFpoa1gu3rSmBHoRkcVvPaSURmoiofqLzNduuRyUHlVz8m?= =?us-ascii?Q?MF35NJ8SarU76HX8FmrTwBmIvL9fiDupKZHcQRUWywewkTnBQ8UDvLqTPjW7?= =?us-ascii?Q?pSUVIWQ41f+kInC8kuq2XmeBlcMwsqKuu3W5MXMIRQo+myNQN8Ro7JPVijsS?= =?us-ascii?Q?e1mT4r6IjQlMpra6LzQ6y+OnveMxG6xSatBY3rvGgHTnzPUw8pC1eqfI2Hk1?= =?us-ascii?Q?2VA26KiUpU74+aiDraDBMnWWIXJktYYO88UCW+AVzhgoNzWVt1zJieiFFvKb?= =?us-ascii?Q?4CzFYNVwM52iUhiSsPGjUxfOD+OoNEsXrbeK3/WVg+/74CgCtPuULmx/0lsj?= =?us-ascii?Q?MPfzEWHnMdIBPCBF8iUxeX2d4trDXf7FDRDQ/1FX7f7qpYEfBv3w0IcpDQfz?= =?us-ascii?Q?NSKpggJk/V2z65MGdEpDEdcUeJ7aFdvIGFyrSxzMiBpRaUeF279hBSvGZ0wZ?= =?us-ascii?Q?p5CymlD5KdWmmBd0L0GofSW4c/VArIaqSMaDyci6yqm3fkktXMBX4N4RfoU8?= =?us-ascii?Q?IYdTyc0EZBV9dcMryp9rbbJKNfHvw5bzHXSDDIP2iAJ0KmuvH45CF/fiOk1W?= =?us-ascii?Q?OqXBLG0LnVdweJ9rl0B4+m91L34VK54UFBSn8vsHL3rzFFD2VI8O6SUrvPR9?= =?us-ascii?Q?OQqX6aQlScJvs5FcuSl6yQNW9UA9d5Znn5I3dpJVURdyTWH8Krsxv9wGM8nE?= =?us-ascii?Q?M+8WhrJxsdJfxi/i0TfVUW6vIhQdXgHQDpZuIvFu9KiqbpGvkuSW9x2NuppJ?= =?us-ascii?Q?IkJUN55RHCfUhJr6TMaMLs/1bROsNWrxtuXBlH94vBcGP0RnD99Q2pHe8DQo?= =?us-ascii?Q?9+JTdRczm/+wfNg8F0yofP9mCZOZ9qRizFrB0nbngsfT+zYIIafHv3gspir0?= =?us-ascii?Q?54xJ7HHJiGtEVdrUhqZhtHlbAxR4bodsNx+dtbwkK4yL08BDlE4YHkTwkfJX?= =?us-ascii?Q?2D4LBtycCkBVaTXbqKI5XEiykvCQ4ebtcnDdvyT9Ulscni5IxEhFZu+TTG3T?= =?us-ascii?Q?R2Fr5GplRdb0QBdXPdlQV13SZuvB5ME05ueTSCNMLrTvo0e2fRldWk0pEkOt?= =?us-ascii?Q?asxWlDUH1Gd9DIgJaJ98sNzLWpNTjsLTFMUyJ3h3ngZsVT/v9EhRxkcM4jWy?= =?us-ascii?Q?kQqH/1F469eeQjkdawxwMlwiK1ySz+LtRyK66Cu1ec1SLTFsGLgiUuTUT9O/?= =?us-ascii?Q?wE/m3CWvEkwZkSWGIjx0G+PzYcR4gGvcm67mI0HZjlEAr4Sw1/VS6n4BvGbd?= =?us-ascii?Q?URfqsxxzoOFO6X7eHVHVu0sPYu6YNfVzQRHZhR2duCK7N8qDOnnvdetmjfQB?= =?us-ascii?Q?kjQBHA+6p8sGX7ZWwVSvb9/eosraXc43xyrvyShYwH/oqrobfDGKK+ncI61v?= =?us-ascii?Q?ML1C2j2pR6MZA1FmrjPAoNyiQ0WUz/iWHu7soCabie26SrwlhtJQX49gHBXx?= =?us-ascii?Q?sqaM7C4CruBn3I1CMvNwU/XAndZnuEJgX5Qcbt80WU/ewLohwU7KASob0tsk?= =?us-ascii?Q?KHitdCByAlrkbMwhiNww+u/UswkfKgCY7vDeVAHwkol7eqyERqZA3UX0eCBB?= =?us-ascii?Q?oUj7V45sqXBqzXGcajAs2/Oj//C3YEMzmIsOvezA6wBQcA6Hn4JkjuKjlm+E?= =?us-ascii?Q?lpFhcKyl13c7oy2S2jAlyCvFz3Laab50ZNcz8fiuBT0Yt+HFUbu6/W505ASt?= =?us-ascii?Q?asMynXsi2MSJ8LGNqZLc1wqsMheV9HM=3D?= X-Exchange-RoutingPolicyChecked: ecR+Xe8z7k7GZgSVenhkaEm+SHBLAkkSpjdzYXb6cwDwY7eFTOb27tZWdvJeHV0RUVs6YAKAxaRKxGm9mvR55py/sM4l5Y8HK8JbqojaJXLTOkPBSJPrJeLYK2nKbp+oq1D4gOgRPYQvEDGO1SLLwG3isdQ1ekxIJiBK6y7EV5aUz0GIyPdJkdD4Dcmi8KZX0w9AxzjCy5XVTRbPvUk61OdC6w1LJCcK9xvZ71HqNj6vZgEQrKAdhZ1Z99lDnNTh+nX6PyYVicVagvaaiI0c2eGYck8NMLopdhCXEZrXZdbluW5Y6dLcsNZ0m46FH6mSRxBd02lQp4H9R8OaQFu/hw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: da3e6171-b6c2-4e4d-1791-08df2dd95451 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:55.7998 (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: Zh6hg9ajYdZ1YiNI6E+jLevNSfE7BaCupWx7QJZSnQUF/5Trx8pOyh/iEkWuqyneo5RRGH0KGGDJOKwsiA4DZD9WA8ODY27d8Pxq+ctsNIk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Authority-Analysis: v=2.4 cv=fqdJ914f c=1 sm=1 tr=0 ts=6ad607a5 cx=c_pps a=iGETFsOoOHXRiUW2e12q2Q==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=m1qT39pvC01PgN2II3AA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: 3i-IRsSosv4PP0ezz4u0Pj3nFyUwpS4u X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX1AwHeSDEXV1/ 6XWOqLR8P/x3cRi3OeQ+K/CfSg34kQGYoMCzwLnOpwaU5qUPKTn+xYyL5N+Z51axm6KXX1KlM3/ Py3XBx9QHB778KgH5wtPednuNRCq9c0= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXzkwIo+gzsAmM bHeCTgBVSFqP+Msu5St9eBFgGtzB7Qa9UZIw1c/5A0YNhuuLqUDzfHFomdP29N1EY3vR3HHOtlw aJg8RScDokAbQqpKoyAvbuwO15ew+k9XV8b762pweWJgdjtL7trJlmv0F/F6mXAkJNsmF+V7Uvr 558yKQX6YAzuCcnrM6gGMtjTQtLyHleX0XTNZTSx/usPgki1LCXj5146x2aLq9GjWFCNrKjhoU1 kc0vWXEw8DakNFur3Xy9FlZy90v9o1s+++6uGz9Xhda+RAPMXMG3v1usJWq62euOe/Cw7m5OO6k BmzRVM8NkopwXc9NYCtje2VyltC9meQqhTsTaKgYs0O23pjyrXkcjtCWoLyVwAVatG8ViFusKHM WtQDstjVPww7fpRHBJR+rWyPBHbtJi+pmrWkVEbfpY5WcQ8ZQ+sEM8OJqW5gh1Bj2zTge31rOQq rrG3ls3VxAyjnzLccAA== X-Proofpoint-GUID: 3i-IRsSosv4PP0ezz4u0Pj3nFyUwpS4u 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792411562-184CB9EA-F3662C0F/0/0 X-purgate-type: clean X-purgate-size: 5702 The use of consistent variable names makes it much easier to follow which fields are being accessed from I8259CommonState. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- include/hw/isa/i8259_internal.h | 6 +-- hw/intc/i8259_common.c | 74 ++++++++++++++++----------------- 2 files changed, 40 insertions(+), 40 deletions(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index e039d6f067..71fdd74266 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -37,8 +37,8 @@ OBJECT_DECLARE_TYPE(I8259CommonState, I8259CommonClass, I8259_COMMON) struct I8259CommonClass { DeviceClass parent_class; - void (*pre_save)(I8259CommonState *s); - void (*post_load)(I8259CommonState *s); + void (*pre_save)(I8259CommonState *cs); + void (*post_load)(I8259CommonState *cs); }; struct I8259CommonState { @@ -70,7 +70,7 @@ struct I8259CommonState { MemoryRegion elcr_io; }; -void pic_reset_common(I8259CommonState *s); +void pic_reset_common(I8259CommonState *cs); ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master); void pic_stat_update_irq(int irq, int level); diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index ac8dc7cf00..705a28ecbf 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -33,33 +33,33 @@ static int irq_level[16]; static uint64_t irq_count[16]; -void pic_reset_common(I8259CommonState *s) +void pic_reset_common(I8259CommonState *cs) { - s->last_irr = 0; - s->irr &= s->elcr; - s->imr = 0; - s->isr = 0; - s->priority_add = 0; - s->irq_base = 0; - s->read_reg_select = 0; - s->poll = 0; - s->special_mask = 0; - s->init_state = 0; - s->auto_eoi = 0; - s->rotate_on_auto_eoi = 0; - s->special_fully_nested_mode = 0; - s->init4 = 0; - s->single_mode = 0; + cs->last_irr = 0; + cs->irr &= cs->elcr; + cs->imr = 0; + cs->isr = 0; + cs->priority_add = 0; + cs->irq_base = 0; + cs->read_reg_select = 0; + cs->poll = 0; + cs->special_mask = 0; + cs->init_state = 0; + cs->auto_eoi = 0; + cs->rotate_on_auto_eoi = 0; + cs->special_fully_nested_mode = 0; + cs->init4 = 0; + cs->single_mode = 0; /* Note: ELCR and LTIM are not reset */ } static int pic_dispatch_pre_save(void *opaque) { - I8259CommonState *s = opaque; - I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); + I8259CommonState *cs = opaque; + I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); if (info->pre_save) { - info->pre_save(s); + info->pre_save(cs); } return 0; @@ -67,26 +67,26 @@ static int pic_dispatch_pre_save(void *opaque) static int pic_dispatch_post_load(void *opaque, int version_id) { - I8259CommonState *s = opaque; - I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); + I8259CommonState *cs = opaque; + I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); if (info->post_load) { - info->post_load(s); + info->post_load(cs); } return 0; } static void pic_common_realize(DeviceState *dev, Error **errp) { - I8259CommonState *s = I8259_COMMON(dev); + I8259CommonState *cs = I8259_COMMON(dev); ISADevice *isa = ISA_DEVICE(dev); - isa_register_ioport(isa, &s->base_io, s->iobase); - if (s->elcr_addr != -1) { - isa_register_ioport(isa, &s->elcr_io, s->elcr_addr); + isa_register_ioport(isa, &cs->base_io, cs->iobase); + if (cs->elcr_addr != -1) { + isa_register_ioport(isa, &cs->elcr_io, cs->elcr_addr); } - qdev_set_legacy_instance_id(dev, s->iobase, 1); + qdev_set_legacy_instance_id(dev, cs->iobase, 1); } ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master) @@ -118,9 +118,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) { - I8259CommonState *s = I8259_COMMON(obj); + I8259CommonState *cs = I8259_COMMON(obj); - if (s->master) { + if (cs->master) { *irq_counts = irq_count; *nb_irqs = ARRAY_SIZE(irq_count); } else { @@ -133,22 +133,22 @@ static bool pic_get_statistics(InterruptStatsProvider *obj, static void pic_print_info(InterruptStatsProvider *obj, GString *buf) { - I8259CommonState *s = I8259_COMMON(obj); + I8259CommonState *cs = I8259_COMMON(obj); - pic_dispatch_pre_save(s); + pic_dispatch_pre_save(cs); 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, - s->priority_add, - s->irq_base, s->read_reg_select, s->elcr, - s->special_fully_nested_mode); + cs->master ? 0 : 1, cs->irr, cs->imr, cs->isr, + cs->priority_add, + cs->irq_base, cs->read_reg_select, cs->elcr, + cs->special_fully_nested_mode); } static bool ltim_state_needed(void *opaque) { - I8259CommonState *s = I8259_COMMON(opaque); + I8259CommonState *cs = I8259_COMMON(opaque); - return !!s->ltim; + return !!cs->ltim; } static const VMStateDescription vmstate_pic_ltim = { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:06:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454148.1667702 (Exim 4.92) (envelope-from ) id 1xIm7z-0002RW-3A; Mon, 19 Oct 2026 12:06:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454148.1667702; Mon, 19 Oct 2026 12:06: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 1xIm7y-0002RC-TW; Mon, 19 Oct 2026 12:06:06 +0000 Received: by outflank-mailman (input) for mailman id 1454148; Mon, 19 Oct 2026 12:06:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm7x-0002Ke-Re for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm7x-00EDsj-7p for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:05 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607a9-e002-0a2a0a5209dd-0a2a450784ee-14 for ; Mon, 19 Oct 2026 14:06:05 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607ab-b4ea-0a2a45070019-94a39b0c1622-3 for ; Mon, 19 Oct 2026 14:06:04 +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 69JBoEoZ3623171; Mon, 19 Oct 2026 05:06:00 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021099.outbound.protection.outlook.com [40.93.194.99]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hdjnwr1ex-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:00 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:05: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:05: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=7wm8uo+H49sktKaMqKuuL2u6+/dMUEYN+P4+MkpQf Kk=; b=jag9bJ0vU967Z9vc7RHWSS9EX65WcbR30ynXsPmbN7VcNT9cho0tyxXP2 h+5LS0caQyadGp6jQE1EHdYjKKGhzNi2Zlluj9g0Z28tTiuLPg7WQqFK5X2jsfU5 r6HJgPs+tejtfL9ptXYxL6q+QeipMrDlPvLQaaCNw4+C2hAJxnOUhZbTQmV6lLFE oE8noZwzla0o4bwP7CqGhvnAcHv41pLCoBCQnjvxxTduU30BiQWO/IOmEMHxA+Or RgNMakK0ZoMM/yQ1cY/OuCwvEnoLzcce/Pphueocq8xE5yMO8lyEhXbGNRxYUE/U I/nKfQlN8Cp3Lr99QzdaQbAJ3kbyA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tpq81l+UKZToBu4f44cRRPJVI/WVqhYzHU8uAEuhyiwfeu5SS0kUBMSDZeBYbRmttINnfQ7xqgUxuvQDRR/f3GIrWvWn7DvK5jd6zjTRFsqxVglQjnQWUmN/kANq2RiuvDtpttPpkTL54h2/6upXTd9x7l1moS5Qy1zay4Cx53/PG+WNUtZ+g6nA03VuhBPH6MVsxDN77aCDh3iQZJDH8Tb/ZJTWtgK4QrKYCuljkEuYPGuZxdqz5g97ap2aNQ7Qt7DlELLSRWq1luXYNVs1mQU6FRuVuTsO5sQY6HlOkQpEyV8qXvFHbBeQ1yejX8RsKinBZsysktWuZLl1HMBzyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7wm8uo+H49sktKaMqKuuL2u6+/dMUEYN+P4+MkpQfKk=; b=Q9pKBu8v7Q9trJyRMp5WOCRbxhTra4ZT4cXPp6aoNlAwT5vPQeHivTZYxIf2uXi4GcQqj64lFW0ZMt1iBXLeT0JYt2aKmOzLTtau0mis37tjZILoii64uuZLDjhX4cGxFWPq0txDZbP1fzEkyQ5kRpIm3Z0hdW2/crZFYRASfrCLRvmSRQwDLnoi6D0wU/n0ZSlzAZR71ceI5Aey60QPam0eLGjbAprbdV4PO0fWt4qvJOC8qqrOrTvTa96XmletLSf1yGQs15LxnENkxCjIGTE1MmR0si+tL3TGaAPG33lXBi2C+24kCSE/NEE5x/scUKoclnjrSGSU9tThbd3Uvw== 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=7wm8uo+H49sktKaMqKuuL2u6+/dMUEYN+P4+MkpQfKk=; b=TNOpvi8D1SV3ye6EI1xu2RYriJLEjzRCPSzcrgWLIWDn+8wAQ8cxOb3oVuieUhM92SyTHESbvkYDW9rsziiTyefa6po6yucbkVOEW5GDa3rzLUUmVsenBMmVn/MBOhztYeJagWVXc1xSV+rxp0lNLapt7DbXG9a7euN5kvZ9S2iRCld2W0Vo8KEKCdyi3l+R5DvbqJbmp9j5OI7Q8vJRkiFssag6nuakMIU+hl1RRg0g7MdAkKvFQBDaBc0QZQHMcnRGd8qHzUyQe9FhkRIZqN6NOkGCX0TRqVUQgK+4TA3ksypfIzkMvYbMBwbpj5xKObDffjsIuR7ZSJjNIE+SKA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 12/28] i8259_common.c: use i8259/i8259_common prefix for functions Date: Mon, 19 Oct 2026 13:04:44 +0100 Message-ID: <20261019120517.1448687-13-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY5PR03CA0011.namprd03.prod.outlook.com (2603:10b6:a03:1e0::21) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 8364fc10-c0d4-4f6e-9baf-08df2dd95695 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: VXTayo2LC2Dh6JFikHKiqMNPTZ7ULVpMHQk+fR2TG7yNwHNQGBifb+mXCVBAASkw2kPwZDGL3vmdCT79xRjUwaeFuFoWkDZrc/AdhKSXvCHpAuY+VS2NJLh5zvOOZTSC1nzWTManDyVQKCSZPPeFcjGiuYjpnOvf9OGfoj1Cf23ptnXqldNJ8jaEQS3NzRliOoNJLH9PQIZEZxGvGMDLyWefie+jNStwPsayO1rrvF0EZPThQFUeoNKUjtBkDJDsF0tT3xLYuBVh0Gi5AJDF6y/d9L/h3aPADN3JCmXRbLsj0MjRZ9L7WrZMNV2iwajpRwqHFKcWn2hR2lb6TIE9WHrDtJYh9p48tRB6LyPDHx8Tkh5r2n/MFP1U2bClr8IcZDN61SkjhQptIXmphMvBicCgjoZ7nQf773kbaEdiaPGwaAHGR7+P7wdt8m44LtUhfN9khZLfhwCbxdbaOn2+Mjr1BLQxAImtvUQ8S4d72QdDk9bpuJ+e+qpzWZD9O7/H+a/sMXf783WdHciQSC7pCMJtgdSZ6k0V/Gu59O+J1IAQyc4SSXIRZWNt4Edsp5ORTZl1IaTP53EhZDVd0MeQdmKTCPmf5NyDWFHvBEbk3ujTYJGN09dDyD5j4q/xjet4DQC4th3t8inLMIGi2NqBhCYepyHM54fDsHRt/i3JSt4= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TFLh+bpJ68XynYMNos+Q8IT8s8TwdJiGomNvfYp+kVSOJcYGE3EIm2B+XfTJ?= =?us-ascii?Q?gskyzXv4ZAv3Vmw7WlTkpx6QAlIrUwiXeNkkWyQmPbEvb1m7Cln6lNefvbAk?= =?us-ascii?Q?DOiFfgu8mou2M9KOvXEk6ztk9bpfJDfdQ90e4fCT9lUX5VCP8TIKvotn0ILT?= =?us-ascii?Q?RMXuy69TRgZ+T9QXvZ+4EDQrobUJs66ypBI/lmy62jDgEf2jBepysqlZZOss?= =?us-ascii?Q?1lSk7GDFmK8EhCNuco+OS1M7uHXloHXikPK2x8Qc1afmx8mnk6kaex+QwuCU?= =?us-ascii?Q?JPEFwGgbaT/ZAXcJVFktM2Rt+Da0mgSUxpuGLB3lj2I0m7XAGeHePWRYUCiN?= =?us-ascii?Q?71zPbbP6EyyyFflqnC7VVN2Spngibx7gX7QULFxTkXLV7xIcGYWr2X3ejWL3?= =?us-ascii?Q?6WVCuUZCd6h92ByJPN0TIE3siRYRWtN/p1sp/+oX3Dn/c6sX4O+QWEZmN/p+?= =?us-ascii?Q?KVeyukW7Ic1VjZICsJqkr/jSQNm4IIMtM0N32CA72rkKrq1dFdaz57LViV8g?= =?us-ascii?Q?nhdQqh4h14asa6+4UPQP7OViEiSQz1G4YhcRYaeqcok+XCGr0Xs4AKIkHh7g?= =?us-ascii?Q?Q7pFxjBtRsH4EJCzKuuZkDsU1FWAQqU/zjykpakoIOQSDTpvH2iqXFJL4HAK?= =?us-ascii?Q?N8UzTSQKWsNqCtpJoPMful142LuC2U7q7IGd+G3MpG7nXAzENWSLikUbAMHR?= =?us-ascii?Q?847IkWHXKMr4VfZMAnSOA/QryCVjwdyqma8GLzWukW/LZtO150CpspOTpzUR?= =?us-ascii?Q?gxoNbgZoyPWs694ui2Y6/Memzajh9o/9OCkpDnpEqNVgcwjfa59GK3ZuUeA7?= =?us-ascii?Q?yWm5V5HQ0J+AMIaMaBi46AL4HrMpCmtCTwN7zANbGycrfMJn3qI5rXlYqLSN?= =?us-ascii?Q?2UaMeyLFOIkrYZ4tq/30cB5GcwGCQ1qkkRawhWHvUl/3bBxOZhgAfj7/xfuU?= =?us-ascii?Q?mJf9VQ9unUYa5ViZIt3pAY0czLAoKCi3OBpb9TP/zCkCdY/Z/pVASuCBc+Q3?= =?us-ascii?Q?Z8KqcdtR9wGnkORd3SjfDWDknshd69YeaE7TUobeq4rXNBJeUk7FUjs0n5A8?= =?us-ascii?Q?Si9QH2XzXAY7/Qooz1FtDPM0cq7+49XBaz3w7Xk0oaQ0KiZY2unXSufIgX0d?= =?us-ascii?Q?C//IN4ddPElIP1PdVjUC9MSAkNFTda8Zp7xwPRGnrS1Xe9aaVj3WkCjL9flx?= =?us-ascii?Q?RP+CU/Ks/kkepmSLnMT95bNUV/IOBOs4wSCnLw8A9fx4m5icB7yw1TZfU5GI?= =?us-ascii?Q?TYyWBUJ0Dsdinh9nBXYgpvl6oNZFK4DHnj/zNY4TOBQN7VJZYxsgaNoa/eB3?= =?us-ascii?Q?n/IAaHAjgvr94lEeSmdeBAVFNLVaBCiWJE3eMWFPNawF+kEXQMgH55fZq8ug?= =?us-ascii?Q?yt/ya6Uq57wChokwPACFSVimkrteXUnlMvLFp2PQEWfVYiUdvp1ECImfxSkk?= =?us-ascii?Q?baHiqC7GTIG4315c9+iKuCZ15eD45kKrtjaUumul1Od8nyzWR7D4UMLVmwYs?= =?us-ascii?Q?7y+KwcAoYABWnscfj5YlQew6kyckvEDGMc5kpch2bhe7lkZKk39NQQ5dHN/P?= =?us-ascii?Q?GK93Q6kb8cQBeAk0opGpB7wbTDQBwhPYdwOvu0cT4t0K5v5AdMavzY7uXTK9?= =?us-ascii?Q?n2bIphjxISb398ztfZ+e3tk2jdFVBP0PYMwoxiTModDMjGWNdltBXJ8XRR5y?= =?us-ascii?Q?1hQWJzN3l76/YuyljXpdQj4N5jACLp/Drpg6K0XS9k4jii8zMyDLD4zncHzc?= =?us-ascii?Q?0QT+U/5a2nJyUKIJiQlC0UMkgmbHCQs=3D?= X-Exchange-RoutingPolicyChecked: pmBmlwJz7SrGAje8jvQaqxJ1CDaDt13NTxvguBDRQb6BrIwi0Qv0AYcUNocZ57D946zMG+P9dET+oUdmUzJ1xSxRZV/DMZxirTsARuuHgWLxMZDemYaF/u6y+TgEsffbe0lcCptbgDOMKLlOr2Mhjkap+SVwUJ/Um6TbccNPKvXebskY7BMnnUZlfSLivbO1nw6dPSKd7PQ5Nnn3rIsW+7qfmiLWq4Dn8SCnIKbpfTFv4SvPbs6f9e7meE5o/lti/ZVNhuUSFLEEZ30o1YBe7LChU95pe0qAizGCZwc2XcEPIdFkEP0+I5H1eANwbnZWXyS4Es18TXvr1744HCFdXA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8364fc10-c0d4-4f6e-9baf-08df2dd95695 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:05:59.5660 (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: 5DFrkgKKzBbeH4ZoazcPvgjNPCGFIiUQycYXiiNiHqQlq+mrstBZbZHkNgXToCJml6QpYVL0Muy5PDD1sbUSYuVX0r/XtliZ3Xx2Y81VfVg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Authority-Analysis: v=2.4 cv=fqdJ914f c=1 sm=1 tr=0 ts=6ad607a8 cx=c_pps a=MAB4nyKqAzWELJb2TLvteg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=ox8dIxdxdu1w5TD4ToMA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: k3VY4p6MI4HvCUrdq4duavTPYNCJ6BiG X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX+cb6+0sZxMf4 ezWPWS6aPxGd/v+RIrCYxk8M+G9cGBk6x2DIhTfnI/qbgdwPw0Gl1UxPoypKCf+p903CFFtG69B DP7UEFAsS4jxT+4pK6rZDKC3P59uuKs= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX8C4slN5M8l4X VSmO+08i6KnxaMksd68KZETrnqKPB2cKu5G1Uc3PvFqq7zivRCBb6xPSxpQQmFK1hr9NNr6sMnt h5vpvioOiXriOH0LeIwLx8HoRhAjQq30aCOCJ2ksgQG1FZ4p5uEa24yVnEzvylDfZ4zLHwUD7A0 p8QT/d0Paq3lqQdrPey9Axr6037BmLFRLu7TaFo6ILgaSdnj09U94HwYD9tFLqiYTydVM04L1M0 ynNMdumVht4lK7bL65f6Z1HnemqBqpaj37TIJtAAimPiQpgC7YHLfGSWfcMhnOdiktTlJ8d5+PD 1jJc4Cmm+O6CbxC/JkxgAxl5GZgmNv4aaY9y+cV1cjmM8+LC8sGPIXQcuG5J5oNvJHMcv5sqVL+ 1jS8wijsff1MOLJtbwERayjTQ5TX+CZf4PwP7DpVHFR4JUlEABqGaW9P0nEhberR4A6GXitgNOO lvb52lrJwQ+ahiiWhyw== X-Proofpoint-GUID: k3VY4p6MI4HvCUrdq4duavTPYNCJ6BiG 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1792411565-35EC6AE4-436CB10D/0/0 X-purgate-type: clean X-purgate-size: 8111 This ensures consistency with our normal QOM-based naming convention. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 71fdd74266..644508a44e 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -70,8 +70,8 @@ struct I8259CommonState { MemoryRegion elcr_io; }; -void pic_reset_common(I8259CommonState *cs); +void i8259_common_reset(I8259CommonState *cs); 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 86b1ffea4e..3a960e48e6 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -108,7 +108,7 @@ static void kvm_pic_reset(DeviceState *dev) I8259CommonState *cs = I8259_COMMON(dev); cs->elcr = 0; - pic_reset_common(cs); + i8259_common_reset(cs); kvm_pic_put(cs); } @@ -117,7 +117,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 700412df74..97ecb77407 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -124,7 +124,7 @@ static void pic_set_irq(void *opaque, int irq, int level) int irq_index = cs->master ? irq : irq + 8; trace_pic_set_irq(cs->master, irq, level); - pic_stat_update_irq(irq_index, level); + i8259_stat_update_irq(irq_index, level); #ifdef DEBUG_IRQ_LATENCY if (level) { @@ -215,7 +215,7 @@ int pic_read_irq(I8259State *s) static void pic_init_reset(I8259CommonState *cs) { - pic_reset_common(cs); + i8259_common_reset(cs); pic_update_irq(cs); } diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index 705a28ecbf..31bd663439 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 *cs) +void i8259_common_reset(I8259CommonState *cs) { cs->last_irr = 0; cs->irr &= cs->elcr; @@ -53,7 +53,7 @@ void pic_reset_common(I8259CommonState *cs) /* 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 *cs = opaque; I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); @@ -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 *cs = opaque; I8259CommonClass *info = I8259_COMMON_GET_CLASS(cs); @@ -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 *cs = 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 *cs = 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 *cs = I8259_COMMON(obj); - pic_dispatch_pre_save(cs); + i8259_common_dispatch_pre_save(cs); 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", cs->master ? 0 : 1, cs->irr, cs->imr, cs->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 Mon Oct 19 12:06:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454152.1667711 (Exim 4.92) (envelope-from ) id 1xIm83-0002uJ-If; Mon, 19 Oct 2026 12:06:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454152.1667711; Mon, 19 Oct 2026 12:06: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 1xIm83-0002tr-D8; Mon, 19 Oct 2026 12:06:11 +0000 Received: by outflank-mailman (input) for mailman id 1454152; Mon, 19 Oct 2026 12:06:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm82-0002q1-7u for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm81-001I40-KM for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:09 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607b1-2eae-0a2a0a5409dd-0a2a4501cbca-2 for ; Mon, 19 Oct 2026 14:06: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 6ad607b0-5984-0a2a45010019-94a39b0cd776-3 for ; Mon, 19 Oct 2026 14:06:09 +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 69J8OsGS3282325; Mon, 19 Oct 2026 05:06:05 -0700 Received: from dm1pr04cu001.outbound.protection.outlook.com (mail-centralusazon11020080.outbound.protection.outlook.com [52.101.61.80]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc74ekje3-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:04 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=+oPkk2OhFpF/vtiHULlP+3P3BHO9YE69TRweo9UeO 9w=; b=UX06c5Exv78Kz4BBZsi3VCAgmIcrm0jMNL6PDWjTVdvwggpUPzYyDzqHe +Av7ZnNTv1qisV53N/7x8VIQqSA4glAla7HetAQ4D2yuHrhESugC23UPVAwxaY9q 5RbJivJbf/fyWK0HhM+tr7DgNEBhFEHtLZWVFpmbGqRLjsNxthhr2eTQukUo+qJO zRJ06JOPNqtOSAmdwnA9ljXOeRrUleFBvi1S4bCmyGw2BirvWQ0Vftrji9HCnRxC N+YhukL3Qld5sX6vLSnGjPYH8vc6+ZU8bbr7GMfT87hkfh1O5LJobWbfLgR6D4to yGERG27FeQ/ix60J//Gyn8O4QvGqg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZcznPsKCUpX7oX0KmxXT1gejoNKCxbGD9I3jH8WOmBVu5E4OWYXi6rKGSBKr/jTXwFKc2Vm1j4nA6dk2cd/7xJwCavGCFECTlJ2HDKLNki+XS/VXTcxlhufyrS/WmYOq/J1LtSzlMGlrKGV3q0YF7bQotL4nrs8LmVFrcs9+h6/AYTEZkMUCgE/2yLEAdZ3M5+k4pRrkQvJY/1VUDgmMVUUQG30BxuOHttyMwSAltx6uLEdThyiHVMnX6cBeYvI+0y41LFCplttnLMzfZ/qOSWNHhG5xg4bXxLZME1HZpOU8trzy7U+/qbUeAB3i61l6vD7bTnURdzzbV5XbKGk+4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+oPkk2OhFpF/vtiHULlP+3P3BHO9YE69TRweo9UeO9w=; b=b4cWFd8bDgSp7S2z3pPRvgxrR/q8krligYplH8TC1rGsiEL7EcYuPRBleKXf353WWsrM2AQKN2j3Q986Azz+/0zAgPQAe0yeZWPCbPtQEZY1k0S7GJuQuXi9xoxBTd/NGwYXlJQdmI9vVG2GPLo9l1r5fFTUiAzJjVEoj5tog9SZ7/mP8G0tnA0+91iyyw1Lt/YSX/hXl88oxRs8NVuBvjuO7t8P15FQS/pQNtHFzpYKquH1A3APepwnpUdz3cdGVcegs34mgzD1Pwc8sJwn3MWyqlwpWsWiExSXHbJgz0sNiZ3zmNPO5vvPDRswBAb7Oa6jtvH0AD2aZr59O3b1HQ== 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=+oPkk2OhFpF/vtiHULlP+3P3BHO9YE69TRweo9UeO9w=; b=q6H7EO7PLEhAxLsyInNuVLrbpvDfXPu3kqsFF50H0Bur+j7ufbN5XhcW6v51nEN8r5l+mgfi+7wAsQDD6JsKrRPUQn7AGOG2OWP2vYyf1b02LygWCyFw3Tz8EcyjE4bj6aOD9ouSHY3FUIYLbdPuts61tWP4WvqQPj30JMP50tHLUUqBUgtDor9w8i7LVjMAPCxVTvWZT9JEUlJ0E7RfOI5VKS5kiXdN/MvL1K5T/zFKZDi7QwLLhzFUn2OGgRtdwURfS6Y1ihaCXEDJVq3UZcSd311jlU++mbs4NTFBRywFKx5ZfVJqafy/yxV4k+SeFp5UJh6DkAt4U+9GxIVJfA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 13/28] i8259.c: use i8259 prefix for functions Date: Mon, 19 Oct 2026 13:04:45 +0100 Message-ID: <20261019120517.1448687-14-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0356.namprd03.prod.outlook.com (2603:10b6:a03:39c::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: fa172ae7-49cb-48e7-8556-08df2dd958a8 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|3023799007|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: S9UH6dCrkwI3HZcxqr+AD6jPGOV8sSHPTvF+M8OsuvVroaOSzrxT2qLsqeOkEr909+azhOw5dC5UciKYnUsZCi8UGqfA4aVLUTW0lP+zhPSF+3ANtQdCZH4A0+5U+Q9YGat75t+Qmo7KSvEMPxZnSwj/WOpKGnhg27aBwSo8eFQGx8beNglQ7EsE9zSr/mlnYyRD7BZO+8ewImgnoBR9gMfxlaOTyDINYrUlypGHF75iXC94DjaR2axaNZluzz910Vhpnk6XZ3aTXStzb+8czssT8ZV94s02JPaKfilDBZ6/RZFN3ikFR9QrKIcM6ii4cBZHHwbH9fGWIKNM/vrclPuYWRUOO+KP9G/FpyS9MzDTTGzJfMVyopyhMYOXHLuvsEil1zu4nG3ALwoT3YKkEnm58fw6LjO+kjpYRKYTalshqrvvXya+i1/gWBKKZxmUZhv53JwBqAVp9R2F/C7KuudAyKBHgPUx42yyymDTpmA7BUl4vIuZnLPuqfaHmHtVkBO5KQr119Hu4hp24S3qCq+smwGk+AUZl334qwYPm2VUPLuCMp577xAaVrCk3PjgUUr6A8ijKjcalfdrRItP2IAXFH/+YXwzQZQYmlALbHOCBBMuYo9HFMff1KXzW2I6CgPqUZFkg4HCZ0AvnKPNkGqVGmFcB/186Tw1G5Q8DPw= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(3023799007)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?o49tzVnSU/f2U/S7RZNlh96lrT63f4Vxn0eAAuM/wz+R7VNmRmWUdKOeQdqG?= =?us-ascii?Q?w7aMB/rZ0TopY1WRPXIcZCM/A7J4or4aBhHgJDZef2qQsrSpFSzBRlDWQT7p?= =?us-ascii?Q?B8O6U2cryJm0pgTPguEdGhqhFReRTurU2CO2STTYT+KyhBrj1qvKFNqj1Yn9?= =?us-ascii?Q?SZa6QfQuTrXnB2NxxGoPQ6txNsKd2cEpLIx1a4dYxgdrr/uwPOtdmMUa4+VG?= =?us-ascii?Q?S7XGSEf/8xYHl1UTsmy8ThpgdUpr4qWDS9lJSfooBhp8OZLwRTjWmD3oq0al?= =?us-ascii?Q?Hob6aP6eaghq1TCB71un73bmjP3Qz5747wbY3kD25+YSpIPAqO1Xvj2IspMT?= =?us-ascii?Q?06QKFWA/upKkKma3BUZJXX4NDCS/IYFWengZ57nTbjSmgnrv8i8LJPlVlkzC?= =?us-ascii?Q?64TyR5640EGQBiixkZLziBwdjF2NJmSmURLrRcXqoMwHhQl+2mwYbXvO2ODj?= =?us-ascii?Q?h14BQtu91e/H9nLdYoAnZ4FOlEjchp3XJs8UfX9fHwT8wmtXiSqb/owo639f?= =?us-ascii?Q?idqgCjjTYMf7LfjzO5/xMYEBTATeI2WP2gIGnvX0jCWbk85FtxOlYEGFCOmh?= =?us-ascii?Q?DAjr/Zq2Hcb0jDhjU+rXBPpaYjrml5iRt4XSKj+wm5uJt9jY5v6ghEVt582P?= =?us-ascii?Q?/LhkLOHWkDZ5phjeh4LN5HeGEdO1i0WJjMd1ayIWrHLjvYBG5qFpDZSnefMs?= =?us-ascii?Q?8m0ZUCQ16Q0/BQKeN+QbzdSdIiztpAlxmz2w1XuRLdEbrp+jmjvRd1M9fTyM?= =?us-ascii?Q?O4EGKj5nOb+glHSCcbFzW06LARzkRVdljzzyD9I+bSSY1kVlS5s8h+DDq7Oy?= =?us-ascii?Q?BsCfsqeEaHoWzPQ5JtBmCapmJ2yZ47mFjEbgAoPQtBwVT9N84fRu90stJqiQ?= =?us-ascii?Q?/iV0qSM+N0aBnrppehMofjFS3/Qnm/eEdwcCdHNlU82j8GLjvNzchlo9hVA4?= =?us-ascii?Q?Eu+f4sEFZycVm7w9BeVZ6Cxov89TD4scDrD+Rj0bqjQHadPjhVQ3JF2RFtMr?= =?us-ascii?Q?5shpqSUAFOhP5CszlPTgapxfzkjj5QnY+xL6AcDVezpK/qhTK62H+dyVzPfu?= =?us-ascii?Q?f7LDvLMeFoPB1ymUYvSZHKyPdPO+3xlaoIVpPMj5g4cxG/MDO65XEH6jkMSJ?= =?us-ascii?Q?BNW+1LyFFTBGMuSEVQaA5FZ9UzXrwvDMMhIX78WOFhcVuGnm4opKQw6zudxL?= =?us-ascii?Q?z9uv62pl7sdhCXcwnOSI24u/zmbuAGieqPFXC01zQB9Be0gFQlp7jsY4wCTW?= =?us-ascii?Q?5sObi3Smx15bab13q7A5oeJ11s6PH6cQwgBDxANj/47dz2KCz+XwPEwPNtz+?= =?us-ascii?Q?TbjWFdyV8Vt8RFPhspSjz3h6y+dyF1+UjA2XA3JGE7luCI/7JlI3Fklrr1mh?= =?us-ascii?Q?X+WRi4nKg4B3nNNzSSUsAkjgB1mMi+7pp2xkR1DN4XsuCDOWSqIHIHUZm5a6?= =?us-ascii?Q?koqTJ111NCvPVKAkr/p61mCe9340d2Rx8iGqY3YniKpxRsf9a75dVPjDnY8p?= =?us-ascii?Q?izOsVqhqcmlcWX1AM2NsXfRird3EbqDGc+Z5gi4p0w1/a2vu7CnTCXxoPK65?= =?us-ascii?Q?InVXyL49AOkaIrQJ2775d4xz3wcDeYcrbei1PvtA5ESOzJA+29U9wQnFAgvr?= =?us-ascii?Q?Oa2pW38MklrejSlqyL1EFZWORXOPTtpAp+dXm3iieOgBnJs1c7U//VbDty63?= =?us-ascii?Q?h6qkmezhv+HFnybzWTafC0Y6VLbQL4o5oZprOc+rbjYI6WGyGgl1nXLXBIvT?= =?us-ascii?Q?baWIxre+vBCJR6aqHZB4h0ylUECE9M0=3D?= X-Exchange-RoutingPolicyChecked: YVOXh0uhQgbO+a3nnP7N3wisbshtVwvbd/yJgjn04a9M+CMfhXm9hEl9olyd/MF/o/RCJoQnzJCKNHZPTTOWy6ANqj8+ho1zV+pFqVc5sT+knN8rrMK9DW7P+Kle6VHf/Ef9bGHmRmbZY0yznn4hx4gOy4BfACoSPIuyZFi4kDn5NIHmgo15dJBm+1N1yU5ezkh92+Utzo7yyvKDoZwgbQ1RozkWLi/0/MpXXECmHhi3kOHSbVXV3b69WXNCVASk4LFPdHZsB3wAFRJv5yvesi8qcQI5f1pB0xLnQnQfK3/eqT5WHaCRaOJBMMJIgTJXovFpFyz2uHgR5kqgdy60/g== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa172ae7-49cb-48e7-8556-08df2dd958a8 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:03.3880 (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: +DIaaox02iSbIzzkLpokkHo9OA2sRiBlJcsKu9szbB0Jqt6lFY7lEhCM0wQeCywsyfk4ZAstJUU1i/TO+XE8+r/AUJCikQWnxdNbj/JAZF0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-ORIG-GUID: 22aMbDFpKLGza0VF2G0YpVzTwkjh4taC X-Authority-Analysis: v=2.4 cv=HYGB3SE8 c=1 sm=1 tr=0 ts=6ad607ac cx=c_pps a=UMsKb9OrGFB5W2EpWsGVZg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=n0Z0T_akzs0uib7mm64A:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-GUID: 22aMbDFpKLGza0VF2G0YpVzTwkjh4taC X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX68bLQwx4fDo1 zi7Fqep6djWcZNVzZj/rfW0D091wXBmZCb0BFMwqhNUFNE5oKIHyaIGFhlN2yJJJKDfSwnVRCg2 4lAHfqBZ9eR7ZahkTm1c2CyE/puRBHU= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX5wGbXOkLUYjs alq9f2fU11C0jzhOLDgCpRmgCvyzeF9s0ZIrYUpbYps7iMAdhHe8ZOVa88taxJ19HKEuVMVOGWf XX0UKPxNs92YLSRKX1cjfsCnhilbQYIh3mEwBaq7AdU2sud3b28SHooBv7aAgc8GIPFkqcEaZ2Z ahR5i/L2/ACrSG//ci+rIWFT4Wo/JqHS9agAee3YTnTVSa9leaNu2dF5n2INvRJVA0Zh1T7IrIj nigov5FMfFZhMO6bs53Lob82co50bsPrsi+VFuihumR40peQ0xFBH/KRLiawCJixNCfNZvDmYib l26stBNbGc5DHqYlOhR5WNVE6jESsNrR7930p4Bt9TiMu9g7PC+Jv/XWWr6fXwIq6iivAwRai++ ewE7cku3scNKnnhEQ9wX+yEgEJ+veZs9+ZNJEQ5s8GDBl7JW/ZMrgCJS+2CVZzU/Rne0CKD0PpO K6H8u8AY0RPLzg8Iayg== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1792411569-BDE78757-E0971939/0/0 X-purgate-type: clean X-purgate-size: 11620 This ensures consistency with our normal QOM-based naming convention. Also update the trace event names for those trace events that originate from a single i8259 chip. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/intc/i8259.c | 104 +++++++++++++++++++++---------------------- hw/intc/trace-events | 8 ++-- 2 files changed, 56 insertions(+), 56 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 97ecb77407..4b34e5a649 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -73,8 +73,8 @@ static int get_priority(I8259CommonState *cs, int mask) return priority; } -/* return the pic wanted interrupt. return -1 if none */ -static int pic_get_irq(I8259CommonState *cs) +/* return the i8259 wanted interrupt. return -1 if none */ +static int i8259_get_irq(I8259CommonState *cs) { int mask, cur_priority, priority; @@ -103,13 +103,13 @@ static int pic_get_irq(I8259CommonState *cs) } /* Update INT output. Must be called every time the output may have changed. */ -static void pic_update_irq(I8259CommonState *cs) +static void i8259_update_irq(I8259CommonState *cs) { int irq; - irq = pic_get_irq(cs); + irq = i8259_get_irq(cs); if (irq >= 0) { - trace_pic_update_irq(cs->master, cs->imr, cs->irr, cs->priority_add); + trace_i8259_update_irq(cs->master, cs->imr, cs->irr, cs->priority_add); qemu_irq_raise(cs->int_out[0]); } else { qemu_irq_lower(cs->int_out[0]); @@ -117,13 +117,13 @@ static void pic_update_irq(I8259CommonState *cs) } /* 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 *cs = opaque; int mask = 1 << irq; int irq_index = cs->master ? irq : irq + 8; - trace_pic_set_irq(cs->master, irq, level); + trace_i8259_set_irq(cs->master, irq, level); i8259_stat_update_irq(irq_index, level); #ifdef DEBUG_IRQ_LATENCY @@ -152,11 +152,11 @@ static void pic_set_irq(void *opaque, int irq, int level) cs->last_irr &= ~mask; } } - pic_update_irq(cs); + i8259_update_irq(cs); } /* acknowledge interrupt 'irq' */ -static void pic_intack(I8259CommonState *cs, int irq) +static void i8259_intack(I8259CommonState *cs, int irq) { if (cs->auto_eoi) { if (cs->rotate_on_auto_eoi) { @@ -169,7 +169,7 @@ static void pic_intack(I8259CommonState *cs, int irq) if (!cs->ltim && !(cs->elcr & (1 << irq))) { cs->irr &= ~(1 << irq); } - pic_update_irq(cs); + i8259_update_irq(cs); } int pic_read_irq(I8259State *s) @@ -177,24 +177,24 @@ int pic_read_irq(I8259State *s) I8259CommonState *cs = I8259_COMMON(s); int irq, intno; - irq = pic_get_irq(cs); + irq = i8259_get_irq(cs); 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(cs, irq); + i8259_intack(cs, irq); irq = irq2 + 8; } else { intno = cs->irq_base + irq; - pic_intack(cs, irq); + i8259_intack(cs, irq); } } else { /* spurious IRQ on host controller */ @@ -213,34 +213,34 @@ int pic_read_irq(I8259State *s) return intno; } -static void pic_init_reset(I8259CommonState *cs) +static void i8259_init_reset(I8259CommonState *cs) { i8259_common_reset(cs); - pic_update_irq(cs); + i8259_update_irq(cs); } -static void pic_reset(DeviceState *dev) +static void i8259_reset(DeviceState *dev) { I8259CommonState *cs = I8259_COMMON(dev); cs->elcr = 0; cs->ltim = 0; - pic_init_reset(cs); + i8259_init_reset(cs); } -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 *cs = opaque; uint32_t addr = addr64; uint32_t val = val64; int priority, cmd, irq; - trace_pic_ioport_write(cs->master, addr, val); + trace_i8259_ioport_write(cs->master, addr, val); if (addr == 0) { if (val & 0x10) { - pic_init_reset(cs); + i8259_init_reset(cs); cs->init_state = 1; cs->init4 = val & 1; cs->single_mode = val & 2; @@ -271,23 +271,23 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, if (cmd == 5) { cs->priority_add = (irq + 1) & 7; } - pic_update_irq(cs); + i8259_update_irq(cs); } break; case 3: irq = val & 7; cs->isr &= ~(1 << irq); - pic_update_irq(cs); + i8259_update_irq(cs); break; case 6: cs->priority_add = (val + 1) & 7; - pic_update_irq(cs); + i8259_update_irq(cs); break; case 7: irq = val & 7; cs->isr &= ~(1 << irq); cs->priority_add = (irq + 1) & 7; - pic_update_irq(cs); + i8259_update_irq(cs); break; default: /* no operation */ @@ -299,7 +299,7 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, case 0: /* normal mode */ cs->imr = val; - pic_update_irq(cs); + i8259_update_irq(cs); break; case 1: cs->irq_base = val & 0xf8; @@ -321,16 +321,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 *cs = opaque; int ret; if (cs->poll) { - ret = pic_get_irq(cs); + ret = i8259_get_irq(cs); if (ret >= 0) { - pic_intack(cs, ret); + i8259_intack(cs, ret); ret |= 0x80; } else { ret = 0; @@ -347,7 +347,7 @@ static uint64_t pic_ioport_read(void *opaque, hwaddr addr, ret = cs->imr; } } - trace_pic_ioport_read(cs->master, addr, ret); + trace_i8259_ioport_read(cs->master, addr, ret); return ret; } @@ -355,53 +355,53 @@ int pic_get_output(I8259State *s) { I8259CommonState *cs = I8259_COMMON(s); - return (pic_get_irq(cs) >= 0); + return (i8259_get_irq(cs) >= 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 *cs = opaque; cs->elcr = val & cs->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 *cs = opaque; return cs->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 *cs = I8259_COMMON(dev); I8259Class *k = I8259_GET_CLASS(dev); - memory_region_init_io(&cs->base_io, OBJECT(cs), &pic_base_ioport_ops, cs, + memory_region_init_io(&cs->base_io, OBJECT(cs), &i8259_base_ioport_ops, cs, "pic", 2); - memory_region_init_io(&cs->elcr_io, OBJECT(cs), &pic_elcr_ioport_ops, cs, + memory_region_init_io(&cs->elcr_io, OBJECT(cs), &i8259_elcr_ioport_ops, cs, "elcr", 1); qdev_init_gpio_out(dev, cs->int_out, ARRAY_SIZE(cs->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); } @@ -443,8 +443,8 @@ static void i8259_class_init(ObjectClass *klass, const void *data) I8259Class *k = I8259_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 = { @@ -455,9 +455,9 @@ static const TypeInfo i8259_info = { .class_size = sizeof(I8259Class), }; -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) diff --git a/hw/intc/trace-events b/hw/intc/trace-events index 7512c6e600..003924ddb4 100644 --- a/hw/intc/trace-events +++ b/hw/intc/trace-events @@ -1,11 +1,11 @@ # See docs/devel/tracing.rst for syntax documentation. # i8259.c -pic_update_irq(bool master, uint8_t imr, uint8_t irr, uint8_t padd) "master %d imr %"PRIu8" irr %"PRIu8" padd %"PRIu8 -pic_set_irq(bool master, int irq, int level) "master %d irq %d level %d" +i8259_update_irq(bool master, uint8_t imr, uint8_t irr, uint8_t padd) "master %d imr %"PRIu8" irr %"PRIu8" padd %"PRIu8 +i8259_set_irq(bool master, int irq, int level) "master %d irq %d level %d" +i8259_ioport_write(bool master, uint64_t addr, uint64_t val) "master %d addr 0x%"PRIx64" val 0x%"PRIx64 +i8259_ioport_read(bool master, uint64_t addr, int val) "master %d addr 0x%"PRIx64" val 0x%x" pic_interrupt(int irq, int intno) "irq %d intno %d" -pic_ioport_write(bool master, uint64_t addr, uint64_t val) "master %d addr 0x%"PRIx64" val 0x%"PRIx64 -pic_ioport_read(bool master, uint64_t addr, int val) "master %d addr 0x%"PRIx64" val 0x%x" # apic_common.c cpu_set_apic_base(uint64_t val) "0x%016"PRIx64 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:06:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454157.1667720 (Exim 4.92) (envelope-from ) id 1xIm86-0003K5-Sj; Mon, 19 Oct 2026 12:06:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454157.1667720; Mon, 19 Oct 2026 12:06: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 1xIm86-0003Ja-LI; Mon, 19 Oct 2026 12:06:14 +0000 Received: by outflank-mailman (input) for mailman id 1454157; Mon, 19 Oct 2026 12:06:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm85-0003D4-HY for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm84-009h3t-UK for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:12 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607a9-bab6-0a2a0a5309dd-0a2a4508d86e-36 for ; Mon, 19 Oct 2026 14:06:12 +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 6ad607b3-f659-0a2a45080019-94a397440b8c-3 for ; Mon, 19 Oct 2026 14:06:12 +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 69J8QSxm3508824; Mon, 19 Oct 2026 05:06:08 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021083.outbound.protection.outlook.com [40.93.194.83]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc4x43qng-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:07 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=q+TiuT29Lft1Lhctk/2jJK60T8JNvSJE91lHid7oU 0g=; b=ar0/SEzDl89z7nuCsFBUJyacAApX7qxBfzgVF/lNeSSfX62xGbXrNx8JS dD1DHeAyNY1OcL2ro/wBWdKH1FpOu1+45q+8EBViNRfP0g1phDBpjEZSG1zBSAWB BwuBkKGMN1JIuaSM+PTOGFD4v/LNsbKA5rSzCDGYBmBwi6yyK/88+0jmI+QJlriq 5zjO0tB14NwwftXJZz/eYvMOtW9LMUwN+Mk62Rzg+OJ7HOs0Iwn05zgOe32tBcUi ckxrnsKsq2a04HccG1gxwsdiXDWyCcRhZO3GJy5ZiOinOkM0CjMYlhEze7VMCNGD fxXWTRItEzpJKLBu6kbrKXy7ygEAA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=H51gqg3MY8tCh0KWgEmoi51cAeZ0Tuk1nsJ29EgqoE54RpPuWUdIpStbrMkZDmBoWSHPyLYGp4ng+U6oBIUGDFKTp7a7cQFsXB8Izz9eV02ofL4sCK8IiITEyVMKdkOZYqiS2iNruBWz2pOv+V4XkrM/AhwBBROKNwmM1RNUBETAyQqIvjtBRDzWcomQ2TbbyKVdWe2SRgg9X1mjFvgw/Y7HAOQVgKxwoxU4whzJqxKGuGZbIsLlU7b6I+Yc2A14MPtrNl/ZUZ8K4WatE3Y65SiT2piytQlxCLkhaE160vCQQszf9rx/Id/dMNXST2Euj3W1EysyCSV1crEc+MpIBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q+TiuT29Lft1Lhctk/2jJK60T8JNvSJE91lHid7oU0g=; b=JimvXdgU+vYXgutnUmkMgHbI2kSMs2m0uYc9reIGQGfdyr8beGREqnlF/Uxn46Ne4N1T5cLXKhGLUYNdHzHFwjiY+7v4camL1cPoBThwGshilKPyN8iQgxapwYpz2P/nXyeTqujKs3wwQmJRPdSNmvvRoD/0bKscPSkoRGjvIZdJLAsZdI3pEe0WXagRtzTMHODc0ujA9bqKgeILH36TqUmg/Bb2JRqvbEXblTRg5/fVaeUaqyuWkdecz4JP17H2BljHh2u+DTGvRenU6Omk3VI//dorwSzoU4A6DT0O727nU09ihoq/z2oKcSTNla4Xdg55tmvJpsRetTEicO+skA== 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=q+TiuT29Lft1Lhctk/2jJK60T8JNvSJE91lHid7oU0g=; b=CQK/I7ar51r5GaY5aeHA5PtriSBv7yGZNVPPhtxKrP6dyAmL0ht4Z/2cCq3bQ9hh+FzTog4BULtB4GskOMNguI4/WjRU87lLLusrDcwLBCq1krJaewZYJl+Ajmkq52ziWj0T++PhGe47hpsiMFVFqOZa0kFTOo+TTYq1XU2hjNp/Rj592AiJVJFB89YmqoR5bZ3o6hnY81rOxvay/6TU7s60/Qy5RfOA+59HwudKXAQoGTzNVaHrBgxvdwG8SYfcGHsxF5JRhBc7H0VrrdH2p+klEGL4udWGaxLzMMdt8+XbYi8xT60urn8i1zDL5yWmoDKIcZ+9Zu+tlLq15PYFfQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 14/28] kvm/i8259.c: use kvm_i8259 prefix for functions Date: Mon, 19 Oct 2026 13:04:46 +0100 Message-ID: <20261019120517.1448687-15-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0345.namprd03.prod.outlook.com (2603:10b6:a03:39c::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_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 5a892209-3942-4aa5-b696-08df2dd95ab2 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: EwMW6GjyLXaYxr0Aeugg21leQ+4eMTEffSJuShcLRp/iB/yTiIvkYI6nwuIeqamcU+hDhsuT2hh3DB8bINauj+kk9ORTLHpRbRyMXKSxrmBOE+UgNrP2lnq6V0SlKdYu47rYr6/ul5pabP5ALLlgwBl3Cf6ejSD+e+AhEGqdSPGDOCrDLMtTRY3tC7B8U74lBhtqPzpPlfHW+iL7gmlmBiosz1PUadWn/EkTHKwUDlrNTg2GYCxYpCjyVknaNkFRP83Lv3zJ/84w7COmH7t6L/1QLN50yQBZe5u04uv47zhGdERpY8/sW0aOv2UqpcBlnCuDFWeh7jksRvxGujEGgo05m5TY7q5XffZOE0VR+NMe9kFiK9ZF7XHnuk1mjvfZ6I3QWICIIIFB2TVLAWop6tfccu9LDFy+7IjoE5HfVmni8xLFOPVntEyso6jiLBLK+m1qKpQIzxWzvvkGdcG6q1z1h/1HIISxAoH1MF6lwbHXfGRBnxSuZ8TFZ57kEyKoI1ML4uhPiK6lZxEZD/vou9Eutr8xx67e/wSDF8RAe3niuUbtY9Xb0N/p3hdvYUwibxprzL5JH2y7hzQgsuXCHhFLxTBkMHSq//sM3bYBtjcWOY5wBMQCkpluVWZhHcm8oLXEz1R2Bq4rUKjDVB7Hu4wG3aLd6+h8Vixed2sBaVA= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?q54s9NKHwxN+7zw2S1VzxRpm3c+W5J/E6GvwD3xIKLA3FmWkIgEwjrWfyUfG?= =?us-ascii?Q?KAMtPEyHZtA8i1vQHNRJFD1qQhRhJ0v7trEFOEMeuUBkvNSDZ7f1K5YRmc+g?= =?us-ascii?Q?uIiEDwQ2vJTmg2y2iw0XP26A0cBquI7/j7QRWUDkVBxInMbgE1kiX1Jvekd3?= =?us-ascii?Q?+qr5nGFJrwFKP+VmaZF1BHQEOzsmVJfIc1O48fyWpAGvIw86Vl+6vOA0ZBON?= =?us-ascii?Q?YCjQNNkrx+gTVmP3G1YVi9PPRRKQKhbGU7rR/+bRH0oY1yXNmumUthRvG2Ed?= =?us-ascii?Q?C7Yd7pov0AiCP8PrsZTjElNIZzjkCo7ZuMfDR81KKIHxtqmD8SadIM87fxLG?= =?us-ascii?Q?WZM5WKiij2aiwvadZRrjWEUwhkgzj1By+kvj13y1Q66TeAzk+o8TKO3C3T4U?= =?us-ascii?Q?CKzuT1BLCvuTSaO5mKBBp0NABbludWVcS1jsEa4V7YS685V5hZ0cSE17hTiO?= =?us-ascii?Q?Ei0FhudqYFyCh4k+LnljhGN4TIFdQP4imwm0hbCC2007y3dOoJQOEWP7iMR3?= =?us-ascii?Q?cK/bsWi8no4z4QNJRMc+mU22HzIk6to4veRkLnVNcgqypCkWYS32iaWpWfrG?= =?us-ascii?Q?i7j0zxUCqZrLEnTYqTrK3v4bZ3hokxXm7T5VsU9soZR9mfPI2IZeaRaZxfy3?= =?us-ascii?Q?HgiQk2YDMV6gx7E308uN2lpG07t1dVLd3Dw/6kDUwiK9oaWUtm986IMsnPI6?= =?us-ascii?Q?I3FXIpS5R3ojyGstxgg/EROIFKYDAptwq0BB2EdHsqYmTIddMi+oA1LD3pgQ?= =?us-ascii?Q?Z1bpqdm0upgz6nDUfsC66nU5bmiQ0o4mhqbEeSZwAmCGP/y8CDcB5X7mv4fr?= =?us-ascii?Q?uXNVkdM98gPdSBYSEuQH7oGVtvjXmiZptcxiciHxeqYkx24eGOTiTls3q5KP?= =?us-ascii?Q?kPQ0kNumikXFjGTcZnTgBhY3hLR9cA3RP8LM9APn/uyDDwItdYMoG0wF8veC?= =?us-ascii?Q?TYwFA/oR63/c2TBYpi8jgpx0LoArzv8HvPOs15eVWQ85Rf6A6UvELTYcAuJT?= =?us-ascii?Q?dwlbHO8Oqs9HkZxKz6FbK+Ymmtv2RiFuoQakM11gTTcKUDVCsym79RBn3785?= =?us-ascii?Q?lm6fNC+FS7FA6Art+klwhRfhvS1qKLXHM4rwF7kMZnpoHBOAz78Z8xj3s0am?= =?us-ascii?Q?jxs3mN8XQmCZa+HqA5C+y3x+Z4rFW8TGr6MvUX9sQaoIl+fnIpWlZi0ScpMz?= =?us-ascii?Q?+lrAP79xdDVUgRG3mVtInaqvb94WxU8FpizwzYnICxvpYUIDydTbsL3sjU87?= =?us-ascii?Q?gGkgTChY3KMgdxz9MZrotu7h98U8G/XmVzQlBkiu+RBcxfTCARbbF67Yn8p+?= =?us-ascii?Q?JrQ+bufPKOk/PdywYX56PfkJjqZF/6CNNffJsQcLTbY8vlg8aOSrx0WO4Mwu?= =?us-ascii?Q?+lAcLnrYVdySQm2/1UO1x4mDr3HYQcPWRAZYkb1n/yKUvPXdXBNh7G8tqkDV?= =?us-ascii?Q?uRmvb/0Skm61+8PO3QhbUrfWBCDWLMzqNhB5v3vAx5bSgFvZOSbmZE5evGRv?= =?us-ascii?Q?ivgqbrJbJu/kennY1ZL/M6RaekdHxX5wqEsZ+Cs14zX15o01IEIQZ1WJgPA+?= =?us-ascii?Q?q3xiMxfvkI9k3JajOYqMaL1LhTZdcA2HJEL8XAw8M8Dx82mq9qFc8iYKgZpL?= =?us-ascii?Q?PgYPHF4eLpvHlhNaXN2Ti6MwoolvO7PwwOe5YbC+kiCCR6aE/YhFP/RuYE9N?= =?us-ascii?Q?EkcamR1t2Q5xLQ2mTxQ7PwP8beJ1iP/D6Kb/tjWc0VpCNKfOd/Uft84VSp52?= =?us-ascii?Q?D6P5ncegcpwKhXZicwgs3BlEgabT2ng=3D?= X-Exchange-RoutingPolicyChecked: 4O99g9hfNJhaj38d9KGvif6GPUY9AhQj7INl3Xz5NGE/MVB9APTkL8rpJo4Vh2Skp5Noev4CvNgIHjGGhdF17c6jjeGn69R4FAG9iSI0qBYwOOlP8o2707I63x1erJ9tCu8R1tHwXce6Biv7s6BFfrjmcsD0sJFQc+mq1rGcKLqyETab11ansQQ+odbAeoYC6n3haQxJJHx3+8evLOm0+KduDDCf6fcNUXu82sNNvhDbSKPx9WsPU7jYVRDtw1v2HIWCVbQBSQg5s/9k2oEALRTcHTYIp+GnEwYp3Puenq175OlkGGmE9C+FUxKu82nZ6OWwvVR/5taehh2mumNnHg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a892209-3942-4aa5-b696-08df2dd95ab2 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:06.4714 (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: k20q7/0utuKVLQCRfOf9DwGbxpWsy22QHxxWdiVou9yObHnFpQXcT/g9CD/FmWhVFAVFhyeq0dVuXIu8RwKagWHuYZxO7fPMNKng1SaXVAk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Proofpoint-ORIG-GUID: NGM8duR-YZmZmuJUu3vDkFvxi3fw4PAR X-Proofpoint-GUID: NGM8duR-YZmZmuJUu3vDkFvxi3fw4PAR X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXxePepuclIsdq FhSg2VFgBdOhnxohbZkxWEfKr/Dn+Gxhbdj/IU0cIRdQ7Dy/jAT7zBP272VbJx1K+q77wm6hClt AlIQoR1TOwcVZsuiB6gIA9hjDOehuxg= X-Authority-Analysis: v=2.4 cv=DqHDa2/+ c=1 sm=1 tr=0 ts=6ad607af cx=c_pps a=IDYaL8Jh3K30OkZprGHyjg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=b1AWVSNg6wsnrng390EA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX3rQ6KCpx8IWE fmsMfup7Qs0LGwzfZ11VebZ5AoeRZINv8txHYAGkAk7C1X8VXIxEhfROSAULTpOE58zARmzh6vb 3t9O/PPjIOMPv4rpno18clI6FcKA6Auxg3NYYnmqADCpNHIVH9hiQ8AHmSRwEFOWt8OY2Ndac0C pb1oVc5g0JAbaNWKscK1xSjOkfiBpbuXGG+KmnKUZ5EbOzwTUMoWMvYPM/PStIy80ShQEKNMdK5 oYQ3SguoEXl0YhxfuXqS2M7szAht+xeBrM/oJckGAyVtLneLkvvkMhDqnx7+D5Pc7SkSu6gWN8R ylZ5D3JDb2a3GxON3MGcMN2RLG2levoFP9/CvSNnKc3sCkiX1E9cia1BthtNC7kqoynDYmNURp6 +SHG1wCyvzShyMEmakH2bcEwPU+TQZ7lxok3rTqyUMiZNIayefYQrbS+VDDBhOw8GsGSWohy7fa wXABkneFK0TcYYcp7Dw== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792411572-CFED287B-75FDD80E/0/0 X-purgate-type: clean X-purgate-size: 2803 This ensures consistency with our normal QOM-based naming convention. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/i386/kvm/i8259.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 3a960e48e6..952f58be11 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -36,7 +36,7 @@ struct KVMI8259Class { DeviceRealize parent_realize; }; -static void kvm_pic_get(I8259CommonState *cs) +static void kvm_i8259_get(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -69,7 +69,7 @@ static void kvm_pic_get(I8259CommonState *cs) cs->elcr_mask = kpic->elcr_mask; } -static void kvm_pic_put(I8259CommonState *cs) +static void kvm_i8259_put(I8259CommonState *cs) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -103,14 +103,14 @@ static void kvm_pic_put(I8259CommonState *cs) } } -static void kvm_pic_reset(DeviceState *dev) +static void kvm_i8259_reset(DeviceState *dev) { I8259CommonState *cs = I8259_COMMON(dev); cs->elcr = 0; i8259_common_reset(cs); - kvm_pic_put(cs); + kvm_i8259_put(cs); } static void kvm_pic_set_irq(void *opaque, int irq, int level) @@ -122,7 +122,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 *cs = I8259_COMMON(dev); KVMI8259Class *kpc = KVM_I8259_GET_CLASS(dev); @@ -147,10 +147,11 @@ 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, &kpc->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, + &kpc->parent_realize); + k->pre_save = kvm_i8259_get; + k->post_load = kvm_i8259_put; } static const TypeInfo kvm_i8259_info = { @@ -161,9 +162,9 @@ static const TypeInfo kvm_i8259_info = { .class_size = sizeof(KVMI8259Class), }; -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 Mon Oct 19 12:06:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454167.1667728 (Exim 4.92) (envelope-from ) id 1xIm8B-0003tv-B6; Mon, 19 Oct 2026 12:06:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454167.1667728; Mon, 19 Oct 2026 12: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 1xIm8B-0003tk-7b; Mon, 19 Oct 2026 12:06:19 +0000 Received: by outflank-mailman (input) for mailman id 1454167; Mon, 19 Oct 2026 12:06:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8A-0003n1-FM for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm89-00BZ7Y-SL for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:17 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607b6-8faa-0a2a0a5109dd-0a2a4502e782-18 for ; Mon, 19 Oct 2026 14:06:17 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607b8-6ca4-0a2a45020019-94a39744966a-3 for ; Mon, 19 Oct 2026 14:06:17 +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 69J8QTtZ3460294; Mon, 19 Oct 2026 05:06:12 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021105.outbound.protection.outlook.com [40.93.194.105]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8jwkfub-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:11 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DSWPR02MB11441.namprd02.prod.outlook.com (2603:10b6:8:354::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:09 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=po3EEb9dG7/G0E+Na053cQN8h6xsnwFa0pjZGUjYe P8=; b=tOMVb/sQxDKYRay9HGLrNQ1vBTyj2zKggrW0QNYjZYqD7BfLAOWfs2/8v UxJx1pPzNyZloWeiKPu9rqTJL+nLXftHIZC0/k3n/oPLH+1lRx98YFPk/36BwXgm tK7eAbaPnBir46pJa+gjMWnwjVDRYW6EY0nkIWHwsZs2veE1Cf3ruyhX528waLMy oS82b/uw8D8tK5dLph6ObXnIO3jhwwd/QAX/ilto7cu9rDqmC0aY4jfAzLhXkrkm 3FzzfsdbWdLFO09YUKtuzXGJDf7nwYdHBqUZevwvJ58mwPog0aJ3JoVo/hlnEiQ/ bHrMGJaAlqe0/4qa7xnLpGfwfT5Qg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Wv45yEzcQFDAmDS2ikfc5aRsYA4UkWDeTJBGPaqgJ95AvkeAulVAAN81uPwDjAp6IYKcaQ+KORC7UG0VhtxsrSOa1AJglh07dmkwzQIQ8yEjLeGRS4t5xUmWWuljBKDlZQfrOozcFZryi8UaH0aeywUkK8YIXzmwXK9x4dL+3LP1r9LwleOSFWeaLxqaWwM1jgnXBIp6cWkCdP6Z1qO1qLyagaENNPHZ6tw4/wVE2sluZRXf35S88P2WyKlorw/rAF51TolkJS30uLn/lEf9HAcGbQGRcSpjZuQmCNUjQTfYajc59uv6z11vTsDVwLZ01c4Dz/1/HOYgbZy831zAUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=po3EEb9dG7/G0E+Na053cQN8h6xsnwFa0pjZGUjYeP8=; b=TdqJ7GZTuIAFyuAw8u9RXXfO/zyj3oHiRPfiVgqfz4tQfssOcnUdE2R9lXWvcisEbfgKQpLLrFXARSX1FmGiQaRuKxDz/6BvI/acRVbjcLqBeGhIOBpaTZQhjrk4r/JtWtgEOS607+VWm7PUUegTkpbqg5x3Gia/OWuM9iJEJgJFof2OOulcNYyESBhBkqtd19qmlHhHSLUKVUxn/KX+JbIjsVBEdtKk5XKbZdJfYDq5XEtP/Fj7kFM9hqhFlQATBXnX0edb41nUiHfqunZCzJ3BVDEq3Ln8gwWS+M98kLuKqKuCvytOEHdBhyRSdYoohQDIgtI3ua6movow+wN1ow== 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=po3EEb9dG7/G0E+Na053cQN8h6xsnwFa0pjZGUjYeP8=; b=GOZUOM7Ux6BwxWs1VVf1zXRbyOC2PSs2fQtySNTAM/AG1Wp9V/8K43+zenUqn3EUdOnVx27GTOcSeSTUDtTusXRDdPNR+akoQLXCludVii48lS+9L3XxDfwZ4i01xuRoiWbisEfEF0Wai5duQ8C1Wybj6mlJGan/B9bMaod2QXzqJN6nhkZilZH9lCe6MKz2CPAM4qtxaZOqHkEtcsD6AoiN1SSJ4RqIp9ApkSGFisOMB977ENqU05vll0uqs9YxMEa6o0S/iWYJZ+xgx9dHMdirjkVY+mFgXc8j+U09uvw0wDO++ANxclXnntOOqeVARJDPg3hzGzWe4A5JPj3ZeQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 15/28] i8259_common.c: convert to use DEFINE_TYPES() macro Date: Mon, 19 Oct 2026 13:04:47 +0100 Message-ID: <20261019120517.1448687-16-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BYAPR21CA0013.namprd21.prod.outlook.com (2603:10b6:a03:114::23) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|DSWPR02MB11441:EE_ X-MS-Office365-Filtering-Correlation-Id: 4796ebd9-b609-4371-9a45-08df2dd95ca7 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|22082099003|18002099003|10067099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 3gSknD9vFVWEMRCf83RiUdQeP2j7+6PidSWO2Dz24ejvrgjlu8RWA0kHVn7gIhrnYyQk8hYuqmpUYM8p/NTSWChPlqUGy+pMZh1zl5i+NH+xVpMszTG0bfUHICmecEbvUTQFPHTTh0FCCBlKtuOMUzBPDB1mTxDM7pP7xy2wU52S9uXUCqoFKRrMA8OMXojJW1Tda8UKtIJLOO/iAOq6xvz/kb8jWbpv3EPa72qAaUOKf1PpSe5vjwJVSOb6sB//NBGQo0OE8OzzMMmLYJ4aPXXKHQ5j+sHbCqDctoNKYxQ4dFGdsMqwKL51IFjBxzgLiB8PxXj+q1WHtZq/VtzQDRNFKG7xcInAcB4Rj+e8n4O9dbZa2yBwAu3TL88zjhMHnABryWnrAMxc3JvZSgrTYemGPd4j2L1V6Hbr9oRT0rhSHMuNgn7TIrXd1weqdJAV/rYijEknGxFHJwICPwQ5yURhESlV6LrHVFsHzt7tAQkr/YnWXskfsag88/PQCfm+wNbuOGYtmgK3hxiVEdV8klNWVsJM+3V1nWCVRCAIMQuN3+5V86R4xqL12yXNZoUeyRZBxK4MQ90bnEKbUFYBYxV3BzA02LjBy3uA/pUNajRcY2XEX5tJepeEERPKkeMfP3U/juEBIwC0+ChtHfCejB7Slu8y4sgA9GYfmKUuDgs= 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)(376014)(23010399003)(1800799024)(366016)(22082099003)(18002099003)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zQyS8JjoF3YdPpLgqw5KEDaJhBJiHqPDsL3+3otD5JO2ql72DeW48k3UQ5i3?= =?us-ascii?Q?6T/5p17Y84ZBedcmT1e12GgVXeac3zU1AaM7nrdE5s9bgj82ZgOPtsqia9hm?= =?us-ascii?Q?xByOtdDc6aR/HVDrI6TwGMaEABztvC6gyWKyS3nZ+SlM0N3oTGXikhhHf/ks?= =?us-ascii?Q?4qjPpzogYdvOCsXecl9eN+WKCqaJ6AAG/nFkrScDYJLGUKa54T1uBPrqAZ6d?= =?us-ascii?Q?P3X2CLrtQg48c13gZZXO+CD1XOGrgzo44sr8vzGSRURF5an5sMJ2YAkO43KO?= =?us-ascii?Q?CdtKERYoTnPqFmMCItFWOCKjDeRDN5Tqs0mssIrQr6sLpDk7T76AW92HjROd?= =?us-ascii?Q?XTJpnfmv0JJxN6RL3Wn6qyR4Y12A+lf8xdkQFLSr6ap0RqlE95l0y9AF42tx?= =?us-ascii?Q?byHjeUe/4y8Z8/5uO7rmOh2yO42Vn6qYZH1QSKOJGYyj+ves6HowJOrSEU80?= =?us-ascii?Q?pstj/alSCnHzQpaUTuG1q2sERSrJiYXVuY1hq+8x8jXgeKBvhPCeqXnQb315?= =?us-ascii?Q?4Evi0YKbVV68Lf3GwIDOE7jbwuksPZr3o+7GPy3an+f+fhGb3VLgPKMX2+CA?= =?us-ascii?Q?LaYqjvYwo/pSbiCapNclOZ1Uk2lo4F3XXXeZ/8AfZ8rQadLImZNql94RyWTd?= =?us-ascii?Q?7iakXwH3KYN1NBxIlfV+N9sDynJDrgD7MyOccjch5jEa28/p4pB3/dXa2SIc?= =?us-ascii?Q?H++tf4jVbgXLdjmllre2PcauBnRIKN1R+9XCALn6OBYCj3Gh/T+uBXpiiXj9?= =?us-ascii?Q?upV5u/VwYWwvnFVBM5nwpibTtzT6dJiuyB0PVwkFWVxjqjRPxSEOjVp9n989?= =?us-ascii?Q?wXrq9ib0ul46GQm48pTgI0IL/WfIt+ZWOhd++H+hlnz+nsSVf9JAxlqZItEO?= =?us-ascii?Q?6JCfYeKiBWvf+LNJFwKt5d9Si3wnSkrwxeEWyyI5+MYLBQPDuKAdY4bJMinb?= =?us-ascii?Q?+NkEboWA9fpoFn0bkS5RzzYHk+ADKkryAClwdNyR3YyG2v+kfsTmdRpmgWY3?= =?us-ascii?Q?MbwMoRWstpaBtuhhcAiLQPDxGwCsfdNpL1B9NSlZIeAHoMU7D0OQ0SnKvLyl?= =?us-ascii?Q?7/bum/ls9ts52xg121EawaImVxgNuh/6/hC3rrgVoi8OYY9fJneg9l0ySbzl?= =?us-ascii?Q?4sF9dZ5L1tsWERQ65IYC0wQE1GTfa+WSmkyde8c2OnkqS1ItIp1E07q+qdAp?= =?us-ascii?Q?DujUcv/IYVgLFne76PB3+cFEtu8yblk9JbM21tqPdUue62LpkCaD78kkdyWw?= =?us-ascii?Q?HTALU34yIWQn6QF9Z7rvy7c7mDmQjuXTWrgT0OQPOsjdBbYPkCpV5YqjmVoJ?= =?us-ascii?Q?i5JOTDObco9zqgWaBv4fHKvCVbb7YaCRGbbOCzurkJ43q2kffr+mp+VPnaFr?= =?us-ascii?Q?VDTFaNxgs/XT/5gsLuayWrHoed2t874yKHici9JUKp2Ye23IvTx0rr/t42dQ?= =?us-ascii?Q?JbpfY3kivj/xImXVycRHYYpRrKUXC4Zek7voA2Cj+EBNkoPybPJn7sl55tIX?= =?us-ascii?Q?jw8FZAqFe18GJTDZlt6S5ZFAtarwKet6lyN0RIjOPzeK0DgkImRdeU4nkNGv?= =?us-ascii?Q?o4/3Mp4JAvvUMJKtxbnlgF5OdtFuk8KNNYW6MTldD9r4oWl8QUepe7UXx6Ea?= =?us-ascii?Q?LI2WY/W17/D6P15qoah6r6bKjm1AEme/5GhKK/NH+eOk05gXbODqGCf4Bzud?= =?us-ascii?Q?COEy+Riow2KNag1YxIsfPutQ6K+rVyp93ZIQV+eU9qJX2jOasDDHDWbDIzFd?= =?us-ascii?Q?W28yNZf6/WRfYgtfczSamaZR7Xy2QDk=3D?= X-Exchange-RoutingPolicyChecked: gyEMWDK/WfVk0yNZNHNv38NLqUMoTqqlR4YfoI8/t8V491zZKinQ+0hHw8YYEZD4emBtRqddeSduOKT5Y1L39SYKKN2Pw8oBDQqZwQnCfLSmNum0XD/0a5HraLYSrhSrX05YE2oUCuKHAG4MAioIk8sjQ6ztyphx6HN5dW9f/pou7gjY9vNVdf+ePSuti7NRVQnfZfxdWzJ89yB5tAcWPygEz/yD18vkxl7qyruY04fZR0jpTWaZLGl5GQK6JbxqP0zuOz3939gJ7vAyBeLPnctdW/ztF/FeZe27Bzvdin7MzlPjhuV5oubJNkGrm5CJoj3A002yKTxPTnj5qdEUHA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4796ebd9-b609-4371-9a45-08df2dd95ca7 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:09.6290 (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: sPISeUbywyvEdtlksSVJJ7T6xqiLPJ3qSzcIc0YxKsRxzbyVAcokWwe+xbEWXM9RP6tJ3Y3yucEUMyhWnUyJG69oONZKshEvSBtI782SzuE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR02MB11441 X-Authority-Analysis: v=2.4 cv=OecNnRTY c=1 sm=1 tr=0 ts=6ad607b3 cx=c_pps a=zmg3q5OHj3OrxBnMicu8lg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=1L6crL_YRTbalZ11mEUO:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=bPck6Z4TT5Um9jj7BtEA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX/RnbWjU9u61G +P9ynO/lUwCx4Nlb0krTGm1eNCUu3Qp9tU4my8ICs/53UWplXw/9oZ2NEDC6THfCuc4HfNZJhmt kvvr2mfJLw9Y8ggIdmcXbFONyR3ZCEHVSoIINwYVLgAmUQbDxQgNUK1cDiupQ/G0tQFyvxQB8Hs yCYBjV5isfNwdZXa9VNgjepDcbRiP3DUVMEnSZqCj7N255JHShUdHF57uFLc0Ez10LwQLK6q8C0 WpsvSFhnu1LOHKDWNEGl0kH2khqGwf2LMUk3qgXlT6THXSwiqPwxGF8ORI5bem2K4mNUgr7eXnv p6Vo2qUS3gW4hpzxwz4RIxqQ1GtBkCsUwnZCCXwa68ypPe4wDUGfyUl5XYOT/M0L68pTBtf5cov BeFTHNpgwrFw6ncXJv4r/6nZRKf2qTe6QSOkuHalXxKPHKICUPoDRgrGwaNz861gkxKkmByutCi ldGAXmT0H3QoIRKzKSw== X-Proofpoint-ORIG-GUID: UlWlS3-PANTYhF7JWIkkeUqcDdFmKJ0L X-Proofpoint-GUID: UlWlS3-PANTYhF7JWIkkeUqcDdFmKJ0L X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX/e3ANpbUCF+O 8eQsgxxsicyQ47q7x6CUtyJJnORBsD2QdTd7MNE/qFMNd5pK++Kf2V2u9Yryo2IpgcMWpntKcMC +Vl9NmMGGcTji8RglZ2PbYVRLGUF1j4= 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-720697/1792411577-F3ABD2AC-6E3D95A9/0/0 X-purgate-type: clean X-purgate-size: 1595 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 31bd663439..09b761321a 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 Mon Oct 19 12:06:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454174.1667737 (Exim 4.92) (envelope-from ) id 1xIm8E-0004R4-Le; Mon, 19 Oct 2026 12:06:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454174.1667737; Mon, 19 Oct 2026 12:06: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 1xIm8E-0004Qr-Gg; Mon, 19 Oct 2026 12:06:22 +0000 Received: by outflank-mailman (input) for mailman id 1454174; Mon, 19 Oct 2026 12:06:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8D-0004Jb-Pe for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8D-00EDzF-66 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:21 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607b5-e002-0a2a0a5209dd-0a2a4506ac4e-32 for ; Mon, 19 Oct 2026 14:06:21 +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 6ad607bb-195a-0a2a45060019-94a39b0c35a2-3 for ; Mon, 19 Oct 2026 14:06:20 +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 69JBnE5U3621301; Mon, 19 Oct 2026 05:06:16 -0700 Received: from ch1pr05cu001.outbound.protection.outlook.com (mail-northcentralusazon11020133.outbound.protection.outlook.com [52.101.193.133]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hdjnwr1g1-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:16 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:13 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=4Zzg/I05mP5n7TY2uFK7TpWDkHes0ZRgUzLc2R50k 64=; b=igoqW8cbhcOcdA7/h3RrrXtLsjxYfoIEStiUn0bRSojVhsqACvmkZn4xs a4V98fHsfxvnt9gvtBNMDG9YA8mMC/3AoGbiF43dzExfp0jB5msxQhshl1IwWGvo H35IW9qxS+7fPBd+kIDUpBmQ2had5fP4+5CNGAbjfZfvqVc8GIOxY5yzC/eH1sU8 AhTd+Di6oB+Zdqmu/ZIWZgyRqNDo3nf7mMkJS+t4EKMKWqnsKaPSv3Fm66s41xPE 9wYCPMiO/2azbFHpGwYfsljRNOulyIV0THMXwZLvVD/IngVGrFsykxod8U15iIrz 86ZZ+juWijzP1Fa7qfpKpdvi+x2jg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=btm41jwWjYUZDSNGcz1huZrUT/YQFnvPMxAgGsUy7YMy2265NJ0EqDPmpljGeH2Mw+p+U/X9xvWXdWqOzUTs+UsT4Qx5guQ9nJ46wjYF3/MjHpmCOImIwK/W+D82G8SWaOcZcuoy0tD6JHbX8pv+mQrY08IOTg8VRqGIhKa7iEgOnXNgzQmP1MV/fyhcKmly2V/43S25sqE3+uVgnYqSzqguFS6SMB93gUAdzLuRuQ22Ywu561EQy3zveAAnp4vfp4B0SrbW+fcaBm3AjBPRXoz5rRHvBktXOS57ij2wKWYo7uOZhRUGc6SuSZll5TqKthhUbyNZXDrWmC0+d3q1BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4Zzg/I05mP5n7TY2uFK7TpWDkHes0ZRgUzLc2R50k64=; b=X9ahRmPQ5rQlbX/b1PuguizskM89hXKb1/jE0eXcchfnRx199dBJto/ybjKpfCCfuY+Y2PhCrCa3W6w947cdi74isg61PaHYc9gGeVgeioQEui0ouVa+EhwVJMMuJvRXti0w+oKYjirneLeuQWwVyJEJ79OlB1bFfLZzWUg783yeBbs7AtecNToSsmX8I7vcUAR10utn4ler3HKeeyKvfqarFGIq8efDwXpkIrP7mPkXqvcNFTm0sszdkdCgfdjeynK1aVbof+LTa80kVaiKQI5WEQ0c/OlFp9UT+oNHA8t+M1OPGwX0qjFConmkDxrppbF7qZ6Fz2PIYZkSL+4ESw== 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=4Zzg/I05mP5n7TY2uFK7TpWDkHes0ZRgUzLc2R50k64=; b=vFa1VIyJ+up/xksJeLKIRS47KJ63tR9l0N6k44hekhovSZy2CxkBKzDGkqi/8NSU/bu17LgXf7e+0fd/aAw8rmnqFA92prBPxZEuQWuO7epCSk9fW/axK7eup85lXX7f+1u4/DpNCnztrHwi3QQG7huRVqrn7SUrD8YKBxFS3AGDHwEzbdbdym541oLXVexUzSc31a8udUYBbX7AaT4FMENVNXNqm7YYtujwBYHVRzKq0IwNdLzA60KAg5UR8NdBEgKa7sfqUNA4nnLH4uDiCQDesZxgbPrU1S5buRc4Qd+yanx/aoHAHKdUOIY/2z20LN6QSBouI/rdPlkfa/+sOA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 16/28] i8259.c: convert to use DEFINE_TYPES() macro Date: Mon, 19 Oct 2026 13:04:48 +0100 Message-ID: <20261019120517.1448687-17-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BYAPR21CA0026.namprd21.prod.outlook.com (2603:10b6:a03:114::36) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: ec832800-bb7e-443f-f7dd-08df2dd95ec1 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: srM7CAQsBRQf4jvrcRaKr1qV2/58NfxhtN4cJijSXCf9616Dm+/A127zc6NYODP/r3L6+c+i5OtiVxr0mqyKcc5COIj5UjL6vYmH0ldOdFN5hiAZ+G1N/iuLFEuhY4D155OXeMiLzCYCpbSKd33uLt+o0+pxj9vYHou7//MxJ0qduCu/FxtoFo6tR92srmUPKcJaIvpfeLzuvkc+7UxjkpBojZ/NJ+mMhJr/xJcG/AG+S4dfKAK9HIM1O5QrTQDJPuZSNmJcgqxsr+geV5URpmDItu2jirc2MGL2raHIwr1lQyOAKYDhRE9TShwrWZLDLhX885y0cX/11A4gzUUWizbmE5XByK5oCoG0baagACDmmn/khy1S/Sy0x5E205NP8B5nqgHQVSpvJ7+eIkMEp7SWIDK1QhjEhbAB+ZkKjKUe7tc2xYMY3cGellrJHRmFKNwu4TgV6CV+KoW8Q0B9Qi0yVAEbGfcJudZjZiJPO26zGycgKZkcUuiA/0ND1R/+oHsirJbfM/SQuTNrXRfpSilaG8ZvOuSYZsf6/By/mzN14x15LX0mOoUF4Eu7lR9jElsdBTUNLFHDV1Vj52QHV50PGsoKwTq5d2VFZS2LRlwtIRivB8i3896+yXD5nxkmJEU0tcuGWwBODwOzZgkEonOUoNM+G+tu1CCl5OQQOFg= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Fo7dj0tupf3hwlJ7www9LzYoNM3rzyV1ZbUop0Da4qkEcMKjyG5FXAsLpejG?= =?us-ascii?Q?IDxTNfiDA37lnZkKzth1Bxhsj6Ti9IzMO4HccOo3Ebp0YsvYFEJIgaShT+o1?= =?us-ascii?Q?0p2nFAVnlB6AB7+5dOv2aRXddnWtI5CXZpnCtVrVzsa4TI0HRtr7H2L+ak7H?= =?us-ascii?Q?yJj8vlnJJ/vQ98Nwe7zKSmrz4HWrXCyR2N/1FSFi61f8bPxwPGIkG1NtWKsr?= =?us-ascii?Q?8K5ka9u0dUg+5TN2q0znUul0r7PoQD56croBvoDE8uB4zq1757D8SPF0kGHk?= =?us-ascii?Q?m3kQhkcZ8A/ua7gSSPSCUOPXARXRJkQQUqXsR4RF7nmS4O5dfp9RRrBZmH0g?= =?us-ascii?Q?7xFqspr8eI2X4G41NWTjZCZDOZl6VccXCdjoVc2SEjyD6HYKqqcuUZ862oa2?= =?us-ascii?Q?wP67anHc4ePsIBTlR0nmiVrBWOpTlKh2cRT5tpMqtETtJHArVVBSm8C2DV/+?= =?us-ascii?Q?/WQzX9FYCpB/1t3JUBWzuQ4d7XbWrNocbgeeA+C/URMdL3+ofzZU9RDXriQk?= =?us-ascii?Q?vPVn7zwCH/Aa83JyE2EMr6H7It0JP3trQWr3u9A7d/WWHNPPatMbQIU4a0lG?= =?us-ascii?Q?4SouQ2GDe/Rhz46lZ+t/o3PvgHfXOjYQaPLiPBo+mbHCUnXquhblmGp3+hLM?= =?us-ascii?Q?wLqoBw+cS9yBiE/CyMqPX3n4FA0j03p/l6LQwohXh5YaR6rC41oJU5qfYNW9?= =?us-ascii?Q?am1M9rRnVF6FMWbAyq+8CiqtzfX/yru33O7C4bo2Bh2f3zMbAp9TTufxPGT8?= =?us-ascii?Q?z8OFjpPRNXEmChMkmCuDkZQiyW+JPFFPLItC+C8u+e0PLWV2ZQMjjlli7ZPZ?= =?us-ascii?Q?uKBh8WsBChRFAo3J4OEFd6oFYfcw2rXdRWROQ1Fbr/xwO9GEGiw+MiCtVEvG?= =?us-ascii?Q?aeKgzEpP2CLJwh9b6QG6I/XuJV+rDVlCE6/p4+8rnysL31khwKJw1S9g7qkF?= =?us-ascii?Q?i1legNz7ybbSvI2ZWZyctxjS9SxgIoL20aAfbioH0Cq15hT2Nfhz5oTjwe9y?= =?us-ascii?Q?lsg1+yq/rNK1/FtbimkDM+LRXt58zcb1fhQUTBw0AAzwXy+RZca5c2UZY9+f?= =?us-ascii?Q?HsO9gXXNH6mbH70UPbKFbnXH9+BNyh4pmIClJSfKxN/MwcERSk2J6C55zXZ2?= =?us-ascii?Q?Urq0zDpcO/K+JqekKXcAP8hQopOfho5JoXp03+hlGVV5HXSM7uP5lwChW/NJ?= =?us-ascii?Q?Fq1nBzd+36h8ereOt9f9IioiIHqLj45XTEpWex3nYfto+imFFNwscln5weY8?= =?us-ascii?Q?tAeVN3PfNDmLiGyk0mn/l43LoDvTf3sA68f46/4DkfQmQny2XHzLN86QhcAA?= =?us-ascii?Q?/5msfTP8VI3zcQhFumEjz5YgUSmUNPIb1vUisPAecCDz8UEMC3kxPufArRhm?= =?us-ascii?Q?hNVTg+pgMFwaR2ZofKcj6eb7gQKXJd0JNUBhy4NH0bwbE4j1bPCbuET5qHHG?= =?us-ascii?Q?+QjioCYfsfn0nyBUwZQXOuXUofHoUm9dSvWGquqIlAD+4yxvAIi+hhrx1opj?= =?us-ascii?Q?Z92wxa1dgAa9q6aEGC5Z0XD5wMy7ReZ93eqFfetig3yCJNzvkF40DHagB7HN?= =?us-ascii?Q?nFdqp4zRsfa41AnVo/n5FThwzGr035rClbw9NkblHs+RqHIVRiLGkbvCOPHm?= =?us-ascii?Q?ccpFotbXvXYI2WqG8bJVBJiplplxiASMjHKpFOAJ4gOV2J4wEfNimHxLL08Y?= =?us-ascii?Q?93bDDSCBmaaDF5giGV7SY3wtV4baIjjnqjjY6EXAowK7B4Sr7V8pQta4B3vc?= =?us-ascii?Q?0uB5TvNJTd3wq8n3iwrs63AeipRfQY8=3D?= X-Exchange-RoutingPolicyChecked: YWdDHAnbrLY89y3Z7cMCXIDlJifFNOiS9FFFph2mhgdKQ8d9rxXjFByYFkEYZP6xbgkt4r4R7xikQk4yAQHv4OvVYzSQ7CdR/UnoQ1aX9ty6MRYHIhiVvG7uXnIV44h9a+oEltl67fUuFWheiDZfH6Yby1Kqx2XoH9XMzlvzxN3m1PDDXkD6Rn4dmWof/xv5YDK0liq3DnUOtGxWzQyLulPQE5ZqliUrqtLS26sV1SIhZxvQIqWhGTCO9ryzWi0SOySYeIqq5aXGMHLsYpNiK/+bb7L4Rg6PY4pW4ye/n1uJb2JVD2v+FWsrIjWuBTr6q5XC5eyQindaG6IMNJZThA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec832800-bb7e-443f-f7dd-08df2dd95ec1 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:13.1905 (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: e0JwntP+S9FOzPoxpidpGuIaEzb+bO9DJ77lQAkQCmWXvSKw7Lw34nMFuBUVy9+YYiY5rnmDlqjP9DRb/NMbQx4Dxhxonw17oTfz7wyWh2A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Authority-Analysis: v=2.4 cv=fqdJ914f c=1 sm=1 tr=0 ts=6ad607b8 cx=c_pps a=OkMMD3sknCYbbSSSOfdz/w==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=lKrOaJ4ZLGcPJhkerdAA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: qlM35gZqRfZt8Djvyj-5dkQoP4DXkuz6 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXwPQQZcUfmwN8 GMsid9qjHnGUcHGd9/tgaCkKP5GQ1FpFWhL0Px3/kJBDMx07EpqdtIM4fPMRa4s3O9DAPa0GiEI XiBcvWsP/1SzOwwRd5w2sF9TBL/q6vM= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX+Zr+YSbwZgMh QR7ywHauQPQgGbHBEx+QwRuzzbJepjEe9r38klRSQWBx3AiyW+/xwXRtBdtZQ8bMCPQ3E/VzKTm OgBxpRyW9FI9hcsbTkUDCA3+SR4llh22Ly3GvetE1V5ZpstqKeDnsA2V+M/tnn+xLs+UToADtWr YvCVjJEWfkAPc73E5S1vd72lyACG667K2A8zHUAHe+KnURi6GlsLk0cycAkHgDfIPwaUMPLekjd U4Attejd+hbewOdanVfNad/9G8c+G5qJslPcjG8v18lppOmvoA4cvQ6mZzs71OgpM2LkLIOd796 k3hkkhRRbzHcESJqvYhiPZ0kuXq29+NOvM2/TFFzuPS3YEgR1cSBafMT5JvnZFyogJP2on0qCRu fJvAF1I7NVLq5sStPUCUxIa2lvoG5s29sXP4SJ2j9v79IAeYKUEmIawlmpDNdKhNwDmTwCwMgbF 9LXUOp/D4G3Hl6yElXw== X-Proofpoint-GUID: qlM35gZqRfZt8Djvyj-5dkQoP4DXkuz6 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1792411581-F687577B-E66B86DB/0/0 X-purgate-type: clean X-purgate-size: 1193 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/intc/i8259.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 4b34e5a649..e5fa0f2e5e 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -447,17 +447,14 @@ 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, - .instance_size = sizeof(I8259State), - .parent = TYPE_I8259_COMMON, - .class_init = i8259_class_init, - .class_size = sizeof(I8259Class), +static const TypeInfo i8259_type_infos[] = { + { + .name = TYPE_I8259, + .instance_size = sizeof(I8259State), + .parent = TYPE_I8259_COMMON, + .class_init = i8259_class_init, + .class_size = sizeof(I8259Class), + }, }; -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 Mon Oct 19 12:06:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454180.1667746 (Exim 4.92) (envelope-from ) id 1xIm8J-0004yF-1N; Mon, 19 Oct 2026 12:06:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454180.1667746; Mon, 19 Oct 2026 12:06: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 1xIm8I-0004y0-Sl; Mon, 19 Oct 2026 12:06:26 +0000 Received: by outflank-mailman (input) for mailman id 1454180; Mon, 19 Oct 2026 12:06:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8G-0004ox-Ry for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8G-009h7S-89 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:24 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607b8-bab6-0a2a0a5309dd-0a2a45078d32-18 for ; Mon, 19 Oct 2026 14:06:24 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607be-b4ea-0a2a45070019-94a397440992-3 for ; Mon, 19 Oct 2026 14:06:23 +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 69J8QSCe3508827; Mon, 19 Oct 2026 05:06:19 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021083.outbound.protection.outlook.com [52.101.52.83]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc4x43qpr-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:18 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:16 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=YBENO+AVPrr9uTUjU0EffDFLvrFbeW1XWzcjaPVFV 10=; b=cU+9bHkgY3GwwRF+VbPi0uo51N/74s6Mcyzc3xax2/gb4NyDl/eWmq6n8 t8eNTzRkMnNA7eVlZEPjKQhZnipWQs2JpMWqdxZojEswhQYhRh9a9rqaJ41i0URR kUOE637Q63/L66tKNY11Hf6LsF0lrmXQnh0LE4y5fofvx6rjRSiBliAuvabPay5e MASaMCP8HUvrEW9B6E21m0+5DkuGjHImN/j1AN/AH4yehy9sR2eYeJH21csoWptO lqz1qIcKcZkTaEk9/WG9ANahAOQl5X0L3T+oy6yzL0wJ2+Y0gVkixSaARoTPZmYf t1R0Jh/ktZ0oTc2HbyHVbYmsikxWw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WNkgQLPzICIJnVOdz391/rjrUI4CtiiTo9IJSF9KMt1Yi0CUVhl4TSob/J3Vq+HS0X6THgZf+sgYnretP20apRldE/Q19iFChHrHy3VH+8kFi38uKSrcg1TWgwvBjuxMT2Gbyyq/KmnUoRQZfX8h7ty8OWB1XJY9ZJWaCtqywMG9ZTkuuiJv6HlXyezPi3QxCpfaTNePUE6ENek5YgGA3NE20KbvqwJtyC77dKvppQ/sbSwUyv4b4J2vICJpzL+Hx3YG/l14PnI0iTjwV8JQhm3OrqSlQwk/SJa0+aDUD0LNVFgDG9IrV0OsJ19PUyQbdg2D0imt94k1EwgU4ZvCTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YBENO+AVPrr9uTUjU0EffDFLvrFbeW1XWzcjaPVFV10=; b=nn5nMRNP5N5ZkizTDPcA4saEyGf79fML1NVU5rQ2pdjH0qH+NwgQ17K/Tns7PMwPumUJ3ZEfT9v9BWCbqOKytabRYt5JvhxafMKdixkQZ/1oDC1AwVgLDyO/H4Sn8zrkE3jzMqB9dGkFvI266bmpP4Ny8ob6Wmq2dfELa9LAqhbyZCnHUHVVpnLrsTH2e354myS3qzRUa4OghJVEx9x4KDaPgkd4u71JLCgf4iJgl3bawUQIuk+XJK/Zns/jUw91MU0yoHe5LDTpE4BZz+qk/zvG4I1v404RCYQrexXRq8cmd5Q3+de4/Qc/MyZHiK7hQQQg8iNFT4rjDqhm/NOppQ== 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=YBENO+AVPrr9uTUjU0EffDFLvrFbeW1XWzcjaPVFV10=; b=EImVt5OVXuAeJVdNyAcMrZpdHxKdAHjrEBAviFNWRwaOoynljPR6DwPon79H0PxLnmp8cZtOdwDAEXHbbUYLYwCi/cPasHRBmbOYmQrlxzTWSNZHuTmU7Yta/OjxxPgisrtjKFdQNUC17CGLSQC5b5bvdmWmZ6iIaSW4NmL9jBK+1YS+YNTptnH8aJLaUZJbcuAHdOTir5wZ6Dji/o2EtkG29oF9QHynACdfAjCBtyPiW4l58gEJRrNpYAiu3j/RvVTIti2isdVLs0F1eOVOHeVyvUUdpq+rkrQukZ/0vAJlWA2lQ3dDHeICl3BviArJRueAy87HwE0cI5L478wLaw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 17/28] kvm/i8259.c: convert to use DEFINE_TYPES() macro Date: Mon, 19 Oct 2026 13:04:49 +0100 Message-ID: <20261019120517.1448687-18-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY1P220CA0026.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: 7e51ba10-eaf1-4e25-5074-08df2dd960a8 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: d80rMGGt3ybKd2pGVHwitUfQYIF2O6T961bTUq0yVLmwtm+JKR7bNAQZWMXtDCvudJ2L+gIfO7MF8JXu/IbzSgXX1JvOX10CXhIi73jAav2IoH0cgzwUE4tRdaCZi1jAYgwIr57Ukf9IEEjufrBbuqRbk4ulmDGPjCbQrz1gnNgy8xUhUtceL5r1M8scOBunz1inHSZDWR4UotHgSudvk7ZCb6apGx74sTfiI7p4XT9J/vfeHW6n9kAWaLzs5fyBOdQwifV6ZEzqnl0YYz8Ivw4Ynfen6y48pSTQyX8yNerFWdTe+VI/Gy9jtidjRM1WFgSqYq6/xqFZJfQU1ns1iQlY1NRnpiSyhk7YJvexUR0K4W1lnGiuL7ayvpMqcnSK0PX6o5X45zTJPWimYY7IQfUShr2GE6YxVdAQVMTRXoKYhYtFFV87v335z99pcO3WA1dA+7olBOhAFZYR6RNwHRV3LoSKb9hl5szoK5QlWEOeujrggj4iswsoe9+AAV585hCtPmMB9VmSF9WLVFdfifpSFgE7nuuhNpvwW0+YXySNvU3P/DvMuIfgTE5BhJwM/uWbXiXG7HPdEXjH0ZRo+cKN8uXpG2JiCNnQRu04oF8658IUULCaOd3ZMmngJ19oF4hypoyfGA9Et3YmootSCbsPthG7KP88vLBqmkjcjWE= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OPVE0T55G/GthBDAdbkHkLJjV0q4GprO9bQYQBXL4ayzqESwc6eHvD5XJoxS?= =?us-ascii?Q?Umk+eAZnEBlThTZbYqrCUolHcJ/gIK2/nZzZVDBrK/95Li0MlzIGEZvaWvxj?= =?us-ascii?Q?cg1ZKDrLhfYmyuqUpNiirq9Lya0NU8r1PeeXG3t5OzpyG+uZsl+3jEHjWqbC?= =?us-ascii?Q?w112bjtg2eJs9r1EpZhJI0MAsDN343S4tqPgRnRsTosFNxQW+0z+S8O1d6m3?= =?us-ascii?Q?IZyqgaq6Bt3CTbiyy9eMCLu3npCgnthAaV8Sz/e10cQzoNpcTLtt5N/00lnz?= =?us-ascii?Q?zHgkIvpNteUNXaL45CxBlxeUHrcSiVMgIdCoUgUmjZJx/P46nAY/xxwkU9wc?= =?us-ascii?Q?Jh8yvUP6vXNOYiMt4uv6LWA8d4UY650qMmKPjgrWlk3EXEvA0S9Aq0S0PMqo?= =?us-ascii?Q?k7VcVf2EJehXKPrC0f5CCWvpzTYQX44qrtdlDWEOFmbA4tJF8dbwA5cYseY4?= =?us-ascii?Q?Mn5BEaOFC2g16DBD7GbpS5luXtkBfT4yw9qBNKcY6TyIzebma/sdR7Gy/7cU?= =?us-ascii?Q?CKJ92ZvSW5ZFbyvlCn6wOaPGEcg9695uu9BGja4ohXUdOjwnmed8LUlIJVC3?= =?us-ascii?Q?EPA6mxhfzSHu2xrbe9cbQ8lp7vP1G1G711/fSowOCB2ULqQ4OSYT4nwJQie4?= =?us-ascii?Q?nYDcdJBwZfvoc3kM0kK0cymQn7/c4QS0gTvtbliS94W5/40BF0qYyDNbMy4F?= =?us-ascii?Q?DcLPjvVXjzqOQi/rsxUI46LlK3R0MzPSBHHrh/QzdBWklIFpVn0OOEAWbHAM?= =?us-ascii?Q?r9kpc0Y+QC+/i/taYuTIu/LQTqZBBthQkglvTI0fuXcASgueXAYMHlgZucc/?= =?us-ascii?Q?HEHpAgECUAjA8z12dGRj43XYO+b4OG7owHGky5g8L6Bfzkv2zqgKmNaOAEQi?= =?us-ascii?Q?9rAiY0iWKBis24rGYvB/5H4sSYgvHZYui6qOc2hlp3F/a0y8shHna1KivlEF?= =?us-ascii?Q?famqXaJvOdGYOWdan7ajTB8cxFwnSsUuawpsjwsJsiqbid+ltCo7B+WlOLP3?= =?us-ascii?Q?HmrZlC3WJSaRuksX5C67AZy+Sf3IipfrzqLJ+p5e2DcojfVpHqa/KwwSdRPg?= =?us-ascii?Q?KneXedOuYVPxo6hmgMyXCB9rkzrEsho0EudR9jsJ61oNMPxiey8eec6/VEX6?= =?us-ascii?Q?9YPr49auqTuoRwkFjAc3UL6OtaUr89/rTPhcd7QY0AenlKkI1TLmAX4wayDK?= =?us-ascii?Q?RKkqLLLxsKu+hiyUhr6sgL7zGbjP/PMXH+3bqk5ZxZmaMxcnGHGiDMfBxqPq?= =?us-ascii?Q?BGFK7nIA5SfMizBg0lpmaFyHAjmOVsFO/3+Loe+SJqZVA5Z/jkhynfHsgL6z?= =?us-ascii?Q?8FFvlzrsfGEW6k3M32fqAwFc7bETYUNiWJF++mh002RGNnYCeotMym5NppZN?= =?us-ascii?Q?8fo6db4zEa9ebATKT2HitQQ6zB0iJ0l6fE3xFHZtnU7yMsiyhgCVLvm+E+2s?= =?us-ascii?Q?CcXc3ytKT/lc5hnseETEzYPC/k8fokxlxY87uvF83Jr59GnXBM9kaljnIHLc?= =?us-ascii?Q?zCVsZGHd79nTKENeuMTmwSuKU5tgo+zZUC4SBLLCkhcP1LA/nNlypMYCKMiY?= =?us-ascii?Q?/61DMZpupUPymPXW0FEWiXE0aW3wRKWRufFBQ6sHaS8LfjQ4KZu685hW/iXD?= =?us-ascii?Q?YCobbjUO2OCZ3yqMc9MuerVWZ66aAz18b8Fs/KHpfW1mrak8DLugHxmOnwoL?= =?us-ascii?Q?zJ8LlAQ4X8XWCudV7U1lLBzaVSLI0dfI86h1BTZwFyd0bH/Y8IxdskEToZQ8?= =?us-ascii?Q?II70NgaPTxMKmEe9n/uQbUomcDe9Ql0=3D?= X-Exchange-RoutingPolicyChecked: vfYI+t2dF3HptCXQ029O9LLZqhT2RibIVRj+FsEsdrRix/Oh283gca0k4DwJxPIuEhI3bsh8+KErBbugPtpBPMt8OE4ZpFVyxDhnGrbwoaNH60Tdff8TuVdNEvS50NWpUj023iuthJ/AkKQdkFkOKa7cCqI6epvAsqGQBzBRhjXBhsZRpAgJK219RKQDjPDnBC93uiz2S2Blx8R2H+SSZPLyvwhGgMuP0h+f2RxQ6bFyKIP0pttzJJdvfFpyEPXxV0Sv08CFquZZpfNWvTzviuB+ormIUDM1F7fC9YFFLxdXqHV0FBj8Jk9fPOG+Ld3HNGXKwY7Kg6bvA9KMgNC4AA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e51ba10-eaf1-4e25-5074-08df2dd960a8 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:16.3497 (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: 5OffBO2pQinvHfeUIwTy7r/BAfcG/b3Pp5WGfEbwxrQeBe/UcD7lyQ79iLuu0dhAPW5neZHgqcySdear+CaeltluNz0/Fpydr+SYB1ur58E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-ORIG-GUID: VxjcBY-mQhR7NocekDvFRnIvdTEhHwHy X-Proofpoint-GUID: VxjcBY-mQhR7NocekDvFRnIvdTEhHwHy X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX5N7a8u0CC4Ub 12zekDNudziF9jGf64U9+7EcHeTN7dYvpHNMiywaYZgfPBXzeCScoeJ7hxz+G/tlRrbVFmY0cyE xivPLnX3rwNZnVsYM2MaLsJCeNl/Xco= X-Authority-Analysis: v=2.4 cv=DqHDa2/+ c=1 sm=1 tr=0 ts=6ad607ba cx=c_pps a=X+j8kQviiGxwf3Sz5eWiEw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=CQnoaSmAlUSJywai4vEA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX/Bao0tWbSQ6W 8emJhJfP2/4wAcgFcdOauBlCrHSodkuJnCfag5oKBiZBOY7OhC9cBP6zxwZu47X7dlt2U89jTr3 Xnz22KUtZGxF6vWxrAPz+YorfkvRpOT4HUAKEhy9uNaC64H4uWHscPktbAbDxNRiBxY5L68m+yg IsSdFbdqlDNaP0TM50UnqiSvDVPT9iwJ+OQy276ZAHC8KQ0mmOmOmquFpNmMhwajtEWJlulxVpl nwt/f5IoMHGPstLSSgxPGeGazBfF2ZvnsM/mpUQznsIm66o7gtOczK+g2NP1fGK2WzSOOzii7Fz 6jxbckoJ3aomU2zu+MFbJsFlqlhvQQyYzDnUQ7VS/jvNkzLmt+LOAA53E63TWc3dCrSbwcN+fre /RaRE1clh6MMQkDysUi5fvIUzfPzuKs6h4AreJY04G1nnE4iUKylsqH5f651YBsUVXWwLFoQ0ud W8JoUhl+54Z2PFAk6SA== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1792411584-36EDEAE4-78DDE724/0/0 X-purgate-type: clean X-purgate-size: 1232 Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- hw/i386/kvm/i8259.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 952f58be11..9ee23b5695 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -154,17 +154,14 @@ 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, - .instance_size = sizeof(KVMI8259State), - .class_init = kvm_i8259_class_init, - .class_size = sizeof(KVMI8259Class), +static const TypeInfo kvm_i8259_type_infos[] = { + { + .name = TYPE_KVM_I8259, + .parent = TYPE_I8259_COMMON, + .instance_size = sizeof(KVMI8259State), + .class_init = kvm_i8259_class_init, + .class_size = sizeof(KVMI8259Class), + }, }; -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 Mon Oct 19 12:06:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454183.1667756 (Exim 4.92) (envelope-from ) id 1xIm8K-0005F6-LQ; Mon, 19 Oct 2026 12:06:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454183.1667756; Mon, 19 Oct 2026 12: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 1xIm8K-0005Er-Fb; Mon, 19 Oct 2026 12:06:28 +0000 Received: by outflank-mailman (input) for mailman id 1454183; Mon, 19 Oct 2026 12:06:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8I-0004xm-Un for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8I-009h7S-B4 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:26 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607bb-bab6-0a2a0a5309dd-0a2a450392f8-16 for ; Mon, 19 Oct 2026 14:06:26 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607c1-fae8-0a2a45030019-94a39b0c0dbc-3 for ; Mon, 19 Oct 2026 14:06:26 +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 69J8Ouhl3282357; Mon, 19 Oct 2026 05:06:21 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021075.outbound.protection.outlook.com [52.101.52.75]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc74ekjfc-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:21 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:19 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=vZDjPjvAeuhaiIHbETR1s+dP4jG+860Y1G05PguIu kA=; b=U/F+OK+VS+9RrVXtW/yKT1GpKRS5H4/vabjezLObYo9rsjrHeHSaUlzo8 sRO2ePdA/tIsAWnc3cnktNxODdJ6J8mJhvftOs/wc2yTAaNo8MMdE0tgbqpULYHs ktwrLkSVPDWldtx9Gtc5sUVR2d5Yc6dKthFV7aX/PsPYZvcxRu1UFOdWfit+tBkk kVE0XW/FrS5rDOYf9vmzl2fqINwaYG1eTg34yQ6TMbMFWWzNHDmdzih/JYGfz0ug qmeaQvWSVle6SQn9jvB+ZHgQv8ovD3Rz2BTQLhdnHrCiNCNMiGe1UNe+LLQvoupu auNGMSNL85kO4+ssombshpDNS3fJg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nVM7tdqPfNu1pmRReCH3It6gbGz8d1xlZx+dvMBqFNHPEkD/rrFE2tsOYdu7Nd/8GmQmvrFWqA/PioWWmtT3f73YkvWCFzksCia+vLnWBRpTZKr4CL5hmJUK2HXRKt1BDCWqAXPBsF23SRSJC92z7rTyXTKp0s0Ih6h6CSgILbwTXlmvwNo9qm+Vs5tzws87N0SbUJ/Uz5b5MJkTcAheNbMlZaxL94KixromJ09ITVrPplBhJgO3+Q2ZAImroMDqy8m7msNmgkT2DJwUHv5zsxt21O99sVjjcrq0il66NK8CSeXH1n6HGaBIQSo/x3VquEDS/73N8W1gaq49kjuyLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vZDjPjvAeuhaiIHbETR1s+dP4jG+860Y1G05PguIukA=; b=SyCp20Wd7WY6r09OAxs4XTzajzEUN3BGen44mn1D9R9RlP/0NPCnbqiDFKiJqC/8BWGB4esvq6kRcaDRGa6N5YRYs/ddkTuhIKYT3kIYHaq6yfUbovcMejxNCOXyQxCHq9aRNvXvxDf2MlRrWwvqIovEmMYPJByX0KZjJ1OJGARSjm3MfKm3oX5TalW70mAbCy/z7TidHyn5Y1CjdI8tGvGbLjsBgkpkOxBclnVnV61Vf0BThDf1RKifNPTi672pVcUmh19BinttYea+TAa88sa4BHRLC/jtiWnVq03qGNs+Qlia1CCezpT9G5PJcUfD/5Dei/lV8G+sBZusWhCE2Q== 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=vZDjPjvAeuhaiIHbETR1s+dP4jG+860Y1G05PguIukA=; b=NmOzPORV1yIXjQgXlgSOAGCvkFmmeCcW14CuUAEsOzQGemJGKT7SQwV8nmDhKHKLGPjYHMu5bGl3PUvAl6Pv1ZqK6bDHm0ZNawyr/NGYKpXhbY+DVE6M/WMj3rMdaaqpyWFt/9FixHa0pspEvlV+P0d4NuBfrn4LtPIrFh96IPyHWezhX5UhIfjyzf8Ahsp9I3BQIIPCI/wbggvUGCoDDVavvxCHGYW9U1k4fGZSjfCJpl5txeoqY+dPA31tUJX54pNZ1xBlVyTq9egTB6+Z21ISFjuA++clFmsXW7zubik33tdFQPwi9kIcomlTh1HQCR00AMFC13GsKnzN1Ox4ag== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 18/28] isa-bus.c: introduce isa_realize() function Date: Mon, 19 Oct 2026 13:04:50 +0100 Message-ID: <20261019120517.1448687-19-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR04CA0017.namprd04.prod.outlook.com (2603:10b6:a03:217::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: af66f567-2a32-489c-933d-08df2dd96270 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|10067099003|18002099003|22082099003|10063799003; X-Microsoft-Antispam-Message-Info: s+8D1IFV5TV/TLdN4BilfhH04mgcy+F8wITtLToLTWAnAcHT+neBxxFv6isuwopPcYzqwHs69WlcvLzJJRkrn8V4VT5jLzPc21QJxKsbe8N/Xr2GWUsUA/VgdKC5MZJ+wLHtnedI2S8LnMpwomqBj9r4VfkyHYfZU/LLQP90EpRF9lzzp3vkH1RmSHlsRIJVVGUDgQ8Mvyc6AckqfrsyH+GjtGQwlWnEetQ8qqQIYt3ISkTiYJWGx4bHHXWW3nLw6wmvd6Ac6yjFi8Zw2LFw/rVvs5SmHK4K/ynW7RBlwApJC3x2oIgonTouAdxkpe/+NxwptZz5hWoq02AmrlhE5U5ykqXU2vH1K4FOK4Gg1/9H97vLppJTtbZZKzGYXqR0Aetrtfzg9+0FkzG8tbe3kQyz34Ono1AZRKRUTf5VMLy3NAEIrz4FTljyuWgAR2Wm6DlIJiqiidfyLKSLz4v9owN9QqrsRF9jMyu1ZKnMsQSRhTAD6E6ZjlbEVk/L5/CONNF/DfSG4LwX0McbdEP36MteS39tQDn7uwT0rWyRe8x2MoJ4hswoB8+fEyrXwjeWRhitPbp2/rPharNbQX7kWq2E9i6tESVE0rAxjMiwbX/EwzE8WXYr1jm05rHDb5xKCfmiddYWAYzaSSqWJO3GrWxh+tdKdI+c38wiEaM4J8M= 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)(1800799024)(376014)(23010399003)(56012099006)(10067099003)(18002099003)(22082099003)(10063799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?idhpI24EUjQEHwPKSWoS+8se1CCaqvSmavQeWSDXvcwAqRRQILbDGDJNwTfs?= =?us-ascii?Q?VMMU4DLx7KwOOgibR37HpXcQndL8NgWW2JhRo6/Fl3xzgI4DuCzzKXsnRjUY?= =?us-ascii?Q?Jrv4BW6R1Rv8tUtt/E80JozHgn1m6yMN7e9+EaAHtzgU1gY7YGGoLEGuSz4D?= =?us-ascii?Q?nB9JTYAPHAVw+gCRKQbMoM8E0c/mG4efXUDF8gxErN+9LdC6m8P0eOFqx3YT?= =?us-ascii?Q?IU84jsZpuj7kL4nGtT3XiRauIqytbuJSTdC8VLc3mN7YV+v5EYVX0bQAZpxu?= =?us-ascii?Q?iHZeQOBw9MQ8t9S+/Pn2JDWs/2pYpRBcb0zIUD27BuvShyI5HbDXW9eW1HQW?= =?us-ascii?Q?dWPpRv1Wxi+vRqJHLc1gUbtB9QGgjpkhfATPiyv48XTGm2EUERNwnCtToYeQ?= =?us-ascii?Q?O7EDVvyazYV/2zePVQCchAtHOkG5EyZogpdVppPG1Ci8KYj32Y9Pd86kp9l+?= =?us-ascii?Q?zJcmAlFfUHwfahqt/89CR1xpqf51e3rApG2Kt+CG7iqtNALydUY5vJdnHfME?= =?us-ascii?Q?FGqCEKfdACsPgULMjUYaPF1BnaC7VgxPCdV7FCMzztiUtmWzL1SDDJCtl5pQ?= =?us-ascii?Q?eVsew5W+qVAJIlUArthxXMJACHznv5gI5ehaSYJx/4kJ030wZu1N1vbhomvh?= =?us-ascii?Q?o3uZkYjdb9zHphQBz/tgdOM+lihrAQK1B83dr1PXTKnKg9mGsRypAk1LbTkN?= =?us-ascii?Q?zA9O4WseHo4I6mAhWM/yNKdbO3V/YnD0t73R5xUeSkQRQPgTnBAZo8MBpgg+?= =?us-ascii?Q?lsQ35NS6KCQUQ4YayHECdqPy4dgIjRRBCT8tBLhiTTUhQb5K+7rFJ1C4Srjw?= =?us-ascii?Q?Lqk4PeiT1MBM4KF/fq2GRFSLNgrWGVVepLQ62Z2ZSpmjI1zeHGnmVKpostzI?= =?us-ascii?Q?op3wZ8ZYfuoqlnyH+oWDxlvrSOOIcEr5Wd2MZ7GObGyTTDRvbUBu0198E3Zv?= =?us-ascii?Q?LxlBEDJRvQQxswvXi12xv1WSt7y2WDrKazvAXIh82BZxxw5ws8DFuK1LzEB5?= =?us-ascii?Q?V3Ti7dwzst7DRxdcRwAQJ9hp7knowWfxZ9CvWNST4nLzXcJcMY993eg6p9mN?= =?us-ascii?Q?z7Rw6oed0FfyfwPK+qD9FolIwO8AmK/QVj5cxP6lgyTcQwCfZ/ci1g2qptr3?= =?us-ascii?Q?1azTwN4tqJBw+HiV+UTb33QR5OiU/ceEP1u6FOqWPvKmJZQ6QUD9U3WhP+y1?= =?us-ascii?Q?bkVUqw/4NUZoBl2Fz4BP8AcPvPOQT+WUmA5HURzfg+EqxcZlURW9ISAkZTao?= =?us-ascii?Q?uvvOuRSUn48HIeWuDb0bUHSpbqaAMn+hwxIvwTH4m6jp1Y0cGweM3DKsqAmn?= =?us-ascii?Q?vapML4RiyZ85Q2eXnUPEnJOMXGXH0IdsuMgbfXPQ4eGm7Q8gEDEVhUnrtJIB?= =?us-ascii?Q?UPvdrMki0ac9e0coLgsknnZZ9wgCI+iYZMQyBpoghWg1lVY/5/IgaYLLvHgQ?= =?us-ascii?Q?8VGOjG+xKcKwH4Y3ZReSWj+ozo2ji2L0m74aLTtw2GzIH9gBC3XWnpSOGSlP?= =?us-ascii?Q?4usrZZXs8Z3+7ubCJz8qVi9KhNNDOs1zQV6Y/mQeRhDD6gGqeL6koB44eZWx?= =?us-ascii?Q?l1/u0rhmTeY9zE85TJJV5GQSOU1om0WPCu/iSJwJqOSXuBD1dph6/Ah5CO47?= =?us-ascii?Q?u37XSTa0vuyG8XpeEQ3shz8WI35SxFEzdoBPKSakMBp/MVQIFV2P85C/9NI0?= =?us-ascii?Q?gORT0gIvs3/5hbcYOgzndZ5H1qs0hj9/gF1BwmazMzc7ocCc2Je3i2kYIm8J?= =?us-ascii?Q?58gl0c37C0AZo3Qw2NLjiMP+mL6QZhE=3D?= X-Exchange-RoutingPolicyChecked: VZjceDUODmABJreCh7haIR/J6QyiSxJlMJBaxhCCTZkPtHwIGMGSSgJQEbT90MHYCTndX4nOIkBBGuFQaYScwOqDTmBZ5tgEyyPcizw3ABspfzT2q5e6tTDbmhDFAGGseO3rcDNxfpOVDID6YfmkMWAgWnMI6tlFUWykaYp0py2t/cDwHjDi/5EE0KmulV2mlvRYgLWjlDPQB8OzGHBgthQBVhTFg71/TJv3Baj188TwqjL7k8OzCFr6N83CJrOnIIN6QqpqkYlhssOjsljvNpufxiaynL2NpNa96XX67B0M0rNQT7Pv74/Q8yaTDX8/F7IK8dzC41oySOWRe7U6ZQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: af66f567-2a32-489c-933d-08df2dd96270 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:19.3262 (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: EVcuKOYI3JMhaElhyO54MLI2I0xzvcgiOWAMqOcCQqD4X+9EAwYRWGKwAp9ilaWiIxuUX8CwYr8mh1llfuJ9sKbd+Qn4oT5aiToG0Ejie/Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-ORIG-GUID: ruPj8cio3ZtN4r86KudUZ4k8QiuVp5YS X-Authority-Analysis: v=2.4 cv=HYGB3SE8 c=1 sm=1 tr=0 ts=6ad607bd cx=c_pps a=+Ua/q5Qdf9RbITHm97vdGw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=E42jAAAtX2bsQao6xnwA:9 X-Proofpoint-GUID: ruPj8cio3ZtN4r86KudUZ4k8QiuVp5YS X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX09ajS1fHTcIE Sg3yDl9jyw8/0crTTuH1JxBIl2hJG3AAmSAahoP3jf9dBWWbQjHpZdc43mtwW9nG1J5zDRHTLii fjlFSwA/8pE8K65mEELuQtRNc4XOw24= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX5PW+LQClQFyI cJRP25Z2EDP5Ga4Y6Uef5s2pRWdw8TbvFXxADMiSzxRFzU21BqXOsDOCSis6LEwHBl8hx+yPcXB aRZq8TMbSpwQg9QSC5iYtsuqaepliQTfLZGFnO0qkSwCdRkmm+tP+RpgnwIolJNNIxX/gk0WLSG myb8pfzLDtU1eB+/MCEWkiVE6iHM9h0rrcKkBiUfm0pZTcyaAoATBpxFs0vdXozZzJqtrWR9vwP ErBSi9OlgcYZPHVRmQqWpH4rwuA1He4jK+HT9ovgmNH7GNXLqDx4nclmTZ5/YMyc9VpFtRwxgeR jyv77DEVfq71nkFncCzZYZMyiK51gO48xmHE+ZWMabkhqfzObjrxnVwHD4Ymn0aQxdlv9K1qPmb wdHXpK3dCoz0SzjzQRXsDVkXlglg2lck16tKYhr2zB2jrP9GJ/msASYQphE9QET2rki04egG6pn CTb/1xh6Bk/4zkGCOIA== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-33051d/1792411586-77AF14E9-B199C533/0/0 X-purgate-type: clean X-purgate-size: 1426 This is required for implementing a container device containing one or more ISA devices to ensure that the refcount is handled correctly. Signed-off-by: Mark Cave-Ayland --- include/hw/isa/isa.h | 1 + hw/isa/isa-bus.c | 5 +++++ 2 files changed, 6 insertions(+) diff --git a/include/hw/isa/isa.h b/include/hw/isa/isa.h index 94bff33fcc..a3d54110fd 100644 --- a/include/hw/isa/isa.h +++ b/include/hw/isa/isa.h @@ -82,6 +82,7 @@ IsaDma *isa_bus_get_dma(ISABus *bus, int nchan); qemu_irq isa_bus_get_irq(ISABus *bus, unsigned irqnum); ISADevice *isa_new(const char *name); ISADevice *isa_try_new(const char *name); +bool isa_realize(ISADevice *dev, ISABus *bus, Error **errp); bool isa_realize_and_unref(ISADevice *dev, ISABus *bus, Error **errp); ISADevice *isa_create_simple(ISABus *bus, const char *name); diff --git a/hw/isa/isa-bus.c b/hw/isa/isa-bus.c index 7e6d2ce5a9..102f4a0e0d 100644 --- a/hw/isa/isa-bus.c +++ b/hw/isa/isa-bus.c @@ -172,6 +172,11 @@ ISADevice *isa_create_simple(ISABus *bus, const char *name) return dev; } +bool isa_realize(ISADevice *dev, ISABus *bus, Error **errp) +{ + return qdev_realize(&dev->parent_obj, &bus->parent_obj, errp); +} + bool isa_realize_and_unref(ISADevice *dev, ISABus *bus, Error **errp) { return qdev_realize_and_unref(&dev->parent_obj, &bus->parent_obj, errp); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:06:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454188.1667764 (Exim 4.92) (envelope-from ) id 1xIm8M-0005f9-Uf; Mon, 19 Oct 2026 12:06:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454188.1667764; Mon, 19 Oct 2026 12:06: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 1xIm8M-0005es-Q1; Mon, 19 Oct 2026 12:06:30 +0000 Received: by outflank-mailman (input) for mailman id 1454188; Mon, 19 Oct 2026 12:06:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8L-0005Wh-PZ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8L-009hCP-5j for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:29 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607b8-bab6-0a2a0a5309dd-0a2a45078d32-28 for ; Mon, 19 Oct 2026 14:06:29 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607c3-b4ea-0a2a45070019-94a39b0c701e-3 for ; Mon, 19 Oct 2026 14:06:28 +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 69J8OqF81634767; Mon, 19 Oct 2026 05:06:25 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021101.outbound.protection.outlook.com [52.101.52.101]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8bckgb7-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:24 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:23 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=PnqtO96A9vYIZxbUx2QdtGXp0O4R5cO7m2kz08fWd Z8=; b=Vrujwd/vQl1EMumpl/HDswL+rUVPEV82c/yFbKbO/j4S64HDOK5rbXSHB W7DZlTOxuXvfZzrzlKMKaMeFwYMA7JZ1BgIkip2VED9VyH1aOZUJOjVsGcwnFoM2 LFreQVKDcr4a8VMFyU9L/UJhi/BZ8fcURbLrtdQC0rL4QJP2O/htUCe9IPFi721n ixC1+xxYbghlQtfLeUiRP5rx8vyRPYcT3i86PCabd8xl0lWnILycamJb/3TzQkVF LnLIhfwmHQv6petXXTSQtCc9EQwr0myR9/S5VBXf2iuUcygA05fvCwYto+BiPjsd N+dQb53Lp6NuOrO16w1AjWpEBNAUQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ob6Ks8mvE4h+Wk71W0UHvTkIfn2uFV5s0VgAwxH/RPpQUU0hxNqsU3EDh60vA61368iQyzmq3Mpz/9WM/VmaeJWVj0MyMPf8BwcpDdLjZP6f0ePyZVS0T6EVT65AfwN2exVIqjextcKm5rUhlQYXLhQXfZJ3kSvi/eWDvmjwwYoKLi4fuYzcx4WKHM96BlpzjbF+4wG/9NaXN6x8NW9iq73IH79XGMs9YXd+oELbrbzfSA95rgx6c1TKdnGGg70hx+Bm/Sz3qDhL4W2vdos3CFhaqt+qVInCsAW9ao+yYMjt5nTOkifHIqsIx/Hb41b1qGkVbSmp8t5TybE2x01jBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PnqtO96A9vYIZxbUx2QdtGXp0O4R5cO7m2kz08fWdZ8=; b=IkqZMo89dKA6MAhd/EPIjLPJuGDBuSQMugBTOxkORru4eUzugWz15P2K11X3yyxkN6AH9Bb5QZImJLPn17t7RcOkPGWO4RJ1P/tD3UN3W3qaumSKMJfreGDF+l6VWyEi0P+BZaAajEmjVfMts+lijqmSke6SCxahvhn0zmqnypjxq2s/c9eG1armpedjBeQfFPUTzcjEYiOnYkGaW7cITyYVtQuvI8FNR7b2jpFTvS1+FsBtPF84Z6KnNCibjeq/ab7eledAMnkp+6bXL7QyJvBGWIEvsP3IVsIR9ChIOTXvsv1Umk2RH6QRSFB7o7uOMEaKvJcVgl7vkROBs8NL3Q== 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=PnqtO96A9vYIZxbUx2QdtGXp0O4R5cO7m2kz08fWdZ8=; b=TBf/XUfArf69zV5vIIphaoFqQvpL+uM/f+29q21DkCo7OtU0l9LnI6XBaNS8DXR+A7r1Z8qi2BX35Hj5R8FtRDImY+pIQ5yQN2H2J7f4Fkq0Datrh2Pyv6BxBLvO/4SpEqZEDWoebv8m9mTTFoXbMHBOBbAqTQ1rtgI5lbGTWnG1v1VCFgNFmy1vvtNKWrCi9+/aUQTMPgrszEvJdIhBrYzCYCGyhOI5NQIODhECvwi8FPL9K1sSOwE4vnPKzMLYrg3LGGbmeFzv3YoxapRmbbgGl+rO8gIK3+FMI4pJx/F/SeBfQcHWEs3qsmpkHvhNh41H3WOpJKyrTnpq/6/mTQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 19/28] i8259.c: introduce TYPE_I8259_PIC device Date: Mon, 19 Oct 2026 13:04:51 +0100 Message-ID: <20261019120517.1448687-20-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR04CA0001.namprd04.prod.outlook.com (2603:10b6:a03:217::6) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: 2a628b17-e706-4a9f-b2b4-08df2dd96474 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 7ogPhNT0QqcZW21xLpnTLe3tvz0S/fIEw52he+O1GgYKJFpovlMVEvvrBrivZikRNvktnl6QaGTpR/+qudjYiOXmf/UPBF0M3dd496uI4yFX7kUejo/ncOz9xdWHMg1oGMR8qmEsqwHKvnqRP3GU+BQsIKa2SEZl7UCj6gQG/xLWIIsxQbvvIjeMFKXc5Wg6XZibnpAwb3XHhlq8psf0AuyFSeO4NrOjh9e0MIHxr8L54Vu5wGnVHt9Szp3WZ/spYNfcWPCreHzEULS/z8lFpe5s2H6k0E9xTGWVNXeNkCgxy64ucfZdARXxM+avgczP+nTTj1qgwWMjTw/XPD0xn7ziDwsbDl0qG69OULTOmOlS5KKJjLFL5muJcckFsa+tLvKtIfQa0lgoTnFZC1TRyWVJPcx3f6JmmnIWAdmyI/qlTaMFOI1U0jNyDTK7PUuql0OKIVqDaWWXV1QKrA929Sn5841KTQp44rJ5Kw9eiHJ6TAM7UKKbTZWNEy58Q7980sIys5I/jd8D4ybN/KSXDQ6E+8Lze7uZZ1PCZboMOD/nO3vW/d36yl8/8YYmsFvvqLLJIsj29CH2kUPMxGlqP63iXRZT9DrpPEiFT1VC7UY4rh6XYTwg5QKZ903h6pmlUzou6STSAMzZ58aUfBv7t0pq5EUKZRWkEgJNZosui78= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ewAcqArovDFtY6ZtLNv0SoVny7QcS1JjL0O6e0/qX5+3o7LkE3T2m8ECAese?= =?us-ascii?Q?rqZbVusp0KngbBuWhH+dfWxwYctVTBNOo1CwOba/RIPAf6nIbVT7/OJSjcYo?= =?us-ascii?Q?oUf6vRmr6ZKY0qT8xin+0XzUUVmvoG2hMKLMH9+oURmvy8hBECPkUfth8kwL?= =?us-ascii?Q?4+dMeaefMfZu7g72UUzqmng/fHpaAvU0BHv+Wg4a5IFLY2l90NTRV6VRm+LQ?= =?us-ascii?Q?dxdFrlHgRvtIUM0wurhBtA3kB3cTzSsEWN5EuP9uXbFzDUiq5ykUTm6ief+I?= =?us-ascii?Q?wB4wnrlslf44a9gHe6Ku3YyHvfhNfuKk98aIIb8GUQKT7uODe+jHkD714CNd?= =?us-ascii?Q?PIhOEmUtvsY8JmZxeO4ok442aE3cwSvcCvmHYJRFEjDjsKGDos1rc0mmJmCo?= =?us-ascii?Q?wY1wwPYMnOcTEUdrcDMy8+lCMzGHQXyZuO9dVIJ7qxOk7/AfU3A+TOQx92wq?= =?us-ascii?Q?km/cUGEjlhK/p9RW7kQ6sYTwpnJsyXXTvEzFraM9wm0yT1xZMou0zoaRcbOD?= =?us-ascii?Q?BJ4ENPe9/6zTTWjUHmBsbm9XLaVkeIvjkhWI7Y1s5scbA3BBPlHEERGxMjnn?= =?us-ascii?Q?dz72ZPU7mFyJ9EEZpik7E7BTZKh9vGzxs7GnubOQmcm5EjktGDTdot4KSp7D?= =?us-ascii?Q?TCGjx1mmqBaUTVpqU25oalKsQmGyjlACrEWrWnxIyFBWqdfm5M2Xret2bAm5?= =?us-ascii?Q?dQwqW/vGPhiBj8LFMIFmeg+pa3jxgF9sFJrpc12gyCiKVl4wF9TIzOR0mPif?= =?us-ascii?Q?lKHio/atXx611H9b2s3LhUWpDd/8IpEgyI8r8UllfT82qoBBzTGqD57YkZxv?= =?us-ascii?Q?uQVRWhTXsdTbpbe92xHo90T4rS7LBOXxJw8BogwCMDcDxUUqZ4aIjzjWzuuY?= =?us-ascii?Q?Dd232yDfzbJqMnszv2BL9kYGAeppV+RMxkg1WgeL4gTPMan+HKSMZ6IIlcM9?= =?us-ascii?Q?R/ohwBGi4wKQb4A1qlFnCPlGsEEIyPmZ6WrPSGrc6PWskhNwsUWS2z5lh5PD?= =?us-ascii?Q?x8WBEbwsEk7rTYUNRSrwBt6DeZLBbPy3nVBwyLYrjWQBipkyaC1ge+1dWcr5?= =?us-ascii?Q?lm+GAjC7nsH5IpzaMJe9eWLzUsoFapNFokemxNR21L+ScqVa53kmiDEoRoWn?= =?us-ascii?Q?mXmX8QMGpwybX8bDjXHU48MIO1y6RtDx7mTFIqTQeLKYC6+X7tBl7MMmh9Vw?= =?us-ascii?Q?zdP5+Ppn/0vZnrh7n7ZWukyt2xTnf5h4JDkO5D3Ym4ieGjqFGv0kgJ+4MHXG?= =?us-ascii?Q?LjjfOZJ0PwyvdLPxSR4QAX1dg+orIA52re3dKtM+LDqlcYkV8331/k1IVzAL?= =?us-ascii?Q?lT2ZC54/zH2pEKypijcZbwoRywz6LmtSkRYYoMFH8Ju4B51UOuneYBSkMeUW?= =?us-ascii?Q?GdCVmZ55a5DDUtckXuSkGijLstWWxNeXoHB3sAzEJstriRjSZXr6vUv4egVm?= =?us-ascii?Q?DhgeqAFpda1E0XNPwG3kwc4cXtFWEBlL+s8MDtjMJqd5AjcAftBk7wCcPZj4?= =?us-ascii?Q?81Uggjyl33E0k0OH0C0XPLtkrrFDMZF2i1U1LwipLVvLaqCesHCJsGjzDwta?= =?us-ascii?Q?xq+jXYiGKXzx8scd0nE2y77TDAM5/kcyap2+/mom/YQ37cDwjdR4AbRg11uC?= =?us-ascii?Q?8o5kbUpC+ERa1Z24bQ8kDaazQrBW57yNpDc2OJr71+V1tmp1RwgCS/7YZy99?= =?us-ascii?Q?76v8GlQO25NwZqtkWWGD55hTG8S+RQPSWyNS1BW/7tVL/o1Jm74aMURxSJs1?= =?us-ascii?Q?79psT9oILjPrQw9nLDj+dEVmwJTBZsI=3D?= X-Exchange-RoutingPolicyChecked: eW/0aws4iyAoOaxTHlaVJCMeXtKaOhLi12cA+HTgifsRmdd76H1rc4Fmhwi7yaYux4hySs0+KUvEk5XwPCEH4Hd/z8BInlZr/VYUSeDPTqPYqMieQuX7FeRX30tLEGoyyIaIDGdhwoI90NtEnIBDZuMaiqz/OxDNtMGK1zL1qfLF/tZiMSJ64evBxTRy688s7J4jlsTV0TQ6ecJg5+wFIQiCMdufhlo2pcpkOyWk8BhP9WQ+1H+UPb4W5Ij+Ou4JEgpWwEI6Ebr0S1sXQXoTGmnhRldMIUsB3CrICJbt0vPGjeoRSJDRB0nFqSp/MkT1YS3nYm72N5CIthOW2X5oMg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a628b17-e706-4a9f-b2b4-08df2dd96474 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:22.8969 (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: qfWXiv9nneuSltgrweCnWhhx5r8xpYe4O8dbxGeynNdTtNphTx0ZCRL5NCmPEYN/YG2IUmdG1i6pD2G2l6vT3T5jvlHx7Ux1AVk4RsTDxA0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX79uJ7V3Q9vnK QHN51xjTKm3anOGzTTogGrXyOTNr0TPr5EJHRed2DAvnuaFp0NfoWXthhQsHTJMuVNFnnBWBYzG RRfxZaV/L08ViXga7OcKL6b0eP1qUsk= X-Proofpoint-GUID: CyIYS5U_ySI0bavRSdkHZYVHZEAXeOhe X-Authority-Analysis: v=2.4 cv=V8joQuni c=1 sm=1 tr=0 ts=6ad607c0 cx=c_pps a=3cYuoP5kWG2k1oDcrssWdQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=0XGB6JmbSUb4YdcodAIA:9 X-Proofpoint-ORIG-GUID: CyIYS5U_ySI0bavRSdkHZYVHZEAXeOhe X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXwK9brB+mcXBd YdUKBZ9oUtDRJ/dReeGnzxK1NpacdvVnE6VXqJTudm77xA0g2Fcb5VnVMVAsF9Xyw5RMMLernH2 AmbCZSa3PrSzxgRK7X9B/7Ef9yZfGc4+cq+sX0OldXM9iJH9KvVM2grNSHTN7oqBPLCJuXAWjjf VEzMz8FDj1yUcZB8hJXuSOEqdm80sExlifQtFSDqBFfkhYeP8MHMrSmSh9AI9siRIHuqPSAzcYT DJYsIxtNFffdItX+dAsfjQ6FiA3RpFsRfp69pIRyVTALM57T4JTpa9mv4okYqyAeB3wWHGcF4Xv Ihm42qE8/QVpctm5q5Gp3tn8eb86s18ToZDJxwqyl7ootXIeR936i+Rs1KzDrc+tZ1tj9ESvyox Z0gMJvhWsmGGnSCYz5FxR8fAxEfTm2m4LKmgeCTmlDzyBptNWy8t7rtn4YMbijpLfBWy9MyT6BJ Swm9sUFwnYDRt72x66g== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1792411589-350CDAE4-E94C1284/0/0 X-purgate-type: clean X-purgate-size: 5658 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 e5fa0f2e5e..fe524efbce 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" @@ -51,6 +53,22 @@ struct I8259Class { DeviceRealize parent_realize; }; +#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; + I8259State i8259[2]; +}; + +OBJECT_DECLARE_SIMPLE_TYPE(I8259PICState, I8259_PIC) + + #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif @@ -410,30 +428,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(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(pic_obj); + pic_obj = object_resolve_path_component(OBJECT(dev), "secondary"); + slave_pic = I8259_COMMON(pic_obj); return irq_set; } @@ -447,6 +459,90 @@ 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(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(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, @@ -455,6 +551,13 @@ static const TypeInfo i8259_type_infos[] = { .class_init = i8259_class_init, .class_size = sizeof(I8259Class), }, + { + .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 Mon Oct 19 12:06:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454197.1667773 (Exim 4.92) (envelope-from ) id 1xIm8U-0006Sl-9S; Mon, 19 Oct 2026 12:06:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454197.1667773; Mon, 19 Oct 2026 12: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 1xIm8U-0006Se-6U; Mon, 19 Oct 2026 12:06:38 +0000 Received: by outflank-mailman (input) for mailman id 1454197; Mon, 19 Oct 2026 12:06:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8S-0006Dj-Kt for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8S-00EE38-12 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:36 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607ba-e002-0a2a0a5209dd-0a2a45099bac-36 for ; Mon, 19 Oct 2026 14:06:35 +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 6ad607ca-be1a-0a2a45090019-94a39744a198-3 for ; Mon, 19 Oct 2026 14:06:35 +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 69J8QMp03460266; Mon, 19 Oct 2026 05:06:29 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021116.outbound.protection.outlook.com [52.101.52.116]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8jwkfvj-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:28 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:26 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=uIP/FNzxgTNq6IxC5pZ5ECWrlTbe9ctn/rT0opm86 Ng=; b=LspzrnUpjMMURQNmDOfRrZ5GbNFT4r5l3yk796eWl7E1KYn8I5xVcFOSz GfMPSzYDxolEi+P2+LdLn9beg9MeQrQx5FB4MVTsNRK87fJQWYpJWyiuxlWN05/Y kxlHLiTfKsWxoO4ynkuDNOzNl4dHqJuWDYQGL8tw0WGoumUBzMpC/IRXiDcVs3sq WW/P5OU9henMh6aaX6WQbhMQU29WwkcEjmHDigVzsXRxkC06GfWU1nTLtjm2Z27d evyntFg5kjw8efQRKgzSTaHd6dTRvyogvQjEOQclGYD8YjpqfHIgf6qnViCGQ5tN Eb0Flk6IsT8DpmxokW677YfftjVpw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tl1Cbbeh14uyKMREhbaZrlHjD1ZeRtKG38T/D63+6y5jI+eGDxrYsnQOGKu6CtYnWREPU48y2k3PYto5btxUx2CjU5Gkn7A7LMfIjUX38zZTK0r/YywUl1e4Q0dW7Cl9aPYd7clIyRnuHNxLP31SU8FDv0QY0kWJIyqm+cFBV5d6jLSQq4sUPnm5XEos+5NC80u3WZ6j/biEx8Yo50jFuFPXpR0ZphQGgLZduZUbtt7QepNcGvLR5SLX1s9H2HWEqKLJpWizBJ+bvIjoa+3ppsvydqr49Bp3f82korSfax1HJAPQ25qq+YaAtRwJvQQjf+4rQfyT3Xb9yohSWZwvzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uIP/FNzxgTNq6IxC5pZ5ECWrlTbe9ctn/rT0opm86Ng=; b=WXqxq7Pa/TnQugITwhFcSlYnzr10SaT2pLhTtJel3bjRV7zX4M17czWIJqcJ7rjdpjv8NpSbxmC3KnYGgFhWfIhMiQBFSzH4/GF6UL/ENTnbB2vVZjrtX5OxtJaUXOd2/7FkVEBGBQmSxn/hmJVofDmK+VooCDL0iKHX02+XkK7sop8P6PhAUH2zXepWv3r0Av6qryZePEX56vGeeXZ+IzWopH7T1f5KaGMqk49GALQ8tKgN6h5oc2KmU6cRatgiSUTVoyeZkV8I76nxl0cRcWMBBBotwPUUTHxg7Ou6oxX1iYpJPcTSbLrMscDhvgB9+azjJbdwcGC+Y8/J6qrlyw== 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=uIP/FNzxgTNq6IxC5pZ5ECWrlTbe9ctn/rT0opm86Ng=; b=A6anItIMk5HDevlYxhvuiZ3TXb0RZbA/QdB7cq+gRGlxymUElbJGD9R8mG282+gT3C5CdnL1GDemK6oVVSKQfR/iMgGOhTsb5Q3PYKEs9Pn0m/A1sPU+ZgW3MXF7I0mUKZApc9yyq+ZjwB7FlcgMB2b7jSXCMtFs+B9GQf69r595a+Tph+Kj3UKUgH4pxshYfo8eN+NTRgOI+A+RGgpSVZFUmRWmRPhkd6eBitdz5Zt3tL1HZR22OaohmAVxi5lfFN2NXzyxq3nxycul85n97yXfOzv2F5JRqCWkidKwOjQqixujJSU3YNQBa3uYx3Ti/55M2mWOOakzR8h+iG8TDA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 20/28] i8259.c: properly cascade secondary i8259 from primary i8259 Date: Mon, 19 Oct 2026 13:04:52 +0100 Message-ID: <20261019120517.1448687-21-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0130.namprd03.prod.outlook.com (2603:10b6:a03:33c::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: d294ac6e-dd68-4da1-c520-08df2dd96658 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|10067099003|18002099003|22082099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: pklBNMQbuYEuZELq9c27A/kzklyb/0vC6PWPxZjj3Z2yrJsqPbGccT+dOuHZrSrzpzpnMd8KSO3P8XkyHZI2HfR7bfMuqSxoSTOQLsNScSSS4ZSMC2TunWgvdaYkWY7taFimiI+9Cn/Vji7d6v32tAUFq4ZD1599S0Rl68J9QrrDYXuaiTp4VxmUDVgEEdh2qbTXOoaEi0Xt0PhSgakaO+sx9MVEQl+Ym7SoHL0jdgipVvGzsP3kPaOoVTrK2jLUPfLpjS/F1YPvIDOKV0WvxGOM3b/tnamgh/yumqam5UXd+a8dxCta8YMeUz71FxaOE7bHDqqR9BDJ1YNgC/1d9gKQUVdqRr2WzD3YQID/YKPafd7y//sAnUF9cK9fucl6BGEhYtGfNkFBgQSPWKNjJZ9zTbEdM+XJx73kXTFPmhON6kvIIRP8Yt8ST8w/N52buvtrtBq5UM/Qi0UBbyvQJX3BF4rYcwZBUtNp3F/fs/ssty36GV27cN6T7Sf08LfJJOpsKZGWeNxuVVQvJIxT1TsOLtzteXcVi8pz7gFCVDb84cPMc3K9UevI9jujp0wg9ITpo0BhY82ADceYRxHsxFfjmAidX5SH9w/EWnCKuA523CeR5UHKhLHsTxcvXoXpOdT3uqfEAGfR29BqamE/O1lwLUhpCF9ECMfiwg6vheE= 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)(1800799024)(376014)(23010399003)(56012099006)(10067099003)(18002099003)(22082099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/mUlG1BDMeUci3klfg+24kUPBOQEI+F6Gk2sgJMGoRc4xu22jEzLLthsO6i6?= =?us-ascii?Q?eUlHEMpFwO9BvQMu1q+gK2lu4m5KXBj+A219d/cahtfQSIhMIwWvBu+nJARo?= =?us-ascii?Q?aVzhKQ3zQ9LdMDN9f3TWras9Rn1w8qOmKOitFHDEjn0yUucK7wgSaQHbAB/N?= =?us-ascii?Q?x4Ygl6hlnSJK6V/pPnC68607BipEzCWFxaZVYX/Ks7HfcMycrVHee+j7m1VG?= =?us-ascii?Q?jfbT2reNC0iULkZOrxnQuXQFQ4HOmMEjLYYMdQb6wCp8MOkEjfP9BmGVEq6C?= =?us-ascii?Q?DO86uldeOgmtMwkuKyAZI9jciEcauc9p9h+8QS4FKMs+n/K1VcgL7BBSm3Mc?= =?us-ascii?Q?+91+95UbAlYQtRMyJSpH6v+qVlDsbNhmAHWd3GMMHL3zjIZXylDTKve/SwlQ?= =?us-ascii?Q?ZNYJX0X2kMG4mjnQv2vrhF16Scr18AnhTMQoOmHAgt0yEAuWPoR+keoXsqt1?= =?us-ascii?Q?eLvcBus17C/mWtmcaQks46yu+kESNp4uteKmggshsSSAMF42CFP9jMPe1s6o?= =?us-ascii?Q?3aBV4B/X3glQFp7R7x49UG7dFS3OacbxtoC6cJ0AWMyugSikvH3IMgxCSPlc?= =?us-ascii?Q?GhSKuWK0EHMIFrNYuHJ4GoND/qVlVr1j7datzM7kzRIpfc6TxOiWYNSog9SJ?= =?us-ascii?Q?f8nRcfx1E54PNUxrMAtG6nPWij3yQf6GalnLAZ46TX2woLyto1//vM9Q3BPh?= =?us-ascii?Q?OxxTHU4JT93do7mVr6i9VYSBXGeu1k6SpzALzj6X0Gs0NWpHV3ehxQGqRR80?= =?us-ascii?Q?mBR8rkM+BIM/FKe71fG/ElTfa5WfsndE4G83uRLQ2QUP/XERAtktMfignP6+?= =?us-ascii?Q?auztXffxssYJF8UjEIdzkKuubKZn9Phz4Jr/2x4HiyAh5gFIBiKBEpgZF9OB?= =?us-ascii?Q?aJaKSUtg75E1ljwlJGulGQrDlM3AKNkC9uZFYmIttn0BtUs2hLjcsrLNDuXI?= =?us-ascii?Q?SZmbxGGonm/HpY4BRbsMGDkOf2ISFCrKAouT0dub28ZfNe3GiIK6G5wN1GA2?= =?us-ascii?Q?0GvbB/RNgT7HcTS4ELQJx1WbzdupbBKKL24klaDxl+qkyW1VTErayrls38AD?= =?us-ascii?Q?1yqQJrfkGtOGxQWptuGzuImPAAbjb8VDfcMGUwvfeuUFGB6a/OtLYun7eHVj?= =?us-ascii?Q?ZA2mP+qlFo2gXyyDnzEg7rIHrymRmRHrmssHWSU25U9099aEJEj/ln1rPeAS?= =?us-ascii?Q?A9qrQ6qlwr7oJK5Ll/KpsmYhm2p1I8Gm7Rvwx2+iDhGMBB18pyVZT7dKlDTX?= =?us-ascii?Q?H7ykj+bfbextZAdjO5H4lcP/V6FIbrShZu44MqIctW+RtgrLpHtan3QnWO6U?= =?us-ascii?Q?0xeCLD5smZuOnuZUAeqo+6+Olelm19uy+a2BOWUZfXPDSCWgmxRffirZWw47?= =?us-ascii?Q?gxrOs2UFZfmWKTljKXTciiHxgiBm4xci+67z/w+tEV/rsajOimHJ6A9bZ51r?= =?us-ascii?Q?v49MMQquCi4Aq8lRMfDeJSwvVvnJEYGGuV083d38jRvAb+/MmnSZZrCHG3Er?= =?us-ascii?Q?XRym0vkIldjL20Ropi4Ui4bv3gmS+OEZ4l2goFpM896W5DkUZ3N7TBSqB/8P?= =?us-ascii?Q?51y3bE1QBqye85Tr6EH7i+np+VKIFQ7Lh/TVJ4wgCe0lOyaD78/RqGxBTlEZ?= =?us-ascii?Q?2gsnT6f52VqT467A54GZzXWW827HnkFn7s6Yw+qal2cPhcGw0/Ob8qMiUL6+?= =?us-ascii?Q?2P4I2l0WnsDvuZ2GVjcbjZAuQEg4dHj51IIRHpPTwfy8mGgBBLBj/gHjTwUP?= =?us-ascii?Q?pg0QtJ/fN1G5hKzZWtsjiAemnm+Byjc=3D?= X-Exchange-RoutingPolicyChecked: 3GXP/QreMAWLBtBxQdmBjsYsiS9perNZa16ShBMgwQyGLLLtSF0r5Lv3LlcjZl8Hcb6LtVDwgmtZdgckQwXhrhDMfkzKFa3W9w4iv3z+f5eZKw1CX4oaqwhzbS/TOyDhGmhJq2/ooU4VfocFY1VPr4gDvGunXXbWU8TeP5MSvvj5V4uVJ3Mo3FafaOKZYh2oyh4pj0siz7MYWr59Z/mLIWJFK5vZ31pRO85cTlHODz2QjxpRVQ1ZwfaFGN+cQZSASo3zPkfXNjruK14JFhfnXiaT7uO3BnsTDThUVxlQmHPnUJLgyv6g1/cIB50nsCIWSMoCasWltJV6blUi8QCzag== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d294ac6e-dd68-4da1-c520-08df2dd96658 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:25.9657 (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: 9ZmfOJ+lzW6t4JBGTyj/Ko4y8bEj4u3hb2TeDmGFKQBfak+CAjbtygKnED5dZveyKiZ1GKAcE627PqaFwvrbhewMREXCW+tBKgM3YvtOR/E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Authority-Analysis: v=2.4 cv=OecNnRTY c=1 sm=1 tr=0 ts=6ad607c4 cx=c_pps a=LbO2ZyHrMbRaCxC771SosA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=1L6crL_YRTbalZ11mEUO:22 a=64Cc0HZtAAAA:8 a=9VHIr0pmzsvXQOZnOXcA:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXzltTkQNNJp2F 0ry5lpk4hE8rxWb7ImfI2h/BMV95b6BzpIjHO4guqdGtmaLp0WgTYqNApFPISZg9J5KvFbMhkgh AV1/TW2iIe8ZuYvDRYW/fzgPIcdoHS1UqzxijsHlRVpVBT2iwYif/2RkRIQ0AQIoVg9dAh8mFLu /eye3IbTWNCwEXVq4u/BSO+vuEgD6o93GaZQLM4zuEEwonujleTrpw1PT/L70y+RDFG4Ei0Wpk3 7L0R6G3z4F/xhrXQgHh7QY9+DkDy+QgfUJFZxjsGZcawCuJJROiBSlYm0YHgFFi/L36jhtb2Uq4 GXlyUmgXzhySa8jcUsfKhhmAB5/p6F2SvaRfVwYObxodIPfkpvXjFKUrdGhIPbZubKBeAqBnDcp RXjcHQib9DhU+QhxqzXafMASANN5tXOu3hgS6bNK8+fecxOhD3DdbRth16W8OmVcsIQ2V4lFjjc QnhhmhO5dNs96h0qB2A== X-Proofpoint-ORIG-GUID: SHKQp29evYl9ERj-kV3SakwNthvdkp5_ X-Proofpoint-GUID: SHKQp29evYl9ERj-kV3SakwNthvdkp5_ X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX2COTy/uK+vVe 8yhyNh1p6k4GjQWC6i3OwrfGILO4mKEnuCEBPYPmoWsPOFYeyCFIoD84Lv1A/dsdDVAojl/VL+4 n6y5JDDDc83ut+Mz+JHRjT+aWAj84g4= 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-bad1c0/1792411595-BD0CD034-23172771/0/0 X-purgate-type: clean X-purgate-size: 1369 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. This is a bug fix since in a cascaded configuration on real hardware it is possible (although unlikely) that the cascaded input from the secondary i8259 can be masked on the primary i8259. Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index fe524efbce..d713795ae0 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -504,6 +504,11 @@ static void i8259_pic_realize(DeviceState *dev, Error **errp) } for (i = 0; i < 8; i++) { + /* Cascaded input is not usable */ + if (i == 2) { + continue; + } + s->pass_irqs[i] = qdev_get_gpio_in(pri_dev, i); } @@ -519,7 +524,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 Mon Oct 19 12:06:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454199.1667782 (Exim 4.92) (envelope-from ) id 1xIm8W-0006n5-Iw; Mon, 19 Oct 2026 12:06:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454199.1667782; Mon, 19 Oct 2026 12: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 1xIm8W-0006mk-FK; Mon, 19 Oct 2026 12:06:40 +0000 Received: by outflank-mailman (input) for mailman id 1454199; Mon, 19 Oct 2026 12:06:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8U-0006V8-KT for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8U-009hFu-0h for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:38 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607c6-bab6-0a2a0a5309dd-0a2a4501b394-32 for ; Mon, 19 Oct 2026 14:06:37 +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 6ad607cc-5984-0a2a45010019-94a397443c16-3 for ; Mon, 19 Oct 2026 14:06:37 +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 69J8QPJk3199051; Mon, 19 Oct 2026 05:06:31 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021079.outbound.protection.outlook.com [52.101.52.79]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc83euh1a-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:30 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:29 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=ojnPbeqBzxvW8ef/Ffu9RV9uInJCYb6lWSzAf8/lS tQ=; b=XWbdxJnVRkIOGAFQCUohzwz+x0+WRz2utVV9zBDkT/Kwz0PBCDxvUss1X VNSBKveilwCjupNRgMZFWLi2L5BVp93+kAPEnzbqpDxXFMKLArULTaZKBJOS08Lf cjK7Uq5+gtgn4qLQ+6N7EXiSiCa9JpXvUNdkcyzK2rnmYQiW1Vd/J7LsF3xYt0wh Gp74bYhnLjc52eiuRhhzz5ItAYRWMJGikz27RS8UYTkclML1oNJXsPEVkpMdfXRA bHfEQ7JVGanYBVQzCpMij6vKhrZpo1ViWg4eYlsT+MW0e0YfVy1HiCeAK/F74hvC d9hWJLHpPOYccwvLvUbxJlmWSPnyg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L0DpSua5ECADkZhvp4RpVLkmgzxrbYCk3Xnt/tv4qhBV7hIPUVUgRGyDGRSauBRGKX4eRvSrcI+7nh0KmHdeVFp3vbREiaYwACc2zUVOBVolJNlwMs/M3kpNrqwZKqL9LMRcfWoCZf3zpT7ehRx7mJmQOizPC7go3gNVynyOrQ+4cGzWQ6m4vQuUnwwSes4QiNChobpjMnf8thYhQR4Pqvh7SsALFlCJXiQHkfNXY2yFM+f1sqzctlX2hP+XhSrq11rVG55eN4rMlXUkCA9QcXHx5RNYL516askFU85xXDkX29Y2kMJitfhP5CVS0Z3Sa0C6JfSMShCtXGhLOOwBzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ojnPbeqBzxvW8ef/Ffu9RV9uInJCYb6lWSzAf8/lStQ=; b=YXSvj32dnqP+WNboOTyoQbIK4yG+qSOubrh5asw5rttPk4hysMgNIXmh6WOddh9DvhkYHZhQSFF5809yrFG8g+kl9NP0KEySUPOUlOny5Wxfh2QRkWp37IPhiIkz9kISqH8nz/MwuKhCbRuptFKgxOdSg1uLxWz3CxIOHKTTnMEIhJ5ZQAb3HhY+ELRZ13nDc+5j3tlo242YEA7JLcpen2/BAcGotfKG9aCNSo/Gtw5l9yu5ZOOWaJTZELEOVSDRQkxfeQ/ao1abolCOq8GtuaFDROdkUT2JJS8IJFMrSU61UDp6u0ytz4peXi1ztU1QaSS+9FjHXamU0lIcsGNmBA== 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=ojnPbeqBzxvW8ef/Ffu9RV9uInJCYb6lWSzAf8/lStQ=; b=N8NR5thR3X1JR78q1kcK/ZRThP5DX/mGMjrOWsTgHfKncrrMqYw9e2FJf8QyXMbwhDJSz7db6KL6emMLCk1yILJLGTNJUa2E4OencXobWFXLpEs35IAbK2Ii8MFlkoXBNDU9nbcS/eiiUInKq9Zr6ap/sxkluUUB+qTQ1s0BVYASdH/Twp33CD2DC02HvAaJ8DkkPkAvvxjGSAru+BQA7rEfIWzzHWJ8TIYhSqbcBn7WJ5hAE63Z93JM9a2AT7/2SNNPDlv8+VHhgXcQcSeAfBDBhEeUnAyHBcy4QOpuXugnSqSD5XMlfFAywLyCziqwaheNJ/wVRLm8A2EFkaHt9Q== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 21/28] kvm/i8259.c: introduce TYPE_KVM_I8259_PIC device Date: Mon, 19 Oct 2026 13:04:53 +0100 Message-ID: <20261019120517.1448687-22-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0100.namprd05.prod.outlook.com (2603:10b6:a03:334::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: ff895f13-58d4-476a-d1ee-08df2dd9683d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: WWDhQ7ShZaaFydn6u+fxG0L8DKicMcc6ae07vYJu9nXbyoOWSY+Y9T1TKhyjCHL51YIPXe3JmIwFuQgrtanaMx272n/52z8zphGip6jS0hGVl8Cq+n4YP5OUuU+kYzQCPstnn/jg1loo1unMJjC/Ux+KgPS3ZfNd4lhLlzPT2L7OyvMSreVUxFd/qBY6HcFqujRNHpwELleWpUMrTSXTWeeQ2qN89D6Ww3HILL1aRCk96004oly7ZjmGy6/ZZxGvXodGQ4sUp+gFB5/SVzaWG3fflQeDVTsMxMRxPNFHlZl3hCeBhq9KIrh3YYXtmmwGKVfX5000ntWDyDXFyHJ+uJ3SVlxCoZkauM9NxtRqGsd9+BqqpK5XP4frgsdf2LEjnEkxnQ2o0pD/vvzwsTP1SstF7+Y0HItmiTHlujsdiPEfaNTV14RyT4CNjVBiJLjeuNKYaK8LCtDZ7aYFm2s/Mrphq1LK6hb87P8sbhrtFTgXq9ZVXVgBIClGrOiQcw5F6ux/45nhyqcFhIf7CTfQ5h0SzON1uH5yUKb64jrRRR8aYP/Z8tDwKb/+3cAqtgBs+LLcDPqOQsgt8fnIzhfozQw6UsJb+Cd9++ApAHB2+M6j/nc0oXxLFVyc2Qk3lCuOoUyC2dgiorGTH7bOFMn7GjynsQqCsvAhkcqW8ZGnSYw= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RwE4X86iDgMsmzpXt2KJuqbtbllaa68Zo2ynDu5q5yle6hDtqLtMEqRhuS+t?= =?us-ascii?Q?e/XigAYriqN/6Rf8N7iIELgYASKqbAtGCFQyQjkaqCEAS+1qJRME1Q8SN1F2?= =?us-ascii?Q?v4hZ4KLB3edNW4Ff9C9hsg79BB1BaVZT8IHZ1w1Xmo7zs+MZNdpLhDIhnlUA?= =?us-ascii?Q?3uFhJozfL5yToGDg/VCAW2bRepOr3xUHbR0C1oBzc7v3qi8GlVepD6dcEyJJ?= =?us-ascii?Q?Ohrxwk53Ui5+8djTLxEkBjnSqsicglFV0SdKj2KAMCFF2MlQK/Vb/WPusW4B?= =?us-ascii?Q?LJ5yETLNV1IAVLKd+xM0JOqM6Je0oPnCWYVYyugjjcQWCHFX8on4uUwuykfQ?= =?us-ascii?Q?XPcA6B3fAKgBo5m8IJEmJ3WTGHwuSwqQuv132e/a8x76U9uzvK8L1WR/vyo3?= =?us-ascii?Q?QvNgvoL5PBUGVrQiJsn/FxsAK28AveLX0UVkHlueNIOPasP3WnI0wu8A+AJK?= =?us-ascii?Q?FB3gMXSUUf/LSbe0Tq0buj5Si/uDP3UwsklwttfzhjwXQBfQDZ6Q+qI4ggK/?= =?us-ascii?Q?KHxLliDVs1ZZaZglokpCTT0umD1ZoMiRaszki9kFsPmrOrY4zGGdcmqlifzZ?= =?us-ascii?Q?D8x6RDZSkrxxEdSP3gJzXjP/dqrBIWyjsMSAjPJNsX+GCF/ZEHS6vgt5EYTn?= =?us-ascii?Q?5UExutUPjf4PZB/Nw9QhJtYqw2wKMNwvyBxrs+KKTb9AhD6wm2ixAIHT4JfX?= =?us-ascii?Q?OalKYATdJh7qzoWV0sq8yeX8YaftJ1dSp8nTyfRIExGxB9Nyrh6EeicqJrE+?= =?us-ascii?Q?3cPVBGnLJ2FqQdx7R2jR9BoL/UMq1y0xSpW+VTeG+FFnHkcgTMGweOHWY8ta?= =?us-ascii?Q?Sx/gDBorNXI+lT6v8Vo77YudxSfxv6V1UgDLsl5BXBUh8wF10HWxVlHFn79W?= =?us-ascii?Q?uc4BsaWP2Drz/wz4l143IQtw/YkpdQoG8hjJ7CltDCbaz61sHUIyrxBVw9Xc?= =?us-ascii?Q?0StaQstiwX90/YnRRVQQryEI6tHgEVmr8bRXev38YwZ0S+KrChhSTGwIlm8D?= =?us-ascii?Q?F8qJYVo+5wl7WeN6l5A7n7Ery+KAL4wqWPsZhrCzCmO0ud2bgG02gttPUyom?= =?us-ascii?Q?ibuhHPz1YVO0QNAtw98ZkGz8wulyYWzhg2NkLo4GX+kgBytFpvkRwZqdiS3E?= =?us-ascii?Q?3UqxTaY+uIEKeDbodpMwZR2J6rTsBYmDOFxPNFnQ/fYUNULQh36Qoc2JL2jt?= =?us-ascii?Q?HXRzHNlVRx8jk3A2ma5eDf9lmrJCbfuXYnywa05OmXDfU/NKFeX2nBEWbOhp?= =?us-ascii?Q?b1f1jNHFOyZVg219IXqefWpSUHHv7xuYG8zV1JSZ+Buh3dkkrGH4q0L4bLSd?= =?us-ascii?Q?LSrk/HhmNaufmk3CRpZSNLx/V9FYiROZQlOpxcSD3sl+llbv4GV4YvRnNbaU?= =?us-ascii?Q?6l79lr5Kd8U2u2ELhOAXso/zaOeBvV6U5sElxe7ZLNtUqwGx3+q34A0+uguR?= =?us-ascii?Q?6VqzmwbHc4HNt2VGZKEEJ3PG/wwtO3/KUK/7ucZjY+ix7y+lLfBscdGVaV84?= =?us-ascii?Q?a9xeDDDQtEUN+p+YSQkLfebcOAQm2Ktf1Jta+mQmNEFOaCFAHs27YdAJxb01?= =?us-ascii?Q?S5HYp9mS6vr4ERhZ0k0br0VSAmaA8trO9Q4RiWkRpTKxVjFRvxjN1xfAUEmW?= =?us-ascii?Q?EHICNxDWNZEUGM8EOAgdY4rpDLBIe3KGQK21c06RR/janvPBe0Hvntx8RacH?= =?us-ascii?Q?mKFWpjgftIWL5MFY+1v5SkmGtLR3OWNRHq5DZdnKnSCdnqU4rVc2JbxyrTLM?= =?us-ascii?Q?AGJG7G7o9QHx/q/ZjkayRjoubZjgPsk=3D?= X-Exchange-RoutingPolicyChecked: 3cWlCkv5//vFoQjJnT31JCaW94trqfUYE94VtTroJnXhUL6Tv/gJOFdkjMgSz6IemKpWPcLzOdXFaViXtIFPex0nWOaWPuKwNDJbaCPU6iV2tGMzteFyCz2Du0pEYWytW7+v5zjEJ5/ymhMywqNascfutDVMRorcFXq9K9UsK3oLdshESz/3HQzYpBuyv0fjGksrmfH6cEHVOVHfzpHfwrdcNhcFrVHPg7INZHLuBpuSy29VcNVixMQXuuG/+7FdUrfXXYwybaUMEIxy0Ug+Op1HqvDfl/8yRlVXOk51srQNMncVZU+9VDt8YXPguVmJ/Z4Blg6sXUWpRp5FUlUJ3Q== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff895f13-58d4-476a-d1ee-08df2dd9683d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:29.2293 (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: 5YcF1HpIR5brjz6WMvFRJRiMeii+eaX4i8QpqDkL45QRYgW+0EkyQgOGQzHVM7dpsB2fJyA1MERV8dDC6GZIOTkWmDebZ1l5TnMwerGvq3I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX9UTjCZ9vKc6g Dru6FQVztUmvwsl1ToZOPAieCbeW9YQN3PMNd5H22Y3EfaZ/7qS90onowXs88YCJ1wMjbTefujD jVlg/6eIM1AcNYlCHRqG+nuLddGullizrDYBcBzuQaWWqIEPXgF8xstXOIRZKksYg2LATgvwnUs nY0xidq3uqvFFM72iBNzjjq8N8+L1mtthQbffbO8f1b1/RUtQix9NhQYd10FrRAoEjmrhKbw2Gi b1I6ayOA98PitZ/M1i0eVEpPF6EKzJvv9lIi6YcKQkO9inXAA1RpPgjPD4X1NQKisvRad33KR7t AE9czdWDE5PJqderMFdFOZc6eRp9YtAdvMzoFNSjgSLkHIleyBoy9FAH1gs9tprg4eB+6Sa1Ze2 dMhXOvAH4ENOEtuizhcpNxWNYtrtBIP+1RRHj2Tuz9RVLxSwWVvGzE6oD7KM6x2NjrBmpiXPB47 9Fe51qbP+UHckR2s7sg== X-Proofpoint-ORIG-GUID: 3BYfKqASBupiI0H_2GLgE--YuR5qKaTf X-Authority-Analysis: v=2.4 cv=RI8mjIi+ c=1 sm=1 tr=0 ts=6ad607c7 cx=c_pps a=Lzux+ftsp8NJ2nFuhgYiNA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=CV9Lyex1vB-al1NDbmIA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXxwB8YHKWs2mn 31V/BFKsE/b6ViPyHIceq4W1Js49PCwSMH8pUYqaUmN2gd01rCZk9p/FXc6Wmyky59kCBZ7VSVy ocT/5vVwwOwM2GbIw30UtwV7nK/uZ/Y= X-Proofpoint-GUID: 3BYfKqASBupiI0H_2GLgE--YuR5qKaTf 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1792411597-BFA6E757-65C29822/0/0 X-purgate-type: clean X-purgate-size: 4302 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 9ee23b5695..48282db58e 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -16,7 +16,9 @@ #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" @@ -36,6 +38,18 @@ struct KVMI8259Class { DeviceRealize parent_realize; }; +#define TYPE_KVM_I8259_PIC "kvm-i8259-pic" + +struct KVMI8259PICState { + DeviceState parent_obj; + + ISABus *isabus; + KVMI8259State i8259[2]; +}; + +OBJECT_DECLARE_SIMPLE_TYPE(KVMI8259PICState, KVM_I8259_PIC) + + static void kvm_i8259_get(I8259CommonState *cs) { struct kvm_irqchip chip; @@ -135,10 +149,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) @@ -154,6 +179,59 @@ 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(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(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, @@ -162,6 +240,13 @@ static const TypeInfo kvm_i8259_type_infos[] = { .class_init = kvm_i8259_class_init, .class_size = sizeof(KVMI8259Class), }, + { + .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 Mon Oct 19 12:06:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454201.1667791 (Exim 4.92) (envelope-from ) id 1xIm8Y-0007BD-6d; Mon, 19 Oct 2026 12:06:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454201.1667791; Mon, 19 Oct 2026 12:06:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8Y-0007B1-1Z; Mon, 19 Oct 2026 12:06:42 +0000 Received: by outflank-mailman (input) for mailman id 1454201; Mon, 19 Oct 2026 12:06:40 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8W-0006nH-PJ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8W-00EE6C-5P for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:40 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607bf-e002-0a2a0a5209dd-0a2a450ba14e-40 for ; Mon, 19 Oct 2026 14:06:40 +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 6ad607ce-b7e8-0a2a450b0019-94a39744b234-3 for ; Mon, 19 Oct 2026 14:06:39 +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 69J8QSxt3508824; Mon, 19 Oct 2026 05:06:35 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021112.outbound.protection.outlook.com [40.107.208.112]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc4x43qqh-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:35 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:32 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=aSoQnzPVPKCptsUfYQKIegr73fefTWafbQ2RSswwh KA=; b=VK68Y9oM/NpGpHfhaAP1Iqc3P87/lhY6UOghVZeOOXx5cRHLsJpX/xBdk JBUANJd6p5OfOWPl7vqjX8v9lUo+vz2e9yjrCcqtJT+BlJxTyJC04aAJl/JoBeOp qxSNsfRY93go8/mWECc9fwVvEoM2/y9NY4zApGvlh8mTx7PzSgtI3zwwbyRYxCpy w0YhB08kd0k1VwyOs2qzKIYdGLMl8DdrBGkEnRhGBUEbjRmiwRvpkcLVaaTNfOZC dTiU+nSFkwQTaMRw+fdv9BnYpa9eNu9xxObIHTJ8eUybxNtuxisiN53JMBYcBycy 5sI2eOkEv/2pgHE8RLWaZCrHDbB9g== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L6nx04cexwgcPhULTSsawVbo/t9r7qR6GuCv1lEFdxBu4hA+2ctqWetoaukJYo0s83QBFl8wf7d46x7XZInRQgneZD9SMxw4YyXp8V+hsHHfGhqSdHA8a+FmeIeCy89gxti8+wBAJGS82k2+eZDrBmdiCfQVDs+x/R/w7b5NxlUdsTyPpGlc37sVULTQDUjWjT5dpbJWpLkWFYzgpjYGnzvg4vWkybj9fCRlGyC533vstqZmVXAqqepbj4YBaW7wB8YQ6EFiUUXdrcvnukpDc8FDDGOJ0E0tEhJVtUA0IuJugPfOoTt9fF725EXyG30ROyn2TFD7rXJwOiNpaBfSIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aSoQnzPVPKCptsUfYQKIegr73fefTWafbQ2RSswwhKA=; b=I4vhN8moj9wzuYqvcu5SQ1etTTMIo+MZBQq+1wF8hG6vZXxFasHZ+8pSJJYGfOngKxkYp4ojzmaZ3GBPMcgmWqjBpYZI1oswFMhsBy85cSKmMjeGcGAaVhdccKaQkev7VHAh+Mvmq4Mwo+yiG4R7+3A0rRstl0l238+sr+76/4EgevHbQnTLr5ZPgEEGPWtwHFt5C5jiVjyduf0ughzJaHqDWDU1kmzA7rDWcdGgPMxak25Y4fOh6MgH21sQQS8v+sQTqcyA8PhyviBWe8mB/98e6IBawo+5IjfqMapAaS0FjQlE3iuc9jzKmi1XVcHCI/XTomQ2dtGlu0fq+QhswQ== 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=aSoQnzPVPKCptsUfYQKIegr73fefTWafbQ2RSswwhKA=; b=PLdkFuc+LxWzdM2OVJm7tuvaNjVFzWcVceLIINxo+4uLeVE3ltZUqbHqVIyb/4w6w+Kz+RdVzl529asHIb7b2CItcqjrKGBXGma+A8Ma70zCaVxssBcjdDtsDT2Ozp5fk/5K/chQp1tyScbco4EQ/QSXIhGGwaWy83VPUKjf+NMlFMrvB38N3RTO+2EjlKVOJ0Y7usT1OOWjY0YG3ALBYB5uf+uwkQD4ACSrBiuuwvP62dIIYRFedHJwg2KsJTkbZPSbUsRS1uUT7v3591GvfrTEISlkU/I4/JgfmOjEXGf7j/y1XuB73ndeOtifrmxMrdhn7cejBbvGr13acPcEjQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 22/28] xen-hvm.c: rename xen_interrupt_controller_init() to xen_i8259_init() Date: Mon, 19 Oct 2026 13:04:54 +0100 Message-ID: <20261019120517.1448687-23-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0192.namprd05.prod.outlook.com (2603:10b6:a03:330::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: d13180f8-6229-467f-86bd-08df2dd96a2d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 2xHenfZFJXFV6Tj3130LQ9b8nJZ4yRuDDWUJnAHPja1gzBzpCvoB2whdGzN7u+dm0NWzXm4wJ6o60d47GnLzt8ffyiG3j9cWSE8uIjmPoOpAAcJ/pZa/c/2xBowG9yvxiBrHak0sbLSugWt9bn2F/qLQr+1FN0LPqVuaN7cUDWWwJKtbG5YZE5Be8SDZLVQQjPUW4C+k3RvoEejh8MXglRghoXnEz0bBzUGGJqPCtTrBGHgtigFv9agpRr2z/umeL9r7R9FBsEHdCfq/KsKdO+I1xETSPyFSAn/pk4goXSL3A30N7+HufmqCmTs5L3Ti73YQiseO1IgWkeQBIIvUja2J7Fj88Xs63sMfYp70ALthal3ejM4mqv9p/IW0lC5+kQk4eQtQbwcIn7B4Zys586VF4MQa+6nEtAwAwrORSW8EMeaL8hBNmNSMq9zWqt6KYjDcxvES1XjiWrbb2+off3KN4lGOpDllTFEzqMq8MQgzxByb/DYuyAlea7y18mBye/bAjneMn8S4fHAps4Xaw+UTtDDPzxBwRbRKUvG+EHjUWmza7i7fehLss+Qly7U1863Emp9KE9VzXbiti7GTl1XkDXcdoqCCYAHPidhO4TJuXCsTOIYoP4llPKEZp2/EELMDtcPAR/PbrIlkLE1aPR7URq86DP75Q6RFMEOdBNU= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2mVvgeEhxrZQJBg2RFXKtRROj4cG//vCg03GYhAKvjhUqJZAo8dOL6Jv2vCH?= =?us-ascii?Q?EB5yOxVzEaKP7VMETzAV8Cnhkjalj9IaojnAeAOrP9iQYKTmC9C52EhVq3Ft?= =?us-ascii?Q?HD5ckpJKJgZkT7Wd2l/JNPvt30t0EiX4fTfaE0Ny1YsPE7g9qpAT6/ypaZqs?= =?us-ascii?Q?lp3dgLbK/8kqxBCo1PqZuTRcFNiDqHSXfOimOYU/mOk6aqw2voU1Km/iO/R6?= =?us-ascii?Q?yf7HifT4AZ/s4gf27OQX3F8hM+t9d7zuE5F18ehjABG2abP+ymX6xS96Cmaa?= =?us-ascii?Q?LoCbhw8VK8LUmJAgAZITjUS1FK6VWX6wyngMA3k+ywbegVEhvj+er2YHPshs?= =?us-ascii?Q?JnDdsYBxYknuB2JRkOlUhzpEVPJ/MU3A0Z4M4YwosrqBWp/I/mm2HLA9QcSd?= =?us-ascii?Q?0TJsDKrTGgLrbU9HyXXuuTwPs2KjYh37G7K+d23VVQGaxOemIw0kciqguEkx?= =?us-ascii?Q?N9MPwh5SsOEi9Wvq88+FreSZjh5x44wlZRR1gfXkRBSGNz6UONKw5ZHTOfH1?= =?us-ascii?Q?y31spXJOi/0yrqOiXS7WzhkKA4brXxzxFcXsBpcZMqDZTtSWZSIWrpNn6dC6?= =?us-ascii?Q?rVFL+OvFUy4jqmgJEJJ//4K1FUBaobl4/p4OugkCbwdXATDQht/GL9lVC+bv?= =?us-ascii?Q?Pd0HU8yLWM+WCtEryYX/xySBa4itVGECTBjkW793OAkKQ6HS4EyNNIL4DL0y?= =?us-ascii?Q?YcpcT6y58p1noiWCKofDcAjKq1e8Du9cG4v27KbQ1Awz6EBTRh0pj7+igBg9?= =?us-ascii?Q?MJyd9OGut2McLQjnQI9t7UxQ0h5gdbwGkdvV9JPY+reMmhWmCta2RZv1w3Su?= =?us-ascii?Q?6UpXbC6bl9JSGCpyj4T74PfJUcjx6YG9RNrj60MpMyYciF5I+OUsSotIlUvx?= =?us-ascii?Q?Q0C57UwL4zl6vUZoCzALmbaEY0SINcP1PvGf7WX5BnFu62xFTBcXxntD5eFs?= =?us-ascii?Q?OgGofg7Og6cYpeZwCn10z8GdIAmKSKtGljonNEw6T6nn5mT7zoGOd7h/0HW1?= =?us-ascii?Q?TA2iZTdDQJ1nFDAnJAa9gul2JSuU/JD0t05Q2tjiri5mv4ZifZaWqb2TzpZN?= =?us-ascii?Q?cM23gyQvsrpoXMU7iGu0si/uhLRzObUQeeU52A5FfQ6SMX4HJJ0cfT+mNTbN?= =?us-ascii?Q?eWtgGjwwyUN6ohKvcT51Lp8Cl5IK1BXt7LCTRuerUDpYLYPohDNxNyN5BSL6?= =?us-ascii?Q?mUeP/R0V1sRBq9aCVt4qBMZbGN9m2wUCpTA6pWNSMnKrbRg78eJTR7Ypdhrt?= =?us-ascii?Q?bm07P1RehKsrWB+xfZxYORgEzijzbHLnWFGlXuxuaUiam1jZbQ9kIta3sMBB?= =?us-ascii?Q?SUtHJJxXNdsUS+mqXERxvLuo5HeS1coIe4aAHiTiATKmf21JdEaKIUBUkuOK?= =?us-ascii?Q?FEPIxyMJnwiDXiggeeaiFTXwkS9/vhRvNDlXa+O1VoeoZ4+zccISB5Qhg0EW?= =?us-ascii?Q?ly5bxCU7j2UceUUy8gIWRPRH1COVN2IMwzre7sPQ/ijvMBV4RO/+Ip0PcEz3?= =?us-ascii?Q?YrgKMih0PlRa5a4Z4oEaxROUfbA2kmL4v8o730RYyer01DC7LCcURn+POpVh?= =?us-ascii?Q?gmU97M+quToOkNZkbcM74C6OWmL/VY5vnAESMPmVSFvqCONxILpQZ2SEuzdF?= =?us-ascii?Q?ZLFzEzOp3VSUEKgafCOfnUhLrJiR8QpHGKkBcOFZRueHWpiJr17bNehMuGq8?= =?us-ascii?Q?HlVfu8aQFd8/JZaWp5z8noVOZgBa97EHQ1+mRhytkSbrnnsNzuzC6ZY19xvL?= =?us-ascii?Q?puS6ubWWRsQ71FblJdTWJcpzT5l+lOI=3D?= X-Exchange-RoutingPolicyChecked: fKgK8mZEXBJuS7tQLcuNr4494lnBTK8uwwt38x/YDcVLR2y093eT31cpQK/SMDO1A142ylMi1k0Hlm9KWNjUrqE2cRS0r6lz0vU/i5CXhf0MkECJZrw31p9Ro1R+x6yGduPH9vcLIHCo0eD3UNe57V/9Hcd99uVy5sdWT3lJIxUyi3LiEVX0zhiMyNxBwfeegCY7LGSS9NR6UR0DjJB5MhgW5d+dM1GuiVp2TpzI0XLkQ9CmSGz40hKqhcM164IXaX3/cIyptUe8MvhnGvH0LXXJGdb5/zQpeoXSSONwerPqSRuM+qo787su1DcDPqIM+dJryIrd4YNXC8N8tBfykg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d13180f8-6229-467f-86bd-08df2dd96a2d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:32.4994 (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: NaYxCez8D25gqwHMCh8wRJ3uPJsTjnlSAF6Xky8WkbhkLKDC1LYE7tTAlKqZ4DQoJwqOwFeuAzidk2uuxLGLDQAdkWKXp9SgwU5AGqPbrS0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-ORIG-GUID: CgsKdAUEX5Kq2m1WKwMuMd3f41NK1D-t X-Proofpoint-GUID: CgsKdAUEX5Kq2m1WKwMuMd3f41NK1D-t X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX7z2mrku/Sugc 0twb3jd2yIwEMFDyOli5EU7Vcmr6hr2dj9vT+u9DKBF4RxqL3MRFmmVUgGwChoU3kiFxCk4WcOw F0EW62qChxx//mAptHaUApIFdmF+XOM= X-Authority-Analysis: v=2.4 cv=DqHDa2/+ c=1 sm=1 tr=0 ts=6ad607cb cx=c_pps a=wTfA4ZSRtyUhnooKhWOBPw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=ufYRZG4kn_nPcl-B8swA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX/A9NLfRIIpUl 4BgcYpG1UXAYkEqB+UD9alliCEWIG0ELmS94/wAAsPdkZEahG8rybVFYPK51+aLXwvyis3Gbhc6 XtjJ7bHZLZQ6WAtaR8bCsXIv8rRA4Ey4BkXvEO5nEkWmKaN77MFELgIrEnbSIFwEnsHl5R0fwPq FnzJ5mVjnVo8LhfUcY9iK/r4Ha0IabtW9U7El4xuvmlchUzlYLqVcXSgfSnFz//iFkjeTVY//Wv EoG0xefIfS1Y0WPTzoW4eI3UwhmRuTaGKu7cevd+eVn+omfSYa2dLLIWtlTsioRVrxniFxG24/X wEzkMcCm1lqQJ0CaWvUT8MTJLSoxJlKT5D19upB9KQOUldke4TLA39+vz03YESwMDZqMRDEiPgV eJ5zYI4PP8L/norf7UyetGHKOuYfILoLzpZpWeEpDbMjOTVGU6gOsAdbF6PX8VStndpBXJNK6p9 1hVaWmEgcHnL00HXnJQ== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792411600-192CC9EA-D96CDE52/0/0 X-purgate-type: clean X-purgate-size: 2252 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 Reviewed-by: Peter Maydell --- 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 2d8c87b0e3..dbfd55de30 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1167,7 +1167,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 Mon Oct 19 12:06:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454205.1667800 (Exim 4.92) (envelope-from ) id 1xIm8a-0007UP-JN; Mon, 19 Oct 2026 12:06:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454205.1667800; Mon, 19 Oct 2026 12:06: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 1xIm8a-0007U2-D3; Mon, 19 Oct 2026 12:06:44 +0000 Received: by outflank-mailman (input) for mailman id 1454205; Mon, 19 Oct 2026 12:06:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8Y-0007KB-Uo for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8Y-00EE6C-Ai for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:42 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607c8-e002-0a2a0a5209dd-0a2a450c8c32-38 for ; Mon, 19 Oct 2026 14:06:42 +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 6ad607d0-f479-0a2a450c0019-94a39744d2a6-3 for ; Mon, 19 Oct 2026 14:06:41 +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 69J8QSQV3508828; Mon, 19 Oct 2026 05:06:37 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021128.outbound.protection.outlook.com [40.107.208.128]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc4x43qqy-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:37 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:35 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=BexHW3YkOkiqmixFUVy2Qp1/kd4vwMG2OiIAhrOPp7ieXj1c6cbtmfzwK 9z6ql4hAGcYm2ItPbTS/HZypwMwP8AgWKsvMOxfIUv3+Vk37c9CrLhCFG7yQFSjr qxLNU+mBkSrjdE8VWrzGpdbG5OKgQNluHRsH4ejo0viJ+SfsJdFL3sT/A1SbAaaL RtFwBT2Q5sgOGtxF0i2zumMzq0Y7A0Lh3pkqBJNvm168EhNTt5G1MJSNyzq/iRj/ 2a+z0o4LAbkcBEOuK4VocDYO5jCnAVfX8w63EMQJyKVZYJo8ObjYLB9J9VLUhJGW p+bGGpVNPBz3ZRo6SEKOMVj8TfqFA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bi8p4BXwFLqpPgeqYATRm8MNI0zBbrTWvpjAVZkEKsXoyiyOpbZZHvsxuPvPXoVVFfjaTfu3geoLJ99LeWQ982Xj1xjkAXzEFTjbN3YtRfzHY8CL9BWaOdul4Tb7DQbKnlWJ4QUVSkkqCnsu0sOoGUv0lJ9wc9M0nzbuZ8DVqPY/OHYhV/woSp8ck1LnMNnwO/mqC7Ic7QhJUs6kUhXJMPxypNN9g/kPoglisydeJHQQqkA7C8oDxQZK46NMJpZnuqGR1xmxOF9Q071gp5uLTKD7orH50Z1Rnc0bHxag7AGookS3hI7Rkvf0HV7YjnZAyeRgorlhW+sWsnWpbVNllA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-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=ANhEa3rpGGCiKw98xmIY+SQ4xhtwVW9v91oqFB6WKlmJ2r8blNBuME2hjM3OfIPa27EwiaAwi2ChA0NTClAyR9Dz+F2/dGz8f0hhH/zhmOm1dfPn5d4F/HDg+mL+/Bre5DmYV3BwLOcWNa8KN22TW0dvo6vArplMlWzmJVqld4OwTnfGw9pbd1j1MESaX77bfuKW2SZQuzy/esddtMOxzAU0XFQvgpj0jJBedxKXt/RJhXgXrhp5EI6C3ZlHPIoim19/u23F2Iz5NpVBolujU6D/nsyO6hCdrB+WgmJFupKy8Vgf+azYOrKvzKVQuiX96CbWl3QZC1xh9dAf/ZlhtQ== 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=EliVQ2rtjhURbkeHEpIoLl+VIRiKjxNY1119GUXQLN23UIgh4+eY/VvkmQnue3FbS//qLZxZykj26H4alJiupbpaVA5uiZpznXEQ43HIXuWtNVddk62PIQx4N+8K/kHfarCHiwWxCokN7ygs82iNOibA6FhdzHqoRibYb+WUDdOJNzI5+3SU9AGC1LTbxuJGgRi2kOa9QSLQGMMx/GyGdDJzV1o9zJxdJ3lRs2shQ/zS0ti5aDkzHa0nYRzuRGuvYDhZC5sED3ijQ79eVfvXIWcT2EOWMr+SXJAxev4o8Bm8PQ1Ee5bj4IEB+gyldwoSH1/Ex4UNlWCFjUFUuSgHAQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 23/28] xen/xen-hvm.c: introduce TYPE_XEN_I8259_PIC device Date: Mon, 19 Oct 2026 13:04:55 +0100 Message-ID: <20261019120517.1448687-24-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY5PR04CA0019.namprd04.prod.outlook.com (2603:10b6:a03:1d0::29) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: df20da01-0b12-4afb-838c-08df2dd96c43 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: mrUtXT5iNAoPMSImOxngGGKgtq/Nk+Idi1ZNQwXcYbA0ffSRwxbwF/DYVEd9odGRsEC28saT3Fy/+XchkrseW30IZrz6hZbEGBTuMLoPTHg6tCpouO4mIdqxm4TbvANsu+MkCMia0G3y9Am+LEJQOe7GOi8ceC/UfKuU+eKvqacQilEwHbouhI10/uUseYxYOPMPS3XL+TpfAk2mN4Z+zIp1puoFfAyWkbhbzxVIPof93tHNR0w4LgU9O9YJeujxAI7YnSczRRs9+m0y6ugx6lt0uhf1oTvwqQ/mHaNc0ZzZiLTqZoRUtGNfIOEo+kgzKSqYbw8AgtTl4RQTEAS7KRPQ24E9rS9lhIT/SJOSb8BViXf7F2sxj+SwJUY58r8PJ2GtdRj/Y7pGt8D4m4V0cg2Kky8FMlOMQJfWL/5PEAeiSY/IVjb6LZTZ+zEHfe34CgkQEiMrE2QPQ3H+EWdar6nmov9qk1GCG6YrYyOYTrLhws3Ma/13upDmzpSnCszzh8D1T1PKTmw/aD4ygbBGjC8C6NJ5f8Gy8jYgW63xXr4/3+MfsRpDSUw4BMowaA6EiFA5ufyu+hyzdGaatDwBVLZMP02xprBUEGldPQKHMCluKMQfufE6B5csZAAZv8b+KRC227EZSn9eYt1z6edtNPFOACKqlgvjFJ8pdhD2cHA= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?pgKimP+VDRGcI4gXBGZ240N5OOOgBEZTZKv1L/y+EO0MWAvjmMADYTwPFsa1?= =?us-ascii?Q?zmjPpSAcovRFWtAbA6Cp7KnoKym/5G8R+BjL3GdTodofO3o7TSN20TvfNY4T?= =?us-ascii?Q?X0sci0CI+wMnkyoZTGyDreixWfYu11wtNZ0m/sx6IQ/4bBXbZMBAiuoA0tnz?= =?us-ascii?Q?g3yjqZOhvfNkfL9a35GNW7LAWCpSOQnNqDEafaqIKLH/DPBP+IU0XX1pLrQn?= =?us-ascii?Q?aauJwQvjkh2o4yTfJ/Ps/C+QVnWk5lY7vy469oBr+HspmNxJ5cwYSieKE1Mq?= =?us-ascii?Q?Clcung4YjXO1/xAl1pCvMPR+z16ttAAaznmnvJSloT1xPd+qePLTIGTA+LLl?= =?us-ascii?Q?hjc8D3ejsaf/AkL73zOWZ2OE0CA0SDH7ijEG2q8a/aqKKQggg1Ke1/MxAjdI?= =?us-ascii?Q?uYV+1Fc3+l55USwLGO/gGb2uVKw2hLO7zay3yxnDPfM5VW+HHOLEMx4QHkcf?= =?us-ascii?Q?QJZD/onm8vnv5sTwZgY++d636TIH/vxIBYjA1rmNTvlgmsv5kXd0GTjv5vtr?= =?us-ascii?Q?ED3i/lTfDCPnHUwPgHmvG1v4idzw0kLBZJF16CajJUQ1RlDMLij3TEnNu+wj?= =?us-ascii?Q?nQpF3yh7th3A4wiN3COsXc54Zs60sZHsXxyfqzTPNPLKFh+dzIPIgS48R3Cc?= =?us-ascii?Q?4lu33LS+OrwQ1K7QEZpnauSj23R61rZ+J5V7oWLhQVOvHJJ3VLSH6nJJ+Esf?= =?us-ascii?Q?OhI4v+z6Nc7JbrJ3P09TGi9TE0qCC+oDcA40kU+kPqDEz7qVx65IY1dDjCxX?= =?us-ascii?Q?OUjr1hRh7y3S/YlhglKUyvsr5l4eTEsooNeiEBs2PQ4g1GdxoOmOEmDdczXi?= =?us-ascii?Q?dig12R0jA4qrjO39PTV2URdljE7AGl+dkjn5I0OVQ7+8W6aC5dnthxLjVxwI?= =?us-ascii?Q?enJsHwuJAnNStTpeQiO04jWwEpNqOOaLpLSvVoITMczFPDHF/s3GlCglniSm?= =?us-ascii?Q?HkM8/64OL2YJkkC5p5kbEeR3S50iJ3Jis868JlBLlDTDueQzRguYfkm9eo5k?= =?us-ascii?Q?ZOaOboijtvcGmSneulLNrexFXsUezHHtPvXE2QZ5d377O3Y0pceCkQB2z7Br?= =?us-ascii?Q?2WHUk7UIh0qv0fTzegWdRpgNiRpxcanK4H4HsutvSmv/8kT0HqeX36wQC9RO?= =?us-ascii?Q?VgRyRpYH80Dd6rvF7R4yRBb7jAbUNphqIjUSG+oWO2GFuYnLZHc5zYTS/ETT?= =?us-ascii?Q?Wyn9Z49XfnelQ5zejba1A6cun5uePbiY/DslmhIN4QlgOtFqZiTIIEP3/Lnv?= =?us-ascii?Q?oCsMawjlTv0VU8tcLph6inC8j1kXriTyIYuF4lNh6TkGC2hs38svKGiSaggs?= =?us-ascii?Q?Osin5rVBqDeEvxK/rFzPCtdVbYyRjKlHK3vzHCYZFiawGgLYkIJR9luUjk3+?= =?us-ascii?Q?zTO10pmsoTvxcX+/xP//WWKa8nsjKdPH9piKH5KzfZy7bLGOLkhy5API3bq9?= =?us-ascii?Q?PhzuTYnDVZuxyOkk3bI42n8k1gbf0AGABSsgvqq7/OjKZZJ9q2KfI2gXgHy1?= =?us-ascii?Q?mcP8UPw8YBvk3DrraLHUXyN0p+Vo4e795X4wdp6M9rzzrPNh/BLKJVGbWTFR?= =?us-ascii?Q?6yNoZgYXuUy192VzqwXH13+l4v5/d1ParNZv49RFY8eu4z+1R5cBl6j7EYQ/?= =?us-ascii?Q?cMmD3oz9JpVfDpmbJ9MiMXWcQlEu80eq7iwunXWCiaMomYy8a63zL/gHWja/?= =?us-ascii?Q?9jRpIwTVBXqcmfcaBlfnKeNl44LQEJrQBtXuy1s8Og3hFZnfSLzhotTU2hvQ?= =?us-ascii?Q?ourOrO8ekwwRDETBOqZrpSR87EjdXTQ=3D?= X-Exchange-RoutingPolicyChecked: hda0Ne5LRgxZndcFe+UbmQX13CpMIBnX5UvKtm48MijsyMKTsPx+a4pbUdMyY+tXooPwTf5Yh1uKhjxoWLTXy9ba58yaZp+2DCeVAGHRuRQjHZAzY7KhLqYwA/8H4NanKm9nHFN0jrfZ5x5yNeQRXwog94ioL//U9NtElawhbUEPj1lwFxk2URqbfR86F9SVkb6kPkRk84npf1UyOdVV7Wyp/P8+02BxecY6ntHbc/icm98GoBW8xwcIcRXaf1SAeY/nwTuSe89ik29/qNyK7NLQqAyJ9wXsKrh+vIqGXTuIiw1xIXpsWAiz1X9hFCiyf02rI+ne8qAbVzplDivEQA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: df20da01-0b12-4afb-838c-08df2dd96c43 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:35.8357 (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: lgSpoE7Nn7l425ii3sZz1lTnLwuQP/zoeLONII8Am2VzxhMKBBJm10XDJRVRq8O0h2XZBc1zi4ah7M3NjjTuUWdAUyj2sZSziNq85i5Wb+Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-ORIG-GUID: 7hT8YounA0wJWlf2RGeb9zgeUtXMAIjy X-Proofpoint-GUID: 7hT8YounA0wJWlf2RGeb9zgeUtXMAIjy X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX5KNoUZ6EWuA3 2rJMkJanZ2YduW/iOkSzR5WHNR2dOeTfKwBl7ENmWsWB/v/OIu6wC+hlaiwUjGdD/CNJz46vddH LGm4B7icLrvC1L7OL2OrODskaInwtoo= X-Authority-Analysis: v=2.4 cv=DqHDa2/+ c=1 sm=1 tr=0 ts=6ad607cd cx=c_pps a=HH4JkQGtkLi2X7RbypODRQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=tqVLSPGIGyqkaOPIRdYA:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX/Al4jhd3a+dU hgCPyKt7lFWJt+q+a+Y+C9Clhw/p0lq68OJks8kbTzRYSVcba1y7vUKU61woW8iw8fIBNX8ZuoC riOhEewYXVBOrB/CdyTWJSsob0VpoB/i4iGpu6TcMw8qyxdb2nzUv/xkKl8y1XpQUnmu2QUJFSO IjbXPoGvbwwVIlDcflP9OClSZhu0Xi6eRDrYoev0o5aoS3HC5dm33+suemZIQC7FCzZQLozPDlV QULE5MgOc0AYcyA9+BeLP4F8Lzl8Md37XBnDbebnymDsadZAuhZsMfVI4zkHV+h7hyb25mN7ySl /etFMo0SjzpmqmaJPUmWSUc43+emkmMV7xpFsigolH0XqfhBllJoQrlUbHhwhyZBR/TGZxI/nXr BcmcXO8nu6O9VMDyU/2ISB38jlT/big+oC9uBJuopz9RZPJVMWnvkptbDkmoRpXWl1MiNPy+1Mc p9CBfclzlAJvYPIMC2g== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1792411602-5290EA5B-461ED0B0/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 Mon Oct 19 12:06:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454208.1667810 (Exim 4.92) (envelope-from ) id 1xIm8d-0007wL-Tg; Mon, 19 Oct 2026 12:06:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454208.1667810; Mon, 19 Oct 2026 12:06: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 1xIm8d-0007wA-MP; Mon, 19 Oct 2026 12:06:47 +0000 Received: by outflank-mailman (input) for mailman id 1454208; Mon, 19 Oct 2026 12:06:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8b-0007lc-MA for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8b-00EE6C-2V for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:45 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607d0-e002-0a2a0a5209dd-0a2a4504b58e-20 for ; Mon, 19 Oct 2026 14:06:45 +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 6ad607d3-b57f-0a2a45040019-94a39b0c40ee-3 for ; Mon, 19 Oct 2026 14:06:44 +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 69J8Om2S1634634; Mon, 19 Oct 2026 05:06:40 -0700 Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11021114.outbound.protection.outlook.com [52.101.52.114]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8bckgca-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:40 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=WyA/oexDigpjp1MqIVZSX3oyJADfec6ddFmZwK/KF s4=; b=mycBKSmnXP56E8nOzCpZHEoXtJ0UP98j1TqbUJ5zeHkGOkJ58dWLu0nre 3J5Le4YItZVsS27HFICFMvZJ7fN8obtkTRCfhNgI0S2A1FRj2NZ7+GZxBI2OiMlq 1eDnKd7OVshtyJAZQ3N3ve78C3D6UK2DUVewraVCazjCz8xHDUp4U7OksHk35+d6 1cwY5iQMSPQDq/SQZJi1utEN1geywzvaT2cYdFzdGHk+xlRYu15J1V96YcAPrphv lXIvz0Om+3a00IOg9wXV6VeLyyPpZa/ruxp9IEplv0v5P/tjBV6QvE/HqLm+XaEk 8MLeT5+n8ura0ToMfoFI3VH/q43nQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uMgyNCUcUYf2OVlyKzYGszOKvHn88PYi/fvrR2cgAAih5Dcg2+Gg66IanO60FgjGnBbNK/8sTM1NzM/dg3p6YvmaGIOALN4ZsqeLBZ8zkQmL5n6JmBDUBrGk4kmJmuvCsWALJkswtK+4T3jihZaMTl8Bwt5i9ANkHEZdyIp4uEMihOENTE+xoG/T61rNVX06haitx6rCjSsF6Ivrn5UJVCLhYreuoQ7hEpsWXSExrJ+PP55NL6+kw4syoD62kyeNNWcPdRSrctWSxh+fNphEtPyP3azIqiV18ObdLUSR5ag9QP2tTEgjYXxojObbK0CC+PMyssg+WGnnlUnE0/Qqew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WyA/oexDigpjp1MqIVZSX3oyJADfec6ddFmZwK/KFs4=; b=e7G52uuha3zPYSwdkkVTR2EWVMbYHI0LffcGz8pWu8kYfIIVc3XNxAZNT5Mk7e0aXXZ4DpUuMS0n7vLdisk0+nd67L5HtBNDlU6wia+t72t5oSqmR6wO5ABOW6+dpYJs7lWSPVLy1tXVmFrkrmRutcqLCxljCwYcAtLybId6n1E7MfKwqqym0fCgGMGpGm6VcdIY7k+PwqH7Tecf4k4TvcJtuq3QPokuGvvXabzW2Punk+swatv4T8a1gdWznOlktKyvKIvYjvNQb9Ygl0HDLCAj7vKY480/GJJ9Y5ABZUbxl7o6TZzn5//vjbeV0O4EO6rgTKj8c+zdAdNwA2sRsQ== 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=WyA/oexDigpjp1MqIVZSX3oyJADfec6ddFmZwK/KFs4=; b=YW7XUx3ylt530mxcN+FNS2uBiqTm0kuOS3CsJOm0cQ0v04TpKyJuUSUbq2Anyv8ZO9lXFWZce9mIfctSvh8RFUrnQ7rSwmPhRY3cPAFuoEC7JhOaz9CPpfJFMQtdMaJChHe8Cu0XPuBsSt39u9DW003JG+E0avdy1X1v+N0Q/vSAUvlFGqNKeua4IagiUmop9KCrWsxU7jiIpRTrh7QeDmCXT1bnLI/QdS8KfE8jXj+G1dr9/V6Q/rFPgbFWyts2WZhoqS8VSKkfJ/F/uH4HyzTRWWjkZ4kyMMnHW6qy0XOzjwt4td+AVPxd2yLNMKwhBmU/GauetLEuYTfcKnhW7g== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 24/28] i8259_common.c: remove unused i8259_init_chip() function Date: Mon, 19 Oct 2026 13:04:56 +0100 Message-ID: <20261019120517.1448687-25-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0206.namprd03.prod.outlook.com (2603:10b6:a03:2ef::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: fd6fde36-aba7-4327-37c2-08df2dd96e11 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 2xy2Jq3EA33hKKwi8YxuPCp+EfPnVXH2cWqc9ItYvQ6ZZIKfT6cyw4X/SlaKw9otmIx1d6K5Ji2EBi+9vvO0C+R/a/dl1gRuuFKN9Hoq/z8DJu2MEjjuT1xfLvKJYv/5JecKjQ4vKzy6rHEY4uk6XuH7pcxe5yD8TmrJ5DGlxqv7sDkyFu1c7EwUQjvoCdgBZ+pxFHwAh1AnWLwGSyv7GRRrnzTTlUHDS2nETXdaPMwuHvDgBP/3lAIUwt393jhU5rkmlvb+H17jffbAE4/SfXwTIDO5wgTpG29S/uiEcadmEIO+W1zghB3G7Q+FFQLNZ1Ty8mar+m6VZfDL+2lztOo80ArBQpdOKR3qbKn0yz+oihNrQTn7qTFJZZJZTWD7oDrkoGBzO+W73vTKuE+0D6IgLedd67ka/0zQVtQP1Qnj9NhrYqv+cN2qQcjNTGZ2nrccHoVNu+457XNepUflJcQO25jSlAZ45wjnv4tCE7K4vQvgKuHGLpF/XipMRoOKIwmcSaqk6ZskFC9mK4VIAU04cIEBIbk7QuTsAZQ5FGzs/0xkpTKfBGKpIlOtzelTk6v7h+XmxzSwzTDdWw/xhcIokb+YehkNlT1OoMvUGIntYD6eDg/TPpuzS/MCUXPjJ3oizMsTDbjpugvByt35V3BUZzYRF4oRjd3uaZxiEqk= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?dKHweXxhBkbNK1bVEOe5MXQEx8CV3uLkfpINCIQDeERBxQkZI4SiXbjuG/Mc?= =?us-ascii?Q?nIY1GzwNqCl2Z+a43wxIGUn1uaPFLVj6BUgDxV5e+3PknIpG5zSouXW4A3x1?= =?us-ascii?Q?h3DuOwMMSo4WKOCopsn5m6lQOnbJUoJzYhn6wmA2bGdXrfmQApvfA/Am6Vvl?= =?us-ascii?Q?GE/2cfeKHhw69qcb2CpyzaYnNDCNs75+g39esWuyGFU77hSzxNLGDq0C1ppB?= =?us-ascii?Q?T9x+QMDTcKpHIWRxqlB+++UuuyylD4wFOzUiJqpGYDtsV0yRgh+eb4nj/z0F?= =?us-ascii?Q?dtsmB8QGUFjUFhP1QLF/zihJkLY/xavVHJxp9ay/ZSo8s7OYCbXOO/JwTDgs?= =?us-ascii?Q?84uUt9cWENOd9b0ird52rSSpRMwgayVErsTNNAwlbR1BNlDhClFfRCMHYPKY?= =?us-ascii?Q?WSBycOg+ljk0PPE0sQVp1TUUbzdI4YastzM8p3ThweM22Fb6IEFOvZYiIR6u?= =?us-ascii?Q?J3cNM5bvktcz+ZlRuqFVci4Gi3q051xSn1n20mH4ufBy/1BSerSujKlzd/pv?= =?us-ascii?Q?gQvfZV2a02d5OvDmJ42mXgw1c3+KtDv3GSNcSTqbHe6RYVqUZoElSmbgJSMX?= =?us-ascii?Q?KCyNyEM1kXNX9lrgcoxh62+TrINXftMwB4i0iwoOd4iBBSNNJ1lz3zMGORDe?= =?us-ascii?Q?ipa8IL8NotYDfbFcPE+OEHETQfguQfihEdyOVt594X5f0Vf0L3tvZDBWsDVm?= =?us-ascii?Q?tlp7MlWH7Mi8lSG5A3/0iT5YZsS3S1sl9Tau4ak2il5cEQqgAIkSyYcKbqGq?= =?us-ascii?Q?+V63vnttiW3r0iuwAKc7wpeeptZeq+FG04JCCqtyjmLEyS/hZhEy8087AM89?= =?us-ascii?Q?sg/mcAYu8zQjEGhn68++PFfMqmrYmel+nEj5htXm+i61SOwctkL/12Ya2EY2?= =?us-ascii?Q?e5lid9/9mrC7I9ep13vaqhiOZP3XLeBS3VDCln1PqgwhLXx99zmHxzHQTcX8?= =?us-ascii?Q?gyU1EJ8vJM+LYpTMhwWu9xnXVW1+zdjdP1aRM+w3VvlC2Ny5MZ8Bsgqg9bTU?= =?us-ascii?Q?FTPWgdnBfiIj9Jm3QRZQJlHFV3DPIGUVkEG65naxsEEz78usumeMyeCamjkV?= =?us-ascii?Q?JzHbb/4ZywHuiaypJIU8QF7Bvg4Er2sjT15eA4JZ7Hb9smJVJvsDxpcMX/tY?= =?us-ascii?Q?aaV9/Pnn/quG0ocy52z1s/dvZmFUs73y81gqwH0G7FhbW/reSMh26pmJrUN2?= =?us-ascii?Q?ur/Bpixk/yYK/7p8kvd31svFFbrJCQ1iRNXP7jKv5KxxCdpU5bOpUJwdGlRp?= =?us-ascii?Q?y2gCEJb7ho7mI2Wf/pi/TWXf0zSbH9odH0/HgJUIlzMx89gXGMKJORkAx6oG?= =?us-ascii?Q?xTcXfhvigUVfypd+0qfi0RFBQgJh6yH1pliNyDtMblQK0YYbT33WIrs4atYM?= =?us-ascii?Q?q/kENTGCdjn/SwUhblNfv+HGtfBAWdBA2pB7WzTIsGGbPeoIFZGxCeCh4RSf?= =?us-ascii?Q?iQU2GwjAjHk6Wpp10OE1VcAWvtpSGUyk7fmhTtC4al0l/RFIV+oZh8BbuvyH?= =?us-ascii?Q?oQ1BwlkWqS1dIzUXwk6qm79k+dzu1J4dfMP30NssoFqypsUuoYCi0ji/k+nu?= =?us-ascii?Q?CflZgt0Xwle1rZVXWMMC0ZMN2rWhLkovzaIRvl3ca2Qo9tEV+hkjlbIJrn29?= =?us-ascii?Q?Ig0XkUuGtJhR8zTcm+nLhfQlamaD+/1gd53YdBhYLipYTgfb0uph/104VGVr?= =?us-ascii?Q?jfTS54xm1deeWzCnSr2AZRxo1VZmbmROCkmrCl4jorPyjj+qYTNj3+6+U7au?= =?us-ascii?Q?tu7id8aNTPPxdT645pvgY5vOIGTJY3A=3D?= X-Exchange-RoutingPolicyChecked: HB664yAc1QCUAuYdgk6xVa1T0ojtJEpvDvLKOzg3C9jAABO7ArP4yOmeU0qsDI7XA4kcNLEDpphW1KLTGtFSKNVpkZrYbUo4hBGbiKarVVa6T2lWh/KlSIUDta8J04ArO9BZ0dd3m2FGdp0OSvZ+RxGfVtrnWe1z8kWz5dy6+xHeUsYR7M568jlRep76vnXv7Km41qqWFLpm3qEpeNCbtrJRsXDMRROL9KQo1ebAJ1qSSuuk+6bypTE7g0bN4huWyPwYj9lALdc3ZMkT2vVhCYDuozftY35OGDCAOUlN7ZEGzhaNw2JF5e3QUoAG8IgElUd1yrL57AZP4Mk88IsDxQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fd6fde36-aba7-4327-37c2-08df2dd96e11 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:38.8231 (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: RkaWEsPnGm2pVPQkszWB45ipN9e3kHcjPT68oM96uhPIq8UNdTIMctx1FfURs4XX1xRA9UDM7oQcwJCyj5FYX0gP2K1NLHqHqS18XtU6pPY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX5uVg75pVWslY x0Cr4u2ujQni+wGSQxuSIxcjty9AN695kDRF6w+uZSCtRYTF8IpvS4gupptRh/SrgdEYEeJFk0p 9RsRqHeo3bkwpIQAC/yDoNS9bqP6zgQ= X-Proofpoint-GUID: -IV53k1Livxz_40hyx5wQcyKGE2vFe5p X-Authority-Analysis: v=2.4 cv=V8joQuni c=1 sm=1 tr=0 ts=6ad607d0 cx=c_pps a=iJ0/73tnBOJCmN8OdmQeBQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=fn9E0C1quIHmE1dKZfwA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: -IV53k1Livxz_40hyx5wQcyKGE2vFe5p X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX5zswkFbffTdH 0NGm5t/i/Yaq8CH1muTM4gw6HKAT6znC7yu1mUqfdTPzMre5DVxAI9iuvGNJYP9/ju8Zi2xa765 5KsH/1L2wV0DhmR2pZF8UwdXgd+vDpf9tRDgh5zuR1OSRfuWQ9KUTthWkGLhK3qYHEjMIfQBgRq L/Xv2l1vjZfltKweEwmMi1thD33X4JZLqG8lsiGOAkPblNNLLPi4oUFe22gLL/Mmr9CsnXK3/yh WHP/WyoXPCPg988Hy+jsUMEFeeqO9NZGQ1ybM574AcTPKThweuDLy5uyqzhu2o5thOtAzZfuwFH d25A7tja11t9lwToBE+mdRQ1ykADUS4+fklCFT4Udg3sdJNMBV6MQCEN6c+yupY/GEbzSlIZzaY sGytOGUKFEB8wIBRAIBNAj/lMR5Wz2mv/TNz90C/HMKEeWjKMgA7rM1LQ/2Y21HWml6JNxenoIj 6jK0P3Rw9IjITjUOzPQ== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792411604-C24CBB50-C86D2A3B/0/0 X-purgate-type: clean X-purgate-size: 1704 This function is now unused and can be removed. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 644508a44e..dd255fac24 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -71,7 +71,6 @@ struct I8259CommonState { }; void i8259_common_reset(I8259CommonState *cs); -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 09b761321a..5fa38fbc5f 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, cs->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 Mon Oct 19 12:06:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454215.1667818 (Exim 4.92) (envelope-from ) id 1xIm8h-0008SK-D4; Mon, 19 Oct 2026 12:06:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454215.1667818; Mon, 19 Oct 2026 12:06: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 1xIm8h-0008Rc-8R; Mon, 19 Oct 2026 12:06:51 +0000 Received: by outflank-mailman (input) for mailman id 1454215; Mon, 19 Oct 2026 12:06:49 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8f-0008Hx-Gg for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8e-00EE9V-TH for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:48 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607d5-e002-0a2a0a5209dd-0a2a4508c184-14 for ; Mon, 19 Oct 2026 14:06:48 +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 6ad607d6-f659-0a2a45080019-94a39b0c3680-3 for ; Mon, 19 Oct 2026 14:06:47 +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 69J8Osgu3282313; Mon, 19 Oct 2026 05:06:43 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021081.outbound.protection.outlook.com [40.107.208.81]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc74ekjh4-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:43 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=rzdHUCfCbytGRtS+cKyd2Lkn3aUnlJZ11xO0v/Rty v4=; b=DZ9F/NNkYaGBd7Ztg7txXoHDFp00rqBN/bNDCt1I+RWAZCmzD5LnZzcWs zASfOWOk4UmCUyVtcoFX3iQxP8+WbeoZwI8buGDzp4zkIAscXlX9Zu2izTdgxjyp 3lEeqqXFUWNNYwqGetBeKzoVHOgWY2fWT7/AbjqPAwAg8QGPg4+kQ1KMAgSVoi1E FkR97q1Opohw0bjDJSVEYX+/R5DGd4DJQQfGVvHu0ZN0hLRHqs34Dh7LuMum2Hhk Y5HTR0ttAYmVomGkOV5YsTFA/jJ3s2ksr+0QSx1M98a5HS5hF8FTGOi3tCLbVphv znlHug4GoPqtS9WgknmG9KpMTv81w== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dQYMKM6lgTJWzqtOx93qWpPlfMkXYqRIwv/4eBrK+LjaKNHswFYDxU92qbiem70tev3ohmARI+fc68vkCRarzOBkjjYxDoCuXOdnXPQDvrYRNFONqt8LoxzsB0Y1jOWdzrzhKU34Rl4LaRGCdeyuUzmd2yiaT38WDRYE2lHjaw9A7DVLVGcKqD8CuzsuOj/llvM1essMU6r4xk4ukBg1ti4nD8RILAQ9FIu0tsedXddK1McZTbW/16S8Bq1lRXO3brZlGTZmBFmcpDriEDKYF/ypXYyYPQNNGZLtGf7TfYecCMoZ2VvU94zBhn9BMN7J56x9p6f6duwDvWcGjnk4Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rzdHUCfCbytGRtS+cKyd2Lkn3aUnlJZ11xO0v/Rtyv4=; b=uKO27ix8RZ+pwLthVIsPNOfaW0VYRse5HxrzcMmMNZNj4/d4Vcdrb4U+UDWKCeeIYk4AY/I8n07F+gON7MGuPCwqQmAm64xipeyFq8ziB/0u4jbhfWaKWGcvnGQS+QpxsXAMkPt3wHhihSozK7v8CtIc2p7/7/pWswHHC1r7NQ57GP66mR6+f9C3ISPV58ZzbPLsswClOUzwtr3OvR89Cd85jBt2/PZNoqaREuE+J5ZbytkmK6o1ZRqkyAFHDyuzBktHx7X8JP31sMnQpObDlE4Vkr2FuRNc5tq6H2o36YAZmmgQGJPioKzQgKblvVjMiC8ZMMdXKQiJFF21+pn25w== 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=rzdHUCfCbytGRtS+cKyd2Lkn3aUnlJZ11xO0v/Rtyv4=; b=gNLwVesZuRcaqwZ5P/wkNR4ihSTn/YUAWk7wa5p0pjoSYaaF9KgzJDg68aQ2gY5RrG9OBxIGX/Wh/NVxaf/4Klv7bFvq2RaGNNOlk0n2RS8pVQxtpi48Hn3ptoTbkZm/gX3qFBLtHFAVcreYPgvP15lmB3KpkJ3W2UyCbmKpZA3zGaWIFIIxGJ6Xd+pcIbVEyp9HXzOq/LCqZHOSanY5StTcj+ThD9A3al/q1oT+DTMNDfCYG8QvFnJlEEDo5fgaSs8dfZ9zRCykffNFM/GQRavgjL+UvyT4xj5wSys2siQ1lsMB3zR+9bVyr9pe1laBvERRPih2LqIZb6gBHyektw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 25/28] i8259: move InterruptStatsProviderClass get_statistics() from i8259 to PIC Date: Mon, 19 Oct 2026 13:04:57 +0100 Message-ID: <20261019120517.1448687-26-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0226.namprd03.prod.outlook.com (2603:10b6:a03:39f::21) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: 33a3d0ca-597e-4e97-230c-08df2dd96fc0 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: PCI5xssRG+KrTMRYJUtAR0AtnchMqk9pKLvg0Y3s/o0giDhDuhldbjdnu0MosjkopNySP74M5KVeJWmzL4VMJQaP+xb+zcQVsrFQCovBgB2ma3GJXaD06466+ZMOZNLP4UVi1300Cr7+Y1JiDKDZmaP2J/B5QQ6oQfHNQ5WnJVXYpdvNA6nmwqXStB2gYo+FX323t5MJq/Y9gbpZTjHv3UwMH8RjMA3J7S51iBBwKc+ABWDB5KYCycD225BSK1OQ1atc64k3OezqJ7XhA2t1fN94z13P93qpKzTySXh+tYWzBh+NvqntRoqzPDio76aWYrfLaYBQ6u+GLtRzMidHKwZ3TDRsgxLAqhgAitA27JbFMMI008FwzQa0lSgITxyQ3zFGh/1KObJSwm5Zf+a4C0Ysdca03XkiIPLH7amtFD1IaG28QyM/XRzeZrwDt3MJumSuJeoActZJIZ/RYF1FQsckAVhXggxQ+EzlvBQ93gU4ZAmYMGs5LnpsnwCOlsyDxlLmI0s4up54HdBr7NhatAqDjz9ltymnX1Q19AQ1VcGQLk3oeJCGFzg9g3cG1o06fA8ihTDgH72WMws+vsT9vhIjpqP9nCmQaofDGYEJXD6OREiauu2YaPE0IGENWsg4IQpBFWxCziVKKtItebYSLAsLpa9Mp5DJtHmK3kSYoA8= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6BsdDoP54UWjFv2Eqi+RVppp9JzHMMkNQsT8lUYLy98fTxqaEEJ7FfeaYA7q?= =?us-ascii?Q?mXICmsRQ6f+08bISV9KCA7wbBCgkcRoUQYhXCzG42WlkPHND1JipFaYrsnf+?= =?us-ascii?Q?3X/uQu7IFRCfscECFrPsz2yc0xqgo6bdrzJklBh8i1N9GIzEwlpmHKzyLlgv?= =?us-ascii?Q?CBlIzW+OdipRpQRfkKOIO5cffbe+t6FgFUWGUmO7qt5TSExMzZ5ChreullJM?= =?us-ascii?Q?QZ1WB1wOPoegfmg+pXuO7YTpQTdhhq2U2ySCUERFRkRb94PAWUf6YWQDSTdQ?= =?us-ascii?Q?UrDVHQsdGUcEOOpFu92WVNsFWk6g4iH1BKOQaWWyEAV5+Gz0MSxtkrBMPkFT?= =?us-ascii?Q?sj1EQuBnAtLomIiTU08A2Nu0UG/FYzX+f/8iEif9x4uCRvBLpRmVP9swd/ZO?= =?us-ascii?Q?u3lr8QdEz6jUAhelLPvOKVDrb41J7UrqnLqIB256wJb/Ca8SjbRmRiJjuWXA?= =?us-ascii?Q?KkuRYXHYGBzPoCcfKj8HR7VJjdMkcPh9jHU2z6MCAYGEaoY6Q7yxaitE46DG?= =?us-ascii?Q?8Tl5Zeh/S7Yu4Ccepv4sSTEssaeg9Elnxq4WhyvTHNW9BJadNjOUYOg7mIHr?= =?us-ascii?Q?32TXUkm6DTPHi42bgKWk2FNh2rEolhVoJZAqRLsARhMDq3o56U1/yOs8BTo0?= =?us-ascii?Q?12REndYUVnKD5o6KUdH5iW0/Iiy3REPtwZRsPniLv4F2A5DO4cbmH5H8hAum?= =?us-ascii?Q?veJ0XcgMfPwCkEnbghnIzcM30fYHiORxYYDg1TAqg1FhVzqHf+ID6nogg1HG?= =?us-ascii?Q?84pAs0VBcAmIUCgG6SDkAQAzVnsFedBTQjondMWSVWZ/rdQi7Qb7UICycLO2?= =?us-ascii?Q?FD4aCJEG3VH01azsVEOvgbfObLQAW7HQPfNsHaNlC7fWDaNa7BD9mKT5rOEs?= =?us-ascii?Q?4q6cP80NtG0TKOifHsnzu7DzEt50mMwYKhBI6y/Ru/GKsucsjTelGds+alSN?= =?us-ascii?Q?K4l/T3pGAo3ZkD+lAO1bwfNc1qRNXkFBIFCvFf5n6orrBPPil54QJzIITQch?= =?us-ascii?Q?TodNL9SafJrKku8H6Me8RWd9ApMi1EYAguBWEM/koXYEan0BCywLu+BETCEu?= =?us-ascii?Q?yxy8VyPBxao04pcDR4LtDgIab2auUghqo/pmW40xUnfpPH2QxfU+GOWXpNiQ?= =?us-ascii?Q?2SS8vAYXrE1a/Xpi80fVwOwlfGEel5g75UtI8bTEZyjNZ5qVbove6Fh/27Di?= =?us-ascii?Q?shOSc2Lkpp3PqpF6CUeeKDrlqMSByhPYT3zm7wYgxQvo07Z5bVoLVJKHyg3J?= =?us-ascii?Q?xmkgc8eVOzXY79iDVfYwgcEeUkQT+bfxpgsOsqcHsBDHk2npCEeQD52bYp8z?= =?us-ascii?Q?qc/d8DYZIM17bqLO6XZnX4fXuPp9Ar4kcao/xFpG9mAj37tPWAlI6hHZyKT6?= =?us-ascii?Q?Y2FDQZDv9JzkaCS1/oPG/ACC0dPVqRhs9g8I97NOmz3OmJ9tTr3JoGBn7LXz?= =?us-ascii?Q?6rQoJ3uICPijjQpdWT09Y1GZH3qaqL8oOzRKEcF3JyL3pwYjzSYLJ47gjNPe?= =?us-ascii?Q?Rj3qpVqeqBhtm6tjQGpqVDjyrFSLl/WSCbCk7UQ7CYFAJBFv7oCkalZKHCTC?= =?us-ascii?Q?mSa3SnbEtxjMddAU8JaTr56ZtFDNBDx6Eyseho83wy/LRfeFAKbN2hr07REZ?= =?us-ascii?Q?C1WLs3I8VhgQ+GlQvfldK/uFunPbmXQffeRDDnqW2ppQl9w3dn/Hyg4Uko5i?= =?us-ascii?Q?k8lzFNswh2UCvp9bftkIKyYKNq+3REkcMiVky7Wb2ueHEbYhihtTz+Zk/qHQ?= =?us-ascii?Q?oWbRpDd182xH4THIo67vRyEQtZMwUh8=3D?= X-Exchange-RoutingPolicyChecked: 3VgqgBrFo2TK/kZGtQNt1wm1XBe03fXmy7rmq8EN6NuOOguFD0lovMMyjx7JFAC7S8kVojrnSSKfNjmGF7o6zGq0ivnQA123VaAPgPBnH2yT7ANO6B19dQNjadMXmyBwdQpmMdPyjcnCG8HPPvrh3tzsBr7S5ZlIFLpJidIaHZQCR0NnRKFchtFS8cwn5D1/pE0Ynx5/Jfr4sKPF0RGK/5qGhTjQUlYBlXMbFPYVyNs2elcOE1Boszk9LgdvnFBrLG21PCWuZErVcs++2wQV9zn6AuLBMH9SWNrThAJyOZ6F7+dhDxdWLHO/QGHtyDuCYmmWbh8RkgIQTjBiWCx5jg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 33a3d0ca-597e-4e97-230c-08df2dd96fc0 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:41.7970 (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: 8gTrJVNSdNSrV1oFp6bshDdHDJgIaK0cSnQF7rzoIyBoxjeLloApFH/8mCHFKbIWaR8cc0LbrsNyUQEvv08obiR6ij0WM1pfPwSreJAr0LA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-ORIG-GUID: oxMzofU_jbYfVCur4kRFq25ggyCPCFsg X-Authority-Analysis: v=2.4 cv=HYGB3SE8 c=1 sm=1 tr=0 ts=6ad607d3 cx=c_pps a=HzPr6oCfsVO1Dm+K1Iow0Q==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=A7cMN0_0mIGH7w_oRUwA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-GUID: oxMzofU_jbYfVCur4kRFq25ggyCPCFsg X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX5EGJous4Wetm X4ZUdoqS1fOtRbiM/Z5N5lxcZl8ijC1H7DFuraSLmkg2yYly9gRrmKHj5B9sfXnlR0tNBn9KH2u uU57zDVXOIl9HizGfPZ+h+7vm7VWjYk= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX4Ba4PBjsU9/y sWJctk3i1gK84ofezgL/MSlBDXgKlfsTbqUVrk7vC4t1FktYhYuHCXjX+/ryEZPvsLF464kdfbA HNcfF4VxW0uaUmllfTvejhJLI8X+oKv4hBEWtAlMOST7ez46pxPeb9n6pGXXHhXrK7nw9J/rA1Q TOp7Wmig4m0pZeqWVI1qju+b6nlzfXym4YPoha5BPC9UHk577wPwFC1p+gf1XKUzG6JTtt6B0Cj 515Q4+hEQuTsnpJWH56ZSOquipYSG2QF4Z1buWySNlTfqGHrRaTtUAa3btCysTDeW3StI3KS94j o1fglNii3ST8aDOJz6041w2lITZ9bvZPYsw16Pm4Kz3KvF3ROcGARCq4ll26qUc/WscZwYSlqJm Iap5MYcPW+HsrUfvWfK6LvDueX57PErBgKlV9qgpeUP+ItK1PeP5NOmWrABQvKroNrSvCcxR8UN IT99GMg++DKeBfxYNpQ== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792411607-CD14E87B-94C3D63C/0/0 X-purgate-type: clean X-purgate-size: 5964 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 Reviewed-by: Peter Maydell --- 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 87ccd55a4d..d51a7fde32 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 I8259State I8259State; @@ -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(I8259State *s); int pic_read_irq(I8259State *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 dd255fac24..2807409eff 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 48282db58e..8cea5fb12b 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -223,9 +223,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 */ @@ -246,6 +249,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 d713795ae0..c3a3199b8e 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -540,9 +540,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 */ @@ -563,6 +566,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 5fa38fbc5f..684290fb2d 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 *cs = I8259_COMMON(obj); - - if (cs->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 Mon Oct 19 12:06:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454221.1667827 (Exim 4.92) (envelope-from ) id 1xIm8j-0000Su-U6; Mon, 19 Oct 2026 12:06:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454221.1667827; Mon, 19 Oct 2026 12: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 1xIm8j-0000Rz-N1; Mon, 19 Oct 2026 12:06:53 +0000 Received: by outflank-mailman (input) for mailman id 1454221; Mon, 19 Oct 2026 12:06:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8h-0008UE-Lw for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8h-001IIn-1b for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:51 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607d9-2eae-0a2a0a5409dd-0a2a4507c346-4 for ; Mon, 19 Oct 2026 14:06:51 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607d9-b4ea-0a2a45070019-94a39b0c14f4-3 for ; Mon, 19 Oct 2026 14:06:50 +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 69J8Oq051634764; Mon, 19 Oct 2026 05:06:46 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021089.outbound.protection.outlook.com [40.107.208.89]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8bckgcp-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:46 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:44 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=qMHM6pEmEweBChs82szaxAk8IybJ8PAiFa8eJRnz4 zo=; b=VIQGO/AZfLGAM6zr0nYXqnq/nE+nTUol6Sa3jIOUiWP95ara38PI2eSU8 80xJgsu5laYdysWwRRx/7cmJFc+phskMdIeXG0O0x44vB6VpISBBP1xxrLabccuN 7B7Opk86tXJWWQ8ms1yqDN7TFcbk5Xfg7A23dLol4P6DA8Tv5Lpl/OcUmOhbR4mX 3KHemcL+1KFuoddIRW1+RO8TSdppyhFXVKU6xkc2YDumvSSOiOmNbn38aW5u4Z1u 7ZeJdYWm0lSVvtnqYHOVZM1x/ATeiKcx5B02XFj5jiRPC+whfDWj5DYwe80Rkz+W kPch99BoMS+wISlEpZmLTAHMOQ9BA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UQX5tKrmyZ35Aj/cTBGgxgBA+t3Vgi6/WaR4qPBjoS98PbPI13QOztUAH0IMQDBru84WKxRBJH1UTZWnujSuiudpJ+G6P8mgx9xT1M+Sril/+UQOxtuLwM3ySB4+lX7vO2AXBl+6Sz91JO2vfXjhQK1R70vU5X804TtfkhSeg+CYlJSNguRRrLfKL+dHLjpkKmkk2BFYOYQrOC19pVYBa7j6Pw6Tgj+FHlZGXbSoIN78vLhZ6rwH+3lEmS5Qdf04VQHIKW9B3hkdow4Sp5Q0DYyEV91M3I2Ufv36QCJB4DULjDu6tl+s2+7+ZjHhNdzO67OINkXQME6sJtfgl/Rdvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qMHM6pEmEweBChs82szaxAk8IybJ8PAiFa8eJRnz4zo=; b=Z3aPWhMw9dfGHR1O43CxT3fT01LIFRcjCDFUIOCliQCwnQnXfVDO4pblYYEDLjxA/KLXbmttTbaEfycIcj7YTFH7WtfjMn6CmKre78qz0V3SXZrZlMusDiz6rAZQlEO6UQqEMFSvTy1+dZiPo2K66Qy3YwMN+f8sGKVMj6AVpKwHWj1MVbOYrMauwpbW5IyO9DUzXY0ibYlYRyB1n26LEyd8cz2q66EDyV0o7pbPfWiXY088TiwWSqoPxzTu+VUvn5PFpdVlCm6AUAaCAzi32wdMCoOmyzpUNddLQgU6ktt40wWbb0YQXcgFEuL2iiGZGOVTJTew4FAW659COnexRA== 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=qMHM6pEmEweBChs82szaxAk8IybJ8PAiFa8eJRnz4zo=; b=vvhLMCe9es2mOdoH2hPrdFv73B+AATJfTjrBqv5Sczt/Je7+3G7JwGZbCTWmpZsUi5c6BJXC9PcWrD5Qk4J8JsbijXHJFVRoBU2eD044sYHlx+biKzNrgZdB8MvFTYqS+akWKEfxCJA8mMYtrsdaa4nrirR1K0cGIPW3LNdmHs7b7Onw+No+9XOz95KjRHuft8XeIQ4bWG9CIHhO2qQuCeg5eXRFJW/oxZyOGqccDuCmeOE4Gn9dgTJtjtH+vb4qvfum8hRLqNNTnLREVxHlYO5nvIo8OfH6BZs/fbTg5tGSVwLCJL/ZL/3ZTUps/zPTvwqudNT90JckX2MmQBATnQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 26/28] i8259.c: switch isa_pic from I8259State to I8259PICState Date: Mon, 19 Oct 2026 13:04:58 +0100 Message-ID: <20261019120517.1448687-27-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0193.namprd03.prod.outlook.com (2603:10b6:a03:2ef::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: 77c01717-1a6d-4654-1665-08df2dd97196 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: A9lr+kUSOAJm8FYA2RIIXGY0Wa8YJzq8o6CvXiwmFijf83TR5FvrZQXM/CgmNNoV6Jd7O+/rxDwbrfNwMZWD0Wp/BRdeNR+VgeYEYgeBD7yH04hmU5ZeB+T3nOjjxFAId61OloaiIaoa2DP3FVhaXUc44M3cjkmU5WXTWn6nL4lYxxrVQUmI4frbr7LLyn8quqbljN0Md+HOj2Xwh6mBeXgzxvJf+A2/jjmC64SpaAtjVn+153mR9WKiu2JOENYH344sop3dvZQ1I44+K5tPXvD6c+eS2SqC+TFU692KNjz9wErxbo2eDZdoZzoVIOMxJG9LFEDetbmy0ri0Ov2AhbKAieBu8/Ai/LRWiQa0nFrxjn9CLI2KdyPAqxDr2F4NfAClZh1micH+vsF0E6DbfyzxL5O4mViqO5qYHHSvzVpOgTOYp9H44kjoeKn7+Pxt+wOSp42exZFDoawhNFoDvjJ0F5CuvXv5xGN/zT7OwIKRFsjwVKEA6mA6axDiJ1lRc/LyOHaeaFeZjM140vMo87DCrRjuMcnOgB0ihZHZWoUsWtX1iVdGbyZd5LcavZGwqmwhDkGo4xX/2EJ9mptLfB5z7lIbKwC7dQ/Dla0vR7buigE/9L+QIrFN9Gu1DABcVubQIF8VbSGea2MKiPuMwFN55l+iVv77+DSoGQL5JKM= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KUvYU9gRj1MTedK/pIHkbsHZdOZlCkLek2g7xg+8ADmCgsD9OavBHcjv7kmP?= =?us-ascii?Q?WUwmC8/TSZD9/YoTGzm6+UBlhPZSsjXrzmv2r/1WD56PCfz2f7eIdGTMjKTO?= =?us-ascii?Q?UooGhmTAg42qN+bjpO2IL/fwOhQ6Of9TfCqzToFghjaVmdb0+VIcCHQ1TbtV?= =?us-ascii?Q?8JJWVrvYPXlrcWd+RizCLws7EACHxYy61SBp/g6bxIzIbthn9yO6EBRorXzN?= =?us-ascii?Q?f0z6yazlCFTbOBvpBGVq89Pzv5qTb6yUqXg0G1EIptrMdXnkR9cm7iX+UTDn?= =?us-ascii?Q?Fzxgnov1hK1U8yrKfG2s8UzJGFbqaPH6TrUUCCkaeXmF9MAUiHCQy2QQhDaW?= =?us-ascii?Q?bOCKYbLke+aLtfm62bm5pwLGqh99C5agJmB8zY27tHc2zmgl79/BqW7OKtDC?= =?us-ascii?Q?H8tAOADzBPL9UNypCPyg2V9s3yYSTCV+RTu60XP8GoNZr0//vchV5shRkHkP?= =?us-ascii?Q?r/774ooYIiqrAGRwDXmB5iVIZOmYMXktI/KzpAuFOdKAF4z4BzxYL/2gYw+S?= =?us-ascii?Q?XY9eUPxkXrVYyU8DGc6CPJCC9dp4afwD+/GrAm4dpl5dlvEsNDl+aKsMXcUw?= =?us-ascii?Q?lPCjRm2312FgRzKDr5OP+jAy8KxoC5lxhjOz+KC8StAZ8K1lkwj5vyYwyXWr?= =?us-ascii?Q?FXwb74FVz2aj0QHyqPy/V2uOMniEMtLBvQuiVJbMmFp5/15qMg6YT4bcnF6s?= =?us-ascii?Q?MdmVYwDOYTUif5wfYoB0q+mkQ+JeEFfFQJtKWhJEZHKFwFPLS711IjRTrS66?= =?us-ascii?Q?f0v7VAcRkcmssHgv25vKFTTK0u5qqKdNyfTpnUCxGJBE6zUIvvks8NI+ldZJ?= =?us-ascii?Q?fqkEElhG2gzXENEje+RKY3GFWfwO2xJTIBAmSxy6IITk+BnBL1f5e8XK91VV?= =?us-ascii?Q?YmGwLOR0eVo3mNvjOQXpzYSWZAB5zRq6bvWshuEkygBjXql5LtTjfL1O6z9f?= =?us-ascii?Q?G11A7qpasE4cwSkZaf5folqrMsPOyAQ8GUalYaF2/cyLrCML0mjsr+g5ZSMx?= =?us-ascii?Q?puhxhOO+J/P9yYF8MQV/ingzBqTz9oPN5UGAw3v1zsUIAlv365gtqWJ3SleM?= =?us-ascii?Q?Tzm/mHYifHgBvw1ABSuaoXnPVjbDxaWQZwxzBjPt30vc44IF5sYX3Csi0CPu?= =?us-ascii?Q?/ozffIZfawlKwwyeUe/duvYoZoKaN+zr5McErIG2J7qQKpOQaQs6+cWgnPIE?= =?us-ascii?Q?hR99+yVuhIiM7rSByDdtfoh39dLSMvporZcBiwpRYqakkAlDir/nqFqC4FHm?= =?us-ascii?Q?6S8yGbXzOqV6CO0kLshfm6nfHygDQSTzOrsa+s1gIyncOpeOmj2Pg9ip3L9G?= =?us-ascii?Q?nRnoDLzNZvdL0OX19ElrGu13duLvnwkVT28YPGaEGa7RePKHA24n5d03iRSE?= =?us-ascii?Q?0149GQDIj3JTf70y4nKE70t8cBTHUMscjyctTipyJp2E3MEm1XCzsSkWQbNO?= =?us-ascii?Q?4WJkQ+6O4qzwm+sE6IGt7JYf3bHIB6oy/nKiNhVZOH6pvWxnR+2Iy7CT8rN3?= =?us-ascii?Q?OYFd4PFY7iFDTYPIWqwZ9Iiz0A+dt716A40FU/TWDLEEF2cjCtykEqQXO6GZ?= =?us-ascii?Q?TXAbjLW6HGYYH5ZUdssYAeRAtIR5J6owXi93uUBfcGn5VeyRVCIGJWwjVvXc?= =?us-ascii?Q?GTmk3Kyum0zppiVSswf6b/BpBZiZW0zvSKaW5dz2kAu9e/3Vln1niB+sN3Ct?= =?us-ascii?Q?eXt0VmDucqoRef0q1xfxR+fXFoGIC7hMg90ohM6n+0SAf4Ft8Xc9I2QC+cV9?= =?us-ascii?Q?pZsp1w4jBz8AgDJHXecm/sL4+w45pWA=3D?= X-Exchange-RoutingPolicyChecked: ThBfAIov6SwxEmtU1IWSxrzMULODTFryhRQnMP98CkI3LMBeNGe3KlVVR1fYNJeGa2V6eLb5ZXlhiy+oqnX+EoTEHfi7qHeiIMvtBgvM0tBmfiD9bveHkwi0rj5QD4t3pJksbgMZwAXwwRvbi7v9cmmw/QiErnaRW1i8Hw9U96AlP2KTDW7nWHeI5UhhtTDXuJHWuD13CXvP65LKZ7jiDDISEUC47qqaC04wCZajKzVaEGx36OhccHx4yyFxfh4F3OXonpgRydGqcWN9n3va73MoMulzpLAE7JnJ77R/rnoZ6QGdRC3ZZtxx6j4DdO8rIzK36MSRb1N48YRLR/W74w== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 77c01717-1a6d-4654-1665-08df2dd97196 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:44.8856 (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: QzuW5BhXad1XnS1RzZQODsNwfH/cSal9X52UWHfF2hw2nw//UawicofFDfFFhJKFVW3J0LoWdjy3pefaT5+S6gZry4vgRWKrDYm7ynfOO6w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX9+k8ku3sSSu1 iiuTjQPsT+besID2LFxiiYRDKNiMd+TYRSMw/+HlguwHoEA8Iw3+6tB0kQ9cQb0I2b1phQuGOyl oUVcZLpvncooMGHrwgtBYxlShTHUCS8= X-Proofpoint-GUID: MpzQRNtRbaVkCRf23UvOOCMY5XI4Wmji X-Authority-Analysis: v=2.4 cv=V8joQuni c=1 sm=1 tr=0 ts=6ad607d6 cx=c_pps a=rgmdkwC1tPsVJMj+r4rvFA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=Re7Oh-p8VE-n4k5LXTMA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: MpzQRNtRbaVkCRf23UvOOCMY5XI4Wmji X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX3wFJFBlK9PAg zyl8OKpxn2xhUJlFdP6hsWt7rF3afagVfu5lMCPJsxsVMgYg3is+M+7XJ+TqNGl0kfbF8Jh0xvI GdelwVqsD+GQivE/4xWtAn+nByfwu/6Fa8eqJs3B8X+/hK0HdFRc0nW3IhcnMuqZH4qzn1Vfvhx 4aCikTEhWjMUY8nhw5VFGvmR4DEtcqpubfJnoOZ+UxHF5kltMRX9LPhYxiGmBLW46+7IJVKargL RaAzFy4EaDjJC8Mh1WbF7d8/BpdsAZf7uMBoBZ0xKkG38EMAdj8Yp5GDpbjbyyLXB6cuFBPIW5E JxcAmcJBMukPtZaWk7msAU1Zc8l0PQzZ5ghN+Sf7jpi9XdHrG8nK+Q6in+tMaxKMz9D1A+rfbTs GUy1y+vGRNiPRDvOunm1J9Ybilyot1drmJst+nSNN0av1JCJfkcIbo31sAz8Jag3IBFWdMG9ce4 Lsej+lAMadCKw8WCHog== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ef75cf/1792411610-344CBAE4-2B3F9E28/0/0 X-purgate-type: clean X-purgate-size: 4546 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 I8259State 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 Reviewed-by: Peter Maydell --- include/hw/intc/i8259.h | 8 ++++---- hw/intc/i8259.c | 34 +++++++++++++++------------------- 2 files changed, 19 insertions(+), 23 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index d51a7fde32..4922f88d5b 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -5,9 +5,9 @@ /* i8259.c */ -typedef struct I8259State I8259State; +typedef struct I8259PICState I8259PICState; -extern I8259State *isa_pic; +extern I8259PICState *isa_pic; /* * i8259_init() @@ -18,8 +18,8 @@ extern I8259State *isa_pic; */ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in); qemu_irq *kvm_i8259_init(ISABus *bus); -int pic_get_output(I8259State *s); -int pic_read_irq(I8259State *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 c3a3199b8e..b59e26cbc6 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -72,8 +72,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(I8259PICState, I8259_PIC) #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif -I8259State *isa_pic; -static I8259CommonState *slave_pic; +I8259PICState *isa_pic; /* return the highest priority found in mask (highest = smallest number). Return 8 if no irq */ @@ -190,34 +189,35 @@ static void i8259_intack(I8259CommonState *cs, int irq) i8259_update_irq(cs); } -int pic_read_irq(I8259State *s) +int pic_read_irq(I8259PICState *s) { - I8259CommonState *cs = I8259_COMMON(s); + I8259CommonState *pcs = I8259_COMMON(&s->i8259[0]); + I8259CommonState *scs = I8259_COMMON(&s->i8259[1]); int irq, intno; - irq = i8259_get_irq(cs); + irq = i8259_get_irq(pcs); if (irq >= 0) { int irq2; if (irq == 2) { - irq2 = i8259_get_irq(slave_pic); + irq2 = i8259_get_irq(scs); if (irq2 >= 0) { - i8259_intack(slave_pic, irq2); + i8259_intack(scs, irq2); } else { /* spurious IRQ on slave controller */ irq2 = 7; } - intno = slave_pic->irq_base + irq2; - i8259_intack(cs, irq); + intno = scs->irq_base + irq2; + i8259_intack(pcs, irq); irq = irq2 + 8; } else { - intno = cs->irq_base + irq; - i8259_intack(cs, irq); + intno = pcs->irq_base + irq; + i8259_intack(pcs, irq); } } else { /* spurious IRQ on host controller */ irq = 7; - intno = cs->irq_base + irq; + intno = pcs->irq_base + irq; } #ifdef DEBUG_IRQ_LATENCY @@ -369,9 +369,9 @@ static uint64_t i8259_base_ioport_read(void *opaque, hwaddr addr, return ret; } -int pic_get_output(I8259State *s) +int pic_get_output(I8259PICState *s) { - I8259CommonState *cs = I8259_COMMON(s); + I8259CommonState *cs = I8259_COMMON(&s->i8259[0]); return (i8259_get_irq(cs) >= 0); } @@ -428,7 +428,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); @@ -442,10 +441,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(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 Mon Oct 19 12:06:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:06:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454225.1667836 (Exim 4.92) (envelope-from ) id 1xIm8m-0000on-EW; Mon, 19 Oct 2026 12:06:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454225.1667836; Mon, 19 Oct 2026 12: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 1xIm8m-0000oe-9R; Mon, 19 Oct 2026 12:06:56 +0000 Received: by outflank-mailman (input) for mailman id 1454225; Mon, 19 Oct 2026 12:06:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8k-0000at-MD for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8k-00EEBF-25 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:54 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607d4-8faa-0a2a0a5109dd-0a2a450bdf82-28 for ; Mon, 19 Oct 2026 14:06:54 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad607dc-b7e8-0a2a450b0019-94a39b0cf76e-3 for ; Mon, 19 Oct 2026 14:06:53 +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 69J8OqJN1634761; Mon, 19 Oct 2026 05:06:49 -0700 Received: from ch1pr05cu001.outbound.protection.outlook.com (mail-northcentralusazon11020079.outbound.protection.outlook.com [52.101.193.79]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc8bckgd5-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:49 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06: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%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=4jl31NceyHhCzS5Gylgxsc0CneyACA8P9yuxjR+0T aU=; b=X3a+lbaaOHqOsdDMRq2cdo83uMJim+QbWNZVvxd2lQPbFTMLFbTKz/G6e Ado9rW9fi6+V4KCZ6tFdM4pTf5xcaUg9R6RPJ78ZWjyCa5GqNfZgmMGcyKsBDrLv 6QcuOdlkTAjE42Fqc03MZqnNpki+13EknYewMIh5FEmftgb+C/J3kh3OsRgHMgiL E/2aicUahqOrh9u/ULdv1sKfyAY7/WjvPdgjWQx9PmIVyOpk2HmqTH7jq8VW/mED 3+BKdnDafqhooKrF3B0/rRtW9edGaNmFdTj/34btG2swwH/RETwchmtnKcCygav+ aFY4BlPqS7tMbTZGt7ccUzKAWYJmg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ebi9EbwD5RpopBlMHgVJyyYG1vknUwzNMqLwldAl4n+bVe5Ycs97syLENPULFdpBd3fY5lgHWOQ2CSdp3MhktsSdjA0RiJRcKVUooAarknrKg1nKoUuTboglbpsEh5uB8yN4zJyEFHT2C4AALSeag0KKe8i29yzrFGFCjOEYJpzc0o2pjSuCR2/zkvailEgApi0KH60YSPlrSKh3La0V1a+MUDfkDgUEQK0I72ixkxBaZbqYS++CkC0yxgicI9e5gyIMjHvDxBpbn/9Cazoee565Qs05wLsi9B5pEX1HrCkJpyKtpA3t+5lus4/rwh7CzMN+wwlNBRWVtRU7tcp+qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4jl31NceyHhCzS5Gylgxsc0CneyACA8P9yuxjR+0TaU=; b=CuqUl0qnj5yaQTYC4oMOW4ulZij/5ehNe5YBjGw9T2G+bQ6juggY4IaOBIr6hN/awyzCVkkxMHKdehWQwUFeLFscJkkPYh7fgptk61jUE3EIK2yMjrwIbHlB5U7ZPfJ4ErqsfyqA3Nr/rtWcolrB8roH5UwrWV+9ixU9kmea8GwxWfxmb/bxCuQWTXH/tzV8BTWsiGimJHpUCmi0W14QArSuSeKBVH80voEsHmM8bpRFmwvKI5eJqJ/S3zEgRFqoeo9jMVBTflVvwfdA7qPSHW8rD+h0+5CtG06Mo/Wkb6Qh6aTx321YZBNs0Ih8C/7LJ6XMDWBJxkvCLJVtqrn+0Q== 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=4jl31NceyHhCzS5Gylgxsc0CneyACA8P9yuxjR+0TaU=; b=U5U92foy9ZqgM7uFe3qPyL8Z0Tx4DLVNsx9FXb23LHYGfBEkcSQgkQSjoOlwEa1cQyCBjkc8VUchob+8fCI0H7+/YiImFahAhRcE3xxoBxF6rWtFPdr9dJxplgXOMapq2wbrArebtWbE8wqPU+3u7oc8dIIGdvhaxpDXSbPrB2uqSATtRKzOkV+cwXAgwcHov1o8DABh3STBt2qX1gjE4VyEqtmQ6EHGatvmghXPUWt0WN3a6ZBe4leClUa2mmUZClaIlwGDroxLWKqYA/kTHx0jRVG1t8qP/bCexvbs97/gtOXlrNc8XNLRDWmHCM6GL1O7x36bh0YZXMNllOiU2w== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 27/28] i8259_common.c: remove static irq_count and irq_level variables Date: Mon, 19 Oct 2026 13:04:59 +0100 Message-ID: <20261019120517.1448687-28-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY1P220CA0011.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::11) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: ca3858fc-8323-4d1a-b15a-08df2dd97383 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: 8/W8vhzQR662qw3wj4MwSTY6gejtZ+jOHJsEwyKUHYcL1C9IK0I5XWjTH/R8r285gzbvK2LEazUZZcKzmz1NxchJorqxThQJHY7IEqnTzNco4+1p+T/aDvnJtDqJA0nLW1gKZwNXCK+pO+8DpEWCbKOmJ1Lq4Nsbv52Jz5qX1KxzEtvpSxVUZFgxjT2AkOGngP5De5Q1sj06C3vHD/9l6DOxrI7aM8eUyPzj6Bt0+vGQmiOfz0GpaTBdLDWwPXze9AQlrvpwrhFmuloH/bbiCTStlfc5oPUjcjOIttRhSEHkczrdtco6N74VVoufxqmxZN+baaAzMT4/8PU9vJ+BOGq6583DP9mX0HoHVI0M+JHMhac9rt6AgtoFnfYT+asTc+XzVM0MNP4OGnihJJoSAee+4LRwruQbu7ay641rb+X0+fyi50Eg4jEo5MqDz+1BI7ilhlSb76+Ah6IURcy0YHp/jDoQVODpUlAM4Wju4nhPllD9/sRTMR8h6Q+hfdVlokt5gn0XZerhrS2uJ8hZQ8JqA2zpsDnNwwESB7Oo2ABRWLeeJfd6VlusnEtH/xymv8D0P9UealLpvCqX9G2lHe8OmvSD4NytkyPO7iwTaaw0kh8PNQKC9hC5WYI3DuSBQcbBCb065eqAebniqhJv0z8bIHSTaXagY+xVTzXLiyU= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2kKcxjp2qYOp3appwYVzTx11dyyAG6e054id0xxVc1Lux+q4Ieegyf+vJhnx?= =?us-ascii?Q?k650k2kU8V6wNXwDHb1Ahryq246+fE0TP8t+Ou1ktE9q9e9oQu9pEuxxbCnG?= =?us-ascii?Q?kI3IQw8CEQKe9k7WEq2OMQlkKaN+mwuVSGBN99HR8XOsEeujPL0CwPKqVaHs?= =?us-ascii?Q?izkwOiyv97YhxKJwIHysXrVbhTFByC4w6asUVO2T6OvJXeMBgYiHnlHuVfl7?= =?us-ascii?Q?Db9SyyHMH8IfeOweefBKTROhyU4MHxiEF/qgoj7U+OJ3T6qgLEexbbACsp8N?= =?us-ascii?Q?ukdrnhQU+AgVzmYwq7dj9d7WcCqDZvbjlJJajwFwOV2cJkJ+JWTiaOp+QoJe?= =?us-ascii?Q?T3IaKv/UjmRth33Ol1c7XrsVVlKDkAdUompcBO07oME7W1o5V/S/5071RSEh?= =?us-ascii?Q?1YdbwnTdaueEbWPCdvOcWH/Ht0xSbuK8s6MXIL70wswZX0gLLs3RU5WwK6LZ?= =?us-ascii?Q?deE1CYBhR//sGsy4voawE6u21HJNFk/Ud9DHDI9JcMkjxnlnMgVbbp2Obr+l?= =?us-ascii?Q?hK5fVY59oz4RCNJE4JCPTZQgCYnKg1WEbNQUH/LOMtNrFjn1Kz6y5rzBeqTg?= =?us-ascii?Q?FdhW6GUvzAonvlX+J9IglnXtbxYldXE0MbO2d0feRcdu7+IUbhwrYEEJH5Sj?= =?us-ascii?Q?WXIw19+yRqtVZAJYS0tWXqHx/u6Ja+tHVv3N9OTpSivVkZOyLAgn6wKfJ4OI?= =?us-ascii?Q?8vwhsqM1skxYuzn6FFxQCEIpcDyQrNwbwMa8K7swPR8TcnG/d9w5xYma/x19?= =?us-ascii?Q?MEKWqBA/k9ciGuIvUJna67+OF7+k2WBWBiDxwZWJdd4BdznZuvhTkxozkYsj?= =?us-ascii?Q?BemDFijgk5ekfuzPW81LAotDyKRV/GwME8kXc7cDjHZd8yLPDrcOZv+AVKPs?= =?us-ascii?Q?6BEntKin6tdJKScAIfxA4SEodhL7hESxucyLzL4q8G4Ss5OGD83ZTpl/QUzK?= =?us-ascii?Q?YF0wycPdpYQQj0HsAPh6sz8XkjcqWebsWxwQRHy/loLlMLGE4uybjOaMmgYP?= =?us-ascii?Q?3wgTdSN6qwB4psOrYbceuGSruchO7WMvhqowjXbRjq7aFbg8fIdZLW71DDzS?= =?us-ascii?Q?7Cp6eNv9rWsoV1Er29o7lAE640/H7+ibX2Gx8+EkrxsuTxxvV4Hq29K7xg9z?= =?us-ascii?Q?GHPF7vvYlr3H3EwBIfAQfLspRXZsZVEr8lzQVKPOkwZHW7y/9j7kQoZjglg6?= =?us-ascii?Q?51HxJ1gNUPOj0JqSyV0RAHcFg8o73cnwkyeozjzUURrz+VHh0Qo4UQ32SNOc?= =?us-ascii?Q?afzOX+oDzbxlLokKRFvC+fc/7abbsl5uL2LDeQeWqS3M8Vf32dXNBFNKvRAO?= =?us-ascii?Q?mhMAhfBXNRXFl3qO9KwtNDtpze8ykQma+9p+GU47Hr0a8YUAbdmtJeeM/ImB?= =?us-ascii?Q?HKkErHKM9/2siX7Cb6sa3Xuen342sD9ni0tzEDH7Zgz4xnZdklOyxdlMoDqd?= =?us-ascii?Q?SUf5t6pgM11c0caureFKBLQ3hJd5d/ekmppD1GKmcpKmDl03o62Km+13oT0U?= =?us-ascii?Q?jqYQvoEdTqfHk4+2t5hZNxNEd1WyUmKXoRAA2ZgtqzJn4fFnN8bGRymoiHwK?= =?us-ascii?Q?rZyKOnWMNuCs8p78PoGZrNxufxTNqEFTlRS6jRnadAeKh7YlfCCOUVI7xlwZ?= =?us-ascii?Q?g58RogVTF8/oEFeGRqN3vYFK4z4WZwNOAc06ptW1Wh0tZXFZwXRb+mEP2tA3?= =?us-ascii?Q?To0JK8W0KoNFYF1XyXYfKqf4i/X6DpUmGlpSX8XgIccimZRmzLusMYVFOnOg?= =?us-ascii?Q?1dVcrDZ8PnWW6nRgpHHtGEQkW0zD+yg=3D?= X-Exchange-RoutingPolicyChecked: wB7qyxuyeVgT84a9gsn/SwFSfqhgg71ue9Df/EZD0Ua7GK8yd0JsulEDq7k5J82I7ChKxRvgcAFiV2mijJ8TfXlQOxT+2brxZQk3tHzD5OM0/8LqQiU2pyHd7dmcJc5JB7yQ6CpSodfaab12qiiJkDbEO0mgudEGr0ONpHjl8AybnUcT95IHdBMMupdTkcLwcWYO1WKwzCyZBTBfG1CSNbD1u6knzcPwvX3yGdRt0f+q36yEH6PutKH1ofCX5bHAHD6+gk0BOg4fRCdNxnFYkzkLalT3ra0MUFMvGYlNOapV3WRYenpFUD6yto1gQ4NUfmbyCwC7AdxIQwf/OKbYuw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca3858fc-8323-4d1a-b15a-08df2dd97383 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:48.1183 (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: FUYUc5VSmhyHELOkDXTFaggCo/mm+E55VzyRK5auerniXZYxB94MafNtGwoM1dM8ZXTqDP7NLtZg+R0ElJGAewo5j+/0DRGqP+0NbmDG0Z4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXy+W//cV7XCfs KEJRWeojHqfdzKrv/ksdYuOXmdSVe3Qe8hhHHz5AibWVGugeAqcqkGc8rSN9z+u+td8D6+xSsAV tw+5jwlkhophCU7qPLlAhovjGWrWcs4= X-Proofpoint-GUID: NkeXy2_I8x0v5qhZFd0Ja9RMaoOLZpTB X-Authority-Analysis: v=2.4 cv=V8joQuni c=1 sm=1 tr=0 ts=6ad607d9 cx=c_pps a=eu25Gv8CuaBvrl3+j+Cigg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=m9Rx451XjQ6kX_1OFlEA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-ORIG-GUID: NkeXy2_I8x0v5qhZFd0Ja9RMaoOLZpTB X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfXyuBDJXKJkBUZ tnexKbRFnkxBmrdLZf04t2TlwTjrj34LFU91IF9mj0gzbjyK4O7Q2SUFhqN0wYsCs//PQWvCh97 /EfVTjiNrJG6x6baameeq+OYuBojHkJXwwpMrs0456NgtxfBoh1UzHpGDuA/HT3PPuXY6M0/PWW 5k8h69P9YZ5Dkoj56iYbxydVaSTJD1x9dAimK3f+92Om2t28FV1Qith9UEw+NBfZB45RYGJ2vD5 9lOl71ab1mYNpBMdrQVpCS6HTH5AhNEDhrteOmNFR39NFRI53p675UfDRoQnuxCZtDPZ5cexlaW rkFIX2sqP6KjViwAjn+erxseom3lg2rlNSJ1avHsiebM0wGzEtQBZX8gtq9ovjpyh92e4hKN2RS z5DUKqf77e8oQ5Xy7SrW1e3C7vDFE5zNJbt1oNM1Ugf7hczAhAhqBaqPkGLYIqGdNK0GhCJwe1A dltEQlxYOinIKZXArMA== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792411613-186CA9EA-D2B9E52E/0/0 X-purgate-type: clean X-purgate-size: 7389 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 Reviewed-by: Peter Maydell --- 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 4922f88d5b..42d6f992ac 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -20,9 +20,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 2807409eff..e0002843a1 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -70,6 +70,7 @@ struct I8259CommonState { }; void i8259_common_reset(I8259CommonState *cs); -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 8cea5fb12b..bf5ae334b9 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -45,6 +45,9 @@ struct KVMI8259PICState { ISABus *isabus; KVMI8259State i8259[2]; + + int irq_level[ISA_NUM_IRQS]; + uint64_t irq_count[ISA_NUM_IRQS]; }; OBJECT_DECLARE_SIMPLE_TYPE(KVMI8259PICState, KVM_I8259_PIC) @@ -117,6 +120,18 @@ static void kvm_i8259_put(I8259CommonState *cs) } } +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 *cs = I8259_COMMON(dev); @@ -129,9 +144,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); } @@ -227,7 +243,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 b59e26cbc6..79b5e603bc 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -64,14 +64,16 @@ struct I8259PICState { ISABus *isabus; IRQState i8259_primary_out_irq; I8259State 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 @@ -138,16 +140,8 @@ static void i8259_set_irq(void *opaque, int irq, int level) { I8259CommonState *cs = opaque; int mask = 1 << irq; - int irq_index = cs->master ? irq : irq + 8; trace_i8259_set_irq(cs->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 (cs->ltim || (cs->elcr & mask)) { /* level triggered */ @@ -224,7 +218,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); @@ -456,10 +450,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 684290fb2d..3bafd81ea7 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 *cs) { @@ -89,26 +87,17 @@ static void i8259_common_realize(DeviceState *dev, Error **errp) qdev_set_legacy_instance_id(dev, cs->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 Mon Oct 19 12:07:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:07:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454230.1667845 (Exim 4.92) (envelope-from ) id 1xIm8q-0001KR-RZ; Mon, 19 Oct 2026 12:07:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454230.1667845; Mon, 19 Oct 2026 12:07: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 1xIm8q-0001KF-KL; Mon, 19 Oct 2026 12:07:00 +0000 Received: by outflank-mailman (input) for mailman id 1454230; Mon, 19 Oct 2026 12:06:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIm8p-0001Dl-Fk for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:06:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIm8o-00EEBF-SJ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:06:58 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad607e0-8faa-0a2a0a5109dd-0a2a4508ccbe-4 for ; Mon, 19 Oct 2026 14:06:58 +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 6ad607e1-f659-0a2a45080019-94a3974448a6-3 for ; Mon, 19 Oct 2026 14:06:58 +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 69J8QSQX3508828; Mon, 19 Oct 2026 05:06:53 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021083.outbound.protection.outlook.com [40.107.208.83]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hc4x43qrw-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Oct 2026 05:06:53 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MWHPR02MB11820.namprd02.prod.outlook.com (2603:10b6:303:2aa::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 12:06:51 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%4]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 12:06: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=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=SZiLewJ31Wd7JJfgU0jxATyKUq9AnyFgswSLPaZDy F0=; b=dqjQ1RYgGFuytr8VYNLkAFaoXMl3TnF3/I5eu2iBSTYxj6YxRPcv6FlLL Yjtw+DUNBdcmkY2PT7iwejzx9V2XCZckDb/kppuppgSCyDbpB202ODHNG/VU15Zs fi9haNZit8QuE8KVAZgO8Cc446ay2aDSdqzYb1geT9+aEBwZqv86cLWbKIk2MxzE FLXqlisAQC2qXlT5kzaING2+I6CW+DABySDyk+7SMNkbTbnnLj0kzgrkW2H6Oy2Z ypjF7exuByOnJqwKG+27pMIZ9aTL+o/TGni9xt4rQNY35iFxAd7mjVCmqSAaOiUD WuC5yaZp2IdgbuRAsMjXG3DCMWDjw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VRZQ8C6fAfyy96MoxUzpVha+2XHULH0uU93VZD9XPIOwmPE4UYdFtjDdf12FIS5g7FApd763OcEdQ/OMTLesAtB5EqJivH5R6k/MtzJQUNgJhE0dZUz2602Rz1XYAGTsxCTtPBgKEEjs0YBMFQs+He1qLvKdWh8ADqumm2ws68kmm82KS750r8XL67xuPDxjPDC/3fktGFvFBpLC7OqsYBrLgMSwDO/p5asi7mS5AYtO7mp7yq5+rcICC8Jz1lYdncS5rovcDWbq5a053GtfDTqs+x+pZnPSr6SlHAt5JtE+GfnaOcUTB436CkbtFxpuyKFYZQJsQZb9sx2w8DREbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SZiLewJ31Wd7JJfgU0jxATyKUq9AnyFgswSLPaZDyF0=; b=yZSx9MaMomJeipZvKrHJFLt9y62Gw3HnNTiSVbW6K0qXxW4mdZ1gVKCUFdgqc99IJyVbg2pqgI1Jpn3cmiiHI1nhQ+69zzxm6G0WholvLcP7qZkR7edponaHA5xCtL2XcTeBjDd+Lcck1V1ydiT9e2Sj1at/ecLTp9w6yPVMwwnKWleaFdxe/ZZry3JOAzt1h7QeMaP0lz1P73Mc2SjMbfIWm/zgSwSGXEj0kHrZsLihSel11Q3C8fq9rKRZxZgIv4XzOyXNIWAua32dsg1IX0Zm9XrhwvKAM8K3y3b74tNUjn83p4umlqT6Bob5irbedavlwWgvxjBmgwF75EqOIQ== 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=SZiLewJ31Wd7JJfgU0jxATyKUq9AnyFgswSLPaZDyF0=; b=E5OwtLC5fUFO+JZ/HwzAPNhK5CElp0oSziLEXPiaZBTCsM5xMhKpBkm6n5cL0zAPeYporY6WhBGhEqa9mhygt102PM9SU7/4eEmqLJcKK1iLxsWUHIv+6zeqGpK1L/qF9Wsl+BwM5wx/Dh5WAKyHl7BgrS6zRze1FElKwnNqoHqyHWZBQEXBKtQJugsinx7rRIIOUjPH5Z1pZ/+hnJUxLz2lXaLi6bHlQPUXRDLfStn7w9peUNsIPCJX45ndjmaxclmlGWQPjkGUSwVSRRl4htk1j48QytEuU874hOawgmh5U7Ufa+rpLeEHtRC9jTRKsljCfS9Eo9uIZxzSgnfZ7Q== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; 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 v3 28/28] i8259_common.c: add missing 0x prefixes to "info pic" output Date: Mon, 19 Oct 2026 13:05:00 +0100 Message-ID: <20261019120517.1448687-29-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY1P220CA0007.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::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_|MWHPR02MB11820:EE_ X-MS-Office365-Filtering-Correlation-Id: 461d40c1-2576-45d8-1d94-08df2dd97565 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|261009223027099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: 4YaEciYVjNuTGnSbh+bbPombjnODIe1YZ+9tyI4YjtYjop5gJuVOGua25oQ/5+tmj8pJ3ataCcu0Af9nGfb7P3bscC9ZTWqs3rTJMSNhwotqveb20xOQYtr2Yu4VkhH8xWHQNzw9Pe5C80Cww0qvKyNMHjr3JMSj6uuufaAX3efH/DxxHiRrK9OSo6cEfSDK1WHIDZ6JwLxao7U2aVh2jP65La+iPVDpo3TunwB9xdLxnJKPinyQmpZDFTsPTuZvewLg5HhkXbS5VjTWaZGZ8hkSS5EXTSG7N+7OXmUF+8e9ExRc/zneIN6UHNb8mvttWJyjWyYgo2COCgbp/T5q0yqUXUeoOAosJ56OIbo75Oh0fH/lOaMFg38Ge4Sgu4Z85dJTPhUDU9gd3lvJNK9iHGOl7N5lSHlK0oMNTw22Zd3Vcantp1oT1ONBzOAOECA8oo8R1r4m7Auk6FEFsqWgO5JmO6k5sHND5QBToY/GFn//BvXlUI0bUufkTAuVMvy98D/CR2hVgf0vmTDkBPz0GsqU72r1fH1jwzcJM+ff/4+nYIMAYBVp/8IcfdqgGdjlIWK6XtJ5DMaMz6zW3dGmnnjC4V5ZxR1oa+sXeoJhYqXDsIXhK16hPVQzy5NScs9Yjq3czKY8J9/VJeMh7hr0S/1oIGlgmsUctTuHgMNbnsQ= 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)(1800799024)(376014)(23010399003)(56012099006)(261009223027099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?MGL4eORQGFRSnqXbfB/8polufm3OvAZm4BwI3SeFxTRDFWPv3NPUB0bjcvBx?= =?us-ascii?Q?+HYt/GlF0ZctavCH0stbECVKmig1r0NtFNifHTnsQG/03OJu/RhkWcDp7UoH?= =?us-ascii?Q?1mmieqbp0yPf4xxnTHuQYUPao26iPCJE4QZExKhNAM691tfIluQD41VJplcg?= =?us-ascii?Q?ImHhMtgMDfKpvpiEk7p20B6z2zoyRhurI7gVlWtVCgojMl8sFw1v2c6/EBow?= =?us-ascii?Q?3SDvSnHoPFVF1IRqTsTXh8edr01YeyyzeTPSY7biJ+JYeD8ZXs8XGEJ49ecQ?= =?us-ascii?Q?etBAg+p0cMaX+akv7CwjahayEdR2Z7LDXSiPAIaYFImy5/7G+vN+BWV6/9+r?= =?us-ascii?Q?XMLtVM6E5KohhIUZ/B1UxDmLBvTiw+thA8BwuxtlXa3GtBPaKFg2wg8ZzrCM?= =?us-ascii?Q?/fNnXq3G1MXv74taEtUAh7KYBQTJsGpe4W+ccFAwW0n3voaDFgd6JeFw6/ry?= =?us-ascii?Q?SnXlavFNrQQabafzyH13yrSdkZkD1JTA4WaLoXhPLYqdPfysgu1nvzrbYyr6?= =?us-ascii?Q?a0AbWuiKGbB3upwJrW322nPiiKVHQk7f/N2xw5QQHstnPwyd3rWsXcQpmMWT?= =?us-ascii?Q?gdS7+09y91Z4wpOeukQPRmMgnb9v9jpo62J5SzENTl0B3br5tIFrWBzMxHYK?= =?us-ascii?Q?o9zW9Q0hbbc2RlOQv3GYH4SYGFepoBM7iiIPTrQ8op+DNP10iLHToG7um3cn?= =?us-ascii?Q?SC06k3MPUCBBF3zNk8qPtcOtGT2v+mFbuwfzMc0EmxUmiJ9rKUIFzgRs+EWS?= =?us-ascii?Q?NO49J1TJ1Q/BlIHbe1Tm98k5AU628NlWZYww2Jt8B37HTlHzL5Whhg29DotI?= =?us-ascii?Q?CgIy147t1aSmghc/F9ALRqSgiYzM38I6C4xvIKyU2xTZW/jKfMLnpbA2zCvV?= =?us-ascii?Q?mUBxbdw4bMwbrqX5ttQZqMNxZnWtI7Qfjsq44TvhlbMyejzijlOl3ryNdmJN?= =?us-ascii?Q?bVrVymdFm30Q2vAPjR7oOtq7Rfv/c/H/Sf4nwTLDagNbW7/LL7yDm7UI/KMR?= =?us-ascii?Q?36AvNtAHlmRd1skui60ZhBJuH8H8D3KPtT0eYgOx9uaYWu43K860imI6SCXN?= =?us-ascii?Q?CZ7zrw3K1H6akAUslMP7sBpHV/3KAsi24jDm4w9/K/bZ1xYZm4dxePsPzk+E?= =?us-ascii?Q?5bzQ6BQ9M1Mock5mvcXtxlsC0Pu2asWkQbH3cy/kEa9pUkX6PKZu9vqLBdNr?= =?us-ascii?Q?6P0u4C6TVPe02gdGUOZQclpE0aeB50xfA/HPNPjQ7mDhnMg4PhOTnhrkvwvZ?= =?us-ascii?Q?frK/s6PDA8JcTNqiZsI6c8sr1b7palxaVznIDIdMq13euWOxc9Nv7xKCDsep?= =?us-ascii?Q?AaU2QLrK3G+yfeJDO+lleFN607TB3iaPTzK/nVudeUBwrBOW4pRl8fh0Ttpv?= =?us-ascii?Q?pcQ7eTouj/9W3+V87mQfgLJWcA8n/3vLjqA0sPzAbg2vzpxBTDdmDBrUmypy?= =?us-ascii?Q?0rbcORsU9zGORmAhkcKfBSxnMPpctLX5Q2gOU+Z16YR3KhalPMNFnUFpX54x?= =?us-ascii?Q?Ab/32YQFdCUhnKnYpQ2X0+g/5tm6mL5NOsTUCXEAmdUXdEHNAeckKyUswRGB?= =?us-ascii?Q?4Qep6vt4i/2Q82nYAdZUhVmGG09S6UM44LTkTZpwDW1st9j/GuH38Db1cPLr?= =?us-ascii?Q?MlDmnCySPdDfH0O/WD2WS+V+aVAEUlhSTJWpxb9toQGU/egyP3/CrsYZx6Je?= =?us-ascii?Q?WEH0r4WVgwj5ctaqnSOO3ACoqc82Wz1AJl7zF7CMBYTEYQLsjoAGF2OMHmVn?= =?us-ascii?Q?2lZ613Se+0qsoBmAYZRjd+k6QX2FsrE=3D?= X-Exchange-RoutingPolicyChecked: gSBtdlG2V9SQS/4rjzN8f88aTT5FKmcRNn00l6N0PU+fIk4AmcgQ8nfiEb6w+TztaBnSl3P4voyGGUokjVWAL2dqRe9f6kBaCpXCHPFQzKfP7gJiSE/nZ/6huN/7/tqOL6MuvxuBr7Pk6/dRxyPp3QpNZYu11SWxhUPTyzirOOSHN7Tprbcns2LGurZUK6gd3e1XHqEY6b9TOWsAkert1Kq18KN2+zj90w0WIPYa4JKvojsMRHNpz44JqhyiAhqyEDRQtg0y2T5wb7jWUl7FNLm54+xldaVHW0EfUr+oOr8I0prrLjoDTEU+sdQnKBry2rvbYlooCtzAXKJ5guj1VA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 461d40c1-2576-45d8-1d94-08df2dd97565 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 12:06:51.1907 (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: d4KDtwg/z8YNr543baV19SftsND+MO90+1SSeAldTX4Q4YbfrS23B5NXL61IUD2DTaI8hUn0j+EPaNY9EgIjXQHvle6qJr56+4bO0T+Ygz8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB11820 X-Proofpoint-ORIG-GUID: 7dvhmcvLOxLDbKaXDcl534pefhzMiX5o X-Proofpoint-GUID: 7dvhmcvLOxLDbKaXDcl534pefhzMiX5o X-Proofpoint-Spam-Info: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX4UaFWQehI5z8 xalCs1udqy5zLEisVJxm2SlhvnGIgPmkeHKX6r+6eQi4PYswI48s/N+IS6LE37/ExLrJG15Nq6b vhVE2+0OWAOA0KCB0J+cw/7UpqdaD7Y= X-Authority-Analysis: v=2.4 cv=DqHDa2/+ c=1 sm=1 tr=0 ts=6ad607dd cx=c_pps a=JzGR8r3o28cAtrGeABx37g==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=4lKoNvaWMPz1F08twPcA:9 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDE5MDA0OCBTYWx0ZWRfX2jSHLgTU1Qxp NV8XfamzJQTS59ywkTcNjGQlxP8ETsnbM7Ukl/U60JK1jD/pSoiQMvzsVHdVbhL7+ZY3IO/ZEPr uJlCBu3jbhTVDGe38lt89nfOq1CHPv4qmt17whpcZDMkkZZC49p7SYd9pJph1oGq/wXAGk1PaeH 5cTOFWZd25wZGScNMYYKq+S3KXLoP6qL2IqaMh4cOUPV6kudXb96DMbaCWfvt0IocI0ARUVZrof DhGLhAE71Tm+GpWKtNZEXOWJHH+nWtCDTkKXiv+s05oDc7wsLJhwpfiS1SW1ecBnESv6W2S6Yk9 fEPK8uHNcn8eYHYuHD63hqBK78hMSUf94iJQ6JFs1iVvrV6PP7NkPm5NvAnJB0E1k57bTN8nHiG EETJ6RAuc6AJlmziUj8jmMV1yIR106iB6mpMHPRROKxLrDuyohZncFnh7Bp7va0hYVwGNOBpwdb SObPMy0d9fKlcMjlaoA== 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-10-19_03,2026-10-14_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1792411618-DF6D687B-3765F698/0/0 X-purgate-type: clean X-purgate-size: 1201 This indicates that the specified register values are being output in hex. Signed-off-by: Mark Cave-Ayland Reviewed-by: Peter Maydell --- 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 3bafd81ea7..ee325a659a 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 *cs = I8259_COMMON(obj); i8259_common_dispatch_pre_save(cs); - 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", cs->master ? 0 : 1, cs->irr, cs->imr, cs->isr, cs->priority_add, cs->irq_base, cs->read_reg_select, cs->elcr, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 12:12:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 12:12:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454306.1667861 (Exim 4.92) (envelope-from ) id 1xImDy-0007wa-NN; Mon, 19 Oct 2026 12:12:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454306.1667861; Mon, 19 Oct 2026 12:12: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 1xImDy-0007wT-KU; Mon, 19 Oct 2026 12:12:18 +0000 Received: by outflank-mailman (input) for mailman id 1454306; Mon, 19 Oct 2026 12:12:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xImDx-0007wN-On for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 12:12:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xImDx-00Gh8i-5A for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:12:17 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6091c-2eae-0a2a0a5409dd-0a2a45088550-22 for ; Mon, 19 Oct 2026 14:12:16 +0200 Received: from [209.85.128.174] (helo=mail-yw1-f174.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6091f-f659-0a2a45080019-d15580aec8fd-3 for ; Mon, 19 Oct 2026 14:12:16 +0200 Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-8b0a28a720aso14608057b3.2 for ; Mon, 19 Oct 2026 05:12: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=linaro.org header.i="@linaro.org" 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=1792411935; cv=none; d=google.com; s=arc-20260327; b=MLlskiuAhfN4Cdsr3SH8WqrH2m6Jx1JByOYAO1LquJNZkxiJpjJ6pQ+ONPY/6iuB2s NJwGd5Kv6JUmp3WPmfDtlkMCD5TRlDDBV5MXugKSVo3s7uC5T/PhDpzqLLpoZI+y9ijM bNMrjrDj2ShQ+tosoP6I3a8pAV66oYA6+ibFWLuelx0rW2FQ07wg24vKd3qbN+mlj7ln KYEpKfRDtjzJ1rkeLyCDryoGUHqTqj6PnEqza0oXbKRR9SWqav04fef90HGFSvFlL2E+ 3iWuJf5GGMxyII+0sLCDui5mlTOzj/LWNQN+6R9iW1MXzL7pEfmcvHk5hqVcKB+dm0OC EKwA== 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=7cmhy7Rroz4LNmdo/2C48BjcF94jPiYFsUptYORfGWk=; fh=6mpZ5wFoQQyqlzF5elRrLGZpMMuDqidbHG55QrNLb18=; b=pSYlVuHK/ZETwrBDDSOhJq/PmauBDhLWYhL0nSQsPE1TkGKUNmneW5RjHzcRocH2tZ l3ToArweqtPKA6UrYzmIp7SBJFVFnBR/uro+O4/ZpapxPX5qwGJLwaD9zLQkaP5t+44i uGEAEb4oUbO19Duuj28V2EYSiKEczjKas4AEJyz7L702ChkXHmfzAsl9mTo3fpMAQBQj JWC0hdjCDUufFdyI5xb5p35XDfFjHINqQUBPrvCl3brM3z67gv+NhOX1IZXV5CRoQaeq oFRf3uFT9bZRSsrd/g4/vhHE1r7P9FpBAj8Wk6AbGTOrAKbdU+ECjvBKG9l4QL0iUWBq HRVA==; 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=1792411935; x=1793016735; 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=7cmhy7Rroz4LNmdo/2C48BjcF94jPiYFsUptYORfGWk=; b=whYfNmJiXyZHUkai/l/mMaE49d2th6lkR9QJ914E8She8vu2NZDG5f1MKO7Saa92QN KKCCaitjngMkuYgnc1Ynh/4eYTG1F/2dg4aPa8w0z29WFzCStS8rPMfko9Qc+DtDINa5 GQgkhGYxdZKAwL/PHPgc4VirfV9Uv0oYI7IFx4fmvC4nBgD7W1PopAgihF19+mNs65uR 7UILfWzXNg7BUbZFnzhVzfFjsiSJwqBp1vygO5e7lbuSE9pBYytQlsNYJGM9p6QxhpHz U47+j7QReRZsjS+f4rJffb0Xpj6WnUXCN5ngZ+/DY02hN17sZ7nStYG17Nl93j017f4q cTKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792411935; x=1793016735; 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=7cmhy7Rroz4LNmdo/2C48BjcF94jPiYFsUptYORfGWk=; b=SaMAcq1/er1lv1zuyE+Rc44sOn0rMr6z5hioWGbZWE3FKMOTiU3w1/mhynTyEx+LHr 1kVQgY9ej8psjKJVDWGxHMLJhBLEbTkWpIXpG262UlVaPy3I8nBhTdYz6NLRVManBchb cMNX0X6QU4voxt7Gi1U/Tl+wKpvVx9xKG8pcZYjofliY4nsCHNok8x1UZquMGqDtbmnV 2lgiSX1vxTdLN3dN51S0I7a3K63fVh7el3s6MF4Q6skAFhi7/Ww74XmAQaJzR7tBAVf2 Md+RgVXMT5AtwpM5VvqZHkiTvkeJfG0q+LqNdBkj79dHnyxDgmCGQoQg2MC0Bt1nWN0R /Yrg== X-Forwarded-Encrypted: i=1; AKwUvBxzuX21I5BgqecKPMHunMQFzeb09s1yX6hWzI20yAuAjwPdIbTX2oP6L2/9xRt11XkL/WsCCtzxdGM=@lists.xenproject.org X-Gm-Message-State: AFq9FYLyxxu9utmwQAECLVGFcenKcOSjKBqiNZJnlLDT/FSQn66aCklR pRzcQxZy+kNFd9RabfFgo0dzyh2nnfUxUMEmG9E2HMdeZsjxUxBeN5gN2h1r5cjpg+W0wcwX/XV lGwMOa654Iwi1qX9T3JsqV2FbN251rcGUhpmZFfGlDQ== X-Gm-Gg: AYBFou315EnpEzBFq7yGhLs2xMSyKZ0YwxROshbZdIIYKDkkkOlNzdn8KaMEssRvlAh mTVzUoumwODjsiqoJZe76ZcNSNaBmMab0RJVuIsEAxvT8FlrOFfTxfifsow4RdbkTAzKWCkzgiC p0o2AcbSHwR9vfpt/BJFk3lyNHKdJxgejI1WNabTBmxL96dKqhqz8a03UL3XusRIouoFpysTTaZ fLqmW9b257LVgLOQbKXZ+GCJSU+Zq/1iqcly/8d3Loxr5PfMBiG/SARTg0FNWqgZYvopiLTf2wS KXLr75KWXzMnno3qjfULpWKMP7FvLWELW8WpJV7t3JFt3mjfJipJ9oNNFnpX3w1cTlPI6Bu5Kqv 7YeABAWEQ7/MG/GbNbL+YmfdQelwDQqJshn/exf6MSu9Us4ey2w== X-Received: by 2002:a05:690c:a6c9:b0:893:44af:ceaa with SMTP id 00721157ae682-8b0f205bc82mr18570277b3.5.1792411935218; Mon, 19 Oct 2026 05:12:15 -0700 (PDT) MIME-Version: 1.0 References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> <20261019120517.1448687-19-mark.caveayland@nutanix.com> In-Reply-To: <20261019120517.1448687-19-mark.caveayland@nutanix.com> From: Peter Maydell Date: Mon, 19 Oct 2026 13:12:03 +0100 X-Gm-Features: AclHuK8ZXrS7z7rNR5xPtI86u1a7DgqF7yBwPx-IzPuf4gXWad_LCi0c6yZfuKo Message-ID: Subject: Re: [PATCH v3 18/28] isa-bus.c: introduce isa_realize() function To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c1860d/1792411936-CC37587B-50E5DC14/0/0 X-purgate-type: clean X-purgate-size: 486 On Mon, 19 Oct 2026 at 13:08, Mark Cave-Ayland wrote: > > This is required for implementing a container device containing one or more ISA > devices to ensure that the refcount is handled correctly. > > Signed-off-by: Mark Cave-Ayland > --- > include/hw/isa/isa.h | 1 + > hw/isa/isa-bus.c | 5 +++++ > 2 files changed, 6 insertions(+) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:11:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:11:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454330.1667876 (Exim 4.92) (envelope-from ) id 1xIn8p-000722-TG; Mon, 19 Oct 2026 13:11:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454330.1667876; Mon, 19 Oct 2026 13: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 1xIn8p-00071v-PT; Mon, 19 Oct 2026 13:11:03 +0000 Received: by outflank-mailman (input) for mailman id 1454330; Mon, 19 Oct 2026 13:11:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIn8o-00071m-Kc for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:11:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIn8n-001ZwX-IQ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:11:01 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad616d7-e002-0a2a0a5209dd-0a2a4501d4d0-36 for ; Mon, 19 Oct 2026 15:11:01 +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 6ad616e4-5984-0a2a45010019-ac6904fe95aa-3 for ; Mon, 19 Oct 2026 15:11:01 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 924046020A; Mon, 19 Oct 2026 13:10:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E045C1F000C7; Mon, 19 Oct 2026 13:10: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=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=1792415459; bh=sQ4wV/CtE843TsaJyn8NdxjU1otXO+lUSiOR4zR4+6M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UYYhVV8DRwSugxc4w9TTb0o/rWDNMV80kuTV12atH3lBKClROKPctzL7bZd9hdFgv PfWhK+tqVWRVA7qQkMj7dT0dnWY0hXHvfIgvLn8S4zOeBl+0okkfv7UJGsT9ZK+x6J U3DvNv+Ss6hZiw4sprDxO9KEs6F6axzzZ84A2hpzBy9wwYEzr/G1ANlH5AHofU6Tiz Uy5kF15EDPm7FE+G0xVDrufXD7ZER+IyTbn1RCyhJvJHjP5VxCxTbulIjhEpKg1U1Q KtgogEtCjb3O4RgR5JeRmDA4jgOCJgFdhH96o7W3KYEtrATjxWWPIzXGacLidHxxvZ 5imvBcCnwnNnQ== From: Frederic Weisbecker To: LKML Cc: Frederic Weisbecker , Marco Crivellari , Peter Zijlstra , Phil Auld , Russell King , Stefano Stabellini , Thomas Gleixner , Waiman Long , linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: [RFC PATCH 41/49] ARM: xen: Move CPUHP_AP_ARM_XEN_STARTING post stop_machine() Date: Mon, 19 Oct 2026 15:08:48 +0200 Message-ID: <20261019130856.49711-42-frederic@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261019130856.49711-1-frederic@kernel.org> References: <20261019130856.49711-1-frederic@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792415461-C5146757-C2393D0D/0/0 X-purgate-type: clean X-purgate-size: 1718 Between CPUHP_TEARDOWN_CPU and CPUHP_AP_OFFLINE, stop_machine executes all the teardown callbacks while stopping all CPUs in the system. This doesn't mix-up well with running RT or isolated tasks. In order to transition smoothly from global stop_machine to finer grained synchronization between teardown callbacks and the other CPUs, a new stop machine post function has been introduced to be executed after the main one with IRQs still disabled while other CPUs can exit stop_machine(). The teardown callback here simply performs IRQ disablement, which can run concurrently with other CPUs. Move it to post stop_machine() accordingly. Signed-off-by: Frederic Weisbecker --- kernel/cpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/cpu.c b/kernel/cpu.c index bc06cb1f0282..8509c6377a61 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -1275,7 +1275,7 @@ void clear_tasks_mm_cpumask(int cpu) static int take_cpu_down(void *_param) { struct cpuhp_cpu_state *st = this_cpu_ptr(&cpuhp_state); - enum cpuhp_state target = max((int)st->target, CPUHP_AP_DUMMY_TIMER_STARTING); + enum cpuhp_state target = max((int)st->target, CPUHP_AP_ARM_XEN_STARTING); int err, cpu = smp_processor_id(); /* Ensure this CPU doesn't handle any more interrupts. */ @@ -1303,7 +1303,7 @@ static int take_cpu_down_post(void *_param) enum cpuhp_state target = max((int)st->target, CPUHP_AP_OFFLINE); int cpu = smp_processor_id(); - WARN_ON(st->state != CPUHP_AP_DUMMY_TIMER_STARTING); + WARN_ON(st->state != CPUHP_AP_ARM_XEN_STARTING); /* * Invoke the former CPU_DYING callbacks. DYING must not fail! */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454377.1667946 (Exim 4.92) (envelope-from ) id 1xInlX-0006i5-BF; Mon, 19 Oct 2026 13:51:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454377.1667946; Mon, 19 Oct 2026 13:51: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 1xInlX-0006hw-7Y; Mon, 19 Oct 2026 13:51:03 +0000 Received: by outflank-mailman (input) for mailman id 1454377; Mon, 19 Oct 2026 13:51:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlV-0006er-Dd for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlU-009usr-Qc for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:00 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62044-8faa-0a2a0a5109dd-0a2a4509944e-0 for ; Mon, 19 Oct 2026 15:51:00 +0200 Received: from [209.85.222.177] (helo=mail-qk1-f177.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62042-be1a-0a2a45090019-d155deb1cc65-3 for ; Mon, 19 Oct 2026 15:50:59 +0200 Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-93f1cf92c9eso224759485a.0 for ; Mon, 19 Oct 2026 06:50:59 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91bcba3d5a1sm97403096d6.8.2026.10.19.06.50.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06: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=1792417858; x=1793022658; 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=j9xcHh2wY++h6+R9ioq32anwJ7T1kqXqVTQttxnVock=; b=OD1qlKc8Rmz9yga4pK6YrfCksB6tZAO81b0koN4FZ87rN8nWx3R97knMtmIkVKn8tu G3JMySp2QqPhEAGUow7MKeNxo5A5ekZGade0hi27owWVrTA06foh8crkgfJgCWpQXuzO er1MIjOt4aFcS07jZna3TN+bXUiVB/wGne663U/D0/vYCxT1sV2/rRdmwpjtctR16/VN o3CPdAWgesyg42sCEdxWuOBOTFEgXUyhqmKauzZSsAgyw+SGa0jmsQe4ktZcX4G7Xf13 asXRUD0g1zjKNJ8VK/HFFFmNfEjYQCHiXFTyCVMcDlZKysyZfGmR8y1HDllGBlfElLAB FESg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417858; x=1793022658; 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=j9xcHh2wY++h6+R9ioq32anwJ7T1kqXqVTQttxnVock=; b=XBounGFZ00ZQaKDsk2F2qdtfGCTD5iBiZ4KfwSY6c7LRWtjZb25p6AbDAPCpf5B9VP 7Jav5pPqycJxJznxLZdQ77L4j6+SgO63eHwTGe+eBDL102YCPH5GUX3MwbzzR8312Rqo YS++mhsovkZUkVk5Ar0zPFuVA0Gvgb2gffkRt0v4VRlMZuteaWRpc4ZnHBA49qaxHD4c rJoR5+Bj25KdoIcz601Vuxn+HTcQB6RKImX2ki8tS9tZ4KqFuvceLSBs0U3CPRIGawOa 2eoYwnd6Wdd2blzCO5Wd3BNZgtD3xWbHH6V21GIw9N1C8+2IHXAGx64Sn8gu5suhicPC kYUw== X-Forwarded-Encrypted: i=1; AKwUvBxMLKpMZ/NWZ9RBwE1rsLuO7rXm/iLpLXkq64/w7MdVNdYsg09jtla0PqLjYyO1Qlvk6wEpWcbqFCU=@lists.xenproject.org X-Gm-Message-State: AFq9FYIx6scxYq2W/H/dna+lIecvS6JDmomqAJLpDKjCgDRgjTkzCrBo xkC97zm2BIpI7k6YYrRr+1hWRU71YseFMayBp0K6/JnuohfcMrtY7odLWKuIhYXoogk= X-Gm-Gg: AYBFou3mwqSRQyEsU6JJY2BC2fhK3jedZXnPK+YZrtCZIBAXBySSsYI5SQDcDTuD70f oibc3Irm37E2gco6ZibrW51e9SgpmpvFW6V4d85eDbTjbEylwU3bsape6fF7XGqnXcDX+rcn8hQ rnU4SkVTiDJPk8EUzmk1CbT0iE4/G/XBdsBX5b+lkOd6MB61CpLjNuhXuXgpkunuNHVXHBcVYo1 X5wOWlLSxd0s0VeRpQg31WP4lkkfcxVB05G96FFC+rcwwwaWnWD3Ne3rreMKIOYLiDEHyJTe5YT NbGFWB3/YlKdtwsP1Vba4NRKZ/T/ayhsSylJ91GeU92yhqvvSL80+7t6hAo+Qu0nxGbNRW3KNOV 9EsGnMdt7QGjNoZDv84fkTbaZlJIa4zlDP0mr4yINplBvLuPFlBQPg80n9Om/rcg8RhF7Otrmjj Rug5IwSYrL292M9/pyNvJcYkkheRmZoDbApmtSK5LEfcw60TvRH6ocm+QhAT3FHWK+X0038cJ6f TA31byTlCKRxsi6 X-Received: by 2002:a05:620a:4095:b0:93e:6b9e:6167 with SMTP id af79cd13be357-93f29cee007mr1347508785a.16.1792417858142; Mon, 19 Oct 2026 06:50:58 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:36 +0000 Subject: [PATCH net-next 02/15] net: skbuff: add skb_checksum_full() that reports failure MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-2-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417848; l=5325; i=josef@toxicpanda.com; h=from:subject:message-id; bh=ZlvWwY4Y8lGqu2UhxWxy8P8g8HVcQXW7x438vujwS94=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNFaoaSkHTQ/kJoHxBw9tZmbGdrEQBXIlSmcmhx2hYL/udLBNhUXEeeONY2pepSid3GD1qdel1E VD02yM/ZF5Ao= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1792417859-FCE14034-D3B0E2FC/0/0 X-purgate-type: clean X-purgate-size: 5327 skb_checksum() can't fail. When the range runs into unreadable frags or past the end of the skb it returns 0, which is also a valid checksum, so its callers can't tell the sum from a failure. For the receive-side validation helpers that means a packet whose payload was never checksummed can pass, and commit 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") made the past-the-end case one of those instead of a BUG(). Add skb_checksum_full(), which adds the range's sum to *@csump and returns 0, or returns -EFAULT for unreadable frags or a range past the end of the skb, and -EINVAL for a negative length, leaving *@csump alone. It's __must_check so a caller can't ignore the failure, and it recurses into frag_list members through itself so a failure there isn't lost either. skb_checksum() becomes a wrapper around it that behaves as before for the callers that haven't been converted: it returns 0 on failure and warns once if that was because of unreadable frags. The following patches convert the core users, and the rest will follow per subsystem. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/skbuff.h | 2 ++ net/core/skbuff.c | 56 +++++++++++++++++++++++++++++++++++++++++--------- 2 files changed, 48 insertions(+), 10 deletions(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 09db32f70b53..969b1c3269ec 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -4279,6 +4279,8 @@ int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len); int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len); int __must_check skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, int len, __wsum *csum); +int __must_check skb_checksum_full(const struct sk_buff *skb, int offset, + int len, __wsum *csump); int skb_splice_bits(struct sk_buff *skb, struct sock *sk, unsigned int offset, struct pipe_inode_info *pipe, unsigned int len, unsigned int flags); diff --git a/net/core/skbuff.c b/net/core/skbuff.c index a2b52a5a61a9..061c61422a38 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3545,12 +3545,31 @@ int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len) EXPORT_SYMBOL(skb_store_bits); /* Checksum skb data. */ -__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) +/** + * skb_checksum_full - checksum a range of an skb + * @skb: buffer to checksum + * @offset: offset in @skb to start at + * @len: number of bytes to checksum + * @csump: the sum to add to; on success the range's sum is added to it + * + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb + * has unreadable frags in the range or runs out before @len does. On + * failure *@csump is not changed. + */ +int skb_checksum_full(const struct sk_buff *skb, int offset, int len, + __wsum *csump) { int start = skb_headlen(skb); int i, copy = start - offset; struct sk_buff *frag_iter; + __wsum csum = *csump; int pos = 0; + int err; + + if (unlikely(len < 0)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } /* Checksum header. */ if (copy > 0) { @@ -3558,13 +3577,13 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) copy = len; csum = csum_partial(skb->data + offset, copy, csum); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; pos = copy; } - if (WARN_ON_ONCE(!skb_frags_readable(skb))) - return 0; + if (!skb_frags_readable(skb)) + return -EFAULT; for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { int end; @@ -3593,7 +3612,7 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) } if (!(len -= copy)) - return csum; + goto out; offset += copy; } start = end; @@ -3606,14 +3625,17 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) end = start + frag_iter->len; if ((copy = end - offset) > 0) { - __wsum csum2; + __wsum csum2 = 0; + if (copy > len) copy = len; - csum2 = skb_checksum(frag_iter, offset - start, copy, - 0); + err = skb_checksum_full(frag_iter, offset - start, copy, + &csum2); + if (err) + return err; csum = csum_block_add(csum, csum2, pos); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; pos += copy; } @@ -3621,9 +3643,23 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) } if (unlikely(len)) { DEBUG_NET_WARN_ON_ONCE(1); - return 0; + return -EFAULT; } +out: + *csump = csum; + return 0; +} +EXPORT_SYMBOL(skb_checksum_full); +/* skb_checksum() has no way to report failure, so it returns 0, which is a + * valid checksum. Use skb_checksum_full() in new code. + */ +__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) +{ + if (unlikely(skb_checksum_full(skb, offset, len, &csum))) { + WARN_ON_ONCE(!skb_frags_readable(skb)); + return 0; + } return csum; } EXPORT_SYMBOL(skb_checksum); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454378.1667953 (Exim 4.92) (envelope-from ) id 1xInlX-0006rD-Pt; Mon, 19 Oct 2026 13:51:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454378.1667953; Mon, 19 Oct 2026 13:51: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 1xInlX-0006p5-Ka; Mon, 19 Oct 2026 13:51:03 +0000 Received: by outflank-mailman (input) for mailman id 1454378; Mon, 19 Oct 2026 13:51:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlW-0006f9-95 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlV-00EZHA-MJ for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:01 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62035-bab6-0a2a0a5309dd-0a2a45039eb4-30 for ; Mon, 19 Oct 2026 15:51:01 +0200 Received: from [209.85.160.174] (helo=mail-qt1-f174.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62044-fae8-0a2a45030019-d155a0aed1fc-3 for ; Mon, 19 Oct 2026 15:51:01 +0200 Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-5363316fa0cso28487541cf.3 for ; Mon, 19 Oct 2026 06:51:01 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.240]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91bcbb27839sm98396566d6.35.2026.10.19.06.50.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06: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=1792417860; x=1793022660; 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=DPzcetTQubRCe4lOTpMna5FIDyGXRIDSoyAwtL9E3zo=; b=XsSTGl1K4GYN+PDY3oQjjdJsMv3LQN11FpIdqnYLLdsat1sBjBdmM7c7tChEWyHzTL dA4Wi3ZS2ytcIVnTokQvZGhh0N4nT8y2uA3Xg3r8psqAdp2TT3rfAANFVhBwLTVAAu6s 0mqJlNumQBsOL+eiCpRM//X/PuYb0ycdQoedzAZSbRA8TGuBlDmG93VmLqfoQZY5K5+M yLYLN96WRezVqHmFq+/8X6tlBDCIArlD0RbUxsY7mzhEF9T/V7xT+lUzfrfRgCx0lh9B UNXtIvyCmpD7qYLgBYXCQ9y1WBCcmwcAtYtFo67xNmjN1HgsUpKCmm5/S8utyDDQJCMo dFlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417860; x=1793022660; 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=DPzcetTQubRCe4lOTpMna5FIDyGXRIDSoyAwtL9E3zo=; b=yE8Ig18QOmHvLn7JDwL0I9RvgEz4nevdzF715+kufVRPmU23XYBmRGh/XKxR/uG+IV mMB/Nmd9G5L1ugBCJ89R8Ow46xEXizrhotimunOU+zxUmdvxTVxpEK/aR1VjrY7w0PSD EW4nMkaITQxKHt1jH36MlKOAzXrAwPCt5FLoBh3pATc1pX9j0MLHdy1N31gzXffv7817 qyzKKPakeSvuJiU1SQYvgL4OqUehBrMCkqG/qScrwVERd77h6CNK6CZZNn5mrM2QtnyC F7+6odwic58GWnazkNftSNtUmNOo10UsImSGebq3w12in/cbNTOjFYU8bUBmhPbiYkkw oQkg== X-Forwarded-Encrypted: i=1; AKwUvBwGStJf3RtJsg0+HdYHVvCbwoVNMxCqqUtxZEfvWwY265atHjZfBn1JU1OLqKoIf8d7I37pSaQgMCE=@lists.xenproject.org X-Gm-Message-State: AFq9FYIfkyvCMDIEJ/7bOmdN9mowdxeqkJHFw3UA007YeJlkSqNSuWUJ 3ZCIQ6XwCmxmPRkXrlKA5e3Ht5N3uhkbbk/vAggRLQgT+S2A4w6dbehyUaFnHBKhy7w= X-Gm-Gg: AYBFou31hXo0+9wxnswpEoOL84hzAZ4fMhcsrB3zzD2sDiZ8fAId86QxAbEzn+v42Cv Qgyp/UaY/VKOiDUCSFCUfNwtBtqANCwORp5WABRGc8aM7G0KH7L7cYaXiWtfLyHxP+rqvHXaKyr cgY83QCCPdZARobt3nLKZBDZWIowIDpvWLvsPz8uVBBgbWSJ5uKpI1T0ndwLjF0AJPheoOjoHcs 0Hb96HQZKhrOjH1tqGOm5kEvh9ddgOXuUKTN/4jAFpvYdmHVSnmiG7+vf6UyhyZi37BSqBKpsvY q4O9D7Gbycq7+I/ebQF0Tj7/+1UGM9pq/l3A3Gi5N5MiSCZnJTgJ/tZuUFYqjWGZ8lSlLGSY+kr T2+HCxPkMfud6MYIoBIfOetIkfLODF99ccgpdMnHvCjgBwU+B59XQTOrBtIKD3HaLr9ahLK2Bzn mds05kHLJ4dpFH6eQvcRL+RAfbVAFB1++3Fr2xj/vgr9Hl5bdSDciepmUFUyvHPVOE5b4nlaW8L bjtEhfidh7DWi4= X-Received: by 2002:ac8:5745:0:b0:532:abc9:8f4f with SMTP id d75a77b69052e-53645ff0043mr114359591cf.37.1792417860150; Mon, 19 Oct 2026 06:51:00 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:37 +0000 Subject: [PATCH net-next 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-3-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417848; l=2860; i=josef@toxicpanda.com; h=from:subject:message-id; bh=prj+BQU7C60dBsXDxJX9jL8mklYfFucWwKvpS5MOuJ4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QORYeqwwHo+WYErVqZ8QYEvyduUuJE0wPwwChX6fbXgz7Urjug8C88v1GDgpgDsaWL42fgGzxt7 mVAv6CTaYGQk= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1792417861-6F8C54E9-700B187B/0/0 X-purgate-type: clean X-purgate-size: 2862 __skb_checksum_complete() verifies a received packet with skb_checksum(), which returns 0 when the range runs into unreadable frags or past the end of the skb. 0 is a valid sum, so it's treated as one: it adds skb->csum, the pseudo-header sum, and folds the result. With a sum of 0 that's csum_fold(skb->csum), which is 0 whenever the pseudo-header sum folds to 0xffff, so a packet whose payload was never checksummed is accepted, marked csum_valid, and left with a wrong CHECKSUM_COMPLETE value in skb->csum. __skb_checksum_complete_head() passes skb->csum in as the seed, so a failure there folds 0 and the packet fails validation, but only because skb_checksum() happened to drop the seed. Use skb_checksum_full() in both, and report a packet that can't be checksummed as having a bad checksum, so callers drop it the way they drop any other bad checksum. Clear csum_valid, and leave skb->csum and ip_summed alone, since there's no full packet checksum to store. Found by the Sashiko AI review of the series that made skb_checksum() return 0 for a range past the end of the skb. Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 061c61422a38..40d2dd20d47d 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3860,9 +3860,17 @@ EXPORT_SYMBOL(skb_crc32c); __sum16 __skb_checksum_complete_head(struct sk_buff *skb, int len) { + __wsum csum = skb->csum; __sum16 sum; - sum = csum_fold(skb_checksum(skb, 0, len, skb->csum)); + /* If the data can't be checksummed it can't be valid either. */ + if (skb_checksum_full(skb, 0, len, &csum)) { + if (!skb_shared(skb)) + skb->csum_valid = 0; + return (__force __sum16)1; + } + + sum = csum_fold(csum); /* See comments in __skb_checksum_complete(). */ if (likely(!sum)) { if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE) && @@ -3886,10 +3894,17 @@ EXPORT_SYMBOL(__skb_checksum_complete_head); */ __sum16 __skb_checksum_complete(struct sk_buff *skb) { - __wsum csum; + __wsum csum = 0; __sum16 sum; - csum = skb_checksum(skb, 0, skb->len, 0); + /* If the data can't be checksummed it can't be valid either. Leave + * skb->csum alone, it's not a full packet checksum. + */ + if (skb_checksum_full(skb, 0, skb->len, &csum)) { + if (!skb_shared(skb)) + skb->csum_valid = 0; + return (__force __sum16)1; + } sum = csum_fold(csum_add(skb->csum, csum)); /* This check is inverted, because we already knew the hardware -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454375.1667931 (Exim 4.92) (envelope-from ) id 1xInlR-0006SF-Tx; Mon, 19 Oct 2026 13:50:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454375.1667931; Mon, 19 Oct 2026 13: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 1xInlR-0006S8-R4; Mon, 19 Oct 2026 13:50:57 +0000 Received: by outflank-mailman (input) for mailman id 1454375; Mon, 19 Oct 2026 13:50:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlQ-0006Ru-LV for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:50:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlP-009usr-2o for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:50:55 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62034-8faa-0a2a0a5109dd-0a2a45079456-24 for ; Mon, 19 Oct 2026 15:50:55 +0200 Received: from [209.85.160.169] (helo=mail-qt1-f169.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6203d-b4ea-0a2a45070019-d155a0a9a5ed-3 for ; Mon, 19 Oct 2026 15:50:54 +0200 Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-5351d76e1baso27234321cf.1 for ; Mon, 19 Oct 2026 06:50:54 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.240]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5362a9dbdb5sm99677641cf.22.2026.10.19.06.50.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:50: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: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=1792417853; x=1793022653; 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=5YreDSl4vDqbNAVIITvhajgrdqUJ1n9sK10J0+0ZRYE=; b=SEKrrvlgtI+M7rlK0MHIdqDxufABvaT6yAT6ehTe0KCXb6ZIPDABaHs1HrSwsVrWVJ cNs2hLa1GNX0wfU4tZegPclpHX/dzFCYVZB3RYNi3rsdaAhYJQolXmubQqi+hGkcEv5J YY03Y5D8KAfvnifQ6N0gT58KiCGIP2vn/HKpfEE0aQuK2+00YN1J0BsQFraO7SGcg6iV C3eIfc3c85v6Kd11mGhYZzI+SWWQBqkJcPzvyMa97Xjs9KJZP/NqOsIUYfcbbF1AdWGx LfhUwHIwrODAGobE1MVV1FyIEcYOBWT0MMCydnisSlYz2sl3vvFW+67eWjbezuRn/uX1 04MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417853; x=1793022653; 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=5YreDSl4vDqbNAVIITvhajgrdqUJ1n9sK10J0+0ZRYE=; b=YY5ylFhQt7lqrh/8v1wqx6IBpEwuuFJvCGMIkjYZMbuawU/mYjDzcdPNSzK/YpZtO7 dqcvPApHqnUtUcuv4wUWlYya1GjNhugqAW1WqHRs1x7FQVmchIK7aUeLn5BIm/DQ7QNI T9h9h5230/gSAWaFUBTEc0F4bvgML9TdvmzJVFhd5oOzcDRv8ISS7q4VRLcXKxxira5Z n86+mbnwO3aarMN8hJDtwSJFDJYoS00NuVrsggP3HDpU/N1YOdLmOrru8JiyVZvofGzD SrMhl/Zc/GDmsVSg3lC8mgM4gykb9GFg0gnHpKc7yVCpbJFC2Cp+0cWzESoKD9Ukkmlg Y8nw== X-Forwarded-Encrypted: i=1; AKwUvByBFBzIXnAPVRhuzeiHfzr6QWlqsTjS4/eu2fOjoRa5n2kJ1jDkDplazOYrY0pC6D1cxW1h3E+02Xw=@lists.xenproject.org X-Gm-Message-State: AFq9FYLHXOXXw7NCyysTgHsnGZuDZIowIg1oqlq3iciWWcUtc9NEzLmn k+2mgNMMl78sY+2MZZmFWKeYHfp6PuZ0/ioFsajB6YqxRoH0ywCQWUWoj1Ogj4vrICM= X-Gm-Gg: AYBFou3WXF3CcNwqFzNjK0VP/Et6FiWcgbw3+gmTwDQalW20OBHk+Pm5uon34nRj/G6 4wJpo5xewMSSqGdVmCEixXS3sAxGXyHWWEitaIKVAJTDhyCl3rgoME65GlH9z/Xvs8mM5yBo/dI apTVUIIlKPXo3MvG9rmcylrQxn331MGpm6bqvVFJ3hSYZMK3Nfrcd3SX22C6xJjU6tvj+63Rvvz cB19Kl9OSE030fgzra3s7LTLV1Wx2QXiBUQWMUiZ3VmDiupytJxfWBjuMg4T8+dAvg+8/fJGCf9 5SGvCEOTun7CT5zAw0m2I7dEjv2ltejopPHyQjs5+kc+ChtqYZ0VeT0GDK86IiAxNVIWTqKWycT eSlPuqWjsQPaP7HEp3w01qGjx9lBy/+30CcW7bcavRoVVmqJgId9nP8oz/Cwa35diF/Yq62DY0L 5PPULpFJ1RFpUwtIFmzmKKv3UVWUkxuEzVKHEvYntZIIXWZnO81auDz53by6TgHkMRdkzK5zxzc h7NaIcyTHwJjVE= X-Received: by 2002:ac8:5d11:0:b0:51c:b98c:f772 with SMTP id d75a77b69052e-53645fedd9emr99044071cf.15.1792417853207; Mon, 19 Oct 2026 06:50:53 -0700 (PDT) From: Josef Bacik Subject: [PATCH net-next 00/15] net: skbuff: follow-ups to the BUG_ON() removal Date: Mon, 19 Oct 2026 13:50:34 +0000 Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIACwg1moC/3WNwQqDMBBEf0X23EUjqZT+SukhqxtNK4lkjRXEf 6+x5x7nzfBmA+HoWOBebBB5ceKCP4K6FNAOxveMrjsy1FXdqEo1SBrlTclapNRj8GjDOIZPmgR Np5TpbH27Gg2HYIps3XrKH+B5Rs/rDM9fI4le3M7ZnbdkhJGi8e2Q0TiVpMsT/nmDff8CfBxvY 70AAAA= X-Change-ID: 20261016-b4-skbuff-bug-on-followups-ad11adf285a4 To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417848; l=4198; i=josef@toxicpanda.com; h=from:subject:message-id; bh=KIaS3RgzIflnJVbs1aR2xV1e37kN7pyP1TLRgrxxSDg=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QG9I0MA4oB2pQusLHea7/1MDYYSfacfAuZk3/f5DoGX+4zhJuIDA85OltKcTqezTiJ7GjwQMaYR jFfuEgK6Q9Ag= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ef75cf/1792417854-348C9AE4-9F3DAC5C/0/0 X-purgate-type: clean X-purgate-size: 4200 Hello, Jakub applied v2 of my skbuff BUG_ON() series[1] before I got v3 out, so this is what v3 would have changed, as fixes on top of what landed, plus the skb_copy_and_csum_bits() patch I'd been sending to net on its own. Patch 1 is that patch[2], moved to net-next as Mina suggested, with his Reviewed-by. It makes skb_copy_and_csum_bits() report failure, and the rest of the series builds on it. Please drop the net version. Patches 2 through 6 deal with skb_checksum() and skb_crc32c(). My v2 had them return 0 when they run out of skb, and that turned out not to be safe: 0 is a valid checksum, and it can make a packet that was never fully checksummed pass verification. So they get versions that report failure, skb_checksum_full() and skb_crc32c_full(), and the core users switch to them: checksum validation now rejects a packet it can't checksum, skb_segment() and pskb_trim_rcsum() fail instead of using a bad sum, and skb_crc32c_csum_help() drops the packet. skb_checksum() and skb_crc32c() stay as wrappers that behave as before, and I'll convert the rest of their callers per subsystem in later series. Patches 7 through 10 fix problems Sashiko and an LLM review found in what was applied. skb_zerocopy() refuses a zero-length copy that Open vSwitch can trigger from a user namespace, skb_try_coalesce() and skb_copy_and_csum_bits() can be handed a negative length, and skb_headlen() can underflow in skb_copy_and_csum_dev(). Patches 11 and 12 make skb_segment() refuse a nested frag_list, which could still oops on a NULL list_skb, and add KUnit cases for the layouts it refuses. Patches 13 and 14 get rid of the same BUG_ON()s in xen-netfront's bounce_skb() and tls's __skb_nsg(), and patch 15 updates comments that still describe the old BUG_ON()s. I tested this with the net_core KUnit tests, a test module that drives each of these paths under KASAN and fault injection, an Open vSwitch reproducer for patch 7, and a stress run over veth with netem. Thanks, Josef [1] https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ [2] https://lore.kernel.org/all/20261013-b4-skb-segment-nosg-unreadable-v2-1-6c28d8ffa51e@toxicpanda.com/ --- Josef Bacik (15): net: skbuff: make skb_copy_and_csum_bits() report unreadable frags net: skbuff: add skb_checksum_full() that reports failure net: skbuff: fail checksum validation when the skb can't be checksummed net: skbuff: fail segmentation when a segment can't be checksummed net: skbuff: fail pskb_trim_rcsum() when it can't checksum the tail net: skbuff: add skb_crc32c_full() that reports failure net: skbuff: let skb_zerocopy() copy a short skb without head_frag net: skbuff: make skb_try_coalesce()'s len unsigned net: skbuff: check csum_start against len in skb_copy_and_csum_dev() net: skbuff: reject a negative length in skb_copy_and_csum_bits() net: skbuff: refuse to segment a nested frag_list net: test the frag_list layouts skb_segment() refuses xen-netfront: don't BUG() when skb_copy_bits() fails in bounce_skb() net/tls: don't BUG() on leftover length in __skb_nsg() net: update comments that still describe the skb BUG_ON()s drivers/net/ethernet/sun/sunvnet_common.c | 10 +- drivers/net/xen-netfront.c | 7 +- include/linux/skbuff.h | 8 +- net/core/dev.c | 7 +- net/core/filter.c | 6 +- net/core/net_test.c | 52 +++++- net/core/skbuff.c | 274 +++++++++++++++++++++++------- net/ipv4/icmp.c | 9 +- net/ipv4/ip_output.c | 11 +- net/ipv6/icmp.c | 7 +- net/ipv6/ip6_output.c | 11 +- net/sunrpc/socklib.c | 9 +- net/tls/tls_sw.c | 5 +- 13 files changed, 327 insertions(+), 89 deletions(-) --- base-commit: 6b3e73774815910a39d8ca75b9ad7df963f61d50 change-id: 20261016-b4-skbuff-bug-on-followups-ad11adf285a4 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454376.1667941 (Exim 4.92) (envelope-from ) id 1xInlX-0006fb-4T; Mon, 19 Oct 2026 13:51:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454376.1667941; Mon, 19 Oct 2026 13:51: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 1xInlX-0006fU-17; Mon, 19 Oct 2026 13:51:03 +0000 Received: by outflank-mailman (input) for mailman id 1454376; Mon, 19 Oct 2026 13:51:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlV-0006el-3t for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlU-001dLL-8m for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:00 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62028-e002-0a2a0a5209dd-0a2a450a9e52-40 for ; Mon, 19 Oct 2026 15:51:00 +0200 Received: from [209.85.219.41] (helo=mail-qv1-f41.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62041-f2d2-0a2a450a0019-d155db29e5b0-3 for ; Mon, 19 Oct 2026 15:50:58 +0200 Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-91791ec1b83so18174546d6.1 for ; Mon, 19 Oct 2026 06:50:57 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.241]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91bcbaae645sm99626496d6.21.2026.10.19.06.50.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06: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=1792417857; x=1793022657; 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=qblwx7bbNy5k368b4HO2T3MytVs1L8oRqcYO8Zy3rtU=; b=Klwj52t/L04ZNTrbvz+c9fMFBZSiGuSEcmxJkDr3UJ9J/QSxZXiveqWv0ZEgO87vti 0K+HKN/OI9oETyiB/g/uhko0+ujsiaJ3q9HJEmQ0725USvMdLH41Yl+XrFUCAYDEJo0N RV27bt4EGXsfGQEjrx60sPiYbDGDSdo5raEXEoij1zLF5ureKaLznIRvtb2FN705CMuh wEpura8d241lmCHFnryrvwgQ0vXfaNBSrDLEz54iV+8Td9Jf5JMmzquhc9jvPM0sIU39 Wyoot6ZGkr3nNlDSY4+69XsIeQlF6117N7VIx5roEnHqiOQ/660vhcpxVWh36TIG8Mrc 2BJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417857; x=1793022657; 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=qblwx7bbNy5k368b4HO2T3MytVs1L8oRqcYO8Zy3rtU=; b=nYVdbW1qPLaPBTixzr9Co1tfAw8kO5sIqi5ZaXtT63yOYL6Cp3zZs2GFJNuHbCfSgc JUSG9o5dkKoCxHON4T1f6k+6qUXsuAIYm+8JNC5fjFNqxWyw8NNL7ZlJwk6aNdxucPT0 oXv5wbyb/7mZD+An8zq3QWYShPWpjPbhrGWksBrKiVZqKo0uSThuhuJ7WhrZEGbEOyae duJJkMrXfXTVwg1k+iJcpR8C5kcUKoM5YHUPlcIw7//LpfbqPwx3jtug0Nw+QFmKnO9+ wPWI25xtmpeFVWxgEHMrMBQZVnukC7sCKgIcGEdEIi+c7AX02LZKFkW7wD96y46oyjyv QBhg== X-Forwarded-Encrypted: i=1; AKwUvBxRWC4bzImFwYstkJM7acnd4hUH/mMT3ZLUO7Io0v6O2DT756Rp/4cRCht3YKvgkNvNcBgc1ej+eCk=@lists.xenproject.org X-Gm-Message-State: AFq9FYIJMClVo3iJe7WlmQb/GrMvUZ+O+j02amb9IX/uF1UpwB8WrukE +3jVACWPOpIX2kp3g7atVc7IfnsUwtVH1qW+KnGThvg5MMgNRYLNku7NOATyc1uFjqI= X-Gm-Gg: AYBFou3XEFWD9UpDp2CZtj7XAOFKNyVz4IsjKyG1MkGt+C6UfdfuWL8Bzk1pJIgFjjX 2dccPdp0paaZE5OU+8+3MFBsnku8AuVYLA9MUpaUSIaq+uQthyEs7pZbJpig0OzF95pMaLgzu8M LsvM5Zvh56k/3fxdaOk7l1u9zzhWkvZdISRWqm0bWtgoWS1P3FB3sdxE+F3WF1cJDxFPhD5v5D7 5wnUHJPyduTA91vmjmUkihO4/ZsTCTuIuci/GqZipAu9PJU/kGkDH4pLJXNSnT3U/T/Vz6K560H 0wcDGePtdYEVHH3IyEoPtC0aI2m6ApzsI/Br/DGRrdpAOSD/VysJc4Xj5kwL5QvThbj1uUw0s0t 2kkLjuEgmzF4VeDRuR8Quwo5PvPppzc1tQe+jutHN66vUC20y6AFhcrIl0tqRebpzXEa0z6vHMj DM+qQKTiIxtq6jpcC+AwZG1yEyuUMuJy8tibpxHcO/CgqEv8OeMnopzy0KG3bpOu5r0vIizJ61c ExOXAl3c3nyJFcQEiUY6kZhzAdCvMyeNm7zR0/2fh5sUzbO6zUfwwxOdXV8NUbAT1mpskzQ X-Received: by 2002:a05:6214:44a0:b0:917:a4d9:1373 with SMTP id 6a1803df08f44-91bdf127eaemr121313976d6.23.1792417856134; Mon, 19 Oct 2026 06:50:56 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:35 +0000 Subject: [PATCH net-next 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-1-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417848; l=13888; i=josef@toxicpanda.com; h=from:subject:message-id; bh=dL3q9YRxfCrEbWcizXq9oznfRWHecZyPcn5ovtK2fxY=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QDmxDJSAVza1wipmMQxYPi6qoFImua7iVjrYNs1kkIjpC41hXs6QTatTN021+n+ilY/mobmNNiA 3jVRJaLK4rw0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-4011c0/1792417858-4B6D6CFC-906E07B3/0/0 X-purgate-type: clean X-purgate-size: 13890 skb_copy_and_csum_bits() has no way to fail. When it reaches unreadable frags it zero-fills the rest of the buffer and returns 0, and since commit ab9414ed70bd ("net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()") that 0 is the correct checksum for what's in the buffer. Its callers can't tell the copy didn't happen. That matters in the !sg && !csum branch of skb_segment(). A devmem TCP skb keeps its whole payload in unreadable frags, so every segment ends up with a payload of zeroes, tcp_gso_segment() writes a valid TCP checksum over it, and the peer accepts the zeroes as stream data. This is reachable when both SG and TX checksum offload are turned off on a device used for devmem TX: sk_setup_caps() still gives TCP SG and HW_CSUM, so the dmabuf send is accepted, validate_xmit_unreadable_skb() lets the skb through for a NETMEM_TX_NO_DMA device or a matching binding, and software GSO segments it with neither feature. Before that commit the segments carried uninitialized memory with a checksum that almost never matched. This was reproduced with a test module rather than on devmem hardware: skb_segment() on a TCPv4 GSO skb with 3000 bytes of payload in a page frag marked unreadable, with features == 0, returns 3 segments whose payloads are all zeroes, each with a checksum of 0, which is correct for zeroes. There's no warning or error; the data is silently replaced. With this patch skb_segment() returns -EFAULT. Make skb_copy_and_csum_bits() return 0 or -EFAULT and hand the checksum back through a pointer, and make it __must_check so a new caller can't ignore the failure. Running out of skb before @len returns -EFAULT too; commit 417261779eab ("net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()") made that a zero-fill and a checksum of 0. Each caller takes the error path it already has for a failed copy: - skb_segment() fails the segmentation, as the csum branch already does when skb_copy_bits() fails. - icmp_glue_bits() and icmpv6_getfrag() return the error, so the ICMP error isn't sent. - __ip_append_data() and __ip6_append_data() drop the new skb and return -EFAULT, as they do when getfrag fails. - vnet_skb_shape() fails the same way it does when its skb_copy_bits() call fails. - xdr_skb_read_bits() returns 0 without consuming anything, as it does when skb_copy_bits() fails, so desc.count stays non-zero and csum_partial_copy_to_xdr() fails. csum_partial_copy_to_xdr() used to checksum the bytes it hadn't copied before checking desc.count. desc.offset and desc.count always add up to skb->len, so that only ran when it was about to fail anyway, and on an unreadable skb skb_checksum() would WARN. Drop it. - skb_copy_and_csum_dev() can't return an error, so it leaves the checksum alone and the frame goes out with a bad one. Its callers are drivers that never see unreadable skbs anyway. The zero-fill stays, so a caller that does send the buffer still doesn't leak anything. This was found by the Sashiko AI review of that commit, and Mina suggested reporting the error from the helper rather than checking for unreadable frags in skb_segment(). Link: https://lore.kernel.org/all/179148235783.434549.14322374227477832817@kernel.org/ Suggested-by: Mina Almasry Reviewed-by: Mina Almasry Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/sun/sunvnet_common.c | 10 +++-- include/linux/skbuff.h | 4 +- net/core/skbuff.c | 63 +++++++++++++++++++++---------- net/ipv4/icmp.c | 9 +++-- net/ipv4/ip_output.c | 11 ++++-- net/ipv6/icmp.c | 7 +++- net/ipv6/ip6_output.c | 11 ++++-- net/sunrpc/socklib.c | 9 ++--- 8 files changed, 83 insertions(+), 41 deletions(-) diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c index 5cca95869052..4f229fcecc32 100644 --- a/drivers/net/ethernet/sun/sunvnet_common.c +++ b/drivers/net/ethernet/sun/sunvnet_common.c @@ -1167,9 +1167,13 @@ static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, int ncookies) /* copy the rest, with csum calculation */ *(__sum16 *)(skb->data + offset) = 0; - csum = skb_copy_and_csum_bits(skb, start, - nskb->data + start, - skb->len - start); + if (skb_copy_and_csum_bits(skb, start, + nskb->data + start, + skb->len - start, &csum)) { + dev_kfree_skb(nskb); + dev_kfree_skb(skb); + return NULL; + } /* add in the header checksums */ if (skb->protocol == htons(ETH_P_IP)) { diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index af1cbc2799b7..09db32f70b53 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -4277,8 +4277,8 @@ void skb_free_datagram(struct sock *sk, struct sk_buff *skb); int skb_kill_datagram(struct sock *sk, struct sk_buff *skb, unsigned int flags); int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len); int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len); -__wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, - int len); +int __must_check skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, + u8 *to, int len, __wsum *csum); int skb_splice_bits(struct sk_buff *skb, struct sock *sk, unsigned int offset, struct pipe_inode_info *pipe, unsigned int len, unsigned int flags); diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 93c2f440b9ec..a2b52a5a61a9 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3630,14 +3630,27 @@ EXPORT_SYMBOL(skb_checksum); /* Both of above in one bottle. */ -__wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, - u8 *to, int len) +/** + * skb_copy_and_csum_bits - copy data out of an skb and checksum it + * @skb: source buffer + * @offset: offset in @skb to start copying from + * @to: destination buffer + * @len: number of bytes to copy + * @csump: where to store the checksum of the copied bytes + * + * Return: 0 on success, or -EFAULT if @skb has unreadable frags or runs + * out before @len does. On failure *@csump is not set and the part of + * @to that couldn't be filled is zeroed. + */ +int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, + u8 *to, int len, __wsum *csump) { int start = skb_headlen(skb); int i, copy = start - offset; struct sk_buff *frag_iter; int pos = 0; __wsum csum = 0; + int err; /* Copy header. */ if (copy > 0) { @@ -3646,7 +3659,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, csum = csum_partial_copy_nocheck(skb->data + offset, to, copy); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; to += copy; pos = copy; @@ -3656,7 +3669,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, /* Don't hand the caller a buffer with stale bytes in it. */ if (len > 0) memset(to, 0, len); - return 0; + return -EFAULT; } for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { @@ -3688,7 +3701,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, } if (!(len -= copy)) - return csum; + goto out; offset += copy; to += copy; } @@ -3705,12 +3718,16 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, if ((copy = end - offset) > 0) { if (copy > len) copy = len; - csum2 = skb_copy_and_csum_bits(frag_iter, - offset - start, - to, copy); + err = skb_copy_and_csum_bits(frag_iter, offset - start, + to, copy, &csum2); + if (err) { + /* The child zeroed its part; zero the rest. */ + memset(to + copy, 0, len - copy); + return err; + } csum = csum_block_add(csum, csum2, pos); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; to += copy; pos += copy; @@ -3722,9 +3739,11 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, /* Don't hand the caller a buffer with stale bytes in it. */ if (len > 0) memset(to, 0, len); - return 0; + return -EFAULT; } - return csum; +out: + *csump = csum; + return 0; } EXPORT_SYMBOL(skb_copy_and_csum_bits); @@ -4006,9 +4025,13 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to) skb_copy_from_linear_data(skb, to, csstart); csum = 0; - if (csstart != skb->len) - csum = skb_copy_and_csum_bits(skb, csstart, to + csstart, - skb->len - csstart); + /* On failure the rest of @to is zeroed; leave the checksum alone so + * the frame goes out with a bad one. + */ + if (csstart != skb->len && + skb_copy_and_csum_bits(skb, csstart, to + csstart, + skb->len - csstart, &csum)) + return; if (skb->ip_summed == CHECKSUM_PARTIAL) { long csstuff = csstart + skb->csum_offset; @@ -5057,11 +5080,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, if (!csum) { if (!nskb->remcsum_offload) nskb->ip_summed = CHECKSUM_NONE; - SKB_GSO_CB(nskb)->csum = - skb_copy_and_csum_bits(head_skb, offset, - skb_put(nskb, - len), - len); + if (skb_copy_and_csum_bits(head_skb, offset, + skb_put(nskb, len), + len, + &SKB_GSO_CB(nskb)->csum)) { + err = -EFAULT; + goto err; + } SKB_GSO_CB(nskb)->csum_start = skb_headroom(nskb) + doffset; } else { diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c index 90c0e22c29be..35008785e3d2 100644 --- a/net/ipv4/icmp.c +++ b/net/ipv4/icmp.c @@ -364,12 +364,15 @@ static int icmp_glue_bits(void *from, char *to, int offset, int len, int odd, DEFINE_RAW_FLEX(struct icmp_bxm, icmp_param, replyopts.opt.__data, IP_OPTIONS_DATA_FIXED_SIZE); __wsum csum; + int err; icmp_param = from; - csum = skb_copy_and_csum_bits(icmp_param->skb, - icmp_param->offset + offset, - to, len); + err = skb_copy_and_csum_bits(icmp_param->skb, + icmp_param->offset + offset, + to, len, &csum); + if (err) + return err; skb->csum = csum_block_add(skb->csum, csum, odd); if (icmp_param->data.icmph.type <= NR_ICMP_TYPES && diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 3396f177a18d..f7da4538d05b 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -1162,9 +1162,14 @@ static int __ip_append_data(struct sock *sk, data += fragheaderlen + exthdrlen; if (fraggap) { - skb->csum = skb_copy_and_csum_bits( - skb_prev, maxfraglen, - data + transhdrlen, fraggap); + if (skb_copy_and_csum_bits(skb_prev, maxfraglen, + data + transhdrlen, + fraggap, + &skb->csum)) { + err = -EFAULT; + kfree_skb(skb); + goto error; + } skb_prev->csum = csum_sub(skb_prev->csum, skb->csum); data += fraggap; diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c index a95b0351824f..31ca3da80b1f 100644 --- a/net/ipv6/icmp.c +++ b/net/ipv6/icmp.c @@ -322,9 +322,12 @@ static int icmpv6_getfrag(void *from, char *to, int offset, int len, int odd, st struct icmpv6_msg *msg = (struct icmpv6_msg *) from; struct sk_buff *org_skb = msg->skb; __wsum csum; + int err; - csum = skb_copy_and_csum_bits(org_skb, msg->offset + offset, - to, len); + err = skb_copy_and_csum_bits(org_skb, msg->offset + offset, + to, len, &csum); + if (err) + return err; skb->csum = csum_block_add(skb->csum, csum, odd); if (!(msg->type & ICMPV6_INFOMSG_MASK)) nf_ct_attach(skb, org_skb); diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 25fe0ba98b1a..d259e7dca8ba 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1724,9 +1724,14 @@ static int __ip6_append_data(struct sock *sk, skb->transport_header = (skb->network_header + fragheaderlen); if (fraggap) { - skb->csum = skb_copy_and_csum_bits( - skb_prev, maxfraglen, - data + transhdrlen, fraggap); + if (skb_copy_and_csum_bits(skb_prev, maxfraglen, + data + transhdrlen, + fraggap, + &skb->csum)) { + err = -EFAULT; + kfree_skb(skb); + goto error; + } skb_prev->csum = csum_sub(skb_prev->csum, skb->csum); data += fraggap; diff --git a/net/sunrpc/socklib.c b/net/sunrpc/socklib.c index d8d8842c7de5..5d780ad4ae3a 100644 --- a/net/sunrpc/socklib.c +++ b/net/sunrpc/socklib.c @@ -49,7 +49,9 @@ xdr_skb_read_bits(struct xdr_skb_reader *desc, void *to, size_t len) if (desc->need_checksum) { __wsum csum; - csum = skb_copy_and_csum_bits(desc->skb, desc->offset, to, len); + if (unlikely(skb_copy_and_csum_bits(desc->skb, desc->offset, + to, len, &csum))) + return 0; desc->csum = csum_block_add(desc->csum, csum, desc->offset); } else { if (unlikely(skb_copy_bits(desc->skb, desc->offset, to, len))) @@ -142,11 +144,6 @@ int csum_partial_copy_to_xdr(struct xdr_buf *xdr, struct sk_buff *skb) desc.csum = csum_partial(skb->data, desc.offset, skb->csum); if (xdr_partial_copy_from_skb(xdr, &desc) < 0) return -1; - if (desc.offset != skb->len) { - __wsum csum2; - csum2 = skb_checksum(skb, desc.offset, skb->len - desc.offset, 0); - desc.csum = csum_block_add(desc.csum, csum2, desc.offset); - } if (desc.count) return -1; if (csum_fold(desc.csum)) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454381.1667967 (Exim 4.92) (envelope-from ) id 1xInlj-0007WU-VY; Mon, 19 Oct 2026 13:51:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454381.1667967; Mon, 19 Oct 2026 13: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 1xInlj-0007WL-Se; Mon, 19 Oct 2026 13:51:15 +0000 Received: by outflank-mailman (input) for mailman id 1454381; Mon, 19 Oct 2026 13:51:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInli-0007Tu-P5 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInli-009uw8-5s for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:14 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6203e-8faa-0a2a0a5109dd-0a2a4504d8e6-38 for ; Mon, 19 Oct 2026 15:51:14 +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 6ad62050-b57f-0a2a45040019-d155deaea41d-3 for ; Mon, 19 Oct 2026 15:51:13 +0200 Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-93f2ed2541aso165362485a.0 for ; Mon, 19 Oct 2026 06:51:13 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93f332739d7sm575249785a.28.2026.10.19.06.51.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06: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=1792417872; x=1793022672; 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=2aRCuku2oKEDF0Op1/pBMZnZUn6snlu290Nklz94qvM=; b=nFQDfc98Zx0rxPble0Rr2HynSduZ4Q339uVr5Dq45zQOQuHCE8/NWakmwX/ZG7VqWZ ViP2DrZUjjLnB2OD/ZmLJptzf7HJXo9P+diG27+6uD/yjAOtwbsz/Yh/gBxlb+QfKqgV l34+XKHH08HdfxbjWeAQz+/ZY5YFTraKUbvM4VsWXgap312Vjl2EOKCD1EeJ1zBSeZMn FCAFt4e5ujH+s98L8Xk5tROXVzs1qWcj+ek18MMs8d8/iRyx8NzxFiDDJIptEaUVqXNd 5qMMmzIk1UaDNlUdvqj9sC0aoBYCIZoUM7mhBRwi7g3vnbsz9nfNmyZZunAYkPG+nJSb Hv+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417872; x=1793022672; 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=2aRCuku2oKEDF0Op1/pBMZnZUn6snlu290Nklz94qvM=; b=zuj7cfDXlwexzRbsth3rxh6PaECzVT9LP0LY3yDsy7Yo7ym2CuSzCJdZYOEAkbf/WK FreC82M3DFFynD6gule/9Pv1ambgs7EV72hd3HfvZgh7iKsaqrr4biNQrXbYXS6q0ikj /Ex74270op4qLPfkAz+rEvW5SmaLQn5VrwYzxTiceJMEkLasZyoS4tAfUpTyY2nKkss+ 1GoMZiu1OZtA+PsO5pyym+wjUoZRjR3mLdQ1qP2iBiBAACTQg7gaTRQ97m1YtEwN8Xi5 3lOi6dl22/zeaD4AFSTlbL1aemObV6J9y0d7wLZ4UhZSutSgK33aN+W3ZfXxNM4pQo92 lgDw== X-Forwarded-Encrypted: i=1; AKwUvBz4/DaYn4RXONjEHAnCBH5FDxMQvCaMKsRu8EojLE9MXmD/h3r3RfcjTk04sDErgrdmmvXbBbJ/jPQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYLsrkO7bbdAWjuLRdJXUyFyNfPv4/j3pIq851fSYUSeKjwDUMkR VMDjo4hsdHjY3RgGP/G+GDOZE0q84CNTw5i+CvoeRArO3++eCo/Y9WgbFPtTXJKDAjg= X-Gm-Gg: AYBFou0MieoM9mrP0qgJbLNPnesLSkl30CI8YcfjM9/0tONJJxyuEEoxGrzj9oldg8T +UZdM3wxH2Dtk1REq9LodknoFu82XvrwcBNAJSFYHx0Op6n/iz4HL6yJwTL2NUyhnRi5M3Zix0+ SQ4RHs1ImR7zlHzxezw8HlUJIT2GXvJ/3+6IMy5BDyQnLeJssm7ypy1D55XrkGxMbpOULAajh91 CGxVhrm/eke4hdZ2BMDGrjRU368lFSoUL+YKA8kZN4YhwxFXvU663EhlmQUDOOXU8NeJ+/MkH3x PbglixYdmnq62UANi9/+7zuO2NjT/PmhswxicCwFklS+t1vT9gFunesseOQD5Vd3zj64pGrBvO1 2tte3R67Ur4GyVWthKl/E+AMm1yKXhc/GozuThjObheMWw47KWCbjVpw/9jO21Vfq3Ktce71ZY1 uMWsQ8Y4d7JGYP1QVi/V3yAUJ5uppvyfihnXQ3wO2REL8p52tL2cNcvNAUD1tvsHdBffqu/mt7k xxHVNRQV+7OqAw= X-Received: by 2002:a05:620a:4608:b0:93e:fcac:a91f with SMTP id af79cd13be357-93f17f9f371mr1747377785a.37.1792417872286; Mon, 19 Oct 2026 06:51:12 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:38 +0000 Subject: [PATCH net-next 04/15] net: skbuff: fail segmentation when a segment can't be checksummed MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-4-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417848; l=1895; i=josef@toxicpanda.com; h=from:subject:message-id; bh=wii8wzXlG4ePvSd6K5rd8H498XoB8iUyEaQEAS7r5bk=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QFNR28egIht/ZoRyU32fPc4iNKinzI14ufAnhDAIIBXEpJO58NOkbKAc331mB1ZlQKPGaXOwjPS ler9rEAlgTAU= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1792417873-C30CDB50-9953B032/0/0 X-purgate-type: clean X-purgate-size: 1897 When the device can't checksum the protocol, skb_segment() computes each segment's checksum in software with skb_checksum(). With SG on, the segments share the original frags, and a devmem TCP skb keeps its whole payload in unreadable frags. The devmem MSG_ZEROCOPY path never sets SKBFL_SHARED_FRAG, so the __skb_linearize() fallback is skipped too. skb_checksum() then warns and returns 0, and tcp_gso_segment() writes a TCP checksum that doesn't cover the payload that goes out. That's reachable with tx-checksumming off and SG on: sk_setup_caps() still gives TCP SG and HW_CSUM, so the dmabuf send is accepted, and harmonize_features() strips the checksum features but keeps SG. Use skb_checksum_full() and fail the segmentation with -EFAULT when it can't checksum a segment, as skb_segment() already does when it can't copy one. Found by the Sashiko AI review of an earlier fix for the same path with SG off. Link: https://lore.kernel.org/all/20261009-b4-skb-segment-nosg-unreadable-v1-1-7e2334a55fe8@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 40d2dd20d47d..88ed2dd99dc0 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -5239,9 +5239,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, if (!nskb->remcsum_offload) nskb->ip_summed = CHECKSUM_NONE; - SKB_GSO_CB(nskb)->csum = - skb_checksum(nskb, doffset, - nskb->len - doffset, 0); + SKB_GSO_CB(nskb)->csum = 0; + if (skb_checksum_full(nskb, doffset, + nskb->len - doffset, + &SKB_GSO_CB(nskb)->csum)) { + err = -EFAULT; + goto err; + } SKB_GSO_CB(nskb)->csum_start = skb_headroom(nskb) + doffset; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454384.1667977 (Exim 4.92) (envelope-from ) id 1xInln-0007o8-6g; Mon, 19 Oct 2026 13:51:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454384.1667977; Mon, 19 Oct 2026 13: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 1xInln-0007o1-40; Mon, 19 Oct 2026 13:51:19 +0000 Received: by outflank-mailman (input) for mailman id 1454384; Mon, 19 Oct 2026 13:51:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlm-0007lx-1l for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInll-00A1LW-Ek for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:17 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62054-bab6-0a2a0a5309dd-0a2a4504c640-6 for ; Mon, 19 Oct 2026 15:51:17 +0200 Received: from [209.85.160.182] (helo=mail-qt1-f182.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62054-b57f-0a2a45040019-d155a0b6a969-3 for ; Mon, 19 Oct 2026 15:51:17 +0200 Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-53394bffe0fso36178551cf.1 for ; Mon, 19 Oct 2026 06:51:17 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.241]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91bccc721a8sm97777206d6.12.2026.10.19.06.51.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06: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=1792417876; x=1793022676; 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=t5hhezvrkrPsILbBbBLRGuH3wT+463IdJ8u+tbtUXF4=; b=JTaaRUObGkbZOT2pl26Or9PtEENCK0/INMTY03Fn/TBOv8zjyRrLSBxVofouwX0T/z MItaZtFk9xyT5VPO2eYtpfMGd/3XyEv49/1oeOL2+aS4+cRukHymmgeFJ5WNt4bHtxD1 uqfBXgTgs5WiXv2kwT+cRAcoO1CBXuydiCf9SAbZDNM8wgEyGaJEEl+pZAYWAL237pxU OjY8FzMOO+DIe3+n7Ht+0vLgl7J8HB31JIlK1v2m3pLfyC6c9EL4LuGyGMDjhwGThKGz FV395XTsmVBRF9HiJ6DYbvsD5ZTqwP1QOrz4FLbViw0HnPQk6k5BSsLvNBjLAAuQYhIS jC6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417876; x=1793022676; 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=t5hhezvrkrPsILbBbBLRGuH3wT+463IdJ8u+tbtUXF4=; b=fL+BmL0eOCs68fZxyrRtSUUHTgtmzNChHQtyVr0tN2s0GTZT8EeOxakrh9pZncUUBr y4qoKSwCBfbWGr7g/QwXXHBxu9ZXYeBv5+TSXLa0hdar+58yp/2LvQl6pl4Q6Ss7ffG0 DmLDqEkkb9vOEreWAAiZX360G9HMW3Mbu+u6So61dNucwJs/EG2oF+7eobkmE3yIAW/t mEIIGUwmff1mz24Td6LiN2dY1Nk5hrHSAymbOZtFjMCIhor1xA0yPLmw4t4NaiwkPkbT vag+f/UcIyzd8BuUiWAovD/TjSP5FwJeLsGmokMfbE57qbo3v6VYexGQ9UoozLKsuvA8 eCVA== X-Forwarded-Encrypted: i=1; AKwUvBwyT1D/owRZAKgNLMeiXWKCD2TU/GETI0fzZQUxRw52K/TPnPppWo3XTdUY7WOPkA6yY90ZmegEHOE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJPlL2V2nLTD4M7ern94GSdJM8DFOFpe2+qPnV90eh/EKoKGnjN GAWyG7DDeNXOAVhhQx8IDi333RsFyWVRgtrrV+A34WZEPiggd1C9aBvsoHFDn1rUdNc= X-Gm-Gg: AYBFou0eQsDBk1peO29jXVAuL+ZKXwyMYO7gI/CMAHP5AtUIN75nKTSVSHllRSeVKDU RC3YeILOorG7GpkD+oJL2UOy1iJ3MPaXjkuQExQB1nL5ZRGDQcp5/yFKkE6uH2JmJJJIwh89y8F cc6iin9JyW+/u1EixH6LCcErm2NjShAoEBsW+DVDavJ6il17FZBvH11QsU/ZsgkS26OOkWmuuUZ JavM6xGjhP5Wo+RWYLwhtDyzVmUvdbCKboU6OfxidD2TcCmQOozmxi5pGujNpLzMM5rSatxqGJN +kaqqw09cUpCb0OTZrI3wL3h/h2vt/4/cm7QHoHZzDmCc1L02z93pUitFYaHqneYgr3psiCqDUg 0/NnJvcur59/0+F12HylBM6jT5TVBIkeNsKK0egWy2d2gbd61XN9DdtPP96n0pSRxpNdsqlXg66 lseNR0gPpflr8yz6RnqdH0Mw3rQYr1PCxo+C7qQakkx8P4uVuJgRO2J8mpx5cnh6We7r25kJ5C1 vt/mLWotjelW3I= X-Received: by 2002:a05:620a:a0c6:10b0:93f:2571:c30a with SMTP id af79cd13be357-93f2571d926mr888761185a.30.1792417875823; Mon, 19 Oct 2026 06:51:15 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:39 +0000 Subject: [PATCH net-next 05/15] net: skbuff: fail pskb_trim_rcsum() when it can't checksum the tail MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-5-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417848; l=1264; i=josef@toxicpanda.com; h=from:subject:message-id; bh=+TWKmcN/9YISrCDdUhnWQSTAcvPk81OG628CQR0a1S8=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPX/xL5smxia3f6ZS9PJYHyB/T8o2gs9Ov0UWXx8FV1o98bw8LukMOYZJRi8edA9qG013xP3J8r M73yrz78D0wI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1792417877-516D2B50-6B464BE5/0/0 X-purgate-type: clean X-purgate-size: 1266 For a CHECKSUM_COMPLETE skb, pskb_trim_rcsum() subtracts the checksum of the bytes it trims from skb->csum. It gets that checksum from skb_checksum(), so if the trimmed range runs into unreadable frags in a frag_list member, or past the end of the skb, it subtracts 0 and leaves skb->csum covering bytes that are no longer in the packet. pskb_trim_rcsum() can already fail, and its callers drop the packet when it does. Use skb_checksum_full() and return its error. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 88ed2dd99dc0..de433d452939 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -2829,9 +2829,13 @@ static int pskb_trim_rcsum_complete(struct sk_buff *skb, unsigned int len) int delta = skb->len - len; if (skb_frags_readable(skb)) { - skb->csum = csum_block_sub(skb->csum, - skb_checksum(skb, len, delta, 0), - len); + __wsum csum = 0; + int err; + + err = skb_checksum_full(skb, len, delta, &csum); + if (err) + return err; + skb->csum = csum_block_sub(skb->csum, csum, len); return 0; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454385.1667986 (Exim 4.92) (envelope-from ) id 1xInlq-00087t-Jl; Mon, 19 Oct 2026 13:51:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454385.1667986; Mon, 19 Oct 2026 13: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 1xInlq-00087Z-FH; Mon, 19 Oct 2026 13:51:22 +0000 Received: by outflank-mailman (input) for mailman id 1454385; Mon, 19 Oct 2026 13:51:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlo-00083x-Ub for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlo-00EegS-3f for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:20 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62052-2eae-0a2a0a5409dd-0a2a4509bbaa-10 for ; Mon, 19 Oct 2026 15:51:20 +0200 Received: from [209.85.222.176] (helo=mail-qk1-f176.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62057-be1a-0a2a45090019-d155deb0cd5f-3 for ; Mon, 19 Oct 2026 15:51:19 +0200 Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-93e503815adso194261685a.1 for ; Mon, 19 Oct 2026 06:51:19 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93f23eb7ba5sm842774385a.27.2026.10.19.06.51.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06: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=1792417878; x=1793022678; 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=ydoWrUsryFQCXy0qk0+H+VOsHqxoYPyCdAWJE4iSCqQ=; b=Lz27IJ4+i6Lb/GcZKjHjW8bh8IiJ6ctkSRMZhGRHtGpXFYXKAwJYKoDpv4roQnPsC4 Qq8UxyQrFXr874GXuXgV+ci/brwGaO3PC4HyAFztrxwq4O5MmmVq0dPnCX5BABWN1ZSv VBqGWIB8C8VBLYyCl8SKEPSH+G3t8dWSfXtZAC41dIdz83bcag2Gvd1k3vbF5dFLUbV9 84rdH4FroNKHsD6TZxIP5QHtZw/0+4ifKaNEiN4gNBRn5BotTeGHvRTiR8DYUTc/ySCp 4To5/POC4geZ8bSadjZ1iiouQdYpSkkcvaAxA/CZfp3LlpIkukYQ/cyiaaF5NNfosqgq ymrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417878; x=1793022678; 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=ydoWrUsryFQCXy0qk0+H+VOsHqxoYPyCdAWJE4iSCqQ=; b=C0p34dWBuGVXQuGyz4XIaVH7gmrRWVBd3aTa7kNeUBWz+WfzEpiJyMpSbicY29pkS0 R8v+019ETCA0nCP0J9cOh3ejtG/dHvXOwkYIv1dUPb9HdlWWwexZT2B06OkclbRMuQyK HxtI8dw4E8VxfniagcXllaoThhhgWiRf5DfGXcchwVBfm9magTTFzxJ7fR2ZKQCD0Wir GTYE8AIXq8rdoVQNHVZhbyHMOEihxRfOXdvIe4K1iviyiC68HmEpW7GKab9mg2xwbESH nm6V62wvKU+OPk9NqS3zeRYiK55vV39sBA0s3xzR87vfIiH/TSZnxsf93hSm7zLTJWFX /N4g== X-Forwarded-Encrypted: i=1; AKwUvBx1FuO5HAcbgk5Gaif+utjC3pslrb0+zyG7S979IA57SmAVqSzphbmEXWaADxQSgA+OIj9DP0s8E0k=@lists.xenproject.org X-Gm-Message-State: AFq9FYLgDkkCkg76dx+R4sdyqb9ObzhPE4bSlOksp1EkbGglbM9Jx6RR IhRLVrTn6pfS1sO9/h02ed0lp9fbCneIMPiBPbbe9eG9ssjf5CmumG/0ijsR2MKoGcM= X-Gm-Gg: AYBFou1zbKQqOFyMS4rcGCOudO/AGr7OQj2R+w6nrX+4DlSrbRSRAO0WWx0f7oCoOzX LTQwdHMnO1aY/7V5xxehSwtU/U6YLCg0CYQgEiygTHIm9RaJZyTW9gQSCg7o66zETdW5mJT/2Gr q66yHi9qFS5oBnU0ZxJRQ0Nyb2PsLjDf16l2N1lkADGzC56OXyBq3SjnSkByEiS6iEadAZelfxb jqgIdptP8Ri7VRnwEqM4zwhAA4rWIBcTekwxfRpeGGT/lnuY6mcmPJr/y0U4C2ny20F1eMHK1nB hDFjV9lwTCDAJG2l7XQfL2OC691V9mVimkO4jaGjF8hMVavB3ON/lCmAi5eEiqEUZeCtwFuauVA 9n9gIKCZ+y3Hw3BKZhjBSUk2nvWm6iGnZLgGDEWS1n1mlm/IUrJhmv2VuUFRpLz90aeLN9vcypW A98CVvn6NULu3xTZnhvneLxYeo3ngU0NVxxJw8CJ0zVTK7FxL5c8maQ+4YD90NcrdOglWPwQ5RR wUoWHwsvioT/bk= X-Received: by 2002:a05:620a:31a8:b0:93f:2957:39e with SMTP id af79cd13be357-93f29df1566mr1298617785a.71.1792417878389; Mon, 19 Oct 2026 06:51:18 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:40 +0000 Subject: [PATCH net-next 06/15] net: skbuff: add skb_crc32c_full() that reports failure MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-6-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417848; l=5122; i=josef@toxicpanda.com; h=from:subject:message-id; bh=4gDL1d1n3xZ9vhvHuHh+fxzaWH1kti0hEf02jn3aBlw=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNQsoPXudgIBCQ4amU4Ot8wGr4uN4l6ll3DjM3OCKkakLx6NEe8pB0UhGAzuQHiV90XwzqMDHE4 OA5x0AeiNWQI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1792417880-FCA16034-FA3C0552/0/0 X-purgate-type: clean X-purgate-size: 5124 skb_crc32c() has the same problem as skb_checksum(): when the range runs into unreadable frags or past the end of the skb it returns 0, which is also a valid CRC. sctp_compute_cksum() complements it, so a failed walk looks like a checksum of 0xffffffff whatever the packet contains, and the packet is accepted whenever its checksum field holds that. Add skb_crc32c_full(), which updates *@crcp and returns 0, or returns -EFAULT or -EINVAL and leaves *@crcp alone, like skb_checksum_full(). skb_crc32c() becomes a wrapper that behaves as before for the callers that haven't been converted. Convert skb_crc32c_csum_help(), which already returns an error when it can't fill in the CRC, so a transmitted SCTP packet that can't be checksummed is dropped instead of going out with a CRC of 0xffffffff. The SCTP and other callers will follow with the skb_checksum() callers. Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/skbuff.h | 2 ++ net/core/dev.c | 7 +++++-- net/core/skbuff.c | 51 ++++++++++++++++++++++++++++++++++++++++++-------- 3 files changed, 50 insertions(+), 10 deletions(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 969b1c3269ec..327a01a5d6d0 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -4329,6 +4329,8 @@ static inline int memcpy_to_msg(struct msghdr *msg, void *data, int len) __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum); +int __must_check skb_crc32c_full(const struct sk_buff *skb, int offset, + int len, u32 *crcp); u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc); static inline void * __must_check diff --git a/net/core/dev.c b/net/core/dev.c index 8eb9bf1ff9eb..1d34fa4544a2 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3738,8 +3738,11 @@ int skb_crc32c_csum_help(struct sk_buff *skb) if (ret) goto out; - crc = ~skb_crc32c(skb, start, skb->len - start, ~0); - *(__le32 *)(skb->data + offset) = cpu_to_le32(crc); + crc = ~0; + ret = skb_crc32c_full(skb, start, skb->len - start, &crc); + if (ret) + goto out; + *(__le32 *)(skb->data + offset) = cpu_to_le32(~crc); skb_reset_csum_not_inet(skb); out: return ret; diff --git a/net/core/skbuff.c b/net/core/skbuff.c index de433d452939..3b2a3747f009 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3788,23 +3788,41 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, EXPORT_SYMBOL(skb_copy_and_csum_bits); #ifdef CONFIG_NET_CRC32C -u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) +/** + * skb_crc32c_full - CRC32C a range of an skb + * @skb: buffer to read + * @offset: offset in @skb to start at + * @len: number of bytes to include + * @crcp: the CRC to continue from; on success, updated with the range + * + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb + * has unreadable frags in the range or runs out before @len does. On + * failure *@crcp is not changed. + */ +int skb_crc32c_full(const struct sk_buff *skb, int offset, int len, u32 *crcp) { int start = skb_headlen(skb); int i, copy = start - offset; struct sk_buff *frag_iter; + u32 crc = *crcp; + int err; + + if (unlikely(len < 0)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } if (copy > 0) { copy = min(copy, len); crc = crc32c(crc, skb->data + offset, copy); len -= copy; if (len == 0) - return crc; + goto out; offset += copy; } - if (WARN_ON_ONCE(!skb_frags_readable(skb))) - return 0; + if (!skb_frags_readable(skb)) + return -EFAULT; for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { int end; @@ -3829,7 +3847,7 @@ u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) } len -= copy; if (len == 0) - return crc; + goto out; offset += copy; } start = end; @@ -3844,19 +3862,36 @@ u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) copy = end - offset; if (copy > 0) { copy = min(copy, len); - crc = skb_crc32c(frag_iter, offset - start, copy, crc); + err = skb_crc32c_full(frag_iter, offset - start, copy, + &crc); + if (err) + return err; len -= copy; if (len == 0) - return crc; + goto out; offset += copy; } start = end; } if (unlikely(len)) { DEBUG_NET_WARN_ON_ONCE(1); - return 0; + return -EFAULT; } +out: + *crcp = crc; + return 0; +} +EXPORT_SYMBOL(skb_crc32c_full); +/* skb_crc32c() has no way to report failure, so it returns 0, which is a + * valid CRC. Use skb_crc32c_full() in new code. + */ +u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) +{ + if (unlikely(skb_crc32c_full(skb, offset, len, &crc))) { + WARN_ON_ONCE(!skb_frags_readable(skb)); + return 0; + } return crc; } EXPORT_SYMBOL(skb_crc32c); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454389.1667995 (Exim 4.92) (envelope-from ) id 1xInlt-0008UR-Sn; Mon, 19 Oct 2026 13:51:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454389.1667995; Mon, 19 Oct 2026 13:51: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 1xInlt-0008UH-OO; Mon, 19 Oct 2026 13:51:25 +0000 Received: by outflank-mailman (input) for mailman id 1454389; Mon, 19 Oct 2026 13:51:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlt-0008S1-13 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInls-00BvIM-71 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:24 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6204a-e002-0a2a0a5209dd-0a2a450bbf54-38 for ; Mon, 19 Oct 2026 15:51:24 +0200 Received: from [209.85.219.42] (helo=mail-qv1-f42.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6205a-b7e8-0a2a450b0019-d155db2ac8ac-3 for ; Mon, 19 Oct 2026 15:51:23 +0200 Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-91b52ba422cso27720986d6.2 for ; Mon, 19 Oct 2026 06:51:23 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.248]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91bd276eec4sm88112796d6.2.2026.10.19.06.51.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417882; x=1793022682; 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=YbXvQLGgZpsimSrfs+W8d8Jbr4mc/fISMihOBkAlu6E=; b=gNh0THi6i4S63sSBnXbJ+WIRxqTSmav0JyG7nia4l+GpvNsMDERIkJ4arHXIep1kG0 5ktnBvG4whYaAfhoUXUWN7W+5XiHU6WbFMqwj1q5gBMXAth6/43VUgA4CP3t/39EBZt9 VVtvrLVxOkrXhDeBvFIIB2sTsmg3ugnUo/6YSJwvr8kHI/ywQLUFihkfPXo6uHMazAj5 ENo5XIvGpupr5CYfyO0og2+/ls5ZpkC6JNkmqSPk12qi1elfmQY54lM039dJDijGdh8O k4LGEIF5433NjfEGMb7WfP0SrLgwMHrb67u5g7U2OXHjoNV1EzefnTOAwicm1gpy3iCF UpjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417882; x=1793022682; 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=YbXvQLGgZpsimSrfs+W8d8Jbr4mc/fISMihOBkAlu6E=; b=TNFdd1Vlgx9657eBxpaUx1do82jd68x22jSv0EWvhL/uxLqaBa4jSuhRaN2K6vDTWU 2NhPM70ClFs7YjeiJNijHPvQ+eTEYAf/R6M2p+fnNwfy6sTY8sjq7OQdsUQAdmOLn8Se eAXHHVL5J4+VbVu/MTP3QTS7xm0ie4VOdw9jcoOIBmwLvi6AMfq4Q53l2V/+/z1x6m0X 8jRGbEEsDlrgPBZOZwyaASlS+kGdYyLc6suukvFD8egH/x8lTun6GuBHshyg8uq7CydF Nt4uomV5jbeO+6QzpeD+W0+9KPdsMsCuuhU58rXXpj6tpsTjlPlEHjCI30YI/pgPd/X6 cMjw== X-Forwarded-Encrypted: i=1; AKwUvBzrpLonaSEbpb09AgWM+T+iowp3p8Bl5IoZRJxwYlY/G0q9lHw4hBO4nctqxCMx+8txn7p0KAFFtOY=@lists.xenproject.org X-Gm-Message-State: AFq9FYL7vN7A/D9kSUBCi9Y2+OugxbZlNT4oUeUS/MmiPvnw527Lb4yi eJTMrtv4dFngYbeOdAbR3cGffiFe3vgbMVyFJB0ecqygNFDTSv2c7LabLPgM8HvFqHY= X-Gm-Gg: AYBFou1pZnDqVcnMyjhtaVpKenvJyNjsP0bno4NW82kXSoIsgM5BGr4X7AHcbnXF6ia NKJii0DqnkM+21MMYyqN01Ayfc8hLVac2b4h/RLXeh131ZOBnq1Ahc0d8DPGrUt0LvXTwETyGXB f+YIrcYFEo26x+43v+aDxyUQ0bjw2ZwrZ0GtAJujZLzj3OQE27ZiUaKOeTlS9+LkPDPue0Mytwj BhbB00dGMGnbhFPuX0Ue792C8SgSEyraZkTftZWmPk8TWZ+l+vMszJkisRSw5GbrCRIwi9GBDSR Y2Lo6faBBvE/cAUy06JXCRRI4U33r/UlDOEesky0a8v4R0WG0uAmoyM9MVYDLYcBYUd4hf3Rwbg /x8JraHNDHEb6ghpVUN4VWzDoBTQw0lO5bJ+hEiFfO0mAoJU0Fn03YlU95dvYfT915pqkwB1N6I cJ2FOAaJ2kGLp4zWasQjQo1Zs/9RhM/BsCQupozty0cyO8rxHB5ebx4/sCKbCDJMCRAaSUG4B4c X8iPMFLTbc9hds9QXo4J9vlzcjxdGEfPCNVtxuRabs93dXrfLoQa06p2dK25qVIFFEkkHLsEuov 4QZ2iJrTdtwgAfYl0g== X-Received: by 2002:a05:6214:29e1:b0:91b:5d39:e145 with SMTP id 6a1803df08f44-91bdf63bb40mr141562036d6.58.1792417880639; Mon, 19 Oct 2026 06:51:20 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:41 +0000 Subject: [PATCH net-next 07/15] net: skbuff: let skb_zerocopy() copy a short skb without head_frag MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-7-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=3126; i=josef@toxicpanda.com; h=from:subject:message-id; bh=p1EJ3Mjc5nJGteUiFCelu7Pkg91i/fkjkkkh/ts8Tfs=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QB3VQkhmVt4VPOky68kfBhcPE1aOMyFJILHR1dQhl/DSlceDdzD2F0Osxoak/AkI08GCT1eWZyg KcJIYQOtx0wY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1792417883-A88C99EA-F91AD503/0/0 X-purgate-type: clean X-purgate-size: 3128 Commit 433380f5ab8f ("net: skbuff: don't BUG() on a missing head_frag in skb_zerocopy()") turned the BUG_ON(!from->head_frag && !hlen) into an -EFAULT return, but left it ahead of the small-payload path. That path copies everything with skb_copy_bits() and never references the head as a page, so the check doesn't apply to it. Open vSwitch gets there with an ordinary request. OVS_PACKET_CMD_EXECUTE allocates the packet with __dev_alloc_skb(..., GFP_KERNEL), which gives it a kmalloc'd head without head_frag. A POP_ETH action on a 14 byte frame leaves it empty, and a USERSPACE action then queues it with queue_userspace_packet(), which calls skb_zerocopy(user_skb, skb, 0, 0). That used to BUG(), and now the upcall fails and the packet is counted as lost, with a WARN on CONFIG_DEBUG_NET kernels. OVS_PACKET_CMD_EXECUTE only needs CAP_NET_ADMIN in the user namespace that owns the network namespace, so with the openvswitch module loaded any user can do this from their own namespace. Move the check below the small-payload path, so a zero-length copy succeeds the same way it does for an skb with a head_frag, and document the -EFAULT case. Found by the Sashiko AI review of v2 of the series that made the change. Fixes: 433380f5ab8f ("net: skbuff: don't BUG() on a missing head_frag in skb_zerocopy()") Link: https://lore.kernel.org/all/179173804997.434549.4450793967361922984@kernel.org/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 3b2a3747f009..735dd25213bb 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4014,8 +4014,9 @@ EXPORT_SYMBOL_GPL(skb_zerocopy_headlen); * Return value: * 0: everything is OK * -ENOMEM: couldn't orphan frags of @from due to lack of memory - * -EFAULT: skb_copy_bits() found some problem with skb geometry, or readable head - * payload would be mixed with unreadable frags. + * -EFAULT: skb_copy_bits() found some problem with skb geometry, @from has + * no head_frag and @hlen is 0 while @len doesn't fit in @to's tailroom, + * or readable head payload would be mixed with unreadable frags. */ int skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) @@ -4026,15 +4027,18 @@ skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) struct page *page; unsigned int offset; + /* dont bother with small payloads */ + if (len <= skb_tailroom(to)) + return skb_copy_bits(from, 0, skb_put(to, len), len); + + /* Without a head_frag the head can't be referenced as a page, so the + * caller has to ask for it to be copied. + */ if (unlikely(!from->head_frag && !hlen)) { DEBUG_NET_WARN_ON_ONCE(1); return -EFAULT; } - /* dont bother with small payloads */ - if (len <= skb_tailroom(to)) - return skb_copy_bits(from, 0, skb_put(to, len), len); - if (hlen) { ret = skb_copy_bits(from, 0, skb_put(to, hlen), hlen); if (unlikely(ret)) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454391.1668004 (Exim 4.92) (envelope-from ) id 1xInlw-0000OC-3r; Mon, 19 Oct 2026 13:51:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454391.1668004; Mon, 19 Oct 2026 13: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 1xInlw-0000O3-0R; Mon, 19 Oct 2026 13:51:28 +0000 Received: by outflank-mailman (input) for mailman id 1454391; Mon, 19 Oct 2026 13:51:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInlu-0000Ej-Qz for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlu-00A1LW-70 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:26 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62054-bab6-0a2a0a5309dd-0a2a4504c640-40 for ; Mon, 19 Oct 2026 15:51:26 +0200 Received: from [209.85.219.46] (helo=mail-qv1-f46.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6205d-b57f-0a2a45040019-d155db2ecdb0-3 for ; Mon, 19 Oct 2026 15:51:25 +0200 Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-917866225aaso19646276d6.1 for ; Mon, 19 Oct 2026 06:51:25 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91be8f89b54sm60221436d6.7.2026.10.19.06.51.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417884; x=1793022684; 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=8wxt1Epm3k3rT9QE881oEaKsrBbXJoueUEmgjTPk70U=; b=DWDFzEeAqUHzKs3T5WdGItjZ2R9poP75fwZRob4g67B5JYSsbf0P+Y6UGcsRPwFVqP 6nLRe7UOxSdNG4ecght6CtVbY7a6bFFwQdfWr02JOO0S9qK+ietx0R5TdNxc7C3uUZ91 NQ5AVPw1TDVMDvdjPiW9UIlAvAWQtGo94adiMkLXqcuJxbcxiwcwa3PBvQanxZGtb4TB glX6IY2BZlKdLqXrTlMf/zqRi28WHAbbo75Feo4nngiyec5vQWw3JDxWNJMj/RLyGvoL iwZpU34R4PMk03HEBkrMdkU8t+K6f9R0/Yl95L8h157pN9WH77x2ertFLcSVTpDtdnsi w8Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417884; x=1793022684; 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=8wxt1Epm3k3rT9QE881oEaKsrBbXJoueUEmgjTPk70U=; b=KEZfUDgTT8j0EHJtweZ5XW65UI1uRJJAsu8dENPmTG9Al9mTg9yjbpatcBXEFT1yNa jeSTtxuvmD6+/x/nH4De4CfYBn4Glxi45qYlv6VqJ6wGHGljNDNMpo9Jsp0krgj1KvFZ XQyi1SnXfrVJ53oJ8gQ7H10BVPtErRsxYhd6u5CHdy+5BtnxkxRZlKRFp6cNdrMDMGpZ f3+zckBlFeOpYcWhMIYm1NCDwuLpwSQFHeOoLglklaxUCrKwQLDa7J0WmtSPGBhHgTk1 b+zOvarUXvW4IktRRUhflNbcTLgxOMG1X2kM++ahdxsFXUvVrLTPUiQgM6kOWH/UUzfT lZDA== X-Forwarded-Encrypted: i=1; AKwUvBwNp5FdFAtaaFdX/R3BgYSCr5jyIrBr5Zq72dwfQdVZyq3OXfW24/rmAmYJ9wLHO5yhpv/DFy4565Q=@lists.xenproject.org X-Gm-Message-State: AFq9FYITjSbc5qJR1n51RQiiGRFSD3+OAObDFdizmMwWbFjIRrhXjpos AymbB7hlEfqYcZbMgfOgSVfAZkAQcXNd4g0RxhGWDqXu8k2eC3SLhq6gwzm9ebzJ9sk= X-Gm-Gg: AYBFou2lhbWlfaeEhdLXMcoaMLkNdUvFSc+7yGKyenzUJwmWN9vxn6CYadfe6Tv1/8u dw+V8ZGxxANe49ZuZx2MiB0a/aHKmHhpp7ARn1B/1QWvw5HFUrHyBeeGa4oHPozk3bSg9nDANjH Nb1NHrFeN7PTl6Fm3lJI+UcJFGq2ZYlwZ3JzOmC+6u+nPwlwVuy32pyxm9t+H/CT+tf39K/I57s oTiikpB6tGOUEJBRh1yQj+X8QcsJG0Tn00Al7m1xoPlv4CWyw898LSZJ2tqNUlRHdt6XlVC92Y+ ++dTJGw1fGjSR16OrblA1Yr8EsiUSNfDhGF4FvxQapilRISLAAsYlmPvGWpV4VIAW94M92/c5Ll rS9N6C6QVKpemBOBh0Do2xnG+s2lZf6hMhMTK02a339oob+CW3inxjakiKHZl9go1KbNFpZPePC yYg5htdJ9vXG3TbAVYtFbe9q3zIZtzbBkx1WzekXsHAZXVZxNX4c34EDFQ+jDncoygJblvpUspT 6vZjS+zfoulH4w= X-Received: by 2002:a05:6214:2022:b0:917:a5f1:1d45 with SMTP id 6a1803df08f44-91bdf165a4amr140313536d6.32.1792417884537; Mon, 19 Oct 2026 06:51:24 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:42 +0000 Subject: [PATCH net-next 08/15] net: skbuff: make skb_try_coalesce()'s len unsigned MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-8-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=2184; i=josef@toxicpanda.com; h=from:subject:message-id; bh=GLGsUKpELPU6q+dQsnPVRh/KHoYno5QlglXwcqwsDWs=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNC9Sgvy7Z40iKvcRhA58lXebwfW6QGNAPE2IPZxOaOYraxtzaaXcB+Os+4BjcCqUxdgTwJlErN lVW88RefeTAY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1792417886-C2ECEB50-00852B0E/0/0 X-purgate-type: clean X-purgate-size: 2186 skb_try_coalesce() keeps from->len, which is unsigned, in an int. A corrupt from->len above INT_MAX turns negative and gets past the len <= skb_tailroom(to) check. Commit 279877d86c82 ("net: skbuff: don't BUG() when skb_copy_bits() fails in copy helpers") moved the copy into the tailroom ahead of skb_put(), so that check is now the only thing left in the way: skb_copy_bits() clamps its copy to the negative length, and memcpy() takes it as an unsigned int, so it becomes a ~2GB write past the end of @to. Before that commit skb_put() ran first, and its overflow check caught such a length before anything was copied. Keep len unsigned, like from->len. skb_tailroom() is never negative, so the tailroom check then refuses such a length, and every other use of len already takes an unsigned value. The truesize sanity check compares the int delta against len; spell out its delta < 0 case so a negative delta still warns now that the comparison is unsigned. Found by the Sashiko AI review of v2 of the series that made the change. Fixes: 279877d86c82 ("net: skbuff: don't BUG() when skb_copy_bits() fails in copy helpers") Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 735dd25213bb..5c89c463f234 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -6392,7 +6392,8 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from, bool *fragstolen, int *delta_truesize) { struct skb_shared_info *to_shinfo, *from_shinfo; - int i, delta, len = from->len; + unsigned int len = from->len; + int i, delta; *fragstolen = false; @@ -6463,7 +6464,7 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from, delta = from->truesize - SKB_TRUESIZE(skb_end_offset(from)); } - WARN_ON_ONCE(delta < len); + WARN_ON_ONCE(delta < 0 || delta < len); memcpy(to_shinfo->frags + to_shinfo->nr_frags, from_shinfo->frags, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454398.1668013 (Exim 4.92) (envelope-from ) id 1xInlz-0000o3-DG; Mon, 19 Oct 2026 13:51:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454398.1668013; Mon, 19 Oct 2026 13:51: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 1xInlz-0000np-8m; Mon, 19 Oct 2026 13:51:31 +0000 Received: by outflank-mailman (input) for mailman id 1454398; Mon, 19 Oct 2026 13:51:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInly-0000lk-D8 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlx-00Eeji-Q4 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:29 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6205c-2eae-0a2a0a5409dd-0a2a45019992-6 for ; Mon, 19 Oct 2026 15:51:29 +0200 Received: from [209.85.222.179] (helo=mail-qk1-f179.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62060-5984-0a2a45010019-d155deb3f1d9-3 for ; Mon, 19 Oct 2026 15:51:29 +0200 Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-93f079a63b8so201007185a.3 for ; Mon, 19 Oct 2026 06:51:28 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93f3cb855a0sm338770685a.4.2026.10.19.06.51.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417888; x=1793022688; 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=i59cwFpnwV4ZWelO27hAghlfIgiy6O8zXnZ0ftvy/nk=; b=ZNzA/lhi3PNJOevdLe0ROC/XpYzghL8wZKBpiXXKkEin3qfvL/AAVf/KcTqs2U60ra 0j+SwOLvafgojm1ZMIH0fik6Fvmu6LtUPUTW+nNPLgZnskLo3d95LvFfMXwJTpuaedeP CHzkL7TyMHcdz20uEfFXz+chO6QkNwCpswe/POHWLUQ7uyN7sJNwsNyo0tLQfHlNh02s G+GgH8tS0LwaBXfcOSyQkeWkYmovxAt22NYGdW9/plUB7VDk49aRN4cmDCsRhT4JFHAl pqnKXpBxO0gPoySIpOgOA8IE7la1RA9yLCMtPn4SEBjr6AR8CJs6b5r8sCkChF9DKm4L eeUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417888; x=1793022688; 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=i59cwFpnwV4ZWelO27hAghlfIgiy6O8zXnZ0ftvy/nk=; b=U/CpioDGYttjIK1Aun/GdJCfS/5L1JRK3/A4AJQ/uvLl4QAjUvXSGEW17+hOm+cPIh 6uLRTuwp7cN1aK8Hu8SQsb6v+KFJSNoQVKnUcBdPulY/jKpWz6JDdupK7fTpiehBbV/9 JYXxpE7QQ5ax3bXkwRy2IrdTqITpdJSjPEWiI7ppU1JlMpUpjkvTYPLVmoq++4V94imA F9Sd8s16PobNRFhrrw9WrutXactXJgv+sIdYmD+eMP7nene79LsjNaQOycXwGMjWHrju dfI4yElI6EvL0O3KQNDS8mVhiSCGorRS1TjbCGms1h3EAdQecRFAiuQ8NHwokalYqrBr 3DWA== X-Forwarded-Encrypted: i=1; AKwUvBwAihHDI2PAtQdEmmWauNkeV8ZIjW4TfXyiA26J9ntDFfhXs86pqn0y52lYQvdXZPpn4Zm/G7X4C/k=@lists.xenproject.org X-Gm-Message-State: AFq9FYIwzJ52ddP9uVt8rula/jpa+sh36DqETvtibDAbVf8j1nOGwN+5 UgOV52rZfeK1DRcdeA0uLqlgNzuyV7JvhPByiDUiNBsV+ExzZp5V75Mz9tV49odWb+Kh09akyv2 NFkbO X-Gm-Gg: AYBFou2Rg+/3NVGyhW7eTA6i+9PVisbDHMKtqLS9BL+2ugF6EJN7kVj+QBIjU3pGSYn PlWg3ebETeEB7X6zacMBU8Ljm0PnEV9E1cHv6IO1GreX1znWMmt/StPvFD7SPnW1dj6lMHXu6ly KFW9/7a883JUIeZi3fo6/EoEkf8Qlz2GHAoffjvVT2l9MyxuNSENNwrQoNT5hwD6aGZj/DwQTGm DRe+BGaH0e3ii4pBhPSOOlnAkTi/RmaWWwKmm0qMvLW7boWIXZipEPKf+eD0nq1gLEqU1QKH9Bq fXsQ2yhWjpttwzB8FVqqFt3x8Kf5LHmIP8hwpQ0pwcxMDKg1K4WQAkAtP6+LSSWS+QX9YDIUXzi 3OVR61a5XFjEUrUv/AHsP5Q6pTogh8TRxwqJkfnaK7F+4+ZqPcDK20JbLnULLvr/6GVekFhnkkx IfHXgYGWJyjN7bgjE37M1inXbjdAMP5Z7vrNN7LstF5oHW6k7mdbXFvfG0y/UpkahgUAx1VHyeB FBB4ml8c88o2dE= X-Received: by 2002:a05:620a:7309:10b0:93f:322b:2209 with SMTP id af79cd13be357-93f322b2321mr606237085a.28.1792417887551; Mon, 19 Oct 2026 06:51:27 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:43 +0000 Subject: [PATCH net-next 09/15] net: skbuff: check csum_start against len in skb_copy_and_csum_dev() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-9-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=1647; i=josef@toxicpanda.com; h=from:subject:message-id; bh=sxMOxEm7hnqJ4JHjLlLYqgrWX5cOQpVgaNwl3bOsGCc=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLHbIa3sdMEeDl3ey/+03pKmEjvdf6OVqCc90eTylLEjn32s0tlhlr2FYQHUU3Yl4h7USrA20K9 UzEGPZt5vtgo= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1792417889-1F66C757-BEAEB250/0/0 X-purgate-type: clean X-purgate-size: 1649 Commit 56453199d28f ("net: skbuff: don't BUG() on a bad csum_start in skb_copy_and_csum_dev()") checks the checksum start against both ends of the linear area before copying up to it. For an skb that isn't CHECKSUM_PARTIAL, though, the checksum start is skb_headlen() itself, so the check compares it to itself and can't fail. If data_len is bigger than len, skb_headlen() underflows to about 4GB, and that becomes the length skb_copy_from_linear_data() copies into the driver's bounce buffer. The old BUG_ON() had the same blind spot. Also check the checksum start against skb->len, so such an skb takes the existing fallback, which copies at most skb->len bytes without filling in the checksum. Found by LLM review after the series that made the change was applied. Fixes: 56453199d28f ("net: skbuff: don't BUG() on a bad csum_start in skb_copy_and_csum_dev()") Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 5c89c463f234..782a6bacd568 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4103,7 +4103,11 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to) else csstart = skb_headlen(skb); + /* skb_headlen() underflows if data_len is bigger than len, so check + * csstart against len as well. + */ if (unlikely(csstart < 0 || csstart > skb_headlen(skb) || + csstart > skb->len || (skb->ip_summed == CHECKSUM_PARTIAL && csstart + skb->csum_offset + sizeof(__sum16) > skb->len))) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454400.1668022 (Exim 4.92) (envelope-from ) id 1xInm1-0001CF-Ou; Mon, 19 Oct 2026 13:51:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454400.1668022; Mon, 19 Oct 2026 13:51: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 1xInm1-0001Bw-KY; Mon, 19 Oct 2026 13:51:33 +0000 Received: by outflank-mailman (input) for mailman id 1454400; Mon, 19 Oct 2026 13:51:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInm0-0000xs-70 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInlz-00Eeji-JC for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:31 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6205c-2eae-0a2a0a5409dd-0a2a45019992-14 for ; Mon, 19 Oct 2026 15:51:31 +0200 Received: from [209.85.160.173] (helo=mail-qt1-f173.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62062-5984-0a2a45010019-d155a0ada50f-3 for ; Mon, 19 Oct 2026 15:51:31 +0200 Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-5351d76e1baso27243231cf.1 for ; Mon, 19 Oct 2026 06:51:30 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.249]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5367c3a016asm8422981cf.25.2026.10.19.06.51.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417889; x=1793022689; 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=NueD3KcSYkb8JdZSOJlKL8CiOB7BO395X3cXr1iZapo=; b=EVqfCMiXD1sTuugn6xQ4dcs9RsIkXJ3Gn9XIvA31AXkjEoyJu/rxk33oP78JkA1xok E/CoWh+06LF8BjNhw3fM5Ap1aGYdcV/Eq4tBaXRvcTufzKYMRuPrwZU6zBW9ee65hRGf 8kfT3gpqi9ChRFAh387WXtktn/Q3ueS1Ji1wISERG8F6A1CPEgx2auG4Fsk9PVm61v52 GDP61YlZcB6vEnjDb9/nXd5y1Apy09xPr9dhUlZKXugaJUDOZKAKNFlKtmTUrvHQKMsW QPX8cGJfZkiBJVbWNIBrSDh47/dX/z12beXRX4QC2LKCJ8XvzyRtG1ySSjAoI+nKqK6T q83Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417889; x=1793022689; 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=NueD3KcSYkb8JdZSOJlKL8CiOB7BO395X3cXr1iZapo=; b=tgISfSOvgLVGtROqAjxXW43F1YL/OFV26hbSq8t5rluqyNKe7hBhuv2T3F1Mnx0rMA 2yGHADPMRs3ZrjikFf5TbuzFpiU3o29sR291sCx0sdH7bKFIEB5s8TXpwwYK8WeHS+Qy vO8brAcnXwjVZEO4glK/sBN/dctXJ4XZ/lryWBLIUHTrfLni2vnMgqDvCzbdR2kh8UhW PtFtT3smNx+FeM+zdzB7c6cEK0RBMss596bJND8/H0Jfs9/+eMxLUXSxpLZmKDO8r95X +fF5+ylR66GdZz99V40ayzi4l8O2O1hDLofMebnnWe9ms6lHPoKaZx8oI8BW5O4AYAQO bagQ== X-Forwarded-Encrypted: i=1; AKwUvByJOriKkpZbxWgZLvfcxy1d1Fhb/KO/WK89OcfhjzEPtMD7kkBPYgL71WnzGrrjN9qdxb6vVewr4Rs=@lists.xenproject.org X-Gm-Message-State: AFq9FYKLA1/VQQX/NuCcZEs39jCp54PizJioCn9eqDLHY0zk7X+v/GPy pL/Bjv1Xt2eQ+QXab17XvdqIhkn8nfRSRIUviDWYqVD8uH1jZNbBsirsLwXKaA64Lsw= X-Gm-Gg: AYBFou0sjRxu1Wv/mFBjsPbWe4+56bAwsVbgoVJKl/6aQ8ddxvskG3qXkbtPciU1G3j JyyVw+iWxod4e1vTn+X84R5Ii+7nI+Ue3wfTLkF9n2oAkv1nGJh2q4rdC+h8Oxq8Ua850BtfVdP 4fpeJyEfYK3yl4itkIsL+0uswAs5xjYd06joHvUhCzg+xFXjTwYDyvMwGZ5QbceyyMDkYyxWATN KZmhJPy7ZJDUJZfv/7cIQ0vnUo32hf6umPkK52ha/NYSKhe2DA0JkHCXuZAJ6C/JiYisSeS5PIb 9aPWz/eqz4yLDVALnVsdlt6NFLzeOZblXXdZ8GMEkvcOlCie6iF1iJmC7rFVLv/9rwPRCY9qHnD H7GB+WZYl+IRSsV7Oum2HDhGqxE+G3hHhhyeALvlzTXKJCorvdjySqI8L2fCUuwPn6Atzcz60fF Lh8Xi9d/O9gshW7jehulcX1INOgFP6GqaRMfkLJnMnwYHGGVfM15bxp3gz4iWw3rZ5OADcWtZ9y rwg9q7GSYl7npQ= X-Received: by 2002:a05:622a:120f:b0:535:1d5b:a7fa with SMTP id d75a77b69052e-53645fcfd95mr105600221cf.14.1792417889532; Mon, 19 Oct 2026 06:51:29 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:44 +0000 Subject: [PATCH net-next 10/15] net: skbuff: reject a negative length in skb_copy_and_csum_bits() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-10-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=2599; i=josef@toxicpanda.com; h=from:subject:message-id; bh=II/CP7Oe6pPmnThcZPqfbajOFeQVtnEAdIjZymwWmTI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLT77d+wO2aZJcnSaM7dE9IczO8S8pXOJ39O2d4Dqx9woYqiJPcR/OP7dZYvy9TOeJvXuBMsRjF HbZ69mG6gdAs= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1792417891-1DC79757-C005D083/0/0 X-purgate-type: clean X-purgate-size: 2601 Commit 417261779eab ("net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()") guards its zero-fill against a negative @len from a broken caller, but such a @len never gets that far. The head, frag and frag_list copies all clamp their length to @len, so a negative one has already turned into a huge copy, or an endless frag walk, by then. Reject a negative @len on entry with -EINVAL, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels, and drop the guard on the zero-fill that can no longer be reached with one. Every caller already handles an error from skb_copy_and_csum_bits(). Found by the Sashiko AI review of v2 of the series that made the change. Fixes: 417261779eab ("net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()") Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 782a6bacd568..56cec58bccb7 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3678,9 +3678,10 @@ EXPORT_SYMBOL(skb_checksum); * @len: number of bytes to copy * @csump: where to store the checksum of the copied bytes * - * Return: 0 on success, or -EFAULT if @skb has unreadable frags or runs - * out before @len does. On failure *@csump is not set and the part of - * @to that couldn't be filled is zeroed. + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb + * has unreadable frags or runs out before @len does. On failure *@csump + * is not set, and on -EFAULT the part of @to that couldn't be filled is + * zeroed. */ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, int len, __wsum *csump) @@ -3692,6 +3693,14 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, __wsum csum = 0; int err; + /* Everything below clamps copies to @len, so a negative one would + * turn into a huge copy. + */ + if (unlikely(len < 0)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } + /* Copy header. */ if (copy > 0) { if (copy > len) @@ -3777,8 +3786,7 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, if (unlikely(len)) { DEBUG_NET_WARN_ON_ONCE(1); /* Don't hand the caller a buffer with stale bytes in it. */ - if (len > 0) - memset(to, 0, len); + memset(to, 0, len); return -EFAULT; } out: -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454405.1668031 (Exim 4.92) (envelope-from ) id 1xInm5-0001Xl-48; Mon, 19 Oct 2026 13:51:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454405.1668031; Mon, 19 Oct 2026 13:51: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 1xInm4-0001XH-Vv; Mon, 19 Oct 2026 13:51:36 +0000 Received: by outflank-mailman (input) for mailman id 1454405; Mon, 19 Oct 2026 13:51:35 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInm3-0001UC-Pe for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInm3-00BvLk-62 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:35 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6204f-e002-0a2a0a5209dd-0a2a4508eb24-44 for ; Mon, 19 Oct 2026 15:51:35 +0200 Received: from [209.85.222.172] (helo=mail-qk1-f172.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62065-f659-0a2a45080019-d155deacec3b-3 for ; Mon, 19 Oct 2026 15:51:34 +0200 Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-93f30660e69so119154585a.0 for ; Mon, 19 Oct 2026 06:51:34 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.240]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93f1a19ce5asm982035485a.32.2026.10.19.06.51.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417893; x=1793022693; 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=nH4MPLjNHd0ezQ30G0wFNIQg5eWAqIll/99R00Ry+f8=; b=HJycgKfVpopbg+81JhnS99qSjXtN/UGTeqRRH6F218Bor7xkxPEVJMAiLSDKMIGSP0 SkpU0v/2nOtHzo9tcBrJTicOg+bhjHDFcmaoyfQaV3FarKnvbAQkVjq+84sIkI07wMew feEXDLS5fJky7a4Eegy25XMMLUXb+jGu9Ks5skcl5tQgpnQgsm3rwm+GwaVwAyuNxCWN 7REm36IRThC3GA11QR8Vu/dmII/3s8FwL1OLVr5qeFF/mSI2swOE2c6DyKY+jwi6aI8N 4SlccIc1+BBqprmthvM8EmhWGdFINgDpVv/zNniKBXXxjHZgTxTKb71yVpJFBCHZZFqj rxwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417893; x=1793022693; 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=nH4MPLjNHd0ezQ30G0wFNIQg5eWAqIll/99R00Ry+f8=; b=W4TPIfmI8P9ISQ+aaktvuYY3FDvoqN3dE3WZSOAURi3Kya3o+0O6t5GAa1d6QFEnVa W2YsUkVCGxWGwWUd3urCx7OmrbSuXU8BM9rRg3Mn4wycDX2AV7puCPUKUtsvAJp3Nsly WgaNOg39mNlrtNApRJCCTTc396caVezMUhGX8/PbkjjLNS1F6givwhJQ+CCo0k4jTXY9 TZUoWx3CJ2sBcfjNpFJ8fD/D8yvfQeoocTSsREIWVyrgoN+HI1+XA01rnizCvl6zP37L iQCBHSFxxF30p3u6BEDX1ZkdmQHUYZ1scOcpzxKHLCQmFiTg2ha+cmLNdb0s6JUiiknh qI8w== X-Forwarded-Encrypted: i=1; AKwUvBwSDHA/2zLWn39w2cnUH9f+c66ktYw8Z6vgjpR9fNeZfR5V5M4HAuqcSYarnggldVVZBoDcWJ7B1XY=@lists.xenproject.org X-Gm-Message-State: AFq9FYIMacVqxJi4r9vsqYJ/Ct/9MO3hDGORSw+6lwFupYxEVEQZhvIP Sy9ems5MpYvao9rn5fyFs1sDawnob2aAZIaJFE763iWpJOxOmgvLjV3iLPR145GYOio= X-Gm-Gg: AYBFou24+F1U311dQoS8GQk5s1qKMfL7MiD9Lzk6pitX4/rTV1RautOVHCnD716eYTW f368782dl51rZHlwZJ4tHRS4gZH3Vwr0qTCH4Giz389ciIcaAdrnpRiWiFEgeUyrQpCCGDYvdMy GBWgcWz0OAs8tqt0HNk+7gjFQLyMnqwP4ztcjTE1D4oKPoQJjmXIrYyvuRQFu6+TtSIP/Z4TNJn IlOTR4Pfv0RKfqZLmPHpxpypszTkqYvZBg/Y1G9iJMzWxxZzvbk/w5L2XjU3PS+a+U8PoLqcbrH CTKWxcPSNb3AkbgP0vEUG/vcWuEcm8B2IBavc7pYz4q8wy5ivyGRWOpZLRhisyWCfqDF6Fb2t3V d9f+fxM7IzcslcXqWsML4PU2QGFW45QPM13YCo6/AEXZk7ESNJpiKbCWHqrajQ/Q/exIUxM06i3 b0Qz8RA6vrZrSLPpjfG/vOYXsbFrolufTnpA2jV/ziuEYdf+lp1VWpMYZ4YU/K+JIz4U8t/2nhL f+GpRA/8zKq3hE= X-Received: by 2002:a05:620a:4109:b0:93f:35fc:5266 with SMTP id af79cd13be357-93f35fc586emr874742485a.44.1792417893366; Mon, 19 Oct 2026 06:51:33 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:45 +0000 Subject: [PATCH net-next 11/15] net: skbuff: refuse to segment a nested frag_list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-11-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=2113; i=josef@toxicpanda.com; h=from:subject:message-id; bh=6Z8CiNviIyVdg98sCBaRoAUJsHn+RV3Sx5RlE56aqBo=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPevlwc09v/MSkDiCKh5chGO+Z/rqVC5uo+IAjB+VXJ5WH8Ns5cSB+345mYyBpXOXcO+Ul5ANjw NRhLiDZ+GoA4= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1792417894-CC77387B-E55E12C1/0/0 X-purgate-type: clean X-purgate-size: 2115 skb_segment() walks head_skb's frag_list, but for each member it only looks at the linear part and frags[], never at the member's own frag_list. head_skb->len still counts those bytes, so with a nested frag_list the walk runs out of members while it still owes data, sets list_skb to NULL, and dereferences it on the next pass, before any of the layout checks get a chance to catch it. Nothing in the tree is known to build such an skb; GRO flushes instead of chaining an skb that already has a frag_list. Check for it up front and fail the segmentation with -EINVAL, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels, like the other frag_list layout checks. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 56cec58bccb7..b6ada54ecc57 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4962,6 +4962,17 @@ struct sk_buff *skb_segment_list(struct sk_buff *skb, } EXPORT_SYMBOL_GPL(skb_segment_list); +/* skb_segment() only walks one level of frag_list. */ +static bool skb_segment_nested_frag_list(const struct sk_buff *head_skb) +{ + const struct sk_buff *iter; + + skb_walk_frags(head_skb, iter) + if (skb_has_frag_list(iter)) + return true; + return false; +} + /** * skb_segment - Perform protocol segmentation on skb. * @head_skb: buffer to segment @@ -5023,6 +5034,16 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, sg = !!(features & NETIF_F_SG); csum = !!can_checksum_protocol(features, proto); + /* The walk below never looks inside a member's own frag_list, but + * head_skb->len counts those bytes, so it would run out of members + * and dereference a NULL list_skb. + */ + if (unlikely(list_skb && skb_segment_nested_frag_list(head_skb))) { + DEBUG_NET_WARN_ON_ONCE(1); + err = -EINVAL; + goto err; + } + if (sg && csum && !gso_by_frags) { if (!max_segs && !(features & NETIF_F_GSO_PARTIAL)) { struct sk_buff *iter; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454407.1668040 (Exim 4.92) (envelope-from ) id 1xInm7-0001vh-FU; Mon, 19 Oct 2026 13:51:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454407.1668040; Mon, 19 Oct 2026 13: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 1xInm7-0001vW-AM; Mon, 19 Oct 2026 13:51:39 +0000 Received: by outflank-mailman (input) for mailman id 1454407; Mon, 19 Oct 2026 13:51:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInm5-0001iN-SW for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInm5-00BvLk-94 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:37 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62067-e002-0a2a0a5209dd-0a2a4503a8e2-4 for ; Mon, 19 Oct 2026 15:51:37 +0200 Received: from [209.85.160.175] (helo=mail-qt1-f175.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62068-fae8-0a2a45030019-d155a0afa45b-3 for ; Mon, 19 Oct 2026 15:51:37 +0200 Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-53639b8903bso30467561cf.0 for ; Mon, 19 Oct 2026 06:51:36 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.240]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5362a8e43cfsm99302081cf.5.2026.10.19.06.51.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417896; x=1793022696; 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=cCcET6n/yfDRwSzhWgNa5UxSYwstO6x0SjXdcG6UWRc=; b=Ki8JxYBcjsJryn86TTCTg+NU48IOxRBs0/TCY7mYKlDaI6wTJ1uJUJGDzp4CUh8PYy BzmNLHiXeqcn2uyYB0LiulSrg/alaKFBGxCWsAJsOQmciSEn/ZMcj9dliJH1NPj5LGak u6AcYuDkHw1apJj2mPJvOFv1rTd0j6+1wBqmclKA9SITFbQ7WWGaqCzDqW7I/L7TaBkE mlaSLJtrnoogHvhAvgbdwW/wFIgaegxRFs2J5ThlPD8bTSueOx7ZNF4mY6EAB4jrUJcO ZLSvOXRFPVu4dozViuKjcr5ZLmhZEtrd3FrcT+NUilTvBXtOFvx86yYqjCgEbF+N7ah0 WKww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417896; x=1793022696; 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=cCcET6n/yfDRwSzhWgNa5UxSYwstO6x0SjXdcG6UWRc=; b=FMIFR+1KT8GBQGn6nqLQO4GNbTlOuCLFqHRBYN17+Pqlb7hDtvRo63O6gdUVpf/5eu JOPsq13QcoE/EK3470QYwXOH2sJz5VVl/gMJYtQ/k+rfn78ReqDW6LHPGc2jqqomgLW0 TWebR2lzOBUoKt1q2O8EY9lD0bVvg7obvs3NdwE+CXhjiVJt9gf4Hyz9rcNc4jw2vKPJ ZSSFdNU7D4W/1U/zAma3e2mWj2L4lVXvNSt/Z19QZsOnuEFidsRgaa7OHepVWWuZAgLI UO6795DK8WYng/q4ucKH3e/ks1/pqQuN2l76MTclt2l6yIfUEl3Wsw4ikTEqoTWOdISZ M2QQ== X-Forwarded-Encrypted: i=1; AKwUvBy9eIksUe2ZX7DLwk3bMC+sRPjKr++WkBYTarOn4i9FzyiH1MsgammNa1p4dElgN/HjtE3qHCFzEbw=@lists.xenproject.org X-Gm-Message-State: AFq9FYKmh3Hr76odmGXOx2od97Yh7AxYxzOLHWsfVzNdlpVVMm5b+syU S9kw6K5Lsx4DtEClJpuzFHuVsHrfmgHzx2RpfA0M8e+poY5DG+qANdafXnPWZokVx2E= X-Gm-Gg: AYBFou1gutnFIV80HiafyhlRRgiXo6RIOo/S69iQxKLGuMYrIXgSkPk16ZkB4snROcK /psZr1VbEV9L+PSn8cZcABBf3OIhi/wnj6jeaAH1xRWW+FjqkWL4Hmmm+JCP1bQuqnY4D2jdXWd XLUTUp7Y/bDaZwTc/Oi5aUqD3NhkbTTP/FZdRrEbqPAPyB+X9CyOBveMzpmIscT/DgSQqYbeeYh A3KGTrg41ezWGYFg0pwuUYkUYJXO+jSzeTeVOpObl61d30l8X+VDM16b6WXdmvnY+upCsH3ENXW 02LAkg9AEkXoxyczp5iUc8ogRlbRB7HpSb1IjDfs3QMq1DU5k5YAMRnvvOpMBgxtpCtEGOPw1Bi EL8zTFDqRlhdnjj/6Fgjy58Z26GspV6OAQMS1d2XtsOa1kKoLwagiiSWyOHgEd3yz7lXIJcZQUr UAPjBCAoxCpr9nWl0ytwkFGjfujD8aX9ewaCVGPpWsK0dOK83GzFSu/lboq1fjBjnEtwtNd21L2 jQj6I3UDfbSWJ4= X-Received: by 2002:a05:622a:8449:20b0:535:22e8:2fd3 with SMTP id d75a77b69052e-5362725afb9mr117803081cf.10.1792417895776; Mon, 19 Oct 2026 06:51:35 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:46 +0000 Subject: [PATCH net-next 12/15] net: test the frag_list layouts skb_segment() refuses MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-12-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=3190; i=josef@toxicpanda.com; h=from:subject:message-id; bh=54YuJC4Sa4ftFWTwcdr1JHSPiV0/4B3b8lTqh1NoeIM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QMl/CfrGUamcaF3Ng1FUVBnBIHC3kZ7QHRED94+HWu2IRKE9xF6ZECYluILceDZSaJN+2T+BFcn /RZqmOf7s7Qg= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1792417897-6C2E04E9-2BCDB0C3/0/0 X-purgate-type: clean X-purgate-size: 3192 The GSO KUnit test only checks layouts skb_segment() can segment. Add two it has to refuse with -EINVAL: the non-uniform frag_list with SG on, which used to hit the BUG_ON(i >= nfrags) the existing test steps around, and a frag_list member that has its own frag_list. Both warn on CONFIG_DEBUG_NET kernels, so run them with the warning backtrace suppressed. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/net_test.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/net/core/net_test.c b/net/core/net_test.c index bc2ef7612e7d..12a175268a01 100644 --- a/net/core/net_test.c +++ b/net/core/net_test.c @@ -39,6 +39,8 @@ enum gso_test_nr { GSO_TEST_RESEGMENT_MULTI, GSO_TEST_RESEGMENT_TAIL, GSO_TEST_RESEGMENT_ONE_MSS, + GSO_TEST_FRAG_LIST_NON_UNIFORM_SG, + GSO_TEST_FRAG_LIST_NESTED, }; struct gso_test_case { @@ -57,6 +59,9 @@ struct gso_test_case { unsigned int nr_segs; const unsigned int *segs; const unsigned int *gso_segs; + + /* skb_segment() is expected to fail with this error */ + int err; }; static struct gso_test_case cases[] = { @@ -204,6 +209,28 @@ static struct gso_test_case cases[] = { }, .gso_segs = (const unsigned int[]) { 0, 0, 0, 0 }, }, + { + /* frag_list members that don't end on gso_size boundaries + * can't be segmented with SG + */ + .id = GSO_TEST_FRAG_LIST_NON_UNIFORM_SG, + .name = "frag_list_non_uniform_sg", + .linear_len = GSO_TEST_SIZE, + .nr_frag_skbs = 4, + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, 1, GSO_TEST_SIZE, 2 }, + .err = -EINVAL, + }, + { + /* the second frag_list member hangs off the first one's + * frag_list instead of off the head's + */ + .id = GSO_TEST_FRAG_LIST_NESTED, + .name = "frag_list_nested", + .linear_len = GSO_TEST_SIZE, + .nr_frag_skbs = 2, + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE }, + .err = -EINVAL, + }, }; static void gso_test_case_to_desc(struct gso_test_case *t, char *desc) @@ -283,6 +310,15 @@ static void gso_test_func(struct kunit *test) if (tcase->id == GSO_TEST_GSO_BY_FRAGS) skb_shinfo(skb)->gso_size = GSO_BY_FRAGS; + + if (tcase->id == GSO_TEST_FRAG_LIST_NESTED) { + struct sk_buff *first = skb_shinfo(skb)->frag_list; + + skb_shinfo(first)->frag_list = first->next; + first->next = NULL; + first->len += tcase->frag_skbs[1]; + first->data_len += tcase->frag_skbs[1]; + } } features = NETIF_F_SG | NETIF_F_HW_CSUM; @@ -296,6 +332,18 @@ static void gso_test_func(struct kunit *test) features &= ~NETIF_F_SG; SKB_GSO_CB(skb)->max_segs = tcase->max_segs; + + if (tcase->err) { + /* the suppression block doesn't run if it can't be set up */ + segs = NULL; + kunit_warning_suppress(test) + segs = skb_segment(skb, features); + KUNIT_EXPECT_EQ(test, PTR_ERR_OR_ZERO(segs), tcase->err); + if (!IS_ERR_OR_NULL(segs)) + kfree_skb_list(segs); + goto free_gso_skb; + } + segs = skb_segment(skb, features); if (IS_ERR(segs)) { KUNIT_FAIL(test, "segs error %pe", segs); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454409.1668050 (Exim 4.92) (envelope-from ) id 1xInm9-0002FN-SZ; Mon, 19 Oct 2026 13:51:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454409.1668050; Mon, 19 Oct 2026 13:51: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 1xInm9-0002F1-Jo; Mon, 19 Oct 2026 13:51:41 +0000 Received: by outflank-mailman (input) for mailman id 1454409; Mon, 19 Oct 2026 13:51:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInm7-0001yV-Q5 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInm7-00EenQ-6O for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:39 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6205c-2eae-0a2a0a5409dd-0a2a45019992-38 for ; Mon, 19 Oct 2026 15:51:39 +0200 Received: from [209.85.160.176] (helo=mail-qt1-f176.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6206a-5984-0a2a45010019-d155a0b0ec31-3 for ; Mon, 19 Oct 2026 15:51:39 +0200 Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-5365d725440so11246871cf.0 for ; Mon, 19 Oct 2026 06:51:38 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.241]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5363455e7d2sm89038411cf.13.2026.10.19.06.51.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06: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=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=1792417898; x=1793022698; 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=l2su03NSLDI+QURR7+Op6WIlpfTiC3EObk5mJFR1rWs=; b=HsfCsgzQfm/3r3/QcfhDFyzF5yj30q3oaOZWVm+pGGSI2QygIV10tqs61KJrXqUfWv rgJmuXKpa9kfpdDFnYg9XO0lTx+p9AxaQvBLFUqlxll6q56EgTX5Gzu45c8evfUJEfOB hjnop1rNQ97I8cRH7jl7sUc4HkSUyg2eckwt8JrWEuOpempCsHne71YgDhb6Z4VZkwpF MgKXafAdo4vbpPt7eRt3MHZi1yuLXX6eEzkousg4gU5Xgqw/uUZGHXYHXr5B4Y0lq2L9 ZiF+b54VgFUAR5Hoqn87/hAMryWD/zAy5YDTkU1Ig4JLAPQbfiTnsCIDrvBuAIxT92cs 7CkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417898; x=1793022698; 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=l2su03NSLDI+QURR7+Op6WIlpfTiC3EObk5mJFR1rWs=; b=VjLPt6f6aqLb8lbI5SywT0mIcYX6+p5hF368Na/wdYKk9axiEhF64qxH4M6lloMPXp 67A7zq8TgKBDJ5mdZVrqE82YIKdVi2CxIsIVq6zBrgHMhpNNtrzFIQ6c3bgU7UjCFS8L ttQWPOAuJ2dD8eU2ULZxC5c2x5Sh4mi4DlnQ/+E2MspZ4oY15Ba12+h/LS6sf3LFEn3l nx9oDKUOYGApPUYys3LrTb7+QhnAn0UCJimqjifXFa7iUyyzV5YJDBFei7PcIpx7SVrF G/QwFtGvlt0iWvOq3G46DvBnsSdOhCA0+OAPAsoJMLDhQe4KIxUbIpXSg3qIn4VfOSAT x0DQ== X-Forwarded-Encrypted: i=1; AKwUvBx41moZ2nvS2Z5fWGbdAJMvjplnBNg0/vEhBVJzso0Uvu54HKI8HX7F23M1Mo9IjCcohplRX2ClheA=@lists.xenproject.org X-Gm-Message-State: AFq9FYLb1GAjlWuQRxcuTuEa/B6Ca3DqW2wQ8DbGpurm7UVrB1jdiwC5 DSaIT757/AjpFu2C+bZH4Kcvt5IIFZNxwHfQhzMyqHs0u26xvft09JL7epnpCrkjn+I= X-Gm-Gg: AYBFou20fuSuEU/pTxW7AeCQCVzTrt32NERR9mtuC6/SYaxEU9YAD/fOXUyubYJ2llE n1rb1UV46fvyaWrGiMAbnq4zJ1rf6a6YlLoTjTAP8YUaj/8DAP7lYfrw0o2sz3KGdXLVnvVZsud bAAOHpj+6QW/4v1M+wjLtuxRO0XuUAmW01zYMC0pKN01Ze7knI0CpYQgULfWQyYyirJhKfBY45O FqqqGGIQz14I++LXHenJA0l/gbbA3nLZgT1GhDCpv25uRDJs+dR/OE/yuPa1AS81LmMAmXyibMm WWxf7Cgo9r11hVJEgDqao/A2QHKslhZMOXV85Zn4s9+RdW4zaCxwYEFIAAf2hSmUv0E4aSS2Cum LFqAJKix9poBuclcZEXn/89iAgBfTrU8hBlGNyH7d0BwIZIiy/I+5hhR5UipPJb/ISMKW/led41 fjac9Mdm9vXl3FIUPTyWG+mIjsi/oVl8iQsxcRMOPwkVki1GChhFz1Ek5oMxRr4+flrqt0flxBu xBDfpiLLeDcNMI= X-Received: by 2002:a05:622a:1b87:b0:536:702c:f8ea with SMTP id d75a77b69052e-536702cfb33mr37062611cf.47.1792417897687; Mon, 19 Oct 2026 06:51:37 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:47 +0000 Subject: [PATCH net-next 13/15] xen-netfront: don't BUG() when skb_copy_bits() fails in bounce_skb() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-13-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=1219; i=josef@toxicpanda.com; h=from:subject:message-id; bh=9EvzAU9EO5dyvCGQMaA1nd2saqGuALWIDCXk9Xn6dMo=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QMKSzC4sHZmaSUvthhUD2jAMmS0Nr86UIBJrUbV6zvlVJH8olJ0s62bKQw5Ehhrzn/DanWtOPAh Q6nevl7Ie1gM= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1792417899-BF86F757-7C49BF39/0/0 X-purgate-type: clean X-purgate-size: 1221 bounce_skb() is an open-coded skb_copy() for skbs whose data isn't page-aligned, and it has the same BUG_ON(skb_copy_bits()). skb_copy_bits() only fails when the skb's lengths don't add up. bounce_skb() already frees the new skb and returns NULL when the allocation comes back misaligned, and xennet_start_xmit() drops the packet in that case. Take the same path, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/xen-netfront.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index fdcb91042f29..17811d81937c 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -695,7 +695,12 @@ static struct sk_buff *bounce_skb(const struct sk_buff *skb) /* Set the tail pointer and length */ skb_put(n, skb->len); - BUG_ON(skb_copy_bits(skb, -headerlen, n->head, headerlen + skb->len)); + if (unlikely(skb_copy_bits(skb, -headerlen, n->head, + headerlen + skb->len))) { + DEBUG_NET_WARN_ON_ONCE(1); + kfree_skb(n); + return NULL; + } skb_copy_header(n, skb); return n; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454411.1668057 (Exim 4.92) (envelope-from ) id 1xInmB-0002aj-Ar; Mon, 19 Oct 2026 13:51:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454411.1668057; Mon, 19 Oct 2026 13:51: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 1xInmB-0002ZC-47; Mon, 19 Oct 2026 13:51:43 +0000 Received: by outflank-mailman (input) for mailman id 1454411; Mon, 19 Oct 2026 13:51:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInm9-0002EX-Lv for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInm9-00BvR2-2G for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:41 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6205d-bab6-0a2a0a5309dd-0a2a4505991a-28 for ; Mon, 19 Oct 2026 15:51:41 +0200 Received: from [209.85.160.172] (helo=mail-qt1-f172.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6206c-4cb1-0a2a45050019-d155a0acc469-3 for ; Mon, 19 Oct 2026 15:51:40 +0200 Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-5365d26ccbdso19540811cf.0 for ; Mon, 19 Oct 2026 06:51:40 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.249]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5362a9dbdb5sm99695721cf.22.2026.10.19.06.51.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417899; x=1793022699; 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=hBRr7gTw0LaEROSfxIaRRGeZueq1UExVdpAZr5NxHXs=; b=fZmjtsX3CVipSeD4msL1iBZbwG7MDQ4DbWGwwvEqELFHiUzWw5NIDeTm71iELlESRl z6lv5bSUnF4Cg6ecz62SZ9XIlhJG58pVKg/qImxaRo18yzWwGCmNMNZXMDIO1vl+8py6 BxP0wfPE2tYpB7GmA9VulKJldlNhxsEZuOvpW82dWENkcC9dMQA2DlKNsfUbjeNTvnl+ 8DpYLga1vC/rjoDS/Q8/wdXvxkTXcJ1ex3jHTuDmtkI8s8t+lTJpUY+M7oqqPM90TZKr WHcqQRwKCg6/6eebXIqWzSRKwEDEr7qVgMmGtqH/iNRgzg6zS+J3oPcONTP2RdinbSlY W+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417899; x=1793022699; 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=hBRr7gTw0LaEROSfxIaRRGeZueq1UExVdpAZr5NxHXs=; b=Tmg6TigEA7Z17CdohTYBe/gtIH7JmOprPFVauBD1W/LgPDjMQWqsAp0p1mJCZ+nmxy GttdHFhkB/cnlFYpmIKZGcGbbb2DPTSsCmLxgGfuOQpa2N9EUJaECu7DkgWMW2wEmV54 dl0Qz7R5WngtETZzMQwikkvv56NmdAgt7/6HsDp9TwDZTLM8NTqMmNKB5jH3FtBCNXxt 2xuB5JjVm+cixCeL+iC8Jkfz73ckMlTYIZm6VKea02esqkHXKsRXuW2K3WeJWMV0QcKP pM3RJO5fFSlh8A9TCPr5hrwyDyn4RISdWb7YK+daaFQJsmUQ4Haj0ah5JmiHBTohzPQF A3wg== X-Forwarded-Encrypted: i=1; AKwUvByjDEUDSZ4Ddf1+/74MDTD7Cq1g3ykR2uK+Iv+LaBGnX0afVo94PBIJLO6zsfpZF8txbKBcXVD11d0=@lists.xenproject.org X-Gm-Message-State: AFq9FYLO68mPECVGHLWa+kAc8BK1UdyL7Lm5PUflo+zpT/Lfjwz5rLlm 12zxgUL6zS9cUYOUUBz8SfQVjiDi4cA4H6C9ZdDcn58Xvc4AYAseX1/eUEhei4zpx4E= X-Gm-Gg: AYBFou1rFcH71aJSHhu/Nu0I8dKtD3t46geBnN87S9ZwoSxccUZwu2ZPcgB2Uq3hnBI +XfEWODGY/vviP56XAfR7uKvpQRDzD2CVRbDaf+oEeaN/nP25uw0POLIEjCGkIN4M5O/fduq3jI e4Hi8KsFI4dYq2C1A2sYQnIgctg0SyeGPO3k5K+lVl54almEo+hTW4qkJZ8DOihRgl3CkM9bkdq MzGxgEGE88UuVw9gjj4OcCrwJpxVKAIJSUz5OuXvvC5B8XCZCSHhgxO6lbN1XHRE1jFECro/sNf NyBod1JBG/UB4QO2GPEsltlQ/qbR2ZmVQrssgGjV3P9ZmwhfLEH9uHhURDcvc4Ny6FHT2v4DlcE AYb49jv7W2OJ2sHZMw5jNVAMYbl339rAeCJMRK7YW/vcCbcsWJvVW3J/pcOcS6i0d3k6QjIMyAC 10wfF754Zxt0H9QULX31nW/OUY2GxYIgZRWHAYVCw8kEwmJU3lAkkfnoMiCRZn7Ft/p34xTHZfh GhDLPiwlruYl/8= X-Received: by 2002:ac8:5e0c:0:b0:530:1b1:72be with SMTP id d75a77b69052e-53646005c93mr115881901cf.40.1792417899549; Mon, 19 Oct 2026 06:51:39 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:48 +0000 Subject: [PATCH net-next 14/15] net/tls: don't BUG() on leftover length in __skb_nsg() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-14-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=1174; i=josef@toxicpanda.com; h=from:subject:message-id; bh=a5Mq1Y08mQBlSbHPsSgUKJSU0iN0kG1IRQ6Z8TBZzAw=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QAaOzcOEyDqIT7ixMNNFAojpV49DkAGaMSTgMMsV3T+Kry+T59Y4cK1hbqIN6aNryN+eDJKEsst k24iTK/yjrAM= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c201ff/1792417901-2551A2A1-95AE5B7F/0/0 X-purgate-type: clean X-purgate-size: 1176 __skb_nsg() counts the scatterlist entries for a range of an skb with a copy of the __skb_to_sgvec() walk, including its BUG_ON(len) when the skb runs out before the range does. tls_decrypt_sg() calls it on the same range it then passes to skb_to_sgvec(), so a bad range would BUG() here before it got to skb_to_sgvec()'s error return. __skb_nsg() already returns -EMSGSIZE for a frag_list nested too deep, and tls_decrypt_sg() fails the record on any return below 1. Return -EINVAL for the leftover length too, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/tls/tls_sw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 312e51270f29..1c578ea47a1b 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -142,7 +142,10 @@ static int __skb_nsg(struct sk_buff *skb, int offset, int len, start = end; } } - BUG_ON(len); + if (unlikely(len)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } return elt; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 13:51:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 13:51:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454418.1668067 (Exim 4.92) (envelope-from ) id 1xInmD-00033O-LL; Mon, 19 Oct 2026 13:51:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454418.1668067; Mon, 19 Oct 2026 13:51: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 1xInmD-00033F-Fx; Mon, 19 Oct 2026 13:51:45 +0000 Received: by outflank-mailman (input) for mailman id 1454418; Mon, 19 Oct 2026 13:51:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xInmC-0002l6-1Z for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 13:51:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xInmB-00EenQ-E5 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:51:43 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62062-2eae-0a2a0a5409dd-0a2a4504afc2-46 for ; Mon, 19 Oct 2026 15:51:43 +0200 Received: from [209.85.219.43] (helo=mail-qv1-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6206e-b57f-0a2a45040019-d155db2be519-3 for ; Mon, 19 Oct 2026 15:51:43 +0200 Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-91791ec1b83so18181286d6.1 for ; Mon, 19 Oct 2026 06:51:43 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91bcbb233d2sm98126806d6.32.2026.10.19.06.51.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 06:51: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=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=1792417902; x=1793022702; 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=Sz34K0Iw8+vtFq1WnWsYscgmIxwM3BOh5ri5FmDCCys=; b=a+xlEpAW2cmF5V4uu/O6jYKhOqXEf9N5lp4qPajrb1IBF4ow27Urvrv4AuR8ABDr+F +Pp9X/m6DGWFSqhRjTHOE+zCfZtayXYPMKtJOBE5cxR3h0BRdLkgDZczutT3T5blZDIp nvkPduUvPok0caxl8yAr2q2i98pSa5n2GFM+MgANPcCg/Hmkt8X+mLdt+n+a2sX+KZNY 9ofIvSpVC2fZeDXDyUClpqGnOCzjxu2C48grLuhXy/MBpvHJhyis6PPwvTb9wbFnjGKI a/7GfP2kfE3fyEmLheIEu+IsiwMVGlJh0LHbnh/wQcGwGP1E5Vy/pZZ3+DXdhttecZ9T iTzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792417902; x=1793022702; 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=Sz34K0Iw8+vtFq1WnWsYscgmIxwM3BOh5ri5FmDCCys=; b=GPiftnZyJwpNQdiP0j/5BusagI1vfJlLB500gXEooKSF/M44n7xF/+FxuxggQWl8tk wvdJG/NOfSjgBzy/vHa3F45nknDHAIudl+hTDivsy0i8I0zvuvlbkNmQNsuoW/flXs9D hqOxJ+/QgoV/VjRn69UZx6pOZKRw1E5s1l8sln4lTxRLBEf/0YAsN/zw0ZKYMgMt8Vsb WKHQdeNuVG2bqn/j7B+4YJLA7ERai6JECuNPwik+Db6L0Z67w7FbrKIl1RB1FNnRuPMD wB2vdhJQ3h6ukqqFWl8yU4cO5U6qdoi+ltlJq2eUkW7u8h1JpG6czlDW2V14TOtdU+5e r3pQ== X-Forwarded-Encrypted: i=1; AKwUvBw/LFE3B3r9db9k6km1HzrGCoZGayB+EotHzeMdGYWHFD8aoY0fdBR7DrfVkVMJi0aUzojwKCLpAiY=@lists.xenproject.org X-Gm-Message-State: AFq9FYJGEkiOSbSewNsvrQ74LK2MWaqUXAAdNVQgBnefun/KgWL5n1K3 XMtU8oLpWuin5+pM+6rrqe7dy7X2/CjXUk9TC6wmgesIVDzfwzfsVvRzZocbHd52mxk= X-Gm-Gg: AYBFou2kv6CPk22kKMKOETXyKCmsd4xLjJkBfxzjuWsv2Nli3ajH1H8JiiJQ8ZE0qX5 PJEUeAC7S5XkBj8BJYEUhG3gyU1Grs7pf9f47f1hoSUg29bSulzTME67i50zOzDx3/w5qZI2DAY oasK/AlIxlCZgcGqej4lQEGiEksLL6FMuPjeE0ZUOUSXRu0aP5cKnMYq62axJZE6Q3tSqhLdlk9 MRQb9WaCQfEUXKaS4ugbPmBfLrMt/cRoKIkhGX6nsZ+/GcM3GEzSSYhq8aaqikTsu16VROaXSvZ c8f0j+hftpHlK7fPJVm9SFGLi9Fn1ELO1sowx1SwNgt2N/gBH6/Zoo6/67TN9cDAPa14m92UYLS Kx0DONG57x0JMIQDBYRmLTFRftXE5PqiI5dcPoTFFrmjHC7MygS0127tvHFUmuYJR3EEnCUM+kj 80JZEIt7CIaYdXmWXDnsAdb7UDhKvV8CTTVVV8GD5Y1D4bW6W0Bj6j8QTaOTu0EmNa6ko4ICyMQ oeUeL3eHEe/jvY= X-Received: by 2002:a05:6214:29e2:b0:919:aba4:22e5 with SMTP id 6a1803df08f44-91bdf0aa97dmr130453586d6.18.1792417901621; Mon, 19 Oct 2026 06:51:41 -0700 (PDT) From: Josef Bacik Date: Mon, 19 Oct 2026 13:50:49 +0000 Subject: [PATCH net-next 15/15] net: update comments that still describe the skb BUG_ON()s MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261019-b4-skbuff-bug-on-followups-v1-15-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792417849; l=2874; i=josef@toxicpanda.com; h=from:subject:message-id; bh=bVkQYPRV5cmZpoQgzwHTIPv/OeC1BGK6SJq4klyY24s=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QGRgYXu9jiEH+o+P/X5XgMdqaIYdTCVgqXiXo+r1ZD/WK34+ps+wJnDs8hXR/0Hv/jB0pnLBW9g OlRZBGpF96AQ= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1792417903-50EDEB50-C2196414/0/0 X-purgate-type: clean X-purgate-size: 2876 The skbuff BUG_ON() conversions left a few comments behind: - bpf_skb_net_grow() says skb_segment() BUG()s on a frag_list with head_frag set at the downgraded MSS. It fails the segmentation and the packet is dropped, which is still why the skb gets linearized. - The GSO KUnit test says the non-uniform frag_list case would hit BUG_ON(i >= nfrags) with SG. That check now fails with -EINVAL. - The skb_to_sgvec() kernel-doc doesn't list the -EINVAL that __skb_to_sgvec() returns when @offset and @len run past the end of the skb. No functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/filter.c | 6 +++--- net/core/net_test.c | 4 ++-- net/core/skbuff.c | 5 +++-- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 3ee1a093337e..f5bce0dc43fe 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -3696,9 +3696,9 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32 off, u32 len_diff, shinfo->gso_segs = 0; /* Due to header growth, MSS needs to be downgraded. - * There is a BUG_ON() when segmenting the frag_list with - * head_frag true, so linearize the skb after downgrading - * the MSS. + * Segmenting a frag_list with head_frag true at the new MSS + * fails and the packet gets dropped, so linearize the skb + * after downgrading the MSS. */ if (!(flags & BPF_F_ADJ_ROOM_FIXED_GSO)) { skb_decrease_gso_size(shinfo, len_diff); diff --git a/net/core/net_test.c b/net/core/net_test.c index 12a175268a01..d38dfeed163b 100644 --- a/net/core/net_test.c +++ b/net/core/net_test.c @@ -325,8 +325,8 @@ static void gso_test_func(struct kunit *test) if (tcase->id == GSO_TEST_GSO_PARTIAL) features |= NETIF_F_GSO_PARTIAL; - /* TODO: this should also work with SG, - * rather than hit BUG_ON(i >= nfrags) + /* TODO: this should also work with SG, rather than fail the + * i >= nfrags check in skb_segment() */ if (tcase->id == GSO_TEST_FRAG_LIST_NON_UNIFORM) features &= ~NETIF_F_SG; diff --git a/net/core/skbuff.c b/net/core/skbuff.c index b6ada54ecc57..4822f96fc1c8 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -5554,8 +5554,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len, * * Fill the specified scatter-gather list with mappings/pointers into a * region of the buffer space attached to a socket buffer. Returns either - * the number of scatterlist items used, or -EMSGSIZE if the contents - * could not fit. + * the number of scatterlist items used, -EMSGSIZE if the contents + * could not fit, or -EINVAL if @offset and @len run past the end of + * the skb. */ int skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 14:25:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 14:25:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454479.1668076 (Exim 4.92) (envelope-from ) id 1xIoIw-00044N-5O; Mon, 19 Oct 2026 14:25:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454479.1668076; Mon, 19 Oct 2026 14:25: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 1xIoIw-00044G-24; Mon, 19 Oct 2026 14:25:34 +0000 Received: by outflank-mailman (input) for mailman id 1454479; Mon, 19 Oct 2026 14:25:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIoIv-00044A-Aq for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:25:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIoIu-00Efeo-9L for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:25:32 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62852-2eae-0a2a0a5409dd-0a2a450cd626-36 for ; Mon, 19 Oct 2026 16:25:32 +0200 Received: from [52.101.84.80] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6285b-f479-0a2a450c0019-346554506b53-3 for ; Mon, 19 Oct 2026 16:25:32 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by AS4PR03MB8626.eurprd03.prod.outlook.com (2603:10a6:20b:589::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 14:25:26 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 14:25: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=F/iKkcrANFmAGMP1Q8OdJ8egMam9x/SyHmh0rkR7TJ+CCmFaZvmr6I6ag2d8RNkhMnzkDmb/r5lFgGId7SMinjsL6ZPRW0iRNdkJhCTdQpE8VyXF36ocY7aDsebN0A8YW66pn+bmoouR6doKLrOf2qAxIF4+h8UkmePbtyz/VaqAFwurK9smqW375nIQhYqA24vAVClBvLwl/E4+Byt0ZcUreHJlvbC+euZaokXCp+MAJijz/heNmGiplL2EIMfzUFcQULQvhJXK0IUApyaM/fXrGhCDVjCKoO/XCXdwLIcP+UiWfUiY+opEIBV/bMcHUBKCzyKE+kxJHqre9cNOhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7UGNIoeTDw6IJbM4PFWZhyPIM+ZOv4SYdoDQnE3EWr4=; b=fnagya6yoQkBWWgsILnrryMkB9zcWexrfyjYjoNrCo3a5amWCGOoFgf5zH+CkSRCktaSIlIZzJ2Rx5UbJ+XcVoLmKh6jsQAD7lix/zmkGbFCt5nJQm4rXLyENqEG/yAjfchKgH4ETSF66tbprw/S3guknVmaVp8V/t5SMd0v9CQVSFQ6TP1ZC6M2dg9TSIUtkkOkjjmW17jXBHeKiLgxiurDmKpaG5DHLYNZlUen/F44uwCNsGV34KJz4VOCWK0T3q+o42vdRogv6ySGEz1H9LAvq/fRo/0x40E0XSpjVlgBOVYpLbjmvsWpZjlh7JDr/Lf3pRebrEQwkUiSOOydnQ== 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=7UGNIoeTDw6IJbM4PFWZhyPIM+ZOv4SYdoDQnE3EWr4=; b=omd/rmYUnPuZM+NEOqg6NEFsqRlKQ/LeleCjF3idE1/edjxOKtAjEqTmPZCj2b7JweQ7JubPbW1otyZeh2flD/RWmBY5R4DOrGV55Zm4K6iVRjblambmLpQc0esXqXhbmLNWWklrPXJuAtdMX2M5OoiUk+dGqElG1Ii63t5hY1iHI1D9Qw86SAKVFoZka3uQXxwC2suB2kVMcsMCChnHLDTaUw+jXZC+tY7vzJk4KDkHzO5g02dPvxBbnUwH1D85tocrGEzP8n4gq3LFQgIk5jGE1ZrDRg9mk5F+bSCI1uaJS27tT+QEIwgmKVJZy2BVE8Yg5PUe0DC9mIVhXHtRhw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <40b59aac-6bc3-4abd-aa51-7a6822ec8069@epam.com> Date: Mon, 19 Oct 2026 17:25:25 +0300 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/3] misra: add Rule 5.5 deviations for macro clashes To: Jan Beulich Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <79de1bea-7e1a-4d15-b7d2-8390ab5bdef2@suse.com> Content-Language: en-US From: Dmytro Prokopchuk In-Reply-To: <79de1bea-7e1a-4d15-b7d2-8390ab5bdef2@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AS4PR09CA0016.eurprd09.prod.outlook.com (2603:10a6:20b:5d4::8) To AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9SPR01MB0028:EE_|AS4PR03MB8626:EE_ X-MS-Office365-Filtering-Correlation-Id: 68f77cdc-fd45-4663-1e74-08df2decd1cf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|7416014|56012099006|4143699003|11063799006|18002099003|10067099003|22082099003; X-Microsoft-Antispam-Message-Info: bwVydrDwdKGzqDoJ8XmfbH7QdO7G0y9tYFddn2IlR7DGYV1O8bQD85GKdn8bpad4hE3df1Ci1b5TfIS0zsD4mSvryRnKjulGDty0CCteI90f9TH6D/enu7/lmhWEB3ctMNdHFavAzZqTHPCWBkBPvW5Te0QWqMrFIN09qI9/ih6Pe9V51U3XHWL6YTXeaHoCNLPsxyIMaU7AxXs+9Wn5Nkw9r154SeZF5YG1K8ieTg6c4Uk+ESdfxQzGmeyffhkFsKneXjWgq1LWvIU9E8L6dpmI1QTEXqHD+hJrtA8NWtvspe+DTTMvoe/WYeIzZ418P3B7nFOcI8kW17Rlmlf9hPuSYacthKzIycAZBRFXMt+fBhlt0pNr1O9q2e2M7q2k6ePKWLUM8X6z9Xzsi0Mqhx2sInRDNRS4cF28e/9qrzdL/tj8/3NsHztESgJSKhVaVoqFH0qwAycYci1U+kLhcKl/O5oUiuPuNEOKm2RTBgrsWTd3thhdxNnwiSol5cPrHyBPc9Jf7Xd/+VzC9lDmYNK6Ak29YdjWpYMHHOQkih/uTcedcGCzQ4yHJko/Cbgq1jWN5we+toFAgaNbiFb87yHXRo3vk0HuRiurX4hgcDDgpgX8OlFLjb8Vyh3f1u/R7AzysF5w3SNk9joyMUMqr+mXvO13pj1BCY27t8mluhw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(7416014)(56012099006)(4143699003)(11063799006)(18002099003)(10067099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Nkh4NUJGYTNjVVMwSitOQmc1TU1YME5oVGM1cG5DUmhoQWovbCs3OHpXSnVx?= =?utf-8?B?TDJ6T3RpTU5qa2JmaUc5c3prdkplakhhODBHWkxjOVM3L2xUdFhQUk9UdVZY?= =?utf-8?B?NEJkdVg3RGJsbzBSU3RGdmw0cER4U2pkazFGUFRMdlNHMk01VXZBK2I5Q0RF?= =?utf-8?B?aDlOYkpFdXJNUzZOWlNkbW9QTE9PZVNPeTlTaFhMWGthY2RqZGVBdmNmVVVu?= =?utf-8?B?QWN6MWRIbW9yVVVtd2lxQVFaZjlTSHhlTWNyU0hZbUxVMy9MaGdGUE1oSXI4?= =?utf-8?B?ZnNsUzlSNFhHZU5hQmE3OGtBMWRWTVpMejZUQXlaeXdmVWtmZWdUOFdBMW9H?= =?utf-8?B?OHpjbXRtS1BCYjVaMCtCMlBQYzFpeWJDRlRKMTloT1hYSmNjS2oyRFBWWVIx?= =?utf-8?B?Ukx1a3J5ajJCcFZiMzF6a0JxRU54RU5ZWU42UU9DU21YUnlCekNFeW9TWFVt?= =?utf-8?B?Y0puZ3Rsb3QzTmNPTjd3Tk1YTVFodE9DMWtoY0xhcjluN3VONnBOS0d5K2k3?= =?utf-8?B?NGw1Zzk0V05lQStJQzJrK3NjdlpqWFRpMXRTM0JQYXB1Y1VHSGVTY2VMdHkx?= =?utf-8?B?QWUwTGEvb3NrUSt0U2RtTGx0aC9KKzJDRDNwZ0RueUNGOWt4Zk5Uem1WTDhR?= =?utf-8?B?Tk5Cbm1xakMwWndLWnBpUXFPTHpDdm8wSkgrNmUvelpidTlTak1hQThzS3hV?= =?utf-8?B?ZUkrRk5mNmNPbkx6VHRXeGdyN085Smoxb0liclBIVmlmelVwZW5meGRjSkdR?= =?utf-8?B?VnlEVzYraU5WR1pnNERvUUhQa0lPRmJxUkxQZzN6bmQ2TFNPbHFVb2pScHM2?= =?utf-8?B?YTI4VklJblpiR3d3ZkRaOFdieHdPamo5aVNqS0hZZDJTNVpuczNlQ1pDZC9P?= =?utf-8?B?eFIzSzhBUFdKdmdqQ1lhYzdiRndCcGJjZHJQT1hVUDNpeWZWTnRKeEsxZTdV?= =?utf-8?B?YVpSK01ia0Q3c1hTQi8xZWVuSjAxVlZ3YTRjMjFsR1FtN3dYMThVNEs0VlVz?= =?utf-8?B?WjBDdnVpRzlsZmRpTTJNRHFkQmtiZ1VIeXhYOXUwVkV2Lzl4UEQ1UVhENk1k?= =?utf-8?B?NEp6eHJmZ2V4QkI5Ni9pSExZMXdyajlNSU9HVkx3eEZUUityRVg2UFhOOCt3?= =?utf-8?B?MHE3QmVFdE9KaFBiS2JuVTJ6Q0xseWc0MDRKVHZVbE5BcHc4ejAyWE85ajVp?= =?utf-8?B?TDZlVjg1eEU2TXhOdXBQcDVwS0xQN1A5MmpId0Z5eGliaDM3SkxIZklJRGJK?= =?utf-8?B?NkVJd3hFYW15VGE1eXdXaVpJZlBpdlhIb25kSXEyRnBYTDJNamVKbk14L3lk?= =?utf-8?B?Qk1YbnBCV1FrSmJIbGI4dUZ0eFJwOU5oOVF4cXNJS24yTWVyd0lkMUVCeXZD?= =?utf-8?B?M1gyZFhhODNka29sRjNOZlpKSVVaWVhLUmd4cGFtbVJsWjg4d0VLckFXYnFT?= =?utf-8?B?d29FOWNXTC9VSnB4alN3NzJwcmllOVhBN3Y4NDNSUGxVUDMyMG92WVlkTURm?= =?utf-8?B?R29HeEdLWEtuQXE4QkRaZTcxOGtGSHRlbEF1N3B2OFNnVGdiYndvZU85a0lT?= =?utf-8?B?YWViSE9ydWw2TXBaYkx2SFhOczYwcjZTNUZiV3FBUDl6TG40SVhHOXVEbk8r?= =?utf-8?B?cDZKR2c2dGlLV0NRMGt3SWhBQXY3SzJQWFVGdFNJbzFYRjlndGdFUGh1N1lC?= =?utf-8?B?MDFBc0tzeHlLVHpBbUVrNHlQOWpRc0VhL3F1bG5ibjFZS0lBUXpjYU1KYjlG?= =?utf-8?B?ZHAvNkg1ZThsQitMTzlxaDc0ZUVGVDIzTHlaVG9PNE1tenVwR05UaGcrY0U5?= =?utf-8?B?NjNGN1hFTmF0Tm13U2ZRMzNrd0J5UTBBbUZ0dTNKZEVZRWdIYzZyM3MzMXI5?= =?utf-8?B?eE5TY2J1aU10SlZhOUdhS3lBRC9abytjbTNUY1dtYWI4RHFjQmw3VjJJTFQ0?= =?utf-8?B?VjZmR3B3Ykh0TU04a3VoSlVHUlFQdHNoUE8wQWJaSkQrNXBJR0NlV3ZZeU1J?= =?utf-8?B?bFF3cWUvOWlHaWtqdHl0RnV3eTQyR0JxczNVeHZkLytoUVVEeTQxYVRKcE9G?= =?utf-8?B?Wm1zQVcyTGNyZkJyS21KVlFPa3RRd1lEU0xBc1NtVjNicmVxRFJmOG1JSExL?= =?utf-8?B?Q1Q5MktlMjlFSHJza3J1amtLTDc4QUdISjlab2N2T1BjNjJ4dzQ5SktNUTFD?= =?utf-8?B?aTcxV1N6YjQraVM1TWxNa2ZXNWkyWWpwSllJZW5jb2c5dkhOZERxOFpKNmlT?= =?utf-8?B?bzNEdVN1SWo4MVQwVjYxOTc0MU9tK0Rnc2pISnBRcm9BYktzWHFWUUNyY1lR?= =?utf-8?B?cTZKQUZmSitsZlZTYTFuaVpDZFlGL0hwUk9qY0VzTjJEMDNhaFFrdlAwZnNj?= =?utf-8?Q?YAcNBqS/4JApTuaU=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68f77cdc-fd45-4663-1e74-08df2decd1cf X-MS-Exchange-CrossTenant-AuthSource: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 14:25:26.6757 (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: UYKzU3OpNM4iOryFWmfDuWwArbZGz4Qn5GRCuAZPks2LJn1SIwKZMNzGN6HaFmOaC/g9gf6H2ePj4inY7XtTtXOg+p7rYIn5zfsIRNy40n8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8626 X-purgate-ID: tlsNG-d25034/1792419932-51339A5B-7AB067B5/0/0 X-purgate-type: clean X-purgate-size: 963 Hi Jan, On 9/29/26 09:52, Jan Beulich wrote: > On 29.09.2026 08:21, Dmytro Prokopchuk1 wrote: >> This series adds deviations for function/macro name clashes where >> the macro is used as a wrapper around an existing function name. >> >> With these three patches all ARM Rules 5.5 became clean. >> >> Changes in v3: >> - update wording with specifying file (constrains) >> - add Jan's ack for the first patch in the list > > I.e. you took my reply to Bastian's comment as sufficient to address his > concern? > > Jan Not entirely. I took your explanation as the rationale, but v3 doesn't record it in the deviation text. The patch is already committed, so v3 didn't record the rationale you gave for sharing the name. I can send a follow-up patch that adds it to the deviation text and rules.rst: the macro deliberately shares the function's name so that accidental use of the size-based function is less likely. BR, Dmytro. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 14:27:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 14:27:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454486.1668086 (Exim 4.92) (envelope-from ) id 1xIoKq-0004Wd-If; Mon, 19 Oct 2026 14:27:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454486.1668086; Mon, 19 Oct 2026 14:27: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 1xIoKq-0004WS-Dn; Mon, 19 Oct 2026 14:27:32 +0000 Received: by outflank-mailman (input) for mailman id 1454486; Mon, 19 Oct 2026 14:27:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIoKp-0004WJ-KX for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:27:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIoKp-001pmv-1H for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:27:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad628cb-e002-0a2a0a5209dd-0a2a4503e018-12 for ; Mon, 19 Oct 2026 16:27:31 +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 6ad628d2-fae8-0a2a45030019-b9ff1c2292e7-3 for ; Mon, 19 Oct 2026 16:27: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 1a1548f6f6b0008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 19 Oct 2026 14:27:28 +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 DD8A2829FA; Mon, 19 Oct 2026 16:27: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=CSqTWT9O4AN5Pn94F26K+Izpn2bO0zKDtNnTH+vptz0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=ItzkLVUTHf/cNN3if+V5qOeQ/wbQB2OtdE3/Aejmu3K8vYXSqI+QeMifk3QEjXXT0iRCv8I8G UkZhjBUcjBWV0tDzQ6/LO5DkKVMf213h0t3JNddT1QxcjFUmlbiirL+f4owM2gqdvVBiu8Y2EjY y0MB3dP38PYYNaGQJ2OP8oUNA9meTQh/k4PqDj1mJiLStovmtCZgaXniMY7TTp5fp8x75iLijvP OV3169+cIAWVca3IsPTTQHwK/aXwjDuk8djfOLo412FAw5dPzq3T3UTamU7Vg1EvkQwcw8uetuN e97NSpNJZZIHiLt50FMq7PsQs94WsI49Drv0BBB1qMgA== X-Zone-Loop: 7684ba8958ab24e90c989a3cc69616dca2d23fd3787f x-campaign-type: default x-transaction-id: f4ba99b6-ee6b-4a01-8649-ee60ebc11ab7 x-swg-uid: 01-f3ac00ad-cc2f-48d7-9af6-246821cf4ede X-Mailer: Sweego Message-ID: <1792420048.8631fc262581453bbf619ec5b2062170.1a1548f6f6b0008425@vates.tech> x-swg-bid: 1792420048.8631fc262581453bbf619ec5b2062170.1a1548f6f6b0008425 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] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write Date: Mon, 19 Oct 2026 16:26:36 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35f.bcdda06206fca13e.1a1548f6ca8.e995f4750d9dae5=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792420048040 X-purgate-ID: tlsNG-33051d/1792420050-764FC4E9-3E0B8FDA/0/0 X-purgate-type: clean X-purgate-size: 2887 ---=Part.35f.bcdda06206fca13e.1a1548f6ca8.e995f4750d9dae5=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The Intel SDM (Vol 3A-13=2E12=2E11, June 2026) says > The semantics of sending a self-IPI via the SELF IPI register > are identical to sending a self targeted edge triggered fixed > interrupt with the specified vector=2E However, this is not expected to alter the ICR register=2E Fix the Xen behavior by sending the Self-IPI directly instead of emulating it by modifying ICR register=2E Fixes: 21c4d089ba2a ("x86 hvm: x2APIC emulation") Assisted-by: Claude Fable 5=2E1 Signed-off-by: Teddy Astie --- Linux/KVM has a similar patch : KVM: x86: Do not change ICR on write to APIC_SELF_IPI https://github=2Ecom/torvalds/linux/commit/d22a81b304a27fca6124174a8e842e8= 26c193466 xen/arch/x86/hvm/vlapic=2Ec | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/vlapic=2Ec b/xen/arch/x86/hvm/vlapic=2Ec index 885f5d304b=2E=2Ebb105225e2 100644 --- a/xen/arch/x86/hvm/vlapic=2Ec +++ b/xen/arch/x86/hvm/vlapic=2Ec @@ -963,6 +963,17 @@ static int cf_check vlapic_mmio_write( return X86EMUL_OKAY; } =20 +/* + * A write to the SELF IPI register sends a fixed, edge triggered IPI wit= h + * the given vector to the local APIC itself=2E Unlike an ICR write it d= oesn't + * update the ICR, which is guest visible, in x2APIC mode even without an= y + * intervention by Xen when APIC-register virtualization is in use=2E + */ +static void vlapic_self_ipi(struct vlapic *vlapic, uint32_t val) +{ + vlapic_ipi(vlapic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK), 0); +} + int vlapic_apicv_write(struct vcpu *v, unsigned int offset) { struct vlapic *vlapic =3D vcpu_vlapic(v); @@ -973,8 +984,9 @@ int vlapic_apicv_write(struct vcpu *v, unsigned int of= fset) if ( offset !=3D APIC_SELF_IPI ) return X86EMUL_UNHANDLEABLE; =20 - offset =3D APIC_ICR; - val =3D APIC_DEST_SELF | (val & APIC_VECTOR_MASK); + vlapic_self_ipi(vlapic, val); + + return X86EMUL_OKAY; } =20 vlapic_reg_write(v, offset, val); @@ -1050,9 +1062,8 @@ int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr,= uint64_t val) case APIC_SELF_IPI: if ( val & ~APIC_VECTOR_MASK ) return X86EMUL_EXCEPTION; - offset =3D APIC_ICR; - val =3D APIC_DEST_SELF | (val & APIC_VECTOR_MASK); - break; + vlapic_self_ipi(vlapic, val); + return X86EMUL_OKAY; =20 case APIC_EOI: case APIC_ESR: --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.35f.bcdda06206fca13e.1a1548f6ca8.e995f4750d9dae5=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 19 14:58:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 14:58:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454504.1668094 (Exim 4.92) (envelope-from ) id 1xIoo9-0002Mi-Sn; Mon, 19 Oct 2026 14:57:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454504.1668094; Mon, 19 Oct 2026 14: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 1xIoo9-0002Mb-PN; Mon, 19 Oct 2026 14:57:49 +0000 Received: by outflank-mailman (input) for mailman id 1454504; Mon, 19 Oct 2026 14:57:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIoo8-0002MV-9B for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 14:57:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIoo6-00ErjS-79 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:57:46 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad62fdf-8faa-0a2a0a5109dd-0a2a4502a4fe-18 for ; Mon, 19 Oct 2026 16:57:45 +0200 Received: from [40.93.194.41] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad62fe6-6ca4-0a2a45020019-285dc2291eab-4 for ; Mon, 19 Oct 2026 16:57:43 +0200 Received: from MW4PR04CA0056.namprd04.prod.outlook.com (2603:10b6:303:6a::31) by PH8PR12MB7134.namprd12.prod.outlook.com (2603:10b6:510:22d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 14:57:36 +0000 Received: from MWH0EPF000C618B.namprd02.prod.outlook.com (2603:10b6:303:6a:cafe::4c) by MW4PR04CA0056.outlook.office365.com (2603:10b6:303:6a::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.19 via Frontend Transport; Mon, 19 Oct 2026 14:57:35 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MWH0EPF000C618B.mail.protection.outlook.com (10.167.249.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 19 Oct 2026 14:57:35 +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.53; Mon, 19 Oct 2026 09:57:27 -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.53; Mon, 19 Oct 2026 09:57:27 -0500 Received: from APPOL-18KY0J4.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 19 Oct 2026 09:57: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=TKxNjuqVIGcSbXLwXGAWx85fVxjCpdwe3JS8nmSu5uJv3FPdikWBlbit77cIccNxb1B2DzQqz/ILyY1eUsERqHGjrR1RTv3HjdXit/CrSFBw4Pr6QoB9FLJfKQavPtYspRTBCGuOJOAQado4LfrehvhE0oX7dxbVafCcYm/i85YsaGyXczlydA/dcd+GFCzQPMPNwQBAuMlHg4ih8k5uigYOCgmN3gdIED9nFOC4beBRUcR5CnOOnt7O03tQ9JIJDrOZ8iNDDZ43rbpSokVKAdNgwk2O1eVLUCqDGnbvI/ict7y3LsMBzWDb+sOK06B/HWOIYgoei/vELS3dMihpFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jYk5IBixoan2IiArJFwaqEC/IXumFkwYCSAmsE+DvQA=; b=k/zn3WUItmTlAx3CA4KredvNYtPEeihivdI34MRVHhHV7SnCQZw4rtYzQZIHs4bjbcI5ZudZnKkg/mVvwb8HcZGgEFxC8Qur9vytaorGqQYQwJ3b1gvMcNQz4mICGB/rDSEs9zaiOKBxc9LBngBa2/5TUPmMOVtFh4NwBD7g8MEFFMzuJsf2OkQ5+K3/EJ6RjDX9DwjSGu3/QXS4hc37l2gvjaCXYk+b9cYwmKGmvV2W7HxE7wmIrk0c6iHXBHT3MXNtE3Whh6Rz/C4064oNbS0B27myIkxRRIl8YYMJoHFSZbvtXgRI8kFTx1j/gQgtvPW8d0kY/9SQg9fjz4QaxA== 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=jYk5IBixoan2IiArJFwaqEC/IXumFkwYCSAmsE+DvQA=; b=ed9pjOniB+7fm19PL0bAJ1wnn8D3uZm2UlTHo7yaEwaisy0o20bRp8DPLeG19VA7N6VEVL4p0Km6bfKzA+RD3PorBNfmveEQ4QTBv8hsrbYtDtGR3cLGOIYI6AbqY7Rk6toRM5XIEUJoZydLKj0y9QWExNyZpCqnnJ3TBc+tgdw= 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 From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH] xen/arm: validate max grant frames against the grant table region Date: Mon, 19 Oct 2026 16:57:25 +0200 Message-ID: <20261019145726.648111-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: MWH0EPF000C618B:EE_|PH8PR12MB7134:EE_ X-MS-Office365-Filtering-Correlation-Id: b015dae9-fd9b-4eb6-df26-08df2df14fad X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|82310400026|36860700016|1800799024|376014|6133799003|18002099003|10067099003|261009223027099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: JQgde4g+ZE874YVldNXQXo8pYUcGSCFrF7W6VwHMBkc9fZftslabVtZgmWErFuKnYGWA8fLj8BplHj8xnrEnG7WNiNnDGAFPwAp67OFDtsgQRSpef7JDAToX4QTstApRtRDZ6rnTg9YO1ISuce4c4/vDMzUA9g7t/lyQls1orjRe0BGKKF27g9ZU6lOuTtHwm8EzLTBrUd43Mgg8urm9+snngQ40/T4bsqYf1KA8HjZ35ACVBhU3mmufnW4moYgTANhT4BUNKx2hVZuqe0Jfi0hCzlBueSetp/aPEeD/HPvRO/tAzv1XfiQ5F2cjKuydBibGY22V5CeHTJCUT4HUaJYkKu9D8MUgJXPGyaB4Xi58DrZ2V535m8A4OV5D6wckdoqWq84gwC4k+1+TTYYZho7BXFD7csnYNHmzOZNkMkZS3b/vRT5Al87HVMx3lRru40+VI3O+nwZ8vc3Tyq+8oocgqRmlY3HheH24AumJJ69pYuEoQrAwh28EFvt/Ph1o7pzMS2Ps9hOK15EI+jb9IlcwqZv1FyLrgt3hqwe7xVm5UtdvsXWnmFcFQ+OQEWycVEn+kX97eOQfQ5ZWwAyod2htPJASkoCLT1Od/aGT3YyNFmdARnS7mO5DUiItTYR65FU7mWgjyuH53L1C42qzp7RY7Idge12GEd5NXWaYAcCaeFB/so5S/MjYR1cYBjyeZIZkYfRnFlJgO+VRLX8+cw== 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)(82310400026)(36860700016)(1800799024)(376014)(6133799003)(18002099003)(10067099003)(261009223027099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 5lj65Os1eYQqBPE0+77fklGlTW6vdo+ilQnrDZouiLA36ihRCE2LfAkB+5jTZiltG7ljGhhDL+7N5D+o4K1O2LQpPrDGEA/Or9mp7piXcK4KoZASFHswoPFsOJN7/NrATVNbRWoQmIiGRWbYmMVSDcwZxSHv5SvfVaQmQYjD1BIAohGkBx8qvdc+5Ms19Qpomh79LzC00UojTcBkNTEFBCETVzLrJvKY83Gu7egAhgq9Vt923hHomrh7nqmH5/PAzkEPutPpRCsYT8kWa0sReAF3/TzvRLcmqnaqhjCb2cMl8fxqOv/jVpv8xTzhujtiVgDMcYFt3K46MqVVOvpBLYVlimHoxWpMooDgArLUAUtCHQ35/sKyOAVFlxwDeWvg22KO8cU2aycE2Cgvvu4LDeqMwfRZyr7YlsuErbquy7wCJdxAUBLqzXd23KYV93fV X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 14:57:35.5707 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b015dae9-fd9b-4eb6-df26-08df2df14fad 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: MWH0EPF000C618B.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7134 X-purgate-ID: tlsNG-720697/1792421865-F3ABD2AC-2D36038A/0/0 X-purgate-type: clean X-purgate-size: 4439 Per the binding (docs/misc/arm/device-tree/guest.txt), region 0 for mapping grant table is large enough to map the whole grant table. Xen never checks that this holds: - enhanced dom0less domUs are given GUEST_GNTTAB_SIZE (4096 frames), while their limit comes from the max_grant_frames DT property or, if absent, from the gnttab_max_frames command line option or default, neither of which is bounded by the region size, - a dom0less hardware domain is given gnttab_dom0_frames() frames, while the max_grant_frames DT property can raise its limit above that. A guest growing its grant table past the end of the region ends up mapping grant frames over whatever follows it in its address space, e.g. the magic pages at GUEST_MAGIC_BASE for a domU. Validate that the configured max frames can actually fit in the region Xen exposes in make_hypervisor_node(). Fix find_gnttab_region() logic of setting the gnttab_size for hardware domain to allow the max frames up until the size of the text section. Otherwise, the DT setting would only allow to shrink it from the default. Fixes: 79eb2871f25e ("xen/arm: configure dom0less domain for enabling xenstore after boot") Fixes: df68a4cb7ed9 ("xen/arm: Add capabilities to dom0less") Signed-off-by: Michal Orzel --- docs/misc/arm/device-tree/booting.txt | 5 ++++- xen/arch/arm/domain_build.c | 16 +++++++++++++++- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index 3787d2e2b668..1dfdff0e4fe3 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -291,7 +291,10 @@ with the following properties: Optional. A 32-bit integer specifying the maximum number of grant frames the domain is allowed to have. If this property is missing, the value specified by Xen command line parameter gnttab_max_frames (or its default - value if unspecified, i.e. 64) is used. + value if unspecified, i.e. 64) is used. For hardware domain and xen,enhanced + domains (for which Xen advertises /hypervisor node) the limit is based on + the max region size (GUEST_GNTTAB_SIZE for domUs, size of Xen's text section + for hardware domain). A larger value makes the domain fail to build. - max_maptrack_frames diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 72f6f7539a7f..1ee1f1f6a733 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1031,6 +1031,8 @@ int __init make_hypervisor_node(struct domain *d, void *fdt = kinfo->fdt; struct membanks *ext_regions = NULL; unsigned int i, nr_ext_regions; + unsigned int gnttab_frames = + gnttab_resource_max_frames(d, XENMEM_resource_grant_table_id_shared); dt_dprintk("Create hypervisor node\n"); @@ -1042,6 +1044,14 @@ int __init make_hypervisor_node(struct domain *d, (sizecells != 1 && sizecells != 2)) panic("Cannot cope with this size\n"); + if ( gnttab_frames > PFN_DOWN(kinfo->gnttab_size) ) + { + printk(XENLOG_ERR + "%pd: grant frames limit (%u) exceeds the region size (%lu frames)\n", + d, gnttab_frames, (unsigned long)PFN_DOWN(kinfo->gnttab_size)); + return -EINVAL; + } + /* See linux Documentation/devicetree/bindings/arm/xen.txt */ res = fdt_begin_node(fdt, "hypervisor"); if ( res ) @@ -1750,6 +1760,9 @@ void __init evtchn_allocate(struct domain *d) static void __init find_gnttab_region(struct domain *d, struct kernel_info *kinfo) { + unsigned int gnttab_frames = + gnttab_resource_max_frames(d, XENMEM_resource_grant_table_id_shared); + /* * The region used by Xen on the memory will never be mapped in DOM0 * memory layout. Therefore it can be used for the grant table. @@ -1758,7 +1771,8 @@ static void __init find_gnttab_region(struct domain *d, * enough space for a large grant table */ kinfo->gnttab_start = __pa(_stext); - kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT; + kinfo->gnttab_size = min_t(unsigned int, gnttab_frames, + PFN_DOWN(_etext - _stext)) << PAGE_SHIFT; #ifdef CONFIG_ARM_32 /* -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:00:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:00:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454547.1668103 (Exim 4.92) (envelope-from ) id 1xIpmQ-0004zU-DI; Mon, 19 Oct 2026 16:00:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454547.1668103; Mon, 19 Oct 2026 16: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 1xIpmQ-0004z1-AU; Mon, 19 Oct 2026 16:00:06 +0000 Received: by outflank-mailman (input) for mailman id 1454547; Mon, 19 Oct 2026 16:00:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xIpmO-0004YH-C4 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:00:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIpmN-0024ZI-Dd for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 18:00:03 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad63e68-8faa-0a2a0a5109dd-0a2a450190a6-44 for ; Mon, 19 Oct 2026 18:00:03 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad63e83-5984-0a2a45010019-d155802fece8-3 for ; Mon, 19 Oct 2026 18:00:03 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a1cef0439aso25018485e9.0 for ; Mon, 19 Oct 2026 09:00: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-48dfd4e28bcsm24218617f8f.23.2026.10.19.09.00.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 09:00: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=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=1792425603; x=1793030403; 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=rXku0uSS7cetVaB1RhHYmZ4LzWZiZ0jJSJfMyr9JCAQ=; b=o0exFcdZDl889rR3yyiY+YHUvmt9oIgWbp3PRkXS5jmKwZ2xepLX3fpLgq5UpZ+ANv 4JywiOu0A5DGZcH9WzGsyUddrBpbU63bKvF8T277rziBNhYESAJgxqe3pU42CzC0qkmE mkxSMaTbLuxuOQsYVZo2QXhip3eZM7W/rv5aA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792425603; x=1793030403; 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=rXku0uSS7cetVaB1RhHYmZ4LzWZiZ0jJSJfMyr9JCAQ=; b=xYrBUTa3LjQYYbG82kMtm4u9B9oYfq4F9M2kXunuvst3WkVAwBOYfBNP60QdFkB/3X 8J7/qBJ7a5GI3kmafhCe9JGPLtcDdxzIzdCkx0AAMpz6AwSfMCOtdN5BIiOgDywELev0 wXVgt96mKYgMAnV6q6cRkA5OdPHxY1PfJvh42W9hpliemYTCsFJIjiwMVKEkb5iVXnnu hPqHe7LHkpX4YrsSfCQdOf9qZLyi1XiHOEZVm2YbbD/PH9lus/VGi/uJ9ZWgOVX/gz9q FSX0fKI5JxlSOxhTeOT2an8j5lBKf9AwBvC0MI4JwYmqJP4MVkEcf2Yq69gB1vZ6DlNL UgNw== X-Gm-Message-State: AFq9FYJ1CwQtByMV5CFHam/fJshO+l4pK165wjEMd4YCXmZ4C3Xv/xm1 UuoshjijEXXjUQHb+lx5/UmLcw5Zc4/MfWjUvlHx1J8GIS/EbSbSbE0a8Do21rAYyzLaC7VFqlI u3qsb X-Gm-Gg: AYBFou2JvlLpM+Ervhj8OXuyMxlfJxs2b/5Ux1ADDenXZr2XxusBofqQUyiWLpVQ9ZM J5bSTsCwpS5TQlMV/+95VqyTWA9rqMUswC7WmQQe7xv00bCVmLh/ICwI0oTFFm4e5n5TnP4z+S4 +TO4naptRkS5L05nSn5Rv/8aSi5r7X96lzGQ7Z/hJGo6uKIfE351Hv/QdYELXpU8tbzYOxt7cJs Sy0OJWcYLlJRwiBCeCa9jEyATUdvYZZcfhfBE6Meq5lbtUNLeUx015Z07jFMR4Cs9YkYaJA2iTt jpTOaIwENodAZ6ca14VCit8nVLuZGZUlj34HOdrtpK/IeX/SJNHVrxsvSsv2f+D/7zgU/dl8h5A U9RpfXVNuuUUOSg7c4w36ziaxgdVNzK1LYVwYZSlij2QCwThfwCS5ngY4LKN/5d4p5vu53hssOC qPHFrGwgx5HFh1qxV6X4UnPi1OIGmNoiofB5wuOhbftLABbmhg2GsdopF6TiXGO1xsh1XBmN/Cb hvaVWxPmFF+5hnNNZss4q5jN79BSeiGU5IYis6qrn224bzJ X-Received: by 2002:a05:600c:3b13:b0:4a0:2150:55fb with SMTP id 5b1f17b1804b1-4a1d75ad08amr206887475e9.4.1792425602167; Mon, 19 Oct 2026 09:00:02 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Teddy Astie Subject: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks Date: Mon, 19 Oct 2026 16:59:59 +0100 Message-Id: <20261019155959.883789-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/1792425603-1FC69757-A7A6712D/10/78276251493 X-purgate-type: spam X-purgate-size: 3785 Between writing MSR_S_CET.SHSTK_EN and establishing SSP using RSTORSSP or SETSSBSY, there must not be any CALL or RET instructions. Building Xen with -fno-early-inlining causes wrmsr() to become out-of-line, and thus suffers #DF during boot. Make the MSR and shstk helpers always_inline. They ought to have been this way all along. Reported-by: Roger Pau Monné Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie No change in the compiled binary at -O2, except for the line numbers embedded into *_param() names. With -fno-early-inlining, the resulting delta is: add/remove: 8/9 grow/shrink: 13/50 up/down: 360/-736 (-376) --- xen/arch/x86/include/asm/msr.h | 8 ++++---- xen/arch/x86/include/asm/shstk.h | 4 ++-- xen/arch/x86/setup.c | 5 +++++ 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h index 1377d156f4e1..d5cec5509faa 100644 --- a/xen/arch/x86/include/asm/msr.h +++ b/xen/arch/x86/include/asm/msr.h @@ -47,7 +47,7 @@ static always_inline uint64_t rdmsr(unsigned int msr) val = a__ | ((u64)b__<<32); \ } while(0) -static inline void wrmsr(unsigned int msr, uint64_t val) +static always_inline void wrmsr(unsigned int msr, uint64_t val) { uint32_t lo = val, hi = val >> 32; @@ -56,7 +56,7 @@ static inline void wrmsr(unsigned int msr, uint64_t val) #define wrmsrl(msr, val) wrmsr(msr, val) /* Non-serialising WRMSR, when available. Falls back to a serialising WRMSR. */ -static inline void wrmsrns(uint32_t msr, uint64_t val) +static always_inline void wrmsrns(uint32_t msr, uint64_t val) { uint32_t lo = val, hi = val >> 32; @@ -72,7 +72,7 @@ static inline void wrmsrns(uint32_t msr, uint64_t val) } /* rdmsr with exception handling */ -static inline int rdmsr_safe(unsigned int msr, uint64_t *val) +static always_inline int rdmsr_safe(unsigned int msr, uint64_t *val) { uint64_t lo, hi; @@ -113,7 +113,7 @@ static inline int rdmsr_safe(unsigned int msr, uint64_t *val) } /* wrmsr with exception handling */ -static inline int wrmsr_safe(unsigned int msr, uint64_t val) +static always_inline int wrmsr_safe(unsigned int msr, uint64_t val) { uint32_t lo = val, hi = val >> 32; diff --git a/xen/arch/x86/include/asm/shstk.h b/xen/arch/x86/include/asm/shstk.h index 9160fe9f0e99..22bbbb2faf37 100644 --- a/xen/arch/x86/include/asm/shstk.h +++ b/xen/arch/x86/include/asm/shstk.h @@ -15,7 +15,7 @@ */ #define SSP_NO_SHSTK 1 -static inline unsigned long rdssp(void) +static always_inline unsigned long rdssp(void) { unsigned long ssp; @@ -24,7 +24,7 @@ static inline unsigned long rdssp(void) return ssp; } -static inline void wrss(unsigned long val, unsigned long *ptr) +static always_inline void wrss(unsigned long val, unsigned long *ptr) { asm ( "wrssq %[val], %[ptr]" : [ptr] "=m" (*ptr) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index fef3c2dd4423..446cd8127693 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -915,6 +915,11 @@ static void __init noreturn reinit_bsp_stack(void) */ local_irq_disable(); + /* + * There must be no CALL or RET instructions between writing + * MSR_S_CET.SHSTK_EN and establishing SSP with RSTORSSP or SETSSBSY + * below. All helpers must be forced inline. + */ wrmsrl(MSR_S_CET, xen_msr_s_cet_value()); /* base-commit: 7e020a4dd6ed30eb6c91a9abe2767034e2bb270a -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:04:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:04:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454556.1668112 (Exim 4.92) (envelope-from ) id 1xIpqc-00060e-Td; Mon, 19 Oct 2026 16:04:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454556.1668112; Mon, 19 Oct 2026 16:04: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 1xIpqc-00060X-Qw; Mon, 19 Oct 2026 16:04:26 +0000 Received: by outflank-mailman (input) for mailman id 1454556; Mon, 19 Oct 2026 16:04:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIpqb-00060R-Eg for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:04:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIpqa-0025IT-OL for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 18:04:24 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad63f52-8faa-0a2a0a5109dd-0a2a450182c2-36 for ; Mon, 19 Oct 2026 18:04:24 +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 6ad63f88-5984-0a2a45010019-b9ff1c238917-3 for ; Mon, 19 Oct 2026 18:04: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 1a154e828680008425.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 19 Oct 2026 16:04:23 +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 7106B81ACD; Mon, 19 Oct 2026 18:04: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=vF+WEXRBfEOMxtWCe+O/rbarwlMLMMIlJbENtRfQC6c=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=JLMTnBnzpg+QOs+7/Hhu6oe/DlvBmztD+mRgVmYsryB123M3f1yy7ALVEkfjNKRcnDLcNVprV Qwpbxt7gGRKv5rynubo4KhtC6zxRmfPrF8lm7zfeldmUsmOlEeSb5sSYA1T4X4+6IRMJGt0r8gE 2AxCPtp65c0TcE268UC1Ca81DD6eyJYlpJf1sqSyB6kuQCP4Pdx5GHg9EtIzeOvU67ZKSv5QwBq XLqaJDHgAavCBGCP+nfvfejw4jIQEYyi5ioUIOqyJOzcPNn7PvZlH84QTWe/H5hDF8dOSbdgPZE E05PWPRUBm7psS1s03eZmDZgXrBGz29oN9tVa4neV93g== X-Zone-Loop: 36a4802472b5b8bf914b396f21a0c0b05fd087b93c34 x-campaign-type: default x-transaction-id: cd0261d9-693c-4bce-a792-604727e47c21 x-swg-uid: 01-179c7cb6-33f1-46a4-a0b4-f8715d198d71 X-Mailer: Sweego Message-ID: <1792425863.8631fc262581453bbf619ec5b2062170.1a154e828680008425@vates.tech> x-swg-bid: 1792425863.8631fc262581453bbf619ec5b2062170.1a154e828680008425 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 19 Oct 2026 18:04:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks To: Andrew Cooper , Xen-devel Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich References: <20261019155959.883789-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: <20261019155959.883789-1-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------yS7l314wlWs0KG0LjX8AhSpG" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792425862591 X-purgate-ID: tlsNG-d62444/1792425864-BDC79757-DAF01267/0/0 X-purgate-type: clean X-purgate-size: 5271 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------yS7l314wlWs0KG0LjX8AhSpG Content-Type: multipart/mixed; boundary="------------7TlivENdj5RjZyiRB2kCiGfc"; protected-headers="v1"; hp="clear" Message-ID: <7b76e1f3-964e-4193-8590-912507b89342@vates.tech> Date: Mon, 19 Oct 2026 18:04:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks To: Andrew Cooper , Xen-devel Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich References: <20261019155959.883789-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: <20261019155959.883789-1-andrew.cooper3@citrix.com> --------------7TlivENdj5RjZyiRB2kCiGfc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTkvMTAvMjAyNiDDoCAxODowMCwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBC ZXR3ZWVuIHdyaXRpbmcgTVNSX1NfQ0VULlNIU1RLX0VOIGFuZCBlc3RhYmxpc2hpbmcgU1NQ IHVzaW5nIFJTVE9SU1NQIG9yDQo+IFNFVFNTQlNZLCB0aGVyZSBtdXN0IG5vdCBiZSBhbnkg Q0FMTCBvciBSRVQgaW5zdHJ1Y3Rpb25zLg0KPiANCj4gQnVpbGRpbmcgWGVuIHdpdGggLWZu by1lYXJseS1pbmxpbmluZyBjYXVzZXMgd3Jtc3IoKSB0byBiZWNvbWUgb3V0LW9mLWxpbmUs DQo+IGFuZCB0aHVzIHN1ZmZlcnMgI0RGIGR1cmluZyBib290Lg0KPiANCj4gTWFrZSB0aGUg TVNSIGFuZCBzaHN0ayBoZWxwZXJzIGFsd2F5c19pbmxpbmUuICBUaGV5IG91Z2h0IHRvIGhh dmUgYmVlbiB0aGlzDQo+IHdheSBhbGwgYWxvbmcuDQo+IA0KPiBSZXBvcnRlZC1ieTogUm9n ZXIgUGF1IE1vbm7DqSA8cm9nZXJAeGVucHJvamVjdC5vcmc+DQo+IFNpZ25lZC1vZmYtYnk6 IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQoNClJldmlld2Vk LWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4NCg0KVGVkZHkNCg== --------------7TlivENdj5RjZyiRB2kCiGfc-- --------------yS7l314wlWs0KG0LjX8AhSpG 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+p0QLLz9AFAmrWP4YFAwAAAAAACgkQZg+p0QLLz9Du VgwAoZn3QeA4hrPh2lM6T3w4c0KdZqBAXlavmckXd1mNFH5o4A42hxebRowS8Lf77oer2GQuiSgH ZIvrCD7c2JOWASsiDxQYQq+X62BhzvEtXhvGCdnGD1Rc53s/iZcRFnP1/N7s3LbmOgCk4UqdsxAy xoJWcKlaG5kdOWZK55AaKn3+nTo1i1LrxSMySaydR1sDXa0I/si1VCSOn1M8WyQTSFEsrONsAdA7 rFEnpxw1owbfBXIiXBu9D9W3SppW9EyAjDbvbuPI2l6BUQh6KyuHUrp7cTOuXu8DadMkWZQz0KYG BCgWB1MzuSa490E/lH2xDVJQvLW/tHD4lBXum7AHbw03ss0XSC7a2VMS+Mff4+vb1hbHSQt2hEIm WroKqAFfKkyQHQ+t2ticTlb7REdIngUm27XAOjvEHwUuO508g0EKVh2LpQgL1+IW3ojZVscTvK3s sQlq2CCeRx9WOmk5s56xZRXH4UgCF0i02AyxEUbwbOePNfjrmqQlR75JATiU =XUve -----END PGP SIGNATURE----- --------------yS7l314wlWs0KG0LjX8AhSpG-- From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:05:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:05:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454516.1668127 (Exim 4.92) (envelope-from ) id 1xIprn-0006aC-J2; Mon, 19 Oct 2026 16:05:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454516.1668127; Mon, 19 Oct 2026 16:05: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 1xIprn-0006a2-D5; Mon, 19 Oct 2026 16:05:39 +0000 Received: by outflank-mailman (input) for mailman id 1454516; Mon, 19 Oct 2026 15:13:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIp2w-0005t3-RI for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:13:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIp2w-00Ensd-7t for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 17:13:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad63382-bab6-0a2a0a5309dd-0a2a4502bb6e-0 for ; Mon, 19 Oct 2026 17:13:06 +0200 Received: from [209.85.208.52] (helo=mail-ed1-f52.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad63382-6ca4-0a2a45020019-d155d03490c0-3 for ; Mon, 19 Oct 2026 17:13:06 +0200 Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-6b1aa36fc0eso17968a12.0 for ; Mon, 19 Oct 2026 08:13: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=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=1792422786; cv=none; d=google.com; s=arc-20260327; b=oD0+etEaXy/sl5TrFDPZIG/8u1LWOq6l8ZLg6+yvGc8dSk2i/jhfPsc/cxT9NfZgVJ c7tFRPDtvq4Acq1/bvTUR0LqNQhZPg98dPW5I9urvjsLhX/tpdpeND3e8zzpjbywavZr jGDuDr0jXM/VL46dNly9tQpHZfvQW5xxfUrNJUOp4ePKfw+Z4/dsXJ12QbnVzwHYMgoW gY1w6tumQcW/ljUxMrGj+IdvOLkIUIinh8WyCQlzKFbnuJToZvNH3Vvn4IGey4/IsHLo 5GO5u4+CDfXqHDGIKfdY9XJjNDGqg0yzu6LyJ1EeyyXXfIKKQAGhpLQz4JlIuOJbLk85 SCNA== 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=/p9kG3mVIwDhglO8V3Ucme+ROyhYkCFN2qn2+pS+V4w=; fh=zXfrAGZcPAH1H+H6X6WdpvYLADKlg3K8IW6L8vxQKSk=; b=ia6rHut/lA6t0/AAFvXFRG9rTcd+nAa1rdzNoDs3Y2Mym0E8hMI2nswgwChq54E6ka 8AZZecm3aKNM2mpZTrb5FHHBR1152NC+2oCJ0cbelkBwMVuO+xW4aWcq5ZdVkqHCkgCt cdrO1e+BvRMtVQbhqwLL5lfqp+IbfGyFJSTwk7YCMENiAOegkN62BMIn5i+L+Chsw0ZZ aYeVATVMrBiTIN4NboOWlJ1iFKSwfPmwKTbmE+sU2pJs1KcTYUvySZU6trl3rX9GQZks t88xWj6MVEyrQ0T+R6qvWNq1v8M3nL3DzwW+yDFuXugeyeI5bJNNXNtIi1iE3aGoL+eH I5eg==; 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=1792422786; x=1793027586; 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=/p9kG3mVIwDhglO8V3Ucme+ROyhYkCFN2qn2+pS+V4w=; b=ENMuMszr6rbPuzvDP6sXtX7rLWX8n8RLMEUqaFIIsD7dcPi1TGBkRln65As7DCK9sF j1HBTXticshUNsIBvVE+/XRzIlQVC3rxqxIUkQjwk+OnWqHMM9WNdZQD0v3YAmi+kjhr vp03FNz8mRLivTkcd4ct34MCf6acdmg7OznKiA9TEPtRaFZwey9MJzzu0htlbxERqUDI nNV3iv4XUAElQw9wY6tlP9w6G9Of9YVAOFXzT/hyQaUfHCR8j0LoIA/p5YjeX7eEjA9f I1ddoRn160ISjXnpFmadmvDbaf4mw+EGdoX4/vB+SmGHvFu1dkKgrkY7e+DdMxcfR3mM qU5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792422786; x=1793027586; 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=/p9kG3mVIwDhglO8V3Ucme+ROyhYkCFN2qn2+pS+V4w=; b=tIrGlUm81LUcvbH4juEouUDWwX/pj/3BZcnXWZsQodyiaDe3rFCGGYJMYIm3WxKv/J nVl755O+ffwSHo+dlE3VsL5owUHvGLc4iZSJJM6nRFZin2V1CF8Xh+AjawwAgoasUUH+ WVIN/KM83ZEd9E2brlM2B1kfLsiMT4W0Q9LDnB08S3piv0gh5h3mFYHA4Fhh1gDHC6qM g4D7Zxapr5DtgYg0NQfZ1K1mnAPUgJgwFcIWEM50t3Dckq2VZs2BqrorOgTuMHh7f6XJ 6che/zGQZkK6QBdnijybtFR9k2s/f7hDBQmppwY5evfw0gHX0618QF3cstf2agsqgKEY jwSA== X-Forwarded-Encrypted: i=1; AKwUvBwdUbrbT5DYttDfZg3hUh921SKFpBX84zQbTrbO8QbncvoF31VswW/rdGZ1po+BiqWhPDGTH3/YBIo=@lists.xenproject.org X-Gm-Message-State: AFq9FYLpAynQ+3gy8BjI+L1Ceu/SGUXtTuU8uXE5y5wqPoo8EZ4gqYMs hbB3RmmdAzn2pziJjfa+aWuBEA8eK5o8IT1sa6zEcLsPSKo6qbIAqCIHwLPetaDutRlFfVaszkV nV0dwmyAgI08y5+jexYp2KaMEFJiM2/+dyj+v9rqD X-Gm-Gg: AYBFou0XpgGaGtNctLNKdHVt3k629YlsP8ZrlT2xLQKZ5b9toZiYWK7LtBKJ2QpcSOu WEG59Yk+ZL2ORcklJyZP73t4jZ71lP2XTnl4l+VdKL2bZBOK/W9ZGx+uV/v1BqAU9RLTYC7Xq4p eXkMb6vrvYC4WOB7xfkN+QcW2EWHovZA9sNLUWoo8ssRIwGp52/DoAe6UHTnfdZhbDUusc4WaUh fFD/wAT/Jd2FMYh4UCypc2H5W/HEFEnnYO7tRGFMyFcnJQ7QcwVrsk8Uj+DMpJSRHW3JZgvX/9s szIe7+KRAPwaL6gAUv50gFXuqalGf3jI/SihZM2PmmsEcljTYGDa4yKll4XJqf9B3vI3xIP2UYB d5U2aeKYmqPBviHQfZ2fq X-Received: by 2002:a05:6402:a550:10b0:6ae:1503:5a27 with SMTP id 4fb4d7f45d1cf-6b3ae3367f7mr84098a12.8.1792422784990; Mon, 19 Oct 2026 08:13:04 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-14-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-14-41dbef50b9f7@toxicpanda.com> From: Mina Almasry Date: Mon, 19 Oct 2026 08:12:53 -0700 X-Gm-Features: AclHuK9fMz77o2Ok6xnWRqmNEA6022u8uZTWFFEyJX4uvm-C0Gim7Z2E1QlIWY0 Message-ID: Subject: Re: [PATCH net-next 14/15] net/tls: don't BUG() on leftover length in __skb_nsg() To: Josef Bacik Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1792422786-F02992AC-C7AFC2E9/0/0 X-purgate-type: clean X-purgate-size: 1668 On Mon, Oct 19, 2026 at 6:51=E2=80=AFAM Josef Bacik = wrote: > > __skb_nsg() counts the scatterlist entries for a range of an skb with a > copy of the __skb_to_sgvec() walk, including its BUG_ON(len) when the > skb runs out before the range does. tls_decrypt_sg() calls it on the > same range it then passes to skb_to_sgvec(), so a bad range would BUG() > here before it got to skb_to_sgvec()'s error return. > > __skb_nsg() already returns -EMSGSIZE for a frag_list nested too deep, > and tls_decrypt_sg() fails the record on any return below 1. Return > -EINVAL for the leftover length too, with a DEBUG_NET_WARN_ON_ONCE() for > debug kernels. > > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > net/tls/tls_sw.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c > index 312e51270f29..1c578ea47a1b 100644 > --- a/net/tls/tls_sw.c > +++ b/net/tls/tls_sw.c > @@ -142,7 +142,10 @@ static int __skb_nsg(struct sk_buff *skb, int offset= , int len, > start =3D end; > } > } > - BUG_ON(len); > + if (unlikely(len)) { > + DEBUG_NET_WARN_ON_ONCE(1); > + return -EINVAL; > + } Ugh, why DEBUG_NET_WARN...? Seems WARN_ON_ONCE() is more appropriate, after all we're downgrading from a BUG_ON(). Another nice thing is that it could have been done inline: if (unlikely(WARN_ON_ONCE(len))) return -EINVAL; But I suppose it doesn't matter much Acked-by: Mina Almasry --=20 Thanks, Mina From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:05:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:05:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454513.1668120 (Exim 4.92) (envelope-from ) id 1xIprn-0006Xp-9y; Mon, 19 Oct 2026 16:05:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454513.1668120; Mon, 19 Oct 2026 16:05: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 1xIprn-0006Xi-7J; Mon, 19 Oct 2026 16:05:39 +0000 Received: by outflank-mailman (input) for mailman id 1454513; Mon, 19 Oct 2026 15:09:58 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIozu-0004pX-OU for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 15:09:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIozt-00En7u-8P for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 17:09:57 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad632c0-bab6-0a2a0a5309dd-0a2a4502bee8-4 for ; Mon, 19 Oct 2026 17:09:57 +0200 Received: from [209.85.208.51] (helo=mail-ed1-f51.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad632c5-6ca4-0a2a45020019-d155d0338da9-3 for ; Mon, 19 Oct 2026 17:09:57 +0200 Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6ae14cdc63aso15867a12.1 for ; Mon, 19 Oct 2026 08:09: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=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=1792422597; cv=none; d=google.com; s=arc-20260327; b=kZuQUrZ2AwFms4xAcIdBntRPYfpHZHvjOVh5khkOalI/eO9EfJalWOd6b5O4o3S3sB hgeiDsGoPKmDVUEsdWZvzOW+xUDiWOFnjzaQsOMxNJkxrHfs2gQo7fZZgaL9YlOMN+9F +RLducZfalPqlF5Y6Rh9tpuF9tVBSfH/L6L9HOKm8Y4jAi/yp39Hg1CL4uTri0+OdsUj Rr7hxcU/P0rTUVR+0CdBwtP319xcfsWJlw33hg3OSmOHGMsGDi4xeEm5gf6sT15kE1Wu 1ALg7Qr+f+rS/vXt1P5+aZ3kwhYv8Ypsu0ZJ2QcyXj1yOvFSq91Ju5eFaXlZN6xfVbxZ jSfg== 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=AWZK7vcabRIRlNI5I0Qlo1HJVZRHgTLgm0d3t+p60UQ=; fh=j7KtDfAVZ0xCKnedpo/AfKr/BVAFGsqOgyOvKdv95/8=; b=EWXZ7qU4X+V5+wxB1ApFMNEEFupM5ZGo7z02ZU+JjhhMd7mkv/l181vKiDE5//1MdR pxKKnDlLwlr1qfvvqc1q6eWyeuEDWijSgqTOQY6EGRiU6F0tkSI9enrDABiPBL6vTWkR 3SzA8ZHAueN9CJQcIfxePFTM4owNHOmvvZRYNdVVc+5WNBbGZm6zeEaksZP21B3g+XUl 9A6eaLtFDWN9+te3Ay1hQeg/FzG6gJvBrlZZbbFaDbUqtell3phz5zskOGUj2Wtdcu/9 hna0UiA4fjE7Ofkp7/cFdEzZ0bpgXUH3jVNiHLT/wvqOfZRcZhQ2Dol32W8gt+chmSTa PN8Q==; 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=1792422597; x=1793027397; 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=AWZK7vcabRIRlNI5I0Qlo1HJVZRHgTLgm0d3t+p60UQ=; b=irSSBwchgGpyHSPNhIboTFJ8A5TNdrVidaxhq8N9ZPjiXG1shGKCRMJhVaxFWE+P7k ox75FBeDev5RrR8uziwR9SDjjB8LrDS1BwB8J/FaRsz2/KuyjCSYRCSY99hWshcKxRln +GEL1fEmr8Pu3NjCW4DVPulQPbMbDMoz9C3tpln5VKI0NWBdueiLJPke3tGRdtw1Py38 so0c4JRe5MnPPNm5acQtyNQeAxW1n6X7ixqldnLDylGkYNzRsXSmCK4nIg260xt2GWpm AW5RLGoWklguzzlnUUovivQ/ZIXXol3jC02QdGxz5UKtcfObofnSYLuvfTZ0D32eN+kd ybaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792422597; x=1793027397; 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=AWZK7vcabRIRlNI5I0Qlo1HJVZRHgTLgm0d3t+p60UQ=; b=nzBKL5RWCM4vOqBwq00UbgMp0SE6DXu2uOnYHthe50LnckCynhsRi7mjplphZZf3w9 BDdnDy71lhQ3nqytNADKKJdFOb7NeLMZy64ACEz1SwXJWgCbJZMxv7J0M4GMyruWlrXE IgkEY06DcxmXJoXiw3s2dQ2HUQ21iY9Qjsr9T9tKyg4oIE10MEYGgLOFyRKK2XMOZuzP aRpyvPA3V8FpMBkBZlm0lsI8dn6cOWY7S0RTZ+BTfDdtpb9H1kHtYGg39Cab9AQaz/H1 9AMmTe3yFITaXB0UlHfH4aWvn7+jz5x7q2fWnIoXHwSXmkapHIxRIn7SuyJYCb/4cZN4 1lWA== X-Forwarded-Encrypted: i=1; AKwUvBzeGH/9QaUcpQCOo3rTAq0uJycD8ksU7OhLKudG2yj+Y+bUsS6zvgcg/8o7htHKtCSKl1IopoPDvwk=@lists.xenproject.org X-Gm-Message-State: AFq9FYLolrqn+m7WEymhjTay7Nz+MF3T/IHS6jLkK/mbhAXT3kc8bvI1 bQUbEQgywD2wWEOy9w4s2akalwVUda3GbLeAkj3/YorNcDOPILhAF2k9DTbjl3ChjIwCoJ5k8/K EfoAfjtdNcfAvNOoUSPwZ5Ioi9x90nEGh6Lw2ShLb X-Gm-Gg: AYBFou3P3QqLeF6L3tbsR3tktA3NbATHz8FR8nF+KigBqBjDB2adswIUMLAUrq+aQ+t ruWYhhCvMOz1VsYAsMx8D/FKafZ+WTrSOMGU3WixiEaBdCqaINQ/rSYWvvODzL2YgN0oJ3pKX6q 3yJlPc7GCv8LZhpA/a1xL/DymV3s8lUeScXhZCiuE4vIAHDpE4m3Q7VSTstPu3gWWnyxISFWaxT ReKDzn5HAoMbx9R+GfZQVOiTFILMelx5grctEHrPIUvTBFz1WOjgdzhG7JVTmbNsvLOflkM8v3O fgZs0I0J6nr0Hfy7nUqVsH8W9DXkG7jSFYrq4jMVAVDMVGwD/LKn0N7xpyYbOVnO5K+V/sq4ZT0 9FKO8bVLasQ== X-Received: by 2002:aa7:c0da:0:b0:6af:afce:184f with SMTP id 4fb4d7f45d1cf-6b3d47d2378mr37599a12.3.1792422596059; Mon, 19 Oct 2026 08:09:56 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-15-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-15-41dbef50b9f7@toxicpanda.com> From: Mina Almasry Date: Mon, 19 Oct 2026 08:09:44 -0700 X-Gm-Features: AclHuK-dz-bSuEIE90POvdnsCfCUclg7akbJCTc6RZqWm9wZlCW3Q22i8toaMP0 Message-ID: Subject: Re: [PATCH net-next 15/15] net: update comments that still describe the skb BUG_ON()s To: Josef Bacik Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1792422597-30DC12AC-D9FA3D89/0/0 X-purgate-type: clean X-purgate-size: 948 On Mon, Oct 19, 2026 at 6:51=E2=80=AFAM Josef Bacik = wrote: > > The skbuff BUG_ON() conversions left a few comments behind: > > - bpf_skb_net_grow() says skb_segment() BUG()s on a frag_list with > head_frag set at the downgraded MSS. It fails the segmentation and > the packet is dropped, which is still why the skb gets linearized. > - The GSO KUnit test says the non-uniform frag_list case would hit > BUG_ON(i >=3D nfrags) with SG. That check now fails with -EINVAL. > - The skb_to_sgvec() kernel-doc doesn't list the -EINVAL that > __skb_to_sgvec() returns when @offset and @len run past the end of > the skb. > > No functional change. > > Assisted-by: LLM > Signed-off-by: Josef Bacik I would have preferred this change is squashed with the code change; if you re-spin for another reason maybe do that. Acked-by: Mina Almasry From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:26:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:26:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454574.1668138 (Exim 4.92) (envelope-from ) id 1xIqBR-0002UQ-4F; Mon, 19 Oct 2026 16:25:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454574.1668138; Mon, 19 Oct 2026 16:25: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 1xIqBR-0002UJ-1T; Mon, 19 Oct 2026 16:25:57 +0000 Received: by outflank-mailman (input) for mailman id 1454574; Mon, 19 Oct 2026 16:23:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIq9A-0002M3-Tg for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:23:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIq99-0027g5-Vz for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 18:23:36 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad643e2-bab6-0a2a0a5309dd-0a2a450b922e-40 for ; Mon, 19 Oct 2026 18:23:35 +0200 Received: from [209.85.210.171] (helo=mail-pf1-f171.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad64406-b7e8-0a2a450b0019-d155d2abb07a-3 for ; Mon, 19 Oct 2026 18:23:35 +0200 Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-89f85edd210so1043701b3a.2 for ; Mon, 19 Oct 2026 09: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=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=1792427014; cv=none; d=google.com; s=arc-20260327; b=QfqtTApkJDj2muIa0sVhieDxvFmlOp1ysb53on+xUOVGam3A08+68cc+7EyJPQwuNn nbomLr8PpwT+r1XQb1ke4FzALXdP/ragyyyApl8E5xAIGRlONT84usqmK1gQ4jophJpE j19AClpUaHMIpR/SLniVrxQBIm/EQjPqX7PsQMLJZa5GFpv1WyO5mEfBp+Tuo0X+30f8 iO1TO1xVXhq6ArGdt1ofKj6z2oO+TehOvN8GxN+g/c6pY6LwnouNwPqU4Ssl3SmFdoDh z/SG2xlttooHvcVKc44rT5qmVOVEnr3LUhGcHqz0lT0hM/gLSDLHFH743ZTei0ywy3C/ YmDQ== 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=DTIxUhdK5WwE/ZvzqZ/orvmnDy6Zp8KzQx6MCWL0bYU=; fh=rFkbf97nRC+gtwLHBW2vGZt53i94TA0CqB43VrFLPzI=; b=p/StDDcG+vCtC02V0aS/di2vluCTO6SezBnaEZQ6zcP5cFu1bIrT+/y9BbR0Ww3yj8 W/UdR+zh9BQ2+wcM642hjcfBd9v7UP35sjeZRRfjpIsFkesuu10Ievo23pGmA760jgXo /GRIbKzxwoQIJqzUv+aiqx3y7GlEGNLIi3fHyyZoV3LWxILjc1mcXyQh+gZsvEjdZhCW 3hwheSVVWQlO1OEfaCWTTaY40lZ8LgYdQzrxsFQg+qiROmQktaUlyoc9n/lLn/KuuEmv RbXif6kIWX0JAH5SJJerJmvP7ZwfOkE+gzxmG/IXwtEgBDdlwKxfNuuCPNDpYd4WLVNx B+4g==; 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=1792427014; x=1793031814; 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=DTIxUhdK5WwE/ZvzqZ/orvmnDy6Zp8KzQx6MCWL0bYU=; b=mT0IWYfhT4UBmPCVNA1iVunOnGvAKbRyJ2Gu72q+pW0Z8IL5+UmxjOJh+9hJkfjKyl s0lfxVbFnWx4v0+DXbxnSncVaCf4eKr1GS9x1HQIqSOIm0jddwShTdQgd/FrzdsSYW/d Je425jEAChaPd3AlzhUQCo3feMRcNrCy/7gcO4nszGU3vBlcaKyRkYUE1fLc7s0HOVOE 5R8OnTPadwtGYPfQQw5Jl6PWKThcG40Lg9FtzGtKDqXB8VzWwZpqlVsmPcchTIvYZ3Pz 8wlCr0GFo2I0Hiko5eYBzVzvSv61F8csfdktgpeF8svaY37MliMRcX+oPwc6zs1/fY38 aPTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792427014; x=1793031814; 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=DTIxUhdK5WwE/ZvzqZ/orvmnDy6Zp8KzQx6MCWL0bYU=; b=cxgfQfH+fePqFewjT/nRm/rWQ3aCQ9S2Yiu99F1P8c9fxVboYBpvvSqZeeEcX7LNXi o0zbfGQGw7Gd+IJZWXYGmAF0Z7Dwsh7bGFFksYLgUGoHNZU2U5SQrNQICnFOi/ZIMTk/ 2K3CBCgtZ0z5Y7kIi1Jf770fgtNS/uLon20xRmt46qrCThjYWW5SnKCrOMIu2wr0Ctfn foutD6TkBg6hRIX6hObQpoeusdk1L4Kb9ouvBjlKlOHD+ISh1whbz4Gp/27zUSYOp/Z/ oIGsGw8dVwAI8SE6eKrctrQ2tqIV4h1AVqv8Ez9IvtCH89bzhguz00KgwG4k3ejUqXbw nnYg== X-Forwarded-Encrypted: i=1; AKwUvBxu8itAP7h3HCHuiUxBfExqH39siojsAD58awr0wmXITxnUIhtiwwg5H+7aOYbrMH58TtVOTyDHIGk=@lists.xenproject.org X-Gm-Message-State: AFq9FYLeUF1wZRM4B4DUz4DbGzDx2fxmzf2C0jmIKGWKzGMaCvMbuE2K 0KHj0y+8FWJ5RqkI8+SyWlzmFxYurpcrX39D6YiXIO+yrUdnx6A5b8Wy9taHh5hVbta+4PhIjDO 2yVE++sIognNrzRdUg86ZGPbMVugLdus= X-Gm-Gg: AYBFou0LGhnMVDMccF4q9McBoklJhRE6Xs9RJpEypNbWZuZ1bkT/m6QSgrOXhYgSJXm GdiSBxLfwtkX8TyAYATepePoAQPSQAqT4kKWYHmBBEpAdTKW0vt3zI5JZFzrAiOe96/n//s6/wr ZZprH2z6wnFn4XKQnn7SNFO9nRVIfRuIlyOFlngbA227FxiwPFK8fr2KRxJSmdgroVuPlLvoHSH 7z/9ESWQZ3zz30dEJNYVPubGUn3yxzLxNgzSie8LtheeMd/cGMCvNurQjuk8Od77SOrNbTMZGTu fNCSHP5Ua8sSxMBgWTp8Cv2M3uwi0Ao9elLNQbRhi+3+xNQYg9DetK5QrENKzR2TyE/yMFy/MvG FOGRdG/YsQuFjANVcIzF6u5hszOr/6cd2ejpzSojxb5hH+02dgq3PKGrqDDGZhnsYFhZRqqISct rQ X-Received: by 2002:a05:6a00:3316:b0:880:f278:6af1 with SMTP id d2e1a72fcca58-8a04a44afe5mr5370952b3a.7.1792427013773; Mon, 19 Oct 2026 09:23:33 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-14-41dbef50b9f7@toxicpanda.com> In-Reply-To: From: Willem de Bruijn Date: Mon, 19 Oct 2026 12:22:52 -0400 X-Gm-Features: AclHuK9ZHv_xyJSLtrCr1JvpLx2mRNJEtxy6hgM41LaZO6bj4mAjFn_L38w5UDA Message-ID: Subject: Re: [PATCH net-next 14/15] net/tls: don't BUG() on leftover length in __skb_nsg() To: Mina Almasry Cc: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Fernando Fernandez Mancera , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1792427015-1BED69EA-D530D80E/0/0 X-purgate-type: clean X-purgate-size: 1814 On Mon, Oct 19, 2026 at 11:13=E2=80=AFAM Mina Almasry wrote: > > On Mon, Oct 19, 2026 at 6:51=E2=80=AFAM Josef Bacik wrote: > > > > __skb_nsg() counts the scatterlist entries for a range of an skb with a > > copy of the __skb_to_sgvec() walk, including its BUG_ON(len) when the > > skb runs out before the range does. tls_decrypt_sg() calls it on the > > same range it then passes to skb_to_sgvec(), so a bad range would BUG() > > here before it got to skb_to_sgvec()'s error return. > > > > __skb_nsg() already returns -EMSGSIZE for a frag_list nested too deep, > > and tls_decrypt_sg() fails the record on any return below 1. Return > > -EINVAL for the leftover length too, with a DEBUG_NET_WARN_ON_ONCE() fo= r > > debug kernels. > > > > Assisted-by: LLM > > Signed-off-by: Josef Bacik > > --- > > net/tls/tls_sw.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c > > index 312e51270f29..1c578ea47a1b 100644 > > --- a/net/tls/tls_sw.c > > +++ b/net/tls/tls_sw.c > > @@ -142,7 +142,10 @@ static int __skb_nsg(struct sk_buff *skb, int offs= et, int len, > > start =3D end; > > } > > } > > - BUG_ON(len); > > + if (unlikely(len)) { > > + DEBUG_NET_WARN_ON_ONCE(1); > > + return -EINVAL; > > + } > > Ugh, why DEBUG_NET_WARN...? Seems WARN_ON_ONCE() is more appropriate, > after all we're downgrading from a BUG_ON(). Another nice thing is > that it could have been done inline: Because that still triggers on systems with panic_on_warn. See also https://lore.kernel.org/all/willemdebruijn.kernel.140f4eac91ab3@gmail.com/ From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:27:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:27:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454581.1668148 (Exim 4.92) (envelope-from ) id 1xIqD8-00035B-EK; Mon, 19 Oct 2026 16:27:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454581.1668148; Mon, 19 Oct 2026 16:27: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 1xIqD8-000354-BQ; Mon, 19 Oct 2026 16:27:42 +0000 Received: by outflank-mailman (input) for mailman id 1454581; Mon, 19 Oct 2026 16:27:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIqD6-00034w-PT for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:27:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIqD5-003tTm-Uk for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 18:27:39 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad644e5-bab6-0a2a0a5309dd-0a2a45099ba4-16 for ; Mon, 19 Oct 2026 18:27:39 +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 6ad644fb-be1a-0a2a45090019-d155d0319154-3 for ; Mon, 19 Oct 2026 18:27:39 +0200 Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-6afac79b3a3so17007a12.1 for ; Mon, 19 Oct 2026 09:27: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=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=1792427259; cv=none; d=google.com; s=arc-20260327; b=cdrWEL0DacxN36iZehZzgosNWLLpVWvwUXp7yPNKc/U9B2KTGdWB1YGFbMOJb8mi++ g0G1yWeLcNMxW/yiOhZOAI6dGEW+ep9AEa08WPtBQGmO3w+JD6qUagCZ+6uMYlI5QPaq 99L0kMYj5IsDZoD5C3cuovS+bu8S7+W+Kt6V5nVY23IQSySbyiw2EfTs+0uOCST4gn7d XW972dvW8L6yFzlDT4hqLumOm8A0PgA3hqu//11fPWEF1WDUAtpRA/EQZz1SJqYYso3l a1VO4LdefeMkduJoFjUS2j9OJ8G2yFJU/5cmNbB/wjxjTbeezgaLjMKL40oeRRu0iiLu xsXQ== 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=jvYDp8Hgj7nrDsJX6hOppStmzsVdbwBuZBD84+051RI=; fh=lkB1jETwqzF5ls4xj6Ut4H3anCNEvkrGVOdtIp6ydo8=; b=HqpTBeQ8EiIacWF3aLmoAu2Jct5dA68H5koZ/MsACoay/GHrQFmAmAyn9Q4RPIpWbL BjeS5+7WWY4ncqkwDA7nzSP0B/t0vkeZlDMkSzaitKynGZzYlkwm7KuU7SGKAG7ldkCD EpFaA9FM5a/wcn0uTYhHS4PgGfxgDO52K5ITeH0F1NBw+R5Gjw/11mhag5BG1zehRtpt DMRhBoIBmzG6OqF5bgoXMtAO7OQJbF00DlVM8C+IorcJID9KFO1bCngKjiY2HUAkATco 2cbU5LyvwP6gELLSBlv5vSO91ikZBjKyYO/Ysrs4lDUpFZbOL+XvjeQkXc9hvhvBAf4Q AVTw==; 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=1792427259; x=1793032059; 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=jvYDp8Hgj7nrDsJX6hOppStmzsVdbwBuZBD84+051RI=; b=P2GlWHT7kwG0aSG/PlyJ/TYQl575swW4i402sAK7964pxSIvlY12+uQJ/Gf3XPTKy2 zb7fcOTio21pOvr2CWR1t85YyZyNR8+ioRuN3K4iqNXrBqQa97i5lIa475bd75n6OrHK +yjnvIVMcP0ohx3oCctbUrhsVaiFXQyVO+nZqjq5RwFO57BuV5r3DDi1eaVrCBseNUxK t7uRcq9Bh4OpzaE/yyhaDKlgrbiP2XxcVZ5K1IlXXKBSRiiDFP6hmtSMEKdVUtMJbAD9 HJJXy1fWSXCMXsVRRudROCupx9rIOojP3MuJHF2UnPP3HJ7IEypWA0PCSUmVFCl2dn7k zfGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792427259; x=1793032059; 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=jvYDp8Hgj7nrDsJX6hOppStmzsVdbwBuZBD84+051RI=; b=JzvmzvUBcEmn1USiuXGBMsjKJcP+aETtkJS/qoUdAy1mZ/WRtXQ7x2mPnUMt57XFpZ nSQQlGqPOFtBRVZAW+JKOtQVbDR2w7jcqOOWSoOLsV96Cp8ylj+hKwEn/O0Uk8nLsOd1 V5T4JKT2yDr7KRZJza8clJctrAYTsPJDy0xXfVuENGqAc+Ku9gWGIw7M9r/4+fME+CCi aPsKQu7nRU6Q07SVWZ2j8ySJht/QIw7KOUfFtzFqSPPAeojGnJ8D3ukJoo2KUNKPbHiH MxGSrzmo1ZnIffWcaZPaLMFDo7Blwux4VrrX7PFDLt4hisvGVXVZrfFZRBL4ZeAofNNS 24XA== X-Forwarded-Encrypted: i=1; AKwUvBzRk4Lek3XtuJZ8mpvG23mu4QroaWQLUiJyo5dd6GDYkr+R0vSREiDXZCpYLhnGLdi7TL+4EHNGwFQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYKhE7pUoUEPz8dZDIUTMzmGhimIH3xJqkUO9JFESKwCPCTWZO/d z3KWKrBcZ/GILtKDvQpL9OHeQPO7DUZMC6AfVapLGsR2QA5sYX5eAJEfK1MdHjIMiiHhG3y7TQr aWI2ZbrCMwzOT4r4fxjZSbMGuHP38R+7cXele/j2E X-Gm-Gg: AYBFou33ZUH5RuDy8imZAu+9Xjk6yVH2RYi1QO4xyO1i6uEkqIOBKImORyypjZfggEF 4/RDtnXiYS+vPnKkuW8AEVcfZHn6oWgHBy/cv43h8uRTcP/QtWKgauwclCqETNxR7w6RecQwZMj k2ROaNOpi+BUAE5/FKhnGBpPDRkeKyQUjIt0joGeP4CsastGPM3860MKqA20leWj0eFwTFkU4nm ka2jFCQDyZG5Y4nZeStRHTuxPbwhtpecCmwCJRxXIfWyEO2Dx16Ose8iloBsK/VWa/s67tpe2Xs PCitUea3k+D1l4IPCHx2fUjAbgr8dzU6L33iXJEOAx5HxZ76tjDwYdEht0UG4OKAMCuc0u88M73 YwN0/l2Ow+KYrqu/iDnTZ X-Received: by 2002:a05:6402:4052:10b0:6a6:8513:7e14 with SMTP id 4fb4d7f45d1cf-6b3ae336676mr18681a12.9.1792427258726; Mon, 19 Oct 2026 09:27:38 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-14-41dbef50b9f7@toxicpanda.com> In-Reply-To: From: Mina Almasry Date: Mon, 19 Oct 2026 09:27:27 -0700 X-Gm-Features: AclHuK-UIC0HG6JOck2i4c0hPYtzFxPXwWW3DcSBGnG1oasbGjmvMuZRGvs17qg Message-ID: Subject: Re: [PATCH net-next 14/15] net/tls: don't BUG() on leftover length in __skb_nsg() To: Willem de Bruijn Cc: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Fernando Fernandez Mancera , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1792427259-BF4D3034-69110AEC/0/0 X-purgate-type: clean X-purgate-size: 2173 On Mon, Oct 19, 2026 at 9:23=E2=80=AFAM Willem de Bruijn wrote: > > On Mon, Oct 19, 2026 at 11:13=E2=80=AFAM Mina Almasry wrote: > > > > On Mon, Oct 19, 2026 at 6:51=E2=80=AFAM Josef Bacik wrote: > > > > > > __skb_nsg() counts the scatterlist entries for a range of an skb with= a > > > copy of the __skb_to_sgvec() walk, including its BUG_ON(len) when the > > > skb runs out before the range does. tls_decrypt_sg() calls it on the > > > same range it then passes to skb_to_sgvec(), so a bad range would BUG= () > > > here before it got to skb_to_sgvec()'s error return. > > > > > > __skb_nsg() already returns -EMSGSIZE for a frag_list nested too deep= , > > > and tls_decrypt_sg() fails the record on any return below 1. Return > > > -EINVAL for the leftover length too, with a DEBUG_NET_WARN_ON_ONCE() = for > > > debug kernels. > > > > > > Assisted-by: LLM > > > Signed-off-by: Josef Bacik > > > --- > > > net/tls/tls_sw.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c > > > index 312e51270f29..1c578ea47a1b 100644 > > > --- a/net/tls/tls_sw.c > > > +++ b/net/tls/tls_sw.c > > > @@ -142,7 +142,10 @@ static int __skb_nsg(struct sk_buff *skb, int of= fset, int len, > > > start =3D end; > > > } > > > } > > > - BUG_ON(len); > > > + if (unlikely(len)) { > > > + DEBUG_NET_WARN_ON_ONCE(1); > > > + return -EINVAL; > > > + } > > > > Ugh, why DEBUG_NET_WARN...? Seems WARN_ON_ONCE() is more appropriate, > > after all we're downgrading from a BUG_ON(). Another nice thing is > > that it could have been done inline: > > Because that still triggers on systems with panic_on_warn. See also > > https://lore.kernel.org/all/willemdebruijn.kernel.140f4eac91ab3@gmail.com= / Heh, looks like we have the opposite instincts here and I missed the initial conversation. DEBUG_NET_WARN_ is fine by me too. Thanks! --=20 Thanks, Mina From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:52:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:52:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454605.1668157 (Exim 4.92) (envelope-from ) id 1xIqaz-00086k-BC; Mon, 19 Oct 2026 16:52:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454605.1668157; Mon, 19 Oct 2026 16:52: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 1xIqaz-00086d-8N; Mon, 19 Oct 2026 16:52:21 +0000 Received: by outflank-mailman (input) for mailman id 1454605; Mon, 19 Oct 2026 16:52:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIqay-00086X-Cc for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:52:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xIqay-00000001zTf-1i4a; Mon, 19 Oct 2026 16:52: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.98.2) (envelope-from ) id 1xIqay-0000000C5Ml-0BJ8; Mon, 19 Oct 2026 16:52: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=gfNxw1p1gN5aBybISNACLPtMDf5a24eOGTjf/2OENws=; b=eZv/fPZhuZkLkRdIJ3WH4AwjOY DFUPg9FCpvmdq2T3uPBmLlD1qP1e2dbNXrJdfqmupWMbYVW3Wa/WnrfNRo0+3zAatXzorV1pXEkkW TezA69lVVwkun3c/2Q3G+EihQf4OZ4tvZzoxy5/yr5/L1GgVCtEvRVFbDEZazqLt/qew=; Date: Mon, 19 Oct 2026 18:52:10 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks Message-ID: References: <20261019155959.883789-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: <20261019155959.883789-1-andrew.cooper3@citrix.com> On Mon, Oct 19, 2026 at 04:59:59PM +0100, Andrew Cooper wrote: > Between writing MSR_S_CET.SHSTK_EN and establishing SSP using RSTORSSP or > SETSSBSY, there must not be any CALL or RET instructions. > > Building Xen with -fno-early-inlining causes wrmsr() to become out-of-line, > and thus suffers #DF during boot. > > Make the MSR and shstk helpers always_inline. They ought to have been this > way all along. > > Reported-by: Roger Pau Monné > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Originally this was reported by Stefano, so it should likely have his reported-by tag also. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:53:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:53:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454611.1668165 (Exim 4.92) (envelope-from ) id 1xIqcM-0000BH-Kd; Mon, 19 Oct 2026 16:53:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454611.1668165; Mon, 19 Oct 2026 16:53: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 1xIqcM-0000B9-Hn; Mon, 19 Oct 2026 16:53:46 +0000 Received: by outflank-mailman (input) for mailman id 1454611; Mon, 19 Oct 2026 16:53:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIqcL-0000B1-C5 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:53:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIqcF-00F2rc-Hm for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 18:53:44 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad64b12-e002-0a2a0a5209dd-0a2a4506cf02-2 for ; Mon, 19 Oct 2026 18:53:39 +0200 Received: from [40.107.200.22] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad64b11-195a-0a2a45060019-286bc8166f4f-3 for ; Mon, 19 Oct 2026 18:53:39 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LY0PR03MB693564.namprd03.prod.outlook.com (2603:10b6:404:219::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 16:53:36 +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.0522.017; Mon, 19 Oct 2026 16:53: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=TnwmLCMTRdPuYhKvAtDfIHVa7oqKnEOyq7yD11x7vTyuITR8Ne/uVnxSFWkDaKpF0SduceKH96fUGSvLvpQUzFfFdtyYLcFddW0YxXq7YUDs5Nva/+UC+MH4zh92N+36tQup7b5qs1+georBWvWwUtf9FE6OCJhOvv5tLoxerRKO9HJZrfjyzsYYtecLXg6uC3ltAJQR+d5g6zs4EHzNoZEfYpOzMSEfpNX/t+yWOTBtm7xjgNKRIbD9AVfHdZU+rWYGh9Ja8Mx9pA8kdbRtF3dy/BYklURffCkNsNWHmsQMaIqI+WZT2Aw0FUJSwUPO+wistrF2uzKM7eJCvw2EpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ChK35QdNKF7oaPjQQCXoMlySTZSqxGkqsiuce17Qams=; b=UPeLzV2nR4L/EfDqZrDxrDSs/5biyFBo2zWr1xTRgsF0YPjmto0sgaRqyWB39XqyybBNinjTq4Of13S4VTu7CuBzqAYx0HznC8+QCAD5+C75bUKIsYktBgndBZ4DoMIASUAhUPNdfsvb8UOhkL7qO4mVhG7TVmTy3JLvwHOvBdrb2Cf2cDH7wj5sxv1RyaUThCVmA3+LDtrKAJPZQlTw0/FUQcPBuaalIW6IZufqOsAre8FKfevOyDsTdbB0SWVFH+iI3d+PmDX/DFyTBDNo90DUVIVXYIhRJd+WKbGLOWdpe1eXrx1GZq/LzASIkNPcLAOioj9up8yV16bmyJfNRw== 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=ChK35QdNKF7oaPjQQCXoMlySTZSqxGkqsiuce17Qams=; b=RvXUM6aOBvKW6Id6WU/bMAvUQJRx9ocnhqVbyONWkoRYe6v4GO4nIvZC4tdXIkw9qIGYfwCuxRHFt4Slelyh4+AHE2bZF8GA0R1N6X08+BzFaeX9O9vpLy8rrJEfNTdYixtaP+Oo36unndjdqgXDZu7s7nJ40eNm/2N/RxYHWMU= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <527158f3-a82d-4146-9a19-8bb257c6ceeb@citrix.com> Date: Mon, 19 Oct 2026 17:53:32 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261019155959.883789-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: PR1P264CA0162.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:347::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_|LY0PR03MB693564:EE_ X-MS-Office365-Filtering-Correlation-Id: fcfc7e59-f314-431f-37f9-08df2e018472 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|56012099006|4143699003|11063799006|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: jXQpgBCjoG9z7e7MVE+UZV9UXoUtWUqKLMrzcgrqbO0+0rCXB908QrT6YyrXR/RgGJ9m3hg9KSISFOp+DyB2R0kYJ8H3nCyjACfBhAHWuAAKVeYVUJ4nPvdqumIIA7bdCcuZgSC9oWjtPXkNekHkdM52cS+eeoSXzbZRB98CtlcOeA5OF+AK76dY+MbxsB0eCT32D+9g4v4RcBalzNxZ/V24ndU3VLonIgEMUmmWnF0y7VhdzNa4g1oiHuj//OMRhFg5VQOZ/v2cS7yVJLaYI3aw1F+UyP0DjMYvdu0Vn3D+kThADuApJCCJx61hZMP4cjC9GL0CBZ+tmGY5/sDz0tbIAHiOcbVuF7Uuxl1I90404EhZ1jEJgPDgtQP7ddcJKxmMrNIz+zl9sPtGuTC6EuH733pMYYMtTe66fsf62RvR0Nl/uET5lZ74QBAZzbNQOvUONKeU05+h1IPuwQ/BelyONJeIOiWhrN3PU0U5HYWdAf+4GTPs9sLdP6wB8HCeEuxaE9JoeKlX1Kh4Jnd+FzWoMbYqTdvZjTipZD6b7S+K7b9BCS4rPBx0Tk7xCRw+PABnRLdHspir2QYnlkc4fSfKMuzmDb6gHtjAEfqInklQGv4dm8e9X5uBL4FhzdZmdRp+9xwrmEo1mct2EdBnVBkD3k1rrcwqwRKsWwPZRZ4= 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)(56012099006)(4143699003)(11063799006)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z0w5V2pPd0lJVWdSVDgyZWZkaklPV3BOcld3czRaU0JtTVV4TFBuemhmbFBD?= =?utf-8?B?Qm1GdVdhNkxJUGFCSnNVS09abFgyNFl1bkdpRktiVW9rMjI0V2t1U0lOTmE5?= =?utf-8?B?ZWlSNFI2RjcveG50RUtMVjUxUHVJV0RKSVdDK200NXlXUjFPYng0U0FKVjFz?= =?utf-8?B?N2V2MlVHNlZqdnBSUmcrcHdFd1NlQVR1a28xQUhjVFZ0ektRQjc0amhsT0NV?= =?utf-8?B?Q2hGa2IrMkR5QTJHa2VWNnhzQzg4U2hRb1VKdVZlUk0xTEZ0cGVoaXJrMWo0?= =?utf-8?B?SGRKcVYzck5HQmlNYS9vME8zd2JaRkhNMnN2bzVZQlBoRnJLbDhVQ0tmSGJa?= =?utf-8?B?V2lJSEZ4US83L2ZUMGxnaVp2NUZTdm9Hb0dmM3ZnZHpScmVLTHZ1aHEyTFFt?= =?utf-8?B?dXRoVjZlTjlmMm5MejduQ2FWUlhDM2Vpa0JnQnZ5bmZEMW1wbDhwSXJOajRR?= =?utf-8?B?SjdYd0o0L21kYVh3eE9HZnZmcktKeUZzc1BYWkkvRnpDaHlvSXVYcEg4b1k0?= =?utf-8?B?akduYTYwcUlxSGh5NjdTV3hMSHc1ZkJGUXNUWGk3cTU0YXhCR3BLK1ZwNE0x?= =?utf-8?B?RGlsdzlvaDkxWE5PV0k2UXpTYmJKRWIwOTVoNVVFOFA4WnpaUzNIYUc1Q1ds?= =?utf-8?B?UFk1aU5NZExoRGN4cDkyV2ZTd0VYdktERXZwV1l5MVpRdHFrc25RZFF2am11?= =?utf-8?B?d3puRDFFL0RUKzFRSmgvbSt5Mi9TSk0xd0RpbDFwNGtZMHdrZWYwemVKVDJB?= =?utf-8?B?NTZ0T0p5VE5GSWt4OVdTNXFWL1JhR2lERWNocURuTUoyYW9IMXIyREdWT1pV?= =?utf-8?B?Vk03V0w0RnFxTW5ZcGN2NXA4bkNxQ292amZJWFNlSkhod2xaTEcwaTI1NEFk?= =?utf-8?B?cDVTOFh4QkJybWp1WnU3YXNHZkZyTGNVdngvRGx2NHRUR1I1TStwcXhaaFVP?= =?utf-8?B?bUNIWEpKbWtjRjAra1JWMDJQeXIyeXg4UUxueXg4UGRyaUNIUE5ZM2ZKZGdN?= =?utf-8?B?dFBSRVkrTzVzNzNiSll2ei8vV0J4UTNRNUJmTHVZWElweHJJOVk4TGU2eGVE?= =?utf-8?B?dXJORUZ2cDVTeTU5RSsxNWNuQm5KS1k2NWpoYU41VjlteFp5aldpWnRYZmhv?= =?utf-8?B?V09NQlNHZC9NTVdjbjdRdy9sNUpBY2FoQXptdjdVWStRb1ZiWHozUUEyNTNw?= =?utf-8?B?eHlIUlh0QitoWThaVFozTVUwVUpPTlA3NzBWWTU0bVEzbVI1cjRRZzROc1Mw?= =?utf-8?B?MlRSTTlGUlhNZkNHbVllTzJtY0VDdDNvdU1PbzVITDVkak1IVTNpMVdCSkFQ?= =?utf-8?B?Z0gxRktxK0hQSDkwcnkzS2hVV08veEEwZG5ZU3p6dk9GcWNKYmphTGxVWjBR?= =?utf-8?B?Y2NEckJJOC9udVlic09LNlhPS0FheFFVSzV4MDdFL3krSTd2c3dOL2lsUWhR?= =?utf-8?B?VzdmNVJySUtxM3JUZzI2eXZ5Zkd0dTdQTkp1dWRoOGhITFExakc5K3huVWxw?= =?utf-8?B?b2t4Z2JwZnVzaThhK2U5a2N3TXFCY0VkemJ2WjkwQ05RbkZ4Y2VSaFA4MVBP?= =?utf-8?B?dGRNYmNLSnplT3c4dWt4Qzdab0FDczFER0hLVzduMjZBSlFtQU9CK0VkMDJS?= =?utf-8?B?Z2EyVktkbEliTTJNWDlYbGxnVFArNERDbUtWaTAxc09VQWNUbjhudU01RnJQ?= =?utf-8?B?MzV1R082dG1Fa1I2alE2bitvVFBEWGN4dHFzdFRjaWdXYWxQT3FUb0JVUG5q?= =?utf-8?B?QmFWNjdPWGpqY0RSRHZXcFlIQ2xvc0NhNDU5NGxPbFZ0akluY1owS1JVeHQy?= =?utf-8?B?WkN3S2xFT3FyY0lPYkRraS8rUXRFc1VyZjV6WDJ2V1ZSR3dTbmd2NVVvR0pm?= =?utf-8?B?Vyt0VWxZUm4xUk1nYm9nOVEzaUlsQmttNU9Pd0lxbzNsejNORlBiM2Nsbk9j?= =?utf-8?B?ZENuS0xtOVNpdWtaVWNJR0N2QUZKTVRuZlhBR21YckZjcjRZeFY1T205UFVP?= =?utf-8?B?eEJKa1RwL1ZUbDdQOWVCN29KZDRvUFJndkxEcjdUbWRMMzRYTjgwNEgrQXZn?= =?utf-8?B?Ulc5dHNCN2U1WkcwZ25qWlFmVElhVTdjYzZIUjhEaUxya1dLUGFLQXl0djhj?= =?utf-8?B?Y3RocTU4elFIc2R5VmdUVUlabUZSOHFaRVhuWkpOTDJRU2FFTC8yaTh4SUVH?= =?utf-8?B?aHFHVjRyYjRYYnh4ekhaWVZQUGtqWXE2UmlOK3pGc3FzbVp2S0lmTFZCbENX?= =?utf-8?B?MFpmdUpyeWhubWZ3L0tVM1RYUURxNW1tSXJTZ0RRT0s0Mmt3bzIwOFFEK3Qw?= =?utf-8?B?aFEvcFd2SG5qc1NORU9rQnJkSlkvTUNQblhGQzQ2NXE0OGxiRGhVUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fcfc7e59-f314-431f-37f9-08df2e018472 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 16:53:36.3644 (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: tT0miBDAKpOp0svZjeoIFBitorPh6w2vzyPBqGPAtDlHkttG2oIzI/NLTuXf3YN9id62j+3qcwbV2od/uszQ/k1VQJh7jsP9g2Fa0tk+QD8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LY0PR03MB693564 X-purgate-ID: tlsNG-16d1c6/1792428819-F627077B-6D9EC7A6/0/0 X-purgate-type: clean X-purgate-size: 815 On 19/10/2026 5:52 pm, Roger Pau Monné wrote: > On Mon, Oct 19, 2026 at 04:59:59PM +0100, Andrew Cooper wrote: >> Between writing MSR_S_CET.SHSTK_EN and establishing SSP using RSTORSSP or >> SETSSBSY, there must not be any CALL or RET instructions. >> >> Building Xen with -fno-early-inlining causes wrmsr() to become out-of-line, >> and thus suffers #DF during boot. >> >> Make the MSR and shstk helpers always_inline. They ought to have been this >> way all along. >> >> Reported-by: Roger Pau Monné >> Signed-off-by: Andrew Cooper > Reviewed-by: Roger Pau Monné > > Originally this was reported by Stefano, so it should likely have his > reported-by tag also. Fine.  I can adjust on commit. Thanks, ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 19 16:54:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 16:54:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454614.1668175 (Exim 4.92) (envelope-from ) id 1xIqdI-0000hn-SZ; Mon, 19 Oct 2026 16:54:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454614.1668175; Mon, 19 Oct 2026 16: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 1xIqdI-0000hg-Pv; Mon, 19 Oct 2026 16:54:44 +0000 Received: by outflank-mailman (input) for mailman id 1454614; Mon, 19 Oct 2026 16:54:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIqdH-0000hT-Eh for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 16:54:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIqdG-00HRaQ-Q2 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 18:54:42 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad64b47-e002-0a2a0a5209dd-0a2a4502deea-8 for ; Mon, 19 Oct 2026 18:54:42 +0200 Received: from [52.101.83.130] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad64b52-6ca4-0a2a45020019-34655382d97b-3 for ; Mon, 19 Oct 2026 18:54:42 +0200 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com (2603:10a6:20b:410::12) by WA4PR03MB982538.eurprd03.prod.outlook.com (2603:10a6:1d0:34::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 16:54:40 +0000 Received: from AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50]) by AM9SPR01MB0028.eurprd03.prod.outlook.com ([fe80::851:da2d:b88a:1b50%6]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 16:54: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=xgqVXVldj3Z5LvPAWAAQnFWAab3wnWB75HTy8+a5kqeWeljXvQxcTmRYQ+nPWZ2ZzWFidTbxbPKq+VjKRfuObFBTe8+pve3NONz8jTl7+4PFsEBBQgXy6gUa9EqJasc9BP9vWv9UXDfADH5v0nKZma839tNP0QENB0WN/xQ29Q5rWJVzTNxQIUZLAnCMpwSgvaJ2CLgxbEUbqFlzZt8KM5KomSynWmkX6ernLvaZ0KXT+oVZMfjWikWyh5xBBD2oorn/MV3oa6qMq4nBcXs19c7KTiH4658wijLv4pEQUVlTXG3erELF/LyAp6nT1sDTL4tK6wjlSPwZ6oqJeiApMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E1QXZm+csZjJpL1tDYRP0Ue67yhh1zn9jsr1tTTJYAA=; b=Ibskdg7hVkgCWkaH2A16fVRy3WjjCo/mZnwTt6nMA0gwtUq7O+i42RaGHhFHCr0775O1/3a9dbBR32lARiBIQIXOwTRCCcJesMb7/libudPo2C0v0oSnWK5SB6VnScLuvSykOT99SsNJvYmKz00S4t4+PC1h8nAJYgeCdG3/WXGW6Ci3CdxeMH1XpwkjV8Wylz6f8STIxlBF/7pr7hqpViT9fHmeukP21KzCGsMfJZF+smKzRWgTpzfygTBuojb3IxrvvBYC51rvgUQTtztU3fn7ZFADNYqkggI6W5FrrEkn+IABsjggiuev9ouwMX4MS/c33nuxQ0aDhNbcGVnkyQ== 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=E1QXZm+csZjJpL1tDYRP0Ue67yhh1zn9jsr1tTTJYAA=; b=fND0P6iLUOeZcQZsypsAd0cP4artyqtR+bBccInUmJ5te9NB9c25VyusEQeQaBPpJgSPcGhpB/heqShFhIJlFQ3n+HYqPkB2MBUrt04ZSNeTmt/xiq8l8zpH4Hc2Zf4mBVXy1pHYj1nI4n4v2fcHAFtLYRWPOyb8x10WZUgmEZdbiqOK9SGMNDMcHZhG8A1MJXj/boWDXkXQd6IIiiMSbd/mMkvSgr50C+0+JcUXCm+zSoGJBXDGrwYGStx/goldxrfKmlC+8VhpR22SYnYz+QKg03yqwxYQa34aSuv9HQ1ICrPm5Uc2W4eaGqOaRXb+etErPwmZ99qEZ3uCJttMEA== From: Dmytro Prokopchuk1 To: "xen-devel@lists.xenproject.org" CC: Dmytro Prokopchuk1 , Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic Thread-Topic: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic Thread-Index: AQHdX+qIyAZynI9P8UKq+juoFEFtXg== Date: Mon, 19 Oct 2026 16:54:40 +0000 Message-ID: Accept-Language: en-US, uk-UA, ru-RU 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: AM9SPR01MB0028:EE_|WA4PR03MB982538:EE_ x-ms-office365-filtering-correlation-id: 4be4aa36-e1c8-44b1-1fa0-08df2e01aab5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|42112799006|23010399003|1800799024|376014|7416014|6133799003|18002099003|10067099003|3023799007|260925021911599003|260925022911599003|260925021311599003|261009221227099003|261009223027099003|11063799006|56012099006|38070700021; x-microsoft-antispam-message-info: 6KnmkQOn7TTZkRRusGKj9w5gQlNUwCufQXCKKOI6dIasx8vVvMXL4pN7wWHgEidtLVIOn5XIyFDjnY9saSFDkDPQeJet4B0LC3ZgxAaqai8rmwGEDMT4RjpXZmNRob7Q8BnGUZPrUr7fGfVekzw+ss59fMd0lhd9oDqQYdIP9Jlc4q5Z2eK+prvxtYNU99eNeIif6GSVV3uOi46zc1+W6+S4PU7I5bRmYwZkRK2EUiHKejqduUHJpo7wiDCKVYdWrS6Iindcjisr2fwlTa+0lmOgCe8yaIEXw9zJ4wlEBa4C/Dj03CsWrlw69fOKGDWHBXh9CPz0BW4Cc/AEVraFerHK+gyy3TcKAENdr0eWzL8+L6bUBMaHqWs2wI0bKgasdqnCYKwt6Q8yO76qow5JFgqB1fl25UVA/PlCVVlDUcvYfvIm91ba5RRCTUannwXRLJXDyEWytmcID0GDIU8C0PqXB0g1Qfb+G1NYmM2a3LRfZZA+g8gSP84pNmhXiwYVSrGIZlTocRWPagV5/DVaMt+FLT+ndsW8r06nbjY9DXK68qWv0IoqoNMHSxYcmz6ePemC6l0TxLRMaXixLjkAczaq43MfnNpAjbIpKYZN8RFShOgGOIiVzMkrcoGO78das+2ydEcDSRV9nYVjTUwpQy9mLisHiEtvB8N4Z2oMv+bZz0zunhXnsfiQWaBJQ7ZldB/BDs1j9P2JfTZZnOpHPD3wj3oznT/Zq3g6bTJ+grA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9SPR01MB0028.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(42112799006)(23010399003)(1800799024)(376014)(7416014)(6133799003)(18002099003)(10067099003)(3023799007)(260925021911599003)(260925022911599003)(260925021311599003)(261009221227099003)(261009223027099003)(11063799006)(56012099006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?lBqwSUk9vRyhJS91rlUEZKuYLh35BN0dGZuYMPNFulaD3NhtNFNn15CeW4?= =?iso-8859-1?Q?cmo9tFEFV37ArFc4e4/jzV7nnNRAtO9HMnsfMluJ5M0I34N1jOf5GakaJo?= =?iso-8859-1?Q?K7gDkq/9R++kkBaVvVrVeloTvysjMix1K7oKERMWHI7sxURzyG4mBONRn6?= =?iso-8859-1?Q?UIBqk2PlR9zQk5d9H3XTtJhQC6ylhRgDYwb1Ybj8MAl+2nEVqtAQeeboUy?= =?iso-8859-1?Q?6RZeMhe9eqhQMhSBKHtkKyqx9ameledAr9e6yt3mN2CxeGikZba2Wm8Vgx?= =?iso-8859-1?Q?+LnnnDqGgyWzV029ZTDsiJpyEXldpvP0zCQ2tS4w72+vyZlHUJszYnJp3s?= =?iso-8859-1?Q?/FKQfPNuEAArKR18xzfi22dVWdjPRgLVxfvWy6LYtPl8hTX40NQbfqPF4g?= =?iso-8859-1?Q?OLnYa3MUzumrwxWkxKppI6CqobJ9Q7ewSLh9EpW/eKs1WJBpPXpeUZcOwM?= =?iso-8859-1?Q?F3yoGx3HVHX5y3VJWDmmbOgAUpyF9hh+oPqOfrcuR27mdkLJz4QA3vgG8E?= =?iso-8859-1?Q?NQiHqK4huK4082MvJGfKSzZwJC0vhjxRUbNnR1WEhm8JR1TycAwAngbHJX?= =?iso-8859-1?Q?W+ITdFQhTwNCYieZlNBFJU6cxoy03BU9IASew4koTYGS4+vVQQOrYJqffO?= =?iso-8859-1?Q?GjJPVLsJG/s/3JoxIxSLuFMaZ54up/ZigbU12aTUzqDG6OxmQ9dY12uxIW?= =?iso-8859-1?Q?polbU8ApANB0Tt6XIfPWlWCPXRWuR6s3eljkFOtMSbAn4iQWNuLoBKNbx8?= =?iso-8859-1?Q?Wvoxx1LbGdZYzeZgpqnmkA47hQXu0g6y6EfxCp1IgXhFXw3bsr+1Kjoyrz?= =?iso-8859-1?Q?wCfLDfd5tyTmGy77ttP2fRAyRJFJatWDY95tqKhLj+0oYUWPI+bLMCpyo2?= =?iso-8859-1?Q?M++Og9Mol6nW7K4cXtYo40CuxJcWc7si+TMM7PJX8scJPavV00HcHRSqjs?= =?iso-8859-1?Q?XTezcnJRtpDxmXfxZN8CR/xrJx68h5bUkAtRPCV3Ey3CVGW5UfyiXfh0qy?= =?iso-8859-1?Q?vwkWK2RxlXT4K1qGgF/vTwyEUcpCpp4VoOrTilHD2RMkHQfyHyskD3D/ki?= =?iso-8859-1?Q?bXGMwbjBV3VFc//6YQASWy60PgPq5WMwhL2QjhvAtmmIlaDSAdG86Oc6M/?= =?iso-8859-1?Q?Q9mfHQXD8sRFbqc9yfANFnyTBrqvBW0iYO2keF6IQhBjPVrlee2KbnhJyF?= =?iso-8859-1?Q?Dlk0CUmiayapRUIo6qxavllGJ2B5piKQSrjo7igyJbRa7OtwRglog6FNVp?= =?iso-8859-1?Q?WjQ7eajVE5euWhJsCC+9e5ZxwKmd2zYxOlEGLlDa1tkeM2yPEnk2go1z6x?= =?iso-8859-1?Q?Z1ZVSJpUpGYvl1nutnFWWCph/xtPMZRPYQBExF7n5WRUilSTWvPshPLQy8?= =?iso-8859-1?Q?DX4/8/BqSP2MleZL8/ckfMH+0+ndDkoLMmVGyuZNBp9UBTYGLffnERtBi3?= =?iso-8859-1?Q?yJcab7JOvUdD6A3UjVQtD9vpdhlFmdu+iI6GghMO6VkK202pNhwusv1mob?= =?iso-8859-1?Q?xIl9fbZC+4NRlHd/vLu92yYDfW9oHjCpJm+APUQTah0CUYlQtbStSMQDMC?= =?iso-8859-1?Q?3+iORiuuU4aDQbefk7L4OkFHpyL31dc9/LmI2Vq4PHynVehh54GEpndMAR?= =?iso-8859-1?Q?m3n21v7L24LnisVZbRJNuyk3vfU0Fm3Id3vFiZZQTgc0VHrC+C2eTbKltE?= =?iso-8859-1?Q?B6mEZU2ewoQpIgk6ZId/pVe0RxBBRxQwuLXMcJRCpCa1Z6sSUDWwdZCUBD?= =?iso-8859-1?Q?xtl5s0MprBLopl1R/Uy4W5/SIS3sEVXLZBmmGAUghTYuDmUxu7K1BPxmQT?= =?iso-8859-1?Q?1mXcH/6SLFtSpY4YVy18S3jTXM1ExHs=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: AM9SPR01MB0028.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4be4aa36-e1c8-44b1-1fa0-08df2e01aab5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2026 16:54:40.3301 (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: hQyiYKYFn8mPQC9e2d4aSeIRXRp1j8pZlmktR7iNSf9QMTdm76J6PjlxGwTvhlJGtKKgqi4rei9cf87jmabioOOlR95Eq9Ci9U7e3Zn0N7M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: WA4PR03MB982538 X-purgate-ID: tlsNG-720697/1792428882-319CB2AC-8AFA6550/0/0 X-purgate-type: clean X-purgate-size: 3666 MISRA C Rule 10.1 states: "Operands shall not be of an inappropriate essential type". The result of relational, equality and logical negation operators has type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5), so using it as an operand of +, -, * and their assignment forms has well-defined semantics. Update ECLAIR configuration to tag such uses as safe. Update deviations.rst and rules.rst accordingly. Signed-off-by: Dmytro Prokopchuk --- Current patch resolves all ARM Rule 10.1 violations (actually, there were o= nly two), and resolves around 55 x86 violations. Test CI pipeline: https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2963748389 --- automation/eclair_analysis/ECLAIR/deviations.ecl | 5 +++++ docs/misra/deviations.rst | 6 ++++++ docs/misra/rules.rst | 2 ++ 3 files changed, 13 insertions(+) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/= eclair_analysis/ECLAIR/deviations.ecl index 6cdb10a129..8bfb1a0f89 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -335,6 +335,11 @@ still non-negative." -config=3DMC3A2.R10.1,etypes+=3D{safe, "stmt(operator(logical)||node(condi= tional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"= } -doc_end =20 +-doc_begin=3D"The result of relational, equality and logical negation oper= ators has type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5), +so using it as an operand of an arithmetic operator is well defined and we= ll known to all Xen developers." +-config=3DMC3A2.R10.1,etypes+=3D{safe, "stmt(operator(add||sub||mul||add_a= ssign||sub_assign))", "src_type(ebool||boolean)"} +-doc_end + -doc_begin=3D"The macro ISOLATE_LSB encapsulates a well-known pattern to o= btain a mask where only the lowest bit set in the argument is set, if any, for u= nsigned integers arguments on two's complement architectures diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 6bcc2adf95..5aeb3ef9a3 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -347,6 +347,12 @@ Deviations related to MISRA C:2012 Rules: well-known to all Xen developers to be a comparison with 0. - Tagged as `safe` for ECLAIR. =20 + * - R10.1 + - The result of relational, equality and logical negation operators h= as + type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5), so usi= ng + it as an operand of an arithmetic operator has well-defined semanti= cs. + - Tagged as `safe` for ECLAIR. + * - R10.1 - Xen only supports architectures where signed integers are represent= end using two's complement and all the Xen developers are aware of this= . For diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index a59cf1782e..54b1cefba1 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -387,6 +387,8 @@ maintainers if you want to suggest a change. compilers' extensions) - Implicit conversions to boolean for conditionals (?: if while for) and logical operators (! || &&) + - Results of relational, equality and logical negation operators + (0 or 1) used as operands of arithmetic operators (+ - *) - The essential type model allows the constants defined by anonym= ous enums (e.g., enum { A, B, C }) to be used as operands to arithm= etic operators, as they have a signed essential type. --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 18:58:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 18:58:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454689.1668185 (Exim 4.92) (envelope-from ) id 1xIsZ1-0002tC-IZ; Mon, 19 Oct 2026 18:58:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454689.1668185; Mon, 19 Oct 2026 18:58: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 1xIsZ1-0002t5-FB; Mon, 19 Oct 2026 18:58:27 +0000 Received: by outflank-mailman (input) for mailman id 1454689; Mon, 19 Oct 2026 18:58:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIsZ0-0002sz-I1 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 18:58:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xIsZ0-000000021lY-2Jt9; Mon, 19 Oct 2026 18:58: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.98.2) (envelope-from ) id 1xIsZ0-0000000H1LX-0rno; Mon, 19 Oct 2026 18:58: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=2V75F28umQ7nU9A5a7X/2ueN6/PybeYSHghsuaipgis=; b=t8h55R7lMF/uYsBKS3sbbYTWBN TubWUuq8ykI/kdwHfWYh/KE26DwH7FFg9z+Fltji25t7zolpESL+zSdd/qkNEGgKWRW5ru4TGUIUg HBY8uivJR9CDvljx0GNJiJqZRmPnFISQDkH+DpG/d7zNt9XTpwfgx81GqwcRw0HvWiCs=; Date: Mon, 19 Oct 2026 20:58:19 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks Message-ID: References: <20261019155959.883789-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: <20261019155959.883789-1-andrew.cooper3@citrix.com> On Mon, Oct 19, 2026 at 04:59:59PM +0100, Andrew Cooper wrote: > Between writing MSR_S_CET.SHSTK_EN and establishing SSP using RSTORSSP or > SETSSBSY, there must not be any CALL or RET instructions. > > Building Xen with -fno-early-inlining causes wrmsr() to become out-of-line, > and thus suffers #DF during boot. > > Make the MSR and shstk helpers always_inline. They ought to have been this > way all along. > > Reported-by: Roger Pau Monné > Signed-off-by: Andrew Cooper Sorry seems like I'm a bit slow today. Also worth adding: Fixes: b60ab42db2f0 ("x86/shstk: Activate Supervisor Shadow Stacks"). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:17:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:17:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454701.1668194 (Exim 4.92) (envelope-from ) id 1xIsrD-00065J-0K; Mon, 19 Oct 2026 19:17:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454701.1668194; Mon, 19 Oct 2026 19: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 1xIsrC-00065C-Sv; Mon, 19 Oct 2026 19:17:14 +0000 Received: by outflank-mailman (input) for mailman id 1454701; Mon, 19 Oct 2026 19:17:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIsrB-000656-Ju for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:17:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIsrA-00089n-Pn for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:17:12 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66cb8-2eae-0a2a0a5409dd-0a2a450aa29e-0 for ; Mon, 19 Oct 2026 21:17:12 +0200 Received: from [40.93.201.4] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66cb6-f2d2-0a2a450a0019-285dc904645b-3 for ; Mon, 19 Oct 2026 21:17:11 +0200 Received: from BLAPR05CA0032.namprd05.prod.outlook.com (2603:10b6:208:335::13) by CH3PR12MB8186.namprd12.prod.outlook.com (2603:10b6:610:129::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 19:17:08 +0000 Received: from BN3PEPF00022BCC.namprd03.prod.outlook.com (2603:10b6:208:335:cafe::8b) by BLAPR05CA0032.outlook.office365.com (2603:10b6:208:335::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.19 via Frontend Transport; Mon, 19 Oct 2026 19:17:06 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF00022BCC.mail.protection.outlook.com (10.167.248.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 19 Oct 2026 19:17:05 +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.53; Mon, 19 Oct 2026 14:17:05 -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.53 via Frontend Transport; Mon, 19 Oct 2026 14:17:04 -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=hUR9irI1UYeyGkeMqxb/TqXFoAGENbefmdiNNnN81uOvz10Xyr+L7dVZsKh7th4/e2l1NKZXC3nTxK6XNmm0EnoyWiOlsxAE/CKWDzolaNw+AYlnHfTEZekr/JedPPobDsDk+VLCC9Q7TIy/2LZ7MAoOziJNRVFbXYFsdWuAai4ypAc6piIOBaNr0d+5ciFnXSQBumIkJIaNKW1def+JpURCslkwx1WVToYp5OqFZIQKOaHvpNAs32/+ukA/i6hEgjXgBtJ4On6jN5LYssDRExktzM9jUoLbu21fx/3U0hN83p6QktEhvmrMXfHTfKtL05uPT48NkYer8wfFMb71QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t+mth8fN4z1ivw40SWovHkzbmoxRaAYcPK+5jBE0+2Q=; b=JaxxmZRkl2flXOE3WwHWzBzDZoujbqs4pqDL24pn42646z8NCEzFWJudaLzqQvxEXM3aG4wMIptyC/fbSt691R/E83jv2M4fjvxSpQYRykWBk5COkTMpPff4PnXQXy+aawdIndLfx+yiioimGV2qwj/FAnTVEbhYfb5ahwRbpaWnfKjXdcISE9Cs0pEoMvMnTChIkDTfFwcBVdWg20PDVQyexw9oShsSMpQMVYW3qMw25i2az3tS7LUtzYz5ExsfmzKj1pMTeN93wKO7VjvcLQWSJi+xDArMUDtdW6CDdBOJOlB0FbOYgZlYVH23EZb9sSJ5W/6cJUZMsbuegV0zjg== 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=t+mth8fN4z1ivw40SWovHkzbmoxRaAYcPK+5jBE0+2Q=; b=zkWPOyYVBYLdhP9i/eaqBl0Cn1oBX17992KBdVjf2zdineTQQazd7wJzrgcSTDwhceo/RSr84R7F6BEuKnnWQRPVDldp7QJu5ZuRM3DDYZBZ55Wq3AAbyDLDLsf+ZbKpUd+3u+cmp3+vFO4eheCJ0dCWanIFNnLoMWjO1wKlIVI= 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: <62f101ef-7f47-4593-a79e-06abbc18f84c@amd.com> Date: Mon, 19 Oct 2026 15:09:02 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/5] vpci: Export functions required for SR-IOV support To: Mykyta Poturai , "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <5b2721b7213d53232ce912e4f9ce0b4e7b1b39c7.1792072426.git.mykyta_poturai@epam.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <5b2721b7213d53232ce912e4f9ce0b4e7b1b39c7.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BCC:EE_|CH3PR12MB8186:EE_ X-MS-Office365-Filtering-Correlation-Id: a9cd8c8e-ac97-4fb1-fcd1-08df2e15902f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|23010399003|36860700016|4143699003|11063799006|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: lWIIDnmyx+6/Ltu9nA6RviIQz4zKJEdEOyM0pyOaw/aEYFNDxpBDEsuGHuyWs8KEF7dsy9zesgwj+uCNVV3BzzApSU6XL3eHUTOCsqqc2CrrN2ZkU+ZIgoyf7hRG931m+toSHZvd3GWLfWfn315RrWOAZE+LRT0KjwGzBS0lZG3uExm/sFwx8jxbyUSqh25aok/PwycoP9hwvj3IcFeksNt/zHwBnkD3bv2T5l1lqW5XDOZa6oJqVY8wRvVlDticzRbvpPjSmzkz3gnjjq7Ci3ORvUnnUXy5rCbuXgj0t50pxTB3zCLGz7rPm7P/XQkf0J332KFAzYLe7N3qVTCFef7PZ0qzDBjhkNHyi6BNjeO0aPgcI1A9cGFi8XJVZZXS8yfstz0pEWntIJE/1aoEwXXBcm5Uf74c1eyxj/7p/WLtF0ej/hlHR0Pz24P+Ia4ZZBENAKsK/lIL7WLXZkTyIRaTrePDHA0MG5eHB90qgBRGWucdeTYw4rXKvrXFn3kvTCK3P72FXNI3kUABC7IPFrDg0Pw6fJ+sgjN8NsGGyPlr98GEwHHhFzR5bgj9FLIuezRvs1RzZVcE3v4VCeIKuzA0WVidCGcUkmbveP2BhWIbSH286zDHmjVHmF2BlmuKVCtDFqzb06xALxTmdLZPwtg6H+lOx+cfiMKDZDUDDclbCKsly1BseTbUfkaUHrRgNUo6jWVv5poeAgZiKMG2nQ== 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)(1800799024)(82310400026)(23010399003)(36860700016)(4143699003)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: HljmdO2iwOKwO8GauWBaAd8sccfWeWfBJa1NHl+lC1Rg2XiL9YoWzNzvBoYC+XYoI6ggdXY0cVGWioV4kc3h6fMhPDSxJGgTAsUGg6xHqOVUtZDqa4YUMZLEpBSkQ/ykTSEA8ix/GZcp17ZUYZQOm0N6DHlEbEDonRIQDr8KO2vH1YkkXo3IV54u/bRox/9w80qNLVihpdXlubtHhGURoxjrb4e0JGIrzE3oIFPSuEXh9XjCPKueF69XTMdXc9MnH6rrivu5o2i7STFjPi3pCPS/dhHZd7Axn7Zi1fQzLtxldzgua64STdzhAjHLQCdf6NSCfwggNUjH1qLUx/DHHbTxRlueqgrKpamCh6W3wttuTvIA2eh/Aa9eRCcipm/snP6Tt08k71Rjm0Z8U7sPC4/47iX4Be5jYeenDBQzfmh7LlKKDXfcfzIWCGe6hmsN X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 19:17:05.7749 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a9cd8c8e-ac97-4fb1-fcd1-08df2e15902f 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: BN3PEPF00022BCC.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8186 X-purgate-ID: tlsNG-4011c0/1792437432-51CC3CFC-20597508/0/0 X-purgate-type: clean X-purgate-size: 410 On 2026-10-15 10:08, Mykyta Poturai wrote: > From: Stewart Hildebrand > > Rename and export vpci_modify_bars, vpci_guest_mem_bar_{read,write} > > Signed-off-by: Stewart Hildebrand > Signed-off-by: Mykyta Poturai > Reviewed-by: Teddy Astie Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:17:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:17:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454704.1668201 (Exim 4.92) (envelope-from ) id 1xIsrc-0006QG-66; Mon, 19 Oct 2026 19:17:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454704.1668201; Mon, 19 Oct 2026 19:17: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 1xIsrc-0006Q9-3O; Mon, 19 Oct 2026 19:17:40 +0000 Received: by outflank-mailman (input) for mailman id 1454704; Mon, 19 Oct 2026 19:17:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIsrZ-0006PO-QL for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:17:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIsrZ-0008G0-7U for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:17:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66cc6-2eae-0a2a0a5409dd-0a2a4501b96c-4 for ; Mon, 19 Oct 2026 21:17:36 +0200 Received: from [40.93.196.10] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66ccf-5984-0a2a45010019-285dc40a99da-3 for ; Mon, 19 Oct 2026 21:17:36 +0200 Received: from DS7PR05CA0069.namprd05.prod.outlook.com (2603:10b6:8:57::21) by IA1PR12MB6460.namprd12.prod.outlook.com (2603:10b6:208:3a8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 19:17:28 +0000 Received: from DM3PEPF000265C1.namprd03.prod.outlook.com (2603:10b6:8:57:cafe::63) by DS7PR05CA0069.outlook.office365.com (2603:10b6:8:57::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.18 via Frontend Transport; Mon, 19 Oct 2026 19:17:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DM3PEPF000265C1.mail.protection.outlook.com (10.167.23.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 19 Oct 2026 19:17:28 +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.53; Mon, 19 Oct 2026 14:17:30 -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.53; Mon, 19 Oct 2026 14:17:27 -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.53 via Frontend Transport; Mon, 19 Oct 2026 14:17:27 -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=U5bk+YZ/AOmTuhLDUUqQ4XUsIJwor90tueWqQ+rA5Rws92K3y4NfhixH9wMUFu3peQS/DTrIl/OpYqACzrD/GAJb33kkD6JQ2isya4Bt5zIwwWK5RFgEySI7sE4Xn7pH1qqZCSYQeYUuyin34IHBI8cBEYgqLJaZPpOklh6SKEWezuVEJDuXHm2yKBgLs0MsEpIE11WGB/UXSHO+M8QF7XtGEQfFxgVLzkgvp4g/L7n+eP1tmmz88VaDBwAOTRDOepF7fImpssMb5zMj8H40y7swoUzbPYlEzmMaHaIXB9WMspjqWVW4hKwiaL6P+0jM9GrtA49Fgqr/4bh7FHplcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CCAkuRImuKtUiIUpukaEwCtuKwnf8f/9h60I7T0owRM=; b=kFS2QE5lzzP1rvPqZNhtf8FCGzcJPC4EUGnEi/WzTBbobG+vP3mfY/WU5Vwe/0sUc79gTxeKWCItDddfgDGmImYl6LnyKJFVx5Nddj2mrsCqBSkDxlQvCwYieFYRC/xbuP77q8d+FbhPosrVvLgWq7Cp/LC89LSv6vI5J/URLVSO2BisXijusZauFFR2QyNUrr+oY3//4onzWEG24W4AIMGFIJHPDLG40QyGXuhGzAlfiu7Z5L+9Cf+ZxqUJobrZ+CKU/9ZkQG3P4Y0HsVKfIk5Qoiu8vamc+9Ziy+ovwOdtgsprqyyxBPT05XB0dZDBCovhTmUjRsodD001qMPWAw== 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=CCAkuRImuKtUiIUpukaEwCtuKwnf8f/9h60I7T0owRM=; b=PYs0v+YTCEmrSZ05RpOvRUIGdzPVKuts1G2JY7sU/TV6ANzNLqsZz4+rm3ROAujDyJD8yew8S7DEF5C4CjXRfkCUZ33LLU3B5z1b2JVNVGjh2g5JK6bkgOcUuxNM7vwJjg0gUrWp3m0qqtfxHH0ZM0cLN46ApZsI/GXFJoELXBo= 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, 19 Oct 2026 15:09:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/5] vpci: use a local variable for the BAR rangeset To: Mykyta Poturai , "xen-devel@lists.xenproject.org" CC: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Stewart Hildebrand" References: <4bce74f6f5d2fc7b58c62acfd377956a9fee8651.1792072426.git.mykyta_poturai@epam.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <4bce74f6f5d2fc7b58c62acfd377956a9fee8651.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM3PEPF000265C1:EE_|IA1PR12MB6460:EE_ X-MS-Office365-Filtering-Correlation-Id: 74a89b2e-67dc-4e39-ab41-08df2e159dbb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|23010399003|36860700016|4143699003|11063799006|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: a0/OIuGq7bEf3FlyO5tvKqg5shuNR2HBxgfFIm/OLdBA4GG5FN0kyM+8wyiuUVXyrwEykMs72D7QzRjAnonszz5owyii8oCCw7G+cLIduixITUjPuzKNOjPuOoN5LQVUVGHjTby84EBtXD10/enh5tUq4ajPS8OuzgAgvM1KmHauVPldF9ibbk64dGgN3YfQcA7ndNFLxXewB7ri/uTZRzNF2iLmkpEcSxnlkN3MXp1pAJ2Wl6ZpxgiCO15+MQ/aB/ZrGo4en9rthXzVK3CYD3sPNeGajkTVe7PKFRY7gn+Vrs9cra5Ma45vamUHcLI+NFiut4aitfz4VdSNwfz+padg+kmvDFKJzWTIifceYBQhNOfJCsdxPiwRfNeuhW7YIWK2/FDqGUfeaOzj/w+NxvBR52AxcuRADIsKhPnPks0s5YsQEJ9Y0Sk1T5N95KJbErGe5+OmPC49ufo0/UFn9IjVjtbA6DPFlM1oFlSPHuemmbHWacFSgWGxKfL3+NxBfnT6WIs43I1eJcqiQvLpUsIFZIeD/eUKn/6PV+7C4sXVGhDhbNt1uJpZ6XGIC9lt5w+cYDWVvF02/D3ROkiHqqYBONjo76IH3WXT6sE/XoMp466qfb5ndIKK9590mPHW0Tct7UpkOPiziL5R7YePuoa0xorC7CvYxQlxFU86ywnLgqhvl5pFwvHRuv5+Xx+embrx+4FVUXJa/QVNDFePQg== 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)(23010399003)(36860700016)(4143699003)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: U9mEnPOIWwYU+0uC43BKbuRrWGPnGfkzxxFsEzpVbT+KMBDUY0TjGCsH8AXmCL6XezrGQVYg3oS8auJP2G14PwDSSp0TO+fNkoYn0cuMMVwARhnfEujw9ArveN/Iznbd0fY+oh09E4qRn5tK8GzgbSEbkbQG8TJeYWmiWBEc/+tcVBc5w5OHc425yi/b2pfJG01kAqU0q9T08eq2mx/yeXs1WHXd6OQFdXvd8E1bgEq4y7E/V8Z3DZPZ/UD1tS93yJgQKIvX3ptQz7VdX4+dJFzRvbgRTe0NgmQ5grjyA2Ocr2exANN+Re1vnTznLvL/0McRJW5cYxd0PjgibAroy+KAGWQOsaiQw9gWZiRW1M2097i9wIKAtwhmMsHtrMHMvEQIND9FcJJmNDyvOGnIeYiZllJwHhpcf4nWYNKxA9l1R1eJzC79uaNoHMi/ZefE X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 19:17:28.4664 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 74a89b2e-67dc-4e39-ab41-08df2e159dbb 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: DM3PEPF000265C1.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6460 X-purgate-ID: tlsNG-d62444/1792437456-1D272757-3546B433/0/0 X-purgate-type: clean X-purgate-size: 1424 On 2026-10-15 10:08, Mykyta Poturai wrote: > From: Mykyta Poturai > > In the BAR (un)mapping paths latch the rangeset of the BAR being > processed into a local variable, instead of dereferencing struct > vpci_bar on every use. Preparatory work for moving the rangesets out > of struct vpci_bar. > > No functional change. > > Signed-off-by: Mykyta Poturai > Signed-off-by: Stewart Hildebrand I guess you need a second S-o-B after Stewart's since you are submitting? Unless... > --- > v3->v4: > * new patch, split out of "vpci: Use pervcpu ranges for BAR mapping" so > that the non-functional churn is separate from the functional change ... it is something totally created by you. Then you can drop Stewart - I think. > @@ -218,8 +219,7 @@ bool vpci_process_pending(struct vcpu *v) > { > spin_lock(&pdev->vpci->lock); > /* Disable memory decoding unconditionally on failure. */ > - modify_decoding(pdev, v->vpci.cmd & ~PCI_COMMAND_MEMORY, > - false); > + modify_decoding(pdev, v->vpci.cmd & ~PCI_COMMAND_MEMORY, false); This seems like an unrelated change. I think you should drop it and incorporate into the next patch touching this line. With that: Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:22:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:22:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454714.1668210 (Exim 4.92) (envelope-from ) id 1xIswP-0008FM-PW; Mon, 19 Oct 2026 19:22:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454714.1668210; Mon, 19 Oct 2026 19: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 1xIswP-0008FF-Mv; Mon, 19 Oct 2026 19:22:37 +0000 Received: by outflank-mailman (input) for mailman id 1454714; Mon, 19 Oct 2026 19:22:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIswP-0008F8-13 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:22:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIswO-00FObN-7L for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:22:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66dfb-e002-0a2a0a5209dd-0a2a4505a560-0 for ; Mon, 19 Oct 2026 21:22:35 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66dfa-4cb1-0a2a45050019-4a68bc0476a4-3 for ; Mon, 19 Oct 2026 21:22:35 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69JJMEkF053145 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Oct 2026 15:22:19 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69JJME2C053144; Mon, 19 Oct 2026 12:22:14 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , "Roger Pau Monné" , Stefano Stabellini Date: Mon, 19 Oct 2026 12:02:14 -0700 Subject: [RFC PATCH 0/5] Fun with git X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-c201ff/1792437755-720AA2A1-4ED1896E/0/0 X-purgate-type: clean X-purgate-size: 3659 I ended up looking at the use of git in the build system. There is some inconsistency in use/behavior and I really dislike how certain pieces of it have evolved. Most of what I'm sending is RFC since I've got too many questions, but the first two are appropriate right now. I find it unsurprising the script predates Xen's conversion to git. Likely the script made it rather more obvious git was winning, then it finally came time to officially convert Xen to using git. Of the four uses of the `git-checkout.sh` script 1 gives a full path and 3 give only the subdirectory. I'm unsure which is appropriate, but inconsistency is a Bad Thing(tm). What is with the naming of the subproject repository directories? Why the "-dir" for "qemu-xen-dir", "ovmf-dir" and "seabios-dir"? Whereas for mini-os it is "extras/mini-os". I imagine there was some good reason at some point, but now it simply seems odd. Then there is the issue of all the duplicated project subdirectory variants. If the `git-checkout.sh` script is used it creates -remote, than a symbolic link -> -remote. Then for most (all?) of these the directory -build is created where the actual build is done. Then there are the problems with factors related to the existence of the script and the way it works. One problem with the script is is breaks cleaning the repository. "Hmm, `git status --ignored` still shows directories, okay let me `rm -rf tools/firmware/*-dir tools/qemu-xen-dir extras/mini-os`" Then the next build you end up redownloading those repositories from scratch. Perhaps the Xen Project's git server can handle the load, but it certainly adds some. Then there is a major slowdown in the build process. Clone the git repository, then move to your fast build machine with lots of processors. Suddenly you're waiting on your Internet link. Then it gets worse if that is the moment when the git server is down. Just to make it worse this also functions as a tracker for finding people building Xen. Yet another issue is, is it still possible to build Xen 4.0? Nominally most/all of the repository histories reach back that far, but you'll have no idea which versions were in use. The combination of outside repository versions needed for a given Xen version build might be quite hard to figure out in the future. I'm including some patches I created while looking into this situation. I think the first is worthwhile no matter what choices are made. The rest are simply resolving issues I found. The last is a proposed adjustment to the script. The script adjustment is unfinished, it is somehow breaking Qemu's build process. It also only successfully addresses the issue of needing to redownload full repositories. A better option might be using `git subtree`. This would address all my concerns in regards to the handling of external project repositories. Does seem a largish step though. Elliott Mitchell (5): make: add use of $(realpath ) in top and main Rules.mk files Config.mk: record hash of SeaBIOS tag scripts/git-checkout.sh: add standard scripting safety steps tools/build: use full path when checking out git repositories scripts/git-checkout.sh: store repositories with Xen, use worktrees Config.mk | 3 ++- Makefile | 12 +++++++---- scripts/git-checkout.sh | 44 ++++++++++++++++++++++++----------------- tools/Makefile | 12 ++++------- tools/Rules.mk | 2 ++ tools/firmware/Makefile | 14 ++++++------- 6 files changed, 48 insertions(+), 39 deletions(-) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:23:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:23:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454719.1668219 (Exim 4.92) (envelope-from ) id 1xIsx9-0000Ig-0t; Mon, 19 Oct 2026 19:23:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454719.1668219; Mon, 19 Oct 2026 19: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 1xIsx8-0000IJ-UT; Mon, 19 Oct 2026 19:23:22 +0000 Received: by outflank-mailman (input) for mailman id 1454719; Mon, 19 Oct 2026 19:23:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIsx8-0000I6-9U for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:23:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIsx7-00FKHE-Md for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:23:21 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66e27-2eae-0a2a0a5409dd-0a2a4507a7cc-2 for ; Mon, 19 Oct 2026 21:23:21 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66e28-b4ea-0a2a45070019-4a68bc04724d-3 for ; Mon, 19 Oct 2026 21:23:21 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69JJN6nc053166 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Oct 2026 15:23:11 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69JJN65n053165; Mon, 19 Oct 2026 12:23:06 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <0b38e7ba64831575c2f2533c69e00da79c4bc958.1792436534.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , "Roger Pau Monné" , Stefano Stabellini Date: Mon, 19 Oct 2026 12:02:14 -0700 Subject: [PATCH 1/5] make: add use of $(realpath ) in top and main Rules.mk files X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-ef75cf/1792437801-36AD8AE4-721AD8BA/0/0 X-purgate-type: clean X-purgate-size: 1027 Date: Sat, 17 Oct 2026 12:25:36 -0700 Without this "/.." tend to accumulate in $(XEN_ROOT) and eventually things start breaking. Address this before something subtlely breaks. Signed-off-by: Elliott Mitchell --- Makefile | 2 +- tools/Rules.mk | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ea432e21b02..f063ce56819 100644 --- a/Makefile +++ b/Makefile @@ -15,7 +15,7 @@ TARGS_BUILD=$(patsubst %, build-%, $(SUBSYSTEMS)) TARGS_CLEAN=$(patsubst %, clean-%, $(SUBSYSTEMS)) TARGS_DISTCLEAN=$(patsubst %, distclean-%, $(SUBSYSTEMS)) -export XEN_ROOT=$(CURDIR) +export XEN_ROOT:=$(realpath $(CURDIR)) include Config.mk .PHONY: mini-os-dir diff --git a/tools/Rules.mk b/tools/Rules.mk index d9b9c740e96..97fb3e9bc09 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -1,5 +1,7 @@ # -*- mode: Makefile; -*- +override XEN_ROOT:=$(realpath $(XEN_ROOT)) + # `all' is the default target all: -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:24:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:24:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454727.1668230 (Exim 4.92) (envelope-from ) id 1xIsxy-0000rM-Dd; Mon, 19 Oct 2026 19:24:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454727.1668230; Mon, 19 Oct 2026 19:24: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 1xIsxy-0000rF-96; Mon, 19 Oct 2026 19:24:14 +0000 Received: by outflank-mailman (input) for mailman id 1454727; Mon, 19 Oct 2026 19:24:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIsxw-0000r5-U5 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:24:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIsxw-00096B-B6 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:24:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66e3f-8faa-0a2a0a5109dd-0a2a4503e16e-36 for ; Mon, 19 Oct 2026 21:24:12 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66e5b-fae8-0a2a45030019-4a68bc04fda8-3 for ; Mon, 19 Oct 2026 21:24:12 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69JJNwjH053176 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Oct 2026 15:24:03 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69JJNwfx053175; Mon, 19 Oct 2026 12:23:58 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <9771fce7e080b2d64fd9535b6e38d70781eb2de3.1792436534.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , "Roger Pau Monné" , Stefano Stabellini Date: Mon, 19 Oct 2026 12:02:14 -0700 Subject: [PATCH 2/5] Config.mk: record hash of SeaBIOS tag X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-33051d/1792437852-758824E9-9CF16FA6/0/0 X-purgate-type: clean X-purgate-size: 969 Date: Sun, 18 Oct 2026 14:12:43 -0700 Recording the tag as a comment, but directing git at the hash allows bypassing downloading tags (git does not selectively download tags). While remote branches get prefixed with the remote name. The result is identical, the tag is simply a reference to the hash. Signed-off-by: Elliott Mitchell --- Config.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Config.mk b/Config.mk index b2dcc729f3d..db7d0299624 100644 --- a/Config.mk +++ b/Config.mk @@ -220,7 +220,8 @@ MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git MINIOS_UPSTREAM_REVISION ?= 26ceb2daf95dd9e7fed9c83d36be3aaf1a0fa8a1 SEABIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/seabios.git -SEABIOS_UPSTREAM_REVISION ?= rel-1.17.0 +# rel-1.17.0 +SEABIOS_UPSTREAM_REVISION ?= b52ca86e094d19b58e2304417787e96b940e39c6 ETHERBOOT_NICS ?= rtl8139 8086100e -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:25:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:25:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454731.1668238 (Exim 4.92) (envelope-from ) id 1xIsyo-0001Kr-Kn; Mon, 19 Oct 2026 19:25:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454731.1668238; Mon, 19 Oct 2026 19:25: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 1xIsyo-0001Ki-Hl; Mon, 19 Oct 2026 19:25:06 +0000 Received: by outflank-mailman (input) for mailman id 1454731; Mon, 19 Oct 2026 19:25:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIsym-0001KX-Te for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:25:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIsym-002UQ4-A2 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:25:04 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66e3d-e002-0a2a0a5209dd-0a2a450b8f5a-46 for ; Mon, 19 Oct 2026 21:25:04 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66e8e-b7e8-0a2a450b0019-4a68bc0440e6-3 for ; Mon, 19 Oct 2026 21:25:04 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69JJOo8x053186 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Oct 2026 15:24:55 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69JJOoMh053185; Mon, 19 Oct 2026 12:24:50 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <87285fe79868156edabf49fa5e8398a8a8f3494d.1792436534.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , "Roger Pau Monné" , Stefano Stabellini Date: Mon, 19 Oct 2026 12:02:14 -0700 Subject: [RFC PATCH 3/5] scripts/git-checkout.sh: add standard scripting safety steps X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-42698a/1792437904-A9EC69EA-260986E5/0/0 X-purgate-type: clean X-purgate-size: 1873 Date: Fri, 16 Oct 2026 19:11:11 -0700 Add doublequotes to all variable references. This ensures building doesn't fail if the full build directory has spaces in it. Also move the `set -e` to the front of the script. Add a default value for $GIT. Rename $TREE to $REPO. These are generally called "repositories", the checked out directory is a tree. Signed-off-by: Elliott Mitchell --- scripts/git-checkout.sh | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh index 56a60193a73..7dde6702b6c 100755 --- a/scripts/git-checkout.sh +++ b/scripts/git-checkout.sh @@ -1,28 +1,30 @@ #!/bin/sh +set -e + if test $# -lt 3; then - echo "Usage: $0 " + echo "Usage: $0 " exit 1 fi -TREE=$1 -COMMITTISH=$2 -DIR=$3 +GIT="${GIT:-git}" -set -e +REPO="$1" +COMMITTISH="$2" +DIR="$3" -if test \! -d $DIR-remote; then - rm -rf $DIR-remote $DIR-remote.tmp - mkdir -p $DIR-remote.tmp; rmdir $DIR-remote.tmp - $GIT clone $TREE $DIR-remote.tmp +if test \! -d "$DIR-remote"; then + rm -rf "$DIR-remote" "$DIR-remote.tmp" + mkdir -p "$DIR-remote.tmp"; rmdir "$DIR-remote.tmp" + "$GIT" clone "$REPO" "$DIR-remote.tmp" if test "$COMMITTISH" ; then - cd $DIR-remote.tmp - $GIT fetch origin "$COMMITTISH" - $GIT branch -D dummy >/dev/null 2>&1 ||: - $GIT checkout -b dummy FETCH_HEAD + cd "$DIR-remote.tmp" + "$GIT" fetch origin "$COMMITTISH" + "$GIT" branch -D dummy >/dev/null 2>&1 ||: + "$GIT" checkout -b dummy FETCH_HEAD cd - fi - mv $DIR-remote.tmp $DIR-remote + mv "$DIR-remote.tmp" "$DIR-remote" fi -rm -f $DIR -ln -sf $(basename $DIR-remote) $DIR +rm -f "$DIR" +ln -sf $(basename "$DIR-remote") "$DIR" -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:25:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:25:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454740.1668248 (Exim 4.92) (envelope-from ) id 1xIszY-0001ou-TG; Mon, 19 Oct 2026 19:25:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454740.1668248; Mon, 19 Oct 2026 19:25: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 1xIszY-0001on-P6; Mon, 19 Oct 2026 19:25:52 +0000 Received: by outflank-mailman (input) for mailman id 1454740; Mon, 19 Oct 2026 19:25:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIszW-0001o3-Nh for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:25:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIszV-004F9Y-Ab for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:25:49 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66eb9-2eae-0a2a0a5409dd-0a2a450cd96a-2 for ; Mon, 19 Oct 2026 21:25:49 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66ebc-f479-0a2a450c0019-4a68bc048040-3 for ; Mon, 19 Oct 2026 21:25:49 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69JJPf8f053198 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Oct 2026 15:25:47 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69JJPf8Z053197; Mon, 19 Oct 2026 12:25:41 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <3ad9849a938fcb8bc08e50216501d4c4e226ab5f.1792436534.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Anthony PERARD Date: Mon, 19 Oct 2026 12:02:14 -0700 Subject: [RFC PATCH 4/5] tools/build: use full path when checking out git repositories X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-d25034/1792437949-774D7A5B-8E0183C8/0/0 X-purgate-type: clean X-purgate-size: 1821 Date: Fri, 16 Oct 2026 18:23:28 -0700 This makes the invocations of the git-checkout script consistent. This makes it easier to understand what is actually occurring. Signed-off-by: Elliott Mitchell --- tools/Makefile | 2 +- tools/firmware/Makefile | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 6ecf7c0da82..46847fca998 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -135,7 +135,7 @@ qemu-xen-dir-find: mkdir -p qemu-xen-dir; \ else \ export GIT=$(GIT); \ - $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_LOC) $(QEMU_UPSTREAM_REVISION) qemu-xen-dir ; \ + $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_LOC) $(QEMU_UPSTREAM_REVISION) $(XEN_ROOT)/tools/qemu-xen-dir ; \ fi .PHONY: qemu-xen-dir-force-update diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile index d69f7c69eac..a14e7cadd05 100644 --- a/tools/firmware/Makefile +++ b/tools/firmware/Makefile @@ -20,11 +20,11 @@ SEABIOSLD ?= $(LD) SEABIOS_EXTRAVERSION ?= "-Xen" ovmf-dir: - GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) ovmf-dir + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/ovmf-dir cp ovmf-makefile ovmf-dir/Makefile; seabios-dir: - GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_REVISION) seabios-dir + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/seabios-dir cp seabios-config seabios-dir/.config; $(MAKE) -C seabios-dir olddefconfig CC=$(SEABIOSCC) LD=$(SEABIOSLD) rm -f seabios-dir/.version -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:26:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:26:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454745.1668256 (Exim 4.92) (envelope-from ) id 1xIt0T-0002I1-4d; Mon, 19 Oct 2026 19:26:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454745.1668256; Mon, 19 Oct 2026 19: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 1xIt0T-0002Hu-1M; Mon, 19 Oct 2026 19:26:49 +0000 Received: by outflank-mailman (input) for mailman id 1454745; Mon, 19 Oct 2026 19:26:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIt0R-0002Hk-VV for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:26:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIt0R-002KND-8f for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:26:47 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad66ee8-2eae-0a2a0a5409dd-0a2a450cd37c-18 for ; Mon, 19 Oct 2026 21:26:47 +0200 Received: from [74.104.188.4] (helo=mailhost.m5p.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad66ef5-f479-0a2a450c0019-4a68bc043034-3 for ; Mon, 19 Oct 2026 21:26:47 +0200 Received: from m5p.com (mailhost.m5p.com [IPv6:fdc4:6ee8:648f:6bf6:0:0:0:f7]) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 69JJQW8v053208 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Oct 2026 15:26:38 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.18.1/8.15.2/Submit) id 69JJQWuX053207; Mon, 19 Oct 2026 12:26:32 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: <376c64cd689c50bba174ef5b0f5cdbc192487077.1792436534.git.ehem+xen@m5p.com> In-Reply-To: References: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , "Roger Pau Monné" , Stefano Stabellini Date: Mon, 19 Oct 2026 12:02:14 -0700 Subject: [RFC PATCH 5/5] scripts/git-checkout.sh: store repositories with Xen, use worktrees X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS, T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com. X-purgate-ID: tlsNG-d25034/1792438007-5290EA5B-57FAED2F/0/0 X-purgate-type: clean X-purgate-size: 6587 Date: Fri, 16 Oct 2026 19:42:44 -0700 The problem with checking out repositories in subdirectories is they may get removed by `git clean`. Whereas storing them with the Xen repository renders them immune to this. Then git worktrees can be used for checking out the specified trees. Remote the addition of "-remote" to the checkout directory names. This is very confusing and a great source for bugs. Signed-off-by: Elliott Mitchell --- WARNING: As of this writing this is known to break qemu-xen building. I've been trying to figure this out, but so far I'm puzzled. --- Makefile | 10 +++++++--- scripts/git-checkout.sh | 42 +++++++++++++++++++++++------------------ tools/Makefile | 12 ++++-------- tools/firmware/Makefile | 14 ++++++-------- 4 files changed, 41 insertions(+), 37 deletions(-) diff --git a/Makefile b/Makefile index f063ce56819..495e2387db2 100644 --- a/Makefile +++ b/Makefile @@ -22,6 +22,7 @@ include Config.mk mini-os-dir: if [ ! -d $(XEN_ROOT)/extras/mini-os ]; then \ GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh \ + mini-os \ $(MINIOS_UPSTREAM_URL) \ $(MINIOS_UPSTREAM_REVISION) \ $(XEN_ROOT)/extras/mini-os ; \ @@ -31,9 +32,12 @@ mini-os-dir: mini-os-dir-force-update: mini-os-dir set -ex; \ if [ "$(MINIOS_UPSTREAM_REVISION)" ]; then \ - cd extras/mini-os-remote; \ - $(GIT) fetch origin; \ - $(GIT) reset --hard $(MINIOS_UPSTREAM_REVISION); \ + rm -rf extras/mini-os; \ + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh \ + mini-os \ + $(MINIOS_UPSTREAM_URL) \ + $(MINIOS_UPSTREAM_REVISION) \ + $(XEN_ROOT)/extras/mini-os ; \ fi export XEN_TARGET_ARCH diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh index 7dde6702b6c..49c5f4b10fd 100755 --- a/scripts/git-checkout.sh +++ b/scripts/git-checkout.sh @@ -3,28 +3,34 @@ set -e if test $# -lt 3; then - echo "Usage: $0 " + echo "Usage: $0 " exit 1 fi GIT="${GIT:-git}" -REPO="$1" -COMMITTISH="$2" -DIR="$3" - -if test \! -d "$DIR-remote"; then - rm -rf "$DIR-remote" "$DIR-remote.tmp" - mkdir -p "$DIR-remote.tmp"; rmdir "$DIR-remote.tmp" - "$GIT" clone "$REPO" "$DIR-remote.tmp" - if test "$COMMITTISH" ; then - cd "$DIR-remote.tmp" - "$GIT" fetch origin "$COMMITTISH" - "$GIT" branch -D dummy >/dev/null 2>&1 ||: - "$GIT" checkout -b dummy FETCH_HEAD - cd - +NAME="$1" +REPO="$2" +COMMITTISH="$3" +DIR="$4" + +# Setup a remote for keeping track of the specified repository +if ! "$GIT" remote | grep -q -e"BUILD/xen/$NAME" +then "$GIT" remote add "BUILD/xen/$NAME" "$REPO" +elif [ "$("$GIT" remote get-url "BUILD/xen/$NAME")" \!= "$REPO" ] +then "$GIT" remote set-url "BUILD/xen/$NAME" "$REPO" + rm -rf "$DIR" +fi + +if [ -e "$DIR" ] +then if [ -d "$DIR" ] + then exit 0 + else rm -rf "$DIR" fi - mv "$DIR-remote.tmp" "$DIR-remote" fi -rm -f "$DIR" -ln -sf $(basename "$DIR-remote") "$DIR" + +# Retrieve the specified commitish +"$GIT" fetch -n "BUILD/xen/$NAME" "$COMMITTISH" + +# Checkout the commitish as a worktree +"$GIT" worktree add -f --detach "$DIR" FETCH_HEAD diff --git a/tools/Makefile b/tools/Makefile index 46847fca998..5739064db98 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -111,9 +111,7 @@ endif # # Directories for external trees: # ${target}-dir -# Used for local builds. Usually a link to ${target}-dir-remote -# ${target}-dir-remote -# Where remote repositories are cloned +# Used for local builds. # ${target} # Where a copy of the source files are put when building a source # tarball for release @@ -134,17 +132,15 @@ qemu-xen-dir-find: if test -d $(QEMU_UPSTREAM_LOC) ; then \ mkdir -p qemu-xen-dir; \ else \ - export GIT=$(GIT); \ - $(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_LOC) $(QEMU_UPSTREAM_REVISION) $(XEN_ROOT)/tools/qemu-xen-dir ; \ + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh qemu-xen $(QEMU_UPSTREAM_LOC) $(QEMU_UPSTREAM_REVISION) $(XEN_ROOT)/tools/qemu-xen-dir ; \ fi .PHONY: qemu-xen-dir-force-update qemu-xen-dir-force-update: qemu-xen-dir-find set -ex; \ if [ "$(QEMU_UPSTREAM_REVISION)" ]; then \ - cd qemu-xen-dir-remote; \ - $(GIT) fetch origin; \ - $(GIT) reset --hard $(QEMU_UPSTREAM_REVISION); \ + rm -rf qemu-xen-dir; \ + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh qemu-xen $(QEMU_UPSTREAM_LOC) $(QEMU_UPSTREAM_REVISION) $(XEN_ROOT)/tools/qemu-xen-dir ; \ fi ifeq ($(debug),y) diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile index a14e7cadd05..0b4d1904e28 100644 --- a/tools/firmware/Makefile +++ b/tools/firmware/Makefile @@ -20,11 +20,11 @@ SEABIOSLD ?= $(LD) SEABIOS_EXTRAVERSION ?= "-Xen" ovmf-dir: - GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/ovmf-dir + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh ovmf $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/ovmf-dir cp ovmf-makefile ovmf-dir/Makefile; seabios-dir: - GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/seabios-dir + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh seabios $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/seabios-dir cp seabios-config seabios-dir/.config; $(MAKE) -C seabios-dir olddefconfig CC=$(SEABIOSCC) LD=$(SEABIOSLD) rm -f seabios-dir/.version @@ -95,9 +95,8 @@ subdir-distclean-seabios-dir: .phony ovmf-dir-force-update: ovmf-dir set -ex; \ if [ "$(OVMF_UPSTREAM_REVISION)" ]; then \ - cd ovmf-dir-remote; \ - $(GIT) fetch origin; \ - $(GIT) reset --hard $(OVMF_UPSTREAM_REVISION); \ + rm -rf ovmf-dir-remote; \ + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh ovmf $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/ovmf-dir ; \ fi subdir-clean-ovmf-dir: @@ -109,9 +108,8 @@ subdir-clean-ovmf-dir: seabios-dir-force-update: seabios-dir set -ex; \ if [ "$(SEABIOS_UPSTREAM_REVISION)" ]; then \ - cd seabios-dir-remote; \ - $(GIT) fetch origin; \ - $(GIT) reset --hard $(SEABIOS_UPSTREAM_REVISION); \ + rm -rf seabios-dir; \ + GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh seabios $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_REVISION) $(XEN_ROOT)/tools/firmware/seabios-dir ; \ fi subdir-clean-seabios-dir: -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:43:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454762.1668274 (Exim 4.92) (envelope-from ) id 1xItGP-0005au-OH; Mon, 19 Oct 2026 19:43:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454762.1668274; Mon, 19 Oct 2026 19: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 1xItGP-0005an-Lj; Mon, 19 Oct 2026 19:43:17 +0000 Received: by outflank-mailman (input) for mailman id 1454762; Mon, 19 Oct 2026 19:43:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGO-0005OJ-9U for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGO-000000022ji-1FsU; Mon, 19 Oct 2026 19:43:16 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGO-00000001FjN-06xx; Mon, 19 Oct 2026 19:43: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=ScatGeN79yCIkgIHLED9u5BvoQ34d9Lt73N7pOTAq9E=; b=o09OGX7ye6Ka7mG88fKyYBbouv OjSiR6qqlfZzWCTtuH8ustkHEh5nj3x5xVNi6+1Fdus/Fbs+Y47IEDbwxXo0UaGcVmaRX0b02aPCk VxAZO/OR711Si63DnpRDrZjOx3wNNCzKxeJuPqY1mF/HItHREh0iIk+OvdGlQ6iOGXLo=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 01/30] x86/PoD: map one page at a time in p2m_pod_zero_check() Date: Mon, 19 Oct 2026 20:42:32 +0100 Message-ID: <20261019-asi-hvm-v4-1-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit p2m_pod_zero_check() maps every page of its batch that passes its checks, up to POD_SWEEP_STRIDE (16) of them, and keeps them mapped across the p2m lookups and updates which follow, each of which maps page-table pages of its own. Its callers hold mappings too: the p2m lookup which found the entry to populate still has its page-table page mapped, and a PV mmu_update() the L1 page it is writing. map_domain_page() cannot always provide that many at once. It uses the mapcache on behalf of PV vCPUs only: in debug builds for every page, in release builds for pages beyond the reach of the directmap in PV guests' page-tables (5TiB, 3.5TiB with CONFIG_BIGMEM). The mapcache has MAPCACHE_VCPU_ENTRIES (16) slots per vCPU of the domain, shared by its vCPUs, and a mapping which finds no slot free or reclaimable hits the BUG_ON() in map_domain_page(): the host crashes. The sweep runs in the context of whichever vCPU populates a PoD entry while the domain's PoD cache is empty. The guest's own vCPUs, being HVM, map through the directmap; a PV vCPU gets there when its domain maps or copies the guest's memory: a device model in dom0 or in a stub domain, a backend doing grant copies. A PV domain with a single vCPU, as a device-model stub domain or a dom0 booted with dom0_max_vcpus=1 is, has 16 slots, and a sweep over 16 candidate pages needs more. The sweep has mapped its whole batch at once since 9ad9a1609fbe ("PoD memory 5/9: emergency scan"), when x86-64 reached all memory through the directmap. The per-vCPU budget came with the mapcache's return to x86-64 in 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al"). Map one page at a time instead, as p2m_pod_zero_check_superpage() already does: map a page for the quick check and unmap it again, and map it anew for the full check after the p2m update and the TLB flush. The checks and their order are unchanged. Each page is mapped twice, which costs little next to scanning it, and the error paths no longer have mappings to undo. Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al") Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Track the pages to check in a bitmask walked with for_each_set_bit(), not an array of bools (Andrew). - Drop the new comment above the first loop; edit the old one's "and map the pages" instead (Andrew). NB this issue was raised in review and verified only by code inspection; it hasn't been demonstrated. --- xen/arch/x86/mm/p2m-pod.c | 72 +++++++++++++++++---------------------- 1 file changed, 31 insertions(+), 41 deletions(-) diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c index 4602c32cff..ed298fa7d2 100644 --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -901,9 +901,10 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { mfn_t mfns[POD_SWEEP_STRIDE]; p2m_type_t types[POD_SWEEP_STRIDE]; - unsigned long *map[POD_SWEEP_STRIDE]; + unsigned int check = 0; + const unsigned long *map; struct domain *d = p2m->domain; - unsigned int i, j, max_ref = 1; + unsigned int j, max_ref = 1; BUG_ON(count > POD_SWEEP_STRIDE); @@ -911,8 +912,11 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count if ( paging_mode_shadow(d) ) max_ref++; - /* First, get the gfn list, translate to mfns, and map the pages. */ - for ( i = 0; i < count; i++ ) + /* + * First, get the gfn list, translate to mfns, and check for being a + * plausible candidate. + */ + for ( unsigned int i = 0; i < count; i++ ) { p2m_access_t a; @@ -921,9 +925,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count /* * If this is ram, and not a pagetable or a special page, and - * probably not mapped elsewhere, map it; otherwise, skip. + * probably not mapped elsewhere, check it; otherwise, skip. */ - map[i] = NULL; if ( p2m_is_ram(types[i]) ) { const struct page_info *pg = mfn_to_page(mfns[i]); @@ -932,7 +935,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count (pg->count_info & PGC_allocated) && !(pg->count_info & PGC_shadowed_pt) && ((pg->count_info & PGC_count_mask) <= max_ref) ) - map[i] = map_domain_page(mfns[i]); + check |= 1U << i; } } @@ -940,20 +943,23 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count * Then, go through and check for zeroed pages, removing write permission * for those with zeroes. */ - for ( i = 0; i < count; i++ ) + for_each_set_bit ( i, check ) { - if ( !map[i] ) - continue; - /* Quick zero-check */ + map = map_domain_page(mfns[i]); for ( j = 0; j < 16; j++ ) - if ( *(map[i] + j) != 0 ) - goto skip; + if ( map[j] != 0 ) + break; + unmap_domain_page(map); /* Try to remove the page, restoring old mapping if it fails. */ - if ( p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, + if ( j < 16 || + p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, p2m_populate_on_demand, p2m->default_access) ) - goto skip; + { + check &= ~(1U << i); + continue; + } /* * See if the page was successfully unmapped. (Allow one refcount @@ -961,6 +967,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count */ if ( (mfn_to_page(mfns[i])->count_info & PGC_count_mask) > 1 ) { + check &= ~(1U << i); + /* * If the previous p2m_set_entry call succeeded, this one shouldn't * be able to fail. If it does, crashing the domain should be safe. @@ -970,38 +978,27 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { ASSERT_UNREACHABLE(); domain_crash(d); - goto out_unmap; + return; } - - skip: - unmap_domain_page(map[i]); - map[i] = NULL; - - continue; } } p2m_tlb_flush_sync(p2m); /* Now check each page for real */ - for ( i = 0; i < count; i++ ) + for_each_set_bit ( i, check ) { - if ( !map[i] ) - continue; - - for ( j = 0; j < (PAGE_SIZE / sizeof(*map[i])); j++ ) - if ( *(map[i] + j) != 0 ) + map = map_domain_page(mfns[i]); + for ( j = 0; j < (PAGE_SIZE / sizeof(*map)); j++ ) + if ( map[j] != 0 ) break; - - unmap_domain_page(map[i]); - - map[i] = NULL; + unmap_domain_page(map); /* * See comment in p2m_pod_zero_check_superpage() re gnttab * check timing. */ - if ( j < (PAGE_SIZE / sizeof(*map[i])) ) + if ( j < (PAGE_SIZE / sizeof(*map)) ) { /* * If the previous p2m_set_entry call succeeded, this one shouldn't @@ -1012,14 +1009,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { ASSERT_UNREACHABLE(); domain_crash(d); - out_unmap: - /* - * Something went wrong, probably crashing the domain. Unmap - * everything and return. - */ - for ( i = 0; i < count; i++ ) - if ( map[i] ) - unmap_domain_page(map[i]); + return; } } else -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:43:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454761.1668264 (Exim 4.92) (envelope-from ) id 1xItGO-0005OV-Dv; Mon, 19 Oct 2026 19:43:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454761.1668264; Mon, 19 Oct 2026 19: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 1xItGO-0005OO-BA; Mon, 19 Oct 2026 19:43:16 +0000 Received: by outflank-mailman (input) for mailman id 1454761; Mon, 19 Oct 2026 19:43:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGN-0005OC-8X for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGN-000000022je-1WMX for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGN-00000001FjN-0Qpv for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43: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:Content-Type: MIME-Version:Message-ID:Date:Subject:To:From; bh=wLsogNPjrZdKtS17lrwteI/YwOL7FRQzUi+W577fu44=; b=OgBgQFpTLw/v8jepk2Mbjig5pz F/SFUvrhRLj45kVWJcuRTE43sJ+vgrBjzrWdo1rATTiR5lIDAOL1ONSWMeLVkEH5/IXnswYQd+LTN wAWV6vjWDyN3S+GwlkgHn2iblqwO90sVd9D6YOnO3yvlVdMNe1rnigieEG30T9EvpC0k=; From: George Dunlap To: xen-devel@lists.xenproject.org Subject: [PATCH v4 00/30] ASI: HVM per-vCPU areas, sparse-view directmap, per-vCPU state area Date: Mon, 19 Oct 2026 20:42:31 +0100 Message-ID: <20261019-asi-hvm-v4-0-b68b66652266@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 This is the first part of a series to implement address space isolation. The approach is the same as v3: Start by focusing on just getting ASI and intra-domain isolation for HVM guests. PV support is added where it's simple to do, and regressions are avoided. The first 20 patches are (sometimes broken-down or extended) versions of what was posted in v3; the last 10 patches make a few additional improvements to the sparse-view directmap, and then begin moving vCPU state out of the xenheap and into a per-vCPU area. To be more detailed: 01: A fix that should be considered for backport 02-14: Implement per-vCPU perdomain area and per-vCPU mapcaches for HVM guests. 15-22: Maintain two "views" of the directmap: A full directmap, and a sparse directmap. The full directmap is what we have now; the sparse directmap removes non-xenheap heap memory. 23-30: Add a vCPU state area to the perdomain area (both for PV and HVM). Move SVM VMCB structures and VMX guest MSR areas into it. One key thing to get feedback on is 22: It's a not very simple effort to mitigate a very rare event. Note that at the end of this series, PV guests can be given the sparse direct-map; this isolates them from other domains, but doesn't isolate vCPUs within a domain. An advantage of this is that it allows us to easily turn the sparse directmap off for dom0 (or other system domains). Some quick tests on my local test rig on v3 of the series show that network throughput from dom0 to a guest drops 31% when the sparse directmap is enabled for dom0 vs not. The rest of the series looks like this: - Move more things into the vCPU state area: user_regs, FPU/XSAVE - Hardening for ioreq server state (The ioreq server pages can't be moved into per-vCPU areas without a massive refactoring of the ioreq server protocol.) - Implement per-pCPU stacks. In this mode, per-pCPU stacks would only be for HVM guests using the "sparse directmap". Until we get per-vCPU root pagetables for PV guests, it's not practical to prevent a PV guest from seeing all the stacks. - Low-hanging optimizations A dependency graph of the above functionality can be found here: https://xenbits.xenproject.org/people/gdunlap/asi-series-deps.html Extending the intra-domain isolation to PV guests would involve implementing per-vCPU root pagetables for PV guests. There are draft implementations of this, but they are quite complicated. George Dunlap (20): x86/PoD: map one page at a time in p2m_pod_zero_check() x86/mm: refuse to promote an L4 while the domain has no vCPU x86/mm: have init_xen_l4_slots() take a vCPU in place of the domain x86/domain_page: drop redundant is_pv_vcpu() checks x86/domain_page: don't unmap a mapcache entry that is not present x86/mm: let Xen's page-table walker operate on a given root x86/mm: build and maintain a sparse view of the directmap x86/domain_page: key the directmap fast paths on the loaded view x86/domain_page: clear a mapcache slot at its last unmap x86/mm: run guest contexts on the sparse directmap view x86/spec-ctrl: wire the sparse directmap view into the asi= option xen/xmalloc: return an emptied region after dropping the pool lock x86/mm: split a sparse directmap superpage with a page being freed x86/mm: introduce a per-vCPU state window in the perdomain area x86/svm: introduce svm_vmcb_map() and svm_vmcb_unmap() x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from() x86/svm: restore guest debug registers in svm_do_resume() x86/svm: drop svm_vmcb_dump()'s paddr and the unused VCPU_svm_vmcb x86/svm: allocate VMCBs from the domain heap behind the vCPU state window x86/vmx: move the guest MSR load/save list off always-mapped memory Roger Pau Monné (10): 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/hvm: introduce per-vCPU L3 page-table x86/domain_page: prepare the mapcache for per-vCPU accounting x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains x86/mm: introduce populate_perdomain_mapping() docs/misc/xen-command-line.pandoc | 49 +++ xen/arch/x86/Kconfig | 1 + xen/arch/x86/Makefile | 1 + xen/arch/x86/domain.c | 30 +- xen/arch/x86/domain_page.c | 302 +++++++++---- xen/arch/x86/hvm/hvm.c | 6 - xen/arch/x86/hvm/svm/nestedsvm.c | 12 +- xen/arch/x86/hvm/svm/svm.c | 151 +++++-- xen/arch/x86/hvm/svm/vmcb.c | 74 +++- xen/arch/x86/hvm/svm/vmcb.h | 20 +- xen/arch/x86/hvm/vmx/vmcs.c | 134 +++++- xen/arch/x86/include/asm/config.h | 23 +- xen/arch/x86/include/asm/domain.h | 51 ++- xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 63 +-- xen/arch/x86/include/asm/mm.h | 29 +- xen/arch/x86/include/asm/sparse-directmap.h | 83 ++++ xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/mm.c | 424 +++++++++++++++--- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/p2m-pod.c | 72 ++-- xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/pv/dom0_build.c | 6 +- xen/arch/x86/pv/domain.c | 30 +- xen/arch/x86/pv/shim.c | 4 +- xen/arch/x86/setup.c | 4 + xen/arch/x86/sparse-directmap.c | 455 ++++++++++++++++++++ xen/arch/x86/spec_ctrl.c | 174 +++++++- xen/arch/x86/x86_64/asm-offsets.c | 1 - xen/arch/x86/x86_64/mm.c | 14 +- xen/common/Kconfig | 18 + xen/common/page_alloc.c | 51 ++- xen/common/xmalloc_tlsf.c | 12 +- xen/include/xen/mm.h | 40 ++ 34 files changed, 1993 insertions(+), 349 deletions(-) create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h create mode 100644 xen/arch/x86/sparse-directmap.c base-commit: 7e020a4dd6ed30eb6c91a9abe2767034e2bb270a -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:43:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454763.1668282 (Exim 4.92) (envelope-from ) id 1xItGR-0005oG-Vg; Mon, 19 Oct 2026 19:43:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454763.1668282; Mon, 19 Oct 2026 19:43: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 1xItGR-0005o9-SZ; Mon, 19 Oct 2026 19:43:19 +0000 Received: by outflank-mailman (input) for mailman id 1454763; Mon, 19 Oct 2026 19:43:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGQ-0005l1-Fu for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:18 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGQ-000000022js-0xCB; Mon, 19 Oct 2026 19:43:18 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGP-00000001FjN-44FX; Mon, 19 Oct 2026 19:43: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:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=gVZuKX9SYj+BXemwpZoxl0keumPErYRZAVZ10RQNwMQ=; b=4ypTgErHnSe8mBjfFUTfHIqJzn yeBSQhXXpoISNR4eZo5O2S6gT26l9DBcKRYRigqNwuBekiz36jrdZwxkShvoBwcU1G3ZEdcvv3LCQ dt1jBQ2zrsODVGcUWADvQgDPxGR/rbX5ddUeajgTyvFpthdoczv0DyjaxxrNtogg8owU=; 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?= , Teddy Astie Subject: [PATCH v4 03/30] x86/mm: purge unneeded destroy_perdomain_mapping() Date: Mon, 19 Oct 2026 20:42:34 +0100 Message-ID: <20261019-asi-hvm-v4-3-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 at both of its call sites. arch_domain_destroy() unconditionally calls free_perdomain_mappings(), which tears down the same entries and additionally frees the page-table structures; and the other caller, the error path of pv_domain_initialise(), returns into arch_domain_create()'s failure path, which invokes free_perdomain_mappings() as well. One vCPU-scoped caller, pv_destroy_gdt_ldt_l1tab(), is covered the same way: a vCPU is only ever destroyed together with its domain, or on the failure path of creating it, and both routes end in free_perdomain_mappings(); the GDT/LDT slots hold no area-owned pages, so there is nothing else for the call to do. While we're getting rid of unneccessary callers, drop this one too. Note that free_compat_arg_xlat() keeps its explicit teardown: switch_compat() calls it on the failure path. While in practice most toolstacks will immediately destroy the domain, in theory a toolstack could let it live on as a 64-bit guest. Release the resources immediately rather than waiting for domain destruction. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap Reviewed-by: Jan Beulich --- Changes in v4: - Remove an unnecessary comment (Jan). Changes in v3: - Note that pv_domain_destroy()'s other call site, the error path of pv_domain_initialise(), is covered the same way (Jan). - Also drop pv_destroy_gdt_ldt_l1tab(), the per-vCPU teardown call (Jan), and comment on why free_compat_arg_xlat() keeps its own. The Reviewed-by tags given for the previous form are dropped. 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 | 10 ---------- 2 files changed, 11 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index ef9c7cd057..6aefe91e02 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 0c42ae58aa..28ea0742ab 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -319,12 +319,6 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) NULL); } -static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) -{ - destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v), - 1U << GDT_LDT_VCPU_SHIFT); -} - void pv_vcpu_destroy(struct vcpu *v) { if ( is_pv_32bit_vcpu(v) ) @@ -333,7 +327,6 @@ void pv_vcpu_destroy(struct vcpu *v) release_compat_l4(v); } - pv_destroy_gdt_ldt_l1tab(v); XFREE(v->arch.pv.trap_ctxt); } @@ -381,9 +374,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); FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:43:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454764.1668292 (Exim 4.92) (envelope-from ) id 1xItGT-00061V-7E; Mon, 19 Oct 2026 19:43:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454764.1668292; Mon, 19 Oct 2026 19:43: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 1xItGT-00061L-3K; Mon, 19 Oct 2026 19:43:21 +0000 Received: by outflank-mailman (input) for mailman id 1454764; Mon, 19 Oct 2026 19:43:19 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGR-0005o0-QB for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:19 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGR-000000022k0-1GbZ; Mon, 19 Oct 2026 19:43:19 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGQ-00000001FjN-4BPF; Mon, 19 Oct 2026 19:43: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:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=8+JAad6tubYajhSY57aMWHsaXENtbq4fiWg5qfzI9E4=; b=iBtYW3U07XnDEU+FpkZ9lFj8sO SUE+I3OGT26j8xHUkuLNvYpPYRDaBz3+FlqzmEmIgXvkGq4khwO4sdoTXqloJM1T0/9TTJw2VORJ9 059A/Ktsj8ue7Nlq34kGLozlKegxNA/CkRr5FvHhA/+L4RNKVEM51VT3l1Cj/hVyAm/s=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v4 04/30] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas Date: Mon, 19 Oct 2026 20:42:35 +0100 Message-ID: <20261019-asi-hvm-v4-4-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 one remaining caller, free_compat_arg_xlat(), is already in a vCPU context, so we just need to change the parameter from a domain pointer to a vCPU pointer. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v4: - Say "No functional change." (Roger). Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series): free_compat_arg_xlat() is the only caller left. - Drop the linear-page-table fast path altogether (Jan): its only user would have been guest-driven LDT teardown, and without it the function does not depend on the linear mapping being available. Changes in v2: - Added to the series Changes since the previously posted version: - The fast path is gone (v3), and with it the previously posted version's sync_local_execstate() call. - 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 | 3 ++- xen/arch/x86/x86_64/mm.c | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index aa515efbee..20a1d27cd0 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -609,7 +609,7 @@ 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 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 3f6f9f3bd4..70b4cc87ae 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6361,10 +6361,11 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, return rc; } -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)); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 8eadab7933..f467ed426b 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -739,7 +739,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 Mon Oct 19 19:43:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454765.1668298 (Exim 4.92) (envelope-from ) id 1xItGT-00064h-Jk; Mon, 19 Oct 2026 19:43:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454765.1668298; Mon, 19 Oct 2026 19:43: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 1xItGT-000641-BK; Mon, 19 Oct 2026 19:43:21 +0000 Received: by outflank-mailman (input) for mailman id 1454765; Mon, 19 Oct 2026 19:43:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGS-0005ur-CS for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGS-000000022k8-1ErZ; Mon, 19 Oct 2026 19:43:20 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGS-00000001FjN-09tM; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=2WAx232e1o23xbVvwluUdMmJZVaoZJGamK8uLinVDPU=; b=NKMK8/Ki0ezCIEAlL7cZwz7gyp L1u3bm3PXbOvQ0ed6wuwklEkss95YOhTORtDceTntsIwdGFHOWnNrzsjVee65HkFrWdU1zKXbZiii T3q0KLx2NkVAVHH23HsPaP8wXRx7H+TW3czd75oZqrCbwv2g4IODQ/E+diO1FL4xnh2E=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v4 05/30] x86/domain_page: drop redundant create_perdomain_mapping() call Date: Mon, 19 Oct 2026 20:42:36 +0100 Message-ID: <20261019-asi-hvm-v4-5-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 populating 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. In debug builds, and on hosts with memory hotplug or with more memory than the PV directmap covers, the call was also what first allocated a PV domain's per-domain L3. Release builds on other hosts already allocated it only with the first vCPU. Drop the call; now we always allocate only with the first vCPU. With the only fallible operation gone, mapcache_domain_init() becomes void, and arch_domain_create()'s error handling for it goes away. The per-domain-mapping work in mapcache_vcpu_init() stays where it is rather than moving into mapcache_domain_init() along with this change, ready for a later patch which introduces per-vCPU mapcaches. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series); no functional difference. - Say why the per-vCPU part stays in mapcache_vcpu_init() (Jan). - Say that the call also first allocated a PV domain's per-domain L3 in some builds, which all builds now do with the first vCPU. 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 | 8 ++------ xen/arch/x86/include/asm/domain.h | 2 +- 3 files changed, 4 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 368e4deff3..8e17fbe6d9 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 5744754f11..f02be1675b 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -223,7 +223,7 @@ void unmap_domain_page(const void *ptr) local_irq_restore(flags); } -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; @@ -232,7 +232,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 + @@ -244,10 +244,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, - NIL(l1_pgentry_t *), NULL); } 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 2d0a915410..212daae1f5 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 Mon Oct 19 19:43:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454766.1668311 (Exim 4.92) (envelope-from ) id 1xItGW-0006VP-0B; Mon, 19 Oct 2026 19:43:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454766.1668311; Mon, 19 Oct 2026 19:43: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 1xItGV-0006VA-Ra; Mon, 19 Oct 2026 19:43:23 +0000 Received: by outflank-mailman (input) for mailman id 1454766; Mon, 19 Oct 2026 19:43:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGU-0006Ij-44 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGT-000000022kG-1M3w; Mon, 19 Oct 2026 19:43:21 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGT-00000001FjN-0Hsu; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=fz3Khl+YQ3OVqb+Nyg7wjka6rX6rxBEMbOvfyB10Kfg=; b=XJczJ526bG6HuY812+loa90tB5 1+6oWDUmNLoiFcFoAOCKbpEJHt9ToG1Zsw2QL3K41BIXSklS0npnpiYLzQYsjKA6wLK5Zs8xIvjJz lSiqjdV8qsRqziu5pRJozUoYUTL/QUS4MdWQBpUvjSBW7byQDAbRQL/PtBqti0zZJx7o=; 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?= , Teddy Astie Subject: [PATCH v4 06/30] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas Date: Mon, 19 Oct 2026 20:42:37 +0100 Message-ID: <20261019-asi-hvm-v4-6-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 before any page tables referencing it are built. 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. Once a domain's area is per-vCPU, a later change gives its vCPUs a teardown of their own; the domain-wide teardown stays for domains with a shared area, PV ones included. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Jan Beulich --- Changes in v4: - Message: drop a sentence repeating its paragraph, and say that the domain-wide teardown stays for domains with a shared area (Roger). - End the comment in arch_vcpu_create() at the colon (Roger). Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series): the capture parameters stay, as the PV GDT/LDT stash still uses them. 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 | 8 ++++++++ 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 | 3 ++- xen/arch/x86/pv/domain.c | 2 +- xen/arch/x86/x86_64/mm.c | 2 +- 7 files changed, 16 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 8e17fbe6d9..94a1ea904a 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -517,6 +517,14 @@ 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). + */ + rc = create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, NULL, NULL); + 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 f02be1675b..f3e65e2d44 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -260,15 +260,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, + int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, NIL(l1_pgentry_t *), NULL); /* Populate bit maps. */ if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse, + rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse, nr, NULL, NIL(struct page_info *)); if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage, + rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage, nr, NULL, NIL(struct page_info *)); if ( rc ) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 6aefe91e02..71da15c0a4 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, NULL, NULL); - 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 20a1d27cd0..c9085214fd 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -606,7 +606,7 @@ 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, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, l1_pgentry_t **pl1tab, struct page_info **ppg); void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 70b4cc87ae..c6bd53354b 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6238,10 +6238,11 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e) (_PAGE_PRESENT | _PAGE_AVAIL0); } -int create_perdomain_mapping(struct domain *d, unsigned long va, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, l1_pgentry_t **pl1tab, struct page_info **ppg) { + 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 28ea0742ab..f3c711b85b 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, v->domain->arch.pv.gdt_ldt_l1tab, NULL); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index f467ed426b..7b04537066 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), NULL, NIL(struct page_info *)); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:43:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454767.1668313 (Exim 4.92) (envelope-from ) id 1xItGW-0006YD-8Q; Mon, 19 Oct 2026 19:43:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454767.1668313; Mon, 19 Oct 2026 19:43: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 1xItGW-0006Xu-3Q; Mon, 19 Oct 2026 19:43:24 +0000 Received: by outflank-mailman (input) for mailman id 1454767; Mon, 19 Oct 2026 19:43:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGU-0006TJ-R3 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGU-000000022kO-3GLw; Mon, 19 Oct 2026 19:43:22 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGU-00000001FjN-2BAz; Mon, 19 Oct 2026 19:43: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=6OJOmz2h1qdSQxscI6ufRihl1BCNT0xYCyFQN2O5ZQY=; b=rj1if8TX1/ezr4RUzRtSvgBz1t /Ds7StBnJxj3AVCWe3isOklU/ssaKqOydWNtFvQxrKr+8Ami+saV1BfHOJ1tKm85/hfgnvizr5NF2 hutHiLBi7hJ6baF8OE8QIJjrdGfeZ+d9wno0s5nvTXqpRVSJ8DYYk0eDxI1Rr7xjvktk=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Teddy Astie Subject: [PATCH v4 07/30] x86/spec-ctrl: introduce Address Space Isolation command line option Date: Mon, 19 Oct 2026 20:42:38 +0100 Message-ID: <20261019-asi-hvm-v4-7-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Introduce the `asi=` command line option, and the opt_vcpu_pt_hvm and opt_pvh_vcpu_pt_hwdom knobs plus the per-domain d->arch.asi.vcpu_pt setting they control. 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 adds a boot-time warning that the feature is not functional and is meant for development only. The mechanisms this option controls apply to HVM domains: an HVM vCPU already runs on its own monitor table, so a per-vCPU per-domain area needs no work at context switch. d->arch.asi.vcpu_pt is therefore only ever set for HVM domains, a PVH hardware domain included; PV domains, a PV hardware domain included, are unaffected. Besides the plain boolean, `pv=`, `hvm=` and `dom0=` select the features for PV domains or HVM domains other than the hardware domain, or for the hardware domain, PV or PVH. None of the features applies to PV domains, so `pv=` has no effect, and `dom0=` acts on a PVH hardware domain only. The boot log gains "ASI features for ..." lines for Dom0 and HVM domains, so hardware-domain-only configurations remain visible. 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, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Docs: "domains" throughout, not "guests" (Roger). - Group the per-domain settings as one-bit fields of d->arch.asi (Roger). - Rename opt_vcpu_pt_hwdom to opt_pvh_vcpu_pt_hwdom: it acts on a PVH hardware domain only (Jan). - parse_asi(): break in the success branch and fall through to default:, rather than a default: label after an else (MISRA C:2012 Rule 16.2; Jan). - Message: enabling a knob adds a boot-time warning; it does not taint (Roger). - Add the pv= and dom0= sub-options here, beside hvm= (Roger). Changes in v3: - HVM only: drop the PV knob and its interaction with XPTI. vCPU-PT applies to HVM domains and to a PVH hardware domain; the Dom0 boot log line says None for a PV one. Changes in v2: - Added to the series Changes since the previously posted version: - Include the hardware domain in the development warning and the boot log summary. - Make the opt_vcpu_pt_* knobs plain booleans preinitialised to false, dropping the late -1 resolution. - Documentation: mention possible protection against unmitigated attacks, and state that hvm= does not affect the hardware domain. - Rewrite the commit message. --- docs/misc/xen-command-line.pandoc | 29 ++++++++++ xen/arch/x86/include/asm/domain.h | 6 ++ xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/spec_ctrl.c | 82 ++++++++++++++++++++++++++++ 4 files changed, 119 insertions(+) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index a6f08463d1..839d06da26 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -202,6 +202,35 @@ 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,dom0}=, +> vcpu-pt= | vcpu-pt=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. + +The mechanisms currently implemented apply to HVM domains, including a PVH +hardware domain. PV domains, including a PV hardware domain, are unaffected. + +* `pv=`, `hvm=` and `dom0=` enable the features for PV domains or HVM domains + other than the hardware domain, or for the hardware domain, PV or PVH. The + plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain + out. The forms naming no domain type (an un-suffixed `vcpu-pt=`) + cover the hardware domain too. + +**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` gives each vCPU its own per-domain area: the per-domain slot of + each vCPU's monitor table maps a region private to that vCPU. + ### asid (x86) > `= ` diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 212daae1f5..12f79feb42 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -474,6 +474,12 @@ struct arch_domain /* Don't unconditionally inject #GP for unhandled MSRs. */ bool msr_relaxed; + /* Fine grained ASI related options. */ + struct { + /* Give each vCPU its own per-domain area (HVM only). */ + bool vcpu_pt:1; + } asi; + /* 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..d84f985e82 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_pvh_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..66c878212a 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -86,6 +86,10 @@ bool __ro_after_init opt_bp_spec_reduce = true; static bool __initdata opt_ibpb_alt; +/* Give each vCPU of an HVM domain its own per-domain area (vCPU-PT). */ +bool __ro_after_init opt_vcpu_pt_hvm; +bool __ro_after_init opt_pvh_vcpu_pt_hwdom; + static int __init cf_check parse_spec_ctrl(const char *s) { const char *ss; @@ -487,6 +491,69 @@ 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_pvh_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_pvh_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; + break; + + default: + if ( (val = parse_boolean("pv", s, ss)) >= 0 ) + /* PV domains are unaffected. */; + else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + opt_vcpu_pt_hvm = val; + else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) + opt_pvh_vcpu_pt_hwdom = val; + else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) + { + switch ( val ) + { + case 1: + case 0: + opt_pvh_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; + break; + + case -2: + s += strlen("vcpu-pt="); + if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + { + opt_vcpu_pt_hvm = val; + break; + } + fallthrough; + 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 +747,13 @@ 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\n", + opt_dom0_pvh && opt_pvh_vcpu_pt_hwdom ? " vCPU-PT" : " None"); +#ifdef CONFIG_HVM + printk(" ASI features for HVM VMs:%s\n", + opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); +#endif } static bool __init check_smt_enabled(void) @@ -1866,6 +1940,9 @@ 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.asi.vcpu_pt = !pv && (is_hardware_domain(d) ? opt_pvh_vcpu_pt_hwdom + : opt_vcpu_pt_hvm); } void __init init_speculation_mitigations(void) @@ -2158,6 +2235,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_pvh_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 Mon Oct 19 19:43:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454770.1668329 (Exim 4.92) (envelope-from ) id 1xItGb-00077m-N3; Mon, 19 Oct 2026 19:43:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454770.1668329; Mon, 19 Oct 2026 19:43: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 1xItGb-00077P-Fd; Mon, 19 Oct 2026 19:43:29 +0000 Received: by outflank-mailman (input) for mailman id 1454770; Mon, 19 Oct 2026 19:43:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGa-00075p-Uj for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGV-000000022kX-3WZT; Mon, 19 Oct 2026 19:43:23 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGV-00000001FjN-2Sl0; Mon, 19 Oct 2026 19: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" 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=gqNXY0Fy96nvsg760epSXdia2CmgV3Q0H0of+zL6Uo8=; b=63LyVTQDDFyWxylg9QAQV+60RR TRY0KrUZ9LOs/OHxzML/8JqcEplHlg58VVMmb3npyb5+EEkvMQfHoj/tL3fPaCP5Qxua+Nz4rTzaB Hded2vk533sm+6IYu68eAeMFdcyruOXYscOFW97uCChL2xcm87zyS2OJ5O/N2sMdqgtE=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Tim Deegan Subject: [PATCH v4 08/30] x86/mm: have init_xen_l4_slots() take a vCPU in place of the domain Date: Mon, 19 Oct 2026 20:42:39 +0100 Message-ID: <20261019-asi-hvm-v4-8-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A later change gives the vCPUs of some domains per-domain areas of their own, and slot 260 of a table private to one vCPU must then hold that vCPU's L3. init_xen_l4_slots(), which fills slot 260, needs the vCPU for that. Have it take a vCPU in place of the domain. A table private to one vCPU passes that vCPU; tables the domain's vCPUs share -- promoted PV guest L4s, PV shadow L4s, and the PV dom0 L4 under construction -- pass any of them. promote_l4_table() passes vCPU 0, whose existence it already checks, and its call is reflowed. No functional change: slot 260 still gets the domain's per-domain L3. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version, split out of "x86/hvm: introduce per-vCPU L3 page-table": init_xen_l4_slots() takes a vCPU in place of the domain (Roger, Jan). - Reflow promote_l4_table()'s call to init_xen_l4_slots() (Jan). --- xen/arch/x86/include/asm/mm.h | 2 +- xen/arch/x86/mm.c | 16 +++++++++++----- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/pv/dom0_build.c | 2 +- xen/arch/x86/pv/domain.c | 2 +- 7 files changed, 17 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index c9085214fd..de45a111f3 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); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index c6bd53354b..ac074cc62d 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1687,14 +1687,18 @@ static int promote_l3_table(struct page_info *page) * 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. + * + * v is the vCPU the table is private to or, for a table the domain's vCPUs + * share, any of them. */ 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. @@ -1797,6 +1801,8 @@ void zap_ro_mpt(mfn_t mfn) static int promote_l4_table(struct page_info *page) { struct domain *d = page_get_owner(page); + /* Any vCPU will do: a PV domain's vCPUs all use the domain-wide L3. */ + const struct vcpu *v = domain_vcpu(d, 0); mfn_t l4mfn = page_to_mfn(page); l4_pgentry_t *pl4e; unsigned int i; @@ -1808,7 +1814,7 @@ static int promote_l4_table(struct page_info *page) * PV domain may get that only with its first vCPU. The domain has no * vCPUs before XEN_DOMCTL_max_vcpus. */ - if ( !domain_vcpu(d, 0) ) + if ( !v ) return -EINVAL; pl4e = map_domain_page(l4mfn); @@ -1887,8 +1893,8 @@ static int promote_l4_table(struct page_info *page) if ( !rc ) { - init_xen_l4_slots(pl4e, l4mfn, - d, INVALID_MFN, VM_ASSIST(d, m2p_strict)); + init_xen_l4_slots(pl4e, l4mfn, v, INVALID_MFN, + VM_ASSIST(d, m2p_strict)); atomic_inc(&d->arch.pv.nr_l4_pages); } unmap_domain_page(pl4e); 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/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 7f72b4b7b2..ebbf4a12ce 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 24f2fa0b7f..dcb1d407ec 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -725,7 +725,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); + v, INVALID_MFN, true); v->arch.guest_table = pagetable_from_paddr(__pa(l4start)); } else diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index f3c711b85b..f139d8f83c 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 Mon Oct 19 19:43:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454771.1668338 (Exim 4.92) (envelope-from ) id 1xItGd-0007O4-8l; Mon, 19 Oct 2026 19:43:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454771.1668338; Mon, 19 Oct 2026 19:43: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 1xItGd-0007N6-0Q; Mon, 19 Oct 2026 19:43:31 +0000 Received: by outflank-mailman (input) for mailman id 1454771; Mon, 19 Oct 2026 19:43:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGb-00077Q-Er for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGP-000000022jq-0zl8; Mon, 19 Oct 2026 19:43:17 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGO-00000001FjN-3zHt; Mon, 19 Oct 2026 19:43: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=jkPIl+dPP6zf0AQ7LteorT5djg7uxPkCmb8aNhe84Jw=; b=iM/SmPKHE2sQAwkaLYZYQY8srW Uql64ogIv6tHXYC80tTTUHJOBSFxpWCMW7dAmPFWqyOVS2WZrhZp9PGZMM0CUAs1imQ6VpxIyFmM6 z19rNIidUMjzJ3bIYsxC/GfScRFiiB5EHAR2cTDmfZASr1jEtw2JjJH5bbPzkyAAYXfo=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 02/30] x86/mm: refuse to promote an L4 while the domain has no vCPU Date: Mon, 19 Oct 2026 20:42:33 +0100 Message-ID: <20261019-asi-hvm-v4-2-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit init_xen_l4_slots() puts the domain's per-domain L3 in slot 260 of the L4s it fills. Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT L3 slot at domain creation") a PV domain gets that L3 with its first vCPU (pv_create_gdt_ldt_l1tab()). Only mapcache_domain_init() makes it earlier, with the domain, and release builds skip that unless memory hotplug is enabled or the host's memory reaches past the part of the directmap PV guests can see. So in release builds on most hosts, an L4 promoted before XEN_DOMCTL_max_vcpus has created the domain's vCPUs gets a slot 260 entry made from a NULL page (0x803e900000000063), pointing far beyond the host's memory. Debug builds happen to have the L3 that early. Refuse such an L4 in every build, so that there is one rule: promote_l4_table() returns -EINVAL while the domain has no vCPU 0, before taking any reference. libxl is unaffected: it creates the vCPUs before it builds or restores a domain. There's no way to trigger the issue from the current toolstack; this is just belt-and-braces. Fixes: fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT L3 slot at domain creation") Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version, split out of "x86/hvm: introduce per-vCPU L3 page-table": promote_l4_table() fails while the domain has no vCPU --- xen/arch/x86/mm.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e42cd33c0d..3f6f9f3bd4 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1798,11 +1798,21 @@ 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() puts the domain's per-domain L3 in slot 260, and a + * PV domain may get that only with its first vCPU. The domain has no + * vCPUs before XEN_DOMCTL_max_vcpus. + */ + if ( !domain_vcpu(d, 0) ) + return -EINVAL; + + pl4e = map_domain_page(l4mfn); + for ( i = page->nr_validated_ptes; i < L4_PAGETABLE_ENTRIES; i++, partial_flags = 0 ) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:43:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:43:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454772.1668342 (Exim 4.92) (envelope-from ) id 1xItGd-0007S5-NY; Mon, 19 Oct 2026 19:43:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454772.1668342; Mon, 19 Oct 2026 19:43: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 1xItGd-0007Qb-EG; Mon, 19 Oct 2026 19:43:31 +0000 Received: by outflank-mailman (input) for mailman id 1454772; Mon, 19 Oct 2026 19:43:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItGc-0007E8-2H for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:43:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItGW-000000022kb-3mSS; Mon, 19 Oct 2026 19:43:24 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGW-00000001FjN-2i3h; Mon, 19 Oct 2026 19:43: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=djncFJQMGREcvSArGBCTiVkXx4p/IkOBHDslyykTajc=; b=ZCqMGSirfqIGpLddDJiiELm2vo Re+kcmOo6FEaIXtthP/ZGljeW3KoXyVm7bDeKmTFnloD5crNsb1kFzjU1Qs1wfvREuoMOArFLLZSP slWugFnUJTi5I4jvo1oYTU/qy8MVrgf+WnEUIGG50mGJN4AGYNPUu96UR2AYN6x6nmT0=; 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?= , Teddy Astie Subject: [PATCH v4 09/30] x86/hvm: introduce per-vCPU L3 page-table Date: Mon, 19 Oct 2026 20:42:40 +0100 Message-ID: <20261019-asi-hvm-v4-9-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 COMPAT_ARG_XLAT pages, and for PV each vCPU's GDT/LDT window 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. Allow the "per-domain" area to be per-vCPU instead ("VCPU-PT") for HVM domains. HVM monitor tables are already per-vCPU, so this needs nothing at context switch: every monitor table carries its vCPU's own L3 from creation, and the per-vCPU mappings are isolated from other running vCPUs at once. We will later build on this, adding a per-vCPU mapcache and per-vCPU mapped areas, into which we can move the vCPU state mentioned above. 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; PV domains always use the domain-wide one.) In {create,destroy}_perdomain_mapping(), if d->arch.asi.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() keeps covering non-vCPU-PT domains. init_xen_l4_slots() is given the vCPU a table is private to or, for a table the domain's vCPUs share, any of them. Have it install that vCPU's perdomain_l3() in slot 260: the tables a domain's vCPUs share are PV ones, and a PV domain's vCPUs all use the domain-wide L3. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-fable-5-1, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Rebase over earlier changes - d->arch.vcpu_pt is now d->arch.asi.vcpu_pt. - init_xen_l4_slots() taking a vCPU in place of the domain, and promote_l4_table() failing while the domain has none, are now patches of their own (Roger, Jan). - Drop the fail_early label: every cleanup step after fail: is safe before its setup has run (Roger). - free_pervcpu_mappings(): clear the pointer, then free, as XFREE() does (Roger). - Likewise in free_perdomain_mappings(). Changes in v3: - HVM only: PV domains keep the domain-wide area, so the PV parts go (the single-vCPU limit, the shadow refusals, the XPTI slot install). init_xen_l4_slots() takes the vCPU as an extra, optional argument rather than in place of the domain, so PV guest L4s, which no vCPU owns, are promoted exactly as before. - Retitle (was: "x86/mm: introduce per-vCPU L3 page-table"). - free_compat_arg_xlat()'s comment names free_pervcpu_mappings() as the teardown for a vCPU-PT domain. Changes in v2: - Added to the series Changes since the previously posted version: - Expand the commit message with the motivation and the design rationale. - 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. - 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. --- xen/arch/x86/domain.c | 9 +++-- xen/arch/x86/include/asm/domain.h | 4 ++ xen/arch/x86/include/asm/mm.h | 2 + xen/arch/x86/mm.c | 66 +++++++++++++++++++++++-------- 4 files changed, 61 insertions(+), 20 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 94a1ea904a..7a4da203d4 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; if ( !is_idle_domain(d) ) { @@ -523,12 +523,12 @@ int arch_vcpu_create(struct vcpu *v) */ rc = create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, NULL, NULL); if ( rc ) - return rc; + goto fail; paging_vcpu_init(v); if ( (rc = vcpu_init_fpu(v)) != 0 ) - return rc; + goto fail; vmce_init_vcpu(v); @@ -576,6 +576,7 @@ int arch_vcpu_create(struct vcpu *v) vcpu_destroy_fpu(v); xfree(v->arch.msrs); v->arch.msrs = NULL; + free_pervcpu_mappings(v); return rc; } @@ -596,6 +597,8 @@ void arch_vcpu_destroy(struct vcpu *v) pv_vcpu_destroy(v); else ASSERT_UNREACHABLE(); + + free_pervcpu_mappings(v); } int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 12f79feb42..4140a92f15 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -332,6 +332,7 @@ struct monitor_write_data { struct arch_domain { + /* Domain-wide L3 for the per-domain slot; NULL in a vCPU-PT domain. */ struct page_info *perdomain_l3_pg; /* I/O-port admin-specified access capabilities. */ @@ -688,6 +689,9 @@ struct arch_vcpu struct vcpu_msrs *msrs; + /* Per-vCPU L3 for the per-domain slot; NULL in a non-vCPU-PT domain. */ + 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 de45a111f3..12d1c06c12 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -369,6 +369,7 @@ int devalidate_page(struct page_info *page, unsigned long type, int preemptible); void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d); +struct page_info *perdomain_l3(const struct vcpu *v); void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt); bool fill_ro_mpt(mfn_t mfn); @@ -612,6 +613,7 @@ int create_perdomain_mapping(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 ac074cc62d..362a88a300 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1681,6 +1681,18 @@ 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. + */ +struct page_info *perdomain_l3(const struct vcpu *v) +{ + const struct domain *d = v->domain; + + return d->arch.asi.vcpu_pt ? v->arch.pervcpu_l3_pg + : d->arch.perdomain_l3_pg; +} + /* * Fill an L4 with Xen entries. * @@ -1693,7 +1705,8 @@ static int promote_l3_table(struct page_info *page) * extended directmap. * * v is the vCPU the table is private to or, for a table the domain's vCPUs - * share, any of them. + * share, any of them: slot 260 gets v's per-domain area (perdomain_l3()), + * which in a domain whose vCPUs share tables (PV) is the domain-wide one. */ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt) @@ -1726,7 +1739,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) && @@ -6249,7 +6262,7 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va, struct page_info **ppg) { 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; @@ -6258,14 +6271,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.asi.vcpu_pt ) + v->arch.pervcpu_l3_pg = pg; + else + d->arch.perdomain_l3_pg = pg; if ( !nr ) { unmap_domain_page(l3tab); @@ -6275,7 +6291,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))); @@ -6372,16 +6388,16 @@ 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; - 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 ) @@ -6420,16 +6436,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 ) { @@ -6465,8 +6476,29 @@ 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) +{ + struct page_info *l3pg = d->arch.perdomain_l3_pg; + + if ( !l3pg ) + return; + d->arch.perdomain_l3_pg = NULL; + free_perdomain_l3(l3pg); +} + +void free_pervcpu_mappings(struct vcpu *v) +{ + struct page_info *l3pg = v->arch.pervcpu_l3_pg; + + if ( !l3pg ) + return; + + v->arch.pervcpu_l3_pg = NULL; + free_perdomain_l3(l3pg); } static void write_sss_token(unsigned long *ptr) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:51:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:51:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454826.1668355 (Exim 4.92) (envelope-from ) id 1xItOi-00034a-G2; Mon, 19 Oct 2026 19:51:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454826.1668355; Mon, 19 Oct 2026 19:51: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 1xItOi-00034T-Cy; Mon, 19 Oct 2026 19:51:52 +0000 Received: by outflank-mailman (input) for mailman id 1454826; Mon, 19 Oct 2026 19:51:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItOh-00034N-8U for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:51:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xItOg-00FSEh-Lh for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:51:50 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad674c3-2eae-0a2a0a5409dd-0a2a450bcb8e-22 for ; Mon, 19 Oct 2026 21:51:50 +0200 Received: from [52.101.53.3] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad674d3-b7e8-0a2a450b0019-34653503c71d-3 for ; Mon, 19 Oct 2026 21:51:49 +0200 Received: from BL1PR13CA0356.namprd13.prod.outlook.com (2603:10b6:208:2c6::31) by CY8PR12MB7290.namprd12.prod.outlook.com (2603:10b6:930:55::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 19:51:44 +0000 Received: from BN2PEPF000044A5.namprd04.prod.outlook.com (2603:10b6:208:2c6:cafe::87) by BL1PR13CA0356.outlook.office365.com (2603:10b6:208:2c6::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.6 via Frontend Transport; Mon, 19 Oct 2026 19:51:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF000044A5.mail.protection.outlook.com (10.167.243.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 19 Oct 2026 19:51:43 +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.53; Mon, 19 Oct 2026 14:51:44 -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.53; Mon, 19 Oct 2026 14:51:41 -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.53 via Frontend Transport; Mon, 19 Oct 2026 14:51: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=e+QybuNnvA7vFq5hn6kFzny7AIhJbyh8g2qfnQYcz7k1Hs7Ne75zcuOc160PPTFYk764hdadbIrit6RDuZ3ZPHXIrTQxwF9DGOBh4whn3gM8RPg6PZm61y86knJdgc4nIZZUtPIMw1HQPglUs6maUb3N92zBJFgoJyw1bhAF2PD+FLLczfd9aeVAJkSeLB3OcYesXosclYqOXhOxm5TcJEeHmR7AUBB8AWebjDj0J5dZ6K8NuDO/prQjIlt+XAT4ivFdXyRbqKa0y/Hi5syAB1USavETYiEXXzCsfSSqcLGXG00zLYMnc9H5FCW6HHMgruabp7cDAn0TGty0+uvP/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=+IOwPRT727iWCjqizbYfYhkYIQvduRkr7SUFrRvv/88=; b=y/zEPdbqPG845sc0hgSdU38WX41VRU6pkc6WRm8GOVx+/lVi0IXn8ajfN6fjvKqE8vdaZXKLQK4K8FWvYe39J5N2LqhDjK+SGXxivqLlik3kQBznyrEU7f/ZNtzuCCxcSWbm+AudD3LVw8eNFqHBN0t/waOznxzni/CnJKmWPI8Qi8T/p0KV78tluYjtJqCSIFhFOkm98v9Bf91RTTF5G88Xk0aLKcTsndD2kBPTtWOhvoR+So2vSI1GSh0Ctw7eNZ0e4bCwLVDJGZSMcHm+0ZyS7SchLBLAbnks7pwIZTgIztsfiApi8712a4FjKC+aCLZLY/v2odVzzjV2A43q6w== 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=+IOwPRT727iWCjqizbYfYhkYIQvduRkr7SUFrRvv/88=; b=vgYZS1h74ptYPB1au5+zCseu6vk4VsY+vDGRAnIfh47bz/7SkKs+SQoYWm1EUEFB/YB4XrTigmjuWPsgN0eBRJBA/c0MhIAHjXW0Qv4SUHW3JAEJPTkVGKH9c2eKL7Rec+D1g3axiVEISTsm+syfD2ms3DgOlFNXsSQokI6iu+k= 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, 19 Oct 2026 15:46:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/5] vpci: allow queueing of mapping operations To: Mykyta Poturai , "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <14cc4abdcf4c3c3d9a620cf4df3ec87e7b11bd13.1792072426.git.mykyta_poturai@epam.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <14cc4abdcf4c3c3d9a620cf4df3ec87e7b11bd13.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A5:EE_|CY8PR12MB7290:EE_ X-MS-Office365-Filtering-Correlation-Id: 34a9e132-6798-4e4b-a815-08df2e1a66ce X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|36860700016|82310400026|56012099006|11063799006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: Q+PXlVX4mQ60OODVp2Ec//9Ia5lKnD7MOn8hEVVKk6ElJLhJ7GMQ5prpZ3LEdX98j+++sTtG75BRBvFBghJrSgf6uNWVZfeV3JcEbo5QRmztzbpyhusHtK/rEwZ0JTwhH4hDWvjzqMTOciCHlrBJmgQW1P3M7LOTF9w7L0mvht5b3HFS3WmtxkYULHoH0MEpvKaBHajfEVAHY0sSUzQXVJTw10AVAYV/eDvioT5AaqyG1GSOwNjIESuxMJC7CEFXbtgiJ2h8u8mmlx7Rtj4MdixCkB5C08/CRmUwobB926uEVFbawDPgeGBaNbO39fm0afl1/KtDOYqiPi9GZodg2iD5IqCGegPAbwKgqrCkDBptT9hE9iBXczjXaNZKGtuMkAcwih6eTeKJZns08clJo9Madn/mK9W+M7cNoPLQzTRHcuQzPMD7lN5k7ldEjcETh53l1onr8cKaII3wI1UXEvWR3+59xV7qEeSNHUuY0CcgcEScv8jrLat9n3v/rFiFQoEcdN7u+5ZNCG+U4os4ZWOzFiboO8iO/TG+HzxvNwjcUTfbpB+ZOqbzdI6lnEDNv7zC2/vC7zttn8y75eF9VynF8lSb56Cs+O1eyKYxG2yzR5Yk+29AiqCMpjfdymQB9kgig54Wnwy6gnfUlJQ0bbexqSlLlIjANBizUqbJDWAkmF+4HSjdfUXg1Kn4uaTlHQKysbTaGGxVeg/4SDNNIQ== 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)(56012099006)(11063799006)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: v95Dl1cQo5BYfDmhs8p93GdIUdizF2oQdO63HRgRhFpfcq3DAa/LXDOCJtpClO5KzqHpTJ0Eec2DuHT62pSaXOj201ugx7VuU5tkYdJZSMeQ4k9+HrKfvJniEdhGY1D7/1tgzBljww60g7MCOcSt0Yb2qovDddPvXeHHfSv+HwCblZE7GaRmsf15lyiSrCPXNcXBs7dD87WIjxvsORrhN3rrWgFKrha2dLxuSk3Emffq2U07Xg5EoBUeRq3z6XHPEOVO2SYon4zbbt+fiRlE62fSfMMgKM4y0yj92cRZWVJ1XI8yzWrexlBxwW1/ilO93AV94VczVRqu68eeZsgZ6cUyl6bOsHhNX+wQUyZfrggiVEcOA/8fPrWjlA5Z2bjrqkv85BJTKKQnYg8hA4C6EWfM0Fw8DJvAp3cd725F9eCLQmAt3U084U1OdVpD/kMC X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 19:51:43.8312 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 34a9e132-6798-4e4b-a815-08df2e1a66ce 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: BN2PEPF000044A5.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7290 X-purgate-ID: tlsNG-42698a/1792439510-AA8D99EA-E2100490/0/0 X-purgate-type: clean X-purgate-size: 4982 On 2026-10-15 10:08, Mykyta Poturai wrote: > From: Stewart Hildebrand > > Introduce vPCI BAR mapping task queue. Store information needed to > map/unmap BARs in struct vpci_map_task. Allow queueing of BAR map/unmap > operations in a list, thus making it possible to perform multiple p2m > operations associated with single PCI config space register access. > > The rangesets describing the ranges to be (un)mapped move from struct > vpci_bar into the task. They are only live for the duration of the > operation, and a single per-device set cannot describe more than one "per-device rangeset"? > queued operation. Allocate them along with the task and free them once > the task has been processed. > > This is preparatory work for further changes that need to perform > multiple unmap/map operations before returning to guest. > > At the moment, only a single operation will be queued. However, when > multiple operations are queued, there is a check in modify_bars() to > skip BARs already in the requested state that will no longer be > accurate. Remove this check in preparation of upcoming changes. > > Amends: 622bdd962822 ("vpci/header: handle p2m range sets per BAR") > Message-ID: <20260406191203.97662-3-stewart.hildebrand@amd.com> > Signed-off-by: Stewart Hildebrand > Signed-off-by: Mykyta Poturai > @@ -280,12 +321,48 @@ static int __init apply_map(struct domain *d, const struct pci_dev *pdev, > -static void defer_map(const struct pci_dev *pdev, uint16_t cmd, bool rom_only) > +static struct vpci_map_task *alloc_map_task(const struct pci_dev *pdev, > + uint16_t cmd, bool rom_only) > +{ > + struct vpci_map_task *task; > + unsigned int i; > + > + task = xvzalloc(struct vpci_map_task); > + Nit: No newline needed here. > + if ( !task ) > + return NULL; > + > + for ( i = 0; i < ARRAY_SIZE(task->bars); i++ ) > + { > + if ( !MAPPABLE_BAR(&pdev->vpci->header.bars[i]) ) > + continue; > + > + task->bars[i].mem = rangeset_new(pdev->domain, NULL, > + RANGESETF_no_print); > + Nit: Extra newline. > + if ( !task->bars[i].mem ) > + { > + destroy_map_task(task); > + return NULL; > + } > + > + task->bars[i].addr = pdev->vpci->header.bars[i].addr; > + task->bars[i].guest_addr = pdev->vpci->header.bars[i].guest_addr; > + } > + > + task->cmd = cmd; > + task->rom_only = rom_only; > + task->pdev = pdev; > + > + return task; > +} > + > +static void defer_map(struct vpci_map_task *task) > { > struct vcpu *curr = current; > > @@ -312,11 +388,17 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only) > struct pci_dev *tmp; > const struct domain *d; > const struct vpci_msix *msix = pdev->vpci->msix; > + struct vpci_map_task *task; > unsigned int i, j; > int rc; > > ASSERT(rw_is_write_locked(&pdev->domain->pci_lock)); > > + task = alloc_map_task(pdev, cmd, rom_only); > + Nit: Extra newline > + if ( !task ) > + return -ENOMEM; > + > /* > * Create a rangeset per BAR that represents the current device memory > * region and compare it against all the currently active BAR memory > @@ -343,9 +425,7 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only) > > if ( !MAPPABLE_BAR(bar) || > (rom_only ? bar->type != VPCI_BAR_ROM > - : (bar->type == VPCI_BAR_ROM && !header->rom_enabled)) || > - /* Skip BARs already in the requested state. */ > - bar->enabled == !!(cmd & PCI_COMMAND_MEMORY) ) This is the removed check mentioned in the commit message? And the reason is that a queue of operation 1 unmap, operation 2 map needs to be processed sequentially, but cmd won't be changing? > + : (bar->type == VPCI_BAR_ROM && !header->rom_enabled)) ) > continue; > > if ( !pci_check_bar(pdev, _mfn(start), _mfn(end)) ) > @@ -152,14 +153,24 @@ struct vpci { > #endif > }; > > -struct vpci_vcpu { > +#ifdef __XEN__ > +struct vpci_map_task { > /* Per-vcpu structure to store state while {un}mapping of PCI BARs. */ > - const struct pci_dev *pdev; > + struct list_head next; > + struct vpci_bar_map { > + uint64_t addr; > + uint64_t guest_addr; > + struct rangeset *mem; > + } bars[ARRAY_SIZE(((struct vpci_header *)NULL)->bars)]; > uint16_t cmd; > bool rom_only : 1; > + const struct pci_dev *pdev; Is there a reason to move this pointer? You introduce a hole in the structure before it. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454833.1668368 (Exim 4.92) (envelope-from ) id 1xItS1-0003kX-8K; Mon, 19 Oct 2026 19:55:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454833.1668368; Mon, 19 Oct 2026 19:55: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 1xItS1-0003jh-3l; Mon, 19 Oct 2026 19:55:17 +0000 Received: by outflank-mailman (input) for mailman id 1454833; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003h2-G4 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022ye-2VeB; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGb-00000001FjN-30XF; Mon, 19 Oct 2026 19:43: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" 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=YJ9wJhjNHJbAx4M8lq+zFhKHnsHGMBHNIuKf/lCuqCk=; b=BgWdGlmdhVDUHGYylgeoPeXSIs Nx77inNA4dmlcPbdTS7wsw5kodnAtP1BuGoXVHF7zfgBa1ZifTis9zCQ6f8ur+//juvwNquuooEiE wnDd3BMZproA3oEpYLj4eKSVcvydfT/OEGo7oeAOkXvpHjC18CmFeno7ZaPejszCLfrc=; 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?= , Teddy Astie Subject: [PATCH v4 14/30] x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains Date: Mon, 19 Oct 2026 20:42:45 +0100 Message-ID: <20261019-asi-hvm-v4-14-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Add a struct mapcache to struct mapcache_vcpu for the per-vCPU accounting, with MAPCACHE_PERVCPU_ENTRIES (64) slots. Its inuse and garbage bitmaps are then an unsigned long each: declare them inline in struct mapcache_vcpu, rather than mapping them in the per-domain area as the domain-wide bitmaps are. A per-vCPU mapcache is only ever used by its own vCPU, and so by one pCPU at a time. We can therefore skip both the lock and the TLB-epoch tracking the domain-wide mapcache needs; a wrap still flushes the local TLB. struct mapcache_vcpu grows from 136 to 176 bytes, and struct vcpu from 3008 to 3072 bytes (x86_64, debug build), within its page. Unlike a domain-wide mapcache, a per-vCPU one cannot, by design, borrow slots from other vCPUs: MAPCACHE_PERVCPU_ENTRIES (64) is the most single-page mappings such a vCPU can hold at once, interrupt handlers' included, and one more hits the BUG_ON() in map_domain_page(). The PoD zero-page sweep held up to 16 on top of its callers' until "x86/PoD: map one page at a time in p2m_pod_zero_check()". A domain-wide mapcache keeps MAPCACHE_VCPU_ENTRIES (16) slots per vCPU; a per-vCPU one gets 64, for a wider margin. The extra slots take no memory: the area is a whole L1 page whatever the number of slots, and each bitmap is still one unsigned long. Wraps, each of which flushes the local TLB, also come less often. mapcache_current_vcpu()'s lazy-context-switch handling (sync_local_execstate() plus a pgtable_vcpu re-read) now applies to any vCPU with a mapcache: when the idle vCPU runs lazily on an HVM vCPU's monitor table, the full switch happens before the idle context uses a mapcache. In release builds map_domain_page() still tries the directmap first, for any vCPU; debug builds exercise the new mapcache. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - d->arch.vcpu_pt is now d->arch.asi.vcpu_pt. - mapcache_lock() / mapcache_unlock() are now mapcache_enter() / mapcache_exit(). has_mapcache()'s comment no longer changes, and the early return in mapcache_enter() has a one-line comment instead of a sentence added to the block (Roger). - mapcache_vcpu_init(): ents and nr become assignments here, ents now depending on the kind of mapcache (Jan). - A per-vCPU mapcache gets 64 slots (MAPCACHE_PERVCPU_ENTRIES) in place of MAPCACHE_VCPU_ENTRIES (16), which still sizes the domain-wide mapcache; its bitmaps, now full, are described as an unsigned long each (Roger). - Move the comment on why a per-vCPU mapcache needs only a local flush from map_domain_page()'s TLB flush to mapcache_new_epoch()'s early return, as one line (Roger). Changes in v3: - HVM only, and per-vCPU from the start: the HVM enablement of "x86: Initialize the mapcache for PV, HVM, and idle domains" (from the directmap removal series) is folded in, without the idle domain and without a domain-wide HVM mapcache. - Retitle (was: "x86/mm: introduce a per-vCPU mapcache when using ASI"). - Say which second unmaps the not-present check in unmap_domain_page() catches: those of an entry the first unmap zapped. - State the budget of single-page mappings a vCPU can hold at once. - The mapcache accounting refactor, the move of struct mapcache_vcpu to struct arch_vcpu and the not-present check in unmap_domain_page() are split out, for review, into the three patches before this one. --- xen/arch/x86/domain_page.c | 61 +++++++++++++++++++++++-------- xen/arch/x86/include/asm/config.h | 2 + xen/arch/x86/include/asm/domain.h | 6 +++ 3 files changed, 53 insertions(+), 16 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 47ccefa4e9..770fee80a4 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -21,7 +21,7 @@ /* Whether the vCPU supports mapcache usage, might not be in use. */ static bool has_mapcache(const struct vcpu *v) { - return is_pv_vcpu(v); + return is_pv_vcpu(v) || v->domain->arch.asi.vcpu_pt; } static inline struct vcpu *mapcache_current_vcpu(void) @@ -34,10 +34,10 @@ static inline struct vcpu *mapcache_current_vcpu(void) return NULL; /* - * If we are in a lazy context-switch state from a PV vCPU do a full switch - * 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. + * If we are in a lazy context-switch state from a vCPU with a mapcache do + * a full switch to the idle vCPU now, otherwise an incoming + * FLUSH_VCPU_STATE IPI would change the page tables under our feet and + * invalidate any in-use mapcache entries. */ if ( unlikely(this_cpu(curr_vcpu) != curr) ) { @@ -57,14 +57,21 @@ static inline struct vcpu *mapcache_current_vcpu(void) } /* - * The accounting for v's mapcache: the domain's, with *dcache set so the - * caller takes the domain-wide lock and TLB-epoch machinery into account. + * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's + * otherwise, in which case *dcache is set so the caller takes the domain-wide + * lock and TLB-epoch machinery into account. */ static struct mapcache *vcpu_mapcache(struct vcpu *v, struct mapcache_domain **dcache) { struct domain *d = v->domain; + if ( d->arch.asi.vcpu_pt ) + { + *dcache = NULL; + return &v->arch.mapcache.cache; + } + *dcache = &d->arch.pv.mapcache; return &(*dcache)->cache; } @@ -72,6 +79,10 @@ static struct mapcache *vcpu_mapcache(struct vcpu *v, static void mapcache_enter(struct mapcache_domain *dcache, struct mapcache_vcpu *vcache) { + /* Only its own vCPU uses a per-vCPU mapcache: no lock or epoch needed. */ + if ( !dcache ) + return; + /* The domain's vCPUs share the mapcache's slots. */ spin_lock(&dcache->lock); @@ -91,6 +102,10 @@ static void mapcache_enter(struct mapcache_domain *dcache, static void mapcache_new_epoch(struct mapcache_domain *dcache, struct mapcache_vcpu *vcache) { + /* Per-vCPU: no epoch, as page-table loads flush its non-global entries. */ + if ( !dcache ) + return; + ASSERT(spin_is_locked(&dcache->lock)); vcache->shadow_epoch = ++dcache->epoch; @@ -99,7 +114,8 @@ static void mapcache_new_epoch(struct mapcache_domain *dcache, static void mapcache_exit(struct mapcache_domain *dcache) { - spin_unlock(&dcache->lock); + if ( dcache ) + spin_unlock(&dcache->lock); } #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) @@ -299,15 +315,25 @@ int mapcache_vcpu_init(struct vcpu *v) struct mapcache_domain *dcache; struct mapcache *cache; unsigned long i; - unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; - unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); + unsigned int ents, nr; if ( !has_mapcache(v) ) return 0; cache = vcpu_mapcache(v, &dcache); - if ( !cache->inuse ) + if ( !dcache ) + { + /* Per-vCPU bitmaps are an unsigned long each, in the vCPU itself. */ + cache->inuse = v->arch.mapcache.inuse; + cache->garbage = v->arch.mapcache.garbage; + ents = MAPCACHE_PERVCPU_ENTRIES; + } + else if ( !cache->inuse ) return 0; + else + ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; + + nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); if ( ents > cache->entries ) { @@ -315,13 +341,16 @@ int mapcache_vcpu_init(struct vcpu *v) int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, NIL(l1_pgentry_t *), NULL); - /* Populate bit maps. */ - if ( !rc ) + /* Populate the domain-wide bit maps (kept in the per-domain area). */ + if ( !rc && dcache ) + { rc = create_perdomain_mapping(v, (unsigned long)cache->inuse, nr, NULL, NIL(struct page_info *)); - if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, - nr, NULL, NIL(struct page_info *)); + if ( !rc ) + rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, + nr, NULL, + NIL(struct page_info *)); + } if ( rc ) return rc; diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index aebd3e8f45..ee84c57432 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -279,6 +279,8 @@ extern unsigned long xen_phys_start; /* map_domain_page() map cache. The second per-domain-mapping sub-area. */ #define MAPCACHE_VCPU_ENTRIES (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEVELS) +/* Single-page slots of a per-vCPU mapcache (vCPU-PT domains). */ +#define MAPCACHE_PERVCPU_ENTRIES 64 #define MAPCACHE_ENTRIES (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES) #define MAPCACHE_VIRT_START PERDOMAIN_VIRT_SLOT(1) #define MAPCACHE_VIRT_END (MAPCACHE_VIRT_START + \ diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 45d308407e..7076e38848 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -80,6 +80,12 @@ struct mapcache_vcpu { uint32_t idx; uint32_t refcnt; } hash[MAPHASH_ENTRIES]; + + /* Accounting of a per-vCPU mapcache (vCPU-PT domains). */ + struct mapcache cache; + /* Backing for cache.{inuse,garbage}. */ + DECLARE_BITMAP(inuse, MAPCACHE_PERVCPU_ENTRIES); + DECLARE_BITMAP(garbage, MAPCACHE_PERVCPU_ENTRIES); }; struct mapcache_domain { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454836.1668385 (Exim 4.92) (envelope-from ) id 1xItS2-00043n-2k; Mon, 19 Oct 2026 19:55:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454836.1668385; Mon, 19 Oct 2026 19:55: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 1xItS1-000411-TQ; Mon, 19 Oct 2026 19:55:17 +0000 Received: by outflank-mailman (input) for mailman id 1454836; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003h9-Gp for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yU-29Zu; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGh-00000001FjN-0TMy; Mon, 19 Oct 2026 19: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" 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=LBUz4QCpPQtpmzUBSklZ+EZWcdBElnumvszUFYusF9k=; b=1rtHKqxdhSBzVicd7dD6yPpiul ELjFZ39fJpxFwN61r3SRdlfEgYrIREVUShAshyHO3gBkIVHIYENnN4NzC2H3IBkOnOfAaw0ULMa03 aXhWzl0RZk0U546ZweI0/n0yUYZWXgPE+E5xujFIOtGxhaTvP0FgWiVKYwIvfmgH/nhQ=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 19/30] x86/mm: run guest contexts on the sparse directmap view Date: Mon, 19 Oct 2026 20:42:50 +0100 Message-ID: <20261019-asi-hvm-v4-19-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In init_xen_l4_slots(), if d->arch.asi.sparse_dmap is set, point the directmap slots at the sparse view, copying from idle_pg_table only the Xen slots below them. A root page-table not shared with a PV guest gets no extended directmap, which the sparse view does not cover. d->arch.asi.sparse_dmap is decided at domain creation: PV domains all have a mapcache, HVM domains need per-vCPU page-tables for one. No option asks for the sparse view yet. The sparse view is built before any domain is created, so the root page-tables of every domain using it carry it from their creation, dom0's included. Dom0's builders reach dom0's memory only through guest virtual addresses and map_domain_page(). In PV shim mode, replace_va_mapping() reads the guest's L4 through the directmap; map it with map_domain_page() instead, as the lower levels already are. Shadow L4s, dom0=shadow's included, get the sparse view from init_xen_l4_slots(). The two directmaps differ where the sparse view leaves memory out, so no translation of the full directmap may remain usable on page-tables carrying the sparse view. Directmap mappings stay global nevertheless: every CR3 write which can move a CPU onto the sparse view goes through switch_cr3_cr4(), which flushes the old page-tables' translations, global entries included, before it returns. The CR3 writes which keep entries -- a PV vCPU's switch between its kernel and user page-tables, XPTI's entry and exit -- stay within one vCPU's page-tables, which carry the same directmap, or go to XPTI's per-CPU root, which maps only Xen's own per-CPU pages there. Removals from the sparse view are flushed on every CPU, global entries included. PV guests running with global pages, a PV dom0 not using the sparse view among them, so keep their directmap TLB entries across switches between guest kernel and user mode. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - d->arch.vcpu_pt and d->arch.sparse_dmap are now d->arch.asi.vcpu_pt and d->arch.asi.sparse_dmap. - Drop sparse_dmap_active and sparse_dmap_activate(): root page-tables carry the sparse view from their creation, dom0's included (Roger). - The sparse view's slots are now marked NX in "x86/mm: build and maintain a sparse view of the directmap". - PV shim: replace_va_mapping() maps the guest's L4 with map_domain_page(). - Give sparse_dmap_wanted() its hardware-domain case (Roger). - init_xen_l4_slots() takes the directmap slots from the sparse view, rather than copying the full directmap's and overwriting them; sparse_dmap_install() goes (Roger). - Message: drop the sentence on NX (Roger). Changes in v3: - New in this version. --- xen/arch/x86/include/asm/sparse-directmap.h | 9 +++++++ xen/arch/x86/mm.c | 28 +++++++++++++++++++-- xen/arch/x86/pv/shim.c | 4 ++- xen/arch/x86/spec_ctrl.c | 7 ++++++ 4 files changed, 45 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index ea14d44334..2f8b94f4c1 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -31,6 +31,14 @@ static inline bool sparse_dmap_configured(void) return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; } +/* Whether a new domain of the given type is to use the sparse view. */ +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) +{ + return sparse_dmap_root && + (hwdom ? opt_sparse_dmap_hwdom + : pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); +} + void sparse_dmap_init(void); int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags); @@ -42,6 +50,7 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); #else /* !CONFIG_SPARSE_DIRECTMAP */ static inline bool sparse_dmap_configured(void) { return false; } +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { return false; } static inline void sparse_dmap_init(void) {} static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 7e3009251c..7b5a355e6e 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1703,7 +1703,8 @@ struct page_info *perdomain_l3(const struct vcpu *v) * 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. + * extended directmap, unless the domain runs on the sparse view of the + * directmap, which replaces the directmap slots. * * v is the vCPU the table is private to or, for a table the domain's vCPUs * share, any of them: slot 260 gets v's per-domain area (perdomain_l3()), @@ -1715,7 +1716,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, const struct domain *d = v->domain; /* * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full - * directmap. + * directmap, unless the domain runs on the sparse view (below). */ bool short_directmap = !paging_mode_external(d); @@ -1750,6 +1751,29 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, l4t[l4_table_offset(PERDOMAIN_VIRT_START)]; /* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */ +#ifdef CONFIG_SPARSE_DIRECTMAP + if ( d->arch.asi.sparse_dmap ) + { + unsigned int i = l4_table_offset(SPARSE_DMAP_START); + + memcpy(&l4t[l4_table_offset(XEN_VIRT_START)], + &idle_pg_table[l4_table_offset(XEN_VIRT_START)], + (i - l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); + + /* + * Every slot the sparse view covers gets its L3, whatever the full + * directmap has there, so that memory added later is covered too. A + * PV root has guest slots above; any other root loses the rest of the + * directmap, which the sparse view does not cover. + */ + for ( ; i < l4_table_offset(SPARSE_DMAP_END); i++ ) + l4t[i] = sparse_dmap_root[i]; + if ( !short_directmap ) + for ( ; i < l4_table_offset(DIRECTMAP_VIRT_END); i++ ) + l4t[i] = l4e_empty(); + } + else +#endif #ifndef NDEBUG if ( short_directmap && unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) ) diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c index 41000b0523..2a47dbc56c 100644 --- a/xen/arch/x86/pv/shim.c +++ b/xen/arch/x86/pv/shim.c @@ -148,12 +148,14 @@ const struct platform_bad_page *__init pv_shim_reserved_pages(unsigned int *size static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start, unsigned long va, mfn_t mfn) { - l4_pgentry_t l4e = l4start[l4_table_offset(va)]; + const l4_pgentry_t *l4t = map_domain_page(virt_to_mfn(l4start)); + l4_pgentry_t l4e = l4t[l4_table_offset(va)]; l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va)); l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va)); l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) + l1_table_offset(va); struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e)); + unmap_domain_page(l4t); put_page_and_type(page); *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 66c878212a..32e6ba28a3 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -1943,6 +1943,13 @@ void spec_ctrl_init_domain(struct domain *d) d->arch.asi.vcpu_pt = !pv && (is_hardware_domain(d) ? opt_pvh_vcpu_pt_hwdom : opt_vcpu_pt_hvm); + + /* + * The sparse directmap view needs a mapcache: PV domains all have one, + * HVM domains through per-vCPU page-tables. + */ + d->arch.asi.sparse_dmap = (pv || d->arch.asi.vcpu_pt) && + sparse_dmap_wanted(pv, is_hardware_domain(d)); } void __init init_speculation_mitigations(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454832.1668363 (Exim 4.92) (envelope-from ) id 1xItS1-0003id-0Y; Mon, 19 Oct 2026 19:55:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454832.1668363; Mon, 19 Oct 2026 19:55: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 1xItS0-0003iV-TN; Mon, 19 Oct 2026 19:55:16 +0000 Received: by outflank-mailman (input) for mailman id 1454832; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003gx-Dv for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yS-21Dl; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGa-00000001FjN-2f7h; Mon, 19 Oct 2026 19:43: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=zn3ZcHMMfyhR8QfM5FyYpbEc+e7vY+aEPBv+DrQrlkY=; b=2sgViO0fKh8kn3LpCSBTEwx3AA gGriFuMiDcxcPGIN/f1nBNOGEW3nC5kPFCO8oTfUgQpHMdnhG9CVfKy0j9F0Ixx4ZL8pBDB42n2JZ WjruUnICtjothAFkN1q3G3+mQWxr2UxiS9EABKYJshar6Yfa1IU0ht/52zhOzpcbe2ME=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v4 13/30] x86/domain_page: don't unmap a mapcache entry that is not present Date: Mon, 19 Oct 2026 20:42:44 +0100 Message-ID: <20261019-asi-hvm-v4-13-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mappings must be torn down by the vCPU that created them, and only once. Have unmap_domain_page() check that the entry it is handed is present and bail out otherwise (ASSERT_UNREACHABLE()), rather than read an MFN out of an empty PTE and act on it, as a second unmap of an entry the first one zapped would. (A second unmap of an entry the maphash kept is caught, as before, only by the refcount ASSERT() in debug builds.) Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v4: - Reword the comment on the new check (Roger). Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 205d7b832a..47ccefa4e9 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -223,6 +223,15 @@ void unmap_domain_page(const void *ptr) ASSERT(cache->inuse); idx = PFN_DOWN(va - MAPCACHE_VIRT_START); + /* + * Sanity check: an entry that isn't present means a double or stray + * unmap. Play it safe: don't act on the MFN in an empty PTE. + */ + if ( !(l1e_get_flags(MAPCACHE_L1ENT(idx)) & _PAGE_PRESENT) ) + { + ASSERT_UNREACHABLE(); + return; + } mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)]; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454834.1668379 (Exim 4.92) (envelope-from ) id 1xItS1-0003up-NW; Mon, 19 Oct 2026 19:55:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454834.1668379; Mon, 19 Oct 2026 19:55: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 1xItS1-0003uH-Jc; Mon, 19 Oct 2026 19:55:17 +0000 Received: by outflank-mailman (input) for mailman id 1454834; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003h4-GU for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yY-2Nbo; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGo-00000001FjN-0HBF; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=Mu6k2BaQFLQ9iQqejDHFz+H+XwqcF1BQPCpuR3LOvj4=; b=5N/xWK8vMsxKqNS9s6OwGEgY51 MC+3dNN4OKtNXIg8kOVNPuXk36+PnCEYA1CYZibi8pVs/YneAZZoNLCMxZX5RQnU6TE/PNKfwHsBb iJwqjOUfuId4Y2CCvd5Mj6fW2wYbXHGuZ/RmN/WS5rN2sY4jQkBcIM8mojak2DtPXJPg=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v4 25/30] x86/svm: introduce svm_vmcb_map() and svm_vmcb_unmap() Date: Mon, 19 Oct 2026 20:42:56 +0100 Message-ID: <20261019-asi-hvm-v4-25-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some accessors of a vCPU's VMCB can run with that vCPU paused, from another vCPU's context: context save/load, the segment and CPL getters, PAT/TSC/intercept updates reachable from toolstack operations, vm_event, the 'v' debug key, and construct_vmcb() itself, which runs before the vCPU ever entered guest context. svm_nested_features_on_efer_update() is among them: it is reachable remotely via hvm_load_cpu_ctxt() -> svm_update_guest_efer(). Route them through new svm_vmcb_map/unmap helpers; construct_vmcb() takes the VMCB from its caller. svm_set_tsc_offset() needs both VMCBs rather than just the active one, so it maps them individually via svm_vmcb_map_one(). A vCPU stays in nested guest mode across a deschedule or a pause, so this path can run remotely with the L2 VMCB active; guest mode does not imply v == current. Hot vmexit-path accesses all have v == current and keep dereferencing svm->vmcb directly. No functional change: the helpers return the VMCB's existing address. They prepare for moving VMCBs off always-mapped memory, where a VMCB's mapping is valid only in its own vCPU's context. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/nestedsvm.c | 4 +- xen/arch/x86/hvm/svm/svm.c | 133 +++++++++++++++++++++++-------- xen/arch/x86/hvm/svm/vmcb.c | 29 ++++++- xen/arch/x86/hvm/svm/vmcb.h | 9 +++ 4 files changed, 136 insertions(+), 39 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 2b998e26bc..dc853e5f1a 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1554,7 +1554,7 @@ 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 vmcb_struct *vmcb = svm_vmcb_map(v); struct nestedsvm *svm = &vcpu_nestedsvm(v); u32 general2_intercepts; vintr_t vintr; @@ -1612,6 +1612,8 @@ void svm_nested_features_on_efer_update(struct vcpu *v) vmcb_set_general2_intercepts(vmcb, general2_intercepts); } } + + svm_vmcb_unmap(v, vmcb); } void __init start_nested_svm(struct hvm_function_table *hvm_function_table) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f2..241843d8c0 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -107,7 +107,7 @@ static void cf_check svm_cpu_down(void) static void cf_check svm_update_guest_cr( struct vcpu *v, unsigned int cr, unsigned int flags) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); uint64_t value; switch ( cr ) @@ -173,11 +173,13 @@ static void cf_check svm_update_guest_cr( default: BUG(); } + + svm_vmcb_unmap(v, vmcb); } static void cf_check svm_update_guest_efer(struct vcpu *v) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); unsigned long guest_efer = v->arch.hvm.guest_efer, xen_efer = read_efer(); @@ -204,6 +206,7 @@ static void cf_check svm_update_guest_efer(struct vcpu *v) guest_efer |= EFER_SVME; vmcb_set_efer(vmcb, guest_efer); + svm_vmcb_unmap(v, vmcb); ASSERT(nestedhvm_enabled(v->domain) || !nsvm_efer_svm_enabled(v)); @@ -352,7 +355,7 @@ static void svm_restore_dr(struct vcpu *v) static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); if ( vmcb->event_inj.v && hvm_event_needs_reinjection(vmcb->event_inj.type, @@ -362,13 +365,15 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c) c->error_code = vmcb->event_inj.ec; } + svm_vmcb_unmap(v, vmcb); + return 1; } static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) { struct page_info *page = NULL; - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb; struct p2m_domain *p2m = p2m_get_hostp2m(v->domain); if ( c->pending_valid ) @@ -417,6 +422,8 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) svm_update_guest_cr(v, 0, 0); svm_update_guest_cr(v, 4, 0); + vmcb = svm_vmcb_map(v); + if ( !paging_mode_shadow(v->domain) ) { vmcb_set_np(vmcb, true); @@ -436,6 +443,8 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) vmcb->event_inj.raw = 0; vmcb->cleanbits.raw = 0; + svm_vmcb_unmap(v, vmcb); + paging_update_paging_modes(v); return 0; @@ -443,7 +452,7 @@ 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; + const struct vmcb_struct *vmcb = svm_vmcb_map(v); data->sysenter_cs = vmcb->sysenter_cs; data->sysenter_esp = vmcb->sysenter_esp; @@ -453,11 +462,13 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) data->msr_star = vmcb->star; data->msr_cstar = vmcb->cstar; data->msr_syscall_mask = vmcb->sfmask; + + svm_vmcb_unmap(v, vmcb); } 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 *vmcb = svm_vmcb_map(v); vmcb->lstar = data->msr_lstar; vmcb->star = data->msr_star; @@ -467,6 +478,9 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) vmcb->sysenter_cs = data->sysenter_cs; vmcb->sysenter_esp = data->sysenter_esp; vmcb->sysenter_eip = data->sysenter_eip; + + svm_vmcb_unmap(v, vmcb); + v->arch.hvm.guest_efer = data->msr_efer; svm_update_guest_efer(v); } @@ -492,7 +506,7 @@ static int cf_check svm_load_vmcb_ctxt(struct vcpu *v, struct hvm_hw_cpu *ctxt) static unsigned cf_check int svm_get_interrupt_shadow(struct vcpu *v) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); unsigned int intr_shadow = 0; if ( vmcb->int_stat.intr_shadow ) @@ -503,13 +517,15 @@ static unsigned cf_check int svm_get_interrupt_shadow(struct vcpu *v) : (vmcb_get_general1_intercepts(vmcb) & GENERAL1_INTERCEPT_IRET) ) intr_shadow |= HVM_INTR_SHADOW_NMI; + svm_vmcb_unmap(v, vmcb); + return intr_shadow; } static void cf_check svm_set_interrupt_shadow( struct vcpu *v, unsigned int intr_shadow) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); bool block_nmi = intr_shadow & HVM_INTR_SHADOW_NMI; vmcb->int_stat.intr_shadow = @@ -527,10 +543,13 @@ static void cf_check svm_set_interrupt_shadow( vmcb_set_general1_intercepts(vmcb, gen1); } + + svm_vmcb_unmap(v, vmcb); } static int cf_check svm_guest_x86_mode(struct vcpu *v) { + /* Current only (see guest_cpu_user_regs() below): no mapping needed. */ struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; if ( unlikely(!(v->arch.hvm.guest_cr[0] & X86_CR0_PE)) ) @@ -544,8 +563,7 @@ static int cf_check svm_guest_x86_mode(struct vcpu *v) static void cf_check svm_cpuid_policy_changed(struct vcpu *v) { - struct svm_vcpu *svm = &v->arch.hvm.svm; - struct vmcb_struct *vmcb = svm->vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); const struct cpu_policy *cp = v->domain->arch.cpu_policy; u32 bitmap = vmcb_get_exception_intercepts(vmcb); @@ -555,6 +573,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v) bitmap &= ~(1U << X86_EXC_UD); vmcb_set_exception_intercepts(vmcb, bitmap); + svm_vmcb_unmap(v, vmcb); /* Give access to MSR_SPEC_CTRL if the guest has been told about it. */ svm_intercept_msr(v, MSR_SPEC_CTRL, @@ -598,13 +617,18 @@ void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) static unsigned int cf_check svm_get_cpl(struct vcpu *v) { - return vmcb_get_cpl(v->arch.hvm.svm.vmcb); + const struct vmcb_struct *vmcb = svm_vmcb_map(v); + unsigned int cpl = vmcb_get_cpl(vmcb); + + svm_vmcb_unmap(v, vmcb); + + return cpl; } 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 *vmcb = svm_vmcb_map(v); ASSERT((v == current) || !vcpu_runnable(v)); @@ -645,12 +669,14 @@ static void cf_check svm_get_segment_register( *reg = (struct segment_register){}; break; } + + svm_vmcb_unmap(v, vmcb); } 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 *vmcb = svm_vmcb_map(v); ASSERT((v == current) || !vcpu_runnable(v)); @@ -679,6 +705,7 @@ static void cf_check svm_set_segment_register( default: ASSERT_UNREACHABLE(); domain_crash(v->domain); + svm_vmcb_unmap(v, vmcb); return; } @@ -716,33 +743,41 @@ static void cf_check svm_set_segment_register( ASSERT_UNREACHABLE(); break; } + + svm_vmcb_unmap(v, vmcb); } static int cf_check svm_set_guest_pat(struct vcpu *v, u64 gpat) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb; if ( paging_mode_shadow(v->domain) ) return 0; + vmcb = svm_vmcb_map(v); vmcb_set_g_pat(vmcb, gpat); + svm_vmcb_unmap(v, vmcb); + return 1; } static int cf_check svm_get_guest_pat(struct vcpu *v, u64 *gpat) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + const struct vmcb_struct *vmcb; if ( paging_mode_shadow(v->domain) ) return 0; + vmcb = svm_vmcb_map(v); *gpat = vmcb_get_g_pat(vmcb); + svm_vmcb_unmap(v, vmcb); + return 1; } static void cf_check svm_set_tsc_offset(struct vcpu *v, uint64_t offset) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); struct vmcb_struct *n1vmcb, *n2vmcb; uint64_t n2_tsc_offset = 0; struct domain *d = v->domain; @@ -750,25 +785,36 @@ static void cf_check svm_set_tsc_offset(struct vcpu *v, uint64_t offset) if ( !nestedhvm_enabled(d) ) { vmcb_set_tsc_offset(vmcb, offset); + svm_vmcb_unmap(v, vmcb); return; } - n1vmcb = vcpu_nestedhvm(v).nv_n1vmcx; - n2vmcb = vcpu_nestedhvm(v).nv_n2vmcx; - + /* + * A vCPU stays in nested guest mode across a deschedule or a pause, so + * this can run remotely with the L2 VMCB active: map both explicitly. + */ if ( nestedhvm_vcpu_in_guestmode(v) ) { + const struct nestedvcpu *nv = &vcpu_nestedhvm(v); + + n1vmcb = svm_vmcb_map_one(v, nv->nv_n1vmcx, nv->nv_n1vmcx_pa); + n2vmcb = svm_vmcb_map_one(v, nv->nv_n2vmcx, nv->nv_n2vmcx_pa); + n2_tsc_offset = vmcb_get_tsc_offset(n2vmcb) - vmcb_get_tsc_offset(n1vmcb); vmcb_set_tsc_offset(n1vmcb, offset); + + svm_vmcb_unmap(v, n2vmcb); + svm_vmcb_unmap(v, n1vmcb); } vmcb_set_tsc_offset(vmcb, offset + n2_tsc_offset); + svm_vmcb_unmap(v, vmcb); } static void cf_check svm_set_rdtsc_exiting(struct vcpu *v, bool enable) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb); u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb); @@ -783,13 +829,14 @@ static void cf_check svm_set_rdtsc_exiting(struct vcpu *v, bool enable) vmcb_set_general1_intercepts(vmcb, general1_intercepts); vmcb_set_general2_intercepts(vmcb, general2_intercepts); + svm_vmcb_unmap(v, vmcb); } #ifdef CONFIG_VM_EVENT static void cf_check svm_set_descriptor_access_exiting( struct vcpu *v, bool enable) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb); u32 mask = GENERAL1_INTERCEPT_IDTR_READ | GENERAL1_INTERCEPT_GDTR_READ | GENERAL1_INTERCEPT_LDTR_READ | GENERAL1_INTERCEPT_TR_READ @@ -802,6 +849,7 @@ static void cf_check svm_set_descriptor_access_exiting( general1_intercepts &= ~mask; vmcb_set_general1_intercepts(vmcb, general1_intercepts); + svm_vmcb_unmap(v, vmcb); } #endif /* CONFIG_VM_EVENT */ @@ -1360,7 +1408,12 @@ static void cf_check svm_inject_event(const struct x86_event *event) static bool cf_check svm_event_pending(const struct vcpu *v) { - return v->arch.hvm.svm.vmcb->event_inj.v; + const struct vmcb_struct *vmcb = svm_vmcb_map(v); + bool pending = vmcb->event_inj.v; + + svm_vmcb_unmap(v, vmcb); + + return pending; } static void cf_check svm_cpu_dead(unsigned int cpu) @@ -2318,45 +2371,55 @@ static void cf_check svm_invlpg(struct vcpu *v, unsigned long linear) static bool cf_check svm_get_pending_event( struct vcpu *v, struct x86_event *info) { - const struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + const struct vmcb_struct *vmcb = svm_vmcb_map(v); + bool pending = vmcb->event_inj.v; - if ( !vmcb->event_inj.v ) - return false; + if ( pending ) + { + info->vector = vmcb->event_inj.vector; + info->type = vmcb->event_inj.type; + info->error_code = vmcb->event_inj.ec; + } - info->vector = vmcb->event_inj.vector; - info->type = vmcb->event_inj.type; - info->error_code = vmcb->event_inj.ec; + svm_vmcb_unmap(v, vmcb); - return true; + return pending; } static uint64_t cf_check svm_get_reg(struct vcpu *v, unsigned int reg) { struct vcpu *curr = current; - const struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + const struct vmcb_struct *vmcb = svm_vmcb_map(v); struct domain *d = v->domain; + uint64_t val = 0; switch ( reg ) { case MSR_SPEC_CTRL: - return vmcb->spec_ctrl; + val = vmcb->spec_ctrl; + break; case MSR_SHADOW_GS_BASE: if ( v == curr ) svm_sync_vmcb(v, vmcb_in_sync); - return vmcb->kerngsbase; + val = vmcb->kerngsbase; + break; default: printk(XENLOG_G_ERR "%s(%pv, 0x%08x) Bad register\n", __func__, v, reg); domain_crash(d); - return 0; + break; } + + svm_vmcb_unmap(v, vmcb); + + return val; } static void cf_check svm_set_reg(struct vcpu *v, unsigned int reg, uint64_t val) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = svm_vmcb_map(v); struct domain *d = v->domain; switch ( reg ) @@ -2371,6 +2434,8 @@ static void cf_check svm_set_reg(struct vcpu *v, unsigned int reg, uint64_t val) domain_crash(d); break; } + + svm_vmcb_unmap(v, vmcb); } static struct hvm_function_table __initdata_cf_clobber svm_function_table = { diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index a6f09672a7..4c48bbc76d 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -43,11 +43,25 @@ void free_vmcb(struct vmcb_struct *vmcb) free_xenheap_page(vmcb); } +struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, + struct vmcb_struct *va, paddr_t pa) +{ + return va; +} + +struct vmcb_struct *svm_vmcb_map(const struct vcpu *v) +{ + return svm_vmcb_map_one(v, v->arch.hvm.svm.vmcb, v->arch.hvm.svm.vmcb_pa); +} + +void svm_vmcb_unmap(const struct vcpu *v, const struct vmcb_struct *vmcb) +{ +} + /* This function can directly access fields which are covered by clean bits. */ -static int construct_vmcb(struct vcpu *v) +static int construct_vmcb(struct vcpu *v, struct vmcb_struct *vmcb) { struct svm_vcpu *svm = &v->arch.hvm.svm; - struct vmcb_struct *vmcb = svm->vmcb; vmcb->_general1_intercepts = GENERAL1_INTERCEPT_INTR | GENERAL1_INTERCEPT_NMI | @@ -201,6 +215,7 @@ int svm_create_vmcb(struct vcpu *v) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct svm_vcpu *svm = &v->arch.hvm.svm; + struct vmcb_struct *vmcb; int rc; if ( (nv->nv_n1vmcx == NULL) && @@ -211,7 +226,10 @@ int svm_create_vmcb(struct vcpu *v) } svm->vmcb = nv->nv_n1vmcx; - rc = construct_vmcb(v); + + vmcb = svm_vmcb_map(v); + rc = construct_vmcb(v, vmcb); + svm_vmcb_unmap(v, vmcb); if ( rc != 0 ) { free_vmcb(nv->nv_n1vmcx); @@ -407,6 +425,7 @@ static void cf_check vmcb_dump(unsigned char ch) { struct domain *d; struct vcpu *v; + struct vmcb_struct *vmcb; printk("*********** VMCB Areas **************\n"); @@ -425,7 +444,9 @@ 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); + vmcb = svm_vmcb_map(v); + svm_vmcb_dump("key_handler", vmcb); + svm_vmcb_unmap(v, vmcb); process_pending_softirqs(); } diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 28dae325ce..9d61767ec7 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -559,6 +559,15 @@ struct vmcb_struct { struct vmcb_struct *alloc_vmcb(void); void free_vmcb(struct vmcb_struct *vmcb); +/* + * Access a VMCB of a vCPU that may not be current. svm_vmcb_map() takes + * the active VMCB, svm_vmcb_map_one() a specific one. + */ +struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, + struct vmcb_struct *va, paddr_t pa); +struct vmcb_struct *svm_vmcb_map(const struct vcpu *v); +void svm_vmcb_unmap(const struct vcpu *v, const struct vmcb_struct *vmcb); + int svm_create_vmcb(struct vcpu *v); void svm_destroy_vmcb(struct vcpu *v); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454835.1668373 (Exim 4.92) (envelope-from ) id 1xItS1-0003pl-Fs; Mon, 19 Oct 2026 19:55:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454835.1668373; Mon, 19 Oct 2026 19:55: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 1xItS1-0003nu-BK; Mon, 19 Oct 2026 19:55:17 +0000 Received: by outflank-mailman (input) for mailman id 1454835; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hI-HX for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yg-2eEW; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGY-00000001FjN-2hyN; Mon, 19 Oct 2026 19:43: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=nYii0FVbr7qWQUooLUKA16mNwNVCccFAiU2dNNQmLGs=; b=0hhp481ohQwC1X8i/yMgQcwHaf hUW3sXG1nbP67YqB6hbAYUV710w6zdV6gDpwkMqjPNVIK5IGt79ADe15n7qmbK2lSncvtyxvvB9iI 7LY969cZe+R6r9yTy1DpRAHkpuBTrKSsP29n7ZyzJsF2slLUa0Nfe0haS4cLFpPstzQA=; 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?= , Teddy Astie Subject: [PATCH v4 11/30] x86/domain_page: prepare the mapcache for per-vCPU accounting Date: Mon, 19 Oct 2026 20:42:42 +0100 Message-ID: <20261019-asi-hvm-v4-11-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Currently, only PV domains have a mapcache, which is domain-wide one. In preparation for enabling per-vCPU mapcaches for HVM domains, split the accounting out into a struct mapcache, embedded in struct mapcache_domain. Introduce has_mapcache(), for whether a vCPU has a mapcache, and vcpu_mapcache(), which returns the accounting for a vCPU's mapcache and, in *dcache, the domain-wide mapcache whose lock and TLB epoch the caller has to take into account. For now has_mapcache() is is_pv_vcpu(), and vcpu_mapcache() always returns the domain's accounting. Move map_domain_page()'s handling of the domain-wide lock and TLB epoch into three helpers: mapcache_enter() takes the lock and catches up with a wrap another vCPU caused, mapcache_new_epoch() starts a new epoch after a wrap, and mapcache_exit() drops the lock. A per-vCPU mapcache can then skip them without map_domain_page() being re-indented. struct mapcache_domain keeps its size (40 bytes, x86_64 debug build), and so do the structures containing it. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Reword has_mapcache()'s comment (Roger). - Move the comment on the domain-wide lock and TLB epoch into the function body (Roger). - Rename mapcache_lock() / mapcache_unlock() to mapcache_enter() / mapcache_exit() (Roger). - mapcache_new_epoch(): assert that the domain-wide lock is held (Roger). - mapcache_vcpu_init(): drop the comment on the early return for a disabled domain-wide mapcache (Jan). - mapcache_vcpu_init(): initialise ents and nr at their declarations, as before (Jan). - Dropping the redundant is_pv_vcpu() checks in map_domain_page() and unmap_domain_page() is now a patch of its own (Jan). Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 137 ++++++++++++++++++++---------- xen/arch/x86/include/asm/domain.h | 19 +++-- 2 files changed, 102 insertions(+), 54 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index ed68483695..e4ea7a254f 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -18,17 +18,19 @@ #include #include +/* Whether the vCPU supports mapcache usage, might not be in use. */ +static bool has_mapcache(const struct vcpu *v) +{ + return is_pv_vcpu(v); +} + static inline struct vcpu *mapcache_current_vcpu(void) { const struct vcpu *v = this_cpu(pgtable_vcpu); const struct vcpu *curr = current; - /* - * During early boot pgtable_vcpu is not set, callers must handle NULL. - * Non-PV domains don't have a mapcache, the directmap covers all physical - * address space. - */ - if ( !v || !is_pv_vcpu(v) ) + /* During early boot pgtable_vcpu is not set, callers must handle NULL. */ + if ( !v || !has_mapcache(v) ) return NULL; /* @@ -54,6 +56,52 @@ static inline struct vcpu *mapcache_current_vcpu(void) return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } +/* + * The accounting for v's mapcache: the domain's, with *dcache set so the + * caller takes the domain-wide lock and TLB-epoch machinery into account. + */ +static struct mapcache *vcpu_mapcache(struct vcpu *v, + struct mapcache_domain **dcache) +{ + struct domain *d = v->domain; + + *dcache = &d->arch.pv.mapcache; + return &(*dcache)->cache; +} + +static void mapcache_enter(struct mapcache_domain *dcache, + struct mapcache_vcpu *vcache) +{ + /* The domain's vCPUs share the mapcache's slots. */ + spin_lock(&dcache->lock); + + /* Has some other CPU caused a wrap? We must flush if so. */ + if ( unlikely(dcache->epoch != vcache->shadow_epoch) ) + { + vcache->shadow_epoch = dcache->epoch; + if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) ) + { + perfc_incr(domain_page_tlb_flush); + flush_tlb_local(); + } + } +} + +/* A wrap has just flushed this CPU's TLB: start a new epoch. */ +static void mapcache_new_epoch(struct mapcache_domain *dcache, + struct mapcache_vcpu *vcache) +{ + ASSERT(spin_is_locked(&dcache->lock)); + + vcache->shadow_epoch = ++dcache->epoch; + dcache->tlbflush_timestamp = tlbflush_current_time(); +} + +static void mapcache_exit(struct mapcache_domain *dcache) +{ + spin_unlock(&dcache->lock); +} + #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) #define MAPCACHE_L2_ENTRIES (mapcache_l2_entry(MAPCACHE_ENTRIES - 1) + 1) #define MAPCACHE_L1ENT(idx) \ @@ -66,6 +114,7 @@ void *map_domain_page(mfn_t mfn) struct vcpu *v; struct mapcache_domain *dcache; struct mapcache_vcpu *vcache; + struct mapcache *cache; struct vcpu_maphash_entry *hashent; #ifdef NDEBUG @@ -77,9 +126,9 @@ void *map_domain_page(mfn_t mfn) if ( !v ) return mfn_to_virt(mfn_x(mfn)); - dcache = &v->domain->arch.pv.mapcache; + cache = vcpu_mapcache(v, &dcache); vcache = &v->arch.pv.mapcache; - if ( !dcache->inuse ) + if ( !cache->inuse ) return mfn_to_virt(mfn_x(mfn)); perfc_incr(map_domain_page_count); @@ -90,41 +139,30 @@ void *map_domain_page(mfn_t mfn) if ( hashent->mfn == mfn_x(mfn) ) { idx = hashent->idx; - ASSERT(idx < dcache->entries); + ASSERT(idx < cache->entries); hashent->refcnt++; ASSERT(hashent->refcnt); ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn)); goto out; } - spin_lock(&dcache->lock); + mapcache_enter(dcache, vcache); - /* Has some other CPU caused a wrap? We must flush if so. */ - if ( unlikely(dcache->epoch != vcache->shadow_epoch) ) - { - vcache->shadow_epoch = dcache->epoch; - if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) ) - { - perfc_incr(domain_page_tlb_flush); - flush_tlb_local(); - } - } - - idx = find_next_zero_bit(dcache->inuse, dcache->entries, dcache->cursor); - if ( unlikely(idx >= dcache->entries) ) + idx = find_next_zero_bit(cache->inuse, cache->entries, cache->cursor); + if ( unlikely(idx >= cache->entries) ) { unsigned long accum = 0, prev = 0; /* /First/, clean the garbage map and update the inuse list. */ - for ( i = 0; i < BITS_TO_LONGS(dcache->entries); i++ ) + for ( i = 0; i < BITS_TO_LONGS(cache->entries); i++ ) { accum |= prev; - dcache->inuse[i] &= ~xchg(&dcache->garbage[i], 0); - prev = ~dcache->inuse[i]; + cache->inuse[i] &= ~xchg(&cache->garbage[i], 0); + prev = ~cache->inuse[i]; } - if ( accum | (prev & BITMAP_LAST_WORD_MASK(dcache->entries)) ) - idx = find_first_zero_bit(dcache->inuse, dcache->entries); + if ( accum | (prev & BITMAP_LAST_WORD_MASK(cache->entries)) ) + idx = find_first_zero_bit(cache->inuse, cache->entries); else { /* Replace a hash entry instead. */ @@ -144,19 +182,18 @@ void *map_domain_page(mfn_t mfn) i = 0; } while ( i != MAPHASH_HASHFN(mfn_x(mfn)) ); } - BUG_ON(idx >= dcache->entries); + BUG_ON(idx >= cache->entries); /* /Second/, flush TLBs. */ perfc_incr(domain_page_tlb_flush); flush_tlb_local(); - vcache->shadow_epoch = ++dcache->epoch; - dcache->tlbflush_timestamp = tlbflush_current_time(); + mapcache_new_epoch(dcache, vcache); } - set_bit(idx, dcache->inuse); - dcache->cursor = idx + 1; + set_bit(idx, cache->inuse); + cache->cursor = idx + 1; - spin_unlock(&dcache->lock); + mapcache_exit(dcache); l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW)); @@ -170,6 +207,7 @@ void unmap_domain_page(const void *ptr) unsigned int idx; struct vcpu *v; struct mapcache_domain *dcache; + struct mapcache *cache; unsigned long va = (unsigned long)ptr, mfn, flags; struct vcpu_maphash_entry *hashent; @@ -181,8 +219,8 @@ void unmap_domain_page(const void *ptr) v = mapcache_current_vcpu(); ASSERT(v); - dcache = &v->domain->arch.pv.mapcache; - ASSERT(dcache->inuse); + cache = vcpu_mapcache(v, &dcache); + ASSERT(cache->inuse); idx = PFN_DOWN(va - MAPCACHE_VIRT_START); mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); @@ -205,7 +243,7 @@ void unmap_domain_page(const void *ptr) hashent->mfn); l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty()); /* /Second/, mark as garbage. */ - set_bit(hashent->idx, dcache->garbage); + set_bit(hashent->idx, cache->garbage); } /* Add newly-freed mapping to the maphash. */ @@ -217,7 +255,7 @@ void unmap_domain_page(const void *ptr) /* /First/, zap the PTE. */ l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); /* /Second/, mark as garbage. */ - set_bit(idx, dcache->garbage); + set_bit(idx, cache->garbage); } local_irq_restore(flags); @@ -239,9 +277,9 @@ void mapcache_domain_init(struct domain *d) 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long))) > MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20)); bitmap_pages = PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)); - dcache->inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE; - dcache->garbage = dcache->inuse + - (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); + dcache->cache.inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE; + dcache->cache.garbage = dcache->cache.inuse + + (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); spin_lock_init(&dcache->lock); } @@ -249,15 +287,20 @@ void mapcache_domain_init(struct domain *d) int mapcache_vcpu_init(struct vcpu *v) { struct domain *d = v->domain; - struct mapcache_domain *dcache = &d->arch.pv.mapcache; + struct mapcache_domain *dcache; + struct mapcache *cache; unsigned long i; unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); - if ( !is_pv_vcpu(v) || !dcache->inuse ) + if ( !has_mapcache(v) ) + return 0; + + cache = vcpu_mapcache(v, &dcache); + if ( !cache->inuse ) return 0; - if ( ents > dcache->entries ) + if ( ents > cache->entries ) { /* Populate page tables. */ int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, @@ -265,16 +308,16 @@ int mapcache_vcpu_init(struct vcpu *v) /* Populate bit maps. */ if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse, + rc = create_perdomain_mapping(v, (unsigned long)cache->inuse, nr, NULL, NIL(struct page_info *)); if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage, + rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, nr, NULL, NIL(struct page_info *)); if ( rc ) return rc; - dcache->entries = ents; + cache->entries = ents; } /* Mark all maphash entries as not in use. */ diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 4140a92f15..542c6b5eca 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -57,6 +57,16 @@ struct trap_bounce { unsigned long eip; }; +struct mapcache { + /* The number of array entries, and a cursor into the array. */ + unsigned int entries; + unsigned int cursor; + + /* Which mappings are in use, and which are garbage to reap next epoch? */ + unsigned long *inuse; + unsigned long *garbage; +}; + #define MAPHASH_ENTRIES 8 #define MAPHASH_HASHFN(pfn) ((pfn) & (MAPHASH_ENTRIES-1)) #define MAPHASHENT_NOTINUSE ((u32)~0U) @@ -73,10 +83,6 @@ struct mapcache_vcpu { }; struct mapcache_domain { - /* The number of array entries, and a cursor into the array. */ - unsigned int entries; - unsigned int cursor; - /* Protects map_domain_page(). */ spinlock_t lock; @@ -84,9 +90,8 @@ struct mapcache_domain { unsigned int epoch; u32 tlbflush_timestamp; - /* Which mappings are in use, and which are garbage to reap next epoch? */ - unsigned long *inuse; - unsigned long *garbage; + /* Accounting of the domain-wide mapcache. */ + struct mapcache cache; }; void mapcache_domain_init(struct domain *d); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454837.1668392 (Exim 4.92) (envelope-from ) id 1xItS2-0004C2-EE; Mon, 19 Oct 2026 19:55:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454837.1668392; Mon, 19 Oct 2026 19:55: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 1xItS2-0004B0-8q; Mon, 19 Oct 2026 19:55:18 +0000 Received: by outflank-mailman (input) for mailman id 1454837; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003h6-Gj for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yM-1Ug1; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGq-00000001FjN-0Vjv; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=0xjjqZgBgY8JRdyUnikpudSp7wTX9GMpnA2R61WibAk=; b=xPX+XWlYED+O8f0wmVmXbJ+ABA bqnIl+GYHkHaw8Dd22+y2MvFJtgs/ZRlwdNNkp59SedwJB/if5e+lcATu+XfNtbFFXjEYtCQcpQ5h Fya36z2ymJvg60Nws0PluJUGixANVpNBLBDUk8hpfSOLdmdFASHEDzvQ91Z7iBy3Ii7E=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v4 27/30] x86/svm: restore guest debug registers in svm_do_resume() Date: Mon, 19 Oct 2026 20:42:58 +0100 Message-ID: <20261019-asi-hvm-v4-27-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit svm_ctxt_switch_to() restores the guest's debug registers when its DR7 enables any of them, which also updates the VMCB. Do it in svm_do_resume() instead, which follows it whenever the vCPU is scheduled in. svm_do_resume() also runs when a vCPU keeps running on its pCPU (continue_running()), without svm_ctxt_switch_to(). Where the guest's debug registers are already loaded, the restore does nothing: flag_dr_dirty records that they are, and only svm_save_dr() clears it, from svm_ctxt_switch_from(). This prepares for moving VMCBs off always-mapped memory: svm_ctxt_switch_to() runs before write_ptbase(), where the incoming vCPU's VMCB will not be mapped. Not yet run with a guest using debug registers. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/svm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 4e19df9865..3de8da7ea3 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -955,8 +955,6 @@ static void cf_check svm_ctxt_switch_to(struct vcpu *v) */ disable_each_ist(per_cpu(idt, cpu)); - svm_restore_dr(v); - svm_tsc_ratio_load(v); if ( cpu_has_msr_tsc_aux ) @@ -980,6 +978,8 @@ static void noreturn cf_check svm_do_resume(void) bool vcpu_guestmode = false; struct vlapic *vlapic = vcpu_vlapic(v); + svm_restore_dr(v); + if ( nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v) ) vcpu_guestmode = 1; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454838.1668400 (Exim 4.92) (envelope-from ) id 1xItS3-0004GB-1D; Mon, 19 Oct 2026 19:55:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454838.1668400; Mon, 19 Oct 2026 19:55: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 1xItS2-0004Dq-IV; Mon, 19 Oct 2026 19:55:18 +0000 Received: by outflank-mailman (input) for mailman id 1454838; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hB-H3 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yG-0zXK; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGi-00000001FjN-1w6N; Mon, 19 Oct 2026 19:43: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" 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=4vwFFDZCpFYjWxxI53FAUMca7zB7w00pZUIvfcxHC8k=; b=YsEWkED9HVO4ibSOhCJ6K4n+To i1vnUzp3MH3wFb7JEnxx0p7SXoQFiRKzzW4S9xq02XaOGfnQ6Lo3yrxARE3H4A6MnEEfJ4qg+6h/t Ui6e2Gh6Rr+Jj1mDA9LPKywG7TYHBIIIXn0pF7zuXKno3BnQSq1wKtbatf6rplINqyxw=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Teddy Astie Subject: [PATCH v4 20/30] x86/spec-ctrl: wire the sparse directmap view into the asi= option Date: Mon, 19 Oct 2026 20:42:51 +0100 Message-ID: <20261019-asi-hvm-v4-20-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Let asi= choose which domains run on the sparse view of the directmap, when the hypervisor is built with CONFIG_SPARSE_DIRECTMAP: * `asi` and `asi=` enable or disable the sparse view, along with vCPU-PT, for every domain including the hardware domain, PV or PVH. HVM domains, a PVH hardware domain included, use the sparse view together with vCPU-PT, which gives them the mapcache it needs; PV domains all have one. A PV domain on the sparse view keeps its domain-wide mapcache and per-domain mappings: the sparse view separates it from other domains, not its vCPUs from each other. * `asi=hvm=`, `asi=pv=` and `asi=dom0=` do the same for HVM or PV domains other than the hardware domain, or for the hardware domain, whatever its type: `asi=1,dom0=0` leaves the hardware domain out of ASI altogether. * A new `asi=directmap=` selects the sparse view for all domains, as `asi=vcpu-pt=` selects vCPU-PT; `vcpu-pt=` alone leaves the sparse view off. On a hypervisor built without CONFIG_SPARSE_DIRECTMAP the forms enabling all features leave the sparse view off, and `directmap=` is rejected as invalid, as compiled-out `spec-ctrl=` sub-options are. A domain type the build lacks is ignored, so that the sparse view is not built for nothing. * For now, a PV domain uses one of XPTI and the sparse view, not both; a later patch lets them combine. Enabled explicitly, for dom0, domUs or both, XPTI takes precedence: the PV domains it covers keep the full directmap, and the boot log says so. Left to its default, XPTI yields: it is disabled for the PV domains using the sparse view, with a boot-log warning where it would otherwise be enabled, as the sparse view does not replace it yet (it still maps the xenheap and Xen's stacks). Each domain's case is settled at its creation, and again if it becomes 32-bit, which XPTI does not cover: switch_compat() then puts a domain that XPTI kept off the sparse view on it, with the domain-wide mapcache, which release builds may not have set up for it. The boot log gains a line with the directmap mode, "sparse" once a sparse view is configured and "full" otherwise, and the "ASI features for ..." lines, one for PV domUs now among them, say which domains use the sparse view. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Docs, comments and message: "domains" throughout, not "guests" (Roger). - Follow the rename of opt_vcpu_pt_hwdom to opt_pvh_vcpu_pt_hwdom and the move of the per-domain settings into d->arch.asi. - pv= and dom0= move to the patch introducing asi=, beside hvm=; opt_sparse_dmap_hwdom and sparse_dmap_wanted()'s hardware-domain case to the patches that add the other knobs and sparse_dmap_wanted() (Roger). - directmap= on a build without CONFIG_SPARSE_DIRECTMAP is rejected as invalid, as compiled-out spec-ctrl= sub-options are, rather than ignored with a warning (Roger). - A PV domain that XPTI kept off the sparse view goes on it when it becomes 32-bit, which ends XPTI; it used to end up with neither. Changes in v3: - New in this version. --- docs/misc/xen-command-line.pandoc | 30 +++++- xen/arch/x86/include/asm/sparse-directmap.h | 7 ++ xen/arch/x86/pv/domain.c | 16 ++++ xen/arch/x86/spec_ctrl.c | 101 ++++++++++++++++++-- 4 files changed, 139 insertions(+), 15 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 839d06da26..092c858f34 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -203,7 +203,7 @@ to appropriate auditing by Xen. Argo is disabled by default. buggy or malicious other domain spamming the ring. ### asi (x86) -> `= List of [ , {pv,hvm,dom0}=, +> `= List of [ , {pv,hvm,dom0}=, directmap=, > vcpu-pt= | vcpu-pt=hvm= ]` > Default: `false` @@ -215,14 +215,16 @@ 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. -The mechanisms currently implemented apply to HVM domains, including a PVH -hardware domain. PV domains, including a PV hardware domain, are unaffected. +The mechanisms currently implemented are `vcpu-pt`, for HVM domains including +a PVH hardware domain, and `directmap`, for all domains including the hardware +domain, PV or PVH. The plain boolean enables or disables both, wherever they +apply. * `pv=`, `hvm=` and `dom0=` enable the features for PV domains or HVM domains other than the hardware domain, or for the hardware domain, PV or PVH. The plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain - out. The forms naming no domain type (an un-suffixed `vcpu-pt=`) - cover the hardware domain too. + out. The forms naming no domain type (an un-suffixed `vcpu-pt=`, and + `directmap=`) cover the hardware domain too. **WARNING: manual de-selection of enabled options will invalidate any protection offered by the feature. The fine grained options provided below @@ -231,6 +233,18 @@ are meant to be used for debugging purposes only.** * `vcpu-pt` gives each vCPU its own per-domain area: the per-domain slot of each vCPU's monitor table maps a region private to that vCPU. +* `directmap` (only available when Xen is built with + `CONFIG_SPARSE_DIRECTMAP`) runs guest contexts on a sparse view of the + directmap, which maps the memory Xen needs to reach at all times (the Xen + heap, Xen's own image, firmware tables), while guest memory is mapped + transiently. This selection is system-wide; `pv=`, `hvm=` and `dom0=` + make it for one domain type, along with the other features. HVM domains use + the sparse view only together with `vcpu-pt`, and PV domains only without + XPTI, which yields to the sparse view unless enabled explicitly (see + `xpti`). The whole-feature forms (`asi`, `asi=`, and `pv=`, `hvm=` + and `dom0=`) set this too, on builds that support it; on other builds they + leave it off. + ### asid (x86) > `= ` @@ -3132,6 +3146,12 @@ Meltdown for all domains. With `dom0` and `domu` it is possible to control page table isolation for dom0 or guest domains only. +With `asi`, XPTI and the sparse directmap view (`asi=directmap`) exclude each +other for a PV domain. Enabled explicitly, as a whole or with `dom0` or +`domu`, XPTI keeps the PV domains it covers off the sparse view, and the boot +log says so. Left to its default, XPTI is disabled for the PV domains using +the sparse view, with a boot-log warning where it would otherwise be enabled. + ### xsave (x86) > `= ` diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index 2f8b94f4c1..db4df82215 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -31,6 +31,10 @@ static inline bool sparse_dmap_configured(void) return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; } +static inline bool sparse_dmap_pv(void) { return opt_sparse_dmap_pv; } +static inline bool sparse_dmap_hvm(void) { return opt_sparse_dmap_hvm; } +static inline bool sparse_dmap_hwdom(void) { return opt_sparse_dmap_hwdom; } + /* Whether a new domain of the given type is to use the sparse view. */ static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { @@ -51,6 +55,9 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); static inline bool sparse_dmap_configured(void) { return false; } static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { return false; } +static inline bool sparse_dmap_pv(void) { return false; } +static inline bool sparse_dmap_hvm(void) { return false; } +static inline bool sparse_dmap_hwdom(void) { return false; } static inline void sparse_dmap_init(void) {} static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags) diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index f139d8f83c..579d6133f5 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -248,6 +248,20 @@ int switch_compat(struct domain *d) d->arch.has_32bit_shinfo = 1; d->arch.pv.is_32bit = true; + /* + * XPTI, cleared below, is for 64-bit domains. A domain it kept off the + * sparse directmap view goes on it now if wanted, and the domain-wide + * mapcache the view needs is set up for the domain and its vCPUs. + */ + if ( d->arch.pv.xpti && sparse_dmap_wanted(true, is_hardware_domain(d)) ) + { + d->arch.asi.sparse_dmap = true; + mapcache_domain_init(d); + for_each_vcpu ( d, v ) + if ( (rc = mapcache_vcpu_init(v)) ) + goto undo_and_fail; + } + /* * For 32bit PV guests the shared_info machine address must fit in a 32-bit * field within the guest's start_info structure. We might need to free @@ -301,6 +315,8 @@ int switch_compat(struct domain *d) undo_and_fail: d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = false; + if ( d->arch.pv.xpti ) + d->arch.asi.sparse_dmap = false; for_each_vcpu( d, v ) { free_compat_arg_xlat(v); diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 32e6ba28a3..25726978b9 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -387,6 +387,19 @@ int8_t __ro_after_init opt_xpti_domu = -1; static __init void xpti_init_default(void) { + /* + * XPTI and the sparse directmap view exclude each other for a PV domain + * (see spec_ctrl_init_domain()). Enabled explicitly, XPTI takes + * precedence: the PV domains it covers stay off the sparse view. Left to + * its default, it yields: it is off where the sparse view is asked for. + */ + if ( !opt_dom0_pvh && opt_xpti_hwdom == 1 && sparse_dmap_hwdom() ) + printk(XENLOG_ERR + "XPTI enabled, disabling Dom0 sparse-directmap\n"); + if ( opt_xpti_domu == 1 && sparse_dmap_pv() ) + printk(XENLOG_ERR + "XPTI enabled, disabling PV DomU sparse-directmap\n"); + if ( (boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) || cpu_has_rdcl_no ) { @@ -397,10 +410,21 @@ static __init void xpti_init_default(void) } else { + bool yield_hwdom = opt_xpti_hwdom < 0 && !opt_dom0_pvh && + sparse_dmap_hwdom(); + bool yield_domu = opt_xpti_domu < 0 && sparse_dmap_pv(); + + /* The default would be on here: say where it yields. */ + if ( yield_hwdom || yield_domu ) + printk(XENLOG_WARNING + "XPTI defaults off for PV %s on the sparse directmap\n", + yield_hwdom ? (yield_domu ? "Dom0 and DomU" : "Dom0") + : "DomU"); + if ( opt_xpti_hwdom < 0 ) - opt_xpti_hwdom = 1; + opt_xpti_hwdom = !sparse_dmap_hwdom(); if ( opt_xpti_domu < 0 ) - opt_xpti_domu = 1; + opt_xpti_domu = !sparse_dmap_pv(); } } @@ -491,6 +515,23 @@ static int __init cf_check parse_pv_l1tf(const char *s) } custom_param("pv-l1tf", parse_pv_l1tf); +/* + * Set the sparse directmap view's knob for each domain type given. A type + * the build lacks stays off, so that no view is built for it, and without + * CONFIG_SPARSE_DIRECTMAP all stay off. + */ +static void __init set_sparse_dmap(bool pv, bool hvm, bool hwdom, bool val) +{ +#ifdef CONFIG_SPARSE_DIRECTMAP + if ( pv && IS_ENABLED(CONFIG_PV) ) + opt_sparse_dmap_pv = val; + if ( hvm && IS_ENABLED(CONFIG_HVM) ) + opt_sparse_dmap_hvm = val; + if ( hwdom ) + opt_sparse_dmap_hwdom = val; +#endif +} + static int __init cf_check parse_asi(const char *s) { const char *ss; @@ -498,7 +539,10 @@ static int __init cf_check parse_asi(const char *s) /* Interpret 'asi' alone in its positive boolean form. */ if ( *s == '\0' ) + { opt_pvh_vcpu_pt_hwdom = opt_vcpu_pt_hvm = true; + set_sparse_dmap(true, true, true, true); + } do { ss = strchr(s, ','); @@ -511,15 +555,33 @@ static int __init cf_check parse_asi(const char *s) case 0: case 1: opt_pvh_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; + set_sparse_dmap(true, true, true, val); break; default: if ( (val = parse_boolean("pv", s, ss)) >= 0 ) - /* PV domains are unaffected. */; + set_sparse_dmap(true, false, false, val); else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + { opt_vcpu_pt_hvm = val; + set_sparse_dmap(false, true, false, val); + } else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) + { opt_pvh_vcpu_pt_hwdom = val; + set_sparse_dmap(false, false, true, val); + } + else if ( (val = parse_boolean("directmap", s, ss)) >= 0 ) + { + /* System-wide: every domain type, the hardware domain too. */ + if ( IS_ENABLED(CONFIG_SPARSE_DIRECTMAP) ) + set_sparse_dmap(true, true, true, val); + else + { + no_config_param("SPARSE_DIRECTMAP", "asi", s, ss); + rc = -EINVAL; + } + } else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) { switch ( val ) @@ -748,12 +810,30 @@ static void __init print_details(enum ind_thunk thunk) opt_pv_l1tf_domu ? "enabled" : "disabled"); #endif - printk(" ASI features for Dom0:%s\n", - opt_dom0_pvh && opt_pvh_vcpu_pt_hwdom ? " vCPU-PT" : " None"); + { + bool hwdom_pt = opt_dom0_pvh && opt_pvh_vcpu_pt_hwdom; + bool hwdom_sd = sparse_dmap_hwdom() && + (opt_dom0_pvh ? hwdom_pt : !opt_xpti_hwdom); + + printk(" ASI directmap mode: %s\n", + sparse_dmap_configured() ? "sparse" : "full"); + printk(" ASI features for Dom0:%s%s%s\n", + hwdom_pt || hwdom_sd ? "" : " None", + hwdom_pt ? " vCPU-PT" : "", + hwdom_sd ? " sparse-directmap" : ""); #ifdef CONFIG_HVM - printk(" ASI features for HVM VMs:%s\n", - opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); + printk(" ASI features for HVM VMs:%s%s%s\n", + opt_vcpu_pt_hvm ? "" : " None", + opt_vcpu_pt_hvm ? " vCPU-PT" : "", + opt_vcpu_pt_hvm && sparse_dmap_hvm() + ? " sparse-directmap" : ""); #endif +#ifdef CONFIG_PV + printk(" ASI features for PV VMs:%s\n", + sparse_dmap_pv() && !opt_xpti_domu + ? " sparse-directmap" : " None"); +#endif + } } static bool __init check_smt_enabled(void) @@ -1946,9 +2026,10 @@ void spec_ctrl_init_domain(struct domain *d) /* * The sparse directmap view needs a mapcache: PV domains all have one, - * HVM domains through per-vCPU page-tables. + * HVM domains through per-vCPU page-tables. A PV domain using XPTI + * stays on the full directmap. */ - d->arch.asi.sparse_dmap = (pv || d->arch.asi.vcpu_pt) && + d->arch.asi.sparse_dmap = (pv ? !d->arch.pv.xpti : d->arch.asi.vcpu_pt) && sparse_dmap_wanted(pv, is_hardware_domain(d)); } @@ -2242,7 +2323,7 @@ void __init init_speculation_mitigations(void) hw_smt_enabled && default_xen_spec_ctrl ) setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE); - if ( opt_pvh_vcpu_pt_hwdom || opt_vcpu_pt_hvm ) + if ( opt_pvh_vcpu_pt_hwdom || opt_vcpu_pt_hvm || sparse_dmap_configured() ) warning_add( "Address Space Isolation is not functional, this option is\n" "intended to be used only for development purposes.\n"); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454840.1668410 (Exim 4.92) (envelope-from ) id 1xItS3-0004Qv-Ms; Mon, 19 Oct 2026 19:55:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454840.1668410; Mon, 19 Oct 2026 19:55: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 1xItS3-0004OX-5e; Mon, 19 Oct 2026 19:55:19 +0000 Received: by outflank-mailman (input) for mailman id 1454840; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hR-Id for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yQ-1q4P; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGt-00000001FjN-1fBH; Mon, 19 Oct 2026 19:43: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" 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=bMNvYGbpwti5AIsINLtLfKcXfjOXZ5N/yCUXzZrTb18=; b=BuaVhJuzRwN+Qj/B48mVkgsgNe rD1Sn9VjswIz47T2CRWAfPdGzLXajbTE2d8UZSKzONXlg6v+YU342J61wYRD3TIZdY20+3YnehBK2 /6garerc3YHryFbe5yxV4UPedTzgfyrKnFyLUZ3XGDKbesGTSwgbFPiRXFrbxz0QDZSo=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 30/30] x86/vmx: move the guest MSR load/save list off always-mapped memory Date: Mon, 19 Oct 2026 20:43:01 +0100 Message-ID: <20261019-asi-hvm-v4-30-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The guest MSR load/save list holds guest MSR values (SPEC_CTRL, LBR, PT, vPMU global control, and EFER on hardware without dedicated controls), but lives on the xenheap, where it stays reachable from every context. Move the page to the domain heap and map it at its fixed slot in the owning vCPU's state window, so that under Address Space Isolation it is only mapped while that vCPU's page tables are loaded. Hardware is unaffected: the VMCS MSR-area pointers hold the physical address, now derived from the page rather than from virt_to_maddr() on a directmap VA. The host MSR load list is left on the xenheap: it holds Xen's own exit-time values, not guest data, so relocating it would serve no isolation purpose. The window VA is only valid in the owning vCPU's context. Almost all accesses have v == current and keep going through vmx->msr_area unchanged (the vmentry-path LBR fixups, the failed-vmentry dump, vPMU, and the MSR intercepts). The remote accessors — vmx_add_msr() / vmx_del_msr() from vCPU construction, policy updates and context load, and single-entry reads/writes from the HVM context save/load and get/set-reg paths, all of which already require the target vCPU to be paused — dispatch through a transient mapping of the page, dropped with unmap_vcpu_state_page(), which also drops this CPU's translations of it: * vmx_add_msr() and vmx_del_msr() map internally around their search/insert/remove. * vmx_read_guest_msr(), vmx_read_guest_loadonly_msr() and vmx_write_guest_msr() move out of line and do the same, via vmx_find_msr_in(), the existing lookup parameterised on the mapped area. vmx_find_msr() itself is unchanged for its remaining callers, which all run in current context and dereference the returned pointer through the window. vmx_destroy_vmcs() takes the page out of the window before freeing it, with unmap_vcpu_state(): without per-vCPU page tables the window is in the domain-wide area, which outlives a vCPU whose creation fails. The new page pointer goes with the existing page_info pointers after pi_desc rather than next to msr_area: struct pi_desc is 64-byte aligned, so inserting eight bytes ahead of it would have added 56 bytes of padding, growing struct vmx_vcpu from 448 to 512 bytes and, via the union in struct arch_vcpu, every struct vcpu by 64 bytes (x86_64 defconfig). Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version. --- xen/arch/x86/hvm/vmx/vmcs.c | 134 +++++++++++++++++++++--- xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 63 +++-------- 2 files changed, 139 insertions(+), 58 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 8ec7ae7403..02ad89e864 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -1416,8 +1416,11 @@ static struct vmx_msr_entry *locate_msr_entry( return start; } -struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, - enum vmx_msr_list_type type) +/* As vmx_find_msr(), but reaching the guest MSR area through @area. */ +static struct vmx_msr_entry *vmx_find_msr_in(const struct vcpu *v, + struct vmx_msr_entry *area, + uint32_t msr, + enum vmx_msr_list_type type) { const struct vmx_vcpu *vmx = &v->arch.hvm.vmx; struct vmx_msr_entry *start = NULL, *ent, *end; @@ -1435,11 +1438,11 @@ struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, break; case VMX_MSR_GUEST: - start = vmx->msr_area; + start = area; break; case VMX_MSR_GUEST_LOADONLY: - start = vmx->msr_area; + start = area; substart = subend; subend = total; break; @@ -1458,6 +1461,69 @@ struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, return ((ent < end) && (ent->index == msr)) ? ent : NULL; } +struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, + enum vmx_msr_list_type type) +{ + ASSERT(v == current || type == VMX_MSR_HOST); + + return vmx_find_msr_in(v, v->arch.hvm.vmx.msr_area, msr, type); +} + +static struct vmx_msr_entry *vmx_msr_area_map(const struct vcpu *v) +{ + const struct vmx_vcpu *vmx = &v->arch.hvm.vmx; + + if ( v == current || !vmx->msr_area ) + return vmx->msr_area; + + return map_domain_page(page_to_mfn(vmx->msr_area_pg)); +} + +static void vmx_msr_area_unmap(const struct vcpu *v, + const struct vmx_msr_entry *area) +{ + if ( v != current && area ) + unmap_vcpu_state_page(area); +} + +int vmx_read_guest_msr(const struct vcpu *v, uint32_t msr, uint64_t *val) +{ + struct vmx_msr_entry *area = vmx_msr_area_map(v); + const struct vmx_msr_entry *ent = + area ? vmx_find_msr_in(v, area, msr, VMX_MSR_GUEST) : NULL; + + *val = ent ? ent->data : 0; + vmx_msr_area_unmap(v, area); + + return ent ? 0 : -ESRCH; +} + +int vmx_read_guest_loadonly_msr(const struct vcpu *v, uint32_t msr, + uint64_t *val) +{ + struct vmx_msr_entry *area = vmx_msr_area_map(v); + const struct vmx_msr_entry *ent = + area ? vmx_find_msr_in(v, area, msr, VMX_MSR_GUEST_LOADONLY) : NULL; + + *val = ent ? ent->data : 0; + vmx_msr_area_unmap(v, area); + + return ent ? 0 : -ESRCH; +} + +int vmx_write_guest_msr(struct vcpu *v, uint32_t msr, uint64_t val) +{ + struct vmx_msr_entry *area = vmx_msr_area_map(v); + struct vmx_msr_entry *ent = + area ? vmx_find_msr_in(v, area, msr, VMX_MSR_GUEST) : NULL; + + if ( ent ) + ent->data = val; + vmx_msr_area_unmap(v, area); + + return ent ? 0 : -ESRCH; +} + int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, enum vmx_msr_list_type type) { @@ -1503,13 +1569,38 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, { paddr_t addr; - if ( (*ptr = alloc_xenheap_page()) == NULL ) + if ( type == VMX_MSR_HOST ) { - rc = -ENOMEM; - goto out; + if ( (*ptr = alloc_xenheap_page()) == NULL ) + { + rc = -ENOMEM; + goto out; + } + + addr = virt_to_maddr(*ptr); } + else + { + struct page_info *pg = alloc_domheap_page(v->domain, + MEMF_no_owner); + mfn_t mfn; + + if ( pg == NULL ) + { + rc = -ENOMEM; + goto out; + } - addr = virt_to_maddr(*ptr); + mfn = page_to_mfn(pg); + clear_domain_page(mfn); + populate_perdomain_mapping(v, + VCPU_STATE_ADDR(v, + VCPU_STATE_IDX_VMX_MSR), + &mfn, 1, __PAGE_HYPERVISOR_RW); + vmx->msr_area_pg = pg; + *ptr = (void *)VCPU_STATE_ADDR(v, VCPU_STATE_IDX_VMX_MSR); + addr = mfn_to_maddr(mfn); + } switch ( type ) { @@ -1525,7 +1616,7 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, } } - start = *ptr; + start = type == VMX_MSR_HOST ? *ptr : vmx_msr_area_map(v); end = start + total; ent = locate_msr_entry(start + substart, start + subend, msr); @@ -1565,6 +1656,8 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, rc = 0; out: + if ( type != VMX_MSR_HOST ) + vmx_msr_area_unmap(v, start); vmx_vmcs_exit(v); return rc; @@ -1576,6 +1669,7 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) struct vmx_msr_entry *start = NULL, *ent, *end; unsigned int substart = 0, subend = vmx->msr_save_count; unsigned int total = vmx->msr_load_count; + int rc = 0; ASSERT(v == current || !vcpu_runnable(v)); @@ -1605,11 +1699,17 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) if ( !start ) return -ESRCH; + if ( type != VMX_MSR_HOST ) + start = vmx_msr_area_map(v); + end = start + total; ent = locate_msr_entry(start + substart, start + subend, msr); if ( (ent == end) || (ent->index != msr) ) - return -ESRCH; + { + rc = -ESRCH; + goto out; + } memmove(ent, ent + 1, sizeof(*ent) * (end - ent - 1)); @@ -1632,7 +1732,11 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) vmx_vmcs_exit(v); - return 0; + out: + if ( type != VMX_MSR_HOST ) + vmx_msr_area_unmap(v, start); + + return rc; } void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector) @@ -1829,7 +1933,13 @@ void vmx_destroy_vmcs(struct vcpu *v) vmx_free_vmcs(vmx->vmcs_pa); free_xenheap_page(v->arch.hvm.vmx.host_msr_area); - free_xenheap_page(v->arch.hvm.vmx.msr_area); + if ( v->arch.hvm.vmx.msr_area_pg ) + { + unmap_vcpu_state(v, VCPU_STATE_IDX_VMX_MSR, 1); + free_domheap_page(v->arch.hvm.vmx.msr_area_pg); + v->arch.hvm.vmx.msr_area_pg = NULL; + v->arch.hvm.vmx.msr_area = NULL; + } free_xenheap_page(v->arch.hvm.vmx.msr_bitmap); } diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h index d0716e97d2..e5730780e2 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h @@ -140,6 +140,10 @@ struct vmx_vcpu { * context. However, the data can be modified by toolstack/migration * actions. Remote access is only permitted for paused vcpus, and is * protected under the domctl lock. + * + * The guest list is a domain-heap page (msr_area_pg, below) mapped at a + * fixed slot in the owning vCPU's state window: msr_area holds that + * window VA, which is only valid in the owning vCPU's context. */ struct vmx_msr_entry *msr_area; struct vmx_msr_entry *host_msr_area; @@ -185,6 +189,9 @@ struct vmx_vcpu { struct page_info *pml_pg; + /* Backing page of msr_area; see the comment there. */ + struct page_info *msr_area_pg; + /* Bitmask of trapped CR4 bits. */ unsigned long cr4_host_mask; @@ -669,55 +676,19 @@ static inline int vmx_add_host_load_msr(struct vcpu *v, uint32_t msr, return vmx_add_msr(v, msr, val, VMX_MSR_HOST); } +/* + * Look an MSR up in the guest or host list of @v. The returned pointer + * reaches the guest lists through the vCPU state window, so for those it + * is only valid (and the call only permitted) in current context; the + * single-entry accessors below handle paused remote vCPUs. + */ struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type); -static inline int vmx_read_guest_msr(const struct vcpu *v, uint32_t msr, - uint64_t *val) -{ - const struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST); - - if ( !ent ) - { - *val = 0; - return -ESRCH; - } - - *val = ent->data; - - return 0; -} - -static inline int vmx_read_guest_loadonly_msr( - const struct vcpu *v, uint32_t msr, uint64_t *val) -{ - const struct vmx_msr_entry *ent = - vmx_find_msr(v, msr, VMX_MSR_GUEST_LOADONLY); - - if ( !ent ) - { - *val = 0; - return -ESRCH; - } - - *val = ent->data; - - return 0; -} - -static inline int vmx_write_guest_msr(struct vcpu *v, uint32_t msr, - uint64_t val) -{ - struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST); - - if ( !ent ) - return -ESRCH; - - ent->data = val; - - return 0; -} - +int vmx_read_guest_msr(const struct vcpu *v, uint32_t msr, uint64_t *val); +int vmx_read_guest_loadonly_msr(const struct vcpu *v, uint32_t msr, + uint64_t *val); +int vmx_write_guest_msr(struct vcpu *v, uint32_t msr, uint64_t val); /* MSR intercept bitmap infrastructure. */ enum vmx_msr_intercept_type { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454839.1668416 (Exim 4.92) (envelope-from ) id 1xItS4-0004g1-6g; Mon, 19 Oct 2026 19:55:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454839.1668416; Mon, 19 Oct 2026 19:55: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 1xItS3-0004cT-Rm; Mon, 19 Oct 2026 19:55:19 +0000 Received: by outflank-mailman (input) for mailman id 1454839; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003ha-KT for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022zJ-34G7; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGn-00000001FjN-09tA; Mon, 19 Oct 2026 19:43: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" 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=KIMuN+gRzQ2bf6n6qCzbyKF+T+td17QWHkd6BfMjllw=; b=0/spY6nDQijmbovDb1WpQiYZ8m d2R+DPchyj5phcApmFz5PjEZcDTGwmmv06NMT9R8BzCYeCd0kegJnMACDtxqjeXVgml0TgedsDwPM Fv9U769D1bjWa45owU+3eQ2aYcGBiH+y1DB27EN10mhIH7y+eKV1lxqt4aINsXiijiq4=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 24/30] x86/mm: introduce a per-vCPU state window in the perdomain area Date: Mon, 19 Oct 2026 20:42:55 +0100 Message-ID: <20261019-asi-hvm-v4-24-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Under Address Space Isolation, guest-owned register state that Xen keeps in always-mapped memory moves to the domain heap, mapped only in the contexts that use it. The long-lived per-vCPU structures involved (the SVM VMCB, the VMX guest MSR load/save list, the guest XSAVE area, and later the aggregated small per-vCPU allocations) all want the same shape: one or more domain-heap pages, mapped once at fixed per-vCPU virtual addresses for the life of the vCPU. Add a fourth per-domain-mapping sub-area providing that destination: a small per-vCPU stride of page slots, with a fixed index assigned to each relocated structure and the page tables created at vCPU creation time. Consumers allocate their own pages and install them with populate_perdomain_mapping(); the backing pages remain caller-owned, so their lifetime stays with the consumer, while the page tables are torn down with the rest of the perdomain area. Before freeing their pages, consumers take them out of the window with unmap_vcpu_state(), on failure paths as at teardown: vCPU creation can fail once a consumer has mapped its pages, and the domain lives on. It flushes the domain's dirty CPUs, which include every CPU whose page-tables carry the window, in the vCPU's own area or in the shared one; so far that mask is empty on every call, as the vCPU has not run or the domain is paused. A consumer reaching a page from another context, through a transient map_domain_page() mapping, drops the mapping with unmap_vcpu_state_page(), which also flushes this CPU's translations of it, there and at its alias in the per-domain mirror: a domain-wide mapcache defers that flush, and the translations would otherwise outlive the mapping. For a domain running without per-vCPU page tables the window has the same domain-wide visibility as the other perdomain sub-areas: the virtual addresses are keyed on vcpu_id, so the same VA arithmetic serves both modes. With vcpu-pt enabled, a vCPU's window is simply absent from its siblings' address spaces. This is infrastructure for moving the SVM VMCB, the VMX MSR load/save lists and the guest XSAVE areas off always-mapped memory. Nothing occupies the area yet; the only behavioural change is the page-table allocation itself and the failure path that comes with it: vCPU creation can now fail with -ENOMEM. Both apply to every guest vCPU, with or without asi=, PV ones included. A domain with per-vCPU page tables gets an L2 and an L1 per vCPU; any other domain, every PV domain among them, one L2 plus an L1 per 64 vCPUs: 2 pages for up to 64 vCPUs. A PV domain's window stays empty until the XSAVE areas move there. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version. --- xen/arch/x86/domain.c | 12 +++++++++ xen/arch/x86/include/asm/config.h | 21 ++++++++++++++- xen/arch/x86/include/asm/mm.h | 2 ++ xen/arch/x86/mm.c | 44 +++++++++++++++++++++++++++++++ 4 files changed, 78 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 7a4da203d4..04868a781e 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -525,6 +525,18 @@ int arch_vcpu_create(struct vcpu *v) if ( rc ) goto fail; + BUILD_BUG_ON((MAX_VIRT_CPUS << VCPU_STATE_VA_SHIFT) > + (PERDOMAIN_SLOT_MBYTES << 20)); + BUILD_BUG_ON(VCPU_STATE_IDX_VMCB >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_N2VMCB >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_VMX_MSR >= VCPU_STATE_NR_PAGES); + /* Page tables only; torn down with the rest of the perdomain area. */ + rc = create_perdomain_mapping(v, VCPU_STATE_START(v), + VCPU_STATE_NR_PAGES, + NIL(l1_pgentry_t *), NULL); + if ( rc != 0 ) + goto fail; + paging_vcpu_init(v); if ( (rc = vcpu_init_fpu(v)) != 0 ) diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index ee84c57432..8a265e25c8 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -158,7 +158,7 @@ /* Slot 260: per-domain mappings (including map cache). */ #define PERDOMAIN_VIRT_START (PML4_ADDR(260)) #define PERDOMAIN_SLOT_MBYTES (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER)) -#define PERDOMAIN_SLOTS 3 +#define PERDOMAIN_SLOTS 4 #define PERDOMAIN_VIRT_SLOT(s) (PERDOMAIN_VIRT_START + (s) * \ (PERDOMAIN_SLOT_MBYTES << 20)) /* Slot 4: mirror of per-domain mappings (for compat xlat area accesses). */ @@ -293,6 +293,25 @@ extern unsigned long xen_phys_start; #define ARG_XLAT_START(v) \ (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT)) +/* + * Per-vCPU state window. The fourth per-domain-mapping sub-area: a small + * per-vCPU stride of page slots holding long-lived per-vCPU structures kept + * out of always-mapped memory, each mapped once for the life of the vCPU at + * a fixed index within the stride. + */ +#define VCPU_STATE_SLOT 3 +#define VCPU_STATE_VIRT_START PERDOMAIN_VIRT_SLOT(VCPU_STATE_SLOT) +#define VCPU_STATE_ORDER 3 +#define VCPU_STATE_NR_PAGES (1U << VCPU_STATE_ORDER) +#define VCPU_STATE_VA_SHIFT (VCPU_STATE_ORDER + PAGE_SHIFT) +#define VCPU_STATE_START(v) \ + (VCPU_STATE_VIRT_START + ((v)->vcpu_id << VCPU_STATE_VA_SHIFT)) +#define VCPU_STATE_ADDR(v, idx) \ + (VCPU_STATE_START(v) + (idx) * PAGE_SIZE) +#define VCPU_STATE_IDX_VMCB 0 +#define VCPU_STATE_IDX_N2VMCB 1 +#define VCPU_STATE_IDX_VMX_MSR 2 + #define ELFSIZE 64 #define ARCH_CRASH_SAVE_VMCOREINFO diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 6d50e17259..6eaea3ba01 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -625,6 +625,8 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int flags); void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr); +void unmap_vcpu_state(const struct vcpu *v, unsigned int idx, unsigned int nr); +void unmap_vcpu_state_page(const void *va); void free_perdomain_mappings(struct domain *d); void free_pervcpu_mappings(struct vcpu *v); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index bf029df566..9c9f3e728c 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6668,6 +6668,50 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unmap_domain_page(l3tab); } +/* + * Take @nr slots of @v's state window, from @idx, out of the per-domain + * area, before the caller frees the pages behind them: the pages are the + * caller's own, and must not stay mapped once freed. The window's + * translations are usable only on CPUs whose page-tables carry it, all in + * the domain's dirty mask: with per-vCPU page-tables, the CPU running v or + * holding it lazily; otherwise, those of any of the domain's vCPUs. + */ +void unmap_vcpu_state(const struct vcpu *v, unsigned int idx, unsigned int nr) +{ + const struct domain *d = v->domain; + + /* Beyond the stride is the next vCPU's window, in a shared area. */ + BUG_ON(idx >= VCPU_STATE_NR_PAGES || nr > VCPU_STATE_NR_PAGES - idx); + + destroy_perdomain_mapping(v, VCPU_STATE_ADDR(v, idx), nr); + + flush_tlb_mask(d->dirty_cpumask); +} + +/* + * Drop a transient mapping of a page behind a vCPU's state window, and this + * CPU's translations of it: at its address, and at its alias in the + * per-domain mirror, which every domain but a 64-bit PV one has (flushing + * that address there is harmless). A per-vCPU mapcache flushes both + * already, with the slot's last mapping; a domain-wide one defers the + * flush, and CPUs running other vCPUs of its domain may have cached the + * slot too. A directmap address, where the caller has no mapcache, needs + * nothing. + */ +void unmap_vcpu_state_page(const void *va) +{ + unsigned long addr = (unsigned long)va; + + unmap_domain_page(va); + + if ( addr < DIRECTMAP_VIRT_START ) + { + flush_tlb_one_local(addr); + flush_tlb_one_local(addr - PERDOMAIN_VIRT_START + + PERDOMAIN_ALT_VIRT_START); + } +} + static void free_perdomain_l3(struct page_info *l3pg) { l3_pgentry_t *l3tab = __map_domain_page(l3pg); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454841.1668424 (Exim 4.92) (envelope-from ) id 1xItS4-0004r4-QY; Mon, 19 Oct 2026 19:55:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454841.1668424; Mon, 19 Oct 2026 19:55: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 1xItS4-0004lt-AI; Mon, 19 Oct 2026 19:55:20 +0000 Received: by outflank-mailman (input) for mailman id 1454841; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hY-Jt for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yW-2GmY; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGr-00000001FjN-1qeb; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=WXccehmoUo316LnD9XW5/ndVjuvHxgbNQjKqxh2kxOI=; b=tod2/hnaQFr59FD07ZjAE2NgIJ LraLVV9STvXUDhkjdyGXCiHO9lB/NP4MKcMy0CE3a1LD8ZezfoxsWBWBn/wefms9gzlOhFt3QuGNX D755nVMWCflmOJfbIDgLm0Sc5w7RiozLi28V9xBe1plK9CY+Ze6uiHdfER7nx5uUHhuw=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v4 28/30] x86/svm: drop svm_vmcb_dump()'s paddr and the unused VCPU_svm_vmcb Date: Mon, 19 Oct 2026 20:42:59 +0100 Message-ID: <20261019-asi-hvm-v4-28-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit svm_vmcb_dump() prints virt_to_maddr() of the VMCB, which is right only while VMCBs are reached through the directmap. Print the virtual address alone. Nothing uses the VCPU_svm_vmcb asm-offset: assembly only consumes VCPU_svm_vmcb_pa. Drop it. Both prepare for moving VMCBs off always-mapped memory. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/vmcb.c | 4 ++-- xen/arch/x86/x86_64/asm-offsets.c | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 4c48bbc76d..f5321b03fb 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -280,8 +280,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) svm_sync_vmcb(curr, vmcb_in_sync); printk("Dumping guest's current state at %s...\n", from); - printk("Size of VMCB = %zu, paddr = %"PRIpaddr", vaddr = %p\n", - sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb); + printk("Size of VMCB = %zu, vaddr = %p\n", + sizeof(struct vmcb_struct), vmcb); printk("cr_intercepts = %#x dr_intercepts = %#x " "exception_intercepts = %#x\n", diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c index 0549fd5e8d..c5259de604 100644 --- a/xen/arch/x86/x86_64/asm-offsets.c +++ b/xen/arch/x86/x86_64/asm-offsets.c @@ -118,7 +118,6 @@ void __dummy__(void) #ifdef CONFIG_HVM OFFSET(VCPU_svm_vmcb_pa, struct vcpu, arch.hvm.svm.vmcb_pa); - OFFSET(VCPU_svm_vmcb, struct vcpu, arch.hvm.svm.vmcb); BLANK(); OFFSET(VCPU_vmx_launched, struct vcpu, arch.hvm.vmx.launched); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454843.1668433 (Exim 4.92) (envelope-from ) id 1xItS5-00051C-Ol; Mon, 19 Oct 2026 19:55:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454843.1668433; Mon, 19 Oct 2026 19:55: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 1xItS5-0004yb-5t; Mon, 19 Oct 2026 19:55:21 +0000 Received: by outflank-mailman (input) for mailman id 1454843; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hv-Oi for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yk-2mTs; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGm-00000001FjN-0Rk8; Mon, 19 Oct 2026 19: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" 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=Yt1PBD1wcL13XT6rHzyFnBSPgO0t4Ozjz4QBOUPAPsc=; b=SNuacrP2SMgDjyEETYlQpWsLCD BOsRFiAORmC5ukmHrvWd8JJM5ctP765o0TTDMX0m6qOSpODM6jo1TioApfNMQnE0v093NZ3UzE0zE qW+x5a4LVZ0e/yPeb1hfLK7Mk9XZKbmF8DiPk8e4BoT1ZoInhOSS6MkNQ4a/fptMcG2U=; 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?= , Teddy Astie Subject: [PATCH v4 23/30] x86/mm: introduce populate_perdomain_mapping() Date: Mon, 19 Oct 2026 20:42:54 +0100 Message-ID: <20261019-asi-hvm-v4-23-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné The per-domain area 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 and the compat argument-translation area. What the interface lacks is a way to install a caller's own pages at a chosen address, which a per-vCPU state window, introduced by a later patch, needs: its users allocate their pages themselves and map them there. Introduce populate_perdomain_mapping(v, va, mfn, nr, flags) for this. It writes the given MFNs, with the given page-table flags, into v's view of the per-domain area, walking the per-domain page-table structures with transient mappings, so v need not be current. 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. 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 never expected: such a page is referenced only by the mapping, and no caller replaces area-owned backing. Should one ever do so, the page is leaked with a message rather than freed. The function is not for contexts with interrupts off: its users map their pages when allocating them. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Re-introduced into the series. - HVM only: the users are the state window's, all of which map their pages at allocation time, so drop the linear-mapping fast path and the IRQs-off walk that context-switch callers needed, along with the map_domain_page_irqoff() variants. --- xen/arch/x86/include/asm/mm.h | 3 ++ xen/arch/x86/mm.c | 62 +++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index af43ae01b0..6d50e17259 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -620,6 +620,9 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); int create_perdomain_mapping(struct vcpu *v, 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(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 449ae561dc..bf029df566 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6554,6 +6554,68 @@ int create_perdomain_mapping(struct vcpu *v, 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(). Present entries are replaced, and + * no TLB flushing is done. + * + * The walk maps the per-domain page-table pages transiently, so v need not + * be current. It is not for contexts with interrupts disabled. + */ +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, + const mfn_t *mfn, unsigned int nr, + unsigned int flags) +{ + struct page_info *l3_pg = perdomain_l3(v); + const l3_pgentry_t *l3tab; + const l2_pgentry_t *l2tab; + l1_pgentry_t *l1tab = NULL; + unsigned int i; + + ASSERT(va >= PERDOMAIN_VIRT_START && + va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); + ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1))); + ASSERT(local_irq_is_enabled()); + + if ( !nr ) + return; + + BUG_ON(!l3_pg); + l3tab = __map_domain_page(l3_pg); + BUG_ON(!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT)); + l2tab = map_l2t_from_l3e(l3tab[l3_table_offset(va)]); + unmap_domain_page(l3tab); + + for ( i = 0; i < nr; i++, va += PAGE_SIZE ) + { + l1_pgentry_t *pl1e; + + if ( !l1tab || !l1_table_offset(va) ) + { + const l2_pgentry_t *pl2e = &l2tab[l2_table_offset(va)]; + + unmap_domain_page(l1tab); + BUG_ON(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT)); + l1tab = map_l1t_from_l2e(*pl2e); + } + + pl1e = &l1tab[l1_table_offset(va)]; + if ( perdomain_l1e_needs_freeing(*pl1e) ) + { + printk(XENLOG_ERR + "%pv: leaking area-owned page %"PRI_mfn" at %#lx\n", + v, mfn_x(l1e_get_mfn(*pl1e)), va); + ASSERT_UNREACHABLE(); + } + l1e_write(pl1e, l1e_from_mfn(mfn[i], flags)); + } + + unmap_domain_page(l1tab); + unmap_domain_page(l2tab); +} + void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454842.1668439 (Exim 4.92) (envelope-from ) id 1xItS6-0005Dn-Gz; Mon, 19 Oct 2026 19:55:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454842.1668439; Mon, 19 Oct 2026 19:55: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 1xItS5-0005Ae-VT; Mon, 19 Oct 2026 19:55:21 +0000 Received: by outflank-mailman (input) for mailman id 1454842; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hk-M8 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022zU-3EEm; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGZ-00000001FjN-2zkB; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=aVPwz/HIeDRqTabRAgDisgdvx3aA/KVHe9Dvzv5GxMA=; b=E00Ua+4/MtlsFXfQ/Vz5+nagTR QLCIosl6WA6fF3CH0m6SkDRMg/mleKgVtsF3QKq6+IQCYAEZ+sXA6dAQER/9pE3HKR8dZGSvZHhvh fwqJ2CTwS5nstW+MDRShQIATtmnjqmUithxK1ANvKG57OosELK4Sc1uJuqc21owerVB4=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v4 12/30] x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu Date: Mon, 19 Oct 2026 20:42:43 +0100 Message-ID: <20261019-asi-hvm-v4-12-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné struct mapcache_vcpu, the per-vCPU part of the mapcache (the maphash and the vCPU's shadow of the domain's TLB epoch), lives in struct pv_vcpu, as only PV vCPUs have a mapcache. In preparation for implementing mapcaches for HVM domains, move it to struct arch_vcpu: v->arch.pv.mapcache becomes v->arch.mapcache. struct pv_vcpu shrinks from 512 to 376 bytes, and struct vcpu grows from 2880 to 3008 bytes (x86_64, debug build), within its page: from here on HVM vCPUs carry the 136-byte struct mapcache_vcpu too, ahead of its use by those of vCPU-PT domains. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 6 +++--- xen/arch/x86/include/asm/domain.h | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index e4ea7a254f..205d7b832a 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -127,7 +127,7 @@ void *map_domain_page(mfn_t mfn) return mfn_to_virt(mfn_x(mfn)); cache = vcpu_mapcache(v, &dcache); - vcache = &v->arch.pv.mapcache; + vcache = &v->arch.mapcache; if ( !cache->inuse ) return mfn_to_virt(mfn_x(mfn)); @@ -224,7 +224,7 @@ void unmap_domain_page(const void *ptr) idx = PFN_DOWN(va - MAPCACHE_VIRT_START); mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); - hashent = &v->arch.pv.mapcache.hash[MAPHASH_HASHFN(mfn)]; + hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)]; local_irq_save(flags); @@ -324,7 +324,7 @@ int mapcache_vcpu_init(struct vcpu *v) BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES); for ( i = 0; i < MAPHASH_ENTRIES; i++ ) { - struct vcpu_maphash_entry *hashent = &v->arch.pv.mapcache.hash[i]; + struct vcpu_maphash_entry *hashent = &v->arch.mapcache.hash[i]; hashent->mfn = ~0UL; /* never valid to map */ hashent->idx = MAPHASHENT_NOTINUSE; diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 542c6b5eca..45d308407e 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -545,9 +545,6 @@ struct arch_domain struct pv_vcpu { - /* map_domain_page() mapping cache. */ - struct mapcache_vcpu mapcache; - unsigned int vgc_flags; struct trap_info *trap_ctxt; @@ -643,6 +640,9 @@ struct arch_vcpu #define async_exception_state(t) async_exception_state[(t)-1] uint8_t async_exception_mask; + /* map_domain_page() mapping cache. */ + struct mapcache_vcpu mapcache; + /* Virtual Machine Extensions */ union { struct pv_vcpu pv; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454844.1668447 (Exim 4.92) (envelope-from ) id 1xItS7-0005Tg-8Y; Mon, 19 Oct 2026 19:55:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454844.1668447; Mon, 19 Oct 2026 19:55: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 1xItS6-0005Q6-Rx; Mon, 19 Oct 2026 19:55:22 +0000 Received: by outflank-mailman (input) for mailman id 1454844; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hu-Oa for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yI-1FGJ; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGj-00000001FjN-315T; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=LN8Bez7AsiyQjAHOZqZjhab+Xv6VL8QpdV20hUs5obk=; b=XPbhxbKiTjI9rUYIxjlVR6X38Q N7dJH7OMsei63XdjTT2UHl/zCZ6QC7VeeM9YoTWORP9VVidYAySyX7FH0R/3Chm5P6//eVhQbcLoP hOg0xa01PX9wX4lZpq2BQXTW51n5jmYtYbw2NXvSZ68P16j9uNdDo9MTrm4LAfa1CVW0=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v4 21/30] xen/xmalloc: return an emptied region after dropping the pool lock Date: Mon, 19 Oct 2026 20:42:52 +0100 Message-ID: <20261019-asi-hvm-v4-21-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When a free leaves a whole region of an xmalloc pool empty, xmem_pool_free() hands the region back through pool->put_mem() with pool->lock still held. For the xenheap pool that is free_xenheap_pages(), which takes the heap lock inside the pool lock and runs arch_xenheap_pages_free(). On x86 with a sparse directmap view configured, the latter takes the page out of the view, at the cost of one to three rounds of TLB-flush IPIs to every CPU, while every other CPU's sub-page xmalloc() and xfree() waits on the pool lock. By then the region is on no free list and no longer counted in the pool, so nothing else can reach it. Drop the lock first and return the region afterwards, as xmem_pool_alloc() already does when it calls pool->get_mem(), and say at both callbacks that they are called without the pool lock, so that they keep not relying on it. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- xen/common/xmalloc_tlsf.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c index b43219b4af..caf33f1a04 100644 --- a/xen/common/xmalloc_tlsf.c +++ b/xen/common/xmalloc_tlsf.c @@ -106,7 +106,10 @@ struct xmem_pool { unsigned long used_size; unsigned long num_regions; - /* User provided functions for expanding/shrinking pool */ + /* + * User provided functions for expanding/shrinking pool. They are + * called without the pool lock held, and must not rely on it. + */ xmem_pool_get_memory *get_mem; xmem_pool_put_memory *put_mem; @@ -488,17 +491,18 @@ void xmem_pool_free(void *ptr, struct xmem_pool *pool) if ( (b->prev_hdr == NULL) && ((tmp_b->size & BLOCK_SIZE_MASK) == 0) ) { - pool->put_mem(b); pool->num_regions--; pool->used_size -= BHDR_OVERHEAD; /* sentinel block header */ - goto out; + spin_unlock(&pool->lock); + pool->put_mem(b); + return; } INSERT_BLOCK(b, pool, fl, sl); tmp_b->size |= PREV_FREE; tmp_b->prev_hdr = b; - out: + spin_unlock(&pool->lock); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454845.1668459 (Exim 4.92) (envelope-from ) id 1xItS8-0005l2-B7; Mon, 19 Oct 2026 19:55:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454845.1668459; Mon, 19 Oct 2026 19: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 1xItS7-0005he-Sl; Mon, 19 Oct 2026 19:55:23 +0000 Received: by outflank-mailman (input) for mailman id 1454845; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003hw-P4 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022zl-3YoA; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGg-00000001FjN-0lcO; Mon, 19 Oct 2026 19: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" 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=dbeZKV9O+bmNdrh0qt89ublfkcV74oImeh0hl17sAps=; b=jgoFtm5p3xGtx39+eoGKrwQ/W9 5PsVIafcft7cfDUDsGeu2STkBtHg3nkAD2IxUNQz98NiQnpb50qQp+2QRWtnFcfa4VmlufVd+8Z/1 EtD349aaIv1/hXmZxn2mQ6HaIbLCAFlA/C1wqDs3zBhx8EQeQfkwPzDRfAz7dH3iH3e4=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 18/30] x86/domain_page: clear a mapcache slot at its last unmap Date: Mon, 19 Oct 2026 20:42:49 +0100 Message-ID: <20261019-asi-hvm-v4-18-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit unmap_domain_page() keeps a recently unmapped slot in the vCPU's maphash (MAPHASH_ENTRIES, 8 per vCPU) for a quick remap of the same MFN, and leaves its PTE in place until the entry is displaced by a later unmap or reclaimed by a full cache. Until then the page stays mapped, although nothing refers to the mapping and the mapcache holds no reference to the page. Where the mapcache clears a slot's PTE, it defers the flush: the slot's translation can stay in the TLB of the CPU which used it until that CPU next flushes. While the full directmap is loaded, that reaches nothing it does not map anyway. On the sparse view of the directmap, Xen reaches domain-heap memory only through mappings made for the purpose. A mapping or a translation left behind keeps the page reachable after its last unmap: while Xen serves another of the guest's contexts on the same vCPU, and, once the page is freed and handed to another domain, from a context which has nothing to do with it. So clear a slot's PTE when its last reference goes, maphash slots included: the hash entry keeps the slot, not the mapping, and a later hit maps the page again in the same slot. The slot has mapped nothing else in between, so that needs no flush. Reusing the slot for another page still goes through the garbage map, or through the replacement of a hash entry when the cache is full, both of which flush first. In a per-vCPU mapcache, as vCPU-PT domains have, also invalidate the slot's translation on the local CPU, right after clearing the PTE. The slot has a second address, in the mirror of the per-domain area that every domain but a 64-bit PV one gets for the compat argument translation area, and its translation is invalidated too: two INVLPGs. That leaves no translation on any CPU, as the vCPU's page-tables are loaded on one CPU at a time, and a CPU loading other page-tables (switch_cr3_cr4()) flushes non-global translations, the mapcache's included. A PV domain's domain-wide mapcache has its PTEs cleared but no INVLPG, as CPUs running the domain's other vCPUs may hold the slot's translation too, which a local INVLPG would not reach. For it, as before, builds with PV support flush a page freed by its owner from TLBs before the page is handed out again. The cost is one PTE write per unmap into the maphash and per remap from it, and in a per-vCPU mapcache two INVLPGs per slot's last unmap. A second unmap of an entry in the maphash now finds its PTE not present and is caught by the check unmap_domain_page() has for entries the first unmap zapped, rather than by the reference count's ASSERT() in debug builds only. The change does not depend on asi= or on a sparse view of the directmap being configured: PV vCPUs use the domain-wide mapcache on the default command line too. For them it adds the PTE writes above, and leaves up to MAPHASH_ENTRIES fewer pages per vCPU mapped in the domain-wide area. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Merge v3's 15/18 ("x86/mm: flush owned pages before reuse with the sparse directmap view") and 16/18 ("x86/domain_page: keep the maphash's slots, not their mappings"). Rather than flush pages freed by their owner before reuse wherever a sparse view is configured, invalidate a per-vCPU mapcache slot's translations on the local CPU right after its PTE is cleared (Roger). - Message: don't restate when PV vCPUs use the mapcache (Roger). Changes in v3: - New in this version. For reviewers: with a slot cleared and invalidated at its last unmap, a per-vCPU mapcache's maphash saves only the search for a free slot, and a second slot for a page mapped twice at once. One page in two slots is fine, and already happens when it is not in the maphash. So per-vCPU mapcaches could drop the maphash, and with it their garbage map and wrap-time flush. In v5, or as a follow-up? --- xen/arch/x86/domain_page.c | 53 +++++++++++++++++++++++++------ xen/arch/x86/include/asm/domain.h | 5 ++- 2 files changed, 48 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 6b662706fb..4198ee7c18 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -130,6 +130,26 @@ static void mapcache_exit(struct mapcache_domain *dcache) #define MAPCACHE_L1ENT(idx) \ __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + pfn_to_paddr(idx))] +/* + * Clear a slot's PTE. For a per-vCPU mapcache (HVM domains only), then also + * drop the slot's translations from this CPU's TLB, at its address and at its + * alias in the per-domain mirror, which every HVM domain has. No other CPU + * can hold them: the vCPU's page-tables are loaded on one CPU at a time, and + * loading other page-tables flushes non-global translations. + */ +static void mapcache_zap(const struct mapcache_domain *dcache, + unsigned int idx) +{ + unsigned long va = MAPCACHE_VIRT_START + pfn_to_paddr(idx); + + l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); + if ( dcache ) + return; + + flush_tlb_one_local(va); + flush_tlb_one_local(va - PERDOMAIN_VIRT_START + PERDOMAIN_ALT_VIRT_START); +} + void *map_domain_page(mfn_t mfn) { unsigned long flags; @@ -176,6 +196,14 @@ void *map_domain_page(mfn_t mfn) { idx = hashent->idx; ASSERT(idx < cache->entries); + /* + * An entry the maphash kept holds on to its slot, not to its mapping + * (see unmap_domain_page()): map the page again. No flush is needed, + * as the slot has mapped nothing else since. + */ + if ( !hashent->refcnt ) + l1e_write(&MAPCACHE_L1ENT(idx), + l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW)); hashent->refcnt++; ASSERT(hashent->refcnt); ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn)); @@ -208,8 +236,8 @@ void *map_domain_page(mfn_t mfn) if ( hashent->idx != MAPHASHENT_NOTINUSE && !hashent->refcnt ) { idx = hashent->idx; - ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) == hashent->mfn); - l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); + ASSERT(!(l1e_get_flags(MAPCACHE_L1ENT(idx)) & + _PAGE_PRESENT)); hashent->idx = MAPHASHENT_NOTINUSE; hashent->mfn = ~0UL; break; @@ -273,32 +301,39 @@ void unmap_domain_page(const void *ptr) local_irq_save(flags); + /* + * The maphash keeps a freed slot, not its mapping: the page may change + * hands meanwhile. A domain-wide mapcache's translation left in a TLB + * is covered by the flush the allocator makes before reusing an owned + * page. + */ if ( hashent->idx == idx ) { ASSERT(hashent->mfn == mfn); ASSERT(hashent->refcnt); hashent->refcnt--; + if ( !hashent->refcnt ) + mapcache_zap(dcache, idx); } else if ( !hashent->refcnt ) { + /* The entry replaced has no mapping left: mark its slot as garbage. */ if ( hashent->idx != MAPHASHENT_NOTINUSE ) { - /* /First/, zap the PTE. */ - ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(hashent->idx)) == - hashent->mfn); - l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty()); - /* /Second/, mark as garbage. */ + ASSERT(!(l1e_get_flags(MAPCACHE_L1ENT(hashent->idx)) & + _PAGE_PRESENT)); set_bit(hashent->idx, cache->garbage); } - /* Add newly-freed mapping to the maphash. */ + /* Add the newly-freed slot to the maphash, without its mapping. */ + mapcache_zap(dcache, idx); hashent->mfn = mfn; hashent->idx = idx; } else { /* /First/, zap the PTE. */ - l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); + mapcache_zap(dcache, idx); /* /Second/, mark as garbage. */ set_bit(idx, cache->garbage); } diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index f84ac15759..0e405157b4 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -74,7 +74,10 @@ struct mapcache_vcpu { /* Shadow of mapcache_domain.epoch. */ unsigned int shadow_epoch; - /* Lock-free per-VCPU hash of recently-used mappings. */ + /* + * Lock-free per-VCPU hash of recently-used mappings. An entry without + * references keeps its slot but not its mapping (see unmap_domain_page()). + */ struct vcpu_maphash_entry { unsigned long mfn; uint32_t idx; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454846.1668466 (Exim 4.92) (envelope-from ) id 1xItS9-0005zL-FZ; Mon, 19 Oct 2026 19:55:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454846.1668466; Mon, 19 Oct 2026 19:55: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 1xItS8-0005rb-Mo; Mon, 19 Oct 2026 19:55:24 +0000 Received: by outflank-mailman (input) for mailman id 1454846; Mon, 19 Oct 2026 19:55:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003i0-QS for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-0000000230A-3wyE; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGf-00000001FjN-12Qo; Mon, 19 Oct 2026 19:43: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" 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=IljL9ERbJZTdTGatiECVH6x/M/gfKWv60kBNbg4WwnQ=; b=iqGzzSm0J/I43i2gk1lTExYrvR SnW6w+qJiJ1EroduJaeymaSVWRtf3EydBaZp1LR8/avjxkq8/tnVXswKyqbCLVsoWZM390KclAoiZ GkliKUC5x3LUxUU5FieyQJe41nSAmwrMYYMmfXYm8wAz0C6V1+IOyame+senp930EiDo=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 17/30] x86/domain_page: key the directmap fast paths on the loaded view Date: Mon, 19 Oct 2026 20:42:48 +0100 Message-ID: <20261019-asi-hvm-v4-17-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit map_domain_page() returns directmap addresses whenever it can: for any MFN the directmap covers in release builds, and for vCPUs without a mapcache. Once guest contexts may run on the sparse view of the directmap, modify this to take the fast path returning the directmap address only when the full directmap is loaded. The release-build shortcut ahead of the vCPU lookup looks at the vCPU whose page-tables are loaded, without completing a lazy context switch: if that vCPU is not on the sparse view, its page-tables map the page through the directmap, and completing the switch would only move the CPU to the idle vCPU's page-tables, which map it too. A vCPU on the sparse view always has a mapcache: HVM ones through per-vCPU page-tables, PV ones through the domain-wide mapcache, which mapcache_domain_init() now sets up for a domain using the sparse view in release builds too, rather than only when the directmap does not cover all memory. map_domain_page_global() mappings must be valid in every context: use vmap() for all of them once a sparse view is configured, as arch_mfns_in_directmap() then says. Add d->arch.asi.sparse_dmap for this; nothing sets it yet. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - d->arch.sparse_dmap is now a one-bit field of d->arch.asi, beside vcpu_pt. - Wrap a line that reached 80 columns. - Drop sparse_dmap_active: d->arch.asi.sparse_dmap alone says whether a domain's root page-tables carry the sparse view (Roger). Builds without CONFIG_SPARSE_DIRECTMAP compile the test out, as before. - Drop the second directmap check after the vCPU lookup: the !cache->inuse case covers it. Changes in v3: - New in this version. --- xen/arch/x86/domain_page.c | 34 ++++++++++++++++++++++++++++--- xen/arch/x86/include/asm/domain.h | 3 +++ 2 files changed, 34 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 770fee80a4..6b662706fb 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -56,6 +56,13 @@ static inline struct vcpu *mapcache_current_vcpu(void) return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } +/* Whether @v's page-tables carry the sparse view of the directmap. */ +static bool on_sparse_dmap(const struct vcpu *v) +{ + return IS_ENABLED(CONFIG_SPARSE_DIRECTMAP) && + v->domain->arch.asi.sparse_dmap; +} + /* * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's * otherwise, in which case *dcache is set so the caller takes the domain-wide @@ -135,9 +142,19 @@ void *map_domain_page(mfn_t mfn) #ifdef NDEBUG if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) - return mfn_to_virt(mfn_x(mfn)); + { + const struct vcpu *pt_vcpu = this_cpu(pgtable_vcpu); + + /* + * The page-tables loaded map @mfn through the directmap, unless they + * carry the sparse view. + */ + if ( !pt_vcpu || !on_sparse_dmap(pt_vcpu) ) + return mfn_to_virt(mfn_x(mfn)); + } #endif + /* No vCPU (early boot), or no mapcache: the full directmap is loaded. */ v = mapcache_current_vcpu(); if ( !v ) return mfn_to_virt(mfn_x(mfn)); @@ -145,7 +162,10 @@ void *map_domain_page(mfn_t mfn) cache = vcpu_mapcache(v, &dcache); vcache = &v->arch.mapcache; if ( !cache->inuse ) + { + ASSERT(!on_sparse_dmap(v)); return mfn_to_virt(mfn_x(mfn)); + } perfc_incr(map_domain_page_count); @@ -294,7 +314,11 @@ void mapcache_domain_init(struct domain *d) ASSERT(is_pv_domain(d)); #ifdef NDEBUG - if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) + /* + * Not needed when the directmap loaded for the domain covers everything. + */ + if ( !d->arch.asi.sparse_dmap && !mem_hotplug && + max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) return; #endif @@ -378,8 +402,12 @@ void *map_domain_page_global(mfn_t mfn) system_state < SYS_STATE_active) || local_irq_is_enabled())); + /* + * Global mappings must hold in every context: a sparse view of the + * directmap rules the directmap out. + */ #ifdef NDEBUG - if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) + if ( arch_mfns_in_directmap(mfn_x(mfn), 1) ) return mfn_to_virt(mfn_x(mfn)); #endif diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 7076e38848..f84ac15759 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -490,6 +490,9 @@ struct arch_domain struct { /* Give each vCPU its own per-domain area (HVM only). */ bool vcpu_pt:1; + + /* The domain's root page-tables carry the sparse directmap view. */ + bool sparse_dmap:1; } asi; /* Emulated devices enabled bitmap. */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454847.1668478 (Exim 4.92) (envelope-from ) id 1xItSB-0006F2-3X; Mon, 19 Oct 2026 19:55:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454847.1668478; Mon, 19 Oct 2026 19:55: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 1xItS9-0006AJ-Rr; Mon, 19 Oct 2026 19:55:25 +0000 Received: by outflank-mailman (input) for mailman id 1454847; Mon, 19 Oct 2026 19:55:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItRz-0003iE-TE for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yu-2vQR; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGp-00000001FjN-0OtQ; Mon, 19 Oct 2026 19:43: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" 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=aVhlCyy1J7G7Zme04HVYXzoAzI/t0O7TFZbPngGRa5g=; b=EN4gmx/0hUfhB7xCXkyaw9ale0 t0EUyoIuGCLpJcLAxcWCGGsWJFwh1lV7D1AcYkl4wkuKzTrc8r+JAhVjQoiPt4Qa8+KAqZOQ4VGVS MSd19vyuoGn1n9CaL/F+WcMN5aB11vvtTSETYnkIc5OOFc8TvD3GVjgVDejlCjvBq2BE=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v4 26/30] x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from() Date: Mon, 19 Oct 2026 20:42:57 +0100 Message-ID: <20261019-asi-hvm-v4-26-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A VMCB's clean bits must all be clear when its vCPU next runs after a deschedule, as other VMCBs run on the pCPU in the meantime. svm_ctxt_switch_to() clears them as the vCPU is scheduled in; clear them in svm_ctxt_switch_from() instead, as it is scheduled out. This is equivalent. While the vCPU is descheduled, accessors reaching its VMCB only ever clear clean bits: svm_vmexit_handler(), which sets them all, runs only in the vCPU's own context. So do the nested-SVM paths that change the active VMCB, nsvm_vcpu_hostrestore() and nsvm_vcpu_vmentry(), and they clear the incoming VMCB's clean bits themselves. This prepares for moving VMCBs off always-mapped memory: svm_ctxt_switch_to() runs before write_ptbase(), where the incoming vCPU's VMCB will not be mapped. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/svm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 241843d8c0..4e19df9865 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -919,6 +919,8 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v) svm_save_dr(v); svm_tsc_ratio_save(v); + v->arch.hvm.svm.vmcb->cleanbits.raw = 0; + svm_sync_vmcb(v, vmcb_needs_vmload); svm_vmload_pa(per_cpu(host_vmcb, cpu)); @@ -938,7 +940,6 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v) static void cf_check svm_ctxt_switch_to(struct vcpu *v) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; int cpu = smp_processor_id(); /* @@ -956,7 +957,6 @@ static void cf_check svm_ctxt_switch_to(struct vcpu *v) svm_restore_dr(v); - vmcb->cleanbits.raw = 0; svm_tsc_ratio_load(v); if ( cpu_has_msr_tsc_aux ) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454849.1668492 (Exim 4.92) (envelope-from ) id 1xItSF-00078H-EW; Mon, 19 Oct 2026 19:55:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454849.1668492; Mon, 19 Oct 2026 19: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 1xItSE-000744-Hq; Mon, 19 Oct 2026 19:55:30 +0000 Received: by outflank-mailman (input) for mailman id 1454849; Mon, 19 Oct 2026 19:55:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItS4-0004sm-L7 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yK-1MGT; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGc-00000001FjN-2gvR; Mon, 19 Oct 2026 19:43: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:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=+Qh68FKnxSRb1Fv+xxuele9p2cel+WGPjQ8nK81SNtY=; b=w+SqXr/yxkcAUG5++mX4Ydr8jg XfJoRzQzSuZQLv8hOTZ0fucmhRmUy7meK3AMu1y9Ypj9ZgOEesCIdii+yJ03hBqnP563jdYwf5MNx nAY2F/MwB4ZDQl5Wb3o5mT6yva1vRwoHBz7qQ1+WkG+Z4A4aJgEFpUKEs+aQsiQtRdd0=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 15/30] x86/mm: let Xen's page-table walker operate on a given root Date: Mon, 19 Oct 2026 20:42:46 +0100 Message-ID: <20261019-asi-hvm-v4-15-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit map_pages_to_xen() and modify_xen_mappings() maintain Xen's own mappings, walking from idle_pg_table, whose Xen slots every other root page-table copies. A later patch introduces a second, sparse directmap hierarchy: page tables for the directmap virtual address range that some guest contexts use in place of idle_pg_table's. It needs the same maintenance at the same virtual addresses. Give virt_to_xen_l{3,2,1}e() the L4 to walk from, and move the bodies of map_pages_to_xen() and modify_xen_mappings() into map_pages_in() and modify_mappings_in(), which take the root as well. The public functions pass idle_pg_table. The EFI runtime-services page-tables mirror idle_pg_table's L4 entries only, so a newly allocated L3 is propagated to them only when the root is idle_pg_table. TLB flushing is unaffected: flushes are by virtual address and go to every online CPU, which covers both hierarchies. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Message: name the second hierarchy as sparse; flushes reach every CPU (Roger). Changes in v3: - New in this version. --- xen/arch/x86/mm.c | 55 ++++++++++++++++++++++++++++++++++------------- 1 file changed, 40 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 362a88a300..514e121c8b 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5229,13 +5229,14 @@ static DEFINE_SPINLOCK(map_pgdir_lock); /* * For virt_to_xen_lXe() functions, they take a linear address and return a - * pointer to Xen's LX entry. Caller needs to unmap the pointer. + * pointer to Xen's LX entry in the page-table hierarchy rooted at @root + * (idle_pg_table for Xen's own mappings). Caller needs to unmap the pointer. */ -static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) +static l3_pgentry_t *virt_to_xen_l3e(l4_pgentry_t *root, unsigned long v) { l4_pgentry_t *pl4e; - pl4e = &idle_pg_table[l4_table_offset(v)]; + pl4e = &root[l4_table_offset(v)]; if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) ) { bool locking = system_state > SYS_STATE_boot; @@ -5251,7 +5252,8 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) l4_pgentry_t l4e = l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR); l4e_write(pl4e, l4e); - efi_update_l4_pgtable(l4_table_offset(v), l4e); + if ( root == idle_pg_table ) + efi_update_l4_pgtable(l4_table_offset(v), l4e); l3mfn = INVALID_MFN; } if ( locking ) @@ -5262,11 +5264,11 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) return map_l3t_from_l4e(*pl4e) + l3_table_offset(v); } -static l2_pgentry_t *virt_to_xen_l2e(unsigned long v) +static l2_pgentry_t *virt_to_xen_l2e(l4_pgentry_t *root, unsigned long v) { l3_pgentry_t *pl3e, l3e; - pl3e = virt_to_xen_l3e(v); + pl3e = virt_to_xen_l3e(root, v); if ( !pl3e ) return NULL; @@ -5300,11 +5302,11 @@ static l2_pgentry_t *virt_to_xen_l2e(unsigned long v) return map_l2t_from_l3e(l3e) + l2_table_offset(v); } -static l1_pgentry_t *virt_to_xen_l1e(unsigned long v) +static l1_pgentry_t *virt_to_xen_l1e(l4_pgentry_t *root, unsigned long v) { l2_pgentry_t *pl2e, l2e; - pl2e = virt_to_xen_l2e(v); + pl2e = virt_to_xen_l2e(root, v); if ( !pl2e ) return NULL; @@ -5380,7 +5382,7 @@ mfn_t xen_map_to_mfn(unsigned long va) bool locking = system_state > SYS_STATE_boot; unsigned int l2_offset = l2_table_offset(va); unsigned int l1_offset = l1_table_offset(va); - const l3_pgentry_t *pl3e = virt_to_xen_l3e(va); + const l3_pgentry_t *pl3e = virt_to_xen_l3e(idle_pg_table, va); const l2_pgentry_t *pl2e = NULL; const l1_pgentry_t *pl1e = NULL; struct page_info *l3page; @@ -5420,7 +5422,12 @@ mfn_t xen_map_to_mfn(unsigned long va) return ret; } -int map_pages_to_xen( +/* + * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or + * another hierarchy sharing its virtual addresses. + */ +static int map_pages_in( + l4_pgentry_t *root, unsigned long virt, mfn_t mfn, unsigned long nr_mfns, @@ -5471,7 +5478,7 @@ int map_pages_to_xen( UNMAP_DOMAIN_PAGE(pl3e); UNMAP_DOMAIN_PAGE(pl2e); - pl3e = virt_to_xen_l3e(virt); + pl3e = virt_to_xen_l3e(root, virt); if ( !pl3e ) goto out; @@ -5595,7 +5602,7 @@ int map_pages_to_xen( free_xen_pagetable(l2mfn); } - pl2e = virt_to_xen_l2e(virt); + pl2e = virt_to_xen_l2e(root, virt); if ( !pl2e ) goto out; @@ -5640,7 +5647,7 @@ int map_pages_to_xen( /* Normal page mapping. */ if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) { - pl1e = virt_to_xen_l1e(virt); + pl1e = virt_to_xen_l1e(root, virt); if ( pl1e == NULL ) goto out; } @@ -5825,6 +5832,15 @@ int map_pages_to_xen( return rc; } +int map_pages_to_xen( + unsigned long virt, + mfn_t mfn, + unsigned long nr_mfns, + pte_attr_t flags) +{ + return map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); +} + int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) { return map_pages_to_xen(virt, INVALID_MFN, nr_mfns, MAP_SMALL_PAGES); @@ -5841,8 +5857,12 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * flags are ignored. * * It is an error to call with present flags over an unpopulated range. + * + * modify_mappings_in() does so in the hierarchy rooted at @root, as + * map_pages_in() does. */ -int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) +static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, + unsigned long e, pte_attr_t nf) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -5869,7 +5889,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) UNMAP_DOMAIN_PAGE(pl2e); UNMAP_DOMAIN_PAGE(pl3e); - pl3e = virt_to_xen_l3e(v); + pl3e = virt_to_xen_l3e(root, v); if ( !pl3e ) goto out; @@ -6120,6 +6140,11 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) #undef flush_area +int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) +{ + return modify_mappings_in(idle_pg_table, s, e, nf); +} + int destroy_xen_mappings(unsigned long s, unsigned long e) { return modify_xen_mappings(s, e, _PAGE_NONE); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454848.1668500 (Exim 4.92) (envelope-from ) id 1xItSG-0007J8-L8; Mon, 19 Oct 2026 19:55:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454848.1668500; Mon, 19 Oct 2026 19:55: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 1xItSF-0007G6-He; Mon, 19 Oct 2026 19:55:31 +0000 Received: by outflank-mailman (input) for mailman id 1454848; Mon, 19 Oct 2026 19:55:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItS4-0004s9-JR for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022yO-1eKI; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGe-00000001FjN-1GFv; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=m8BHF4nspVGbZ4EkQQctpimDT5jF79rMCrrWtMtITns=; b=Xc6R/ZERY4rFQ4GjcU7LBh9FlR +Y7hOJQcomHnyKD5kWvIuHlaSriVFKdXL9UE/qzohbBU6VlkkoY+KzQmUgGopzrZD0BBuuW5TDaaW uzaZsvS5GO3gFJ5uZw5eHiCkLKUWpDfLbjicJtySUwfTePQSQG1AKK09wFXfYvW4AySE=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v4 16/30] x86/mm: build and maintain a sparse view of the directmap Date: Mon, 19 Oct 2026 20:42:47 +0100 Message-ID: <20261019-asi-hvm-v4-16-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The directmap maps all of RAM, and every root page-table carries it, so while any guest context runs, all guest memory is reachable from Xen's address space. For ASI, guest contexts are to run on a view of the directmap which maps only what Xen must reach through it at all times, leaving guest memory to transient mappings (map_domain_page()). Rather than remove the directmap for everyone, keep the full directmap as it is, for the idle domain and for guest contexts not using ASI, and build a second, sparse view: page-tables for the same virtual addresses (the part of the directmap PV guests can see, where everything Xen reaches through the directmap lives), mapping a subset of what the full directmap maps, each entry a copy of the full directmap's. Boot and the idle domain keep the full directmap, so nothing in them needs converting. The sparse view maps the xenheap, and memory never handed to the heap allocator (Xen's image, boot-time allocations, firmware tables). It is built once the boot allocator has handed its memory to the heap, from the full directmap minus the ranges the heap was given, plus the xenheap allocations made meanwhile. The page-tables then come from the heap, and no other CPU is up. The sparse view has an L3 for each of its L4 slots from the start, so its L4 entries never change and root page-tables can take copies of them. It is then kept in step: - xenheap allocations are added, and taken out again before the pages are freed. If that fails the pages stay mapped, and are leaked with a warning rather than reused; - memory handed to the heap later (boot modules, .init) is taken out, and is not handed over if that fails; - a PV dom0's initrd, assigned to dom0 in place, is taken out; - page-tables from the boot allocator, which the sparse view maps with every other boot-time allocation, are taken out when idle_pg_table's hierarchy frees them, and are not freed if that fails, so that the sparse view never keeps a page the heap may hand out; - changes to the full directmap through map_pages_to_xen() and modify_xen_mappings() are mirrored. After boot, map_pages_to_xen() maps into the directmap only memory Xen keeps (stack guard and shadow stack pages, firmware tables); memory hot-add maps the new range into the full directmap only, so that the sparse view never needs page-table pages for it. modify_xen_mappings_lite() needs no change: it only changes the mappings of Xen's image, in L4 slot 261, which every root page-table shares with idle_pg_table, outside the range the sparse view replaces. Common code gains four hooks for this, arch_heap_pages_init(), arch_xenheap_needs_scrub() and arch_xenheap_pages_{alloc,free}(), no-ops unless CONFIG_SPARSE_DIRECTMAP is selected. A failed arch_xenheap_pages_alloc() may have mapped part of the pages: alloc_xenheap_pages() then takes them out through arch_xenheap_pages_free(), as a free would, before freeing them, and leaks them if that fails too. xen_mapping_lookup(), built only with CONFIG_SPARSE_DIRECTMAP, reads an entry of either hierarchy under the L3 table lock. alloc_xenheap_pages() accepts pages still awaiting scrubbing (MEMF_no_scrub). That is harmless while the directmap maps all memory anyway, but the sparse view would make such a page's contents, a dying domain's data for instance, reachable from every context on it until overwritten. With a sparse view configured, arch_xenheap_needs_scrub() makes xenheap allocations scrub those pages first, as domain heap allocations do; clean pages need nothing extra. The allocator may still have to scrub a page before returning it; this will be mapped with map_domain_page(). This is fine for HVM domains on the sparse view, as the mapcache is per-vCPU, so no other vCPU can read unscrubbed data. PV domains' mapcache is still per-domain, so for PV domains on the sparse view, this opens up a window where other vCPUs could potentially speculatively access the unscrubbed data. This would be fixed by having per-vCPU mapcaches for PV domains, or synchronously scrubbing pages on free. Neither are in the scope of the current work. arch_mfns_in_directmap() says whether an MFN range is reachable through the directmap; it now answers for every context, so false once a sparse view is configured. Its one caller, init_node_heap(), then keeps a NUMA node's heap metadata in the xenheap instead of carving it out of the node's memory through the directmap: carved out of a range handed to the heap, it would be left out of the sparse view, which every heap allocation needs it in. The sparse view is built only when some domain type is to use it, which nothing can request yet: this patch changes nothing on its own. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Message: "domain type", not "guest type". - Wrap a line that reached 80 columns. - Memory hot-add maps the new range into the full directmap only. - Define opt_sparse_dmap_hwdom here, beside the PV and HVM knobs (Roger). - add_to_sparse_view(): assert that the lookup finds the MFN expected (Roger). - cmp_mfn_range(): explicit return values, as in cmp_node() (Roger). - Comments and variable name changes in sparse_dmap_init()'s loop over the heap's ranges (Roger). - Message: drop "(NUMA node heap metadata)" (Roger). - Message: drop the reference to the directmap removal series (Roger). - Message: modify_xen_mappings_lite() needs no change (Roger). - Message: note the limit of scrubbing at allocation for PV domains (Roger). - Message: only boot and the idle domain keep the full directmap. - Set the NX bit in this patch, rather than adding it in a later patch. Changes in v3: - New in this version. --- xen/arch/x86/Kconfig | 1 + xen/arch/x86/Makefile | 1 + xen/arch/x86/include/asm/mm.h | 16 +- xen/arch/x86/include/asm/sparse-directmap.h | 67 +++ xen/arch/x86/mm.c | 125 +++++- xen/arch/x86/pv/dom0_build.c | 4 + xen/arch/x86/setup.c | 4 + xen/arch/x86/sparse-directmap.c | 431 ++++++++++++++++++++ xen/arch/x86/x86_64/mm.c | 10 +- xen/common/Kconfig | 18 + xen/common/page_alloc.c | 41 +- xen/include/xen/mm.h | 35 ++ 12 files changed, 737 insertions(+), 16 deletions(-) create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h create mode 100644 xen/arch/x86/sparse-directmap.c diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index e5535ac484..cd72102ccc 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -31,6 +31,7 @@ config X86 select HAS_SCHED_GRANULARITY select HAS_SHARED_INFO imply HAS_SOFT_RESET + select HAS_SPARSE_DIRECTMAP select HAS_UBSAN select HAS_VMAP select HAS_VPCI if HVM diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 2be90ea098..86adf042e9 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -63,6 +63,7 @@ obj-y += shutdown.o obj-y += smp.o obj-y += smpboot.o obj-y += spec_ctrl.o +obj-$(CONFIG_SPARSE_DIRECTMAP) += sparse-directmap.o obj-y += srat.o obj-y += string.o obj-$(CONFIG_SYSCTL) += sysctl.o diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 12d1c06c12..7612cf66ef 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -7,6 +7,7 @@ #include #include #include +#include #include /* @@ -597,6 +598,15 @@ mfn_t alloc_xen_pagetable(void); void free_xen_pagetable(mfn_t mfn); void *alloc_mapped_pagetable(mfn_t *pmfn); +int map_pages_in(l4_pgentry_t *root, unsigned long virt, mfn_t mfn, + unsigned long nr_mfns, pte_attr_t flags); +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, unsigned long e, + pte_attr_t nf); +#ifdef CONFIG_SPARSE_DIRECTMAP +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, + pte_attr_t *flags, unsigned long *nr); +#endif + int __sync_local_execstate(void); /* Arch-specific portion of memory_op hypercall. */ @@ -657,12 +667,16 @@ void write_32bit_pse_identmap(uint32_t *l2); /* * x86 maps part of physical memory via the directmap region. - * Return whether the range of MFN falls in the directmap region. + * Return whether the range of MFN falls in the directmap region in every + * context: never, with a sparse directmap view configured. */ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) { unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END); + if ( sparse_dmap_configured() ) + return false; + return (mfn + nr) <= (virt_to_mfn(eva - 1) + 1); } diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h new file mode 100644 index 0000000000..ea14d44334 --- /dev/null +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -0,0 +1,67 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef X86_SPARSE_DIRECTMAP_H +#define X86_SPARSE_DIRECTMAP_H + +#include +#include +#include + +#ifdef CONFIG_SPARSE_DIRECTMAP + +/* + * The part of the directmap the sparse view covers: the part PV guests can + * see, which is where everything Xen reaches through the directmap lives. + * SPARSE_DMAP_END_MFN is the first MFN past it. + */ +#define SPARSE_DMAP_START DIRECTMAP_VIRT_START +#define SPARSE_DMAP_END HYPERVISOR_VIRT_END +#define SPARSE_DMAP_END_MFN (virt_to_mfn(SPARSE_DMAP_END - 1) + 1) + +/* + * Which domains use the sparse view: PV domains and HVM domains other than + * the hardware domain, and the hardware domain, PV or PVH. + */ +extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm, opt_sparse_dmap_hwdom; + +/* Root of the sparse view, once built (NULL before, or if not configured). */ +extern l4_pgentry_t *sparse_dmap_root; + +static inline bool sparse_dmap_configured(void) +{ + return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; +} + +void sparse_dmap_init(void); +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, + pte_attr_t flags); +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf); +int sparse_dmap_remove(mfn_t mfn, unsigned long nr); +int sparse_dmap_drop_pagetable(mfn_t mfn); + +#else /* !CONFIG_SPARSE_DIRECTMAP */ + +static inline bool sparse_dmap_configured(void) { return false; } +static inline void sparse_dmap_init(void) {} +static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, + unsigned long nr, pte_attr_t flags) +{ + return 0; +} +static inline int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf) +{ + return 0; +} +static inline int sparse_dmap_remove(mfn_t mfn, unsigned long nr) +{ + return 0; +} +static inline int sparse_dmap_drop_pagetable(mfn_t mfn) +{ + return 0; +} + +#endif /* CONFIG_SPARSE_DIRECTMAP */ + +#endif /* X86_SPARSE_DIRECTMAP_H */ diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 514e121c8b..7e3009251c 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -127,6 +127,7 @@ #include #include #include +#include #include #include #include @@ -5422,11 +5423,101 @@ mfn_t xen_map_to_mfn(unsigned long va) return ret; } +#ifdef CONFIG_SPARSE_DIRECTMAP +/* + * Look @va up in the hierarchy rooted at @root, without allocating anything. + * Returns the MFN mapped at @va, or INVALID_MFN, with the mapping's flags in + * L1 form in *flags, and in *nr the number of pages from @va to the end of + * the entry that maps @va (or that finds it unmapped). + */ +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, + pte_attr_t *flags, unsigned long *nr) +{ + bool locking = system_state > SYS_STATE_boot; + l4_pgentry_t l4e = root[l4_table_offset(va)]; + const l3_pgentry_t *pl3e = NULL; + const l2_pgentry_t *pl2e = NULL; + const l1_pgentry_t *pl1e = NULL; + struct page_info *l3page; + unsigned int shift = L4_PAGETABLE_SHIFT; + mfn_t ret = INVALID_MFN; + + L3T_INIT(l3page); + *flags = 0; + + if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) ) + goto out; + + pl3e = map_l3t_from_l4e(l4e) + l3_table_offset(va); + l3page = l4e_get_page(l4e); + L3T_LOCK(l3page); + + shift = L3_PAGETABLE_SHIFT; + if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) ) + goto out; + if ( l3e_get_flags(*pl3e) & _PAGE_PSE ) + { + /* The superpage PAT bit sits among the address bits. */ + *flags = lNf_to_l1f(l3e_get_flags(*pl3e)) | + (l3e_get_intpte(*pl3e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); + ret = _mfn((l3e_get_pfn(*pl3e) & + ~((1UL << (2 * PAGETABLE_ORDER)) - 1)) + + (PFN_DOWN(va) & ((1UL << (2 * PAGETABLE_ORDER)) - 1))); + goto out; + } + + pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(va); + shift = L2_PAGETABLE_SHIFT; + if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) + goto out; + if ( l2e_get_flags(*pl2e) & _PAGE_PSE ) + { + *flags = lNf_to_l1f(l2e_get_flags(*pl2e)) | + (l2e_get_intpte(*pl2e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); + ret = _mfn((l2e_get_pfn(*pl2e) & ~((1UL << PAGETABLE_ORDER) - 1)) + + l1_table_offset(va)); + goto out; + } + + pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(va); + shift = PAGE_SHIFT; + if ( l1e_get_flags(*pl1e) & _PAGE_PRESENT ) + { + *flags = l1e_get_flags(*pl1e); + ret = l1e_get_mfn(*pl1e); + } + + out: + L3T_UNLOCK(l3page); + unmap_domain_page(pl1e); + unmap_domain_page(pl2e); + unmap_domain_page(pl3e); + *nr = ((((va >> shift) + 1) << shift) - va) >> PAGE_SHIFT; + return ret; +} +#endif /* CONFIG_SPARSE_DIRECTMAP */ + +/* + * Free a page-table page that the hierarchy rooted at @root has stopped + * using. One of idle_pg_table's may be in the sparse directmap view: it is + * taken out first, under the sparse view's L3 lock inside an L3 lock of + * idle_pg_table's hierarchy (the only order in which the two nest), and + * kept if that fails. The sparse view's own page-tables are not in it, and + * are freed directly: the caller may hold the sparse view's L3 lock. + */ +static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) +{ + if ( root == idle_pg_table && sparse_dmap_drop_pagetable(mfn) ) + return; + + free_xen_pagetable(mfn); +} + /* * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or * another hierarchy sharing its virtual addresses. */ -static int map_pages_in( +int map_pages_in( l4_pgentry_t *root, unsigned long virt, mfn_t mfn, @@ -5531,10 +5622,10 @@ static int map_pages_in( ol2e = l2t[i]; if ( (l2e_get_flags(ol2e) & _PAGE_PRESENT) && !(l2e_get_flags(ol2e) & _PAGE_PSE) ) - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } unmap_domain_page(l2t); - free_xen_pagetable(l3e_get_mfn(ol3e)); + free_pagetable_in(root, l3e_get_mfn(ol3e)); } } @@ -5632,7 +5723,7 @@ static int map_pages_in( flush_flags(l1e_get_flags(l1t[i])); flush_area(virt, flush_flags); unmap_domain_page(l1t); - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } } @@ -5764,7 +5855,7 @@ static int map_pages_in( flush_area(virt - PAGE_SIZE, FLUSH_TLB_GLOBAL | FLUSH_ORDER(PAGETABLE_ORDER)); - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -5811,7 +5902,7 @@ static int map_pages_in( flush_area(virt - PAGE_SIZE, FLUSH_TLB_GLOBAL | FLUSH_ORDER(2*PAGETABLE_ORDER)); - free_xen_pagetable(l3e_get_mfn(ol3e)); + free_pagetable_in(root, l3e_get_mfn(ol3e)); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -5838,7 +5929,12 @@ int map_pages_to_xen( unsigned long nr_mfns, pte_attr_t flags) { - return map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); + int rc = map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); + + if ( !rc ) + rc = sparse_dmap_mirror_map(virt, mfn, nr_mfns, flags); + + return rc; } int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) @@ -5861,8 +5957,8 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * modify_mappings_in() does so in the hierarchy rooted at @root, as * map_pages_in() does. */ -static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, - unsigned long e, pte_attr_t nf) +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, + unsigned long e, pte_attr_t nf) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -6072,7 +6168,7 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, if ( locking ) spin_unlock(&map_pgdir_lock); flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ - free_xen_pagetable(l1mfn); + free_pagetable_in(root, l1mfn); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -6116,7 +6212,7 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, if ( locking ) spin_unlock(&map_pgdir_lock); flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ - free_xen_pagetable(l2mfn); + free_pagetable_in(root, l2mfn); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -6142,7 +6238,12 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) { - return modify_mappings_in(idle_pg_table, s, e, nf); + int rc = modify_mappings_in(idle_pg_table, s, e, nf); + + if ( !rc ) + rc = sparse_dmap_mirror_modify(s, e, nf); + + return rc; } int destroy_xen_mappings(unsigned long s, unsigned long e) diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index dcb1d407ec..f18959f3b4 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -22,6 +22,7 @@ #include #include #include +#include /* Allow ring-3 access in long mode as guest cannot use ring 1 ... */ #define BASE_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_USER) @@ -650,6 +651,9 @@ static int __init dom0_construct(const struct boot_domain *bd) { if ( assign_pages(mfn_to_page(_mfn(initrd_mfn)), count, d, 0) ) BUG(); + /* The initrd is dom0's now: out of the sparse directmap. */ + if ( sparse_dmap_remove(_mfn(initrd_mfn), PFN_UP(initrd_len)) ) + panic("Cannot unmap dom0's initrd\n"); /* * We have mapped the initrd directly into dom0, and assigned the * pages. Tell the boot_module handling that we've freed it, so the diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index fef3c2dd44..f95aa36e05 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -54,6 +54,7 @@ #include #include #include +#include #include #include @@ -1944,6 +1945,9 @@ void asmlinkage __init noreturn __start_xen(void) system_state = SYS_STATE_boot; + /* The heap now has all memory: page-tables come from it from here on. */ + sparse_dmap_init(); + bsp_stack = cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ if ( !bsp_stack ) panic("No memory for BSP stack\n"); diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c new file mode 100644 index 0000000000..d35a8d6979 --- /dev/null +++ b/xen/arch/x86/sparse-directmap.c @@ -0,0 +1,431 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * A sparse view of the directmap. + * + * Xen maps all of RAM at DIRECTMAP_VIRT_START, and every root page-table + * carries those mappings. The sparse view is a second set of page-tables + * for the same virtual addresses (the part of the directmap PV guests can + * see), mapping only what Xen needs to reach through the directmap at all + * times: + * + * - Memory never handed to the heap: Xen's image, boot-time allocations, + * firmware tables. Not a PV dom0's initrd, used in place, nor the frame + * table and M2P pages carved from hot-added memory. + * - Memory handed to the heap, then allocated to the xenheap. + * + * The rest of the heap's memory, where guest memory comes from, is not + * mapped. Every mapping in the sparse view is either identical to the + * full directmap's at the same address, or empty. + * + * Guest contexts selected on the command line run on root page-tables + * carrying the sparse view's L3s in the directmap slots. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +bool __ro_after_init opt_sparse_dmap_pv; +bool __ro_after_init opt_sparse_dmap_hvm; +bool __ro_after_init opt_sparse_dmap_hwdom; + +/* Root of the sparse view: only ever walked and copied from, never loaded. */ +static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIES]; +l4_pgentry_t *__ro_after_init sparse_dmap_root; + +/* + * Before the sparse view is built: the MFN ranges handed to the heap, which + * it leaves out, and the xenheap allocations made since, which it puts back. + */ +struct mfn_range { + unsigned long s, e; +}; +static struct mfn_range early_heap[256]; +static unsigned int nr_early_heap; +static struct mfn_range early_xenheap[2 * MAX_NUMNODES]; +static unsigned int nr_early_xenheap; +static bool early_overflow; + +/* + * Clip [*mfn, *mfn + *nr) to what the sparse view covers; false if nothing is + * left. + */ +static bool clip_to_sparse_view(unsigned long *mfn, unsigned long *nr) +{ + unsigned long end = SPARSE_DMAP_END_MFN; + + if ( *mfn >= end ) + return false; + if ( *nr > end - *mfn ) + *nr = end - *mfn; + + return *nr; +} + +static void early_range_add(struct mfn_range *r, unsigned int *nr, + unsigned int max, unsigned long s, unsigned long e) +{ + if ( *nr && r[*nr - 1].e == s ) + r[*nr - 1].e = e; + else if ( *nr < max ) + r[(*nr)++] = (struct mfn_range){ s, e }; + else + early_overflow = true; +} + +static void early_range_del(struct mfn_range *r, unsigned int *nr, + unsigned long s, unsigned long e) +{ + unsigned int i; + + for ( i = 0; i < *nr; i++ ) + if ( r[i].s == s && r[i].e == e ) + { + r[i] = r[--*nr]; + return; + } +} + +/* + * Copy the full directmap's mappings of MFNs [mfn, mfn + nr) into the sparse + * view. + */ +static int add_to_sparse_view(l4_pgentry_t *root, unsigned long mfn, + unsigned long nr) +{ + unsigned long start = (unsigned long)mfn_to_virt(mfn); + unsigned long va = start, end = start + (nr << PAGE_SHIFT); + + while ( va < end ) + { + pte_attr_t flags; + unsigned long n; + mfn_t va_mfn = xen_mapping_lookup(idle_pg_table, va, &flags, &n); + int rc; + + ASSERT(mfn_eq(va_mfn, INVALID_MFN) || + mfn_x(va_mfn) == mfn + ((va - start) >> PAGE_SHIFT)); + n = min(n, (end - va) >> PAGE_SHIFT); + if ( !mfn_eq(va_mfn, INVALID_MFN) && + (rc = map_pages_in(root, va, va_mfn, n, flags)) ) + return rc; + va += n << PAGE_SHIFT; + } + + return 0; +} + +static int remove_from_sparse_view(unsigned long mfn, unsigned long nr) +{ + unsigned long va = (unsigned long)mfn_to_virt(mfn); + + return modify_mappings_in(sparse_dmap_root, va, va + (nr << PAGE_SHIFT), + _PAGE_NONE); +} + +/* Memory is about to be handed to the heap allocator. */ +bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) +{ + unsigned long s = mfn_x(mfn); + + if ( !sparse_dmap_configured() || !clip_to_sparse_view(&s, &nr) ) + return true; + + if ( !sparse_dmap_root ) + { + early_range_add(early_heap, &nr_early_heap, ARRAY_SIZE(early_heap), + s, s + nr); + return true; + } + + if ( remove_from_sparse_view(s, nr) ) + { + printk(XENLOG_ERR + "sparse directmap: cannot unmap MFNs %#lx-%#lx, not freeing\n", + s, s + nr - 1); + return false; + } + + return true; +} + +/* + * Xenheap pages enter the sparse view, which guest contexts run on: those + * still holding a previous owner's data must be scrubbed first. + */ +bool arch_xenheap_needs_scrub(void) +{ + return sparse_dmap_configured(); +} + +/* Pages have been allocated from the heap as xenheap pages. */ +int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) +{ + unsigned long s = mfn_x(mfn), nr = 1UL << order; + + if ( !sparse_dmap_configured() ) + return 0; + + /* Xenheap pages must be reachable through the sparse view. */ + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); + + if ( !sparse_dmap_root ) + { + early_range_add(early_xenheap, &nr_early_xenheap, + ARRAY_SIZE(early_xenheap), s, s + nr); + return 0; + } + + return add_to_sparse_view(sparse_dmap_root, s, nr); +} + +/* + * Xenheap pages are about to be freed. A failure means the pages may still + * be reachable through the sparse view, and must not be reused. + */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +{ + unsigned long s = mfn_x(mfn), nr = 1UL << order; + + if ( !sparse_dmap_configured() ) + return 0; + + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); + + if ( !sparse_dmap_root ) + { + early_range_del(early_xenheap, &nr_early_xenheap, s, s + nr); + return 0; + } + + return remove_from_sparse_view(s, nr); +} + +/* Memory leaves Xen's hands without passing through the heap. */ +int sparse_dmap_remove(mfn_t mfn, unsigned long nr) +{ + return arch_heap_pages_init(mfn, nr) ? 0 : -ENOMEM; +} + +/* + * A page-table page of idle_pg_table's hierarchy is about to be freed. One + * the boot allocator provided is in the sparse view, as every boot-time + * allocation is: take it out before the heap may hand it on. One allocated + * since came from the heap and is not in the sparse view, which a lookup + * finds without changing, or flushing, anything. Non-zero: the page may + * still be mapped, and must not be freed. + */ +int sparse_dmap_drop_pagetable(mfn_t mfn) +{ + unsigned long s = mfn_x(mfn), nr = 1, n; + pte_attr_t flags; + int rc; + + if ( !sparse_dmap_root || !clip_to_sparse_view(&s, &nr) || + mfn_eq(xen_mapping_lookup(sparse_dmap_root, + (unsigned long)mfn_to_virt(s), &flags, &n), + INVALID_MFN) ) + return 0; + + rc = remove_from_sparse_view(s, 1); + if ( rc ) + printk(XENLOG_WARNING + "Leaking page-table page %"PRI_mfn": still in the sparse directmap\n", + mfn_x(mfn)); + + return rc; +} + +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, + pte_attr_t flags) +{ + if ( !sparse_dmap_root || virt < SPARSE_DMAP_START || + virt >= SPARSE_DMAP_END ) + return 0; + + nr = min(nr, (SPARSE_DMAP_END - virt) >> PAGE_SHIFT); + + return map_pages_in(sparse_dmap_root, virt, mfn, nr, flags); +} + +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf) +{ + unsigned long va; + + if ( !sparse_dmap_root || e <= SPARSE_DMAP_START || + s >= SPARSE_DMAP_END ) + return 0; + + s = max(s, SPARSE_DMAP_START); + e = min(e, SPARSE_DMAP_END); + + if ( !(nf & _PAGE_PRESENT) ) + return modify_mappings_in(sparse_dmap_root, s, e, nf); + + /* + * A permission change applies where the sparse view maps anything: it + * never creates mappings, and the sparse view need not map all of [s, e). + */ + for ( va = s; va < e; ) + { + pte_attr_t flags; + unsigned long n; + mfn_t mfn = xen_mapping_lookup(sparse_dmap_root, va, &flags, &n); + int rc; + + n = min(n, (e - va) >> PAGE_SHIFT); + if ( !mfn_eq(mfn, INVALID_MFN) && + (rc = modify_mappings_in(sparse_dmap_root, va, + va + (n << PAGE_SHIFT), nf)) ) + return rc; + va += n << PAGE_SHIFT; + } + + return 0; +} + +static int __init cf_check cmp_mfn_range(const void *a, const void *b) +{ + const struct mfn_range *l = a, *r = b; + + if ( l->s > r->s ) + return 1; + if ( l->s < r->s ) + return -1; + + return 0; +} + +static void __init cf_check swap_mfn_range(void *a, void *b) +{ + SWAP(*(struct mfn_range *)a, *(struct mfn_range *)b); +} + +/* + * Build the sparse view: the full directmap, minus the ranges handed to the + * heap so far, plus the xenheap allocations made from them. Called once the + * heap has taken over from the boot allocator, so that the page-tables come + * from the heap, and before any other CPU is up. + */ +void __init sparse_dmap_init(void) +{ + unsigned long va, mapped = 0; + unsigned int i, heap_idx; + + if ( !sparse_dmap_configured() ) + return; + + if ( early_overflow ) + { + printk(XENLOG_WARNING + "Sparse directmap: too many early heap ranges, disabled\n"); + opt_sparse_dmap_pv = opt_sparse_dmap_hvm = opt_sparse_dmap_hwdom = + false; + return; + } + + /* An L3 for every slot, so that the L4 entries never change. */ + for ( va = SPARSE_DMAP_START; va < SPARSE_DMAP_END; + va += 1UL << L4_PAGETABLE_SHIFT ) + { + mfn_t l3mfn; + void *l3t = alloc_mapped_pagetable(&l3mfn); + + if ( !l3t ) + panic("Sparse directmap: out of memory\n"); + unmap_domain_page(l3t); + sparse_l4[l4_table_offset(va)] = + l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR); + } + + sort(early_heap, nr_early_heap, sizeof(*early_heap), cmp_mfn_range, + swap_mfn_range); + + /* + * The full directmap, leaf by leaf, minus the ranges added to the + * heap. Leaves come in address order, which is MFN order in the + * directmap, and the heap ranges are sorted and disjoint, so + * heap_idx only moves forward. + */ + for ( va = SPARSE_DMAP_START, heap_idx = 0; va < SPARSE_DMAP_END; ) + { + pte_attr_t flags; + unsigned long n, s, e; + + /* Get information about the leaf PTE at va. */ + mfn_t mfn = xen_mapping_lookup(idle_pg_table, va, &flags, &n); + + /* Clip the va range we're considering to SPARSE_DMAP_END. */ + n = min(n, (SPARSE_DMAP_END - va) >> PAGE_SHIFT); + if ( mfn_eq(mfn, INVALID_MFN) ) + { + va += n << PAGE_SHIFT; + continue; + } + + /* + * Walk through the range [mfn, mfn + n) looking for ranges not + * handed to the heap. + */ + for ( s = mfn_x(mfn), e = s + n; s < e; ) + { + unsigned long upto = e; + + /* Step past heap ranges that end at or before s. */ + while ( heap_idx < nr_early_heap && early_heap[heap_idx].e <= s ) + heap_idx++; + + /* s lies in a heap range: skip to its end. */ + if ( heap_idx < nr_early_heap && early_heap[heap_idx].s <= s ) + { + s = min(e, early_heap[heap_idx].e); + continue; + } + + /* Map up to the next heap range, or to the end of the leaf. */ + if ( heap_idx < nr_early_heap ) + upto = min(e, early_heap[heap_idx].s); + + if ( map_pages_in(sparse_l4, va + ((s - mfn_x(mfn)) << PAGE_SHIFT), + _mfn(s), upto - s, flags) ) + panic("Sparse directmap: out of memory\n"); + mapped += upto - s; + s = upto; + } + + va += n << PAGE_SHIFT; + } + + /* + * Now add back in ranges from the heap which were allocated to + * the xenheap. + */ + for ( i = 0; i < nr_early_xenheap; i++ ) + { + unsigned long nr = early_xenheap[i].e - early_xenheap[i].s; + + if ( add_to_sparse_view(sparse_l4, early_xenheap[i].s, nr) ) + panic("Sparse directmap: out of memory\n"); + mapped += nr; + } + + /* + * Nothing in the directmap is executed: its slots are NX, as the full + * directmap's are. + */ + if ( cpu_has_nx ) + for ( i = l4_table_offset(SPARSE_DMAP_START); + i < l4_table_offset(SPARSE_DMAP_END); i++ ) + l4e_add_flags(sparse_l4[i], _PAGE_NX_BIT); + + sparse_dmap_root = sparse_l4; + + printk(XENLOG_INFO "Sparse directmap: %lu pages mapped\n", mapped); +} diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 7b04537066..c5d9dd64a3 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -1231,8 +1231,14 @@ int memory_add(unsigned long spfn, unsigned long epfn, unsigned int pxm) i = virt_to_mfn(HYPERVISOR_VIRT_END - 1) + 1; if ( spfn < i ) { - ret = map_pages_to_xen((unsigned long)mfn_to_virt(spfn), _mfn(spfn), - min(epfn, i) - spfn, PAGE_HYPERVISOR); + /* + * Into the full directmap only, not a sparse directmap view: the + * frame table and M2P carved from the start of the range are + * reached through their own mappings, and the rest goes to the + * heap, which the sparse view leaves out. + */ + ret = map_pages_in(idle_pg_table, (unsigned long)mfn_to_virt(spfn), + _mfn(spfn), min(epfn, i) - spfn, PAGE_HYPERVISOR); if ( ret ) goto destroy_directmap; } diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 5b289e444f..8f2f605e45 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -167,6 +167,9 @@ config HAS_STATIC_MEMORY config HAS_SOFT_RESET bool +config HAS_SPARSE_DIRECTMAP + bool + config HAS_STACK_PROTECTOR bool @@ -299,6 +302,21 @@ config SPECULATIVE_HARDEN_LOCK This option is disabled by default at run time, and needs to be enabled on the command line. + +config SPARSE_DIRECTMAP + bool "Sparse directmap view" + depends on HAS_SPARSE_DIRECTMAP + help + Build support for a sparse view of the directmap, alongside the + full one: it maps only the memory Xen needs to reach at all times + (the Xen heap, Xen's own image, firmware tables), while guest + memory is reached through transient mappings. Guest contexts + selected with the `asi=` command line option run on the sparse + directmap view, narrowing the memory reachable from Xen's address + space while they run, and hence the memory disclosure surface of + speculative side channels. + + If unsure, say N. endmenu menu "Other hardening" diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index fe150eccd7..69e8e982b6 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1971,6 +1971,9 @@ static void init_heap_pages( unsigned long i; bool need_scrub = scrub_debug; + if ( !arch_heap_pages_init(page_to_mfn(pg), nr_pages) ) + return; + /* * Keep MFN 0 away from the buddy allocator to avoid crossing zone * boundary when merging two buddies. @@ -2540,10 +2543,33 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags) if ( !(memflags >> _MEMF_bits) ) memflags |= MEMF_bits(xenheap_bits); - pg = alloc_domheap_pages(NULL, order, memflags | MEMF_no_scrub); + /* + * Pages still awaiting scrubbing may do as xenheap pages: the directmap + * maps them anyway. Not so if an arch's sparse directmap view makes them + * reachable where the rest of the heap's memory is not. + */ + if ( !arch_xenheap_needs_scrub() ) + memflags |= MEMF_no_scrub; + + pg = alloc_domheap_pages(NULL, order, memflags); if ( unlikely(pg == NULL) ) return NULL; + if ( arch_xenheap_pages_alloc(page_to_mfn(pg), order) ) + { + /* + * The hook may have mapped part of the pages before failing: take + * them out again as a free would, and leak them if that fails too. + */ + if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + printk(XENLOG_WARNING + "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", + mfn_x(page_to_mfn(pg)), 1U << order); + else + free_domheap_pages(pg, order); + return NULL; + } + for ( i = 0; i < (1u << order); i++ ) pg[i].count_info |= PGC_xen_heap; @@ -2562,6 +2588,19 @@ void free_xenheap_pages(void *v, unsigned int order) pg = virt_to_page(v); + /* + * If the pages cannot be taken out of an arch's sparse directmap view, + * they may remain reachable through it: leak them rather than hand them + * out. + */ + if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + { + printk(XENLOG_WARNING + "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", + mfn_x(page_to_mfn(pg)), 1U << order); + return; + } + for ( i = 0; i < (1u << order); i++ ) pg[i].count_info &= ~PGC_xen_heap; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 153c57f5dd..2bcc45cf58 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -94,6 +94,41 @@ bool scrub_free_pages(void); #define alloc_xenheap_page() (alloc_xenheap_pages(0,0)) #define free_xenheap_page(v) (free_xenheap_pages(v,0)) +/* + * Hooks for an architecture keeping a second, sparse view of its directmap, + * which maps the xenheap but not the rest of the heap's memory. + */ +#ifdef CONFIG_SPARSE_DIRECTMAP +/* Memory is about to be handed to the heap. False: don't, keep it out. */ +bool arch_heap_pages_init(mfn_t mfn, unsigned long nr); +/* Xenheap pages are to be allocated. True: scrub those needing it first. */ +bool arch_xenheap_needs_scrub(void); +/* + * Xenheap pages were allocated. Non-zero: failed, possibly part-way; the + * pages go through arch_xenheap_pages_free() before being freed again. + */ +int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order); +/* Xenheap pages are to be freed. Non-zero: failed, don't reuse them. */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order); +#else +static inline bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) +{ + return true; +} +static inline bool arch_xenheap_needs_scrub(void) +{ + return false; +} +static inline int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) +{ + return 0; +} +static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +{ + return 0; +} +#endif + /* Free an allocation, and zero the pointer to it. */ #define FREE_XENHEAP_PAGES(p, o) do { \ void *_ptr_ = (p); \ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454850.1668509 (Exim 4.92) (envelope-from ) id 1xItSJ-0007cy-0i; Mon, 19 Oct 2026 19:55:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454850.1668509; Mon, 19 Oct 2026 19:55: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 1xItSH-0007W8-5d; Mon, 19 Oct 2026 19:55:33 +0000 Received: by outflank-mailman (input) for mailman id 1454850; Mon, 19 Oct 2026 19:55:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItS4-0004uj-Sc for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022zs-3hwi; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGX-00000001FjN-2QLd; Mon, 19 Oct 2026 19:43: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" 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=eMzms4kJ3QFpMQV91hrT3uRFSRB8DVNpEMsCuiyn6Aw=; b=ZmsEhrIAG33dUiD+l1lP8dUZ1k 3oQuYQq/BVvuSK2DZ6UX6oJ7RMQ0bqZo5aPg3SSnZrUuEyiZiIJ1iLCk2wiEBw/tZUvngtN4j517h dSVvxwiClkKUTO7hl+/JYXm5pONe6ykfViJIk5CLveNIY+S/zQZ2p3sI3u1M6UJm9+ms=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 10/30] x86/domain_page: drop redundant is_pv_vcpu() checks Date: Mon, 19 Oct 2026 20:42:41 +0100 Message-ID: <20261019-asi-hvm-v4-10-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The is_pv_vcpu() checks after mapcache_current_vcpu() never fail: they have been redundant since 622c9a5ba95d ("x86/mm: accurately track which vCPU page-tables are loaded") made mapcache_current_vcpu() do the check itself. mapcache_current_vcpu() is now guaranteed to return a PV vCPU with a caching structure (which is what is needed for the subsequent dcache->inuse check): either a scheduled PV vCPU, or this CPU's idle vCPU (possibly after finishing a lazy context switch). Drop the checks; their speculation barriers (evaluate_nospec()) go too. mapcache_current_vcpu() returns NULL if this CPU's pgtable_vcpu is not yet set (early boot) or is not a PV vCPU. Otherwise it reads pgtable_vcpu again and returns that. In between, pgtable_vcpu changes only when a lazy context switch from a PV vCPU is completed, by mapcache_current_vcpu() itself (sync_local_execstate()) or first by an interrupt such as a FLUSH_VCPU_STATE IPI; completing it loads the idle vCPU's page-tables and sets pgtable_vcpu to the idle vCPU. No other writer of pgtable_vcpu runs in an interrupt that returns to the code it interrupted. During an EFI runtime call pgtable_vcpu is the idle vCPU: efi_rs_enter() completes any lazy switch, then loads EFI's page-tables, which carry the directmap. So the vCPU returned is either the PV vCPU checked or this CPU's idle vCPU. The idle vCPU passes is_pv_vcpu(), as the idle domain is created without XEN_DOMCTL_CDF_hvm, but its mapcache is never set up: domain_create() returns for the idle domain before calling arch_domain_create(), which is what calls mapcache_domain_init(). With its dcache->inuse NULL, map_domain_page() uses the directmap, and unmap_domain_page()'s ASSERT() on dcache->inuse still catches a mapcache address unmapped with no mapcache in use. In builds without CONFIG_PV, is_pv_vcpu() is always false and mapcache_current_vcpu() always returns NULL. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version, split out of "x86/domain_page: prepare the mapcache for per-vCPU accounting", with a justification of its own. NB I've included Claude's complete analysis in the commit message. I've reworded the commit message so that the middle two paragraphs can be dropped, or reworded more briefly on commit. --- xen/arch/x86/domain_page.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index f3e65e2d44..ed68483695 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -74,7 +74,7 @@ void *map_domain_page(mfn_t mfn) #endif v = mapcache_current_vcpu(); - if ( !v || !is_pv_vcpu(v) ) + if ( !v ) return mfn_to_virt(mfn_x(mfn)); dcache = &v->domain->arch.pv.mapcache; @@ -179,7 +179,7 @@ void unmap_domain_page(const void *ptr) ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END); v = mapcache_current_vcpu(); - ASSERT(v && is_pv_vcpu(v)); + ASSERT(v); dcache = &v->domain->arch.pv.mapcache; ASSERT(dcache->inuse); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454851.1668515 (Exim 4.92) (envelope-from ) id 1xItSK-0007vI-1c; Mon, 19 Oct 2026 19:55:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454851.1668515; Mon, 19 Oct 2026 19:55: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 1xItSI-0007r6-QH; Mon, 19 Oct 2026 19:55:34 +0000 Received: by outflank-mailman (input) for mailman id 1454851; Mon, 19 Oct 2026 19:55:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItS4-0004vB-TC for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022zw-3qRA; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGl-00000001FjN-0CHb; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=LeUN4GWtDg25LdWPguyYFlprUdbIgPn6gxNUTDepJeY=; b=hnt901M2zDsh7qOiplQLH+lttG ZIewuytRXco8S5EaFg5m7vVL+ERIbqIQSDb3K63SXuDxtpiEmCFAz23l/r2RFs6p/67N5CvAIvHo7 /Itu3oUx8U3F/4f22ni/Gw1n6A+4ghpeZQ+1wZUDayOWVvVEmq4NhBwhKWygtZuuGDcY=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v4 22/30] x86/mm: split a sparse directmap superpage with a page being freed Date: Mon, 19 Oct 2026 20:42:53 +0100 Message-ID: <20261019-asi-hvm-v4-22-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A xenheap free takes its pages out of the sparse directmap view. Where a superpage covers them, the superpage has to be split, and modify_mappings_in() allocates the page-table page for that. The sparse view has such superpages wherever a xenheap block of 2MiB or more was mapped whole, and wherever map_pages_in() merged the entries of a 2MiB region into one, as it does in the full directmap, once all 512 pages were mapped. The allocation can fail once the hardware domain exists, and the free then keeps its pages out of the heap for good, with a warning. Use one of the pages being freed instead. The sparse view's free hook makes the first of them what alloc_xen_pagetable() would return, and passes it to modify_mappings_in(), which uses it, should a split need a page, before allocating one. The new L1 maps the rest of the superpage, and the page's own entry is cleared along with the others being freed. The hook tells free_xenheap_pages() whether it kept the page, and free_xenheap_pages() then frees the rest of the block as blocks of orders 0 to order - 1. The page goes back to the heap once the L1 has emptied, as any page-table page of the sparse view does. One page is enough if the sparse view has no 1GiB pages: a block smaller than 2MiB lies within one 2MiB page and needs one L1, and a larger block covers whole 2MiB pages and needs none, where a block within a 1GiB page could need an L2 as well. So map_pages_in() makes 1GiB pages, by mapping or by merging, only in idle_pg_table's hierarchy; the sparse view keeps its 2MiB pages, mapped and merged. A xenheap free then allocates nothing in the sparse view. The costs: a 2MiB region split this way can merge again only once it has emptied, as its L1 is one of its own pages; where the sparse view maps a whole 1GiB region, which takes memory never handed to the heap and xenheap memory filling it, contexts on it use 2MiB pages instead of one 1GiB page; and arch_xenheap_pages_free() gains a parameter. The other removals from the sparse view (memory handed to the heap, idle_pg_table's boot-time page-tables, and the undo of a failed xenheap allocation) still allocate when they split a superpage. The sparse view is correct without this, as a free that cannot split its superpage fails safe. It is kept apart from "x86/mm: build and maintain a sparse view of the directmap" so that it can be weighed on its own. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- xen/arch/x86/include/asm/mm.h | 2 +- xen/arch/x86/mm.c | 34 ++++++++++++++++++++++------ xen/arch/x86/sparse-directmap.c | 40 ++++++++++++++++++++++++++------- xen/common/page_alloc.c | 14 ++++++++---- xen/include/xen/mm.h | 11 ++++++--- 5 files changed, 78 insertions(+), 23 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 7612cf66ef..af43ae01b0 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -601,7 +601,7 @@ void *alloc_mapped_pagetable(mfn_t *pmfn); int map_pages_in(l4_pgentry_t *root, unsigned long virt, mfn_t mfn, unsigned long nr_mfns, pte_attr_t flags); int modify_mappings_in(l4_pgentry_t *root, unsigned long s, unsigned long e, - pte_attr_t nf); + pte_attr_t nf, mfn_t *spare); #ifdef CONFIG_SPARSE_DIRECTMAP mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, pte_attr_t *flags, unsigned long *nr); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 7b5a355e6e..449ae561dc 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5540,6 +5540,10 @@ static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) /* * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or * another hierarchy sharing its virtual addresses. + * + * Only idle_pg_table's hierarchy gets 1GiB pages: a xenheap free splits a + * superpage of the sparse directmap view with one of the pages it frees, + * which is enough for a 2MiB page only. */ int map_pages_in( l4_pgentry_t *root, @@ -5549,6 +5553,7 @@ int map_pages_in( pte_attr_t flags) { bool locking = system_state > SYS_STATE_boot; + bool page1gb = cpu_has_page1gb && root == idle_pg_table; l3_pgentry_t *pl3e = NULL, ol3e; l2_pgentry_t *pl2e = NULL, ol2e; l1_pgentry_t *pl1e, ol1e; @@ -5601,7 +5606,7 @@ int map_pages_in( L3T_LOCK(current_l3page); ol3e = *pl3e; - if ( cpu_has_page1gb && + if ( page1gb && IS_L3E_ALIGNED(virt, flags & _PAGE_PRESENT ? mfn : _mfn(0)) && nr_mfns >= (1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT)) && !(flags & (_PAGE_PAT | MAP_SMALL_PAGES)) ) @@ -5887,7 +5892,7 @@ int map_pages_in( } check_l3: - if ( cpu_has_page1gb && + if ( page1gb && (flags == PAGE_HYPERVISOR) && ((nr_mfns == 0) || IS_L3E_ALIGNED(virt, mfn)) ) { @@ -5966,6 +5971,18 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) return map_pages_to_xen(virt, INVALID_MFN, nr_mfns, MAP_SMALL_PAGES); } +static mfn_t take_or_alloc_pagetable(mfn_t *spare) +{ + mfn_t mfn = spare ? *spare : INVALID_MFN; + + if ( mfn_eq(mfn, INVALID_MFN) ) + return alloc_xen_pagetable(); + + *spare = INVALID_MFN; + + return mfn; +} + /* * Alter the permissions of a range of Xen virtual address space. * @@ -5979,10 +5996,13 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * It is an error to call with present flags over an unpopulated range. * * modify_mappings_in() does so in the hierarchy rooted at @root, as - * map_pages_in() does. + * map_pages_in() does. @spare, if not NULL, may hold a page the caller + * gives up for a page-table page, which shattering a superpage then uses + * before allocating one. *@spare reads INVALID_MFN once it has been used, + * and the page is then no longer the caller's. */ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, - unsigned long e, pte_attr_t nf) + unsigned long e, pte_attr_t nf, mfn_t *spare) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -6046,7 +6066,7 @@ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, } /* PAGE1GB: shatter the superpage and fall through. */ - l2mfn = alloc_xen_pagetable(); + l2mfn = take_or_alloc_pagetable(spare); if ( mfn_eq(l2mfn, INVALID_MFN) ) goto out; @@ -6104,7 +6124,7 @@ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, { l1_pgentry_t *l1t; /* PSE: shatter the superpage and try again. */ - mfn_t l1mfn = alloc_xen_pagetable(); + mfn_t l1mfn = take_or_alloc_pagetable(spare); if ( mfn_eq(l1mfn, INVALID_MFN) ) goto out; @@ -6262,7 +6282,7 @@ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) { - int rc = modify_mappings_in(idle_pg_table, s, e, nf); + int rc = modify_mappings_in(idle_pg_table, s, e, nf, NULL); if ( !rc ) rc = sparse_dmap_mirror_modify(s, e, nf); diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c index d35a8d6979..adec474f72 100644 --- a/xen/arch/x86/sparse-directmap.c +++ b/xen/arch/x86/sparse-directmap.c @@ -121,12 +121,13 @@ static int add_to_sparse_view(l4_pgentry_t *root, unsigned long mfn, return 0; } -static int remove_from_sparse_view(unsigned long mfn, unsigned long nr) +static int remove_from_sparse_view(unsigned long mfn, unsigned long nr, + mfn_t *spare) { unsigned long va = (unsigned long)mfn_to_virt(mfn); return modify_mappings_in(sparse_dmap_root, va, va + (nr << PAGE_SHIFT), - _PAGE_NONE); + _PAGE_NONE, spare); } /* Memory is about to be handed to the heap allocator. */ @@ -144,7 +145,7 @@ bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) return true; } - if ( remove_from_sparse_view(s, nr) ) + if ( remove_from_sparse_view(s, nr, NULL) ) { printk(XENLOG_ERR "sparse directmap: cannot unmap MFNs %#lx-%#lx, not freeing\n", @@ -188,10 +189,18 @@ int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) /* * Xenheap pages are about to be freed. A failure means the pages may still * be reachable through the sparse view, and must not be reused. + * + * If the caller allows, the first page serves as the page-table page that + * splitting a superpage of the sparse view needs: the new L1 maps the rest + * of the superpage, and the page leaves the sparse view with the others. + * One page is enough: the sparse view has no 1GiB pages, a block below 2MiB + * lies within one 2MiB page, and a larger one covers whole ones. */ -int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order, bool *first_kept) { unsigned long s = mfn_x(mfn), nr = 1UL << order; + mfn_t spare = INVALID_MFN; + int rc; if ( !sparse_dmap_configured() ) return 0; @@ -204,7 +213,22 @@ int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) return 0; } - return remove_from_sparse_view(s, nr); + if ( first_kept ) + { + struct page_info *pg = mfn_to_page(mfn); + + /* Made what alloc_xen_pagetable() would return, in case it is used. */ + pg->count_info &= ~PGC_xen_heap; + page_set_owner(pg, NULL); + spare = mfn; + } + + rc = remove_from_sparse_view(s, nr, &spare); + + if ( first_kept && mfn_eq(spare, INVALID_MFN) ) + *first_kept = true; + + return rc; } /* Memory leaves Xen's hands without passing through the heap. */ @@ -233,7 +257,7 @@ int sparse_dmap_drop_pagetable(mfn_t mfn) INVALID_MFN) ) return 0; - rc = remove_from_sparse_view(s, 1); + rc = remove_from_sparse_view(s, 1, NULL); if ( rc ) printk(XENLOG_WARNING "Leaking page-table page %"PRI_mfn": still in the sparse directmap\n", @@ -267,7 +291,7 @@ int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, e = min(e, SPARSE_DMAP_END); if ( !(nf & _PAGE_PRESENT) ) - return modify_mappings_in(sparse_dmap_root, s, e, nf); + return modify_mappings_in(sparse_dmap_root, s, e, nf, NULL); /* * A permission change applies where the sparse view maps anything: it @@ -283,7 +307,7 @@ int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, n = min(n, (e - va) >> PAGE_SHIFT); if ( !mfn_eq(mfn, INVALID_MFN) && (rc = modify_mappings_in(sparse_dmap_root, va, - va + (n << PAGE_SHIFT), nf)) ) + va + (n << PAGE_SHIFT), nf, NULL)) ) return rc; va += n << PAGE_SHIFT; } diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 69e8e982b6..055e358f3a 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -2561,7 +2561,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags) * The hook may have mapped part of the pages before failing: take * them out again as a free would, and leak them if that fails too. */ - if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + if ( arch_xenheap_pages_free(page_to_mfn(pg), order, NULL) ) printk(XENLOG_WARNING "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", mfn_x(page_to_mfn(pg)), 1U << order); @@ -2580,6 +2580,7 @@ void free_xenheap_pages(void *v, unsigned int order) { struct page_info *pg; unsigned int i; + bool first_kept = false; ASSERT_ALLOC_CONTEXT(); @@ -2593,7 +2594,7 @@ void free_xenheap_pages(void *v, unsigned int order) * they may remain reachable through it: leak them rather than hand them * out. */ - if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + if ( arch_xenheap_pages_free(page_to_mfn(pg), order, &first_kept) ) { printk(XENLOG_WARNING "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", @@ -2601,10 +2602,15 @@ void free_xenheap_pages(void *v, unsigned int order) return; } - for ( i = 0; i < (1u << order); i++ ) + for ( i = first_kept ? 1 : 0; i < (1u << order); i++ ) pg[i].count_info &= ~PGC_xen_heap; - free_heap_pages(pg, order, true); + if ( !first_kept ) + free_heap_pages(pg, order, true); + else + /* The rest of the block, as the blocks of orders 0 to order - 1. */ + for ( i = 0; i < order; i++ ) + free_heap_pages(pg + (1u << i), i, true); } #endif /* CONFIG_SEPARATE_XENHEAP */ diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 2bcc45cf58..debd511caf 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -108,8 +108,12 @@ bool arch_xenheap_needs_scrub(void); * pages go through arch_xenheap_pages_free() before being freed again. */ int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order); -/* Xenheap pages are to be freed. Non-zero: failed, don't reuse them. */ -int arch_xenheap_pages_free(mfn_t mfn, unsigned int order); +/* + * Xenheap pages are to be freed. Non-zero: failed, don't reuse them. With + * @first_kept not NULL, the arch may keep the first page for itself, and + * then sets *@first_kept to true: that page is not the caller's to free. + */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order, bool *first_kept); #else static inline bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) { @@ -123,7 +127,8 @@ static inline int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) { return 0; } -static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order, + bool *first_kept) { return 0; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 19:55:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 19:55:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1454856.1668524 (Exim 4.92) (envelope-from ) id 1xItSN-0000KN-Uy; Mon, 19 Oct 2026 19:55:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1454856.1668524; Mon, 19 Oct 2026 19:55: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 1xItSM-0000Ez-A2; Mon, 19 Oct 2026 19:55:38 +0000 Received: by outflank-mailman (input) for mailman id 1454856; Mon, 19 Oct 2026 19:55:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xItS9-00069w-Ox for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 19:55:25 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xItRz-000000022zc-3Ntj; Mon, 19 Oct 2026 19:55:15 +0000 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xItGs-00000001FjN-1xGS; Mon, 19 Oct 2026 19:43: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=SZ4nI3B+cfhVuPJjziTGQrpW0Hyptt7NpOiIzFtpX7o=; b=W+PqlqQpK+K3Lw7iJrW1j/i/j5 QO+dlveS1cxCuWZyhrteNvtWuE79JLCnXXahUMQtT0RNOZA/zKjWsoQzTcKl7hnz4VU7HyHfqGfAI CrWEh1pFPLrtdmWHWk0NWHdx7r/hOJZKvaaqvJpygjgQ7jjVOkYL6wJv/F27eCH5ZtRI=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v4 29/30] x86/svm: allocate VMCBs from the domain heap behind the vCPU state window Date: Mon, 19 Oct 2026 20:43:00 +0100 Message-ID: <20261019-asi-hvm-v4-29-b68b66652266@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The VMCB holds the full guest register save area, but lives on the xenheap, where it stays reachable from every context. Move it to the domain heap and map it at a fixed slot in the owning vCPU's state window, so that under Address Space Isolation it is only mapped while that vCPU's page tables are loaded. Hardware is unaffected: VMRUN, VMLOAD and VMSAVE address the VMCB physically, and vmcb_pa now derives from the page rather than from virt_to_maddr() on a directmap VA. A vCPU can have two VMCBs: the primary (nv_n1vmcx) and the nested L2 one (nv_n2vmcx). Both move, taking the first two slots in the window stride. The nested code's swapping of svm->vmcb / svm->vmcb_pa between the two works unchanged, now swapping between two window VAs. free_vmcb() takes a VMCB out of the window with unmap_vcpu_state() before freeing the page: without per-vCPU page tables the window is in the domain-wide area, which outlives a vCPU whose creation fails. The window VA is only valid in the owning vCPU's context. svm_vmcb_map() and svm_vmcb_map_one() return it for v == current, and a transient map_domain_page() mapping otherwise, which svm_vmcb_unmap() drops with unmap_vcpu_state_page(), along with this CPU's translations of it. svm_ctxt_switch_to() no longer touches the VMCB, as it runs before write_ptbase(); svm_ctxt_switch_from() keeps dereferencing the window VA, as the outgoing page tables are still loaded at that point. Runtime-tested under QEMU's SVM emulation with a PVH dom0 on two vCPUs, with and without per-vCPU page-tables: VMCB allocation, VMRUN from the window and context switches. Nested SVM, save/restore, the 'v' debug key and a guest using debug registers remain to be exercised. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/nestedsvm.c | 8 +++--- xen/arch/x86/hvm/svm/svm.c | 10 ++++++++ xen/arch/x86/hvm/svm/vmcb.c | 43 ++++++++++++++++++++++---------- xen/arch/x86/hvm/svm/vmcb.h | 15 ++++++++--- 4 files changed, 56 insertions(+), 20 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index dc853e5f1a..1599a9908d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -71,10 +71,9 @@ int cf_check nsvm_vcpu_initialise(struct vcpu *v) goto err; memset(msrpm, 0x0, MSRPM_SIZE); - nv->nv_n2vmcx = alloc_vmcb(); + nv->nv_n2vmcx = alloc_vmcb(v, VCPU_STATE_IDX_N2VMCB, &nv->nv_n2vmcx_pa); if ( nv->nv_n2vmcx == NULL ) goto err; - nv->nv_n2vmcx_pa = virt_to_maddr(nv->nv_n2vmcx); return 0; @@ -95,7 +94,10 @@ void cf_check nsvm_vcpu_destroy(struct vcpu *v) * of l1 vmcb page. */ if ( nv->nv_n1vmcx ) + { v->arch.hvm.svm.vmcb = nv->nv_n1vmcx; + v->arch.hvm.svm.vmcb_pa = nv->nv_n1vmcx_pa; + } if ( svm->ns_cached_msrpm ) { @@ -113,7 +115,7 @@ void cf_check nsvm_vcpu_destroy(struct vcpu *v) if ( nv->nv_n2vmcx ) { - free_vmcb(nv->nv_n2vmcx); + free_vmcb(v, VCPU_STATE_IDX_N2VMCB, nv->nv_n2vmcx_pa); nv->nv_n2vmcx = NULL; nv->nv_n2vmcx_pa = INVALID_PADDR; } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 3de8da7ea3..6cb3ff4258 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -265,6 +265,10 @@ static void cf_check svm_enable_msr_interception(struct domain *d, uint32_t msr) static void svm_save_dr(struct vcpu *v) { + /* + * @v is the outgoing vCPU, whose page tables are still loaded: the + * VMCB's window VA serves, although current has moved on. + */ struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; unsigned int flag_dr_dirty = v->arch.hvm.flag_dr_dirty; @@ -942,6 +946,12 @@ static void cf_check svm_ctxt_switch_to(struct vcpu *v) { int cpu = smp_processor_id(); + /* + * NB we cannot access the VMCB here: this runs before + * write_ptbase(), so the incoming vCPU's state window is not + * reachable yet. + */ + /* * This is required, because VMRUN does consistency check and some of the * DOM0 selectors are pointing to invalid GDT locations, and cause AMD diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index f5321b03fb..4b398742a9 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -6,6 +6,7 @@ * */ +#include #include #include #include @@ -23,30 +24,40 @@ #include "svm.h" #include "vmcb.h" -struct vmcb_struct *alloc_vmcb(void) +struct vmcb_struct *alloc_vmcb(struct vcpu *v, unsigned int idx, paddr_t *pa) { - struct vmcb_struct *vmcb; + struct page_info *pg = alloc_domheap_page(v->domain, MEMF_no_owner); + mfn_t mfn; + + ASSERT(idx < VCPU_STATE_NR_PAGES); - vmcb = alloc_xenheap_page(); - if ( vmcb == NULL ) + if ( pg == NULL ) { printk(XENLOG_WARNING "Warning: failed to allocate vmcb.\n"); return NULL; } - clear_page(vmcb); - return vmcb; + mfn = page_to_mfn(pg); + clear_domain_page(mfn); + populate_perdomain_mapping(v, VCPU_STATE_ADDR(v, idx), &mfn, 1, + __PAGE_HYPERVISOR_RW); + *pa = mfn_to_maddr(mfn); + + return (struct vmcb_struct *)VCPU_STATE_ADDR(v, idx); } -void free_vmcb(struct vmcb_struct *vmcb) +void free_vmcb(struct vcpu *v, unsigned int idx, paddr_t pa) { - free_xenheap_page(vmcb); + ASSERT(idx < VCPU_STATE_NR_PAGES); + + unmap_vcpu_state(v, idx, 1); + free_domheap_page(maddr_to_page(pa)); } struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, struct vmcb_struct *va, paddr_t pa) { - return va; + return v == current ? va : map_domain_page(maddr_to_mfn(pa)); } struct vmcb_struct *svm_vmcb_map(const struct vcpu *v) @@ -56,6 +67,8 @@ struct vmcb_struct *svm_vmcb_map(const struct vcpu *v) void svm_vmcb_unmap(const struct vcpu *v, const struct vmcb_struct *vmcb) { + if ( v != current ) + unmap_vcpu_state_page(vmcb); } /* This function can directly access fields which are covered by clean bits. */ @@ -219,26 +232,29 @@ int svm_create_vmcb(struct vcpu *v) int rc; if ( (nv->nv_n1vmcx == NULL) && - (nv->nv_n1vmcx = alloc_vmcb()) == NULL ) + (nv->nv_n1vmcx = alloc_vmcb(v, VCPU_STATE_IDX_VMCB, + &nv->nv_n1vmcx_pa)) == NULL ) { printk("Failed to create a new VMCB\n"); return -ENOMEM; } svm->vmcb = nv->nv_n1vmcx; + svm->vmcb_pa = nv->nv_n1vmcx_pa; vmcb = svm_vmcb_map(v); rc = construct_vmcb(v, vmcb); svm_vmcb_unmap(v, vmcb); if ( rc != 0 ) { - free_vmcb(nv->nv_n1vmcx); + free_vmcb(v, VCPU_STATE_IDX_VMCB, nv->nv_n1vmcx_pa); nv->nv_n1vmcx = NULL; + nv->nv_n1vmcx_pa = INVALID_PADDR; svm->vmcb = NULL; + svm->vmcb_pa = INVALID_PADDR; return rc; } - svm->vmcb_pa = nv->nv_n1vmcx_pa = virt_to_maddr(svm->vmcb); return 0; } @@ -248,7 +264,7 @@ void svm_destroy_vmcb(struct vcpu *v) struct svm_vcpu *svm = &v->arch.hvm.svm; if ( nv->nv_n1vmcx != NULL ) - free_vmcb(nv->nv_n1vmcx); + free_vmcb(v, VCPU_STATE_IDX_VMCB, nv->nv_n1vmcx_pa); if ( svm->msrpm != NULL ) { @@ -260,6 +276,7 @@ void svm_destroy_vmcb(struct vcpu *v) nv->nv_n1vmcx = NULL; nv->nv_n1vmcx_pa = INVALID_PADDR; svm->vmcb = NULL; + svm->vmcb_pa = INVALID_PADDR; } static void svm_dump_sel(const char *name, const struct segment_register *s) diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 9d61767ec7..d899beb46e 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -556,12 +556,19 @@ struct vmcb_struct { uint64_t res18[291]; }; -struct vmcb_struct *alloc_vmcb(void); -void free_vmcb(struct vmcb_struct *vmcb); +/* + * VMCBs are domain-heap pages: hardware addresses them physically, and + * Xen maps each one at a fixed slot in the owning vCPU's state window, + * so the returned virtual address is valid only in that vCPU's context. + * @idx is the VCPU_STATE_IDX_* slot to place the mapping in. + */ +struct vmcb_struct *alloc_vmcb(struct vcpu *v, unsigned int idx, paddr_t *pa); +void free_vmcb(struct vcpu *v, unsigned int idx, paddr_t pa); /* - * Access a VMCB of a vCPU that may not be current. svm_vmcb_map() takes - * the active VMCB, svm_vmcb_map_one() a specific one. + * Access a VMCB of a vCPU that may not be current: the window VA for + * current, a transient mapping otherwise. svm_vmcb_map() takes the active + * VMCB, svm_vmcb_map_one() a specific one. */ struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, struct vmcb_struct *va, paddr_t pa); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 19 21:09:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 21:09:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455001.1668553 (Exim 4.92) (envelope-from ) id 1xIuba-0007vQ-QU; Mon, 19 Oct 2026 21:09:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455001.1668553; Mon, 19 Oct 2026 21: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 1xIuba-0007vJ-Nm; Mon, 19 Oct 2026 21:09:14 +0000 Received: by outflank-mailman (input) for mailman id 1455001; Mon, 19 Oct 2026 21:09:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIubZ-0007vD-3x for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:09:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIubY-002V1u-Gn for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 23:09:12 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad686d0-e002-0a2a0a5209dd-0a2a4509be88-26 for ; Mon, 19 Oct 2026 23:09:12 +0200 Received: from [52.101.85.60] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad686f6-be1a-0a2a45090019-3465553cb453-3 for ; Mon, 19 Oct 2026 23:09:12 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MWHPR03MB989378.namprd03.prod.outlook.com (2603:10b6:303:2aa::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.21; Mon, 19 Oct 2026 21:09: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.0522.017; Mon, 19 Oct 2026 21: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" 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=zFHPP05NzX8AOZPFD9L9Z6fs5UnOQvgV2lTnemkPQwVYfesn7aiqXTDGT0r6iskxRUjj92rhvLmsAwja5jZYXzQ5pExdYs4RSkGZVboxjdTfqUxrpDRot0E1emsa0HmH1ChQgeFy62iaQy0SJA5nDQp/wXJquRhnwClDNuJg/9joorfsNWTnxCBUGAHkBYKu76qwcB/UCzm91uqH+I5bmAKkjIs49m8EH6vmHWDp64JoglBKqAQGIxdPkoGA2HJcOQmHBKKKYZhpWfIKVuskywt5cq1yOggQaOZaCE8wEj2P8xXT5PjmnebEYXmz4uxYRSwutCF+63TxiomMqSZeDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JO310+hVUDELztGnhAOqelEig1yc0OS6P5EM9io297U=; b=tLRKR/s00S9r8aq3LuVlugonVLrERQ4Ou4FLYvOOiAtR1midSMkcFJHyqv5c3lN8MuIABE6CddSMZUjc5eMmRPm+a41g7bDjNQT9fQykkICvxEoqqfWasVjkrdVsID3a5HkIYQQA2DYEav9U7wr+01XUE4WITQQAlwtWMoOKriV05GyWUzjJAC7Y0ISuS8euWNQI3lYxBQROund0Kyl/G6Lq6Bf+zJMv07L+jmhoB6Bc4jRKQZ2rfUvFX3bnfA8bj5YWcMiGI6Hf7ebFEJr9Vs188Hr/2mZvWa3VZnQupjlQyjskMY+2eqT8ZwdBIal2S7zCOnyKeYwywba4WxG37w== 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=JO310+hVUDELztGnhAOqelEig1yc0OS6P5EM9io297U=; b=uEL+IT39RhVAoY+6majSv7/UO3RF3Sq/wTyiaim/A/bKtzeU5bMNBoENudDicoPdFEv2KjTvl7Y6YQGebrwPX/gb9u/fMYIygXmyCMyqaf+ShGnnL6CE3eoZ0zBNLLLdacmxzY4/Mjxue/3OV/e76IGiwitKWnXyK/KUGGw7N2A= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: multipart/mixed; boundary="------------RjnV2XL3lLfbcPA5AutKuwJU" Message-ID: <6769b61a-89b8-4283-b476-5a1a9aedbd5b@citrix.com> Date: Mon, 19 Oct 2026 22:09:02 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: Teddy Astie , xen-devel@lists.xenproject.org References: <1792420048.8631fc262581453bbf619ec5b2062170.1a1548f6f6b0008425@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: <1792420048.8631fc262581453bbf619ec5b2062170.1a1548f6f6b0008425@vates.tech> X-ClientProxiedBy: PA7P264CA0345.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:39a::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_|MWHPR03MB989378:EE_ X-MS-Office365-Filtering-Correlation-Id: 37e26ce0-3af2-46f4-c3e1-08df2e2535ae X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|6049299003|1800799024|366016|6133799003|10067099003|22082099003|18002099003|4013099003|4053099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: REOK9jlxQ9OpalSePUJReQ0E+fE8r2A5OZYAwNAZVFlN62+EX9wz7eVkTOk5Vuljn1+XDHpDrcAbCbOotAu799WmbVhBiT4ZDkZ9h2HFN78iLvfzbz9jFPW9U/Tvtw9efrJPfjQ+ZXGVPaGrDXKwsKvfPYFt/iGEcZEk9kqC4sFwmHnoj/uvChxPwP88D6/JLDv1oO4v0xOSsxQE2Tgc3oO5WkgXL9VCcGYvvDLvn3NKlL6nK2bDmOCfKdaECgHhl+9+aOwIMNMbTNcPydNiWsU8SiRFWs1/r4+1i1XwGKcPQuSBISy5vIGgT4JRuJmHNVAw6+cYxEyFIF01j7peO5UKpL3zlAsl9xy7DAIednOJ3t0sRljHESoRZlUqKXtW/ODyBzTvGlPx/BXyKDCiolI5lkaKFJi3FiKWgSQxG92QIMW5dinwfa8507fP6La29svQ1C8Z3fK+KXiDHTdVufJIsj/WuR7dCuAj4qhG1hS4240lT5SmBrHNH8uNVcV6tZ8laVo5H+Yf1tijn4bigaJhByhT91hPu/0S09BQYZJlnO5wUgrciH6YmgLYXeEqYXP1yzXW9wt8QhRhkxJLLdZtc8+gPOpQnL0NaiImS/PWQL7UnQ4na7m6slJbA+6epZsKy30tqN0tUfHgNQykbvkGUDjMaXEFmHD53Zg8hF0= 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)(6049299003)(1800799024)(366016)(6133799003)(10067099003)(22082099003)(18002099003)(4013099003)(4053099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SEkwY2dPcjJWbVVWUDNhMzY3ZDA1aHJOamJXZlhjUkNaMGRzeHA3VzVWSjhx?= =?utf-8?B?NVJiZlNNYnJHcEpHdldZb0JXNTRnU0liMWJOb2Y3K2p2eERzdFhNb3BZSTA0?= =?utf-8?B?ak04Q2JpaExkb0QrSE44MWJ5Y1ZKYWFVVzBodzdhdTg0c2U1SE5WdEg0OTJu?= =?utf-8?B?OXBDak91cTVXZmtEV3FMeFhWUEg1ZmhPWjdCNUlSUGxnbjYrWGZmdjlQUHhI?= =?utf-8?B?YU9SajEvbnI2NDEvd1lMMXNpUU1xeHVlRkY3ME1Xdm4rcWxXbE9OOHRzd1gx?= =?utf-8?B?cG9JZXozYXRRV0l3elN6OGhxeWFBTXdIVXEyczMzSjhkeEE1RHRieEQvU2Jq?= =?utf-8?B?em9HU1JQK0tqUVA1b0xQWnZxV1FoaitYTTUxT0VXc2hsN1VaWGJkZ04wVktk?= =?utf-8?B?OXEza0RHdnBaN2FjQ1krV0VyMnM5cjQ5cjJqWWxpazhGZFJ2L1BPZkQ4U09h?= =?utf-8?B?UVVYNTdyTXpRNUFjbGN6L3Z0ei8rTTRnTUgzdFF0ZUV5N1R6cWJURWxMOVRL?= =?utf-8?B?Z1Z3MGg0TzVpT3B5SEd6dDh0WHU4L0RJamJ4STBSMnRRdUltQVlvYmtBb2tv?= =?utf-8?B?dVhMZ3RDZWdmL3oxU1RrOHV6M1E3cXgwZXpKbCt0VExMRVdBWTNQUEkrYWJX?= =?utf-8?B?VjB2WlFSNWpnWWJ0TUxUYll5dXBwZzJOZXRielFjb1JxQUVWdlVmeDB3dWxG?= =?utf-8?B?c0wybjNUcVV1bm5TZDhSSjhNQWlickdXMDhoNDROVXlaNCthNE01Q1RyRGlI?= =?utf-8?B?NE9PWksxdnovUWdWc0t1OGRKd2hhem9namhjM0RiMjYyaWxHN1NrZEJMUVNG?= =?utf-8?B?MnB0MVFLR0dFN2JUekhSdVFtVGRhQWp1dDV0OUtUMjJoZ1FaZUExdjQxMFl6?= =?utf-8?B?VmRSdlVoeUZEa01vR2VuU0dBSmZzV09ScjR4U21yTjdIWWtGZTErZ1pmVjFD?= =?utf-8?B?MXo2bnhSQWtScFFZQVJjMHB2SnFDazVoNW1MSy9jdG5CWWlCVzBmMW1zQ0Vo?= =?utf-8?B?ZU0xL25GemZVeFBhUHZHMmhXb3Z3QjYvR3dKeVpsMTBvcXQ4Ym5EQjRqcTJq?= =?utf-8?B?UFVoSnoxN3I0Ym01UVZoQThuOWpmSzFNWmtNd2dKcjgreCs4eHo3MlFOMzRz?= =?utf-8?B?ckJuTFZPbWlrL3hGZXArc2pOcVZMU2Z4czFHaGdTNktHTGtaNTNGa1hBMHFp?= =?utf-8?B?d0VPSVFXZFRFR2l3TGlsa3J2K2xJYzZSZ3h5YkxscDFaeTBoOGc1UUl5TEk5?= =?utf-8?B?K0lweEVTR1lGZ2FDWFJ0WE80QlRxbmdUeXRCUytnSGlsM3kzcTZralU1SUJt?= =?utf-8?B?VWdseDJaeTg5MlFHNTBwbkxRWlYvS3RQdHN3NTJJcWpxRXFMeFNNNitQZysz?= =?utf-8?B?VVl1RW5xN0hhVjFVTU5DTERvaStLamh1cUpjSExqbGRyWDF1RkxmV0xoa0dp?= =?utf-8?B?enNBZ2xFNkE0ZFcxNXVUTCtPeEpQaGxwRHFDaTFwcWxFb2w4Ry9hUlNqWVNk?= =?utf-8?B?a1FHYk92YjVWcU9MY0gvenJtLzVkbm5ad0pTcDFqZ1ZjTVlTVUkySnk1Tjhm?= =?utf-8?B?bERhMEV5YlNhT3Qzb0krbFNVdXBqamNUZ2pQNmhuY3hZNmdoellCc0pFYTNt?= =?utf-8?B?QWljLzFjU2pZa1pKa2dqYng2bGRDOWZaSmZ0ZWg3Mm05S3VwR0RBeFk3Ymsr?= =?utf-8?B?ZnM4ZWt3eC8zUCs4aGxjUlM5dG96M0VnWG1xZWdtZEJybVdZYVVGcjY0Q1lY?= =?utf-8?B?ZlVWb29mTnkrNmQ3aXRRU0hhQ3lyK3g2ZXN6MDkyaHNmcDhZVmR5bGhoQVZx?= =?utf-8?B?UFRsMWFwMXRLdXVEZnlTeWxBSnE3S2QvMXcwOUFLMlU3aklDN3FmYnkrczZY?= =?utf-8?B?QnVCRDlDL3FmYmJnbUh3U29MUjVFZ2tQb1o2RkRnZWEwd08yK3QzMG52VnVv?= =?utf-8?B?dUlaTjBJTDBROVVtTDVobUs1SjZMbExwK1k4V3V2ZmdJUmVRUHVyc3VUNFJu?= =?utf-8?B?SVJLcTltbU5nSkZ3QXhIWUp0WTQyWVJyYkFYUFRLL2Jlalk3ejRZT2ErU2pl?= =?utf-8?B?cG51dDV0Tmk0NXFWL24rVGgrSWRqTERLL1ErOUdkeXlpbXE5VUJ2VnViTXR3?= =?utf-8?B?MzQrbzFzbSt2elJSazVYUGJKOGY2U2JmUkN4T0lQdTFhdEZtdzFEUFVqb1F2?= =?utf-8?B?NFpkM2tBODVUUmNPUzBNdm5jSWZ1VGR2RHFTd1B2YWRJdkhiZW9KLzBoL2NB?= =?utf-8?B?NWlIcmZzbnpHWms3WGtDWnd2R2xhenRpUXROWCtnVHMzOFdYMDh0aWkxd3FX?= =?utf-8?B?cXlOSTJ3S2hnbDk0WEYwd25nQmRiSmxoN2t0aGpRTjd1d3JpaE9hZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37e26ce0-3af2-46f4-c3e1-08df2e2535ae X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 21:09:06.0189 (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: QvLIviy8ZrcKExAG9Kf/CCPzFAS/auxx5Lf5nkIPv2JORvKm0kh9sk9h2U+wOzaBCYlf1QucE7mL6mvLa/j777kJ1rF49FiMhPOhEhtH1uc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB989378 X-purgate-ID: tlsNG-bad1c0/1792444152-FD26A034-2697B3C6/0/0 X-purgate-type: clean X-purgate-size: 6415 --------------RjnV2XL3lLfbcPA5AutKuwJU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 19/10/2026 3:26 pm, Teddy Astie wrote: > The Intel SDM (Vol 3A-13.12.11, June 2026) says > >> The semantics of sending a self-IPI via the SELF IPI register >> are identical to sending a self targeted edge triggered fixed >> interrupt with the specified vector. > However, this is not expected to alter the ICR register. > > Fix the Xen behavior by sending the Self-IPI directly instead of > emulating it by modifying ICR register. > > Fixes: 21c4d089ba2a ("x86 hvm: x2APIC emulation") > Assisted-by: Claude Fable 5.1 > Signed-off-by: Teddy Astie What matters is the behaviour on real hardware. If we're taking a strict interpretation, then "identical" means that ICR does get mutated. GNR:     (XEN) '1' pressed -> Extreme debugging in progress...     (XEN) *** Testing self-IPI     (XEN)   Before: ICR 00000000000010ff, IRR 00000000     (XEN)    After: ICR 00000000000400fc, IRR 90000000     (XEN) *** SPIV Turin:     (XEN) '1' pressed -> Extreme debugging in progress...     (XEN) *** Testing self-IPI     (XEN)   Before: ICR 00000000000000ff, IRR 80000000     (XEN)    After: ICR 00000000000000ff, IRR 90000000     (XEN) *** SPIV So, AMD doesn't mutate ICR.  Intel does. Weirdly, Intel reads back ICR_BUSY which shouldn't exist in x2APIC, while AMD fails to read back the shorthand. See the attached patch.  The test sends SPIV to CPU0 using ICR, then a self EVENT_CHECK sampling ICR and IRR before and after.  The SPIV printk() only gets serviced later, which is why it's the last of the printk()s ~Andrew --------------RjnV2XL3lLfbcPA5AutKuwJU Content-Type: text/x-patch; charset=UTF-8; name="0001-dbg-self-ipi.patch" Content-Disposition: attachment; filename="0001-dbg-self-ipi.patch" Content-Transfer-Encoding: base64 RnJvbSBkNDZlZWUwM2VhMjMzMjdiMGE0ODBjMDNmYzIyN2U4ZWViNmRhOTZhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu Y29tPgpEYXRlOiBTYXQsIDI4IE1hciAyMDE1IDE4OjA2OjQ3ICswMDAwClN1YmplY3Q6IGRiZyBz ZWxmLWlwaQoKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvYXBpYy5jIGIveGVuL2FyY2gveDg2 L2FwaWMuYwppbmRleCAxNzZmMTQ5OGUzODAuLmNjMGFjMTYwZWEzOCAxMDA2NDQKLS0tIGEveGVu L2FyY2gveDg2L2FwaWMuYworKysgYi94ZW4vYXJjaC94ODYvYXBpYy5jCkBAIC0xMjY1LDIzICsx MjY1LDEwIEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIHNwdXJpb3VzX2ludGVycnVwdCh2b2lkKQog ICAgICAqIFZlY3RvcmVkIGludGVycnVwdHMgYXJlIEFDS2VkOyBzcHVyaW91cyBpbnRlcnJ1cHRz IGFyZSBub3QuCiAgICAgICovCiAgICAgaWYgKGFwaWNfaXNyX3JlYWQoU1BVUklPVVNfQVBJQ19W RUNUT1IpKSB7Ci0gICAgICAgIGJvb2wgaXNfc3B1cmlvdXM7Ci0KICAgICAgICAgYWNrX0FQSUNf aXJxKCk7Ci0gICAgICAgIGlzX3NwdXJpb3VzID0gIW5taV9jaGVja19jb250aW51YXRpb24oKTsK LSAgICAgICAgaWYgKHRoaXNfY3B1KHN0YXRlX2R1bXBfcGVuZGluZykpIHsKLSAgICAgICAgICAg IHRoaXNfY3B1KHN0YXRlX2R1bXBfcGVuZGluZykgPSBmYWxzZTsKLSAgICAgICAgICAgIGR1bXBf ZXhlY3N0YXRlKGdldF9pcnFfcmVncygpKTsKLSAgICAgICAgICAgIGlzX3NwdXJpb3VzID0gZmFs c2U7Ci0gICAgICAgIH0KLQotICAgICAgICBpZiAoICFpc19zcHVyaW91cyApCi0gICAgICAgICAg ICByZXR1cm47CiAgICAgfQogCi0gICAgLyogc2VlIHN3LWRldi1tYW4gdm9sIDMsIGNoYXB0ZXIg Ny40LjEzLjUgKi8KLSAgICBwcmludGsoS0VSTl9JTkZPICJzcHVyaW91cyBBUElDIGludGVycnVw dCBvbiBDUFUjJWQsIHNob3VsZCAiCi0gICAgICAgICAgICJuZXZlciBoYXBwZW4uXG4iLCBzbXBf cHJvY2Vzc29yX2lkKCkpOworICAgIHByaW50aygiKioqIFNQSVZcbiIpOwogfQogCiAvKgpkaWZm IC0tZ2l0IGEveGVuL2FyY2gveDg2L3RyYXBzLmMgYi94ZW4vYXJjaC94ODYvdHJhcHMuYwppbmRl eCBhYzAxYmEwODcyM2QuLmIzNWQzZmYyODg1NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3Ry YXBzLmMKKysrIGIveGVuL2FyY2gveDg2L3RyYXBzLmMKQEAgLTI2ODcsMyArMjY4Nyw3NiBAQCB2 b2lkIGFzbWxpbmthZ2UgZW50cnlfZnJvbV94ZW4oc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3Mp CiAgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwKICAqIEVuZDoKICAqLworCisjaW5jbHVkZSA8eGVu L2tleWhhbmRsZXIuaD4KKworc3RhdGljIHZvaWQgY2ZfY2hlY2sgY2hlY2tfc2VsZl9pcGkodm9p ZCAqXykKK3sKKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOworICAgIHVpbnQ2NF90IGljcl9iZWZv cmUsIGljcl9hZnRlcjsKKyAgICB1aW50MzJfdCBpcnJfYmVmb3JlLCBpcnJfYWZ0ZXI7CisKKyAg ICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CisKKyAgICBhc20gKCJtZmVuY2U7bGZlbmNlIik7CisK KyAgICAvKiBGb3JjZSB1c2Ugb2YgU1BVUklPVVNfQVBJQ19WRUNUT1IsIDB4ZmYgKi8KKyAgICBh cGljX3dybXNyKEFQSUNfSUNSLAorICAgICAgICAgICAgICAgQVBJQ19ETV9GSVhFRCB8IEFQSUNf REVTVF9QSFlTSUNBTCB8IFNQVVJJT1VTX0FQSUNfVkVDVE9SKTsKKworICAgIGFzbSAoIm1mZW5j ZTtsZmVuY2UiKTsKKworICAgIGljcl9iZWZvcmUgPSBhcGljX3JkbXNyKEFQSUNfSUNSKTsKKyAg ICBpcnJfYmVmb3JlID0gYXBpY19yZG1zcihBUElDX0lSUiArICgweGYwLzMyICogMHgxMCkpOwor CisgICAgYXNtICgibWZlbmNlO2xmZW5jZSIpOworCisgICAgLyogU2VuZCBvdXJzZWx2ZXMgRVZF TlRfQ0hFQ0tfVkVDVE9SLCAweGZjICovCisgICAgYXBpY193cm1zcihBUElDX1NFTEZfSVBJLCBF VkVOVF9DSEVDS19WRUNUT1IpOworCisgICAgYXNtICgibWZlbmNlO2xmZW5jZSIpOworCisgICAg aWNyX2FmdGVyID0gYXBpY19yZG1zcihBUElDX0lDUik7CisgICAgaXJyX2FmdGVyID0gYXBpY19y ZG1zcihBUElDX0lSUiArICgweGYwLzMyICogMHgxMCkpOworCisgICAgYXNtICgibWZlbmNlO2xm ZW5jZSIpOworCisgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOworCisgICAgcHJpbnRrKCIg IEJlZm9yZTogSUNSICUwMTYiUFJJeDY0IiwgSVJSICUwOHhcbiIsIGljcl9iZWZvcmUsIGlycl9i ZWZvcmUpOworICAgIHByaW50aygiICAgQWZ0ZXI6IElDUiAlMDE2IlBSSXg2NCIsIElSUiAlMDh4 XG4iLCBpY3JfYWZ0ZXIsICBpcnJfYWZ0ZXIpOworfQorCitzdGF0aWMgdm9pZCBjZl9jaGVjayBk b19leHRyZW1lX2RlYnVnKHVuc2lnbmVkIGNoYXIga2V5LCBib29sIHVudXNlZCkKK3sKKyAgICBw cmludGsoIiclYycgcHJlc3NlZCAtPiBFeHRyZW1lIGRlYnVnZ2luZyBpbiBwcm9ncmVzcy4uLlxu Iiwga2V5KTsKKworICAgIHN3aXRjaCAoIGtleSApCisgICAgeworICAgIGNhc2UgJzEnOgorICAg ICAgICBpZiAoICF4MmFwaWNfZW5hYmxlZCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHByaW50 aygiKioqIE5vIHgyQVBJQywgc2tpcHBpbmdcbiIpOworICAgICAgICAgICAgYnJlYWs7CisgICAg ICAgIH0KKworICAgICAgICBwcmludGsoIioqKiBUZXN0aW5nIHNlbGYtSVBJXG4iKTsKKyAgICAg ICAgb25fc2VsZWN0ZWRfY3B1cyhjcHVtYXNrX29mKDApLCBjaGVja19zZWxmX2lwaSwgTlVMTCwg MSk7CisgICAgICAgIGJyZWFrOworCisgICAgY2FzZSAnMic6CisgICAgICAgIGJyZWFrOworCisg ICAgY2FzZSAnMyc6CisgICAgICAgIGJyZWFrOworICAgIH0KK30KKworc3RhdGljIGludCBfX2lu aXQgY2ZfY2hlY2sgZXh0cmVtZV9kZWJ1Z19rZXloYW5kbGVyX2luaXQodm9pZCkKK3sKKyAgICBy ZWdpc3Rlcl9pcnFfa2V5aGFuZGxlcignMScsICZkb19leHRyZW1lX2RlYnVnLCAiZGJnIDEiLCAw KTsKKyAgICByZWdpc3Rlcl9pcnFfa2V5aGFuZGxlcignMicsICZkb19leHRyZW1lX2RlYnVnLCAi ZGJnIDIiLCAwKTsKKyAgICByZWdpc3Rlcl9pcnFfa2V5aGFuZGxlcignMycsICZkb19leHRyZW1l X2RlYnVnLCAiZGJnIDMiLCAwKTsKKyAgICByZXR1cm4gMDsKK30KK19faW5pdGNhbGwoZXh0cmVt ZV9kZWJ1Z19rZXloYW5kbGVyX2luaXQpOwo= --------------RjnV2XL3lLfbcPA5AutKuwJU-- From xen-devel-bounces@lists.xenproject.org Mon Oct 19 21:48:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 21:48:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455021.1668561 (Exim 4.92) (envelope-from ) id 1xIvD5-00064T-JF; Mon, 19 Oct 2026 21:47:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455021.1668561; Mon, 19 Oct 2026 21: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 1xIvD5-00064M-GV; Mon, 19 Oct 2026 21:47:59 +0000 Received: by outflank-mailman (input) for mailman id 1455021; Mon, 19 Oct 2026 21:47:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIvD4-00064G-AB for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 21:47:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIvD3-00Fe6w-NK for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 23:47:57 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad68f6e-bab6-0a2a0a5309dd-0a2a450ce8b0-38 for ; Mon, 19 Oct 2026 23:47:57 +0200 Received: from [40.107.209.52] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6900b-f479-0a2a450c0019-286bd134b87d-3 for ; Mon, 19 Oct 2026 23:47:56 +0200 Received: from BN0PR04CA0202.namprd04.prod.outlook.com (2603:10b6:408:e9::27) by BL4PR12MB9481.namprd12.prod.outlook.com (2603:10b6:208:591::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.23; Mon, 19 Oct 2026 21:47:41 +0000 Received: from BN3PEPF00022BD5.namprd03.prod.outlook.com (2603:10b6:408:e9:cafe::88) by BN0PR04CA0202.outlook.office365.com (2603:10b6:408:e9::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.19 via Frontend Transport; Mon, 19 Oct 2026 21:47:41 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF00022BD5.mail.protection.outlook.com (10.167.248.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Mon, 19 Oct 2026 21:47:41 +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.53; Mon, 19 Oct 2026 16:47:40 -0500 Received: from [192.168.19.2] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 19 Oct 2026 16:47: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=P3rxjNSxJt4ndtHlFCBO2jlSVnOrKGEhq9zfS8nNnbIHAZoGGKeQyTlFKR7VsQoGk87lH+hoAu7p2zlUXcy6ZCCH8SqDNLBvp5/Q+IF6Ql5mePL9OqhStMO6BSzTyvrj4uYO76Xax/mtSrdDjdF0xBWipVdn785R1WbVWlOyWpLzID0rOQIQ8rzzTAtX8S8lGTYvOSa/r36GNnOgKLIyPS9XPfsVWzeUaK0nBgp50jMuWWCNkQCdUJ/bLxYyJDdB+v6s2E1Zy9j+LwDBq5FBJq+0iG+kpUALi5HpaWJCf19Tavg57uNQtiy+uHMLGp2ML5vPn3MHc129bLvE5lmjDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MX2UBRevsA/zouKWM+YlnctUNNtq/lYu8jwMIdf1MKQ=; b=etNHnl9S3QhMto1GMzpL4YkoRU8Z+WN+9ClOO3V4C0ChiaqM3naFYK8Kno0cQRaBiV7ffjEygkdViFBo0Mj9htnIL72NWMPABy5Rmo3MnP+/46kTyLh4X6ByerFSTkm5MpNYIq/rnoLhIAx/PEAj97WFDATv37sPPq5vmBd/+yIo/vmFNwq8Ox20Bt176Avt5s/J4eDbOcnLy3qaQSF4wScRmSH6kGpFm0Au5Z1x0HYkkzjm/ytlSvtFFIlAkWnbsd6GwXkk9QJ2FE5PvCVbyTMZeZpOeVjWo6hjn2oyJ2PO00enVG+ZKq6BEBMbGKlaxbcRQ+AG1VoXVlnwnGtt2A== 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=MX2UBRevsA/zouKWM+YlnctUNNtq/lYu8jwMIdf1MKQ=; b=AJEwFedZFJa5fOXw1oAfJgU1pQ2zokqUQvbxJ2Vr03TLsnFX0+IirrF1asOY30mDrycS1KMtzdRBv5CBpLfLmLCEFCjr2zZ6falNJJueNrCx63I/3h4lEXKGMWccxt4Q/CzA+i7AwcGVeeWV2DOGjwt0TR6+HS0MqyuERjWWrsA= 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: <25df5d8d-7cd3-4344-86e1-8af883fa9a65@amd.com> Date: Mon, 19 Oct 2026 17:47:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jason Andryuk Subject: Re: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0 To: Mykyta Poturai , "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <103b10d012cc291906025045a2da1ce728f0bffd.1792072426.git.mykyta_poturai@epam.com> Content-Language: en-US In-Reply-To: <103b10d012cc291906025045a2da1ce728f0bffd.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BD5:EE_|BL4PR12MB9481:EE_ X-MS-Office365-Filtering-Correlation-Id: f1684f83-ca22-4d09-6115-08df2e2a99df X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|23010399003|36860700016|82310400026|376014|1800799024|260925022911599003|6133799003|10067099003|22082099003|260925021311599003|18002099003|56012099006|4143699003|260925021911599003|261009223027099003|11063799006; X-Microsoft-Antispam-Message-Info: oHNtx76ILQMKJkS8xcgXTRwuedu6JG34BJaXm/l3lC7ngcyPjwa7QJr6SB0jOxrpAPvMoAd39FxKg6HHoPaVjpBQM4BpsvFvOVFdkZYN6UqIFA3YuVfl5AmFDkGDn72WzFl3InUecxIX+deiN72DddTRDr3/tl/jedBQ2dj2lzLaWdIPsLhjQ7bd5VCM2C9rUdDGCsV5Nv6EXKkOirxTlI6J4AhVfSIJoOhag7HrFhPNI1f/4YTDNdvbJjaOgDn4XDw9Hd0ij8TzCk56ejiWyBVWttEm2KUawZ2rdRLFoBKwmgiLr2wNJ6f/Yj3F1iH7WTkoI4nEw6Thdw1k94HLR505J+cAxuN3lKm1Se8kbwP7NiasQvb7gy2M4Qd64ib1wTlh6WG8v5za8Pd8NFgLshrIEffGC5Z6cZNXuIK78CO/TT7W8RqWud4zy5oomiS1T5NLHJYTVKffHzPF2m1RrBzzAelhaTcO0pRcQVWBaKIWWYuY7jnH52QAJTRcqO+mW1XgfOpXYQXlb6FBlkEA4I+KhyIJsU8cRU8SriXnnyRWanlUulhooYTp+PbGwBzTN7df574WcFyFTZDNybH42focLuHuHPfmwzOmSrSAdTjSaO+NjmeakMr6o5u7a/Jds2YcCTdlwtu7N55rovRYILTZ2o9/ZAUTkIB9byvwDV0HBd3g0pWLfXaoKuboE7+R+uqUzsTFCFc50tDiHBwvCA== 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)(23010399003)(36860700016)(82310400026)(376014)(1800799024)(260925022911599003)(6133799003)(10067099003)(22082099003)(260925021311599003)(18002099003)(56012099006)(4143699003)(260925021911599003)(261009223027099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 2nkeBcBmmKrp1tZgujGUaQou5CyZHNvHdfPp4iVjcUu8+QyT8nLaZqgDFiF062I3V87oa0yfiYNSZLb4po4z/7aJjSnLILLfKFmQSm401o69Bf6bSSF/24x5PH1nRxuduQYqbboQZ7ws5u7g567h/VQ1dXBOAxK2NzIxgsKTPvyULlr50UTTRT1+sceuOFy2EcLUzisIEfvNma9ko6SPQRy3lzckzDTsAk2g3G1dvDVOUTHbqn4X7onrwuEgKQLFgQmjOdDvpxYKyEKU2BppNKUswxCbVpmQUw3VZaytrsdCiVDJa+p5F1QYxPBdq2ai/iGOQ+MtVuc6q89qt4/vCZD9f+t9QhuEAyp8QOupO0NI+MkuqH2c3iTVHvQ7tA03r2TamaGBoXw7zL6pfyjzMGqj+2LMHd86eDgUZuABcLrkPgY8OUGkTcSJCTpeXKNL X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 21:47:41.4525 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f1684f83-ca22-4d09-6115-08df2e2a99df 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: BN3PEPF00022BD5.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9481 X-purgate-ID: tlsNG-d25034/1792446477-034D7A5B-7784499B/0/0 X-purgate-type: clean X-purgate-size: 15213 On 2026-10-15 10:08, Mykyta Poturai wrote: > From: Stewart Hildebrand > > This code is expected to only be used by privileged domains, > unprivileged domains should not get access to the SR-IOV capability. > > Implement a write handler for the SR-IOV control register, so Xen can > discover the VFs a PF enables and map their BARs. VF BARs live in the > PF's capability and are re-sized on every VF Enable, as the System Page > Size register can change them. They decode only while both VF Enable > and VF MSE are set. > > Xen adds the VFs itself: on VF Enable their routing IDs are recorded > and config space accesses to them terminated for 100ms, as the spec > permits; the first access past that adds the VF. Clearing VF Enable > removes them again. > > Signed-off-by: Stewart Hildebrand > Signed-off-by: Roger Pau Monné > Signed-off-by: Mykyta Poturai > +/* > + * Marking is serialised by the hardware domain's pci_lock, which the SR-IOV > + * control register write handler holds; unmarking only clears a bit. Maybe add an ASSERT()? > + */ > +int pci_vf_setup_begin(pci_sbdf_t sbdf) > +{ > + struct pci_seg *pseg = get_pseg(sbdf.seg); > + > + if ( !pseg ) > + return -ENODEV; > + > + if ( !pseg->vf_setup_map ) > + { > + unsigned int nr = PCI_BDF(-1, -1, -1) + 1; > + > + pseg->vf_setup_map = xvzalloc_array(unsigned long, BITS_TO_LONGS(nr)); > + if ( !pseg->vf_setup_map ) > + return -ENOMEM; > + } > + > + set_bit(sbdf.bdf, pseg->vf_setup_map); > + > + return 0; > +} > diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c > index 5695c300f7..7c0277a7e4 100644 > --- a/xen/drivers/pci/physdev.c > +++ b/xen/drivers/pci/physdev.c > @@ -26,15 +26,15 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > if ( copy_from_guest(&add, arg, 1) != 0 ) > break; > > - pdev_info.is_extfn = (add.flags & XEN_PCI_DEV_EXTFN); > + /* > + * Virtual functions are always discovered by the hypervisor, so > + * they don't need to be added here. Does a PV dom0 still need this path? vPCI won't be used in that case. > + */ > if ( add.flags & XEN_PCI_DEV_VIRTFN ) > - { > - pdev_info.is_virtfn = true; > - pdev_info.physfn.bus = add.physfn.bus; > - pdev_info.physfn.devfn = add.physfn.devfn; > - } > - else > - pdev_info.is_virtfn = false; > + return 0; > + > + pdev_info.is_extfn = (add.flags & XEN_PCI_DEV_EXTFN); > + pdev_info.is_virtfn = false; > > #ifdef CONFIG_NUMA > if ( add.flags & XEN_PCI_DEV_PXM ) > diff --git a/xen/drivers/vpci/sriov.c b/xen/drivers/vpci/sriov.c > new file mode 100644 > index 0000000000..4e09bdfbfd > --- /dev/null > +++ b/xen/drivers/vpci/sriov.c > @@ -0,0 +1,507 @@ > +static int vf_init_bars(struct pci_dev *vf_pdev) > +{ > + int vf_idx; > + unsigned int i; > + const struct pci_dev *pf_pdev = vf_pdev->pf_pdev; > + struct vpci_bar *bars = vf_pdev->vpci->header.bars; > + struct vpci_bar *physfn_vf_bars = pf_pdev->vpci->sriov->vf_bars; > + struct vpci_sriov *sriov = pf_pdev->vpci->sriov; > + > + vf_idx = vf_pdev->sbdf.sbdf - (pf_pdev->sbdf.sbdf + sriov->offset); > + if ( vf_idx < 0 ) > + return -EINVAL; > + > + if ( sriov->num_vfs > 1 && !sriov->stride ) > + return -EINVAL; > + > + if ( sriov->stride ) > + { > + if ( vf_idx % sriov->stride ) > + return -EINVAL; > + vf_idx /= sriov->stride; > + } > + > + if ( vf_idx >= sriov->num_vfs ) > + return -EINVAL; > + > + /* > + * Set up BARs for this VF out of PF's VF BARs taking into account > + * the index of the VF. > + */ > + for ( i = 0; i < PCI_SRIOV_NUM_BARS; i++ ) > + { > + struct vpci_bar *pf_bar = &physfn_vf_bars[i]; Maybe just remove physfn_vf_bars since it is only used once? > + struct vpci_bar *bar = &bars[i]; > + > + /* > + * The upper half of a 64-bit BAR holds no address or size of its own; > + * the handlers reach the lower half through its type alone. > + */ > + if ( pf_bar->type == VPCI_BAR_MEM64_HI ) > + { > + bar->type = VPCI_BAR_MEM64_HI; > + continue; > + } > + > + if ( pf_bar->type != VPCI_BAR_MEM32 && > + pf_bar->type != VPCI_BAR_MEM64_LO ) > + continue; > + > + bar->addr = pf_bar->addr + vf_idx * pf_bar->size; AIUI, the PF has the SR-IOV BARs, which are sized like normal. But I thought the pf_bar->size needs to be reduced by some factor to get the per-VF size. I can't find where that is done. Or am I wrong about this? > + bar->guest_addr = is_hardware_domain(vf_pdev->domain) ? bar->addr : 0; > + bar->size = pf_bar->size; > + bar->type = pf_bar->type; > + bar->prefetchable = pf_bar->prefetchable; > + } > + > + return 0; > +} > +static int map_vfs(const struct pci_dev *pf_pdev, uint16_t cmd) > +{ > + struct pci_dev *vf_pdev; > + int rc; > + > + ASSERT(rw_is_write_locked(&pf_pdev->domain->pci_lock)); > + > + list_for_each_entry(vf_pdev, &pf_pdev->vf_list, vf_list) > + { > + /* Don't try to change mapping if it is already in the correct state. */ > + if ( vf_pdev->vpci->header.bars_mapped == !!cmd ) > + continue; > + > + rc = vpci_modify_bars(vf_pdev, cmd, false); > + if ( rc ) > + { > + gprintk(XENLOG_ERR, "failed to %s VF %pp: %d\n", > + (cmd & PCI_COMMAND_MEMORY) ? "map" : "unmap", > + &vf_pdev->sbdf, rc); > + return rc; > + } > + } > + > + return 0; > +} > + > +static void size_vf_bars(const struct pci_dev *pf_pdev, unsigned int sriov_pos, > + uint64_t *vf_rlen) > +{ > + struct vpci_bar *bars = pf_pdev->vpci->sriov->vf_bars; > + unsigned int i; > + int rc = 0; > + > + ASSERT(rw_is_write_locked(&pf_pdev->domain->pci_lock)); > + ASSERT(!pf_pdev->info.is_virtfn); > + ASSERT(pf_pdev->vpci->sriov); AIUI, because sriov was already dereferenced above, this can be dropped by the compiler. At least if (!pf_pdev->vpci->sriov) can be dropped. > + > + /* Set the BARs addresses and size. */ > + for ( i = 0; i < PCI_SRIOV_NUM_BARS; i += rc ) > + { > + unsigned int idx = sriov_pos + PCI_SRIOV_BAR + i * 4; > + uint32_t bar; > + uint64_t addr, size; > + > + bar = pci_conf_read32(pf_pdev->sbdf, idx); > + > + rc = pci_size_mem_bar(pf_pdev->sbdf, idx, &addr, &size, > + PCI_BAR_VF | > + ((i == PCI_SRIOV_NUM_BARS - 1) ? PCI_BAR_LAST > + : 0)); > + > + /* > + * Update vf_rlen on the PF. According to the spec the size of > + * the BARs can change if the system page size register is > + * modified, so always update rlen when enabling VFs. > + */ > + vf_rlen[i] = size; > + > + if ( !size ) > + { > + bars[i].type = VPCI_BAR_EMPTY; > + continue; > + } > + > + bars[i].addr = addr; > + bars[i].guest_addr = addr; > + bars[i].size = size; > + bars[i].prefetchable = bar & PCI_BASE_ADDRESS_MEM_PREFETCH; > + > + switch ( rc ) > + { > + case 1: > + bars[i].type = VPCI_BAR_MEM32; > + break; > + > + case 2: > + bars[i].type = VPCI_BAR_MEM64_LO; > + bars[i + 1].type = VPCI_BAR_MEM64_HI; > + break; > + > + default: > + ASSERT_UNREACHABLE(); > + rc = 1; > + } > + } > +} > +static int cf_check init_sriov(struct pci_dev *pdev) > +{ > + unsigned int pos; > + > + if ( pdev->info.is_virtfn ) > + return -EINVAL; > + > + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_SRIOV); > + > + ASSERT(pos); > + > + if ( xsm_resource_setup_pci(XSM_PRIV, pdev->sbdf.bdf) ) This is a little misleading. During boot, current is Xen - d[IDLE]. With my XSM_HW_PRIV patches, I failed this check since Xen is not the hardware domain. It seems to me the point of this check is to only expose the SR-IOV capability to a suitable domain. If the PF is assigned to a domU - then don't show the SR-IOV capability. SR-IOV and its BARs is more of a hardware domain responsibility, so I think this should just be an is_hardware_domain() check. And I think it should be based on pdev->domain and not current. On the cleanup side, this is already checking is_hardware_domain(pdev->domain). > + { > + printk(XENLOG_ERR > + "%pp: SR-IOV configuration unsupported for unpriv %pd\n", > + &pdev->sbdf, pdev->domain); > + return -EACCES; > + } > + > + pdev->vpci->sriov = xvzalloc(struct vpci_sriov); > + if ( !pdev->vpci->sriov ) > + return -ENOMEM; > + > + pdev->vpci->sriov->pos = pos; > + > + /* > + * We need to modify vf_rlen in control_write but we can't do it cleanly > + * from pdev because write callback only accepts const pdev. Moving vf_rlen > + * inside of struct vpci_sriov is also not possible because it is used > + * before vpci init. So pass it here as additional data to not require > + * dropping const in control_write. > + */ > + return vpci_add_register(pdev->vpci, vpci_hw_read16, control_write, > + pos + PCI_SRIOV_CTRL, 2, &pdev->physfn.vf_rlen); > +} > + > +static int cf_check cleanup_sriov(const struct pci_dev *pdev, bool hide) > +{ > + unsigned int pos; > + int rc; > + > + if ( !pdev->vpci->sriov ) > + return 0; > + > + ASSERT(!pdev->info.is_virtfn); > + > + unmark_vfs(pdev); > + > + if ( !list_empty(&pdev->vf_list) ) > + { > + struct pci_dev *vf_pdev, *temp; > + > + printk(XENLOG_WARNING Thunderbird stripped it from my reply, but there is trailing space above. > + "Attempting to remove SR-IOV PF %pp with VFs still present, VFs will be forcefully removed first\n", > + &pdev->sbdf); > + > + map_vfs(pdev, 0); > + list_for_each_entry_safe_reverse(vf_pdev, temp, &pdev->vf_list, vf_list) > + { > + pci_remove_device(vf_pdev->sbdf.seg, vf_pdev->sbdf.bus, > + vf_pdev->sbdf.devfn); > + } > + } > + > + pos = pdev->vpci->sriov->pos; > + if ( !hide ) > + { > + XVFREE(pdev->vpci->sriov); > + return 0; > + } > + > + rc = vpci_remove_registers(pdev->vpci, pos + PCI_SRIOV_CTRL, 2); > + if ( rc ) > + { > + printk(XENLOG_ERR "%pd %pp: fail to remove SRIOV handlers rc=%d\n", > + pdev->domain, &pdev->sbdf, rc); > + ASSERT_UNREACHABLE(); > + return rc; > + } > + XVFREE(pdev->vpci->sriov); > + > + /* > + * Unprivileged domains have a deny by default register access policy, no > + * need to add any further handlers for them. > + */ > + if ( !is_hardware_domain(pdev->domain) ) This is the counterpart to the earlier XSM check. > + return 0; > + > + rc = vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, > + pos + PCI_SRIOV_CTRL, 2, NULL); > + if ( rc ) > + printk(XENLOG_ERR "%pd %pp: fail to add SRIOV ctrl handler rc=%d\n", > + pdev->domain, &pdev->sbdf, rc); > + > + return rc; > +} > + > +REGISTER_VPCI_EXTCAP(SRIOV, init_sriov, cleanup_sriov); > + > +/* > + * 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/vpci/vpci.c b/xen/drivers/vpci/vpci.c > index 9a422f9ea0..767fe5c6c9 100644 > --- a/xen/drivers/vpci/vpci.c > +++ b/xen/drivers/vpci/vpci.c > @@ -486,6 +487,11 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size) > return data; > } > > + /* Ahead of any lock being taken, as adding a device acquires them. */ > + if ( unlikely(is_hardware_domain(d) && pci_vf_setup_pending(sbdf)) && unlikely() here breaks the tests build. Add #define unlikely to tools/tests/vpci/emul.h > + !vpci_sriov_add_vf(sbdf) ) > + return data & (0xffffffffU >> (32 - 8 * size)); > + > /* > * Find the PCI dev matching the address, which for hwdom also requires > * consulting DomXEN. Passthrough everything that's not trapped. > @@ -607,6 +613,11 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size, > return; > } > > + /* Ahead of any lock being taken, as adding a device acquires them. */ > + if ( unlikely(is_hardware_domain(d) && pci_vf_setup_pending(sbdf)) && > + !vpci_sriov_add_vf(sbdf) ) > + return; > + > /* > * Find the PCI dev matching the address, which for hwdom also requires > * consulting DomXEN. Passthrough everything that's not trapped. > @@ -680,6 +691,9 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size, > /* Tailing gap, write the remaining. */ > vpci_write_hw(sbdf, reg + data_offset, size - data_offset, > data >> (data_offset * 8)); > + > + /* Only once every lock has been released, as removal acquires them. */ > + vpci_sriov_drop_vfs(); Hooking every vpci_write() for this seems a little unfortunate. Could it be hooked into the vpci softirq? > } > > /* Helper function to check an access size and alignment on vpci space. */ > diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h > index 26aa120583..eead9487d0 100644 > --- a/xen/include/xen/vpci.h > +++ b/xen/include/xen/vpci.h > @@ -145,6 +145,22 @@ struct vpci { > unsigned int nbars:3; > } rebar; > > + struct vpci_sriov { > + /* PF only */ > + struct vpci_bar vf_bars[PCI_SRIOV_NUM_BARS]; > + /* > + * When the VFs which are enabled but not added to Xen yet are > + * guaranteed to respond to config space accesses. Zero if there are > + * none. > + */ > + s_time_t vfs_ready; > + /* Routing ID offset of the first VF, and stride between VFs. */ > + uint16_t offset; > + uint16_t stride; > + uint16_t num_vfs; > + unsigned int pos; unsigned int before uint16_t packs the structure a little better. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Mon Oct 19 23:09:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 23:09:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455039.1668571 (Exim 4.92) (envelope-from ) id 1xIwTS-0001yO-7w; Mon, 19 Oct 2026 23:08:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455039.1668571; Mon, 19 Oct 2026 23:08: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 1xIwTS-0001yH-5G; Mon, 19 Oct 2026 23:08:58 +0000 Received: by outflank-mailman (input) for mailman id 1455039; Mon, 19 Oct 2026 23:08:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIwTQ-0001yB-KI for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 23:08:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIwTP-00D9ZL-Oz for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 01:08:55 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6a2c7-e002-0a2a0a5209dd-0a2a450bd022-20 for ; Tue, 20 Oct 2026 01:08:55 +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 6ad6a306-b7e8-0a2a450b0019-aceafc1fb9d6-3 for ; Tue, 20 Oct 2026 01:08:55 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 54D1043E10; Mon, 19 Oct 2026 23:08:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B0251F000C4; Mon, 19 Oct 2026 23:08:52 +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=1792451333; bh=eLKM7MMeaqzoIZ75AVxnOBs7+cOS67Dja9Pr1r6VNKY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NkdYFlrVNZLObvTMqbesr14pbD3trgw5L2H4TNqYNolXpHBvm0VC1bK38omiDO3Fa fbASWjUz4Y+mxBOv7Oe/+5lfZy6Tv9f0jeU/7lUFPuSCc/5zBgIO4IHYm7aHHO0AlE EKk51z1IAOvHRCTyFS/ZKGBLG1uwo/XKGAfG7H2cWCn1l1TYWMcfIRVB5uyohEbjHy XKNzoa4NveXR4CfL86ig0/VYGiJo4QZ5oAdy5NICa9gP2biM7Tkl7+62MOXScL2R0C JuLj10XXX4Z9gJ0TIeOQoZJJ+UonvzJlctKIAe3C2/mR8tnBXQowrGbiE+Q6lS9W6+ kaHvsfl0o+lqg== Date: Mon, 19 Oct 2026 16:08:51 -0700 From: Jakub Kicinski To: Josef Bacik Cc: Paolo Abeni , Eric Dumazet , "David S. Miller" , Andrew Lunn , Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Tony Nguyen , Przemek Kitszel , Manish Chopra , Rahul Verma , GR-Linux-NIC-Dev@marvell.com, Shahed Shaikh , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org Subject: Re: [PATCH net-next v2 00/10] net: stop calling __pskb_pull_tail() from drivers Message-ID: <20261019160851.7eb2a889@kernel.org> In-Reply-To: References: <20261008-b4-pskb-pull-tail-drivers-v2-0-8f2bd9bee138@toxicpanda.com> <20261008141131.0ac356dd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1792451335-A8CCF9EA-A0E3F2E3/0/0 X-purgate-type: clean X-purgate-size: 1256 On Fri, 9 Oct 2026 09:43:31 -0400 Josef Bacik wrote: > On Thu, Oct 8, 2026 at 5:11=E2=80=AFPM Jakub Kicinski w= rote: > > > > On Thu, 08 Oct 2026 21:02:47 +0000 Josef Bacik wrote: =20 > > > v1->v2: > > > - New 1/10: skb_drop_empty_frags(). xen-netfront, netxen and qlcnic > > > relied on __pskb_pull_tail() releasing zero-length frags even when > > > there's nothing to pull, which pskb_may_pull() doesn't do (Sashiko). > > > - xen-netfront, netxen, qlcnic: call skb_drop_empty_frags() after > > > pskb_may_pull(). > > > - skb_drop_empty_frags() checked with a boot-time test under KASAN and > > > kmemleak, on cloned and uncloned skbs. =20 > > > > Please keep in mind that we ask people to limit themselves to 15 > > outstanding patches per tree. You have 18 right now. > > (200 active netdev contributors + an LLM) x 20 patches =3D=3D insanity = :/ =20 >=20 > Eesh sorry Jakub, the skbuff BUG_ON() removal series is the more > important one, this series is the followup so I can finish that work. > By outstanding do you mean per-merge window or once I get > notifications for things being merged I'm good to send the next batch? Sorry for the silence, I've been mostly offline past week and a half :S From xen-devel-bounces@lists.xenproject.org Mon Oct 19 23:29:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 23:29:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455047.1668581 (Exim 4.92) (envelope-from ) id 1xIwnO-0005Nt-R2; Mon, 19 Oct 2026 23:29:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455047.1668581; Mon, 19 Oct 2026 23:29: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 1xIwnO-0005Nm-Lz; Mon, 19 Oct 2026 23:29:34 +0000 Received: by outflank-mailman (input) for mailman id 1455047; Mon, 19 Oct 2026 23:29:33 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIwnM-0005Ng-W6 for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 23:29:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIwnL-004fJp-Ub for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 01:29:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6a726-8faa-0a2a0a5109dd-0a2a450887f2-46 for ; Tue, 20 Oct 2026 01:29:31 +0200 Received: from [40.93.196.46] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6a7da-f659-0a2a45080019-285dc42e09df-3 for ; Tue, 20 Oct 2026 01:29:31 +0200 Received: from IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6) by MN2PR03MB5072.namprd03.prod.outlook.com (2603:10b6:208:1a7::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Mon, 19 Oct 2026 23:29:28 +0000 Received: from IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::b5ee:28c6:e04b:5599]) by IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::b5ee:28c6:e04b:5599%5]) with mapi id 15.21.0522.017; Mon, 19 Oct 2026 23:29: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=JUVKlKS1y+BG1y5g8AVBr6LGTA6xuGrD4l1zSvuwyCDbOPjVTRo7l9ZkiM4UKxqH+sC0XPv2XX6wZKIGduusvLVBHO63bz0+6QoTNw3SC2lXvPfYmEO5WTwTl8ZYInhkF3Ersd/Hge57zvsNRNw5/1l82sJZ6pIPue/RtXLlsZu0RzTvQ+EaxHCpwHmG+R/R3avajLQkji2fiG018Ue4GzbWxZ3GmUh/uoaCmxwuiDOZ89xBm4knYxW4p5WVi9s7rNEWIDJ/a2hYFPRmJUQhVHcI+JOrYdCQe/26eW83wimB8F/eA6AmEeHqSPG+xo2Lw9hI7NVKhW3nE2fEzg47DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7octSSBU0RYQlZaDN888T7ZYftlnCCk/omHq1ESy0UY=; b=ZqyEAxAULBlbRN9iqIqdanYyZEtpImz1bnC+BVGWwS/AKnKFJY0bUxg+0LyU1mc2wqhURMvgr/hFeDzJvRh8wSSedefYHO9uc/RHt38SsOUM62TI0A5Ut30oS2pZztN2yu3PCxtd30axUE7TcQg8rnDqnycu1D+YSVPchr3kUO22Y9acjzYWcu0sPTzT99+DjUS3mR1lHqWuDuc6prQP+w3WT3oj53QIkuqBXq/3RyinMSyEPDQRDYHBjxIgdZH8xQCSVU/XGdLG0rRO0fvKly9sCVFjdNdoPo5aFiwHpzjBYnnvdbGXiUX5NB7yeqMgfv+btiuCxrsAeNnw+fiU4Q== 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=7octSSBU0RYQlZaDN888T7ZYftlnCCk/omHq1ESy0UY=; b=AIIZJ+jDJcbeQXcsDiWBrUZv3bFFROlg1cw2VkHbbfN0PCYnKHOKETttNplef9k3glcTyWM+VSw1DWpHiT9WhlAQEL/KTpWkauUttWx3FMRHiNfw1FjURM30gxrMDgTAtkZaDGoCcc8Yn965V4OMx+p61dLtaIjp5C9ZDynJPIk= 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: Tue, 20 Oct 2026 00:29:24 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: Teddy Astie , xen-devel@lists.xenproject.org References: <1792420048.8631fc262581453bbf619ec5b2062170.1a1548f6f6b0008425@vates.tech> <6769b61a-89b8-4283-b476-5a1a9aedbd5b@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: <6769b61a-89b8-4283-b476-5a1a9aedbd5b@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0356.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:37c::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR03MB8288:EE_|MN2PR03MB5072:EE_ X-MS-Office365-Filtering-Correlation-Id: 75977db4-ed25-4889-fe22-08df2e38d152 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|4143699003|11063799006|10067099003|260925022911599003|260925021311599003|260925021911599003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: NvnfPLXNPHrIEcGiAos7Mmc6GLdWPQFChnVl/hZ3+c+4x5O0tGFSrewurqgg8aaY3hg2LP52cOLYHv07grE0Zn7FSydUmU02s4uYg7VgsuL3uYRJ/YbVPCw8keWagHAzKP2ssWIf/XrNjvdaz+Zk3UR8xH5zCMdDWGMRztB90Gr/38vYDMuTk1ZpJJy046VryCq5RTvaSdwqBObw4m5sb9iFTlPt5bbp/8xOIJd93Etf6Pv1n3t2fsMs1uoUdJW9zvCDAqrJbe2fAB45YlKORZmiShK784TsC4EvtvY85ot1aLIlg77/5K15PoMjuer1GeNVX9zoSTdzidmeRHZ6ig1t2ZqO6Cv9WNEcykH46DuTXEBETAdltgnlTXiob9mlphShBFZgY5beSz7TzFNqMvSoI5WFgDIM7ogu1pk7YdPblbFpX7Lmv18OLoBZ0Rd0gqjbX/NmawKoYY9bl6BkS2OOm3e2Z+yQ+f9fpgudj1DktKJ9Mo4cTS4659QcX2l/EwkJjQsELmTiqH+49UiSyzyQzTX107BBdY6IXXH/UP58EVfupLmdyCZLMM5seMA8+RayyBEETCHa/YlDkf+EJaUQFCDimAtBSuSCxSAceAA+ogEVxwQjgAxJifaZT3IUQRe3ikuxgZXhPnUxHo3BA5JZzHPPW6pZyGpr2bVPlWc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR03MB8288.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(6133799003)(22082099003)(18002099003)(4143699003)(11063799006)(10067099003)(260925022911599003)(260925021311599003)(260925021911599003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?REN3NUFsMkVtZjBKbEJtdjlPMEI0clpPY0lnVFRUTDBIaDI5Z0hzcVFmRVhi?= =?utf-8?B?c1NTMkFSUFZOZXRvYVpGdEVNNG9GK2tONnM3eVl4ZkRFSmxsZ1FFY3U2UjhX?= =?utf-8?B?aUNNZUJNcnFBTkZMTmZlYkt1QTlQMzlScGtMdVkvZ29tRjZaWEZvTnF4cnR1?= =?utf-8?B?bWJ1cUNQWDZ0a0NxUC9VdVFsRnNINEwwZVVqRUVubHVHOEdnRE9XMko4TnhB?= =?utf-8?B?blVjOXpZZXlQY3JXV0kzdHVyZ1RFWWxYekNhclVRT3RCNGZPUG01VmtydW1I?= =?utf-8?B?YXJrcWlnd3poU3A2R2pDQ0IzWWVJMGszUUhDcVMwZ1VEN2t5cnFZTWMrWG5i?= =?utf-8?B?U3g1NVlrZWFhcEIvYjFsSHlkUkhXS1c2L0R1ZlRUVW9HemJsLzdRc2JkT0Yz?= =?utf-8?B?MlhjQ3NqQVZhR1pYbnhiNnhOMHprR25jMWxMZzdhRGR2dDNNM3FEODB5aS9Z?= =?utf-8?B?NDlkMDIyV0t6L3NNWU5oK1c2Uzc0VkNDV1pGNjd6UmJsTlBrT2R5VDdzRWs1?= =?utf-8?B?eG9jTzFJT3RXd1dXZDNJcE80d3luVCtPK2c0S3lIZ1BoOFJyNlQ5TDJXb2lq?= =?utf-8?B?cmE3OFEwdDFBVUtkbUVCZEVJaEZjWDZQbVNHRFd0Qjh3N3FzeDRsaHIzZHJ4?= =?utf-8?B?UTNvMUVnNDA2V0k2eTRVejV4NGdaaVpyWjlnSzJMdGozWEx0U3JSZFFHK3Ur?= =?utf-8?B?b1crN3BBYlFMOTZ3WkxnL2c0YTNoQ0pNaXVmNm4rckprS3Z2OGYxMFlVUmpO?= =?utf-8?B?T3NkUkRPRmdrZW5hamt6WkFGTjA2azQvK2huQWdZZG40SDN1aHBlOFFWWkZu?= =?utf-8?B?ZGhwTW1kbzlVMlNSZWs1VjhINnlEMVN3VGtLSUpLUEd0Yk83ZlQwek1CRURj?= =?utf-8?B?MkpHUDE2d1ZJRDc4Q3JEbElCU0NyYWNoWkdsZG5QVVZaVTR4WHgydVJWSmsz?= =?utf-8?B?V1FBaU5xRURxR0lGanFNaE9DMFZ0S3hMQ3BYY0s1Z2lRUTBQb0dtL3ZqTEdY?= =?utf-8?B?VmJrRGhPSE1Lc1VyME1hMGFFbG40UEQ0bGFiU1M1NEVUYW5wMXBhanZDbEc0?= =?utf-8?B?cGJlOGcxQ1lFN1RvVkl4Mk9kbWMzVE9qQ00veEVtMSt3blBybW42cFM3My85?= =?utf-8?B?SHBSM3E3T24xend5L0hPR2REa0U2ZWFvRkk5V0tPRkFFaUxyNjdwTWhIVm55?= =?utf-8?B?RUVML0RZclRrRXBGYk5YUDl0RGtLbmhKQVd3ZVlIWnhLbTdrcVVuREx6UWFL?= =?utf-8?B?UWNid1RtV0taU1FNaWEvSktob0pZM2ZFWmk4a3QvaGtlcTI5K2lTSDNYQmJw?= =?utf-8?B?dUh0TjF5UHBLek1hY2xKVGtocEtvL2VRalRVYkFsMzFEUElpcHBiT2ZSYjdI?= =?utf-8?B?dEJwcUluNFdWeGR3cVFpdUthbUNaY2dndkNhVVJ0QUs4dXBrZGlaR2hGQmVw?= =?utf-8?B?VEoyS3FsOWsrVUVaeXIxeWpuZUFZcWp4M3VzWTJaTXlicTdpa0VDdW5EZmFh?= =?utf-8?B?WGo3VEVad2Jocy85bm9Ta2FHNnZJUjFScWxCVDFQQVpBWGoybDVqa1E0RmxR?= =?utf-8?B?QnFJWFRqSURneE1GNDRzOHdHTFRkQ2hDWVQxNEtpQ29vY2xHSWV5UjIvbHUz?= =?utf-8?B?NzlNaDA0UVRtRnVzQytNeTNJeHl5QXZFZ1RSaHFqWGVlODFtTEoxQndRcGVI?= =?utf-8?B?eUVHWlB2eDhMaE9QSUNZWk05YjN6THgwWFJCVHRKOHNxYzVHWHJNaFBMRUFN?= =?utf-8?B?dG1WSmdCTVlqNldmYXFieThwWXQ4TURUVTRlaFl0NmNPdFNUL0VnWDMxbE9n?= =?utf-8?B?bWVJNUd6Ulg0dmNOMkhsTUFjdml3S0VkZkMvU0RLb2UwVVVENTZVZlVLekRG?= =?utf-8?B?b0JNSG1pQVBncFc4aEVDOTdMMWFvdFc1emxrMGwzTUlON2NUaUVvMTlLOG13?= =?utf-8?B?VnpERVk0SXltbW9BanZwZ1g5STlzT3hkQXlwUWx2WFFmdHh6QXlsMFR6MUJ3?= =?utf-8?B?US9RdDBnbElOTXVHZ2p1QnpoOVJ5RTdYMGU0Nzlab0Npa2VETDBmVFVIWmZR?= =?utf-8?B?cExUK0pCSW80alNDdmwxMXVsYzljaTEvNGVZUXUzRlcxTytxYW1PZTFyOUZK?= =?utf-8?B?SzFtRGtLWGpzQ2lHZHQrOHBCTGdrWUlIanpJUk5IelFxektWenNLWDh4cEMv?= =?utf-8?B?Mk9HMUU4TDc0bUl3MnJSMzNwU0s4WklvajFPdzhRbHBvM2hKdElNd0RXcGM2?= =?utf-8?B?cm0vaFFBSjNFcXl3VVorL0dndThnSGs0Z1dKbExQT3hlbGhpR2xrMC9jZG5a?= =?utf-8?B?LytHcStDRlh5SEF4eU9lWjZXWlFrY1RCbXJ6WXgvQ3dENURNMlZTQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75977db4-ed25-4889-fe22-08df2e38d152 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2026 23:29:27.9436 (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: 1XUaIAoWWN9sBjFo7EUstjVyTx8MXg+uF4hXvv2OyUXbF7WIMHOgsGVyLBS005pOm+uH/Rp0wgykjjhh4vv8fcZ3NPWD+/gjYWmeZfrWZoM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5072 X-purgate-ID: tlsNG-c1860d/1792452571-D6F5F87B-14350F2C/0/0 X-purgate-type: clean X-purgate-size: 2020 On 19/10/2026 10:09 pm, Andrew Cooper wrote: > On 19/10/2026 3:26 pm, Teddy Astie wrote: >> The Intel SDM (Vol 3A-13.12.11, June 2026) says >> >>> The semantics of sending a self-IPI via the SELF IPI register >>> are identical to sending a self targeted edge triggered fixed >>> interrupt with the specified vector. >> However, this is not expected to alter the ICR register. >> >> Fix the Xen behavior by sending the Self-IPI directly instead of >> emulating it by modifying ICR register. >> >> Fixes: 21c4d089ba2a ("x86 hvm: x2APIC emulation") >> Assisted-by: Claude Fable 5.1 >> Signed-off-by: Teddy Astie > What matters is the behaviour on real hardware. > > If we're taking a strict interpretation, then "identical" means that ICR > does get mutated. > > GNR: > >     (XEN) '1' pressed -> Extreme debugging in progress... >     (XEN) *** Testing self-IPI >     (XEN)   Before: ICR 00000000000010ff, IRR 00000000 >     (XEN)    After: ICR 00000000000400fc, IRR 90000000 >     (XEN) *** SPIV > > Turin: > >     (XEN) '1' pressed -> Extreme debugging in progress... >     (XEN) *** Testing self-IPI >     (XEN)   Before: ICR 00000000000000ff, IRR 80000000 >     (XEN)    After: ICR 00000000000000ff, IRR 90000000 >     (XEN) *** SPIV > > > So, AMD doesn't mutate ICR.  Intel does. > > Weirdly, Intel reads back ICR_BUSY which shouldn't exist in x2APIC, > while AMD fails to read back the shorthand. > > See the attached patch.  The test sends SPIV to CPU0 using ICR, then a > self EVENT_CHECK sampling ICR and IRR before and after.  The SPIV > printk() only gets serviced later, which is why it's the last of the > printk()s https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2965354494 It looks like it's a behavioural difference between Core and Atom.  Core modify ICR, while Atom do not. Also Atom look to be delivering the "SPIV" IPI too early.  That will be a separate bug. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 19 23:40:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Oct 2026 23:40:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455054.1668589 (Exim 4.92) (envelope-from ) id 1xIwyH-0008WI-NX; Mon, 19 Oct 2026 23:40:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455054.1668589; Mon, 19 Oct 2026 23:40: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 1xIwyH-0008WB-Kb; Mon, 19 Oct 2026 23:40:49 +0000 Received: by outflank-mailman (input) for mailman id 1455054; Mon, 19 Oct 2026 23:40:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIwyF-0008W5-Sn for xen-devel@lists.xenproject.org; Mon, 19 Oct 2026 23:40:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIwyE-00DCFZ-Rk for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 01:40:46 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6aa15-8faa-0a2a0a5109dd-0a2a450b825e-44 for ; Tue, 20 Oct 2026 01:40:46 +0200 Received: from [209.85.208.48] (helo=mail-ed1-f48.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6aa7e-b7e8-0a2a450b0019-d155d030a5e0-3 for ; Tue, 20 Oct 2026 01:40:46 +0200 Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-6acb9c018ffso287827a12.1 for ; Mon, 19 Oct 2026 16:40: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-Type:To:Subject:Message-ID:Date:From:Reply-To:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1792453246; cv=none; d=google.com; s=arc-20260327; b=GokrR/ztEq9hB1t2c7KdutiyJxhoTK2UpmFhKgCYjYQfeobE7H4LhtU6tiywd6ung0 1CbMOfPtsFT6rEabNy/MqGY2p1jDmcFziLjEEGwAXo5E6nIXFVoCNgy0Se51xmw4ZWT4 JALVNf3kG7bN/1lRUSoRYvFNfHlkG/Foo54miZ63JmX71Mva35rcEJu9YoW1KXWNnCV/ R3QepyTr19bjCPD95rvV5QpI92u47fuwzebPSXeaL3vmiiKgKa02JEkv7D6bU5w66F8A /9fxN/9M+cLMVuefhJOx8hIUmhZnF21DpqtU214mXdjO4TbYI0KgIruGx5hev8pgzJL6 0s4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:reply-to:mime-version :dkim-signature; bh=k9sLU2zZysN+hcDUBgFgsh+bW6LB/1ZVChhIXh4bH38=; fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=; b=nfSPBtlE0MJRj+vwzV1SxhQlLQfb8VJK7LyX0k0kc5AXVGe2UQse7VesMDunVS4nKb DwBwcL9GlpaZwNUJYank+pco8908cWhtxJp6H5We9J7MPVGSs1IR5no8ZvXCoZCf2BOF Psq+hCNez1P6LjkAXwOxTpA/scDX9vF/CMd/SEmEk1W53nqMISaAmMGTaBNVQlXJePnN udV2fv/D+6BsapwWMNdxbqzez7QSxOArrI/EcyBPVubgkHWCm6TkW/yQTBajzMOx01FN WmvnBFP+xMmUhuz1QzINpWsDzW+lHpQnYoIy4D7x6QKWuuBlXJZqGtsLslX2xKFKSsoR mEzQ==; 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=1792453246; x=1793058046; darn=lists.xenproject.org; h=content-type:to:subject:message-id:date:from:reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to:content-type; bh=k9sLU2zZysN+hcDUBgFgsh+bW6LB/1ZVChhIXh4bH38=; b=GAL62UBFPkkWyKqUAD4KXK57yfr7avutxX0phAKkiThhTswdX5wzyNxGgR4WLYfJrc n++1k76BSYkBx492m9Edz5lu71Zba7X7b3Rtu8Fi61h+m43m4JyRYw/KU4do/o9WP9Cb jyB+M+3UC2wb6hIPvkE1XNdPRzp1FBAF/L9WbVt8AROqfJ+4L/nh282wdsuHVhl5CDfF LYdCikxQ5g1yHAwUjzU1HDNnqeHfeXIT3McSol6lbdryU5NAkcB8M0Q401rDFJxSRiPF 5OW9waDfwZYZ4VwNmRgh9LY2x4WfsgkxKjIIh7AshBZRN5L/Z/uj5nIHfqOPr7zrJ9SX J7Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792453246; x=1793058046; h=content-type:to:subject:message-id:date:from:reply-to:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=k9sLU2zZysN+hcDUBgFgsh+bW6LB/1ZVChhIXh4bH38=; b=LZtyWrgAAjdUPfsgV7RPUtA7pOgrLZ5/YDxfUNB7Q9PSS86vUm4LpaopvF4ncWsU0l 818d1xISN22qMjdx0u/2GUZeQwiTkgKenaFRhL4fvcOAKf1NjDkEa2ELlgXBb6EUw7eo 1IupUzRYyFNLfyraxVtzd1++PggAT5IXSAtB22zevUqvoKyfYhHtqnHmn0gBfSQ5P43f 2gZTincF/WtAWgFwE5Kqsft75zSF4kRsCMone5Nv9enCXJrXN33edFvTl0L9ycMysFU4 d7YaqM9bDbNVLB1OTnx3L7i7bHfHJKpAFVCtnL8w8zCg/M+jwW1pBHxHxZzdo0OGB4dN hsEA== X-Gm-Message-State: AFq9FYLElEAeWzPiGcB8cjQnqNQN1s+4PaFTvp3fsrHYW01i6lQpGNi4 plKYEloMbxucQF5m6vqGoO0SKAKxpxFWxSPd/riR5Y95cMqphQvEWtzyXOyONq8sSpGnnVk5kul FvkgB1UPxWXzqtoPeVLwBDy0K/lVOF2PUBOlg7k58Qw== X-Gm-Gg: AYBFou0thbAV5cmdDiCoc2Cd6mjEk6YcDwfoGcqQNwsBur+6Fup/joZ6qqsHcKhJpp4 9ZEFBaHEuhEYC43bbt+qo2GLwPuizqUnWhx3RnuMwCxBkUdmSOEsZiVNYRkSMfbfh72CuyqaGW/ eDHaLtZejIrrZuVhr+fWwLUO5sPVasdl3LLRYvZpB02WAJw56FEsGx6ydI3/rTj7CcFY+Lpxs4j xJcG6uPq2TqOiya8o65wcCQA+7igkRBqEEBPaliQyTj1pv/D6aMxgDR1VpplvpRTsp1bx/ZaM7t khWaBbey2UQj2e9PA5vIts+MS7awOlZoJLbE6FHplQLusy0mg++4xws3HWMJEVIaOXLAZ6A22+2 8A5PbVFNe8MVy6kpKiSQXOSqWQ7pBOCKs+dnr/N5S9EmWdhlp7eqCaUMSZ0iUkCI+ESbcxRhd X-Received: by 2002:a05:6402:158a:b0:6b1:c355:c7c2 with SMTP id 4fb4d7f45d1cf-6b3e679f617mr334087a12.13.1792453246257; Mon, 19 Oct 2026 16:40:46 -0700 (PDT) MIME-Version: 1.0 Reply-To: ludloff@gmail.com From: Christian Ludloff Date: Tue, 20 Oct 2026 01:40:34 +0200 X-Gm-Features: AclHuK8MuOKz1Gd45M0vqBXptHGA3tqsrHMTJuH7Ligjuy4RhL29rknB82vgWJY Message-ID: Subject: Re: [PATCH] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-42698a/1792453246-192CC9EA-7204D707/0/0 X-purgate-type: clean X-purgate-size: 461 > It looks like it's a behavioural difference between Core and Atom. > Core modify ICR, while Atom do not. For Core there might be more nuance yet. I seem to have an ICL result for "does not". And I seem to have two SKL machs (same stepping, same ucode) that... disagree with each other. Some sort of config thing...? Maybe Intel can explain. I consider "does not" the cleaner behavior, unless a compelling explanation is offered. -- C. From xen-devel-bounces@lists.xenproject.org Tue Oct 20 00:20:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 00:20:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455059.1668598 (Exim 4.92) (envelope-from ) id 1xIxa1-0006ai-8J; Tue, 20 Oct 2026 00:19:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455059.1668598; Tue, 20 Oct 2026 00:19: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 1xIxa1-0006aa-3B; Tue, 20 Oct 2026 00:19:49 +0000 Received: by outflank-mailman (input) for mailman id 1455059; Tue, 20 Oct 2026 00:19:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIxZz-0006aU-2N for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 00:19:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIxZx-004kgc-1F for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 02:19:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6b305-bab6-0a2a0a5309dd-0a2a4505dd4a-44 for ; Tue, 20 Oct 2026 02:19:44 +0200 Received: from [52.101.56.47] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6b39e-4cb1-0a2a45050019-3465382f9191-4 for ; Tue, 20 Oct 2026 02:19:43 +0200 Received: from PH7P220CA0005.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:326::22) by SJ5PPF0AEDE5C3D.namprd12.prod.outlook.com (2603:10b6:a0f:fc02::989) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 00:19:39 +0000 Received: from PH2PEPF00048912.namprd05.prod.outlook.com (2603:10b6:510:326:cafe::10) by PH7P220CA0005.outlook.office365.com (2603:10b6:510:326::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 20 Oct 2026 00:19:39 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by PH2PEPF00048912.mail.protection.outlook.com (10.167.243.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Tue, 20 Oct 2026 00:19:39 +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.53; Mon, 19 Oct 2026 19:19:39 -0500 Received: from [192.168.19.2] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 19 Oct 2026 19:19: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=bhyJcQd7+enHhmQexFsICoPyMGhkP9eGAA0MjVBoHaifNsy8sjD2qowTG/t5w/+2n1W6mDaJ9UEH6aaLnH5my1lKPwT9VRneLlU0vzIGNasD27kq+B8VTXY5R6VjNmguXqkBW0AxnR5zE4wsOqVgR0BqTjsHnTDXg3mRX8jBruSoSTCiiUknn9fZJTq3Mi0+1t4Hm/UeSV8p1f8YvKYiIWYGvJH/pfy9Akt/AqsO3SHE5zNf9TSdQLfb0+7PnibGa0upIR6Ah4KdYHBs0DiDbYrve5zf+6jm4WPyxr3BGVuRlRVznXGIHu0+3bz/5fPS+I6JFjaa0crSAnA1AjYI1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S7LrlnJ/bLEiNsjpojKGtMT9OmPmnZ1EUDUytplQVGg=; b=cNV07n5pKBk6rI+qozrvPbru6Sz3BTJu3c4FR25YlhxnUqy7TxeF95fs4Natytdviy5jweujW9AvDOAE89fA3D0f4DEUbQtHqYroreSbqwu7TfJFED5xgHkMFUkcmQUSNEtPSQkQOP51G+cbPGj3b6hMPlcxjOCdFmcumhBaBKlUOWUaXsxJNWQqSsw37kU//rVjVmxB/XCVhyijC2DGBS8TGpCeaCnYQD33hs0fgK1a4LE/TaVwnm7jCyxHOT+TsnwlRgIhwed7IXQZsuI6LjHsDtrlfqWr6ejAIiCIDm4MQhMWJKguVsoEMnCCMHpwqnJQ6GWhM2dqAeaz7wCA8Q== 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=S7LrlnJ/bLEiNsjpojKGtMT9OmPmnZ1EUDUytplQVGg=; b=VnPQbHIh6MK2m5hD1nwYOWiqKG+49DQw3DML+g9tPxVQqTe8uFwVSpi7hI8QY1FcmSsGnLs08Ns+i33MXHCJL+NmTL3ibpkn8aXFUk0AxgDvN9jLyYTzox+sja4Jy9I2jdIp22GppdWDy6p2wImNm2+FTRS2HutEN1PDlczEDpQ= 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, 19 Oct 2026 20:19:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 5/5] vpci: add SR-IOV support for DomUs To: Mykyta Poturai , "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <8823cd01334978baea19515c35068c789d4568bb.1792072426.git.mykyta_poturai@epam.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <8823cd01334978baea19515c35068c789d4568bb.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH2PEPF00048912:EE_|SJ5PPF0AEDE5C3D:EE_ X-MS-Office365-Filtering-Correlation-Id: 36babd3f-4968-4f09-5f24-08df2e3fd482 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|23010399003|82310400026|1800799024|10067099003|56012099006|6133799003|22082099003|18002099003|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: YvEvS7F8u9q0sU4J3C9Bu66nv9udsO4eD2MFd8KJgo5diXqal1hkobsaKwxwG0VPRdFMPasPLZ/mOPyDsi70oZ3Jo0gOdlvCXqupt0NrpsNg6Kl6LN3AiBkow44UqGppEA2tnWLDWjjqFn7N6uKwDiZZ7/A5nnApeNPzb4yE/LmdUEwzBMUJEr9xtlGImZtiLzsAQdjqSdPHiF2FEHz6fYJJQQHs78cTUYQN+r5KUpBV7+pyYwQbbeh1w1glZh/FQ80iegiAj85ywsW6HirTqG8+bl4npVweizmFxSZbydDtJthL1ZY2fyQr8Ue5TOR4ic5l58STc9tcGyM/23VVeVhc9S36W2N4u87stBx8w8OBHY/6BseSn5g1YD8GJGuSn3xtTvTFE4dW+0iUGt5GveuXT5UBiKoytIMMuNcHH8Ja9jdFSQ5aVFUcJTKhUeMKQABGQVGK8Jvb6xQjIH8u9upCBYPkXcU7wrseaEnHb970AdWkD0yKcLwpNS9R7kwjDU7UW3j1kYvvqT5fWzZ17Hgs9Ewb5YpjeaqGWKTDPuOu69GNtzdofCte//BkeCIuFG+BCWtlePi26Mt+yeidOEtpQTVwjqoZa9LApKLFAWiWiKDWPM7zCCHoVJX2oYzPIrv8sNbCYpCFLlm6Fnt2war8QYz5EjbDsosUjxEP7T/jmCCYaxkIbu/iT6FaUVtY2bHmnIHMHQDwyCqNvx9qzw== 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)(23010399003)(82310400026)(1800799024)(10067099003)(56012099006)(6133799003)(22082099003)(18002099003)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: O5tJ6EVMLDDL2W9QBJ35bB2RRYIgWvziaRSXYQBsbFeioRO5t3utVvv9QOz3kE7cDG92qsxBsTd5UrMM99kbsa++2MocpOxR+OXpb8IpXuEZfVxjoM6VaqcFOLSOyZCs1gWCFqMTwH+IsgyPONeVEo2TIBt45H+QT90ONOFmFdhMGpk2kmb8SyGOjUbL3XY4dUGdf8hjELBIugpqjSyFTfGdfNq8a5XoLzdyEeWnmpE8h2490WOKPkgr7cqHxn4Ji/aIRnIGZNLgmg1LaHoVi67CnBpuNMCPQ9XhzEM8jbXESEjLG3zWD8HOdmH79LXWPbKPELH3DzS4dX3t3uYox8w04E6JqqIBDjT7Z+JzCvuzryUw3h05X6tGoEA44bjrQYlUCeOP1yKKV+oR1psIUloOfcIsk/FS6h39eNoiwhsoK5jrvXGnrFtghI8wLTGZ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 00:19:39.1909 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 36babd3f-4968-4f09-5f24-08df2e3fd482 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: PH2PEPF00048912.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF0AEDE5C3D X-purgate-ID: tlsNG-c201ff/1792455584-71AAF2A1-EFA064A6/0/0 X-purgate-type: clean X-purgate-size: 955 On 2026-10-15 10:08, Mykyta Poturai wrote: > From: Stewart Hildebrand > > Emulate guest BAR register values based on PF BAR values for VFs. > This allows creating a guest view of the normal BAR registers and emulates > the size and properties as it is done during PCI device enumeration by > the guest. > > Expose VID/DID and class/revision to the guest. > > Note, that VFs ROM BAR is read-only and is all zeros, but VF may provide > access to the PFs ROM via emulation and is not implemented. > > Note this only removes one of the gaps on the way to vPCI DomU support; > VFs are not usable in DomUs until the rest of it is upstream. The DomU > testing behind this patch used out-of-tree vPCI DomU patches. > > Signed-off-by: Stewart Hildebrand > Signed-off-by: Mykyta Poturai Reviewed-by: Jason Andryuk Thanks, Jason From xen-devel-bounces@lists.xenproject.org Tue Oct 20 00:29:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 00:29:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455065.1668607 (Exim 4.92) (envelope-from ) id 1xIxjR-0000FC-6M; Tue, 20 Oct 2026 00:29:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455065.1668607; Tue, 20 Oct 2026 00: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 1xIxjR-0000F5-3K; Tue, 20 Oct 2026 00:29:33 +0000 Received: by outflank-mailman (input) for mailman id 1455065; Tue, 20 Oct 2026 00:29:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIxjQ-0000Ez-8z for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 00:29:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIxjP-00FsYp-MB for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 02:29:31 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6b551-8faa-0a2a0a5109dd-0a2a4509a27e-38 for ; Tue, 20 Oct 2026 02:29:31 +0200 Received: from [40.107.208.32] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6b5e9-be1a-0a2a45090019-286bd0203fb9-4 for ; Tue, 20 Oct 2026 02:29:31 +0200 Received: from BN0PR04CA0097.namprd04.prod.outlook.com (2603:10b6:408:ec::12) by DS0PR12MB7653.namprd12.prod.outlook.com (2603:10b6:8:13e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 00:29:24 +0000 Received: from BN3PEPF00022BC4.namprd05.prod.outlook.com (2603:10b6:408:ec:cafe::6c) by BN0PR04CA0097.outlook.office365.com (2603:10b6:408:ec::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.19 via Frontend Transport; Tue, 20 Oct 2026 00:29:23 +0000 Received: from satlexmb07.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.522.6 via Frontend Transport; Tue, 20 Oct 2026 00:29:23 +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.53; Mon, 19 Oct 2026 19:29:24 -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.53; Mon, 19 Oct 2026 19:29:23 -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.53 via Frontend Transport; Mon, 19 Oct 2026 19:29: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=m3VYQTgi3cIgOI11bg6r3XA0ar4PW7U2kVxYOAxo7e9RMhF6s+98q9JnBOtjuNvcXmWJSjA3I3VNTOMqN7ze4A7AaARxwDXg6vC/IvcJ4uF97FHRSK3IT7ffQkZiXIzwoPRY6wQMQ9d1Rp2FGKmTV+SL7GJ560f2abAmppbPBfNH8ArxzjbqC1MezDP3KlvKfaRT+4Gazu47Z7ldNw+Vtsy9hqQqxUR0pozrCcT74GMizy33loHj9sq4+MKMOKI+NW00QckujEffqVBp3qik60JhguLHyeu3WZh+Z9+kCpSuw7w3mBGWZifgRZI2Dq+jTYyQMJduW1wyqvDUk9WyEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3TDzjaB1CsC+v4d6fNQUgbjYY/jzjV5+vqvFpqFwdro=; b=MQW20aESQ9NJJahkivNer5pl5zaSUzt8qD1Aci0Kn2GF+MuIEoPTiuR6ce67xDgG+Ib8z7PEm+NJ/xHhfFWCwdUTy8RQei2sYllnjyUdgp8l7xqspKb1xC8P420xHlGd60wrF83XCq158gpVCRuW9afdanhY41C6NsXNk4wKdQ3dzxWomObQ5hX1euIR1PdK2Mg6dsEM5b+oZ9QBb3ohq7oCX7YHtm4JTY7cXy6NFeUGjUvaC7LFpckY9qw+2+m20Kr0R7VBJZ0+LvZXVdH6jHSSFq0TSd/IqT7EAWgo/EnZHRL3cLQe5dcuh+wt+ZWl2hNkq8RqauhceyZ1N33GPA== 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=3TDzjaB1CsC+v4d6fNQUgbjYY/jzjV5+vqvFpqFwdro=; b=uZVnGxE9NbBpgvWjO6DVTs7Np96lb9RkeeIxiRThdfsoxtagOwR4zLe41MHPAhmsKWRGQAuWTe9kNkTz2PcIlj3JUkmuVrHToTpv3N9v5Yh90VevgxLEhDRKCqMeWxD6repmA8ZFhGh9zzTutOakAyJUN+MnhdoqhETHtLjoGiU= 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: <9c6c4c93-9782-4192-8528-fb05ec1ebce4@amd.com> Date: Mon, 19 Oct 2026 20:29:21 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0 From: Jason Andryuk To: Mykyta Poturai , "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <103b10d012cc291906025045a2da1ce728f0bffd.1792072426.git.mykyta_poturai@epam.com> <25df5d8d-7cd3-4344-86e1-8af883fa9a65@amd.com> Content-Language: en-US In-Reply-To: <25df5d8d-7cd3-4344-86e1-8af883fa9a65@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: BN3PEPF00022BC4:EE_|DS0PR12MB7653:EE_ X-MS-Office365-Filtering-Correlation-Id: ffde64ba-4454-4fd9-6121-08df2e4130e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|1800799024|376014|7416014|82310400026|56012099006|4143699003|11063799006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: CFqSIjwyxGTXQ5MEDkQWvSmBCrfEbwQK7C6yaDXuMBComfhPSZy0CJAlzciMM2xuSqiEOIAQwKEsntI76PYGz5inYyfNS+LMk4LEeyxn3PKPOhZJrOpar6qktW88aA1NeeuCcuBpHNoNhR+A+gG1d5ZXulgVJweEZo8DGX570TD4san9FeXilsTSeFpXhxvEOH5cGJCAcXaxM1iLV/M6RLLigdZCy3vdsaq3f+UeDuSYPJzKXHhrvhqcivr2j4LTICUlbKtX1EKmXwZYZc27eg2154u+nWZaeiOtYMqhyfb494Df3ighIXvSJ/4bNjnTatUL001kj7rUVXSUdgR1H4um0WzJ/3j2kmBsQOdvhmFcmHhG2ACymyDa3512USGwIp/80ZKAq6pmckUsDQTV9RxbDRCmnJ2Osi1cUzgwGaEJLMp+GsQZNDzVUFrL5VndruzmyGgI6hwDJXbULzAx2y0o2bhlHWGEtf+qtCn8H5RDr+kk5N1TFNPOiCYv9eaZ6YK2g/POej1yBIxEEbuFtQ3RLKzugWwa8uOiInxbsp7xusvk4G0WEXI9foOsIuoMbdrmjGnRMEGuSLZcVptHsdFSWhF21k4QNQENvuD85/B8dnLV4J6hzE+qUFe7gUPbCGxiicTt9kb4p/S2xCaVszEVzSzkjNlxR0+nAx5kyAE9F2y1UpYi2edImQj2PHzxhnCgRlM6Z8QbKPjVD/N9jQ== 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)(1800799024)(376014)(7416014)(82310400026)(56012099006)(4143699003)(11063799006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: BuE62R5OUyVQF/9CceNOsxqyKJD/2f/2cgnkXdQwp3uyl9D6lBad6Teaz7gHsQkI1inPJLMwJWydv2eM8kxgQFReJOCd7i/B6t11e7E6zpaq4vtdYtKszb8w7/fpgCrGpZIep8Js0nPWbkvVHx4zuDxK2renac2pu9p8gH+9f/zlWXCEq+vA8yQyswJy+qN+hXqhj7bjFPyukH2Kj/mD8zl35DKcq7hKZ+PeyQIaaZrkfwdBXwB/w9ee8O4WxGDiUhpSavfw+CVIc/ttnvBM4dL+LJu1uChzjDMR865GMKxZNU38B7e0MjKgy691USlGASS3v5MmpD0RNGUpsDNLN2u6ZhbwN6kl45GOm+FPVPS3+ywI+52KwOvF52KiBHFbXxBI+4xL6v34PaenzHYosLl5r4uTLku/RX32MJRl/OqjzeUkSRfRmQo4L9ttUYCA X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 00:29:23.7299 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ffde64ba-4454-4fd9-6121-08df2e4130e1 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: BN3PEPF00022BC4.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7653 X-purgate-ID: tlsNG-bad1c0/1792456171-BFAD0034-BB263F8E/0/0 X-purgate-type: clean X-purgate-size: 1294 On 2026-10-19 17:47, Jason Andryuk wrote: > On 2026-10-15 10:08, Mykyta Poturai wrote: >> From: Stewart Hildebrand >> +        struct vpci_bar *bar = &bars[i]; >> + >> +        /* >> +         * The upper half of a 64-bit BAR holds no address or size of >> its own; >> +         * the handlers reach the lower half through its type alone. >> +         */ >> +        if ( pf_bar->type == VPCI_BAR_MEM64_HI ) >> +        { >> +            bar->type = VPCI_BAR_MEM64_HI; >> +            continue; >> +        } >> + >> +        if ( pf_bar->type != VPCI_BAR_MEM32 && >> +             pf_bar->type != VPCI_BAR_MEM64_LO ) >> +            continue; >> + >> +        bar->addr         = pf_bar->addr + vf_idx * pf_bar->size; > AIUI, the PF has the SR-IOV BARs, which are sized like normal.  But I > thought the pf_bar->size needs to be reduced by some factor to get the > per-VF size.  I can't find where that is done.  Or am I wrong about this? Ok, I looked around and I think I was wrong. The SR-IOV bar returns the single VF size, and it is up to the OS to multiply by the number of VFs. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Tue Oct 20 02:34:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 02:34:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455071.1668616 (Exim 4.92) (envelope-from ) id 1xIzgC-0003cH-L9; Tue, 20 Oct 2026 02:34:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455071.1668616; Tue, 20 Oct 2026 02:34: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 1xIzgC-0003c6-GV; Tue, 20 Oct 2026 02:34:20 +0000 Received: by outflank-mailman (input) for mailman id 1455071; Tue, 20 Oct 2026 02:34:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xIzgB-0003c0-C9 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 02:34:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xIzgA-003Cbq-BC for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 04:34:18 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6d2aa-2eae-0a2a0a5409dd-0a2a4508a3f6-36 for ; Tue, 20 Oct 2026 04:34:18 +0200 Received: from [52.101.56.37] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6d328-f659-0a2a45080019-346538258a28-3 for ; Tue, 20 Oct 2026 04:34:17 +0200 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by EAYPR03MB020516.namprd03.prod.outlook.com (2603:10b6:303:300::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 02:34:14 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 02:34: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=KHGT/xCP/lHKmmMUSuq0hdGfRGkSljSqmHjs3i78F5y7cjkFelkpLJyMwBILwV0AmSEO4B/SFchpkWdeW5HAXNl1pr+K72F9QShZy/UKt0KmbhJcVTwH1ftCRQmqUxBv2pAsfrF9GWkRzh0Wyb2dDscS0wNxR5TfUTsj94LdYEmgaZTHJ0ZzIZZHPmli0zN08PNPMIktX4QTHEE257WL5+bJx0VVGdcEhohv7Pd68wpdNfr20M3ZwbaOuwdVOIJ0S94DZR8bWMTuaHATokNxJQun0MqB7ijIVyKMhZMPWN4OZ9oFHHeoB9RKxh83f83RINdY/VAXnWf8jaoXAJ3rcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bSyAJ+7mF0iFg6+8/U9QEEA0hLWt2Jce+tVfic3iu3A=; b=jDhUza1YTYqhEniKTQkxiAHyu3quiytiDb0py/KAJy3EGHQhX476wCw1tOODfvSJShV8RY6sgK22YNP6F9ecyLCSTmEEm8F76ydcBqeNbKQ6D+UGZS3U+1V0MstC3F1MrrbX/9uY3P1ArtKNu2wTF7T8TmA6faFnLXYdkFn4R+0F+AxZ8mydERdslPlts/FBYOtSmVBqfrqgIdy/c/6400r9oLJGWl6KIMMy2wEMr4EECXcTuH5oUAYNZhS5P+KJHjQnLFyYA+8TmyH+kLc+9YzSGa1WwF3G2KNH77inh6KVSude6I80kE4hni9n4S1fxgzj4RNHmwJA0Ot+NKi4lA== 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=bSyAJ+7mF0iFg6+8/U9QEEA0hLWt2Jce+tVfic3iu3A=; b=agjxeqGGFZC53DX1bm2lJiUQKHoFykQhlqULWPvs3R020swZmNOBDJYcV3W1hodxx3HXn6JsXJ4qUjWDB2sEZOAt1CnHLSXDkhcQZlOj4pGb9+4cB30Dzo31jIiMPseIWsVvfS/trhoOoYzbAfDjKKsRhGNI8rdJHb5VfnQxvAo= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: kevin.lampis@citrix.com Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 2/5] x86: extend mod_l*_entry() to optionally return the old PTE value Date: Tue, 20 Oct 2026 10:34:00 +0800 Message-Id: <20261020023400.295707-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20261016164815.3109065-3-kevin.lampis@citrix.com> References: <20261016164815.3109065-3-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JNAP275CA0019.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:4d::23) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|EAYPR03MB020516:EE_ X-MS-Office365-Filtering-Correlation-Id: 6211ec2f-fd22-411c-295a-08df2e52a1b3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: YW+mu9WkEpmOP6yzfOxOnN3gKCAlybfRQ1DW3cZkJ4W5j9FdDyAE0CDGtRhYXZfDiuoXMbQ+Pk94WNvAeseF0Ji7+Y07wOZ1B+ey3szq21fpaMRiwR4zrfZCT/uwnYG6wGPg5YRaqe8sPwlTyPnJ44Eom+Ol3mu9wB3DAhgSPVvFx51xfWDC2bETsqWf5di3Qq+0QMOE23GmkBGT3jGZloBt8wQUODrKazkNVN/YOf6nHERyyOmhfh3AovS7o0QWaj57kBtbq67pOXepNEx+BkDOnBQIdxgkCipJSvRH12Erf6x297kzvcU9OgqNKaVDAZjocx8S1npr9BHyAnA3d9gIiz0aKPTSmDPjWk9LBSNPT+8uM8oD6KktBqj6i8YXbmUr6L5ZwGYQ2MwqwEu8CswlD9/LboiC8OG4FjzC3ejenU5CC96afAhMoJtQ+6nzzp3rmr68Agh0YDA5LVS1qIqfrNQt8FRz3iAQbQ5dRz8zYtFvFvd4+Af6QbXOGYNvYPneCEoM1JjaofEeInP+A1ZOsPcWmr2F6huPsVQDY3KOboTWzUWcYdQR/N1H+oAhoAbiWdgZbVBKPtR2jRhtPETdAVUcksqnVw9mJORPuFEFZFgXjJfueGHJVL7Xg/EOx5tLXn7Wyfuodrn6CRzin3dJ1KeyO/vVoPNSrMJAJUg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HLR50HZvW68Mnz2WjpLp5rnWAysPwWLyr/2TANQrCdFqXjQrH6dvHFaz12nQ?= =?us-ascii?Q?tQOHYyAkU9iokJFNvl4kGngGHJ3NRO6CQuHtGezYpiGM4iXJKozIURK9s+Ru?= =?us-ascii?Q?Ch4fjIoZeX4C6DWEmZzaexA7sDLh3BA72E6zUvFtWtB3jeQxfpJzDDDKViQn?= =?us-ascii?Q?h89vUSJPa9i9uXkItSRyGJmOR6JWic4pfRDjRsL3T33y7qMaqR1uk4u7UhiC?= =?us-ascii?Q?MbjpwHRUxNtzlveJ+blfqrIpBlrSHZQEhrfsyN3/3xrj9zxGmlR+qdD5RpOb?= =?us-ascii?Q?Nb8ekOU3UuzqsYIPap6nD6AlQdpqlH7+eX8a9IAS64ewqQI3EiXQqTqySs0Q?= =?us-ascii?Q?6vp2L5pOeDVZ7BzBgWanfEz7REJhjK+dEmuuhSGMYmic5nd6VbbyEqc3qZgg?= =?us-ascii?Q?dgQg2JzcPTV/lzp0k5EAnRq/hc6oFmJ9dV5CKmDePTc3dgAGW2a9WMaKIVon?= =?us-ascii?Q?6WZsaNiboymAMrimUIXOxaeRrzjVpsKcHnp7P3RAly0GlyOZT8uZ9LWZeQ69?= =?us-ascii?Q?7k6hKVxf1lZocpF652L8GZ9TbharkYxHPUw+I5Cz7y8K8B1Z53NOgah8iD4q?= =?us-ascii?Q?Dl+3UruuU2fAxvNIPHziq363hnAsd8UcPxBDOwdeiL1feeGx4uRAtEUASUKa?= =?us-ascii?Q?5X4FUoxlH9RZfCw39gwhxV4vDzASccYbu3nTP42k0DfHfKcpKgirZda0Xqtv?= =?us-ascii?Q?5sLJY2Mwoj+qeTHICznygSF6gEX9xwqcmtfhVB4x5zup1d6Fho1VSTMIvLMH?= =?us-ascii?Q?9AHAezMWQ14HqckOCaqcb7anQNCX8hk0Vy5T7sHCc/tuinw3PfZUB5R+LwSD?= =?us-ascii?Q?Jsb2QO86mkw7/f95d6sIhVtMirICYiGJmBlNSHFFYhygY5sQTbOmNQK73ACV?= =?us-ascii?Q?rkepa8h4Xhlx/B9bipE6X+xOkfJG9tFnMFi1nmrZJDNrXMIco8yI/GPGF1O+?= =?us-ascii?Q?WJZ+YxpwLVyyMio48td10X21S9LatNjHjgX5Kgnk3mf28c+ayMRUUqxPcpxH?= =?us-ascii?Q?ChYpK/xOIxcRB8bL5j2Yd8HcEb4VLyWPhsgRsWi6vXNEKIQVL0rHQzmkSKVr?= =?us-ascii?Q?RoK1Z9YRVL1OUT4a9mFPaUyLmxr7fK6M6T2OVX4sCU1k7JaxQrEQYcj7YNik?= =?us-ascii?Q?+ByYcUOdycZA9Azupt41KLWLvbiJxrfrDbKV/1ISr3bzwCwb+VzxVrB1unZE?= =?us-ascii?Q?mppkQaw8RaaDBnJJVKy7wNouK6jhBDW8LiOqnyMztCuOg4+XXBM2UFlatwpG?= =?us-ascii?Q?s4jLD1E0ecBA7dTbC2Sy6ZN8NvND0pZe5hjKLrtQAorClOrglihw1ccgoyg5?= =?us-ascii?Q?WJqaEwpyzaNV3TRMSpD+oPxnisLhwIbcMIjDC1a3foQc9p7leUCoOFE9Bm3z?= =?us-ascii?Q?25Js/Hm8LENzkimrpETK4Lk/BZqENGZpA0Au3DV2cfMi8E+YZbXGgXAjmHS1?= =?us-ascii?Q?mL2c8wVjLF6Ee+e1OhxnYPa0NNVRTaGbIFybaTKlyxbZLbJJTOEeyfPqfvde?= =?us-ascii?Q?OOMAXSVem2x4maOla/hofRuob4K21HWR4UVBgK+u0UngpcU2GRePUk+lKevl?= =?us-ascii?Q?07OQYidL5rctTKu4AtrVJnb6K2edqwtXC5Xl+lvuUGXS1RKuUCueZNX2nXlj?= =?us-ascii?Q?aGLQUh0G+rVKqd4c1vOHuNVCyLKu1E6utGh9m6UvzJTgtflTmil6oSSnJ+QZ?= =?us-ascii?Q?N0exRpN+zRbDp3JjrzQyWZjGonkSrMigTGwY1S+VzuE8N+St2beEiQhHCIHg?= =?us-ascii?Q?TfbiMDixMg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6211ec2f-fd22-411c-295a-08df2e52a1b3 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 02:34:14.6225 (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: 2APrDg6emZ3vBxiKR2AkW98L8X3DlLo/KXj+gWzfKFSuy8RLjWZT3s2C0iSmUyqqUCS2BcSEUUXpNbl0u4k7jQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: EAYPR03MB020516 X-purgate-ID: tlsNG-c1860d/1792463658-CDB4987B-97CE6F03/0/0 X-purgate-type: clean X-purgate-size: 2366 On Fri, Oct 16, 2026 at 05:48:12 PM, Kevin Lampis wrote: > Calling mod_l*_entry() with a valid ol*e_out pointer will do atomic > CMPXCHG to set the new pte value and return the old pte value through > the ol*e_out pointer. If the ol*e_out pointer is NULL then old behavior > is preserved. > > Signed-off-by: Kevin Lampis > --- > Changes in v4: > - Refactor how UPDATE_ENTRY is used > - Update commit message to specify CMPXCHG instead of xchg > > Changes in v3: > - Add swap to mod_l{2,3,4}_entry() > > Changes in v2: > - UPDATE_ENTRY now returns the old pte value instead of using an out > pointer > --- > xen/arch/x86/mm.c | 106 ++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 84 insertions(+), 22 deletions(-) > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index e42cd33c0d09..609c8595a487 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -2193,7 +2193,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; > @@ -2254,7 +2255,11 @@ 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); > + intpte_t old = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, > + update_flags); > + if ( ol1e_out ) > + *ol1e_out = l1e_from_intpte(old); > + Same "intpte_t old = UPDATE_ENTRY(); if ( olNe_out ) ..." code block is now repeated three times in each of mod_l{1,2,3,4}_entry(). Alternatively, a single local variable per function, assigned at each call site and copied out once at the end. Does this avoid the duplication? From xen-devel-bounces@lists.xenproject.org Tue Oct 20 03:05:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 03:05:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455079.1668624 (Exim 4.92) (envelope-from ) id 1xJ0AJ-0000T3-Nz; Tue, 20 Oct 2026 03:05:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455079.1668624; Tue, 20 Oct 2026 03:05: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 1xJ0AJ-0000Sw-LM; Tue, 20 Oct 2026 03:05:27 +0000 Received: by outflank-mailman (input) for mailman id 1455079; Tue, 20 Oct 2026 03:05:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ0AH-0000Sq-V5 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 03:05:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ0AG-00G7Zo-9i for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 05:05:24 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6da5e-e002-0a2a0a5209dd-0a2a450c8fcc-16 for ; Tue, 20 Oct 2026 05:05:24 +0200 Received: from [40.93.195.26] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6da72-f479-0a2a450c0019-285dc31aeb7c-3 for ; Tue, 20 Oct 2026 05:05:23 +0200 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by LV3PR03MB7432.namprd03.prod.outlook.com (2603:10b6:408:1a5::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 03:05:20 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 03: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=FErW5QHXosfYnH1RgkUSTQ8yOJHFvCMqPjtG6UZiyB3RFXw6LOW9V9q7++JfVMVIoopwHiSN8Z6iunFA2U400u9VjtMbdEEignvEML/q1vWnS9sgui7m5lJIfgg9il4vlI/PSssLs4h98YVLX3gC8fYX52V1iB5KNmbFqvIuPCoWiUPvz2ZXa3dHoxrFtM9H7tvKuvwoLBAZyd9cdO3L9C+64ulrXtqMWBWTn/AUJK5L+3hxl04/IJ9fnhIrR/8luTJ1jWI9zKMRJQXR4O7lqXCQCAPtN1i85okVVP1jbGL/mFR7W8brf7cQ/4nC4/MxEVGKr38Pt9iP/dbQYgESXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Whm9uRPOF4Hbvb1JS/w5hT4zxkjRsYJdS4cbIT+zFDU=; b=F4CItEqE6zx0EXmHn4/y62x/bhPguVO5UEYBYbqfnlotCLA9mk8yPk/ox5qOZBPNVl8R2kDILzIqImLqjtUMGzuCQc663ET5xj4HHONDGzgY3c/EjS5tkITkXf/qcUvsVe02tLVcgm7hhssV2288de6Si6cMlMjm44ZKP/0MinHggbiyRacGfAs69Q5FmKuCUXwDagwALukbqahv6aR+MJXGWR6g8fS8ohejG9odUGLDMpxg8n1lT0XgvQiZ2eC9Bm6TVTOvhlmCbg6XzuKjlhfwxBNWOxlbt1in4pB503k95zjE7HA5GiPXoj3S0HXLgd7OveoPRIBFvzkX8wM9XQ== 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=Whm9uRPOF4Hbvb1JS/w5hT4zxkjRsYJdS4cbIT+zFDU=; b=CB+9YH/YjxlTGXomimENvn0ksW3QTvayx//1G4V1nJtBY0h1WSvWkZVcSeJesvT6YIThDW10nSlMWW5CSFM2OAkVJ8LgszdhzcrwSOngafYsCl/3nCMZpfOLZgNp+im1wXv6Ej8HcX9WvO+FdxKcvEpR1ZU8GJIxfh4K3euaOkU= Authentication-Results: mx.microsoft.com 1; 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: [PATCH v1] x86/nestedsvm: remove dead code for shadow-paging L1 hosts Date: Tue, 20 Oct 2026 11:05:09 +0800 Message-Id: <20261020030509.308211-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI1PR02CA0004.apcprd02.prod.outlook.com (2603:1096:4:1f7::12) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|LV3PR03MB7432:EE_ X-MS-Office365-Filtering-Correlation-Id: 4fa5a97c-65b8-4fc9-50eb-08df2e56f979 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|6133799003|10067099003|18002099003|261009223027099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: CiOR5PvdZpWp55hl7u2qr3BdAY2Hcu2414lJYQzBhjghhYV5g5C+eD00j8sOB9fjuc0OJga2gBSZ+jE33cDhd5ZlC401BXJACm/FTS8wWaJ2qiDTCR6Ls+WbDhfZ/PEhGIoT/2T2vyIBnxCB//YaBPptCQrk40tmkSgeby9Al9+iHqJYse8meV0ws8Sm0tyEDQBBJoWok+VUiciI5MwqfFWIfppliEVlATx08luirYoGM9UlId7hf/3zOyK5gWU/1XNqdlYbTT233LyYv245hWixe/dugZuFu2/cD77CYMHH7veZW6Qful48wTZtc5t9xi00aFXhW4y7XevTGu0x3Dm0gjCtDLw4u/nuzYeGWISdp+iFPs599Fv+yesfdZdok1JkY95NGsY3dAL9bPS5weOUv6VzTtOICH77R7fjPGavPn6Jk+eSWheTB+QAxyTwqADepKTwB9sw1pHgZscv/RV0+l/DbJmmbR1YJvzR6AzZaFUwUphCd+6t5RLW1ZPJKqPW2qTUUNU6vbWO5CxHAp0TPyQCbfenO5eE3qdPK6bx3/njw4B0CWtSf1P7BOTbBgGM93lBeuN2ox6roq9M8tK9SjGJGAxp1K9eGW3eBSqVlc/3OnE30mUbTHu8JltFcuhfPzVdsNpyX61LNLaTXq6e2Q90POGc5trCy+xEaUY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(6133799003)(10067099003)(18002099003)(261009223027099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RqH7xEFr5x+gPyJNIC2gZTc2zt/x7iJZDxKUo8WwoF/GfY73of6XN5IGuiGf?= =?us-ascii?Q?mSlpmEhOOk4alZquq+SJkRSjwxH8ady3zmFOiM5MfP5fOtTz+K9dAQItvIU6?= =?us-ascii?Q?a8rqmtBDDbp0yHKNV05q1vF/wWV1levPT4630AeUKQUxTxiKE+rF1n861zGl?= =?us-ascii?Q?WwflfWIRNYtOu02eH5/vNWckIoH5SCQWvh/HrDdgpqTSIKtRzeHOX0rKC9Z5?= =?us-ascii?Q?fJfJz850skiB92ljf9+CInRhajAQ9clFT4Q2HD0b/dVebRMjI1WIYq3e5VHL?= =?us-ascii?Q?Ap0VSVTbTuoODVKV75rUmhabGU4gil5HnUDDzaOsDytZFwraKqkx7SVvvdFD?= =?us-ascii?Q?HgO28yAZzPfE35jpECSkl0ukXMFt2WGpWAebaOWDsY2Y+jedEzEvyR6B3Lsc?= =?us-ascii?Q?7DF6QSAKRfdceoTCoOGi7v1FIm3IxTr7VucT+GYfrXmIx1ZWltfeC9LY0lE8?= =?us-ascii?Q?dO1Ph5dnqd0l89LzjqzEgT73xT17hd3zCQ69ymKGvAcYluzLrNYxbMnZfs5M?= =?us-ascii?Q?YrrpVZNr7QWGWIN4N7VBJFc5EsbR6D3EyCSTcT++3Vy2fuvpWYKCaNFBEztB?= =?us-ascii?Q?GYbCZkPALjOTKgeMBlx+SW6pf29roWgpTKVitVn0upIuSLDyb9GqlC+tLxgT?= =?us-ascii?Q?lwgrRCXaKrALAouazTY2cxmhq4d4cJDoZ4BCYOetc6rWuyD3XsvMlB/RbczG?= =?us-ascii?Q?33omApEBOciK6FwkmHrfIS6KXMEfdSx5n2KaUQ1aFnxcjPzd3nqC30/pt/Xj?= =?us-ascii?Q?ePX1RcgEKEWE6T83MSs+Suw8ItyM8jk5D1Ijwhz9gL7CfPs5AbO88WzFIltJ?= =?us-ascii?Q?CvuvqQKYod9F5fifmHrk64m4VWEonrpAtfruwBKL4P0funqSZHHginHyLzrw?= =?us-ascii?Q?585lsmKEjrM1SHyygt0Cmo11fc0J4ULfpNEdiaMT1c+mEdO9byROPiv0JR94?= =?us-ascii?Q?errGEFrZBcdfk9p3K5hzrQmu+x5JexhPu0BrHo0/cvakAA3/C/FbjqbqLUsn?= =?us-ascii?Q?/lI8m1RXrmRcqoz5tA/dQLMGUWk7ljXWIrYXLgkwWlsUHeNKhJCw262Dlmqb?= =?us-ascii?Q?1c9os5zemlfH85nQ+f3m/30C++6OCsVkL2hPqAApyAnijO5LTsJXrAtnejj8?= =?us-ascii?Q?mYsbTHBsTmZl/5dmYtWYstoHkClATSU2sCAG+VwH2IrC0oQlUr6q2Wb0JBhZ?= =?us-ascii?Q?2SEeiSegSRgC3drMMJR94sjmKZy/CYHYMEiPTt/WMisW1ExLgy/sS7M6QDuJ?= =?us-ascii?Q?Wd46qh2DFes9pOjjJmQHbRJqPoFSmbWfIYZ2W5h585eCSqDtHhgUgluhV0an?= =?us-ascii?Q?r0nEklVHWsWk/AJRpC5YR46SlU9/xCJllZyjwuu39ex2n1Jim9LrkZ2IiQ1+?= =?us-ascii?Q?0dJ6vhPxAYbdemCiJniRLbW5EuQkIQwfDFLaVbZYV+WzU+SgpFdVobr+pciU?= =?us-ascii?Q?TqMA2rLEqNd6H8AYCSne6tULo2whPTDSBIS5bWYdmppT2j2ixVcduZpODRT2?= =?us-ascii?Q?Wu4Ewt6keTsp3rYFSqQxp8xHLwGKnoZ5ueXd86foqvYgW9XS6DODbRyWuKb6?= =?us-ascii?Q?J6i3oFat+lvnq/ult90gpG+BcNhXYTcpC8cn22SOwfvRHJ62g6J1PRgLLY4G?= =?us-ascii?Q?eZzr56ysnoNxU2MPWjvZxZPnQ8/hSEI4PblGEg7Xk6dXcxRbKoK7vxwm3lP9?= =?us-ascii?Q?Amdjpyf2AMEZwCbNmBXT4AAgGTZxp3dW3rWTxNnA40LvWitwNArL6vRSrebF?= =?us-ascii?Q?bY3eQ3xwsw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4fa5a97c-65b8-4fc9-50eb-08df2e56f979 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 03:05:20.0764 (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: 0dHIx6uoprbvB67teEZAR+Vbuu4qPcK0MwWilJvnJxa0l6V7h/l3FEpDnM+Nm5T373Q8w/BqwmeXBqkimjrukQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7432 X-purgate-ID: tlsNG-d25034/1792465524-76CDBA5B-FEC71AD0/0/0 X-purgate-type: clean X-purgate-size: 7370 From: Chunjie Zhu Nested virtualization is only permitted together with HAP: sanitise_domain_config() rejects XEN_DOMCTL_CDF_nested_virt without XEN_DOMCTL_CDF_hap. The L1 domain therefore cannot be in shadow paging mode while nested virt is enabled, and paging_mode_shadow(v->domain) is always false in the nested SVM code. nsvm_vcpu_hostrestore(), nsvm_vmcb_prepare4vmrun(), nsvm_vmcb_prepare4vmexit() and nestedsvm_check_intercepts() still carry incomplete, never-executed handling for the "host shadow paging + guest shadow paging" case. Drop it, and guard the remaining branch with BUG_ON(paging_mode_shadow(v->domain)) to document the invariant. In nestedsvm_check_intercepts()'s #PF handling, test nestedhvm_paging_mode_hap() first, so the reachable "host nested paging + guest shadow paging" case returns NESTEDHVM_VMEXIT_INJECT directly. Also drop the now always-true paging_mode_hap() check from svm_nested_features_on_efer_update(), and the stale "shadow-on-shadow" TODO in paging_update_nestedmode(). No functional change. Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/nestedsvm.c | 65 +++++++++++--------------------- xen/arch/x86/mm/paging.c | 1 - 2 files changed, 22 insertions(+), 44 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index dc2b6a42534a..748c821d40f8 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -304,21 +304,12 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) /* 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) ) - { - /* host nested paging + guest shadow paging. */ - /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ - } else { - /* host shadow paging + guest shadow paging. */ - - /* Reset MMU context -- XXX (hostrestore) not yet working*/ - if ( !pagetable_is_null(v->arch.guest_table) ) - put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_null(); - /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ + /* host shadow paging + guest shadow paging cannot happen */ + BUG_ON(paging_mode_shadow(v->domain)); } + rc = hvm_set_cr3(n1vmcb->_cr3, false, true); if ( rc == X86EMUL_EXCEPTION ) hvm_inject_hw_exception(X86_EXC_GP, 0); @@ -580,8 +571,11 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( rc != X86EMUL_OKAY ) gdprintk(XENLOG_ERR, "hvm_set_cr3 failed, rc: %u\n", rc); } - else if ( paging_mode_hap(v->domain) ) + else { + /* host shadow paging + guest shadow paging cannot happen */ + BUG_ON(paging_mode_shadow(v->domain)); + /* host nested paging + guest shadow paging. */ vmcb_set_np(n2vmcb, true); /* Keep h_cr3 as it is. */ @@ -596,16 +590,6 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( rc != X86EMUL_OKAY ) gdprintk(XENLOG_ERR, "hvm_set_cr3 failed, rc: %u\n", rc); } - else - { - /* host shadow paging + guest shadow paging. */ - vmcb_set_np(n2vmcb, false); - n2vmcb->_h_cr3 = 0x0; - - /* TODO: Once shadow-shadow paging is in place come back to here - * and set host_vmcb->_cr3 to the shadowed shadow table. - */ - } /* DRn */ if ( !clean.dr ) @@ -1088,8 +1072,11 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) * 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 { + /* host shadow paging + guest shadow paging cannot happen */ + BUG_ON(paging_mode_shadow(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 @@ -1099,15 +1086,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) * 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 */ @@ -1320,16 +1298,16 @@ nestedsvm_check_intercepts(struct vcpu *v, struct cpu_user_regs *regs, /* host nested paging + guest nested paging */ return NESTEDHVM_VMEXIT_HOST; } - if ( paging_mode_hap(v->domain) ) + else { + /* host shadow paging + guest shadow paging cannot happen */ + BUG_ON(paging_mode_shadow(v->domain)); + if ( is_intercepted ) return NESTEDHVM_VMEXIT_FATALERROR; /* host nested paging + guest shadow paging */ return NESTEDHVM_VMEXIT_HOST; } - /* host shadow paging + guest shadow paging */ - /* Can this happen? */ - BUG(); case VMEXIT_EXCEPTION_PF: if ( nestedhvm_paging_mode_hap(v) ) @@ -1341,12 +1319,14 @@ nestedsvm_check_intercepts(struct vcpu *v, struct cpu_user_regs *regs, /* l2 guest intercepts #PF unnecessarily */ return NESTEDHVM_VMEXIT_INJECT; } - if ( !paging_mode_hap(v->domain) ) - /* host shadow paging + guest shadow paging */ - return NESTEDHVM_VMEXIT_HOST; + else + { + /* host shadow paging + guest shadow paging cannot happen */ + BUG_ON(!paging_mode_hap(v->domain)); - /* host nested paging + guest shadow paging */ - return NESTEDHVM_VMEXIT_INJECT; + /* host nested paging + guest shadow paging */ + return NESTEDHVM_VMEXIT_INJECT; + } case VMEXIT_VMMCALL: /* Always let the guest handle VMMCALL/VMCALL */ return NESTEDHVM_VMEXIT_INJECT; @@ -1619,7 +1599,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; diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c index 65455a686787..277d84fb4cb8 100644 --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -924,7 +924,6 @@ void paging_update_nestedmode(struct vcpu *v) /* nested-on-nested */ v->arch.paging.nestedmode = hap_paging_get_mode(v); else - /* TODO: shadow-on-shadow */ v->arch.paging.nestedmode = NULL; hvm_asid_flush_vcpu(v); } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 03:45:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 03:45:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455090.1668651 (Exim 4.92) (envelope-from ) id 1xJ0n6-0007CZ-3f; Tue, 20 Oct 2026 03:45:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455090.1668651; Tue, 20 Oct 2026 03: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 1xJ0n6-0007CS-0s; Tue, 20 Oct 2026 03:45:32 +0000 Received: by outflank-mailman (input) for mailman id 1455090; Tue, 20 Oct 2026 03:45:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ0n5-0006pm-8h for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 03:45:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ0n4-00DbTG-Df for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 05:45:30 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6e3c8-2eae-0a2a0a5409dd-0a2a4503d780-12 for ; Tue, 20 Oct 2026 05:45:28 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6e3d5-fae8-0a2a45030019-9fe2fb159eae-3 for ; Tue, 20 Oct 2026 05:45:27 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowADXrvLN49ZqzdhHCw--.7730S4; Tue, 20 Oct 2026 11:45:22 +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: Zhang Zheng To: xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v3 2/2] xen/ns16550: drain TX before reinitializing the UART Date: Tue, 20 Oct 2026 11:45:43 +0800 Message-ID: <938aadfc32c531f934291fdff3763cdefd5849e6.1792467713.git.zhangzheng@iscas.ac.cn> X-Mailer: git-send-email 2.54.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:qwCowADXrvLN49ZqzdhHCw--.7730S4 X-Coremail-Antispam: 1UD129KBjvJXoW7KFWUKryUAw4DGryxAry7ZFb_yoW8WFWkpF 48KwnYyrWDGa1UGaySyayxGayYqF95uFWfKrykCwnIvrs8Gw1xursxJFyYqrWDArW8Xry3 KFsIvF4DCFWkAr7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPEb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI 8067AKxVWUXwA2048vs2IY020Ec7CjxVAFwI0_Xr0E3s1l8cAvFVAK0II2c7xJM28CjxkF 64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcV CY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv 6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzV Aqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr1j6F4UJwAm 72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI 1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_ Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17 CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0 I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I 8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73 UjIFyTuYvjxUqWrWDUUUU X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-33051d/1792467928-776F34E9-E988E6E9/0/0 X-purgate-type: clean X-purgate-size: 1761 Drain pending output before resetting FIFOs. Bound the wait to avoid hanging boot if the UART never reports empty. Wait for TEMT (which already implies THRE on a 16550) to ensure transmission has finished before reconfiguration. uart->lsr_mask normally checks only THRE, which indicates room for more output. Signed-off-by: Zhang Zheng --- xen/drivers/char/ns16550.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 1f54155d67..29f784280e 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -410,6 +410,12 @@ static void ns16550_setup_preirq(struct ns16550 *uart) static void __init cf_check ns16550_init_preirq(struct serial_port *port) { struct ns16550 *uart = port->uart; + cycles_t start; + /* + * Too early for proper time calibration, assume a 5GHz CPU and let it wait + * about 1s, with still reasonable timeout on a slower CPU. + */ + cycles_t timeout_ticks = 5UL * 1000 * 1000 * 1000; #ifdef CONFIG_HAS_IOPORTS /* I/O ports are distinguished by their size (16 bits). */ @@ -427,6 +433,15 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) #endif } + /* + * Drain firmware/early-console output before changing line settings or + * resetting FIFOs. Wait for TEMT so the shift register is empty too. + */ + start = get_cycles(); + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) && + get_cycles() - start < timeout_ticks ) + cpu_relax(); + ns16550_setup_preirq(uart); /* Check this really is a 16550+. Otherwise we have no FIFOs. */ -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 03:45:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 03:45:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455088.1668633 (Exim 4.92) (envelope-from ) id 1xJ0n4-0006nr-Mu; Tue, 20 Oct 2026 03:45:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455088.1668633; Tue, 20 Oct 2026 03: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 1xJ0n4-0006nk-K4; Tue, 20 Oct 2026 03:45:30 +0000 Received: by outflank-mailman (input) for mailman id 1455088; Tue, 20 Oct 2026 03:45:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ0n3-0006nZ-5s for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 03:45:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ0n2-00BZmn-Ff for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 05:45:28 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6e3ca-bab6-0a2a0a5309dd-0a2a450abe5c-10 for ; Tue, 20 Oct 2026 05:45:27 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6e3d4-f2d2-0a2a450a0019-9fe2fb15a8cc-3 for ; Tue, 20 Oct 2026 05:45:26 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowADXrvLN49ZqzdhHCw--.7730S3; Tue, 20 Oct 2026 11:45:20 +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: Zhang Zheng To: xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v3 1/2] xen/ns16550: identify XScale UARTs from device tree Date: Tue, 20 Oct 2026 11:45:42 +0800 Message-ID: <3e8fac86f88d9d3d002b86469b87c20aea53fcef.1792467713.git.zhangzheng@iscas.ac.cn> X-Mailer: git-send-email 2.54.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:qwCowADXrvLN49ZqzdhHCw--.7730S3 X-Coremail-Antispam: 1UD129KBjvJXoW3GF4UKF13Cw18Aw4Dtry3XFb_yoW7Gry3pF WxK3ZYyrWxtw18G3sIyF47Wa1Fgwn3u34Skrs3G393XF1UtrW8CFy5AF98JryDCrykJFyY kFZYyrWUCan8Zr7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPEb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI 8067AKxVWUGwA2048vs2IY020Ec7CjxVAFwI0_Gr0_Xr1l8cAvFVAK0II2c7xJM28CjxkF 64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcV CY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv 6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzV Aqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr1j6F4UJwAm 72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI 1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_ Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17 CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0 I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I 8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73 UjIFyTuYvjxUyVyIUUUUU X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-4011c0/1792467927-512C8CFC-7CEF4191/0/0 X-purgate-type: clean X-purgate-size: 5393 Identify XScale UARTs using intel,xscale-uart, since IER bit 6 has other meanings on some UART variants. Keep UUE set when writing IER so the UART stays enabled when switching to polling, and enable RTOIE along with receive interrupts. Signed-off-by: Zhang Zheng --- xen/drivers/char/ns16550.c | 29 +++++++++++++++++++++-------- xen/include/xen/8250-uart.h | 2 ++ 2 files changed, 23 insertions(+), 8 deletions(-) diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index be388c8e65..1f54155d67 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -64,6 +64,7 @@ static struct ns16550 { bool intr_works; bool force_polling; bool dw_usr_bsy; + bool xscale; #ifdef NS16550_PCI /* PCI card parameters. */ bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ @@ -168,6 +169,14 @@ static void ns_write_reg(const struct ns16550 *uart, unsigned int reg, u8 c) } } +static void ns_write_ier(const struct ns16550 *uart, u8 ier) +{ + if ( uart->xscale ) + ier |= UART_IER_UUE; + + ns_write_reg(uart, UART_IER, ier); +} + static int ns16550_ioport_invalid(struct ns16550 *uart) { return ns_read_reg(uart, UART_IER) == 0xff; @@ -218,7 +227,7 @@ static void cf_check ns16550_interrupt(int irq, void *dev_id) /* Disable interrupt generation on the device and arm the timer. */ uart->force_polling = true; - ns_write_reg(uart, UART_IER, 0); + ns_write_ier(uart, 0); set_timer(&uart->timer, now + MILLISECS(uart->timeout_ms)); printk(XENLOG_WARNING "uart interrupt taking more than %ums, switched to polling\n", @@ -350,7 +359,7 @@ static void ns16550_setup_preirq(struct ns16550 *uart) lcr = (uart->data_bits - 5) | ((uart->stop_bits - 1) << 2) | uart->parity; /* No interrupts. */ - ns_write_reg(uart, UART_IER, 0); + ns_write_ier(uart, 0); /* Handle the DesignWare 8250 'busy-detect' quirk. */ handle_dw_usr_busy_quirk(uart); @@ -446,7 +455,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart) UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS); /* Enable receive interrupts. */ - ns_write_reg(uart, UART_IER, UART_IER_ERDAI); + ns_write_ier(uart, UART_IER_ERDAI | + (uart->xscale ? UART_IER_RTOIE : 0)); } if ( uart->irq >= 0 ) @@ -654,7 +664,7 @@ static void cf_check ns16550_start_tx(struct serial_port *port) /* Unmask transmit holding register empty interrupt if currently masked. */ if ( !(ier & UART_IER_ETHREI) ) - ns_write_reg(uart, UART_IER, ier | UART_IER_ETHREI); + ns_write_ier(uart, ier | UART_IER_ETHREI); } static void cf_check ns16550_stop_tx(struct serial_port *port) @@ -664,7 +674,7 @@ static void cf_check ns16550_stop_tx(struct serial_port *port) /* Mask off transmit holding register empty interrupt if currently unmasked. */ if ( ier & UART_IER_ETHREI ) - ns_write_reg(uart, UART_IER, ier & ~UART_IER_ETHREI); + ns_write_ier(uart, ier & ~UART_IER_ETHREI); } #ifdef CONFIG_ARM @@ -749,16 +759,16 @@ static int __init check_existence(struct ns16550 *uart) * there's no point trying anything else. */ scratch = ns_read_reg(uart, UART_IER); - ns_write_reg(uart, UART_IER, 0); + ns_write_ier(uart, 0); /* * Mask out IER[7:4] bits for test as some UARTs (e.g. TL * 16C754B) allow only to modify them if an EFR bit is set. */ scratch2 = ns_read_reg(uart, UART_IER) & 0x0f; - ns_write_reg(uart,UART_IER, 0x0F); + ns_write_ier(uart, 0x0f); scratch3 = ns_read_reg(uart, UART_IER) & 0x0f; - ns_write_reg(uart, UART_IER, scratch); + ns_write_ier(uart, scratch); if ( (scratch2 != 0) || (scratch3 != 0x0F) ) return 0; @@ -2034,6 +2044,8 @@ static int __init ns16550_uart_dt_init(struct dt_device_node *dev, uart->dw_usr_bsy = dt_device_is_compatible(dev, "snps,dw-apb-uart"); + uart->xscale = dt_device_is_compatible(dev, "intel,xscale-uart"); + #ifdef CONFIG_ARM uart->vuart.base_addr = uart->io_base; uart->vuart.size = uart->io_size; @@ -2055,6 +2067,7 @@ static const struct dt_device_match ns16550_dt_match[] __initconst = DT_MATCH_COMPATIBLE("ns16550"), DT_MATCH_COMPATIBLE("ns16550a"), DT_MATCH_COMPATIBLE("snps,dw-apb-uart"), + DT_MATCH_COMPATIBLE("intel,xscale-uart"), DT_MATCH_COMPATIBLE("brcm,bcm2835-aux-uart"), { /* sentinel */ }, }; diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h index d13352940c..5709a6c91b 100644 --- a/xen/include/xen/8250-uart.h +++ b/xen/include/xen/8250-uart.h @@ -42,6 +42,8 @@ #define UART_IER_ETHREI 0x02 /* tx reg. empty */ #define UART_IER_ELSI 0x04 /* rx line status */ #define UART_IER_EMSI 0x08 /* MODEM status */ +#define UART_IER_RTOIE 0x10 /* Receive timeout interrupt enable (XScale) */ +#define UART_IER_UUE 0x40 /* UART unit enable (XScale) */ /* Interrupt Identification Register */ #define UART_IIR_NOINT 0x01 /* no interrupt pending */ -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 03:45:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 03:45:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455089.1668639 (Exim 4.92) (envelope-from ) id 1xJ0n4-0006q8-Ut; Tue, 20 Oct 2026 03:45:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455089.1668639; Tue, 20 Oct 2026 03: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 1xJ0n4-0006pK-Qn; Tue, 20 Oct 2026 03:45:30 +0000 Received: by outflank-mailman (input) for mailman id 1455089; Tue, 20 Oct 2026 03:45:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ0n3-0006nY-Pt for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 03:45:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ0n2-00G7gS-99 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 05:45:28 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6e394-e002-0a2a0a5209dd-0a2a4507c31c-36 for ; Tue, 20 Oct 2026 05:45:25 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6e3d3-b4ea-0a2a45070019-9fe2fb15ae9c-3 for ; Tue, 20 Oct 2026 05:45:25 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowADXrvLN49ZqzdhHCw--.7730S2; Tue, 20 Oct 2026 11:45:17 +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: Zhang Zheng To: xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v3 0/2] xen/ns16550: preserve UART operation across firmware handover Date: Tue, 20 Oct 2026 11:45:41 +0800 Message-ID: X-Mailer: git-send-email 2.54.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:qwCowADXrvLN49ZqzdhHCw--.7730S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Wr48uw13tr4UJF4kJw1fWFg_yoWkAFb_uF 4vkas8GrZ8XF4DXasayF45KrZ8ArZIqrykta40qrW3Z34IvrsIgF1DGr15Xrn7ur4kCrn7 Aas0yr93Z3sxKjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbVAYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r126r1DMcIj6I8E87Iv67AKxVW8Jr0_Cr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACI402YVCY1x02628vn2kI c2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF 0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxh VjvjDU0xZFpf9x07jbl19UUUUU= X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-ef75cf/1792467925-A7AD0AE4-C9C2D4E0/0/0 X-purgate-type: clean X-purgate-size: 1115 This series identifies XScale-compatible UARTs from device tree and keeps UUE set when updating IER. Pending output is drained before the FIFOs are reset during ns16550 initialization. Changes in v3: - Identify XScale UARTs through intel,xscale-uart instead of probing IER. - Preserve UUE on IER writes and enable RTOIE with receive interrupts. - Bound the TX drain wait using the XHCI console's raw-counter approach. - Explain why the drain checks TEMT instead of uart->lsr_mask. Tested on SpacemiT K3 with Baptiste's preceding A/D bit patches applied. v2: https://lore.kernel.org/xen-devel/20261010031406.2057735-1-zhangzheng@iscas.ac.cn/ v1: https://lore.kernel.org/xen-devel/20260928023857.1030884-1-zhangzheng@iscas.ac.cn/ Zhang Zheng (2): xen/ns16550: identify XScale UARTs from device tree xen/ns16550: drain TX before reinitializing the UART xen/drivers/char/ns16550.c | 44 ++++++++++++++++++++++++++++++------- xen/include/xen/8250-uart.h | 2 ++ 2 files changed, 38 insertions(+), 8 deletions(-) base-commit: 7e020a4dd6ed30eb6c91a9abe2767034e2bb270a -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 04:58:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 04:58:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455116.1668661 (Exim 4.92) (envelope-from ) id 1xJ1vX-0002Gr-4W; Tue, 20 Oct 2026 04:58:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455116.1668661; Tue, 20 Oct 2026 04: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 1xJ1vX-0002Gk-1c; Tue, 20 Oct 2026 04:58:19 +0000 Received: by outflank-mailman (input) for mailman id 1455116; Tue, 20 Oct 2026 04:58:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ1vW-0002FZ-69 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 04:58:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ1vV-00BjRv-3R for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 06:58:17 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad6f47e-8faa-0a2a0a5109dd-0a2a450796f4-34 for ; Tue, 20 Oct 2026 06:58:17 +0200 Received: from [52.101.46.55] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad6f4e7-b4ea-0a2a45070019-34652e37ae92-3 for ; Tue, 20 Oct 2026 06:58:16 +0200 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by CH8PR03MB8226.namprd03.prod.outlook.com (2603:10b6:610:2c0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 04:58:12 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 04:58: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=hj+6wZzW6mh6Fn8iaYY5KceF1EUPKmR8dlcs6sz+iAvF4Bx+3naTknRAY1atK1WUsQE4wxCrK1PWwp2JzwUXYAZizCfBEZxoByYXJr/jQ5YBuumwLA2qYfjKSJA+DNF4flkgyYWt9oagfwRDe5hNbbcghWQ0dPTDidYlrogWCUOJz38d5T1MRWPSEIOBgjQK6bni1PV1P1OiEEVcPqiLnkozt10bBBuQ9qkslDCdmqk3X2EKD78O2bSUXDqSbpEctsMvv5dR9qwCeoAIBco2/nvQIMgMPfSuOz1MjzmwD/m9A4V3u+btLk58eB5j2U3pk4EnGAJ2jd2WOlQz9w4EKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BrKuCQBOMGitDkTfrBt9LwINhwZ8V4yF6Kn3RG5Tj1E=; b=tJTrnPi3YyNbMkrX6OiYROKZzfs6q1lICf381OxxmEiAGYkpQxM0BTLLvamD/NZhrTYZwJ2VntzKKvtiuGpIxdnrXVWCiwLmqAJsow6CuKsxhMSXAChzNUYGGuNnmsNoegeCZI5HdAL0bCf6aTpnfaeQuO/vZQSYSW8BXjFHl8yjMAveNe64x65zZNtpQJNaZ8AYCHHqLnAXUbMZJ7vs62+RoNGEWTfaYTpby6kEk9iBI6Zm0hsG3RIwwjSl6xtTmRbwp694g0TAFdsPwiWDsVt4KhdU/0L1m4XqLzAuwUAs/oaBtBJ9TcBXTyOcuI6to/zxQCOpl0P3JL1XN/fsYg== 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=BrKuCQBOMGitDkTfrBt9LwINhwZ8V4yF6Kn3RG5Tj1E=; b=lqcJtNyKUUndHdwjrBLZ3CMOArf4dKr4Pd0CQ8xVp7OvOIA44GnMwsTpDNg9HKvrWcFhCduoAEKs7mjluZZ1yoXE5rvPm7+6fiauBAqp7zWE/IwhSuwXsCRuv1EEZ62rdKPhFzSj7zpiZcgEkQyjHryjqdpzS9lS/BmzMNiko6I= Authentication-Results: mx.microsoft.com 1; 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.tsczsss, Chunjie Zhu , teddy.astie@vates.tech Subject: [PATCH v1] x86/nestedsvm: Require SpecCtrl Date: Tue, 20 Oct 2026 12:57:58 +0800 Message-Id: <20261020045758.321952-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JNAP275CA0047.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:4e::8) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|CH8PR03MB8226:EE_ X-MS-Office365-Filtering-Correlation-Id: 97288d11-fe13-436f-e056-08df2e66be0d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|18002099003|10067099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: J0LuiWj5Hd78sDHmPRJB1EkPRBMKt8ZResmHWbZy8vP0QUwXvAHpshPnlGpYT/eXfc0HD79lObuOboQoHwWUprC/TWayKiIu2zmjdwQr9LeW2wQfd/pK8iXzv1IWU/iLbZN+Yx55TylR3GrWwTNikBqeMraq2lrOHfGg9oZ0zxQR+lt0jSHRWq7ARoqfqmKe1AKa+428SRYw0CO00s7IGuQfL2/jK3MrrLOUMcmIZc86IpIxmj4MeC8foxfHjVYp9GWIfUusg1baLILzM2mDSHakMcBNdGuGg19dK3VUJpq8b04WsKPjMwmwKK2Zi/UR2e+d6bp9g6vDXebb0kaodJZxVZPTGLBFs0poWrGJ7g4g2/BmUvHTTePKhtIRXSk4tEtONM3IKGB+cpB8ThxmOK8ZQWO2yOD2koHkPXWwEMoQ6rezPN240+df9WfZSMeZg8+1Q6SfaF6cH4URpra/m/8FLJuXk2J+Jx9u4Kfuu3kwHyTM/2eFpjWbcn3d1PuCIBN6W0G3DPOGMwdOO5/Y5dhczpMlB5AGZeTeYVnHa1M0WXPeVpxQSpCm51eEcnUyMO3p3YX/K8C0Wxs/oWC66C1m8l+AWN5mNVcjEUl6G3n/WSMK9vOEZmLIdWKvKseGEGh8s9agGtH8HPiJeFOoHA9lqBmjc3A6PrSPhVLJon8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(6133799003)(18002099003)(10067099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tXdE0GnWAqyJFC77rmlRjHrbsJyDhkOLqhiYYWn3R8sbT2xLA6kqT7iVf9ER?= =?us-ascii?Q?11pDPHUXpjOSBxZq44CCzqmzlVBhC/xTXhOGkvjwRed6d7MleTC8SaQC1G2j?= =?us-ascii?Q?X78N39QrPIqO/XZ1dVZkdQvTlQVmdynaTr4Mp6ThZwhwB7XSJTg4QFdRvEUo?= =?us-ascii?Q?OAhvDmzJNsRKKy8tjB0R0YdQBbCpgQGctt1nok+1pMj0UC8XdLlLCTNDDmgl?= =?us-ascii?Q?3WiHKM0b1xkH3FgS5nfShfKcmWF8YidvPfHWrfoVuPgKxrdSK8FMgN33jDVl?= =?us-ascii?Q?2BosN6fJegco3bHYxkmitRVgxFP9m9zBQdE9OFBNaP5MmKPknUAIdc7asg/q?= =?us-ascii?Q?c/mO8zQckonWlSDzaDyULd0NEmhB/sXlE//UkwmGg/QnuA4fhvbvRGY2w5w0?= =?us-ascii?Q?RQlPFnqs6jzhLsgivME0zPv86HclqrRYNvk+cLu38CWHWw/BVfrVYpVW3sS4?= =?us-ascii?Q?a45UJvj/OcvdM682pJx6UkfYx+tEnfmeXwTmTJi5sJLsPdlk3rFVbNbxSCt2?= =?us-ascii?Q?rq5EWsqB8SDvFiSo9IpdFzOx0Cm0Qs/RY8S9qGF3+a7p6pbryOiU2kyO16iU?= =?us-ascii?Q?kn48mTVcaoCmss9H3edieg5gIZHyRUiBca+rrcUV03CktGQ//m+654HsEc+f?= =?us-ascii?Q?KGDC33q2Pnm7fpAvmqYCuDXZ//xM4BuMFKf4hzC9piXQf8SRTqigv9F+tRQZ?= =?us-ascii?Q?fhlnj287At5Tbm3Wv2Aa/mM7a8nrxYkSwgPOejG0D1g+X67IEtGEW/9Pcf9T?= =?us-ascii?Q?7AA1ZaWwUGuhqrQ6ey4MAI4Ac+ic1UGilDyQKfvFyY7SwnkQlJJvZSKdthPL?= =?us-ascii?Q?sIHcOjeGqBRBvgU8FuyJpECvvIXdynFJidpY/hHgsGIIX6D4F8xt+9mrej8S?= =?us-ascii?Q?CV8YeSfI1KAAEpSlUANw96bwwlB/M8VkBJjaF9vvgtTI5fZKUHwgwfbpc9E1?= =?us-ascii?Q?A0N5SvnzBmRfiGqhMBa9Ji5Zhe8b+LYDHYlq9StY5GBeGId91mMq5M8wpXwk?= =?us-ascii?Q?3yK6llyEXf1B3JRVNI2z3Zofqr7Wkf6i8O9RqRjyXuo3b5C7yLw+r+SqWdVm?= =?us-ascii?Q?ZtXZVfr1eSVjntuXx+809hTacFvP6tJXJKVegZbWLvtLvo8fMSpGYtk8JqML?= =?us-ascii?Q?LzyYoqtOnb6K31R8ueyJuLd3kBxDgV1tfSTpmMgJacAg3NSFnyP7JH0dX+su?= =?us-ascii?Q?g40zb37YuyE6ZFAPOBUVexpgQTj64RrnIbsHGbEW5l351Jvsih7BYkGl4J5k?= =?us-ascii?Q?SukVnaUY7q0snm5SaY0IaAx1iSiY05NyaKM5XYwzC89PYSDJ4cu7/YeFnP3+?= =?us-ascii?Q?Em0JajiAnavCbWZKOF2aqCSm/3UDXcW9zSpFDEdR6+EUkfFxHYxJNHQCiSDy?= =?us-ascii?Q?RPBFQNQTTsDBahqMSkBLLs9jNBW0kCuvB9iwQ+RkMobyLhgTOYKa3IMnBg7n?= =?us-ascii?Q?/qZXiEu6fuQRSw8qdqdcxXVcTqof8v9RDjGgZNxYf7cfKZZjtmbpMY2/2rxV?= =?us-ascii?Q?ok0nO5JX6ROMTQyFa3OcI14BJ9qNU+dq6ru8WzzKoyskZxKrfa1aL8S8nbwY?= =?us-ascii?Q?5ZJI0PrD9dxtn74lntuQMDw1oz7yNesnSb1r6vMwCqNhoG0R3vHKy26/Y/nQ?= =?us-ascii?Q?eveW8a3HsVLW+8EMSbzZy/DiFZNs2yx3fWY/dBNecaNFl8L4uZPH63C/mVki?= =?us-ascii?Q?y1sFImWe3I4ahOizu8OV9wSa2NOIQAFR0DZex5HwL7sAksA/PRPjj4PFh7rG?= =?us-ascii?Q?HCfhEEtXNg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97288d11-fe13-436f-e056-08df2e66be0d X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 04:58:12.5526 (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: g3KVQA4MsVZ4Hp7a+7J3agFlX/9V+7zVW1tFn2Sfvhq2CnEMzRgzNyiy2NOeJ6aRKQezR6l+W7TBAZoQH0Ju7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR03MB8226 X-purgate-ID: tlsNG-ef75cf/1792472297-A6EDEAE4-0F6ABC08/0/0 X-purgate-type: clean X-purgate-size: 5571 From: Chunjie Zhu Previously L0 did not expose this bit, forcing L1 to intercept and emulate MSR_SPEC_CTRL accesses from L2 in software, which is functionally correct but suboptimal. Per APM vol.2 rev 3.44 "SPEC_CTRL Virtualization", hardware supports combining host and guest SPEC_CTRL values via VMCB.spec_ctrl with a logical OR while a guest runs, and saves the (possibly guest-modified) value back into VMCB.spec_ctrl on #VMEXIT. Require the SVM SpecCtrl feature before running any nested virt guests. Update docs/designs/nested-svm-cpu-features.md with the rationale for requiring and exposing bit 20 (SpecCtrl). Signed-off-by: Chunjie Zhu --- docs/designs/nested-svm-cpu-features.md | 13 +++++++++++++ xen/arch/x86/cpu-policy.c | 3 ++- xen/arch/x86/hvm/svm/nestedsvm.c | 26 ++++++++++++++++++++++++- 3 files changed, 40 insertions(+), 2 deletions(-) diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md index ce168e68e1b3..6999fcf1bb72 100644 --- a/docs/designs/nested-svm-cpu-features.md +++ b/docs/designs/nested-svm-cpu-features.md @@ -109,3 +109,16 @@ 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. + +- 20 `SpecCtrl` *MSR_SPEC_CTRL virtualisation*: Require for L0, provide to L1 + + L0 already relies on this feature to virtualize MSR_SPEC_CTRL for the + L1 hypervisor itself (see `X86_FEATURE_SC_MSR_HVM`). Requiring it + as a baseline for nested virt (first available on Zen2) means L1 can + rely on the same hardware virtualisation for its own L2 guests, + instead of having L0 unconditionally intercept and trap/emulate + MSR_SPEC_CTRL accesses coming from L2. Providing it to L1 is + basically free once it's required of L0, and it removes a + significant amount of "CPU without the feature" fallback code that + would otherwise need to be implemented and maintained for nested + virt. diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index 42dccdce5290..4d6de5dd5d0a 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -832,7 +832,8 @@ static void __init calculate_hvm_max_policy(void) (1u << SVM_FEATURE_LBRV) | (1u << SVM_FEATURE_NRIPS) | (1u << SVM_FEATURE_PAUSEFILTER) | - (1u << SVM_FEATURE_DECODEASSISTS)); + (1u << SVM_FEATURE_DECODEASSISTS) | + (1u << SVM_FEATURE_SPEC_CTRL)); /* Enable features which are always emulated. */ p->extd.raw[0xa].d |= (1u << SVM_FEATURE_VMCBCLEAN); } diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index dc2b6a42534a..46fff4fab5d3 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -481,6 +481,16 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) /* TSC offset */ n2vmcb->_tsc_offset = n1vmcb->_tsc_offset + ns_vmcb->_tsc_offset; + /* + * SPEC_CTRL: When in host mode, the host SPEC_CTRL value is in effect + * and writes update the host SPEC_CTRL register. On a VMRUN, the + * processor loads the guest SPEC_CTRL register value from the VMCB or + * VMSA. For most guests, processor behavior is controlled by the logical + * OR of the two registers. (APM vol.2 rev 3.44 + * "SPEC_CTRL Virtualization"). + */ + n2vmcb->spec_ctrl = n1vmcb->spec_ctrl | ns_vmcb->spec_ctrl; + /* Nested IO permission bitmaps */ rc = nsvm_vmrun_permissionmap(v, clean.iopm); if ( rc ) @@ -1022,6 +1032,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct nestedsvm *svm = &vcpu_nestedsvm(v); struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; + struct vmcb_struct *n1vmcb = nv->nv_n1vmcx; struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; svm_vmsave_pa(nv->nv_n1vmcx_pa); @@ -1035,6 +1046,18 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* Pausefilter - keep it as is */ + /* + * SPEC_CTRL: on real hardware, only the guest's own SPEC_CTRL bits are + * ever saved back to the VMCB on #VMEXIT (APM vol.2 rev 3.44 "SPEC_CTRL + * Virtualization"); the OR with the host's bits is a transient + * execution-time effect, never written back into the guest register. + * Here, n2vmcb->spec_ctrl was seeded with n1vmcb's bits OR'd in at VMRUN + * time (see nsvm_vmcb_prepare4vmrun()), and will still contain them if L2 + * never wrote the MSR itself. Mask those back out so L1's own SPEC_CTRL + * doesn't leak into, and persist in, L2's saved state. + */ + ns_vmcb->spec_ctrl = n2vmcb->spec_ctrl & ~n1vmcb->spec_ctrl; + /* Nested IO permission bitmap */ /* Just keep the iopm_base_pa and msrpm_base_pa values. * The guest must not see the virtualized values. @@ -1678,5 +1701,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_spec_ctrl; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 08:33:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:33:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455140.1668671 (Exim 4.92) (envelope-from ) id 1xJ5HC-0003fQ-8b; Tue, 20 Oct 2026 08:32:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455140.1668671; Tue, 20 Oct 2026 08:32: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 1xJ5HC-0003fI-3v; Tue, 20 Oct 2026 08:32:54 +0000 Received: by outflank-mailman (input) for mailman id 1455140; Tue, 20 Oct 2026 08:32:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5HA-0003fC-SK for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:32:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5H8-003rM6-M8 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:32:50 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad72729-8faa-0a2a0a5109dd-0a2a450cc3a2-34 for ; Tue, 20 Oct 2026 10:32:50 +0200 Received: from [40.93.195.33] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7272f-f479-0a2a450c0019-285dc3217fe8-3 for ; Tue, 20 Oct 2026 10:32:50 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DSVPR03MB989314.namprd03.prod.outlook.com (2603:10b6:8:3a7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:31: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%4]) with mapi id 15.21.0546.012; Tue, 20 Oct 2026 08:31: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=Vn0c7uAicumKSzuWarzvJYwG1AoG9VkoTJ6V0BPkCnvZKp3QT6LPW38PG4DBrihKDnutP8GrYHpTymUKWOWmoE0gz2Rx7RvO4QuPjdgaLBnq81ptM0kXJ9LJpz3S2xV7ZtVFdKwyTWi1u7mBO2L3DGmyziOjjfowAt2WEBYRiPEs4PcHo05rcSsdVwcIvU2x6SKVGvLgYVyoMIRvEu7ohaVsTYJMVCoWYyySTNL3043JywcpkQbNoO12qQnjtmMYp8xGDoyR9fpTqmcEWJVLGQizH7Lwwr3wUdco+k1dG0EMeYixEJ6xLAOA8i7tFpTB79RKC2hR6U/o8lQJtpGkvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aUBo1AHET9eUpwSf4h3YPkc6MwIuaQ2Ke9X8zFvEwVY=; b=u/SOdSBHTfNxkzUYeTQLES1/3gdse5M6IXy1AfbnaSRP1BmvNc6JVXmO0T7eVeQcn7o1PLJDS/WW1WSFS37vfNRta2bCYycT6vxPhUkEs4OchWFJATRp0Kb4PmJbPnjiJ05OjpzYeH6NdKi6r5vC2y4OFzzWXkHhVZx6yPBHU54rjmI2cuCkP0B4iOIY3q3QtFUmbMU8duJaEPMfQelFa8nRfV1aXMs8rOtP1rfkv/KfsFs3tgusBHuOu9H9YzFj9ovn6YR7y6mk4lgLWf9RqMqgGcdI0+rLdaeashpipFQ8r3TKMtZabf83rPNWcg+1GY5Fho0NyUZCGP8PePw4+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=aUBo1AHET9eUpwSf4h3YPkc6MwIuaQ2Ke9X8zFvEwVY=; b=om3HmZhchu4WQwN6KRbIXRh/tT9geE37WH39Cj4YJkUpsFkJJbSlWd/pjmzf4LjzRSAd4b0UacTcmsPfQgSImOtq39ojA4WzTW58GISaFwhlj3QSdd+ny175MScwj9lumGe4VO2dxtusX56GnkTbfUyubxTAOxEaXt5dQTeBOao= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5916f3aa-a008-4233-a562-d091eeb9dc7c@citrix.com> Date: Tue, 20 Oct 2026 09:31:17 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261019155959.883789-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: LO2P265CA0514.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::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_|DSVPR03MB989314:EE_ X-MS-Office365-Filtering-Correlation-Id: 923e433a-0eed-4083-3234-08df2e8484ac X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|10067099003|56012099006|3023799007|22082099003|18002099003|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: V+TwDBu/xGE2FN9qsau2BzlyLLnEgOaLqAtICtuEUOTUqqgqPL2lBWv2opVfCy9LNMJPvxqtTlprxv6rYoehlUph/C8xKkVtNrU6dNrYhuupIUTt/+jxwTCFlblgjMyueI6D/c77OaohTRBvqG6/TheRabVcWb8Dn/NrdLJwQdyjE2zkKZ3LUq+doo+ViSs1fGuAFznSjZc98ixc9tAEGW3xpQBLEXlvyaDHAexSIyesjrGo4u6cwLLmCLz0kfjUWr5WHGoS/FiIWlId+k5i2xrf31OJQX94rNzaGX7tsN4QgGvCTSPtJejlHlXAP8hNlhQvvqY9Rj8yPy7skhBW8ADwYciP+9GBWplurYYGE2QoR55bj7uEn/9QdM2F3dIt/jWwf6ARGlONERXv20QBvTwPbH1IqBvRY63Y1fCyKzsuXKNFBINKk27OWOtldTjrcQS30cdchBgvj0SYYpMyjcaXyQLmzfzinGuzpeXkeHgcg52LHeBIcnkEuZwQERn3nB8RwrCpoCgYBHc+5m7LjqrEGKv/vJGZPL+zDdkkHihuOF672nGz41Tdqb2Lu030SvnyGUwKU/21bXmufI5Rj4fqAgy2oGHKPITJB3y8tvgpvt2MHUHKPRJIWM7fQqa7dceGSUz133nu35riAJwLgrmg8aFbLdh5k4+AU7uIaZg= 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)(56012099006)(3023799007)(22082099003)(18002099003)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RmE2ckdTeWJ2b1R5Nk5JR2Y1WVZpTytNTUdSS1FMYmlvakVxYkJSdjVnY0M2?= =?utf-8?B?QkdCMUJaV2pzZTU2UjVkUmhlV0FCZGZYREx5TXdKd25OMEswanQxc3RnTmRG?= =?utf-8?B?MEhDRXp0SUxFeWxKZ3NCVENham9jclNtS0NxbHhNaUZzbHBTZ2tzdmd6YU1N?= =?utf-8?B?ZVVvZ0hGOXI4RTRsQitFdVBEZ1NsTDRidnV1WVFtTFpQNW1CK0Z5WUU0TGZ6?= =?utf-8?B?M2RUKzFIeWpSK2laR1FGVkhhNDRuOVVYYkNBcDQ2N0pETHgzWjlBRU5CbHlZ?= =?utf-8?B?b0IzaU1Vb0xDMkRNK1hOMnU1dzBDNEMycVdvemU0SnY1N2xVMFFxVDBoWEdj?= =?utf-8?B?amxYdDhrS09idnlKUTNjRzFnNGZYd01JSEtpVGgvSnZDd1hrcWZoZzBWSXZo?= =?utf-8?B?N3dmMk1sdHlxMTNrd0RldlBMVHp5bzFtcC9hemIrODBRYnVndkZ3ZFZ3TC9z?= =?utf-8?B?SEJwWndCd3FWSytBRkhYa3NQYTU5WVIzWkI3RHlsdE9rVGVtWEFRY0x4R0pR?= =?utf-8?B?UWZEdldWWlNEVzcxMituTGdTeFZxWmREM3ZSR3lFSFl1bnl5em5RcVNsTFo1?= =?utf-8?B?Z1ZjdHJBWTdZUGxUcWtXMTJ0VVFLUUdwenZPWnlQejdtYVIvWDJTNWF6N09k?= =?utf-8?B?NVJXY0JCTGNPTXE0dnRMU3B5bk1HRjNPYU5ORTluNzd4am0xTVVMWXNxMnJl?= =?utf-8?B?QXZvWDQ5bUI0MTQwTnlSWjhuZXpNM2s3YjMwM1JWOVNTb2t0bjBEZzNxQ0Zs?= =?utf-8?B?Z0l5SG1oVmswakZ2TUY2OTNSNTNNd2tnYkUvcnJ1V1ZVeVZ5SDVPOHZEWlRv?= =?utf-8?B?SlRUNzJrQlNXT01vY2RkNERobTl6TUVKSFk1aFJSQ2laWWl2QzRDaEFvNmtP?= =?utf-8?B?c2hZa0xGWGFVa2k2anhaZ2VwRm1MN3pXSWJoTmNrWXc2M0p4SXZrQk83Rkx0?= =?utf-8?B?ZXRybGE1VkJrTW1kalJPVWlIdHhldk5FYjUrbVlhallEYVRadmJsZFcrVFU0?= =?utf-8?B?N1I0Sk9UR0dRbWwxQTVUK3JnTE9UcDlFOVQ5VjZ4N09jSHRzM1pUMEtRWkVp?= =?utf-8?B?MXh4YmphL0FlOHM5eWpGOXM4encraDhwYk41b2pDOGYvZ1IzY2ZUMUNxUk1C?= =?utf-8?B?VTZ5dnNLd2JrN3Eya2VxWnV3a0JUMk1zTkNucUlQenJtcmFBUWEvTlVSMHhI?= =?utf-8?B?TWpycE5qeWtsMzlVRW5Sa1ZxWFp6dTlwOUtnRWxsclhkdWEzOUxPTVo1dUtE?= =?utf-8?B?TDV5d0xvQ0VMRER4cGVaOTRxeDdYbU1mMU94eXYrMVdaSGMxcmZQSFhOMlJW?= =?utf-8?B?QjFNcHBLbWQ2d3IrRXlmSDV4eEpqZFJCYmVZZ0l0bDNXbjBUYS9zOEM0cGNo?= =?utf-8?B?d0pvZFJpSVVkU0V2NG4zQ1hyd0NNSkE2cENMRE1kdiszWEZrajhmTUNQLzk5?= =?utf-8?B?VFFPM3orN0pqMklobVA5NWpYRlMyTStsNXF0aVEyMjcyR1VHeHd2cGxXejI1?= =?utf-8?B?SUtuMUdLNVNSYXQ1bTRxR1VUdEw5NmFzaUgvTXMzSnlBdFUwUGt0SDVqSHV4?= =?utf-8?B?dVI0cmtjcTY2K2NPbjZVRmxETEN6aEVLb1dlalFDSEE2d0NnRnpLdlRqY0tz?= =?utf-8?B?OFJNS0EwZFRDSElYaEN4UStiT2JQM01pL0hYZml6a05oelBPTVNpVDd0eFJU?= =?utf-8?B?cXZYdHJwMVVUekJBSTBBZU5mL3ZFd1NDczVHZjNKQnhTanNOdU9SZ3NOc2Qz?= =?utf-8?B?L0cyYmhpWnpxMFR5QWFqRmVuRkVZYU5RcWxKWVRRbmU3dUwzdVVKelp5WE1N?= =?utf-8?B?YmczQ0ZwdEFPWlR5OE42UU02ZlZuQzhtdEJtaXBnWEhDeWYrdjZRUTh4WWRy?= =?utf-8?B?Vk95MnhiSW43TXptc1JSUFFWUkMxK01iQ2RMY1YrNVVISWQ0cXU4VGwvRjU1?= =?utf-8?B?TDg0QjFSaDl6NEsrdWlNK0YxYkpMZUtCdVY2UE5xV1NVcEd0U0doSkJJWEQ0?= =?utf-8?B?N3h0a2k0eDMwYTNoeHFVclpTMlNkUEFwdGozSUNtUFdZSFZBWFRNME9OdTZv?= =?utf-8?B?WE80SlBWZnkydkpBNmdsc0JaY0pFRC9ZNGE5SDlQdmVvOWNLYmN4MmNJRXhD?= =?utf-8?B?QmdhZ2dQbzRNVmpxcHh4aFBtd1RJZlA5QTJha1IrU1JGNmE1NlFOQmgvSVh6?= =?utf-8?B?UU1RZHBVUW5hYU9GWlVJRFZnZWJkM1EyeThJRlFPYmNjUEVHV0k1ZDRMQUZn?= =?utf-8?B?TmMxRm5hdnpBbnZIck9TcTR4dDZBMm9kczE3aFg2NFdpMHRyZDR4K2N3U0tE?= =?utf-8?B?b0VhT2VkcHRkNytWM21OczRqSUtXR3cwZDBSRVNHUUlGTkRhZ2FYdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 923e433a-0eed-4083-3234-08df2e8484ac X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 08:31:20.8261 (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: 7PtxWnKnG9UXuqHHX5/KMYHfiDXJxJbeKee5J1gBRGxojnHMfwzlGrjy/yl83YJvJdFlBd879uCik0YSOwBYvbsVwMe0vF1c2VmktzgY5PU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR03MB989314 X-purgate-ID: tlsNG-d25034/1792485170-51B35A5B-028611E8/0/0 X-purgate-type: clean X-purgate-size: 857 On 19/10/2026 7:58 pm, Roger Pau Monné wrote: > On Mon, Oct 19, 2026 at 04:59:59PM +0100, Andrew Cooper wrote: >> Between writing MSR_S_CET.SHSTK_EN and establishing SSP using RSTORSSP or >> SETSSBSY, there must not be any CALL or RET instructions. >> >> Building Xen with -fno-early-inlining causes wrmsr() to become out-of-line, >> and thus suffers #DF during boot. >> >> Make the MSR and shstk helpers always_inline. They ought to have been this >> way all along. >> >> Reported-by: Roger Pau Monné >> Signed-off-by: Andrew Cooper > Sorry seems like I'm a bit slow today. Also worth adding: > > Fixes: b60ab42db2f0 ("x86/shstk: Activate Supervisor Shadow Stacks"). If we're doing that, we need Fixes: 3037d8b7eb3e ("x86/boot: Use RSTORSSP to establish SSP") too. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Oct 20 08:43:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455148.1668682 (Exim 4.92) (envelope-from ) id 1xJ5RO-0005Xn-5I; Tue, 20 Oct 2026 08:43:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455148.1668682; Tue, 20 Oct 2026 08: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 1xJ5RO-0005Xg-2N; Tue, 20 Oct 2026 08:43:26 +0000 Received: by outflank-mailman (input) for mailman id 1455148; Tue, 20 Oct 2026 08:43:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJ5RM-0005XI-Vc for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:43:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5RM-00EVzr-6C for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:43:24 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad729ac-e002-0a2a0a5209dd-0a2a4503caa8-0 for ; Tue, 20 Oct 2026 10:43:24 +0200 Received: from [52.101.84.117] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad729ab-fae8-0a2a45030019-3465547526e8-3 for ; Tue, 20 Oct 2026 10:43:23 +0200 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by AS8PR03MB8395.eurprd03.prod.outlook.com (2603:10a6:20b:527::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:43:20 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 08:43: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=R972WvP8cyYQGBIhZSd8H8MB+62ld3Ozw7stI5gg8V5InoiAOu3nk+2ec2/oxUT+Ram3hnj+gbuLuSeztIJvoFZPgmNK62VNhcmd3+gRYzgFQ+eml14Zg+0OPA6hHDf/n5V+DBKELPlBpxBqZEeOu9EPREfOe5hf1fTTBENsO9qs0d/OHR7IwiP0Tww16VGtjVVryqjdVWDFzvV8Ify+YX1adve3U+Av7IOsZhARZMW19Y5T64cDljPW1OtsvD2c6A4+xbNtI5RNhPL1XIBuW1nvGTyEa/UHKyxLV9wkTLdO6GY6K682bDNSJbi6GeRGgwknWb2+TpOD4u9TSAwsew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UBIBUcGJqztzbw3PVDcTC84VFIZplOMWbWkzXViCyOk=; b=K1g39itNc3InF1QnphDqyVUXuxXPDwH8aykGomcCg0MXmOjsPd0x19/P5HgDWxJXVOfMdvWkDKmeDFmL2A5yzJbrNUl4D7IMZUTj+Z5LklI/C484vVfAfPmAyDhPjQbFYtl7m39hH8zxKkH+IOE+vaVY90weG68JWz5Jjp1MnEAptBkg88DCNZ53J4Rl/QKVeQECISOCJCOEhTlPiJ5IIkyYS3xm0U/7TGHgBmEDa7mNmWeylkj44rly6KVYkSo5ogOMBbszNsSj+t8pDcEVCQy51b5NqeNY1VOZz5S/8l9yBTJMofnnuElM842rXec3PNBkZxBFsnA5dLzJu/q5Vg== 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=UBIBUcGJqztzbw3PVDcTC84VFIZplOMWbWkzXViCyOk=; b=cX/1tSLJb1HjSaeIh0cz7lpzVi4v9hXIyyeqBHPvn4I1Xcq8jdj3N8YHog9RE1fHZREwR7ZYohXGGSyOJvWnnVK4f9b11gUfQ21L9ZT8C0y9D5tg/XOZgZY1g90Z4PDj0btbbHZh14jfwvyy+NhCLzBAYyXJqF3w1YZq6ZXgBSrl6lOkVeCAIPat4BcK1W0ZkfOEx1ruX7rscBBaKM/72ulf1tcoOzgLFTmElfLIjJFuMISzNe0/dETrH0LORkltbuniXJdgIu1K8OA2Anw2PE5/2M/oEgr49+HUA/puLJGvu83fWd0+N5waacZPHpriZ9byE4sAHMDHhUfGLKzeTA== 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 v14 1/6] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Topic: [PATCH v14 1/6] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Index: AQHdYG8O7hRiIyMpTEi9ibXqhEGBjw== Date: Tue, 20 Oct 2026 08:43: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: 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: GVXPR03MB11113:EE_|AS8PR03MB8395:EE_ x-ms-office365-filtering-correlation-id: 322a3072-517a-4804-cc2a-08df2e8631a9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|7416014|6133799003|18002099003|22082099003|3023799007|38070700021|11063799006|10067099003|261009223027099003|56012099006; x-microsoft-antispam-message-info: QMv3Ak4XCg+f1wduEAbmMmIK5GpO5pyjVI8gR3Wj8Zw4fY6DhfbRZOdTm5Wggb35vJygTEK/tZAvEas8dBBvFbZD3ZctUa7buyEOCBmgXq6ZKy0ackA6CK9+6jPsa7/yVR1jJkBwN6Rd5xPIH7E7x8W9QhLNABRriZW6XgFbWTRJ+zCBwx/7rqBLtPLYf3LI37zqrty9HLgxg2H4MAKamfo6/YwrqFTaPy0JM/22TLIRqbQoSwpTGRtxOzaMR6KdkdKkrtLsJxcSqDCMTBOBBNmagT/kc5bcpTwW87h1jzQoIje8pSNKwTMZoS6+q2KOkFF2NhJHLHQujf4QsrG07niVsh1R7MT/J/zfR6TRCDUBBkOrDZTYCFLM5d/98+zzToD2SmM0CkFUeGzyg2r2hWLfm0ji1QVAFLkjCB8bHJbdFWnMEo6b3XSWouEDc3Wje6i39RuColW+bVBv5OYj8Iwhva4XC+XVDtnHqtk8R2tooLhqJ0LKjfDz49w7yirN23+2S0ca7SslyzJOjn2EIz38LF7+ktOAgskuda3vNP7KQIqnLfLQHcb9BL1D6Enf7sQr8mGwoNgcIc9NM4RgseMZbhEQAkIsd9rkbk3UzX9BATQ4cDjL4mbZk4I/WDzkddoKZke/Qn9m1PE95be1mSvULr2zaAB1ZhTbuAK+Q7BeXxdg8jhoUJDcjSTD4wRc6i5+8C8EbxNvvp6hQUHMAnWRr5O9sgmiFKck6PBtQuA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(7416014)(6133799003)(18002099003)(22082099003)(3023799007)(38070700021)(11063799006)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NkpIVms0YTdjZ1JuWmdaU1VSY1BkSEt1Q0VLNWxkVU9ldXduMzEzZExlZTBh?= =?utf-8?B?MTE3c2pibWlTWktJUjJnS2tFUHl4K3ZRaEhVcEJsdnlqUkNRNmVuN1ZGdjNR?= =?utf-8?B?T3FUR0huUk5jbWVzdHM4VWRvajg3TzJjZDRMS2x0MHpWRHUwWnU2SnovZjl1?= =?utf-8?B?RXpaRW1Ddmt0eUJnZGZxdisrbXNSL0hTdGZzQmJsSEFaY2hMNjRackY2UDlG?= =?utf-8?B?TGJscllXeStySW9UN2x5UUVEZXRaT1RzQ2o3TEJsdVZELy8rYSswaFBIMEht?= =?utf-8?B?RkExQ3lZN29hQTVKT1grT0M3Q1lPRzdEOFgzWldSc2JLNDlnVmU3NlAzOGRp?= =?utf-8?B?aXNTWm92dDQ1RWRpRUhpVXQ5MXB2WUM2UUI3UzF5M08zOG1NUG80WWZ2RldZ?= =?utf-8?B?TWRrS3RVR3pqdytIVXVXdmNoK1lnMW5ZdExpaVRHL0lZSi9GNXRQYWJuY1dr?= =?utf-8?B?dEhLeU9SV2hieXNoditVUG02UEdsdnFNVkt2UDE4NHFtMDRFd1VvRGJ0NzRE?= =?utf-8?B?bE1qaGJtZExuVmVwZk1zMFhPd0FlVzc4RVpuZjV1c1ZDQU9iaU5MSEV1YnUw?= =?utf-8?B?eFdoZ0xYdVRBNU9ucVpoaThVb1k5MnJPaXNZQmc0aFAxTXE1am1tTXUrWHNh?= =?utf-8?B?enZqU2VNWUVydkEyRGxaaVdFTFVJVFVKZUJsMlU0eUZDdVJBQVlmZ0I0R3Nv?= =?utf-8?B?b2JPUDhpQmNKeGJQbmM5OTc0YU9PMCtXanlvQ2hEMDRDcWxqeWhhSjZKMjhw?= =?utf-8?B?dWJwWGNxM1ZYVi9JSDlPbDVRb3VvdlFST3FCYVE1QTBLOUxMQ0dVd1VZOXpU?= =?utf-8?B?YUt6N1VkblpkQVJ2aElZaHpYejErOExMTmQraDJreFZjKzBtMm9ITTZqMHBN?= =?utf-8?B?d3BYQ2Z4bTk5V2NCSGtZSEhoaThMMFprU0l0VzlvYncxVEx6ZE5oaStKRlN1?= =?utf-8?B?N244RG41Z3lGTWNxMVlWUGFIMnFwaGVvdUtEaTZaZVZIRWgvYjhMNVpuTEVr?= =?utf-8?B?QVpRSy9FWGhPaEdDV2N1NTNxUnZ2NVVXeHB1bnhRMHlEY2h2ZE1adnhYNDlK?= =?utf-8?B?UGVTdXBvWlhtSEZvZU5MNzlGQXlDMmlhdE5YK0lxRjdtb09ZOXRHUE8yYzQ5?= =?utf-8?B?ZnYyTmRTSE80QXB5RlUxWVpRUmZFSHA1T1RKOTh0Snh6UUVGSXhIZldsbWNz?= =?utf-8?B?THZ0SHJEVlR6ajVoQkN3NVpQMHZVbW1Hb1FVb1JOdW9RZ2VjS0pBN1lpZnVD?= =?utf-8?B?QjBrOTBTdzRlbmd0M0YzZkhNRDVEcUNscDV4Q3gyU3hTSkkwZlJ5OG9SNm9j?= =?utf-8?B?d0hycFRuZkQreWptZlM3dU5BMTRvWGIxWHNKMEtNVUYvZWJsVmVsQ3VYSUpS?= =?utf-8?B?U252Z3JVT1Q2ZGh2VDhtTUlyaWNhamZYOWV1SXR6U2w1TW4vcmpVbFU2dWp6?= =?utf-8?B?NXd3eDQyODB4UnRHeG1HSndLblV3ZHhJbTBNak4zM1RLK3Vhdm1mdlB0NXRq?= =?utf-8?B?eVNIajBqb2RmeEdIbW05Wkdka2VsSHFrRk1NVjhaYmxLWWpXUzdRTUtsQ1FT?= =?utf-8?B?alh1MHVRNG9Ba2NjVFljd3IzVnMzeEFET0FiYS83YmZYanRqb0hta1VOeFJK?= =?utf-8?B?ZzNnaU9kajhLa05MOHlxc3dheC9GM3NaUXRqOFh6Q3NZaVBZd0hWZlhDTlBQ?= =?utf-8?B?S1BwN3Bpd0JMZkROVFVMVk1SUnhWeUt1bkZPMGxIZTBkd3ZQOG8vL0dLZEpN?= =?utf-8?B?TXRJb2tWY2E4K0syUzZHVUQrOGNMTEFJcTVXZDlpd0ZhaGlHbHVXWjdkYjdB?= =?utf-8?B?T1ZlZWtWbTBnQS8ySzB4QWdaWWdrOFhTTldlbnhDM0xJTHF3R05hbUw0NFhi?= =?utf-8?B?T2p6NnFudFdmd3Q1eVZSTHVqYmpzT3VuRUJzNlZDTnpZV2JocE1tN2l3ZGVj?= =?utf-8?B?aWtzazhDelJ5aGkxZTFzYTlFNkVVa0p2aVpsUVdrMTZmK2RMeWpzT0lvekdx?= =?utf-8?B?bXFoSmU4WmUweFkzb0lSVnZLR3UydE01Mm9jVWZxYTFvYkhHSFRCMFRWNzZH?= =?utf-8?B?VDRkNEhndFJjaXdUd1hydUJsRkVlOWQzdmtUdEhaVGlUNlFZa1htdDBjQVpR?= =?utf-8?B?TytpL2dnYnpCek5BUXR3TWdsY0V6ODZkVmdWRDAzZzBwQ0ZsaVlQNGZlZzFN?= =?utf-8?B?SlRZNG5LV3J2a2ZKSlpIaDQ0b1MvK0lsN05vNGdySlJaQWJVcUhVN3JWdWpE?= =?utf-8?B?N1RvVFBLdG91am16WjRVUUJnaGtjcGpEZzU0M2t0QzF4TzVoTVZDVEtnT0FU?= =?utf-8?B?VFV6M3pPVFg3MnV1ZjMyTG0vam1kU0ladnRnWWpHQ0lleVJaUU9WcXIrdytW?= =?utf-8?Q?Fs1jCFAjs0EWN7Ms=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <83FFC0D495A8E44F8EAC035A9821145F@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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 322a3072-517a-4804-cc2a-08df2e8631a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 08:43:19.6514 (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: E96m3gKWYUUpQmV8fweBZuHPDDHAj1A1p4NAvQcaLxpNXmLcthbrjSYDD0Wm3kxGDKSeZx1WRil5gpabGsZiBRdga/gF3yplKsRN48UlIfA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8395 X-purgate-ID: tlsNG-33051d/1792485804-768FA4E9-22ACC756/10/78276251493 X-purgate-type: spam 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 ZjczZWQwNjA5Mi4uMzcxZWNhMDE5YyAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2Fy ZS9zY2kuYw0KKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQpAQCAtMTI2LDYgKzEy Niw0MiBAQCBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0 IGR0X2RldmljZV9ub2RlICpkZXYpDQogICAgIHJldHVybiAwOw0KIH0NCiANCitpbnQgc2NpX2Rv X2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0KKyAg ICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2Rv bWN0bCkNCit7DQorICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2Ow0KKyAgICBpbnQgcmV0 ID0gMDsNCisNCisgICAgc3dpdGNoICggZG9tY3RsLT5jbWQgKQ0KKyAgICB7DQorICAgIGNhc2Ug WEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KKyAgICAgICAgcmV0ID0gLUVOWElPOw0KKyAgICAg ICAgaWYgKCBkb21jdGwtPnUuYXNzaWduX2RldmljZS5kZXYgIT0gWEVOX0RPTUNUTF9ERVZfRFQg KQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgaWYgKCAhY3VyX21lZGlhdG9yICkN CisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGlmICggIWN1cl9tZWRpYXRvci0+YXNz aWduX2R0X2RldmljZSApDQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICByZXQgPSBk dF9maW5kX25vZGVfYnlfZ3BhdGgoZG9tY3RsLT51LmFzc2lnbl9kZXZpY2UudS5kdC5wYXRoLA0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbWN0bC0+dS5hc3NpZ25fZGV2 aWNlLnUuZHQuc2l6ZSwgJmRldik7DQorICAgICAgICBpZiAoIHJldCApDQorICAgICAgICAgICAg cmV0dXJuIHJldDsNCisNCisgICAgICAgIHJldCA9IHNjaV9hc3NpZ25fZHRfZGV2aWNlKGQsIGRl dik7DQorDQorICAgICAgICBicmVhazsNCisNCisgICAgZGVmYXVsdDoNCisgICAgICAgIC8qIGRv IG5vdCBmYWlsIGhlcmUgYXMgY2FsbCBpcyBjaGFpbmVkIHdpdGggaW9tbXUgaGFuZGxpbmcgKi8N CisgICAgICAgIGJyZWFrOw0KKyAgICB9DQorDQorICAgIHJldHVybiByZXQ7DQorfQ0KKw0KIHN0 YXRpYyBpbnQgX19pbml0IHNjaV9pbml0KHZvaWQpDQogew0KICAgICBzdHJ1Y3QgZHRfZGV2aWNl X25vZGUgKm5wOw0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2Fy ZS9zY2kuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KaW5kZXgg MWQ1NjZiZThlMi4uNmQ4Mjg2YjVjYiAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRl L2FzbS9maXJtd2FyZS9zY2kuaA0KKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13 YXJlL3NjaS5oDQpAQCAtMTQ2LDYgKzE0NiwxNCBAQCBpbnQgc2NpX2R0X2ZpbmFsaXplKHN0cnVj dCBkb21haW4gKmQsIHZvaWQgKmZkdCk7DQogICogY29udHJvbCIgZnVuY3Rpb25hbGl0eS4NCiAg Ki8NCiBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0 X2RldmljZV9ub2RlICpkZXYpOw0KKw0KKy8qDQorICogU0NJIGRvbWN0bCBoYW5kbGVyDQorICoN CisgKiBPbmx5IFhFTl9ET01DVExfYXNzaWduX2RldmljZSBpcyBoYW5kbGVkIGZvciBub3cuDQor ICovDQoraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0 IGRvbWFpbiAqZCwNCisgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhl bl9kb21jdGxfdCkgdV9kb21jdGwpOw0KICNlbHNlDQogDQogI2luY2x1ZGUgPHB1YmxpYy9hcmNo LWFybS5oPg0KZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZG9tY3RsLmMgYi94ZW4vY29tbW9uL2Rv bWN0bC5jDQppbmRleCA4MzQwNWE3NjZhLi4xZDViOTI2MzFjIDEwMDY0NA0KLS0tIGEveGVuL2Nv bW1vbi9kb21jdGwuYw0KKysrIGIveGVuL2NvbW1vbi9kb21jdGwuYw0KQEAgLTI5LDYgKzI5LDkg QEANCiAjaW5jbHVkZSA8eGVuL3h2bWFsbG9jLmg+DQogDQogI2luY2x1ZGUgPGFzbS9jdXJyZW50 Lmg+DQorI2lmZGVmIENPTkZJR19BUk0NCisjaW5jbHVkZSA8YXNtL2Zpcm13YXJlL3NjaS5oPg0K KyNlbmRpZg0KICNpbmNsdWRlIDxhc20vaXJxLmg+DQogI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQog I2luY2x1ZGUgPGFzbS9wMm0uaD4NCkBAIC05MjUsNiArOTI4LDE4IEBAIGxvbmcgZG9fZG9tY3Rs 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 Oct 20 08:43:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455150.1668701 (Exim 4.92) (envelope-from ) id 1xJ5RP-0005ws-Qo; Tue, 20 Oct 2026 08:43:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455150.1668701; Tue, 20 Oct 2026 08:43: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 1xJ5RP-0005wi-Kh; Tue, 20 Oct 2026 08:43:27 +0000 Received: by outflank-mailman (input) for mailman id 1455150; Tue, 20 Oct 2026 08:43:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5RN-0005XS-IA for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:43:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5RM-00EVzr-Ui for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:43:24 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad729ac-e002-0a2a0a5209dd-0a2a4503caa8-10 for ; Tue, 20 Oct 2026 10:43:24 +0200 Received: from [52.101.65.127] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad729ac-fae8-0a2a45030019-3465417fccf2-3 for ; Tue, 20 Oct 2026 10:43:24 +0200 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by DB8PR03MB6314.eurprd03.prod.outlook.com (2603:10a6:10:140::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:43:19 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 08:43: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=lxyleHMxgiqq+gCg0NX/M3rTd/ekIc8sLmKt5vRhAw0qV9W3+vk/8/8QBQXDc2o22As39o/gilUDXEHvoK4VEG1gwO9GBDsRzTSlsuPIblxV4J6gLfoJPkcgYYUf7ImIBYW0hXGrM78rXKiwkgc7zcnMIGCcgtWeLZkQKn/HtltNoKA12iO2UL7hlEhRUM1Vckipg/i3tNFzxKcInEPf/Wkm21/hm5oiKd/AwS24Womxes5UVRVgEkc6vLyQHhuoyCVlu+CueBQeYhb8kKCb0zz7JZCj37EHGqaSfZrmcPiBcPHC0fXSa13iDnvNUwiXK3ZGP7rZCQwgRnLEeLO5/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=7TNXrq/eIe3FRfbDMcTCc6uYRqj4y3XZ4gmJvGPMEpw=; b=PgZgmuB+tl2ew5f8UFJ5bgrradIft7EMBcv0MFE/mGsJM0HUxsLMgGaY8aYSDLYamOO9ES7WQPgK5j0GK4mY/3uQp7itz9VGCE1F/AUklqsdlI52+opetuGeDcbSssR7a84qjCwsTq2YvD6ef6YzXNbLwrSgHV2VVngSUagCULsc7TdAAAIF2KLyLyWMIAqrqI4+MxTwOHKxbQynEngBDlFEjcjwP5uYNUdto/HbW/99ww4kDTbIldLN/O3O9jCf8RZ68FTLYKQX+Vh4X1P6+qtYi8CX0obZDE5rx3yXENmRwXdBrRtNA2s+j7iAenRCMgv4XH3J4/wtr3xPFL9BpA== 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=7TNXrq/eIe3FRfbDMcTCc6uYRqj4y3XZ4gmJvGPMEpw=; b=aRcUoW2bXqMLHOQv+KipGZ05tuKAk1Ov1/8lCWYPIZfm+n94AxGWNb2BLHb8GjIiPrH74D/8qRs5JuI+Vm0pCxSBEOYQj50+bi2wuTSvlOnPQprhPmu91Z0+QwU2iYsHVhwbwMHg1b8QslhfTgNLG5Pi6JM5MJ/BZMBKYcLLfMkxg7wbbebFmmWIAV1zDMAjZnTC092Xjw+tFOGL6Yjlz4sICPzgSoec/79PN0hL4M9rWf0t8UxE6ZsY9jmSNJhU5F4F8lvfC24/tW//yiFfw/VmmGMUPIe0bNJIw5bL6ukE0DQVGeYucjhgHKd1Tbidh4dWmjUIDFoGV2P627ta+Q== 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 Subject: [PATCH v14 0/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Topic: [PATCH v14 0/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Index: AQHdYG8Owtq5VPLnj0mORU5PE9AMEA== Date: Tue, 20 Oct 2026 08:43:19 +0000 Message-ID: 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: GVXPR03MB11113:EE_|DB8PR03MB6314:EE_ x-ms-office365-filtering-correlation-id: 0e4e0430-5e04-49c0-7e47-08df2e8630ff x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|7416014|38070700021|11063799006|56012099006|260925021911599003|261009223027099003|260925022911599003|260925021311599003|10067099003|18002099003|6133799003; x-microsoft-antispam-message-info: oO358fWwhy2ae3H2gmv8HleGtYNNDYWX74e+Be2xgtgCJac6//qSYhJ4+9gIHUlg6L0+mjfoGJCsBb8dL9pa5kBIKaVnIhvBA2eiMk4tK5tquN8JWHQjQoyjLUvhr58qmMK4phU36nTtsCuWQzOBGwdizQRjI5ViuNVE7m4N8S2MZS9+f6aVWEhi7knh9Fz00LuyMzxtQqcsM8AtcEiawCL9B/UPLb0Q9XPu/kyrFSPMfCMqVk7QavCG9ipTS4zh2/I/fTgaS+0NOiz9FnYALIvgIaJJsfzAKXID4lVRRl2+j7+OZCEFfnbBH244vY3shIR1DH4CtST6bzEjwrokse9wtgtjsr7Od1jC6rfIcjhHNJpbldvGxXOAsshEJGoQe/aTtENkf7Er0f/o9x5fSB4zc59aVFJx8ZaGkERYigBNgLePMHNa7Ph+qPdgr72TmyHEjId4Ni0ycJBMQncTEK6gfMhBViqp9ZKNIKMskvX4zqq0h0OnLbYYmeP2WDRcubjJBcELMnHh1n2mXjwYdoeJ1cVTwMAd9IShVsxjwFe+RC37Ib0xeX6MG4lZcQjrhMYp4wXfzS/BTof8E0ARD9bTSvYHmlb/0NOd7KyB3UjGcZ1jmF0VMddJtIjDik6I9VJZCu8U+cDqgQV+G5et1MTLgTl8dxgvZKF4yLnhPs0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(7416014)(38070700021)(11063799006)(56012099006)(260925021911599003)(261009223027099003)(260925022911599003)(260925021311599003)(10067099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?R0FjRGRkN2hFc3VNeXBkako4Z05laElSZWFGV1BIMXllcVlnc2xkTVl2MUpy?= =?utf-8?B?czhqYjRXcTBaSXBMMFlSWGRhZkEzRys0RGZQbjFia3RoY0Zpc2JFL2R4blBF?= =?utf-8?B?RTZTV0dFWXNwNEhsN1NraGZadlc1ekVucHhIT1BCbXZmSDlpNy9NYXNtWk16?= =?utf-8?B?cVBHQTBzUnhFMGRhRmV4RWt0cDg5ZUI1M1JoQlA0djFyZHhwbHJUZTIzenF6?= =?utf-8?B?YVh0dWxybWJ1VWtrejN3OTVJUDA1M3Q1Y2Z3MzQwM2xiNWtxRllrNnlQRmJz?= =?utf-8?B?QUVaVmtxV0hQNW5yL2dFT045Mi9JaDhCazdRdnhVWlpuUUkwNHZjVkord0hw?= =?utf-8?B?dzBSZURCMEprWm9lYnp5TXFtMkJrM0RST0tEYjdXb1JtcmgvLytSN1BUVnlp?= =?utf-8?B?QjRsZ0NDRmtoT3hHZU1yVnA3c1VBSlVMbGlaa3RhcXU5c0N0NitUaVN0VTdr?= =?utf-8?B?eVAzcjBhY0g2aFNwa0RMT3NzUFVTSjl1U3JySXRnV2IvcDhxZHpjTXY3d3Y3?= =?utf-8?B?cTlNdC9GN1pBK1k5bm51UFVFN0RiUyt5ZVNROEJVT29tWTF0cGNRSVFUQ3VS?= =?utf-8?B?Q2RET2dEUnA1MGRiRGc1SEF6NUtLZVJSRHYvb25PWFN2UHRwODVTbnpVOS9X?= =?utf-8?B?SHdDSzd2YWRiU0R3VVJJVlQ3V0JwWDJQREtNZ0hTQ3A4WTl6RmxMTklLam9M?= =?utf-8?B?WEVxam5ybnRuLzNDbWZ3UkNrN1ZmZjFqak9kQldvNExGMUdIQzVOZmhBUWJw?= =?utf-8?B?c25DZ3BYM0ZFeFRINmJSaFQ2WEZkcUFBRGwvTWNGQ2R1L3p3Rmt4SkJVNlFF?= =?utf-8?B?eGhVWDA0V0hIMElvelRBdlkzRDR3aEtlYWdtMVBvcUNaR2Jia2lrWThoOGJ3?= =?utf-8?B?UWVRSG9mVi9FWDRYU2I2c3hBTzM1alE4OFR0UmtVRXBmUFkxREtGTFc2V00y?= =?utf-8?B?MlYwVUJDKzlsS3FXZk5MTmROT3VValhpendxVWRyLzRCSWQ1dWJMbmJ0ek00?= =?utf-8?B?cVFIV2o1ZGhCMzZrUkdKbXlNV0g2cFlTS0V6Y3owTngxZko4U3FjMHpscXFl?= =?utf-8?B?QW93T3BBWm53QUdwRVo1SDVvS241Y01PTWlzT2N6Q2MyMitDVGJvdk1FbHEv?= =?utf-8?B?ckFBeEJTQXpia1U0MDhFb05zSWpNRktpSFRuWVpZTTZ2QVc3YzBXbzExcXg2?= =?utf-8?B?R2VXTGVSdVo4cEdUS1NYdzlJK1JTY3REb1pJV2ppZjVXNG5ZeThQOHltYXFo?= =?utf-8?B?czlCMEx6YVJBZjFwa0hOMlNTVmhWV3JYcXdLVXI2UVVRZVBlazBBQUorS0dO?= =?utf-8?B?UVY1SnFGSnVXSTJGTkNkU3BGZVI3VS8rVWo2ZUxGL1MvcjdtRlhrZmpvSWtq?= =?utf-8?B?Rml3VWsxK05UK0FmUTdvbVVwc0pTQXU2UGJmbnZRQlpsdXNFM3hhTFFpL1JL?= =?utf-8?B?VDN6ZTc1eFFRc2NiZ0N6Yno2UHdTOS8yMFVUNEtUYng5Ym52WWdZc25neTJT?= =?utf-8?B?WXJKRTBraS9VUTkxV1MrVjFSUjlXcGFyV0ovSDhkVXUzbmhBcDFUclU3aGJE?= =?utf-8?B?dCtJclIvODQxQjhuTzJUQ3djdG8raWpLa1JhTlRQNFlBOHFCQnhUMis0di91?= =?utf-8?B?R3NkbC9nUUZlZUVoWWNqTnBQcm92OFRoUVVXNkpBUnBlOHdCLzJPZ2Z6SmxW?= =?utf-8?B?aGMzQitrdEpZRitHK1dKSW9UeXBPTEZMRjErdnpJRHVtU2txcUE1ODROM3hH?= =?utf-8?B?Wkx3WU1aS0RUUUhBdk0yNllrWCtWRFZ3cFNUbE1tMjhzLzZUdk42YmtXMjVY?= =?utf-8?B?alV1MlJseFp5L0pMdUZMZVU1WWJMRE5oSXF0Z3RpWjk4ZWRDNEIzS3puckdH?= =?utf-8?B?V01sZ0VvUXc0Mkt2dHRDMDJ4enlZejRzem1wYUVFRVZlYURGZnFaUGI2YzR4?= =?utf-8?B?OXljcEFTeG1UR3dXSjZXTktzSEViNHdVbHNPVWRMME5lVzUxWWV3ZWlIcTdC?= =?utf-8?B?Vmh2Qm9ITVhPaklZOVhIeEtTb2NvdXN1dzRxamVGQmc0dEFEZUQ3MjN1U2cv?= =?utf-8?B?clpZN3FMNk9sTlp0dUZoR0g3ZHZSb0Fjbk85eUVnOENsY0Njd1hZanJHcG9H?= =?utf-8?B?MmJvVXYxRHQvTE5RUmNXaVkwRmlEWTBabW1HTnc2Y0lmSjllYTNVYitzajJU?= =?utf-8?B?eFpCNlNFcVNUUzZBRjI5SS8rMzdqNDcwVDV4UkxNd2U4UXhhYUJ4Y29GMlB4?= =?utf-8?B?ZUVMa3YrdXNITmVXK2xRR2JXTHpKUXdXb0lVaks1enFhYk96TXhXTWNPM0Ev?= =?utf-8?B?RldQOFBTMmQwSHc4VEpUaUxUUDN5eks2eUFCMi9BRVA2Wm9ObGxveFBiMkdZ?= =?utf-8?Q?98X0vokzl/c/IzJQ=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <68EFC47BF30A46418041F9FF5890F88A@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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e4e0430-5e04-49c0-7e47-08df2e8630ff X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 08:43:19.1507 (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: z1L4TrB+nncXbUJLhb7lO9YY1SNmbe7jjJZI4yl7vbW57NFfyrBAAIRnXD+By8sb1eT3JmfGjGfhbYocgxT8SJlmxg0iWjNEvzdQITNDtwU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6314 X-purgate-ID: tlsNG-33051d/1792485804-77EC24E9-59CDD126/0/0 X-purgate-type: clean X-purgate-size: 25918 SW5yb2R1Y2luZyBwYXRjaCBzZXJpZXMgd2hpY2ggaW5jbHVkZXMgaW1wbGVtZW50YXRpb24gb2Yg dGhlIFNDSSBTQ01JDQpTTUMgbXVsdGktYWdlbnQgc3VwcG9ydC4NClRoaXMgcGF0Y2ggc2VyaWVz IGZvbGxvd3MgUkZDIHY1IFszXSBzZXJpZXMgd2hpY2ggd2FzIGludHJvZHVjaW5nIGJvdGgNClND TUkgc2luZ2xlLWFnZW50IGFuZCBtdWx0aS1hZ2VudCBzdXBwb3J0LiBBZnRlciB0aGUgZGlzY3Vz c2lvbiBpdCB3YXMNCmRlY2lkZWQgdG8gc3BsaXQgZmVhdHVyZXMgYW5kIHVwc3RyZWFtIHNpbmdl LWFnZW50IHN1cHBvcnQgZmlyc3QuIFRoaXMNCmZlYXR1cmUgaXMgbWVyZ2VkIGZvciBub3cgdG8g djQuMjEtcmMyLg0KSSdtIHN0YXJ0aW5nIHRoaXMgcGF0Y2ggc2VyaWVzIGZyb20gdjYgdG8gc2F2 ZSB0aGUgZGlzY3Vzc2lvbiBoaXN0b3J5DQphbmQgZG9uJ3QgYnJlYWsgY2hhbmdlcyBsb2cuDQoN ClBhdGNoIC0geGVuL2RvbWN0bDogZXh0ZW5kIFhFTl9ET01DVExfYXNzaWduX2RldmljZSB0byBo YW5kbGUgbm90DQpvbmx5IGlvbW11DQotIGFkZCBjaGFpbmdlZCBoYW5kbGluZyBvZiBhc3NpZ25l ZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCmFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkg dGhyb3VnaCBTQ0kgZnJhbWV3b3JrLg0KQ2hhbmdlIHdhcyBkb25lIGluIHR3byBwYXJ0czoNCiAt IGNhbGwgdG8gc2NpX2RvX2RvbWN0bCgpIHRvIGRvX2RvbWN0bCgpDQogLSB1cGRhdGUgaW9tbXVf ZG9fZHRfZG9tY3RsKCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKQ0KIGFu ZCBub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVQ0KDQpQYXRj aCAtIHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyDQotIGFkZCBYZW4tc3BlY2lmaWMgU0NNSSBjb250YWluZXIgY29tcGF0aWJsZSBgeGVuLHNj aWANCiAgdW5kZXIgYC9jaG9zZW4veGVuYDsgWGVuIGJpbmRzIG9ubHkgdG8gdGhlIGBhcm0sc2Nt aS1zbWNgIGluc2lkZSBpdCBhbmQNCiAgaWdub3JlcyBvdGhlciBTQ01JIG5vZGVzIChlLmcuIHVu ZGVyIGAvZmlybXdhcmVgKS4NCi0gZGVzY3JpYmUgc2Vjb25kYXJ5IGFnZW50cyBhcyBgeGVuLHNj bWktYWdlbnRgIGNoaWxkcmVuIG9mIGFuIGBhZ2VudHNgDQogIG5vZGUsIHdpdGggYGFybSxzbWMt aWRgLCBgc2htZW1gIGFuZCBvcHRpb25hbCBgcmVnYCBmb3IgdGhlIGFnZW50IElELg0KICBEaXNj b3ZlciB0aGUgSUQgdGhyb3VnaCBCQVNFX0RJU0NPVkVSX0FHRU5UIHdoZW4gYHJlZ2AgaXMgYWJz ZW50Lg0KLSBrZWVwIHNoYXJlZC1tZW1vcnkgbm9kZXMgdW5kZXIgYHhlbl9zY21pX2NvbmZpZ2A7 IHBsYXRmb3JtIFJBTQ0KICByZXNlcnZhdGlvbnMgYXJlIGRlc2NyaWJlZCBzZXBhcmF0ZWx5IGlu IGAvcmVzZXJ2ZWQtbWVtb3J5YC4NCi0gZWFjaCBndWVzdCB1c2luZyBTQ01JIHN1cHBsaWVzIGl0 cyBhZ2VudF9pZCAoZG9tMCB2aWENCiAgYHhlbixkb20wLXNjaS1hZ2VudC1pZGAgcHJvcGVydHkg aW4geGVuLHNjaSBjb21wYXRpYmxlIG5vZGUsDQogIHRvb2xzdGFjayB2aWEgYGFybV9zY2kgPSAi dHlwZT1zY21pX3NtY19tdWx0aWFnZW50LGFnZW50X2lkPS4uLiJgLCBkb20wbGVzcw0KICB2aWEg YHhlbixzY2lfdHlwZWAgKyBgeGVuLHNjaS1hZ2VudC1pZGAgaW4gYHhlbixkb21haW5gKS4NCi0g ZmFjdG9yIG91dCBTQ01JIGdlbmVyaWMgZGVmaW5pdGlvbnMgYW5kIHNobWVtIGNvZGUuDQotIHBh c3N0aHJvdWdoIGNvbmZpZ3VyYXRpb24gZm9yIFNDTUkgZ3Vlc3RzIG1pcnJvcnMgb3RoZXIgSFcg cGFzc3Rocm91Z2guDQoNClBhdGNoIC0gZG9jczogYXJtOiBhZGQgU0NJIFNDTUkgU01DIG11bHRp LWFnZW50IGRyaXZlciBkb2NzDQotIGRvY3VtZW50IHRoZSBYZW4gU0NNSSBjb250YWluZXIgdW5k ZXIgYC9jaG9zZW4veGVuL3hlbl9zY21pX2NvbmZpZ2AgYW5kIHRoZQ0KICBtZWRpYXRvcuKAmXMg YmluZGluZyBydWxlczsgdXBkYXRlIGV4YW1wbGVzIGFjY29yZGluZ2x5Lg0KDQpBbGwgWGVuLXNw ZWNpZmljIFNDTUkgY29uZmlndXJhdGlvbiBub3cgbGl2ZXMgdW5kZXIgYC9jaG9zZW4vYA0KdG8g a2VlcCBob3N0IERUIGNoYW5nZXMgaXNvbGF0ZWQgd2hpbGUgbGVhdmluZyB0aGUgaG9zdCBgL2Zp cm13YXJlL3NjbWlgDQp1bnRvdWNoZWQgZm9yIERvbTAgY29uc3VtcHRpb24uDQoNCkNvZGUgY2Fu IGJlIGZvdW5kIGF0Og0KaHR0cHM6Ly9naXRodWIuY29tL29sZWtzaWltb2lzaWVpZXYveGVuL3Ry ZWUvc2NtaV9tYV91cHN0cnY2DQoNClsxXSBSRkMgdjI6DQpodHRwOi8vcGF0Y2h3b3JrLmtlcm5l bC5vcmcvcHJvamVjdC94ZW4tZGV2ZWwvY292ZXIvY292ZXIuMTY0NDM0MTYzNS5naXQub2xla3Np aV9tb2lzaWVpZXZAZXBhbS5jb20vDQpbMl0gUkZDIHYzOg0KaHR0cHM6Ly9wYXRjaHdvcmsua2Vy bmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9wYXRjaC8yMDI1MDMxMTExMTYxOC4xODUwOTI3LTEt Z3J5Z29yaWlfc3RyYXNoa29AZXBhbS5jb20NClszXSBSRkMgdjU6DQpodHRwczovL2xvcmUua2Vy bmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMTc1MzE4NDQ4Ny5naXQub2xla3NpaV9tb2lzaWVpZXZA ZXBhbS5jb20vDQpbNF0gU0NNSSBzaW5nbGUtYWdlbnQ6DQpodHRwczovL2xvcmUua2VybmVsLm9y Zy94ZW4tZGV2ZWwvY292ZXIuMTc1Njk5NTU5NS5naXQub2xla3NpaV9tb2lzaWVpZXZAZXBhbS5j b20vDQpTQ01JIHNwZWM6DQpodHRwczovL2RldmVsb3Blci5hcm0uY29tL2RvY3VtZW50YXRpb24v ZGVuMDA1Ni9lLz9sYW5nPWVuDQoNClNDTUkgYmluZGluZ3M6DQpodHRwczovL3dlYi5naXQua2Vy bmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L3RyZWUv RG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Zpcm13YXJlL2FybSxzY21pLnlhbWwN Cmh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2 YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvYWNj ZXNzLWNvbnRyb2xsZXJzL2FjY2Vzcy1jb250cm9sbGVycy55YW1sDQoNClJlZmVyZW5jZSBFTDMg Rlc6DQpSUEk1OiBodHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9hcm0tdHJ1c3RlZC1maXJt d2FyZS9jb21taXRzL3JwaTVfZGV2Lw0KUmVuZXNhcyB2NGg6DQpodHRwczovL2dpdGh1Yi5jb20v R3J5Z2lyaWlTL2FybS10cnVzdGVkLWZpcm13YXJlL2NvbW1pdHMvcmNhcl9nZW40X3YyLjdfdjR4 LXNjbWlfdXBkLw0KDQpiYXNlLWNvbW1pdDogZGJlNjBmMjQ0YyAoVXBkYXRlIFhlbiB0byA0LjIx LCAyMDI1LTAyLTIxKQ0KDQpDaGFuZ2VzIGluIHYxNDoNCi0gcmVwbGFjZSB0aGUgZmxhdCBzZWNv bmRhcnktYWdlbnQgbGlzdCBhbmQgaXRzIGNlbGwtY291bnQgcHJvcGVydHkgd2l0aA0KICB4ZW4s c2NtaS1hZ2VudCBjaGlsZCBub2RlcyB1bmRlciBhZ2VudHMsIHVzaW5nIHJlZyBmb3IgYW4gb3B0 aW9uYWwgSUQNCi0gc2NvcGUgc2Vjb25kYXJ5LWFnZW50IHBhcnNpbmcgdG8gdGhlIG1hbmFnZW1l bnQgY2hhbm5lbCdzIHhlbixzY2kgY29udGFpbmVyDQotIHJlc29sdmUgZGlzY292ZXJlZCBJRHMg YmVmb3JlIGluc2VydGlvbiBhbmQgcmVqZWN0IGR1cGxpY2F0ZSBvciBpbnZhbGlkIElEcw0KLSB2 YWxpZGF0ZSBzaGFyZWQtbWVtb3J5IHBoYW5kbGVzLCBhZGRyZXNzZXMgYW5kIG5vbnplcm8gcGFn ZS1hbGlnbmVkIHNpemVzDQotIHJldGFpbiBzaGFyZWQtbWVtb3J5IG5vZGVzIHVuZGVyIHhlbl9z Y21pX2NvbmZpZyBhbmQgZG9jdW1lbnQgcGxhdGZvcm0NCiAgcmVzZXJ2YXRpb25zIHNlcGFyYXRl bHksIGZvbGxvd2luZyB0aGUgcmV2aWV3IGRpc2N1c3Npb24NCi0gdXBkYXRlIGJpbmRpbmcgZXhh bXBsZXMgYW5kIGNvbW1pdCBkZXNjcmlwdGlvbiBmb3IgdGhlIGNoaWxkLW5vZGUgZm9ybWF0DQot IG1hdGNoIHRoZSBjb25zdC1xdWFsaWZpZWQgU0NJIGRvbWFpbl9zYW5pdGlzZV9jb25maWcgY2Fs bGJhY2sgaW50ZXJmYWNlDQotIGRlc2NyaWJlIHNlY29uZGFyeSBhZ2VudHMgYXMgeGVuLHNjbWkt YWdlbnQgbm9kZXMgdW5kZXIgYWdlbnRzDQotIHVwZGF0ZSBob3N0LCBkaXNjb3ZlcnkgYW5kIGRv bTBsZXNzIGV4YW1wbGVzIGZvciB0aGUgY2hpbGQtbm9kZSBmb3JtYXQNCi0gY2xhcmlmeSBzaGFy ZWQtbWVtb3J5IHBsYWNlbWVudCBhbmQgcGxhdGZvcm0gUkFNIHJlc2VydmF0aW9ucw0KDQpDaGFu Z2VzIGluIHYxMzoNCi0gbWVtY3B5X3tmcm9tLHRvfWlvKCk6IGFsaWduIG9ubHkgdGhlIEkvTyBw b2ludGVyIGFuZCBhY2Nlc3MgdGhlDQogIHJlZ3VsYXIgbWVtb3J5IHNpZGUgdGhyb3VnaCBnZXRf dW5hbGlnbmVkX2xlMzIoKS9wdXRfdW5hbGlnbmVkX2xlMzIoKS4NCi0gZG9jdW1lbnQgdGhlIGNv bnRyYWN0IG9mIHRoZSBoZWxwZXJzIGluIHhlbi9pby5oDQotIHJld29yZCB0aGUgQXJtIGltcGxl bWVudGF0aW9uIG5vdGVzIHRvIHN0YXRlIHRoZSBjb25jcmV0ZSBhY2Nlc3MNCiAgcGF0dGVybg0K LSBkcm9wIHRoZSBpbmNvcnJlY3QgY2xhaW0gYWJvdXQgYXZvaWRpbmcgZW5kaWFubmVzcyBjb252 ZXJzaW9uIGZyb20gdGhlDQogIGNvbW1pdCBtZXNzYWdlOyBub3RlIGluc3RlYWQgdGhhdCB0aGUg X2xlMzIgaGVscGVycyBwYWlyIHdpdGgNCiAgcmVhZGwoKS93cml0ZWwoKSBzbyB0aGUgYnl0ZSBz ZXF1ZW5jZSBpcyBwcmVzZXJ2ZWQgb24gZWl0aGVyIGVuZGlhbm5lc3MNCi0gZml4IHR5cG8gaW4g Y29tbWl0IGRlc2NyaXB0aW9uDQoNCkNoYW5nZXMgaW4gdjEyOg0KLSByZWJhc2UgdG8gdGhlIGxh dGVzdCBzdGFnaW5nDQotIGFkZCBSLUJzIGZyb20gU3RlZmFubyBhbmQgQWNrIGZyb20gSmFuDQot IGFkZCBtaXNzZWQgQWNrLg0KLSBBZGQgbWlzc2VkIFItQg0KLSBjb3JyZWN0IHRoZSBFbWFjcyBm b290ZXIgb2YgYm90aCBmaWxlcywgd2hpY2ggYXNrZWQgZm9yIDggY29sdW1uDQp0YWIgaW5kZW50 YXRpb24gd2hpbGUgdGhlIGNvZGUgaXMgaW4gNCBjb2x1bW4gWGVuIHN0eWxlDQotIHJlYmFzZSB0 byB0aGUgbGF0ZXN0IHN0YWdpbmcNCi0gcmV0dXJuIEVJTlZBTCBpZiB4ZW4sc2NpX3R5cGU9c2Nt aV9zbWNfbXVsdGlhZ2VudCB3YXMgc2V0IGJ1dA0KQ09ORklHX1NDTUlfU01DX01BIG5vdCBzZXQN Ci0gcHV0IGFybV9zY2lfYWdlbnRfaWQgYWZ0ZXIgdjhyX2VsMV9tc2EgYW5kIGJlZm9yZSBwYWQg dG8gcHJlc2VydmUNCm9yZGVyLiBSZWR1Y2VkIHBhZCBmcm9tIHVpbnQxNl90IHRvIHVpbnQ4X3Qg dG8gZmlsbCB0aGUgZ2FwICh3YXMgMg0KYnl0ZXMgYmVmb3JlIGFkZGluZyBhcm1fc2NpX2FnZW50 X2lkIGFuZCBsZWZ0IG9ubHkgMSwgc28gdXNlZCB1aW50OF90DQp0byBwcmVzZXJ2ZSBzdHJ1Y3R1 cmUgc2l6ZSkNCi0gZml4IHNjbWlfaGFuZGxlX2NhbGwgdG8gdXNlIGFybV9zbWNjY19ndWVzdF9z bWMgaGVscGVyIGZ1bmN0aW9uDQotIHVwZGF0ZSBzZW5kX3NtY19tZXNzYWdlIGZ1bmN0aW9uIHRv IHVzZSBuZXcgZm9ybWF0IG9mDQphcm1fc21jY2NfMV8xX3NtYw0KLSBndWFyZCB0aGUgRG9tMCBT Q01JIGFnZW50IGlkIHNldHVwIGluIGNyZWF0ZV9kb20wKCkgYW5kIE1BIHJlbGF0ZWQNCmZ1bmNp dG9ucyB3aXRoIENPTkZJR19TQ01JX1NNQ19NQQ0KLSBmaXggdGhlIHhlbl9zY21pX2NvbmZpZyBl eGFtcGxlIGluIGJvb3RpbmcudHh0LCB3aGljaCBwbGFjZWQgcHJvcGVydGllcw0KYWZ0ZXIgc3Vi bm9kZXMgYW5kIHdhcyByZWplY3RlZCBieSBkdGMgd2l0aCAiUHJvcGVydGllcyBtdXN0IHByZWNl ZGUNCnN1Ym5vZGVzIg0KDQpDaGFuZ2VzIGluIHYxMToNCi0gRml4IGFnZW50X2lkIGRvY3VtZW50 YXRpb246IGNsYXJpZnkgaXQgYXBwbGllcyB0byBTQ01JIFNNQw0KbXVsdGktYWdlbnQgc3VwcG9y dCBvbmx5LCBub3QgcGxhaW4gU0NNSSBTTUMgKHJldmlld2VyIGZlZWRiYWNrKQ0KLSBSZW1vdmUg Im5vbi16ZXJvIiBmcm9tIGFnZW50X2lkIGRlc2NyaXB0aW9uIHRvIG1hdGNoIGFjY2VwdGVkDQpy YW5nZSBbMC4uMjU0XQ0KLSBSZW1vdmUgIlVJTlQ4X01BWCAoMjU1KSBpcyB0cmVhdGVkIGFzIGlu dmFsaWQiIGZyb20gdXNlcg0KZG9jdW1lbnRhdGlvbiBhcyB1bm5lY2Vzc2FyeSBpbXBsZW1lbnRh dGlvbiBkZXRhaWwNCi0gQWRkIExJQlhMX0hBVkVfU0NNSV9TTUNfTVVMVElBR0VOVCBmZWF0dXJl IG1hY3JvIGluIGxpYnhsLmggdG8NCmFkdmVydGlzZSB0aGUgbmV3IHNjbWlfc21jX211bHRpYWdl bnQgdHlwZSBhbmQgYWdlbnRfaWQgZmllbGQNCi0gQWRkIGFnZW50X2lkIHZhbGlkYXRpb24gaW4N CmxpYnhsX19hcmNoX2RvbWFpbl9idWlsZF9pbmZvX3NldGRlZmF1bHQoKSB0byByZWplY3QgaW52 YWxpZCB2YWx1ZXMgYXQNCnRoZSBsaWJ4bCBsZXZlbCwgbm90IG9ubHkgaW4geGwNCg0KQ2hhbmdl cyBpbiB2MTA6DQotIHJlbW92ZSB1bnVzZWQgc2NpX2RvX2RvbWN0bCBzdHViIGZyb20gc2NpLmgN Ci0gcmVtb3ZlZCBleHRyYSBpbmNsdWRlIGluIG1lbWNweS17dG8vZnJvbX1pby5jIGZpbGVzDQot IEZpeCB0YWJzIGluIE1BSU5UQUlORVJTIGZpbGUNCi0gcmVtb3ZlIGR1cGxpY2F0ZSBTUERYIHRh ZyBmcm9tIHNjbWktc2htZW0uYw0KLSBhZGQgY2FzdCB0byBBUk1fU01DQ0NfSU5WQUxJRF9QQVJB TUVURVIgdG8gc2V0dGxlIHRoZSBzaWduIHNpbmNlDQpBUk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVU RVIgaXMgLTMgd2hpY2ggaXMgcGFydCBvZiB0aGUgc3BlYyBhbmQgcmVzcA0KaXMgdGhlIGRlZmF1 bHQgc21jY2MgY2FsbCBzdHJ1Y3R1cmUuDQotIHVwZGF0ZSBmcmVlX2NoYW5uZWxfbGlzdC4gQWRk IHNwaW5sb2NrIHRvIGF2b2lkIHJhY2UgY29uZGl0aW9uIGFuZA0KYSBjb21tZW50IHdpdGggYSBk ZXNjcmlwdGlvbiBvZiB0aGUgZnVuY3Rpb24gd29yaw0KLSBwcmVzZXJ2ZSBlcnJvciBvZiBzbWNf Y3JlYXRlX2NoYW5uZWwgaW4gc2NtaV9wcm9iZQ0KLSBjaGVjayBzY21pIHNobWVtIGFkZHJlc3Mg YWxpZ25tZW50IGFzIHdlbCBhcyBpdCBpcyBkb25lIGZvciBzaXplDQotIGNoZWNrIGZvciBkLT5h cmNoLnNjaV9kYXRhICE9IE5VTEwgaW4gc2NtaV9oYW5kbGVfY2FsbA0KLSB1c2UgU0NNSV9TSE1F TV9NQVBQRUQgc2l6ZSBmb3IgaW9tZW1fcGVybWl0X2FjY2Vzcw0KLSBjaGFuZ2UgbGVuIHR5cGUg dG8gdW5zaWduZWQgaW4gc2htZW1fe2dldHxwdXR9X21lc3NhZ2UNCi0gcmVuYW1lIHNobWVtX2No YW5uZWxfaXNfZnJlZSB0byBzaG1lbV9jaGFubmVsX3N0YXR1cw0KLSBhZGQgY29tbWVudCBhYm91 dCBza2lwcGluZyBtZXNzYWdlIHN0YXR1cyB3aGVuIGdldHRpbmcgbWVzc2FnZSByZXNwb25zZQ0K LSBTZXQgY29ycmVjdCBhZ2VudF9pZCByYW5nZXMgZm9yIGRvbTBsZXNzIGFuZCBhIHRvb2xzdGFj ay4gQWdlbnRfaWQgMA0KaXMgbm90IGJpbmRlZCBmb3IgZG9tMCBzbyBjYW4gYmUgcmV1c2VkLiBB bHNvIG1lbnRpb25lZCB0aGF0DQpVSU5UOF9NQVggKDI1NSkgaXMgdHJlYXRlZCBhcyBpbnZhbGlk IGFnZW50X2lkLg0KLSBTcGxpdCBoeXBlcnZpc29yIGFuZCB0b29sc3RhY2sgY2hhbmdlcyBpbnRv IHNlcGFyYXRlIGNvbW1pdHMNCi0gbW92ZSBpbml0IGxpc3QgYW5kIHNwaW4gaW5pdCBhZnRlciBp bml0aWFsIGNoZWNrcyBpbiBwcm9iZSBjYWxsDQotIGZpeCB0eXBvIGluIGNvbW1lbnRzDQotIGNs ZWFuIHJlc291cmNlcyB3aGVuIHNjaV9yZWdpc3RlciByZXR1cm5zIGFuIGVycm9yLg0KLSBTcGxp dCBoeXBlcnZpc29yIGFuZCB0b29sc3RhY2sgY2hhbmdlcyBpbnRvIHNlcGFyYXRlIGNvbW1pdHMN Ci0gcmVwaHJhc2Ugc2VjdGlvbiBhYm91dCAvZmlybXdhcmUvc2NtaS4gTWVudGlvbmVkIHRoYXQg dGhpcyBub2RlIGlzDQp0YWtlbiBmcm9tIEhvc3QgRFQgYW5kIGNvcGllZCB1bm1vZGlmaWVkLg0K LSBmaXggeGVuLHJlZyBhZGRyZXNzIGZvciBzZWNvbmRhcnkgZG9tYWlucyBmb3IgRG9tMGxlc3Mg Y29uZmlndXJhdGlvbg0KDQpDaGFuZ2VzIGluIHY5Og0KLSB0cmVhdCBTQ0kgYXMgYSBnYXRlIGZv ciBYRU5fRE9NQ1RMXyphc3NpZ25fZGV2aWNlOiBhYm9ydCBiZWZvcmUNCklPTU1VIGlmIHNjaV9k b19kb21jdGwoKSByZXR1cm5zIGFuIGVycm9yIG90aGVyIHRoYW4gLUVOWElPLCBpbnN0ZWFkDQpv ZiB0cnlpbmcgdG8gcHJvcGFnYXRlIFNDSSBlcnJvcnMgYWZ0ZXIgYSBzdWNjZXNzZnVsIElPTU1V DQpvcGVyYXRpb24uIFRoaXMgYXZvaWRzIHBhcnRpYWwgc3VjY2VzcyBhbmQgdGhlIG5lZWQgZm9y IElPTU1VIHJvbGxiYWNrLg0KLSByZW1vdmUgZWFybHkgcmV0dXJuIGZyb20gZG9fZG9tY3RsKCkg aW4gdGhlIGFzc2lnbl9kZXZpY2UNCnBhdGggdG8ga2VlcCBSQ1UgaGFuZGxpbmcgaW50YWN0Lg0K LSBjaGFuZ2UgSVNfRU5BQkxFRCgqKSB0byAjaWZkZWYgaW4gc2NpX2RvX2RvbWN0bCBxdWFyZA0K LSByZXdvcmQgY29tbWl0IGRlc2NyaXB0aW9uIHRvIHJlZmVyIHRvIG1lbWNweV9mcm9taW8gYW5k IG1lbWNweV90b2lvDQotIG9yZGVyaW5nIG9iai15IGluIE1ha2VmaWxlDQotIHJlbmFtZSBBTExf TElCUyB0byBBUkNIX0xJQlMNCi0gZHJvcCBpby5oIGFuZCBtb3ZlIGRlZmluaXRpb25zIHRvIHRo ZSBjb21tb24gaGVhZGVyLCBmaXggY29tbWVudHMgdG8NCmJlIGFyY2ggbmV1dHJhbA0KLSB1cGRh dGUgY29tbWVudHMgZm9yIG1lbWNweV97ZnJvbS90b31pbyBpbXBsZW1lbnRhdGlvbg0KLSBzb3J0 IGFuZCByZWZhY3RvciBNQUlOVEFJTkVSUyBlbnRpZXMNCi0gcmVtb3ZlIFNwdXJpb3VzIGNoYW5n ZXMNCi0gYWRkIGV4dHJhIGNoZWNrIHRvIGF2b2lkIEFTU0VSVCB3aGVuIGNhbGxpbmcgdW5tYXBf Y2hhbm5lbF9tZW1vcnkNCmZyb20gYXNzaWduIGRldmljZSBtZXRob2QNCi0gc2V0IGNvcnJlY3Qg dHggZmxhZyB0byBTQ01JX0JBU0VfQUdFTlRfUEVSTUlTU0lPTlNfUkVTRVQgd2hlbg0KZnJlZWlu ZyByZXNvdXJjZXMuIEZsYWcgc2hvdWxkIGJlIHNldCB0byAxIGFjY29yZGluZyB0byB0aGUNCnNl Y3Rpb24gNC4yLjIuMTIgWzBdLg0KLSBmaXggZHQgbm9kZSBjb3BtYXJpbmcNCi0gbW92ZWQgY2hh bm5lbC0+c2htZW0gY2hlY2sgZnJvbSBBU1NFUlQgaW4gdW5tYXBfbWVtb3J5X2NoYW5uZWwgdG8N CiJpZiIgc3RhdGVtZW50LiBUaGlzIHdpbGwgcHJldmVudCBmaXJpbmcgQVNTRVJUIGlmDQp1bm1h cF9jaGFubmVsX21lbW9yeSB3YXMgY2FsbGVkIHR3aWNlIG9uIHRoZSBzYW1lIGNoYW5uZWwuDQoN CkNoYW5nZXMgaW4gdjg6DQotIGNoZWNrIGZvciBDT05GSUdfQVJNX1NDSSB0byBiZSBlYmFibGVk IGluc3RlYWQgb2YgQ09NRklHX0FSTSBiZWZvcmUNCmNhbGxpbmcgc2NpX2RvX2RvbWN0bA0KLSBy ZXdvcmsgc2NpX2RvX2RvbWN0bCBjYWxsIHRvIGF2b2lkIGV4dHJhIGNoZWNrcywgaW1wcm92ZWQg ZXJyb3INCmhhbmRsaW5nLg0KLSBkbyBub3QgcHJvcGFnYXRlIHJldDEgaWYgc2NpX2RvX2RvbWN0 bCByZXR1cm5lZCBwb3NpdGl2ZSByZXQNCi0gdXBkYXRlZCBjb21tZW50IGluIGRvbWN0bC5jIGNv ZGUNCi0gc3dpdGNoZWQgdG8gb3JkZXJlZCBhY2Nlc3NvcnMgdG8gYWRkcmVzcyB0aGUgb3JkZXJp bmcgYW5kIGJhcnJpZXINCmNvbmNlcm5zLg0KLSB1cGRhdGVkIHRoZSBkb2N1bWVudGF0aW9uIHRv IG1hdGNoIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgZXhwbGljaXRseQ0Kc3RhdGUgdGhlIHN1cHBv cnRlZCBhY2Nlc3Mgc2l6ZXMgYW5kIGdyYW51bGFyaXR5Lg0KLSByZW5hbWUgbWVtY3B5XyogaW1w bGVtZW50YXRpb24gZmlsZXMgdG8gbWVtY3B1LSogdG8gZm9sbG93IG5hbWluZw0KY29udmVuc2lv bg0KLSBmaXggaW5kZW50YXRpb24gdG8gbWF0Y2ggWGVuIHN0eWxlDQotIGZpeCBpbnRlbmRhdGlv biB0byBtYXRjaCBYZW4gc3R5bGUNCi0gbW92ZSBtZW1jcHkte2Zyb20vdG99aW8gdG8gbW9yZSBj b252ZW5pZW50IGxpYnJhcnkgcGxhY2UNCi0gdXBkYXRlIHhlbl9zY21pIGZ1bmNfaWQgaW4gY29t bWl0IGRlc2NyaXB0aW9uDQotIHVwZGF0ZWQgZG9jdW1lbnRhdGlvbiB3aXRoIHRoZSBuZXcgRFQg Zm9ybWF0DQotIHVwZGF0ZWQgb3B0X2RvbTBfc2NtaV9hZ2VudF9pZCBzZXR0aW5nIHRvIGF2b2lk IGl0IHRvIGJlIGVxdWFsDQpTQ01JX0FHRU5UX0lEX0lOVkFMSUQuDQotIGNoYW5nZWQgU0NNSV9B R0VOVF9JRF9JTlZBTElEIGZyb20gMHhmZiB0byBVSU5UOF9NQVggd2hpY2ggbWFrZXMNCmNvZGUg bW9yZSBjbGVhciBzaG93aW5nIHRoYXQgVUlOVDhfTUFYIGlzIHRoZWF0ZWQgbGlrZSBpbnZhbGlk DQphZ2VudF9pZCBhbmQgY291bGRuJ3QgYmUgdXNlZC4gQWxzbyBleGNsdWRlZCBTQ01JX0FHRU5U X0lEX0lOVkFMSUQNCmZyb20gYWNjZXB0YWJsZSB2YWx1ZSByYW5nZQ0KLSByZW1vdmUgb3V0ZGF0 ZWQgeGVuLGNvbmZpZyBwcm9wZXJ0eSBpZ25vcmUsIGFkZGVkIHhlbixzY2kgY29tcGF0aWJsZQ0K dG8gc2tpcF9tYXRjaGVzIGluIGhhbmRsZV9ub2RlDQotIGFkZCBkb2N1bWVudGF0aW9uIGZvciBw cmUtZXhpc3Rpbmcgc2NtaS1zbWMtcGFzc3Rocm91Z2ggY29tbWFuZCBsaW5lDQpvcHRpb24gaW4g YWxwaGFiZXRpY2FsbHkgY29ycmVjdCBsb2NhdGlvbiAoaW4gJ3MnIHNlY3Rpb24pDQotIGFkZCBu b3RlIHRvIGNvbW1pdCBkZXNjcmlwdGlvbiBhYm91dCBkb2N1bWVudGF0aW9uIGZvciBwcmV2aW91 c2x5DQp1bmRvY3VtZW50ZWQgc2NtaS1zbWMtcGFzc3Rocm91Z2gNCi0gRml4IFNNQyBJRHMgaW4g RFQgZXhhbXBsZXMgKFhlbiBtYW5hZ2VtZW50IHVzZXMgMHg4MjAwMDAwMywgRG9tMCB1c2VzIDB4 ODIwMDAwMDIpDQotIEFkZCBleHBsaWNpdCBub3RlIGV4cGxhaW5pbmcgd2h5IERvbTAgYW5kIFhl biBjaGFubmVscyBkbyBub3QgY29uZmxpY3QNCi0gRG9jdW1lbnQgZG9tMGxlc3MgbXVsdGktYWdl bnQgY29uZmlndXJhdGlvbiBleGFtcGxlICh4ZW4sc2NpX3R5cGUgLyB4ZW4sc2NpLWFnZW50LWlk KQ0KLSBBZGQgc2NtaV94ZW4gbm9kZSB0byBhZ2VudC1kaXNjb3ZlcnkgZXhhbXBsZSB3aXRoICNz Y21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMgPSAyDQotIERyb3AgZG9tMD1zY2ktYWdlbnQtaWQg Y29tbWFuZCBsaW5lIGhhbmRsaW5nOyBEb20wIFNDTUkgaXMgbm93IGVuYWJsZWQgdmlhDQogIHhl bixkb20wLXNjaS1hZ2VudC1pZCBpbiB0aGUgeGVuLHNjaSBEVCBjb250YWluZXINCi0gUmVmcmVz aCBkb2NzIGFuZCBleGFtcGxlcyB0byBtZW50aW9uIHRoZSBEVCBwcm9wZXJ0eSBpbnN0ZWFkIG9m IHRoZSBjbWRsaW5lIG9wdGlvbg0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiB0byBtYXRjaCB0aGUg bGFzdCBEVCBmb3JtYXQNCi0gZml4ZWQgUlNUOiAiLi4uIGNvZGUtYmxvY2s6OiBkdHMiIC0+ICIu LiBjb2RlLWJsb2NrOjogZHRzIg0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiB3aXRoIGRvbTBsZXNz IGNvbmZpZ3VyYXRpb24gZXhhbXBsZQ0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiB3aXRoIG5ldyBw YXJhbSB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQNCmluc3RlYWQgb2YgdGhlIGNvbW1hbmQgbGluZSBw YXJhbWV0ZXINCg0KQ2hhbmdlcyBpbiB2NzoNCi0gdXBkYXRlIGRvbWN0bCB0byBidWlsZCBvbiBi b3RoIEFybSBhbmQgeDg2IHBsYXRmb3Jtcw0KLSBtb3ZlIHJldDEgZGVjbGFyYXRpb24gdG8gdGhl IHRvcCBvZiB0aGUgZnVuY3Rpb24gYXMgcmVxdWlyZWQgYnkgY29kZQ0Kc3R5bGUNCi0geDg2IGd1 aWRhbmNlOiByZW1vdmVkIHRoZSBzcGVjdWxhdGl2ZSBub3RlOyBoZWFkZXIgbm93IGp1c3Qgc2F5 cw0KICBlYWNoIGFyY2ggc3VwcGxpZXMgaXRzIG93biBpbXBsZW1lbnRhdGlvbiBvciBtYWNyby4N Ci0gbmFtZSBzcGFjaW5nOiBkcm9wcGVkIHRoZSBkb3VibGUtdW5kZXJzY29yZTsgdGhlIGhlbHBl cnMgYXJlIG5vdw0KICBtZW1jcHlfZnJvbWlvIC8gbWVtY3B5X3RvaW8uIFRoZSBoZWFkZXIgYWxz byBleHBsaWNpdGx5IGFsbG93cyBhbg0KICBhcmNoIHRvIGRlZmluZSB0aGVzZSBhcyBtYWNyb3Mg YmVmb3JlIGluY2x1ZGluZyBpdC4NCi0gdXBkYXRlZCBpby5jIHRvIGtlZXAgMzItYml0IHRyYW5z ZmVycyBzYWZlIG9uIGFybTMyDQotIG1vdmVkIHRvIF9fcmF3X3JlYWQqL19fcmF3X3dyaXRlKiBh Y2Nlc3NvcnMgdG8gYXZvaWQgZW5kaWFubmVzcyBjb252ZXJzaW9uLg0KLSBzcGxpdCB0aGUgaGVs cGVycyBpbnRvIHNlcGFyYXRlIGNvbXBpbGF0aW9uIHVuaXRzDQotIHJld29yayBzY21pIG5vZGVz IGZvciB4ZW4gdG8gbWF0Y2ggb24gY29tcGF0aWJsZSBzdHJpbmcgaW5zdGVhZCBvZg0KdGhlIGRp cmVjdCBwYXRoDQotIHVwZGF0ZSBkb2N1bWVudGF0aW9uIGluIHNlY3Rpb24gb2YgdGhlIHhlbl9z Y21pIGNvbmZpZ3VyYXRpb24gd2hpY2gNCmlzIG1hdGNoZWQgYnkgInhlbixzY2kiIGNvbXBhdGli bGUgaW5zdGVhZCBvZiB0aGUgZGlyZWN0IHBhdGguDQoNCkNoYW5nZXMgaW4gdjY6DQotIGNoYW5n ZSBpb21tdV9kb19kb21jdGwgYW5kIHNjaV9kb19kb21jdGwgY29tbWFuZCBvcmRlciBhbmQNCmNh bGwgc2NpX2RvX2RvbWN0bCBmaXJzdCB3aGljaCB3aWxsIHByb2R1Y2UgY2xlYW5lciBjb2RlIHBh dGguDQpBbHNvIGRyb3BwZWQgY2hhbmdpbmcgcmV0dXJuIGNvZGUgd2hlbiBpb21tdSB3YXMgZGlz YWJsZWQgaW4NCmlvbW11X2RvX2RvbWN0bC4NCi0gc29ydGVkIG9ianMgaW4gTWFrZWZpbGUgYWxo YWJldGljYWxseQ0KLSBhZGRlZCBuZXdsaW5lIGF0IHRoZSBlbmQgb2YgTWFrZWZpbGUNCi0gdXNl ZCB1aW50e059X3QgaW50ZWFkIG9mIHV7Tn0NCi0gYWRkIGNvbW1lbnQgYWJvdXQgd2h5IDMyIGJp dCBJTyBvcGVyYXRpb25zIHdlcmUgdXNlZA0KLSB1cGRhdGVkIGNhc3Qgb3BlcnRhaW9ucyB0byBh dm9pZCBkcm9wcGluZyBjb25zdG5lc3Mgd2hpY2ggaXMgd3JvbmcNCi0gbW92ZSBmdW5jdGlvbiBk ZWZpbml0aW9ucyB0byBnZW5lcmljIHBsYWNlIHNvIHRoZSBjb3VsZCBiZSByZXVzZWQgYnkNCm90 aGVyIGFyY2gNCi0gYWRkIFNQRFggdGFnIHRvIGlvLmMNCi0gdXBkYXRlZCBzY21pLXNobWVtIHRv IHVzZSBpby5oIGZyb20gZ2VuZXJpYyBsb2NhdGlvbg0KLSB1cGRhdGUgc2NtaV9hZ2VudF9pZCBw YXJhbWV0ZXIgdG8gYmUgcHJvdmlkZWQgaW5zaWRlIGRvbTA9IHBhcmFtZXRlcg0KbGlzdCBhbmQg aGF2ZSB0aGUgZm9sbG93aW5nIGZvcm1hdCAiZG9tMD1zY2ktYWdlbnQtaWQ9MCINClRoaXMgY2hh bmdlIHdhcyBkb25lIGFzIGEgcmVzcG9uc2UgZm9yIFN0ZWZhbm8gY29tbWVudCBhbmQNCnJlcXVp cmVzIGEgbG90IG9mIGNvZGUgY2hhbmdlcywgYnV0IHByb2R1Y2VzIG11Y2ggY2xlYW5lciBzb2x1 dGlvbg0KdGhhdCdzIHdoeSBJJ3ZlIGFkZGVkIGl0IHRvIHRoZSBjb2RlLg0KLSBmaXggZmlsZSBj b21tZW50cyBhbmQgcmV0dXJuIGNvZGVzDQotIGZpeCBsZW5naHQgY2hlY2tzIGluIHNobWVtX3tn ZXQscHV0fV9tZXNzYWdlIHRvIHVzZSBvZmZzZXRvZg0KLSByZW1vdmUgbGVuIG1lbWJlciBmcm9t IHNjbWlfY2hhbm5lbCBzdHJ1Y3R1cmUgYXMgaXQgaXMgbm90IHVzZWQNCi0gc2V0IHNjbWktc2Vj b25kYXJ5LWFnZW50cyBwcm9wZXJ0eSB0byBiZSBtYW5kYXRvcnkgc2luY2UgaWYgbm8NCnNlY29u ZGFyeSBhZ2VudHMgd2VyZSBwcm92aWRlZCB0aGVuIHRoZXJlIGlzIG5vIHNlbmNlIHRvIGVuYWJs ZSBzY21pDQp3aGVuIG5vIHNlY29uZGFyeSBhZ2VudHMgYXJlIHBvcHVsYXRlZCB0byB0aGUgRG9t YWlucw0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiBpbiBib290aW5nLnR4dCwgYWRkZWQgeGVuX3Nj bWkgbm9kZSB0byB0aGUNCmV4YW1wbGUNCi0gYWRqdXN0IGQtPmFyY2guc2NpX2VuYWJsZWQgdmFs dWUgaW4gc2NtaV9kb21haW5fZGVzdHJveQ0KLSBmaXggbG9jayBtYW5hZ2VtZW50IGluIHNtY19j cmVhdGVfY2hhbm5lbCBjYWxsDQotIGF2b2lkIGV4dHJhIG1hcF9jaGFubmVsX21lbW9yeSBjb21t YW5kIGZvciBYZW4gbWFuYWdlbWVudCBjaGFubmVsDQpiZWNhdXNlIGNvbGxlY3RfYWdlbnRfaWQg Y2FsbCB1bm1hcHMgbWVtb3J5IGlmIERPTUlEX1hFTiBpcyBub3QNCnNldC4gU28gZm9yIFhlbiBt YW5hZ2VtZW50IGNoYW5uZWwgd2UgY2FuIGluaXQgZG9tYWluX2lkIGFkIERPTUlEX1hFTg0KYmVm b3JlIGNhbGxpbmcgY29sbGVjdF9hZ2VudF9pZCBzbyBtZW1vcnkgc2hvdWxkbid0IGJlIHVubWFw cGVkLg0KLSByZW1vdmUgYWxsIEhWQyBtZW50aW9ucyBmcm9tIHRoZSBtdWx0aS1hZ2VudCBkb2MN Ci0gdXBkYXRlIHNjaS1hZ2VudC1pZCBwYXJhbWV0ZXIgZGVzY3JpcHRpb24gaW4gdGhlIGRvY3Vt ZW50YXRpb24NCi0gYWRkIG1pc3NpbmcgU2lnbi1vZg0KLSBtaW5vciBmaXhlcyBhY3Jvc3MgdGhl IGRvY3VtZW50DQoNCkNoYW5nZXMgaW4gdjU6DQotIHJldHVybiAtRUlOVkFMIGlmIG1lZGlhdG9y IHdpdGhvdXQgYXNzaWduX2R0X2RldmljZSB3YXMgcHJvdmlkZWQNCi0gaW52ZXJ0IHJldHVybiBj b2RlIGNoZWNrIGZvciBpb21tdV9kb19kb21jdGwgaW4NClhFTl9ET01DVExfYXNzaWduX2Rldmlj ZSBkb21jdGwgcHJvY2Vzc2luZyB0byBtYWtlIGNsZWFuZXIgY29kZQ0KLSBjaGFuZ2UgLUVOT1RT VVBQIGVycm9yIGNvZGUgdG8gLUVOWElPIGluIHNjaV9kb19kb21jdGwNCi0gaGFuZGxlIC1FTlhJ TyByZXR1cm4gY29tZGUgb2YgaW9tbXVfZG9fZG9tY3RsDQotIGxlYXZlICFkdF9kZXZpY2VfaXNf cHJvdGVjdGVkIGNoZWNrIGluIGlvbW11X2RvX2R0X2RvbWN0bCB0byBtYWtlDQpjb2RlIHdvcmsg dGhlIHNhbWUgd2F5IGl0J3MgZG9uZSBpbiAiaGFuZGxlX2RldmljZSIgY2FsbCB3aGlsZQ0KY3Jl YXRpbmcgaHdkb20oZG9tMCkgYW5kICJoYW5kbGVfcGFzc3Rocm91Z2hfcHJvcCIgY2FsbCBmb3Ig ZG9tMGxlc3MNCmNyZWF0aW9uDQotIGRyb3AgcmV0dXJuIGNoZWNrIGZyb20gc2NpX2Fzc2lnbl9k dF9kZXZpY2UgY2FsbCBhcyBub3QgbmVlZGVkDQotIGRvIG5vdCByZXR1cm4gRUlOVkFMIHdoZW4g YWRkaWduX2R0X2RldmljZSBpcyBub3Qgc2V0LiBUaGF0IGlzDQpiZWNhdXNlIHRoaXMgY2FsbGJh Y2sgaXMgb3B0aW9uYWwgYW5kIG5vdCBpbXBsZW1lbnRlZCBpbiBzaW5nbGUtYWdlbnQgZHJpdmVy DQotIG1vdmUgbWVtY3B5X3RvaW8vZnJvbWlvIHRvIHRoZSBnZW5lcmljIHBsYWNlDQotIGZpeCBk ZXZpY2UtdHJlZSBleGFtcGxlIGZvcm1hdCBpbiBib290aW5nLnR4dCwgYWRkZWQgIjsiIGFmdGVy ICJ9Ii4NCi0gdXBkYXRlIGRlZmluZSBpbiBzY21pLXByb3RvLmgNCi0gdXBkYXRlIGRlZmluZSBp biBzY21pLXNobWVtLmggZmlsZQ0KLSBzY21pX2Fzc2lnbl9kZXZpY2UgLSBkbyBub3QgaWdub3Jl IC1FT1BOT1RTVVBQIHJldHVybg0KY29kZSBvZiB0aGUgZG9fc21jX3hmZXINCi0gcmVtb3ZlIG92 ZXJ3cml0aW5nIGFnZW50X2NoYW5uZWwtPmFnZW50X2lkIGFmdGVyDQpTQ01JX0JBU0VfRElTQ09W RVJfQUdFTlQgY2FsbA0KLSBhZGQgbXVsdGktYWdlbnQgZmlsZXMgdG8gdGhlIE1BSU5UQUlORVJT DQotIGFkZCBTQ01JIG11bHRpLWFnZW50IGRlc2NyaXB0aW9uIHRvIHRoZSBTVVBQT1JULm1kDQot IGhhbmRsZSBBUk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVURVIgcmV0dXJuIGNvZGUgYW5kIHJldHVy biAtRUlOVkFMDQpmb3Igc21jIGNhbGwNCi0gdXBkYXRlZCBjb2xsZWN0X2FnZW50cyBmdW5jdGlv bi4gU2V0IGFnZW50X2lkIHBhcmFtZXRlciBhcyBvcHRpb25hbA0KaW4gc2NtaS1zZWNvbmRhcnkt YWdlbnRzIGRldmljZS10cmVlIHByb3BlcnR5DQotIGludHJvZHVjZSAiI3NjbWktc2Vjb25kYXJ5 LWFnZW50cy1jZWxscyIgcGFyYW1ldGVyIHRvIHNldCBpZg0KYWdlbnRfaWQgd2FzIHByb3ZpZGVk DQotIHJlYW5tZSB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIHByb3BlcnR5IHRvIHNjbWktc2Vj b25kYXJ5LWFnZW50cw0KLSBtb3ZlIG1lbWNwdV90b2lvL2Zyb21pbyBmb3IgdGhlIGdlbmVyaWMg cGxhY2UNCi0gdXBkYXRlIFhlbiB0byBnZXQgbWFuYWdlbWVudCBjaGFubmVsIGZyb20gL2Nob3Nl bi94ZW4sY29uZmlnIG5vZGUNCi0gZ2V0IGh5cGVydmlzb3IgY2hhbm5uZWwgZnJvbSBub2RlIGlu c3RlYWQgb2YgdXNpbmcgaGFyZGNvZGVkDQotIHVwZGF0ZSBoYW5kbGluZyBzY21pIGFuZCBzaG1l bSBub2RlcyBmb3IgdGhlIGRvbWFpbg0KLSBTZXQgbXVsdGktYWdlbnQgZHJpdmVyIHRvIHN1cHBv cnQgb25seSBBcm02NA0KLSByZXdvcmsgbXVsdGktYWdlbnQgZHJpdmVyIHRvIGxlYXZlIEhvc3Qg RGV2aWNlLXRyZWUgdW5tb2RpZmllZA0KDQpDaGFuZ2VzIGluIHY0Og0KLSB0b29sc3RhY2sgY29t bWVudHMgZnJvbSBBbnRob255IFBFUkFSRA0KLSBhZGRlZCBkb20wbGVzcyBzdXBwb3J0DQotIGFk ZGVkIGRvYyBmb3IgInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiDQoNCkdyeWdvcmlpIFN0cmFz aGtvICgyKToNCiAgeGVuL2RvbWN0bDogY2hhaW4gU0NJIGhhbmRsaW5nIGJlZm9yZSBJT01NVSBp biBhc3NpZ25fZGV2aWNlIGRvbWN0bA0KICBkb2NzOiBhcm06IGFkZCBTQ0kgU0NNSSBTTUMgbXVs dGktYWdlbnQgZHJpdmVyIGRvY3MNCg0KT2xla3NpaSBNb2lzaWVpZXYgKDQpOg0KICB4ZW46IGFy bTogc21jY2M6IGFkZCBJTlZBTElEX1BBUkFNRVRFUiBlcnJvciBjb2RlDQogIGxpYi9hcm06IEFk ZCBJL08gbWVtb3J5IGNvcHkgaGVscGVycw0KICB4ZW4vYXJtOiBzY21pOiBpbnRyb2R1Y2UgU0NJ IFNDTUkgU01DIG11bHRpLWFnZW50IGRyaXZlcg0KICB0b29scy94bC9saWJ4bDogd2lyZSB1cCBT Q01JIFNNQyBtdWx0aS1hZ2VudCBjb25maWd1cmF0aW9uDQoNCiBNQUlOVEFJTkVSUyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKw0KIFNVUFBPUlQubWQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMSArDQogLi4uL2FybS9maXJtd2FyZS9hcm0t c2NtaS5yc3QgICAgICAgICAgICAgICAgIHwgNDA1ICsrKysrKysrKw0KIGRvY3MvbWFuL3hsLmNm Zy41LnBvZC5pbiAgICAgICAgICAgICAgICAgICAgICB8ICAxMyArDQogZG9jcy9taXNjL2FybS9k ZXZpY2UtdHJlZS9ib290aW5nLnR4dCAgICAgICAgIHwgMTk1ICsrKysrDQogdG9vbHMvaW5jbHVk ZS9saWJ4bC5oICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA4ICsNCiB0b29scy9saWJzL2xp Z2h0L2xpYnhsX2FybS5jICAgICAgICAgICAgICAgICAgfCAgMTMgKw0KIHRvb2xzL2xpYnMvbGln aHQvbGlieGxfdHlwZXMuaWRsICAgICAgICAgICAgICB8ICAgNCArLQ0KIHRvb2xzL3hsL3hsX3Bh cnNlLmMgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAyNyArDQogeGVuL2FyY2gvYXJtL01h a2VmaWxlICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAxICsNCiB4ZW4vYXJjaC9hcm0vYXJj aC5tayAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKw0KIHhlbi9hcmNoL2FybS9kb20w bGVzcy1idWlsZC5jICAgICAgICAgICAgICAgICB8ICAxNyArDQogeGVuL2FyY2gvYXJtL2RvbWFp bl9idWlsZC5jICAgICAgICAgICAgICAgICAgIHwgIDQzICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdh cmUvS2NvbmZpZyAgICAgICAgICAgICAgICAgfCAgMTIgKw0KIHhlbi9hcmNoL2FybS9maXJtd2Fy ZS9NYWtlZmlsZSAgICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJl L3NjaS5jICAgICAgICAgICAgICAgICAgIHwgIDM2ICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUv c2NtaS1wcm90by5oICAgICAgICAgICAgfCAxNjQgKysrKw0KIHhlbi9hcmNoL2FybS9maXJtd2Fy ZS9zY21pLXNobWVtLmMgICAgICAgICAgICB8IDExOCArKysNCiB4ZW4vYXJjaC9hcm0vZmlybXdh cmUvc2NtaS1zaG1lbS5oICAgICAgICAgICAgfCAgNDUgKw0KIHhlbi9hcmNoL2FybS9maXJtd2Fy ZS9zY21pLXNtYy1tdWx0aWFnZW50LmMgICB8IDc5MiArKysrKysrKysrKysrKysrKysNCiB4ZW4v YXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmggICAgICAgfCAgIDggKw0KIHhlbi9h cmNoL2FybS9pbmNsdWRlL2FzbS9zbWNjYy5oICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2Fy Y2gvYXJtL2xpYi9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgIHwgICAyICsNCiB4ZW4vYXJj aC9hcm0vbGliL21lbWNweS1mcm9taW8uYyAgICAgICAgICAgICAgfCAgNTYgKysNCiB4ZW4vYXJj aC9hcm0vbGliL21lbWNweS10b2lvLmMgICAgICAgICAgICAgICAgfCAgNTYgKysNCiB4ZW4vY29t bW9uL2RvbWN0bC5jICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMTUgKw0KIHhlbi9kcml2 ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMgICAgICAgICB8ICAgNiArDQogeGVuL2luY2x1 ZGUvcHVibGljL2FyY2gtYXJtLmggICAgICAgICAgICAgICAgIHwgICA1ICstDQogeGVuL2luY2x1 ZGUveGVuL2lvLmggICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDI1ICsNCiAyOSBmaWxlcyBj aGFuZ2VkLCAyMDc5IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pDQogY3JlYXRlIG1vZGUg MTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3RvLmgNCiBjcmVhdGUgbW9kZSAx MDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KIGNyZWF0ZSBtb2RlIDEw MDY0NCB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5oDQogY3JlYXRlIG1vZGUgMTAw NjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMNCiBjcmVhdGUg bW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2xpYi9NYWtlZmlsZQ0KIGNyZWF0ZSBtb2RlIDEwMDY0 NCB4ZW4vYXJjaC9hcm0vbGliL21lbWNweS1mcm9taW8uYw0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4 ZW4vYXJjaC9hcm0vbGliL21lbWNweS10b2lvLmMNCg0KLS0gDQoyLjQzLjANCg0KYmFzZS1jb21t aXQ6IGFhNzNhMWI5OTMwOWYyMmQ5YmJjMjYwM2QxYjIwNmU3Mjk4ZDk0NzMNCmJyYW5jaDogc2Nt aV9tYV91cHN0cnYxNA== From xen-devel-bounces@lists.xenproject.org Tue Oct 20 08:43:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455151.1668707 (Exim 4.92) (envelope-from ) id 1xJ5RQ-0005yX-2R; Tue, 20 Oct 2026 08:43:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455151.1668707; Tue, 20 Oct 2026 08:43: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 1xJ5RP-0005xb-SK; Tue, 20 Oct 2026 08:43:27 +0000 Received: by outflank-mailman (input) for mailman id 1455151; Tue, 20 Oct 2026 08:43:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5RN-0005XV-QI for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:43:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5RN-00EVzr-6b for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:43:25 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad729ac-e002-0a2a0a5209dd-0a2a4503caa8-14 for ; Tue, 20 Oct 2026 10:43:25 +0200 Received: from [52.101.84.117] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad729ab-fae8-0a2a45030019-3465547526e8-5 for ; Tue, 20 Oct 2026 10:43:24 +0200 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by AS8PR03MB8395.eurprd03.prod.outlook.com (2603:10a6:20b:527::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:43:22 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 08:43: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=WWLEbNFvHsvyTzY+BxmQi+u8B+cqiRuy6ZfXN9BSOrS2Zd7otsnjz4sf0rzihBNzfA2z763/RP4TMuJs1Elnr6B7yH5VeuMRnLcNyZHpZJinZ5sosN2lzdzOIyamHOGbLzYs82Mhj0IuUdYLbFhHUqPSKUi2LapNJ62wH/EV77pS8+rXTIvF77Ib4L6QornHqbPhnraOsWI5xp3Pp1CdJBda7KJnxPTGfDVKxEnHVfzS1SReRX1AVJ+ALQQxTTTmUM3OI1phaOEJV2jFAiXesgzK3OpwvT/hQjoQfMxyp7GLwLycGRCGbRrsVssSDP5NAUmaZqvA24JxLN4IqDaTSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Fgg9cHMriHhGOg+Y24vzMOHf2dI+HJEpVRu9jm6g36M=; b=kTFC7mIPmbOXDfn/1SdpaLRxG6B+x8HeJdDU3Yl4J8UsGjgezpJ7gnlOWB1PMglj7kqSZ0hly9gs786FXfJhYUtYfXcp4ytz7SlbdXDWYyFnewmxp3zic1bjCpDqiPGQ0vLXhNa9A9LlJdT2kVZwgcCiJ4DNDdyHxDbN12nCmRKvqLhSekF47TxTMuUWc1gVlN8ehnln62hY0jih5MIhUVm2q6oOSAUMVIi0fo0f9dxkgTQAvDszJgY0LcVIdHTvZHtT853lXnSiXOIScikIXKMQB55KpZ4Ajp1hxs0J97QMDp7aF93V3kVbilwS3ST0uYfAjNEj0w0jnJzG/vEfPw== 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=Fgg9cHMriHhGOg+Y24vzMOHf2dI+HJEpVRu9jm6g36M=; b=dVnLZmbNNYHJnehvAR1QAbFQFVwEbmLZ4WdCscWRqcGD7fPL9qQOFfQN0JGElwnDeLLqK+up9A7w6X2Z/itCrKyt9l9/B/ed3yL1wyYvbUnnOaT/J2uJ0KdJ8WX81MLHny4nwK5Lk9oFwEtuGKF/D2qmf6R8fenlJF1/N3hDQt8f4xrMRg1Z7huOgzTz9OS1CiJI3l1Um92qN0P2ymeM+XRFxkU5F8FBshNW43T3rzZNNrYT4pxd0AfM7D/vO1F9jwgwbmLXvCyBqTLMsv+APVQWGE/DyO5IudJMlatT6hfdDVevfZPb3LB4UUoZDBicXjE2kmRXSpbupwp8rHptoQ== 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 Subject: [PATCH v14 3/6] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v14 3/6] lib/arm: Add I/O memory copy helpers Thread-Index: AQHdYG8PNqq9SzC3aUiu3lmAtwvgnQ== Date: Tue, 20 Oct 2026 08:43:20 +0000 Message-ID: <31deb8be49033aa8d2f1940f69ad4cba362f6e91.1792485704.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: 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: GVXPR03MB11113:EE_|AS8PR03MB8395:EE_ x-ms-office365-filtering-correlation-id: 29e2f592-4d6d-4065-6431-08df2e863295 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|7416014|18002099003|22082099003|3023799007|260925022911599003|38070700021|260925021911599003|11063799006|10067099003|261009223027099003|260925021311599003|56012099006; x-microsoft-antispam-message-info: Q7jh2HbBsIizKlQUcDivvRHw5oORzPCIWY1uXZ7hNJUq6BHYScLdpqqm7UNOD7ggTU1tsUxYhAHn8R6xf9F/bqCGuJ//XLCyJuxrJQSCUw9FTbOiNsG6cADKTEU9/gwqIYqaq6kM6oO7aHrhaQvEkBjt/OUC8X2flh72wl0HeKDwjKJ+P0T16kekr8+WmZhqHtRakyvBdxXYkJbaOuzkpJr5MOWuHV+mncZGSU7uaKrskwf6Ld996z1czlrfv9TR0xMinikVoNE0qHZyADAyU6+nRjlWSBkf8R5FTUBSP3o3rtIkQ2zcmbq/YONGaWuq6/sAjhCsTwkvtAgQUXgunaR6xPCq92/ZhwhqjxZ7owJnA4P6orRoySejfBqdB2I+WcqdOnpWcTqdpK6SLgTNhwPAciJZWxe7/SXPIT3I2zKy8j5t8gPqzoLx8AgEFvHmzO+0AGHlRxLeCcSSgQ94CfwGg4m91f8RCgzzsBlevYnHv7LXNx9yL2RDAFxqzLw37jXpAIQZiiMKEmMvIPE7HueFLrjNEC4E9EU9wVoaXYliHp/DNBoJEm3WiUbrDxyDctoVoH7DW+Pbkbwk2koGKYxP0/6oyHJvDXKPlaRku/UmmdmwTducaYJuTWA+ojKTgNghOkP578baJ7iqQmYnDHb4KMOJPFEAjPxiEO7Os1Pl1aP6P2ORIS9YE4xGATktE9ZqjIU+USMyzYlf2d0W0ZFRUDTEbzuMtGboLsbv0tk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(7416014)(18002099003)(22082099003)(3023799007)(260925022911599003)(38070700021)(260925021911599003)(11063799006)(10067099003)(261009223027099003)(260925021311599003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?xD508+bxmvAtzqrKuLZYnvPItC4wjksPnpGxmaTW9zeXOEMRvpZRNzMjKQ?= =?iso-8859-1?Q?A4kvLvESgXOEasX9eDMjiatmL9DMOUQg3vvsPiOLvdv45HEbwF/COM4mB0?= =?iso-8859-1?Q?903a1Vi5wzgQ+lHNGGfB0WPdfLDV3+XyPU+5ZDnXl5zFPT7TYIcTAhdJFl?= =?iso-8859-1?Q?ziFLR63Q5Eo32UBbvnggX7WpRNoMZaOX4oTq2R7w8JFFoJ3PDeutOdiWp2?= =?iso-8859-1?Q?83fvgDET4smI98GQoWkNVWJWhtTKHwYHXDG3W6Yj32rP4TTUOd6KaIyvtx?= =?iso-8859-1?Q?OyAuDYM/GK7CK4JAupsg8Jrn3FJFR9O41AC41NzVo1qPK1BUdgFvtlxqrN?= =?iso-8859-1?Q?KiEvROcFwnhYce2u29PxqFOijlHpqNMkXOFj6KX3PnN3+34mzIJiWJ1Gjd?= =?iso-8859-1?Q?uemPvO/tL8MAH/X7Kpnt5PLTahd1dEjcqjITnYRqvKNSLGRkho7A//4SKH?= =?iso-8859-1?Q?126yR9h6ITD/PS02AVtmfM96d+Dgu+KTydNIHkNe32l23uUai7SFdS2YIc?= =?iso-8859-1?Q?cCljL3jdWApJxR/3y0sq2YUim/09w6zJVQ2nnmgdm3bNIyP23w+xd3lOWO?= =?iso-8859-1?Q?6mHF1wkb4turtYUtDLjMRQGY9R+vHjwV/3RoGo/f7m09bEU+fANbui3TtO?= =?iso-8859-1?Q?hoU/4WdFu+DKA83QeG7Y+Mt0lPvItgs7LyDVfQ4LSIdIussp/Z2exMCr7Y?= =?iso-8859-1?Q?6KxlzjbNdlcXZkR6/tmmXYNeyUNQlQsJH0c9Tc83A8lzE4JRAa76nQUFCn?= =?iso-8859-1?Q?iDpM812lXgNHrBNj9NTvfJVPJFntYRsnNPEnHwD3olOx2bCpPCXB+3SUPC?= =?iso-8859-1?Q?NeHtRPnD75+DaXBJErBqJIxQ+0vxTGbfAZKeghuidXlBJVzQszkvv9lz9P?= =?iso-8859-1?Q?19620RGMNNhB92HpT6kX0pgWsTiJ0huAjF1lv1i8v6tMlXysd1JLETQllu?= =?iso-8859-1?Q?gy3hOSWM4JbvtXZh81j1HlRIWP966Z7+WvaMUXTMoggRDzZzobMwKbGAdT?= =?iso-8859-1?Q?gX8Z0OBZpxmC7eTOlvTEA7gcktmnfwEatHK7VGCl+Bit7CKg9RTytc8eFN?= =?iso-8859-1?Q?DsmV15Fnptf0Nmg75HuGsdPgy6X5VYwCeqtumYCcuCV9JuyE/mTG0M44LC?= =?iso-8859-1?Q?rTkl6yUEW9vt4u5rgee94ZYFSrwtkuKK/6EzfjCXBnmkqef1lAwaug5g0L?= =?iso-8859-1?Q?yBh8qCqeg0M9gaWe/GsSMLp6d4ZV2hrr/oHpM+DKPNjkYUC3zSRG6YgwVY?= =?iso-8859-1?Q?1dMN9EcxOT1uHHPqesBRkhorfd9lNdK6sHZTl0KzyN9A5jAhPZK2OZ/REM?= =?iso-8859-1?Q?FH6uJnXgaGEE+hh0pai5ZocTgAco32X8htlO/jf6ACYDzYi1gbZOamFGl2?= =?iso-8859-1?Q?LPxBWQv6ax2Hm0AJQSZv0aR8TslBOjfdU9Ucj/J0yj+PStIeKDliDuM6Oe?= =?iso-8859-1?Q?jnfJsUr2dKcG9bsWRO9tQNkEn81i7VofJ5KuiD4YR0Vg5q7LLWlBFjOX7E?= =?iso-8859-1?Q?vpLAxDwCX22J0scPEnhTExqW+wz5Arhi4SlO3TA6S8xLH8GdeyKac6r0A4?= =?iso-8859-1?Q?ALcRTLXPdJIWRt7jhgJ+WALM/JuCU1n5MmdnzM/5FCXZXCQi4Hth6tkTpp?= =?iso-8859-1?Q?E9Yt8jPjx7AiAiQUS/x78Rn+YGS4MyUzO75LvSmHu81M0Cj9dkIpWmeWWZ?= =?iso-8859-1?Q?JZALFJiXP3DUQbUvbLJIvOO9hKijFKA7sdyiSffavZI7j8u7zyWrbIdXDb?= =?iso-8859-1?Q?FCPrevN0yZuLC/QeZ11Oh1DS11wc8xFfxIRQ8U2tGid5RMdFS2bdX2J/Ub?= =?iso-8859-1?Q?zmRS6yngGTnR8Cggid9MYOzC/oHURbA=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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29e2f592-4d6d-4065-6431-08df2e863295 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 08:43:20.4236 (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: hQiimm0RlmdcHH6lj1nrex9Gy6DDnBP8NU9y4YWn/dCunyEVrOYlmVQwdKCL5DzY4RIvHQwtgtgxTMcuY8eJqGl8UclB5ybayCIhgtdgPyg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8395 X-purgate-ID: tlsNG-33051d/1792485804-75EFF4E9-FBAFD980/0/0 X-purgate-type: clean X-purgate-size: 10172 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 --- (no changes since v13) 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 cdcec8cd03..ba61f9e5fd 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 Oct 20 08:43:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455152.1668712 (Exim 4.92) (envelope-from ) id 1xJ5RQ-00064T-D7; Tue, 20 Oct 2026 08:43:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455152.1668712; Tue, 20 Oct 2026 08:43: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 1xJ5RQ-00062D-4l; Tue, 20 Oct 2026 08:43:28 +0000 Received: by outflank-mailman (input) for mailman id 1455152; Tue, 20 Oct 2026 08:43:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5RO-0005Xf-85 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:43:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5RN-00EVzr-Kx for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:43:25 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad729ac-e002-0a2a0a5209dd-0a2a4503caa8-18 for ; Tue, 20 Oct 2026 10:43:25 +0200 Received: from [52.101.84.117] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad729ab-fae8-0a2a45030019-3465547526e8-6 for ; Tue, 20 Oct 2026 10:43:25 +0200 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by AS8PR03MB8395.eurprd03.prod.outlook.com (2603:10a6:20b:527::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:43:22 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 08:43: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=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=wl9/kYlMAQYUbhvSWtuAc899cPlI0iN4Rs/REI6UZ4cr8pgzY+JtlKqBc16+cjyZBW2W3NzkrBHuphzN6UXl2j1D653RypnU43cA8qnGHM+3vowazwuwkRslxXPKwH0OF3gu7O4+FaFHROLc7ueGnENqmY09wqxxpLj04tscs+evg/8pF+Aq9hC0z1lKx5RFK5IINhTH8K4sLjLicpe9ldstY9dLSvPdN4Kb4kH7XL5aytwI+OJxiekAtfupWYAe3WANYu7n2lhx5LyLRsvW4l+VBY06rbwRsmdparP83tAjV2179muuKX8FP76dx3KHlSkfuD8FQzU34eZ2uURDAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3DYIXbzLMR33EgXn2802OVqeBnV2sN4/5SZ9JohGO9E=; b=orHoBcT4W0S6snqnRv+IfaspqSmB15Ls0MhaFjr7r/JAhq99DsqUqAIbXzUshUmqsDFSkhyorxZXYLD1RYU9hK/Lw/OnGWrAANAjVG2TZhxSo0lvhgVrwOj4ta/IBff/0psqdBS1sWhJDuP7+J30aIWJwbNG8JW/ZNxXTpjrQ5hoOW9hxn0VYx8kV/G6j1kv9WhRKLXZ7QGfzZjSGN+Aq3ZqYXKXZhUbBGkAmWTp0sQj1O4o9UJlxvFL0EwTPW8yPMrMFG5dpaUYBpO+Rx/XQjnJmRqg3Z88IGekkSwDg56fYTZwb1okEVe/2wJcIMbveEcj9PLRMwN+r5CfO60epg== 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=3DYIXbzLMR33EgXn2802OVqeBnV2sN4/5SZ9JohGO9E=; b=C0LvN0f6E9GcNiukJe14i5nHMdWiWqrbHEkbKGiWxQ7fLDQhF8F/fRse1UsahAIExtaxV/nsCE2O3nKUY/2eoDjczgUAdR98vcxOFe8JLshgESmOSBIKaH2gH0p5d9hoSh445S9229CdqxKRPSrA8UwA3dRZmOWZuFCU3OnFq6vjyDS5cAeBZcqJhk8ljWacV1WJjzSG8PATHQAfSmB2f8Hp1tgZ7m40T1f3yoDtC1K0mzHrPOpbR6zX3flWwPkDWnOTmdwDn+sRpkoI/2Dlto/NBt1diAeF2gQcb5f+z1oyMYWKscnFWMPIFVMrBtKLLRGADpVwXLNG/fEICeyQ2g== 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 v14 5/6] tools/xl/libxl: wire up SCMI SMC multi-agent configuration Thread-Topic: [PATCH v14 5/6] tools/xl/libxl: wire up SCMI SMC multi-agent configuration Thread-Index: AQHdYG8PVPoz1quH8USwCU7AQlcM3Q== Date: Tue, 20 Oct 2026 08:43:21 +0000 Message-ID: <4f863f8c656a41dec40274cd5cb504896a060880.1792485704.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: 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: GVXPR03MB11113:EE_|AS8PR03MB8395:EE_ x-ms-office365-filtering-correlation-id: 3fcda0df-43c1-4cf8-56c6-08df2e863304 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|7416014|6133799003|18002099003|22082099003|38070700021|11063799006|10067099003|261009223027099003|56012099006; x-microsoft-antispam-message-info: v9c6j76NzP1FZTOMEj8VITSJhM+3TH5VOG1C7gDm4hnJGFQRC/qZ+11Q0X2RDWEhEvT75xkrd11H2CCCMmT6zENo9dLF2ndQyrHHsf/jnb5g8J0o+P6AUXW0t8AEXzNCX3CuEzm/L2Xxx2HEoM6SL8BAubeoiig6jbyzTqI8C++F+dXRvK85mOhE/NGcnLFwx7uNw+gNFDTl9Md3ByOh6uap+6Bz7nl/M2yb6RxaY6idhfQJpMyG+al34vw1d7qTvKdBhHDY1dslYsZ/12GH8EZ9pWGMwf4u3rplGipNurq2VPdVTUiB3gXFYmgsflGjJJDGP7gTtpsmI9V0jEsC8zdHhbMK/d6HypXarQGHAfta6NqkGKqBmWheUazk20UHcJXz6zaxdLHbmVqhKXpd0+6rYixzJ5P2W6BgGfxuP4BhYuyH31hvBRgeQtpcicFFv+/LjFhGH34ZKxeZv19resrXej2Lj0jkV7LJogGgD/Vvkjj1EnKPYf46WUXYvLd045stcvWU7dAntT4+1TSk7dyfDqy/AezQB1aKBYhG/17YOqIacF/HUM0ipgpsAuBxohQeRh9fQK/nYi53sVLUsrBgqUhZfYvGVtedjWABpc5NLF3NL/zmL6NSuC5w8LnOmXOZ62XBaBAOW509J7Ggez+Ckh9UMRJi9hIOGntCT+flS6q2viE3ginH6s5t3B9RJkd012Ua9BUIbkk3YQAtRlcRp/tP3of0FJhE/9T7s98= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(7416014)(6133799003)(18002099003)(22082099003)(38070700021)(11063799006)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?vzq2327vxp71ZctARHZ5QeGzCJsWlUkBjz0uvK8ufw3xSXe5pK4jIBmdS3?= =?iso-8859-1?Q?ypx28L8eJY5gpSyYkcAXImqovDe448IGEdZfY286xtX4IYHUMNcAShc6yC?= =?iso-8859-1?Q?XgG2IsbcRJ/w86BdnOvD89kn+cSHr6/34yBJpEOJlvAJmxx1dmJYhDtW/k?= =?iso-8859-1?Q?ZcrU3y+uHVtLPm1rPezvOba3mjPiyBBtMnMHpYup8WSLiHOA5uqlhPwixF?= =?iso-8859-1?Q?A+mwuwYelfxwWTQIajYcu+LsfZNY710kO3YnOuSmCyw1rJzq+AYp/6YkLj?= =?iso-8859-1?Q?bQz/uF/rxXCPCS264qKpzI5CwgdPHwlT1r4UDVp++IjR5liv/Br1iAue6o?= =?iso-8859-1?Q?1uZLU9Sx+NJ4bV3x5wA78G+e3YoOwR3oiyIccRLp8bWmNhJ5oLzQUVDD3e?= =?iso-8859-1?Q?TgH+XKFPgHKg1YmQgDPlu6JIrHQoftT0fzJNho8qobYQEjNmCoF5m1Qbz0?= =?iso-8859-1?Q?q5zz6LBhCql6aKV6Km50FByJfgE/qjo2hrZ4xzkhNSGyVjAIzjY2Ab+Jsc?= =?iso-8859-1?Q?WucE1Q+UXSwHqrdq55s6wAZob0gBwdX9uXQyOV/0lmsjIhcTJc7YtLOthK?= =?iso-8859-1?Q?whddJZAF+rAATRn31eCesGnxJyT00IHOwzl+NzbU4c5iRCf7VueuSn0RtV?= =?iso-8859-1?Q?3xNAlZ4aThAExdTHqdl0fnBBFOTkPTNCz2nc0ueV9XZqh6/Il2tl9j16O4?= =?iso-8859-1?Q?fIfRUJuu50okzxex3Xj7TzniM8eundNgh/O66d+2xBb/byamYgCtEM/lFc?= =?iso-8859-1?Q?9V4uZJHO+Fkwyo4toTkrcI4VXUZu0KHl/wIcTGoZ9B1xoKaPG3ACzCmQXo?= =?iso-8859-1?Q?pF0d3y6PMf7TQQA1J0Q2yt5qkdmE9SurrStgDaZTwIz/bM9zREmSLh/U8N?= =?iso-8859-1?Q?uWQi5AbBNrebRqm4QLWAs5eDoZ4IM68u0t+/T1bYiqXgwcwZkSMboPJ9GE?= =?iso-8859-1?Q?RkpmePh/pmU2Hy4CW/dhD3VcEPJJnwOju2Ym0jrN3+f9GBuP1x3NblGaLc?= =?iso-8859-1?Q?3ls9W4AtHeXRxnFcQJrOajLKj6Si5sUEhv0gVXKZqq+mliWeLxpf46CJnQ?= =?iso-8859-1?Q?qDMJK5jp75GpUq8tx3L5myY7YPfMhLcUls+SSRyG+5HkDI+wELvC3LHsvs?= =?iso-8859-1?Q?cTFhoooel5Oa7jQfkhkQcTyxcPBmhEAPjOeEX/WXp8SHH8MDdEK6BK1unI?= =?iso-8859-1?Q?R5tmgw24Lz8Oo+Degp0v/JUh7itQfkckI/z0BqppRuKMMLAlzz6PqeswNM?= =?iso-8859-1?Q?EkZgtSOALrOhFxEoFETvpOLGPX0Y2AlW0BHwK1sO5d3LB5ey8bIcsemqqL?= =?iso-8859-1?Q?2jFsB1dJZb0AdHyXACI8b1ISh6gM4C2UiqbfncpYkZyX5nrg6P3c+c85Zl?= =?iso-8859-1?Q?3BordwNUL6UZXPYsIr2dIc+Sha+tyzbZpkMPD4UsYkY6CiISp28PfM3O4R?= =?iso-8859-1?Q?hwt+TtiaVghbnkYH+NrSrFp4Q6D1XMTkQUl2MoCLz/57tFGIEgUbh7bqfN?= =?iso-8859-1?Q?bCHSTDdtwi+qN1FmM+OSNFeJ12P1CVrLMPAmiX5e+oodiMBITPbQH7x+AD?= =?iso-8859-1?Q?l4O3pg2InHAzgbY7SYd9DSQ74o1IUayHTKEHCXgQFcjgQvl61bbgW0k5vS?= =?iso-8859-1?Q?9hCkLg65xi+Y7/nuHLLRx5+eD8HtpYPLufmoR6EnFZnSutKP6MmKwwO7x7?= =?iso-8859-1?Q?+JgxW5m1L2yhlSSC+sYBmXUufZvAiS/BvhrtqJyOeRJvbqNySgNRWVoZqM?= =?iso-8859-1?Q?vk/Eo0LWJ4zHvERA+sSCNJMvulwNefyzBMHiEC2MxtuRDpfih4h8ImckxK?= =?iso-8859-1?Q?Gy02w/oygPbeCVUiPyGr2/gWmIyVQV8=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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3fcda0df-43c1-4cf8-56c6-08df2e863304 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 08:43:21.3450 (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: Um8Wh+DaPWfC0OtzGjVT2gTmaoLQD+3gPTRv4HEdh47KsrrmX6lQZWwODehPtDmeUt0JjUqBPpkn6XqlyH6S4P9KZt6Ac7anF8G4+Ot3mAo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8395 X-purgate-ID: tlsNG-33051d/1792485805-6ECCB4E9-32C2ED15/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 b19c25c8d1..9d38ac0f7e 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3184,8 +3184,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 d294fb36bd..be25f23288 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -326,6 +326,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 aa8fa852fc..f92922abea 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -237,6 +237,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); @@ -1897,6 +1901,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 d819955108..9b38c8f6de 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -555,11 +555,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 Oct 20 08:43:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455149.1668688 (Exim 4.92) (envelope-from ) id 1xJ5RO-0005aB-Fq; Tue, 20 Oct 2026 08:43:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455149.1668688; Tue, 20 Oct 2026 08: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 1xJ5RO-0005ZW-9O; Tue, 20 Oct 2026 08:43:26 +0000 Received: by outflank-mailman (input) for mailman id 1455149; Tue, 20 Oct 2026 08:43:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5RN-0005XJ-4z for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:43:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5RM-00EVzr-Hh for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:43:24 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad729ac-e002-0a2a0a5209dd-0a2a4503caa8-4 for ; Tue, 20 Oct 2026 10:43:24 +0200 Received: from [52.101.84.117] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad729ab-fae8-0a2a45030019-3465547526e8-4 for ; Tue, 20 Oct 2026 10:43:24 +0200 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by AS8PR03MB8395.eurprd03.prod.outlook.com (2603:10a6:20b:527::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:43:20 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 08:43: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=H6z9/DMRthTt8tPbPTMEJI3hTdoYIjQF119d1z4jsOyZUP2c+IKtB7QV/ks3bbuqtek0H9CwuOlOrJ/zrt1F/ZOY29dp5kV8Cfhfm78+TylazllX6ZC7znphJtp3+Rz0CaHfZZhPBfzZcHmZ3ga8nww7ygszwuCuW27CrnQJEijDMsQEjkg++nZR49qm0DWWA8vi4t8wm5dXa9lpRbvq8qSpI7ujg/ZZg3+QuOVqRu19wf49/FRSldUVAL4l+HApp+AH5H1PY0Xe4BTSKqKGdXLB2fyyND1NVxiLVL2nDBvdVWAELOuugkGI9jnLTxmLGg7DRz80ZPXEu0TQ8tLn+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=HaPlyiQF1WAzVJ67Z+NxO+5WCG19GCRvpAl3HPh9kPA=; b=MqkvH2rF7bzzqeHijogXeX90UZWHa+7gN4ux8vPx0rQk32IM3xXsS7NlZAbDvGXYFS3bU6E3x35gq7sr7a9kbIjn0NRSm3uObdGP2arTrQ+sViwrXO87UolrUP6ZNpDbSmahPeOh3kGLuA8Jwz4vUI8o1yoYeMz8OT14hst9X4d5doIN6XeapAMKD/tfFZQH3ML85odIXk3tvUQqQc9VGZc/eRcwitR/GX10MSezBjYGXkXotdpUnZnXcHOTQTuSn+6MFppYB/iB6tVBCsa+LrGDZLR7eZAp+VR1XgtCRmsAilo8zc6dLAkztxJqDn4DkJ8rHnaQsRfcOsIu0jwZ7w== 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=gpOKmf/tG06EMV2iCPEMUKf2Fv3MaPjj4GHIrWCr8DsTWV/JkLsltZOa7wS7olpYSfrZBsMysx5towmH/Gxb8t7bkOkQrvGBQVBSpad2MEinbPeMZJLdPDb7p280J1/TJWFG6uNV+RcfDPOPNE69Ce2e2sCZ4plMMJEVTWTI092GrN+WwqEBD6zMQZFZmkr3jSAzGz1W2bo6isaGUHLYJREFnf9Z2Ct0hn/plo0Gkl/xuLuUj990t5C0XLzvsj8K5mwbdNM6Yk9lqcfxzvHCDZ+eOyNuJxbxGlqK+EX+u96+S4mz/ZX/1JxBSRhf+qscqVTe1x01wPZRbUa/RG2HKw== 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 Subject: [PATCH v14 2/6] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Topic: [PATCH v14 2/6] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Index: AQHdYG8OvUO/mxPUDU2sduaNbQWazg== Date: Tue, 20 Oct 2026 08:43:20 +0000 Message-ID: <8354d8eb8be9d24f86b2f8d12e5b3a33227c0d7a.1792485704.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: 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: GVXPR03MB11113:EE_|AS8PR03MB8395:EE_ x-ms-office365-filtering-correlation-id: a30fc80f-cb35-4c04-d9bf-08df2e8631ed x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|7416014|18002099003|22082099003|3023799007|38070700021|11063799006|10067099003|261009223027099003|56012099006; x-microsoft-antispam-message-info: Kn3MjQu7iedL9fVF9EnGJLPsnYdjNujZzP7kqSM8ScCBVHfNmxy+/vC+EENxsu+LtqxGJJBzqrc/bdrv2tibK0bEOzIhN1biTmhpI5qU1dgoP1JRqL9CAZanzI/fvzKNObyrZOvFpKgrlVy5QaCV5jVjMiMCvEAZE8drUDkkD5NO3b3kJmiANVqgvrez0wf0m3YoLYdZzBEeWEscWujBgjir619IvffaPnbM2hnDRp9WuT2qZo2stTlFN+upryUwTvhEJkx2ZTlmotrzWi1JCkm2Y1owKTt+7o5IHfxipcxj/BD7fiQzni9vcmAm54g17eRxAt9GqUx0GFQyWQoAs2FCa2dlRosrLIiJCiNoi+VExXm2WWpVz9DQQRPDgeE5NEAXoIcjn8pIUdUGoX0IT4CM3yDG0w0vX4dx941uUgSPRK5Ff3Z0aa1r6EOdoAlPDMz5RPAUZxMbU4mVsn5stLlfL9/VrppdsV4agLBphtOr/FPtxcoD+VGGWOXRaYoHIX0MgAGxFU3tLATqpKU3XOgE/j/fnKa/bi6oJKbJ1cVIEzLZvOdw7BA8wDfNjKZEQRcN81O3a3d0UpYe4mtJ7XSgpceOpTgKh1uU46D4OSjJrtz94isfz2IJSgp4bap6ObMdobWlZvDMISKUl+5pjvd5iqCBfqaFToJpsMplye4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(7416014)(18002099003)(22082099003)(3023799007)(38070700021)(11063799006)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?QDrRFoFS/B+B7SDv3U//8kIDNwtBm+gK/QyPobtundoqLVUE3aRLIj2puV?= =?iso-8859-1?Q?rD63aPQH7dO8cJvky+dx2jfBDWzWgpwux9Pubfh/dVJpBi8wc7L4oInox1?= =?iso-8859-1?Q?U/NgrfB5RlzigMH7BL3/lsxSrLY0LOXR54dN3vQegWOCjZNkgtwnvzGav1?= =?iso-8859-1?Q?MNbIPrzeb7TQIhcOw5vFz6nKJxCHpLiPFfQyErdrAKgZxumo9KXOeAE5yk?= =?iso-8859-1?Q?PLhMtGpZ7aAgri01wLnaTX4SjSpRqWv2IsvO0aX+OBRdWLo5fbPYiNwqOp?= =?iso-8859-1?Q?yxeFolUYKVLfhJuBLdlBF19/qg1v516ljz4OWEQPf8Yrs9y887TZwH7/Wp?= =?iso-8859-1?Q?OJBpSiEcEs6oTu/1GjtKO+MryuwbH1WiqDcbWrtK34tribDIcMiPzMppYH?= =?iso-8859-1?Q?rL2ZLysKn5k8hSZdzuoZadwdFnUq15ibPKdTs48n25ZlMxKuu+RT0foX7B?= =?iso-8859-1?Q?RUzCqvbjBXVOnbzewWMK/cCRTgSke1YcAt/eViMYHXmJpMFvvGxrgUn4DW?= =?iso-8859-1?Q?atVId3eP2/OzxXEKfLQuTJ+k1b3qFZ3lL/+Eo6etDUNrCsz2srHJqyQvEy?= =?iso-8859-1?Q?We5WhtoKKT1KJ7NHwFDGmVvc1htkEYM7xdE2qmbuKeiKABZxAmYplNr3ng?= =?iso-8859-1?Q?TGCOTqqQD3k6rpQmH86pg0wmgfnRpSSgOSbyEgyvzBUkV8ri+MwwXJOSEu?= =?iso-8859-1?Q?/DXvgkwoYrpMeCvvUnpvT2CfEYMHmDTFmu5yzjLZtzWwf12YXQw2tCVh0K?= =?iso-8859-1?Q?YiyM0EG8UeeFlzz86MDQ8v1uvkBu4m456hjaIagXTxbouAuJzKSEzFRLdH?= =?iso-8859-1?Q?8WyyV1hWEagrVy3w+9IZF/oJrxUkFC5WqkbxpzKE1uXQPsuwm7wX2KYjzt?= =?iso-8859-1?Q?rzLCs/1PQxuqKliC9xAvi+lCAYpcbMRrRI1m+mTCMQxwQAneIci65m730v?= =?iso-8859-1?Q?ilN9UNQr7mZfmv+6dUib22q92wgnkRLWclLLbeaFRuUkm8+7UJqmsnGbwZ?= =?iso-8859-1?Q?bQlGpGujWn0n90+xhhQxeBzYTGgNnv1hC/bkiXXm60fKANWhgUOdYZJONv?= =?iso-8859-1?Q?RM1jv4UYU3AlwBvrT43ErhB/Dsukm7N9zhTMnomyTVQ+UeBPAQSS8/ZYqV?= =?iso-8859-1?Q?d6j7oe39ilW2Ch0mXuyWm642N/Ty9/LY0eKfyZ24FAK71TfsNoHi4DPdvD?= =?iso-8859-1?Q?tebH4C/jmzEf3ypPzOwoGGPK0TjLXZ1hCIXc0qwKuObDLDtr5BlYcGnxkw?= =?iso-8859-1?Q?piPf9HudB1EYSIUB+hnuqIxel1y7vAKAitI43/Jsv+JamsiC5k5Ko//PIc?= =?iso-8859-1?Q?IOIpYon3hl4onTfD+YmZ67S97C+KvovI1EHWSji7NNLmPZiZc856RZbW35?= =?iso-8859-1?Q?P8DLMztZQ+R+B0y8YzD7J+9kNyfjtItf+YGKFA14C8OzkH0qP/4c0NzbAf?= =?iso-8859-1?Q?VaKoVtNn8PiB940PNoCYjngJ+akGKEQw2cGsUB4TMAWdRvMQbCv9Zcdh/I?= =?iso-8859-1?Q?AXc9pKQAlnOK+wn4/Wtydk8HnmWqdPvEPCYq1QcWDCq2fSID4sDs4FZ3HG?= =?iso-8859-1?Q?UDR+ogqN5CLvZ3t9XiKkAhbnuxwG5II5tYv0e6cx6ENFhbY+HFe4EJZvO9?= =?iso-8859-1?Q?45ZHtcpLoCorbr2LD4JAtJbi0XQe/4ZaBJyDNr9l2zA/w5HP2Tyx6tTS96?= =?iso-8859-1?Q?HvW2jTfuQP1EmtsgjUQpHqQfTttX/RvBAc+10GvQzgvPZIIcDoPBVPoQ/j?= =?iso-8859-1?Q?J9ZXFqRu8/+1Vj8Xafqe8EaEXb2wMuJuw7kHuLd2Roh9FlH++UMyvGv7xF?= =?iso-8859-1?Q?5DJu8lZeqFuhT+vyls1mUc6FRc67Y4E=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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a30fc80f-cb35-4c04-d9bf-08df2e8631ed X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 08:43:20.0293 (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: Z9wkhXdMFGXSTFb4XiiX7lvcxgFLdcjRrjq5QlhRIsypQyRcRdWXZuz0N6MGOkbZWxbv5uYuMMV5Ojis5nloSZfTdmuyT+b2xmpPLtpIpiI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8395 X-purgate-ID: tlsNG-33051d/1792485804-6CADC4E9-4A8AC370/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 Oct 20 08:43:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:43:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455153.1668728 (Exim 4.92) (envelope-from ) id 1xJ5RS-0006dZ-Vx; Tue, 20 Oct 2026 08:43:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455153.1668728; Tue, 20 Oct 2026 08:43: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 1xJ5RS-0006dB-RI; Tue, 20 Oct 2026 08:43:30 +0000 Received: by outflank-mailman (input) for mailman id 1455153; Tue, 20 Oct 2026 08:43:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5RO-0005bO-Kd for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:43:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5RO-00EVzr-0k for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:43:26 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad729ac-e002-0a2a0a5209dd-0a2a4503caa8-20 for ; Tue, 20 Oct 2026 10:43:25 +0200 Received: from [52.101.84.117] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad729ab-fae8-0a2a45030019-3465547526e8-7 for ; Tue, 20 Oct 2026 10:43:25 +0200 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by AS8PR03MB8395.eurprd03.prod.outlook.com (2603:10a6:20b:527::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:43:22 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 08:43: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=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=u96Cd7VhfDf3Y/jPzoskHtUTCqCHGClStLXXmoTKgMtO/K/AMNhq+mCFXKNXjky3iz2QsUm9cdWSXyzZF6PXBpYwmvCvq9ncXf05gUCVN4EP9ckM8vUUCC0I3F4DSVtu7u5rl2v41hJhPgDefe9uBVT9BVcr9DoW5SwksCusCR9/SchISMmbkZABkrB+/1KDrnMDH5SEg5bySnkTkN96Jda58CHcqDjKC2JBuTCuJNm+CuSeCV1qgHZbiP5C6yXJtElhB1qbw4aPbYGpfBjOpXYdl+WRDLUIW9YF6QlzlA0RuTIEiS8+j63HAM54AnG8H8Pu8Q5FLeTpaUv7TTRYsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Yn3jRqfrRQikNR3iJFZ08M6MlpshbpPz0gGnlQLJOJg=; b=FJznxNtd9LIyXLGkaM9oEDcsLlNzvKaPGy4e8oUfVuUSAXKB/JoUQ5W4Us/T5zvo7mINIfoonmHEUp1yDYy3J742xPR74pKqZiwg3dphEnMA0DksvyBR1QbQD5KqGYQY7UeTfG/HX/enRhnYb05ykpKtN2EJhm+0lTAEhMNMeKZobVRjwiJvyBnRq4soxnBv4cSbKAWoApvhtLsEbxScndXlpCk+jAKA8udn4yaHcaNMTWms9f6xRP6ETpjL2mMM255mHVASTa3I+5vOZy93seYKygtCHJIjnAU5GrvafwkmKsyfMFV6RvMgCVPhQbmXuUICFX/htK0UHhuujaxqRw== 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=Yn3jRqfrRQikNR3iJFZ08M6MlpshbpPz0gGnlQLJOJg=; b=faI12mhtzQQs+2aSqhzvgvvkt6hUulUTb6NZ33RiH33ij2XMMk5XUooAGMfl07GokbytJzdyKNBRWwLCAIE33ZP9sXy06T1SwsLalfu5Q5YS0AMkzCxMZ9mlhEat6OqEkPtOCkSomLDa7TaurzP9lxI9X384TmTCToqaqenaK0Cw5EbG0j9jnIsNO7gBj9bUfmY5h9SGTXDqJzvnI462tN3VtEgdMahrkzClDOWa+LSGLATaOX3fzL2f6i269jV0zSzFzk0vuSVqw0cSM/9qPU+IBs7NrDTFy4AuNOkJ+aYtq7/MRCmi8u1PaufQIHh0C4KVa2ozC5ltKYkPx8KUwA== 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 v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdYG8PUG4uC8qBAkeMIAyIqnSgzA== Date: Tue, 20 Oct 2026 08:43:20 +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: 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: GVXPR03MB11113:EE_|AS8PR03MB8395:EE_ x-ms-office365-filtering-correlation-id: fc395842-5138-4b9c-112d-08df2e8632ca x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|7416014|6133799003|18002099003|22082099003|3023799007|260925022911599003|38070700021|260925021911599003|11063799006|10067099003|261009223027099003|260925021311599003|56012099006; x-microsoft-antispam-message-info: opy66mvz0/59oFYI82JmInW2pcUaSYmJzpdaBt8sM+DKVHv7iQDAwNv6wvu0HIjNMn1KmRkeEeN1drEULjvyj4M1/ZIOiXrGo6pZsFUQ3m3ks57IUmhMiwAiiu54QqIPRW5Egxt3GXU25uyiw7iknXVkJz87N793MxUl2ueflRh14y+b0KM5JOUGX8UQ4LiS4zVrq3Fm03qi0TS6fFYG4I0XZP2XlzFLlQ6kswie9/OrZzWZmDmmsAo477RAIDddJtD67vW0ZFdhGNAPV8D9rTKKLODj48rHHUDFu5QBNp2K4UAIBtQOtFH00qffbCbSL9QffPqb9yFPsISvctFoYIFBfI4bqv8L6q+Ef4x4u2f/MMuwegXPbSCUukpKeQrYg/b6fNbfptYrgCL6/UQ+i+lVnQxWpiT41EBaaljJ4QCQMd1K7qTRuDNql5pThoDUP5sk5OCiheruaz7otBQk9CL9CPpsagBnbifdoBs2NokeQ5W/Na3n/H9Iy7X6/wbzvh6dt007GgSjg/95kzus6RNWNkStkRZO+UQ9JgsLuimyxaJN2Hj9AMmhl3B/+/edqNBe7CEqkEQ+379SQd9znoMsqjf7aiLORH8D7BLWwQAPE5i2Dvbb3D65GA90d0E9aZSrxHLL3h7Jh/khdhJlhfNmOCxEoFJY8NGaXsjW36w= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(7416014)(6133799003)(18002099003)(22082099003)(3023799007)(260925022911599003)(38070700021)(260925021911599003)(11063799006)(10067099003)(261009223027099003)(260925021311599003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?6XLlyl4rJi2w4/wtPxK7/h2swRCFhhDbpp82tC9ivDXp8DrR5bsmC8XxWu?= =?iso-8859-1?Q?6get4TTdCm61ny/S6wbBVeiIKvSAE8u36fxGiEK+Qk0JDeBhXQfGj89YNa?= =?iso-8859-1?Q?HMHMsUsolmYUvAlBzmwI6lif2jVKf4GsymlNEE45M0DegiwUKpXMfe0n7B?= =?iso-8859-1?Q?/7RTpDFqBL0mqkmsp5JqCBI1NEqSlcMqZQLBWOrV6gKa8iISZSlie0Ij1f?= =?iso-8859-1?Q?Zy1oQiMR3/GsEyOw848VtJNMqOGccwhmVKEJ5Axf6+BGSE2mFS0rwLO8Tw?= =?iso-8859-1?Q?On902uRt2dvG9KzZAUWZRL4fazKGhWd5oxp3yFk08JhtN1CDOjPXGd2ggl?= =?iso-8859-1?Q?FGx1AMnLLZxn4VLTV5lZX8Ak3PBiRQib3XKgPArkfLfvuVaxoU1XZMiMpM?= =?iso-8859-1?Q?nDI5BKhlJNZA2+RKMGRIkopBUs5LIGz3NPWd8LIl+AH/DlPLIBlnoHYbX8?= =?iso-8859-1?Q?Sw4Uqek7IbgUeYTfTEvR1C7ZlaueLwSzX+e8H0W+KSbtNhGBFuCSFYPg0e?= =?iso-8859-1?Q?HIQvgUgjMNaT3bcfowNgrZAVABcjsQBwaAcSJGuGBulnio7C4QLpY4x/qJ?= =?iso-8859-1?Q?z284HetpLacFp4ED9hL5gq2sxnJBwy60LnrlHD1bqjUvXq2fUwf4/VEST7?= =?iso-8859-1?Q?ONJrmTzfElzUBYV1dn6CezCLL2xxCB2sn7utVPqJ+n5YNTf+pyiSBxUC1Q?= =?iso-8859-1?Q?FJSuwfPHCi7VaHwIg1rHCGeDzmCaS4ow8i4r0esj4gVf75CydLgE1BSh3z?= =?iso-8859-1?Q?GrcaMXynASqOj7Ghgs0CQ8wNM6oeYGrYvVeUpQEXtJNHEDueFssSxZHCo5?= =?iso-8859-1?Q?YE4OIt887xq4ZUdBWUZ3zaNkh5idkani02F73yl3V67736lrhVOv+LJLgN?= =?iso-8859-1?Q?jIEmpHsNnOrQWHoKT+fMyt+rbWd0xKIXU/i9CG5HyTlfIed/daYJN3Zb38?= =?iso-8859-1?Q?FBvOK9JIXYaZAhDzKPiwhCEOVH7uojNgWQapSSPFP+L9/Nrs+0Rw7SCX6/?= =?iso-8859-1?Q?1Q5WbYtjiSmrVmx0zvFm3dbaru5vl3NB2BtIPZ54xhlJ6du/UKu99cSjx7?= =?iso-8859-1?Q?SjKO7GfgFOOP9pphr/f+FxLRXb7jbGI68qoo2vcBFV/1Vjt2TpM/crHbZU?= =?iso-8859-1?Q?97YaD8pHftYubf1d2+KGkOOopKcgoikh1d9cnecitYTPq0n2LfvRyXZtqA?= =?iso-8859-1?Q?VVYzZjIgfAHCsFRO4JEfzBTRNJt+KXFylr8nPzBxXMtyxiB5XEhdwiOOUb?= =?iso-8859-1?Q?h0cxQgjngdAXMM1eWZDJsum1Bb3NXtM+6AaxpaiYS/CIculJ72wATUi0RG?= =?iso-8859-1?Q?WNXM0sirSfXpvnW+z5bxz7liIlyGEiAtVnMxylVQke8G4NN584kexLJ0ly?= =?iso-8859-1?Q?pgOXC7xZcft5rzoJvJqpyQ6gArHrCp0VBLphTH+hqoCsf1TWPr4CvdfIr2?= =?iso-8859-1?Q?lHSAbGDFaUMdxYW2CPlYLV8WjTdb+UjlLMerccjNPr1qqG0Nl5t9gvLrgl?= =?iso-8859-1?Q?BnCeZj1njVf5n9+cSoXQtxmD/JZXEDdaOMkpmXadS3dQ/HA9cqFqKoHi2e?= =?iso-8859-1?Q?Og1/OM9TRhFmCrpuhEsDRbnK/EQFL0Oij5mjSLa5s30F6PgsHvL0yKT+nT?= =?iso-8859-1?Q?5cLDelXGs8HqwxMTpWD+CrUzRO5LOV5bmkEF0OZED4+ee+Q1VEeHiOBWb6?= =?iso-8859-1?Q?0pV/OnHsjpLzAztTX7LGOsDk5XkJPLzLXxyxpOOyD26unWMr8bE8+TS6ST?= =?iso-8859-1?Q?c4cdCoc6sllp2LBUSrZGgQi22qRL1vnWpbX2YSwTMQ42mT9xUeE0EwHoqe?= =?iso-8859-1?Q?VySkqfbHpcOF623CytYhLSYYoFyDyMQ=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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc395842-5138-4b9c-112d-08df2e8632ca X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 08:43:20.9559 (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: tr15gvJJqBxiXIGlYEshzL2MhJBwxg87inbd7AhcykGiDul1qwktS4UWvxhvhtwjvUcrjgR0sbRAcx/rPQxP7oRUOhPVvAagtgCea5xVMoM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8395 X-purgate-ID: tlsNG-33051d/1792485805-6EACC749-292BAEF4/0/0 X-purgate-type: clean X-purgate-size: 69169 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 following 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 (required for Xen and secondary agents without reg) - BASE_RESET_AGENT_CONFIGURATION (optional) - BASE_SET_DEVICE_PERMISSIONS (optional) The driver binds to the arm,scmi-smc management node inside a Xen-specific container compatible with xen,sci under /chosen/xen. Other SCMI nodes, including the host /firmware/scmi, are ignored by the mediator. Describe secondary agents as xen,scmi-agent children of an agents node inside the same container. The agents node uses #address-cells =3D <1> and `#size-cells =3D <0>`. Each child provides arm,smc-id and a single shmem ph= andle. The optional single-cell reg property supplies the SCMI agent ID (0..254). When reg is absent, Xen discovers the ID using BASE_DISCOVER_AGENT on that channel. Use agent@ for an explicit ID, and a node name without a unit address for discovery. Disabled agent nodes are ignored; at least one enabled secondary agent is required. Resolve discovered IDs before adding channels to the list, so duplicate IDs are rejected consistently, including clashes with Xen's management agent. Explicit IDs avoid mapping and probing secondary channels during initialization. Xen always discovers its own management agent ID. Keep shared-memory nodes under xen_scmi_config and leave the platform's existing /firmware/scmi and host OSPM shared-memory node unchanged. Channel nodes describe locations, rather than reserve memory: if firmware buffers occupy system RAM, the platform DT must reserve the whole firmware-owned range in /reserved-memory before Xen boots. A single reservation may cover multiple channels, including unused ones. SRAM outside system RAM does not require a RAM reservation. Channel nodes need not be moved into /reserved-memory. For example: / { #address-cells =3D <2>; #size-cells =3D <2>; scmi_shm_0: 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>; #address-cells =3D <1>; #size-cells =3D <0>; shmem =3D <&scmi_shm_0>; }; }; chosen { #address-cells =3D <2>; #size-cells =3D <2>; ranges; xen { #address-cells =3D <2>; #size-cells =3D <2>; ranges; xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; xen,dom0-sci-agent-id =3D <0>; /* Xen 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>; #address-cells =3D <1>; #size-cells =3D <0>; #access-controller-cells =3D <1>; shmem =3D <&scmi_shm_1>; }; agents { #address-cells =3D <1>; #size-cells =3D <0>; agent@0 { compatible =3D "xen,scmi-agent"; reg =3D <0>; arm,smc-id =3D <0x82000002>; shmem =3D <&scmi_shm_0>; }; agent@2 { compatible =3D "xen,scmi-agent"; reg =3D <2>; arm,smc-id =3D <0x82000004>; shmem =3D <&scmi_shm_2>; }; agent@3 { compatible =3D "xen,scmi-agent"; reg =3D <3>; arm,smc-id =3D <0x82000005>; shmem =3D <&scmi_shm_3>; }; }; }; }; }; }; To discover a secondary agent ID instead, omit reg from its node: agent-domu { compatible =3D "xen,scmi-agent"; arm,smc-id =3D <0x82000004>; shmem =3D <&scmi_shm_2>; }; The agents child nodes replace the former scmi-secondary-agents list and `#scmi-secondary-agents-cells` property. The xen,sci subtree is omitted fro= m Dom0's DT; the host OSPM channel is passed through when SCMI is enabled for Dom0. Full configuration and domain examples are included in the binding documentation and the hypervisor guide in patch 6. 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 v14: - replace the flat secondary-agent list and its cell-count property with xen,scmi-agent child nodes under agents, using reg for an optional ID - scope secondary-agent parsing to the management channel's xen,sci contain= er - resolve discovered IDs before insertion and reject duplicate or invalid I= Ds - validate shared-memory phandles, addresses and nonzero page-aligned sizes - retain shared-memory nodes under xen_scmi_config and document platform reservations separately, following the review discussion - update binding examples and commit description for the child-node format - match the const-qualified SCI domain_sanitise_config callback interface 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 | 195 +++++ 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 | 792 ++++++++++++++++++++ xen/include/public/arch-arm.h | 5 +- 12 files changed, 1403 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 3787d2e2b6..178f2493d8 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,183 @@ 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. + +- agents + + Required child of the xen,sci container. Describes the secondary SCMI + agents available for assignment to domains. Set #address-cells =3D <1> + and #size-cells =3D <0> in this node. At least one enabled child with + compatible =3D "xen,scmi-agent" is required. Each such child has: + + - reg: Optional single-cell SCMI agent ID in the range 0..254. When + present, name the node agent@, with the unit address in hexadeci= mal. + When absent, use a name without a unit address; Xen discovers the ID + using BASE_DISCOVER_AGENT on that channel. A malformed reg is reject= ed. + - arm,smc-id: Required SMC function ID for this agent's doorbell. + - shmem: Required single phandle to an arm,scmi-shmem node. Its addres= s + and nonzero size must be Xen page aligned. + + Agent IDs must be unique, including IDs returned by discovery, and mus= t + not identify Xen's management agent. Children marked disabled are igno= red. + The management arm,scmi-smc node remains a sibling of agents, directly + under xen,sci. + +- 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 selected + agent's ``func_id`` and shared-memory region must match the host + ``/firmware/scmi`` channel passed to Dom0. + +The shared-memory nodes may remain inside xen_scmi_config, while the +platform's existing /firmware/scmi and its shared-memory node stay unchang= ed. +Shared-memory nodes describe channel locations; they do not reserve RAM. +If the channel buffers occupy system RAM, the platform DT must reserve the +whole firmware-owned range in /reserved-memory before Xen boots. One +reservation may cover several channels, including channels not listed in +this configuration. SRAM outside system RAM does not require a RAM +reservation. Moving the channel nodes into /reserved-memory is not require= d. + +As an example: + +/ { + #address-cells =3D <2>; + #size-cells =3D <2>; + + scmi_shm_0: 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>; + #address-cells =3D <1>; + #size-cells =3D <0>; + shmem =3D <&scmi_shm_0>; + }; + }; + + chosen { + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + xen { + #address-cells =3D <2>; + #size-cells =3D <2>; + 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 */ + + /* Xen 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"; /* Xen management agent= func_id */ + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; /* Xen management agent shmem= */ + }; + + agents { + #address-cells =3D <1>; + #size-cells =3D <0>; + + agent@0 { + compatible =3D "xen,scmi-agent"; + reg =3D <0>; + arm,smc-id =3D <0x82000002>; + shmem =3D <&scmi_shm_0>; + }; + + agent@2 { + compatible =3D "xen,scmi-agent"; + reg =3D <2>; + arm,smc-id =3D <0x82000004>; + shmem =3D <&scmi_shm_2>; + }; + + agent@3 { + compatible =3D "xen,scmi-agent"; + reg =3D <3>; + arm,smc-id =3D <0x82000005>; + shmem =3D <&scmi_shm_3>; + }; + }; + }; + }; + }; +}; + +This keeps the host OSPM channel (SMC 0x82000002, shmem 0x47ff0000) separa= te +from Xen's privileged management channel (SMC 0x82000003, shmem 0x47ff1000= ). +The xen,sci subtree is omitted from Dom0's device tree. + +To discover a secondary agent ID, omit reg from its node. For example, +replace only agent@2 above with: + +agent-domu { + compatible =3D "xen,scmi-agent"; + arm,smc-id =3D <0x82000004>; + shmem =3D <&scmi_shm_2>; +}; + +BASE_DISCOVER_AGENT is required on secondary channels only when reg is +omitted. Xen always uses it to discover its management agent ID. Providing +reg avoids mapping and probing the secondary channel during initialization= . +The scmi-secondary-agents and #scmi-secondary-agents-cells properties used +by earlier versions are replaced by the agents child nodes. + +Dom0less example (multi-agent) +------------------------------- + +Use the same Xen SCMI configuration as above. Remove xen,dom0-sci-agent-id +if Dom0 does not use SCMI. Add xen,sci_type and xen,sci-agent-id to the +predefined guest's node under /chosen: + +chosen { + 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.) */ + }; +}; + +The guest's partial DT and shared-memory mapping must use the SMC function +ID and shared-memory channel associated with agent 2 in the agents node. diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 7bbb2eafb6..01c2a5ce52 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -293,6 +293,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 72f6f7539a..5d42cdf6af 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -88,6 +88,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)) @@ -1480,6 +1513,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 @@ -1975,6 +2009,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..6c46f6cd36 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c @@ -0,0 +1,792 @@ +/* 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" + +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_channel_addr(struct dt_device_node *scmi_node, u64 *addr, + u64 *size) +{ + struct dt_device_node *shmem_node; + uint32_t phandle; + int ret; + + ret =3D dt_property_read_variable_u32_array(scmi_node, "shmem", &phand= le, + 1, 1); + if ( ret < 0 ) + return ret; + + shmem_node =3D dt_find_node_by_phandle(phandle); + if ( !shmem_node || + !dt_device_is_compatible(shmem_node, "arm,scmi-shmem") ) + return -EINVAL; + + ret =3D dt_device_get_address(shmem_node, 0, addr, size); + if ( ret ) + return ret; + + if ( !*size || !IS_ALIGNED(*size, SCMI_SHMEM_MAPPED_SIZE) || + !IS_ALIGNED(*addr, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: invalid shmem range for %s\n", + scmi_node->full_name); + return -EINVAL; + } + + return 0; +} + +/* + * 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 int __init collect_agents(struct dt_device_node *scmi_node) +{ + struct dt_device_node *agents, *node; + unsigned int count =3D 0; + + /* Use the configuration containing this management channel. */ + for ( agents =3D scmi_node->parent; agents; agents =3D agents->parent = ) + if ( dt_device_is_compatible(agents, "xen,sci") ) + break; + + ASSERT(agents); + + dt_for_each_child_node(agents, node) + if ( dt_node_name_is_equal(node, "agents") ) + break; + + if ( !node ) + { + printk(XENLOG_ERR "scmi: missing agents node\n"); + return -EINVAL; + } + agents =3D node; + + if ( dt_child_n_addr_cells(agents) !=3D 1 || + dt_child_n_size_cells(agents) !=3D 0 ) + return -EINVAL; + + dt_for_each_child_node(agents, node) + { + struct scmi_channel agent =3D { + .agent_id =3D SCMI_BASE_AGENT_ID_OWN, + .domain_id =3D DOMID_INVALID, + }; + struct scmi_channel *channel; + bool discover; + uint32_t len; + u64 size; + int ret; + + if ( !dt_device_is_compatible(node, "xen,scmi-agent") || + !dt_device_is_available(node) ) + continue; + + discover =3D !dt_find_property(node, "reg", &len); + if ( !discover ) + { + if ( len !=3D sizeof(uint32_t) || + !dt_property_read_u32(node, "reg", &agent.agent_id) ) + return -EINVAL; + } + + if ( !dt_property_read_u32(node, "arm,smc-id", &agent.func_id) ) + return -EINVAL; + + ret =3D scmi_dt_read_channel_addr(node, &agent.paddr, &size); + if ( ret ) + return ret; + + if ( discover ) + { + /* Resolve the ID before inserting it into the channel list. *= / + spin_lock_init(&agent.lock); + ret =3D collect_agent_id(&agent); + if ( ret ) + return ret; + } + + /* Guest configurations encode agent IDs in an eight-bit field. */ + if ( agent.agent_id >=3D UINT8_MAX ) + return -EINVAL; + + channel =3D smc_create_channel(agent.agent_id, agent.func_id, + agent.paddr); + if ( IS_ERR(channel) ) + { + printk(XENLOG_ERR "scmi: Could not create channel for %s: %ld\= n", + node->full_name, PTR_ERR(channel)); + return PTR_ERR(channel); + } + + count++; + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", + agent.agent_id, agent.func_id, (unsigned long)agent.paddr); + } + + return count ? 0 : -EINVAL; +} + +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(const struct xen_domctl_createdomain *conf= ig) +{ + 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) +{ + 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; + } + + return scmi_dt_read_channel_addr(scmi_node, addr, &size); +} + +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 14d51e0746..722c2d2e3a 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 @@ -347,7 +348,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 Oct 20 08:43:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:43:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455154.1668734 (Exim 4.92) (envelope-from ) id 1xJ5RT-0006k5-JO; Tue, 20 Oct 2026 08:43:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455154.1668734; Tue, 20 Oct 2026 08:43: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 1xJ5RT-0006iY-Br; Tue, 20 Oct 2026 08:43:31 +0000 Received: by outflank-mailman (input) for mailman id 1455154; Tue, 20 Oct 2026 08:43:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5RR-0006Yc-Q0 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:43:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ5RR-00EW66-6J for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:43:29 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad729ac-e002-0a2a0a5209dd-0a2a4503caa8-28 for ; Tue, 20 Oct 2026 10:43:28 +0200 Received: from [52.101.84.117] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad729ab-fae8-0a2a45030019-3465547526e8-8 for ; Tue, 20 Oct 2026 10:43:28 +0200 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by AS8PR03MB8395.eurprd03.prod.outlook.com (2603:10a6:20b:527::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 08:43:23 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0522.017; Tue, 20 Oct 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=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=GrvyeA4tAnfXLw3xrJPjeNwULwNkmT929UmCwva1Wl74xvv1Wn/uw29u/peNJ7GLf51gld86NcIyKYpq+wDP57vhMNkqLbmoiAV+hY2Cdf7hZ40NzygAkGuGhK5XhGmCrWhbqj7VPRxvyCqPLLVWOS0N+95Ou2kYNY05HwzP0ZH688MC3qymJNC4ZCtUUdTumyR+7icYP1JlI9Le8jWgRkz+j7OAn3VinXqHrZMKctYHyHdrFvG76JRoWRNZcYHQcsx3XdHYDanDf1hKEGle0YTNpRkB80ncySYiOp8ChqIKl2TCnw1kwD37tVfnfzeMb+iIN/NNFGpGkeCLXkMt2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eGase0MvgQ11xf3D0p639mDVM/bgys3NZwE31QW+lKw=; b=EUTEVXBmTKW0N9UQjNaD5vL9CD2SkjyWNdT+ASx1LgHvgzV9Zv4x2Cg0K1z1Upd8TeEsrRzAhXo86qmad2/mD+27Kv3UHVRZq6uPUMMUIh43Z1IrJbhR4PNu/0wuD2Nz2ikAo4VfW45ptlqTRdhqnDywOBPda7HFo5AyPZ6CIQrhSsWw7dRRRCQWycSob+YIt6gstnDtFqTpvGfskUzDwxJo6IhCs1a9ZIMeW94hSQRaqYcuCbPxJiiudE8SOx8ezTvxmAMviJsx044rgZVxe3JsL6Ts/i0cR5epfUCdiKNYioDIYiwT9GD97sXRTKNaLYancjEOx522xPaOUHmCsQ== 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=eGase0MvgQ11xf3D0p639mDVM/bgys3NZwE31QW+lKw=; b=beMUqv/+PfxUD79s/hqB1CN+SP6qQG6b0Sy6r3qE2mienRrhTiUM/5mK8hUBTvQhlXMxiYyjUIqhhYw7A7mS1BVBL1lOzd94iw65/Sop3jvFfpvAyr41CFNTCBNkpOLbc5cAehUGP+sdloO9PX+5IMheMoDiIOLwy6W/GGpFfR1DDU2BDVhvurgPwjYDYK9GE85JEIcHcqA/9yS/xUubD4ZuTT9XU0BXf/i2dTNSHWMC0ZQ3d1HxbgLsh1cT/E09WIVAVcSrGMPuKcnsoni6S1sae+bxsG55LoO/Qsi5h6IKxVAYOnb0VgbZnyepDmA3xAydjZgYAlIe7A4JQgbFUA== 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 v14 6/6] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Topic: [PATCH v14 6/6] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Index: AQHdYG8Q7qVBhYr1q0OFBlaFyWoovg== Date: Tue, 20 Oct 2026 08:43: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: 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: GVXPR03MB11113:EE_|AS8PR03MB8395:EE_ x-ms-office365-filtering-correlation-id: 200f41c2-79fd-4fa8-3e5c-08df2e863341 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|7416014|6133799003|18002099003|22082099003|3023799007|38070700021|5023799004|11063799006|10067099003|261009223027099003|56012099006; x-microsoft-antispam-message-info: 6D8Ql9kkXrHMd27JfmtTQMHhimXYcRubpILox8oC1lI29u5TMR42iKUGwMSufEFr+CcT84byZ/u81b9mjDqNveQLzARStSztWA21HlxV2aVbvEQB/YXu7t0i399aqvCJs3VDtFnfVKMsEjpRESthtJQ3Mmn/uSTKkao7r344PbvyZeyQfiAmKbIUYV/mfWqrc7RhyiubKahvYXp5YLlQYS5WSOal2YXGSs+x8ONdknJe5bP31FHPWLR1F5nQO+q8Yl3Obr0oRs5knl8vpD0SDDNWm9V5F4t/oCRSqqYQ9ompNNznAuobTFjHwbbIzUJL/WraIr7c8XCZat/rIDDjJHTedkaUnBwfZAoUMZCtlz4DNglX5Rq8sMwp4HWXkkEEOsoXN8phNqJwnruitG7kqwldlfTKg+J6MUd5D2O2TZCH01/R2Fc00ne1aiDbOXjjznJQt/vBPe9cRQsahFC8aSDM5KcIQn4AMFzN0KFpaWodRYH+PYdLFBr6MC3DZumFGqAHM/u1muH6/xdCNHC5LngM2UYDs/L3jeY85lpz9nd2R20FbUd2O5T8cKFEN3T+fhiBt6dsDSJ2DD3/Idv4/LySWYxKska9zt4bkmjaO9BwHHSofUvW3hJ1sjw2J4LD2Fna7SIfUM4LiqlOguEds3npruAfMP3w6ch8RYOQo40= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(7416014)(6133799003)(18002099003)(22082099003)(3023799007)(38070700021)(5023799004)(11063799006)(10067099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?HjFhtTt2h2EJcH/4B3LMXLGrg5bdTV9yIaUH7+64F2aYtBL3k5B6SngEv/?= =?iso-8859-1?Q?LCvb83yfKaCO60AFjFmICFV5yTbVJvKdlkJMStfcEh6/ekF7sYFp0l4h00?= =?iso-8859-1?Q?AAR1wU/eY1SQ4EsidSsJrKzdnuy2pfhjb1jJ/U1O2hwlBgLbc9fMNLHJUK?= =?iso-8859-1?Q?dxt6ykdnualTpUbYmL9fygdgVgwZ8bYPVAWdguPOyWZiyHVpC1eKDuq+NH?= =?iso-8859-1?Q?g6sz94QfBaiNejnsGWPJAk6mjEl9nDSdzvUvVvC2cQVaFTb7LWR0TuIkWJ?= =?iso-8859-1?Q?UiQ4hztKVuL9HyfHsM3w78t3XKTZSlRnj8bXD7YB2eeSHB0sutj/gPz3In?= =?iso-8859-1?Q?LLV1EL3CkM+tnZ3guod4UXZZ8wuE4M6tgkgTXsOm9vvLMToclukL30VUOx?= =?iso-8859-1?Q?jSBA1LOj9gDEAM0HA34sjOLBeY8eyEoJzDyGSfT6AuJexjVxcSG6uf4EOs?= =?iso-8859-1?Q?mJk14ufYK2kNvVBJ2tqWMk1/H+CSl6/GQwhtFiQ/jdJxJWiqNRN6KQxgzK?= =?iso-8859-1?Q?dlKN6FYmZkc8CgUPGvNwCzxUMlL/aclQeZquWjDNKylNz5dBbCmVtZedy0?= =?iso-8859-1?Q?CYXO32LuNQdBX9n4j601rfKGAr6/P/vEfeYm/OGLXqu61dcnMb6U452hg8?= =?iso-8859-1?Q?Hr8odS8GLYAl1H07VX3l6OcxLgLjmzKlpChg5leOCyKziH2vecsq2S5Rw+?= =?iso-8859-1?Q?r+B+NAhhxRHr8h4lQIY4R0mw22CKpr0ZSVkvDGxsmuKqXx47SES5L1SwoM?= =?iso-8859-1?Q?RQbetcrS9FB3YbXr1LjFR1SeuSS7S5ZS14iW4ddcwtLUL+6gMe0m5DABgZ?= =?iso-8859-1?Q?AB9ae8BOxAvAkgCk52+zKnW2FKbOO1hOaHLLSuo48s4gIlAD3YUO3fvGEL?= =?iso-8859-1?Q?Yj2MJU3Z7+OBQc5ceCDSEkyblLRxXw30on/z2FsoYHeQN54HwA/OeZgVvm?= =?iso-8859-1?Q?SutncRJ2Yct26bA25/NkxTB5GgIFL32WtMSopVAKoHSfORFfB33q2WpGXy?= =?iso-8859-1?Q?CW25NDkMs04QRWQzlHdNYsoi80pjgfgGjjwfrTJQRZvTaFYg0FjTIxQRAo?= =?iso-8859-1?Q?Ba4O+SwX6PCkqiUbTW4KHHvx7TucAmQkMy6og8+Mb39JNlSOYv91h4ckKy?= =?iso-8859-1?Q?zEY3QYBy3kq8avdEl4O9oXFtxlDEnkljSNkXxtJakxzDo2mJpNVgrMf8D2?= =?iso-8859-1?Q?tjCWy0YFFoXGDB3tvxSzeFk5/zjRdftnMmMdlrijKkhRWAERswledJrSbn?= =?iso-8859-1?Q?H1CpMusTmlwcuJPE451TR8RrN1Ykw5oj2fUv/dgWwc6L0IIJB/HQlJmVIY?= =?iso-8859-1?Q?Hqp196FHGLAB/1Wnezw2p8RTH8a8/gAYrccsCEY0w5NbBn70A/zZJiYbCW?= =?iso-8859-1?Q?xIr08GfV9t+MfEe/7aXa3mBtVdnYHgL3oU+wrIi8MFXeQ89HIhYq4K6Tmq?= =?iso-8859-1?Q?DwxtqxwFwTLr9DaluDtWGNR+UuOIfn5PFtS69gt8fifPRUhjtH1uBGdz2E?= =?iso-8859-1?Q?j2R1+MofdycBxFQqw/pKcrFiZpIQwxxWmiaxmFAbRNO9QWAUUle42G1KDr?= =?iso-8859-1?Q?vTQs+uCRxKFn+wBeB60a/pP9MX+6MPZL8rGPXdHT1j6z7uvosj18TaqTVo?= =?iso-8859-1?Q?FjpNR5n9dSG4KRSmF+FKIwp6YvoHZMOv9CskxEwSfPuB5nRFEt+o6+xZNE?= =?iso-8859-1?Q?J6gT1vB05jqJjCID15Np0Xyq5BdWiXJ7ft/EegncxlLqy3HDc5tgJkL2sr?= =?iso-8859-1?Q?TebiS+Ga+kNpnqCGYjoRGBhkFdC6Huz8YkFRG7pBOAbBUzPmeZM7Mt8vNT?= =?iso-8859-1?Q?mE3TPsc/Rqo4X9KNenRKT9n9T6oOyI0=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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 200f41c2-79fd-4fa8-3e5c-08df2e863341 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 08:43:21.7628 (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: RUgTEU4PjjitsExOgQ2vGzuvAx3b+DSuf9LDCnq6E2wuTqbrPNTqTvp5CSNV8DsS/OHJjj/7THHgQv+bpShOi1YETwhnkdaVAnRvDv4JZzE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8395 X-purgate-ID: tlsNG-33051d/1792485808-7448C4E9-A951EE2E/0/0 X-purgate-type: clean X-purgate-size: 18995 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 --- Changes in v14: - describe secondary agents as xen,scmi-agent nodes under agents - update host, discovery and dom0less examples for the child-node format - clarify shared-memory placement and platform RAM reservations 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 | 405 ++++++++++++++++++ 1 file changed, 405 insertions(+) diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst index d9698f4e4b..25459d22dc 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,406 @@ 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 (required for Xen; required for secondary agents wit= hout ``reg``) +- 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 */ + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; /* Xen management shared memory */ + }; + +.. 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 reads secondary agents from an ``agents`` child of the + ``xen,sci`` container. This child has ``#address-cells =3D <1>`` and + ``#size-cells =3D <0>``. Each enabled ``xen,scmi-agent`` child specifies= its + doorbell in ``arm,smc-id`` and a single shared-memory phandle in ``shmem= ``. + The optional single-cell ``reg`` property supplies the SCMI agent ID + (0..254). IDs must be unique and distinct from Xen's management agent. + At least one enabled secondary agent is required. + + The shared-memory nodes remain under ``xen_scmi_config``; the host OSPM + shared-memory node and ``/firmware/scmi`` remain in the platform DT. + A shared-memory node describes a channel location and does not reserve R= AM. + If buffers occupy system RAM, the platform must reserve the entire + firmware-owned range in ``/reserved-memory`` before Xen boots. A single + reservation may cover multiple channels, including unused ones. SRAM + outside system RAM does not require a RAM reservation. The channel nodes + do not have to be moved into ``/reserved-memory``. + +.. code-block:: dts + + / { + #address-cells =3D <2>; + #size-cells =3D <2>; + + scmi_shm_0: 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_0>; /* Host OSPM agent shmem */ + }; + }; + + chosen { + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + xen { + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + xen,dom0-sci-agent-id =3D <0>; + + /* Xen 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 smc= -id */ + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; /* Xen management agent s= hmem */ + }; + + agents { + #address-cells =3D <1>; + #size-cells =3D <0>; + + agent@0 { + compatible =3D "xen,scmi-agent"; + reg =3D <0>; + arm,smc-id =3D <0x82000002>; + shmem =3D <&scmi_shm_0>; + }; + + agent@2 { + compatible =3D "xen,scmi-agent"; + reg =3D <2>; + arm,smc-id =3D <0x82000004>; + shmem =3D <&scmi_shm_2>; + }; + + agent@3 { + compatible =3D "xen,scmi-agent"; + reg =3D <3>; + arm,smc-id =3D <0x82000005>; + shmem =3D <&scmi_shm_3>; + }; + }; + }; + }; + }; + }; + +The ``xen,sci`` subtree is omitted from Dom0's DT. The host OSPM channel i= s +copied to Dom0 when SCMI is enabled for it. Xen uses its separate privileg= ed +management channel to configure the other agents. + +To discover a secondary agent ID through ``BASE_DISCOVER_AGENT``, omit +``reg`` and use a node name without a unit address. For example, replace +only ``agent@2`` above with: + +.. code-block:: dts + + agent-domu { + compatible =3D "xen,scmi-agent"; + arm,smc-id =3D <0x82000004>; + shmem =3D <&scmi_shm_2>; + }; + +Providing ``reg`` skips mapping and probing that secondary channel during +initialization. A malformed ``reg`` is rejected. Xen always discovers its +own management agent ID. Thus ``BASE_DISCOVER_AGENT`` is mandatory for the +management channel and for secondary channels whose ``reg`` is omitted. +The former flat secondary-agent properties are replaced by these nodes. + +.. 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 */ + /* agents, shared memory 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 relies on the ``agents`` child and the ``xen,dom0-sci-a= gent-id`` +property from the ``xen,sci`` container under ``/chosen``. If the ``/firmw= are/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: + +Use the complete Xen SCMI configuration above. Remove +``xen,dom0-sci-agent-id`` if Dom0 does not use SCMI. The guest selects the +secondary channel described by ``agent@2``: + +.. code-block:: dts + + chosen { + 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 Oct 20 08:46:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 08:46:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455185.1668746 (Exim 4.92) (envelope-from ) id 1xJ5Tr-0000ee-1l; Tue, 20 Oct 2026 08:45:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455185.1668746; Tue, 20 Oct 2026 08:45: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 1xJ5Tq-0000eX-Uv; Tue, 20 Oct 2026 08:45:58 +0000 Received: by outflank-mailman (input) for mailman id 1455185; Tue, 20 Oct 2026 08:45:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ5Tp-0000eM-RA for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 08:45:57 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xJ5Tp-00000003eYH-2DEF; Tue, 20 Oct 2026 08:45:57 +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.98.2) (envelope-from ) id 1xJ5Tp-00000005YG5-0k13; Tue, 20 Oct 2026 08:45: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" 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=tExn8gEWG18jx/rCO3HfzBEnybQkBY44c4vBPT9MoA4=; b=Nvzp+N3U+xdHoyxOsUKEkDeY6L TacZ+V+uAPgcDmQCd+HEIapkVNka8IckSkF8x4H+KK1hF9n+b2xL2iPlDLpsOw9WykL60ha0Pn4TD 7v0eU0YD7s7AHDzdVNFVQu6QugPyKjd7CM48FFvwhAAPdtu+6RDmOhB0Y6YI91yijQfc=; Date: Tue, 20 Oct 2026 10:45:51 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH] x86/shstk: Fix possible crash while enabling Shadow Stacks Message-ID: References: <20261019155959.883789-1-andrew.cooper3@citrix.com> <5916f3aa-a008-4233-a562-d091eeb9dc7c@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5916f3aa-a008-4233-a562-d091eeb9dc7c@citrix.com> On Tue, Oct 20, 2026 at 09:31:17AM +0100, Andrew Cooper wrote: > On 19/10/2026 7:58 pm, Roger Pau Monné wrote: > > On Mon, Oct 19, 2026 at 04:59:59PM +0100, Andrew Cooper wrote: > >> Between writing MSR_S_CET.SHSTK_EN and establishing SSP using RSTORSSP or > >> SETSSBSY, there must not be any CALL or RET instructions. > >> > >> Building Xen with -fno-early-inlining causes wrmsr() to become out-of-line, > >> and thus suffers #DF during boot. > >> > >> Make the MSR and shstk helpers always_inline. They ought to have been this > >> way all along. > >> > >> Reported-by: Roger Pau Monné > >> Signed-off-by: Andrew Cooper > > Sorry seems like I'm a bit slow today. Also worth adding: > > > > Fixes: b60ab42db2f0 ("x86/shstk: Activate Supervisor Shadow Stacks"). > > If we're doing that, we need > > Fixes: 3037d8b7eb3e ("x86/boot: Use RSTORSSP to establish SSP") Fine with me, I just went for the first instance, and didn't care for the FRED one. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:35:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:35:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455207.1668754 (Exim 4.92) (envelope-from ) id 1xJ6FC-0008ET-Km; Tue, 20 Oct 2026 09:34:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455207.1668754; Tue, 20 Oct 2026 09: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 1xJ6FC-0008EM-Ht; Tue, 20 Oct 2026 09:34:54 +0000 Received: by outflank-mailman (input) for mailman id 1455207; Tue, 20 Oct 2026 09:34:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6FB-0008EG-EJ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:34:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6FA-00EhcT-Nx for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:34:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad735bb-bab6-0a2a0a5309dd-0a2a4503aaa4-4 for ; Tue, 20 Oct 2026 11:34:52 +0200 Received: from [52.101.53.66] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad735bb-fae8-0a2a45030019-34653542e23e-4 for ; Tue, 20 Oct 2026 11:34:52 +0200 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by LY0PR03MB850118.namprd03.prod.outlook.com (2603:10b6:404:222::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:34:50 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%4]) with mapi id 15.21.0522.016; Tue, 20 Oct 2026 09:34: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=YQbF3x92PJyH5nFY+DScOwh+ja+gTNsa7dHLGFEb6yvWFQbb+1wIR7/WB1rCAVQ8q7L3ztT0Bp3eRWNWHfSgbkTT5sjC8DmaMyYl6b3QXH/pf5QCPyOTK3t+mpOorkEB1TwExCDvl5Ukn1C4TzlTTvj22InKgCUqAvRMDQKeZu96TtsJXbyaISrfUTu5ZfUbYev/Rh0QX3YW7j7DAqjO52RWWOs7QsNHm9ISAJvI2mei7/rn5jgIvoEZ1QHprWOoIc2GfF6IbmcODVeG7oGCk/cFcmPTbY0heFUL26fMOxmNYPcNvl60tB5Rk66S/xAzLZCjlXr3DaJ6U7CvgxVulQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cK1t4aEvfoRj8dRcTAZCYSgvG1RfubWFrwaJSPwHsxA=; b=ZPEmOkbt6rWlQomDn76njyO5x7C8wkESdmx92S/dvaHmz6a8l7tc4wKlXNXXH9tZhVdsLfe25dGS549lUOYuJAEpGPIUo+CxBIZd5OwP3OIrAasLNR3orHs28pdOHzl4dxL3nl+i9Ga+iAbc/quTdjEIJ+adcNaGixq7JQKLdBYTTT5Lp6AHMb4N/PFv0nz51dAsFs+lSfmFHgptzGvVQcm2NISimwgop1VjBMHxqVymaqqDvnqcC+tdyLSrHj8cKQ+GHJIJuaB2SY6d0MCcm8NomY5799Ub3kB+grQkm3XaVmDfI/OYWSPBhtk0T83tpY2dRbvc9uksdwvzuVxrRQ== 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=cK1t4aEvfoRj8dRcTAZCYSgvG1RfubWFrwaJSPwHsxA=; b=DlmbDTnLzzngdcfn9+1ZA35aff6eUjv7MP7+hxyAdaS6JYOfJGHpnLFgyvtIp6xSeZuWvpUttZkOz8SUJmMy2B8fnVju4OM5ihmd6JuF0p8om17CBLcf41igLHmu+fHw+6l0wjA4IvBpOqA235RWoXI/fZwSTqbrsQ/Z1NSVYOY= Authentication-Results: mx.microsoft.com 1; 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?= , Teddy Astie Subject: [PATCH] x86/np2m: flush the np2m on an SVM nested TLB flush Date: Tue, 20 Oct 2026 17:34:32 +0800 Message-ID: <20261020093432.105318-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0158.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:cd::11) To CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR03MB7889:EE_|LY0PR03MB850118:EE_ X-MS-Office365-Filtering-Correlation-Id: b462f676-5141-4012-6c8b-08df2e8d62ff X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|18002099003|10067099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: g0U0vhXOqprcaY1G+OQDKRfPTZmLo76QMfsB/YENbl3pYPhFBYndx9BvfV5+iWsRrEBoMIbtIB5CUhh84tZIrYzkRTSQn81nG+K1JOcwTRpizx+korFjqlg/mJvKu5QVVjR3/bynI9XNSYHqStu00/gfdgrdWhhnwlLSZbD4ohvahsbvPVCBhlmiJz/M6dObOL67aLyPtThn8C12J9tIaQFGAbfa9tZvW5Vsy7GW89+YxhE8rQn2ohvCQTFZQll4tKfrJk6KC4OEgMxdWeOEacWGK0sIxKIigz9eUfAJ7VKAijqjphY5zdVVfYHvMfJpSHZXyvIUVw2zo/Sz8onclI1WaNGb+nvVJu6ea3DE3BNYh/F8yZ53IJE9PulluRvzSs3Ev273PZ5ZkUFblWW3QxYz6mHS+u3vgmmVIu/oXgF87pSjg8rq/4zNyGsMIESDolhN9iSWIMIa9iNZ0Z8Qz/Xglbf/OZJZjmGP3JH6I0NbzZ6G7UI96Pjj55PwTqbajPkbw9mWNSZJ6qv7ujZkXC773h/LYvZ8NcWg7NQ5jamSRNSd1R0ZtzW3tZfJDLI7+VaVkOW0y1/vbQSHCEN2N+oDy1t4eNkUu/ipuA90NbHDEQ+thVZuhWxP/AH00EU+ 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)(1800799024)(366016)(18002099003)(10067099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sJOp49k7BkzLzeJWyNZIrtO0khpn1PFOHur0A0lh5eY0H/MwYFbbAFaCmAab?= =?us-ascii?Q?BQ8Oo7/Y3lYIPt92aZGDvLTTYhomiTEXBs92Gr+zGsmCBOGM9a+N7D9p7zA0?= =?us-ascii?Q?n2q4G2UBUK4jGt3ReFpiwV9INfsl9b70egVO4c41Fgqai48je5DmIpH/OuFa?= =?us-ascii?Q?kVfoknPseCeHlp775Oi960rTrNjsTp7JoNrLtkP/kGgzD3wNAhDl//dDNGnU?= =?us-ascii?Q?goA0W64gTzJdPSrZA/nnYqOkwDLIQsvXT39KqlyytUHaKAm3FQUNONfzcHt0?= =?us-ascii?Q?NAXj7Fp0SZJ7+WGv0uYJZvzFOrKIkSesNwa+N929bcor+tN/r+b6RnyaXEwc?= =?us-ascii?Q?uJHMA4s1WOXp6Hp2+JPWuk6PQWhnRjWvem3+EjmigX+Flkrqdt4o+drhADbO?= =?us-ascii?Q?hfCGXBtI+ePnT5s9eBu/O3JmOAd4qsxr6+rLDYUkPHOiP4kFfTnc4H/Ve/dw?= =?us-ascii?Q?0SQLFb6mPIK1F/xYuwI3E5/roBqdHpPKsJSA5k8cM8+anbJ+3NnrCoS3YbVk?= =?us-ascii?Q?WO8RFXWETFx65rXkg/BYIQSSEtCqB/O/+jldhKobsM2xy0+Yk/o82IqedIhh?= =?us-ascii?Q?I21/0VcsHfEK802R/UPbLwRYw34nQBdd0nFimOWkRbtMYjek4bVIMyBssoU3?= =?us-ascii?Q?WoTZemmaqFirTqKC+x94hwjwd7k3ku6XxgQnIrd0BFmSiVUaYWY3Uhw8/eSN?= =?us-ascii?Q?xk/iLaaTECbdNA/5eT46TnhG987DCNCS5H4tMdcNh8CwkVAtcqalUwHjOvyC?= =?us-ascii?Q?+mkvVrwxrhsCNnuJGkSe6PFnlM9cnpc+0Gq/HDd6VRH68n4alA2TiDjtNNeD?= =?us-ascii?Q?pRCqauhHH7+johb/3JkO/VFJxGt3cyEogONBEKSywPOzkCPUDHJU/6QglJ3U?= =?us-ascii?Q?R24xU2A2WiETZf+KnEDuLWdEElGNZCSVR8yCf5e6VUg8NkW+Y1cuHvs4g4AT?= =?us-ascii?Q?abmjPkPev/08q93Sm+wBq9Fy4mPUlU0MgStxWpWJPr4M9CW3zl6W3RPqKfL6?= =?us-ascii?Q?9+H4luL7m4E/CyW4UoVMgjjG1Ps/AhT3+uRCWHFYHwhi1iZRFRULevV/LCSv?= =?us-ascii?Q?QybW+7fJST6sg0ytKchznYqnIeNWBqUZ6GrkD/FTkOiNfCojpBsk4Xm/MA3s?= =?us-ascii?Q?6683pzgd9CD8Pdl4bm8BCE21mkjatFImU3J6xrC8kLmlyFCKal+lMoDzfxnH?= =?us-ascii?Q?aS0u78FCwZWdzhTG7TYRccLXo5FzNRDch/mWbOyJHMHIsKDnDu1+4NF6lwQy?= =?us-ascii?Q?vg5TV6cDw8xpoj5ONBf/bpefDwPugzPUzjOVCTmUKw4PRrZrkMa1GcDuLXph?= =?us-ascii?Q?zH9xvAbSvrpNTBqZoUlj39+rGqymq88t1bdVal6rlIERNYdhZI4amAMP12mI?= =?us-ascii?Q?3az4OfD0vi98+Vx9yHXDBx1zcus+o/UHJ8c5CWGLOebm9q3gW+N+aeqY/xAP?= =?us-ascii?Q?+5rNAeVHJ2qHKQ74Yzr+vUEtmzPphlBbaBZF/z31rvWksIYFGPP7XFplYx5L?= =?us-ascii?Q?7OrkIj0Y+VxdlEhZy0DzqDn7iVS2G6lbBAMquEOywPgHVB2Z/9sqkj90l3Xd?= =?us-ascii?Q?P6yvw/Qhauod5KKLpZ41Yog5wcn3js/FGlFfAlDddHDig4xlUOMuCyjfIwdf?= =?us-ascii?Q?jCVax+A92avLfDEPAbLZuvc2AqxvidG8VwBdvKHGe3kGrkqNw7UvQ7uuMwG6?= =?us-ascii?Q?9Bwc9QDykU8zyOOyr3dbJjGq4z2UxbQ4NKgO0NhUSUDloXSk6DqdqCmORfWa?= =?us-ascii?Q?CPqCfYjF+g=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b462f676-5141-4012-6c8b-08df2e8d62ff X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 09:34:50.0507 (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: bybcPal3vhPsKQ5NhR+ToDnfsDGjMSTZa17Yrq5MdPlF2Ft27EM+aC+G5spYBFCNaz75XJ072fM2WEVgNeBKG+GJtr9RjXNqSYzGGb/Yxcs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LY0PR03MB850118 X-purgate-ID: tlsNG-33051d/1792488892-6FEC24E9-FB9CE0BC/0/0 X-purgate-type: clean X-purgate-size: 2269 On SVM, L1 flushes what is cached from its nested page tables by setting TLB_CONTROL or using a new ASID on VMRUN. Either sets nv_flushp2m, which p2m_get_nestedp2m_locked() handles by only dropping nv_p2m. Since np2ms are shared between vCPUs, the lookup then finds the np2m for the same N_CR3 and reuses it as is, so L2 keeps the mappings from before L1 changed its NPT. Flush that np2m before reusing it, as nested VMX does via np2m_flush_base() on INVEPT. Fixes: 6df4b481b0c5 ("x86/np2m: implement sharing of np2m between vCPUs") Signed-off-by: Stephen Cheng Assisted-by: Claude:claude-opus-5-5 --- Ross Lagerwall has a partial fix for this in the XenServer internal patch queue, which was also part of v1 of Chunjie Zhu's "x86/nestedsvm: rework nested VMRUN/VMEXIT handling" series (patch 5/5, dropped in v2): https://lore.kernel.org/xen-devel/20260924091605.344577-1-chunjie.zhu@citrix.com/ It flushes nv_p2m, the np2m this vCPU used last, before dropping it: if ( nv->nv_flushp2m && nv->nv_p2m ) + { + p2m = nv->nv_p2m; + if ( p2m ) + p2m_flush_table(p2m); nv->nv_p2m = NULL; + } That covers a vCPU re-entering the same N_CR3, but not one entering an N_CR3 whose np2m another vCPU filled: on its first VMRUN (nv_p2m is NULL), with an ASID new to it, or when switching N_CR3. This patch flushes the np2m for the incoming N_CR3 instead, which covers all of these. Tested with an XTF test that is not yet upstream: L1 repoints an NPT entry, then enters L2 on another vCPU or N_CR3 under a new ASID. L2 saw the old frame before this patch and sees the new one with it. xen/arch/x86/mm/p2m.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 027b9ae69b..52cadd9b25 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1547,7 +1547,11 @@ p2m_get_nestedp2m_locked(struct vcpu *v) p2m_lock(p2m); if ( p2m->np2m_base == np2m_base ) + { + if ( nv->nv_flushp2m ) + p2m_flush_table_locked(p2m); goto found; + } p2m_unlock(p2m); } -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455213.1668763 (Exim 4.92) (envelope-from ) id 1xJ6Jj-0000YT-67; Tue, 20 Oct 2026 09:39:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455213.1668763; Tue, 20 Oct 2026 09:39: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 1xJ6Jj-0000YM-3A; Tue, 20 Oct 2026 09:39:35 +0000 Received: by outflank-mailman (input) for mailman id 1455213; Tue, 20 Oct 2026 09:39:33 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6Jh-0000YG-Oh for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jg-0067sn-Ue for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:32 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736d4-bab6-0a2a0a5309dd-0a2a4509a464-2 for ; Tue, 20 Oct 2026 11:39:32 +0200 Received: from [52.101.65.131] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736d4-be1a-0a2a45090019-34654183b1c5-3 for ; Tue, 20 Oct 2026 11:39:32 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by MRWPR03MB11467.eurprd03.prod.outlook.com (2603:10a6:501:7f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:30 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 09:39: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=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=mu6fm0b9Vy2c35YKPu6Y30irjGBg1RSs83UpOaaNep0fgGv9d2DYQTg1qRP/e8t8Q6xWQjhiJkhWt9lugxox7RlRA31YExC+OcisurJIIa1o8NMcDZFfNIgqHqenmYQk0MLPlEXKSGdGJ3jv3R2hb/DNvHoMdm6fd44++cP0ma0Jaf2HeEpMsrzsR/0PNtqXnFvyO4cdqDPQLFo4ptcu2OdjN0eE47SiR0ZiOzHI4WeV2p7tpgBCm6QxrPTMx1syevLf16MKFEB4AO9k8pTsRhycbuOTFOywogw8jiUml3TibZhB+Vd3QXuR8GUUvNKbsBks4+skeHOcEUuaeEzfFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MTpEl0e6T6L52zpNiymwiLPpq0S1h+7UVL5YSn7HJOo=; b=IUFjQGStO7hfJvACLlo9Kvq1R32DMWchxKyzRdJYsfzwryiDCL9v33pgTOj+BIyglFRXE0uq+8bsbZNQnkkYn3FLvrZ2h2pc/bOTgwXyNmeNMJNpUPf+f1De9svZQOlO1I8jCgXESxUBsrIhYHQz0WaUgCzN8SYN8VuSWTtjayMKeBhvdv4VkEZc60JyEFkgl47PwQfe2LDtx45XKKGoL1lbga/WzX3Nrx9uiCHkzfLAxoGy9p0464C0DYEuZMGbpqiGNdyDti6cbyn/dFjfMwkWvHtqs2R/VA5B/BTjfQmQcFCjq+UhdKo4N36YrxV3CzWpqZv9fq77WKlcRic5Fw== 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=MTpEl0e6T6L52zpNiymwiLPpq0S1h+7UVL5YSn7HJOo=; b=ZmRhBv8xBZ1kO/Mn6wSDC2/5TjFk11yQ6Hfkc2Kk3BgT3QnZJ6jHh4FRPUJSGQHuy+h9SWdbjnaRAbUDOsim17HYBTte/1eOXh+3h+b0LRd6gQlvis8BfiA9dQYQccRcx7ijCToeFt5CTlbTzVr3YL+QS1JuBldb76GKWg+KFtgPehDu21kz5Nk4qWJb80GFc2mc3IAUbO9KiU8kFLMXL8aTxI1eZM3e10PgZZH7dvqGPtzWqJ+EVklZp8Zct1VGOObtUU/3hJImwXUrtYkwcCVKWbbWR2VLw5LatJq8KictKwNpZAUH3lsbsfNpL63w2mOpdJ42yMwb655LtRq2kA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , Andrew Cooper , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Teddy Astie , Anthony PERARD , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , "Daniel P. Smith" Subject: [PATCH v10 0/6] Implement CPU hotplug on Arm Thread-Topic: [PATCH v10 0/6] Implement CPU hotplug on Arm Thread-Index: AQHdYHbnoKYmN5snA0uGKDQEmLPurQ== Date: Tue, 20 Oct 2026 09:39:30 +0000 Message-ID: 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: PAVPR03MB10102:EE_|MRWPR03MB11467:EE_ x-ms-office365-filtering-correlation-id: 2c96a9b7-b0e3-430b-0d5a-08df2e8e0a33 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|23010399003|38070700021|56012099006|11063799006|261009223027099003|10067099003|18002099003|6133799003; x-microsoft-antispam-message-info: YEJ1EmcoYGPrCoPfepiwK+0NRsKqU5ZhFoglLQco8RrLNsJk0IQmZN8vEHeNRWhBUAegfohVTorib3ZDyTXc3gDRZ95k3umXuWJZjt7xnj2AS/3aWBQHmcbIlyA3uWgr7lB43+Y87uuVU2X2BDhCr/bhO5ZiKmV065IhP79HsOvCX2pj5j0ky8qsJVlxpPggJ/TZdj9TO6dTYmqwnIyBAUFIW3rcFDP14VJO6lZFAAimcA4Gml/CDRGkn0wQ3ONhVORy26QgtEz1qGXBffZwmGdnNoadv9fEdf5gV8VFBfQz0vrDn5lm59TguO4L4WuxfdiDmBrdrEP4VjAZJjUEEdUbwTs1lWf3mbQtYhPTQNeV8n4HhqYMXZJkurQ67j9VtA021KpR1G+KABTJ0vi+aVaCSWzp7G+7r7cUaNwiNceVfrYlxokvn+OJ1AeGpqEk/TenrMkLeY3cTiKP+Bn6LYA3AY9w59XHRs+LOAXhgdKuxCB7vm1ZIsHfbIZdMsD9N7Cz9fsc0x2HCfzpuzeadnCWsOcE9LqnAYZC6T4rITzn5NTwhJCN8mrWcifmUpqy/93MIvFzZK0WPPu4FHfqkFlC9X+ZI6MjgauTUIVwg0OBog8hnkimAOMrygrKJ0lSmDRgXSorZSOFYru7IwYXDw7H+2HOW3LWdiHHnP2I99O4nKs4wFI/zPirP32KEJlj01laQ9vJMhahFq4A53/WxdWyU8T0NqcL+7NmSouyh1I= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(23010399003)(38070700021)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?PbxxMjbH5DO1XAo0GXyxWtSUFAebICvVtuLro8evucqyroZmEJvL40W6DB?= =?iso-8859-1?Q?3RG5ly3WxaCrIDR6cLi6RfAqWLFuf0h8b7acR3hfQyZdCNe/NqllfEeXZO?= =?iso-8859-1?Q?baFCNJM4tfZjw1HnoOpnJL0YG9Fss2ocKhrq5ROZ2uEwJmsaIKklfrXvJe?= =?iso-8859-1?Q?xlKWL3gNQviktZxfS3n/RtmJd54HmXa6dWOqKjBN5DDBW1G2uoDrYxDeVG?= =?iso-8859-1?Q?xAh5D/Wf/nkUMZPYI0/2c5TXeutprA3pNGpVjJtupCi4YfOwvaz8yiRJkk?= =?iso-8859-1?Q?Wn+anrCKMUsHRVqTvGQth0IS/rlf4svxgfXIfQAHErD7V4QjRcc6OSY20j?= =?iso-8859-1?Q?KQHUXcKnhdLVPtkaDuYcw0olS8PueUnx0q8ip8g23yvHaTJXRXH1ynckTp?= =?iso-8859-1?Q?9wBKA94AUZ5kOXIbfCPNyiYzqs8t+9FyBmSavLfbqvVt06aivZk4/aUXE2?= =?iso-8859-1?Q?1f5P7i0qgcXlbaEX+p9KlqoxPz3oTpSwFHVNQss8qji+wKwn7NOJIhAQDu?= =?iso-8859-1?Q?Lejw8sAlsvwI8d2v3P1NdR8V4TR7FT0kvb7rMLMzL0fFzfb6rsHaOtx0Tc?= =?iso-8859-1?Q?PN4ME76r8BUqDW+7X2Vd1MXEy3A4fRFTpnfAqLU2NvSTUGxFlPCe3OWVMP?= =?iso-8859-1?Q?S/UKUNguTdMpF05Czhq4mOdBcrw2jYrjU+loDKSNvmiINAPak51Ci/D81q?= =?iso-8859-1?Q?y0xHaNeOi4/YsS+AnlMpKM/CgoDW76vIiSz+zAMVWcGwRaLCS0Q0Ctsa0F?= =?iso-8859-1?Q?J+7jrZ0Tvt2QJV+B4Ey9DibTjS0wgMnoAURtpCRM2Tv2YL++NpUK40lVxb?= =?iso-8859-1?Q?4cG5HJOL+B68sxyi9JleOs+mixOGIKeSQAq2vLyd2IncJ0MZi1R3ogAyJS?= =?iso-8859-1?Q?jjfo3DYSB/Yj9Xxo2fGQOyhBWcwNGpAY0bdyxgbM7TYR6JXm7B0h4aR3zX?= =?iso-8859-1?Q?uQWKj19d5Lwlajwl0632vkuPwOQtYquUDbWokeuU8kF08cvuOrCDBFzPe7?= =?iso-8859-1?Q?8aFvbpmfIzxgEN6+RS6chRl5cvpUbRNfKxihPRgZA7QnZJfyPNmDBFdo99?= =?iso-8859-1?Q?aJpm+UgsectjXyync3qb25EyxscMWmrmQjNXfga+Ck00e0uy6WL6xzcsFD?= =?iso-8859-1?Q?OIFnAvQIL3WNfHYpwLjp4Fo7gYY9i5OR3G4+bjkSjm29BKhrEdq0/Gbnfv?= =?iso-8859-1?Q?xID7q6xxXQYxDp33/aqpWnKQdhu4dYQZHlg0g55Uu1ZaJpZuI3Br4F6QfP?= =?iso-8859-1?Q?QxTAlOBcLY/fRIGtpPW0oYYh4rp9hUj/ViVChxP13AGTXi6Iyt1lnSuoth?= =?iso-8859-1?Q?SLA2ZYtX+uUG4AIBCwkowbqERIQn13hXSJlzlxejqCQCoyo8dtQfx90edn?= =?iso-8859-1?Q?YwItWcyp6UrSk/HtD9bG9zfCwRrgXHJ04wG1dMnmywqfJ9qjqlaEKTeJlM?= =?iso-8859-1?Q?n971WyMd1QBiI5fa0gYme+4mMWX8iy5npT6wkEKYYT+zkHuJsvOKlwzEcP?= =?iso-8859-1?Q?XJqFg+PUMNfopTwvHytrXUBEjLwO2Pl3SKIYK012dyOppo/VboUWXW+bzp?= =?iso-8859-1?Q?SgDhRnZuQSykW0PvrIIiOjJUll2Jw6iXAaNtk3HixSobGFsyMpHr85nR51?= =?iso-8859-1?Q?PVvT/ag+ER4BJxsxA99rtmszftq050zFGbhqnLR58OZ0PWUYHAtuxDo6qK?= =?iso-8859-1?Q?PoCkKBqIJWWkLj1r+JquEfYXg8eDTQV5hCzpdcLovhsYKBoR3aZJ6V6wSm?= =?iso-8859-1?Q?uSfKfzRC2qUfYoYTbpY9IhDY1dVLLueRlnKa4snHl3e+nZKQ4ifmuMTRwC?= =?iso-8859-1?Q?D7Ud7MF6GA=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c96a9b7-b0e3-430b-0d5a-08df2e8e0a33 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 09:39:30.0819 (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: 9Crj4e60G3P6uuWnm2DExr6PErxhEXCMfAWHdL40MEQOvNd3KGHocyxxIO6HxYBhXxI+PxFe0m/I/6j7j4KsHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MRWPR03MB11467 X-purgate-ID: tlsNG-bad1c0/1792489172-BE4DB034-0C96CF6D/0/0 X-purgate-type: clean X-purgate-size: 2389 This series implements support for CPU hotplug/unplug on Arm. To achieve this, several things need to be done: 1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented on Arm64. 2. Enabled building of xen-hptool. 3. Migration of irqs from dying CPUs implemented. Tested on QEMU and R-Car Gen5 HW. v9->v10: * rebase * see individual patches v8->v9: * rebase * see individual patches v7->v8: * see individual patches v6->v7: * new patch "Kconfig: Make cpu hotplug configurable v5->v6: * see individual patches v4->v5: * drop merged patches * combine "smp: Move cpu_up/down helpers to common code" with=20 "arm/sysctl: Implement cpu hotplug ops" * see individual patches v3->v4: * add irq migration patches * see individual patches v2->v3: * add docs v1->v2: * see individual patches Mykyta Poturai (6): arm/irq: Keep track of irq affinities arm/irq: Migrate IRQs during CPU up/down operations Kconfig: Make cpu hotplug configurable arm/sysctl: Implement cpu hotplug ops tools: Allow building xen-hptool without CONFIG_MIGRATE docs: Document CPU hotplug docs/misc/cpu-hotplug.txt | 99 ++++++++++ tools/misc/Makefile | 9 +- tools/misc/xen-hptool-x86.c | 278 ++++++++++++++++++++++++++++ tools/misc/xen-hptool.c | 293 ++---------------------------- tools/misc/xen-hptool.h | 15 ++ xen/arch/arm/gic-vgic.c | 2 + xen/arch/arm/irq.c | 70 ++++++- xen/arch/arm/smp.c | 9 + xen/arch/arm/vgic.c | 14 +- xen/arch/arm/vgic/vgic-mmio-v2.c | 11 +- xen/arch/arm/vgic/vgic.c | 21 ++- xen/arch/ppc/stubs.c | 5 + xen/arch/riscv/stubs.c | 5 + xen/arch/x86/include/asm/smp.h | 3 - xen/arch/x86/platform_hypercall.c | 12 ++ xen/arch/x86/smp.c | 35 +--- xen/arch/x86/sysctl.c | 23 ++- xen/common/Kconfig | 8 + xen/common/smp.c | 35 ++++ xen/common/sysctl.c | 32 ++++ xen/include/xen/smp.h | 4 + xen/xsm/flask/hooks.c | 2 +- 22 files changed, 645 insertions(+), 340 deletions(-) create mode 100644 docs/misc/cpu-hotplug.txt create mode 100644 tools/misc/xen-hptool-x86.c create mode 100644 tools/misc/xen-hptool.h --=20 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455214.1668773 (Exim 4.92) (envelope-from ) id 1xJ6Jl-0000lG-Bt; Tue, 20 Oct 2026 09:39:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455214.1668773; Tue, 20 Oct 2026 09:39: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 1xJ6Jl-0000l9-98; Tue, 20 Oct 2026 09:39:37 +0000 Received: by outflank-mailman (input) for mailman id 1455214; Tue, 20 Oct 2026 09:39:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6Jk-0000kg-89 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jj-00225F-LB for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:35 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736d6-2eae-0a2a0a5409dd-0a2a450882cc-2 for ; Tue, 20 Oct 2026 11:39:35 +0200 Received: from [52.101.83.127] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736d7-f659-0a2a45080019-3465537fb3bd-3 for ; Tue, 20 Oct 2026 11:39:35 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by GV2PR03MB8750.eurprd03.prod.outlook.com (2603:10a6:150:ab::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:32 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 09:39: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=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=Sub0qD6tLH5BcfaUcWApBX2667l47BmJ0pUhwAxyr4mYnbMLU/qFcsny0HsnCFpeQNKlPzmU0Akarr0JwWjzuwT/hwKNSNR8rPq1Xg0TuaYfei7cd/5SrMDRpE68d9nOM809svfTHmIxDddYr8Ixj0FgPMbNDRNr86LjelYvSWDeuPFh3F+eNl5yYHySKnyom4wXOhhzL6l4uZLHpyV+RJNrs0iJSefhTdnDfIBbp+CWmlh3tjYsjfjdQsWSJagM7hMSTH2/smkJZw5nagneUsNRpjbNKCLlM9BTBEKDzQW0V2LyTCrp93/aS0PUbti/64xEdq1943UOBxkfR4FRlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OdTcdhGeUFmFSGj+TanNgCix0RM6shODJJfkVdvycEY=; b=nG5fY7CQcHk1wMVEEu8Ty7NjlJTbRHp9E5+bAnTFJJzNDhFWKcg/tKeHhNruC5Aecx6lUA9LVJzL78n+9mmEtgXo01t6wQkY8vdqEnmHVJWheXDcMqMQWzDfa4RxWJYJIJC0qBH32StnyjkuxzEA4J0xEg67Ej/UsHHe1s6uCsUd1EC5TBvEMY8MROdC6lG2mZ01tD3sydM3iIwVP2WiXCssLg9pNR6UKS8Rg+AdEeQcxqT1EAlr2ZSYPIE2d+7LiLWsbuFSWj8OoAPWZOV0S96WDQp+x4kCAOmVPEKOzcb+lSRLsbZT/+qFRtPymErjcIF5h1Kl4l2JO0BCnsmYbA== 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=OdTcdhGeUFmFSGj+TanNgCix0RM6shODJJfkVdvycEY=; b=bLxUrUEriVMOSdjzdZixLNZuJzzhsNR4rbefgL9QtM/WHQecJgKhYrWVXoAy8AckhSSVPGoIyx/SrPYpwqQzmlI9Zhw821vlQUZRMn6l0OAxcAO0xVyUmMi+F5odYTEj6zlbyOTzFlhccGsVi7Y9jN6GfEM4Dkl/yJujRwbubb3rGLBHExI13MuSNP+M7out4A0cEztLv/P2/nWIoSDQ1chi1hoVMk0MfgymN8sfY/b4MqZb9N9ljv96UF5ueSIxtQxvVdbqheYfd1p6pKQ+jiwvFa4LwJTbbLm59lYgeiWkNS+9tBBJgX/pE3X8hYmKiJFbEnrNmfjPmTdlPtRa6A== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v10 1/6] arm/irq: Keep track of irq affinities Thread-Topic: [PATCH v10 1/6] arm/irq: Keep track of irq affinities Thread-Index: AQHdYHbnTjLdfq2txEihb/QFQv2VIw== Date: Tue, 20 Oct 2026 09:39:30 +0000 Message-ID: <27ccdfb942a02de88bc0d384de899da229622366.1792480416.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|GV2PR03MB8750:EE_ x-ms-office365-filtering-correlation-id: 4ebfebe6-d313-483c-7979-08df2e8e0a9e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|261009223027099003|10067099003|56012099006|22082099003|18002099003|11063799006|38070700021; x-microsoft-antispam-message-info: Kxcr3nRWfGgOPNtShxUoTQPm1O9e+bZQJgfsJIi69UtMLWj5e3A6+aluBfF2XFdk9zHwtppiQxPvq8aBTZm1uTQs2mmcQ3sXUdSATOr/ACAedbzk8Z2nMMKrvvksBYVaqyH2jdBRHvbQykkusVs4F/FRWKBruTdSVt2I5bePHigmrdqfdXc4NyHcl99X6nraIIw6r0YPMwjvuoSqiHVR2sd71nn2y/XDxI+084ACB/BLsAh2RlSJTBXRrtZ1KU3s3WVQSto4MV/7/3DaMzUPxubHWmzHYuo3GmEK23cJaLrmebhCNXMcGuXIfW9+yfMklF7t86T62yt/+vJLk/o/GZo99KK9Dq5F/R/HDqzD6+153WoJ+eG31V8xsY+N/7RCh16xRO1swE29eJBB7jKOIZyUjlTjpCRijHVq9/5O8gx2LfohjMvaj0e2RFMrOFyEAP7ODagPDHKF/OtwXXUNg5N0Z1q9R1Fv71MKS6h0d4YWcH7reJvYUSUreFIF20gsipLfJ1QlMqTaJb+MuM8IsuutMtKUjXwiKjPq30a3kjqjK58nlMTs8zrWJWaw41HFyq8FhxE79QS7z+5Za24o2Ie1pWrYdO/KoYbyl9yFI6NvMpQ7ZUEw4F3tJuta40I6s8YsKHfCgBfkRFHKde4LgoQ/kOKMpJeRIMvvwvXCtTn63XQ4dKq/qIKmIdZpFAkjYqkSSjc6w98xEqxp0uKiYZYfPtpC9X4kl19Da4S+8JA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(261009223027099003)(10067099003)(56012099006)(22082099003)(18002099003)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fUq9oCuUeDUBVhsDKCFHPNKKivC7bjVM4zoK9iF4mnd+WUEN5LXoaopnN9?= =?iso-8859-1?Q?NPzIBTq1JOziHqovMcWZO7Byu3ICS2Tqdp/LCz874QTd3kKMQmgs5D197y?= =?iso-8859-1?Q?lhVbpWHgkot3B7seNu+18zTGdiz4Yh932yuBlNuRNMsOhkp820Iix/mKIl?= =?iso-8859-1?Q?yKzmgC13BvthRr5Md1SfvZpAYeVEbLLZnAu6vAXpFHltNcNf/IkpYjeS2q?= =?iso-8859-1?Q?xUj4YBDnLgF5fELhDeXmuVisfOeXqqqbFQtqwA404k596QZbmFyQsQQoNs?= =?iso-8859-1?Q?lt2Gw2h9+QtGlTwwfgI13hdiPiOgOAAau2+bvusrUAS0AJLlFuY96/gdDu?= =?iso-8859-1?Q?b5qy7o0UmZ8kkIlSZzJg4zLoOAoCEpLbB1Cckdmc9dhPH3dTgOyAbnu/Dw?= =?iso-8859-1?Q?pHWZUdTtZ1QhOfo1EfKSlHqDg0v2p3urxXqNxuGXiR/BaKTQFQvFpOkpGL?= =?iso-8859-1?Q?fEgIIiLPPcBnmWoOB+fRYxbCYQGFldl/chVGH99rkITlCzcsTBcmVgq6qe?= =?iso-8859-1?Q?Y+XnVS7ju+jmDeXipxti678Gig0ZC9kGktWsZL3mtcmLMnDgUdsvi/ckp0?= =?iso-8859-1?Q?RXqZK+bcOniffaFoVRRCcxR8hL1eDXunKPPPXX8Nv+TlWy/ioDeSkljkCU?= =?iso-8859-1?Q?DpC84yiwPc2Bqbk3WRwBFZzOzgUtOJ96Aq8HYWrr3eKGjS+xtk57nRWnA7?= =?iso-8859-1?Q?lBVN4CqW7kIFwX8X3rUeWB9D4H1rsvJHkektwtBkfgv/+U0ZjkiapvVD/b?= =?iso-8859-1?Q?PC2q4cnY+rM+XRIP7Uo+8OutMR06vLqqGXbk7daSziccg9emAqCcskTyRC?= =?iso-8859-1?Q?UaYZ3F4+jN/XnUBj7ZQYa1trprtxlG1HP3LKeOF/pAz9nel9Atm9gbbrr7?= =?iso-8859-1?Q?+rPP3PO9FGAStl+9Sr3YSDX6lFt+ZSwUkDq/M8DR1oNk3P+hWzjnQ35hfr?= =?iso-8859-1?Q?Sw92CpziIo5WpzDBE5QzixUvYPjo9S6YWqIXk9xuFQO91kYRsjElByl5g7?= =?iso-8859-1?Q?Sd/ZAPtUkvxnyqhG9AG7be8Ue19tsPddzVBhcFl1lh4I5RxDxGjIHOZWPG?= =?iso-8859-1?Q?R9Cea3JRGjPOjpSFX3uNu3lZFDY2b75b6y7eaL8lESGF/wRzfwGGb+lh9/?= =?iso-8859-1?Q?MMb/BYVd73W8rU9fXIB5Fwg8Shoihwm3VyQXA5k8to/NuyNEZjBkLOILAl?= =?iso-8859-1?Q?FWwjTY2tbzSEbKN8eyKC0JpByvu2wEXrlyk1ZpKMYaelNyBuo/6kEbhRa8?= =?iso-8859-1?Q?1FGfLmEMN1ScNdByB9oPXoCtQgDRhnqJ7jJTxopOf8F+PG+HQbILP5585f?= =?iso-8859-1?Q?T+3BshLnP3fKXFdI1uy64aCLfeIfo5PdQj0ezYpbYguwrs7yLXfxaDG8Q/?= =?iso-8859-1?Q?92bCrnkPhFDYxWAKqfZ57qzAOkmW1QGfrET/OYmz/053nBH42ob3r9raJT?= =?iso-8859-1?Q?e/VQjDAtBCpMCcczzkjHraq69mQF9cImZlPbtBcQ3SDauYumSXWLg4Pw65?= =?iso-8859-1?Q?9xWH8FfYhr251s6JRnEe/lQFki7pi8su3hkKTmj7SqEDd4cbs9tP3B2M54?= =?iso-8859-1?Q?84Djwxi8zxbTAcZyL7GZCZN6xZiSM4Ts/tyeo9QASyLoV/pjT467c2lJyt?= =?iso-8859-1?Q?Ib3lTff8RGxqWMv2F4KmCFp8z0WXQT59cdZWXbQhmp5VJrMi3rKSA19Gp3?= =?iso-8859-1?Q?4SkHXMZym+Mh/62M6LXTH775gWmIQTz5P3HD94kTUCh5BQ1AZNo0jntmvr?= =?iso-8859-1?Q?HjA9mnys3iIRct1H5LRecrYMW3eHVwwHvMiyXDzwQKoABBmjS/t1+GlZSq?= =?iso-8859-1?Q?9qKfr8rLqQ=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ebfebe6-d313-483c-7979-08df2e8e0a9e X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 09:39:30.5337 (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: koAXXH9B85TcyX4tmN317gsHb4GyjZfB6kQ5YABwRPjX+RQh1ImVX1C07lQ7cdAHsZih4sYOg2wJL3/EOMycCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB8750 X-purgate-ID: tlsNG-c1860d/1792489175-D715E87B-5518C772/0/0 X-purgate-type: clean X-purgate-size: 7565 Currently on Arm the desc->affinity mask of an irq is never updated, which makes it hard to know the actual affinity of an interrupt. Fix this by updating the field in irq_set_affinity. Changing desc->affinity requires desc->lock to be held, so add an assertion to ensure that callers of irq_set_affinity are doing so correctly. With desc->lock now being required for irq_set_affinity, add locking around calls to it where it was missing. Signed-off-by: Mykyta Poturai Reviewed-by: Bertrand Marquis --- v9->v10: * no changes v8->v9: * no changes v7->v8: * no changes v6->v7: * update commit message * fix possible locking on null desc * collect RBs v5->v6: * add missing locking around irq_set_affinity calls v4->v5: * add locking v3->v4: * patch introduced --- xen/arch/arm/gic-vgic.c | 2 ++ xen/arch/arm/irq.c | 9 +++++++-- xen/arch/arm/vgic.c | 14 ++++++++++++-- xen/arch/arm/vgic/vgic-mmio-v2.c | 11 +++++------ xen/arch/arm/vgic/vgic.c | 21 +++++++++++++-------- 5 files changed, 39 insertions(+), 18 deletions(-) diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c index fae80e6cd2..28ad4903b4 100644 --- a/xen/arch/arm/gic-vgic.c +++ b/xen/arch/arm/gic-vgic.c @@ -232,7 +232,9 @@ static void gic_update_one_lr(struct vcpu *v, int i) if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) ) { struct vcpu *v_target =3D vgic_get_target_vcpu(v, irq); + spin_lock(&p->desc->lock); irq_set_affinity(p->desc, cpumask_of(v_target->processor))= ; + spin_unlock(&p->desc->lock); clear_bit(GIC_IRQ_GUEST_MIGRATING, &p->status); } } diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 8d3517e761..594aaedd22 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -224,10 +224,15 @@ static inline struct domain *irq_get_domain(struct ir= q_desc *desc) return irq_get_guest_info(desc)->d; } =20 +/* Must be called with desc->lock held */ void irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask) { - if ( desc !=3D NULL ) - desc->handler->set_affinity(desc, mask); + if ( desc =3D=3D NULL ) + return; + + ASSERT(spin_is_locked(&desc->lock)); + cpumask_copy(desc->affinity, mask); + desc->handler->set_affinity(desc, mask); } =20 int request_irq(unsigned int irq, unsigned int irqflags, diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index acded6a40f..53f36780d1 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -490,7 +490,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *ne= w, unsigned int irq) =20 if ( list_empty(&p->inflight) ) { + spin_lock(&p->desc->lock); irq_set_affinity(p->desc, cpumask_of(new->processor)); + spin_unlock(&p->desc->lock); spin_unlock_irqrestore(&old->arch.vgic.lock, flags); return true; } @@ -498,7 +500,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *ne= w, unsigned int irq) if ( !list_empty(&p->lr_queue) ) { vgic_remove_irq_from_queues(old, p); + spin_lock(&p->desc->lock); irq_set_affinity(p->desc, cpumask_of(new->processor)); + spin_unlock(&p->desc->lock); spin_unlock_irqrestore(&old->arch.vgic.lock, flags); vgic_inject_irq(new->domain, new, irq, true); return true; @@ -518,6 +522,7 @@ void arch_move_irqs(struct vcpu *v) struct domain *d =3D v->domain; struct pending_irq *p; struct vcpu *v_target; + unsigned long flags; int i; =20 /* @@ -539,7 +544,13 @@ void arch_move_irqs(struct vcpu *v) p =3D irq_to_pending(v_target, virq); =20 if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->s= tatus) ) + { + if ( !p->desc ) + continue; + spin_lock_irqsave(&p->desc->lock, flags); irq_set_affinity(p->desc, cpu_mask); + spin_unlock_irqrestore(&p->desc->lock, flags); + } } } =20 @@ -619,8 +630,8 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsig= ned int n) spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags); if ( p->desc !=3D NULL ) { - irq_set_affinity(p->desc, cpumask_of(v_target->processor)); spin_lock_irqsave(&p->desc->lock, flags); + irq_set_affinity(p->desc, cpumask_of(v_target->processor)); /* * The irq cannot be a PPI, we only support delivery of SPIs * to guests. @@ -975,4 +986,3 @@ void vgic_check_inflight_irqs_pending(struct vcpu *v, u= nsigned int rank, uint32_ * indent-tabs-mode: nil * End: */ - diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio= -v2.c index b7c2d7ce99..fc04741ca1 100644 --- a/xen/arch/arm/vgic/vgic-mmio-v2.c +++ b/xen/arch/arm/vgic/vgic-mmio-v2.c @@ -159,24 +159,23 @@ static void vgic_mmio_write_target(struct vcpu *vcpu, for ( i =3D 0; i < len; i++ ) { struct vgic_irq *irq =3D vgic_get_irq(vcpu->domain, NULL, intid + = i); + struct irq_desc *desc =3D irq_to_desc(irq->hwintid); =20 - spin_lock_irqsave(&irq->irq_lock, flags); + spin_lock_irqsave(&desc->lock, flags); + spin_lock(&irq->irq_lock); =20 irq->targets =3D (val >> (i * 8)) & cpu_mask; if ( irq->targets ) { irq->target_vcpu =3D vcpu->domain->vcpu[ffs(irq->targets) - 1]= ; if ( irq->hw ) - { - struct irq_desc *desc =3D irq_to_desc(irq->hwintid); - irq_set_affinity(desc, cpumask_of(irq->target_vcpu->proces= sor)); - } } else irq->target_vcpu =3D NULL; =20 - spin_unlock_irqrestore(&irq->irq_lock, flags); + spin_unlock(&irq->irq_lock); + spin_unlock_irqrestore(&desc->lock, flags); vgic_put_irq(vcpu->domain, irq); } } diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c index 84212bbefe..663fa16995 100644 --- a/xen/arch/arm/vgic/vgic.c +++ b/xen/arch/arm/vgic/vgic.c @@ -815,22 +815,27 @@ void arch_move_irqs(struct vcpu *v) { struct vgic_irq *irq =3D vgic_get_irq(d, NULL, i + VGIC_NR_PRIVATE= _IRQS); unsigned long flags; + irq_desc_t *desc; =20 if ( !irq ) continue; =20 - spin_lock_irqsave(&irq->irq_lock, flags); - - /* Only hardware mapped vIRQs that are targeting this vCPU. */ - if ( irq->hw && irq->target_vcpu =3D=3D v) + if ( !irq->hw ) { - irq_desc_t *desc =3D irq_to_desc(irq->hwintid); + vgic_put_irq(d, irq); + continue; + } =20 + desc =3D irq_to_desc(irq->hwintid); + spin_lock_irqsave(&desc->lock, flags); + spin_lock(&irq->irq_lock); + + /* Only hardware mapped vIRQs that are targeting this vCPU. */ + if ( irq->target_vcpu =3D=3D v ) irq_set_affinity(desc, cpumask_of(v->processor)); - } =20 - spin_unlock_irqrestore(&irq->irq_lock, flags); - vgic_put_irq(d, irq); + spin_unlock(&irq->irq_lock); + spin_unlock_irqrestore(&desc->lock, flags); } } =20 --=20 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455215.1668782 (Exim 4.92) (envelope-from ) id 1xJ6Jo-00010d-LQ; Tue, 20 Oct 2026 09:39:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455215.1668782; Tue, 20 Oct 2026 09:39: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 1xJ6Jo-00010U-I3; Tue, 20 Oct 2026 09:39:40 +0000 Received: by outflank-mailman (input) for mailman id 1455215; Tue, 20 Oct 2026 09:39:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6Jm-0000ww-EX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jl-00CgDe-RH for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736cd-8faa-0a2a0a5109dd-0a2a450188f2-20 for ; Tue, 20 Oct 2026 11:39:37 +0200 Received: from [52.101.65.122] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736d9-5984-0a2a45010019-3465417ac47b-3 for ; Tue, 20 Oct 2026 11:39:37 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by BESPR03MB911377.eurprd03.prod.outlook.com (2603:10a6:b10:106::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:34 +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.0522.013; Tue, 20 Oct 2026 09:39: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=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=BhZ5yRXvwFLcK+tDhvI+94aShrNWVBuupxibGtTJljvAFiaUW9hbcwl8lkiMvEaWS1kY+S1MJv6SQG8KT1UZQ6eMygazETwE40/1OW0mK5uN0axoCdWwycaLatb1HJRcHvmWbJN0DrGqeqG5MpeNSZe9v2ghbOiMT51a8/bIO5FLt5fOI6Xv7MDRmQW7FSkZw/Vt8B7egvuRPT6X6LkUyJzkEnbZJxjxFNyU0sVSvEkEMkzrH9IF0XYg2NguphfaxLP3QAkZodzUx9LcLYZ47qc0cwtnYBJEdMICy9g5xf1C+8TphkqV0oQ/j9Vk9UB81KfEw9eoH4sGpcELeVascg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eG3bWNE9IXXA6p9ws4tzCLKJumsCa58Moj1A2q7tPnQ=; b=IKh/mkJdHQb025csTxq3OvCAEX0yeIgD/n3UERG+RVlgm4HaQje0/UnlmmWndr8JequTvh6iFinVof+4pMS/WDYZeEgRdXmIXrd/wcpk5Upo0w8IPSga4OlBM0HjXcbUSFhvxP21/lQuEWPiSc9UWVPk4LNRkvFdkViRI2fa9LKLaFIKXKO74mgr5GClkGQw2zdMGIlxdRGVoOz7qU20/dsX/b2PbwJWdwHg3iTnFpsLTqgkbZYQxK8UAwaMtvM/aVm3wfYJZtSu/yqdHailzQexavACYxFG97xQtrOWVGGa71JYKG6slk43S8MFNguL4jMN3Dvwkm/yqTlRVC8Hxw== 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=eG3bWNE9IXXA6p9ws4tzCLKJumsCa58Moj1A2q7tPnQ=; b=unNmwU2bM51/dJKQE8+sL1Psc3gvj9zrMvMiInLn0fyfjXDxWgbnJPN9rfD2PiZAXsWQaz3nlS23yltu+a9hjpWFhT47ETRHjauBmbb9qQ4WVfP/IwdK2FaAA7CSN0Vt1qA8pXhQzcEqnA+3IDWOi1d/jksb3AvPxcrJL496cqO5x2WOqnI4s7q5l/xrZ/yrMrTkmqKR7wALqXC2xCvRjiO5n6S3tPYXoZANK5vRsjnGCEsZE2n5heRJGynS7218oTWdDbbHWAECnL/pWLjUv9IgehF5xKpmBIVg0InH52upR3pJWLw1uchsIJ3b+wA7Exq6A1aBhuYHdttkY8c4qw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <4090edd7-03d1-466a-9b06-e724b93c5b3d@epam.com> Date: Tue, 20 Oct 2026 12:39:33 +0300 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 08/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks To: Bertrand Marquis , Mykola Kvach Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Luca Fancellu References: <1f036e7ad5ad6efba635ca029b0fab133300603a.1787838455.git.mykola_kvach@epam.com> Content-Language: en-US From: Mykola_Kvach In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: WA0P291CA0017.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::16) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|BESPR03MB911377:EE_ X-MS-Office365-Filtering-Correlation-Id: 0e6736cf-266d-495c-0acf-08df2e8e0cc4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|6133799003|18002099003|22082099003|3023799007|11063799006|4143699003|10067099003|5023799004|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: 0TSNrJdr+6W72YliT7gEg3CmYX+PzV+/DUGx69tjFsXvIGzrat11yPjVTWpfha98C7TdU0X20XQkk+a0xcipxNgynw1KFHDB8F5tiCMwEO3quJz3hduycl5+L4xk39SmQ5OC9wcOw2S+Y72Dl8OMVChKg6h/FzOOH4eo3KzF82iiQz2o0OBuDGb76ASeR55d2lqbBzJPUE4pleDERy2PH+DsKTm3kaXmvVVhpB1NI/874Ct4dzH/9REnmrBzNFl6j2tpaG5YJGZgell0/5uA146GuitB7tyorcs1A8I3Y9Oasi4CQ6i84yYbIA2WmmkfpAPeLyct77nGu4t1Uj1KHBP7vaQjvFMfNBCgswUYgJwJoTYfvfacsJLLOLhHhYS/xMfBMKgJTnLO05xDHqYDwhKX+PuxnxSdepuOcgmfuHFjV7uTMGtLatSSUM76v18V+MjPcfiyxGAa9TRWlRPRBPSrww88VzmlXIaWD1pDiXoaooEzuZIzMUTH6VGZtp/g2cE7XWscwB65EimuzqS5AD3hLvjgcz2Vc0SZikXNqRTEr/3tCZMOk7zBCmtS3UM+dw3lNV6fC0FfyVPVY4EGrqf4n11+2hCxHpQLtxhxIoWs1LHZ3iuvKZSq906m3dgw+sUJyXoh7cICitzoXHqmS+bJ36CwX10Lp5+5r5jjVEo= 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)(23010399003)(366016)(376014)(1800799024)(6133799003)(18002099003)(22082099003)(3023799007)(11063799006)(4143699003)(10067099003)(5023799004)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M293MHRRdU9ybHE2ZEZ5d1gvL3UzYlhGN2hWd1dxMFAya1hnMTJROUJUUS9h?= =?utf-8?B?UVYzcW9FTEczYitqQ2RyczJtL0tTVGU3YlZKZmM1d3FjQmxxZWNZZWRKOVRn?= =?utf-8?B?NE9HaWhqbElvL2lpTGcxaHFHZHpQMHdGN0lGYVRHR1Y1dGdzWEo1VGhDV0VF?= =?utf-8?B?SUw0Tm1hNW43SlJ6a0NsRGJKZlppbG5EZG9UQXhtdFlObTN0QVpHaW1sTTZZ?= =?utf-8?B?cVVCdTJISnN3alFrZGxPN2FNWThreHRHb2I5YzBkcG8xdTZnQVJQbWV0bmth?= =?utf-8?B?Z1RpWUZ2S2E1VTBxWlBvSVk0bGpaSHJDQnNRQmNDRk1wUjdtRW1WQVdva1N2?= =?utf-8?B?Q1l3S2NqanAzZ0Jja1VXZ2lOaDhXWlZkcmxCSVQ0cXhacTJXa1dYR200Tkl1?= =?utf-8?B?azVpRzNqYUo0ZGlLdE1OK2NjK3Brak42YVUyeTA5UlBBQVJCRWw5NmdqTXMv?= =?utf-8?B?SkZUR3AzN283eTJ5RHhibkdESWUyQ3A4aTJVV29RWVlVb1MrV1lObmVWaXdQ?= =?utf-8?B?NGxxdzFYb3pUKzUyUDFxM2UzaXJBRSswYVpRKytncEkrUFhaYUlsWXUrU0FC?= =?utf-8?B?eTFvQnZvS21EakRETGZiT0tkVzdzMnVQMUpTcG5ZeHpSdEQrU3hqZDJLZGNn?= =?utf-8?B?MG4xWXE5c0xGalV0RTVWTXNac2kyZHFheTkxeEdSQnNVYk8yUi9UMWc4aUky?= =?utf-8?B?T3VQangzSmxZdEcxcjlpZ1l5L253eGJER2xpVjNpSG8rUmhHNWtSY0lXeHBl?= =?utf-8?B?TXdvOVJQRXpCeDN2ajV4d080dFZpRVRPb1k0WkoxR0pXUENWVEl0N09ZV3B0?= =?utf-8?B?RHl6eHVsQ0JVemRWQTM0Vll0TzVudWE4VzBCQUZyV3BHSTMxSnRJc3pOVjVY?= =?utf-8?B?L1YzekVmQWRmd3Z4MEJPeFozbm9vOFdINzN0QzJFY2FBZlVQRTZqRkRKS1NL?= =?utf-8?B?dWxsUXJZcFdRNmllcTMzUW52TFcySGwxV0pDa3lwbWIvaU5Sb3gwSkFTckpt?= =?utf-8?B?Qkpsanp1S1V1Sk9ZMEhSWk5mSW43TmRyQWt2YXRmQm1ERXlYWjhCSnFveDhY?= =?utf-8?B?Ri96cjZwQURXWTJNMWh5QWdiZ094eG51TGRnSUVGVFI4OU1zSUQ4M25RRW9Y?= =?utf-8?B?aXpyWllhUGRhdXRnWTljTU9zazhnaU13TlBCUnBsOEliZFl6bi96M0NRKyt5?= =?utf-8?B?RGVrc2QrY2pNdkJqenY3MjBaSGxuaFY3TE92aE94eDJ5N2ZYekJ4Qld2RURW?= =?utf-8?B?MFZRc3R2bzZSMm5pZk0yMzJFZC9zak1UVW4xZDc0SDhvT0k0Ymk5Smc0SXVj?= =?utf-8?B?Y1ZSS0s4bU5ZUkxaMjZWZ1JISWxjQW13MUFiU2d1c05PTHc0VTFjUGFiejQv?= =?utf-8?B?cFdtOVNaamc4Tmw4TytpMmRvZ1ZqVTNycnAzVlE5SmIwbURsL3ZBL2o0bFBH?= =?utf-8?B?ZXQ3azhiTnNRZlFNb2dIOVR1MWJCSUtnZmZscFFnaFcvSy9GUVZCUlNRMTY0?= =?utf-8?B?ejNaYkt4N1hsNVROVGhwTmR4TldEQWtXUWM0dXBKeThjZ2F1YVpwNHUvYXRL?= =?utf-8?B?SytlN0lSbE9iSWNCOXRpd2xFZVNjN0RVNElvMUczaWJsUXJ0OGZON0lTNTl5?= =?utf-8?B?UEhlK3R5U043ZFJsZWRET3ZnQWNqYmh2c1cvMlkzUjJEeGh1N1A1MkJGZXpS?= =?utf-8?B?QkE4ZjBYSlArMWR5NXg1UkU3OVBYTXJ1TW4zYXcwcVRzZnE2dkJraHpLZVVJ?= =?utf-8?B?citrN1NyeXBvTEpKOTFhRmVxWUtlZ0l1UThMUXlyT1oyTFlGbml5eVdGM3ZC?= =?utf-8?B?Y25KeU5CSjRqSGVsZC9JMHVkQm5OT0VkWmI0SlB1cUpsN1RXL0NBbnpsKzg2?= =?utf-8?B?UVZPRDZpQTM2WjVMVWRDQyt6eGN6QWNyS2pCRkJWQlN6VnJwaHFBYm1UVGRp?= =?utf-8?B?clZRNk5GMWVyTk4vZ0FsSjg4OS9sdlZzRmJUZVZOeldLemllVVc3aHBtS0RL?= =?utf-8?B?VWxxbkNxNTlJYXp2Qlp2MnBleXVnaU5kNzdnNTJIM2g1U04xeXMwTFhSMWgr?= =?utf-8?B?Tkl3L2VnSFJpa0pGRDl0M1FyMTA0eFRucVRQVitYaDJBWTh4VmM5SWc1RCt0?= =?utf-8?B?Z3E2aVdRb0RzYWhTazFKaitGc0RsbWdqc1FESTE0akp0U0tOR09rK1F2ZEI4?= =?utf-8?B?QWJOaGtYQXh1ak5BN2J3N1VvQ3l3TnAwT0ZtR2dxUkp6SXp5VzBXNmV5dVVV?= =?utf-8?B?Rmk5Sk1MTElpbnl1czVZN0ZkMWl3NURJa1BZaFhkcVdheXlSbkdoRmUxQ0R6?= =?utf-8?B?amdKcWRpREhpeE5TTUxrZDJxWXYxbmFjek5LMW5RZU94TG1mU3BKQT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e6736cf-266d-495c-0acf-08df2e8e0cc4 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 09:39:34.5609 (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: c7zRqvl9c3vkyEJwHwkqDs6kPLXTl+AOjIBk3JXJFqpWJ2Ea+AFbZrz/ME5wz/S4hJfoC2xt41Kj23EUMro4dw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BESPR03MB911377 X-purgate-ID: tlsNG-d62444/1792489177-BD146757-655DB5F7/0/0 X-purgate-type: clean X-purgate-size: 20770 Hi Bertrand, all, An update on the PCIe register retention question and the testing of this patch on R-Car Gen4. On 28/09/2026 12:33, Bertrand Marquis wrote: > Hi Mykola, > >> On 28 Sep 2026, at 10:01, Mykola Kvach wrote: >> >> Hi all, >> >> I have one more thing to check here regarding the R-Car Gen4 PCIe >> BDF-to-OSID mappings across system suspend/resume. >> >> The mappings are programmed in the PCIe APP CNVID/CNVIDMSK registers, >> while CNVOSIDCTRL provides the default OSID. If this state is lost >> during SYSTEM_SUSPEND, PCI DMA could potentially use the default OSID >> after resume instead of the OSID assigned to the device. >> >> I also found a recent Linux rcar-gen4 PCIe PM patch which notes that >> S4 and V4H use an always-on PCIe power domain, while on V4M the PCIe >> controller loses state during suspend. However, I have not found an >> explicit guarantee that these particular APP registers are retained >> on S4. >> >> The Linux BSP is not a direct reference for this case, as its current >> R-Car S4 IPMMU setup does not use the per-BDF OSID mappings programmed >> through these registers. >> >> This series has not previously been tested on R-Car S4 Spider. I have >> tested the suspend/resume path on several other platforms (R-Car H3ULCB, >> R-Car Gen5 and Orange Pi 5), but not this particular PCIe state. >> >> I will also try to check this on a real R-Car S4 board by comparing >> the PCIe APP register state before and after SYSTEM_SUSPEND. >> >> So please consider this patch as needing some further investigation >> from my side for now. > > Thanks for the information. > > I will skip this patch for now (and anyway i will need some help on it as IPMMU and > in general Renesas drivers are not really something i know). > Based on the discussion with Renesas, the PCIe BDF-to-OSID registers need to be saved and restored for S2R on S4. This includes CNVID, CNVIDMSK and CNVOSIDCTRL. Saving the IPMMU context and micro-TLB registers alone does not cover this state. I have been trying to get a working native Linux S2R setup first, before testing this under Xen. For V4H, I have not found any evidence of working S2R support, even with native Linux, or a known working firmware setup. My successful tests on White Hawk only covered s2idle and the PM test stages. These do not confirm S2R support. On S4 Spider, the reference setup requires S2R-enabled ICUMX firmware and separate SCP applications for G4MH and CR52. The build instructions depend on additional SDK components and licensed compilers. Rebuilding Linux and TF-A alone is therefore not enough to reproduce this setup. With the original firmware setup, I traced TF-A 2.5 stopping while waiting for an SCMI response. With SET_SCMI_PARAM=0, this happened during suspend. With SET_SCMI_PARAM=1, it happened during SCMI initialization, before U-Boot. I also tested TF-A 2.11, but the board still hung during S2R. I do not have traces confirming the same failure point in 2.11. Renesas kindly provided test firmware binaries. The G4MH and CR52 SCP applications now start, but the loader takes the warm boot path even after a power cycle, and the board does not reach U-Boot. Renesas mentioned similar behavior on some Spider boards and suggested trying another board. I am checking with colleagues to arrange that, which may take a few days. I will continue investigating this, but it has already delayed the next revision for several weeks. I would like to avoid holding up the whole series while we work on the board and firmware setup. For the next revision, I propose keeping the IPMMU suspend/resume patch, clearly stating that it has only been tested on H3ULCB (R-Car Gen3), and leaving R-Car Gen4 host S2R support out for now. I also propose adding a check in the host-suspend policy to reject host-wide suspend on R-Car Gen4, rather than relying only on a note in the commit message. This restriction would apply only to host-wide suspend, not normal IPMMU use or guest-only suspend. The PCIe OSID save/restore changes and support for the other R-Car generations can then follow separately once they have been validated. Would this approach be acceptable? Thanks, Mykola > Cheers > Bertrand > >> >> Thanks, >> Mykola >> >> On Thu, Aug 27, 2026 at 6:45 PM Mykola Kvach wrote: >>> >>> From: Oleksandr Tyshchenko >>> >>> Store and restore active context and micro-TLB registers. >>> >>> On resume, restore Root IPMMU context state before restoring Cache IPMMU >>> micro-TLB state. Cache IPMMUs select Root contexts through their micro-TLB >>> configuration, so restoring Cache micro-TLBs before the Root context >>> registers are restored can expose stale or uninitialized context state. >>> >>> Tested on R-Car H3 Starter Kit. >>> >>> Signed-off-by: Oleksandr Tyshchenko >>> Signed-off-by: Mykola Kvach >>> Reviewed-by: Luca Fancellu >>> --- >>> Changes in V10: >>> - Iterate over registered IPMMUs in reverse order during resume so Root IPMMU >>> context state is restored before Cache IPMMU micro-TLB state. >>> >>> Changes in V9: >>> - set dt_device_set_protected() only after ipmmu_alloc_ctx_suspend() >>> succeeds, so DT devices do not remain protected on allocation failure. >>> >>> Changes in V7: >>> - moved suspend context allocation before pci stuff >>> --- >>> xen/drivers/passthrough/arm/ipmmu-vmsa.c | 323 +++++++++++++++++++++-- >>> 1 file changed, 308 insertions(+), 15 deletions(-) >>> >>> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c >>> index fa9ab9cb13..2e54fa63d6 100644 >>> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c >>> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c >>> @@ -71,6 +71,8 @@ >>> }) >>> #endif >>> >>> +#define dev_dbg(dev, fmt, ...) \ >>> + dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__) >>> #define dev_info(dev, fmt, ...) \ >>> dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__) >>> #define dev_warn(dev, fmt, ...) \ >>> @@ -130,6 +132,24 @@ struct ipmmu_features { >>> unsigned int imuctr_ttsel_mask; >>> }; >>> >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + >>> +struct ipmmu_reg_ctx { >>> + unsigned int imttlbr0; >>> + unsigned int imttubr0; >>> + unsigned int imttbcr; >>> + unsigned int imctr; >>> +}; >>> + >>> +struct ipmmu_vmsa_backup { >>> + struct device *dev; >>> + unsigned int *utlbs_val; >>> + unsigned int *asids_val; >>> + struct list_head list; >>> +}; >>> + >>> +#endif >>> + >>> /* Root/Cache IPMMU device's information */ >>> struct ipmmu_vmsa_device { >>> struct device *dev; >>> @@ -142,6 +162,9 @@ struct ipmmu_vmsa_device { >>> struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX]; >>> unsigned int utlb_refcount[IPMMU_UTLB_MAX]; >>> const struct ipmmu_features *features; >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX]; >>> +#endif >>> }; >>> >>> /* >>> @@ -547,6 +570,249 @@ static void ipmmu_domain_free_context(struct ipmmu_vmsa_device *mmu, >>> spin_unlock_irqrestore(&mmu->lock, flags); >>> } >>> >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + >>> +static DEFINE_SPINLOCK(ipmmu_devices_backup_lock); >>> +static LIST_HEAD(ipmmu_devices_backup); >>> + >>> +static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX]; >>> + >>> +static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu, >>> + unsigned int utlb) >>> +{ >>> + return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb))); >>> +} >>> + >>> +static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu) >>> +{ >>> + struct ipmmu_vmsa_backup *backup_data; >>> + >>> + dev_dbg(mmu->dev, "Handle micro-TLBs backup\n"); >>> + >>> + spin_lock(&ipmmu_devices_backup_lock); >>> + >>> + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) >>> + { >>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); >>> + unsigned int i; >>> + >>> + if ( to_ipmmu(backup_data->dev) != mmu ) >>> + continue; >>> + >>> + for ( i = 0; i < fwspec->num_ids; i++ ) >>> + { >>> + unsigned int utlb = fwspec->ids[i]; >>> + >>> + backup_data->asids_val[i] = ipmmu_imuasid_read(mmu, utlb); >>> + backup_data->utlbs_val[i] = ipmmu_imuctr_read(mmu, utlb); >>> + } >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_backup_lock); >>> +} >>> + >>> +static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu) >>> +{ >>> + struct ipmmu_vmsa_backup *backup_data; >>> + >>> + dev_dbg(mmu->dev, "Handle micro-TLBs restore\n"); >>> + >>> + spin_lock(&ipmmu_devices_backup_lock); >>> + >>> + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) >>> + { >>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); >>> + unsigned int i; >>> + >>> + if ( to_ipmmu(backup_data->dev) != mmu ) >>> + continue; >>> + >>> + for ( i = 0; i < fwspec->num_ids; i++ ) >>> + { >>> + unsigned int utlb = fwspec->ids[i]; >>> + >>> + ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]); >>> + ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i]); >>> + } >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_backup_lock); >>> +} >>> + >>> +static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *domain) >>> +{ >>> + struct ipmmu_vmsa_device *mmu = domain->mmu->root; >>> + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; >>> + >>> + dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->context_id); >>> + >>> + regs->imttlbr0 = ipmmu_ctx_read_root(domain, IMTTLBR0); >>> + regs->imttubr0 = ipmmu_ctx_read_root(domain, IMTTUBR0); >>> + regs->imttbcr = ipmmu_ctx_read_root(domain, IMTTBCR); >>> + regs->imctr = ipmmu_ctx_read_root(domain, IMCTR); >>> +} >>> + >>> +static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *domain) >>> +{ >>> + struct ipmmu_vmsa_device *mmu = domain->mmu->root; >>> + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; >>> + >>> + dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->context_id); >>> + >>> + ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0); >>> + ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0); >>> + ipmmu_ctx_write_root(domain, IMTTBCR, regs->imttbcr); >>> + ipmmu_ctx_write_all(domain, IMCTR, regs->imctr | IMCTR_FLUSH); >>> +} >>> + >>> +/* >>> + * Xen: Unlike Linux implementation, Xen uses a single driver instance >>> + * for handling all IPMMUs. There is no framework for ipmmu_suspend/resume >>> + * callbacks to be invoked for each IPMMU device. So, we need to iterate >>> + * through all registered IPMMUs performing required actions. >>> + * >>> + * Also take care of restoring special settings, such as translation >>> + * table format, etc. >>> + */ >>> +static int __must_check ipmmu_suspend(void) >>> +{ >>> + struct ipmmu_vmsa_device *mmu; >>> + >>> + if ( !iommu_enabled ) >>> + return 0; >>> + >>> + printk(XENLOG_DEBUG "ipmmu: Suspending...\n"); >>> + >>> + spin_lock(&ipmmu_devices_lock); >>> + >>> + list_for_each_entry( mmu, &ipmmu_devices, list ) >>> + { >>> + if ( ipmmu_is_root(mmu) ) >>> + { >>> + unsigned int i; >>> + >>> + for ( i = 0; i < mmu->num_ctx; i++ ) >>> + { >>> + if ( !mmu->domains[i] ) >>> + continue; >>> + ipmmu_domain_backup_context(mmu->domains[i]); >>> + } >>> + } >>> + else >>> + ipmmu_utlbs_backup(mmu); >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_lock); >>> + >>> + return 0; >>> +} >>> + >>> +static void ipmmu_resume(void) >>> +{ >>> + struct ipmmu_vmsa_device *mmu; >>> + >>> + if ( !iommu_enabled ) >>> + return; >>> + >>> + printk(XENLOG_DEBUG "ipmmu: Resuming...\n"); >>> + >>> + spin_lock(&ipmmu_devices_lock); >>> + >>> + /* >>> + * IPMMUs are registered with list_add(), with Root IPMMU probed first. >>> + * Walk backwards to restore Root contexts before Cache micro-TLBs. >>> + */ >>> + list_for_each_entry_reverse( mmu, &ipmmu_devices, list ) >>> + { >>> + uint32_t reg; >>> + >>> + /* Do not use security group function */ >>> + reg = IMSCTLR + mmu->features->control_offset_base; >>> + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECGRP); >>> + >>> + if ( ipmmu_is_root(mmu) ) >>> + { >>> + unsigned int i; >>> + >>> + /* Use stage 2 translation table format */ >>> + reg = IMSAUXCTLR + mmu->features->control_offset_base; >>> + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_S2PTE); >>> + >>> + for ( i = 0; i < mmu->num_ctx; i++ ) >>> + { >>> + if ( !mmu->domains[i] ) >>> + continue; >>> + ipmmu_domain_restore_context(mmu->domains[i]); >>> + } >>> + } >>> + else >>> + ipmmu_utlbs_restore(mmu); >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_lock); >>> +} >>> + >>> +static int ipmmu_alloc_ctx_suspend(struct device *dev) >>> +{ >>> + struct ipmmu_vmsa_backup *backup_data; >>> + unsigned int *utlbs_val, *asids_val; >>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); >>> + >>> + utlbs_val = xzalloc_array(unsigned int, fwspec->num_ids); >>> + if ( !utlbs_val ) >>> + return -ENOMEM; >>> + >>> + asids_val = xzalloc_array(unsigned int, fwspec->num_ids); >>> + if ( !asids_val ) >>> + { >>> + xfree(utlbs_val); >>> + return -ENOMEM; >>> + } >>> + >>> + backup_data = xzalloc(struct ipmmu_vmsa_backup); >>> + if ( !backup_data ) >>> + { >>> + xfree(utlbs_val); >>> + xfree(asids_val); >>> + return -ENOMEM; >>> + } >>> + >>> + backup_data->dev = dev; >>> + backup_data->utlbs_val = utlbs_val; >>> + backup_data->asids_val = asids_val; >>> + >>> + spin_lock(&ipmmu_devices_backup_lock); >>> + list_add(&backup_data->list, &ipmmu_devices_backup); >>> + spin_unlock(&ipmmu_devices_backup_lock); >>> + >>> + return 0; >>> +} >>> + >>> +#ifdef CONFIG_HAS_PCI >>> +static void ipmmu_free_ctx_suspend(struct device *dev) >>> +{ >>> + struct ipmmu_vmsa_backup *backup_data, *tmp; >>> + >>> + spin_lock(&ipmmu_devices_backup_lock); >>> + >>> + list_for_each_entry_safe( backup_data, tmp, &ipmmu_devices_backup, list ) >>> + { >>> + if ( backup_data->dev == dev ) >>> + { >>> + list_del(&backup_data->list); >>> + xfree(backup_data->utlbs_val); >>> + xfree(backup_data->asids_val); >>> + xfree(backup_data); >>> + break; >>> + } >>> + } >>> + >>> + spin_unlock(&ipmmu_devices_backup_lock); >>> +} >>> +#endif /* CONFIG_HAS_PCI */ >>> + >>> +#endif /* CONFIG_SYSTEM_SUSPEND */ >>> + >>> static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) >>> { >>> uint64_t ttbr; >>> @@ -559,6 +825,9 @@ static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) >>> return ret; >>> >>> domain->context_id = ret; >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + domain->mmu->root->reg_backup[ret] = &root_pgtable[ret]; >>> +#endif >>> >>> /* >>> * TTBR0 >>> @@ -615,6 +884,9 @@ static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain) >>> ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH); >>> ipmmu_tlb_sync(domain); >>> >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + domain->mmu->root->reg_backup[domain->context_id] = NULL; >>> +#endif >>> ipmmu_domain_free_context(domain->mmu->root, domain->context_id); >>> } >>> >>> @@ -1338,10 +1610,11 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) >>> struct iommu_fwspec *fwspec; >>> >>> #ifdef CONFIG_HAS_PCI >>> + int ret; >>> + >>> if ( dev_is_pci(dev) ) >>> { >>> struct pci_dev *pdev = dev_to_pci(dev); >>> - int ret; >>> >>> if ( devfn != pdev->devfn ) >>> return 0; >>> @@ -1358,17 +1631,24 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) >>> if ( !to_ipmmu(dev) ) >>> return -ENODEV; >>> >>> - if ( !dev_is_pci(dev) ) >>> + if ( !dev_is_pci(dev) && dt_device_is_protected(dev_to_dt(dev)) ) >>> { >>> - if ( dt_device_is_protected(dev_to_dt(dev)) ) >>> - { >>> - dev_err(dev, "Already added to IPMMU\n"); >>> - return -EEXIST; >>> - } >>> + dev_err(dev, "Already added to IPMMU\n"); >>> + return -EEXIST; >>> + } >>> >>> - /* Let Xen know that the master device is protected by an IOMMU. */ >>> - dt_device_set_protected(dev_to_dt(dev)); >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + if ( ipmmu_alloc_ctx_suspend(dev) ) >>> + { >>> + dev_err(dev, "Failed to allocate context for suspend\n"); >>> + return -ENOMEM; >>> } >>> +#endif >>> + >>> + /* Let Xen know that the master device is protected by an IOMMU. */ >>> + if ( !dev_is_pci(dev) ) >>> + dt_device_set_protected(dev_to_dt(dev)); >>> + >>> #ifdef CONFIG_HAS_PCI >>> if ( dev_is_pci(dev) ) >>> { >>> @@ -1377,26 +1657,28 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) >>> struct pci_host_bridge *bridge; >>> struct iommu_fwspec *fwspec_bridge; >>> unsigned int utlb_osid0 = 0; >>> - int ret; >>> >>> bridge = pci_find_host_bridge(pdev->seg, pdev->bus); >>> if ( !bridge ) >>> { >>> dev_err(dev, "Failed to find host bridge\n"); >>> - return -ENODEV; >>> + ret = -ENODEV; >>> + goto free_suspend_ctx; >>> } >>> >>> fwspec_bridge = dev_iommu_fwspec_get(dt_to_dev(bridge->dt_node)); >>> if ( fwspec_bridge->num_ids < 1 ) >>> { >>> dev_err(dev, "Failed to find host bridge uTLB\n"); >>> - return -ENXIO; >>> + ret = -ENXIO; >>> + goto free_suspend_ctx; >>> } >>> >>> if ( fwspec->num_ids < 1 ) >>> { >>> dev_err(dev, "Failed to find uTLB"); >>> - return -ENXIO; >>> + ret = -ENXIO; >>> + goto free_suspend_ctx; >>> } >>> >>> rcar4_pcie_osid_regs_init(bridge); >>> @@ -1405,7 +1687,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) >>> if ( ret < 0 ) >>> { >>> dev_err(dev, "No unused OSID regs\n"); >>> - return ret; >>> + goto free_suspend_ctx; >>> } >>> reg_id = ret; >>> >>> @@ -1420,7 +1702,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) >>> { >>> rcar4_pcie_osid_bdf_clear(bridge, reg_id); >>> rcar4_pcie_osid_reg_free(bridge, reg_id); >>> - return ret; >>> + goto free_suspend_ctx; >>> } >>> } >>> #endif >>> @@ -1429,6 +1711,13 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) >>> dev_name(fwspec->iommu_dev), fwspec->num_ids); >>> >>> return 0; >>> +#ifdef CONFIG_HAS_PCI >>> + free_suspend_ctx: >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + ipmmu_free_ctx_suspend(dev); >>> +#endif >>> + return ret; >>> +#endif >>> } >>> >>> static int ipmmu_iommu_domain_init(struct domain *d) >>> @@ -1490,6 +1779,10 @@ static const struct iommu_ops ipmmu_iommu_ops = >>> .unmap_page = arm_iommu_unmap_page, >>> .dt_xlate = ipmmu_dt_xlate, >>> .add_device = ipmmu_add_device, >>> +#ifdef CONFIG_SYSTEM_SUSPEND >>> + .suspend = ipmmu_suspend, >>> + .resume = ipmmu_resume, >>> +#endif >>> }; >>> >>> static __init int ipmmu_init(struct dt_device_node *node, const void *data) >>> -- >>> 2.43.0 >>> >>> > From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455216.1668792 (Exim 4.92) (envelope-from ) id 1xJ6Js-0001HA-36; Tue, 20 Oct 2026 09:39:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455216.1668792; Tue, 20 Oct 2026 09:39: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 1xJ6Jr-0001Gw-UY; Tue, 20 Oct 2026 09:39:43 +0000 Received: by outflank-mailman (input) for mailman id 1455216; Tue, 20 Oct 2026 09:39:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6Jr-0001Fp-As for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jq-00225F-Ns for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:42 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736de-2eae-0a2a0a5409dd-0a2a4503a702-0 for ; Tue, 20 Oct 2026 11:39:42 +0200 Received: from [52.101.66.96] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736de-fae8-0a2a45030019-346542601808-3 for ; Tue, 20 Oct 2026 11:39:42 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by DU0PR03MB8671.eurprd03.prod.outlook.com (2603:10a6:10:3eb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:40 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 09:39: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=CmGz+Agh10uRR4CpcLv9nwevAxuqH0SL/JO2TOVFDRNvyjXgszCdLq6+WvcvbYwRhUmz1a54WJBB92rFaLyQKav3ctNpOaTb/SFy3VocWaZ0eXZbRj/zPGDjiy59jA3/FHW6W+K5ZZkRmoYqpVVH0ffZf7xwBhQkVc5kZ0vH0ex1P045dywR3EJasuFYcEgMcKH4V3bcyjCiyRRtE8KAZb1q7QTyAAj0a5wca+PLkIZUxqaNH8i5ORfkUWauR1SdVztV4YNZ8TdMasA3S6clCAQMNuZsMm/J5XO0Z/b4JIlgtHZlBIOhXls5UWKi83QcOmtQmzyJHLj0ywLhe8wZlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WkFW2/HddsDstyO/MREni/S0PHm4etAIWuTqD5hYt5E=; b=IX2HxTAx3IWHD870xzH79u36Nh/f5TTOZyyUcZJVqVKTsSovTnGuAJHBk8zPjwiTQ9F2n/k28MlPdBN659z7WKPTrSjqMp1JLaevrPNKFYm4+aDAXDvQloGML7n0wLZw/iTvrSKqh6BnTwhjCccqBDJFhEOHKjcnzhWFQcAXp8gahCpGXsKNLyH8IJVxc7K9e1uT7kI0kMbtZPK29f+8j+lyq7r1drzd6uKRS8vZLRd3UXw+2tQfDXW/Jc1bwqe9NUomGYxIzTvK+Y/swuIHZh/iGdeIaVU6/U4Do9y20muy2zHz/7T9lk5eOd3K+IXxvLIciKEA5mGLhE6G2Ly/vg== 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=WkFW2/HddsDstyO/MREni/S0PHm4etAIWuTqD5hYt5E=; b=mZ7wX9IowJGh7RxLkT+1oW1vLpsaeH9TmIEVwjK+LWpDb6AKVnqCFQi1wqBhdIzZbvDKufG3/8fUDsklauv+ij9ByX1sBf8uqVhR8ijD2Zpj7lGTypfZFKzfRNX/cbir1dr8dCy1P9dDScoLvR6lwdOke1ieR3Hu9r02X1W1IgYfBFIMGSuRYU+z3ww9xpKBw4KVYiGuGeF2CmRoLK75y1JMfIRjKlYUKQ09tb9asDUUNBC+boCAMLjFMktlVk3ZJWODUe2gzJ7k7FjpvokbS1W9g+7IWTZWhnM+yw5sa76wuBrI/3XxtiAZ4z50HagAOiKZ1bIFnBEzdljRmkVwiw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v10 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Topic: [PATCH v10 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Index: AQHdYHbolVxSCaRf0E6Y0uINqp/GGw== Date: Tue, 20 Oct 2026 09:39:30 +0000 Message-ID: <3a880578d558388ab6d033ccc1f89aa4efecdc81.1792480416.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|DU0PR03MB8671:EE_ x-ms-office365-filtering-correlation-id: 779ebdd2-1b68-4d6f-d10d-08df2e8e0bb7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|18002099003|10067099003|22082099003|11063799006|38070700021|261009223027099003|56012099006; x-microsoft-antispam-message-info: djjNPdOwqfWnPuQTjkwTiTA8fosmJw/NUY7u+EdpYJLdMZBVHlXPvSWBugTfHsCgtnHGNbIgZV34VVFd9xLKm7RThEOhLWzB7JLGjdMtvc8PGpjQb4ARKUFEkvZonE7+XjfLcPxykseryO8QC+jt0I3alAJkxy+91lbaz0nATnpHWQk1i9o3Kb9ZnnBywEYStq+Z1JXtY6l1nCMY3/IxO6Zp01tXEDnxOPkjU98s1Pn1Epe6lomCGYd7j8+Zh8K1yTkkCf3FNjvqL52IognT2QQGRE0Yq3yw/ruifvmPVvrQJKa0c50KXoedt7UTCTkRyegZRaxo2eXx9JYVWfu6DrcOp5kpSLuarzUewz2zP28J9vOe0+7w4X+wXfgr1UJUh1xLGSK0FlTIR9In2qKqFWJfP+tfAHGtkG/KmOCikVClJnujwwP/aI0XoarUec4vhtyzVYwai8ChDZA/xRs8QfbF+qfPVtrZCrkbqAvOx7vQnMKzLu9eKCxwPjUFXjBCMRJINCdkqfrWVTUqqi63bjbc5v2JbMSOqJ6p3RbuKahHWlKNCgS9DKLjwfOqK/0z91OXusAeR3yZg+lkhitUxDeAYFNSGlUYornTYbqKNqMyKL6SVxuPklU3ZO2bVKn7STDwrHLjFdld2JLb1R9Y+GW97QQtN2l5W5zC4vCLQHZjHmfTKWGuJMinUkGX4n1c0rFeA92diX0mFgLTq/Z5wYCn1vbGucbxDwif6yQOFVA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(18002099003)(10067099003)(22082099003)(11063799006)(38070700021)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?lH/VJdqN7JKwon0xNFj0kOoP5AeBQdSsqWze+bEesj47QDYfPMtLwPUys1?= =?iso-8859-1?Q?aRANrzd9TLP5SQVuLlXt1azFvOOn34AcebfW/jsJKcWTY6SFVBNT5FwPn3?= =?iso-8859-1?Q?8itjABvSVTIzKjO/Ys74Zlt2hn7CUD/SweD9oqUgnaEfcf8Idin3cXr8WC?= =?iso-8859-1?Q?J/OAK8MNcBvRVigV8HVMQjxFj7iiNeHy88TxigPAkI12mYoVBDwTvLIEW8?= =?iso-8859-1?Q?H5VNln+aaAMNwJ6G9JC2VgBN87dxrQcHwIyQx/Ouqg+ooAbjB7c2m4ZNpd?= =?iso-8859-1?Q?5DFdfqp4nOrcY9vfCIaGd90SHO3TEEsKA9G62ZqeN/HiJYWh+6I9BNR7db?= =?iso-8859-1?Q?wGmZLe/12PTGOzubZjHtnqnLKh5+LmezYDB2cBOy/Vcjjn7AFzQTd5ncIe?= =?iso-8859-1?Q?hXY1Zhgs67tFJ4E2jX40umO3ycXRgOtpO15th7IL1pZTPqv47c36TsK4gJ?= =?iso-8859-1?Q?ER8UivO1P+tUUiJlKthU4twm8nrxMditgjmAD2e4uXv8ayolBiBufyT8ep?= =?iso-8859-1?Q?EUgrgzTgkcFDObPwXp4GEpUrV6Njp/TsLl2JZiNL4s1TlFCF3MniHd7wSd?= =?iso-8859-1?Q?Rh6QIoofI0lJKo7b/TZoxUQwxcOKg9/jgJ4lQc9lZK/s1ywCY3joPBr0Uz?= =?iso-8859-1?Q?qIepWjhvFbXHP+sngVaGWBV+FsI7DOnMK/pFulADnBHhf8cXhPW+kKI8Dh?= =?iso-8859-1?Q?/4tPBUDeqvOaM3O3juLdbU4S07eAT3nw73Uvo96pkF+LSIlQ96EE/btJ7t?= =?iso-8859-1?Q?YeW89wpsQr/3Ij775sUd0hPB2SItxoMIihTpqaN+INjZ/Rqsslv2GIyW+5?= =?iso-8859-1?Q?d9CQ/9/Rd+ui0E6X7rxZKoB7CLgDUv7VfWSxiVu+x+ZH6CjyoQKNQl5MlU?= =?iso-8859-1?Q?hdqpLZHaxnpsdN5caqyGq++/DdqJsO18yjUhCH/kn1T/h5TnrpL/KqqWmj?= =?iso-8859-1?Q?AubHhgSHVaPhuwfIKkEtU06USJ3OiGwUjRTcTBhEQIz9HPdHV0SHPGMxZn?= =?iso-8859-1?Q?42PNA83F9zjD5kXkszE84QWlvtgwyW82Y/vOcb6UgTR8wAElHegTYM7VLj?= =?iso-8859-1?Q?sKS51amFDuK+PD9WVc65c8yZp+/7/mPR5VgpZsbicas3Up1kdkJxvwuI5B?= =?iso-8859-1?Q?rA5yO4wyuKXmH+I/5CVza7KsQNbpvGtidN3vfZjkX3X5R23XhJQGLrn/3P?= =?iso-8859-1?Q?1U8R7SftJiA4uNyoDBqWz5bM62TtlwBJW4KfSqgOCy0VXipi2eClaOUP3f?= =?iso-8859-1?Q?6V4bTZaCLLXpxKYoEoYZAtCY4vSpTGU2XxKj1ilE8nyVnQCa+mVKnr7v2I?= =?iso-8859-1?Q?7SDSPNMmGPOYzkiyKkMyjQy+2E6E6NUs8Tw6TFXVHw+jd2aAeMjh12hq0E?= =?iso-8859-1?Q?7zV2DqrfXfZmGQhOke7Sxj0BxH2PdkcwkubKPNcAAuP+3niCmuuhpQMD7r?= =?iso-8859-1?Q?jT6dNkZRQW+m1HN6Rv8mJVW+5+Odq5xdVXO9BUkMrsw2ueTT2WKShe15OR?= =?iso-8859-1?Q?zQCRquOBf9rS7Q4F/zRW+C6SpNXyQq3wKonTElouEbq0cvaeGdLKmVIfAs?= =?iso-8859-1?Q?cG58vKwTxg7ZH14Jr1Cf9VZTfp5dIcAkWB9TKqZjWwpiDER+RPNLjLoDAl?= =?iso-8859-1?Q?JTQhGM8sm8XNyBCJ8mAjwEcCcX4vMjZAdTQqZ6kii4Fh12c+adZX+lJCNH?= =?iso-8859-1?Q?kxiymHiPY6zkCUlUQzQEhpeZCC+Wt12dQDdB+eL7kdCDhR+hLOW91qNM+A?= =?iso-8859-1?Q?ye1ELlWLNGLvAtpl6Upe5bfWzDjtEq0c1UHUUvh4svHUV5vdnW9l/EZT0a?= =?iso-8859-1?Q?iAiY+arCZg=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 779ebdd2-1b68-4d6f-d10d-08df2e8e0bb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 09:39:30.8548 (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: 6fuf6yNDXz83HUqX9Y7B/05MBEkOdi9ucP9b49npt6sJzOJ2fl1RE49/HAtpdvbMtVW7Yf2EBFM0BJYE4CRf8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8671 X-purgate-ID: tlsNG-33051d/1792489182-7488A4E9-E1D0BADF/0/0 X-purgate-type: clean X-purgate-size: 3865 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 --- v9->v10: * make cpu_next static to balance_irq * move the offline path to the CPU_DEAD notifier * make rebalance_irqs static 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/irq.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 594aaedd22..d5145a4723 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -166,6 +166,58 @@ static int init_local_irq_data(unsigned int cpu) return 0; } =20 +static void balance_irq(int irq, unsigned int from, bool up) +{ + static int cpu_next; + 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 drivers = to + * select one CPU from that mask. If the dying CPU was included in the= IRQ's + * affinity mask, we cannot determine exactly which CPU the interrupt = is + * currently routed to, as GIC drivers lack a concrete get_affinity AP= I. So + * to be safe we must reroute it to a new, definitely online, CPU. In = the + * case of CPU going down, we move only the interrupt that could resid= e on + * it. Otherwise, we rearrange all interrupts in a round-robin fashion= . + */ + 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); +} + +static 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_espi= s(); + irq++ ) + balance_irq(irq, from, up); +#endif +} + static int cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) { @@ -180,6 +232,15 @@ static int cpu_callback(struct notifier_block *nfb, un= signed 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; + case CPU_DEAD: + if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) + rebalance_irqs(cpu, false); + break; } =20 return notifier_from_errno(rc); --=20 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455217.1668796 (Exim 4.92) (envelope-from ) id 1xJ6Js-0001Jz-DV; Tue, 20 Oct 2026 09:39:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455217.1668796; Tue, 20 Oct 2026 09:39: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 1xJ6Js-0001Jk-7O; Tue, 20 Oct 2026 09:39:44 +0000 Received: by outflank-mailman (input) for mailman id 1455217; Tue, 20 Oct 2026 09:39:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJ6Jr-0001GC-Hp for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jq-00225F-Uc for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:42 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736de-2eae-0a2a0a5409dd-0a2a4503a702-2 for ; Tue, 20 Oct 2026 11:39:42 +0200 Received: from [52.101.66.96] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736de-fae8-0a2a45030019-346542601808-4 for ; Tue, 20 Oct 2026 11:39:42 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by DU0PR03MB8671.eurprd03.prod.outlook.com (2603:10a6:10:3eb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:40 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 09:39: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=NbuZuMgZdEBkPTiPOwO8fx5oORluFe2xAwGLSnlsxqatgTEvRYA0LFS/28TfbAk8jCvv4Gb95z3B8cejqBjllJMtQJJNxs1Gidvl24yLJ3snioQFpRpujLAxd1SCjiDSp4rUW+3sOSnQkphwcO4mCsFaEJs+4KF7xu5C89xFRudn1MY+MqKUwHwKgFEllNwEulk7rr1VL0Lb7db9SqG2VezfpGpXBjCvDMJRBIb46JPc5I9s9K75SRKJrjNx3SpqyVwmwXP/R4gSVhnkoluh38x81tudkr/4x7y7kJBrgcMoDQrsyYLtXeBQtQPlf1jzCiSOb/9Nuw69bAodQa8Fjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XSH/shLHqfzfi6a2PE83Muqm7Z4QFle5WSXa99NiJOg=; b=jNEAcOMC0WLo031x5/GLOqDZUYr0EDAvOzeO/NV2I/Nr3oBxzYvR7U4L4GwBrDcUD3DS96Y//uT2sWWAoEgvQoIamMfQXqHVHFhSpYB3Lwq7AxX8+AsdduB8yc1R3mEaOZ1UGd6++Tlr1pUx0WY+FtSBZS/XaSByq2MVmugqW4axEmtD0wJMNYTT9/mMJhmHAOE4Qo5lBcRkclznSLu+FhFJ009KUf/L6N4KV+Am6sBYbykBKGAiKUs2dyBVxcDwe7AsKSdISm153307nYbwAbTKvliCD0IzOVEh+qM1HOIlpOVZHzHGgNjR3HPCGqtjTYi06HL81VvU+HkerCOtUg== 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=XSH/shLHqfzfi6a2PE83Muqm7Z4QFle5WSXa99NiJOg=; b=UbqcFC858lLj713eP8AmfRzkgX8WYPAlwh9x4gRaTx2tWDiTJ8hGB64k3SytnCC4QLYjeT3oOqTBdkAbT4v1V/GAtBaaYZgKI7Tkz1mwpVUaqYSEAW+1FvlB/gft5n9W+b4Aljp08s9MpR4tJ8tuHX0sptBVwAcSawcJDtPIuAjWz1+Nsxv/m7bUpoVEsQOH0gwWip4qVn8ZDP9a+aFj3bA7hzxjQNo60DaywtR1u0EmcVlqVX9QaSDwVfbMHPA7WmS2uPRlVksTGEAdeQPzvknbx8+C9KStiAvqFbY1cFt46cRMJWudXLgYLcXaN2c6d6u3Dm17D/Xj/UesECTWdQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Jan Beulich , Andrew Cooper , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v10 3/6] Kconfig: Make cpu hotplug configurable Thread-Topic: [PATCH v10 3/6] Kconfig: Make cpu hotplug configurable Thread-Index: AQHdYHbowdij+hqO0Eqr0KOoURLsZA== Date: Tue, 20 Oct 2026 09:39:31 +0000 Message-ID: <819a5c697e06e45115a330fc2907fbfd4d166ea1.1792480416.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|DU0PR03MB8671:EE_ x-ms-office365-filtering-correlation-id: 6136018a-55cc-4078-3774-08df2e8e107d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10063799003|18002099003|10067099003|22082099003|11063799006|38070700021|261009223027099003|56012099006; x-microsoft-antispam-message-info: Yt9kSoAFaOVmOzdiKFIBHM5jJrIq8+cfn2LLq+jjFiFCcW023qCtfuvhlok5phzIbAv+83vWgG00B8SGNrtYpUhUdLiTLAwQ1iQT+ORSbGug+LsIaTwBhOnSK/yUamzjiYMTsALp1nGCfcpUmN9WrTtwiY3PyGXSWFeCeaPbi6pAyd+hkO7VUjrl4pQWT2adHqLGhZBEwJkmD/kuqkjVed0nVNyTw4uHwx63r+5aiRWqho7c2+0y3vfxtwrxIFd/97na2L2eIJJ2BTjKYunVxxYIgwZfx6qQT6DKUHyYtkVJzMMgwNEbcipnaz8vsQI9vvl1qUF8WfAvStF0CVnosoJYkS6s6LJycij9S5IxHnAGw3iUtlRq/RMSpHgIHgbGpHe8eFdWH7T88k30gPHXRSAObFLj51DI/E+yHvhya3eCzPnG2BjAjpCmGDxr+0bRgCcrv6Xc/BEjeI6F9R+gjNrMrXILnyt/urbOUDFBGe5c60AEz3pSiWnQ1/lrbYbg82U4eqznCRDu13KmkXA1g3eMiE1qpwow2RtOrKU1omrI+4ORBy6Xuh3SB+iYBhF3tURNrwe+4wzm6vlLpxf/MML8TLBXAgDYuI5xPjvp37WwqHfuS9IkJ0ZJHo0zioU9h4PC1BBc/Nk7lfcFN2DP3o4teXPIoLc9IO5Ju1IY9tsi85BlAQ3V4mXDA7hne8mX9KF0Ra09jCYe3J7iVwIx9FNcuTgD8QdAcnFmUc/SBpU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10063799003)(18002099003)(10067099003)(22082099003)(11063799006)(38070700021)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TBHzOGCSrh1MXo4Fg697ioI22eL8aEcMPHvsIexDnRdeJtTaQPJKyoIROy?= =?iso-8859-1?Q?6BG7fHAn7eRtwKTzqvY3q8tkfjaW+rPdSbCAHrG6JPqvLhC/FGsvy6Z5sO?= =?iso-8859-1?Q?Da0fHxhhg8Tu1am+0ZH4A1yjamAaCy5RXQ0gVGr1i8CODH9ZEPONfWqfBA?= =?iso-8859-1?Q?sWQlZCEsyocuv9ly3QZpv69p4JhD15wIBreKoOM8TL9XThI/0GJuOsYyca?= =?iso-8859-1?Q?aUT9Db7fjoWBfpYxhFgh/1f0Z6UdZ6Ioy3qx9eUdr5NzejtpQOjUQ7d7US?= =?iso-8859-1?Q?jJIzfJ8FLBqY4CiIpZONM2KSCh/a90HRwmrzbhTLsPlLPaHIZK9DBnoWF5?= =?iso-8859-1?Q?814scnuLvG5RJhgb7wZ+XkEDXMpzBrzFYLFFWtbS6n+EISHqeD1LSKT0Wq?= =?iso-8859-1?Q?2hzxsIDal5QPe/uL8L36dF3/h19Yqg7QAISP56Zd2153QJSBEBBxYF9kE5?= =?iso-8859-1?Q?eAd+tcqBtcYjrFFRlwwlMMxSswJKREu3EbyBQpDFACOAnk03p/75htYuVe?= =?iso-8859-1?Q?jjOiANwiA5KZODF+NgMUnQKOYt0A0nAfg3xZWqEDJEhK/KPNKsFxem0ozl?= =?iso-8859-1?Q?WV97r/pCYdPvPtY9C4VjB5GqbYg9T+Z6tSwu01utdOKMG6L1NEtw7t2Xio?= =?iso-8859-1?Q?D6rj31fKai4sSQ1/e88iIKd7Xekz09TV1MODWiPun5t+0CpJ+WEjkspX0Q?= =?iso-8859-1?Q?HeUBnBq9SYAVbehnirogvfEY36b0kdLxjMNaDnAL5oXM7ypFM/OVGr0oIM?= =?iso-8859-1?Q?BkWiP22RSsCc7Drl8Zzufwg+3jbvqodtSTLqqv2/vOJMuSezjCUji0UW9S?= =?iso-8859-1?Q?mF6LMfMa/1/OvzPWOG6IsMTWj3mhkSqKS8VzhEccubJ6tQhEGEMnKCFujU?= =?iso-8859-1?Q?XL5HKlpeAuALzsjPyF0VdTRlF3cRlGxx39qlMfJekmyfmcG8Nt1JMjSH62?= =?iso-8859-1?Q?cc/zgO/g0dTkatPTPP7ODiL2EuOn0WJHf+7OQMZXDKqcdsuRl3DZvn71i3?= =?iso-8859-1?Q?SfeEdZbcXsLYWFWCMAUNDDlwDpVaIlHQeL0qYSPmvJfVNSMY3KaVBngysb?= =?iso-8859-1?Q?xvWEzc4aqqlcjSQDQHIIGeBERhybtaaKhx2RqrjmXJByo5upDot9ZotFeV?= =?iso-8859-1?Q?NLug9qGWx/5YH3hB2snn34Wi/wdeMAHj+Q4E3TGfr9vxtqT0afGit18lqX?= =?iso-8859-1?Q?uwnOPwTxEFlFzjr5+WgCxpWqpzzlhnYJ1qsECH5qV1yPNq2pmA/MfnQmTV?= =?iso-8859-1?Q?VDrGBSjdNDkkpOWtcWOsj6QbFaD95TkDFcgFW8yWDNlIn10Tqkot2R2TsV?= =?iso-8859-1?Q?JXS/g5fOuBAxVuuFwJDNaosYHm+pTy1Gsm0u0T7qhTRE8l9KVjGM37li7x?= =?iso-8859-1?Q?JKJtnczK1nKSd7KT5quD84pcafgJSww8jJtbOXSMjvLgn4LaSJhePEUzVM?= =?iso-8859-1?Q?91OCu0eOrpZeISd6cYP6fRI3EmS0OmsNrhM51j6sHIeynS4Ohf7GbF2ftW?= =?iso-8859-1?Q?z3GCwrPhkjpmVTqqGjPhUl0bQ2a6Lr5SR/AQW7sGswSx7EpovzMBHdhD3r?= =?iso-8859-1?Q?UV6nYkbAf1x9TzvG9hMwdje77jpHpfy1tDOh5zCOgnx4i8td9UnBZRBWvc?= =?iso-8859-1?Q?N6LDly3FZ01XXwK24Skwt5VaSXcAiC2gpTc9voWJA0scu8rgxrbYCEw1q6?= =?iso-8859-1?Q?RRgE6mJnvg00iW9h9X+sLH2Ud9MQ4c+QGORtPX9M7U4sf1Cqq+mPWXrNMJ?= =?iso-8859-1?Q?Z4OT4uSmen0HFnSzkB6V/GW0S43GDBDqYs4ZlxWYvOP7+uP18qlYerRWvR?= =?iso-8859-1?Q?m0N5AmfMnQ=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6136018a-55cc-4078-3774-08df2e8e107d X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 09:39:31.1802 (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: GGnvaSqbWyWfQQ03iMVhig5RWTGc9ybHb5y7CoKKJCWnZElJKlxvggq48E+MMzFtBF7ccdiZjSxNzXBwz7ijDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8671 X-purgate-ID: tlsNG-33051d/1792489182-6C2E04E9-AB417C26/10/78276251493 X-purgate-type: spam X-purgate-size: 3686 For the purposes of certification, we want as little code as possible to be unconditionally compiled in. Make CPU hotplug and SMT operations configurable to ease the process. This will also help with introducing CPU hotplug on Arm, where it needs to be configurable. Signed-off-by: Mykyta Poturai Acked-by: Jan Beulich --- v9->v10: * no changes v8->v9: * add "if EXPERT" * add AB v7->v8: * fix style * s/CPU_HOTPLUG/CPU_ONLINE_OFFLINE/ v6->v7: * new patch --- xen/arch/x86/platform_hypercall.c | 12 ++++++++++++ xen/arch/x86/smp.c | 3 +++ xen/arch/x86/sysctl.c | 12 ++++++++++++ xen/common/Kconfig | 8 ++++++++ 4 files changed, 35 insertions(+) diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hype= rcall.c index 6dee4922f3..361a4cd37a 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -735,6 +735,12 @@ ret_t do_platform_op( { int cpu =3D op->u.cpu_ol.cpuid; =20 + if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) + { + ret =3D -EOPNOTSUPP; + break; + } + if ( cpu >=3D nr_cpu_ids || !cpu_present(cpu) || clocksource_is_tsc() ) { @@ -757,6 +763,12 @@ ret_t do_platform_op( { int cpu =3D op->u.cpu_ol.cpuid; =20 + if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) + { + ret =3D -EOPNOTSUPP; + break; + } + if ( cpu =3D=3D 0 ) { ret =3D -EOPNOTSUPP; diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c index ae4e5a66d7..e3c4c0d5e0 100644 --- a/xen/arch/x86/smp.c +++ b/xen/arch/x86/smp.c @@ -416,6 +416,7 @@ void cf_check call_function_interrupt(void) smp_call_function_interrupt(); } =20 +#ifdef CONFIG_CPU_ONLINE_OFFLINE long cf_check cpu_up_helper(void *data) { unsigned int cpu =3D (unsigned long)data; @@ -443,8 +444,10 @@ long cf_check cpu_down_helper(void *data) { int cpu =3D (unsigned long)data; int ret =3D cpu_down(cpu); + /* Have one more go on EBUSY. */ if ( ret =3D=3D -EBUSY ) ret =3D cpu_down(cpu); return ret; } +#endif diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c index 6bd4e191a7..10d485e633 100644 --- a/xen/arch/x86/sysctl.c +++ b/xen/arch/x86/sysctl.c @@ -53,6 +53,12 @@ static long cf_check smt_up_down_helper(void *data) unsigned int cpu, sibling_mask =3D boot_cpu_data.x86_num_siblings - 1; int ret =3D 0; =20 + if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) + { + ASSERT_UNREACHABLE(); + return -EOPNOTSUPP; + } + opt_smt =3D up; =20 for_each_present_cpu ( cpu ) @@ -120,6 +126,12 @@ long arch_do_sysctl( long (*fn)(void *data); void *hcpu; =20 + if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) + { + ret =3D -EOPNOTSUPP; + break; + } + switch ( op ) { case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 5b289e444f..5713dc1f9c 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -646,6 +646,14 @@ config SYSTEM_SUSPEND =20 If unsure, say N. =20 +config CPU_ONLINE_OFFLINE + bool "CPU online/offline support" if EXPERT + depends on X86 + default y + help + Enable support for bringing CPUs online and offline at runtime. On + X86 this is required for disabling SMT. + menu "Supported hypercall interfaces" visible if EXPERT =20 --=20 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455218.1668810 (Exim 4.92) (envelope-from ) id 1xJ6Jt-0001i0-N8; Tue, 20 Oct 2026 09:39:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455218.1668810; Tue, 20 Oct 2026 09:39: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 1xJ6Jt-0001ga-HF; Tue, 20 Oct 2026 09:39:45 +0000 Received: by outflank-mailman (input) for mailman id 1455218; Tue, 20 Oct 2026 09:39:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6Jr-0001Gb-Qr for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jr-00228c-7a for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:43 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736de-2eae-0a2a0a5409dd-0a2a4503a702-6 for ; Tue, 20 Oct 2026 11:39:43 +0200 Received: from [52.101.66.96] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736de-fae8-0a2a45030019-346542601808-5 for ; Tue, 20 Oct 2026 11:39:43 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by DU0PR03MB8671.eurprd03.prod.outlook.com (2603:10a6:10:3eb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:41 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 09:39: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=li6WnMCS4yYj2DFfG9X5HgBqz1NHd18ZHV6D8cmInNGvPznlHzoCL2EFoz6ITt/JEd/rtkqr7lis9Or6mNkHh3B8QECev7lyyAZMNeQNHxTOwRulVg9BD3lxKQHqbceJhTUxrqgazIrHdGP1zRiTTZSqdGMTrqR/hlOsnwlwVt9NtGwMkVfWv2afDQ0PE26qfPCS8oQQ1G67svABFP0isk6SjytHnuTSlAMrnyZX2efOm4DyXJkTcg5GRjBVe2vEQVeRg+8+Bu+rE1gNhzUpZzcLCuBIMwN69PyRFdMqmu8NMxecLtCJ8fM7pWinaKrTV9SApDqEk41ELOcbNE5vaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WP09p0XgjdqZOlb1RwpfsNkWYXOT6ydA7eId42t90eI=; b=tiN8EmoR/n+nLiuque2kfi8dMPKya3wf5gz6lrfLABpXOGas+Al7xZUb57/zz6LEf5Jv3rR/KfzFP5kIS9DTMRzujGLl+lWntzA3PVDCgQ69C3/UxAULySzDguRNRK6kkr/TsrojMYThJhC6wBxYwKXrJ9+F4w1o2fwpYvRfNIequA3OhqO7VjJjXwhHy3mwMzk10CvVqfO773Ti1fU18LLVv2ZCovMPIfSzX05CY76TyBSTOd0dxTYNvDCm5scumXNoVe+znxr8iNNngztXdcC/04HWgnoB5qIPXI4n8022Fr05c1EoOsTqydZbygwK/QUQM8Gsm+RgBM03uTbgRg== 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=WP09p0XgjdqZOlb1RwpfsNkWYXOT6ydA7eId42t90eI=; b=riQGNllEEZ5VAN34bKrGKgQqDI8sJ9p6ai1rjeULgryr6JEV1ztYqEbDlmgXVwetYdZ8cOVfTPv1bYml/Lia71rn3uuRwBlfIYkjLrOiY4Qx//ZUC85m5Q/7Pqh3vLFDkzJ+lXiKU2NbInj8KZvqq0j5E/ZLq6oPk52tVHX4M/u9SWqVh6YgV28FnfT3NzywUeZ4jVj8XY3XsR7gdshIbLAx9M3gHyohyinFudsvsaLl0KeEy+FOv4DXCglptqjroWRdFKDPjh4aoiKVeYWPh4+a9lrAPkRtejPnuVtXUnbdiD9lxAZ2SSllo8pUdfo5ReSgzW3vL1MJjc5qtZBdJw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Anthony PERARD Subject: [PATCH v10 5/6] tools: Allow building xen-hptool without CONFIG_MIGRATE Thread-Topic: [PATCH v10 5/6] tools: Allow building xen-hptool without CONFIG_MIGRATE Thread-Index: AQHdYHbpwvfZ+lGiaEOW2pVf4XluEg== Date: Tue, 20 Oct 2026 09:39:32 +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: 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: PAVPR03MB10102:EE_|DU0PR03MB8671:EE_ x-ms-office365-filtering-correlation-id: 1d912ddd-2351-4aba-28d2-08df2e8e10ca x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|18002099003|10067099003|22082099003|11063799006|38070700021|260925021311599003|260925021911599003|260925022911599003|261009223027099003|56012099006; x-microsoft-antispam-message-info: D0DiKADtSiyj6sJbaFq6ZIjLfMMry0Qp91JZAofUtBvRUMJKRuWg7CQCFKRs05H599ww/5b4Z7h62SMI2UXeWSzqgo6cZY7mfpr0f/qIDoacckzRxZ+hWIViLP1UesLOHPfHmWJsEhs+Q92Hj2z4RMT8T9AfDw/ml7VbSqBNrSYfpA2CHJCEtxKZQ7jYkAnMKsdPX56Js8XX6nADZeFplIocCXlHQPxFflpZ/nt7y4z4E9g/Sb1plMFB561CBIx5l34Cc6Yj8TkcGj418WAwT+RYmQyW9blwpgkePlG7/c3XRZAi5DvxpD1/ykHR8ojPWVjMS64tZXBsRxQ/EF9jJ2bcJFitbiBZnv1XOL52MH/gAVo5pgFkObrQtHJUwkWejVUpMIfrBF6sP+ipj9Djx67OZfQ9KaUciQ8EhH+1WIaEEgclz2xxd8JbeH1HF8Odx80ecLWTqpBe/V/6oewM1UaOhbpNBI4q6/6py0QSFR1qSoD9A56Se2kbOhM3enzAdFmVFeMfcFlYCIPonEQkHL6vKIkcKCwQiz+zGDt3bFqo0Ocsj918QTHOmPmDLKvYDMu9BvYZUDYFoc8g5k1HEgUxUVMzT9y6K/Q3/kS5xpbEJ+50SBiN1dacJrJvtPJrzt2YU2rxYyHFV2TciRNd9dCm25Glnilknx2PFbd8Bga3hDrSoYBqk4DlkkmIblZiSczuOPwzlV4/jsY1ulj2jF0mABp3m/buz7jj7YANCS0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(6133799003)(18002099003)(10067099003)(22082099003)(11063799006)(38070700021)(260925021311599003)(260925021911599003)(260925022911599003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?zvnngu0tiLg5vnn9c58k6n56MgbsIisro/psHNwQUfUKGGp97VL1h09j01?= =?iso-8859-1?Q?Vixdd3OAUOwz0vYD0OF/6QW7OxOifml2Qxc7Ar/uRMEX/y/Pk/Q13PMCoh?= =?iso-8859-1?Q?ttzEQaOPuU6Kh5cIA9keSi6q4ZnnmiTw0eC1Ug+BwNsTc7iKE+dx9o3VJS?= =?iso-8859-1?Q?ax0bbrcVCdPRZ83/IEv8EvGRRccaBnn1l7OJa5hXlfW/PUf9eEx7n0NBe7?= =?iso-8859-1?Q?cF+5oCC2yhH4ajp74ys3vMtQqFCH/uZMxwqSar0ilMHzz8PT420p9D93eR?= =?iso-8859-1?Q?I24jIqRjSaN6R3hwQpBNO1YTUlmajSjoOPQOTeBPkdbjMcJTrz04PO05gi?= =?iso-8859-1?Q?kYdSgdBcHoSpLyAAx7Z+BdEZd4/riEwH02qC8cIFnNP0W4WJu/eCBZPRYt?= =?iso-8859-1?Q?upMLV2eqPCmyomzj1cGBZmG8J4GADeiPhdc7bW/C/bEnjIRexDfcRvBywX?= =?iso-8859-1?Q?6XaHyLWsCIgq7YFSSSUFcYX4ARYsNbwwx9GrPWzWvSGACLvGrc2To21UDB?= =?iso-8859-1?Q?mzMSDfV5GrCnLsJ/63YDQjA7aC4Yty0ZZUKka9OqVFSgM3VGyEdnSaRNiV?= =?iso-8859-1?Q?FrOK2dHjem1fGMX4c2/gbBU3IqIkYQ9DX9t5KViq2XxFOIz+lqWO8DZ0Cb?= =?iso-8859-1?Q?1iTLj2LoQ1Quxz5k37okjGILv91qH/KPLHmMXLBGAaib5Jt9LpfComKS0B?= =?iso-8859-1?Q?stO9k2iw617PWzyPUCKYnCqmiN/w6dCKLJGP97cUtAyHvWGneI0qy0/Jxf?= =?iso-8859-1?Q?+bn0mrKlYHdOKApzkvOQH5apnN+PTzIYRA1g6Z3Rgah12ASuRMY9AgvucM?= =?iso-8859-1?Q?MoRhl2uwqNPBJQVdZQUTOikBUmH4sLsYk2g1I2MPGpCsLaylI1kH2S3y0P?= =?iso-8859-1?Q?qrZcFVe1EoqhTId5iXpjiNIE4LyX6jSHpUMJOdJ4qCzeouSMTGE0AcqvaM?= =?iso-8859-1?Q?3s4yrL0Vx3Z9s+XwozwGlK8K1zIAhC3B0EW2IH1C8NwzSxoTX5+c+b7yne?= =?iso-8859-1?Q?sx5Q9XWmRrb+kiWcrJmDP5VznGKVpaatCZXHxQgsQmOss6rxd11sAiHTf8?= =?iso-8859-1?Q?07QXRB03eMb1bzI4D1085og6NQOtBlzgbqJkSPKsg2DSyGfD/8n1tBZmk8?= =?iso-8859-1?Q?dxMfoVM7J6vLCl8bFRC0Dr76pQZPMRsRyOsjURGbE7Q6jV6cmJ35WPZ0a4?= =?iso-8859-1?Q?kketk4EFsVLd/XzfT9v3GTNDJxCJ2ku4avzZweYg8IurlDewuWjX4jHnrF?= =?iso-8859-1?Q?ncluf4N/8TqU5e4B5ijvYW/Mm4imWRzR3SZmc5jWVuxT8s1DWvTbLq9auH?= =?iso-8859-1?Q?MH5UZhAAo+lkCjQ8VbGZUZ9kNu5Kdf4uPsOJJkA/Sl2fa+LpAfdTsszG2K?= =?iso-8859-1?Q?iViwhOBkKOaYWfVEfkoKOcMfI5QjVBfOvnbgbCmADpMmkJkbTq0k2W1nPF?= =?iso-8859-1?Q?dX0vqVlXa8/P7b/gALJDnr/GgG1n0etVNxufKDgAX8gpKTI+TtF3FfpLCT?= =?iso-8859-1?Q?s8Bkqi7auksfQ/njbV4xRLJND0dm5FhdHt6JdGr2ZxoKed1uXbAXwRELdT?= =?iso-8859-1?Q?FvEOLRZmRgPbUPUvnefMKNlxWk23fE8zSXv5wcYRZr6LYuhrJNUJvZ4ke0?= =?iso-8859-1?Q?muG3b8pPNQaTOnl9gQxd/531BIfT3ryzBHNosCYYErBHEv12TxhUhCTjd1?= =?iso-8859-1?Q?Qh8N81vG0NNQyZiIb9tdOixKF3sApevGgg8PKZk1aJCfJRg/f3IwQ4Y9+o?= =?iso-8859-1?Q?FabXLrI5a/wPV+p6i+z3w8mI8d6lz5m6WofA0nMIuDs7YIsCzSfJPUWweq?= =?iso-8859-1?Q?t4wpV4chDw=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d912ddd-2351-4aba-28d2-08df2e8e10ca X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 09:39:32.3138 (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: QFFLPGlojdKOBVECxzZQyrdYsqzG2Zg2bLnUv7JJoEIqTedkfQi6qG43Q2Z83hAKmNuU7DagGiHNtJxJJ4xKag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8671 X-purgate-ID: tlsNG-33051d/1792489183-77CC34E9-E416ED60/0/0 X-purgate-type: clean X-purgate-size: 24541 With CPU hotplug sysctls implemented on Arm it becomes useful to have a tool for calling them. According to the commit history it seems that putting hptool under config MIGRATE was a measure to fix IA64 build. As IA64 is no longer supported it can now be brought back. So build it unconditionally. Operations specific to x86 architecture are moved into a separate file and only built on x86. Signed-off-by: Mykyta Poturai Reviewed-by: Anthony PERARD --- v9->v10: * collect RB v8->v9: * use CONFIG_X86 instead of CONFIG_MIGRATE * fix style issues v7->v8: * move x86 specific function into a separate file v6->v7: * no changes v5->v6: * don't change order in Makefile v4->v5: * make hptool always build v3->v4: * no changes v2->v3: * no changes v1->v2: * switch to configure from legacy config --- tools/misc/Makefile | 9 +- tools/misc/xen-hptool-x86.c | 278 ++++++++++++++++++++++++++++++++++ tools/misc/xen-hptool.c | 293 ++---------------------------------- tools/misc/xen-hptool.h | 15 ++ 4 files changed, 314 insertions(+), 281 deletions(-) create mode 100644 tools/misc/xen-hptool-x86.c create mode 100644 tools/misc/xen-hptool.h diff --git a/tools/misc/Makefile b/tools/misc/Makefile index 6ee783f43e..064ab7c4bd 100644 --- a/tools/misc/Makefile +++ b/tools/misc/Makefile @@ -16,7 +16,7 @@ INSTALL_BIN +=3D xencov_split INSTALL_BIN +=3D $(INSTALL_BIN-y) =20 # Everything to be installed in regular sbin/ -INSTALL_SBIN-$(CONFIG_MIGRATE) +=3D xen-hptool +INSTALL_SBIN +=3D xen-hptool INSTALL_SBIN-$(CONFIG_X86) +=3D xen-hvmcrash INSTALL_SBIN-$(CONFIG_X86) +=3D xen-hvmctx INSTALL_SBIN-$(CONFIG_X86) +=3D xen-lowmemd @@ -104,8 +104,11 @@ xenhypfs: xenhypfs.o xenlockprof: xenlockprof.o $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS) =20 -xen-hptool: xen-hptool.o - $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(L= DLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS) +hptool-objs-y :=3D xen-hptool.o +hptool-objs-$(CONFIG_X86) +=3D xen-hptool-x86.o + +xen-hptool: $(hptool-objs-y) + $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(L= DLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS) =20 xenhypfs.o: CFLAGS +=3D $(CFLAGS_libxenhypfs) =20 diff --git a/tools/misc/xen-hptool-x86.c b/tools/misc/xen-hptool-x86.c new file mode 100644 index 0000000000..95a7e05990 --- /dev/null +++ b/tools/misc/xen-hptool-x86.c @@ -0,0 +1,278 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include +#include +#include +#include +#include +#include +#include "xen-hptool.h" + +int hp_mem_online_func(int argc, char *argv[], xc_interface *xch) +{ + uint32_t status; + int ret; + unsigned long mfn; + + if (argc !=3D 1) + { + show_help(); + return -1; + } + + sscanf(argv[0], "%lx", &mfn); + printf("Prepare to online MEMORY mfn %lx\n", mfn); + + ret =3D xc_mark_page_online(xch, mfn, mfn, &status); + + if (ret < 0) + fprintf(stderr, "Onlining page mfn %lx failed, error %x\n", mfn, e= rrno); + else if (status & (PG_ONLINE_FAILED |PG_ONLINE_BROKEN)) { + fprintf(stderr, "Onlining page mfn %lx is broken, " + "Memory online failed\n", mfn); + ret =3D -1; + } + else if (status & PG_ONLINE_ONLINED) + printf("Memory mfn %lx onlined successfully\n", mfn); + else + printf("Memory is already onlined!\n"); + + return ret; +} + +int hp_mem_query_func(int argc, char *argv[], xc_interface *xch) +{ + uint32_t status; + int ret; + unsigned long mfn; + + if (argc !=3D 1) + { + show_help(); + return -1; + } + + sscanf(argv[0], "%lx", &mfn); + printf("Querying MEMORY mfn %lx status\n", mfn); + ret =3D xc_query_page_offline_status(xch, mfn, mfn, &status); + + if (ret < 0) + fprintf(stderr, "Querying page mfn %lx failed, error %x\n", mfn, e= rrno); + else + { + printf("Memory Status %x: [", status); + if ( status & PG_OFFLINE_STATUS_OFFLINE_PENDING) + printf(" PAGE_OFFLINE_PENDING "); + if ( status & PG_OFFLINE_STATUS_BROKEN ) + printf(" PAGE_BROKEND "); + if ( status & PG_OFFLINE_STATUS_OFFLINED ) + printf(" PAGE_OFFLINED "); + else + printf(" PAGE_ONLINED "); + printf("]\n"); + } + + return ret; +} + +static int suspend_guest(xc_interface *xch, xenevtchn_handle *xce, int dom= id, + int *evtchn, int *lockfd) +{ + int port, rc, suspend_evtchn =3D -1; + + *lockfd =3D -1; + + if (!evtchn) + return -1; + + port =3D xs_suspend_evtchn_port(domid); + if (port < 0) + { + fprintf(stderr, "DOM%d: No suspend port, try live migration\n", do= mid); + goto failed; + } + suspend_evtchn =3D xc_suspend_evtchn_init_exclusive(xch, xce, domid, + port, lockfd); + if (suspend_evtchn < 0) + { + fprintf(stderr, "Suspend evtchn initialization failed\n"); + goto failed; + } + *evtchn =3D suspend_evtchn; + + rc =3D xenevtchn_notify(xce, suspend_evtchn); + if (rc < 0) + { + fprintf(stderr, "Failed to notify suspend channel: errno %d\n", rc= ); + goto failed; + } + if (xc_await_suspend(xch, xce, suspend_evtchn) < 0) + { + fprintf(stderr, "Suspend Failed\n"); + goto failed; + } + return 0; + +failed: + if (suspend_evtchn !=3D -1) + xc_suspend_evtchn_release(xch, xce, domid, + suspend_evtchn, lockfd); + + return -1; +} + +int hp_mem_offline_func(int argc, char *argv[], xc_interface *xch) +{ + uint32_t status, domid; + int ret; + unsigned long mfn; + + if (argc !=3D 1) + { + show_help(); + return -1; + } + + sscanf(argv[0], "%lx", &mfn); + printf("Prepare to offline MEMORY mfn %lx\n", mfn); + ret =3D xc_mark_page_offline(xch, mfn, mfn, &status); + if (ret < 0) { + fprintf(stderr, "Offlining page mfn %lx failed, error %x\n", mfn, = errno); + if (status & (PG_OFFLINE_XENPAGE | PG_OFFLINE_FAILED)) + fprintf(stderr, "XEN_PAGE is not permitted be offlined\n"); + else if (status & (PG_OFFLINE_FAILED | PG_OFFLINE_NOT_CONV_RAM)) + fprintf(stderr, "RESERVED RAM is not permitted to be offlined\= n"); + } + else + { + switch(status & PG_OFFLINE_STATUS_MASK) + { + case PG_OFFLINE_OFFLINED: + { + printf("Memory mfn %lx offlined successfully, current stat= e is" + " [PG_OFFLINE_OFFLINED]\n", mfn); + if (status & PG_OFFLINE_BROKEN) + printf("And this offlined PAGE is already marked broke= n" + " before!\n"); + break; + } + case PG_OFFLINE_FAILED: + { + fprintf(stderr, "Memory mfn %lx offline failed\n", mfn); + if ( status & PG_OFFLINE_ANONYMOUS) + fprintf(stderr, "the memory is an anonymous page!\n"); + ret =3D -1; + break; + } + case PG_OFFLINE_PENDING: + { + if (status & PG_OFFLINE_XENPAGE) { + ret =3D -1; + fprintf(stderr, "Memory mfn %lx offlined succssefully,= " + "this page is xen page, current state is" + " [PG_OFFLINE_PENDING, PG_OFFLINE_XENPAGE]\n",= mfn); + } + else if (status & PG_OFFLINE_OWNED) + { + int result, suspend_evtchn =3D -1, suspend_lockfd =3D = -1; + xenevtchn_handle *xce; + xce =3D xenevtchn_open(NULL, 0); + + if (xce =3D=3D NULL) + { + fprintf(stderr, "When exchange page, fail" + " to open evtchn\n"); + return -1; + } + + domid =3D status >> PG_OFFLINE_OWNER_SHIFT; + if (suspend_guest(xch, xce, domid, + &suspend_evtchn, &suspend_lockfd)) + { + fprintf(stderr, "Failed to suspend guest %d for" + " mfn %lx\n", domid, mfn); + xenevtchn_close(xce); + return -1; + } + + result =3D xc_exchange_page(xch, domid, mfn); + + /* Exchange page successfully */ + if (result =3D=3D 0) + printf("Memory mfn %lx offlined successfully, this= " + "page is DOM%d page and being swapped " + "successfully, current state is " + "[PG_OFFLINE_OFFLINED, PG_OFFLINE_OWNED]\n= ", + mfn, domid); + else { + ret =3D -1; + fprintf(stderr, "Memory mfn %lx offlined successfu= lly" + " , this page is DOM%d page yet failed to = be " + "exchanged. current state is " + "[PG_OFFLINE_PENDING, PG_OFFLINE_OWNED]\n"= , + mfn, domid); + } + xc_domain_resume(xch, domid, 1); + xc_suspend_evtchn_release(xch, xce, domid, + suspend_evtchn, &suspend_loc= kfd); + xenevtchn_close(xce); + } + break; + } + }//end of switch + }//end of if + + return ret; +} + +int main_smt_enable(int argc, char *argv[], xc_interface *xch) +{ + int ret; + + if ( argc ) + { + show_help(); + return -1; + } + + for ( ;; ) + { + ret =3D xc_smt_enable(xch); + if ( (ret >=3D 0) || (errno !=3D EBUSY) ) + break; + } + + if ( ret < 0 ) + fprintf(stderr, "Unable to enable SMT: errno %d, %s\n", + errno, strerror(errno)); + else + printf("Enabled SMT\n"); + + return ret; +} + +int main_smt_disable(int argc, char *argv[], xc_interface *xch) +{ + int ret; + + if ( argc ) + { + show_help(); + return -1; + } + + for ( ;; ) + { + ret =3D xc_smt_disable(xch); + if ( (ret >=3D 0) || (errno !=3D EBUSY) ) + break; + } + + if ( ret < 0 ) + fprintf(stderr, "Unable to disable SMT: errno %d, %s\n", + errno, strerror(errno)); + else + printf("Disabled SMT\n"); + + return ret; +} diff --git a/tools/misc/xen-hptool.c b/tools/misc/xen-hptool.c index 590810b6eb..7b886e2304 100644 --- a/tools/misc/xen-hptool.c +++ b/tools/misc/xen-hptool.c @@ -6,8 +6,8 @@ #include #include #include +#include "xen-hptool.h" =20 -static xc_interface *xch; =20 void show_help(void) { @@ -18,239 +18,25 @@ void show_help(void) " help display this help\n" " cpu-online online CPU \n" " cpu-offline offline CPU \n" +#if defined(__i386__) || defined(__x86_64__) " mem-online online MEMORY \n" " mem-offline offline MEMORY \n" " mem-status query Memory status\n" " smt-enable onlines all SMT threads\n" " smt-disable offlines all SMT threads\n" +#endif ); } =20 /* wrapper function */ -static int help_func(int argc, char *argv[]) +static int help_func(int argc, char *argv[], xc_interface *xch) { show_help(); return 0; } =20 -static int hp_mem_online_func(int argc, char *argv[]) -{ - uint32_t status; - int ret; - unsigned long mfn; - - if (argc !=3D 1) - { - show_help(); - return -1; - } - - sscanf(argv[0], "%lx", &mfn); - printf("Prepare to online MEMORY mfn %lx\n", mfn); - - ret =3D xc_mark_page_online(xch, mfn, mfn, &status); - - if (ret < 0) - fprintf(stderr, "Onlining page mfn %lx failed, error %x\n", mfn, e= rrno); - else if (status & (PG_ONLINE_FAILED |PG_ONLINE_BROKEN)) { - fprintf(stderr, "Onlining page mfn %lx is broken, " - "Memory online failed\n", mfn); - ret =3D -1; - } - else if (status & PG_ONLINE_ONLINED) - printf("Memory mfn %lx onlined successfully\n", mfn); - else - printf("Memory is already onlined!\n"); - - return ret; -} - -static int hp_mem_query_func(int argc, char *argv[]) -{ - uint32_t status; - int ret; - unsigned long mfn; - - if (argc !=3D 1) - { - show_help(); - return -1; - } - - sscanf(argv[0], "%lx", &mfn); - printf("Querying MEMORY mfn %lx status\n", mfn); - ret =3D xc_query_page_offline_status(xch, mfn, mfn, &status); - - if (ret < 0) - fprintf(stderr, "Querying page mfn %lx failed, error %x\n", mfn, e= rrno); - else - { - printf("Memory Status %x: [", status); - if ( status & PG_OFFLINE_STATUS_OFFLINE_PENDING) - printf(" PAGE_OFFLINE_PENDING "); - if ( status & PG_OFFLINE_STATUS_BROKEN ) - printf(" PAGE_BROKEND "); - if ( status & PG_OFFLINE_STATUS_OFFLINED ) - printf(" PAGE_OFFLINED "); - else - printf(" PAGE_ONLINED "); - printf("]\n"); - } - - return ret; -} - -static int suspend_guest(xc_interface *xch, xenevtchn_handle *xce, int dom= id, - int *evtchn, int *lockfd) -{ - int port, rc, suspend_evtchn =3D -1; - - *lockfd =3D -1; - - if (!evtchn) - return -1; - - port =3D xs_suspend_evtchn_port(domid); - if (port < 0) - { - fprintf(stderr, "DOM%d: No suspend port, try live migration\n", do= mid); - goto failed; - } - suspend_evtchn =3D xc_suspend_evtchn_init_exclusive(xch, xce, domid, - port, lockfd); - if (suspend_evtchn < 0) - { - fprintf(stderr, "Suspend evtchn initialization failed\n"); - goto failed; - } - *evtchn =3D suspend_evtchn; - - rc =3D xenevtchn_notify(xce, suspend_evtchn); - if (rc < 0) - { - fprintf(stderr, "Failed to notify suspend channel: errno %d\n", rc= ); - goto failed; - } - if (xc_await_suspend(xch, xce, suspend_evtchn) < 0) - { - fprintf(stderr, "Suspend Failed\n"); - goto failed; - } - return 0; - -failed: - if (suspend_evtchn !=3D -1) - xc_suspend_evtchn_release(xch, xce, domid, - suspend_evtchn, lockfd); - - return -1; -} - -static int hp_mem_offline_func(int argc, char *argv[]) -{ - uint32_t status, domid; - int ret; - unsigned long mfn; - - if (argc !=3D 1) - { - show_help(); - return -1; - } - - sscanf(argv[0], "%lx", &mfn); - printf("Prepare to offline MEMORY mfn %lx\n", mfn); - ret =3D xc_mark_page_offline(xch, mfn, mfn, &status); - if (ret < 0) { - fprintf(stderr, "Offlining page mfn %lx failed, error %x\n", mfn, = errno); - if (status & (PG_OFFLINE_XENPAGE | PG_OFFLINE_FAILED)) - fprintf(stderr, "XEN_PAGE is not permitted be offlined\n"); - else if (status & (PG_OFFLINE_FAILED | PG_OFFLINE_NOT_CONV_RAM)) - fprintf(stderr, "RESERVED RAM is not permitted to be offlined\= n"); - } - else - { - switch(status & PG_OFFLINE_STATUS_MASK) - { - case PG_OFFLINE_OFFLINED: - { - printf("Memory mfn %lx offlined successfully, current stat= e is" - " [PG_OFFLINE_OFFLINED]\n", mfn); - if (status & PG_OFFLINE_BROKEN) - printf("And this offlined PAGE is already marked broke= n" - " before!\n"); - break; - } - case PG_OFFLINE_FAILED: - { - fprintf(stderr, "Memory mfn %lx offline failed\n", mfn); - if ( status & PG_OFFLINE_ANONYMOUS) - fprintf(stderr, "the memory is an anonymous page!\n"); - ret =3D -1; - break; - } - case PG_OFFLINE_PENDING: - { - if (status & PG_OFFLINE_XENPAGE) { - ret =3D -1; - fprintf(stderr, "Memory mfn %lx offlined succssefully,= " - "this page is xen page, current state is" - " [PG_OFFLINE_PENDING, PG_OFFLINE_XENPAGE]\n",= mfn); - } - else if (status & PG_OFFLINE_OWNED) - { - int result, suspend_evtchn =3D -1, suspend_lockfd =3D = -1; - xenevtchn_handle *xce; - xce =3D xenevtchn_open(NULL, 0); - - if (xce =3D=3D NULL) - { - fprintf(stderr, "When exchange page, fail" - " to open evtchn\n"); - return -1; - } - - domid =3D status >> PG_OFFLINE_OWNER_SHIFT; - if (suspend_guest(xch, xce, domid, - &suspend_evtchn, &suspend_lockfd)) - { - fprintf(stderr, "Failed to suspend guest %d for" - " mfn %lx\n", domid, mfn); - xenevtchn_close(xce); - return -1; - } - - result =3D xc_exchange_page(xch, domid, mfn); - - /* Exchange page successfully */ - if (result =3D=3D 0) - printf("Memory mfn %lx offlined successfully, this= " - "page is DOM%d page and being swapped " - "successfully, current state is " - "[PG_OFFLINE_OFFLINED, PG_OFFLINE_OWNED]\n= ", - mfn, domid); - else { - ret =3D -1; - fprintf(stderr, "Memory mfn %lx offlined successfu= lly" - " , this page is DOM%d page yet failed to = be " - "exchanged. current state is " - "[PG_OFFLINE_PENDING, PG_OFFLINE_OWNED]\n"= , - mfn, domid); - } - xc_domain_resume(xch, domid, 1); - xc_suspend_evtchn_release(xch, xce, domid, - suspend_evtchn, &suspend_loc= kfd); - xenevtchn_close(xce); - } - break; - } - }//end of switch - }//end of if - - return ret; -} - -static int exec_cpu_hp_fn(int (*hp_fn)(xc_interface *, int), int cpu) +static int exec_cpu_hp_fn(int (*hp_fn)(xc_interface *, int), int cpu, + xc_interface *xch) { int ret; =20 @@ -265,7 +51,7 @@ static int exec_cpu_hp_fn(int (*hp_fn)(xc_interface *, i= nt), int cpu) return ret; } =20 -static int hp_cpu_online_func(int argc, char *argv[]) +static int hp_cpu_online_func(int argc, char *argv[], xc_interface *xch) { int cpu, ret; =20 @@ -277,7 +63,7 @@ static int hp_cpu_online_func(int argc, char *argv[]) =20 cpu =3D atoi(argv[0]); printf("Prepare to online CPU %d\n", cpu); - ret =3D exec_cpu_hp_fn(xc_cpu_online, cpu); + ret =3D exec_cpu_hp_fn(xc_cpu_online, cpu, xch); if (ret < 0) fprintf(stderr, "CPU %d online failed (error %d: %s)\n", cpu, errno, strerror(errno)); @@ -287,7 +73,7 @@ static int hp_cpu_online_func(int argc, char *argv[]) return ret; =20 } -static int hp_cpu_offline_func(int argc, char *argv[]) +static int hp_cpu_offline_func(int argc, char *argv[], xc_interface *xch) { int cpu, ret; =20 @@ -298,7 +84,7 @@ static int hp_cpu_offline_func(int argc, char *argv[]) } cpu =3D atoi(argv[0]); printf("Prepare to offline CPU %d\n", cpu); - ret =3D exec_cpu_hp_fn(xc_cpu_offline, cpu); + ret =3D exec_cpu_hp_fn(xc_cpu_offline, cpu, xch); if (ret < 0) fprintf(stderr, "CPU %d offline failed (error %d: %s)\n", cpu, errno, strerror(errno)); @@ -308,76 +94,27 @@ static int hp_cpu_offline_func(int argc, char *argv[]) return ret; } =20 -static int main_smt_enable(int argc, char *argv[]) -{ - int ret; - - if ( argc ) - { - show_help(); - return -1; - } - - for ( ;; ) - { - ret =3D xc_smt_enable(xch); - if ( (ret >=3D 0) || (errno !=3D EBUSY) ) - break; - } - - if ( ret < 0 ) - fprintf(stderr, "Unable to enable SMT: errno %d, %s\n", - errno, strerror(errno)); - else - printf("Enabled SMT\n"); - - return ret; -} - -static int main_smt_disable(int argc, char *argv[]) -{ - int ret; - - if ( argc ) - { - show_help(); - return -1; - } - - for ( ;; ) - { - ret =3D xc_smt_disable(xch); - if ( (ret >=3D 0) || (errno !=3D EBUSY) ) - break; - } - - if ( ret < 0 ) - fprintf(stderr, "Unable to disable SMT: errno %d, %s\n", - errno, strerror(errno)); - else - printf("Disabled SMT\n"); - - return ret; -} - struct { const char *name; - int (*function)(int argc, char *argv[]); + int (*function)(int argc, char *argv[], xc_interface *xch); } main_options[] =3D { { "help", help_func }, { "cpu-online", hp_cpu_online_func }, { "cpu-offline", hp_cpu_offline_func }, +#if defined(__i386__) || defined(__x86_64__) { "mem-status", hp_mem_query_func}, { "mem-online", hp_mem_online_func}, { "mem-offline", hp_mem_offline_func}, { "smt-enable", main_smt_enable }, { "smt-disable", main_smt_disable }, +#endif }; =20 =20 int main(int argc, char *argv[]) { int i, ret; + xc_interface *xch; =20 if (argc < 2) { @@ -402,7 +139,7 @@ int main(int argc, char *argv[]) return 1; } =20 - ret =3D main_options[i].function(argc -2, argv + 2); + ret =3D main_options[i].function(argc -2, argv + 2, xch); =20 xc_interface_close(xch); =20 diff --git a/tools/misc/xen-hptool.h b/tools/misc/xen-hptool.h new file mode 100644 index 0000000000..34f492c34b --- /dev/null +++ b/tools/misc/xen-hptool.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef __XEN_HPTOOL_H__ +#define __XEN_HPTOOL_H__ + +#if defined(__i386__) || defined(__x86_64__) +int hp_mem_online_func(int argc, char *argv[], xc_interface *xch); +int hp_mem_query_func(int argc, char *argv[], xc_interface *xch); +int hp_mem_offline_func(int argc, char *argv[], xc_interface *xch); +int main_smt_enable(int argc, char *argv[], xc_interface *xch); +int main_smt_disable(int argc, char *argv[], xc_interface *xch); +#endif + +void show_help(void); + +#endif /* __XEN_HPTOOL_H__ */ --=20 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455219.1668813 (Exim 4.92) (envelope-from ) id 1xJ6Ju-0001lX-2R; Tue, 20 Oct 2026 09:39:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455219.1668813; Tue, 20 Oct 2026 09:39: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 1xJ6Jt-0001l6-Rc; Tue, 20 Oct 2026 09:39:45 +0000 Received: by outflank-mailman (input) for mailman id 1455219; Tue, 20 Oct 2026 09:39:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6Js-0001Go-2d for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jr-00228c-Fu for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:43 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736de-2eae-0a2a0a5409dd-0a2a4503a702-10 for ; Tue, 20 Oct 2026 11:39:43 +0200 Received: from [52.101.66.96] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736de-fae8-0a2a45030019-346542601808-6 for ; Tue, 20 Oct 2026 11:39:43 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by DU0PR03MB8671.eurprd03.prod.outlook.com (2603:10a6:10:3eb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:41 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 09:39: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=Y1tGMxrIJP88P4gjOMCO4+swm8OEVHJmbWGPdHmL5vJrXBPrbHMewaiYHPKhWMGNbqwsL6HzEv2jhtTznrZNLJ0xd7jQow05PSzs9K5u1w1eGxxaW1+H3+YVHYv0I1UBlrHMZRjvxAsNAiBEvMKpuM15epJF9wKTIBBW3Pite76EfniSJ3DbXK53p8JJ2Wifr1oSkthAa+9A9BqoDO/aRkEygA+db14j3cc1vEFUcUBkgUOm14R7Stb1zBXY+PCsBLItmhpyLdP6xeFhF6X8WM0tfciGk9mAVXhBhXJnPUsZbk6ZmKTEn4f7cCJpzhGFJ4hDNvrJB8uC9uBCHXUA9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M8Vqp7IgRH5ASACw2BY0rPnCZbIROisRLWI9droQYbY=; b=EtuCjox+bWUUtkiPuMZ0v9hwYdO+CQjiywq1rYCHmXdoQRsGR1YSpD1ELYQZsZzFnKWpqu+zzRftKKGcBXC+ozYiDoXdjf4ULHZt/RU+CcqQM8pPmq/mWM7FLm/9V6368tHbsnY8F4Hp4ZbHBPpY42sArt0lV84KCwvusDrE4DKABnGZywExnNAbybmrVhDxEto+KuKzKmSMKQKwhy4S8IMuyvJnLkz0q3i4jjIM44ibob7PEo6O3oxcYrkB2revSF5vWiWhdPWS92su5F3SIHTLC9UwmjkYt1iKTj4ZuzYxxFHUgkTnbQ7VpczlizdTSAbjFN6HOeQFVOQ0UkqQ7g== 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=M8Vqp7IgRH5ASACw2BY0rPnCZbIROisRLWI9droQYbY=; b=s1h4hTuTjHGkz7BYZfwLaLzqq5kyiohYU/HUBPVNJLobru9Yith/816PgSgUQlWNO/eUwZG7jXbZA+eRtMIbu+sblp/rgJ2BKBCinUp5J55eHtDCDL1JhsMv7RHFsHpY/vuWtAB1KqxYwKLrKoKq0vPQNYIQ/L966H7R1N6gfINFWVkWMo3+FBMSXXXceFsfqxxso9QdwMixXeeuSSNhnktFqqdmpRWszq/oRE/ej2RuL78T5VdL13gFQZUSdCxzOOHrrd80LtQffApmXow+DcBGSkkvHmP4NdOWpr7DUpx+baqY+IOfRWxXaOgr5awNORBezw7ivmUk/nLYLAMmyw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Teddy Astie , "Daniel P. Smith" Subject: [PATCH v10 4/6] arm/sysctl: Implement cpu hotplug ops Thread-Topic: [PATCH v10 4/6] arm/sysctl: Implement cpu hotplug ops Thread-Index: AQHdYHboqAxeQuFbP0CPmTz/IKkt0g== Date: Tue, 20 Oct 2026 09:39:31 +0000 Message-ID: <2fb71ea8cfe221f25b1dbbb50bdc5a74be09194c.1792480416.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: PAVPR03MB10102:EE_|DU0PR03MB8671:EE_ x-ms-office365-filtering-correlation-id: 45da5fe9-be6e-4a80-c886-08df2e8e10a5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|23010399003|1800799024|366016|10063799003|18002099003|10067099003|22082099003|11063799006|38070700021|261009223027099003|56012099006; x-microsoft-antispam-message-info: xvvKk5zGv+RGx2o8VxudvIPTNpTCanvfeGdjs49i6saQT6DkuRv/oeF1oM05Ep11JNWs/w5z7+9mPJpYdx/ZrVTsTh5id/SYR6IRhxUGg2/4Tel31ViNq//LiSSDqfuDW5EtLxAqJcstxezohDp8nVempw7YPfQ0RfCPXG28/K/etxSCoAVtwLqEHZNTvrWUyBnoc2kijtxvPVFF8xft0JYEImtGDp3vM34j85bu4PAS7JD7QMt4jLByVK2a12lCzkCmCH8TL7S2br+wddFbjb+gVIJvfWsWIRDxfZkNL4pYsbIAG6+C4O0ute1qlF4d8NacfV56M4j4+vYHA45Vw5iQtEH/2uz/JDUEB8zdFvN50fOF50/gROQGUUbqrSMXS0A+JO/bNPpkkr7ht5FlxgB+UE5dl6mTgkGr4yB9d8/6ykBsXsrpQCr7zpI2t0cYrNCQ3EJZRU1cqoHaKBF56CCt+PwtBDLi+XECUjAIugLub59k/JhoBu30lugXn1qAr526NFKrTPoZlGJlbVJEx5JitDMXM4QVnSYIJOGq3pU/fJ2/g8qdQvP333F9QrHFGCkk2KqnwkPH+BYLpXg5/1KKWGvXgeRhZkdzn+HjdHVlFTlMp5WjT4TjvCjdc4BdboyoDlP7zeV/t8Ymmu5yEmlzEWxa+zliccVedVEIeJt7JWEzmoQ+jpT6HsplpsbXvJxE3L7xjPPNsyiZx2CLZAWR/S7uvloIKR+dt2y8sAw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(23010399003)(1800799024)(366016)(10063799003)(18002099003)(10067099003)(22082099003)(11063799006)(38070700021)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?iO1RTeOuGdTkh5+/2aAza5V3wenrLnAzbJkfwzG0XTHseDUILVhBksxTSC?= =?iso-8859-1?Q?MDnWOb140qiVtkGk6+SEZ5xS9c7k0YCmArMAlJW40K2txDzZkgq4O8ISsM?= =?iso-8859-1?Q?HYiiMKvMl/GrDblPE9+toY4XSrR3GTfH3kVttX2+5X3DSg0rm4OnH7yKCd?= =?iso-8859-1?Q?WzieaHpX9ATCRdPBSemAqZbMdyQVH3rHVVYxdC3CglqWoS/Yhly2D6osp0?= =?iso-8859-1?Q?tVm0JfalVcnBjonT2va2w9bCVjdJBokG3GiYqA6wyI/WXcPWv1WzqHNN8Y?= =?iso-8859-1?Q?NxhZ3+qYtP4ZWvLar0Heg8wOeOS2sMtddpizAsSNfgGOq463kgt0WhF/hI?= =?iso-8859-1?Q?9N3/NoYlPfPGS/xX1RjkQCA3tqJLm44cgP7MtlEKvmEgEvlG3Ms71VCjL9?= =?iso-8859-1?Q?wo/NnUSOFcCYjTaCZdo+SUvirIQYAzDrrDAGBbisp+7kvKfGAhvb8c+vES?= =?iso-8859-1?Q?/s/HF45FSmfU0Y9fesEV1jikX3Xqx+mYa20CuedfKLUV1cz8lwNGSneXd+?= =?iso-8859-1?Q?tB7ukhfiLbUCtVA4lHbAmRo43djqr5uJcu1Kln9sNE1bkQXDcKuqe2aO0F?= =?iso-8859-1?Q?4AfXDtKs11gWmurmIdjdXYUGpwQzknySeV8pLLrxH8MYkIJB0IosU07Lkz?= =?iso-8859-1?Q?HNlvneIkuL2/pPenLUT6x3Bb01fhnEqIuDkfjmpGSs0IrphEYlASeCFpPw?= =?iso-8859-1?Q?0g9DX3U8I7OFaEgHBIp5HtnKsMnxK2eVRp5555Brj1kU+yqjihyyZkbwJM?= =?iso-8859-1?Q?IY7Dwp6koHq4XQ4IyKCpLY5DfUXG+8yh7xfTKE6rBK8AoG5jpbvenaWszw?= =?iso-8859-1?Q?Pl9fJiC9C44RaNC9Mla/sp4dnrCs4LHQczi/gMySVMs1TTbqk1PwRq7jrd?= =?iso-8859-1?Q?aeAuLH7Iqr8zOoURyLIpmEpRFs30MWBEeTgGZ0uIbCrEJD7jKbiwRCmI4g?= =?iso-8859-1?Q?QLMl+POE+HQkoAD3mmMz/FsNIpxgfTj8CKNfSk5OocK1+dJ5p2sEiqPTbN?= =?iso-8859-1?Q?1STmR+Ln8b0d1WBwI0PLGCsP/IHN/kt2bCip4DwHlnE6hUbJlddG+hP2of?= =?iso-8859-1?Q?R+jjf2lXvk8hqUh3HiPLpVbxTnWYGQcV1h9XIc9rF4ura7KOUJBpGyD1yL?= =?iso-8859-1?Q?uuKM7nLk1bt2NXlZ7AAezPehxQWPQD+EI0zI0QTloBW0NSTamaLc+GCwpx?= =?iso-8859-1?Q?X3XS+JK80H5q9Drzov87HEBzENyqNba62dkM6uB/WuG70TiaJXWGzjxP72?= =?iso-8859-1?Q?Nl/B6G9RxPgNmhlkjPPfUOq4kZeqIOqh7SUWJb2cCwzJ4kmn6eiMnQTui4?= =?iso-8859-1?Q?esTsm/J/fRcL8+uHm0rGVCXMxtzgwRq+uh5DN+7Fd3BoR1ZP8aRWzxD0XW?= =?iso-8859-1?Q?L+46Hn9WeS8uxlHLXj+/Qyy3Ufe9sP12hvw+vjPKxuEa4nudrJXZiR8vwx?= =?iso-8859-1?Q?nfRaYg6wmvGuTs6YP48TsrGXPo3ZNVxQS09Lf+IxmH3Bwk/xQGQwzKBPiE?= =?iso-8859-1?Q?r7OdxWJddwKXTyTg+2YzWRUaEBWmrdi9pW97vK5cQSZPw2fE+9cNrja0uG?= =?iso-8859-1?Q?60kzNXJnyV1uYCP2YMXI/dkNzp1Vzj+W9p5/gMaTgCUQ0g70YDVxhRqOl2?= =?iso-8859-1?Q?YkwotTVxwjRMOClrNcDSkcRzEijenruto+E8aSM7I5ZqSizvTAlnwsD8bn?= =?iso-8859-1?Q?YPPWsF9RwsqnUNt6vs4YRgC/U2Em+NnIoI3x01jRz9EH0FA22kj43bcHFA?= =?iso-8859-1?Q?lvnwij5tTndf+y0k48Ah9g1sZYsERoBDfchk61NqFYGKUoY2nqk/V4ISDe?= =?iso-8859-1?Q?sNbm3jipyw=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45da5fe9-be6e-4a80-c886-08df2e8e10a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 09:39:31.6825 (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: 3R6UH0nLvF2ylHRYnscjCo+9tCN2N+1Qslltjxeu1GYDjDDYnC3dw+bhHJF9yk2M9begBNYUmKAsGdeiNIBHnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8671 X-purgate-ID: tlsNG-33051d/1792489183-6DCD34E9-405638AA/0/0 X-purgate-type: clean X-purgate-size: 10479 SMT-disable enforcement check is moved into a separate architecture-specific function. For now this operations only support Arm64. For proper Arm32 support, there needs to be a mechanism to free per-cpu page tables, allocated in init_domheap_mappings. Also, hotplug is not supported if ITS enabled, and partially supported FFA, or TEE is enabled, as they use non-static IRQ actions. Remove ifdef guards for x86 in flask, as cpu hotplug is now supported on more architectures. Signed-off-by: Mykyta Poturai --- v9->v10: * rename arch_cpu_can_stay_online to arch_cpu_keep_online * drop the single-use hp_op and hcpu variables * make CPU_ONLINE_OFFLINE depend on !TEE, as FFA and TEE use non-static IRQ actions v8->v9: * simplify dependencies of config CPU_ONLINE_OFFLINE again * rebased ove XSA-499 v7->v8: * simplify dependencies of config CPU_ONLINE_OFFLINE v6->v7: * use IS_ENABLED istead of ifdef in more places * remove unneded variables * more explicit fallthrough in do_sysctl v5->v6: * fix style issues * rename arch_smt_cpu_disable -> arch_cpu_can_stay_online and invert the logic * use IS_ENABLED istead of ifdef * remove explicit list af arch-specific SYSCTL_CPU_HOTPLUG_* options from the common handler * fix flask issue v4->v5: * move handling to common code * rename config to CPU_HOTPUG * merge with "smp: Move cpu_up/down helpers to common code" v3->v4: * don't reimplement cpu_up/down helpers * add Kconfig option * fixup formatting v2->v3: * no changes v1->v2: * remove SMT ops * remove cpu =3D=3D 0 checks * add XSM hooks * only implement for 64bit Arm --- xen/arch/arm/smp.c | 9 +++++++++ xen/arch/ppc/stubs.c | 5 +++++ xen/arch/riscv/stubs.c | 5 +++++ xen/arch/x86/include/asm/smp.h | 3 --- xen/arch/x86/smp.c | 34 +++------------------------------ xen/arch/x86/sysctl.c | 11 ++++------- xen/common/Kconfig | 4 ++-- xen/common/smp.c | 35 ++++++++++++++++++++++++++++++++++ xen/common/sysctl.c | 32 +++++++++++++++++++++++++++++++ xen/include/xen/smp.h | 4 ++++ xen/xsm/flask/hooks.c | 2 +- 11 files changed, 100 insertions(+), 44 deletions(-) diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c index b372472188..039577ad02 100644 --- a/xen/arch/arm/smp.c +++ b/xen/arch/arm/smp.c @@ -44,6 +44,15 @@ void smp_send_call_function_mask(const cpumask_t *mask) } } =20 +/* + * We currently don't support SMT on ARM so we don't need any special logi= c for + * CPU disabling + */ +bool arch_cpu_keep_online(unsigned int cpu) +{ + return true; +} + /* * Local variables: * mode: C diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c index 82a289af85..2c2e9412ad 100644 --- a/xen/arch/ppc/stubs.c +++ b/xen/arch/ppc/stubs.c @@ -101,6 +101,11 @@ void smp_send_call_function_mask(const cpumask_t *mask= ) BUG_ON("unimplemented"); } =20 +bool arch_cpu_keep_online(unsigned int cpu) +{ + BUG_ON("unimplemented"); +} + /* irq.c */ =20 void irq_ack_none(struct irq_desc *desc) diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 3a7953593d..2307408c6c 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -65,6 +65,11 @@ void smp_send_call_function_mask(const cpumask_t *mask) BUG_ON("unimplemented"); } =20 +bool arch_cpu_keep_online(unsigned int cpu) +{ + BUG_ON("unimplemented"); +} + /* irq.c */ =20 void irq_ack_none(struct irq_desc *desc) diff --git a/xen/arch/x86/include/asm/smp.h b/xen/arch/x86/include/asm/smp.= h index 572b39b01c..6c33567cb5 100644 --- a/xen/arch/x86/include/asm/smp.h +++ b/xen/arch/x86/include/asm/smp.h @@ -44,9 +44,6 @@ int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t = pxm); =20 void __stop_this_cpu(void); =20 -long cf_check cpu_up_helper(void *data); -long cf_check cpu_down_helper(void *data); - long cf_check core_parking_helper(void *data); bool core_parking_remove(unsigned int cpu); uint32_t get_cur_idle_nums(void); diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c index e3c4c0d5e0..b56d8dfd36 100644 --- a/xen/arch/x86/smp.c +++ b/xen/arch/x86/smp.c @@ -417,37 +417,9 @@ void cf_check call_function_interrupt(void) } =20 #ifdef CONFIG_CPU_ONLINE_OFFLINE -long cf_check cpu_up_helper(void *data) +bool arch_cpu_keep_online(unsigned int cpu) { - unsigned int cpu =3D (unsigned long)data; - int ret =3D cpu_up(cpu); - - /* Have one more go on EBUSY. */ - if ( ret =3D=3D -EBUSY ) - ret =3D cpu_up(cpu); - - if ( !ret && !opt_smt && - cpu_data[cpu].compute_unit_id =3D=3D INVALID_CUID && - cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) > 1 ) - { - ret =3D cpu_down_helper(data); - if ( ret ) - printk("Could not re-offline CPU%u (%d)\n", cpu, ret); - else - ret =3D -EPERM; - } - - return ret; -} - -long cf_check cpu_down_helper(void *data) -{ - int cpu =3D (unsigned long)data; - int ret =3D cpu_down(cpu); - - /* Have one more go on EBUSY. */ - if ( ret =3D=3D -EBUSY ) - ret =3D cpu_down(cpu); - return ret; + return opt_smt || cpu_data[cpu].compute_unit_id !=3D INVALID_CUID || + cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) <=3D 1; } #endif diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c index 10d485e633..a4254beabb 100644 --- a/xen/arch/x86/sysctl.c +++ b/xen/arch/x86/sysctl.c @@ -121,13 +121,13 @@ long arch_do_sysctl( =20 case XEN_SYSCTL_cpu_hotplug: { - unsigned int cpu =3D sysctl->u.cpu_hotplug.cpu; unsigned int op =3D sysctl->u.cpu_hotplug.op; long (*fn)(void *data); void *hcpu; =20 if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) { + ASSERT_UNREACHABLE(); ret =3D -EOPNOTSUPP; break; } @@ -135,13 +135,10 @@ long arch_do_sysctl( switch ( op ) { case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: - fn =3D cpu_up_helper; - hcpu =3D _p(cpu); - break; - case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: - fn =3D cpu_down_helper; - hcpu =3D _p(cpu); + /* Handled by common code */ + ASSERT_UNREACHABLE(); + ret =3D -EOPNOTSUPP; break; =20 case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE: diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 5713dc1f9c..329bb07ae9 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -648,8 +648,8 @@ config SYSTEM_SUSPEND =20 config CPU_ONLINE_OFFLINE bool "CPU online/offline support" if EXPERT - depends on X86 - default y + depends on !ARM || (!HAS_ITS && !TEE) + default X86 help Enable support for bringing CPUs online and offline at runtime. On X86 this is required for disabling SMT. diff --git a/xen/common/smp.c b/xen/common/smp.c index a011f541f1..af532d4873 100644 --- a/xen/common/smp.c +++ b/xen/common/smp.c @@ -16,6 +16,7 @@ * GNU General Public License for more details. */ =20 +#include #include #include #include @@ -104,6 +105,40 @@ void smp_call_function_interrupt(void) irq_exit(); } =20 +#ifdef CONFIG_CPU_ONLINE_OFFLINE +long cf_check cpu_up_helper(void *data) +{ + unsigned int cpu =3D (unsigned long)data; + int ret =3D cpu_up(cpu); + + /* Have one more go on EBUSY. */ + if ( ret =3D=3D -EBUSY ) + ret =3D cpu_up(cpu); + + if ( !ret && !arch_cpu_keep_online(cpu) ) + { + ret =3D cpu_down_helper(data); + if ( ret ) + printk("Could not re-offline CPU%u (%d)\n", cpu, ret); + else + ret =3D -EPERM; + } + + return ret; +} + +long cf_check cpu_down_helper(void *data) +{ + unsigned int cpu =3D (unsigned long)data; + int ret =3D cpu_down(cpu); + + /* Have one more go on EBUSY. */ + if ( ret =3D=3D -EBUSY ) + ret =3D cpu_down(cpu); + return ret; +} +#endif /* CONFIG_CPU_ONLINE_OFFLINE */ + /* * Local variables: * mode: C diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 8fb5ff0af3..dd21b6ff7e 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -475,6 +475,38 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_= sysctl) copyback =3D 1; break; =20 + case XEN_SYSCTL_cpu_hotplug: + { + long (*fn)(void *data); + + ret =3D -EOPNOTSUPP; + if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) + break; + + switch ( op->u.cpu_hotplug.op ) + { + case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: + fn =3D cpu_up_helper; + break; + + case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: + fn =3D cpu_down_helper; + break; + + default: + fn =3D NULL; + break; + } + + if ( fn ) + { + ret =3D continue_hypercall_on_cpu(0, fn, _p(op->u.cpu_hotplug.= cpu)); + break; + } + } + + /* Use the arch handler for cases not handled here */ + fallthrough; default: ret =3D arch_do_sysctl(op, u_sysctl); copyback =3D 0; diff --git a/xen/include/xen/smp.h b/xen/include/xen/smp.h index 2ca9ff1bfc..525099e182 100644 --- a/xen/include/xen/smp.h +++ b/xen/include/xen/smp.h @@ -76,4 +76,8 @@ extern void *stack_base[NR_CPUS]; void initialize_cpu_data(unsigned int cpu); int setup_cpu_root_pgt(unsigned int cpu); =20 +bool arch_cpu_keep_online(unsigned int cpu); +long cf_check cpu_up_helper(void *data); +long cf_check cpu_down_helper(void *data); + #endif /* __XEN_SMP_H__ */ diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index d65ba0aeae..a1eed309b4 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -957,7 +957,7 @@ static int cf_check flask_sysctl(const struct xen_sysct= l *op) case XEN_SYSCTL_getdomaininfolist: return flask_getdomaininfo(dom_xen); =20 -#ifdef CONFIG_X86 +#ifdef CONFIG_CPU_ONLINE_OFFLINE case XEN_SYSCTL_cpu_hotplug: switch ( op->u.cpu_hotplug.op ) { --=20 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 09:39:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 09:39:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455224.1668828 (Exim 4.92) (envelope-from ) id 1xJ6K1-0002Pd-I3; Tue, 20 Oct 2026 09:39:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455224.1668828; Tue, 20 Oct 2026 09: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 1xJ6K1-0002PS-DM; Tue, 20 Oct 2026 09:39:53 +0000 Received: by outflank-mailman (input) for mailman id 1455224; Tue, 20 Oct 2026 09:39:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6K0-0002MN-9j for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:39:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6Jz-00228c-Ks for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:39:51 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad736de-2eae-0a2a0a5409dd-0a2a4503a702-30 for ; Tue, 20 Oct 2026 11:39:51 +0200 Received: from [52.101.69.140] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad736e7-fae8-0a2a45030019-3465458c04f3-3 for ; Tue, 20 Oct 2026 11:39:51 +0200 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by DU4PR03MB10766.eurprd03.prod.outlook.com (2603:10a6:10:590::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 09:39:43 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.21.0522.017; Tue, 20 Oct 2026 09:39: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=Mxz2MIm1Er+Fs26AWJheLEEoya9PYfzfBy2F+V777Hx3ecTZT8o6XCloklGHEUzrMRX2uzNcnTrDuCjbBkNeMYZXatRRWIpmoQ467eHYx8GCG/xB5FWFlxqf7z6Mqj5Q66yZcIwvcwVQx8ZWzD+bILzFP61PsY+qCl0leynhW4XVvMViCgV+kIMxxmX+c4HH8ytgOdScJ8sdX19XBhkzpDgTf2SGEA5idLE10HqB7NaLuc7e3s+AMUeiBziybsCqn4EsP1aFsoaQmfHjzGCrKyytu+YZ/VSOT9oy799y/iwThOBzzUELcxKRzLYKofRQrfT5zY8gsGpmtwCWCR48pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YMyhBAE/7rfHl01UzJ57fXgvKA/wY8oU49dZTVpWZpw=; b=KvjskuKIrxs30i+czbO9A8lqFsr8tlfQBnZc3QKwsFny903wm6+E+wJrse1Oej34LZqbQzu2k3P9w6CZ+i6PGSPFKVjcLCRW0VIevbwAHRZVL7EyUaumJ2Yef7af2W+lXLRhsaSSVRuSyrgLEaiZJWEUYBB2T+88Ce2NdTVh+QiEfaNg1DxalMhqcuixZq3aGgoRXrzjC63ti0YweHx0J9rwvgOE7t2xknwbU58muuVxbTbvsFuz4HtGE7rl2Nf8xDkx9p+MT7/45TNhFzbqcxxEhky1jKiOFP1Y1qM2pcWm+EIjbosUzAhOaM6TB0XrYX5UF8qcGSSf+O7NVLRnxQ== 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=YMyhBAE/7rfHl01UzJ57fXgvKA/wY8oU49dZTVpWZpw=; b=abg5CwKmUx2qA0/EbuhsbLnZQxypnPG1hz+uTTRbIrErquGknS7gtXGI8cg8CCd+Amw2a0Sx6/5SnYgd5PN45F5TWlg8wBwJgMCwEfMhBbUb+1CIZs3b2JnHhLfLNAZv6hc4ty5AgANvAwNVnOWUmFe7UBdxlBhFieiBtUaxuWTrddLzTIobdLx1GgwQ439who/aal19Q4wgLV79NUKVev/deqyV/oXY5mOnHmZ9MA13kTZidjSF9u2V9dw4z0+q/9rwtd6tXKRtkc4Dj2xTV3zMYlP8NS5XNOAlaiedw6e9ppaSHYN3nF5qHgOEMGMM1IM2XXdtD94Q8Zgoxd4iKw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini Subject: [PATCH v10 6/6] docs: Document CPU hotplug Thread-Topic: [PATCH v10 6/6] docs: Document CPU hotplug Thread-Index: AQHdYHbpsQDcThpgWEa/HAWZdfZsGw== Date: Tue, 20 Oct 2026 09:39:32 +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: 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: PAVPR03MB10102:EE_|DU4PR03MB10766:EE_ x-ms-office365-filtering-correlation-id: 9ee29877-8127-4bd1-5e55-08df2e8e10fa x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|38070700021|260925022911599003|56012099006|11063799006|260925021911599003|260925021311599003|261009223027099003|22082099003|18002099003|6133799003|10067099003; x-microsoft-antispam-message-info: Szsm+NoeyvwDp69VC4q4NDMFRva4WTY65Be4srsDYUqp/B/gl6MR1wQJjr37umAlYoCEJBPQ1uA4eVwmS5YNrbVwpDJhWmA0cEKG08RJc3IybLubq1WG2lw1jVoA+XMPoZquUn+DQXPdAgQ3h9BZ5u/IU+Q0WTouhJDWvL9VOIiYOs1lHNJDJvDH9Y4g+H2C6p1dK9ApvSq7sd/1MOdBrqo7EttugXFOVVAFNXbobqfuxPRkdiydFZdLggeQPfIi0tbPNS1uUVFOCUdHgOsfktePtDBEQ6LdKNzk5e/hKxJrmD2aEHXADZhGZF7g+LV8dLYliibthN2p0sI06Pi4hoEHk1+bw5vcn6zw6Lthjkm/KOlAH/Jqliid9HAAn5KzWDFIs5xkX7ZCWn9/Ybnmig4iU3j+e2gGiVyzGONa4m/u6DU9oswTFXm//MiJ0W2TdB/fUyo8LcVV9Ufb0WXPb4I6xQp5p8lj42+bTs4RD8uZL+a0x80pngEWmtTehb82KRVKEVWQ0RnKBlspzgE+FTVjIomO5B1ZrBVp1VqNjAIWxbg9ZQZ4n631gU95QpU2aouyyPOhTjtGXMK5xwdwEdPXfwxZXAfKSZG++7qYV569eH7mktntqDl4TTs6Z6MUrbnzAGS+J8jCTxPy6PflvcjmWY3ssxMQQBMhcRksIm9MNgfXtXNLVDZudOmH5EP2QeRN/Ft7kAeZIVLKEucUy2PRh86KmgQ0Gi1epPHBDgs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(38070700021)(260925022911599003)(56012099006)(11063799006)(260925021911599003)(260925021311599003)(261009223027099003)(22082099003)(18002099003)(6133799003)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?/w9xUSYCFWXrdD9XF3cHKORI2OqRc/WtcjdbDwiwwWHwzu4h41VrhizPH9?= =?iso-8859-1?Q?w6ufnVcXmLeEEVv6KGs6ros4tZguf8ElSTKkgkyr0QfbD158wA0janut10?= =?iso-8859-1?Q?bg1KGcfDfNk0FqA5gdcHSFnEsexHUlaZN9ys67kzM4Kjj2n/ofpeB2eCIf?= =?iso-8859-1?Q?5bng/NFwdIQZL3wr8qtmxFo87ix/eU1kg6XWSYZcAlLJt372ZEkJdEHH81?= =?iso-8859-1?Q?/7g+YJifdXq6YDlsKHrxcCQb5LJijcnOo/cfzfp3SgJhUb98lTApoDTSC6?= =?iso-8859-1?Q?OknBpvHVGsqoYRGJrxYOSV30xuoV3jHEoCpUpATxj/zeE/ivFWjjFT/6ak?= =?iso-8859-1?Q?To4fc6Vf5H3Pjw2VWV7TW4pevNaSeAhCCIxGtLGYqi57sXDlxKxI1dSxCa?= =?iso-8859-1?Q?mUWb+Xml4DadoRG6vbBi8D02eOHH4HI0emGd0DCL7pRkijGtTQWfDL6r7Y?= =?iso-8859-1?Q?Q0qKyg6oHx3/SBbkQ0oa+5+Wi0/a4aVPDVNQ3EazLsirrLt4obk91CssER?= =?iso-8859-1?Q?0LhVuZT9pN3s740bDssYV7ixuA1ZtF7vlm8y3Hsj7F3GKk7kz49eSy5xVT?= =?iso-8859-1?Q?JecdDKj/2QgMlDvXOjs39uX9rYvQcJ2RwXM0f/mfGFMv+v0TKvbMvjsbpR?= =?iso-8859-1?Q?bnOgt4OtT0Dq69KV7gNO9axG3VmhudEEOfPohBEWG34nlGOvyXw1uSLW3X?= =?iso-8859-1?Q?9GNB2zPInjAYFfzA3Z76ZuB2tAmU7GZW8m1T8dTR6TdobCoPX4vQzmtjW9?= =?iso-8859-1?Q?LCiCcXHXSckUyGtIpUy2L6WSxbjikqhgD+bGdJb83hP3t+KGlLnkJYCwUt?= =?iso-8859-1?Q?hds+etgRC1/AHK39IJ6I8EgJVJAYRh24FXNZlNkHLNKkBLWy1Z9+H7x/R+?= =?iso-8859-1?Q?7hylx1rCy20GQ/BOdvR9m5x6V6KU/Z+Dp92gZqyZ71jVCmaEKBWlSUpuRo?= =?iso-8859-1?Q?S5oyeHZlChA3HOYSkyshxX+lH3eCCy0Q3k3YtD563K0WNfnR5L8TUNj8Oc?= =?iso-8859-1?Q?/nCHFf/pOZ9nYEjmXdTaJi4wWfGKMnt7tx08cbds9OY7lYSFtcqzYqFVae?= =?iso-8859-1?Q?vxlBNNKkcYmv83HUrWqnwngDhnLdSLdCLY6Pd4aKrWvHQnwqc1nH/W+Rpf?= =?iso-8859-1?Q?Dxr9hl/kT+D/eEUrFCcuV/sjGFqxorJ4YvTQxx5R/5sAmqgLL2RrLPE03p?= =?iso-8859-1?Q?ln0GwIOQC0+WfixzfN/qTSLy4gMlMEInRRWm8rrHIivE38id3nU+Vbkllv?= =?iso-8859-1?Q?QuIg7Jj/GuTZZKrh3ROATX5f0J8oqB6D4jcK7G7dCkBQqTgaCp7nGmXxqk?= =?iso-8859-1?Q?q/FXApRNcIcDeqBdh26R/qcOayIm5ZisMznDz7+3QmyvJtintxZYzHA/N4?= =?iso-8859-1?Q?dxsHKun7Q0g9FabewgQ+Rz69uYGL5U5ojhbahiiE2wcI8eAT4M/GH5AfJg?= =?iso-8859-1?Q?Pu5rJ4mwEJjcP1AsamqSi+2XAKbEAMAliDVc+N/9o54IxbsZPrcGvLrwqM?= =?iso-8859-1?Q?rQjC3Osc7VFMnTUUEn2pDsPy2rg/j4t+oLo+UuN/CO7nsXZbnVK4Et4i/s?= =?iso-8859-1?Q?0gmwDm1JtRZUS1r1NGUCNq/zlRW7WBR96BFzfPhvMmLq6Vx/uLoTQC1VYd?= =?iso-8859-1?Q?FPyGjjU3xymVNV4bjhC0bftDrPCJq51hRsXIW+6AmU3MRVcAicNci2/1Rr?= =?iso-8859-1?Q?julb4I/IuxDntcuODXj2Sp8bdTzaecES+BR7mIDJxdmSr59Gnw/bSIJhwY?= =?iso-8859-1?Q?+wUtU5+DFere92/NHhCOhe4NoFiM1Nh3uRkLA+wIXMmEwm3lWzBXMFZKGw?= =?iso-8859-1?Q?9YOY64qo5Q=3D=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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ee29877-8127-4bd1-5e55-08df2e8e10fa X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2026 09:39:32.7083 (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: 03qFiOhjMEryhE1H+m94P7UpuxvbWfkvAuJsW5xCLa8xshjO67RULPvhbVQyW4GiLvvdGmDAza+4TG+9bJ/rIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10766 X-purgate-ID: tlsNG-33051d/1792489191-7428D4E9-EC501877/0/0 X-purgate-type: clean X-purgate-size: 4310 Signed-off-by: Mykyta Poturai --- v9->v10: * explain the actual ITS incompatibility * say FFA and TEE are incompatible, matching the Kconfig dependency v8->v9: * no changes 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 | 99 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 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..407f5e202d --- /dev/null +++ b/docs/misc/cpu-hotplug.txt @@ -0,0 +1,99 @@ +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 removed = from a +running system without requiring a reboot. It is implemented on x86 and Ar= m64 +architectures. + +Implementation Details +---------------------- + +CPU hotplug is implemented through the `XEN_SYSCTL_CPU_HOTPLUG_*` sysctl c= alls. +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 boot = 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, they = will +be automatically migrated to other online pCPUs. Interrupts used by guest +domains are handled by the scheduler when it reschedules the vCPUs to a ne= w, +online, pCPU. When a pCPU is being onlined, some Xen-bound interrupts will= get +redistributed to the newly onlined pCPU to prevent imbalance. + +If pCPU being offlined has some vCPUs pinned to it, they will be automatic= ally +unpinned and migrated to other online pCPUs. + +Limitations +----------- + +On Arm64 cpu hotplug is currently not compatible with the ITS: the per-CPU= LPI +pending table and GICR_CTLR.EnableLPIs are set up once at boot and are not +re-usable, so onlining a pCPU a second time fails. + +On Arm64 it is also not compatible with the FFA and TEE mediators, as both= use +non-static IRQ actions. + +Configuration +------------- + +The presence of the feature is controlled by CONFIG_CPU_ONLINE_OFFLINE opt= ion. +It is enabled by default on x86 architecture. On Arm64, the option is disa= bled +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 setups = 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 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:21:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:21:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455268.1668835 (Exim 4.92) (envelope-from ) id 1xJ6y2-0003V5-Nz; Tue, 20 Oct 2026 10:21:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455268.1668835; Tue, 20 Oct 2026 10: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 1xJ6y2-0003Uy-LD; Tue, 20 Oct 2026 10:21:14 +0000 Received: by outflank-mailman (input) for mailman id 1455268; Tue, 20 Oct 2026 10:21:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ6y1-0003Ua-8v for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:21:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ6y0-00HMKJ-EK for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:21:12 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7408f-bab6-0a2a0a5309dd-0a2a4506a076-18 for ; Tue, 20 Oct 2026 12:21:12 +0200 Received: from [52.101.46.13] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad74096-195a-0a2a45060019-34652e0d2322-3 for ; Tue, 20 Oct 2026 12:21:12 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SJ0PR03MB5790.namprd03.prod.outlook.com (2603:10b6:a03:2dd::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 10:21:07 +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.0546.012; Tue, 20 Oct 2026 10:21: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=Me+Tl8TrKE09Z4WE2ZvU0JRQp4lOiX5aNIjDPpVLr2p2ybvw2fg8RFOcbcJwNV2g5xyR6rBCwijwPSrwB1XgAYeIV/BMmaLjHFxsRJPqFYGrwKN9de2m1R1BCT+ZiE69HUegVzDItX+6D5I7KbZloMxqdkJpvRBhrzFMniyYesZY/iBwOv+o1z9vLm4d7C6Sw1RmfZil1PlcxkUg69GitYp2jQxwX5Wav2NTpZ/Hm4datXADTf61TuaHjME3ApOA3mmyhCsfszo44vsRrssJq7lwLFDoOXAPP1+/RpwIz5pmQxR4cn1Xz97FxiRZAT/zVcPvJmsY/WDK9rL52F+37w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sYcKJGPZCIg8wULZ9pRY79CuhpvGOhHYrTgiDjblkUk=; b=b5SmjiU2BXLGQJB33j0SeD+6mqg4oSI56WKqmdJN2Y+iWdQQD5dRvvgWAdu0HEVitYAjPHl3K6xhb61bVZTLATlxAuYbfjC2kC9wqpfGZPMC7wSdH8MyBpsqKRSpjWv3oFsmPzXFbM0KDXZIa1A/WijO+uk580NqdC927630VJAoC24Ge2PeWvAwuSXBpnpOyfqiEX+TxWF/MTOuBlnvJu0c/KV6/zwfaG5VnyVQbOe5YKwZ6+O5AimaK6uxfPX6N5YHAQ68O789B9tUwDiGHnX5rvzYuTOjgJMN+pPq9xxZFcmrRgZA1yyY1LgfTAUJWE98pMAyB+S8lGIjCV1ZvQ== 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=sYcKJGPZCIg8wULZ9pRY79CuhpvGOhHYrTgiDjblkUk=; b=jP/wW400+ZZVbsytZxwLG5I0xeiGPH8qAsxAnywYXGR/jI6XwZF63dUw0L/kBr+VIkenR20tBobmGoNY/UzjlNHL8yrjiBdX5OOfoXpJCTiMNvbyPtpW7btEzM2JPcPlyuJbGigwPsA38VJJgL+aAecjl+wzeGY3+sQIvjo9UY0= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <7757cb6d-78d2-4d73-bfee-f9d5db8f15a1@citrix.com> Date: Tue, 20 Oct 2026 11:21:03 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/np2m: flush the np2m on an SVM nested TLB flush To: Stephen Cheng , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <20261020093432.105318-1-stephen.cheng@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <20261020093432.105318-1-stephen.cheng@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0021.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::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_|SJ0PR03MB5790:EE_ X-MS-Office365-Filtering-Correlation-Id: 73dbbd47-9304-49f7-5630-08df2e93dac0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: j0ZjwZ9bi4kiO6iVWBpqUcrN9N4lbmF27UxGLdgiWEwarYtZ/6cTZeeg8LDFd+pUChWQxQI3ZmVduCaoCYZ2ZqiCvaSsdeFAP7qrrnN1QG4i64bICDtL5dwsyuivDgxT6F8lpXBH2Mo+b1yRbt86Y7JmfQCfRYQjZHod/CAV2VoZ3fuUaHxpTJUyYWKCW56UJqobH7vT5Ltb6X3LIlGcAMZgR4JvTV1D8YhRS484vFPwr5XtyxVrqmPi+i0qa6cCIc+q+Etd1CqkwQS5Nepa9N9rznBpuEiLMVTBtoVaJQ3IuGe4YC2Nf7Y7Ty56H9sEHd8ouVsDK2LoYK5Em4hHyVecflSVGaXZANz64bDCzhgXVcDiCqSHoo2q1+ZZYiEMGrsZFPO/1Znqnc8lYCQY2Bj0UQ7+s82xOPsJRbsg49yE+BjP1H+XC681Vo37rocHeRkGttBOHy1WIbt3iNymNrvMJqFffQTdDSijxEsl3Z8GbKLLzE3cCVOUvJ5/cuzma1IBl6oK6Rv+rpPyANCVK/9m2RfKqxeiHItOrw7IEQZ2OuPCTm16yyeFy+hjhFqX4EbugMYyn0uHTTlYpWsakBjxlSEmuR74qIB9W58Cclgrc9SgGJk/Ei3jaRybM7UE 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)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VS9pT2lmVkFDVHcxZFNoNkE1S3k0b08vaDhWbEg1UDdVVWRQR0VkWVZDeVZi?= =?utf-8?B?TmEwbnRTTHFxc28yQnBtTjZXcU00eUhpdkQxZGtXdURLbmV0QUJBdFIrL2hE?= =?utf-8?B?cW5BYzlEZGRuSTR5ODkwaXo3TWIrNWZTeDFINUF1OHU1ZXV3Y0VCazBVamZr?= =?utf-8?B?Q2l0dThUWVEvaTlCUVN5ZTV4dDFnbGJuODV5ZlZpSmpHWTYyZ1haM29wYjVE?= =?utf-8?B?MmtJeSs2eWsrSlFOdGFkY2lIUllWTlRwYmZ4WGFuV2Z4b21BeDh6cTM0OCt6?= =?utf-8?B?RGljMlVtTUxobFNmVGVCOFBNWWdMc2NzZ3poQU51aDVpY05qVzQ1ZTFzcXNE?= =?utf-8?B?QUJHZG9BUFlRaWhiczVUcGI2b2NVbzZ5Y2oybmZLbXdvVVo4dW5sVUUyd3Rr?= =?utf-8?B?UlNtdjBoeXZhb3NqR0ZZSTlzMmhibEFrUFJlWjdnd3gvZi8xd0pXeStzMDJV?= =?utf-8?B?Q2dNWnhKTktKdHdDa3dMV005ZmRpZGNtcjBPYVNRbFhqYXdJWjRWWjJOUnlk?= =?utf-8?B?UzdWM2FZd3VKdm42N2dMQmlvSC9zS0pMU0N2c1NjcXVtOTZOYVJVd2JEMzFZ?= =?utf-8?B?NGhEdzRYYWFIakE2ME5sUTdnSjl5V3Z6ZHZTQUQwL1ZYR2Nza281aUpwc2Q2?= =?utf-8?B?Mm9SNXh6ZlNFeEJDSEpRbjk0S0Fab2o4b1Vjc0xQTXZoZWJKWWZ5dGMzNmtM?= =?utf-8?B?STI2Z0liaXVQY3d4d2F3aDhUbm0xNTBJZmdKbHEyc0I0ZHhLWmxrNEhSbHBz?= =?utf-8?B?aDVjSno5OW9uOFlzS3MxNGtkTldkdXBYUEJ0a1l1Y2lVSzRuTWduRmswekkw?= =?utf-8?B?VXJ2U1B5ZytBUm1lRUNuSFZ6eGtlQ20wWEhOM08wcXc4VnhmWUl6Y2E5MmZi?= =?utf-8?B?eHlnTXNnZ252RVVWc1k2NkdETVYreE9MWXo2THU5QS80cTZhb25na0s2SHMw?= =?utf-8?B?NzlBOHhwSTBvdVhBb0h1Z0R2NktsdWZtSnJIZWVMVXdkWmRkQ0pGbnRFQno0?= =?utf-8?B?Yll0d1dSYXVaeWpwd0lHOGFpU1VyLzNaZE5mWk0zaUdzWGwrblkyVGF2K0c3?= =?utf-8?B?UTNGcFBCOWdTcHhIb0FaRWtqNkFnV2N4dXYvYzROZUliaUhHM3pkcFd0amlx?= =?utf-8?B?ZzIyN1FaNEJIQ2JSZHRUajJ1U1dUNmZJTEgzOG5xWEJ0VnNuTnEwRFNqRkdT?= =?utf-8?B?TzhjSE5JK0tkK25NTDZzc2dnWkxjWlpEUFRZNStpYjkxRGtTMHRlS05sVWJw?= =?utf-8?B?ZEdnVEVPWVRZMERmYm5uWG53S0d3dlk4c1c4Sm8xelFkNS9DaHlDTXM1N29P?= =?utf-8?B?TUwyVlZUcVNJWXVzUkRrUTZoaEJYZ1dZNW8zQlF0ZVBNRy9iT0lLWkFodU0x?= =?utf-8?B?WGlQeUZ0SVh3NUN4d2xjbm1FSTE0YzdqTEs4TTZETThDNVVLYk5DOFdTall1?= =?utf-8?B?QWU3a2JLblhBdzRQMXhUVmxUblZNQzdUUjU4UmVmYXpJV1pNV2VOa25KYkVp?= =?utf-8?B?cTJ0SUhpQ2VXMVJkT0ZCTzVJNU9kWkl5bG1XaGdKNzB6ckVFb1N6RHB1ZEg5?= =?utf-8?B?VXJwaVhmamFpdWZVVm5uRDQ1YTliNjd3VEtrYnZRbjcvTzI5WFpIZTkxbGR5?= =?utf-8?B?THkzYW5yMlFENWJaR3FZaDNtWGduN0dtbGU4WlRNQ3J3MEpLOGFtdThEOUhQ?= =?utf-8?B?OXBaYmtPZSt3OTJlU0xSODZBVWlER0h6WTdzTDRPU0dkckhpdDluN0ZsdG4v?= =?utf-8?B?VFRQdHhvb2JTZ0w5eXZYdXJpUWpIT28veEpqQ1FUSEFwa3RPVE5NM2hBNytU?= =?utf-8?B?aTFpaXUyN2VuSGxacnpSanAvU2FvYlVqMnJJbC81bjBIL2pQK1dXVFpkdytu?= =?utf-8?B?TFJaTjM1ckIvWEZvS0pRS0lNQVg3NlhRbkwzRExiTG5udFpTK3B4c1p3OFVl?= =?utf-8?B?KzU4ZjlwNFNqS0J4N2V1RjlGcFdlNEVycWdjOVhkNkpaUU4zbzNYRjFaMXhk?= =?utf-8?B?eXJKSXlDQ1dOQXE2Z295WFJ0b3FENHZzUHpXRnJwaWZtYlZVdjVDNEMrL1lk?= =?utf-8?B?TXk4Mm9KQkpkQlhpcFB5NGZEWkk5UXRxdVlHblFSVmRkTXZkaDRmNFBHdytS?= =?utf-8?B?Q3crZzY4SVZhcFN5ODFhaUNoRWthS0RVbi9UdEo0ajczTEVhUmNHandsdUw0?= =?utf-8?B?L05KaDhVSHV5K2FwZ09WUUttWlowZ20yMXdDTHovWDZEQ0hzQkRRdElyWDJk?= =?utf-8?B?UWh6LysxQXBWOTcrc2hHUWY3MVRFdUtKTGNUYk1MczFHZGp5TmZUbU45ZjBs?= =?utf-8?B?RzVNSm43TFBEdU9peTlxd1ZROTNDRkY2ZGhXdUgxaWRadS9hK2d1MDZZVXoy?= =?utf-8?Q?GHm+xwnHQJMW5B6Q=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73dbbd47-9304-49f7-5630-08df2e93dac0 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 10:21:07.6718 (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: ZnRKzn6nNstGgAhzHERyU0lYYuqdCACuAk0+9x5+0dfdEv6sQi4xQHDny10FWJB2OwcQbCnqFTLsSvWiBnzMBb8TQaZsRalwM4qofTbqD2U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5790 X-purgate-ID: tlsNG-16d1c6/1792491672-FE87577B-51A555DC/0/0 X-purgate-type: clean X-purgate-size: 2604 On 10/20/26 10:34 AM, Stephen Cheng wrote: > On SVM, L1 flushes what is cached from its nested page tables by setting > TLB_CONTROL or using a new ASID on VMRUN. Either sets nv_flushp2m, which > p2m_get_nestedp2m_locked() handles by only dropping nv_p2m. Since np2ms > are shared between vCPUs, the lookup then finds the np2m for the same > N_CR3 and reuses it as is, so L2 keeps the mappings from before L1 changed > its NPT. > > Flush that np2m before reusing it, as nested VMX does via > np2m_flush_base() on INVEPT. > > Fixes: 6df4b481b0c5 ("x86/np2m: implement sharing of np2m between vCPUs") > Signed-off-by: Stephen Cheng > Assisted-by: Claude:claude-opus-5-5 > --- > Ross Lagerwall has a partial fix for this in the XenServer internal patch > queue, which was also part of v1 of Chunjie Zhu's "x86/nestedsvm: rework > nested VMRUN/VMEXIT handling" series (patch 5/5, dropped in v2): > https://lore.kernel.org/xen-devel/20260924091605.344577-1-chunjie.zhu@citrix.com/ > > It flushes nv_p2m, the np2m this vCPU used last, before dropping it: > > if ( nv->nv_flushp2m && nv->nv_p2m ) > + { > + p2m = nv->nv_p2m; > + if ( p2m ) > + p2m_flush_table(p2m); > nv->nv_p2m = NULL; > + } > > That covers a vCPU re-entering the same N_CR3, but not one entering an > N_CR3 whose np2m another vCPU filled: on its first VMRUN (nv_p2m is NULL), > with an ASID new to it, or when switching N_CR3. This patch flushes the > np2m for the incoming N_CR3 instead, which covers all of these. I think this is useful information and should be in the commit message. > > Tested with an XTF test that is not yet upstream: L1 repoints an NPT > entry, then enters L2 on another vCPU or N_CR3 under a new ASID. L2 saw > the old frame before this patch and sees the new one with it. > > xen/arch/x86/mm/p2m.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > index 027b9ae69b..52cadd9b25 100644 > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -1547,7 +1547,11 @@ p2m_get_nestedp2m_locked(struct vcpu *v) > p2m_lock(p2m); > > if ( p2m->np2m_base == np2m_base ) > + { > + if ( nv->nv_flushp2m ) > + p2m_flush_table_locked(p2m); > goto found; > + } > > p2m_unlock(p2m); > } With the above commit message tweak, Reviewed-by: Ross Lagerwall From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:55:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:55:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455123.1668844 (Exim 4.92) (envelope-from ) id 1xJ7VD-0000f2-GT; Tue, 20 Oct 2026 10:55:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455123.1668844; Tue, 20 Oct 2026 10: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 1xJ7VD-0000ev-Dr; Tue, 20 Oct 2026 10:55:31 +0000 Received: by outflank-mailman (input) for mailman id 1455123; Tue, 20 Oct 2026 07:25:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ4Dq-00019w-G7 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 07:25:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ4Dp-005dCq-Py for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:25:21 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad71744-8faa-0a2a0a5109dd-0a2a450ce7d2-36 for ; Tue, 20 Oct 2026 09:25:17 +0200 Received: from [139.150.92.17] (helo=smtp92-17.hiworks.co.kr) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7175a-f479-0a2a450c0019-8b965c118726-3 for ; Tue, 20 Oct 2026 09:25:17 +0200 Received: from hi-smtp-node1 (unknown [172.18.0.2]) by smtp92-17.hiworks.co.kr (Postfix) with ESMTPS id 4j83pf1kcGzkVfg9 for ; Tue, 20 Oct 2026 16:25:14 +0900 (KST) Received: from hi-smtp-node1 (unknown [192.168.71.54]) by hi-smtp-node1 (Postfix) with ESMTP id 4j83pf1SpHzQLZQX for ; Tue, 20 Oct 2026 16:25:14 +0900 (KST) Received: from split.smtp.hiworks.com (amphora-3294b420-308a-4b9e-8a1d-bf25580dae1f.openstack.gabia.io) by hi-smtp-node1 with ESMTP id gq6wn6pwwkt77yb6; Tue, 20 Oct 2026 16:25:14 +0900 (KST) Received: from hiworks-k8s (EHLO mail-api-v2-prod-574865655-dnh9d) (10.251.81.192) by 0 (smtp-channel-split) with SMTP; Tue, 20 Oct 2026 16:25:13 +0900 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: Tue, 20 Oct 2026 16:25:13 +0900 (KST) From: =?UTF-8?B?7KCV7ISd7Jqp?= Reply-To: =?UTF-8?B?7KCV7ISd7Jqp?= To: xen-devel@lists.xenproject.org Message-ID: Subject: [RFC PATCH] xen/device-tree: Experimental support for TI K3 custom interrupt properties MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_108571_1738017415.1792481113640" X-Priority: 3 X-Authinfo: HIWORKS WEB authenticated X-purgate-ID: tlsNG-d25034/1792481117-51737A5B-CBB93FB4/0/0 X-purgate-type: clean X-purgate-size: 6102 ------=_Part_108571_1738017415.1792481113640 Content-Type: multipart/related; boundary="----=_Part_108572_802335075.1792481113640" ------=_Part_108572_802335075.1792481113640 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGVsbG8sCgpUaGlzIFJGQyBwYXRjaCBhZGRzIHN1cHBvcnQgZm9yIFRleGFzIEluc3RydW1lbnRz IChUSSkgSzMgY3VzdG9tIAppbnRlcnJ1cHQgcHJvcGVydGllcyAoJ3RpLGludGVycnVwdC1yYW5n ZXMnIGFuZCAndGksaW50ci10cmlnZ2VyLXR5cGUnKSAKaW4gWGVuJ3MgZGV2aWNlIHRyZWUgcGFy c2VyLgoKT24gVEkgSzMgcGxhdGZvcm1zLCBjZXJ0YWluIGRldmljZXMgdXNlIHRoZXNlIGN1c3Rv bSBwcm9wZXJ0aWVzIGluc3RlYWQgCm9mIHRoZSBzdGFuZGFyZCAnaW50ZXJydXB0cycgcHJvcGVy dHkgZHVlIHRvIHRoZSBUSS1TQ0kgaW50ZXJydXB0IHJvdXRlciAKYXJjaGl0ZWN0dXJlLiBDdXJy ZW50bHksIFhlbiBmYWlscyB0byBwYXJzZSB0aGVzZSBub2RlcywgcHJldmVudGluZyAKcHJvcGVy IGludGVycnVwdCBjb25maWd1cmF0aW9uIGZvciB0aG9zZSBkZXZpY2VzLgoKVG8gYWRkcmVzcyB0 aGlzLCB0aGUgYXR0YWNoZWQgZXhwZXJpbWVudGFsIHBhdGNoIGV4dGVuZHMgCmR0X251bWJlcl9v Zl9pcnEoKSBhbmQgZHRfZGV2aWNlX2dldF9yYXdfaXJxKCkgdG8gcGFyc2UgCid0aSxpbnRlcnJ1 cHQtcmFuZ2VzJyBhbmQgY2FsY3VsYXRlIHJhdyBJUlFzIGFjY29yZGluZ2x5LgoKSG93ZXZlciwg dGhpcyBpbXBsZW1lbnRhdGlvbiBoYXMgc2V2ZXJhbCBsaW1pdGF0aW9ucyBhbmQgaXMgZmFyIGZy b20gaWRlYWw6CjEuIFZlbmRvci1zcGVjaWZpYyBwcm9wZXJ0aWVzIGFyZSBoYXJkY29kZWQgaW50 byBYZW4ncyBjb21tb24gCiAgIGRldmljZSB0cmVlIHBhcnNlci4KMi4gTWFudWFsIGluZGV4IGNh bGN1bGF0aW9ucyBhbmQgbWFnaWMgbnVtYmVycyBhcmUgdXNlZCByYXRoZXIgdGhhbiAKICAgbGV2 ZXJhZ2luZyBhIHByb3BlciBhYnN0cmFjdGlvbiBsYXllci4KCldlIHdvdWxkIGdyZWF0bHkgYXBw cmVjaWF0ZSBjb21tdW5pdHkgZmVlZGJhY2sgb24gdGhlIGZvbGxvd2luZyBwb2ludHM6Ci0gSXMg dGhlcmUgYSBwcmVmZXJyZWQgd2F5IHRvIGhhbmRsZSB2ZW5kb3Itc3BlY2lmaWMgaW50ZXJydXB0 IAogIGJpbmRpbmdzIGxpa2UgdGhpcyB3aXRoaW4gWGVuJ3MgRFQgZnJhbWV3b3JrPwotIFdvdWxk IGl0IGJlIGJldHRlciB0byByZWZhY3RvciB0aGlzIGxvZ2ljIGludG8gYSBzZXBhcmF0ZSAKICBh cmNoaXRlY3R1cmUtc3BlY2lmaWMgb3IgY29udHJvbGxlci1zcGVjaWZpYyBsYXllciwgb3IgaXMg dGhlcmUgCiAgYW4gZXhpc3RpbmcgbWVjaGFuaXNtIHdlIG1pc3NlZD8KCkFueSBhZHZpY2UsIHN1 Z2dlc3Rpb25zLCBvciBhcmNoaXRlY3R1cmFsIGd1aWRhbmNlIGlzIHdlbGNvbWUuCgpCZXN0IHJl Z2FyZHMsCkplZAoKLS0tCiB4ZW4vY29tbW9uL2RldmljZS10cmVlL2RldmljZS10cmVlLmMgfCA2 NCArKysrKysrKysrKysrKysrKysrKysrKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwgNjAgaW5zZXJ0 aW9ucygrKSwgNCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL2RldmljZS10 cmVlL2RldmljZS10cmVlLmMgYi94ZW4vY29tbW9uL2RldmljZS10cmVlL2RldmljZS10cmVlLmMK aW5kZXggMGI1Mzc1ZjE1MS4uYTA4NGYwMzQ4NyAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9kZXZp Y2UtdHJlZS9kZXZpY2UtdHJlZS5jCisrKyBiL3hlbi9jb21tb24vZGV2aWNlLXRyZWUvZGV2aWNl LXRyZWUuYwpAQCAtMTEyMyw4ICsxMTIzLDIzIEBAIHVuc2lnbmVkIGludCBkdF9udW1iZXJfb2Zf aXJxKGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2aWNlKQogCiAgICAgLyogR2V0IHRo ZSBpbnRlcnJ1cHRzIHByb3BlcnR5ICovCiAgICAgaW50c3BlYyA9IGR0X2dldF9wcm9wZXJ0eShk ZXZpY2UsICJpbnRlcnJ1cHRzIiwgJmludGxlbik7Ci0gICAgaWYgKCBpbnRzcGVjID09IE5VTEwg KQotICAgICAgICByZXR1cm4gMDsKKyAgICBpZiAoIGludHNwZWMgPT0gTlVMTCApIHsKKyAgICAg ICAgaW50IGksIHJldGludG51bSA9IDA7CisgICAgICAgIGludHNwZWMgPSBkdF9nZXRfcHJvcGVy dHkoZGV2aWNlLCAidGksaW50ZXJydXB0LXJhbmdlcyIsICZpbnRsZW4pOworICAgICAgICBpZihp bnRzcGVjID09IE5VTEwpIHsKKyAgICAgICAgICAgIHJldHVybiAwOworICAgICAgICB9CisgICAg ICAgIGludGxlbiAvPSBzaXplb2YoKmludHNwZWMpOworICAgICAgICBkdF9kcHJpbnRrKCIgdXNp bmcgJ3RpLGludGVycnVwdC1yYW5nZXMnIHByb3BlcnR5XG4iKTsKKworICAgICAgICBmb3IoIGkg PSAyIDsgaSA8IGludGxlbjsgaSs9Myl7CisgICAgICAgICAgICByZXRpbnRudW0gKz0gYmUzMl90 b19jcHUoaW50c3BlY1tpXSk7CisgICAgICAgIH0KKyAgICAgICAgZHRfZHByaW50aygiIGludHNw ZWM9JWQgaW50bGVuPSVkXG4iLCBiZTMyX3RvX2NwdSgqaW50c3BlYyksIHJldGludG51bSk7CisK KyAgICAgICAgcmV0dXJuIHJldGludG51bTsKKyAgICB9CisKICAgICBpbnRsZW4gLz0gc2l6ZW9m KCppbnRzcGVjKTsKIAogICAgIGR0X2RwcmludGsoIiB1c2luZyAnaW50ZXJydXB0cycgcHJvcGVy dHlcbiIpOwpAQCAtMTU3OCw4ICsxNTkzLDQ5IEBAIGludCBkdF9kZXZpY2VfZ2V0X3Jhd19pcnEo Y29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpkZXZpY2UsCiAKICAgICAvKiBHZXQgdGhlIGlu dGVycnVwdHMgcHJvcGVydHkgKi8KICAgICBpbnRzcGVjID0gZHRfZ2V0X3Byb3BlcnR5KGRldmlj ZSwgImludGVycnVwdHMiLCAmaW50bGVuKTsKLSAgICBpZiAoIGludHNwZWMgPT0gTlVMTCApCi0g ICAgICAgIHJldHVybiAtRUlOVkFMOworICAgIGlmICggaW50c3BlYyA9PSBOVUxMICl7CisgICAg ICAgIGludCBpID0gMCwgbmV3aWR4ID0gMCwgY3VybWF4ID0gMCwgdHJpZ2dlcnR5cGUgPSA0Owor ICAgICAgICB1MzIgdHlwZWxlbjsKKworICAgICAgICBpbnRzcGVjID0gZHRfZ2V0X3Byb3BlcnR5 KGRldmljZSwgInRpLGludGVycnVwdC1yYW5nZXMiLCAmaW50bGVuKTsKKyAgICAgICAgaWYoaW50 c3BlYyA9PSBOVUxMKSB7CisgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsKKyAgICAgICAgfQor ICAgICAgICBpbnRsZW4gLz0gc2l6ZW9mKCppbnRzcGVjKTsKKyAgICAgICAgZHRfZHByaW50aygi IHVzaW5nICd0aSxpbnRlcnJ1cHQtcmFuZ2VzJyBwcm9wZXJ0eVxuIik7CisgICAgICAgIGR0X2Rw cmludGsoIiBpbnRzcGVjPSVkIGludGxlbj0lZFxuIiwgYmUzMl90b19jcHUoKmludHNwZWMpLCBp bnRsZW4pOworCisgICAgICAgIHAgPSBkdF9pcnFfZmluZF9wYXJlbnQoZGV2aWNlKTsKKyAgICAg ICAgaWYgKCBwID09IE5VTEwgKQorICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7CisKKyAgICAg ICAgaSA9IDA7CisgICAgICAgIG5ld2lkeCA9IGluZGV4OworICAgICAgICBjdXJtYXggPSBiZTMy X3RvX2NwdShpbnRzcGVjW2kgKyAyXSk7CisgICAgICAgIHdoaWxlKG5ld2lkeCA+PSBjdXJtYXgp eworICAgICAgICAgICAgbmV3aWR4IC09IGN1cm1heDsKKworICAgICAgICAgICAgaSArPSAzOwor ICAgICAgICAgICAgY3VybWF4ID0gYmUzMl90b19jcHUoaW50c3BlY1tpICsgMl0pOworICAgICAg ICB9CisKKyAgICAgICAgdG1wID0gZHRfZ2V0X3Byb3BlcnR5KGRldmljZSwgInRpLGludHItdHJp Z2dlci10eXBlIiwgJnR5cGVsZW4pOworICAgICAgICBpZih0bXAgIT0gTlVMTCkgeworICAgICAg ICAgICAgZHRfZHByaW50aygiIHVzaW5nICd0aSxpbnRyLXRyaWdnZXItdHlwZScgcHJvcGVydHlc biIpOworICAgICAgICAgICAgZHRfZHByaW50aygiIHRtcD0lZCB0eXBlbGVuPSVkXG4iLCBiZTMy X3RvX2NwdSgqdG1wKSwgdHlwZWxlbik7CisKKyAgICAgICAgICAgIHRyaWdnZXJ0eXBlID0gYmUz Ml90b19jcHUoKnRtcCk7CisgICAgICAgIH0KKworICAgICAgICBvdXRfaXJxLT5zcGVjaWZpZXJb MF0gPSAwOworICAgICAgICBvdXRfaXJxLT5zcGVjaWZpZXJbMV0gPSBiZTMyX3RvX2NwdShpbnRz cGVjW2kgKyAxXSkgKyBuZXdpZHggLSAzMjsKKyAgICAgICAgb3V0X2lycS0+c3BlY2lmaWVyWzJd ID0gdHJpZ2dlcnR5cGU7CisgICAgICAgIG91dF9pcnEtPnNpemUgPSAzOworICAgICAgICBvdXRf aXJxLT5jb250cm9sbGVyID0gcDsKKworICAgICAgICByZXR1cm4gMDsKKyAgICB9CisKICAgICBp bnRsZW4gLz0gc2l6ZW9mKCppbnRzcGVjKTsKIAogICAgIGR0X2RwcmludGsoIiB1c2luZyAnaW50 ZXJydXB0cycgcHJvcGVydHlcbiIpOwotLSAKMi40My4wCg== ------=_Part_108572_802335075.1792481113640-- ------=_Part_108571_1738017415.1792481113640-- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:55:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:55:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455126.1668854 (Exim 4.92) (envelope-from ) id 1xJ7VW-0000vY-PC; Tue, 20 Oct 2026 10:55:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455126.1668854; Tue, 20 Oct 2026 10: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 1xJ7VW-0000vP-LY; Tue, 20 Oct 2026 10:55:50 +0000 Received: by outflank-mailman (input) for mailman id 1455126; Tue, 20 Oct 2026 07:28:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ4Gl-0001KX-M4 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 07:28:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ4Gk-003d4d-VA for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 09:28:22 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad71813-2eae-0a2a0a5409dd-0a2a4505b8c0-32 for ; Tue, 20 Oct 2026 09:28:22 +0200 Received: from [79.135.106.120] (helo=mail-106120.protonmail.ch) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad71816-4cb1-0a2a45050019-4f876a78ad7d-3 for ; Tue, 20 Oct 2026 09:28: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=lrw5xn6zmrgwjg4x3oteet6dzm.protonmail2 header.d=proton.me header.i="@proton.me" header.h="Date:To:From:Subject:Message-ID:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=lrw5xn6zmrgwjg4x3oteet6dzm.protonmail2; t=1792481301; x=1792740501; bh=ma6dsYAeSOTRStqdIRsDBk+0FnUo+52hhwVoyi+LQ80=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=vQJay5x0a5nLQVuVxeaZVa8vIjOjYlPShyURML5WmMvkLArc/XvgVTxRF28f0H2m9 AU1xLf/CAO75GOzkcvj86lUav2STLilFsZRwMtGMwWG6w8o0AitfrKp0+eElAHVvXF SidbHNQgNDBwQWw11XW0MYGLVohkLkxrSGJRblJG99MIRpEAKExFwRtjGGgVUYw1D9 0W9/A5U9jydC4xqAF2sRQJ96fqG18WTbZCboDupNy0hwFya1PIVwo91W9lpLwdSvn4 BgeRfkhTpECKBJFXcS9UXs+mZN1cPUx9s/HKCdWYryZcPlFKiZkM0gbmOWhhjg3r3q LBSSqS/m2JFqQ== Date: Tue, 20 Oct 2026 07:28:17 +0000 To: evilbootloader@proton.me, xen-devel@lists.xenproject.org From: lluisbessasanz Subject: [PATCH] x86/altp2m: pause the vCPU before taking the altp2m list lock Message-ID: <20261020072806.465449-1-lluisbessasanz@proton.me> Feedback-ID: 116934124:user:proton X-Pm-Message-ID: 133332cbbfb1a3cd7404c8e14a6732b930984778 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1792481302-730B22A1-1A54319D/0/0 X-purgate-type: clean X-purgate-size: 6492 From: Llu=C3=ADs Bessa p2m_switch_vcpu_altp2m_by_id() takes the altp2m list lock and then updates the vCPU's EPTP. For a vCPU other than current, vmx_vcpu_update_eptp() -> vmx_vmcs_enter() pauses it and waits in vcpu_sleep_sync() until it is off its pCPU, with the lock still held. A vCPU on its way off its pCPU may need the p2m lock: context_switch() updates its runstate area, which for an area registered by guest virtual address (VCPUOP_register_runstate_memory_area, as Linux does) is a copy to guest memory and needs a p2m lookup. A vCPU handling a log-dirty write fault holds the host p2m lock in p2m_change_type_one() and waits for the altp2m list lock in p2m_altp2m_propagate_change(). That closes a cycle: dom0 vCPU, vm_event_resume() -> p2m_altp2m_check(): holds the altp2m list lock, waits for vCPU X to be descheduled vCPU X, context_switch() -> update_runstate_area(): waits for the host p2m lock vCPU Y, hvm_hap_nested_page_fault() -> p2m_change_type_one(): holds the host p2m lock, waits for the altp2m list lock A vm_event consumer switching views in its responses (VM_EVENT_FLAG_ALTERNATE_P2M) hits it with a Linux HVM guest while QEMU tracks dirty VRAM for a VNC client. The dom0 vCPUs involved spin in Xen and stop handling interrupts, and dom0 hangs. Pause the vCPU before taking the lock, like p2m_switch_domain_altp2m_by_id() does with domain_pause_except_self(). The pause in vmx_vmcs_enter() then finds the vCPU already descheduled. Only vm_event_resume() switches another vCPU's view, the other callers switch current and are unaffected. Signed-off-by: Llu=C3=ADs Bessa Co-Authored-By: Claude Opus 5.5 --- Notes: Seen on Xen 4.20.1 (debug=3Dn), Intel family 6 model 0xb7, PV dom0 (Lin= ux 6.8, 6 vCPUs pinned), Xen command line: dom0_mem=3D6144M,max:6144M dom0_max_vcpus=3D6 dom0_vcpus_pin=3D1 forc= e-ept=3D1 ept=3Dad=3D0 hap_1gb=3D0 hap_2mb=3D0 altp2m=3D1 hpet=3Dlegacy-replace= ment smt=3D0 sched=3Dcredit conring_size=3D4M Guest: HVM, hap=3D1, altp2m=3D2 (external), 3 vCPUs, 8 GiB, vga=3D"stdv= ga", vnc=3D1, QEMU 9.1.0. Ubuntu 22.04 with its stock 5.15 kernel, no driver= s installed. The trace of CPU12 below shows Xen copying the runstate into guest memory, so the guest kernel registered a runstate area by itself. =20 vm_event consumer: a multithreaded DRAKVUF build we are developing, which handles the vm_events of different vCPUs in parallel threads. It traces syscalls with altp2m breakpoints, every breakpoint response sets VM_EVENT_FLAG_ALTERNATE_P2M (fast single step). The same build with single-threaded event handling hangs as well, so one dom0 thread answering events is enough. Upstream DRAKVUF wasn't tested, it sends the same kind of responses. =20 With a VNC client attached and the guest screen changing, dom0 hangs within seconds in most runs, with multithreaded and single-threaded event handling: soft lockups in dom0, disk and network I/O stop. Not seen without a VNC client, nor with a Windows guest without Xen PV drivers. =20 Debug keys 'q' and 'd' during the hang (trimmed). d1 has pause_count=3D= 1 (QEMU in hap_track_dirty_vram()), but its vCPUs are still running: =20 VCPU0: CPU12 [has=3DT] pause_count=3D2 VCPU1: CPU14 [has=3DT] pause_count=3D0 VCPU2: CPU16 [has=3DT] pause_count=3D0 =20 CPU2 (d0v1, DRAKVUF answering a breakpoint; our build running with single-threaded event handling): vcpu_sleep_sync+0x32/0x60 vmx_vmcs_try_enter.part.0+0x3e/0xe0 vmx_vcpu_update_eptp+0x43/0xb0 p2m_switch_vcpu_altp2m_by_id+0x14a/0x1d0 vm_event_resume.part.0+0x245/0x270 evtchn_send+0x28a/0x2e0 do_event_channel_op+0x1cc/0x1130 =20 CPU12 (d1v0, being descheduled): queue_read_lock_slowpath+0x22/0x60 p2m_get_page_from_gfn+0x305/0x360 hvm_translate_get_page+0x19c/0x1e0 __hvm_copy+0xa9/0x460 copy_to_user_hvm+0x71/0x90 update_runstate_area+0x200/0x3a0 _update_runstate_area+0x9/0x40 context_switch+0x63/0x940 schedule+0x1c4/0x260 __do_softirq+0x59/0xa0 vmx_asm_do_vmentry+0x2b/0x30 =20 CPU14 (d1v1, log-dirty write fault on VRAM): _rspin_lock+0x42/0x60 p2m_altp2m_propagate_change+0x62/0x2d0 ept_set_entry+0x71c/0x7c0 p2m_set_entry+0x8e/0x150 p2m_change_type_one+0xb5/0x270 hvm_hap_nested_page_fault+0x3f6/0x6b0 vmx_vmexit_handler+0xe7f/0x17f0 =20 Also waiting: CPU8 (d0v4, QEMU) in vcpu_sleep_sync() from _domain_pause= () in hap_track_dirty_vram(), CPU16 (d1v2) for the p2m write lock in p2m_get_gfn_type_access(), CPU10 (d0v5, netback) for the p2m read lock = in gnttab_copy(). =20 Tested on 4.20.1 with this patch: 9 runs of 15 s with a VNC client attached, 3 with single-threaded and 6 with multithreaded event handling, 390k to 818k traced syscalls each, no hang. A run with a Windows guest works as before. Compile-tested on staging. xen/arch/x86/mm/altp2m.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c index 0bc9b9a..8c3450c 100644 --- a/xen/arch/x86/mm/altp2m.c +++ b/xen/arch/x86/mm/altp2m.c @@ -220,6 +220,17 @@ bool p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsi= gned int idx) if ( idx >=3D d->nr_altp2m ) return rc; =20 + /* + * Updating another vCPU's EPTP (vmx_vmcs_enter()) waits until that vC= PU + * is off its pCPU. Wait for it before taking the altp2m list lock: th= e + * vCPU may need the p2m lock to get off its pCPU (to update its runst= ate + * area in guest memory), while a vCPU handling a log-dirty fault hold= s the + * p2m lock and waits for the altp2m list lock in + * p2m_altp2m_propagate_change(). + */ + if ( v !=3D current ) + vcpu_pause(v); + altp2m_list_lock(d); =20 if ( d->arch.altp2m_eptp[idx] !=3D mfn_x(INVALID_MFN) ) @@ -230,6 +241,10 @@ bool p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsi= gned int idx) } =20 altp2m_list_unlock(d); + + if ( v !=3D current ) + vcpu_unpause(v); + return rc; } =20 --=20 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455280.1668862 (Exim 4.92) (envelope-from ) id 1xJ7Vq-0001LO-3D; Tue, 20 Oct 2026 10:56:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455280.1668862; Tue, 20 Oct 2026 10:56: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 1xJ7Vp-0001LG-WF; Tue, 20 Oct 2026 10:56:10 +0000 Received: by outflank-mailman (input) for mailman id 1455280; Tue, 20 Oct 2026 10:46:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7MF-0007FE-2e for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:46:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7ME-00CudL-B2 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:46:14 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74673-8faa-0a2a0a5109dd-0a2a450be3e4-14 for ; Tue, 20 Oct 2026 12:46:13 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad74674-b7e8-0a2a450b0019-aa0a817c4ee3-3 for ; Tue, 20 Oct 2026 12:46:13 +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-661-DKkuKb5XMHGYZ_bW7teTCg-1; Tue, 20 Oct 2026 10:46:08 +0000 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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 48DA71800BD0; Tue, 20 Oct 2026 10:46:01 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B0D3A1956089; Tue, 20 Oct 2026 10:45:51 +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=1792493172; 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=MptOf1hVsZ1OcnRpLWGVoNoF31BJAipRXCSmM3yzXJc=; b=evXG8karoU4jRnzSENT1qSvlVMMTbBIleKyqm4d7cJ25MCJZmT5puXE8iQHT3JrCtbrRLc HviFZNhcO9/iC8ZPsH5gwWIiUCCEIsIKmLxDIQHPIVaz25ZjeeGM/v3FdZuvDjLAGW4hVb pFUnpO0lYqrwOT86occK6OWDpq6j+WU= X-MC-Unique: DKkuKb5XMHGYZ_bW7teTCg-1 X-Mimecast-MFC-AGG-ID: DKkuKb5XMHGYZ_bW7teTCg_1792493164 From: marcandre.lureau@redhat.com Subject: [PATCH v7 00/65] Hi Date: Tue, 20 Oct 2026 14:45:17 +0400 Message-Id: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAAAAAAAC/yXMQQqAIBCF4avErBPMqKCrRAu1qSYoTSsC8e5ZL T/43wvg0RF6aLMADi/yZLaEJs9Az3KbkNGQDIKLuuCCs92sbJeWmEbUSgkpy2qElFuHI93fVdf /9qdaUB/vHmJ8AJZKl35sAAAA X-Change-ID: 20261020-qom-qapi-ceecbb2aa35f To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Stefan Berger X-Developer-Signature: v=1; a=openpgp-sha256; l=18033; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=YQH1wFu02Ce7UI3SJRB7LFwFPSLUsv52xFDWmiRbu9A=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZXhnO81OQ6oQCifSYiCo/KRE9qOY0nNm6UM YRzm0e0Z+eJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGVwAKCRDa6OEJdZac 5eu3EACgBRt96Jmd4w9dAGsxJWUgTeuIC9Q+Gu7gsqjyAwWPz6xsT83ATwr2NrI7URczXKUUzUH SbstTSknWKlqAwFuJjI4N6i+JRmDoxihzJQkOQZvOldkC7brA7szgus5eQ/zmOAg/rePS0H3ifD 4LAgZnm78mR03sDIgOV7HEPf00+9SlWVHwEQ8jkPET0AMorE0iYTfreMTCyOHojmshPxuvEhmzg mfmGIDTA5/DyeM9byxrom2suwhLB+x18H79b+CIfx9Wgvy/9lmjzGiMed8oLBSjlR6JV506TMh5 G09N/Qrf99ZBtIk7bSASRkT37x/Ey6efRDBuB9X9E9sr0T2CX+aJnKqpUT2eh2Cg70OnA4yV750 c7invSavJvaFnyk3srbbQltdVmoHGmNb8N1EY33+nCMnEQObkb7nNdtPNS7bZzVTQ79lTodfqm/ q+OnquwCSNX5O2YSDC0MaV10KSjVUkknfXcHdwlSmjl06/hB1pIDEo4rk8M/wriwL2oiI61pPxN wRijVyD+nW2B5H6F0qjcKswRZRke444dd1hSd/VRjCHO8KoZEUPqaxHoQZUnmcywR2RMQWAxgop 73X1MQY2XKu5YQomKMTluUEPoxA+JML0FtZUdnmOEaU2dSt1RK85qAk2HBA9VJpGrYX4adQ6sdT 275ub/bPzYg5t4Q== 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: t7HYCdvZlEemWRyuWTbpScHhM9PVK3n3toIxyOOx2Gg_1792493164 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493173-2C39B9EA-F49440E7/0/0 X-purgate-type: clean X-purgate-size: 18035 This series connects QOM and qdev properties to the QAPI type system, so that management tools can discover the QAPI schema type of each object property. Today, QOM properties carry a free-form "type" string ("bool", "uint32", "OnOffAuto", ..) that has no formal link to the QAPI schema exposed by query-qmp-schema. Management tools must maintain ad-hoc mappings or rely on naming conventions to figure out how to interpret property values. This series adds: - A new QAPITypeInfo struct that pairs a property with its QAPI schema type name, enum lookup table, and list-element type. - A QAPI code generator (qapi-type-infos) that emits a QAPITypeInfo instance for every schema-defined type, including the mapping between internal C names and the schema name visible to clients. - A "qapi-type" field in the ObjectPropertyInfo and ObjectPropertyValue QMP structs, populated from the QAPITypeInfo when present giving clients a cross-reference into query-qmp-schema output. - Conversion of all PropertyInfo definitions from the old .type/.enum_table strings to the new .qapi_type pointer. - Replacement of the generic qdev_prop_array with typed per-element array PropertyInfos, removing the arrayinfo/arrayfieldsize indirection from struct Property. - Removal of the deprecated PropertyInfo.type and .enum_table fields, and of the old object_property_add_enum/add_tm APIs. Along the way, a few pre-existing type mismatches in property definitions are fixed, the "struct tm" RTC property is replaced with a proper QAPI StructTm type etc. Introducing more specific types or a "typedef" to QAPI could help provide better associated type informations than plain "str" in many cases, for example. Changes in v7: - fixed a few more mis-typed list properties - use designated initializers for StructTm fields - assert enum get() returns >= or an error - a few commit message and code comment tweaks - rebased, add r-b trailers Changes in v6: - Rebase, resolve a few conflicts - Replace old PATCH 03-04 by new PATCH 01-06, adjust PATCH 09 [old PATCH 05] - Fix temporary build breakage: convert PCSouthBridgeOption only when it gets QAPIfied [PATCH 62], delay removal of old interface until after that [PATCH 63]. - Clean up checkpatch long line warnings, except leave the ones in PATCH 38 for later Changes in v5: - make "masked_name" mandatory, skip QType QAPITypeInfo generation - added/split "hw/ppc/spapr_caps: fix property type name" patch - added "qapi: select introspectable types directly", simplifying type discovery - fixed an include path - doc adjustments - rebased, collect r-b trailers - Link to v4: https://lore.kernel.org/qemu-devel/20260904-qom-qapi-v4-0-a985f168e938@redhat.com Changes in v4: - new patch "qom/qmp: populate description & default-value" - added gtk-doc comments for class_property_add_qapi*() - correct some property types to reflect the visitor - collected rb, rebased - Link to v3: https://lore.kernel.org/qemu-devel/20260818-qom-qapi-v3-0-24b8bbbe3d86@redhat.com Changes in v3: - QAPI analysis redesign (replacing the old "expose name map" from introspect) - all non-implicit QAPI types are now introspectable, including QOM-only types - QAPITypeInfo.schema_name -> masked_name - exposes integer signedness and width through query-qmp-schema - various extra property fixes - rebase, some patch split or merge - Link to v2: https://lore.kernel.org/qemu-devel/20260616-qom-qapi-v2-0-cc9396b9c18c@redhat.com Changes in v2: - Added kernel-doc documentation for the QAPITypeInfo struct fields. - Dropped "qom: drop free-form property typename registration", it's still needed for array of links to provide useful type names. - Added qdev_prop_link_list for array-of-links properties, with a create function that generates "linkList" type names matching the existing "link" convention. - qdev_prop_link now uses &str_type_info instead of "link" (the full "link" type name is set at property-add time) - Simplified DEFINE_PROP_LINK_ARRAY to use qdev_prop_link_list, dropping the now-unnecessary _arraytype parameter. - rebased - Link to v1: https://lore.kernel.org/qemu-devel/20260510-qom-qapi-v1-0-48ba6a1a1fa5@redhat.com Signed-off-by: Marc-André Lureau --- Marc-André Lureau (59): qapi: add QAPITypeInfo struct definition qapi/gen: fix _module_basename for multi-dash 'what' parameters qapi: add type-infos generator meson: add qapi-type-infos-*.c/h to build qom: add qapi_type field to ObjectProperty qapi/qom: add qapi-type field to ObjectPropertyInfo qom/qmp: populate qapi-type in QMP handlers qom/qmp: populate description & default-value in qom_property_info() qom: add object_property_set_default_enum() qom: add object_{class_}property_add_qapi qom: add object_{class_}property_add_qapi_enum tests: update check-qom-proplist for QAPI-aware property registration qom: convert QAPI enum properties to QAPI-aware registration qom: convert struct properties to QAPI-aware registration x86: convert OnOffAuto properties to QAPI-aware registration microvm: convert OnOffAuto properties to QAPI-aware registration pc: convert OnOffAuto vmport property to QAPI-aware registration arm/virt: convert OnOffAuto acpi property to QAPI-aware registration riscv/virt: convert OnOffAuto properties to QAPI-aware registration loongarch/virt: convert OnOffAuto properties to QAPI-aware registration hostmem-file: convert OnOffAuto rom property to QAPI-aware registration sev: convert OnOffAuto legacy-vm-type property to QAPI-aware registration whpx: convert OnOffAuto hyperv property to QAPI-aware registration whpx: convert OnOffAuto arch properties to QAPI-aware registration accel/kvm: convert OnOffSplit property to QAPI-aware registration whpx: convert OnOffSplit property to QAPI-aware registration hw/ppc/spapr_caps: fix property type name ppc/spapr-caps: convert to QAPI-aware property registration net/colo-compare: fix compare_timeout setter visitor type net/colo-compare: fix max_queue_size setter visitor type hw/misc/xlnx-versal-trng: add missing getter for fips-fault-events qom: convert scalar properties to QAPI-aware registration i386/cpu: convert strList property to QAPI-aware registration accel/hvf: convert OnOffSplit property to QAPI-aware registration i386/x86: convert SgxEPCList property to QAPI-aware registration virtio-balloon: convert guest-stats property to QAPI type qom: replace object_property_add_tm with StructTm QAPI type hw/nvdimm: convert UUID property to QAPI-aware registration hw/s390-virtio-ccw: convert loadparm property to QAPI-aware registration hw/ppc/spapr_drc: convert fdt property to QAPI-aware registration hw/s390x: convert BootCertificatesList to QAPI-aware registration hw/gpio/pca955x: use QAPI enums for led and pin properties include: add QEMU_REPEAT helper macro hw/gpio/pca955x: convert pin/led property to QAPI-aware enum hw/pci: change the busnr type to uint8 qdev: add qapi_type field to PropertyInfo with fallback registration qdev: convert core PropertyInfo definitions to use qapi_type qdev: adjust PciDevfn declared type qdev: convert system PropertyInfo definitions to use qapi_type hw: convert device-local PropertyInfo definitions to use qapi_type target/riscv: convert PropertyInfo definitions to use qapi_type qdev: convert PropertyInfo definitions to use qapi_type qdev: introduce typed array PropertyInfos qdev: simplify DEFINE_PROP_ARRAY and remove generic array PropertyInfo qdev: remove deprecated PropertyInfo.type and .enum_table fields hw/i386: convert PCSouthBridgeOption to QAPI enum qom: remove old enum property registration API qom: use QAPITypeInfo in object_property_get_enum tests/qmp-cmd-test: assert qapi-type resolves in query-qmp-schema Markus Armbruster (6): qapi/schema: Rename .lookup_entity() and tighten return type qapi: Ease access to introspection names qapi/introspect: Simplify masked name comment emission slighly qapi/introspect: Don't elide types qapi: QAPISchemaVisitor.visit_needed() is now unused, drop qapi/introspect: Tweak integer type masking accel/hvf/hvf-all.c | 29 ++-- accel/kvm/kvm-all.c | 31 ++-- accel/nitro/nitro-accel.c | 3 +- accel/tcg/tcg-all.c | 3 +- accel/whpx/whpx-common.c | 58 +++---- authz/list.c | 14 +- backends/cryptodev.c | 7 +- backends/hostmem-file.c | 33 ++-- backends/hostmem-memfd.c | 3 +- backends/hostmem.c | 20 +-- backends/spdm-socket.c | 4 +- backends/tpm/tpm_util.c | 3 +- block/throttle-groups.c | 10 +- chardev/char-socket.c | 3 +- crypto/secret_common.c | 12 +- crypto/secret_keyring.c | 9 +- crypto/tlscreds.c | 12 +- docs/devel/qapi-code-gen.rst | 92 ++++++++++- docs/interop/virtio-balloon-stats.rst | 22 +-- docs/sphinx/qapidoc.py | 2 +- event-loop-base.c | 7 +- hw/acpi/ich9.c | 1 + hw/acpi/pci.c | 7 +- hw/arm/virt.c | 31 ++-- hw/block/xen-block.c | 3 +- hw/core/clock.c | 3 +- hw/core/machine-qmp-cmds.c | 4 +- hw/core/machine.c | 13 +- hw/core/qdev-prop-internal.h | 23 +++ hw/core/qdev-properties-system.c | 97 ++++++------ hw/core/qdev-properties.c | 182 ++++++++++++++------- hw/cpu/core.c | 10 +- hw/cxl/cxl-host.c | 6 +- hw/display/apple-gfx-mmio.m | 2 +- hw/display/apple-gfx-pci.m | 2 +- hw/display/apple-gfx.h | 1 + hw/display/apple-gfx.m | 7 +- hw/gpio/aspeed_gpio.c | 5 +- hw/gpio/aspeed_sgpio.c | 3 +- hw/gpio/pca9552.c | 261 ++++++++++++------------------- hw/gpio/pca9554.c | 157 +++++++------------ hw/gpio/stm32l4x5_gpio.c | 5 +- hw/i386/microvm.c | 80 ++++------ hw/i386/pc.c | 32 ++-- hw/i386/pc_piix.c | 61 +++----- hw/i386/sgx-epc.c | 10 +- hw/i386/x86.c | 113 ++++++------- hw/ide/ide-dev.c | 3 +- hw/input/stellaris_gamepad.c | 2 +- hw/intc/apic_common.c | 3 +- hw/intc/arm_gicv3_common.c | 2 +- hw/intc/arm_gicv5_common.c | 4 +- hw/intc/rx_icu.c | 4 +- hw/loongarch/virt.c | 87 +++++------ hw/mem/nvdimm.c | 11 +- hw/mem/pc-dimm.c | 3 +- hw/microblaze/petalogix_s3adsp1800_mmu.c | 19 ++- hw/misc/arm_sysctl.c | 4 +- hw/misc/aspeed_lpc.c | 73 ++++++--- hw/misc/aspeed_sdmc.c | 3 +- hw/misc/mps2-scc.c | 2 +- hw/misc/npcm7xx_mft.c | 3 +- hw/misc/tz-ppc.c | 19 +-- hw/misc/xlnx-versal-trng.c | 15 +- hw/net/ne2000-isa.c | 3 +- hw/net/rocker/rocker.c | 2 +- hw/net/virtio-net.c | 2 +- hw/nvme/ctrl.c | 3 +- hw/nvme/nguid.c | 3 +- hw/nvram/xlnx-bbram.c | 3 +- hw/nvram/xlnx-efuse.c | 5 +- hw/nvram/xlnx-versal-efuse-ctrl.c | 2 +- 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/pci/pci.c | 3 +- hw/ppc/spapr_caps.c | 39 ++--- hw/ppc/spapr_drc.c | 5 +- hw/ppc/spapr_rtc.c | 24 ++- hw/remote/vfio-user-obj.c | 22 +-- hw/riscv/microchip_pfsoc.c | 3 +- hw/riscv/riscv_hart.c | 6 +- hw/riscv/virt.c | 52 +++--- hw/rtc/mc146818rtc.c | 22 ++- hw/s390x/ccw-device.c | 3 +- hw/s390x/css.c | 5 +- hw/s390x/s390-pci-bus.c | 3 +- hw/s390x/s390-virtio-ccw.c | 11 +- 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/vfio-user/pci.c | 5 +- hw/vfio/pci-quirks.c | 3 +- hw/virtio/virtio-balloon.c | 87 ++++------- hw/virtio/virtio-iommu-pci.c | 2 +- hw/virtio/virtio-mem-pci.c | 3 +- hw/virtio/virtio-mem.c | 18 ++- hw/xen/xen-pvh-common.c | 9 +- include/chardev/char.h | 8 - include/hw/block/block.h | 2 +- include/hw/core/qdev-properties-system.h | 2 + include/hw/core/qdev-properties.h | 40 +++-- include/hw/cxl/cxl_component.h | 5 +- include/hw/i386/pc.h | 4 +- include/qapi/qapi-type-info.h | 31 ++++ include/qemu/osdep.h | 33 ++++ include/qemu/uuid.h | 4 + include/qom/object.h | 186 +++++++++++++++------- iothread.c | 9 +- meson.build | 1 + migration/options.c | 4 +- monitor/qmp.c | 12 +- net/colo-compare.c | 15 +- net/dump.c | 6 +- net/filter-buffer.c | 3 +- net/filter.c | 10 +- qapi/common.json | 28 ++++ qapi/machine.json | 152 ++++++++++++++++++ qapi/meson.build | 4 + qapi/pragma.json | 1 + qapi/qom.json | 10 ++ qga/meson.build | 2 + qom/object.c | 237 +++++++++++++--------------- qom/qom-qmp-cmds.c | 47 +++--- scripts/qapi/backend.py | 2 + scripts/qapi/gen.py | 2 +- scripts/qapi/introspect.py | 74 +++------ scripts/qapi/schema.py | 57 +++++-- scripts/qapi/type_infos.py | 163 +++++++++++++++++++ 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 | 26 +-- target/i386/kvm/kvm.c | 38 +++-- target/i386/kvm/tdx.c | 4 +- target/i386/sev.c | 31 ++-- target/i386/whpx/whpx-all.c | 101 ++++-------- target/ppc/compat.c | 3 +- target/riscv/cpu.c | 47 +++--- target/riscv/kvm/kvm-cpu.c | 7 +- target/riscv/tcg/tcg-cpu.c | 13 +- target/s390x/cpu-system.c | 4 +- target/s390x/cpu_models.c | 5 +- target/sparc/cpu.c | 3 +- tests/include/meson.build | 2 + tests/meson.build | 6 + tests/qapi-schema/meson.build | 1 + tests/qtest/qmp-cmd-test.c | 55 ++++++- tests/unit/check-qom-proplist.c | 99 +++++++++--- tests/unit/test-qdev-global-props.c | 11 +- tests/unit/test-qdev.c | 2 +- ui/console-vc.c | 8 +- ui/console.c | 3 +- ui/dbus.c | 18 ++- ui/input-linux.c | 11 +- util/thread-context.c | 7 +- util/uuid.c | 5 + 170 files changed, 2317 insertions(+), 1628 deletions(-) --- base-commit: 8967b2fe1b2aaae3c29e207d85fab901d580a2dc change-id: 20261020-qom-qapi-ceecbb2aa35f Best regards, -- Marc-André Lureau From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455282.1668867 (Exim 4.92) (envelope-from ) id 1xJ7Vq-0001O6-Dn; Tue, 20 Oct 2026 10:56:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455282.1668867; Tue, 20 Oct 2026 10:56: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 1xJ7Vq-0001Mm-7M; Tue, 20 Oct 2026 10:56:10 +0000 Received: by outflank-mailman (input) for mailman id 1455282; Tue, 20 Oct 2026 10:46:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7MP-0007Fk-M1 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:46:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7MO-00CudL-Vr for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:46:25 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74668-8faa-0a2a0a5109dd-0a2a45039d92-48 for ; Tue, 20 Oct 2026 12:46:24 +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 6ad7467d-fae8-0a2a45030019-aa0a857cd20b-3 for ; Tue, 20 Oct 2026 12:46:22 +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-298-icWL8dY1Mw2Sv8wMuI-1iw-1; Tue, 20 Oct 2026 10:46:17 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EFCAE1955EA1; Tue, 20 Oct 2026 10:46:10 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B862C7D6; Tue, 20 Oct 2026 10:46: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=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=1792493181; 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=SL1ZQMFYVZqYTtNaimBSrRx03AL2YY9TcP8iYzzQRMU=; b=GoIOFSpMGUgIb+5RE1gq7qVkaoFM2udlkHQ4p1BfDua2UtQq22cDQJnBta8aRocX7Fq8dI O/mJAxMYzV7HSEsuzwWLPRggFGSscLplK2BC/5b2zktuGlTQYNABcKu5p/3LhWnIMXwPLJ Piiz3/37Rxk/AiLVYotflTe1GkiJcKg= X-MC-Unique: icWL8dY1Mw2Sv8wMuI-1iw-1 X-Mimecast-MFC-AGG-ID: icWL8dY1Mw2Sv8wMuI-1iw_1792493173 From: marcandre.lureau@redhat.com Date: Tue, 20 Oct 2026 14:45:18 +0400 Subject: [PATCH v7 01/65] qapi/schema: Rename .lookup_entity() and tighten return type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-1-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2295; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=NMq+Yt1ZfEaiiiNISBhSiNYen4lYgrhVdbLzdVLcgfY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZXTleuqEiJdOJBA42CH7+pe3OkqntERWYE8 KkGpCTR7GKJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGVwAKCRDa6OEJdZac 5eYXD/90lN2dF09F8Y8jULoa/Yv/HKP5x+nzYa1fz/PQiLU7rTNVeepj43nm7pjOPbzOWrqEQTu NGoiSEKMRcvP1/dL9lcMa2CMuoel6YAqIPu3c4B7fzk9RaLK8bST/AFHrsPamduiFcq5dCcGKaG ju0zoBbLNJoiwWpPC77UMf+Clab17oGrd3Z4UfxbvjwQFg/pdxCzvARoDcoMrPWROgcdkSOxy56 Z6gpyvJsS0JuLkUElGeGWPoEAgx1DSsdcQqYRRYzQ00USvXT8UPIPr1TxhQw1E5kvawYPNKsNKA 0ajGyDh/qGM8oz38HT0eipfUQxbk8tb7XPYDfOGFlTY+onpx7NVz31xrjXvctk3vjKZAkgcyqmg RB1fck+uzzyRqd14eL/FGI9vQkNgZQQPerW76Mv0nw/WnkXLfVaC2b632vq1GWpP0HYNbveno4Y RCPyzB+PhVOAVSC08/A9hkdBN+7OmaKswbhyW0DLGJhdtmeqMfxvW9buz3UlCDtJKSO63qUb2no tAMywgLV/anwoy+3qbtqNT4ZANXeoYjryX7nYBKXePcjhoApDzPCtpb9mbVcci4eJ+HXy1wiqY5 7Q/ftdsMrLQ6OjJ/QgY7rouCvnwhQKViJteuaYK5NDjHS3qbduGhwOfg4VUfD42iQhmNxKSpseU mBGYatJXPQ/kgYg== 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: 45G7gB1gHxDeotBxi67OEpXnN8hVmUENjXOZytJDf9I_1792493173 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1792493182-75A814E9-22980722/0/0 X-purgate-type: clean X-purgate-size: 2344 From: Markus Armbruster Commit 060b5a9323 (qapi: Dumb down QAPISchema.lookup_entity()) accidentally relaxed QAPISchema.lookup_entity()'s return type to QAPISchemaEntity. Tighten it back to QAPISchemaDefinition, and rename the method to .lookup_defn(). Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau --- docs/sphinx/qapidoc.py | 2 +- scripts/qapi/schema.py | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/sphinx/qapidoc.py b/docs/sphinx/qapidoc.py index 54a32e45f7ed..31d09ed6343e 100644 --- a/docs/sphinx/qapidoc.py +++ b/docs/sphinx/qapidoc.py @@ -512,7 +512,7 @@ def transmogrify(self, schema: QAPISchema) -> nodes.Element: modules.add(module_source) if doc.symbol: - ent = schema.lookup_entity(doc.symbol) + ent = schema.lookup_defn(doc.symbol) assert isinstance(ent, QAPISchemaDefinition) vis.visit_entity(ent) else: diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py index 8d88b40de2e1..9c9e257a8fd5 100644 --- a/scripts/qapi/schema.py +++ b/scripts/qapi/schema.py @@ -1184,11 +1184,11 @@ def _def_definition(self, defn: QAPISchemaDefinition) -> None: defn.info, "%s is already defined" % other_defn.describe()) self._entity_dict[defn.name] = defn - def lookup_entity(self, name: str) -> Optional[QAPISchemaEntity]: + def lookup_defn(self, name: str) -> Optional[QAPISchemaDefinition]: return self._entity_dict.get(name) def lookup_type(self, name: str) -> Optional[QAPISchemaType]: - typ = self.lookup_entity(name) + typ = self.lookup_defn(name) if isinstance(typ, QAPISchemaType): return typ return None @@ -1324,7 +1324,7 @@ def _make_implicit_object_type( return None # See also QAPISchemaObjectTypeMember.describe() name = 'q_obj_%s-%s' % (name, role) - typ = self.lookup_entity(name) + typ = self.lookup_defn(name) if typ: assert isinstance(typ, QAPISchemaObjectType) # The implicit object type has multiple users. This can -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455284.1668871 (Exim 4.92) (envelope-from ) id 1xJ7Vq-0001TB-OF; Tue, 20 Oct 2026 10:56:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455284.1668871; Tue, 20 Oct 2026 10:56: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 1xJ7Vq-0001Qz-HD; Tue, 20 Oct 2026 10:56:10 +0000 Received: by outflank-mailman (input) for mailman id 1455284; Tue, 20 Oct 2026 10:46:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7MT-0007Fw-HK for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:46:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7MS-002EHQ-U7 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:46:28 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74680-bab6-0a2a0a5309dd-0a2a4509d282-10 for ; Tue, 20 Oct 2026 12:46:28 +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 6ad74683-be1a-0a2a45090019-aa0a817c7905-3 for ; Tue, 20 Oct 2026 12:46:28 +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-349-AZuVlQ_mNCWlMBKmGs5kWg-1; Tue, 20 Oct 2026 10:46:23 +0000 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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 73F281800D85; Tue, 20 Oct 2026 10:46:18 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9D8411956088; Tue, 20 Oct 2026 10:46: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=1792493187; 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=Wrkputc8/RPpD4nnWHNw9T7RRAU4Kg2aM4nuyIGGs8E=; b=P2KwWbnS9ygGzQ/ZLqIaSEASARp1ANhH7OH8vh9SkqbCeKGzLAOjyDqcjuuzp56faazgvM eVmAUmPzTC4TVEhpvQOPAJ9X0YS6JelQZjBH9HP2Uas5A0/IsLtPfgKkGvQOsX/wNJ5DZv 4s4hwEOGelFhvZpAi4BkPo99bXszpBM= X-MC-Unique: AZuVlQ_mNCWlMBKmGs5kWg-1 X-Mimecast-MFC-AGG-ID: AZuVlQ_mNCWlMBKmGs5kWg_1792493179 From: marcandre.lureau@redhat.com Date: Tue, 20 Oct 2026 14:45:19 +0400 Subject: [PATCH v7 02/65] qapi: Ease access to introspection names MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-2-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=7889; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=a2pApAt20adFheRFMFL0JhfgD1DBySkAUQki6ne7iLY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZX47T8N7MhCWr0sH+GZry8k5SuXuUXyZs9e X4b68TesAyJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGVwAKCRDa6OEJdZac 5auAD/4/Ie/cSClFbfq3pLk5G4chwRGPx/IkNYssN2QhE7SuensGeO9N3hAkiwjTWMQUa4RmIV3 Ih/ody0cyQZ7ebEGwThhPd/0tDx7xTVJYKJlWKSTE5TWfQGUlgdud9VFnpmx8tSWLwXoFzA3/Hi z84mm5HxX4k1UOcwbKkeDY6EkPEVuH8/N0fn/A7MiLmcS+vrSdBq2tiEnHZ2QEopsTjy7Fg+8Dm trZ5cGqVMRvocoVM8CgiT6O62rCese/7CxN6AiIHPC523itkKI9FAhKp4RCjU92vE34Y4qb3OK7 4nLiR3tXfQKU/YeaXR1MILIVGMiK5nF1dai6meQh2g2gFR5CZaT6gar5YZXLqO6P5vbb/h9A5B1 XfERQ+8YYELHMZBHW9/k9O9lzRT4AaVsNM0NRp0v7q2tBK8LXDi/gCQ8p7fmH14kbbMpCNI05fK raCcLlKl6gYu52cO8zN9VqgDnMq9FRZW0+OUXJFULxZ30mbl8FV2VQh7yqS7Pjv7b0zNHWAunEZ wonP/p1G5r2Po5hwZOcexcv5WAK6BbCPlEQLoNz9USS4GnPaglfv0pEsF4RVBhsqmN/mm7S8mbt wlt5AqKpk3Y/XRH4EIFYc+5GuwKmie/wmHA0vfOmbqn2V9JRLHgrJL5pHEdbb6UDEt2kucPZXXU qlf+go84nzQ475Q== 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: 2-qu0rH9ZhSFifJT8_LtKB31j1Grb9Zhj9f_IyJFeUg_1792493179 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1792493188-BF0DD034-D54B9E37/0/0 X-purgate-type: clean X-purgate-size: 7938 From: Markus Armbruster query-qmp-schema masks type names, because they are not part of the external interface. Marc-André Lureau would like to also use them with qom-list & friends. Trouble is the masked names are buried deep in QAPISchemaGenIntrospectVisitor. Lift them into schema.py: new QAPISchemaDefinition method introspection_name() returns a definition's name for use in introspection. This changes the masked names, which is fine. Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau --- scripts/qapi/introspect.py | 23 ++++------------------- scripts/qapi/schema.py | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 19 deletions(-) diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py index 7e28de2279ad..644461560c64 100644 --- a/scripts/qapi/introspect.py +++ b/scripts/qapi/introspect.py @@ -30,7 +30,6 @@ QAPISchemaAlternatives, QAPISchemaArrayType, QAPISchemaBranches, - QAPISchemaBuiltinType, QAPISchemaEntity, QAPISchemaEnumMember, QAPISchemaFeature, @@ -177,7 +176,6 @@ def __init__(self, prefix: str, unmask: bool): self._schema: Optional[QAPISchema] = None self._trees: List[Annotated[SchemaInfo]] = [] self._used_types: List[QAPISchemaType] = [] - self._name_map: Dict[str, str] = {} self._genc.add(mcgen(''' #include "qemu/osdep.h" #include "%(prefix)sqapi-introspect.h" @@ -208,18 +206,14 @@ def visit_end(self) -> None: self._schema = None self._trees = [] self._used_types = [] - self._name_map = {} def visit_needed(self, entity: QAPISchemaEntity) -> bool: # Ignore types on first pass; visit_end() will pick up used types return not isinstance(entity, QAPISchemaType) def _name(self, name: str) -> str: - if self._unmask: - return name - if name not in self._name_map: - self._name_map[name] = '%d' % len(self._name_map) - return self._name_map[name] + assert self._schema + return self._schema.definition_introspection_name(name, self._unmask) def _use_type(self, typ: QAPISchemaType) -> str: assert self._schema is not None @@ -237,13 +231,6 @@ def _use_type(self, typ: QAPISchemaType) -> str: # Add type to work queue if new if typ not in self._used_types: self._used_types.append(typ) - # Clients should examine commands and events, not types. Hide - # type names as integers to reduce the temptation. Also, it - # saves a few characters on the wire. - if isinstance(typ, QAPISchemaBuiltinType): - return typ.name - if isinstance(typ, QAPISchemaArrayType): - return '[' + self._use_type(typ.element_type) + ']' return self._name(typ.name) @staticmethod @@ -271,8 +258,7 @@ def _gen_tree(self, name: str, mtype: str, obj: Dict[str, object], # Output a comment to make it easy to map masked names # back to the source when reading the generated output. comment = f'"{self._name(name)}" = {name}' - name = self._name(name) - obj['name'] = name + obj['name'] = self._name(name) obj['meta-type'] = mtype if features: obj['features'] = self._gen_features(features) @@ -327,8 +313,7 @@ def visit_array_type(self, name: str, info: Optional[QAPISourceInfo], ifcond: QAPISchemaIfCond, element_type: QAPISchemaType) -> None: element = self._use_type(element_type) - self._gen_tree('[' + element + ']', 'array', {'element-type': element}, - ifcond) + self._gen_tree(name, 'array', {'element-type': element}, ifcond) def visit_object_type_flat(self, name: str, info: Optional[QAPISourceInfo], ifcond: QAPISchemaIfCond, diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py index 9c9e257a8fd5..11f3accec873 100644 --- a/scripts/qapi/schema.py +++ b/scripts/qapi/schema.py @@ -136,6 +136,13 @@ def __repr__(self) -> str: def c_name(self) -> str: return c_name(self.name) + def set_ordinal(self, ordinal: int) -> None: + pass + + # pylint: disable=unused-argument + def introspection_name(self, unmask: bool) -> str: + return self.name + def check(self, schema: QAPISchema) -> None: assert not self._checked super().check(schema) @@ -323,6 +330,17 @@ def visit(self, visitor: QAPISchemaVisitor) -> None: class QAPISchemaType(QAPISchemaDefinition, ABC): + def __init__( + self, + name: str, + info: Optional[QAPISourceInfo], + doc: Optional[QAPIDoc], + ifcond: Optional[QAPISchemaIfCond] = None, + features: Optional[List[QAPISchemaFeature]] = None, + ): + super().__init__(name, info, doc, ifcond, features) + self._masked_name: Optional[str] = None + # Return the C type for common use. # For the types we commonly box, this is a pointer type. @abstractmethod @@ -363,6 +381,17 @@ def need_has_if_optional(self) -> bool: # Except for arrays; see QAPISchemaArrayType.need_has_if_optional(). return not self.c_type().endswith(POINTER_SUFFIX) + def set_ordinal(self, ordinal: int) -> None: + assert not self._masked_name + self._masked_name = str(ordinal) + + def introspection_name(self, unmask: bool) -> str: + # Type names are not part of the external interface. Hide + # them in introspection. Also saves a few characters on the + # wire. + assert self._masked_name + return self.name if unmask else self._masked_name + def check(self, schema: QAPISchema) -> None: super().check(schema) for feat in self.features: @@ -402,6 +431,11 @@ def json_type(self) -> str: def doc_type(self) -> str: return self.json_type() + def introspection_name(self, unmask: bool): + if self.json_type() == 'int': + return 'int' + return self.name + def visit(self, visitor: QAPISchemaVisitor) -> None: super().visit(visitor) visitor.visit_builtin_type(self.name, self.info, self.json_type()) @@ -503,6 +537,9 @@ def doc_type(self) -> Optional[str]: return None return 'array of ' + elt_doc_type + def introspection_name(self, unmask: bool): + return '[' + self.element_type.introspection_name(unmask) + ']' + def visit(self, visitor: QAPISchemaVisitor) -> None: super().visit(visitor) visitor.visit_array_type(self.name, self.info, self.ifcond, @@ -1182,6 +1219,7 @@ def _def_definition(self, defn: QAPISchemaDefinition) -> None: "'%s' is already defined\n%s" % (defn.name, where)) raise QAPISemError( defn.info, "%s is already defined" % other_defn.describe()) + defn.set_ordinal(len(self._entity_dict)) self._entity_dict[defn.name] = defn def lookup_defn(self, name: str) -> Optional[QAPISchemaDefinition]: @@ -1208,6 +1246,11 @@ def resolve_type( info, "%s uses unknown type '%s'" % (what, name)) return typ + def definition_introspection_name(self, name: str, unmask: bool) -> str: + defn = self.lookup_defn(name) + assert defn + return defn.introspection_name(unmask) + def _module_name(self, fname: str) -> str: if QAPISchemaModule.is_system_module(fname): return fname -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455286.1668879 (Exim 4.92) (envelope-from ) id 1xJ7Vr-0001W7-6x; Tue, 20 Oct 2026 10:56:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455286.1668879; Tue, 20 Oct 2026 10:56: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 1xJ7Vq-0001Uv-SB; Tue, 20 Oct 2026 10:56:10 +0000 Received: by outflank-mailman (input) for mailman id 1455286; Tue, 20 Oct 2026 10:46:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Mb-0007Gn-BH for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:46:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Ma-00CukM-OX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:46:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74680-8faa-0a2a0a5109dd-0a2a4505e44a-18 for ; Tue, 20 Oct 2026 12:46:36 +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 6ad7468b-4cb1-0a2a45050019-aa0a857ca199-3 for ; Tue, 20 Oct 2026 12:46:36 +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-266-qJjFWL2MMmO8dr1kA-VMhA-1; Tue, 20 Oct 2026 10:46:31 +0000 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9A622180133B; Tue, 20 Oct 2026 10:46:26 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 20B851800643; Tue, 20 Oct 2026 10:46: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=1792493195; 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=Q7myRjnvJN1zs4/WFeao6QDd+ittV+0+bFc6WNm3+3s=; b=d1t+v8tt33knoKaG8jHk/PYClQCNXXITRyYcyO35zumS0xaEug85CT1UctY0/Oiridg6aO pBeHPSZ3cX4e4aTDD8u727Aclf/ISekS2E2sWkIY11/1MMEOCFenh1l923R+BafUwg/nx3 eiKc+vp5fXOU71hkAOrYCVyN9Kj24XU= X-MC-Unique: qJjFWL2MMmO8dr1kA-VMhA-1 X-Mimecast-MFC-AGG-ID: qJjFWL2MMmO8dr1kA-VMhA_1792493187 From: marcandre.lureau@redhat.com Date: Tue, 20 Oct 2026 14:45:20 +0400 Subject: [PATCH v7 03/65] qapi/introspect: Simplify masked name comment emission slighly MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-3-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1620; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=VT5u6B1qUaxaf9+tLnGedzovD3GH8labF6VNv1guiyM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZXLImEUkMO1oHPQ87OflvNF4Yi2udXpYkVC bgHxuhfWBSJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGVwAKCRDa6OEJdZac 5apPEACW7/JRacnRcMdLuR2wffTHpKlhTnnNttkfa+uxqEFGpUBAVm+QmXcBWiHQepjJYrrnCLX kX+DqErqWmeiNvxzI6JiXnzTLZT+qJhJv8xsO/VJJDrfMn1ueuWzUrj+B6OuHiY8G6sKD5B22r2 /VsVx5S39hkt2iAucJYFWX/jCbXr/n7JLfXZhIxEj5BOvCvg5Yi0LL2TqlYsbb8popca2rYP1LR NPoU4LRf51hxD2ywaO+6y/j0N21xE0p2YkndRii6LnkybRIxrfS/5bnqGpLfMNBLgkT78iIM8lt NrBUIcQuB2ZB1X0yNDB2FHzKruZggB1WNpUshItWpvIpDoPoGH3skEwfR/V5fD0qfS/LZSqqyjB 4FJtdTuRRF4YsaCbLtQNFS8/+QQV4/Vdi5fyBJBJkUomWmIJ9Gmo13qCN7QZ48ATUiFB5yMjLX9 bstCXnov+XHxOtODxHO4PES/1tyzo8hAqxMSO7jC3lVaeZiXCYHaNmzZGZmg8rw+ACTin7LuEQX oFXd4FeQcXIRzEKbNbs3ma5jEAL5lKpL5YEur2r2ksx/zaX4Ck+aLw4T4c9LwKnL2l82ALZeysf UF3MM5kuOAz2l1KljOxTX1ENX/TZBM0eH+aQiWoC7ma7Ez/O5zz63gJTXWajtX6GQgtJcz+zO1R w+mtvxa/th+1OpQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: QRNlgcLSWBwlTWweTePpD6PTYbWtzhRxfevEUnCAFHQ_1792493187 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792493196-F4EA12A1-E63C5A86/0/0 X-purgate-type: clean X-purgate-size: 1669 From: Markus Armbruster Instead of emitting the comment for certain meta-types, simply emit it when introspection name and name differ. This additionally emits it for arrays, which is fine. Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau --- scripts/qapi/introspect.py | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py index 644461560c64..49d1ed2897e8 100644 --- a/scripts/qapi/introspect.py +++ b/scripts/qapi/introspect.py @@ -253,12 +253,12 @@ def _gen_tree(self, name: str, mtype: str, obj: Dict[str, object], Will be omitted from the output if empty. """ comment: Optional[str] = None - if mtype not in ('command', 'event', 'builtin', 'array'): - if not self._unmask: - # Output a comment to make it easy to map masked names - # back to the source when reading the generated output. - comment = f'"{self._name(name)}" = {name}' - obj['name'] = self._name(name) + introspection_name = self._name(name) + if introspection_name != name: + # Output a comment to make it easy to map masked names + # back to the source when reading the generated output. + comment = f'"{introspection_name}" = {name}' + obj['name'] = introspection_name obj['meta-type'] = mtype if features: obj['features'] = self._gen_features(features) -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455288.1668882 (Exim 4.92) (envelope-from ) id 1xJ7Vr-0001ai-EB; Tue, 20 Oct 2026 10:56:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455288.1668882; Tue, 20 Oct 2026 10:56: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 1xJ7Vr-0001YM-6A; Tue, 20 Oct 2026 10:56:11 +0000 Received: by outflank-mailman (input) for mailman id 1455288; Tue, 20 Oct 2026 10:46:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Mi-0007HN-CJ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:46:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Mh-002ESM-Oo for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:46:43 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74680-bab6-0a2a0a5309dd-0a2a4509d282-44 for ; Tue, 20 Oct 2026 12:46:43 +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 6ad74692-be1a-0a2a45090019-aa0a857c4f3b-3 for ; Tue, 20 Oct 2026 12:46:43 +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-300-zY61osTGPTaA1pnSKnNHFQ-1; Tue, 20 Oct 2026 10:46:38 +0000 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 5CC261955D69; Tue, 20 Oct 2026 10:46:33 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 14CBF30000E7; Tue, 20 Oct 2026 10:46: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=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=1792493202; 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=W4iwz5jM7eZNLXaBc15ajfHMaIvbcteyV5+hzYG/iP8=; b=RYpTwtrgQV9LDr6PPPWCGIvUefmfFMfa4QnuHfFNKR6T1J7fKes+R3z0I8KtXFn2z8ykPI TZ7/jE9z0T4CMAosoU0dpsH8Uv9STFnF7A4I68YlGjP78SI/xiEZaifjpFv1LL4NUWuaQ4 F93txUTVYjzk5Hi8WiKhD6jhIZqNuKo= X-MC-Unique: zY61osTGPTaA1pnSKnNHFQ-1 X-Mimecast-MFC-AGG-ID: zY61osTGPTaA1pnSKnNHFQ_1792493194 From: marcandre.lureau@redhat.com Date: Tue, 20 Oct 2026 14:45:21 +0400 Subject: [PATCH v7 04/65] qapi/introspect: Don't elide types MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-4-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=5331; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=mh48JZUSGfIpAp1DsQ/GZxfBrxYDTkjYALDPFWkE2w0=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZXTj6BLvZgq0XBaDnDR415+cGHcMUxi/2dk ZicZ3/0CO+JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGVwAKCRDa6OEJdZac 5cNFEACs0g3nYzOw9mcOrDPnlJXKJuNeci0n6VbAEXZsFCZ1u4JNtS1ifs+0pHvISJaoZta0my6 lvkGupWdwq079dv7nvmOoT5lGQxsx41FDbzeMAh2AqGRiaoTGIR34hQFf3sOLgmZraxp30Lt33v I9FftBFuBgNH1cHh44kywesPPVrmlfX1fGV1hURBsBolTEkpUT+VNW3Si1XrztZk2PXf1zupIB1 6v4kYskKQkdj6v95qbfwBDHaMsgyUWRuc4dE9BsDkCCULJcdcOw0jQy+xkShVjgbTzRG/spQtdm OJgHTTwkqlLpLSzKkiZiWk130rNvNbU9ZPZZ7pWrSjD87w4sUoVTVlLNx7btfbj6VpkVI/lsNHX eXEv52qGqAcZCZptkK8oP/CIE6nCQvMdxcZ31fqe3HxosbVA5tVjhnoeC/tQyiJZuiyExxkFiJ7 0ZbpjT/AIjGFffTJ3IYXzUgPfgdB1arCF3YD86a2cQEZgHpGQtJ675JNQAPfC7Gbgpu/znK2Txl QskafbOYE8+L5oukgyV+eYRWnqzZsRIXJeUrRhCXcOW2+NOIDZyh5yfQvEaIefITC4ILWuwtEEF F1kFYI7xr5ozlv5mmkOq6tEUPt+N9cLcy/vZVW0O4PEQCCt0FJuN5TvgfUPN9YjLObVm6vjQw9L JjRCn7EZx7/9Trw== 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: cP31hDvhxy1B8F7cAdgBeAt6ETRKpUplzKQZrcplQQs_1792493194 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1792493203-39EC6034-30D853B4/0/0 X-purgate-type: clean X-purgate-size: 5380 From: Markus Armbruster query-qmp-schema elides types not reachable from commands and events. It currently emits 1251 out of 1385 definitions, and elides 134 types. Whether that's worthwhile is debatable. Marc-André Lureau would like to make QOM introspection (qom-list & friends) refer to QAPI types. We additionally need types reachable from QOM properties. Unfortunately, the QAPI generator knows nothing about QOM properties. We could manually mark the QAPI types to elide, or the QAPI types not to elide even though they are not reachable from commands and events. Feels very much not worthwhile to me. We could conservatively approximate "reachable from QOM properties" by "available for use with QOM properties". These are the built-in and user-defined types, and their arrays. With that, we'd elide just 38 out of 1385 definitions. Too few to be worthwhile. Simply emit everything. Output of query-qmp-schema grows from 247KiB to 274KiB for me. Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau --- docs/devel/qapi-code-gen.rst | 2 -- scripts/qapi/introspect.py | 31 ++++--------------------------- 2 files changed, 4 insertions(+), 29 deletions(-) diff --git a/docs/devel/qapi-code-gen.rst b/docs/devel/qapi-code-gen.rst index b1cc5b5f0db1..77f08bb68cac 100644 --- a/docs/devel/qapi-code-gen.rst +++ b/docs/devel/qapi-code-gen.rst @@ -1250,8 +1250,6 @@ JSON array of strings. To examine a type, start with a command or event using it, then follow references by name. -QAPI schema definitions not reachable that way are omitted. - The SchemaInfo for a command has meta-type "command", and variant members "arg-type", "ret-type" and "allow-oob". On the wire, the "arguments" member of a client's "execute" command must conform to the diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py index 49d1ed2897e8..15302ecf155a 100644 --- a/scripts/qapi/introspect.py +++ b/scripts/qapi/introspect.py @@ -28,9 +28,7 @@ from .schema import ( QAPISchema, QAPISchemaAlternatives, - QAPISchemaArrayType, QAPISchemaBranches, - QAPISchemaEntity, QAPISchemaEnumMember, QAPISchemaFeature, QAPISchemaIfCond, @@ -175,7 +173,6 @@ def __init__(self, prefix: str, unmask: bool): self._unmask = unmask self._schema: Optional[QAPISchema] = None self._trees: List[Annotated[SchemaInfo]] = [] - self._used_types: List[QAPISchemaType] = [] self._genc.add(mcgen(''' #include "qemu/osdep.h" #include "%(prefix)sqapi-introspect.h" @@ -187,10 +184,6 @@ def visit_begin(self, schema: QAPISchema) -> None: self._schema = schema def visit_end(self) -> None: - # visit the types that are actually used - for typ in self._used_types: - typ.visit(self) - # generate C name = c_name(self._prefix, protect=False) + 'qmp_schema_qlit' self._genh.add(mcgen(''' #include "qobject/qlit.h" @@ -205,32 +198,12 @@ def visit_end(self) -> None: c_string=_tree_to_qlit(self._trees))) self._schema = None self._trees = [] - self._used_types = [] - - def visit_needed(self, entity: QAPISchemaEntity) -> bool: - # Ignore types on first pass; visit_end() will pick up used types - return not isinstance(entity, QAPISchemaType) def _name(self, name: str) -> str: assert self._schema return self._schema.definition_introspection_name(name, self._unmask) def _use_type(self, typ: QAPISchemaType) -> str: - assert self._schema is not None - - # Map the various integer types to plain int - if typ.json_type() == 'int': - type_int = self._schema.lookup_type('int') - assert type_int - typ = type_int - elif (isinstance(typ, QAPISchemaArrayType) and - typ.element_type.json_type() == 'int'): - type_intlist = self._schema.lookup_type('intList') - assert type_intlist - typ = type_intlist - # Add type to work queue if new - if typ not in self._used_types: - self._used_types.append(typ) return self._name(typ.name) @staticmethod @@ -295,6 +268,8 @@ def _gen_variant(self, variant: QAPISchemaVariant def visit_builtin_type(self, name: str, info: Optional[QAPISourceInfo], json_type: str) -> None: + if json_type == 'int' and name != 'int': + return self._gen_tree(name, 'builtin', {'json-type': json_type}) def visit_enum_type(self, name: str, info: Optional[QAPISourceInfo], @@ -312,6 +287,8 @@ def visit_enum_type(self, name: str, info: Optional[QAPISourceInfo], def visit_array_type(self, name: str, info: Optional[QAPISourceInfo], ifcond: QAPISchemaIfCond, element_type: QAPISchemaType) -> None: + if element_type.json_type() == 'int' and name != 'intList': + return element = self._use_type(element_type) self._gen_tree(name, 'array', {'element-type': element}, ifcond) -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455290.1668891 (Exim 4.92) (envelope-from ) id 1xJ7Vs-0001kc-3x; Tue, 20 Oct 2026 10:56:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455290.1668891; Tue, 20 Oct 2026 10:56: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 1xJ7Vr-0001i6-Lu; Tue, 20 Oct 2026 10:56:11 +0000 Received: by outflank-mailman (input) for mailman id 1455290; Tue, 20 Oct 2026 10:46:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Mp-0007Ht-9o for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:46:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Mo-002ESM-Ml for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:46:50 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7469a-bab6-0a2a0a5309dd-0a2a4502898a-0 for ; Tue, 20 Oct 2026 12:46:50 +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 6ad74699-6ca4-0a2a45020019-aa0a817c7251-3 for ; Tue, 20 Oct 2026 12:46:50 +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-681-dv92ItMdM9G_nQvMyXZAiA-1; Tue, 20 Oct 2026 10:46:44 +0000 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0CCE818005B9; Tue, 20 Oct 2026 10:46:40 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 26AF11800643; Tue, 20 Oct 2026 10:46: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=1792493209; 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=xG2OGo4lx2YCSH10YJfMac8tHdMtlMp6mBUYGSWviZ4=; b=Wi/LmWHgVQr37I7HM3dRB37hrGFBOQn+POAjUGkCspzb/xs7B/45HyRdqnnjjAqGsoculR Fm0PDKk0n7c/JKrKi9uVpx6BgkLIqXQ90msn/Cyu4HP2SsrypUrJhjFP4XISBKYm9L7B+z ErL74X8unniWmR4TO8fyEFMpBsEj8f8= X-MC-Unique: dv92ItMdM9G_nQvMyXZAiA-1 X-Mimecast-MFC-AGG-ID: dv92ItMdM9G_nQvMyXZAiA_1792493201 From: marcandre.lureau@redhat.com Date: Tue, 20 Oct 2026 14:45:22 +0400 Subject: [PATCH v7 05/65] qapi: QAPISchemaVisitor.visit_needed() is now unused, drop MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-5-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1193; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=yBAs+PsGI+mRRHuSXNI42xoWI9p0TSDsh65vQW8BRrc=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZX3wnVoTG1DT7PkibN0fixZC+3g4HczKxre WlR6XwfjdSJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGVwAKCRDa6OEJdZac 5XW2D/45KfzoQQ844pW9wPBstfoA4zhpxgYbXZdFhd1B3tDYs+gd0ydHZpM8roMnIC6sUz2UZVw IXLD2jiHt7yLZuphP/QVxipCVGpGWDePAo2x1ibRtN36V7QF2kYhmxqri0MMwpjy6AJMTGCUuMB xpRJlv+RypwgdJZTss3IDeLAh6amwIn5KwnKxa+VhAa1TweG97haA2x1DkLDE1BBaEBWerNMIhY XkU4aw+JMmBUEmqAu5AXPH7DXgINM5RHn/JzyiI3T7yLfmL0zAUjrq4eWRwG1HVPMGONTO7JfNE 0o0E+ULXqwLnQTgbGmZcyCHeOER/LovvzMIKrdz4xytDwyhERlt04lMyYKta/VQamfyHHL2eqte BmWKR4GrxysyQvF6+XvxLYIUbvcW/GEmZ2K3JOVgeh6yRY/mnANaUpqMzl5nZ1WZij3x49QanrG auTI+YKu1G7+pXQipQNg7LGtWo8+sBXCM44evsO6d6zedjLoJkpGbTJ2q1EbcCLvk12mjFkkh4A KdfC5MVpqO+KN0XR8txFvJs/K3UkRZlxM97ff+6aW7nGxBCmH5iL8yB/dAH2yravcO9bYYO+LQC Gs61agHa3hpCya2FC5c0KTXMLzmROHlqfLGqWdmgsZLg8hrozGFp5ahu+m+OGcL5QZ746vJi74E ghKphqYO93tyqXA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: a1wXs17lB3vVykj5tBpI7evB5uSFhglHw9gLgIPbmTg_1792493201 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1792493210-F0CA22AC-6E2130EF/0/0 X-purgate-type: clean X-purgate-size: 1242 From: Markus Armbruster Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau --- scripts/qapi/schema.py | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py index 11f3accec873..9e2152fa419b 100644 --- a/scripts/qapi/schema.py +++ b/scripts/qapi/schema.py @@ -179,11 +179,6 @@ def visit_end(self) -> None: def visit_module(self, name: str) -> None: pass - def visit_needed(self, entity: QAPISchemaEntity) -> bool: - # pylint: disable=unused-argument - # Default to visiting everything - return True - def visit_include(self, name: str, info: Optional[QAPISourceInfo]) -> None: pass @@ -315,8 +310,7 @@ def add_entity(self, ent: QAPISchemaEntity) -> None: def visit(self, visitor: QAPISchemaVisitor) -> None: visitor.visit_module(self.name) for entity in self._entity_list: - if visitor.visit_needed(entity): - entity.visit(visitor) + entity.visit(visitor) class QAPISchemaInclude(QAPISchemaEntity): -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455292.1668899 (Exim 4.92) (envelope-from ) id 1xJ7Vs-0001sj-GA; Tue, 20 Oct 2026 10:56:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455292.1668899; Tue, 20 Oct 2026 10: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 1xJ7Vs-0001qz-3U; Tue, 20 Oct 2026 10:56:12 +0000 Received: by outflank-mailman (input) for mailman id 1455292; Tue, 20 Oct 2026 10:47:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7NJ-0007Ii-7U for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:47:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7NI-002Egh-KT for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:47:20 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad746b4-e002-0a2a0a5209dd-0a2a4503cc92-8 for ; Tue, 20 Oct 2026 12:47:20 +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 6ad746b7-fae8-0a2a45030019-aa0a817cb311-3 for ; Tue, 20 Oct 2026 12:47:20 +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-91-PGvBjJmAP4aH1aJU5oYqmw-1; Tue, 20 Oct 2026 06:47:14 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5803E1800476; Tue, 20 Oct 2026 10:47:10 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B80D41956095; Tue, 20 Oct 2026 10:47: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=1792493239; 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=a0eKD3sUSsLDHL5Rbyj5qW1a5Bhls7mo+yQHcVi0dNs=; b=g0MDV1Y6heatGmPCdnglJ6LtHUtco6JyNGxu8LL5QtcZfdhHQQC02ImbX/yFE9nck+hwFj RlMWNGuZmgDOMoCoNb9/wkURw1DMCwMpyHukdggjWPUvcsyyg55CCELMCJifWpy5u5Y27t 6XzBFM4FeTKVl5KP6IfsDoMuSFt3YZ8= X-MC-Unique: PGvBjJmAP4aH1aJU5oYqmw-1 X-Mimecast-MFC-AGG-ID: PGvBjJmAP4aH1aJU5oYqmw_1792493230 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:27 +0400 Subject: [PATCH v7 10/65] meson: add qapi-type-infos-*.c/h to build MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-10-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=4026; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=eVJytPz3KQHyW0Eei+IlbvI0CrYX88Ak+jznKk8pYYM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYJt0ke19J4ltackOupI0pq7CK76MV5JKhu L19h61q7CSJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5bh7D/9o800Zx8Ea1Xfpr7ACGgnyzV8jkcBlp8Hzb7ozpogEKFcTat3oDoryJJsQxlgzgJHhAf4 xQT98v3zkCaoHRIbB6dR0HYZBqyvICSDEA2z6dydBWQCfbIPdcVhiGF29ilFln4WSCVMEnObaFP jSBeBazjRdH0T5xfyjCgJrBQSq2TnF577fRbor2DDFXhnjiRkuCteCnjdCRACcbp4bKOu/8aTqC zvMFT7nTq00cMgLWk7O7y/3V/o+NEYmNBrudDZxN2ovKLglKgbEKGZt1CpNg1Us3yGbmp7C/ued 6j8TVzxJBorlnnqcRONbN8vEXcK6fO6P9qZR7nTYal7lYdU6r9TCQoY4kvvQW+uDqXgQEAWmhOi jZqDTnpIgJdgITBb5cP1iuDx4m8zCGYgw4FDJSEPYQuWHaFdqeNvNBw0pdC2xUr2TTibV+OLWUp XXsHgCRssrvOLRavHKOKXE7Escb305j2bbdur64seJPONvFdSWLWSuLMcyK8cwxzTEA9j2xa2Hg HoJL3z3i0vH4SqDy9prxpuF+J3j1IYnps0k+MK+mTLYI4e8iqke/uSs4PUmCOpQMq5J4Otq6DcH MJqQiQREJhxMnpMKZBd9vBvDhmvts3IVzg3hJvzD52nk7JW3EAtQdIwCfqF4JndhviB2CIPR+OA lCJIJFcJtrFbXpg== 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-MFC-PROC-ID: fw5doU28uotdIqwyk7XxjwZrknzQy4Gct74BT-0D6s8_1792493230 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1792493240-6F6C64E9-C11DE64B/0/0 X-purgate-type: clean X-purgate-size: 4028 Add the per-module type-infos output files so they are compiled into the build. Reviewed-by: Kostiantyn Kostiuk Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- qapi/meson.build | 4 ++++ qga/meson.build | 2 ++ tests/include/meson.build | 2 ++ tests/meson.build | 6 ++++++ tests/qapi-schema/meson.build | 1 + 5 files changed, 15 insertions(+) diff --git a/qapi/meson.build b/qapi/meson.build index a46269b5a0c9..7477953492ad 100644 --- a/qapi/meson.build +++ b/qapi/meson.build @@ -79,6 +79,7 @@ endif qapi_nonmodule_outputs = [ 'qapi-introspect.c', 'qapi-introspect.h', + 'qapi-type-infos.c', 'qapi-type-infos.h', 'qapi-types.c', 'qapi-types.h', 'qapi-visit.h', 'qapi-visit.c', 'qapi-commands.h', 'qapi-commands.c', @@ -88,6 +89,7 @@ qapi_nonmodule_outputs = [ ] qapi_outputs = qapi_nonmodule_outputs + [ + 'qapi-builtin-type-infos.c', 'qapi-builtin-type-infos.h', 'qapi-builtin-types.c', 'qapi-builtin-visit.c', 'qapi-builtin-types.h', 'qapi-builtin-visit.h', ] @@ -96,6 +98,8 @@ qapi_inputs = [] foreach module : qapi_all_modules qapi_inputs += [ files(module + '.json') ] qapi_module_outputs = [ + 'qapi-type-infos-@0@.c'.format(module), + 'qapi-type-infos-@0@.h'.format(module), 'qapi-types-@0@.c'.format(module), 'qapi-types-@0@.h'.format(module), 'qapi-visit-@0@.c'.format(module), diff --git a/qga/meson.build b/qga/meson.build index cfa2157efb23..79163b7d8e93 100644 --- a/qga/meson.build +++ b/qga/meson.build @@ -39,6 +39,8 @@ qga_qapi_outputs = [ 'qga-qapi-init-commands.h', 'qga-qapi-introspect.c', 'qga-qapi-introspect.h', + 'qga-qapi-type-infos.c', + 'qga-qapi-type-infos.h', 'qga-qapi-types.c', 'qga-qapi-types.h', 'qga-qapi-visit.c', diff --git a/tests/include/meson.build b/tests/include/meson.build index 8e8d1ec4e692..026480d96851 100644 --- a/tests/include/meson.build +++ b/tests/include/meson.build @@ -4,6 +4,8 @@ test_qapi_outputs_extra = [ 'test-qapi-commands-sub-module.h', 'test-qapi-events-sub-module.c', 'test-qapi-events-sub-module.h', + 'test-qapi-type-infos-sub-module.c', + 'test-qapi-type-infos-sub-module.h', 'test-qapi-types-sub-module.c', 'test-qapi-types-sub-module.h', 'test-qapi-visit-sub-module.c', diff --git a/tests/meson.build b/tests/meson.build index 5877d2f60b12..6769a1e7812f 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -2,6 +2,8 @@ subdir('bench') subdir('qemu-iotests') test_qapi_outputs = [ + 'qapi-builtin-type-infos.c', + 'qapi-builtin-type-infos.h', 'qapi-builtin-types.c', 'qapi-builtin-types.h', 'qapi-builtin-visit.c', @@ -22,6 +24,10 @@ test_qapi_outputs = [ 'test-qapi-init-commands.h', 'test-qapi-introspect.c', 'test-qapi-introspect.h', + 'test-qapi-type-infos-sub-sub-module.c', + 'test-qapi-type-infos-sub-sub-module.h', + 'test-qapi-type-infos.c', + 'test-qapi-type-infos.h', 'test-qapi-types-sub-sub-module.c', 'test-qapi-types-sub-sub-module.h', 'test-qapi-types.c', diff --git a/tests/qapi-schema/meson.build b/tests/qapi-schema/meson.build index debff633ac17..392b59d8dccd 100644 --- a/tests/qapi-schema/meson.build +++ b/tests/qapi-schema/meson.build @@ -231,6 +231,7 @@ custom_target('QAPI doc', 'doc-good-qapi-events.c', 'doc-good-qapi-events.h', 'doc-good-qapi-init-commands.c', 'doc-good-qapi-init-commands.h', 'doc-good-qapi-introspect.c', 'doc-good-qapi-introspect.h', + 'doc-good-qapi-type-infos.c', 'doc-good-qapi-type-infos.h', 'doc-good-qapi-types.c', 'doc-good-qapi-types.h', 'doc-good-qapi-visit.c', 'doc-good-qapi-visit.h' ], input: files('doc-good.json'), -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455294.1668904 (Exim 4.92) (envelope-from ) id 1xJ7Vt-00022a-7W; Tue, 20 Oct 2026 10:56:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455294.1668904; Tue, 20 Oct 2026 10:56: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 1xJ7Vs-00020J-OB; Tue, 20 Oct 2026 10:56:12 +0000 Received: by outflank-mailman (input) for mailman id 1455294; Tue, 20 Oct 2026 10:47:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7NQ-0007JE-6L for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:47:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7NP-00EyXF-CO for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:47:27 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad746aa-8faa-0a2a0a5109dd-0a2a4509df90-38 for ; Tue, 20 Oct 2026 12:47:27 +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 6ad746be-be1a-0a2a45090019-aa0a817cb8c1-3 for ; Tue, 20 Oct 2026 12:47:27 +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-261-ihbyk2kzMnWd3H-QsJ0KOQ-1; Tue, 20 Oct 2026 10:47:20 +0000 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 EFDAD18007F6; Tue, 20 Oct 2026 10:47:15 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id AC08B1800586; Tue, 20 Oct 2026 10:47: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: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=1792493245; 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=T3j8f+7qjazkHlU3ibuflAeMZnSK6eTgFQwyyu7+HY4=; b=Ma1S9WUJwCrl7Z8h//7gJQ6StBDL/nu4R0flBPucFKAY4XaX8e5jH+oo+mf2E0F+vR8wIo /AavSU1Jt93i1O2rk4QEDLGy54TSEqNYVFOlyuGCN0ZHbQtM05f4yKNhzm27UaG/V/CZ3S XWXONaRFLVON5vtm0nDsfP+HISqCpj4= X-MC-Unique: ihbyk2kzMnWd3H-QsJ0KOQ-1 X-Mimecast-MFC-AGG-ID: ihbyk2kzMnWd3H-QsJ0KOQ_1792493236 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:28 +0400 Subject: [PATCH v7 11/65] qom: add qapi_type field to ObjectProperty MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-11-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1530; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=2OIgxeWqZ6otP2YGCtYtdyJ3HEK4Fvyx/L7bWvHPHdk=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYjp5Y+KqlnMbXKVbPp8oeCxnUXz1KL4/P8 K4p+GJF/R2JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5TnHEACR1GhcDzcI8DmQKfHIpJvlmkNBtahkon1/NhI0x7islO7obbKLlwPWCy4wQP0LWmjiFde xdHBmPABE8w+GBhIOHh7SA0bED9tVk5Z/KKlUlLW05WmHAclgZP0w/6d5wvOkytAsYlsqG3VRxy pzheoaZub7M/f1Vel44KT2PyTTkmTa/qOXxEwlb0xyleSWHAWJ9YwJZGDMVgrIazoCrrCjuu3I7 iTedHPzNeu958dcqBAk2k83xJ9h7d8l/nOwWQBatA7434OZv4mQjeA8o1Ofgcbi65KOPJGxySd/ zpF8bho145/tHV1hb2kOE9AJZWK5EagdnYfGHXBmTDKlj+Th/DTIwXSf5tt/sZhF0vRDi1iPq/I LKCOU9KvJA+kSgItubIrwmplrAZNenxsHtooqhUGlhbPvcmEcxvBEYCswzXAevfatbwJoe7DFxw Q+8H0wl+PDfMBiyBB0MAjrQjDNAgi3DiW+nG2xFvGonrsvQbamKdlaKdTC0x/2QCSiZM65jfyJv qZtODKR7Ucan3Z0MVy9Ve7TFMgJLRkBuEHYeUxKnLwFChoZ5UPUii0h9F/SrqgDGCI5+Y7VLkFR PA/35B9aACGPcf7BnkarTv8euSmDQVmF5eXIH82cCmx+dLkD7Y0WERC0r9g9iDHW6Ux3KE0GVqX 9APAXx+LTkI4QMg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: fcVR9DLBUPWUx9Y5p675YT2Bh5H24f709Dr9mNBFClA_1792493236 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1792493247-BF2DC034-316C5D66/0/0 X-purgate-type: clean X-purgate-size: 1532 Add a const pointer to QAPITypeInfo in ObjectProperty. NULL for now, but future patches will add means to make it non-null. The QAPITypeInfo will then be used by QOM introspection to tie the property to a QAPI type. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- include/qom/object.h | 2 ++ qom/object.c | 1 + 2 files changed, 3 insertions(+) diff --git a/include/qom/object.h b/include/qom/object.h index 90c1a34e49aa..e9b380462ded 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -15,6 +15,7 @@ #define QEMU_OBJECT_H #include "qapi/qapi-builtin-types.h" +#include "qapi/qapi-type-info.h" #include "qemu/module.h" struct TypeImpl; @@ -91,6 +92,7 @@ struct ObjectProperty char *name; char *type; char *description; + const QAPITypeInfo *qapi_type; ObjectPropertyAccessor *get; ObjectPropertyAccessor *set; ObjectPropertyResolve *resolve; diff --git a/qom/object.c b/qom/object.c index 96498f3d001c..c34b47312f29 100644 --- a/qom/object.c +++ b/qom/object.c @@ -3171,6 +3171,7 @@ object_property_add_alias(Object *obj, const char *name, property_release_alias, prop); op->resolve = property_resolve_alias; + op->qapi_type = target_prop->qapi_type; if (target_prop->defval) { op->defval = qobject_ref(target_prop->defval); } -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455296.1668913 (Exim 4.92) (envelope-from ) id 1xJ7Vu-0002EQ-27; Tue, 20 Oct 2026 10:56:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455296.1668913; Tue, 20 Oct 2026 10:56: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 1xJ7Vt-0002CU-FX; Tue, 20 Oct 2026 10:56:13 +0000 Received: by outflank-mailman (input) for mailman id 1455296; Tue, 20 Oct 2026 10:47:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7NU-0007JS-4P for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:47:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7NT-004cQR-Hc for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:47:31 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad746bd-8faa-0a2a0a5109dd-0a2a45079988-30 for ; Tue, 20 Oct 2026 12:47:31 +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 6ad746c2-b4ea-0a2a45070019-aa0a857cbe7b-3 for ; Tue, 20 Oct 2026 12:47:31 +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-330---ICFwzSMLyjVd2-rA4_dw-1; Tue, 20 Oct 2026 10:47:26 +0000 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 B08BA1955EA9; Tue, 20 Oct 2026 10:47:21 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7AA0630000E7; Tue, 20 Oct 2026 10:47: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=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=1792493250; 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=ECa+EP2+GWrANsxj0WvwUZJkCIlcvdWbNsc8NiwNlVo=; b=g5CiGGuNvFD0rgfvjV/dslMMhS8N2Tk2sVawBzi7DbQM0fjPit4aIcWckuDIta3ksgelEp 5OmtJONQBOz7bKbSzEseUXQFsTZqVjjWpuE8swVjkr/CYFVvHU15f6ssTOzsWVUtWEZsJ8 ocTQ1UmmJF45kUNLVyBF1gpUAo+Z1T0= X-MC-Unique: --ICFwzSMLyjVd2-rA4_dw-1 X-Mimecast-MFC-AGG-ID: --ICFwzSMLyjVd2-rA4_dw_1792493241 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:29 +0400 Subject: [PATCH v7 12/65] qapi/qom: add qapi-type field to ObjectPropertyInfo MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-12-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1921; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=iKT89ERqmB5xJit6r3j8WUD6ClpE36oEYsgjEEvZ40o=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYxccp5RLblnwypa/9MUPo5yHCT1xWIDSPC kA8/nPQHZWJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5e/BD/9TtX0u6H+0rpG8WE+dl2QuQTNqc7I7UQsZIGnhPN3Al/XNQZiAz7mmC9G+NYbkf+JSdfB k5kprVrQhJ3Qwo46Eo+f3qr8ThczDGZA6O4hzHv5kxdvgp6qn1DaCqqyaCoKsR/z+iuGL2HmZsU mDSJqIH3dy3Hb40RluHg7V7GmVv4Rf6FguZ82m5gB7pbbTD2eXnx3z+CnMSeaAmfG4F8BZ0feAi ZZdOtwWw3zJcvLJE4/+UfOCPiGxw4cQtY+ATWlNBSjHmmNXNtzG8MlEvUPCJ2Sjn27mHRxuM7nO WQ6+yJh/lQ0Ghbdq95AVNza5NuB1EVwplpUXCjM1cH+Yy2DOAZFw8NZuDgRazKKFH/AOAYKwO7P fSFGOlRSGjjJuFA4w4sYrs+YXl2zcGOmUVTKNTX3yF2OhQx8UgAnNPV9I4poe0gXiUAgmElaUBX bAH8SeScvuf8ZDHbsiN/1WmUdBrI/V4+IxLJlZYGHkeyF8ysSL5DJ7MeUTFBeBmG5LI9nRNWyhj xgXX8aohw8Oq+7nyejaTJP4C9/B8IRO6jiFJRRUvMsMjnKfTeEn2904ZPwG2JU6Qdo5st5sHmK6 GVmZP2Uzs/39Pu485CCHNkrP67konhv+JXIwq2EN4q6gZq+7K1gfG51xtJ2MyHYyCc0BAAGTRD5 xkTzLUa6kbRI52Q== 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: TkhLPz90VvreOJxmXBfv2WjtG_xZHSvmirvCRQZqCwI_1792493241 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1792493251-378D1AE4-B244C33E/0/0 X-purgate-type: clean X-purgate-size: 1923 Add an optional 'qapi-type' field to ObjectPropertyInfo and ObjectPropertyValue. When present, it contains the masked type name that can be looked up in query-qmp-schema output. Absent for properties without a QAPI type association. Always absent for now, populated in the following changes. Reviewed-by: Markus Armbruster Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- qapi/qom.json | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/qapi/qom.json b/qapi/qom.json index 49f222796ab4..34be7768135c 100644 --- a/qapi/qom.json +++ b/qapi/qom.json @@ -35,6 +35,10 @@ # qdev device type name. Link properties form the device model # graph. # +# @qapi-type: the name of the property's type as it appears in the +# output of ``query-qmp-schema``. Absent if the type does not +# occur there. (since 11.2) +# # @description: if specified, the description of the property. # # @default-value: the default value, if any (since 5.0) @@ -44,6 +48,7 @@ { 'struct': 'ObjectPropertyInfo', 'data': { 'name': 'str', 'type': 'str', + '*qapi-type': 'str', '*description': 'str', '*default-value': 'any' } } @@ -55,6 +60,10 @@ # @type: the type of the property, as described in # `ObjectPropertyInfo`. # +# @qapi-type: the name of the property's type as it appears in the +# output of ``query-qmp-schema``. Absent if the type does not +# occur there. (since 11.2) +# # @value: the value of the property. Absent when the property cannot # be read. # @@ -63,6 +72,7 @@ { 'struct': 'ObjectPropertyValue', 'data': { 'name': 'str', 'type': 'str', + '*qapi-type': 'str', '*value': 'any' } } ## -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455298.1668919 (Exim 4.92) (envelope-from ) id 1xJ7Vu-0002SS-LA; Tue, 20 Oct 2026 10:56:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455298.1668919; Tue, 20 Oct 2026 10:56: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 1xJ7Vu-0002On-9D; Tue, 20 Oct 2026 10:56:14 +0000 Received: by outflank-mailman (input) for mailman id 1455298; Tue, 20 Oct 2026 10:48:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7ON-0007MJ-S9 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:48:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7ON-006MOh-1c for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:48:27 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad746e4-2eae-0a2a0a5409dd-0a2a45098a72-36 for ; Tue, 20 Oct 2026 12:48:26 +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 6ad746f9-be1a-0a2a45090019-aa0a857c61d7-3 for ; Tue, 20 Oct 2026 12:48:26 +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-510-cVbzbvoGOKiXjaCIGIacxQ-1; Tue, 20 Oct 2026 10:48:22 +0000 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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F35FD1956050; Tue, 20 Oct 2026 10:48:17 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7FEA65BC; Tue, 20 Oct 2026 10:48: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=1792493305; 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=eMqswUiLM19ojZ+xv5E964KFYfmL1usSS/p/S7HX9Dw=; b=SG/6TJhWYrfN1diSOU9FJeLz7qhcpo+UoKAkb06jB2hbyMG1/pEdeUWTuRpmx+/Li/j53B oZ5k47XXi1o0d6rXzLfDTfFy6OqEFRVNkNcA6cL5Rv9zpnPisVc9oUClARg3U7bH5COsOl U4nZ0sMaFAJQibHpSptXKahla9h44MA= X-MC-Unique: cVbzbvoGOKiXjaCIGIacxQ-1 X-Mimecast-MFC-AGG-ID: cVbzbvoGOKiXjaCIGIacxQ_1792493298 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:40 +0400 Subject: [PATCH v7 23/65] pc: convert OnOffAuto vmport property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-23-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2552; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=rT4IlVA3K6hhZkzIFOmf7AHwvtTZzfc1DRg/HWfKdY4=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZM5/OPYpgkFOCrz7lC/8MWagOdQlNe9HMu Ryp6VHtccaJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5SEYD/9QUk3mMyoHypSwCfk0l9cp7LpdZdLAE2EvzjA5uGZIIAqBUxJDWAuzNGzj6S+fvUJlWdC EAhsGdZYLWEH7ASWHHvy7QL+I4sYO8Xg73A6bzHJwEOXw/X9WMYP92+xT4V4aCVSuSlgPw0vTW0 iDGOxiKxLpni8ZM7f9KyKZ7A07apImgWr/PvLmtbAQVMyGBFVMAlRVQNHiAVAYdPfO4SqPGDtEL FSBHcAGWwReG+sJQLCw41zKiUg19IRx+HFFvZizprongoFMpDaugaNynZ5796k7gt/kq32gooTW K1HtncPs4zo3o0RQhly74rTNpbStacdnJYfkbYDra1gDQX4eyKiFqN0SjV67VE/VvdnJQ8LJ+8E Io6ab5QTARFKwxykGzqjoPPlbjW5eZ6GbWMq2hOGAKs7EJU3OZb880jYHppuGtTKMeUpX/uuFJ5 eN4Qb9D4OSHbiB0FCPwmlld/4ccrph+UXo3QxiUbsq3bq2b/jfEoZkiNrexjwcvm0VgnTwhUzxZ 8vLXrwQhyrorPwXLyf2OJODHc3WMrHl2l0U2HAnthI2rPwYhMyYDc0jK0pwPULBUOsnDcOp0HmV s84v32DlNvvS1/ARhP+gJq6EJ073Rob14KhIt2ElZfOtp3GUn5BAYDx7P4sYVuaJp2x6H2r0frC taKgfMicnsq1l+w== 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: afHXkvdjJaInW29m8ZdwSh07harrZdA3bOoAkmzNXZY_1792493298 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1792493306-FD469034-3F158D7D/0/0 X-purgate-type: clean X-purgate-size: 2554 Convert the vmport OnOffAuto property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/i386/pc.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 2d8c87b0e34c..12de020adfbf 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -46,6 +46,7 @@ #include "kvm/kvm_i386.h" #include "kvm/tdx.h" #include "hw/xen/xen.h" +#include "qapi/qapi-type-infos-common.h" #include "qobject/qlist.h" #include "qemu/error-report.h" #include "hw/acpi/acpi.h" @@ -1417,21 +1418,16 @@ static const HotplugHandler *pc_get_hotplug_handler(MachineState *machine, return NULL; } -static void pc_machine_get_vmport(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int pc_machine_get_vmport(Object *obj, Error **errp) { PCMachineState *pcms = PC_MACHINE(obj); - OnOffAuto vmport = pcms->vmport; - - visit_type_OnOffAuto(v, name, &vmport, errp); + return pcms->vmport; } -static void pc_machine_set_vmport(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void pc_machine_set_vmport(Object *obj, int value, Error **errp) { PCMachineState *pcms = PC_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &pcms->vmport, errp); + pcms->vmport = value; } static bool pc_machine_get_fd_bootchk(Object *obj, Error **errp) @@ -1728,11 +1724,13 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "Maximum ram below the 4G boundary (32bit boundary)"); - object_class_property_add(oc, PC_MACHINE_VMPORT, "OnOffAuto", - pc_machine_get_vmport, pc_machine_set_vmport, - NULL, NULL); - object_class_property_set_description(oc, PC_MACHINE_VMPORT, - "Enable vmport (pc & q35)"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = PC_MACHINE_VMPORT, + .description = "Enable vmport (pc & q35)", + .qapi_type = &OnOffAuto_type_info, + .get = pc_machine_get_vmport, + .set = pc_machine_set_vmport, + )); object_class_property_add_bool(oc, PC_MACHINE_SMBUS, pc_machine_get_smbus, pc_machine_set_smbus); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455300.1668927 (Exim 4.92) (envelope-from ) id 1xJ7Vv-0002d4-9q; Tue, 20 Oct 2026 10:56:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455300.1668927; Tue, 20 Oct 2026 10:56: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 1xJ7Vu-0002Z4-Ry; Tue, 20 Oct 2026 10:56:14 +0000 Received: by outflank-mailman (input) for mailman id 1455300; Tue, 20 Oct 2026 10:49:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7PV-0007Pt-Nk for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:49:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7PV-002FFo-4b for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:49:37 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74737-2eae-0a2a0a5409dd-0a2a4509c02e-16 for ; Tue, 20 Oct 2026 12:49:36 +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 6ad7473f-be1a-0a2a45090019-aa0a817cbbe9-3 for ; Tue, 20 Oct 2026 12:49:36 +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-31-cMjt34M1M1KDozVQqfp4-Q-1; Tue, 20 Oct 2026 06:49:25 -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 6DEAB18005BC; Tue, 20 Oct 2026 10:49:21 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 88FC91956088; Tue, 20 Oct 2026 10:49: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=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=1792493375; 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=563WFmKiLO7dqjDqTC7WMPfEiXr6apTsp1OZACEim0s=; b=fDnrM/lx3VpgORToMAsKRUAnQzsIfHPn6VWSwqt2sh2Qk5QS1cWgeSNS2GqhZHKixfBzVR FVIoiRuOMXiXrpuy2YE2p8Af4L4NEX4pzkwYOJY1a93DrKO9vMU631sxEaQwyvngD7FZ9X zn+hnMqJXeeOUFmaqY4EYYldsES6MLA= X-MC-Unique: cMjt34M1M1KDozVQqfp4-Q-1 X-Mimecast-MFC-AGG-ID: cMjt34M1M1KDozVQqfp4-Q_1792493361 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:52 +0400 Subject: [PATCH v7 35/65] net/colo-compare: fix compare_timeout setter visitor type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-35-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=986; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=ut4iYtgZkRe9PHyTHqoA5Y4P74BD/xuE+aYJ9SkZgtQ=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaypTQuRSc2e46naq5h2E43TS8QqJ3WLD4A vhN/XcoCWiJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5d7uEACx86dNfBKT5U/pKovqIeXYBLYQ//vmgkwdkrPTI4ndp54y3HdcyZ5HRfCgtKdveLHg+jd X+w+YSqBLl5VEUHjm/meu5m+OH+47NHQTNS2OKFtIjrxy/gNQNKipDooyWUZscVjYX1UGThUBNN dVl9HT3PRymM5GJv6gQ6PTVcRkeH0Kxu4oI+1CFyViK6e+5yw9DJwVb5QoOpVeThfgWhFpg3pjL sceKJT9j8XZXVzHbmihcdoYAT3+D7EKFVk1qo0UyOLGA9/8KZOP1HdXhWDgb2qZfH53dKb7Ko8e uEwVXLIXLPEvUgi9lAaQyLh7T+FyJcBCnEEs6xCFzJqne3xq63RvlAKDFKOu/ILq50B/wHxRXFw AjBbG/L64r+z+dli7dfrYX/QYWxXTLKaMrudDjRReACkngn9oQQ6QeuvsTH+PK6E0IORyfozZwd PZX89gASbZR1oNofjZBZlHjuYS4yeBsThEwa4eD7jAxHw81oB1ubcKmEIPILuJUom2AZbAZfx2j +6EZUzt+UOWlN5WSLgBSX4ZnOSrhDJo1RQmsu4JsKh0Pe4hsWUb+I+nUCfKE6aydG/D+MwmW2qS ddEbgTIu+25MUoFBllzZJOwwYkCEgScY2rLSf628Aspu5Mgqq5QEpvfYnAis/PeOgKgX88neUhv FwqeHEUL+SZt/vA== 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: YSO0PXlRKix1fsUgzX3q9yIM4pvQjWXAtORZY3jpXGs_1792493361 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1792493376-BC2F4034-FC48F7EC/0/0 X-purgate-type: clean X-purgate-size: 988 The setter was using visit_type_uint32, truncating the value, while the getter and typename use uint64. Use visit_type_uint64 consistently. Fixes: 0c4266ef2690 ("net/colo-compare.c: Fix compare_timeout format issue") Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- net/colo-compare.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/colo-compare.c b/net/colo-compare.c index 5986fb1e8800..948a2f7f9e4b 100644 --- a/net/colo-compare.c +++ b/net/colo-compare.c @@ -1075,9 +1075,9 @@ static void compare_set_timeout(Object *obj, Visitor *v, Error **errp) { CompareState *s = COLO_COMPARE(obj); - uint32_t value; + uint64_t value; - if (!visit_type_uint32(v, name, &value, errp)) { + if (!visit_type_uint64(v, name, &value, errp)) { return; } if (!value) { -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455302.1668939 (Exim 4.92) (envelope-from ) id 1xJ7Vw-0002qy-8a; Tue, 20 Oct 2026 10:56:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455302.1668939; Tue, 20 Oct 2026 10:56: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 1xJ7Vv-0002ni-LH; Tue, 20 Oct 2026 10:56:15 +0000 Received: by outflank-mailman (input) for mailman id 1455302; Tue, 20 Oct 2026 10:50:36 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7QS-0008Qv-LU for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7QR-004cyI-Uv for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:35 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74775-8faa-0a2a0a5109dd-0a2a4506bdee-32 for ; Tue, 20 Oct 2026 12:50:35 +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 6ad7477a-195a-0a2a45060019-aa0a857c58db-3 for ; Tue, 20 Oct 2026 12:50:35 +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-656-Cd5iFrsSPFiy_O9eCidOaQ-1; Tue, 20 Oct 2026 10:50:30 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C16C31955DE8; Tue, 20 Oct 2026 10:50:24 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4304D1956095; Tue, 20 Oct 2026 10:50: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=1792493434; 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=stj/oklFy5XE7Ux6UVzd34CG7YO8zlEFRRZGNs4BwjQ=; b=FA0d2bZnAjmxVWje6jrukFJntl8LiVIkhaR2F4/sYQiFzzxjDZjYwU0+k2L+2hmOh0kOs6 NGTCd6tAIogNIkzjpZnuTBTOijskLjMXw/PYFRv5NLwTxBguhSwKPlbmuFabxHk5BLVOvH w6Q9huSBL1rRBYe+t1owfKD78Tazug0= X-MC-Unique: Cd5iFrsSPFiy_O9eCidOaQ-1 X-Mimecast-MFC-AGG-ID: Cd5iFrsSPFiy_O9eCidOaQ_1792493424 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:03 +0400 Subject: [PATCH v7 46/65] hw/ppc/spapr_drc: convert fdt property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-46-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1126; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=tzAtw2N/GmjCt5f2xymcXMco6tXqwvWNy/tFAoovn48=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZbrmMIXAAgbwi3HHXAfckNSBqoT7PupXMdX jNNL1pkTe6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5ZtBD/9HzJq3j9NRTh8cC/IrlGiBUn7R8G3aWpPmmvNkh3x2f+rQGtv+c4/4fZ5SVY8vIMlozLI LUxj6qGBu0GxrQWT8fSd91RvbaYDeiByrDclv6ElUBKkE+tgleBEJUKwQJfK3M0e39H0MbjtzRg dxzN4rNG0OtE8h6qgxhP29CFH3AITnPK6JfYp3BIuQLwbsy/HZwgwge9j97HT9lCQ3XaWTtwWEp mj+SjQmSYNj3MWpB5O71V5XG20mItYobMA5CEVyvnwge7sN5eyuap4ds31caHAW78QyHPlOFVoC mLdbsQcFaIesAIo6kEnisNkqHnb8yVLFTI6dZfqTwCKl2twuRgOyGq3sME35mvXwpXYnk7ngkNm 4Wv7Qk3oqp9AjkpD2TpcMxKOiMI/qMeCTzwBE3Ul8FypE56v856BMn24Tr0BYUM36SttPitGe8O y06nmXFiwC88uT5JL/gPnfbVYmjDD8CwTftjlcRo66wdO/Uj1cC4+wc1ynGvOspelolj6z9kjry bcWiTwBgrkt3gSwktkytTSDlZ5MqNlPDv0mE82BFtszFNBtxOhfX0w97OQzXtVLle5h+YKHfgdn N5d4ugnLs5FJL1SrpPAd+tbg85sl64x/ZW1OdnyMEQL9XhQtUEDzjmQBCxiIyHOFat+aC63mV0H gQWNLU0ZIgJd7oA== 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-MFC-PROC-ID: _nnVg7BEkDR_5LkQkCG8wdxg9IDhvmWsX7fRsSmZsBA_1792493424 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1792493435-FC40377B-124A8830/0/0 X-purgate-type: clean X-purgate-size: 1128 Use object_property_add_qapi() with any_type_info for the "fdt" property, since the FDT structure is dynamically shaped at runtime and cannot be represented as a static QAPI type. Reviewed-by: Amit Machhiwal Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/ppc/spapr_drc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c index 64f9ca29b02e..740149ffdf3e 100644 --- a/hw/ppc/spapr_drc.c +++ b/hw/ppc/spapr_drc.c @@ -587,7 +587,7 @@ static void spapr_dr_connector_instance_init(Object *obj) object_property_add_uint32_ptr(obj, "id", &drc->id, OBJ_PROP_FLAG_READ); object_property_add_qapi(obj, "index", &uint32_type_info, prop_get_index, NULL, NULL, NULL); - object_property_add(obj, "fdt", "struct", prop_get_fdt, + object_property_add_qapi(obj, "fdt", &any_type_info, prop_get_fdt, NULL, NULL, NULL); drc->state = drck->empty_state; } -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455303.1668947 (Exim 4.92) (envelope-from ) id 1xJ7Vx-00031v-8r; Tue, 20 Oct 2026 10:56:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455303.1668947; Tue, 20 Oct 2026 10:56: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 1xJ7Vw-0002yu-F6; Tue, 20 Oct 2026 10:56:16 +0000 Received: by outflank-mailman (input) for mailman id 1455303; Tue, 20 Oct 2026 10:50:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7QT-0008R4-MW for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7QS-00HRtL-SY for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:36 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7476f-e002-0a2a0a5209dd-0a2a45078784-48 for ; Tue, 20 Oct 2026 12:50:36 +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 6ad746c7-b4ea-0a2a45070019-aa0a817c6193-3 for ; Tue, 20 Oct 2026 12:47:36 +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-581-QIWQbiQEOjKXo9XLY2S_-Q-1; Tue, 20 Oct 2026 10:47:30 +0000 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 A06391800846; Tue, 20 Oct 2026 10:47:26 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 26A6630000E7; Tue, 20 Oct 2026 10:47: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=1792493255; 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=PVXTIIpNbgnr5AJ+/yIbBcdA8eA5b8YMHg0i2cYvT44=; b=Lo6QaQrBtjz7PYtpX0Jon0MPlcgYoiUnh0VDBUBNm6yCJRvf6ecaZZDqPw58pETqiMtDOX /ygMvgf5GECfFwkFUpXYVlmI18kD70dFTkQPC7ezNGzi/stAzDw+IoWSDZAN6Zpyt3yXvJ hOW19em0Ol02fq7s3fJwongnPC/EtXM= X-MC-Unique: QIWQbiQEOjKXo9XLY2S_-Q-1 X-Mimecast-MFC-AGG-ID: QIWQbiQEOjKXo9XLY2S_-Q_1792493246 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:30 +0400 Subject: [PATCH v7 13/65] qom/qmp: populate qapi-type in QMP handlers MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-13-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=3535; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=i+4aNg1CWaC9FuQwQPBmrQeBSkYvF4PheLxhenOOFfo=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYDWzReLBw3m81dGDIXbwzl9a7/x3QA+lLt YiL2TIXOxiJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5SUfD/wJNBGKtLromvCCVRWVjPvxR5grgFUIPYxITDg41xmOLrKqK6tkYNGmFOZFpRXvHXGYvRQ TdQmUahRaSDpeuJbFcaYT73xbCCqya8tVq8EmWAT5UeRvgtVrubv+XmDarrnryY02yLXvkIPllC xD258e/Sa+caea6AEZbydm8puSKag8kjyvK+G/zuYF1znKnI8eJxFrc3NH2jpHB6n9mLR5rzuys KpmuOkIz/+997QlgvghfOc9I5oUvG09YZbw98d4FxVxtx5ARqn/Vp/by4sa4tu2Tu0k6JWoMyR2 FLbIEl5NmPd/Vzzo8e0e2s7lkcsZEaa6+6GDVtgr3zcY0ceNHCAlZDAcuV2JumnHEjgGHaGDC3j m73n3AS2hBEShtU728GRRbYOuf5ZVmV0IHuJrD2XWVTkdWBtjjOKsTKqGgmguNhjUQn/iZ1XRs6 AwFiABH4kHoVozldkVrlbvXe7p5VFD4ze0fzu1PCDur+7/Ays4XczNXKWN1fQ5u2ZNLW5LYbfg+ ljEVnbaU+fg2V7agpnwf/IswI8Aw7S6ja3o33R2iu3N6LeX5VdqV5qtUy9mRVydHeEJii8A9+vl Yd8aU3wBZlxTyloC0tuExCV6B9nUqFz84SN6C4Bl11QPGw0u4G9nKK1ivmRDCOq3WPxaOAUae2j TUSTCHbBFtRj1ig== 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: sHwSZr-HnG559bICcJtoxPQiNr-KN63m3XNF-YRXhHM_1792493246 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1792493256-A6CDFAE4-E3FA7228/0/0 X-purgate-type: clean X-purgate-size: 3537 Wire up the new qapi-type field in all four QMP handlers that return ObjectPropertyInfo or ObjectPropertyValue: qom-list, qom-list-get, device-list-properties, and qom-list-properties. When an ObjectProperty has a qapi_type set, the masked QAPI type name is copied into the response, allowing clients to cross-reference with query-qmp-schema. No property has it yet, the following changes will populate it. Reviewed-by: Markus Armbruster Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- qom/qom-qmp-cmds.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c index f17389c7305c..47bf3bf2937a 100644 --- a/qom/qom-qmp-cmds.c +++ b/qom/qom-qmp-cmds.c @@ -25,9 +25,23 @@ #include "qapi/qobject-input-visitor.h" #include "qapi/qobject-output-visitor.h" #include "qemu/cutils.h" +#include "qapi/qapi-type-info.h" #include "qom/object_interfaces.h" #include "qom/qom-qobject.h" +static ObjectPropertyInfo *qom_property_info(ObjectProperty *prop) +{ + ObjectPropertyInfo *info = g_new0(ObjectPropertyInfo, 1); + + info->name = g_strdup(prop->name); + info->type = g_strdup(prop->type); + if (prop->qapi_type) { + assert(prop->qapi_type->masked_name); + info->qapi_type = g_strdup(prop->qapi_type->masked_name); + } + return info; +} + static Object *qom_resolve_path(const char *path, Error **errp) { bool ambiguous = false; @@ -58,12 +72,7 @@ ObjectPropertyInfoList *qmp_qom_list(const char *path, Error **errp) object_property_iter_init(&iter, obj); while ((prop = object_property_iter_next(&iter))) { - ObjectPropertyInfo *value = g_new0(ObjectPropertyInfo, 1); - - QAPI_LIST_PREPEND(props, value); - - value->name = g_strdup(prop->name); - value->type = g_strdup(prop->type); + QAPI_LIST_PREPEND(props, qom_property_info(prop)); } return props; @@ -78,6 +87,10 @@ static void qom_list_add_property_value(Object *obj, ObjectProperty *prop, item->name = g_strdup(prop->name); item->type = g_strdup(prop->type); + if (prop->qapi_type) { + assert(prop->qapi_type->masked_name); + item->qapi_type = g_strdup(prop->qapi_type->masked_name); + } item->value = object_property_get_qobject(obj, prop->name, NULL); } @@ -241,9 +254,7 @@ ObjectPropertyInfoList *qmp_device_list_properties(const char *typename, continue; } - info = g_new0(ObjectPropertyInfo, 1); - info->name = g_strdup(prop->name); - info->type = g_strdup(prop->type); + info = qom_property_info(prop); info->description = g_strdup(prop->description); info->default_value = qobject_ref(prop->defval); @@ -284,11 +295,8 @@ ObjectPropertyInfoList *qmp_qom_list_properties(const char *typename, object_property_iter_init(&iter, obj); } while ((prop = object_property_iter_next(&iter))) { - ObjectPropertyInfo *info; + ObjectPropertyInfo *info = qom_property_info(prop); - info = g_malloc0(sizeof(*info)); - info->name = g_strdup(prop->name); - info->type = g_strdup(prop->type); info->description = g_strdup(prop->description); info->default_value = qobject_ref(prop->defval); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455305.1668953 (Exim 4.92) (envelope-from ) id 1xJ7Vx-0003Fn-Tw; Tue, 20 Oct 2026 10:56:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455305.1668953; Tue, 20 Oct 2026 10: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 1xJ7Vx-0003AJ-9H; Tue, 20 Oct 2026 10:56:17 +0000 Received: by outflank-mailman (input) for mailman id 1455305; Tue, 20 Oct 2026 10:50:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7QU-0008RA-Kh for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7QU-00CvYD-1M for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:38 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7476d-bab6-0a2a0a5309dd-0a2a450ca39a-30 for ; Tue, 20 Oct 2026 12:50:38 +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 6ad74740-f479-0a2a450c0019-aa0a857ccd51-3 for ; Tue, 20 Oct 2026 12:49:37 +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-692-f6pkGtb9O-GKxmFhJLnr0g-1; Tue, 20 Oct 2026 10:49:33 +0000 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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 96BF018011E7; Tue, 20 Oct 2026 10:49:29 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 07CCA418; Tue, 20 Oct 2026 10:49: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=1792493376; 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=0IAJt0UD2BHY2aeJtNI3vxcEoKPgyvku96KOQdFfo40=; b=H7ZrEHKdzz68TWuYsdgHagkcKbQxkCBIwiD7+9bunZJ45w0cUzRT8zVV1c3G9p75AAp7WQ T7bbBL3/PReTdz1tCir39/t5pBGimpjvBDvw1bWV/YW/Wc+AGHVJ1pQAhTwl7ssy/jM9CX X0XYMo3u0biEqJSuQDdCD/slsK3hL5U= X-MC-Unique: f6pkGtb9O-GKxmFhJLnr0g-1 X-Mimecast-MFC-AGG-ID: f6pkGtb9O-GKxmFhJLnr0g_1792493369 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:53 +0400 Subject: [PATCH v7 36/65] net/colo-compare: fix max_queue_size setter visitor type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-36-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1019; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=2Ht6gW7AXC+9m2hyIj3XjReAS0cmbqbO/nhhR3s10ik=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaBju/eY1bBbqeZbyaaIna3yDT1YO5S2ZfK Dk+TjopPr+JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5dQZD/9+OPsZ+9wdTvZlJAHJ8LdZ+1IrTm8SRc4WfgMoVaUgmxvUmArgHB8hI32zhhT+Ba88j5h KVa4ATUp8pq0eFWpUQQliSGEcG8IcvbDzwCdXHlbCyx1nenDacuX0x1Xzy6lOPsZkDaLW4sd1av aslU4lzEjPo+woZOS+f31o8bS96Uj4DK9zSO/2jZS60JmsZVWU2RuRFsQ4ynCztQC5WVe561WiF Neo8iP9N1N6jRWQ/W9lDjOjhSLPfoogGEELTAUdypajGDPuGgyGOUNHGrXgAoT6RZ9LSPkaXi9M YVb+sG/RbGXWjlrdd/CFkcXWKmRvs4HZYOoCxI3XLPjngyKh4mXKogIvBPZkZyD1Mc01f37OWJJ Z601T1TKyOwOevdMSa3zjfTSInCHXtBGcfygNJ1EHaIfbfspA5GBA6TYOD34MkYVQ7Xo0EMeDYd ZIRp02UPolMQALQO0ANg3mVOP62D3BNsyhxHxlfjumfHsGoGYZ6mHjkjkO/PzHDEye+BfFcPcE1 op8EVu1uAVHHecAerzTbPZ2xi8hfaVgovOLMJe0DIozxp7l06V9c+bbZegHgr1qr0kr+5Z1dy+b cGCIdsvGHbP8dorXb8/DNE5clHvwjDTMX8mVMgxx/XbT5GQClDJRTRj2mTFy/Cr8znwahtft6UL 2RCiOOUs4aDYIGg== 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: t2UDmA5Ri04ASnUKEJ0mPmk-iyUtk1Qg-GnqhxDfmK8_1792493369 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1792493377-52331A5B-2042A45C/0/0 X-purgate-type: clean X-purgate-size: 1021 The setter was using visit_type_uint64, accepting values wider than the uint32_t field. Use visit_type_uint32 to match the getter, field, and typename. Fixes: 0c4266ef2690 ("net/colo-compare.c: Fix compare_timeout format issue") Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- net/colo-compare.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/colo-compare.c b/net/colo-compare.c index 948a2f7f9e4b..a6910de869ff 100644 --- a/net/colo-compare.c +++ b/net/colo-compare.c @@ -1129,9 +1129,9 @@ static void set_max_queue_size(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) { - uint64_t value; + uint32_t value; - if (!visit_type_uint64(v, name, &value, errp)) { + if (!visit_type_uint32(v, name, &value, errp)) { return; } if (!value) { -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455306.1668963 (Exim 4.92) (envelope-from ) id 1xJ7Vz-0003bA-EX; Tue, 20 Oct 2026 10:56:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455306.1668963; Tue, 20 Oct 2026 10: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 1xJ7Vy-0003VG-JM; Tue, 20 Oct 2026 10:56:18 +0000 Received: by outflank-mailman (input) for mailman id 1455306; Tue, 20 Oct 2026 10:50:39 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7QV-0008RM-92 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7QU-004cyI-Lz for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:38 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74765-8faa-0a2a0a5109dd-0a2a450b8d4a-34 for ; Tue, 20 Oct 2026 12:50:38 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad74704-b7e8-0a2a450b0019-aa0a817ced0b-3 for ; Tue, 20 Oct 2026 12:48:38 +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-29-uBDd0-1GMx-Pw1Kl9QVEug-1; Tue, 20 Oct 2026 06:48:27 -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 0BFD51955DCB; Tue, 20 Oct 2026 10:48:23 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 811011800257; Tue, 20 Oct 2026 10:48: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=1792493316; 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=oguRv2squZzE4kLuZbCGfVuSLth7nwetzOZz6ya/vQM=; b=ZE+oPup0eNqt85KXkWK0XNRSdRWPZDTjwjJ0B2dNVzEo9yU68sjnvJRKWu38HF7Go5Xi3I WDkodvsp/Lup8IRhRQAxaaY4RoUoCbCIapzlNSX5HMXfERPg7l3F4BAN4gHttXAg5aojFC nd7psqf3OEzphq7jjk9pO1cKsj1R3CY= X-MC-Unique: uBDd0-1GMx-Pw1Kl9QVEug-1 X-Mimecast-MFC-AGG-ID: uBDd0-1GMx-Pw1Kl9QVEug_1792493303 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:41 +0400 Subject: [PATCH v7 24/65] arm/virt: convert OnOffAuto acpi property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-24-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2443; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=WJV9rbWGfyoHPVy5l0gOvkb5+YjNc4EgQxym05N/4z0=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZD2w11mplFmU1C3uOjRIrgiEXmssGFGVqF U+VXCQyIhmJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5VV9D/4yHO7gBqYrWIgKINlgaqxweu9J3zPt0Q96BUDUTYP82Ji46aRrDnTKFU/lmiVpB0fAB4e XJamdIf6GysZPW/ts5RuPqmpRgUOHkFyl3w6WSrVcFZiUziA7H7//SozvNb0ksb52BEBDgRfu59 76EmyWmsMmdXm+7NFzf2Yr+0bybSNkLa/MDFeCosMy7O2q3mPK9t3viHrwkYiKodq7f49cF6ULL oQdp5XFWl+UruNu6YzMVat1OiEu+899ewJ0eacPhEublBVLtFTlEyPN76iInq272v6ozbm0j+v4 dODiO9YWj3H5tgsJT8uGwdCphesONwj0ehWE8RIOlcUgPq4CG6I5T2hqeBC816s74u8j3SXm1gs UhtJlBc/VY3cXU1/oQ2tjN4SSA6n7oGSwK+LRulGbjdZC6TUoOksZ1YjYPPMnyAOQ5TRVyAAgpc O/JcWDzz2hNjVcm8QKZsT7maPZt2pSxPvzOMz6stvRCSGt8xEj/e2l9kUWyvKNOEIFsGMjCJ4NB pytKX14Dode4YAKX1vRHPXwn7/ugDk+4mt37W8v1DKB3P4UJu9L8YinWg2FGRK8OTzDd+mMm7aT E0xuadOhVSJzsCQlpI4JB5RAmJ9WvMZdP4Mo65KTRR9rVKvDeEboNO+ggGjsDNOsWBeK+S/od4x iQ07BZ5MWxFvlRw== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: FAl71IotVJWAVOSEjfipUjAnMp35J6PKHyeAAHri7vM_1792493303 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493318-1B2DC9EA-14E3AB90/0/0 X-purgate-type: clean X-purgate-size: 2445 Convert the acpi OnOffAuto property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/arm/virt.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 0d56197dacee..0da10b799cfb 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -73,7 +73,7 @@ #include "whpx_arm.h" #include "hw/firmware/smbios.h" #include "qapi/visitor.h" -#include "qapi/qapi-visit-common.h" +#include "qapi/qapi-type-infos-common.h" #include "qobject/qlist.h" #include "standard-headers/linux/input.h" #include "hw/arm/smmuv3.h" @@ -3565,21 +3565,16 @@ bool virt_is_acpi_enabled(const VirtMachineState *vms) return true; } -static void virt_get_acpi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int virt_get_acpi(Object *obj, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(obj); - OnOffAuto acpi = vms->acpi; - - visit_type_OnOffAuto(v, name, &acpi, errp); + return vms->acpi; } -static void virt_set_acpi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void virt_set_acpi(Object *obj, int value, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &vms->acpi, errp); + vms->acpi = value; } static bool virt_get_ras(Object *obj, Error **errp) @@ -4207,11 +4202,13 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) mc->default_ram_id = "mach-virt.ram"; mc->default_nic = "virtio-net-pci"; - object_class_property_add(oc, "acpi", "OnOffAuto", - virt_get_acpi, virt_set_acpi, - NULL, NULL); - object_class_property_set_description(oc, "acpi", - "Enable ACPI"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "acpi", + .description = "Enable ACPI", + .qapi_type = &OnOffAuto_type_info, + .get = virt_get_acpi, + .set = virt_set_acpi, + )); object_class_property_add_bool(oc, "secure", virt_get_secure, virt_set_secure); object_class_property_set_description(oc, "secure", -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455310.1668972 (Exim 4.92) (envelope-from ) id 1xJ7W0-0003p3-P2; Tue, 20 Oct 2026 10:56:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455310.1668972; Tue, 20 Oct 2026 10:56: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 1xJ7Vz-0003lW-S2; Tue, 20 Oct 2026 10:56:19 +0000 Received: by outflank-mailman (input) for mailman id 1455310; Tue, 20 Oct 2026 10:50:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7QX-0008SN-R1 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7QX-00HRtL-7a for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:41 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7477b-e002-0a2a0a5209dd-0a2a450ac7d0-18 for ; Tue, 20 Oct 2026 12:50:41 +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 6ad746cb-f2d2-0a2a450a0019-aa0a817c6749-3 for ; Tue, 20 Oct 2026 12:47:40 +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-ofFqrjFmNVuI0_Rhk-bdPQ-1; Tue, 20 Oct 2026 10:47:36 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C6E151955F2B; Tue, 20 Oct 2026 10:47:31 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B32B31956089; Tue, 20 Oct 2026 10:47: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=1792493259; 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=xIOxZR09tVRL3LoeQ2VRl9bxdzxaCKN+MMqdzDBpGyw=; b=KaWZWAvuU3i6WT/33/tFs0Zu9uqcKTv9JPWvnAzqLH/ekNIQvzzBzbw5/t+WQG6+gszsdW p3fiDEHcxfRw3UiaJpXuYm1AKDQia4yGtBoJ8TP0wPDs+jm2KrbdGz/EVnIhKr2oBIDOL+ 6n+A7ELc4UxVCpz40noodKo4AtQc7rE= X-MC-Unique: ofFqrjFmNVuI0_Rhk-bdPQ-1 X-Mimecast-MFC-AGG-ID: ofFqrjFmNVuI0_Rhk-bdPQ_1792493252 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:31 +0400 Subject: [PATCH v7 14/65] qom/qmp: populate description & default-value in qom_property_info() MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-14-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2485; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=uHhhGddxQUOPXHn3kN1zjJ5emGyO+zAsacCmEIp7fMU=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYLHL/+jjl6D3jfhu6YY8r0v/h+oK3dZuqT ezvQZmL6dCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5aAaD/48dANrC6kyut3XOROjrQRxjwUIv0i0xWNW1n7ucgCFOO9+fWLOIuRBmElFO8tK1LUW7VK /cncnMEOpfNGGxBqlK4/E7MLLWxcEJ5PONbxrrynUEl5/6iktSG9+p0FbZ+69Ig8sBSWsaKMfX/ TjixcX9RrpcR4kM6W9+KDi3doDCw2opXnVXJs1dfbDHber2cptUgcPZg2klCeonD69YCtbh4E9V frLj2F6fhDEwXovHE9dmaAYXrx4MUlWNnWXF7Ghho/OQ4AT803/e68yxS2d9vGvR6oW5buPzIu1 mlrM9vteISWAcBit+HYHv2uAYbAEKeadp5Ifyen2Y9sH0dNkfWUPOKHL3vno7uRTfS18hxD4e86 26PatMtqKUJup7iwHq5V9QigizN31NfbU5AoBe12vGQ+E4qUTFiii1meZ1Syaz0HEsBut5DlGZB jKTxA5YXNzKXzh2gMr+EtfsPvTLms/u/oHjnzmZgwDvCIzLlT/lSl87AwFbhpHDBguQjcfTQ0Mg K1VhLdp03W/CZAUX9UALGzwbqu8DJbYjRo9rTfwd+PDdexNm4+dmZiWa48aQpfFwu3KSXV4xnXK BbNdAPMgYnoyiVVLq2Hy2zHqhvba3qJkOIDNjbbdfwMBrbGOpIDzaSUIS939LVbTmE62eCGjZ/p HPrxdrpQOIPKiOQ== 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: FeVsWjfg37di_klvrJYx_7uFtzdaewDopNYqLE3-ttk_1792493252 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1792493260-4ACDBCFC-02A7C6A7/0/0 X-purgate-type: clean X-purgate-size: 2487 Move description and default_value population from the individual QMP handlers into qom_property_info(), so all callers get them. This also adds description and default-value to qom-list responses, which previously only returned name and type. The handler doesn't care. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- qom/qom-qmp-cmds.c | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c index 47bf3bf2937a..84a295905148 100644 --- a/qom/qom-qmp-cmds.c +++ b/qom/qom-qmp-cmds.c @@ -35,6 +35,8 @@ static ObjectPropertyInfo *qom_property_info(ObjectProperty *prop) info->name = g_strdup(prop->name); info->type = g_strdup(prop->type); + info->description = g_strdup(prop->description); + info->default_value = qobject_ref(prop->defval); if (prop->qapi_type) { assert(prop->qapi_type->masked_name); info->qapi_type = g_strdup(prop->qapi_type->masked_name); @@ -243,8 +245,6 @@ ObjectPropertyInfoList *qmp_device_list_properties(const char *typename, object_property_iter_init(&iter, obj); while ((prop = object_property_iter_next(&iter))) { - ObjectPropertyInfo *info; - /* Skip Object and DeviceState properties */ if (strcmp(prop->name, "type") == 0 || strcmp(prop->name, "realized") == 0 || @@ -254,11 +254,7 @@ ObjectPropertyInfoList *qmp_device_list_properties(const char *typename, continue; } - info = qom_property_info(prop); - info->description = g_strdup(prop->description); - info->default_value = qobject_ref(prop->defval); - - QAPI_LIST_PREPEND(prop_list, info); + QAPI_LIST_PREPEND(prop_list, qom_property_info(prop)); } object_unref(obj); @@ -295,12 +291,7 @@ ObjectPropertyInfoList *qmp_qom_list_properties(const char *typename, object_property_iter_init(&iter, obj); } while ((prop = object_property_iter_next(&iter))) { - ObjectPropertyInfo *info = qom_property_info(prop); - - info->description = g_strdup(prop->description); - info->default_value = qobject_ref(prop->defval); - - QAPI_LIST_PREPEND(prop_list, info); + QAPI_LIST_PREPEND(prop_list, qom_property_info(prop)); } object_unref(obj); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455311.1668978 (Exim 4.92) (envelope-from ) id 1xJ7W2-00049o-Bt; Tue, 20 Oct 2026 10:56:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455311.1668978; Tue, 20 Oct 2026 10:56: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 1xJ7W1-00043p-D0; Tue, 20 Oct 2026 10:56:21 +0000 Received: by outflank-mailman (input) for mailman id 1455311; Tue, 20 Oct 2026 10:50:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7QY-0008T2-Af for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7QX-004d16-NY for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74765-8faa-0a2a0a5109dd-0a2a450b8d4a-48 for ; Tue, 20 Oct 2026 12:50:41 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad74744-b7e8-0a2a450b0019-aa0a817cc801-3 for ; Tue, 20 Oct 2026 12:49: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-533-OoWhFoGcPlaWpGKQnrYdqg-1; Tue, 20 Oct 2026 10:49:38 +0000 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DEDA7180056E; Tue, 20 Oct 2026 10:49:34 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id F20721956095; Tue, 20 Oct 2026 10:49: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=1792493380; 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=pJsKiDwP7cQjHHYkeJJ5It1m2SB+6i/Xk0ZLXrFcWgM=; b=BLQHVwSP4y4yzoziJP2D0gjyTzL+idpS0aU1x4+ElIIkjLX63goWhyZ4XHfWKbps/inmX4 rno6TW/C4lKJzW3t0FnT0TpTZjiAcMbwB3KE7gEXa56L6D0GVFnmd/JNUBWG30uGc+y9KI 5ddxpKlNqRk2K2yzw4ZiRaE8lBBBZ9A= X-MC-Unique: OoWhFoGcPlaWpGKQnrYdqg-1 X-Mimecast-MFC-AGG-ID: OoWhFoGcPlaWpGKQnrYdqg_1792493375 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:54 +0400 Subject: [PATCH v7 37/65] hw/misc/xlnx-versal-trng: add missing getter for fips-fault-events MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-37-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1222; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=2e+J+3h+NUPhMCTdhI0KGfNu+o02kfLWSTEk2RShPvY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaaRUiZcgxP4oeKcbE8gs+UJl28BKoajpQ9 8TC/3Dz3TSJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5XzVD/4vu1/c4/2gcCv9WZzxVogHqWbTFYkuxZ02zog+1m/pXb+X9tvwReTfeI9FydQAbiZpvId gteOK6+wAlg83zfJniCoLV7jtP+dM5FXb46UnupVcgv/SpBK4D2RejZAEufi29iApBO2oMfn9MA 3gfevxd7THNtXegKa7wKxruBeVPEYPFhEync0+DH6wgg9EKaD4+GFKqqZ1aFNfaCLt7UzUsP7Io b9+cbToEVKKLoDEBVL7pnuO/RzwrBYxdHtsto9XcDx8y4g00K8cmochz1vpOtUh1O6/aPjsDzwK lKyeCMpsv+EwbyDSx+RRGeRZoQL3XRTFUrpQmhchGFQcMAfKsHMqjtEKGrCcBGzulk4EhNmKESi edlb7NLs0r0skfsaaxWorKW1rpeiTEEy7alnw7IdbIUqKy3rnu3rveuxXewnTcB5bnsDrNxwMVM RJ1A+85E1foSNRMRMPCuJRAvBFVzYYCaInFNaD07ePzVfR7vR1R636oNhc5efIWcOKbTVs3dJXz FKOIZkVWdXxVmQbuvftuGvvca4rYARfHdC0A54iqWotUPHpfdcW7NJx6aWHAQ7T4HiH7zy6MznP 41E815xj58W8vZEWWlZSmcwXiUWFv7br2GVoiGXDN/GV9hh7gLgW1P2qn3CFsh0+V4JLm81THXE KiNpEqL9FN+vZmA== 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-MFC-PROC-ID: JS-yoMsrphmC7hWTtUOO9oIwz0MOA-XNXFfl1Hp0gWk_1792493375 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493381-2C59A9EA-E1C400D4/0/0 X-purgate-type: clean X-purgate-size: 1224 Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/misc/xlnx-versal-trng.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/hw/misc/xlnx-versal-trng.c b/hw/misc/xlnx-versal-trng.c index aa1d65de7b70..0584ee089e3c 100644 --- a/hw/misc/xlnx-versal-trng.c +++ b/hw/misc/xlnx-versal-trng.c @@ -650,10 +650,22 @@ static void trng_prop_fault_event_set(Object *obj, Visitor *v, trng_fault_event_set(XLNX_VERSAL_TRNG(obj), *events); } +static void trng_prop_fault_event_get(Object *obj, Visitor *v, + const char *name, + void *opaque, + Error **errp) +{ + const Property *prop = opaque; + uint32_t *events = object_field_prop_ptr(obj, prop); + + visit_type_uint32(v, name, events, errp); +} + static const PropertyInfo trng_prop_fault_events = { .type = "uint32", .description = "Set to trigger TRNG fault events", .set = trng_prop_fault_event_set, + .get = trng_prop_fault_event_get, .realized_set_allowed = true, }; -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455312.1668991 (Exim 4.92) (envelope-from ) id 1xJ7W4-0004al-S5; Tue, 20 Oct 2026 10:56:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455312.1668991; Tue, 20 Oct 2026 10: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 1xJ7W3-0004Ui-JT; Tue, 20 Oct 2026 10:56:23 +0000 Received: by outflank-mailman (input) for mailman id 1455312; Tue, 20 Oct 2026 10:50:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7QY-0008T3-J6 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7QY-002FRA-03 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:42 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74779-bab6-0a2a0a5309dd-0a2a4502e220-30 for ; Tue, 20 Oct 2026 12:50:41 +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 6ad74780-6ca4-0a2a45020019-aa0a857c9cdd-3 for ; Tue, 20 Oct 2026 12:50:41 +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-694-nPrkmqWhMXen_3R1vU7oZw-1; Tue, 20 Oct 2026 10:50:34 +0000 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 06E3A1805A18; Tue, 20 Oct 2026 10:50:30 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D157218005B8; Tue, 20 Oct 2026 10:50: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=1792493440; 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=wDKqI9lxsJYOWv5oXkIIVMolronNVooZmn3jjB1NaoM=; b=JnSpf3wkoHQHHOIAZ6Y9OpdY5+3qdd/WVTpPWP2/pBk31YNgGDzJLoiiCvAm2aBDxBcbNq wOVT2Vvgn9/FBcozigME5XA3dxwUym/aBfkPuC6Xwb6xUKKZqM9WRiO8Ia889aTJfSIid0 VjvCKp7r82Zl8AC+PX7K9F1hSI9pnZk= X-MC-Unique: nPrkmqWhMXen_3R1vU7oZw-1 X-Mimecast-MFC-AGG-ID: nPrkmqWhMXen_3R1vU7oZw_1792493430 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:04 +0400 Subject: [PATCH v7 47/65] hw/s390x: convert BootCertificatesList to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-47-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1505; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=wdbhYWD/vf672j0phUbR1cOU3kwkLl3/cupZ0YaTznU=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZbDkYgPj0HDzsA3Y34WzGHrPrDPeDHvzd0l wPaLOFmX3WJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5QyFD/0b7xA4ChrYMo5WcQsrtlQZqCXFanjHmndWojPNq6E6DJrh7yNweRlM5B8GO8az5oyA75h sUttRiBWYNvMnlgXQtH/nE8T96ywsGyTT9ZInHttlzN9P5Fh5Kr/SqOcHkuYj6mXh4Qo8l9kpkX 5Ls7K8Ke23byTyibodkbaedkpfdM3EpJ3hzQ5r3Cbp68RrQqxPRAGGe+DEVXyTzCaUIrg/oKuKl ee+1owd49sj/oDWlsbQ8JKwkl9rM61yJQqCHZ/8bYXLsQ8Sy+lP6fJkHm9Ng4C2rM7dDW0wPeZJ /AnxrnFDz+SaS70Z+Q7qSIRHxareyWZJA0rnKOl82n26hwJ2mAFFTibkJxJPdnojLqX+mWBzWUU 61jumL2L/vI6Hbuh3iO7YnsdjYk+RAjIYNyc/LVGHWFYLkgevtNRkvL4bo4c8ILFq/kfEbpOOX9 IJctXj/7n79Sx62wNtTjV3Wmenr+zMkYIemOn14uqf9VuXdkB0ih5iiJgO031WJpDUGUW/l3UO0 Nt1goAs8YdyzC1w+yD/OBemcsUJMxG2IKhcXMBoyjQtwO1hYYX+0qqyxosT72NLiOrgKTvIWx/C AamF9QKFFgHdWVkuKlqIBCfed1sEkedvwsLa07Bik/rEdPJdSrKHrHCPDZ9x/Q5r3QVwD+zyVVq V10wnjLfSGUrDTg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: utdPST58jF8PmTWVmLhvTFx64KcObVXir9opW5y0A2w_1792493430 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1792493441-676BF2AC-68B38349/0/0 X-purgate-type: clean X-purgate-size: 1507 Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/s390x/s390-virtio-ccw.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 3ed425b16c3e..8bc09c179552 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -44,6 +44,7 @@ #include "target/s390x/kvm/pv.h" #include "migration/blocker.h" #include "qapi/qapi-builtin-type-infos.h" +#include "qapi/qapi-type-infos-machine-s390x.h" #include "qapi/visitor.h" #include "qapi/qapi-visit-machine-s390x.h" #include "hw/s390x/cpu-topology.h" @@ -918,8 +919,10 @@ static void ccw_machine_class_init(ObjectClass *oc, const void *data) " to upper case) to pass to machine loader, boot manager," " and guest kernel"); - object_class_property_add(oc, "boot-certs", "BootCertificatesList", - machine_get_boot_certs, machine_set_boot_certs, NULL, NULL); + object_class_property_add_qapi(oc, "boot-certs", + &BootCertificatesList_type_info, + machine_get_boot_certs, + machine_set_boot_certs, NULL, NULL); object_class_property_set_description(oc, "boot-certs", "provide paths to a directory and/or a certificate file for secure boot"); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455316.1668997 (Exim 4.92) (envelope-from ) id 1xJ7W6-0004vW-Il; Tue, 20 Oct 2026 10:56:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455316.1668997; Tue, 20 Oct 2026 10:56: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 1xJ7W5-0004n4-Kq; Tue, 20 Oct 2026 10:56:25 +0000 Received: by outflank-mailman (input) for mailman id 1455316; Tue, 20 Oct 2026 10:50:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qd-0008Ua-08 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qc-004d16-DC for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74772-8faa-0a2a0a5109dd-0a2a4501af7a-44 for ; Tue, 20 Oct 2026 12:50:46 +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 6ad74785-5984-0a2a45010019-aa0a817cd663-3 for ; Tue, 20 Oct 2026 12:50:46 +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-589-Nf-L8n-POp-Ce5Q3K4PxmQ-1; Tue, 20 Oct 2026 10:50:39 +0000 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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BCEDD1800846; Tue, 20 Oct 2026 10:50:35 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7AC121800643; Tue, 20 Oct 2026 10:50: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=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=1792493444; 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=qwky9rRTw8oAHcuQCucWGoFZKa5DrHxcGAirH7r71y0=; b=IPHu8QiVTsVREFNzvpxqRWJ5kpgS1hMLyiPLkyDn6tseFZFhs3kUudzTJpGQIDTkUIxTOk tmWKOIb70DWUH4bBWU2nQRr2Ptj6z+UAPQLst4l0YNOzVJOpnkvRXAbv923oDk0mJZKbQY SA7+MkNwMf4KTFlD6mugXrRGAqhD/CU= X-MC-Unique: Nf-L8n-POp-Ce5Q3K4PxmQ-1 X-Mimecast-MFC-AGG-ID: Nf-L8n-POp-Ce5Q3K4PxmQ_1792493435 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:05 +0400 Subject: [PATCH v7 48/65] hw/gpio/pca955x: use QAPI enums for led and pin properties MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-48-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=15047; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=N091Shg2JHcPog3qa/YLAcE9hWHktbmtx29N6CIdf6Y=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZbJcXMYrMMXfr6szUmvgOQEfgL142iqUKd5 YT6P0Nj+9+JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5Y1YEAC7Jjf0CNAuzPG1AoI6lNR1KKO2PD4cPsq5GQornKbm+OrFX6OdHOWVRiNy9yshRki5VHt y1UIfWtv5lVJuPfzIgFkDFdGGFqhZ5SX0+7I6l66rkSAPfQ9MYYZRi289uk6B2/arJH7Z5EFSKu iGlcGVQc9S4x3c/Kg1PtMxGhPvrXr76hSgtXid7nFld1/V2cAMfUm0M6Vr6yAb7Lul5Rp3r/caN cCC0tt6RzA9y+QM8LZnrQwFHhW7YHTh58dM4yXW5D3r/njyP8n3g0XYR1Jim0YTWx3z3PJWUMuE GxUCHw92BCWEbbwDilX7tms1L3KPst0YiZ7RL79JHKJb9xCAa6jVwQsv584lT0mhe1F1Ogonqkn NDkBOXyzBbvt79Pyn0stvJKsMla/XLny8sSa8o3wQZRTjd10guCFqF+CAbeX5XwrWLig/kslQgi jmNCSeNgdwl+kFZJQ3Glx9hD55WBtmbMVgakjAAfk2GP44aEKIPJ0c9xGjUtf4jdsQHElwlk3dc 2IUG2VKR7vs+3NqwHkSYoCEk4c5P7Y42OJuYcXbXlU5s45IJDDbzPXqMdfHHkLd94cf/XE2iFHx E+2DhjzzNnw3c3Sr3XpRdw/jiWTPqEjBMSGCfy/ObEFvsn6BTov7EsqvWS6VL9qe04p2/+GTroa X35jn64JCYgndcQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: dNcVM2fCgkWhu22-AcrWY6KpHIE_1zbgCeuWl94dHYc_1792493435 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792493446-1E664757-7A7EDC81/0/0 X-purgate-type: clean X-purgate-size: 15049 Replace hand-rolled string lookup tables with QAPI enums Pca9552LedState and Pca955{2,4}PinState for the led%d and pin%d QOM properties. This fixes the incorrect property type ("bool" for LEDs, "str" for pins) and lets QAPI handle string-to-enum conversion in the visitor, removing the manual string matching in the setters. Add QEMU_BUILD_BUG_ON guards to ensure the QAPI-generated enum values stay in sync with the hardware register encoding. I kept Pca9552PinState & @Pca9554PinState separate types, because I don't know if they could diverge. We could eventually merge those. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/gpio/pca9552.c | 82 +++++++++++++++++++++---------------------------------- hw/gpio/pca9554.c | 39 ++++++++++---------------- qapi/machine.json | 46 +++++++++++++++++++++++++++++++ 3 files changed, 92 insertions(+), 75 deletions(-) diff --git a/hw/gpio/pca9552.c b/hw/gpio/pca9552.c index 719149b7174b..16741c22dea3 100644 --- a/hw/gpio/pca9552.c +++ b/hw/gpio/pca9552.c @@ -23,7 +23,8 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" -#include "qapi/visitor.h" +#include "qapi/qapi-types-machine.h" +#include "qapi/qapi-visit-machine.h" #include "trace.h" #include "qom/object.h" @@ -59,16 +60,15 @@ struct PCA955xClass { /* * Note: The LED_ON and LED_OFF configuration values for the PCA955X * chips are the reverse of the PCA953X family of chips. + * + * The QAPI enums must match the hardware register values. */ -#define PCA9552_LED_ON 0x0 -#define PCA9552_LED_OFF 0x1 -#define PCA9552_LED_PWM0 0x2 -#define PCA9552_LED_PWM1 0x3 -#define PCA9552_PIN_LOW 0x0 -#define PCA9552_PIN_HIZ 0x1 - -static const char *led_state[] = {"on", "off", "pwm0", "pwm1"}; -static const char *pin_state[] = {"low", "high"}; +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_ON != 0x0); +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_OFF != 0x1); +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_PWM0 != 0x2); +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_PWM1 != 0x3); +QEMU_BUILD_BUG_ON(PCA9552_PIN_STATE_LOW != 0x0); +QEMU_BUILD_BUG_ON(PCA9552_PIN_STATE_HIGH != 0x1); static uint8_t pca955x_pin_get_config(PCA955xState *s, int pin) { @@ -142,24 +142,24 @@ static void pca955x_update_pin_input(PCA955xState *s) uint8_t config = pca955x_pin_get_config(s, i); switch (config) { - case PCA9552_LED_ON: + case PCA9552_LED_STATE_ON: /* Pin is set to 0V to turn on LED */ s->regs[input_reg] &= ~bit_mask; break; - case PCA9552_LED_OFF: + case PCA9552_LED_STATE_OFF: /* * Pin is set to Hi-Z to turn off LED and * pullup sets it to a logical 1 unless * external device drives it low. */ - if (s->ext_state[i] == PCA9552_PIN_LOW) { + if (s->ext_state[i] == PCA9552_PIN_STATE_LOW) { s->regs[input_reg] &= ~bit_mask; } else { s->regs[input_reg] |= bit_mask; } break; - case PCA9552_LED_PWM0: - case PCA9552_LED_PWM1: + case PCA9552_LED_STATE_PWM0: + case PCA9552_LED_STATE_PWM1: /* TODO */ default: break; @@ -176,7 +176,7 @@ static void pca955x_update_pin_input(PCA955xState *s) */ if (s->regs[config_reg] & bit_mask) { /* Input mode - reflect external state */ - if (s->ext_state[i] == PCA9552_PIN_LOW) { + if (s->ext_state[i] == PCA9552_PIN_STATE_LOW) { s->regs[input_reg] &= ~bit_mask; } else { s->regs[input_reg] |= bit_mask; @@ -360,7 +360,7 @@ static void pca955x_get_led(Object *obj, Visitor *v, const char *name, PCA955xClass *k = PCA955X_GET_CLASS(obj); PCA955xState *s = PCA955X(obj); int led, rc, reg; - uint8_t state; + Pca9552LedState state; rc = sscanf(name, "led%2d", &led); if (rc != 1) { @@ -378,7 +378,7 @@ static void pca955x_get_led(Object *obj, Visitor *v, const char *name, */ reg = PCA9552_LS0 + led / 4; state = (pca955x_read(s, reg) >> ((led % 4) * 2)) & 0x3; - visit_type_str(v, name, (char **)&led_state[state], errp); + visit_type_Pca9552LedState(v, name, &state, errp); } /* @@ -397,10 +397,9 @@ static void pca955x_set_led(Object *obj, Visitor *v, const char *name, PCA955xClass *k = PCA955X_GET_CLASS(obj); PCA955xState *s = PCA955X(obj); int led, rc, reg, val; - uint8_t state; - g_autofree char *state_str = NULL; + Pca9552LedState state; - if (!visit_type_str(v, name, &state_str, errp)) { + if (!visit_type_Pca9552LedState(v, name, &state, errp)) { return; } rc = sscanf(name, "led%2d", &led); @@ -413,16 +412,6 @@ static void pca955x_set_led(Object *obj, Visitor *v, const char *name, return; } - for (state = 0; state < ARRAY_SIZE(led_state); state++) { - if (!strcmp(state_str, led_state[state])) { - break; - } - } - if (state >= ARRAY_SIZE(led_state)) { - error_setg(errp, "%s invalid led state %s", __func__, state_str); - return; - } - reg = PCA9552_LS0 + led / 4; val = pca955x_read(s, reg); val = pca955x_ledsel(val, led % 4, state); @@ -437,7 +426,8 @@ static void pca955x_get_pin(Object *obj, Visitor *v, const char *name, PCA955xClass *k = PCA955X_GET_CLASS(obj); PCA955xState *s = PCA955X(obj); int pin, rc; - uint8_t input_reg, state; + uint8_t input_reg; + Pca9552PinState state; rc = sscanf(name, "pin%2d", &pin); if (rc != 1) { @@ -455,7 +445,7 @@ static void pca955x_get_pin(Object *obj, Visitor *v, const char *name, */ input_reg = PCA9535_INPUT0 + (pin / 8); state = (s->regs[input_reg] >> (pin % 8)) & 0x1; - visit_type_str(v, name, (char **)&pin_state[state], errp); + visit_type_Pca9552PinState(v, name, &state, errp); } static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, @@ -464,10 +454,10 @@ static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, PCA955xClass *k = PCA955X_GET_CLASS(obj); PCA955xState *s = PCA955X(obj); int pin, rc; - uint8_t state, config_reg; - g_autofree char *state_str = NULL; + Pca9552PinState state; + uint8_t config_reg; - if (!visit_type_str(v, name, &state_str, errp)) { + if (!visit_type_Pca9552PinState(v, name, &state, errp)) { return; } rc = sscanf(name, "pin%2d", &pin); @@ -480,16 +470,6 @@ static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, return; } - for (state = 0; state < ARRAY_SIZE(pin_state); state++) { - if (!strcmp(state_str, pin_state[state])) { - break; - } - } - if (state >= ARRAY_SIZE(pin_state)) { - error_setg(errp, "%s invalid pin state %s", __func__, state_str); - return; - } - /* Only input-configured pins can be driven by an external device. */ config_reg = PCA9535_CONFIG0 + (pin / 8); if (!((s->regs[config_reg] >> (pin % 8)) & 0x1)) { @@ -499,7 +479,7 @@ static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, return; } - pca955x_set_ext_state(s, pin, state != PCA9552_PIN_LOW); + pca955x_set_ext_state(s, pin, state != PCA9552_PIN_STATE_LOW); } static const VMStateDescription pca9552_vmstate = { @@ -529,7 +509,7 @@ static void pca9552_reset_hold(Object *obj, ResetType type) s->regs[PCA9552_LS2] = 0x55; s->regs[PCA9552_LS3] = 0x55; - memset(s->ext_state, PCA9552_PIN_HIZ, PCA955X_PIN_COUNT_MAX); + memset(s->ext_state, PCA9552_PIN_STATE_HIGH, PCA955X_PIN_COUNT_MAX); pca955x_update_pin_input(s); s->pointer = 0xFF; @@ -549,7 +529,7 @@ static void pca9535_reset_hold(Object *obj, ResetType type) s->regs[PCA9535_CONFIG0] = 0xFF; /* All pins as inputs */ s->regs[PCA9535_CONFIG1] = 0xFF; /* All pins as inputs */ - memset(s->ext_state, PCA9552_PIN_HIZ, PCA955X_PIN_COUNT_MAX); + memset(s->ext_state, PCA9552_PIN_STATE_HIGH, PCA955X_PIN_COUNT_MAX); pca955x_update_pin_input(s); s->pointer = 0xFF; @@ -567,12 +547,12 @@ static void pca955x_initfn(Object *obj) if (k->has_led_support) { /* LED variant: expose the LED selector state as led%d. */ name = g_strdup_printf("led%d", ix); - object_property_add(obj, name, "bool", + object_property_add(obj, name, "Pca9552LedState", pca955x_get_led, pca955x_set_led, NULL, NULL); } else { /* GPIO variant: expose the pin logic level as pin%d. */ name = g_strdup_printf("pin%d", ix); - object_property_add(obj, name, "str", + object_property_add(obj, name, "Pca9552PinState", pca955x_get_pin, pca955x_set_pin, NULL, NULL); } g_free(name); diff --git a/hw/gpio/pca9554.c b/hw/gpio/pca9554.c index 904698cdce85..e4eddc829ef7 100644 --- a/hw/gpio/pca9554.c +++ b/hw/gpio/pca9554.c @@ -16,6 +16,8 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-types-machine.h" +#include "qapi/qapi-visit-machine.h" #include "qapi/visitor.h" #include "trace.h" #include "qom/object.h" @@ -32,10 +34,8 @@ typedef struct PCA9554Class PCA9554Class; DECLARE_CLASS_CHECKERS(PCA9554Class, PCA9554, TYPE_PCA9554) -#define PCA9554_PIN_LOW 0x0 -#define PCA9554_PIN_HIZ 0x1 - -static const char *pin_state[] = {"low", "high"}; +QEMU_BUILD_BUG_ON(PCA9554_PIN_STATE_LOW != 0x0); +QEMU_BUILD_BUG_ON(PCA9554_PIN_STATE_HIGH != 0x1); static void pca9554_update_pin_input(PCA9554State *s) { @@ -54,7 +54,7 @@ static void pca9554_update_pin_input(PCA9554State *s) * Input: the pin is Hi-Z with a pull-up, so it reads high * unless an external device drives it low. */ - if (s->ext_state[i] == PCA9554_PIN_LOW) { + if (s->ext_state[i] == PCA9554_PIN_STATE_LOW) { s->regs[PCA9554_INPUT] &= ~bit_mask; } else { s->regs[PCA9554_INPUT] |= bit_mask; @@ -156,7 +156,7 @@ static void pca9554_get_pin(Object *obj, Visitor *v, const char *name, { PCA9554State *s = PCA9554(obj); int pin, rc; - uint8_t state; + Pca9554PinState state; rc = sscanf(name, "pin%2d", &pin); if (rc != 1) { @@ -175,7 +175,7 @@ static void pca9554_get_pin(Object *obj, Visitor *v, const char *name, * holds the wire level regardless of the configured direction. */ state = (s->regs[PCA9554_INPUT] >> pin) & 0x1; - visit_type_str(v, name, (char **)&pin_state[state], errp); + visit_type_Pca9554PinState(v, name, &state, errp); } static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, @@ -183,10 +183,10 @@ static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, { PCA9554State *s = PCA9554(obj); int pin, rc, val; - uint8_t state, mask; - g_autofree char *state_str = NULL; + uint8_t mask; + Pca9554PinState state; - if (!visit_type_str(v, name, &state_str, errp)) { + if (!visit_type_Pca9554PinState(v, name, &state, errp)) { return; } rc = sscanf(name, "pin%2d", &pin); @@ -199,16 +199,6 @@ static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, return; } - for (state = 0; state < ARRAY_SIZE(pin_state); state++) { - if (!strcmp(state_str, pin_state[state])) { - break; - } - } - if (state >= ARRAY_SIZE(pin_state)) { - error_setg(errp, "%s invalid pin state %s", __func__, state_str); - return; - } - if (s->hw_dir) { /* Warn and ignore if the guest has configured this pin as output */ if (!((s->regs[PCA9554_CONFIG] >> pin) & 0x1)) { @@ -219,13 +209,13 @@ static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, return; } /* Drive the external input level */ - pca9554_set_ext_state(s, pin, state != PCA9554_PIN_LOW); + pca9554_set_ext_state(s, pin, state != PCA9554_PIN_STATE_LOW); } else { /* Legacy behavior: force output mode and drive */ /* First, modify the output register bit */ val = pca9554_read(s, PCA9554_OUTPUT); mask = 0x1 << pin; - if (state == PCA9554_PIN_LOW) { + if (state == PCA9554_PIN_STATE_LOW) { val &= ~(mask); } else { val |= mask; @@ -264,7 +254,7 @@ static void pca9554_reset(DeviceState *dev) s->regs[PCA9554_POLARITY] = 0x0; /* No pins are inverted */ s->regs[PCA9554_CONFIG] = pin_mask; /* All pins are inputs */ - memset(s->ext_state, PCA9554_PIN_HIZ, pc->pin_count); + memset(s->ext_state, PCA9554_PIN_STATE_HIGH, pc->pin_count); pca9554_update_pin_input(s); s->pointer = 0x0; @@ -280,7 +270,8 @@ static void pca9554_initfn(Object *obj) char *name; name = g_strdup_printf("pin%d", pin); - object_property_add(obj, name, "str", pca9554_get_pin, pca9554_set_pin, + object_property_add(obj, name, "Pca9554PinState", + pca9554_get_pin, pca9554_set_pin, NULL, NULL); g_free(name); } diff --git a/qapi/machine.json b/qapi/machine.json index 34be3156270c..46b6935ab0b8 100644 --- a/qapi/machine.json +++ b/qapi/machine.json @@ -416,6 +416,52 @@ { 'enum': 'LostTickPolicy', 'data': ['discard', 'delay', 'slew' ] } +## +# @Pca9552LedState: +# +# LED state for PCA9552. +# +# @on: LED on +# +# @off: LED off +# +# @pwm0: LED controlled by PWM0 +# +# @pwm1: LED controlled by PWM1 +# +# Since: 11.2 +## +{ 'enum': 'Pca9552LedState', + 'data': ['on', 'off', 'pwm0', 'pwm1'] } + +## +# @Pca9552PinState: +# +# Pin state for PCA9552. +# +# @low: Pin low +# +# @high: Pin high +# +# Since: 11.2 +## +{ 'enum': 'Pca9552PinState', + 'data': ['low', 'high'] } + +## +# @Pca9554PinState: +# +# Pin state for PCA9554. +# +# @low: Pin low +# +# @high: Pin high +# +# Since: 11.2 +## +{ 'enum': 'Pca9554PinState', + 'data': ['low', 'high'] } + ## # @inject-nmi: # Injects a Non-Maskable Interrupt (machine specific: for example -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455317.1669008 (Exim 4.92) (envelope-from ) id 1xJ7W8-0005DX-BG; Tue, 20 Oct 2026 10:56:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455317.1669008; Tue, 20 Oct 2026 10:56: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 1xJ7W7-0005AO-17; Tue, 20 Oct 2026 10:56:27 +0000 Received: by outflank-mailman (input) for mailman id 1455317; Tue, 20 Oct 2026 10:50:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qd-0008Uf-HD for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qc-00Crdk-UE for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:46 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7477c-2eae-0a2a0a5409dd-0a2a4507e786-16 for ; Tue, 20 Oct 2026 12:50:46 +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 6ad746d1-b4ea-0a2a45070019-aa0a857c7e31-3 for ; Tue, 20 Oct 2026 12:47:46 +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-98-b50LkXhBNAOr4KDZgzOCJQ-1; Tue, 20 Oct 2026 06:47:41 -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 0944C1955F10; Tue, 20 Oct 2026 10:47:37 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2487E418; Tue, 20 Oct 2026 10:47: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=1792493265; 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=+mUlmiLA0IUJrEFhhdtqFL7MoWyX2aJUgEr0fLN0OLI=; b=SS6C7+uEhqtNUXezaeMbtvhstrOQmCgu0s3y+3E+BtHv3tfr0kag5KFKHNhW3JBuYaaMH7 Z0y1/boFOo6SErFAGe6fIF0DeEZgXq7994YgT0jVxJTWqGW2UQzXaBnpBZ0xwyE3ennvma CgF8xSLirWR7345uZ+XW1dKTWwHGFUg= X-MC-Unique: b50LkXhBNAOr4KDZgzOCJQ-1 X-Mimecast-MFC-AGG-ID: b50LkXhBNAOr4KDZgzOCJQ_1792493257 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:32 +0400 Subject: [PATCH v7 15/65] qom: add object_property_set_default_enum() MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-15-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1741; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=bT9PbeYHomyeIGAcVfTDM+lJI5Y2hBOOffhp2f1n7bs=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZY3cZceXMTAsDTPVPQLUPiFXhCtfGOTuUzE ex7dEME5rOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5YB4D/9GPjvfJ9QnS3NS7uzoH3zuMz6cgmZWUWiCGV7tsWnNbbIfmXnGwpWDwpNzL9cRsohPRiM Tt8mSTGA/sJmszkK+oQShJ63FCmfW5pbd7ruMCtTStlRVh8rCjUWyx0b9IGf9lj7a1sXuaMjRiZ RmIstsYrcvq9fJ0J5SM1RTodk1Qvgn2pQe7pG/U8OW8Myg6fto5tvml4IN5pYuE4YB/AteIWUfl cy3Y6JisAPLbkZWEjeehnRqpYjs8lJcEc0jd6jT5Ajm3DFQFLMkmckRPpjNofoDbeN1tQ7K0s98 vwayy8xoutwUgsV9wX6qCvRBLY1+DpxNBTHm+xV32yF2estcn1ixmHngJQMaNbWwx3sJ0FueH2i nHGW2/UH0XkgcegNOKOcSppusTIisYEHOeK2W37dK7A4gv7fgemaMBfKADWuc6jN/xKP4O2sAOs EPPKK+R1nyzBdIIsDWdYkhnmUpz08PjAX7t/9zIyQvJy6HeZMYEvqH92Dv9Aqm0tKTwJeHGv8Mx G+jFxLb6K1GFyZQ9S6izdwx5JWqfiEfKijUzBP4iLHpB4BirgMYkk/bqayFVYZSlxI7iVj9lGda LEl9RmhNncJu8lNAZW9bmWSGo4Vlr/rpl4jKvIuRbcz2N62kMeZEEXIRFPUNBGeJNDW8b+FYyQK eIre7G+lNeX5Okw== 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: ZBBJlYuRB8K_9BoZJwGdjr0B2xJ0iydyhq8fqGlVnE4_1792493257 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1792493266-3C212AE4-4F2B330F/0/0 X-purgate-type: clean X-purgate-size: 1743 A simple helper to set the default enum value from the integer value. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- include/qom/object.h | 9 +++++++++ qom/object.c | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/include/qom/object.h b/include/qom/object.h index e9b380462ded..2a5723c555e9 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -1260,6 +1260,15 @@ void object_property_set_default_bool(ObjectProperty *prop, bool value); */ void object_property_set_default_str(ObjectProperty *prop, const char *value); +/** + * object_property_set_default_enum: + * @prop: the property to set + * @value: the value to be written to the property + * + * Set the property default value. + */ +void object_property_set_default_enum(ObjectProperty *prop, int value); + /** * object_property_set_default_list: * @prop: the property to set diff --git a/qom/object.c b/qom/object.c index c34b47312f29..1d09315b328b 100644 --- a/qom/object.c +++ b/qom/object.c @@ -1719,6 +1719,15 @@ void object_property_set_default_str(ObjectProperty *prop, const char *value) object_property_set_default(prop, QOBJECT(qstring_from_str(value))); } +void object_property_set_default_enum(ObjectProperty *prop, int value) +{ + assert(prop && prop->qapi_type && prop->qapi_type->lookup); + + object_property_set_default(prop, QOBJECT(qstring_from_str( + qapi_enum_lookup(prop->qapi_type->lookup, value) + ))); +} + void object_property_set_default_list(ObjectProperty *prop) { object_property_set_default(prop, QOBJECT(qlist_new())); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455318.1669018 (Exim 4.92) (envelope-from ) id 1xJ7W9-0005XL-Il; Tue, 20 Oct 2026 10:56:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455318.1669018; Tue, 20 Oct 2026 10:56: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 1xJ7W8-0005RV-K8; Tue, 20 Oct 2026 10:56:28 +0000 Received: by outflank-mailman (input) for mailman id 1455318; Tue, 20 Oct 2026 10:50:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qe-0008Um-PZ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qe-004d16-67 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:48 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74781-8faa-0a2a0a5109dd-0a2a4504a994-44 for ; Tue, 20 Oct 2026 12:50:48 +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 6ad74786-b57f-0a2a45040019-aa0a817c6709-3 for ; Tue, 20 Oct 2026 12:50:47 +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-689-7M2NqJufMDOobZCWpwZs9w-1; Tue, 20 Oct 2026 10:50:45 +0000 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5E3CE1954AF3; Tue, 20 Oct 2026 10:50:41 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4CA251956095; Tue, 20 Oct 2026 10:50: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=1792493446; 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=S8kTexksySb92RkWPQob17KtLeYJq8y0yNIndqLcc+s=; b=BIawTRzGLvx1avtBgI+2CzxYzP7GS/2Kj++TtBPLdzMuo/aypEovwbrGl6TahSumY596Cn 071ufiPwswGDnizIZZtkL2Nxd0AW8InkQzGIvUjt9sq3H2RwM+dy6IcFlViWZKvbT9sasm S32jN6KyezERGhoWxUp1dcp9t+R7v+k= X-MC-Unique: 7M2NqJufMDOobZCWpwZs9w-1 X-Mimecast-MFC-AGG-ID: 7M2NqJufMDOobZCWpwZs9w_1792493441 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:06 +0400 Subject: [PATCH v7 49/65] include: add QEMU_REPEAT helper macro MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-49-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=5069; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=QfToyuYJOLlF7sVISH3TkcbrVSBGm2Ii2KsCu8httjE=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZctD1NQTngqU/jBCkEfMek9xa0vMpb6NJE8 n3GhucWk+2JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5Ql3D/wOI62xjJd8gtsu1K015Mj1esGNk3N1OdLVzhvzC8XbQvPEjY9tEjanTvUT/tSDkebzQqp wfSbuNHZo2LWhz4d7Wb0804H4k/QbpWXXItKX82506hR5MwcSm8hUjY/X6b3sz99rcdsWT0OYuB N2PLFvmXrXrT34rd2lk3l9IEv008VGElWvHn+lGOsyEFdIi/zoDQuQTkGXQNX9r8iwDerholxzT +YZ5vO9NOWYzlEcvAPuA1dqTZKv0M9sHG++CE+6rKm7la2iiLolf0dIPC9Lek616L5XTeNy7Con EF8tZhpLovhA6XrZr2f/PiaJxHf5yCU0Sq0nNl8Fbybo63RLmGHKN3Eu3hwqRCLDy9l1/5v++ol S9hoHIJukwRZWnX0ts9nDy7TeFwjlL2jTa5zYCWg9W7/sdnOtFpaRYdj/lgqkMlTa+D86mUvx9a 9InKktX0yyqWi5G5hNKi9NOS0lo8H7z0cS/vAMcv16S106YylJ7/t+pIcH0uo8VsZZRuXZ7h/LE P4apvjyFIb53bu2HO5H2KfwPzrSgW8jM6CGO9+0RBtkG7nQ+6OYilLtspSRo2mGJD8ejzD5m8U6 /mj9N3MBuGZckwN2lJSTywe0n7qy4Ybb5v/f4A7HZtbB78gEulqlZppqsvIUcivzHg3tITYzqlL tsVVC+qXxIFzhWg== 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-MFC-PROC-ID: QhIwsYQSFdP_batAZoqWWBKJkzb2S8QHqhw6wpbOyAc_1792493441 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792493448-530CDB50-B313043F/0/0 X-purgate-type: clean X-purgate-size: 5071 Introduce a macro used in following commit, and convert a few existing candidates. Inspired by a similar macro in Linux kernel/trace/bpf_trace.c Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/misc/tz-ppc.c | 19 ++----------------- hw/remote/vfio-user-obj.c | 17 +++-------------- include/hw/cxl/cxl_component.h | 5 +---- include/qemu/osdep.h | 33 +++++++++++++++++++++++++++++++++ 4 files changed, 39 insertions(+), 35 deletions(-) diff --git a/hw/misc/tz-ppc.c b/hw/misc/tz-ppc.c index 6f820430eed8..5f09ce164c19 100644 --- a/hw/misc/tz-ppc.c +++ b/hw/misc/tz-ppc.c @@ -303,26 +303,11 @@ static const VMStateDescription tz_ppc_vmstate = { #define DEFINE_PORT(N) \ DEFINE_PROP_LINK("port[" #N "]", TZPPC, port[N].downstream, \ - TYPE_MEMORY_REGION, MemoryRegion *) + TYPE_MEMORY_REGION, MemoryRegion *), static const Property tz_ppc_properties[] = { DEFINE_PROP_UINT32("NONSEC_MASK", TZPPC, nonsec_mask, 0), - DEFINE_PORT(0), - DEFINE_PORT(1), - DEFINE_PORT(2), - DEFINE_PORT(3), - DEFINE_PORT(4), - DEFINE_PORT(5), - DEFINE_PORT(6), - DEFINE_PORT(7), - DEFINE_PORT(8), - DEFINE_PORT(9), - DEFINE_PORT(10), - DEFINE_PORT(11), - DEFINE_PORT(12), - DEFINE_PORT(13), - DEFINE_PORT(14), - DEFINE_PORT(15), + QEMU_REPEAT(TZ_NUM_PORTS, DEFINE_PORT) }; static void tz_ppc_class_init(ObjectClass *klass, const void *data) diff --git a/hw/remote/vfio-user-obj.c b/hw/remote/vfio-user-obj.c index 7e6819f670b5..84c3ff05cfb8 100644 --- a/hw/remote/vfio-user-obj.c +++ b/hw/remote/vfio-user-obj.c @@ -496,22 +496,11 @@ static size_t vfu_object_bar_rw(PCIDevice *pci_dev, int pci_bar, buf, count, is_write); \ } \ -VFU_OBJECT_BAR_HANDLER(0) -VFU_OBJECT_BAR_HANDLER(1) -VFU_OBJECT_BAR_HANDLER(2) -VFU_OBJECT_BAR_HANDLER(3) -VFU_OBJECT_BAR_HANDLER(4) -VFU_OBJECT_BAR_HANDLER(5) -VFU_OBJECT_BAR_HANDLER(6) +QEMU_REPEAT(PCI_NUM_REGIONS, VFU_OBJECT_BAR_HANDLER) +#define VFU_OBJECT_BAR_HANDLER_PTR(BAR_NO) vfu_object_bar##BAR_NO##_handler, static vfu_region_access_cb_t *vfu_object_bar_handlers[PCI_NUM_REGIONS] = { - &vfu_object_bar0_handler, - &vfu_object_bar1_handler, - &vfu_object_bar2_handler, - &vfu_object_bar3_handler, - &vfu_object_bar4_handler, - &vfu_object_bar5_handler, - &vfu_object_bar6_handler, + QEMU_REPEAT(PCI_NUM_REGIONS, VFU_OBJECT_BAR_HANDLER_PTR) }; /** diff --git a/include/hw/cxl/cxl_component.h b/include/hw/cxl/cxl_component.h index ffc82202206c..fca8b7055ccd 100644 --- a/include/hw/cxl/cxl_component.h +++ b/include/hw/cxl/cxl_component.h @@ -186,10 +186,7 @@ REG32(CXL_HDM_DECODER_GLOBAL_CONTROL, CXL_HDM_REGISTERS_OFFSET + 4) /* Support 4 decoders at all levels of topology */ #define CXL_HDM_DECODER_COUNT 4 -HDM_DECODER_INIT(0); -HDM_DECODER_INIT(1); -HDM_DECODER_INIT(2); -HDM_DECODER_INIT(3); +QEMU_REPEAT(CXL_HDM_DECODER_COUNT, HDM_DECODER_INIT) /* * CXL r3.1 Section 8.2.4.21: CXL Extended Security Capability Structure diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h index 1ec5b42230be..a5e7ff99cb89 100644 --- a/include/qemu/osdep.h +++ b/include/qemu/osdep.h @@ -191,6 +191,39 @@ extern "C" { #include "qemu/typedefs.h" +/* + * QEMU_REPEAT(n, m) - invoke m(0) m(1) ... m(n-1) + * + * Expands to n invocations of m, each with a literal integer argument. + * n must be a compile-time constant in 0..16. + * + * Example - generate 4 per-index function definitions: + * + * #define DEFINE_GETTER(i) \ + * static int get_##i(void) { return values[i]; } + * + * QEMU_REPEAT(4, DEFINE_GETTER) + */ +#define QEMU_REPEAT_0(m) +#define QEMU_REPEAT_1(m) QEMU_REPEAT_0(m) m(0) +#define QEMU_REPEAT_2(m) QEMU_REPEAT_1(m) m(1) +#define QEMU_REPEAT_3(m) QEMU_REPEAT_2(m) m(2) +#define QEMU_REPEAT_4(m) QEMU_REPEAT_3(m) m(3) +#define QEMU_REPEAT_5(m) QEMU_REPEAT_4(m) m(4) +#define QEMU_REPEAT_6(m) QEMU_REPEAT_5(m) m(5) +#define QEMU_REPEAT_7(m) QEMU_REPEAT_6(m) m(6) +#define QEMU_REPEAT_8(m) QEMU_REPEAT_7(m) m(7) +#define QEMU_REPEAT_9(m) QEMU_REPEAT_8(m) m(8) +#define QEMU_REPEAT_10(m) QEMU_REPEAT_9(m) m(9) +#define QEMU_REPEAT_11(m) QEMU_REPEAT_10(m) m(10) +#define QEMU_REPEAT_12(m) QEMU_REPEAT_11(m) m(11) +#define QEMU_REPEAT_13(m) QEMU_REPEAT_12(m) m(12) +#define QEMU_REPEAT_14(m) QEMU_REPEAT_13(m) m(13) +#define QEMU_REPEAT_15(m) QEMU_REPEAT_14(m) m(14) +#define QEMU_REPEAT_16(m) QEMU_REPEAT_15(m) m(15) +#define QEMU_REPEAT_(n, m) QEMU_REPEAT_##n(m) +#define QEMU_REPEAT(n, m) QEMU_REPEAT_(n, m) + /** * Mark a function that executes in coroutine context * -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455321.1669027 (Exim 4.92) (envelope-from ) id 1xJ7WB-0005qq-U8; Tue, 20 Oct 2026 10:56:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455321.1669027; Tue, 20 Oct 2026 10:56: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 1xJ7WA-0005jq-6N; Tue, 20 Oct 2026 10:56:30 +0000 Received: by outflank-mailman (input) for mailman id 1455321; Tue, 20 Oct 2026 10:50:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qf-0008V4-DI for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qe-004d40-QV for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:48 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74785-8faa-0a2a0a5109dd-0a2a450cd584-16 for ; Tue, 20 Oct 2026 12:50:48 +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 6ad7470e-f479-0a2a450c0019-aa0a817c6ed9-3 for ; Tue, 20 Oct 2026 12:48:47 +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-83--Z5Wuh_zPUyc0JzRRnv_JA-1; Tue, 20 Oct 2026 06:48:42 -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 15B921956076; Tue, 20 Oct 2026 10:48:39 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1EFBA418; Tue, 20 Oct 2026 10:48: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=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=1792493326; 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=VsbaU0VdjEFE5/Kdiolu0QHc56Ub04+6AJsyszfha5Q=; b=Kvj6Uhmx0CftacNi8fS11w2+s5+vYOuMOklkfQcL817okxj1BLEXQ5Wx0bxnDrs2S7y03u /igaXAem0RanY67EA4+bRDbOFopm14PF8Is+FUroEJEjxZShXK7zfrGslsQ1kCajOGRwjm flMBuzKO9F2N5mpB94gS69XuGdt0/A0= X-MC-Unique: -Z5Wuh_zPUyc0JzRRnv_JA-1 X-Mimecast-MFC-AGG-ID: -Z5Wuh_zPUyc0JzRRnv_JA_1792493319 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:44 +0400 Subject: [PATCH v7 27/65] hostmem-file: convert OnOffAuto rom property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-27-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=3017; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=iZFd9HvderJ8uRReytwVEg9V/BI0/W9et6yTV5n+0HQ=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaUi0I/HhTBoPEm8cGvUR2Ags/oP63+/IJC B3aPbt5x/6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5SbrEACzpT4DA3aDgoPm1mkI7LWP4C1/KmFL4+/JVH+4dvDiHK2lfPUcj6g8+5ZAjiaZ7BNg5vr GU3ywL52hlZ5JZCn41HMfti/ha4z983dNfIctpiaV9RJU+A22EtAvPLpDEcFPF9PfeB/aMB6a1h 0Dpk/O8iKpIR0ww2sHYfJ7HC8jqBpBpc5BTWLONeOzWTk3OnFRU6R0c5BPcI6cENi7juVgxXrtZ ispq5YrtGrp52pLe3Ewh7Z+QrKyA2oKxwo7jhh3PQ9MQf1Bv4H9XMKBZmivwnir/bT4wnDtabCG Z3MBE8QRfPUHzLW7s8idRTcelPr99S0+ZteQGhagDNHrC6CSQMSUQPO7daBJj8bgI/gxraF66d0 ceIDBeRODFFyp397ZvOHRafc6G41UZt3Q09G/ONGcgNom+1IxZuqlJKhvb2/lhLdZMQFRPNkGAj +EpBka/x64Ny38YdXyQE79VKzddpZZLDC1bVdR+/jm4r3s6ujtMANYlwZojYhpW6CGtB8RorWmI BzUp4XLCDTQrGR4EZej7rnfAUKzkJ3+sMWrkIk59mZgmLJ5fXSxLqhwExH6OrIEp1ay3QZ15Bhp MS3Wp8RSmuhgaHr6i15QnVDly1vb0u60cJvRjNcpvjIEC40XFnirrOV6Qw6AmT4lgBoJx/CvkS4 b2y0JppmjOhRU9g== 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: AjAgkOcKgY090WkV1dYEmrwuURwST74AHYyS7yURdok_1792493319 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1792493328-51936A5B-8B59395A/0/0 X-purgate-type: clean X-purgate-size: 3019 Convert the rom OnOffAuto property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- backends/hostmem-file.c | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c index 7efecf71f565..7d4d52482966 100644 --- a/backends/hostmem-file.c +++ b/backends/hostmem-file.c @@ -19,7 +19,7 @@ #include "qom/object_interfaces.h" #include "qom/object.h" #include "qapi/visitor.h" -#include "qapi/qapi-visit-common.h" +#include "qapi/qapi-type-infos-common.h" OBJECT_DECLARE_SIMPLE_TYPE(HostMemoryBackendFile, MEMORY_BACKEND_FILE) @@ -230,30 +230,24 @@ static void file_memory_backend_set_readonly(Object *obj, bool value, fb->readonly = value; } -static void file_memory_backend_get_rom(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static int file_memory_backend_get_rom(Object *obj, Error **errp) { HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj); - OnOffAuto rom = fb->rom; - - visit_type_OnOffAuto(v, name, &rom, errp); + return fb->rom; } -static void file_memory_backend_set_rom(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static void file_memory_backend_set_rom(Object *obj, int value, Error **errp) { HostMemoryBackend *backend = MEMORY_BACKEND(obj); HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj); if (host_memory_backend_mr_inited(backend)) { - error_setg(errp, "cannot change property '%s' of %s.", name, + error_setg(errp, "cannot change property 'rom' of %s.", object_get_typename(obj)); return; } - visit_type_OnOffAuto(v, name, &fb->rom, errp); + fb->rom = value; } static void file_backend_unparent(Object *obj) @@ -298,10 +292,13 @@ file_backend_class_init(ObjectClass *oc, const void *data) object_class_property_add_bool(oc, "readonly", file_memory_backend_get_readonly, file_memory_backend_set_readonly); - object_class_property_add(oc, "rom", "OnOffAuto", - file_memory_backend_get_rom, file_memory_backend_set_rom, NULL, NULL); - object_class_property_set_description(oc, "rom", - "Whether to create Read Only Memory (ROM)"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "rom", + .description = "Whether to create Read Only Memory (ROM)", + .qapi_type = &OnOffAuto_type_info, + .get = file_memory_backend_get_rom, + .set = file_memory_backend_set_rom, + )); } static void file_backend_instance_finalize(Object *o) -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455323.1669034 (Exim 4.92) (envelope-from ) id 1xJ7WD-0006GD-Du; Tue, 20 Oct 2026 10:56:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455323.1669034; Tue, 20 Oct 2026 10: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 1xJ7WC-00069U-8C; Tue, 20 Oct 2026 10:56:32 +0000 Received: by outflank-mailman (input) for mailman id 1455323; Tue, 20 Oct 2026 10:50:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qg-0008Vg-BF for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qf-00Crdk-O5 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:49 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74788-2eae-0a2a0a5409dd-0a2a4501d57a-6 for ; Tue, 20 Oct 2026 12:50:49 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad74710-5984-0a2a45010019-aa0a857cbf29-3 for ; Tue, 20 Oct 2026 12:48: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-656-evkX-KHbNye8aHdQO4NYlg-1; Tue, 20 Oct 2026 10:48:38 +0000 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 BF9F3180056E; Tue, 20 Oct 2026 10:48:33 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D3CE130000E7; Tue, 20 Oct 2026 10:48: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=1792493328; 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=PV9kuqJKGQPXQgRGsKGHU0tbZKUNtph+KWyMZp45370=; b=TpWlFmnBdRUuF9+RlCvOXz1huOM59mJdNdVCwlhpbJrHDIRV3Du9T5FMMMoMUxJ9xT4xgM ib41fCWIdNVRCxhqQk/AXra30L/osptgj5eYtsqv9DTacrdUcswPNAcdljjAqqApT6O4cb 3J7IhiKNxQd3KewFYF4gA1674FjWe9A= X-MC-Unique: evkX-KHbNye8aHdQO4NYlg-1 X-Mimecast-MFC-AGG-ID: evkX-KHbNye8aHdQO4NYlg_1792493313 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:43 +0400 Subject: [PATCH v7 26/65] loongarch/virt: convert OnOffAuto properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-26-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=6018; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=mcn2JeHI5hIu+VBT7QhXgV3egUYPPh04IMlXvF5e4Ec=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZn4jMd/2ebsZ0FoPPbj1jDn2hGRETnXjT2 a9TRgsJMRyJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5VcbD/0XQPP+Hq6G02Te1ATdBSDCe1WOePn+q3hsXMEjoOzOBoMnryWDu8kNBch2qC8q592TwYn hRkWhx3p8YWF9kYFeQ23u32TqttVt/lCxq8pWndKI6GgSC5v8616dnw2YpSgsb3fosKThWBUUUk fCN2F7JenKbU2ahFlCWtu7UAB0XSoTl4KkhrepX20amiSBjQnvZQvYi/1xg7w2m5ZMSYMSmH/LC l23OSw7QCemnhrF++uLTOObyXcs8T5yYj67uh0BF19kJB3ZzZ0jaMA3li1HytdrFcV7GwnFvH0D LXX8Rrv5mvff1zR2spKxkS9RctUmQZdKlOZ+GhgQnZX+wyQIgSQesWnPD8JmIU9lJGXw7voOqGQ cnwmMtO4dkVkqgg8e8dPEOenMG0LMpxPwEXmbP1l4zz9T5pL6YEFBPe3sLJ/Q4vz+eChkhPJpnT kbYtHnZSNae7agOjfkGpzv0xQZnugriVrT0XMl8A8/QQEQDDkngQF3/tF2Wjp1UBd9uE9NLqTVA 5kCV+wPxw4rBcTH/PtAQiXN2Y/UxDOIz8vsWuaQySEqGQynllWHdiPAk4QmiAgkoxO/0r0j4yWG zVIXphd2t3fdmg99IfAn5usbT83aXvGpab7PMeWgsXcGpLJh205ful7Mp2GUVpQTa6A92/oPOaA YI89h+wirCbvd3w== 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: mAAx1bP5p02YpV9wJ8dBplXAqWl-DFTtV_vHElF0KnY_1792493313 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792493329-C4558757-B1EA9200/0/0 X-purgate-type: clean X-purgate-size: 6020 Convert the acpi, v-eiointc, and dmsi OnOffAuto properties from manual visitor-based callbacks to property_add_qapi_enum(). Reviewed-by: Bibo Mao Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/loongarch/virt.c | 85 +++++++++++++++++++++++++---------------------------- 1 file changed, 40 insertions(+), 45 deletions(-) diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 9c5371af9dee..db8ea76f117c 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -36,7 +36,8 @@ #include "target/loongarch/cpu.h" #include "target/loongarch/cpu-mmu.h" #include "hw/firmware/smbios.h" -#include "qapi/qapi-visit-common.h" +#include "qapi/qapi-type-infos-common.h" +#include "qapi/visitor.h" #include "hw/acpi/generic_event_device.h" #include "hw/mem/nvdimm.h" #include "hw/core/platform-bus.h" @@ -51,26 +52,21 @@ #include "qemu/log.h" #include "kvm/kvm_loongarch.h" -static void virt_get_dmsi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int virt_get_dmsi(Object *obj, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(obj); - OnOffAuto dmsi = lvms->dmsi; - - visit_type_OnOffAuto(v, name, &dmsi, errp); - + return lvms->dmsi; } -static void virt_set_dmsi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) + +static void virt_set_dmsi(Object *obj, int value, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(obj); + lvms->dmsi = value; - visit_type_OnOffAuto(v, name, &lvms->dmsi, errp); - - if (lvms->dmsi == ON_OFF_AUTO_OFF) { + if (value == ON_OFF_AUTO_OFF) { lvms->misc_feature &= ~BIT(IOCSRF_DMSI); lvms->misc_status &= ~BIT_ULL(IOCSRM_DMSI_EN); - } else if (lvms->dmsi == ON_OFF_AUTO_ON) { + } else if (value == ON_OFF_AUTO_ON) { lvms->misc_feature = BIT(IOCSRF_DMSI); } } @@ -78,21 +74,16 @@ static void virt_set_dmsi(Object *obj, Visitor *v, const char *name, #define DEFAULT_HIGH_PCIE_MMIO_SIZE_GB 64 #define DEFAULT_HIGH_PCIE_MMIO_SIZE (DEFAULT_HIGH_PCIE_MMIO_SIZE_GB * GiB) -static void virt_get_veiointc(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int virt_get_veiointc(Object *obj, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(obj); - OnOffAuto veiointc = lvms->veiointc; - - visit_type_OnOffAuto(v, name, &veiointc, errp); + return lvms->veiointc; } -static void virt_set_veiointc(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void virt_set_veiointc(Object *obj, int value, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &lvms->veiointc, errp); + lvms->veiointc = value; } static bool virt_get_highmem_mmio(Object *obj, Error **errp) @@ -1025,21 +1016,16 @@ static void virt_init(MachineState *machine) loongarch_load_kernel(machine, &lvms->bootinfo, phys_addr_mask); } -static void virt_get_acpi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int virt_get_acpi(Object *obj, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(obj); - OnOffAuto acpi = lvms->acpi; - - visit_type_OnOffAuto(v, name, &acpi, errp); + return lvms->acpi; } -static void virt_set_acpi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void virt_set_acpi(Object *obj, int value, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &lvms->acpi, errp); + lvms->acpi = value; } static char *virt_get_oem_id(Object *obj, Error **errp) @@ -1483,20 +1469,29 @@ static void virt_class_init(ObjectClass *oc, const void *data) hc->unplug_request = virt_device_unplug_request; hc->unplug = virt_device_unplug; - object_class_property_add(oc, "acpi", "OnOffAuto", - virt_get_acpi, virt_set_acpi, - NULL, NULL); - object_class_property_set_description(oc, "acpi", - "Enable ACPI"); - object_class_property_add(oc, "v-eiointc", "OnOffAuto", - virt_get_veiointc, virt_set_veiointc, - NULL, NULL); - object_class_property_set_description(oc, "v-eiointc", - "Enable Virt Extend I/O Interrupt Controller."); - object_class_property_add(oc, "dmsi", "OnOffAuto", - virt_get_dmsi, virt_set_dmsi, NULL, NULL); - object_class_property_set_description(oc, "dmsi", - "Enable direct Message-interrupts Controller."); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "acpi", + .description = "Enable ACPI", + .qapi_type = &OnOffAuto_type_info, + .get = virt_get_acpi, + .set = virt_set_acpi, + )); + + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "v-eiointc", + .description = "Enable Virt Extend I/O Interrupt Controller.", + .qapi_type = &OnOffAuto_type_info, + .get = virt_get_veiointc, + .set = virt_set_veiointc, + )); + + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "dmsi", + .description = "Enable direct Message-interrupts Controller.", + .qapi_type = &OnOffAuto_type_info, + .get = virt_get_dmsi, + .set = virt_set_dmsi, + )); machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE); machine_class_allow_dynamic_sysbus_dev(mc, TYPE_UEFI_VARS_SYSBUS); #ifdef CONFIG_TPM -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455326.1669044 (Exim 4.92) (envelope-from ) id 1xJ7WF-0006aD-NC; Tue, 20 Oct 2026 10:56:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455326.1669044; Tue, 20 Oct 2026 10:56: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 1xJ7WE-0006Ts-30; Tue, 20 Oct 2026 10:56:34 +0000 Received: by outflank-mailman (input) for mailman id 1455326; Tue, 20 Oct 2026 10:50:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qi-0008WN-9Y for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qh-004d40-Mf for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:51 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7478b-8faa-0a2a0a5109dd-0a2a4504bc34-2 for ; Tue, 20 Oct 2026 12:50:51 +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 6ad7474d-b57f-0a2a45040019-aa0a817cd823-3 for ; Tue, 20 Oct 2026 12:49:50 +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-117-XUXv77GHO2OCTyQEVcEWJg-1; Tue, 20 Oct 2026 06:49:45 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3B1F418011E7; Tue, 20 Oct 2026 10:49:41 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1CB63195608C; Tue, 20 Oct 2026 10:49: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=1792493389; 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=eVX3ZvHEwBSXNYOzSbNt3BOZCjs1Nmjrz4zkatMYBkU=; b=DMbvYzi4kxDNZersoh9WJvgV5DA2ucWZmeNUYnvgOUSxk3mZQXK/I2quJwmTV/j5abcjYu 3onjaKdN3xKFctvs1dYb3mBoS+RhNNol9lPZ3a7SeWWgJSS+ov5uybUVoquOesvBW/HH3q d6osQFNW0dpAdbQ543IsjXyh/L67qz4= X-MC-Unique: XUXv77GHO2OCTyQEVcEWJg-1 X-Mimecast-MFC-AGG-ID: XUXv77GHO2OCTyQEVcEWJg_1792493381 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:55 +0400 Subject: [PATCH v7 38/65] qom: convert scalar properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-38-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=108660; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=1zdoLwB5ecSZAOO1VVlwa1bcSEdnAj2iT7iIGMQmjQI=; b=kA0DAAoB2ujhCXWWnOUByyZiAGrXRlug7fU4tcjGQ3ZxPTnQv47jZ4pm1Upu65UQZYx4q2LyX 4kCMwQAAQoAHRYhBIepvZM/h8YG0nb2Ldro4Ql1lpzlBQJq10ZbAAoJENro4Ql1lpzlRpUQAJOE 23fi4vI9nH+/CLvpSC11JRPuhf1vH6nL/qoCGl7PRC02AfW9rh9dE58JN2nICu/RCzlVNNzjFgE l8wwCwqlkoIQrnwY69hYr7ogAcNKmd5U2MZl5dhGPE0o0BiXNSqAdN+sbqoddy0/6glYWBTD+3+ QFx9KUiYOLrobwBKKw3lefiYxWcL3xds0MQ0AiMCxc91rljgd/q8JmNABVabbuoXAP4kHbZtGCJ LTwGEUEZFEfVy6Gkh1ZxAwRWog7NX9XQuODji6k+WJGL1Mm+0zLK/lkMmDF6oUFeGu/PAnyso/n Sk549aGfT+IbDWNM/rIwRnUY6p5yOJv50F0lAviXB0GtTRjKKG/Q/mkhCr2xu+Ce7TejKG3jmZh hHg7OWJdvp69PJP3J5EbyVWA+9KHaZahNNfBHtFLZ2kBIuSH5i29hZxTO/52/RtiyOQPv5pBObV iyJ7vaelDLq7PuoOzAbspq2Mwh328NfY5M2sdL/9mco2je6BFlb8+sYmFpUllV4/w+j2ujETL5e oklsO1Lc/dXjPkNz2bWGTw7aDVHRfrSsEmwB8qNbEJUhkujo2wORZKktaoYamHIEPLhSyhk3xOQ XczODyC4xAAyzdEGcIROtfsTZu1BlsY+gOcDTW0h36kQv9Gj1y4jjr35A2NWiKSxT+CYe3s7qfC PNU3Y 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: JkAG1x6vd0Zg3zItVrWKV-kYt2wsUMGUBv9G6PtRlQg_1792493381 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792493391-536C28F0-A7D36919/0/0 X-purgate-type: clean X-purgate-size: 108662 Reviewed-by: Amit Machhiwal Signed-off-by: Markus Armbruster 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 | 10 +++-- 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, 347 insertions(+), 244 deletions(-) diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index 1d91667fb880..bc178482b309 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" @@ -4303,13 +4304,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 7d4d52482966..46646115713e 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 666593ff6c0b..fcd51680cd64 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" #include "system/kvm.h" @@ -195,7 +196,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 edb8e6ab4502..45a2ea6ef174 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 987867477acc..c0f24ad91e42 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" @@ -985,9 +986,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 6d421b990cef..64228a620e69 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 0da10b799cfb..2fa728b99e08 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -4257,7 +4257,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); @@ -4265,7 +4265,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 94737e17e66f..7272944f30a2 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -1137,7 +1137,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 8997bf1785c8..326a1eda69ac 100644 --- a/hw/cxl/cxl-host.c +++ b/hw/cxl/cxl-host.c @@ -611,7 +611,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 12de020adfbf..c2bca40e511a 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1718,7 +1718,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, @@ -1756,13 +1756,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 29cda843c942..9636f32fb624 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" @@ -159,10 +160,11 @@ static void sgx_epc_class_init(ObjectClass *oc, const void *data) mdc->get_memory_region = sgx_epc_md_get_memory_region; mdc->fill_device_info = sgx_epc_md_fill_device_info; - object_class_property_add(oc, SGX_EPC_SIZE_PROP, "uint64", - sgx_epc_get_size, - NULL, - NULL, NULL); + object_class_property_add_qapi(oc, SGX_EPC_SIZE_PROP, + &uint64_type_info, + sgx_epc_get_size, + NULL, + NULL, NULL); } static const TypeInfo sgx_epc_info = { 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 db8ea76f117c..edb59568038b 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 578421c21761..1065b9411ddf 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" @@ -10612,7 +10613,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 07d519cf6d77..7ffbe48e5134 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" @@ -1039,7 +1040,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 cc113c0810e7..9f9a2abfa08d 100644 --- a/qom/object.c +++ b/qom/object.c @@ -22,10 +22,10 @@ #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 "qapi/compat-policy.h" #include "qobject/qdict.h" -#include "qobject/qjson.h" #include "qemu/id.h" #include "qapi/qmp/qerror.h" #include "trace.h" @@ -2449,7 +2449,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, @@ -2467,7 +2467,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, @@ -2519,7 +2519,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, @@ -2536,7 +2536,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, @@ -2945,8 +2945,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 * @@ -2986,8 +2986,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 * @@ -3006,8 +3006,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 * @@ -3047,8 +3047,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 * @@ -3067,8 +3067,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 * @@ -3108,8 +3108,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 * @@ -3128,8 +3128,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 * @@ -3169,8 +3169,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 f1910af8a010..ff8dae018aa2 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 dcd0d698b300..c9e5f294b336 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" @@ -328,7 +329,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); } @@ -518,13 +519,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); @@ -543,13 +544,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 3d905f8565de..1569a64b3b57 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" @@ -1820,7 +1821,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 c92e331e7317..db73b7668f42 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)); @@ -1529,8 +1530,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 4553ef0892a1..3601a56e6848 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -10457,7 +10457,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); @@ -10977,13 +10977,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", @@ -10992,7 +10992,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); /* @@ -11005,7 +11005,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 f2e8dc8c156d..03c6816cf61e 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 08a4d14ea1f6..664c1a767950 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -28,6 +28,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" @@ -1412,20 +1413,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 45ad5e1525a8..c90db86cda85 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" @@ -539,7 +540,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); @@ -559,7 +560,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); @@ -575,7 +576,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 e07ca95e49bd..88fdbec4fb4c 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" @@ -1473,7 +1474,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); @@ -1527,7 +1528,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); @@ -1603,10 +1604,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 b7357172007e..840603cb233f 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.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455328.1669053 (Exim 4.92) (envelope-from ) id 1xJ7WI-0007DE-A7; Tue, 20 Oct 2026 10:56:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455328.1669053; Tue, 20 Oct 2026 10: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 1xJ7WG-00075j-ML; Tue, 20 Oct 2026 10:56:36 +0000 Received: by outflank-mailman (input) for mailman id 1455328; Tue, 20 Oct 2026 10:50:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qm-00006E-Oq for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qm-00EzCr-5l for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:56 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74774-e002-0a2a0a5209dd-0a2a4508c9a4-46 for ; Tue, 20 Oct 2026 12:50:56 +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 6ad74752-f659-0a2a45080019-aa0a857c8ebf-3 for ; Tue, 20 Oct 2026 12:49:55 +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-206-FotbGa2bN3uiQWrd6VJL7Q-1; Tue, 20 Oct 2026 10:49:52 +0000 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1CFF51800A30; Tue, 20 Oct 2026 10:49:48 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8F8041800677; Tue, 20 Oct 2026 10:49: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=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=1792493394; 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=SaO9TD83O1mESMfVgH3WuoSzmG3APdCIb1nj0sICWaY=; b=hwi5tyWQQkZoLbJwOmxca9kaXuRDjPDVA2ODN4Z8PomCnVYc9cm1wNPvWG1yDPxRdSEpcv Dsm4b+IYKKWW4KwWF5nU+vHQA7bswT6mq5ty32WpahbnCzIWkCXi9sCGcjFlOjQzLp8FFJ wGUK75mYTrtAuA2HIiemn46V5QJkP0s= X-MC-Unique: FotbGa2bN3uiQWrd6VJL7Q-1 X-Mimecast-MFC-AGG-ID: FotbGa2bN3uiQWrd6VJL7Q_1792493388 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:56 +0400 Subject: [PATCH v7 39/65] i386/cpu: convert strList property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-39-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=927; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=/KSVjwfA6NJABrU8j/+rplEihE7WbSuvvPqkwS91nlk=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Zbi8OK49WAzCOnFkroErxJhCPevzYVZbRRQ puH2R/pXLCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5Za+EAC4HYxAzDB6R6B/Noe10vMQK3B2SHQlClijhbENvmsvZv+GkuP6ofyL3AMjQq7g/lGOrmr kZR2Ol0ojf7GsTbPDPZC1kjtzUdQMn/LtO42Lk23fn3xUsw2aW27mj3TXI7nh1DDVWX3jgPxwiK ydRbU6lC/4F6A2VQWjdFzU4fbU2KK61YYgUEglYkpb5R7yjvLJ7W4mKRBchEfEtR49x12Pq5twp DWF2vI63kyQ/P+Qvouz+2AbBduW0y+965Qh/qC22TeE2/sEmP9wJbYUB2zJytThfAWj2eyNiueK GizBJDEuMzW1gBvPXs4efEsA9PwP5/qk6kJHD/DYuianSi4tR+5ENhbyKrBLusUCPSLdvQwkAh4 3U1ofLR/Z2pxMxJR4y8fxT7RNDj7Jtl9kLNLxZEhSQqnkKDtN58/dHtfzjnHnxsuGU/ntoYHAxO 4HYyMk9ilCrrh200rMF5WADd68dXw0wcnmHZMt7J3ihT8FcMQw7g+jVnCiYfY6yGwqvW8n6STUT +U6Uzo4zLAOoAHD699r7p6EkjoKe8OT7lqPFtrwIyM+Tpv0Sh47SdRwNoD8CcP6tycIaDAyB5lZ jlNKLfm+Ov/X+M47Kj5g0z3/DpvIrUhDJ2+rTO5vF4Sgl8eVMwqfuLYlVB0lTw7eQ9ys7QpVHig U3bIykrc/pNCZdA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: OfkIPxz6tvlQwNAVrpLgx6VcXQv7_yVimTCgauIC4Yg_1792493388 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792493396-D477387B-ACAAA674/0/0 X-purgate-type: clean X-purgate-size: 929 Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- target/i386/cpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 3601a56e6848..0a9acfa74600 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -11001,7 +11001,8 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) * QMP command: they list the features that would have prevented the * CPU from running if the "enforce" flag was set. */ - object_class_property_add(oc, "unavailable-features", "strList", + object_class_property_add_qapi(oc, "unavailable-features", + &strList_type_info, x86_cpu_get_unavailable_features, NULL, NULL, NULL); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455329.1669065 (Exim 4.92) (envelope-from ) id 1xJ7WL-0007hn-0E; Tue, 20 Oct 2026 10:56:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455329.1669065; Tue, 20 Oct 2026 10: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 1xJ7WJ-0007b2-2p; Tue, 20 Oct 2026 10:56:39 +0000 Received: by outflank-mailman (input) for mailman id 1455329; Tue, 20 Oct 2026 10:50:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qn-00006K-7H for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qm-00CrhG-K5 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:56 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74788-2eae-0a2a0a5409dd-0a2a4501d57a-18 for ; Tue, 20 Oct 2026 12:50:56 +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 6ad74717-5984-0a2a45010019-aa0a817ce3f1-3 for ; Tue, 20 Oct 2026 12:48:56 +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-491-PGS6jTcAOfWke_074JgvdA-1; Tue, 20 Oct 2026 10:48:48 +0000 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 607CC1955DCB; Tue, 20 Oct 2026 10:48:44 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3C7E018002B1; Tue, 20 Oct 2026 10:48:41 +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=1792493335; 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=ITZAmzqb42SOieKlyK1KvmCdBEM4ZFKVGJMc/HmGp5k=; b=jPOQbE5jdemeDMlDEVYa9jszq44btWVEnEK74DkI4epnraE2Mri5hI5hGJB/zGnJTWsRIs Etw0pjvfwLUBhAjYpYJBHgB6ENWWYcgwtSARSbmXuGmAlvoIYQXlT7cyhxU7jKoMmClrdA hsWxSTiA1WIQ0Jah9+4Hj0tFjFm0eko= X-MC-Unique: PGS6jTcAOfWke_074JgvdA-1 X-Mimecast-MFC-AGG-ID: PGS6jTcAOfWke_074JgvdA_1792493324 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:45 +0400 Subject: [PATCH v7 28/65] sev: convert OnOffAuto legacy-vm-type property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-28-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2932; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=e2zxmMhmJGF0dwc0SRzZuUR5qMnfM/36nnJtEEhS5HU=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaPCLOl/jTkrNhGvjvoErUEYn1j7um/aMo0 ZI7dyqyzT6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5bBPD/9YSzBj8rYL1VR6mIizfqkgB0/PpThetAFKK6VOJ5UwsrSCvay3ut/gvIfOk0yHdhdHVWq Uz2ZKUkj9DO9sRX39BQCuKmjIsfoY3siZbaDChTtbShjPxhuFraX/nC2nvPuqd3vJJCy6AOeiCN 0ihLqhJPkeYoPKVqVd8jLDAt24/RSLOtUiuCXK3ZjSyXPiQCI7Q+c4ObrWUqfFSKoZuD/WjUmpI Ydb1AYXzIDBSx6VHn33zxDswViVybQV5ahY7osUUBE7KAI28mVSFrxFOCGWT58Hpz/xomG0JKq8 9VXoJNH+E5shv0v0VhMSnm+pvNmz0id2LZty8354Pi1CZ+KdmxSwz7Kxqdc0NCFER77a7+xn7J6 x0S9Zu85aLRNnCRSOJ5auSHQgryCGQvKSOlqFFL+SCOVftpsiiUH4bd8CAKJCIPeqw7j7beCCGY KNB6BsQL6TDT7zaAQmMPNVZur/l87U4iJmPZjBF6c3RiM/10WKCnxRb3MWcocawkttpcuS9FLxg B9ud9eSGegnwhA1PxzXyburB+4c8MbRt5hdLKQvae+gUTUK0Z3BG3jbmybChBhoNKRREWEUepvd LkDhvCIHcfCmtyY2QCNu5qT/nkPIDzUZOqpHc0Oq8GA49cI/MvabenocOgTLTS9BEKBuQDZRWKY jeq3wdMr+xiPpNg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: Yq1g67OpNLMbqFPhLzwxzh4OLrc7PODts6t1JLQ_vrQ_1792493324 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792493336-BDE78757-0060696E/0/0 X-purgate-type: clean X-purgate-size: 2934 Convert the legacy-vm-type OnOffAuto property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- target/i386/sev.c | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/target/i386/sev.c b/target/i386/sev.c index cc16c6b07123..b2c7260c80a4 100644 --- a/target/i386/sev.c +++ b/target/i386/sev.c @@ -20,6 +20,7 @@ #include #include "qapi/error.h" +#include "qapi/qapi-type-infos-common.h" #include "qom/object_interfaces.h" #include "qemu/base64.h" #include "qemu/module.h" @@ -2939,23 +2940,16 @@ sev_guest_set_session_file(Object *obj, const char *value, Error **errp) SEV_GUEST(obj)->session_file = g_strdup(value); } -static void sev_guest_get_legacy_vm_type(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static int sev_guest_get_legacy_vm_type(Object *obj, Error **errp) { SevGuestState *sev_guest = SEV_GUEST(obj); - OnOffAuto legacy_vm_type = sev_guest->legacy_vm_type; - - visit_type_OnOffAuto(v, name, &legacy_vm_type, errp); + return sev_guest->legacy_vm_type; } -static void sev_guest_set_legacy_vm_type(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static void sev_guest_set_legacy_vm_type(Object *obj, int value, Error **errp) { SevGuestState *sev_guest = SEV_GUEST(obj); - - visit_type_OnOffAuto(v, name, &sev_guest->legacy_vm_type, errp); + sev_guest->legacy_vm_type = value; } static void @@ -2981,11 +2975,14 @@ sev_guest_class_init(ObjectClass *oc, const void *data) sev_guest_set_session_file); object_class_property_set_description(oc, "session-file", "guest owners session parameters (encoded with base64)"); - object_class_property_add(oc, "legacy-vm-type", "OnOffAuto", - sev_guest_get_legacy_vm_type, - sev_guest_set_legacy_vm_type, NULL, NULL); - object_class_property_set_description(oc, "legacy-vm-type", - "use legacy VM type to maintain measurement compatibility with older QEMU or kernel versions."); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "legacy-vm-type", + .description = "use legacy VM type to maintain measurement " + "compatibility with older QEMU or kernel versions.", + .qapi_type = &OnOffAuto_type_info, + .get = sev_guest_get_legacy_vm_type, + .set = sev_guest_set_legacy_vm_type, + )); } static void -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455330.1669072 (Exim 4.92) (envelope-from ) id 1xJ7WM-0008Es-Nf; Tue, 20 Oct 2026 10:56:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455330.1669072; Tue, 20 Oct 2026 10:56: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 1xJ7WL-00086v-K9; Tue, 20 Oct 2026 10:56:41 +0000 Received: by outflank-mailman (input) for mailman id 1455330; Tue, 20 Oct 2026 10:50:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qn-00006L-BX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qm-002FUq-Oc for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74783-bab6-0a2a0a5309dd-0a2a450695a8-30 for ; Tue, 20 Oct 2026 12:50:56 +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 6ad746db-195a-0a2a45060019-aa0a857cb563-3 for ; Tue, 20 Oct 2026 12:47:56 +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-488-ofM9Jc0cNLCC9EhH-k12SQ-1; Tue, 20 Oct 2026 10:47:51 +0000 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 10F8B19560B6; Tue, 20 Oct 2026 10:47:47 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 05BB51800444; Tue, 20 Oct 2026 10:47: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=1792493275; 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=VkXUlwrEvWdaFT7ZgPzD9XegjPTV54S9i+Wt7fwK38w=; b=ZWw7PUbEOSaQqQmEL9mhHmawW5Iwa9h9YaC6bsuOJ5dWycxOjK6gx0WcZjKRRDnaVWjB9Z Y+aFECiwRvoJEDfDySS9A0adBiCJKNl7u33a/XsZK20YezRVhIeVbdql9tRYM5v+2vxBrM E+9HNYnjVa+xml42KxxCUVWJnbIdnBs= X-MC-Unique: ofM9Jc0cNLCC9EhH-k12SQ-1 X-Mimecast-MFC-AGG-ID: ofM9Jc0cNLCC9EhH-k12SQ_1792493267 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:34 +0400 Subject: [PATCH v7 17/65] qom: add object_{class_}property_add_qapi_enum MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-17-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=7651; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=6wd/SoQY2q+EMLwTd/AeIQErpXbBILREXSh6bn43Lqo=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZB/jExQFvbdi+wU3hKVxpaaPc1XbpmkIhP WMqxmJ0I1aJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5dBmD/9iljR90PsVPSEMouwGTqd5u0I3uFFVeGE6aj8If5dMfAJeES/9tbvs9mRjLcapLLGllYU TQNIPpVo9+5Q6yWoXDup+0bZugqArDJn+E+oR5GWaIn14K0W/lTsFVa1fdorL5FJzcZt9nLwPbs qBkK2X0Tow/JAOq9beFe0nqvt9e3h8csBkY2OzylCKV8xgUUa/N7/jUd9n3xMAaklrEguKhws7p RB2EmxgN94MyEQXZtZhqjVrWq/vsUKgCcwLJ7z6Xyu8ikQIh00qHstMPJONSLnW5X32860y2JUn RdI6UxJof0RAZu18Ge3d8Qgv+eKmoIfivMtXvHmI0YJtHLFqrI6rXfocRQLrZTDmpURYQ6U9u1U 9yB9eLpPbMa9W1bghYaq4IAEJtvVsjv1kKDYGVAIPSlYH4dCgI/2TzssabsosxuEN1Phkx1epKW nBgKSEf8pt2cQsFq4SKILCVz/lUAkaZIcqrcLdVjN41qVK33dbV9SETzfNzbcypT0qn3Uvh31bB cekeBayXn2khLf+x2Dyym0EbRSJPRvIWIuFiabEG6a8kpeAZgLkNy8ux2Hrid+xaEV/Q2NlRSrc gxaEBZ3gRSWWWvkLE9xRhqAlVrj2m9egPJPQhy1zP1+3Zkc94/+TwXdjvCND2ByqbflBsfGVWJ7 eokXUJapDD7zDZg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: 4eVOH8WTLgbzo171EGIxVHHuw2VkEF--2ax94U-GSfg_1792493267 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1792493276-FC60277B-0516E0D8/0/0 X-purgate-type: clean X-purgate-size: 7653 Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- include/qom/object.h | 74 ++++++++++++++++++++++++++++++++++++++++++ qom/object.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 159 insertions(+), 5 deletions(-) diff --git a/include/qom/object.h b/include/qom/object.h index eb61d8842b80..e04be4caed57 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -2027,6 +2027,80 @@ ObjectProperty *object_class_property_add_enum(ObjectClass *klass, int (*get)(Object *, Error **), void (*set)(Object *, int, Error **)); +/** + * struct QapiEnumProp: Descriptor for a property backed by a QAPI enum type + * + * Binds a QOM object property to a QAPI enum, providing automatic + * string<->int conversion through QAPI visitors and optional + * default-value initialization during object instance init. + * + * Use the QAPI_ENUM_PROP() macro to construct instances inline. + * + * @name: property name exposed on the QOM object + * @description: human-readable description (shown in ``-device help``, etc.) + * @default_value: initial enum value applied via @set during instance init, + * or -1 (the QAPI_ENUM_PROP default) to skip initialization + * @qapi_type: pointer to the generated QAPITypeInfo for the enum + * (provides the string<->int lookup table) + * @get: getter that returns the current enum value as int, or -1 on error + * @set: setter that receives the enum value as int; %NULL for read-only props + */ +typedef struct QapiEnumProp { + const char *name; + const char *description; + const int default_value; + const QAPITypeInfo *qapi_type; + int (*get)(Object *, Error **); + void (*set)(Object *, int, Error **); +} QapiEnumProp; + +#define QAPI_ENUM_PROP(...) ({ \ + static const QapiEnumProp _prop = { \ + .default_value = -1, __VA_ARGS__ \ + }; \ + &_prop; }) + +/** + * object_property_add_qapi_enum: + * @obj: the object to add a property to + * @prop: property descriptor + * + * Add an enum property with QAPI type association. + * + * Returns: The newly added property on success, or %NULL on failure. + */ +ObjectProperty * +object_property_add_qapi_enum(Object *obj, const QapiEnumProp *prop); + +/** + * object_class_property_add_qapi_enum: + * @klass: the class object to add a property to + * @prop: property descriptor + * + * Add an enum property with QAPI type association. + * + * Use the QAPI_ENUM_PROP() macro to construct the property descriptor + * inline. If .default_value is not set, the property is not initialized + * (default_value is -1). Otherwise, the setter is called with + * default_value during object instance init. + * + * Example:: + * + * object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + * .name = "policy", + * .description = "Set the NUMA policy", + * .default_value = HOST_MEM_POLICY_DEFAULT, + * .qapi_type = &HostMemPolicy_type_info, + * .get = my_get_policy, + * .set = my_set_policy, + * )); + * + * Returns: The newly added property on success, or %NULL on failure. + */ +ObjectProperty * +object_class_property_add_qapi_enum(ObjectClass *klass, + const QapiEnumProp *prop); + /** * object_property_add_qapi: * @obj: the object to add a property to diff --git a/qom/object.c b/qom/object.c index bebbfc43556d..cc113c0810e7 100644 --- a/qom/object.c +++ b/qom/object.c @@ -1219,7 +1219,7 @@ static void object_class_foreach_tramp(gpointer key, gpointer value, return; } - if (data->implements_type && + if (data->implements_type && !object_class_dynamic_cast(k, data->implements_type)) { return; } @@ -1786,7 +1786,6 @@ int object_property_get_enum(Object *obj, const char *name, char *str; int ret; ObjectProperty *prop = object_property_find_err(obj, name, errp); - EnumProperty *enumprop; if (prop == NULL) { return -1; @@ -1799,14 +1798,17 @@ int object_property_get_enum(Object *obj, const char *name, return -1; } - enumprop = prop->opaque; - str = object_property_get_str(obj, name, errp); if (!str) { return -1; } - ret = qapi_enum_parse(enumprop->lookup, str, -1, errp); + if (prop->qapi_type) { + ret = qapi_enum_parse(prop->qapi_type->lookup, str, -1, errp); + } else { + EnumProperty *enumprop = prop->opaque; + ret = qapi_enum_parse(enumprop->lookup, str, -1, errp); + } g_free(str); return ret; @@ -2609,6 +2611,84 @@ object_class_property_add_enum(ObjectClass *klass, const char *name, prop); } +static void get_qapi_enum(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) +{ + const QapiEnumProp *prop = opaque; + int value; + Error *err = NULL; + + value = prop->get(obj, &err); + assert(value >= 0 || err); + if (err) { + error_propagate(errp, err); + return; + } + + visit_type_enum(v, name, &value, prop->qapi_type->lookup, errp); +} + +static void set_qapi_enum(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) +{ + const QapiEnumProp *prop = opaque; + int value; + + if (!visit_type_enum(v, name, &value, prop->qapi_type->lookup, errp)) { + return; + } + prop->set(obj, value, errp); +} + +static void init_qapi_enum(Object *obj, ObjectProperty *prop) +{ + const QapiEnumProp *e = prop->opaque; + + if (e->set && e->default_value >= 0) { + e->set(obj, e->default_value, &error_abort); + } +} + +ObjectProperty * +object_property_add_qapi_enum(Object *obj, const QapiEnumProp *e) +{ + ObjectProperty *prop; + + assert(e && e->qapi_type && e->qapi_type->lookup); + + prop = object_property_add_qapi(obj, e->name, e->qapi_type, + e->get ? get_qapi_enum : NULL, + e->set ? set_qapi_enum : NULL, + NULL, + (void *)e); + prop->description = g_strdup(e->description); + if (e->default_value >= 0) { + prop->init = init_qapi_enum; + } + + return prop; +} + +ObjectProperty * +object_class_property_add_qapi_enum(ObjectClass *klass, const QapiEnumProp *e) +{ + ObjectProperty *prop; + + assert(e && e->qapi_type && e->qapi_type->lookup); + + prop = object_class_property_add_qapi(klass, e->name, e->qapi_type, + e->get ? get_qapi_enum : NULL, + e->set ? set_qapi_enum : NULL, + NULL, + (void *)e); + prop->description = g_strdup(e->description); + if (e->default_value >= 0) { + prop->init = init_qapi_enum; + } + + return prop; +} + ObjectProperty * object_property_add_qapi(Object *obj, const char *name, const QAPITypeInfo *qapi_type, -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455331.1669080 (Exim 4.92) (envelope-from ) id 1xJ7WO-0000Ft-Qt; Tue, 20 Oct 2026 10:56:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455331.1669080; Tue, 20 Oct 2026 10: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 1xJ7WN-0000AK-Kk; Tue, 20 Oct 2026 10:56:43 +0000 Received: by outflank-mailman (input) for mailman id 1455331; Tue, 20 Oct 2026 10:50:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qo-00006Y-7d for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qn-00CrhG-KR for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:57 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74791-2eae-0a2a0a5409dd-0a2a4508a15a-0 for ; Tue, 20 Oct 2026 12:50:57 +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 6ad74718-f659-0a2a45080019-aa0a817c92c1-3 for ; Tue, 20 Oct 2026 12:48:57 +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-561--SDF1wKINiCajNC4XN8nVg-1; Tue, 20 Oct 2026 10:48:53 +0000 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 C281219560AD; Tue, 20 Oct 2026 10:48:49 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CC00130000E7; Tue, 20 Oct 2026 10:48: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=1792493336; 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=neSxnRoG/OmCl+kteGebRHQJWP0OZxqFcRCZ8c/QA3c=; b=is2p5rs4M47Kb5I0qVWQ/8KTtLVZw4mr0u4/M0xbmkcNDhobWEdHz26KaB3A9bGpx5OSOu GwPrQVsHXBT6NdUvceRnTjgx236NyOx3OjOQKs4f4ym943i489aC68QjLunJDcydcVWCY7 CYhP+St76XYBBSW7eetEHzPNa02hWtE= X-MC-Unique: -SDF1wKINiCajNC4XN8nVg-1 X-Mimecast-MFC-AGG-ID: -SDF1wKINiCajNC4XN8nVg_1792493329 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:46 +0400 Subject: [PATCH v7 29/65] whpx: convert OnOffAuto hyperv property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-29-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2624; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=fGCiDH3DKuAcB7LiCAkFXJHjeu1egNzKD2fVY9nF9O8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaOCCAg3rKTDCUl37+MgI4Ayhi8dunIN41j jugR4kjAkCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5b6WEACNN5lLKAUjdYB4zCcQJTY9b/clU3Ul2ZqrNT8WzHUQ+fqxHO7sMKEnV/KpehWqsAYB7Wa TcTcGvlU8B+Rp77AddGo/jHP3KiihUrvHM5s2QNpNKBTkpdE/FtNtDGvtY7Rl7BnE0I4ur8xacz HXMHNM++tzb2u4VkpDDbgWl8A7MUiCYAu2iAC93LMBoFtVGYq/tjz4PQr2gFfLvNxJ8hh8g+2iu smVuhJO5UxVs/qkZoh6kIe0LZ6WvLafLB9/AU4a+YYPl0g7G3gvQV+Pzb64VIcibMzpV8qJ8b8M t+/BnO1YoRZPZ11BLDzxA83zKDcZQWNwtNYWZCCxAgLA9Evb3RKKpX3ezykZW625hA11ml8/USP Ng9IwZx3DS+SVp66cPB3YD4Vblja8jaJLVCuGSQnNstkM9jWJ41xW1pTt/RQn1TsRK/t7qyBtO1 kHBG4Xp7bkht89XuKnLvIPrFH/W85g9KGuerywfZYfz/FobiX2GdtR3qPJiq0+oIJa2vLvqAjID 3M72ERKY7E2DdWkQ/qN6y7zsbhicNq980YAI7vae2/ht1mYnRZYyo4tF62m7MjopLEjAufj+RHB jZQHwA8CL5TVxFAQmJ8wDFE+5CAwj4qru7MbpAYn1njH780Iqg5frmuGfrB2B5bUXeimrR8uppN FX/dQnG4r/dU1+A== 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: GYxlFWTtJOgEk61ITIIlRybRnLBqwAUTgoBs8eeYCz4_1792493329 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792493337-CD54C87B-B4D0087C/0/0 X-purgate-type: clean X-purgate-size: 2626 Convert the hyperv OnOffAuto property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- accel/whpx/whpx-common.c | 29 ++++++++++------------------- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/accel/whpx/whpx-common.c b/accel/whpx/whpx-common.c index 247e12db8128..187938c02b51 100644 --- a/accel/whpx/whpx-common.c +++ b/accel/whpx/whpx-common.c @@ -22,6 +22,7 @@ #include "qemu/error-report.h" #include "qapi/error.h" #include "qapi/qapi-types-common.h" +#include "qapi/qapi-type-infos-common.h" #include "qapi/qapi-visit-common.h" #include "migration/blocker.h" #include "accel/accel-cpu-target.h" @@ -470,18 +471,11 @@ static void whpx_set_kernel_irqchip(Object *obj, Visitor *v, } } -static void whpx_set_hyperv(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static void whpx_set_hyperv(Object *obj, int value, Error **errp) { struct whpx_state *whpx = &whpx_global; - OnOffAuto mode; - if (!visit_type_OnOffAuto(v, name, &mode, errp)) { - return; - } - - switch (mode) { + switch (value) { case ON_OFF_AUTO_ON: whpx->hyperv_enlightenments_allowed = true; whpx->hyperv_enlightenments_required = true; @@ -497,11 +491,7 @@ static void whpx_set_hyperv(Object *obj, Visitor *v, whpx->hyperv_enlightenments_required = false; break; default: - /* - * The value was checked in visit_type_OnOffAuto() above. If - * we get here, then something is wrong in QEMU. - */ - abort(); + g_assert_not_reached(); } } @@ -533,11 +523,12 @@ static void whpx_accel_class_init(ObjectClass *oc, const void *data) NULL, NULL); object_class_property_set_description(oc, "kernel-irqchip", "Configure WHPX in-kernel irqchip"); - object_class_property_add(oc, "hyperv", "OnOffAuto", - NULL, whpx_set_hyperv, - NULL, NULL); - object_class_property_set_description(oc, "hyperv", - "Configure Hyper-V enlightenments"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "hyperv", + .description = "Configure Hyper-V enlightenments", + .qapi_type = &OnOffAuto_type_info, + .set = whpx_set_hyperv, + )); whpx_arch_accel_class_init(oc); } -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455332.1669090 (Exim 4.92) (envelope-from ) id 1xJ7WQ-0000ae-Qe; Tue, 20 Oct 2026 10:56:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455332.1669090; Tue, 20 Oct 2026 10: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 1xJ7WP-0000Rd-9z; Tue, 20 Oct 2026 10:56:45 +0000 Received: by outflank-mailman (input) for mailman id 1455332; Tue, 20 Oct 2026 10:50:58 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qo-00006f-MJ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:50:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qo-004d40-3B for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:50:58 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74790-8faa-0a2a0a5109dd-0a2a450be49e-8 for ; Tue, 20 Oct 2026 12:50:58 +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 6ad746a0-b7e8-0a2a450b0019-aa0a857cb4b9-3 for ; Tue, 20 Oct 2026 12:46: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-66-08VlUpjQOgagH2hPOiBlKQ-1; Tue, 20 Oct 2026 06:46:51 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id ACB211956044; Tue, 20 Oct 2026 10:46:46 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8DCE25BC; Tue, 20 Oct 2026 10:46: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=1792493216; 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=1Mnn0OKxBD8aP9I5qh8TLkmYe32toylT7CmahJ3BKVM=; b=aRlEL/EKjLDgdfRlni9gHnXSERJVF4eZKFHu9aBXnfOuM3xWX4PZsr+d3kWqML647r1KxO vGjgtQTugTAHHMwnqfVUXr2pXshbCWGyg8MfkiRdfrj4vT70rHotICYF+qtNOweKEH2/gv koMWV3El6LV25ip8ifmgDgmSAr+f1xY= X-MC-Unique: 08VlUpjQOgagH2hPOiBlKQ-1 X-Mimecast-MFC-AGG-ID: 08VlUpjQOgagH2hPOiBlKQ_1792493207 From: marcandre.lureau@redhat.com Date: Tue, 20 Oct 2026 14:45:23 +0400 Subject: [PATCH v7 06/65] qapi/introspect: Tweak integer type masking MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-6-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=3300; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=Xp7N7Cw12fT4B5RHyRwaz0UVvBY0Z8fxHr38SNSrB2w=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZY+HBluuWmLicnFhqmNZvedYN8EZPAWD5tz upmO1Ga58aJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5XzlD/9HEY5z6oC69wenr9Qv7msxCbEfY7YI+AvbI4TE33VpTsB5TXw0w5hoWWG2I7nT0pxMrC6 gjxcavbpLfNQuSlpsicTsD9FELzSz+6xM2MwthryKshrqOQ9eRIaSYzYj3XG7snmj5JTIp1NNtv uGyxTUY11F5thO0nh78pl5m3FnMgJ6J+bR4QZEixKMGDsWgdCBjFf35n+hs8Zq0TNqPPWdZM4WU 57QEO3MxpnUTcn8ZIAlxz7YffgWnpU+luA9bZzFqcMNqPeQ/+RHcjv3I6UUIkEAQsDNF+gvnDrJ 0A0Spg+6FzMovmlLnKdyDNOj6AaNgCwSBLwxZYMfMpx3I4QGmDOSrKcbVpOnh6MpSqeem9v3E/A s/LAha/LFAADBkXjPbHEKPDdUytOKctZ5gi0Ohky86vcCzQBcxOVOnk4PcWYQrzYFwj9TPpC2xi deGrYMAo64/fK+8aRp2ADj0fVj4WgnOQ5R5PVEbkxEjGkosB3xcpxKcWBrP+aSookP2fMF0jWZb lKHZmcLSlzz257XcK6F/9t5jcM17+nvcivFb2k3m2Zgtv47ZxI2g3D7m4GndVEQKFcBhq2PLDyJ 1YX7I6YK/eWF/FLjTA8Tfv5IJA62HbC6KqrK/8ewzPwZHbkgvIrqnvS4oQ6Mkv3S4l3TDiGWTv8 1WOmqtKMlpy+WEQ== 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: jI1_K7Azoyc5huIZJ8ORYOUgthqX3V6_MK4I88uhwE0_1792493207 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493217-182F49EA-FE0A7697/0/0 X-purgate-type: clean X-purgate-size: 3349 From: Markus Armbruster Since introspection maps all integer types to 'int', we need to skip all but one of them. Instead of filtering by hardcoded name, filter out duplicates. Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau --- scripts/qapi/introspect.py | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/scripts/qapi/introspect.py b/scripts/qapi/introspect.py index 15302ecf155a..dc6f70a6fe9e 100644 --- a/scripts/qapi/introspect.py +++ b/scripts/qapi/introspect.py @@ -172,7 +172,7 @@ def __init__(self, prefix: str, unmask: bool): ' * QAPI/QMP schema introspection', __doc__) self._unmask = unmask self._schema: Optional[QAPISchema] = None - self._trees: List[Annotated[SchemaInfo]] = [] + self._trees: Dict[str, Annotated[SchemaInfo]] = {} self._genc.add(mcgen(''' #include "qemu/osdep.h" #include "%(prefix)sqapi-introspect.h" @@ -191,13 +191,14 @@ def visit_end(self) -> None: extern const QLitObject %(c_name)s; ''', c_name=c_name(name))) + trees = list(self._trees.values()) self._genc.add(mcgen(''' const QLitObject %(c_name)s = %(c_string)s; ''', c_name=c_name(name), - c_string=_tree_to_qlit(self._trees))) + c_string=_tree_to_qlit(trees))) self._schema = None - self._trees = [] + self._trees = {} def _name(self, name: str) -> str: assert self._schema @@ -235,7 +236,12 @@ def _gen_tree(self, name: str, mtype: str, obj: Dict[str, object], obj['meta-type'] = mtype if features: obj['features'] = self._gen_features(features) - self._trees.append(Annotated(obj, ifcond, comment)) + if introspection_name in self._trees: + # Duplicates are possible because + # QAPISchemaBuiltinType.introspection_name() returns 'int' + # for all integer types. Ignore them. + return + self._trees[introspection_name] = Annotated(obj, ifcond, comment) def _gen_enum_member(self, member: QAPISchemaEnumMember ) -> Annotated[SchemaInfoEnumMember]: @@ -268,8 +274,6 @@ def _gen_variant(self, variant: QAPISchemaVariant def visit_builtin_type(self, name: str, info: Optional[QAPISourceInfo], json_type: str) -> None: - if json_type == 'int' and name != 'int': - return self._gen_tree(name, 'builtin', {'json-type': json_type}) def visit_enum_type(self, name: str, info: Optional[QAPISourceInfo], @@ -287,8 +291,6 @@ def visit_enum_type(self, name: str, info: Optional[QAPISourceInfo], def visit_array_type(self, name: str, info: Optional[QAPISourceInfo], ifcond: QAPISchemaIfCond, element_type: QAPISchemaType) -> None: - if element_type.json_type() == 'int' and name != 'intList': - return element = self._use_type(element_type) self._gen_tree(name, 'array', {'element-type': element}, ifcond) -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455338.1669099 (Exim 4.92) (envelope-from ) id 1xJ7WT-00013j-2I; Tue, 20 Oct 2026 10:56:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455338.1669099; Tue, 20 Oct 2026 10:56: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 1xJ7WR-0000wz-MG; Tue, 20 Oct 2026 10:56:47 +0000 Received: by outflank-mailman (input) for mailman id 1455338; Tue, 20 Oct 2026 10:51:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qq-00008C-W7 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qq-004d40-Cd for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:00 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7478b-8faa-0a2a0a5109dd-0a2a4504bc34-40 for ; Tue, 20 Oct 2026 12:51:00 +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 6ad746de-b57f-0a2a45040019-aa0a857c5929-3 for ; Tue, 20 Oct 2026 12:47:59 +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-378-qnN94N6QPK2vA93ceMbHjQ-1; Tue, 20 Oct 2026 10:47:46 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9161F1955F02; Tue, 20 Oct 2026 10:47:41 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 15EC75BC; Tue, 20 Oct 2026 10:47: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=1792493278; 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=w3CoU0QuGNI+p7I3jy6WGQ0mlfEWpp4sXXt2/m2QXAI=; b=D+0o74KQQ/iAzz0i6BCX0iYkV8kwbgbBlC5SeZmlId+ZVB1an4olzwd2sx3Q6iqbAmARQN UPNXlPvjfx2/KNvgib4gZEpJxuSrul+pWwu1U2/WTo+ecqwPMsI55eSxu3/LNsYB9XTHKI HeSSg4nOjGNgaTWd0LT5yOMIJ9Gcfw4= X-MC-Unique: qnN94N6QPK2vA93ceMbHjQ-1 X-Mimecast-MFC-AGG-ID: qnN94N6QPK2vA93ceMbHjQ_1792493261 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:33 +0400 Subject: [PATCH v7 16/65] qom: add object_{class_}property_add_qapi MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-16-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=4847; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=Kq06N3iO6F8AhEf3w27s03u+jnvcQuJjGRRe4Zmd+Hw=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYIBdWrkS5tz+9/UTddwYES8EXuUjGwwr7o DY/JyPpfPaJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5YwTEACxwwoxioLPKJmAISYmT8CzcjaWz6/mg9O/RdNTtr/Qe5SgKfnNgHmYpowIFXzfKxXxVk0 B1ORjczYVaJ2+0sEYatt98MR4cL6Hv6jxJmuNPVhuZm/dGP4xT8zjDnqPWrzyhuGDnRW314fM0G cs/+K/C+Nwe2hpLMybC8gw/whDhlPfHu8KTvLEBX5v7tKzgP6D7PedIBYWNwqFSmpuO0PlQuMHR vN33ahh98LvZbfbEhdgO2kdICQMa0DUZEF3ng3OASLe7+t8JVNn+KdmUEBihcL1bJKaAVpj30Xa akndT9MZhwYvZw095fcPoxfNhNpNXbRLhzvdGBMkE2j3b8DxfYnc+JFviLUfeaEL/RnpAHO/io7 w903ZGKDrm8kPlKsMwWsMLrWGdPLR5Kc5NsiK0+s+/lExqWl6WXGAKpJ1XWiI9SvSRFr+pT8sRG YQnTqX+5yjvMZjHUf8jZ5kJOLYZxU/73vOGIBhxLDvlVywwQz+b5C3azNqGdFSLYqf+PbAJiruh g7uaTSrEABrr0xm+UN5VZL/yxAJEyP0wzq4K8tg3ZRfb9EeYCKYxoaRTQnBz5hWjPVnJbnUqt4X lIR0HJed6Cwk5m/Qb1NAZshRIkE3JTkSJUbwmlB1M99oPiceyZi0qG1emOPy0nq/lenfk9B+FRX AIGs9zGqOul8NUQ== 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: TpKASW0VFf-FnefmHBsslcMz2r6KW0Xvst0dpP9wvGU_1792493261 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792493279-C1CD7B50-9FABBD01/0/0 X-purgate-type: clean X-purgate-size: 4849 Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- include/qom/object.h | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++ qom/object.c | 32 ++++++++++++++++++++++++++++++ 2 files changed, 87 insertions(+) diff --git a/include/qom/object.h b/include/qom/object.h index 2a5723c555e9..eb61d8842b80 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -2027,6 +2027,61 @@ ObjectProperty *object_class_property_add_enum(ObjectClass *klass, int (*get)(Object *, Error **), void (*set)(Object *, int, Error **)); +/** + * object_property_add_qapi: + * @obj: the object to add a property to + * @name: the name of the property + * @qapi_type: QAPI type info descriptor + * @get: The getter to be called to read a property. If this is NULL, then + * the property cannot be read. + * @set: the setter to be called to write a property. If this is NULL, + * then the property cannot be written. + * @release: called when the property is removed from the object. This is + * meant to allow a property to free its opaque upon object + * destruction. This may be NULL. + * @opaque: an opaque pointer to pass to the callbacks for the property + * + * Add a property with a QAPI type association. The property type name + * is derived from @qapi_type->name. + * + * Returns: The newly added property on success, or %NULL on failure. + */ +ObjectProperty * +object_property_add_qapi(Object *obj, const char *name, + const QAPITypeInfo *qapi_type, + ObjectPropertyAccessor *get, + ObjectPropertyAccessor *set, + ObjectPropertyRelease *release, + void *opaque); + +/** + * object_class_property_add_qapi: + * @klass: the object class to add a property to + * @name: the name of the property + * @qapi_type: QAPI type info descriptor + * @get: The getter to be called to read a property. If this is NULL, then + * the property cannot be read. + * @set: the setter to be called to write a property. If this is NULL, + * then the property cannot be written. + * @release: called when the property is removed from the object. This is + * meant to allow a property to free its opaque upon object + * destruction. This may be NULL. + * @opaque: an opaque pointer to pass to the callbacks for the property + * + * Add a property with a QAPI type association. The property type name + * is derived from @qapi_type->name. + * + * Returns: The newly added property on success, or %NULL on failure. + */ +ObjectProperty * +object_class_property_add_qapi(ObjectClass *klass, + const char *name, + const QAPITypeInfo *qapi_type, + ObjectPropertyAccessor *get, + ObjectPropertyAccessor *set, + ObjectPropertyRelease *release, + void *opaque); + /** * object_property_add_tm: * @obj: the object to add a property to diff --git a/qom/object.c b/qom/object.c index 1d09315b328b..bebbfc43556d 100644 --- a/qom/object.c +++ b/qom/object.c @@ -2609,6 +2609,38 @@ object_class_property_add_enum(ObjectClass *klass, const char *name, prop); } +ObjectProperty * +object_property_add_qapi(Object *obj, const char *name, + const QAPITypeInfo *qapi_type, + ObjectPropertyAccessor *get, + ObjectPropertyAccessor *set, + ObjectPropertyRelease *release, + void *opaque) +{ + ObjectProperty *prop; + + prop = object_property_add(obj, name, qapi_type->name, + get, set, release, opaque); + prop->qapi_type = qapi_type; + return prop; +} + +ObjectProperty * +object_class_property_add_qapi(ObjectClass *klass, const char *name, + const QAPITypeInfo *qapi_type, + ObjectPropertyAccessor *get, + ObjectPropertyAccessor *set, + ObjectPropertyRelease *release, + void *opaque) +{ + ObjectProperty *prop; + + prop = object_class_property_add(klass, name, qapi_type->name, + get, set, release, opaque); + prop->qapi_type = qapi_type; + return prop; +} + typedef struct TMProperty { void (*get)(Object *, struct tm *, Error **); } TMProperty; -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455339.1669109 (Exim 4.92) (envelope-from ) id 1xJ7WV-0001XL-Pk; Tue, 20 Oct 2026 10:56:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455339.1669109; Tue, 20 Oct 2026 10:56: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 1xJ7WT-0001Rj-Qg; Tue, 20 Oct 2026 10:56:49 +0000 Received: by outflank-mailman (input) for mailman id 1455339; Tue, 20 Oct 2026 10:51:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qr-00008Y-SV for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qr-002FXm-9J for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:01 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74783-bab6-0a2a0a5309dd-0a2a450695a8-38 for ; Tue, 20 Oct 2026 12:51:01 +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 6ad74793-195a-0a2a45060019-aa0a817ce921-3 for ; Tue, 20 Oct 2026 12:51:01 +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-47-CrQK4deUNTad1FIQ0b2Mjg-1; Tue, 20 Oct 2026 06:50:50 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F3CE01954194; Tue, 20 Oct 2026 10:50:46 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B3F891956088; Tue, 20 Oct 2026 10:50: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=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=1792493459; 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=UI1oOgUjr2C09/42flcMtOL/qp5uyR5nZp4lNbzLhMM=; b=aBcpfFks5R2JtW3NhoETeQXUYT2rpM7YPXqSibr/ZjfBs9N0eqw6qdWoZ4IsDtYLzThO+j me6pmCJ3rmWDYqVxVY4lXIAquWMAY8K2sG3rcEGofGbIo9PxKmmZ9/LhQwplKUSEFSNo2H 59feevwZ3PJrLVW2kIV/5CuL/wOkSAU= X-MC-Unique: CrQK4deUNTad1FIQ0b2Mjg-1 X-Mimecast-MFC-AGG-ID: CrQK4deUNTad1FIQ0b2Mjg_1792493447 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:07 +0400 Subject: [PATCH v7 50/65] hw/gpio/pca955x: convert pin/led property to QAPI-aware enum MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-50-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=18182; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=/T2C1S926CriVURvy1V0b555zaz9n8rbWnuo7vsoD8E=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Zc/MyZjsGCSo1em3rwgIrcI3my50hA6ArKg XY6eoCG8OOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5WerD/9ns1InvVwABVk1Ky8TEmeyVcSbJeoQ9nMEgwkTHwjl6qy+A2E4Cjjp5FAOPp7vSLb1FVz ZXMI8PMPr4JEzANxAvBYlnRoEGPZWbJJLf767vjKnD8shLpXlXhnvL9alhzbcNGyXIkOUELKEGB P4mM2H4U9fK8o3tgDeq4H0SEsbQVrgGpKJ27O9m7ISTwXbHhZ2ZBBLm4DQguo/iU1/kJ5Rgp9DD vlZFzPj+Ou/pP1RN7vLgr+2VKDcu6BSThcuqpOnYT/g7z14okU02LhRu/+3E4siXVFTnLUMc9kP W36YY8NastaSyEKVu3Y8pSvJiiTk0LClt+biOdN06lDl5EeoLSyczPFdPrfibyX5qyqz35XJfvf SLw9HQCVxO9o+9cACPrRm31c8Q0pHEpDEs6p12Jk0YhG7LSCGOL3smAcPDNSwqA8VE6ea5paj7z 74Tr28SsZAahFvb95zAmoYTZmaobkL/CnrvnQJDmnJgaA2EBKeYSj2COvwCHP1zz6zzbY2ySv6g vCVkOGb3B2VMQVrjOQg68OiiNgB9U+5qCBJkyzHVLXTebevqwzcbalEFgE2RHHzL3tbBq/ecpRG HWNo20RnvrQvpG9pxYxhGmGni7lpSdZzHnm/WuJYaHbEgwLAwAAvYXD1+eTxTM6Lx7smAXkFK2l xSsQ6OzWsYMuwNw== 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: Fh5QFf8XGwno5fvV-EcJBDueGcckmhwG1uxEu3QyQlk_1792493447 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1792493461-F5E0E77B-BBE043D4/0/0 X-purgate-type: clean X-purgate-size: 18184 Replaces the runtime-parsed visitor-based QOM property accessors with compile-time per-pin/per-LED accessor functions using QEMU_REPEAT. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/gpio/pca9552.c | 205 +++++++++++++++++++++--------------------------------- hw/gpio/pca9554.c | 136 ++++++++++++++---------------------- 2 files changed, 131 insertions(+), 210 deletions(-) diff --git a/hw/gpio/pca9552.c b/hw/gpio/pca9552.c index 16741c22dea3..0a007bbbe4ac 100644 --- a/hw/gpio/pca9552.c +++ b/hw/gpio/pca9552.c @@ -25,6 +25,7 @@ #include "qapi/error.h" #include "qapi/qapi-types-machine.h" #include "qapi/qapi-visit-machine.h" +#include "qapi/qapi-type-infos-machine.h" #include "trace.h" #include "qom/object.h" @@ -354,33 +355,6 @@ static int pca955x_event(I2CSlave *i2c, enum i2c_event event) return 0; } -static void pca955x_get_led(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - PCA955xClass *k = PCA955X_GET_CLASS(obj); - PCA955xState *s = PCA955X(obj); - int led, rc, reg; - Pca9552LedState state; - - rc = sscanf(name, "led%2d", &led); - if (rc != 1) { - error_setg(errp, "%s: error reading %s", __func__, name); - return; - } - if (led < 0 || led >= k->pin_count) { - error_setg(errp, "%s: invalid led %s", __func__, name); - return; - } - /* - * Get the LSx register as the qom interface should expose the device - * state, not the modeled 'input line' behaviour which would come from - * reading the INPUTx reg - */ - reg = PCA9552_LS0 + led / 4; - state = (pca955x_read(s, reg) >> ((led % 4) * 2)) & 0x3; - visit_type_Pca9552LedState(v, name, &state, errp); -} - /* * Return an LED selector register value based on an existing one, with * the appropriate 2-bit state value set for the given LED number (0-3). @@ -391,97 +365,8 @@ static inline uint8_t pca955x_ledsel(uint8_t oldval, int led_num, int state) ((state & 0x3) << (led_num << 1)); } -static void pca955x_set_led(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - PCA955xClass *k = PCA955X_GET_CLASS(obj); - PCA955xState *s = PCA955X(obj); - int led, rc, reg, val; - Pca9552LedState state; - - if (!visit_type_Pca9552LedState(v, name, &state, errp)) { - return; - } - rc = sscanf(name, "led%2d", &led); - if (rc != 1) { - error_setg(errp, "%s: error reading %s", __func__, name); - return; - } - if (led < 0 || led >= k->pin_count) { - error_setg(errp, "%s: invalid led %s", __func__, name); - return; - } - - reg = PCA9552_LS0 + led / 4; - val = pca955x_read(s, reg); - val = pca955x_ledsel(val, led % 4, state); - pca955x_write(s, reg, val); -} - static void pca955x_set_ext_state(PCA955xState *s, int pin, int level); -static void pca955x_get_pin(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - PCA955xClass *k = PCA955X_GET_CLASS(obj); - PCA955xState *s = PCA955X(obj); - int pin, rc; - uint8_t input_reg; - Pca9552PinState state; - - rc = sscanf(name, "pin%2d", &pin); - if (rc != 1) { - error_setg(errp, "%s: error reading %s", __func__, name); - return; - } - if (pin < 0 || pin >= k->pin_count) { - error_setg(errp, "%s invalid pin %s", __func__, name); - return; - } - - /* - * Report the raw pin logic level; polarity inversion is a read-time - * transform applied to the INPUT register, not to the pin state itself. - */ - input_reg = PCA9535_INPUT0 + (pin / 8); - state = (s->regs[input_reg] >> (pin % 8)) & 0x1; - visit_type_Pca9552PinState(v, name, &state, errp); -} - -static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - PCA955xClass *k = PCA955X_GET_CLASS(obj); - PCA955xState *s = PCA955X(obj); - int pin, rc; - Pca9552PinState state; - uint8_t config_reg; - - if (!visit_type_Pca9552PinState(v, name, &state, errp)) { - return; - } - rc = sscanf(name, "pin%2d", &pin); - if (rc != 1) { - error_setg(errp, "%s: error reading %s", __func__, name); - return; - } - if (pin < 0 || pin >= k->pin_count) { - error_setg(errp, "%s invalid pin %s", __func__, name); - return; - } - - /* Only input-configured pins can be driven by an external device. */ - config_reg = PCA9535_CONFIG0 + (pin / 8); - if (!((s->regs[config_reg] >> (pin % 8)) & 0x1)) { - qemu_log_mask(LOG_UNIMP, - "%s: pin %d is configured as output, ignoring set\n", - s->description, pin); - return; - } - - pca955x_set_ext_state(s, pin, state != PCA9552_PIN_STATE_LOW); -} - static const VMStateDescription pca9552_vmstate = { .name = "PCA9552", .version_id = 0, @@ -536,26 +421,92 @@ static void pca9535_reset_hold(Object *obj, ResetType type) s->len = 0; } +/* + * Get the LSx register as the qom interface should expose the device + * state, not the modeled 'input line' behaviour which would come from + * reading the INPUTx reg + */ +#define DEFINE_LED_ACCESSORS(n) \ +static int prop_get_led##n(Object *obj, Error **errp) \ +{ \ + PCA955xState *s = PCA955X(obj); \ + uint8_t reg = PCA9552_LS0 + (n) / 4; \ + return (pca955x_read(s, reg) >> (((n) % 4) * 2)) & 0x3; \ +} \ +static void prop_set_led##n(Object *obj, int val, Error **errp) \ +{ \ + PCA955xState *s = PCA955X(obj); \ + uint8_t reg = PCA9552_LS0 + (n) / 4; \ + uint8_t old = pca955x_read(s, reg); \ + pca955x_write(s, reg, pca955x_ledsel(old, (n) % 4, val)); \ +} + +QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, DEFINE_LED_ACCESSORS) + +#define LED_ENUM_PROP(n) { \ + .name = "led" #n, \ + .default_value = -1, \ + .qapi_type = &Pca9552LedState_type_info, \ + .get = prop_get_led##n, \ + .set = prop_set_led##n, \ +}, + +static const QapiEnumProp led_enum_props[] = { + QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, LED_ENUM_PROP) +}; + +/* + * Report the raw pin logic level; polarity inversion is a read-time + * transform applied to the INPUT register, not to the pin state + * itself. + */ +#define DEFINE_PIN_ACCESSORS(n) \ +static int prop_get_pin##n(Object *obj, Error **errp) \ +{ \ + PCA955xState *s = PCA955X(obj); \ + uint8_t input_reg = PCA9535_INPUT0 + (n) / 8; \ + return (s->regs[input_reg] >> ((n) % 8)) & 0x1; \ +} \ +static void prop_set_pin##n(Object *obj, int val, Error **errp) \ +{ \ + PCA955xState *s = PCA955X(obj); \ + uint8_t config_reg = PCA9535_CONFIG0 + (n) / 8; \ + /* Only input-configured pins can be driven by an external device */ \ + if (!((s->regs[config_reg] >> ((n) % 8)) & 0x1)) { \ + qemu_log_mask(LOG_UNIMP, \ + "%s: pin %d configured as output, ignoring set\n", \ + s->description, (n)); \ + return; \ + } \ + pca955x_set_ext_state(s, (n), val != PCA9552_PIN_STATE_LOW); \ +} + +QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, DEFINE_PIN_ACCESSORS) + +#define PIN_ENUM_PROP(n) { \ + .name = "pin" #n, \ + .default_value = -1, \ + .qapi_type = &Pca9552PinState_type_info, \ + .get = prop_get_pin##n, \ + .set = prop_set_pin##n, \ +}, + +static const QapiEnumProp pin_enum_props[] = { + QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, PIN_ENUM_PROP) +}; + static void pca955x_initfn(Object *obj) { PCA955xClass *k = PCA955X_GET_CLASS(obj); assert(k->pin_count <= PCA955X_PIN_COUNT_MAX); + /* TODO: use array/list instead of individual QAPI enum properties */ for (int ix = 0; ix < k->pin_count; ix++) { - char *name; - if (k->has_led_support) { - /* LED variant: expose the LED selector state as led%d. */ - name = g_strdup_printf("led%d", ix); - object_property_add(obj, name, "Pca9552LedState", - pca955x_get_led, pca955x_set_led, NULL, NULL); + object_property_add_qapi_enum(obj, &led_enum_props[ix]); } else { - /* GPIO variant: expose the pin logic level as pin%d. */ - name = g_strdup_printf("pin%d", ix); - object_property_add(obj, name, "Pca9552PinState", - pca955x_get_pin, pca955x_set_pin, NULL, NULL); + object_property_add_qapi_enum(obj, &pin_enum_props[ix]); } - g_free(name); } } diff --git a/hw/gpio/pca9554.c b/hw/gpio/pca9554.c index e4eddc829ef7..f2a5b94a36d8 100644 --- a/hw/gpio/pca9554.c +++ b/hw/gpio/pca9554.c @@ -18,7 +18,7 @@ #include "qapi/error.h" #include "qapi/qapi-types-machine.h" #include "qapi/qapi-visit-machine.h" -#include "qapi/visitor.h" +#include "qapi/qapi-type-infos-machine.h" #include "trace.h" #include "qom/object.h" @@ -151,83 +151,60 @@ static void pca9554_set_ext_state(PCA9554State *s, int pin, int level) } } -static void pca9554_get_pin(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - PCA9554State *s = PCA9554(obj); - int pin, rc; - Pca9554PinState state; - - rc = sscanf(name, "pin%2d", &pin); - if (rc != 1) { - error_setg(errp, "%s: error reading %s", __func__, name); - return; - } - if (pin < 0 || pin >= PCA9554_GET_CLASS(s)->pin_count) { - error_setg(errp, "%s invalid pin %s", __func__, name); - return; - } - - /* - * Report the physical pin level. The input register is kept in sync by - * pca9554_update_pin_input(): output pins mirror the OUTPUT register and - * input pins reflect the externally driven (or pulled-up) level, so it - * holds the wire level regardless of the configured direction. - */ - state = (s->regs[PCA9554_INPUT] >> pin) & 0x1; - visit_type_Pca9554PinState(v, name, &state, errp); +/* + * Report the physical pin level. The input register is kept in sync + * by pca9554_update_pin_input(): output pins mirror the OUTPUT + * register and input pins reflect the externally driven (or + * pulled-up) level, so it holds the wire level regardless of the + * configured direction. + */ +#define DEFINE_PIN_ACCESSORS(n) \ +static int prop_get_pin##n(Object *obj, Error **errp) \ +{ \ + PCA9554State *s = PCA9554(obj); \ + return (s->regs[PCA9554_INPUT] >> (n)) & 0x1; \ +} \ +static void prop_set_pin##n(Object *obj, int val, Error **errp) \ +{ \ + PCA9554State *s = PCA9554(obj); \ + if (s->hw_dir) { \ + if (!((s->regs[PCA9554_CONFIG] >> (n)) & 0x1)) { \ + qemu_log_mask(LOG_UNIMP, \ + "%s: pin %d configured as output," \ + " ignoring set\n", \ + s->description, (n)); \ + return; \ + } \ + pca9554_set_ext_state(s, (n), val != PCA9554_PIN_STATE_LOW); \ + } else { \ + /* Legacy behavior: force output mode and drive */ \ + uint8_t mask = 0x1 << (n); \ + int v = pca9554_read(s, PCA9554_OUTPUT); \ + if (val == PCA9554_PIN_STATE_LOW) { \ + v &= ~mask; \ + } else { \ + v |= mask; \ + } \ + pca9554_write(s, PCA9554_OUTPUT, v); \ + v = pca9554_read(s, PCA9554_CONFIG); \ + v &= ~mask; \ + pca9554_write(s, PCA9554_CONFIG, v); \ + } \ } -static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - PCA9554State *s = PCA9554(obj); - int pin, rc, val; - uint8_t mask; - Pca9554PinState state; +QEMU_REPEAT(PCA9554_PIN_COUNT, DEFINE_PIN_ACCESSORS) - if (!visit_type_Pca9554PinState(v, name, &state, errp)) { - return; - } - rc = sscanf(name, "pin%2d", &pin); - if (rc != 1) { - error_setg(errp, "%s: error reading %s", __func__, name); - return; - } - if (pin < 0 || pin >= PCA9554_GET_CLASS(s)->pin_count) { - error_setg(errp, "%s invalid pin %s", __func__, name); - return; - } +#define PIN_ENUM_PROP(n) { \ + .name = "pin" #n, \ + .default_value = -1, \ + .qapi_type = &Pca9554PinState_type_info, \ + .get = prop_get_pin##n, \ + .set = prop_set_pin##n, \ +}, - if (s->hw_dir) { - /* Warn and ignore if the guest has configured this pin as output */ - if (!((s->regs[PCA9554_CONFIG] >> pin) & 0x1)) { - qemu_log_mask(LOG_UNIMP, - "%s: pin %d is configured as output, " - "ignoring external set\n", - s->description, pin); - return; - } - /* Drive the external input level */ - pca9554_set_ext_state(s, pin, state != PCA9554_PIN_STATE_LOW); - } else { - /* Legacy behavior: force output mode and drive */ - /* First, modify the output register bit */ - val = pca9554_read(s, PCA9554_OUTPUT); - mask = 0x1 << pin; - if (state == PCA9554_PIN_STATE_LOW) { - val &= ~(mask); - } else { - val |= mask; - } - pca9554_write(s, PCA9554_OUTPUT, val); - - /* Then, clear the config register bit for output mode */ - val = pca9554_read(s, PCA9554_CONFIG); - val &= ~mask; - pca9554_write(s, PCA9554_CONFIG, val); - } -} +static const QapiEnumProp pin_enum_props[] = { + QEMU_REPEAT(PCA9554_PIN_COUNT, PIN_ENUM_PROP) +}; static const VMStateDescription pca9554_vmstate = { .name = "PCA9554", @@ -264,16 +241,9 @@ static void pca9554_reset(DeviceState *dev) static void pca9554_initfn(Object *obj) { PCA9554Class *pc = PCA9554_GET_CLASS(obj); - int pin; - for (pin = 0; pin < pc->pin_count; pin++) { - char *name; - - name = g_strdup_printf("pin%d", pin); - object_property_add(obj, name, "Pca9554PinState", - pca9554_get_pin, pca9554_set_pin, - NULL, NULL); - g_free(name); + for (int pin = 0; pin < pc->pin_count; pin++) { + object_property_add_qapi_enum(obj, &pin_enum_props[pin]); } } -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455340.1669116 (Exim 4.92) (envelope-from ) id 1xJ7WW-0001tB-PF; Tue, 20 Oct 2026 10:56:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455340.1669116; Tue, 20 Oct 2026 10:56: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 1xJ7WV-0001oh-Ax; Tue, 20 Oct 2026 10:56:51 +0000 Received: by outflank-mailman (input) for mailman id 1455340; Tue, 20 Oct 2026 10:51:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qt-00009G-KK for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qt-00CrlS-17 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74795-2eae-0a2a0a5409dd-0a2a4504e546-20 for ; Tue, 20 Oct 2026 12:51:03 +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 6ad746e1-b57f-0a2a45040019-aa0a857c95db-3 for ; Tue, 20 Oct 2026 12:48: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-624-Yh3hFIQYORWMSyn7dgfYTg-1; Tue, 20 Oct 2026 10:47:56 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 64C7A1955EBF; Tue, 20 Oct 2026 10:47:52 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7DD3F1803A59; Tue, 20 Oct 2026 10:47: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=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=1792493281; 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=QCsJ6kicmUEQxvaxmAE24eNtz/CdTOeeNBSuCmDZMU8=; b=FRnFS5+mMpfAa5h+Ky/2Ig9z6W4JQKW/c8vOfqJV7SHaaJa6MCTDVDw8wNU6TNgv48J//Y /mnA9HrMIr+lp8NkFsfburrw6fcOj4rr51GPlLhtrn2cTwSp3IwcRH7GET+M8W+NLElR26 ZhIWj2AWpE/nheQJndq7M6Zj118gnqw= X-MC-Unique: Yh3hFIQYORWMSyn7dgfYTg-1 X-Mimecast-MFC-AGG-ID: Yh3hFIQYORWMSyn7dgfYTg_1792493272 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:35 +0400 Subject: [PATCH v7 18/65] tests: update check-qom-proplist for QAPI-aware property registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-18-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=5424; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=PG77OxkKQyF3UcxTgSF0ItIIQR9h6IXM0cn9v6bEm2s=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZx0j1p4X5AH6xbN8P7cVXiebxN4/NouqlD Bs0dZkcTS6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5btyD/sEpsN54WFVkoxy/MA7ND5ExbGYknt3DZedYvvU6rJFWigzxdRqfgu17q4W5zjE+AamjfL BupH4gTHx7+2HfkN3D1gTx/xFdM5Kl6ToEoiDKjNOo862W3jNyyg4ovmX4tTnGNMAz88AfPwhL+ 2ZWNFNzjipqIGY0qQX4Bx66aa2+YE4fY3hQ9iiu+WjFc6AbgnPg4TF4XhUyHF70who98clFVOMD yjczx/5tD0aUOR4P15K6+ixi33/auB4tE1Iwmnx/jgl1p3xCy28fffjfyI9wgZwkX2u2stbYLIn lDbgxSH1ReWWj7z4XdgyxwniV2xbBYeYJEkOtCV/y7/dK6+AM+a7Qnq3kI/dzYhJuvhq5wU+HGR RiM76TgllhaUHS8VdrKmAFY/LmMaDcf5u+dyeDe3ragYCi0YRneV87Q3JrrFqhWtzDyLlEBLQBg R2RYEWwbUq91SYc+sy3M2s1dxK/Auw8r9jDxBr9VPRZeaKJzAr1tPm6hnSzp+dkR4vgyuSdKfW2 xgnVBc5i1OBtTZMbay85wjtkAfGfPH5jqgFBr3+8p6u1r9UH55oNAmVqy1ev7FnV/EBA4FlmSyX 4Ic6VS1CTDmF2CzubrTp3nVMwtdHRxtTKiFnV+tWJm6wxUGQS0/zDlqzL+ypt2gHRnuRwgDXqHU doz9mjn/aUw3+xw== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: HGrlm3_L3fIgzhIY14LSxG0_sjx69Xo9rnYaU35XMmM_1792493272 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792493282-C34C3B50-F7C8D11F/0/0 X-purgate-type: clean X-purgate-size: 5426 Migrate the dummy object's string and enum properties from the legacy object_class_property_add_str/enum() helpers to the new QAPI-aware object_class_property_add_qapi/qapi_enum() registration. Add test cases verifying that the qapi_type metadata is correctly populated on properties registered through the new API, and that it remains NULL for properties using the old-style registration. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- tests/unit/check-qom-proplist.c | 93 ++++++++++++++++++++++++++++++++++------- 1 file changed, 77 insertions(+), 16 deletions(-) diff --git a/tests/unit/check-qom-proplist.c b/tests/unit/check-qom-proplist.c index 89de92b7d91f..69155e720751 100644 --- a/tests/unit/check-qom-proplist.c +++ b/tests/unit/check-qom-proplist.c @@ -108,22 +108,21 @@ static int dummy_get_av(Object *obj, } -static void dummy_set_sv(Object *obj, - const char *value, - Error **errp) +static void dummy_set_sv(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) { DummyObject *dobj = DUMMY_OBJECT(obj); - g_free(dobj->sv); - dobj->sv = g_strdup(value); + g_clear_pointer(&dobj->sv, g_free); + visit_type_str(v, name, &dobj->sv, errp); } -static char *dummy_get_sv(Object *obj, - Error **errp) +static void dummy_get_sv(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) { DummyObject *dobj = DUMMY_OBJECT(obj); - return g_strdup(dobj->sv); + visit_type_str(v, name, &dobj->sv, errp); } @@ -135,16 +134,28 @@ static void dummy_init(Object *obj) } +static const QAPITypeInfo dummy_animal_qapi_type_info = { + .name = "DummyAnimal", + .masked_name = "DummyAnimalSchema", + .lookup = &dummy_animal_map, +}; + +static const QAPITypeInfo dummy_str_qapi_type_info = { + .name = "str", + .masked_name = "StrSchema", +}; + static void dummy_class_init(ObjectClass *cls, const void *data) { - object_class_property_add_str(cls, "sv", - dummy_get_sv, - dummy_set_sv); - object_class_property_add_enum(cls, "av", - "DummyAnimal", - &dummy_animal_map, - dummy_get_av, - dummy_set_av); + object_class_property_add_qapi(cls, "sv", &dummy_str_qapi_type_info, + dummy_get_sv, dummy_set_sv, + NULL, NULL); + object_class_property_add_qapi_enum(cls, QAPI_ENUM_PROP( + .name = "av", + .qapi_type = &dummy_animal_qapi_type_info, + .get = dummy_get_av, + .set = dummy_set_av, + )); } @@ -703,6 +714,54 @@ static void test_qom_partial_path(void) object_unparent(cont1); } +static void test_dummy_qapi_enum(void) +{ + ObjectProperty *prop; + Object *parent = object_get_objects_root(); + DummyObject *dobj = DUMMY_OBJECT( + object_new_with_props(TYPE_DUMMY, + parent, + "dummy0", + &error_abort, + "av", "platypus", + NULL)); + + g_assert(dobj->av == DUMMY_PLATYPUS); + + prop = object_property_find(OBJECT(dobj), "av"); + g_assert(prop); + g_assert(prop->qapi_type == &dummy_animal_qapi_type_info); + g_assert_cmpstr(prop->qapi_type->name, ==, "DummyAnimal"); + g_assert_cmpstr(prop->qapi_type->masked_name, ==, "DummyAnimalSchema"); + g_assert(prop->qapi_type->lookup == &dummy_animal_map); + + object_unparent(OBJECT(dobj)); +} + +static void test_dummy_qapi_prop(void) +{ + ObjectProperty *prop; + Object *parent = object_get_objects_root(); + DummyObject *dobj = DUMMY_OBJECT( + object_new_with_props(TYPE_DUMMY, + parent, + "dummy0", + &error_abort, + "sv", "hello", + NULL)); + + g_assert_cmpstr(dobj->sv, ==, "hello"); + + prop = object_property_find(OBJECT(dobj), "sv"); + g_assert(prop); + g_assert(prop->qapi_type == &dummy_str_qapi_type_info); + g_assert_cmpstr(prop->qapi_type->name, ==, "str"); + g_assert_cmpstr(prop->qapi_type->masked_name, ==, "StrSchema"); + g_assert(prop->qapi_type->lookup == NULL); + + object_unparent(OBJECT(dobj)); +} + int main(int argc, char **argv) { g_test_init(&argc, &argv, NULL); @@ -727,6 +786,8 @@ int main(int argc, char **argv) g_test_add_func("/qom/proplist/iterator", test_dummy_iterator); g_test_add_func("/qom/proplist/class_iterator", test_dummy_class_iterator); g_test_add_func("/qom/proplist/delchild", test_dummy_delchild); + g_test_add_func("/qom/proplist/qapi_enum", test_dummy_qapi_enum); + g_test_add_func("/qom/proplist/qapi_prop", test_dummy_qapi_prop); g_test_add_func("/qom/resolve/partial", test_qom_partial_path); return g_test_run(); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455343.1669125 (Exim 4.92) (envelope-from ) id 1xJ7WZ-0002QC-Or; Tue, 20 Oct 2026 10:56:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455343.1669125; Tue, 20 Oct 2026 10:56: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 1xJ7WX-0002KG-R4; Tue, 20 Oct 2026 10:56:53 +0000 Received: by outflank-mailman (input) for mailman id 1455343; Tue, 20 Oct 2026 10:51:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qt-00009H-TY for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qt-004d7w-AO for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:03 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74790-8faa-0a2a0a5109dd-0a2a450be49e-38 for ; Tue, 20 Oct 2026 12:51:03 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7471d-b7e8-0a2a450b0019-aa0a817c7943-3 for ; Tue, 20 Oct 2026 12:49:02 +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-517-GSbpLDLrPQqHZRQ94vMg0A-1; Tue, 20 Oct 2026 10:48:59 +0000 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 401F418002AD; Tue, 20 Oct 2026 10:48:55 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4CB201800257; Tue, 20 Oct 2026 10:48:52 +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=1792493341; 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=vqRAumP9Q4P45v+BnAaswZB9eyGK4924nboYOJbbp2E=; b=R1ZglALcFIqD4UxGynC9vb3nFq+Jj2YAK6AuSJmSzfD4w2F1iyswNIuVIgjY3HN0yUGVY/ kE+GlXWLD9Q8Cl/YT5IjWsv9I8ncIITWrpbeEsMmcuf2B9CNmONYq/aSjwv76U2MnvXsra j5vZ5HMcWF+Fmcc1ks2hSfmwAwvSJhI= X-MC-Unique: GSbpLDLrPQqHZRQ94vMg0A-1 X-Mimecast-MFC-AGG-ID: GSbpLDLrPQqHZRQ94vMg0A_1792493335 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:47 +0400 Subject: [PATCH v7 30/65] whpx: convert OnOffAuto arch properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-30-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=6702; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=F8HZ01XPkkBAtzYnAznI+OeIpIRAjOQCT4x6+nWcsZQ=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaNHtr+AkGnY6QtTL0vsHs6SXFQUQ8MQ6i4 S1YABGB6XOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5U3+D/0bY0Yw06OplfGaxwkWeRkmM8vGPJ5F9M0cVeicCg/oXCYp+UKgC78TYi76WRGpbyL2C7S 0KxXaqPjOuPoiru3KbrrdebJxsrbKZijDWmhlIsP9jywqVWMuCB+weipCeiSrSWcM8KYKDNl6lh BAGjS+eZuivN40OoVe2PxA7lKt96RrybUNJq39LwnTdm/8Lx0x5A7nOmtMf6p5zUDEy6bO9wTJ9 /9cnmG5OgUn4fNab0GmXDPDj2/b7lDQNLOZQiOEE1aPD1CnruklCEcrbKrMXEZIYQc9JkVJVviZ sWu3vDJ9GCWP/JGd6P26BcaZeOw6qiIfSjJgGMcE3CyRguBdSr4ldn+yC83f6n9vVa68VDVU85t PoSwXa0eYL0MCuvzu1v2GPnE/oDcMkqhH7+e/tLdejjt7K9jX7qtbmGTnHtszQGZv3Bn0tfV3RM fJtheu+i9GFuCM5MxESNY85RUBO6acenPHsR1+nmHtqbICIGanSHvfZzCXqJL4WwAH/IRbzic4F sB4SZ4sCdErodKNcNWECfUhDwpvmtfzJ5r4PC9kT3qEABypAk8pdibNyUNuaX6p+KJtOwuuQsnA NP6Npp4aqbXBUyIW3gZUAcetZJhmn/V7jRQ/TFEG2uGqdOa3T2YNGJ9TDknE1CAeWkCjRf+IwA6 Z2YAEk2bZvmBjgQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: Xuyrt3XswhHI2RK1JKKZM-_NHEB4wC0uqSybdHo9TwU_1792493335 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493342-1B2DC9EA-5FBEBB9C/0/0 X-purgate-type: clean X-purgate-size: 6704 Convert the ignore-unknown-msr, intercept-msr-gp, and ssd OnOffAuto properties from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- target/i386/whpx/whpx-all.c | 101 +++++++++++++++----------------------------- 1 file changed, 34 insertions(+), 67 deletions(-) diff --git a/target/i386/whpx/whpx-all.c b/target/i386/whpx/whpx-all.c index 113f79afb9ab..64fa389a2f93 100644 --- a/target/i386/whpx/whpx-all.c +++ b/target/i386/whpx/whpx-all.c @@ -30,7 +30,7 @@ #include "qemu/error-report.h" #include "qapi/error.h" #include "qapi/qapi-types-common.h" -#include "qapi/qapi-visit-common.h" +#include "qapi/qapi-type-infos-common.h" #include "migration/blocker.h" #include "host-cpu.h" #include "accel/accel-cpu-target.h" @@ -1875,6 +1875,7 @@ void whpx_apply_breakpoints( } } + void whpx_arch_destroy_vcpu(CPUState *cpu) { X86CPU *x86cpu = X86_CPU(cpu); @@ -1955,7 +1956,7 @@ static int whpx_handle_hyperv_guestidle(CPUState *cpu) return whpx_handle_halt(cpu); } -static void whpx_vcpu_kick_out_of_hlt(CPUState *cpu) +static void whpx_vcpu_kick_out_of_hlt(CPUState *cpu) { WHV_REGISTER_VALUE reg; whpx_get_reg(cpu, WHvRegisterInternalActivityState, ®); @@ -2059,7 +2060,7 @@ static void whpx_vcpu_pre_run(CPUState *cpu) .Vector = irq, }; reg_count += 1; - /* + /* * When the Hyper-V APIC is enabled, to get out of HLT we * either have to request an interrupt or manually get it away * from HLT. @@ -2359,7 +2360,7 @@ int whpx_vcpu_run(CPUState *cpu) WHV_REGISTER_VALUE reg_values[3] = {0}; WHV_REGISTER_NAME reg_names[3]; UINT32 reg_count; - bool is_known_msr = 0; + bool is_known_msr = 0; bool raises_gpf = false; uint64_t val; @@ -2911,120 +2912,86 @@ void whpx_cpu_instance_init(CPUState *cs) * Partition support */ -static void whpx_set_unknown_msr(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static void whpx_set_unknown_msr(Object *obj, int value, Error **errp) { struct whpx_state *whpx = &whpx_global; - OnOffAuto mode; - if (!visit_type_OnOffAuto(v, name, &mode, errp)) { - return; - } - - switch (mode) { + switch (value) { case ON_OFF_AUTO_ON: whpx->ignore_unknown_msr = true; break; - case ON_OFF_AUTO_OFF: whpx->ignore_unknown_msr = false; break; - case ON_OFF_AUTO_AUTO: whpx->ignore_unknown_msr = true; break; default: - /* - * The value was checked in visit_type_OnOffAuto() above. If - * we get here, then something is wrong in QEMU. - */ - abort(); + g_assert_not_reached(); } } -static void whpx_set_intercept_msr_gp(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static void whpx_set_intercept_msr_gp(Object *obj, int value, Error **errp) { struct whpx_state *whpx = &whpx_global; - OnOffAuto mode; - if (!visit_type_OnOffAuto(v, name, &mode, errp)) { - return; - } - - switch (mode) { + switch (value) { case ON_OFF_AUTO_ON: whpx->intercept_msr_gp = true; break; - case ON_OFF_AUTO_OFF: whpx->intercept_msr_gp = false; break; - case ON_OFF_AUTO_AUTO: whpx->intercept_msr_gp = false; break; default: - /* - * The value was checked in visit_type_OnOffAuto() above. If - * we get here, then something is wrong in QEMU. - */ - abort(); + g_assert_not_reached(); } } -static void whpx_set_ssd(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static void whpx_set_ssd(Object *obj, int value, Error **errp) { struct whpx_state *whpx = &whpx_global; - OnOffAuto mode; - if (!visit_type_OnOffAuto(v, name, &mode, errp)) { - return; - } - - switch (mode) { + switch (value) { case ON_OFF_AUTO_ON: whpx->separate_security_domain = true; break; - case ON_OFF_AUTO_OFF: whpx->separate_security_domain = false; break; - case ON_OFF_AUTO_AUTO: whpx->separate_security_domain = true; break; default: - /* - * The value was checked in visit_type_OnOffAuto() above. If - * we get here, then something is wrong in QEMU. - */ - abort(); + g_assert_not_reached(); } } void whpx_arch_accel_class_init(ObjectClass *oc) { - object_class_property_add(oc, "ignore-unknown-msr", "OnOffAuto", - NULL, whpx_set_unknown_msr, - NULL, NULL); - object_class_property_set_description(oc, "ignore-unknown-msr", - "Configure unknown MSR behavior"); - object_class_property_add(oc, "intercept-msr-gp", "OnOffAuto", - NULL, whpx_set_intercept_msr_gp, - NULL, NULL); - object_class_property_set_description(oc, "intercept-msr-gp", - "Intercept #GP to log erroring MSR accesses."); - object_class_property_add(oc, "ssd", "OnOffAuto", - NULL, whpx_set_ssd, - NULL, NULL); - object_class_property_set_description(oc, "ssd", - "Separate security domain"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "ignore-unknown-msr", + .description = "Configure unknown MSR behavior", + .qapi_type = &OnOffAuto_type_info, + .set = whpx_set_unknown_msr, + )); + + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "intercept-msr-gp", + .description = "Intercept #GP to log erroring MSR accesses.", + .qapi_type = &OnOffAuto_type_info, + .set = whpx_set_intercept_msr_gp, + )); + + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "ssd", + .description = "Separate security domain", + .qapi_type = &OnOffAuto_type_info, + .set = whpx_set_ssd, + )); } int whpx_accel_init(AccelState *as, MachineState *ms) -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455344.1669133 (Exim 4.92) (envelope-from ) id 1xJ7Wb-0002qV-CT; Tue, 20 Oct 2026 10:56:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455344.1669133; Tue, 20 Oct 2026 10:56: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 1xJ7WZ-0002l8-Q9; Tue, 20 Oct 2026 10:56:55 +0000 Received: by outflank-mailman (input) for mailman id 1455344; Tue, 20 Oct 2026 10:51:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qv-0000AR-NM for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qv-002FXm-47 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:05 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7478f-bab6-0a2a0a5309dd-0a2a4505d420-22 for ; Tue, 20 Oct 2026 12:51:05 +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 6ad7475a-4cb1-0a2a45050019-aa0a817c826f-3 for ; Tue, 20 Oct 2026 12:50:04 +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-691-X_BZbfi1OoaEw-XuKd7GEA-1; Tue, 20 Oct 2026 10:49:57 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 382911954B17; Tue, 20 Oct 2026 10:49:53 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 89D3D1956089; Tue, 20 Oct 2026 10:49: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=1792493402; 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=zgYXy9wUlwpZwJEXhfhg6ueZe5iP6OdFNQDVMpjhNJA=; b=BOWeipw9WxhEler+SP0WenptoYrcVWFdcYkTTIlvIHnxl7sPdiWMA0oxqEFr945ebzsYo0 P17DXAeI97qM2dPjnj28vJc0XJJn7SbsZUJn/8cGp4Uw+pV9DVZs/WsNRIF9vkzpMI9iJN b9KDO5+9/M7+1JFEbjRRPHHGA09SD4M= X-MC-Unique: X_BZbfi1OoaEw-XuKd7GEA-1 X-Mimecast-MFC-AGG-ID: X_BZbfi1OoaEw-XuKd7GEA_1792493393 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:57 +0400 Subject: [PATCH v7 40/65] accel/hvf: convert OnOffSplit property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-40-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2523; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=21V2JPj2rB3XQ9p0Fpt/4Sfi5TlT/INiy3CejR1RcSQ=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Zbcvmz2dcDonHaGuZ+0JSpCQbdwS1IqolsF mrcOSZwsk+JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5fbMD/4oDBa4aRAcuosgqEgTN/lLvXMd4CMMg/8NISFX3WirC2kLfaACPLJXeKGgyRmLFD49aZS C90374vVULKD25rkYEUinJNvw+z9cP8i/VTdLPCDvrtC/7kvYoqnDLVLO3J2Q3Wd5nfI6rmQZEk BwtAVjR6SSBb0iStYbJyVtP1TklsvdIlQhIhxfshPIqRwse/RgRnOxnAYRNMRVtDhm7Vu0j9+oI wQB+bCNaqKS88nEJIGu53wZ2zbS3wyEAQfjpFxwi2bIDLHSRhy3a07Hpo2bHHN003BU8sQAI530 fQnkPZFCQYFsKo1aZUPu739hgcgJsTtebTEHP7wVhaY5T9oTYjhlHy1h4bcxUIi+sUYQMwDz/B2 FNBgAkMwUmaom+WrzqUMDHFkmLBUULwbNeGiCgyNquapgGac7N7DQsItMvc5RouXeu8HIEjusQP ji/64PxnCl55S40Wr93VNww9w+uHtJ2MYwSRdIxtBvnRYW8k45wZ6f8n/bZ43PwOPLzkIMPhkAB AZPh9GndU9GtEDdzZQobzjyi5YtG9aqyHYwsF8IvbkM9hDWBKeSxYQInUbsFVgKYsEzJt9ORvoG Xh7xWXHM+nTdrSEW+k93/3Qu2ekkPkSElHFptLpXseE43g35XzS9fsK0+PV6Y6aNivNUO37QrR2 au4mCAtBZO6aHYg== 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: Z0XUv_bmELUFBRsn_Y3lCCIiU8iMB11Msyq1zWIBHjY_1792493393 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792493404-F68B62A1-15046773/0/0 X-purgate-type: clean X-purgate-size: 2525 Convert the OnOffSplit property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- accel/hvf/hvf-all.c | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/accel/hvf/hvf-all.c b/accel/hvf/hvf-all.c index 8bd9154a50b6..2fd594ad156f 100644 --- a/accel/hvf/hvf-all.c +++ b/accel/hvf/hvf-all.c @@ -11,6 +11,7 @@ #include "qemu/osdep.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-common.h" #include "qapi/qapi-visit-common.h" #include "accel/accel-ops.h" #include "exec/cpu-common.h" @@ -230,18 +231,12 @@ static int hvf_accel_init(AccelState *as, MachineState *ms) return hvf_arch_init(); } -static void hvf_set_kernel_irqchip(Object *obj, Visitor *v, - const char *name, void *opaque, +static void hvf_set_kernel_irqchip(Object *obj, int value, Error **errp) { - OnOffSplit mode; - hvf_kernel_irqchip_override = true; - if (!visit_type_OnOffSplit(v, name, &mode, errp)) { - return; - } - switch (mode) { + switch (value) { case ON_OFF_SPLIT_ON: #ifdef HOST_X86_64 /* macOS 12 onwards exposes an HVF virtual APIC. */ @@ -261,11 +256,7 @@ static void hvf_set_kernel_irqchip(Object *obj, Visitor *v, break; default: - /* - * The value was checked in visit_type_OnOffSplit() above. If - * we get here, then something is wrong in QEMU. - */ - abort(); + g_assert_not_reached(); } } @@ -277,11 +268,13 @@ static void hvf_accel_class_init(ObjectClass *oc, const void *data) ac->allowed = &hvf_allowed; hvf_kernel_irqchip_override = false; hvf_kernel_irqchip = false; - object_class_property_add(oc, "kernel-irqchip", "on|off|split", - NULL, hvf_set_kernel_irqchip, - NULL, NULL); - object_class_property_set_description(oc, "kernel-irqchip", - "Configure HVF irqchip"); + + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "kernel-irqchip", + .qapi_type = &OnOffSplit_type_info, + .set = hvf_set_kernel_irqchip, + .description = "Configure HVF irqchip", + )); } static const TypeInfo hvf_accel_type = { -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:56:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:56:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455347.1669142 (Exim 4.92) (envelope-from ) id 1xJ7Wd-0003Di-CB; Tue, 20 Oct 2026 10:56:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455347.1669142; Tue, 20 Oct 2026 10: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 1xJ7Wb-00036l-JW; Tue, 20 Oct 2026 10:56:57 +0000 Received: by outflank-mailman (input) for mailman id 1455347; Tue, 20 Oct 2026 10:51:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qx-0000BP-CK for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qw-00EzG1-PJ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:06 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74794-e002-0a2a0a5209dd-0a2a4503a12e-14 for ; Tue, 20 Oct 2026 12:51:06 +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 6ad746e5-fae8-0a2a45030019-aa0a817c758b-3 for ; Tue, 20 Oct 2026 12:48:06 +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-381-X4ttvQKTOGG9YvCqjtTwwQ-1; Tue, 20 Oct 2026 10:48:00 +0000 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 11DD51802573; Tue, 20 Oct 2026 10:47:57 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8CE561800444; Tue, 20 Oct 2026 10:47:54 +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=1792493284; 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=VhnuP9GUFWkUKVrWiyyQ4TwAPJA5jCWzmPwQlY7WHrg=; b=PTXGlegFAmkgtV0NZ7aXnCK1gEwRhg+ab68SmHpjKcYQId3wL1JEOF+4J2qJ1srH4SEmsW hterHCuHo/pzDNyVSdwLuDAWLKHwHGssrgmJoLE0aIyKQejufG4U772qV+XIBaULysEBml +7VBaA8K1Rfuef8vB8r1um+NwQhrf1s= X-MC-Unique: X4ttvQKTOGG9YvCqjtTwwQ-1 X-Mimecast-MFC-AGG-ID: X4ttvQKTOGG9YvCqjtTwwQ_1792493277 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:36 +0400 Subject: [PATCH v7 19/65] qom: convert QAPI enum properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-19-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=17948; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=6HmJUS8ti31K3a3a2qrKIDTAV1LxUYYBxrUY2iMoiRk=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZPwxGnXSq4QWDKEGgMqYI/Z8qJ2n4E63t1 CAug9EBmVyJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5RHYD/0VR6RzZzElo//CjihnI3BcxT2JM6duKVAvqwMTKrGjqQtVIr3yVB0WUDpv88WeJIFdg0g K44rtv1wBk3k27wWQHYXY7c7JCopqGlklnoCl86FeoYYYtNUsZPVs9q0ULFWIGI4Tqp9X1F3SN4 dbjLnZ1Ds0GY7fjQa/rXmv1xBN/ahVlo1NQKDWaeCSJwkAUBJwZiQQ736DUVGC/tvtwX84EN9Lj tzSSsfMTBvx8cfQd8cXEIO6dhfddIinGu4eywL3AK9pJrNpx6dC5Dnam87ouxnsCWLlA+6dFsLe 2Bdmci2g1kcW2nSWb7I9o9TCiM/vYwjLeUAqn7U/0L3UQ8bGN7FSEWEVuyu1zZ5cMJK9629XRc3 4Y/qFNn34AbWMmCBopkJp/i6yYUt2EfML+gU2n9Bk+HcR+bjmDaQQYN7HtB0Gtgy9+XmlJXrvMP bkXFMpwWuoCn1YI6Bva6xjA/IWMdU/ZWW3UtIEZPXG8WkIw38aJVQormQ3+2lWqXnL94+ZMpScV kW49h/CEZOyzQQD21DXh7geRV1HjhOnTlfIUNdehs+faDS+daQfvUFXcgFyCeq7y+3TDtO1xakH yHL8HFJRXqWCOyvHMBUDfw0xmYBnia9NugUUUqNrAEMaAvPgcg6yI34b2O1h2KaPpyFe5IVMSAA p5e/RxCRFKHbH2Q== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: b9uo3j7HUeIf06YDh-Yju29OfqzwQ-7Ctm2pS2SsM3o_1792493277 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1792493286-768FA4E9-7CA80C2E/0/0 X-purgate-type: clean X-purgate-size: 17950 Convert all callers of object_class_property_add_enum() but one to use the new object_class_property_add_qapi_enum() with the QAPI_ENUM_PROP() macro, which provides type information via QAPITypeInfo instead of raw lookup tables and string type names. This enables QMP QOM introspection to report accurate QAPI type names for enum properties. Where a separate set_description call was used, the description is now embedded in the QAPI_ENUM_PROP initializer. Leave pc_i440fx_machine_options() for later, because enum PCSouthBridgeOption is a handmade QAPI-like enum instead of a real one. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- authz/list.c | 12 +++++++----- backends/hostmem.c | 14 ++++++++------ crypto/secret_common.c | 12 +++++++----- crypto/tlscreds.c | 12 +++++++----- hw/microblaze/petalogix_s3adsp1800_mmu.c | 19 +++++++++++-------- include/chardev/char.h | 8 -------- monitor/qmp.c | 12 +++++++----- net/filter.c | 10 +++++++--- target/i386/kvm/kvm.c | 30 +++++++++++++++++------------- ui/console-vc.c | 8 +++++++- ui/dbus.c | 18 ++++++++++++++---- ui/input-linux.c | 11 +++++++---- 12 files changed, 99 insertions(+), 67 deletions(-) diff --git a/authz/list.c b/authz/list.c index 17aa0efd80e8..363b2ee12c98 100644 --- a/authz/list.c +++ b/authz/list.c @@ -22,6 +22,7 @@ #include "authz/list.h" #include "trace.h" #include "qom/object_interfaces.h" +#include "qapi/qapi-type-infos-authz.h" #include "qapi/qapi-visit-authz.h" #include "qemu/module.h" @@ -120,11 +121,12 @@ qauthz_list_class_init(ObjectClass *oc, const void *data) { QAuthZClass *authz = QAUTHZ_CLASS(oc); - object_class_property_add_enum(oc, "policy", - "QAuthZListPolicy", - &QAuthZListPolicy_lookup, - qauthz_list_prop_get_policy, - qauthz_list_prop_set_policy); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "policy", + .qapi_type = &QAuthZListPolicy_type_info, + .get = qauthz_list_prop_get_policy, + .set = qauthz_list_prop_set_policy, + )); object_class_property_add(oc, "rules", "QAuthZListRule", qauthz_list_prop_get_rules, diff --git a/backends/hostmem.c b/backends/hostmem.c index 8782c8b1ea98..edb8e6ab4502 100644 --- a/backends/hostmem.c +++ b/backends/hostmem.c @@ -16,6 +16,7 @@ #include "hw/core/boards.h" #include "qapi/error.h" #include "qapi/qapi-builtin-visit.h" +#include "qapi/qapi-type-infos-common.h" #include "qapi/visitor.h" #include "qemu/config-file.h" #include "qom/compat-properties.h" @@ -551,12 +552,13 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) NULL, NULL); object_class_property_set_description(oc, "host-nodes", "Binds memory to the list of NUMA host nodes"); - object_class_property_add_enum(oc, "policy", "HostMemPolicy", - &HostMemPolicy_lookup, - host_memory_backend_get_policy, - host_memory_backend_set_policy); - object_class_property_set_description(oc, "policy", - "Set the NUMA policy"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "policy", + .description = "Set the NUMA policy", + .qapi_type = &HostMemPolicy_type_info, + .get = host_memory_backend_get_policy, + .set = host_memory_backend_set_policy, + )); object_class_property_add_bool(oc, "share", host_memory_backend_get_share, host_memory_backend_set_share); object_class_property_set_description(oc, "share", diff --git a/crypto/secret_common.c b/crypto/secret_common.c index a5ecb876aeba..381d23ecc8e0 100644 --- a/crypto/secret_common.c +++ b/crypto/secret_common.c @@ -22,6 +22,7 @@ #include "crypto/secret_common.h" #include "crypto/cipher.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-crypto.h" #include "qom/object_interfaces.h" #include "qemu/base64.h" #include "qemu/module.h" @@ -269,11 +270,12 @@ qcrypto_secret_class_init(ObjectClass *oc, const void *data) ucc->complete = qcrypto_secret_complete; - object_class_property_add_enum(oc, "format", - "QCryptoSecretFormat", - &QCryptoSecretFormat_lookup, - qcrypto_secret_prop_get_format, - qcrypto_secret_prop_set_format); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "format", + .qapi_type = &QCryptoSecretFormat_type_info, + .get = qcrypto_secret_prop_get_format, + .set = qcrypto_secret_prop_set_format, + )); object_class_property_add_str(oc, "keyid", qcrypto_secret_prop_get_keyid, qcrypto_secret_prop_set_keyid); diff --git a/crypto/tlscreds.c b/crypto/tlscreds.c index fb09e295a65c..54859720bf74 100644 --- a/crypto/tlscreds.c +++ b/crypto/tlscreds.c @@ -20,6 +20,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-crypto.h" #include "qapi-types-crypto.h" #include "qemu/module.h" #include "qemu/error-report.h" @@ -221,11 +222,12 @@ qcrypto_tls_creds_class_init(ObjectClass *oc, const void *data) object_class_property_add_str(oc, "dir", qcrypto_tls_creds_prop_get_dir, qcrypto_tls_creds_prop_set_dir); - object_class_property_add_enum(oc, "endpoint", - "QCryptoTLSCredsEndpoint", - &QCryptoTLSCredsEndpoint_lookup, - qcrypto_tls_creds_prop_get_endpoint, - qcrypto_tls_creds_prop_set_endpoint); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "endpoint", + .qapi_type = &QCryptoTLSCredsEndpoint_type_info, + .get = qcrypto_tls_creds_prop_get_endpoint, + .set = qcrypto_tls_creds_prop_set_endpoint, + )); object_class_property_add_str(oc, "priority", qcrypto_tls_creds_prop_get_priority, qcrypto_tls_creds_prop_set_priority); diff --git a/hw/microblaze/petalogix_s3adsp1800_mmu.c b/hw/microblaze/petalogix_s3adsp1800_mmu.c index c5f64319009b..9a8fcc667812 100644 --- a/hw/microblaze/petalogix_s3adsp1800_mmu.c +++ b/hw/microblaze/petalogix_s3adsp1800_mmu.c @@ -27,6 +27,7 @@ #include "qemu/target-info.h" #include "qemu/units.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-common.h" #include "target/microblaze/cpu.h" #include "hw/core/sysbus.h" #include "net/net.h" @@ -174,14 +175,16 @@ static void petalogix_s3adsp1800_machine_class_init(ObjectClass *oc, mc->init = petalogix_s3adsp1800_init; mc->is_default = true; - prop = object_class_property_add_enum(oc, "endianness", "EndianMode", - &EndianMode_lookup, - machine_get_endianness, - machine_set_endianness); - object_property_set_default_str(prop, target_big_endian() ? "big" - : "little"); - object_class_property_set_description(oc, "endianness", - "Defines whether the machine runs in big or little endian mode"); + prop = object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "endianness", + .description = + "Defines whether the machine runs in big or little endian mode", + .qapi_type = &EndianMode_type_info, + .get = machine_get_endianness, + .set = machine_set_endianness, + )); + object_property_set_default_enum(prop, + target_big_endian() ? ENDIAN_MODE_BIG : ENDIAN_MODE_LITTLE); } static const TypeInfo petalogix_s3adsp1800_machine_types[] = { diff --git a/include/chardev/char.h b/include/chardev/char.h index 2616c19cc095..21bf85d197eb 100644 --- a/include/chardev/char.h +++ b/include/chardev/char.h @@ -352,12 +352,4 @@ static void set_encoding(Object *obj, int value, Error **errp) \ cast_func(obj)->encoding = value; \ } -static inline void chardev_vc_add_encoding_prop(ObjectClass *oc, - int (*get)(Object *, Error **), - void (*set)(Object *, int, Error **)) -{ - object_class_property_add_enum(oc, "encoding", "ChardevVCEncoding", - &ChardevVCEncoding_lookup, get, set); -} - #endif diff --git a/monitor/qmp.c b/monitor/qmp.c index eb44012643f6..c2849214d58b 100644 --- a/monitor/qmp.c +++ b/monitor/qmp.c @@ -30,6 +30,7 @@ #include "qapi/error.h" #include "qapi/qapi-commands-control.h" #include "qapi/qapi-commands-char.h" +#include "qapi/qapi-type-infos-qom.h" #include "qobject/qdict.h" #include "qobject/qjson.h" #include "qobject/qlist.h" @@ -133,11 +134,12 @@ static void monitor_qmp_class_init(ObjectClass *cls, const void *data) object_class_property_add_bool(cls, "pretty", monitor_qmp_get_pretty, monitor_qmp_set_pretty); - object_class_property_add_enum(cls, "close-action", - "MonitorQMPCloseAction", - &MonitorQMPCloseAction_lookup, - monitor_qmp_get_close_action, - monitor_qmp_set_close_action); + object_class_property_add_qapi_enum(cls, QAPI_ENUM_PROP( + .name = "close-action", + .qapi_type = &MonitorQMPCloseAction_type_info, + .get = monitor_qmp_get_close_action, + .set = monitor_qmp_set_close_action, + )); moncls->emit_event = monitor_qmp_emit_event; moncls->requires_iothread = monitor_qmp_requires_iothread; diff --git a/net/filter.c b/net/filter.c index 389f3b0bfefb..79883af22a54 100644 --- a/net/filter.c +++ b/net/filter.c @@ -8,6 +8,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-common.h" #include "qapi/qmp/qerror.h" #include "qemu/error-report.h" @@ -342,9 +343,12 @@ static void netfilter_class_init(ObjectClass *oc, const void *data) object_class_property_add_str(oc, "netdev", netfilter_get_netdev_id, netfilter_set_netdev_id); - object_class_property_add_enum(oc, "queue", "NetFilterDirection", - &NetFilterDirection_lookup, - netfilter_get_direction, netfilter_set_direction); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "queue", + .qapi_type = &NetFilterDirection_type_info, + .get = netfilter_get_direction, + .set = netfilter_set_direction, + )); object_class_property_add_str(oc, "status", netfilter_get_status, netfilter_set_status); object_class_property_add_str(oc, "position", diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index da922f72d71e..f2e8dc8c156d 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -14,6 +14,8 @@ #include "qemu/osdep.h" #include "qapi/qapi-events-run-state.h" +#include "qapi/qapi-type-infos-common.h" +#include "qapi/qapi-type-infos-run-state.h" #include "qapi/error.h" #include "qapi/visitor.h" #include @@ -7089,12 +7091,13 @@ static void kvm_arch_set_honor_guest_pat(Object *obj, int value, Error **errp) void kvm_arch_accel_class_init(ObjectClass *oc) { - object_class_property_add_enum(oc, "notify-vmexit", "NotifyVMexitOption", - &NotifyVmexitOption_lookup, - kvm_arch_get_notify_vmexit, - kvm_arch_set_notify_vmexit); - object_class_property_set_description(oc, "notify-vmexit", - "Enable notify VM exit"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "notify-vmexit", + .description = "Enable notify VM exit", + .qapi_type = &NotifyVmexitOption_type_info, + .get = kvm_arch_get_notify_vmexit, + .set = kvm_arch_set_notify_vmexit, + )); object_class_property_add(oc, "notify-window", "uint32", kvm_arch_get_notify_window, @@ -7127,13 +7130,14 @@ void kvm_arch_accel_class_init(ObjectClass *oc) object_class_property_set_description(oc, "xen-evtchn-max-pirq", "Maximum number of Xen PIRQs"); - object_class_property_add_enum(oc, "honor-guest-pat", "OnOffAuto", - &OnOffAuto_lookup, - kvm_arch_get_honor_guest_pat, - kvm_arch_set_honor_guest_pat); - object_class_property_set_description(oc, "honor-guest-pat", - "Disable KVM quirk that ignores guest PAT " - "memory type settings (default: auto)"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "honor-guest-pat", + .description = "Disable KVM quirk that ignores guest PAT " + "memory type settings (default: auto)", + .qapi_type = &OnOffAuto_type_info, + .get = kvm_arch_get_honor_guest_pat, + .set = kvm_arch_set_honor_guest_pat, + )); } void kvm_set_max_apic_id(uint32_t max_apic_id) diff --git a/ui/console-vc.c b/ui/console-vc.c index 99cc8f09c887..cca4790c993c 100644 --- a/ui/console-vc.c +++ b/ui/console-vc.c @@ -6,6 +6,7 @@ #include "chardev/char.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-char.h" #include "qemu/option.h" #include "qemu/queue.h" #include "qom/compat-properties.h" @@ -326,7 +327,12 @@ static void char_vc_class_init(ObjectClass *oc, const void *data) cc->supports_size_opts = true; cc->supports_encoding_opts = true; - chardev_vc_add_encoding_prop(oc, get_encoding, set_encoding); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "encoding", + .qapi_type = &ChardevVCEncoding_type_info, + .get = get_encoding, + .set = set_encoding, + )); } static void char_vc_init(Object *obj) diff --git a/ui/dbus.c b/ui/dbus.c index 7be0f8e26119..afc321514c68 100644 --- a/ui/dbus.c +++ b/ui/dbus.c @@ -38,6 +38,8 @@ #include "qemu/audio.h" #include "audio/audio_int.h" /* FIXME: use QOM dynamic cast instead of drv->name */ #include "qapi/error.h" +#include "qapi/qapi-type-infos-char.h" +#include "qapi/qapi-type-infos-ui.h" #include "trace.h" #include "dbus.h" @@ -508,9 +510,12 @@ dbus_display_class_init(ObjectClass *oc, const void *data) object_class_property_add_bool(oc, "p2p", get_dbus_p2p, set_dbus_p2p); object_class_property_add_str(oc, "addr", get_dbus_addr, set_dbus_addr); object_class_property_add_str(oc, "audiodev", get_audiodev, set_audiodev); - object_class_property_add_enum(oc, "gl-mode", - "DisplayGLMode", &DisplayGLMode_lookup, - get_gl_mode, set_gl_mode); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "gl-mode", + .qapi_type = &DisplayGLMode_type_info, + .get = get_gl_mode, + .set = set_gl_mode, + )); } #define TYPE_CHARDEV_VC "chardev-vc" @@ -602,7 +607,12 @@ dbus_vc_class_init(ObjectClass *oc, const void *data) cc->chr_open = dbus_vc_open; cc->supports_encoding_opts = true; - chardev_vc_add_encoding_prop(oc, get_encoding, set_encoding); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "encoding", + .qapi_type = &ChardevVCEncoding_type_info, + .get = get_encoding, + .set = set_encoding, + )); } static void diff --git a/ui/input-linux.c b/ui/input-linux.c index f4eee1ffd7ec..715d1f589297 100644 --- a/ui/input-linux.c +++ b/ui/input-linux.c @@ -6,6 +6,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-common.h" #include "qemu/config-file.h" #include "qemu/main-loop.h" #include "qemu/module.h" @@ -506,10 +507,12 @@ static void input_linux_class_init(ObjectClass *oc, const void *data) object_class_property_add_bool(oc, "repeat", input_linux_get_repeat, input_linux_set_repeat); - object_class_property_add_enum(oc, "grab-toggle", "GrabToggleKeys", - &GrabToggleKeys_lookup, - input_linux_get_grab_toggle, - input_linux_set_grab_toggle); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "grab-toggle", + .qapi_type = &GrabToggleKeys_type_info, + .get = input_linux_get_grab_toggle, + .set = input_linux_set_grab_toggle, + )); } static const TypeInfo input_linux_info = { -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455349.1669170 (Exim 4.92) (envelope-from ) id 1xJ7Wm-00056x-Jw; Tue, 20 Oct 2026 10:57:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455349.1669170; Tue, 20 Oct 2026 10: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 1xJ7Wl-00051s-40; Tue, 20 Oct 2026 10:57:07 +0000 Received: by outflank-mailman (input) for mailman id 1455349; Tue, 20 Oct 2026 10:51:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qy-0000Be-HI for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qx-00EzG1-Ty for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:07 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74794-e002-0a2a0a5209dd-0a2a4503a12e-16 for ; Tue, 20 Oct 2026 12:51:07 +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 6ad7475e-fae8-0a2a45030019-aa0a817ccc27-3 for ; Tue, 20 Oct 2026 12:50:07 +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-37-O30bwBRGPzmDiwX1sYGXKg-1; Tue, 20 Oct 2026 06:50:02 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 726D5195606F; Tue, 20 Oct 2026 10:49:58 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6513818002B1; Tue, 20 Oct 2026 10:49: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=1792493406; 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=GVWb5UrZ3l9OWc8z0jMYQBZzqJcQOCGKYpInKz+na1M=; b=SPBNIMvSiQotHH2p21k5K/ETyEhREtscUuUerlFTJWfJzOJUWafHx7/Tegvw/f6Fg+5OHc ABMti7urGRriNQpAxctKYS/eUHSFkZKfg6E4Y/DmXLv9B+cfprX5/4oSrL/7DRZOcyFQsJ u31tQjr0iOW5De4V7Mz/5x0RglCKLlQ= X-MC-Unique: O30bwBRGPzmDiwX1sYGXKg-1 X-Mimecast-MFC-AGG-ID: O30bwBRGPzmDiwX1sYGXKg_1792493398 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:58 +0400 Subject: [PATCH v7 41/65] i386/x86: convert SgxEPCList property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-41-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1122; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=3ycIKkcsrbeBaqgGVPPqutgRU2x41tR3vpY71IOY4RM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Zbm7moIDDW7GGdTGA1Ntevlz9fNWvXvLsJR bIPPo13KrCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5Z6AD/9gPLakZLGtkob/1hq4vp9WcOhy+Qf2mehJtKFcowbdPBQjOD8jHexmcUoSOILep2f0ZLJ dZ93x7+KtpDPJ/4hOVEelty3/2kYzR1QGS2GLV1xt70MVDdKb6YGI7nv9ZhSRPqLxUf2quaFnpm umHDou1B6dYT/+c0icU7IlgdqRtOxyZ75sKO27Z6dmZnoqFYLIP/lXyNuIuKzlZ2yjLPAGUsLFk LK3zOo1vwisjf/BZLY9TIovgjVy9se5BpqWx1A7pqHpe32TwXQU1x7ixQEeFADdUg1WCkE/isdM krDIS7cujn4AJtgOxH6JqN07z+G7SToDICJtrtNtgw/zd3B649uK5Li/udmEyCLk1PK2QpnS/+6 QpLTgx5m+Nobyae7jNQ7UKPCwATlex3vDyur7bvIfFNayOgpP/FZpJy2MwJzaxXsKL/juZ8h5dk NKpgvzPljgaORC5S+IsFoYPk7tgCHPRUF4r7b0ueCMur6MDrxaHIbMJKGergjautzcwg3hpKn8x Ul7p9A/g0SdO4ZaHIVOBXSGBW+ng3qndsxDvkIeH5v8SOsNZtu9D9oCnarKouLgzTUoO0aJoslY tDeb5MWngF3MQnylC815Zw6FQmYbBKNJCkjC0aiegP2CSTAx7etM/l6FB+NT/OktrtRZUXlUxN2 Ai4S2aLDD28Dk1g== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: Co2u3qCfoC_tGCrDujalM0DzEH55gj1tcw4uUsMfvlQ_1792493398 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1792493407-6E6CE4E9-1B99878E/0/0 X-purgate-type: clean X-purgate-size: 1124 Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/i386/x86.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/i386/x86.c b/hw/i386/x86.c index d0c782ec8544..ed38760d798d 100644 --- a/hw/i386/x86.c +++ b/hw/i386/x86.c @@ -25,6 +25,7 @@ #include "qemu/units.h" #include "qapi/error.h" #include "qapi/qapi-type-infos-common.h" +#include "qapi/qapi-type-infos-machine.h" #include "qapi/qapi-visit-machine.h" #include "qapi/visitor.h" #include "system/qtest.h" @@ -426,7 +427,7 @@ static void x86_machine_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "Set the ratelimit for the bus locks acquired in VMs"); - object_class_property_add(oc, "sgx-epc", "SgxEPC", + object_class_property_add_qapi(oc, "sgx-epc", &SgxEPCList_type_info, machine_get_sgx_epc, machine_set_sgx_epc, NULL, NULL); object_class_property_set_description(oc, "sgx-epc", -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455350.1669174 (Exim 4.92) (envelope-from ) id 1xJ7Wn-0005DN-67; Tue, 20 Oct 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 1455350.1669174; Tue, 20 Oct 2026 10: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 1xJ7Wm-0005BQ-0i; Tue, 20 Oct 2026 10:57:08 +0000 Received: by outflank-mailman (input) for mailman id 1455350; Tue, 20 Oct 2026 10:51:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Qz-0000Bm-47 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Qy-002FaV-HH for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479b-bab6-0a2a0a5309dd-0a2a45029f70-2 for ; Tue, 20 Oct 2026 12:51:08 +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 6ad746ab-6ca4-0a2a45020019-aa0a817c731b-3 for ; Tue, 20 Oct 2026 12:47:08 +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-225-c5deni3IOC2wghL_mDuwjA-1; Tue, 20 Oct 2026 10:47:02 +0000 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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E2CAE1800BD4; Tue, 20 Oct 2026 10:46:58 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 66E731956088; Tue, 20 Oct 2026 10:46: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=1792493226; 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=ABGJlqhjTzuYRZnmPc116ozStZtH+NrxbC+tSxh9ams=; b=EixwMFHvTimPrYLZp7+w5IYqM2gBc2eRfW0oaQmhK0dKDRZN53jlO7IkGJRJ4yUyWklcKf MIGKbasrVncQMU+cfbUt4L092DG4znK85OhlnNFSPK0EREu1jRc5mg21JkA2F+DPct9qVo +D6/dHDgyMo2cNWpqGAYWZfIXpd26tQ= X-MC-Unique: c5deni3IOC2wghL_mDuwjA-1 X-Mimecast-MFC-AGG-ID: c5deni3IOC2wghL_mDuwjA_1792493219 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:25 +0400 Subject: [PATCH v7 08/65] qapi/gen: fix _module_basename for multi-dash 'what' parameters MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-8-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1135; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=OXQAJj92qnLHVy/ekT2tV/E7DqxlrqwyneXLdAaw748=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYkpNZTiTu/0NKP25uG6QN+n4wrDZMxyVQO X1gFQ2YGniJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5Tm3EACDRom1wjYZ0S5SCUsfw8t+j56evvGukUBRwQKN2w3Du6uYAw4nS9RuGSZhu8Qnd+u5pMZ RR4HP3oxzkczsRTA8h9qgVMNqhnT0wlElBiABH9tCI3YJUEmCvZ6BcLxuFPzfBeyc9GxW13b1zO eFJpHhMeM/R3jK04zRuRqksv4/8kXnR6/wpqoTWxFKiLIHlDVBwA/CTfIs4nGprg3ZGZmRlb33o EmNs25MODVt3L329BQIU0WG7OwYkXsYoGUdf4ZEbcr9CZywiZ8S0Rvx9fyqeYkVfaSlmqy1IM8D gBphVT/878S1qnGZqgmJs2Mb/btw8aPl7PQPV5lHDeMKBfwNHCoePHXNHb7C36F9khg3w29QQGl cKkIx32v/w3/L0dR1CWVI+YkbZ7xfh8oZJabF87gg5+jzpgm0AhaVUIgHU33CwJpYm2u62IUU6O GUxREslEK8bfz4pPnfxyzQVd8JIjSZoz7J2ip2+0PYyI8mftsOWTAFnUU8jnITGf2UjSAGRfXtR DTXKPDqAwHdk7bX3rSvoybxG2RnFNFluw+yjjhDEyY/RhYpOJItxVCbcr+e3/wkbhBjbIiHOO14 e3pUpNugRf71Qh75I/eHU/GjXdHLvK/PibBXQ7ZxPFfUTuBYAVOQILNa2K4bAzoDOqwVFf9OOq/ UAbLSh+VqcTxYTw== 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: ksMbsfJH8tUod-7x-2x2YGg-yDcjuqCuelOOCs_TgNM_1792493219 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1792493228-670B02AC-4CDBC78D/0/0 X-purgate-type: clean X-purgate-size: 1137 The re.sub() call replaces every hyphen in 'what' with the system module infix. This produces broken filenames for multi-hyphen names (e.g. 'qapi-type-infos' becomes 'qapi-builtin-type-builtin-infos'). Add count=1 so only the first hyphen is replaced. Reviewed-by: Markus Armbruster Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- scripts/qapi/gen.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/qapi/gen.py b/scripts/qapi/gen.py index 0c9b8db3b024..690187d4280d 100644 --- a/scripts/qapi/gen.py +++ b/scripts/qapi/gen.py @@ -300,7 +300,7 @@ def _module_basename(self, what: str, name: str) -> str: ret += '-' + os.path.splitext(basename)[0] else: assert QAPISchemaModule.is_system_module(name) - ret += re.sub(r'-', '-' + name[2:] + '-', what) + ret += re.sub(r'-', '-' + name[2:] + '-', what, count=1) return ret def _module_filename(self, what: str, name: str) -> str: -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455352.1669182 (Exim 4.92) (envelope-from ) id 1xJ7Wo-0005Nz-Qx; Tue, 20 Oct 2026 10:57:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455352.1669182; Tue, 20 Oct 2026 10: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 1xJ7Wn-0005KP-9f; Tue, 20 Oct 2026 10:57:09 +0000 Received: by outflank-mailman (input) for mailman id 1455352; Tue, 20 Oct 2026 10:51:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R0-0000CH-ST for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R0-00EzG1-97 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:10 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479c-e002-0a2a0a5209dd-0a2a4505a14c-10 for ; Tue, 20 Oct 2026 12:51:10 +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 6ad74724-4cb1-0a2a45050019-aa0a817c6d61-3 for ; Tue, 20 Oct 2026 12:49:09 +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-695-yDBtsgiZMVeudebqgTG40w-1; Tue, 20 Oct 2026 10:49:04 +0000 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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 463A71955F13; Tue, 20 Oct 2026 10:49:00 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C02F71800643; Tue, 20 Oct 2026 10:48: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=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=1792493348; 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=GzrRsz6mLl7MwzdhkY7vfYrvBkZMGUNTXQg1+7bFvLg=; b=WjI35hrQXJ0ijBYcUi0UVMCHqSVtKNNZW1/084jkdA/Q5NyXD8a085euiie+zES1K6B6ZS PgzFLcHRGxQ/qH951645GnryXtaSjuAlaz/ic3UGMN0jHvB9bwO4QsRpjHWAeK18vROm9e WwOPmBovFIroMLyoFI+pmgrUa/iZfP4= X-MC-Unique: yDBtsgiZMVeudebqgTG40w-1 X-Mimecast-MFC-AGG-ID: yDBtsgiZMVeudebqgTG40w_1792493340 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:48 +0400 Subject: [PATCH v7 31/65] accel/kvm: convert OnOffSplit property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-31-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2783; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=+bwgKTQoEXvch3Nux+0BT762997CE8SOrsZR1127GSg=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Za8fqdACvj1nRd8+C/AFYeoaG4KSLJ6yGQQ Glfe3Z930GJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5eUfD/9SnH6zP3RrX1y/+UloXnrP0adIyHDiLTAU3ewz/VXg/42/fyfveSadLjnEYI4LS5PYVJD v/pRwcO+N8ttIKGUUnzvZ8LbPJ2aOUgbCxlb4OK1H/o0SeUotkF4vrecY3jiuanZDAad9nnJknV xUSfv6C47md+eGcoSxfBJtIoHoCzqP0VrumAL7f2whnw8f6IDaVVKTSD6sZJ2Efs7s1Qn16rBMu sqGVWI8FrPFjMzb/2EDPUkou27o+hp2N8qu8YOve5UpP6QDxfnvjhmhmzJqVkCfvoO7rCGKkijo k6vWvpqSMKDK7l1tHS0Ku4FIISLg98nxTng63G6H0qOK0nHyQP1GSk2qwxpiYk8u9Ce9qsIz+11 sIE9BYfcmZCOjWPUgJLaVkhwmIjD02zSVmTioREECRxLjNPpDkjuJr0Xdlsh2WYnRWY3Fl1t7OD GbNk+8g5pktMfc35r/EnZqCHRxK62xZpnLhPmwgZXCOU2v78mH+KMUj4kAc1hL4GqVsXBZ9hmrQ jIMQW97/Fx15LS09jI953OtIvrmwRkkpGdMo1MDk0IGUeACzxNcIm9WjoGfUs6o75BDqmwcC7i1 Z3C6vhvu7wZNWdHqfWnywxQ/mt0EngUghtCxbR/EkXeD+K3qeezLfiPlajqHqOA85YFTZ6KTEUz jiYTPV8RQoITU0g== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: 2Z1-Kbm-t9Y3NgDiW21Y-rDzCnPh0Bs1Z9_mxRN93ws_1792493340 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792493350-2551A2A1-D300DC9D/0/0 X-purgate-type: clean X-purgate-size: 2785 Convert the OnOffSplit property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- accel/kvm/kvm-all.c | 26 ++++++++++---------------- 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index db8fba53f339..1d91667fb880 100644 --- a/accel/kvm/kvm-all.c +++ b/accel/kvm/kvm-all.c @@ -46,6 +46,7 @@ #include "qapi/visitor.h" #include "qapi/qapi-types-common.h" #include "qapi/qapi-visit-common.h" +#include "qapi/qapi-type-infos-common.h" #include "system/reset.h" #include "qemu/guest-random.h" #include "system/hw_accel.h" @@ -4151,22 +4152,17 @@ static void kvm_set_kvm_shadow_mem(Object *obj, Visitor *v, s->kvm_shadow_mem = value; } -static void kvm_set_kernel_irqchip(Object *obj, Visitor *v, - const char *name, void *opaque, +static void kvm_set_kernel_irqchip(Object *obj, int value, Error **errp) { KVMState *s = KVM_STATE(obj); - OnOffSplit mode; if (s->fd != -1) { error_setg(errp, "Cannot set properties after the accelerator has been initialized"); return; } - if (!visit_type_OnOffSplit(v, name, &mode, errp)) { - return; - } - switch (mode) { + switch (value) { case ON_OFF_SPLIT_ON: s->kernel_irqchip_allowed = true; s->kernel_irqchip_required = true; @@ -4183,10 +4179,7 @@ static void kvm_set_kernel_irqchip(Object *obj, Visitor *v, s->kernel_irqchip_split = ON_OFF_AUTO_ON; break; default: - /* The value was checked in visit_type_OnOffSplit() above. If - * we get here, then something is wrong in QEMU. - */ - abort(); + g_assert_not_reached(); } } @@ -4303,11 +4296,12 @@ static void kvm_accel_class_init(ObjectClass *oc, const void *data) ac->has_memory = kvm_accel_has_memory; ac->allowed = &kvm_allowed; - object_class_property_add(oc, "kernel-irqchip", "on|off|split", - NULL, kvm_set_kernel_irqchip, - NULL, NULL); - object_class_property_set_description(oc, "kernel-irqchip", - "Configure KVM in-kernel irqchip"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "kernel-irqchip", + .qapi_type = &OnOffSplit_type_info, + .set = kvm_set_kernel_irqchip, + .description = "Configure KVM in-kernel irqchip", + )); object_class_property_add(oc, "kvm-shadow-mem", "int", kvm_get_kvm_shadow_mem, kvm_set_kvm_shadow_mem, -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455355.1669188 (Exim 4.92) (envelope-from ) id 1xJ7Wq-0005u3-Jz; Tue, 20 Oct 2026 10:57:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455355.1669188; Tue, 20 Oct 2026 10:57: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 1xJ7Wp-0005l4-N4; Tue, 20 Oct 2026 10:57:11 +0000 Received: by outflank-mailman (input) for mailman id 1455355; Tue, 20 Oct 2026 10:51:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R1-0000Cs-IX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R0-00CroT-VT for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:10 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479d-2eae-0a2a0a5409dd-0a2a450480cc-4 for ; Tue, 20 Oct 2026 12:51:10 +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 6ad746ad-b57f-0a2a45040019-aa0a817c56bf-3 for ; Tue, 20 Oct 2026 12:47:10 +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-379-Q9FEb42bMfer0z7ZaConTg-1; Tue, 20 Oct 2026 10:46:57 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9809D1954B20; Tue, 20 Oct 2026 10:46:52 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2267C1800444; Tue, 20 Oct 2026 10:46: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=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=1792493229; 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=T4Uxxm/AUYAlgWDMQDpSo2oDR3RYBjxEx/nUKW/pClc=; b=E2K2radMdsPv/z5GuiUEacMLRQoFsy5QmnWbthuXZ0n750dz3TFMAedfzKGMnNSRjpPgAW AnKvUmnIUzisbHGnH3jWfxQVBxyuiWFhyeUJsgV2At+pcHWUXzQQWBywC/LAibKbd99pRv ZTTW1RtdOKuzzARm6TKQYLirxhpIuh8= X-MC-Unique: Q9FEb42bMfer0z7ZaConTg-1 X-Mimecast-MFC-AGG-ID: Q9FEb42bMfer0z7ZaConTg_1792493213 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:24 +0400 Subject: [PATCH v7 07/65] qapi: add QAPITypeInfo struct definition MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-7-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1828; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=ncAoduk+W++XsQQC6jhXGd6nHnXr1eyWDznZbZI1kq8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYgCKdk47hapDm+FojdwVHdZciBcCELJvB+ Yw7agAaZi2JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5T9oD/9GpeJFOttXk8RI55B118B4xUvL1oaf8Lo8kCm7RluwGbnLkgkEWk3zfL95zz4jtUJwnKQ LkI/5HSvCywgfyFPEHSeLsTL1fdJsoyRVHSZu5kn7dXrnfwQt03BqXsZoGPyzgJ4O6dtOX+WHQ/ p6v8cw5FjgYcyrcGkoZL25m8291Qj+cifHCodAv8D8Pwc/O0TMY9tcXyBGixECq8bhC05GlyiFL 1HahUKZPfY5wzXAb1ZpI5IG4ebak9SIACrEGavNNow/2pr7YKP9Dv4SiziC+P1lhVrmELQbxRok HGAL/k9Se+GdzyvbmuU0S5/R4GZNAkxqR3Zt8oy+8jyDYnlw8M9s/RPqgkS98TF1jpcFKlp/7EA YNW4QBcSGFwWOBrSYO2580wx+fB01GWAv5Oxz3vyKBSQyKgmF04H7rB9l2vKNMWnxKRzNqjbmXt 8EvxF5m5VzSm7Pv1Y7jp9cZ/hGY7hDy84syz2Amn5jd7IFzuDgcyRV5G0EZQisXAao1ed7uWeCA rdKBAJUAVv0WyiAVn5qgDoZcqgLGp/vBung/13PF3FFVyJdvO3llipzkXBwaLeKpimriCvSA0ag eO9DfBCSkrhnJUIyeTawq6BHzOMEOc9xWB+Mubdj/bUzMsWXWGu7MXSGR9kP+1Nkw0P1SbqEYCO SE+11f2XzLE52rQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: 6b_Va5ds9oq5M8Iyga0PJdskdc_VHzxTuAwpCnJshyg_1792493213 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792493230-C14D3B50-61B11E91/0/0 X-purgate-type: clean X-purgate-size: 1830 Introduce a minimal struct that pairs a QAPI type's internal name with its "masked" introspection name. Generated constants of this type will let QOM property registration carry a reliable reference to the QAPI schema and possibly other associated data. The fields are populated in following commits. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- include/qapi/qapi-type-info.h | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/include/qapi/qapi-type-info.h b/include/qapi/qapi-type-info.h new file mode 100644 index 000000000000..6a6355568325 --- /dev/null +++ b/include/qapi/qapi-type-info.h @@ -0,0 +1,31 @@ +/* + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#ifndef QAPI_TYPE_INFO_H +#define QAPI_TYPE_INFO_H + +#include "qapi/util.h" + +/** + * QAPITypeInfo - QAPI type metadata + * + * @name: QAPI type name (e.g. "str", "OnOffAuto", "int32List"). + * QOM uses this as the property type string. + * @masked_name: Name of the type in the QAPI introspection schema, assigned by + * scripts/qapi code generator (e.g. "368"). + * @lookup: QEnumLookup for this type, or NULL for non-enum types. + * visit_type_enum(), qapi_enum_parse(), and qapi_enum_lookup() + * all rely on it. + * @list: The list-type counterpart, or NULL if none exists. + * str_type_info.list points to strList_type_info. qdev array + * properties follow this to find the list type for their element. + */ +typedef struct QAPITypeInfo { + const char *name; + const char *masked_name; + const QEnumLookup *lookup; + const struct QAPITypeInfo *list; +} QAPITypeInfo; + +#endif /* QAPI_TYPE_INFO_H */ -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455358.1669200 (Exim 4.92) (envelope-from ) id 1xJ7Wt-0006Ht-6k; Tue, 20 Oct 2026 10:57:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455358.1669200; Tue, 20 Oct 2026 10:57: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 1xJ7Wr-0006AG-Cc; Tue, 20 Oct 2026 10:57:13 +0000 Received: by outflank-mailman (input) for mailman id 1455358; Tue, 20 Oct 2026 10:51:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R2-0000Dh-IT for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R1-004dBJ-Vi for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:11 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479c-8faa-0a2a0a5109dd-0a2a450bb700-12 for ; Tue, 20 Oct 2026 12:51:11 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7479e-b7e8-0a2a450b0019-aa0a817cb205-3 for ; Tue, 20 Oct 2026 12:51:11 +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-315-plwKHC4NOLSL9hNBtPanxA-1; Tue, 20 Oct 2026 10:51:05 +0000 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 D94121800628; Tue, 20 Oct 2026 10:51:01 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1B6D11956089; Tue, 20 Oct 2026 10:50: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=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=1792493470; 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=OxciqWPAoEP3mYi79fT0gwyx/y+Ueu4PihTpFMb+Vro=; b=CqVoWHLhZ84pEkgr5wDmP1CtQuk4fnkA/sNu5kqWFyG9/dspdTTyTqiQuuCtdd8MMfZkX2 SmLFvkJz2YFfq+amhUWzz8P2S4jyk+J+GD7oBPIwUYqVMrUjHfw/+tM37LXaSYoL95Zf/0 nZEY3p2ceyX8mRg4TWcw6heDNo09TWc= X-MC-Unique: plwKHC4NOLSL9hNBtPanxA-1 X-Mimecast-MFC-AGG-ID: plwKHC4NOLSL9hNBtPanxA_1792493462 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:10 +0400 Subject: [PATCH v7 53/65] qdev: convert core PropertyInfo definitions to use qapi_type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-53-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=6959; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=RHtqBiZ1ZpqW16u5ZDKaCCTk7bDqrZ48KqqtmQit3DY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZctFtIhQr7wjwq0vlVATZsMz0DILvEH+0jv hwCsb531JmJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5fUsD/9v7R2O4amiuZ6SP+5w4OuXKDrY8C+/Sc9jWdJC+ykOn3MS1oFd6aG72bZkKifmaaiUg7L TYOQ73e/j30Aq8BxvAneXubghaxQasTkvl99rK7tpyVZmrR50QihCvaY/ojpH0CLNYG2XkUUxKL y8yd7vUzbbeRmLV9PNMcmwDeruh6TA0cZ9WXnDE587xYeh2mwT4wozR1RpBy/mOaVV6pCsAH5fC FJEzUzb0nzAnNGbVueWWQDRGCe73rj4hcn34RKSLYVxJQzQWL2mdCkPZN0RISYsH2pQ7vRwObYz NfzpXdVqc2iGmdIhuVCSrT22vQagV3Ver1Mu/8au7kLcxHnm9QFUhImJS4yToAOJk2Lgk2IJuAj RKOI0UHd43FbgYRrs5+S+TOkayjmFvlvJQ5ttHfYA95e+Dy55b6P2DbihYrAcl+AabExEmH+ikO Z3dzsDiMnsSR4xCGGFtThVh4RJ/4Qw1IGQAl3Lu+8C3d89oEU6hCmPWUiZAWw0a20/UT9N9KyKx is8Bnc3h8p0qMcWdiz2wZ7Pb/oOW6ZTqdF94KyeCq1FZS1D/CmS265DPmP+EGKz75jb30ZiRafc vpG2mZrXz/I1P9ivzKYIX20Jf3dTEQesxhMn3mUkfIGOcm3wVD1XCjYjkRPs6YUrOSeAgL0EmlP kEIkN/dkX0GxvOQ== 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: oItgUr_EWg9djf1ysjyX_2vq_zrOc5vUYItMzxhG-TY_1792493462 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493471-198C19EA-9AEC1DC8/0/0 X-purgate-type: clean X-purgate-size: 6961 Replace .type string with .qapi_type pointer on all core PropertyInfo definitions in qdev-properties.c. Remove .enum_table from enum definitions, since the lookup is now accessed through .qapi_type->lookup via the qdev_propinfo_enum_lookup() fallback helper. Note that qdev_prop_usize now reports "uint32" or "uint64" depending on the host. If usize is worth preserving, it should be added as a QAPI builtin type. Or perhaps we should simply use "size" everywhere (u64)? It's also strange to use type "size" for both u32 (prop_size32) and u64 (prop_size). Link property are actually strings. The "full type name" is set when the property is added, as "link". Array property will be refactored in a subsequent patch. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/qdev-properties.c | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c index ee50fbb9f570..abdb380cb9ec 100644 --- a/hw/core/qdev-properties.c +++ b/hw/core/qdev-properties.c @@ -12,6 +12,8 @@ #include "qdev-prop-internal.h" #include "qom/compat-properties.h" #include "qom/qom-qobject.h" +#include "qapi/qapi-builtin-type-infos.h" +#include "qapi/qapi-type-infos-common.h" void qdev_prop_set_after_realize(DeviceState *dev, const char *name, Error **errp) @@ -181,7 +183,7 @@ static void set_default_value_bool(ObjectProperty *op, const Property *prop) } const PropertyInfo qdev_prop_bit = { - .type = "bool", + .qapi_type = &bool_type_info, .description = "on/off", .get = prop_get_bit, .set = prop_set_bit, @@ -231,7 +233,7 @@ static void prop_set_bit64(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_bit64 = { - .type = "bool", + .qapi_type = &bool_type_info, .description = "on/off", .get = prop_get_bit64, .set = prop_set_bit64, @@ -293,9 +295,8 @@ static void prop_set_on_off_auto_bit64(Object *obj, Visitor *v, } const PropertyInfo qdev_prop_on_off_auto_bit64 = { - .type = "OnOffAuto", + .qapi_type = &OnOffAuto_type_info, .description = "on/off/auto", - .enum_table = &OnOffAuto_lookup, .get = prop_get_on_off_auto_bit64, .set = prop_set_on_off_auto_bit64, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -322,7 +323,7 @@ static void set_bool(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_bool = { - .type = "bool", + .qapi_type = &bool_type_info, .description = "on/off", .get = get_bool, .set = set_bool, @@ -362,7 +363,7 @@ void qdev_propinfo_set_default_value_uint(ObjectProperty *op, } const PropertyInfo qdev_prop_uint8 = { - .type = "uint8", + .qapi_type = &uint8_type_info, .get = get_uint8, .set = set_uint8, .set_default_value = qdev_propinfo_set_default_value_uint, @@ -389,7 +390,7 @@ static void set_uint16(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_uint16 = { - .type = "uint16", + .qapi_type = &uint16_type_info, .get = get_uint16, .set = set_uint16, .set_default_value = qdev_propinfo_set_default_value_uint, @@ -434,14 +435,14 @@ static void set_int32(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_uint32 = { - .type = "uint32", + .qapi_type = &uint32_type_info, .get = get_uint32, .set = set_uint32, .set_default_value = qdev_propinfo_set_default_value_uint, }; const PropertyInfo qdev_prop_int32 = { - .type = "int32", + .qapi_type = &int32_type_info, .get = qdev_propinfo_get_int32, .set = set_int32, .set_default_value = qdev_propinfo_set_default_value_int, @@ -486,14 +487,14 @@ static void set_int64(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_uint64 = { - .type = "uint64", + .qapi_type = &uint64_type_info, .get = get_uint64, .set = set_uint64, .set_default_value = qdev_propinfo_set_default_value_uint, }; const PropertyInfo qdev_prop_int64 = { - .type = "int64", + .qapi_type = &int64_type_info, .get = get_int64, .set = set_int64, .set_default_value = qdev_propinfo_set_default_value_int, @@ -515,7 +516,7 @@ static void set_uint64_checkmask(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_uint64_checkmask = { - .type = "uint64", + .qapi_type = &uint64_type_info, .get = get_uint64, .set = set_uint64_checkmask, }; @@ -551,7 +552,11 @@ static void set_usize(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_usize = { - .type = "usize", +#if HOST_LONG_BITS == 32 + .qapi_type = &uint32_type_info, +#else + .qapi_type = &uint64_type_info, +#endif .get = get_usize, .set = set_usize, .set_default_value = qdev_propinfo_set_default_value_uint, @@ -595,7 +600,7 @@ static void set_string(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_string = { - .type = "str", + .qapi_type = &str_type_info, .release = release_string, .get = get_string, .set = set_string, @@ -604,9 +609,8 @@ const PropertyInfo qdev_prop_string = { /* --- on/off/auto --- */ const PropertyInfo qdev_prop_on_off_auto = { - .type = "OnOffAuto", + .qapi_type = &OnOffAuto_type_info, .description = "on/off/auto", - .enum_table = &OnOffAuto_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -647,7 +651,7 @@ static void set_size32(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_size32 = { - .type = "size", + .qapi_type = &size_type_info, .get = qdev_propinfo_get_size32, .set = set_size32, .set_default_value = qdev_propinfo_set_default_value_uint, @@ -1060,7 +1064,7 @@ static void set_size(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_size = { - .type = "size", + .qapi_type = &size_type_info, .get = get_size, .set = set_size, .set_default_value = qdev_propinfo_set_default_value_uint, @@ -1142,7 +1146,7 @@ static void set_link(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_link = { - .type = "link", + .qapi_type = &str_type_info, .create = create_link_property, /* * Since we have a create method, the get and set are used -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455360.1669205 (Exim 4.92) (envelope-from ) id 1xJ7Wu-0006fc-Vc; Tue, 20 Oct 2026 10:57:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455360.1669205; Tue, 20 Oct 2026 10: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 1xJ7Wt-0006aK-Hs; Tue, 20 Oct 2026 10:57:15 +0000 Received: by outflank-mailman (input) for mailman id 1455360; Tue, 20 Oct 2026 10:51:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R4-0000Eh-36 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R3-00EzJf-G6 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:13 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479c-e002-0a2a0a5209dd-0a2a4505a14c-18 for ; Tue, 20 Oct 2026 12:51:13 +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 6ad7479f-4cb1-0a2a45050019-aa0a857c7871-3 for ; Tue, 20 Oct 2026 12:51:13 +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-456-_pwTePgnOyq7pM8ip4VO7Q-1; Tue, 20 Oct 2026 10:51:01 +0000 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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 91D281800EFA; Tue, 20 Oct 2026 10:50:56 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 15C651956088; Tue, 20 Oct 2026 10:50:54 +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=1792493471; 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=O4pdCz1MgQ3GeOtrPeQzKHNQrLJKFwMgs4D5tHNFOGI=; b=XsVRMeFFt21/YhHE2stfcKEd33yp9FwNaoEOIFlWhKw0JoA9Ag1wdQB8kvNTJSsMztXxcc FTPNsz+G57IRpLci0SFzClu5GR4GyJCLxO9s7VWlAzfV3IL4kQcGDXFMxGEscRbwr0mb4Y pTHDiFkMG9yZRxtlNZumwpYJdCN+3GA= X-MC-Unique: _pwTePgnOyq7pM8ip4VO7Q-1 X-Mimecast-MFC-AGG-ID: _pwTePgnOyq7pM8ip4VO7Q_1792493456 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:09 +0400 Subject: [PATCH v7 52/65] qdev: add qapi_type field to PropertyInfo with fallback registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-52-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=7178; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=MHwt79KEqovxMUVbjLHZbzyPQ3O7/QvHLzBLKn+XdlM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Zcd4GS3Tym0oVL8eCpFa4hRCCy54I3T6LAS GF+IaGc/aeJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5WzhEACv7w/6wGYDKzLQ4S7kKafC2zvA6aWWltqZx5U2rfzcdYynrwTqRWspmtblrvG3W+dgEC+ GAiDyLTgKT/lplKlqYBCdfo+mBOQ4RjrVFTquBNP7tb1Fd+qp3t9zQNOdVsG19deLE9AuNuonie dHae66WUQvaHL65hhmJipl9CSHWAnomOXOJyyJ5TL7veXseSM7+BeIhf9rfjjFO8FcXXPYefN7N Vj3I83aE6DPR/08nzenNixXWPzk/ArswJ6q/WcvvA4tPhYrSNEycqptfkH7BEXqVd7el6w8D/YN MPh3DkIQPMJRNazDp8xYwJ9S7WdeQafqvm2YRNH3av88ggfFTz7NYxyA1NqzQtYSoUdHWuIhTn4 iEQZvksitISNyDmdkzfDLuR2kXyHOr5e/Ll/cSV0Ps9dQfXLywgbcnCbHnAusIvjx2/yJpdI/Kw UDLtSxgSEKeHrkvuJ1rkjQRWeS3sG8ZaCwAtAzrvEAf7FBdvdyzvLVfovAymyrCO3O4KUQsdLtc k505iFW90rwA+7wcXcuPkUs77jjArhUF6EOpJVKL6ErZLXV946xeHqqPjfKif9ol3evcCxzVX6r unBBDNEV7BsJc5ZHOQ+1Ftf9LXCkbgKFmXSobicTcap1DX/Io5n/fKrAoeaRBbBM42ysjZJzaqZ B28Z8/csjxKt2hA== 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: GIUICMVa35xPwusYeLywITNAKTrcBo3E3X-oKi0LE0Y_1792493456 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792493473-F5EA92A1-0FE4773E/0/0 X-purgate-type: clean X-purgate-size: 7180 Add a qapi_type field to PropertyInfo to prepare for the transition from string-based type metadata to QAPI type-info. Add a qdev_prop_qapi_type() helper that resolves the QAPI type for a property from .qapi_type. It will be later extended to cope with array types. Update qdev_property_add_static() and qdev_class_add_property() to prefer object_property_add_qapi() when a QAPI type is available, falling back to the old object_property_add() for unconverted properties. Update the shared enum accessor functions to prefer .qapi_type->lookup over .enum_table via a new qdev_propinfo_enum_lookup() helper. No PropertyInfo definitions are changed, all .qapi_type fields default to NULL, so the fallback paths are always taken. This patch is no-op for now. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/qdev-properties.c | 68 ++++++++++++++++++++++++++++++--------- include/hw/core/qdev-properties.h | 1 + 2 files changed, 53 insertions(+), 16 deletions(-) diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c index 34d7b26a7303..ee50fbb9f570 100644 --- a/hw/core/qdev-properties.c +++ b/hw/core/qdev-properties.c @@ -99,13 +99,22 @@ static ObjectPropertyAccessor *field_prop_setter(const PropertyInfo *info) return info->set ? field_prop_set : NULL; } +static const QEnumLookup *qdev_propinfo_enum_lookup(const PropertyInfo *info) +{ + if (info->qapi_type) { + assert(info->qapi_type->lookup); + return info->qapi_type->lookup; + } + return info->enum_table; +} + void qdev_propinfo_get_enum(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) { const Property *prop = opaque; int *ptr = object_field_prop_ptr(obj, prop); - visit_type_enum(v, name, ptr, prop->info->enum_table, errp); + visit_type_enum(v, name, ptr, qdev_propinfo_enum_lookup(prop->info), errp); } void qdev_propinfo_set_enum(Object *obj, Visitor *v, const char *name, @@ -114,14 +123,15 @@ void qdev_propinfo_set_enum(Object *obj, Visitor *v, const char *name, const Property *prop = opaque; int *ptr = object_field_prop_ptr(obj, prop); - visit_type_enum(v, name, ptr, prop->info->enum_table, errp); + visit_type_enum(v, name, ptr, qdev_propinfo_enum_lookup(prop->info), errp); } void qdev_propinfo_set_default_value_enum(ObjectProperty *op, const Property *prop) { object_property_set_default_str(op, - qapi_enum_lookup(prop->info->enum_table, prop->defval.i)); + qapi_enum_lookup(qdev_propinfo_enum_lookup(prop->info), + prop->defval.i)); } /* Bit */ @@ -941,8 +951,8 @@ void qdev_prop_set_enum(DeviceState *dev, const char *name, int value) prop = qdev_prop_find(dev, name); object_property_set_str(OBJECT(dev), name, - qapi_enum_lookup(prop->info->enum_table, value), - &error_abort); + qapi_enum_lookup(qdev_propinfo_enum_lookup(prop->info), value), + &error_abort); } void qdev_prop_set_array(DeviceState *dev, const char *name, QList *values) @@ -1143,18 +1153,33 @@ const PropertyInfo qdev_prop_link = { .set = set_link, }; +static const QAPITypeInfo *qdev_prop_qapi_type(const Property *prop) +{ + /* this will be later extended to cope with QAPI array properties */ + return prop->info->qapi_type; +} + void qdev_property_add_static(DeviceState *dev, const Property *prop) { Object *obj = OBJECT(dev); ObjectProperty *op; + const QAPITypeInfo *qapi_type = qdev_prop_qapi_type(prop); assert(!prop->info->create); - op = object_property_add(obj, prop->name, prop->info->type, - field_prop_getter(prop->info), - field_prop_setter(prop->info), - prop->info->release, - (Property *)prop); + if (qapi_type) { + op = object_property_add_qapi(obj, prop->name, qapi_type, + field_prop_getter(prop->info), + field_prop_setter(prop->info), + prop->info->release, + (Property *)prop); + } else { + op = object_property_add(obj, prop->name, prop->info->type, + field_prop_getter(prop->info), + field_prop_setter(prop->info), + prop->info->release, + (Property *)prop); + } object_property_set_description(obj, prop->name, prop->info->description); @@ -1176,12 +1201,23 @@ static void qdev_class_add_property(DeviceClass *klass, const char *name, if (prop->info->create) { op = prop->info->create(oc, name, prop); } else { - op = object_class_property_add(oc, - name, prop->info->type, - field_prop_getter(prop->info), - field_prop_setter(prop->info), - prop->info->release, - (Property *)prop); + const QAPITypeInfo *qapi_type = qdev_prop_qapi_type(prop); + + if (qapi_type) { + op = object_class_property_add_qapi(oc, + name, qapi_type, + field_prop_getter(prop->info), + field_prop_setter(prop->info), + prop->info->release, + (Property *)prop); + } else { + op = object_class_property_add(oc, + name, prop->info->type, + field_prop_getter(prop->info), + field_prop_setter(prop->info), + prop->info->release, + (Property *)prop); + } } if (prop->set_default) { prop->info->set_default_value(op, prop); diff --git a/include/hw/core/qdev-properties.h b/include/hw/core/qdev-properties.h index eba5436e53b1..1ea2ba66bb37 100644 --- a/include/hw/core/qdev-properties.h +++ b/include/hw/core/qdev-properties.h @@ -34,6 +34,7 @@ struct PropertyInfo { const char *type; const char *description; const QEnumLookup *enum_table; + const QAPITypeInfo *qapi_type; bool realized_set_allowed; /* allow setting property on realized device */ char *(*print)(Object *obj, const Property *prop); void (*set_default_value)(ObjectProperty *op, const Property *prop); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455361.1669209 (Exim 4.92) (envelope-from ) id 1xJ7Ww-0006zY-5S; Tue, 20 Oct 2026 10:57:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455361.1669209; Tue, 20 Oct 2026 10: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 1xJ7Wu-0006tN-VQ; Tue, 20 Oct 2026 10:57:16 +0000 Received: by outflank-mailman (input) for mailman id 1455361; Tue, 20 Oct 2026 10:51:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R4-0000F4-En for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R3-002FaV-RW for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74796-bab6-0a2a0a5309dd-0a2a4506ed12-36 for ; Tue, 20 Oct 2026 12:51:13 +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 6ad74764-195a-0a2a45060019-aa0a817c6f5d-3 for ; Tue, 20 Oct 2026 12:50:13 +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-553-_7Frlu4AM46-pYvhF0dpvA-1; Tue, 20 Oct 2026 10:50:08 +0000 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7188D1956076; Tue, 20 Oct 2026 10:50:03 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DC7271800586; Tue, 20 Oct 2026 10:50: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=1792493412; 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=EljyyKpOaP+UVHeVMtiabRjWia9m5EXPj7DEMxHLTqI=; b=QMWsi5VVcviMK0s0SHV+TgMQk21CviSjtawjS/R8q89kZClam+7WG56cyle89XmhkpEnMp 9JMXCTEeMD61s7Ip6tjq2YTSPsDcHoc0fea4kdHHaI3V0ZcykzlXQ/yoMvpxa8DQuLr5za 0MvGekwskWGDTwuoBBqy1OmjO3Zc8Zo= X-MC-Unique: _7Frlu4AM46-pYvhF0dpvA-1 X-Mimecast-MFC-AGG-ID: _7Frlu4AM46-pYvhF0dpvA_1792493403 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:59 +0400 Subject: [PATCH v7 42/65] virtio-balloon: convert guest-stats property to QAPI type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-42-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=10182; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=0g8PFfs3LJuc0BLWv6rMvjXCCHAbNtdnRJuucBbysso=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZbJgd7s8Bcgu4jJ87MBVuZ+yAsGD3uZV7Ld ZOdhpMi4vyJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5a+iD/9O1qwWl2Gco4J1mBvanY/rwFGr7NPb9pyAfuwVDpozMDdvXhMl7hahB1Ds96uxJ/rE4qX SBiL4gdjh3V17vwq4s8eVGAy4vXzmKarp9JFyYGBdIYBMyaD/l/nF9JpCvzHBfeoJVaJiT1PQQt xYL67ZSgUBNuzxP6nOe8i/6molK+XMubhLA3Kq2QQXlkYO/VdfQtO/IJhzrmXxbG01aPW1rlCzK dpH2Pg86MU+st3pFO6V2u2mWPT4iBrhRvldHPguFEFz3XzWBP4mk0lC6FjZzlsEbsug2La+TE/A Cssx+kRcv3yHPtzgrG0dTA8JSlBWJMGi6Mj+MpceHoDoFYuX3fYpide5R/fVlg+SeNqlorDtHuk novEDfzkqUfPInZeNVGWeblx5V2CWdPPHGjJiTexE+gYnW0dCzCdm7huVbeMNcwx115bEnARo3K 3p5W5EaVBokC/qsklxmPmHMpC8HOC11c6bky6ZydQ9R0CXbJaooGegZUHMl8BQVojw9uT4HuIEf zhvHk7DKGkyT1aTa3Oe+Ey83EQ7NDIygPh75uIZjWT6gzgVMLebNYJMiE9wdeb8EdXuAg/JFEnW F8wmPQVW1QH9o6VSbwih+m8LfSoBGJO4URR1+cnKCLSUdPeyYFJmFz5ZccsUYDyKK8i/VtQMyW0 2U8t9WP1qP4jaPg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: tIpB-4zpMbNMmps9qekzvNkoNPKCEbNfugiMWQYz9t8_1792493403 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1792493413-FC80577B-77A5D993/0/0 X-purgate-type: clean X-purgate-size: 10184 Define VirtioBalloonStats and VirtioBalloonGuestStats QAPI struct types in the schema, replacing the hand-rolled visitor in balloon_stats_get_all() with a generated visit_type_VirtioBalloonGuestStats() call. The wire format is preserved: the JSON output from qom-get is identical to the previous hand-rolled visitor output. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- docs/interop/virtio-balloon-stats.rst | 22 +-------- hw/virtio/virtio-balloon.c | 84 ++++++++++++-------------------- qapi/machine.json | 92 +++++++++++++++++++++++++++++++++++ 3 files changed, 123 insertions(+), 75 deletions(-) diff --git a/docs/interop/virtio-balloon-stats.rst b/docs/interop/virtio-balloon-stats.rst index b9a6a6edb229..88d3271bbb02 100644 --- a/docs/interop/virtio-balloon-stats.rst +++ b/docs/interop/virtio-balloon-stats.rst @@ -22,27 +22,7 @@ polling the guest's balloon driver for new stats in the specified time interval. To retrieve those stats, clients have to query the guest-stats property, -which will return a dictionary containing: - - * A key named 'stats', containing all available stats. If the guest - doesn't support a particular stat, or if it couldn't be retrieved, - its value will be -1. Currently, the following stats are supported: - - - stat-swap-in - - stat-swap-out - - stat-major-faults - - stat-minor-faults - - stat-free-memory - - stat-total-memory - - stat-available-memory - - stat-disk-caches - - stat-htlb-pgalloc - - stat-htlb-pgfail - - * A key named last-update, which contains the last stats update - timestamp in seconds. Since this timestamp is generated by the host, - a buggy guest can't influence its value. The value is 0 if the guest - has not updated the stats (yet). +which will return a VirtioBalloonGuestStats (see QAPI documentation). It's also important to note the following: diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c index 7ffbe48e5134..bfc75f5dfc72 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -29,6 +29,8 @@ #include "qapi/error.h" #include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-events-machine.h" +#include "qapi/qapi-type-infos-machine.h" +#include "qapi/qapi-visit-machine.h" #include "qapi/visitor.h" #include "trace.h" #include "qemu/error-report.h" @@ -170,33 +172,8 @@ static void balloon_deflate_page(VirtIOBalloon *balloon, } } -/* - * All stats upto VIRTIO_BALLOON_S_NR /must/ have a - * non-NULL name declared here, since these are used - * as keys for populating the QDict with stats - */ -static const char *balloon_stat_names[] = { - [VIRTIO_BALLOON_S_SWAP_IN] = "stat-swap-in", - [VIRTIO_BALLOON_S_SWAP_OUT] = "stat-swap-out", - [VIRTIO_BALLOON_S_MAJFLT] = "stat-major-faults", - [VIRTIO_BALLOON_S_MINFLT] = "stat-minor-faults", - [VIRTIO_BALLOON_S_MEMFREE] = "stat-free-memory", - - [VIRTIO_BALLOON_S_MEMTOT] = "stat-total-memory", - [VIRTIO_BALLOON_S_AVAIL] = "stat-available-memory", - [VIRTIO_BALLOON_S_CACHES] = "stat-disk-caches", - [VIRTIO_BALLOON_S_HTLB_PGALLOC] = "stat-htlb-pgalloc", - [VIRTIO_BALLOON_S_HTLB_PGFAIL] = "stat-htlb-pgfail", - - [VIRTIO_BALLOON_S_OOM_KILL] = "stat-oom-kills", - [VIRTIO_BALLOON_S_ALLOC_STALL] = "stat-alloc-stalls", - [VIRTIO_BALLOON_S_ASYNC_SCAN] = "stat-async-scans", - [VIRTIO_BALLOON_S_DIRECT_SCAN] = "stat-direct-scans", - [VIRTIO_BALLOON_S_ASYNC_RECLAIM] = "stat-async-reclaims", - - [VIRTIO_BALLOON_S_DIRECT_RECLAIM] = "stat-direct-reclaims", -}; -G_STATIC_ASSERT(G_N_ELEMENTS(balloon_stat_names) == VIRTIO_BALLOON_S_NR); +/* Update VirtioBalloonStats QAPI type when new stats are added */ +G_STATIC_ASSERT(VIRTIO_BALLOON_S_NR == 16); /* * reset_stats - Mark all items in the stats array as unset @@ -258,33 +235,31 @@ static void balloon_stats_get_all(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) { VirtIOBalloon *s = VIRTIO_BALLOON(obj); - bool ok = false; - int i; + VirtioBalloonStats stats = { + .stat_swap_in = s->stats[VIRTIO_BALLOON_S_SWAP_IN], + .stat_swap_out = s->stats[VIRTIO_BALLOON_S_SWAP_OUT], + .stat_major_faults = s->stats[VIRTIO_BALLOON_S_MAJFLT], + .stat_minor_faults = s->stats[VIRTIO_BALLOON_S_MINFLT], + .stat_free_memory = s->stats[VIRTIO_BALLOON_S_MEMFREE], + .stat_total_memory = s->stats[VIRTIO_BALLOON_S_MEMTOT], + .stat_available_memory = s->stats[VIRTIO_BALLOON_S_AVAIL], + .stat_disk_caches = s->stats[VIRTIO_BALLOON_S_CACHES], + .stat_htlb_pgalloc = s->stats[VIRTIO_BALLOON_S_HTLB_PGALLOC], + .stat_htlb_pgfail = s->stats[VIRTIO_BALLOON_S_HTLB_PGFAIL], + .stat_oom_kills = s->stats[VIRTIO_BALLOON_S_OOM_KILL], + .stat_alloc_stalls = s->stats[VIRTIO_BALLOON_S_ALLOC_STALL], + .stat_async_scans = s->stats[VIRTIO_BALLOON_S_ASYNC_SCAN], + .stat_direct_scans = s->stats[VIRTIO_BALLOON_S_DIRECT_SCAN], + .stat_async_reclaims = s->stats[VIRTIO_BALLOON_S_ASYNC_RECLAIM], + .stat_direct_reclaims = s->stats[VIRTIO_BALLOON_S_DIRECT_RECLAIM], + }; + VirtioBalloonGuestStats guest_stats = { + .last_update = s->stats_last_update, + .stats = &stats, + }; + VirtioBalloonGuestStats *argp = &guest_stats; - if (!visit_start_struct(v, name, NULL, 0, errp)) { - return; - } - if (!visit_type_int(v, "last-update", &s->stats_last_update, errp)) { - goto out_end; - } - - if (!visit_start_struct(v, "stats", NULL, 0, errp)) { - goto out_end; - } - for (i = 0; i < VIRTIO_BALLOON_S_NR; i++) { - if (!visit_type_uint64(v, balloon_stat_names[i], &s->stats[i], errp)) { - goto out_nested; - } - } - ok = visit_check_struct(v, errp); -out_nested: - visit_end_struct(v, NULL); - - if (ok) { - visit_check_struct(v, errp); - } -out_end: - visit_end_struct(v, NULL); + visit_type_VirtioBalloonGuestStats(v, name, &argp, errp); } static void balloon_stats_get_poll_interval(Object *obj, Visitor *v, @@ -1037,7 +1012,8 @@ static void virtio_balloon_instance_init(Object *obj) s->free_page_hint_cmd_id = VIRTIO_BALLOON_FREE_PAGE_HINT_CMD_ID_MIN; s->free_page_hint_notify.notify = virtio_balloon_free_page_hint_notify; - object_property_add(obj, "guest-stats", "guest statistics", + object_property_add_qapi(obj, "guest-stats", + &VirtioBalloonGuestStats_type_info, balloon_stats_get_all, NULL, NULL, NULL); object_property_add_qapi(obj, "guest-stats-polling-interval", &int_type_info, diff --git a/qapi/machine.json b/qapi/machine.json index 9b145c635baf..34be3156270c 100644 --- a/qapi/machine.json +++ b/qapi/machine.json @@ -1126,6 +1126,98 @@ ## { 'struct': 'BalloonInfo', 'data': {'actual': 'int' } } +## +# @VirtioBalloonStats: +# +# VirtIO balloon device guest memory statistics. +# +# If the guest doesn't support a particular stat, or if it couldn't +# be retrieved, its value will be -1. +# +# @stat-swap-in: The amount of memory that has been +# swapped in (in bytes). +# +# @stat-swap-out: The amount of memory that has been +# swapped out to disk (in bytes). +# +# @stat-major-faults: The number of major page faults +# that have occurred. +# +# @stat-minor-faults: The number of minor page faults +# that have occurred. +# +# @stat-free-memory: The amount of memory not being used +# for any purpose (in bytes). +# +# @stat-total-memory: The total amount of memory available +# (in bytes). +# +# @stat-available-memory: An estimate of how much memory is available +# (in bytes) for starting new applications, without pushing the +# system to swap. +# +# @stat-disk-caches: The amount of memory, in bytes, that can be +# quickly reclaimed without additional I/O. Typically these pages +# are used for caching files from disk. +# +# @stat-htlb-pgalloc: The number of successful hugetlb page +# allocations +# +# @stat-htlb-pgfail: The number of failed hugetlb page +# allocations +# +# @stat-oom-kills: The number of OOM killer invocations +# +# @stat-alloc-stalls: The number of memory allocation stalls +# +# @stat-async-scans: The number of memory scanned asynchronously +# +# @stat-direct-scans: The number of memory scanned directly +# +# @stat-async-reclaims: The number of memory reclaimed asynchronously +# +# @stat-direct-reclaims: The number of memory reclaimed directly +# +# Since: 11.2 +## +{ 'struct': 'VirtioBalloonStats', + 'data': { + 'stat-swap-in': 'uint64', + 'stat-swap-out': 'uint64', + 'stat-major-faults': 'uint64', + 'stat-minor-faults': 'uint64', + 'stat-free-memory': 'uint64', + 'stat-total-memory': 'uint64', + 'stat-available-memory': 'uint64', + 'stat-disk-caches': 'uint64', + 'stat-htlb-pgalloc': 'uint64', + 'stat-htlb-pgfail': 'uint64', + 'stat-oom-kills': 'uint64', + 'stat-alloc-stalls': 'uint64', + 'stat-async-scans': 'uint64', + 'stat-direct-scans': 'uint64', + 'stat-async-reclaims': 'uint64', + 'stat-direct-reclaims': 'uint64' } } + +## +# @VirtioBalloonGuestStats: +# +# Guest statistics from the VirtIO balloon device. +# +# @last-update: timestamp in seconds of the last stats +# update from the guest (since this timestamp is generated +# by the host, a buggy guest can't influence its value), +# or 0 if no update has been received yet. +# +# @stats: balloon memory statistics +# +# Since: 11.2 +## +{ 'struct': 'VirtioBalloonGuestStats', + 'data': { + 'last-update': 'int', + 'stats': 'VirtioBalloonStats' } } + ## # @query-balloon: # Return information about the balloon device. -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455362.1669216 (Exim 4.92) (envelope-from ) id 1xJ7Wx-0007Cz-Nc; Tue, 20 Oct 2026 10:57:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455362.1669216; Tue, 20 Oct 2026 10: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 1xJ7Ww-0007A8-Gx; Tue, 20 Oct 2026 10:57:18 +0000 Received: by outflank-mailman (input) for mailman id 1455362; Tue, 20 Oct 2026 10:51:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R4-0000F8-Kz for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R4-00CroT-1g for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:14 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74788-2eae-0a2a0a5409dd-0a2a4501d57a-44 for ; Tue, 20 Oct 2026 12:51:14 +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 6ad746b0-5984-0a2a45010019-aa0a817c8889-3 for ; Tue, 20 Oct 2026 12:47:13 +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-413-CaChFFwCP4K-8MY9RuA87Q-1; Tue, 20 Oct 2026 10:47:08 +0000 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 4ECE719560BA; Tue, 20 Oct 2026 10:47:04 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6FCFD1800643; Tue, 20 Oct 2026 10:47: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=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=1792493232; 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=9fsJslKCeoRdmSlurWERnpkKgveOnsXmWR9P5zsycws=; b=H69cYq6FuKpeO2ENt7EWyJq4cJDN4BNwP+POU9R4QeAhtq1+yBPt24jsOAydLC1+VujDQH MnPZlItPWrzoGxlDFNCN0OCcmhez9a9mKrcfgXO0wOvnaX18Gt5aCXA1kkiN4WqNtYe4ip 8TqXKEL0rgT+A92PqOcl8cIsYakVQNA= X-MC-Unique: CaChFFwCP4K-8MY9RuA87Q-1 X-Mimecast-MFC-AGG-ID: CaChFFwCP4K-8MY9RuA87Q_1792493224 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:26 +0400 Subject: [PATCH v7 09/65] qapi: add type-infos generator MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-9-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=11937; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=g11BDsqjD7nTY1JkXgXYml3RSI9xXvonR2GIve0ncmU=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZYJJsN/o3bE8+2FCYnBUPV5NJQM5Nv0DZ+W cs66TGPSluJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWAAKCRDa6OEJdZac 5X89D/9JRzqpQfKNC9gbQGRY59/nwxgGa32YPoyHyyoM0h2BvDmF7ZbinfNq2T9MVqshAYEoiFR xc7ljZ9NoGxlTuLVwS1aNl6HHnsmDhKb5jVgr5AoMWWz4rVqi+xj63l45jNUSseCUXeuy0bCkEg yZQBQUFEMFUZf304KtU3Njd18Egs4T0KuLqkFEEw5dkzWV3eZ/b5OhaCAKqoZedcvkQsZW7uvwI 6Ae0AjBOYIfxG3WN9Ij9DoZ8/I8X4ziwRqXr89st8Dtr0I2t6e9J2cXetf9OWT4OGfPwxsEliyT icKaxTcbiSyEP+QhBnS7Vz3hB/KApZDT+czUQX6T29+2H8KRyPs41CClGk1MQ4rUIz5QDTn98sZ SSY/ZdRafGBX/r+hQ8bLdy5WzBHNtnn5vjrxoOalrZQ3lkgmFSB+R3UMIxHTPRzij+vsVtmiGxw U5gv0Srb6iZ8qjMjcqiupzChnZtsLekIggh80TZwGRjdhyZdXY7Xn2FoW/Hn7QVfxpGn+9wEUQ3 bpdpQSG0xXFH+C38NmXfJ72C/QyZIu9PqL8R5H/iyqxdRJd92ojKG3qoIStS+8l19dNilIxa2YR eL1VActz/GY+9zR11F3R3dnsROQAhx1070vOdfVrv0WbKEHtXIw+k49jML+OTKNlgawyHNIFBDf bKqUQ5KwfG4PxOA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: PYnD41ipzsbdZ-2HiYmfib_EgstlHwjn_bdzSJZWj8s_1792493224 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792493233-1F063757-B1D64FEC/0/0 X-purgate-type: clean X-purgate-size: 11939 New QAPISchemaGenTypeInfoVisitor produces per-module qapi-type-infos-*.h/c files. Each file declares QAPITypeInfo constants pairing the QAPI type name with its masked introspection name. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- docs/devel/qapi-code-gen.rst | 92 ++++++++++++++++++++++++ meson.build | 1 + scripts/qapi/backend.py | 2 + scripts/qapi/type_infos.py | 163 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 258 insertions(+) diff --git a/docs/devel/qapi-code-gen.rst b/docs/devel/qapi-code-gen.rst index 77f08bb68cac..1cc5338a210a 100644 --- a/docs/devel/qapi-code-gen.rst +++ b/docs/devel/qapi-code-gen.rst @@ -1250,6 +1250,9 @@ JSON array of strings. To examine a type, start with a command or event using it, then follow references by name. +.. TODO document QOM introspection (qom-list, qom-list-properties, + qom-get) and how it relates to QAPI type information. + The SchemaInfo for a command has meta-type "command", and variant members "arg-type", "ret-type" and "allow-oob". On the wire, the "arguments" member of a client's "execute" command must conform to the @@ -2099,3 +2102,92 @@ Example:: })); [Uninteresting stuff omitted...] + + +Code generated for type information +----------------------------------- + +Type information is generated for user-defined types and their array +types. With option --builtins, it is also generated for the built-in +types. + +The following files are created: + + ``$(prefix)qapi-type-infos.c`` + A ``QAPITypeInfo`` instance for each type listed above, providing + a mapping between the QAPI type name and the masked name used by + introspection, along with optional enum lookup table and array + type pointers. + + ``$(prefix)qapi-type-infos.h`` + Declarations for the above type info instances + +Each ``QAPITypeInfo`` struct has the following fields: + +``name`` + The QAPI type name (e.g. ``"UserDefOne"``). + +``masked_name`` + The masked name used in ``query-qmp-schema`` output. + +``lookup`` + For enum types, a pointer to the corresponding ``QEnumLookup`` + table. ``NULL`` for non-enum types. + +``list`` + For types that have an array variant, a pointer to the array type's + ``QAPITypeInfo``. ``NULL`` when no array type exists. + +These type info instances are used by QOM property registration +functions (``object_property_add_qapi()``, +``object_class_property_add_qapi_enum()``, etc.) to associate each +property with its QAPI type. The ``qom-list`` and +``device-list-properties`` QMP commands then expose the ``qapi-type`` +field, giving management tools a formal type reference they can look +up in the introspection schema. + +Example:: + + $ cat qapi-generated/example-qapi-type-infos.h + [Uninteresting stuff omitted...] + + #ifndef EXAMPLE_QAPI_TYPE_INFOS_H + #define EXAMPLE_QAPI_TYPE_INFOS_H + + #include "qapi/qapi-builtin-type-infos.h" + + extern const QAPITypeInfo UserDefOne_type_info; + + extern const QAPITypeInfo UserDefOneList_type_info; + + #endif /* EXAMPLE_QAPI_TYPE_INFOS_H */ + $ cat qapi-generated/example-qapi-type-infos.c + [Uninteresting stuff omitted...] + + const QAPITypeInfo UserDefOne_type_info = { + .name = "UserDefOne", + .masked_name = "1", + .list = &UserDefOneList_type_info, + }; + + const QAPITypeInfo UserDefOneList_type_info = { + .name = "UserDefOneList", + .masked_name = "[1]", + }; + + [Uninteresting stuff omitted...] + +For a modular QAPI schema (see section `Include directives`_), code for +each sub-module SUBDIR/SUBMODULE.json is actually generated into :: + + SUBDIR/$(prefix)qapi-type-infos-SUBMODULE.h + SUBDIR/$(prefix)qapi-type-infos-SUBMODULE.c + +If qapi-gen.py is run with option --builtins, additional files are +created: + + ``qapi-builtin-type-infos.h`` + Type info instances for built-in types + + ``qapi-builtin-type-infos.c`` + Definitions for the above type info instances diff --git a/meson.build b/meson.build index bbef9d9c2932..e51fb7a37740 100644 --- a/meson.build +++ b/meson.build @@ -3510,6 +3510,7 @@ qapi_gen_depends = [ meson.current_source_dir() / 'scripts/qapi/__init__.py', meson.current_source_dir() / 'scripts/qapi/parser.py', meson.current_source_dir() / 'scripts/qapi/schema.py', meson.current_source_dir() / 'scripts/qapi/source.py', + meson.current_source_dir() / 'scripts/qapi/type_infos.py', meson.current_source_dir() / 'scripts/qapi/types.py', meson.current_source_dir() / 'scripts/qapi/visit.py', meson.current_source_dir() / 'scripts/qapi-gen.py' diff --git a/scripts/qapi/backend.py b/scripts/qapi/backend.py index 49ae6ecdd33e..508ab2173539 100644 --- a/scripts/qapi/backend.py +++ b/scripts/qapi/backend.py @@ -8,6 +8,7 @@ from .features import gen_features from .introspect import gen_introspect from .schema import QAPISchema +from .type_infos import gen_type_infos from .types import gen_types from .visit import gen_visit @@ -63,3 +64,4 @@ def generate(self, gen_commands(schema, output_dir, prefix, gen_tracing) gen_events(schema, output_dir, prefix) gen_introspect(schema, output_dir, prefix, unmask) + gen_type_infos(schema, output_dir, prefix, builtins, unmask) diff --git a/scripts/qapi/type_infos.py b/scripts/qapi/type_infos.py new file mode 100644 index 000000000000..b29e31d92640 --- /dev/null +++ b/scripts/qapi/type_infos.py @@ -0,0 +1,163 @@ +""" +QAPI type info generator + +SPDX-License-Identifier: GPL-2.0-or-later +""" + +from typing import List, Optional + +from .common import c_name, mcgen +from .gen import QAPISchemaModularCVisitor, ifcontext +from .schema import ( + QAPISchema, + QAPISchemaAlternatives, + QAPISchemaBranches, + QAPISchemaEnumMember, + QAPISchemaFeature, + QAPISchemaIfCond, + QAPISchemaObjectType, + QAPISchemaObjectTypeMember, + QAPISchemaType, +) +from .source import QAPISourceInfo + + +class QAPISchemaGenTypeInfoVisitor(QAPISchemaModularCVisitor): + + def __init__(self, prefix: str, unmask: bool): + super().__init__( + prefix, 'qapi-type-infos', + ' * Schema-defined QAPI type info', + ' * Built-in QAPI type info', __doc__) + self._unmask = unmask + self._schema: Optional[QAPISchema] = None + + def visit_begin(self, schema: QAPISchema) -> None: + super().visit_begin(schema) + self._schema = schema + + def _begin_builtin_module(self) -> None: + self._genc.preamble_add(mcgen(''' +#include "qemu/osdep.h" +#include "qapi/qapi-builtin-types.h" +#include "qapi/qapi-builtin-type-infos.h" +''')) + self._genh.preamble_add(mcgen(''' +#include "qapi/qapi-type-info.h" +''')) + + def _begin_user_module(self, name: str) -> None: + type_infos = self._module_basename('qapi-type-infos', name) + types = self._module_basename('qapi-types', name) + self._genc.preamble_add(mcgen(''' +#include "qemu/osdep.h" +#include "%(types)s.h" +#include "%(type_infos)s.h" +''', + types=types, + type_infos=type_infos)) + self._genh.preamble_add(mcgen(''' +#include "qapi/qapi-builtin-type-infos.h" +''')) + + def _has_list(self, name: str) -> bool: + assert self._schema is not None + return self._schema.lookup_type(name + 'List') is not None + + def _masked_name(self, name: str) -> str: + assert self._schema is not None + return self._schema.definition_introspection_name(name, self._unmask) + + def _gen_type_info(self, name: str, + ifcond: Optional[QAPISchemaIfCond] = None, + with_lookup: bool = False, + with_list: bool = False) -> None: + c_id = c_name(name + '_type_info') + masked_name_str = '"%s"' % self._masked_name(name) + with ifcontext(ifcond or QAPISchemaIfCond(), + self._genh, self._genc): + self._genh.add(mcgen(''' + +extern const QAPITypeInfo %(c_id)s; +''', + c_id=c_id)) + self._genc.add(mcgen(''' + +const QAPITypeInfo %(c_id)s = { + .name = "%(name)s", + .masked_name = %(masked_name)s, +''', + c_id=c_id, name=name, + masked_name=masked_name_str)) + if with_lookup: + self._genc.add(mcgen(''' + .lookup = &%(c_name)s_lookup, +''', + c_name=c_name(name))) + if with_list: + self._genc.add(mcgen(''' + .list = &%(list_id)s, +''', + list_id=c_name(name + 'List_type_info'))) + self._genc.add(mcgen(''' +}; +''')) + + def visit_builtin_type(self, + name: str, + info: Optional[QAPISourceInfo], + json_type: str) -> None: + self._gen_type_info(name, with_list=self._has_list(name)) + + def visit_enum_type(self, + name: str, + info: Optional[QAPISourceInfo], + ifcond: QAPISchemaIfCond, + features: List[QAPISchemaFeature], + members: List[QAPISchemaEnumMember], + prefix: Optional[str]) -> None: + self._gen_type_info(name, ifcond, + with_lookup=True, + with_list=self._has_list(name)) + + def visit_array_type(self, + name: str, + info: Optional[QAPISourceInfo], + ifcond: QAPISchemaIfCond, + element_type: QAPISchemaType) -> None: + self._gen_type_info(name, ifcond) + + def visit_object_type(self, + name: str, + info: Optional[QAPISourceInfo], + ifcond: QAPISchemaIfCond, + features: List[QAPISchemaFeature], + base: Optional[QAPISchemaObjectType], + members: List[QAPISchemaObjectTypeMember], + branches: Optional[QAPISchemaBranches]) -> None: + assert self._schema is not None + typ = self._schema.lookup_type(name) + assert typ + if typ.is_implicit(): + return + self._gen_type_info(name, ifcond, + with_list=self._has_list(name)) + + def visit_alternate_type(self, + name: str, + info: Optional[QAPISourceInfo], + ifcond: QAPISchemaIfCond, + features: List[QAPISchemaFeature], + alternatives: QAPISchemaAlternatives) -> None: + self._gen_type_info(name, ifcond, + with_list=self._has_list(name)) + + +def gen_type_infos(schema: QAPISchema, + output_dir: str, + prefix: str, + opt_builtins: bool, + opt_unmask: bool) -> None: + vis = QAPISchemaGenTypeInfoVisitor(prefix, opt_unmask) + schema.visit(vis) + vis.write(output_dir, opt_builtins) -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455364.1669225 (Exim 4.92) (envelope-from ) id 1xJ7X0-0007gt-DO; Tue, 20 Oct 2026 10:57:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455364.1669225; Tue, 20 Oct 2026 10: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 1xJ7Wy-0007Z7-NK; Tue, 20 Oct 2026 10:57:20 +0000 Received: by outflank-mailman (input) for mailman id 1455364; Tue, 20 Oct 2026 10:51:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R5-0000Fe-E2 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R4-002Fd5-Mw for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:14 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74794-bab6-0a2a0a5309dd-0a2a4509e19c-42 for ; Tue, 20 Oct 2026 12:51:14 +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 6ad747a1-be1a-0a2a45090019-aa0a817c9cfb-3 for ; Tue, 20 Oct 2026 12:51:14 +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-317-_02t9xyMOm20feBYezgTrw-1; Tue, 20 Oct 2026 10:50:55 +0000 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E195F1954AF3; Tue, 20 Oct 2026 10:50:51 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 668161956089; Tue, 20 Oct 2026 10:50: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=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=1792493473; 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=xYy3oSp+ff1fXLKzAr/ltjneF4aulTjsLHGvoluUofo=; b=X6XVMan97T5ihTg48c2LqhaCkgh+pMdhNbPs4qiNVuGZooyWrOAFFN0/qnf56VddwYvV9f Q5SS6aueFM1ee0mm8zfvrmqmncOJnWzs6aeP2kyhwu9SJHz7eQNJwn5nacKCHpQOTtm9SJ IqXyFpjSR0JdM29wmvi7VhWoZKi/jZ4= X-MC-Unique: _02t9xyMOm20feBYezgTrw-1 X-Mimecast-MFC-AGG-ID: _02t9xyMOm20feBYezgTrw_1792493452 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:08 +0400 Subject: [PATCH v7 51/65] hw/pci: change the busnr type to uint8 MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-51-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=676; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=XgvIxLl/BnhUDwV4Ml62CrnmhSOe02ljvgEL6HF9kIM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZcsdAOAS0hjUnxh3WDcMl5LulHDaGVEH+/r GrDaZ1+NveJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5WzUD/4gS8E5fmzaBRANZzmTHi4LMZi0Pnr4ISijVYni9psdGZecJgyELgBiKlkS5moIjcmgfO9 LtzEDam7EKKaMjQcN5+qoT9kJDLjDpBykqFrZivQF2+tVHrtUmmPMpE3gd+qdxjg6bjuHJE9nm1 y58JRaSIUeY5pv9QUPqHyIIC2MN6AtkJNS6T4D6zslZnqceh+5SUOmjDOh3IoP69Ya4dCoo4eLh /c5wEk48USsos1BczsynxRLqlv372oV7D6FHO+gwf7Umv7Wuuk3wMq7v55VvBk9ClGMFFFHl1Bl K3IymWi5lcpeebgGoY2rJ461Nf1K2sX+de1UruF0XycFGG7zJB0fY0/QCktkFe//ULP8eWVVPxr x4po1soNOkYf6gQEeqjLamK0g8ZJygWnnbTzMGQEwO1n2GefBmYe/bslKuhzlSlv0HKmfN1M7tb byc79SREJ+GyMzX/SS2qzWi9Gn2rDYqKAs9h/RWWJ+yB/ND5yn9/LQ7juXguQ9BRcahIQMeTOiD VEEzjLcJHQbx5RCwpKZQ95j9UiN4WpHPiULZe4dPYsvpFHaoocZ8FKiKm53uryDXr8nXEA4SAUg dfhpm5tVTAMYZqUADL7oer+1PwE0J6AANyAUXX8h59mqI45I6O/T5kqAez+QPc00dcUYloWmkkC 4rA7sxiB57P9E5A== 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: 3-zo0R8hDFTe36sl23F5YEoxm1tPW3954qsxBThSEqo_1792493452 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1792493474-BF2DC034-E1FB13CE/0/0 X-purgate-type: clean X-purgate-size: 678 It is effectively a u8. The next changes are going to use the uint8_type_info for it. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/pci/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 0efb4eb4bb03..6edc702776ab 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -80,7 +80,7 @@ static void prop_pci_busnr_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_pci_busnr = { - .type = "busnr", + .type = "uint8", .get = prop_pci_busnr_get, }; -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455367.1669234 (Exim 4.92) (envelope-from ) id 1xJ7X2-00081I-Fi; Tue, 20 Oct 2026 10:57:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455367.1669234; Tue, 20 Oct 2026 10:57: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 1xJ7X0-0007u5-JD; Tue, 20 Oct 2026 10:57:22 +0000 Received: by outflank-mailman (input) for mailman id 1455367; Tue, 20 Oct 2026 10:51:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R5-0000Fg-Kx for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R5-00CroT-1m for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:15 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74799-2eae-0a2a0a5409dd-0a2a45079190-24 for ; Tue, 20 Oct 2026 12:51:15 +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 6ad74729-b4ea-0a2a45070019-aa0a817c9a81-3 for ; Tue, 20 Oct 2026 12:49:14 +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-189-NYqEQbiqO-eptIVh-iXBxg-1; Tue, 20 Oct 2026 10:49:09 +0000 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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CC9791955DC2; Tue, 20 Oct 2026 10:49:05 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id AB839418; Tue, 20 Oct 2026 10:49: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=1792493353; 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=+msWSN975JraU+AQ2pjkwTOzy6rb7VP7Sy0YWpQFyaI=; b=WMwxtfs9ibMlyq05dCMs8f/jwudkWoTlmXfl1l0NVnOfN7wSJBbxwr6/qjJUBZ/xGbw2qA v1TlWyZVW1U7XEyHrL72+xsIql93N2sNI746PaPn0mD38k9A1J2oW5u74ZUfpaX3yhDTwR cl2BZwh6BZcf+hrQfFTEwmT21bYpCEQ= X-MC-Unique: NYqEQbiqO-eptIVh-iXBxg-1 X-Mimecast-MFC-AGG-ID: NYqEQbiqO-eptIVh-iXBxg_1792493346 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:49 +0400 Subject: [PATCH v7 32/65] whpx: convert OnOffSplit property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-32-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2405; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=qwLr64BOI3m44mmy9A+SITIRRpm72tGui++1suPv5QI=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaQPXZ9WY6MhNw1DyiQHvUVteDQyhQLNYx9 5hVrQKQA32JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5WR8D/9WFCaokBX+igEl9S/wj1xhyGPSG66SFfV27Dltbb57zmq4uC5jvUX5w6dWXvYhtPNHQFe 9K66GKAgusLvRKSD+H3zGLUW8U3ETC61HN7gxl/1me7MCOgx4nP4TuXC1IGc7N04Uy5p/K7CCsv 3m46hhOQ/zOVysQ/z+FfY9DGA3PsDFV5vpg2sI4loFLN5558gsYEPjpded2r/AVynOfpuqed2bX NsNJM/utLP5uFN4rESVP7aXet5+W6chof8bssQP5vH834/eDq3PJrbZ4Ot9Q1iHx9WPiPv9Rw56 JYEYeGXqbn3zlh5nLP8rzUGp2ug5AdD4t/I9Z26eJu6bDuLCkBYk74iepLUVgX9W4DO6oiGh3et GKakHxnLhUun1C5Ol9NCVBaytv0BslRU/Fvw+cX2rIIZ0km5KyWtqiP7Fp65uNlItR2MeaUEDQ3 yloZx1kGhihimd582aexp35/fKD5T1d3yhKR0VFCwxbT9halzluTupdhjEGH+0ZFsekn9ipXO7N AuESTeKZ/orDCQk3U9Z1+5iRkWyT+M7qnMaKqFtveqCTTqKQhVQaCO+cbv92R+RjOruwYCbOgB8 /9W9WeMcY/EDXsuwsJ5c9Hn3lYMIZuQYd2A0dPWG2l+UDTv6P77b/e0AvpSGAfOx92YoEM7oybG +IQmmuEwivE+VvA== 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: SBWh1pWrw7LRl5nf9xHGTzDq87xCwN7DvyEoluPOvAY_1792493346 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1792493354-A78D1AE4-4BAE2520/0/0 X-purgate-type: clean X-purgate-size: 2407 Convert the OnOffSplit property from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- accel/whpx/whpx-common.c | 29 ++++++++++------------------- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/accel/whpx/whpx-common.c b/accel/whpx/whpx-common.c index 187938c02b51..5d4b405e56d3 100644 --- a/accel/whpx/whpx-common.c +++ b/accel/whpx/whpx-common.c @@ -434,18 +434,12 @@ error: return false; } -static void whpx_set_kernel_irqchip(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) +static void whpx_set_kernel_irqchip(Object *obj, int value, + Error **errp) { struct whpx_state *whpx = &whpx_global; - OnOffSplit mode; - if (!visit_type_OnOffSplit(v, name, &mode, errp)) { - return; - } - - switch (mode) { + switch (value) { case ON_OFF_SPLIT_ON: whpx->kernel_irqchip_allowed = true; whpx->kernel_irqchip_required = true; @@ -463,11 +457,7 @@ static void whpx_set_kernel_irqchip(Object *obj, Visitor *v, break; default: - /* - * The value was checked in visit_type_OnOffSplit() above. If - * we get here, then something is wrong in QEMU. - */ - abort(); + g_assert_not_reached(); } } @@ -518,11 +508,12 @@ static void whpx_accel_class_init(ObjectClass *oc, const void *data) ac->pre_resume_vm = whpx_pre_resume_vm; ac->allowed = &whpx_allowed; - object_class_property_add(oc, "kernel-irqchip", "on|off|split", - NULL, whpx_set_kernel_irqchip, - NULL, NULL); - object_class_property_set_description(oc, "kernel-irqchip", - "Configure WHPX in-kernel irqchip"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "kernel-irqchip", + .qapi_type = &OnOffSplit_type_info, + .set = whpx_set_kernel_irqchip, + .description = "Configure WHPX in-kernel irqchip", + )); object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( .name = "hyperv", .description = "Configure Hyper-V enlightenments", -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455370.1669241 (Exim 4.92) (envelope-from ) id 1xJ7X4-0008Rf-FE; Tue, 20 Oct 2026 10:57:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455370.1669241; Tue, 20 Oct 2026 10: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 1xJ7X2-0008J8-RN; Tue, 20 Oct 2026 10:57:24 +0000 Received: by outflank-mailman (input) for mailman id 1455370; Tue, 20 Oct 2026 10:51:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7R9-0000Hy-Dl for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7R8-00EzNE-Qi for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:18 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74794-e002-0a2a0a5209dd-0a2a4503a12e-40 for ; Tue, 20 Oct 2026 12:51:18 +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 6ad74769-fae8-0a2a45030019-aa0a857c5eb3-3 for ; Tue, 20 Oct 2026 12:50:18 +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-508-dvXahRDTM9ep7v5fxtgUQQ-1; Tue, 20 Oct 2026 10:50:13 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 250A01954B17; Tue, 20 Oct 2026 10:50:09 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D408F1800643; Tue, 20 Oct 2026 10:50: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=1792493417; 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=Itw7ntZ95b3QcknDaSfuTChM6ZY/eyyVFOmmM9NldCA=; b=Vdg31WpxgEQy/kpLYhXNNXR/SefnbmXNnmE+GH+9Se1GupJSfP1xhFeNJlhhCzJN4TbWXX 70/y0t0GZhVAoa4UeflRIl5xBEMMSPHskA4/p8wwDEC8Dn0bwvKB48wVZfxsOrg+Bqpz+G KaeU+UoVxylkTcG12m/d99N6XxMJzJc= X-MC-Unique: dvXahRDTM9ep7v5fxtgUQQ-1 X-Mimecast-MFC-AGG-ID: dvXahRDTM9ep7v5fxtgUQQ_1792493409 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:00 +0400 Subject: [PATCH v7 43/65] qom: replace object_property_add_tm with StructTm QAPI type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-43-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=10126; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=8en+VmzcHhkOLZUQUh0YjN1piPKoLpt2OiF/08xyjt4=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZbnN7eBjTOgKWdRnn37M96n/vY+BRbUyYzY fpY6OFY4GyJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5YVUD/9onwAEiHq4pCCkbty5UAKselNdSCAGMHXx5SISVLS2Kwi85In4t9/kLGEyHrqHeZQuERb /DrZ3NA7govycT07do1BCxp0bJ9Tsl1z7uJ4Kjoa862ewDpOD825V9s/3o8StmpPJoOtYthPSyK gPvECR0A34F5byFx68WIF0RiEx5+zxT3cIWaS2BQ/n9aN+iP9nslNRRyVURbpSu/HLWg9PJ2RCo 6D4EIrnn+ct6phJy5oEmDmD8fuchqDjTRI5Uf+Of+uf/KkSFwFilkUS2gt3DtjU/dI/ngzQnQjM A4togvItM9aalAiU32Ccxvck2JsYA21Y4SU9yNvXyW3wGemfbFApSEM8JyNq3pc8zPpEjN5pwf3 pD1Me0RXjz5Hm8AMvVw4bQ9NruvfmbUxftEfh04ryFlAqRLb3zqC2EYQvIa57Lu637taVwqYF38 ChZGbQKAD9tG7noF8pinzh5OCw/N0JHhIMkXcugBD6Ib31pA8zY/ByWYHO+Vgsr53dLJGgHpYPT jN6RFE1SokU1E6XU978tXDwQMOmYbzZifj1e8yyZVjvS/7ewgYLNx4oszXrh2Ez++ApJnBhsfss aQUwz1FeO06KT5e6USlZd8/B5+Yq1ppDR7geKaJQU6y6wnWs2H4dE61Y+jbOF1Ck6NK8ECMGVBo 8wUA5cr0hid+yZw== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: W1RqsZ5IQbstqeO4OCiVTZ3FkT4EZeUl_X1XN6Bie0I_1792493409 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1792493418-74C884E9-459186F1/0/0 X-purgate-type: clean X-purgate-size: 10128 Define a StructTm QAPI struct in common.json matching the existing "struct tm" property wire format (tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec as int32). Convert the two callers (mc146818rtc and spapr_rtc) to use object_property_add_qapi() with a standard ObjectPropertyAccessor that populates a StructTm and calls the generated visitor. Remove object_property_add_tm(), object_class_property_add_tm(), the TMProperty type, and the property_get_tm() helper from qom/object.c, along with their declarations in object.h. Reviewed-by: Amit Machhiwal Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/ppc/spapr_rtc.c | 24 +++++++++++++++--- hw/rtc/mc146818rtc.c | 22 ++++++++++++++--- include/qom/object.h | 29 ---------------------- qapi/common.json | 28 +++++++++++++++++++++ qapi/pragma.json | 1 + qom/object.c | 69 ---------------------------------------------------- 6 files changed, 69 insertions(+), 104 deletions(-) diff --git a/hw/ppc/spapr_rtc.c b/hw/ppc/spapr_rtc.c index 1f7d2d8f898b..5105cf538f64 100644 --- a/hw/ppc/spapr_rtc.c +++ b/hw/ppc/spapr_rtc.c @@ -33,6 +33,9 @@ #include "migration/vmstate.h" #include "qapi/error.h" #include "qapi/qapi-events-misc.h" +#include "qapi/qapi-type-infos-common.h" +#include "qapi/qapi-visit-common.h" +#include "qapi/visitor.h" #include "qemu/cutils.h" #include "qemu/module.h" @@ -131,9 +134,23 @@ static void rtas_set_time_of_day(PowerPCCPU *cpu, SpaprMachineState *spapr, rtas_st(rets, 0, RTAS_OUT_SUCCESS); } -static void spapr_rtc_qom_date(Object *obj, struct tm *current_tm, Error **errp) +static void spapr_rtc_qom_date(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) { - spapr_rtc_read(SPAPR_RTC(obj), current_tm, NULL); + struct tm value; + StructTm tm, *tmp = &tm; + + spapr_rtc_read(SPAPR_RTC(obj), &value, NULL); + + tm = (StructTm) { + .tm_year = value.tm_year, + .tm_mon = value.tm_mon, + .tm_mday = value.tm_mday, + .tm_hour = value.tm_hour, + .tm_min = value.tm_min, + .tm_sec = value.tm_sec, + }; + visit_type_StructTm(v, name, &tmp, errp); } static void spapr_rtc_realize(DeviceState *dev, Error **errp) @@ -150,7 +167,8 @@ static void spapr_rtc_realize(DeviceState *dev, Error **errp) rtc_ns = qemu_clock_get_ns(rtc_clock); rtc->ns_offset = host_s * NANOSECONDS_PER_SECOND - rtc_ns; - object_property_add_tm(OBJECT(rtc), "date", spapr_rtc_qom_date); + object_property_add_qapi(OBJECT(rtc), "date", &StructTm_type_info, + spapr_rtc_qom_date, NULL, NULL, NULL); } static const VMStateDescription vmstate_spapr_rtc = { diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c index ba396435d1af..6010f8587ce0 100644 --- a/hw/rtc/mc146818rtc.c +++ b/hw/rtc/mc146818rtc.c @@ -42,6 +42,8 @@ #include "migration/vmstate.h" #include "qapi/error.h" #include "qapi/qapi-events-misc.h" +#include "qapi/qapi-type-infos-common.h" +#include "qapi/qapi-visit-common.h" #include "qapi/visitor.h" #include "trace.h" @@ -854,12 +856,25 @@ static const MemoryRegionOps cmos_ops = { .endianness = DEVICE_LITTLE_ENDIAN, }; -static void rtc_get_date(Object *obj, struct tm *current_tm, Error **errp) +static void rtc_get_date(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) { MC146818RtcState *s = MC146818_RTC(obj); + struct tm value; + StructTm tm, *tmp = &tm; rtc_update_time(s); - rtc_get_time(s, current_tm); + rtc_get_time(s, &value); + + tm = (StructTm) { + .tm_year = value.tm_year, + .tm_mon = value.tm_mon, + .tm_mday = value.tm_mday, + .tm_hour = value.tm_hour, + .tm_min = value.tm_min, + .tm_sec = value.tm_sec, + }; + visit_type_StructTm(v, name, &tmp, errp); } static void rtc_realizefn(DeviceState *dev, Error **errp) @@ -1019,7 +1034,8 @@ static void rtc_class_initfn(ObjectClass *klass, const void *data) device_class_set_props(dc, mc146818rtc_properties); set_bit(DEVICE_CATEGORY_MISC, dc->categories); - object_class_property_add_tm(klass, "date", rtc_get_date); + object_class_property_add_qapi(klass, "date", &StructTm_type_info, + rtc_get_date, NULL, NULL, NULL); } static const TypeInfo mc146818rtc_info = { diff --git a/include/qom/object.h b/include/qom/object.h index e04be4caed57..29cbd84b8d03 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -2156,35 +2156,6 @@ object_class_property_add_qapi(ObjectClass *klass, ObjectPropertyRelease *release, void *opaque); -/** - * object_property_add_tm: - * @obj: the object to add a property to - * @name: the name of the property - * @get: the getter or NULL if the property is write-only. - * - * Add a read-only struct tm valued property using a getter function. - * This function will add a property of type 'struct tm'. - * - * Returns: The newly added property on success, or %NULL on failure. - */ -ObjectProperty *object_property_add_tm(Object *obj, const char *name, - void (*get)(Object *, struct tm *, Error **)); - -/** - * object_class_property_add_tm: - * @klass: the object class to add a property to - * @name: the name of the property - * @get: the getter or NULL if the property is write-only. - * - * Add a read-only struct tm valued property using a getter function. - * This function will add a property of type 'struct tm'. - * - * Returns: The newly added property on success, or %NULL on failure. - */ -ObjectProperty *object_class_property_add_tm(ObjectClass *klass, - const char *name, - void (*get)(Object *, struct tm *, Error **)); - typedef enum { /* Automatically add a getter to the property */ OBJ_PROP_FLAG_READ = 1 << 0, diff --git a/qapi/common.json b/qapi/common.json index 1352e664b23e..222037ea0b32 100644 --- a/qapi/common.json +++ b/qapi/common.json @@ -218,3 +218,31 @@ ## { 'enum': 'EndianMode', 'data': [ 'unspecified', 'little', 'big' ] } + +## +# @StructTm: +# +# Broken-down time. Field semantics match C ``struct tm``. +# +# @tm_year: years since 1900 +# +# @tm_mon: months since January (0-11) +# +# @tm_mday: day of the month (1-31) +# +# @tm_hour: hours since midnight (0-23) +# +# @tm_min: minutes after the hour (0-59) +# +# @tm_sec: seconds after the minute (0-59, 60-61 for leap seconds) +# +# Since: 11.2 +## +{ 'struct': 'StructTm', + 'data': { + 'tm_year': 'int32', + 'tm_mon': 'int32', + 'tm_mday': 'int32', + 'tm_hour': 'int32', + 'tm_min': 'int32', + 'tm_sec': 'int32' } } diff --git a/qapi/pragma.json b/qapi/pragma.json index 342cedc42e76..9be2819a46bd 100644 --- a/qapi/pragma.json +++ b/qapi/pragma.json @@ -109,6 +109,7 @@ 'QKeyCode', # send-key, input-sent-event 'QapiErrorClass', # QMP error replies 'SshHostKeyCheckMode', # blockdev-add, -blockdev + 'StructTm', # qom-get of RTC date property 'SysEmuTarget', # query-cpu-fast, query-target 'UuidInfo', # query-uuid 'VncClientInfo', # query-vnc, query-vnc-servers, ... diff --git a/qom/object.c b/qom/object.c index 9f9a2abfa08d..cf18880c6c0c 100644 --- a/qom/object.c +++ b/qom/object.c @@ -2721,75 +2721,6 @@ object_class_property_add_qapi(ObjectClass *klass, const char *name, return prop; } -typedef struct TMProperty { - void (*get)(Object *, struct tm *, Error **); -} TMProperty; - -static void property_get_tm(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - TMProperty *prop = opaque; - Error *err = NULL; - struct tm value; - - prop->get(obj, &value, &err); - if (err) { - error_propagate(errp, err); - return; - } - - if (!visit_start_struct(v, name, NULL, 0, errp)) { - return; - } - if (!visit_type_int32(v, "tm_year", &value.tm_year, errp)) { - goto out_end; - } - if (!visit_type_int32(v, "tm_mon", &value.tm_mon, errp)) { - goto out_end; - } - if (!visit_type_int32(v, "tm_mday", &value.tm_mday, errp)) { - goto out_end; - } - if (!visit_type_int32(v, "tm_hour", &value.tm_hour, errp)) { - goto out_end; - } - if (!visit_type_int32(v, "tm_min", &value.tm_min, errp)) { - goto out_end; - } - if (!visit_type_int32(v, "tm_sec", &value.tm_sec, errp)) { - goto out_end; - } - visit_check_struct(v, errp); -out_end: - visit_end_struct(v, NULL); -} - -ObjectProperty * -object_property_add_tm(Object *obj, const char *name, - void (*get)(Object *, struct tm *, Error **)) -{ - TMProperty *prop = g_malloc0(sizeof(*prop)); - - prop->get = get; - - return object_property_add(obj, name, "struct tm", - get ? property_get_tm : NULL, NULL, - property_release_data, - prop); -} - -ObjectProperty * -object_class_property_add_tm(ObjectClass *klass, const char *name, - void (*get)(Object *, struct tm *, Error **)) -{ - TMProperty *prop = g_malloc0(sizeof(*prop)); - - prop->get = get; - - return object_class_property_add(klass, name, "struct tm", - get ? property_get_tm : NULL, - NULL, NULL, prop); -} static char *object_get_type(Object *obj, Error **errp) { -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455372.1669248 (Exim 4.92) (envelope-from ) id 1xJ7X6-0000OR-CK; Tue, 20 Oct 2026 10:57:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455372.1669248; Tue, 20 Oct 2026 10:57: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 1xJ7X4-0000DQ-Eb; Tue, 20 Oct 2026 10:57:26 +0000 Received: by outflank-mailman (input) for mailman id 1455372; Tue, 20 Oct 2026 10:51:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RA-0000IE-Qe for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RA-00CroT-78 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:20 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479d-2eae-0a2a0a5409dd-0a2a450480cc-28 for ; Tue, 20 Oct 2026 12:51:20 +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 6ad746f2-b57f-0a2a45040019-aa0a857cab4d-3 for ; Tue, 20 Oct 2026 12:48:19 +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-90-lr-fJuH1N7yjYLe80xUfpw-1; Tue, 20 Oct 2026 10:48:12 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4EE0619560AD; Tue, 20 Oct 2026 10:48:08 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 57984418; Tue, 20 Oct 2026 10:48: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=1792493298; 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=6lRxJze+aC9KBEtw6tohukWxBkXDlU7+bxwjduyrfYI=; b=Kaj4KZgTulnr38Z/8Rj4H077L0+4B/alS0DE0BoZiJinx/3/Lqs3JIft1jtX1M/TeurSho IE5p9Y02SRurJ8596UUY5r2k2KzPtbMBZ2825+4jbthoxLttsbWpFVn/jPvZmvfZo4tTHj ArugwBtWK63g7QsV+0I2HJ3y+KnmgoM= X-MC-Unique: lr-fJuH1N7yjYLe80xUfpw-1 X-Mimecast-MFC-AGG-ID: lr-fJuH1N7yjYLe80xUfpw_1792493288 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:38 +0400 Subject: [PATCH v7 21/65] x86: convert OnOffAuto properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-21-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=6572; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=b7fcdLGC+2GPa3Wjcm0RtVCaYcyqYMRaEmGki/G6FxE=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZL3Tdedh9aQxPbswLDhqZdFL2lbqwZPM3S vvP3WGv3QuJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5ZKBEACTX7yzzr/j4WtC3RVqTKIFFKTc4t5cKUo1/m5rQXWpVE294kwdKLk1lDmvrKiKRvWP4EQ IXceFiuouMslZldIx6rvaH8qSwjZojuOdcYtS9kFgfcaJK8VG1oplTpXBTZyB+FZ5/Gs3aBsMEB t5tdVvlWE3vGgNVKnRHihfelAI1rsOCfCvhEN3PVuOpYZHZKn030ec8DuqYmBLIN4JK4NxVlOEq I4l+7RRUjTn+UQESYBdkTzD/7kKYnGyn1sh0NdEggBXI+qh4XVF67TCIe6Ki74Wu524pvWiTdln a3Zk5ywcYwrxnmqPHXrSS1L0qdbKMXK4AQgM0zIudWEbOABj6LN4FDyS8jBaTa6vmZ+6wldFjwP ORPV5b4B47gEo08l0vCoYvWt7VU6AifaMjSwi+P+U/W7XfjYPyU6XXZsoqfCb+ZS2MhN4qE70/R geuTBaQWhAXFMMHFgunyJFt2hCIcqJ0Wwerw6vSBrR6qY7x8Q+Oq5HHVjKdjCf4wdFX8VTMobJX f2lLxWx1ceEwmSbW9y3AQIIpTNSfdZx9uwaDx+qUSVHWy4bCIARc+2wjb1w2wN7BzvcSjKSi51x /DLhpKPP5A6gaSOHyxMUXd4RmFQntMM0WO6mwAlY2oD0erBahJsrhVsPBr0wSYuH41Bmo80lsiA bEw6ebgS3xjIi8A== 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: MNXtcdEy5pgq6MSlFeSPSR4DuMYQjPRMzR-gHU3RLAM_1792493288 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792493299-C0EDEB50-176E8B82/0/0 X-purgate-type: clean X-purgate-size: 6574 Convert the smm, acpi, pit, and pic OnOffAuto properties from manual visitor-based callbacks to property_add_qapi_enum(). Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/i386/x86.c | 104 +++++++++++++++++++++++++--------------------------------- 1 file changed, 45 insertions(+), 59 deletions(-) diff --git a/hw/i386/x86.c b/hw/i386/x86.c index f8ba3244e221..63f297a10532 100644 --- a/hw/i386/x86.c +++ b/hw/i386/x86.c @@ -24,7 +24,7 @@ #include "qemu/error-report.h" #include "qemu/units.h" #include "qapi/error.h" -#include "qapi/qapi-visit-common.h" +#include "qapi/qapi-type-infos-common.h" #include "qapi/qapi-visit-machine.h" #include "qapi/visitor.h" #include "system/qtest.h" @@ -188,21 +188,16 @@ bool x86_machine_is_smm_enabled(const X86MachineState *x86ms) return false; } -static void x86_machine_get_smm(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int x86_machine_get_smm(Object *obj, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - OnOffAuto smm = x86ms->smm; - - visit_type_OnOffAuto(v, name, &smm, errp); + return x86ms->smm; } -static void x86_machine_set_smm(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void x86_machine_set_smm(Object *obj, int value, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &x86ms->smm, errp); + x86ms->smm = value; } bool x86_machine_is_acpi_enabled(const X86MachineState *x86ms) @@ -213,55 +208,40 @@ bool x86_machine_is_acpi_enabled(const X86MachineState *x86ms) return true; } -static void x86_machine_get_acpi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int x86_machine_get_acpi(Object *obj, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - OnOffAuto acpi = x86ms->acpi; - - visit_type_OnOffAuto(v, name, &acpi, errp); + return x86ms->acpi; } -static void x86_machine_set_acpi(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void x86_machine_set_acpi(Object *obj, int value, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &x86ms->acpi, errp); + x86ms->acpi = value; } -static void x86_machine_get_pit(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int x86_machine_get_pit(Object *obj, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - OnOffAuto pit = x86ms->pit; - - visit_type_OnOffAuto(v, name, &pit, errp); + return x86ms->pit; } -static void x86_machine_set_pit(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void x86_machine_set_pit(Object *obj, int value, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &x86ms->pit, errp); + x86ms->pit = value; } -static void x86_machine_get_pic(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static int x86_machine_get_pic(Object *obj, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - OnOffAuto pic = x86ms->pic; - - visit_type_OnOffAuto(v, name, &pic, errp); + return x86ms->pic; } -static void x86_machine_set_pic(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +static void x86_machine_set_pic(Object *obj, int value, Error **errp) { X86MachineState *x86ms = X86_MACHINE(obj); - - visit_type_OnOffAuto(v, name, &x86ms->pic, errp); + x86ms->pic = value; } static char *x86_machine_get_oem_id(Object *obj, Error **errp) @@ -391,31 +371,37 @@ static void x86_machine_class_init(ObjectClass *oc, const void *data) mc->kvm_type = x86_kvm_type; nc->raise_nmi = x86_nmi; - object_class_property_add(oc, X86_MACHINE_SMM, "OnOffAuto", - x86_machine_get_smm, x86_machine_set_smm, - NULL, NULL); - object_class_property_set_description(oc, X86_MACHINE_SMM, - "Enable SMM"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = X86_MACHINE_SMM, + .description = "Enable SMM", + .qapi_type = &OnOffAuto_type_info, + .get = x86_machine_get_smm, + .set = x86_machine_set_smm, + )); - object_class_property_add(oc, X86_MACHINE_ACPI, "OnOffAuto", - x86_machine_get_acpi, x86_machine_set_acpi, - NULL, NULL); - object_class_property_set_description(oc, X86_MACHINE_ACPI, - "Enable ACPI"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = X86_MACHINE_ACPI, + .description = "Enable ACPI", + .qapi_type = &OnOffAuto_type_info, + .get = x86_machine_get_acpi, + .set = x86_machine_set_acpi, + )); - object_class_property_add(oc, X86_MACHINE_PIT, "OnOffAuto", - x86_machine_get_pit, - x86_machine_set_pit, - NULL, NULL); - object_class_property_set_description(oc, X86_MACHINE_PIT, - "Enable i8254 PIT"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = X86_MACHINE_PIT, + .description = "Enable i8254 PIT", + .qapi_type = &OnOffAuto_type_info, + .get = x86_machine_get_pit, + .set = x86_machine_set_pit, + )); - object_class_property_add(oc, X86_MACHINE_PIC, "OnOffAuto", - x86_machine_get_pic, - x86_machine_set_pic, - NULL, NULL); - object_class_property_set_description(oc, X86_MACHINE_PIC, - "Enable i8259 PIC"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = X86_MACHINE_PIC, + .description = "Enable i8259 PIC", + .qapi_type = &OnOffAuto_type_info, + .get = x86_machine_get_pic, + .set = x86_machine_set_pic, + )); object_class_property_add_str(oc, X86_MACHINE_OEM_ID, x86_machine_get_oem_id, -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455373.1669255 (Exim 4.92) (envelope-from ) id 1xJ7X7-0000nl-Ua; Tue, 20 Oct 2026 10:57:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455373.1669255; Tue, 20 Oct 2026 10: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 1xJ7X6-0000gG-Ds; Tue, 20 Oct 2026 10:57:28 +0000 Received: by outflank-mailman (input) for mailman id 1455373; Tue, 20 Oct 2026 10:51:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RB-0000Ih-Fh for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RA-00EzNE-SZ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:20 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747a7-e002-0a2a0a5209dd-0a2a4502edb4-6 for ; Tue, 20 Oct 2026 12:51:20 +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 6ad7472f-6ca4-0a2a45020019-aa0a817cd067-3 for ; Tue, 20 Oct 2026 12:49:20 +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-443-LCXPFJilNDyc21HBnDLkMg-1; Tue, 20 Oct 2026 10:49:15 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8E0361955BD4; Tue, 20 Oct 2026 10:49:11 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 51BBB18002B1; Tue, 20 Oct 2026 10:49: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=1792493359; 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=R8vVLHsjEWyiM3GyLmHOx9f7QvIPqbFYRpW6VNEtrF4=; b=Dq0C0yWnYVZ/Cx04ZWwngqaU/lvTR7rTCu3Y2LlZCeBipOK8drahR2e87jqbeGo0GENNNl jnf1ISCS3yTIMiKqbXKY19MtoyM0fpIiQPgQ1PlQmybTs3xV0Y6272mZ+mzCUcRODyjCJF e4jXAgviV8e6k0wITVm72TFevIy3+nw= X-MC-Unique: LCXPFJilNDyc21HBnDLkMg-1 X-Mimecast-MFC-AGG-ID: LCXPFJilNDyc21HBnDLkMg_1792493351 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:50 +0400 Subject: [PATCH v7 33/65] hw/ppc/spapr_caps: fix property type name MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-33-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=878; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=Qq7OSQxtuwlCseGf35wegvnM5f+EnUrGWd4RRhnAzxw=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZaWeTAuqQ+RlnWisH2RQ0zLCOkC+4rdcGXQ QZYeC6VHiyJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5SEMD/9w84ouUqqiCZ64ZylCbaeUJxtrtqWrrPUGFcC4JDbVpUU7Nct7HZK5iaBsDnqrZURBNr/ 8RtOPyRuf3Q4/lguHW+RKtJ6Jw6sS9784J67RNrbD/EUHDIUOt7QzUVNwflsohDZNJOI9y+5Jnm kQo6SsduyW19qi63LcidGWcAlV/Xhkp7CQCbfFhhsWCCOZImzdzQNYXU5o48Xw0oHdXg8nKkp8o CHqOboRWcyM8r62/Gw1pH4wfJ4FTNQ6cZE+4d9Vig+z5pqWha7vzQllfk7aMxXAmqkXS/vARQoM UXUUZp/aZHyRnnikACNHPNcdFMpXi+1ZumV++RqFqAMt4YSox+qwQ7UscrjDUjEIb5XAOUktB5B VPkm6qZmiK9o23zlZPnbrcOd6Cc/oVEoxtzF/5aGWNPq4xUErMRaj6oZ1O0g3E2Sp17WjDScFl+ 0lzVm3f2Q6znwnFis+4sg7ZlVUeCQv4+0yNa6+YCuJUlOi9rSfQRe9bHmQZvOvqRYdxKhXzWeUP px5zlcXZSRP9vaSQKS4s9yZuJXZyk9Fm+4Tp9UD7LAkNEdD0HnXM4AvsfFojISVCJV9Kog3R+f0 PepoSJr4XZ308R58TgTJ4NL5LlAsuYnr0Pwm+XPXvg1N8aoTb4MS7gKitj+utet5HHJ0ws1tClu dh4Iln1OvPNjzpQ== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: TmiLVO2uMf2EMiQvrSYpTqR_qs6qj7ZiyaocpYtQ5fE_1792493351 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1792493360-F1CAA2AC-2B8EB8D5/0/0 X-purgate-type: clean X-purgate-size: 880 The getter/setter use visit_type_size(). Fix the type name mismatch. Reviewed-by: Amit Machhiwal Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/ppc/spapr_caps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c index 0d659e9b0251..103b17364feb 100644 --- a/hw/ppc/spapr_caps.c +++ b/hw/ppc/spapr_caps.c @@ -784,7 +784,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_HPT_MAXPAGESIZE, .get = spapr_cap_get_pagesize, .set = spapr_cap_set_pagesize, - .type = "int", + .type = "size", .apply = cap_hpt_maxpagesize_apply, .cpu_apply = cap_hpt_maxpagesize_cpu_apply, }, -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455374.1669260 (Exim 4.92) (envelope-from ) id 1xJ7XA-0001FQ-41; Tue, 20 Oct 2026 10:57:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455374.1669260; Tue, 20 Oct 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 1xJ7X8-00014T-Bu; Tue, 20 Oct 2026 10:57:30 +0000 Received: by outflank-mailman (input) for mailman id 1455374; Tue, 20 Oct 2026 10:51:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RB-0000In-W5 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RB-00EzNE-Cz for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:21 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74794-e002-0a2a0a5209dd-0a2a4503a12e-48 for ; Tue, 20 Oct 2026 12:51:21 +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 6ad746f2-fae8-0a2a45030019-aa0a817c9a65-3 for ; Tue, 20 Oct 2026 12:48:20 +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-541-JzE2Aw8dO7qEs2TC0tJQ1g-1; Tue, 20 Oct 2026 10:48:07 +0000 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E3D2518005BC; Tue, 20 Oct 2026 10:48:02 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id BA4BE1956041; Tue, 20 Oct 2026 10:47: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=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=1792493298; 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=Vp5ZhrZ42bWj3S549eW3vIVawiZYq0pfGezhyH5wDcg=; b=ZAhA9+43RVMEslwUFrbtTOAiQaFI/f43HoqvWbJo/AZaUIwagb98xdqyiNfa5JEz951IBo b/Wj8Q+lgjtuesiAJ97OMbkF4vOBATMz5D8WIvf9QoUicDOBUNeyuuZEWQWTib1t5NxF2A naNss/8OZESzbfMjhAt4lSm2MjKeZOE= X-MC-Unique: JzE2Aw8dO7qEs2TC0tJQ1g-1 X-Mimecast-MFC-AGG-ID: JzE2Aw8dO7qEs2TC0tJQ1g_1792493283 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:37 +0400 Subject: [PATCH v7 20/65] qom: convert struct properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-20-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=12148; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=eg+SxgTFJgIB4Yau2dF+w/HtN0glmjOwr1JI4WkR+8g=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZZQGFK/ZN3udAc6CNCpipD4AhiQQoJIGozU /UDWSaFQtOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWQAKCRDa6OEJdZac 5RtTD/4kY/PNza23E86wJfF/fcJzESsEo8MEy/VqKsja5Oehs0XOVVUYFNHeM3Hoz1tn0t6gfEB gEdZ6/dJUGUJsPT0Dj0TYlXOOC8uD6Zvml9ph4IssmkkoEVdOYCBEEh67ckdRLA+NhNogviRDgz pCf2Zf7wUKqc1WkJF7sDNgP2H346XFj5MJrvHYj+nchuXlLLJoJ2p8HRttnZVit3Bdcc8EVPLeq AiHdKE812PiIqx1KWVmo/AZD0Lve7bA8x3s9o2bXTj/C5WfXxaruFK1SEfvzwTSqS+eDZQa+9fR 7myj8VpQE8yMn4VkxlzMrQIdY3RLVol5dLbJqyOXixRGS7tup1ZTrthFFukzQ+JCIscmo0IFAzV 5Si0D6bITCS6Tuut/xCbHDT8PSneeFZ0cWij9WWp5dAB/MsZaiDjGU6VMM1DQbYxVVuPSDXujjZ TWfeG0zqk2YrLWTnqGDFDYN8sWFPB7hVAyu+5Z0C6WsRhAW6yJvDeRVFo09jibHvtdFtdDs6rZl TpG4qpJJgjL9ZoJid62lKL1oqVwWecyUyjvka9DVriGfw5BrWPlNKx6/zMNe82tz/yXa4413sCM /wmN+rl/byVmDvaAb/tgK1r7TXAwbPeuTuY/7eZ/wdgx3JWRblmU8A4iQI4d152HVQpmQjZ/jgZ aNhHsQ21q2Xo4hw== 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-MFC-PROC-ID: lxppWjbBY4csTXOpecbn7V2J1uMVwv3REGMIRwz2LM8_1792493283 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1792493301-7468B4E9-1EC9E842/0/0 X-purgate-type: clean X-purgate-size: 12150 Convert all callers of object_property_add() and object_class_property_add() that register struct-typed properties with QAPI visitor-based getters/setters to use object_property_add_qapi() and object_class_property_add_qapi() instead. This replaces the manual string type name with a reference to the generated QAPITypeInfo constant, enabling QMP introspection to report accurate QAPI type information for struct properties. Existing getters/setters are preserved unchanged. The cxl-fmw property type is corrected from "CXLFixedMemoryWindow" (not a real QAPI type) to "CXLFixedMemoryWindowOptionsList", along with other mis-typed list properties. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- authz/list.c | 2 +- block/throttle-groups.c | 5 +++-- chardev/char-socket.c | 3 ++- hw/core/machine.c | 11 +++++++---- hw/cxl/cxl-host.c | 4 +++- hw/remote/vfio-user-obj.c | 5 +++-- hw/vfio-user/pci.c | 5 +++-- target/i386/cpu.c | 11 ++++++++--- target/i386/kvm/tdx.c | 4 +++- target/s390x/cpu-system.c | 4 +++- 10 files changed, 36 insertions(+), 18 deletions(-) diff --git a/authz/list.c b/authz/list.c index 363b2ee12c98..3efbe1fa1687 100644 --- a/authz/list.c +++ b/authz/list.c @@ -128,7 +128,7 @@ qauthz_list_class_init(ObjectClass *oc, const void *data) .set = qauthz_list_prop_set_policy, )); - object_class_property_add(oc, "rules", "QAuthZListRule", + object_class_property_add_qapi(oc, "rules", &QAuthZListRuleList_type_info, qauthz_list_prop_get_rules, qauthz_list_prop_set_rules, NULL, NULL); diff --git a/block/throttle-groups.c b/block/throttle-groups.c index 37814b84fe09..987867477acc 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-type-infos-block-core.h" #include "qapi/qapi-visit-block-core.h" #include "qom/object.h" #include "qom/object_interfaces.h" @@ -993,8 +994,8 @@ static void throttle_group_obj_class_init(ObjectClass *klass, } /* ThrottleLimits */ - object_class_property_add(klass, - "limits", "ThrottleLimits", + object_class_property_add_qapi(klass, + "limits", &ThrottleLimits_type_info, throttle_group_get_limits, throttle_group_set_limits, NULL, NULL); diff --git a/chardev/char-socket.c b/chardev/char-socket.c index 81bac42a1587..8e0e5d4343aa 100644 --- a/chardev/char-socket.c +++ b/chardev/char-socket.c @@ -31,6 +31,7 @@ #include "qemu/option.h" #include "qapi/error.h" #include "qapi/clone-visitor.h" +#include "qapi/qapi-type-infos-sockets.h" #include "qapi/qapi-visit-sockets.h" #include "qemu/yank.h" #include "trace.h" @@ -1568,7 +1569,7 @@ static void char_socket_class_init(ObjectClass *oc, const void *data) cc->chr_listener_cleanup = tcp_chr_listener_cleanup; cc->chr_get_filename = tcp_chr_get_filename; - object_class_property_add(oc, "addr", "SocketAddress", + object_class_property_add_qapi(oc, "addr", &SocketAddress_type_info, char_socket_get_addr, NULL, NULL, NULL); diff --git a/hw/core/machine.c b/hw/core/machine.c index d9ac4b419a36..94737e17e66f 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -18,6 +18,7 @@ #include "hw/core/loader.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-machine.h" #include "qapi/qapi-visit-machine.h" #include "qapi/qapi-commands-machine.h" #include "qemu/madvise.h" @@ -1118,19 +1119,20 @@ static void machine_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "dumpdtb", "Dump current dtb to a file and quit"); - object_class_property_add(oc, "boot", "BootConfiguration", + object_class_property_add_qapi(oc, "boot", &BootConfiguration_type_info, machine_get_boot, machine_set_boot, NULL, NULL); object_class_property_set_description(oc, "boot", "Boot configuration"); - object_class_property_add(oc, "smp", "SMPConfiguration", + object_class_property_add_qapi(oc, "smp", &SMPConfiguration_type_info, machine_get_smp, machine_set_smp, NULL, NULL); object_class_property_set_description(oc, "smp", "CPU topology"); - object_class_property_add(oc, "smp-cache", "SmpCachePropertiesWrapper", + object_class_property_add_qapi(oc, "smp-cache", + &SmpCachePropertiesWrapper_type_info, machine_get_smp_cache, machine_set_smp_cache, NULL, NULL); object_class_property_set_description(oc, "smp-cache", "Cache properties list for SMP machine"); @@ -1212,7 +1214,8 @@ static void machine_class_init(ObjectClass *oc, const void *data) "Set RAM backend" "Valid value is ID of hostmem based backend"); - object_class_property_add(oc, "memory", "MemorySizeConfiguration", + object_class_property_add_qapi(oc, "memory", + &MemorySizeConfiguration_type_info, machine_get_mem, machine_set_mem, NULL, NULL); object_class_property_set_description(oc, "memory", diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c index e279ce5fe3ae..8997bf1785c8 100644 --- a/hw/cxl/cxl-host.c +++ b/hw/cxl/cxl-host.c @@ -13,6 +13,7 @@ #include "system/qtest.h" #include "hw/core/boards.h" +#include "qapi/qapi-type-infos-machine.h" #include "qapi/qapi-visit-machine.h" #include "hw/cxl/cxl.h" #include "hw/cxl/cxl_host.h" @@ -616,7 +617,8 @@ void cxl_machine_init(Object *obj, CXLState *state) "Set on/off to enable/disable " "CXL instantiation"); - object_property_add(obj, "cxl-fmw", "CXLFixedMemoryWindow", + object_property_add_qapi(obj, "cxl-fmw", + &CXLFixedMemoryWindowOptionsList_type_info, machine_get_cfmw, machine_set_cfmw, NULL, state); object_property_set_description(obj, "cxl-fmw", diff --git a/hw/remote/vfio-user-obj.c b/hw/remote/vfio-user-obj.c index a0498d218faf..7e6819f670b5 100644 --- a/hw/remote/vfio-user-obj.c +++ b/hw/remote/vfio-user-obj.c @@ -47,6 +47,7 @@ #include "hw/core/boards.h" #include "hw/remote/machine.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-sockets.h" #include "qapi/qapi-visit-sockets.h" #include "qapi/qapi-events-misc.h" #include "qemu/notify.h" @@ -931,8 +932,8 @@ static void vfu_object_class_init(ObjectClass *klass, const void *data) k->nr_devs = 0; - object_class_property_add(klass, "socket", "SocketAddress", NULL, - vfu_object_set_socket, NULL, NULL); + object_class_property_add_qapi(klass, "socket", &SocketAddress_type_info, + NULL, vfu_object_set_socket, NULL, NULL); object_class_property_set_description(klass, "socket", "SocketAddress " "(ex: type=unix,path=/tmp/sock). " diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c index 983e1d4ad470..f58c4a0f3965 100644 --- a/hw/vfio-user/pci.c +++ b/hw/vfio-user/pci.c @@ -8,6 +8,7 @@ #include "qemu/osdep.h" #include +#include "qapi/qapi-type-infos-sockets.h" #include "qapi-visit-sockets.h" #include "qemu/error-report.h" @@ -471,8 +472,8 @@ static void vfio_user_pci_class_init(ObjectClass *klass, const void *data) device_class_set_legacy_reset(dc, vfio_user_pci_reset); device_class_set_props(dc, vfio_user_pci_properties); - object_class_property_add(klass, "socket", "SocketAddress", NULL, - vfio_user_pci_set_socket, NULL, NULL); + object_class_property_add_qapi(klass, "socket", &SocketAddress_type_info, + NULL, vfio_user_pci_set_socket, NULL, NULL); object_class_property_set_description(klass, "socket", "SocketAddress (UNIX sockets only)"); diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 5da80ade70eb..4553ef0892a1 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -35,6 +35,8 @@ #include "sev.h" #include "qapi/error.h" #include "qemu/error-report.h" +#include "qapi/qapi-type-infos-machine.h" +#include "qapi/qapi-type-infos-run-state.h" #include "qapi/qapi-visit-machine.h" #include "standard-headers/asm-x86/kvm_para.h" #include "hw/core/qdev-properties.h" @@ -10540,10 +10542,12 @@ static void x86_cpu_initfn(Object *obj) x86_cpu_init_default_topo(cpu); - object_property_add(obj, "feature-words", "X86CPUFeatureWordInfo", + object_property_add_qapi(obj, "feature-words", + &X86CPUFeatureWordInfoList_type_info, x86_cpu_get_feature_words, NULL, NULL, (void *)env->features); - object_property_add(obj, "filtered-features", "X86CPUFeatureWordInfo", + object_property_add_qapi(obj, "filtered-features", + &X86CPUFeatureWordInfo_type_info, x86_cpu_get_feature_words, NULL, NULL, (void *)cpu->filtered_features); @@ -11007,7 +11011,8 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) NULL, NULL); #if !defined(CONFIG_USER_ONLY) - object_class_property_add(oc, "crash-information", "GuestPanicInformation", + object_class_property_add_qapi(oc, "crash-information", + &GuestPanicInformation_type_info, x86_cpu_get_crash_info_qom, NULL, NULL, NULL); #endif diff --git a/target/i386/kvm/tdx.c b/target/i386/kvm/tdx.c index 8294dbde3aa8..81c5ba3a1b54 100644 --- a/target/i386/kvm/tdx.c +++ b/target/i386/kvm/tdx.c @@ -14,6 +14,7 @@ #include "qemu/base64.h" #include "qemu/mmap-alloc.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-sockets.h" #include "qapi/qapi-visit-sockets.h" #include "qom/object_interfaces.h" #include "crypto/hash.h" @@ -1586,7 +1587,8 @@ static void tdx_guest_init(Object *obj) tdx_guest_get_mrownerconfig, tdx_guest_set_mrownerconfig); - object_property_add(obj, "quote-generation-socket", "SocketAddress", + object_property_add_qapi(obj, "quote-generation-socket", + &SocketAddress_type_info, tdx_guest_get_qgs, tdx_guest_set_qgs, NULL, NULL); diff --git a/target/s390x/cpu-system.c b/target/s390x/cpu-system.c index d963d9e940e1..30992ef654f4 100644 --- a/target/s390x/cpu-system.c +++ b/target/s390x/cpu-system.c @@ -30,6 +30,7 @@ #include "system/reset.h" #include "qemu/timer.h" #include "trace.h" +#include "qapi/qapi-type-infos-run-state.h" #include "qapi/qapi-visit-run-state.h" #include "system/hw_accel.h" @@ -137,7 +138,8 @@ void s390_cpu_system_init(Object *obj) S390CPU *cpu = S390_CPU(obj); cs->start_powered_off = true; - object_property_add(obj, "crash-information", "GuestPanicInformation", + object_property_add_qapi(obj, "crash-information", + &GuestPanicInformation_type_info, s390_cpu_get_crash_info_qom, NULL, NULL, NULL); cpu->env.tod_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, s390x_tod_timer, cpu); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455375.1669272 (Exim 4.92) (envelope-from ) id 1xJ7XC-0001sT-Rh; Tue, 20 Oct 2026 10:57:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455375.1669272; Tue, 20 Oct 2026 10: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 1xJ7XA-0001hE-Va; Tue, 20 Oct 2026 10:57:32 +0000 Received: by outflank-mailman (input) for mailman id 1455375; Tue, 20 Oct 2026 10:51:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RD-0000JG-CX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RC-004dBJ-Pa for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:22 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747a7-8faa-0a2a0a5109dd-0a2a4508b6ba-10 for ; Tue, 20 Oct 2026 12:51:22 +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 6ad747a9-f659-0a2a45080019-aa0a817cdb43-3 for ; Tue, 20 Oct 2026 12:51:22 +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-571-wpfby2pGOJyKwLe7dRoy5g-1; Tue, 20 Oct 2026 10:51:16 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 59F701956058; Tue, 20 Oct 2026 10:51:12 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6E20D1956088; Tue, 20 Oct 2026 10:51:09 +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=1792493481; 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=kVlgXy2vPG5I3mKp16fhq+bJb3obYLJd/3IFPjDdE9g=; b=R/ar126Pn4RLNJDh7XB+2g8touJ5NII/vb6HQut+LtJRJ/dIifJFHN5UnAnYRbMai3kFuo UdQyo/HmrmfrsD9q9fNNePfjfObK3+ADLALpIwGY1xYzOXCHHHy+CLTa3fJEuc1U7KiRhw XRPOZd1ZB6gKsReh+rTJH8WdS5HqjA0= X-MC-Unique: wpfby2pGOJyKwLe7dRoy5g-1 X-Mimecast-MFC-AGG-ID: wpfby2pGOJyKwLe7dRoy5g_1792493472 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:12 +0400 Subject: [PATCH v7 55/65] qdev: convert system PropertyInfo definitions to use qapi_type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-55-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=16488; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=bKJiGjLc93NMNQe/axyuBXbCYEzkRfYsjB6tY47k/ME=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZcE6NcoIi2kkZhgPlwo4cwnMvIG9Khmkeki 3B164oT25KJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5X4UD/oDIy4uzsDDKJ07Mwj4Le45Vv+5f8w9BOVeka0VijEf6x5pFmvuYTSqEfaovLHlXgeSaEI zRulvXe5KuGodBABZfg89LkkU5r2EBsPvVQVTz36tFtr/RA9tZ5OtkaUG4KoKgg1D84YjYZBKYC Dk7TuM+jRsDKwGYy9VsZ8RbLtkeZYVkKQ47Ekt/kYAgAbfRS6HL0GjcKqnMhKmZy4bFDxIEZtzd 0Zxv6JkIMu/i85FepDnytt2YCwhT6mvnL2ScEExHqyED7UcBzuU9VNMIEQSEAubvjd+MjJTK3RI 5q04XcpN4cpum2fvygKb8Trpj87BED6uoFvqmN48XHYwvPraPB3A8R9QYjPirdeq2e7K8SiblBq vliHBphsgAVgdcD1TuoFYOjqePJRz6v/Y/2M5pEg4m/MUBMWxvgP+O1qKuanj4WpOpXOG6xMlj9 pPUbKIIOtP6V1WUU7l5JRxfNPSGI4nhqjUO6LuQAwQWZE1zl+QKxMNgfWZledVaSyNLWWxAwHnO PHlyxs6OELk7p+QbfVeRnCQExc9dguQA8maKFafKmWIv91WwQ5KyX7D0OKHowXAosPoJ38fqbha 5UVZ5QSnmbDWHl/Qu80RjzcHcFsVx39BDAbueT4Ue3krKr40/8NsJQcY3lboVJN0DEmse+TPH0o 9Mdq/H0L6fXU0Cg== 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: q0X-a5wx3T2LJMP0VZSIwKujFwCSwBfXZV6xmhzfBhU_1792493472 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792493482-CDF4787B-B4E6DA02/0/0 X-purgate-type: clean X-purgate-size: 16490 Replace .type string and .enum_table pointer with .qapi_type in all PropertyInfo definitions in qdev-properties-system.c Update file-private enum accessor functions to use .qapi_type->lookup instead of .enum_table. Note, this should be a faithful conversion, but it would be worth to consider better types than just "str" for references (block node names, chardev/netdev IDs, MAC addrs, etc) Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/qdev-prop-internal.h | 2 + hw/core/qdev-properties-system.c | 93 +++++++++++++++++----------------------- hw/core/qdev-properties.c | 2 +- 3 files changed, 43 insertions(+), 54 deletions(-) diff --git a/hw/core/qdev-prop-internal.h b/hw/core/qdev-prop-internal.h index d7b77844fe0b..c190b7b88cf4 100644 --- a/hw/core/qdev-prop-internal.h +++ b/hw/core/qdev-prop-internal.h @@ -8,6 +8,8 @@ #ifndef HW_CORE_QDEV_PROP_INTERNAL_H #define HW_CORE_QDEV_PROP_INTERNAL_H +const QEnumLookup *qdev_propinfo_enum_lookup(const PropertyInfo *info); + void qdev_propinfo_get_enum(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp); void qdev_propinfo_set_enum(Object *obj, Visitor *v, const char *name, diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c index 3381de1144d6..8819a9a0b748 100644 --- a/hw/core/qdev-properties-system.c +++ b/hw/core/qdev-properties-system.c @@ -27,6 +27,7 @@ #include "qemu/uuid.h" #include "qemu/error-report.h" #include "qdev-prop-internal.h" +#include "qapi/qapi-type-infos.h" #include "qemu/audio.h" #include "chardev/char-fe.h" @@ -238,7 +239,7 @@ static void release_drive(Object *obj, const char *name, void *opaque) } const PropertyInfo qdev_prop_drive = { - .type = "str", + .qapi_type = &str_type_info, .description = "Node name or ID of a block device to use as a backend", .realized_set_allowed = true, .get = get_drive, @@ -247,7 +248,7 @@ const PropertyInfo qdev_prop_drive = { }; const PropertyInfo qdev_prop_drive_iothread = { - .type = "str", + .qapi_type = &str_type_info, .description = "Node name or ID of a block device to use as a backend", .realized_set_allowed = true, .get = get_drive, @@ -315,7 +316,7 @@ static void release_chr(Object *obj, const char *name, void *opaque) } const PropertyInfo qdev_prop_chr = { - .type = "str", + .qapi_type = &str_type_info, .description = "ID of a chardev to use as a backend", .get = get_chr, .set = set_chr, @@ -389,7 +390,7 @@ inval: } const PropertyInfo qdev_prop_macaddr = { - .type = "str", + .qapi_type = &str_type_info, .description = "Ethernet 6-byte MAC Address, example: 52:54:00:12:34:56", .get = get_mac, .set = set_mac, @@ -477,7 +478,7 @@ out: } const PropertyInfo qdev_prop_netdev = { - .type = "str", + .qapi_type = &str_type_info, .description = "ID of a netdev to use as a backend", .get = get_netdev, .set = set_netdev, @@ -514,7 +515,7 @@ static void set_audiodev(Object *obj, Visitor *v, const char* name, } const PropertyInfo qdev_prop_audiodev = { - .type = "str", + .qapi_type = &str_type_info, .description = "ID of an audiodev to use as a backend", /* release done on shutdown */ .get = get_audiodev, @@ -584,7 +585,8 @@ static void qdev_propinfo_set_losttickpolicy(Object *obj, Visitor *v, int *ptr = object_field_prop_ptr(obj, prop); int value; - if (!visit_type_enum(v, name, &value, prop->info->enum_table, errp)) { + if (!visit_type_enum(v, name, &value, + qdev_propinfo_enum_lookup(prop->info), errp)) { return; } @@ -604,9 +606,8 @@ static void qdev_propinfo_set_losttickpolicy(Object *obj, Visitor *v, QEMU_BUILD_BUG_ON(sizeof(LostTickPolicy) != sizeof(int)); const PropertyInfo qdev_prop_losttickpolicy = { - .type = "LostTickPolicy", + .qapi_type = &LostTickPolicy_type_info, .description = "Policy for handling lost ticks (discard/delay/slew)", - .enum_table = &LostTickPolicy_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_losttickpolicy, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -631,7 +632,7 @@ static void set_blocksize(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_blocksize = { - .type = "size", + .qapi_type = &size_type_info, .description = "A power of two between " MIN_BLOCK_SIZE_STR " and " MAX_BLOCK_SIZE_STR, .get = qdev_propinfo_get_size32, @@ -644,9 +645,8 @@ const PropertyInfo qdev_prop_blocksize = { QEMU_BUILD_BUG_ON(sizeof(BlockdevOnError) != sizeof(int)); const PropertyInfo qdev_prop_blockdev_on_error = { - .type = "BlockdevOnError", + .qapi_type = &BlockdevOnError_type_info, .description = "Error handling policy (report/ignore/enospc/stop/auto)", - .enum_table = &BlockdevOnError_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -657,10 +657,9 @@ const PropertyInfo qdev_prop_blockdev_on_error = { QEMU_BUILD_BUG_ON(sizeof(BiosAtaTranslation) != sizeof(int)); const PropertyInfo qdev_prop_bios_chs_trans = { - .type = "BiosAtaTranslation", + .qapi_type = &BiosAtaTranslation_type_info, .description = "Logical CHS translation algorithm " " (auto/none/lba/large/rechs)", - .enum_table = &BiosAtaTranslation_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -669,9 +668,8 @@ const PropertyInfo qdev_prop_bios_chs_trans = { /* --- FDC default drive types */ const PropertyInfo qdev_prop_fdc_drive_type = { - .type = "FloppyDriveType", + .qapi_type = &FloppyDriveType_type_info, .description = "Floppy drive type (144/288/120/none/auto)", - .enum_table = &FloppyDriveType_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -680,10 +678,9 @@ const PropertyInfo qdev_prop_fdc_drive_type = { /* --- MultiFDCompression --- */ const PropertyInfo qdev_prop_multifd_compression = { - .type = "MultiFDCompression", + .qapi_type = &MultiFDCompression_type_info, .description = "multifd compression method" " (none/zlib/zstd/qpl/uadk/qatzip)", - .enum_table = &MultiFDCompression_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -694,9 +691,8 @@ const PropertyInfo qdev_prop_multifd_compression = { QEMU_BUILD_BUG_ON(sizeof(MigMode) != sizeof(int)); const PropertyInfo qdev_prop_mig_mode = { - .type = "MigMode", + .qapi_type = &MigMode_type_info, .description = "Migration mode (normal/cpr-reboot)", - .enum_table = &MigMode_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -707,18 +703,16 @@ const PropertyInfo qdev_prop_mig_mode = { QEMU_BUILD_BUG_ON(sizeof(GranuleMode) != sizeof(int)); const PropertyInfo qdev_prop_granule_mode = { - .type = "GranuleMode", + .qapi_type = &GranuleMode_type_info, .description = "Granule page size (4k/8k/16k/64k/host)", - .enum_table = &GranuleMode_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, }; const PropertyInfo qdev_prop_zero_page_detection = { - .type = "ZeroPageDetection", + .qapi_type = &ZeroPageDetection_type_info, .description = "Zero page detection (none/legacy/multifd)", - .enum_table = &ZeroPageDetection_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -729,9 +723,8 @@ const PropertyInfo qdev_prop_zero_page_detection = { QEMU_BUILD_BUG_ON(sizeof(SsidSizeMode) != sizeof(int)); const PropertyInfo qdev_prop_ssidsize_mode = { - .type = "SsidSizeMode", + .qapi_type = &SsidSizeMode_type_info, .description = "ssidsize mode: auto, 0-20", - .enum_table = &SsidSizeMode_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -742,9 +735,8 @@ const PropertyInfo qdev_prop_ssidsize_mode = { QEMU_BUILD_BUG_ON(sizeof(OasMode) != sizeof(int)); const PropertyInfo qdev_prop_oas_mode = { - .type = "OasMode", + .qapi_type = &OasMode_type_info, .description = "oas mode: auto, 32, 36, 40, 42, 44, 48, 52, 56", - .enum_table = &OasMode_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -824,7 +816,7 @@ out: } const PropertyInfo qdev_prop_reserved_region = { - .type = "str", + .qapi_type = &str_type_info, .description = "Reserved Region, example: 0xFEE00000:0xFEEFFFFF:0", .get = get_reserved_region, .set = set_reserved_region, @@ -904,8 +896,7 @@ static char *print_pci_devfn(Object *obj, const Property *prop) } const PropertyInfo qdev_prop_pci_devfn = { - /* The formatted string accepted by the setter is a CLI convenience. */ - .type = "int32", + .qapi_type = &int32_type_info, .description = "Slot and optional function number, example: 06.0 or 06", .print = print_pci_devfn, .get = qdev_propinfo_get_int32, @@ -1011,7 +1002,7 @@ inval: } const PropertyInfo qdev_prop_pci_host_devaddr = { - .type = "str", + .qapi_type = &str_type_info, .description = "Address (bus:device.function) of " "the host device, example: 04:10.0", .get = get_pci_host_devaddr, @@ -1021,9 +1012,8 @@ const PropertyInfo qdev_prop_pci_host_devaddr = { /* --- OffAutoPCIBAR off/auto/bar0/bar1/bar2/bar3/bar4/bar5 --- */ const PropertyInfo qdev_prop_off_auto_pcibar = { - .type = "OffAutoPCIBAR", + .qapi_type = &OffAutoPCIBAR_type_info, .description = "off/auto/bar0/bar1/bar2/bar3/bar4/bar5", - .enum_table = &OffAutoPCIBAR_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -1062,7 +1052,8 @@ static void get_prop_pcielinkspeed(Object *obj, Visitor *v, const char *name, abort(); } - visit_type_enum(v, name, &speed, prop->info->enum_table, errp); + visit_type_enum(v, name, &speed, + qdev_propinfo_enum_lookup(prop->info), errp); } static void set_prop_pcielinkspeed(Object *obj, Visitor *v, const char *name, @@ -1072,8 +1063,8 @@ static void set_prop_pcielinkspeed(Object *obj, Visitor *v, const char *name, PCIExpLinkSpeed *p = object_field_prop_ptr(obj, prop); int speed; - if (!visit_type_enum(v, name, &speed, prop->info->enum_table, - errp)) { + if (!visit_type_enum(v, name, &speed, + qdev_propinfo_enum_lookup(prop->info), errp)) { return; } @@ -1103,9 +1094,8 @@ static void set_prop_pcielinkspeed(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_pcie_link_speed = { - .type = "PCIELinkSpeed", + .qapi_type = &PCIELinkSpeed_type_info, .description = "2_5/5/8/16/32/64", - .enum_table = &PCIELinkSpeed_lookup, .get = get_prop_pcielinkspeed, .set = set_prop_pcielinkspeed, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -1147,7 +1137,8 @@ static void get_prop_pcielinkwidth(Object *obj, Visitor *v, const char *name, abort(); } - visit_type_enum(v, name, &width, prop->info->enum_table, errp); + visit_type_enum(v, name, &width, + qdev_propinfo_enum_lookup(prop->info), errp); } static void set_prop_pcielinkwidth(Object *obj, Visitor *v, const char *name, @@ -1157,8 +1148,8 @@ static void set_prop_pcielinkwidth(Object *obj, Visitor *v, const char *name, PCIExpLinkWidth *p = object_field_prop_ptr(obj, prop); int width; - if (!visit_type_enum(v, name, &width, prop->info->enum_table, - errp)) { + if (!visit_type_enum(v, name, &width, + qdev_propinfo_enum_lookup(prop->info), errp)) { return; } @@ -1191,9 +1182,8 @@ static void set_prop_pcielinkwidth(Object *obj, Visitor *v, const char *name, } const PropertyInfo qdev_prop_pcie_link_width = { - .type = "PCIELinkWidth", + .qapi_type = &PCIELinkWidth_type_info, .description = "1/2/4/8/12/16/32", - .enum_table = &PCIELinkWidth_lookup, .get = get_prop_pcielinkwidth, .set = set_prop_pcielinkwidth, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -1241,7 +1231,7 @@ static void set_default_uuid_auto(ObjectProperty *op, const Property *prop) } const PropertyInfo qdev_prop_uuid = { - .type = "str", + .qapi_type = &str_type_info, .description = "UUID (aka GUID) or \"" UUID_VALUE_AUTO "\" for random value (default)", .get = get_uuid, @@ -1254,9 +1244,8 @@ const PropertyInfo qdev_prop_uuid = { QEMU_BUILD_BUG_ON(sizeof(S390CpuEntitlement) != sizeof(int)); const PropertyInfo qdev_prop_cpus390entitlement = { - .type = "S390CpuEntitlement", + .qapi_type = &S390CpuEntitlement_type_info, .description = "auto/low/medium/high (default medium)", - .enum_table = &S390CpuEntitlement_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -1299,7 +1288,7 @@ static void release_iothread_vq_mapping_list(Object *obj, } const PropertyInfo qdev_prop_iothread_vq_mapping_list = { - .type = "IOThreadVirtQueueMappingList", + .qapi_type = &IOThreadVirtQueueMappingList_type_info, .description = "IOThread virtqueue mapping list [{\"iothread\":\"\", " "\"vqs\":[1,2,3,...]},...]", .get = get_iothread_vq_mapping_list, @@ -1310,18 +1299,16 @@ const PropertyInfo qdev_prop_iothread_vq_mapping_list = { /* --- Endian modes */ const PropertyInfo qdev_prop_endian_mode = { - .type = "EndianMode", + .qapi_type = &EndianMode_type_info, .description = "Endian mode, big/little/unspecified", - .enum_table = &EndianMode_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, }; const PropertyInfo qdev_prop_vmapple_virtio_blk_variant = { - .type = "VMAppleVirtioBlkVariant", + .qapi_type = &VMAppleVirtioBlkVariant_type_info, .description = "unspecified/root/aux", - .enum_table = &VMAppleVirtioBlkVariant_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, @@ -1364,7 +1351,7 @@ static void release_virtio_gpu_output_list(Object *obj, } const PropertyInfo qdev_prop_virtio_gpu_output_list = { - .type = "VirtIOGPUOutputList", + .qapi_type = &VirtIOGPUOutputList_type_info, .description = "VirtIO GPU output list [{\"name\":\"\"},...]", .get = get_virtio_gpu_output_list, .set = set_virtio_gpu_output_list, diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c index abdb380cb9ec..a9abc646d5d7 100644 --- a/hw/core/qdev-properties.c +++ b/hw/core/qdev-properties.c @@ -101,7 +101,7 @@ static ObjectPropertyAccessor *field_prop_setter(const PropertyInfo *info) return info->set ? field_prop_set : NULL; } -static const QEnumLookup *qdev_propinfo_enum_lookup(const PropertyInfo *info) +const QEnumLookup *qdev_propinfo_enum_lookup(const PropertyInfo *info) { if (info->qapi_type) { assert(info->qapi_type->lookup); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455379.1669279 (Exim 4.92) (envelope-from ) id 1xJ7XF-0002MG-4b; Tue, 20 Oct 2026 10:57:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455379.1669279; Tue, 20 Oct 2026 10: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 1xJ7XD-0002CM-5B; Tue, 20 Oct 2026 10:57:35 +0000 Received: by outflank-mailman (input) for mailman id 1455379; Tue, 20 Oct 2026 10:51:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RF-0000KV-QX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RF-00EzNE-7J for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:25 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747aa-e002-0a2a0a5209dd-0a2a4507c7bc-8 for ; Tue, 20 Oct 2026 12:51:25 +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 6ad7476f-b4ea-0a2a45070019-aa0a817c6c25-3 for ; Tue, 20 Oct 2026 12:50:24 +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-461-0yk3KpK5MBKZ9_x5V_hyRg-1; Tue, 20 Oct 2026 10:50:18 +0000 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 78F3E1954102; Tue, 20 Oct 2026 10:50:14 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8AABE1956095; Tue, 20 Oct 2026 10:50: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=1792493423; 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=5CC43HGq5NqmO9GuRv3YOCIPDVNxOH0lYT23DJe+EOs=; b=jVrjmmFAv6bndAcCTKwV+tRjMBEqYZEgoWH6mBmsh11DQjcTXoUTQB3UDNiDTpxSNKcpus +MeRZMNPCr9nHfh1yDccQLuQnW30C/JV9bFzKqymxN+nC7jmn+vZEDMKDfRsU9p0Wd65f5 cG00oZP2AU+nxXhkH8wcKz6QCbdsfJ8= X-MC-Unique: 0yk3KpK5MBKZ9_x5V_hyRg-1 X-Mimecast-MFC-AGG-ID: 0yk3KpK5MBKZ9_x5V_hyRg_1792493414 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:01 +0400 Subject: [PATCH v7 44/65] hw/nvdimm: convert UUID property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-44-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=2398; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=JcrXJbY3n1i8Aie2efrfuUCSPF/58nBE1VKv/oA1cHQ=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Zb3uRNyW/Ops8TO0GvUmz+pY4b6iH48X9V4 dT8KSx5JbWJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5eITD/46vxBPKKy5DKVq41RW+PpNl8DJi94l5Ic/FKfo92YajuNHmy1WErhgftc0rpWEf92vWp2 /kk3U5z38JmBDTtBklsCNKY8V6UA1XuWHNxhMtpJz2/4uluVz/cPDYqtyc5XAf9WWJkCw/hKmmS GadWFMgjwRsGaAuWAT8IbDB82XGWkgzxZBqh76fEVznt+V5gX1shJ/a/u7KUcuHEJIPgCWlTFJL QBCIrSrvGW7MWZ0xI6AR+EAtJ5oG9xc74eILqmJoNMDhp/m+1JEEOl25Mbb1EyX6EfB8kpzqdSH KM5tKqVXHz/gpPWacm9DzXGSH+nsG/v0CDnsS4ywByxghoIzo5/Ky0uP3XENBVy1UT+Uf8hu9t5 CD+bEOs7ExRxdT41kAbWSQ1vB42SwN1uJkXot5RNttTmmYv0IAoxkSuNpwJa+Cs1fdhKaoPZfil VUqLPeJmD5Q6WahLYyg8bC0pz2HjinNVlT0LFkveiW9+hmae361bD7hOPLGVvxO7cDzDUOLn1Xm E/kEb3lwBP8u23KM6nwMg79RA4QttKHK8lFNs00JdB3dg5vTZuLt8HetlALcd+9l8UGL2rTRW1P hEksQQ1rUSoEHWaxQZgtclQUsPD8AksY8ygzbhXCo6fmu78aH5/mTWRUeItn2w9Ul5sPsE2sTFj 9RH9c/P0NdV/h2w== 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-MFC-PROC-ID: oal_qqmoozeINSO2tGrHRNiOvRE5tK5fmy6ZFWMVswQ_1792493414 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1792493425-A5CC7AE4-EE8F1828/0/0 X-purgate-type: clean X-purgate-size: 2400 Add a QemuUUID_type_info and use object_property_add_qapi() instead of object_property_add() for the nvdimm UUID property. The type info is defined manually in uuid.c rather than generated, since QAPI does not yet support string typedefs. An alternative would be to extend the QAPI schema language with a 'typedef' construct (e.g. { 'typedef': 'UUID', 'data': 'str' }), which would let the generator produce the type info, C typedef, and introspection entry automatically. Alternatively, the exposed type being a string, we could change the property to be str_type_info. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/mem/nvdimm.c | 4 ++-- include/qemu/uuid.h | 4 ++++ util/uuid.c | 5 +++++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c index 123ddc938546..b7ccb5c93678 100644 --- a/hw/mem/nvdimm.c +++ b/hw/mem/nvdimm.c @@ -104,8 +104,8 @@ static void nvdimm_init(Object *obj) 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); + object_property_add_qapi(obj, NVDIMM_UUID_PROP, &QemuUUID_type_info, + nvdimm_get_uuid, nvdimm_set_uuid, NULL, NULL); } static void nvdimm_finalize(Object *obj) diff --git a/include/qemu/uuid.h b/include/qemu/uuid.h index 869f84af09dd..ed0c62327d4d 100644 --- a/include/qemu/uuid.h +++ b/include/qemu/uuid.h @@ -16,6 +16,8 @@ #ifndef QEMU_UUID_H #define QEMU_UUID_H +#include "qapi/qapi-type-info.h" + /* Version 4 UUID (pseudo random numbers), RFC4122 4.4. */ @@ -99,4 +101,6 @@ QemuUUID qemu_uuid_bswap(QemuUUID uuid); uint32_t qemu_uuid_hash(const void *uuid); +extern const QAPITypeInfo QemuUUID_type_info; + #endif diff --git a/util/uuid.c b/util/uuid.c index 234619dd5e69..363a03051aba 100644 --- a/util/uuid.c +++ b/util/uuid.c @@ -17,6 +17,11 @@ #include "qemu/uuid.h" #include "qemu/bswap.h" +const QAPITypeInfo QemuUUID_type_info = { + .name = "QemuUUID", + .masked_name = "str", +}; + void qemu_uuid_generate(QemuUUID *uuid) { int i; -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455381.1669292 (Exim 4.92) (envelope-from ) id 1xJ7XH-0002o5-Mw; Tue, 20 Oct 2026 10:57:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455381.1669292; Tue, 20 Oct 2026 10:57: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 1xJ7XF-0002ca-GA; Tue, 20 Oct 2026 10:57:37 +0000 Received: by outflank-mailman (input) for mailman id 1455381; Tue, 20 Oct 2026 10:51:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RH-0000Kp-6r for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RG-004dEx-K0 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479c-8faa-0a2a0a5109dd-0a2a450bb700-46 for ; Tue, 20 Oct 2026 12:51:26 +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 6ad747ad-b7e8-0a2a450b0019-aa0a857c5e61-3 for ; Tue, 20 Oct 2026 12:51:26 +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-640-LD3Q4rjXMEKqjPFqN7WD9w-1; Tue, 20 Oct 2026 10:51:21 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2D8291955BD4; Tue, 20 Oct 2026 10:51:17 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id ABCAE1956089; Tue, 20 Oct 2026 10:51: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=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=1792493485; 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=1eBYCbo62pybnrvd2zJR+X4E8rHf2MlZgP3d6Su31eo=; b=B5BTHB2zdGsiYb36C/7V5s1tj6j776NLHQIAysWTvKqVwxHdmR2nE2rq/6jrMaFjqTtR0I hePnLysUxSFu7/Mh0lIzoylI8cAef7lYjHk/EvxAY9Cfp339NA2fWb0vp7zougiOAdJ8RB nGCrXqNa6ENmH2AYVYgTeXQ1DOCKEHo= X-MC-Unique: LD3Q4rjXMEKqjPFqN7WD9w-1 X-Mimecast-MFC-AGG-ID: LD3Q4rjXMEKqjPFqN7WD9w_1792493477 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:13 +0400 Subject: [PATCH v7 56/65] hw: convert device-local PropertyInfo definitions to use qapi_type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-56-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=8815; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=IuCBdKGBPF8OB+y7s4jio7rdRTdD0humb0BIR918jzY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZcQxqX6eOMSpfYs+pLT9Ow0Na9hEzQjJ0+w S7czDd2tmOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5Ss8D/9u4K3F7gThG/+rssznoV4GJ740Eb7vM34SO7kM+CMcAz0SmichYUKsY043yCHop4AuZHC LCq264K5jqI6bLVK5pUhsy42PlJ5ABe9K2vKHMUqJp8pSnncy2C74LHZmXSwl/61sE/J3BLrH7h nYIupz1f2RXz2Kseg4wCVaJb/12YUegn0C4BbAn1osYrlQC1CpAPskw/O4gjHHg19dANxc0iuOl kP/04E9U9V5/Qv3sg7Gma0B2LGOdkqB3UDFV+ya/UgRaGAzYW/FGRfCX3zHJjg/sFdqnVmmeQST Bd1Tu7ZeRf5mznPPYqaQXSiRpnQZWF8j/f9MZkFOJprVi9JKsVO0NzFxbG0wPemso49Okgkzmq0 tdFxFZlrsEPQ2lI/7l83w3+2xaA2aV+uqDCdxukgn+J2CNR9CNo80p75nJpZDjhncVjJGd1M8Yo msm+r+wrIQSoNQ9OrNQYvJ9I2AH5VOpdkqnrBqH+/c0d1BcIg+M/xYRpFfF6xcNX/t2hVaRZjjX 5tEZTIjyloiOSYCAqN2wriWOfN+tmlUocDn/0o53+Th53eTDQl6slDt39kqP+VURUXmsyer4GF8 Mic7qD4Dg11IPqUhCiVLNiuH+iTqs3LsM0IQqHPrhsl2ZPqybHUGY2vDA565zimKYuU3A1kLKNc 4eR+F+9z6aMxDww== 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: uPzOGT0iGuh59v6EHfTVg7HgD8gKs-haIeTaB9J-9jw_1792493477 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493486-188C99EA-96F1E895/0/0 X-purgate-type: clean X-purgate-size: 8817 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: Markus Armbruster 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 6edc702776ab..1b22c8d112f3 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 65341c68c3bf..50d14ab855f7 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; @@ -2530,7 +2531,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, @@ -2538,7 +2539,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 2724b27ec2a1..96603bfdb8a9 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -35,6 +35,7 @@ #include "system/runstate.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" S390pciState *s390_get_phb(void) { @@ -1843,7 +1844,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.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455382.1669297 (Exim 4.92) (envelope-from ) id 1xJ7XJ-0003Gz-DU; Tue, 20 Oct 2026 10:57:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455382.1669297; Tue, 20 Oct 2026 10: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 1xJ7XH-00038O-RH; Tue, 20 Oct 2026 10:57:39 +0000 Received: by outflank-mailman (input) for mailman id 1455382; Tue, 20 Oct 2026 10:51:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RI-0000LC-1t for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RH-00Crub-Eu for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:27 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7479d-2eae-0a2a0a5409dd-0a2a450480cc-44 for ; Tue, 20 Oct 2026 12:51:27 +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 6ad74736-b57f-0a2a45040019-aa0a857c9e75-3 for ; Tue, 20 Oct 2026 12:49:27 +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-532-AU63UEb8PQ-MadFO--Yndg-1; Tue, 20 Oct 2026 10:49:20 +0000 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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8EE4D1955DE9; Tue, 20 Oct 2026 10:49:16 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1701A418; Tue, 20 Oct 2026 10:49: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=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=1792493366; 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=G0tJqQA4vjH1OewDrlPPbV755lqj6OJV4iLGYLxe1dQ=; b=M+ZBmkfYHDagIKA6a0QK4yLoimrm2zgmjFSPRWk0GK1/K/o4rcn8/QDeza+mlmLq7Oyl0F rtF88j7+w9ll9ohQWO0171oemcXpW2gE4m3dJrQlgVgWJEF4UtHgyC3+0tPt6L+x27h0tv mQRPKrSDYwcXbUlTX2BNYVRx6Z5Z1MA= X-MC-Unique: AU63UEb8PQ-MadFO--Yndg-1 X-Mimecast-MFC-AGG-ID: AU63UEb8PQ-MadFO--Yndg_1792493356 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:45:51 +0400 Subject: [PATCH v7 34/65] ppc/spapr-caps: convert to QAPI-aware property registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-34-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=6963; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=h0OiLsI4rZp+v/Mhu46aHZ2MeGUSC4RGBbFRwR/fgso=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZafzwZrCef0nnjKmQFgGHI7d1DU4j3tcKg8 rfJ8YYSxbiJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWgAKCRDa6OEJdZac 5ZNiD/9uJkrnfIq0f1AAFb55zRGcmM6E9/bY9PjcQwic7qZwiIF30FoVEyW+LS1V4LBV8lFxJNS PQU7j6R+CB6v9HoMI64E1PyApDwdLlnaHAJlXcyEPUzd2BVafhj1hHbaYhLxkEy1FKLnJgXjLkJ gdIwysLCQIt8EXWXa5PEr9we5qawBjwypQ0Lag+ls7M/dEH/0Kh1uzOi9w8a2krYIDQZcarZN7i E4LtOP390qyqqA6YnMhP59VMT+qvfxHzc/ZQswUOQyZJDTsWt5bsBXzpOFFpbBXuTXpDT9AtofO ID8iow8Lpz1Tszo5kP/m/Lm4S8UWRsm6FmK1PFXmwtWWlyXJh+CUFxiKOxoxpS5FTXbRJGSv05O ZMYDLHTHu8+gadlaJjYgyFbJVyKlNsrAGTmFvM/RU3rpVkTt06dMhmHo8K8rWEYHAwUYB4Ks35l E6S+GJ02O0X284mnQwikHn+fLhcivRrqM+9mynA/bGmrsWZIK4DhT6Cp8zFSPLW47Oshjun/E64 G1PIDvecXY/KRp7V24XZJYFMStRWq10r6lNpi654+g4kT2EsUxLVHwoqsQTcV+XoNk/+hsNx570 AStfbHcS7MyUnY6GxM7Pl2zFwIbukx86j8jruO3yrSjE+v6CcaPGGLJ2oigWATENvOZrnqpgn3Y yk4mypdVxiZikCA== 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: 1cQZwZqz_9-azft6scwSnN05ejfbyioGzpBabvjSL3k_1792493356 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792493367-C26CAB50-006B6F29/0/0 X-purgate-type: clean X-purgate-size: 6965 Replace the type string in SpaprCapabilityInfo with a QAPITypeInfo pointer and switch spapr_caps_add_properties() from object_class_property_add() to object_class_property_add_qapi(). Reviewed-by: Amit Machhiwal Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/ppc/spapr_caps.c | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c index 103b17364feb..e622c79eb52a 100644 --- a/hw/ppc/spapr_caps.c +++ b/hw/ppc/spapr_caps.c @@ -24,6 +24,7 @@ #include "qemu/osdep.h" #include "qemu/error-report.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/error.h" #include "qapi/visitor.h" #include "system/hw_accel.h" @@ -59,7 +60,7 @@ typedef struct SpaprCapabilityInfo { /* Getter and Setter Function Pointers */ ObjectPropertyAccessor *get; ObjectPropertyAccessor *set; - const char *type; + const QAPITypeInfo *type; /* Possible values if this is a custom string type */ SpaprCapPossible *possible; /* Make sure the virtual hardware can support this capability */ @@ -725,7 +726,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_HTM, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_htm_apply, }, [SPAPR_CAP_VSX] = { @@ -734,7 +735,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_VSX, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_vsx_apply, }, [SPAPR_CAP_DFP] = { @@ -743,7 +744,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_DFP, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_dfp_apply, }, [SPAPR_CAP_CFPC] = { @@ -752,7 +753,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_CFPC, .get = spapr_cap_get_string, .set = spapr_cap_set_string, - .type = "string", + .type = &str_type_info, .possible = &cap_cfpc_possible, .apply = cap_safe_cache_apply, }, @@ -762,7 +763,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_SBBC, .get = spapr_cap_get_string, .set = spapr_cap_set_string, - .type = "string", + .type = &str_type_info, .possible = &cap_sbbc_possible, .apply = cap_safe_bounds_check_apply, }, @@ -774,7 +775,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_IBS, .get = spapr_cap_get_string, .set = spapr_cap_set_string, - .type = "string", + .type = &str_type_info, .possible = &cap_ibs_possible, .apply = cap_safe_indirect_branch_apply, }, @@ -784,7 +785,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_HPT_MAXPAGESIZE, .get = spapr_cap_get_pagesize, .set = spapr_cap_set_pagesize, - .type = "size", + .type = &size_type_info, .apply = cap_hpt_maxpagesize_apply, .cpu_apply = cap_hpt_maxpagesize_cpu_apply, }, @@ -794,7 +795,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_NESTED_KVM_HV, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_nested_kvm_hv_apply, }, [SPAPR_CAP_NESTED_PAPR] = { @@ -803,7 +804,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_NESTED_PAPR, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_nested_papr_apply, }, [SPAPR_CAP_LARGE_DECREMENTER] = { @@ -812,7 +813,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_LARGE_DECREMENTER, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_large_decr_apply, .cpu_apply = cap_large_decr_cpu_apply, }, @@ -822,7 +823,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_CCF_ASSIST, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_ccf_assist_apply, }, [SPAPR_CAP_FWNMI] = { @@ -831,7 +832,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_FWNMI, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_fwnmi_apply, }, [SPAPR_CAP_RPT_INVALIDATE] = { @@ -840,7 +841,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_RPT_INVALIDATE, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_rpt_invalidate_apply, }, [SPAPR_CAP_AIL_MODE_3] = { @@ -849,7 +850,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_AIL_MODE_3, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_ail_mode_3_apply, }, [SPAPR_CAP_DAWR1] = { @@ -858,7 +859,7 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { .index = SPAPR_CAP_DAWR1, .get = spapr_cap_get_bool, .set = spapr_cap_set_bool, - .type = "bool", + .type = &bool_type_info, .apply = cap_dawr1_apply, }, }; @@ -1069,9 +1070,9 @@ void spapr_caps_add_properties(SpaprMachineClass *smc) g_autofree char *name = g_strdup_printf("cap-%s", cap->name); g_autofree char *desc = g_strdup(cap->description); - object_class_property_add(klass, name, cap->type, - cap->get, cap->set, - NULL, cap); + object_class_property_add_qapi(klass, name, cap->type, + cap->get, cap->set, + NULL, cap); object_class_property_set_description(klass, name, desc); } -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455385.1669304 (Exim 4.92) (envelope-from ) id 1xJ7XK-0003fP-T1; Tue, 20 Oct 2026 10:57:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455385.1669304; Tue, 20 Oct 2026 10:57: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 1xJ7XJ-0003YG-O1; Tue, 20 Oct 2026 10:57:41 +0000 Received: by outflank-mailman (input) for mailman id 1455385; Tue, 20 Oct 2026 10:51:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RK-0000Lp-3A for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RJ-00HSQO-G6 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:29 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747b1-bab6-0a2a0a5309dd-0a2a450b8e48-0 for ; Tue, 20 Oct 2026 12:51:29 +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 6ad74774-b7e8-0a2a450b0019-aa0a857c6d91-3 for ; Tue, 20 Oct 2026 12:50:29 +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-142-LEtBYtaXNhep3HOST1h5pg-1; Tue, 20 Oct 2026 06:50:24 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C61F61955DA5; Tue, 20 Oct 2026 10:50:19 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 854725BC; Tue, 20 Oct 2026 10:50:16 +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=1792493428; 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=cjstbMWmXOAnQJ0vRg4/TV0UxKxkDAMv9/7iDMdvYXk=; b=XSffY2IVRgKgqakC6JFT2BMyHFj54TJXSMa5xU8QBEIRxg5dsbGsaWvi+/pHaj3+eRokW0 qn1zCMaRbLDwnuJ94IPUwSpWYP8YhZiu1/RaIzLsTmOvRrL0Qjj7FQBlojsaIcts423yVY cE9YQQJd2SiIeiKrPZB49vwaau/9VhQ= X-MC-Unique: LEtBYtaXNhep3HOST1h5pg-1 X-Mimecast-MFC-AGG-ID: LEtBYtaXNhep3HOST1h5pg_1792493420 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:02 +0400 Subject: [PATCH v7 45/65] hw/s390-virtio-ccw: convert loadparm property to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-45-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1438; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=kUpPGFy4418k+1NoT02grj7G7ylnBF+ugRFLSNuQ/I8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZbZ381/sBWM1azZ53D7cfjK2vNDIyCM5jiw Xz8ukfeXYKJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGWwAKCRDa6OEJdZac 5WE7EACcNb6WUPAXGp4swEqKgOrI7mRkcimuGMJxDQptX6voqKSzXDGgbjpNbOpCSvTsAUBzqkf VmQ+u1XXdOcMUFOXV12h+uVIagNkH/FDk+vj6EhW+7Kv+xUWHQwihzevCBsOe5YRu7AoC5JFL7e 0gnAXgwlHoUc7rofc1b2A696Xi73B0BOxB5zdDwbfJPmC+zNLT3hs1Td4Kz/nHF5mI2tkY38zor J9Gu+Zngb8i7tCVWNN4rxMRTflUnEleoTBaZ/MzpgKLm6BMGvNB/RklxuTW9RaHm5c7Hn2tOkUX BjBeCAlN8BDg+4cPXlsrKBOZG04cS8ma9QO+ZFcTJJ0v6YXzwA+GsHW4fPIoGszFa+UyJOoyFyZ JjxorHFP+v58GJcIr421M6yCPKqLa70RxTrPsVBPMAHrP0TejWLeOs0hIrNkRiE5+2601BD6apI rZkqEk8rXGc2YmuOolkjrs6b6PIw2R6sibjUwbIPFEHNu7HbC/WLZG6sxGdbaHB5xKhjg7Yo0Hf sljEdE+S9n89L1t8za9aF28F5ivQkNlw/vJ2npjoxGF9L6HCdk+EiYF61ps7MRQR9ViFVustynh PdOoORH0IHDSPitjUdZoIvZb6i6CW8KZCeXn1ZUTNMv/w8f9vbbxVroo3zzRSKiilj8k+2MxLjs N6G+newXEeukaug== 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: vqv6ZsqdlPP53dCUgsK0l7KtoPyI116VmiZcYaluEWk_1792493420 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1792493429-AA8D99EA-6ADA8562/0/0 X-purgate-type: clean X-purgate-size: 1440 The QAPI type is actually a string. Here also, if we had typedef support we could expose a more specific type. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/s390x/s390-virtio-ccw.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index fda5ecc9ad3c..3ed425b16c3e 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -43,6 +43,7 @@ #include "system/hostmem.h" #include "target/s390x/kvm/pv.h" #include "migration/blocker.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qapi/qapi-visit-machine-s390x.h" #include "hw/s390x/cpu-topology.h" @@ -908,7 +909,8 @@ static void ccw_machine_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "dea-key-wrap", "enable/disable DEA key wrapping using the CPACF wrapping key"); - object_class_property_add(oc, "loadparm", "loadparm", + /* if QAPI learns to typedef str, we could expose a more specific type */ + object_class_property_add_qapi(oc, "loadparm", &str_type_info, machine_get_loadparm, machine_set_loadparm, NULL, NULL); object_class_property_set_description(oc, "loadparm", -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455388.1669319 (Exim 4.92) (envelope-from ) id 1xJ7XO-0004BN-2G; Tue, 20 Oct 2026 10:57:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455388.1669319; Tue, 20 Oct 2026 10:57: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 1xJ7XM-00045W-1X; Tue, 20 Oct 2026 10:57:44 +0000 Received: by outflank-mailman (input) for mailman id 1455388; Tue, 20 Oct 2026 10:51:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RO-0000N6-4A for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RN-004dIO-HK for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:33 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747a4-8faa-0a2a0a5109dd-0a2a4501b65a-46 for ; Tue, 20 Oct 2026 12:51:33 +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 6ad747b2-5984-0a2a45010019-aa0a817c5cad-3 for ; Tue, 20 Oct 2026 12:51:31 +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-365-se9LWCHqPrS8GDVKoZHxeg-1; Tue, 20 Oct 2026 10:51:26 +0000 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 5E2BF1800878; Tue, 20 Oct 2026 10:51:22 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3CCCA18005B3; Tue, 20 Oct 2026 10:51: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=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=1792493490; 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=0exBW/XllTPTbSwFohqKA2w8apHuJMdvUCko9RJ056E=; b=Pma88dWqnTmc4FPmMNkYkgNUTRvQZ2HY3kR7RsYoRLUoQJ0FXkp8KgmATBtb+RTbDvRM9N ZZCVCo/bsC3Uv1XcTFzW+AOuAEAKgb2gt+q+ZXtf5Re27G4KejpIzMnvk+z20sPWf/v5z7 wUVcfzqLGrrEepRyA6SU4O6Oq3itDdA= X-MC-Unique: se9LWCHqPrS8GDVKoZHxeg-1 X-Mimecast-MFC-AGG-ID: se9LWCHqPrS8GDVKoZHxeg_1792493482 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:14 +0400 Subject: [PATCH v7 57/65] target/riscv: convert PropertyInfo definitions to use qapi_type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-57-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=5488; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=XKjrfhJ2Z/vpJVDltF2KXqS9w+wUXXQdOLcco6lHE08=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10Zc82i8KNdsFK3/pKeHfVnxA4m/fOSulmH97 UqyLuCWFoWJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5Z6cD/40rHcZVYX8wDxKQt8xTbOSbGFHhrkGBp+FJMr/D3qXf1CzfRM/zrW7BsamxNoTKamLgia vG/IF1pMis4auL226bPWZSNCw1wM64OiZLp34N3g6ajQDAnS4jfnerIAq7txzCCJUbSjDZABnY+ O/X/WwsFuXapBnFcvD2GRf7OtzeasFepDj3L1mQI9qlcIH41qkSHstkXLXEuCxStBNzaQuJ+1nT f8elVasH3Qez1yhQlVLkdcseJ+WxT9culB/RhJzlcYMOY3ijoorNNWBmNMniKWqUHM380+dg4mi s5Xym63nleHU9QrcqKokpmXEO6nqQXGl5BVpG/+GI8J37DOJEBt7FopbJ8Qa/Prf2L0HVZ2F4Ri v52x6jhQ2cVDf52+6cx4EEUH1NulOv3VMoE+O/9QeuJjD6NvDl0kfVkgV83mliwEwc7vahuvnT6 MZHRXzDT5gm/k1ueiE/SDcCEv9mGmfnj3XnZ7GWpLcbscFJebhqv5NagTK8eB75QcE5f7Li5RfK wc2VMbA5H3KXsbPLwfv0Bwcz8Ok9gFGyw0cb4nah/uS/gLpuvZSH3RlnyRCw3dHiiNOvmw9ktLa bEN7ShgjTnPCfdQW49hOPBZARpkjinKmx6OFPDecrZiaNqDlQaduXgMnp5B749lfM7OBJ8Ch+S8 7b7viGC9MASEqng== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: DA2jTM9ESM5rdDbEhPDzBLagdqfUFOHp66NC6XzKjH4_1792493482 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792493492-BC95A757-F6AB39A4/0/0 X-purgate-type: clean X-purgate-size: 5490 Mechanical conversion of all local PropertyInfo definitions in target/riscv/cpu.c Signed-off-by: Markus Armbruster Reviewed-by: Alistair Francis Signed-off-by: Marc-André Lureau --- target/riscv/cpu.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 664c1a767950..28bfcb36ecb7 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -1704,7 +1704,7 @@ static void prop_pmu_num_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_pmu_num = { - .type = "uint8", + .qapi_type = &uint8_type_info, .description = "pmu-num", .get = prop_pmu_num_get, .set = prop_pmu_num_set, @@ -1746,7 +1746,7 @@ static void prop_pmu_mask_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_pmu_mask = { - .type = "uint32", + .qapi_type = &uint32_type_info, .description = "pmu-mask", .get = prop_pmu_mask_get, .set = prop_pmu_mask_set, @@ -1778,7 +1778,7 @@ static void prop_mmu_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_mmu = { - .type = "bool", + .qapi_type = &bool_type_info, .description = "mmu", .get = prop_mmu_get, .set = prop_mmu_set, @@ -1811,7 +1811,7 @@ static void prop_pmp_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_pmp = { - .type = "bool", + .qapi_type = &bool_type_info, .description = "pmp", .get = prop_pmp_get, .set = prop_pmp_set, @@ -1851,7 +1851,7 @@ static void prop_num_pmp_regions_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_num_pmp_regions = { - .type = "uint8", + .qapi_type = &uint8_type_info, .description = "num-pmp-regions", .get = prop_num_pmp_regions_get, .set = prop_num_pmp_regions_set, @@ -1889,7 +1889,7 @@ static void prop_pmp_granularity_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_pmp_granularity = { - .type = "uint32", + .qapi_type = &uint32_type_info, .description = "pmp-granularity", .get = prop_pmp_granularity_get, .set = prop_pmp_granularity_set, @@ -1965,7 +1965,7 @@ static void prop_priv_spec_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_priv_spec = { - .type = "str", + .qapi_type = &str_type_info, .description = "priv_spec", /* FIXME enum? */ .get = prop_priv_spec_get, @@ -1998,7 +1998,7 @@ static void prop_vext_spec_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_vext_spec = { - .type = "str", + .qapi_type = &str_type_info, .description = "vext_spec", /* FIXME enum? */ .get = prop_vext_spec_get, @@ -2041,7 +2041,7 @@ static void prop_vlen_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_vlen = { - .type = "uint16", + .qapi_type = &uint16_type_info, .description = "vlen", .get = prop_vlen_get, .set = prop_vlen_set, @@ -2082,7 +2082,7 @@ static void prop_elen_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_elen = { - .type = "uint16", + .qapi_type = &uint16_type_info, .description = "elen", .get = prop_elen_get, .set = prop_elen_set, @@ -2118,7 +2118,7 @@ static void prop_cbom_blksize_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_cbom_blksize = { - .type = "uint16", + .qapi_type = &uint16_type_info, .description = "cbom_blocksize", .get = prop_cbom_blksize_get, .set = prop_cbom_blksize_set, @@ -2154,7 +2154,7 @@ static void prop_cbop_blksize_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_cbop_blksize = { - .type = "uint16", + .qapi_type = &uint16_type_info, .description = "cbop_blocksize", .get = prop_cbop_blksize_get, .set = prop_cbop_blksize_set, @@ -2190,7 +2190,7 @@ static void prop_cboz_blksize_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_cboz_blksize = { - .type = "uint16", + .qapi_type = &uint16_type_info, .description = "cboz_blocksize", .get = prop_cboz_blksize_get, .set = prop_cboz_blksize_set, @@ -2226,7 +2226,7 @@ static void prop_mvendorid_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_mvendorid = { - .type = "uint32", + .qapi_type = &uint32_type_info, .description = "mvendorid", .get = prop_mvendorid_get, .set = prop_mvendorid_set, @@ -2262,7 +2262,7 @@ static void prop_mimpid_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_mimpid = { - .type = "uint64", + .qapi_type = &uint64_type_info, .description = "mimpid", .get = prop_mimpid_get, .set = prop_mimpid_set, @@ -2319,7 +2319,7 @@ static void prop_marchid_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_marchid = { - .type = "uint64", + .qapi_type = &uint64_type_info, .description = "marchid", .get = prop_marchid_get, .set = prop_marchid_set, -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455390.1669323 (Exim 4.92) (envelope-from ) id 1xJ7XP-0004ca-9V; Tue, 20 Oct 2026 10:57:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455390.1669323; Tue, 20 Oct 2026 10:57: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 1xJ7XO-0004W5-1Q; Tue, 20 Oct 2026 10:57:46 +0000 Received: by outflank-mailman (input) for mailman id 1455390; Tue, 20 Oct 2026 10:51:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RR-0000Nc-Tp for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RR-004dIO-AX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747a7-8faa-0a2a0a5109dd-0a2a4508b6ba-38 for ; Tue, 20 Oct 2026 12:51:37 +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 6ad747b8-f659-0a2a45080019-aa0a817c7a21-3 for ; Tue, 20 Oct 2026 12:51:37 +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-15-JRWtrvsmMnafOZ4pe9-J1A-1; Tue, 20 Oct 2026 06:51:33 -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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B4C2E1800BDD; Tue, 20 Oct 2026 10:51:27 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CA95D1800677; Tue, 20 Oct 2026 10:51: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=1792493495; 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=VTmJNa8VT5lexLUKxdzeLthZimg97eONPVFzq6wZuao=; b=Fpav/KImTiylw0zAK2W8eDh+L8tFFht93N6roHK6IWBJO4LArQzaeLhR4nfyALmTH/dlYb h8piPumFznDX6Yj/WEnQGXrK8gi5VEyGp7J/4Rxv4nJBA9SyHI3Oinhrs0F0ZwpkAhXlkE XZ1uYfDXTlQvOFBsaySzaYvKwj09tck= X-MC-Unique: JRWtrvsmMnafOZ4pe9-J1A-1 X-Mimecast-MFC-AGG-ID: JRWtrvsmMnafOZ4pe9-J1A_1792493487 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:15 +0400 Subject: [PATCH v7 58/65] qdev: convert PropertyInfo definitions to use qapi_type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-58-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Stefan Berger X-Developer-Signature: v=1; a=openpgp-sha256; l=3664; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=LIT19w6YWiCW19RYxdZdXGqpA2yVHBE+/WdhPO2w+KQ=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZcuI+2h8ZVKhhoVFi3OkRbLhN7DQhHpw2e8 ZI+IW/5ZPeJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5d+rD/94HsUuS+bA630XGAf6+mNBdx3g5ggb5XrVvKXw9Au65Kows5jbGNX5ExMKeDtXzXsYPQZ 7bawMDy/OvYIm6c0sRa+DQhSHoKTRGyrflTzi3akNDBX1iTFKTE4ApPz982Yb2V1+zjv7S6JoKL s9x+m0L+aJhxXlji2Ne4h/2GqI65xptxwVMDeF5hdFhM1b/GVOLPZQYUgjk16EE7HtDzi9XcRpU qLzkGt0xA8pztXbBxv9kfTMNJvnlKFhUM2FhczGoJMlwLYyrRx/K4ZHzoaT6XiuPZUK7YMxmpkr 6kU46qGrWbK2PfH+q/Y8JKYadL6yh8v3kSS3na9fd5DaDkQX0p+Bnx8iLycn9BNcAfY/w7UNwsU 1syWcvdD3Zjx91KEjMZBf6XQOUp3zeontuSGuATb4jhC/tPGcmnOMzCZilju6MMinaNxT3lY42y HXItgz39UYWffKdBjfxJX3O1XuqYxbblcTGZmheVuso724KYPKlpfJKMUI+l8dYZwzkB21LBjpD CypHEsnuhmR2vRevpDVirDYKTs59vv51cttaKCBf0mOGodSLdbRKt66uM3ORmazmTeb/HPU+/oD vW8fnePj8pQJmxXFS18zBsuuz75rzcslLcOf/SWSu8i8o5lSfTxYhOhED+/Lizl23J6M6lVvKko +KUM9I7WMK1AoZw== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: XVZsjRwnBRXm8zLizZUGnw0G4VqrBxKTVI9FqQnLtoc_1792493487 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792493497-CE14687B-623D1D8E/0/0 X-purgate-type: clean X-purgate-size: 3666 Convert the remaining PropertyInfo definitions outside hw/ After this patch, all PropertyInfo definitions have .qapi_type set, except qdev_prop_link (uses .create) and qdev_prop_array (refactored in the next patches). Signed-off-by: Markus Armbruster Reviewed-by: Stefan Berger Signed-off-by: Marc-André Lureau --- backends/spdm-socket.c | 4 ++-- backends/tpm/tpm_util.c | 3 ++- migration/options.c | 4 +++- target/sparc/cpu.c | 3 ++- 4 files changed, 9 insertions(+), 5 deletions(-) diff --git a/backends/spdm-socket.c b/backends/spdm-socket.c index 826efc276dcd..4a4307975965 100644 --- a/backends/spdm-socket.c +++ b/backends/spdm-socket.c @@ -17,6 +17,7 @@ #include "hw/core/qdev-properties.h" #include "hw/core/qdev-properties-system.h" #include "hw/core/qdev-prop-internal.h" +#include "qapi/qapi-type-infos-sockets.h" static bool read_bytes(const int socket, uint8_t *buffer, size_t number_of_bytes) @@ -253,9 +254,8 @@ void spdm_socket_close(const int socket, SpdmTransportType transport_type) } const PropertyInfo qdev_prop_spdm_trans = { - .type = "SpdmTransportType", + .qapi_type = &SpdmTransportType_type_info, .description = "Spdm Transport, doe/nvme/mctp/scsi/unspecified", - .enum_table = &SpdmTransportType_lookup, .get = qdev_propinfo_get_enum, .set = qdev_propinfo_set_enum, .set_default_value = qdev_propinfo_set_default_value_enum, diff --git a/backends/tpm/tpm_util.c b/backends/tpm/tpm_util.c index 7019f7fd3eb9..dc6d4b211567 100644 --- a/backends/tpm/tpm_util.c +++ b/backends/tpm/tpm_util.c @@ -30,6 +30,7 @@ #include "system/tpm_backend.h" #include "system/tpm_util.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" /* tpm backend property */ @@ -77,7 +78,7 @@ static void release_tpm(Object *obj, const char *name, void *opaque) } const PropertyInfo qdev_prop_tpm = { - .type = "str", + .qapi_type = &str_type_info, .description = "ID of a tpm to use as a backend", .get = get_tpm, .set = set_tpm, diff --git a/migration/options.c b/migration/options.c index 46d040fc3f25..029282a1605c 100644 --- a/migration/options.c +++ b/migration/options.c @@ -37,6 +37,8 @@ #include "ram.h" #include "options.h" #include "system/kvm.h" +#include "qapi/qapi-builtin-type-infos.h" +#include "qapi/qapi-type-infos-common.h" /* Maximum migrate downtime set to 2000 seconds */ #define MAX_MIGRATE_DOWNTIME_SECONDS 2000 @@ -294,7 +296,7 @@ static void set_default_value_tls_opt(ObjectProperty *op, const Property *prop) * TYPE_MIGRATION's TLS options. */ const PropertyInfo qdev_prop_StrOrNull = { - .type = "StrOrNull", + .qapi_type = &StrOrNull_type_info, .get = get_StrOrNull, .set = set_StrOrNull, .release = release_StrOrNull, diff --git a/target/sparc/cpu.c b/target/sparc/cpu.c index ae9bdca9df82..d0354a4d02af 100644 --- a/target/sparc/cpu.c +++ b/target/sparc/cpu.c @@ -30,6 +30,7 @@ #include "tcg/tcg.h" #include "fpu/softfloat.h" #include "target/sparc/translate.h" +#include "qapi/qapi-builtin-type-infos.h" //#define DEBUG_FEATURES @@ -948,7 +949,7 @@ static void sparc_set_nwindows(Object *obj, Visitor *v, const char *name, } static const PropertyInfo qdev_prop_nwindows = { - .type = "int", + .qapi_type = &int_type_info, .description = "Number of register windows", .get = sparc_get_nwindows, .set = sparc_set_nwindows, -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455392.1669331 (Exim 4.92) (envelope-from ) id 1xJ7XQ-0004yE-VJ; Tue, 20 Oct 2026 10:57:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455392.1669331; Tue, 20 Oct 2026 10:57: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 1xJ7XP-0004qq-KM; Tue, 20 Oct 2026 10:57:47 +0000 Received: by outflank-mailman (input) for mailman id 1455392; Tue, 20 Oct 2026 10:51:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7RW-0000OE-GC for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7RV-00HSUK-TI for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:41 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747b7-bab6-0a2a0a5309dd-0a2a4505c874-22 for ; Tue, 20 Oct 2026 12:51:41 +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 6ad747bc-4cb1-0a2a45050019-aa0a817c8131-3 for ; Tue, 20 Oct 2026 12:51:41 +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-491-xio_7je-O7qSetICYWdMZA-1; Tue, 20 Oct 2026 10:51:36 +0000 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 A1AEC19541A2; Tue, 20 Oct 2026 10:51:32 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DDBF930000E7; Tue, 20 Oct 2026 10:51: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=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=1792493500; 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=nP79V/gtequIXU+t/Eu02ll/FN9WUbHuc8AyTpCeGFQ=; b=JHHN6DP0gi4BBye0SSokSIdSfmIn576WOZoBFdd7NUvYXQvKHlFdSNXmjc8/cwiMaYqeTl 7GsK2p9lyUnqNjrDMmWM1oSjnRdkPkhmPAdnkT+lACm3nvJ/S9vBRngWb6w1F2XUK4b3PW zB54U7s1JrmGFNuBD0XG4CMiWoIAFU0= X-MC-Unique: xio_7je-O7qSetICYWdMZA-1 X-Mimecast-MFC-AGG-ID: xio_7je-O7qSetICYWdMZA_1792493492 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:16 +0400 Subject: [PATCH v7 59/65] qdev: introduce typed array PropertyInfos MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-59-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=14678; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=mlWOi/fW9OK4tckY+TRn1APE+VrJXQmOBnALGjwbEQ0=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZcpE0N36exL5+QBGMlSA4uACN+Y42xftBBX h9qkQtQ0riJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5c4yD/0UfQJG5WPTuqhdaOYQ99AXPKpribvFkipRwwlEz96K4bv7wRdXGRAr48+aD1LJmqKvk4f V17WHG4HitooSDv/eG/xUEtK/FocBxblDotXH8BhHVOB/Vm6+WZvumi1SaA7wsEEJTOmCoxI/+1 JA4g74DbBXlF27s435rmq88I5yk503Hr5D/mtYjnBGEfJQJWP6gtGR0jJooy4WkKd1mu2/doJoa GW4yy09MADqm4HEVyvYVFq3jhw9DCTR1I6QOkWeiDwWMpsMGGG80At5F8/GBdJaNBTvKB8RZIx8 MW0217lABMAz0nqw4WtpPqsol58KGjFV+nukL2w94iheX41hZlKyYMRt9HIMJvIlqJKkYnC/Pod Lf2LyJ9MJTjl3cStpGO6ZWTbaI7PTJTbDg/EPSgMc5bXZN+74W/24LNLnlAJV42D6Gn3H5x5HXc kRlLKg4vMoJA+KqASQpzEaMBcqXVKg5hlFivlzNZ783+Jo1g5fMBJCcH8BnPj9MWzmabnxLyWPU L/Vgjr2BOHK8D+hyhWAoWZGJSCdsQ+cvw06/E7oFhDC2pt/iuWjoHiDroClUn2z1un54JMSBOeF 6koVyz1y+KYiYSH2xjv1sEelhoyWcBxu0Gsr6HR7pAkp7whYnNX+56uoutkbGSccx3fFcrczzZN x8oPZybEnxuzd7A== 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: y0a8Gz-0_LCaggKu8PaIZVlATlsHioyDrFqPhNUaRXM_1792493492 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792493501-F4EA12A1-B6C11B05/0/0 X-purgate-type: clean X-purgate-size: 14680 Add element_info and element_size fields to PropertyInfo, and extend qdev_prop_qapi_type() to derive QAPI types for array properties via element_info->qapi_type->list. Add typed list PropertyInfo definitions that replace the generic qdev_prop_array. Each typed list PropertyInfo knows its element type at compile time through the element_info and element_size fields, which allows the QAPI type to be derived automatically. Infrastructure changes: - Add prop_array_info() and prop_array_elem_size() helpers that prefer the new element_info/element_size fields with fallback to the old arrayinfo/arrayfieldsize fields for compatibility - Make get_prop_array, set_prop_array, release_prop_array, and default_prop_array non-static so they can be used by DEFINE_PROP_ARRAY_INFO in other translation units - Add DEFINE_PROP_ARRAY_INFO macro in qdev-prop-internal.h The array of links needs special care for its "full type name" to follow the "linkList" pattern used by link properties ("link"). The old qdev_prop_array and DEFINE_PROP_ARRAY macro are preserved for compatibility; they will be replaced in the next patch. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/qdev-prop-internal.h | 21 +++++++ hw/core/qdev-properties-system.c | 5 ++ hw/core/qdev-properties.c | 104 ++++++++++++++++++++++++------- include/hw/core/qdev-properties-system.h | 2 + include/hw/core/qdev-properties.h | 8 +++ 5 files changed, 119 insertions(+), 21 deletions(-) diff --git a/hw/core/qdev-prop-internal.h b/hw/core/qdev-prop-internal.h index c190b7b88cf4..40fa4bc63f03 100644 --- a/hw/core/qdev-prop-internal.h +++ b/hw/core/qdev-prop-internal.h @@ -27,4 +27,25 @@ void qdev_propinfo_get_int32(Object *obj, Visitor *v, const char *name, void qdev_propinfo_get_size32(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp); +void get_prop_array(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp); +void set_prop_array(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp); +void release_prop_array(Object *obj, const char *name, void *opaque); +void default_prop_array(ObjectProperty *op, const Property *prop); + +/* + * Note: .qapi_type is derived from element_info->qapi_type->list by + * qdev_prop_qapi_type() + */ +#define DEFINE_PROP_ARRAY_INFO(_elem_prop_info, _elem_type) \ + { \ + .element_info = &(_elem_prop_info), \ + .element_size = sizeof(_elem_type), \ + .get = get_prop_array, \ + .set = set_prop_array, \ + .release = release_prop_array, \ + .set_default_value = default_prop_array, \ + } + #endif diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c index 8819a9a0b748..ad4a00f776e6 100644 --- a/hw/core/qdev-properties-system.c +++ b/hw/core/qdev-properties-system.c @@ -484,6 +484,8 @@ const PropertyInfo qdev_prop_netdev = { .set = set_netdev, }; +const PropertyInfo qdev_prop_netdev_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_netdev, NICPeers); /* --- audiodev --- */ static void get_audiodev(Object *obj, Visitor *v, const char* name, @@ -822,6 +824,9 @@ const PropertyInfo qdev_prop_reserved_region = { .set = set_reserved_region, }; +const PropertyInfo qdev_prop_reserved_region_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_reserved_region, ReservedRegion); + /* --- pci address --- */ /* diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c index a9abc646d5d7..bace12b10e36 100644 --- a/hw/core/qdev-properties.c +++ b/hw/core/qdev-properties.c @@ -666,6 +666,22 @@ struct ArrayElementList { void *value; }; +static const PropertyInfo *prop_array_info(const Property *prop) +{ + if (prop->info->element_info) { + return prop->info->element_info; + } + return prop->arrayinfo; +} + +static int prop_array_elem_size(const Property *prop) +{ + if (prop->info->element_size) { + return prop->info->element_size; + } + return prop->arrayfieldsize; +} + /* * Given an array property @parent_prop in @obj, return a Property for a * specific element of the array. Arrays are backed by an uint32_t length field @@ -675,7 +691,7 @@ static Property array_elem_prop(Object *obj, const Property *parent_prop, const char *name, char *elem) { return (Property) { - .info = parent_prop->arrayinfo, + .info = prop_array_info(parent_prop), .name = name, /* * This ugly piece of pointer arithmetic sets up the offset so @@ -693,19 +709,21 @@ static Property array_elem_prop(Object *obj, const Property *parent_prop, * underlying element's property release hook for each element and free the * property array. */ -static void release_prop_array(Object *obj, const char *name, void *opaque) +void release_prop_array(Object *obj, const char *name, void *opaque) { const Property *prop = opaque; uint32_t *alenptr = object_field_prop_ptr(obj, prop); void **arrayptr = (void *)obj + prop->arrayoffset; char *elem = *arrayptr; int i; + const PropertyInfo *elem_info = prop_array_info(prop); + int elem_size = prop_array_elem_size(prop); - if (prop->arrayinfo->release) { + if (elem_info->release) { for (i = 0; i < *alenptr; i++) { Property elem_prop = array_elem_prop(obj, prop, name, elem); - prop->arrayinfo->release(obj, NULL, &elem_prop); - elem += prop->arrayfieldsize; + elem_info->release(obj, NULL, &elem_prop); + elem += elem_size; } } @@ -719,8 +737,8 @@ static void release_prop_array(Object *obj, const char *name, void *opaque) * (a pointer to which is stored in the additional field described by * prop->arrayoffset). */ -static void set_prop_array(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +void set_prop_array(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) { ERRP_GUARD(); const Property *prop = opaque; @@ -728,6 +746,8 @@ static void set_prop_array(Object *obj, Visitor *v, const char *name, void **arrayptr = (void *)obj + prop->arrayoffset; ArrayElementList *list, *elem, *next; const size_t size = sizeof(*list); + const PropertyInfo *elem_info = prop_array_info(prop); + int elem_size = prop_array_elem_size(prop); char *elemptr; bool ok = true; @@ -746,9 +766,9 @@ static void set_prop_array(Object *obj, Visitor *v, const char *name, while (elem) { Property elem_prop; - elem->value = g_malloc0(prop->arrayfieldsize); + elem->value = g_malloc0(elem_size); elem_prop = array_elem_prop(obj, prop, name, elem->value); - prop->arrayinfo->set(obj, v, NULL, &elem_prop, errp); + elem_info->set(obj, v, NULL, &elem_prop, errp); if (*errp) { ok = false; goto out_obj; @@ -770,8 +790,8 @@ out_obj: for (elem = list; elem; elem = next) { Property elem_prop = array_elem_prop(obj, prop, name, elem->value); - if (prop->arrayinfo->release) { - prop->arrayinfo->release(obj, NULL, &elem_prop); + if (elem_info->release) { + elem_info->release(obj, NULL, &elem_prop); } next = elem->next; g_free(elem->value); @@ -784,19 +804,19 @@ out_obj: * Now that we know how big the array has to be, move the data over to a * linear array and free the temporary list. */ - *arrayptr = g_malloc_n(*alenptr, prop->arrayfieldsize); + *arrayptr = g_malloc_n(*alenptr, elem_size); elemptr = *arrayptr; for (elem = list; elem; elem = next) { - memcpy(elemptr, elem->value, prop->arrayfieldsize); - elemptr += prop->arrayfieldsize; + memcpy(elemptr, elem->value, elem_size); + elemptr += elem_size; next = elem->next; g_free(elem->value); g_free(elem); } } -static void get_prop_array(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) +void get_prop_array(Object *obj, Visitor *v, const char *name, + void *opaque, Error **errp) { ERRP_GUARD(); const Property *prop = opaque; @@ -806,6 +826,8 @@ static void get_prop_array(Object *obj, Visitor *v, const char *name, ArrayElementList *list = NULL, *elem; ArrayElementList **tail = &list; const size_t size = sizeof(*list); + const PropertyInfo *elem_info = prop_array_info(prop); + int elem_size = prop_array_elem_size(prop); int i; bool ok; @@ -813,7 +835,7 @@ static void get_prop_array(Object *obj, Visitor *v, const char *name, for (i = 0; i < *alenptr; i++) { elem = g_new0(ArrayElementList, 1); elem->value = elemptr; - elemptr += prop->arrayfieldsize; + elemptr += elem_size; *tail = elem; tail = &elem->next; @@ -826,7 +848,7 @@ static void get_prop_array(Object *obj, Visitor *v, const char *name, elem = list; while (elem) { Property elem_prop = array_elem_prop(obj, prop, name, elem->value); - prop->arrayinfo->get(obj, v, NULL, &elem_prop, errp); + elem_info->get(obj, v, NULL, &elem_prop, errp); if (*errp) { goto out_obj; } @@ -848,7 +870,7 @@ out_obj: } } -static void default_prop_array(ObjectProperty *op, const Property *prop) +void default_prop_array(ObjectProperty *op, const Property *prop) { object_property_set_default_list(op); } @@ -861,6 +883,39 @@ const PropertyInfo qdev_prop_array = { .set_default_value = default_prop_array, }; +const PropertyInfo qdev_prop_uint8_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_uint8, uint8_t); +const PropertyInfo qdev_prop_uint16_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_uint16, uint16_t); +const PropertyInfo qdev_prop_uint32_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_uint32, uint32_t); +const PropertyInfo qdev_prop_uint64_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_uint64, uint64_t); +const PropertyInfo qdev_prop_string_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_string, char *); + +static ObjectProperty *create_link_list_property(ObjectClass *oc, + const char *name, + const Property *prop) +{ + g_autofree char *full_type = g_strdup_printf("link<%s>List", + prop->link_type); + + return object_class_property_add(oc, name, full_type, + get_prop_array, set_prop_array, + release_prop_array, (Property *)prop); +} + +const PropertyInfo qdev_prop_link_list = { + .element_info = &qdev_prop_link, + .element_size = sizeof(void *), + .create = create_link_list_property, + .get = get_prop_array, + .set = set_prop_array, + .release = release_prop_array, + .set_default_value = default_prop_array, +}; + /* --- public helpers --- */ static const Property *qdev_prop_walk(DeviceClass *cls, const char *name) @@ -1159,8 +1214,15 @@ const PropertyInfo qdev_prop_link = { static const QAPITypeInfo *qdev_prop_qapi_type(const Property *prop) { - /* this will be later extended to cope with QAPI array properties */ - return prop->info->qapi_type; + if (prop->info->qapi_type) { + return prop->info->qapi_type; + } + if (prop->info->element_info) { + assert(prop->info->element_info->qapi_type); + assert(prop->info->element_info->qapi_type->list); + return prop->info->element_info->qapi_type->list; + } + return NULL; } void qdev_property_add_static(DeviceState *dev, const Property *prop) diff --git a/include/hw/core/qdev-properties-system.h b/include/hw/core/qdev-properties-system.h index 2cbea16d615e..819dce7d5e5d 100644 --- a/include/hw/core/qdev-properties-system.h +++ b/include/hw/core/qdev-properties-system.h @@ -23,6 +23,8 @@ extern const PropertyInfo qdev_prop_fdc_drive_type; extern const PropertyInfo qdev_prop_drive; extern const PropertyInfo qdev_prop_drive_iothread; extern const PropertyInfo qdev_prop_netdev; +extern const PropertyInfo qdev_prop_netdev_list; +extern const PropertyInfo qdev_prop_reserved_region_list; extern const PropertyInfo qdev_prop_pci_devfn; extern const PropertyInfo qdev_prop_blocksize; extern const PropertyInfo qdev_prop_pci_host_devaddr; diff --git a/include/hw/core/qdev-properties.h b/include/hw/core/qdev-properties.h index 1ea2ba66bb37..0c067170079d 100644 --- a/include/hw/core/qdev-properties.h +++ b/include/hw/core/qdev-properties.h @@ -35,6 +35,8 @@ struct PropertyInfo { const char *description; const QEnumLookup *enum_table; const QAPITypeInfo *qapi_type; + const struct PropertyInfo *element_info; + int element_size; bool realized_set_allowed; /* allow setting property on realized device */ char *(*print)(Object *obj, const Property *prop); void (*set_default_value)(ObjectProperty *op, const Property *prop); @@ -75,7 +77,13 @@ extern const PropertyInfo qdev_prop_string; extern const PropertyInfo qdev_prop_on_off_auto; extern const PropertyInfo qdev_prop_size32; extern const PropertyInfo qdev_prop_array; +extern const PropertyInfo qdev_prop_uint8_list; +extern const PropertyInfo qdev_prop_uint16_list; +extern const PropertyInfo qdev_prop_uint32_list; +extern const PropertyInfo qdev_prop_uint64_list; +extern const PropertyInfo qdev_prop_string_list; extern const PropertyInfo qdev_prop_link; +extern const PropertyInfo qdev_prop_link_list; #define DEFINE_PROP(_name, _state, _field, _prop, _type, ...) { \ .name = (_name), \ -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455394.1669344 (Exim 4.92) (envelope-from ) id 1xJ7XT-0005Lx-2K; Tue, 20 Oct 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 1455394.1669344; Tue, 20 Oct 2026 10:57: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 1xJ7XR-0005Hf-Pz; Tue, 20 Oct 2026 10:57:49 +0000 Received: by outflank-mailman (input) for mailman id 1455394; Tue, 20 Oct 2026 10:51:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Rb-0000Om-IS for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Ra-004dLe-VK for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:46 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747bc-8faa-0a2a0a5109dd-0a2a450ac0cc-28 for ; Tue, 20 Oct 2026 12:51:46 +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 6ad747c1-f2d2-0a2a450a0019-aa0a817c8407-3 for ; Tue, 20 Oct 2026 12:51:46 +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-443-ZgjA7GB6MIOQEU4UKDz0Pw-1; Tue, 20 Oct 2026 10:51:41 +0000 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 9DAA619541A2; Tue, 20 Oct 2026 10:51:37 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2887A5BC; Tue, 20 Oct 2026 10:51: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=1792493505; 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=r8QtuizhlL08ffZvDlPlw2v2PSSFR41aZ6S3u6bs6Qs=; b=Dl5WQd25DyFfc1Bf2Vnqio5y2uLcQNgdmza66W2oUqvHs3aOkVxLYrdLwDGO6l6DsigvSo 0GUVkGg9QM/Z8lNnaiYCcKvANqSsOp94fEUe/Xc4Z0UM2SBokcQP5HYloX4JKJOhzrcn8k 2NsBnUsFAbEJQ9tahCYrgubQdqie9fo= X-MC-Unique: ZgjA7GB6MIOQEU4UKDz0Pw-1 X-Mimecast-MFC-AGG-ID: ZgjA7GB6MIOQEU4UKDz0Pw_1792493497 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:17 +0400 Subject: [PATCH v7 60/65] qdev: simplify DEFINE_PROP_ARRAY and remove generic array PropertyInfo MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-60-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=18915; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=AcBmF3xK1ByT+5UwBtaglHA+LD1ebp5i6d9a8Eno2C4=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZcQVsvYZthZcJnIe4I+d1Hh4MrCaE9gYxWU lhG/CyXLeSJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5ehBD/0bQxYDrIfQP8eZONOGiv1tqlX8g1WhNB17TG+vBi5j+C3oGfzsx38lnKRAcN5xgxzz1CM 1C6QLO3YbdB7nO7OD6wXVB2ACmBrsKt/kzhkJMRAOS2F6RZkcrxNnIvxNV64HsPCaV/bgKHptCW i3j8mn2meJlvQg1JeQ9c6gGf0UkYJsMGfVKnqEU6rUR5mZx0iX5zghoO+VG1oXmHXVYe7oOl7lb E5wtqIj6ipYyrt3nTaE84ZNyXgchLpOG3YU+afL4IA6cH4CkPrnv7B4OmnjET3jRLE+kStLOe9C N0izUsnNyTalfSJxy4y0Dbrewp8QQntANZnrle7jyFTW8kUQmu0G/0/80F4LxWf9y8dRpqJYDHl 4nzzttOhpDmwqnqQoB16CcQlMNhX3vXFqO+jDwjYeS5qXdM91f88Cgn+r6fakjIYk/II637VUYV Pb0MHezwGN8sBTUROcVPxo65vHguUIdV1Zcp6jJ/seTaCbNFiOqFY9mqhW6PEI/dn4u8rTWLhvV JbZdVZyrW1STJql4uj6cX7xOhzHzd1/FtlOUJKxigqrbx8XjmLOauttoZzOnJdnnsQHcShiKuAb VdyqA86tVpuDQPZba/kmur0HlRnDqMuvW+V3Mb8Ij0S8aGdUuq9Zp5RscZC2sLV9VUt8bwaf8mz 3T5spA2nBMmHtjQ== 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: pcixnRtM0l1SHRb4oJi-nW0yVtYtnO3OVDaV5fECdcg_1792493497 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1792493506-508CDCFC-AF7B7058/0/0 X-purgate-type: clean X-purgate-size: 18917 Change DEFINE_PROP_ARRAY, the macro now uses _arrayprop##_list to resolve the typed list PropertyInfo (introduced in the previous patch) instead of the generic qdev_prop_array. This means the element type and size information is carried by the PropertyInfo itself rather than duplicated at each callsite. Since the typed list PropertyInfos encode element_info and element_size, the .arrayinfo and .arrayfieldsize fields are no longer set by the macro (they will be removed from the Property struct in the next patch). Remove qdev_prop_array, which is now unused. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/qdev-properties.c | 8 -------- hw/display/apple-gfx-mmio.m | 2 +- hw/display/apple-gfx-pci.m | 2 +- hw/display/apple-gfx.h | 1 + hw/display/apple-gfx.m | 4 ++++ hw/input/stellaris_gamepad.c | 2 +- hw/intc/arm_gicv3_common.c | 2 +- hw/intc/arm_gicv5_common.c | 4 ++-- hw/intc/rx_icu.c | 4 ++-- hw/misc/arm_sysctl.c | 4 ++-- hw/misc/mps2-scc.c | 2 +- hw/net/rocker/rocker.c | 2 +- hw/net/virtio-net.c | 2 +- hw/nvram/xlnx-efuse.c | 2 +- hw/nvram/xlnx-versal-efuse-ctrl.c | 2 +- hw/riscv/riscv_hart.c | 6 ++---- hw/virtio/virtio-iommu-pci.c | 2 +- include/hw/block/block.h | 2 +- include/hw/core/qdev-properties.h | 27 ++++++++++----------------- tests/unit/test-qdev.c | 2 +- 20 files changed, 35 insertions(+), 47 deletions(-) diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c index bace12b10e36..5c403cc2e57e 100644 --- a/hw/core/qdev-properties.c +++ b/hw/core/qdev-properties.c @@ -875,14 +875,6 @@ void default_prop_array(ObjectProperty *op, const Property *prop) object_property_set_default_list(op); } -const PropertyInfo qdev_prop_array = { - .type = "list", - .get = get_prop_array, - .set = set_prop_array, - .release = release_prop_array, - .set_default_value = default_prop_array, -}; - const PropertyInfo qdev_prop_uint8_list = DEFINE_PROP_ARRAY_INFO(qdev_prop_uint8, uint8_t); const PropertyInfo qdev_prop_uint16_list = diff --git a/hw/display/apple-gfx-mmio.m b/hw/display/apple-gfx-mmio.m index 58beaadd1f10..dcd04617eb87 100644 --- a/hw/display/apple-gfx-mmio.m +++ b/hw/display/apple-gfx-mmio.m @@ -258,7 +258,7 @@ static void apple_gfx_mmio_reset(Object *obj, ResetType type) static const Property apple_gfx_mmio_properties[] = { DEFINE_PROP_ARRAY("display-modes", AppleGFXMMIOState, common.num_display_modes, common.display_modes, - qdev_prop_apple_gfx_display_mode, AppleGFXDisplayMode), + qdev_prop_apple_gfx_display_mode), }; static void apple_gfx_mmio_class_init(ObjectClass *klass, const void *data) diff --git a/hw/display/apple-gfx-pci.m b/hw/display/apple-gfx-pci.m index b0694f4cb855..74f79c8b157b 100644 --- a/hw/display/apple-gfx-pci.m +++ b/hw/display/apple-gfx-pci.m @@ -118,7 +118,7 @@ static void apple_gfx_pci_reset(Object *obj, ResetType type) static const Property apple_gfx_pci_properties[] = { DEFINE_PROP_ARRAY("display-modes", AppleGFXPCIState, common.num_display_modes, common.display_modes, - qdev_prop_apple_gfx_display_mode, AppleGFXDisplayMode), + qdev_prop_apple_gfx_display_mode), }; static void apple_gfx_pci_class_init(ObjectClass *klass, const void *data) diff --git a/hw/display/apple-gfx.h b/hw/display/apple-gfx.h index 3197bd853dab..b7eef7b9b14a 100644 --- a/hw/display/apple-gfx.h +++ b/hw/display/apple-gfx.h @@ -69,6 +69,7 @@ void *apple_gfx_host_ptr_for_gpa_range(uint64_t guest_physical, MemoryRegion **mapping_in_region); extern const PropertyInfo qdev_prop_apple_gfx_display_mode; +extern const PropertyInfo qdev_prop_apple_gfx_display_mode_list; #endif diff --git a/hw/display/apple-gfx.m b/hw/display/apple-gfx.m index 77c420b30006..592d692d793d 100644 --- a/hw/display/apple-gfx.m +++ b/hw/display/apple-gfx.m @@ -16,6 +16,7 @@ #include "qemu/cutils.h" #include "qemu/log.h" #include "qapi/qapi-builtin-type-infos.h" +#include "hw/core/qdev-prop-internal.h" #include "qapi/visitor.h" #include "qapi/error.h" #include "qemu/aio-wait.h" @@ -879,3 +880,6 @@ static void apple_gfx_set_display_mode(Object *obj, Visitor *v, .get = apple_gfx_get_display_mode, .set = apple_gfx_set_display_mode, }; + +const PropertyInfo qdev_prop_apple_gfx_display_mode_list = + DEFINE_PROP_ARRAY_INFO(qdev_prop_apple_gfx_display_mode, AppleGFXDisplayMode); diff --git a/hw/input/stellaris_gamepad.c b/hw/input/stellaris_gamepad.c index 376d91abad70..20613f649977 100644 --- a/hw/input/stellaris_gamepad.c +++ b/hw/input/stellaris_gamepad.c @@ -80,7 +80,7 @@ static void stellaris_gamepad_reset_enter(Object *obj, ResetType type) static const Property stellaris_gamepad_properties[] = { DEFINE_PROP_ARRAY("keycodes", StellarisGamepad, num_buttons, - keycodes, qdev_prop_uint32, uint32_t), + keycodes, qdev_prop_uint32), }; static void stellaris_gamepad_class_init(ObjectClass *klass, const void *data) diff --git a/hw/intc/arm_gicv3_common.c b/hw/intc/arm_gicv3_common.c index f7ba74e6d52a..1298b6b735e9 100644 --- a/hw/intc/arm_gicv3_common.c +++ b/hw/intc/arm_gicv3_common.c @@ -615,7 +615,7 @@ static const Property arm_gicv3_common_properties[] = { */ DEFINE_PROP_BOOL("force-8-bit-prio", GICv3State, force_8bit_prio, 0), DEFINE_PROP_ARRAY("redist-region-count", GICv3State, nb_redist_regions, - redist_region_count, qdev_prop_uint32, uint32_t), + redist_region_count, qdev_prop_uint32), DEFINE_PROP_LINK("sysmem", GICv3State, dma, TYPE_MEMORY_REGION, MemoryRegion *), DEFINE_PROP_UINT32("first-cpu-index", GICv3State, first_cpu_idx, 0), diff --git a/hw/intc/arm_gicv5_common.c b/hw/intc/arm_gicv5_common.c index b155486af65e..61c8ae493021 100644 --- a/hw/intc/arm_gicv5_common.c +++ b/hw/intc/arm_gicv5_common.c @@ -191,9 +191,9 @@ static void gicv5_common_realize(DeviceState *dev, Error **errp) static const Property arm_gicv5_common_properties[] = { DEFINE_PROP_LINK_ARRAY("cpus", GICv5Common, num_cpus, - cpus, TYPE_ARM_CPU, ARMCPU *), + cpus, TYPE_ARM_CPU), DEFINE_PROP_ARRAY("cpu-iaffids", GICv5Common, num_cpu_iaffids, - cpu_iaffids, qdev_prop_uint32, uint32_t), + cpu_iaffids, qdev_prop_uint32), DEFINE_PROP_UINT32("irsid", GICv5Common, irsid, 0), DEFINE_PROP_UINT32("spi-range", GICv5Common, spi_range, 0), DEFINE_PROP_UINT32("spi-base", GICv5Common, spi_base, 0), diff --git a/hw/intc/rx_icu.c b/hw/intc/rx_icu.c index 992b069ae245..125a6dcb6804 100644 --- a/hw/intc/rx_icu.c +++ b/hw/intc/rx_icu.c @@ -356,9 +356,9 @@ static const VMStateDescription vmstate_rxicu = { static const Property rxicu_properties[] = { DEFINE_PROP_ARRAY("ipr-map", RXICUState, nr_irqs, map, - qdev_prop_uint8, uint8_t), + qdev_prop_uint8), DEFINE_PROP_ARRAY("trigger-level", RXICUState, nr_sense, init_sense, - qdev_prop_uint8, uint8_t), + qdev_prop_uint8), }; static void rxicu_class_init(ObjectClass *klass, const void *data) diff --git a/hw/misc/arm_sysctl.c b/hw/misc/arm_sysctl.c index ebc95b9bb54c..1df85593a5cb 100644 --- a/hw/misc/arm_sysctl.c +++ b/hw/misc/arm_sysctl.c @@ -626,10 +626,10 @@ static const Property arm_sysctl_properties[] = { DEFINE_PROP_UINT32("proc_id", arm_sysctl_state, proc_id, 0), /* Daughterboard power supply voltages (as reported via SYS_CFG) */ DEFINE_PROP_ARRAY("db-voltage", arm_sysctl_state, db_num_vsensors, - db_voltage, qdev_prop_uint32, uint32_t), + db_voltage, qdev_prop_uint32), /* Daughterboard clock reset values (as reported via SYS_CFG) */ DEFINE_PROP_ARRAY("db-clock", arm_sysctl_state, db_num_clocks, - db_clock_reset, qdev_prop_uint32, uint32_t), + db_clock_reset, qdev_prop_uint32), }; static void arm_sysctl_class_init(ObjectClass *klass, const void *data) diff --git a/hw/misc/mps2-scc.c b/hw/misc/mps2-scc.c index 554b504c7203..32f9e166feed 100644 --- a/hw/misc/mps2-scc.c +++ b/hw/misc/mps2-scc.c @@ -464,7 +464,7 @@ static const Property mps2_scc_properties[] = { * motherboard configuration controller to suit the FPGA image. */ DEFINE_PROP_ARRAY("oscclk", MPS2SCC, num_oscclk, oscclk_reset, - qdev_prop_uint32, uint32_t), + qdev_prop_uint32), }; static void mps2_scc_class_init(ObjectClass *klass, const void *data) diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c index 910dce901b67..afbc32e99d94 100644 --- a/hw/net/rocker/rocker.c +++ b/hw/net/rocker/rocker.c @@ -1466,7 +1466,7 @@ static const Property rocker_properties[] = { DEFINE_PROP_UINT64("switch_id", Rocker, switch_id, 0), DEFINE_PROP_ARRAY("ports", Rocker, fp_ports, - fp_ports_peers, qdev_prop_netdev, NICPeers), + fp_ports_peers, qdev_prop_netdev), }; static const VMStateDescription rocker_vmsd = { diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c index 19f453fb7dfd..56194398742e 100644 --- a/hw/net/virtio-net.c +++ b/hw/net/virtio-net.c @@ -4377,7 +4377,7 @@ static const Property virtio_net_properties[] = { DEFINE_PROP_BIT64("hash", VirtIONet, host_features, VIRTIO_NET_F_HASH_REPORT, false), DEFINE_PROP_ARRAY("ebpf-rss-fds", VirtIONet, nr_ebpf_rss_fds, - ebpf_rss_fds, qdev_prop_string, char*), + ebpf_rss_fds, qdev_prop_string), DEFINE_PROP_BIT64("guest_rsc_ext", VirtIONet, host_features, VIRTIO_NET_F_RSC_EXT, false), DEFINE_PROP_UINT32("rsc_interval", VirtIONet, rsc_timeout, diff --git a/hw/nvram/xlnx-efuse.c b/hw/nvram/xlnx-efuse.c index b1c9ee4980a0..99c16ce76f15 100644 --- a/hw/nvram/xlnx-efuse.c +++ b/hw/nvram/xlnx-efuse.c @@ -266,7 +266,7 @@ static const Property efuse_properties[] = { DEFINE_PROP_UINT32("efuse-size", XlnxEFuse, efuse_size, 64 * 32), DEFINE_PROP_BOOL("init-factory-tbits", XlnxEFuse, init_tbits, true), DEFINE_PROP_ARRAY("read-only", XlnxEFuse, ro_bits_cnt, ro_bits, - qdev_prop_uint32, uint32_t), + qdev_prop_uint32), }; static void efuse_class_init(ObjectClass *klass, const void *data) diff --git a/hw/nvram/xlnx-versal-efuse-ctrl.c b/hw/nvram/xlnx-versal-efuse-ctrl.c index f5d5587cb657..101320b82fd9 100644 --- a/hw/nvram/xlnx-versal-efuse-ctrl.c +++ b/hw/nvram/xlnx-versal-efuse-ctrl.c @@ -740,7 +740,7 @@ static const Property efuse_ctrl_props[] = { TYPE_XLNX_EFUSE, XlnxEFuse *), DEFINE_PROP_ARRAY("pg0-lock", XlnxVersalEFuseCtrl, extra_pg0_lock_n16, - extra_pg0_lock_spec, qdev_prop_uint16, uint16_t), + extra_pg0_lock_spec, qdev_prop_uint16), }; static void efuse_ctrl_class_init(ObjectClass *klass, const void *data) diff --git a/hw/riscv/riscv_hart.c b/hw/riscv/riscv_hart.c index 32fd39737ff6..132cf8737001 100644 --- a/hw/riscv/riscv_hart.c +++ b/hw/riscv/riscv_hart.c @@ -48,11 +48,9 @@ static const Property riscv_harts_props[] = { * defined by "rnmi-exception-vector". */ DEFINE_PROP_ARRAY("rnmi-interrupt-vector", RISCVHartArrayState, - num_rnmi_irqvec, rnmi_irqvec, qdev_prop_uint64, - uint64_t), + num_rnmi_irqvec, rnmi_irqvec, qdev_prop_uint64), DEFINE_PROP_ARRAY("rnmi-exception-vector", RISCVHartArrayState, - num_rnmi_excpvec, rnmi_excpvec, qdev_prop_uint64, - uint64_t), + num_rnmi_excpvec, rnmi_excpvec, qdev_prop_uint64), DEFINE_PROP_LINK("memory", RISCVHartArrayState, memory, TYPE_MEMORY_REGION, MemoryRegion *), }; diff --git a/hw/virtio/virtio-iommu-pci.c b/hw/virtio/virtio-iommu-pci.c index 7b5ffddc1e97..1f3a07c5d119 100644 --- a/hw/virtio/virtio-iommu-pci.c +++ b/hw/virtio/virtio-iommu-pci.c @@ -38,7 +38,7 @@ static const Property virtio_iommu_pci_properties[] = { DEFINE_PROP_UINT32("class", VirtIOPCIProxy, class_code, 0), DEFINE_PROP_ARRAY("reserved-regions", VirtIOIOMMUPCI, vdev.nr_prop_resv_regions, vdev.prop_resv_regions, - qdev_prop_reserved_region, ReservedRegion), + qdev_prop_reserved_region), }; static void virtio_iommu_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp) diff --git a/include/hw/block/block.h b/include/hw/block/block.h index df941df19f26..70bf03a8de73 100644 --- a/include/hw/block/block.h +++ b/include/hw/block/block.h @@ -83,7 +83,7 @@ static inline unsigned int get_physical_block_exp(BlockConf *conf) _conf.account_failed, ON_OFF_AUTO_AUTO), \ DEFINE_PROP_ARRAY("stats-intervals", _state, \ _conf.num_stats_intervals, _conf.stats_intervals, \ - qdev_prop_uint32, uint32_t) + qdev_prop_uint32) #define DEFINE_BLOCK_PROPERTIES(_state, _conf) \ DEFINE_PROP_DRIVE("drive", _state, _conf.blk), \ diff --git a/include/hw/core/qdev-properties.h b/include/hw/core/qdev-properties.h index 0c067170079d..39f95ce7a3c6 100644 --- a/include/hw/core/qdev-properties.h +++ b/include/hw/core/qdev-properties.h @@ -76,7 +76,6 @@ extern const PropertyInfo qdev_prop_size; extern const PropertyInfo qdev_prop_string; extern const PropertyInfo qdev_prop_on_off_auto; extern const PropertyInfo qdev_prop_size32; -extern const PropertyInfo qdev_prop_array; extern const PropertyInfo qdev_prop_uint8_list; extern const PropertyInfo qdev_prop_uint16_list; extern const PropertyInfo qdev_prop_uint32_list; @@ -148,15 +147,15 @@ extern const PropertyInfo qdev_prop_link_list; * @_name: name of the array * @_state: name of the device state structure type * @_field: uint32_t field in @_state to hold the array length - * @_arrayfield: field in @_state (of type '@_arraytype *') which - * will point to the array - * @_arrayprop: PropertyInfo defining what property the array elements have - * @_arraytype: C type of the array elements + * @_arrayfield: field in @_state which will point to the array + * @_arrayprop: PropertyInfo for the array elements (e.g. qdev_prop_uint32); + * a corresponding list PropertyInfo named @_arrayprop##_list + * must exist * * Define device properties for a variable-length array _name. The array is * represented as a list in the visitor interface. * - * @_arraytype is required to be movable with memcpy(). + * The element type must be movable with memcpy(). * * When the array property is set, the @_field member of the device * struct is set to the array length, and @_arrayfield is set to point @@ -166,12 +165,10 @@ extern const PropertyInfo qdev_prop_link_list; * @_arrayfield memory. */ #define DEFINE_PROP_ARRAY(_name, _state, _field, \ - _arrayfield, _arrayprop, _arraytype) \ - DEFINE_PROP(_name, _state, _field, qdev_prop_array, uint32_t, \ + _arrayfield, _arrayprop) \ + DEFINE_PROP(_name, _state, _field, _arrayprop##_list, uint32_t, \ .set_default = true, \ .defval.u = 0, \ - .arrayinfo = &(_arrayprop), \ - .arrayfieldsize = sizeof(_arraytype), \ .arrayoffset = offsetof(_state, _arrayfield)) #define DEFINE_PROP_LINK(_name, _state, _field, _type, _ptr_type) \ @@ -183,10 +180,8 @@ extern const PropertyInfo qdev_prop_link_list; * @_name: name of the array * @_state: name of the device state structure type * @_field: uint32_t field in @_state to hold the array length - * @_arrayfield: field in @_state (of type '@_arraytype *') which - * will point to the array + * @_arrayfield: field in @_state which will point to the array * @_linktype: QOM type name of the link type - * @_arraytype: C type of the array elements * * Define device properties for a variable-length array _name of links * (i.e. this is the array version of DEFINE_PROP_LINK). @@ -195,12 +190,10 @@ extern const PropertyInfo qdev_prop_link_list; * where each string is the QOM path of the object to be linked. */ #define DEFINE_PROP_LINK_ARRAY(_name, _state, _field, _arrayfield, \ - _linktype, _arraytype) \ - DEFINE_PROP(_name, _state, _field, qdev_prop_array, uint32_t, \ + _linktype) \ + DEFINE_PROP(_name, _state, _field, qdev_prop_link_list, uint32_t, \ .set_default = true, \ .defval.u = 0, \ - .arrayinfo = &qdev_prop_link, \ - .arrayfieldsize = sizeof(_arraytype), \ .arrayoffset = offsetof(_state, _arrayfield), \ .link_type = _linktype) diff --git a/tests/unit/test-qdev.c b/tests/unit/test-qdev.c index 77c3eee71713..8cd004b1efab 100644 --- a/tests/unit/test-qdev.c +++ b/tests/unit/test-qdev.c @@ -23,7 +23,7 @@ static const Property my_dev_props[] = { DEFINE_PROP_UINT32("u32", MyDev, prop_u32, 100), DEFINE_PROP_STRING("string", MyDev, prop_string), DEFINE_PROP_ARRAY("array-u32", MyDev, prop_array_u32_nb, prop_array_u32, - qdev_prop_uint32, uint32_t), + qdev_prop_uint32), }; static void my_dev_class_init(ObjectClass *oc, const void *data) -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455396.1669353 (Exim 4.92) (envelope-from ) id 1xJ7XV-0005kS-9P; Tue, 20 Oct 2026 10:57:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455396.1669353; Tue, 20 Oct 2026 10:57: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 1xJ7XT-0005bv-Km; Tue, 20 Oct 2026 10:57:51 +0000 Received: by outflank-mailman (input) for mailman id 1455396; Tue, 20 Oct 2026 10:51:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Rm-0000PJ-Bk for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Rl-00Cvm1-Hq for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:57 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747ca-8faa-0a2a0a5109dd-0a2a4505e676-10 for ; Tue, 20 Oct 2026 12:51:57 +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 6ad747cb-4cb1-0a2a45050019-aa0a857c501f-3 for ; Tue, 20 Oct 2026 12:51:57 +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-674-wz3IHZmqNpWyL00b1VAr7Q-1; Tue, 20 Oct 2026 10:51:46 +0000 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 390C7180132B; Tue, 20 Oct 2026 10:51:42 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id AEC3230000E7; Tue, 20 Oct 2026 10:51: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=1792493515; 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=LYACgjhTWZ9q+fLhnzsamP9g+AzKgXq2yAfu5fEslcg=; b=aanf2Mf7GTaqdeppr2099HyhO9I/TSgix+uC+WtKZV2G8B6Kmdc7XEbSim7JOqlhC/6Ee7 K+eG0nFiK/NUTA/b80rr8zIsGdF19H1FD4YKd+YjdHzQUQHy1fsdEVjhdRSNwbxj1LiUjO ApO0yCl0V+8Vq3W+7VIwWrSWc79xMf0= X-MC-Unique: wz3IHZmqNpWyL00b1VAr7Q-1 X-Mimecast-MFC-AGG-ID: wz3IHZmqNpWyL00b1VAr7Q_1792493502 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:18 +0400 Subject: [PATCH v7 61/65] qdev: remove deprecated PropertyInfo.type and .enum_table fields MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-61-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=5656; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=GW0iWX+ovnUEAGVG0BxcFS64OjWdn47qGiXFBFBt6kE=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZduD65Qr6F408CFXCHRwiWcGKpWuyckav27 m0L7FlHyHOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXQAKCRDa6OEJdZac 5SIyD/9K494S/RKkzAsSOv9T/MgMAP/WgYu11N3TAUAFlouXn2Swjs8mxH+DvN0TL1zOI7DEln4 fWF3jd4K9yGpeOdK3FVhlUuUGIu+vCahmXGsC2IRNnSgUJb4k2RHjeIiyWV/jhtNA/9wx465q/C 0OSjxbW+EtYZ3lz0RkjF6YDM+tm9WVYqnQnMDbFuzngcpgqksdveXP06Xu2THNHykMaEy9m8nir mzxnTI67NabjcysMX+MF1Qgy6e2kI6X8PSi5Ii4CpJXlg6NszHB8aISyuxGh3En/Fv2Y/2f/fzC sIKxBFBcSVSMYhRpwzAZZCX8YSUbh2Y42NRkfwZMI08gHA+sl8pYFdenolCBtd8mEDlWjtCWGLB c97FNo8YgEqQpDTNZOal6LhBdRktum+TSi1XlcqMndZ/TCO/g5x8g/hnsFrp/+6WHt+4VAegrzT mkGeBr/Y+ok5ueSlc+kTZYEoLpKHAsHeYM3r+GcPnXOgCk9GvkOrAfaAoHc155+qqmkOyAUeWJu V4X338aVVee/lykp8yDDcAkwPVhw1DH0lCRXuHCA2/aR8xhiZg8zMindNp8TtG/QbTUCwDa/WMw hJcKbcWKMOqkjIZn3eNTlzVwzpE6SFeoKKAnXaQFooDRlL0a/mAzPqJ1ahGBT4iLEdc/AVpxjkM ETt5bqcvNS2VmlQ== 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: aiKVchuLA7BQOzpTiF3oqenAXhvLeVLnjKgzaRlMziU_1792493502 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792493517-2551A2A1-B41E74CC/0/0 X-purgate-type: clean X-purgate-size: 5658 Now that all PropertyInfo definitions use .qapi_type, remove the legacy .type (string) and .enum_table fields from PropertyInfo, and the .arrayinfo/.arrayfieldsize fields from Property. Remove fallback branches in qdev_property_add_static() and qdev_class_add_property() that used object_property_add() with prop->info->type: these always use the QAPI-aware registration path now. Simplify qdev_propinfo_enum_lookup(), prop_array_info() and prop_array_elem_size() to use the new fields directly. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/qdev-properties.c | 58 ++++++++++++--------------------------- include/hw/core/qdev-properties.h | 4 --- 2 files changed, 17 insertions(+), 45 deletions(-) diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c index 5c403cc2e57e..a121878467e1 100644 --- a/hw/core/qdev-properties.c +++ b/hw/core/qdev-properties.c @@ -103,11 +103,8 @@ static ObjectPropertyAccessor *field_prop_setter(const PropertyInfo *info) const QEnumLookup *qdev_propinfo_enum_lookup(const PropertyInfo *info) { - if (info->qapi_type) { - assert(info->qapi_type->lookup); - return info->qapi_type->lookup; - } - return info->enum_table; + assert(info->qapi_type->lookup); + return info->qapi_type->lookup; } void qdev_propinfo_get_enum(Object *obj, Visitor *v, const char *name, @@ -668,18 +665,12 @@ struct ArrayElementList { static const PropertyInfo *prop_array_info(const Property *prop) { - if (prop->info->element_info) { - return prop->info->element_info; - } - return prop->arrayinfo; + return prop->info->element_info; } static int prop_array_elem_size(const Property *prop) { - if (prop->info->element_size) { - return prop->info->element_size; - } - return prop->arrayfieldsize; + return prop->info->element_size; } /* @@ -1224,20 +1215,13 @@ void qdev_property_add_static(DeviceState *dev, const Property *prop) const QAPITypeInfo *qapi_type = qdev_prop_qapi_type(prop); assert(!prop->info->create); + assert(qapi_type); - if (qapi_type) { - op = object_property_add_qapi(obj, prop->name, qapi_type, - field_prop_getter(prop->info), - field_prop_setter(prop->info), - prop->info->release, - (Property *)prop); - } else { - op = object_property_add(obj, prop->name, prop->info->type, - field_prop_getter(prop->info), - field_prop_setter(prop->info), - prop->info->release, - (Property *)prop); - } + op = object_property_add_qapi(obj, prop->name, qapi_type, + field_prop_getter(prop->info), + field_prop_setter(prop->info), + prop->info->release, + (Property *)prop); object_property_set_description(obj, prop->name, prop->info->description); @@ -1261,21 +1245,13 @@ static void qdev_class_add_property(DeviceClass *klass, const char *name, } else { const QAPITypeInfo *qapi_type = qdev_prop_qapi_type(prop); - if (qapi_type) { - op = object_class_property_add_qapi(oc, - name, qapi_type, - field_prop_getter(prop->info), - field_prop_setter(prop->info), - prop->info->release, - (Property *)prop); - } else { - op = object_class_property_add(oc, - name, prop->info->type, - field_prop_getter(prop->info), - field_prop_setter(prop->info), - prop->info->release, - (Property *)prop); - } + assert(qapi_type); + op = object_class_property_add_qapi(oc, + name, qapi_type, + field_prop_getter(prop->info), + field_prop_setter(prop->info), + prop->info->release, + (Property *)prop); } if (prop->set_default) { prop->info->set_default_value(op, prop); diff --git a/include/hw/core/qdev-properties.h b/include/hw/core/qdev-properties.h index 39f95ce7a3c6..2267e734d1fd 100644 --- a/include/hw/core/qdev-properties.h +++ b/include/hw/core/qdev-properties.h @@ -23,17 +23,13 @@ struct Property { int64_t i; uint64_t u; } defval; - const PropertyInfo *arrayinfo; int arrayoffset; - int arrayfieldsize; uint8_t bitnr; bool set_default; }; struct PropertyInfo { - const char *type; const char *description; - const QEnumLookup *enum_table; const QAPITypeInfo *qapi_type; const struct PropertyInfo *element_info; int element_size; -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455397.1669365 (Exim 4.92) (envelope-from ) id 1xJ7XX-0006L1-Oa; Tue, 20 Oct 2026 10:57:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455397.1669365; Tue, 20 Oct 2026 10: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 1xJ7XW-0006Dj-5f; Tue, 20 Oct 2026 10:57:54 +0000 Received: by outflank-mailman (input) for mailman id 1455397; Tue, 20 Oct 2026 10:51:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Rn-0000PP-4T for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:51:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Rm-00Cs1D-HQ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:51:58 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747ce-e002-0a2a0a5209dd-0a2a4502e712-0 for ; Tue, 20 Oct 2026 12:51:58 +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 6ad747cd-6ca4-0a2a45020019-aa0a857c9a75-3 for ; Tue, 20 Oct 2026 12:51:58 +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-228-MDo8sez-NcyGAOl5_G0YjQ-1; Tue, 20 Oct 2026 10:51:52 +0000 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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E077E1955DD1; Tue, 20 Oct 2026 10:51:47 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9E9F31800677; Tue, 20 Oct 2026 10:51: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=1792493517; 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=th1JKpfzAzi8+0DyZvMgIumhc4CFEiTeW47qkGiYHs4=; b=CC9N30oSmUu8aKCBiTlzH5oGWOB22lcZbrsEu/zrhlPXWSMPtPn+Fgza5e90uxzsgnRxHz KWncaeA2qEmJ9H2qn4/7hZOk7ZIdqGmu92gH+LuwBKUVDj/4925N57zH8/dQ2WYDURzDBY w/7b3TLtK8zK6lDFgTSL8lG3y66IhIQ= X-MC-Unique: MDo8sez-NcyGAOl5_G0YjQ-1 X-Mimecast-MFC-AGG-ID: MDo8sez-NcyGAOl5_G0YjQ_1792493508 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:19 +0400 Subject: [PATCH v7 62/65] hw/i386: convert PCSouthBridgeOption to QAPI enum MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-62-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=6526; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=jr+R1XEAXGqEfl6dzBqQchDTHMoMaEnbkkCJTWPjK7M=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZdHAMFgnhAvWl4qCaozSGC8ZoljjEYi6VBP 70IoZTx452JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXQAKCRDa6OEJdZac 5bQgEACXrVy4PI0RHLf3EYbpFdgeh/G/qw9Szqqn90QJFXbDyFtQmp3c6wFtAFWSP3ffrhRIGOr RcUHeYkCVoyizAcDDgjI8OyPrmHVEnG3PwXeWRtGK0kH1my0bbmCJx/osVW8rApSvdzvYpi9s0Y 6bnxKKjw0JzliwdtFqTmFt0nn1S7YQOKfUDqhPgAWAHg8bwDPi1N1201GaF9lvKcJLYtaT4uNPx duB+KEvf23TePBMMCkwNlGjW5qm6S0gf5Ryxjb7UDLk0DAMDD6sOLYbUwrlEcS2bJu7T+7pz3Pk KIUx9WJmwNr8hA510xbEUM7U+qI4jtLtBszuvBioYQI3kVmqBqcaNtqPICXlIwOy+0b4xnL1Gkk eA26OvbARkhRxfm9CnY4bEgdMJQoeQnDOu1qzkbjiH5164V7Vey/w6iyXw5kqW/vm1Sq08RW2k9 ICd329fnCbR+neChTSaunOu2wlSsKfBfb8AHGJDPC9l+G08VUaWeDhOHfuAgrke7NLVPatk+RPO Idq2+9q621/0Y/k95lzrzNRBGYp6P2uo1GlxLYcHglKAYZo/Cej2Jt8gBe7Gw+Qz351rWqwXcvm 8YX+kB6Z2Q3knEFy4SolR3NudeuK7WGfrFsryom7DUjqSDf2dGK5/LD4kxH5aflGMGZmB0moZnG LnhWzV1mrbEwmtw== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: mRP8Zf2jinq8Tnm-_d0gupfXADqfnbadxFEyOdcGcts_1792493508 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1792493518-660A82AC-05C22CCB/0/0 X-purgate-type: clean X-purgate-size: 6528 Move PCSouthBridgeOption from a hand-rolled C enum to a proper QAPI enum in qapi/machine.json. This gives the x-south-bridge property a generated type_info with a valid masked_name, so it appears in query-qmp-schema introspection and the qapi-type field of qom-list-properties output. The south_bridge/default_south_bridge fields change from const char * to PCSouthBridgeOption, with an explicit mapping table from enum value to QOM device type name. Enum values are changed: "PIIX3"->"ppix3", "piix4-isa"->"piix4", this is under a x-property, so shouldn't be a breaking change. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/i386/pc_piix.c | 61 ++++++++++++++++------------------------------------ include/hw/i386/pc.h | 4 ++-- qapi/machine.json | 14 ++++++++++++ 3 files changed, 34 insertions(+), 45 deletions(-) diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 63c4667ea372..5a94a34166d8 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -47,6 +47,7 @@ #include "hw/acpi/acpi.h" #include "hw/vfio/types.h" #include "qapi/error.h" +#include "qapi/qapi-type-infos-machine.h" #include "qemu/error-report.h" #include "system/xen.h" #ifdef CONFIG_XEN @@ -75,6 +76,11 @@ static GlobalProperty pc_piix_compat_defaults[] = { static const size_t pc_piix_compat_defaults_len = G_N_ELEMENTS(pc_piix_compat_defaults); +static const char *pc_south_bridge_type[] = { + [PC_SOUTH_BRIDGE_OPTION_PIIX3] = TYPE_PIIX3_DEVICE, + [PC_SOUTH_BRIDGE_OPTION_PIIX4] = TYPE_PIIX4_PCI_DEVICE, +}; + /* * Return the global irq number corresponding to a given device irq * pin. We could also use the bus number to have a more precise mapping. @@ -236,7 +242,8 @@ static void pc_init1(MachineState *machine, const char *pci_type) gsi_state = pc_gsi_create(&x86ms->gsi, true); - pci_dev = pci_new_multifunction(-1, pcms->south_bridge); + pci_dev = pci_new_multifunction(-1, + pc_south_bridge_type[pcms->south_bridge]); object_property_set_bool(OBJECT(pci_dev), "has-usb", machine_usb(machine), &error_abort); object_property_set_bool(OBJECT(pci_dev), "has-acpi", @@ -317,51 +324,18 @@ static void pc_init1(MachineState *machine, const char *pci_type) } } -typedef enum PCSouthBridgeOption { - PC_SOUTH_BRIDGE_OPTION_PIIX3, - PC_SOUTH_BRIDGE_OPTION_PIIX4, - PC_SOUTH_BRIDGE_OPTION_MAX, -} PCSouthBridgeOption; - -static const QEnumLookup PCSouthBridgeOption_lookup = { - .array = (const char *const[]) { - [PC_SOUTH_BRIDGE_OPTION_PIIX3] = TYPE_PIIX3_DEVICE, - [PC_SOUTH_BRIDGE_OPTION_PIIX4] = TYPE_PIIX4_PCI_DEVICE, - }, - .size = PC_SOUTH_BRIDGE_OPTION_MAX -}; - static int pc_get_south_bridge(Object *obj, Error **errp) { PCMachineState *pcms = PC_MACHINE(obj); - int i; - for (i = 0; i < PCSouthBridgeOption_lookup.size; i++) { - if (g_strcmp0(PCSouthBridgeOption_lookup.array[i], - pcms->south_bridge) == 0) { - return i; - } - } - - error_setg(errp, "Invalid south bridge value set"); - return 0; + return pcms->south_bridge; } static void pc_set_south_bridge(Object *obj, int value, Error **errp) { PCMachineState *pcms = PC_MACHINE(obj); - if (value < 0) { - error_setg(errp, "Value can't be negative"); - return; - } - - if (value >= PCSouthBridgeOption_lookup.size) { - error_setg(errp, "Value too big"); - return; - } - - pcms->south_bridge = PCSouthBridgeOption_lookup.array[value]; + pcms->south_bridge = value; } #ifdef CONFIG_XEN @@ -398,7 +372,7 @@ static void pc_i440fx_machine_options(MachineClass *m) { PCMachineClass *pcmc = PC_MACHINE_CLASS(m); ObjectClass *oc = OBJECT_CLASS(m); - pcmc->default_south_bridge = TYPE_PIIX3_DEVICE; + pcmc->default_south_bridge = PC_SOUTH_BRIDGE_OPTION_PIIX3; pcmc->pci_root_uid = 0; pcmc->default_cpu_version = 1; @@ -413,12 +387,13 @@ static void pc_i440fx_machine_options(MachineClass *m) machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE); machine_class_allow_dynamic_sysbus_dev(m, TYPE_UEFI_VARS_X64); - object_class_property_add_enum(oc, "x-south-bridge", "PCSouthBridgeOption", - &PCSouthBridgeOption_lookup, - pc_get_south_bridge, - pc_set_south_bridge); - object_class_property_set_description(oc, "x-south-bridge", - "Use a different south bridge than PIIX3"); + object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( + .name = "x-south-bridge", + .description = "Use a different south bridge than PIIX3", + .qapi_type = &PCSouthBridgeOption_type_info, + .get = pc_get_south_bridge, + .set = pc_set_south_bridge, + )); compat_props_add(m->compat_props, pc_piix_compat_defaults, pc_piix_compat_defaults_len); } diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index 8edec62a1af2..3afd376116b1 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -47,7 +47,7 @@ typedef struct PCMachineState { uint64_t max_ram_below_4g; OnOffAuto vmport; SmbiosEntryPointType smbios_entry_point_type; - const char *south_bridge; + PCSouthBridgeOption south_bridge; bool acpi_build_enabled; bool wdat_enabled; @@ -94,7 +94,7 @@ struct PCMachineClass { /* Device configuration: */ bool pci_enabled; - const char *default_south_bridge; + PCSouthBridgeOption default_south_bridge; /* Compat options: */ diff --git a/qapi/machine.json b/qapi/machine.json index 46b6935ab0b8..cc028e890ae5 100644 --- a/qapi/machine.json +++ b/qapi/machine.json @@ -462,6 +462,20 @@ { 'enum': 'Pca9554PinState', 'data': ['low', 'high'] } +## +# @PCSouthBridgeOption: +# +# South bridge chipset option for PC i440FX machines. +# +# @piix3: Intel PIIX3 (default) +# +# @piix4: Intel PIIX4 +# +# Since: 11.2 +## +{ 'enum': 'PCSouthBridgeOption', + 'data': ['piix3', 'piix4'] } + ## # @inject-nmi: # Injects a Non-Maskable Interrupt (machine specific: for example -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:57:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:57:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455400.1669372 (Exim 4.92) (envelope-from ) id 1xJ7XZ-0006dY-BH; Tue, 20 Oct 2026 10:57:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455400.1669372; Tue, 20 Oct 2026 10: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 1xJ7XX-0006YW-Um; Tue, 20 Oct 2026 10:57:55 +0000 Received: by outflank-mailman (input) for mailman id 1455400; Tue, 20 Oct 2026 10:52:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Rr-0000QK-Oj for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:52:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Rr-00Cs6S-5Y for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:52:03 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747c7-2eae-0a2a0a5409dd-0a2a450aeb62-20 for ; Tue, 20 Oct 2026 12:52:02 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad747d1-f2d2-0a2a450a0019-aa0a857c70d3-3 for ; Tue, 20 Oct 2026 12:52: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-328-LUDw3GgDOriOUgUPMvJZCA-1; Tue, 20 Oct 2026 10:51:57 +0000 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 55CF01955BD4; Tue, 20 Oct 2026 10:51:53 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7054130000E7; Tue, 20 Oct 2026 10:51: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=1792493521; 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=ccOsUIeVtpZ4LAvRKvLPIKBLjfW8xoZv/G7l+9bsArM=; b=WhsqAkxH0SNuRK4xGo4qzxY0VZiHxLB3d15AKr0ers9RqTQDtzZE1r7RFWRA0s4YWS2amp QbHHU0bZYjYKarsjihX0DDeUaQBRV+VfaskQJUHxrE70LSoEI1S1O6jvJRANGKusym9Cxc jYoSaVFOpNqLsW6Xz3meiMc5E4cVhtY= X-MC-Unique: LUDw3GgDOriOUgUPMvJZCA-1 X-Mimecast-MFC-AGG-ID: LUDw3GgDOriOUgUPMvJZCA_1792493513 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:20 +0400 Subject: [PATCH v7 63/65] qom: remove old enum property registration API MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-63-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=7342; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=4DUVOH2Il1uXarwapsGNw4Sqxi5JL+XRDYj5v/DxTXw=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZdSCtnqLwFsuDwikbI6gRflGPZtD05w5lEa CvQaDVyJvKJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXQAKCRDa6OEJdZac 5VbJEACAn2E9Fh4lFMReVrd4NHuC3naIFHBUIw5ZLoxN7mbcaqivG69WFWxx7ZOrTDRmg/G7yWj fDJpczz3Mb0e0IfqafD0Zo52HRprrS3vQqsPJaRNSQkXu2fm6LC1O8aSPWSYAU1eanghk9OhXWy YrwTj+hC9ewJZHcH2F93rQKIhbccNRiQPCGgJPy4Lrq/uTwsScJ1VwIlavz58EMOc8D5pLsrqcC yq0g6DK4SrNPSK30qRc1DYPDZzDv6UP/6SYl4MOl80b/lEg9HtMa3nOcPYat73Xrz4lJ34zsyq2 DaiEjhshxRzeWlxSRKFBlCtFXeclBqDgqyY/wXjt1O7g+q+UUKYGqmFXdH3HZHF2a0DzqVUoNpl 4FKV2A5wr9Y9wmy+YIR0Lnw3Te8+UkuWx8TJu4UGPD64J7Am8Zdr+5lc4k63v3MIxbJ3V6i3/gx xcPgIxzQ2tjUAC413GKGiKMZihOU5ca3wMMcT+SurJ4f6AckLphRseXIw6lV64r07VMlIt2v/on t/KCYg7F6sIRLgxf7Q8rsFrDB/0o+lW42EJjrEKIKBVNwdsoxM+4Tc7BWJ7ciCx3ovDWcgc+b9G Z8i3KE57kVIhAV2xKZSycVzEGQWVUjJagDqkIlSLS/+8A/FeLV/wYW0PQJQEo9s4t45BXPSFjoI Q65g0nQz/0Olqvw== 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: ZNlu8c_XsVBjatgHBS589vF0V6iHwYWNrGnKpXSs3Gs_1792493513 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1792493522-589C9CFC-ACD03AEC/0/0 X-purgate-type: clean X-purgate-size: 7344 Now that all callers use object_class_property_add_qapi_enum(), remove the legacy object_property_add_enum() and object_class_property_add_enum() functions along with their EnumProperty struct and property_get_enum / property_set_enum helpers. Simplify object_property_get_enum() to assert on qapi_type rather than falling back to the old EnumProperty opaque data. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- include/qom/object.h | 45 ++-------------------------- qom/object.c | 82 ++-------------------------------------------------- 2 files changed, 4 insertions(+), 123 deletions(-) diff --git a/include/qom/object.h b/include/qom/object.h index 29cbd84b8d03..a9bbc44cfcc9 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -1697,12 +1697,12 @@ char *object_get_canonical_path(const Object *obj); * because it was ambiguous, or %NULL. Set to %false on success. * * There are two types of supported paths--absolute paths and partial paths. - * + * * Absolute paths are derived from the root object and can follow child<> or * link<> properties. Since they can follow link<> properties, they can be * arbitrarily long. Absolute paths look like absolute filenames and are * prefixed with a leading slash. - * + * * Partial paths look like relative filenames. They do not begin with a * prefix. The matching rules for partial paths are subtle but designed to make * specifying objects easy. At each level of the composition tree, the partial @@ -1986,47 +1986,6 @@ ObjectProperty *object_class_property_add_bool(ObjectClass *klass, bool (*get)(Object *, Error **), void (*set)(Object *, bool, Error **)); -/** - * object_property_add_enum: - * @obj: the object to add a property to - * @name: the name of the property - * @typename: the name of the enum data type - * @lookup: enum value namelookup table - * @get: the getter or %NULL if the property is write-only. - * @set: the setter or %NULL if the property is read-only - * - * Add an enum property using getters/setters. This function will add a - * property of type '@typename'. - * - * Returns: The newly added property on success, or %NULL on failure. - */ -ObjectProperty *object_property_add_enum(Object *obj, const char *name, - const char *typename, - const QEnumLookup *lookup, - int (*get)(Object *, Error **), - void (*set)(Object *, int, Error **)); - -/** - * object_class_property_add_enum: - * @klass: the object class to add a property to - * @name: the name of the property - * @typename: the name of the enum data type - * @lookup: enum value namelookup table - * @get: the getter or %NULL if the property is write-only. - * @set: the setter or %NULL if the property is read-only - * - * Add an enum property using getters/setters. This function will add a - * property of type '@typename'. - * - * Returns: The newly added property on success, or %NULL on failure. - */ -ObjectProperty *object_class_property_add_enum(ObjectClass *klass, - const char *name, - const char *typename, - const QEnumLookup *lookup, - int (*get)(Object *, Error **), - void (*set)(Object *, int, Error **)); - /** * struct QapiEnumProp: Descriptor for a property backed by a QAPI enum type * diff --git a/qom/object.c b/qom/object.c index cf18880c6c0c..791d981dc689 100644 --- a/qom/object.c +++ b/qom/object.c @@ -1774,12 +1774,6 @@ uint64_t object_property_get_uint(Object *obj, const char *name, return retval; } -typedef struct EnumProperty { - const QEnumLookup *lookup; - int (*get)(Object *, Error **); - void (*set)(Object *, int, Error **); -} EnumProperty; - int object_property_get_enum(Object *obj, const char *name, const char *typename, Error **errp) { @@ -1803,12 +1797,8 @@ int object_property_get_enum(Object *obj, const char *name, return -1; } - if (prop->qapi_type) { - ret = qapi_enum_parse(prop->qapi_type->lookup, str, -1, errp); - } else { - EnumProperty *enumprop = prop->opaque; - ret = qapi_enum_parse(enumprop->lookup, str, -1, errp); - } + assert(prop->qapi_type); + ret = qapi_enum_parse(prop->qapi_type->lookup, str, -1, errp); g_free(str); return ret; @@ -2543,74 +2533,6 @@ object_class_property_add_bool(ObjectClass *klass, const char *name, prop); } -static void property_get_enum(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - EnumProperty *prop = opaque; - int value; - Error *err = NULL; - - value = prop->get(obj, &err); - if (err) { - error_propagate(errp, err); - return; - } - - visit_type_enum(v, name, &value, prop->lookup, errp); -} - -static void property_set_enum(Object *obj, Visitor *v, const char *name, - void *opaque, Error **errp) -{ - EnumProperty *prop = opaque; - int value; - - if (!visit_type_enum(v, name, &value, prop->lookup, errp)) { - return; - } - prop->set(obj, value, errp); -} - -ObjectProperty * -object_property_add_enum(Object *obj, const char *name, - const char *typename, - const QEnumLookup *lookup, - int (*get)(Object *, Error **), - void (*set)(Object *, int, Error **)) -{ - EnumProperty *prop = g_malloc(sizeof(*prop)); - - prop->lookup = lookup; - prop->get = get; - prop->set = set; - - return object_property_add(obj, name, typename, - get ? property_get_enum : NULL, - set ? property_set_enum : NULL, - property_release_data, - prop); -} - -ObjectProperty * -object_class_property_add_enum(ObjectClass *klass, const char *name, - const char *typename, - const QEnumLookup *lookup, - int (*get)(Object *, Error **), - void (*set)(Object *, int, Error **)) -{ - EnumProperty *prop = g_malloc(sizeof(*prop)); - - prop->lookup = lookup; - prop->get = get; - prop->set = set; - - return object_class_property_add(klass, name, typename, - get ? property_get_enum : NULL, - set ? property_set_enum : NULL, - NULL, - prop); -} - static void get_qapi_enum(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) { -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:58:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:58:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455402.1669382 (Exim 4.92) (envelope-from ) id 1xJ7Xb-00070O-UP; Tue, 20 Oct 2026 10:57:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455402.1669382; Tue, 20 Oct 2026 10:57: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 1xJ7XZ-0006qd-JO; Tue, 20 Oct 2026 10:57:57 +0000 Received: by outflank-mailman (input) for mailman id 1455402; Tue, 20 Oct 2026 10:52:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7Rw-0000Qr-PE for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:52:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7Rw-00CvpI-5z for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:52:08 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747d8-8faa-0a2a0a5109dd-0a2a450cb766-0 for ; Tue, 20 Oct 2026 12:52:08 +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 6ad747d6-f479-0a2a450c0019-aa0a817caceb-3 for ; Tue, 20 Oct 2026 12:52:07 +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-607-UkF2cxSIP0KFpD-x2kfPug-1; Tue, 20 Oct 2026 10:52:03 +0000 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 171B41955DE8; Tue, 20 Oct 2026 10:51:59 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D26A65BC; Tue, 20 Oct 2026 10:51: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=1792493526; 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=edIbxy8j0ZeLmK0JPM910tAFzYTrVmN4a79XoyzsTPs=; b=XWLOffIqp0dzfMN7npTE8ln70l0mHDaJQ4YaNJRInktXlCaBxNhmbyBVPhyAV6otDDtdZy SGBHj4GLBUSArH6Iom+X3eSUe1sm1Jj0316wi3U4uAgDVTXTIztlHtKwQV/ossAe8gzT6w DXMxUDvxjwkY5B0h7ZOJsOZASue9/7c= X-MC-Unique: UkF2cxSIP0KFpD-x2kfPug-1 X-Mimecast-MFC-AGG-ID: UkF2cxSIP0KFpD-x2kfPug_1792493519 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:21 +0400 Subject: [PATCH v7 64/65] qom: use QAPITypeInfo in object_property_get_enum MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-64-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=4777; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=btPOLigegMrUtE/H8gDPhCCZC+0Be3DpIj2amZiGpeM=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZdBPk60N5wT01axiLdb48ZwuPjCejnM2ZCc 8PglQD+RAWJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXQAKCRDa6OEJdZac 5SPyEAC5HRZ0r0eZqxI5kzCsHrclz4H0Z1qTSRRBggURJDWP1KPYcglKwzX4001DDcIq+3FTVpq uqL6jJTS5vpJyJyR897eCp/+/txzLU8tlhsslIoDbOhlREexjvA38cJU7R22vQlvcx+DpICRHE3 a5XvP5h0s1/Pyiwdap+iMevEvuEEcbH/jRuSHep2d8iVv7Koi8q0iUC8zZ9PuwSKBiXi/oILGfy aiMrs8f/RgP9W/MoV3ZQRoFzC+PDRjFuTVfcaA60kq0BkbXlZZqC8u7Z+II9Xx+mxD8jpqF0dvl YdxYl9iXw3cbjdx662K6DNPPTjQqlqch+lUyD9IDKGSOxwMVRZODMwFtKF8oOvp/VlJSjSI2dYp n/X+gSwpl4DPtL64HznEe7j1fcGEq0YFRHnDbDHbwuxtIa57jCuK6wDAdaarfxUiuLtPfX7zXKA 1mhzw7Xk53JCYfVRtyhDDwz68cwocztkSeDoHbr+rWIMtJWAgR3K0ZgRcwpuhUoaQpp7LtkUpd6 SttTn4wc4MNuYc4Awpzamcf3DaIFaC+EQhFDU5i9gl+OPJb5rstVcuwsDzcleSXgUaDrqgSpCQo Bgm5lkNrnrlf7BG0h6WM3CgbBEadCmph3q1159HTgqfLA36QI7zt946mDEQrtiXWNDke3TZA+Wo l6wkFmd77J6ABag== 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: 1QqciViunR43AoID7g27I24Nvg6AtEsZPSRbmjCdOo0_1792493519 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1792493527-01EC2A5B-1FD9F548/0/0 X-purgate-type: clean X-purgate-size: 4779 The typename parameter becomes a QAPITypeInfo pointer, and the validation compares prop->qapi_type against it instead of matching prop->type strings. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/machine-qmp-cmds.c | 4 +++- include/qom/object.h | 4 ++-- qom/object.c | 8 ++++---- tests/unit/check-qom-proplist.c | 6 +++--- 4 files changed, 12 insertions(+), 10 deletions(-) diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c index 3fee45d568da..6b425baeb2da 100644 --- a/hw/core/machine-qmp-cmds.c +++ b/hw/core/machine-qmp-cmds.c @@ -18,6 +18,7 @@ #include "qapi/qapi-commands-accelerator.h" #include "qapi/qapi-commands-machine.h" #include "qobject/qobject.h" +#include "qapi/qapi-type-infos-common.h" #include "qapi/qobject-input-visitor.h" #include "qapi/type-helpers.h" #include "qemu/uuid.h" @@ -252,7 +253,8 @@ static int query_memdev(Object *obj, void *opaque) } else { m->has_reserve = true; } - m->policy = object_property_get_enum(obj, "policy", "HostMemPolicy", + m->policy = object_property_get_enum(obj, "policy", + &HostMemPolicy_type_info, &error_abort); host_nodes = object_property_get_qobject(obj, "host-nodes", diff --git a/include/qom/object.h b/include/qom/object.h index a9bbc44cfcc9..9f937e30dae5 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -1566,7 +1566,7 @@ uint64_t object_property_get_uint(Object *obj, const char *name, * object_property_get_enum: * @obj: the object * @name: the name of the property - * @typename: the name of the enum data type + * @type_info: the QAPITypeInfo of the enum * @errp: returns an error if this function fails * * Returns: the value of the property, converted to an integer (which @@ -1574,7 +1574,7 @@ uint64_t object_property_get_uint(Object *obj, const char *name, * value is not an enum). */ int object_property_get_enum(Object *obj, const char *name, - const char *typename, Error **errp); + const QAPITypeInfo *type_info, Error **errp); /** * object_property_set: diff --git a/qom/object.c b/qom/object.c index 791d981dc689..40b569d4d574 100644 --- a/qom/object.c +++ b/qom/object.c @@ -1775,7 +1775,7 @@ uint64_t object_property_get_uint(Object *obj, const char *name, } int object_property_get_enum(Object *obj, const char *name, - const char *typename, Error **errp) + const QAPITypeInfo *type_info, Error **errp) { char *str; int ret; @@ -1785,10 +1785,10 @@ int object_property_get_enum(Object *obj, const char *name, return -1; } - if (!g_str_equal(prop->type, typename)) { + if (prop->qapi_type != type_info) { error_setg(errp, "Property %s on %s is not '%s' enum type", - name, object_class_get_name( - object_get_class(obj)), typename); + name, object_class_get_name(object_get_class(obj)), + type_info->name); return -1; } diff --git a/tests/unit/check-qom-proplist.c b/tests/unit/check-qom-proplist.c index 69155e720751..1cb48c7490ef 100644 --- a/tests/unit/check-qom-proplist.c +++ b/tests/unit/check-qom-proplist.c @@ -582,14 +582,14 @@ static void test_dummy_getenum(void) val = object_property_get_enum(OBJECT(dobj), "av", - "DummyAnimal", + &dummy_animal_qapi_type_info, &error_abort); g_assert(val == DUMMY_PLATYPUS); /* A bad enum type name */ val = object_property_get_enum(OBJECT(dobj), "av", - "BadAnimal", + &dummy_str_qapi_type_info, &err); g_assert(val == -1); error_free_or_abort(&err); @@ -597,7 +597,7 @@ static void test_dummy_getenum(void) /* A non-enum property name */ val = object_property_get_enum(OBJECT(dobj), "iv", - "DummyAnimal", + &dummy_animal_qapi_type_info, &err); g_assert(val == -1); error_free_or_abort(&err); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 10:58:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 10:58:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455404.1669390 (Exim 4.92) (envelope-from ) id 1xJ7Xd-0007Nt-BV; Tue, 20 Oct 2026 10:58:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455404.1669390; Tue, 20 Oct 2026 10: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 1xJ7Xb-0007D8-BS; Tue, 20 Oct 2026 10:57:59 +0000 Received: by outflank-mailman (input) for mailman id 1455404; Tue, 20 Oct 2026 10:52:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7S1-0000RO-VR for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 10:52:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7S1-00Cs6O-Bb for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 12:52:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad747dd-e002-0a2a0a5209dd-0a2a45068648-0 for ; Tue, 20 Oct 2026 12:52:13 +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 6ad747dc-195a-0a2a45060019-aa0a857cab35-3 for ; Tue, 20 Oct 2026 12:52:13 +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-460-7pgMjRlDPJm6ek2MrAPphA-1; Tue, 20 Oct 2026 10:52:08 +0000 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 0A12B1954ACE; Tue, 20 Oct 2026 10:52:04 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 81B4630000E7; Tue, 20 Oct 2026 10:52: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=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=1792493532; 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=Cht00yUtxWZgYYGvkiDrdQx2K2tPqKneM6BMi8EBSe8=; b=JaiHpW5pNptVTLB7kq5Loz5RYWsz0iErLrcBMQyuIH2NKRp/XtwXC0Fo8kcAcKMTa/GByy PXiWvaEOgXNT6N/xpromKLPXwbMAYgPHHoMCaJ9WvKZifDD4qmpMYHnULwOqwM7crvzIpE FkkBzsY6OxL878kJyet2CGiWhQwacI0= X-MC-Unique: 7pgMjRlDPJm6ek2MrAPphA-1 X-Mimecast-MFC-AGG-ID: 7pgMjRlDPJm6ek2MrAPphA_1792493524 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:22 +0400 Subject: [PATCH v7 65/65] tests/qmp-cmd-test: assert qapi-type resolves in query-qmp-schema MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-65-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=3522; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=d0AC/pqR2xkFHzouOcdpk0rfewmoRKNngAyjCDgTMl8=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZdBKSnHJPBpmcmbmASu7qOtoUGXTowk7yNX g+tgxS9nNCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXQAKCRDa6OEJdZac 5YaTD/9vG9jkAEkIZLFzUN64FilSwr9riDSC6dE2d/cUhX4cjMjxDVeEJE3fOoiBKvDHuHP6Fam eLESfFQfsqJcKbQZcC7fZwpUyYgAah0Te7HBf1dTcZEFTRvKN74njWw41ZqG0c7tTwK2RvnjIsK 8fHHImBlQjy3IQpEa+tkvQUC4iH8rw0sZLyrCG2YcdoTu7W+WXDLexUk2cOs0ruBPuwoKzJNY0h kfSjtPXCqWAYW/CLE/XAxTIg0npoHuOEJsdHN2vFua1QGpata7fM9WvmMdkxxN/mTWXE368BfaR SefydRBG8ysGItK2Wa42Jka1iFQCJauQfgYfzHLKFuwYgNDhmVGREedy/FHX4FKrmlFt+/DTCBT WQqkUunveY9WHZTah8Oyc6HQu217yOg1Pu1mzdUOKA7L5efOGeeF2VXLU4xx8F0cI3x9n1w2m9S ZjD8AIg2GEOQSHZTOHmvLShHGgZeqbIHmzkuVPwP9Uu0Xvd4oFkSUdsv018jZzRlsuC1WZ19WVs HwVfX09lvPTKCeCW/MnPJHOy4Jz9YIZOrueZvIMglgwQcZOoG8zo20m3HJUDkc4M1fhIN0xN5GX +pxjl6niKchvnstVDhaDerpY/9nebfmNnSTV8sMRAPUBnvklXn1847TNA0iuqTN+Qp24h+XOk0a iSGRIgq7QkVJWcA== 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: QGr1tgqQxZy1zMlcyfZ_8mAsnv1CZVgTP_7M39yeS5A_1792493524 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1792493533-FE27077B-F57D7AFD/0/0 X-purgate-type: clean X-purgate-size: 3524 For every QOM type returned by qom-list-types, call qom-list-properties and verify that each property's qapi-type value (when present) maps to a valid entry in the query-qmp-schema introspection output. The test is gated behind g_test_slow() since it iterates all registered QOM types. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- tests/qtest/qmp-cmd-test.c | 55 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/tests/qtest/qmp-cmd-test.c b/tests/qtest/qmp-cmd-test.c index 279a8f5614e9..acb7b0dd6a9f 100644 --- a/tests/qtest/qmp-cmd-test.c +++ b/tests/qtest/qmp-cmd-test.c @@ -15,6 +15,7 @@ #include "qapi/error.h" #include "qapi/qapi-visit-introspect.h" #include "qobject/qdict.h" +#include "qobject/qlist.h" #include "qapi/qobject-input-visitor.h" const char common_args[] = "-nodefaults -machine none"; @@ -131,6 +132,8 @@ typedef struct { GHashTable *hash; } QmpSchema; +static QmpSchema schema; + static void qmp_schema_init(QmpSchema *schema) { QDict *resp; @@ -343,9 +346,56 @@ static void test_object_add_failure_modes(void) qtest_quit(qts); } +static void test_qapi_type(void) +{ + QTestState *qts; + g_autoptr(QDict) resp = NULL; + QList *types; + QListEntry *type_entry, *prop_entry; + + qts = qtest_init(common_args); + + resp = qtest_qmp(qts, + "{ 'execute': 'qom-list-types'," + " 'arguments': { 'abstract': true } }"); + g_assert(qdict_haskey(resp, "return")); + types = qdict_get_qlist(resp, "return"); + + QLIST_FOREACH_ENTRY(types, type_entry) { + QDict *type = qobject_to(QDict, qlist_entry_obj(type_entry)); + const char *name = qdict_get_str(type, "name"); + g_autoptr(QDict) props_resp = NULL; + QList *props; + + props_resp = qtest_qmp(qts, + "{ 'execute': 'qom-list-properties'," + " 'arguments': { 'typename': %s } }", + name); + if (!qdict_haskey(props_resp, "return")) { + continue; + } + props = qdict_get_qlist(props_resp, "return"); + + QLIST_FOREACH_ENTRY(props, prop_entry) { + QDict *prop = qobject_to(QDict, qlist_entry_obj(prop_entry)); + const char *qapi_type = qdict_get_try_str(prop, "qapi-type"); + const char *propname = qdict_get_str(prop, "name"); + const char *ty = qdict_get_str(prop, "type"); + + if (qapi_type) { + g_assert_nonnull(qmp_schema_lookup(&schema, qapi_type)); + } else if (!g_str_has_prefix(ty, "child<") && + !g_str_has_prefix(ty, "link<")) { + g_test_message("%s.%s %s has no associated qapi-type", + name, propname, ty); + } + } + } + qtest_quit(qts); +} + int main(int argc, char *argv[]) { - QmpSchema schema; int ret; g_test_init(&argc, &argv, NULL); @@ -355,6 +405,9 @@ int main(int argc, char *argv[]) qtest_add_func("qmp/object-add-failure-modes", test_object_add_failure_modes); + if (g_test_slow()) { + qtest_add_func("qmp/qapi-type", test_qapi_type); + } ret = g_test_run(); -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 11:11:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 11:11:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455720.1669430 (Exim 4.92) (envelope-from ) id 1xJ7kE-0003D7-L6; Tue, 20 Oct 2026 11:11:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455720.1669430; Tue, 20 Oct 2026 11:11: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 1xJ7kE-0003D0-He; Tue, 20 Oct 2026 11:11:02 +0000 Received: by outflank-mailman (input) for mailman id 1455720; Tue, 20 Oct 2026 11:02:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ7bn-0008OX-SI for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 11:02:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ7bm-006PAc-Qe for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:02:18 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad74a38-bab6-0a2a0a5309dd-0a2a4501e376-4 for ; Tue, 20 Oct 2026 13:02:18 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad747a4-5984-0a2a45010019-aa0a857cda4f-3 for ; Tue, 20 Oct 2026 12:51: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-330-D7y_ed00OAaymLbt3bjJCQ-1; Tue, 20 Oct 2026 10:51:11 +0000 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 BC19B18011FD; Tue, 20 Oct 2026 10:51:06 +0000 (UTC) Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D664E30002CD; Tue, 20 Oct 2026 10:51: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=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=1792493476; 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=AzOqWKFaDt1dcUvSh5TH4ogfAdXt1H3DxJt5OXlYfGQ=; b=HFuZItCjPMvWDVAA2LRECwoTBqQ2YclwZwTnLUaV/HO96sBrU6Hs4xzTwwbKRTUEWmIhwr MuhW0C7mu0kqJk/cQSSsgsblCZX3NmgfrPHMshpIz4maIzJEhky/j94J4zrP/5UU2DtXyQ XwvXn1YrRPQ5L6oYDQcVU3Bb8VZwQk0= X-MC-Unique: D7y_ed00OAaymLbt3bjJCQ-1 X-Mimecast-MFC-AGG-ID: D7y_ed00OAaymLbt3bjJCQ_1792493466 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Tue, 20 Oct 2026 14:46:11 +0400 Subject: [PATCH v7 54/65] qdev: adjust PciDevfn declared type MIME-Version: 1.0 Message-Id: <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= X-Developer-Signature: v=1; a=openpgp-sha256; l=1182; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=Rc9Kn1ykFR1030A/T3Qsw/MLRtZoT0IcFryuHUpEgHo=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBq10ZcBKB9OckTgPDc5ceinUI9Ks8T8mQpbSHjR wt32qduSASJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCatdGXAAKCRDa6OEJdZac 5UlxD/0aesvLeJMhDPNK4VKMeyOaPPsCQtFR4qFG7KlCXynT1T2vJymf0cc0GzQxvMuqQi7QkP3 Nq+vx1h0wS8aWYock4+0cMRoNcvRyjdcEIEaz+hY9fYszOClGXo+WgnVvXIP/ymzT6wOrtEm8zi KyTeNOPlbml9T8xE5XCRMCuRDYgQQ/C50LkGOdvWZPi4/QPg61NcRcEdwgwyKWGA//4KF53Etv9 YF57/ckC+h0DIpVltVP7DozmL6yMRAQhvvbN/k7Wvocf991FXI4FBBQjx3DjWlI02TWx1ZbTHj7 Ul0nCa4y4Trxncc4kvuErZYreWkXTb3OM10IrtqT0Cxjebhspuf6b49Tpbr3s/b8iiX9czsUwXA p89Q53jzV6hkwxaqFNslKASETfvPDs+MhV9lykZnoFlxSdUnXT9X0E7aN2lUv3YRzxnc6Jff11W T3pb97gVWEOi/Odv9Mpm+kqrjqMdiRufTDS9y2rm+bzyC4oRVO5awihl+6ojLB1OJGVVwkwc7rQ Zbl0T+Ercm3AhwHa5/RMvPncaAuJqvWSIsEqW1vouhls8x0QJ+F7U8ndzLr4k1Xw79jazen5h9J arXpcL+C7MupGvk2Kx7ddRWgG+DbBn8bd6xO139DIRMT2by8ApQ+rFpyVEq/Uj7YjDAk1NxdvS0 GHFEBLCP2lMK0Ow== 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: NJ-3ncSn2vE7Prz85pQtfhUlzqAXJomnRWHo0pDlABk_1792493466 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792493477-1D67C757-544D5596/0/0 X-purgate-type: clean X-purgate-size: 1184 PciDevfn is a bit special, since it accepts integer and string as setter, but only output integer as getter. Unfortunately, we can't declare an alternate str|int QAPI type for it, since: branch 'string' can't be distinguished from 'integer' Rather than declaring it as "str", use the common type instead. Signed-off-by: Markus Armbruster Signed-off-by: Marc-André Lureau --- hw/core/qdev-properties-system.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c index 5bfdfe1ab9d9..3381de1144d6 100644 --- a/hw/core/qdev-properties-system.c +++ b/hw/core/qdev-properties-system.c @@ -904,7 +904,8 @@ static char *print_pci_devfn(Object *obj, const Property *prop) } const PropertyInfo qdev_prop_pci_devfn = { - .type = "str", + /* The formatted string accepted by the setter is a CLI convenience. */ + .type = "int32", .description = "Slot and optional function number, example: 06.0 or 06", .print = print_pci_devfn, .get = qdev_propinfo_get_int32, -- 2.56.0.116.g6de20f6092dc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:52:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:52:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455864.1669484 (Exim 4.92) (envelope-from ) id 1xJAFw-00087i-9a; Tue, 20 Oct 2026 13:51:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455864.1669484; Tue, 20 Oct 2026 13:51: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 1xJAFw-00087b-6F; Tue, 20 Oct 2026 13:51:56 +0000 Received: by outflank-mailman (input) for mailman id 1455864; Tue, 20 Oct 2026 13:51:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAFv-00087V-I9 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:51:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAFu-000Nqf-KV for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:51:54 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad771e9-e002-0a2a0a5209dd-0a2a450cd07c-46 for ; Tue, 20 Oct 2026 15:51: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 6ad771fa-f479-0a2a450c0019-b9ff1c239a47-3 for ; Tue, 20 Oct 2026 15:51: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 1a1599536d8000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 13:51:53 +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 B19D781B2E; Tue, 20 Oct 2026 15:51:52 +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=V/75RGEsEtsnGU0WXZZ1cfYHm88H7Kn4+IVIKtQ72gs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=KD1sJHUp/bXfc44bpo/lHAHdYMNZl9scFKteurpItYe1RsjdA+Rs8Zm4FTw4LDqTT/w3MebEQ lQlpjA8yLaZouXmFahhA/8szgEmKiASUw34JYBsKM+F0PJ9tqjPvIMeswhR/juF/pd9Ayt0wJc8 IZclNdbNtV+htKK84EOXQ3O95ehoKy5D3utn8DHJ7zU6sB+GSaI9Q2rVtne5xLNgk01lckEB4Zd xINV09kkLIiIF8R+rkZJGTZWy9Fls/JwzNChDDLtfWvCYdJeImnnu2TfSoAlOTbpV442QTOVVYH A8Bxc4GqyhaN5HK5WWZVuMj0ruI+9Be7XtZHPjvj4/+g== X-Zone-Loop: 671e7958a7aa0ce540cab0847f881048ba669b876407 x-campaign-type: default x-transaction-id: 0eba7c7b-3dfb-4a5d-a90c-4665a9e4109c x-swg-uid: 01-2cab2f36-0015-4fcc-99f3-87e8e0d7996b X-Mailer: Sweego Message-ID: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> x-swg-bid: 1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f 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?= , Denis Mukhin Subject: [PATCH 0/6] vmx/apicv: APICv and IOMMU posted interrupt improvements Date: Tue, 20 Oct 2026 15:51:30 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.4e.2f29739024001b1f.1a15995342f.4ef697d52e3f951c=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792504312884 X-purgate-ID: tlsNG-d25034/1792504314-52132A5B-079F7333/0/0 X-purgate-type: clean X-purgate-size: 1605 ---=Part.4e.2f29739024001b1f.1a15995342f.4ef697d52e3f951c=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Various improvements around APICv/iommu-intpost found by Claude Fable (and Opus)=2E Some of the APICv bugfixes makes APICv behavior align better with emulated lapic=2E Testing shows that "Don't lose posted interrupts while SN=3D1" vastly improves VT-d interrupt posting reliability=2E I guess there's more stuff to fix (especially around comments), but that's probably a good start=2E I'm not sure how the current HVM infra around interrupt posting fits with AMD AVIC=2E Feedback welcome=2E Teddy Astie (6): vmx/apicv: Fix vmx_pi_hooks_assign() comment x86/vlapic: Fix hardware virtualized APIC state after reset vmx/apicv: Don't lose posted interrupts while SN=3D1 vmx/apicv: Fully deassign the PI hooks when the last device is removed vmx/apicv: Replace the PI_CSW_{FROM,TO} flags with a boolean vmx/apicv: Don't defer RVI update when an event is pending injection xen/arch/x86/hvm/vlapic=2Ec | 43 ++++++- xen/arch/x86/hvm/vmx/intr=2Ec | 11 +- xen/arch/x86/hvm/vmx/vmx=2Ec | 159 ++++++++++++++++--------- xen/arch/x86/include/asm/hvm/domain=2Eh | 3 +- xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh | 5 + 5 files changed, 160 insertions(+), 61 deletions(-) --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.4e.2f29739024001b1f.1a15995342f.4ef697d52e3f951c=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:53:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:53:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455874.1669496 (Exim 4.92) (envelope-from ) id 1xJAHl-0000os-Qc; Tue, 20 Oct 2026 13:53:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455874.1669496; Tue, 20 Oct 2026 13:53: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 1xJAHl-0000ol-Ni; Tue, 20 Oct 2026 13:53:49 +0000 Received: by outflank-mailman (input) for mailman id 1455874; Tue, 20 Oct 2026 13:53:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAHk-0000l2-Bv for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:53:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAHj-000OEO-Oy for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:53:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad77256-2eae-0a2a0a5409dd-0a2a45048eb8-40 for ; Tue, 20 Oct 2026 15:53:47 +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 6ad7726b-b57f-0a2a45040019-b9ff1c239605-4 for ; Tue, 20 Oct 2026 15:53: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a15996ec68000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 13:53:45 +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 03BAE81B3D; Tue, 20 Oct 2026 15:53: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=Jzn2Zb5AruTQT8qiLJh0Qy0tL9MdFQryxCPUXJhgofU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=iflqUXi55gbQp4tGeRaqjKdwE63QEsMRAvyj27+MP37KmImgL2usmAjZ2BL+Sxo01F74kvYNx G1GfiJCwkjFObNQA7hH21qGilszC/uBSdTKbSLoVm/FFI7UprgWnyqdV0bHC10ehhshOBx5PEBR jUOQvU7uOm9c9gTBxaNqHmDYnd5Y9K8ojbEe1z2+TWJiu1f+CeIuLkkJzuGoHOmZKUVNir2/S4C ezyAjmvYKN2mP8Vtwl1xNZ/hjIpkYumtvf0T3Qy5AbPuSy4xfiZDIiAs2ZnRSeomCaAtF1X615Z bNtwffJXvV8SBTP3Nbs4QwgFm4rqgiKH61h0q+ExGUdw== X-Zone-Loop: 9bf5e49e3ab031e257e0c47c9c9906eef8e3b333d314 x-campaign-type: default x-transaction-id: 9440ae8c-5708-4f88-a4cd-7fe259f11341 x-swg-uid: 01-f5b8cd32-22ff-4cc6-a5a6-e3ae76b95927 X-Mailer: Sweego Message-ID: <1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f@vates.tech> x-swg-bid: 1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f 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?= , Denis Mukhin Subject: [PATCH 2/6] x86/vlapic: Fix hardware virtualized APIC state after reset Date: Tue, 20 Oct 2026 15:53:29 +0200 In-Reply-To: <20261020135333.38064-2-teddy.astie@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.51.2171014568280812.1a15996eabf.261fe5f835c35f94=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792504425151 X-purgate-ID: tlsNG-ebf023/1792504427-536C2B50-D91D0DFB/0/0 X-purgate-type: clean X-purgate-size: 7029 ---=Part.51.2171014568280812.1a15996eabf.261fe5f835c35f94=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are various issues in the current vlapic logic handling reset - SVI and RVI aren't reset, and GUEST_INTR_STATUS is not updated appropriately - stale PIR bits are merged into fresh IRR Fixes: d7dafa375bc1 ("VMX: Add posted interrupt supporting") Signed-off-by: Teddy Astie Assisted-by: Claude Fable 5=2E1 --- While the change looks fine to me, I feel some of the comments are too Intel-centric, and not sure how them apply to AMD AVIC=2E --- xen/arch/x86/hvm/vlapic=2Ec | 43 ++++++++++++++++++++++++++++++++++---- xen/arch/x86/hvm/vmx/vmx=2Ec | 30 ++++++++++++++++++++------ 2 files changed, 63 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/hvm/vlapic=2Ec b/xen/arch/x86/hvm/vlapic=2Ec index 885f5d304b=2E=2E53f8907640 100644 --- a/xen/arch/x86/hvm/vlapic=2Ec +++ b/xen/arch/x86/hvm/vlapic=2Ec @@ -68,6 +68,7 @@ static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM= ] =3D =3D=3D APIC_TIMER_MODE_TSC_DEADLINE) =20 static void vlapic_do_init(struct vlapic *vlapic); +static void vlapic_reset_hw_state(struct vlapic *vlapic); =20 static int vlapic_find_highest_vector(const void *bitmap) { @@ -277,6 +278,7 @@ static void vlapic_init_sipi_one(struct vcpu *target, = uint32_t icr) { case APIC_DM_INIT: { int rc; + struct vlapic *vlapic =3D vcpu_vlapic(target); =20 /* No work on INIT de-assert for P4-type APIC=2E */ if ( (icr & (APIC_INT_LEVELTRIG | APIC_INT_ASSERT)) =3D=3D @@ -290,7 +292,8 @@ static void vlapic_init_sipi_one(struct vcpu *target, = uint32_t icr) /* Reset necessary VCPU state=2E This does not include FPU state= =2E */ rc =3D vcpu_reset(target); ASSERT(!rc); - vlapic_do_init(vcpu_vlapic(target)); + vlapic_do_init(vlapic); + vlapic_reset_hw_state(vlapic); domain_unlock(target->domain); break; } @@ -1429,6 +1432,13 @@ static void vlapic_do_init(struct vlapic *vlapic) if ( !has_vlapic(vlapic_vcpu(vlapic)->domain) ) return; =20 + /* + * Drain the posted interrupt descriptor (and clear its ON bit) befor= e + * zeroing the IRR, so that vectors posted before the reset don't get + * merged into the fresh IRR by a later sync=2E + */ + hvm_sync_pir_to_irr(vlapic_vcpu(vlapic)); + vlapic_set_reg(vlapic, APIC_LVR, VLAPIC_VERSION); =20 for ( i =3D 0; i < 8; i++ ) @@ -1462,8 +1472,26 @@ static void vlapic_do_init(struct vlapic *vlapic) destroy_periodic_time(&vlapic->pt); } =20 -/* Reset the VLAPIC back to its power-on/reset state=2E */ -void vlapic_reset(struct vlapic *vlapic) +/* + * Bring hardware accelerated APIC state (on VMX: RVI, SVI and the EOI-ex= it + * bitmap) back in line with the just reset registers=2E Hardware derive= s the + * virtual PPR from SVI and delivers virtual interrupts based on RVI with= out + * consulting the IRR, so leaving them stale after a reset would block + * subsequent interrupts, or inject a vector which isn't pending at all= =2E + */ +static void vlapic_reset_hw_state(struct vlapic *vlapic) +{ + struct vcpu *v =3D vlapic_vcpu(vlapic); + + if ( !has_vlapic(v->domain) ) + return; + + if ( hvm_funcs=2Eprocess_isr ) + alternative_vcall(hvm_funcs=2Eprocess_isr, -1, v); +} + +/* Reset the VLAPIC registers back to their power-on/reset state=2E */ +static void vlapic_reset_regs(struct vlapic *vlapic) { const struct vcpu *v =3D vlapic_vcpu(vlapic); =20 @@ -1478,6 +1506,13 @@ void vlapic_reset(struct vlapic *vlapic) vlapic_do_init(vlapic); } =20 +/* Reset the VLAPIC back to its power-on/reset state=2E */ +void vlapic_reset(struct vlapic *vlapic) +{ + vlapic_reset_regs(vlapic); + vlapic_reset_hw_state(vlapic); +} + /* rearm the actimer if needed, after a HVM restore */ static void lapic_rearm(struct vlapic *s) { @@ -1705,7 +1740,7 @@ int vlapic_init(struct vcpu *v) =20 clear_page(vlapic->regs); =20 - vlapic_reset(vlapic); + vlapic_reset_regs(vlapic); =20 tasklet_init(&vlapic->init_sipi=2Etasklet, vlapic_init_sipi_action, v= ); =20 diff --git a/xen/arch/x86/hvm/vmx/vmx=2Ec b/xen/arch/x86/hvm/vmx/vmx=2Ec index 31bb094d6f=2E=2Eb655075c17 100644 --- a/xen/arch/x86/hvm/vmx/vmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vmx=2Ec @@ -2194,10 +2194,10 @@ static void cf_check vmx_update_eoi_exit_bitmap( vmx_clear_eoi_exit_bitmap(v, vector); } =20 -static u8 set_svi(int isr) +static uint8_t set_svi(int isr) { unsigned long status; - u8 old; + uint8_t old; =20 if ( isr < 0 ) isr =3D 0; @@ -2216,12 +2216,14 @@ static u8 set_svi(int isr) =20 static void cf_check vmx_process_isr(int isr, struct vcpu *v) { - unsigned int i; + unsigned int i, rvi =3D 0; + unsigned long status; const struct vlapic *vlapic =3D vcpu_vlapic(v); =20 vmx_vmcs_enter(v); =20 - set_svi(isr); + /* Rebuild the EOI-exit bitmap from scratch, dropping stale entries= =2E */ + bitmap_zero(v->arch=2Ehvm=2Evmx=2Eeoi_exit_bitmap, X86_IDT_VECTORS); =20 /* * Theoretically, only level triggered interrupts can have their @@ -2237,13 +2239,29 @@ static void cf_check vmx_process_isr(int isr, stru= ct vcpu *v) * bitmap correctly=2E */ for ( i =3D 0x10; i < X86_IDT_VECTORS; ++i ) - if ( vlapic_test_vector(i, &vlapic->regs->data[APIC_IRR]) || - vlapic_test_vector(i, &vlapic->regs->data[APIC_ISR]) ) + { + if ( vlapic_test_vector(i, &vlapic->regs->data[APIC_IRR]) ) + { + set_bit(i, v->arch=2Ehvm=2Evmx=2Eeoi_exit_bitmap); + rvi =3D i; + } + else if ( vlapic_test_vector(i, &vlapic->regs->data[APIC_ISR]) ) set_bit(i, v->arch=2Ehvm=2Evmx=2Eeoi_exit_bitmap); + } =20 for ( i =3D 0; i < ARRAY_SIZE(v->arch=2Ehvm=2Evmx=2Eeoi_exit_bitmap);= ++i ) __vmwrite(EOI_EXIT_BITMAP(i), v->arch=2Ehvm=2Evmx=2Eeoi_exit_bitm= ap[i]); =20 + /* + * Hardware delivers virtual interrupts based on RVI alone, without + * looking at the IRR, and derives the virtual PPR from SVI=2E Both = must + * therefore reflect the register contents: RVI is the highest pendin= g + * vector (0 if none), SVI the highest in-service one (0 if none)=2E + */ + status =3D MASK_INSR(rvi, VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK) | + ((isr < 0 ? 0 : isr) << VMX_GUEST_INTR_STATUS_SVI_OFFSET); + __vmwrite(GUEST_INTR_STATUS, status); + vmx_vmcs_exit(v); } =20 --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.51.2171014568280812.1a15996eabf.261fe5f835c35f94=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:53:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:53:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455873.1669493 (Exim 4.92) (envelope-from ) id 1xJAHl-0000lN-Js; Tue, 20 Oct 2026 13:53:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455873.1669493; Tue, 20 Oct 2026 13:53: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 1xJAHl-0000lG-G9; Tue, 20 Oct 2026 13:53:49 +0000 Received: by outflank-mailman (input) for mailman id 1455873; Tue, 20 Oct 2026 13:53:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAHk-0000l0-4x for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:53:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAHj-000OEO-Hs for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:53:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad77256-2eae-0a2a0a5409dd-0a2a45048eb8-38 for ; Tue, 20 Oct 2026 15:53:47 +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 6ad7726b-b57f-0a2a45040019-b9ff1c239605-3 for ; Tue, 20 Oct 2026 15:53: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a15996e4a1000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 13:53:43 +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 E68C981DC6; Tue, 20 Oct 2026 15:53: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=AseNajs4Y9qMRyP5C5A3ZVOpuHAa0rbWW9c3ZzHzWdc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=XkI2Ctz0owm5ma6LQWlUwD5vNHV2ELZxBW2k/ZRPlPGlehlhpm/SJphbLFQSGbRv7UbKpOuC9 7vdCcTk+G1T2g3Nt4wo0K3l9GffFDEKtTDWNK7xG2+ZNMOvr5TUzDQDUioM+F4ysUlL3GbPFrIN tChobmibJpo+NXUXU51orfirDIbs8DzRDNvwdI0vjInGDjMn9Su2JZJsT+hrOtgiJm+y9q1q9Mv EXkWzuPK+5KN2M8iwR8kPTIookogZc8pNs4WxB5hJJDEAGWZsbuA54lwakvGPA3sIBSVfFpZf3n 84Fphe14deqNt/x39KblNQyKM1cxLxb2bZw7XvRhzm2g== X-Zone-Loop: 5afb56d1d6191fe3a3cd5aeae8a4fb3362370dae2c53 x-campaign-type: default x-transaction-id: 85bbb5a4-388b-4694-8677-56c91771da51 x-swg-uid: 01-b329dbe7-8122-4151-afde-0bad1826fe16 X-Mailer: Sweego Message-ID: <1792504423.8631fc262581453bbf619ec5b2062170.1a15996e4a1000f79f@vates.tech> x-swg-bid: 1792504423.8631fc262581453bbf619ec5b2062170.1a15996e4a1000f79f 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 1/6] vmx/apicv: Fix vmx_pi_hooks_assign() comment Date: Tue, 20 Oct 2026 15:53:28 +0200 In-Reply-To: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.50.bd4b6428bf971b7b.1a15996e29a.4413b678a157b37f=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792504423067 X-purgate-ID: tlsNG-ebf023/1792504427-516D2B50-8FCC1CB9/0/0 X-purgate-type: clean X-purgate-size: 2357 ---=Part.50.bd4b6428bf971b7b.1a15996e29a.4413b678a157b37f=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When the VM is preempted/offline, we're looking to suppress the notification (as we're going to resume the guest later on, processing any pending interrupt) to avoid needlessy processing interrupts in Xen=2E That behavior is actually SN=3D1 and not SN=3D0 (which makes Xen process interrupts)=2E Fixes: 4b759ce163f4 ("vmx: VT-d posted-interrupt core logic handling") Signed-off-by: Teddy Astie --- So it now matches what docs/misc/vtd-pi=2Etxt says=2E 3=2E When vCPU is preempted or sleeping - Set 'SN' to suppress non-urgent interrupts (Currently, we only support non-urgent interrupts) When vCPU is preempted or sleep, it doesn't need to accept posted-interrupt notification event since we don't change the behavi= or of scheduler when the interrupt occurs, we still need wait for the n= ext scheduling of the vCPU=2E When external interrupts from assigned dev= ices occur, the interrupts are recorded in PIR, and will be synced to IRR before= VM-Entry=2E - Set 'NV' to 'posted_intr_vector'=2E xen/arch/x86/hvm/vmx/vmx=2Ec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx=2Ec b/xen/arch/x86/hvm/vmx/vmx=2Ec index 3c7374a9ff=2E=2E31bb094d6f 100644 --- a/xen/arch/x86/hvm/vmx/vmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vmx=2Ec @@ -303,7 +303,7 @@ void vmx_pi_desc_fixup(unsigned int cpu) * If the VM is currently either preempted or offline (i=2Ee=2E, not run= ning * because of some reason other than blocking waiting for an interrupt), * there's nothing Xen can do -- we want the interrupt pending bit set i= n - * the guest, but we don't want to bother Xen with an interrupt (SN clea= r)=2E + * the guest, but we don't want to bother Xen with an interrupt (SN set)= =2E * * There's a brief window of time between vmx_intr_assist() and checking * softirqs where if an interrupt comes in it may be lost; so we need Xen --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.50.bd4b6428bf971b7b.1a15996e29a.4413b678a157b37f=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:53:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:53:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455875.1669509 (Exim 4.92) (envelope-from ) id 1xJAHo-0001C6-25; Tue, 20 Oct 2026 13:53:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455875.1669509; Tue, 20 Oct 2026 13:53: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 1xJAHn-0001Bz-VP; Tue, 20 Oct 2026 13:53:51 +0000 Received: by outflank-mailman (input) for mailman id 1455875; Tue, 20 Oct 2026 13:53:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAHm-0000uN-DM for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:53:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAHl-005FUj-IZ for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:53:49 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7725c-e002-0a2a0a5209dd-0a2a4502d836-46 for ; Tue, 20 Oct 2026 15:53:49 +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 6ad7726d-6ca4-0a2a45020019-b9ff1c128e0d-3 for ; Tue, 20 Oct 2026 15:53: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 1a15996ef22000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 13:53:46 +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 B5B4681B3D; Tue, 20 Oct 2026 15:53: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: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=/deWJryXA3ZF7Y0BOA32Mgf1VnUaFf1YaZyFGD1qmCk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=sqC4oCCPBkMboVAzBGKtajiIAMmATtl73leMFHbvePXDeLfE8pfY/cJ2DbC4aQgKZeuQs+nm4 vRV5KEHXvnnu8Dok6xzfTFaHsxZP+UwpLZjV0nyLulOiyM5589pMyP52meVzw3ni/7YdpjW/oJj XXpLX8RcC17O7NACQGzGvTxdgaeivccNhEjaWQBlC0X+Vql1JiF8X1bh2RDxjXcQT2CCD4x37TU OLR8sbV0IloVjUdv54PZznLLaUyV7VI48tRuAOhmRqfv3DVR3Y4D2AN2jiGIin2kdgq2e/TWo0a sYHQ36QppGuGeQ85DMLpa+OArCkfnfDWFlFlR8FZ1quA== X-Zone-Loop: d196853433b765c3c1afad803641a07d3ef65a2b3fa2 x-campaign-type: default x-transaction-id: 2d585555-4420-44ca-99be-e5a28922ed1d x-swg-uid: 01-09dee455-4875-43c1-a2f4-7562d1d7dcfb X-Mailer: Sweego Message-ID: <1792504426.8631fc262581453bbf619ec5b2062170.1a15996ef22000f79f@vates.tech> x-swg-bid: 1792504426.8631fc262581453bbf619ec5b2062170.1a15996ef22000f79f 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/6] vmx/apicv: Don't lose posted interrupts while SN=1 Date: Tue, 20 Oct 2026 15:53:30 +0200 In-Reply-To: <20261020135333.38064-2-teddy.astie@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.52.2f4fad2419199ce5.1a15996ed88.6a4f53c2a2bf26a6=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792504425864 X-purgate-ID: tlsNG-720697/1792504429-F20A82AC-BBF27547/0/0 X-purgate-type: clean X-purgate-size: 8911 ---=Part.52.2f4fad2419199ce5.1a15996ed88.6a4f53c2a2bf26a6=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When a vCPU is descheduled, vmx_pi_switch_from() sets SN so the IOMMU doesn't notify a pCPU the vCPU isn't running on=2E For non-urgent interrupts the IOMMU then records the vector in the PIR but neither sets ON nor sends a notification (VT-d spec "Interrupt-Posting Hardware Operation")=2E vmx_deliver_posted_intr() mirrored that and refused to set ON while SN was set=2E vmx_sync_pir_to_irr() however uses ON as its "PIR needs scanning" gate, and hardware only processes the PIR upon receipt of the notification vector, never at VM entry=2E Clearing SN in vmx_pi_switch_to() therefore left such vectors parked in the PIR until an unrelated posting happened to set ON=2E A re-posting of the same vector doesn't help either, as the early pi_test_and_set_pir() return skips the ON logic altogether=2E Set ON when clearing SN if the PIR is non-empty, as KVM does, and have the software path always set ON: SN has no bearing on it, since __vmx_deliver_posted_interrupt() already refrains from IPIing a vCPU that isn't running=2E vmx_pi_desc_fixup() sets SN around moving blocked vCPUs between pCPU lists and had the same window, so handle it there too by waking the vCPU as the existing ON case does=2E Only affect systems where iommu=3Dintpost is enabled=2E Fixes: 4b759ce163f4 ("vmx: VT-d posted-interrupt core logic handling") Fixes: 7c00de17562e ("VMX: permanently assign PI hook vmx_pi_switch_to()")= " Assisted-by: Claude Fable 5=2E1 Signed-off-by: Teddy Astie --- xen/arch/x86/hvm/vmx/vmx=2Ec | 93 +++++++++++++++----------- xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh | 5 ++ 2 files changed, 60 insertions(+), 38 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx=2Ec b/xen/arch/x86/hvm/vmx/vmx=2Ec index b655075c17=2E=2E3d77d77534 100644 --- a/xen/arch/x86/hvm/vmx/vmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vmx=2Ec @@ -151,6 +151,21 @@ static void vmx_pi_switch_to(struct vcpu *v) x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MA= SK)); =20 pi_clear_sn(pi_desc); + + /* + * Interrupts posted while SN was set (by the IOMMU for non-urgent + * interrupts, see VT-d spec 5=2E2=2E3) have their vector recorded in= the PIR + * but neither set ON nor generate a notification=2E vmx_sync_pir_to= _irr() + * uses ON as its "PIR needs scanning" indicator, and hardware only + * processes the PIR upon receipt of the notification vector, so such + * vectors would otherwise stay parked in the PIR until an unrelated + * posting sets ON=2E Set it ourselves if there is anything pending= =2E + * + * pi_clear_sn() is a locked operation and hence orders the PIR read + * after the SN clear=2E + */ + if ( !pi_is_pir_empty(pi_desc) ) + pi_set_on(pi_desc); } =20 static void vmx_pi_unblock_vcpu(struct vcpu *v) @@ -263,6 +278,18 @@ void vmx_pi_desc_fixup(unsigned int cpu) } =20 pi_clear_sn(&vmx->pi_desc); + + /* + * A posting which arrived while SN was set above has left its ve= ctor + * in the PIR without setting ON or notifying anyone=2E The vCPU= is on + * the new cpu's blocking list by now, so wake it up directly as = in + * the ON case; vmx_pi_unblock_vcpu() will take it off the list= =2E + */ + if ( !pi_is_pir_empty(&vmx->pi_desc) ) + { + pi_set_on(&vmx->pi_desc); + vcpu_unblock(container_of(vmx, struct vcpu, arch=2Ehvm=2Evmx)= ); + } } =20 spin_unlock_irqrestore(old_lock, flags); @@ -368,18 +395,17 @@ void vmx_pi_hooks_deassign(struct domain *d) domain_pause(d); =20 /* - * Note that we don't set 'd->arch=2Ehvm=2Epi_ops=2Eswitch_to' to NUL= L - * here=2E If we deassign the hooks while the vCPU is runnable in the - * runqueue with 'SN' set, all the future notification event will be - * suppressed since vmx_deliver_posted_intr() also use 'SN' bit - * as the suppression flag=2E Preserving the 'switch_to' hook functio= n can - * clear the 'SN' bit when the vCPU becomes running next time=2E Afte= r - * that, No matter which status(runnable, running or block) the vCPU = is in, - * the 'SN' bit will keep clear for the 'switch_from' hook function t= hat set - * the 'SN' bit has been removed=2E At that time, the 'switch_to' hoo= k function - * is also useless=2E Considering the function doesn't do harm to the= whole - * system, leave it here until we find a clean solution to deassign t= he - * 'switch_to' hook function=2E + * Note that we keep the 'switch_to' hook=2E Any vCPU which isn't bl= ocked + * has just been descheduled by domain_pause() with the 'switch_from' + * hook still in place, and hence has 'SN' set=2E Interrupts posted = by the + * IOMMU while 'SN' is set only have their vector recorded in the PIR= , + * without setting 'ON'=2E vmx_pi_switch_to() clears 'SN' and sets '= ON' + * if the PIR isn't empty, so that such vectors get delivered once th= e + * vCPU runs again=2E It also keeps 'NDST' up to date, which + * vmx_pi_hooks_assign() relies upon should a device get assigned aga= in=2E + * + * Once 'SN' is clear it stays clear, as nothing sets it anymore, and= the + * hook is redundant from then on=2E */ d->arch=2Ehvm=2Epi_ops=2Evcpu_block =3D NULL; d->arch=2Ehvm=2Epi_ops=2Eflags =3D PI_CSW_TO; @@ -2322,8 +2348,6 @@ static void __vmx_deliver_posted_interrupt(struct vc= pu *v) =20 static void cf_check vmx_deliver_posted_intr(struct vcpu *v, u8 vector) { - struct pi_desc old, new, prev; - if ( pi_test_and_set_pir(vector, &v->arch=2Ehvm=2Evmx=2Epi_desc) ) return; =20 @@ -2339,30 +2363,23 @@ static void cf_check vmx_deliver_posted_intr(struc= t vcpu *v, u8 vector) return; } =20 - prev=2Econtrol =3D v->arch=2Ehvm=2Evmx=2Epi_desc=2Econtrol; - - do { - /* - * Currently, we don't support urgent interrupt, all - * interrupts are recognized as non-urgent interrupt, - * Besides that, if 'ON' is already set, no need to - * send posted-interrupts notification event as well, - * according to hardware behavior=2E - */ - if ( pi_test_sn(&prev) || pi_test_on(&prev) ) - { - vcpu_kick(v); - return; - } - - old=2Econtrol =3D v->arch=2Ehvm=2Evmx=2Epi_desc=2Econtrol & - ~((1 << POSTED_INTR_ON) | (1 << POSTED_INTR_SN)); - new=2Econtrol =3D v->arch=2Ehvm=2Evmx=2Epi_desc=2Econtrol | - (1 << POSTED_INTR_ON); - - prev=2Econtrol =3D cmpxchg(&v->arch=2Ehvm=2Evmx=2Epi_desc=2Econtr= ol, - old=2Econtrol, new=2Econtrol); - } while ( prev=2Econtrol !=3D old=2Econtrol ); + /* + * Always set ON, irrespective of SN: ON is what vmx_sync_pir_to_irr(= ) + * keys off, so leaving it clear while SN is set would park the vecto= r in + * the PIR until an unrelated posting sets ON=2E SN only exists to s= top the + * IOMMU from notifying a pCPU the vCPU isn't running on; it has no + * bearing on the software path, where __vmx_deliver_posted_interrupt= () + * already refrains from sending an IPI to a vCPU that isn't running= =2E + * + * If ON was already set, whoever set it has taken care of the + * notification (or hardware will pick the vector up when it processe= s + * the pending notification), so a plain kick suffices=2E + */ + if ( pi_test_and_set_on(&v->arch=2Ehvm=2Evmx=2Epi_desc) ) + { + vcpu_kick(v); + return; + } =20 __vmx_deliver_posted_interrupt(v); } diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh b/xen/arch/x86/inclu= de/asm/hvm/vmx/vmx=2Eh index b7b8bc0c84=2E=2E7f286f8679 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh @@ -94,6 +94,11 @@ static inline int pi_test_pir(uint8_t vector, const str= uct pi_desc *pi_desc) return test_bit(vector, pi_desc->pir); } =20 +static inline bool pi_is_pir_empty(const struct pi_desc *pi_desc) +{ + return bitmap_empty(pi_desc->pir, X86_IDT_VECTORS); +} + static inline int pi_test_and_set_on(struct pi_desc *pi_desc) { return test_and_set_bit(POSTED_INTR_ON, &pi_desc->control); --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.52.2f4fad2419199ce5.1a15996ed88.6a4f53c2a2bf26a6=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:53:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:53:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455876.1669519 (Exim 4.92) (envelope-from ) id 1xJAHp-0001PR-CT; Tue, 20 Oct 2026 13:53:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455876.1669519; Tue, 20 Oct 2026 13:53: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 1xJAHp-0001PI-8v; Tue, 20 Oct 2026 13:53:53 +0000 Received: by outflank-mailman (input) for mailman id 1455876; Tue, 20 Oct 2026 13:53:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAHn-0001BY-Ah for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:53:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAHm-006xHp-NV for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:53:50 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7726e-8faa-0a2a0a5109dd-0a2a4506d652-2 for ; Tue, 20 Oct 2026 15:53:50 +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 6ad7726e-195a-0a2a45060019-b9ff1c228035-3 for ; Tue, 20 Oct 2026 15:53: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 1a15996f17b000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 13:53:46 +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 5494C82800; Tue, 20 Oct 2026 15:53: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=vrUdu5oSpf6Vj6QPP161AAKtUJ9o8bO5hOPV90BJ4jw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=TYLztz2EeJIqKeCYOv4Hh3mdaw958/fct1B61XIdMNdvq/Qg8ljs9+bE4BtMUP8R6/POcgLdP oW20VtWDAUUaIwVAAGNEWQEC7keJ6ruhn+8CVnlyXqNNorfJdEHwYVtctn3Syc4QoXXeE0qUtJ/ 5L3bTvy3TyWr9WWDorPJfKnMAz5tZvmC6+ss5//rZ3LXuCw5Tpga7HFzJZrpOnA8yztZgIKguuE y9TMAhRx/4E5OjrY64PhfatOpm8y9CrqkjgU6hbKJLe+r5HgH/7ngJ66cmSf6Au2/MJjpVSEP7S GlvztRTWnCf95/wvE72hMxBcsko02op/5vB2WC/vEYDQ== X-Zone-Loop: ee691cfd165b7a0a1d439529934b37b460714b35d009 x-campaign-type: default x-transaction-id: e05a6571-8663-4aac-960b-109bcc46efe3 x-swg-uid: 01-4c868f89-d915-4c6f-a9ba-6207317b3b40 X-Mailer: Sweego Message-ID: <1792504426.8631fc262581453bbf619ec5b2062170.1a15996f17b000f79f@vates.tech> x-swg-bid: 1792504426.8631fc262581453bbf619ec5b2062170.1a15996f17b000f79f 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 4/6] vmx/apicv: Fully deassign the PI hooks when the last device is removed Date: Tue, 20 Oct 2026 15:53:31 +0200 In-Reply-To: <20261020135333.38064-2-teddy.astie@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.53.532838114bc79f7e.1a15996efe2.5a4bdcc6f679e4cf=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792504426467 X-purgate-ID: tlsNG-16d1c6/1792504430-F647377B-69244FE4/0/0 X-purgate-type: clean X-purgate-size: 4480 ---=Part.53.532838114bc79f7e.1a15996efe2.5a4bdcc6f679e4cf=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable vmx_pi_hooks_deassign() has been keeping the 'switch_to' hook installed forever since 7c00de17562e, for it to clear SN when a vCPU which was descheduled with SN set runs again=2E It also has to set ON if anything got posted to the PIR while SN was set, as otherwise these vectors would stay parked in there=2E The domain is paused at that point, so there's no need to defer any of this to the next context switch: clear SN and set ON as needed right away, and drop PI_CSW_TO alongside PI_CSW_FROM=2E Without the hook, NDST isn't kept up to date anymore, so reset it to APIC_INVALID_DEST for vmx_pi_hooks_assign() to set it up again upon a later assignment, as it does for a freshly created vCPU=2E While at it, also wake up blocked vCPUs with ON set: vmx_pi_unblock_vcpu() resets NV to posted_intr_vector before taking the vCPU off the blocking list, so a posting landing in between is only notified to the pCPU, and nothing would wake the vCPU=2E Fixes: 7c00de17562e ("VMX: permanently assign PI hook vmx_pi_switch_to()") Assisted-by: Claude Opus 5=2E5 Signed-off-by: Teddy Astie --- We're removing the comment that the previous commit fixed=2E I'm not sure if that would be preferable to merge this one with the previous one=2E --- xen/arch/x86/hvm/vmx/vmx=2Ec | 46 ++++++++++++++++++++++++++------------ 1 file changed, 32 insertions(+), 14 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx=2Ec b/xen/arch/x86/hvm/vmx/vmx=2Ec index 3d77d77534=2E=2E6db2529730 100644 --- a/xen/arch/x86/hvm/vmx/vmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vmx=2Ec @@ -394,25 +394,43 @@ void vmx_pi_hooks_deassign(struct domain *d) ASSERT(current->domain !=3D d); domain_pause(d); =20 - /* - * Note that we keep the 'switch_to' hook=2E Any vCPU which isn't bl= ocked - * has just been descheduled by domain_pause() with the 'switch_from' - * hook still in place, and hence has 'SN' set=2E Interrupts posted = by the - * IOMMU while 'SN' is set only have their vector recorded in the PIR= , - * without setting 'ON'=2E vmx_pi_switch_to() clears 'SN' and sets '= ON' - * if the PIR isn't empty, so that such vectors get delivered once th= e - * vCPU runs again=2E It also keeps 'NDST' up to date, which - * vmx_pi_hooks_assign() relies upon should a device get assigned aga= in=2E - * - * Once 'SN' is clear it stays clear, as nothing sets it anymore, and= the - * hook is redundant from then on=2E - */ d->arch=2Ehvm=2Epi_ops=2Evcpu_block =3D NULL; - d->arch=2Ehvm=2Epi_ops=2Eflags =3D PI_CSW_TO; + d->arch=2Ehvm=2Epi_ops=2Eflags =3D 0; =20 for_each_vcpu ( d, v ) + { + struct pi_desc *pi_desc =3D &v->arch=2Ehvm=2Evmx=2Epi_desc; + vmx_pi_unblock_vcpu(v); =20 + /* + * Any vCPU which isn't blocked has just been descheduled by + * domain_pause() with the 'switch_from' hook still in place, and + * hence has 'SN' set=2E Nothing sets it anymore from now on, so= do + * what vmx_pi_switch_to() would have done when the vCPU next run= s: + * clear 'SN', and set 'ON' if anything got posted in the meantim= e=2E + */ + pi_clear_sn(pi_desc); + if ( !pi_is_pir_empty(pi_desc) ) + pi_set_on(pi_desc); + + /* + * A blocked vCPU may have had an interrupt posted after + * vmx_pi_unblock_vcpu() reset 'NV' to posted_intr_vector, and, n= ow + * that it is off the blocking list, nobody will wake it up=2E T= he + * domain is paused, so a spurious wakeup is harmless=2E + */ + if ( pi_test_on(pi_desc) ) + vcpu_unblock(v); + + /* + * Reset 'NDST' to its initial value, for vmx_pi_hooks_assign() t= o + * set it up again if a device gets assigned later on: without th= e + * 'switch_to' hook it isn't kept up to date anymore=2E + */ + write_atomic(&pi_desc->ndst, APIC_INVALID_DEST); + } + domain_unpause(d); } =20 --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.53.532838114bc79f7e.1a15996efe2.5a4bdcc6f679e4cf=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:53:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:53:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455877.1669524 (Exim 4.92) (envelope-from ) id 1xJAHp-0001S6-M9; Tue, 20 Oct 2026 13:53:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455877.1669524; Tue, 20 Oct 2026 13:53: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 1xJAHp-0001Qx-FN; Tue, 20 Oct 2026 13:53:53 +0000 Received: by outflank-mailman (input) for mailman id 1455877; Tue, 20 Oct 2026 13:53:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAHn-0001Bj-PM for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:53:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAHn-00DPue-5W for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:53:51 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7725a-bab6-0a2a0a5309dd-0a2a450ad0f6-28 for ; Tue, 20 Oct 2026 15:53:51 +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 6ad7726e-f2d2-0a2a450a0019-b9ff1c229ba3-3 for ; Tue, 20 Oct 2026 15:53: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a15996f3d5000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 13:53:47 +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 E2509828FB; Tue, 20 Oct 2026 15:53: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=rOr97SyIe1ugkipnvYhSxQQI1DhuRpLz45xbXvScgbs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=VHxUFMHZBiIazn2zsjKykn1dWxuUoK3V0ZcgnmZXnHyHlXZ7QS2d23QaQY1f5Po2z1v0F/5g8 eL0GDs7/BJcayv/Yizari/oFNDEgAMGlrWY3Y4MoHbAkU5KQRciqgmgQHWQGPzU/kAXegaDaR3s Ik7PLAMTjirg23UKIAXv7yCFtxTxDdEzjCAEE9qTKEU87+RCGNR6SD0rEfrf08fzkShE/55zYge KFgWXQ18Tey9fRMIWSmLIUyjNy1V7eDEdGowQaEjUrSBSXghKKTBZNxBWXlUOoUtuZdOuhpZbd4 qqK56STvUXHUBwQJO9rpdIQfphhySr4vLk+gakpZS5Nw== X-Zone-Loop: dc46f740da4673916ac0ec3ec48c17f15809093f1fc3 x-campaign-type: default x-transaction-id: 675e14d8-fd03-41c6-a789-bab1c5e22b23 x-swg-uid: 01-3b52d807-c2a2-4bd8-b272-d73a13f696a7 X-Mailer: Sweego Message-ID: <1792504427.8631fc262581453bbf619ec5b2062170.1a15996f3d5000f79f@vates.tech> x-swg-bid: 1792504427.8631fc262581453bbf619ec5b2062170.1a15996f3d5000f79f 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?= , Denis Mukhin Subject: [PATCH 5/6] vmx/apicv: Replace the PI_CSW_{FROM,TO} flags with a boolean Date: Tue, 20 Oct 2026 15:53:32 +0200 In-Reply-To: <20261020135333.38064-2-teddy.astie@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.54.2254fd81d8c2d8bd.1a15996f236.68412d95f7ba3d73=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792504427062 X-purgate-ID: tlsNG-4011c0/1792504431-506CECFC-ED568A79/0/0 X-purgate-type: clean X-purgate-size: 3526 ---=Part.54.2254fd81d8c2d8bd.1a15996f236.68412d95f7ba3d73=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Now that vmx_pi_hooks_deassign() no longer keeps the 'switch_to' hook around on its own, both context switch hooks are always enabled and disabled together, so there's no point in tracking them separately=2E A separate indicator is still needed rather than keying off pi_ops=2Evcpu_block: vmx_pi_hooks_assign() relies on the context switch hooks being active before NDST is set up and vcpu_block is installed=2E No functional change=2E Assisted-by: Claude Opus 5=2E5 Signed-off-by: Teddy Astie --- Does AVIC needs the previous split flags (FROM/TO) ? --- xen/arch/x86/hvm/vmx/vmx=2Ec | 12 ++++-------- xen/arch/x86/include/asm/hvm/domain=2Eh | 3 ++- 2 files changed, 6 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx=2Ec b/xen/arch/x86/hvm/vmx/vmx=2Ec index 6db2529730=2E=2E9ae77fe496 100644 --- a/xen/arch/x86/hvm/vmx/vmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vmx=2Ec @@ -74,10 +74,6 @@ static int cf_check vmx_msr_write_intercept( unsigned int msr, uint64_t msr_content); static void cf_check vmx_invlpg(struct vcpu *v, unsigned long linear); =20 -/* Values for domain's ->arch=2Ehvm_domain=2Epi_ops=2Eflags=2E */ -#define PI_CSW_FROM (1u << 0) -#define PI_CSW_TO (1u << 1) - struct vmx_pi_blocking_vcpu { struct list_head list; spinlock_t lock; @@ -357,7 +353,7 @@ void vmx_pi_hooks_assign(struct domain *d) * This can make sure the PI (especially the NDST feild) is * in proper state when we call vmx_vcpu_block()=2E */ - d->arch=2Ehvm=2Epi_ops=2Eflags =3D PI_CSW_FROM | PI_CSW_TO; + d->arch=2Ehvm=2Epi_ops=2Ectxt_switch =3D true; =20 for_each_vcpu ( d, v ) { @@ -395,7 +391,7 @@ void vmx_pi_hooks_deassign(struct domain *d) domain_pause(d); =20 d->arch=2Ehvm=2Epi_ops=2Evcpu_block =3D NULL; - d->arch=2Ehvm=2Epi_ops=2Eflags =3D 0; + d->arch=2Ehvm=2Epi_ops=2Ectxt_switch =3D false; =20 for_each_vcpu ( d, v ) { @@ -1198,7 +1194,7 @@ static void cf_check vmx_ctxt_switch_from(struct vcp= u *v) vmx_restore_host_msrs(); vmx_save_dr(v); =20 - if ( v->domain->arch=2Ehvm=2Epi_ops=2Eflags & PI_CSW_FROM ) + if ( v->domain->arch=2Ehvm=2Epi_ops=2Ectxt_switch ) vmx_pi_switch_from(v); } =20 @@ -1207,7 +1203,7 @@ static void cf_check vmx_ctxt_switch_to(struct vcpu = *v) vmx_restore_guest_msrs(v); vmx_restore_dr(v); =20 - if ( v->domain->arch=2Ehvm=2Epi_ops=2Eflags & PI_CSW_TO ) + if ( v->domain->arch=2Ehvm=2Epi_ops=2Ectxt_switch ) vmx_pi_switch_to(v); } =20 diff --git a/xen/arch/x86/include/asm/hvm/domain=2Eh b/xen/arch/x86/includ= e/asm/hvm/domain=2Eh index dd7fa96aad=2E=2Ee731096cc4 100644 --- a/xen/arch/x86/include/asm/hvm/domain=2Eh +++ b/xen/arch/x86/include/asm/hvm/domain=2Eh @@ -41,7 +41,8 @@ struct mem_sharing_domain * and actually has a physical device assigned =2E */ struct hvm_pi_ops { - unsigned int flags; + /* Run the PI hooks upon context switch=2E */ + bool ctxt_switch; =20 /* * Hook into arch_vcpu_block(), which is called --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.54.2254fd81d8c2d8bd.1a15996f236.68412d95f7ba3d73=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:53:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:53:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455878.1669529 (Exim 4.92) (envelope-from ) id 1xJAHq-0001Zg-1c; Tue, 20 Oct 2026 13:53:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455878.1669529; Tue, 20 Oct 2026 13:53: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 1xJAHp-0001XF-Rr; Tue, 20 Oct 2026 13:53:53 +0000 Received: by outflank-mailman (input) for mailman id 1455878; Tue, 20 Oct 2026 13:53:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAHn-0001Bp-TU for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:53:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAHn-00DPue-A1 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:53:51 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7726f-bab6-0a2a0a5309dd-0a2a4504e5d0-0 for ; Tue, 20 Oct 2026 15:53:51 +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 6ad7726b-b57f-0a2a45040019-b9ff1c239605-5 for ; Tue, 20 Oct 2026 15:53: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a15996f611000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 13:53:48 +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 7FE0182974; Tue, 20 Oct 2026 15:53: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=LhwuiXoRm7FVm1qXUDZ2mXBabDFJ1lqje8dUpkbOgZU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=PliB0PuTwt0yAFnxTQh7zRongHmtp+zYR4ojgtrAuQx04BwaCgw0gNlswd4QO5SMtG/wFP+VU KcqQNAJLgxZCvZzmzSrCi9hlh8/pPb7k8p18A3rQ1bdifExtbpguUWvnmjds1K9UZK8uq4uCn5g dq4vUP2YWSkJ0RiJZYtXhk0+sH2CVjKWKiOWxxkGHxKV9tLM25DkoVuhoLVjYgcEZy00lzfjOnv jNsZ/svo75DaBOKxjHsyAQkr5IeSOkTJZHoOp1eoSYuBD62/UsO7/kdeL2OrlhEZ34++oGW7NpM Vh4C5tmttE8HT5RM7mggjuPYiQ3dJTjIr/uMAV3uFFoQ== X-Zone-Loop: ca72812a9000b0c2908c4a75bc63ce8d9f05baafb266 x-campaign-type: default x-transaction-id: dc3d1a55-3d3d-4797-8931-07896c8acd9b x-swg-uid: 01-6da38972-d4f6-4a79-a76d-9ae108883a66 X-Mailer: Sweego Message-ID: <1792504428.8631fc262581453bbf619ec5b2062170.1a15996f611000f79f@vates.tech> x-swg-bid: 1792504428.8631fc262581453bbf619ec5b2062170.1a15996f611000f79f 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 6/6] vmx/apicv: Don't defer RVI update when an event is pending injection Date: Tue, 20 Oct 2026 15:53:33 +0200 In-Reply-To: <20261020135333.38064-2-teddy.astie@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.55.a4e302a0791dab0c.1a15996f47d.9b5b6e8e0fa63e90=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792504427645 X-purgate-ID: tlsNG-ebf023/1792504431-C14D3B50-9A59B25A/0/0 X-purgate-type: clean X-purgate-size: 2896 ---=Part.55.a4e302a0791dab0c.1a15996f47d.9b5b6e8e0fa63e90=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable With virtual interrupt delivery, vmx_intr_assist() bails out early when VM_ENTRY_INTR_INFO already holds an event to inject (e=2Eg=2E a re-injecte= d exception, or a #DB from single-stepping an emulated instruction)=2E For PIC, NMI and MCE sources it arms the interrupt window, so Xen gets another go once the event has been delivered=2E For LAPIC sources it does nothing, leaving RVI stale=2E Hardware only delivers virtual interrupts based on RVI, so a LAPIC vector which became pending in the same VM exit (synced from the PIR, or raised by the emulated instruction itself) isn't seen by the guest until some unrelated VM exit runs vmx_intr_assist() again=2E That can take an arbitrary amount of time if the guest doesn't exit; up to ~10ms was observed in testing=2E There is no need to wait: an event in VM_ENTRY_INTR_INFO doesn't prevent RVI from being updated, and hardware evaluates pending virtual interrupts once the injected event has been delivered=2E Only skip the early exit for LAPIC sources; the others still need VM_ENTRY_INTR_INFO themselves=2E Fixes: 25b81a7941d7 ("xen: enable Virtual-interrupt delivery") Signed-off-by: Teddy Astie Assisted-by: Claude Fable 5=2E1 --- xen/arch/x86/hvm/vmx/intr=2Ec | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/intr=2Ec b/xen/arch/x86/hvm/vmx/intr=2Ec index 6c220c4c2e=2E=2E85d8bfa31d 100644 --- a/xen/arch/x86/hvm/vmx/intr=2Ec +++ b/xen/arch/x86/hvm/vmx/intr=2Ec @@ -274,8 +274,17 @@ void asmlinkage vmx_intr_assist(void) goto out; } =20 + /* + * An event already queued for injection only gets in the way= of + * interrupts which need VM_ENTRY_INTR_INFO themselves=2E LA= PIC + * interrupts are delivered by hardware based on RVI, which c= an be + * updated regardless: the virtual interrupt is then recognis= ed + * once the injected event has been delivered, without needin= g a + * further VM exit for Xen to notice the pending vector=2E + */ __vmread(VM_ENTRY_INTR_INFO, &intr_info); - if ( intr_info & INTR_INFO_VALID_MASK ) + if ( (intr_info & INTR_INFO_VALID_MASK) && + intack=2Esource !=3D hvm_intsrc_lapic ) { if ( (intack=2Esource =3D=3D hvm_intsrc_pic) || (intack=2Esource =3D=3D hvm_intsrc_nmi) || --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.55.a4e302a0791dab0c.1a15996f47d.9b5b6e8e0fa63e90=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 13:57:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 13:57:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455912.1669547 (Exim 4.92) (envelope-from ) id 1xJALe-0004tS-FJ; Tue, 20 Oct 2026 13:57:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455912.1669547; Tue, 20 Oct 2026 13:57: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 1xJALe-0004tL-Ar; Tue, 20 Oct 2026 13:57:50 +0000 Received: by outflank-mailman (input) for mailman id 1455912; Tue, 20 Oct 2026 13:57:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJALd-0004ry-C0 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:57:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJALc-002pIB-LS for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:57:48 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad77350-bab6-0a2a0a5309dd-0a2a45049fc2-22 for ; Tue, 20 Oct 2026 15:57:48 +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 6ad7735c-b57f-0a2a45040019-d155dd30adfe-3 for ; Tue, 20 Oct 2026 15:57:48 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48e10a70540so1432350f8f.1 for ; Tue, 20 Oct 2026 06:57:48 -0700 (PDT) Received: from notebook.. ([88.230.43.46]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e1d8185d2sm6631984f8f.28.2026.10.20.06.57.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2026 06: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=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=1792504668; x=1793109468; 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=XLwEmqG5++2i0BaWFfhfUbwyKohnUHt/d5JgE82jxXk=; b=KsZV4Zhfm7GLoFpGzdCuwh6J/5UTTB2l4gACLgibOkjglyvkJ2+gw2+MDcBNBSgy+H JUQc+twy1efJh8goXBxx0Bvx4ktpe4GofMaHSlxKO96h9zXGYjDVcyUysALAvxIC7FHm xukL4eWc8zHJl78uW4dRJwOKrI7jrkKmqDF3E+WHIGxUKPTZvyV+8/VaXRave+D6bWty l14dnrBtyaXfwCbe1tHWDDpuoWzKduhBlEf3BlOoHAavgo90ry7ztkaXtUfj+6Us+PGz xK5s30/56EXO6fedptQNKTR1zSD5+UDQgju8JRt/T/yjqt8kZjRv+NpbyTTLBBMi6BKs K3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792504668; x=1793109468; 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=XLwEmqG5++2i0BaWFfhfUbwyKohnUHt/d5JgE82jxXk=; b=QZ3jGtmpu02d0ZTzSRTCm8iM+xawaPO+Y0bAtcB4yKWl/xiqsXEGlZRKbFX6ZvJriZ LDk35jF3EI8nReWjz5fIQ7EeV2FxUj5RE9pu8cJEQ0uCfxIujuGhqdSIjeM6yZ9NSnI9 Uyhkg+8uIVrVw2ti1VCXYzUs0Gs5G337JWEp13cFU63ptRzSrKcXf2sYGzKGSII2GNcV wyTk3Z6D3bTkeIhmfmPSOnFiBauOKTQn31SxEDZSbOp/bJ/xmsF6JW3IB9mfmafJGq/P O27tCRUJTbdXQGHUjoS522MdbinIumUg2KyG/jgDe913S/5GnDZllKQNXRtYrbdPzPiw LymA== X-Gm-Message-State: AFq9FYJSbtdYXV+WLpyhFU/mzWqWM/P+RxPzIRKDQbzNrUr7+nT3sQ1a Ryixn1kBaGxWBRi8eqYSjqLclOc7BIVXFr+wP0ntqX4NSDhnK24RmSejkpw5sQ== X-Gm-Gg: AYBFou2XE7TMLW0/Q2auV5m/PnrDZjHOvjkYxdX3rTBCrkX8hpwnO4IrGjwmRe7nkgD 2hasyA8OC70/5GLguYUHc2ll+dyxsYENPBZ11+QASa6aukcS6KfXH4/seYcs6xgmAjKQ5p5nHkm fWrPFjVenqsExVoCVTuWamCRl1ldprfF3+p6lNpYcOvhKF7iLmTGqohadlIAee6HyyAdCLu/+9p O6DLbkypCNV7RbsiagrRlhyJiNUegFy7xbE4DWegqZGCaxkJyArT2+lmczz2kIpb/+ZhLtdh/im duCwhYmf6VnIJ0N4NiPZ4Xu5jHQykskM23tB4L6wxKSbo+IMGIGoRKYsltoraga6/YfY739r3ih 7w4lp0IU7BVC2SI7KEhNqNMNRIAEwocf2UxaTIWEuNN2KKxJ3X0+hAl3ahYx79nNdW2eI47QsU8 K1oLmEEQ/eA53rCcTmLbvgoWUZsBCI3j9jI6f1nlBoCc+BcOzAbdqWo2t99o9ppwobD9K1 X-Received: by 2002:a05:6000:1050:b0:48d:ecba:3cf8 with SMTP id ffacd0b85a97d-48e07fa82f3mr15741818f8f.43.1792504667708; Tue, 20 Oct 2026 06:57:47 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, Furkan Caliskan Subject: [PATCH] x86/desc: build boot GDT descriptors with a macro Date: Tue, 20 Oct 2026 16:57:22 +0300 Message-Id: <20261020135722.45714-1-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792504668-585C7B50-B89637DF/0/0 X-purgate-type: clean X-purgate-size: 5396 The raw 64-bit constants in boot_gdt[] and boot_compat_gdt[] hide what each descriptor actually is. Replace them with a GDTE() macro, modelled on Linux's GDT_ENTRY_INIT(), plus named GDTE_FLAGS_* constants and a GDTE_FLAT() helper for flat segments. No functional change. Signed-off-by: Furkan Caliskan --- xen/arch/x86/desc.c | 61 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 48 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/desc.c b/xen/arch/x86/desc.c index 9f63928154..647affb6a3 100644 --- a/xen/arch/x86/desc.c +++ b/xen/arch/x86/desc.c @@ -27,32 +27,67 @@ #define SEL2GDT(sel) (((sel) >> 3) - FIRST_RESERVED_GDT_ENTRY) +/* + * Expands to a brace-enclosed initializer for seg_desc_t; only use it + * inside an initializer list. + * + * flags: bit layout matches its position in the descriptor's high dword + * bits 0-3 : type + * bit 4 : s (0 = system, 1 = code/data) + * bits 5-6 : dpl + * bit 7 : p (present) + * bit 12 : avl + * bit 13 : l (64-bit code segment) + * bit 14 : d/b + * bit 15 : g (granularity: 0 = byte, 1 = 4KiB) + */ +#define GDTE(flags, base, limit) \ + { (((uint64_t)(limit) & 0x0ffffULL) | \ + (((uint64_t)(base) & 0x0ffffffULL) << 16) | \ + (((uint64_t)(flags) & 0x0ffULL) << 40) | \ + (((uint64_t)(limit) & 0xf0000ULL) << 32) | \ + (((uint64_t)(flags) & 0xf000ULL) << 40) | \ + (((uint64_t)(base) & 0xff000000ULL) << 32)) } + +/* Common flag combinations (same values Linux uses for equivalent segments) */ +#define GDTE_FLAGS_RING0_CS64 0xa09b /* P DPL0 S code RX A, L, G */ +#define GDTE_FLAGS_RING0_DS32 0xc093 /* P DPL0 S data RW A, G */ +#define GDTE_FLAGS_RING1_CS32 0xc0bb /* P DPL1 S code RX A, G */ +#define GDTE_FLAGS_RING1_DS32 0xc0b3 /* P DPL1 S data RW A, G */ +#define GDTE_FLAGS_RING3_CS32 0xc0fb /* P DPL3 S code RX A, G */ +#define GDTE_FLAGS_RING3_DS32 0xc0f3 /* P DPL3 S data RW A, G */ +#define GDTE_FLAGS_RING3_CS64 0xa0fb /* P DPL3 S code RX A, L, G */ +#define GDTE_FLAGS_PERCPU 0x0091 /* P DPL0 S data RO A */ + +/* Xen maps every flat segment across all of memory. */ +#define GDTE_FLAT(flags) GDTE(flags, 0, 0xfffff) + __section(".data.page_aligned") __aligned(PAGE_SIZE) seg_desc_t boot_gdt[PAGE_SIZE / sizeof(seg_desc_t)] = { /* 0xe008 - Ring 0 code, 64bit mode */ - [SEL2GDT(__HYPERVISOR_CS)] = { 0x00af9b000000ffff }, + [SEL2GDT(__HYPERVISOR_CS)] = GDTE_FLAT(GDTE_FLAGS_RING0_CS64), /* 0xe010 - Ring 0 data */ - [SEL2GDT(__HYPERVISOR_DS32)] = { 0x00cf93000000ffff }, + [SEL2GDT(__HYPERVISOR_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING0_DS32), /* 0xe018 - reserved */ /* 0xe023 - Ring 3 code, compatibility */ - [SEL2GDT(FLAT_RING3_CS32)] = { 0x00cffb000000ffff }, + [SEL2GDT(FLAT_RING3_CS32)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS32), /* 0xe02b - Ring 3 data */ - [SEL2GDT(FLAT_RING3_DS32)] = { 0x00cff3000000ffff }, + [SEL2GDT(FLAT_RING3_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING3_DS32), /* 0xe033 - Ring 3 code, 64-bit mode */ - [SEL2GDT(FLAT_RING3_CS64)] = { 0x00affb000000ffff }, + [SEL2GDT(FLAT_RING3_CS64)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS64), /* 0xe038 - reserved */ /* 0xe040 - TSS */ /* 0xe050 - LDT */ /* 0xe060 - per-CPU entry (limit == cpu) */ - [SEL2GDT(PER_CPU_SELECTOR)] = { 0x0000910000000000 }, + [SEL2GDT(PER_CPU_SELECTOR)] = GDTE(GDTE_FLAGS_PERCPU, 0, 0), }; #ifdef CONFIG_PV32 @@ -60,29 +95,29 @@ __section(".data.page_aligned") __aligned(PAGE_SIZE) seg_desc_t boot_compat_gdt[PAGE_SIZE / sizeof(seg_desc_t)] = { /* 0xe008 - Ring 0 code, 64bit mode */ - [SEL2GDT(__HYPERVISOR_CS)] = { 0x00af9b000000ffff }, + [SEL2GDT(__HYPERVISOR_CS)] = GDTE_FLAT(GDTE_FLAGS_RING0_CS64), /* 0xe010 - Ring 0 data */ - [SEL2GDT(__HYPERVISOR_DS32)] = { 0x00cf93000000ffff }, + [SEL2GDT(__HYPERVISOR_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING0_DS32), /* 0xe019 - Ring 1 code, compatibility */ - [SEL2GDT(FLAT_COMPAT_RING1_CS)] = { 0x00cfbb000000ffff }, + [SEL2GDT(FLAT_COMPAT_RING1_CS)] = GDTE_FLAT(GDTE_FLAGS_RING1_CS32), /* 0xe021 - Ring 1 data */ - [SEL2GDT(FLAT_COMPAT_RING1_DS)] = { 0x00cfb3000000ffff }, + [SEL2GDT(FLAT_COMPAT_RING1_DS)] = GDTE_FLAT(GDTE_FLAGS_RING1_DS32), /* 0xe02b - Ring 3 code, compatibility */ - [SEL2GDT(FLAT_COMPAT_RING3_CS)] = { 0x00cffb000000ffff }, + [SEL2GDT(FLAT_COMPAT_RING3_CS)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS32), /* 0xe033 - Ring 3 data */ - [SEL2GDT(FLAT_COMPAT_RING3_DS)] = { 0x00cff3000000ffff }, + [SEL2GDT(FLAT_COMPAT_RING3_DS)] = GDTE_FLAT(GDTE_FLAGS_RING3_DS32), /* 0xe038 - reserved */ /* 0xe040 - TSS */ /* 0xe050 - LDT */ /* 0xe060 - per-CPU entry (limit == cpu) */ - [SEL2GDT(PER_CPU_SELECTOR)] = { 0x0000910000000000 }, + [SEL2GDT(PER_CPU_SELECTOR)] = GDTE(GDTE_FLAGS_PERCPU, 0, 0), }; #endif -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 14:35:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 14:35:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455934.1669555 (Exim 4.92) (envelope-from ) id 1xJAvs-00021w-7P; Tue, 20 Oct 2026 14:35:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455934.1669555; Tue, 20 Oct 2026 14:35: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 1xJAvs-00021p-4l; Tue, 20 Oct 2026 14:35:16 +0000 Received: by outflank-mailman (input) for mailman id 1455934; Tue, 20 Oct 2026 14:35:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJAvq-00021h-Dc for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 14:35:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJAvp-005O5Y-JN for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:35:13 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad77c1c-2eae-0a2a0a5409dd-0a2a450cd988-18 for ; Tue, 20 Oct 2026 16:35:13 +0200 Received: from [52.101.52.7] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad77c1f-f479-0a2a450c0019-34653407dc8b-3 for ; Tue, 20 Oct 2026 16:35:12 +0200 Received: from BY3PR04CA0006.namprd04.prod.outlook.com (2603:10b6:a03:217::11) by SA1PR12MB8096.namprd12.prod.outlook.com (2603:10b6:806:326::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 14:35:09 +0000 Received: from SJ1PEPF000037AB.namprd03.prod.outlook.com (2603:10b6:a03:217:cafe::5b) by BY3PR04CA0006.outlook.office365.com (2603:10b6:a03:217::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.20 via Frontend Transport; Tue, 20 Oct 2026 14:35:09 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000037AB.mail.protection.outlook.com (10.167.244.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 14:35:08 +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.53; Tue, 20 Oct 2026 09:35:06 -0500 Received: from APPOL-18KY0J4.amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 09:35:04 -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=mEsPRQfvUR6NPzDnLv7lRIxiXR9UgSFlt79+5YKAGzv938lj+dEfeohUZ2dLiGRNuDSLFP6dqJKRTyUdDs3Z2Ulcr02wS/OgjTTw9xKG0UdgGA+jSz5UCck9KjTG21kul71GspF+RJLytuz9Cs0t+4e62E5YyXSqS8yflJcOkTpujfhhFbml9E0TG9uVg8tv2waim3zXwrnCF1Xr9aijNENkZ0DsNNG8NHSsBHHOpUwCOWDXoXLbABJJxks6hwvAQ2wRcLcmTrD3KZ5PPEfle39fhm8loq3yvbm/B1IwRsrbtiQz38H7AxUTMwRxRXKPv2GktF6yGubecczsfw67DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fZ3EkhLGGbupSOcpyXTTmgfore2DDfsMhPuaVmmgq0g=; b=TNGK0gLKSQET1EMAx9UnX93tdi5Cn2WVuBGD+otGutzKhsEGwY5KSkE5XHPWR2eKnHGdWZTbwEgIZXpWNGfbaFPq77QF5zle52Mgee+TqRkg0g46yLD/ENxCE9yRYqOdXoyg/l6Z97cfNABgUydwSclGZTGLUFdoOm/QpcJIiDzGe7EHePuisQWhHvzBhbitHGZZT68q5v5aJjmM7p18lJwvTvaZart22pYb2MkSqm02b1FXKYOzpdYNsQrxf79ojGvLI0yKqzef6nGe8ccolAbmyXw7LYDeqfcB+WByFeypnaKsluisYneH1RgQJipS1FGTKNdbgq11DWVsCjz9+Q== 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=fZ3EkhLGGbupSOcpyXTTmgfore2DDfsMhPuaVmmgq0g=; b=PKcpFVCw686K2dbsrSVJGT1pkji55Cn0WoH7DiyAWTnENLVKStDWeXBE2tgv51KqObq3wfMAUPiJ0c0NhZjC2eC0YFg6SaKuH14quA8ILoCHM2fmdEC0ZkpBqLqFJor++6ZfbR0YWW+HsFcUvCMVLU5zhU9i55s4RQ/LC8RBRzk= 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 From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH] xen/arm: Don't create useless P2M pool for a hardware domain Date: Tue, 20 Oct 2026 16:34:58 +0200 Message-ID: <20261020143458.194784-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: SJ1PEPF000037AB:EE_|SA1PR12MB8096:EE_ X-MS-Office365-Filtering-Correlation-Id: d6f3cc76-3e4d-47b8-93db-08df2eb75732 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|36860700016|82310400026|56012099006|5023799004|11063799006|261009223027099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: xqRU61ssPLbbmTghZii2CbVifieVb2rQczk3ofLNf6s/dJxL/Pr6VtqknXQIg6OgcPNxfP29vfLQIggyKX/Xv0y1I+WTmxCmHVOtnPsZYF3Tto5OqEjeii6C3z36fzSebDyO8WcWANLW8dYTiF6bTIZRkVQUXZvVwaNova1i7Ipo0QZ/oxudq8et69NP/OKMmv7m1l8e5gOdcZEaYWdazrdBOl5fRPP9Susc9R2GyJ+ajOzyXNkzELUMGquHgvnNVQgrwcs5AXSXkFTHUrEmBEDAxMA6C9iVMd3ITBJSK20nI7YyFCI+U+DQigqm5gy56W1ucRXtONK0H7Z1e1O+7F9dy1t/DYJi0m2z4n7c10oT0A/rS5nolIBFYYgC6LBugLc6Z54lZmGJ+GaVZUvyZ/qD71VxWbYdUbpXiP7t/E8v8ngmoXe3cVBvT3W9OfMq1Mtuxa5jz+qHrUs06NDvDDSz4lPg5P5AjZbbZqX7yak0NnzVoz5kkXKPMDe3OOla6jTJdgcJf3W2d3bIYKu7PLpIWQW23bIlPqroZP2VZ+1qWVqT07McjV7V3E2X9lJCyqePww4h0VQ2RROWDAhuOOUaRwQ3azFYyzL0WDPwsj0e9PAQT2QWhgN66jnbMGTTRj0D9PgVQdUnuJ48kjMK1jFlPAelPQotetD4pwdSSY1283/bMvb+fxklhi8mcImgTu8SijuTfTeDJG9Qp/+Zlg== 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)(36860700016)(82310400026)(56012099006)(5023799004)(11063799006)(261009223027099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: RWq3T2Uh8ntOr6YEYtRKeZA29ixL/wCFIzNXF6p/96kdnuqww/oMPXYqeILTkWlJif5E8w78SqNW9A49/01ryX9D8Ar1zX+EgvoD0nmkeoLq/xLKkkUzDQTzoz9gaJ4RRhHNfYHmo51VFe9CUyHpJL4yLVeJ9+JndokR5PNNQXacosqnkXdTZkFiN0lHvSyengGBSKZqchub3ZbdK5VtMGj3SXqJscEf1Tro0NRzIgHRTgEr6viLk/FrcUla9/7ze9mUIdWL/WFa7MGYV9rZmB3ITBAh+nVHmvBp01uETBeq0OQOGOZTnB9qOspo5Vb4iXXXrYO/wEexDF6jYoqzawkoZ1tSeYdyK1xdHFYBrn7N6FrmsmQv2heKzrGtBOf1L+yLJnKQR/e4qVPG0OsXNN9e+7Lwyd+DP7uuug6oV29BYfZqjGdkwuJjIueMNgnl X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 14:35:08.5456 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d6f3cc76-3e4d-47b8-93db-08df2eb75732 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: SJ1PEPF000037AB.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8096 X-purgate-ID: tlsNG-d25034/1792506913-014C7A5B-1455352E/0/0 X-purgate-type: clean X-purgate-size: 4435 On Arm, the hardware domain does not use the P2M pool. Its P2M pages are allocated directly from the heap, without any limit. However, when the hardware domain is created using dom0less, we still allocate a P2M pool for it, either of the default size or the one given in xen,domain-p2m-mem-mb. This memory is never used and is simply wasted. The same applies when the pool size is set for the hardware domain using XEN_DOMCTL_set_paging_mempool_size. Don't create the pool for a hardware domain. Make the get/set paging mempool domctls return -EOPNOTSUPP, skip the pool teardown and reject xen,domain-p2m-mem-mb for a hardware domain in dom0less. The dom0less check is Arm specific, because on RISC-V the hardware domain does use the P2M pool. Signed-off-by: Michal Orzel --- docs/misc/arm/device-tree/booting.txt | 4 +++- xen/arch/arm/mmu/p2m.c | 14 ++++++++++++++ xen/common/device-tree/dom0less-build.c | 12 ++++++++++++ 3 files changed, 29 insertions(+), 1 deletion(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index 3787d2e2b668..c3705ab7d913 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -277,7 +277,9 @@ with the following properties: used for the domain P2M pool. This is in-sync with the shadow_memory option in xl.cfg. Leaving this field empty in device tree will lead to the default size of domain P2M pool, i.e. 1MB per guest vCPU plus 4KB - per MB of guest RAM plus 512KB for guest extended regions. + per MB of guest RAM plus 512KB for guest extended regions. On Arm, the + hardware domain has no dedicated P2M pool, so specifying this property + for it makes the domain fail to build. - max_grant_version diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c index 2cf35d8a3709..70d7c9fed955 100644 --- a/xen/arch/arm/mmu/p2m.c +++ b/xen/arch/arm/mmu/p2m.c @@ -61,6 +61,10 @@ static void p2m_free_page(struct domain *d, struct page_info *pg) /* Return the size of the pool, in bytes. */ int arch_get_paging_mempool_size(struct domain *d, uint64_t *size) { + /* No dedicated pool (no limit) for a hardware domain */ + if ( is_hardware_domain(d) ) + return -EOPNOTSUPP; + *size = (uint64_t)ACCESS_ONCE(d->arch.paging.p2m_total_pages) << PAGE_SHIFT; return 0; } @@ -69,6 +73,8 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool can_preempt) { struct page_info *pg; + /* No dedicated pool (no limit) for a hardware domain */ + ASSERT(!is_hardware_domain(d)); ASSERT(spin_is_locked(&d->arch.paging.lock)); for ( ; ; ) @@ -119,6 +125,10 @@ int arch_set_paging_mempool_size(struct domain *d, uint64_t size) unsigned long pages = size >> PAGE_SHIFT; int rc; + /* No dedicated pool (no limit) for a hardware domain */ + if ( is_hardware_domain(d) ) + return -EOPNOTSUPP; + if ( (size & ~PAGE_MASK) || /* Non page-sized request? */ pages != (size >> PAGE_SHIFT) ) /* 32-bit overflow? */ return -EINVAL; @@ -134,6 +144,10 @@ int p2m_teardown_allocation(struct domain *d) { int ret = 0; + /* No dedicated pool - nothing to tear down */ + if ( is_hardware_domain(d) ) + return 0; + spin_lock(&d->arch.paging.lock); if ( d->arch.paging.p2m_total_pages != 0 ) { diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index fcb438c50a04..a877e695ad11 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -757,6 +757,18 @@ static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem, int rc; rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb); + + /* No dedicated pool (no limit) for a hardware domain on Arm */ + if ( IS_ENABLED(CONFIG_ARM) && is_hardware_domain(d) ) + { + if ( !rc ) + return 0; + + printk(XENLOG_ERR + "xen,domain-p2m-mem-mb cannot be specified for a hardware domain\n"); + return -EINVAL; + } + /* If xen,domain-p2m-mem-mb is not specified, use the default value. */ p2m_pages = rc ? p2m_mem_mb << (20 - PAGE_SHIFT) : -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 15:00:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 15:00:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455961.1669572 (Exim 4.92) (envelope-from ) id 1xJBJl-0008V4-A2; Tue, 20 Oct 2026 14:59:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455961.1669572; Tue, 20 Oct 2026 14: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 1xJBJl-0008Ux-7I; Tue, 20 Oct 2026 14:59:57 +0000 Received: by outflank-mailman (input) for mailman id 1455961; Tue, 20 Oct 2026 14:59:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJBJk-0008Ur-Lt for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 14:59:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJBJk-00DbrN-2i for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:59:56 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad781dc-bab6-0a2a0a5309dd-0a2a4502e3c2-32 for ; Tue, 20 Oct 2026 16:59:56 +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 6ad781eb-6ca4-0a2a45020019-b9ff1c22a9f3-3 for ; Tue, 20 Oct 2026 16:59: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a159d355ee000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 14:59:44 +0000 Received: from [10.235.238.14] (149.173.185.81.rev.sfr.net [81.185.173.149]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 58B1F82C93; Tue, 20 Oct 2026 16:59: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=t9wbN/2AA5muZyQtX251zwAhFK6rWAPKQApJ4Pd5M2s=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=eIz/40OzXV/Mq+bsv/O1yvjUWfsUbaDkpx/FQ/XlgHetItGN0bDmMK80WpOXgAtEfA03B3XgI wbUf3PaA98/aLIssUkKPW73ggpINhcD+BUvR0a5KmHYLxltpgLHCwDIfT8E8PsdjkTEK105iDiH L+MGjYxu0pZpaarH5K8QiFfQZsivKxEW5c8X85yVPCRNzA5O7GY0CoBDxNMbBaQUJIqqsB67DuF gqFoFtapuGNCOAhkBnJttFOmsqzn96WKpaqqvJoXZv4rpFxyXQ9fBF/uGtvCb67n5Slse6H1hT3 CtyxIRvUMN+D5/1bEUgunCd3NHKC3DL5asEgiVPgpFiw== X-Zone-Loop: 97a14402183efeeaee22a08beb62303e42f76dbfa4cf x-campaign-type: default x-transaction-id: c612f015-b0f1-490f-a367-377fa780c720 x-swg-uid: 01-e9f974b9-7d30-40da-bcc5-110e62601fc4 X-Mailer: Sweego Message-ID: <1792508384.8631fc262581453bbf619ec5b2062170.1a159d355ee000f79f@vates.tech> x-swg-bid: 1792508384.8631fc262581453bbf619ec5b2062170.1a159d355ee000f79f 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 v3 16/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: <198c5d8b140fb156b914eae007582ec3b0e83cba.1790779209.git.oleksii.kurochko@gmail.com> References: <198c5d8b140fb156b914eae007582ec3b0e83cba.1790779209.git.oleksii.kurochko@gmail.com> Date: Tue, 20 Oct 2026 16:59:35 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792508376; l=936; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=FkshxL7v1IQwBJVln9Xlm09mUGf1Z1rNv628cddjKhM=; b=au5EgGwKB61ZdFkI3VMcGZiLxO5hawE0YQIj/soxOzDze0SgJEXezOlLst4Pl0OGubo5Qg5Le Y7iEV7DXAKBA1mZzTEJAGHLvf1P6LcDLMO2dzXwQen6UA9jE5UCVJ2t 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: 1792508384337 X-purgate-ID: tlsNG-720697/1792508395-319CB2AC-B2BBCBEE/10/73395122804 X-purgate-type: spam X-purgate-size: 936 On Wed, 30 Sep 2026 18:23:35 +0200, Oleksii Kurochko 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. Yet only one pair is defined, > selected by Xen's XLEN and named as if it were the only one, so the 4-byte > forms, which a guest running with VSXL=32 and Sv32 in vsatp produces, can't > be named at all on RV64. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 15:00:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 15:00:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455960.1669564 (Exim 4.92) (envelope-from ) id 1xJBJg-0008I5-04; Tue, 20 Oct 2026 14:59:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455960.1669564; Tue, 20 Oct 2026 14:59: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 1xJBJf-0008Hy-Sq; Tue, 20 Oct 2026 14:59:51 +0000 Received: by outflank-mailman (input) for mailman id 1455960; Tue, 20 Oct 2026 14:59:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJBJe-0008Hs-9o for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 14:59:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJBJd-0030Mz-Kr for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:59:49 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad781be-2eae-0a2a0a5409dd-0a2a450be29a-34 for ; Tue, 20 Oct 2026 16:59:49 +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 6ad781e5-b7e8-0a2a450b0019-b9ff1c22aadf-3 for ; Tue, 20 Oct 2026 16:59: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a159d3517e000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 14:59:43 +0000 Received: from [10.235.238.14] (149.173.185.81.rev.sfr.net [81.185.173.149]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 4826882C90; Tue, 20 Oct 2026 16:59: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: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=hi7qVxZTCK667hEpjdc1RZ+3c9uCaxe2Qcb2en0L13s=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=RkVwXR0l0+Rgo6D7sqnWfl9yAW2WGOLf5rZl/5lL9g9qC08z1K5Iozm6NMKEsF1sbndaBtjlU J3UXWIzBBwkV+EdtaZ/iy+gzbYUXSxBfNxUPGvSVBBTwr0H9uFm6SefO+3gYJw5b/vpfiCvhapi sb+ALb5DvnN7e2FyoliyCVy5+XiIp/fM6iiJdOkfQKKDdgTu4uQph059FRtkDC14ucbOJ7brudv 3+HRZCp+uAsnAc0EkjzTsIiXR79Hy0knJ7zw2zTCh9fxz17ZQcjz9vUC19G5pshd7nEa6d4a4oI 2GxaXRu4OMQeQMZF3SU1Mf0sOlqJlcslliZTL0maYczw== X-Zone-Loop: d84f2bea13fd68af8318881662880b3ee34fd0c7a12b x-campaign-type: default x-transaction-id: 2d9dbc8c-d5c8-463a-9a34-55f76e296606 x-swg-uid: 01-29ddb68d-d03d-4e36-ac7d-2ebc5370a719 X-Mailer: Sweego Message-ID: <1792508383.8631fc262581453bbf619ec5b2062170.1a159d3517e000f79f@vates.tech> x-swg-bid: 1792508383.8631fc262581453bbf619ec5b2062170.1a159d3517e000f79f 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 v3 15/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: <8c1c0c2adf56a395b6419335161da9f11fc827c5.1790779209.git.oleksii.kurochko@gmail.com> References: <8c1c0c2adf56a395b6419335161da9f11fc827c5.1790779209.git.oleksii.kurochko@gmail.com> Date: Tue, 20 Oct 2026 16:59:35 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792508376; l=18705; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=LAbSui4TZGlqqBOxTb+dNLlkEWirTqrxfrKhZz0B85k=; b=rv1zJJRVjn/9hIoYnlTC2SXWI0Jhh/NW4qN8HO+wpVXC0j8WsloX6uQZOrQfyJo7WIHbS6Qvh 5fGUpduDpNqDKXmq/pqYBqfSV6bkvoAtWIpVH0K+gfl4XaTu8ketNup 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: 1792508382967 X-purgate-ID: tlsNG-42698a/1792508389-19EC69EA-49250016/10/73395122804 X-purgate-type: spam X-purgate-size: 18705 > 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, > and pass the trap cause down to fixup_exception() for it. > > Also add gpr-num.h, providing symbolic GPR numbers for use in assembly > and inline asm. It is derived from Linux 6.16, with the register list > turned into a GPR_LIST() macro instead of being open-coded with .irp, so > that it can be used from C as well. > > Resolving a GPR number to the saved value of the register relies on > struct cpu_user_regs holding x0..x31 contiguously and in register-number > order. Add regs_gpr_ptr() for that, and check the layout against > GPR_LIST() at build time. The block doesn't have to be at the start of > the structure, so anchor REG_PTR() at ->zero too rather than at the > structure itself. > > Update the exception handling code to dispatch based on the entry type. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v3: > - Update the commit message. > - Keep the name of the asm_extable assembler macro: renaming it to > _asm_extable was unrelated to this patch. > - Replace regs_get_gpr() in extable.c with regs_gpr_ptr() in asm/regs.h, > returning where the register's value is saved rather than the value > itself, so that a single helper serves code which reads a guest register > as well as code which writes one. Anchor the array access at > ®s->zero rather than casting regs itself, matching the relaxed > layout requirement below, and bound the index with array_index_nospec() > so that release builds, where the ASSERT() is compiled out, cannot read > past the register frame. Add NR_GPRS instead of open-coding 32. > - Move the layout BUILD_BUG_ON()s out of regs_get_gpr() into > build_assertions() in domain.c, so that they no longer sit in one > particular consumer of the mapping. > - Anchor those checks at offsetof(struct cpu_user_regs, zero) rather than > at offset 0: the x0..x31 block only has to be contiguous and in > register-number order, it no longer has to sit at the start of the > structure. Update the comment above struct cpu_user_regs accordingly, > keeping the "->zero must read as 0" requirement as a separate point. > - REG_PTR(): anchor at ®s->zero for the same reason. > - gpr-num.h: move the part of the comment describing the generation of the > .L_gpr_num_ symbols down to the construct which actually generates > them; GPR_LIST() itself has other users. > - gpr-num.h: emit the separator ahead of each list entry instead of after > it, so that the expansion doesn't end with one and whatever follows a use > of the list has to supply its own; ASM_EXTABLE_TRAP_INFO() supplies the > "\n" it needs. > - gpr-num.h: state in the file header what was changed compared to the > Linux original. > - asm/extable.h: no functional change, put EX_TRAP_INFO_REG() on a single > line and reflow the comment describing the exception table entry format. > - Drop BUG_ON() in ex_handler_trap_info() as trap_info pointer should be > guaranteed properly filled by compilation process. > --- > Changes in v2: > - regs_get_gpr(): take a GPR number instead of a byte offset, dropping the > multiplication at the call site. A non-multiple-of-8 offset is now > unrepresentable. > - regs_get_gpr(): ASSERT(num < 32) instead of a range check returning 0, > which isn't usable as an error indicator. No num == 0 check: reading x0 > is harmless out of context, and a NULL trap_info is caught by the > existing BUG_ON() where the dereference happens. > - regs_get_gpr(): index the register frame as an array, constify regs and > drop the pointless inline. > - Anchor the first BUILD_BUG_ON() at offsetof(..., zero) == 0 rather than > at ra, pinning both ends of the x0..x31 range. > - Drop MAX_REG_OFFSET; asm/processor.h is no longer touched by this patch. > - ex_handler_trap_info(): use regs->sepc and the cause passed down from > do_trap() instead of re-reading CSR_SEPC/CSR_SCAUSE; fixup_exception() > gains a cause parameter. stval stays a CSR read as do_trap() doesn't > read it. > - asm/extable.h: revert the .word -> .long change, the extra parens and the > stray semicolon after .popsection; use .half for the new type and data > fields to match .word. > - Make GPR_LIST() the single source of the ABI-name -> register-number > mapping, and check struct cpu_user_regs against it at build time, so the > two can no longer diverge. > - Add the explanatory comment above sturc cpu_user_regs to explain an > ordering of x0-x31 registers. > --- > --- > xen/arch/riscv/domain.c | 22 ++++++++ > xen/arch/riscv/extable.c | 48 +++++++++++++++- > xen/arch/riscv/include/asm/extable.h | 61 ++++++++++++++------- > xen/arch/riscv/include/asm/gpr-num.h | 53 ++++++++++++++++++ > xen/arch/riscv/include/asm/processor.h | 14 ++++- > xen/arch/riscv/include/asm/regs.h | 23 +++++++- > xen/arch/riscv/include/asm/riscv_encoding.h | 7 ++- > xen/arch/riscv/include/asm/traps.h | 6 ++ > xen/arch/riscv/traps.c | 2 +- > 9 files changed, 210 insertions(+), 26 deletions(-) > create mode 100644 xen/arch/riscv/include/asm/gpr-num.h > > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index fd21cb1789..f60f871aba 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -484,9 +485,30 @@ void context_switch(struct vcpu *prev, struct vcpu *next) > > static void __init __maybe_unused build_assertions(void) > { > +/* > + * GPR_LIST() puts nothing between its entries, so the separator has to come > + * from here. It is emitted ahead of each entry rather than after it, so that > + * the expansion doesn't end with one and its use below can be terminated like > + * an ordinary statement. > + */ > +#define CHECK_GPR_INDEX(num, name) \ > + ; BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) != \ > + offsetof(struct cpu_user_regs, zero) + \ > + (num) * sizeof(unsigned long)) > + > /* > * Enforce the requirement documented in struct cpu_info that > * guest_cpu_user_regs must be the first field. > */ > BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs)); > + > + /* > + * Enforce the requirement documented in struct cpu_user_regs that the > + * x0..x31 fields are contiguous and in architectural register-number > + * order, which is what lets a register number be resolved to its saved > + * value by indexing them as an array anchored at ->zero. > + */ > + GPR_LIST(CHECK_GPR_INDEX); > + > +#undef CHECK_GPR_INDEX > } > diff --git a/xen/arch/riscv/extable.c b/xen/arch/riscv/extable.c > index 5b89c4278c..19d9e3617c 100644 > --- a/xen/arch/riscv/extable.c > +++ b/xen/arch/riscv/extable.c > @@ -6,8 +6,11 @@ > #include > #include > > +#include > #include > #include > +#include > +#include > > #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field) > > @@ -32,6 +35,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 +68,26 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, > regs->sepc = ex_fixup(ex); > } > > -bool fixup_exception(struct cpu_user_regs *regs) > +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_gpr_ptr(regs, ex->data); > + > + /* > + * 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 +105,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..1ff557b70d 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) > + ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) > .endm > > #else /* __ASSEMBLER__ */ > @@ -23,20 +30,35 @@ > > 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 "\n" \ > + 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 in case of a fault, `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 +67,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..867ee172c0 > --- /dev/null > +++ b/xen/arch/riscv/include/asm/gpr-num.h > @@ -0,0 +1,53 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Based on Linux 6.16 arch/riscv/include/asm/gpr-num.h, with the > + * register list turned into GPR_LIST() instead of being open-coded > + * with .irp, so that it can also be used outside of assembly. > + */ > +#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; users expand it with > + * their own per-register macro. Among them, the layout of struct cpu_user_regs > + * is checked against this list at build time (see build_assertions() in > + * domain.c), so neither list can 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) > + > +/* Number of GPRs described by GPR_LIST(). */ > +#define NR_GPRS 32 > + > +#ifdef __ASSEMBLER__ > + > +/* > + * 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 > + * 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__ */ > + > +/* See the comment ahead of the __ASSEMBLER__ flavour above. */ It's hard to understand which comment you're talking about, if you are talking about the separator comment above GPR_NUM_EQU, may I suggest something like: /* See the GPR_NUM_EQU()'s comment about separator use */ > +#define GPR_NUM_EQU(num, name) "\n.equ .L_gpr_num_" #name ", " #num > +#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/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h > index 647268e6d0..599ae3cd60 100644 > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -911,8 +911,13 @@ > #define REG_OFFSET(insn, pos) \ > (SHIFT_RIGHT((insn), (pos) - LOG_REGBYTES) & REG_MASK) > > +/* > + * The x0..x31 block of struct cpu_user_regs is not required to sit at the > + * start of the structure, so anchor the offset at ->zero (x0) rather than > + * at the structure itself. > + */ > #define REG_PTR(insn, pos, regs) \ > - (unsigned long *)((unsigned long)(regs) + REG_OFFSET(insn, pos)) > + (unsigned long *)((unsigned long)&(regs)->zero + REG_OFFSET(insn, pos)) I don't see why this hunk is needed here. Nothing in the tree uses REG_PTR() (nor GET_RS*() / SET_RD()), and ->zero is the first member of struct cpu_user_regs, so this is a no-op today. It is also unrelated to the extable change. If you want REG_PTR() to follow the same layout assumption as regs_gpr_ptr(), I'd rather see it built on top of it, e.g. regs_gpr_ptr(regs, REG_OFFSET(insn, pos) >> LOG_REGBYTES), in a separate patch together with its first user. Otherwise please drop the hunk (and the matching sentence in the commit message). -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 15:00:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 15:00:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455963.1669582 (Exim 4.92) (envelope-from ) id 1xJBJu-0001Fj-Is; Tue, 20 Oct 2026 15:00:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455963.1669582; Tue, 20 Oct 2026 15: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 1xJBJu-0001Fb-Em; Tue, 20 Oct 2026 15:00:06 +0000 Received: by outflank-mailman (input) for mailman id 1455963; Tue, 20 Oct 2026 15:00:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJBJs-0000xf-V2 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:00:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJBJs-00DbyY-Bb for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 17:00:04 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad781dc-bab6-0a2a0a5309dd-0a2a4502e3c2-42 for ; Tue, 20 Oct 2026 17:00:04 +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 6ad781eb-6ca4-0a2a45020019-b9ff1c22a9f3-4 for ; Tue, 20 Oct 2026 16:59: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 1a159d35ad4000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 14:59:46 +0000 Received: from [10.235.238.14] (149.173.185.81.rev.sfr.net [81.185.173.149]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 774BC82C90; Tue, 20 Oct 2026 16:59: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: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=sDhhZ7pFmzaASXZhR5+nszPfCqaYsEK5PHtvzy4QOM4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=aXAO3BeFAoo9Uym1c/txZeb0gJaZDDPTXV+2WuoKBZoKYasdSDfqCqu07gFM9Mp+fDs/7u1V0 U9hpnfxcnISzjGE8CFBq4raua1vYForRcLAGc17dpLlVIACk2xxw1hIlkxiHzBMtliVfw/a/NsV zhHPezBhwd2roATIaOsgO627X9pFb9FVL4PdLPMnVXBoJrwb4S1DwkvcoH7SU22s+Tm+oL73+FI AWRWnpLVQ/LKDSk8NBmSwmv6RS0L13+3L30gYwohplT8GG0PhHlR2OEuQ3g918QEN9lKApDBmfz o7Q2bBfLHl2KBT4Rbn5p35gNtaWtxT/yrLFt5DZJttdQ== X-Zone-Loop: 1fd6766763a6c1dff26645eec6bcea1cf429f7a37a43 x-campaign-type: default x-transaction-id: 706d827d-b7c1-43ae-ba1f-56376516fe72 x-swg-uid: 01-f494aace-7d69-44df-96ae-47f3484f2789 X-Mailer: Sweego Message-ID: <1792508386.8631fc262581453bbf619ec5b2062170.1a159d35ad4000f79f@vates.tech> x-swg-bid: 1792508386.8631fc262581453bbf619ec5b2062170.1a159d35ad4000f79f 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 v3 17/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: <42d1a37341eadd764022a1658bebcffcee15238a.1790779209.git.oleksii.kurochko@gmail.com> References: <42d1a37341eadd764022a1658bebcffcee15238a.1790779209.git.oleksii.kurochko@gmail.com> Date: Tue, 20 Oct 2026 16:59:35 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792508376; l=7620; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Suw3T89BcxjO9wuu5jNLZD25Lxs9IE9fLqsi4tiiCLE=; b=MybGBe1FeJbkiUer4aLzLDjVFCD6yo43Oeta8FheSSAn8oyRFZ2v6HXtvUUAdM28mRCXmBgsk 17S6hX0b6zEAivCZKVsVMyre2VGslb1A05N7CEOJ8/5eS6GoiWMLWCd 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: 1792508385603 X-purgate-ID: tlsNG-720697/1792508398-F1EAB2AC-4F20F604/10/73395122804 X-purgate-type: spam X-purgate-size: 7620 > 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. Nit: should drop "in later" as it would be stale in the future. I'd suggest: - Load fault / Store fault: this is where MMIO emulation will hook. Not in scope of this patch. > > 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 Xen doesn't access the VS-stage page tables here: the implicit access is done by the hardware page-table walker, while translating a guest access through the guest's VS-stage page tables. I'd suggest to use spec's wording. Moreover, "and" is not needed between both conditions as you said above "when both" which already indicates that both should be true. Here is a proposition: ``` Any of these three faults can instead be reported via a pseudoinstruction in htinst, when both: (a) the fault is caused by an implicit memory access for VS-stage address translation. (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. > > resolve_faulting_gpa() is a stub which always fails for now, so any guest > page fault other than one taken on an implicit access for VS-stage > translation currently crashes the domain. That one is reflected to the > guest through trap_redirect(), which is still a BUG_ON() placeholder > though, and so takes the host down. This is no worse than before this > patch, where these traps fell through to do_unexpected_trap() and die(). > > Cache the "trap came from the guest" test in a local, as the guest page > fault case needs it too. > > Signed-off-by: Oleksii Kurochko > + default: > + domain_crash(current->domain, "Impossible cause (%#lx) in %s?\n", > + gf->cause, __func__); Nit: please drop __func__, the message is unique enough to find where it comes from. > + return; > + } > + > + trap_redirect(&utrap); > +} > + > +void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cause) > +{ > + 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); > + > + /* > + * 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) Nit: I think this paragraph could be re-written by using what you said in the commit message. ``` htinst reports one of the special pseudoinstruction values when both: (a) the fault is caused by an implicit memory access for VS-stage address translation (b) htval holds a nonzero value: the guest physical address of that VS-stage PTE, not of the guest's original access, which is unknown as VS-stage translation didn't complete. No access to emulate then: to match bare hardware behavior, inject an access fault of the ORIGINAL access type (Instruction, Load, or Store/AMO) that initiated the address translation. ``` > + * > + * 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. > + * > + * 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. > + */ > + if ( htinst_is_pseudo(gf.htinst) ) > + { > + inject_access_fault(&gf); > + > + return; > + } > + > + rc = resolve_faulting_gpa(&gf); > + if ( rc ) > + goto out; > + > + 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. > + */ > + inject_access_fault(&gf); > + return; > + > + default: > + ASSERT_UNREACHABLE(); > + rc = -EOPNOTSUPP; > + > + break; > + } > + > + out: > + if ( rc ) > + domain_crash(current->domain, > + "%s: unable to handle guest page fault (cause=%#lx) at gpa %#"PRIpaddr"\n", > + __func__, cause, gf.gpa); Probably __func__ can be dropped as the message is unique enough. > +} > diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c > @@ -193,6 +194,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) > { > register_t pc = cpu_regs->sepc; > unsigned long cause = csr_read(CSR_SCAUSE); > + bool from_guest = cpu_regs->hstatus & HSTATUS_SPV; > @@ -275,3 +289,9 @@ enum mc_disposition arch_do_multicall_call(struct mc_state *state) > + > +/* Redirect trap to Guest. */ This duplicates the comment on the prototype in traps.h, so I'd drop it here. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 15:01:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 15:01:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455977.1669591 (Exim 4.92) (envelope-from ) id 1xJBLA-0002GQ-Sx; Tue, 20 Oct 2026 15:01:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455977.1669591; Tue, 20 Oct 2026 15:01: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 1xJBLA-0002GJ-Pg; Tue, 20 Oct 2026 15:01:24 +0000 Received: by outflank-mailman (input) for mailman id 1455977; Tue, 20 Oct 2026 15:01:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJBL8-0002G4-W6 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:01:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJBL7-00DcJA-GX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 17:01:21 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad78234-8faa-0a2a0a5109dd-0a2a450b8a2a-38 for ; Tue, 20 Oct 2026 17:01:21 +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 6ad78241-b7e8-0a2a450b0019-b9ff1c22a383-3 for ; Tue, 20 Oct 2026 17:01: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a159d4bf40000f79f.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 15:01:17 +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 2D3B48207D; Tue, 20 Oct 2026 17:01: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=I3K40r4feh2Ix+Lr1O5N3VXWD6EDgoCurTQsjQkhbQs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=NYpxDdJjSCMX0xeeP5MpsVTWgJtS0F9cT2uLufiSWAfa/NibNIDkgZ+4dYxDlzkAXp1TgVXs2 irywskaKOWSLxMpXVZGLIGCW/WPJt/LjUYdoKOMr6tTNZhCwlQ+M6nx8Pobwd8HKFTBtvtD8jT2 vow/qd5Fvd26msAo0J7PftN1Qv9iREONiHolHw2f+vPUK6gPvxDxPlTdq2wK4h+lyQ/HDcrkC9/ B9XgeDknRS8EY3NKxGZkpeZADC7nx2EXiR/KZYjh2BKPKUV2jpK6nvtejgIwiwb8Hb4vePzHU59 zAfyQQ721sFGiQtEgZvzEfauNd/ndgQ5i/esi6iZ6zew== X-Zone-Loop: fad66d375572e421a8f43c9ad98879340f361cea54c4 x-campaign-type: default x-transaction-id: 2ed39b88-ff88-4548-9528-6bda47527036 x-swg-uid: 01-2fc052ab-b9ff-4cd6-aa42-bcdeb046b897 X-Mailer: Sweego Message-ID: <1792508477.8631fc262581453bbf619ec5b2062170.1a159d4bf40000f79f@vates.tech> x-swg-bid: 1792508477.8631fc262581453bbf619ec5b2062170.1a159d4bf40000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 20 Oct 2026 17:01:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/nestedsvm: Require SpecCtrl 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.tsczsss References: <20261020045758.321952-1-chunjie.zhu@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: <20261020045758.321952-1-chunjie.zhu@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Io78WQajgCjbqwduUL4FFylZ" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792508471342 X-purgate-ID: tlsNG-42698a/1792508481-2C39B9EA-19765D48/0/0 X-purgate-type: clean X-purgate-size: 8304 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Io78WQajgCjbqwduUL4FFylZ Content-Type: multipart/mixed; boundary="------------tQ00g08ndIYtv0xl48kGl02G"; protected-headers="v1"; hp="clear" Message-ID: Date: Tue, 20 Oct 2026 17:01:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/nestedsvm: Require SpecCtrl 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.tsczsss References: <20261020045758.321952-1-chunjie.zhu@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: <20261020045758.321952-1-chunjie.zhu@citrix.com> --------------tQ00g08ndIYtv0xl48kGl02G Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAwNzowMSwgY2h1bmppZS56aHVAY2l0cml4LmNvbSBhIMOpY3Jp dMKgOg0KPiBGcm9tOiBDaHVuamllIFpodSA8Y2h1bmppZS56aHVAY2l0cml4LmNvbT4NCj4g DQo+IFByZXZpb3VzbHkgTDAgZGlkIG5vdCBleHBvc2UgdGhpcyBiaXQsIGZvcmNpbmcgTDEg dG8gaW50ZXJjZXB0IGFuZA0KPiBlbXVsYXRlIE1TUl9TUEVDX0NUUkwgYWNjZXNzZXMgZnJv bSBMMiBpbiBzb2Z0d2FyZSwgd2hpY2ggaXMNCj4gZnVuY3Rpb25hbGx5IGNvcnJlY3QgYnV0 IHN1Ym9wdGltYWwuIFBlciBBUE0gdm9sLjIgcmV2IDMuNDQgIlNQRUNfQ1RSTA0KPiBWaXJ0 dWFsaXphdGlvbiIsIGhhcmR3YXJlIHN1cHBvcnRzIGNvbWJpbmluZyBob3N0IGFuZCBndWVz dCBTUEVDX0NUUkwNCj4gdmFsdWVzIHZpYSBWTUNCLnNwZWNfY3RybCB3aXRoIGEgbG9naWNh bCBPUiB3aGlsZSBhIGd1ZXN0IHJ1bnMsIGFuZA0KPiBzYXZlcyB0aGUgKHBvc3NpYmx5IGd1 ZXN0LW1vZGlmaWVkKSB2YWx1ZSBiYWNrIGludG8gVk1DQi5zcGVjX2N0cmwNCj4gb24gI1ZN RVhJVC4NCj4gDQo+IFJlcXVpcmUgdGhlIFNWTSBTcGVjQ3RybCBmZWF0dXJlIGJlZm9yZSBy dW5uaW5nIGFueSBuZXN0ZWQgdmlydA0KPiBndWVzdHMuDQo+IA0KPiBVcGRhdGUgZG9jcy9k ZXNpZ25zL25lc3RlZC1zdm0tY3B1LWZlYXR1cmVzLm1kIHdpdGggdGhlIHJhdGlvbmFsZQ0K PiBmb3IgcmVxdWlyaW5nIGFuZCBleHBvc2luZyBiaXQgMjAgKFNwZWNDdHJsKS4NCj4gDQo+ IFNpZ25lZC1vZmYtYnk6IENodW5qaWUgWmh1IDxjaHVuamllLnpodUBjaXRyaXguY29tPg0K PiAtLS0NCj4gICBkb2NzL2Rlc2lnbnMvbmVzdGVkLXN2bS1jcHUtZmVhdHVyZXMubWQgfCAx MyArKysrKysrKysrKysrDQo+ICAgeGVuL2FyY2gveDg2L2NwdS1wb2xpY3kuYyAgICAgICAg ICAgICAgIHwgIDMgKystDQo+ICAgeGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMg ICAgICAgIHwgMjYgKysrKysrKysrKysrKysrKysrKysrKysrLQ0KPiAgIDMgZmlsZXMgY2hh bmdlZCwgNDAgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1n aXQgYS9kb2NzL2Rlc2lnbnMvbmVzdGVkLXN2bS1jcHUtZmVhdHVyZXMubWQgYi9kb2NzL2Rl c2lnbnMvbmVzdGVkLXN2bS1jcHUtZmVhdHVyZXMubWQNCj4gaW5kZXggY2UxNjhlNjhlMWIz Li42OTk5ZmNmMWJiNzIgMTAwNjQ0DQo+IC0tLSBhL2RvY3MvZGVzaWducy9uZXN0ZWQtc3Zt LWNwdS1mZWF0dXJlcy5tZA0KPiArKysgYi9kb2NzL2Rlc2lnbnMvbmVzdGVkLXN2bS1jcHUt ZmVhdHVyZXMubWQNCj4gQEAgLTEwOSwzICsxMDksMTYgQEAgbGVhZiA4MDAwMDAwQTplZHgN Cj4gICAgIFVzaW5nIGl0IGluIEwwIHJlZHVjZXMgdGhlIGNoYW5jZSB0aGF0IHdlJ2xsIG1h a2Ugc29tZSBzb3J0IG9mIGVycm9yDQo+ICAgICBpbiB0aGUgZGVjb2RlIHBhdGguICBBbmQg aWYgaGFyZHdhcmUgc3VwcG9ydHMgaXQsIGl0J3MgZWFzeSBlbm91Z2gNCj4gICAgIHRvIHBy b3ZpZGUgdG8gdGhlIEwxLg0KPiArDQo+ICstIDIwIGBTcGVjQ3RybGAgKk1TUl9TUEVDX0NU UkwgdmlydHVhbGlzYXRpb24qOiBSZXF1aXJlIGZvciBMMCwgcHJvdmlkZSB0byBMMQ0KPiAr DQo+ICsgIEwwIGFscmVhZHkgcmVsaWVzIG9uIHRoaXMgZmVhdHVyZSB0byB2aXJ0dWFsaXpl IE1TUl9TUEVDX0NUUkwgZm9yIHRoZQ0KPiArICBMMSBoeXBlcnZpc29yIGl0c2VsZiAoc2Vl IGBYODZfRkVBVFVSRV9TQ19NU1JfSFZNYCkuICBSZXF1aXJpbmcgaXQNCj4gKyAgYXMgYSBi YXNlbGluZSBmb3IgbmVzdGVkIHZpcnQgKGZpcnN0IGF2YWlsYWJsZSBvbiBaZW4yKSBtZWFu cyBMMSBjYW4NCj4gKyAgcmVseSBvbiB0aGUgc2FtZSBoYXJkd2FyZSB2aXJ0dWFsaXNhdGlv biBmb3IgaXRzIG93biBMMiBndWVzdHMsDQo+ICsgIGluc3RlYWQgb2YgaGF2aW5nIEwwIHVu Y29uZGl0aW9uYWxseSBpbnRlcmNlcHQgYW5kIHRyYXAvZW11bGF0ZQ0KPiArICBNU1JfU1BF Q19DVFJMIGFjY2Vzc2VzIGNvbWluZyBmcm9tIEwyLiAgUHJvdmlkaW5nIGl0IHRvIEwxIGlz DQo+ICsgIGJhc2ljYWxseSBmcmVlIG9uY2UgaXQncyByZXF1aXJlZCBvZiBMMCwgYW5kIGl0 IHJlbW92ZXMgYQ0KPiArICBzaWduaWZpY2FudCBhbW91bnQgb2YgIkNQVSB3aXRob3V0IHRo ZSBmZWF0dXJlIiBmYWxsYmFjayBjb2RlIHRoYXQNCj4gKyAgd291bGQgb3RoZXJ3aXNlIG5l ZWQgdG8gYmUgaW1wbGVtZW50ZWQgYW5kIG1haW50YWluZWQgZm9yIG5lc3RlZA0KPiArICB2 aXJ0Lg0KDQpJJ20gbm90IHN1cmUgd2UgYWN0dWFsbHkgbmVlZCB0aGlzIHJlcXVpcmVtZW50 Lg0KDQpBIGNvbW1lbnQgcmVnYXJkaW5nIE1TUl9TUEVDX0NUUkwgdmlydHVhbGl6YXRpb24g c3VnZ2VzdCB0aGF0IA0KTVNSX1NQRUNfQ1RSTCB2aXJ0dWFsaXphdGlvbiBpcyBhcyBvbGQg YXMgTVNSX1NQRUNfQ1RSTCBpdHNlbGYNCg0KID4gVmlydHVhbGlzaW5nIE1TUl9TUEVDX0NU UkwgZm9yIGd1ZXN0cyBkZXBlbmRzIG9uIFNWTSBzdXBwb3J0LCB3aGljaA0KID4gb24gcmVh bCBoYXJkd2FyZSBtYXRjaGVzIHRoZSBhdmFpbGFiaWxpdHkgb2YgTVNSX1NQRUNfQ1RSTCBp biB0aGUNCiA+IGZpcnN0IHBsYWNlLg0KDQpTbyBpZiB0aGVyZSdzIG5vIE1TUl9TUEVDX0NU UkwsIHRoZXJlIGlzIG5vdGhpbmcgc3BlY2lhbCB0byBkbyBmb3IgDQpuZXN0ZWQgdmlydC4N Cg0KV2hhdCB3ZSBjYW4gZXZlbnR1YWxseSBzYXkgaXMgdGhhdCB3ZSBjYW4gcmVxdWlyZSBN U1JfU1BFQ19DVFJMIA0KdmlydHVhbGl6YXRpb24gc3VwcG9ydCBpZmYgd2Ugd2FudCBob3N0 IE1TUl9TUEVDX0NUUkwuDQoNClRlZGR5DQo= --------------tQ00g08ndIYtv0xl48kGl02G-- --------------Io78WQajgCjbqwduUL4FFylZ 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+p0QLLz9AFAmrXgjYFAwAAAAAACgkQZg+p0QLLz9Bx jgwAn4nlLBevBneb9qFybLuKLNUpNWCKxHR2sYuQHzF5B2OjSxQGSkL4Ah2GzypeUYe8SSWcPIt9 ERBGHASG6MWZ2U+ndeCOdDW62Ha227K5rikr9wiW18+JHX38gINY0mrH8CGVEJunRtXtWr2m9+Z2 8mQpECjcZAP3pZzmvyqhfluKNQ7kfCH1r2q8JUDcf4S3beO9fkbBbxWJS0L0h5aVnU9QEs5bDC8w nr9msc7PRxpCxI6DFqdRadYFK53fpe6B4SahJpByYsLxTb0krn0KkZWWuFMYbXDeY0ckL54fjN98 fb13VHl4QU3DmncVku6okWYMHD+lK4MR4fCfjQJtSsiLdJ9KOayF9uRAe2DITWgd/sdFuzaNJfoJ 2uBvLmwMnY2IKiNxLpg4ar1HxwrXaZPg5GoyDRAcXlASPHeuiAnbiksGZZsWXzRytNiJIyZbXaVe ssk3tLLQI9Hz4hSDwd72TAav037SHTbzEk/RAJfEby4H8AK+Ygpyd9Xkt9jm =1MXX -----END PGP SIGNATURE----- --------------Io78WQajgCjbqwduUL4FFylZ-- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 15:22:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 15:22:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456001.1669599 (Exim 4.92) (envelope-from ) id 1xJBfc-0006a7-K9; Tue, 20 Oct 2026 15:22:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456001.1669599; Tue, 20 Oct 2026 15:22: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 1xJBfc-0006a0-HH; Tue, 20 Oct 2026 15:22:32 +0000 Received: by outflank-mailman (input) for mailman id 1456001; Tue, 20 Oct 2026 15:22:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJBfb-0006Yc-4G for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:22:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJBfa-0033QI-DU for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 17:22:30 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad78727-bab6-0a2a0a5309dd-0a2a4509cb9a-40 for ; Tue, 20 Oct 2026 17:22: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 6ad78736-be1a-0a2a45090019-b9ff1c2281bb-3 for ; Tue, 20 Oct 2026 17:22: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 1a159e814b4000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 15:22:24 +0000 Received: from leducb.local (149.173.185.81.rev.sfr.net [81.185.173.149]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 2051581DC6; Tue, 20 Oct 2026 17:22:23 +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=CSBTOdv5UzZAb1Tx+z+CtOJtffNGp3lXbCiV+1NscZE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=OfsxIE48AmtOZOEKmQl+3i2K0gwp/PE6R2k4rq+0KxpoawvdhJesVkur+mm37QdrhzNHUGdaq oj4OQt5lD77DAcXoKLUqfJZKPntq+j/Ns/1Dg0VH14R+hYkNi/yRa3mpF8i153tOa2R4U2I+kCs Y7E78PvTrzSUfoBWd5ToBATaBhO2mbvCRQ8U5Z4xFamSyIG3pMEVxU+MqnSjklRxrdIsy8s6j2X ZofhodEdFgpuOmw0OuoxCW6dw14l7aMYOOwGLwUxjPxl7WNdT5QiTjLalZA0PT+GHNGOLVJKPtT g3vA23zqTfg+TKlLP8cmIYBOFMs+X/lANRVNyOX/bgBg== X-Zone-Loop: 4d9cc59b5477daf916afe61b49601a5519fe0e41f1b0 x-campaign-type: default x-transaction-id: e17ceb3e-b243-4aea-974a-117a6120a76f x-swg-uid: 01-7267bdee-e470-42f0-9049-e7976a211579 X-Mailer: Sweego Message-ID: <1792509744.8631fc262581453bbf619ec5b2062170.1a159e814b4000f79f@vates.tech> x-swg-bid: 1792509744.8631fc262581453bbf619ec5b2062170.1a159e814b4000f79f 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 v3 18/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: <109f3a920a2f5e58de5889ac2bcb834cc7ce967a.1790779209.git.oleksii.kurochko@gmail.com> References: <109f3a920a2f5e58de5889ac2bcb834cc7ce967a.1790779209.git.oleksii.kurochko@gmail.com> Date: Tue, 20 Oct 2026 17:22:16 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792509737; l=491; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=vtMID585poca8HxU8wRTPoLjs/QKL8NbS608vwd2X0M=; b=rYlF/9ERW9OzLcGiBrCh9Bp15DhDC1LWwE+BC879rZFIIaZb99WEICClp2ZY27kIC+Hf+jzdv KH1P3Myl+wjADXJT3ZQ7JLc0aEgcDlNbSL1K3aAtReTx/8ub3Oub1Zh 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: 1792509743730 X-purgate-ID: tlsNG-bad1c0/1792509750-3B8D1034-14D6287A/0/0 X-purgate-type: clean X-purgate-size: 491 > [ ... 54 lines skipped ... ] > @@ -107,6 +107,11 @@ > #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) Nit: STVEC_MODE_MASK needs a third tab for its value to line up with the other two (and with the surrounding #define-s). -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 15:25:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 15:25:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456013.1669609 (Exim 4.92) (envelope-from ) id 1xJBid-0007Rk-0k; Tue, 20 Oct 2026 15:25:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456013.1669609; Tue, 20 Oct 2026 15:25: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 1xJBic-0007Rd-UA; Tue, 20 Oct 2026 15:25:38 +0000 Received: by outflank-mailman (input) for mailman id 1456013; Tue, 20 Oct 2026 15:25:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJBib-0007RW-Q8 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:25:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJBib-000eg8-6w for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 17:25:37 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad787e9-e002-0a2a0a5209dd-0a2a4509ebae-12 for ; Tue, 20 Oct 2026 17:25:37 +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 6ad787f0-be1a-0a2a45090019-b9ff1c23abb3-3 for ; Tue, 20 Oct 2026 17:25: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 1a159eafd67000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 15:25:34 +0000 Received: from [10.235.238.14] (149.173.185.81.rev.sfr.net [81.185.173.149]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 8A22581B42; Tue, 20 Oct 2026 17:25: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=iMNbXnQojxE3RDP3NV+8nCNWDfjppYbWdupluVqSX84=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=kb2F3rKZRnnciG6l0Dj6rt/xHXK1RMhNfEJjBMOTZY3p+E788gb0i5FJnYYd4dNr9n+NLXhBL IwzHolI3kQcEDPIvmddV+mMam0VOIIFrbinIVxRU94gmAnJLyzisYAjuFJ4w+MpVUdkQ7pR0tOd HLQFSv8XyZW2Ewee79y2yl14+rsInIuIuJgZ5Kyg3Jo5p7pj846ozJ00pHOAKS/iFNDLs33IXJp iSXDRzwuEueh/uaE2LEBVHBjswQvSIXBZsyoR3Abuc2RedXxZsudx3QGf0xGwIeVu04YOGdadyU WGSwcHwHlA4GyF+LY9+qi3AgWOlhtad6kOm+z2PMzLrQ== X-Zone-Loop: bbeb4a0e07162980e2072ffaaf1d53ed534f2bd2a041 x-campaign-type: default x-transaction-id: 4c5e3e1e-aa5a-4356-818a-86202c327b7e x-swg-uid: 01-10db777d-4c53-4b5f-9762-48d391950c53 X-Mailer: Sweego Message-ID: <1792509935.8631fc262581453bbf619ec5b2062170.1a159eafd67000f79f@vates.tech> x-swg-bid: 1792509935.8631fc262581453bbf619ec5b2062170.1a159eafd67000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 20 Oct 2026 17:25:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 18/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 , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <109f3a920a2f5e58de5889ac2bcb834cc7ce967a.1790779209.git.oleksii.kurochko@gmail.com> <179250973602.489973.14893581320042795275.b4-review@b4> 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: <179250973602.489973.14893581320042795275.b4-review@b4> 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: 1792509934324 X-purgate-ID: tlsNG-bad1c0/1792509937-BE2C4034-E64F752A/0/0 X-purgate-type: clean X-purgate-size: 613 On 10/20/26 5:22 PM, Baptiste Le Duc wrote: >> [ ... 54 lines skipped ... ] >> @@ -107,6 +107,11 @@ >> #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) > > Nit: STVEC_MODE_MASK needs a third tab for its value to line up with the > other two (and with the surrounding #define-s). > Instead of this small Nit, everything LGTM: Reviewed-by: Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 15:26:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 15:26:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456017.1669618 (Exim 4.92) (envelope-from ) id 1xJBjg-0007tz-9t; Tue, 20 Oct 2026 15:26:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456017.1669618; Tue, 20 Oct 2026 15:26: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 1xJBjg-0007ts-6m; Tue, 20 Oct 2026 15:26:44 +0000 Received: by outflank-mailman (input) for mailman id 1456017; Tue, 20 Oct 2026 15:26:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJBjf-0007tk-CN for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:26:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJBje-007EWe-PT for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 17:26:42 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad78832-bab6-0a2a0a5309dd-0a2a4504a2e8-2 for ; Tue, 20 Oct 2026 17:26:42 +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 6ad78832-b57f-0a2a45040019-b9ff1c22a769-3 for ; Tue, 20 Oct 2026 17:26: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-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a159ebf27b000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 15:26:37 +0000 Received: from [10.235.238.14] (149.173.185.81.rev.sfr.net [81.185.173.149]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 5A34681B46; Tue, 20 Oct 2026 17:26: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=ubw/UeBhaUnN970jvtac+P7O/b5BLLuiZYReumryN/c=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=F1gRHGzYErx1sECUYbmsZoX+zwxMejhhID8g39vfI9bqPa8pB3QElDT51U2zwQLTTwyJkYzpI 45HAR+ebU8XPoBpVIdtktv1DDOjNj/enNCE0c5GLnndUDM2yT69N5s3WMrPiM05Pv/8gFOi//QW u4XTOwgAo5STnwjG2xOdhzOppMdNRDNTS+dQdJTLfZN7cJzTjQzYYiFLyixoW87C3NnypGOnhRG szrLJTuIbVoyRJfwmoqIGm+yN/PAHxlfJSeLjrfWvQihAUwIQAfh9duLSCW45c3tOgsqAvjzy32 BjbegHJKbTqDb7yT+qEvCcAglp2YGq+qYmXtI/I+pjBQ== X-Zone-Loop: 8549f672b82ae0df8fe42a4f65f39dc83a2742594a2e x-campaign-type: default x-transaction-id: 39a62f09-c5c5-416d-b290-b2c4ac254466 x-swg-uid: 01-35d9f8ec-a3fc-4ffb-ae7f-573b977016ac X-Mailer: Sweego Message-ID: <1792509997.8631fc262581453bbf619ec5b2062170.1a159ebf27b000f79f@vates.tech> x-swg-bid: 1792509997.8631fc262581453bbf619ec5b2062170.1a159ebf27b000f79f 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 v3 19/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: References: Date: Tue, 20 Oct 2026 17:26:29 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792509990; l=822; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=7siBI3nUXyNpzfgQa+AIqtZCKfZAe6zYq5apcGqImdc=; b=VA9Yqk3cmURPYMelrBx11P44PREr5WPASwAiFChOCO+T1GHf1TqcXW40k9R+OVarW86Q+ske7 fYxM97yK3KVBQ26kVmu4xGr0OP8PNw6HqjQkjr401EsKZV8VqceckeW 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: 1792509996983 X-purgate-ID: tlsNG-ebf023/1792510002-C26CAB50-35218D66/10/73395122804 X-purgate-type: spam X-purgate-size: 822 On Wed, 30 Sep 2026 18:23:38 +0200, Oleksii Kurochko wrote: > The H extension allows htval, on a guest-page fault, to be written with > either the faulting guest physical address or zero. The 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. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 20 16:25:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 16:25:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456055.1669631 (Exim 4.92) (envelope-from ) id 1xJCeS-00033T-FA; Tue, 20 Oct 2026 16:25:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456055.1669631; Tue, 20 Oct 2026 16:25: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 1xJCeS-00033L-CM; Tue, 20 Oct 2026 16:25:24 +0000 Received: by outflank-mailman (input) for mailman id 1456055; Tue, 20 Oct 2026 16:25:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJCeR-00033C-0d for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:25:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJCeP-005Bng-VC for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 18:25:21 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad795cf-2eae-0a2a0a5409dd-0a2a4504cd84-48 for ; Tue, 20 Oct 2026 18:25:21 +0200 Received: from [209.85.128.181] (helo=mail-yw1-f181.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad795f0-b57f-0a2a45040019-d15580b5c835-3 for ; Tue, 20 Oct 2026 18:25:21 +0200 Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-8b0a28a720aso28825877b3.2 for ; Tue, 20 Oct 2026 09:25: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=linaro.org header.i="@linaro.org" 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=1792513520; cv=none; d=google.com; s=arc-20260327; b=V0qjYftyTzP0LwTptOO8VLmrhVHFM+iLa8EDmZaKZcPhia35fcVAvYvfMJOoEHRhWZ UVFne4TQNYgnbYl1VsqZ6Mr8/WK9GjTd67NaT0w3kFGm0v7X53r6AQ3s17Yk1Y6OSkEI DSOOxbE8PlgnmsxFGyRuGLP1NaxOzZW10UoamSMmI0h1AZclNsXKEKB56/XJyTYVp0M2 nDv0itgKzD6fcvkOAJDuaggdH+NHeKC41Ki2VZGDbMQs+WM4F64CHX9jC99Zru/M67T1 1CgTetRcOE0y3hwHQ4L7tcdFecTBgYqLrKCJ6s5dgEhj1HD6W47xVn2MisxPsMrlco+2 DFIQ== 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=ZFyRHRWDimKsIXLTtocAbmFsZAPHL360YzlKcMjZ5HQ=; fh=Sor44lcO/HuxlF0plnZ84yfSXOxLUpVnOB7003u1YV8=; b=lbgH8ps7MCYtjXbBG5tQ6fz82bWwLt9cpF6EUZdwmTcbhGOnDNi4RzS6BURH/XB/rg bl8kYemgGu1YVpnTLrSh5UMmbm2I3bQfMYXv6fmB97a4gUPxGAAoG/UaPGVyIQ0rIAcA ZVE/XJYP8L0x5CbkkWgWozqMmahHKqN+pBH8rInKts7L1yCvFsuFbX3u/KM5c6na1S7P Y5FtlTh4X7SAm39WT0MIvYMFYkC833bDugEf/iaB7SlorYrY6nA16yA/J0QMTZ9jZzez NfFC/sxeT0gUq28OttrGl2G/vqOS2BN9BNuVjkbuBAaUKe6QrzyJUKEHLj3AtG4lsBg2 AL5Q==; 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=1792513520; x=1793118320; 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=ZFyRHRWDimKsIXLTtocAbmFsZAPHL360YzlKcMjZ5HQ=; b=J3O80HafeNKfJ4kw2zCBdyOtjg/wLQg29mvHcxWi9qkwOg0vlApJ++xHaCZ+IjXQx5 FsFD53j24WqCt3NMQbxe2hEijVxIuXcLCiypHrxGAdzfRq99ZGR8ZY1vrye59Ne4dZIe s8zQ3M3li9+j2k6huJHIYHDP5OCpvA8W4J7JV1YePc3y4It4dZjBnUvjru9F8dxhYZLc nH0jb54ufovCcssisaOcrCFCM9bX6Tp4fkrfjeOp0Ra/mFor6wTNazKs7E1CWFGhxnZt rMvrmoovJN+5FI8Y1EHTHP3Xca2llXlsDwTgnqrenMHtqYSVmxQbAWgDFZ/EkjnXCsT8 NiUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792513520; x=1793118320; 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=ZFyRHRWDimKsIXLTtocAbmFsZAPHL360YzlKcMjZ5HQ=; b=zDPfI7ZJpBePyVBikUd2Orj3OxYsX02YFVQYK10GYVovv6cHytShsAQhayOQk7OEdp xwGDa5V/9LF5lJQwqBPChODOQ3cxVo7l8qSgOfvLpzL3S/jIMXPuyxhp2fRK3Hu3rJyo 2M2EK5DvdCUAyfP507DKdSSztwtzxvGjBnqWU6r7Mbrs/AFn1pfAjyQcQOAjF6zn5/qc 71wJFFG78N11zHoNUcwGA07nD786HStg7mxW02zx/X/FogRIlWBvqirDripn1MF5V/AD T/Nwjdyje+z8HvHVirfjDqbIpJP+eWfc9uYlQ3oVo0Kz5Dac++hBe4xsR+6/B9RE6vhP JRAA== X-Forwarded-Encrypted: i=1; AKwUvBxUQvjvPhaIIu1GFLuEpV5+C9+ud7B1izFJVDtGM+ql0VV359a2mZE2PABO9zabtkFZXHzms46UzUc=@lists.xenproject.org X-Gm-Message-State: AFq9FYKlSbpoLWsyTq8vLlkcU4+C896ki1RMQPJIGriYbJj0p0OkVviQ 8JQodliuMlt0SqH3rcDH+dTZiM9Dp/IHe0NKNLd4jRab3j6SAUYcnSuy2lI6fVx9HIerMsiNuFh 0rfZ8QVjQOnDwGs101wZNbJ51Myi6+XAztu99J4g9vw== X-Gm-Gg: AYBFou3jxNa48MQTcoxbgycA0Oq/dEMav9q0tv34D/5EdBNPogRoemtHDxY6wXGDZW3 5mKtJ65rPcI3tMW/8drpoI58QqhskICp632zRh6tV9rZFAid4vG8XYjSO3aiuw6NX2PAki9f72P Qz4iCJUQR5dUv2LIi6j6/YnZdGdcnmAdGtKBxUXb6P/hxHe9VFKfTCxhb0AGenj72qgEbASuAXN HP0ncfIXRlBPVvm9PVFxrfDB5VhLo6nHCAP96ZDrumj+jCsHwL7pxkr/qzARuxz/FCG7IvpTe0n rQuNgwYft+IXwCCXwubndhlSrusG9Chq3G9Ogicbf5cwmAHNU1XW4LEwv/IpSvi9KJam92faEgB 6htSDCHf0RwG9toqpcbpCuPo0iiVyQLdVdh3U1Sano9saOpppgA== X-Received: by 2002:a05:690c:f04:b0:8b0:89ea:6aca with SMTP id 00721157ae682-8b0f205b7c7mr41948537b3.6.1792513520046; Tue, 20 Oct 2026 09:25:20 -0700 (PDT) MIME-Version: 1.0 References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> <20261019120517.1448687-20-mark.caveayland@nutanix.com> In-Reply-To: <20261019120517.1448687-20-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 20 Oct 2026 17:25:08 +0100 X-Gm-Features: AclHuK81FSUXc_eOw_N_QDMC3HNYDg2Uzn43k6DU9fOUomcs44mfgMQdEdvyF6E Message-ID: Subject: Re: [PATCH v3 19/28] i8259.c: introduce TYPE_I8259_PIC device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1792513521-587C6B50-88F6F1BC/0/0 X-purgate-type: clean X-purgate-size: 351 On Mon, 19 Oct 2026 at 13:07, Mark Cave-Ayland wrote: > > This device represents a PIC for an x86 machine consisting of 2 cascaded i8259 > devices wired accordingly. > > Signed-off-by: Mark Cave-Ayland > --- Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 20 16:26:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 16:26:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456059.1669642 (Exim 4.92) (envelope-from ) id 1xJCf5-0003QH-Ot; Tue, 20 Oct 2026 16:26:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456059.1669642; Tue, 20 Oct 2026 16:26: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 1xJCf5-0003QA-L0; Tue, 20 Oct 2026 16:26:03 +0000 Received: by outflank-mailman (input) for mailman id 1456059; Tue, 20 Oct 2026 16:26:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJCf4-0003Q4-KU for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:26:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJCf3-007Mu7-S0 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 18:26:02 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7960c-bab6-0a2a0a5309dd-0a2a450ab9a4-22 for ; Tue, 20 Oct 2026 18:26:01 +0200 Received: from [209.85.128.178] (helo=mail-yw1-f178.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad79618-f2d2-0a2a450a0019-d15580b2cda2-3 for ; Tue, 20 Oct 2026 18:26:01 +0200 Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-8ac4806e210so23541957b3.1 for ; Tue, 20 Oct 2026 09:26: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=linaro.org header.i="@linaro.org" 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=1792513560; cv=none; d=google.com; s=arc-20260327; b=DbsGmoIWSUO6o7eMJLLnSSqzuMDdiGjTV4BmXnFJLz0w8iVfbLCQO3m7+t446qFqz8 gr55bJqs6EtVdntfjiKybiKgg3dQSibFRX0ehkxGPtY9Zkz26L5VlIPmO4tF7wFv0OYA pZg5kIlsI27CZG2r7CJVC6rkQhJmGUEXcUVr4VRCcmCSPFA/j6on3eMXzF/XEK95atau 5J6k3oh9SNMRoqwy2AaDeRIwG9HFioAY/kvIpdK8WCJZot4PvvvuXIEZd9kdv9TD4m1k GkMUAMkVhMH2Q0b/mkUP5WNx23cZRgCxiAiIt5m5sdeLXh8C8OQFYSasO8HP0TPV/Egy CDOg== 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=0H70iKzAA969SR73zPnNY9mwxeFlOcwPhNOOkWbaM+Q=; fh=+I4aGsXiB3sQBf47KFdt6yKgK2EgnhNS0hiinzB3+Z0=; b=Nk586DfRqxFIB1WJ837Ne96tR7sUTDB6pTBOrTCG/5yegYjliF1rv1yes1MfLcAdNJ BVH/qW0RU3hE/Vtq3dGN4+9EFcZSsrVJaEbxrlWmTKk0Vv2Bu0poqz6zPlC2LkY65dQv wS5qx8xv18FQCtvd2spqaZSzrqtWT8fkXyrENmGS+AbsgO3DTmqhHLQq7ocVdgQZlfyT 9LnbcuxcZ3i5RqukBG3qamp0az8DiEJ+gKkTppv1w1NqzSYr1lJbRLeD0tYuSAwK4X9L FQa7Ffl4yEr8YD2n+5lpzWCY2OVaUkA/ze/znzvisGAWgKcWF+ZDzVmTZQt7FjokADu+ rl1g==; 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=1792513560; x=1793118360; 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=0H70iKzAA969SR73zPnNY9mwxeFlOcwPhNOOkWbaM+Q=; b=uo31CCkt0xHZHMt8X9mZpuBLBJLyLo3qKu4IaoPw8E4UHqdD7OhD7w6VqB9tzxJF5l aD4Pa0xSFc1F2eLJUyAtmfFTMcm7ubXiM7dl1t8BR+aF1SYHMkoolGkCvijnT5l7yYwY IHTRNr6V2ThJlwvVk3WHslJncir/3VXqFFIp2k7/KP4Wzx22F/YS6RLnI7+fUZ+0XIEz eD86bNNLWQkhZZYqQXt2fL1RsKWQBjg+b9mRfTObE+PlKjzM9/Mt8s7nzCrQCtgHtRkA Oa7GM/tstuLH0V+j4GBcyrzAnfs0GC1rzOo3AnAyZrOpBTrlN/CJF86o0D7djoksxyTz /ilw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792513560; x=1793118360; 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=0H70iKzAA969SR73zPnNY9mwxeFlOcwPhNOOkWbaM+Q=; b=cKmv4h1zLgt/qhE818g7lt+tBjY4nq9XqhRkX8VusWcAhxlwV7RFCICrJSu5lJLkr0 k9QrBPb9Sn313n4bSpGMCcTGP5TAqjSgOSrnYdYZeZ1oQeRiNdCj0CRLbUCEVG/CBJRX 4hcpbu9VhUv7LKIC9sZlEQc4hLN9DauTxepveTIpOlNe51Hbf64NUHtPphaa1ti9TdH2 a7y1gm9fAP3vI5dz9THGjuB0zfdjI5NUGd3Bz9PTm8UflbFiVc2/3UUgPkEbBvP8SCJK 22GThWA9ia2/ZCbtSuuPVeztBLagvp5v6qpAhqDwdCU+cYjm5vk8KW4q1i7HGORbrFpu 6bqw== X-Forwarded-Encrypted: i=1; AKwUvBwYueJVzHkFDiMD/aespkXMHOoiu+yZqZ93CTYZafXWR7fpVlLbEEgtkseL/0/NLxwUrrwqDmcpVTs=@lists.xenproject.org X-Gm-Message-State: AFq9FYJaMgmvg0ofLAfPJapzk9JaXZBql8n3cH581+jVbbyt0VaKk2sf rvpWelB91AkBKzjbo6oZIs42IgyC2D1en44qEcrB0QYn/ukjjFY6pc2IA1LjaCa321jI8171qup Ol1hRpwK4UW+IR6AnL1fN5zSvlsVVHrl8UUrEMCviOA== X-Gm-Gg: AYBFou3vvKbzWUV2ei7lQBmOvH0kP+QgjVsY0WDoLNcY0RyI5i9K/e2KpGVjCVLjrZV o7g5NDAd60LBOMmUdoY2mscA/zg0zxw8r+qu4RIwxuKxPqmTdhyyTlVn49qO4szrzNn8+dYVVYu 879Di7pEQB5NIfCocSbimj8c8hqZgSaP5Wpmbb65pUwqlOKg7JpTeIHGYgbMeLv+9JNmO//qznP MXA99R4G4DnmRqCABgqq8xNPd41paiBvCOrPi5b16Ka58ZhaGZPzqFYYtvsGi2DlKgSDg7rpSfj M0HhFd+uWsq3cxyC4DHtQCxsafv+djvmdDPphNaRbABxFMDmlN4w3RaUBNMPMsdvATV4C3B3hQz uFfUO0Izj2sVj2sGCkemYCjmklb2NuvES8ND9mxM= X-Received: by 2002:a05:690c:c4e9:b0:8a8:6a39:37e0 with SMTP id 00721157ae682-8b0f21973f2mr38103367b3.42.1792513560025; Tue, 20 Oct 2026 09:26:00 -0700 (PDT) MIME-Version: 1.0 References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> <20261019120517.1448687-21-mark.caveayland@nutanix.com> In-Reply-To: <20261019120517.1448687-21-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 20 Oct 2026 17:25:47 +0100 X-Gm-Features: AclHuK_WLO7-DtB7Su2eRjiC_GGoRME7VJlerd_B7UXaWvtf_V6xRSQGWvB8Jog Message-ID: Subject: Re: [PATCH v3 20/28] i8259.c: properly cascade secondary i8259 from primary i8259 To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-4011c0/1792513561-510C9CFC-48610D04/0/0 X-purgate-type: clean X-purgate-size: 706 On Mon, 19 Oct 2026 at 13:07, Mark Cave-Ayland wrote: > > 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. > > This is a bug fix since in a cascaded configuration on real hardware it is > possible (although unlikely) that the cascaded input from the secondary i8259 > can be masked on the primary i8259. > > Signed-off-by: Mark Cave-Ayland > --- > hw/intc/i8259.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 20 16:27:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 16:27:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456065.1669650 (Exim 4.92) (envelope-from ) id 1xJCg7-0003xp-4R; Tue, 20 Oct 2026 16:27:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456065.1669650; Tue, 20 Oct 2026 16: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 1xJCg7-0003xi-1C; Tue, 20 Oct 2026 16:27:07 +0000 Received: by outflank-mailman (input) for mailman id 1456065; Tue, 20 Oct 2026 16:27:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJCg5-0003xY-Ri for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:27:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJCg5-000naL-7i for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 18:27:05 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad79659-e002-0a2a0a5209dd-0a2a4504e962-0 for ; Tue, 20 Oct 2026 18:27:05 +0200 Received: from [209.85.128.170] (helo=mail-yw1-f170.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad79658-b57f-0a2a45040019-d15580aaa97d-3 for ; Tue, 20 Oct 2026 18:27:04 +0200 Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-8b0d91601bdso6799257b3.1 for ; Tue, 20 Oct 2026 09:27: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=linaro.org header.i="@linaro.org" 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=1792513623; cv=none; d=google.com; s=arc-20260327; b=aPfGZoiiqBuEtpHNX/pcZvFmX8zRJYny/B6heYqDPy7M4w5cHC+Ym60CdPb6nldd8+ AtppYxXRSc/XSUL6XUOb6E7bW/9G5G93kMqtHZ98+nQO5JPmm8YuSjJU86LcYO8ujYpb 9TPUzQB8QE7LF1XrgOqQ0IycL2g2/0AwVfCINvhZpAh8sA0JPbjeSX3AzQvUaiYDdOGS P+1zFiDzHI4UXqPL+e1qgdIOeMgPQs+bWHi3MJcyGTJMmF5Y42ZRi+sTu+Lg8/2T+Q6P sPHxRYcah6Zexc+3Vk5zm5/bDISYEo0GcpZjX+KyJ8GT96Ts3s9pidfaEoVoR41npU6m 24hQ== 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=ciUzy2+xlwruDHhswN3vsLK0iURu5Kl9UfgL5Gb+gTI=; fh=DA7+rEDi/jik/Jat4OYXFJ3IXVddQ4s9xwUieqyoZdE=; b=NAuVOj0VhE2MPqvj5G73igT5koSd2JfaaIZfxkliezRJNsTVxh2PPJYwqGBOxidx1f hFQssQncbw4/qS8Jc66PzpX3K72/JhNnNgTcOpHsq7nawVqyY5dC2p+KK0O3EkxkrUly cPl/efdXYTk/cf8QUDex4skr9ug4bmQ6ECIzEIc8TGu954qZLA7Sr6cSOPqZZA1gOXSO HTFHdGqA/FdEWkl9LeztmbMRhHrF/6EIaZH/yUN6PoIR9K5RvEZ2vFQQofXht5gqfW4e 2AmUmOjUOKocWttfsVUEobqYanMvR3k2Cdj4OW3IsH0UJWbPgbD9Sx3mosHm1okYTjLL vH7g==; 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=1792513623; x=1793118423; 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=ciUzy2+xlwruDHhswN3vsLK0iURu5Kl9UfgL5Gb+gTI=; b=erLoOGGbeqov4tjboAtSY6XHYini7pwZ7ojpHgIdRR0Ubbdm5Lp+C6I6SpBhaikWXz yQTDQLlAXfJSWBVvEyd5cw+zVGi3i72/M4c6GSzUsHpypHTxXoie1g4TtGOYExuktHt5 wuucEr8UXgXi3QuYD+2X9qYlTlEA3Dhfz0AnzH7lT4Peraxej4MXMfptaD8FNOhAvcK3 JcjLpWKaFhMNm0cCdRRlOYL61x9yIiuqYE3oBxR6NSftIH0IhdsU2giH3s1ZXJlJvMmB zWRqWh2wyEVibrVr2Rp/aTVAUuly11G60tLOXgOA0LEPvps6mJLv86122I+KTlh/uiX/ xdvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792513623; x=1793118423; 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=ciUzy2+xlwruDHhswN3vsLK0iURu5Kl9UfgL5Gb+gTI=; b=hrkhoxpUULfFvIyZwXc6wLdyMNFFFQINr/E2KVd+SUhbOk6b+AljxuBtsyEdmC7aVZ 56SETT6gi8dJw8gUVT9k27ygPtIpqWkAflsWRBhYI+8Er7pip2hIxQA6C/udUGwpm26K oD9KvNk2Y3+vAoHIN+GnrNycepo10AMNRWp786suywreiQVvS8wXLyMQBzBRBqtgRIy3 zOQxiHAdLkoPT2Hn0zIyHE8d0v2rXs2JVXkx4GfyQrjQdbiEnPD8l6C+GxTZUhZEZIUD HTOm5HfcVTk+QjG+QweAkiRDYCkVScOeIy+s2bc4oy0McmkMl43ePIW0BUj/kdeBsjZ2 IzfQ== X-Forwarded-Encrypted: i=1; AKwUvBwDtfsPoQ00z1uMr8JAv33Z1zy/hoKbZ+71qFWqHuZ2RJ5qA3bCT/4IW2jm6wUZqSgdKdG2u+CiVjo=@lists.xenproject.org X-Gm-Message-State: AFq9FYIhcaHAWEeAqPx2gOLZJxLaleVPVIqe2clDGssqDl4VVsFRxh1j 0zCwS1nQQNqNWZmoV2ex1oiDjdfkmdbnYrTBAx63G1TAlTS6OnInzeevyls2HaVH7+4VKnPuqQo idncl7sYEYYVBZuyJBGaSuCO2xVpLECCv3QySVLT847/ahWQrwgY5304= X-Gm-Gg: AYBFou1OfHw1BSTl6mn1xNB6Qw7TjbXr1V6Pi5IJM8D9y/vQSYFyzWAy9uq1eWtSffJ nmCMbrh8vmcHmGbfDdg7oYMlxowcPL9JWjrKe+r90HalOn7VwfPvOnlSU/w5dnyIAy80ln7Jc9+ Vz+/SdR4Xe5IRwnc6CdQn5MFaKUJfN3rUzrBJFKgCzlD65SgbST86tITXcrJQXnX+yr0wUK49L7 XeSuIl/osxesriipJ/bNGkyEwqbu3uSrLUtBTSWp0BdzpzS7AHjKtDd35ZBuoeULh9fivupMTRV /1sws/o6WzWoddifK02Dj9WK6Mkt6Abd3Qw0Yurf9fVw4226B57lSzefZeZwjhntR2aAUFPWIda 6POKX2+Bc8t2zSFNowjUiZW5itBSJSCkiYEVVpg8m0ExYI/4YFQ== X-Received: by 2002:a05:690c:288:b0:8a9:9f40:24b4 with SMTP id 00721157ae682-8b11ffdcfd3mr9303527b3.15.1792513623300; Tue, 20 Oct 2026 09:27:03 -0700 (PDT) MIME-Version: 1.0 References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> <20261019120517.1448687-22-mark.caveayland@nutanix.com> In-Reply-To: <20261019120517.1448687-22-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 20 Oct 2026 17:26:51 +0100 X-Gm-Features: AclHuK_GG3xd3jb3G-pcWY9ph0D-7_Tu77TTN6sv2RLan-q546w3SCV2MEkiB-g Message-ID: Subject: Re: [PATCH v3 21/28] kvm/i8259.c: introduce TYPE_KVM_I8259_PIC device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1792513625-512DCB50-45E2A351/0/0 X-purgate-type: clean X-purgate-size: 435 On Mon, 19 Oct 2026 at 13:08, Mark Cave-Ayland wrote: > > 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(-) Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 20 16:27:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 16:27:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456069.1669658 (Exim 4.92) (envelope-from ) id 1xJCgr-0004Og-CT; Tue, 20 Oct 2026 16:27:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456069.1669658; Tue, 20 Oct 2026 16:27: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 1xJCgr-0004OZ-9p; Tue, 20 Oct 2026 16:27:53 +0000 Received: by outflank-mailman (input) for mailman id 1456069; Tue, 20 Oct 2026 16:27:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJCgr-0004OT-1F for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:27:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJCgq-005C7E-Ae for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 18:27:52 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad79684-2eae-0a2a0a5409dd-0a2a4509ae98-8 for ; Tue, 20 Oct 2026 18:27:52 +0200 Received: from [209.85.128.173] (helo=mail-yw1-f173.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad79687-be1a-0a2a45090019-d15580ada4fe-3 for ; Tue, 20 Oct 2026 18:27:52 +0200 Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-8ac8a2ac52bso10132677b3.0 for ; Tue, 20 Oct 2026 09:27: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=linaro.org header.i="@linaro.org" 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=1792513671; cv=none; d=google.com; s=arc-20260327; b=c4z0OZDvpKTUeSuUVK6oUt3V/MobWlFJhHnSSPgVD6ZXdzdzDtP0yw5l2ttl/Bw80I A7BE2bsHQcxxYMEdiFC14aOUODizRf5FJBLK5KuIIFvtCQ3AYbDsbhgI3vUi0jt3+Jeu +5JAssMJGfTkzaHu1E099GZE/SJGey1ifWlBfOFCCOy7wdQkC7rt9upGX4GvuFpgnPpb mE14Uo/uy1Mqzqbcj84ADTD+C0DpiakQ2pvLAV+A0OInbyuR5dDsNbs+T0Sl9jWUsGyv 46ZjUeuasSoyokgDhMeYIajMIvPxdUGIN1zGgIXxhUsM9x6U5g3NCiWg2EXImxuWFErv 8RNw== 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=avYRdodUQ6KiGgYB+yLXS5NG80XwFq+SqjqDPGJcPQ8=; fh=t6Pfkup9bzRm+DllxMjYUuFoGvPj2Ty/Ugz1X/ldDi4=; b=sSsqr51sX+lNmYuIwUO96CWaMfGl+lnD/Xdk9n1SY4/4Mro5vLVfaTQBdRaHdJSC19 fAcDHiZBBTEkEvEAYY3Uc9JtFX7afdU3UDjSigp03oceMPIrvE5eMtYqNWkSg8qc5uEd 8qBniQ0nTuPht5k+R2unzk6elUgqwLvl9KWwpxXcm2cAaZ8osxEcSyuenKQMMyDe5Glf Ug6o8fyG4/aEJKN+/i8Be357VSlK06LOgAILx0TZxoseYnSu3Db4y38cPiMhirXg8cgy 4xJNksX56lf8tY0T3joikk+G8rn2jNN4w/jEGsODtbbz8oA0a4EmMr8PnY0CnuuOt6aE M9WA==; 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=1792513671; x=1793118471; 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=avYRdodUQ6KiGgYB+yLXS5NG80XwFq+SqjqDPGJcPQ8=; b=Z8XVtZ5DEfKZFcOafdJkA0jWWE4w8RXxoWx642OCQnrzKQ+CY8lZ+RIuL9fpkQANZw 7a/IgP2455BgyedU4MTc33jJkFQtQ6j+ZinQ3p6RmEO2y/ogiqPRsCwVz6u+rAJsmlhW 56uL0f88WXNoWVul6efMmdPqm7uUzEcwGxa8529MFxUhUziLdUbvSSPbWfh8GcFsZwsd fPXOFIOnLL5LoyRP55Do275KAe2izocazQvDKDOQ3yGxSnHpvkAhzJwnCTBlYcIZmpR5 H4ljhzO0aCVBOVQaHAoI+VREpE1fXPkIM9dlQ57M6c0kBm+vtfLELCZyMBVSbDyZEfyS KTrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792513671; x=1793118471; 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=avYRdodUQ6KiGgYB+yLXS5NG80XwFq+SqjqDPGJcPQ8=; b=mcTKAIzOzwrKe43suQ6o8ZeByTEXN/LkJP6pIxmGsd2jSkHWX7/9aqEZhgmL0iAryM 08C9jy0aWFFtoXD23FlWceRxR3S4rXYFlNvUTHDwsjzg3aGrhQHX01knCEKWbBW5crjm 0FfTcTx8iFeCOKjGnUNwqu28kYp5idUvqRXt0NKf78E6VyVCOG+kZv53oKS1f8PZREi/ 5p6lmW7y6HuKwdQ2p9BDg6wqsDy23BMzgsT0piEoTep+WTWIxZ775reVgor4zwCcV7C+ 6ChvqR/4rDs/4Bu/rSmSJxqv7H4zPGIE3+vl/urP2Pv0LWuj7ASWY2ZDtooU7mHCVdGE IsGQ== X-Forwarded-Encrypted: i=1; AKwUvBwYz6F1UrkPg1zpsZe+j31X5e5GaAdE2W3WTT7fkZm9K3aEGCKh81Nqcz5HsvA2l2Q7DPAn0NVJ7WE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJxOSdK2Eiy40v9W03g4My18s6izqC7b7XjSH4DxuZzXDMy39nA eZaBUIDb4CXhOmIQlEEysFF0LJA9npqVRu/GnKuWcl+aHMFn/eCUh8lT/Gf1qSwwElrrH8A8J2h 9mXqOjLlfhRynPpnJSeIqsrdOCmk532toVTsGD+mZrA== X-Gm-Gg: AYBFou1OM8ewOeszcJSh5Z8YVX101aB4AbqfpbiudoSgGCzOahjKqYCZoLIaTUiAU30 jxx7Wta/FmPC5tTZfj5XOVULsE8rUW59dwX/9w7Hu/ibYKtJj225YqKYbkJUEVEHI0a6ZaVVTWE 2/9h1Srjuaxy1dobbsOJm33OEUXpkwT88Flc6J9AUDTlIc9Uk4P7twiuZZPSah6QGxPfNF9bHPG kek83Ub1eQgT6p0wmF6ZWmT+hPxiYmrL8ETXfbfs6gid3fkSZ9aDhw2ZaklTKqy22QXFpm1o7dT rXD+7DWzcUc1Y7ccTdKUpXxB603kYcsSbUso4SX4MUe5OyYNsRQhakoNURMJq5ok3aRcJD582zO sdQTlC9PURCNejSmCtDnevBq9giI+FbcKXhk2jnI= X-Received: by 2002:a05:690c:397:b0:873:5c7b:c136 with SMTP id 00721157ae682-8b12023edd5mr9254677b3.30.1792513670500; Tue, 20 Oct 2026 09:27:50 -0700 (PDT) MIME-Version: 1.0 References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> <20261019120517.1448687-24-mark.caveayland@nutanix.com> In-Reply-To: <20261019120517.1448687-24-mark.caveayland@nutanix.com> From: Peter Maydell Date: Tue, 20 Oct 2026 17:27:38 +0100 X-Gm-Features: AclHuK-LxX8V8SUjcf5mPQUtqxySvk3Fvyjs4x_5sidwHX23zHXcCnE77fpNL7s Message-ID: Subject: Re: [PATCH v3 23/28] xen/xen-hvm.c: introduce TYPE_XEN_I8259_PIC device To: Mark Cave-Ayland Cc: 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 Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-bad1c0/1792513672-BD8C1034-93771274/0/0 X-purgate-type: clean X-purgate-size: 422 On Mon, 19 Oct 2026 at 13:11, Mark Cave-Ayland wrote: > > 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(-) > Reviewed-by: Peter Maydell thanks -- PMM From xen-devel-bounces@lists.xenproject.org Tue Oct 20 16:54:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 16:54:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456087.1669668 (Exim 4.92) (envelope-from ) id 1xJD6A-0000z7-Bx; Tue, 20 Oct 2026 16:54:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456087.1669668; Tue, 20 Oct 2026 16:54: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 1xJD6A-0000z0-7y; Tue, 20 Oct 2026 16:54:02 +0000 Received: by outflank-mailman (input) for mailman id 1456087; Tue, 20 Oct 2026 16:54:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJD69-0000yr-7g for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 16:54:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJD68-00E2lu-KB for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 18:54:00 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad79c90-e002-0a2a0a5209dd-0a2a4505d77e-26 for ; Tue, 20 Oct 2026 18:54:00 +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 6ad79ca8-4cb1-0a2a45050019-b9ff1c22b1f7-3 for ; Tue, 20 Oct 2026 18:54: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 1a15a3be15b000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 20 Oct 2026 16:53: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 491E881DEB; Tue, 20 Oct 2026 18:53: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=03U4Gp71EJX1XZmHAY2plSaL9UCiNO03ffGZko0HxOQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=FgOWvvIshurWgFvDIgAqNA17TifWNTemgrfwd47cp5JLmEHd1/F6m0pxR6DFYKKb7uluoA8sp TBp0pm3gtYPmatP52ZjAS0vrybtGW/To3NY1htr6XZJdeWlU9SxqCAifmrad5Yk1Fibvn7Uah7x VJrNP/VxXSL68RvCoWcelie1sBvCuClTgcwciLTRyoqADt4mRr3aMx4QK7UR41EFNwwI5wiPy6g swBEDNN7/sqfg3LUTcTRLN88QP4o5zkZ9qYbfsHI50neKpHkSvYnxjsLCyyfYKfxsBfcT8bEM6H wAFJNWQIqjBiKhTIJETozYx0UueOkh/bfDI5vBioKtsA== X-Zone-Loop: 1622391ff852450dc242ad066e87b960b37b5f478dee x-campaign-type: default x-transaction-id: 04d8d709-5e17-49a3-ab3e-fefa59a0aad4 x-swg-uid: 01-a4266813-cbab-47c6-8ae9-0ad831c36169 X-Mailer: Sweego Message-ID: <1792515236.8631fc262581453bbf619ec5b2062170.1a15a3be15b000f79f@vates.tech> x-swg-bid: 1792515236.8631fc262581453bbf619ec5b2062170.1a15a3be15b000f79f 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] x86/nestedhvm: Inline nestedhvm_vcpu_in_guestmode() Date: Tue, 20 Oct 2026 18:53:27 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.6b.3b5b6858a03e0815.1a15a3bde67.cfa53d779037299e=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792515235431 X-purgate-ID: tlsNG-c201ff/1792515240-F72B32A1-9321703F/0/0 X-purgate-type: clean X-purgate-size: 2050 ---=Part.6b.3b5b6858a03e0815.1a15a3bde67.cfa53d779037299e=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This function just returns vcpu_nestedhvm(v)=2Env_guestmode and would be better inlined to improve codegen=2E Signed-off-by: Teddy Astie --- xen/arch/x86/hvm/nestedhvm=2Ec | 7 ------- xen/arch/x86/include/asm/hvm/nestedhvm=2Eh | 6 +++++- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/nestedhvm=2Ec b/xen/arch/x86/hvm/nestedhvm= =2Ec index bddd77d810=2E=2E3205277e81 100644 --- a/xen/arch/x86/hvm/nestedhvm=2Ec +++ b/xen/arch/x86/hvm/nestedhvm=2Ec @@ -15,13 +15,6 @@ =20 static unsigned long *shadow_io_bitmap[3]; =20 -/* Nested VCPU */ -bool -nestedhvm_vcpu_in_guestmode(struct vcpu *v) -{ - return vcpu_nestedhvm(v)=2Env_guestmode; -} - void nestedhvm_vcpu_reset(struct vcpu *v) { diff --git a/xen/arch/x86/include/asm/hvm/nestedhvm=2Eh b/xen/arch/x86/inc= lude/asm/hvm/nestedhvm=2Eh index ea2c1bc328=2E=2E9e158bc5ce 100644 --- a/xen/arch/x86/include/asm/hvm/nestedhvm=2Eh +++ b/xen/arch/x86/include/asm/hvm/nestedhvm=2Eh @@ -28,11 +28,15 @@ static inline bool nestedhvm_enabled(const struct doma= in *d) return IS_ENABLED(CONFIG_HVM) && (d->options & XEN_DOMCTL_CDF_nested_= virt); } =20 +static inline bool nestedhvm_vcpu_in_guestmode(struct vcpu *v) +{ + return vcpu_nestedhvm(v)=2Env_guestmode; +} + /* Nested VCPU */ int nestedhvm_vcpu_initialise(struct vcpu *v); void nestedhvm_vcpu_destroy(struct vcpu *v); void nestedhvm_vcpu_reset(struct vcpu *v); -bool nestedhvm_vcpu_in_guestmode(struct vcpu *v); #define nestedhvm_vcpu_enter_guestmode(v) \ vcpu_nestedhvm(v)=2Env_guestmode =3D 1 #define nestedhvm_vcpu_exit_guestmode(v) \ --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.6b.3b5b6858a03e0815.1a15a3bde67.cfa53d779037299e=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 20 18:48:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 18:48:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456143.1669677 (Exim 4.92) (envelope-from ) id 1xJEsl-00076V-1s; Tue, 20 Oct 2026 18:48:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456143.1669677; Tue, 20 Oct 2026 18:48: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 1xJEsk-00076O-Uc; Tue, 20 Oct 2026 18:48:18 +0000 Received: by outflank-mailman (input) for mailman id 1456143; Tue, 20 Oct 2026 18:48:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJEsj-00076I-R7 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 18:48:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJEsi-00GFvr-U2 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:48:16 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7b741-bab6-0a2a0a5309dd-0a2a45099b58-40 for ; Tue, 20 Oct 2026 20:48:16 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7b770-be1a-0a2a45090019-d155dd33b99f-3 for ; Tue, 20 Oct 2026 20:48:16 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48e0d885929so2775928f8f.3 for ; Tue, 20 Oct 2026 11:48:16 -0700 (PDT) Received: from ehlo.thunderbird.net (dynamic-2a02-3100-18af-d500-ec6b-a832-f355-434e.310.pool.telefonica.de. [2a02:3100:18af:d500:ec6b:a832:f355:434e]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e2584afe1sm183030f8f.56.2026.10.20.11.48.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Oct 2026 11:48: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:MIME-Version:Message-ID:References:In-Reply-To:Subject:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792522096; x=1793126896; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id :references:in-reply-to:subject:to:from:date:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6FwV03BnljHvrYkJf+lErNTezJD62CanPfxXQ6NNZ5U=; b=kOYevv0r3Rb0nEI6cH6T4ZJqwv5Zc38Gfd9dY6usBSIXnl2xQCCb7saXki+JyeO59d ewir+Sh2XRWvr2IKU/mdI3sjB6CQn2IKtUrO5w+AehTsIbjvblBDGl1AqKfPU7UAq2bi lVCHKzUmgoQZf3c5ieAEM6QMPZrytjGB0IMLdh80fq+g1IsZ86O90NReF4BA1iwDizmO bJQNlNtO30CeS+9ZeUATMJRdScNUddXJFZWMsgv2lnntmJzubeDUob5JlASBGI4+eyo2 l317n94PNB8CorLnxxnOdIUNjT+TuStgZP4bkVXoWPT9Tw0EvoWHDKF8OalBrdiWS66y wZhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792522096; x=1793126896; h=content-transfer-encoding:content-type:mime-version:message-id :references:in-reply-to:subject:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6FwV03BnljHvrYkJf+lErNTezJD62CanPfxXQ6NNZ5U=; b=AZkqw2B1+Me6wDik1gLeJmrdkjBKo+YEiKAKRg/sxw0S+oNRCuyB35Y+AMioyMqzDY TxO+1wOeuiyo7Inc4uiRmhiOYFhAUN/HsLkqSn9NfHByWLGPgKubIv7sF9HqXRmBYy3h wg3fw4cL4aNh1vqvn5FQHbxHrPzbDJ/U5kYAcv00ADL3JYWK3NkQaO4qiwHNzDkG6aS+ 3Lr/9BhJyuhao0MRbTd1R1u5PAet8CQAdmmPoCAnjowbqGetCo6A7hOSoWGWH+YSBuB5 JeaX7rY/bFtfWn19DCZ1oIA+fuNKCuyStL5duNsJ6oVlW+cOz1RTR5ZQSk5Hdk7GDV06 8ffA== X-Forwarded-Encrypted: i=1; AKwUvByqr4YLQhL34JWmKkXDnc22CC1PoxcrsYMgM75FTslT9VElz7rSc7yEN/v2cSa9LVPEofItuEm8ZWQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYLR2OtPzmNyi/I6kxgiegqKjXQRih8qbtQVg86KgVrRZDqMc7Jc mGIEO6InlRIt8Zl+99ODLO5FFs5fVh8Bg1Rhx3kLePQiassbTT+1gXJv X-Gm-Gg: AYBFou1MVnu677bdLPQxCrlPTQn9M57NO7mH68pE8HZ661wGo4HFFcjkyJMwyV5k/cg GycinbgAJnlp34TSG54SLglyFaAfgqA+1CfMb6ALimF0jWkIR1SPyZyHcYwLOcUZ7ioyhJQH/Wv tQ4/mCvGyYBdvva4uBc+jO4SCJMQT09DaHNiOz0Uk3bD/akxw+9cC0nhn/9WS0rcK5NUsrbgojg 9czEiA71nmAMuUyuGixrte0d4J7/2FNTR4NXkD+3cT1Q0CXEsEZwFTGtD7Y0KW32DBaugrjjr54 GRG8EvkP0itRWrhkFvkWrlAqnADr382OuzrPKLzVk1YUEKAR4+YJz7XBwmOwFTSErhf+nJimiZ4 cweu4cQ/v7VlYrCexBJ57C7/5W71efU+I5JN/QfV0NkrjinojGOPhUboVc3PhQd2gchs2Uv2n54 7Sq4T3etr5E3z8C0iiCUHRDUEdp3n7TCJpbkYT2z/pdWq79Phg1PyyKE0YeBc7Vul1X5LcnQZDG huhp235mPb/Ge2V7wcMhqgp5nzVy4BTDzC8Q3CBAag7LUSOSioUt+8hdsaJRuGewV83Z9fYHu7a Nx87/3Wx3qpap22PJJc= X-Received: by 2002:a05:6000:4a0a:b0:48d:f14a:9183 with SMTP id ffacd0b85a97d-48e07bbc619mr25855899f8f.15.1792522095942; Tue, 20 Oct 2026 11:48:15 -0700 (PDT) Date: Tue, 20 Oct 2026 17:39:39 +0000 From: Bernhard Beschow To: qemu-devel@nongnu.org, Mark Cave-Ayland , pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, xen-devel@lists.xenproject.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v3_22/28=5D_xen-hvm=2Ec=3A_rename_xen=5Fin?= =?US-ASCII?Q?terrupt=5Fcontroller=5Fini?= =?US-ASCII?Q?t=28=29_to_xen=5Fi8259=5Finit=28=29?= In-Reply-To: <20261019120517.1448687-23-mark.caveayland@nutanix.com> References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> <20261019120517.1448687-23-mark.caveayland@nutanix.com> Message-ID: <22FB9414-4D72-4699-9FB4-107D9DF10F28@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1792522096-BEEDE034-C179D0D4/0/0 X-purgate-type: clean X-purgate-size: 2717 Am 19=2E Oktober 2026 12:04:54 UTC schrieb Mark Cave-Ayland : >This clarifies that the interrupt controller being modelled is an emulate= d >i8259 implementation, and brings the naming convention in line with the >in-built i8259 and KVM i8259 implementations=2E > >Signed-off-by: Mark Cave-Ayland >Reviewed-by: Peter Maydell >--- > include/hw/xen/xen=2Eh | 2 +- > hw/i386/pc=2Ec | 2 +- > hw/i386/xen/xen-hvm=2Ec | 2 +- > stubs/xen-hw-stub=2Ec | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > >diff --git a/include/hw/xen/xen=2Eh b/include/hw/xen/xen=2Eh >index e94c6e5a31=2E=2Eee4ed4f11b 100644 >--- a/include/hw/xen/xen=2Eh >+++ b/include/hw/xen/xen=2Eh >@@ -42,7 +42,7 @@ void xen_intx_set_irq(void *opaque, int irq_num, int le= vel); > void xen_hvm_inject_msi(uint64_t addr, uint32_t data); > int xen_is_pirq_msi(uint32_t msi_data); >=20 >-qemu_irq *xen_interrupt_controller_init(void); >+qemu_irq *xen_i8259_init(void); >=20 > void xen_register_framebuffer(struct MemoryRegion *mr); >=20 >diff --git a/hw/i386/pc=2Ec b/hw/i386/pc=2Ec >index 2d8c87b0e3=2E=2Edbfd55de30 100644 >--- a/hw/i386/pc=2Ec >+++ b/hw/i386/pc=2Ec >@@ -1167,7 +1167,7 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq *i82= 59_irqs) > if (kvm_pic_in_kernel()) { > i8259 =3D kvm_i8259_init(isa_bus); > } else if (xen_enabled()) { >- i8259 =3D xen_interrupt_controller_init(); >+ i8259 =3D xen_i8259_init(); > } else { > i8259 =3D i8259_init(isa_bus, x86_allocate_cpu_irq()); > } >diff --git a/hw/i386/xen/xen-hvm=2Ec b/hw/i386/xen/xen-hvm=2Ec >index d3ce082e07=2E=2Eaf3a90987c 100644 >--- a/hw/i386/xen/xen-hvm=2Ec >+++ b/hw/i386/xen/xen-hvm=2Ec >@@ -112,7 +112,7 @@ static void xen_set_irq(void *opaque, int irq, int le= vel) > xen_set_isa_irq_level(xen_domid, irq, level); > } >=20 >-qemu_irq *xen_interrupt_controller_init(void) >+qemu_irq *xen_i8259_init(void) > { > return qemu_allocate_irqs(xen_set_irq, NULL, 16); Since this function allocates 16 IRQs, the convention according to this se= ries would be xen_i8259_pic_init(), no? Otherwise, much appreciated clarification of the terminology=2E Best regards, Bernhard > } >diff --git a/stubs/xen-hw-stub=2Ec b/stubs/xen-hw-stub=2Ec >index 6cf0e9a4c1=2E=2Eb3e27f0292 100644 >--- a/stubs/xen-hw-stub=2Ec >+++ b/stubs/xen-hw-stub=2Ec >@@ -29,7 +29,7 @@ int xen_is_pirq_msi(uint32_t msi_data) > return 0; > } >=20 >-qemu_irq *xen_interrupt_controller_init(void) >+qemu_irq *xen_i8259_init(void) > { > return NULL; > } From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:03:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:03:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456180.1669685 (Exim 4.92) (envelope-from ) id 1xJG3L-0000gR-80; Tue, 20 Oct 2026 20:03:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456180.1669685; Tue, 20 Oct 2026 20:03: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 1xJG3L-0000gK-4v; Tue, 20 Oct 2026 20:03:19 +0000 Received: by outflank-mailman (input) for mailman id 1456180; Tue, 20 Oct 2026 20:03:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG3J-0000gE-Se for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:03:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG3J-001DD3-49 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:03:17 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c8e7-bab6-0a2a0a5309dd-0a2a45059b30-46 for ; Tue, 20 Oct 2026 22:03:16 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7c904-4cb1-0a2a45050019-a0658309cb22-3 for ; Tue, 20 Oct 2026 22:03:16 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 527BB842420D; Tue, 20 Oct 2026 16:02:32 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie , =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= , Oleksii Kurochko , Jan Beulich Subject: [PATCH v2 0/9] tools: optional LZ4 compression of the libxenguest migration stream Date: Tue, 20 Oct 2026 21:02:28 +0100 Message-ID: <20261020200238.1815766-1-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792526596-F56AD2A1-5D0A127F/0/0 X-purgate-type: clean X-purgate-size: 6580 Hello, This series adds optional LZ4 compression of the PAGE_DATA records of the libxenguest migration stream. It is off by default: a toolstack asks for it with XCFLAGS_COMPRESS_LZ4, xl with "xl migrate --compress", and it is compiled in only if a supported liblz4 is present. Based on staging at 7e020a4dd6ed (2026-10-15). v1: https://lists.xenproject.org/archives/html/xen-devel/2026-07/msg00916.html Main changes since v1 (details in each patch): - No new record type: PAGE_DATA's reserved field becomes a flags field (algorithm in bits 7-0, bit 8 for a compressed pfn array, bits 31-9 must be zero). New patch 1 makes receivers reject non-zero reserved fields. - One LZ4 frame for each record's page data (patch 9 adds a second for the pfn array), with mandatory block checksums, compressed from a staged copy of the batch rather than from the live mapping. - A batch is sent compressed whenever that makes it smaller (v1: below 97%). The 90% cut-off is unchanged: once an iteration's total after compression is 90% or more of its total before, compression stops for the rest of the save. - xl marks compressed streams with a mandatory flag, so an older xl refuses them before creating the domain (new patch 8). - New patch 9 compresses each record's pfn array too, as discussed in v1, so the whole record body apart from count and flags is compressed. It saves a little: 0.33% of the page data bytes on a compressible guest. Notes for reviewers: - Patches 1-2 check PAGE_DATA's reserved field and use it to extend the record in place. To allow this, they amend two general rules of the stream spec: reserved fields are ignored on restore, and a record type is extended only by adding a new one. An old receiver rejects an LZ4 record rather than misreading it: with patch 1, at the reserved-field check; without it, at its PAGE_DATA checks, at the latest the length check. - Patch 9 keeps the pfn array in plaintext when the compressed record would have a valid uncompressed length. This only protects receivers without patch 1, and can be removed once none of those remain. - 64KB interleaved staging (compressing each 64KB as it is copied), suggested on v1, was measured and not taken. It needs 64KB LZ4 blocks, and in a dom0 benchmark it compressed 25-124% slower than this series' staging with 4MB blocks, on EPYC 9354 and Xeon Gold 6430 with 0%, 50%, 90% and 100% random data. Performance: wall time of the whole command, mean of 2-6 runs, and change against no compression. Ten Windows VMs of 64 GiB evacuated together (xe host-evacuate, which returns when all ten have moved), or one of them migrated (xe vm-migrate), while the guests: - are idle: optimistic scenario; - run desktop applications: average scenario; - or run an extreme memory-write burner: a worst-case scenario. off LZ4 Intel Xeon Gold 6430, 100 Gb/s idle evacuate 195s 123s -37% migrate 182s 96s -47% desktop apps evacuate 318s 197s -38% migrate 208s 156s -25% memory burner evacuate 1339s 1417s +6% migrate 1004s 992s -1% AMD EPYC 9354, 25 Gb/s idle evacuate 260s 73s -72% migrate 167s 49s -71% desktop apps evacuate 266s 105s -61% migrate 179s 82s -54% memory burner evacuate 556s 416s -25% migrate 1833s 1883s +3% PV guest, xl migrate to the same host, 2 GiB, n=3: 15.1s and 2.54 GB plain, 10.1s and 0.89 GB with --compress. Testing: every patch builds with and without liblz4, and the Python stream tests pass. Out of tree, with Xen stubbed out and under gcc's ASan and UBSan, the changed save and restore functions round-trip uncompressed and LZ4 records with plaintext and compressed pfns, and reject damaged and malformed ones, with every supported liblz4 release. On XenServer hosts: performance tests; 100 migrations of a loaded guest between two hosts; uncompressed migrations both ways between hosts with and without the series; xl migrate of PVH and PV guests with --debug (the receiver checks every page against a second copy: no mismatch); xl save/restore; a sender built without a supported liblz4 fails with --compress, as expected, before sending any guest memory; older receivers refuse LZ4 streams cleanly; damaged streams are rejected (bad checksum, reserved bits, unknown algorithm). With patch 9: 200 live migrations of loaded 64 GiB Windows VMs (100 to the same host, 100 between two hosts), evacuations of 10-VM hosts, and receivers without patch 9 refuse the compressed pfn array stream as expected. Marcus Granado (9): tools/libs/guest: reject non-zero reserved fields in PAGE_DATA docs/specs, tools: define the PAGE_DATA flags field tools/libs/guest: decompress LZ4 PAGE_DATA records on restore tools/libs/guest: compress PAGE_DATA records with LZ4 on save tools/libs/guest: stop compressing PAGE_DATA when it stops paying off tools/libs/guest: add XCFLAGS_COMPRESS_LZ4 to request LZ4 compression tools/libxl,xl: add a --compress option to xl migrate tools/xl: mark LZ4 migration streams with a mandatory header flag tools/libs/guest: compress the PAGE_DATA pfn array too CHANGELOG.md | 3 + docs/man/xl.1.pod.in | 8 + docs/specs/libxc-migration-stream.pandoc | 108 +++++++++- tools/include/libxl.h | 1 + tools/include/xenguest.h | 5 +- tools/libs/guest/Makefile | 2 +- tools/libs/guest/xg_sr_common.h | 39 ++++ tools/libs/guest/xg_sr_restore.c | 243 ++++++++++++++++++++-- tools/libs/guest/xg_sr_save.c | 250 +++++++++++++++++++++++ tools/libs/guest/xg_sr_stream_format.h | 18 +- tools/libs/light/libxl_dom_save.c | 4 +- tools/libs/light/libxl_domain.c | 1 + tools/libs/light/libxl_internal.h | 1 + tools/python/xen/migration/libxc.py | 90 +++++++- tools/python/xen/migration/tests.py | 87 +++++++- tools/xl/xl.h | 7 +- tools/xl/xl_cmdtable.c | 2 + tools/xl/xl_migrate.c | 21 +- tools/xl/xl_saverestore.c | 7 +- 19 files changed, 850 insertions(+), 47 deletions(-) base-commit: 7e020a4dd6ed30eb6c91a9abe2767034e2bb270a -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:03:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:03:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456190.1669694 (Exim 4.92) (envelope-from ) id 1xJG3s-00016F-H0; Tue, 20 Oct 2026 20:03:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456190.1669694; Tue, 20 Oct 2026 20: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 1xJG3s-000168-EF; Tue, 20 Oct 2026 20:03:52 +0000 Received: by outflank-mailman (input) for mailman id 1456190; Tue, 20 Oct 2026 20:03:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG3q-00015e-KG for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:03:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG3q-005YoM-1M for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:03:50 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c908-2eae-0a2a0a5409dd-0a2a4505d2b6-46 for ; Tue, 20 Oct 2026 22:03:49 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7c924-4cb1-0a2a45050019-a0658309afe2-3 for ; Tue, 20 Oct 2026 22:03:49 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 8F6268424217; Tue, 20 Oct 2026 16:03:05 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie , Jan Beulich Subject: [PATCH v2 1/9] tools/libs/guest: reject non-zero reserved fields in PAGE_DATA Date: Tue, 20 Oct 2026 21:02:29 +0100 Message-ID: <20261020200238.1815766-2-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792526629-F5CA82A1-6C62C9D1/0/0 X-purgate-type: clean X-purgate-size: 4782 A PAGE_DATA record has two reserved fields: the 32-bit field after count, and bits 59-52 of each pfn entry. libxenguest ignores both on restore, as the specification's general rule for reserved fields requires, while the Python stream validator (tools/python/xen/migration/libxc.py) rejects both. A receiver which ignores either field can silently misread a record which uses it to change how the record's contents are organised. Reject a PAGE_DATA record with either field non-zero. Qualify the specification's general rule so that a record can override it, require rejection of both reserved fields, and bump the specification's revision. This deliberately tightens restore. Every libxenguest since Xen 4.6, and convert-legacy-stream, writes both fields as zero, so no stream they produce is rejected. Backport: 4.17+ Reported-by: Teddy Astie Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - New patch, after Teddy Astie pointed out on v1 that ignoring reserved fields does not help a future field which changes how the record's contents are organised. docs/specs/libxc-migration-stream.pandoc | 11 ++++++++--- tools/libs/guest/xg_sr_restore.c | 15 +++++++++++++++ tools/libs/guest/xg_sr_stream_format.h | 5 +++-- 3 files changed, 26 insertions(+), 5 deletions(-) diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc index 1319ce1f1e..b1c81b5d68 100644 --- a/docs/specs/libxc-migration-stream.pandoc +++ b/docs/specs/libxc-migration-stream.pandoc @@ -3,7 +3,7 @@ Andrew Cooper <> Wen Congyang <> Yang Hongyang <> -% Revision 3 +% Revision 4 Introduction ============ @@ -76,7 +76,8 @@ All the fields within the headers and records have a fixed width. Fields are always aligned to their size. Padding and reserved fields are set to zero on save and must be -ignored during restore. +ignored during restore, unless the record containing them says +otherwise. Integer (numeric) fields in the image header are always in big-endian byte order. @@ -298,12 +299,16 @@ Field Description ----------- -------------------------------------------------------- count Number of pages described in this record. +(reserved) Set to zero on save. A restoring side must reject a + record with this field non-zero. + pfn An array of count PFNs and their types. Bit 63-60: XEN_DOMCTL_PFINFO_* type (from `public/domctl.h` but shifted by 32 bits) - Bit 59-52: Reserved. + Bit 59-52: Reserved. Set to zero on save. A restoring + side must reject a record with any of these bits set. Bit 51-0: PFN. diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c index 458eaa5992..eae5a8e828 100644 --- a/tools/libs/guest/xg_sr_restore.c +++ b/tools/libs/guest/xg_sr_restore.c @@ -400,6 +400,14 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) goto err; } + /* Reject rather than ignore: a future use may change the layout. */ + if ( pages->_res1 != 0 ) + { + ERROR("Reserved field set in PAGE_DATA record: %#x", + (unsigned int)pages->_res1); + goto err; + } + if ( pages->count < 1 ) { ERROR("Expected at least 1 pfn in PAGE_DATA record"); @@ -424,6 +432,13 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) for ( i = 0; i < pages->count; ++i ) { + if ( pages->pfn[i] & PAGE_DATA_PFN_RESZ_MASK ) + { + ERROR("Reserved bits set in pfn[%u]: %#"PRIx64, i, + pages->pfn[i]); + goto err; + } + pfn = pages->pfn[i] & PAGE_DATA_PFN_MASK; if ( !ctx->restore.ops.pfn_is_valid(ctx, pfn) ) { diff --git a/tools/libs/guest/xg_sr_stream_format.h b/tools/libs/guest/xg_sr_stream_format.h index 99dca5d490..1e6e50a710 100644 --- a/tools/libs/guest/xg_sr_stream_format.h +++ b/tools/libs/guest/xg_sr_stream_format.h @@ -87,8 +87,9 @@ struct xc_sr_rec_page_data_header uint64_t pfn[0]; }; -#define PAGE_DATA_PFN_MASK 0x000fffffffffffffULL -#define PAGE_DATA_TYPE_MASK 0xf000000000000000ULL +#define PAGE_DATA_PFN_MASK 0x000fffffffffffffULL +#define PAGE_DATA_PFN_RESZ_MASK 0x0ff0000000000000ULL +#define PAGE_DATA_TYPE_MASK 0xf000000000000000ULL /* X86_PV_INFO */ struct xc_sr_rec_x86_pv_info -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:03:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:03:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456192.1669705 (Exim 4.92) (envelope-from ) id 1xJG3z-0001OO-PJ; Tue, 20 Oct 2026 20:03:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456192.1669705; Tue, 20 Oct 2026 20:03: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 1xJG3z-0001OH-Kx; Tue, 20 Oct 2026 20:03:59 +0000 Received: by outflank-mailman (input) for mailman id 1456192; Tue, 20 Oct 2026 20:03:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG3y-0001Na-Cv for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:03:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG3x-003cZt-Pz for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:03:57 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c92b-8faa-0a2a0a5109dd-0a2a4502e304-4 for ; Tue, 20 Oct 2026 22:03:57 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7c92c-6ca4-0a2a45020019-a0658309b218-3 for ; Tue, 20 Oct 2026 22:03:57 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 523328424212; Tue, 20 Oct 2026 16:03:13 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie Subject: [PATCH v2 2/9] docs/specs, tools: define the PAGE_DATA flags field Date: Tue, 20 Oct 2026 21:02:30 +0100 Message-ID: <20261020200238.1815766-3-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1792526637-F16AF2AC-32F8F28F/0/0 X-purgate-type: clean X-purgate-size: 11996 The 32-bit field after count in a PAGE_DATA record is reserved, and libxenguest and the Python stream validator reject a record which sets it. The record's page_data is page_size bytes of uncompressed contents per present page, and nothing in the record can say that it is encoded otherwise, so pages cannot be sent compressed. Turn that field into a flags field. Bits 7-0 identify the algorithm used to encode page_data, 0x00 meaning none, and a restoring side must fail on a value it does not implement. Bits 31-8 stay reserved, and a restoring side must still reject a record which sets any of them, overriding the general rule for reserved fields. Make libxenguest and the Python validator enforce both rules, and check the length of page_data according to the algorithm. Add test_page_data_flags for the Python checks. The specification's Future Extensions section requires a new record type for any extension of an existing one. Also allow an existing type to be extended in place when a receiver which predates the extension is guaranteed to reject the extended record rather than misread it. For PAGE_DATA, this holds for an encoding which leaves count and the pfn array in plaintext and shortens page_data: an older libxenguest which ignores the field fails its exact length check. The stream version is not bumped. A zero flags field means what the reserved field meant, and no other value is accepted. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - Replaces v1 1/6, which added a PAGE_DATA_LZ4 record type: PAGE_DATA's reserved field becomes a flags field, following review by Teddy Astie and Frediano Ziglio. LZ4 is assigned in patch 3. docs/specs/libxc-migration-stream.pandoc | 28 +++++++++++++++++------ tools/libs/guest/xg_sr_restore.c | 29 ++++++++++++++++-------- tools/libs/guest/xg_sr_stream_format.h | 8 ++++++- tools/python/xen/migration/libxc.py | 28 ++++++++++++++++++----- tools/python/xen/migration/tests.py | 25 +++++++++++++++++++- 5 files changed, 94 insertions(+), 24 deletions(-) diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc index b1c81b5d68..fd44dd6e0a 100644 --- a/docs/specs/libxc-migration-stream.pandoc +++ b/docs/specs/libxc-migration-stream.pandoc @@ -3,7 +3,8 @@ Andrew Cooper <> Wen Congyang <> Yang Hongyang <> -% Revision 4 + Marcus Granado <> +% Revision 5 Introduction ============ @@ -279,7 +280,7 @@ memory contents. 0 1 2 3 4 5 6 7 octet +-----------------------+-------------------------+ - | count (C) | (reserved) | + | count (C) | flags | +-----------------------+-------------------------+ | pfn[0] | +-------------------------------------------------+ @@ -299,8 +300,19 @@ Field Description ----------- -------------------------------------------------------- count Number of pages described in this record. -(reserved) Set to zero on save. A restoring side must reject a - record with this field non-zero. +flags Bit 7-0: Algorithm used to encode page_data. + + 0x00: None. page_data is page_size octets of + uncompressed contents per present page. + + 0x01 - 0xFF: Unassigned. + + A restoring side must fail on an algorithm value it + does not implement, rather than attempting to + interpret the page_data. + + Bit 31-8: Reserved. Set to zero on save. A restoring side + must reject a record with any of these bits set. pfn An array of count PFNs and their types. @@ -312,8 +324,8 @@ pfn An array of count PFNs and their types. Bit 51-0: PFN. -page_data page_size octets of uncompressed page contents for each - page set as present in the pfn array. +page_data Contents of each page set as present in the pfn array, + encoded with the algorithm in flags bits 7-0. -------------------------------------------------------------------- Note: Count is strictly > 0. N is strictly <= C and it is possible for there @@ -802,7 +814,9 @@ The format may be extended by adding additional record types. Extending an existing record type must be done by adding a new record type. This allows old images with the old record to still be -restored. +restored. An existing record type may instead be extended in place if +a receiver which predates the extension is guaranteed to reject the +extended record rather than misread it. The image header may only be extended by _appending_ additional fields. In particular, the `marker`, `id` and `version` fields must diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c index eae5a8e828..93b020b55f 100644 --- a/tools/libs/guest/xg_sr_restore.c +++ b/tools/libs/guest/xg_sr_restore.c @@ -401,10 +401,10 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) } /* Reject rather than ignore: a future use may change the layout. */ - if ( pages->_res1 != 0 ) + if ( pages->flags & PAGE_DATA_FLAGS_RESZ_MASK ) { - ERROR("Reserved field set in PAGE_DATA record: %#x", - (unsigned int)pages->_res1); + ERROR("Reserved bits set in PAGE_DATA record: %#x", + (unsigned int)(pages->flags & PAGE_DATA_FLAGS_RESZ_MASK)); goto err; } @@ -463,13 +463,24 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) types[i] = type; } - if ( rec->length != (sizeof(*pages) + - (sizeof(uint64_t) * pages->count) + - (PAGE_SIZE * pages_of_data)) ) + switch ( pages->flags & PAGE_DATA_ALGO_MASK ) { - ERROR("PAGE_DATA record wrong size: length %u, expected " - "%zu + %zu + %lu", rec->length, sizeof(*pages), - (sizeof(uint64_t) * pages->count), (PAGE_SIZE * pages_of_data)); + case PAGE_DATA_ALGO_NONE: + if ( rec->length != (sizeof(*pages) + + (sizeof(uint64_t) * pages->count) + + (PAGE_SIZE * pages_of_data)) ) + { + ERROR("PAGE_DATA record wrong size: length %u, expected " + "%zu + %zu + %lu", rec->length, sizeof(*pages), + (sizeof(uint64_t) * pages->count), + (PAGE_SIZE * pages_of_data)); + goto err; + } + break; + + default: + ERROR("Unsupported algorithm %u in PAGE_DATA record", + (unsigned int)(pages->flags & PAGE_DATA_ALGO_MASK)); goto err; } diff --git a/tools/libs/guest/xg_sr_stream_format.h b/tools/libs/guest/xg_sr_stream_format.h index 1e6e50a710..f839d874c8 100644 --- a/tools/libs/guest/xg_sr_stream_format.h +++ b/tools/libs/guest/xg_sr_stream_format.h @@ -83,10 +83,16 @@ struct xc_sr_rhdr struct xc_sr_rec_page_data_header { uint32_t count; - uint32_t _res1; + uint32_t flags; uint64_t pfn[0]; }; +/* PAGE_DATA flags: bits 7-0 are the algorithm, bits 31-8 are reserved. */ +#define PAGE_DATA_ALGO_MASK 0x000000ffU +#define PAGE_DATA_FLAGS_RESZ_MASK 0xffffff00U + +#define PAGE_DATA_ALGO_NONE 0x00000000U + #define PAGE_DATA_PFN_MASK 0x000fffffffffffffULL #define PAGE_DATA_PFN_RESZ_MASK 0x0ff0000000000000ULL #define PAGE_DATA_TYPE_MASK 0xf000000000000000ULL diff --git a/tools/python/xen/migration/libxc.py b/tools/python/xen/migration/libxc.py index e52e632cb1..2906b78d36 100644 --- a/tools/python/xen/migration/libxc.py +++ b/tools/python/xen/migration/libxc.py @@ -86,6 +86,11 @@ PAGE_DATA_FORMAT = "II" PAGE_DATA_PFN_MASK = (1 << 52) - 1 PAGE_DATA_PFN_RESZ_MASK = ((1 << 60) - 1) & ~((1 << 52) - 1) +# page_data flags: bits 7-0 algorithm, bits 31-8 reserved (must reject) +PAGE_DATA_ALGO_MASK = 0x000000ff +PAGE_DATA_FLAGS_RESZ_MASK = 0xffffff00 +PAGE_DATA_ALGO_NONE = 0x00 + # flags from xen/public/domctl.h: XEN_DOMCTL_PFINFO_* shifted by 32 bits PAGE_DATA_TYPE_SHIFT = 60 PAGE_DATA_TYPE_LTABTYPE_MASK = (0x7 << PAGE_DATA_TYPE_SHIFT) @@ -259,11 +264,14 @@ class VerifyLibxc(VerifyBase): raise RecordError( "PAGE_DATA record must be at least %d bytes long" % (minsz, )) - count, res1 = unpack(PAGE_DATA_FORMAT, content[:minsz]) + count, flags = unpack(PAGE_DATA_FORMAT, content[:minsz]) - if res1 != 0: + if flags & PAGE_DATA_FLAGS_RESZ_MASK: raise StreamError( - "Reserved bits set in PAGE_DATA record 0x%04x" % (res1, )) + "Reserved bits set in PAGE_DATA record 0x%08x" + % (flags & PAGE_DATA_FLAGS_RESZ_MASK, )) + + algo = flags & PAGE_DATA_ALGO_MASK pfnsz = count * 8 if (len(content) - minsz) < pfnsz: @@ -289,9 +297,17 @@ class VerifyLibxc(VerifyBase): nr_pages += 1 pagesz = nr_pages * 4096 - if len(content) != minsz + pfnsz + pagesz: - raise RecordError("Expected %u + %u + %u, got %u" % - (minsz, pfnsz, pagesz, len(content))) + datasz = len(content) - minsz - pfnsz + + if algo == PAGE_DATA_ALGO_NONE: + + if datasz != pagesz: + raise RecordError("Expected %u + %u + %u, got %u" % + (minsz, pfnsz, pagesz, len(content))) + + else: + raise StreamError( + "Unsupported algorithm %u in PAGE_DATA record" % (algo, )) def verify_record_x86_pv_info(self, content): diff --git a/tools/python/xen/migration/tests.py b/tools/python/xen/migration/tests.py index fcf94b0bb2..1944ae09b3 100644 --- a/tools/python/xen/migration/tests.py +++ b/tools/python/xen/migration/tests.py @@ -6,7 +6,7 @@ Unit tests for migration v2 streams import unittest -from struct import calcsize +from struct import calcsize, pack from xen.migration import libxc, libxl @@ -30,6 +30,29 @@ class TestLibxc(unittest.TestCase): ): self.assertEqual(calcsize(fmt), sz) + def test_page_data_flags(self): + """ PAGE_DATA flags: algorithm dispatch and the reserved bits """ + + v = libxc.VerifyLibxc(lambda *_: None, lambda *_: b"") + PAGE = b"\x00" * 4096 + NOTAB = libxc.PAGE_DATA_TYPE_NOTAB | 0x1 # one normal page, pfn 1 + + def rec(flags, data): + return pack(libxc.PAGE_DATA_FORMAT, 1, flags) + \ + pack("=Q", NOTAB) + data + + # Uncompressed: exactly one page of data, and nothing else accepted. + v.verify_record_page_data(rec(libxc.PAGE_DATA_ALGO_NONE, PAGE)) + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(libxc.PAGE_DATA_ALGO_NONE, PAGE[:-1])) + + # An unimplemented algorithm, and any reserved bit, are refused. + self.assertRaises(libxc.StreamError, v.verify_record_page_data, + rec(libxc.PAGE_DATA_ALGO_NONE + 1, PAGE)) + for bit in range(8, 32): + self.assertRaises(libxc.StreamError, v.verify_record_page_data, + rec(1 << bit, PAGE)) + class TestLibxl(unittest.TestCase): -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:04:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:04:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456201.1669712 (Exim 4.92) (envelope-from ) id 1xJG4B-0001qD-V6; Tue, 20 Oct 2026 20:04:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456201.1669712; Tue, 20 Oct 2026 20:04: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 1xJG4B-0001q6-Rv; Tue, 20 Oct 2026 20:04:11 +0000 Received: by outflank-mailman (input) for mailman id 1456201; Tue, 20 Oct 2026 20:04:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG4A-0001nL-LV for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:04:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG4A-005Yr0-2P for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:04:10 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c928-e002-0a2a0a5209dd-0a2a4505d56e-30 for ; Tue, 20 Oct 2026 22:04:10 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7c938-4cb1-0a2a45050019-a0658309e0f6-3 for ; Tue, 20 Oct 2026 22:04:09 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 1741A842421A; Tue, 20 Oct 2026 16:03:24 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie Subject: [PATCH v2 4/9] tools/libs/guest: compress PAGE_DATA records with LZ4 on save Date: Tue, 20 Oct 2026 21:02:32 +0100 Message-ID: <20261020200238.1815766-5-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792526649-71EA92A1-5C38F210/0/0 X-purgate-type: clean X-purgate-size: 9122 write_batch() sends the pages of each batch uncompressed, writing iovecs which point into the foreign mapping straight to the stream. Restore decodes PAGE_DATA algorithm 0x01, LZ4, but nothing emits it, so memory which compresses well still crosses the link at full size. When ctx->save.compression selects LZ4, copy the batch's page data into a staging buffer, compress it into one LZ4 frame with block checksums, and send the frame, zero-padded to REC_ALIGN, in place of the pages. Send the batch uncompressed unless the frame is strictly shorter than the page data, as the stream specification requires of a saver. The copy is required: LZ4 may encode a page P by reference to an earlier page Q, checked against Q's current bytes but rebuilt from Q as encoded earlier in the frame. A guest write to Q in between corrupts P undetected, as the block checksums cover the compressed data, and P is not re-sent unless the guest writes it again. Stage from the iov rather than the mapping, as only the iov describes the record: PV pagetables are normalised into separately allocated pages, and a page deferred on EAGAIN stays in the mapping but has no data in the record. The batch is staged whole and compressed as one block of up to 4MB; copying in smaller chunks interleaved with compression was slower in most configurations measured. The two buffers, about 8MB together, are allocated on first use. If allocation or compression fails, compression is switched off for the rest of the save rather than failing it. The encoder is guarded by XG_SR_LZ4, as the decoder is. Nothing sets ctx->save.compression yet, so behaviour is unchanged. Suggested-by: Frediano Ziglio Suggested-by: Teddy Astie Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - Was v1 3/6. - One LZ4 frame per batch, carried in PAGE_DATA and compressed from a staged copy of the page data, replaces per-page blocks compressed from the live mapping in a separate record type. - Send compressed whenever the frame is shorter (v1: below 97%). - If allocation fails, compression is switched off rather than failing the save (v1 failed it). tools/libs/guest/xg_sr_common.h | 14 ++++ tools/libs/guest/xg_sr_save.c | 133 ++++++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+) diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h index 53647caa30..e567a47582 100644 --- a/tools/libs/guest/xg_sr_common.h +++ b/tools/libs/guest/xg_sr_common.h @@ -221,6 +221,12 @@ static inline int update_blob(struct xc_sr_blob *blob, return 0; } +enum xc_sr_compression +{ + XC_SR_COMPRESS_NONE, + XC_SR_COMPRESS_LZ4, +}; + struct xc_sr_context { xc_interface *xch; @@ -265,6 +271,14 @@ struct xc_sr_context uint64_t rec_pfns[MAX_BATCH_SIZE]; int errors[MAX_BATCH_SIZE]; } *buffers; + + /* Which algorithm to compress page data with. */ + enum xc_sr_compression compression; + + /* LZ4 staging and output buffers, allocated on first use. */ + void *lz4_staging_buf; + void *lz4_compress_buf; + size_t lz4_compress_buf_size; } save; struct /* Restore data. */ diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c index 6a77e33a47..33954a7023 100644 --- a/tools/libs/guest/xg_sr_save.c +++ b/tools/libs/guest/xg_sr_save.c @@ -73,6 +73,118 @@ static int write_checkpoint_record(struct xc_sr_context *ctx) return write_record(ctx, &checkpoint); } +static void cleanup_compression(struct xc_sr_context *ctx) +{ + free(ctx->save.lz4_staging_buf); + free(ctx->save.lz4_compress_buf); + ctx->save.lz4_staging_buf = NULL; + ctx->save.lz4_compress_buf = NULL; + ctx->save.lz4_compress_buf_size = 0; +} + +#if defined(XG_SR_LZ4) +/* + * One block per 4MB batch: smaller blocks can be 2x slower to decode. + * liblz4 allows 64KB, 256KB, 1MB and 4MB. + */ +#define XC_SR_COMPRESS_BLOCK_SIZE LZ4F_max4MB + +/* + * Compress the page data in iov[2..iovcnt) into an LZ4 frame, and replace + * those entries with one describing it, padded to the record alignment. + * Returns the new iovcnt, the original one with iov untouched if the batch + * should be sent uncompressed, or -1 if the batch itself is malformed. + */ +static int lz4_compress_batch(struct xc_sr_context *ctx, struct iovec *iov, + int iovcnt, unsigned int nr_pages, + uint32_t *flags, uint32_t *length) +{ + static const LZ4F_preferences_t prefs = { + .frameInfo = { + .blockSizeID = XC_SR_COMPRESS_BLOCK_SIZE, + .blockChecksumFlag = LZ4F_blockChecksumEnabled, + }, + }; + xc_interface *xch = ctx->xch; + size_t raw = (size_t)nr_pages * PAGE_SIZE, clen, staged; + uint8_t *dst; + int i; + + if ( nr_pages == 0 ) + return iovcnt; + + if ( !ctx->save.lz4_staging_buf ) + { + size_t bound = LZ4F_compressFrameBound(MAX_BATCH_SIZE * PAGE_SIZE, + &prefs); + + ctx->save.lz4_staging_buf = malloc(MAX_BATCH_SIZE * PAGE_SIZE); + ctx->save.lz4_compress_buf = malloc(bound); + ctx->save.lz4_compress_buf_size = bound; + + if ( !ctx->save.lz4_staging_buf || !ctx->save.lz4_compress_buf ) + { + IPRINTF("Unable to allocate LZ4 buffers, sending uncompressed"); + cleanup_compression(ctx); + ctx->save.compression = XC_SR_COMPRESS_NONE; + return iovcnt; + } + } + + /* The iov must match nr_pages, or stale bytes would be compressed. */ + for ( i = 2, staged = 0; i < iovcnt; ++i ) + staged += iov[i].iov_len; + if ( staged != raw ) + { + ERROR("Staged %zu bytes for a batch of %u pages", staged, nr_pages); + return -1; + } + + /* LZ4 must not read live guest memory: the frame could decode wrong. */ + for ( i = 2, dst = ctx->save.lz4_staging_buf; i < iovcnt; ++i ) + { + memcpy(dst, iov[i].iov_base, iov[i].iov_len); + dst += iov[i].iov_len; + } + + clen = LZ4F_compressFrame(ctx->save.lz4_compress_buf, + ctx->save.lz4_compress_buf_size, + ctx->save.lz4_staging_buf, raw, &prefs); + + if ( LZ4F_isError(clen) ) + { + IPRINTF("LZ4 compression failed: %s, sending uncompressed", + LZ4F_getErrorName(clen)); + cleanup_compression(ctx); + ctx->save.compression = XC_SR_COMPRESS_NONE; + return iovcnt; + } + + /* The stream format allows LZ4 only when strictly shorter. */ + if ( clen >= raw ) + { + DBGPRINTF("LZ4: %zu -> %zu bytes, sending uncompressed", raw, clen); + return iovcnt; + } + + DBGPRINTF("LZ4: %zu -> %zu bytes (%zu.%zu%% ratio)", raw, clen, + (clen * 1000 / raw) / 10, (clen * 1000 / raw) % 10); + + /* Pad in place: raw is a multiple of REC_ALIGN and > clen, so it fits. */ + memset((uint8_t *)ctx->save.lz4_compress_buf + clen, 0, + ROUNDUP(clen, REC_ALIGN) - clen); + + iov[2].iov_base = ctx->save.lz4_compress_buf; + iov[2].iov_len = ROUNDUP(clen, REC_ALIGN); + + *flags |= PAGE_DATA_ALGO_LZ4; + *length -= raw - clen; + + /* iov[0] headers, iov[1] pfns, iov[2] page data frame. */ + return 3; +} +#endif /* XG_SR_LZ4 */ + /* * Writes a batch of memory as a PAGE_DATA record into the stream. The batch * is constructed in ctx->save.buffers->batch_pfns. @@ -228,6 +340,26 @@ static int write_batch(struct xc_sr_context *ctx) for ( i = 0; i < nr_pfns; ++i ) rec_pfns[i] = ((uint64_t)(types[i]) << 32) | batch_pfns[i]; + switch ( ctx->save.compression ) + { + case XC_SR_COMPRESS_NONE: + break; + + case XC_SR_COMPRESS_LZ4: +#if defined(XG_SR_LZ4) + iovcnt = lz4_compress_batch(ctx, iov, iovcnt, nr_pages, + &hdrs.page_data.flags, &hdrs.rec.length); + /* + * -1: iov[2..] is not nr_pages pages. Compressed: stale bytes for + * missing pages, or extra pages dropped, unseen by the checksums. + * Uncompressed: rec.length would not match the bytes writev() writes. + */ + if ( iovcnt < 0 ) + goto err; +#endif + break; + } + if ( writev_exact(ctx->fd, iov, iovcnt) ) { PERROR("Failed to write page data to stream"); @@ -807,6 +939,7 @@ static void cleanup(struct xc_sr_context *ctx) NRPAGES(bitmap_size(ctx->save.p2m_size))); free(ctx->save.deferred_pages); free(ctx->save.buffers); + cleanup_compression(ctx); } /* -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:04:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:04:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456208.1669722 (Exim 4.92) (envelope-from ) id 1xJG4J-0002DB-9u; Tue, 20 Oct 2026 20:04:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456208.1669722; Tue, 20 Oct 2026 20:04: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 1xJG4J-0002D3-6Z; Tue, 20 Oct 2026 20:04:19 +0000 Received: by outflank-mailman (input) for mailman id 1456208; Tue, 20 Oct 2026 20:04:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG4H-0002Bc-RT for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:04:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG4H-00EFnl-8M for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:04:17 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c920-2eae-0a2a0a5409dd-0a2a45088be8-26 for ; Tue, 20 Oct 2026 22:04:17 +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 6ad7c93f-f659-0a2a45080019-a06583098f38-3 for ; Tue, 20 Oct 2026 22:04:17 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 29D17842421A; Tue, 20 Oct 2026 16:03:32 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= , Teddy Astie Subject: [PATCH v2 5/9] tools/libs/guest: stop compressing PAGE_DATA when it stops paying off Date: Tue, 20 Oct 2026 21:02:33 +0100 Message-ID: <20261020200238.1815766-6-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792526657-DF6D687B-5A915AB0/0/0 X-purgate-type: clean X-purgate-size: 6136 When LZ4 compression is in use, write_batch() compresses the page data of every batch until the end of the save, whatever the result. For a guest whose memory hardly compresses, this spends CPU at both ends for little or no reduction of the stream. Total the page data bytes before and after compression over each precopy iteration, counting a batch sent uncompressed as no saving. If an iteration's total after compression is 90% or more of its total before, stop compressing for the rest of the save. The check runs in send_memory_live() at the end of each precopy iteration. A non-live save (xc_domain_save() without XCFLAGS_LIVE) has no precopy iterations, so it never stops compressing. The 90% threshold is a heuristic; a poor choice costs CPU or bandwidth, never correctness. Log, at info level, the ratio of each judged iteration, the decision to stop and a summary of the batches sent while compression was on. Suggested-by: Edwin Török Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - Was v1 4/6, "adaptively disable LZ4 on poor compression ratio". - A batch sent uncompressed counts as no saving; v1 counted its compressed size. tools/libs/guest/xg_sr_common.h | 9 +++++ tools/libs/guest/xg_sr_save.c | 69 +++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h index e567a47582..38ec1da095 100644 --- a/tools/libs/guest/xg_sr_common.h +++ b/tools/libs/guest/xg_sr_common.h @@ -275,6 +275,15 @@ struct xc_sr_context /* Which algorithm to compress page data with. */ enum xc_sr_compression compression; + /* + * Page data bytes before (raw) and after (out) compression, in + * the current iteration and in all iterations so far. + */ + uint64_t compress_raw_total; + uint64_t compress_out_total; + uint64_t compress_raw_all_total; + uint64_t compress_out_all_total; + /* LZ4 staging and output buffers, allocated on first use. */ void *lz4_staging_buf; void *lz4_compress_buf; diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c index 33954a7023..4fa1d22859 100644 --- a/tools/libs/guest/xg_sr_save.c +++ b/tools/libs/guest/xg_sr_save.c @@ -83,6 +83,67 @@ static void cleanup_compression(struct xc_sr_context *ctx) } #if defined(XG_SR_LZ4) +static void compress_stats_reset(struct xc_sr_context *ctx) +{ + ctx->save.compress_raw_total = 0; + ctx->save.compress_out_total = 0; +} + +static void compress_stats_accumulate(struct xc_sr_context *ctx, + size_t raw_len, size_t compressed_len) +{ + ctx->save.compress_raw_total += raw_len; + ctx->save.compress_out_total += compressed_len; + ctx->save.compress_raw_all_total += raw_len; + ctx->save.compress_out_all_total += compressed_len; +} + +static void compress_stats_summary(const struct xc_sr_context *ctx) +{ + xc_interface *xch = ctx->xch; + uint64_t raw = ctx->save.compress_raw_all_total; + uint64_t out = ctx->save.compress_out_all_total; + unsigned int permil; + + if ( !raw ) + return; + + permil = out * 1000 / raw; + IPRINTF("Compression summary: compressed %"PRIu64" -> %"PRIu64" bytes (%u.%u%% average ratio) while compression was on", + raw, out, permil / 10, permil % 10); +} + +#define XC_SR_COMPRESS_ITER_THRESHOLD 90 + +static void compress_stats_evaluate(struct xc_sr_context *ctx) +{ + xc_interface *xch = ctx->xch; + uint64_t raw = ctx->save.compress_raw_total; + uint64_t out = ctx->save.compress_out_total; + unsigned int iter = ctx->save.stats.iteration; + + if ( ctx->save.compression == XC_SR_COMPRESS_NONE ) + return; + + if ( raw ) + { + unsigned int permil = out * 1000 / raw; + + IPRINTF("Iteration %u: compressed %"PRIu64" -> %"PRIu64" bytes (%u.%u%% average ratio)", + iter, raw, out, permil / 10, permil % 10); + + if ( out * 100 >= raw * XC_SR_COMPRESS_ITER_THRESHOLD ) + { + IPRINTF("Iteration %u: at or above the %u%% threshold - disabling compression for remaining iterations", + iter, XC_SR_COMPRESS_ITER_THRESHOLD); + ctx->save.compression = XC_SR_COMPRESS_NONE; + cleanup_compression(ctx); + } + } + + compress_stats_reset(ctx); +} + /* * One block per 4MB batch: smaller blocks can be 2x slower to decode. * liblz4 allows 64KB, 256KB, 1MB and 4MB. @@ -164,11 +225,13 @@ static int lz4_compress_batch(struct xc_sr_context *ctx, struct iovec *iov, if ( clen >= raw ) { DBGPRINTF("LZ4: %zu -> %zu bytes, sending uncompressed", raw, clen); + compress_stats_accumulate(ctx, raw, raw); return iovcnt; } DBGPRINTF("LZ4: %zu -> %zu bytes (%zu.%zu%% ratio)", raw, clen, (clen * 1000 / raw) / 10, (clen * 1000 / raw) % 10); + compress_stats_accumulate(ctx, raw, clen); /* Pad in place: raw is a multiple of REC_ALIGN and > clen, so it fits. */ memset((uint8_t *)ctx->save.lz4_compress_buf + clen, 0, @@ -638,6 +701,9 @@ static int send_memory_live(struct xc_sr_context *ctx) rc = send_dirty_pages(ctx, stats.dirty_count); if ( rc ) goto out; +#if defined(XG_SR_LZ4) + compress_stats_evaluate(ctx); +#endif } if ( policy_decision != XGS_POLICY_CONTINUE_PRECOPY ) @@ -939,6 +1005,9 @@ static void cleanup(struct xc_sr_context *ctx) NRPAGES(bitmap_size(ctx->save.p2m_size))); free(ctx->save.deferred_pages); free(ctx->save.buffers); +#if defined(XG_SR_LZ4) + compress_stats_summary(ctx); +#endif cleanup_compression(ctx); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:04:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:04:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456219.1669731 (Exim 4.92) (envelope-from ) id 1xJG4N-0002Z5-I6; Tue, 20 Oct 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 1456219.1669731; Tue, 20 Oct 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 1xJG4N-0002Yr-DD; Tue, 20 Oct 2026 20:04:23 +0000 Received: by outflank-mailman (input) for mailman id 1456219; Tue, 20 Oct 2026 20:04:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG4M-0002Xh-G1 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:04:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG4L-001DOX-TL for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:04:21 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c922-bab6-0a2a0a5309dd-0a2a450cdaaa-28 for ; Tue, 20 Oct 2026 22:04:21 +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 6ad7c944-f479-0a2a450c0019-a0658309c05c-3 for ; Tue, 20 Oct 2026 22:04:21 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 1A0E3842421D; Tue, 20 Oct 2026 16:03: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; none From: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie Subject: [PATCH v2 6/9] tools/libs/guest: add XCFLAGS_COMPRESS_LZ4 to request LZ4 compression Date: Tue, 20 Oct 2026 21:02:34 +0100 Message-ID: <20261020200238.1815766-7-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1792526661-036D6A5B-49D0D88D/0/0 X-purgate-type: clean X-purgate-size: 2362 Nothing sets ctx->save.compression to XC_SR_COMPRESS_LZ4, so the LZ4 path in write_batch() is unreachable and a caller of xc_domain_save() has no way to ask for compressed PAGE_DATA records. Add XCFLAGS_COMPRESS_LZ4 and select LZ4 when it is set. A caller which does not set it sees no change; one which does needs a receiver able to decompress LZ4. A libxenguest built without a supported liblz4 cannot honour the flag, so fail up front with EOPNOTSUPP rather than silently send uncompressed records. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - Was v1 5/6. - Set ctx->save.compression; the field moved into the save context. Bit 2 was XCFLAGS_HVM until commit 2004db3ced18 ("tools/save: Drop unused parameters from xc_domain_save()") removed it in 4.14. tools/include/xenguest.h | 5 +++-- tools/libs/guest/xg_sr_save.c | 11 +++++++++++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h index 2a277cb7cd..70301c2f48 100644 --- a/tools/include/xenguest.h +++ b/tools/include/xenguest.h @@ -24,8 +24,9 @@ #define XC_NUMA_NO_NODE (~0U) -#define XCFLAGS_LIVE (1 << 0) -#define XCFLAGS_DEBUG (1 << 1) +#define XCFLAGS_LIVE (1 << 0) +#define XCFLAGS_DEBUG (1 << 1) +#define XCFLAGS_COMPRESS_LZ4 (1 << 2) /* LZ4 on save; restorer needs LZ4 */ #define X86_64_B_SIZE 64 #define X86_32_B_SIZE 32 diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c index 4fa1d22859..fe3d78bdd6 100644 --- a/tools/libs/guest/xg_sr_save.c +++ b/tools/libs/guest/xg_sr_save.c @@ -1166,6 +1166,17 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, ctx.save.debug = !!(flags & XCFLAGS_DEBUG); ctx.save.recv_fd = recv_fd; + if ( flags & XCFLAGS_COMPRESS_LZ4 ) + { +#if defined(XG_SR_LZ4) + ctx.save.compression = XC_SR_COMPRESS_LZ4; +#else + ERROR("XCFLAGS_COMPRESS_LZ4 requested but libxenguest was built without a supported liblz4"); + errno = EOPNOTSUPP; + return -1; +#endif + } + if ( xc_domain_getinfo_single(xch, dom, &ctx.dominfo) < 0 ) { PERROR("Failed to get domain info"); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:04:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:04:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456229.1669740 (Exim 4.92) (envelope-from ) id 1xJG4S-0002u5-P1; Tue, 20 Oct 2026 20:04:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456229.1669740; Tue, 20 Oct 2026 20:04: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 1xJG4S-0002tw-Li; Tue, 20 Oct 2026 20:04:28 +0000 Received: by outflank-mailman (input) for mailman id 1456229; Tue, 20 Oct 2026 20:04:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG4Q-0002qS-M1 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:04:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG4Q-007mVw-35 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:04:26 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c943-8faa-0a2a0a5109dd-0a2a4505e3b4-12 for ; Tue, 20 Oct 2026 22:04:26 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7c948-4cb1-0a2a45050019-a06583099792-3 for ; Tue, 20 Oct 2026 22:04:25 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 6C5D8842421A; Tue, 20 Oct 2026 16:03:41 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Oleksii Kurochko , Community Manager , Teddy Astie Subject: [PATCH v2 7/9] tools/libxl,xl: add a --compress option to xl migrate Date: Tue, 20 Oct 2026 21:02:35 +0100 Message-ID: <20261020200238.1815766-8-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792526666-F48A62A1-128FA400/0/0 X-purgate-type: clean X-purgate-size: 8328 libxenguest can compress PAGE_DATA records with LZ4 when its caller sets XCFLAGS_COMPRESS_LZ4, but libxl never sets it, so xl has no way to ask for compression. Add a LIBXL_SUSPEND_COMPRESS_LZ4 flag for libxl_domain_suspend(), pass it to libxenguest as XCFLAGS_COMPRESS_LZ4, and expose it as "xl migrate --compress". Off by default: whether compressing pays off depends on how compressible the guest's memory is and on the CPU headroom of both hosts, so the caller decides. Only xl migrate gets the option; xl save and xl remus never use LZ4. The receiving side needs no option, as each PAGE_DATA record says whether it is compressed. A receiver which cannot decompress rejects the first compressed record, after it has created the domain, and the migration fails with the guest still on the source. A sender whose libxenguest was built without a supported liblz4 fails the migration before sending any guest memory; libxl reports it as a suspend timeout. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - Was v1 6/6. The libxl and xl code is unchanged; the help text and man page now say both hosts need liblz4 support in libxenguest, and CHANGELOG.md has an entry. No LIBXL_HAVE_* macro: LIBXL_SUSPEND_COMPRESS_LZ4 is itself a #define, so a caller can test for it with #ifdef LIBXL_SUSPEND_COMPRESS_LZ4. CHANGELOG.md | 3 +++ docs/man/xl.1.pod.in | 8 ++++++++ tools/include/libxl.h | 1 + tools/libs/light/libxl_dom_save.c | 4 +++- tools/libs/light/libxl_domain.c | 1 + tools/libs/light/libxl_internal.h | 1 + tools/xl/xl_cmdtable.c | 2 ++ tools/xl/xl_migrate.c | 13 ++++++++++--- 8 files changed, 29 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 225397f128..4f1da5d9e5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) afterwards. ### Added + - On x86: + - Optional LZ4 compression of the memory stream during migration + (xl migrate --compress). ### Removed - On Arm: diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index 51405f4e33..b0439231e2 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -488,6 +488,14 @@ domain. Display huge (!) amount of debug information during the migration process. +=item B<--compress> + +Compress the memory stream using LZ4 inside libxenguest before sending it +to the destination host. This can significantly reduce migration time on +slow transports, and reduce dom0 CPU pressure during host evacuations when +the migration data is subsequently encrypted or copied through pipes. +Requires liblz4 support in libxenguest on both hosts. + =item B<-p> Leave the domain on the receive side paused after migration. diff --git a/tools/include/libxl.h b/tools/include/libxl.h index d294fb36bd..1114c8f8d1 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -1922,6 +1922,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, LIBXL_EXTERNAL_CALLERS_ONLY; #define LIBXL_SUSPEND_DEBUG 1 #define LIBXL_SUSPEND_LIVE 2 +#define LIBXL_SUSPEND_COMPRESS_LZ4 4 /* * Only suspend domain, do not save its state to file, do not destroy it. diff --git a/tools/libs/light/libxl_dom_save.c b/tools/libs/light/libxl_dom_save.c index d64fd64f2e..16b882ecf0 100644 --- a/tools/libs/light/libxl_dom_save.c +++ b/tools/libs/light/libxl_dom_save.c @@ -245,6 +245,7 @@ void libxl__domain_save(libxl__egc *egc, libxl__domain_save_state *dss) const libxl_domain_type type = dss->type; const int live = dss->live; const int debug = dss->debug; + const int compress_lz4 = dss->compress_lz4; const libxl_domain_remus_info *const r_info = dss->remus; libxl__srm_save_autogen_callbacks *const callbacks = &dss->sws.shs.callbacks.save.a; @@ -269,7 +270,8 @@ void libxl__domain_save(libxl__egc *egc, libxl__domain_save_state *dss) if (rc) goto out; dss->xcflags = (live ? XCFLAGS_LIVE : 0) - | (debug ? XCFLAGS_DEBUG : 0); + | (debug ? XCFLAGS_DEBUG : 0) + | (compress_lz4 ? XCFLAGS_COMPRESS_LZ4 : 0); /* Disallow saving a guest with vNUMA configured because migration * stream does not preserve node information. diff --git a/tools/libs/light/libxl_domain.c b/tools/libs/light/libxl_domain.c index 37fcd92871..86458a69c0 100644 --- a/tools/libs/light/libxl_domain.c +++ b/tools/libs/light/libxl_domain.c @@ -527,6 +527,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags, dss->type = type; dss->live = flags & LIBXL_SUSPEND_LIVE; dss->debug = flags & LIBXL_SUSPEND_DEBUG; + dss->compress_lz4 = flags & LIBXL_SUSPEND_COMPRESS_LZ4; dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_NONE; rc = libxl__fd_flags_modify_save(gc, dss->fd, diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h index b65e0064b9..ff7a334501 100644 --- a/tools/libs/light/libxl_internal.h +++ b/tools/libs/light/libxl_internal.h @@ -3598,6 +3598,7 @@ struct libxl__domain_save_state { libxl_domain_type type; int live; int debug; + int compress_lz4; int checkpointed_stream; const libxl_domain_remus_info *remus; /* private */ diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c index e48d5c5edc..aadca23a77 100644 --- a/tools/xl/xl_cmdtable.c +++ b/tools/xl/xl_cmdtable.c @@ -174,6 +174,8 @@ const struct cmd_spec cmd_table[] = { "-e Do not wait in the background (on ) for the death\n" " of the domain.\n" "--debug Print huge (!) amount of debug during the migration process.\n" + "--compress Compress the memory stream using LZ4 in libxenguest.\n" + " Requires liblz4 support in libxenguest on both hosts.\n" "-p Do not unpause domain after migrating it.\n" "-D Preserve the domain id" }, diff --git a/tools/xl/xl_migrate.c b/tools/xl/xl_migrate.c index 4b4a379aa1..31a8cb4f32 100644 --- a/tools/xl/xl_migrate.c +++ b/tools/xl/xl_migrate.c @@ -177,7 +177,7 @@ static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child, } static void migrate_domain(uint32_t domid, int preserve_domid, - const char *rune, int debug, + const char *rune, int debug, int compress_lz4, const char *override_config_file) { pid_t child = -1; @@ -206,6 +206,8 @@ static void migrate_domain(uint32_t domid, int preserve_domid, if (debug) flags |= LIBXL_SUSPEND_DEBUG; + if (compress_lz4) + flags |= LIBXL_SUSPEND_COMPRESS_LZ4; rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL); if (rc) { fprintf(stderr, "migration sender: libxl_domain_suspend failed" @@ -538,10 +540,11 @@ int main_migrate(int argc, char **argv) char *rune = NULL; char *host; int opt, daemonize = 1, monitor = 1, debug = 0, pause_after_migration = 0; - int preserve_domid = 0; + int preserve_domid = 0, compress_lz4 = 0; static struct option opts[] = { {"debug", 0, 0, 0x100}, {"live", 0, 0, 0x200}, + {"compress", 0, 0, 0x300}, COMMON_LONG_OPTS }; @@ -571,6 +574,9 @@ int main_migrate(int argc, char **argv) case 0x200: /* --live */ /* ignored for compatibility with xm */ break; + case 0x300: /* --compress */ + compress_lz4 = 1; + break; } domid = find_domain(argv[optind]); @@ -602,7 +608,8 @@ int main_migrate(int argc, char **argv) pause_after_migration ? " -p" : ""); } - migrate_domain(domid, preserve_domid, rune, debug, config_filename); + migrate_domain(domid, preserve_domid, rune, debug, compress_lz4, + config_filename); return EXIT_SUCCESS; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:04:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:04:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456242.1669749 (Exim 4.92) (envelope-from ) id 1xJG4W-0003FC-4w; Tue, 20 Oct 2026 20:04:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456242.1669749; Tue, 20 Oct 2026 20:04: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 1xJG4V-0003Eq-TM; Tue, 20 Oct 2026 20:04:31 +0000 Received: by outflank-mailman (input) for mailman id 1456242; Tue, 20 Oct 2026 20:04:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG4U-0003BB-Kd for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:04:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG4U-005YwM-1b for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:04:30 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7c91d-e002-0a2a0a5209dd-0a2a4507bb9c-44 for ; Tue, 20 Oct 2026 22:04:30 +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 6ad7c94d-b4ea-0a2a45070019-a0658309a4fe-3 for ; Tue, 20 Oct 2026 22:04:29 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id B6968842421A; Tue, 20 Oct 2026 16:03:45 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie Subject: [PATCH v2 8/9] tools/xl: mark LZ4 migration streams with a mandatory header flag Date: Tue, 20 Oct 2026 21:02:36 +0100 Message-ID: <20261020200238.1815766-9-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1792526670-3C411AE4-0F6C33C9/0/0 X-purgate-type: clean X-purgate-size: 5662 A receiver which cannot decompress LZ4 rejects the first compressed PAGE_DATA record. That is late: the receiver has already created the domain, precopy has started, and an older libxenguest's error says nothing about compression. xl can fail earlier. Its save file header carries mandatory_flags, and create_domain() rejects unknown bits before it calls libxl_domain_create_restore(). Similar to commit e72ce244dc91 ("tools/xl: Mandatory flag indicating the format of the migration stream"), claim bit 2 for LZ4 and set it for "xl migrate --compress". An older xl then reports mandatory flag 0x4 as unsupported and creates no domain. This is defence in depth, for xl-to-xl migration only. An xl which knows the flag but whose libxenguest lacks liblz4 still accepts the header and fails late, at the first compressed PAGE_DATA record, though with an error that names LZ4. The header is written before any record, so a stream in which no record ends up compressed still carries the flag and needs an LZ4-aware xl. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - New, after an off-list question from Ross Lagerwall: an older xl now refuses a compressed stream before it creates the domain. tools/xl/xl.h | 7 +++++-- tools/xl/xl_migrate.c | 8 ++++---- tools/xl/xl_saverestore.c | 7 +++++-- 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index 7b75f9a493..009cbd1c3c 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -77,8 +77,10 @@ static const char migrate_report[]= #define XL_MANDATORY_FLAG_JSON (1U << 0) /* config data is in JSON format */ #define XL_MANDATORY_FLAG_STREAMv2 (1U << 1) /* stream is v2 */ +#define XL_MANDATORY_FLAG_COMPRESS_LZ4 (1U << 2) /* PAGE_DATA may use LZ4 */ #define XL_MANDATORY_FLAG_ALL (XL_MANDATORY_FLAG_JSON | \ - XL_MANDATORY_FLAG_STREAMv2) + XL_MANDATORY_FLAG_STREAMv2 | \ + XL_MANDATORY_FLAG_COMPRESS_LZ4) struct save_file_header { char magic[32]; /* savefileheader_magic */ @@ -102,7 +104,8 @@ void save_domain_core_begin(uint32_t domid, uint8_t **config_data_r, int *config_len_r); void save_domain_core_writeconfig(int fd, const char *source, - const uint8_t *config_data, int config_len); + const uint8_t *config_data, int config_len, + int compress_lz4); /* * The xl process should always return either EXIT_SUCCESS or diff --git a/tools/xl/xl_migrate.c b/tools/xl/xl_migrate.c index 31a8cb4f32..230aac1b71 100644 --- a/tools/xl/xl_migrate.c +++ b/tools/xl/xl_migrate.c @@ -153,7 +153,7 @@ static void migration_child_report(int recv_fd) { static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child, uint8_t *config_data, int config_len, - const char *rune) + const char *rune, int compress_lz4) { int rc = 0; @@ -172,7 +172,7 @@ static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child, } save_domain_core_writeconfig(send_fd, "migration stream", - config_data, config_len); + config_data, config_len, compress_lz4); } @@ -200,7 +200,7 @@ static void migrate_domain(uint32_t domid, int preserve_domid, child = create_migration_child(rune, &send_fd, &recv_fd); migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len, - rune); + rune, compress_lz4); xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0); @@ -740,7 +740,7 @@ int main_remus(int argc, char **argv) child = create_migration_child(rune, &send_fd, &recv_fd); migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len, - rune); + rune, 0); if (ssh_command[0]) free(rune); diff --git a/tools/xl/xl_saverestore.c b/tools/xl/xl_saverestore.c index 747094ec7b..5151c8a130 100644 --- a/tools/xl/xl_saverestore.c +++ b/tools/xl/xl_saverestore.c @@ -79,7 +79,8 @@ void save_domain_core_begin(uint32_t domid, } void save_domain_core_writeconfig(int fd, const char *source, - const uint8_t *config_data, int config_len) + const uint8_t *config_data, int config_len, + int compress_lz4) { struct save_file_header hdr; uint8_t *optdata_begin; @@ -89,6 +90,8 @@ void save_domain_core_writeconfig(int fd, const char *source, memcpy(hdr.magic, savefileheader_magic, sizeof(hdr.magic)); hdr.byteorder = SAVEFILE_BYTEORDER_VALUE; hdr.mandatory_flags = XL_MANDATORY_FLAG_STREAMv2; + if (compress_lz4) + hdr.mandatory_flags |= XL_MANDATORY_FLAG_COMPRESS_LZ4; optdata_begin= 0; @@ -144,7 +147,7 @@ static int save_domain(uint32_t domid, int preserve_domid, exit(EXIT_FAILURE); } - save_domain_core_writeconfig(fd, filename, config_data, config_len); + save_domain_core_writeconfig(fd, filename, config_data, config_len, 0); int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL); close(fd); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:08:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:08:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456380.1669758 (Exim 4.92) (envelope-from ) id 1xJG8V-000583-MH; Tue, 20 Oct 2026 20:08:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456380.1669758; Tue, 20 Oct 2026 20:08: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 1xJG8V-00057w-IZ; Tue, 20 Oct 2026 20:08:39 +0000 Received: by outflank-mailman (input) for mailman id 1456380; Tue, 20 Oct 2026 20:08:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG8U-00057q-Ly for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:08:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG8T-0066gM-KU for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:08:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7ca16-8faa-0a2a0a5109dd-0a2a4508cd4a-18 for ; Tue, 20 Oct 2026 22:08:37 +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 6ad7c954-f659-0a2a45080019-a0658309d064-3 for ; Tue, 20 Oct 2026 22:04:36 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id B059E842421A; Tue, 20 Oct 2026 16:03: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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie Subject: [PATCH v2 9/9] tools/libs/guest: compress the PAGE_DATA pfn array too Date: Tue, 20 Oct 2026 21:02:37 +0100 Message-ID: <20261020200238.1815766-10-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1792526677-DF8D587B-60237905/13/0 X-purgate-type: clean X-purgate-size: 28017 An LZ4 PAGE_DATA record compresses only its page data. Its pfn array, 8 bytes per page, still travels in plaintext ahead of the frame. Define bit 8 of the flags field: the pfn array is compressed too, with the record's algorithm, as a frame of its own immediately before the page data frame. That makes it easier to handle the pfns and the page data separately, in both the saver and restore. Bit 8 needs an algorithm other than PAGE_DATA_ALGO_NONE. For PAGE_DATA_ALGO_LZ4 both frames carry block checksums. The count stays in plaintext, so restore can bound it before decoding anything, and finds the page data frame where decoding the pfn frame ends. The saver sets bit 8 on every batch it compresses, except when a) the pfn frame is no smaller than the array, so would save nothing, or b) the size rule below applies, for backwards compatibility. Restore decodes both frames with a new helper, which resets the LZ4 context before each frame. This compresses the whole record body apart from count and flags, as discussed in v1. Compressing the pfn array saves a little on real traffic: 0.33% of the page data bytes for a compressible 64 GiB guest, 0.016% for an incompressible one. The size rule (b) makes the saver send the pfn array in plaintext when the two frames total 8 * count bytes plus a whole number of pages. A receiver without "tools/libs/guest: reject non-zero reserved fields in PAGE_DATA" ignores the flags field, so it reads the frames as count pfns followed by page data. Its checks of those pfns may let them pass, which leaves its exact length check as the only certain rejection, and that check could pass at exactly those sizes. This rule can be removed once every receiver has that commit, which is marked for backport to 4.17 and later. libxenguest does not check the rule on restore, as that would prevent it ever being removed; only the Python stream checker does, as a test of the saver. Suggested-by: Andrew Cooper Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - New in v2. Andrew Cooper suggested the pfn array to be compressed too; in v1 review Frediano Ziglio asked about compressing whole records. Tested: builds with and without liblz4; the Python unit tests; a round trip of the changed save and restore functions with Xen stubbed out, under ASan and UBSan, through uncompressed records, LZ4 records with plaintext and with compressed pfns, the size-rule fallback and malformed bit-8 records; and live migrations with xl migrate --compress --debug. docs/specs/libxc-migration-stream.pandoc | 55 ++++++++- tools/libs/guest/xg_sr_restore.c | 140 ++++++++++++++++------- tools/libs/guest/xg_sr_save.c | 59 ++++++++-- tools/libs/guest/xg_sr_stream_format.h | 8 +- tools/python/xen/migration/libxc.py | 43 ++++++- tools/python/xen/migration/tests.py | 39 ++++++- 6 files changed, 284 insertions(+), 60 deletions(-) diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc index 2d25e70e13..86028c7d20 100644 --- a/docs/specs/libxc-migration-stream.pandoc +++ b/docs/specs/libxc-migration-stream.pandoc @@ -326,7 +326,47 @@ flags Bit 7-0: Algorithm used to encode page_data. does not implement, rather than attempting to interpret the page_data. - Bit 31-8: Reserved. Set to zero on save. A restoring side + Bit 8: Compressed pfn array. The pfn array is + compressed too, with the algorithm in bits 7-0. + May only be set when bits 7-0 are not 0x00; a + restoring side must reject the record otherwise. + + When set, the pfn array is not present in + plaintext. The flags field is instead followed + by pfn_frame, whose decompressed content is the + count pfn entries (count * 8 octets, encoded as + for pfn below), then page_data_frame, whose + decompressed content is page_size octets for each + page set as present in that pfn array. They are + back to back, with no separator, length field or + padding between them. + + The length of pfn_frame is not recorded; a + restoring side finds its end by decoding it, so + an algorithm can only be used with bit 8 if its + encoding marks its own end. count is never + compressed, so that a restoring side can bound + its buffers before decompressing anything. + + For algorithm 0x01, both are complete LZ4 frames. + Both must set the block-checksum flag, and a + restoring side must reject one which does not. + page_data_frame is subject to the rules for + algorithm 0x01, and a restoring side must reject + a pfn_frame which does not decode to exactly + count * 8 octets. + + A saving side must send the record with bit 8 + clear instead, the pfn array in plaintext and + page_data_frame as page_data, when the two frames + together, L octets, satisfy L >= count * 8 and + (L - count * 8) is a multiple of page_size. This + ensures that a restoring side which ignores this + field, as revisions 1 to 3 of this specification + required, and so judges the record by its length + alone, rejects it rather than misreading it. + + Bit 31-9: Reserved. Set to zero on save. A restoring side must reject a record with any of these bits set. pfn An array of count PFNs and their types. @@ -346,6 +386,19 @@ page_data Contents of each page set as present in the pfn array, Note: Count is strictly > 0. N is strictly <= C and it is possible for there to be no page_data in the record if all pfns are of invalid types. +When flags bit 8 is set, the record is instead laid out as follows: + + 0 1 2 3 4 5 6 7 octet + +-----------------------+-------------------------+ + | count (C) | flags | + +-----------------------+-------------------------+ + | pfn_frame... | + ... + +-------------------------------------------------+ + | page_data_frame... | + ... + +-------------------------------------------------+ + -------------------------------------------------------------------- PFINFO type Value Description ------------- --------- ------------------------------------------ diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c index 29a3b13253..79dbfccd2f 100644 --- a/tools/libs/guest/xg_sr_restore.c +++ b/tools/libs/guest/xg_sr_restore.c @@ -356,32 +356,19 @@ static int process_page_data(struct xc_sr_context *ctx, unsigned int count, #if defined(XG_SR_LZ4) /* - * Decode the LZ4 frame at src into ctx->restore.lz4_decomp_buf. The - * decoded size comes from the pfn array. + * Decode the LZ4 frame at the start of src into exactly dst_len bytes of + * ctx->restore.lz4_decomp_buf. With consumed NULL the frame must use all of + * src, which rejects trailing data; otherwise its length is returned there. */ -static void *decompress_page_data(struct xc_sr_context *ctx, const void *src, - size_t src_len, unsigned int nr_pages) +static void *lz4_decode_frame(struct xc_sr_context *ctx, const char *what, + const void *src, size_t src_len, size_t dst_len, + size_t *consumed) { xc_interface *xch = ctx->xch; LZ4F_frameInfo_t info; - size_t expected = (size_t)nr_pages * PAGE_SIZE; - size_t out_len = expected, hdr_len = src_len, rest_len, in_len, ret; - - /* The buffer is a fixed MAX_BATCH_SIZE pages. */ - if ( nr_pages > MAX_BATCH_SIZE ) - { - ERROR("Compressed PAGE_DATA record with %u pages exceeds MAX_BATCH_SIZE %u", - nr_pages, MAX_BATCH_SIZE); - return NULL; - } + size_t out_len = dst_len, hdr_len = src_len, rest_len, in_len, ret; - /* The format requires the frame to be strictly shorter than the pages. */ - if ( src_len >= expected ) - { - ERROR("LZ4 frame in PAGE_DATA record (%zu bytes) is not shorter than its page data (%zu bytes)", - src_len, expected); - return NULL; - } + assert(dst_len <= MAX_BATCH_SIZE * PAGE_SIZE); if ( !ctx->restore.lz4_dctx ) { @@ -402,15 +389,15 @@ static void *decompress_page_data(struct xc_sr_context *ctx, const void *src, ret = LZ4F_getFrameInfo(ctx->restore.lz4_dctx, &info, src, &hdr_len); if ( LZ4F_isError(ret) ) { - ERROR("LZ4 frame in PAGE_DATA record has a bad header: %s", - LZ4F_getErrorName(ret)); + ERROR("LZ4 %s frame in PAGE_DATA record has a bad header: %s", + what, LZ4F_getErrorName(ret)); return NULL; } /* liblz4 accepts frames without the block checksums required here. */ if ( info.blockChecksumFlag != LZ4F_blockChecksumEnabled ) { - ERROR("LZ4 frame in PAGE_DATA record has no block checksums"); + ERROR("LZ4 %s frame in PAGE_DATA record has no block checksums", what); return NULL; } @@ -436,36 +423,64 @@ static void *decompress_page_data(struct xc_sr_context *ctx, const void *src, if ( LZ4F_isError(ret) ) { - ERROR("Failed to decompress PAGE_DATA record: %s", - LZ4F_getErrorName(ret)); + ERROR("Failed to decompress LZ4 %s frame in PAGE_DATA record: %s", + what, LZ4F_getErrorName(ret)); return NULL; } /* Not an error, but the frame did not end: input or output ran out. */ if ( ret != 0 ) { - ERROR("LZ4 frame in PAGE_DATA record is truncated or decodes to over %zu bytes", - expected); + ERROR("LZ4 %s frame in PAGE_DATA record is truncated or decodes to over %zu bytes", + what, dst_len); return NULL; } /* in_len and out_len now hold the bytes consumed and produced. */ - if ( out_len != expected ) + if ( out_len != dst_len ) { - ERROR("LZ4 frame in PAGE_DATA record produced %zu bytes, expected %zu", - out_len, expected); + ERROR("LZ4 %s frame in PAGE_DATA record produced %zu bytes, expected %zu", + what, out_len, dst_len); return NULL; } - if ( in_len != rest_len ) + if ( consumed ) + *consumed = hdr_len + in_len; + else if ( in_len != rest_len ) { - ERROR("LZ4 frame in PAGE_DATA record followed by %zu unconsumed bytes", - rest_len - in_len); + ERROR("LZ4 %s frame in PAGE_DATA record followed by %zu unconsumed bytes", + what, rest_len - in_len); return NULL; } return ctx->restore.lz4_decomp_buf; } + +/* Decompress the page data frame at src, of nr_pages pages. */ +static void *decompress_page_data(struct xc_sr_context *ctx, const void *src, + size_t src_len, unsigned int nr_pages) +{ + xc_interface *xch = ctx->xch; + size_t expected = (size_t)nr_pages * PAGE_SIZE; + + /* The buffer is a fixed MAX_BATCH_SIZE pages. */ + if ( nr_pages > MAX_BATCH_SIZE ) + { + ERROR("Compressed PAGE_DATA record with %u pages exceeds MAX_BATCH_SIZE %u", + nr_pages, MAX_BATCH_SIZE); + return NULL; + } + + /* The format requires the frame to be strictly shorter than the pages. */ + if ( src_len >= expected ) + { + ERROR("LZ4 frame in PAGE_DATA record (%zu bytes) is not shorter than its page data (%zu bytes)", + src_len, expected); + return NULL; + } + + return lz4_decode_frame(ctx, "page data", src, src_len, expected, NULL); +} #endif /* XG_SR_LZ4 */ /* @@ -476,7 +491,9 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) { xc_interface *xch = ctx->xch; struct xc_sr_rec_page_data_header *pages = rec->data; + const uint64_t *rec_pfns; unsigned int i, pages_of_data = 0; + size_t pfn_len; void *page_data; int rc = -1; @@ -523,17 +540,54 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) goto err; } + /* Compressed pfns need an algorithm; only LZ4 is implemented. */ + if ( (pages->flags & PAGE_DATA_FLAG_COMPRESSED_PFNS) && + (pages->flags & PAGE_DATA_ALGO_MASK) != PAGE_DATA_ALGO_LZ4 ) + { + ERROR("Compressed pfn array with unsupported algorithm %u in PAGE_DATA record", + (unsigned int)(pages->flags & PAGE_DATA_ALGO_MASK)); + goto err; + } + if ( pages->count < 1 ) { ERROR("Expected at least 1 pfn in PAGE_DATA record"); goto err; } - if ( rec->length < sizeof(*pages) + (pages->count * sizeof(uint64_t)) ) + if ( pages->flags & PAGE_DATA_FLAG_COMPRESSED_PFNS ) { - ERROR("PAGE_DATA record (length %u) too short to contain %u" - " pfns worth of information", rec->length, pages->count); +#if defined(XG_SR_LZ4) + if ( pages->count > MAX_BATCH_SIZE ) + { + ERROR("Compressed pfns in PAGE_DATA record: count %u exceeds MAX_BATCH_SIZE %u", + pages->count, MAX_BATCH_SIZE); + goto err; + } + + /* The page data frame overwrites these, after the copy below. */ + rec_pfns = lz4_decode_frame(ctx, "pfn", pages->pfn, + rec->length - sizeof(*pages), + pages->count * sizeof(uint64_t), + &pfn_len); + if ( !rec_pfns ) + goto err; +#else + ERROR("LZ4 compressed PAGE_DATA record but LZ4 support not compiled in"); goto err; +#endif + } + else + { + if ( rec->length < sizeof(*pages) + (pages->count * sizeof(uint64_t)) ) + { + ERROR("PAGE_DATA record (length %u) too short to contain %u" + " pfns worth of information", rec->length, pages->count); + goto err; + } + + rec_pfns = pages->pfn; + pfn_len = pages->count * sizeof(uint64_t); } pfns = malloc(pages->count * sizeof(*pfns)); @@ -547,21 +601,21 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) for ( i = 0; i < pages->count; ++i ) { - if ( pages->pfn[i] & PAGE_DATA_PFN_RESZ_MASK ) + if ( rec_pfns[i] & PAGE_DATA_PFN_RESZ_MASK ) { ERROR("Reserved bits set in pfn[%u]: %#"PRIx64, i, - pages->pfn[i]); + rec_pfns[i]); goto err; } - pfn = pages->pfn[i] & PAGE_DATA_PFN_MASK; + pfn = rec_pfns[i] & PAGE_DATA_PFN_MASK; if ( !ctx->restore.ops.pfn_is_valid(ctx, pfn) ) { ERROR("pfn %#"PRIpfn" (index %u) outside domain maximum", pfn, i); goto err; } - type = (pages->pfn[i] & PAGE_DATA_TYPE_MASK) >> 32; + type = (rec_pfns[i] & PAGE_DATA_TYPE_MASK) >> 32; if ( !is_known_page_type(type) ) { ERROR("Unknown type %#"PRIx32" for pfn %#"PRIpfn" (index %u)", @@ -578,7 +632,7 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) types[i] = type; } - page_data = &pages->pfn[pages->count]; + page_data = (uint8_t *)pages->pfn + pfn_len; switch ( pages->flags & PAGE_DATA_ALGO_MASK ) { @@ -598,7 +652,7 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) case PAGE_DATA_ALGO_LZ4: #if defined(XG_SR_LZ4) { - size_t hdrsz = sizeof(*pages) + (sizeof(uint64_t) * pages->count); + size_t hdrsz = sizeof(*pages) + pfn_len; page_data = decompress_page_data(ctx, page_data, rec->length - hdrsz, pages_of_data); diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c index fe3d78bdd6..192abc82c5 100644 --- a/tools/libs/guest/xg_sr_save.c +++ b/tools/libs/guest/xg_sr_save.c @@ -150,11 +150,19 @@ static void compress_stats_evaluate(struct xc_sr_context *ctx) */ #define XC_SR_COMPRESS_BLOCK_SIZE LZ4F_max4MB +/* Size rule: could len bytes pass as pfns_len of pfns plus whole pages? */ +static bool page_data_size_clash(size_t len, size_t pfns_len) +{ + return len >= pfns_len && (len - pfns_len) % PAGE_SIZE == 0; +} + /* * Compress the page data in iov[2..iovcnt) into an LZ4 frame, and replace - * those entries with one describing it, padded to the record alignment. - * Returns the new iovcnt, the original one with iov untouched if the batch - * should be sent uncompressed, or -1 if the batch itself is malformed. + * those entries with one describing it, padded to the record alignment. The + * pfn array in iov[1] becomes a second frame too, unless that is no smaller or + * the size rule applies. Returns the new iovcnt, the original one with iov + * untouched if the batch should be sent uncompressed, or -1 if the batch + * itself is malformed. */ static int lz4_compress_batch(struct xc_sr_context *ctx, struct iovec *iov, int iovcnt, unsigned int nr_pages, @@ -167,7 +175,7 @@ static int lz4_compress_batch(struct xc_sr_context *ctx, struct iovec *iov, }, }; xc_interface *xch = ctx->xch; - size_t raw = (size_t)nr_pages * PAGE_SIZE, clen, staged; + size_t raw = (size_t)nr_pages * PAGE_SIZE, clen, pfn_clen, staged, pad; uint8_t *dst; int i; @@ -176,8 +184,9 @@ static int lz4_compress_batch(struct xc_sr_context *ctx, struct iovec *iov, if ( !ctx->save.lz4_staging_buf ) { + /* The page data frame plus up to REC_ALIGN - 1 bytes of padding. */ size_t bound = LZ4F_compressFrameBound(MAX_BATCH_SIZE * PAGE_SIZE, - &prefs); + &prefs) + REC_ALIGN; ctx->save.lz4_staging_buf = malloc(MAX_BATCH_SIZE * PAGE_SIZE); ctx->save.lz4_compress_buf = malloc(bound); @@ -233,16 +242,44 @@ static int lz4_compress_batch(struct xc_sr_context *ctx, struct iovec *iov, (clen * 1000 / raw) / 10, (clen * 1000 / raw) % 10); compress_stats_accumulate(ctx, raw, clen); - /* Pad in place: raw is a multiple of REC_ALIGN and > clen, so it fits. */ - memset((uint8_t *)ctx->save.lz4_compress_buf + clen, 0, - ROUNDUP(clen, REC_ALIGN) - clen); - - iov[2].iov_base = ctx->save.lz4_compress_buf; - iov[2].iov_len = ROUNDUP(clen, REC_ALIGN); + /* The pages are compressed: reuse the staging buffer for the pfn frame. */ + assert(LZ4F_compressFrameBound(iov[1].iov_len, &prefs) <= + MAX_BATCH_SIZE * PAGE_SIZE); + pfn_clen = LZ4F_compressFrame(ctx->save.lz4_staging_buf, + MAX_BATCH_SIZE * PAGE_SIZE, + iov[1].iov_base, iov[1].iov_len, &prefs); + + /* + * The size rule only protects receivers without "tools/libs/guest: + * reject non-zero reserved fields in PAGE_DATA"; drop it once none remain. + * Such a receiver reads the frames as iov[1].iov_len bytes of pfns and + * pages, so page_data_size_clash() checks the lengths as it sees them. + */ + if ( LZ4F_isError(pfn_clen) || pfn_clen >= iov[1].iov_len || + page_data_size_clash(pfn_clen + clen, iov[1].iov_len) ) + DBGPRINTF("LZ4: sending %zu bytes of pfns uncompressed", + iov[1].iov_len); + else + { + *flags |= PAGE_DATA_FLAG_COMPRESSED_PFNS; + *length -= iov[1].iov_len - pfn_clen; + iov[1].iov_base = ctx->save.lz4_staging_buf; + iov[1].iov_len = pfn_clen; + } *flags |= PAGE_DATA_ALGO_LZ4; *length -= raw - clen; + /* Pad in place: the buffer was allocated with REC_ALIGN to spare. */ + pad = ROUNDUP(*length, REC_ALIGN) - *length; + memset((uint8_t *)ctx->save.lz4_compress_buf + clen, 0, pad); + + iov[2].iov_base = ctx->save.lz4_compress_buf; + iov[2].iov_len = clen + pad; + + assert(iov[0].iov_len + iov[1].iov_len + iov[2].iov_len == + sizeof(struct xc_sr_rhdr) + ROUNDUP(*length, REC_ALIGN)); + /* iov[0] headers, iov[1] pfns, iov[2] page data frame. */ return 3; } diff --git a/tools/libs/guest/xg_sr_stream_format.h b/tools/libs/guest/xg_sr_stream_format.h index af695ae771..9bc5b75104 100644 --- a/tools/libs/guest/xg_sr_stream_format.h +++ b/tools/libs/guest/xg_sr_stream_format.h @@ -87,9 +87,13 @@ struct xc_sr_rec_page_data_header uint64_t pfn[0]; }; -/* PAGE_DATA flags: bits 7-0 are the algorithm, bits 31-8 are reserved. */ +/* + * PAGE_DATA flags: bits 7-0 are the algorithm, bit 8 marks a compressed pfn + * array, bits 31-9 are reserved. + */ #define PAGE_DATA_ALGO_MASK 0x000000ffU -#define PAGE_DATA_FLAGS_RESZ_MASK 0xffffff00U +#define PAGE_DATA_FLAG_COMPRESSED_PFNS 0x00000100U +#define PAGE_DATA_FLAGS_RESZ_MASK 0xfffffe00U #define PAGE_DATA_ALGO_NONE 0x00000000U #define PAGE_DATA_ALGO_LZ4 0x00000001U diff --git a/tools/python/xen/migration/libxc.py b/tools/python/xen/migration/libxc.py index 10e163e272..5e606a70ee 100644 --- a/tools/python/xen/migration/libxc.py +++ b/tools/python/xen/migration/libxc.py @@ -86,9 +86,11 @@ PAGE_DATA_FORMAT = "II" PAGE_DATA_PFN_MASK = (1 << 52) - 1 PAGE_DATA_PFN_RESZ_MASK = ((1 << 60) - 1) & ~((1 << 52) - 1) -# page_data flags: bits 7-0 algorithm, bits 31-8 reserved (must reject) +# page_data flags: bits 7-0 algorithm, bit 8 pfn array compressed too (not with +# algorithm 0), bits 31-9 reserved (must reject) PAGE_DATA_ALGO_MASK = 0x000000ff -PAGE_DATA_FLAGS_RESZ_MASK = 0xffffff00 +PAGE_DATA_FLAG_COMPRESSED_PFNS = 0x00000100 +PAGE_DATA_FLAGS_RESZ_MASK = 0xfffffe00 PAGE_DATA_ALGO_NONE = 0x00 PAGE_DATA_ALGO_LZ4 = 0x01 @@ -278,6 +280,10 @@ class VerifyLibxc(VerifyBase): algo = flags & PAGE_DATA_ALGO_MASK + if flags & PAGE_DATA_FLAG_COMPRESSED_PFNS: + self.verify_page_data_compressed_pfns(content[minsz:], count, algo) + return + pfnsz = count * 8 if (len(content) - minsz) < pfnsz: raise RecordError( @@ -333,6 +339,39 @@ class VerifyLibxc(VerifyBase): "Unsupported algorithm %u in PAGE_DATA record" % (algo, )) + def verify_page_data_compressed_pfns(self, payload, count, algo): + """ Page Data record whose pfn array is compressed too """ + + if algo == PAGE_DATA_ALGO_NONE: + raise RecordError( + "Compressed pfn array without an algorithm in PAGE_DATA record") + if algo != PAGE_DATA_ALGO_LZ4: + raise StreamError( + "Unsupported algorithm %u in PAGE_DATA record" % (algo, )) + + if count == 0: + raise RecordError("PAGE_DATA record with no pfns") + + # Without decompressing, check the saver's size rule: not count pfns + # plus whole pages, which a receiver ignoring flags could misread. + pfnsz = count * 8 + if len(payload) >= pfnsz and (len(payload) - pfnsz) % 4096 == 0: + raise RecordError( + "Compressed PAGE_DATA payload of %u is %u pfns and whole pages" + % (len(payload), count)) + + # Only the pfn frame's header is checkable: the page data frame starts + # where decoding the pfn frame ends. + if len(payload) < PAGE_DATA_LZ4_FRAME_MIN: + raise RecordError( + "LZ4 frame in PAGE_DATA record too short: %u bytes" + % (len(payload), )) + + if not ord(payload[4:5]) & PAGE_DATA_LZ4_FLG_BLOCKSUM: + raise RecordError( + "LZ4 frame in PAGE_DATA record has no block checksums") + + def verify_record_x86_pv_info(self, content): """ x86 PV Info record """ diff --git a/tools/python/xen/migration/tests.py b/tools/python/xen/migration/tests.py index 9e6d925e51..dd7e8eb5cd 100644 --- a/tools/python/xen/migration/tests.py +++ b/tools/python/xen/migration/tests.py @@ -74,10 +74,47 @@ class TestLibxc(unittest.TestCase): # An unimplemented algorithm, and any reserved bit, are refused. self.assertRaises(libxc.StreamError, v.verify_record_page_data, rec(libxc.PAGE_DATA_ALGO_LZ4 + 1, FRAME)) - for bit in range(8, 32): + for bit in range(9, 32): self.assertRaises(libxc.StreamError, v.verify_record_page_data, rec(1 << bit, PAGE)) + def test_page_data_compressed_pfns(self): + """ PAGE_DATA with the pfn array compressed too (flags bit 8) """ + + v = libxc.VerifyLibxc(lambda *_: None, lambda *_: b"") + FRAME = b"\x04\x22\x4d\x18\x70\x70\x72" + b"\x00" * 93 + PFNS = libxc.PAGE_DATA_FLAG_COMPRESSED_PFNS + LZ4 = libxc.PAGE_DATA_ALGO_LZ4 + + def rec(count, flags, payload): + return pack(libxc.PAGE_DATA_FORMAT, count, flags) + payload + + # Two frames are fine unless they total 8 * count plus whole pages, + # which a receiver ignoring the flags could misread. + v.verify_record_page_data(rec(1024, PFNS | LZ4, FRAME + FRAME)) + v.verify_record_page_data(rec(16, PFNS | LZ4, FRAME + FRAME)) + for extra in (0, 4096, 2 * 4096): + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(16, PFNS | LZ4, + FRAME + b"\x00" * (128 + extra - 100))) + + # The pfn frame has a whole header, with block checksums, and there + # are pfns at all. + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(16, PFNS | LZ4, FRAME[:6])) + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(16, PFNS | LZ4, + FRAME[:4] + b"\x60" + FRAME[5:] + FRAME)) + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(0, PFNS | LZ4, FRAME + FRAME)) + + # Bit 8 needs a compression algorithm, and one this checker knows. + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(16, PFNS | libxc.PAGE_DATA_ALGO_NONE, + FRAME + FRAME)) + self.assertRaises(libxc.StreamError, v.verify_record_page_data, + rec(16, PFNS | (LZ4 + 1), FRAME + FRAME)) + class TestLibxl(unittest.TestCase): -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:09:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:09:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456397.1669766 (Exim 4.92) (envelope-from ) id 1xJG8x-0005ZP-So; Tue, 20 Oct 2026 20:09:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456397.1669766; Tue, 20 Oct 2026 20: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 1xJG8x-0005ZI-Q1; Tue, 20 Oct 2026 20:09:07 +0000 Received: by outflank-mailman (input) for mailman id 1456397; Tue, 20 Oct 2026 20:09:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG8w-0005Yy-BH for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:09:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG8v-00GP9w-MT for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:09:05 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7ca61-e002-0a2a0a5209dd-0a2a4505b4c0-0 for ; Tue, 20 Oct 2026 22:09:05 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7c933-4cb1-0a2a45050019-a0658309e30e-3 for ; Tue, 20 Oct 2026 22:04:04 +0200 Received: from mewpvdipd1023.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id A843A8424213; Tue, 20 Oct 2026 16:03:19 -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: Marcus Granado To: xen-devel@lists.xenproject.org Cc: Marcus Granado , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Teddy Astie Subject: [PATCH v2 3/9] tools/libs/guest: decompress LZ4 PAGE_DATA records on restore Date: Tue, 20 Oct 2026 21:02:31 +0100 Message-ID: <20261020200238.1815766-4-marcus.granado@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020200238.1815766-1-marcus.granado@citrix.com> References: <20261020200238.1815766-1-marcus.granado@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1792526644-726B52A1-715D3F49/13/0 X-purgate-type: clean X-purgate-size: 18558 PAGE_DATA records carry page contents uncompressed; algorithm 0x00 is the only one assigned in their flags field. Compressing them would put less data on the wire during migration, at a CPU cost on both hosts, worth paying where the bottleneck is the link, or encryption of the stream by ssh or TLS. Assign algorithm 0x01 (PAGE_DATA_ALGO_LZ4) to LZ4, and decode it on restore. page_data is then one LZ4 frame: LZ4 for its speed, and its Frame Format because it is specified outside Xen, delimits itself and can carry block checksums. This encoding requires these checksums, as without them a corrupted frame can decode into wrong page contents; liblz4 accepts a frame without them, so the decoder checks the block-checksum flag itself. The output size comes from the pfn array, and the frame must decode to exactly that size and end where the record ends. Before decoding, the record must have no more pages of data than the decoder's buffer holds (the most the saver puts in a record), and a payload strictly shorter than the uncompressed page data. The stream specification requires the latter for a saver: it makes an older libxenguest which ignores the flags field fail its exact length check on these records, rather than take the frame for page contents. Nothing emits algorithm 0x01 yet, so receivers can be updated first. Restore has no option to turn it on or off: any stream may use it. The decoder is guarded by XG_SR_LZ4, which xg_sr_common.h defines when HAVE_LZ4 is set and liblz4 is 1.8.1 or later, avoiding releases with known decoder bugs. A build without XG_SR_LZ4 rejects algorithm 0x01 with an error naming the missing LZ4 support. configure puts -DHAVE_LZ4 and liblz4's CFLAGS in ZLIB_CFLAGS, which only xg_dom_bzimageloader.o used: apply it to every libxenguest object, so that HAVE_LZ4, and the layout of any structure that depends on it, cannot differ between objects. The Python stream validator checks algorithm 0x01's payload length and block-checksum flag, and test_page_data_flags gains LZ4 cases. Suggested-by: Teddy Astie Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Marcus Granado --- Notes: Changes in v2: - Was v1 2/6, which decoded per-page LZ4 blocks from a new PAGE_DATA_LZ4 record. Now PAGE_DATA algorithm 0x01: one LZ4 frame per record, as Teddy Astie suggested, with mandatory block checksums. - The uncompressed size asked for by Teddy Astie and Frediano Ziglio comes from the pfn array; the decode buffer has a fixed size. docs/specs/libxc-migration-stream.pandoc | 24 +++- tools/libs/guest/Makefile | 2 +- tools/libs/guest/xg_sr_common.h | 16 +++ tools/libs/guest/xg_sr_restore.c | 141 ++++++++++++++++++++++- tools/libs/guest/xg_sr_stream_format.h | 1 + tools/python/xen/migration/libxc.py | 23 ++++ tools/python/xen/migration/tests.py | 31 ++++- 7 files changed, 229 insertions(+), 9 deletions(-) diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc index fd44dd6e0a..2d25e70e13 100644 --- a/docs/specs/libxc-migration-stream.pandoc +++ b/docs/specs/libxc-migration-stream.pandoc @@ -40,8 +40,6 @@ Not Yet Included The following features are not yet fully specified and will be included in a future draft. -* Page data compression. - * ARM @@ -305,7 +303,24 @@ flags Bit 7-0: Algorithm used to encode page_data. 0x00: None. page_data is page_size octets of uncompressed contents per present page. - 0x01 - 0xFF: Unassigned. + 0x01: LZ4. page_data is a single LZ4 frame, as + defined by the LZ4 Frame Format specification[^1], + whose decompressed content is page_size octets + for each present page. A restoring side must + reject a frame which does not decode to exactly + that many octets, or which does not end where + page_data ends. + + The frame must set the block-checksum flag in + its frame descriptor, and a restoring side must + reject one which does not. + + A saving side may only use this value when the + frame is strictly shorter than the uncompressed + page_data it replaces; otherwise it must send the + record with algorithm 0x00. + + 0x02 - 0xFF: Unassigned. A restoring side must fail on an algorithm value it does not implement, rather than attempting to @@ -371,6 +386,9 @@ guest's P2M table during a live migration[^2]. Restoring an image with unrecognised page types shall fail. +[^1]: LZ4 Frame Format Description, version 1.6.4: + + [^2]: In the legacy format, this is the list of unmapped PFNs in the tail. diff --git a/tools/libs/guest/Makefile b/tools/libs/guest/Makefile index 93338a9301..037f1f4de9 100644 --- a/tools/libs/guest/Makefile +++ b/tools/libs/guest/Makefile @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk include Makefile.common -xg_dom_bzimageloader.o xg_dom_bzimageloader.opic: CFLAGS += $(ZLIB_CFLAGS) +CFLAGS += $(ZLIB_CFLAGS) $(LIBELF_OBJS:.o=.opic): CFLAGS += -Wno-pointer-sign diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h index c07c6db59e..53647caa30 100644 --- a/tools/libs/guest/xg_sr_common.h +++ b/tools/libs/guest/xg_sr_common.h @@ -3,6 +3,18 @@ #include +#if defined(HAVE_LZ4) +#include +/* + * 1.8.1 fixed a memcpy() from NULL in LZ4F_decompress(). + * 1.9.0's decoder reads past its input (fixed in 1.9.1). + */ +#if LZ4_VERSION_NUMBER >= 10801 && LZ4_VERSION_NUMBER != 10900 +#include +#define XG_SR_LZ4 +#endif +#endif + #include "xg_private.h" #include "xg_save_restore.h" #include "xg_sr_stream_format.h" @@ -277,6 +289,10 @@ struct xc_sr_context /* Whether a STATIC_DATA_END record has been seen/inferred. */ bool seen_static_data_end; + /* LZ4 decoder buffer and context, allocated on first use. */ + void *lz4_decomp_buf; + void *lz4_dctx; + /* * With Remus/COLO, we buffer the records sent by the primary at checkpoint, * in case the primary will fail, we can recover from the last diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c index 93b020b55f..29a3b13253 100644 --- a/tools/libs/guest/xg_sr_restore.c +++ b/tools/libs/guest/xg_sr_restore.c @@ -354,6 +354,120 @@ static int process_page_data(struct xc_sr_context *ctx, unsigned int count, return rc; } +#if defined(XG_SR_LZ4) +/* + * Decode the LZ4 frame at src into ctx->restore.lz4_decomp_buf. The + * decoded size comes from the pfn array. + */ +static void *decompress_page_data(struct xc_sr_context *ctx, const void *src, + size_t src_len, unsigned int nr_pages) +{ + xc_interface *xch = ctx->xch; + LZ4F_frameInfo_t info; + size_t expected = (size_t)nr_pages * PAGE_SIZE; + size_t out_len = expected, hdr_len = src_len, rest_len, in_len, ret; + + /* The buffer is a fixed MAX_BATCH_SIZE pages. */ + if ( nr_pages > MAX_BATCH_SIZE ) + { + ERROR("Compressed PAGE_DATA record with %u pages exceeds MAX_BATCH_SIZE %u", + nr_pages, MAX_BATCH_SIZE); + return NULL; + } + + /* The format requires the frame to be strictly shorter than the pages. */ + if ( src_len >= expected ) + { + ERROR("LZ4 frame in PAGE_DATA record (%zu bytes) is not shorter than its page data (%zu bytes)", + src_len, expected); + return NULL; + } + + if ( !ctx->restore.lz4_dctx ) + { + LZ4F_dctx *dctx = NULL; + + ret = LZ4F_createDecompressionContext(&dctx, LZ4F_VERSION); + if ( LZ4F_isError(ret) ) + { + ERROR("Unable to create LZ4 decompression context"); + return NULL; + } + ctx->restore.lz4_dctx = dctx; + } + + /* Start each frame at its header (restore stops at any error). */ + LZ4F_resetDecompressionContext(ctx->restore.lz4_dctx); + + ret = LZ4F_getFrameInfo(ctx->restore.lz4_dctx, &info, src, &hdr_len); + if ( LZ4F_isError(ret) ) + { + ERROR("LZ4 frame in PAGE_DATA record has a bad header: %s", + LZ4F_getErrorName(ret)); + return NULL; + } + + /* liblz4 accepts frames without the block checksums required here. */ + if ( info.blockChecksumFlag != LZ4F_blockChecksumEnabled ) + { + ERROR("LZ4 frame in PAGE_DATA record has no block checksums"); + return NULL; + } + + if ( !ctx->restore.lz4_decomp_buf ) + { + ctx->restore.lz4_decomp_buf = malloc(MAX_BATCH_SIZE * PAGE_SIZE); + if ( !ctx->restore.lz4_decomp_buf ) + { + ERROR("Unable to allocate %lu bytes for decompression", + (unsigned long)MAX_BATCH_SIZE * PAGE_SIZE); + return NULL; + } + } + + /* LZ4F_getFrameInfo() read the header; decode the rest of the frame. */ + rest_len = src_len - hdr_len; + in_len = rest_len; + + /* NULL options: checksums are verified; liblz4 keeps its own buffers. */ + ret = LZ4F_decompress(ctx->restore.lz4_dctx, ctx->restore.lz4_decomp_buf, + &out_len, (const uint8_t *)src + hdr_len, &in_len, + NULL); + + if ( LZ4F_isError(ret) ) + { + ERROR("Failed to decompress PAGE_DATA record: %s", + LZ4F_getErrorName(ret)); + return NULL; + } + + /* Not an error, but the frame did not end: input or output ran out. */ + if ( ret != 0 ) + { + ERROR("LZ4 frame in PAGE_DATA record is truncated or decodes to over %zu bytes", + expected); + return NULL; + } + + /* in_len and out_len now hold the bytes consumed and produced. */ + if ( out_len != expected ) + { + ERROR("LZ4 frame in PAGE_DATA record produced %zu bytes, expected %zu", + out_len, expected); + return NULL; + } + + if ( in_len != rest_len ) + { + ERROR("LZ4 frame in PAGE_DATA record followed by %zu unconsumed bytes", + rest_len - in_len); + return NULL; + } + + return ctx->restore.lz4_decomp_buf; +} +#endif /* XG_SR_LZ4 */ + /* * Validate a PAGE_DATA record from the stream, and pass the results to * process_page_data() to actually perform the legwork. @@ -363,6 +477,7 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) xc_interface *xch = ctx->xch; struct xc_sr_rec_page_data_header *pages = rec->data; unsigned int i, pages_of_data = 0; + void *page_data; int rc = -1; xen_pfn_t *pfns = NULL, pfn; @@ -463,6 +578,8 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) types[i] = type; } + page_data = &pages->pfn[pages->count]; + switch ( pages->flags & PAGE_DATA_ALGO_MASK ) { case PAGE_DATA_ALGO_NONE: @@ -478,14 +595,29 @@ static int handle_page_data(struct xc_sr_context *ctx, struct xc_sr_record *rec) } break; + case PAGE_DATA_ALGO_LZ4: +#if defined(XG_SR_LZ4) + { + size_t hdrsz = sizeof(*pages) + (sizeof(uint64_t) * pages->count); + + page_data = decompress_page_data(ctx, page_data, + rec->length - hdrsz, pages_of_data); + if ( !page_data ) + goto err; + break; + } +#else + ERROR("LZ4 compressed PAGE_DATA record but LZ4 support not compiled in"); + goto err; +#endif + default: ERROR("Unsupported algorithm %u in PAGE_DATA record", (unsigned int)(pages->flags & PAGE_DATA_ALGO_MASK)); goto err; } - rc = process_page_data(ctx, pages->count, pfns, types, - &pages->pfn[pages->count]); + rc = process_page_data(ctx, pages->count, pfns, types, page_data); err: free(types); free(pfns); @@ -822,6 +954,11 @@ static void cleanup(struct xc_sr_context *ctx) free(ctx->restore.buffered_records); free(ctx->restore.populated_pfns); + free(ctx->restore.lz4_decomp_buf); +#if defined(XG_SR_LZ4) + if ( ctx->restore.lz4_dctx ) + LZ4F_freeDecompressionContext(ctx->restore.lz4_dctx); +#endif if ( ctx->restore.ops.cleanup(ctx) ) PERROR("Failed to clean up"); diff --git a/tools/libs/guest/xg_sr_stream_format.h b/tools/libs/guest/xg_sr_stream_format.h index f839d874c8..af695ae771 100644 --- a/tools/libs/guest/xg_sr_stream_format.h +++ b/tools/libs/guest/xg_sr_stream_format.h @@ -92,6 +92,7 @@ struct xc_sr_rec_page_data_header #define PAGE_DATA_FLAGS_RESZ_MASK 0xffffff00U #define PAGE_DATA_ALGO_NONE 0x00000000U +#define PAGE_DATA_ALGO_LZ4 0x00000001U #define PAGE_DATA_PFN_MASK 0x000fffffffffffffULL #define PAGE_DATA_PFN_RESZ_MASK 0x0ff0000000000000ULL diff --git a/tools/python/xen/migration/libxc.py b/tools/python/xen/migration/libxc.py index 2906b78d36..10e163e272 100644 --- a/tools/python/xen/migration/libxc.py +++ b/tools/python/xen/migration/libxc.py @@ -90,6 +90,11 @@ PAGE_DATA_PFN_RESZ_MASK = ((1 << 60) - 1) & ~((1 << 52) - 1) PAGE_DATA_ALGO_MASK = 0x000000ff PAGE_DATA_FLAGS_RESZ_MASK = 0xffffff00 PAGE_DATA_ALGO_NONE = 0x00 +PAGE_DATA_ALGO_LZ4 = 0x01 + +# LZ4 frame: at least magic, FLG, BD and HC; FLG bit 4 is B.Checksum +PAGE_DATA_LZ4_FRAME_MIN = 7 +PAGE_DATA_LZ4_FLG_BLOCKSUM = 0x10 # flags from xen/public/domctl.h: XEN_DOMCTL_PFINFO_* shifted by 32 bits PAGE_DATA_TYPE_SHIFT = 60 @@ -305,6 +310,24 @@ class VerifyLibxc(VerifyBase): raise RecordError("Expected %u + %u + %u, got %u" % (minsz, pfnsz, pagesz, len(content))) + elif algo == PAGE_DATA_ALGO_LZ4: + + # Without decompressing, check the saver's length rule. + if datasz >= pagesz: + raise RecordError( + "LZ4 frame in PAGE_DATA record (%u bytes) is not shorter than its page data (%u bytes)" + % (datasz, pagesz)) + + frame = content[minsz + pfnsz:] + if len(frame) < PAGE_DATA_LZ4_FRAME_MIN: + raise RecordError( + "LZ4 frame in PAGE_DATA record too short: %u bytes" + % (len(frame), )) + + if not ord(frame[4:5]) & PAGE_DATA_LZ4_FLG_BLOCKSUM: + raise RecordError( + "LZ4 frame in PAGE_DATA record has no block checksums") + else: raise StreamError( "Unsupported algorithm %u in PAGE_DATA record" % (algo, )) diff --git a/tools/python/xen/migration/tests.py b/tools/python/xen/migration/tests.py index 1944ae09b3..9e6d925e51 100644 --- a/tools/python/xen/migration/tests.py +++ b/tools/python/xen/migration/tests.py @@ -36,19 +36,44 @@ class TestLibxc(unittest.TestCase): v = libxc.VerifyLibxc(lambda *_: None, lambda *_: b"") PAGE = b"\x00" * 4096 NOTAB = libxc.PAGE_DATA_TYPE_NOTAB | 0x1 # one normal page, pfn 1 + XTAB = libxc.PAGE_DATA_TYPE_XTAB | 0x1 # no page of data, pfn 1 - def rec(flags, data): + def rec(flags, data, pfn=NOTAB): return pack(libxc.PAGE_DATA_FORMAT, 1, flags) + \ - pack("=Q", NOTAB) + data + pack("=Q", pfn) + data # Uncompressed: exactly one page of data, and nothing else accepted. v.verify_record_page_data(rec(libxc.PAGE_DATA_ALGO_NONE, PAGE)) self.assertRaises(libxc.RecordError, v.verify_record_page_data, rec(libxc.PAGE_DATA_ALGO_NONE, PAGE[:-1])) + # An LZ4 frame header: magic, then FLG with the block-checksum bit. + FRAME = b"\x04\x22\x4d\x18\x70\x70\x72" + b"\x00" * 93 + + # LZ4: the payload is checked against the saver's length rule, + # 0 < len < the uncompressed size it replaces: one page here, and + # none with an XTAB pfn. FULL is a valid frame header padded to one + # page, so only the length rule can reject it. + FULL = FRAME + b"\x00" * (4096 - len(FRAME)) + v.verify_record_page_data(rec(libxc.PAGE_DATA_ALGO_LZ4, FULL[:-1])) + v.verify_record_page_data(rec(libxc.PAGE_DATA_ALGO_LZ4, FRAME)) + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(libxc.PAGE_DATA_ALGO_LZ4, b"")) + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(libxc.PAGE_DATA_ALGO_LZ4, FULL)) + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(libxc.PAGE_DATA_ALGO_LZ4, FRAME, XTAB)) + + # ... and against the frame having a whole header with block checksums. + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(libxc.PAGE_DATA_ALGO_LZ4, + FRAME[:4] + b"\x60" + FRAME[5:])) + self.assertRaises(libxc.RecordError, v.verify_record_page_data, + rec(libxc.PAGE_DATA_ALGO_LZ4, FRAME[:6])) + # An unimplemented algorithm, and any reserved bit, are refused. self.assertRaises(libxc.StreamError, v.verify_record_page_data, - rec(libxc.PAGE_DATA_ALGO_NONE + 1, PAGE)) + rec(libxc.PAGE_DATA_ALGO_LZ4 + 1, FRAME)) for bit in range(8, 32): self.assertRaises(libxc.StreamError, v.verify_record_page_data, rec(1 << bit, PAGE)) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:09:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:09:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456423.1669776 (Exim 4.92) (envelope-from ) id 1xJG9X-00067W-8y; Tue, 20 Oct 2026 20:09:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456423.1669776; Tue, 20 Oct 2026 20:09: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 1xJG9X-00067K-5s; Tue, 20 Oct 2026 20:09:43 +0000 Received: by outflank-mailman (input) for mailman id 1456423; Tue, 20 Oct 2026 20:09:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJG9V-00066k-Rq for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:09:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJG9U-005ZVS-9r for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:09:40 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7ca66-2eae-0a2a0a5409dd-0a2a450781d8-40 for ; Tue, 20 Oct 2026 22:09:40 +0200 Received: from [209.85.221.177] (helo=mail-vk1-f177.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7ca83-b4ea-0a2a45070019-d155ddb1bd29-3 for ; Tue, 20 Oct 2026 22:09:40 +0200 Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-5eadf48fb2dso342404e0c.1 for ; Tue, 20 Oct 2026 13:09:39 -0700 (PDT) Received: from gmail.com (111.46.245.35.bc.googleusercontent.com. [35.245.46.111]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5eae981d239sm558143e0c.14.2026.10.20.13.09.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2026 13:09: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:MIME-Version:Subject:References:In-Reply-To:Message-ID:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792526979; x=1793131779; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=a/FHpmQozRyX6PRPz0UuyxMFmwgJ5gMZhHW6lZCR6ao=; b=Ld63QP+wpVX3p6wu7jJgh6l5DU8PF/HGrKdVjwBsMIjMk/IEHRkFEL1RwJ2H9xtIdh hdrHYWyZBRCcCcwoIuSOpiALmlMNnNbTM/nOug78c642ckA1uRKz2+fpUIhsqna9/aq4 9+/4ZPNeQ4d4yNsDCpkP8y3Ex/gtdmYT5PmQyQXIMXRHX4jq91UBzJpp9hQphM7YI03c mNPARTu9yhSjzK5ut2i/W2DNDpxJSSQ53/2Ng0fsYbNWHSS99GUd/g314VUcSb2o/xBj HvG2IjVIelMx4VFx3uGlVzB4Rmb2V+k6Y6W/CnmLCccaKyziDi6FViItY+TftP9Eb44C wpLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792526979; x=1793131779; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=a/FHpmQozRyX6PRPz0UuyxMFmwgJ5gMZhHW6lZCR6ao=; b=Ps/SD5I1koKC+7kcNwBJK1jK+QmfwvUqlEHJw1Lzm5IVjbz+kxJeyiNtOOwxnIQmB7 7XNI0w24LUwUOKgHzYBUGuWbbVCPk11P6+TmOXcYxyDqOr3Wz1k/gK7y+bVomCrsIwm1 cJKtPWpEW4wwkrIAUqqhftURf5K+EyMpq+EtZ1il73h5dCOwRN6atJ4qNF+zU5Veft5J JbgkCYfwrX5YASxvmVb8Lg1/ynVeNQbXMZqCi0te+7+6F41HjLnzJ9bNc01nqT0djoCi vclvfotVrZGMTHZed5+Cg/1iT3IXHWMBcjRPzW+NSmrR5cZYzxqhqtX4qa1KPcTaLT64 xhvQ== X-Forwarded-Encrypted: i=1; AKwUvBzCefBG+he103LYwLQtg+BG5SLNeolZfGSjwIJOc18CQF71y9NVuqKnwEMybeykRF60P/uSfg1fES4=@lists.xenproject.org X-Gm-Message-State: AFq9FYIKn1uAnqmzrlsEIK+m07NYJekD7Rw3P0cqgENyGbNxfWqycg9i VDeMDluhPFVf9SRt1OkKJlhGVLtDFKgMt5s8kT1tA/zngGaaKocXrrEg X-Gm-Gg: AYBFou1kFkAbGUF4hNOIXuI1EobOIhEDXTbHk6Lu8i2t0uPNLaswXScIKMD2YySWKHw CE/9TqBjit7m8cQz+xD0Ov9/fRGjb1DDeBO4fQwnGwdFC/StmZJ4djlOmGhx5CEE5YiVJr31HYd OuIrMm1GWKCEVPsTh/0wI7hj90NaHm/flKctfLZc6sr5azM9D2Xb8SBRQk6TqWsvrJeSmLOvbD2 DQ8cItBqaRjEczvfk59Ce7mHVcGc33tSddAnjXW5zVaHhjQlj8TRs4ZbrQYkfEFqYU8VV7Jtbb/ tMelvEa+P/S0nb+0c5+mpl+slihr9niCg3N4L7IzIuBcDYCUjKNoxx7vt/WfJRvE1oXS5vOSeK1 WSWGeY0YL40JxQ4aY6acKlM+uVlghNTFAjqQPtK5pxv5kn/fiv61XsCrnPvmmAfgYvvMvfAC4Ll gdPOVdCGLJvMmj4roMWUUdETCtjauRwYw6hGkfgHgD/VnGAkgVFOObxIXOKmG0nHbF6bczMYvm3 n2K3ixTVsykyYSpGhp6Uq/8yAG8Pv1AnubjyM30IxHFUBbzPao7tTwxb1cLI/zAqrWpcZrkJBCu 1hejPTpqJBnvWj6QzWtsBIkY3vqZ80SbYwD+1w== X-Received: by 2002:a05:6122:8616:b0:5c9:a60b:e5c8 with SMTP id 71dfb90a1353d-5eaaa414a8bmr4189894e0c.11.1792526978625; Tue, 20 Oct 2026 13:09:38 -0700 (PDT) Date: Tue, 20 Oct 2026 16:09:37 -0400 From: Willem de Bruijn To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik Message-ID: In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-11-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-11-41dbef50b9f7@toxicpanda.com> Subject: Re: [PATCH net-next 11/15] net: skbuff: refuse to segment a nested frag_list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1792526980-37AD0AE4-C1C76924/0/0 X-purgate-type: clean X-purgate-size: 2825 Josef Bacik wrote: > skb_segment() walks head_skb's frag_list, but for each member it only > looks at the linear part and frags[], never at the member's own > frag_list. head_skb->len still counts those bytes, so with a nested > frag_list the walk runs out of members while it still owes data, sets > list_skb to NULL, and dereferences it on the next pass, before any of > the layout checks get a chance to catch it. > > Nothing in the tree is known to build such an skb; GRO flushes instead > of chaining an skb that already has a frag_list. Check for it up front > and fail the segmentation with -EINVAL, with a DEBUG_NET_WARN_ON_ONCE() > for debug kernels, like the other frag_list layout checks. > > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > net/core/skbuff.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 56cec58bccb7..b6ada54ecc57 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -4962,6 +4962,17 @@ struct sk_buff *skb_segment_list(struct sk_buff *skb, > } > EXPORT_SYMBOL_GPL(skb_segment_list); > > +/* skb_segment() only walks one level of frag_list. */ > +static bool skb_segment_nested_frag_list(const struct sk_buff *head_skb) > +{ > + const struct sk_buff *iter; > + > + skb_walk_frags(head_skb, iter) > + if (skb_has_frag_list(iter)) > + return true; We can probably check the same without adding an extra skb_walk_frags. Perhaps @@ -5025,6 +5025,12 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, while (pos < offset + len) { if (i >= nfrags) { + if (unlikely(!list_skb || skb_has_frag_list(list_skb))) { + DEBUG_NET_WARN_ON_ONCE(1); + err = -EINVAL; + goto err; + } + > + return false; > +} > + > /** > * skb_segment - Perform protocol segmentation on skb. > * @head_skb: buffer to segment > @@ -5023,6 +5034,16 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, > sg = !!(features & NETIF_F_SG); > csum = !!can_checksum_protocol(features, proto); > > + /* The walk below never looks inside a member's own frag_list, but > + * head_skb->len counts those bytes, so it would run out of members > + * and dereference a NULL list_skb. > + */ > + if (unlikely(list_skb && skb_segment_nested_frag_list(head_skb))) { > + DEBUG_NET_WARN_ON_ONCE(1); > + err = -EINVAL; > + goto err; > + } > + > if (sg && csum && !gso_by_frags) { > if (!max_segs && !(features & NETIF_F_GSO_PARTIAL)) { > struct sk_buff *iter; > > -- > 2.55.0 > From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:17:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:17:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456458.1669784 (Exim 4.92) (envelope-from ) id 1xJGHJ-0007rH-07; Tue, 20 Oct 2026 20:17:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456458.1669784; Tue, 20 Oct 2026 20: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 1xJGHI-0007rA-Tf; Tue, 20 Oct 2026 20:17:44 +0000 Received: by outflank-mailman (input) for mailman id 1456458; Tue, 20 Oct 2026 20:17:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJGHG-0007qH-MX for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:17:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJGHG-005aWb-3R for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:17:42 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7cc3a-bab6-0a2a0a5309dd-0a2a4506cf1a-40 for ; Tue, 20 Oct 2026 22:17:42 +0200 Received: from [209.85.221.169] (helo=mail-vk1-f169.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7cc65-195a-0a2a45060019-d155dda9c895-3 for ; Tue, 20 Oct 2026 22:17:41 +0200 Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-5eac48af23fso1028024e0c.2 for ; Tue, 20 Oct 2026 13:17:41 -0700 (PDT) Received: from gmail.com (111.46.245.35.bc.googleusercontent.com. [35.245.46.111]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-990d0e116a5sm838405241.2.2026.10.20.13.17.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2026 13:17: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:MIME-Version:Subject:References:In-Reply-To:Message-ID:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792527460; x=1793132260; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=87SiGqQk09gjnLOfFzKbGj+YDTzrcqCWleu/6jAMDYE=; b=U6RN83HUiW1WXt2Z/ydka8evlHTcc7iEMD2Y04mQ53/Uqox5hg4rJxc3Ewf4gCoef6 Qiklm48tr6npHYT6fRneZWp2MC/J/sMBb0hDTfggmrUe7fPnJZbA2x8xy9bm7iRUzoNV Y/5YBAAWE1W/yO5JFzGgfiTnpPGgqBNHmVWb14iFWJsWSDob49w6OHQ0dCj9uzqSVmFR m4jYz2QDfxdnxTxf3B9IAMyWZGUR1uxuXW+vYH/WWkCImCz7N1ARAf9n868SWfNgfMXC hEbc2rEt0D9Qv2V/lP7GNO/nG2jFfAzFbd6OcwWIk1vPsimFpRdEtrOOjINfYXOYF2Ri 1B/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792527460; x=1793132260; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=87SiGqQk09gjnLOfFzKbGj+YDTzrcqCWleu/6jAMDYE=; b=vjoy08o3y0gKL7DIzsQbKgNIvtoiHxcpnjZJJ6ZAAaIPHrjP+O7ncs+4ZuCTsyM49Y pGvFbqAnmebSnoNHKQUf0MS50VBZMDdd10Px8LCPlXCrBUpR+MOIcW22hwjwblkJwmDW Qrx1Z2fSMSM84ooSv2QXLYZIWM8YrT5ntAwxvXOILeId+N6s40nmRlMb/eD2t8c1eXAW uSCkpgJqNXaszS7ae6WJW/jFKkdkJOnwpa4pgdvYSKpmamlWJWg/F4FKrjYIMEiGoteB ygb2TSNfoXmm3qcA/tAEu4db8cl4wuB8TAmF/mW0HZz38sJ5GW4UBXaljvATKzexCxbd XXaQ== X-Forwarded-Encrypted: i=1; AKwUvBxH9RpFDQftCmXrGwPIWIqTy/BSCtmFqC02X7jT0wH3v/U1gjKMXfUmnZIpetVRq0zmcyz0pB78B9Q=@lists.xenproject.org X-Gm-Message-State: AFq9FYJIs5pjW/7PH6qFPHI5b7Qegg5vnjvpd2rGZsph/G0eCxuz4CL6 5TJI4s6hle0AoKUFdRiKQsWPBxATzyBXHFp68Q9a8nRKUO2gWEGvUfBF X-Gm-Gg: AYBFou2KL33MbR/imd3IADif2h/ZrzypwHQHrzpAD9OgC7QVLekycYbebPMoz8uhOfV 0xly0uREQ8b6EmmFGNRgHS64cJq71qGvzTSJpW7W1wjvIiosADx6jgP9X71hvfJM0GeyH+qBHMe DocxNMFvJcdLNyfy0bg5O2mqgMB4IXX1szNsRwvFiPyv+dz4gWzjWOWHhsslZ8cVUFDMR33d4Pn ntBRv6g7uFqFcmr5Nh68wH8GV04tO+ONuXDxc7ALUdh3BWgZyyiESv2JGlFlAo+LENLhSN5ddjU RlFw9Ps6MTtTEboDpl+j5IPZ4SAFd+P/0rku73UTUA6KxPkqwFlQiGQdjmieIGCB9TCs1FbRbin /TUI14H0fCwPHCANLA+OyKeiZRQC4r2RwpZVYKTCVk0YMyLNny87gwi7OO3/OtQsDKPjPOn0mwq gKfrJIXILUDqoBWUxAqQmjC42X/vg/IX/E8OaLbzLKYzqaXELyXB4uZxshj7irokmfn96BOJeex cyblVSl7Zt66p0kvWU/PmoaKvb/f96qu9cFanlaRnN6av4LdmUl3T1hD0cAWuePaoga1rnhjGg5 kUiqApPe99LMpP6Qkv70yw5NWjCtRD41eLbOYQ== X-Received: by 2002:a05:6102:4485:b0:7b3:4199:2dd7 with SMTP id ada2fe7eead31-7cc92256068mr130816137.0.1792527460493; Tue, 20 Oct 2026 13:17:40 -0700 (PDT) Date: Tue, 20 Oct 2026 16:17:39 -0400 From: Willem de Bruijn To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik Message-ID: In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-12-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-12-41dbef50b9f7@toxicpanda.com> Subject: Re: [PATCH net-next 12/15] net: test the frag_list layouts skb_segment() refuses MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1792527462-FEA7477B-F305DFDA/0/0 X-purgate-type: clean X-purgate-size: 3531 Josef Bacik wrote: > The GSO KUnit test only checks layouts skb_segment() can segment. Add > two it has to refuse with -EINVAL: the non-uniform frag_list with SG > on, which used to hit the BUG_ON(i >= nfrags) the existing test steps > around, and a frag_list member that has its own frag_list. > > Both warn on CONFIG_DEBUG_NET kernels, so run them with the warning > backtrace suppressed. > > Assisted-by: LLM > Signed-off-by: Josef Bacik Reviewed-by: Willem de Bruijn Thanks! > --- > net/core/net_test.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > diff --git a/net/core/net_test.c b/net/core/net_test.c > index bc2ef7612e7d..12a175268a01 100644 > --- a/net/core/net_test.c > +++ b/net/core/net_test.c > @@ -39,6 +39,8 @@ enum gso_test_nr { > GSO_TEST_RESEGMENT_MULTI, > GSO_TEST_RESEGMENT_TAIL, > GSO_TEST_RESEGMENT_ONE_MSS, > + GSO_TEST_FRAG_LIST_NON_UNIFORM_SG, > + GSO_TEST_FRAG_LIST_NESTED, > }; > > struct gso_test_case { > @@ -57,6 +59,9 @@ struct gso_test_case { > unsigned int nr_segs; > const unsigned int *segs; > const unsigned int *gso_segs; > + > + /* skb_segment() is expected to fail with this error */ > + int err; > }; > > static struct gso_test_case cases[] = { > @@ -204,6 +209,28 @@ static struct gso_test_case cases[] = { > }, > .gso_segs = (const unsigned int[]) { 0, 0, 0, 0 }, > }, > + { > + /* frag_list members that don't end on gso_size boundaries > + * can't be segmented with SG > + */ > + .id = GSO_TEST_FRAG_LIST_NON_UNIFORM_SG, > + .name = "frag_list_non_uniform_sg", > + .linear_len = GSO_TEST_SIZE, > + .nr_frag_skbs = 4, > + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, 1, GSO_TEST_SIZE, 2 }, > + .err = -EINVAL, > + }, > + { > + /* the second frag_list member hangs off the first one's > + * frag_list instead of off the head's > + */ > + .id = GSO_TEST_FRAG_LIST_NESTED, > + .name = "frag_list_nested", > + .linear_len = GSO_TEST_SIZE, > + .nr_frag_skbs = 2, > + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE }, > + .err = -EINVAL, > + }, > }; > > static void gso_test_case_to_desc(struct gso_test_case *t, char *desc) > @@ -283,6 +310,15 @@ static void gso_test_func(struct kunit *test) > > if (tcase->id == GSO_TEST_GSO_BY_FRAGS) > skb_shinfo(skb)->gso_size = GSO_BY_FRAGS; > + > + if (tcase->id == GSO_TEST_FRAG_LIST_NESTED) { > + struct sk_buff *first = skb_shinfo(skb)->frag_list; > + > + skb_shinfo(first)->frag_list = first->next; > + first->next = NULL; > + first->len += tcase->frag_skbs[1]; > + first->data_len += tcase->frag_skbs[1]; > + } > } > > features = NETIF_F_SG | NETIF_F_HW_CSUM; > @@ -296,6 +332,18 @@ static void gso_test_func(struct kunit *test) > features &= ~NETIF_F_SG; > > SKB_GSO_CB(skb)->max_segs = tcase->max_segs; > + > + if (tcase->err) { > + /* the suppression block doesn't run if it can't be set up */ > + segs = NULL; > + kunit_warning_suppress(test) > + segs = skb_segment(skb, features); nit: if respinning, add braces > + KUNIT_EXPECT_EQ(test, PTR_ERR_OR_ZERO(segs), tcase->err); > + if (!IS_ERR_OR_NULL(segs)) > + kfree_skb_list(segs); > + goto free_gso_skb; > + } > + > segs = skb_segment(skb, features); > if (IS_ERR(segs)) { > KUNIT_FAIL(test, "segs error %pe", segs); > > -- > 2.55.0 > From xen-devel-bounces@lists.xenproject.org Tue Oct 20 20:40:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 20:40:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456499.1669793 (Exim 4.92) (envelope-from ) id 1xJGcw-0003dN-Q8; Tue, 20 Oct 2026 20:40:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456499.1669793; Tue, 20 Oct 2026 20:40: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 1xJGcw-0003dF-NE; Tue, 20 Oct 2026 20:40:06 +0000 Received: by outflank-mailman (input) for mailman id 1456499; Tue, 20 Oct 2026 20:40:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJGcw-0003XU-56 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:40:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJGcv-00GSue-II for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:40:05 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7d19a-bab6-0a2a0a5309dd-0a2a4503c3ca-4 for ; Tue, 20 Oct 2026 22:40:00 +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 6ad7d19f-fae8-0a2a45030019-aceafc1fcbec-3 for ; Tue, 20 Oct 2026 22:40:00 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 92A8F415FC; Tue, 20 Oct 2026 20:39:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59B7E1F000CC; Tue, 20 Oct 2026 20:39: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=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=1792528798; bh=53M2qSXMc7SnZSiMV+QqkK+Sw+wyCmkqw7MJ0K3TR8c=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PaKDTjMRAsn6NTNMMK9pjPi1pes1zSuYpw3UZvsxXnJNYkUej4Tk3Pq8ieQm9Pwns kdzGLH5KPXi+A0YIi4k3BbctSqjQ1+1KPpL6n2lihz5c7mSaC1naP9r6lF0aPRJUzf LtItny56GQReMk+8w8QdIYUWdl1kHsqKqcWqZxnU9xKHFG/xwIfZnIYAVd8bcduLpn aym1C02Ls81IhN6OhoACuds2h2OfquqaHx6CD4ouWoR99Ct2c2iBjYVG5Qrw9PCuWV 5q4KCZip0vifSexb02b7FRP4SZ3lCeiSI30cf9qZx9o8f97R/M6/KdslPGoNJ5YMtu C63LNBjvu8Lig== Date: Tue, 20 Oct 2026 13:39:53 -0700 (PDT) From: Stefano Stabellini To: Michal Orzel cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH] xen/arm: validate max grant frames against the grant table region In-Reply-To: <20261019145726.648111-1-michal.orzel@amd.com> Message-ID: <727cd372-04c2-0df1-3758-3c86c9673642@kernel.org> References: <20261019145726.648111-1-michal.orzel@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-purgate-ID: tlsNG-33051d/1792528800-6DAD44E9-EF3F89DA/0/0 X-purgate-type: clean X-purgate-size: 1478 On Mon, 19 Oct 2026, Michal Orzel wrote: > Per the binding (docs/misc/arm/device-tree/guest.txt), region 0 for > mapping grant table is large enough to map the whole grant table. Xen > never checks that this holds: > - enhanced dom0less domUs are given GUEST_GNTTAB_SIZE (4096 frames), > while their limit comes from the max_grant_frames DT property or, if > absent, from the gnttab_max_frames command line option or default, > neither of which is bounded by the region size, > - a dom0less hardware domain is given gnttab_dom0_frames() frames, > while the max_grant_frames DT property can raise its limit above > that. > > A guest growing its grant table past the end of the region ends up > mapping grant frames over whatever follows it in its address space, > e.g. the magic pages at GUEST_MAGIC_BASE for a domU. > > Validate that the configured max frames can actually fit in the region > Xen exposes in make_hypervisor_node(). > > Fix find_gnttab_region() logic of setting the gnttab_size for hardware > domain to allow the max frames up until the size of the text section. > Otherwise, the DT setting would only allow to shrink it from the > default. > > Fixes: 79eb2871f25e ("xen/arm: configure dom0less domain for enabling xenstore after boot") > Fixes: df68a4cb7ed9 ("xen/arm: Add capabilities to dom0less") > Signed-off-by: Michal Orzel Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Tue Oct 20 21:33:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 21:33:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456552.1669805 (Exim 4.92) (envelope-from ) id 1xJHSd-0002Gs-NS; Tue, 20 Oct 2026 21:33:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456552.1669805; Tue, 20 Oct 2026 21:33: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 1xJHSd-0002Gl-KQ; Tue, 20 Oct 2026 21:33:31 +0000 Received: by outflank-mailman (input) for mailman id 1456552; Tue, 20 Oct 2026 21:33:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJHSc-0002Gf-0k for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 21:33:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJHSb-005hVM-4S for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 23:33:29 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7ddbb-e002-0a2a0a5209dd-0a2a4505c05e-46 for ; Tue, 20 Oct 2026 23:33:28 +0200 Received: from [52.101.57.4] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7de27-4cb1-0a2a45050019-34653904971e-3 for ; Tue, 20 Oct 2026 23:33:28 +0200 Received: from CH0PR03CA0276.namprd03.prod.outlook.com (2603:10b6:610:e6::11) by CH3PR12MB7523.namprd12.prod.outlook.com (2603:10b6:610:148::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 21:33:24 +0000 Received: from CH01EPF000BE945.namprd02.prod.outlook.com (2603:10b6:610:e6:cafe::5d) by CH0PR03CA0276.outlook.office365.com (2603:10b6:610:e6::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.20 via Frontend Transport; Tue, 20 Oct 2026 21:33:24 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH01EPF000BE945.mail.protection.outlook.com (10.167.244.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 21:33:24 +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.53; Tue, 20 Oct 2026 16:33:24 -0500 Received: from amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 16:33: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=X3QCgAMpPQUIqx3CKVoR/1xEbntiUU+97w7Fi19SVtw3IdcmS22p1W+UTdltIkYv2Pc/2OUpq/GDrQYDMRgRztvJqQNlckTQoLmdeDxz6V1+L2bpwoMMhvp7l/zVVX35fhkKvL12WW2ysQ46hP6GvB0jqJBKqlMriCe4iM/xE6ozdmNQ2E0//EH6fmmuMkTrm5+PSpsPDxL+VxZyqsG+Ub47k2xgwyLD1/UaeesPLrVcRpL2rhQNLCYqnrYGEHRTy4i3OYC6zuSj9BrYORzdCLeLMSeD9/YnH1OFA0NBk355AonlTb04qIN0JkD4z9AUM42Q1hDgkF86a7LToMDqYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4mLmovPYFSQH+pk2lrvaukpqTjj7fDJAJGejPwRKTs4=; b=hv+4ZMP8KjSyfCbww+7tZMiUuKEA+6jEK+TUPXmBVccmv6MzvJvVVouVtafOal6y0hHb3Gko89DElBZ7Hg04Tnq826ohkxADPixq0iN2dC1h0LymXw/sOWa31nGt3fhKZK3ygGeeCb+QLbcFw6sOXEisiG2cOj/+HTTyNq3UAj6JYXK6SqH50MK7DB4QmC6cYLSea7//uiVHgTqejy009W1/g4OGSVW8vNWijgi9ybaDeGZonRb07YA0Yz4rw1SDU+JanskXEl/+nHzvvXUIrhBfmfNuMH/LLKF9GyDxprSFAII+3tRudLBLFoNp3AP3hczSucj/mXeVN5nIACh2iA== 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=4mLmovPYFSQH+pk2lrvaukpqTjj7fDJAJGejPwRKTs4=; b=on0KDxh20XdmlxYpFme69MYy5NuVBLfcalxNSVEUZtbBpBbBXVqqWQNc+T7ej0+3k/WxaHY1Yu/K6gbFOuIUCMVc0hWDrfYd1pXlL5KsgNNR/XUg74G2o3r/kG85TY1ZMu+pvYsndnpIfvMmJd3IX+NqaQWriNAYhrxDog9vDoc= 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 From: Stefano Stabellini To: CC: , , , , , Subject: [PATCH] xen/x86/hvm: Propagate emulated CR2 writes to the VMCB Date: Tue, 20 Oct 2026 14:33:15 -0700 Message-ID: <20261020213315.3641133-1-stefano.stabellini@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: CH01EPF000BE945:EE_|CH3PR12MB7523:EE_ X-MS-Office365-Filtering-Correlation-Id: 5ebdd492-458c-4f93-69a5-08df2ef1c575 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|82310400026|1800799024|376014|10067099003|18002099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: ulKqh5J86RKXsGSRXlHzrUCptnSN/cDumwinnhASOkvBcXr5oPKDeuyfSHPPF0TU/tDRTaXFBvSPq9a0aHcLqOuYaKG/bUVhfj5IHBqtNRVjD5GUgeyHodhP2+eFeXG6pACr/glfsrDG4PunEz6re2Dl/BT/Pk59RZQ4dXEdP6pyPjzSfqIqF4W1FwKjiqhPAY7YAWda1wLIDa/pAmkFmO3yxIsoXvROIlScL3g0pEEsNdFU4/SWhLHo1BApbsZg44Ow0ujmWQYPTfWDGr7bw6k+iBfaZFZDYzV8b1xJ8Bmws6p/C7v4kRFQTh5a24dIKCgxdC3DZZpnQy1sMJ9JBSu9lSglRnMAKP8ehYewNP6wOZKTm5oKerFiPHC1gwR2rbfVGX5KuuMJ/6vDc0VUmR4FJ/eA35y7FPxkWub90c6QEuV0EmcR7UCcMIVNRmAR5D5UJBD5DcgVjmXGRlffHc0UXOaLUgrXWEEz+xLOLiwCK3RvD5wlZdEQsuj8eLxDIWVxaCGVyZfiK8zYHnifl0JPjgU7TWSfErbuf13CIi6usCd3UF6YaU0cVZyGHn7kbCAuvJPVkGCjXepEOjNyhj0EzQKoBWqMtojiieAzjKK2Nll2ZTqupt1RMokB/YexxADLK7T4aDQdm4+RWrEloDUHClS/glF1RT+uCa43fckuL853v5sc4AbleAPrO26USmVaLRaVzKtBy0LjE/g98g== 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)(10067099003)(18002099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: b+ry1AOAK0ZCXUEdzHgGQ1tG1ub9I5KxWHEKYBWI+K70fGCMpaE0Cbve3GyD+zbt0uZKRRdMvtjO1EWu5Be3OeXd2Mf1bBP0ilt5x+dSge7BJRG2UPykyC/0irrdVDSXu+z6U2u2fPFyHskSIjCMYA6n0M44mQDkDwkkMi+tV1LWiXXsSm1L7cY9P01FuoRki9yyuXSXCgRqXnjIWEy2eG/vqAarYthM8iZUbWryKAYU+7TWfA9J61DmPyh34cyUgrU/88AI+ULBbpJMTipvbzcyilunns/BUdlN7MGB6AkoZ9qFkgcM3SzjGR1/bFHlszsycH0fXGtLVNwvrz5h9reHZlF+e+rPmlGZnfB6SAJxfL5lt7muDe7T3PydXJKmmd9s5lLXNVGib8y+7CJt3pUNDjEj99D48iPNOg+NmP6hBRA3g44LbXgKF5XzGsXn X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 21:33:24.4145 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5ebdd492-458c-4f93-69a5-08df2ef1c575 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: CH01EPF000BE945.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7523 X-purgate-ID: tlsNG-c201ff/1792532008-720AA2A1-93755F36/0/0 X-purgate-type: clean X-purgate-size: 813 hvmemul_write_cr() updates guest_cr[2] but, unlike every other writer of it, doesn't call hvm_update_guest_cr(). On SVM, CR2 is loaded from the VMCB, so the emulated write never reaches the guest, and the next VMExit overwrites guest_cr[2] with the stale VMCB value. Signed-off-by: Stefano Stabellini --- xen/arch/x86/hvm/emulate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index c09ea002ec..cd2831d34b 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -2350,6 +2350,7 @@ static int cf_check hvmemul_write_cr( case 2: curr->arch.hvm.guest_cr[2] = val; + hvm_update_guest_cr(curr, 2); rc = X86EMUL_OKAY; break; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 21:48:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 21:48:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456563.1669814 (Exim 4.92) (envelope-from ) id 1xJHhC-0004FF-2L; Tue, 20 Oct 2026 21:48:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456563.1669814; Tue, 20 Oct 2026 21:48: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 1xJHhB-0004F8-Vz; Tue, 20 Oct 2026 21:48:33 +0000 Received: by outflank-mailman (input) for mailman id 1456563; Tue, 20 Oct 2026 21:48:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJHhA-0004EF-FU for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 21:48:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJHh9-006GiV-Sb for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 23:48:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7e159-e002-0a2a0a5209dd-0a2a4508b7c8-28 for ; Tue, 20 Oct 2026 23:48:31 +0200 Received: from [40.93.201.43] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7e1ae-f659-0a2a45080019-285dc92bc0e3-3 for ; Tue, 20 Oct 2026 23:48:31 +0200 Received: from CH2PR18CA0023.namprd18.prod.outlook.com (2603:10b6:610:4f::33) by DS7PR12MB9044.namprd12.prod.outlook.com (2603:10b6:8:e3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 21:48:27 +0000 Received: from CH2PEPF00000141.namprd02.prod.outlook.com (2603:10b6:610:4f:cafe::8b) by CH2PR18CA0023.outlook.office365.com (2603:10b6:610:4f::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.20 via Frontend Transport; Tue, 20 Oct 2026 21:48:27 +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.546.15 via Frontend Transport; Tue, 20 Oct 2026 21:48:27 +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.53; Tue, 20 Oct 2026 16:48:26 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 16:48: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=woNk6nEOSMDBxgreeVSUbDBT6U5cMRFcAYdG30X3x2kU2Rie04LjaIlaksjXLslR75HGfSH2VEGo4We/zc0WmWwCrk+XHaOZXkq7k3YUGQLYG7gTYkb8PHVfOCpZux7uWJpVN7Cyq83jURuMN/eLZngixdfxb2KvB2UyBiM9eRJpokoY4Oka8OhW3XLU5OFB2JilIiCwVKJiU9EZlb5DFWHC6r/2YVebjVsbI5xsWpKP6Lj9IOW4ofJOZ58e2Ck2oPDTTXNFdSHaSVSrnFZ8B9U+jICuwKXZeQK/gLrLCIejGQ0lMFGJIwYlt81ZkAMvnniDRyqa/bp9PvQVP/JggA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lWfJxBnbFCN8jfpoKTdBHh0yaVi1TS/lq8L8UsyMq8I=; b=tBiQNkRauRQ18m5Vy68JVtcpXMUgyI2eHPH6LQMNl5GFhyOid62znwwn8x4GP+qRckE3Jlz7zB5xLU1CfXHyrzxOFTlyTcOnVEXlw6wpJIBPV+b2H59V4Q069X80FrBrXPgjcFU7he1aLeC/iwDgH5WKLqkgdquEMv5dOPDe6u7A/HBkUjkVjlHoHOKtU5D+aNSJk1HHgzk8fI0b8NDmqDaymZBHGp8i8oxz6emFqM3ngd7fFbfO1v8Rm+FQBb5Hukx/Uiao7NewSoKrrxM53/67oweyS45L6kOSlp9N+QfbXNiywpsEWmzYAfAlkRJHg5AO54dWcbmstAtip1Mgjw== 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=lWfJxBnbFCN8jfpoKTdBHh0yaVi1TS/lq8L8UsyMq8I=; b=GOkVarQ8qMt1/dzOAyeTX274Fqg01I+NHo0umJ8RGn4Wo4zCIg5eG3DzFlGFVzMto9nt5PIY9RYwavyn2fLkTr43vt6aVfCEK/ahmvML0pHENjHNB25BUb+9EQktIK/fOitgeD7zy6RVkemNyDm3Sz+7G4611CCUREaNwo8SytU= 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 From: Stefano Stabellini To: CC: , , , , , Subject: [PATCH] x86/bzimage: Check that the payload lies within the image Date: Tue, 20 Oct 2026 14:48:25 -0700 Message-ID: <20261020214825.3655848-1-stefano.stabellini@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: CH2PEPF00000141:EE_|DS7PR12MB9044:EE_ X-MS-Office365-Filtering-Correlation-Id: f9700f1f-bd03-4a33-f501-08df2ef3df7a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|1800799024|82310400026|376014|10067099003|18002099003|3023799007|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: CPEf6+iGsWR3BXSg6i+XbjvdI1UKh/Hyk2gLUjTSchbSh29y9/bxwW8uJXuoelE/VJa2yP1LGmQd/G0p32X3B6vHkH9sN01HUsdOvJh15QdYmLzz3iM7HpDmBbq+1AzgnJLWUd1vlvdrqqB90hoMOHoJR61HyLZ9Q9pibMVHby298i62QEBZka6l36TVDIHIAKdhlpYmBvn2Ar42+gvuXU3wHS+ZpQdQ7PseyT78kNqaH6KeQWLDtg/Ukj+gbpCX+fmbmC7C+l38g9a1hp+1bFb60DBWEL123sxiDz4136oCYmk/7ULt7WtkfBtCr1JfHhriTc+AV8Jo/NvrJHvC4cTUcdZmlh8yyJwTxPAyy2o3y5WQrroMIYNog46PgPF15bzBpcJuR/gJlhqJyW7s/Mqnjhq8VHL4rNSvOP10QZkG2f9uZcLIAY1aZALIq4c5FtbEfu1ov3wf4lq/xS8MZT4vvFWUVuh9hWCyVAmDPQOdIK1QFM+Qr+WHjOqrNc+3NjVWUW4ID+x43CujRPLEGoMIChmAzecKrPnQjr7yYmtT7Aix6T6k6KNJjujlFR3MDJG/faQDcMUlTezswyha3669mPHWwrsDywv3gU6DqKtCUaBYz/Pcm93yEFosPtjcbiyvqKSEnUnasY45qCIY/ufFaAZtOyim1tCCU3uEGwwnVwRIuBRBU/NT42EAALSU8BEAIw3z2sNgFzf4fEFPPA== 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)(36860700016)(1800799024)(82310400026)(376014)(10067099003)(18002099003)(3023799007)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 0YQm5kYnI7fT9uhNNiX70N3BJJ4N2dY7OsyMe0uj/wJ6be8R+VX096d6joEH84WmUEwOMVK01zLUfPnUFQnaXz3Pq3NBy87IOSLwVbK16qs6sNUlfm1vUlRSNtwZrfwa7XApJr6D1Nk++yPe7COSEZm+9M3NhCflNeRnW9A92qfvqIlR531ibmcazHbO/kDAjmQjCckKzogQ2RpnhTA8qzSQl237s8uJZSluKPCk9oSp3nYRgw5qpmmsZAMADfnrRYMGmBJ3zGLIrIsLpNHhylCICe/AFKnTstlP/TefG7cZoYWuxaBPPqKs6SZFAu6vjaCjFlQMTdmyOlrPy+BoMknz/WWnfaSyGKF0d6XlxQ5MMN2V/e37QvCeZnQP4YPO80iu9Wf0Y78VE4oEutyZpijeBlC8QOKvcUtlFe4v2RIkJG3P2yF+YoBQL+xRcv64 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 21:48:27.0877 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f9700f1f-bd03-4a33-f501-08df2ef3df7a 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: DS7PR12MB9044 X-purgate-ID: tlsNG-c1860d/1792532911-CDB4987B-C8CBFB17/0/0 X-purgate-type: clean X-purgate-size: 2144 bzimage_check() doesn't validate setup_sects, payload_offset or payload_length against the image size. A truncated or malformed bzImage therefore makes bzimage_headroom() and bzimage_parse() read beyond the end of the boot module, which shows up as a fatal page fault, a bogus headroom, or a decompression failure, rather than as a bad image. Reject such a header up front. bzimage_parse() passes bzimage_check() a length which includes the decompression headroom in front of the image, so subtract it to check against the image alone. Signed-off-by: Stefano Stabellini --- xen/arch/x86/bzimage.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c index 66f648f311..a5c48755b6 100644 --- a/xen/arch/x86/bzimage.c +++ b/xen/arch/x86/bzimage.c @@ -54,6 +54,8 @@ struct __packed setup_header { static __init int bzimage_check(struct setup_header *hdr, unsigned long len) { + unsigned long payload_start; + if ( len < sizeof(struct setup_header) ) return 0; @@ -65,6 +67,15 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) hdr->version >> 8, hdr->version & 0xff); return -EINVAL; } + + payload_start = (hdr->setup_sects + 1) * 512UL + hdr->payload_offset; + if ( payload_start > len || hdr->payload_length > len - payload_start ) + { + printk("bzImage payload %#x@%#lx exceeds the %#lx byte image\n", + hdr->payload_length, payload_start, len); + return -EINVAL; + } + return 1; } @@ -107,7 +118,8 @@ int __init bzimage_parse(void *image_base, void **image_start, unsigned long *image_len) { struct setup_header *hdr = (struct setup_header *)(*image_start); - int err = bzimage_check(hdr, *image_len); + /* *image_len also counts the headroom ahead of *image_start. */ + int err = bzimage_check(hdr, *image_len - (*image_start - image_base)); unsigned long output_len; if ( err < 0 ) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 22:00:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 22:00:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456576.1669824 (Exim 4.92) (envelope-from ) id 1xJHsD-00060O-1B; Tue, 20 Oct 2026 21:59:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456576.1669824; Tue, 20 Oct 2026 21: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 1xJHsC-00060H-Tv; Tue, 20 Oct 2026 21:59:56 +0000 Received: by outflank-mailman (input) for mailman id 1456576; Tue, 20 Oct 2026 21:59:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJHsB-00060B-Id for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 21:59:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJHsA-001Oih-SY for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 23:59:54 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7e42e-e002-0a2a0a5209dd-0a2a4502ea8c-26 for ; Tue, 20 Oct 2026 23:59:54 +0200 Received: from [40.107.209.42] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7e458-6ca4-0a2a45020019-286bd12a29b3-4 for ; Tue, 20 Oct 2026 23:59:54 +0200 Received: from MW4PR02CA0002.namprd02.prod.outlook.com (2603:10b6:303:16d::10) by IA4PR12MB929686.namprd12.prod.outlook.com (2603:10b6:207:110::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 21:59:50 +0000 Received: from MW1PEPF0001888E.namprd03.prod.outlook.com (2603:10b6:303:16d:cafe::32) by MW4PR02CA0002.outlook.office365.com (2603:10b6:303:16d::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.20 via Frontend Transport; Tue, 20 Oct 2026 21:59:49 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MW1PEPF0001888E.mail.protection.outlook.com (10.167.249.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 21:59:49 +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.53; Tue, 20 Oct 2026 16:59:48 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 16:59: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=JOHTJZWoOFleh3mynl1hCguxR08Qujw+7U7MQfgxudtiaL7Kg1bOXwZjox0fuV2TUGAUuk/h7tMcPoQkC+EW8dCrbIIuc/1rGP19X5ZyPD9tmpPpfTjzoDQL7ZtDhxr+ottwepOLlPCSOOX3zAeTF+ELI7ur7EC0NcJD9QiqE/4A/pIWCy/sn3LfznelgXvWzlW3NYOD266u17f0Nsmaelt/rHGRQR4rnntA13PPoRnND/SL4LwIeR9f2tXLdB/jUe7tad6Z04o166MZ6IexsdJCn+3yQI4FcSoTEWwkhlJ24fW5r4VzvqSDjm0M2GIaqLKoWrE7W7GIwIHiDF4WGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9FhfR7bu914GJu8wPNMWnXkcHIbDHzzuoXzcUtJH2wY=; b=e4v2emswJeFI+zt5693HdRiqQhYqPmvWYX3hgyZHBO6errtvPkKSx8CXULOv2uKuGSmVoVggrqgaX99G1VYmlZepKsLpY1++OqLZ7/gWYiRcH9KhFM2icd2i38nyK66q4ddx7AjHKwrTvjwh3OsZ0qJ4rqJ45HUG5COPmHeKkSCQr9XbxXYRpAL+5GtkhqGfzPlRttFzy0nEDsKtPBR/jaTR3tNQT5vOw78novCvfVOLMV07thK6Eq1m8NIT1nETH9BMm/o49VYXmBqA5F0Kf9/WCcAEHo5a1a+E54GORuoR1tGiZPi0fa1Xv94H+GAMiD/yTq8+XKjGzP2pOdZEuw== 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=9FhfR7bu914GJu8wPNMWnXkcHIbDHzzuoXzcUtJH2wY=; b=0L7oNkBPysZL2xiH5l0zUhX/iorWzvngUieCTFIJNCPtqRYV7mvhWu8pf51IFyP5hS5UQCVM0wadzbIFyf/vntEdBW4OuAJGXzQVicOrtFqlQAMglg/3ehTX9VlKOQRC7vR/w0RCQ3U31oSpv0NSeIZcbSKWKoPLE0U/sw8uras= 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 From: Stefano Stabellini To: CC: , , , , , Subject: [PATCH] xen/amd/iommu: Skip IO-APICs missing from the IVRS in shared IRT mode Date: Tue, 20 Oct 2026 14:59:41 -0700 Message-ID: <20261020215941.3667346-1-stefano.stabellini@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: MW1PEPF0001888E:EE_|IA4PR12MB929686:EE_ X-MS-Office365-Filtering-Correlation-Id: 66e1169d-9962-4899-4292-08df2ef57637 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|23010399003|36860700016|10067099003|18002099003|11063799006|260925021311599003|260925021911599003|260925022911599003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: qHdScHD8VJfCCNf/TBhq+lb6GX0lB52j8VJDx5e/U6XNSRj/4SnZGFoN9ZnznIhURlYHZmVmS/0+fknkRL2PQnei+Y1ElSHl0OfeTNWHkNQW7TSvadIR0TP/pZuYKkmxSVk49+v8uW92sgzSfCRlqmhlCkTRY4gXzbrsz/x97ZxEEO/f0QqGjFo+30w0+v2d3LV8IvCSy7hHrYQrd2gVQuzFV5xbUKNnrSrSN4C+kxtkhuPI9P4jXd78nbiJSHMntOKOaPAhYhVBgEcS3p1/pesLA/Zjyke8YV694RIpowb6OnUwNWU/8CNH+57BRnYcmsE4uQcsfEZPicoRHnyBdlpd/DEirFthxMrbR4g5KtrfrvnMq5a/vzhT1BVQkZMgcdjfP5I+tl98MlNMyRtpJyBdP5oMqTevG6ocw7We2LRbhCrVxwy6gbhlMAg2fkNcfTI/cZejpxm8Uf18MclISO+Fp7UQf53ylc4+v1UkAJZ25IcUpYZVCsQ4D7U0yJWLB8M37NykwmWguaZ/6gqwv79uUMxzVQjKwkHffmtIK9m6r4QUsJUMqAy9BgVNNXwILiL2kGki1gHIhPHj5uqAEZ1iv2iFR6O1NH4N98m8Z4zzxzkvVIgWLi6JIaL7e4Y11DfrsHrWQxax4dkGasGcHx2UPmivXyZHPusBEFn6oQyDAas6pkHvtSSiuQfgECtBTVsEa50et5YKIOtum/147g== 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)(1800799024)(376014)(23010399003)(36860700016)(10067099003)(18002099003)(11063799006)(260925021311599003)(260925021911599003)(260925022911599003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: /BDrYiChMd8znobSBqnrXUyMwtIPdyX16KQqxbeEYilpkdCiWjT9HNVb/epkL8PRz3vcd1HlrgYC7f4Lc/WO6qK5q5faTyPAn9zj0Hoh4hjmWp0NbQqt5a+3uwKmykFAV34pqQCi2puhakO2ne/BmzvcNwIIdIQkl+tzPiAcqWPDJn8D5a+Scpl3u8JFubWnlauaOwcxhJfy506OiFXzq1JZXzZ1IQsA3vF39gX8MbGytcaLJENUhMztl9rS71IWv1oeu+RgLOvZZ4YqXhOHmyhIpwu0ma1Yiaj5I/E6RlrmxUTuDoCvppRLkseI6ShcDX9ZZ1acjpJjDXuy/JSJtOj15fIT/o2xME4UsTqFKki13cEWQJH6NXANsNblZBv2BFEthR4C0/O+nJzgoeJowF/nwaJdGh1ER22eCr9F7CxkH6eoIWvtT9OfUz6NtnvW X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 21:59:49.3703 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 66e1169d-9962-4899-4292-08df2ef57637 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: MW1PEPF0001888E.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR12MB929686 X-purgate-ID: tlsNG-720697/1792533594-F22A92AC-9988601C/0/0 X-purgate-type: clean X-purgate-size: 1196 When an IO-APIC with entries isn't described by the IVRS, ioapic_id_to_index() returns MAX_IO_APICS. With per-device interrupt remapping tables this is fatal, but in shared mode parse_ivrs_table() only logs it and then uses MAX_IO_APICS as an index, reading and writing one past the end of ioapic_sbdf[]. Skip such an IO-APIC instead. It is left without interrupt remapping, which is what the rest of the code already assumes for an IO-APIC with no index. Signed-off-by: Stefano Stabellini --- xen/drivers/passthrough/amd/iommu_acpi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c index 39ae637959..4688908824 100644 --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -1132,6 +1132,7 @@ static int __init cf_check parse_ivrs_table(struct acpi_table_header *table) IO_APIC_ID(apic)); if ( amd_iommu_perdev_intremap ) return -ENXIO; + continue; } /* SB IO-APIC is always on this device in AMD systems. */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 22:08:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 22:08:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456585.1669832 (Exim 4.92) (envelope-from ) id 1xJI0X-0007m9-O5; Tue, 20 Oct 2026 22:08:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456585.1669832; Tue, 20 Oct 2026 22: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 1xJI0X-0007m2-LN; Tue, 20 Oct 2026 22:08:33 +0000 Received: by outflank-mailman (input) for mailman id 1456585; Tue, 20 Oct 2026 22:08:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJI0V-0007kO-Ee for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:08:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJI0U-003pUG-MT for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 00:08:30 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7e62a-8faa-0a2a0a5109dd-0a2a450ca2ac-24 for ; Wed, 21 Oct 2026 00:08:30 +0200 Received: from [52.101.48.53] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7e65c-f479-0a2a450c0019-34653035395a-3 for ; Wed, 21 Oct 2026 00:08:30 +0200 Received: from CH5P223CA0002.NAMP223.PROD.OUTLOOK.COM (2603:10b6:610:1f3::10) by MW6PR12MB8866.namprd12.prod.outlook.com (2603:10b6:303:24c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.14; Tue, 20 Oct 2026 22:08:26 +0000 Received: from BL6PEPF0006C3DA.namprd02.prod.outlook.com (2603:10b6:610:1f3:cafe::9a) by CH5P223CA0002.outlook.office365.com (2603:10b6:610:1f3::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 20 Oct 2026 22:08:25 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL6PEPF0006C3DA.mail.protection.outlook.com (10.167.249.228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 22:08:25 +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.53; Tue, 20 Oct 2026 17:08:25 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 17:08: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=xjjv2jLpxXhIcXeZtgGvESP5yoDQqTVBR6lRKUKAKR1cIY62FgX4C383A19qeB71Z5AUp8nO/excsTdzAYfkFDEUq0ElSW2O4NCITZKy79z80U6GJn2fkHCXA1mLzPa8oCLwVv0CDMQyf+PqJ3p9OvjdFL+YaJtPETQf6IAZ1IHABJXbCX6/8x+hRSh0FgxezbXjfGR1azf8mtLxffMDhBp6vQ+p8r4j3kMcI+cq9dvwAIsS3+s49uIPxwD6Vzedmtiecs8TZmEEBScDUH1DRLyhzbULKLpJu69n4ErzoTOQlNAUcelREL1j4MEQI2y2cvIeR/lgr/GdG+ol8NLSzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2XFgylyY5lCQI8u54Xl+Lijc4iEF4EWHbGduJ1YJbxQ=; b=sgnU4k5JRvTy8P3WFdqpQD287xZKP5bTEmkeVupyV/HyMfFQrCqIJewP2mKsRm9yPgVkR41+aYdh2XqKxwpD7o5sNjuispq3xIFEUaHdOlwodHz+o5iDASAp2il7G4wauzRVUHXtEAPAHCYuXtYZ0+J0qnHnVdfUr2it0AbYnUzljgCPE4S1WnhKHE81/o3aqTjWBfcZgl0tsW66H/LtGltJzDpK7GOnYTtNr8nWb5hQVFtb6BX/ZGKqWPqMK3TIzmT8yvDsV/pgKA00ZFyO2z9UwR8HF/CPs2nnkqCNZBkWQSDE/67EgeMtoLtJB+LdOuJ2YF5WYHn6utAfzdq7vQ== 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=2XFgylyY5lCQI8u54Xl+Lijc4iEF4EWHbGduJ1YJbxQ=; b=qx1I1AzdY7bc/rz7SNxl+9Kc4dilm5g4LpAkO9u5S4wHvTcMd3Ytx3izj0sxf3pDg2KLlvcc0wYuRbLs6o1CsTTkRfWp2Wvkyv0JMUlg1I2fM5HXnJJNXRTjKiBvMP6nCVDCGLAK0UTgV8w0gXrT6vLsRoSo3IZILAMfCAwl+qM= 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 From: Stefano Stabellini To: CC: , , , , , Subject: [PATCH] xen/amd/iommu: Don't swap the IVMD read and write permissions Date: Tue, 20 Oct 2026 15:08:21 -0700 Message-ID: <20261020220821.3681692-1-stefano.stabellini@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: BL6PEPF0006C3DA:EE_|MW6PR12MB8866:EE_ X-MS-Office365-Filtering-Correlation-Id: 8377a12a-3df2-410f-c799-08df2ef6a9bb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700016|23010399003|376014|10067099003|18002099003|11063799006|260925021911599003|260925022911599003|260925021311599003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: soDy8W2TGJjhGHX0GbPQ4jWHbNCBivqJHzmkZOz4MfzjpW7+2BSI9VfHTXeyyvZfwlikyljaLH5VN9XbpwKvXc50OzKj2qM/PXoJcnTp+yeB9tMCk/B0asVP4csGvze621RziNt4OXIQ7rfZg0FCWvWg0tb3dDfiiahvbgpPQqM+38ArMW4mCbGCghunjYxx9RRWdirng3Z22n2TG3qArT0d4l/3/DUPu42uATWYZUryPgSEcQvOgvoU5YbJups4fSOSpD4x0bh1EWr+mJQnVCZCsIO5OxhdUHpem/Q073dYh6OPimt/cp5WdOiPAfQGwsWCFOaDyT3ZI/FUQZkxEjfdN6KFD1KntuAyAkKogN/MFToWcDTgBKipN8QYyyvu448JC0nAq+C6zsBVuTW+olArhVSQ1ec+mDQGu5LirVr9V30ninKZ+PP7RAD319mmWw0M1bWHe4BagQvSIKT7H8APOPFrtDyBTrxTkILDTeKpeDhJFLPUvIHzvIbxvU/pVOL7Rxhi74KEjIG4U24mEL4KkMzzSdk+C/HfpM+6Wg8M0nvict8ZCFP4Wh4EBhM9te6n7SwVNj+gB7TZqUNpBgYXZnXA646s0qlXSd6+rM8CLQFnsh/JTeZqoOcacr86AyvaZAjB4WAfPYeKgb8fBJ4qkcSOqFIpEtO93Bo7YOQIoqUdAstwyRePgyfjaLw0AWzmMx5zB5Gi9avHsjLJKQ== 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)(1800799024)(36860700016)(23010399003)(376014)(10067099003)(18002099003)(11063799006)(260925021911599003)(260925022911599003)(260925021311599003)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: tFXu3mm5KhNeuTaf8wT2JEqKoEoCX6goSJ7YyLk+iDl9a9Dl8nzMnbpJM16lWz/WWSRfpERbLSJOKnwkjKfaTbUIS4UBgp/Hf5SVCIIWVqOjRBv/RKmJcI3XEoucdzEaNb9sS6r7d/zbU3rzj629vidZFzUP/YDaXhXKj+vTa4+Nn9/pE+ADlgPakCnkgNyNAtaidjjv5a9+saUOf01yl734FB5DI7m4hZJESR9bNMccsA+aNYYxRxVBXP6/JkZjFudZtbsSKk7B1ioyYrplmycWB5OffbM30E8uMjIL680XIDVOtXiEn7u4JO78+Qr43HqZ9RcFRpZOwEMQ3o+Z/cqqzfpzDt6zib9dtoCdoMYwKlSsnUBBKLkpzTr8t/tR+lyz3wJQnE/BDDAjr4d1tR1WSPhLwflwQnyXtxyNHIuoWqnZ3JsZlFEuTyCDI+RZ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 22:08:25.3938 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8377a12a-3df2-410f-c799-08df2ef6a9bb 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: BL6PEPF0006C3DA.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8866 X-purgate-ID: tlsNG-d25034/1792534110-76CDBA5B-12CFB247/0/0 X-purgate-type: clean X-purgate-size: 1209 Per the IVMD Flags definition, bit 1 is IR and bit 2 is IW, matching ACPI_IVMD_READ and ACPI_IVMD_WRITE. parse_ivmd_block() takes iw from the former and ir from the latter, so a unity range firmware declares read-only is mapped write-only, and vice versa. Ranges with both permissions, including Xen's own, are unaffected. Signed-off-by: Stefano Stabellini --- xen/drivers/passthrough/amd/iommu_acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c index 4688908824..fe3dee872c 100644 --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -414,8 +414,8 @@ static int __init parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block) exclusion = true; else if ( ivmd_block->header.flags & ACPI_IVMD_UNITY ) { - iw = ivmd_block->header.flags & ACPI_IVMD_READ; - ir = ivmd_block->header.flags & ACPI_IVMD_WRITE; + iw = ivmd_block->header.flags & ACPI_IVMD_WRITE; + ir = ivmd_block->header.flags & ACPI_IVMD_READ; } else { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 22:12:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 22:12:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456593.1669841 (Exim 4.92) (envelope-from ) id 1xJI4G-0000t3-A6; Tue, 20 Oct 2026 22:12:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456593.1669841; Tue, 20 Oct 2026 22:12: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 1xJI4G-0000sw-7J; Tue, 20 Oct 2026 22:12:24 +0000 Received: by outflank-mailman (input) for mailman id 1456593; Tue, 20 Oct 2026 22:12:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJI4F-0000sX-3T for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:12:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJI4E-001QVZ-6U for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 00:12:22 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7e727-2eae-0a2a0a5409dd-0a2a4507940e-40 for ; Wed, 21 Oct 2026 00:12:21 +0200 Received: from [40.107.209.48] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7e744-b4ea-0a2a45070019-286bd1309419-3 for ; Wed, 21 Oct 2026 00:12:21 +0200 Received: from BN1PR12CA0023.namprd12.prod.outlook.com (2603:10b6:408:e1::28) by CY3PR12MB9704.namprd12.prod.outlook.com (2603:10b6:930:102::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Tue, 20 Oct 2026 22:12:17 +0000 Received: from BN3PEPF0000B374.namprd21.prod.outlook.com (2603:10b6:408:e1:cafe::2a) by BN1PR12CA0023.outlook.office365.com (2603:10b6:408:e1::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.20 via Frontend Transport; Tue, 20 Oct 2026 22:12:17 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF0000B374.mail.protection.outlook.com (10.167.243.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.0 via Frontend Transport; Tue, 20 Oct 2026 22:12:17 +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.53; Tue, 20 Oct 2026 17:12:15 -0500 Received: from amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 17:12: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=ZzFbkAkyCGmYaaPHKdQFBfVfNy8FCAEHQyqSlPQKFkdK3JyUGBY/H3k8MuEmX65SgYjc8COBOhvPhtQ5jEfjsQky937AJoHhw8nAjT8E2Yz7PskU7pBNUMDxfb8fQwojvlegOh5lbFBeZ0W7XPPEYhUOSaFB+TcH78OLispUhGiAbZap0xPaxjvalRJg7qi4ndUeUb+y1Y9TNvUUaGGI5xhhDFihowmI0Nt5KwzCXqbr/whHK0v2TffiuxiM8poZ3+J6L07nylU8f6qozFLOys1eAEjFi9t/XRKtkk0ASZjU58LytW52JM1SvvXXYEk3a9sJN/Agcyv9/8lDFRlvdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0lTzeI14p4isnUJycPWW8/lofc2072mgt52wrZcl9+A=; b=Sf7OyMJ1olu/3LOF0Ai7oOeTd5TSFqKLE0VTBd4OfZaXBz5v5SgOFEYMql6vT8XAB6ol8OddhzQsZRBpN5BKjSf1q781/QQEndzjsXsdImqf+grKA8D1VJ5qWVC2U/eizpPN/d8y/N8nmMJSGjuMhiXYrsM4/uLybURkz2dcXgvZ42T21DiVrQKAURoDI8YztVdM724J8MX0yxujgq/XgrnTfG3/MuJv0CUZV6lJADVygHltV8S9s6uR3Jydv3EPIyTztOhPHdtlKBB0pgXgHY/kN0l9eGSf6d+8Mz3A9sOkkL/PkFlrGykDAxIz2SXBAgxBhoB5aYsej3SoqA6WRw== 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=0lTzeI14p4isnUJycPWW8/lofc2072mgt52wrZcl9+A=; b=smrl3qE2irLCyIhCKL/FSUDtCDohFD1AkirhLM1ccpA3n3+TGl7xqAw4dT8n/D8uOElzYp3Pg8l5qG8t+aa96EWbVMXsmfNoqA7sIij/R9DEkSg18UdP3a4Tm5xG6GlOgATbXp+TV/c/3kiNFtq/+PLkviIs6VcNTun8hRTFsBk= 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 From: Stefano Stabellini To: CC: , , , , , Subject: [PATCH] xen/amd/iommu: record the IOMMU for alias DeviceIDs Date: Tue, 20 Oct 2026 15:12:14 -0700 Message-ID: <20261020221214.3683476-1-stefano.stabellini@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: BN3PEPF0000B374:EE_|CY3PR12MB9704:EE_ X-MS-Office365-Filtering-Correlation-Id: 024ee4f3-debb-483d-a654-08df2ef73415 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|1800799024|23010399003|376014|261009223027099003|10067099003|56012099006|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: SYbk33rlha4P58K3luuxBC76Eo67eyp4SxmW734o6Kp+lszKVRA98tFHcf98SFhWSnbh9NRdPPD2AUVBW2Rtl/Ew2UNaw1TqfjR97dgZ1hTFtzNwdJ/xKgiF4VqsfR/EfOqhAOaqchOkI7teQmf0xVMnKpMapRb3dXHbiTjfdwN0rMlv9gONouJWiUMl+UcQFQ5bRlt2JDm0APUD1em7YuziiVBdrTAj3kJ0RRP6jiB3WqMz8RmrY8gTfBrhkv0+KO/ZEKlKIr5j6+enqb0AhTtvwSuqaY4K4gQ+0OLpanP8fJvhyu1quNGuNwn3VNCq39usIfjYkpFENicl/H4Xqwx/VDcrIHQ3/JJVTlEhmoqij4xeI2kFCH/CesPyUNE6gwLpnNZVTnkf//IeXe7PEsMeZmeAJNjAO359cEcLtiNa7vy9xpaCpwEA3nMaGr2x8vwa5Hfp4MxSRa7BJAtd8dXc2B/8vigV55iJM7+S9YW/l5vXVpce+ZRfQ4BiLPfkhivzAt+zxgKT2mVtbiWO+NdxZsMMtOjgjhzn5W6Mca28Wq0RNG0+oyR/nGvlIxlEPurt4jkh6Uxis0Ulg/OqOk8AEDDIo7R0NM0hXV3hdzwfAxVxd2y5rUOvqZXWBN5tzptXuMbGkLAgWdhLolVldHhvmicWXJyZtccZTAsCipDLyEkXnGtS5LV4icaYe8Ulw8RBlUUr2U446FRmZxG8yQ== 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)(82310400026)(1800799024)(23010399003)(376014)(261009223027099003)(10067099003)(56012099006)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 7Ej7rE/u1LomhCe1Na6HLyEVsSlpfbR7DAWYkvqql2AreWGunQk7tQyOIhCT+pjyJOriuFYsQ/T/kvf3oZF0Ce8FVxSs23twvxgbmx/zSdPxsKCeFYinVGcvhoTNOIhoToQBzixNfZdNn1mrLHgmUSe+nEJVh9XNoGq7dLC3ZL41/pj5VHXV7uqVULDbxuxHuYXLfCesqfH40tMN832BTYQaYI6KXG7uY7QUB6rhc1d5F6THE6IRhDcaaf8ATFmTd68doWkc3TnIWcFZWip7l4Cg5JfWlPbKg4DO1iFKbH9ASxScxBXE/E+Y3JXOPB78YWOjPRQzGZ244nrrccIqaBdUUo9wskaW6MnoVfZdbOa3Xm9eS6V7p5dR59cFBqdy+oUXsrqBR63t2Dj56qElkbShgRsx17xAOUl1cGRGhuNsg6ax+ZIldHaEsJ6UCywm X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 22:12:17.5104 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 024ee4f3-debb-483d-a654-08df2ef73415 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: BN3PEPF0000B374.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9704 X-purgate-ID: tlsNG-ef75cf/1792534341-A64DBAE4-E92BEDF2/0/0 X-purgate-type: clean X-purgate-size: 1094 add_ivrs_mapping_entry() marks an alias DeviceID valid and may give it an interrupt remapping table, but records the IOMMU only for the aliased device. If no IVHD entry names the alias DeviceID itself, amd_iommu_setup_device_table() passes a NULL IOMMU to amd_iommu_set_intremap_table(), and Xen crashes at boot. Signed-off-by: Stefano Stabellini --- xen/drivers/passthrough/amd/iommu_acpi.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c index fe3dee872c..31fae663c8 100644 --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -104,6 +104,10 @@ static void __init add_ivrs_mapping_entry( /* Assign IOMMU hardware. */ ivrs_mappings[bdf].iommu = iommu; + + /* Requests using the alias go through the same IOMMU. */ + if ( !ivrs_mappings[alias_id].iommu ) + ivrs_mappings[alias_id].iommu = iommu; } static struct amd_iommu * __init find_iommu_from_bdf_cap( -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 22:36:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 22:36:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456607.1669852 (Exim 4.92) (envelope-from ) id 1xJIR8-0004BS-4H; Tue, 20 Oct 2026 22:36:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456607.1669852; Tue, 20 Oct 2026 22: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 1xJIR8-0004BL-0x; Tue, 20 Oct 2026 22:36:02 +0000 Received: by outflank-mailman (input) for mailman id 1456607; Tue, 20 Oct 2026 22:36:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJIR6-0004BF-5Z for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:36:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJIR5-00EVP3-Ib for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 00:35:59 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7ecac-8faa-0a2a0a5109dd-0a2a450bdc02-18 for ; Wed, 21 Oct 2026 00:35:59 +0200 Received: from [40.93.194.23] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7eccd-b7e8-0a2a450b0019-285dc2178a51-3 for ; Wed, 21 Oct 2026 00:35:59 +0200 Received: from CH0PR03CA0231.namprd03.prod.outlook.com (2603:10b6:610:e7::26) by CH1PR12MB9597.namprd12.prod.outlook.com (2603:10b6:610:2ae::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 22:35:51 +0000 Received: from BL02EPF0002992C.namprd02.prod.outlook.com (2603:10b6:610:e7:cafe::38) by CH0PR03CA0231.outlook.office365.com (2603:10b6:610:e7::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.20 via Frontend Transport; Tue, 20 Oct 2026 22:35:51 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL02EPF0002992C.mail.protection.outlook.com (10.167.249.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 22:35:50 +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.53; Tue, 20 Oct 2026 17:35:50 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 17:35: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=c42g3tyEN+Y0tQxCOi0ccS0HP+tihUmxpIa1B9F2okmIRcfApZ3mSPcAm2Op2kn0mfG95gpuyiiH27MHyHkrdt/1UY1+ciAAn+GB6322eXAQP4QK3CZcH0bLSV0k86H8D4ab1npJy50eITU7eHr7YOgqsxaMNfcWO6Mrvm4+scPk3nSwFOeo6guqkzwAg9DSu1zJjfLQIS7jyv0MiOolYihwH7u3DQRvfPGiA7rddr1b+SlLHbrsSVLsBgJE+V5r1Y1kGAiMHlMA4iQ1N1TD1k7IdPvMlvpUxO1KO9wx1xx1XHFP//TWRjFv7hmdkctW/pgCMZ4k3X1ACSuUPLgHiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Vzji5eITuo5XfFpeBwgxfWgE41NZan1QMZX+6pDPknM=; b=IWR3o3KGO9KAXzVaes0Eh36OalUxsUjKEJRb4UfchrAYoAlTJ++19B6OnRAm8LuEUlUAg1iBocNFhgke8e5K5VlA5ShRRP8uueYMkHr4xdPE2mKe0Rw9/ygfURXdWQxut9vg4pWwjn8i7YshMqpMRs6tC+mhj60VuDLga0Z145PKL1tjipstG1YuCsWb+pWeiKm67FxjmWptYS9wQn9klgVCJs3f4PUjJLnkQLkkpAN4XlXBH3IyFpBm7z5SkVpDDEJ32E3EjZvl6tMuaXs/7qhC0XdszQyY65bb+QXVVMDxU3IghGFqBYVGuFJYHbcstfy/v/l+dckYF+MgYG3BCg== 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=Vzji5eITuo5XfFpeBwgxfWgE41NZan1QMZX+6pDPknM=; b=MqTvVkFuHINQ/YXDXL1rhBJ7ENvtF+GuHNkUpANGdSL++EZ2RceyHj4VkxwfkydHinFZrU7W/1+OhMsjtQg0yA62pmGOk44TiR1ZqhhrsuEPb0s9AVR7rYAsWfCjxILz2/M9V2GlE7x9A4qYORl72Tq2ce0rFOy/VpeBdJ2vEf4= 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 From: Stefano Stabellini To: CC: , , , Subject: [PATCH] xen/sched: Fix the sorted insertion in sched_domain_insert_unit() Date: Tue, 20 Oct 2026 15:35:34 -0700 Message-ID: <20261020223534.3703199-1-stefano.stabellini@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: BL02EPF0002992C:EE_|CH1PR12MB9597:EE_ X-MS-Office365-Filtering-Correlation-Id: 0ebe48e0-f78b-4fed-ba3c-08df2efa7e72 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|36860700016|82310400026|56012099006|11063799006|261009223027099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: 63tDwmKz6EPwXBcLzqin/lqR6t9IJmUKtFP0MhKaoR3KMRyhmoumKAStTo3r1CguNoAkp5dBScleiHJCHfQGhgXhrzjjCDzBqEbsH14h43vQY34aUnatIVqHyibxa158nVXQD1cCUz5X88pMomIJztpEej5LUR4rfqj0x/yI6viljS/E/lG9W478y4ytck+yMcfBhESgobYCl/WO4Hm/yiv0YfRzxuUJJTD4N9oNhn86414qCe3PgLtn+HTbxgI7QcRgOB3+/aMOVKe+i9ak81wTutCH7YUD4eS2L2QgBekeJXfodCAaB54GIvSa8pANpjN01UYXpB5OygwED2xuquEip50fXx+Nm6RuwnXCSRCd4jbLbsGlLYHDkpXSEoLEJP6PEZlcRkx2v+eus2URf8N5yw+TyAl1A0j8UKR36oKZ6lPcoue+/bh8djuZ90NksE9W+jeqpdzmFXvrVPKE0yB2KjJMWr2hNIJ/zrM2dy0vfSJ8dwKYeF/HUz5lP91T9WHkFvk40+sosvOySXCmDOXSyZ8+qtxCFQXT/08RkPAnj/gfbXFygsOYMKdGLBRnytHPRgtm0uClf93decjHLb1YidyblNcVtPqpnM2oiQokOgzHsCGj5qkQNU1L+DO253/cg5SdRUbnEJM1PoCV+4NHc8Dr2kBHyfTF1bDPyp6ZGCTGTZ/R+vqeLbWMgojCJ9d7EZw0R3q4hTmC/ySwKQ== 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)(82310400026)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +0oRefM57GHDGrOhCKKiE1CHLwvO88Vrq2oiWqc2t3z3YasTmfgJwBLIsPe3sTfOj3bkHl+wuYhzEShTdfxDz3JUCuQ4nkHh2u84ksmJ4xYSDEOiVu2YiIA5SldGUzANguAWtzlOJNuySEYoKelk5Unpss1i5UylhTyitqF1pL3zt4g9QsJaYj6wWT7aAlnQdSs0qOIxd6hFivVWdB3iXaKJT7bXdb8VVYw2hiwobd8epDaPaP6LpE5CKam0n3pQihfnf1NOB5eXccf/tLxh7vnQsgDvDFCUQur5F4PY9L+nZbbVMj4IwtO+yGkGlStjChVVswkjoNvU9wu0fpo0KKEnQRQkl7vGk1GJH35w1EahcnSS6Lfgdqzi7ZPxCKqovyhEWj5+j58UxRMxHz5Q2F2mwLKW0qBi7l0+egWHe7e8LTAtQvQz0Nd+t9wcdWr6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 22:35:50.7585 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0ebe48e0-f78b-4fed-ba3c-08df2efa7e72 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: BL02EPF0002992C.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9597 X-purgate-ID: tlsNG-42698a/1792535759-AA0C59EA-C606D92C/0/0 X-purgate-type: clean X-purgate-size: 1070 The loop links the new unit in front of the unit whose successor has a higher unit_id, rather than after it: inserting 1 into {0, 2} gives {1, 0, 2}. Stop at the first unit with a higher unit_id instead. I think it usually works because guest vCPUs are typically inserted in order. Signed-off-by: Stefano Stabellini --- xen/common/sched/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c index 0b072bdee6..a95d6752df 100644 --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -489,8 +489,7 @@ static void sched_domain_insert_unit(struct sched_unit *unit, struct domain *d) for ( prev_unit = &d->sched_unit_list; *prev_unit; prev_unit = &(*prev_unit)->next_in_list ) - if ( (*prev_unit)->next_in_list && - (*prev_unit)->next_in_list->unit_id > unit->unit_id ) + if ( (*prev_unit)->unit_id > unit->unit_id ) break; unit->next_in_list = *prev_unit; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 20 22:41:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Oct 2026 22:41:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456615.1669861 (Exim 4.92) (envelope-from ) id 1xJIWX-0005uM-Le; Tue, 20 Oct 2026 22:41:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456615.1669861; Tue, 20 Oct 2026 22:41: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 1xJIWX-0005uF-Hd; Tue, 20 Oct 2026 22:41:37 +0000 Received: by outflank-mailman (input) for mailman id 1456615; Tue, 20 Oct 2026 22:41:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJIWW-0005u9-Bf for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:41:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJIWV-0083hr-Kl for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 00:41:35 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7ee19-bab6-0a2a0a5309dd-0a2a4506b752-4 for ; Wed, 21 Oct 2026 00:41:35 +0200 Received: from [40.93.198.50] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7ee1d-195a-0a2a45060019-285dc6329a83-3 for ; Wed, 21 Oct 2026 00:41:35 +0200 Received: from CYXPR02CA0082.namprd02.prod.outlook.com (2603:10b6:930:ce::29) by SN7PR12MB6957.namprd12.prod.outlook.com (2603:10b6:806:263::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 22:41:26 +0000 Received: from CY8PEPF00000050.namprd05.prod.outlook.com (2603:10b6:930:ce:cafe::a2) by CYXPR02CA0082.outlook.office365.com (2603:10b6:930:ce::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Tue, 20 Oct 2026 22:41:26 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CY8PEPF00000050.mail.protection.outlook.com (10.167.247.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 22:41:26 +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.53; Tue, 20 Oct 2026 17:41:25 -0500 Received: from amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 20 Oct 2026 17:41: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=BFGxgmwh2hyjetUuGhUKShmPvabBtd5BG7ODJoUplY7Jq/yx9xzpspBAxCcaE5eMO+uTP2qAW6b+ongi6Ma9T3dBfwwrFVopb52DgdyzQDd2aZTRHzw+nFvXPwFbjM+pV5ftepk5CKuDOMfeVRSWS8leZjnFW956atptwSZSmf/YODGHr4k/Fhtpqd0mbZ547IIe5IRUOxEnzzm4w7Wtu7pEG2csCcx3459uNo5GyoFpI06LFnpUggvfibIRDsTMjMe3W864brYS2wlRO36MxEKBLlFcZazPf7Gg/Jb5ssgo7YjHFb8AC6XMjNYgx/Bv5TZNz1CSaCMGbS2h8rz4XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i2TMl5q79/075XExQN9cH1tRrO3ZhgLtFiJ/Z47MAdw=; b=NFH25YIBgWKVbnq0irFVROvVqcVJXg7O0b5mUJkfM42CVsEqKovqjKJrMl0mCSrNjftYSLx7BvztWd43AdcFzHD4vwNM+WOCBx8sUwggN0c7mRXMFO4It+63mXt4WbH+huQJoq86zAXVqJKvRrQhbtHCUx8Y8DZf/EROgbKL7x3ltb3dpPkbc2+qYXX1b4CRJJ0XAxwhEXyMfZWSCQRBGF26PRLZRyUZnEQm+AdZHZ3LhsgpsJrrI5zrKXjmjAd7E5YyuD2OVzuoO5rjkf6a6f6/GGg8rvmX7rkyPSYWVYT175pp4I48poaaZq4GiE365nvUd71Ny+AHhToDPZNnHA== 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=i2TMl5q79/075XExQN9cH1tRrO3ZhgLtFiJ/Z47MAdw=; b=u4YRGtwkVZCV6fytKx0NvbvguLBQeq71FBuwyMpVp5iyqE7ojpbqk/ngtJrBuChCHYkE8qXN0s01o8Pr3ylD5CzI6gS14imlSm5NiubKuVk1cqcae0YDV3C/FdcPYLbngpcqX9m56lWNxzA+4Q/ZqHN5wbL8TjZK6+74NuXJ0vI= 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 From: Stefano Stabellini To: CC: , , , , , Subject: [PATCH] xen/x86/svm: Apply the virtual-8086 IOPL check to INT n only Date: Tue, 20 Oct 2026 15:41:23 -0700 Message-ID: <20261020224123.3710391-1-stefano.stabellini@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: CY8PEPF00000050:EE_|SN7PR12MB6957:EE_ X-MS-Office365-Filtering-Correlation-Id: 110f18f1-cd7b-4e30-d20a-08df2efb4660 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|376014|82310400026|1800799024|261009223027099003|10067099003|56012099006|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: 2UYA4r3Xqy7MFHequENO+pa8KC1f27n4GbZzJAOamDY6renBzYfJ53ITMsdVQg1YwjfqrW6RAmEDvf/q7zemHCDp9aghU5XNUre3jmkVj0SgYaWAu00rBtS7ap5AfGooQhqBren2gO0w+r8kgwQl1ZyzW/30MKNHIqUElfDotT0IgarUBjQUOGazkUYjCIusL7kD7IweVrAKvCZjOIPGPmmC59nOAHHu7WPCBilLluuhUqFDtg57vY3xRmCMURXgXlJH6fI4go1gVjf7GTeGrZT7ZtH8vNTmPyDUmZn2nTctaYG+kraJ5Q5Cp1ZGyFcTXmaQh9+CbehTutNZMkBfTmemWOJDuWfYHb/q9sZxi5gvUNSvMc7m8xwKKfmXc9Z1TYkIQsGlsgPxSLmCrKwK5osd7XhCyeb2e68fLkVPhfB22Az2FuSrCYs3UZkct7GU2ONobKdeWvweuSB1UPVEavdi0jrZB8lJHLle7F6TlPIzFNkC8vBZDH904FpVJzDxG5Bz+ihYaFJ40yh86tDFn9x7EhK/MOFlMj1ctEzlRPOV/1pSiUMkE7aM7NIXg51g83ZRLIC84Z7cgXMcWMc82yw1pO2D+zYNCb5HergC62ksBNezJahcrTlb+AfliLFCeXLMVTtQGEj712fil+XeHYNz94dGzSMaWZKGRtGXaFOEQL1vvKvpIjZvGgtjIOg4PuIeJhYzE35gPcBYPXLBiA== 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)(261009223027099003)(10067099003)(56012099006)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 1xe4q81kIA0f6+wu4T7haaThWqGmbpBQpN65RsG4cxPS6j8EOwMlBvWy34iN/GQXof2PX4aQDk8kuUrA7DGv7gdH4svozMXc8jDYEMcXnrgyx0SJu25u+I6JdVAoa2efuAbuqCbjGKUtKHgGUNOUiOzwTTWm1KdMEOgqgDb0Sd1rssBICRp2ZzD2avZjkMRQhBn4HR8xMyoRCGzmBiIKrgWQbXLYJbXNjh9PGFR4bY80OP62lTZCl/wv2Tikwds2MD3WnxcMd5dtEyR8N1sh9f+1dAvSw4bzdX1YAcCzj47sprpxx6lTsIvieNSm2ymuhtFD2QLW624qiHu2LEs1IUUABec+Bkwj6LxArNGHqsmrfu9eRC8Xge4NbQ7HZvrnxiJwv5D9eOJblFIJiuWH6ndxVEveRMLKhUf6W0G7ULshpOH4Qd0NermdxvHrlck1 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 22:41:26.1424 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 110f18f1-cd7b-4e30-d20a-08df2efb4660 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: CY8PEPF00000050.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6957 X-purgate-ID: tlsNG-16d1c6/1792536095-1F4C977B-CBD86F6D/0/0 X-purgate-type: clean X-purgate-size: 1246 In virtual-8086 mode with IOPL < 3, INT n raises #GP(0). INT1, INT3 and INTO are not affected. They are delivered normally. svm_emul_swint_injection() applies the check to all of them, so an ICEBP raises #GP instead of #DB. It also reports the IDT entry in the #GP error code instead of 0. Limit the check to INT n and use error code 0. Signed-off-by: Stefano Stabellini --- xen/arch/x86/hvm/svm/svm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f2..df74531d1a 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1153,9 +1153,12 @@ static void svm_emul_swint_injection(struct x86_event *event) * 32bit OS. Someone with many TUITs can see about reading the TSS * Software Interrupt Redirection bitmap. */ - if ( (regs->eflags & X86_EFLAGS_VM) && + if ( type == X86_ET_SW_INT && (regs->eflags & X86_EFLAGS_VM) && MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) + { + ec = 0; goto raise_exception; + } /* * Read all 8/16 bytes so the idtr limit check is applied properly to -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 00:41:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 00:41:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456660.1669870 (Exim 4.92) (envelope-from ) id 1xJKOd-0005CK-Ky; Wed, 21 Oct 2026 00:41:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456660.1669870; Wed, 21 Oct 2026 00:41: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 1xJKOd-0005CD-Gk; Wed, 21 Oct 2026 00:41:35 +0000 Received: by outflank-mailman (input) for mailman id 1456660; Wed, 21 Oct 2026 00:41:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJKOc-0005C7-UH for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 00:41:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJKOc-001eaY-3W for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 02:41:34 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad80a24-2eae-0a2a0a5409dd-0a2a45028cd0-10 for ; Wed, 21 Oct 2026 02:41:34 +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 6ad80a3c-6ca4-0a2a45020019-ac6904fe9c88-3 for ; Wed, 21 Oct 2026 02:41:33 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 062B8601FE; Wed, 21 Oct 2026 00:41:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B23F21F000D0; Wed, 21 Oct 2026 00:41:31 +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 A9D493809A0D; Wed, 21 Oct 2026 00:41: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="Subject:From:In-Reply-To:References:Date:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792543291; bh=X2Kxv3mJpDKDJB+5pKZCRsssmwhER53b4YfHaRp0jJY=; h=Subject:From:In-Reply-To:References:Date:To:Cc; b=RXKMryKRvHG1QjDbjYmrorK3r8Znn/wabnd7G0UVf9tFJkp4ks84JbpaHKxrlKQyZ VugmYge8S8iZytDdibGpZsMvQhmSzoxrkNn6dLjRr7tKRlgrawNAUZfVxMQkAVgGhU 42IvdfQ9ljXrAsqIb1ZZnIUAZT1zTutCqC0GwNzzinBkstVbHh/ykpizLVJx775tab GDUJPVan10kFDgF6OEUMPqq4gKNXyRbX29+693W5kc/F/h+M5ynLyUwtIe+YznlADx lcudBrjD+A07A/OF+pLHSuKkz4UDdjlFQXOXRQu/Ol2jfLPf5wIaBVdpRe+8krrE7b UYXoEm9uH9ftA== Subject: Re: [GIT PULL] xen: branch for v7.4-rc1 From: pr-tracker-bot@kernel.org In-Reply-To: <20261015114439.418665-1-jgross@suse.com> References: <20261015114439.418665-1-jgross@suse.com> X-PR-Tracked-List-Id: Xen developer discussion X-PR-Tracked-Message-Id: <20261015114439.418665-1-jgross@suse.com> X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.4-rc1-tag X-PR-Tracked-Commit-Id: 61b6d1df1d6234c38a6ea7e4f58e7da035ef6ab4 X-PR-Merge-Tree: torvalds/linux.git X-PR-Merge-Refname: refs/heads/master X-PR-Merge-Commit-Id: 2a0d3d73c112e1ffbb8cc01098b9bd2a3087b40f Message-Id: <179254329058.289274.8850742191656357692.pr-tracker-bot@kernel.org> Date: Wed, 21 Oct 2026 00:41:30 +0000 To: Juergen Gross Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org X-purgate-ID: tlsNG-720697/1792543294-321D72AC-BFB912EB/0/0 X-purgate-type: clean X-purgate-size: 362 The pull request you sent on Thu, 15 Oct 2026 13:44:39 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.4-rc1-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2a0d3d73c112e1ffbb8cc01098b9bd2a3087b40f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html From xen-devel-bounces@lists.xenproject.org Wed Oct 21 02:11:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 02:11:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456695.1669877 (Exim 4.92) (envelope-from ) id 1xJLmv-0000I8-T9; Wed, 21 Oct 2026 02:10:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456695.1669877; Wed, 21 Oct 2026 02:10: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 1xJLmv-0000Hv-Pw; Wed, 21 Oct 2026 02:10:45 +0000 Received: by outflank-mailman (input) for mailman id 1456695; Wed, 21 Oct 2026 02:10:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJLmu-0000Hp-Th for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 02:10:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJLmu-004BgJ-3w for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 04:10:44 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad81f24-e002-0a2a0a5209dd-0a2a450993cc-0 for ; Wed, 21 Oct 2026 04:10:44 +0200 Received: from [52.101.193.62] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad81f22-be1a-0a2a45090019-3465c13e90ba-3 for ; Wed, 21 Oct 2026 04:10:43 +0200 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by SA6PR03MB7664.namprd03.prod.outlook.com (2603:10b6:806:43d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Wed, 21 Oct 2026 02:10:39 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%4]) with mapi id 15.21.0522.016; Wed, 21 Oct 2026 02:10: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=PXI4X/YaVYYRH9cxZld1AgL/inAwnn1z3B+ViQkqjh903++Fxz/eqL3MMA/p0FhTUD8JSI2EMR9rlGoE6XH0KNyb0CrG8yLSZuOcEPV0cKisAMagCymd4Dtnr4RYm4M2ZRN7z+Om1/A4C4LMypm4OzE8FnVWEPO00ozh8PgnVqttzNnJxztJVMKRpXbQu/dbOcFs5jPnzuH4Vv1+Mwk/8cifVOSau4JBw3sU5xzYBqRLrkdqprAFTt7P6OgHu0qzY24WVrPpFIjP6WvMJbJ5kKqYovMxc8C37hB1JBJWDFWSDqz10EjRYFcqyej1Cmhjx0ySSh9kx6lSdMrFX+Wq4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xLLtrtQSv/K1xygCbcjAPnvdR4OzMAFi5DJIFNHliR4=; b=sbQu+6NulpNpy0QvMI2D1iXLkErQLHRGPNWHFgMo2Hb4KNdSaw+cMsck0VpW9cSk62Rxs483wWvpGiG+/WN+De7ul4siOGiMH6JLMWbKKIsdO2264yc9fN+XBOF8qt+ImZymQM4aAdX6uFxptPDzAubzQLochRosU58zEV5UOE4QZIqbop+CUzV1bEmTozHLUC9UkjZokirt+N6JaCJg+ArQNZdlZAaHH8IDPvcVKcR6V8yVFkksPmwUQbBvASLTo70kyq8hSltf3sL+KotFP+rNJDM4Sut18AZwlYtrjt96+c4hhkiXhHzTjSFe2kr4TcSfWqmB0KhYRAf400ZAeg== 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=xLLtrtQSv/K1xygCbcjAPnvdR4OzMAFi5DJIFNHliR4=; b=BKIGXFmmKGgoGFXSFG95zNmdtWL58tk360vL1XaIa/yXmdccFzcJMNWKU3Mr9JKSFIjlyEKxiZSSACNuCy9ZgpLYNDeF/eGwysrOcuPgRmcl9S16x2JppMiw96VR2ki1YGkZlCHA4FPSY/Cx27E9p2wIlWfJcr6tw54zWQxPdm0= Authentication-Results: mx.microsoft.com 1; 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?= , Teddy Astie Subject: [PATCH v2] x86/np2m: flush the np2m on an SVM nested TLB flush Date: Wed, 21 Oct 2026 10:10:28 +0800 Message-ID: <20261021021028.123867-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <7757cb6d-78d2-4d73-bfee-f9d5db8f15a1@citrix.com> References: <7757cb6d-78d2-4d73-bfee-f9d5db8f15a1@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2P153CA0039.APCP153.PROD.OUTLOOK.COM (2603:1096:4:c6::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_|SA6PR03MB7664:EE_ X-MS-Office365-Filtering-Correlation-Id: 73fdaaa4-acc2-4376-4527-08df2f1880a8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: SZq8Wo8Be6fNuQ1ZsEYDfzgrCqQG6dFw7aAJvKGHk6r5sRr6+5syqXnighIIMbXlSfOTum/VupBnPcklIH3kHXl5UWAs3CaLTkvIH2F1mq3w1snjThWargftOJ+P5diC8wxCAIm6szdOq6O5X47ynX2P2Qspm7DQ+xNdKrAkNNmzOcGlIRzeZ3Y+WfLyp8plILWFtrPziA/e98mYqL+IxcRugRGWtYP7Ml2ubz6Waxt817D19dH7cDZ6VqVxSmAG5oqmhrqEUiMDDHGTH5+qswFrPHbVD/i8d9L15Zk6NDeO7YuX3jDT8EdUXqm0xds1+lVdim9rMyOIXAwkGtDMXcNib/XeqH4L/lqgGRJIfq/PkNCHBzYB+0swY/N1l8dh3CRO1KyzXvEfolXZan3uFIJ6qn9YsYYUM1u3tEIKfV2tY6U2b79ZXFPfEt9dWGOSRdGLG5KwIsgsTiTZEeyr1oi5whc7flHDBech7P4vG2BIRAPaDM2UFZeZUJHTWDpC/rTVF9LLlhSEwGWXIQ5Bl78AijVDvTio3znK2R/inw63T5qmQPq/5wiQD0z9Dwr2Cxf0ilXEH1IuJrOiemR2ARG6imiPBofoFnC3xH8ht52BIOJ0KowIyZjuanDNLimM 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)(23010399003)(376014)(1800799024)(366016)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uCwlO0TWZ5qhtoRyS/uOiRa27sfs6RHiGp0fSKVQ6tYAeLZILupP3CE0h8Lr?= =?us-ascii?Q?YyYCkv8xibQ5JmOTCTTIF9/QoixzRhDRO3TGs7N6ysrQSP1Keta3e5/tiCTq?= =?us-ascii?Q?y8Y4+7PDwoIovC9gU69skD4+rEzQeowMUz7+MVNx7amuGOYfSAgqHstb9jEe?= =?us-ascii?Q?wrVIDk8Q9RouBRGtB6vnQYdEDB6z4vroLl3lhIAi3uSa9HbZWr9rkEaWySVu?= =?us-ascii?Q?yK7udLagj/NSO71pDPVdtdGYOdwcxem871MfbCyDvhxeU1IvcyiYa7hod4Vr?= =?us-ascii?Q?m9BC6C87emLK0Jw0RcH5XgVW6TrOPcxzcZnRdbUbEMjm8huknZLRTFxgIbao?= =?us-ascii?Q?r+5PmaBOpnQNY9iKqOvYStMaOsS4pMSQhqeKpjkie6vHgTubA28eNUhRqD8S?= =?us-ascii?Q?gCRhZ74/zjw7MKYPakceqmQUenYEiOROH+OlhWnkFx5fErvFQ8CpbRZ4z1Gl?= =?us-ascii?Q?6LKU9pzLV9QjB9/L+SpEvdESfriHpOY9fA063m4Yq5Twp4xXe0+1E+CnuR4H?= =?us-ascii?Q?+HYQGqFZWM12seKFOtU59Fc4iZ2EsPEkotwOMlFiECV6z+vAOS0vZaz1AhYA?= =?us-ascii?Q?0g+7bzh1HgCwuPRN5FgfSz1V/knjUGmsqttdAR6N6dnRAuUkAnIWYFY0ex/i?= =?us-ascii?Q?fPdYKx/ZcipHEyjkrSSG/F8SeBsNTMH3D8espcIIHQd1fouX0Josh89rcICw?= =?us-ascii?Q?mqlWbIKGr4l0fFe7ArvI2bZF4lVR8tBHwIFuPGWALdi6MKizknDlf2bOsQ/+?= =?us-ascii?Q?QoJsxKE9+u3kvmMVTcVq7keX/WxPTZQeyA4gzEXzuD7pTiWD4CF65piFPmuv?= =?us-ascii?Q?fKvWQzf/ede3rJ4PAk1wKTjd8/FZXy+4jcshhJ7ZmVtJfN+YHgcoRWahFoaw?= =?us-ascii?Q?aF41iNzthBNoCFhHRq5kKXMqZn1IzOevavdSy1vERmAg4mOXN8ZYjsTOmoS3?= =?us-ascii?Q?SzVZRdr9yzsYhXAibvv6gdf3uqZYzRAedIeSQ8CQuzfkXb1ptl4/dK7lGQLJ?= =?us-ascii?Q?91JbVLsOAXBLrbPesvKYXgpWRi2qrA/dkrcUbyyQSlYBRrq0+cbW3AjLEdmh?= =?us-ascii?Q?j+ATwu3jxRft8SCHh2gmvhrpAY4kGWzopTUs+5DeolGV6KFEOemC9d5K5P0q?= =?us-ascii?Q?evN4J6xi559VR7zzeJxStD3s3TDSWRORTchaWtPXGIjymsqydH1+zo7YHl6s?= =?us-ascii?Q?ox1KZFU65R/5HkGcdwNSFhQ9Aj6LoKyHo8tvct8BDkMFLStd+0dDrqdh2leo?= =?us-ascii?Q?XH7ozQpDN+eYoKFGdM0hkzd9dpJw+Py+jPs5DN07PyDhEqV5boMtEQy2us5y?= =?us-ascii?Q?QKsXFO/rxusBkWntmF/uDE90zAcRNv98VY00N52UnnUHqRKRJJy5A38izT7d?= =?us-ascii?Q?cm5B5Xcx9TA2HSHQbVFf9TI6aCpwJC/qjLx1YfruByh1LYFCiSVW+Z7ZpRGW?= =?us-ascii?Q?qx/RVdnvGZUg2fk5K/SwoZP8vlMeM3tKY4rIWLb4PoZ+5LQJTTYEQ2gqd5V2?= =?us-ascii?Q?s63oyhPU4lX2WFX2RsPMOwNcxTEKu8Cd6fxMuymEtbBq+MqhqEaNh0iS6uad?= =?us-ascii?Q?BY5UQzuLCRwmklAVbSaLwDwYypi8QNPjKV1p1CmfUiy5meF4XfcHFrtL7/sb?= =?us-ascii?Q?JL5kiFEaovS7kc+N4h8NGKyKn4SKCUZYec8Z4FmcqS0IHoWx1NLvC/uYLfC0?= =?us-ascii?Q?KVeyImG+FY6/snpnZKMJ4nKnlP6detLQPKiLgPH00sSEuj4SJjUhCqwzIqTz?= =?us-ascii?Q?2JzvhDA/9Q=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73fdaaa4-acc2-4376-4527-08df2f1880a8 X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 02:10:39.6811 (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: KGrfdgjjAnqk1fVRVknJkSWmX6Mn1FXzdzET+4RkXmMiH9qKGJBvKSBAKc+/GP/xbCZkxOjeJ0p92QJYmE9LGm8AB5stVtflHHR+rFGRRb0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7664 X-purgate-ID: tlsNG-bad1c0/1792548644-FD06B034-682A0A4C/0/0 X-purgate-type: clean X-purgate-size: 2338 On SVM, L1 flushes what is cached from its nested page tables by setting TLB_CONTROL or using a new ASID on VMRUN. Either sets nv_flushp2m, which p2m_get_nestedp2m_locked() handles by only dropping nv_p2m. Since np2ms are shared between vCPUs, the lookup then finds the np2m for the same N_CR3 and reuses it as is, so L2 keeps the mappings from before L1 changed its NPT. The obvious fix, flushing nv_p2m (the np2m this vCPU used last) before dropping it, is not enough. It covers a vCPU re-entering the same N_CR3, but not one entering an N_CR3 whose np2m another vCPU filled: on its first VMRUN (nv_p2m is NULL), with an ASID new to it, or when switching N_CR3. Instead, flush the np2m for the incoming N_CR3 before reusing it, as nested VMX does via np2m_flush_base() on INVEPT. Fixes: 6df4b481b0c5 ("x86/np2m: implement sharing of np2m between vCPUs") Signed-off-by: Stephen Cheng Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Ross Lagerwall --- v2: - Explain in the commit message why flushing nv_p2m is not enough (Ross). Ross Lagerwall's partial fix, which flushes nv_p2m, was part of v1 of Chunjie Zhu's "x86/nestedsvm: rework nested VMRUN/VMEXIT handling" series (patch 5/5, dropped in v2): https://lore.kernel.org/xen-devel/20260924091605.344577-1-chunjie.zhu@citrix.com/ if ( nv->nv_flushp2m && nv->nv_p2m ) + { + p2m = nv->nv_p2m; + if ( p2m ) + p2m_flush_table(p2m); nv->nv_p2m = NULL; + } Tested with an XTF test that is not yet upstream: L1 repoints an NPT entry, then enters L2 on another vCPU or N_CR3 under a new ASID. L2 saw the old frame before this patch and sees the new one with it. xen/arch/x86/mm/p2m.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 027b9ae69b..52cadd9b25 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1547,7 +1547,11 @@ p2m_get_nestedp2m_locked(struct vcpu *v) p2m_lock(p2m); if ( p2m->np2m_base == np2m_base ) + { + if ( nv->nv_flushp2m ) + p2m_flush_table_locked(p2m); goto found; + } p2m_unlock(p2m); } -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 08:20:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 08:20:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456793.1669899 (Exim 4.92) (envelope-from ) id 1xJRY9-0000Pc-DU; Wed, 21 Oct 2026 08:19:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456793.1669899; Wed, 21 Oct 2026 08: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 1xJRY9-0000PV-Av; Wed, 21 Oct 2026 08:19:53 +0000 Received: by outflank-mailman (input) for mailman id 1456793; Wed, 21 Oct 2026 08:19:51 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJRY7-0000PP-Qv for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 08:19:51 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xJRY7-00000005UT5-2UP2; Wed, 21 Oct 2026 08:19: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.98.2) (envelope-from ) id 1xJRY7-0000000Bl8s-0zfO; Wed, 21 Oct 2026 08:19: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=zih/YHTh2oXn5bNkn1DI2OrBDiu3Ur9QKpyCozdCFJY=; b=Kf1FNC0lTXhRYvnlX1yJbHCAIh FLBwR0DL0JIZnV3kq2jmVWvuccWzI7JaLrehx83w5psx3BlYPW29gD0duCvdS1WXurlV1C9PURKE+ YuQ5QYknErivNgYQupAavoMokhkkka5hxvHcPSS2FRfEW+aRl2YURKuyzawEsJSZCXYg=; Date: Wed, 21 Oct 2026 10:19:45 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: [PATCH] xen/x86/hvm: Propagate emulated CR2 writes to the VMCB Message-ID: References: <20261020213315.3641133-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261020213315.3641133-1-stefano.stabellini@amd.com> On Tue, Oct 20, 2026 at 02:33:15PM -0700, Stefano Stabellini wrote: > hvmemul_write_cr() updates guest_cr[2] but, unlike every other writer of > it, doesn't call hvm_update_guest_cr(). On SVM, CR2 is loaded from > the VMCB, so the emulated write never reaches the guest, and the next > VMExit overwrites guest_cr[2] with the stale VMCB value. > > Signed-off-by: Stefano Stabellini Acked-by: Roger Pau Monné I wonder whether there's more missing here, see below. > --- > xen/arch/x86/hvm/emulate.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c > index c09ea002ec..cd2831d34b 100644 > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -2350,6 +2350,7 @@ static int cf_check hvmemul_write_cr( > > case 2: > curr->arch.hvm.guest_cr[2] = val; > + hvm_update_guest_cr(curr, 2); Looking at hvm_update_cr(), is this possibly also missing a call to nestedhvm_set_cr()? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 21 08:36:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 08:36:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456807.1669908 (Exim 4.92) (envelope-from ) id 1xJRoS-0003PK-Nc; Wed, 21 Oct 2026 08:36:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456807.1669908; Wed, 21 Oct 2026 08: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 1xJRoS-0003PD-KR; Wed, 21 Oct 2026 08:36:44 +0000 Received: by outflank-mailman (input) for mailman id 1456807; Wed, 21 Oct 2026 08:36:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJRoQ-0003P5-S4 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 08:36:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJRoP-0072Ui-LY for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 10:36:41 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad87997-bab6-0a2a0a5309dd-0a2a4507bbf6-0 for ; Wed, 21 Oct 2026 10:36:39 +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 6ad87996-b4ea-0a2a45070019-b9ff1c22b1b7-3 for ; Wed, 21 Oct 2026 10:36: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 1a15d9aee9c000f79f.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 21 Oct 2026 08:36:37 +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 3E6FB8050D; Wed, 21 Oct 2026 10:36: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: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=FQTrxWiSfZEV75zYaR1Sb7n3xsNIZ86HfzJH8VOlPAY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=nOjeHJruB+7jbYROEAeGaQNpFABL/45XYASG314KVqTiUoV3J24GVInRqvuH+6sDqIyaL4Lec ZKkmQqkijT/xs8pn/+uALOEeyvtYVY7hl7cq5RMuY6gjDEYnQACS+sGuOLtC7NshvaAQu/05wiF nkr1dNLpuTX7/XGvYG06A7zHSXmDGYPPdc2abDSk4efjfalyz1k181js9i4Jm6fQkPRzPpiFrbG 11hwGk/GROwtnCZuV7JvKOXgPpnZ4BumHX/OObw1U29nfo6876dByBpsrUjde4hHorFGiTqrBDA dHnD3I/7K34G6BTp3k+pZ3xEvYcfIlX5mMMhSMSlHkZQ== X-Zone-Loop: 1d3cd2ccd68871385e2d5d46764634f7d4e39ee37c4c x-campaign-type: default x-transaction-id: f6f03b53-b66b-477c-b32c-5ab93bd8a7cb x-swg-uid: 01-a135f7c7-6078-4a16-9501-b3cfda85988d X-Mailer: Sweego Message-ID: <1792571797.8631fc262581453bbf619ec5b2062170.1a15d9aee9c000f79f@vates.tech> x-swg-bid: 1792571797.8631fc262581453bbf619ec5b2062170.1a15d9aee9c000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 21 Oct 2026 10:36:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/amd/iommu: Don't swap the IVMD read and write permissions To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com References: <20261020220821.3681692-1-stefano.stabellini@amd.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: <20261020220821.3681692-1-stefano.stabellini@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------TRQmbTh4QmqHUI3MZAriA1Hr" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792571796393 X-purgate-ID: tlsNG-ef75cf/1792571799-370DDAE4-C34369EE/0/0 X-purgate-type: clean X-purgate-size: 6505 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------TRQmbTh4QmqHUI3MZAriA1Hr Content-Type: multipart/mixed; boundary="------------GCvhsxvzdal0v8O15occTQbE"; protected-headers="v1"; hp="clear" Message-ID: Date: Wed, 21 Oct 2026 10:36:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/amd/iommu: Don't swap the IVMD read and write permissions To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com References: <20261020220821.3681692-1-stefano.stabellini@amd.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: <20261020220821.3681692-1-stefano.stabellini@amd.com> --------------GCvhsxvzdal0v8O15occTQbE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjEvMTAvMjAyNiDDoCAwMDoxMCwgU3RlZmFubyBTdGFiZWxsaW5pIGEgw6ljcml0wqA6 DQo+IFBlciB0aGUgSVZNRCBGbGFncyBkZWZpbml0aW9uLCBiaXQgMSBpcyBJUiBhbmQgYml0 IDIgaXMgSVcsIG1hdGNoaW5nDQo+IEFDUElfSVZNRF9SRUFEIGFuZCBBQ1BJX0lWTURfV1JJ VEUuICBwYXJzZV9pdm1kX2Jsb2NrKCkgdGFrZXMgaXcgZnJvbQ0KPiB0aGUgZm9ybWVyIGFu ZCBpciBmcm9tIHRoZSBsYXR0ZXIsIHNvIGEgdW5pdHkgcmFuZ2UgZmlybXdhcmUgZGVjbGFy ZXMNCj4gcmVhZC1vbmx5IGlzIG1hcHBlZCB3cml0ZS1vbmx5LCBhbmQgdmljZSB2ZXJzYS4N Cj4gDQo+IFJhbmdlcyB3aXRoIGJvdGggcGVybWlzc2lvbnMsIGluY2x1ZGluZyBYZW4ncyBv d24sIGFyZSB1bmFmZmVjdGVkLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFi ZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAYW1kLmNvbT4NCj4gLS0tDQo+ICAgeGVuL2Ry aXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2FjcGkuYyB8IDQgKystLQ0KPiAgIDEgZmls ZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZm IC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2FjcGkuYyBiL3hl bi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9hY3BpLmMNCj4gaW5kZXggNDY4ODkw ODgyNC4uZmUzZGVlODcyYyAxMDA2NDQNCj4gLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91 Z2gvYW1kL2lvbW11X2FjcGkuYw0KPiArKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h bWQvaW9tbXVfYWNwaS5jDQo+IEBAIC00MTQsOCArNDE0LDggQEAgc3RhdGljIGludCBfX2lu aXQgcGFyc2VfaXZtZF9ibG9jayhjb25zdCBzdHJ1Y3QgYWNwaV9pdnJzX21lbW9yeSAqaXZt ZF9ibG9jaykNCj4gICAgICAgICAgIGV4Y2x1c2lvbiA9IHRydWU7DQo+ICAgICAgIGVsc2Ug aWYgKCBpdm1kX2Jsb2NrLT5oZWFkZXIuZmxhZ3MgJiBBQ1BJX0lWTURfVU5JVFkgKQ0KPiAg ICAgICB7DQo+IC0gICAgICAgIGl3ID0gaXZtZF9ibG9jay0+aGVhZGVyLmZsYWdzICYgQUNQ SV9JVk1EX1JFQUQ7DQo+IC0gICAgICAgIGlyID0gaXZtZF9ibG9jay0+aGVhZGVyLmZsYWdz ICYgQUNQSV9JVk1EX1dSSVRFOw0KPiArICAgICAgICBpdyA9IGl2bWRfYmxvY2stPmhlYWRl ci5mbGFncyAmIEFDUElfSVZNRF9XUklURTsNCj4gKyAgICAgICAgaXIgPSBpdm1kX2Jsb2Nr LT5oZWFkZXIuZmxhZ3MgJiBBQ1BJX0lWTURfUkVBRDsNCj4gICAgICAgfQ0KPiAgICAgICBl bHNlDQo+ICAgICAgIHsNCg0KVGhhdCBwcm9iYWJseSB3YW50cyBhIEZpeGVzOiBub3RlLg0K Rml4ZXM6IGU5NDFhYmQ3Y2FiMSAoIkFDUEk6IGVsaW1pbmF0ZSBkdXBsaWNhdGUgSVZSUyBk ZWZpbml0aW9ucyIpDQoNCldpdGggdGhhdCwNClJldmlld2VkLWJ5OiBUZWRkeSBBc3RpZSA8 dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4NCg0KVGVkZHkNCg== --------------GCvhsxvzdal0v8O15occTQbE-- --------------TRQmbTh4QmqHUI3MZAriA1Hr 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+p0QLLz9AFAmrYeZEFAwAAAAAACgkQZg+p0QLLz9BK eAwAkjj2WNaerM8QMpHxvOXUkY3ukEkiHBRARV6AsC2kkHMPy7ruxTsJmMTq8jFBAIod9PjK9BFn jUZ3vwQO703bDtfgL5/f0XVA7r3LDWqH9AfCSn6NJyCKEP8PHbeKIUNf1JW86s/+F0vrwir8hwos P6afzaYSUKOolDCfOhRsxjij55G9LZSAKOki+dou/+OMYTacOP1Z7tbRbWr3fT1z/YUoqxkQnmH/ tL0cWSiHO6vamT2OnoeQ8fkAY33VEN9f2Vh2HHMwi4NGYnF7S6PHWUhZK8QFuNE4+3uAlBRegvgC 01LODJsIzhdxffjaSQcjasZ6fsrt0Bmh7Rq/JeILpwg9LXbvdM61FlFL3e9n2OeWoFtmNty0WOKl Y08xiyeYHB2KwlHdjt8XmOI4i6n7zPpplX20aYCW0M1usiIYiyE3A6gKr9Ebv1r0sum7B+WHOykJ 0fLu6Iegz7kUq0QRk/W/EEWSCsh2JHh+XuGp7KHpf8UzFBDtTt2+7tZgDdYF =Ukpt -----END PGP SIGNATURE----- --------------TRQmbTh4QmqHUI3MZAriA1Hr-- From xen-devel-bounces@lists.xenproject.org Wed Oct 21 08:51:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 08:51:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456813.1669917 (Exim 4.92) (envelope-from ) id 1xJS2Q-0006Sl-RI; Wed, 21 Oct 2026 08:51:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456813.1669917; Wed, 21 Oct 2026 08: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 1xJS2Q-0006Se-O9; Wed, 21 Oct 2026 08:51:10 +0000 Received: by outflank-mailman (input) for mailman id 1456813; Wed, 21 Oct 2026 08:51:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJS2P-0006SY-Dg for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 08:51:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJS2O-00G5WI-Ix for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 10:51:08 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad87cfa-2eae-0a2a0a5409dd-0a2a450cd376-2 for ; Wed, 21 Oct 2026 10:51:08 +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 6ad87cfb-f479-0a2a450c0019-b9ff1c228129-3 for ; Wed, 21 Oct 2026 10:51: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 1a15da83071000f79f.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 21 Oct 2026 08:51:05 +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 DF0C98088C; Wed, 21 Oct 2026 10:51: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=Lm0wp9YoupniqkJX+09pmQnXMjWXx5i/7HuzUmcvoKs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=hkDrgJup+LfF2AK8XrXyYzGV1hHFzpSzdLInr9aqWl4Cw5PlZCijZBUgPdHLnUv0xTxD6+J86 pSiqRSeQizeIFXG0ZRR6ULc2cROQtuQTpY3+BmPEM9fT+SyQhK6aDK6mJzvMVFRa+EV9+Zg/EN5 cAkPVGi6TERtNRIUDJiohk1iATZEDLJIHI70cxy6hahB/tFpqa1yX9GznJgJUYfQp0mDZGTvvuC TpyXK+ZvwjsMAX2SrMdJPTOTUW+rNmbRuJX8wv8SAn71guch6QU7Aojcvk7wnAcWM5XRKrua+Vf vVGmK0Ydy/cZ6qRh9KtFfsafeRGZIFVADe8D6h1DPArw== X-Zone-Loop: b6e9281e38efabe097c102a805cde208aec4fbc3cfbc x-campaign-type: default x-transaction-id: e3c00b40-dee8-4e62-aab6-7df71b79599a x-swg-uid: 01-6850e34d-8a73-480f-9249-1fed2120ebfd X-Mailer: Sweego Message-ID: <1792572666.8631fc262581453bbf619ec5b2062170.1a15da83071000f79f@vates.tech> x-swg-bid: 1792572666.8631fc262581453bbf619ec5b2062170.1a15da83071000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 21 Oct 2026 10:51:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/amd/iommu: Skip IO-APICs missing from the IVRS in shared IRT mode To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com References: <20261020215941.3667346-1-stefano.stabellini@amd.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: <20261020215941.3667346-1-stefano.stabellini@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------k01182ByWMU9bAS8EbtS6aFa" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792572665049 X-purgate-ID: tlsNG-d25034/1792572668-774D7A5B-E280A435/0/0 X-purgate-type: clean X-purgate-size: 6333 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------k01182ByWMU9bAS8EbtS6aFa Content-Type: multipart/mixed; boundary="------------goLJC7ouf9FFdUoMF6sRJw00"; protected-headers="v1"; hp="clear" Message-ID: <2060aeab-f692-458d-ae4a-f7b2cc080ea1@vates.tech> Date: Wed, 21 Oct 2026 10:51:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/amd/iommu: Skip IO-APICs missing from the IVRS in shared IRT mode To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com References: <20261020215941.3667346-1-stefano.stabellini@amd.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: <20261020215941.3667346-1-stefano.stabellini@amd.com> --------------goLJC7ouf9FFdUoMF6sRJw00 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjEvMTAvMjAyNiDDoCAwMDowMiwgU3RlZmFubyBTdGFiZWxsaW5pIGEgw6ljcml0wqA6 DQo+IFdoZW4gYW4gSU8tQVBJQyB3aXRoIGVudHJpZXMgaXNuJ3QgZGVzY3JpYmVkIGJ5IHRo ZSBJVlJTLA0KPiBpb2FwaWNfaWRfdG9faW5kZXgoKSByZXR1cm5zIE1BWF9JT19BUElDUy4g IFdpdGggcGVyLWRldmljZSBpbnRlcnJ1cHQNCj4gcmVtYXBwaW5nIHRhYmxlcyB0aGlzIGlz IGZhdGFsLCBidXQgaW4gc2hhcmVkIG1vZGUgcGFyc2VfaXZyc190YWJsZSgpDQo+IG9ubHkg bG9ncyBpdCBhbmQgdGhlbiB1c2VzIE1BWF9JT19BUElDUyBhcyBhbiBpbmRleCwgcmVhZGlu ZyBhbmQgd3JpdGluZw0KPiBvbmUgcGFzdCB0aGUgZW5kIG9mIGlvYXBpY19zYmRmW10uDQo+ IA0KPiBTa2lwIHN1Y2ggYW4gSU8tQVBJQyBpbnN0ZWFkLiAgSXQgaXMgbGVmdCB3aXRob3V0 IGludGVycnVwdCByZW1hcHBpbmcsDQo+IHdoaWNoIGlzIHdoYXQgdGhlIHJlc3Qgb2YgdGhl IGNvZGUgYWxyZWFkeSBhc3N1bWVzIGZvciBhbiBJTy1BUElDIHdpdGgNCj4gbm8gaW5kZXgu DQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3Rh YmVsbGluaUBhbWQuY29tPg0KPiAtLS0NCj4gICB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h bWQvaW9tbXVfYWNwaS5jIHwgMSArDQo+ICAgMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9u KCspDQo+IA0KPiBkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lv bW11X2FjcGkuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9hY3BpLmMN Cj4gaW5kZXggMzlhZTYzNzk1OS4uNDY4ODkwODgyNCAxMDA2NDQNCj4gLS0tIGEveGVuL2Ry aXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2FjcGkuYw0KPiArKysgYi94ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfYWNwaS5jDQo+IEBAIC0xMTMyLDYgKzExMzIsNyBA QCBzdGF0aWMgaW50IF9faW5pdCBjZl9jaGVjayBwYXJzZV9pdnJzX3RhYmxlKHN0cnVjdCBh Y3BpX3RhYmxlX2hlYWRlciAqdGFibGUpDQo+ICAgICAgICAgICAgICAgICAgICAgIElPX0FQ SUNfSUQoYXBpYykpOw0KPiAgICAgICAgICAgICAgIGlmICggYW1kX2lvbW11X3BlcmRldl9p bnRyZW1hcCApDQo+ICAgICAgICAgICAgICAgICAgIHJldHVybiAtRU5YSU87DQo+ICsgICAg ICAgICAgICBjb250aW51ZTsNCj4gICAgICAgICAgIH0NCj4gICANCj4gICAgICAgICAgIC8q IFNCIElPLUFQSUMgaXMgYWx3YXlzIG9uIHRoaXMgZGV2aWNlIGluIEFNRCBzeXN0ZW1zLiAq Lw0KDQpSZXZpZXdlZC1ieTogVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+ DQoNClRlZGR5DQo= --------------goLJC7ouf9FFdUoMF6sRJw00-- --------------k01182ByWMU9bAS8EbtS6aFa 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+p0QLLz9AFAmrYfPgFAwAAAAAACgkQZg+p0QLLz9A8 Dgv8DDSsxntORH7jzmdnqC/1cv10TLAYrdiUWL0F/9zj/xsJT3nuA93xRMr/5CmD7jsbx2/0C5tA BlH6ulxcB0mlLhVivGEHjPV1KzHgFzkbvOFCItpXFr7k14V8jSJZeWTF0QhbcIyNjsgEX68r33qH aOcH1Ljs2Bmy0VGaa5J9IT+yGaqkUF30UqBHurCn4wGbow+0vb7PlXZB7tvFRueSGiuADE+C73Uy E7RgXZDqrzMw4f5UYnf9EOVAzY9TTEnbgJ9gXvWVowXzSKsOhyOMtgzQe68P712SblW1wmU+A9lO 4Af/UnXzLCFMQ1Ui0nk/2uauvE86KMLbOUakbv6IEFwL6EWDmc7OD7WLja6yMM8fptxrF2GsFK14 +k9OYsGl4+J1Qb/89qBOXw85zPvTn70/iVDvDvKsEpswI6vD0Yu0yuO+MFysAnvIj8vhPZZZTinp urSSf6Bb4R0PbWmLD9Linn+/Ppf/x6nRShHMb1BwlGcqhlHDURJS/AiXVz3B =Q9sK -----END PGP SIGNATURE----- --------------k01182ByWMU9bAS8EbtS6aFa-- From xen-devel-bounces@lists.xenproject.org Wed Oct 21 09:22:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 09:22:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456824.1669925 (Exim 4.92) (envelope-from ) id 1xJSW6-0002bh-5r; Wed, 21 Oct 2026 09:21:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456824.1669925; Wed, 21 Oct 2026 09:21: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 1xJSW6-0002ba-2k; Wed, 21 Oct 2026 09:21:50 +0000 Received: by outflank-mailman (input) for mailman id 1456824; Wed, 21 Oct 2026 09:21:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJSW4-0002bU-QB for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 09:21:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJSW3-00FwFn-TY for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 11:21:47 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad88425-bab6-0a2a0a5309dd-0a2a450a88fc-18 for ; Wed, 21 Oct 2026 11:21:47 +0200 Received: from [52.101.52.51] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8842a-f2d2-0a2a450a0019-34653433a2fa-4 for ; Wed, 21 Oct 2026 11:21:47 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by LV3PR03MB7357.namprd03.prod.outlook.com (2603:10b6:408:195::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Wed, 21 Oct 2026 09:21: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.0546.012; Wed, 21 Oct 2026 09:21: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=iVKTI+8SpbFrwmss/cDlULIjId7C1sUAcae4ZueQHn/QGn9aXgGNGoP9zeqTXUqJHC8RS6f7z4bZ3UdRHeUIDktNWEHQ/0fPNTGQNlvT1WSSvfrUqs/AS3SMxAyEj9nSHNQuek51Tmb0NNRM1wW+VgsZ00iAQikfLuW+r+CuC6x13cdEm8rp3b/FjSHRQZM3R7l/2OZIftd11vPFQbp28DQZUVmyTCdj53Vx6NrYhTtCw441occNrTpL4e5bLTaaTA+qw/BymZwWGrnqXrep43dq2pz6E+aKX26O9icOcHagc2cX/qkC8wKVFx4LS/xn/YJeoPScpp5ja6SMnhTzjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ecPqRTo6wtPnw6acd6o+so58GA5o9FPZgWSVeoey6Lk=; b=dpYRF4RtJw9C2jEHW3FY+ri6Z8IgKl9mnHYyOSAxqtMTlVLwYLAegUYe966WQ1a+Q0oYbDpcoInBmAKmIrbJ7BkSBcUQLXhlqtyKFGtjvTGneW4/cvy69wZNdV6q06BGv2l0DA96wA2oEdwx7cAK2KJYY7fB7Sar89DnGO4dAKYWoMHt/lKwaYKBFandCqHdcQVQEWxWXpUk1P8kwOCg8fcBNUMSW9VWqRLzo+L5U257Wlf8BbL4qoiLepRhSdAMjRA6FlpD4WhzGV5i0KMMRHpnI2XFKSM0ImPwvlnkNwOlMCzvvhDrtTT5KdJByBzivMhjXT1RW/KJh9M2tUqhbA== 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=ecPqRTo6wtPnw6acd6o+so58GA5o9FPZgWSVeoey6Lk=; b=l/nK7N4wA1wJ00mcRuXeo4F+a1itL52Tna7O4dgFFYJqOp7yN4f5XEOF5P89hNkwDwnkv2qV68Xz1WuoCRqLKoHdhdBrVen5BRlSFgoda79j29N4JeQRku5A/wWHTTVGj3pQM5S63vt2mgHqhWpaD0JaCfMutsb3oxxyoy+3SLA= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <44c485d8-1d57-4c59-9484-7c52303fbe2c@citrix.com> Date: Wed, 21 Oct 2026 10:21:38 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 26/30] x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from() To: George Dunlap , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-26-b68b66652266@xenproject.org> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <20261019-asi-hvm-v4-26-b68b66652266@xenproject.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PA7P264CA0458.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:398::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_|LV3PR03MB7357:EE_ X-MS-Office365-Filtering-Correlation-Id: 4304f646-7847-4534-1549-08df2f54b90f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|4143699003|11063799006|261009223027099003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: I3Tpby8pKqE/xOO4FQlqeX6PEgE2Zj5084Dm/JcMi147o4ni4PULB1Ju6VFzRO/x5qJRbj/k8Ej5gU6KEm0HuUJtyRixX0yA9xooTn3FZys2fXjg3r74U2RKi36lUGiabNCZAAHsnFJ6CFRbzwuTzDP1gBGjOUb6IaYbJt2ZJYIGOqOcFO8CxvZLkmiwFbSo0vUrf0X5iTGwfVcwfV1mRFbBmQFEME9fKOnYhEB24Qr/1Jf6FHQClKuA76Y4ogo03gUsU4xN6E13jN9sjRpYyIu3rYwoH3SGNIs1MspjmSP2mMxcpC3CoPa/xp53zXIwZ83NjsxNMwt2FzGYaYxxMJ4FINjEsyvx+tqiZ12c7nOburlYYuBcLWdaKlU2ExGBkZs4lP/J3XoCZtdXxqyy5e9r3W6sRL/XTJ8u7wvrLTBhhTE/XXELllRzUhnCmDHd5+GGiWx0mKr4mfzqzDfeTgbaNIX9Cp6njihZmBTmGpCKcoy0cTPUsmvEsX7alPAboy74MFK7wJc1LGkFoaxQrKaaktQRNTd0PiPcRHLQp2y8fWART2fIIh3jZM8W0OmF6vbjK6OSqXFGG1Vyn3Tg5B4xHTVT1ipc2FTw00JS9u0aqTGODHPuGdNXF8g3gSRwe23OLybDqZuKbMO3pyl3GwTsvIT9aixppnKrliz1HsM= 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)(376014)(23010399003)(56012099006)(4143699003)(11063799006)(261009223027099003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SXhPY2Y1OGRyU21aUFhpM3cyMFZwMWtibmJhbFF1ZkNxbkVmTjdVSW5jV0V4?= =?utf-8?B?bTRTNXZEM3BTWkZIbFVCcmZOOFN0bCtkZ2w4R2VtamliN1hNdFpkMk5lNTZL?= =?utf-8?B?OFV5c3pBQ3Awa1gva2VSR2Fya3dQTjFYSFFJZnVFWWZuTmtrbzZadmR1WVQw?= =?utf-8?B?cE80Ry92Y2xVUXFLWlU4cEpKS0xxZHUrU1FEMWd3bG8rU21zTEdObXBnZk9r?= =?utf-8?B?UWhWSzNUV25hTFMrZDNQdWcxMWpDNWVTLzVEZ2tXMjRnQkkrYnlubjMxQjZZ?= =?utf-8?B?Q0ZTa1VDSGpLdTI0QWNha2dXczFOMzh6eUF3dTRTSFVNVmtsNjdZOWhjWlkx?= =?utf-8?B?bnNIeFpNVndBK0FLdE1VWGZaNkh1alkxbVpJclMzWFowMjVuZWtvWWpva1ZC?= =?utf-8?B?UDJWS25oSTI4WkMrT3hGajdPbFZGTXBqWmJ0UC9aRlp1SWswU3FyNWUyMU1q?= =?utf-8?B?NFNrVGd4QlVONWd1eWZaWnFVQUowamhRRlZYZ3NpREh1VWFSTmNLeFlVZWlN?= =?utf-8?B?dExHazNVbWxxTXUvQlBwamxBdWxvNldDS1h5SG9qZjZvb09JT1BrQUdrTXhs?= =?utf-8?B?RzgxbWhyaHN1bkIyOW5TbzAvdFhTYWc5bzhBYXhBakM5NXBKZWJndkFkdHhJ?= =?utf-8?B?dzVHWEo2UVFGR0ZoTkJKcGdxblQzT2JqRVUwejNQNVAxbWc3U0hOTmpIR09n?= =?utf-8?B?M3NPUFFyYWN1dGFMMHd3aGtrMFVPbzRHNlVVRWFyYWhpb3UrVXhGOVFmV3NJ?= =?utf-8?B?ejdjUlM2WERpNTZzbzJVdDFkLy95Z1ZQbjJPVlVzOTNYclF2T2FxVWVhVXJ1?= =?utf-8?B?eXRmMjVadVlSV1ozQXE4bCtCY3lwSHhKdzh0WEhwRFZQUXB6c3dlR3pJd3Zr?= =?utf-8?B?Mlo1L0lTSCs4SW5SNDRRVUlIVFZLUTlBUkdPYmpkcVJGcGFJTXRqQ29BNmZ1?= =?utf-8?B?V3lxWFcrU2hnTGRmRjM1UG9qV2ZSOWV1MkJQcUl5NlhPTXFJcjVtK0w0U21R?= =?utf-8?B?azhDcUNJSjRlb3lMVyszeW1iTWxqV1E0Vy9aQU5VT0pMRU9HaGE0blQyeUZX?= =?utf-8?B?eitEQmJTVjVTeWlxVVdqNWt1SGluWmJkVjlLeTdETWVjZUVIK0xxVUJVdVlX?= =?utf-8?B?SVNXYXhaY05QcG1SdUpqNDJqdmV6MzJaY0p2dm1RU0N0MTcxL20vaGxsb1JJ?= =?utf-8?B?N1BRMmFHWlpOQXBVb1ZWVDNkc0NLRm1zRElDTFRmbTRUbG4zekZaRSt4MG53?= =?utf-8?B?YTFhYXhHTGZEWk9XMm85NlZMMnpVdnpXMlhwNUpBdU5KUTVRV3k2OWQ4UTll?= =?utf-8?B?eExFMTMyTzAxU0xSU3gwZkQ0R3B4QjMvNmlFdlhsd0QrWlRJTzlNcGdWWnhl?= =?utf-8?B?VVhsdStKaVhXZ2Vsd1k1d2ZRVDBzNzJnbys4MXVwbXQxNE9UUGZFc2dvTEZ5?= =?utf-8?B?UjU1a3U3dmpVUTJkcnZRU3UweEdmVm9yY2RzY3JualBxL3RBY01wK2ZvNkNO?= =?utf-8?B?YXpxRE5qaTBYT3hRWEE0VldQM1RCdVhRRFZLdnVaOGswZ3d5Y0daSEQ5Zm9j?= =?utf-8?B?VVl3ak0vSWNaM2ROWjZ2SkN4VUl0VG9SS0R5aG0yaU9RYVp0dC93eVZCYllQ?= =?utf-8?B?WTVLSHhtL2dmZzlYT3RkUVdSSXpIOExrSkRBS2FLVGE2ZXB1RW9Gb0NVcDNs?= =?utf-8?B?M3grMG5wZUxoL3NUbytOQ242bzRuVXM5MVZpRVlPS1ZyQVdnR0Q3VkRINHRi?= =?utf-8?B?TG5xVGsxL1htelB2eGcrOEkyVDlrK2grWDJsSU1xd3NqUlppZzdyU29vd0RI?= =?utf-8?B?ZXIyeEpyeVJLd0VXK3ExU0wwRWl1N2Qvb0R6WTkvUEJXTzdCSnhWTE5vU3Bw?= =?utf-8?B?UG81OE9XVTVRdUtSdGt0bThvWXBpZ2RzL2xFTXVScGF4blVsNW1RTFl1aUl1?= =?utf-8?B?L3JMdDQzWWxlZkJnZHR6QzI4M0ZzT0tKaUpNN045WExveE9Yckh4UjBMc1RC?= =?utf-8?B?Y3hsc29wUDJaNXJ4d3RMdUxiTFZYdXBabVVqWGdmbTBjSzhUT3VvcDlSQVEw?= =?utf-8?B?cWJ3WlQ4SndBbU5xTTlYVEJVS1U2Yk0vU1hGTUQrUExNelVUekk1U2ZRamNs?= =?utf-8?B?TktPTmMzQjRqcWlzWSt5cTNteWFTZHZTdXBEQnNjS1BhRFNLTXA2Z2JteUFZ?= =?utf-8?B?d1FXOEhOZWRlWExKSTFERlpTQkd5SkFNYzVQT2kvTXVGOStIcFdWdmg5aWpY?= =?utf-8?B?aDB2R1NqQ2NrL2VBSGFLYW4rZTBHVjcxRlROb053MVJrbDBKeW9zVmd2cUIy?= =?utf-8?B?d3FLbEtCWjZBeEd2SStmWEE2alMyUFczUExUOWttWExmSW1XcXg3N09sYlNs?= =?utf-8?Q?12Kfn+xIVB/ELSkw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4304f646-7847-4534-1549-08df2f54b90f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 09:21:44.0134 (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: KnWkCiE9h2mqksQFGuoswqw0LTL8Tas6LHdKsX/ejoCb0FGgewmkV6hnebcENJDPxvuWzm1YF/81uCC3B6Nt4ewOO+WXBK7WZ6KGYjMa/sY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7357 X-purgate-ID: tlsNG-4011c0/1792574507-5A7DACFC-052C5044/0/0 X-purgate-type: clean X-purgate-size: 2384 On 10/19/26 8:42 PM, George Dunlap wrote: > A VMCB's clean bits must all be clear when its vCPU next runs after a > deschedule, as other VMCBs run on the pCPU in the meantime. > svm_ctxt_switch_to() clears them as the vCPU is scheduled in; clear them > in svm_ctxt_switch_from() instead, as it is scheduled out. > > This is equivalent. While the vCPU is descheduled, accessors reaching > its VMCB only ever clear clean bits: svm_vmexit_handler(), which sets > them all, runs only in the vCPU's own context. So do the nested-SVM > paths that change the active VMCB, nsvm_vcpu_hostrestore() and > nsvm_vcpu_vmentry(), and they clear the incoming VMCB's clean bits > themselves. > > This prepares for moving VMCBs off always-mapped memory: > svm_ctxt_switch_to() runs before write_ptbase(), where the incoming > vCPU's VMCB will not be mapped. > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap > --- > Changes in v4: > - New in this version. > --- > xen/arch/x86/hvm/svm/svm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 241843d8c0..4e19df9865 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -919,6 +919,8 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v) > svm_save_dr(v); > svm_tsc_ratio_save(v); > > + v->arch.hvm.svm.vmcb->cleanbits.raw = 0; > + > svm_sync_vmcb(v, vmcb_needs_vmload); > svm_vmload_pa(per_cpu(host_vmcb, cpu)); > > @@ -938,7 +940,6 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v) > > static void cf_check svm_ctxt_switch_to(struct vcpu *v) > { > - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; > int cpu = smp_processor_id(); > > /* > @@ -956,7 +957,6 @@ static void cf_check svm_ctxt_switch_to(struct vcpu *v) > > svm_restore_dr(v); > > - vmcb->cleanbits.raw = 0; > svm_tsc_ratio_load(v); > > if ( cpu_has_msr_tsc_aux ) FYI I posted "x86/svm: Don't clear clean bits on every context switch" a few weeks ago which moves it into svm_do_resume(). I think that is preferable for the reasons mentioned in the patch and IIUC would still be after the vCPU's VMCB is mapped. Ross From xen-devel-bounces@lists.xenproject.org Wed Oct 21 09:30:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 09:30:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456836.1669934 (Exim 4.92) (envelope-from ) id 1xJSer-0004Mo-Uo; Wed, 21 Oct 2026 09:30:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456836.1669934; Wed, 21 Oct 2026 09:30: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 1xJSer-0004Mh-SK; Wed, 21 Oct 2026 09:30:53 +0000 Received: by outflank-mailman (input) for mailman id 1456836; Wed, 21 Oct 2026 09:30:52 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJSep-0004Mb-WF for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 09:30:52 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xJSep-00000005Vfx-3cna; Wed, 21 Oct 2026 09:30: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.98.2) (envelope-from ) id 1xJSep-0000000DYRo-2Bi3; Wed, 21 Oct 2026 09:30: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=ANSkhbGG3Wb0xxus9wuO0harqyiYcR3OVYnLfX7PjO4=; b=1QaOjwqQ8Op4aj7HwkZEPd4S6/ LWwQyefxgKXSwmyytSYt3VgW0DUWPhT2FTXBjdWhimOSv7xdISEBLcjBh9em0m63vxZ8Vv3JzyBEy SppM8G19Uznt1adhdwvxSRbgcksdi/r8fUEDt1/TYcBw+zRAULfKt3bgafO+1Y0AP2Bk=; Date: Wed, 21 Oct 2026 11:30:48 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: [PATCH] x86/bzimage: Check that the payload lies within the image Message-ID: References: <20261020214825.3655848-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261020214825.3655848-1-stefano.stabellini@amd.com> On Tue, Oct 20, 2026 at 02:48:25PM -0700, Stefano Stabellini wrote: > bzimage_check() doesn't validate setup_sects, payload_offset or > payload_length against the image size. A truncated or malformed bzImage > therefore makes bzimage_headroom() and bzimage_parse() read beyond the > end of the boot module, which shows up as a fatal page fault, a bogus > headroom, or a decompression failure, rather than as a bad image. > > Reject such a header up front. bzimage_parse() passes bzimage_check() a > length which includes the decompression headroom in front of the image, > so subtract it to check against the image alone. > > Signed-off-by: Stefano Stabellini > --- > xen/arch/x86/bzimage.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c > index 66f648f311..a5c48755b6 100644 > --- a/xen/arch/x86/bzimage.c > +++ b/xen/arch/x86/bzimage.c > @@ -54,6 +54,8 @@ struct __packed setup_header { > > static __init int bzimage_check(struct setup_header *hdr, unsigned long len) > { > + unsigned long payload_start; > + > if ( len < sizeof(struct setup_header) ) > return 0; > > @@ -65,6 +67,15 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) > hdr->version >> 8, hdr->version & 0xff); > return -EINVAL; > } > + > + payload_start = (hdr->setup_sects + 1) * 512UL + hdr->payload_offset; Do you really need the UL, doesn't it get auto-promoted to unsigned long already? If there's some issue with the types, that requires the calculation to be promoted top unsigned long, the other instances of this calculation should also be adjusted. > + if ( payload_start > len || hdr->payload_length > len - payload_start ) > + { > + printk("bzImage payload %#x@%#lx exceeds the %#lx byte image\n", Maybe best wqorded as: "... payload XXX past the image size (%#lx)" I think the "byte image" wording is not very clear IMO. > + hdr->payload_length, payload_start, len); > + return -EINVAL; > + } > + > return 1; > } > > @@ -107,7 +118,8 @@ int __init bzimage_parse(void *image_base, void **image_start, > unsigned long *image_len) > { > struct setup_header *hdr = (struct setup_header *)(*image_start); > - int err = bzimage_check(hdr, *image_len); > + /* *image_len also counts the headroom ahead of *image_start. */ IMO you can remove the dereferences from the variable names, it just makes the comment harder to reads for no real benefit, readers already know by context you are referencing the contents, not the pointer address. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 21 10:39:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 10:39:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456487.1669955 (Exim 4.92) (envelope-from ) id 1xJTj9-0004bJ-6n; Wed, 21 Oct 2026 10:39:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456487.1669955; Wed, 21 Oct 2026 10:39: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 1xJTj9-0004Zx-0L; Wed, 21 Oct 2026 10:39:23 +0000 Received: by outflank-mailman (input) for mailman id 1456487; Tue, 20 Oct 2026 20:30:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJGTM-0002LY-GM for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:30:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJGTL-001E3H-TS for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:30:11 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7cf50-8faa-0a2a0a5109dd-0a2a4509c7dc-4 for ; Tue, 20 Oct 2026 22:30:11 +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 6ad7cf51-be1a-0a2a45090019-94a39c016b4c-3 for ; Tue, 20 Oct 2026 22:30:11 +0200 Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69KHE4cV3176043; Tue, 20 Oct 2026 20:28:59 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 4hdw58n91k-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 20 Oct 2026 20:28:59 +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 69KKOc4J1753723; Tue, 20 Oct 2026 20:28:57 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([172.16.1.71]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4he7bs2390-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2026 20:28:57 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (smtpav05.wdc07v.mail.ibm.com [10.39.53.232]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 69KKSu7F26542802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Oct 2026 20:28:56 GMT Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AF0B58059; Tue, 20 Oct 2026 20:28:56 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 39C1758053; Tue, 20 Oct 2026 20:28:49 +0000 (GMT) Received: from mambor8.rchland.ibm.com (unknown [9.10.239.198]) by smtpav05.wdc07v.mail.ibm.com (Postfix) with ESMTP; Tue, 20 Oct 2026 20:28:49 +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:Reply-To: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:reply-to:subject:to; s=pp1; bh=Pbg2OFXa34DEIIHpJyaCulmgUfbxOrfxEkZAKRhMex4=; b=gryBQiZpYaYe +rscbtJOMUMGzJILaO9bxcqwAzLIOX+j60zcXWH7tKvp08o40WoTpUGVyLoqWjGF ZkUPXLwP8RwgFXaLLDWNzTKj3ap3mJdD1BO/1HXfs1dYuHwb9rWeRqt8GowmS644 50UL+brNoroymAw4we0HPjTOmE1wcH9sGecmJN6hvUF49OvQ80slVcDAhqxSmPlQ hSAB89mjuxAM4Xy/czGuXpXvp+9ip0/G8lAJ8i3S+uKSjmnkBnAPhxEv9O4Zujz+ n5IQ9SrRLVR2AI3cmiOziLyzdt3R0G+SY7SZNguBEHE3h6jlPLu0ojoSEWc6Cwsc weZZ1xQpeA== Message-ID: <9623e038a99fbaa32f3b674335b717aaac28a9b7.camel@linux.ibm.com> Subject: Re: [PATCH v7 48/65] hw/gpio/pca955x: use QAPI enums for led and pin properties From: Miles Glenn Reply-To: milesg@linux.ibm.com To: =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau , qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , "Daniel P." =?ISO-8859-1?Q?Berrang=E9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?ISO-8859-1?Q?Mathieu-Daud=E9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?ISO-8859-1?Q?C=E9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?ISO-8859-1?Q?C=E9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Date: Tue, 20 Oct 2026 15:28:48 -0500 In-Reply-To: <20261020-qom-qapi-v7-48-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-48-431a86b02b58@redhat.com> Organization: IBM Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-27.el8_10) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-GUID: zeP-fO0kgTLfU0Y4FkkqqLfDzxwqTXh5 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDIwMDA4MCBTYWx0ZWRfX6vfHkSoMpOMs YG6m3cwWZurqaQTfQ06m6A87TuTTul77BsxxpqVfk7/ATEX9h6WKuwqRT/72WjhQ8O8yk8Luwp1 FB5Ay7YFmD1mRNK9GZcgSc8Q0Lx0ZGY= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDIwMDA4MCBTYWx0ZWRfX9kRKfuj7A4SJ K9FDhbZFwvRvTu+zu+AUckEi7IUDpkeOkAxQG5EDDCYy1/KE+MjPjypIdZwGcYwvWUSsZlTT3Hs OS/5Rckuuyqz0WFf3/DT3VutTV8HYQxhhgX3BRAvLyAfUlSpUSoN46ARWU00weGvTBrTH0QVn6M f5BizkR9cgDKb6gs0r9w+CCssIXoozjlupXcpp86spzc+8ttVskw6c2VUWh+BzRhz4U4Mx3VlQ0 0Kv86A3V9fDyudePBjJF7gIaUM/dHlXw8Sr2AJP/+jKQ0qqYkQ0g+u/QWWz12lHn/bzpPAxZFjG AedC/6g+TSzwYyFxM4iBjOm0qwmLNOCRV3Ez0qRFHApXLqXwg7ZYb21jwawLvarH+Leoidgy90B BCb4tUDdKKNkJ1MZHfFMDAApPElWmkq+fGTsOrBRzkbwtym0VD72/vYSvL0af3w6SqxRLV4BY74 LRLyPLMPa1F6e9MaJTw== X-Proofpoint-ORIG-GUID: t2DQFQv3F5Q70YKOMQrzHUpg36aEx9RI X-Authority-Analysis: v=2.4 cv=Ob4NnRTY c=1 sm=1 tr=0 ts=6ad7cf0b cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=VnNF1IyMAAAA:8 a=20KFwNOVAAAA:8 a=HV9-su-gHPMe9Pw3G_AA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA: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-10-20_03,2026-10-19_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 phishscore=0 spamscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1011 impostorscore=0 priorityscore=1501 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610200080 X-purgate-ID: tlsNG-bad1c0/1792528211-FDC6D034-729D452F/0/0 X-purgate-type: clean X-purgate-size: 15981 Reviewed-by: Glenn Miles Thanks, Glenn On Tue, 2026-10-20 at 14:46 +0400, Marc-André Lureau wrote: > Replace hand-rolled string lookup tables with QAPI enums > Pca9552LedState and Pca955{2,4}PinState for the led%d and pin%d QOM > properties. This fixes the incorrect property type ("bool" for LEDs, > "str" for pins) and lets QAPI handle string-to-enum conversion in the > visitor, removing the manual string matching in the setters. > > Add QEMU_BUILD_BUG_ON guards to ensure the QAPI-generated enum values > stay in sync with the hardware register encoding. > > I kept Pca9552PinState & @Pca9554PinState separate types, because I > don't know if they could diverge. We could eventually merge those. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-André Lureau > --- > hw/gpio/pca9552.c | 82 +++++++++++++++++++++---------------------------------- > hw/gpio/pca9554.c | 39 ++++++++++---------------- > qapi/machine.json | 46 +++++++++++++++++++++++++++++++ > 3 files changed, 92 insertions(+), 75 deletions(-) > > diff --git a/hw/gpio/pca9552.c b/hw/gpio/pca9552.c > index 719149b7174b..16741c22dea3 100644 > --- a/hw/gpio/pca9552.c > +++ b/hw/gpio/pca9552.c > @@ -23,7 +23,8 @@ > #include "hw/core/irq.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > -#include "qapi/visitor.h" > +#include "qapi/qapi-types-machine.h" > +#include "qapi/qapi-visit-machine.h" > #include "trace.h" > #include "qom/object.h" > > @@ -59,16 +60,15 @@ struct PCA955xClass { > /* > * Note: The LED_ON and LED_OFF configuration values for the PCA955X > * chips are the reverse of the PCA953X family of chips. > + * > + * The QAPI enums must match the hardware register values. > */ > -#define PCA9552_LED_ON 0x0 > -#define PCA9552_LED_OFF 0x1 > -#define PCA9552_LED_PWM0 0x2 > -#define PCA9552_LED_PWM1 0x3 > -#define PCA9552_PIN_LOW 0x0 > -#define PCA9552_PIN_HIZ 0x1 > - > -static const char *led_state[] = {"on", "off", "pwm0", "pwm1"}; > -static const char *pin_state[] = {"low", "high"}; > +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_ON != 0x0); > +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_OFF != 0x1); > +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_PWM0 != 0x2); > +QEMU_BUILD_BUG_ON(PCA9552_LED_STATE_PWM1 != 0x3); > +QEMU_BUILD_BUG_ON(PCA9552_PIN_STATE_LOW != 0x0); > +QEMU_BUILD_BUG_ON(PCA9552_PIN_STATE_HIGH != 0x1); > > static uint8_t pca955x_pin_get_config(PCA955xState *s, int pin) > { > @@ -142,24 +142,24 @@ static void pca955x_update_pin_input(PCA955xState *s) > uint8_t config = pca955x_pin_get_config(s, i); > > switch (config) { > - case PCA9552_LED_ON: > + case PCA9552_LED_STATE_ON: > /* Pin is set to 0V to turn on LED */ > s->regs[input_reg] &= ~bit_mask; > break; > - case PCA9552_LED_OFF: > + case PCA9552_LED_STATE_OFF: > /* > * Pin is set to Hi-Z to turn off LED and > * pullup sets it to a logical 1 unless > * external device drives it low. > */ > - if (s->ext_state[i] == PCA9552_PIN_LOW) { > + if (s->ext_state[i] == PCA9552_PIN_STATE_LOW) { > s->regs[input_reg] &= ~bit_mask; > } else { > s->regs[input_reg] |= bit_mask; > } > break; > - case PCA9552_LED_PWM0: > - case PCA9552_LED_PWM1: > + case PCA9552_LED_STATE_PWM0: > + case PCA9552_LED_STATE_PWM1: > /* TODO */ > default: > break; > @@ -176,7 +176,7 @@ static void pca955x_update_pin_input(PCA955xState *s) > */ > if (s->regs[config_reg] & bit_mask) { > /* Input mode - reflect external state */ > - if (s->ext_state[i] == PCA9552_PIN_LOW) { > + if (s->ext_state[i] == PCA9552_PIN_STATE_LOW) { > s->regs[input_reg] &= ~bit_mask; > } else { > s->regs[input_reg] |= bit_mask; > @@ -360,7 +360,7 @@ static void pca955x_get_led(Object *obj, Visitor *v, const char *name, > PCA955xClass *k = PCA955X_GET_CLASS(obj); > PCA955xState *s = PCA955X(obj); > int led, rc, reg; > - uint8_t state; > + Pca9552LedState state; > > rc = sscanf(name, "led%2d", &led); > if (rc != 1) { > @@ -378,7 +378,7 @@ static void pca955x_get_led(Object *obj, Visitor *v, const char *name, > */ > reg = PCA9552_LS0 + led / 4; > state = (pca955x_read(s, reg) >> ((led % 4) * 2)) & 0x3; > - visit_type_str(v, name, (char **)&led_state[state], errp); > + visit_type_Pca9552LedState(v, name, &state, errp); > } > > /* > @@ -397,10 +397,9 @@ static void pca955x_set_led(Object *obj, Visitor *v, const char *name, > PCA955xClass *k = PCA955X_GET_CLASS(obj); > PCA955xState *s = PCA955X(obj); > int led, rc, reg, val; > - uint8_t state; > - g_autofree char *state_str = NULL; > + Pca9552LedState state; > > - if (!visit_type_str(v, name, &state_str, errp)) { > + if (!visit_type_Pca9552LedState(v, name, &state, errp)) { > return; > } > rc = sscanf(name, "led%2d", &led); > @@ -413,16 +412,6 @@ static void pca955x_set_led(Object *obj, Visitor *v, const char *name, > return; > } > > - for (state = 0; state < ARRAY_SIZE(led_state); state++) { > - if (!strcmp(state_str, led_state[state])) { > - break; > - } > - } > - if (state >= ARRAY_SIZE(led_state)) { > - error_setg(errp, "%s invalid led state %s", __func__, state_str); > - return; > - } > - > reg = PCA9552_LS0 + led / 4; > val = pca955x_read(s, reg); > val = pca955x_ledsel(val, led % 4, state); > @@ -437,7 +426,8 @@ static void pca955x_get_pin(Object *obj, Visitor *v, const char *name, > PCA955xClass *k = PCA955X_GET_CLASS(obj); > PCA955xState *s = PCA955X(obj); > int pin, rc; > - uint8_t input_reg, state; > + uint8_t input_reg; > + Pca9552PinState state; > > rc = sscanf(name, "pin%2d", &pin); > if (rc != 1) { > @@ -455,7 +445,7 @@ static void pca955x_get_pin(Object *obj, Visitor *v, const char *name, > */ > input_reg = PCA9535_INPUT0 + (pin / 8); > state = (s->regs[input_reg] >> (pin % 8)) & 0x1; > - visit_type_str(v, name, (char **)&pin_state[state], errp); > + visit_type_Pca9552PinState(v, name, &state, errp); > } > > static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, > @@ -464,10 +454,10 @@ static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, > PCA955xClass *k = PCA955X_GET_CLASS(obj); > PCA955xState *s = PCA955X(obj); > int pin, rc; > - uint8_t state, config_reg; > - g_autofree char *state_str = NULL; > + Pca9552PinState state; > + uint8_t config_reg; > > - if (!visit_type_str(v, name, &state_str, errp)) { > + if (!visit_type_Pca9552PinState(v, name, &state, errp)) { > return; > } > rc = sscanf(name, "pin%2d", &pin); > @@ -480,16 +470,6 @@ static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, > return; > } > > - for (state = 0; state < ARRAY_SIZE(pin_state); state++) { > - if (!strcmp(state_str, pin_state[state])) { > - break; > - } > - } > - if (state >= ARRAY_SIZE(pin_state)) { > - error_setg(errp, "%s invalid pin state %s", __func__, state_str); > - return; > - } > - > /* Only input-configured pins can be driven by an external device. */ > config_reg = PCA9535_CONFIG0 + (pin / 8); > if (!((s->regs[config_reg] >> (pin % 8)) & 0x1)) { > @@ -499,7 +479,7 @@ static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, > return; > } > > - pca955x_set_ext_state(s, pin, state != PCA9552_PIN_LOW); > + pca955x_set_ext_state(s, pin, state != PCA9552_PIN_STATE_LOW); > } > > static const VMStateDescription pca9552_vmstate = { > @@ -529,7 +509,7 @@ static void pca9552_reset_hold(Object *obj, ResetType type) > s->regs[PCA9552_LS2] = 0x55; > s->regs[PCA9552_LS3] = 0x55; > > - memset(s->ext_state, PCA9552_PIN_HIZ, PCA955X_PIN_COUNT_MAX); > + memset(s->ext_state, PCA9552_PIN_STATE_HIGH, PCA955X_PIN_COUNT_MAX); > pca955x_update_pin_input(s); > > s->pointer = 0xFF; > @@ -549,7 +529,7 @@ static void pca9535_reset_hold(Object *obj, ResetType type) > s->regs[PCA9535_CONFIG0] = 0xFF; /* All pins as inputs */ > s->regs[PCA9535_CONFIG1] = 0xFF; /* All pins as inputs */ > > - memset(s->ext_state, PCA9552_PIN_HIZ, PCA955X_PIN_COUNT_MAX); > + memset(s->ext_state, PCA9552_PIN_STATE_HIGH, PCA955X_PIN_COUNT_MAX); > pca955x_update_pin_input(s); > > s->pointer = 0xFF; > @@ -567,12 +547,12 @@ static void pca955x_initfn(Object *obj) > if (k->has_led_support) { > /* LED variant: expose the LED selector state as led%d. */ > name = g_strdup_printf("led%d", ix); > - object_property_add(obj, name, "bool", > + object_property_add(obj, name, "Pca9552LedState", > pca955x_get_led, pca955x_set_led, NULL, NULL); > } else { > /* GPIO variant: expose the pin logic level as pin%d. */ > name = g_strdup_printf("pin%d", ix); > - object_property_add(obj, name, "str", > + object_property_add(obj, name, "Pca9552PinState", > pca955x_get_pin, pca955x_set_pin, NULL, NULL); > } > g_free(name); > diff --git a/hw/gpio/pca9554.c b/hw/gpio/pca9554.c > index 904698cdce85..e4eddc829ef7 100644 > --- a/hw/gpio/pca9554.c > +++ b/hw/gpio/pca9554.c > @@ -16,6 +16,8 @@ > #include "hw/core/irq.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-types-machine.h" > +#include "qapi/qapi-visit-machine.h" > #include "qapi/visitor.h" > #include "trace.h" > #include "qom/object.h" > @@ -32,10 +34,8 @@ typedef struct PCA9554Class PCA9554Class; > DECLARE_CLASS_CHECKERS(PCA9554Class, PCA9554, > TYPE_PCA9554) > > -#define PCA9554_PIN_LOW 0x0 > -#define PCA9554_PIN_HIZ 0x1 > - > -static const char *pin_state[] = {"low", "high"}; > +QEMU_BUILD_BUG_ON(PCA9554_PIN_STATE_LOW != 0x0); > +QEMU_BUILD_BUG_ON(PCA9554_PIN_STATE_HIGH != 0x1); > > static void pca9554_update_pin_input(PCA9554State *s) > { > @@ -54,7 +54,7 @@ static void pca9554_update_pin_input(PCA9554State *s) > * Input: the pin is Hi-Z with a pull-up, so it reads high > * unless an external device drives it low. > */ > - if (s->ext_state[i] == PCA9554_PIN_LOW) { > + if (s->ext_state[i] == PCA9554_PIN_STATE_LOW) { > s->regs[PCA9554_INPUT] &= ~bit_mask; > } else { > s->regs[PCA9554_INPUT] |= bit_mask; > @@ -156,7 +156,7 @@ static void pca9554_get_pin(Object *obj, Visitor *v, const char *name, > { > PCA9554State *s = PCA9554(obj); > int pin, rc; > - uint8_t state; > + Pca9554PinState state; > > rc = sscanf(name, "pin%2d", &pin); > if (rc != 1) { > @@ -175,7 +175,7 @@ static void pca9554_get_pin(Object *obj, Visitor *v, const char *name, > * holds the wire level regardless of the configured direction. > */ > state = (s->regs[PCA9554_INPUT] >> pin) & 0x1; > - visit_type_str(v, name, (char **)&pin_state[state], errp); > + visit_type_Pca9554PinState(v, name, &state, errp); > } > > static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, > @@ -183,10 +183,10 @@ static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, > { > PCA9554State *s = PCA9554(obj); > int pin, rc, val; > - uint8_t state, mask; > - g_autofree char *state_str = NULL; > + uint8_t mask; > + Pca9554PinState state; > > - if (!visit_type_str(v, name, &state_str, errp)) { > + if (!visit_type_Pca9554PinState(v, name, &state, errp)) { > return; > } > rc = sscanf(name, "pin%2d", &pin); > @@ -199,16 +199,6 @@ static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, > return; > } > > - for (state = 0; state < ARRAY_SIZE(pin_state); state++) { > - if (!strcmp(state_str, pin_state[state])) { > - break; > - } > - } > - if (state >= ARRAY_SIZE(pin_state)) { > - error_setg(errp, "%s invalid pin state %s", __func__, state_str); > - return; > - } > - > if (s->hw_dir) { > /* Warn and ignore if the guest has configured this pin as output */ > if (!((s->regs[PCA9554_CONFIG] >> pin) & 0x1)) { > @@ -219,13 +209,13 @@ static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, > return; > } > /* Drive the external input level */ > - pca9554_set_ext_state(s, pin, state != PCA9554_PIN_LOW); > + pca9554_set_ext_state(s, pin, state != PCA9554_PIN_STATE_LOW); > } else { > /* Legacy behavior: force output mode and drive */ > /* First, modify the output register bit */ > val = pca9554_read(s, PCA9554_OUTPUT); > mask = 0x1 << pin; > - if (state == PCA9554_PIN_LOW) { > + if (state == PCA9554_PIN_STATE_LOW) { > val &= ~(mask); > } else { > val |= mask; > @@ -264,7 +254,7 @@ static void pca9554_reset(DeviceState *dev) > s->regs[PCA9554_POLARITY] = 0x0; /* No pins are inverted */ > s->regs[PCA9554_CONFIG] = pin_mask; /* All pins are inputs */ > > - memset(s->ext_state, PCA9554_PIN_HIZ, pc->pin_count); > + memset(s->ext_state, PCA9554_PIN_STATE_HIGH, pc->pin_count); > pca9554_update_pin_input(s); > > s->pointer = 0x0; > @@ -280,7 +270,8 @@ static void pca9554_initfn(Object *obj) > char *name; > > name = g_strdup_printf("pin%d", pin); > - object_property_add(obj, name, "str", pca9554_get_pin, pca9554_set_pin, > + object_property_add(obj, name, "Pca9554PinState", > + pca9554_get_pin, pca9554_set_pin, > NULL, NULL); > g_free(name); > } > diff --git a/qapi/machine.json b/qapi/machine.json > index 34be3156270c..46b6935ab0b8 100644 > --- a/qapi/machine.json > +++ b/qapi/machine.json > @@ -416,6 +416,52 @@ > { 'enum': 'LostTickPolicy', > 'data': ['discard', 'delay', 'slew' ] } > > +## > +# @Pca9552LedState: > +# > +# LED state for PCA9552. > +# > +# @on: LED on > +# > +# @off: LED off > +# > +# @pwm0: LED controlled by PWM0 > +# > +# @pwm1: LED controlled by PWM1 > +# > +# Since: 11.2 > +## > +{ 'enum': 'Pca9552LedState', > + 'data': ['on', 'off', 'pwm0', 'pwm1'] } > + > +## > +# @Pca9552PinState: > +# > +# Pin state for PCA9552. > +# > +# @low: Pin low > +# > +# @high: Pin high > +# > +# Since: 11.2 > +## > +{ 'enum': 'Pca9552PinState', > + 'data': ['low', 'high'] } > + > +## > +# @Pca9554PinState: > +# > +# Pin state for PCA9554. > +# > +# @low: Pin low > +# > +# @high: Pin high > +# > +# Since: 11.2 > +## > +{ 'enum': 'Pca9554PinState', > + 'data': ['low', 'high'] } > + > ## > # @inject-nmi: > # Injects a Non-Maskable Interrupt (machine specific: for example > From xen-devel-bounces@lists.xenproject.org Wed Oct 21 10:39:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 10:39:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455855.1669949 (Exim 4.92) (envelope-from ) id 1xJTj8-0004Vs-TA; Wed, 21 Oct 2026 10:39:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455855.1669949; Wed, 21 Oct 2026 10:39: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 1xJTj8-0004Vk-PO; Wed, 21 Oct 2026 10:39:22 +0000 Received: by outflank-mailman (input) for mailman id 1455855; Tue, 20 Oct 2026 13:25:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ9qj-0002IX-Hw for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:25:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ9qi-00DKpW-Up for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:25:52 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad76bdd-e002-0a2a0a5209dd-0a2a450c9984-16 for ; Tue, 20 Oct 2026 15:25:52 +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 6ad76bdf-f479-0a2a450c0019-aa0a857c5e6d-3 for ; Tue, 20 Oct 2026 15:25: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-402-GpgImfhOMWa0lumUFG9c1g-1; Tue, 20 Oct 2026 13:25:47 +0000 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 D737F1800BDD; Tue, 20 Oct 2026 13:25:39 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EA9B818005B3; Tue, 20 Oct 2026 13:25:35 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 71D8121E6A04; Tue, 20 Oct 2026 15:25: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=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=1792502751; 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=A/2pHd+aS8DA34XJvVp3LyaeljRYqqdyzYtr5T0L1kw=; b=F+5RUplZlFA/aNN08lauJ+UTGkc6AiwT8Rx1h8d9T3ifJ58aVfPcVayvSNRZMCUnhODbYg ojZoObdiC1LiiZBmfEpepFwYikN8ckTkb45g8FCUcv1FGzqYmHbTWvqQqWrZc7UpAwNqLf h4uM8Apoh3gxxtZ0ZCNIUPVt+Ah7tDw= X-MC-Unique: GpgImfhOMWa0lumUFG9c1g-1 X-Mimecast-MFC-AGG-ID: GpgImfhOMWa0lumUFG9c1g_1792502743 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 43/65] qom: replace object_property_add_tm with StructTm QAPI type In-Reply-To: <20261020-qom-qapi-v7-43-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:46:00 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-43-431a86b02b58@redhat.com> Date: Tue, 20 Oct 2026 15:25:33 +0200 Message-ID: <874iegpkqa.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: W6Eqtq9_NUEoEzIQ7YdJHWxL2OWvy5TyfI6zkw9FnRQ_1792502743 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1792502752-01CC3A5B-04F31F7B/0/0 X-purgate-type: clean X-purgate-size: 9014 Marc-Andr=C3=A9 Lureau writes: > Define a StructTm QAPI struct in common.json matching the existing > "struct tm" property wire format (tm_year, tm_mon, tm_mday, tm_hour, > tm_min, tm_sec as int32). > > Convert the two callers (mc146818rtc and spapr_rtc) to use > object_property_add_qapi() with a standard ObjectPropertyAccessor > that populates a StructTm and calls the generated visitor. > > Remove object_property_add_tm(), object_class_property_add_tm(), > the TMProperty type, and the property_get_tm() helper from > qom/object.c, along with their declarations in object.h. > > Reviewed-by: Amit Machhiwal > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau > --- > hw/ppc/spapr_rtc.c | 24 +++++++++++++++--- > hw/rtc/mc146818rtc.c | 22 ++++++++++++++--- > include/qom/object.h | 29 ---------------------- > qapi/common.json | 28 +++++++++++++++++++++ > qapi/pragma.json | 1 + > qom/object.c | 69 ----------------------------------------------= ------ > 6 files changed, 69 insertions(+), 104 deletions(-) > > diff --git a/hw/ppc/spapr_rtc.c b/hw/ppc/spapr_rtc.c > index 1f7d2d8f898b..5105cf538f64 100644 > --- a/hw/ppc/spapr_rtc.c > +++ b/hw/ppc/spapr_rtc.c > @@ -33,6 +33,9 @@ > #include "migration/vmstate.h" > #include "qapi/error.h" > #include "qapi/qapi-events-misc.h" > +#include "qapi/qapi-type-infos-common.h" > +#include "qapi/qapi-visit-common.h" > +#include "qapi/visitor.h" > #include "qemu/cutils.h" > #include "qemu/module.h" > =20 > @@ -131,9 +134,23 @@ static void rtas_set_time_of_day(PowerPCCPU *cpu, Sp= aprMachineState *spapr, > rtas_st(rets, 0, RTAS_OUT_SUCCESS); > } > =20 > -static void spapr_rtc_qom_date(Object *obj, struct tm *current_tm, Error= **errp) > +static void spapr_rtc_qom_date(Object *obj, Visitor *v, const char *name= , > + void *opaque, Error **errp) > { > - spapr_rtc_read(SPAPR_RTC(obj), current_tm, NULL); > + struct tm value; > + StructTm tm, *tmp =3D &tm; > + > + spapr_rtc_read(SPAPR_RTC(obj), &value, NULL); > + > + tm =3D (StructTm) { > + .tm_year =3D value.tm_year, > + .tm_mon =3D value.tm_mon, > + .tm_mday =3D value.tm_mday, > + .tm_hour =3D value.tm_hour, > + .tm_min =3D value.tm_min, > + .tm_sec =3D value.tm_sec, > + }; > + visit_type_StructTm(v, name, &tmp, errp); > } > =20 > static void spapr_rtc_realize(DeviceState *dev, Error **errp) > @@ -150,7 +167,8 @@ static void spapr_rtc_realize(DeviceState *dev, Error= **errp) > rtc_ns =3D qemu_clock_get_ns(rtc_clock); > rtc->ns_offset =3D host_s * NANOSECONDS_PER_SECOND - rtc_ns; > =20 > - object_property_add_tm(OBJECT(rtc), "date", spapr_rtc_qom_date); > + object_property_add_qapi(OBJECT(rtc), "date", &StructTm_type_info, > + spapr_rtc_qom_date, NULL, NULL, NULL); The @type reported by qom-list & friends changes from "struct tm" (visible at the end of this patch) to to "StuctTm". Such changes can be compatibility breaks. Same "this is okay" argument as for the previous patch, and same request: please note the change in the commit message. > } > =20 > static const VMStateDescription vmstate_spapr_rtc =3D { > diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c > index ba396435d1af..6010f8587ce0 100644 > --- a/hw/rtc/mc146818rtc.c > +++ b/hw/rtc/mc146818rtc.c > @@ -42,6 +42,8 @@ > #include "migration/vmstate.h" > #include "qapi/error.h" > #include "qapi/qapi-events-misc.h" > +#include "qapi/qapi-type-infos-common.h" > +#include "qapi/qapi-visit-common.h" > #include "qapi/visitor.h" > #include "trace.h" > =20 > @@ -854,12 +856,25 @@ static const MemoryRegionOps cmos_ops =3D { > .endianness =3D DEVICE_LITTLE_ENDIAN, > }; > =20 > -static void rtc_get_date(Object *obj, struct tm *current_tm, Error **err= p) > +static void rtc_get_date(Object *obj, Visitor *v, const char *name, > + void *opaque, Error **errp) > { > MC146818RtcState *s =3D MC146818_RTC(obj); > + struct tm value; > + StructTm tm, *tmp =3D &tm; > =20 > rtc_update_time(s); > - rtc_get_time(s, current_tm); > + rtc_get_time(s, &value); > + > + tm =3D (StructTm) { > + .tm_year =3D value.tm_year, > + .tm_mon =3D value.tm_mon, > + .tm_mday =3D value.tm_mday, > + .tm_hour =3D value.tm_hour, > + .tm_min =3D value.tm_min, > + .tm_sec =3D value.tm_sec, > + }; > + visit_type_StructTm(v, name, &tmp, errp); > } > =20 > static void rtc_realizefn(DeviceState *dev, Error **errp) > @@ -1019,7 +1034,8 @@ static void rtc_class_initfn(ObjectClass *klass, co= nst void *data) > device_class_set_props(dc, mc146818rtc_properties); > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > =20 > - object_class_property_add_tm(klass, "date", rtc_get_date); > + object_class_property_add_qapi(klass, "date", &StructTm_type_info, > + rtc_get_date, NULL, NULL, NULL); > } > =20 > static const TypeInfo mc146818rtc_info =3D { > diff --git a/include/qom/object.h b/include/qom/object.h > index e04be4caed57..29cbd84b8d03 100644 > --- a/include/qom/object.h > +++ b/include/qom/object.h > @@ -2156,35 +2156,6 @@ object_class_property_add_qapi(ObjectClass *klass, > ObjectPropertyRelease *release, > void *opaque); > =20 > -/** > - * object_property_add_tm: > - * @obj: the object to add a property to > - * @name: the name of the property > - * @get: the getter or NULL if the property is write-only. > - * > - * Add a read-only struct tm valued property using a getter function. > - * This function will add a property of type 'struct tm'. > - * > - * Returns: The newly added property on success, or %NULL on failure. > - */ > -ObjectProperty *object_property_add_tm(Object *obj, const char *name, > - void (*get)(Object *, struct tm *, Error **)= ); > - > -/** > - * object_class_property_add_tm: > - * @klass: the object class to add a property to > - * @name: the name of the property > - * @get: the getter or NULL if the property is write-only. > - * > - * Add a read-only struct tm valued property using a getter function. > - * This function will add a property of type 'struct tm'. > - * > - * Returns: The newly added property on success, or %NULL on failure. > - */ > -ObjectProperty *object_class_property_add_tm(ObjectClass *klass, > - const char *name, > - void (*get)(Object *, struct tm *, Error **)= ); > - > typedef enum { > /* Automatically add a getter to the property */ > OBJ_PROP_FLAG_READ =3D 1 << 0, > diff --git a/qapi/common.json b/qapi/common.json > index 1352e664b23e..222037ea0b32 100644 > --- a/qapi/common.json > +++ b/qapi/common.json > @@ -218,3 +218,31 @@ > ## > { 'enum': 'EndianMode', > 'data': [ 'unspecified', 'little', 'big' ] } > + > +## > +# @StructTm: > +# > +# Broken-down time. Field semantics match C ``struct tm``. Again, please use the revised syntax for introductions. > +# > +# @tm_year: years since 1900 > +# > +# @tm_mon: months since January (0-11) > +# > +# @tm_mday: day of the month (1-31) > +# > +# @tm_hour: hours since midnight (0-23) > +# > +# @tm_min: minutes after the hour (0-59) > +# > +# @tm_sec: seconds after the minute (0-59, 60-61 for leap seconds) > +# > +# Since: 11.2 Same "do we care?" as for the previous patch. > +## > +{ 'struct': 'StructTm', > + 'data': { > + 'tm_year': 'int32', > + 'tm_mon': 'int32', > + 'tm_mday': 'int32', > + 'tm_hour': 'int32', > + 'tm_min': 'int32', > + 'tm_sec': 'int32' } } > diff --git a/qapi/pragma.json b/qapi/pragma.json > index 342cedc42e76..9be2819a46bd 100644 > --- a/qapi/pragma.json > +++ b/qapi/pragma.json > @@ -109,6 +109,7 @@ # Externally visible types whose member names may use uppercase Not this patch's fault, but here goes anyway: the comment should be "may use uppercase or '_'". I'll fix it. 'member-name-exceptions': [ # visible in: 'ACPISlotType', # query-acpi-ospm-status [...] > 'QKeyCode', # send-key, input-sent-event > 'QapiErrorClass', # QMP error replies > 'SshHostKeyCheckMode', # blockdev-add, -blockdev > + 'StructTm', # qom-get of RTC date property > 'SysEmuTarget', # query-cpu-fast, query-target > 'UuidInfo', # query-uuid > 'VncClientInfo', # query-vnc, query-vnc-servers, ... [...] From xen-devel-bounces@lists.xenproject.org Wed Oct 21 10:39:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 10:39:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1455829.1669944 (Exim 4.92) (envelope-from ) id 1xJTj8-0004TV-Kr; Wed, 21 Oct 2026 10:39:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1455829.1669944; Wed, 21 Oct 2026 10:39: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 1xJTj8-0004TO-HF; Wed, 21 Oct 2026 10:39:22 +0000 Received: by outflank-mailman (input) for mailman id 1455829; Tue, 20 Oct 2026 13:00:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJ9Rx-0007bx-G5 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 13:00:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJ9Rw-000FNz-RV for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 15:00:16 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad765df-bab6-0a2a0a5309dd-0a2a450be5bc-12 for ; Tue, 20 Oct 2026 15:00:16 +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 6ad765df-b7e8-0a2a450b0019-aa0a857c64d3-3 for ; Tue, 20 Oct 2026 15:00: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-394-SCYlsoeCN1mldLXfI2uYiQ-1; Tue, 20 Oct 2026 13:00:08 +0000 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id ABD0219539BD; Tue, 20 Oct 2026 13:00:00 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E085418002B1; Tue, 20 Oct 2026 12:59:56 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 65E3F21E6A04; Tue, 20 Oct 2026 14:59: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=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=1792501215; 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=IdGexhi468SGRjXz9icUeN0PDMP62iaPPGR0zWDcYQ8=; b=bezrBxu/Dm83yO7DO68W7ctUh7FzrtnWEmQwFFyai5kHpOmRvBUil8R/wjOn0u903d/NzG UqE3F4oNkls5MdGzBJqKfbzIA9Bz9N1UeKOqtgIqZkRm2z1SoJkAGzT17I6+q1Mo8pbxZc R0x4846lqG2krxiD9VmqTASfc2CmvmQ= X-MC-Unique: SCYlsoeCN1mldLXfI2uYiQ-1 X-Mimecast-MFC-AGG-ID: SCYlsoeCN1mldLXfI2uYiQ_1792501202 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 42/65] virtio-balloon: convert guest-stats property to QAPI type In-Reply-To: <20261020-qom-qapi-v7-42-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:45:59 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-42-431a86b02b58@redhat.com> Date: Tue, 20 Oct 2026 14:59:54 +0200 Message-ID: <87h5igplx1.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: ejCCdj6z0vmq38IcMMCUvFhyUrFTaiVIqncs1WNAsJ0_1792501202 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1792501216-A9EC69EA-E1C505C4/0/0 X-purgate-type: clean X-purgate-size: 13560 Marc-Andr=C3=A9 Lureau writes: > Define VirtioBalloonStats and VirtioBalloonGuestStats QAPI struct types > in the schema, replacing the hand-rolled visitor in balloon_stats_get_all= () > with a generated visit_type_VirtioBalloonGuestStats() call. > > The wire format is preserved: the JSON output from qom-get is identical > to the previous hand-rolled visitor output. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau > --- > docs/interop/virtio-balloon-stats.rst | 22 +-------- > hw/virtio/virtio-balloon.c | 84 ++++++++++++-----------------= --- > qapi/machine.json | 92 +++++++++++++++++++++++++++++= ++++++ > 3 files changed, 123 insertions(+), 75 deletions(-) > > diff --git a/docs/interop/virtio-balloon-stats.rst b/docs/interop/virtio-= balloon-stats.rst > index b9a6a6edb229..88d3271bbb02 100644 > --- a/docs/interop/virtio-balloon-stats.rst > +++ b/docs/interop/virtio-balloon-stats.rst > @@ -22,27 +22,7 @@ polling the guest's balloon driver for new stats in th= e specified time > interval. > =20 > To retrieve those stats, clients have to query the guest-stats property, > -which will return a dictionary containing: > - > - * A key named 'stats', containing all available stats. If the guest > - doesn't support a particular stat, or if it couldn't be retrieved, > - its value will be -1. Currently, the following stats are supported: > - > - - stat-swap-in > - - stat-swap-out > - - stat-major-faults > - - stat-minor-faults > - - stat-free-memory > - - stat-total-memory > - - stat-available-memory > - - stat-disk-caches > - - stat-htlb-pgalloc > - - stat-htlb-pgfail Missing here: - stat-oom-kills - stat-alloc-stalls - stat-async-scans - stat-direct-scans - stat-async-reclaims - stat-direct-reclaims Review note, not a request for anything. > - > - * A key named last-update, which contains the last stats update > - timestamp in seconds. Since this timestamp is generated by the host, > - a buggy guest can't influence its value. The value is 0 if the guest > - has not updated the stats (yet). > +which will return a VirtioBalloonGuestStats (see QAPI documentation). > =20 > It's also important to note the following: > =20 > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c > index 7ffbe48e5134..bfc75f5dfc72 100644 > --- a/hw/virtio/virtio-balloon.c > +++ b/hw/virtio/virtio-balloon.c > @@ -29,6 +29,8 @@ > #include "qapi/error.h" > #include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-events-machine.h" > +#include "qapi/qapi-type-infos-machine.h" > +#include "qapi/qapi-visit-machine.h" > #include "qapi/visitor.h" > #include "trace.h" > #include "qemu/error-report.h" > @@ -170,33 +172,8 @@ static void balloon_deflate_page(VirtIOBalloon *ball= oon, > } > } > =20 > -/* > - * All stats upto VIRTIO_BALLOON_S_NR /must/ have a > - * non-NULL name declared here, since these are used > - * as keys for populating the QDict with stats > - */ > -static const char *balloon_stat_names[] =3D { > - [VIRTIO_BALLOON_S_SWAP_IN] =3D "stat-swap-in", > - [VIRTIO_BALLOON_S_SWAP_OUT] =3D "stat-swap-out", > - [VIRTIO_BALLOON_S_MAJFLT] =3D "stat-major-faults", > - [VIRTIO_BALLOON_S_MINFLT] =3D "stat-minor-faults", > - [VIRTIO_BALLOON_S_MEMFREE] =3D "stat-free-memory", > - > - [VIRTIO_BALLOON_S_MEMTOT] =3D "stat-total-memory", > - [VIRTIO_BALLOON_S_AVAIL] =3D "stat-available-memory", > - [VIRTIO_BALLOON_S_CACHES] =3D "stat-disk-caches", > - [VIRTIO_BALLOON_S_HTLB_PGALLOC] =3D "stat-htlb-pgalloc", > - [VIRTIO_BALLOON_S_HTLB_PGFAIL] =3D "stat-htlb-pgfail", > - > - [VIRTIO_BALLOON_S_OOM_KILL] =3D "stat-oom-kills", > - [VIRTIO_BALLOON_S_ALLOC_STALL] =3D "stat-alloc-stalls", > - [VIRTIO_BALLOON_S_ASYNC_SCAN] =3D "stat-async-scans", > - [VIRTIO_BALLOON_S_DIRECT_SCAN] =3D "stat-direct-scans", > - [VIRTIO_BALLOON_S_ASYNC_RECLAIM] =3D "stat-async-reclaims", > - > - [VIRTIO_BALLOON_S_DIRECT_RECLAIM] =3D "stat-direct-reclaims", Not missing here. > -}; > -G_STATIC_ASSERT(G_N_ELEMENTS(balloon_stat_names) =3D=3D VIRTIO_BALLOON_S= _NR); > +/* Update VirtioBalloonStats QAPI type when new stats are added */ > +G_STATIC_ASSERT(VIRTIO_BALLOON_S_NR =3D=3D 16); The assertion becomes awkward. What about ... > =20 > /* > * reset_stats - Mark all items in the stats array as unset > @@ -258,33 +235,31 @@ static void balloon_stats_get_all(Object *obj, Visi= tor *v, const char *name, > void *opaque, Error **errp) > { > VirtIOBalloon *s =3D VIRTIO_BALLOON(obj); > - bool ok =3D false; > - int i; > + VirtioBalloonStats stats =3D { > + .stat_swap_in =3D s->stats[VIRTIO_BALLOON_S_SWAP_IN], > + .stat_swap_out =3D s->stats[VIRTIO_BALLOON_S_SWAP_OUT], > + .stat_major_faults =3D s->stats[VIRTIO_BALLOON_S_MAJFLT], > + .stat_minor_faults =3D s->stats[VIRTIO_BALLOON_S_MINFLT], > + .stat_free_memory =3D s->stats[VIRTIO_BALLOON_S_MEMFREE], > + .stat_total_memory =3D s->stats[VIRTIO_BALLOON_S_MEMTOT], > + .stat_available_memory =3D s->stats[VIRTIO_BALLOON_S_AVAIL], > + .stat_disk_caches =3D s->stats[VIRTIO_BALLOON_S_CACHES], > + .stat_htlb_pgalloc =3D s->stats[VIRTIO_BALLOON_S_HTLB_PGALLOC], > + .stat_htlb_pgfail =3D s->stats[VIRTIO_BALLOON_S_HTLB_PGFAIL], > + .stat_oom_kills =3D s->stats[VIRTIO_BALLOON_S_OOM_KILL], > + .stat_alloc_stalls =3D s->stats[VIRTIO_BALLOON_S_ALLOC_STALL], > + .stat_async_scans =3D s->stats[VIRTIO_BALLOON_S_ASYNC_SCAN], > + .stat_direct_scans =3D s->stats[VIRTIO_BALLOON_S_DIRECT_SCAN], > + .stat_async_reclaims =3D s->stats[VIRTIO_BALLOON_S_ASYNC_RECLAIM= ], > + .stat_direct_reclaims =3D s->stats[VIRTIO_BALLOON_S_DIRECT_RECLA= IM], > + }; ... putting it here? This initializer also needs to be updated when stats are added. Another review note... The kernel gives us an array of stats with well-known indexes. Since we "improved" on that interface, we need to manually convert to struct. Oh well. > + VirtioBalloonGuestStats guest_stats =3D { > + .last_update =3D s->stats_last_update, > + .stats =3D &stats, > + }; > + VirtioBalloonGuestStats *argp =3D &guest_stats; > =20 > - if (!visit_start_struct(v, name, NULL, 0, errp)) { > - return; > - } > - if (!visit_type_int(v, "last-update", &s->stats_last_update, errp)) = { > - goto out_end; > - } > - > - if (!visit_start_struct(v, "stats", NULL, 0, errp)) { > - goto out_end; > - } > - for (i =3D 0; i < VIRTIO_BALLOON_S_NR; i++) { > - if (!visit_type_uint64(v, balloon_stat_names[i], &s->stats[i], e= rrp)) { > - goto out_nested; > - } > - } > - ok =3D visit_check_struct(v, errp); > -out_nested: > - visit_end_struct(v, NULL); > - > - if (ok) { > - visit_check_struct(v, errp); > - } > -out_end: > - visit_end_struct(v, NULL); > + visit_type_VirtioBalloonGuestStats(v, name, &argp, errp); > } > =20 > static void balloon_stats_get_poll_interval(Object *obj, Visitor *v, > @@ -1037,7 +1012,8 @@ static void virtio_balloon_instance_init(Object *ob= j) > s->free_page_hint_cmd_id =3D VIRTIO_BALLOON_FREE_PAGE_HINT_CMD_ID_MI= N; > s->free_page_hint_notify.notify =3D virtio_balloon_free_page_hint_no= tify; > =20 > - object_property_add(obj, "guest-stats", "guest statistics", > + object_property_add_qapi(obj, "guest-stats", > + &VirtioBalloonGuestStats_type_info, > balloon_stats_get_all, NULL, NULL, NULL); The @type reported by qom-list & friends changes from "guest statistics" to "VirtioBalloonStats". Such changes can be compatibility breaks. We accept this one, because: 1. What "guest statistics" might mean was never documented. ObjectPropertyInfo's (flawed) comment covers only "primitive", child and link types, which misleadingly suggests values like this one don't exist. 2. We are not aware of anything relying on it, and we can't quite see why anything would want to rely on it. 3. @type is a bad interface we ought to deprecate in favor of @qapi-type. All this needs to be noted in the commit message. Perhaps even in release notes. I guess the latter will be easier if we do deprecate @type. > =20 > object_property_add_qapi(obj, "guest-stats-polling-interval", &int_t= ype_info, > diff --git a/qapi/machine.json b/qapi/machine.json > index 9b145c635baf..34be3156270c 100644 > --- a/qapi/machine.json > +++ b/qapi/machine.json > @@ -1126,6 +1126,98 @@ > ## > { 'struct': 'BalloonInfo', 'data': {'actual': 'int' } } > =20 > +## > +# @VirtioBalloonStats: > +# > +# VirtIO balloon device guest memory statistics. > +# > +# If the guest doesn't support a particular stat, or if it couldn't > +# be retrieved, its value will be -1. Please use the revised syntax for introductions: ## # @name: introduction, best to keep it brief, but you may continue it # like this if necessary. If your text need to refer to arguments # / members, it's almost certainly not brief introduction anymore. # # Additional text can go here. But do consider putting it further # down. I apologize for the inconvenience. We need this to eliminate certain syntactic ambiguities that plagued the doc generator. We'll need it some more for the doc inliner. > +# > +# @stat-swap-in: The amount of memory that has been > +# swapped in (in bytes). Wrap lines at column 70, please. > +# > +# @stat-swap-out: The amount of memory that has been > +# swapped out to disk (in bytes). > +# > +# @stat-major-faults: The number of major page faults > +# that have occurred. > +# > +# @stat-minor-faults: The number of minor page faults > +# that have occurred. > +# > +# @stat-free-memory: The amount of memory not being used > +# for any purpose (in bytes). > +# > +# @stat-total-memory: The total amount of memory available > +# (in bytes). > +# > +# @stat-available-memory: An estimate of how much memory is available > +# (in bytes) for starting new applications, without pushing the > +# system to swap. > +# > +# @stat-disk-caches: The amount of memory, in bytes, that can be > +# quickly reclaimed without additional I/O. Typically these pages > +# are used for caching files from disk. > +# > +# @stat-htlb-pgalloc: The number of successful hugetlb page > +# allocations > +# > +# @stat-htlb-pgfail: The number of failed hugetlb page > +# allocations > +# > +# @stat-oom-kills: The number of OOM killer invocations > +# > +# @stat-alloc-stalls: The number of memory allocation stalls > +# > +# @stat-async-scans: The number of memory scanned asynchronously > +# > +# @stat-direct-scans: The number of memory scanned directly > +# > +# @stat-async-reclaims: The number of memory reclaimed asynchronously > +# > +# @stat-direct-reclaims: The number of memory reclaimed directly > +# > +# Since: 11.2 The actual interface, namely the device property, is much older (1.4?). Do we care? I'm not sure; this isn't part of QMP proper, it's for use with QOM, where documentation has always been rather weak. > +## > +{ 'struct': 'VirtioBalloonStats', > + 'data': { > + 'stat-swap-in': 'uint64', > + 'stat-swap-out': 'uint64', > + 'stat-major-faults': 'uint64', > + 'stat-minor-faults': 'uint64', > + 'stat-free-memory': 'uint64', > + 'stat-total-memory': 'uint64', > + 'stat-available-memory': 'uint64', > + 'stat-disk-caches': 'uint64', > + 'stat-htlb-pgalloc': 'uint64', > + 'stat-htlb-pgfail': 'uint64', > + 'stat-oom-kills': 'uint64', > + 'stat-alloc-stalls': 'uint64', > + 'stat-async-scans': 'uint64', > + 'stat-direct-scans': 'uint64', > + 'stat-async-reclaims': 'uint64', > + 'stat-direct-reclaims': 'uint64' } } I don't like the "stat-" prefix, but we can't change that now. > + > +## > +# @VirtioBalloonGuestStats: > +# > +# Guest statistics from the VirtIO balloon device. Please use the revised syntax for introductions. > +# > +# @last-update: timestamp in seconds of the last stats > +# update from the guest (since this timestamp is generated > +# by the host, a buggy guest can't influence its value), > +# or 0 if no update has been received yet. The original text is=20 * A key named last-update, which contains the last stats update timestamp in seconds. Since this timestamp is generated by the host, a buggy guest can't influence its value. The value is 0 if the guest has not updated the stats (yet). Threee sentences instead of one with a parenthesis. I find this easier to read. > +# > +# @stats: balloon memory statistics > +# > +# Since: 11.2 > +## > +{ 'struct': 'VirtioBalloonGuestStats', > + 'data': { > + 'last-update': 'int', > + 'stats': 'VirtioBalloonStats' } } > + > ## > # @query-balloon: > # Return information about the balloon device. From xen-devel-bounces@lists.xenproject.org Wed Oct 21 10:39:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 10:39:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456506.1669961 (Exim 4.92) (envelope-from ) id 1xJTj9-0004iJ-Ed; Wed, 21 Oct 2026 10:39:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456506.1669961; Wed, 21 Oct 2026 10:39: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 1xJTj9-0004gX-9I; Wed, 21 Oct 2026 10:39:23 +0000 Received: by outflank-mailman (input) for mailman id 1456506; Tue, 20 Oct 2026 20:42:31 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJGfH-0004Go-NR for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 20:42:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJGfH-001FLS-4N for xen-devel@lists.xenproject.org; Tue, 20 Oct 2026 22:42:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad7d216-8faa-0a2a0a5109dd-0a2a4508c6f2-38 for ; Tue, 20 Oct 2026 22:42:31 +0200 Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad7d235-f659-0a2a45080019-94a39c0114fa-3 for ; Tue, 20 Oct 2026 22:42:30 +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 69KHE7fa1368439; Tue, 20 Oct 2026 20:41:38 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 4hdw5bda8x-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 20 Oct 2026 20:41:37 +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 69KKL8rN1753729; Tue, 20 Oct 2026 20:41:36 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([172.16.1.72]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4he7bs24g1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2026 20:41:36 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com [10.39.53.229]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 69KKfZRk12517922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Oct 2026 20:41:35 GMT Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1F0905805E; Tue, 20 Oct 2026 20:41:35 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BD8ED58058; Tue, 20 Oct 2026 20:41:27 +0000 (GMT) Received: from mambor8.rchland.ibm.com (unknown [9.10.239.198]) by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTP; Tue, 20 Oct 2026 20:41:27 +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:Reply-To: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:reply-to:subject:to; s=pp1; bh=ZUXi7wiEMe2tdgO/StfvU9pGNatYDPEYkYpr3SsxzLE=; b=RlDigF9lsTqM tTcz67lqRcQIIyKRfsH2omumJlO9v1oYu2keY01iqqNQY/OXRuHPKVgo+dusPdJ7 TGMAmQzdHEtoUzqBRRB+p2jRhm6uspUWal7wI9ETaxB7v4JQ8JU5l6ekl6yl63h0 I5F4rs0YN/foiumMEHVENZdyuVKFpnRoCVJlw8ZkHcMXj4EXARAPQW9qDiGT/1W1 7JY5cppKkFFpP3zE73cbYFUhDIa9gIU/EWG1a0lLAkWMg7J+Tay56rcVl0KlsR7s ep0odC2xwDk5qAi4L9bWaylnuZpgl4gDIDJAdCxdP4u5plML+T+q41SD70UW1Go0 J7KgO4BwPQ== Message-ID: Subject: Re: [PATCH v7 50/65] hw/gpio/pca955x: convert pin/led property to QAPI-aware enum From: Miles Glenn Reply-To: milesg@linux.ibm.com To: =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau , qemu-devel@nongnu.org Cc: Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , "Daniel P." =?ISO-8859-1?Q?Berrang=E9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?ISO-8859-1?Q?Mathieu-Daud=E9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?ISO-8859-1?Q?C=E9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?ISO-8859-1?Q?C=E9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Date: Tue, 20 Oct 2026 15:41:27 -0500 In-Reply-To: <20261020-qom-qapi-v7-50-431a86b02b58@redhat.com> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-50-431a86b02b58@redhat.com> Organization: IBM Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-27.el8_10) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-GUID: MXNIWy7ihcYs6ZABOpKsku9FGo9K_Fsm X-Proofpoint-ORIG-GUID: E8l_roD9eJZDAYf_etXkufCAlSk0HsoM X-Proofpoint-Spam-Info: AW1haW4tMjYxMDIwMDA4MCBTYWx0ZWRfXylQtXOBUYn2S 8ic3H33Wbx+UaOQcpsfS63FTsNzMONF93+2gyuhJrO/HAENTOynFoSQ/OuYq+F6f3jvj4SyQ1Pj kK2NEWGppQTvC8Z3l6yG5RRlieIgMbw= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDIwMDA4MCBTYWx0ZWRfX3CKW0Q6y9zhw 6Ai+rszw6bufj+NJae9+cn8L4vAgniY6lSu2ZTiMgcZOhgrG9urFqnsQ0BLJYwk3d70Iu66d2sc 04XYvilt8gzcZpmMhwsqa0/cdEzReOh0/tq54yle+o3U2YbAuolYYXFpQ7aXZTgDdp9BidjSTHa a3uIhn/Hrb4CaGBcpGOmUqY+JcGeA9YWkBCUE0ER/iuF3+DmrcjrIidiPjpwKtD9dboXefDQLtg TYm88yr9WvhgKUs3Dx6CkrF+qs9i0NMj2Y2qiF4GzusCB0SEJrWIgSkuigDXitLW4wh/cB81T55 WlTmlX10FEwAMrYNUwotMipdOQ6Zh7OyD6/DUK8c5b2siDndwtiplaPCEYnUrnLtm28OESKDZD2 /fi6Yc02Ni+Vwub6jYcU3fM8cdHUY1wk5CiqE8Qtk5ivScxwaOP73OuiQU1vlb/opP5WcwYCl0N veKhZny0BFO4MtC559Q== X-Authority-Analysis: v=2.4 cv=Gb2CDgXL c=1 sm=1 tr=0 ts=6ad7d202 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=20KFwNOVAAAA:8 a=zBbYNmvnHTV63AnQkW4A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA: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-10-20_03,2026-10-19_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 malwarescore=0 spamscore=0 phishscore=0 clxscore=1015 bulkscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610200080 X-purgate-ID: tlsNG-c1860d/1792528951-D4F4F87B-9AC4E369/0/0 X-purgate-type: clean X-purgate-size: 19268 On Tue, 2026-10-20 at 14:46 +0400, Marc-André Lureau wrote: > Replaces the runtime-parsed visitor-based QOM property accessors with > compile-time per-pin/per-LED accessor functions using QEMU_REPEAT. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-André Lureau > --- > hw/gpio/pca9552.c | 205 +++++++++++++++++++++--------------------------------- > hw/gpio/pca9554.c | 136 ++++++++++++++---------------------- > 2 files changed, 131 insertions(+), 210 deletions(-) > > diff --git a/hw/gpio/pca9552.c b/hw/gpio/pca9552.c > index 16741c22dea3..0a007bbbe4ac 100644 > --- a/hw/gpio/pca9552.c > +++ b/hw/gpio/pca9552.c > @@ -25,6 +25,7 @@ > #include "qapi/error.h" > #include "qapi/qapi-types-machine.h" > #include "qapi/qapi-visit-machine.h" Do you still need to include qapi/qapi-visit-machine.h? > +#include "qapi/qapi-type-infos-machine.h" > #include "trace.h" > #include "qom/object.h" > > @@ -354,33 +355,6 @@ static int pca955x_event(I2CSlave *i2c, enum i2c_event event) > return 0; > } > > -static void pca955x_get_led(Object *obj, Visitor *v, const char *name, > - void *opaque, Error **errp) > -{ > - PCA955xClass *k = PCA955X_GET_CLASS(obj); > - PCA955xState *s = PCA955X(obj); > - int led, rc, reg; > - Pca9552LedState state; > - > - rc = sscanf(name, "led%2d", &led); > - if (rc != 1) { > - error_setg(errp, "%s: error reading %s", __func__, name); > - return; > - } > - if (led < 0 || led >= k->pin_count) { > - error_setg(errp, "%s: invalid led %s", __func__, name); > - return; > - } > - /* > - * Get the LSx register as the qom interface should expose the device > - * state, not the modeled 'input line' behaviour which would come from > - * reading the INPUTx reg > - */ > - reg = PCA9552_LS0 + led / 4; > - state = (pca955x_read(s, reg) >> ((led % 4) * 2)) & 0x3; > - visit_type_Pca9552LedState(v, name, &state, errp); > -} > - > /* > * Return an LED selector register value based on an existing one, with > * the appropriate 2-bit state value set for the given LED number (0-3). > @@ -391,97 +365,8 @@ static inline uint8_t pca955x_ledsel(uint8_t oldval, int led_num, int state) > ((state & 0x3) << (led_num << 1)); > } > > -static void pca955x_set_led(Object *obj, Visitor *v, const char *name, > - void *opaque, Error **errp) > -{ > - PCA955xClass *k = PCA955X_GET_CLASS(obj); > - PCA955xState *s = PCA955X(obj); > - int led, rc, reg, val; > - Pca9552LedState state; > - > - if (!visit_type_Pca9552LedState(v, name, &state, errp)) { > - return; > - } > - rc = sscanf(name, "led%2d", &led); > - if (rc != 1) { > - error_setg(errp, "%s: error reading %s", __func__, name); > - return; > - } > - if (led < 0 || led >= k->pin_count) { > - error_setg(errp, "%s: invalid led %s", __func__, name); > - return; > - } > - > - reg = PCA9552_LS0 + led / 4; > - val = pca955x_read(s, reg); > - val = pca955x_ledsel(val, led % 4, state); > - pca955x_write(s, reg, val); > -} > - > static void pca955x_set_ext_state(PCA955xState *s, int pin, int level); > > -static void pca955x_get_pin(Object *obj, Visitor *v, const char *name, > - void *opaque, Error **errp) > -{ > - PCA955xClass *k = PCA955X_GET_CLASS(obj); > - PCA955xState *s = PCA955X(obj); > - int pin, rc; > - uint8_t input_reg; > - Pca9552PinState state; > - > - rc = sscanf(name, "pin%2d", &pin); > - if (rc != 1) { > - error_setg(errp, "%s: error reading %s", __func__, name); > - return; > - } > - if (pin < 0 || pin >= k->pin_count) { > - error_setg(errp, "%s invalid pin %s", __func__, name); > - return; > - } > - > - /* > - * Report the raw pin logic level; polarity inversion is a read-time > - * transform applied to the INPUT register, not to the pin state itself. > - */ > - input_reg = PCA9535_INPUT0 + (pin / 8); > - state = (s->regs[input_reg] >> (pin % 8)) & 0x1; > - visit_type_Pca9552PinState(v, name, &state, errp); > -} > - > -static void pca955x_set_pin(Object *obj, Visitor *v, const char *name, > - void *opaque, Error **errp) > -{ > - PCA955xClass *k = PCA955X_GET_CLASS(obj); > - PCA955xState *s = PCA955X(obj); > - int pin, rc; > - Pca9552PinState state; > - uint8_t config_reg; > - > - if (!visit_type_Pca9552PinState(v, name, &state, errp)) { > - return; > - } > - rc = sscanf(name, "pin%2d", &pin); > - if (rc != 1) { > - error_setg(errp, "%s: error reading %s", __func__, name); > - return; > - } > - if (pin < 0 || pin >= k->pin_count) { > - error_setg(errp, "%s invalid pin %s", __func__, name); > - return; > - } > - > - /* Only input-configured pins can be driven by an external device. */ > - config_reg = PCA9535_CONFIG0 + (pin / 8); > - if (!((s->regs[config_reg] >> (pin % 8)) & 0x1)) { > - qemu_log_mask(LOG_UNIMP, > - "%s: pin %d is configured as output, ignoring set\n", > - s->description, pin); > - return; > - } > - > - pca955x_set_ext_state(s, pin, state != PCA9552_PIN_STATE_LOW); > -} > - > static const VMStateDescription pca9552_vmstate = { > .name = "PCA9552", > .version_id = 0, > @@ -536,26 +421,92 @@ static void pca9535_reset_hold(Object *obj, ResetType type) > s->len = 0; > } > > +/* > + * Get the LSx register as the qom interface should expose the device > + * state, not the modeled 'input line' behaviour which would come from > + * reading the INPUTx reg > + */ > +#define DEFINE_LED_ACCESSORS(n) \ > +static int prop_get_led##n(Object *obj, Error **errp) \ > +{ \ > + PCA955xState *s = PCA955X(obj); \ > + uint8_t reg = PCA9552_LS0 + (n) / 4; \ > + return (pca955x_read(s, reg) >> (((n) % 4) * 2)) & 0x3; \ > +} \ > +static void prop_set_led##n(Object *obj, int val, Error **errp) \ > +{ \ > + PCA955xState *s = PCA955X(obj); \ > + uint8_t reg = PCA9552_LS0 + (n) / 4; \ > + uint8_t old = pca955x_read(s, reg); \ > + pca955x_write(s, reg, pca955x_ledsel(old, (n) % 4, val)); \ > +} > + > +QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, DEFINE_LED_ACCESSORS) > + > +#define LED_ENUM_PROP(n) { \ > + .name = "led" #n, \ > + .default_value = -1, \ > + .qapi_type = &Pca9552LedState_type_info, \ > + .get = prop_get_led##n, \ > + .set = prop_set_led##n, \ > +}, > + > +static const QapiEnumProp led_enum_props[] = { > + QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, LED_ENUM_PROP) > +}; > + > +/* > + * Report the raw pin logic level; polarity inversion is a read-time > + * transform applied to the INPUT register, not to the pin state > + * itself. > + */ > +#define DEFINE_PIN_ACCESSORS(n) \ > +static int prop_get_pin##n(Object *obj, Error **errp) \ > +{ \ > + PCA955xState *s = PCA955X(obj); \ > + uint8_t input_reg = PCA9535_INPUT0 + (n) / 8; \ > + return (s->regs[input_reg] >> ((n) % 8)) & 0x1; \ > +} \ > +static void prop_set_pin##n(Object *obj, int val, Error **errp) \ > +{ \ > + PCA955xState *s = PCA955X(obj); \ > + uint8_t config_reg = PCA9535_CONFIG0 + (n) / 8; \ > + /* Only input-configured pins can be driven by an external device */ \ > + if (!((s->regs[config_reg] >> ((n) % 8)) & 0x1)) { \ > + qemu_log_mask(LOG_UNIMP, \ > + "%s: pin %d configured as output, ignoring set\n", \ > + s->description, (n)); \ > + return; \ > + } \ > + pca955x_set_ext_state(s, (n), val != PCA9552_PIN_STATE_LOW); \ > +} > + > +QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, DEFINE_PIN_ACCESSORS) > + > +#define PIN_ENUM_PROP(n) { \ > + .name = "pin" #n, \ > + .default_value = -1, \ > + .qapi_type = &Pca9552PinState_type_info, \ > + .get = prop_get_pin##n, \ > + .set = prop_set_pin##n, \ > +}, > + > +static const QapiEnumProp pin_enum_props[] = { > + QEMU_REPEAT(PCA955X_PIN_COUNT_MAX, PIN_ENUM_PROP) > +}; > + > static void pca955x_initfn(Object *obj) > { > PCA955xClass *k = PCA955X_GET_CLASS(obj); > > assert(k->pin_count <= PCA955X_PIN_COUNT_MAX); > + /* TODO: use array/list instead of individual QAPI enum properties */ > for (int ix = 0; ix < k->pin_count; ix++) { > - char *name; > - > if (k->has_led_support) { > - /* LED variant: expose the LED selector state as led%d. */ > - name = g_strdup_printf("led%d", ix); > - object_property_add(obj, name, "Pca9552LedState", > - pca955x_get_led, pca955x_set_led, NULL, NULL); > + object_property_add_qapi_enum(obj, &led_enum_props[ix]); > } else { > - /* GPIO variant: expose the pin logic level as pin%d. */ > - name = g_strdup_printf("pin%d", ix); > - object_property_add(obj, name, "Pca9552PinState", > - pca955x_get_pin, pca955x_set_pin, NULL, NULL); > + object_property_add_qapi_enum(obj, &pin_enum_props[ix]); > } > - g_free(name); > } > } > > diff --git a/hw/gpio/pca9554.c b/hw/gpio/pca9554.c > index e4eddc829ef7..f2a5b94a36d8 100644 > --- a/hw/gpio/pca9554.c > +++ b/hw/gpio/pca9554.c > @@ -18,7 +18,7 @@ > #include "qapi/error.h" > #include "qapi/qapi-types-machine.h" > #include "qapi/qapi-visit-machine.h" Do you still need qapi/qapi-visit-machine.h? > -#include "qapi/visitor.h" > +#include "qapi/qapi-type-infos-machine.h" > #include "trace.h" > #include "qom/object.h" > > @@ -151,83 +151,60 @@ static void pca9554_set_ext_state(PCA9554State *s, int pin, int level) > } > } > > -static void pca9554_get_pin(Object *obj, Visitor *v, const char *name, > - void *opaque, Error **errp) > -{ > - PCA9554State *s = PCA9554(obj); > - int pin, rc; > - Pca9554PinState state; > - > - rc = sscanf(name, "pin%2d", &pin); > - if (rc != 1) { > - error_setg(errp, "%s: error reading %s", __func__, name); > - return; > - } > - if (pin < 0 || pin >= PCA9554_GET_CLASS(s)->pin_count) { > - error_setg(errp, "%s invalid pin %s", __func__, name); > - return; > - } > - > - /* > - * Report the physical pin level. The input register is kept in sync by > - * pca9554_update_pin_input(): output pins mirror the OUTPUT register and > - * input pins reflect the externally driven (or pulled-up) level, so it > - * holds the wire level regardless of the configured direction. > - */ > - state = (s->regs[PCA9554_INPUT] >> pin) & 0x1; > - visit_type_Pca9554PinState(v, name, &state, errp); > +/* > + * Report the physical pin level. The input register is kept in sync > + * by pca9554_update_pin_input(): output pins mirror the OUTPUT > + * register and input pins reflect the externally driven (or > + * pulled-up) level, so it holds the wire level regardless of the > + * configured direction. > + */ > +#define DEFINE_PIN_ACCESSORS(n) \ > +static int prop_get_pin##n(Object *obj, Error **errp) \ > +{ \ > + PCA9554State *s = PCA9554(obj); \ > + return (s->regs[PCA9554_INPUT] >> (n)) & 0x1; \ > +} \ > +static void prop_set_pin##n(Object *obj, int val, Error **errp) \ > +{ \ > + PCA9554State *s = PCA9554(obj); \ > + if (s->hw_dir) { \ > + if (!((s->regs[PCA9554_CONFIG] >> (n)) & 0x1)) { \ > + qemu_log_mask(LOG_UNIMP, \ > + "%s: pin %d configured as output," \ > + " ignoring set\n", \ > + s->description, (n)); \ > + return; \ > + } \ > + pca9554_set_ext_state(s, (n), val != PCA9554_PIN_STATE_LOW); \ > + } else { \ > + /* Legacy behavior: force output mode and drive */ \ > + uint8_t mask = 0x1 << (n); \ > + int v = pca9554_read(s, PCA9554_OUTPUT); \ > + if (val == PCA9554_PIN_STATE_LOW) { \ > + v &= ~mask; \ > + } else { \ > + v |= mask; \ > + } \ > + pca9554_write(s, PCA9554_OUTPUT, v); \ > + v = pca9554_read(s, PCA9554_CONFIG); \ > + v &= ~mask; \ > + pca9554_write(s, PCA9554_CONFIG, v); \ > + } \ > } > > -static void pca9554_set_pin(Object *obj, Visitor *v, const char *name, > - void *opaque, Error **errp) > -{ > - PCA9554State *s = PCA9554(obj); > - int pin, rc, val; > - uint8_t mask; > - Pca9554PinState state; > +QEMU_REPEAT(PCA9554_PIN_COUNT, DEFINE_PIN_ACCESSORS) > > - if (!visit_type_Pca9554PinState(v, name, &state, errp)) { > - return; > - } > - rc = sscanf(name, "pin%2d", &pin); > - if (rc != 1) { > - error_setg(errp, "%s: error reading %s", __func__, name); > - return; > - } > - if (pin < 0 || pin >= PCA9554_GET_CLASS(s)->pin_count) { > - error_setg(errp, "%s invalid pin %s", __func__, name); > - return; > - } > +#define PIN_ENUM_PROP(n) { \ > + .name = "pin" #n, \ > + .default_value = -1, \ > + .qapi_type = &Pca9554PinState_type_info, \ > + .get = prop_get_pin##n, \ > + .set = prop_set_pin##n, \ > +}, > > - if (s->hw_dir) { > - /* Warn and ignore if the guest has configured this pin as output */ > - if (!((s->regs[PCA9554_CONFIG] >> pin) & 0x1)) { > - qemu_log_mask(LOG_UNIMP, > - "%s: pin %d is configured as output, " > - "ignoring external set\n", > - s->description, pin); > - return; > - } > - /* Drive the external input level */ > - pca9554_set_ext_state(s, pin, state != PCA9554_PIN_STATE_LOW); > - } else { > - /* Legacy behavior: force output mode and drive */ > - /* First, modify the output register bit */ > - val = pca9554_read(s, PCA9554_OUTPUT); > - mask = 0x1 << pin; > - if (state == PCA9554_PIN_STATE_LOW) { > - val &= ~(mask); > - } else { > - val |= mask; > - } > - pca9554_write(s, PCA9554_OUTPUT, val); > - > - /* Then, clear the config register bit for output mode */ > - val = pca9554_read(s, PCA9554_CONFIG); > - val &= ~mask; > - pca9554_write(s, PCA9554_CONFIG, val); > - } > -} > +static const QapiEnumProp pin_enum_props[] = { > + QEMU_REPEAT(PCA9554_PIN_COUNT, PIN_ENUM_PROP) > +}; > > static const VMStateDescription pca9554_vmstate = { > .name = "PCA9554", > @@ -264,16 +241,9 @@ static void pca9554_reset(DeviceState *dev) > static void pca9554_initfn(Object *obj) > { > PCA9554Class *pc = PCA9554_GET_CLASS(obj); > - int pin; > > - for (pin = 0; pin < pc->pin_count; pin++) { > - char *name; > - > - name = g_strdup_printf("pin%d", pin); > - object_property_add(obj, name, "Pca9554PinState", > - pca9554_get_pin, pca9554_set_pin, > - NULL, NULL); > - g_free(name); Should we have the same TODO comment here as with the 9552 code? Thanks, Glenn > + for (int pin = 0; pin < pc->pin_count; pin++) { > + object_property_add_qapi_enum(obj, &pin_enum_props[pin]); > } > } > > From xen-devel-bounces@lists.xenproject.org Wed Oct 21 11:03:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 11:03:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456919.1669981 (Exim 4.92) (envelope-from ) id 1xJU6W-0001w1-M9; Wed, 21 Oct 2026 11:03:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456919.1669981; Wed, 21 Oct 2026 11: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 1xJU6W-0001vu-Gh; Wed, 21 Oct 2026 11:03:32 +0000 Received: by outflank-mailman (input) for mailman id 1456919; Wed, 21 Oct 2026 11:03:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJU6U-0001un-6E for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 11:03:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJU6T-007W0j-FR for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:03:29 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad89bfa-bab6-0a2a0a5309dd-0a2a4503d640-46 for ; Wed, 21 Oct 2026 13:03:28 +0200 Received: from [40.93.201.64] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad89bff-fae8-0a2a45030019-285dc9406f0b-3 for ; Wed, 21 Oct 2026 13:03:28 +0200 Received: from BN9PR03CA0322.namprd03.prod.outlook.com (2603:10b6:408:112::27) by LV9PR12MB9807.namprd12.prod.outlook.com (2603:10b6:408:2eb::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Wed, 21 Oct 2026 11:02:46 +0000 Received: from BN3PEPF00022BDA.namprd03.prod.outlook.com (2603:10b6:408:112:cafe::93) by BN9PR03CA0322.outlook.office365.com (2603:10b6:408:112::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Wed, 21 Oct 2026 11:02:46 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF00022BDA.mail.protection.outlook.com (10.167.248.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Wed, 21 Oct 2026 11:02:46 +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.53; Wed, 21 Oct 2026 06:02: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.53; Wed, 21 Oct 2026 06:02:46 -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.53 via Frontend Transport; Wed, 21 Oct 2026 06:02: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=hPsr/POziLBaie29wSDJsJ08zTQc6FVwl4nIONQ1Wqt4hvhiV6HUWz/pOvujx2Ia6VpE0mwM3QpcriQI9jHomn31TZEXIAMfA5cYGRw/3+RARWgU1Z8yZ90sp82w49K/ZQU0H8NXykbHcI3nBAcOec4l0xfQUsDvrqFfnYLTfBW68Uwr8iXWlki3Z6DYSOxOw/QKC25n2ycfnd3VFoKDt9RH/iJy9WVooA9tM4U5i5w56L3BLz89QL9q7+Afg8Ww99i1McZOKFQWuT8WdFLYaeM+RDniS3T19SyAKm1JWhnlYAha5aoGvbkaNZg6KcF7kuJ6vcIyYgcU/kAODRyYcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r8ZgG7fzQivswrw0NfdKa7l9bqdczz0fbxgSeRTh/Yc=; b=BXJuGDVYHtnpt0rvIHvEnvarRsXhs/ustoTp+p3sHI2gVtNeTXj26M5lPO+mIWr82zxSLqn6lyne2Ew7SqIFmAbF4RxgBSaX1By/NDy7BLLgSRweW+0/m6KnWCBr+vrXa6ZmeF2xDLArCSuvIF7eTgskeur+CO9YKiiNB+S6ZVZ7F7zKnrRkdewapATxqyliRE9yb1OX2IzCHNaOFrQ0AWwYsJNO0VTqpALcHjsk6xU47hylfoq4jyyPJJ9zqCEhcItBT1WbDZpuqPLqdhtZfCo1X1SAaS64JPVBqJuC82vbEFmrr6G3r1ZWp0vdAxWJ64TAuZKSp1OEX5P0IYf3Fw== 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=r8ZgG7fzQivswrw0NfdKa7l9bqdczz0fbxgSeRTh/Yc=; b=gaA35V6MSsk8VaVJolEa23b3rGSS52bwJ2VDPifqqwGTI9yID9HoTQEJfQqVCj922fpap197PtkNb+XKR7rodVuUpAp5W3Hx/oI/pcpTuNxaEeFlTkPblAo32drGRnOjWhThY0ZSlC0F+LFH3nyl0N4bYnBhMy1pYhTO9pLl5vA= 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: <22b3b21a-775e-4d82-b9bc-5fea1849294c@amd.com> Date: Wed, 21 Oct 2026 13:02:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration To: Hirokazu Takahashi , CC: , , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20261019015749.48492-1-taka@valinux.co.jp> <20261019015749.48492-2-taka@valinux.co.jp> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261019015749.48492-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: BN3PEPF00022BDA:EE_|LV9PR12MB9807:EE_ X-MS-Office365-Filtering-Correlation-Id: f17eb076-de5e-4933-872c-08df2f62d6cc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|376014|7416014|23010399003|1800799024|6133799003|22082099003|18002099003|10067099003|4143699003|260925021911599003|260925022911599003|260925021311599003|261009223027099003|5023799004|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: QWyX1YqJcD2/3Pm24bLcaJ+cv/qo99ayDDItcx2wsbfeffnYVnDj/uEq1ygmDGkS4XIx6N5yrAEn11tfbotA7SEIlxYYUXJdGUVoGGFv/4/KMJ50Fq66+IsL51Mgmyz29xvTjw9ahTv/mV3fDG4f9DT89I5vimdk7/JuVX569uX+xVQn1ZINNGorXvoXB0L162AlY5zYMAnHxSOtfbcKqreAWYd+PnRwK5VlcFfrc3kAR+4qGLt6xY3LeTbLt23vC6KbnGP1zBK7CY+evJcUc7PrvKx8DCrVoKaeMamwaYe0Jq+8Pq+i9dt+VmM82Ecaset8G+8R8WkqdzIF4VEsYSWLiIZFc8hTpmaGuSPnO9js/AR8w3yva5+vqp5RsaPUuYg0omE7S+UYrSaPDKa7lbm5RAPQQ9uUv0EljR8Je0okR7DZUr8J/4la10fXfaW5z6niWKtiFVHWhE7rBarpjCc9tfAU5Ui4WUt1n1Xe7VNAUVmV0I9VCrZ+l7W/12/aWgPjpzGA/8p0Q22MeLYkMgHquBjFCWkkZM5oiOVFzHlj/donF/PqfbmYVrkQ/vYt5YL2w8VmQcvSAAZhKdEVogYOtM7pR2POvNocQGe9XlhZYwcYgnS05dkpdBdv+KafSEh76ZEdaRwAZufQHhqyl8MKbomA/UlBKOE1gnBvObOeFZsiqvIunnzfKZYA68pKhjqFzkb9FFLJyjFztqzC7w== 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)(376014)(7416014)(23010399003)(1800799024)(6133799003)(22082099003)(18002099003)(10067099003)(4143699003)(260925021911599003)(260925022911599003)(260925021311599003)(261009223027099003)(5023799004)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EefgJ+29yp7833OIV0/OyOiiG46PITJWmyaMt6vF0MfnSZSyq2R9w2PieCjKaIQt+Qg79avxtmJ63np5pidqA8krZLa10ha6OKIUdmsUAzAwBmn/Uc/XdH0xKeq4lFkkm58LyDLCcQPAOO7O9IT/GEZ2WqiHfctjRsxiDqlNIVXkjCc7NHjPinUGG9P5yYGzYzNwlDVgm4pDz+C3xBpAIyoMf9+4H0l/VeDYZDtjJHoBVlSh+BCPukGv7wIDWgwS/QVd8Daw+tTowzpXUjZSBG0lKwW9jiPmsNYreQ4IU9bzBeUsh4UGYU01B3OfH5SwwitoyAHflsGwyrvFMcscinhPHiYhs1Swm/UfKitgcGfmzqW4jJO2mnGy4WS9KdhTO1Vpkz8RyJXsBiUb8yTOX3Zuy13bHyQ7Ov4r0W9CluaFOBAllPXUcWI2LLBM94t8 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 11:02:46.6464 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f17eb076-de5e-4933-872c-08df2f62d6cc 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: BN3PEPF00022BDA.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR12MB9807 X-purgate-ID: tlsNG-33051d/1792580608-778C54E9-6FCBE5CE/0/0 X-purgate-type: clean X-purgate-size: 15800 On 19-Oct-26 03:57, 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 > --- > Changes in v12: > - Error reporting for memory allocation failures in init_cpu_topology() > into a single error path. > - Emit an error message from init_cpu_topology() when > dt_init_cpu_topology() or acpi_init_cpu_topology() returns an error, > explicitly indicating that CPU topology initialization has failed. > - Drop the Reviewed-by tag from patch 0001 due to changes in > common/cpu-topology.c. > - In dt_smp_init_cpus(), add a comment explaining that the boot core > remains valid even if arch_cpu_init() fails. > - dt_init_cpu_topology() returns -EINVAL if a leaf node lacks the cpu > phandle property or if the target node is not a valid CPU node. > - dt_init_cpu_topology() continues parsing subsequent threads instead > of returning early when a referenced CPU is not tracked by Xen. > - Update the log message when skipping an unmapped CPU to reflect > that secondary CPUs have not yet been brought up at this stage. > - Remove trailing periods from log messages. > - Drop the Reviewed-by tag from patch 0001 due to changes in > common/cpu-topology.c. > > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/setup.c | 3 + > xen/arch/arm/smpboot.c | 10 + > xen/common/Kconfig | 22 ++ > xen/common/Makefile | 1 + > xen/common/cpu-topology.c | 73 +++++ > xen/common/cpu.c | 5 + > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/cpu-topology.c | 370 ++++++++++++++++++++++++++ > xen/drivers/acpi/Makefile | 1 + > xen/drivers/acpi/topology.c | 43 +++ Shouldn't this file be called cpu-topology like the DT equivalent? > xen/include/xen/acpi.h | 13 + > xen/include/xen/cpu-topology.h | 34 +++ > xen/include/xen/dt-cpu-topology.h | 35 +++ > 14 files changed, 612 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 b9c5c40678..3d0f689220 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_SHARED_INFO > select HAS_STACK_PROTECTOR > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 2cd1c021b5..c1aa06bd31 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -10,6 +10,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -375,6 +376,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 8c9072f3c1..d34396f9b1 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 Nothing in this file seems to use this header > #include > #include > #include > @@ -245,6 +247,14 @@ static void __init dt_smp_init_cpus(void) > } > else > tmp_map[i] = hwid; > + > + /* > + * Because the boot CPU (i == 0) is already running, treat it as valid > + * even if arch_cpu_init() fails (e.g. due to a missing enable-method). > + */ > + if ( (rc >= 0) || (i == 0) ) > + /* 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 5b289e444f..fb42f0aa8b 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 > > @@ -194,6 +197,25 @@ config VM_EVENT > config NEEDS_LIBELF > bool > > +config GENERIC_CPU_TOPOLOGY > + bool > + > +config DT_CPU_TOPOLOGY > + bool "Device tree based CPU topology support" > + depends on HAS_GENERIC_CPU_TOPOLOGY && DEVICE_TREE_PARSE > + 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" > + depends on HAS_GENERIC_CPU_TOPOLOGY && ACPI > + 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 f69d47d189..d0eb39a633 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..8c64532e28 > --- /dev/null > +++ b/xen/common/cpu-topology.c > @@ -0,0 +1,73 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +static void __init free_topology_table(void) > +{ > + unsigned int cpu; > + > + if ( !cpu_topology ) > + return; > + > + 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 = 0; > + > + if ( num_possible_cpus() == 1 ) > + return; > + > + cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids); > + > + if ( cpu_topology ) > + { > + 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) ) > + ret = -ENOMEM; The loop continues allocating after the first error which is incorrect. > + } > + } > + else > + ret = -ENOMEM; > + > + if ( ret != 0 ) > + printk(XENLOG_WARNING "CPU topology table allocation failed\n"); After printing this one we will also print the "Failed to initialize..." one. Please goto the error. > + else 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 ) In v11 I asked you to print error on real failure, not all the time e.g. on - EOPNOTSUPP or ENOENT as a result of not finding cpu-map. > + { > + printk("Failed to initialize cpu topology (error %d)\n", ret); XENLOG_ERR/WARNING? > + 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 730d202349..b15b3382d2 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..bfcf153cc4 > --- /dev/null > +++ b/xen/common/device-tree/cpu-topology.c > @@ -0,0 +1,370 @@ > +/* 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) > +{ > + 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) > + { > + 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_name_is_equal(np, name) ) > + 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 int __init get_cpu_for_node( > + const struct dt_device_node *dt_node, unsigned int *cpu) > +{ > + const struct dt_device_node *cpu_node = > + dt_parse_phandle(dt_node, "cpu", 0); > + > + if ( !cpu_node || !dt_device_type_is_equal(cpu_node, "cpu") ) > + { > + *cpu = INVALID_TOPO_ID; > + return -EINVAL; > + } > + > + *cpu = cpu_node_to_id(cpu_node); > + > + return 0; > +} > + > +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; > + int ret; > + > + 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; > + ret = get_cpu_for_node(thread, &cpu); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "%s: No CPU found for thread\n", dt_node_name(thread)); Use dt_node_full_name(). Otherwise the printed name can be ambiguous. > + return ret; > + } > + > + if ( cpu == INVALID_TOPO_ID ) > + { > + /* > + * Ignore this CPU node definition as the corresponding physical > + * CPU failed to boot. You updated the printk message but not the comment. Please fix. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 21 11:41:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 11:41:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456965.1669989 (Exim 4.92) (envelope-from ) id 1xJUgz-0008CZ-FA; Wed, 21 Oct 2026 11:41:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456965.1669989; Wed, 21 Oct 2026 11:41: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 1xJUgz-0008CS-Bn; Wed, 21 Oct 2026 11:41:13 +0000 Received: by outflank-mailman (input) for mailman id 1456965; Wed, 21 Oct 2026 11:41:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJUgy-0008CM-3o for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 11:41:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJUgx-005gAG-Gs for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:41:11 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8a4d7-e002-0a2a0a5209dd-0a2a4507c1f2-0 for ; Wed, 21 Oct 2026 13:41:11 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8a4d7-b4ea-0a2a45070019-d155dd2aacce-3 for ; Wed, 21 Oct 2026 13:41:11 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48b0584ad71so416859f8f.0 for ; Wed, 21 Oct 2026 04:41:11 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e2583f25asm4779096f8f.45.2026.10.21.04.41.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Oct 2026 04:41: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: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=1792582871; x=1793187671; 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=llresBdBQJEa+pUyBfMo3RMCjuevYB264QApIKbkTwM=; b=ODb539BfqfoQNtmRb20+U4NUifiIvJLK8zRN4eEBP92kBXgG9fV/AAkIieFzJEbfu0 dC0UF3cJn+pzCZqEey0KReo7yb1So2Y82bjxG4H3dWBmQnny9RbvqqFbbdjkOw+NfTVk wgIrrXooG+Wa7RiEEq6ynN7aOGp3FfOgyR0hz/Ko5JEOfjZd7VrPy0xjkncqrEdhoNy/ CT/Qq2Ba0jFPVs3LNVMfy2Ih1Y6viXhaIihjXL9sbB/E4Qcn2unpTbCKA8ra2PVIlYbe idFSCLb9vC8PYUvzFERXq1HtdWaE9YYpRkcaIqiSMkRHcHmYLunDUq5XAN+cawFzcpuU b1Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792582871; x=1793187671; 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=llresBdBQJEa+pUyBfMo3RMCjuevYB264QApIKbkTwM=; b=eDKeDppjoLo18PTcnOddv3UpIC/vSn3wSlhdjSrUBnyHmpXjWwuFLPYQdyueM8I6+i 02dbzykre0+Z6x1FX7nXRVbD3ZkGxkmAOdQi8uT4lh10vEZmb13e7m8ZYKZiRouVE34F R3rqDK7482hrggNeBwNmGgvYRrnU50fJWn90bm8CHK3Dxo5gUM9LG8fcBZfkZoNdZagc R85McOnjOvoTkh7A3VMZ9JcuzRr6iKBFsmX/9jC1iVC7ZqAJExZTGf2bAG7dJSnlXd42 9QZ7O8yM/JJlJn0EVuO4MbmOr0Pu+/HBFOkWxmTVr4lJb7mjRFDaACh2drIwbQsA59Ej sNlg== X-Gm-Message-State: AFq9FYJ+hza8S+wmFNsLvotLieNupGvXCWIdRONfjJDszKEvJjdSQpag RH7BTxa3pEFe3RYIOiijyuVIp2ESnGIAuK6OpPGswdH6V9gyKYiQFa8fC4Bl1Q== X-Gm-Gg: AYBFou2qd9KBBalZSRzhIQayWTBmEyvkHLC74so3w1V75oU5iTeXvedEykaVdUgWia+ dKFq8a3VEXQY2elZaiLNFCw+kOAf1Y9ep9R9lHcTeP3v+OMVtH3xm/UPZUMoF8MAnpMKtq6BtJr tvp2oFhRZ+Ww5gWM+Llzru7CjMotSDomJhqn7GG34KQHh67xpBW05cDyTbO71jAGHiyqHAfWEEY 0Pl19Rbqhdco5Rzlir/NqWeTyXW+0gHVfGu9FsMrZpDPxaQetAZD459c08Fev+HT6ZY+AY1wXSs v1hGsKNr3qPJTLBUJVwV4VNW2lPd5Cgj3n/oSNfl4Up31Yfxq8HspQ7KWkNADsM+2kjjl9eYshh kTV9ipOvD0zXiz7ROWT1+J7iAAzRoZ+un3moyO3lLeKDcNL8yZiqJFjIJaiNYzB+wv4YVfCNiOh X9paSOVo/CrQbRLlpAkhiHEZ5zQU7pLA/O9hjmQgWkbFVU7bcpqm0zdbwbzaH+KeIo0kNMdvYXZ f5naOPwy/UQ+wId0zorCv3oUou80tFD/i+bn3Ydjj7CQjvh+NS7KxIU88yDHM4RA2NxmWSK75ZZ 4O57HYtEzZBdClhm4CeZ/WCAgolv X-Received: by 2002:a05:6000:1a8a:b0:48d:dc6f:219a with SMTP id ffacd0b85a97d-48e264ad992mr3872218f8f.27.1792582870555; Wed, 21 Oct 2026 04:41:10 -0700 (PDT) Message-ID: <79b3daf0-6d97-4e30-a8f5-3df1c35dcfe9@gmail.com> Date: Wed, 21 Oct 2026 13:41:09 +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 schedule Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1792582871-35CC7AE4-33C7887E/10/73395122804 X-purgate-type: spam X-purgate-size: 1025 Hi all, The release schedule for Xen 4.23 has been finalized. The key dates and milestones leading up to the release are listed below: - Last posting date Fri Feb 05, 2027 Patches adding new features are expected to be posted to the mailing list by this date, although perhaps not in their final version. - Code freeze / RC1 Fri Feb 26, 2027 (+3 weeks from Last posting date) Features posted before the Last posting date can be committed until this date. From this point onwards, bug fixes only. -RC2 Fri Mar 05, 2027 (+1 week from RC1) -RC3 Fri Mar 12, 2027 (+1 week from RC2) Fixes for serious bugs (including regressions) and low-risk fixes only. - Final commits Fri Mar 19, 2027 (+1 week from RC3) Branch off staging-4.23. - Release Wed Mar 24, 2027 I've updated the Xen 4.23 Release Notes with this schedule, which can now be accessed via the RN link: https://xenbits.xen.org/docs/unstable/support-matrix.html Thanks and have a good week! Best regards, Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 21 11:45:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 11:45:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1456973.1669999 (Exim 4.92) (envelope-from ) id 1xJUkq-0000Hm-U0; Wed, 21 Oct 2026 11:45:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1456973.1669999; Wed, 21 Oct 2026 11: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 1xJUkq-0000Hf-Qa; Wed, 21 Oct 2026 11:45:12 +0000 Received: by outflank-mailman (input) for mailman id 1456973; Wed, 21 Oct 2026 11:45:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJUkp-0000HZ-KW for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 11:45:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJUkp-00GOUW-1A for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:45:11 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8a5c2-2eae-0a2a0a5409dd-0a2a450b876e-30 for ; Wed, 21 Oct 2026 13:45:11 +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 6ad8a5c6-b7e8-0a2a450b0019-b9ff1c22aba5-3 for ; Wed, 21 Oct 2026 13:45: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 1a15e4785ac000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 21 Oct 2026 11:45:08 +0000 Received: from leducb.local (199.148.3.89.rev.sfr.net [89.3.148.199]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id BBABA8088C; Wed, 21 Oct 2026 13:45: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=kEv6Pif+476DTNvF2i548z1gYyiH4AajDAuMqvEHulE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=EkTijRhbB0NqbNEtpb6ldEG9wlKFs5J0Ntie+aTXdYDvdbhF0DaMO/vFG6M8C8tLAhuNAVXDB u7Ha+c/tpa/2s4N4mOhJjiNOh4HJPeN3St/5AaPjBxpaE4GhA/Ff0KsRq0l4wO6TJ6K45nsoVgA aJnhNC0MI/0wtnlXw5J2NPMaVlqTBVqgXI0s7C5SwLCLplQ9J9P71R6VOZYWMEfPcXk33zNMOZ1 lLQIOUtO/VPzqpkBkbTqfEZkHEkvovwPWqspU8N7xng5uxFE0E58YUC/+vfjs38YNDtbxLlXfYA 23AXGz0QwzEL7RqJLc9ZbT6R0oa3UhuBG/hqZKCl8GGQ== X-Zone-Loop: d06db611fcc81cc59ecce606fab6f1676c869b3c16eb x-campaign-type: default x-transaction-id: f4e4397c-337a-4b3b-a3d2-76894f07d1eb x-swg-uid: 01-e1f9ab1e-7cfb-42e7-8e07-5cdcf7e29f9c X-Mailer: Sweego Message-ID: <1792583108.8631fc262581453bbf619ec5b2062170.1a15e4785ac000f79f@vates.tech> x-swg-bid: 1792583108.8631fc262581453bbf619ec5b2062170.1a15e4785ac000f79f 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 v3 20/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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis In-Reply-To: References: Date: Wed, 21 Oct 2026 13:45:04 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792583106; l=1017; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=HO6XFLuzj0NtkcDHbqTu9Yqos4RN3QD3uGWS+cvEZUc=; b=Wgw8ptGvWDkCUxVIYLehtrI3uZXbFUDsMcHUsD2UNQJpGWiJfPnJEfh9A+uVvIP9IvU9pAke1 lb27s+XMKY6Cpk3Yy4ixbdE2v/mUT7LvGK92KBX71kMbTfnEH4iuvLA 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: 1792583107083 X-purgate-ID: tlsNG-42698a/1792583110-1AAD89EA-FB6C9CBF/0/0 X-purgate-type: clean X-purgate-size: 1017 > 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. Nit: "The shift" reads as the right shift just described, while what is meant is shifting htval back left by 2 to recover the address. Could you say so explicitly? Something like: ```` Shift htval back left by 2 and take the two low bits from stval. htval is first converted to paddr_t, then shifted: a guest physical address is 34 bits wide on RV32 with Sv32x4, so shifting the XLEN-wide register itself would drop the top two bits. ``` Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 21 12:19:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 12:19:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457030.1670007 (Exim 4.92) (envelope-from ) id 1xJVHn-0005eg-E0; Wed, 21 Oct 2026 12:19:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457030.1670007; Wed, 21 Oct 2026 12:19: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 1xJVHn-0005eZ-BB; Wed, 21 Oct 2026 12:19:15 +0000 Received: by outflank-mailman (input) for mailman id 1457030; Wed, 21 Oct 2026 12:19:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJVHl-0005eT-NA for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 12:19:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJVHl-00GVr5-3j for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 14:19:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8adb9-2eae-0a2a0a5409dd-0a2a45068900-48 for ; Wed, 21 Oct 2026 14:19:13 +0200 Received: from [52.101.46.70] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8adbd-195a-0a2a45060019-34652e4654e3-4 for ; Wed, 21 Oct 2026 14:19:11 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SJ0PR03MB6534.namprd03.prod.outlook.com (2603:10b6:a03:38e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.18; Wed, 21 Oct 2026 12:19: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.0546.012; Wed, 21 Oct 2026 12:19: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=VSAyfd2ZRxwoR/RdzlbdQh3qFS6yt7alRaULT4f/pmbn7B3IlFN3NzwKV3pxqHRhFwn+kmQXAQQJspM+yICeN2q+7mS/0fPAbP/QXDvG8qfyFqaQJGSesm/2S7/ldIMfeDp+KGcuOLkTBzkRnoT7BBGhlFeh7k9PixGGppCw+mO8fHeFDk+BjUA+XIFORqdDtYvODBJ/7Z4n1YM4a5T6NpIlWu20QBSGkbzHcO5LwviGPfuNlyhQ0BoghFv7+ieJpor2w/QblkSjThOkE4bQ9Sf5HQXV5jCTstBh0d8yJtkjo0LqNIT6SNltgpYu2ua8Bmhie5LQrurf2IfpC3Lt0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7ngwEiwfSDSxCA3ils7CWgGstjPZkhvt4WCoAa8Lc8g=; b=TWIAejdC6JALQ9NbaklKsv7Os0sFkdNBgYrsFMqw/LKO8pcH3qD8Gp0Uo1f+JdKjYWA555Q6cLyBwSigJDH8QLOu2UgqL5DFlEzLdn23sLLQWR0qqTjzbv1FlhoTPV1RnrupEHjZJTLGwDD8lWT3ZqTtSS/veqv4X9pV2Yh8/Qu9JnFm3LxYR+qzP4wLoPRgY0uk1zkdL+uzpCDv2x2ZHmT1fqAdmEZNGy6xVlxPXVtaPv0hbzBE0MVO3HPRe8zDm+VDjPu/UdSHwgHr0+ZBw3UQkNuee0ObLTaiwelNly5+PCs1xv+nH7MdckoBF0PZ7ZW9vXIxfeKaOIr7oY+5dA== 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=7ngwEiwfSDSxCA3ils7CWgGstjPZkhvt4WCoAa8Lc8g=; b=EPGtP7CuXOfA1UIS+ZbhCDQJNvNtEzdTs9YEXyDMdmoynGorUp/IwZvQkQhvMr25nUZT/a3gjnQgjKRU30JVpjIgeyK7PG/QaIkA6L0XU2Kr6PKQ6PxAaSUyU6KzGNFOS7d0pKQU/pasVttfdtY8tW8oGjXlbArdWHeHcmGgtRw= 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, 21 Oct 2026 13:19:04 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nestedhvm: Inline nestedhvm_vcpu_in_guestmode() To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1792515236.8631fc262581453bbf619ec5b2062170.1a15a3be15b000f79f@vates.tech> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <1792515236.8631fc262581453bbf619ec5b2062170.1a15a3be15b000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0129.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c6::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_|SJ0PR03MB6534:EE_ X-MS-Office365-Filtering-Correlation-Id: f82c7ab5-60e7-4980-7d09-08df2f6d8142 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|56012099006|11063799006|261009223027099003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: TaSD6k6KQMtgmkI4AA+4Y8yY9l2sj3TsyDUMoavVfS7cHiGTpq4pZF8FVrQigHhEw2WIO2xs/vq4y6v/61o67PgiRrrVSGCdG6NwqGOjDmb49xTR5tkQzxXXTigC9DU8PsPQqeq6tH7su6+8a3AXNiZQ57V3lMC3D9+DadW+wLOmxfbpWnIU6tpS8KvR8rv6ES8SHNRrIXH73k3dpmtJqohKxpAGwoE8CtILTaRE2GRFU/MhSotNP/9vZAhmucNdlInSnpYTr7mVrp5MtfZCgg945Xgtk2mqylUkexkxv7ZZnatu8rVoX/M54Ab5WliVFVF0PLIHm0BU9TwPvDsSj/dec8VuvpMl1gnn4ooZWtfpG5KrgpFk6uTqbQKH36gE6Ui7LLVMswhtQKZcg/yigga8sGP2GUGnB34W+A2GmY/jLUwxZ7nIGk5rRp0DS/caz4Zw4E2fGN3Je+2gkgNvhxeUBmV5WIEhAJNEt6dI8/Fyf6xAb7DfVoBMO7Kw8Thj6AQxRGGcI9E3EliqLztAH4/IJACxeoMy9MHzNVYy2f/xieRI+9GqlHF72CpaQd22HTAMHACRobQxnYYGnfdu4tc2AgNpH7kuwGCJpuNzp/cls2k/d73XIHZmfi37scdg8A1fpypsSZgIapQIP63fuAJxvjsiE7fdx6x36cGgMAM= 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)(56012099006)(11063799006)(261009223027099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MXBKUXBleFNGNjh1aDZCc1BnZ0EwNkp6VlpScEdhUlladEl4OVFKTDhEc01C?= =?utf-8?B?TUNMaVJnNTNYeFVReXVjWERFRmE2WUw2ckFSeEQ4ZERyL2ZXK09nOGp5S3Zk?= =?utf-8?B?eHdDamVmejlEajV2cFd2Vmh6Sk42eElndmJOaTdHenh4Vk9YMXZjQmpaeE5O?= =?utf-8?B?c1dNekJNaUVxSlZ2OXhQS29oYXJ2YWh2ZWVLSDZtcHVTOFFSU01JSWpQTGxV?= =?utf-8?B?bGRxR05tZ2gzb0c4QTVGWDlKREFkcmpneGhGQ2xaUzFYeEdkcXpkazJ1Y3A0?= =?utf-8?B?YXY4NThiRExpUEwwdW8yRk9QVy8rbktQbHBTckRERVNDdk5JUmUzQVFYL3BU?= =?utf-8?B?cHBxcmoyQjFZLzd3anMyYW9zQ1hIc1R4NGxoQ2wyR2QxRzJYT0l3Wk5FaDNz?= =?utf-8?B?QldVYWg3Yk1DMFJSaFB1OTJyd3VFYlFObmVnbTZBMnhSZ2FQdndjOE83bXNw?= =?utf-8?B?R2tKUGtlNkhsblVxcDZMQU1JR3pEZ3lnbm9HWXlscWdFWVo1MjJaSHJBZi9l?= =?utf-8?B?VTE3bDlndmtBK1Z2YXkwTmh3cTg4N1NQN0VwS3ZlTkpQMHhKTmdnajMrTDgy?= =?utf-8?B?ai8vbTZabE1TTjZWY0RtQWkzV0h2ZU9BZm5TNnBQaDU4MmFLNGcwOURsQlI1?= =?utf-8?B?NkVZTldjeUxWWDk1QTNBS21lVm5EME5CSmJra212ejRkY1phdFk2T2VzWEE0?= =?utf-8?B?Z3h5b29iSUhuN3AvSm9MWk5kTFg5ZUhlL3J2Y1BIRUI4UzhQL0tpaVE2cDZW?= =?utf-8?B?VUhOV3o2UUhzM216NWdoTHZRRUJsWW9rVXY0czMwNExRU05remM1RWpadHFK?= =?utf-8?B?a3AzQVhLUXFmTkZHZWVxSENKbDdWTktJckZaNllsSDNLZWNUTFByVmplTFV0?= =?utf-8?B?T2pVNWcwNkpwWFYyRDlIZkdiRG80WmY2UDk0Vzd5d1hpUVJQbEYyTk9sTEJs?= =?utf-8?B?ck5WVUMxU1ZCMGwxZjVwZUhBcnRNVGtwWmlmSnUyNGRFZFRBandzQVcvcVM1?= =?utf-8?B?THJXR2RTMWFmZm1iVVVMWjlYRVlDTXl0WnNoT3d5SVpaUE52akI1eWc3aTVF?= =?utf-8?B?VkQ1MmRQSlNTaTl0eWJ5YlhrV1JXN3oraTEyOTIxRWZaSmZNZ3VQakhEUEVm?= =?utf-8?B?RWpTUGZEbSsrMEJHWXdSL1hIeThoME5zRVpybE1Fa3AwcnRBVU1GOFkyOXVQ?= =?utf-8?B?TnNJYm5GVkNRbkh0VFVsaCtJS2FaOTBVSnNRK21SbFRTeGxTTWpUMFlrTWth?= =?utf-8?B?cDFqM2tPUmdkSjM5bVBYL25iQ3duR3UzK3pjaXBCSXl3MWhPdFUwemEzaU5i?= =?utf-8?B?cTdpYWNJN3NubGR1bDNMMjFNUlg0RTRwRXl4bVYyNkwxZytudWw3TXl5Q0NV?= =?utf-8?B?VFpzL0lJWGc3QllEQWZ0TnVZblozV3F4bUtlMmxlYjlDSHk3STMrVVNVMEs5?= =?utf-8?B?Mkp6VTdJOTEwOURoellZcDA1VVJReFZhejNTSloxbkprcjIwaXBvcEIzbHRo?= =?utf-8?B?cHJ5L0hMTzJCR1Q5aHczbURiKzZsM1llbHlEU2ZKT0M5Tll2Q1Y5R3NRRVNm?= =?utf-8?B?V2tDT2UvUTVDTTNrYWdMaVVUOE5SdVFBMTVBbHlhdVgyWGFBWkZVdXk4OEFv?= =?utf-8?B?SklvRmMvTUhvT2lDSDFvNlQveWMwNlFxYW1Yc1BWQXphTm5oOEduQXBpcDVN?= =?utf-8?B?Ny9Zb3V5WCtxaE1tREN4eHV4T1p1Vmovem1ISWkxRlgzdXBud0tDUys4d1dF?= =?utf-8?B?SXRUcTQyc3lmMFYxbkNXZkVVVklkL0MxcjcwRVFSNUkybDFKVit4ZjB0UHpQ?= =?utf-8?B?SGwwZytLamlqekZCV2hSaGFLUGZ2cFBaL1lTUlhVR25IL0xQR01mR2o3RGZn?= =?utf-8?B?YWIraHRHVm9HdmVEZTFZMWJaRmh3anl1U0NBQ1d6RkVwcGZ3YmtRTUluU1Zk?= =?utf-8?B?U1VCbUZUMlVtRHdtVFR1Z3NCazArcmVQRVozK0FBdkhrRDdjdTduVnBoNzY5?= =?utf-8?B?R05JWXU3NUhiaUlHQjRHeHR3YS9sdkNVRStNS2FKS0Q0T2w2NTh4L081cXQ0?= =?utf-8?B?Ky9ucE01T09sYlgySUU1Ty9rZmdnVlNOMjRzOUMxQzVYZ0JJdndlT0JNdGFI?= =?utf-8?B?TVhDdHN2MGQ3aDcrclVYLzFXK2g3NnZnbE5uZTJxbG5aTUJzWFlpRzBPN1dT?= =?utf-8?B?YVJwTnJKT3RLNDVjZkRKdUlId2xtQTBrblVLMEdGQWphTGpIcTUxc0hyYndG?= =?utf-8?B?azR0ampyTUJMellUSGRDTzVTY2tvM2dYL1ZyOE5GOGwybWlkcmI1eDNVeUo2?= =?utf-8?B?K2ViOUJYV2ZCR0E5bnhzbWJ3c3NxQXcvQnVoV2ZkREo5ZG1WOCt2TGdmT0dZ?= =?utf-8?Q?w+2P+CTQC+4Z7IKw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f82c7ab5-60e7-4980-7d09-08df2f6d8142 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 12:19:07.8001 (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: fzG8oE/lq9bjJyj9U0l+uI77hplgz6mx1LLxYP/bOCIHxQ1nISNp8qfA1/F8zC2RaEWtO3Fi4ibFqOJ9yenXX0Kwxqjokw7Fg2mAXVbXsmA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6534 X-purgate-ID: tlsNG-16d1c6/1792585153-F6A7477B-490D74AC/0/0 X-purgate-type: clean X-purgate-size: 2134 On 10/20/26 5:53 PM, Teddy Astie wrote: > This function just returns vcpu_nestedhvm(v).nv_guestmode and would > be better inlined to improve codegen. > > Signed-off-by: Teddy Astie > --- > xen/arch/x86/hvm/nestedhvm.c | 7 ------- > xen/arch/x86/include/asm/hvm/nestedhvm.h | 6 +++++- > 2 files changed, 5 insertions(+), 8 deletions(-) > > diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c > index bddd77d810..3205277e81 100644 > --- a/xen/arch/x86/hvm/nestedhvm.c > +++ b/xen/arch/x86/hvm/nestedhvm.c > @@ -15,13 +15,6 @@ > > static unsigned long *shadow_io_bitmap[3]; > > -/* Nested VCPU */ (minor) I think this comment logically applies to the following functions as well, but since it doesn't add any value I think it's fine to remove it. > -bool > -nestedhvm_vcpu_in_guestmode(struct vcpu *v) > -{ > - return vcpu_nestedhvm(v).nv_guestmode; > -} > - > void > nestedhvm_vcpu_reset(struct vcpu *v) > { > diff --git a/xen/arch/x86/include/asm/hvm/nestedhvm.h b/xen/arch/x86/include/asm/hvm/nestedhvm.h > index ea2c1bc328..9e158bc5ce 100644 > --- a/xen/arch/x86/include/asm/hvm/nestedhvm.h > +++ b/xen/arch/x86/include/asm/hvm/nestedhvm.h > @@ -28,11 +28,15 @@ static inline bool nestedhvm_enabled(const struct domain *d) > return IS_ENABLED(CONFIG_HVM) && (d->options & XEN_DOMCTL_CDF_nested_virt); > } > > +static inline bool nestedhvm_vcpu_in_guestmode(struct vcpu *v) > +{ > + return vcpu_nestedhvm(v).nv_guestmode; > +} > + > /* Nested VCPU */ (minor) I think the function should logically go after this comment but again, it doesn't add any value so should probably just be removed. Otherwise this looks good to me. Ross > int nestedhvm_vcpu_initialise(struct vcpu *v); > void nestedhvm_vcpu_destroy(struct vcpu *v); > void nestedhvm_vcpu_reset(struct vcpu *v); > -bool nestedhvm_vcpu_in_guestmode(struct vcpu *v); > #define nestedhvm_vcpu_enter_guestmode(v) \ > vcpu_nestedhvm(v).nv_guestmode = 1 > #define nestedhvm_vcpu_exit_guestmode(v) \ From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:12:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:12:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457111.1670016 (Exim 4.92) (envelope-from ) id 1xJW6Y-0005UX-6S; Wed, 21 Oct 2026 13:11:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457111.1670016; Wed, 21 Oct 2026 13: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 1xJW6Y-0005UQ-3h; Wed, 21 Oct 2026 13:11:42 +0000 Received: by outflank-mailman (input) for mailman id 1457111; Wed, 21 Oct 2026 13:11:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJW6W-0005UG-HR for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:11:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJW6V-00GupP-UQ for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:11:39 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8ba06-bab6-0a2a0a5309dd-0a2a4509a96c-18 for ; Wed, 21 Oct 2026 15:11:39 +0200 Received: from [40.93.198.12] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8ba09-be1a-0a2a45090019-285dc60cc7a8-3 for ; Wed, 21 Oct 2026 15:11:38 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by LV3PR03MB8001.namprd03.prod.outlook.com (2603:10b6:408:27f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Wed, 21 Oct 2026 13:11: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.0546.012; Wed, 21 Oct 2026 13:11: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=mRFVlnUd67sZs0tWj5BMttspFSYmAXUojQrN/wvgcbybpdA+djRUTusVrqblAnn7ajOwo8B9rWznzKYBrFY1yXNgxFIwXkK7psWoRW481rEmhE/zA0iGj7ephRWX6HmAm1ijdO1S1xDIu/N03AAQDnTy9daFfKqBlr2uT9J9YJzbJYYraiskDArKHAMBee1XZqiYu7Sr5Cdj6dgl9j14PEFmh2eP6P8dDu8TRAdJ6ih1LPgUQIO4tlMS1+pqIVfxGCX+VOYQZbIINKVVZQj+RflPlaGvFXy7T3UG+Syvmk0lpkLxN5kzqyPPu6UY6gnFf2Q7E6NKb8FDue5FSBzR6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eMKq2hosY3n2Jkdt8BIfiPZxBfY4uYcPjsGcQxNPe2A=; b=BFh6Zcrf8gC9+KURAnSVrhlV7ZMjjH8TQ6Le7x06G7nnV/vdt7cus1MzV+B16y480pGtMV1NEd+iKnnG8Qn+1Lz/P2zOXpcqTdSCtjP+t8ENo+yz8om92fEkZth5k44QG1RZoINZRcY5FQVetbryqtuAmJ+xr66Dixy5tCc3J+BAA2uRMXFTIht5K8+b094ST6HPuf36ZubpuQSGTKEL+tzUl9vkL+TWC9idDfFpA0DhKQLQtkOZGKw+SeQGqVd+QgfEnGdaNBr5H+SGxTU3EnkyfzvohVKxNT66RJJ0ne3/uu84RFcH3wyv0G4hGUIPNG4bEgGP6TA6skkBSLr36A== 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=eMKq2hosY3n2Jkdt8BIfiPZxBfY4uYcPjsGcQxNPe2A=; b=o9nU0xGzDwoqqSHd22N/k7OZ8Qz8r06eJzuRDA/hPvScCPIIg0tgWM5tsqEkSCRlqMT9tn3je2RDFS5waQtXfNZKXdiyPbAUrh0SUERHTSb++JiAtRhh/fYOaehNoRgodCAXEZZQ4YliiXqLIcELVjWphfmG3hHPl1zDOWnddAU= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <26141f92-f6cf-459d-ae56-e010db9062db@citrix.com> Date: Wed, 21 Oct 2026 14:11:30 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86/hvm: Propagate emulated CR2 writes to the VMCB To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech References: <20261020213315.3641133-1-stefano.stabellini@amd.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: PA7P264CA0003.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2d3::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_|LV3PR03MB8001:EE_ X-MS-Office365-Filtering-Correlation-Id: 1eebe9ca-c5c0-48d3-2a0a-08df2f74d57f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|56012099006|11063799006|4143699003|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: WRKTsF3Ul6DkQIjVmuYKIXtUrwf1CdvIRxwZgRQUZT3TotvIf7e15l7X89WQUex188LXlt3OhkGfH2iOrAhMit3p5Ipdtqi9Neqa64rPJAtYDrcUPw7AIUIuQOutS53EOCLLNai+W9A4pJ4WcLw+IgCjjoRVZHoaoE60X34zV6VQKlbwYRadAzPE7EXlFQhgFn6+v2zCDtFOnBo/+lDIRtv38meZEQnSIQcMQfK6ySh2fE7Gk29QKiTqEmetLzo8u5+zYDXchDzPwQCaTgt6sllrvzm/87hXx0Fmcq44EXETUMZy1fNyxWhal7mUSV1lM/4tN54Tl89AxrVSwX2rinnyiZMhPFqkk/pmyG1b//Fmwc4kcoCu8M1i17bQ2djq87kIcTYnU6xr6O7Q5Etz6AqLlnJ8a/ekEDhxccqmtSGkHIEgUxD4p+Pmz6TW9/PbdwhOgO6k5DOKv15vK79J2cM6YqTgmBkxpbW6ccCQHFc+i7vi7lGNI9+EQTCFShSQChen69Io+biyfjMldfC9GqoCTgLXjy4oZn/t98EXLk4R1piEKJz8X6PlHjIvA09aZqiUEs/KCkaQP8F/88EIbbcRypc0lSBmNpAxsPZRLxkKqznpeBb0UiqhuGF9ilH1QKnUxqjJt22XmbesvTNExQ== 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)(376014)(1800799024)(366016)(56012099006)(11063799006)(4143699003)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eTZwM2NkTFJoZEpXc0wrWmhWaWk4dmw4UWNrc1dVZjkraCt1dWxPTkxPdlhw?= =?utf-8?B?bWJkRUVsSyttdWMzbGxkWW45MmxIdFJreGUxdXhPNEFwUW5zN0pQSTE1bktK?= =?utf-8?B?Q01Bc0JWNVAxQ2h4WTh0cjF0dWVSalM3ZzNuVER1MWpmUU1rV0FhQjRnSnhi?= =?utf-8?B?K0RCZXdRRlVUZDkwYWpNL1NlcVdFdVBjd1U2MThzajJxY2tQZ0NkM3BQT1hk?= =?utf-8?B?ZmhUeHV6NFpvTGFWZStBcTVtVlBaeFZ5dHZKV25RWUtzbzh2ZWU5OWFQVk1p?= =?utf-8?B?TnNJSkJETmhrSXVrNjRkT2Fwd0dhTlEzQXAvTit6OUhUWUVLVFRIQmFDV0wx?= =?utf-8?B?aDl0d1pYamFtSnVSUjgzQ2VMR0V5MGk3T2NUd2JHRXlXemUxbVFBRndmcXU5?= =?utf-8?B?MUppOERxbVZsUjZmMHJrRGpmYUhiUStldlowRmNkck1lVUF2WXYrYlhBditt?= =?utf-8?B?enNHdkZGTDYrZHdOb3RIQXo0RkFjMXZwNkpWbWxQY0pnVGxCWmx4TEZxNU5r?= =?utf-8?B?akV1MU9tblVJdml5STJRTHF4TDhDaTIyRWI2bndzOTZtSG1uUzZ2ZnBvMmpm?= =?utf-8?B?S2VpM1lSbE5jWG13NnhBY3ZWSTIrVVJTc0Z6RzFYVEVNeTBtTEF4VCs0UGhn?= =?utf-8?B?SEtVYlV4bWtiUEp4MDZrNjVrU0dzV1FFZ29pMjJKeTZIakRSdnIybmZucDFw?= =?utf-8?B?V3c3RnhjaU1yWG9BVXFrMHRXOGdka0V1SndlRjl6MUpRQnYyQVNtN1djU1pm?= =?utf-8?B?dVlLRWl4ZWhzWUJyMUtZckxoNmZFTnJXL1FscmVCSmgya24yR0ZnZWZ3MU83?= =?utf-8?B?TmdDRC9qL201aWxhV1JtUmM1S2g1anNYRW9tcTNVdC83M3ZuRU5YQUxkNWZR?= =?utf-8?B?bndLNGZqREdNZk9LS3M4dHFUMGJsdGV4Rk9McDhUcWl5NFRQYmJlcTEwQTU4?= =?utf-8?B?T2hxdEtIRXBKWGM1L2pTK3FLWkkrNm52aUVoeU1yS1pXNW9GYWd3L1ZNazcx?= =?utf-8?B?emRPaGFtMVBWdklab0g0SjhvYVZzMWhIQTBNZ0hacDlGZXBjdzVKREVsK3BI?= =?utf-8?B?VVZXZ2J5RmhFSXdUZEFmOW0raE9sa3h1L1N3WmRhNUljaFFZSndNV3JuQTJF?= =?utf-8?B?Y2Z1a0hLaEVnM0ptMjZ4clRhWjVHajdmRXFhdFVTSE1mYTJ6SFpIM1ZteVhI?= =?utf-8?B?TkNkWE1YNG8ySFY3Uld4TjVZdmlUMlVRMjVXenhVYVNjYjY1emF6YnJ3Vmh3?= =?utf-8?B?K1dtWUJ1WjJxSmhEL2NVWjBPOWIvdm84VTRTQXJHNEt2MkhyVmRZZUd6REZr?= =?utf-8?B?THJRV21keklOOTBmaUw1dVp5T3ZLNkd4RWdkYTZFdHNMczdEU0VNK0htQ3pJ?= =?utf-8?B?d2hDOVVGTjRaU0ZzdS9yakxBVmxPWGJpNEZ6V0FMOHRXdEE1UzJEUHJqVita?= =?utf-8?B?N0R1OTJJTHp1U0dhcndiSEJoRzFIaHN4MWh4cWV3UlBVVnFnUDBuMGpXNVRu?= =?utf-8?B?enZOUHBaeXY1NWNDWEl5MndubnQ0cU5TOHVNYmROb3lyS2F6a2hod0tOaGJs?= =?utf-8?B?N1VJOWtYcWIxb2htaVl4SE50TDk4S01wNHpFTjNnNnd2NEtlM1NJZHRWSGs1?= =?utf-8?B?OEdBTnZ6T3lFUXRrb3VYWDFxZ1JkL0VMcjhkakl5MjEzMGRkc2xOVnNJVENQ?= =?utf-8?B?U01uVkdQR0tzcGEvRlBpa1RrU3MrcW5lZW84NEJPRFNONGNJWm1zSGN6MVl0?= =?utf-8?B?bHJTVy9BdVA3MkJpeUY4Vk0wRnBBeXlaakhzT2RzRDdmV2VzWmZVVG1QOHNG?= =?utf-8?B?SmJweU84Z0VteUVLcEc1ZXFxdlZrWFZEQWxrYXpJTkhiaWxBc2czK0kveWY2?= =?utf-8?B?YUVzTG5RNHZ0L1BHZGpWbWF4MGYvaDhkbWhiNHVqNnNnVG9GbFljczZ0REV3?= =?utf-8?B?andqMmhTSTZKQ3NrMmJDYnIxdHBTS3FGVjhWZ1JDR2lCcDdPUFlnQjYrZlVV?= =?utf-8?B?NUQzaHBDSkg3VkszYXVyMlZKT0s5eDl2ck9oTFB5T0FVajgrWUJLakdWM0x1?= =?utf-8?B?Tk5GUTV2YUM4eXB4TGJGbDBaajFIMHphU28vc081eVo5Mlh1cjZYMkhaWVNK?= =?utf-8?B?T1pOUDFVS2xOMjNHZHl2UC9tK0VFM0N0Q0NPa0wyc3lZdDQ0SHAzOHo2V3dY?= =?utf-8?B?aUszVVpKSXVBUEhGRXVvNEpPY2k5VFZBZWRyZnpydzM0L0lLNkxJZk5hQWg4?= =?utf-8?B?QmtjZ3UrRkMyQUViUWFjczllRXd3UUtwVTYvZWtpN3A3Qk1NeHdRUUJMN0Fp?= =?utf-8?B?YmVvU1FDcUQvYngwSnFha3pYZUhXWXVEeW03RkRvZXJCZFFiTFJydlhIVXRT?= =?utf-8?Q?zbiXHk2PcK56Khww=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1eebe9ca-c5c0-48d3-2a0a-08df2f74d57f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 13:11:35.6222 (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: r18jCe0Jd+DvluPJYOdbbjPELPGFBzyP/slmwzpvIxXha7l6QNIqBdHyKq/KnOs3ePb9fgjeHhCXyQvgQJhjHeLe9h6nk4YJnxQ+Po/nJM4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB8001 X-purgate-ID: tlsNG-bad1c0/1792588299-BE4DB034-1524EAD8/0/0 X-purgate-type: clean X-purgate-size: 1444 On 10/21/26 9:19 AM, Roger Pau Monné wrote: > On Tue, Oct 20, 2026 at 02:33:15PM -0700, Stefano Stabellini wrote: >> hvmemul_write_cr() updates guest_cr[2] but, unlike every other writer of >> it, doesn't call hvm_update_guest_cr(). On SVM, CR2 is loaded from >> the VMCB, so the emulated write never reaches the guest, and the next >> VMExit overwrites guest_cr[2] with the stale VMCB value. >> >> Signed-off-by: Stefano Stabellini > > Acked-by: Roger Pau Monné > > I wonder whether there's more missing here, see below. > >> --- >> xen/arch/x86/hvm/emulate.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c >> index c09ea002ec..cd2831d34b 100644 >> --- a/xen/arch/x86/hvm/emulate.c >> +++ b/xen/arch/x86/hvm/emulate.c >> @@ -2350,6 +2350,7 @@ static int cf_check hvmemul_write_cr( >> >> case 2: >> curr->arch.hvm.guest_cr[2] = val; >> + hvm_update_guest_cr(curr, 2); > > Looking at hvm_update_cr(), is this possibly also missing a call to > nestedhvm_set_cr()? AFAIK the values set by nestedhvm_set_cr() are not used at all with nested SVM and from a brief look may only be used for CR0 and CR4 for VVMX. So maybe it is not needed, though for consistency I think it would make sense to replace both lines with a single call to hvm_update_cr(). Ross From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:15:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:15:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457117.1670026 (Exim 4.92) (envelope-from ) id 1xJW9t-00068g-Kg; Wed, 21 Oct 2026 13:15:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457117.1670026; Wed, 21 Oct 2026 13:15: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 1xJW9t-00068Z-Gt; Wed, 21 Oct 2026 13:15:09 +0000 Received: by outflank-mailman (input) for mailman id 1457117; Wed, 21 Oct 2026 13:15:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJW9r-00068R-7h for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:15:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJW9q-00GhSu-Cp for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:15:06 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8bacc-e002-0a2a0a5209dd-0a2a4506dea4-48 for ; Wed, 21 Oct 2026 15:15:05 +0200 Received: from [40.107.209.70] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8bad7-195a-0a2a45060019-286bd146db11-3 for ; Wed, 21 Oct 2026 15:15:04 +0200 Received: from SJ0PR05CA0055.namprd05.prod.outlook.com (2603:10b6:a03:33f::30) by DM6PR12MB4265.namprd12.prod.outlook.com (2603:10b6:5:211::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Wed, 21 Oct 2026 13:14:57 +0000 Received: from CO1PEPF00018869.namprd03.prod.outlook.com (2603:10b6:a03:33f:cafe::49) by SJ0PR05CA0055.outlook.office365.com (2603:10b6:a03:33f::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Wed, 21 Oct 2026 13:14:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF00018869.mail.protection.outlook.com (10.167.249.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Wed, 21 Oct 2026 13:14:56 +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.53; Wed, 21 Oct 2026 08:14:54 -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.53; Wed, 21 Oct 2026 08:14:53 -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.53 via Frontend Transport; Wed, 21 Oct 2026 08:14: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=dBM/omIy8G+wPF+FVyn8uZSZN45RnR5kl78ybfsy//uwf21btWWkKqKcW4HxDDuv9jr3h+j6pTAmp3yxi5S8B1ERqIv0S5STcx9SNHzmX9K6b8H9Au+euWgKPZLHMCPLDTquuTg+IoSdy9cEpWxJU+DsQUvbrj0NsUr0uDj8YaXATl+YO0TZBVbslgM4TSmxiSXdxLSaOwcB3fMKIPm7SvypFzVvltDFzVa1xPiy1Q1l2Genm5WBVn1u16iIKxtINsSdzPuMUNiST1AjtnfxZv7PFwFL/oA/G6I68pCzd24f8cIYYH131c9sh1O1jdiwrbiCNoaEFknpDqIKdTGIHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VsRJxPyWjlAnynPvNNxxCA/5BkznntMByV7OjIfvvtA=; b=eBx4oWfxq6qgW+H7J9RPbtnp3oDGltoKjMBlwhY4Nb0GsGsMexDuTqq3nnQ+zvBQtNZd1vJBpnskjkwejxxFdtIPj7HMnw2L1lxIlkujyoPW7K3bsmgrgNqdnVdFJXlCxwTthhkyqprnOkz4x/n09tqqa6hq0nb2/rskegq5x5rVcgEOs30AusWz/aZcv47m5VjZL8AjrDnwpwv6JnjK193TtLRSrxt3/4mwIx3/ZKtTLwMBqC8prtMpBitoHs2lLxdJRL4PJC4xj9fS45xrx9fMuWfRovsgGqRzo5pOYVVmBHorve2TDP/1QUPbLQ/ZBPMaDzvHP+Jjk+Kk0CD3PQ== 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=VsRJxPyWjlAnynPvNNxxCA/5BkznntMByV7OjIfvvtA=; b=ORYYAfwLbfwnYWf5kuLYSo3A0AYaqqQ0AzTSLe50hqTVnZXhPwjhser9TrYAAkacxKO7uhWq0gN1fq4ieeiErKy780fDCWuRoX0U7iZH8tMH+4DfE+muy4BntVQlunpEJI8gIezslC8Vj0YjYrIpg/24yBOL0twiaAkiVfjG90M= 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: <0d758d59-1ac3-4833-aae6-8c181d5ec1e8@amd.com> Date: Wed, 21 Oct 2026 15:14:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 2/4] xen/sched: Link CPU topology to scheduler To: Hirokazu Takahashi , CC: , , Juergen Gross , 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 , "Oleksii Kurochko" , Dario Faggioli , George Dunlap References: <20261019015749.48492-1-taka@valinux.co.jp> <20261019015749.48492-3-taka@valinux.co.jp> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261019015749.48492-3-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: CO1PEPF00018869:EE_|DM6PR12MB4265:EE_ X-MS-Office365-Filtering-Correlation-Id: 5588ce9a-4b70-4abc-e382-08df2f754d9f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|7416014|23010399003|376014|82310400026|56012099006|4143699003|11063799006|261009223027099003|22082099003|18002099003|6133799003|10067099003; X-Microsoft-Antispam-Message-Info: zgke9+uXsESTuK+b+IjWrDDg8CBEokNSUUwbcdJY9ynLcrSztD32ohAYPXsPWIDF3MgYOO5dd2Sr4wiWjb/8yP7r8ptc/tjSY70Ie4hMw30GlKsUbjBiu9lwioeGfQnFGRbVORR9sOLmtW0eGomP06O9ImOUvY/j0/jGcw579r2N/zcNDG3br0pNl3qFG6mcQyL+9/UHVFSOpiEmqusQVAZHQNV7MlGODAphCbM61I9lw4SycQEpxfRHfREmhvZixYFZhNIiO3S/R77y1ZgVo51Rf2cWK3WE0Qnfj4OMhfd3oyBR/IlBcsOgaMrH4NAgHPQqWtF2g0DRU2NgDHW8x701F1WI7HDaEzLfg105eNEt/XTFIhhmGDhtgQU9+ihNWg+JA6PUJRlMUwqQ1LjuqQpqTwyhKuvSzgJldbOBvUDI+mhO92E15QofMm0mNHfgPJExxU6fya6mmb35ZB9z9LgtjvpURRX2iRBduYH1HGX76A12wR2iGta56aDDoRvuILZz3ilM84Ps637gMwmHt78uc5LwuZ+a10nswDs2UgKumFwJhnEu0/3oq79xPunXv3ln5tGQM23W2XC027ju/EtHyuLLi4LRUlMOvJORLL8U7vWIjOQMbNWIDcjs3VYqlqMaUMKWl7pDyAegkRrRmEh1KKtpB4xoPQenm0GCka8CiP9nqebLICopLci8VST2nNmtq03aXBnVF7aZwRbiQw== 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)(7416014)(23010399003)(376014)(82310400026)(56012099006)(4143699003)(11063799006)(261009223027099003)(22082099003)(18002099003)(6133799003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: UaSkD4HOnxF1TEXJujx5ntav6ra1s/z6uC2NsJvNu44ChEPRbD8kUVOZYPgPW2ojA30x/fJGbnB9EkN04dP6UFoBjik5NkYv5JVu6zfrfANdhKU41DzPFE41yfjFf2yvJjRub0V/+4VQBVFYItK3xtOJNW454QTcMPjnqbXvAXgAhBSrELBFuLzKasKCYoiG16wydEeF3piUbvhzh5Hzo5asCKatWjsCPJHhxAP64kx3wSI62VzMJwcwBWQ8KGL4i6t8/sz+e5jpi1RxZrJwBe67420g/6CKPE6TglvH3XwADYBTJ+GKAp1xiWBKSYJRLw3iiSs1Fnf4Gp6M0eAQnEEB+tjGWwisfaHztxfoprfd1KHhY6G7gkGLzxKMBOYS4tTp9qzIEiE0dbnI0QaFhZDOWsZoko6sySwyWkW3e/Y+V9nfv7NTRgEDwCJ94IsW X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 13:14:56.9081 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5588ce9a-4b70-4abc-e382-08df2f754d9f 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: CO1PEPF00018869.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4265 X-purgate-ID: tlsNG-16d1c6/1792588505-FCE0677B-A262FC2D/10/78276251493 X-purgate-type: spam X-purgate-size: 9298 On 19-Oct-26 03:57, Hirokazu Takahashi wrote: > 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 | 41 +++++++++++++++- > 9 files changed, 115 insertions(+), 21 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 d34396f9b1..cf4858eb37 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -93,13 +93,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); The comment above the cpu_sibling_mask definition is now stale. > > 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 bfcf153cc4..b7b1acc73d 100644 > --- a/xen/common/device-tree/cpu-topology.c > +++ b/xen/common/device-tree/cpu-topology.c > @@ -344,6 +344,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; > + } No braces for single line statements. > + > + 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; > + } No braces for single line statements. > + } > + > + 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; > + } No braces for single line statements. > + > + topo->num_siblings = cpumask_weight(topo->thread_sibling); > + } > +} > + > int __init dt_init_cpu_topology(void) > { > unsigned int cpu; > @@ -353,9 +414,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 c32e753bb4..335cadb8b1 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 f9836447b2..32f5b97c3e 100644 > --- a/xen/drivers/acpi/topology.c > +++ b/xen/drivers/acpi/topology.c > @@ -24,6 +24,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 27b9bd443e..52ee93d4d0 100644 > --- a/xen/include/xen/cpu-topology.h > +++ b/xen/include/xen/cpu-topology.h > @@ -3,23 +3,60 @@ > #ifndef XEN_CPU_TOPOLOGY_H > #define XEN_CPU_TOPOLOGY_H > > -#ifdef CONFIG_GENERIC_CPU_TOPOLOGY > - > #include > +#include > + > +#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; phys_cluster_id and cluster_sibling are only used to compute each other. Are they really needed? > + 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); cpu_topology[] is built from all CPUs, so a CPU that then fails to boot stays in its siblings masks. I think a CPU should be added to these masks only once it is online. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:26:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:26:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457143.1670033 (Exim 4.92) (envelope-from ) id 1xJWLD-0007zK-Mj; Wed, 21 Oct 2026 13:26:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457143.1670033; Wed, 21 Oct 2026 13: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 1xJWLD-0007zD-K5; Wed, 21 Oct 2026 13:26:51 +0000 Received: by outflank-mailman (input) for mailman id 1457143; Wed, 21 Oct 2026 13:26:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWLC-0007z7-6U for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:26:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWLB-001NGB-Hs for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:26:49 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8bd88-bab6-0a2a0a5309dd-0a2a4502c6ea-34 for ; Wed, 21 Oct 2026 15:26:49 +0200 Received: from [52.101.43.47] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8bd97-6ca4-0a2a45020019-34652b2fdf00-3 for ; Wed, 21 Oct 2026 15:26:48 +0200 Received: from PH8P220CA0017.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:345::21) by SN7PR12MB7297.namprd12.prod.outlook.com (2603:10b6:806:2ad::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Wed, 21 Oct 2026 13:26:43 +0000 Received: from SJ5PEPF000001ED.namprd05.prod.outlook.com (2603:10b6:510:345:cafe::39) by PH8P220CA0017.outlook.office365.com (2603:10b6:510:345::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.16 via Frontend Transport; Wed, 21 Oct 2026 13:26:43 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF000001ED.mail.protection.outlook.com (10.167.242.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Wed, 21 Oct 2026 13:26:42 +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.53; Wed, 21 Oct 2026 08:26:41 -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.53; Wed, 21 Oct 2026 08:26:41 -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.53 via Frontend Transport; Wed, 21 Oct 2026 08:26: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=lyMj/SB40cbmlvBTJVIBTujiYyEwA/mu/ZqDm4NnXKPPLXJopHqmNpYJl+cvcvOSzrRFidfYhIFUlTRsa0QU+RQ9/I+FW14mdHVePkXQVXOk69m+d06/MT+rDKmiQ7HbU9ieVfg92BMxkPlkL5/HJRr0Mgft+bkJzB5EywaAEEbALNoTK71F91ZT33BbQ7F1ao0sY33PuqZ8xiRHT9mLHJlnnvj1TRnbINOqY9KwFJRTidPB2G+VCrdaqBreoNjPBRFreIptawyZ3PnxJb/ttQ4E8QrScACwF6am2EGthpMqHbDWs1krSXXBAccWG3IUCsfAJYyZN87RIOH2PN1WAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DY/wsFYYvEngNEDjTFM23GzUCzWYAhBmqOOoe/FCJ2E=; b=Rj2jOKUAEgUsYiFxOmzdaB+qv7nal81LnElEunChCPKZYe37xjTvRmUugRU+YH9wtQBYLdKV/iBuTWKZ23M9dc8R5Gxs8ZyxO2BZZdGQQKACm8LTAdOfk217QCVeAX1ecojCjXrMD+iIlNd33CZ1/wZIUichbzvzs0nhgj+pKrI8Tdys7dsgnWHzJFz58lgPpsNzvoe7eBdCOoqzIxHmxZpVE02TJOIMFdoP4QZH1ITlV+iBjEiV+zbu/pU25ILNe6mk02HCh20msKmLVzsVTQA6KEWz1FNgNUjgUBqs/x41p3XmiGSeqlocdKmex12yeknJx4bPDrXDyqAHK4OhyA== 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=DY/wsFYYvEngNEDjTFM23GzUCzWYAhBmqOOoe/FCJ2E=; b=sjhOnl8N8z76SAkkjV4PUkG1Xk2GmXId1oHWgd1qgRwxtzBCT3jJng/kr+rHt1lE5Ks8ByeQG4tk0tNq8ZIbLg0ymYBSRx4NSUoL+l0WNmc2rallfWm5XhoudlZe7itk4SfTFiXNtFd3MAirlb9oMYGmKtHuj1w3ErstyV/5YjI= 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 From: Ayan Kumar Halder To: CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: [PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver Date: Wed, 21 Oct 2026 14:26:40 +0100 Message-ID: <20261021132640.599126-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: SJ5PEPF000001ED:EE_|SN7PR12MB7297:EE_ X-MS-Office365-Filtering-Correlation-Id: dfdd28c8-0767-4499-0350-08df2f76f23d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|1800799024|376014|36860700016|18002099003|10067099003|11063799006|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: Syf95CC6rIBWxHdyU+w4CU9gny3gZ3tjCIRo9/z4k/+IkKBrKJcFCStPjEwh3lnnCqp3doSBu7R7389BbfoQyGYrbCi3B9t+hwVoSEzfSFrSUkcD+LSGVv49ojXTwPeZV1JFwKCbfEFu15h6c/59AInhTwCrBXoRoUxcdrGYsI0laZBWXQ+Ka8eJGQzS7ujg7gYmOYTq2X6GWshmniujYdihi84GZm8RmM4grwjEFYpaPxbb5v8glqWE7PMuEpsycBQ8njYrlmuCfasgDGZs/209IxHcgF1B+0wqTCcTs3LjEFnn4zneewJZLOdViWEpdtbxmyWFNzvcvS2fnTJ+FyFNyDUrZRFWE9ZwFwyZUBWDJsBzU5XcqtR+nMbaSbegEnK0QA5T4gdxI39gylu7c+nCTwceg4vnA6i33qBJOIHMY3hsdmVW/tC31dEm7plkmy7TvaBXz6/d7I96g2TC+G47LgHzYAMLYVGTI3QWdQ986jRk4BdwNc/6HRWAl5HYQZqcQnQ1p2f1T9t93g0R4F4HxhF0YAV3MuEy3Ob6IydxklFe7wAWsK+TM9b3x/Uxe4N6bcVaqHlGXdJCstTb6C+TCsHSzsNx5edq29R8hZpkhWKvyKqafdK4rDz4/Yq6JrqOWXKiylwjJ6beHt457+ndovvP7qP0hJ1nFxOqe1XL1gu5ZMfmfoEXBwoEmAAKRoG5TGpf3P/lrx0RBP/rGg== 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)(23010399003)(1800799024)(376014)(36860700016)(18002099003)(10067099003)(11063799006)(261009223027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: svub2mBRevRCQjkXpaagDN5rdiUX/Ao+FUvbpxKEM5d9TO66+dH5SAo//nZ4aooMcarI0fW1d49gsxmPLttQrGfB0pmb6p0T4ORrM2X6aedxGpEF1oFHemu70cFJK2VPQNCQtTf2rPElzr/weI4W+PhilU+L0VEZgvMORGdZFM82ULeWzElT+d8w0PuPVNr81dXyZSoYZUYTly95JLU0KbfE9FEwZhhWvZ4UkkDox0+ijDv2H890CWfUvHLt3J85Gkr3fIZ/I6VQVjZtkEUrXNuHhQ+9IffLyOdksC0VVxF4fFRp8zSPvoPuOTt66D3H0lj9l/e3DVTnGuXV3el3JSgD+aXrE6exHSGrfjgb5X7UOeEEA32Jdw9RFfm4B1VnOGUcw8JDgXvQ8kVa0bCjlMzNrNXc5WaRZzNDXuT42lrDEzKpIoBAUel2LFhKkqS6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 13:26:42.5337 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dfdd28c8-0767-4499-0350-08df2f76f23d 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: SJ5PEPF000001ED.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7297 X-purgate-ID: tlsNG-720697/1792589209-F30B02AC-6273D795/0/0 X-purgate-type: clean X-purgate-size: 3071 psci_init_0_2() stores the value returned by PSCI_VERSION in the global psci_ver before checking that Xen supports it. When the firmware reports a version other than 0.2 or 1.x, the function prints "Unrecognized PSCI version" and returns -EOPNOTSUPP, but psci_ver keeps the rejected value and psci_cpu_on_nr stays 0. psci_init() then tries the PSCI 0.1 fallback, which overwrites psci_ver on success. When the fallback fails as well (the /psci node is not compatible with "arm,psci", it has no "cpu_on" property, or Xen boots with ACPI), psci_init() returns an error that smp_init_cpus() ignores, and psci_ver still holds the rejected version. All the users of psci_ver then consider PSCI as available: - on arm64, smp_psci_init() installs call_psci_cpu_on() as the method to bring up the secondary CPUs; - on arm32, platform_cpu_up() calls call_psci_cpu_on() instead of the platform specific cpu_up() callback; - call_psci_cpu_off(), call_psci_system_off() and call_psci_system_reset() issue their PSCI calls. As a result, Xen brings up each secondary CPU with an SMC using function ID 0. An SMCCC compliant firmware refuses it, and Xen reports "Failed to bring up CPU (error -1)" for each secondary CPU. Only set psci_ver once the version has been accepted, so that a rejected version leaves psci_ver at 0 and Xen behaves as if PSCI was not available. In the case above, Xen no longer issues any other PSCI call: on arm64 the secondary CPUs using the "psci" enable-method are rejected by smp_psci_init() and Xen boots on the boot CPU only; on arm32 platform_cpu_up() uses the platform cpu_up() callback, if any. CPU_OFF, SYSTEM_OFF and SYSTEM_RESET are not issued either, as when the PSCI 0.1 fallback is used. Fixes: 4d3d72c01467 ("xen/arm: Initial support for PSCI-0.2") Signed-off-by: Ayan Kumar Halder --- xen/arch/arm/psci.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index 634d0d7467..a720cf8d41 100644 --- a/xen/arch/arm/psci.c +++ b/xen/arch/arm/psci.c @@ -169,6 +169,7 @@ static int __init psci_init_0_2(void) }; int ret; struct arm_smccc_res res; + uint32_t ver; if ( acpi_disabled ) { @@ -191,16 +192,17 @@ static int __init psci_init_0_2(void) } res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION); - psci_ver = PSCI_RET(res); + ver = PSCI_RET(res); /* For the moment, we only support PSCI 0.2 and PSCI 1.x */ - if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 ) + if ( ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(ver) != 1 ) { printk("Error: Unrecognized PSCI version %u.%u\n", - PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver)); + PSCI_VERSION_MAJOR(ver), PSCI_VERSION_MINOR(ver)); return -EOPNOTSUPP; } + psci_ver = ver; psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON); return 0; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457175.1670056 (Exim 4.92) (envelope-from ) id 1xJWeu-0002uU-Cr; Wed, 21 Oct 2026 13:47:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457175.1670056; Wed, 21 Oct 2026 13: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 1xJWeu-0002uN-8e; Wed, 21 Oct 2026 13:47:12 +0000 Received: by outflank-mailman (input) for mailman id 1457175; Wed, 21 Oct 2026 13:47:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWet-0002u5-It for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWes-0065Kl-W0 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c24b-2eae-0a2a0a5409dd-0a2a4501c87c-30 for ; Wed, 21 Oct 2026 15:47:10 +0200 Received: from [209.85.219.49] (helo=mail-qv1-f49.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c25d-5984-0a2a45010019-d155db31e12d-3 for ; Wed, 21 Oct 2026 15:47:10 +0200 Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-91befbcad6dso13332836d6.3 for ; Wed, 21 Oct 2026 06:47:10 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.240]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91c10c5002bsm24928116d6.42.2026.10.21.06.47.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06: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=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=1792590429; x=1793195229; 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=qblwx7bbNy5k368b4HO2T3MytVs1L8oRqcYO8Zy3rtU=; b=AIBe8EmnLp+PQkWOowuEEZgdgewZea7OG33/ad/7yJZOoKkrj2fgEl9ThrZLuqmDKj v7h/XwB+qeuTUxAMTNMnBA7WI0JiY9BGvrygNTBWDh1GzietlHT5ztKgK53cb/6VeGXP h0+pa0LdK4H+Nhhy+nZQYFv4L07/kGZWEMk62aJPhY0xB7ZapLKS2DeXhLdCxUmdm/qA 9EJ760Y7nCrnJy/v1Blj8elkCnfYyXuZqydjolCA11uFpCXDSAVYaiSzEElcOT8AAbNp IZBq0A6oDlxc4KxGlPUnXI3EDhk2aPI/FlZFCSpoQ+9WyjcAm476L1l7We8xee2FiZ80 xaug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590429; x=1793195229; 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=qblwx7bbNy5k368b4HO2T3MytVs1L8oRqcYO8Zy3rtU=; b=QgfUbH2pCtm3R3NepIQygoCgm4Xy56un8rOueDhkyCkFisCDH/f15XpX5CijhdXV30 8wU8iO+MiuRyBMgX15BjXSZB/iiroHoClFMNvOVUq6JUstt1vPTuPbYDVaDZ1kDg43ZV f2I1l32URwn282PsK7gYJQf0pVcW9Id7wSkWNTVNo7j2CiT06I8SHLmQMUAUy+jz9vzP BZ2pvBziBAP1s784NmYkMmIareo5+EXrNHOYE26sVJDTMKorUCXa+xDOhBftEoY54r63 Ev01U+Pa7NbJVqXP+ZztToMVF18reV9MACDEUZkyMnDvb2WURuCwXZR2CM3DAA9qUE/9 fQ2Q== X-Forwarded-Encrypted: i=1; AKwUvByWpVdZFTFfblA+FTDhZjvxaGZJ9I4Et4WFoCpdQaO5xzNDjw9LfMY7PjlOPc+xM+Vq3e3WVUn3p2k=@lists.xenproject.org X-Gm-Message-State: AFq9FYIGGZpxSdM2M14x+nR9lcWabEWuigSKuK8dgCQcP6zP3tarzGYI t5GcrRl2KQHrsqfrNjY/zS2yBU2PQ2oq1l4CM72ZPqZXNF0w/fnSQ4HRFvUyZR5lHTY= X-Gm-Gg: AYBFou0KUQgWDXiVqrBq2EYv1Mur7VPQnZPFhuagmGsfbikNOr5HTV2CybwIwxX/dl/ NcKQz5J4cHAtEMiQYuIZm+d3Y9oPPn5Cl9SuKly7QIkzke4TbKij31shf3Ru+DIU7uJ/3eZJ6x6 J5gfIOGtE3Z+X/hCGVYp1lNAerxmLLY8YaHL14vW7mn0Ynfu3NyF1+6GnB++gKgi8rqH4wh4oGu EAfzq34+Z00+kEJPEoSmVQbVJ7r+hWIUHp4Kgrik+5mIO82MyD8IXCebytIkEwFCPkJMjfWXiwF jdKt6Dp5fCSR7EK16fsGipMo4MSRZOJ/7T9Xr2U5nLXWju2pHzv4hqsrHm2IAZWaGq0CiZcCTMT OmzEsRJaJg6PMCIZZgtqRV90dzoNcKT5TCLPTZcQicFyHeSS5cFsgYoL739wdxNHka4UURW6HuW NlGa2x9NjtPY55Ek54GcSaJyz55xTtfpXT8fqEPQk/mHZY5UvSokK+ErIM9Y4g9jiQYFvhlV2X4 kvuWZi7rs8ZAkxiixsREYmtZ6Pg4hc+JnZ+XzKNKa51uDJDVrz7YnwVYo2roCj8j3+MUZfi X-Received: by 2002:a05:6214:4b11:b0:917:fadc:2f21 with SMTP id 6a1803df08f44-91c12f01d19mr33872926d6.41.1792590428703; Wed, 21 Oct 2026 06:47:08 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:45 +0000 Subject: [PATCH net-next v2 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-1-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590422; l=13888; i=josef@toxicpanda.com; h=from:subject:message-id; bh=dL3q9YRxfCrEbWcizXq9oznfRWHecZyPcn5ovtK2fxY=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLjOa2jk/RqfHBEHNl98PapaCIgqg156sTloid5SLqvbbvhKLKBISHp0ZjIrUQ3V73NPcL7eVfA LaF6it8760wk= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1792590430-C495A757-10095E1D/0/0 X-purgate-type: clean X-purgate-size: 13890 skb_copy_and_csum_bits() has no way to fail. When it reaches unreadable frags it zero-fills the rest of the buffer and returns 0, and since commit ab9414ed70bd ("net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()") that 0 is the correct checksum for what's in the buffer. Its callers can't tell the copy didn't happen. That matters in the !sg && !csum branch of skb_segment(). A devmem TCP skb keeps its whole payload in unreadable frags, so every segment ends up with a payload of zeroes, tcp_gso_segment() writes a valid TCP checksum over it, and the peer accepts the zeroes as stream data. This is reachable when both SG and TX checksum offload are turned off on a device used for devmem TX: sk_setup_caps() still gives TCP SG and HW_CSUM, so the dmabuf send is accepted, validate_xmit_unreadable_skb() lets the skb through for a NETMEM_TX_NO_DMA device or a matching binding, and software GSO segments it with neither feature. Before that commit the segments carried uninitialized memory with a checksum that almost never matched. This was reproduced with a test module rather than on devmem hardware: skb_segment() on a TCPv4 GSO skb with 3000 bytes of payload in a page frag marked unreadable, with features == 0, returns 3 segments whose payloads are all zeroes, each with a checksum of 0, which is correct for zeroes. There's no warning or error; the data is silently replaced. With this patch skb_segment() returns -EFAULT. Make skb_copy_and_csum_bits() return 0 or -EFAULT and hand the checksum back through a pointer, and make it __must_check so a new caller can't ignore the failure. Running out of skb before @len returns -EFAULT too; commit 417261779eab ("net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()") made that a zero-fill and a checksum of 0. Each caller takes the error path it already has for a failed copy: - skb_segment() fails the segmentation, as the csum branch already does when skb_copy_bits() fails. - icmp_glue_bits() and icmpv6_getfrag() return the error, so the ICMP error isn't sent. - __ip_append_data() and __ip6_append_data() drop the new skb and return -EFAULT, as they do when getfrag fails. - vnet_skb_shape() fails the same way it does when its skb_copy_bits() call fails. - xdr_skb_read_bits() returns 0 without consuming anything, as it does when skb_copy_bits() fails, so desc.count stays non-zero and csum_partial_copy_to_xdr() fails. csum_partial_copy_to_xdr() used to checksum the bytes it hadn't copied before checking desc.count. desc.offset and desc.count always add up to skb->len, so that only ran when it was about to fail anyway, and on an unreadable skb skb_checksum() would WARN. Drop it. - skb_copy_and_csum_dev() can't return an error, so it leaves the checksum alone and the frame goes out with a bad one. Its callers are drivers that never see unreadable skbs anyway. The zero-fill stays, so a caller that does send the buffer still doesn't leak anything. This was found by the Sashiko AI review of that commit, and Mina suggested reporting the error from the helper rather than checking for unreadable frags in skb_segment(). Link: https://lore.kernel.org/all/179148235783.434549.14322374227477832817@kernel.org/ Suggested-by: Mina Almasry Reviewed-by: Mina Almasry Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/ethernet/sun/sunvnet_common.c | 10 +++-- include/linux/skbuff.h | 4 +- net/core/skbuff.c | 63 +++++++++++++++++++++---------- net/ipv4/icmp.c | 9 +++-- net/ipv4/ip_output.c | 11 ++++-- net/ipv6/icmp.c | 7 +++- net/ipv6/ip6_output.c | 11 ++++-- net/sunrpc/socklib.c | 9 ++--- 8 files changed, 83 insertions(+), 41 deletions(-) diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c index 5cca95869052..4f229fcecc32 100644 --- a/drivers/net/ethernet/sun/sunvnet_common.c +++ b/drivers/net/ethernet/sun/sunvnet_common.c @@ -1167,9 +1167,13 @@ static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, int ncookies) /* copy the rest, with csum calculation */ *(__sum16 *)(skb->data + offset) = 0; - csum = skb_copy_and_csum_bits(skb, start, - nskb->data + start, - skb->len - start); + if (skb_copy_and_csum_bits(skb, start, + nskb->data + start, + skb->len - start, &csum)) { + dev_kfree_skb(nskb); + dev_kfree_skb(skb); + return NULL; + } /* add in the header checksums */ if (skb->protocol == htons(ETH_P_IP)) { diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index af1cbc2799b7..09db32f70b53 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -4277,8 +4277,8 @@ void skb_free_datagram(struct sock *sk, struct sk_buff *skb); int skb_kill_datagram(struct sock *sk, struct sk_buff *skb, unsigned int flags); int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len); int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len); -__wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, - int len); +int __must_check skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, + u8 *to, int len, __wsum *csum); int skb_splice_bits(struct sk_buff *skb, struct sock *sk, unsigned int offset, struct pipe_inode_info *pipe, unsigned int len, unsigned int flags); diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 93c2f440b9ec..a2b52a5a61a9 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3630,14 +3630,27 @@ EXPORT_SYMBOL(skb_checksum); /* Both of above in one bottle. */ -__wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, - u8 *to, int len) +/** + * skb_copy_and_csum_bits - copy data out of an skb and checksum it + * @skb: source buffer + * @offset: offset in @skb to start copying from + * @to: destination buffer + * @len: number of bytes to copy + * @csump: where to store the checksum of the copied bytes + * + * Return: 0 on success, or -EFAULT if @skb has unreadable frags or runs + * out before @len does. On failure *@csump is not set and the part of + * @to that couldn't be filled is zeroed. + */ +int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, + u8 *to, int len, __wsum *csump) { int start = skb_headlen(skb); int i, copy = start - offset; struct sk_buff *frag_iter; int pos = 0; __wsum csum = 0; + int err; /* Copy header. */ if (copy > 0) { @@ -3646,7 +3659,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, csum = csum_partial_copy_nocheck(skb->data + offset, to, copy); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; to += copy; pos = copy; @@ -3656,7 +3669,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, /* Don't hand the caller a buffer with stale bytes in it. */ if (len > 0) memset(to, 0, len); - return 0; + return -EFAULT; } for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { @@ -3688,7 +3701,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, } if (!(len -= copy)) - return csum; + goto out; offset += copy; to += copy; } @@ -3705,12 +3718,16 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, if ((copy = end - offset) > 0) { if (copy > len) copy = len; - csum2 = skb_copy_and_csum_bits(frag_iter, - offset - start, - to, copy); + err = skb_copy_and_csum_bits(frag_iter, offset - start, + to, copy, &csum2); + if (err) { + /* The child zeroed its part; zero the rest. */ + memset(to + copy, 0, len - copy); + return err; + } csum = csum_block_add(csum, csum2, pos); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; to += copy; pos += copy; @@ -3722,9 +3739,11 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, /* Don't hand the caller a buffer with stale bytes in it. */ if (len > 0) memset(to, 0, len); - return 0; + return -EFAULT; } - return csum; +out: + *csump = csum; + return 0; } EXPORT_SYMBOL(skb_copy_and_csum_bits); @@ -4006,9 +4025,13 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to) skb_copy_from_linear_data(skb, to, csstart); csum = 0; - if (csstart != skb->len) - csum = skb_copy_and_csum_bits(skb, csstart, to + csstart, - skb->len - csstart); + /* On failure the rest of @to is zeroed; leave the checksum alone so + * the frame goes out with a bad one. + */ + if (csstart != skb->len && + skb_copy_and_csum_bits(skb, csstart, to + csstart, + skb->len - csstart, &csum)) + return; if (skb->ip_summed == CHECKSUM_PARTIAL) { long csstuff = csstart + skb->csum_offset; @@ -5057,11 +5080,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, if (!csum) { if (!nskb->remcsum_offload) nskb->ip_summed = CHECKSUM_NONE; - SKB_GSO_CB(nskb)->csum = - skb_copy_and_csum_bits(head_skb, offset, - skb_put(nskb, - len), - len); + if (skb_copy_and_csum_bits(head_skb, offset, + skb_put(nskb, len), + len, + &SKB_GSO_CB(nskb)->csum)) { + err = -EFAULT; + goto err; + } SKB_GSO_CB(nskb)->csum_start = skb_headroom(nskb) + doffset; } else { diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c index 90c0e22c29be..35008785e3d2 100644 --- a/net/ipv4/icmp.c +++ b/net/ipv4/icmp.c @@ -364,12 +364,15 @@ static int icmp_glue_bits(void *from, char *to, int offset, int len, int odd, DEFINE_RAW_FLEX(struct icmp_bxm, icmp_param, replyopts.opt.__data, IP_OPTIONS_DATA_FIXED_SIZE); __wsum csum; + int err; icmp_param = from; - csum = skb_copy_and_csum_bits(icmp_param->skb, - icmp_param->offset + offset, - to, len); + err = skb_copy_and_csum_bits(icmp_param->skb, + icmp_param->offset + offset, + to, len, &csum); + if (err) + return err; skb->csum = csum_block_add(skb->csum, csum, odd); if (icmp_param->data.icmph.type <= NR_ICMP_TYPES && diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 3396f177a18d..f7da4538d05b 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -1162,9 +1162,14 @@ static int __ip_append_data(struct sock *sk, data += fragheaderlen + exthdrlen; if (fraggap) { - skb->csum = skb_copy_and_csum_bits( - skb_prev, maxfraglen, - data + transhdrlen, fraggap); + if (skb_copy_and_csum_bits(skb_prev, maxfraglen, + data + transhdrlen, + fraggap, + &skb->csum)) { + err = -EFAULT; + kfree_skb(skb); + goto error; + } skb_prev->csum = csum_sub(skb_prev->csum, skb->csum); data += fraggap; diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c index a95b0351824f..31ca3da80b1f 100644 --- a/net/ipv6/icmp.c +++ b/net/ipv6/icmp.c @@ -322,9 +322,12 @@ static int icmpv6_getfrag(void *from, char *to, int offset, int len, int odd, st struct icmpv6_msg *msg = (struct icmpv6_msg *) from; struct sk_buff *org_skb = msg->skb; __wsum csum; + int err; - csum = skb_copy_and_csum_bits(org_skb, msg->offset + offset, - to, len); + err = skb_copy_and_csum_bits(org_skb, msg->offset + offset, + to, len, &csum); + if (err) + return err; skb->csum = csum_block_add(skb->csum, csum, odd); if (!(msg->type & ICMPV6_INFOMSG_MASK)) nf_ct_attach(skb, org_skb); diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 25fe0ba98b1a..d259e7dca8ba 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1724,9 +1724,14 @@ static int __ip6_append_data(struct sock *sk, skb->transport_header = (skb->network_header + fragheaderlen); if (fraggap) { - skb->csum = skb_copy_and_csum_bits( - skb_prev, maxfraglen, - data + transhdrlen, fraggap); + if (skb_copy_and_csum_bits(skb_prev, maxfraglen, + data + transhdrlen, + fraggap, + &skb->csum)) { + err = -EFAULT; + kfree_skb(skb); + goto error; + } skb_prev->csum = csum_sub(skb_prev->csum, skb->csum); data += fraggap; diff --git a/net/sunrpc/socklib.c b/net/sunrpc/socklib.c index d8d8842c7de5..5d780ad4ae3a 100644 --- a/net/sunrpc/socklib.c +++ b/net/sunrpc/socklib.c @@ -49,7 +49,9 @@ xdr_skb_read_bits(struct xdr_skb_reader *desc, void *to, size_t len) if (desc->need_checksum) { __wsum csum; - csum = skb_copy_and_csum_bits(desc->skb, desc->offset, to, len); + if (unlikely(skb_copy_and_csum_bits(desc->skb, desc->offset, + to, len, &csum))) + return 0; desc->csum = csum_block_add(desc->csum, csum, desc->offset); } else { if (unlikely(skb_copy_bits(desc->skb, desc->offset, to, len))) @@ -142,11 +144,6 @@ int csum_partial_copy_to_xdr(struct xdr_buf *xdr, struct sk_buff *skb) desc.csum = csum_partial(skb->data, desc.offset, skb->csum); if (xdr_partial_copy_from_skb(xdr, &desc) < 0) return -1; - if (desc.offset != skb->len) { - __wsum csum2; - csum2 = skb_checksum(skb, desc.offset, skb->len - desc.offset, 0); - desc.csum = csum_block_add(desc.csum, csum2, desc.offset); - } if (desc.count) return -1; if (csum_fold(desc.csum)) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457174.1670047 (Exim 4.92) (envelope-from ) id 1xJWes-0002hu-6L; Wed, 21 Oct 2026 13:47:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457174.1670047; Wed, 21 Oct 2026 13:47: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 1xJWes-0002hn-2O; Wed, 21 Oct 2026 13:47:10 +0000 Received: by outflank-mailman (input) for mailman id 1457174; Wed, 21 Oct 2026 13:47:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWer-0002hh-20 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWeq-0065HB-Em for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:08 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c25a-2eae-0a2a0a5409dd-0a2a4504a012-12 for ; Wed, 21 Oct 2026 15:47:08 +0200 Received: from [209.85.219.48] (helo=mail-qv1-f48.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c25a-b57f-0a2a45040019-d155db30cc58-3 for ; Wed, 21 Oct 2026 15:47:07 +0200 Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-917a04338c1so7513186d6.0 for ; Wed, 21 Oct 2026 06:47:07 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.248]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91c10b71043sm25068716d6.9.2026.10.21.06.47.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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: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=1792590426; x=1793195226; 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=NSUQxko8Tfcm6XPL29du3h24csJ7ZCIrANnIj8sRtpc=; b=qGU9reyoNuwEV+jT+EE0WRYnHrs/vuun/NL9enKxKsjvgrS8eZq+kcoXtx/P4wuPqC 3O7YBneJUTDgJOlrYWHIiZHvAM7Q1X5weyLUn+HChZkBLA5BpZAJ+CY9dCCfNe8WRL9I MN5YQcieI9t7EtvIbQXwA9KgaemM7+WVn2/E4rbOQO17r0anqO7Y+CRy7EWVzQ6UUBeh 6R/YMVtwm1iW/4vghPfSxVZVD6Mz0Kxh4mBhnIKlewNuFXl+P4+TDtVPC/l367sdk8jF Cjf+Fotugpor47TymtfRa4V5MCwkP9PoBw/qXNE90ywOA2uVylZUk+jt2vhZEad+nW9Z b9kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590426; x=1793195226; 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=NSUQxko8Tfcm6XPL29du3h24csJ7ZCIrANnIj8sRtpc=; b=eXVADDfLeSzqNKiiv2MZ3JxBh7Nn4iSg5sU/PyusHTUQiPAVFQJApHJDlF7GmpgcpU ux1Mu+HcheqCD59tof4gwmtWPjfDNw6KR27a1zMpK4bQ0hEXfeOiXjknZ6tPiUduQIiT Q4ysxD4xsJDhADCCyI84NdUJF3/lD8vcKUHbPrQv1ZcDTm6slHZiJnoJzo7hxXP43U2J K52WEYv8mxThgnuR7XgxXioUcezmgqkwybUf4YXpKJgdeVQw5IevQHXjS0e4rAqo5gtW BUHTm7zZKWVH0nQv30RbAC6gzb9wHkxXVR4zwkcCeerTi6pPndR7SD/ps1OafC0njN7L G77Q== X-Forwarded-Encrypted: i=1; AKwUvBy2KTnokSptizcgkMHFLmrM9CTs+KjzYCo1wXRYXZoq1IscI/hxfl+BsdzqxWpeBaXugkXhO9d4eFU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKMyoMyX6523q+HkBA6yfEs6xAIDRh2vZ/Bcu3J4emIbi3FfIeO drEztPJTWCL2WwqNjrXNL5DDhsHL4TT4IEvtIQXCeW41++KowVcD4gqmEFysSJt0MCE= X-Gm-Gg: AYBFou13T/V1ClVHQn59NeifrJ0LUavbp2qmKri4OwhynXchIkHkFza9E1dMzCsWsFx vrI/JLJOK3c6GySqITxkusTMQJQRpdSv5Ov+0r/Zt+nSMyFjZ+uW/reS/bsZj9m6GtospECK2P1 MNcv/ar0TRW65ZxGbs+Na723dY4MPS12OBIzrzOuEyafBQeQfXoHT97qZnJJFm+DFMZpVNLuemV Ulgg2vIh/S2RYMubYk/37aYWb+/gee1AOIMr8aSG+yCL83X1GtXljT2rimTJZ4Y9h+O4PYSlCRI A5kqLz06mzHqrvCa1PbSsKBTVz9Ql1h7NCOzSlmhvt1qchj8Z99z6/SYmTRQkq0mT8KbNRFRFsJ /SlH+MzsX2wyitWNblgbgXnQmQkuPBq1oTeKm4uI/qktDZYHxsx7XENKbrP/oCY1tOIcXEH0bjl AaC0Ul6ucGKmPwvyi+6R8NfZgn3WDdobU9lxODms4BHh8MKET/qtH/XLysETKyNUR1r5X0Y8jIM wBNNQUqGpgH1QXPK6t+UpBhQVZGf/W486zkVbFYtInUqHT4+HHY8xjdux2yDP7nBEXV2QwPn4o7 EMqwTnsaUIt8u7iktg== X-Received: by 2002:a05:6214:5684:b0:91b:925f:d0dd with SMTP id 6a1803df08f44-91c12ed41a6mr37332546d6.24.1792590426192; Wed, 21 Oct 2026 06:47:06 -0700 (PDT) From: Josef Bacik Subject: [PATCH net-next v2 00/15] net: skbuff: follow-ups to the BUG_ON() removal Date: Wed, 21 Oct 2026 13:46:44 +0000 Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAEbC2GoC/32OzQ6CMBCEX8Xs2VVK8PfkexgO3XYrVWxJWxBje HcBvepxZmdnvhdEDpYjHBcvCNzZaL0bRb5cgKqkuzBaPWrIs3wrMrFFKjDeqDUGqb2gd2h8Xft H20SUWgipTb7fyALGgiawsf1cfgbHCR33CcrPJbZ0ZZWm7ilLMjJSkE5Vk1U3ayrWs/ljbXqqb Ew+PGf4TswzX87DP85OYIaF0MRmk9HB7E7J91Y10mm5Uv4O5TAMb/GmpXoaAQAA X-Change-ID: 20261016-b4-skbuff-bug-on-followups-ad11adf285a4 To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik , Willem de Bruijn X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590422; l=4828; i=josef@toxicpanda.com; h=from:subject:message-id; bh=MkdG+2v6TUl21fjtjrRq3//sPUH2f8XRlORQeByLWDY=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QO2vlJS71pMOkXvl8dcJMiw3/K0ESBPLJ0YBRx9eL5GrB+5fwCnrWBfCg1SGoHqd9H8+QO+i+vN 43y042wwUbw4= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1792590428-C30CDB50-AD143268/0/0 X-purgate-type: clean X-purgate-size: 4830 v1: https://lore.kernel.org/all/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com/ v1->v2: - skb_segment(): check each frag_list member as the walk takes it, instead of an extra pass over the frag_list up front (Willem). - KUnit test: braces around the suppressed skb_segment() call (Willem), and the comment update for the non-uniform case moved into the same patch (Mina). - Picked up Willem's Reviewed-by and Mina's Acked-bys. --- Original email (v1) --- Hello, Jakub applied v2 of my skbuff BUG_ON() series[1] before I got v3 out, so this is what v3 would have changed, as fixes on top of what landed, plus the skb_copy_and_csum_bits() patch I'd been sending to net on its own. Patch 1 is that patch[2], moved to net-next as Mina suggested, with his Reviewed-by. It makes skb_copy_and_csum_bits() report failure, and the rest of the series builds on it. Please drop the net version. Patches 2 through 6 deal with skb_checksum() and skb_crc32c(). My v2 had them return 0 when they run out of skb, and that turned out not to be safe: 0 is a valid checksum, and it can make a packet that was never fully checksummed pass verification. So they get versions that report failure, skb_checksum_full() and skb_crc32c_full(), and the core users switch to them: checksum validation now rejects a packet it can't checksum, skb_segment() and pskb_trim_rcsum() fail instead of using a bad sum, and skb_crc32c_csum_help() drops the packet. skb_checksum() and skb_crc32c() stay as wrappers that behave as before, and I'll convert the rest of their callers per subsystem in later series. Patches 7 through 10 fix problems Sashiko and an LLM review found in what was applied. skb_zerocopy() refuses a zero-length copy that Open vSwitch can trigger from a user namespace, skb_try_coalesce() and skb_copy_and_csum_bits() can be handed a negative length, and skb_headlen() can underflow in skb_copy_and_csum_dev(). Patches 11 and 12 make skb_segment() refuse a nested frag_list, which could still oops on a NULL list_skb, and add KUnit cases for the layouts it refuses. Patches 13 and 14 get rid of the same BUG_ON()s in xen-netfront's bounce_skb() and tls's __skb_nsg(), and patch 15 updates comments that still describe the old BUG_ON()s. I tested this with the net_core KUnit tests, a test module that drives each of these paths under KASAN and fault injection, an Open vSwitch reproducer for patch 7, and a stress run over veth with netem. Thanks, Josef [1] https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ [2] https://lore.kernel.org/all/20261013-b4-skb-segment-nosg-unreadable-v2-1-6c28d8ffa51e@toxicpanda.com/ --- Changes in v2: - Link to v1: https://patch.msgid.link/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com --- Josef Bacik (15): net: skbuff: make skb_copy_and_csum_bits() report unreadable frags net: skbuff: add skb_checksum_full() that reports failure net: skbuff: fail checksum validation when the skb can't be checksummed net: skbuff: fail segmentation when a segment can't be checksummed net: skbuff: fail pskb_trim_rcsum() when it can't checksum the tail net: skbuff: add skb_crc32c_full() that reports failure net: skbuff: let skb_zerocopy() copy a short skb without head_frag net: skbuff: make skb_try_coalesce()'s len unsigned net: skbuff: check csum_start against len in skb_copy_and_csum_dev() net: skbuff: reject a negative length in skb_copy_and_csum_bits() net: skbuff: refuse to segment a nested frag_list net: test the frag_list layouts skb_segment() refuses xen-netfront: don't BUG() when skb_copy_bits() fails in bounce_skb() net/tls: don't BUG() on leftover length in __skb_nsg() net: update comments that still describe the skb BUG_ON()s drivers/net/ethernet/sun/sunvnet_common.c | 10 +- drivers/net/xen-netfront.c | 7 +- include/linux/skbuff.h | 8 +- net/core/dev.c | 7 +- net/core/filter.c | 6 +- net/core/net_test.c | 53 +++++- net/core/skbuff.c | 275 +++++++++++++++++++++++------- net/ipv4/icmp.c | 9 +- net/ipv4/ip_output.c | 11 +- net/ipv6/icmp.c | 7 +- net/ipv6/ip6_output.c | 11 +- net/sunrpc/socklib.c | 9 +- net/tls/tls_sw.c | 5 +- 13 files changed, 327 insertions(+), 91 deletions(-) --- base-commit: 6b3e73774815910a39d8ca75b9ad7df963f61d50 change-id: 20261016-b4-skbuff-bug-on-followups-ad11adf285a4 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457176.1670064 (Exim 4.92) (envelope-from ) id 1xJWew-00037x-Lj; Wed, 21 Oct 2026 13:47:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457176.1670064; Wed, 21 Oct 2026 13: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 1xJWew-00037q-IT; Wed, 21 Oct 2026 13:47:14 +0000 Received: by outflank-mailman (input) for mailman id 1457176; Wed, 21 Oct 2026 13:47:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWeu-00031A-UO for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWeu-00AIAc-B4 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:12 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c259-8faa-0a2a0a5109dd-0a2a450cc678-20 for ; Wed, 21 Oct 2026 15:47:12 +0200 Received: from [209.85.219.44] (helo=mail-qv1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c25f-f479-0a2a450c0019-d155db2cc99f-3 for ; Wed, 21 Oct 2026 15:47:12 +0200 Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-91b8306b9f8so11941166d6.3 for ; Wed, 21 Oct 2026 06:47:11 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.241]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91c10c42b17sm25128096d6.40.2026.10.21.06.47.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=1792590431; x=1793195231; 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=j9xcHh2wY++h6+R9ioq32anwJ7T1kqXqVTQttxnVock=; b=pkEzOhXoywAEw9G3IJE2XrG9nlSG7LqRrXWGWHK5NZ7DmU648tJ7oWNLWB1NgNd93W PduirwpDmtViAJS5S1GDcmD8i0WKXO333Gq2TnVLJQvpc6b2o1I70tblTQn+xavXHAXA xihexU3NPp4qtunuKCjZ4xJ2KbISHPOZEl5vPycT1FF23BSSvNXPampymirOiYJWAGll g8FR7z+e1GOX4RB/5eZwkuCGzK/kpje9Co2pd4tC/zh8eRN+8LuiE8BZs9zN14RKCIbM i0bufPNDjnNP+9hFa1MSc14gW9ytycXY1I7rBE/n7BSN4C1aH+CJvMEaiL2SqWR75ReX eThA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590431; x=1793195231; 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=j9xcHh2wY++h6+R9ioq32anwJ7T1kqXqVTQttxnVock=; b=lMAUdh+Vgto/lN2Zx+X2FJJMdZMfE/j/i8YAVD7XwjiYCxQr3OG7T+eSWFCQ2DMMDq W1mdEH2s7Fpye+wdDx4bx9YYvFVOzTmDzP5QO2W2+P8gHa784o+87rVLp07HvRL/Z7ef aFLT6xgv2N9ah6Q4deuExRFzKpEKpczRy1gPlNVE9KBI4OoiPk7nc7crGv0snZSIRT2m SotulOQKz29V78Q45peNXDyqWmFM0fAi6O3t3SFmtjiMUOsWNJ4SSeQXUCXr1tSHO8mN W6RmZQoCrEry4tDh827STg15rXIfcQyT3lK/UhMNqv/li9KKcPVEjj9+vR5EFxwbLCMu /PXA== X-Forwarded-Encrypted: i=1; AKwUvBy6npQKD3mq//zBUQbIjM/ur8npXnpEvMEPCzhgqDbWyt7XRQ0l1d2i4Oo9SyjDQE/Tcm7MMPWKTgA=@lists.xenproject.org X-Gm-Message-State: AFq9FYLxj6pmu5wFziRuIApJ74Zp/NIvFYNdU9aZM7dt8DX3AJgCNoTD 8WDLxhQij2F2WYffZKNOVS0uQFLchbusea7Ds4ndFBmZfbuaxl6G7NLi+kC5u53G8oQ= X-Gm-Gg: AYBFou2Ddhn5VaPP7LlONronzXT+S7GzV0QBwIOnqdKI7f9Qb7ZKjNq6jGPXPWhF+/d ecXhBr6wJUxNOHwoDeoZB5q/7PR1JcGFbQ9x99Q9B1wAiG8/bkY2DP+u8fwH35xMbFH892LVXl/ eEXJleK7Fo3sAoeqakyhTWOdcX+fYfDrW7Q9s6uNynyPc3WjQiJgBTqyJkohQ7g6luzeO9DhAZ6 gyFHCW2oQhrUIms8C7lKGEAQUSY+8TtEC+VlSiQspSSyF41iU6GCkY8kxo+OEC+WlncgtPBKxs/ HHZRtctsqZZKeHoHmgGK0DlR9nBH1cNQeP+ipdR4hEYbT0AI1jW+U6ZxBqwg3j7bJJ0Ljprh5mB HWq42IvyI6yPzDYDW9nW1x6Ae+Xz1I92eHanPSjIy3aBDVYNPjERnbmITEJDUeQECKVfAv5DrEQ fx2BQ5us9nBKWNmz2JDnVzMDeU/0r5rI86yDlNt7/vfuZQwXCd+zXA2pMa07VXF52WbLuqHGXvM uV+VGPZnnHsrfATR0ZqzkCAjQBBtepz0oCZAAKw4gTVVXsmc5rgRvEGeeDiAZoB6Vezy1CZRA== X-Received: by 2002:a05:620a:468c:b0:93e:ce12:aadd with SMTP id af79cd13be357-93f57f47979mr408941985a.58.1792590430520; Wed, 21 Oct 2026 06:47:10 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:46 +0000 Subject: [PATCH net-next v2 02/15] net: skbuff: add skb_checksum_full() that reports failure MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-2-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590422; l=5325; i=josef@toxicpanda.com; h=from:subject:message-id; bh=ZlvWwY4Y8lGqu2UhxWxy8P8g8HVcQXW7x438vujwS94=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QB9IaUyRRnrhDlcjRASKEoLr8PFoRFRxjWkPSpu94bv/cMt6C3uKGuj4pHXocRUTVQp2sAYCM4v P9XCyt8XsuQ0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d25034/1792590432-766DEA5B-85DC29EB/0/0 X-purgate-type: clean X-purgate-size: 5327 skb_checksum() can't fail. When the range runs into unreadable frags or past the end of the skb it returns 0, which is also a valid checksum, so its callers can't tell the sum from a failure. For the receive-side validation helpers that means a packet whose payload was never checksummed can pass, and commit 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") made the past-the-end case one of those instead of a BUG(). Add skb_checksum_full(), which adds the range's sum to *@csump and returns 0, or returns -EFAULT for unreadable frags or a range past the end of the skb, and -EINVAL for a negative length, leaving *@csump alone. It's __must_check so a caller can't ignore the failure, and it recurses into frag_list members through itself so a failure there isn't lost either. skb_checksum() becomes a wrapper around it that behaves as before for the callers that haven't been converted: it returns 0 on failure and warns once if that was because of unreadable frags. The following patches convert the core users, and the rest will follow per subsystem. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/skbuff.h | 2 ++ net/core/skbuff.c | 56 +++++++++++++++++++++++++++++++++++++++++--------- 2 files changed, 48 insertions(+), 10 deletions(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 09db32f70b53..969b1c3269ec 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -4279,6 +4279,8 @@ int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len); int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len); int __must_check skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, int len, __wsum *csum); +int __must_check skb_checksum_full(const struct sk_buff *skb, int offset, + int len, __wsum *csump); int skb_splice_bits(struct sk_buff *skb, struct sock *sk, unsigned int offset, struct pipe_inode_info *pipe, unsigned int len, unsigned int flags); diff --git a/net/core/skbuff.c b/net/core/skbuff.c index a2b52a5a61a9..061c61422a38 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3545,12 +3545,31 @@ int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len) EXPORT_SYMBOL(skb_store_bits); /* Checksum skb data. */ -__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) +/** + * skb_checksum_full - checksum a range of an skb + * @skb: buffer to checksum + * @offset: offset in @skb to start at + * @len: number of bytes to checksum + * @csump: the sum to add to; on success the range's sum is added to it + * + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb + * has unreadable frags in the range or runs out before @len does. On + * failure *@csump is not changed. + */ +int skb_checksum_full(const struct sk_buff *skb, int offset, int len, + __wsum *csump) { int start = skb_headlen(skb); int i, copy = start - offset; struct sk_buff *frag_iter; + __wsum csum = *csump; int pos = 0; + int err; + + if (unlikely(len < 0)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } /* Checksum header. */ if (copy > 0) { @@ -3558,13 +3577,13 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) copy = len; csum = csum_partial(skb->data + offset, copy, csum); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; pos = copy; } - if (WARN_ON_ONCE(!skb_frags_readable(skb))) - return 0; + if (!skb_frags_readable(skb)) + return -EFAULT; for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { int end; @@ -3593,7 +3612,7 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) } if (!(len -= copy)) - return csum; + goto out; offset += copy; } start = end; @@ -3606,14 +3625,17 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) end = start + frag_iter->len; if ((copy = end - offset) > 0) { - __wsum csum2; + __wsum csum2 = 0; + if (copy > len) copy = len; - csum2 = skb_checksum(frag_iter, offset - start, copy, - 0); + err = skb_checksum_full(frag_iter, offset - start, copy, + &csum2); + if (err) + return err; csum = csum_block_add(csum, csum2, pos); if ((len -= copy) == 0) - return csum; + goto out; offset += copy; pos += copy; } @@ -3621,9 +3643,23 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) } if (unlikely(len)) { DEBUG_NET_WARN_ON_ONCE(1); - return 0; + return -EFAULT; } +out: + *csump = csum; + return 0; +} +EXPORT_SYMBOL(skb_checksum_full); +/* skb_checksum() has no way to report failure, so it returns 0, which is a + * valid checksum. Use skb_checksum_full() in new code. + */ +__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) +{ + if (unlikely(skb_checksum_full(skb, offset, len, &csum))) { + WARN_ON_ONCE(!skb_frags_readable(skb)); + return 0; + } return csum; } EXPORT_SYMBOL(skb_checksum); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457177.1670073 (Exim 4.92) (envelope-from ) id 1xJWex-0003LS-Rh; Wed, 21 Oct 2026 13:47:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457177.1670073; Wed, 21 Oct 2026 13:47: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 1xJWex-0003LL-Oa; Wed, 21 Oct 2026 13:47:15 +0000 Received: by outflank-mailman (input) for mailman id 1457177; Wed, 21 Oct 2026 13:47:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWew-00037Y-G0 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWev-00AIAc-Sb for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:13 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c261-8faa-0a2a0a5109dd-0a2a45099ac4-2 for ; Wed, 21 Oct 2026 15:47:13 +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 6ad8c260-be1a-0a2a45090019-d155deb2dc74-3 for ; Wed, 21 Oct 2026 15:47:13 +0200 Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-93f2493c28bso55442785a.0 for ; Wed, 21 Oct 2026 06:47:13 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93f56e221fcsm254323085a.40.2026.10.21.06.47.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06: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=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=1792590432; x=1793195232; 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=DPzcetTQubRCe4lOTpMna5FIDyGXRIDSoyAwtL9E3zo=; b=OOfaMOnqIk0W9HvPbm8JiXx8T7Fi0cfyG1qhMk04GyXhTqfumHyRuLWA1Y+D5R3H06 7hg4L4MqqJDJbiF7trJGRuGT884XVWpvhcl7RUpWp7MHA8P91RQWmecXaqVGEnZ7Q0lJ FqoNYpvfyxSCVOEHCJ154U+zpWFp/YR+Fc9GMOhe+zZtbDpRye3YvG352SFE+Lsly+l/ NalLkNnuJHg0b2z2CZtyThGjlb5jSpde969oCnc+xkPvH1aBGmDb0KjQrktBsZmnkUf5 0emGdmNpoQ1zW0YS1tRfSzbO/KWEJKacjQQP0erIE9A8EwSi8+yyUBVGUcTvttMQfGMk LbBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590432; x=1793195232; 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=DPzcetTQubRCe4lOTpMna5FIDyGXRIDSoyAwtL9E3zo=; b=ZqXihm+TKPiHfcHBtSHsqz/5mhQOpIEtbJ9znSPuH+cNaPlv3E4LwBnG6vnGwqViez iAOfs9f/siqM3Ho7O2OQq15xwXFemInIHqE8vcOrkQK1CJmcc2YxFfxdnXtaGnlBvyFB cTqM81jdFai4M9GaRipATNqp/FH8tFO4WY78KdyxUBV7L+oiZlbb/H3jGzIe0CKhAbLt fPoa5f7RWAiAQzeweVuZah5d5IB//mt7KFI06fbva9f6VCO1fU2JILeTMBBoI0iSOkHr HkcB+uXAo1prH9+40dSj2Krof+cibEH09dI98iOfrRhQEi0CeH3Kb4AuYjXRuTdLzIfi i3RA== X-Forwarded-Encrypted: i=1; AKwUvBz7pekaNDiJqJFzfsaKwixz6cR6Vx5mSoTcEujfhzHxNmj1sBzaEYW6Rh9zNbTFUZTegxEzLo0RMhs=@lists.xenproject.org X-Gm-Message-State: AFq9FYKwhshbvunUMLKhtedwyasCmyfjyMg9GquLKF1BC747Vux1aDUJ sns7kPg1CnA7IELbfI5qLRs0GDk4cZbRKBnI2XgpyeQt/n/BLsZ1JyLfYXE9sowekxg= X-Gm-Gg: AYBFou3eaqFtQXqCM+sYQ+6+z2RiDdN7unbQi1Ax6ymnumBkVP0iZK9rUXqBrRIse8N GjC1WptJH1zeEjg1m4NpkS55ub9g4PNAkKwB+9KAFS2E91qBsoxU/ELOyyIP2ya+oEpAm1c6klt JFCJcJx60cawGGpfecz5Yu0HQ6ept9cpyehJqC69XDx0E7xMIJDk/OYBqO5XnMsA5yYKVPQfhiU 12tYWAxsfR0S0fbMgn84DAHdAagc3xIC7JOMTWlk4/gTTykFf9s3wdz7Ika1ra0v0kD1TDXhhBl ChQqskD8CMN6XQcXl9d2RjGx6Y6EIPKMEP00wAiQH1rbVCIlxHf/B8W5xBbXaraca2/aBdBvBJM KyvGghcPCI3NPLIPG2id2ZX7vGfI5503ybWp9suCpl6n3KmOfMSDkPoNT7fODIfyg9gD1oW7RJB sSF5FDbhM7auyx9jLkk7OAnnuG+sppiSrsvKgx4M+2OHqT7i/iq669w21smdbncRUt+SKf/mBvB mlsuiagDNoNzFWYihU6kNerO6oQaeqkLzMddMMnvy0DxgP/mO3G3veb6IMp3KIK87tVNwOL X-Received: by 2002:a05:620a:f04:b0:93e:4fac:9d31 with SMTP id af79cd13be357-93f57f2012cmr439406185a.26.1792590432356; Wed, 21 Oct 2026 06:47:12 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:47 +0000 Subject: [PATCH net-next v2 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-3-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590422; l=2860; i=josef@toxicpanda.com; h=from:subject:message-id; bh=prj+BQU7C60dBsXDxJX9jL8mklYfFucWwKvpS5MOuJ4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QB6W8Sr4kysX4RYVPQ/s/LIgV/tAxufFvsN3bU4kpLKDEj3qrHCW/VhTdVB4zPVL/3cqJoYEUrD 0TwvTS8OOXQM= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1792590433-BF6D2034-A3F13248/0/0 X-purgate-type: clean X-purgate-size: 2862 __skb_checksum_complete() verifies a received packet with skb_checksum(), which returns 0 when the range runs into unreadable frags or past the end of the skb. 0 is a valid sum, so it's treated as one: it adds skb->csum, the pseudo-header sum, and folds the result. With a sum of 0 that's csum_fold(skb->csum), which is 0 whenever the pseudo-header sum folds to 0xffff, so a packet whose payload was never checksummed is accepted, marked csum_valid, and left with a wrong CHECKSUM_COMPLETE value in skb->csum. __skb_checksum_complete_head() passes skb->csum in as the seed, so a failure there folds 0 and the packet fails validation, but only because skb_checksum() happened to drop the seed. Use skb_checksum_full() in both, and report a packet that can't be checksummed as having a bad checksum, so callers drop it the way they drop any other bad checksum. Clear csum_valid, and leave skb->csum and ip_summed alone, since there's no full packet checksum to store. Found by the Sashiko AI review of the series that made skb_checksum() return 0 for a range past the end of the skb. Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 061c61422a38..40d2dd20d47d 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3860,9 +3860,17 @@ EXPORT_SYMBOL(skb_crc32c); __sum16 __skb_checksum_complete_head(struct sk_buff *skb, int len) { + __wsum csum = skb->csum; __sum16 sum; - sum = csum_fold(skb_checksum(skb, 0, len, skb->csum)); + /* If the data can't be checksummed it can't be valid either. */ + if (skb_checksum_full(skb, 0, len, &csum)) { + if (!skb_shared(skb)) + skb->csum_valid = 0; + return (__force __sum16)1; + } + + sum = csum_fold(csum); /* See comments in __skb_checksum_complete(). */ if (likely(!sum)) { if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE) && @@ -3886,10 +3894,17 @@ EXPORT_SYMBOL(__skb_checksum_complete_head); */ __sum16 __skb_checksum_complete(struct sk_buff *skb) { - __wsum csum; + __wsum csum = 0; __sum16 sum; - csum = skb_checksum(skb, 0, skb->len, 0); + /* If the data can't be checksummed it can't be valid either. Leave + * skb->csum alone, it's not a full packet checksum. + */ + if (skb_checksum_full(skb, 0, skb->len, &csum)) { + if (!skb_shared(skb)) + skb->csum_valid = 0; + return (__force __sum16)1; + } sum = csum_fold(csum_add(skb->csum, csum)); /* This check is inverted, because we already knew the hardware -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457178.1670082 (Exim 4.92) (envelope-from ) id 1xJWf1-0003bq-4q; Wed, 21 Oct 2026 13:47:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457178.1670082; Wed, 21 Oct 2026 13:47: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 1xJWf1-0003bf-0N; Wed, 21 Oct 2026 13:47:19 +0000 Received: by outflank-mailman (input) for mailman id 1457178; Wed, 21 Oct 2026 13:47:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWez-0003Xq-09 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWey-00AIG5-D9 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:16 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c261-8faa-0a2a0a5109dd-0a2a45099ac4-8 for ; Wed, 21 Oct 2026 15:47:16 +0200 Received: from [209.85.160.176] (helo=mail-qt1-f176.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c263-be1a-0a2a45090019-d155a0b0e526-3 for ; Wed, 21 Oct 2026 15:47:15 +0200 Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-536605c4d8fso4891991cf.1 for ; Wed, 21 Oct 2026 06:47:15 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.248]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91c10baeadcsm25487476d6.19.2026.10.21.06.47.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590434; x=1793195234; 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=2aRCuku2oKEDF0Op1/pBMZnZUn6snlu290Nklz94qvM=; b=SwLZpr5vVunA8nTkM8vi7dsk7YhQdaMlviWrKfGeEcJexI/vGEtLkKu5f9pgYoJSfz HiBo/8x+Gh7NPnfoaaAgGtvcmoCOJvp+AmheI56SD1JLI0vakV7ozXhkbp6xOSkr9jyi 05MvWh/eS69OYlBjcU1meUWX6leP1fH0V+q36awN4fYxBTU07NsCYHpQo318Ft+ltGX1 4sxyFIBKaMHNnrH6DuoN4XM2euzkPwuXQWMHVeiAAR0X2CT4T4W0Uiwq3un2309x+/PS SPX6jxZLIgre4E8cJWgVi/UPI5ZN0CRpFg8hyvD8yYtTbx4GaKJs7ESsz7KnV41tR/VK ELDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590434; x=1793195234; 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=2aRCuku2oKEDF0Op1/pBMZnZUn6snlu290Nklz94qvM=; b=mcz4rWzgRFVbnx+roo81V4+Qk3fB5KMHX9wG+dBTnFg/RrpLYrJlmX988aoEBZRsRj 8SC4gW2qtzE6bCPGZrSxplvSWKdhB2n1PrmXebXAJJQ45jdCgrRVAW0b/r7D0mmcSzaI vc7+4Fwz8fDNH1bePIjDHujrqhJjIVyoS3LYza4ZJD2+d1JLnfSEI7Q8BmbXnLjlgskO LMTlwMTy19ZrLdVqeFLYANojy7IozsEBkd+bcbIWButu8yO5wlf3Svv3pCLfYAlh4wvA hZxzAPm+7bLV1RFTV8uvTVW0yYbv/NKMiWXXZ+3HjBcTBVivQKTDnrCPpPrnHf6g+/Li if2A== X-Forwarded-Encrypted: i=1; AKwUvBzDJi8MxU5I4lAruD8H6gLYdoXOJiLV3otrP2ES97+omxfzzzvgNVPEIkbyQCmQo+iQwnxlJglSVno=@lists.xenproject.org X-Gm-Message-State: AFq9FYL8IqpFXFMpChwxrUYehG1updRkmTgiMP2JCz51p/h/6uRnxrw3 cPp5GCBpReJMASFCVI+MlVZYkYDth0H9Ci6dlTznEgfeYgwkZtiHZddWkLftaZj4F8Q= X-Gm-Gg: AYBFou2kZId1BxG9JSeskFJVtX3uOIm4WPPSsyrPbsb/ivUJBAcTmsGubZnJEesM5UX ssP7EGmI/xbcG2bZugthqgNyS9A7g5+bmcrR6ykHO8wYbHMwhrD/HapCW/XOEcGLJnyKMecvIOT JJHWda7GdJ05DA7ytbKAMGh/QnEVGjIDccAnzoYXjtXi4Bhiuo7F6Du+2gjXhQvwBcL2YqXz+YO JPiSJAGu1UB72JxC86HwmC9X2oNPpaRhGBNzZiu8xVxBvV3Jz1Qkxb3BO5GXV6aD08XfGYU9QLQ Yh0U0d2zYDceeqanx4qjvOtGwjf45nB3CUqhLsO4YN3m8SJVPQ2+AUKSomCAAzyhLpp8yWd0//B Mfr9BCMsmZ0og0Y6vvzbLM6wdG2VBo7ymyq2pD4TkOvzLieh58B686WtOvF3aAvcfJpAllJy2he KMUyUB/Drruc1/rzEAeMbQ9Wq4Ft0Pu8DblIAIS+qG7ZW8kWYb9nGKQAzMtNkf6eMO8u6w6dO7M qkN/UJDI8uNDQ4OKxFZ1S/NkjLUl5l9KTvltA4TKR63YlF6WR5WLgjfuEy9IGZz/6IJOPCv X-Received: by 2002:a05:622a:400c:b0:535:baa:a78d with SMTP id d75a77b69052e-5369b4f46c6mr30150331cf.10.1792590434551; Wed, 21 Oct 2026 06:47:14 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:48 +0000 Subject: [PATCH net-next v2 04/15] net: skbuff: fail segmentation when a segment can't be checksummed MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-4-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590422; l=1895; i=josef@toxicpanda.com; h=from:subject:message-id; bh=wii8wzXlG4ePvSd6K5rd8H498XoB8iUyEaQEAS7r5bk=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QFXNkJVl00uSWJUSJGE5ur3ZFVCzw0/41zwWUKiPaUfI51HMPUlDfMqmqTrCEh6QYjM2gM13Our wstomOnSWpgM= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1792590436-3AAD8034-F8A7646E/0/0 X-purgate-type: clean X-purgate-size: 1897 When the device can't checksum the protocol, skb_segment() computes each segment's checksum in software with skb_checksum(). With SG on, the segments share the original frags, and a devmem TCP skb keeps its whole payload in unreadable frags. The devmem MSG_ZEROCOPY path never sets SKBFL_SHARED_FRAG, so the __skb_linearize() fallback is skipped too. skb_checksum() then warns and returns 0, and tcp_gso_segment() writes a TCP checksum that doesn't cover the payload that goes out. That's reachable with tx-checksumming off and SG on: sk_setup_caps() still gives TCP SG and HW_CSUM, so the dmabuf send is accepted, and harmonize_features() strips the checksum features but keeps SG. Use skb_checksum_full() and fail the segmentation with -EFAULT when it can't checksum a segment, as skb_segment() already does when it can't copy one. Found by the Sashiko AI review of an earlier fix for the same path with SG off. Link: https://lore.kernel.org/all/20261009-b4-skb-segment-nosg-unreadable-v1-1-7e2334a55fe8@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 40d2dd20d47d..88ed2dd99dc0 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -5239,9 +5239,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, if (!nskb->remcsum_offload) nskb->ip_summed = CHECKSUM_NONE; - SKB_GSO_CB(nskb)->csum = - skb_checksum(nskb, doffset, - nskb->len - doffset, 0); + SKB_GSO_CB(nskb)->csum = 0; + if (skb_checksum_full(nskb, doffset, + nskb->len - doffset, + &SKB_GSO_CB(nskb)->csum)) { + err = -EFAULT; + goto err; + } SKB_GSO_CB(nskb)->csum_start = skb_headroom(nskb) + doffset; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457179.1670086 (Exim 4.92) (envelope-from ) id 1xJWf1-0003eT-Cg; Wed, 21 Oct 2026 13:47:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457179.1670086; Wed, 21 Oct 2026 13:47: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 1xJWf1-0003ck-7S; Wed, 21 Oct 2026 13:47:19 +0000 Received: by outflank-mailman (input) for mailman id 1457179; Wed, 21 Oct 2026 13:47:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWf0-0003ad-J3 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWez-00AIGi-Vy for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:18 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c261-e002-0a2a0a5209dd-0a2a4504eaf4-16 for ; Wed, 21 Oct 2026 15:47:17 +0200 Received: from [209.85.219.45] (helo=mail-qv1-f45.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c264-b57f-0a2a45040019-d155db2dcdc9-3 for ; Wed, 21 Oct 2026 15:47:17 +0200 Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-91c19fc50abso3885006d6.1 for ; Wed, 21 Oct 2026 06:47:17 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91c10b736adsm24541336d6.7.2026.10.21.06.47.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590436; x=1793195236; 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=t5hhezvrkrPsILbBbBLRGuH3wT+463IdJ8u+tbtUXF4=; b=iLDanUPTnWyCQhL5NCmjMaxftP1+znmIm44ZIgmo5+i8CqyBFX399Aegm2N82c1A+3 AAc5Iz79houwcd9KfEWobTrYPNJuqw39oLqjg+COjEhKNQgZ5O/gRHggtq7KXYmCthke CPoW00/JywtwZAbMgaP6zfVYsv/HWy8YfprlIzM0lslORlM9efY3mfE/dnZ4FaWsayIp YaRSPlDZxFKiDBsDrzStbVZsePHmR2tAIrvddfv5Lyv1prI2T62SQvVisJxjotDWv496 LRA4zsWhBzND0S2K8DhMEDwUK5p4fffk1mP4v3FjugDX/f0pnAkFn29h/QO3cTxaIG49 +LMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590436; x=1793195236; 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=t5hhezvrkrPsILbBbBLRGuH3wT+463IdJ8u+tbtUXF4=; b=iA++AGm0cFMohKsRMLS9eobKdRk0rnQ4vwzFkenfk9wPXFV0ewv+K9TNpqQqfHWh9b 1dqSVryOwCrhhxDUv6FPt6WigUexrSnFon4jUBGQfzLjjOswpLdYX+aoqjSgaa4J69KV e8sBxGv+/8eBVbrhOUSLlMjVrBZ4F4fF/LKajPgR24Mkj2dvSEtcMinFz5L7Ya+2/iuB wkBgMSwqqPhqFaVOLhxuuIBhWRccNcZ+c3PO/CliEWFO6adzyGdOSEYyY4trpQnnmIUn NF3GrP5JJqtY9GBDHxy9gt7aeygj7eIDatYVJ20buEL+KHP254Z6A+T6m+uxdUFpM8Zx zNtw== X-Forwarded-Encrypted: i=1; AKwUvBwf7/gW32qG0QBpImoYaxs/JrkXJSV4GVI+S7PMltsScm75P4O8Vocrc0hy383e/0MgvkMVzN2k6Io=@lists.xenproject.org X-Gm-Message-State: AFq9FYIRGjXbv7ndL3ticXxDBWYxozGetbgRL0gdbyr9+NR3DG5OvsVq SXaA6aQJDDN0SFzvqlh7UBiMdeW/M796Vw74AEIhk5k9IGhlSdZCRcYF6BuOv/k5K+M= X-Gm-Gg: AYBFou1+MEEMqDlaPUdOAfYP5iElD1BqJ5NNf6G7MRurLbS33GaVMaptUmFsekq+sra CQmkHP05H737xW/fftW3biwuRClStSAHOnbFSOymQFXVANx85zaw09x5THll47BKR9nE2xcPsWL prZakohSEEoEXNQRcZs7Rq522z5zlArMKVb+jmnYyVJQ8y4GOsoz03GyplA6l8ilqpRwUPlRGpq VT+OHezBg1uEzLnhOrlwMDhJDt3tw80ExefjBEiIMfVyvVzqvn3ytpM21xnQjTLrgZCARCM6pqh Tx9mX8X9wew+eOPqI2U8Rn473iq+89VDHBy9CB5Vs5MP6X6DayyLAkTfg9SIuAvXK9EUIpkj8NU C+AOoIiHoDtuvngo+JNQ4fDPuLXm3cp9GdXb9LGZ8OrqgQcDUAss6FXWUIQLPHM8yVAzICMGwzh pjbDNNcUbyQZQ+wDnFhzW0JxprdgCfAfaNqMHFglf9XVg6Wc7Vngd87p/GdWVPI4F6GE3mK3sAI erW328KyR1Gsow31oHCPKSoUg1KhAN0JHfylK5brOjRJK51iv8nPr4jFDDl4oshwdTvimST X-Received: by 2002:a05:6214:5910:b0:917:bebe:9be5 with SMTP id 6a1803df08f44-91c12eec79emr37007046d6.37.1792590436396; Wed, 21 Oct 2026 06:47:16 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:49 +0000 Subject: [PATCH net-next v2 05/15] net: skbuff: fail pskb_trim_rcsum() when it can't checksum the tail MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-5-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=1264; i=josef@toxicpanda.com; h=from:subject:message-id; bh=+TWKmcN/9YISrCDdUhnWQSTAcvPk81OG628CQR0a1S8=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QFTlNfGUcXXV3pjdWKViUvre5XIQ/uvNasCkIWODiOg4AiKOk9pUX7ncc6s9bQlJoyAZkqeFxAv XxSpKAAtILwU= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1792590437-C18D1B50-C5E67439/0/0 X-purgate-type: clean X-purgate-size: 1266 For a CHECKSUM_COMPLETE skb, pskb_trim_rcsum() subtracts the checksum of the bytes it trims from skb->csum. It gets that checksum from skb_checksum(), so if the trimmed range runs into unreadable frags in a frag_list member, or past the end of the skb, it subtracts 0 and leaves skb->csum covering bytes that are no longer in the packet. pskb_trim_rcsum() can already fail, and its callers drop the packet when it does. Use skb_checksum_full() and return its error. Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 88ed2dd99dc0..de433d452939 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -2829,9 +2829,13 @@ static int pskb_trim_rcsum_complete(struct sk_buff *skb, unsigned int len) int delta = skb->len - len; if (skb_frags_readable(skb)) { - skb->csum = csum_block_sub(skb->csum, - skb_checksum(skb, len, delta, 0), - len); + __wsum csum = 0; + int err; + + err = skb_checksum_full(skb, len, delta, &csum); + if (err) + return err; + skb->csum = csum_block_sub(skb->csum, csum, len); return 0; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457182.1670100 (Exim 4.92) (envelope-from ) id 1xJWf3-00045d-OR; Wed, 21 Oct 2026 13:47:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457182.1670100; Wed, 21 Oct 2026 13:47: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 1xJWf3-00045R-KQ; Wed, 21 Oct 2026 13:47:21 +0000 Received: by outflank-mailman (input) for mailman id 1457182; Wed, 21 Oct 2026 13:47:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWf2-000436-QB for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWf2-0082fY-6Y for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:20 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c265-bab6-0a2a0a5309dd-0a2a4501bb8a-8 for ; Wed, 21 Oct 2026 15:47:20 +0200 Received: from [209.85.219.50] (helo=mail-qv1-f50.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c267-5984-0a2a45010019-d155db32ac48-3 for ; Wed, 21 Oct 2026 15:47:20 +0200 Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-91b834592afso8922016d6.0 for ; Wed, 21 Oct 2026 06:47:19 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.249]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91c10b736adsm24541966d6.7.2026.10.21.06.47.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=1792590439; x=1793195239; 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=ydoWrUsryFQCXy0qk0+H+VOsHqxoYPyCdAWJE4iSCqQ=; b=NSXq2rx1o+rfp7k4E9hljUPF1uVXW3l+4EH5hntGX96e6bBdb9gmUBUvm1ayDGEuU2 3kEW1Dg0D9sZ6G5lq4+QSUiURMaYmP3JDqkvfpx6+yGgxhkXXxUvzCapUxCiEi4TPrFa MwB0EBQGByvSk6Cto7jHO1C3DMEopNf8+BDrzkFdggHg7HJByBtxhI+uUK3qrIgAuSC2 jlQN/354OHlXCRUkm49Vi9q9DoJngXRGCTAtiGuCgI/Tf7GDx0fK4Z8traOiOgB6YXtw Q3kfYN6FrkgpXBYbmaB9iV7XUc0jb5EbvsXpnD5qDcC5zO7hl3jYtWJhW5ZwRlx11gAd HCVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590439; x=1793195239; 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=ydoWrUsryFQCXy0qk0+H+VOsHqxoYPyCdAWJE4iSCqQ=; b=Bht3GeqvsfZ52rGlLQJGp8mBltH8zGYrlmsf+M1wNmQoxq4dftG3MXOqMBPxG1ICzl Z230zR2pFFr0YPxvzXt6Y2CPVMk2n79CTfxifquP39vBLlnnU65ov56eaDJAXsxcarx1 odnKRi88j+NvaF58EBtzx+VLTQVhsmEeFD2pzUCTHz4Ji5vERMfHX1zXwIlvywSBlbZi DSYpcF9NP7LbFd+g3GRwlA7RVcxO8kG9CchXLKEwGAIpWHkvfEQTsvsz8eQwfGoiQs0Z XKKje3hPfyrkWpHMXmFueqvw5sp13+b5oq70R5R32Qmz46Ygaex+XCIT1g6pBC4VOy1f 7NFg== X-Forwarded-Encrypted: i=1; AKwUvByy1WqzJhZZC+gz9FOWQ3h/s4qOwjIFtdolgzIKFQ/OjNLdQb/xJWS84DA3kGS7UDIPTnj3N/8utlc=@lists.xenproject.org X-Gm-Message-State: AFq9FYIpQTR9LJa8XmH65ATYxlbor5fNh+myaF0MDeANXpcqtVNS12tQ mYEnBSI/aCMhP1/mzLbiMW2r82ErMIR072dEMk5zsKmhAKsze//Y2rOjf4bHIbfFSlo= X-Gm-Gg: AYBFou0DmKPhkH0Y2F3yuio4y8NkWJSBBF8KA/rDXg896FULdCj2w5eY8PxLfI+HTZJ 9MkMje7zWOz7pVxVsRq/Drql9EFqx+zOpwZB+ubw/HMIQkUaoKEziHWjB54rHOIB3SK8KK+ZbUY BH80gTw1l14dFYK8SkUO40NIagbs/ikkaHU+UU8U36wJCwnk9Nlt2pRRBIW2ui5NZ4Gbelrh64h de+7ZgnXsfWYlHecOpfsBY1QJcG6zMy/UQZGZpaDriickv2JSpjP3xD0vkbURMbKX2AWWwCLVD9 tWDxLjmcjg0DN9vsRW0O0qlHkZns5V1kaIONgANkhacvLP7EPa6dsRKlPbE30WTokac7pWVLvHH 6jWHMu571uVYdyTBcY3q+oA0LyxqaPoEuJQwSuirZAxjL8CRRBRR9Vi3cfCtCWgX5QqwsJ4HVTu a/W0difOXCGLjhY3mZjbLiZauWpo08hvfoBMoXa/4l3u5dj4kZGAzpKizhO1qALaV2Bp0eT1+od o2WX1QpWk81/siOFwB5Dsmit5JsLa2KtUFcptS6nW0LclL5DN+XsDCqrwIHZE+2lrvCI7wA X-Received: by 2002:a05:6214:3c8e:b0:914:7df6:ca52 with SMTP id 6a1803df08f44-91c12edf334mr35650786d6.9.1792590438463; Wed, 21 Oct 2026 06:47:18 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:50 +0000 Subject: [PATCH net-next v2 06/15] net: skbuff: add skb_crc32c_full() that reports failure MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-6-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=5122; i=josef@toxicpanda.com; h=from:subject:message-id; bh=4gDL1d1n3xZ9vhvHuHh+fxzaWH1kti0hEf02jn3aBlw=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QGFH6qByESWgbyznzi7Yaz/CoAWhQfAOqIbi/BhB5oBR1rY2fhlWIxIK8c81xGv75bwiI8TG6yn I+0cEu9/8yQc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1792590440-1F66C757-1EF61EA9/0/0 X-purgate-type: clean X-purgate-size: 5124 skb_crc32c() has the same problem as skb_checksum(): when the range runs into unreadable frags or past the end of the skb it returns 0, which is also a valid CRC. sctp_compute_cksum() complements it, so a failed walk looks like a checksum of 0xffffffff whatever the packet contains, and the packet is accepted whenever its checksum field holds that. Add skb_crc32c_full(), which updates *@crcp and returns 0, or returns -EFAULT or -EINVAL and leaves *@crcp alone, like skb_checksum_full(). skb_crc32c() becomes a wrapper that behaves as before for the callers that haven't been converted. Convert skb_crc32c_csum_help(), which already returns an error when it can't fill in the CRC, so a transmitted SCTP packet that can't be checksummed is dropped instead of going out with a CRC of 0xffffffff. The SCTP and other callers will follow with the skb_checksum() callers. Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/skbuff.h | 2 ++ net/core/dev.c | 7 +++++-- net/core/skbuff.c | 51 ++++++++++++++++++++++++++++++++++++++++++-------- 3 files changed, 50 insertions(+), 10 deletions(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 969b1c3269ec..327a01a5d6d0 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -4329,6 +4329,8 @@ static inline int memcpy_to_msg(struct msghdr *msg, void *data, int len) __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum); +int __must_check skb_crc32c_full(const struct sk_buff *skb, int offset, + int len, u32 *crcp); u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc); static inline void * __must_check diff --git a/net/core/dev.c b/net/core/dev.c index 8eb9bf1ff9eb..1d34fa4544a2 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3738,8 +3738,11 @@ int skb_crc32c_csum_help(struct sk_buff *skb) if (ret) goto out; - crc = ~skb_crc32c(skb, start, skb->len - start, ~0); - *(__le32 *)(skb->data + offset) = cpu_to_le32(crc); + crc = ~0; + ret = skb_crc32c_full(skb, start, skb->len - start, &crc); + if (ret) + goto out; + *(__le32 *)(skb->data + offset) = cpu_to_le32(~crc); skb_reset_csum_not_inet(skb); out: return ret; diff --git a/net/core/skbuff.c b/net/core/skbuff.c index de433d452939..3b2a3747f009 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3788,23 +3788,41 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, EXPORT_SYMBOL(skb_copy_and_csum_bits); #ifdef CONFIG_NET_CRC32C -u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) +/** + * skb_crc32c_full - CRC32C a range of an skb + * @skb: buffer to read + * @offset: offset in @skb to start at + * @len: number of bytes to include + * @crcp: the CRC to continue from; on success, updated with the range + * + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb + * has unreadable frags in the range or runs out before @len does. On + * failure *@crcp is not changed. + */ +int skb_crc32c_full(const struct sk_buff *skb, int offset, int len, u32 *crcp) { int start = skb_headlen(skb); int i, copy = start - offset; struct sk_buff *frag_iter; + u32 crc = *crcp; + int err; + + if (unlikely(len < 0)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } if (copy > 0) { copy = min(copy, len); crc = crc32c(crc, skb->data + offset, copy); len -= copy; if (len == 0) - return crc; + goto out; offset += copy; } - if (WARN_ON_ONCE(!skb_frags_readable(skb))) - return 0; + if (!skb_frags_readable(skb)) + return -EFAULT; for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { int end; @@ -3829,7 +3847,7 @@ u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) } len -= copy; if (len == 0) - return crc; + goto out; offset += copy; } start = end; @@ -3844,19 +3862,36 @@ u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) copy = end - offset; if (copy > 0) { copy = min(copy, len); - crc = skb_crc32c(frag_iter, offset - start, copy, crc); + err = skb_crc32c_full(frag_iter, offset - start, copy, + &crc); + if (err) + return err; len -= copy; if (len == 0) - return crc; + goto out; offset += copy; } start = end; } if (unlikely(len)) { DEBUG_NET_WARN_ON_ONCE(1); - return 0; + return -EFAULT; } +out: + *crcp = crc; + return 0; +} +EXPORT_SYMBOL(skb_crc32c_full); +/* skb_crc32c() has no way to report failure, so it returns 0, which is a + * valid CRC. Use skb_crc32c_full() in new code. + */ +u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) +{ + if (unlikely(skb_crc32c_full(skb, offset, len, &crc))) { + WARN_ON_ONCE(!skb_frags_readable(skb)); + return 0; + } return crc; } EXPORT_SYMBOL(skb_crc32c); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457184.1670108 (Exim 4.92) (envelope-from ) id 1xJWf6-0004NN-1L; Wed, 21 Oct 2026 13:47:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457184.1670108; Wed, 21 Oct 2026 13: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 1xJWf5-0004N3-Th; Wed, 21 Oct 2026 13:47:23 +0000 Received: by outflank-mailman (input) for mailman id 1457184; Wed, 21 Oct 2026 13:47:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWf4-0004Gc-OE for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWf4-0082fY-4s for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:22 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c265-bab6-0a2a0a5309dd-0a2a4501bb8a-18 for ; Wed, 21 Oct 2026 15:47:22 +0200 Received: from [209.85.160.174] (helo=mail-qt1-f174.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c269-5984-0a2a45010019-d155a0aeb91f-3 for ; Wed, 21 Oct 2026 15:47:21 +0200 Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-5361e313e63so7844711cf.3 for ; Wed, 21 Oct 2026 06:47:21 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-536ab6f1cd7sm99741cf.10.2026.10.21.06.47.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590440; x=1793195240; 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=YbXvQLGgZpsimSrfs+W8d8Jbr4mc/fISMihOBkAlu6E=; b=AuNp0eeBSQhvNs1v7mk60klD9nA3B04VLWN8Iz5/iqRbUdXUpYJ0XSq7OlNAV/yKvA UV6RtmGl3gTJ4+r6X0WCa938gLdsavR0olM5P3ydCFjlahGsmVmiKCg1rqiMqBhGeZv1 wxGng3PFBMLYIc5MVQg5a9AN+Z2ISa2J3kGgb6aei2dsvvKvkFTCDJTsoNotXsZF44ps YUy8YRv01A7hDNz/ocVYZY2/gc9jGRPNV7dYNQzi87Wcwy0ZgahvYOD8qHAAYOjiL20c NRo227ZYAO+W8YKbnCtTkdEjOK2wdPHP4bloig1xGkU8wGMW5nyztOtGnuYm76n4blrj 2ZSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590440; x=1793195240; 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=YbXvQLGgZpsimSrfs+W8d8Jbr4mc/fISMihOBkAlu6E=; b=Gatdm10E2CcMlmL4rRxrzYZW5Nhf9TXiz6EfyFgoaB0OBTznjV0KsrhHHEaV7Dvk4/ 6nx4OpmWl7y9cbWqGdV3Yv+5Q2m1lLgAq6KHaNjR8Gp3YCIpxc8XMt4YRwRteJkKbHwv UcAoHlN6RAorWD1Ux0EPRTXOvy2AnM8HU6T7l758hLr1/HvBsEYXjF9wZXUi0HzeX+QX wruekm7CYoRRQ3cxbnE+OKXfCRwh2rZfFDOP7ERT2B9Kjktlte/gAgkwZcE+1EiKgoH3 adEOKtOK/F9TX86xNWDdupfkE2YYW0IFTq0XTS2uq1y2Vy1VVOL8tTY6ssN11KEB9PXM Foqw== X-Forwarded-Encrypted: i=1; AKwUvBxCJIn+M2IwYk1GPsrLhb9VEs4Bp2+iLiYoBvcVktpLccuMN9j24mwqgoTtlnxOqMMP65whQ22dn78=@lists.xenproject.org X-Gm-Message-State: AFq9FYIvVaEVr4YmDhusOVvpFEAFLO0+aRI5EzOtapV2OZaVEJPY5HFy LVctBTdTJHq4Hjz6Xba4tbvs3f8LRt4XLKI6ySXiANXKAMOt+KeNIflWPfnDM5EnF9U= X-Gm-Gg: AYBFou0MpjjfFYoqK1dW2PbTYPNiWQDXaAbic6Mi9K86SVmrANg/UfDoOV5yptH+Fqk 9wQ04GFWBtzBzSELqfUjsQhUoVzvRSii2EhK/U3IVbkXNZJulqldI4dcvD0YVpyLSLqND0MvCRM mQ1kANH8WmmCAFmVlRO1Gj72A1/sVbMWouK6HrPVciLxfX/0HKemYKcXLDwypldlZOnlw99NJeL yZhNBk56mxk3uCsGrtRHV4Ds8QJ4bYoOukO/cXaJ3t8kktpI9kFFdJLj8cywmY8TlB1//wKyxQf Ga79+KKTJUGUd8Ph1GeQ9VxgAsXq0szScegaJ87s2rgQcPeuX1Re8PTh1OH6IqzB4X+gYTVe8nI A6Pu2jIDQ8Dvl6FBk058NvRAslqA1f+q4UGICDQPwldzFqvVcIYz1Bv3lfy5Q0n5NQwTxz6XgO5 yrSOJNslY9BW/kl7YdFMSV7+4sldMOGjigIygP6MihdxAx9eSS+1ZnQqcixZtAR1P8+lJkLzIdU DDUuXGWcgnXP7fhgzyLYcLse1Q+K1c+lXh7F8THK5XFOp+61JbWd6RcxnucAjqGy1np3Vyf X-Received: by 2002:ac8:59c9:0:b0:535:1a91:1d24 with SMTP id d75a77b69052e-5369b7f388fmr31766751cf.43.1792590440431; Wed, 21 Oct 2026 06:47:20 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:51 +0000 Subject: [PATCH net-next v2 07/15] net: skbuff: let skb_zerocopy() copy a short skb without head_frag MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-7-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=3126; i=josef@toxicpanda.com; h=from:subject:message-id; bh=p1EJ3Mjc5nJGteUiFCelu7Pkg91i/fkjkkkh/ts8Tfs=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNjL87kVYWUrnftY9mKgbby2CAWEAfeQsOPkOxYJxwdVe1tb8PkhdyoBdSvFLiY/y+B7u4uFDoJ YD3tF1Z8SYAA= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1792590442-1DE78757-F2D6B848/0/0 X-purgate-type: clean X-purgate-size: 3128 Commit 433380f5ab8f ("net: skbuff: don't BUG() on a missing head_frag in skb_zerocopy()") turned the BUG_ON(!from->head_frag && !hlen) into an -EFAULT return, but left it ahead of the small-payload path. That path copies everything with skb_copy_bits() and never references the head as a page, so the check doesn't apply to it. Open vSwitch gets there with an ordinary request. OVS_PACKET_CMD_EXECUTE allocates the packet with __dev_alloc_skb(..., GFP_KERNEL), which gives it a kmalloc'd head without head_frag. A POP_ETH action on a 14 byte frame leaves it empty, and a USERSPACE action then queues it with queue_userspace_packet(), which calls skb_zerocopy(user_skb, skb, 0, 0). That used to BUG(), and now the upcall fails and the packet is counted as lost, with a WARN on CONFIG_DEBUG_NET kernels. OVS_PACKET_CMD_EXECUTE only needs CAP_NET_ADMIN in the user namespace that owns the network namespace, so with the openvswitch module loaded any user can do this from their own namespace. Move the check below the small-payload path, so a zero-length copy succeeds the same way it does for an skb with a head_frag, and document the -EFAULT case. Found by the Sashiko AI review of v2 of the series that made the change. Fixes: 433380f5ab8f ("net: skbuff: don't BUG() on a missing head_frag in skb_zerocopy()") Link: https://lore.kernel.org/all/179173804997.434549.4450793967361922984@kernel.org/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 3b2a3747f009..735dd25213bb 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4014,8 +4014,9 @@ EXPORT_SYMBOL_GPL(skb_zerocopy_headlen); * Return value: * 0: everything is OK * -ENOMEM: couldn't orphan frags of @from due to lack of memory - * -EFAULT: skb_copy_bits() found some problem with skb geometry, or readable head - * payload would be mixed with unreadable frags. + * -EFAULT: skb_copy_bits() found some problem with skb geometry, @from has + * no head_frag and @hlen is 0 while @len doesn't fit in @to's tailroom, + * or readable head payload would be mixed with unreadable frags. */ int skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) @@ -4026,15 +4027,18 @@ skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) struct page *page; unsigned int offset; + /* dont bother with small payloads */ + if (len <= skb_tailroom(to)) + return skb_copy_bits(from, 0, skb_put(to, len), len); + + /* Without a head_frag the head can't be referenced as a page, so the + * caller has to ask for it to be copied. + */ if (unlikely(!from->head_frag && !hlen)) { DEBUG_NET_WARN_ON_ONCE(1); return -EFAULT; } - /* dont bother with small payloads */ - if (len <= skb_tailroom(to)) - return skb_copy_bits(from, 0, skb_put(to, len), len); - if (hlen) { ret = skb_copy_bits(from, 0, skb_put(to, hlen), hlen); if (unlikely(ret)) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457185.1670118 (Exim 4.92) (envelope-from ) id 1xJWf8-0004gF-DO; Wed, 21 Oct 2026 13:47:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457185.1670118; Wed, 21 Oct 2026 13: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 1xJWf8-0004fo-8F; Wed, 21 Oct 2026 13:47:26 +0000 Received: by outflank-mailman (input) for mailman id 1457185; Wed, 21 Oct 2026 13:47:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWf6-0004Ps-E1 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWf5-0065O0-Qi for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:23 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c269-2eae-0a2a0a5409dd-0a2a4502dad4-10 for ; Wed, 21 Oct 2026 15:47:23 +0200 Received: from [74.125.224.42] (helo=mail-yx1-f42.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c26a-6ca4-0a2a45020019-4a7de02ad4d0-3 for ; Wed, 21 Oct 2026 15:47:23 +0200 Received: by mail-yx1-f42.google.com with SMTP id 956f58d0204a3-677bc4704cbso661451d50.0 for ; Wed, 21 Oct 2026 06:47:23 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-67a0e501bf6sm1068068d50.14.2026.10.21.06.47.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590442; x=1793195242; 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=8wxt1Epm3k3rT9QE881oEaKsrBbXJoueUEmgjTPk70U=; b=pLNb3CezOhCRkdIm+KZ/s3uNcq4wTjgUXY6G0lz+uea1B91sVvISZSO5HhV8EpmyNM a14oCsJFkluDNIQv0L2Miuu6eKOEdv7Z7FnV7nXMp8LXT4D5rYBLuVIiYcKHwlof6qJx HxbF/zxOXXehGKfppNDqgl7mNl10GgYZYICOKlnj1lEgt4/wMgtTFr4ZRyd2pelJb/8H Oo19uXEkDGSsIeG7IgqrE0/JBDQQlquXyrdNFE1VMGwjbLV5lvoK9UHKV3mhPhbcNGW0 WDg8mNNTbt9yTW/CfrqT78NT3zUd71cWamgm36rG2yCWsbXaJjhgvC9YytSmWLvTYvA/ wSqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590442; x=1793195242; 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=8wxt1Epm3k3rT9QE881oEaKsrBbXJoueUEmgjTPk70U=; b=CUt1gzq/NCzRoh85ZagSzW+Pc+7bio8u0mg/ANKpop5sBIa8AUjmb0ZLwqxgrh5Fxm n0XWyzR688d5m5kYPiz7JBeohEkEazqaHE2WwBtNMRXEbKkH48RljP6V1URo5HjAcaAP LPi8qPP6D+giBP9M5DjZWjasTE9ZXUJsWB/uMPeeruFKE/jdLiQLOgk8mzuPaSLjE+c/ Z1k+gVfzK3FRee2nqlqzG3YSqlPQxB3myRh24CvXLh22Xew450Caut8ZtYZDmim20ttG 2H/U2Dm6HuMRnZAl9fo1YFxZh23p68k4vcyNWZ3pbhN0v/e8YGspFK8X76G6JWP2hsNM YH/w== X-Forwarded-Encrypted: i=1; AKwUvBynTUKcr2pl6yb+I/ieXLQ3+BVSVr/khehYUm9t8+4JBTHunVOUAhLO6HjPuyNnLG+Pqgzs4acINoY=@lists.xenproject.org X-Gm-Message-State: AFq9FYIsYaIT3cRfdoq1e2my5gFn2R7f+CmATbs9EGVnhfGSQ19zaDVJ gMvejoJXeb6pplnfV03YnaPHBpE1P7gC5njfzh6ITya38Ojma2hCb7Oc8T7aHB4vZwk= X-Gm-Gg: AYBFou2Lfd+ISD7oKvBbwLVvadOz1+kpxpJMCsKeD81jO60+M2GpwEbweRTIvyt9Nd6 3P1c3az+3guvkoc7VDRfjd8+8W78mD4jbVNPK8v4MKc0PTTxoYJl8+GeQIcYJWxtlYErbUokVAT BXFRfYmpZ5jS4SPeuVCFC+Yoqik4Ye0ZsB1epjv2V9ZUEbn/6U5xroHviIETaWLSpxLe1o/Xxyo GEBX5toe/yHWW45FbOb4ItLWlRmfSu4KsiTXEUVSTlNX/d2STHO7/sE5DOe2pZJgXLGPZDTZnAK aIAvWCACKh8YT2lDNFbbpEaOKoMlgjG4Nm9HgDJeLIiztD/1qXkVjpDyTePs73G+a8BbapQvMQm 6OQL+kowSf4Fs5wFg/7LFSqXgyED/bnJkXuXe+L1+Z1AEOxhrWKvR0ROBJYUvXO2Wxjm5JpRPMT qG1PgaDrOBmY0H2a7zUvRvOA52qzUIWracoJTCTc1xp08H7LuPPIp8cjHrxTbAiLxqZAhn0DGt6 Q8eRF1w2ayB/Mvsscq+b5xBLDCYVhsKThKlAmqjQmT7mqn6aryAAzX61p/CXwpR9ZuzpF+l X-Received: by 2002:a05:690e:140e:b0:679:9942:8977 with SMTP id 956f58d0204a3-67a0e034ce2mr861218d50.7.1792590442281; Wed, 21 Oct 2026 06:47:22 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:52 +0000 Subject: [PATCH net-next v2 08/15] net: skbuff: make skb_try_coalesce()'s len unsigned MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-8-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=2184; i=josef@toxicpanda.com; h=from:subject:message-id; bh=GLGsUKpELPU6q+dQsnPVRh/KHoYno5QlglXwcqwsDWs=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QHtIQpXIZEHUiTOUwL7sUcXUNd8TtVIN+/3dZDmNgDJuDjg0ASyNkhneJ5Ri6l2qmlypziQED+1 55FOiTpYFJwc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1792590443-660A82AC-4DEF8A2B/0/0 X-purgate-type: clean X-purgate-size: 2186 skb_try_coalesce() keeps from->len, which is unsigned, in an int. A corrupt from->len above INT_MAX turns negative and gets past the len <= skb_tailroom(to) check. Commit 279877d86c82 ("net: skbuff: don't BUG() when skb_copy_bits() fails in copy helpers") moved the copy into the tailroom ahead of skb_put(), so that check is now the only thing left in the way: skb_copy_bits() clamps its copy to the negative length, and memcpy() takes it as an unsigned int, so it becomes a ~2GB write past the end of @to. Before that commit skb_put() ran first, and its overflow check caught such a length before anything was copied. Keep len unsigned, like from->len. skb_tailroom() is never negative, so the tailroom check then refuses such a length, and every other use of len already takes an unsigned value. The truesize sanity check compares the int delta against len; spell out its delta < 0 case so a negative delta still warns now that the comparison is unsigned. Found by the Sashiko AI review of v2 of the series that made the change. Fixes: 279877d86c82 ("net: skbuff: don't BUG() when skb_copy_bits() fails in copy helpers") Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 735dd25213bb..5c89c463f234 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -6392,7 +6392,8 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from, bool *fragstolen, int *delta_truesize) { struct skb_shared_info *to_shinfo, *from_shinfo; - int i, delta, len = from->len; + unsigned int len = from->len; + int i, delta; *fragstolen = false; @@ -6463,7 +6464,7 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from, delta = from->truesize - SKB_TRUESIZE(skb_end_offset(from)); } - WARN_ON_ONCE(delta < len); + WARN_ON_ONCE(delta < 0 || delta < len); memcpy(to_shinfo->frags + to_shinfo->nr_frags, from_shinfo->frags, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457188.1670127 (Exim 4.92) (envelope-from ) id 1xJWf9-0004uz-NB; Wed, 21 Oct 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 1457188.1670127; Wed, 21 Oct 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 1xJWf9-0004tx-Hj; Wed, 21 Oct 2026 13:47:27 +0000 Received: by outflank-mailman (input) for mailman id 1457188; Wed, 21 Oct 2026 13:47:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWf8-0004jK-QC for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWf8-0065O0-6r for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:26 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c269-2eae-0a2a0a5409dd-0a2a4502dad4-20 for ; Wed, 21 Oct 2026 15:47:26 +0200 Received: from [209.85.128.179] (helo=mail-yw1-f179.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c26d-6ca4-0a2a45020019-d15580b3d5f7-3 for ; Wed, 21 Oct 2026 15:47:26 +0200 Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-8b10ac6ab7bso7014097b3.1 for ; Wed, 21 Oct 2026 06:47:25 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b1300c85c9sm11376607b3.23.2026.10.21.06.47.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590444; x=1793195244; 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=i59cwFpnwV4ZWelO27hAghlfIgiy6O8zXnZ0ftvy/nk=; b=AFSJRYlkxA9bwg1z1aVODNAMPx1P/r81DrySWCFC21j+/ayftiAUfZ5QszzmcyR9w0 zkxv5/c59BJ5jX8FXdp0QbRM9PQm62jOtA8TR13hI2gnaObq0A0ugVIpFQ37O8jk5nV7 UApyYq3xbv++NmE9CuOYFUncluJNy4KpiXpOeZfrO5OGfRvwBodI2j+v1UTXV/97Em1p PbxR7+72IgvkJ/GqmQSLJWG4u686NJL7Ej2JbXccVes6dLpz54sH1G3p9g2gnb27v7Mo LZpenyMx6uagZ5kuE8VpSen7TMDrjX5+gXr2CYvKNFlpeZcSJXvSTIq1Mxmq9PZa6abF q9XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590444; x=1793195244; 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=i59cwFpnwV4ZWelO27hAghlfIgiy6O8zXnZ0ftvy/nk=; b=RNEOKM4wbWZ2Wk6irQ3J4/dAcoOmbfHnF45mgWLiZBHgGRpDG0C6NDPUt0+N7FomDf kpwbRjxaElNhVor77mVcarLu43GgZ/2NG/XXZq+3O42XZX+Q/KTSZbTnNpk1yzJ+1yc6 ma4PUyRpASEw+9jNCXk+u/QaKLfcqcZD3reqcIJs1L1jGVwWIWCAjd0yggQZnrQJuQ0d sSwXEDHDJGpc3Ozc9cgH4LawMp8bEI3Nw5+4FiF2PDnrIsvheI9CiEmTZXWpoDBDTeQl pCoJ9lfpvGfElUKN+JMQqYZCHX7z6cbibUgwdiMdpsXvRswJT1rLzuDT/yj3bM4S7OmB 2qNA== X-Forwarded-Encrypted: i=1; AKwUvBxOvprTMXI91k0OdhUuWkhREJvt/LfCY6YTG8YX3P5d8JYeN4DS3G5nha+xBSoP1bS0t5SRFBMqIqQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYJztPqYfaJH6izdEL89oub1yPu33jOWtOtQg6fxe5n6Lom2VWEC w4NWzaeLajfdNhn3ZU3TgU5mtCkyhxii4GqCgRF6wHUdAMGgNczxHqyJZcYCAhSP3Qk= X-Gm-Gg: AYBFou10a6NwBUjsHYXN4LIzqvvwFHN/CseLaHRN8dIlslQMMuYB9So1k/2XN+CxP3N t8UiQZ9K/9pIOB0YnwzL9GgQ3cWNZF92IlGRdcHw1E2p6VPrMuhb9dmY3GzkPNzO0J7uUBOyHGd 7ly82iPZpng1JT4Z2Th2rVJYnts7vQjSW9knY2plfJiCWzI+bKWyhBdT809S09hMOfZGw1AtbO7 46QuAFrJMF25zuZ3DNdWKgwgVvA2h73bWw1svgbnTgXRyKSLVesGZy6ibkjgIS3UPaIOVzfaKR+ zl1SjZNNZg5YDltkveEzAXdSXIWER+qExiZiIPAJDv3OCGxc38HCd31TB5TCAbwmEzLbhEApIKp 8m7r1YzscOQqD0Ffuy/Xs06PIvlZGgu3xTsCjZRcl/0nb8uPDjUFnd5TgLHUXi6VwGqiv8PYAnX R6Y10sNy5/TQyvPHi9/SoJ7gt2qhRAL/qKCTxCKBW8HNLv+WFBXIbvVEEkIU4tauzSjuoFLUhqw 6fkrkA/kPgJ62pHHT479j3bi3X9gnLrwnQt0hRe79jXJkTGHpVMxBJYstUoHN5heLZz99cWxFI5 SIrRsLXX24DMHidioA== X-Received: by 2002:a53:b651:0:b0:676:a43e:ea5d with SMTP id 956f58d0204a3-67a0e53f355mr566093d50.94.1792590444386; Wed, 21 Oct 2026 06:47:24 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:53 +0000 Subject: [PATCH net-next v2 09/15] net: skbuff: check csum_start against len in skb_copy_and_csum_dev() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-9-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=1647; i=josef@toxicpanda.com; h=from:subject:message-id; bh=sxMOxEm7hnqJ4JHjLlLYqgrWX5cOQpVgaNwl3bOsGCc=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QJ5DZXQlsw5+XJkbUArUHkgGRU3eEEoiu+2jmTppSATvScEPdtV2sfsGUnIAGlonU/HYjZGtwF3 0pwcvexSMIwc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1792590446-309C32AC-27F8C5FC/0/0 X-purgate-type: clean X-purgate-size: 1649 Commit 56453199d28f ("net: skbuff: don't BUG() on a bad csum_start in skb_copy_and_csum_dev()") checks the checksum start against both ends of the linear area before copying up to it. For an skb that isn't CHECKSUM_PARTIAL, though, the checksum start is skb_headlen() itself, so the check compares it to itself and can't fail. If data_len is bigger than len, skb_headlen() underflows to about 4GB, and that becomes the length skb_copy_from_linear_data() copies into the driver's bounce buffer. The old BUG_ON() had the same blind spot. Also check the checksum start against skb->len, so such an skb takes the existing fallback, which copies at most skb->len bytes without filling in the checksum. Found by LLM review after the series that made the change was applied. Fixes: 56453199d28f ("net: skbuff: don't BUG() on a bad csum_start in skb_copy_and_csum_dev()") Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 5c89c463f234..782a6bacd568 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4103,7 +4103,11 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to) else csstart = skb_headlen(skb); + /* skb_headlen() underflows if data_len is bigger than len, so check + * csstart against len as well. + */ if (unlikely(csstart < 0 || csstart > skb_headlen(skb) || + csstart > skb->len || (skb->ip_summed == CHECKSUM_PARTIAL && csstart + skb->csum_offset + sizeof(__sum16) > skb->len))) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457189.1670136 (Exim 4.92) (envelope-from ) id 1xJWfC-0005II-C1; Wed, 21 Oct 2026 13:47:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457189.1670136; Wed, 21 Oct 2026 13: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 1xJWfC-0005Hh-7N; Wed, 21 Oct 2026 13:47:30 +0000 Received: by outflank-mailman (input) for mailman id 1457189; Wed, 21 Oct 2026 13:47:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWfA-00053x-DH for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWf9-00AIK2-QL for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:27 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c265-bab6-0a2a0a5309dd-0a2a4501bb8a-40 for ; Wed, 21 Oct 2026 15:47:27 +0200 Received: from [74.125.224.48] (helo=mail-yx1-f48.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c26e-5984-0a2a45010019-4a7de030b10c-3 for ; Wed, 21 Oct 2026 15:47:27 +0200 Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-675617e81f9so628253d50.3 for ; Wed, 21 Oct 2026 06:47:27 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.240]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-67a0e185441sm1078051d50.3.2026.10.21.06.47.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=1792590446; x=1793195246; 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=NueD3KcSYkb8JdZSOJlKL8CiOB7BO395X3cXr1iZapo=; b=fMChHudTgr9flx+XRJ+qRCzp0jQVf7BlG0ySn4MzcudkteKxEpP/G8nN//QCG1qsUp tJM/yrwGqfSkMKDJKbE6aeCqWt7G24it2CyGwTsWHbEPqKtl3AduGaYzba2xIJxet2W/ S0XBzil3uaiizuqJ12FFxdFOcDaGcSEHwc1xeA2hqiwQkXzCJfF3tjWZETuaskinF3P+ QC/WY/UR5240nD+kdB+1eiuKXgQwOXLwKwlSImDcs+ikeiqGb/663nwc2nW70N+2cGHS 6zN9paLzDxL6KaOe9FRkLAgxSZRfUnoicKohpyuRxoszuqFRLaG1szWakLpQ+JxwwjgS vYeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590446; x=1793195246; 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=NueD3KcSYkb8JdZSOJlKL8CiOB7BO395X3cXr1iZapo=; b=mJDQfIju0WmxgreMTNqwz/G01H3dcejZrEap4SLjMb7M7q/rAvRDFNKYpcvMG09ybQ VKqESUW59M3Zm5QUET8glqz2rVN1/rJdu1eyXOQiiX6Y2F4tLeJTi5F9eF66+rVGhxM0 cYC79cNhJv7PXJongqBKrPP1fRJhAqhIb9dh7XJS/SPUCJu0ofCg9eiNNJXp3Inl28PI /xs8QCQfCZXkhIuL+XkkgFohYd8A6mqzVtwS3zARwF3XB9035JqMc+AMg2qnRcVopKRP pmcxU4tZSTJCuAwayuMgYPuC+VlmwI1wOmrVjnnwTzpEcciIarZa2j9ZWJU33LXujMWQ s9GQ== X-Forwarded-Encrypted: i=1; AKwUvBw54r3i361UF7s0NkCeQyJpFvSXllR+fri+/4/Abenr8b8+RjbWUce/n9Z4FalPpd7vvr4OYo2ctVE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ3QHISrAkBQhwmdnVNADHROeOOeLWVT5K2MVzZjXboi5Kfo/fi 81JF2VLH0/sDaMNYvgB27d3xNWS11GNfYKiOjYhxzZ+3q2qVYNw6VlspRyiH2PTgE6o= X-Gm-Gg: AYBFou1MeUCSzW525YKvt+OmNyRsX3g1/E0MlOQfyHfd9/G5TFL2ywCbiIjg3djHFDz enDRzpCrLMhtWseMlHVLux3TU0mwXci1RpAKbQjfv31+2mgxL/HxIWnL5QJukyX/KbLk1gucqVR URzxOpwV+pU2wyNNjorG664jXcVTOA79F8f68Ecg1l9at7WEgisgfbrYivThpUErc0grdY+VgH1 G9Je6uiTWLWBrEpNU9tBjldCMwDexjeoD8dX2ooGCfSG59SJLShutnat1ZeVt3jUCMWrcUhOA37 GLSB+H8pmzJmwMDlvVP6Udh9UNJVj8l4NDlB1SJRw3nk+K4AQD6v7DDWuAAo3nu8wn3cQmE6uC0 BuqfVFVyJrnvOYsZ28rSnBTHdNHfpA9A/GsA8b0HELxknMs02N44ul6zz2sf7BJfixE9DSQvRQw B6LXm0eGGUgzsQIaP8Q3NZ7BYQkicP9YkCa5Wnjqchp41nQ5x9rSTEUzgmv5UewCyO0ZwzddKyk JVM4id+ecfoScNEyhXRUh55ESvC5u2RMfw69YwKplg4fipswKIHR5AECUQmh4xX/PYeHrJA X-Received: by 2002:a05:690e:4853:b0:675:617e:6c2d with SMTP id 956f58d0204a3-67a0e4b66b2mr896013d50.25.1792590446255; Wed, 21 Oct 2026 06:47:26 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:54 +0000 Subject: [PATCH net-next v2 10/15] net: skbuff: reject a negative length in skb_copy_and_csum_bits() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-10-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=2599; i=josef@toxicpanda.com; h=from:subject:message-id; bh=II/CP7Oe6pPmnThcZPqfbajOFeQVtnEAdIjZymwWmTI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QBCv/T4tuugSwX2rkOLKSCWrxmAA7LyX/rWbZaGf+yX4wPBG8KKxQ/YtsGe6jDvfA44EL7VQpSI 8w8aIZgV/RQE= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1792590447-1E07B757-510F8D62/0/0 X-purgate-type: clean X-purgate-size: 2601 Commit 417261779eab ("net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()") guards its zero-fill against a negative @len from a broken caller, but such a @len never gets that far. The head, frag and frag_list copies all clamp their length to @len, so a negative one has already turned into a huge copy, or an endless frag walk, by then. Reject a negative @len on entry with -EINVAL, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels, and drop the guard on the zero-fill that can no longer be reached with one. Every caller already handles an error from skb_copy_and_csum_bits(). Found by the Sashiko AI review of v2 of the series that made the change. Fixes: 417261779eab ("net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()") Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 782a6bacd568..56cec58bccb7 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3678,9 +3678,10 @@ EXPORT_SYMBOL(skb_checksum); * @len: number of bytes to copy * @csump: where to store the checksum of the copied bytes * - * Return: 0 on success, or -EFAULT if @skb has unreadable frags or runs - * out before @len does. On failure *@csump is not set and the part of - * @to that couldn't be filled is zeroed. + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb + * has unreadable frags or runs out before @len does. On failure *@csump + * is not set, and on -EFAULT the part of @to that couldn't be filled is + * zeroed. */ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, int len, __wsum *csump) @@ -3692,6 +3693,14 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, __wsum csum = 0; int err; + /* Everything below clamps copies to @len, so a negative one would + * turn into a huge copy. + */ + if (unlikely(len < 0)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } + /* Copy header. */ if (copy > 0) { if (copy > len) @@ -3777,8 +3786,7 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, if (unlikely(len)) { DEBUG_NET_WARN_ON_ONCE(1); /* Don't hand the caller a buffer with stale bytes in it. */ - if (len > 0) - memset(to, 0, len); + memset(to, 0, len); return -EFAULT; } out: -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457190.1670143 (Exim 4.92) (envelope-from ) id 1xJWfD-0005YL-PA; Wed, 21 Oct 2026 13:47:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457190.1670143; Wed, 21 Oct 2026 13:47: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 1xJWfD-0005Xa-Kt; Wed, 21 Oct 2026 13:47:31 +0000 Received: by outflank-mailman (input) for mailman id 1457190; Wed, 21 Oct 2026 13:47:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWfC-0005Ke-Nx for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWfC-00AIKh-4e for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:30 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c26c-e002-0a2a0a5209dd-0a2a4505b806-32 for ; Wed, 21 Oct 2026 15:47:30 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c271-4cb1-0a2a45050019-d15580acbd92-3 for ; Wed, 21 Oct 2026 15:47:29 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8b0db268bd8so4644947b3.1 for ; Wed, 21 Oct 2026 06:47:29 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b1300715cfsm11333607b3.14.2026.10.21.06.47.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=1792590448; x=1793195248; 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=2KWwlh/hCg0SMpmIsRqC2+1Lcm/oFCtvXzTkdFFgQUQ=; b=cRexcqVwq2TgMJKWPGrFBijzh26jWGKVqRwZtVeSGdPObAKLku5b9crhqx7ZHPNWcB ztrDn78DB2q7PlVnZ8CjHfOcOxVN8/zDc6KvMsLHYMl4NcIzyrqTJQQAQyr+GDku6oY2 nVFqXTVrPb9CIQ6OpAgoqfDXo8Xd/1M1tH5tv3Y5WveVnBJvDqDLiswXEoWyuNkWhAiD g20gQOD7mGYLvqKRL0bcspVxxZAO/8yOKdt+Bj71Iv2TdKOqCiynUM+f3QyXo4cN8ZbP aFpLPrONwBbCWGRt4/UaKDt1ksEcWhOTzxaWLjdPcZ/3EaYPy2FjZNpivKRq0O/K58/j AwVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590448; x=1793195248; 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=2KWwlh/hCg0SMpmIsRqC2+1Lcm/oFCtvXzTkdFFgQUQ=; b=1R4VhZ7n6+uPXr4IGQLmmMHKuq38lu3A8YwMli8ZngUBgTC4//xOLPde/kztfQjMDz EN7NKhPJAPPVxjCfFzLhIM22jOuTkwyFq1hWkt1kvAg/twk1rfYk+jLmr700DTk2HzZy 0tHc+QCJfPHH9/Wxujq+JN+IvgcMDBe0sIokV7N7eyr2yCpFD961pY65jb2u8986nTtL sEVeLZS5dzqacOep3kUQvF/SeiSSF98KNflzPRQ7TPP2HUm4M+G8xkm7i1wjtmGZVPXx x+6VRmKyx+5vQDTR//+OkHXBVKXD/NfSFC5anZuhg19D+Y/kdrlN8uoaITJ//kjER8OA 2GzQ== X-Forwarded-Encrypted: i=1; AKwUvBw3RwuXj7nLWGo121JjvuMlYx6P2UWtmnEr1fDgKhn663u6jhUUTFlGFGH4um0g3L3G361nvqAZrGM=@lists.xenproject.org X-Gm-Message-State: AFq9FYLwSMcIlHA227rDrjnC71juxwqInLPjO/HK4d5CCT+0w17jG5tN LR6tBVZq89Wusrw+SkvHOfWmSJh31itBpm27jmj8zokjHcuKt1gpyGMu1EG3VAQvXTZ5M9KfH9i QSQ3g X-Gm-Gg: AYBFou0mfcOlIDUd2rZ+LjLSQBkyMKEorBtZ2UK+TElWBg0ZYPrFVvQ29ffGXSuyJLX DQDWreF6Degxilo8xGDZlY2dOPRjAkKJouqZecBLf1nncv2VXmDNVgB0HUdZ7h4Tj/VIWA2dxOV XPih/gb8dP+OoyEwnN6QKFc7WbfV77RXkv3IRbA0aOOQV7GXn2LipqNjJDTeItkd8gSKSznAMHt siVQqw0kyXvgHCmB+WqE5SVUNF4ZDwVTK6zP11qDEkHhYqOMkKbsmueUNTM7eR7s0ZXSZbWYd8n /JqB7r0e4v9uwCIneBBBaOiGucUi62u3LKTZToA3KOA3GmWyDutcQI8pjvnAiDaOT2Pi03VliZj URqatO51rLp2uMSQeY/bQQTMdIVh1F+l8rrGWH0a34D/rAWMs+n9w/7Esf7YFPcp8GzLtYufrL3 jG+2cdutsnIJWYkXScdthgDFndLfm3Ca8T3uVpyPUMjGnDfx21I+ZEDuGKXpKGRxVO8XlyXxG+e wDDW5hQgkDCLnv1Mhc4DjpKDmpO1lEjTtqKU8hwdIrjn3P13by2zwuwFibu5QjO8pkaP5fy X-Received: by 2002:a05:690c:d87:b0:873:5bd1:98b7 with SMTP id 00721157ae682-8b13403e9b6mr12177067b3.41.1792590448219; Wed, 21 Oct 2026 06:47:28 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:55 +0000 Subject: [PATCH net-next v2 11/15] net: skbuff: refuse to segment a nested frag_list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-11-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Willem de Bruijn , Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=2884; i=josef@toxicpanda.com; h=from:subject:message-id; bh=bYC4uz0w4NZKAYryGVW9UUHYf9kR1dL3ZNzRUgIMFMM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QB/boFORXWtYqGQkg0oKg7TLwyvigi4nOkir+rQFpE7KoN+Aub774BEuZtAZae7bNyllztx+HmX 8eAIEPekArQE= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c201ff/1792590450-72CB02A1-614AFCFC/0/0 X-purgate-type: clean X-purgate-size: 2886 skb_segment() walks head_skb's frag_list, but for each member it only looks at the linear part and frags[], never at the member's own frag_list. head_skb->len still counts those bytes, so with a nested frag_list the walk runs out of members while it still owes data, sets list_skb to NULL, and dereferences it on a later pass, before any of the layout checks get a chance to catch it. When the member is taken whole with skb_clone(), the pskb_trim() that follows also drops its nested data. Nothing in the tree is known to build such an skb; GRO flushes instead of chaining an skb that already has a frag_list. Check each member as the walk takes it, in the GSO_BY_FRAGS, clone and frag paths, and fail the segmentation with -EINVAL if there's no member left or it has its own frag_list, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels, like the other frag_list layout checks. Without SG the payload is copied with helpers that do recurse into nested frag_lists, so that path is left alone. Suggested-by: Willem de Bruijn Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/skbuff.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 56cec58bccb7..c5e28a52114b 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -5087,6 +5087,15 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, int size; if (unlikely(gso_by_frags)) { + /* The walk only goes one level deep: running out of + * members, or finding one with its own frag_list, means + * a nested frag_list that head_skb->len counts. + */ + if (unlikely(!list_skb || skb_has_frag_list(list_skb))) { + DEBUG_NET_WARN_ON_ONCE(1); + err = -EINVAL; + goto err; + } len = list_skb->len; } else { len = head_skb->len - offset; @@ -5096,9 +5105,11 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, hsize = skb_headlen(head_skb) - offset; - if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && + if (hsize <= 0 && i >= nfrags && list_skb && + skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { - if (unlikely(skb_headlen(list_skb) > len)) { + if (unlikely(skb_headlen(list_skb) > len || + skb_has_frag_list(list_skb))) { DEBUG_NET_WARN_ON_ONCE(1); err = -EINVAL; goto err; @@ -5216,6 +5227,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, while (pos < offset + len) { if (i >= nfrags) { + if (unlikely(!list_skb || + skb_has_frag_list(list_skb))) { + DEBUG_NET_WARN_ON_ONCE(1); + err = -EINVAL; + goto err; + } + if (skb_orphan_frags(list_skb, GFP_ATOMIC) || skb_zerocopy_clone(nskb, list_skb, GFP_ATOMIC)) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457193.1670154 (Exim 4.92) (envelope-from ) id 1xJWfG-0005w3-7a; Wed, 21 Oct 2026 13:47:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457193.1670154; Wed, 21 Oct 2026 13:47: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 1xJWfG-0005vI-1z; Wed, 21 Oct 2026 13:47:34 +0000 Received: by outflank-mailman (input) for mailman id 1457193; Wed, 21 Oct 2026 13:47:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWfE-0005kS-Sc for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWfE-0065O0-8z for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:32 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c263-2eae-0a2a0a5409dd-0a2a4508872c-40 for ; Wed, 21 Oct 2026 15:47:32 +0200 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c273-f659-0a2a45080019-d15580accc14-3 for ; Wed, 21 Oct 2026 15:47:31 +0200 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8b0e21048f8so7465957b3.0 for ; Wed, 21 Oct 2026 06:47:31 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.248]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b1347fc578sm8595177b3.36.2026.10.21.06.47.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590450; x=1793195250; 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=k0p9amurCDLU2dmqJDge7ICpn0TqfU4pmUDL+z2zafc=; b=JQoM7TcoX5pi8MFZgJeaB164/VzGrWEZIQ5zc8LKXdcl8ZnB/upSyIIezTcjGLp3gD K9Ui7tb7yKdwfGH680dZYWs0SzMtM9hrxrlt9K11fK3yujR2V2gFV532ISe73gEBn5Q9 O0pgf1s4Dz1vpzG3hCSVKLR5k/epn236JVS4rfVqhVYTcpQw9ZJE9SBPVOerm4nr3VS1 QgOhl035SKnrP88wpDhf2py3fwr/9IgqsndItuKQOtlm8wnvizJ8K9/o0PaTj3PjMu4z 5IDhNnoyfQETAq4uVvTDsvtp2eoHkgKkVMGZI+tY3Nr25WM4ARVvIbYjBtqrZrB0/TLq n/BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590450; x=1793195250; 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=k0p9amurCDLU2dmqJDge7ICpn0TqfU4pmUDL+z2zafc=; b=ptRWt1elk0zdgiLtQCYIiybSM9GYhcPItS9ZZRo/LQYK+ibojtOFrELWSC+rn00qco gcw030sdUIH+ORPD1f3p9rDmL89+vSu0zIZtMTPik1sP4hWAjmjcMyYkW4AOHNAYrjHT 2erDFvuI6pSKlJLU1auDMoEnpaYurkoU+sSfsPeyADyt/Yv1hK0v+VIPUr2gshu/+ecY cvASRJ/RE0mwoZr1CdCYhp1/0DhQ5doZvFxrg3y3Tdn/v/jaUqG8xsVLSoLDUhSPlC1C RU+BjnZ+KRecDkI/rvjgOApURUH1LaI2r8EqURshQAxB2sfvSSK/QOjW+ckyQFJZdJ9L ci8w== X-Forwarded-Encrypted: i=1; AKwUvByy52py8e1CgETP7smRyZsEnXO7RNBp/B53sa42QHwR0a1JQsub6z2A9Vrkvzuw7Q7LvIooAxm5GzA=@lists.xenproject.org X-Gm-Message-State: AFq9FYLkknIdKmowOtDoHbL97eymoHYr1pewQHr7L8/iGP/dhkQA8hTQ hJBytM777Q6OWuXBWTWJ5YV82fa1JZoCXQXqpYMQE2rXU/CWCSyMhiw/V8rQDydQUUA= X-Gm-Gg: AYBFou2QtcQBHFjdm1MX1OX8AC88RAHKwN8Mb9msPtf5To6VAqoM+pItMsIBIQlX8ta jqWKnQ5u4aTNIEOrx7FSNB67vC5HdGdZUvJOmHn0aGmXjmYoQfOM4tWpOCWq/JPtHxnXm/WsEU1 82leisfwl/xluw+2w3iPDn4TBGvz23zIvEkoMcxgOm7LoiOTuzyQitBHt7/wj4AX7IC8TRuPjLW hNpwt8wSBlXf91rb9XheIgD6xyCaNO8L2Dx8oJxVWQZUjjxaA9alkCfMearbAjcyrEPjJLN5bT1 VoezAeR1Ek6zdNf+YXqrWfWy/85fHH4BlzvI+ZQ1zkCJY+XD1jQb4nCw06GBBfVThB40V3ST5Tr wxXZ1LRPZGD2X9VmDp43kltZAAqEK/T81Wh93UaKUsLLS4g43IhIbP84yIj4tIeKtX4I3LnBbPh Ur/FMOWYEuR3ozHsga9li4dxR4+QI++nnSDXxLVtDO+o04su5OLsZz6K3egBuhevsbzV7+h/eGG dKcFdUOSPFPDtCMMps2lGOLUFjpLXwoZOFBtm4LS1DJEP58jOmDoowfAkXBCSBmFDpNFptwvcd4 oZaobDTm7dhnUuk0zQ== X-Received: by 2002:a05:690c:282:b0:8b0:8a9c:fac9 with SMTP id 00721157ae682-8b133fdfa78mr12586347b3.28.1792590450548; Wed, 21 Oct 2026 06:47:30 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:56 +0000 Subject: [PATCH net-next v2 12/15] net: test the frag_list layouts skb_segment() refuses MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-12-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Willem de Bruijn , Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=3631; i=josef@toxicpanda.com; h=from:subject:message-id; bh=ciolQj524j1USUzaeLZb/LHm0dD/CBvyPNIxBZrRY0k=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QJe3JwejlUG1MTBrcQrYruvC03fnpYN7R/Yfj2aVB3nUZLxD2jgW6l4Sp+Atgj8oyoEvxHlliU3 gY7jb4nUyNgY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1792590452-D554C87B-D34DC262/0/0 X-purgate-type: clean X-purgate-size: 3633 The GSO KUnit test only checks layouts skb_segment() can segment. Add two it has to refuse with -EINVAL: the non-uniform frag_list with SG on, which used to hit the BUG_ON(i >= nfrags) the existing test steps around, and a frag_list member that has its own frag_list. Both warn on CONFIG_DEBUG_NET kernels, so run them with the warning backtrace suppressed. Also update the comment on the non-uniform case, which still says SG would hit that BUG_ON(). Reviewed-by: Willem de Bruijn Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/net_test.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/net/core/net_test.c b/net/core/net_test.c index bc2ef7612e7d..222d24793591 100644 --- a/net/core/net_test.c +++ b/net/core/net_test.c @@ -39,6 +39,8 @@ enum gso_test_nr { GSO_TEST_RESEGMENT_MULTI, GSO_TEST_RESEGMENT_TAIL, GSO_TEST_RESEGMENT_ONE_MSS, + GSO_TEST_FRAG_LIST_NON_UNIFORM_SG, + GSO_TEST_FRAG_LIST_NESTED, }; struct gso_test_case { @@ -57,6 +59,9 @@ struct gso_test_case { unsigned int nr_segs; const unsigned int *segs; const unsigned int *gso_segs; + + /* skb_segment() is expected to fail with this error */ + int err; }; static struct gso_test_case cases[] = { @@ -204,6 +209,28 @@ static struct gso_test_case cases[] = { }, .gso_segs = (const unsigned int[]) { 0, 0, 0, 0 }, }, + { + /* frag_list members that don't end on gso_size boundaries + * can't be segmented with SG + */ + .id = GSO_TEST_FRAG_LIST_NON_UNIFORM_SG, + .name = "frag_list_non_uniform_sg", + .linear_len = GSO_TEST_SIZE, + .nr_frag_skbs = 4, + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, 1, GSO_TEST_SIZE, 2 }, + .err = -EINVAL, + }, + { + /* the second frag_list member hangs off the first one's + * frag_list instead of off the head's + */ + .id = GSO_TEST_FRAG_LIST_NESTED, + .name = "frag_list_nested", + .linear_len = GSO_TEST_SIZE, + .nr_frag_skbs = 2, + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE }, + .err = -EINVAL, + }, }; static void gso_test_case_to_desc(struct gso_test_case *t, char *desc) @@ -283,19 +310,41 @@ static void gso_test_func(struct kunit *test) if (tcase->id == GSO_TEST_GSO_BY_FRAGS) skb_shinfo(skb)->gso_size = GSO_BY_FRAGS; + + if (tcase->id == GSO_TEST_FRAG_LIST_NESTED) { + struct sk_buff *first = skb_shinfo(skb)->frag_list; + + skb_shinfo(first)->frag_list = first->next; + first->next = NULL; + first->len += tcase->frag_skbs[1]; + first->data_len += tcase->frag_skbs[1]; + } } features = NETIF_F_SG | NETIF_F_HW_CSUM; if (tcase->id == GSO_TEST_GSO_PARTIAL) features |= NETIF_F_GSO_PARTIAL; - /* TODO: this should also work with SG, - * rather than hit BUG_ON(i >= nfrags) + /* TODO: this should also work with SG, rather than fail the + * i >= nfrags check in skb_segment() */ if (tcase->id == GSO_TEST_FRAG_LIST_NON_UNIFORM) features &= ~NETIF_F_SG; SKB_GSO_CB(skb)->max_segs = tcase->max_segs; + + if (tcase->err) { + /* the suppression block doesn't run if it can't be set up */ + segs = NULL; + kunit_warning_suppress(test) { + segs = skb_segment(skb, features); + } + KUNIT_EXPECT_EQ(test, PTR_ERR_OR_ZERO(segs), tcase->err); + if (!IS_ERR_OR_NULL(segs)) + kfree_skb_list(segs); + goto free_gso_skb; + } + segs = skb_segment(skb, features); if (IS_ERR(segs)) { KUNIT_FAIL(test, "segs error %pe", segs); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457197.1670164 (Exim 4.92) (envelope-from ) id 1xJWfI-0006Nd-MH; Wed, 21 Oct 2026 13:47:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457197.1670164; Wed, 21 Oct 2026 13: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 1xJWfI-0006NL-F3; Wed, 21 Oct 2026 13:47:36 +0000 Received: by outflank-mailman (input) for mailman id 1457197; Wed, 21 Oct 2026 13:47:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWfG-0005zU-M9 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWfG-00AIKh-1b for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:34 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c26c-e002-0a2a0a5209dd-0a2a4505b806-46 for ; Wed, 21 Oct 2026 15:47:34 +0200 Received: from [74.125.224.42] (helo=mail-yx1-f42.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c275-4cb1-0a2a45050019-4a7de02ae978-3 for ; Wed, 21 Oct 2026 15:47:33 +0200 Received: by mail-yx1-f42.google.com with SMTP id 956f58d0204a3-67489c8202cso627712d50.3 for ; Wed, 21 Oct 2026 06:47:33 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-67a0e5779ddsm1061588d50.20.2026.10.21.06.47.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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: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=1792590452; x=1793195252; 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=l2su03NSLDI+QURR7+Op6WIlpfTiC3EObk5mJFR1rWs=; b=Ov4ZpWZHnDcgAZrqkLwPLI57kM7mivdeBjqemIQ6qVJsWPn833Few8ZL4VsrAqXUdy t0q7MNuaScy9QwHdYz3LTUVnRiqQr5UvwjnTBqvzm+DKLsvqq1ULdTCrVmRvRDuBo1jt sfDAF0cx8WTrQAekwmcvP9dcJBD//O2BCDgj9D/A/Xi5SQ4DadGabk2Iv5egCs9uu7yl HUm9pWPUgU6szR/shRVQSZP3qlrRzaroAgJrrWoPSxL+GSccFOWEJXdFYMVhyDZ+FEsN aLd6H0ktVLKQaSWG0HlE4weAFqt1NxBIv2DT4WChxIOQlnBI+b2bxGt5EzMoDO9pD86Z +y4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590452; x=1793195252; 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=l2su03NSLDI+QURR7+Op6WIlpfTiC3EObk5mJFR1rWs=; b=tJVyhzgLyMGUJiUn6vrb4HOm64rCRfz/D/t0dXqkT2VecSmQqVmnz1nW62Vyh8T34F cI94q50YcbgBgIG1Ztl57hxmdEp9q/PXY2zYHzzzXhv6CxckZ92jsPXooK/pXR/LFMKg vdxw3zWYUeXPfo7Rzy5RJNthUIM4TS/9V+eeCcVtxF90blk8EkU+Kc/xjiV2mmOqeZut kCMc44/PV1ISymqoeUxkmfRY/Etq1rNM0Bbodqt7AtwnUZBqt0pN0OcbhuoklpSPICnY LXdV2WU3ky+q2uhyPiAvbJtlgmxe8aHGLuZTiEF6Cq5gXIZoIlTd+a7zumYL9m2QAayk fGEw== X-Forwarded-Encrypted: i=1; AKwUvBxMy0Os/BrkZHtillkPUL3eBAx6cZfG8hBNi0XfMXdZ7WfeRgRiR2lP4rxx9tudlTTTmnq+u2g84O0=@lists.xenproject.org X-Gm-Message-State: AFq9FYI92mX26ZyvVxALw1gequkaRl5jyitF8TG4cWR8gylIUXPlMJpx 8JbsKayrLn5RlyFHvvSLPbvzo3d3qkZGaYPy5WFsUohsp+Jswh9+k/q3TpJixYliDmI= X-Gm-Gg: AYBFou0EhjIEUJs+00NRrBLOtqb2Zo6trRrg60a2jqc/SD5oLCPo4/cVWTUj/P+0Qp9 66GZbxTXpcvU+Qr9gWABHMvtigNG3YzDAAR8Hq0so1vk1LoMcXxpY4G3j4E4C59NNFk9V2sGBk6 IXpD8Xh3TxUAohFPdjkZoi/f0CCSNVwsjK9v+jsjOKnxZFXBSmh52YOwo41TIzOtfhRotsKXsCA X++pFIrLpCqLuK6ipYlCWqQAbOuz0vEbNFHA6dfxc2qWjxQTo2Z2H2Xh+VPwNhaolK/fck1RFcP YMTlmKCWhkPSG8Dk3V7gSElC9i1K0Lbbjj0nqtii+HV9POgzSZBJazOv4vA+n8Tesq7AXtRgq2l ghilVRuRc7uc2qV8pdYQU+CqXfgmIn9LPWA3jvVzUstOYdJcYViUhjYfDZDpkxySE/+S8582mSx v4qRaxPMnTO5Qq/HReCSi38MemHBCJ9oUyKIU20A4JId5HEPV+t8FWfXoANKlUYMAAYYKebKVxN 0bdgcd/tNjLbB0iYW3zsBQpMByatcWSmwbgxrAHqtunIF5yxwsOGZlrTlqTSeH9ozBwKXSK X-Received: by 2002:a05:690e:1406:b0:679:b98d:9b88 with SMTP id 956f58d0204a3-67a0e0331e3mr1078570d50.3.1792590452506; Wed, 21 Oct 2026 06:47:32 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:57 +0000 Subject: [PATCH net-next v2 13/15] xen-netfront: don't BUG() when skb_copy_bits() fails in bounce_skb() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-13-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590423; l=1219; i=josef@toxicpanda.com; h=from:subject:message-id; bh=9EvzAU9EO5dyvCGQMaA1nd2saqGuALWIDCXk9Xn6dMo=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QAQjp9kFMKs5+2pU2zx7IwIuaWfR/3YW8oytDjzI4+zZ1wUKMLjTsMaA+PjAnDttJOXuOtpmibb u+dc+qRy2bgg= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c201ff/1792590454-722AB2A1-06B00963/0/0 X-purgate-type: clean X-purgate-size: 1221 bounce_skb() is an open-coded skb_copy() for skbs whose data isn't page-aligned, and it has the same BUG_ON(skb_copy_bits()). skb_copy_bits() only fails when the skb's lengths don't add up. bounce_skb() already frees the new skb and returns NULL when the allocation comes back misaligned, and xennet_start_xmit() drops the packet in that case. Take the same path, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels. Assisted-by: LLM Signed-off-by: Josef Bacik --- drivers/net/xen-netfront.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index fdcb91042f29..17811d81937c 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -695,7 +695,12 @@ static struct sk_buff *bounce_skb(const struct sk_buff *skb) /* Set the tail pointer and length */ skb_put(n, skb->len); - BUG_ON(skb_copy_bits(skb, -headerlen, n->head, headerlen + skb->len)); + if (unlikely(skb_copy_bits(skb, -headerlen, n->head, + headerlen + skb->len))) { + DEBUG_NET_WARN_ON_ONCE(1); + kfree_skb(n); + return NULL; + } skb_copy_header(n, skb); return n; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457200.1670171 (Exim 4.92) (envelope-from ) id 1xJWfK-0006fd-Ax; Wed, 21 Oct 2026 13:47:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457200.1670171; Wed, 21 Oct 2026 13:47: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 1xJWfK-0006eQ-1l; Wed, 21 Oct 2026 13:47:38 +0000 Received: by outflank-mailman (input) for mailman id 1457200; Wed, 21 Oct 2026 13:47:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWfJ-0006Sp-7T for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWfI-003fNk-KO for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:36 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c261-8faa-0a2a0a5109dd-0a2a45099ac4-38 for ; Wed, 21 Oct 2026 15:47:36 +0200 Received: from [209.85.128.174] (helo=mail-yw1-f174.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c277-be1a-0a2a45090019-d15580aee532-3 for ; Wed, 21 Oct 2026 15:47:36 +0200 Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-8ac525c1f05so6244377b3.1 for ; Wed, 21 Oct 2026 06:47:36 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.247]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b13010e9afsm11079637b3.30.2026.10.21.06.47.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590455; x=1793195255; 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=i0J3D+b7/r3u1OwRyftYjz/adUeAE/55QZV56gd3GFQ=; b=gwclMz6VXUz5jjTLEsnsU3gq/6bGHGymqp1kZSUZBe9/pkaUpkdWxeyql3v4at2IK7 M9Pdf5Vxup7zkuWWpQYlec3ILhV4dLrFc5nsYcoEvdhyPHKRmPx8HqM+R2sKhg/8wWWn 7Rj/79zpWiinN+XutztjleNKy6eOVw4eaxJrqVr6lbGNv/R9n8YCcrinoT7kz7xKSmhW f7hL6DEDM0jANrD3xGVqokHx0RrqVsMGm5zQG0CIAhzv9vxCtVJ5i5TBqh81zZaD0wkq P9TDXYcnDCh7HqRpTwPmBvKA2HaYfnVz545I3Wfigz7bfiyYiI2gOItaXZPFe8TUergc a3ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590455; x=1793195255; 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=i0J3D+b7/r3u1OwRyftYjz/adUeAE/55QZV56gd3GFQ=; b=2u4E7IZQ2i/yUC4fXTJyP/U+2EPksqjoDqaCQHG1fl+MbynP/RSpBTqJOJaCFZr+Nz /XptU+6GvFfuiGPon6Bw+28d0mK7wzkksg4xEWofMq4PT0KeiX/q27x18lakQ+550WSe fpnGXDxhhqS5VGmgfdNPtvvqJmzs7nScbZHhs0IeaMS83rlcQG/KKhBMAOs0eCb9Xa9U Zz3HmClOh/ZxgZUthN0+83c0RGtiTgqTf1PchbuoF6MivcGpYNQmQUYkzxB5zcD+WEWQ P4Hoy/zJyK8V8aqiiwom1flxGJbxJQtAdEsJrJp46lUDYlsFEjvauAjJmmKyjegtOeq2 j4DA== X-Forwarded-Encrypted: i=1; AKwUvBzKULM63nLBCiIfGj2DJY8k5gRk1GqQrLOt0UCJi4QhX9a2yJAOlATwR5y7YMnShV41ggIwfIzNhDw=@lists.xenproject.org X-Gm-Message-State: AFq9FYL1pzAnEKzQdn7N+MQLzCtYiXHvfj4t9mkVj3AzQKgEf6Ngljnp +jY1NfT6qLu0l1O7OaNhPXrQNKUzIohwWVULudNW8ljKCD3aUNqxlhcpNZmiB5dZ580= X-Gm-Gg: AYBFou0tXQgYYgelGN5AIwwnXjqba2kmRpCxCSnQtZXcskQoBJ5Cb1MTt8PTs/a5gLE UtUzDxYO3+GoxF/6wwji7oX2HaANktPnbPzKDeXVkhRHJSGnMc8U9g2z4KvD1xe55QVHvaM1e7C lP6PkLMIhmhX97nf68hvDplRrwnRI2g8Lp4coal6uLLou2UGr3SrbCHUHF4Hth9Bmy59ZJej87p l2F8A/0pG/DfOT8y5n40bsQH5Bp/lIPnFGMkSbqfAy/2T1NfReKfcjG6ggeWa1XTCR8jxW3Ui8U u0jmUak7fYk697PcgjoISS0sXplN7mQTRUK8GjLwtAE5Pusk0BjTk9SmL6nL/ZD2OF0UKCe2dcc ZDTMuSyIsKiX20SMpeH03ZReTEraxzQVXZKkOL3sgXMd0AfuBYgqFgObAowZczDj591/PJ26Krf Kanv7Mnd7dDF9YBVI76HtDYbZKJ6SuF4nCBUZkk1M94Hl/sb7ANKgP0uCmpywxORXu2jmxnSjRa bDy8UrbiOUURuf1Ta95m3rw0ZDZUh8NRob7aUlCyGivH1ZBJxf0GLQwqxPqYKM1HBBYx5Ruw7w+ JbKi4xjpwYNfsOeHXiw= X-Received: by 2002:a05:690c:6e84:b0:8b0:d9c9:3fc6 with SMTP id 00721157ae682-8b133cab002mr11832947b3.13.1792590455037; Wed, 21 Oct 2026 06:47:35 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:58 +0000 Subject: [PATCH net-next v2 14/15] net/tls: don't BUG() on leftover length in __skb_nsg() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-14-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590424; l=1223; i=josef@toxicpanda.com; h=from:subject:message-id; bh=5t4cbRJHSGQYLLp/0ImHHFowlzs4pEzQ4N7rNchrePQ=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QEgLrOmYkZSVdXm9PAivGpLFnrgKNrg9SpPHyFwsg+XmCzRKGvvpRNTQOmmSS2AzD9Qw0WBfByj Oucz9Cz9YYwA= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1792590456-39AC0034-E93962E3/0/0 X-purgate-type: clean X-purgate-size: 1225 __skb_nsg() counts the scatterlist entries for a range of an skb with a copy of the __skb_to_sgvec() walk, including its BUG_ON(len) when the skb runs out before the range does. tls_decrypt_sg() calls it on the same range it then passes to skb_to_sgvec(), so a bad range would BUG() here before it got to skb_to_sgvec()'s error return. __skb_nsg() already returns -EMSGSIZE for a frag_list nested too deep, and tls_decrypt_sg() fails the record on any return below 1. Return -EINVAL for the leftover length too, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels. Acked-by: Mina Almasry Assisted-by: LLM Signed-off-by: Josef Bacik --- net/tls/tls_sw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 312e51270f29..1c578ea47a1b 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -142,7 +142,10 @@ static int __skb_nsg(struct sk_buff *skb, int offset, int len, start = end; } } - BUG_ON(len); + if (unlikely(len)) { + DEBUG_NET_WARN_ON_ONCE(1); + return -EINVAL; + } return elt; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 13:47:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 13:47:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457202.1670181 (Exim 4.92) (envelope-from ) id 1xJWfM-00078k-MB; Wed, 21 Oct 2026 13:47:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457202.1670181; Wed, 21 Oct 2026 13:47: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 1xJWfM-00077u-Ec; Wed, 21 Oct 2026 13:47:40 +0000 Received: by outflank-mailman (input) for mailman id 1457202; Wed, 21 Oct 2026 13:47:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWfL-0006uW-At for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 13:47:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJWfK-003fNk-Nq for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:47:38 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8c26e-8faa-0a2a0a5109dd-0a2a4504b266-42 for ; Wed, 21 Oct 2026 15:47:38 +0200 Received: from [209.85.128.179] (helo=mail-yw1-f179.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8c279-b57f-0a2a45040019-d15580b3d81e-3 for ; Wed, 21 Oct 2026 15:47:38 +0200 Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-8b05bf699easo7006147b3.2 for ; Wed, 21 Oct 2026 06:47:38 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.250]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b13018e0d1sm11045597b3.41.2026.10.21.06.47.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 06:47: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=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=1792590457; x=1793195257; 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=B3Vx6nCjfDKI1O0Rv8fJf2F45AGRs7XGpGz0epefQ+g=; b=K13mRVOBoZI+RKB8CEOjTZw669BjWZDcjcgz8GoevtOcCMYs7N2PVmEFj5Z9oQj9LZ Vfq+6wG/qhRTyg0TD6Pr8zdtIMKCDiSvmprhg2qVo9CHSSO0d6oi3VGIgVUoG7H4NrI0 MfiUriHoKN54+oy+/FBXc2sSWnyNHfAKjWoY1SW3KXW9gQ4p+AmcRI2BlUGWUggN/L/c RusgnaNT+QssUKMsIdoN2IdebzefN40Bkf0bPGJ1yUO3p1wn9ZMCSHDhNJbCEIOIP+DE xVvEJ6YrvFgl6ns+2U/7arhrPpym0JHuWlpaVSTgY5NwcHGfTPfisZ1hrcoI4DQWAVl0 860Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792590457; x=1793195257; 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=B3Vx6nCjfDKI1O0Rv8fJf2F45AGRs7XGpGz0epefQ+g=; b=sOSTDrCTXNVj5D6UZWS4YYVADI65aWDGnP/8BxVBskbDXV46Sb488crL63eRJQMOXt 2C8FKbTDSxl25XJDwrT5csFrQfGvSBB0ubJOymeCVH2vQtRhju7JsGWEw4F2u8AlP7Sw eo+VHFEA79uBxUJ8APIUOz5hSciDkgbLV7UXmy1zlI1B0utU7XRkSAgTfBzlC02PUNm4 npr4Kyc9uZOuCgsk1O0kSkEXMOXq9FyuhCDfO6vTy2ppsIEu5udLkF2OKzk5wgJiH445 HCWe6xm6uBqq4aHQkSqGM7GnrIqgRoXrvcWvgRDT54d2cwLVKGsfAvjhBJh1FoYH90Ul XwFw== X-Forwarded-Encrypted: i=1; AKwUvBz50tF9DhcsSVhfh9teC5Vyni0jXWnUkqceVbuU75eTOZFwptA7u+DNf/z7T67Brcf2X539X2Pt5o4=@lists.xenproject.org X-Gm-Message-State: AFq9FYIj0DaCoyntvNAR3t9HCKUNaX/PSmwueQ9MyAm4lXBpChGFTKlD JbYR3wZgnj3amaZxqIYPBhxiL0/Ga34FgeJf26rLWc/b8op+E9luWcbliMC5keyoaOc= X-Gm-Gg: AYBFou04E/UBB1UOVv5ftd+eS25pdskoPsXX6bd2+9fRCMUZ1RohK8pMmdGjlr30idt iuEpb7WSa1mgBQ40KMQfjzBZTH0lrJmFfFMZnb89yeDmDH33Qh+3Qjl07qa/yHtWTFkHkG2rUfj LAfBsxPIhEyCXPh1OUOgMqy3TfXizcHNvfjRgzrX7h2zk18MjOWDCDnKNo5XqPl/kPdr2xVDN5K w3irgFtxU2gBGkMHNmFbn+DPipkWqd/wGTK9ePQtL7UXj6iYDRTanu0Tj8jAJsmnvrSN76xCl1S xxZtc6uVZEjUIrs8sRs3JdjUVgZuHPmGqsHDfGozN1zEpMfITv+Z0NhF2r6l5wMfUSfiRAq210C 8G3YnCUF19n3m1RS9U6Jrnmq5xOsLl1vjUrvlZ9NOBqB7PKPhdjOu/c2evmnESdyaqe/sQtfDmw zKRyWYuvQJe+nH9hVeMUgRdRjkht6kMihQuEoYFHAJjDt5r+pTDH2PJYJ9l531c5MQ2dJQWzVRD s6XKfxiC1dQa00SP4Y6K1SvSObn8TA/9JgqbOsU8oRhAyoiEYZDdSGYm++wlqyGcV2hx7kH X-Received: by 2002:a05:690c:4:b0:873:5c6b:a314 with SMTP id 00721157ae682-8b134389b4dmr10867637b3.66.1792590457017; Wed, 21 Oct 2026 06:47:37 -0700 (PDT) From: Josef Bacik Date: Wed, 21 Oct 2026 13:46:59 +0000 Subject: [PATCH net-next v2 15/15] net: update comments that still describe the skb BUG_ON()s MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261021-b4-skbuff-bug-on-followups-v2-15-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1792590424; l=2172; i=josef@toxicpanda.com; h=from:subject:message-id; bh=MDGe2ZQJ+rI3P7PzLeUdDmFI72t2b7q58f2qUsQ4Bag=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QBAD74Tlz2UL8T7L2mQyY7NisozlhPe3QQxIgCRdFLU8kx33xd6A5QYzW2kATM5/cjWZtxWiPe3 SKnGmgkQI4gA= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1792590458-C36C2B50-ECE6C033/0/0 X-purgate-type: clean X-purgate-size: 2174 The skbuff BUG_ON() conversions left a few comments behind: - bpf_skb_net_grow() says skb_segment() BUG()s on a frag_list with head_frag set at the downgraded MSS. It fails the segmentation and the packet is dropped, which is still why the skb gets linearized. - The skb_to_sgvec() kernel-doc doesn't list the -EINVAL that __skb_to_sgvec() returns when @offset and @len run past the end of the skb. No functional change. Acked-by: Mina Almasry Assisted-by: LLM Signed-off-by: Josef Bacik --- net/core/filter.c | 6 +++--- net/core/skbuff.c | 5 +++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 3ee1a093337e..f5bce0dc43fe 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -3696,9 +3696,9 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32 off, u32 len_diff, shinfo->gso_segs = 0; /* Due to header growth, MSS needs to be downgraded. - * There is a BUG_ON() when segmenting the frag_list with - * head_frag true, so linearize the skb after downgrading - * the MSS. + * Segmenting a frag_list with head_frag true at the new MSS + * fails and the packet gets dropped, so linearize the skb + * after downgrading the MSS. */ if (!(flags & BPF_F_ADJ_ROOM_FIXED_GSO)) { skb_decrease_gso_size(shinfo, len_diff); diff --git a/net/core/skbuff.c b/net/core/skbuff.c index c5e28a52114b..e0c8f2f6bfac 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -5551,8 +5551,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len, * * Fill the specified scatter-gather list with mappings/pointers into a * region of the buffer space attached to a socket buffer. Returns either - * the number of scatterlist items used, or -EMSGSIZE if the contents - * could not fit. + * the number of scatterlist items used, -EMSGSIZE if the contents + * could not fit, or -EINVAL if @offset and @len run past the end of + * the skb. */ int skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 21 14:02:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 14:02:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457283.1670190 (Exim 4.92) (envelope-from ) id 1xJWu2-0005uX-UV; Wed, 21 Oct 2026 14:02:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457283.1670190; Wed, 21 Oct 2026 14:02: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 1xJWu2-0005uQ-Rq; Wed, 21 Oct 2026 14:02:50 +0000 Received: by outflank-mailman (input) for mailman id 1457283; Wed, 21 Oct 2026 14:02:49 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJWu1-0005uK-Ce for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 14:02:49 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xJWu1-00000005aPq-1UJz; Wed, 21 Oct 2026 14:02:49 +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.98.2) (envelope-from ) id 1xJWu0-00000003eQ5-43fA; Wed, 21 Oct 2026 14:02: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" 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=/paedUJtUfe1GU0V4D9BXctReHAWlvWbxprmJFB3qqQ=; b=c/agvLJWj8W0scKf93UtipV/ij pmZgCw+T4GsqIbF/DlTJmoyRASLe8Dyf5VoaiRt76xCpYEbkvDGR0MkgwNqZ9k7A15Co2T+Qnasbk Pzdz/OuM49At8IGT8l/0ndgIzIkVAOnDTJDQdT8bBtBKnZWvSSXIvS1GYm9DUdy1GZpg=; Date: Wed, 21 Oct 2026 16:02:46 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ross Lagerwall Cc: Stefano Stabellini , xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: [PATCH] xen/x86/hvm: Propagate emulated CR2 writes to the VMCB Message-ID: References: <20261020213315.3641133-1-stefano.stabellini@amd.com> <26141f92-f6cf-459d-ae56-e010db9062db@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26141f92-f6cf-459d-ae56-e010db9062db@citrix.com> On Wed, Oct 21, 2026 at 02:11:30PM +0100, Ross Lagerwall wrote: > On 10/21/26 9:19 AM, Roger Pau Monné wrote: > > On Tue, Oct 20, 2026 at 02:33:15PM -0700, Stefano Stabellini wrote: > > > hvmemul_write_cr() updates guest_cr[2] but, unlike every other writer of > > > it, doesn't call hvm_update_guest_cr(). On SVM, CR2 is loaded from > > > the VMCB, so the emulated write never reaches the guest, and the next > > > VMExit overwrites guest_cr[2] with the stale VMCB value. > > > > > > Signed-off-by: Stefano Stabellini > > > > Acked-by: Roger Pau Monné > > > > I wonder whether there's more missing here, see below. > > > > > --- > > > xen/arch/x86/hvm/emulate.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c > > > index c09ea002ec..cd2831d34b 100644 > > > --- a/xen/arch/x86/hvm/emulate.c > > > +++ b/xen/arch/x86/hvm/emulate.c > > > @@ -2350,6 +2350,7 @@ static int cf_check hvmemul_write_cr( > > > case 2: > > > curr->arch.hvm.guest_cr[2] = val; > > > + hvm_update_guest_cr(curr, 2); > > > > Looking at hvm_update_cr(), is this possibly also missing a call to > > nestedhvm_set_cr()? > > AFAIK the values set by nestedhvm_set_cr() are not used at all with nested SVM > and from a brief look may only be used for CR0 and CR4 for VVMX. So maybe it is > not needed, though for consistency I think it would make sense to replace both > lines with a single call to hvm_update_cr(). Yes, however at the time being hvm_update_cr() is static to hvm.c. It would mean exporting the function, which maybe we should have done in the first place instead of exporting hvm_update_guest_cr()? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 21 14:56:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 14:56:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457350.1670199 (Exim 4.92) (envelope-from ) id 1xJXkB-0005jv-Sb; Wed, 21 Oct 2026 14:56:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457350.1670199; Wed, 21 Oct 2026 14: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 1xJXkB-0005jo-PK; Wed, 21 Oct 2026 14:56:43 +0000 Received: by outflank-mailman (input) for mailman id 1457350; Wed, 21 Oct 2026 14:56:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJXkA-0005jh-1h for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 14:56:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJXk9-008F3n-4D for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 16:56:41 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8d29c-bab6-0a2a0a5309dd-0a2a4508e8dc-28 for ; Wed, 21 Oct 2026 16:56:40 +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 6ad8d2a8-f659-0a2a45080019-b9ff1c1294ab-3 for ; Wed, 21 Oct 2026 16:56: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a15ef6d2f2000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 21 Oct 2026 14:56:36 +0000 Received: from [10.20.30.14] (96.17.23.93.rev.sfr.net [93.23.17.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id F08A981B4E; Wed, 21 Oct 2026 16:56:34 +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=QG7CxMo79XdFLeBVjvq0bf/F7Gbu6SHO6G+wD6sSU/I=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=gZNbX/+XSaRg+0grRQbuDvSRpMPO4nKTvcgcEFcJ+5XP9kchUbdhHe6TphhB05ktVjU7m0xDs AigCnnzO4Fy594luCkV4BHo46Y1METsPwCNKFCqq3eVd4Gd4jb6v6qI+oAyRo2zfxRcggbmSkX0 HOAGaH22c5qU6KhZcNu1SgPjmW8k4cnHlpZZDxUTEcLnwIUhMlFewPKvZmFGbl+FmoLpMj9c1Tl dCuTIuBXSHpWjFpfnPZ41Q9CrJIavQVDDLQ8ruzKH6Y9PWcXzaM+v0uYshUpou5vZSza65JObtZ erQgzWw3MjHYvegvT6/9Q/ZJIyH7Gt0B06LWkK96/QUg== X-Zone-Loop: db75927cdf7a1d71d08b9ef3862c40865013e82188a6 x-campaign-type: default x-transaction-id: 0372d9b9-e215-4292-995a-48b1e1903084 x-swg-uid: 01-8571917c-262c-4dea-bdd9-9635a9cbcad2 X-Mailer: Sweego Message-ID: <1792594596.8631fc262581453bbf619ec5b2062170.1a15ef6d2f2000f79f@vates.tech> x-swg-bid: 1792594596.8631fc262581453bbf619ec5b2062170.1a15ef6d2f2000f79f 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 v3 21/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, 21 Oct 2026 16:56:27 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792594589; l=2947; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=onPY+Nraq24eEHQYOmZiZkdricPO/2ZbnGcQEqb+qPs=; b=50Jb8nuflVrP/UOgIqIJzW31BV1/OXxizeG28oaQotXkZ2v3s/38Qo3zL0F0KseY8LnlWrLo0 S61qaTj5JonD9QI1MEpTVC3W9Z8qMcfTk2qsEXA/yyqnvgpaDPayDtH 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: 1792594595758 X-purgate-ID: tlsNG-c1860d/1792594600-D497287B-17F96C4A/0/0 X-purgate-type: clean X-purgate-size: 2947 > [ ... 75 lines skipped ... ] > +/* > + * 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. > + * 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. > + * > + * 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. It must therefore only be called > + * while handling a trap taken from that vCPU, never from a nested trap > + * taken in HS-mode, which may have interrupted Xen at a point where > + * hstatus, vsatp or hgatp don't belong to the 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. > + */ Shouldn't docstring belong to header file? > +unsigned long 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. > + */ > + if ( read_insn ) > + { > + asm volatile ( "\n" > + "1: hlvx.hu %[val], (%[addr])\n" > + ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti]) > + " andi %[tmp], %[val], 3\n" > + " addi %[tmp], %[tmp], -3\n" > + " bnez %[tmp], 3f\n" > + " addi %[addr], %[addr], 2\n" Could you add a short comment explaining that the andi/addi/bnez sequence checks the low two bits of the first halfword to tell a compressed instruction from a 32-bit one? It is not obvious on first read. Something like: ``` /* * bits[1:0] != 0b11: 16-bit (compressed) instruction, nothing more * to read. */ ``` -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 21 15:11:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 15:11:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457370.1670212 (Exim 4.92) (envelope-from ) id 1xJXyC-0000OF-47; Wed, 21 Oct 2026 15:11:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457370.1670212; Wed, 21 Oct 2026 15:11: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 1xJXyC-0000O8-17; Wed, 21 Oct 2026 15:11:12 +0000 Received: by outflank-mailman (input) for mailman id 1457370; Wed, 21 Oct 2026 15:11:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJXyA-0000O2-IV for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:11:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJXy9-00AWwo-VS for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 17:11:09 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8d5fe-2eae-0a2a0a5409dd-0a2a450bcd6c-48 for ; Wed, 21 Oct 2026 17:11:09 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8d60d-b7e8-0a2a450b0019-b9ff1c2399bd-3 for ; Wed, 21 Oct 2026 17:11: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 1a15f041119000f79f.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 21 Oct 2026 15:11:04 +0000 Received: from [10.20.30.14] (96.17.23.93.rev.sfr.net [93.23.17.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id B366282B0A for ; Wed, 21 Oct 2026 17:11: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: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=D48FjnwJuDkN6Z74EgIO9fvChiy+NcJdceSkrU+Lh+o=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Aj9Jj1DBWjRrWpxAsrv+4lPx3j+9KX6KUpMJYpAUV4g8LetIjOR57MUP+lrdAM2HDntmEyAum cbAr/8ABMZkHVL9uwoQFmQ50vMslODc1N+evipgMAMq2kQNmSRzFIbG0U80Vl2IN/yAzpqtJHjK qtRG2Gdta2fNgqtn/7Rhv4zaxSc+qfpYbO6zcBFaJwRZbfuGgEV9pbk9nYZLxWX2bvqoXFJU9Fg QASS32IdFrM6amcMa75NVI1dZnrUFOab7oXwRhFg8Gb6B5k4It3LgM+ZSIyIkAvyNOzUJBGiYuf Yn7c9UCjCZrE9kiiAMtiJlqgYjd14CoDjJsnXjEtVgRg== X-Zone-Loop: 5800d4e80a71dd1f2844c9fb6fa948750221ca5a90a4 x-campaign-type: default x-transaction-id: d3efb3e5-34b8-48c0-a7f3-0b78fb3da42c x-swg-uid: 01-91f8fd51-8a08-404f-a2a6-326270e52fbb X-Mailer: Sweego Message-ID: <1792595464.8631fc262581453bbf619ec5b2062170.1a15f041119000f79f@vates.tech> x-swg-bid: 1792595464.8631fc262581453bbf619ec5b2062170.1a15f041119000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 21 Oct 2026 17:11:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 21/39] xen/riscv: add guest memory read helper To: xen-devel@lists.xenproject.org References: 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: 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: 1792595463848 X-purgate-ID: tlsNG-42698a/1792595469-AB4D39EA-505EE37C/0/0 X-purgate-type: clean X-purgate-size: 2030 Sorry I forgot one thing.> +unsigned long 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. > + */ > + if ( read_insn ) > + { > + asm volatile ( "\n" I think this would need asm_inline instead...> + "1: hlvx.hu %[val], (%[addr])\n" > + ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti]) > + " andi %[tmp], %[val], 3\n" > + " addi %[tmp], %[tmp], -3\n" > + " bnez %[tmp], 3f\n" > + " addi %[addr], %[addr], 2\n" > + "\n" > + "2: hlvx.hu %[tmp], (%[addr])\n" > + ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti]) > + " slli %[tmp], %[tmp], 16\n" > + " or %[val], %[val], %[tmp]\n" > + "3:\n" > + : [val] "+&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr), > + "+m" (*trap) > + : [ti] "r" (trap) ); > + > + /* > + * Although HLVX instructions' explicit memory accesses require execute > + * permissions, they still raise the same exceptions as other load > + * instructions, rather than raising fetch exceptions instead. > + */ > + if ( trap->scause == CAUSE_LOAD_PAGE_FAULT ) > + trap->scause = CAUSE_FETCH_PAGE_FAULT; > + } > + else > + { > + asm volatile ( "\n" ... same for here. From xen-devel-bounces@lists.xenproject.org Wed Oct 21 15:28:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 15:28:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457396.1670222 (Exim 4.92) (envelope-from ) id 1xJYEw-0002dP-J0; Wed, 21 Oct 2026 15:28:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457396.1670222; Wed, 21 Oct 2026 15: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 1xJYEw-0002dI-F1; Wed, 21 Oct 2026 15:28:30 +0000 Received: by outflank-mailman (input) for mailman id 1457396; Wed, 21 Oct 2026 15:28:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJYEu-0002dC-TB for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:28:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJYEu-008K71-6H for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 17:28:28 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8da18-bab6-0a2a0a5309dd-0a2a4501d296-10 for ; Wed, 21 Oct 2026 17:28:28 +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 6ad8da1b-5984-0a2a45010019-b9ff1c2380f9-3 for ; Wed, 21 Oct 2026 17:28: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 1a15f13e684000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 21 Oct 2026 15:28:22 +0000 Received: from [10.20.30.14] (96.17.23.93.rev.sfr.net [93.23.17.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id F059081B4E; Wed, 21 Oct 2026 17:28: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=3+TQ8qKxqQn1nSOE8UMcaep+7BnIWihCjmR34n3eEAA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=pJuyfrijAeA/p0GEpWeQTjmp/FrU1S5WkdfyCWtWXkppMiC9b5ZyR7w7NlSa9rWcjTQ1G9uO7 te0KeqTsJGlNR14dd8+kGUNTvcTJfAJ38tw0r/gypBABlTnWK/uMkYLMONIuvGG2jGSGSkWQCls SIm5u69sPZ42XX823KZMWvaUnT9OSwkvfSLoI0RL8EUj7QA6Ice3ljokLabDiOAZKZcbIRRsARg 6UvfxpRbw6ILWPsPogpERZBE4yn+dxDOTvc23X4yhJvWggva0KkdwNEADyaHP203btuxNBj606D vzuzQ598BQdW13DkwwgfL3tCw33nx9gciovsqYSRUFqA== X-Zone-Loop: b26f5b197cefdf3e3771f9de9b8a06e0df6a91bfc620 x-campaign-type: default x-transaction-id: bcb8e75c-d0e3-4ae1-abe6-46198fc245ca x-swg-uid: 01-226afb13-b523-4413-a320-1ea09d50f5b3 X-Mailer: Sweego Message-ID: <1792596502.8631fc262581453bbf619ec5b2062170.1a15f13e684000f79f@vates.tech> x-swg-bid: 1792596502.8631fc262581453bbf619ec5b2062170.1a15f13e684000f79f 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 v3 22/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: <4e2b4e7a99f4d2133ff92559303d19382749de7a.1790779209.git.oleksii.kurochko@gmail.com> References: <4e2b4e7a99f4d2133ff92559303d19382749de7a.1790779209.git.oleksii.kurochko@gmail.com> Date: Wed, 21 Oct 2026 17:28:13 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792596495; l=2987; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=fFj8o3LS+yiIGjyLnD0AbZNQbRANFSl4YRScMss7Ra0=; b=sGlMp1H8yyiTm6053VjnJUvJ5jQSrkUgfdS8BAVQoh3JNpUqWASJGnKd9/pxc42TDLA7PRFeJ pa5lzHWpSD3BoFeZnb7B3hjYjZbTZZJ2tESeXSlA23o9BzZxJ+C9UHv 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: 1792596501500 X-purgate-ID: tlsNG-d62444/1792596508-C5341757-2ADE4651/0/0 X-purgate-type: clean X-purgate-size: 2987 > 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: > This reads a bit confusingly: the colon makes the bullets look like the conditions under which the lookup is done, yet the first one starts with "a trap taken from the guest". Maybe state up front that the bullets are the excluded cases, e.g.: ``` Move the lookup ahead of the cause switch, and only do it for exceptions taken in Xen context. Both other cases must skip it: - Traps taken from the guest: sepc is then a guest address, which the guest can make equal to an address listed in the exception table. ... - Interrupts: an interrupt taken at an address listed in the table would be "fixed up" as if the access itself had faulted, ... ``` > [ ... 40 lines skipped ... ] > @@ -196,11 +196,34 @@ void do_trap(struct cpu_user_regs *cpu_regs) > unsigned long cause = csr_read(CSR_SCAUSE); > bool from_guest = cpu_regs->hstatus & HSTATUS_SPV; > > + /* > + * A synchronous trap taken in Xen context may come from an access done on > + * a vCPU's behalf, e.g. the hlv/hlvx sequences in read_guest(), > + * or from a probing access like csr_read_safe(). Both are covered by > + * exception table entries which record the fault details for the caller > + * and resume execution past the faulting instruction. > + * > + * Traps taken from the guest must never be fixed up: sepc is then a guest > + * address, which the guest could point at an address listed in the > + * exception table, making Xen act on an entry (and, for EX_TYPE_TRAP_INFO, > + * write through a pointer) fully under guest control. > + * > + * Interrupts must be excluded too: one taken at an address which happens > + * to be listed in the exception table would otherwise be "fixed up" as if > + * the access itself had faulted, silently skipping it. > + * > + * Returning early skips check_for_pcpu_work() below, which is correct: > + * that only runs for traps taken from the guest. > + */ > + if ( !from_guest && !(cause & CAUSE_IRQ_FLAG) && > + fixup_exception(cpu_regs, cause) ) > + return; > + > switch ( cause ) > { > case CAUSE_VIRTUAL_SUPERVISOR_ECALL: > /* CAUSE_VIRTUAL_SUPERVISOR_ECALL should come from VS-mode */ > - BUG_ON(!(cpu_regs->hstatus & HSTATUS_SPV)); > + BUG_ON(!from_guest); Does this hunk really belong to this patch? It seems it belongs to previous patch where you introduced the local `from_guest`. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 21 15:29:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 15:29:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457402.1670231 (Exim 4.92) (envelope-from ) id 1xJYFj-00035y-SR; Wed, 21 Oct 2026 15:29:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457402.1670231; Wed, 21 Oct 2026 15:29: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 1xJYFj-00035r-Ne; Wed, 21 Oct 2026 15:29:19 +0000 Received: by outflank-mailman (input) for mailman id 1457402; Wed, 21 Oct 2026 15:29:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJYFi-00035f-AV for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 15:29:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJYFh-006Nhs-KH for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 17:29:17 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8da41-2eae-0a2a0a5409dd-0a2a450b819a-18 for ; Wed, 21 Oct 2026 17:29:17 +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 6ad8da4b-b7e8-0a2a450b0019-94a39744aab8-3 for ; Wed, 21 Oct 2026 17:29:16 +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 69LEGuTC2154049; Wed, 21 Oct 2026 08:29:03 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021116.outbound.protection.outlook.com [40.93.194.116]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4hdw5rd96g-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 21 Oct 2026 08:29:03 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by DM6PR02MB6810.namprd02.prod.outlook.com (2603:10b6:5:214::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Wed, 21 Oct 2026 15:28: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%4]) with mapi id 15.21.0546.012; Wed, 21 Oct 2026 15:28: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=EyzUt4miw1h9iwxpYHYX+NSr9Iq8fmPl3drzE+roD tE=; b=0NlzqJF5ehxPK1CsCSkDaPmga0YuhTX/KXH53n8GyVzpEYj/kQpfmfezi fQG2PJ2PfMnuy0+r6VFiEV5ET2j9WFN8xenxKkufjRBgJP487X0LJftvC2his1a+ dW5S0lWKWcjLMnxlH0MrYvZVY9KFbPAWDHxRk7wMYoyZUQ92jr5UFtt6l0uQtKyn EX+3vFs32RTeLi1leMd2zZhfXIAO4vmUeHMz/heCTtx04lZYOI48K/4dJ0hj+Y6z U+Yvgtn7/XOaYw3uzxtkpQEelig2WEY0P7G0P705Xc7nvJXs5HT80mVLnBWF+A9+ PKcdkgEztLBMDBOvIf/6S9Q5rfIiw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tT9g8PfMCFwuvZ09YAElu71QHrCvdHleJLjQkSeJ0E89zb8ElSUoghmyB/JK5779u3D8G/IeGSl9ZGmLo2r/Xgup3d4+GwECCQ79aK7kf/wCN8JGO7VS/IWGcDWMHjP63u5cBxuKqr8Vuxlw5hxSseSBQ6WpVZfUzYibt/ifRjV4w6xPT+YSUfW6phqaAbLHxwZaktW9gNpgjJH4bBl1o4UhxmoHBTdNAoR1qLhmfmUdK1dlC+skiMn6ntEYtnkTYOiBVTkRY9vfuEWGvb2ONs/vzoWEoi+HZgtAuO9P7WogH7sRygrrDSErGlFZfbCXac3ROGf0UtzA2OdNis0vkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EyzUt4miw1h9iwxpYHYX+NSr9Iq8fmPl3drzE+roDtE=; b=RySvdUL9oubRV8U7I6MngqIUneb4dEjUU70MBR/vU+hotRtRtDGXAE9bQpljwt7C3zrNdMGjwlmPuPwPevQGhXGO+vgSrv0hHpJdw1T1fBkfGJQeNKYG9wtzvnJUOKsD2cqE81/3ImlzrP7HQmbWeuPcv1d1PciLpDlYJdPA1FWK0XVqkHIqB/6pp8puj1NUTD3OXEDiOyYe9+jnDxw1abIzKTunzpRcxVLQL5wh6Lddy3jLfIgimUPxfFBlfSTWhFwPDwakmlII4HZotVei8ucreEiuQAFbkomzEQlL0WL8XIXXZG7PiTpHxg28rCGAiEADjwUtOOFFeFzJ8C5pUQ== 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=EyzUt4miw1h9iwxpYHYX+NSr9Iq8fmPl3drzE+roDtE=; b=K0k2dUIKMB38WOFiWeo2+1nDKTqetulQuAAMdl96jNP8WAHVrUwZGS0y2eR0P46uEI3XI/2DeyqsLXq3C6yauqPrNdkLqOKTqZnQPS6h21Os8X6tzzwjKUVV95jDqg+deg5mJ35NWVTl4OCXEH7QCoBkZLPHjyJTqnrDzj4GS+fkfKsUUJZe29vN146Onsr4xyYi+xP7s6dafkBMzIMT0k2IvxYVTRXHLhr9LlRlNloNQ69LlJC/vsQq6E4+V/gHjFVhj5goBFnaTOPJgl+Yxe3ioFNFtxCUh1Ivl2vJKIl43OeR7ToL8gUA+bug8fkTZSEmUgpYsTIhTNlhOA6s9A== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: <3148a8e1-8f5a-4773-a4d1-4aa5a5465531@nutanix.com> Date: Wed, 21 Oct 2026 16:28:47 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 22/28] xen-hvm.c: rename xen_interrupt_controller_init() to xen_i8259_init() To: Bernhard Beschow , qemu-devel@nongnu.org, pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, xen-devel@lists.xenproject.org References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> <20261019120517.1448687-23-mark.caveayland@nutanix.com> <22FB9414-4D72-4699-9FB4-107D9DF10F28@gmail.com> Content-Language: en-US From: Mark Cave-Ayland In-Reply-To: <22FB9414-4D72-4699-9FB4-107D9DF10F28@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY3PR04CA0015.namprd04.prod.outlook.com (2603:10b6:a03:217::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_|DM6PR02MB6810:EE_ X-MS-Office365-Filtering-Correlation-Id: 3631a320-405f-4c14-de7e-08df2f880306 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|261009223027099003|56012099006|4143699003|22082099003|18002099003|10067099003|6133799003; X-Microsoft-Antispam-Message-Info: QDuAtallgV8IK0HlyXoqwawdrE/5P7AEOqjz9yLFkfzr5DKu+eE/l7+gKW03kAGvs4Pn3PkPmCW7CRlSf838OYKH/CWaK1lhbnTjeUL8Tcj33/m2FGNDivlQ4SDl7W2hYrsecf++rfje0NsrP8Xutgmtia/J3eQxHM4GXxD1y4EiIyvvUW628j3OnuNT1AMwlvsbiORXJyWHpuocCiZhrKzImmpyCSdKNyDVdmVkequLF15JZHEiRGufKq65yh4QM7Vpmfm91l7yERPqXCP/fMZv4Wo8LAf+cHNzXa9j5IN9t0vSl4oZkOaf+XRRK9sc1vHtU31FtfsszWh9PORtCpbrcmDke21jPPj7jtZLv3vM4OMzLjSh6S0ulFUUS9VtGKJ7zyywULou2iuuA84Dnn8ur/zjNWq36jpU+cUsZ/eOqf856o9fAv0r/sBbnup+Zirn0QbSXRQy9if3+PbHBzN6OzZ581GFjFkL/wBb7OTaYazZaTBYHpSVYB17R0pxU6yyR8OACzghG/KPyHDw5pEucZDJZtFObFlympEf2ey/WQf2+rz8Drnip74IVuEDj76srl0BDSjNfeigbd88i449wEq0jDr0M14MHzv+Xv39FE9PehjWLONgQCd0MCwoHC9sD9Lcv7v6nfuzFQEFVqWWmRa48XMZuquuwOG9jXg= 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)(376014)(23010399003)(261009223027099003)(56012099006)(4143699003)(22082099003)(18002099003)(10067099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d1QrMjJGaHF5Y2dWVlBWYm9kbnUzZUlwQ2l3NzM0MU5yNkVWbng1MWFZeDE2?= =?utf-8?B?K09WT0ZRVW5NOWs0MVMyS2prYm5jcXArZkprVCs5R1VpTi9hQU1kekZLVUVV?= =?utf-8?B?QktmQUM5bll0YXJJOGYxb3RmeUJTMzBhM3M3d1lOb1ViWDMvSXppVWkwL3FU?= =?utf-8?B?Vkp4cGtqbWsrckRwa2pob1RMQjUxUU4xY1dKYXVlNmh3ZU9JSU1ndEh2SHRp?= =?utf-8?B?TDBDcmhYV055cXlQd0p6dENBb2ZOdWNVTjZySllSaXBIZFFnOXNFd3dBSnRs?= =?utf-8?B?S0Y3amg3VFdoS0hWQktBSWxWUHhYMHVZNWg4V3RyWEpzSDJyRDBURmJpNlg4?= =?utf-8?B?dFlteHJjaVpDYkRTbng0a3dlRG5aYTlabUhGZ05UeGZTNGdlR0llSnllRTBX?= =?utf-8?B?NC9QUlBCNUs3RjRKbDg5WlVvRWF5eXMyZlBpS25nRXBMYitmREpnelhBcHJC?= =?utf-8?B?eGtKOFBYTlZxanN5V2dHanJFOWJVZk9tc1dzdlUra0FkS3VZVHVIc3VUdWl2?= =?utf-8?B?dFl1RWh3Y3ZtTTMyM0h0SDVVbUd4anlGcmZQbE5rWlZoMTJTM3A4T3Y3OWVr?= =?utf-8?B?NlQyQ2NST1BFUzk5Tnh2a3ZlMUpsZnpEYW43ekRlR3lKZHVIWmRLUldoMnU2?= =?utf-8?B?L2tHQVJ6Qy90OEhrZ1g3TVk5WHpRVVhMOFNSSWRGemt4b25kdHU5S2RiYkdM?= =?utf-8?B?MEh4MXpWNUJLWWE0QVhmUitvdmpWODdkMWd5MjlXb1ArRHZBQ29STSt3c1hH?= =?utf-8?B?cU5qWUthSXovMjV5N2pCVzUvNjNtdUlMclBodHFJUE5QV3NKZnBIa2tvVDBm?= =?utf-8?B?dVB3cE1DVC9Ca09UdXptbTg1d3FNVnU4aGJoUU54RzZieEdBUlBMc1VrNVZM?= =?utf-8?B?emZwZWVwVXFHcDZZUEpwVlB2RlBRYjI2cWVLRnZOZFpUWUJkTUgrczRnNERF?= =?utf-8?B?bzZ3cDdySjFmZm9VMG0zSE4yVDNHR2ZYRU1hblFpODZPVnV4RW1vcE90SUpk?= =?utf-8?B?azlYS1dmN3lYZzZMV09sa2JqMFZUaTJNekJOYlRZNUpmNU9sZ2EzbUxmMk1H?= =?utf-8?B?T0dTVDJabDh3Kzc4cGlJekEyVkpPUEhSY2lkQkUyaThmK05NTE5UTk1rK3E2?= =?utf-8?B?b0xxS0lpc1RFdzZkVU9MTldrUlBJamg5ejNZNkEvQXp0b1pWSC9ZaThVdnlU?= =?utf-8?B?bllsN0QvTmdiaXhjOWVEaVdnTUJEU0RkMFNQK3c4OEp6eTRMNjg5WTVYK25n?= =?utf-8?B?ZmhkRlBxY2hRaTBmYUlhMXRONkpzSUxmUkJKN1F2QVNqT1FqK2gyMm5hTS9Z?= =?utf-8?B?WnBUV3ljcWxpUHhkWlQ4YWFSMFM2eXFvVElZckVJQXZMWDI4Z1pZSjBPWDI0?= =?utf-8?B?REZKVVM4cy85amhraENlb25DNFN6ZW1wYitKTjd6aGVmUVk0NFd4Mm1hTUlo?= =?utf-8?B?ZkJhdm56RkJnTmR4bFVVempxNU40YTZPalZPVVFBeitqdkxKdC9XeWt1S0ZN?= =?utf-8?B?d3FSRnk4bnV2RkFCMGNRQmNkckhLZlZucFZCVWhTNmFRT3BROHl1NlVoTlBO?= =?utf-8?B?OFVadjRVWVFVRmJLMXBHZkFmakJMWGdmMEkrZ3FnMjd6WXJVVyt5OE12Rksy?= =?utf-8?B?NVZvSDFidWxlK2NwQ0ZkV1FNMVRsWWhiWjIvUnVYZUFyTFBVRGRkdERQbUlj?= =?utf-8?B?VTI3Q3JlU0lSK1YyZlNMOWZja2JFc2dxeEhRQXRVaFNLOWh6SkU4RXhBMGlj?= =?utf-8?B?VXNOMEFybTJRTVdmajl4elQ4SU9OWER0a1lXM08vUzBvMGY1ei9lSUgwZXd1?= =?utf-8?B?dnllaDZNazBzOXFTMHNqRWEvNGIrMTA0dkRxTTdzVHcxempsaXc3Tlovenk1?= =?utf-8?B?bVc5L0k4NGxqT3lRVi92TUhSd3JoS1p2L0VMaTJLZ2tmdjlBRnYrUUllMEh2?= =?utf-8?B?NTJNVGhNWFRTZHdNU080SXBiUXBLcTc5dWdiZkJQZ0Vmbkg2ZUtsV1paYytm?= =?utf-8?B?OVNlTWlaSkY4WXJrTWNVWEdDQ1BnTGRjdHlJUTN5ODNCRGRTMzFrNC9TejVU?= =?utf-8?B?VVdUTzV3cDFNWEVWVGwwTFNTZ1hGb1R1UktLWmVkRHQ1b0pQajZuRDFOS2tu?= =?utf-8?B?VkE5dXZyMW05elVUdzhmQWFHTGNjQnplUU14R2NxeGVDK3BGOHkrbnVuc3BJ?= =?utf-8?B?MjI1TUY1YzhqbEtCZVgvNEhZRHJiMHpyNjZmOGtkNFFyT1FRazJPbVlvaS9U?= =?utf-8?B?NnpUckdQOExEYzVFUU9UZlVULy9tRFBwdHI4UHVuSDVNNmJBdStuSWx4Rzdz?= =?utf-8?B?TFVuZGlqMms1WWtsZ3JOYWtjb3c2bkM5Tk9jbW45R216UlBYa2R1dExEVjRG?= =?utf-8?Q?gaeJdo04MdrTKuME=3D?= X-Exchange-RoutingPolicyChecked: dRqtH/O8RXCs6nJjm2T45m5Jnu4crSsQ+B8coVt6XD3F40sMTExgn04zZ2KMNK6xf/grt/bQZFu45WOVdK98w4NMaoZ6IQWi3rfqPXgXGgtd5U5gXKrKqz3kUvy7gFJlJT3CkUFjHEH8+qCnjtq9WcnWNsdl4IPfOUoLZpJZk35jsVjZv0fTKSNvZi4oA7qqLlc2XakrkycNKq2XDzjiJeHseSjfNy5uec7FFZx073MMAPeLxEDAupMiz5V+q3sdrHEvsWu+f11BNflQWvph2NXOP7Hadg2DIIpP9p6gu0ADnyPBNGXw2E14JSd5H5GBQh6OlFckfr/7q3sqmAK1/w== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3631a320-405f-4c14-de7e-08df2f880306 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 15:28:52.7588 (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: jAMVlFxiAvGmuac9xkh9YdllWLQ4DTuiIt1ge1Kthjh3U+2RWMqKw4x5IwMIaT1mpHVO4r1DD5WrFjkxpAEedmlqud8HfmHfZ+j1s8Qq5rI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6810 X-Proofpoint-ORIG-GUID: 7TQJyx3FTLsyPtSWNx71hwwAmBNoDsu9 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDIxMDA2MSBTYWx0ZWRfX90I+hzSomUgY eX5nxWqFNSSWc/+SPhhRX+uSxg5xnq0SdfhqdQ5w06oENBJY0S6TWVqXF0FQCus2IgFD0mEP38H 8Ipu7jHXb9Nw5h7ssdIl1kOeAz6GSkE= X-Proofpoint-GUID: 7TQJyx3FTLsyPtSWNx71hwwAmBNoDsu9 X-Authority-Analysis: v=2.4 cv=At97T+9P c=1 sm=1 tr=0 ts=6ad8da3f cx=c_pps a=U/cWNT7cGANcmDM7K3LxiQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=KKAkSRfTAAAA:8 a=K7m7aL5B5UdGmL8ntpEA:9 a=QEXdDO2ut3YA:10 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDIxMDA2MSBTYWx0ZWRfXwGF1EAY1cisG jw8Zr8y+Q4rVTrbsxnTeLqDCmPUOEcqHXqTm5fJ/KgFx7qev3GIL+S4YXz0HWRqqCGlMp6O45tu Icbvsh1IYHVcA8fZGrg8F4n5qw4fc+tdQ9Shl4Pybj/abWsd0Uh6IiXTuiVfzKcYVsTt/+M4iQB f40GdKLuFS816NqoTZj4lqySHe6KIe5XGwea7JWPM+KN+VuWaeI3oGo+8E9jgNv+VCNa5ENkMPM NV7bxAXjl82XRl8gq3gPhMLV0aBK0Hy7kDMtegC/PbU56GprIXKZGVZMQTALf+jU4zut97a38bS OjpSH1KBWQbdRD09nAWUN+Gaz9UBkMmHgJkaxx4ct4MtyA32kGH5kvH+6o9IuUveJlDr1Gq8McG 8Lujlf7Qg6u4QobGSUQHE2W7HgijC2+FKevf+8ObbxzwxTU7se+MH2b3LOaoF04hWidzlnyTugh O4tWtp37SkHa5tvIC6Q== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-21_04,2026-10-21_01,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1792596557-198C19EA-7B68A6E5/0/0 X-purgate-type: clean X-purgate-size: 3051 On 20/10/2026 18:39, Bernhard Beschow wrote: > Am 19. Oktober 2026 12:04:54 UTC schrieb Mark Cave-Ayland : >> 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 >> Reviewed-by: Peter Maydell >> --- >> 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 2d8c87b0e3..dbfd55de30 100644 >> --- a/hw/i386/pc.c >> +++ b/hw/i386/pc.c >> @@ -1167,7 +1167,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); > > Since this function allocates 16 IRQs, the convention according to this series would be xen_i8259_pic_init(), no? I've deliberately used the same naming here as KVM does in pc_i8259_create(), i.e. xen_i8259_init() to match kvm_i8259_init(). However ultimately it shouldn't matter as I'm planning to remove those *_i8259_init() functions in a future series. > Otherwise, much appreciated clarification of the terminology. Thanks! > Best regards, > Bernhard > >> } >> 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; >> } ATB, Mark. From xen-devel-bounces@lists.xenproject.org Wed Oct 21 16:02:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 16:02:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457426.1670239 (Exim 4.92) (envelope-from ) id 1xJYlv-0000jT-8y; Wed, 21 Oct 2026 16:02:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457426.1670239; Wed, 21 Oct 2026 16:02: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 1xJYlv-0000jM-5L; Wed, 21 Oct 2026 16:02:35 +0000 Received: by outflank-mailman (input) for mailman id 1457426; Wed, 21 Oct 2026 16:02:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJYlu-0000jG-Jj for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 16:02:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xJYlu-00000005d0C-2znY for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 16:02:34 +0000 Received: from mail-lj1-f180.google.com ([209.85.208.180]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xJYlu-00000006N7H-2nln for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 16:02:34 +0000 Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-3ab4891fc73so8104981fa.0 for ; Wed, 21 Oct 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" 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=H7NULoOHNlw+dfwR3xwa/ClCFozBRW7oB/WH1dWqxvc=; b=JpmSvb4VSmIaJhfVo4qiCxSfhD lJwd9nCctK04TjQ83fHydLLFZyF1ftePfew512HBAOvFsgjLL6642YxaiSoa2f10OBfMPTCdKLPEm BaoBHIVwqM3Y/q/Y0dmVSqzE/G0SKXuBLPdYN9iukVtkRRSwUgCuNRhfpVXzjLfOKIqg=; X-Gm-Message-State: AFq9FYJ2kdjYOyvDLWPvLQjPNKSZuuDmEXIp3hjyV+gIV8/mtfe0AirO ZujyK82WtnPpuzFwc34OvGvIaeDa9fyW1uohFQ6QNtiIaILBpnUqHpxqsE4AiUWmZEbzUosmFEs /1XwkFLm72o5CB0quEB3+Fl4by/CGt+g= X-Received: by 2002:a05:651c:1990:b0:3a9:decc:71d8 with SMTP id 38308e7fff4ca-3ac4420b02cmr7453761fa.20.1792598553366; Wed, 21 Oct 2026 09:02:33 -0700 (PDT) MIME-Version: 1.0 References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-26-b68b66652266@xenproject.org> <44c485d8-1d57-4c59-9484-7c52303fbe2c@citrix.com> In-Reply-To: <44c485d8-1d57-4c59-9484-7c52303fbe2c@citrix.com> From: George Dunlap Date: Wed, 21 Oct 2026 17:02:21 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8x578LBIgoQB-OCsYcWBmumDpAD-i01nOkgTXPKlXk3PVX3vsBFfL5q8E Message-ID: Subject: Re: [PATCH v4 26/30] x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from() To: Ross Lagerwall Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 21, 2026 at 10:22=E2=80=AFAM Ross Lagerwall wrote: > FYI I posted "x86/svm: Don't clear clean bits on every context switch" a = few > weeks ago which moves it into svm_do_resume(). I think that is preferable= for > the reasons mentioned in the patch and IIUC would still be after the vCPU= 's > VMCB is mapped. OK; since yours is a single patch with two acks, I'll rebase onto yours. Thanks, -George From xen-devel-bounces@lists.xenproject.org Wed Oct 21 16:57:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 16:57:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457480.1670249 (Exim 4.92) (envelope-from ) id 1xJZdI-00088e-7y; Wed, 21 Oct 2026 16:57:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457480.1670249; Wed, 21 Oct 2026 16: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 1xJZdI-00088X-2y; Wed, 21 Oct 2026 16:57:44 +0000 Received: by outflank-mailman (input) for mailman id 1457480; Wed, 21 Oct 2026 16:57:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJZdG-00088R-G6 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 16:57:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJZdF-004AO0-IV for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 18:57:41 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8eefc-8faa-0a2a0a5109dd-0a2a45058d0a-20 for ; Wed, 21 Oct 2026 18:57:41 +0200 Received: from [52.101.201.43] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad8ef03-4cb1-0a2a45050019-3465c92b9998-3 for ; Wed, 21 Oct 2026 18:57:41 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH6PR03MB997196.namprd03.prod.outlook.com (2603:10b6:510:3dc::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Wed, 21 Oct 2026 16:57:36 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0546.012; Wed, 21 Oct 2026 16:57: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=Pc3Mzx1ZwlkbO/f2zJWJ6k3kwhq0lqPeMVvnLTTOTMW5JwUYlSte9Fp3LFK/NZSLXL3TzcMIFX9h4bSKMvLvRFk5l72jPWI2y5kiF9JQ5fyg/zEXQQBlX17lo2eYre6bMOoY8tDqqzljDogdHDdPd8MsRik7XluKae3CAbaSD4G+0D5q8kflCE+sPkt8KXb9A6HrQUmTRzEjlUvNrwQPAupi1j6qh8Riqlv1fBeIUV9xBP56UqsTcy6pvhkTQeF4uCvrnn10hnG4w53YwIbOHGipVTckcl00d45vfxRe9hc+9F1WS+SuL5S6KAdEDOhxRlOYCLrETzZqJgQpDmGCtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NSdRuYQevsR9txi9ntwH53BkqPEjU13DFaNpYuthTNw=; b=YZyQTwZjnxq8ydCEeCB+1J0/DxuilufD/cPVdA8vXrrXjGajC3nefu+SGs9Svo2B6T9YR9G8Zp3iBg89vwwt7NzED/DsBogyL9Piqz9pUa8AaTjxEaNykKRUGFbQKkXJNf4verXgdLnbEufb3PuzVt3/MZokP/xvF9K6XOfsfWAGwLCMuTrr2kctp3l1xFjV4rmMu8buY3075Iz6YkHknYV4nCP+ezpD+g9mibzUNs+v+DdiEPMz/m78af9Au1dmNnv7pTpoPMnjo+rndY0Co1BTVMWV4swsh7Qvb6fbxenBtcXRG3RA3617qgO4C+kCYYi74lEnTCtp40y/y96YxA== 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=NSdRuYQevsR9txi9ntwH53BkqPEjU13DFaNpYuthTNw=; b=SowU99M3RXxDhUEd3f95Rt1+Tq8QlW3wPUyWK72h+Q5bEIht5zJ8fLY7+FRtlLJgdJKInXK+qMvzTk856Ir6bzGSbL20DN2W3FL4Vi7cC9BZfCG3W0NZkhkEU77EY8iL1uNOmRb5c6/Ix3wjzsWpKvDgOAMljayigat4QKrz5iU= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <02d1a710-fdb4-479e-af2b-41755aa97d92@citrix.com> Date: Wed, 21 Oct 2026 17:57:33 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH v4 26/30] x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from() To: George Dunlap , Ross Lagerwall References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-26-b68b66652266@xenproject.org> <44c485d8-1d57-4c59-9484-7c52303fbe2c@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: LO4P123CA0656.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:316::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_|PH6PR03MB997196:EE_ X-MS-Office365-Filtering-Correlation-Id: 0aac804d-613d-454a-4ce3-08df2f9468a4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|56012099006|4143699003|11063799006|10067099003|18002099003|261021121427099002|22082099003; X-Microsoft-Antispam-Message-Info: ldufVY6w6xtWSwe4U490JD2eOIJDCZcD5wMHpFweq9BOkqEPzA/cvcWqIUWCEG3tnF7+UnserngoI0pDYF4g+yEzQncSDGGITFYl2zzdb31PdtTYnPICLwhsUbERuAjmgFWsKL4KtidJAbXbhjPQBkg0dbM8uRQKJccW3N/mLys8gpmJ5PYifUhl9gAUfNrRwTVpmJWufvnMBX6kYl/8hzaP9pL7o5cklBRjrLz/8fueS3VFi4exos/USTZ7T5xnn/8g/NCcpOG11e8Dml/tpK7dqqeVu10fL2DbaLRNCioM4+pD+maeAXJdMd4OK7oyptdOh+mA0nPd7jH+O+2AnGDA+1rY5TNnpyOUMPMAQwuzYFxczdMRn5Ykpl0OWprVaD7g8Yo3gbQPGCrZIkXGzWxjC135rzcuqepbmqRKDHU3rK7Q9y4ZScRHRNjSfwzernCVlDWsWdoAWelttdx4N2Ur9ZoaRRic5kybOGFqXLxsnb20cyMLXd8EJEqlkcnPExan0QoTwybsY+DOkzuPOOVgMVdPd8+nj8SeCFaXqZJpBJkoEWu1H4+D04NOnKrHQMcZNlLcDj99ItslJnZYMsyzODFwHxmU3MgOSOLNrb5FuTN0o5kRKF2u2ckcWO0toUwXZEJGFJHTxbE+qA150hIld68DSKKCdMH9w6doaPQ= 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)(56012099006)(4143699003)(11063799006)(10067099003)(18002099003)(261021121427099002)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SVlqanBXUm1hblhEUzFYTzhuVkUrT2wra1NWdXBFQ21hN3FwUlZYcjRUMXh3?= =?utf-8?B?ZWlwTmZNRFRxQjFjVjllYm5Gems5Y2lhRFg1VWE2SUZUSGgyUWt6aEQ2dlgr?= =?utf-8?B?VkdaVE9wZHFqdGsrRzl4bXhlcUJBUmRsT0ZyQzRWNVM5dk14MWpDSnJjajhq?= =?utf-8?B?ZFFOR1phQUpieHA1a0FDR1BKOFJqTDIyOGhSM09Ma3hYMUVIQjQzZ2xNWlZS?= =?utf-8?B?MWU4L3JRNzZxOVFQaUtva2NNM1JUVnJhNC9TbUsxVmhDd0VGZFpodmhNWFln?= =?utf-8?B?bWxXaXFhZWp3MlNkc2xNZjd6cVA1WVRjZVA0TGh6dmxvUkprd29BR21ublVp?= =?utf-8?B?Q1VkbHo0aG9ySmo1dzN3b21VS0VRK0xkNnhLTWRKRGl0TEFGK1YxZ3BEdTdy?= =?utf-8?B?NU9QMXJaRWNFdVRPeHJYV1NXOGh4em1vNTAvdEhLZExRZkZEWWlXaFFuTG5t?= =?utf-8?B?OVg5S0o4Y2ZhVzJoTjJ1eTZleDFrajR3eGU2V3AwckNoVHFrbmlFVTluNXZ3?= =?utf-8?B?aUw2aVVPQjE1WHkzMUVESmx0dWl5WFUrRk1ISWxTeVMwSnlSb0xCY1AyZE92?= =?utf-8?B?YUlZN3A1dWJTU2pGdW1FVU52Mkh2cG1sakpqZC9nMnExK2pxZzZCcExiQUxU?= =?utf-8?B?UG5mS29LenNJRWhsaTlQdVZ4aitpNXNRWFFOeU5rWlMxbExPY05oeFFtZFh2?= =?utf-8?B?eDNSR251QVRzRERFc0dpODA5bUM5dW5venJlMUtQa3JjNFhSOWljZ2FaUnBy?= =?utf-8?B?ZXBVMGdBQ09jd3pobWVrWnZHZC8reHdzZUFlMjRNU214eVZCdFFnS1B6ZEdY?= =?utf-8?B?ZVNmZFNzc0kyV09jOU1OMlY5RHFUbUhxbmt4di81WmFkemg4VHhaTVR1VkVm?= =?utf-8?B?bCtIcWhtQ0lYNmo5MHJYOEJjL2lpQ0pSdm0rVkdmN0xEU25aWmtLUzJieERB?= =?utf-8?B?b1lNVjg5TSsvczBHN0FzbEFyQTlVSW5wZDRqa1RKMkFmSGVkVjQrbElHYTNE?= =?utf-8?B?ckcyNW9ONVorc0RxYkliU2JDdnZaWTlSTS9aL2w4R1V5SVZhM3ZKZkduUkNH?= =?utf-8?B?eGpjemdyWlNndEZOOXFhVFJiZkhaS1hXZG9GTUZLRi9jOHo3YW9WQjgwVTl6?= =?utf-8?B?ZUtaU3puY0RrVnQ4MzFaZjJCN0d2SXZTUmYrajRGOGwvWU14VEhXbTFEQnJX?= =?utf-8?B?L1JiM0RWSzJDaC9NTng4UWlRcTNrdVg5Y213TUFPTEdEM3NhU3o3WkJlSVh4?= =?utf-8?B?YUtuOUJTbnpERDhTbUtNem9CakR6OVR4ekxnT0VzdnA2MXBWT2dCRFN0YXEy?= =?utf-8?B?K0FnYjl1YmdZSWZsZTNsT1hXWHplcjFlYTVtR1BlVE1MeHJQbXo0Z0xnZEpY?= =?utf-8?B?Zm1XWmRnMnFBcWZYMWhqOXdDNmVweDcrVHhyb0tqWmFmdHpTdERRWXBLSjNJ?= =?utf-8?B?c3Erdi9SZFQ1TG9ZbDZKMWU1c1JVV3VPSnlKNHltaUlvRkFJc1NNV3VVNFdR?= =?utf-8?B?Unp1SkRhQVlCVzF0OUVKT25IU3NsQVE1QzFBV2w2Um91cThsSEZVNE1NaVlF?= =?utf-8?B?VmtMbW0xQXFNaWpEVnpOOHJ3Rzg2MG8xV1VndzVKcnFRMXdMUm5MMERWQzFy?= =?utf-8?B?RDI1eHZkc1UvdWc3K1VFb0tCRUdtdzdCNUlDYWxXZHRwQ3FraUlIcnF3RUNL?= =?utf-8?B?RFFmM1VxdG1vMWZhVUdxZWF1RnBRNDkyYWdjL1NJbmEyNDR2SlVzbnpOU1U5?= =?utf-8?B?b1lFMUJwV3hyc3R6ekgrbk4yOTF3bmJRRWp1SXhkZXR0cHBxWjlWY2dYY2Rj?= =?utf-8?B?MDVEQ3lvUHR1NHZ5ZE9mL2hIUmhnbVNtR0NXUVB1eWo0T3ZMTk5xbzRCTEdI?= =?utf-8?B?aDFzdlV4OUF5VUVYZDdRNkxOalBXc1JxVHlrcWg0WS9kMFVMNTByTjhDNHJB?= =?utf-8?B?UDhmMWFFcWF2Rm85Mi9FeWl0WEZvRjZ0TlpjNXZmTm5zQ0JxMXJNYXdGQmNL?= =?utf-8?B?TEZFd1c4RldIZ2VRaWdkbnZMcHNxY1ZpN1ZCWS9aSERvT1dqWGtjZjkzM0dw?= =?utf-8?B?bnVxNVJyNU9tR2xKWjZvV1RkQUh2YXhhbWFyNVUvck94Q1BzckEyb1VDelVp?= =?utf-8?B?ODFyQnBPOVVUUlp0MjZiMmpTRDVmRzYzU0lsT0FRM2NZYlIxOTYrNVpGeStj?= =?utf-8?B?Zld5TVgrMHBjRUFUMUdSVVl1YUNVT2pLSFk0WnNEWjN5R2lyT1ZKK3NxTEJ6?= =?utf-8?B?TVhwazk2RVgzQ0c1YXpSWHZHOWlEKzQrMzZCaVdoYjg5ZU4wRmpVejh0cEhv?= =?utf-8?B?TjV6RDQ4c3pEblJzL3UySi9sWGZZWFArNnFjRllRZUwrUVZ2WU00UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0aac804d-613d-454a-4ce3-08df2f9468a4 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 16:57:36.7986 (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: 5/vja361F2qPN/UhQ8In7yIEmLQ2+JKubWixPQ41sPkp0FvBDmtVq6qsBMgwz16eF/pUPLBSq+H9THMeqFsmy24g4AFiH435YEikS9nrhBo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH6PR03MB997196 X-purgate-ID: tlsNG-c201ff/1792601861-F76BD2A1-DFD56D57/0/0 X-purgate-type: clean X-purgate-size: 550 On 21/10/2026 5:02 pm, George Dunlap wrote: > On Wed, Oct 21, 2026 at 10:22 AM Ross Lagerwall > wrote: >> FYI I posted "x86/svm: Don't clear clean bits on every context switch" a few >> weeks ago which moves it into svm_do_resume(). I think that is preferable for >> the reasons mentioned in the patch and IIUC would still be after the vCPU's >> VMCB is mapped. > > OK; since yours is a single patch with two acks, I'll rebase onto yours. I thought I'd already committed it...   Apparently not. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Oct 21 21:35:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Oct 2026 21:35:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457629.1670257 (Exim 4.92) (envelope-from ) id 1xJdxx-0003ml-Me; Wed, 21 Oct 2026 21:35:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457629.1670257; Wed, 21 Oct 2026 21:35: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 1xJdxx-0003md-IG; Wed, 21 Oct 2026 21:35:21 +0000 Received: by outflank-mailman (input) for mailman id 1457629; Wed, 21 Oct 2026 21:35:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJdxw-0003mX-86 for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 21:35:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJdxv-000RC6-LD for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 23:35:19 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad93017-e002-0a2a0a5209dd-0a2a45098168-0 for ; Wed, 21 Oct 2026 23:35:19 +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 6ad93017-be1a-0a2a45090019-d155dd2fe1ec-3 for ; Wed, 21 Oct 2026 23:35:19 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48dee593f18so954499f8f.3 for ; Wed, 21 Oct 2026 14:35:19 -0700 (PDT) Received: from ?IPV6:2a02:8012:3a1:0:e0eb:d807:1db9:ec95? ([2a02:8012:3a1:0:e0eb:d807:1db9:ec95]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e254f093asm8390996f8f.4.2026.10.21.14.35.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Oct 2026 14: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; none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792618519; x=1793223319; 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=vuf4gu+cZK0zwE9Bo0/B6FEPxPMzK24nZpHR8b9+Svo=; b=Av51VF8Hsx17/+T7ufGM4CYiOkPtDxN3wSeYuuJFU5Gq2VvRMc8WxjDdevEp/5xuxW li9UcyqJMyLzYtqc6g0i+K53+piC7OHaYdWEn3SP8QX6Hb7mbNCP6YkfOstFyenYgmTU WN3n8v0iOvGeTXV0810sDJgh8/GZwHC7OmGqofeYxpyB1neDZSu8spkFb8YJYP0wUwd4 5eaFnVruZgJXKqU88bazALzr1lalqRjuVtp70ng6ahvUml+dXnk0Nn4Nn3LT2D6DrANy kKD3aKlSVw/Zb/BLmmdXTiOHlhHvDg+Vywp9TprzTkfcDYPc0DdIjEbTWUNS3DOiQSVk 0tvg== X-Forwarded-Encrypted: i=1; AKwUvByHICuBNpI2iMo51/LFnz3xI1Bnex+SHzZgqvnHJAziV7rxYraQrTGERvIVnhiIAaNLKe1YZNnONes=@lists.xenproject.org X-Gm-Message-State: AFq9FYLpxXcQui7YSN3kxquxkIoTiCFq9RKyhl4eh5oYcuuimtXvjtsF bfrTgB42jhk7gpqXLN354pKbBr7uNeHD4kvwun4c500oE1KRE55nA+rD1yOl3w== X-Gm-Gg: AYBFou3Gf6JVnTtGx7tIBZGNj9ceYwn44OfNcIvMqOQaVTACEclXF6TLtiVrQvJgV8a YaLDR2Gh4rvq0GXXuVgRyllJHjsh1hhQrtiHCZu5jsE3yQfJ1/JdYyAVqoi7ae/sl/hTNysfmir BFp7BVzkGOf1OKSpSJkq3Vjr1yUXepkXHeaa/CZfNCsdhHP+KuE4z0CplCOvt66YWbNOYgv9ZZi u5z4yyAVscVKAizhbySez5lG/rWYgbAY03cHczHlR+iQ/dmwUdzmqZc3fB2sXvMsk4H/HHZDV82 v6ouAql8KJM5RpPYaDbBad2/Kxt6Lb5S/hIpI9jDX3UwcckYYlQdcqT//fFgrT/Yo0bowkHFOjD PwogHMSSL3QPiXMPwRUvKSbbKN+xFaaSfuoy5ymwtgwSOdToYVBJCgKiRRWCD77b/lulwBuTBav T3ZvGMAD3ziTaL++5nts0qWjecgQkYGEyJc8Be+vYZTzCGZeXSj4TlDj4aI5hew07I7CZG8y6w7 7b11B99oy/mYE6t55i8b9QnZyWW9z4Wh4T+AyGAxg4CrWovPrdErvL4b21MXSCZEBF8HstSUHjj FnEiCJart+5ENwcHlemyZ0tyxcsu/7/8LLI= X-Received: by 2002:a5d:6f04:0:b0:48d:f3a4:610b with SMTP id ffacd0b85a97d-48e264bba16mr7462500f8f.25.1792618518953; Wed, 21 Oct 2026 14:35:18 -0700 (PDT) Message-ID: Date: Wed, 21 Oct 2026 22:35:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Fix under-mapping in map_range_to_domain() To: "Orzel, Michal" , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20261007135848.220047-1-michal.orzel@amd.com> <055dc887-0cfd-4274-a5f6-e5afdd576746@xen.org> <9a4f56d4-4c2e-4d5a-8489-9300170729a3@amd.com> <71defbe4-44a1-4b76-8d0a-bcc6ab40515f@xen.org> <9d970022-6b08-421c-aca0-589a0b5c2c27@amd.com> Content-Language: en-GB From: "Grall, Julien" In-Reply-To: <9d970022-6b08-421c-aca0-589a0b5c2c27@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1792618519-3BCD7034-94E79509/0/0 X-purgate-type: clean X-purgate-size: 2217 Hi Michal, Sorry for the late reply. On 12/10/2026 08:32, Orzel, Michal wrote: >>> >>> I don't think we can reject unaligned regions in map_range_to_domain() >>> though, as the host DT is not under our control and hwdom would fail to >>> boot on platforms with sub-page devices. I asked AI to look at the Linux boards >>> for Arm and Arm64 (140 boards in total with unaligned regions) and even the >>> boards we claim to support have nodes that would fail: >>> - RPI4: hdmi@7ef00700, <0x7ef01f00 0x400> >>> - IMX8QXP: clock-controller@5b290004, <0x5b290004 0x10000> >> >> I am not suggesting to reject unaligned regions when mapped into the >> hardware domain. I am suggesting to reject it when we want to >> passthrough to another domain. So we don't end up in a situation two >> different devices on the same page are passthrough to two different >> domains (or between Xen and a domain). >> >> Codewise, it would mean map_range_to_domain() would enforce the >> alignment and the caller will be left to decide what to do. We could >> also decide about the alignment base don whether this is the HW domain >> or not within the function. > For passthrough this is already the case. map_range_to_domain() does > not map anything for nodes with xen,passthrough and the domU mapping is done by > handle_passthrough_prop(), which rejects mstart, gstart and size that are not > page aligned. > > The remaining case is the overlay which can be attached to any 1:1 domain and > this goes through handle_device() -> map_range_to_domain() without any alignment > check. All the other callers operate on hwdom, so I think we could reject a > region that is not page aligned if d is not the hardware domain, before granting > the iomem permission in map_range_to_domain(). > > Shouldn't we accept this patch as is so that we can backport (overlay is not > supported) it as a fix and then add a second one with a rejection mentioned > above that will help the overlay (and any future) case? Thanks for the input. I didn't realise we would want to backport this patch. If so, I agree the split make sense. Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Oct 22 01:47:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 01:47:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457752.1670266 (Exim 4.92) (envelope-from ) id 1xJhtp-00055A-9Y; Thu, 22 Oct 2026 01:47:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457752.1670266; Thu, 22 Oct 2026 01:47: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 1xJhtp-000552-50; Thu, 22 Oct 2026 01:47:21 +0000 Received: by outflank-mailman (input) for mailman id 1457752; Thu, 22 Oct 2026 01:47:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJhtm-00054w-RG for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 01:47:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJhtl-000Ynv-Sz for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 03:47:17 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad96b25-8faa-0a2a0a5109dd-0a2a450b80a8-0 for ; Thu, 22 Oct 2026 03:47:17 +0200 Received: from [209.85.221.169] (helo=mail-vk1-f169.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad96b24-b7e8-0a2a450b0019-d155dda9dcbc-3 for ; Thu, 22 Oct 2026 03:47:17 +0200 Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-5eaefe5b523so845886e0c.0 for ; Wed, 21 Oct 2026 18:47:17 -0700 (PDT) Received: from gmail.com (111.46.245.35.bc.googleusercontent.com. [35.245.46.111]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5eae980f64esm5275613e0c.13.2026.10.21.18.47.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 18:47: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:MIME-Version:Subject:References:In-Reply-To:Message-ID:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792633636; x=1793238436; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=jCKRYOUlKmoPJSnDi6pvpqUte660v3ToEOh1Wa/1TdM=; b=C8mcvl316tLOTrxfqr1lFp5qnwJCIaHKuoV9Lr82c58gZORiGIdXAKez5zKdA5/XNa zjZlO3bSikRPXoxij9ti4bBaKKGW9ksxVcHuZcbf99rKKYShJzRb1e0INqZYJo/Hw9ck tESiw2qnkHYSeB/gDlOHSysxgsT6YEUvgSj1+0USpIs8UErA9RUk5YxGuI0N1LJGBbAu NFvEnn2bDvgsTav31O9OEC1bNP9ATSvnPL2BrlAubhQGjJn759EvHH6T9BxtCzEldTTr dLxgHLe0CyPWfO8jH9fGncOYfrCqUmsJ0yrGgBIfHz0yVAZzQEhWrxhdCtnnnuPFOqki rZCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792633636; x=1793238436; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jCKRYOUlKmoPJSnDi6pvpqUte660v3ToEOh1Wa/1TdM=; b=t5LvVIQX2HlAh44S9ftPL7O3lpc5c14AT26Yiezt9LJXn4tLElUYV5VLlvmSM4pQ9O 5+C6WTjMxwDXhW9GMQ9qXXZg69q3AUl/9eyDvp9LKvgItITmRHP810wFxEifOMrWwCbS wh6xwIV0rltK+jxvQ10+FEpULHp+8RzyDIvjmBqn5Jb11Dez4xkQ4P3UYD7bXmpS5qxE S9N207ZTHUzfpH6WEabD9dJc+dFgYleOAHnQhy9poPfJcaQdmblqhKLnPlvKnmXO8KJt ZpwWPEIuUGCn8Oe5jH5uiO3i5ChB+oDVvB7rSTx9a0Ks75XayR3sVVkLRlXi00SCDBuu oAJQ== X-Forwarded-Encrypted: i=1; AKwUvBzyK42H6GgrU8ICSejRzX/w56vt6hTzAXXLUGOBMUucoXZ0OmgKeTM9kqjQ4NOMQoY8h+aqZ2BlN/A=@lists.xenproject.org X-Gm-Message-State: AFq9FYKTQBjBSrZFYC3cmaRPijACr3jFePunTKrU7cCXtrvZHeyXjs+i 6INgbanhWW535GOtZEXxRdph9L2HDlPoJCaIFBgPy4/VPrH8E0+AJL8U X-Gm-Gg: AYBFou19sftBrhHrKHm9v0LXEoUWpZ7srQrHmo7EBY+zN0EsejMF2Cs9pPl2h5aAGTE NNKMotkPDBT218bUQ9hVxKRl+K/0aWJZ3pR2Epvb1Nu0QU3MrwqQgzeqlbh1xDbRmx3BmbW8voO R5cON358Ugxyb2R9jFhaO7xXTG7dK/qAKpxgfF3N+4fMxRnp3bQwd45vFrJYsyqx2nZTfjsmQMw WGAyoLMNgoUXyc2Lc9JGQPiNvNLogzKtZVUwGUnwXB8DVrdtTlvg6Tf31q1umrhLAux90/srdr2 YPtVpxPU8297Yk1uC7Fz4cL3ZqL4e5mBxH2oORsXscLGLYneVdn3wcwq/+GAABimYuWz/jxiAqO DPsKzT13JmekKJmPEcncrV8R3MegmAJw08G3DZYF6OHLa5wb8el2fgZsfkpkgCbKIOmkAGuUOB6 H8nMeXXvbsdEYo2yXXKuYBJgq23HgehqIUbtuddIw1o8CbjFgkMU6vPQQE96yxX/x0zNGwOBLvW F1fHrzLcTpX4uJipval8Lc6/44tlSEtKGdnMRPCNuq6MG7WYxIilOOk58NlCjmfF6ypKXTR2ZmJ GfsnyNn9zCxn0uSENQWjwmDGKf832Ba131aU0jFpcK5i+Wy78nqRwEQHVX3XtjD2N2VswXobrnQ +vaiEkwHuGWK7q9i3D6U= X-Received: by 2002:a05:6122:1d9f:b0:5e6:82ca:c551 with SMTP id 71dfb90a1353d-5eaebef16acmr1695454e0c.22.1792633636272; Wed, 21 Oct 2026 18:47:16 -0700 (PDT) Date: Wed, 21 Oct 2026 21:47:15 -0400 From: Willem de Bruijn To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Willem de Bruijn , Josef Bacik Message-ID: In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-11-2aa780a03524@toxicpanda.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-11-2aa780a03524@toxicpanda.com> Subject: Re: [PATCH net-next v2 11/15] net: skbuff: refuse to segment a nested frag_list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1792633637-2C59A9EA-756025D2/0/0 X-purgate-type: clean X-purgate-size: 3373 Josef Bacik wrote: > skb_segment() walks head_skb's frag_list, but for each member it only > looks at the linear part and frags[], never at the member's own > frag_list. head_skb->len still counts those bytes, so with a nested > frag_list the walk runs out of members while it still owes data, sets > list_skb to NULL, and dereferences it on a later pass, before any of > the layout checks get a chance to catch it. When the member is taken > whole with skb_clone(), the pskb_trim() that follows also drops its > nested data. > > Nothing in the tree is known to build such an skb; GRO flushes instead > of chaining an skb that already has a frag_list. Check each member as > the walk takes it, in the GSO_BY_FRAGS, clone and frag paths, and fail > the segmentation with -EINVAL if there's no member left or it has its > own frag_list, with a DEBUG_NET_WARN_ON_ONCE() for debug kernels, like > the other frag_list layout checks. Without SG the payload is copied > with helpers that do recurse into nested frag_lists, so that path is > left alone. > > Suggested-by: Willem de Bruijn > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > net/core/skbuff.c | 22 ++++++++++++++++++++-- > 1 file changed, 20 insertions(+), 2 deletions(-) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 56cec58bccb7..c5e28a52114b 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -5087,6 +5087,15 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, > int size; > > if (unlikely(gso_by_frags)) { > + /* The walk only goes one level deep: running out of > + * members, or finding one with its own frag_list, means > + * a nested frag_list that head_skb->len counts. > + */ > + if (unlikely(!list_skb || skb_has_frag_list(list_skb))) { > + DEBUG_NET_WARN_ON_ONCE(1); > + err = -EINVAL; > + goto err; > + } This patch became quite a bit more complex because of my request. More than I anticipated. Are you sure this first block is needed? > len = list_skb->len; > } else { > len = head_skb->len - offset; > @@ -5096,9 +5105,11 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, > > hsize = skb_headlen(head_skb) - offset; > > - if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && > + if (hsize <= 0 && i >= nfrags && list_skb && this test for list_skb != NULL is new. Previously this code already tested skb_headlen(list_skb) without it. Likely not needed for anything new in this patch? > + skb_headlen(list_skb) && > (skb_headlen(list_skb) == len || sg)) { > - if (unlikely(skb_headlen(list_skb) > len)) { > + if (unlikely(skb_headlen(list_skb) > len || > + skb_has_frag_list(list_skb))) { > DEBUG_NET_WARN_ON_ONCE(1); > err = -EINVAL; > goto err; > @@ -5216,6 +5227,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, > > while (pos < offset + len) { > if (i >= nfrags) { > + if (unlikely(!list_skb || > + skb_has_frag_list(list_skb))) { > + DEBUG_NET_WARN_ON_ONCE(1); > + err = -EINVAL; > + goto err; > + } > + > if (skb_orphan_frags(list_skb, GFP_ATOMIC) || > skb_zerocopy_clone(nskb, list_skb, > GFP_ATOMIC)) > > -- > 2.55.0 > From xen-devel-bounces@lists.xenproject.org Thu Oct 22 08:21:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 08:21:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457854.1670359 (Exim 4.92) (envelope-from ) id 1xJo3O-00057w-6l; Thu, 22 Oct 2026 08:21:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457854.1670359; Thu, 22 Oct 2026 08:21: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 1xJo3O-00057n-3Z; Thu, 22 Oct 2026 08:21:38 +0000 Received: by outflank-mailman (input) for mailman id 1457854; Thu, 22 Oct 2026 08:21:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJo3M-00057f-H1 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 08:21:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJo3L-0065ef-N8 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 10:21:35 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9c78e-2eae-0a2a0a5409dd-0a2a4508d3be-6 for ; Thu, 22 Oct 2026 10:21:35 +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 6ad9c78e-f659-0a2a45080019-aa0a857c51cd-3 for ; Thu, 22 Oct 2026 10:21:35 +0200 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-culzfh6qPpGd8R0q895OBA-1; Thu, 22 Oct 2026 08:21:30 +0000 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-48af4a0bd0fso862086f8f.2 for ; Thu, 22 Oct 2026 01:21:30 -0700 (PDT) Received: from [192.168.188.234] (ip232-47-231-195.pool-bba.aruba.it. [195.231.47.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e2581f15esm11704149f8f.20.2026.10.22.01.21.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2026 01:21: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=1792657294; 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=pvrxCavEY1oK9h13zUKSYsDKsO/+0N+t+Jn7Dea1vaM=; b=aaknlfmJq4wB5U99Zq0qZmU+6qQrMuRXLC5bBVzf4Z33Q7scC3dEOtmU1iRVrQwzgzDCHr Nl4ykTN+yxpsYmKQX1pmv4rQVYBnVWm6JVDHuFIeI6sFgRVmJT4VSMNFz173PmBclUoDkQ KO6RMKYzP2dPRgBa9+7zMyhXNSG2OtI= X-MC-Unique: culzfh6qPpGd8R0q895OBA-1 X-Mimecast-MFC-AGG-ID: culzfh6qPpGd8R0q895OBA_1792657289 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792657289; x=1793262089; 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=pvrxCavEY1oK9h13zUKSYsDKsO/+0N+t+Jn7Dea1vaM=; b=P/TP/E8zitTUOxvoTNdh3O2wu3lR61G+7YhiXZWo0mStVWLjw5n+MdaJhp0M73svyC aSAfe5ncIomzDfR3fZdFYTBxDJNiWMKAWQ64h/kUlhxa7XmtZK9nbk7wdszSE9zm1HZ7 Hx+xtFBsYuTqhb8FhQVqjENXXLtggT65PtJqMHJg01ZPH9zCxEcleLuFCQp2SceQ4LMq G0LRzo2gOUdNQOBFqODhL5cdnEkdK0f8GbN2xFHZmqxATRTgG/+FzmS0XiomXibAYLWu RCTCbWna0TfbLH1GwgXcOTxabFojqfIsRkQj3Ol024/Q+XBvIWrBQv1xkbpXD2DRPL4u MbAA== X-Forwarded-Encrypted: i=1; AKwUvBy7ziIxR7WrFgh7yFn5hWhRO5vbdPtccFRpWu8DGlQzoSVK1VNv+Fgciirhi4IiNC6M4jT5h18N0kI=@lists.xenproject.org X-Gm-Message-State: AFq9FYLHpLQUZ/ZWBHEMyt9cTHR/7AOob5gjtypkkY+/vKRVt76H3d2w 1aEk7zRFvLuw4uSHznas84EeBO1JKOSoqLzyB1+WtE7FOCxqBBjK6+WsN7Appv8zAybpT+Fxwjo 6ISBgPX9jJUtX8Iyz+0b2m3tSZeVlOWLdK4hNZfNMpj3YXTahJCY4XffVslPakY94+8tY X-Gm-Gg: AYBFou0QslwWmbSsZv/zRZ41vZ4O1p9Q6BcOz8gN99PLbNVDG6N2CUgxcb2KGhFxfTD GcbW+sKU7mVv3NyaYoZ6Aa0TQp0oUXn0/HFbqzwBhdM5y58NIS48CXG0iMrIA1eKhIjBVX525Un 9lv5GgoStrlOptPBsrxldnCDq8dNbGrauLb2lCJgKIJdechExaMoRUYjJMHk3sG606s99dGvMP0 KhaV72Q4XYbJgJfhQa9Dr/m/V11COZvwkAm0mC08Cdb7jlwvsogCnrtz1BqqSM3o+6gEvnoBE6o hqf85BGLSXRvucn/VOW4+POGjStfU6lxeg0rmUp6KvzcUDET3LDXVX7TFQbJ8F4sImrXVzSlEoy ll0gYmNZWrczbVERa8Jw9IrsFVJV0AvK9fL59fYupkJyhTvqoLQryhpm4pbZOrTsOTcDz2I7+rg == X-Received: by 2002:a05:6000:25c3:b0:48c:43a3:6a74 with SMTP id ffacd0b85a97d-48e2649d874mr10773775f8f.12.1792657289371; Thu, 22 Oct 2026 01:21:29 -0700 (PDT) X-Received: by 2002:a05:6000:25c3:b0:48c:43a3:6a74 with SMTP id ffacd0b85a97d-48e2649d874mr10773718f8f.12.1792657288926; Thu, 22 Oct 2026 01:21:28 -0700 (PDT) Message-ID: <717ace2e-18b2-4df5-848d-5757c01ee5de@redhat.com> Date: Thu, 22 Oct 2026 10:21:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-1-2aa780a03524@toxicpanda.com> From: Paolo Abeni In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-1-2aa780a03524@toxicpanda.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: K_hvyk3Z-zqaf7lO5FirHQX-k1CjbtfGtpTDVoQwEjI_1792657289 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1792657295-D437587B-AB3290FE/0/0 X-purgate-type: clean X-purgate-size: 5589 On 10/21/26 15:46, Josef Bacik wrote: > skb_copy_and_csum_bits() has no way to fail. When it reaches > unreadable frags it zero-fills the rest of the buffer and returns 0, > and since commit ab9414ed70bd ("net: skbuff: don't leave stale bytes in > skb_copy_and_csum_bits()") that 0 is the correct checksum for what's in > the buffer. Its callers can't tell the copy didn't happen. > > That matters in the !sg && !csum branch of skb_segment(). A devmem TCP > skb keeps its whole payload in unreadable frags, so every segment ends > up with a payload of zeroes, tcp_gso_segment() writes a valid TCP > checksum over it, and the peer accepts the zeroes as stream data. This > is reachable when both SG and TX checksum offload are turned off on a > device used for devmem TX: sk_setup_caps() still gives TCP SG and > HW_CSUM, so the dmabuf send is accepted, validate_xmit_unreadable_skb() > lets the skb through for a NETMEM_TX_NO_DMA device or a matching > binding, and software GSO segments it with neither feature. Before > that commit the segments carried uninitialized memory with a checksum > that almost never matched. > > This was reproduced with a test module rather than on devmem hardware: > skb_segment() on a TCPv4 GSO skb with 3000 bytes of payload in a page > frag marked unreadable, with features == 0, returns 3 segments whose > payloads are all zeroes, each with a checksum of 0, which is correct for > zeroes. There's no warning or error; the data is silently replaced. > With this patch skb_segment() returns -EFAULT. > > Make skb_copy_and_csum_bits() return 0 or -EFAULT and hand the checksum > back through a pointer, and make it __must_check so a new caller can't > ignore the failure. Running out of skb before @len returns -EFAULT > too; commit 417261779eab ("net: skbuff: don't BUG() on leftover length > in skb_copy_and_csum_bits()") made that a zero-fill and a checksum of 0. > Each caller takes the error path it already has for a failed copy: > > - skb_segment() fails the segmentation, as the csum branch already > does when skb_copy_bits() fails. > - icmp_glue_bits() and icmpv6_getfrag() return the error, so the ICMP > error isn't sent. > - __ip_append_data() and __ip6_append_data() drop the new skb and > return -EFAULT, as they do when getfrag fails. > - vnet_skb_shape() fails the same way it does when its skb_copy_bits() > call fails. > - xdr_skb_read_bits() returns 0 without consuming anything, as it does > when skb_copy_bits() fails, so desc.count stays non-zero and > csum_partial_copy_to_xdr() fails. csum_partial_copy_to_xdr() used > to checksum the bytes it hadn't copied before checking desc.count. > desc.offset and desc.count always add up to skb->len, so that only > ran when it was about to fail anyway, and on an unreadable skb > skb_checksum() would WARN. Drop it. > - skb_copy_and_csum_dev() can't return an error, so it leaves the > checksum alone and the frame goes out with a bad one. Its callers > are drivers that never see unreadable skbs anyway. > > The zero-fill stays, so a caller that does send the buffer still > doesn't leak anything. > > This was found by the Sashiko AI review of that commit, and > Mina suggested reporting the error from the helper rather than checking > for unreadable frags in skb_segment(). > > Link: https://lore.kernel.org/all/179148235783.434549.14322374227477832817@kernel.org/ > Suggested-by: Mina Almasry > Reviewed-by: Mina Almasry > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > drivers/net/ethernet/sun/sunvnet_common.c | 10 +++-- > include/linux/skbuff.h | 4 +- > net/core/skbuff.c | 63 +++++++++++++++++++++---------- > net/ipv4/icmp.c | 9 +++-- > net/ipv4/ip_output.c | 11 ++++-- > net/ipv6/icmp.c | 7 +++- > net/ipv6/ip6_output.c | 11 ++++-- > net/sunrpc/socklib.c | 9 ++--- > 8 files changed, 83 insertions(+), 41 deletions(-) > > diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c > index 5cca95869052..4f229fcecc32 100644 > --- a/drivers/net/ethernet/sun/sunvnet_common.c > +++ b/drivers/net/ethernet/sun/sunvnet_common.c > @@ -1167,9 +1167,13 @@ static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, int ncookies) > > /* copy the rest, with csum calculation */ > *(__sum16 *)(skb->data + offset) = 0; > - csum = skb_copy_and_csum_bits(skb, start, > - nskb->data + start, > - skb->len - start); > + if (skb_copy_and_csum_bits(skb, start, > + nskb->data + start, > + skb->len - start, &csum)) { Recently Eric did some work to remove return arguments from the fast-path, as with some config it gives measurable overhead. See commit a02a765bd5c2ae7705144829b2911c96c29db6ba. S/W csum should not be the fastest path, but AFAICS the UDP output path could use it when building the aggregate segments. I'm wondering using a 64 bit return value and encoding there both the csum and the error coudl make sense. Also currently net-next is closed for the merge window, and a bunch of changes in this series looks more like cleanup than fixes. Cleanup will have to wait for the end of the merge window, fixes can land at any time. /P From xen-devel-bounces@lists.xenproject.org Thu Oct 22 08:37:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 08:37:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457863.1670369 (Exim 4.92) (envelope-from ) id 1xJoIn-00074K-Gb; Thu, 22 Oct 2026 08:37:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457863.1670369; Thu, 22 Oct 2026 08: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 1xJoIn-00074D-DB; Thu, 22 Oct 2026 08:37:33 +0000 Received: by outflank-mailman (input) for mailman id 1457863; Thu, 22 Oct 2026 08:37:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJoIm-000747-9P for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 08:37:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJoIk-008Yj1-EX for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 10:37:30 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9cb47-e002-0a2a0a5209dd-0a2a4503da74-18 for ; Thu, 22 Oct 2026 10:37:30 +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 6ad9cb49-fae8-0a2a45030019-b9ff1c23ae47-3 for ; Thu, 22 Oct 2026 10:37: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 1a162c2110b000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 08:37:27 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id C38AA81AD1; Thu, 22 Oct 2026 10:37: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=+704xng93SrmmfWhH0hFBiVyGpntHRf6eEGQOSEeYno=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=G/4GDtcLcNOAIHp2MdQrPOYQnAmOVRmIdjt3OvycSRxapEUOBW+PNHTfgUEyrzF018QPWeqSt qQaKs6IEIEE6/MLCF380KkY9pPPnFlGy6kzubuHqVC+KcHH/YIfWQNzdEiKDDy6MdQLH8ZRsQRJ S3DXOBC7IOiNp4tLcPWhRoB5nc6r7rOkEBMwaC8eG2v46IjDiviDWykKmqUPi5lz6E9HCcXGYkS lpp6QjwrQF2vOqxwDaaJM6HHig42d+OL2Ii0XEmv1a+Tu5rsPTPUckFfIM20zdqEU3lcYPrGlsP 0rmKNvKdeoVW+3a81fFjRo54JQuzhZMt+Zfdcb7sieaw== X-Zone-Loop: 2f1f84e66bf37622d31664c0a06eb0f193a3bf29d8f7 x-campaign-type: default x-transaction-id: be42124a-acd3-4fef-9e54-bc1fcc079db6 x-swg-uid: 01-a3722898-8a08-4085-ba51-b4e43c3a2e7e X-Mailer: Sweego Message-ID: <1792658248.8631fc262581453bbf619ec5b2062170.1a162c2110b000f79f@vates.tech> x-swg-bid: 1792658248.8631fc262581453bbf619ec5b2062170.1a162c2110b000f79f 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Julian Vetter Subject: [PATCH v2 0/1] tools/ocaml: implement stub_xc_domain_create() for ARM Date: Thu, 22 Oct 2026 10:37:20 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.e9.f888f7cddc1920eb.1a162c20de0.d05f59c1a13ac16d=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792658247140 X-purgate-ID: tlsNG-33051d/1792658250-6C6DE4E9-5C76269A/0/0 X-purgate-type: clean X-purgate-size: 1388 ---=Part.e9.f888f7cddc1920eb.1a162c20de0.d05f59c1a13ac16d=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Andrew, thank you for your feedback! I have addressed your two comments about the OCaml types=2E > type xen_arm_arch_domainconfig contains clock_frequency: int32; but > you've just removed that from the hypercall=2E > > I suggest that we use the fact that this hypercall doesn't work on ARM > at all to allow a minor breakage to remove that too=2E It will want to b= e > a prerequisite to this patch=2E I'm not sure I fully understand what you mean here=2E The removal of the clock_frequency from the hypercall (and from the OCaml side) is already in staging with my earlier patch series (commit: baaa185201 "xen/arm: report clock_frequency via sysctl physinfo, not createdomain")=2E So, xen_arm_arch_domainconfig already only has gic_version and nr_spis=2E Is this what you mean? Andrii Sultanov (1): tools/ocaml: implement stub_xc_domain_create() for ARM tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.e9.f888f7cddc1920eb.1a162c20de0.d05f59c1a13ac16d=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 08:40:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 08:40:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457871.1670377 (Exim 4.92) (envelope-from ) id 1xJoLS-0000Lt-WF; Thu, 22 Oct 2026 08:40:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457871.1670377; Thu, 22 Oct 2026 08:40: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 1xJoLS-0000Lm-TU; Thu, 22 Oct 2026 08:40:18 +0000 Received: by outflank-mailman (input) for mailman id 1457871; Thu, 22 Oct 2026 08:40:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJoLR-0000Lg-N5 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 08:40:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJoLQ-0067Xm-Sv for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 10:40:16 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9cbee-8faa-0a2a0a5109dd-0a2a4503ca14-10 for ; Thu, 22 Oct 2026 10:40: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 6ad9cbf0-fae8-0a2a45030019-b9ff1c22b46f-3 for ; Thu, 22 Oct 2026 10:40: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 1a162c493a1000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 08:40:12 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 9468881AD1; Thu, 22 Oct 2026 10:40: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=VNulx1bCrzh3vCxQgjHzJKXhADx3kPT4J+dx0mPyvrk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=T5u+tLMcutQbUyz/3RzVCeK6aH83ijK1+ywdqLWfALK3HOy8XkAoM7EfuT1I7Qk0kzwXx1xaP tZwST/AxyLlwtJRk9+vlquLNhPcMBp/tlqcxQhJeGGGx4TQVmC3/+JO2vJqlMglNj5m7WKMaqNc tyJ93RQMCuGJDsYUk7sKaNPuyRXbPbxgBq3N2agOHgRLu4Y6rtQ0H7VnKZI0E0Ow7LYw3l9g5bP 0sk+yn60Co43NfHpwXEQ47rWe0WrtEBD3anMa0qkCVIUQ4qexa4QhtVj2Y4QxQlxYc+8tLImObz fhfgLzG33+hE2UOIVQE2RNlZHIuWkWRl8DunFfQuDjrQ== X-Zone-Loop: 5d41ae2aaa3941fc047d6f4a1b62fcbdcf1f5a2f86b6 x-campaign-type: default x-transaction-id: 376ad652-e5a2-433e-af6f-165e3bdeaf6f x-swg-uid: 01-89d541bb-a469-4923-98b6-66337ef28a97 X-Mailer: Sweego Message-ID: <1792658412.8631fc262581453bbf619ec5b2062170.1a162c493a1000f79f@vates.tech> x-swg-bid: 1792658412.8631fc262581453bbf619ec5b2062170.1a162c493a1000f79f 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Julian Vetter Subject: [PATCH v2 1/1] tools/ocaml: implement stub_xc_domain_create() for ARM Date: Thu, 22 Oct 2026 10:40:06 +0200 In-Reply-To: <1792658248.8631fc262581453bbf619ec5b2062170.1a162c2110b000f79f@vates.tech> References: <1792658248.8631fc262581453bbf619ec5b2062170.1a162c2110b000f79f@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.ea.1ddfb3026dc806c1.1a162c4919c.2982aacf828e1b70=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792658411933 X-purgate-ID: tlsNG-33051d/1792658416-6DED24E9-D503E236/0/0 X-purgate-type: clean X-purgate-size: 2831 ---=Part.ea.1ddfb3026dc806c1.1a162c4919c.2982aacf828e1b70=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andrii Sultanov stub_xc_domain_create() fails unconditionally with "Unhandled: ARM" for the ARM variant of arch_domainconfig, so no OCaml toolstack (e=2Eg=2E xenopsd) can create an ARM domain=2E To fix this, convert the two fields of xen_arm_arch_domainconfig, gic_version and nr_spis, into the corresponding fields of struct xen_arch_domainconfig and reject values that do not fit, as is already done for other parameters=2E The remaining fields (sve_vl, tee_type, arm_sci_type and v8r_el1_msa) aren't exposed to OCaml yet, so they stay zero=2E Also add a BUILD_BUG_ON() on the size of the createdomain struct, just like the x86 case, to catch future ABI changes=2E Signed-off-by: Andrii Sultanov Signed-off-by: Julian Vetter --- Changes in v2: - Reduce comment to just /* ARM */ - Use narrow types with Long_val() to detect truncation --- tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index 180f2fbf45=2E=2Ec15a3428da 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -257,8 +257,34 @@ CAMLprim value stub_xc_domain_create(value xch_val, v= alue wanted_domid, value co arch_domconfig =3D Field(VAL_ARCH, 0); switch ( Tag_val(VAL_ARCH) ) { - case 0: /* ARM - nothing to do */ + case 0: /* ARM */ +#if defined(__arm__) || defined(__aarch64__) + { + /* Quick & dirty check for ABI changes=2E */ + BUILD_BUG_ON(sizeof(cfg) !=3D 72); + + /* Mnemonics for the named fields inside xen_arm_arch_domainconfig */ +#define VAL_GIC_VERSION Field(arch_domconfig, 0) +#define VAL_NR_SPIS Field(arch_domconfig, 1) + + uint8_t gic_version =3D Long_val(VAL_GIC_VERSION); + uint32_t nr_spis =3D Long_val(VAL_NR_SPIS); + + if ( gic_version !=3D Long_val(VAL_GIC_VERSION) ) + caml_invalid_argument("gic_version"); + + if ( nr_spis !=3D Long_val(VAL_NR_SPIS) ) + caml_invalid_argument("nr_spis"); + + cfg=2Earch=2Egic_version =3D gic_version; + cfg=2Earch=2Enr_spis =3D nr_spis; + +#undef VAL_NR_SPIS +#undef VAL_GIC_VERSION + } +#else caml_failwith("Unhandled: ARM"); +#endif break; =20 case 1: /* X86 - emulation flags in the block */ --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.ea.1ddfb3026dc806c1.1a162c4919c.2982aacf828e1b70=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 09:07:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 09:07:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457884.1670385 (Exim 4.92) (envelope-from ) id 1xJolW-0003mD-Th; Thu, 22 Oct 2026 09:07:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457884.1670385; Thu, 22 Oct 2026 09: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 1xJolW-0003m6-Qs; Thu, 22 Oct 2026 09:07:14 +0000 Received: by outflank-mailman (input) for mailman id 1457884; Thu, 22 Oct 2026 09:07:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJolV-0003m0-RS for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 09:07:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJolU-001gS8-Q2 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 11:07:12 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9d235-2eae-0a2a0a5409dd-0a2a450683b0-42 for ; Thu, 22 Oct 2026 11:07:12 +0200 Received: from [40.93.201.46] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad9d23e-195a-0a2a45060019-285dc92e1bf8-3 for ; Thu, 22 Oct 2026 11:07:12 +0200 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by BY5PR03MB4983.namprd03.prod.outlook.com (2603:10b6:a03:1e3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Thu, 22 Oct 2026 09:07:09 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%4]) with mapi id 15.21.0522.016; Thu, 22 Oct 2026 09:07: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=yCEoVYhJ4o1DmIXLO7OGC6SsKpjneRfw0ybrF7zZURKtdEu0sWq/lp/2HkzJIjC3O+wfYaMvEFBfGTzoo1FeumOpC0MqHlO5yXgJ4wu4Ls2n7d47MCA1q72MWnmI+n3puyIW+Ukn745xmOd1TCLrw3NHJ/6vc851N4LsREohTb0c5cPnKx3myMPsNay2NpQcjLCT8rfd2TLdC5XwU/kSxxGkP2AU+z5XvttV4jiGfvWv4/qZi1Wm6v1U5vcqchSKHkUGgGk+eNYDmFGIknxfHRuuoOflPngM8Cp8BT6Jek0gebv3zZQfCJ74gd8OwHOQkiR+5MCJU1a1/ldx0k3JHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cVJ9QDL7TJ6xYiY9YpmuP2JzHHKsIqxTUFhVhiztq4Q=; b=L3OsvMgSZZBKvSbiVR07VxkKnM9SRUOOx2LgvNPd5VqzKIjUa26Y//OXuSe4RVgGxX5lbZ/J6vgkfkzXt/USprITCogPP+nis4chQ2Ob1WlAjoGJH+WQ/b+F72tmdp5vu7clg/OoXGZOuv6f7CI2rE9Kxd+yWcypEDwy91xepZGXVwE+nlJs89B0HGQS5uNlBQvJaGpBjV67n3HYThR/aUemm1ww0wwbhOsENvZTl6ZY/hFsWRe1yWi2ttJWltOSuSsK1B1CRfxAxHozYRgbKkXpxz9APGWSwbsyuTCfRtRvolooJtKhgwhkSBybonBcg7gygTMWeVbbDbUDRtbqrw== 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=cVJ9QDL7TJ6xYiY9YpmuP2JzHHKsIqxTUFhVhiztq4Q=; b=cima7LJhM5uqVqp3GkuW539dI5/6u4HFCNu32T8E3iUyzCJvHDsZsJvqgNwO9sFvswUbIe2nWZHhj3a1GaHvBeI6lflWRyGw0mzn+IAgoHiiACzT7D4pIfByOZVtfALp9i2qtSdiaRf0UAZhffR5DKq/r3BWRPt6z7IM9ZuBJpw= Authentication-Results: mx.microsoft.com 1; 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 , Chunjie Zhu Subject: [PATCH] x86/nestedsvm: Record NextRIP with the deferred #VMEXIT Date: Thu, 22 Oct 2026 17:06:57 +0800 Message-ID: <20261022090658.151682-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU0P306CA0023.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:16::18) To CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR03MB7889:EE_|BY5PR03MB4983:EE_ X-MS-Office365-Filtering-Correlation-Id: 52648f1c-e365-487b-8ea7-08df301bd9ae X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|261021123027099003|11063799006|56012099006|261009223027099003|261021121427099003|10067099003|18002099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: f25MBzOm/0yirUGVbRHO0Tllt11aJtoHKb94X6H3ijAPi2Z3n1A1T/HKYY+2kmQkaR5L5FrTEgCcGjk+eczlD4PKFOlqlTr343Eo+ii5c2+MxLG4FqioSMdv6L08ABHi0jevXj0k8T8L9GFJAy8cHp+rtDhk5wvwx83AdfvQ2G/UFhaUFN4dOmfo+mCVF1LDk7pTSaQkJaMb9WSgy1jPe4eWNB37cNABrAF+dBwmdxLxM8x11T//mrjgIKmy4S/Gtt1iGHK2eNlpLCyzqNsjGSfeieDNVAiGkwCmap7vj5fjfkJb3m2pIPzXq7ToWZa66Kuel600ACTqvTLzFhCSIiYNYTd9n8hX1Kfp92p4nVA2DH+k+9TYR1YirMLaQ8kWNqdTtBghAl2MJdziFXjczbM5JyjTPWooHIt3gD0+oAd6jWZaPq+gslvpgfw6aUduFfDsNUDyfiy/TgfEK4A6gWsf/owlQXyqqk4GIE8hFYDNott5X1JgXMrnQ7hSQZXLf4OQ05l3kG9t1fABBqX1QgNbD4ohQm24e92S45ErIQHrcKFdLxO7jsGRBxoBZvH7CEjeG4z86sxxHild+d3GTdEyZLApreujLBwPzkIBhGwlYVyPfQzfhQqvV1bPi1hYwyMrmQJIQ4wp9Wj/+Hc0vSdJNfCeJzbLtSJ2VlqxKZc= 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)(1800799024)(366016)(261021123027099003)(11063799006)(56012099006)(261009223027099003)(261021121427099003)(10067099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Ll3s95mIM+6yIq118qMJPOjmbPG7O64Tl0/8RYMIi2DuI1tJnoKuM67qzxmK?= =?us-ascii?Q?zdynSCE9JkRsQpfFjvRSQuJ99YRjI/hY0FvVXGmBU14nE/vvudTC6OpBYbrx?= =?us-ascii?Q?F88bJMJ1pmNMoOS5teP8wKqRHgAXCrPSNSsOovVtJiuvh/WaHosK2XoOIUZd?= =?us-ascii?Q?ExaYmMPaP94/rnaVkCdG3bE3+A++gofrJ6ixSPT25JVgzP307p88uzQ1cGd8?= =?us-ascii?Q?LFvnFJXOeHGCq82hqU/bKuqHSH+DY+FvY8/RZZVy5H4eMYIJyJ03SJUPXIZ+?= =?us-ascii?Q?y2sbbO1URDhJlx2wshXh+d57GYqJHMx32f2aojIpxaTi+lS3p+F/PF6Ja6QQ?= =?us-ascii?Q?jSV2+VRxMuIzgqaJhegG0wHQA9N+yNvOkN9ier2PPwF1wWVfjepymt7jVqCO?= =?us-ascii?Q?wZH9oK9z3lDZyRvmCTrPukRFOZBthsZaRmyDC9+QwEYX15R1WDSZPKdET6cJ?= =?us-ascii?Q?w9Tw1qtf6LUTWNRLPLkTMUEOY9k3ZO2gxb5BvY7DhOmiqvxOi5QjM99eaGfw?= =?us-ascii?Q?w26gv5CQqUY7Gl77PVGi+KyWxZwIoSoFuw7OHUEbLTZDBpzewDqBqMwoyQ2r?= =?us-ascii?Q?KxltZnyEuOLdmkyWaUk5RFh+fz3ZaOhhj6NdI+cxv+t3efkc1ozYQY+oVvSz?= =?us-ascii?Q?NiP50Ppujc8JSaTWlCzenOUFsGpAcz5znfhhnCDTlCp+Lzp0PFx0DKmuFTHz?= =?us-ascii?Q?EYnoJ97SkqcP9aTbR+VHruannBoLqjK+8JZRNtkUZlc6+h1oRIIPG2yTXmOw?= =?us-ascii?Q?rIASFjg3Y+xC3JYWRdyLEc7bk1PJM9e7xOfUyNZraXCFKO2bSz2DP2jfk7F8?= =?us-ascii?Q?T1z7YgSULXcU+defzXsd0NXwu9YCrl4dGcIZi8JwAkg9cqIljxtXzRQsOC85?= =?us-ascii?Q?yZeSGMjpX+pN+N2hDcQTP38JitCdocrfi0xqRyMdq4ARnIjQ+UHi+F8RXceX?= =?us-ascii?Q?z7Q5QmiPDBssuKaDVuyFvhal0NqDjB1B1RlSiXLp2FgchiBeBvSdN5VZ02rF?= =?us-ascii?Q?ARqXF2wnGAoqYXDUjNXuYn0C+Vmh/MmpgouZjhMjTaz1Umma1QsSDsCl9/Pu?= =?us-ascii?Q?rEj6om3nABxSvmMGReq4cHLCg8F8XCS49FfriZLeGP66EHw8M0492yt2iWcT?= =?us-ascii?Q?xHoUJ7O0eVnkOZ308aNi3AywtR+T1sNbbUi+GixnHO7soxASONDUOH5zoecF?= =?us-ascii?Q?lpe6NXJgw+TLbKtuA3O7S7wZBCBwPQ685Et5Sb4R2ER+ff8z30YK0yP4Ejcu?= =?us-ascii?Q?4xrXSQazF4Z5pZWFd2DGDDzf1iy4r8l5RjTFXwKDsER9hLX5rzieqaNZpOPz?= =?us-ascii?Q?jf5zDh+oU7saw/m84XzziIK3HQlRRH3tn46jEkw9YUQHs+dX2mn4WK8TDUV6?= =?us-ascii?Q?mkiY3drYGuE1QN4Ho2wUdci/03GBerWbXyfHIRkU7qZWRppcgloKEwBQmoMe?= =?us-ascii?Q?yc7C0k4wuFDibNjoW3Dw3hOw0ybRCfFU7VvXVvYAo7l+pRlj8zTi2R9nQ5vZ?= =?us-ascii?Q?sbKxuVF64HydEDWGQ27/y5Bqs7LmUQJcTLnWSjj4vEaHANnw/CIDUnHfUgGi?= =?us-ascii?Q?KKUmkcQYexQne9aZi7bTeyYyGZ3tNr+YrYgLWRIS3SqN13qZgT4bsM/JyUvy?= =?us-ascii?Q?dvOD8V+0cJVdZ6skyT9P2XuyI8Tslevr0yydHO/JtrFVSqhKb3oRKJeCbLV0?= =?us-ascii?Q?cmOxxiLg5R5XqLpSsRathKNtJIV6h6eCC6MPsz393TUcdZJ6B3RfL8WkIVRj?= =?us-ascii?Q?guWqRs0pcA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52648f1c-e365-487b-8ea7-08df301bd9ae X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2026 09:07:08.6133 (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: qvpXzBZakVnBD6R8MB03/KpPhNGdhUKmJg8AE9CXkd/+n2uElKNs8Dpihbz3ezT9ijyLZLdI1tU7uSZsAYwgy5W9EW99RwVKzUmvJMAU5lI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB4983 X-purgate-ID: tlsNG-16d1c6/1792660032-F4C0777B-E5274423/0/0 X-purgate-type: clean X-purgate-size: 9150 nsvm_vmcb_prepare4vmexit() copies NextRIP from the hardware #VMEXIT, but L0 also delivers #VMEXITs it creates itself, for which that value belongs to a different exit. Such a #VMEXIT saves no nRIP (AMD64 APM vol 2, publication 24593 rev 3.44, section 15.7.1). For example: 1. L1 intercepts #GP but not MSR accesses. 2. L2 executes RDMSR of an MSR which Xen doesn't implement. 3. Hardware exits to L0 with VMEXIT_MSR and NextRIP after the RDMSR. 4. L0 handles the RDMSR itself and injects #GP into L2. 5. L1 intercepts #GP, so L0 delivers VMEXIT_EXCP_GP to L1. 6. L1 sees NextRIP after the RDMSR, instead of 0. Record NextRIP in ns_vmexit alongside the exitcode and exitinfo, and have each source of a #VMEXIT supply it: the hardware value for a reflected #VMEXIT, the next RIP for an INT3/INTO which L0 emulated, and zero for everything else, including a failed VMRUN. Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Signed-off-by: Stephen Cheng Assisted-by: Claude:claude-opus-5-5 --- Found with a nested-SVM XTF test, not yet upstream. This is the #VMEXIT counterpart of commit 9d6b6e4f7394 ("x86/svm: Sync nextrip during virtual VMRUN"). BOUND's #BR is raised by the emulator as a plain hardware exception without an instruction length, so it still reports 0 rather than the next RIP. Chunjie's "x86/nestedsvm: rework nested VMRUN/VMEXIT handling" series also changes nestedsvm_vmexit_defer() and nsvm_vcpu_vmexit_inject(); under it NextRIP would become one more value passed alongside exitinfo1/2. I'm happy to rebase on top of it, or the other way round, whichever merge order is preferred. xen/arch/x86/hvm/svm/nestedhvm.h | 3 ++- xen/arch/x86/hvm/svm/nestedsvm.c | 32 ++++++++++++++++++++---- xen/arch/x86/hvm/svm/svm.c | 8 +++--- xen/arch/x86/include/asm/hvm/svm-types.h | 1 + 4 files changed, 35 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedhvm.h b/xen/arch/x86/hvm/svm/nestedhvm.h index 9bb04a0434..963390e8a9 100644 --- a/xen/arch/x86/hvm/svm/nestedhvm.h +++ b/xen/arch/x86/hvm/svm/nestedhvm.h @@ -28,7 +28,8 @@ int nestedsvm_vmcb_map(struct vcpu *v, uint64_t vmcbaddr); void nestedsvm_vmexit_defer(struct vcpu *v, - uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2); + uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2, + uint64_t nextrip); enum nestedhvm_vmexits nestedsvm_vmexit_n2n1(struct vcpu *v, struct cpu_user_regs *regs); enum nestedhvm_vmexits diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 2b998e26bc..241912e1ad 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -154,6 +154,7 @@ int cf_check nsvm_vcpu_reset(struct vcpu *v) svm->ns_hostflags.bytes = 0; svm->ns_vmexit.exitinfo1 = 0; svm->ns_vmexit.exitinfo2 = 0; + svm->ns_vmexit.nextrip = 0; svm->ns_iomap = NULL; @@ -696,6 +697,7 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( inst_len == 0 ) { svm->ns_vmexit.exitcode = VMEXIT_SHUTDOWN; + svm->ns_vmexit.nextrip = 0; return -1; } @@ -717,6 +719,7 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct cpu_user_regs *regs) case NSVM_ERROR_VVMCB: gdprintk(XENLOG_ERR, "inject VMEXIT(INVALID)\n"); svm->ns_vmexit.exitcode = VMEXIT_INVALID; + svm->ns_vmexit.nextrip = 0; return -1; case NSVM_ERROR_VMENTRY: default: @@ -782,6 +785,7 @@ nsvm_vcpu_vmexit_inject(struct vcpu *v, struct cpu_user_regs *regs, } ns_vmcb->exitcode = exitcode; + ns_vmcb->nextrip = svm->ns_vmexit.nextrip; ns_vmcb->event_inj.raw = 0; return 0; } @@ -789,10 +793,26 @@ 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) { + const struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + uint64_t nextrip = 0; + ASSERT(vcpu_nestedhvm(v).nv_vvmcx != NULL); + /* + * An exception intercept saves NextRIP only for INT3, INTO and BOUND + * (AMD APM vol 2 rev 3.44, 15.7.1). The emulator raises BOUND's #BR as + * a plain hardware exception, so only INT3/INTO can be recognised here. + * As in svm_inject_event(), truncate it outside of 64bit mode. + */ + if ( event->type == X86_ET_SW_EXC ) + { + nextrip = guest_cpu_user_regs()->rip + event->insn_len; + if ( !((vmcb_get_efer(vmcb) & EFER_LMA) && vmcb->cs.l) ) + nextrip = (uint32_t)nextrip; + } + nestedsvm_vmexit_defer(v, VMEXIT_EXCEPTION_DE + event->vector, - event->error_code, event->data); + event->error_code, event->data, nextrip); return NESTEDHVM_VMEXIT_DONE; } @@ -1063,8 +1083,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* LBR virtualization - keep lbr control as is */ - /* NextRIP */ - ns_vmcb->nextrip = n2vmcb->nextrip; + /* NextRIP is set by nsvm_vcpu_vmexit_inject(). */ /* Decode Assist */ ns_vmcb->guest_ins_len = n2vmcb->guest_ins_len; @@ -1219,7 +1238,8 @@ enum hvm_intblk cf_check nsvm_intr_blocked(struct vcpu *v) /* VMEXIT emulation */ void nestedsvm_vmexit_defer(struct vcpu *v, - uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2) + uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2, + uint64_t nextrip) { struct nestedsvm *svm = &vcpu_nestedsvm(v); struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; @@ -1232,6 +1252,7 @@ nestedsvm_vmexit_defer(struct vcpu *v, svm->ns_vmexit.exitcode = exitcode; svm->ns_vmexit.exitinfo1 = exitinfo1; svm->ns_vmexit.exitinfo2 = exitinfo2; + svm->ns_vmexit.nextrip = nextrip; vcpu_nestedhvm(v).nv_vmexit_pending = 1; } @@ -1359,6 +1380,7 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, case NESTEDHVM_VMEXIT_ERROR: exitcode = VMEXIT_INVALID; + vcpu_nestedsvm(v).ns_vmexit.nextrip = 0; break; default: ASSERT(!nestedhvm_vcpu_in_guestmode(v)); @@ -1478,7 +1500,7 @@ 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); + nestedsvm_vmexit_defer(v, exitcode, intack.source, exitinfo2, 0); return NSVM_INTR_FORCEVMEXIT; } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f2..cf9e3ef1ab 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1618,7 +1618,7 @@ 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); + nestedsvm_vmexit_defer(v, VMEXIT_NPF, pfec, gpa, 0); return; } @@ -2556,7 +2556,7 @@ void asmlinkage svm_vmexit_handler(void) enum nestedhvm_vmexits nsret; struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; - uint64_t exitinfo1, exitinfo2; + uint64_t exitinfo1, exitinfo2, nextrip; paging_update_nestedmode(v); @@ -2581,6 +2581,7 @@ void asmlinkage svm_vmexit_handler(void) */ exitinfo1 = vmcb->exitinfo1; exitinfo2 = vmcb->exitinfo2; + nextrip = vmcb->nextrip; nv->nv_vmswitch_in_progress = 1; nsret = nestedsvm_vmexit_n2n1(v, regs); nv->nv_vmswitch_in_progress = 0; @@ -2588,7 +2589,8 @@ void asmlinkage svm_vmexit_handler(void) { case NESTEDHVM_VMEXIT_DONE: /* defer VMEXIT injection */ - nestedsvm_vmexit_defer(v, exit_reason, exitinfo1, exitinfo2); + nestedsvm_vmexit_defer(v, exit_reason, exitinfo1, exitinfo2, + nextrip); 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 beab9a3af2..fafbd646cc 100644 --- a/xen/arch/x86/include/asm/hvm/svm-types.h +++ b/xen/arch/x86/include/asm/hvm/svm-types.h @@ -74,6 +74,7 @@ struct nestedsvm { 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 */ + uint64_t nextrip; /* NextRIP to report to the l1 guest */ } ns_vmexit; union { -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 22 09:54:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 09:54:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457903.1670395 (Exim 4.92) (envelope-from ) id 1xJpV3-0002jc-Vf; Thu, 22 Oct 2026 09:54:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457903.1670395; Thu, 22 Oct 2026 09: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 1xJpV3-0002jV-Sf; Thu, 22 Oct 2026 09:54:17 +0000 Received: by outflank-mailman (input) for mailman id 1457903; Thu, 22 Oct 2026 09:54:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJpV2-0002jP-LN for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 09:54:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJpV2-006QHY-1y for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 11:54:16 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9dd45-e002-0a2a0a5209dd-0a2a4508c128-10 for ; Thu, 22 Oct 2026 11:54:16 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad9dd47-f659-0a2a45080019-d1558031bcbb-3 for ; Thu, 22 Oct 2026 11:54:15 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a20803a757so2140715e9.0 for ; Thu, 22 Oct 2026 02:54:15 -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-4a203b3a4eesm54187115e9.7.2026.10.22.02.54.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2026 02:54: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: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=1792662855; x=1793267655; 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=8kP2bh8OLzoj43YL1NHpZyuOIvZ9wkudBB2G5sKl/Fg=; b=NXy8MItjZR7Qn3Ou+OLdKlw2M7sy+lVsiRrOL/F7t9cTfp7oqRHIM/QWbXx3O1+anx 9n4RTUYRDIvhEXXEwweqwp/uy2dnM9Jckq7paRV8NzLaesl9Nyilx+TWI5uFRLTjRsVk gwgTVPXmQny3MH29gOPMPKe2YK8Coybf4sNpVpFKvElnoxeCZJlEfXQ4MOZjWqVArpSe 8TgmW768HHSMAs7As9SiqBpq1GnisdYF2KPHbK1jqBBBzWTqYsnNCEUk5/LNkl2wylLg 5zJQuLOn3P7t80Cp4Ud4koKLpFJ5NjtgrbeAV+ktrhI931aNRR0/26JSSQwYvQEcqG6P ZI1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792662855; x=1793267655; 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=8kP2bh8OLzoj43YL1NHpZyuOIvZ9wkudBB2G5sKl/Fg=; b=MTUCRXP19fG8lnI3ikBUjOMcSjyEeLQ3zAN5R1K6Vv+vTGHk/g3oBYvXlAT6HygRVe jTFrQ+ALvY91qOfNmypnMcjYgS9NE0zhXbnZkE2KTXj7RpBX1s9G79ON1Y2yL8YvKpXd Z7QPrenbo+wFyarZlFHKTnVHBDhTBYWXPaemTRJ36c8fbqiuQk2f5Ya/RqVHgHSJTtWe EJJIyuB4+XCqgUzx3x13wiBkuE07bQcjIfyMmKBkN17hR3SLMi9r5dsMweEuJNpOAbcu AciRE1KzrWwKF8NRL50NnTloW1xdA8dw1mqdKHgAvzeeYZNekoBsk9LDZFU4a/cwp4LH p3rA== X-Forwarded-Encrypted: i=1; AKwUvBwtFs0sjjd0iv7n3orfX6Ri01KrO5vQX1IFNe58cHXGmwwrGoObpaqW6aovKMfa0x/CB1of/cJX6po=@lists.xenproject.org X-Gm-Message-State: AFq9FYLMI0l0ao4M8M9sEQpuSinusiftDB61z30+FRcOZS+vUnE2TWT7 wpvnxTlHFpMpvZwZUlcIkLNN7M6fFQl0+EIVcY2I6un18UiBuNIBv4yH X-Gm-Gg: AYBFou0y/qAOZC3/K/R+cCMU7Ijm6U95MCGOHDpIGHqkqY6hU7fZ6A8gxLv49VT4TMX dcOgcZgDJdHpGE15pN3B/QEGgOP6vekimSyse7Yxeko9sWspihMSwut2sxrRV7udwG5RZGAArD3 OBS8Ck6t1oSVcMl40na28wdJx3Gn7wJ8+oM14doD25OrksH7b2XszJhUdmL4hgFjLIbx+TY9siY GMpwqgqqRkBn8ONQ0xxDNBVhnxaFAmlqWLfuuqSM7n+MdQUTgtaK/dqG/hVDNL4S5CGCVMgCVKJ DrrBVzI4Nu/TDwT0Kr9CGFRYQvEnUgEFyN5osXFPTpFlE2R9EGg6oWJZgNJzf4ftrilrF0lI+1Z YSoXV37+1WbzM7Fkwsoeqe0oSL/IRKkYfrEVoguQ6ZE8n/pDKwRzT5095uN19W7JCj9ihOZHxsM P4u9FHTBpuZOACiLGtQ2oPaYgNn1MhbLs9Cik6RtXxrXwemNQ/eD/cj/t/bYWLvgNSLV8002Bq3 KMf85NKzmMJsp/Y6CvUt1Bc/ypJ2Eserty9dbx/GJ7nOQQfoL/5SAUiFBuaW0tiMi6qpNwkFA9N DV3ATwjOgHskGq9Gi9oN2khZNCgMfWX9fqivwg== X-Received: by 2002:a05:600c:a215:b0:4a1:fcfa:2a07 with SMTP id 5b1f17b1804b1-4a1fdd395bemr65253455e9.30.1792662855163; Thu, 22 Oct 2026 02:54:15 -0700 (PDT) Date: Thu, 22 Oct 2026 10:54:13 +0100 From: David Laight To: Paolo Abeni Cc: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH net-next v2 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags Message-ID: <20261022105413.348a2585@pumpkin> In-Reply-To: <717ace2e-18b2-4df5-848d-5757c01ee5de@redhat.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-1-2aa780a03524@toxicpanda.com> <717ace2e-18b2-4df5-848d-5757c01ee5de@redhat.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-c1860d/1792662855-D7B5987B-ECF939CD/0/0 X-purgate-type: clean X-purgate-size: 6462 On Thu, 22 Oct 2026 10:21:26 +0200 Paolo Abeni wrote: > On 10/21/26 15:46, Josef Bacik wrote: > > skb_copy_and_csum_bits() has no way to fail. When it reaches > > unreadable frags it zero-fills the rest of the buffer and returns 0, > > and since commit ab9414ed70bd ("net: skbuff: don't leave stale bytes in > > skb_copy_and_csum_bits()") that 0 is the correct checksum for what's in > > the buffer. Its callers can't tell the copy didn't happen. > > > > That matters in the !sg && !csum branch of skb_segment(). A devmem TCP > > skb keeps its whole payload in unreadable frags, so every segment ends > > up with a payload of zeroes, tcp_gso_segment() writes a valid TCP > > checksum over it, and the peer accepts the zeroes as stream data. This > > is reachable when both SG and TX checksum offload are turned off on a > > device used for devmem TX: sk_setup_caps() still gives TCP SG and > > HW_CSUM, so the dmabuf send is accepted, validate_xmit_unreadable_skb() > > lets the skb through for a NETMEM_TX_NO_DMA device or a matching > > binding, and software GSO segments it with neither feature. Before > > that commit the segments carried uninitialized memory with a checksum > > that almost never matched. > > > > This was reproduced with a test module rather than on devmem hardware: > > skb_segment() on a TCPv4 GSO skb with 3000 bytes of payload in a page > > frag marked unreadable, with features == 0, returns 3 segments whose > > payloads are all zeroes, each with a checksum of 0, which is correct for > > zeroes. There's no warning or error; the data is silently replaced. > > With this patch skb_segment() returns -EFAULT. > > > > Make skb_copy_and_csum_bits() return 0 or -EFAULT and hand the checksum > > back through a pointer, and make it __must_check so a new caller can't > > ignore the failure. Running out of skb before @len returns -EFAULT > > too; commit 417261779eab ("net: skbuff: don't BUG() on leftover length > > in skb_copy_and_csum_bits()") made that a zero-fill and a checksum of 0. > > Each caller takes the error path it already has for a failed copy: > > > > - skb_segment() fails the segmentation, as the csum branch already > > does when skb_copy_bits() fails. > > - icmp_glue_bits() and icmpv6_getfrag() return the error, so the ICMP > > error isn't sent. > > - __ip_append_data() and __ip6_append_data() drop the new skb and > > return -EFAULT, as they do when getfrag fails. > > - vnet_skb_shape() fails the same way it does when its skb_copy_bits() > > call fails. > > - xdr_skb_read_bits() returns 0 without consuming anything, as it does > > when skb_copy_bits() fails, so desc.count stays non-zero and > > csum_partial_copy_to_xdr() fails. csum_partial_copy_to_xdr() used > > to checksum the bytes it hadn't copied before checking desc.count. > > desc.offset and desc.count always add up to skb->len, so that only > > ran when it was about to fail anyway, and on an unreadable skb > > skb_checksum() would WARN. Drop it. > > - skb_copy_and_csum_dev() can't return an error, so it leaves the > > checksum alone and the frame goes out with a bad one. Its callers > > are drivers that never see unreadable skbs anyway. > > > > The zero-fill stays, so a caller that does send the buffer still > > doesn't leak anything. > > > > This was found by the Sashiko AI review of that commit, and > > Mina suggested reporting the error from the helper rather than checking > > for unreadable frags in skb_segment(). > > > > Link: https://lore.kernel.org/all/179148235783.434549.14322374227477832817@kernel.org/ > > Suggested-by: Mina Almasry > > Reviewed-by: Mina Almasry > > Assisted-by: LLM > > Signed-off-by: Josef Bacik > > --- > > drivers/net/ethernet/sun/sunvnet_common.c | 10 +++-- > > include/linux/skbuff.h | 4 +- > > net/core/skbuff.c | 63 +++++++++++++++++++++---------- > > net/ipv4/icmp.c | 9 +++-- > > net/ipv4/ip_output.c | 11 ++++-- > > net/ipv6/icmp.c | 7 +++- > > net/ipv6/ip6_output.c | 11 ++++-- > > net/sunrpc/socklib.c | 9 ++--- > > 8 files changed, 83 insertions(+), 41 deletions(-) > > > > diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c > > index 5cca95869052..4f229fcecc32 100644 > > --- a/drivers/net/ethernet/sun/sunvnet_common.c > > +++ b/drivers/net/ethernet/sun/sunvnet_common.c > > @@ -1167,9 +1167,13 @@ static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, int ncookies) > > > > /* copy the rest, with csum calculation */ > > *(__sum16 *)(skb->data + offset) = 0; > > - csum = skb_copy_and_csum_bits(skb, start, > > - nskb->data + start, > > - skb->len - start); > > + if (skb_copy_and_csum_bits(skb, start, > > + nskb->data + start, > > + skb->len - start, &csum)) { > > Recently Eric did some work to remove return arguments from the fast-path, > as with some config it gives measurable overhead. See commit > a02a765bd5c2ae7705144829b2911c96c29db6ba. And, as soon as you take &csum, not only does the value have to get re-read from stack, but the compiles has to assume that the address might have been saved and can be updated by any other function call. > > S/W csum should not be the fastest path, but AFAICS the UDP output path > could use it when building the aggregate segments. > > I'm wondering using a 64 bit return value and encoding there both the csum > and the error could make sense. That gets really horrid especially on 32bit. That is why I suggested earlier that since csum values 0 and ~0 are equivalent one of the two values could be used as an error result. An 'adc loop' won't normally generate zero, but there might be some code that relies on it - so would need changing before zero could be used as an error return value. David > > Also currently net-next is closed for the merge window, and a bunch of > changes in this series looks more like cleanup than fixes. Cleanup will have > to wait for the end of the merge window, fixes can land at any time. > > /P > From xen-devel-bounces@lists.xenproject.org Thu Oct 22 10:03:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 10:03:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457909.1670404 (Exim 4.92) (envelope-from ) id 1xJpdd-0004kw-Rg; Thu, 22 Oct 2026 10:03:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457909.1670404; Thu, 22 Oct 2026 10: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 1xJpdd-0004kp-OZ; Thu, 22 Oct 2026 10:03:09 +0000 Received: by outflank-mailman (input) for mailman id 1457909; Thu, 22 Oct 2026 10:03:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJpdc-0004kj-DZ for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 10:03:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJpdb-001rMh-Ca for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 12:03:07 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9df52-e002-0a2a0a5209dd-0a2a45048ca4-20 for ; Thu, 22 Oct 2026 12:03:07 +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 6ad9df5a-b57f-0a2a45040019-b9ff1c23992b-3 for ; Thu, 22 Oct 2026 12:03: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 1a1631070d2000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 10:03:04 +0000 Received: from [192.168.1.52] (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 6B2F782A69; Thu, 22 Oct 2026 12:03: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=zvJyISb3vQPGxR0euKap2XzAGC99LFUzb/+MkPMMVSE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=OVQOXxNNBdVLPAvdnRu3nD+BJ9Jd7XnZxM+v2UAg7Dt9eeyhjF5FfvuWI7H1zuYUTd0UaIgFW 8R4jY2m/il7j1GZkpdLE6NUfBhSmzTh255KasI2GmjipVFYtmNDWBrbYyQd+hAXtSlz3+NbvoXe 7hPo96RdDgHksoMakiG/W5q6MN2F6kg4ZCfWKjai9Ok2YleALx3DfBPCOF4OLPvREiLX8ai7VAQ TUoJ91m4ihR07ztc8gkJjVnsSiGxptxffLurCmpglVWN23btrSi05dhXhTi38bgGExLw4gyi0kK FJUNW5twEf8LjElm8JQxe5IXNFcbuwZ87LiXrVSfkJFw== X-Zone-Loop: 125ba5c40f642d550407dd08563c999a887ad97e01b4 x-campaign-type: default x-transaction-id: eb10ec8c-ce5b-4b42-a884-5a4de46444a3 x-swg-uid: 01-7298593e-0748-4585-a225-2d1a8543f0e5 X-Mailer: Sweego Message-ID: <1792663384.8631fc262581453bbf619ec5b2062170.1a1631070d2000f79f@vates.tech> x-swg-bid: 1792663384.8631fc262581453bbf619ec5b2062170.1a1631070d2000f79f 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 v3 23/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: References: Date: Thu, 22 Oct 2026 12:02:56 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792663378; l=11215; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=YwM1/YgJS/BtHyk/eh3362ee3qawZVAF/HQVBtLs7Nw=; b=d3n7waXknbdn2v946DBgLeyMZtnsmwkOgf8oi+Xu9ZAzwoOsZVQbhhGnXUNWRx4jziyY/h+mP GPAccm81NOaA2T+64NyRWKEjD/LTJ259ikyTv4IQcvJSXeRjOoLR6nC 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: 1792663383647 X-purgate-ID: tlsNG-ebf023/1792663387-C22D4B50-9FF4F2C3/10/73395122804 X-purgate-type: spam X-purgate-size: 11215 > 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(), together > with the XLEN_FIELD_*, INSN_OPCODE_* and RV_RD()/RV_RS2() definitions > they need. > > Nothing calls any of this yet, so reference the functions from the > emulate_load() stub to keep the build going; the references go away once > emulate_load() gains its body later. > > Signed-off-by: Oleksii Kurochko > --- > How these helpers are used can be seen in the patches adding emulate_load() > and emulate_store(). Appreciate this precision, thanks! > [ ... 116 lines skipped ... ] > +/* > + * 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. Reading "it also gives the width of vsstatus itself", one might understand that VSXL equals UXL in all cases, while, as you mentioned, this only holds when VSXL says 32. I would slightly reword it, e.g.: ``` VSXL is consulted whichever mode the trap came from: if VSXL says 32, vsstatus has no UXL field, so VU-mode is 32-bit as well and there is 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 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); xl only ever holds a 2-bit field, so unsigned int would be better here. > [ ... 49 lines skipped ... ] > +static unsigned long *guest_gpr(struct cpu_user_regs *regs, > + const struct decoded_insn *di) > +{ > + /* > + * decode_ldst_insn() is what fills @di in, and it rejects an access > + * wider than a guest register. > + */ > + ASSERT(di->len <= (guest_xlen(regs) / BITS_PER_BYTE)); Nit: the parentheses around the division aren't needed. > [ ... 14 lines skipped ... ] > +static bool 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)); > + > + /* > + * Bit[0] == 1 implies trapped instruction value is transformed instruction > + * or custom value. A transformed instruction is a 32-bit encoding, so a > + * value with any bit above bit[31] set is a custom one, which is of no use > + * for decoding: fetch the instruction from guest memory then, as for zero. > + */ > + if ( (htinst & BIT(0, UL)) && (htinst == (uint32_t)htinst) ) > + { > + /* > + * 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() decodes. Its handling of > + * compressed encodings exists 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 have it decoded as such. Reading this, I first understood that something had to be done to recover the original compressed opcode. "Restoring the opcode bits" suggests going back to the trapped encoding, while it is only setting bits[1:0] to 0b11 of an already expanded instruction. Maybe say that first, e.g.: ``` /* * A compressed instruction is reported already expanded to its * 32-bit equivalent by the hardware, so htinst always holds a * 32-bit encoding, apart from bits[1:0] which is holding a marker: * bit[0] is set to flag the transformation and bit[1] is clear if * the trapped instruction was compressed. Setting both bits gives * the original 32-bit encoding for decode_ldst_insn(). */ ``` > + * > + * 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 | 3; > + 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 (or a > + * custom value, see above) is left: the instruction has to be read from > + * guest memory. Nit: as the assert would disappears in release build, this comment is partially true. I would suggest something like: ``` * Bit[0] == 0 implies trapped instruction value is zero or * special value. With the pseudoinstructions ruled out (see * comment above) only zero (or a custom value, see above) is * left: the instruction has to be read from guest memory. ``` > + */ > + > + di->insn = 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. Typo: "Such faults ... are considered" (plural subject). Also "a fault happen" above should be "a fault happens", and "as bus error" -> "a bus error". Maybe: /* * If a G-stage translation fault happens while fetching the * trapped instruction, CAUSE_LOAD_GUEST_PAGE_FAULT is generated. * Such faults are treated as an access fault. */ I used access fault instead of bus error because the code below sets CAUSE_FETCH_ACCESS which is more like an access fault. > [ ... 54 lines skipped ... ] > +/* > + * 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()). Fields which don't apply to the instruction are left > + * alone, so @di is expected to start out zeroed. > + * > + * @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. Nit: odd wrapping, "the encodings" fits on the line above. > + * > + * Returns false if the instruction is not a load or store which can be > + * emulated here. > Nit: maybe reword for clarity: * Returns false if the instruction is not a load or store, or cannot be * emulated here. > + */ > +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. Very clear thanks. > + */ > + 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) ) > + /* 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); Nit: the RVC branch above says where funct3 lives (bits[15:13]), this one doesn't. Maybe mention bits[14:12] as well, so the reader doesn't wonder why 12 here vs 13 above: ``` /* * LOAD and STORE (I/S-type) have funct3 in bits[14:12]: 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. */ ``` > [ ... 51 lines skipped ... ] > diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h > index b01da95f7e..1af309aa4a 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) Do we really need long here? int wouldn't be enough? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 22 11:42:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 11:42:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457982.1670445 (Exim 4.92) (envelope-from ) id 1xJrBw-0002xh-Us; Thu, 22 Oct 2026 11:42:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457982.1670445; Thu, 22 Oct 2026 11:42: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 1xJrBw-0002xa-RU; Thu, 22 Oct 2026 11:42:40 +0000 Received: by outflank-mailman (input) for mailman id 1457982; Thu, 22 Oct 2026 11:42:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJrBu-0002xQ-II for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 11:42:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJrBt-006lED-TV for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 13:42:37 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9f69a-e002-0a2a0a5209dd-0a2a4504c87c-28 for ; Thu, 22 Oct 2026 13:42:37 +0200 Received: from [40.107.200.53] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ad9f6ac-b57f-0a2a45040019-286bc835f527-3 for ; Thu, 22 Oct 2026 13:42:37 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN6PR03MB7767.namprd03.prod.outlook.com (2603:10b6:208:4f1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Thu, 22 Oct 2026 11:42:34 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0546.016; Thu, 22 Oct 2026 11:42: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=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=bYK2qnLgutMICcET0AdN+dfbe7n4YC3DYFCNXSwv7vqtkdZwFm+ATC7CPkSZkrL74Tpb9okEf5YN+gHdsyq0VGU5pG5mPCh5hcU1eNJFj7TqvjoqinySosr+lWqOFjOVlsG/aeEwOjaJhLgzySiSO9VNldkyzw9Zx8ogGyU+GeoTpb9AuTlddaS90QcAtqQOa0WWLiE8njrTQVMsLfEgFtxJTkUzzVKtozgRgVLTTzeV308sMfypH6LFRe4bNBwUYqstJyJcAjY+6MLrPhkv9uxqtgfNZ8sPmFXRyDR+u3QyQ09emqtEEa5ZjKmdvdZci7pJKAymjGGIgwytAkK22Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DQ4ubFdDDVMv1BMRy0WHcKrpEBnB6KRN8+MWDZ4fS3A=; b=LeEq65skJC+2RWsm/qARZJbR2xlbx/eJ7Lix2prZ3deg6coUraD9epPJM3wfI79D98OHyxokg2tS1D4UN7tLi1om1vS5LcvmHg7uBZe7QPx0uV46EmrbI1I3RsF7+wf5aty3ZgbFgXNr0FgVUD33hS0lYJ2JFebE7CScPVbF/BtD/lhSrFWwpluq8GvK7jCSmJ741J+yS2SaoYxq/jTt5WsrMQntKxUq3sp916FehSawxERoiRjmE3HEmThA1fbMIAWJJ19d8VgWM/r+yNpZp4oq/gUkPAhBFqpRSevhuNHamb459pzT9RUiBR2oCE9ieif2zBnhGyQTO2V+vLrTqg== 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=DQ4ubFdDDVMv1BMRy0WHcKrpEBnB6KRN8+MWDZ4fS3A=; b=OVX5GkFNfUyvSU7mNt4lSS7yl85mCkoEpy8fSuQOqFagS43numz9r0DyhLWYDQbU16jxwe3A1BDYs/uMVNWA9iuoWXxtyNDY13tzUbC4GRPH32L0ynt9lKgXQ5frg40KvnpdbSkz1KQe7tYJV9Pawzg8taQu8arX3zoIdkAKCi4= 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, 22 Oct 2026 12:42:29 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD Subject: Re: [PATCH v2 1/1] tools/ocaml: implement stub_xc_domain_create() for ARM To: Julian Vetter , xen-devel@lists.xenproject.org References: <1792658248.8631fc262581453bbf619ec5b2062170.1a162c2110b000f79f@vates.tech> <1792658412.8631fc262581453bbf619ec5b2062170.1a162c493a1000f79f@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: <1792658412.8631fc262581453bbf619ec5b2062170.1a162c493a1000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0511.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::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_|MN6PR03MB7767:EE_ X-MS-Office365-Filtering-Correlation-Id: 2a1fad39-7e04-4eef-fa60-08df30318f50 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|261009223027099003|10067099003|261021121427099003|6133799003|56012099006|22082099003|18002099003|3023799007|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: ZHVXI4ee3xzOr53ehBO5luNcvn0bJmjIyCjnXeH4lpogreTliZOWbGX/bgw40bkQVWY4y5MpI/yDiqjOf3nmvjuI1NUaJCssq53b4/+Y3eyj6H5vSQP2TfVaN+o8Dsqbv3LdiAVFULfvpp+WxQoBjOIDYZM8RDncT4RaFKb+Buf9tIS6gBAF/f6IYy1I+iXmYv4lnwf2IqFzDTILWjeo9hFZ2M74YrOXWp9KPf0JG6rKafZyIBbnewfK5NRvrahTHQfqW7pVAIUmDSYQtiVsLF8BfCZezOkerwCaic9eWFWKKZC4CNDRcwAPgdTsdDVnT/enJ0znWoTov3pMNKDaWAJqvv7sORK9YQmtu5m4nuVWEtq4brKkbhY1BuIjcCSTpEQvW4zQnD0TWV94GFB3Z2UnF/a7jbePOI+vQYYJoVmdWxsYr7FBSZggGg0irp2/UEfexjWcDOLcqvwP3qSyAgjqyyrxEVufS1ERNVBJUoC7VO8Zh3uXgcxr+veRKU6ShW4Xo7QBl/1uLSMqznOSQruS+nulKr7I83qlRzR/w7ba6orR/l8yWHiHgXTR+YVaoYo/eOxSf9TGi/ZXaeQyhVHvDglmXssS0ntgJF1Vq/kf3xZfsX7fVkXk39umx6LqLps3iBKJPEylpTebdg4eph7jq5ABNnShq2SZRCzucGo= 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)(261009223027099003)(10067099003)(261021121427099003)(6133799003)(56012099006)(22082099003)(18002099003)(3023799007)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RERsVmNTL1EvVUgwRkZ0UmozczVoWEZxK2JRdTZGTDFvZXZVM1NKbWxmci90?= =?utf-8?B?aXBFM2FENHltNmRFMjlLVlFERncrNmJJWjBCODRDRnE2b1Fqdkk4R1dXUzFQ?= =?utf-8?B?dlVrcWwxR1FmeVBXUitHUWh6QkE1VE9RcmFOSlhmQWdVNWxnK2tDRldrNFBM?= =?utf-8?B?S0dPOWNtOFdSV1VIYzI1dEkzbXdIa3BTTXBRWVFUU0JXU0xwYmFEUVJPbjFC?= =?utf-8?B?ZGpnclphSlZYRGNKTjhaR2xmcm55czArYjVGNTloYllhWDlxK3NiZXpNWEFP?= =?utf-8?B?TjlZRkZGSnBPaThRSk1DbEc4MlVoZXppRXZJNXBxTHQwb2tFQ2hqY25QS3Fl?= =?utf-8?B?ME5ja3JyaGxqSFNyU3NwS1IzSENzbm82a3lUWDJIVnBqNlF5TG5WbnNEaEVJ?= =?utf-8?B?ZFBWcTNTT3ZzemQ0QU43QlRKaW1EWmY5RURzSUVMMnRKOWFQUXVNSFIvTGJr?= =?utf-8?B?TVcvdFB4d0VRZ24vbWt1OHc4MkgzU04wYzZhQW4vcTZvYW1RZEsvc0xOcWhi?= =?utf-8?B?bzFyU1NRN3c3R0FObE9pbHRGa25XOUh5RTU3ZlQweWswNnBzZFFSeDhVcHE5?= =?utf-8?B?cnhxUllab0lLSmVmUWhGWU1KVWJ0ZlVFYlFUQ2VRTy9kNlp3d0NZcG5GNFlC?= =?utf-8?B?RDJBRnRieGNXVHIyVDVvSGw1aXhwZFhSN0w4VFcvWUFzem43V2RtOVUyYnFt?= =?utf-8?B?a1lDVHkwQzNDa0xKQ1I0aTdsWEhORitBQ1FEZThUdnQxOVBLeXZkQVdORk55?= =?utf-8?B?QU9rYVhJN2tsejBWYndkbHliQkpIaG9zY0hremdlK1h6WXd1N1diakdVRFNx?= =?utf-8?B?VUdhMDZjeFJvVWs0bE4wSFl0Ly94dnBtRUVid2xUeDhHMnEwbU9zSmYrSGxl?= =?utf-8?B?UUFpbm1PZXUxbTEyKzJYQUhnYmtjZWIvTEJJdmR5aExwVnVEbDJVV01ta1Fr?= =?utf-8?B?U2l0ZHliYllRakdsMDlEemVmdHBVSFBwUVlKOWV2MGhZWFJsRlVDNTdsRm4r?= =?utf-8?B?V2lnV1lNUU52dXhCSGFaM1QvZVlXdklMN1k2M3VMdW1mNWNPeFV5bndUck1Z?= =?utf-8?B?ZnFxTkI3eGRoVTVtZGJWUjJPSHBmMmtud1U3R1RLcHI1eXBvWXI0TFNPeDlz?= =?utf-8?B?MFFPemVsNGxrbEhyZUYxSnBuZU9DMHVpbDZYNXFPVFk1YktFQWFha0xkRTlE?= =?utf-8?B?Q3BSM1N2RXo0VDVlZnFIYXJ6N2tEcDFMNlZsUnZ1YVlGcnRtOHRRSGk2cEla?= =?utf-8?B?VW5xV2dmS0dRcjZBMC9vMXJLWXJiVzYrZVdLLzlLdW1KWmg0Um5ob0R1WlRm?= =?utf-8?B?dUNqOUZmUlI0LzlYSFhBdHExMDRjYm1tcVdQYnpabnJIVjZRYUEzMmJ6SGgz?= =?utf-8?B?Ri9nQVpEV2xiVDJ6TStqK1FIL2xxVlVvbFlzKzFwb1VFZzUrNEFqNmVoNFMr?= =?utf-8?B?Wm5iZXFuUEZoWnpsYVQycjZDbE5kbG03ZXlIclZLdmFIcDZCWHNwVThTaUJn?= =?utf-8?B?TzA5NnlqQnB6SXU0clp1c0IrWWRTWGdMUTVPN2tSNG5VcXZFMlVFZEJPYk83?= =?utf-8?B?cmw5NmNuTWt1SE1ucmlNaDg5QnJhaEM2QTcyRkR5RmhQVlFmY21vbUNTbzRn?= =?utf-8?B?aWN3RTJob1VTaXovNEJ0Qm03L29TeUprTy8yTHNmbU4vZ2ZsNlVvSnZIaWFH?= =?utf-8?B?N1YvdGUyOXZNTlJpb1NNd0Zodi85RDVYSzErYm1iVGIzODVUa1I4RUNJQ0JD?= =?utf-8?B?Rkd2WmdIRjVtVlVuLzNxNU9Va0pNaGkzUkJjS2l0Uy82a0NScHdZK2ttc2pK?= =?utf-8?B?bW8xVHNnR2pCVzNZWTZpKzJHQWUrMjNBN1I4Sk5hNUtaN04vWVloZ2pwbGtX?= =?utf-8?B?TWNWc3pTZEVXcU1QZVhWYm1wMGRidTM0NlAySmVZOE5hNFpDMjl5WG9qWWFy?= =?utf-8?B?eFdnUTR1dVlLdm5uRVdmdXVTYkVUNUkzU2hmZXJseFZZY2p0aVZVdFhUS1VP?= =?utf-8?B?d2dvUHBHSkxPYnJTM0tlL3hzaUdCam9ES0tBWVpoM2FvNnlRUlJhVXIyWDNT?= =?utf-8?B?V0l1aTRFdTNTcDZUN2RmQ3FUN0o2OHVkMDhyTHc3eVFGTDJTeTQ4VkoxTGZM?= =?utf-8?B?ZjNrK3c0aVBPa2hBN3c0NXE0RzA2SWZCeHgvSmZXQkQ1UUM5dWY2dmhQaEtM?= =?utf-8?B?dVFEcUJaWks3c0IwUGlSbFllM0dOVkJtZW9ZUzIzengzS212N0p1OW90a1Fl?= =?utf-8?B?YTZlRHB6SDV4NVlLK3RiQ2xGZExPTnN1SjdQZ0o3bFhMU0FjREkyVWh1UWkw?= =?utf-8?B?alRXNENaelVQOUptVjVQTk5lVXZLZXl1d1gzUFJCa085M3B2VkhJZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a1fad39-7e04-4eef-fa60-08df30318f50 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2026 11:42:32.7983 (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: r30U+JyAZAMKIlqzVDWWbgQFz0Lnpt+pHoLz2WmNMqZFT1CuMzV8us01XjroD+XqnKh4C6zlf2TJTcFc3xER7jE+1WD8pGkOCsZF2yuCVxY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7767 X-purgate-ID: tlsNG-ebf023/1792669357-50EDEB50-454FE0D1/0/0 X-purgate-type: clean X-purgate-size: 963 On 22/10/2026 9:40 am, Julian Vetter wrote: > From: Andrii Sultanov > > stub_xc_domain_create() fails unconditionally with "Unhandled: ARM" for > the ARM variant of arch_domainconfig, so no OCaml toolstack (e.g. > xenopsd) can create an ARM domain. > > To fix this, convert the two fields of xen_arm_arch_domainconfig, > gic_version and nr_spis, into the corresponding fields of struct > xen_arch_domainconfig and reject values that do not fit, as is already > done for other parameters. The remaining fields (sve_vl, tee_type, > arm_sci_type and v8r_el1_msa) aren't exposed to OCaml yet, so they stay > zero. > > Also add a BUILD_BUG_ON() on the size of the createdomain struct, just > like the x86 case, to catch future ABI changes. > > Signed-off-by: Andrii Sultanov > Signed-off-by: Julian Vetter Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Thu Oct 22 12:13:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 12:13:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458030.1670487 (Exim 4.92) (envelope-from ) id 1xJrfX-0007vZ-Ns; Thu, 22 Oct 2026 12:13:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458030.1670487; Thu, 22 Oct 2026 12:13: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 1xJrfX-0007vS-In; Thu, 22 Oct 2026 12:13:15 +0000 Received: by outflank-mailman (input) for mailman id 1458030; Thu, 22 Oct 2026 12:13:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJrfW-0007vH-9V for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 12:13:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJrfV-00B6Vh-MQ for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:13:13 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9fdd1-8faa-0a2a0a5109dd-0a2a45038db6-24 for ; Thu, 22 Oct 2026 14:13: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 6ad9fdd9-fae8-0a2a45030019-b9ff1c12b493-3 for ; Thu, 22 Oct 2026 14:13: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 1a1638784d8000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 12:13:08 +0000 Received: from [192.168.1.52] (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 5EDF382B3E; Thu, 22 Oct 2026 14:13: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=YwcJTug30YV6MarLquP7ragoki0M6zg/ikiHj0VjsQg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=XP00dRsj4QUhu4OdHw7ZtFmKMIpPJO8rDN9vFtdSuziUttKxMj7K4/kqAF2cQMaCacAYQkB74 9fJTSwiAjFbl7aKSQgnCwcNFrrNJv5xrYBvTlRBqCBzDIQEK2avLIsYCf4a4zgysdpcaCvN88Nw jUwqC/fz8wSj0nzaqMDQgHQ+x2ZTfCWkB0Wm27vAKZiBLzE0KJxn3VeMhgqUgmIeZQor2SbW1z4 Vl836D4HiKkkXrCzIf1ZXAoDeEgM3+9+ovpMncPxAUFHuE3ZUJWC0OFDvF6u71G8/5y+V6ksGcM 5MIdy9ruBodK3pziuokMdRvm5cFM0XW+VMHjUwBVLcHA== X-Zone-Loop: 35b4dc8018403ae2961a00f5721a254fda065da98099 x-campaign-type: default x-transaction-id: bfb7c18e-395c-4edb-a020-10d201ff37f8 x-swg-uid: 01-c419a371-6c03-454a-9c9c-796aceb231fe X-Mailer: Sweego Message-ID: <1792671188.8631fc262581453bbf619ec5b2062170.1a1638784d8000f79f@vates.tech> x-swg-bid: 1792671188.8631fc262581453bbf619ec5b2062170.1a1638784d8000f79f 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 v3 24/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: <9943b1f4-1890-4917-ae39-bf9c70fc36c7@gmail.com> References: <9943b1f4-1890-4917-ae39-bf9c70fc36c7@gmail.com> Date: Thu, 22 Oct 2026 14:13:01 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792671182; l=1425; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=gQKYxbT+Crw1jWiAMdbc+26gb62yat8xw4yogHozE1E=; b=2QYhPsvromvPxhJTJQNb94aEqo04zyss6htno05STxC6axztMeScLTKV2Qe1cXt1vZFxXk+M6 hI+2HjraAbyALzcQ0M1Q+orXwICGJgIy8kiu+7JqsJZC0vGpV8IvjUU 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: 1792671187610 X-purgate-ID: tlsNG-33051d/1792671193-7428D4E9-EDC4D363/10/73395122804 X-purgate-type: spam X-purgate-size: 1425 On 2026-10-15 16:59:53+02:00, Oleksii Kurochko wrote: > On 9/30/26 6:23 PM, Oleksii Kurochko wrote: > > > 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. > > This part of commit message should be updated. Suggestion look below... > > > 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 > > --- > > [...] Sorry I don't understand, did you forget to put the suggestion? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 22 12:30:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 12:30:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458073.1670539 (Exim 4.92) (envelope-from ) id 1xJrwU-0003DY-NE; Thu, 22 Oct 2026 12:30:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458073.1670539; Thu, 22 Oct 2026 12:30: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 1xJrwU-0003DQ-KN; Thu, 22 Oct 2026 12:30:46 +0000 Received: by outflank-mailman (input) for mailman id 1458073; Thu, 22 Oct 2026 12:30:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJrwU-0003DK-0K for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 12:30:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJrwT-006w1Z-5j for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:30:45 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada01e0-2eae-0a2a0a5409dd-0a2a4502c096-46 for ; Thu, 22 Oct 2026 14:30:45 +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 6ada01f4-6ca4-0a2a45020019-b9ff1c12b075-3 for ; Thu, 22 Oct 2026 14:30: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a163979000000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 12:30:39 +0000 Received: from [192.168.1.52] (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 C5FEB80D94; Thu, 22 Oct 2026 14:30:38 +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=mF8488MbfF8zVdg2/+fG2MAaEhbtML2nMUv3PaZkE+0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=GaTDUl4H+11uR2OuD6CbyoMkplrm17VAJQzAqsjqxqAs/uVLzPJWwtxypCcQ5oou/knfGgGJ9 uaYbK4/hyfNZpEoj1zCdA4i+T/mMe/6jYng6bC43UeiguJzLa1BmLVyu46IAk1yCynoBy8auDEG o6KYMjInF+jrHWlNSp5q72OPEu1/MEcY0V/uvb4sTFzpsKBmJ4UnKu7ouZSaCDkMG2mkpcwbJps 3ZUtEj38UpxnHbWeCGT3cQR48bHfYtJZSVnCtmoSXr1OFGvLZC3HAclsp6gMTPEVxJNglTxq60P sC6Jrf+If90MUlASPANGueux7tsz3qJNmy39kdssutmA== X-Zone-Loop: fc5168f07cd00d66317f8d4169e46ad8ae101b9f6c4c x-campaign-type: default x-transaction-id: bfcce7fb-dbc8-4d03-b99a-083e476a9354 x-swg-uid: 01-0eb51cec-642f-4784-8ada-d6e6a1a1cfe4 X-Mailer: Sweego Message-ID: <1792672239.8631fc262581453bbf619ec5b2062170.1a163979000000f79f@vates.tech> x-swg-bid: 1792672239.8631fc262581453bbf619ec5b2062170.1a163979000000f79f 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 v3 24/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: <9943b1f4-1890-4917-ae39-bf9c70fc36c7@gmail.com> References: <9943b1f4-1890-4917-ae39-bf9c70fc36c7@gmail.com> Date: Thu, 22 Oct 2026 14:30:33 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792672233; l=3454; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=LFT/3z68hIrfjTjnlmTNtU1afYZWLx19wL/Hqh5QnMU=; b=bcArfGBMM+RwySao7F3JGEDdeVmSE3ztzH6Q43ES9CTsHolnKdvcb5oIg8a9eKfSEw7jxGaYi DOqHyUGxRIFDDQJqn0UqYbkv8KjSNzvJtsv9MYk7/YhKwRe5ETR5HPi 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: 1792672239019 X-purgate-ID: tlsNG-720697/1792672245-67ABD2AC-6C31AC06/10/73395122804 X-purgate-type: spam X-purgate-size: 3454 On 2026-10-15 16:59:53+02:00, Oleksii Kurochko wrote: > On 9/30/26 6:23 PM, Oleksii Kurochko wrote: > > > 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. > > This part of commit message should be updated. Suggestion look below... > > > 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 > > --- > > [...] > > > static int emulate_load(const struct guest_fault *gf) > > { > > - /* Transient, until the helpers gain their users. */ > > - (void)advance_pc; > > - (void)guest_xlen; > > - (void)guest_gpr; > > - (void)insn_fetch_faulted; > > - (void)decode_ldst_insn; > > + struct cpu_user_regs *regs = gf->regs; > > + mmio_info_t info = { .is_write = false }; > > + struct decoded_insn di = {}; > > + unsigned int shift = 0; As shift is always computed, I don't think it makes sense to init it. > > + int rc; > > > > - return -EOPNOTSUPP; > > + /* 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(info.data) - di.len); > > + > > +#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. */ > > + if ( di.reg ) > > + *guest_gpr(regs, &di) = (long)(info.data << shift) >> shift; > > It would be more correct to have here: > > shift = BITS_PER_BYTE * (sizeof(info.data) - di.len); > ... > if ( di.reg ) > *guest_gpr(regs, &di) = di.is_unsigned > ? (info.data << shift) >> shift > : (long)(info.data << shift) >> shift; > > and update the commit message part "Sign extension is done here…" to: > > Sign and zero extension are done here rather than in the handlers: a > shift pair drops whatever lies above the access width in the value read > and, for a signed load, sign-extends it, so a handler need only report > the value it read. this LGTM. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 22 12:37:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 12:37:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458089.1670555 (Exim 4.92) (envelope-from ) id 1xJs3D-0003y8-F4; Thu, 22 Oct 2026 12:37:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458089.1670555; Thu, 22 Oct 2026 12:37: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 1xJs3D-0003y1-CD; Thu, 22 Oct 2026 12:37:43 +0000 Received: by outflank-mailman (input) for mailman id 1458089; Thu, 22 Oct 2026 12:37:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJs3C-0003xv-05 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 12:37:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJs3B-002LPM-D5 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:37:41 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada038b-e002-0a2a0a5209dd-0a2a450c85b6-28 for ; Thu, 22 Oct 2026 14:37:41 +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 6ada0394-f479-0a2a450c0019-b9ff1c12b2df-3 for ; Thu, 22 Oct 2026 14:37: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a1639df031000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 12:37:37 +0000 Received: from [192.168.1.52] (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 B640380D94; Thu, 22 Oct 2026 14:37: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=3/TIeJ8V2lF/5VM+1C0BXG3TzV7I63OwP9omcQ2gPKU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=hqhcJIrBe8HFLieMQb3zXTvAm7dnt2dHFAxquIO2G8RzA4MUQuChQiGpmKuOIiXQEbQU2htEe lkqI67oaofC5nWak6P2RGvS6Gk1AKELLdoojDFFtE+2zZmd7bH+tRstaMeQwZ7jUWGo1/4mxNxS 4ryu+RpM0dOUv8r1WB0iYE434KqlSe9qaPypaRMnzwNK2ZCLNAptjHREQyZx7qNbRXKJwf9makt dShZ1+o8LV7VB8EjVVeSeA5FTJLCKyCyRLIsFmOm/dHguSZlVd3ky1EglXWFyuLiU8xima0+MPp WBvXi/sNE3VBSBg4pv52raCeMvI8D+qqxZkmXeYcau8w== X-Zone-Loop: bd30931c95a011dfdc29315fd978ad8384730bd14da9 x-campaign-type: default x-transaction-id: 88da5564-2a34-45e6-b416-1e89474377c7 x-swg-uid: 01-bdc8fa0d-07c2-4a99-a1d6-314d4ebc4ada X-Mailer: Sweego Message-ID: <1792672657.8631fc262581453bbf619ec5b2062170.1a1639df031000f79f@vates.tech> x-swg-bid: 1792672657.8631fc262581453bbf619ec5b2062170.1a1639df031000f79f 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 v3 25/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: References: Date: Thu, 22 Oct 2026 14:37:28 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792672651; l=1089; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=xUpGL8l1X2ln0qDZR5bCCwfQ/kwyNFBglaw2GkSDEwQ=; b=AMfirpoSVA8ak2qmjsIHaW54yHUIDJ+LdunGAdjRmDga5bZQ2HZX9fNCD5L1FMMw5gA3T+dcd bv5FqK8EmMoAJLmKJAbRQ7z+qxO+F8LYCeJckfCRwU4pJdqekLUmDlm 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: 1792672656941 X-purgate-ID: tlsNG-d25034/1792672661-016C6A5B-A2868FAB/0/0 X-purgate-type: clean X-purgate-size: 1089 > Extend the guest page fault handler with store emulation to support MMIO > write accesses. > > Like emulate_load(), emulate_store() obtains the trapped instruction with > insn_fetch_faulted(), which also deals with a fault taken while re-reading > it, and decodes it with decode_ldst_insn(). As with the load path, the > access is completed synchronously through do_mmio(). > > 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. Nit: the wording is unclear because "emulated via the vINTC backend" sounds like the vINTC does the decoding, I'd suggest: ``` At the moment the only MMIO handler registered is the vAPLIC one, so in practice every trapped guest store ends up in vaplic_mmio_ops' write handler. ``` Instead of that, everything LGTM, so: Reviewed-by: Baptiste Le Duc Thanks! -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 22 12:39:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 12:39:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458100.1670568 (Exim 4.92) (envelope-from ) id 1xJs5O-0004iy-Pg; Thu, 22 Oct 2026 12:39:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458100.1670568; Thu, 22 Oct 2026 12: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 1xJs5O-0004ir-N0; Thu, 22 Oct 2026 12:39:58 +0000 Received: by outflank-mailman (input) for mailman id 1458100; Thu, 22 Oct 2026 12:39:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJs5N-0004il-2u for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 12:39:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJs5M-009Les-8w for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:39:56 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada0400-bab6-0a2a0a5309dd-0a2a450ba60e-24 for ; Thu, 22 Oct 2026 14:39:56 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada041b-b7e8-0a2a450b0019-b9ff1c238865-3 for ; Thu, 22 Oct 2026 14:39: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 1a1639ff9d2000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 12:39:50 +0000 Received: from [192.168.1.52] (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 1451B820D1; Thu, 22 Oct 2026 14:39: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=CoBWFYKkHb42QoD3/q34cB0cjiDkIzF8Z+yUYtMdPf4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Khika+lEHGob9wZoIHSK6Heo7imzlxvZR8BAB4xRvTTffNdRTIVd5OM1LRUQ9PDIXi7xUBVJ3 bewT2MBGDsJcBoiYjdnaXHRUnsNFtBlYnXVpE1J2gLv0gUzYqQuNG+uudmIInAwxj2p6HoGp7ZS f7LkwcLQyR9mz+imEjBTi6aShzp5N0YUty0thhJlbwHEiwtz/KfwTxsB1NzquJkCYb2EucgzEDG 4pkjwOl0uLrLU3FJnhp8ZaTLA7P2kzJeHi4pI3d7L+YD17EV9qT7OlQaLjn1Vugxvc1N7Okr3/S AqVyqKZC08FExsL0IhO06QxBcj0qYw3KETHJ+An+pNSA== X-Zone-Loop: eb285aa81a7ced14998e3054cef64c0141baeed4c12e x-campaign-type: default x-transaction-id: d448ffe7-d4b2-4573-964d-0f1e85a9a6e6 x-swg-uid: 01-0cca641a-1e3d-44fe-b6cb-8fd97749c7d2 X-Mailer: Sweego Message-ID: <1792672791.8631fc262581453bbf619ec5b2062170.1a1639ff9d2000f79f@vates.tech> x-swg-bid: 1792672791.8631fc262581453bbf619ec5b2062170.1a1639ff9d2000f79f 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 v3 27/39] xen/riscv: handle the case when no vCPU migration is needed 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, 22 Oct 2026 14:39:43 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792672784; l=679; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=z5mdU21xoFBTYKu1EVauRYY2WynXMVjOmDj4k/sebNA=; b=AYv0+Bhw+RplXsdC54UCYDbupUfjuzA/Te5uISCMdxLMFiOC9qXeHSMnozRy9DJ4ZrB+92Ynr f4G+ayYvGRzAFbycVZe3SgJR9QBPQaUi5OcDdlL9yjCZcBym9W1tZ0W 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: 1792672790286 X-purgate-ID: tlsNG-42698a/1792672796-AA0C59EA-EF2E4FF0/10/73395122804 X-purgate-type: spam X-purgate-size: 679 On Wed, 30 Sep 2026 18:23:46 +0200, Oleksii Kurochko wrote: > The scheduler moves a vCPU's interrupts (arch_move_irqs(), i.e. > imsic_migrate_vcpu()) ahead of context_switch() whenever the unit is > picked up by a pCPU other than the one it was assigned to, which can > already happen for a freshly created vCPU on its very first run. No IMSIC > h/w interrupt file has been mapped for such a vCPU yet, so there is > nothing to migrate: return early while its last_cpu is still CPU_NONE, > i.e. while it hasn't run. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 22 13:28:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 13:28:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458177.1670598 (Exim 4.92) (envelope-from ) id 1xJsqN-0003kJ-HP; Thu, 22 Oct 2026 13:28:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458177.1670598; Thu, 22 Oct 2026 13:28: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 1xJsqN-0003kB-D3; Thu, 22 Oct 2026 13:28:31 +0000 Received: by outflank-mailman (input) for mailman id 1458177; Thu, 22 Oct 2026 13:28:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJsqM-0003k5-4V for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 13:28:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJsqL-00C248-6O for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 15:28:29 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada0f7c-bab6-0a2a0a5309dd-0a2a450b9212-2 for ; Thu, 22 Oct 2026 15:28:29 +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 6ada0f7d-b7e8-0a2a450b0019-d1558035b4ae-3 for ; Thu, 22 Oct 2026 15:28:29 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a20c923847so3076805e9.0 for ; Thu, 22 Oct 2026 06:28:29 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e258426f4sm12389209f8f.54.2026.10.22.06.28.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2026 06:28: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=1792675708; x=1793280508; 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=Qg7BHB5v9FDWAlFgYoBtMVRo7WwT7dQ4n8Bi+JAvx9k=; b=ZB2vDHHiPKMZA0rjtAIGdU1TMbRWwE2FEiG6XQ894oXFUp5PwskgSxsdJ9MKIShJeo A3LqEkQ2dzxUVeTG+ZrvrSWpC7bvt1unEdq/0DodE3xnSn4INcBm4mu8d7avm0rebHMU Xwxhyybfi4XZ452Xp1zcrhRSsqGUeuC0GHLuo5ic5K3cTkguSy53YpkmgNwu1rJicGij VLA0pZVGXBSi7WDlpptcP6dCeW23UnT5sEkjxyImy38Uqd/oW523pYJVQjDBSMD8BrtG zD3+Zym2ZhwzbD3G0LpB1o03ztjjWsJM3/SqB2Mq6kSHeVCnfhUvdgUytiGieJo85XWW myQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792675708; x=1793280508; 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=Qg7BHB5v9FDWAlFgYoBtMVRo7WwT7dQ4n8Bi+JAvx9k=; b=AIuEpExUF3G/A5H1ASPJsCzIcICtC/FLP5fKB7X+7eUttoDI8iiVSnle5f9sW1YTYV JQO4HYgaEJl62jKG2bk44NkEGC+czMlM6V9POLOzbcnucPXhNOtpImwfLIYF7j9ZdRJd IiQkbagnWKkTuqP8GWMUv91Bm1vrhYL9s8pWsut1VRrKeFF6w1Khv+yk8BJx6JBR38hX w1SDnTG9VrWSwqEigTorKgQS+7mAkY1A3+LHETucXQjSNUJOTkCyRi1tc2fhHnEbcga+ 7QY9CExuGkaL0zBQlQ/pDCQbTB7aye4fYgcb2lcZDRIivdWjdlQIy2Kcw4kw2bpBdlHx 2law== X-Forwarded-Encrypted: i=1; AKwUvBwVPdc9q9kTLzZSlKvniz3lAhq5ywOli9BIHbUKVqWgvxjF5XrXCPRymWh0EldhHOZHrB0YqoP2/4A=@lists.xenproject.org X-Gm-Message-State: AFq9FYLe2kF8mpG0Q1mzVCx5VyS5GQ6KIyXFRhCMe/e+hNAmrrYCeBc8 ErPXt3zIy80PX33xSCxKeEauP9HPfIFPlYlNlIGLE+IKdyqyoyepTol1I382yQ== X-Gm-Gg: AYBFou24Q/1iIN9xirVQjFkp0SZcf3aEJBp6JpEu6Y3AG8QTYmMJjh2WRnqJqGKaBMA 4bN179e1SNi+nYtrfaG50HayvNEGK+NQZY1ZrzoxovTS3j3XyX3L41T9AfeEC304HXrYnYd6hx4 4PjnkN3dhNHMUnNLiXQ28jutYGC+Uhw3Q6/1Q+Gt9/8yflCqmQxkiUXu8qxDOyRTI3P5p1DFvQl Amsoh9o13WQNz6hZnL20RbbB52NawwMk1kx0wALBvTR5H3q0zp+5z0dxYOBCI/PuFZVLqWoV5N1 O7iIAlrcspPE7di0yDNukG5Stn8vCq+tW+uv5DXNz5iRnqsnjotNsjd/3lvwBTUG9xvIJV3ECog zie436iAbFm7/6eoGTROdAmmZqVgpuVwMJQw92Wyw3UdgWlboHgELGboGWqXmnpY6K+Bxk+2dSt rQOxNlGXVLB7zurPSDACnLKQu0rg3qDb0mu22UGt9o4xPHzSpZr8Le0PPQjD4uTUrwbbTmxg7BV W9OU09CyobtxdN0hHCf5KgdhC7Gt22LaW7YD9jgk7Lda/dqGfeXXPCV1lF4xGtxdJcS9h8w2pZp raWffBRy8sjY1NLgsCGUJnQH6vAm X-Received: by 2002:a05:600c:b86:b0:4a0:1fb9:2f51 with SMTP id 5b1f17b1804b1-4a1fdd2fa6cmr111360115e9.14.1792675708355; Thu, 22 Oct 2026 06:28:28 -0700 (PDT) Message-ID: <846f2ec6-da73-4f12-b46f-5e9f841e35ad@gmail.com> Date: Thu, 22 Oct 2026 15:28:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] Add a QTB container to run the Xen riscv64 tests To: Baptiste Le Duc , 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 References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823787.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1787823787.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1792675709-2C59A9EA-A439C875/10/63158204843 X-purgate-type: spam X-purgate-size: 5692 On 8/27/26 11:42 AM, Baptiste Le Duc wrote: > QTB (QEMU Test Bench) is a Python framework, developed as part of AMD's Xen > safety initiative, that drives a live QEMU instance over qtest and QMP. It > gives a test full access to the machine while the emulation runs: read and > write the consoles, inspect the registers and the memory, inject interrupts. > > For now the riscv64 CI tests only use it to read the Xen console in the > smoke test, since DomU is not supported yet. Once it is, the same > framework will read and write the DomU consoles and inject IRQs, so the > tests can assert an interrupt reaches the expected guest and vCPU. > > QTB is not upstream in QEMU yet, though it is planned to be, so get the > framework from AMD's fork gitlab.com/xen-project/people/amd/qemu and > pip-installs qemu.qtb from it. s/pip-installs/pip-install/ It would also be good to say explicitly that only the Python package comes from the fork, while the emulator itself is Debian's qemu-system-riscv64. > > Signed-off-by: Baptiste Le Duc > --- > containerize | 1 + > images/debian/13-qtb-riscv64.dockerfile | 45 +++++++++++++++++++++++++ This is more a question for the CI maintainers: should this container live in test-artifacts at all? So far test-artifacts only holds containers for building its own artifacts (kernels, rootfs, microcode), which xen.git then pulls in via cross-project needs:. The containers the xen.git test jobs run in, including debian:13-riscv64, which already carries qemu-system-riscv64 for the test phase, and the hardware runner ones, are all built from automation/build/ in xen.git and pulled from XEN_REGISTRY. Having it as automation/build/debian/13-qtb-riscv64.dockerfile in xen.git would keep the container next to its only user, avoid the new ARTIFACTS_REGISTRY variable and the image: override in patch 6, and drop the "must land first" ordering between two repositories. > 2 files changed, 46 insertions(+) > create mode 100644 images/debian/13-qtb-riscv64.dockerfile > > diff --git a/containerize b/containerize > index dad9afa..477b670 100755 > --- a/containerize > +++ b/containerize > @@ -31,6 +31,7 @@ case "_${CONTAINER}" in > _alpine-3.24-arm64-base) CONTAINER="${BASE}/alpine:3.24-arm64-base" ;; > _alpine-3.24-arm64-build) CONTAINER="${BASE}/alpine:3.24-arm64-build" ;; > _alpine-3.24-x86_64-base) CONTAINER="${BASE}/alpine:3.24-x86_64-base" ;; > + _debian-13-qtb-riscv64) CONTAINER="${BASE}/debian:13-qtb-riscv64" ;; > _alpine-3.24-x86_64-build|_) CONTAINER="${BASE}/alpine:3.24-x86_64-build" ;; It seems like these lines are sorted/grouped by architecture name. So I think it will be better to put _debian-13-qtb-riscv64 here. > esac > > diff --git a/images/debian/13-qtb-riscv64.dockerfile b/images/debian/13-qtb-riscv64.dockerfile > new file mode 100644 > index 0000000..86215d3 > --- /dev/null > +++ b/images/debian/13-qtb-riscv64.dockerfile > @@ -0,0 +1,45 @@ > +# syntax=docker/dockerfile:1 > +FROM --platform=linux/amd64 debian:trixie-slim > +LABEL maintainer.name="The Xen Project" > +LABEL maintainer.email="xen-devel@lists.xenproject.org" > + > +ENV DEBIAN_FRONTEND=noninteractive > + > +ARG QEMU_REPO=https://gitlab.com/xen-project/people/amd/qemu.git > +ARG QEMU_COMMIT=24cd7e5c0d7e4db8e651f091d0b9da2e7c58dbab > + This commit is currently the tip of the 'safety' branch, and no tag points to it. If that branch gets rebased, the commit may become unreachable and the container will no longer rebuild. Could a tag be created for it in the fork? > +RUN < +#!/bin/bash > + set -eu > + > + useradd --create-home user > + > + apt-get update > + > + DEPS=(# Base environment > + ca-certificates > + device-tree-compiler > + git > + python3-jinja2 > + python3-minimal > + python3-pip > + python3-yaml > + > + # Qemu for test phase > + qemu-system-riscv64 > + ) > + > + apt-get -y --no-install-recommends install "${DEPS[@]}" > + > + # QTB framework > + git init /tmp/qemu > + git -C /tmp/qemu fetch --depth 1 "$QEMU_REPO" "$QEMU_COMMIT" > + git -C /tmp/qemu checkout FETCH_HEAD > + pip install --break-system-packages /tmp/qemu/python[qtb] Please quote the argument: unquoted, /tmp/qemu/python[qtb] is a glob matching /tmp/qemu/python{q,t,b}, and it works only because none of them exists. Also, this fetches qemu.qmp, pexpect, pygdbmi and ptyprocess from PyPI with only lower bounds, so the result depends on when the container is built: building it now installs qemu.qmp 0.0.6, while the fork ships 0.0.5. The fork already bundles wheels for all of the [qtb] dependencies in python/wheels/, so they can be installed offline. I've checked that the following works, with python3-setuptools added to DEPS: pip install --break-system-packages --no-index --no-build-isolation \ --find-links /tmp/qemu/python/wheels "/tmp/qemu/python[qtb]" Minor: python3-pytest isn't installed, so the unit tests from patch 4 can't be run in this container, although the README asks only for "the prerequisites above plus pytest". It would be convenient to have it here. FWIW, I've built the container and run the smoke test from this series in it against a locally built riscv64 Xen (console-test run dom0less-1smp-0domu-1vcpu-aplic-imsic-null): it passes. ~ Oleksii > + > + rm -rf /tmp/qemu > + rm -rf /var/lib/apt/lists/* > +EOF > + > +USER user > +WORKDIR /build From xen-devel-bounces@lists.xenproject.org Thu Oct 22 13:38:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 13:38:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458192.1670612 (Exim 4.92) (envelope-from ) id 1xJt0C-0005mz-Kf; Thu, 22 Oct 2026 13:38:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458192.1670612; Thu, 22 Oct 2026 13: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 1xJt0C-0005ms-G9; Thu, 22 Oct 2026 13:38:40 +0000 Received: by outflank-mailman (input) for mailman id 1458192; Thu, 22 Oct 2026 13:38:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJt0A-0005mk-TD for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 13:38:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJt0A-00DgZE-1d for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 15:38:38 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada11dd-e002-0a2a0a5209dd-0a2a450abb86-0 for ; Thu, 22 Oct 2026 15:38:37 +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 6ada11dd-f2d2-0a2a450a0019-b9ff1c22866b-3 for ; Thu, 22 Oct 2026 15:38: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 1a163d5b71c000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 13:38:32 +0000 Received: from [192.168.1.52] (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 1194681F99; Thu, 22 Oct 2026 15:38: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=Dw2fRabQzezKIvf1NlRVsFOL1aPuqwy/+pE/9/FVYoY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=YTluAJyl4oUBmdqafQ+q5IKyH6exDQ+IXX+/qBHafyPbClpHhzIEge64N8pbPkHzYAGNMiavV 8jhRSBJnl2kROeUuEYMoe8nzWLAirhS0XKubEv52YkfNvkItceKp31C/7n63Sn2xMfjqBdnBckA 96dLk3+Nb5uAzWpPavGPWqX9MOEUrIRzsl1yNhYvRu1uRS/v8dLIkoEFvAsr2WgK9NZ/YWLByVD KPKsCrOSLuPN+tGFJL0ML2yumpMVlM0LcsD1dDNKoYBQxalyrSvqTE2WMjELCjAOawPlKuTdWD1 BKGh1a460J4vdbvdqdItWmfLgW46i6ZMhMXOFxH0d+6A== X-Zone-Loop: d4412244508ebb3d9c39299f20368ee0a55e8e0b7acf x-campaign-type: default x-transaction-id: 741cd6fe-b53b-4940-b75f-67a53c9a1e60 x-swg-uid: 01-70aeb852-b246-42ad-b9c2-b61e0734f86e X-Mailer: Sweego Message-ID: <1792676312.8631fc262581453bbf619ec5b2062170.1a163d5b71c000f79f@vates.tech> x-swg-bid: 1792676312.8631fc262581453bbf619ec5b2062170.1a163d5b71c000f79f 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 v3 28/39] xen/riscv: introduce vaplic_reconfigure_target() 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, 22 Oct 2026 15:38:25 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792676306; l=4924; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=PlTw2plOSyk8QEZxKYG1XQ1GcZaion0uCbPoCk5yMGM=; b=DPzKUZogmhcCjlkmdiSLqH0LlRY19qJWzdx73YRaDo6YgBNph6qjmzUVhuhOz2dhffQoPSvBq DEGx51UEPs3AcAHswoXzL3i83EBpE+M7camDL997+zosqqlB0tY6j4v 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: 1792676312282 X-purgate-ID: tlsNG-4011c0/1792676317-59BC0CFC-CA0692D1/0/0 X-purgate-type: clean X-purgate-size: 4924 > 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. > Jan's first question on v2 was how this avoids losing interrupts that are raised mid-retarget. You answered it on the list (step 3 of the AIA VS-level migration sequence; in-flight MSIs still land in the old file's eip and get merged into the new file later), but neither the description nor a comment says so. Please put it in the description, since this function is only correct as one step of that sequence. > [ ... 43 lines skipped ... ] > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -128,7 +128,10 @@ static unsigned long aplic_hart_index(unsigned int cpu) > /* > * v->processor can't be used here: during a migration it names the new pCPU > * before the interrupt file is moved there. The caller has to hold > - * vsfile_lock until the result is written to the h/w. > + * vsfile_lock, so that the guest file id and the pCPU owning it are read as > + * a consistent pair. A value built from the old file just before a migration > + * publishes the new one isn't lost: vaplic_reconfigure_target() runs after > + * the publication and rewrites every source targeting the vCPU. At this point in the series nothing calls vaplic_reconfigure_target(), so "runs after the publication" describes a caller that doesn't exist yet. Either move this sentence to the patch that adds the call, or word it as a requirement on that caller. > [ ... 43 lines skipped ... ] > > +/* Decode the target vCPU from a TARGET snapshot (NULL if none). */ > +static struct vcpu *vaplic_target_decode_vcpu(const struct domain *d, > + uint32_t target) > +{ > + unsigned int hart_idx = MASK_EXTR(target, APLIC_TARGET_HART_IDX); > + > + /* > + * Skip a source whose EIID is 0, e.g. one still holding its reset > + * value: interrupt identity 0 isn't valid at any IMSIC interrupt file, > + * so such a source delivers nothing and needs no retargeting. > + * The hart index range check is only a guard: the write path refuses to > + * record values with an out-of-range hart index. > + */ "Reset value" reads as if the AIA spec defined one, but it doesn't: APLIC state other than domaincfg, the MSI address config registers and the genmsi Busy bit is UNSPECIFIED after reset. The 0 here only comes from xvzalloc_array() in domain_vaplic_init(). Could this be made explicit? It may also be worth saying that this check keeps unprogrammed sources from decoding as targeting vCPU0 (hart index 0), which would otherwise cause pointless physical TARGET rewrites on every vCPU0 migration. Something like: /* * Skip a source whose EIID is 0 (not yet programmed, vAPLIC state * is zero-initialised): identity 0 is reserved at every IMSIC, so * it can't fire. Otherwise it would also decode as targeting * vCPU0 and get rewritten on every vCPU0 migration. * The hart index range check is only a guard: the write path * refuses to record values with an out-of-range hart index. */ > [ ... 6 lines skipped ... ] > +void vaplic_reconfigure_target(const struct vcpu *v) > +{ > + struct domain *d = v->domain; > + struct vaplic *vaplic = to_vaplic(d); > + struct vimsic_state *vimsic_state = v->arch.vimsic_state; > + unsigned int irqn; > + > + bitmap_for_each ( irqn, d->arch.vintc->used_irqs, d->arch.vintc->nr_virqs ) > + { > + struct vaplic_source *src = &vaplic->regs.sources[irqn]; > + unsigned long flags; > + uint32_t target; > + > + /* APLIC interrupt sources start from 1, there is no source 0. */ > + if ( !irqn ) > + continue; > + > + spin_lock_irqsave(&src->lock, flags); > + > + target = read_atomic(&src->target); > + > + if ( vaplic_target_decode_vcpu(d, target) == v ) > + { > + /* > + * IRQs are already off under src->lock so no need for *_irqsave > + * here. > + */ > + read_lock(&vimsic_state->vsfile_lock); > + aplic_hw_write_reg(offsetof(struct aplic_regs, target[irqn - 1]), > + aplic_msi_target_gen(v, target)); > Doesn't this need the same vsfile_cpu != CPU_NONE check as vaplic_emulate_store()? Because it seems that, for a vCPU on a s/w VS-file, aplic_msi_target_gen() calls aplic_hart_index(CPU_NONE) and indexes imsic->msi[] out of bounds; the ASSERT() in aplic_msi_target_gen() doesn't help in release builds. Since both callers now do the same lock/check/generate/write sequence, a helper for it would make sense. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 22 13:55:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 13:55:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458218.1670619 (Exim 4.92) (envelope-from ) id 1xJtGh-0000KO-UM; Thu, 22 Oct 2026 13:55:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458218.1670619; Thu, 22 Oct 2026 13: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 1xJtGh-0000KH-RY; Thu, 22 Oct 2026 13:55:43 +0000 Received: by outflank-mailman (input) for mailman id 1458218; Thu, 22 Oct 2026 13:55:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJtGg-0000KB-Rv for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 13:55:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJtGf-00DjqW-Tl for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 15:55:41 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada15da-bab6-0a2a0a5309dd-0a2a4504e728-10 for ; Thu, 22 Oct 2026 15:55:41 +0200 Received: from [40.107.201.52] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada15db-b57f-0a2a45040019-286bc93463e3-3 for ; Thu, 22 Oct 2026 15:55:41 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CH3PR03MB114257.namprd03.prod.outlook.com (2603:10b6:610:39e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Thu, 22 Oct 2026 13:55: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.0546.017; Thu, 22 Oct 2026 13:55: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=sern73/HzA0QW9TWGB0kWPWuIVNs2sdlbf1IcMPY3L6MEVyNHmxaOKV2a6pJGKkb3P97Tqoex2Ja9pVKk0+3gwvpA1me2lcYnWWScUOhtFsV8iRgF4bA/nfmtJScEEBBiArzIHAr753ZNy2OuGzYt+yc+a2g9ct2wPVEZJ1iRmAwj7MZpcSYe2r3o1PXmiQePgvKL/hDUZ4W++YzXhMkM83Gg5p4ERselhEiBS+1rYlK0bcccyvRBjMtJ6p/rdan83qpopUcRuFBKw/UMLqE3GNtK4nb8yAZKQkT78VkyUayxoFfg8zbrm14tYNv5cj095z8h/KZXxJK77G76wSKvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Uv8rEWvSEwpvuZ2NCj5R5cblN2Dybczq/xXjhR3rDAs=; b=KJI2vpRKt3spDHX7iC3429nY+DRjCalwvbp/YLqi/wSTQzZCYi3b1F0aQQ3SYdAyWKdu3av4xvcNfwLXAhIDXzBnv7+PG4s0bM5ZgGr42NA8Z13YGPO3l0Dt7C32ayXg8epDd1OBNi/YJVw37USYdE8aGBjRLAXtT6tA1Suf0CrU0SquLhFggcv5CcwDevCon5r0U8T6V1L/FKNqWactGFQQp4Zbpva2TzF6PPQ64DP/DX80cxiDMKHKOLvGCvJFeOSrpBXU3TMP6o66lJTsURoewoFRRBlmlXBg0reoE+XiscDqMi/8BUjfJ5TIB7GCweY7E6tOVEZJNeMsMcEsXg== 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=Uv8rEWvSEwpvuZ2NCj5R5cblN2Dybczq/xXjhR3rDAs=; b=L7ASMbHBFjfVR4DKFpAhJrAJFZhX0laMxAxz+XFrAbs4JwwDjjG91MdlcwQb9QwBYD4WyR1uNuf1iE8BkzWTWIpofdd+B0qWzuxYuZ41WtYkphoR89AtrxHoTyE/yuoQzcstVPkH/MxgPOXfwp2ILFcar168spjUGn721AK+Ndo= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <86d6b7b5-41f2-41b4-8710-7356c78fd15e@citrix.com> Date: Thu, 22 Oct 2026 14:55:32 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86/svm: Apply the virtual-8086 IOPL check to INT n only To: Stefano Stabellini , 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: <20261020224123.3710391-1-stefano.stabellini@amd.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <20261020224123.3710391-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0112.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c3::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_|CH3PR03MB114257:EE_ X-MS-Office365-Filtering-Correlation-Id: 7e192628-3e4d-44ca-b7c1-08df30442661 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|18002099003|11063799006|261021123027099003|261021121427099003|261009223027099003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: rCwEa5GjSxB0tiB5KNkbREGzfe3Yj7RnO12H7e2N1tWo8CPqEbAeuK29HPcuHaAOETafhcOxBMDyyUBBGBSYstTyiDBieSChGJMMbigMCdPI2Ji9MXpcOwc+KoAkuosdO7TFlEK6mri6r6yX3bnRSVfc4onF6b3yBi+ZG0728Nmd63CtOwnZn1gJ+wltaf5+m0sbIzeMIZYgoHaSyA/HZYmBM9AIBZt2Moc+WKHhEoR9MKwqq1XmmQluFCMhxhosF/QXjsRf1UQAZ31NDgjVGgfXKXxDz7rDa97Lznoli/kZTpurXuHrbkOkJfuIN+UfX6bsErfWU+Qmdu6Suz0XO1m+WHpQWyurXw94nxboe8KFNrRFlURuDKP6Ix4OwPE3JFQ7+2UaSNE5G8SNviCE96vZUr0RjImUXIYRQama1MLNgZQyLElAUXSsVKKEbcq/8wtuSXml2sHo2BFQf+ovupNX51ACav0iJrpLZWZ0GlEO/mR2ehLCeNv5lrWLUK69RjuUPrqGxE1mdpOa9Tt3jL4iPDS0Z7zgExVHNPRqGjtq/ti3xU97gwESE2twLZsdfBTbuxpVHOxA0vWFhgYJ9GN3wWmi7wevVPqykhPSNMmWUhvpXwyH2SZjL5ksCMQPCJ76icXNUYCibxHunKza8va4AqgUzzkX2lGHwlQ/+3s= 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)(376014)(1800799024)(366016)(22082099003)(18002099003)(11063799006)(261021123027099003)(261021121427099003)(261009223027099003)(10067099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?am5LM2FzeWkwZUhWalFrQ1hWRUpwTU8yOU9FQkZsbHRDQ1hwTlhpTm0rNnlO?= =?utf-8?B?bmp4YThWenMxTVFhQVMwZUZhaFFaeGxtTnhXZXpmaXQwY3o4bHVPUW1QdDFD?= =?utf-8?B?cml5R2pkMmJmREVqYk9XMG5TYzBXMHNhTWcvMFdZN2ZiU3ZxdG1tU0xPSGZC?= =?utf-8?B?bTRrZUxMRHdQN0M2UG82TUh6dlU5MVV6TVhRMTViakNKbjJzMTVlMUhnZHNQ?= =?utf-8?B?ZzBRVDhXcWpsUHpVNVBUakRTN3gxZHIyTktxMVdvL2xsNUVDQVNtaE1Zem5W?= =?utf-8?B?My9NbVBLMkhsSHVDWlZLYjMreDdnQTVPcTNXUjJCUlJkbkZ1ZUJaYjZ6Zml0?= =?utf-8?B?UGQwUnZBbDUyeERIWkJPVVViNXpNV0hLeDBKWjNyYmRPR21idWViYzdPRGlr?= =?utf-8?B?NmlHRjVDVnZkZ1NNMlB0bXFUbHJLTTd3ellHZjZxZ3Y0ZGtQcDJ1V2E0MkNB?= =?utf-8?B?REJ3VXlYTTRIZ3p5dEE1cm90Z3NrZDMreVRoakJiUFdSb2UwVGRYcE9USXRX?= =?utf-8?B?U3BPNlRIaEdNM0cwSis5OGczNlBEV0lueTQrTEx5ZVdMUENXQ3FvUUpyckNj?= =?utf-8?B?RE1wV09yOG1hTEVCWno0TkZ4R1JkM0JtMSttbEJCdE50VkxCd3pReitWL2pB?= =?utf-8?B?RittQUZYUWQ5OVRJUlRiWUU2Y3Fkd1doNktjTklyWGh2SncveGo3WHl6d2lt?= =?utf-8?B?VitDeHlqaXVrWnMxWU50RFJGUlJiclIwOTNGQ28vVkdzcG90RFdYWFFmTzVu?= =?utf-8?B?YXIyRkZhWTRSVS9HR1VpdjdjbnhrSkJrb2ZRZUNFbmJIVm5sZkhWWEpmdU82?= =?utf-8?B?YW5lQVRLVHlkeTZIMDB2bzJQeFd4WVBZWnVIcUlWbWVsaVJVY2poeVJLZnZs?= =?utf-8?B?bDdmUUE4MjhObW4yeEVCZ1pPOUdlOUlsSGdyb2JhVURtNTcvOTM4RktORGhp?= =?utf-8?B?bWU5bHUyNFZlS1YwRUdVTDNrUzFMM1dDdGl3YURwcGtxSllGRVRvNlRjZGlv?= =?utf-8?B?WDBtSGNsK3BZWDFIcklQZXhoOTQyVXZMek9Hall2VGx1VjNEaUtoK2U5K3pj?= =?utf-8?B?cTBsUEhUbndwM0dRcEFzMVpPL2x0RXUzeWN5L1ZwK1JzYVN6T2NiZzM2YXd0?= =?utf-8?B?NUQxY2ZpMUtUeVhsSVFtc3BTZldESWQ1NDhHUGFtdTRuZEJQRmc0L1pySldT?= =?utf-8?B?MFIwZTJuYllWcmlnNUtJWjhpNDBGVitmT09CendrVGxzb0V2UlZYeVZ5Z0M1?= =?utf-8?B?WXRHWE56a1BvaHRLUm5lWFhvaFF1SVQ2NnlEa29JaDkybzRNM01tbzMvY3oz?= =?utf-8?B?OGZ5U0RSREN3YU9KNEExNFdPYjI2WEV2REVHUU50YnRVNkpLMHdmb1k5dk5R?= =?utf-8?B?dExqUEdRWU9XRjBpcUNZczVhWEVEb1NIZTVIVWpsYVlLMHc3U0EyUjdubURM?= =?utf-8?B?UXBOMVBxb0dCRitlTkE5MXlNUWlWaHEvQ0k5anRDM3B5emlubngraHJneU1F?= =?utf-8?B?aFcrcHU5eEJVamJFQ0V4OFg3M211VjdycU80Y3pVYXVUN3dlWEJUTGtRY2RH?= =?utf-8?B?cllzOFNxT0tKdlpYRXorZy8vVjM2R0ExdXRSa2VVdGdZN1hSOXoyVFlxVStS?= =?utf-8?B?c2g0S0hZSTdwOWpBcEhPYXIvUnB0NHVKT3pOOXN6ZDJkY0x4V0JaTlhwWDdW?= =?utf-8?B?K0tkK1RKWm1KNWxVQ1g2REhTSzlkMkVnMXRPZ2Q1cFVjY1JwWjRSemdTYXBY?= =?utf-8?B?em11T3ZVUTgvSVBId0RqU3lpRkowK1p0R2oyd3M2aUI3K1JvTEdaQnRxbmVZ?= =?utf-8?B?QjNnaVNzOHBBYzlSY2VWdkRlZGZHU3FMUnhHV2hVTDE5THlzT0lrOXU3allk?= =?utf-8?B?dTVsSmNUMktzK2dhS1Z5aW9ZVHViQW9oYURGTzZBZlZxZnUwbGpnUHhKQU81?= =?utf-8?B?YW1YR0NLNDFiNmIxSEZTcnYvdElSODErWnl3bmFhdWNYa0l3UnlEeXlzYUQ1?= =?utf-8?B?bk13ZHdSWlhhd2F3V2xza29RbVFDaG9hNHJmNExKY3ByZktMRzFTUTFpR2ox?= =?utf-8?B?U2lSSFVETS90UFYyelFuK0xlNk84WW9LamgwQ3dDZ3BmL0wxT0w5OTdLaStV?= =?utf-8?B?d3V5UjVONmcveWlxY1dhUGFZUTVIOVBteGUySC82WU4wNVc3elFMWnBsejM2?= =?utf-8?B?TG5tNTNFNjM3RmRiRG5ramw4R013dXphOE5KdHlOTmd2VjNNZDFtZWcrOFJU?= =?utf-8?B?SnRBRUVHSUtLdTlCNFV5YW9EWVAzVlJWZ0haMDBmVVloM2NPdEFvbjVHNDFZ?= =?utf-8?B?NC9HdnJhUE9JeVVWSEJDdWhpa2tONFhYenpjTEFyZW1SV2pwSG9vZDE2UWZN?= =?utf-8?Q?9myWJpQ2e5G8m09M=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e192628-3e4d-44ca-b7c1-08df30442661 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2026 13:55:37.1842 (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: Qe0ylTRA2ZOQjduvYifjXJHYtJiQ/RvvPcZR4spQGXLK82FOht9kc/mG1MOD6ON6zc4AuZm7xJcmjo8MSqQhgg3V6kHchZmL6t/QvovWJqc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR03MB114257 X-purgate-ID: tlsNG-ebf023/1792677341-52ECEB50-82EAF931/0/0 X-purgate-type: clean X-purgate-size: 1625 On 10/20/26 11:41 PM, Stefano Stabellini wrote: > In virtual-8086 mode with IOPL < 3, INT n raises #GP(0). INT1, INT3 > and INTO are not affected. They are delivered normally. > > svm_emul_swint_injection() applies the check to all of them, so an ICEBP > raises #GP instead of #DB. It also reports the IDT entry in the #GP > error code instead of 0. > > Limit the check to INT n and use error code 0. > > Signed-off-by: Stefano Stabellini > --- > xen/arch/x86/hvm/svm/svm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 71e48351f2..df74531d1a 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1153,9 +1153,12 @@ static void svm_emul_swint_injection(struct x86_event *event) > * 32bit OS. Someone with many TUITs can see about reading the TSS > * Software Interrupt Redirection bitmap. > */ > - if ( (regs->eflags & X86_EFLAGS_VM) && > + if ( type == X86_ET_SW_INT && (regs->eflags & X86_EFLAGS_VM) && > MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) > + { > + ec = 0; > goto raise_exception; > + } > > /* > * Read all 8/16 bytes so the idtr limit check is applied properly to I think this is correct. The check could perhaps move earlier to avoid needing to reset ec to 0. I do wonder though if there are other cases in the function where ec needs to be reset to 0? The pseudocode in the APM seems to have at least one other case. Ross From xen-devel-bounces@lists.xenproject.org Thu Oct 22 14:02:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 14:02:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458229.1670628 (Exim 4.92) (envelope-from ) id 1xJtMr-00026p-Id; Thu, 22 Oct 2026 14:02:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458229.1670628; Thu, 22 Oct 2026 14:02: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 1xJtMr-00026i-Fb; Thu, 22 Oct 2026 14:02:05 +0000 Received: by outflank-mailman (input) for mailman id 1458229; Thu, 22 Oct 2026 14:02:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJtMp-00026c-U2 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:02:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJtMp-007D7D-Al for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 16:02:03 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada174e-e002-0a2a0a5209dd-0a2a4503df58-28 for ; Thu, 22 Oct 2026 16:02:03 +0200 Received: from [209.85.208.48] (helo=mail-ed1-f48.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada175b-fae8-0a2a45030019-d155d030d469-3 for ; Thu, 22 Oct 2026 16:02:03 +0200 Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-6af9a9451daso2828540a12.0 for ; Thu, 22 Oct 2026 07:02:03 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6b402f2c2dfsm1826889a12.1.2026.10.22.07.02.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2026 07:02: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=1792677723; x=1793282523; 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=QRNX6rUTXBQF2KsfYxNrV+t0oPnCnyHjH/Lci/dShOg=; b=gvBWFzMjupYix4NPAGF7dtEnx3S+S7X5Rz5unegYMVQuFiviwgxyxL7lFTezqpfFhE 0xfR9z5QIsprYvtljI56eML5PTGJqp/Ize554BU7nSvDU9PR0ttRPxK4PrfDKqB/M6i1 CUkE1mEUbzq1tm0nAiwiTAgBcknoAtZcIiLmfK/tSt/hubgpaPLLs/7QDmH1CwZq492e EfrWSxUvzq4waCrEm9S+3drSnH5cyZ3IlJwKDHW/zHOD5Bh0Sn1W9/h1XEDQ7f25XnaA UHH3jK9KwM5DS57kRbFi4/d/icRcjEMDitsagOTTsZhMaeIOJpLKGsrPluVDViHvRAHK o6aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792677723; x=1793282523; 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=QRNX6rUTXBQF2KsfYxNrV+t0oPnCnyHjH/Lci/dShOg=; b=mhrGLi69haYU2/ShsbOqGA0hnJH2jYk0GESph7VY22IwpL1X1ZOuxoWciLPy3p3zlQ NyVWEKWZJ1kgH6alyhMJctZE9jh/7k5poPyIIoM32WbA8/Xo0aY+NkFel6U0vIiQunDX JUTUKM1wfesbBpbUYyJVlojcD8msobJyt0Tl7Yx8DTl9T3ZXEGEhGLTwxxFcIurMRUOG bHOxx+P418vOE6ry4Wp0Mk373MBRlNATyKpaHY5p0s2bOaOqX23ufBiHBfglUbpzFZKy 2qM+yqDb3J2KAwJzRLUJZJm2EUJPvOV0IkBQ0PhU4oUE6cVNkKYdKuabIk/iucfJrg5I dQOw== X-Forwarded-Encrypted: i=1; AKwUvBy1fsPzOmY19JV/5rKA6bm5z4tB3LUgv9nYRYl1vmx2k3ugQRLA704cMWMR1RgnQGvuNJbaKo2Z6I4=@lists.xenproject.org X-Gm-Message-State: AFq9FYKgnVXpTKxJobQiS212aQUD4g3nXtn2DYdlAQ7iE3BuCylPAt/Y 9rDtSiFOxEeQcqu5w7VGt0ZvuZb4zFOoJZUezG/HCf3CDzhC0Y/jcBlg X-Gm-Gg: AYBFou2lpL6KPtX6dUqmxwmgKT1axk98GIPbv7z/1cdQPXh9hqepknWzL3siNUfdBZs 6jPvYSMM+diMISc2DVol0+6RQEMO07a5XQbmVZrCmFqG/2iYfzkMZjozn+DrPnLonJW74a7KocN 0/r6qEjKttL2T0qkyJaK3dlnz1nmwwkFLQyEHkxEyTec5bI4+FrammVyx6EwQrx88f+AU6kl37Y f5Q/d1rBNya1JA88D9CVNWqt1yZj+czl3rkrhRtE3fdMyJ1CMX2FcyActUnqE/9vJ1UWn2/a8ug YpBoW84tj1v58Vb5/J9Yo4Mpec0m3Re5UCf/8rZ+wLkGHrm+xr2xpFR5MQuyleYVHVUsXlkCdFN ZRfsFZzYi/SRqGuoXOpnWcpEZI06XfUWLsp+iCI9f7Lt0pesXgKKK3EtWvP0Z6BP1ynaqsP73WL MnvzRBivKaKk8wlkJ99x2RYJI0tjLYXAxJhVqU1OlWlgPDUmHXbVLl1YeBcZstFXw4hQD7AftuQ AL1HS+17H8XZSBgtqzaKp/dxLm0a5cuMyq1m6gTGgfWrq+IL8hDSUZFnDWua2FjgGR5fPMTLO9L LXOpDSgaw3CFwyekPxbtqbAqnf/tlMxLquxjrCXXQlK17Lj/Ww== X-Received: by 2002:a05:6402:11cc:b0:6aa:1112:62f2 with SMTP id 4fb4d7f45d1cf-6b408ea1659mr4951533a12.15.1792677721310; Thu, 22 Oct 2026 07:02:01 -0700 (PDT) Message-ID: <3fd7584a-786a-4742-9f3a-aee8dfa42e43@gmail.com> Date: Thu, 22 Oct 2026 16:01:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] automation/qtb: add jinja2 device trees for riscv64 smoke tests To: Baptiste Le Duc , xen-devel@lists.xenproject.org Cc: Doug Goldstein , Stefano Stabellini References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1792677723-76CF84E9-766C32E8/10/73395122804 X-purgate-type: spam X-purgate-size: 9571 On 8/27/26 11:42 AM, 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. We want to have more strong position why we need a template for host instead of using what QEMU could provide with --machinedump. Probably we want to double check again if --machinedump isn't enough... But I am okay to proceed with template too. > The template is inert on its own: the generated dtb will be used in next > patch. Please describe what the template is for instead of referring to the next patch: the commit message should stand on its own. > > 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) -#} What if virt.h here? > +{%- 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"; Probably, it could also make sense to not hard-code isa property as potentiall we could have tests with different set of extensions. Also, this is a hand-picked subset: Zicbom/Zicboz/Zicbop are missing although their block sizes are set just above. I haven't checked what will be needed in Xen to support this extension (or if we could count them as supported...) until this isn't clarified it seems like it will be better to drop: + riscv,cbop-block-size = <0x40>; + riscv,cboz-block-size = <0x40>; + riscv,cbom-block-size = <0x40>; > + mmu-type = "riscv,{{ mmu_type }}"; Xen doesn't read mmu-type from the host CPU nodes: it is parsed only from dom0less domain nodes (arch_parse_dom0less_node()). The host stage-1 mode is fixed at build time (RV_STAGE1_MODE), and the G-stage mode is detected at runtime by probing hgatp. So mmu_type has no effect on Xen, and "It varies per machine (hart count, MMU type)" doesn't hold for the MMU type. It also makes the DT inaccurate: per the binding, mmu-type is the largest translation mode the hart supports, which is sv57 for QEMU's rv64 (that's what QEMU puts there), while the default here is sv48. If the intent is to choose a guest's MMU mode, it belongs to the DomU node. > + > + cpu{{ i }}_intc: interrupt-controller@{{ i }} { The node has a unit address but no reg, which makes dtc warn (unit_address_vs_reg). QEMU and the binding use plain "interrupt-controller". It seems like removing of "@{{ i }}" could be enough. > + #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"; The binding requires compatible = "qemu,aplic", "riscv,aplic", which is also what QEMU generates. The same applies to both APLICs, and to the IMSICs below ("qemu,imsics", "riscv,imsics"). > + }; > + > + aplic@c000000 { > + riscv,delegate = <&aplic_s 0x01 {{ QEMU_IRQCHIP_NUM_SOURCES }}>; The binding names this property riscv,delegation. QEMU emits both riscv,delegate and riscv,delegation, while the template has only the former. ~ Oleksii > + 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 Thu Oct 22 14:24:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 14:24:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458265.1670638 (Exim 4.92) (envelope-from ) id 1xJti9-0005Wv-AS; Thu, 22 Oct 2026 14:24:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458265.1670638; Thu, 22 Oct 2026 14:24: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 1xJti9-0005Wo-7X; Thu, 22 Oct 2026 14:24:05 +0000 Received: by outflank-mailman (input) for mailman id 1458265; Thu, 22 Oct 2026 14:24:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJti8-0005Wi-AQ for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:24:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJti7-007H4r-Na for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 16:24:03 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada1c83-e002-0a2a0a5209dd-0a2a4505e58e-0 for ; Thu, 22 Oct 2026 16:24:03 +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 6ada1c82-4cb1-0a2a45050019-b9ff1c23b5bb-3 for ; Thu, 22 Oct 2026 16:24: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 1a163ff5306000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 14:23:59 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id AC65882AFC; Thu, 22 Oct 2026 16:23: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=vlWKZj/gYCSs7h+Jw/HshG+LXbNuQBcp1pR5RSaWgW0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=VVyLSrLYnNfXKaiaMsX3SJDxQ+r07OmDFOjR7CSd05lmHd6CPmGf0Zp984RkSUWYBZmsPsbxT BtiaFCfNV7isDmiV+JV7aas5Hh8Eoyu697q2DmJdIkw2ib/WiY4C/sekXVmky1+nczhCRS5xQzy TQHcOTpaTUpIWF74hSB9HxL5GP/nonGfSVsTEzP6KzVIIAKhC5vkFYmYXo6K5sxWLlGmijlxzkI hjom4cSjhlug848Mna2WE6lh9AC5+I+Xm5ez/vtgZzA0a6WKG/fuLsVRxVjsWnnhvZMNf6U5AHk Bix/cRN6iKpojQtUuOuQz+wffEBIv9z8vzZaD3Mitddw== X-Zone-Loop: f7bd0419009f5549d7deb07481233154afa9fa16117a x-campaign-type: default x-transaction-id: fe0a471e-dcaa-4907-8f92-b05ee1e232d6 x-swg-uid: 01-dbd07b85-caf4-4b62-adb5-ad1830cc5431 X-Mailer: Sweego Message-ID: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> x-swg-bid: 1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Julian Vetter Subject: [PATCH 0/2] tools/ocaml: bindings needed to build ARM domains Date: Thu, 22 Oct 2026 16:23:53 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.132.3cf5113902c4bef7.1a163ff503d.9c62f99227416224=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792679039037 X-purgate-ID: tlsNG-c201ff/1792679042-243112A1-0B0DF697/0/0 X-purgate-type: clean X-purgate-size: 1859 ---=Part.132.3cf5113902c4bef7.1a163ff503d.9c62f99227416224=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, this series adds two bindings that are still missing for an OCaml toolstack, to create and build ARM domains=2E Patch 1 exposes the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 bits of XEN_SYSCTL_physinfo in arm_physinfo_caps=2E Since XEN_DOMCTL_CONFIG_GIC_NATIVE was removed, the toolstack has to pick a concrete GIC version itself=2E The OCaml physinfo stub only reports the SVE vector length on ARM, so OCaml toolstacks currently can't select a GIC version=2E Patch 2 adds bindings for XEN_DOMCTL_{get,set}_paging_mempool_size=2E The existing shadow_allocation_{get,set} bindings use XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION, which are x86-only and fail with -ENOSYS on ARM, so there is no way to size the P2M pool of an ARM domain from OCaml, as libxl does=2E Even though I'm sending these patches as a series, they are somewhat independent from each other=2E But together with the patch I sent earlier today "tools/ocaml: implement stub_xc_domain_create() for ARM", they are what xenopsd needs to create ARM domains=2E Signed-off-by: Julian Vetter Julian Vetter (2): tools/ocaml: expose the supported guest GIC versions in physinfo tools/ocaml: add bindings for the paging mempool size tools/ocaml/libs/xc/xenctrl=2Eml | 7 +++++ tools/ocaml/libs/xc/xenctrl=2Emli | 6 +++++ tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 40 ++++++++++++++++++++++++++++- 3 files changed, 52 insertions(+), 1 deletion(-) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.132.3cf5113902c4bef7.1a163ff503d.9c62f99227416224=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 14:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 14:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458275.1670647 (Exim 4.92) (envelope-from ) id 1xJtlt-0006JE-Nx; Thu, 22 Oct 2026 14:27:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458275.1670647; Thu, 22 Oct 2026 14:27: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 1xJtlt-0006J7-LE; Thu, 22 Oct 2026 14:27:57 +0000 Received: by outflank-mailman (input) for mailman id 1458275; Thu, 22 Oct 2026 14:27:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJtls-0006Ip-Mg for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:27:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJtls-007EK4-0R for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 16:27:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada1d60-8faa-0a2a0a5109dd-0a2a450382b0-38 for ; Thu, 22 Oct 2026 16:27:55 +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 6ada1d6b-fae8-0a2a45030019-b9ff1c128807-3 for ; Thu, 22 Oct 2026 16:27: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.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a16402dab1000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 14:27:51 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 1179281F99; Thu, 22 Oct 2026 16:27: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=STba8BPhO18lctrNM4b/bVk5Yg4GFlOvgQptyFrgR8I=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=OFwAh8xz9d+Ir+phxkUd0U1Kc+3z8gFZqK1by0xXP15PVKTHiHImo89QZKi5m9C2K7/3xZg3u RD3aSUaFbpZvHASN888AjSYk6ZT7r7EDsZLjKgsUsGeGi8wKDgOSKqoLTiecrb6PL0tC8VNV16o NN6fT3eR2CxsXMvkHAKIvwtRNdm6GG+1XNXyqIyXXanrGHapDMmV66peUqIoLEGLj2kCoym9rqN DoqY7j80l6LiGZQR+wkyDuz1bz7tbDNScft8cbkZIYiQFSGVnVC5vkQSsHYUwng6jvkP1cLb1w5 MCda4BQbdvUTAZ5SsXSih7XbjkMRM5LL6qAfyBJ3eScw== X-Zone-Loop: 1c30074f350a1d778bc0123968c8dcddd671aae73271 x-campaign-type: default x-transaction-id: 21b912bf-b9fe-4a62-9f7e-36c6ac59efe7 x-swg-uid: 01-e47c4b2b-104e-4855-b470-403bda12b39c X-Mailer: Sweego Message-ID: <1792679271.8631fc262581453bbf619ec5b2062170.1a16402dab1000f79f@vates.tech> x-swg-bid: 1792679271.8631fc262581453bbf619ec5b2062170.1a16402dab1000f79f 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Julian Vetter Subject: [PATCH 0/2] tools/ocaml: bindings needed to build ARM domains Date: Thu, 22 Oct 2026 16:27:42 +0200 In-Reply-To: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> References: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.134.35419e23abad15a7.1a16402d803.b4b42fc80b2cf2b1=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792679270404 X-purgate-ID: tlsNG-33051d/1792679275-6DED24E9-E1DCED2C/0/0 X-purgate-type: clean X-purgate-size: 1906 ---=Part.134.35419e23abad15a7.1a16402d803.b4b42fc80b2cf2b1=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, this series adds two OCaml bindings that are still missing for an OCaml toolstack, such as xenopsd, to create and build ARM domains=2E Patch 1 exposes the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 bits of XEN_SYSCTL_physinfo in arm_physinfo_caps=2E Since XEN_DOMCTL_CONFIG_GIC_NATIVE was removed, the toolstack has to pick a concrete GIC version itself, which libxl and the Python bindings already do=2E The OCaml physinfo stub only reports the SVE vector length on ARM, so OCaml toolstacks currently can't make that choice=2E Patch 2 adds bindings for XEN_DOMCTL_{get,set}_paging_mempool_size=2E The existing shadow_allocation_{get,set} bindings use XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION, which are x86-only and fail with -ENOSYS on ARM, so there is no way to size the P2M pool of an ARM domain from OCaml, as libxl does=2E The two patches are independent of each other and each applies on its own to staging=2E Together with "tools/ocaml: implement stub_xc_domain_create() for ARM" (currently under review), they are what xenopsd needs to create ARM domains=2E Signed-off-by: Julian Vetter Julian Vetter (2): tools/ocaml: expose the supported guest GIC versions in physinfo tools/ocaml: add bindings for the paging mempool size tools/ocaml/libs/xc/xenctrl=2Eml | 7 +++++ tools/ocaml/libs/xc/xenctrl=2Emli | 9 +++++++ tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 40 ++++++++++++++++++++++++++++- 3 files changed, 55 insertions(+), 1 deletion(-) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.134.35419e23abad15a7.1a16402d803.b4b42fc80b2cf2b1=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 14:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 14:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458276.1670652 (Exim 4.92) (envelope-from ) id 1xJtlt-0006Lb-VS; Thu, 22 Oct 2026 14:27:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458276.1670652; Thu, 22 Oct 2026 14:27: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 1xJtlt-0006LT-RI; Thu, 22 Oct 2026 14:27:57 +0000 Received: by outflank-mailman (input) for mailman id 1458276; Thu, 22 Oct 2026 14:27:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJtlt-0006Iv-4o for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:27:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJtls-007EK4-HH for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 16:27:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada1d60-8faa-0a2a0a5109dd-0a2a450382b0-44 for ; Thu, 22 Oct 2026 16:27:56 +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 6ada1d6b-fae8-0a2a45030019-b9ff1c22a047-3 for ; Thu, 22 Oct 2026 16:27: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 1a16402dca1000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 14:27:51 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id CFDC2829DC; Thu, 22 Oct 2026 16:27: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=YTgXlzttAeRb/a6Ze7SHiBrWzRpbitGkHPepi++P888=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=WYfShA2TwDlXCo2WbgdTlkr0iUU2r45N5hHcYmjbVAzWxf6/5N3Wy1sXaMB2z0OaSb15LAcH0 Amya96JyTiAKm9rIY8Dnvr10xj7oyg5vyOK1vfsU0kKEk08d33d0Sb0CTHH6uQSBeax0f+kbQpf aIpJqEo0x3Y6tTHkH4Z4/yDBY1BZaj9OIEvaXYGuRyKF5nhcXypTzbkRYCRqERiTHmMK1Fzai4N 7rwbcdFf2T+WkWSjFUON46C72V2gszTKSPra5+zkdlx3gt99xK59zsyDDTW9lL0BNEUqCn1ztfr kAFngkf9SHye/QCPrefyqew5rf2iWLKClSOyb4mUwadg== X-Zone-Loop: b0e9030591f3787c542b1c4044451b51de73eabfdc91 x-campaign-type: default x-transaction-id: 9baa8ff8-8081-4996-94f8-2140296961f1 x-swg-uid: 01-f64348c7-5f4a-455e-8300-082dd017b640 X-Mailer: Sweego Message-ID: <1792679271.8631fc262581453bbf619ec5b2062170.1a16402dca1000f79f@vates.tech> x-swg-bid: 1792679271.8631fc262581453bbf619ec5b2062170.1a16402dca1000f79f 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Julian Vetter Subject: [PATCH 1/2] tools/ocaml: expose the supported guest GIC versions in physinfo Date: Thu, 22 Oct 2026 16:27:43 +0200 In-Reply-To: <20261022142744.338622-1-julian.vetter@vates.tech> References: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> <20261022142744.338622-1-julian.vetter@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.135.81e82e92c2477ead.1a16402db06.a26dc90f0669e6a3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792679271174 X-purgate-ID: tlsNG-33051d/1792679276-6CEDA4E9-9545D314/0/0 X-purgate-type: clean X-purgate-size: 3020 ---=Part.135.81e82e92c2477ead.1a16402db06.a26dc90f0669e6a3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Since XEN_DOMCTL_CONFIG_GIC_NATIVE was removed, the toolstack has to choose a concrete GIC_V2 or GIC_V3 version itself when creating an ARM domain=2E libxl and the Python bindings do so via the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 bits of XEN_SYSCTL_physinfo, but the OCaml physinfo stub only extracts the SVE vector length on ARM, so an OCaml toolstack has no way to select the GIC version=2E Add gic_v2 and gic_v3 to arm_physinfo_caps and populate them using arch_capabilities_arm_gic_v2/v3(), as is done for the Python bindings=2E Signed-off-by: Julian Vetter --- tools/ocaml/libs/xc/xenctrl=2Eml | 2 ++ tools/ocaml/libs/xc/xenctrl=2Emli | 2 ++ tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 7 ++++++- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/tools/ocaml/libs/xc/xenctrl=2Eml b/tools/ocaml/libs/xc/xenctr= l=2Eml index 582897af6d=2E=2E37e41879bb 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Eml +++ b/tools/ocaml/libs/xc/xenctrl=2Eml @@ -134,6 +134,8 @@ type physinfo_cap_flag =3D type arm_physinfo_caps =3D { sve_vl: int; + gic_v2: bool; + gic_v3: bool; } =20 type x86_physinfo_cap_flag diff --git a/tools/ocaml/libs/xc/xenctrl=2Emli b/tools/ocaml/libs/xc/xenct= rl=2Emli index 9414b87164=2E=2E7a0dd7d8ba 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Emli +++ b/tools/ocaml/libs/xc/xenctrl=2Emli @@ -119,6 +119,8 @@ type physinfo_cap_flag =3D type arm_physinfo_caps =3D { sve_vl: int; + gic_v2: bool; + gic_v3: bool; } =20 type x86_physinfo_cap_flag diff --git a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index c15a3428da=2E=2Ee0c435e346 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -35,6 +35,7 @@ #define XC_WANT_COMPAT_MAP_FOREIGN_API #include #include +#include #include =20 #include "mmap_stubs=2Eh" @@ -880,11 +881,15 @@ CAMLprim value physinfo_arch_caps(const xc_physinfo_= t *info) =20 tag =3D 0; /* tag ARM */ =20 - arch_obj =3D caml_alloc_tuple(1); + arch_obj =3D caml_alloc_tuple(3); =20 Store_field(arch_obj, 0, Val_int(MASK_EXTR(info->arch_capabilities, XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK) * 128)); + Store_field(arch_obj, 1, + Val_bool(arch_capabilities_arm_gic_v2(info->arch_capabilities))); + Store_field(arch_obj, 2, + Val_bool(arch_capabilities_arm_gic_v3(info->arch_capabilities))); =20 #elif defined(__i386__) || defined(__x86_64__) =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.135.81e82e92c2477ead.1a16402db06.a26dc90f0669e6a3=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 14:27:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 14:27:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458277.1670666 (Exim 4.92) (envelope-from ) id 1xJtlv-0006ib-7B; Thu, 22 Oct 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 1458277.1670666; Thu, 22 Oct 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 1xJtlv-0006iS-1t; Thu, 22 Oct 2026 14:27:59 +0000 Received: by outflank-mailman (input) for mailman id 1458277; Thu, 22 Oct 2026 14:27:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJtlt-0006J0-CT for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:27:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJtls-007HrS-PK for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 16:27:56 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada1d68-bab6-0a2a0a5309dd-0a2a450b8136-16 for ; Thu, 22 Oct 2026 16:27:56 +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 6ada1d6c-b7e8-0a2a450b0019-b9ff1c228743-3 for ; Thu, 22 Oct 2026 16:27: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 1a16402de81000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 22 Oct 2026 14:27:52 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 52DCB81F99; Thu, 22 Oct 2026 16:27: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=YZYoHWUJy0DmQNfTi4M3QNymJsXvmbW4+PPryWlCJhY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=d/c7jITpuHY3WqcmhNgB+73wBD/qGeLpoJCgbnFfwHuXb/HbqUGHPUpV5MuKOc9jjhVKyuygy CWW+DQnMgxVYsY3VacTWRp9ACHRPINlCCzrGUMgW08LqizFSg0gipQJnsdQ9KTMZdl0UgAB2bzm ewytCEvshMzn+qQTkLylBButPgGbi85GoiU9gvtghbDsbgvWVGVnH0k0Ovb7eM50ZQ7pkhrvrGM 6ki/1f96P5isCLX8F6vjWq86jQqJvMkrjqUTiu3LP7jgCAfm+428JCnQg/o1nllRK/IBlvVHR4x XBbhFTrm+QkUmp76l2pZhRjkY9RNQbPNpuQmLnljOB4Q== X-Zone-Loop: 1b49339cbac41f34b7e91bf6d80fb1c772c20c8a0182 x-campaign-type: default x-transaction-id: bd9cb396-7a0f-4ff2-ac40-231740af7025 x-swg-uid: 01-2734b988-cf39-4b75-852a-b1deca5ca440 X-Mailer: Sweego Message-ID: <1792679272.8631fc262581453bbf619ec5b2062170.1a16402de81000f79f@vates.tech> x-swg-bid: 1792679272.8631fc262581453bbf619ec5b2062170.1a16402de81000f79f 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Julian Vetter Subject: [PATCH 2/2] tools/ocaml: add bindings for the paging mempool size Date: Thu, 22 Oct 2026 16:27:44 +0200 In-Reply-To: <20261022142744.338622-1-julian.vetter@vates.tech> References: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> <20261022142744.338622-1-julian.vetter@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.136.be787071d18a1000.1a16402dced.52be1c3e56b91a2e=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792679271661 X-purgate-ID: tlsNG-42698a/1792679276-18CCF9EA-DF87DCF4/0/0 X-purgate-type: clean X-purgate-size: 4110 ---=Part.136.be787071d18a1000.1a16402dced.52be1c3e56b91a2e=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The OCaml bindings only expose the shadow_allocation_{get,set} functions, which use XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION=2E These are x86-only, on ARM they fail with -ENOSYS=2E So, an OCaml toolstack has no way to size the P2M pool of an ARM domain, which libxl does via XEN_DOMCTL_set_paging_mempool_size=2E So, add a pair of functions paging_mempool_size_{get,set}, which just wrap xc_{get,set}_paging_mempool_size()=2E Signed-off-by: Julian Vetter --- tools/ocaml/libs/xc/xenctrl=2Eml | 5 +++++ tools/ocaml/libs/xc/xenctrl=2Emli | 4 ++++ tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 33 +++++++++++++++++++++++++++++ 3 files changed, 42 insertions(+) diff --git a/tools/ocaml/libs/xc/xenctrl=2Eml b/tools/ocaml/libs/xc/xenctr= l=2Eml index 37e41879bb=2E=2E55cfc2e9a2 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Eml +++ b/tools/ocaml/libs/xc/xenctrl=2Eml @@ -283,6 +283,11 @@ external shadow_allocation_set: handle -> domid -> in= t -> unit external shadow_allocation_get: handle -> domid -> int =3D "stub_shadow_allocation_get" =20 +external paging_mempool_size_set: handle -> domid -> int64 -> unit + =3D "stub_xc_set_paging_mempool_size" +external paging_mempool_size_get: handle -> domid -> int64 + =3D "stub_xc_get_paging_mempool_size" + external evtchn_alloc_unbound: handle -> domid -> domid -> int =3D "stub_xc_evtchn_alloc_unbound" external evtchn_reset: handle -> domid -> unit =3D "stub_xc_evtchn_reset" diff --git a/tools/ocaml/libs/xc/xenctrl=2Emli b/tools/ocaml/libs/xc/xenct= rl=2Emli index 7a0dd7d8ba=2E=2E0d5cc94198 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Emli +++ b/tools/ocaml/libs/xc/xenctrl=2Emli @@ -210,6 +210,10 @@ external shadow_allocation_set : handle -> domid -> i= nt -> unit =3D "stub_shadow_allocation_set" external shadow_allocation_get : handle -> domid -> int =3D "stub_shadow_allocation_get" +external paging_mempool_size_set : handle -> domid -> int64 -> unit + =3D "stub_xc_set_paging_mempool_size" +external paging_mempool_size_get : handle -> domid -> int64 + =3D "stub_xc_get_paging_mempool_size" external evtchn_alloc_unbound : handle -> domid -> domid -> int =3D "stub_xc_evtchn_alloc_unbound" external evtchn_reset : handle -> domid -> unit =3D "stub_xc_evtchn_reset= " diff --git a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index e0c435e346=2E=2Eef3d16beaa 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -1259,6 +1259,39 @@ CAMLprim value stub_shadow_allocation_set(value xch= _val, value domid, CAMLreturn(Val_unit); } =20 +CAMLprim value stub_xc_get_paging_mempool_size(value xch_val, value domid= ) +{ + CAMLparam2(xch_val, domid); + xc_interface *xch =3D xch_of_val(xch_val); + uint64_t c_size; + int ret; + + caml_enter_blocking_section(); + ret =3D xc_get_paging_mempool_size(xch, Int_val(domid), &c_size); + caml_leave_blocking_section(); + if (ret !=3D 0) + failwith_xc(xch); + + CAMLreturn(caml_copy_int64(c_size)); +} + +CAMLprim value stub_xc_set_paging_mempool_size(value xch_val, value domid= , + value size) +{ + CAMLparam3(xch_val, domid, size); + xc_interface *xch =3D xch_of_val(xch_val); + uint64_t c_size =3D Int64_val(size); + int ret; + + caml_enter_blocking_section(); + ret =3D xc_set_paging_mempool_size(xch, Int_val(domid), c_size); + caml_leave_blocking_section(); + if (ret !=3D 0) + failwith_xc(xch); + + CAMLreturn(Val_unit); +} + CAMLprim value stub_xc_domain_ioport_permission(value xch_val, value domi= d, value start_port, value nr_ports, value allow) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.136.be787071d18a1000.1a16402dced.52be1c3e56b91a2e=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 14:55:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 14:55:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458323.1670673 (Exim 4.92) (envelope-from ) id 1xJuCA-0003GN-6P; Thu, 22 Oct 2026 14:55:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458323.1670673; Thu, 22 Oct 2026 14: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 1xJuCA-0003GG-3K; Thu, 22 Oct 2026 14:55:06 +0000 Received: by outflank-mailman (input) for mailman id 1458323; Thu, 22 Oct 2026 14:55:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJuC8-0003GA-B1 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 14:55:04 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xJuC8-00000007PLu-1EEB; Thu, 22 Oct 2026 14:55:04 +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.98.2) (envelope-from ) id 1xJuC7-00000009kdA-3tIk; Thu, 22 Oct 2026 14:55: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=sWaWDlZ1Q97j4RqGrs5N9Ud1PBkvXaHeJEj8Fmpm/pU=; b=gM7cwc7lS0xZX8q+98RMUoWn+E Rkix+svXHORzmqXevbXw1su9YzqshRzrbf5M0ugPvKGIrxoRq9+5nrLqpqBpvrh/y4riEBFEqG9Ge b1s5X0RfBD8IhZ+YCpEWv7HE7SFXfhzakiTx+Qv+TRcjCluavLem5COSzGdEfdu/PLqs=; Date: Thu, 22 Oct 2026 16:54:58 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v4 01/30] x86/PoD: map one page at a time in p2m_pod_zero_check() Message-ID: References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-1-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261019-asi-hvm-v4-1-b68b66652266@xenproject.org> On Mon, Oct 19, 2026 at 08:42:32PM +0100, George Dunlap wrote: > p2m_pod_zero_check() maps every page of its batch that passes its > checks, up to POD_SWEEP_STRIDE (16) of them, and keeps them mapped > across the p2m lookups and updates which follow, each of which maps > page-table pages of its own. Its callers hold mappings too: the p2m > lookup which found the entry to populate still has its page-table page > mapped, and a PV mmu_update() the L1 page it is writing. > > map_domain_page() cannot always provide that many at once. It uses the > mapcache on behalf of PV vCPUs only: in debug builds for every page, in > release builds for pages beyond the reach of the directmap in PV guests' > page-tables (5TiB, 3.5TiB with CONFIG_BIGMEM). This is IMO too verbose. It doesn't add any value to the justification here what's the memory limit at which the mapcache starts to be used. I also don't think it's relevant to list what causes mapcache to be used in general. It just distracts from the justification of the change, by making the patch description unwieldy long. > The mapcache has > MAPCACHE_VCPU_ENTRIES (16) slots per vCPU of the domain, shared by its > vCPUs, and a mapping which finds no slot free or reclaimable hits the > BUG_ON() in map_domain_page(): the host crashes. > > The sweep runs in the context of whichever vCPU populates a PoD entry > while the domain's PoD cache is empty. The guest's own vCPUs, being > HVM, map through the directmap; a PV vCPU gets there when its domain > maps or copies the guest's memory: a device model in dom0 or in a stub > domain, a backend doing grant copies. A PV domain with a single vCPU, > as a device-model stub domain or a dom0 booted with dom0_max_vcpus=1 > is, has 16 slots, and a sweep over 16 candidate pages needs more. > > The sweep has mapped its whole batch at once since 9ad9a1609fbe ("PoD > memory 5/9: emergency scan"), when x86-64 reached all memory through the > directmap. The per-vCPU budget came with the mapcache's return to > x86-64 in 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al"). > > Map one page at a time instead, as p2m_pod_zero_check_superpage() > already does: map a page for the quick check and unmap it again, and > map it anew for the full check after the p2m update and the TLB flush. > The checks and their order are unchanged. Each page is mapped twice, > which costs little next to scanning it, and the error paths no longer > have mappings to undo. > > Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al") > Assisted-by: Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap Acked-by: Roger Pau Monné I've got one suggestion below, but doesn't change the logic. > --- > Changes in v4: > - Track the pages to check in a bitmask walked with for_each_set_bit(), > not an array of bools (Andrew). > - Drop the new comment above the first loop; edit the old one's "and map > the pages" instead (Andrew). > > NB this issue was raised in review and verified only by code > inspection; it hasn't been demonstrated. > --- > xen/arch/x86/mm/p2m-pod.c | 72 +++++++++++++++++---------------------- > 1 file changed, 31 insertions(+), 41 deletions(-) > > diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c > index 4602c32cff..ed298fa7d2 100644 > --- a/xen/arch/x86/mm/p2m-pod.c > +++ b/xen/arch/x86/mm/p2m-pod.c > @@ -901,9 +901,10 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > { > mfn_t mfns[POD_SWEEP_STRIDE]; > p2m_type_t types[POD_SWEEP_STRIDE]; > - unsigned long *map[POD_SWEEP_STRIDE]; > + unsigned int check = 0; > + const unsigned long *map; > struct domain *d = p2m->domain; > - unsigned int i, j, max_ref = 1; > + unsigned int j, max_ref = 1; > > BUG_ON(count > POD_SWEEP_STRIDE); > > @@ -911,8 +912,11 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > if ( paging_mode_shadow(d) ) > max_ref++; > > - /* First, get the gfn list, translate to mfns, and map the pages. */ > - for ( i = 0; i < count; i++ ) > + /* > + * First, get the gfn list, translate to mfns, and check for being a > + * plausible candidate. > + */ > + for ( unsigned int i = 0; i < count; i++ ) > { > p2m_access_t a; > > @@ -921,9 +925,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > > /* > * If this is ram, and not a pagetable or a special page, and > - * probably not mapped elsewhere, map it; otherwise, skip. > + * probably not mapped elsewhere, check it; otherwise, skip. > */ > - map[i] = NULL; > if ( p2m_is_ram(types[i]) ) > { > const struct page_info *pg = mfn_to_page(mfns[i]); > @@ -932,7 +935,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count > (pg->count_info & PGC_allocated) && > !(pg->count_info & PGC_shadowed_pt) && > ((pg->count_info & PGC_count_mask) <= max_ref) ) > - map[i] = map_domain_page(mfns[i]); > + check |= 1U << i; Not that I have a strong opinion, but I think it's clearer if you use __{set,clear}_bit(). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Oct 22 15:16:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 15:16:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458353.1670683 (Exim 4.92) (envelope-from ) id 1xJuWd-0006nr-Sy; Thu, 22 Oct 2026 15:16:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458353.1670683; Thu, 22 Oct 2026 15: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 1xJuWd-0006nk-QE; Thu, 22 Oct 2026 15:16:15 +0000 Received: by outflank-mailman (input) for mailman id 1458353; Thu, 22 Oct 2026 15:16:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xJuWd-0006ne-7D for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 15:16:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJuWc-00BcQ9-KK for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 17:16:14 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada28bd-e002-0a2a0a5209dd-0a2a4508dc82-14 for ; Thu, 22 Oct 2026 17:16:14 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada28b3-f659-0a2a45080019-d155dd2fe93c-3 for ; Thu, 22 Oct 2026 17:16:03 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48bbb06e746so1238349f8f.3 for ; Thu, 22 Oct 2026 08:16:03 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e2583523asm12984219f8f.37.2026.10.22.08.16.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2026 08:16: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: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=1792682163; x=1793286963; 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=XOY5V2I7WVNx7NuhLs0lweaAB5/YgZ23anQKEeEyg14=; b=V5E3ZJuoSlOG1npgfr8WfFtOEMBwSCPaoxAkPApjMUPwwK/PxIGo8kVy8GKOxT/cfN BqlN3AOjAguMcddZwd5GrzoU4ByAUzXo61IiBGXo3zKandYK1UFyrr3CVpf25Cf1sWRv WsNJXAjjZIWYI+jlrma86Jk0c8nbb3ZZLqnpzN7DNN6RAXv2/57EbNXPiuex7NmeKFEW cPmcJzHx+KOfrJDKxHm2eAOMuFLGdcHhcqQrEsjRd1kuoaZL2/NOYra8AUEjDwxr4+BX 2zX1gQ9XKMFSBcuwmY6u2M6avcWtRK0rfT2pPKUgw6fIjcpNN6KiSs394o5y/x4ypsGj kJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792682163; x=1793286963; 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=XOY5V2I7WVNx7NuhLs0lweaAB5/YgZ23anQKEeEyg14=; b=SmOMgarVOp/HNulDRJBT95ARX31vv0gDcck4SQyyrojbgkFqDyjq+QNfkHilaYRHEk 8iiD+YVKRcLqIYa4Dyq4tTvtZEBlcIPQf3/EFNTbN24NOMqfx6x68GCj1sxWfecmL98a 0NmcFlmpokJuvcVxBrGMintH/zYs/2oKwg0lOCBm3yp+W9FnpDhvunaW35PCXY0qflu0 F73g0wfEnsCKixldpMhVLTLmr+Ggdrh7l5b7o9/GI0VX3LPTYRR2SJg8hLdPbP55kKpC j+t4Hs2wUE6cUMTJIU4bd3j1H63AKMjTDIhP0g3zXz5EmCMbPCmiX4StSqqUXchzSSCR Qb7Q== X-Forwarded-Encrypted: i=1; AKwUvBwQ3CaaTvlVYUIG2rESfBXHwG+uMfcYAE5/K9bhYe8aN9zmABmHysHsBhX1WcFFCW/G+vRjhIu8jZk=@lists.xenproject.org X-Gm-Message-State: AFq9FYKP2AQiokgO5SpnzOXWXoD5Gisd9XvLSGSO8Qgm9VLtd85Yh8rS zKcfTPZvRtdzaAil58//dKBKPhDDsdgg3VI6BpGb2LQuatBEoyHqFIUl X-Gm-Gg: AYBFou22vMgLzrcJW+da86YfuxmVD6qNfya+l/P842M5QB3bRBLdui/X/dk4SA+uyhC +Zlr6Sa0csbVMf41o6QGJzZjjNJAm6QONYMxNxoatcmNSm4GO/EDC2WQmtepzp6ZTAblQPQJf9i D5PFI1z8tI9/Pw+dda3GiAUy0hhn6i+sX45aa9YY6ZslP6W28aovCxLXJtIP3hooURxb+AyXfYY 8Qktsw7xNWgNM/05IxSyA4060SOPY2U/u3UkI3tq0OIKfOvHAbdYqHFrnmMsvL+smMjdnviHETF 8RWKVJIFouKgGj3AzUojtysXrt38BI2vDo/cessBWb1fCZyYgb3+mpiiBfBu4OmoXNmRMUORIsd Nipt3+toV70qN/96O+MRnBZfLfRjA9LYvcocX2B4d4649OVq87OIqz4Uxg+V3OjixDfW3dI6RmR Uon5BjdQfX3Y8dOpoSfwRK4OBBxlaJ3E5vGIx3WjHPt0eRGqpJBbXfNHw71Wuo4jZmsAupwkNIu N68cf4oTPag5ZtB4L8sHH60MyKrohb/G7v6CBZGuA8RtTgUlJwioNEUP12Su5crTKMAqXdeTgJE +6oaxvCjmeEKBZ92m2RnwfxedBCA X-Received: by 2002:a05:6000:40db:b0:488:8ab9:f74c with SMTP id ffacd0b85a97d-48e2644ef10mr12981926f8f.3.1792682162671; Thu, 22 Oct 2026 08:16:02 -0700 (PDT) Message-ID: <008e9c3e-07ae-4ee0-9aed-b132db796fac@gmail.com> Date: Thu, 22 Oct 2026 17:15:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] automation/qtb: add Python QTB framework with the console-test type To: Baptiste Le Duc , xen-devel@lists.xenproject.org Cc: Doug Goldstein , Stefano Stabellini References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1792682163-CF95A87B-DD8CC60E/10/73395122804 X-purgate-type: spam X-purgate-size: 19594 On 8/27/26 11:42 AM, Baptiste Le Duc wrote: [...] > > diff --git a/automation/scripts/qemu_smoke_riscv64.py b/automation/scripts/qemu_smoke_riscv64.py > new file mode 100755 > index 0000000000..f338fafcc2 > --- /dev/null > +++ b/automation/scripts/qemu_smoke_riscv64.py > @@ -0,0 +1,122 @@ > +#!/usr/bin/env python3 > +# SPDX-License-Identifier: GPL-2.0-only > +"""CLI launcher for the qtb riscv64 dom0less tests. > + > +The test type comes first (e.g. `console-test`), then a command. Each type > +reads its own config file, which ships with the type. > + > +Commands: > + list Print every test the type defines in the config, then exit. > + run Boot one test's machine under QEMU and drive it to a pass/fail > + verdict. > + > +Usage: > + ./qemu_smoke_riscv64.py console-test list > + ./qemu_smoke_riscv64.py console-test run dom0less-1smp-0domu-1vcpu-aplic-imsic-null > +""" > + > +from __future__ import annotations > + > +import argparse > +import logging > +import sys > +from collections.abc import Sequence > +from traceback import extract_tb, format_exc > + > +from qtb.riscv import RiscvQtbTest, TEST_TYPES, RiscvTestMachine, cleanup_temp_dir > + > +logger = logging.getLogger(__name__) > + > + > +def _run_test(test: RiscvQtbTest, log_dir: str | None) -> int: > + """Compile the machine's device trees, boot it, and run the test.""" > + vm = RiscvTestMachine(test.machine, timeout=test.timeout, log_dir=log_dir) > + try: > + with vm: > + vm.launch() > + test.run(vm) > + except Exception as exc: > + print( > + f"FAIL: {test.name}: {type(exc).__name__}: {exc}", > + file=sys.stderr, > + flush=True, > + ) > + return 1 This is all that ends up in the job log when the test fails. I made a test wait for a string which never appears, and the whole output was: FAIL: never-matches: TIMEOUT: Timeout exceeded. searcher: searcher_string: 0: b'THIS STRING NEVER APPEARS' Together with mirror_console=False (see machine.py below), there isn't a single line of Xen's output in the job log, whereas qemu-smoke-riscv64.sh puts the whole console there. Finding out where Xen stopped then requires downloading con0.log from the artifacts. Also, as this catches every exception and prints only its message, a bug in the framework itself is reported the same way, with no traceback even with -v. > + > + print(f"PASS: {test.name}", flush=True) > + return 0 [...] > diff --git a/automation/scripts/qtb/riscv/config.py b/automation/scripts/qtb/riscv/config.py > new file mode 100644 > index 0000000000..b5068d6bfb > --- /dev/null > +++ b/automation/scripts/qtb/riscv/config.py > @@ -0,0 +1,119 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +"""YAML config parser for qtb-based Xen riscv64 tests. > + > +Parsing steps: > + - validate the YAML > + - build the dataclasses: the host device tree is compiled on first use > + of MachineConfig.dt > +""" > + > +from __future__ import annotations > + > +import functools > +import inspect > +from dataclasses import dataclass > +from functools import cached_property > +from pathlib import Path > + > +import yaml > + > +from .paths import resolve_binary, resolve_path > +from .xen_dt import DeviceTree, build_xen_device_tree > + > +XEN_MMU_TYPE_DEFAULT: str = "sv48" See my reply to patch 2: Xen doesn't read mmu-type from the host CPU nodes, so this has no effect on it. > +XEN_BOOTARGS_DEFAULT: str = "" > + > +MACHINE_MEMORY: int = 2048 > +MACHINE_INTERRUPT_CONTROLLER: str = "aplic-imsic" > + > + > +def required_keys(argument_name: str, keys: set, label: str = ""): > + """Validate the dict passed as `argument_name` has every key in `keys`.""" This is a lot of machinery (binding the decorated function's signature through inspect) just to check that two or three keys are present, and it doesn't catch the mistakes one is likely to make in config.yaml. What I got (with help of AI) for a few of them: - an empty machine entry: config.py:40: 'NoneType' object has no attribute 'keys' - pcpu: "two": qemu-host.dts.j2:52: 'str' object cannot be interpreted as an integer - pcpu: 0: the DT is generated and QEMU is launched, which then fails with "Invalid CPU topology". A few explicit checks (pcpu is an integer >= 1, an entry is a mapping, ...) would be both simpler and more useful. MachineConfig.from_config() doesn't use the decorator either and checks its keys by hand, so the same file has two ways of doing the same thing. > + keys = set(keys) > + > + def decorate(func): > + sig = inspect.signature(func) > + > + @functools.wraps(func) > + def wrapper(*args, **kwargs): > + arg = sig.bind(*args, **kwargs).arguments[argument_name] > + missing = keys - arg.keys() > + if missing: > + raise ValueError( > + f"{label or func.__name__} missing keys: {sorted(missing)}" > + ) > + return func(*args, **kwargs) > + > + return wrapper > + > + return decorate > + > + > +@dataclass > +class BinariesConfig: > + xen: Path > + > + > +@required_keys("raw", {"xen"}, label="binaries config") > +def _parse_binaries(raw: dict) -> BinariesConfig: > + return BinariesConfig(xen=resolve_binary(raw["xen"])) > + > + > +@required_keys("raw", {"pcpu"}, label="machine config") > +def _parse_machine( > + raw: dict, > + binaries: BinariesConfig, > + machine: str, > +) -> MachineConfig: > + return MachineConfig( > + name=machine, > + pcpu=raw["pcpu"], > + binaries=binaries, > + mmu_type=raw.get("mmu_type", XEN_MMU_TYPE_DEFAULT), > + xen_bootargs=raw.get("xen_bootargs", XEN_BOOTARGS_DEFAULT), > + ) > + > + > +@dataclass(frozen=True) > +class MachineConfig: > + """One named machine: the test-agnostic description of what to boot. > + > + A machine is reusable across test types; a test (see RiscvQtbTest > + subclasses) picks a machine by name and layers its own parameters on top. > + """ > + > + name: str > + pcpu: int > + binaries: BinariesConfig > + mmu_type: str # Xen (host) MMU type, injected into the host dts cpus. > + xen_bootargs: str > + > + @classmethod > + def from_config(cls, file_name: str, machine: str) -> MachineConfig: > + """Build only the single named machine from the catalog at `path`. > + > + A test run boots one machine, so there is no need to construct the > + whole catalog: parse the YAML, validate the shared binaries, and > + build just the requested entry. > + """ > + fpath: Path = resolve_path(file_name) > + raw: dict = yaml.safe_load(fpath.read_text()) > + > + required = ("binaries", "machines") > + missing = [k for k in required if k not in raw] > + if missing: > + raise ValueError(f"Global config {file_name} missing keys: {missing}") > + > + binaries: BinariesConfig = _parse_binaries(raw["binaries"]) > + > + machines = raw["machines"] > + if machine not in machines: > + known = ", ".join(sorted(machines)) or "(none)" > + raise ValueError(f"unknown machine {machine!r}; known machines: {known}") > + > + return _parse_machine(machines[machine], binaries, machine) > + > + @cached_property > + def dt(self) -> DeviceTree: > + """Host device tree, compiled on first use.""" > + return build_xen_device_tree(self) [...] > diff --git a/automation/scripts/qtb/riscv/console_test/console_test.py b/automation/scripts/qtb/riscv/console_test/console_test.py > new file mode 100644 > index 0000000000..95540fd388 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/console_test/console_test.py > @@ -0,0 +1,145 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +"""Console string expectation test (`type: console-test`). > + > +Per console: assert each expected string is printed within the timeout. > +Nothing is injected; this only watches console output. > + > +YAML (console-test.yaml): each test names the machine it boots (tests may > +share one) and maps a console index to the string(s) expected on it: 0 is > +Xen's own console. > + > + machine_catalog: config.yaml > + tests: > + dom0less-1smp-0domu-1vcpu-aplic-imsic-null: # test name (run positional) > + machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null # from config.yaml > + expect: # console index -> string(s) > + 0: [All set up] > +""" > + > +from __future__ import annotations > + > +import logging > +from typing import ClassVar > + > +import pexpect > +import yaml > + > +from ..paths import resolve_path > +from ..config import MachineConfig, required_keys > +from ..qtb_test import TIMEOUT_DEFAULT, RiscvQtbTest > +from ..machine import RiscvTestMachine > + > +logger = logging.getLogger(__name__) > + > +TYPE_ID: str = "console-test" > + > +CONFIG_FILE_DEFAULT: str = "console_test/console-test.yaml" > +DESCRIPTION_DEFAULT: str = "Assert expected string(s) are printed on the Xen console" > +ATTEMPTS_DEFAULT: int = 3 > + > +XEN_CONS_IDX: int = 0 > + > + > +class ConsoleTest(RiscvQtbTest): > + type_id: ClassVar[str] = TYPE_ID > + description: ClassVar[str] = DESCRIPTION_DEFAULT > + config_file: ClassVar[str] = CONFIG_FILE_DEFAULT > + > + def __init__(self, raw: dict, test_name: str) -> None: > + self.name, self.data, self.machine = self._parse_test_cfg(raw, test_name) > + > + self.expect = self.data["expect"] # expected console string > + > + self.timeout = int(self.data.get("timeout", TIMEOUT_DEFAULT)) > + if self.timeout < 1: > + raise ValueError("timeout < 1, must be at least 1") > + > + self.attempts = int(self.data.get("attempts", ATTEMPTS_DEFAULT)) > + if self.attempts < 1: > + raise ValueError("attempts < 1, must be at least 1") > + > + @staticmethod > + def _load_yaml(path) -> dict: > + return yaml.safe_load(resolve_path(path).read_text()) > + > + @classmethod > + def from_config(cls, config_file: str, test_name: str) -> ConsoleTest: > + return cls(cls._load_yaml(config_file), test_name) > + > + @staticmethod > + @required_keys("test_data", {"machine", "expect"}) > + def _parse_test_data( > + machine_catalog: str, test_data: dict, test_name: str > + ) -> tuple[str, dict, MachineConfig]: > + """Parse test data dictionary""" > + test_machine = MachineConfig.from_config(machine_catalog, test_data["machine"]) > + > + def invalid(why: str) -> ValueError: > + return ValueError( > + f"test {test_name!r}: {why}; expected " > + f"{{{XEN_CONS_IDX}: ['str1', 'str2', ...]}}" > + ) > + > + expect = test_data["expect"] > + if not isinstance(expect, dict) or expect.keys() != {XEN_CONS_IDX}: > + raise invalid( > + f"expect must map console index {XEN_CONS_IDX} (Xen's own " > + f"console, the only one) and nothing else, got {expect!r}" > + ) > + strings = expect[XEN_CONS_IDX] > + if not isinstance(strings, list): > + raise invalid( > + f"{ConsoleTest.config_file} expects a list of string(s), " > + f"got {type(strings).__name__}" > + ) > + if not strings: > + raise invalid("Xen has no expected string") > + if not all(isinstance(s, str) and s for s in strings): > + raise invalid(f"Xen expects non-empty strings, got {strings!r}") > + return (test_name, test_data, test_machine) > + > + @staticmethod > + @required_keys("raw", {"machine_catalog", "tests"}) > + def _parse_test_cfg(raw: dict, test_name: str) -> tuple[str, dict, MachineConfig]: > + """Read the config: return the named test dict and its machine.""" > + > + tests = raw["tests"] > + if test_name not in tests: > + known = ", ".join(sorted(tests)) or "(none)" > + raise ValueError(f"unknown test {test_name!r}; known tests: {known}") > + > + test_data = tests[test_name] > + return ConsoleTest._parse_test_data( > + raw["machine_catalog"], test_data, test_name > + ) > + > + @staticmethod > + def list_tests(config_file: str) -> list[str]: > + tests = ConsoleTest._load_yaml(config_file).get("tests") > + if not tests: > + logger.warning("no 'tests' key found in %s", config_file) > + return [] > + return list(tests) > + > + @staticmethod > + def _console(vm: RiscvTestMachine): > + """Xen's own console (con0).""" > + if vm.console is None: > + raise RuntimeError("Xen console not wired up, machine not launched?") > + return vm.console > + > + def run(self, vm: RiscvTestMachine) -> None: > + cons = self._console(vm) > + for strings in self.expect.values(): > + for s in strings: > + self._expect_string(cons, s) > + > + def _expect_string(self, cons, expected: str) -> None: > + """Wait for `expected` on the console, retrying on timeout.""" > + for attempt in range(self.attempts): > + try: > + cons.expect_exact(expected, timeout=self.timeout) > + return > + except pexpect.TIMEOUT: > + if attempt == self.attempts - 1: > + raise Nothing is actually retried here: on a timeout, expect_exact() is just called again on the same stream, so "attempts" only multiplies the timeout. With timeout: 5 and attempts: 3, the failing test above gave up after exactly 15 seconds, and with the defaults it is a single 360 second wait per string. I'd drop attempts and keep only timeout. Also, console.exp, which the other QEMU and hardware tests use, honours TEST_TIMEOUT and TEST_TIMEOUT_OVERRIDE, while this ignores them. [...] > diff --git a/automation/scripts/qtb/riscv/machine.py b/automation/scripts/qtb/riscv/machine.py > new file mode 100644 > index 0000000000..74a05dfc82 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/machine.py > @@ -0,0 +1,57 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +"""QtbMachine for riscv64.""" > + > +from __future__ import annotations > + > +from collections.abc import Sequence > + > +from qemu.qtb import QtbMachine > + > +from .config import MACHINE_INTERRUPT_CONTROLLER, MACHINE_MEMORY, MachineConfig > +from .paths import resolve_from_path > + > + > +class RiscvTestMachine(QtbMachine): > + arch_name = "riscv64" > + gdb_arch = "riscv:rv64" > + > + qemu_bin = "qemu-system-riscv64" > + > + def __init__( > + self, > + mc: MachineConfig, > + *, > + timeout: int, > + log_dir: str | None = None, > + ) -> None: > + self.machine_conf = mc > + super().__init__( > + memory=MACHINE_MEMORY, > + cpus=mc.pcpu, > + mirror_console=False, Why not mirror the console? QTB's own from_argv() mirrors it unless --no-mirror is given, and with it the job log would contain Xen's output, as it does today. > + timeout=timeout, > + log_dir=log_dir, > + ) > + [...] > diff --git a/automation/scripts/qtb/riscv/paths.py b/automation/scripts/qtb/riscv/paths.py > new file mode 100644 > index 0000000000..237f1bf502 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/paths.py > @@ -0,0 +1,60 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +"""Path helpers: resolve pkg-relative paths.""" > + > +from __future__ import annotations > + > +import os > +import shutil > +import tempfile > +from functools import lru_cache > +from pathlib import Path > + > +# Every relative path in this module is resolved against this base. > +_BASE = Path(__file__).resolve().parent > + > +# Build artifacts, overridable for CI. > +_BINARIES_BASE = Path(os.environ.get("QTB_BINARIES_DIR") or _BASE / "binaries") So by default xen is looked for in automation/scripts/qtb/riscv/binaries/, while every other script in automation/scripts/ uses binaries/ at the top of the tree. Without QTB_BINARIES_DIR, a run from the top of the tree fails with "cannot resolve '.../automation/scripts/qtb/riscv/binaries/xen': does not exist", and "resolved under binaries/" in the README (patch 5) doesn't make that clear either. Defaulting to binaries/ at the top of the tree would follow the existing convention, and patch 6 wouldn't need to set QTB_BINARIES_DIR. [...] > diff --git a/automation/scripts/qtb/riscv/xen_dt.py b/automation/scripts/qtb/riscv/xen_dt.py > new file mode 100644 > index 0000000000..8881b01b36 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/xen_dt.py > @@ -0,0 +1,58 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +"""Build the Xen host device tree for a MachineConfig. > + > +The tree is rendered from its Jinja2 template (dts/qemu-host.dts.j2), which > +takes the hart count, the Xen MMU type and the Xen command line, then compiled > +to a DTB with dtc. > +""" > + > +from __future__ import annotations > + > +from dataclasses import dataclass > +from functools import lru_cache > +from pathlib import Path > +from typing import TYPE_CHECKING > +from jinja2 import Environment, FileSystemLoader > + > +from .paths import resolve_path, temp_dir > +from .dt import compile_to_dtb, write_dts > + > +if TYPE_CHECKING: # config imports this module, so only import it for typing. > + from .config import MachineConfig > + > +# Directory holding the Jinja2 platform device tree templates. > +_DTS_DIR = "dts" > + > + > +@dataclass(frozen=True) > +class DeviceTree: > + """Compiled device trees for one machine launch.""" > + > + dts: Path > + dtb: Path > + > + > +@lru_cache(maxsize=1) > +def _env() -> Environment: > + return Environment( > + loader=FileSystemLoader(resolve_path(_DTS_DIR)), > + keep_trailing_newline=True, > + ) > + > + > +def _render_xen_dts(machine: MachineConfig) -> str: > + """Render the Xen host device tree source text for `machine`.""" > + tmpl = _env().get_template("qemu-host.dts.j2") > + return tmpl.render( > + ncpus=machine.pcpu, > + mmu_type=machine.mmu_type, > + xen_bootargs=machine.xen_bootargs, > + ) > + > + > +def build_xen_device_tree(machine: MachineConfig) -> DeviceTree: > + """Compile `machine` device tree into the shared scratch dir.""" > + out = temp_dir() The scratch dir is removed on exit, so after a failed run --log-dir contains only con0.log and the qtest log, and there is no way to see which DT Xen was booted with. Could the .dts be copied to --log-dir as well? ~ Oleksii > + dts: Path = write_dts(_render_xen_dts(machine), machine.name, out) > + dtb: Path = compile_to_dtb(dts, out) > + return DeviceTree(dts=dts, dtb=dtb) From xen-devel-bounces@lists.xenproject.org Thu Oct 22 17:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 17:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458457.1670692 (Exim 4.92) (envelope-from ) id 1xJwHO-0005Mq-KT; Thu, 22 Oct 2026 17:08:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458457.1670692; Thu, 22 Oct 2026 17:08: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 1xJwHO-0005Mi-Fq; Thu, 22 Oct 2026 17:08:38 +0000 Received: by outflank-mailman (input) for mailman id 1458457; Thu, 22 Oct 2026 17:08:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJwHN-0005Mc-0G for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 17:08:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJwHM-00EGEk-5v for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 19:08:36 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada42c7-2eae-0a2a0a5409dd-0a2a4504bc54-24 for ; Thu, 22 Oct 2026 19:08:36 +0200 Received: from [52.101.85.30] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada4312-b57f-0a2a45040019-3465551e979b-3 for ; Thu, 22 Oct 2026 19:08:35 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH2PR03MB5301.namprd03.prod.outlook.com (2603:10b6:610:9d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Thu, 22 Oct 2026 17:08: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%4]) with mapi id 15.21.0546.016; Thu, 22 Oct 2026 17:08: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=ifMDwCHEwRHq13CmiVej6qb1F3hoR+ule+o+kvKDz8NO+4rU6F/qxxumOpjmsEi4ucBU3O4DPCDS5kRS4973IwEvQiaeN/KOuabEDLqJchneUKgeBsCQnhzc+jITvvSRUEAFca9Oi0iS7VZ4JT0r4yrwUaY7gEEp/wUVW29qtpMsg+TG++uCD4aWEWaNZlLPgEwLNoaJCx4FY8ocwAhUUk0APPxgT1KRE0GI2IHtoBKwpu1f/1sbGVXpUbgTYfUtYeS6L22kCJVN17kPkIsFR/yaI0aszo/RKOKn+SGXcYfMfbeQL+CoKpKPJ9lBR9W7gcUpfmM2XKx8M81zNnqBAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A7LXFtEsWDolrsJFGMGXmMfEF4jyBd86w9aFZXL3WXU=; b=woOQcPKKiGccmq5dXWSm/l6NK8P/5LVbqR4wq1ljgImyILal3l9ly5skS+/IXYuyUqObx0LeFF40RL7PCqLJe6Vbf/zjAN17ZXr83zTRWYAqpiee0VOg+C2WU+abVFhXpw+XLlNbv7Mwd9e75uLS278apiqlgceZtKlkdZo/PeJD4sjJnEcGHMtEIRyd47fWsqNGT9pqmdkIi86xdW0SlJ120ULowRMtr+2Ec8OZngNN8e8Wg97cR4m5Ld6GoKnwBMaiRyk/VEPl/GA4sYs4GZvf15Io8p78TVnYJVuhLFKMtjcRwLuu5hp6R8mxsiaV0cDx72CvdDWuffKt4fiiQA== 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=A7LXFtEsWDolrsJFGMGXmMfEF4jyBd86w9aFZXL3WXU=; b=fcBMeCk1jMiuPUqLd8Y5iCIAXjIiVGiWAIDlPjoqnu4k6dI8BSc3mVSYwgYphc6tAkjWE3Ui/D1HgqPXReBChJy9qy8+brE4HjMxFHD3FfqvkmFSXKiArcxaKCUXOiB7LzvQGYHcjYmYEo/0bufYY9oUAVSN+TVB/cG8GCQjTMA= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <192c430b-565b-4b89-957b-01b80ede9049@citrix.com> Date: Thu, 22 Oct 2026 18:08:26 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: [PATCH] xen/x86/svm: Apply the virtual-8086 IOPL check to INT n only To: Ross Lagerwall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261020224123.3710391-1-stefano.stabellini@amd.com> <86d6b7b5-41f2-41b4-8710-7356c78fd15e@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: <86d6b7b5-41f2-41b4-8710-7356c78fd15e@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PR3P191CA0050.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:55::25) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH2PR03MB5301:EE_ X-MS-Office365-Filtering-Correlation-Id: 14ad8888-a909-4a99-7927-08df305f18fc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|56012099006|4143699003|11063799006|261021121427099003|261009223027099003|261021123027099003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: vSaW3PJPBIf//IdvaI0aKrV2QxMlknSKHDxV91+mJlSTbsRLIKxHG9C5F+aUtpB2zXXtOXlZRiNSDaOHbWsCqTxB7T7Bam5LR0uxJQxoXI2JoSOmuEjU0dd5KwKm8dz4uhH6LtuI5467Y3pX9APTsSmleXznbFY0RtooIt/aEsZE25BDTfGi+miUiDh6E+vNYXrWH2aAW/2OUdDMvFvAu3Wize9yywv3ALTy4mE0ndv/iT4ZTb9xgq3mOlToLxd6ecV5RNmp5xFk4quH1kwwY3VXy/y+UKqaRsRuEEWRtx8R1GKPK8RTxXlD7pLn3IcNFyMfKRl+SZgqrGe36IL/XSXSpHJ+KxWlbtS9hTF1rZUrHrPobpNplzx4XZ10mPQ6/WcHc8N21XPWxaOG5R6L/xwljGfX7z5D1vAeimiwyXIePCM8e1ChuZRxZ1zxfYMQ2zyGFZRJyu0DcL0kaVBU6akyIRg/Q8H7ugni+Ba9FCLfaTlzHeVPrdGRgOiuIbFpUqFhe5As6pFedsL0lcrpCWd8sP5VHOCa2W+ICf2oUAQB97IQsRHLZNXrykjG8eWjeBdsfNmz0V7uazZtjptHeoCMZs7g6h3xppkOBUHaljukrvrsFyeO11XxOxDSPT+Y2bAnIv0AoDanw2aUE1cD2oHA++j0h+VnG6+MtE4X5qc= 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)(4143699003)(11063799006)(261021121427099003)(261009223027099003)(261021123027099003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cGlsVkVBc2lyS2dxbkxDallYUThXQlBCNmF6ZjVuTWtpYVk5UTRwYWl1Y0lS?= =?utf-8?B?cm9ZcmV2MVJoeUNnY3RXSDN2eHpBRXJCRmN2SU95eUdUUDVpRGROTGMvTmxT?= =?utf-8?B?ZnRHVnFuSHB6OW9MMC9ENTkrbStPVUwrZ1F6K0NWdUdZc3A4VWREMzdmNlVJ?= =?utf-8?B?QzlBWjZmbm1VK1hnUUg2ZmxWU1lwZEx3Qk9HVW0ram5weHJDQUtoRjcvRGxn?= =?utf-8?B?bTZpUmxjRHBsMWJ1RVpqNlpEK3JBWmpsbkJvMndkT0hwSWlNUHNIcStJTkZD?= =?utf-8?B?eTVUZllXai9MMEw0WG5WWGlyTzRXS1JwQzFWbVNrUVNmY2M0ME00SEh5QTVz?= =?utf-8?B?ZmR1ckViNlJLOEdSUDZxeFBaSkxmNFZ0TlF1cG9LbE11VmtWVENRcGM4REt0?= =?utf-8?B?Q2Z2c1lxUzQ2aTdFQWZTOE5WUlk5OHRJOEh5Y2VnbFA0QXFEeUp5S1BuV3RB?= =?utf-8?B?b29DRW5HbkNOUWVnMVpVM1U2WkJUcWF4SlhETFJDbXhhM0NQUzhDNXU5aHlV?= =?utf-8?B?TnZSQmg0WGhSWmg2VEZmcGZlWDI1ZUhUV012WW9lYXVFb3ZYYjlCN3ZTb1Ez?= =?utf-8?B?OE9UVW9ZMVJ3Y2ZFN1FvakFpQ0Myb3plbVV1ZTFmV1RmczNPd01tZ1Z0QW1D?= =?utf-8?B?RlYxcVl0dmgyamJCS0ovTW9rTWJ6cnh3WE1YQnBwRTZ0bDBYR2VvOFEyM1VF?= =?utf-8?B?N2tiYnBFbWV0TmZtcmVEMVFtQVRRSjI0OGdrbE9NQ3o0OGVFR3FmTmVBRWxR?= =?utf-8?B?c3o2dlBsV01aN2dCQnpmeVU1Ty9SZlN2MWZHNFdFdkRNcG5pbVh1RThiSjdx?= =?utf-8?B?YnVmRy8rV0U1MWd4bDFQM1c0Y1lJeWwzS2RUVGFvbGJxNlhtKzZnMGlNNzVi?= =?utf-8?B?WUY3Tkt1M2pCWmk3MkRuVGhUSENjbzFkWTdXNW9mYWhFQW9FVWMzM045QWNS?= =?utf-8?B?enNaYyt0bEpXeG1MRHl6TGZ6TFRVYjZodUVjUVF3VDJaeUFibUQzUnQwQUhF?= =?utf-8?B?NGdVaG9zQTF4dnRNOUtpcm1nWXp6TjZ5Nm9IeUhtTytQVGl0bjhaOHlzN0Z2?= =?utf-8?B?TjNncEdrQWY0M25YOEN6ZTloMFhXYzFVYStVa2ozdkVWWlBNQ3FMVFlvQ3Z1?= =?utf-8?B?eWxaajJrdVFWVXRzNlVyVzJ1ZnZjVnh6dWZmc0JBOVJ1SGZxUjRtbXRlSGZa?= =?utf-8?B?ckxpSWpOK2tPZWV5YjI1RVkxOGRtNDZsbXo1WjBQbEhnZU9hTGNoQ0lXQ21J?= =?utf-8?B?Y3JBSTdieng4dzZiRUhXN3JLVyt1TmRhaTZaVjVhc0N3OXNhS2VvcVFHY3ZF?= =?utf-8?B?c2l1WHdTWVRZYlIzS2pRWGtxSVliR1F2RmN6Nk14aHd0OEQwVjk2elBNT2ph?= =?utf-8?B?TDd0OHRxekNYMXZlZUdTZ1dwaGdRengxSWlJQ2wrVHpwYjZTcFBDU3NvYnkv?= =?utf-8?B?OEt3MkNsVGZzc2hoVHJPbURKUFVGRUdNb0ZvRE8yTUpzdlJnSEYzNmVsZTVq?= =?utf-8?B?dDhjbkRQZmZmZEo5QVQxcnY3a1pQZWdDbGFwVDMwZ1pVSzkyRUEzbFhTWEZi?= =?utf-8?B?NTlEcHJ6c1Y2L3hZVmRPSGRHVkFBMjhGV2piT0U2SFREMFJqWWRYV1o2ODh0?= =?utf-8?B?OVpyT3ZhYTh6bXRtNUJzcnpzRnA3OCtBeitOT3BHWDdyUWs3ckVCckZyQlJn?= =?utf-8?B?aE9Ud0o5RVpKU2E3L1RNSnhMVFFLZm9QZGQyd2lGdEVFOGdUbWJqMk5nU2or?= =?utf-8?B?Z1k3ZnBtUWxPcUZzcHpGeWp3Q1JhUXZqVmRiMVZhRDdDQW1jdmFIOXFzajRH?= =?utf-8?B?dldLMEozNWtUUnpCb0p6NTNaUzlybFJoVjJ1ZFFhRmJFR2hXTTBNRERkS1Y2?= =?utf-8?B?anU3b3FMZ1Y1V0FLcnA4Y3drczl1V2phRGRIUVRMcFk4NE84cnU2NTgvKzF2?= =?utf-8?B?OTVHaDVWZTdoblZUSDdodFpHUlp3U3lnMTZ2SHRTV3VhYnMrbllCRHhpZDJT?= =?utf-8?B?TU1zM1hZZXBrejE3UnQ1T2lMMkdhYVV1OHcrM1ZFblNXNHBaSkQvbmszRFFB?= =?utf-8?B?Z3FTNmE0WXZaUlFqVTRUU1k5Q2UxVlo2S0Q0WTZRaGlTQkQzUktpT0hvZi83?= =?utf-8?B?STArem1vSUdkaGk3bEk4STA2dmcxeWhranEzdUZJc3hGbWNuRG5JaVpCaEs3?= =?utf-8?B?QVErVkNQaG1oaUFhUkRnUlNsaVRmSnAwQzJBR3NWajVYWHZadnFKQkMrdWIy?= =?utf-8?B?Ull4d1ZrRmsrSU1vMm13QkhNMUFqSElUaFRLT1lGbEtqY0NEbGNPVS9qallW?= =?utf-8?B?RmpDbStiQjNqMWdtR0JkVG1WTzUxZ0NYRU96VUVWbnU1ZktkSW1zZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14ad8888-a909-4a99-7927-08df305f18fc X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2026 17:08:31.1047 (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: AkK5ERK3Q0KtVJDzJ9EGBXzRWD7Glbiz2o00R926yci6CpO/uFnpGM4h2YkT3elSCji6pUlYznHApyovrIoLOqVuy9C0TGNXjHoQ7fqrOws= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5301 X-purgate-ID: tlsNG-ebf023/1792688916-C06DAB50-307BA9FF/0/0 X-purgate-type: clean X-purgate-size: 3868 On 22/10/2026 2:55 pm, Ross Lagerwall wrote: > On 10/20/26 11:41 PM, Stefano Stabellini wrote: >> In virtual-8086 mode with IOPL < 3, INT n raises #GP(0).  INT1, INT3 >> and INTO are not affected. They are delivered normally. >> >> svm_emul_swint_injection() applies the check to all of them, so an ICEBP >> raises #GP instead of #DB.  It also reports the IDT entry in the #GP >> error code instead of 0. >> >> Limit the check to INT n and use error code 0. >> >> Signed-off-by: Stefano Stabellini >> --- >>   xen/arch/x86/hvm/svm/svm.c | 5 ++++- >>   1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >> index 71e48351f2..df74531d1a 100644 >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -1153,9 +1153,12 @@ static void svm_emul_swint_injection(struct >> x86_event *event) >>        * 32bit OS.  Someone with many TUITs can see about reading the >> TSS >>        * Software Interrupt Redirection bitmap. >>        */ >> -    if ( (regs->eflags & X86_EFLAGS_VM) && >> +    if ( type == X86_ET_SW_INT && (regs->eflags & X86_EFLAGS_VM) && >>            MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) >> +    { >> +        ec = 0; >>           goto raise_exception; >> +    } >>         /* >>        * Read all 8/16 bytes so the idtr limit check is applied >> properly to > > I think this is correct. The check could perhaps move earlier to avoid > needing > to reset ec to 0. > > I do wonder though if there are other cases in the function where ec > needs to > be reset to 0? The pseudocode in the APM seems to have at least one > other case. I confirmed, and indeed it is #GP[0] not #GP[sel].  Also that ICEBP/INT3/INTO are not subject IOPL like this. I agree with Ross that this wants moving earlier; between the CR0.PE check and deciding idte_size.  The comment also wants adjusting, so I think it wants to look like this: diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f22c..c83b28d29727 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1140,6 +1140,17 @@ static void svm_emul_swint_injection(struct x86_event *event)      if ( !(vmcb_get_cr0(vmcb) & X86_CR0_PE) )          goto raise_exception; /* TODO: support real-mode injection? */   +    /* +     * In vm86 mode, INT $N is subject to IOPL. +     * +     * TODO: It is also subject to CR4.VME=1, which would require reading the +     * TSS Software Interrupt Redirection bitmap. +     */ +    if ( type == X86_ET_SW_INT && +         regs->eflags & X86_EFLAGS_VM && +         MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) +        goto raise_exception; +      idte_size   = lm ? 16 : 8;      idte_offset = trap * idte_size;   @@ -1147,16 +1158,6 @@ static void svm_emul_swint_injection(struct x86_event *event)      ec = (trap << 3) | X86_XEC_IDT |           (type == X86_ET_PRIV_SW_EXC ? X86_XEC_EXT : 0);   -    /* -     * TODO: This does not cover the v8086 mode with CR4.VME case -     * correctly, but falls on the safe side from the point of view of a -     * 32bit OS.  Someone with many TUITs can see about reading the TSS -     * Software Interrupt Redirection bitmap. -     */ -    if ( (regs->eflags & X86_EFLAGS_VM) && -         MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) -        goto raise_exception; -      /*       * Read all 8/16 bytes so the idtr limit check is applied properly to       * this entry, even though we don't look at all the words read. I'm happy to adjust this on commit if you're happy? ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 22 18:26:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 18:26:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458523.1670709 (Exim 4.92) (envelope-from ) id 1xJxUO-000732-4Z; Thu, 22 Oct 2026 18:26:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458523.1670709; Thu, 22 Oct 2026 18:26: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 1xJxUO-00072v-1m; Thu, 22 Oct 2026 18:26:08 +0000 Received: by outflank-mailman (input) for mailman id 1458523; Thu, 22 Oct 2026 18:26:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJxUM-00072p-W0 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 18:26:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJxUM-003gqZ-CL for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 20:26:06 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada5521-e002-0a2a0a5209dd-0a2a4506bcbe-20 for ; Thu, 22 Oct 2026 20:26:06 +0200 Received: from [52.101.52.41] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada553c-195a-0a2a45060019-34653429278a-3 for ; Thu, 22 Oct 2026 20:26:05 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB5778.namprd03.prod.outlook.com (2603:10b6:303:6e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.14; Thu, 22 Oct 2026 18:26: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%4]) with mapi id 15.21.0546.016; Thu, 22 Oct 2026 18:26: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=TusHCX6cSTJWYE6VUdFmS3TDqGmnwQtnENfLtDDpnr61K6tBgT/pg9iGGxnSnrPGHysdWtkiwg6ziDKG4V1JsM0D2ctb4vwunW1vVZy7CcFZgapLXJjRzdQX1f/FVtZ2A5k/dJeBU1MRw+d6C9Bnxch1g7c/y9lAvhwnL1F3pZU/h2TWL9wGkPwpL330R+vHt6uvd8KRSPIo8BjJO6LfAOW34mXn0eGEr04nGtcx1Li/sQNZ/gF7wCSNgnMolaPXeD9ujTvAcpbh94V4rYYgnJNKLdX70CkmMu5PjjDyRddcgkBU0nj8pS7VtDXGhabKw+SJroC/w12ewNbgZoLkeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WoWiVcX3/WbsE7kFzD5lGF+CS5uiw3aAqy4e8uoxvGM=; b=vigKiju8bJkdPhMRDMspDFAU04vi8xybs6VoYZ4uNGEDkk0Onovxdivp8cwIfekwoYulz8W13WlEpPR1lcCrXRBk4ettKhOiwk+EfeMCh3okUjt1nRhnCf9D2hYLV7XIhlI1uA+p0yTBpGQvl3RT6LWho85olnCfZ9EjjNAgttDcB5hLkeVuIC4Dv1R7Yyd/8i+xwEiSdyxPknkYxsK3TgYTnDyAr6sgo6j4DeMfQk1cSS1nfQZc6hHFA4YChQZT4z6xgfdS1XQ5lZlTQmoBkCbEYVwEO9vEaSSKfvL1huh3eEo+bz6U5R55uF46RP/LDYDORYGkJ6g3x4uK5Hv1qQ== 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=WoWiVcX3/WbsE7kFzD5lGF+CS5uiw3aAqy4e8uoxvGM=; b=R/+tTo6Ziw9u4QSX3xSeFTmwJewpX3M4lhSZUCN2tk0wBjNk1HOIixvHuTuY/VtK+anvsKneX7cNlryJVGJdk1NnrHU0SaFs4eVqyNbdxIJ1Oi7PD271p01axdZ6lXfltDoriogwbfIr/cpfXph4XytSRDVJspz3ANJtXfEBG/8= 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, 22 Oct 2026 19:25:59 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD Subject: Re: [PATCH 2/2] tools/ocaml: add bindings for the paging mempool size To: Julian Vetter , xen-devel@lists.xenproject.org References: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> <20261022142744.338622-1-julian.vetter@vates.tech> <1792679272.8631fc262581453bbf619ec5b2062170.1a16402de81000f79f@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: <1792679272.8631fc262581453bbf619ec5b2062170.1a16402de81000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0029.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:313::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB5778:EE_ X-MS-Office365-Filtering-Correlation-Id: 0753c98c-1096-436b-a7f5-08df3069edd0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|261009223027099003|261021135927099003|261021121427099003|10067099003|56012099006|261022105027099003|6133799003|261022075727099003|18002099003|22082099003|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: U/LNCHIGQvFRs6cfo7/JYovjwSg7OGVh5fwLdAgnYtyJet4eQsMgXPaAViBQE1KGNDNNj5VKICJ8xBAP0FJTw4gS3Nf5FeHCShQ6UFu+jpmAcw/zj1nPkNIHr/NS1p9qe75Vk9AtYXP3k/hxnJMOXDlf51xNyNpsAm8nHV5vmqImP0y9rLnPf1q2DhA6bsZKaOSayBT0D9MADJ+iNJa6DKMSfCfUrRnH1n6PC3XDcjGihA14Wp/ZmhLfW/M7+GHLln9ch21yrOamrqWRBzOjKQYkfZAG8Opws+CedqT59MDde+mZrH6DlnbwwtdWdP2iavCGPCYJlFzKf3qjGv3pVTmJ6JPD8IOIFlW00lsKTBo+Lk/wNbvh5L/Ut7CCFFJTMq9lFDqB8KuIx97s9xtFncOB0B3QymgHQhFSvOWgN4ei9ieepDBTH7xbynrW1ld//dO2q5IsQihF9svRJxLld4GuEhEE6IpwDiGY4+OMPlCKXmrepXH0JoaVwC6eKQKsHJrjKWbXWskh6+94Cnc2iexbXJDh0dqCP6/pjNdwkCLE3Hh8szW49pz+GC3s6+EbJpJUd45/licbeH6Fq4vUUZfWRKIdYjjHtFuEqRhaSKN/Acjib5Xx7ZeZCk6zib26AWCSS6ogT9VObNI/p/5uAOTnzKGfj/vmGZE+0gOwhH4= 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)(261009223027099003)(261021135927099003)(261021121427099003)(10067099003)(56012099006)(261022105027099003)(6133799003)(261022075727099003)(18002099003)(22082099003)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K05WYXJNQWFWOGdJNnNVZEFweHZNcCtSSERtWW12Y1ZnRzFsOURmTnlpQStm?= =?utf-8?B?SHVuN0hSUHFYeDdsekZ3S0lZdjc2VDFrUytMS3B1SkZmVjZ6T1g5UVVyZFNV?= =?utf-8?B?WGFTSEt6TXF0OGQxWkZ4NEFMWmJHL1grS1BXQkwxTHVlZlJuR0lUTEZyenZM?= =?utf-8?B?dGZGMnRGTmJGTXhwUnN0Tkx3UnN3a0wxNlFuaEY5Y1BTMFFKek5jT01INVZk?= =?utf-8?B?MHRzdDM0WDJOZlZGc01lUDJ3YTNqTUEzVFJ6VFdsS0h3dHczTFgyMDNPRCtt?= =?utf-8?B?NnVKY29xTEovRjFHYXdFWmc2YWxXdWJjUW1JdHFocld1RUJCbDVaTGJmZTFr?= =?utf-8?B?WkxVWWMzZTdEOHBSS29ySkxmRDVzSE1WVGNaZ2tjNXp4WVhIN1IzMEtpdW11?= =?utf-8?B?cXU4WHhjNkt5RU9ab2IwSDNnaGsxSXhVdlBkbjFQMjBDc29ZUW9GWVdFVVA4?= =?utf-8?B?ckE1c2FkRzNzdDhlbWhOZVNQdko2aFRTT2R0RkpKWkRBTnBTOWNhMmhGTnky?= =?utf-8?B?Ukc2QkRTclNXNFdwYS9tSkJWdWpTSllGeEpTamZWV1JEaTMwenpXbmhjcUIw?= =?utf-8?B?Z0RUZ3dYblQxY2RLMVVEYWF0UXY4Wm9JbXgrRXZsTFpNblZFWTZ4R29vZnZC?= =?utf-8?B?b3lMeUU4RnY5L0lkL282MzNKMk53WDhtWHlkQVFmSWtoTlhDWDM1VzVPU3g5?= =?utf-8?B?S3dxUjJreldteGV0ZEZtM1VhNVhHSFhpR3owNnYwcnhhL1BxQ3JYS2dqNVdW?= =?utf-8?B?eG5YRzhIaHZCcjJ5cWxkMEw1ODIrekZhdG9ack03UERzUkhzMVpQYnRQZmI5?= =?utf-8?B?YmMzYVBicWNYbTNWTWRxTzNocEQ2Sm9oMWV1elVkd0J5aUJoWERycjdYRjU4?= =?utf-8?B?dWJvWnQyUHQ4UklzMUVPSE9saG8yVFRtZFZiUEsvMHVSVERGMFRRd21jV0Q1?= =?utf-8?B?dVBaQ0tNRGlIeCsyWHN5blhRT1ZvR2ZLcjVUSCtYQk0zLzU3bVRrend4dnZL?= =?utf-8?B?SlBTZlE1YVQ4NXd1WkQvdERjVDdIWjVNQTM0ckhOYUxlMkhmNWNFSDkwdDFo?= =?utf-8?B?TDNTeVlMWkMzby9HOXY4OVVBUzNQZnR1RXJheWxkanlrZXRlaHlXWENSQ0Fw?= =?utf-8?B?REkzc2VHSXZodGlBN3pGcjlLS1k5WVZNSWdlTTUrODBEWERxK0ZjWUhlZjho?= =?utf-8?B?dGdpdEVYNTV3dkpPV3JOcHpsZmlaRnZUT0NpaHVKVlB4RFdneEdOc0lmS2tU?= =?utf-8?B?dUV6a1VVNXpLa040NmMrRXE2TVNtZzgvbmNteDYwRGRHT0FHbURQU25tTlFG?= =?utf-8?B?VWZqeUxqL21WM0NmcG91a1Z2cjAyN3RpYjArR3Rmc1dlSUY4Z2EzK2xHNExW?= =?utf-8?B?QnUzbXRwNis2Z3ZWZGNWU0h4SEhRVUhtQjhmcUJNei91dmJxYWQ4MXBJb1Nz?= =?utf-8?B?ZVFBcUpvS25jd2FlZ1RZMHZjcC9NRzhNMEVVeTUvanpmVDdDa3MzeElRZURz?= =?utf-8?B?a3A2N29ia24rclp2cnFoWDVKeUFXYTFPTFZ6V1ZNUzNyTExkUFZ3eVVJRTdP?= =?utf-8?B?WmtXWUQwVUJMQVpwTGhnWFJhb1gwZTF0S3JtbVViVHhwcTJnUi9vZDdNVlEx?= =?utf-8?B?NnI0M0JNYlZneFVWNFQ3U0FSbzgrZTN1TElGbkl4UW1LeS8wZzIyaTFwUHVt?= =?utf-8?B?NVplcXl1VUhsaEpSVFMrODErclRTTXZMdUVIYlRyRkJjM2dab1p1T1l1VlYy?= =?utf-8?B?SVBic1dYNHZ6NDN2YjByeCtpQ253M1pXcFk4VUMyZmg4d2N3WWNTL2QyeENW?= =?utf-8?B?clI1SzBueDRuckYxUlJ2UHZObDdzSzdQdFpRNUZ4bStzQ1FFeS8wZFluR1R4?= =?utf-8?B?SUF5bU9YNUdRSndMaXNXZWlsWk05V1h3enZicUFXK25FYTNoNTlROXg5NmV3?= =?utf-8?B?YmZyRnlmdi9ERGRxYStiQlY1NTIyLzJ0Um1GYVdTRUVhOFIwUzJmM2dBdGp6?= =?utf-8?B?UjdYKzBaajcxaWpSUVZRZkYzSjkvWGllRlFjblAvaEZwRHlPTFFNOFEvMElC?= =?utf-8?B?RmkxbWFFU0NvK081eXZ3c0kxcDVZMFBEK2d1U1pLTWh6dU5tcWN5NUVxdGwv?= =?utf-8?B?VHVZT3JpU0hKcmJYbUVXaU9ldUx6cUZPMHRobXM5OUp4MzNIQVVDRUVxOENN?= =?utf-8?B?Skcya2ZFTlplSXFibk1LV2pueTZvdGRDaW1MK3RBV3hwdkwzU1JQeVpYb3Zv?= =?utf-8?B?MjFzUCsxTE9Ua3JiZFJOYzFMRXc0SkpHZ0JianBYaExiVmd1VGs4aEJOem0w?= =?utf-8?B?dFVGTTBmbDFSOVhGOTlSYkQvS25QOFFKK1BjcUwyRlB6UWJ5a3hKQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0753c98c-1096-436b-a7f5-08df3069edd0 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2026 18:26:03.0647 (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: VU0FW/AaQzxfOuML0fSeWDHtxSy7pkmYPMbAT45Bpc67DoIPTa4FzO8DUVhF218ieVjlJmpvurv5NV9BcZrpQJgDCKifwPvDidY4oD1FfkA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5778 X-purgate-ID: tlsNG-16d1c6/1792693566-F5E0E77B-895F2766/0/0 X-purgate-type: clean X-purgate-size: 4658 On 22/10/2026 3:27 pm, Julian Vetter wrote: > The OCaml bindings only expose the shadow_allocation_{get,set} > functions, which use XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION. These > are x86-only, on ARM they fail with -ENOSYS. So, an OCaml toolstack has > no way to size the P2M pool of an ARM domain, which libxl does via > XEN_DOMCTL_set_paging_mempool_size. > > So, add a pair of functions paging_mempool_size_{get,set}, which just > wrap xc_{get,set}_paging_mempool_size(). > > Signed-off-by: Julian Vetter > --- > tools/ocaml/libs/xc/xenctrl.ml | 5 +++++ > tools/ocaml/libs/xc/xenctrl.mli | 4 ++++ > tools/ocaml/libs/xc/xenctrl_stubs.c | 33 +++++++++++++++++++++++++++++ > 3 files changed, 42 insertions(+) > > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml > index 37e41879bb..55cfc2e9a2 100644 > --- a/tools/ocaml/libs/xc/xenctrl.ml > +++ b/tools/ocaml/libs/xc/xenctrl.ml > @@ -283,6 +283,11 @@ external shadow_allocation_set: handle -> domid -> int -> unit > external shadow_allocation_get: handle -> domid -> int > = "stub_shadow_allocation_get" > > +external paging_mempool_size_set: handle -> domid -> int64 -> unit > + = "stub_xc_set_paging_mempool_size" > +external paging_mempool_size_get: handle -> domid -> int64 > + = "stub_xc_get_paging_mempool_size" > + > external evtchn_alloc_unbound: handle -> domid -> domid -> int > = "stub_xc_evtchn_alloc_unbound" > external evtchn_reset: handle -> domid -> unit = "stub_xc_evtchn_reset" > diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli > index 7a0dd7d8ba..0d5cc94198 100644 > --- a/tools/ocaml/libs/xc/xenctrl.mli > +++ b/tools/ocaml/libs/xc/xenctrl.mli > @@ -210,6 +210,10 @@ external shadow_allocation_set : handle -> domid -> int -> unit > = "stub_shadow_allocation_set" > external shadow_allocation_get : handle -> domid -> int > = "stub_shadow_allocation_get" > +external paging_mempool_size_set : handle -> domid -> int64 -> unit > + = "stub_xc_set_paging_mempool_size" > +external paging_mempool_size_get : handle -> domid -> int64 > + = "stub_xc_get_paging_mempool_size" > external evtchn_alloc_unbound : handle -> domid -> domid -> int > = "stub_xc_evtchn_alloc_unbound" > external evtchn_reset : handle -> domid -> unit = "stub_xc_evtchn_reset" > diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c b/tools/ocaml/libs/xc/xenctrl_stubs.c > index e0c435e346..ef3d16beaa 100644 > --- a/tools/ocaml/libs/xc/xenctrl_stubs.c > +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c > @@ -1259,6 +1259,39 @@ CAMLprim value stub_shadow_allocation_set(value xch_val, value domid, > CAMLreturn(Val_unit); > } > > +CAMLprim value stub_xc_get_paging_mempool_size(value xch_val, value domid) > +{ > + CAMLparam2(xch_val, domid); > + xc_interface *xch = xch_of_val(xch_val); > + uint64_t c_size; > + int ret; > + > + caml_enter_blocking_section(); > + ret = xc_get_paging_mempool_size(xch, Int_val(domid), &c_size); > + caml_leave_blocking_section(); > + if (ret != 0) > + failwith_xc(xch); > + > + CAMLreturn(caml_copy_int64(c_size)); > +} > + > +CAMLprim value stub_xc_set_paging_mempool_size(value xch_val, value domid, > + value size) > +{ > + CAMLparam3(xch_val, domid, size); > + xc_interface *xch = xch_of_val(xch_val); > + uint64_t c_size = Int64_val(size); > + int ret; > + > + caml_enter_blocking_section(); > + ret = xc_set_paging_mempool_size(xch, Int_val(domid), c_size); > + caml_leave_blocking_section(); > + if (ret != 0) > + failwith_xc(xch); > + > + CAMLreturn(Val_unit); > +} I personally would consider these bindings fine.  But if we were to accept the code like this, we'd have to make a change in due course. It is not safe to use Int_val() inside a blocking section like this.  Well, it is actually safe, but it also triggers ThreadSanitiser and therefore the Ocaml devs have declared it to be unsafe. During the mark/sweep phases, the Ocaml GC writes back every single value, even the non-pointer ones (despite not changing value).  And instead of fixing this behaviour, it's been declared to be "correct" behaviour, forcing every C binding to be edited to avoid the pattern. So, you need an `uint32_t c_domid = Long_val(domid)` outside of the blocking section.  At some point we need to fix this pattern everywhere else in our bindings. Thinking about it further, we also need a truncation check on domid, because a 64bit Ocaml could pass 0x100000000 which would get truncated to 0 passing through the bindings. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 22 18:58:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 18:58:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458541.1670718 (Exim 4.92) (envelope-from ) id 1xJxzh-0003kr-GU; Thu, 22 Oct 2026 18:58:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458541.1670718; Thu, 22 Oct 2026 18:58: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 1xJxzh-0003kk-Ct; Thu, 22 Oct 2026 18:58:29 +0000 Received: by outflank-mailman (input) for mailman id 1458541; Thu, 22 Oct 2026 18:58:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJxzg-0003ke-H9 for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 18:58:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJxzf-007vPs-8z for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 20:58:27 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada5cc9-e002-0a2a0a5209dd-0a2a450b8570-8 for ; Thu, 22 Oct 2026 20:58:27 +0200 Received: from [202.12.124.144] (helo=fout-b1-smtp.messagingengine.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada5cd1-b7e8-0a2a450b0019-ca0c7c90c4bd-3 for ; Thu, 22 Oct 2026 20:58:26 +0200 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id DD2091D001BE for ; Thu, 22 Oct 2026 14:58:24 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 22 Oct 2026 14:58:24 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Oct 2026 14:58:23 -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=fm2 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=fm2 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=fm2; t=1792695504; x=1792781904; bh=SmpmP6LX2MozVamlzq2gAt0cJuWdWugaPpMNfN4jt7E=; b= lkKga06ZdN3YVHM1hOJaphdmZ5pAn1svkDpCs7dRKMEHGPxQEhthUB91aLxiEjNs gN0o+BdIbRMZ8zcOzmyU14MXtHwRuKXTd0BD30TRJ52oM0+/ZrRzuUWrPNNqifPV aIvwHUAY3drIFiKh+jQBAXkP6pKAPFzFHXr0fWvESFfGJep6QWNm91ZeZHNMXskw Hq9fDNmbvHXdlVdenTVzjAkArGTkmxMdWmlFEH1nxs0aiAZC34SIThyGNG5neDmG P1r15gflRweQ943C/9Wps947ltzZ+I2P21+XQV7MHlJSDl5nbJ8jkZ7Fqsvlqjv/ A9Uk1actmqFTWYRki5O5WQ== 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=fm2; t= 1792695504; x=1792781904; bh=SmpmP6LX2MozVamlzq2gAt0cJuWdWugaPpM NfN4jt7E=; b=qQ3AJEIeTfq934cZSXsRTPYavaVnDvK6KsH4GZO2zmdg88KIB9P nXdwOaDrJv6B46XN8WV7PAr2Pzz8t2B7YtwWa0amdQJrnIdKkm9m+z/VG+aai0GL rHut38ymo+zH5/ulMWoFS6wID2VkB5fNWkimn8J595NpGBj/xG5ckfYiJm/m8Jtx 3GX6FpxGP8Xu2C7SrJel2N0kSK8KURtKbpAipiZICqotMSA/BPUMCkN7DQtOb10r hzX6vrxkOipnvE6kDyDU5XkJ0B1Iql27lgh+90YcjH/HGqNjdyX5DvEFBO5RhqcA +FxK1xegkn7WwwfSPvQZVzhvObgugcGC7uQ== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=sign d=invisiblethingslab.com a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1792695504; d=invisiblethingslab.com; mf=PG1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20+; rt=PHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZz4=; s=fm2:rsa-sha256:D4ICtQR6eG9t536ECQSSj3T7m/L0UTtks7haXWyuX6Bj6G5 HYNx8h3+HJywJzZPrkCzFbH3lzW69LgrHyQcuj4e9+b4BFhg0XtCBtUzKn3PI4Vl mqNIRt5zJlSSg8Dx+z+FbnTBm2YmdBW0M2Oa4zoZue+j+Y2xibWg8Em0G0I7ivAD +6BiD6K+CXnizGUsokwv0+aGi8A9HVkb2PkaD3581M/Ya9MoiLigi4WMt6v/rim+ Ztmptq1kW0NMI1G2G/6wl70YzQ9K2RAQMXB6wpOkGpgd/V7ksZMfgfizvKGGRB9T XEct1aYJk7xn8+tWN9upAlSb3/cRKt1n9aHEqTA==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=mi-m=1; hc=12; hn=cc,content-disposition,content-type,date,feedback-id,from, in-reply-to,message-id,mime-version,references,subject,to; Message-Instance: m=1; h=sha256:MgmAxUXIqr83ScGsGHusOeAfukxu1TjyOF7HMTKZMNg=:CZM9KCNPkYTj9z44sfTuwbf+fq/mLgwt/o3MxzNb5CE=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFNl1hVVzhz2dvusx1RozNBkKxbCtfrxfeFl01tThkhsiM19ClTX5RHVDNlY9i3Wm KePn+Y2RLHoNawnlXHcCnUHY7H8MMbleTSDG4W5EnyTIgpeetXgApHj9OLb9xclBMejaM1 BfGDTDo4TWB+0FtELhazsFGhzBueDNlIoDL8nvrYkPLHDumy6lSixWE3v9C9uXN0QjRwzq fCyp+1A/aqCoQfVAzJYHVw0fe/U6AumxdaEJ76V4Cf4RPQqbVqvw5CLkqBMNU4diBHvlES azZ1ynTq9tww3p8DYdVbF85QicEEWn/MogNwlAlROpg7LURB3i2PYSKJupDcle0zcDicXF 64j7E6jELzUmX+ZO6kVK5YX/JaV5UlHv41tRpcxAN/RnCG8f/vsyII8LJ0nHb2H/TjyNg+ YhgP59P/Me+OcNtQIZOSOYCvlwBaqIdR9C6VVXxu3wMSONGeciyq1vCyYzX047Wt1yOSwU G4arFfm9qf/sCHyuG63/PIz9sFPitCFauSPpIBIgStFxmPiGyFKS50hdnr7XY0PUAjD4BC OgXtoZAOtzcgQWLSaHnKuRMrSrpwK6Z4cDAw0OKJw+kw/87QRTCqrz/HYeusZ53DUNgEUA 0uf+xLxHXgsaMuwNrY6MAkP4VCtBDGeIgw5VO2AZjbEH3hfS80ir9iWFDcqA X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Thu, 22 Oct 2026 20:58:21 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: xen-devel Subject: Re: Cannot boot PVH dom0 with big initrd Message-ID: References: <56cdf5c7-2a2f-4d46-91ed-ba0a361ea649@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FmuGHjoxYaDKyr38" Content-Disposition: inline In-Reply-To: <56cdf5c7-2a2f-4d46-91ed-ba0a361ea649@suse.com> X-purgate-ID: tlsNG-42698a/1792695507-19CC79EA-954BAECD/0/0 X-purgate-type: clean X-purgate-size: 2694 --FmuGHjoxYaDKyr38 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2026 20:58:21 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: Jan Beulich Cc: xen-devel Subject: Re: Cannot boot PVH dom0 with big initrd On Mon, Oct 12, 2026 at 10:32:47AM +0200, Jan Beulich wrote: > On 13.02.2026 05:02, Marek Marczykowski-G=C3=B3recki wrote: > > After fixing the xhci crash, I hit another issue - booting with 236MB > > initrd doesn't work, I get: > >=20 > > (XEN) [ 3.151856] *** Building a PVH Dom0 *** > > ... > > (XEN) [ 3.593940] Unable to allocate memory with order 0! > > (XEN) [ 3.597110] Failed to setup Dom0 physical memory map > > (XEN) [ 3.599884]=20 > > (XEN) [ 3.602482] **************************************** > > (XEN) [ 3.605272] Panic on CPU 0: > > (XEN) [ 3.607928] Could not construct d0 > > (XEN) [ 3.610692] **************************************** > > (XEN) [ 3.613463]=20 > > (XEN) [ 3.616035] Reboot in five seconds... > > (XEN) [ 8.626565] Resetting with ACPI MEMORY or I/O RESET_REG. > >=20 > > Full console log: https://gist.github.com/marmarek/c9dbc87bf07b76f28997= 81755762f565 > >=20 > > If I skip initrd, then it boots just fine (but dom0 is not happy about > > that). 164MB initrd failed too, but 13MB started ok. > > Just in case, I tried skipping XHCI console, but it didn't change > > anything. >=20 > You may want to give [1] a try, minimally up to patch 11 (patches 01 > and 02 are unrelated, so could be omitted as well). I've tested with the full series, and yes, it does fix booting PVH dom0 on this hardware. The console log looks like this now: https://gist.github.com/marmarek/7a418274520d66468908a1f1ff56aede Thanks! --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --FmuGHjoxYaDKyr38 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmraXM0ACgkQ24/THMrX 1yxJtgf/as9DvGwiuTnKne4yJF4iG8WCNb+JAijs/nlwepmfW4LZaPQEjgzn9RfK NibQvfK8p8OzO4IuJiJ+1/86hggeagZW5J9/+OBSGeP48gql52mbwv6LzvpZRaOS 16blYsSzSg/XReg1jIxLjX7ltmXZd+p7FefMdsf9GY22cdNEBQxji+L+KS+qHGSj MB1BJisP0TChPrAUEwrHM9h8w9DIXySPyEXT9u8DT2XyGVdm86GRNQrv3xFthWfz a1Ddz73t1U9NPJ5/m69CX17I8HLQszEWlVIePF0M6ohrGAYObchaprwYIwc244dm HIdQCfc934j8izmAbYr0IRYZPaXAKg== =JhfN -----END PGP SIGNATURE----- --FmuGHjoxYaDKyr38-- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 20:30:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 20:30:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458577.1670726 (Exim 4.92) (envelope-from ) id 1xJzQF-0007L2-PY; Thu, 22 Oct 2026 20:29:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458577.1670726; Thu, 22 Oct 2026 20:29: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 1xJzQF-0007Kv-N3; Thu, 22 Oct 2026 20:29:59 +0000 Received: by outflank-mailman (input) for mailman id 1458577; Thu, 22 Oct 2026 20:29:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJzQE-0007Kp-Nk for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 20:29:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJzQE-00868r-4t for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 22:29:58 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada720f-bab6-0a2a0a5309dd-0a2a450ce994-22 for ; Thu, 22 Oct 2026 22:29:57 +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 6ada7244-f479-0a2a450c0019-aceafc1fa712-3 for ; Thu, 22 Oct 2026 22:29:57 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id AAB66415FA; Thu, 22 Oct 2026 20:29:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DAE31F01825; Thu, 22 Oct 2026 20:29:54 +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=1792700995; bh=v5+K7DRtyEH4BLjRULC+nucWCN08JsEjn4ywlxNdoPM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O/0RBDlTACAEE0ZZdetxJ44VV27g17aAIDGLkw4l6A268+YjlijdyDflHwt4WYK8Z qhF6H0iQzbZrD5RXk8I1tu+HSgvYjtT+OsXkpuqPHIWrO9GSESd13SkO+YVe+IJTGp DcRdMd3FoyINPIHYVwsagCeRxDYyiWxopPEfFHUHV/RNVs5zheJE8iJRBkl1UPWsKC lBQPEanVYvfT4UWp8lsbPg6wDYkXdsrWLp+ND9+0Yaj7i3r9lQn40z0lvpExNxlUyS egv6zb1jTRk/FC9FNxSqYL09S7lFjZmc1JYaNYDtA6Drgm2mnPyYPsWII9yW64LQxG cdLLTopoaA+rA== Date: Thu, 22 Oct 2026 13:29:50 -0700 (PDT) From: Stefano Stabellini To: Andrew Cooper cc: Ross Lagerwall , Stefano Stabellini , xen-devel@lists.xenproject.org, jbeulich@suse.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: [PATCH] xen/x86/svm: Apply the virtual-8086 IOPL check to INT n only In-Reply-To: <192c430b-565b-4b89-957b-01b80ede9049@citrix.com> Message-ID: <2f51c577-86b9-2d20-2032-f9d56b344f47@kernel.org> References: <20261020224123.3710391-1-stefano.stabellini@amd.com> <86d6b7b5-41f2-41b4-8710-7356c78fd15e@citrix.com> <192c430b-565b-4b89-957b-01b80ede9049@citrix.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1519767978-1792700995=:4086347" X-purgate-ID: tlsNG-d25034/1792700997-774D7A5B-E4FCEDFB/0/0 X-purgate-type: clean X-purgate-size: 4439 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1519767978-1792700995=:4086347 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 22 Oct 2026, Andrew Cooper wrote: > On 22/10/2026 2:55 pm, Ross Lagerwall wrote: > > On 10/20/26 11:41 PM, Stefano Stabellini wrote: > >> In virtual-8086 mode with IOPL < 3, INT n raises #GP(0).  INT1, INT3 > >> and INTO are not affected. They are delivered normally. > >> > >> svm_emul_swint_injection() applies the check to all of them, so an ICEBP > >> raises #GP instead of #DB.  It also reports the IDT entry in the #GP > >> error code instead of 0. > >> > >> Limit the check to INT n and use error code 0. > >> > >> Signed-off-by: Stefano Stabellini > >> --- > >>   xen/arch/x86/hvm/svm/svm.c | 5 ++++- > >>   1 file changed, 4 insertions(+), 1 deletion(-) > >> > >> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > >> index 71e48351f2..df74531d1a 100644 > >> --- a/xen/arch/x86/hvm/svm/svm.c > >> +++ b/xen/arch/x86/hvm/svm/svm.c > >> @@ -1153,9 +1153,12 @@ static void svm_emul_swint_injection(struct > >> x86_event *event) > >>        * 32bit OS.  Someone with many TUITs can see about reading the > >> TSS > >>        * Software Interrupt Redirection bitmap. > >>        */ > >> -    if ( (regs->eflags & X86_EFLAGS_VM) && > >> +    if ( type == X86_ET_SW_INT && (regs->eflags & X86_EFLAGS_VM) && > >>            MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) > >> +    { > >> +        ec = 0; > >>           goto raise_exception; > >> +    } > >>         /* > >>        * Read all 8/16 bytes so the idtr limit check is applied > >> properly to > > > > I think this is correct. The check could perhaps move earlier to avoid > > needing > > to reset ec to 0. > > > > I do wonder though if there are other cases in the function where ec > > needs to > > be reset to 0? The pseudocode in the APM seems to have at least one > > other case. > > I confirmed, and indeed it is #GP[0] not #GP[sel].  Also that > ICEBP/INT3/INTO are not subject IOPL like this. > > I agree with Ross that this wants moving earlier; between the CR0.PE > check and deciding idte_size.  The comment also wants adjusting, so I > think it wants to look like this: > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 71e48351f22c..c83b28d29727 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1140,6 +1140,17 @@ static void svm_emul_swint_injection(struct > x86_event *event) >      if ( !(vmcb_get_cr0(vmcb) & X86_CR0_PE) ) >          goto raise_exception; /* TODO: support real-mode injection? */ >   > +    /* > +     * In vm86 mode, INT $N is subject to IOPL. > +     * > +     * TODO: It is also subject to CR4.VME=1, which would require > reading the > +     * TSS Software Interrupt Redirection bitmap. > +     */ > +    if ( type == X86_ET_SW_INT && > +         regs->eflags & X86_EFLAGS_VM && > +         MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) > +        goto raise_exception; > + >      idte_size   = lm ? 16 : 8; >      idte_offset = trap * idte_size; >   > @@ -1147,16 +1158,6 @@ static void svm_emul_swint_injection(struct > x86_event *event) >      ec = (trap << 3) | X86_XEC_IDT | >           (type == X86_ET_PRIV_SW_EXC ? X86_XEC_EXT : 0); >   > -    /* > -     * TODO: This does not cover the v8086 mode with CR4.VME case > -     * correctly, but falls on the safe side from the point of view of a > -     * 32bit OS.  Someone with many TUITs can see about reading the TSS > -     * Software Interrupt Redirection bitmap. > -     */ > -    if ( (regs->eflags & X86_EFLAGS_VM) && > -         MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) > -        goto raise_exception; > - >      /* >       * Read all 8/16 bytes so the idtr limit check is applied properly to >       * this entry, even though we don't look at all the words read. > > > I'm happy to adjust this on commit if you're happy? Yes please, thank you! --8323329-1519767978-1792700995=:4086347-- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 20:57:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 20:57:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458594.1670736 (Exim 4.92) (envelope-from ) id 1xJzqS-0003VQ-Un; Thu, 22 Oct 2026 20:57:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458594.1670736; Thu, 22 Oct 2026 20: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 1xJzqS-0003VJ-Rm; Thu, 22 Oct 2026 20:57:04 +0000 Received: by outflank-mailman (input) for mailman id 1458594; Thu, 22 Oct 2026 20:57:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJzqR-0003VC-2Q for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 20:57:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJzqQ-0088Z5-5a for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 22:57:02 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada787f-e002-0a2a0a5209dd-0a2a4505d682-24 for ; Thu, 22 Oct 2026 22:57:02 +0200 Received: from [52.101.201.27] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada789c-4cb1-0a2a45050019-3465c91b4ee3-3 for ; Thu, 22 Oct 2026 22:57:01 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS0PR03MB8247.namprd03.prod.outlook.com (2603:10b6:8:28f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Thu, 22 Oct 2026 20:56: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%4]) with mapi id 15.21.0546.016; Thu, 22 Oct 2026 20:56: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=sBjNNwx0K9kXKsekeq8s1sPn2Zc44IscJUdu3sGEqNWiZKtZNKg/2sHMq41KYcsLZBqND3NzXbQMf+N9c/c7Er8pSbr/xHQn41MiEw0L7vHlCWQdizExIK3FSTQRA9fpfk7KhSwlEHXqz+QNhqdH4kVAjXbxzW3pKdriSijShav1ugIPiSNSslE+aJve00/Dwquox88KmWabUG1OpeSWqvCbYfKkySBKPE8yLoSKfqPU0Aymtsf0EDRIXLRprpDfNkVzWIo8BTrS+EyqcMItNry16JFkfE2XLsz8uT5t6MQx2pVwAq2b9pTkWcfZVl7Pe8p143ypc0fNl/mmQVnMQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A/9kfvwLGOVAuL1tPWOAwcPE1tuUAOUGOL6Hpgau6mc=; b=d5mvxavnB81hsplg9GHzfp+L3kkz1+zVd45Oq46aJMNPeM7hhGoQjeHhYl5s8LH3Xy8M3x6CSEAPXuf/tizi4f/F9GMgms3G+mUQFnmty8Uwrey+63zbMu6rgbtJFKj76q/GQyb9eZ7BZ9WPKPNeGLui4hr2H1R/YhnvIw81vfcbFMHlstBo4FxBrFKR/1ify9Ikjb8euYaBG4IgYiOlgYDj2rpMbwM3jcSnM1de1iEYFjLJOV8hRS+BHZ5kxKVr4wbBuUXGAB2cQOaRjZH0ATVhBxOZ7urk9zDDLhXb/3exvrezu10SBsjAOmQU4tC/uTc7KZmqRVLTbZMHHwpqrA== 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=A/9kfvwLGOVAuL1tPWOAwcPE1tuUAOUGOL6Hpgau6mc=; b=rmXSMKdwOxjXy4jaUHTsltqlSdAc/IHDtZGeWIPzTVawkqc5IKUb52RaHOPQlIoY2p7zPy6P4xLRagPmTOyZSTsdZtR1GgW+gi/aIsDNjxFVKdgZ7xUVejnksxmKaIwq2sco8s5m24xi0p82iT5p2ruGecK5AFAq9aohgtlXzrw= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: multipart/mixed; boundary="------------CzIthXSbkoKnLKBhJCV0jcHQ" Message-ID: <9019a85e-c121-4d21-95fb-078765e0c3d8@citrix.com> Date: Thu, 22 Oct 2026 21:56:55 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD Subject: Re: [PATCH 0/2] tools/ocaml: bindings needed to build ARM domains To: Julian Vetter , xen-devel@lists.xenproject.org References: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@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: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> X-ClientProxiedBy: PA7P264CA0225.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:374::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_|DS0PR03MB8247:EE_ X-MS-Office365-Filtering-Correlation-Id: 6922f19b-ac09-4f59-8003-08df307f0339 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|6049299003|1800799024|23010399003|376014|366016|6133799003|18002099003|22082099003|261022105027099003|261022075727099003|4053099003|11063799006|261009223027099003|261021121427099003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: x1CkoOiH6S7botRxR1JWAWGT2atD+yFBsf0Gj7S/AUQ0cKCTEiketlqPDkSgPi0RrCkAGmI0jvQFTzCadrgu9adZQHJM0Yu4WbF2Zf7ze6ZiS/XihLqCYu6V5srEc6ILlTFKnsJVoD3U4RHjJB97VTm2pldJrsyaKkSEMLu5Oz9Teq72jc5fSjw130EcNzNcnYnjhttqnZaN8kRFCr5mWNw3GtRo0z6yEcbbBqfCgqLaAo09YTuuXJAzWiH1L/UPPaiW5Vb9eLk+2Wvrt+y5hfF8jIs5l/IkunpdP5jkwLxSl3beoClzxJ+0Xoe7IbIFOAnZUxh6xs1U8vB7sidQQJqukqbeGE2Ps7EpCRfs2ejad6ghYUErxte8f7mE08+O338Oipbz8iC9haSHLb7Xdpm5oSNqgtWEiMvR9quIuiBgVSiOqp7XdflEQmSRExhArMQ8QQmQ5TgowaTmWI4O9ppzJxfWH8glBys9lO5M7nvWNKpSNx0JJ5/28a46wqjHQVVc4OAkCNIOg5AatMRU/XVFRLtJ7q7On967szLSFTCuObKqP1KxLTx4E6jwe3wAUeS9dCiDjqSU+GorP7Ps47XHKnYhEtJbcIjirJtp5sNPj9Jd/1uP/T06KvB/9dNNsP8LJpMnVMdTRS/pD5HMBVgowdRwTT9IGG41H3yKQhs= 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)(6049299003)(1800799024)(23010399003)(376014)(366016)(6133799003)(18002099003)(22082099003)(261022105027099003)(261022075727099003)(4053099003)(11063799006)(261009223027099003)(261021121427099003)(10067099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S2xhcXRFdmhPc29HYTAwNVZTVm8xdjd5WnhhYmE3RFBnbmU5WUxJYzNNQ09P?= =?utf-8?B?ckhINy9YYk0xRCtMZHd5dGd1dW5XbHQxQnczQVpUVU9mSEdpQkI4bHhEOW1C?= =?utf-8?B?OGEyMWR0M1JxZlY3Z2F6aTVGenJTNnNrYVBDekV6ZkpiL1VvRUI3Q3ZUcGE1?= =?utf-8?B?eWZ4cjlsZDkrS3lSczhZSGJtT1hqZkI1WktJWVZrOEtoV2llZUQ0djRQV25C?= =?utf-8?B?U1g1SmQxSHQyUVpxUGtCbVhKYmxQSkp6bnYwcjJobXoxa2FaNnNINnlnUWxx?= =?utf-8?B?RE5pazBvdUdPbDZvb0J2L3RCQ25xZ1JnWTNzNnJEcWlBbGc2V0JzVTZlRzhG?= =?utf-8?B?RnIyeFIzNTRwM212TDcvZThYRmM3YnNKTVZkUlBwbVhBZ3l3Tnk0UTdhcTN1?= =?utf-8?B?MFpsMUdNZWN4RXR3T2tRU2ZuWitab3hQWGQ2NDFDY05mUDk1NHk3TytBT05j?= =?utf-8?B?WS8xMFJ1dDRqSkRxOTFJMHN1ZzFTNHByYmxOb3RPNGtGcW5NbVZZU0I5OVBt?= =?utf-8?B?aUxXL2Fldk5GS3ZPNmxYaUJhbDR1NlltK3lEZG84TDFTekpEZ0NOZWNJTjIr?= =?utf-8?B?ZmJ1UGFTREUyV0JMb1NxRU1Mc1BFbWtUelFWOGRRbEFmU0Z2Vy9WNE1SZFhS?= =?utf-8?B?WHFPeURLZEQ2TE5helcwL3dla3N2a3UwKzE1cWU3Y0lURWZVSGVmMzE2Q3M2?= =?utf-8?B?QWhsOEJMMjVjNlBSb1ZaNWlvRE5tSHhLTDFJUlV5QUN0ZW9HUjkyRnRZeStN?= =?utf-8?B?M09WN1lMVVhFUWU1c3VRV0xub2J5cE5oQUg2SzFxWExJeExhdndWVUxRL2Uz?= =?utf-8?B?bXQ0cWRKNStqYmlEUGwzU3NFNHRPUGxkellaamo1RkMxYy9OMHZabGU4c0Ew?= =?utf-8?B?TkJSZXl1SzJNNkZRN3R5c3FBblFLd1BiQmNZc3o0TEUxM2ZzUTFBRkdpR3dE?= =?utf-8?B?SUhCSVlUZ0JtNzVDTENyTUJtamZHMm1SYUxISHdyY1ZlYmsvN1o3THUwUzlj?= =?utf-8?B?YVBkWlVZUlZmNkFtYWdvMGNtaE52U0JheU92UExSekdGQTJDNm1LL0NHVUl1?= =?utf-8?B?R2s2a3NKZXpVaUxza3VwN2FpaG5jaGJaS0kwUkp3M29qQ0Mzc3Z2YndPNXY5?= =?utf-8?B?WUZVNi9JSjlqTUkydTROdWpqMytEMFZuOHJQMUNaclRNQ0hLWEZ6eTRqQm1a?= =?utf-8?B?REk2WS9mS0hwd0xIL0N0Y2VjWVNPNXZ2a0U2bFYvckdYTWF2R0d2bnB2ZDBY?= =?utf-8?B?aHRuQzZueldRWC9CbG5SVzJEbFErMnJJMWoxaDlOTCtiakt4SDZBYTZzTUFa?= =?utf-8?B?azN1MkJGWXFwK2RGeVNVOVJlaEl5RkJLQll1amZJc2kxMzYvSThSWnlIMUlW?= =?utf-8?B?Z3RKakptcmczQW1SZXZUZVY5Vlh0UExhbU1nNkpKRkpORkZ3RlNJNTF0eEJR?= =?utf-8?B?MmZIUHpjNkFRUHc3M21ncGNON1Z6dG9tdFhuSkFPaDdPZ0F2dGFPR1g3SG9Q?= =?utf-8?B?RFNFeFBnS05aWHB1V1dVVXFHMVRYQXF4VVNMVytwOVh3MDErVnlTOVl5emYz?= =?utf-8?B?UXRTNzFmL0RHYklvU3hyME5NbW5OVE1vcEZKSmg1UGNneHQwdzhvT3Y1dnpX?= =?utf-8?B?bXhOUmN2dzFLZmJUbndTbmhMcGpiYkNrZEFYTmZ0Nm1nYTJVeU0zT2s2QnJV?= =?utf-8?B?L2lTNG9weklCNnpCZDR4OFVjOHNWdXRrcG1WS0VCUWI1RXhMa0V6czJTSGZl?= =?utf-8?B?V1lSTGZNaFlrcENjSVBvcXlqMU5oRXQvcVYxclBqckZya2lDd0pkT1g0MmFV?= =?utf-8?B?THduTGIxSmVEK0N2ZS85ZmNhUjZhUVdMc21GSS96K3o2NStQRFJRZm5icS9i?= =?utf-8?B?WnpGNFhpbDJTZmlEOUVKRHVHMjloUmdCeWJWZEx6SnI3SUgrU2poME8zb2VR?= =?utf-8?B?UmxSUTdWMjhPQ01UUFRMNnhnbG1TeHhoUk9tYjg2L09JU1Q1dnQzMVNGNzF0?= =?utf-8?B?VUNsUVR5bGJqWERxTkdKTVA5dDl1bE5KZkdRck5VQm13NG5kWU9uZWZWa2JY?= =?utf-8?B?eHFQeUg5cGZ5Rjl6cVcxUEQzZkhWblBYL1ZKdjhEVnJuMUo1S0VPakVUNUt3?= =?utf-8?B?ckMzcUcxUXNZWlJqZmJGVjFNTGtVbUZMZ3BXbVFHam9PWDA2SXh4RVA3NjdX?= =?utf-8?B?eit0dFIybHVsVmptbFhzWDEvYlZnc2R3RXRZOUpaUlM5TXdRd2V0azBTQkEx?= =?utf-8?B?UTFOcXF1ZUlXc0lXdVRFVmJ0aUdoSWRwbjQxbHl3a3hDSzZiS0lXVzRXbTBx?= =?utf-8?B?Q0FpYU5zL09XOFJZa3I4U1Ixa213Zk1LVVJKL2ZwZk92VTV0WGgzZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6922f19b-ac09-4f59-8003-08df307f0339 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2026 20:56:58.4866 (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: hSMKsyVMPf31Pao15HpoW0N+27n7677E0SHOEp1GLE4yvqgnbqszfKf8UDuWvjM/KTZ5wzXpZULooefcIqTDisx4gqqyukVMUGbVPiDj3gY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB8247 X-purgate-ID: tlsNG-c201ff/1792702622-243112A1-0502BDF5/0/0 X-purgate-type: clean X-purgate-size: 9465 --------------CzIthXSbkoKnLKBhJCV0jcHQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22/10/2026 3:23 pm, Julian Vetter wrote: > Hello, > this series adds two bindings that are still missing for an OCaml > toolstack, to create and build ARM domains. > > Patch 1 exposes the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 bits of > XEN_SYSCTL_physinfo in arm_physinfo_caps. Since > XEN_DOMCTL_CONFIG_GIC_NATIVE was removed, the toolstack has to pick a > concrete GIC version itself. The OCaml physinfo stub only reports the > SVE vector length on ARM, so OCaml toolstacks currently can't select a > GIC version. > > Patch 2 adds bindings for XEN_DOMCTL_{get,set}_paging_mempool_size. The > existing shadow_allocation_{get,set} bindings use > XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION, which are x86-only and fail > with -ENOSYS on ARM, so there is no way to size the P2M pool of an ARM > domain from OCaml, as libxl does. > > Even though I'm sending these patches as a series, they are somewhat > independent from each other. But together with the patch I sent earlier > today "tools/ocaml: implement stub_xc_domain_create() for ARM", they are > what xenopsd needs to create ARM domains. XEN_DOMCTL_{get,set}_paging_mempool_size were added in a security fix, when it was demonstrated that ARM needed such a memory pool. A remaining task is to remove XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION.  Doing so is another small step along the big API/ABI rewrite, and these calls need purging because they round to the nearest 1M in various places, rather than doing precisely what the toolstack asked. Doing this for the main C code should be relatively easy.  The Ocaml level is more tricky because of how Xapi statically links. I expect the least bad option is to reimplement shadow_allocation_{get,set} in terms of your new paging_mempool_size_{get,set} in xenctrl.ml, allowing us to remove the older C bindings.  We can then move Xapi over to the new API, and retire the compatibility stubs in due course. On a totally separate note, when you reported the arm segfault originally, I put together the attached patch which is a derivation of a smoke test I've had for checking bindings.  The Ocaml part is definitely not pretty, and would benefit from someone who can write the language rather better than I can. But, I think now is about the right time to put this in as a real test to run in CI.  What I did was a gross hack, but in principle all we need to do is install it into $(DESTDIR)$(LIBEXEC)/tests and it should get picked up and run automatically in Gitlab CI. What I can't find is anything which can truly pretty-print an Ocaml object without some external structural definition.  To test the bindings, we need to reference every part of them in Ocaml code (and have it not crash), to confirm that we built the correct structure in C. I can probably start by submitting it with test_xenversion only (to get the plumbing in), and we can build from there? Thoughts? Thanks, ~Andrew --------------CzIthXSbkoKnLKBhJCV0jcHQ Content-Type: text/x-patch; charset=UTF-8; name="0001-CI-Ocaml-Smoke.patch" Content-Disposition: attachment; filename="0001-CI-Ocaml-Smoke.patch" Content-Transfer-Encoding: base64 RnJvbSAzNjgxMmEyZjAwM2I5MTE0Nzg0YWEwODYyY2M1ODZjYjFjNzc3MTE4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu Y29tPgpEYXRlOiBXZWQsIDEyIE9jdCAyMDIyIDE1OjA3OjA5ICswMTAwClN1YmplY3Q6IENJOiBP Y2FtbCBTbW9rZQoKCmRpZmYgLS1naXQgYS9hdXRvbWF0aW9uL3NjcmlwdHMvcWVtdS1hbHBpbmUt eDg2XzY0LnNoIGIvYXV0b21hdGlvbi9zY3JpcHRzL3FlbXUtYWxwaW5lLXg4Nl82NC5zaAppbmRl eCAyNDJmZmNhNjkzZmUuLjBhYzMxNTUzYzgxYyAxMDA3NTUKLS0tIGEvYXV0b21hdGlvbi9zY3Jp cHRzL3FlbXUtYWxwaW5lLXg4Nl82NC5zaAorKysgYi9hdXRvbWF0aW9uL3NjcmlwdHMvcWVtdS1h bHBpbmUteDg2XzY0LnNoCkBAIC01Myw2ICs1Myw4IEBAIGJhc2ggL2V0Yy9pbml0LmQveGVuY29t bW9ucyBzdGFydAogCiB4bCBsaXN0CiAKK29zbW9rZSB8fCBleGl0IDEKKwogeGwgLXZ2diBjcmVh dGUgLWMgL3Jvb3QvZG9tVS5jZmcKIAogIiA+IGV0Yy9sb2NhbC5kL3hlbi5zdGFydApkaWZmIC0t Z2l0IGEvYXV0b21hdGlvbi9zY3JpcHRzL3FlbXUtc21va2UtZG9tMC1hcm0zMi5zaCBiL2F1dG9t YXRpb24vc2NyaXB0cy9xZW11LXNtb2tlLWRvbTAtYXJtMzIuc2gKaW5kZXggNWRjMzQ4YzcxYWE5 Li4wZGE0YzViOTcxODcgMTAwNzU1Ci0tLSBhL2F1dG9tYXRpb24vc2NyaXB0cy9xZW11LXNtb2tl LWRvbTAtYXJtMzIuc2gKKysrIGIvYXV0b21hdGlvbi9zY3JpcHRzL3FlbXUtc21va2UtZG9tMC1h cm0zMi5zaApAQCAtMjEsNiArMjEsOCBAQCBlY2hvICIjIS9iaW4vYmFzaAogCiB4bCBsaXN0CiAK K29zbW9rZSB8fCBleGl0IDEKKwogeGwgLXZ2diBjcmVhdGUgLWMgL3Jvb3QvdGVzdC5jZmcKIAog IiA+IC4vcm9vdC94ZW4uc3RhcnQKZGlmZiAtLWdpdCBhL2F1dG9tYXRpb24vc2NyaXB0cy9xZW11 LXNtb2tlLWRvbTAtYXJtNjQuc2ggYi9hdXRvbWF0aW9uL3NjcmlwdHMvcWVtdS1zbW9rZS1kb20w LWFybTY0LnNoCmluZGV4IDFkNjczZjE4NDI1MS4uYzFmYjY4MTcyNDQzIDEwMDc1NQotLS0gYS9h dXRvbWF0aW9uL3NjcmlwdHMvcWVtdS1zbW9rZS1kb20wLWFybTY0LnNoCisrKyBiL2F1dG9tYXRp b24vc2NyaXB0cy9xZW11LXNtb2tlLWRvbTAtYXJtNjQuc2gKQEAgLTUwLDYgKzUwLDggQEAgYmFz aCAvZXRjL2luaXQuZC94ZW5jb21tb25zIHN0YXJ0CiAKIHhsIGxpc3QKIAorb3Ntb2tlIHx8IGV4 aXQgMQorCiB4bCAtdnZ2IGNyZWF0ZSAtYyAvcm9vdC9kb21VLmNmZwogCiAiID4gZXRjL2xvY2Fs LmQveGVuLnN0YXJ0CmRpZmYgLS1naXQgYS90b29scy9vY2FtbC9NYWtlZmlsZSBiL3Rvb2xzL29j YW1sL01ha2VmaWxlCmluZGV4IDcyNTJlYjIzZDc5OC4uN2I3OWE5OWRmMjZiIDEwMDY0NAotLS0g YS90b29scy9vY2FtbC9NYWtlZmlsZQorKysgYi90b29scy9vY2FtbC9NYWtlZmlsZQpAQCAtMyw2 ICszLDcgQEAgaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTIDo9 IGxpYnMKIFNVQkRJUlMgKz0geGVuc3RvcmVkCitTVUJESVJTICs9IHNtb2tlCiAKIC5OT1RQQVJB TExFTDoKICMgdGFyZ2V0cyBoZXJlIG11c3QgYmUgcnVuIGluIG9yZGVyLCBvdGhlcndpc2Ugd2Ug Y2FuIHRyeQpkaWZmIC0tZ2l0IGEvdG9vbHMvb2NhbWwvc21va2UvTWFrZWZpbGUgYi90b29scy9v Y2FtbC9zbW9rZS9NYWtlZmlsZQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAw MDAuLjBjZTIzYzEzYzNiMAotLS0gL2Rldi9udWxsCisrKyBiL3Rvb2xzL29jYW1sL3Ntb2tlL01h a2VmaWxlCkBAIC0wLDAgKzEsMzQgQEAKK1hFTl9ST09UID0gJChDVVJESVIpLy4uLy4uLy4uCitP Q0FNTF9UT1BMRVZFTCA9ICQoQ1VSRElSKS8uLgoraW5jbHVkZSAkKE9DQU1MX1RPUExFVkVMKS9j b21tb24ubWFrZQorCitPQkpTID0gb3Ntb2tlCisKK09DQU1MSU5DTFVERSArPSBcCisJLUkgJChP Q0FNTF9UT1BMRVZFTCkvbGlicy94YiBcCisJLUkgJChPQ0FNTF9UT1BMRVZFTCkvbGlicy9tbWFw IFwKKwktSSAkKE9DQU1MX1RPUExFVkVMKS9saWJzL3hjIFwKKwktSSAkKE9DQU1MX1RPUExFVkVM KS9saWJzL2V2ZW50Y2huCisKK1NNT0tFTElCUyA9IFwKKwl1bml4LmNteGEgXAorCS1jY29wdCAt TCAtY2NvcHQgJChPQ0FNTF9UT1BMRVZFTCkvbGlicy9tbWFwICQoT0NBTUxfVE9QTEVWRUwpL2xp YnMvbW1hcC94ZW5tbWFwLmNteGEgXAorCS1jY29wdCAtTCAtY2NvcHQgJChPQ0FNTF9UT1BMRVZF TCkvbGlicy9ldmVudGNobiAkKE9DQU1MX1RPUExFVkVMKS9saWJzL2V2ZW50Y2huL3hlbmV2ZW50 Y2huLmNteGEgXAorCS1jY29wdCAtTCAtY2NvcHQgJChPQ0FNTF9UT1BMRVZFTCkvbGlicy94YyAk KE9DQU1MX1RPUExFVkVMKS9saWJzL3hjL3hlbmN0cmwuY214YSBcCisJLWNjb3B0IC1MIC1jY29w dCAkKE9DQU1MX1RPUExFVkVMKS9saWJzL3hiICQoT0NBTUxfVE9QTEVWRUwpL2xpYnMveGIveGVu YnVzLmNteGEgXAorCS1jY29wdCAtTCAtY2NvcHQgJChYRU5fUk9PVCkvdG9vbHMvbGlicy9jdHJs CisKK1BST0dSQU1TID0gb3Ntb2tlCitPQ0FNTF9QUk9HUkFNID0gb3Ntb2tlCisKK29zbW9rZV9M SUJTID0gJChTTU9LRUxJQlMpCitvc21va2VfTUxTT1JURUQgPSAkKHNoZWxsICQoT0NBTUxERVAp IC1zb3J0ICQoT0JKUzo9Lm1sKSkKK29zbW9rZV9PQkpTID0gJChvc21va2VfTUxTT1JURUQ6Lm1s PSkKKworYWxsOiBvc21va2UKKworaW5zdGFsbDogYWxsCisJJChJTlNUQUxMX0RJUikgJChERVNU RElSKSQoc2JpbmRpcikKKwkkKElOU1RBTExfUFJPRykgb3Ntb2tlICQoREVTVERJUikkKHNiaW5k aXIpCisKK2luY2x1ZGUgJChPQ0FNTF9UT1BMRVZFTCkvTWFrZWZpbGUucnVsZXMKZGlmZiAtLWdp dCBhL3Rvb2xzL29jYW1sL3Ntb2tlL29zbW9rZS5tbCBiL3Rvb2xzL29jYW1sL3Ntb2tlL29zbW9r ZS5tbApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAuLjE5MTA1OTNiMGU4 YwotLS0gL2Rldi9udWxsCisrKyBiL3Rvb2xzL29jYW1sL3Ntb2tlL29zbW9rZS5tbApAQCAtMCww ICsxLDU5IEBACitvcGVuIFByaW50ZgorKCogb3BlbiBYZW5jdHJsCisgKiBvcGVuIFhlbm1tYXAg KikKKworbGV0IHhjaCA9IFhlbmN0cmwuaW50ZXJmYWNlX29wZW4gKCkKKworbGV0IHRlc3RfeGVu dmVyc2lvbiAoKSA9CisgIGxldCB2ZXIgPSBYZW5jdHJsLnZlcnNpb24geGNoIGluCisgIHByaW50 ZiAiWGVuIHZlcnNpb246ICVkLiVkJXNcbiIgdmVyLm1ham9yIHZlci5taW5vciB2ZXIuZXh0cmEK KworbGV0IHRlc3RfcGh5c2luZm8gKCkgPQorICBsZXQgcCA9IFhlbmN0cmwucGh5c2luZm8geGNo IGluCisKKyAgcHJpbnRmICJQaHlzaW5mbzpcbiI7CisgIHByaW50ZiAiICB0aHJlYWRzX3Blcl9j b3JlICVkXG4iIHAudGhyZWFkc19wZXJfY29yZTsKKworICBsZXQgc3RyX29mX3g4Nl9waHlzaW5m b19jYXBfZmxhZyBmOnN0cmluZyA9CisgICAgbWF0Y2ggZiB3aXRoCisgICAgKCogfCBDQVBfWDg2 X0FTU0lTVEVEX1hBUElDIC0+ICJ4YXBpYyIKKyAgICAgKiB8IENBUF9YODZfQVNTSVNURURfWDJB UElDIC0+ICJ4MmFwaWMiICopCisgICAgfCBfIC0+IHJhaXNlIE5vdF9mb3VuZAorICBpbgorCisg IG1hdGNoIHAuYXJjaF9jYXBhYmlsaXRpZXMgd2l0aAorICAgIHwgWDg2IHggLT4KKyAgICAgICBi ZWdpbgorICAgICAgICAgcHJpbnRmICIgIGFyY2ggY2FwIGZsYWdzOiI7CisgICAgICAgICBMaXN0 Lml0ZXIgKGZ1biB4IC0+IHByaW50ZiAiICVzIiAoc3RyX29mX3g4Nl9waHlzaW5mb19jYXBfZmxh ZyB4KSkgeDsKKyAgICAgICAgIHByaW50ZiAiXG4iCisgICAgICAgZW5kCisgICAgfCBBUk0geCAt PgorICAgICAgIGJlZ2luCisgICAgICAgICBwcmludGYgIiAgU1ZFIGxlbjogJWRcbiIgeC5zdmVf dmwKKyAgICAgICBlbmQKKworbGV0IHRlc3RfZG9taW5mb2xpc3QgKCkgPQorICBsZXQgZG9tcyA9 IFhlbmN0cmwuZG9tYWluX2dldGluZm9saXN0IHhjaCAwIGluCisKKyAgbGV0IHByZXR0eXByaW50 X2RvbSAoZDpYZW5jdHJsLmRvbWFpbmluZm8pID0KKyAgICBwcmludGYgImQlZDogIiBkLmRvbWlk OworICAgIG1hdGNoIGQuYXJjaF9jb25maWcgd2l0aAorICAgICAgfCBYODYgeCAtPiBwcmludGYg Ing4NlxuIgorICAgICAgfCBBUk0geCAtPiBwcmludGYgIkFSTSBHSUMlZFxuIiB4LmdpY192ZXJz aW9uCisgICAgaW4KKworICBMaXN0Lml0ZXIgcHJldHR5cHJpbnRfZG9tIGRvbXMKKworbGV0ICgp ID0KKyAgcHJpbnRmICJTdGFydC4uLlxuJSEiOworCisgIHRlc3RfeGVudmVyc2lvbiAoKTsKKyAg dGVzdF9waHlzaW5mbyAoKTsKKyAgdGVzdF9kb21pbmZvbGlzdCAoKTsKKworICBwcmludGYgIlN0 YXJ0aW5nIEdDLmNvbXBhY3QoKVxuJSEiOworICBHYy5jb21wYWN0ICgpOworICBwcmludGYgIkRv bmVcbiI7CisKKyAgKCkK --------------CzIthXSbkoKnLKBhJCV0jcHQ-- From xen-devel-bounces@lists.xenproject.org Thu Oct 22 20:57:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Oct 2026 20:57:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458597.1670745 (Exim 4.92) (envelope-from ) id 1xJzqs-0003u1-6E; Thu, 22 Oct 2026 20:57:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458597.1670745; Thu, 22 Oct 2026 20:57: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 1xJzqs-0003tu-3N; Thu, 22 Oct 2026 20:57:30 +0000 Received: by outflank-mailman (input) for mailman id 1458597; Thu, 22 Oct 2026 20:57:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJzqq-0003sT-Ml for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 20:57:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJzqq-003z4P-3i for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 22:57:28 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ada78b6-8faa-0a2a0a5109dd-0a2a4502ba6e-0 for ; Thu, 22 Oct 2026 22:57:26 +0200 Received: from [52.101.125.79] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ada78b3-6ca4-0a2a45020019-34657d4fb3a2-3 for ; Thu, 22 Oct 2026 22:57:25 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYRP286MB5138.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:116::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Thu, 22 Oct 2026 20:57:21 +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.0546.017; Thu, 22 Oct 2026 20: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=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=gOu++UVcjowZpjqteJTHpWalrnjJjeMEudPjmrnMJBcsoZtKqtTTxhZnCI98PO5H8dz2a0E7M7TIhF4RrYsp9/tECmsP60l15Mgw1uzYV+WdYo4Wyr+la+piUJuVZSzHMcPL/xImdYXje5eyT0PyZDCG4WwXa27FKWmIzJIzQYeOv8GENDaoHqKlOLOrt9ZyiKZaVHLPXXsHo/Ml9QVb8tDCSkPEq/c4FjK8r71UR1tv4/Necr4jxWAgr5wCYBW4juXzfKHHGarrfjVtFf+qzKeqCqJfqUT+wqHmCUGgVpE+W1xF9uCxr8U87vpXtOzXDMeVCoTbo0ydMC7tccogJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GcPbvWO3fWCtg+TX/iVPDjxJ6aVeKoWU16tT0g+PwA8=; b=YHgiVxgLvnJG/ot1sJFeayIKOSTAPqMj2lbrq/Iwcoj1li3uc6omRKCJ8OGTguZlQIAaCxW2XI6KK1hssjup/Svj25xrgTyLREVkDoiPzd+gWYb6Wgg1V7jZ5nDar9m62SPowwFgnZ7zGhkBDE6QrGp4BMMwrj7GjNYtN6s53Au4xiQ9Hg7y0fV4a+9RwzH+AtsbO2xXiDfT20/FyRuuAMftkS2ULEM8+6IFCF/04Nsm9qSKiZ4K3x8jnd9UoLWYlVCJLZryDHTkEx9/f/kFkOBAdLL8AdzZAVxzKlDYzf75RuezA+GZtdI0vxohZ7GGrrmztrQYh3dqo23NN5XNrg== 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=GcPbvWO3fWCtg+TX/iVPDjxJ6aVeKoWU16tT0g+PwA8=; b=ck+EIILbOwBNFfAM+jK0gesp79b72cNNtyKMAoFYW5B8FocH3bH4DNl/rdMNy1oMb8yYraTc5KSsfN/4o20IBLFfTn1gjo0FqwaXx/qlfmY4q1cCJc1AGcyYSU/NpR1m/Buhq+zO4nIgZTNB4L9IZsD7V8nxMABBJ0gw2lAxmU4= From: Hirokazu Takahashi To: "Orzel, Michal" , "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" , "Mykyta_Poturai@epam.com" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH v12 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Topic: [PATCH v12 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Index: AQHdX21OrO4+KL2GDkargycw+FU9OrcH2ImAgAIuzCA= Date: Thu, 22 Oct 2026 20:57:21 +0000 Message-ID: References: <20261019015749.48492-1-taka@valinux.co.jp> <20261019015749.48492-2-taka@valinux.co.jp> <22b3b21a-775e-4d82-b9bc-5fea1849294c@amd.com> In-Reply-To: <22b3b21a-775e-4d82-b9bc-5fea1849294c@amd.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP 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=valinux.co.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OS9P286MB7222:EE_|TYRP286MB5138:EE_ x-ms-office365-filtering-correlation-id: ccf00d1e-4987-46dd-3798-08df307f10d2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|7416014|38070700021|4143699003|56012099006|5023799004|10067099003|261021121427099003|261009223027099003|22082099003|6133799003|18002099003|261022105027099003; x-microsoft-antispam-message-info: dyoWCe5Xq/f32Uzlrq82e+5WTLqipUZRXNPFuyC01duWYm3ZPjUEVU7+kUE0YV3RGYmEJLNGwYuuLHbSysu6p2risg8P1aYRBYAeQ9PNF1y6JEuyVsiTkF9NQs5r9olpGk9Bx7OGCE5jqXH92xsqk3j5pv8EkFvDcNojWanep+SpEu31aVWn4D/ZfSUpQvOZpsdBWhPaEfOuSlBzWMfsAbF75k0OCTZ/5kqGsqvATVan/IlKjTvQMXwnTxJP3jhkVBqyLX7RGWNqYcCOXI+8WgEdzzvHnkGAONVnaK0cpagNxyuNtYBSwnig8dWCfixrAE9XK2K5zm2nkzGwWga2YzQfVywrt/liqj3cJa66eP08etGwn01NJAaFljenGs+Bz4St4QYLxTSDRWSkvnlrKaU9onPtOTn7yon8Sgy9CFJG/4CzqvXd33GHvX1ao9Fly4iHnZ87Ih9ZWXgRnYPmsqMzTc2Nus8/3bjJh+coEIhRlD49+SMeXm3GcWiEzgJODeHvtgPaJfhQWagtiiHCLjurxRolQabzoaW4+NyCL66/ci5RZYnA5meojSfhogkFxuEFgckV+Ip4mOoUlQY3reqlqw3W7aAuk1LtPXV7BXWHcWogVt3/VTu1CIwOQak95Xd0k4Qc/uF5MFSmKY7mphaHWsNst4GDR22PUTo84TCQ33tpjBS24ka65z6daKKHqOXKIdpphXr8FIQ/PiWYHw== 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)(376014)(7416014)(38070700021)(4143699003)(56012099006)(5023799004)(10067099003)(261021121427099003)(261009223027099003)(22082099003)(6133799003)(18002099003)(261022105027099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZFA5MEtoS2l5R3FwdnAzZXF1MXdDUXBqRy9XbEtDdlBvRVBrRmNoVHlCdk0y?= =?utf-8?B?Y29QajNMeXAyQ2k2NWtrYWVoYUprRElVaWZTN1hpa3ZXWmYrOUhPVmhRNDl0?= =?utf-8?B?bk9jOEFNc1BCREk5cWdudlJnN3ZpaTQ1dDNtd0R4LysvSm1IY0tGVVdqY2ZM?= =?utf-8?B?NGZXNjJtTmJNalpDWGQrZWtxcE9TLy94OC9NYWlFTkUzVnBRa3ZTbWw0aXJ3?= =?utf-8?B?bWZWS0JZV3FHR2x2b0VBQWN6TmhvYWRpM05USGpxN1FTVU1FdTBXSFVWNmFV?= =?utf-8?B?a3BCTzZZajlNaEJIM09UblZNeWNkV1lYNGlOb2pCZXIvZC9KVk5VSTI2bGsr?= =?utf-8?B?bXZTVXVodG01Mk9kVXJqaWlqR0tWV1NpcjY3WmEvQS9PQUNQd0RTVS9OUW5n?= =?utf-8?B?OTBVTFlxRVNGYmYycnhmelovOUMra1FHODNpR1NRSnhXTnRURm5LdHFsenZR?= =?utf-8?B?TFBlOHJuMVFrbVZjVXpvRzNBM1NETWJSUTZrVzRuQzZzTnlZVngvUmM0QXcv?= =?utf-8?B?eGNqTHFIWXFIZkNiWmE4QVZOSjdwZFhELzdhbVMveW9tdEN3eU5MM3cxSjBp?= =?utf-8?B?eHJXak83cTN6dEpkOGU2QmYwTmduVGYyYTZoNkZrcGR5dHVRTmZoc3owcW42?= =?utf-8?B?V3o5ekNOWEdBNXFhaFBVaXpPclFMZERoUkE0QXFhNzI5YWMzTFdwMzBZV2c2?= =?utf-8?B?VUI1ZzJWVGd6YzRsZ0tIckxzNUp4ZjByN2ZvQy8yUU1LeEttd1g4UHBMS05a?= =?utf-8?B?eXJEQTZhd3hDSFdIL0ZrR3BvbGRES2VpOWE0QlVSYXVWMUdzUXkvMDJSMk1C?= =?utf-8?B?Yyt6bnFHSjJuKzB3MFhIUWFsa2NOdFVNY1JGRk03VzZWdzR5dGZCTGhIMkVj?= =?utf-8?B?ZElRUEY3RWFHVUdjYm51emczaWJmR0ZZcUhaVzAyK1ZiaHF1MVRPeGxUNk9Z?= =?utf-8?B?MTNsZjlIejlEOFh2VWlWU0VoZ2NjeVJZbTFmTGp6NnovZldKaGZMYkU1QWxa?= =?utf-8?B?bUVCQnFBUnBOc3JPZWo1cGpmbThFMks5c0lSK2hLTjZjbk5CTHRYVWIzQXhY?= =?utf-8?B?KzE1MUh2SXFkbTFMbXhBSUxndGIzam1ZSGJSR04yZ1phWjNEcG95aXMrUURy?= =?utf-8?B?YjJidDM5Z0ladldlUXJTNjRCNkRVaHYvbVB6NjVFaVNpeS9vMVVQRldxVUVl?= =?utf-8?B?ekFrUmJDc21hMUVzbjN3WGt2Yks3eTFiaCszcmRyajQ2RWo0NjdpeTRkMUo2?= =?utf-8?B?L01PeWxyOGFnMUpJZk9Kbk1ZUmJCSjBucGgrQWhwVnpRTmY1Ti8wcWcvc1p6?= =?utf-8?B?NHdWc0wxNlVTdzlDVVJSMHdGeHVURC83VTQva2VKM0U0ZmJxL3NFRkgwUkwv?= =?utf-8?B?emJEdlRMU0ZWVXpQekloREdQaStnUnpsQXgySlJxVE9lYmJzNnRZemtjelRB?= =?utf-8?B?MUJZZXBHTlRCbFZZVnhkemxJQzdFNlFkUy9YMjNVVExIZFpGYk1RdmFLLzBD?= =?utf-8?B?UTl2R1NUMFdzc1lFS2xleENUR3k5UVlsdFdKUE9LSFVFOXdLUG9TWXIyMVNa?= =?utf-8?B?YXhKMlYvcmU5U1pNNFVRL0ZtdVRvWU82cithcFFpVUtZd0ExK2doQjBKR0Fj?= =?utf-8?B?NENjek5YdTFmSGZQbzNPQ29vWWRsWmY2cWxYOWhGR29DWGVqQ2VXeU5SazQ5?= =?utf-8?B?UEpiWUphWFMwMHVlSFFRcVRnWUZVVlRrK3VMM2ovQnVnb2pIZ2FlMmIvU2ZT?= =?utf-8?B?c1cvVDU5cEF3cXd0QllIVjVnTXlKbnRyQVEwNnJlb3M4NzNrbnphc2k1Uk9m?= =?utf-8?B?MG5WM3VBMWVOenpGUjJ4L3VWKzNuY2c5ZlI2WkwxVHNWZWlUNHZMWUo5azNo?= =?utf-8?B?MkJBSW5LQ3BHUCtmWUR5UGNnL0xDd2oyTEp4Mm50YXRxOEFRaVFHMklvbnRO?= =?utf-8?B?cVNpQ1NuLzFGWVlqRHYvRmFBOExxRnJ2RDJENFBlSm1FNjBvLzRPQUgrRU40?= =?utf-8?B?a3U5QjBKcXlSRUM0QXBJVXA5QS9vcUI3NVV3NFc3M0xjVTVRWjdVai9xYVNk?= =?utf-8?B?aXQwR1h6SW4vN1dkT0ROK3VoenRGYmp0c3IweHhMVTRVRUJiWXJaVXZLRzB4?= =?utf-8?B?cjhmbUwwbk1MMjlxUmxHRUNEQnpoM1RFa2RxYkxPdlhhZGpHbVZzMmtOd2gz?= =?utf-8?B?ZDNscktIYXZTa0l3ZkRTK1ZueG9obUxOWjdkQUJPaTBTU1F1QlVFTGthV2o4?= =?utf-8?B?Ti9hU1hSeWVJNThCL1gxSHE3VDRnYmFWMGNtWTVLY2EvTTBuUTJPbWMxR0h6?= =?utf-8?Q?h7ANbJhvYppi2C8BHY?= 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: ccf00d1e-4987-46dd-3798-08df307f10d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2026 20:57:21.1071 (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: xH9vZg7YVd4gz2XxXEb2HPXs9rG6dJRYlq6PUrQnVL7uT9eredz5epDHFzRITZ/rqv6SXo+gpyAoABb84gr4iA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYRP286MB5138 X-purgate-ID: tlsNG-720697/1792702646-F1CAA2AC-00194E63/0/0 X-purgate-type: clean X-purgate-size: 4422 SGkgTWljaGFsLA0KDQo+ID4gIHhlbi9jb21tb24vZGV2aWNlLXRyZWUvY3B1LXRvcG9sb2d5LmMg fCAzNzAgKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gPiAgeGVuL2RyaXZlcnMvYWNwaS9N YWtlZmlsZSAgICAgICAgICAgICB8ICAgMSArDQo+ID4gIHhlbi9kcml2ZXJzL2FjcGkvdG9wb2xv Z3kuYyAgICAgICAgICAgfCAgNDMgKysrDQo+IFNob3VsZG4ndCB0aGlzIGZpbGUgYmUgY2FsbGVk IGNwdS10b3BvbG9neSBsaWtlIHRoZSBEVCBlcXVpdmFsZW50Pw0KDQpPa2F5Lg0KDQo+ID4gZGlm ZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9zbXBib290LmMgYi94ZW4vYXJjaC9hcm0vc21wYm9vdC5j DQo+ID4gaW5kZXggOGM5MDcyZjNjMS4uZDM0Mzk2ZjliMSAxMDA2NDQNCj4gPiAtLS0gYS94ZW4v YXJjaC9hcm0vc21wYm9vdC5jDQo+ID4gKysrIGIveGVuL2FyY2gvYXJtL3NtcGJvb3QuYw0KPiA+ IEBAIC05LDEwICs5LDEyIEBADQo+ID4NCj4gPiAgI2luY2x1ZGUgPHhlbi9hY3BpLmg+DQo+ID4g ICNpbmNsdWRlIDx4ZW4vY3B1Lmg+DQo+ID4gKyNpbmNsdWRlIDx4ZW4vY3B1LXRvcG9sb2d5Lmg+ DQo+ID4gICNpbmNsdWRlIDx4ZW4vY3B1bWFzay5oPg0KPiA+ICAjaW5jbHVkZSA8eGVuL2RlbGF5 Lmg+DQo+ID4gICNpbmNsdWRlIDx4ZW4vZGV2aWNlX3RyZWUuaD4NCj4gPiAgI2luY2x1ZGUgPHhl bi9kb21haW5fcGFnZS5oPg0KPiA+ICsjaW5jbHVkZSA8eGVuL2R0LWNwdS10b3BvbG9neS5oPg0K PiBOb3RoaW5nIGluIHRoaXMgZmlsZSBzZWVtcyB0byB1c2UgdGhpcyBoZWFkZXINCg0KVGhpcyBo ZWFkZXIgaXMgcmVxdWlyZWQgYmVjYXVzZSB0aGlzIGZpbGUgdXNlcyBtYXBfY3B1X3RvX2R0X25v ZGUoKS4NClRoaXMgZXh0ZXJuIGRlY2xhcmF0aW9uIGlzIHByb3ZpZGVkIGluIGl0Lg0KDQo+ID4g K3ZvaWQgX19pbml0IGluaXRfY3B1X3RvcG9sb2d5KHZvaWQpDQo+ID4gK3sNCj4gPiArICAgIHVu c2lnbmVkIGludCBjcHU7DQo+ID4gKyAgICBpbnQgcmV0ID0gMDsNCj4gPiArDQo+ID4gKyAgICBp ZiAoIG51bV9wb3NzaWJsZV9jcHVzKCkgPT0gMSApDQo+ID4gKyAgICAgICAgcmV0dXJuOw0KPiA+ ICsNCj4gPiArICAgIGNwdV90b3BvbG9neSA9IHh2emFsbG9jX2FycmF5KHN0cnVjdCBjcHVfdG9w b2xvZ3ksIG5yX2NwdV9pZHMpOw0KPiA+ICsNCj4gPiArICAgIGlmICggY3B1X3RvcG9sb2d5ICkN Cj4gPiArICAgIHsNCj4gPiArICAgICAgICBmb3IgKCBjcHUgPSAwOyBjcHUgPCBucl9jcHVfaWRz OyBjcHUrKyApDQo+ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAgICAgICBpZiAoICF6YWxsb2Nf Y3B1bWFza192YXIoJmNwdV90b3BvbG9neVtjcHVdLnRocmVhZF9zaWJsaW5nKQ0KPiB8fA0KPiA+ ICsgICAgICAgICAgICAgICAgICF6YWxsb2NfY3B1bWFza192YXIoJmNwdV90b3BvbG9neVtjcHVd LmNvcmVfc2libGluZykNCj4gfHwNCj4gPg0KPiArICAgICAgICAgICAgICAgICAhemFsbG9jX2Nw dW1hc2tfdmFyKCZjcHVfdG9wb2xvZ3lbY3B1XS5jbHVzdGVyX3NpYmxpbmcpDQo+ICApDQo+ID4g KyAgICAgICAgICAgICAgICByZXQgPSAtRU5PTUVNOw0KPiBUaGUgbG9vcCBjb250aW51ZXMgYWxs b2NhdGluZyBhZnRlciB0aGUgZmlyc3QgZXJyb3Igd2hpY2ggaXMgaW5jb3JyZWN0Lg0KDQpZb3Ug YXJlIHJpZ2h0LiBJIHdpbGwgZml4IGl0Lg0KDQo+ID4gKyAgICAgICAgfQ0KPiA+ICsgICAgfQ0K PiA+ICsgICAgZWxzZQ0KPiA+ICsgICAgICAgIHJldCA9IC1FTk9NRU07DQo+ID4gKw0KPiA+ICsg ICAgaWYgKCByZXQgIT0gMCApDQo+ID4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJD UFUgdG9wb2xvZ3kgdGFibGUgYWxsb2NhdGlvbiBmYWlsZWRcbiIpOw0KPiBBZnRlciBwcmludGlu ZyB0aGlzIG9uZSB3ZSB3aWxsIGFsc28gcHJpbnQgdGhlICJGYWlsZWQgdG8gaW5pdGlhbGl6ZS4u LiIgb25lLg0KPiBQbGVhc2UgZ290byB0aGUgZXJyb3IuDQoNCk9rYXkuDQoNCj4gPiArICAgIGVs c2UgaWYgKCBhY3BpX2Rpc2FibGVkICkNCj4gPiArICAgICAgICByZXQgPSBkdF9pbml0X2NwdV90 b3BvbG9neSgpOw0KPiA+ICsgICAgZWxzZQ0KPiA+ICsgICAgICAgIHJldCA9IGFjcGlfaW5pdF9j cHVfdG9wb2xvZ3koKTsNCj4gPiArDQo+ID4gKyAgICAvKiBGcmVlIHRoZSBDUFUgdG9wb2xvZ3kg dGFibGUgaWYgaW5pdGlhbGl6YXRpb24gZmFpbHMuICovDQo+ID4gKyAgICBpZiAoIHJldCAhPSAw ICkNCj4gSW4gdjExIEkgYXNrZWQgeW91IHRvIHByaW50IGVycm9yIG9uIHJlYWwgZmFpbHVyZSwg bm90IGFsbCB0aGUgdGltZSBlLmcuIG9uIC0NCj4gRU9QTk9UU1VQUCBvciBFTk9FTlQgYXMgYSBy ZXN1bHQgb2Ygbm90IGZpbmRpbmcgY3B1LW1hcC4NCg0KT2theQ0KIA0KPiA+ICsgICAgew0KPiA+ ICsgICAgICAgIHByaW50aygiRmFpbGVkIHRvIGluaXRpYWxpemUgY3B1IHRvcG9sb2d5IChlcnJv ciAlZClcbiIsIHJldCk7DQo+IFhFTkxPR19FUlIvV0FSTklORz8NCg0KSSB3aWxsIGZpeCBpdC4N Cg0KDQo+ID4gKyAgICAgICAgaWYgKCAhdGhyZWFkICkNCj4gPiArICAgICAgICAgICAgYnJlYWs7 DQo+ID4gKw0KPiA+ICsgICAgICAgIGxlYWYgPSBmYWxzZTsNCj4gPiArICAgICAgICByZXQgPSBn ZXRfY3B1X2Zvcl9ub2RlKHRocmVhZCwgJmNwdSk7DQo+ID4gKyAgICAgICAgaWYgKCByZXQgKQ0K PiA+ICsgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4gPiAr ICAgICAgICAgICAgICAgICAgICIlczogTm8gQ1BVIGZvdW5kIGZvciB0aHJlYWRcbiIsIGR0X25v ZGVfbmFtZSh0aHJlYWQpKTsNCj4gVXNlIGR0X25vZGVfZnVsbF9uYW1lKCkuIE90aGVyd2lzZSB0 aGUgcHJpbnRlZCBuYW1lIGNhbiBiZSBhbWJpZ3VvdXMuDQoNCk9rYXkuDQoNCj4gPiArICAgICAg ICAgICAgcmV0dXJuIHJldDsNCj4gPiArICAgICAgICB9DQo+ID4gKw0KPiA+ICsgICAgICAgIGlm ICggY3B1ID09IElOVkFMSURfVE9QT19JRCApDQo+ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAg ICAgICAvKg0KPiA+ICsgICAgICAgICAgICAgKiBJZ25vcmUgdGhpcyBDUFUgbm9kZSBkZWZpbml0 aW9uIGFzIHRoZSBjb3JyZXNwb25kaW5nIHBoeXNpY2FsDQo+ID4gKyAgICAgICAgICAgICAqIENQ VSBmYWlsZWQgdG8gYm9vdC4NCj4gWW91IHVwZGF0ZWQgdGhlIHByaW50ayBtZXNzYWdlIGJ1dCBu b3QgdGhlIGNvbW1lbnQuIFBsZWFzZSBmaXguDQoNCk9rYXkNCg== From xen-devel-bounces@lists.xenproject.org Fri Oct 23 00:44:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 00:44:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458694.1670754 (Exim 4.92) (envelope-from ) id 1xK3No-00005u-8I; Fri, 23 Oct 2026 00:43:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458694.1670754; Fri, 23 Oct 2026 00: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 1xK3No-00005m-3U; Fri, 23 Oct 2026 00:43:44 +0000 Received: by outflank-mailman (input) for mailman id 1458694; Fri, 23 Oct 2026 00:43:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK3Nn-00005d-6G for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 00:43:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK3Nm-004M93-JH for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 02:43:42 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adaad6f-8faa-0a2a0a5109dd-0a2a45059a5c-20 for ; Fri, 23 Oct 2026 02:43:42 +0200 Received: from [209.85.219.46] (helo=mail-qv1-f46.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adaadbd-4cb1-0a2a45050019-d155db2ed900-3 for ; Fri, 23 Oct 2026 02:43:42 +0200 Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-91b813ac020so5926756d6.3 for ; Thu, 22 Oct 2026 17:43:41 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.246]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91c3971484dsm6287796d6.30.2026.10.22.17.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2026 17:43: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=toxicpanda.com header.i="@toxicpanda.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=toxicpanda.com; s=google; t=1792716221; x=1793321021; 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=CA393/dbh3Z3YHwEnkYHgdANjZe1N8bA84W85qprnlw=; b=IEQx/qjWlHG2j5ERIxwAsOqyTzbe5wZoIOfYJfDpC8qeCQO8ZcuZ/JvU246bknj1i+ CmggoXKrghp5XVgGw2uJF+E0vkeewah0+ENz5M/IU67qZv8m1dDM+dxN/w9BpDOsjMjM +L9dsIEzZ7fTxn+1zN8opRXWMHQucSP1vijmUB1uZKWlwU2etYZzVbDzSclbxv5Gnlzq 2CxxzN6/cdbc9oS0APd3o1TX/hX00LsRWAII7ZmFdjrIV15h/mBFD85BIwZGqKUSJapt k1hwyLx2ALumWhXoeF5hTLu04C9rYIc3XAoXeUjWZLKxa36UpFBrOsiBFfxQQ84YgAAS NLIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792716221; x=1793321021; 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=CA393/dbh3Z3YHwEnkYHgdANjZe1N8bA84W85qprnlw=; b=lqPOm5eo1JkPwgnQRmTXFz2akj5nhbDe3zPsAXJWZIzzj4lSDUR10kT0MWPrVu1ReE /UV+hGvA+S6NFEe2k/nDEXc61LLUBE2DbY4fYoIeZSFBe5YpwLpdEk3stKxe9sEHwTok XZJOD7EiGh+w31yAOJFemYbT8BELVu0yfUsMdMVkBHZu3PMPlKTfvAb430HLE+QqPeyi tAd7k8jLyVpG+4yWYWGyPmL123pIx2KdrEx19aiPeFcgPKyrJJ1dFBRX5K1DE0/Aliwd 8bcVH03vCH7jvXAPdwIt0NdbB5aOZqAgmfVwjeJS6zyfhypOBHYH5TkM+m91/ornSbsj FbwQ== X-Forwarded-Encrypted: i=1; AKwUvBw3c68Npj3/MqlWWHViDEbI57ju1S5Z6slWRD7fxnRQixbZM+8TAg9fjBzoM5B6BoXEImsK6LD5zmQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYIa3bMyd4EYFsUgONHWD1Mdt+kN9ZNyisr1i41di3g1zd68HN9s KlXTsvLiXhHlEO0pwC5k64WT7N8t6XauyX6KGHhZAgYLp4bK1SlgqPxWapsuV7M7wk4= X-Gm-Gg: AYBFou1gl79NOKUIQpgc023sY9u9jd5k8sMacCUAy+Q12VdoHe2rwGMmHammfg+At5p 6aNylJPe8AbzzSumbA0FECsHgoEZKnKZGuopERhaDipFy3U1IEmwc5nMt93hSi7F/DljJ7g032v AepQZSnqryd6tTxTOOFLJ8EExsQlLlN2p1b2DYxXq7Cgy0s6ZhumLy9nj/y6QwwfuWM4d7k5BFJ WeDhC15KRVllimx/i92j9f+CNUgxJEogdoRLdwvJrhVAQ+OnHcOm+SVwlNsgl+0DTZB1mk4YUKf xViY/cwqHzGNOSi5j5ombQhAc49a3V/OKtVXkJRixTfzxG7FHZscm3l9FGhiiUXxCkF6gFhbXzP s2/l+8SWyO2P769QCZpmr/DG4vxHDM2qmj+uySxNo3nRVipaOw6aYDB6i0F2U2bUywrw9OL7goT zO8nq0jr6cfI2EFWPmvNIczMyUeY/LsEFcAIG0bn4QWCLUSPEFvn0IMy336Z/TIvLCI+RZ3TYBP 66mt9gPa7SEgACy2NenwliFiR77KlxeDh+XgNkWuxbayu1tBk4+msXcRmKQPXQRhZLX4Svjdeya j+7oHWL2CkybaVryjA== X-Received: by 2002:a05:6214:d65:b0:91c:1fdc:467d with SMTP id 6a1803df08f44-91c3a9d3548mr7612716d6.29.1792716220553; Thu, 22 Oct 2026 17:43:40 -0700 (PDT) From: Josef Bacik To: Paolo Abeni Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH net-next v2 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags Date: Thu, 22 Oct 2026 20:07:28 +0000 Message-ID: <179269964884897.2.9376562849077840876@toxicpanda.com> In-Reply-To: <717ace2e-18b2-4df5-848d-5757c01ee5de@redhat.com> References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-1-2aa780a03524@toxicpanda.com> <717ace2e-18b2-4df5-848d-5757c01ee5de@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1792716222-245122A1-E37FDDC6/0/0 X-purgate-type: clean X-purgate-size: 2834 On Thu, Oct 22, 2026 at 10:21:26AM +0200, Paolo Abeni wrote: > Recently Eric did some work to remove return arguments from the fast-path, > as with some config it gives measurable overhead. See commit > a02a765bd5c2ae7705144829b2911c96c29db6ba. > > S/W csum should not be the fastest path, but AFAICS the UDP output path > could use it when building the aggregate segments. I checked this on x86_64 defconfig (CONFIG_STACKPROTECTOR_STRONG=y, gcc 13.3), looking at which functions call __stack_chk_fail before and after patches 1-6. The callers on the output path don't change. __ip_append_data() and __ip6_append_data() pass &skb->csum and skb_segment() passes &SKB_GSO_CB(nskb)->csum, so no local has its address taken. The two append functions already have a stack protector today, and skb_segment() doesn't have one before or after. You're right about the helpers themselves though. skb_copy_and_csum_bits() and skb_checksum_full() both gain a stack protector, because of the &csum2 local in the frag_list recursion. Moving that loop into a noinline function gets rid of it, and only an skb with a frag_list pays for it: before v2 frag_list loop split out skb_copy_and_csum_bits no yes no skb_checksum / _full no yes no __ip_append_data yes yes yes __ip6_append_data yes yes yes skb_segment no no no skb_copy_and_csum_bits 774 905 666 bytes I'll do that in v3. These gain one and keep it, since they do pass a local: __skb_checksum_complete(), __skb_checksum_complete_head(), pskb_trim_rcsum_slow(), skb_copy_and_csum_dev(), icmp_glue_bits(), icmpv6_getfrag() and xdr_skb_read_bits(). Each of them goes on to checksum or copy the payload in software. I haven't measured cycles. bloat-o-meter for patches 1-6 with the split is +1177 bytes in total, most of it the new error paths. > I'm wondering using a 64 bit return value and encoding there both the csum > and the error coudl make sense. I'd like to keep the int return and the pointer. It's __must_check, so the compiler catches a caller that ignores the failure, and a packed value needs every caller to know how to unpack it. 0 or ~0 as the error doesn't work either, it changes the checksum on the wire for data that sums to zero: https://lore.kernel.org/all/179199883858343.2.17884063473154560573@toxicpanda.com/ > Also currently net-next is closed for the merge window, and a bunch of > changes in this series looks more like cleanup than fixes. Cleanup will have > to wait for the end of the merge window, fixes can land at any time. There's no rush on any of it, so I'll resend the whole series when net-next reopens. Thanks, Josef From xen-devel-bounces@lists.xenproject.org Fri Oct 23 00:44:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 00:44:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458698.1670763 (Exim 4.92) (envelope-from ) id 1xK3OW-0000V8-F9; Fri, 23 Oct 2026 00:44:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458698.1670763; Fri, 23 Oct 2026 00:44: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 1xK3OW-0000V1-C0; Fri, 23 Oct 2026 00:44:28 +0000 Received: by outflank-mailman (input) for mailman id 1458698; Fri, 23 Oct 2026 00:44:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK3OV-0000Ut-TU for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 00:44:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK3OV-004MI4-AP for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 02:44:27 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adaadd5-8faa-0a2a0a5109dd-0a2a4504d262-24 for ; Fri, 23 Oct 2026 02:44:27 +0200 Received: from [209.85.219.42] (helo=mail-qv1-f42.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adaade9-b57f-0a2a45040019-d155db2abc71-3 for ; Fri, 23 Oct 2026 02:44:26 +0200 Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-917a707f37eso5035466d6.0 for ; Thu, 22 Oct 2026 17:44:26 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.242]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93f70e81a80sm54979785a.1.2026.10.22.17.44.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2026 17:44: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=toxicpanda.com header.i="@toxicpanda.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=toxicpanda.com; s=google; t=1792716265; x=1793321065; 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=jfhyo87AY7L5DeyPwopI2784pYBnvPIRPDiBBG8hjuE=; b=WobsS8arxF3f2eMWACVmf/O2A5CIlrxwYk/OFkFn+eFVBzpFfEhxAA9FzA25kxQ24T WJe49AyjK/DPWhpAEDSw6MtpxwoO4o7qoQb5iwPo/APakJDLSaDxOGZK6PXnozfpBf2H +AaSU1eJxLFMrg2wxER3zpQkvo6pdOtRaDlQwJdW8shLUK7Mzza/5cnYWYou53/q0BuO +sV5cauGHOwhdA5n9+UTj3HgyD+7S7GQeoH5Qxn5fLch/WW2JkA2paENxTms4G/E0jFl zagwoEBSJlrfU2xj7bP1mek0wcZxA20BB5IGm0VOJ5XDEFidixk0A2F/BNlZXmZJ20Re Bt1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792716265; x=1793321065; 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=jfhyo87AY7L5DeyPwopI2784pYBnvPIRPDiBBG8hjuE=; b=ZuhWgaU+sgcpTZ4KHkztAvCY7GDfe83cpTffj4NZD7qgnH1wryFmsZHQwqzreAix6y IU2EirUcthXU3+Ke49KxuSxyUtaS0/rRuKp0gFsg1KXYnyDJOmUu/Ni8lc5PfcrJMWCg wLiRpoTaeKDsPkTYRtKV+CImEWOrBiMCLeYpq0JnzQF1afl6fd6oRxY4berzgbcSCzga Nw8vUZfQRXXotEp5rsphkqcHieylYPCc1lJvSpSzJbrtwhkhvbshgHWKHPfcNeWOPY7k t1x8b4/5uQ6Z17LDCkRqNDvauBFSCNyfg9CDPNTGrBYFt7Nb/8r3Ysf2DScmwn1MRF0W GY8A== X-Forwarded-Encrypted: i=1; AKwUvByAHYPhJPzTH21/fvOEeeiAl81j7i2DJRxJk/8c92/bpH/cX6gaCSKe7CpOaDTvMM+FuwRNgL+MCe0=@lists.xenproject.org X-Gm-Message-State: AFq9FYLtTu620WJYGBX1krjcDKPF9AonOHy0tQMGU8SP+H2d5haudWob 2ybNVgp486z7Z1CG/RRHK69kxB8q3HB3mHC3DODauU54dO1pOj9LMeQZrhvfAK6QXZM= X-Gm-Gg: AYBFou0itgyL1weZFeAki1eh3erlvSMer2JW2pnQIwHv66+CiAJncGpN4JuHqzIIWZF 349BmjQxkc77awPhR8G8i7PHl0QFxLjSEugSSPUTSXxLlWfIqYI9v/EYehQSb/oygnv7aje4tNw ewkWdSfRcbTkhLfQNdGYAO1sULmzLLb3iaHzIgyo7EmJ0ntgv8LO5fUYV8/RxitQF0c/cHYSDHH w4p5LahsE8JXqb2CTNWfeNTLkqczTLJyX/7bCPo4O9YVt6RFXGqetRiNO7NbTKUvT7XFKRUvpt3 zgAP3mXj1KflbXgsxXX8SkI7rJLgq/SpKlAkEMFXOYNMpWhq3W2gNDEPB26mtlnpbkNNQAjwaGG +WJcy5y+EwPoSh2Zh0ZqSYbt+3PbROkfic9uULglzAzmkzIunPX36P+PBF2pdI8roj50R+/0FlX 0afePtELELEkYjTUgtl8jLgCCP2JIAvrgRn7jGKteWtiEDNcEW9vrp30u+gXIftVo1Ce5gAdeeu r2RPTpe3pxxVHye1tkf2VGXLQBHiSLnGuTMo2TSdMZR9OUmI5mdWExQ1PZIsxEMm9wIE/u9meez 1ImQsalCHdx0eQfwRg== X-Received: by 2002:a05:620a:6188:b0:93e:a8c5:132f with SMTP id af79cd13be357-93f6f788f5cmr211153385a.29.1792716265323; Thu, 22 Oct 2026 17:44:25 -0700 (PDT) From: Josef Bacik To: Willem de Bruijn Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Willem de Bruijn Subject: Re: [PATCH net-next v2 11/15] net: skbuff: refuse to segment a nested frag_list Date: Thu, 22 Oct 2026 19:58:29 +0000 Message-ID: <179269910950894.2.12425346173477603662@toxicpanda.com> In-Reply-To: References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-11-2aa780a03524@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1792716267-C06DAB50-F0418DBD/0/0 X-purgate-type: clean X-purgate-size: 2062 On Wed, Oct 21, 2026 at 09:47:15PM -0400, Willem de Bruijn wrote: > This patch became quite a bit more complex because of my request. > More than I anticipated. > > Are you sure this first block is needed? No, it isn't. I took it out and ran three KUnit cases with a nested frag_list under GSO_BY_FRAGS: a linear first member with the nested bytes counted in its len, the same without them counted, and a paged first member. They all still get -EINVAL, from the check in the clone branch or the one in the frag walk. > this test for list_skb != NULL is new. Previously this code already > tested skb_headlen(list_skb) without it. Likely not needed for > anything new in this patch? Same answer, the cases above pass without it too. With every member checked as it's taken, list_skb can only run out if head_skb->len is wrong for some other reason, which isn't what this patch is about. So done this way the patch comes down to the check you suggested in the frag walk, plus skb_has_frag_list(list_skb) added to the existing headlen check in the clone branch. The second one is needed: with only the frag walk check, the frag_list_nested KUnit case still hits a NULL pointer dereference in skb_segment(), because the linear member is cloned, list_skb becomes NULL, and the next pass reads its headlen. The other option is to go back to the single walk up front from v1. It's an extra pass over the frag_list, but it's one check in one place. The difference in behaviour is without SG: there a nested frag_list whose member doesn't match gso_size goes through the copy path, which recurses, and a KUnit case for that gets correctly sized segments today. The in-walk checks leave that alone and the up front walk would refuse it. Nothing in the tree builds a nested frag_list either way. I lean towards the walk up front for v3 because it's simpler to read. Would you be ok with that, or do you prefer the two in-walk checks? net-next is closed, so I'll resend the whole series once it reopens. Thanks, Josef From xen-devel-bounces@lists.xenproject.org Fri Oct 23 01:02:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 01:02:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458710.1670772 (Exim 4.92) (envelope-from ) id 1xK3fv-0002dL-Rd; Fri, 23 Oct 2026 01:02:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458710.1670772; Fri, 23 Oct 2026 01: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 1xK3fv-0002dE-P0; Fri, 23 Oct 2026 01:02:27 +0000 Received: by outflank-mailman (input) for mailman id 1458710; Fri, 23 Oct 2026 01:02:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK3fu-0002d8-Cr for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 01:02:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK3ft-004Ny7-NS for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 03:02:25 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adab217-e002-0a2a0a5209dd-0a2a4505c30c-18 for ; Fri, 23 Oct 2026 03:02:25 +0200 Received: from [52.101.83.104] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adab221-4cb1-0a2a45050019-34655368d3b0-3 for ; Fri, 23 Oct 2026 03:02:25 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AM7PR03MB6611.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 01:02: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%4]) with mapi id 15.21.0546.012; Fri, 23 Oct 2026 01: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" 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=g8YoPAkW5hTCNElKCVXycfM/irzhOtCtAV8rqnjXsNjW8XLc9a+fGoGbEeERlzwTXoY6wzc/Cx8JaS6J1KZyiqt+cffurAgnsiX7CBPsCHZoNjOhsBhHIJh/P+yE+eDa29mz1xE1dx94E4u3n+pYH5aR64k+VMUugdhXpijkPjEoCIxthNSMhebq0tooMUT5vbzqI2b5C8PT5HiRNsxr/shQgjqfjkbheKQgmr9cfQYN4AQmkgk+nKdpZTLeDOJRTdncyflnKnDF6cXsmg7JfZC1to+gWzT9RcQFOqloN6h/DGWEMGzIPJaC7974WO1h8A0m6MLxmp4OYiz/9O90Og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0Cr95uzyJTQ2SIOyr27a+bJf+FmBkG286w2Ct4/NhK4=; b=SS4S7+p0g/bdKUkUop7OueIbsXTHCjVQEOTOshX2Z78c4zxZJ47v6vgKyneP4fo69ey+fQOWedaOc3vinsrXSPCv9cvyCFxXMViy2N460O8hiiPuXa+TuzbUSrVx8HKVPrySnKk3GoNK/LKVmWdxozfU+d34fFQvPTF1qFaVvxmjHO4DfwSZZySHQ9ZnyEz+7Zq86W204iYQONphnbEjH4GHAKYK+6JpHtblc9X78Cgp0ywB1yX5pdhkucc/SqbRja3JIMyMlaRXGmLXELL00zfia15ocljnBgbosArPhyavinEn8pKMY4ysmIJkbXvMWLTqqM4W/zitpCoJCmkqPg== 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=0Cr95uzyJTQ2SIOyr27a+bJf+FmBkG286w2Ct4/NhK4=; b=vQcnFqd6Zg96KHTr8jsLjfVA1+LZSnLqqXHdOGhE+TF8O15oDkGLxdyLwJyKI/2+/gwRF95zj9ilp1Gndug/gE3M7EENVplwAReQ32TjVrm0gEvShEmdVGiSyngWS19rEYvvYlUrj4zCu5ZMoR9sarYzHCc7Icby2COmTbmcYASeYzgjH67A6jLvcivqUj8yvMw5fHkp4EyD2H+ik+4EShNhOdDypoMIRPY+eCThC+lEcvBqWYCay/OqVSnWFUx7IxWU/1mD3YjgpQpDT/EXUzPix/b9BgTQy022G4pplAyUxBhjUOW+IlD7g/Qxqp98t4i1UUhB9geuOgHR2IChHQ== From: Volodymyr Babchuk To: Michal Orzel CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: Re: [PATCH] xen/arm: Don't create useless P2M pool for a hardware domain Thread-Topic: [PATCH] xen/arm: Don't create useless P2M pool for a hardware domain Thread-Index: AQHdYKA5Y9iGAf1wvEqPStYCLfy4lg== Date: Fri, 23 Oct 2026 01:02:22 +0000 Message-ID: <87fqxxut42.fsf@epam.com> References: <20261020143458.194784-1-michal.orzel@amd.com> In-Reply-To: <20261020143458.194784-1-michal.orzel@amd.com> (Michal Orzel's message of "Tue, 20 Oct 2026 16:34:58 +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: 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_|AM7PR03MB6611:EE_ x-ms-office365-filtering-correlation-id: 7d2d7417-668e-40b4-f9c0-08df30a14ba4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|42112799006|261009223027099003|261022105027099003|261021121427099003|261021123027099003|10067099003|56012099006|18002099003|22082099003|11063799006|5023799004|38070700021; x-microsoft-antispam-message-info: rkxEU1wlXCDf72/gKMW6ZIAHNIaikbhFiavUL4n5k61/Ll3KvjpG470EvIXXpDXNrZt/B43TQcRMhmmA7LxDrXEyjZ/FeJ1Y5TqFmdVlyRtWDwxqEeN4X1HYe+lEU3EM3KQMMcqAEeIuiktca7BpLdDPl1Mye+qu4WpFahKfyOc8D5CJ8hn/OCE5kJhiXbFEQQuzi0s9QB2DBXcBTMpjHRa0f6n5Vm3yJyTb4IT6S65QoCapsDIBgWaeysM05wtslVD79SEOEXkTcjz/CK5Co/JKhJNtJBKvJsb9URqBMn1W/sgt5xsNXLXMgwf1sZlc75KHlP0NqbDPc2hU4YP27YLB+xTVrAIQAcFxBBCtNXd0Ky5wpKN6YesAOlcECp5AE/H64qM+iQ8ovXa1xkWiwc/WgG2kcyi8PVj4OHIMnx4CV0+QKvLwHSUIJA4HLjpNKoVct9on/nlYWPAV0RQW9Ymzn6lNgONUvPPqYP53scP7k1XlE0hewPwS/p/gxbzvlmQRaGqRRZ3o098oxExHj2wrhQIMp+daYvP72sINKLfntD0Wz3N7kS5nO8mnPP3Fu4KoB3GSnc9IVKfp9R8IB2Bmo5Cj5QCuivemBmaSw11rzqSib/vAEP3YyLwLSvZ8x6vtk6es9HS+o2aKI060eZE8d2girOUE7AuBQGzyh7Q1yNzNKGBqoBye+wA/yR1290Mlq2WYPK/crak3sANXzi+xGUmS48hdgNAI0OyvliQ= 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)(261009223027099003)(261022105027099003)(261021121427099003)(261021123027099003)(10067099003)(56012099006)(18002099003)(22082099003)(11063799006)(5023799004)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ZLXuSC95I9djXIOmM5aL13UfWGRlBMKquZRLRBn/5KBIejgU3zgpnr+TIM?= =?iso-8859-1?Q?49D+bARA5LBTwru8Xdu03XakjEnqRnfveajP/zfj31MEk3mAfn0MtwOJbG?= =?iso-8859-1?Q?6R/vKOQS3oafHO9MArE+0dHC5IZMt46lZDYUP87tZVVClrryI577nRFGI7?= =?iso-8859-1?Q?CIfQVAHS1zKXcBAkcnIVuX8Ebuz7CF2iKat1LhF1MwoRQgha3y/gSDe+F3?= =?iso-8859-1?Q?dNQi8Jm0gc20nf3YK0/mwPIXAGBRCC+JN6mvqiWmmBV3odwIOnUzWT525n?= =?iso-8859-1?Q?Frzdm6hG7BVqvgbVfms4ZxOZl2nOqv24tvVBBdOeG2s0AmUlCyxCENTHie?= =?iso-8859-1?Q?FrQgW7GVlDId7R5jnXSBn/ZxVb6M0tC/xjC07KdyiqvA7wY2D+fmbpzLrN?= =?iso-8859-1?Q?CPZ8MCURoHObx6txawIhAy4kvKL9NFleoARSf3zNVk4WgjR8HjQx3pJFU7?= =?iso-8859-1?Q?1gwPOmciY+ocfePLW8j02fWxGJZkFkPT0RLw1cK0xBbjMYH84ExhQwmAHn?= =?iso-8859-1?Q?A5LuvuLWZn3h1sLwR+GTkR0c1YuRWU1uc2Rj57XyJOUeSaw56VUD7P72eX?= =?iso-8859-1?Q?iDNr6kMhP58wjQlPEbzuQUdZF70Cfli1mKYo6g4+uPLyT4U12J+1HSvKB8?= =?iso-8859-1?Q?fcrlAhu7fpxFjp8BQepUhB+nvul9CudfgWen0tQfDTQimC10x3BqFXUgbc?= =?iso-8859-1?Q?ovbzve2g5U7EFiw564WEAjKnLae8Pqvgg4n7Ri4ftrMmSqONb/Xvx1LNc+?= =?iso-8859-1?Q?3CSwlJzWL4+dom8E4ie9xZHzAN8qfAdI/4QPBk7iL3t/uAGfQ+xcGOv4Vo?= =?iso-8859-1?Q?UAiTBZ2Na0iRGZPOfKI6QIEYYKPaJ0Xy0Nzoclzzek6aMBLRlgoYeOV29O?= =?iso-8859-1?Q?RCIvEqsiGVarxALxq9MsJ0hJ6Ts98DiL87MhKgM0XSosJBkSdUQtascQhL?= =?iso-8859-1?Q?GmgjmCrsitdSdfgij623UtoyCGlao5ptK5xLpgpHe2GVXElRZ7YbzHkqkY?= =?iso-8859-1?Q?KCQa4hiN6TiCJaLyDuW77q849VnvzCAkK77np8z/3awA3RtrRoxT85L94N?= =?iso-8859-1?Q?PEFwrdKUuKKF73GnTTK1Z3U6IHgHXZAFB4S2xHOZrJCUXtnKvkbAXGVKc1?= =?iso-8859-1?Q?o1PSripny/y+0j7mQEc+dSK8lpsXaHvZ+ntJSxGUB0qRWUZWOFawzU14UK?= =?iso-8859-1?Q?iQP1eeTlrbIbo0PzJ9SvS6CWyALmwf+TOqZO3pr5L29nUYmJtN138wnOMa?= =?iso-8859-1?Q?UW8dhodLyVabgXFTd69YGFCg64XgSvPfuNRXMGlQF0j/rrFu8C4lN4UscN?= =?iso-8859-1?Q?ruhTIZF0AoTBe8Vf++DxvuJkcCViD/fr0/b48i8W7NIvKusSkIMTvpT5Ft?= =?iso-8859-1?Q?94Ejz4Ke7Kw1YtR3FpE3qyI7cg5PlJkZj2chLu8mjp9kE3Pe7qH4gy1InH?= =?iso-8859-1?Q?eH73pKIOiP9VkJ489Kn+5SgvTVl1FPHiDE21eU/5ZabgNxicaVXd1ZH+xk?= =?iso-8859-1?Q?i7KtMrdT1qL4VegBhKaIiUVO2oLKQL/8GEbOXr58mlWPXiU0TBv0Ex+bJ9?= =?iso-8859-1?Q?u9CsMYHc5LxfUg7fnArL91JjEedFHppXR/oqkLdDxxBPOzqLHhQUk8s52m?= =?iso-8859-1?Q?Ov1APfQ3krNt34p/1gn7V5wx84E03LUj4nTGZiFte02aUtkql5Gm2vzxgU?= =?iso-8859-1?Q?8vgAjuWKfpgVuWr8TojCcx8TGYA+bd1KIpW68oFXM6P5p0zhiUOLfZ8ld9?= =?iso-8859-1?Q?8QjfmA3aFs/Ge+AIlCT4hl7ZyuUz1naMfEg0Qt0mqCv0K+7fUpO08/rzIN?= =?iso-8859-1?Q?UeQb1muaPX3/h8gYysHXYBs0pD8rx4E=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: 7d2d7417-668e-40b4-f9c0-08df30a14ba4 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2026 01:02:22.6838 (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: 1yUY3EPzmERnjmOn+yCDjkQ6D2iuxxzpZzj3nMXmPaIrhRPNQx1v2j7CVQucW0qobVUUMsOtThMVEBurXEqq3FOWV333mz4Ru5i3DUPy/5I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6611 X-purgate-ID: tlsNG-c201ff/1792717345-738BE2A1-44A20BA1/0/0 X-purgate-type: clean X-purgate-size: 4850 Hi Michal, Michal Orzel writes: > On Arm, the hardware domain does not use the P2M pool. Its P2M pages are > allocated directly from the heap, without any limit. However, when the > hardware domain is created using dom0less, we still allocate a P2M pool > for it, either of the default size or the one given in > xen,domain-p2m-mem-mb. This memory is never used and is simply wasted. > The same applies when the pool size is set for the hardware domain using > XEN_DOMCTL_set_paging_mempool_size. > > Don't create the pool for a hardware domain. Make the get/set paging > mempool domctls return -EOPNOTSUPP, skip the pool teardown and reject > xen,domain-p2m-mem-mb for a hardware domain in dom0less. > > The dom0less check is Arm specific, because on RISC-V the hardware domain > does use the P2M pool. > > Signed-off-by: Michal Orzel Reviewed-by: Volodymyr Babchuk > --- > docs/misc/arm/device-tree/booting.txt | 4 +++- > xen/arch/arm/mmu/p2m.c | 14 ++++++++++++++ > xen/common/device-tree/dom0less-build.c | 12 ++++++++++++ > 3 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device= -tree/booting.txt > index 3787d2e2b668..c3705ab7d913 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -277,7 +277,9 @@ with the following properties: > used for the domain P2M pool. This is in-sync with the shadow_memory > option in xl.cfg. Leaving this field empty in device tree will lead = to > the default size of domain P2M pool, i.e. 1MB per guest vCPU plus 4K= B > - per MB of guest RAM plus 512KB for guest extended regions. > + per MB of guest RAM plus 512KB for guest extended regions. On Arm, t= he > + hardware domain has no dedicated P2M pool, so specifying this proper= ty > + for it makes the domain fail to build. > =20 > - max_grant_version > =20 > diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c > index 2cf35d8a3709..70d7c9fed955 100644 > --- a/xen/arch/arm/mmu/p2m.c > +++ b/xen/arch/arm/mmu/p2m.c > @@ -61,6 +61,10 @@ static void p2m_free_page(struct domain *d, struct pag= e_info *pg) > /* Return the size of the pool, in bytes. */ > int arch_get_paging_mempool_size(struct domain *d, uint64_t *size) > { > + /* No dedicated pool (no limit) for a hardware domain */ > + if ( is_hardware_domain(d) ) > + return -EOPNOTSUPP; > + > *size =3D (uint64_t)ACCESS_ONCE(d->arch.paging.p2m_total_pages) << P= AGE_SHIFT; > return 0; > } > @@ -69,6 +73,8 @@ int p2m_set_allocation(struct domain *d, unsigned long = pages, bool can_preempt) > { > struct page_info *pg; > =20 > + /* No dedicated pool (no limit) for a hardware domain */ > + ASSERT(!is_hardware_domain(d)); > ASSERT(spin_is_locked(&d->arch.paging.lock)); > =20 > for ( ; ; ) > @@ -119,6 +125,10 @@ int arch_set_paging_mempool_size(struct domain *d, u= int64_t size) > unsigned long pages =3D size >> PAGE_SHIFT; > int rc; > =20 > + /* No dedicated pool (no limit) for a hardware domain */ > + if ( is_hardware_domain(d) ) > + return -EOPNOTSUPP; > + > if ( (size & ~PAGE_MASK) || /* Non page-sized request? */ > pages !=3D (size >> PAGE_SHIFT) ) /* 32-bit overflow? */ > return -EINVAL; > @@ -134,6 +144,10 @@ int p2m_teardown_allocation(struct domain *d) > { > int ret =3D 0; > =20 > + /* No dedicated pool - nothing to tear down */ > + if ( is_hardware_domain(d) ) > + return 0; > + > spin_lock(&d->arch.paging.lock); > if ( d->arch.paging.p2m_total_pages !=3D 0 ) > { > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-= tree/dom0less-build.c > index fcb438c50a04..a877e695ad11 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -757,6 +757,18 @@ static int __init domain_p2m_set_allocation(struct d= omain *d, uint64_t mem, > int rc; > =20 > rc =3D dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_= mb); > + > + /* No dedicated pool (no limit) for a hardware domain on Arm */ > + if ( IS_ENABLED(CONFIG_ARM) && is_hardware_domain(d) ) > + { > + if ( !rc ) > + return 0; > + > + printk(XENLOG_ERR > + "xen,domain-p2m-mem-mb cannot be specified for a hardware= domain\n"); > + return -EINVAL; > + } > + > /* If xen,domain-p2m-mem-mb is not specified, use the default value.= */ > p2m_pages =3D rc ? > p2m_mem_mb << (20 - PAGE_SHIFT) : --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Fri Oct 23 01:05:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 01:05:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458723.1670781 (Exim 4.92) (envelope-from ) id 1xK3jH-0003Cz-DC; Fri, 23 Oct 2026 01:05:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458723.1670781; Fri, 23 Oct 2026 01:05: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 1xK3jH-0003Cs-AQ; Fri, 23 Oct 2026 01:05:55 +0000 Received: by outflank-mailman (input) for mailman id 1458723; Fri, 23 Oct 2026 01:05:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK3jF-0003Cl-Qu for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 01:05:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK3jF-00DSjn-3w for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 03:05:53 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adab2e3-8faa-0a2a0a5109dd-0a2a450a8e4c-40 for ; Fri, 23 Oct 2026 03:05:52 +0200 Received: from [40.107.159.96] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adab2f0-f2d2-0a2a450a0019-286b9f6037bb-3 for ; Fri, 23 Oct 2026 03:05:52 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AM7PR03MB6611.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 01:05: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%4]) with mapi id 15.21.0546.012; Fri, 23 Oct 2026 01:05: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=chdNeMXwAJRLilKC1tackzLIUp7TCmogkKdwPBd0a+dW3BzF9Vq1depPJP4Nv3YFpsnMntG7uG3MJ1HbEbEM7OcAnCqXSGPSLnpbnD1dDTfdQjAYrZqWwAyIENLtgx8FJpOmj5savBoGRDWAuQlKT8/Ui3ibLvTMOhFDUpSb1EVt6zHegbQ0AWRlNEzlpqINrKAAYd8fbNIkLpxXuGYv/o1KKhhpoAeUbaan+PH8UL9RbwHVD9naTI4RZeR5E/mAsLmU1a2RxrTJt6qOkCI1f98gcOPjw7cJnVZ3tcDM37bhetfqRwIa8k13E6zQU2cYdAFlbFkVe4OKYq9LRfRPBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/Rtz+fASszqVVsZR66/MhDDBBqFxZVLmOlGsqIYpI+8=; b=lNhpzcBsZXNdWsd9rD1p/N7NUlU3DKN3fcy4hRsPVldDnlx1qLV0iFAybKuPHt9Y24OZmSBvX8POaGQpwwAcxnuRWSxCBOhLaD7Q5p6TQ1JtqczxeSJKfe/bvABUF7ykKjljNe7x+Uyl2LVzMGuQfZnbKACNgPxm1UaUhw5aYDnuu3b+52T+46FS3QS8qVtYQBtgGGZ7MVwZXkdBxQTttgW48nR3UV9WealZ5ox260MsfLvstYHDudsqDzOQFyDlcSrznf0ydfhWixL3vlo93t5D6aokmfuvCeiuhn1EAKrbgdETNBeFk/ABzNNF6CmotWZn+JRycn7VVcAdmlq4gA== 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=/Rtz+fASszqVVsZR66/MhDDBBqFxZVLmOlGsqIYpI+8=; b=NT6ME5EYw/+BmufWSwcvtdNvgZgo/H8geXOO5tknU307J5GKP5Lwj3fbmuX51+1Rze9k1+MwLX1c+qP7qxz0xTxa/9/DdskRdViO3XVyMTVNJrg9vvShWhYG8F3qWkzzi0zboiqwgsU/Ue52lDQt1Zt9EastkqHohAMS55s0XW/+ird3P69xJgFB1j9qCcC9uuq2TzQBTWLUVUd59PsFwsdDv3hf8HD6oB3ZNsiE50iIJYMrYdwllumCVKAbu0OH4K1SU4RYIr45vTvP36Q/aeVWI3arE6yCt9GwwbNBxI1Gr1njznHRNA0iRlG1vGIuiZu2DMkb61W8MD6T4W1wsw== From: Volodymyr Babchuk To: Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v10 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Topic: [PATCH v10 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Index: AQHdYHbuWxOoSM3qDECYUmtGRYf7WA== Date: Fri, 23 Oct 2026 01:05:50 +0000 Message-ID: <877bj9usy9.fsf@epam.com> References: <3a880578d558388ab6d033ccc1f89aa4efecdc81.1792480416.git.mykyta_poturai@epam.com> In-Reply-To: <3a880578d558388ab6d033ccc1f89aa4efecdc81.1792480416.git.mykyta_poturai@epam.com> (Mykyta Poturai's message of "Tue, 20 Oct 2026 09:39:30 +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_|AM7PR03MB6611:EE_ x-ms-office365-filtering-correlation-id: c98b170d-8044-4454-3b99-08df30a1c7b3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|42112799006|261009223027099003|261022105027099003|261021121427099003|261022075727099003|10067099003|56012099006|18002099003|22082099003|11063799006|4143699003|38070700021; x-microsoft-antispam-message-info: M2Tt/sd0/oxag6PKJR8tjQdENKdZ/i7r/3x8niJ/IZ/41m3mfiZDDikwLtsr4uGCvN/O3rHfpsDWXcOpVE2MQk/3x3lN9dLnCY+OGzCoiqeh+BBmbXg9Z3DW3Ulo7dI7WYUcW8eZ7f/LMZINDuwdypQtCh979PE+i7YG8Glhee8XQb3WIsFPOEaNZWzbnmYGs90RKJ6lL/azwg9PPFVrGYSiZwwns5d/jgXy2/9IvvMC1kfKo8e35MndNsF9PyfMZkmx3mhfCBrZh+exPAvtF+bmXE+nwQh5218Ie4LnHxdWywsO1FY7oUbnjiLCOd7TUECHhoDCkV4O1NF++cxs5BygPmmngH6L7mnkRiIyVkvQPh63jgzK5XZVT+qu7pSAvGWEUd3kVGOnbsWVwIVNVyinKQcwvJ4MyJ9xk/6GCsGEKjk3HGUYop4kmFqkjFVMNAIqBGe7+I7pZKlArEKb0E6rBNRDwb7EDnH35SWL9SCsnAhk1sn+BT/F8DnMEuZGD/VS4PIyvdem1cOVV1H5uXyu7PR8x2mCLYF6Yc8V4eaqsK0u1kns0UDrsr2n1svjUMAxJT4RlUvgbc5QnmCfgr3zeNTmWFuWHvmOrF8cPH5hiD3BxJT4pBaOIT6hQyB1iQ9TJUgCR3JT3CwIE1lgx7EtW7HEdLIzQ0c9C/+qmFmYau6c+KL50L6ufjtIpLXM2ehI5h1cniEZVCMbak1qlsukYBdkCqdK3yk4w/u1qB0= 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)(261009223027099003)(261022105027099003)(261021121427099003)(261022075727099003)(10067099003)(56012099006)(18002099003)(22082099003)(11063799006)(4143699003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?gaJQ/AXo2GBUrJF7dogSJPff6PU/uHv/EA+OmpVMNXDIaZER83IebZxvPb?= =?iso-8859-1?Q?LgizeFupksEpDIhWYYntj2gaxOjg8xjbZ5plC+gUqoG4FxKXVc4pvfki9q?= =?iso-8859-1?Q?3arU3lGn3hknAJNOjAAhBtQ4DbEkukmudOTDAK88W9w70fgxKB3HYE81rp?= =?iso-8859-1?Q?wAjQo1/dOu8D4Y7G+65rRLPBcWJQ222uWkUhOUeIe9Kis0yN3zlgsEtbdc?= =?iso-8859-1?Q?0qwfKYtC6NOTmIs9j0eUtBxZxbPXnshZr8G4lsshHOX7qgHBoef3LmZrB4?= =?iso-8859-1?Q?BaisBFABcpnu2jXru89UVgs9UDA0xR6fzcWU+g9YvhY5yloQSdHugT3oku?= =?iso-8859-1?Q?hHEWCzzmLs0rzMgLIAANOcS/l2KmbbPb6dlmhRzBO1Tc4zrOnsT6Z6P+Pw?= =?iso-8859-1?Q?btindlVWEuiY1m58emMrTQl7oYVN0gt7R+wgToBKqo6RYdZ/QLDepyv9qs?= =?iso-8859-1?Q?3Ylx1P+0tcrq/q9eFK5OtxM33p97Dcn8M3FyoQIlBd+QHIBJsMUV68Xhr6?= =?iso-8859-1?Q?rqJCce0J8W4mWgOsDejdu0Yy/UkWRACejpYZWOtSJ82OwMg9hSIS/qdzaW?= =?iso-8859-1?Q?Grsm1KRzcBXnoEo99U2a0N3HyH4ddoKL76D6HW1RqzDyeR+iRlnIbHfN8q?= =?iso-8859-1?Q?tnWCSkca1pQ2Oj87Q3+KfK8AZC5dVD1eBYNg+51re8u2Iwt+ygphUzTj0K?= =?iso-8859-1?Q?ET4/PJwZ6UgG/3R9vOoa754GZ6Tfi1+gSOWd5TALobNBiPpweici0cgfdB?= =?iso-8859-1?Q?kfr5xEmFj9jHUBRJit3ErFELKO9xKE1O6ADFwQVGV95WRC4G5n2BIkWEO9?= =?iso-8859-1?Q?ahLaRwpIKg0UukxptD4u/M0T8BwK9xpEr4INcZrlrUdGSTY9VX4kCwd9rD?= =?iso-8859-1?Q?2UJjqWhZZr6jdlsVUhNUFNNO9mQ/B9q04FHuYsTxR/+ly3n5j9Pfu1EVgb?= =?iso-8859-1?Q?KckQFJxMJ+Bol55ak68Pk5XsgmCVyb5mzE/HuYhTJGbdhuAzolkmjZXxA8?= =?iso-8859-1?Q?e7UYJ98eY5ONNZl+FgXxGuJwLt6MlxJbjtTKm9P+ntCVfO9GEaivFIvyoW?= =?iso-8859-1?Q?KX+a1+FTsGnGe6kb6TzBndtYf2zp2C+LZhx7EAqXZ7L8zFLkjGbAfZb9d3?= =?iso-8859-1?Q?3D0+sf66oQvljyutu+BpVAe2lKOVhUitv+T3o2lDWQIGrag7nA1k7tAVor?= =?iso-8859-1?Q?UNM2dQ30Kwi6ueQPAMMETwcn4eaBt/OOvOwBRfJa6BIXuIK2PvaymXqMoi?= =?iso-8859-1?Q?wjhDkY+R53uUU+T6M7P9lC58Qsdtv8tdh2Hc1aZUi1lIG4DluAu4niuYv2?= =?iso-8859-1?Q?JDA2QD760eZv7OnbkWRk4BpRjXJI1AGCsNay18/Vc9Q59h8iE6bgk+Kkzp?= =?iso-8859-1?Q?LMmKesTgY+IU6qWvB4o66uFkm/lVAm2DLP45sGi6IPyW5vr/9Zynpx1F2k?= =?iso-8859-1?Q?VGx0NuQ6tb/Q17P0+Y/ZdT7PNIjFoOq9OwzXhAfSbLmY/fNrOgb7E2+kLK?= =?iso-8859-1?Q?ij1n/HtK5yI1csT/bK1xgCE/c7awjBGzry/YUTcaJsNh5tVSpCle/x/GnB?= =?iso-8859-1?Q?4tUFA1l220vx6hO4ScdMY4/OyrNh/z/P+Rybf6/+4p+A5gw1Wd1mhEXcM6?= =?iso-8859-1?Q?/LfaXvgB6RVolprm3TfFrfGiWYj61b4nawajrkDxoyoNL3BYUaTHrX3ckQ?= =?iso-8859-1?Q?4wAbZ2kMehiqUB009DCCzw+mr4jXItCxl6H5VcXgmGk8XQ/TujrvzpLhar?= =?iso-8859-1?Q?9SCU+rUBJDj5yvclIZu+Gu2Q03yMUzz0DxmFq/GWsPZM/ZBNThuMD3gNNN?= =?iso-8859-1?Q?omwnW4rfL00HwNFnKoqQUGY3U+Zf1GE=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: c98b170d-8044-4454-3b99-08df30a1c7b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2026 01:05:50.7418 (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: EbhkLEocECdogF5TpK6v6fRouRkK+0j7qUxpiO1RgN0G8Cl1pgItiKnWrs6936DO0zFlxsTmqa3sQqUc2JmTZBhYjqai4V4mVP90+tQAcds= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6611 X-purgate-ID: tlsNG-4011c0/1792717552-59BC0CFC-80772C39/0/0 X-purgate-type: clean X-purgate-size: 4245 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 Reviewed-by: Volodymyr Babchuk > --- > v9->v10: > * make cpu_next static to balance_irq > * move the offline path to the CPU_DEAD notifier > * make rebalance_irqs static > > 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/irq.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 61 insertions(+) > > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index 594aaedd22..d5145a4723 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -166,6 +166,58 @@ static int init_local_irq_data(unsigned int cpu) > return 0; > } > =20 > +static void balance_irq(int irq, unsigned int from, bool up) > +{ > + static int cpu_next; > + 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); > +} > + > +static 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 > +} > + > static int cpu_callback(struct notifier_block *nfb, unsigned long action= , > void *hcpu) > { > @@ -180,6 +232,15 @@ 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; > + case CPU_DEAD: > + if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) > + rebalance_irqs(cpu, false); > + break; > } > =20 > return notifier_from_errno(rc); --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Fri Oct 23 01:09:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 01:09:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458730.1670789 (Exim 4.92) (envelope-from ) id 1xK3n8-0003tQ-Su; Fri, 23 Oct 2026 01:09:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458730.1670789; Fri, 23 Oct 2026 01: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 1xK3n8-0003tJ-Pr; Fri, 23 Oct 2026 01:09:54 +0000 Received: by outflank-mailman (input) for mailman id 1458730; Fri, 23 Oct 2026 01:09:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK3n6-0003tB-JB for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 01:09:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK3n6-006UnM-06 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 03:09:52 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adab3de-bab6-0a2a0a5309dd-0a2a45068f38-2 for ; Fri, 23 Oct 2026 03:09:51 +0200 Received: from [40.107.130.105] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adab3df-195a-0a2a45060019-286b82697665-3 for ; Fri, 23 Oct 2026 03:09:51 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AM7PR03MB6611.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 01:09:49 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0546.012; Fri, 23 Oct 2026 01: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=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=yfPDdgdatgDFo7ob40dMv6c8K2AGww59ea7QXrz0MjvNj9QKPn5sQgzt7097J/2ws+m/LB3pW44aXFtas9SB16qVUQKaiS5g+xOR4gsjystKPaGLEslyG64Nq7rAXqX5aoH3HswwaLlF2DxH73T0JAV1R8ZwyJcDofkcxZJUiz3LwRc2nloqUK/yIcNklhv5283JmYLcZT7IrahMrsc8bb7Lm8+c+MCZaywuL4EhTbwqntJoji5qDbVRVXt9fQK0AYk+kdgTbmls94Uhd2mNEDFK75VW7iepNSLQvAQ1DcooCb7KEFffw6SAeWcfgRw2fkRG9pnEzl6rwdeQm7MS7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MGj4dnDvYKWplnNAwD1KsBbSXv0yNeTxXKrFUFyfYJ0=; b=TRHm7OfeyEDXozJhhkAWkJvRW6RSV2JWkvjhLPRkOOkQ3K4c0fTfm0c71htM1045PwsZz/xfjOx6xFbCpt8TBvwIDW5kym5IMFTPTtchlc5QG3TOP9rCmROwZ8J/+UgkYNmNTjeLB1s5E2QKbPsosm6XKgBsv4wRm2L1JLnYfb5NU8tsTjP+bY7RG/8pLqxfsn72RxbH+zpSajNuM+iKBc8UcNanhviuKLnzGMltGlHrSi2u5JlUm44t4lqvKFNNnYoH6RzXov7nww3VMxASJFlHvWFg9x0qliVq+8HVxqSAsn3s6g1FYDSYnVrTnjk1W1ttGOrpw1NklL0JdYQpUA== 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=MGj4dnDvYKWplnNAwD1KsBbSXv0yNeTxXKrFUFyfYJ0=; b=coVDb+kKvErAlnkMpmT5/UzGTXvB0d6GBaUjIo/MpYkcqC1BcJUmsopxFlDodULUCSbyqdA1NIL3Ww3Tp23ppkS+Egb4KHDZW5PXiwYR79VOuT17ItJuSiwbcWxNfWAj8Ac7MRfPCUTzv/1UO5HmKInkWuR7Y+p7j79CFNn/IRzyQBRzb14LxiUdvvfKGfHbWaM9k3+jQLDByyVEsWzOsd2HvlOhYF9wMeNTEnUzot68TrSlIP5aAHJ4IAmhe0NxBIZT8lxaprHVkQ1botxtSwSE5Wliipq+xZsggcV585sy1ytLiiP+TbIkO1sn5b1AXO/Ad4MmKl5r6oI9YuoPlA== From: Volodymyr Babchuk To: Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Teddy Astie , "Daniel P. Smith" Subject: Re: [PATCH v10 4/6] arm/sysctl: Implement cpu hotplug ops Thread-Topic: [PATCH v10 4/6] arm/sysctl: Implement cpu hotplug ops Thread-Index: AQHdYHbv9KB0zIuWzEeIKs1XLwNTMw== Date: Fri, 23 Oct 2026 01:09:48 +0000 Message-ID: <87y0bpte78.fsf@epam.com> References: <2fb71ea8cfe221f25b1dbbb50bdc5a74be09194c.1792480416.git.mykyta_poturai@epam.com> In-Reply-To: <2fb71ea8cfe221f25b1dbbb50bdc5a74be09194c.1792480416.git.mykyta_poturai@epam.com> (Mykyta Poturai's message of "Tue, 20 Oct 2026 09:39: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: 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_|AM7PR03MB6611:EE_ x-ms-office365-filtering-correlation-id: 2d08fe34-9c81-4f27-2f7f-08df30a2555d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|366016|42112799006|261009223027099003|261022105027099003|261021121427099003|261022075727099003|261021123027099003|10067099003|56012099006|18002099003|22082099003|11063799006|4143699003|38070700021; x-microsoft-antispam-message-info: emwU69X+ricIwUPgc4fTOOoI7IwvjBmNM5AF5UJ3mo9OfVgPtQ1W4xpyCaQmtYBbO8sw0rj9kLLG5N7yhx+cdgsYrMWeymsrU46kjw7sLzgRdV4gAx1Q9MYUn80DZqbyKiO9+9VZdyJazD/6IsOLXUz2rGZVBfQ5/tj4UkQl9HW94j3oePvmY3iKKqgw7JS7DQ9tH7NQYLnXeWXlhJg4ZMJEFfLsO7MQTOTHT5nEG4MgNLWrtf65kM1ZAxUXyIQB7Pu6/P61OkiO7MiBqeNGundQiVrRX2qY8Mx6/UFeJYrUzLDNq3ppy86I/2YW7H4bzv4PqeAJUqBI/nq8V4tzhX5W43Y/EhZIgaL6i+x1kPrXoGHT147E4xGYWw7vwgxKmUt2iq5Tlke6u/pYWRX66m4y/cDLJ2SsMBkmxL+sZXjjOcJ8TLD5scfcSaMx06OKXYoJOzg9e/3w4cGC/XM6eMFM/OxddGeyMZxRfE7NRMcSq6vgyohAgzKUzUT1+lnp3DyqA4FaVd0mFLXMu6MP6GgLpYOIGZPPDXOKvkwvfQvSLqckmkCKRn18Wv/Y98d5wTxDgJZqfJeMAWXpQE7hnl4JVekoaMyjUc+0WtdMhbuOUGnMJMPB+qki8/wYRmeCeEYBKsY82em677bjrbVBDMqMogBIDG2IdShqvjF5HGFhqHc+xM6RinPeou9AM3dZfiA8Si/1Q4V3GuFVbyEAmXe5rHr1HqrcddvzKiWZdMU= 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)(7416014)(1800799024)(366016)(42112799006)(261009223027099003)(261022105027099003)(261021121427099003)(261022075727099003)(261021123027099003)(10067099003)(56012099006)(18002099003)(22082099003)(11063799006)(4143699003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?PCBhYC1Yqsz6KWyWhWWQg4Vtc6ivhz1zrrXhGojX1415fC2U7W0RovTSOo?= =?iso-8859-1?Q?9BrRk/y0yKDRiNvWGJlAR1pwQqKfekXa6FXvzHTTjcr+S5+FtfH1KUzqP1?= =?iso-8859-1?Q?xxqe04okEKZcCl3DdFQTIQcwn9KTWaKiU9zib7rhkcQurlg2aLRnbfag63?= =?iso-8859-1?Q?bj9GlfvP0p40M7lemN5S0BCCXpUQGXSnGEL1dOymX5FaB7LfUpVLnvovEB?= =?iso-8859-1?Q?gks88ndXzxuYbAt2HMGr3gZjJUoVKFa/ZDWnxEymSVcfcfOJcTWJY2/PTf?= =?iso-8859-1?Q?M4JrANslT1fSTparLdLYj78j37/KKJ7rYBucEjOw0Ad0dH9AfMiEL7augo?= =?iso-8859-1?Q?LVjRfia9sJuBSaW7q6hZ7JbnmPNAhgl1kehFJDhlafOYUwN0AWNEfQVYXE?= =?iso-8859-1?Q?kyvuGF+ZhtQdN9LfpzPPLBnHShoBaByXvpV0WX6CQxVsqa4ibYecdroyxR?= =?iso-8859-1?Q?i3P7ODeKcohucRxSf3zW9mwZ8E7yKs/dz87ETiz93njiIoY0Jg3RJ27iZJ?= =?iso-8859-1?Q?jlERVTATafTSIxHMDRXMRHVEhb9WWrkHwrw059yea4qV5EaH3Nm0P+7+2s?= =?iso-8859-1?Q?GqZAFbUFf3wijQ+A4sx8+KceTCd97hKOubCNh0jIbbCHIL9GLBShiWWDex?= =?iso-8859-1?Q?uiP/D0V5APPPwDjaQAF6GPPLkOPYTds4BLeRFk/ZL3x9UvIGDQWKPyfWq3?= =?iso-8859-1?Q?5RGVLVT/0wd84tlrw8wzxmtGvAPYstE0flkOeQoGcfH+5htHZwK5QFwSlt?= =?iso-8859-1?Q?OXZ7GJEdShtff2cRTC1NxWuqX2mh1GkAme3Wa1WxtTBswRd3vYYwPJfAoI?= =?iso-8859-1?Q?/IB/HjiqjjGvLUBVlHc6x7tx810V2zZGZhG414pbvHspp9kIQoRe9/lJ5X?= =?iso-8859-1?Q?FU2wEkH0mRSTL4GPUAa5XDpFAtOl3109MTVwJfmw/O42fUwLO0MvIydSuj?= =?iso-8859-1?Q?RYI8c4/aOiIpDkQkrMb8il8jdDSbxywt7ODlEGA1C+Lb/POfJ0dl99gtd9?= =?iso-8859-1?Q?hHnBWqDYp5GTA964QLtUGeybSf9LlsZHxmglLpA153mgdtkokDnQStZbMZ?= =?iso-8859-1?Q?bUobk+zwIlaoarZxvF5EQxKXB3y5kSRjlmV9rtOVh+C0hUfg1nlpD4pdo9?= =?iso-8859-1?Q?uSy/jndra2t9DYfcLxnHbbB4xv4MLNe5KkBFfto1gg9jMe9qWr+7Qo6h51?= =?iso-8859-1?Q?hYSZUrORzC9BwqiakvJHF2rLhYpk4LT6kEgeYdBDwVCYb7ayRZYtS/lKJc?= =?iso-8859-1?Q?DfMCoRke4xlNGyrpVHUwL6nWib3qsp5EQvebItdQkkcRsjzS4/ANiZ2O4U?= =?iso-8859-1?Q?OQj1Qcq3yqEiaiycZNhoRM8EkiFL/LidJMuGDf6qhvd6QZ3vgnWn7nwJ8o?= =?iso-8859-1?Q?ZzmSIvAYXgjRhQYX8JTcPDfd6YcoGrhmpc94qMbOpktKqBUPjDZ7y2aCkA?= =?iso-8859-1?Q?cuVYvOrGoFmTYzFAsvK8z1cZohqYDKZPRUpuIngoTmMdJUXEK96BHkK+zu?= =?iso-8859-1?Q?8eE9Ksbu/YQFJMC8BsdnpDOIEjt83S97hm/2s9n1CbdpIiqiBzZkXMVWfw?= =?iso-8859-1?Q?Tnm6fxVaaaeXgf129QiBNQNgY5joBiS1egL2iEJqzq7W+uDTwyQqzacweb?= =?iso-8859-1?Q?fOzDeUek6CbAKyI8kj1WpQclodDIL88lBvHrN0vHFVwWujaq/hddxU5iEb?= =?iso-8859-1?Q?pTkJ++rsJXyD9a/FSotJGACd81wCfLN4Pji3gEdk6j7HvZreZqeTrvZpo+?= =?iso-8859-1?Q?E/d8pdZrO78afBoNOfBaAicPmtKhFWRec4rH+JRqLgGdRvSa1OLP5JAaWI?= =?iso-8859-1?Q?Rwq+cpNJHiR2qscK6pujWzHR1DRkGzQ=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: 2d08fe34-9c81-4f27-2f7f-08df30a2555d X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2026 01:09:48.4337 (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: DkYZbjkYFYboUUI0bnntVhM33udoPIOjmYbz6oHYQ1D7XesdH+0CI6Z11HCkkarMU+XMFvCy6cycJCo1avyh86CeFvvnucKLO7SUdpMAKrk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6611 X-purgate-ID: tlsNG-16d1c6/1792717791-FC20077B-76C905AB/0/0 X-purgate-type: clean X-purgate-size: 7615 Hi, Mykyta Poturai writes: > SMT-disable enforcement check is moved into a separate > architecture-specific function. > > For now this operations only support Arm64. For proper Arm32 support, > there needs to be a mechanism to free per-cpu page tables, allocated in > init_domheap_mappings. Also, hotplug is not supported if ITS enabled, > and partially supported FFA, or TEE is enabled, as they use non-static > IRQ actions. > > Remove ifdef guards for x86 in flask, as cpu hotplug is now > supported on more architectures. > > Signed-off-by: Mykyta Poturai > --- > v9->v10: > * rename arch_cpu_can_stay_online to arch_cpu_keep_online > * drop the single-use hp_op and hcpu variables > * make CPU_ONLINE_OFFLINE depend on !TEE, as FFA and TEE use non-static > IRQ actions > > v8->v9: > * simplify dependencies of config CPU_ONLINE_OFFLINE again > * rebased ove XSA-499 > > v7->v8: > * simplify dependencies of config CPU_ONLINE_OFFLINE > > v6->v7: > * use IS_ENABLED istead of ifdef in more places > * remove unneded variables > * more explicit fallthrough in do_sysctl > > v5->v6: > * fix style issues > * rename arch_smt_cpu_disable -> arch_cpu_can_stay_online and invert the > logic > * use IS_ENABLED istead of ifdef > * remove explicit list af arch-specific SYSCTL_CPU_HOTPLUG_* options > from the common handler > * fix flask issue > > v4->v5: > * move handling to common code > * rename config to CPU_HOTPUG > * merge with "smp: Move cpu_up/down helpers to common code" > > v3->v4: > * don't reimplement cpu_up/down helpers > * add Kconfig option > * fixup formatting > > v2->v3: > * no changes > > v1->v2: > * remove SMT ops > * remove cpu =3D=3D 0 checks > * add XSM hooks > * only implement for 64bit Arm > --- > xen/arch/arm/smp.c | 9 +++++++++ > xen/arch/ppc/stubs.c | 5 +++++ > xen/arch/riscv/stubs.c | 5 +++++ > xen/arch/x86/include/asm/smp.h | 3 --- > xen/arch/x86/smp.c | 34 +++------------------------------ > xen/arch/x86/sysctl.c | 11 ++++------- > xen/common/Kconfig | 4 ++-- > xen/common/smp.c | 35 ++++++++++++++++++++++++++++++++++ > xen/common/sysctl.c | 32 +++++++++++++++++++++++++++++++ > xen/include/xen/smp.h | 4 ++++ > xen/xsm/flask/hooks.c | 2 +- > 11 files changed, 100 insertions(+), 44 deletions(-) > > diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c > index b372472188..039577ad02 100644 > --- a/xen/arch/arm/smp.c > +++ b/xen/arch/arm/smp.c > @@ -44,6 +44,15 @@ void smp_send_call_function_mask(const cpumask_t *mask= ) > } > } > =20 > +/* > + * We currently don't support SMT on ARM so we don't need any special lo= gic for > + * CPU disabling > + */ > +bool arch_cpu_keep_online(unsigned int cpu) > +{ > + return true; > +} > + > /* > * Local variables: > * mode: C > diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c > index 82a289af85..2c2e9412ad 100644 > --- a/xen/arch/ppc/stubs.c > +++ b/xen/arch/ppc/stubs.c > @@ -101,6 +101,11 @@ void smp_send_call_function_mask(const cpumask_t *ma= sk) > BUG_ON("unimplemented"); > } > =20 > +bool arch_cpu_keep_online(unsigned int cpu) > +{ > + BUG_ON("unimplemented"); > +} > + > /* irq.c */ > =20 > void irq_ack_none(struct irq_desc *desc) > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > index 3a7953593d..2307408c6c 100644 > --- a/xen/arch/riscv/stubs.c > +++ b/xen/arch/riscv/stubs.c > @@ -65,6 +65,11 @@ void smp_send_call_function_mask(const cpumask_t *mask= ) > BUG_ON("unimplemented"); > } > =20 > +bool arch_cpu_keep_online(unsigned int cpu) > +{ > + BUG_ON("unimplemented"); > +} > + > /* irq.c */ > =20 > void irq_ack_none(struct irq_desc *desc) > diff --git a/xen/arch/x86/include/asm/smp.h b/xen/arch/x86/include/asm/sm= p.h > index 572b39b01c..6c33567cb5 100644 > --- a/xen/arch/x86/include/asm/smp.h > +++ b/xen/arch/x86/include/asm/smp.h > @@ -44,9 +44,6 @@ int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_= t pxm); > =20 > void __stop_this_cpu(void); > =20 > -long cf_check cpu_up_helper(void *data); > -long cf_check cpu_down_helper(void *data); > - > long cf_check core_parking_helper(void *data); > bool core_parking_remove(unsigned int cpu); > uint32_t get_cur_idle_nums(void); > diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c > index e3c4c0d5e0..b56d8dfd36 100644 > --- a/xen/arch/x86/smp.c > +++ b/xen/arch/x86/smp.c > @@ -417,37 +417,9 @@ void cf_check call_function_interrupt(void) > } > =20 > #ifdef CONFIG_CPU_ONLINE_OFFLINE > -long cf_check cpu_up_helper(void *data) > +bool arch_cpu_keep_online(unsigned int cpu) > { > - unsigned int cpu =3D (unsigned long)data; > - int ret =3D cpu_up(cpu); > - > - /* Have one more go on EBUSY. */ > - if ( ret =3D=3D -EBUSY ) > - ret =3D cpu_up(cpu); > - > - if ( !ret && !opt_smt && > - cpu_data[cpu].compute_unit_id =3D=3D INVALID_CUID && > - cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) > 1 ) > - { > - ret =3D cpu_down_helper(data); > - if ( ret ) > - printk("Could not re-offline CPU%u (%d)\n", cpu, ret); > - else > - ret =3D -EPERM; > - } > - > - return ret; > -} > - > -long cf_check cpu_down_helper(void *data) > -{ > - int cpu =3D (unsigned long)data; > - int ret =3D cpu_down(cpu); > - > - /* Have one more go on EBUSY. */ > - if ( ret =3D=3D -EBUSY ) > - ret =3D cpu_down(cpu); > - return ret; > + return opt_smt || cpu_data[cpu].compute_unit_id !=3D INVALID_CUID || > + cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) <=3D 1; > } > #endif > diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c > index 10d485e633..a4254beabb 100644 > --- a/xen/arch/x86/sysctl.c > +++ b/xen/arch/x86/sysctl.c > @@ -121,13 +121,13 @@ long arch_do_sysctl( > =20 > case XEN_SYSCTL_cpu_hotplug: > { > - unsigned int cpu =3D sysctl->u.cpu_hotplug.cpu; > unsigned int op =3D sysctl->u.cpu_hotplug.op; > long (*fn)(void *data); > void *hcpu; > =20 > if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) > { > + ASSERT_UNREACHABLE(); > ret =3D -EOPNOTSUPP; > break; > } > @@ -135,13 +135,10 @@ long arch_do_sysctl( > switch ( op ) > { > case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: > - fn =3D cpu_up_helper; > - hcpu =3D _p(cpu); > - break; > - > case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: > - fn =3D cpu_down_helper; > - hcpu =3D _p(cpu); > + /* Handled by common code */ > + ASSERT_UNREACHABLE(); > + ret =3D -EOPNOTSUPP; > break; > =20 > case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE: > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 5713dc1f9c..329bb07ae9 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -648,8 +648,8 @@ config SYSTEM_SUSPEND > =20 > config CPU_ONLINE_OFFLINE > bool "CPU online/offline support" if EXPERT > - depends on X86 > - default y > + depends on !ARM || (!HAS_ITS && !TEE) I don't think this is correct, unless RISC-V also support this. Maybe introduce HAS_CPUONLINE_OFFLINE as we do for similar features? [...] --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Fri Oct 23 01:12:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 01:12:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458740.1670799 (Exim 4.92) (envelope-from ) id 1xK3pp-0005SR-FF; Fri, 23 Oct 2026 01:12:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458740.1670799; Fri, 23 Oct 2026 01: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 1xK3pp-0005SK-Ba; Fri, 23 Oct 2026 01:12:41 +0000 Received: by outflank-mailman (input) for mailman id 1458740; Fri, 23 Oct 2026 01:12:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK3po-0005SE-2w for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 01:12:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK3pn-006VAe-G2 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 03:12:39 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adab402-2eae-0a2a0a5409dd-0a2a450b92d2-42 for ; Fri, 23 Oct 2026 03:12:39 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adab481-b7e8-0a2a450b0019-b9ff1c2397e9-3 for ; Fri, 23 Oct 2026 03:12: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 1a166511467000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Oct 2026 01:12:32 +0000 Received: from localhost.localdomain (142.220.66.37.rev.sfr.net [37.66.220.142]) (Authenticated sender: ngoc-tu.dinh@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 0B9F082AFC; Fri, 23 Oct 2026 03:12: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; 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=UpzAsBL3BaDQJfl8w3oCa9ArcpkjvtzVZuOJOHge0/8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=kB6v+5+5cC4VmN4Ha6ikh6LrlL/bYKGQXJqOq26aEoxeuX5eqxcnXZJgfqFzZ78VDGjZiTVq1 I8gBJ+EwT/QAdurGqTbAppkKBS3Kzspd+bW1kpbLZELJJmZjFPBA09AJiPaWL6RE6/giPNy34wC XqISu/DGYFud74uEcKKq+mWRn9lAdJ23ltUJNo1ssYLgYfesO4g5gR5rGik3NjeqL7dlno0fcMD JGuQCLTS/xfXn+bEPst3q3qhDXuc2DtwKcOdSuhFOAwPAVOCcOy9JCbjx83cbm7I8i3dYWJswzY 5VJCXk6G38MinMalbudygImzytDKls8aYycoQa43EELg== X-Zone-Loop: 633eca05b336fd2e6cbe33ae48dc76d37611608504e3 x-campaign-type: default x-transaction-id: eef00c42-7d88-4d54-a551-d71c2fe88b73 x-swg-uid: 01-9f0a2a20-ce52-44d9-85bb-65df19ae3ce5 X-Mailer: Sweego Message-ID: <1792717952.8631fc262581453bbf619ec5b2062170.1a166511467000f79f@vates.tech> x-swg-bid: 1792717952.8631fc262581453bbf619ec5b2062170.1a166511467000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Tu Dinh To: xen-devel@lists.xenproject.org Cc: Tu Dinh , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/vpt: Validate timer object with generation number Date: Fri, 23 Oct 2026 03:12:28 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.14f.8573d86700e65843.1a1665110b1.4206c985e7a761a4=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792717951153 X-purgate-ID: tlsNG-42698a/1792717959-AB2DC9EA-958AB1A5/0/0 X-purgate-type: clean X-purgate-size: 3151 ---=Part.14f.8573d86700e65843.1a1665110b1.4206c985e7a761a4=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The remote completion path of pt_update_irq removes timers from tm_list by checking that their addresses match the previous iteration=2E However, if the guest rearms a timer during the gap between two list iterations, the resulting timer object is no longer the same, even if their addresses match=2E Removing the timer from the list will then lose the armed timer object=2E Record a generation number in each timer object upon arming, and check that the generation number matches before removing it from the list=2E Signed-off-by: Tu Dinh --- xen/arch/x86/hvm/vpt=2Ec | 6 ++++++ xen/arch/x86/include/asm/hvm/vpt=2Eh | 1 + 2 files changed, 7 insertions(+) diff --git a/xen/arch/x86/hvm/vpt=2Ec b/xen/arch/x86/hvm/vpt=2Ec index 50ed738998=2E=2Edce365f137 100644 --- a/xen/arch/x86/hvm/vpt=2Ec +++ b/xen/arch/x86/hvm/vpt=2Ec @@ -318,6 +318,7 @@ int pt_update_irq(struct vcpu *v) struct list_head *head =3D &v->arch=2Ehvm=2Etm_list; struct periodic_time *pt, *temp, *earliest_pt; uint64_t max_lag; + uint64_t generation; int irq, pt_vector =3D -1; bool level; =20 @@ -356,6 +357,7 @@ int pt_update_irq(struct vcpu *v) } =20 earliest_pt->irq_issued =3D 1; + generation =3D earliest_pt->generation; irq =3D earliest_pt->irq; level =3D earliest_pt->level; =20 @@ -411,6 +413,9 @@ int pt_update_irq(struct vcpu *v) list_for_each_entry ( pt, &v->arch=2Ehvm=2Etm_list, list = ) if ( pt =3D=3D earliest_pt ) { + if ( pt->generation !=3D generation ) + break; + pt_irq_fired(v, pt); cb =3D pt->cb; cb_priv =3D pt->priv; @@ -550,6 +555,7 @@ void create_periodic_time( set_timer(&pt->timer, pt->scheduled); =20 pt_vcpu_lock(v); + pt->generation++; pt->on_list =3D 1; list_add(&pt->list, &v->arch=2Ehvm=2Etm_list); pt_vcpu_unlock(v); diff --git a/xen/arch/x86/include/asm/hvm/vpt=2Eh b/xen/arch/x86/include/a= sm/hvm/vpt=2Eh index f6bcec8090=2E=2E8914ed6d5c 100644 --- a/xen/arch/x86/include/asm/hvm/vpt=2Eh +++ b/xen/arch/x86/include/asm/hvm/vpt=2Eh @@ -34,6 +34,7 @@ struct periodic_time { u8 irq; struct vcpu *vcpu; /* vcpu timer interrupt delivers to */ u32 pending_intr_nr; /* pending timer interrupts */ + u64 generation; /* distinguish two armings of the same ti= mer */ u64 period; /* frequency in ns */ s_time_t scheduled; /* scheduled timer interrupt */ u64 last_plt_gtime; /* platform time when last IRQ is injecte= d */ --=20 2=2E56=2E0 -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates = solutions web: https://vates=2Etech ---=Part.14f.8573d86700e65843.1a1665110b1.4206c985e7a761a4=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 23 01:56:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 01:56:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458761.1670807 (Exim 4.92) (envelope-from ) id 1xK4WK-0002pz-Id; Fri, 23 Oct 2026 01:56:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458761.1670807; Fri, 23 Oct 2026 01:56: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 1xK4WK-0002ps-Fo; Fri, 23 Oct 2026 01:56:36 +0000 Received: by outflank-mailman (input) for mailman id 1458761; Fri, 23 Oct 2026 01:56:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK4WI-0002pm-9u for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 01:56:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK4WH-00FAa2-J5 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 03:56:33 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adabe21-8faa-0a2a0a5109dd-0a2a450ca4f0-20 for ; Fri, 23 Oct 2026 03:56:33 +0200 Received: from [40.107.159.82] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adabed1-f479-0a2a450c0019-286b9f52683f-3 for ; Fri, 23 Oct 2026 03:56:33 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by MMZPR03MB647648.eurprd03.prod.outlook.com (2603:10a6:190:4c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Fri, 23 Oct 2026 01:56:29 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0546.012; Fri, 23 Oct 2026 01:56: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=GBt/SnjZ1NLSllOyb4MD36w7ZZLJAVstzU6JQllkjkcAnjqruW8WBzKTL5va3ItYznNV6+OSZkjcpCFjxQD5Sj9P105fum8YOLC7UOGcxO4dREyRDgOapJAc3jMVoLzcGwaHQCFA6agxyda8l4KvvzyOmIW63N6mAdPAIs5/BLOlEXkEd9Jp0M17Xk2quviTTyQlMe9jGCVFCk9jvTFIBm/9dyZRrDEMWRfk1Fo8RtPx3FbdKwh0AAL2hGeiOrTyllIhl7HtHP1QL3y4lEf2JIRIb5L3869KGEgjtDRO+9ulQfgE3Pmt+l5oZIFqwl66muW/sNoEdf8PODQBLd6kSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NzgvpxZwGof/EUUXE22kj+bYNxRo0NQ6DPaedQuJZYs=; b=bXScgLgqW2NTszhQnEbdlEFyOOmNyaramKJgEob/Ah4PKoN+Jgl5CbeEFJiRRVUcqpC2Z/8uNGt9++zZ6rGmeh/mddD1etrrG2Y/mSn1pkd9ILD3122uLMVb5YQ8hAj4TVweFAPYhzQKfVbA0IlOB+ltok9DgSHh0RcUhJVNt5nljl8Oihg8fQN2t6l1foKdPREU65OnwTRlXNHGuP4REqoZVakt4z4wy36BopDBtQci9EaoGRlgFq8guL2ylALKDxEge7UAktWCMB+nt0aXf8AEu/XrYq2tSsupblZeMtGre3yIoEawDKQTJhdXWx83TngCitOJGLtIM0SKMGT/YA== 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=NzgvpxZwGof/EUUXE22kj+bYNxRo0NQ6DPaedQuJZYs=; b=TmDWYDvJ8tVAB9rTp0XqpaeyEFb6C1UjizgUlDIeZsz1A1BlKrBryujqDwrXNXKuVQKDSLWtHVSsE+cIXv0PqoX5a81BaS8DWOtxxTW8nm0Cg3h0qlFE5Ty7UKwZ3B7RKHDtq2/3Q/VnhHjxHq7+hJsqG/6RvuY4YeJI4hrxkfirLLLlJJv2hD6mHJHC8jo4bbHhSwxGpkj2/cKtbyGhGbde/gkCyH3O8gwx30Nsf84wavA2O5LKsjPv/6Txuo0iRDEB5mi0yYpDg5ZQ+A5m38UuygqQOiKWNXd3tUQGUykm1yktIe8yPqZ62W0KMQvE0ciGAq0ZhqVosuJvIsZ40w== 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 v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdYG8UqIf/0AA9cU2/foNeomddPw== Date: Fri, 23 Oct 2026 01:56:28 +0000 Message-ID: <87mrs5tc1g.fsf@epam.com> References: In-Reply-To: (Oleksii Moisieiev's message of "Tue, 20 Oct 2026 08:43:20 +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_|MMZPR03MB647648:EE_ x-ms-office365-filtering-correlation-id: 139f6820-f35d-453b-f364-08df30a8da72 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|366016|42112799006|1800799024|23010399003|261022105027099003|260925021311599003|261022075727099003|260925021911599003|56012099006|261009223027099003|260925022911599003|4143699003|11063799006|38070700021|261021133027099003|261021123027099003|261021130227099003|261021121427099003|261021135927099003|10067099003|18002099003|22082099003|6133799003|261022115727099003|4133799003|3023799007|261022113327099003; x-microsoft-antispam-message-info: QvDFjY9Abfq0sOl54miuIrJX7P0Yh42wo4EK+J/KRKjnctzp6qjBUcdY1nAIk2OCm39q8ItMoeCG/B9U4Z8qxnS2AmT6f/7u/wzm3/gPfwOKIFdGqd/fclxTjbEeqlD3tx7HbcNAIxaidL2SstU1V7AIlAr5QcWJomLR8A7K6/qA6VfLl3zGSkE4EuUqHFbDqonDUYiPZ1aBo8+tISnfc78R2yJ2uXIONbp3v40ICgl26QhdBEIFsiX70Fy8S+K4piNpsxYF0qsKagfwZ+CpMoEvumoz4L9xB5CyiFd/HZJOzGbIt0h6KhrxOxJ47du+xS8XYu/VSHqdk85gvRdT781Jv/OFq+uFniIFSgcEl+h+x1oZ9GJSXtv6l2C7xVjjMPnQ/vuBqGI7XPjBExNhOlLjMHSKTwEDGt+knSYpjhrTzrC6XuHOsX3jAI/FZsuBwYDJ50aaVN0PPAaeRrng4VTMqZLVMq3aQ+4p32B+hBTavf+cdsofNongS0DDAvVu7FdaXTk2mFQauDag+zeKcM6QwNGMOMgluQfbd/RSNZRBbNSiBQt6qGZ+xAv3jCP53jGjdsJUGgbZVhlHH1ddtkbGGuEsGQctVYBq8i4Xkytp9HI1cEmAFrKj0bscgoWqqGSGaU2/FQXvH/KCTfCKoEiOvk3pxHNrlLunTgrpGo8= 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)(366016)(42112799006)(1800799024)(23010399003)(261022105027099003)(260925021311599003)(261022075727099003)(260925021911599003)(56012099006)(261009223027099003)(260925022911599003)(4143699003)(11063799006)(38070700021)(261021133027099003)(261021123027099003)(261021130227099003)(261021121427099003)(261021135927099003)(10067099003)(18002099003)(22082099003)(6133799003)(261022115727099003)(4133799003)(3023799007)(261022113327099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?J74lhKX56EnvlZNZv20YH8euuuYQEC6EfGt1/l2ZpdZEGJBw+I3BcAQCqG?= =?iso-8859-1?Q?nADirY2Fmi9EVlSRzCxvOrP68qXKDt7nW+lRPa2j63wDu+E1pWz8ld8ykk?= =?iso-8859-1?Q?P7iYxSUgbDfaTitUM/5DuJJ+MeHkvS696XXCIGIHDdl9xS83p+SPRfMjZp?= =?iso-8859-1?Q?bJ3Wt1JGmhHcGLlAJDqiZXdGBdx/lXt3QlP1bg6ceKRnNqK5qJzy2C93fv?= =?iso-8859-1?Q?2aods7SRF3Frpl3MRBtZmYIN8VMiFgvCiqRXkD52Uc3l4Scy3aGeppvHKQ?= =?iso-8859-1?Q?AiNc2wrrzNgzQSfPfXDzd7esZ/h054MUdO+D8CltFlclumr8BCfc/VKP5b?= =?iso-8859-1?Q?kC2kXbOJAAZmxWl3OUZbdsNS2ejFnxxq1jdepINnvVA8ohegh+rVcS2HnV?= =?iso-8859-1?Q?TzyAxhHZevZn5QK0YweqG6zmuwyIPif6A21U2W2CnE9gZqFFI/xrXVEQMm?= =?iso-8859-1?Q?S7AtgfpXwQjFT834SZIM9WpEmRCZD9z8f34dPCYwFF0zvsA9MlD2ybmMI3?= =?iso-8859-1?Q?ygpJtk2LXkFVZypgd9j68s+NP4a6wK4EcPwACagtL6ekwtPRHYZOn8QziM?= =?iso-8859-1?Q?36cvnow34c/RWWOKgQe5TWYl+/YGtUbXWpGQMYKB2CM/WmWmXFs6H5K3bp?= =?iso-8859-1?Q?25fJORLpSYzPcAHsyTqsZN5IrmFny103YQXYryuPM5el+UP0vF9Tsb11vT?= =?iso-8859-1?Q?5+3xMWYqFnANyezi1lfFBU9XNROYxNClGzOqiJ9dc28w8xA+3FoPy9tMxa?= =?iso-8859-1?Q?NkpLb2qdga+9mKayMfUntlZp5dRphQiegPxmjwYbGa6lniUfTkGPGb/OOS?= =?iso-8859-1?Q?fW3djk5m3tKksOXJTaOdM0dmEXWjL2GDXfas0vbSe/k02g1N+2+MCURcFg?= =?iso-8859-1?Q?yDMdGMHcu5IDuBsWPnMqGHIPCJbWhWxkqfqfvXrXCT0yWmzkSWeFi8XdQR?= =?iso-8859-1?Q?JRJzw9BqpWbmEeXHQx/cO5dVGcqyI5zOBPjW+u1fYvkAkBo90i7KAlJda1?= =?iso-8859-1?Q?GMODGZ3BqY/KTc2u0UGJhY/3JzanYJXdBMlIUXskK78EGeDsnwAilrNdWV?= =?iso-8859-1?Q?PU7JCg2d3XqYiMzyTGdYbQrgmOCry8gKijrROoeyP/Zy4OsK/jiUgGfYAw?= =?iso-8859-1?Q?VXRBkFrX8ompbPTv8zj4Ed/nfRS0cyU4bZ1tSPWRq+ZD17FQtH5lrRXghX?= =?iso-8859-1?Q?1tsbhAuUrXtccX5QBzwtVlG+H3F6ZurTyKRZqroONfmwCjydM9VdtComx3?= =?iso-8859-1?Q?vxGMGG2mLDcttGG6hytaYfauhNT61OgQabJumKJoTwvZJe9BLiPsE/pQ6E?= =?iso-8859-1?Q?BKqQjzxTEgHegoBp/v1BI9/ds575nAx/r+shhrZkpxSAIPFoGAKKDk7Z6t?= =?iso-8859-1?Q?nQNKyiNSZ+88I/gItbB7d8HtB2ziE0LjQQfog4vb3Jg52nntMAOKzIeQ5O?= =?iso-8859-1?Q?NIv/0u+ZJGLjMNqKRiTN0+bGLZp2pdw/Rkn1mDDHXz4LYDucs8HiNlsyVv?= =?iso-8859-1?Q?Lee9XrF2LWGxehVkVDlTboOionmh2z/9MKs6GLDiA6n9TvHIrsChyHLmyV?= =?iso-8859-1?Q?IaSXJ0b1NzjDtCXOEiClCulSkQkhVeapg66Nf7nrWFvIJE9dGdNzGMXvMW?= =?iso-8859-1?Q?zqQPQ0AlgnhnF15ycy0tIUEuysEOmDucQuL5b34suuewQvFbYdnrh93EPC?= =?iso-8859-1?Q?NI+wKOXxgWiq+A30JXs1l59C1XxFsN6lmxz78CUddkil5h28hpkHEKc4fY?= =?iso-8859-1?Q?WQPEpRyVqUEPNuxcKQ12GxhPt+Ub2toH+mVQjt2FTKPXWdGrS97BQZpx/Q?= =?iso-8859-1?Q?ms0o5G1+UwTpuRPsIS3jqV0HTou6liM=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: 139f6820-f35d-453b-f364-08df30a8da72 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2026 01:56:28.7205 (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: FTeKH5hekYy6tDj32+S6oovGK00eVlYRmmd+kujJq6fSJJXXI4FAfBL5kKT9buDBp0qD/eEJ8FItCWS1LCmbOPMIKXMyomE03YZ8WuGye9Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MMZPR03MB647648 X-purgate-ID: tlsNG-d25034/1792720593-5073F9FB-85E95DCF/0/0 X-purgate-type: clean X-purgate-size: 74405 Hi Oleksii, Oleksii Moisieiev writes: > 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 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 > 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 (required for Xen and secondary agents without reg) > - BASE_RESET_AGENT_CONFIGURATION (optional) > - BASE_SET_DEVICE_PERMISSIONS (optional) > > The driver binds to the arm,scmi-smc management node inside a Xen-specifi= c > container compatible with xen,sci under /chosen/xen. Other SCMI nodes, > including the host /firmware/scmi, are ignored by the mediator. > > Describe secondary agents as xen,scmi-agent children of an agents node > inside the same container. The agents node uses #address-cells =3D <1> an= d > `#size-cells =3D <0>`. Each child provides arm,smc-id and a single shmem = phandle. > The optional single-cell reg property supplies the SCMI agent ID (0..254)= . > When reg is absent, Xen discovers the ID using BASE_DISCOVER_AGENT on tha= t > channel. Use agent@ for an explicit ID, and a node name without a uni= t > address for discovery. Disabled agent nodes are ignored; at least one > enabled secondary agent is required. > > Resolve discovered IDs before adding channels to the list, so duplicate > IDs are rejected consistently, including clashes with Xen's management > agent. Explicit IDs avoid mapping and probing secondary channels during > initialization. Xen always discovers its own management agent ID. > > Keep shared-memory nodes under xen_scmi_config and leave the platform's > existing /firmware/scmi and host OSPM shared-memory node unchanged. Chann= el > nodes describe locations, rather than reserve memory: if firmware buffers > occupy system RAM, the platform DT must reserve the whole firmware-owned > range in /reserved-memory before Xen boots. A single reservation may cove= r > multiple channels, including unused ones. SRAM outside system RAM does > not require a RAM reservation. Channel nodes need not be moved into > /reserved-memory. > > For example: > > / { > #address-cells =3D <2>; > #size-cells =3D <2>; > > scmi_shm_0: 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>; > #address-cells =3D <1>; > #size-cells =3D <0>; > shmem =3D <&scmi_shm_0>; > }; > }; > > chosen { > #address-cells =3D <2>; > #size-cells =3D <2>; > ranges; > > xen { > #address-cells =3D <2>; > #size-cells =3D <2>; > ranges; > > xen_scmi_config { > compatible =3D "xen,sci"; > #address-cells =3D <2>; > #size-cells =3D <2>; > ranges; > xen,dom0-sci-agent-id =3D <0>; > > /* Xen 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>; > #address-cells =3D <1>; > #size-cells =3D <0>; > #access-controller-cells =3D <1>; > shmem =3D <&scmi_shm_1>; > }; > > agents { > #address-cells =3D <1>; > #size-cells =3D <0>; > > agent@0 { > compatible =3D "xen,scmi-agent"; > reg =3D <0>; > arm,smc-id =3D <0x82000002>; > shmem =3D <&scmi_shm_0>; > }; > > agent@2 { > compatible =3D "xen,scmi-agent"; > reg =3D <2>; > arm,smc-id =3D <0x82000004>; > shmem =3D <&scmi_shm_2>; > }; > > agent@3 { > compatible =3D "xen,scmi-agent"; > reg =3D <3>; > arm,smc-id =3D <0x82000005>; > shmem =3D <&scmi_shm_3>; > }; > }; > }; > }; > }; > }; > > To discover a secondary agent ID instead, omit reg from its node: > > agent-domu { > compatible =3D "xen,scmi-agent"; > arm,smc-id =3D <0x82000004>; > shmem =3D <&scmi_shm_2>; > }; > > The agents child nodes replace the former scmi-secondary-agents list and > `#scmi-secondary-agents-cells` property. The xen,sci subtree is omitted f= rom > Dom0's DT; the host OSPM channel is passed through when SCMI is enabled > for Dom0. Full configuration and domain examples are included in the > binding documentation and the hypervisor guide in patch 6. > > 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 v14: > - replace the flat secondary-agent list and its cell-count property with > xen,scmi-agent child nodes under agents, using reg for an optional ID > - scope secondary-agent parsing to the management channel's xen,sci conta= iner > - resolve discovered IDs before insertion and reject duplicate or invalid= IDs > - validate shared-memory phandles, addresses and nonzero page-aligned siz= es > - retain shared-memory nodes under xen_scmi_config and document platform > reservations separately, following the review discussion > - update binding examples and commit description for the child-node forma= t > - match the const-qualified SCI domain_sanitise_config callback interface > > 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 | 195 +++++ > 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 | 792 ++++++++++++++++++++ > xen/include/public/arch-arm.h | 5 +- > 12 files changed, 1403 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 3787d2e2b6..178f2493d8 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,183 @@ 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= . > + > +- agents > + > + Required child of the xen,sci container. Describes the secondary SCM= I > + agents available for assignment to domains. Set #address-cells =3D <= 1> > + and #size-cells =3D <0> in this node. At least one enabled child wit= h > + compatible =3D "xen,scmi-agent" is required. Each such child has: > + > + - reg: Optional single-cell SCMI agent ID in the range 0..254. When > + present, name the node agent@, with the unit address in hexade= cimal. > + When absent, use a name without a unit address; Xen discovers the = ID > + using BASE_DISCOVER_AGENT on that channel. A malformed reg is reje= cted. > + - arm,smc-id: Required SMC function ID for this agent's doorbell. > + - shmem: Required single phandle to an arm,scmi-shmem node. Its addr= ess > + and nonzero size must be Xen page aligned. > + > + Agent IDs must be unique, including IDs returned by discovery, and m= ust > + not identify Xen's management agent. Children marked disabled are ig= nored. > + The management arm,scmi-smc node remains a sibling of agents, direct= ly > + under xen,sci. > + > +- 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 selected > + agent's ``func_id`` and shared-memory region must match the host > + ``/firmware/scmi`` channel passed to Dom0. > + > +The shared-memory nodes may remain inside xen_scmi_config, while the > +platform's existing /firmware/scmi and its shared-memory node stay uncha= nged. > +Shared-memory nodes describe channel locations; they do not reserve RAM. > +If the channel buffers occupy system RAM, the platform DT must reserve t= he > +whole firmware-owned range in /reserved-memory before Xen boots. One > +reservation may cover several channels, including channels not listed in > +this configuration. SRAM outside system RAM does not require a RAM > +reservation. Moving the channel nodes into /reserved-memory is not requi= red. > + > +As an example: > + > +/ { > + #address-cells =3D <2>; > + #size-cells =3D <2>; > + > + scmi_shm_0: 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>; > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + shmem =3D <&scmi_shm_0>; > + }; > + }; > + > + chosen { > + #address-cells =3D <2>; > + #size-cells =3D <2>; > + ranges; > + > + xen { > + #address-cells =3D <2>; > + #size-cells =3D <2>; > + 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 */ > + > + /* Xen 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"; /* Xen management age= nt func_id */ > + arm,smc-id =3D <0x82000003>; > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + #access-controller-cells =3D <1>; > + shmem =3D <&scmi_shm_1>; /* Xen management agent shm= em */ > + }; > + > + agents { > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + > + agent@0 { > + compatible =3D "xen,scmi-agent"; > + reg =3D <0>; > + arm,smc-id =3D <0x82000002>; > + shmem =3D <&scmi_shm_0>; > + }; > + > + agent@2 { > + compatible =3D "xen,scmi-agent"; > + reg =3D <2>; > + arm,smc-id =3D <0x82000004>; > + shmem =3D <&scmi_shm_2>; > + }; > + > + agent@3 { > + compatible =3D "xen,scmi-agent"; > + reg =3D <3>; > + arm,smc-id =3D <0x82000005>; > + shmem =3D <&scmi_shm_3>; > + }; > + }; > + }; > + }; > + }; > +}; > + > +This keeps the host OSPM channel (SMC 0x82000002, shmem 0x47ff0000) sepa= rate > +from Xen's privileged management channel (SMC 0x82000003, shmem 0x47ff10= 00). > +The xen,sci subtree is omitted from Dom0's device tree. > + > +To discover a secondary agent ID, omit reg from its node. For example, > +replace only agent@2 above with: > + > +agent-domu { > + compatible =3D "xen,scmi-agent"; > + arm,smc-id =3D <0x82000004>; > + shmem =3D <&scmi_shm_2>; > +}; > + > +BASE_DISCOVER_AGENT is required on secondary channels only when reg is > +omitted. Xen always uses it to discover its management agent ID. Providi= ng > +reg avoids mapping and probing the secondary channel during initializati= on. > +The scmi-secondary-agents and #scmi-secondary-agents-cells properties us= ed > +by earlier versions are replaced by the agents child nodes. > + > +Dom0less example (multi-agent) > +------------------------------- > + > +Use the same Xen SCMI configuration as above. Remove xen,dom0-sci-agent-= id > +if Dom0 does not use SCMI. Add xen,sci_type and xen,sci-agent-id to the > +predefined guest's node under /chosen: > + > +chosen { > + 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.) */ > + }; > +}; > + > +The guest's partial DT and shared-memory mapping must use the SMC functi= on > +ID and shared-memory channel associated with agent 2 in the agents node. > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.= c > index 7bbb2eafb6..01c2a5ce52 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -293,6 +293,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 72f6f7539a..5d42cdf6af 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -88,6 +88,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)) > @@ -1480,6 +1513,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 > @@ -1975,6 +2009,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"); "of the SMC message". Also, looks like it is over 80 characters. > + 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); Why do you mix writel() and writel_relaxed() here? > + > + 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"); "of the input SMC message" > + 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")= ; "of the SMC message" Also, I am wondering if you really need to print this error messages in the first place. > + 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[]; > +}; Should it be __packed? > + > +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE > + > +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, I am not sure if volatile makes sense here, taking into account that this is __iomem anyway. Also, shmem_put_message sounds to generic... Maybe scmi_put_message? > + 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); Basically the same comments as for previous one. > +#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..6c46f6cd36 > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c > @@ -0,0 +1,792 @@ > +/* 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" > + > +struct scmi_channel { > + uint32_t agent_id; If all agent_ids large than UINT8_MAX are invalid, why do you need uint32_t here? > + uint32_t func_id; > + domid_t domain_id; > + uint64_t paddr; paddr_t > + 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); You will print this even if send_smc_message() fails. I think it should go before "clean:" label. Also, maybe "cleanup:" ? > + > + 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, You will need proper format, not "%lx" for 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, Then you can put this function into __init as well > + * 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_channel_addr(struct dt_device_node *scmi_node, u64 *addr, > + u64 *size) > +{ > + struct dt_device_node *shmem_node; > + uint32_t phandle; > + int ret; > + > + ret =3D dt_property_read_variable_u32_array(scmi_node, "shmem", &pha= ndle, > + 1, 1); > + if ( ret < 0 ) > + return ret; > + > + shmem_node =3D dt_find_node_by_phandle(phandle); > + if ( !shmem_node || > + !dt_device_is_compatible(shmem_node, "arm,scmi-shmem") ) > + return -EINVAL; > + > + ret =3D dt_device_get_address(shmem_node, 0, addr, size); > + if ( ret ) > + return ret; > + > + if ( !*size || !IS_ALIGNED(*size, SCMI_SHMEM_MAPPED_SIZE) || > + !IS_ALIGNED(*addr, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: invalid shmem range for %s\n", > + scmi_node->full_name); > + return -EINVAL; > + } > + > + return 0; > +} > + > +/* > + * 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) Also __init? > +{ > + 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 ) On error, Xen's channel will be mapped still. Is this intended behaviour? > + 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 int __init collect_agents(struct dt_device_node *scmi_node) > +{ > + struct dt_device_node *agents, *node; > + unsigned int count =3D 0; > + > + /* Use the configuration containing this management channel. */ > + for ( agents =3D scmi_node->parent; agents; agents =3D agents->paren= t ) > + if ( dt_device_is_compatible(agents, "xen,sci") ) > + break; > + > + ASSERT(agents); > + > + dt_for_each_child_node(agents, node) > + if ( dt_node_name_is_equal(node, "agents") ) > + break; > + > + if ( !node ) > + { > + printk(XENLOG_ERR "scmi: missing agents node\n"); > + return -EINVAL; > + } > + agents =3D node; > + > + if ( dt_child_n_addr_cells(agents) !=3D 1 || > + dt_child_n_size_cells(agents) !=3D 0 ) > + return -EINVAL; > + > + dt_for_each_child_node(agents, node) > + { > + struct scmi_channel agent =3D { > + .agent_id =3D SCMI_BASE_AGENT_ID_OWN, > + .domain_id =3D DOMID_INVALID, > + }; > + struct scmi_channel *channel; > + bool discover; > + uint32_t len; > + u64 size; uint64_t > + int ret; > + > + if ( !dt_device_is_compatible(node, "xen,scmi-agent") || > + !dt_device_is_available(node) ) > + continue; > + > + discover =3D !dt_find_property(node, "reg", &len); > + if ( !discover ) > + { > + if ( len !=3D sizeof(uint32_t) || > + !dt_property_read_u32(node, "reg", &agent.agent_id) ) > + return -EINVAL; > + } > + > + if ( !dt_property_read_u32(node, "arm,smc-id", &agent.func_id) ) > + return -EINVAL; > + > + ret =3D scmi_dt_read_channel_addr(node, &agent.paddr, &size); > + if ( ret ) > + return ret; > + > + if ( discover ) > + { > + /* Resolve the ID before inserting it into the channel list.= */ > + spin_lock_init(&agent.lock); > + ret =3D collect_agent_id(&agent); > + if ( ret ) > + return ret; > + } > + > + /* Guest configurations encode agent IDs in an eight-bit field. = */ > + if ( agent.agent_id >=3D UINT8_MAX ) > + return -EINVAL; > + > + channel =3D smc_create_channel(agent.agent_id, agent.func_id, > + agent.paddr); > + if ( IS_ERR(channel) ) > + { > + printk(XENLOG_ERR "scmi: Could not create channel for %s: %l= d\n", > + node->full_name, PTR_ERR(channel)); > + return PTR_ERR(channel); > + } > + > + count++; > + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", > + agent.agent_id, agent.func_id, (unsigned long)agent.paddr= ); Why cast to unsigned long? > + } > + > + return count ? 0 : -EINVAL; > +} > + > +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(const struct xen_domctl_createdomain *co= nfig) > +{ > + 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); You can use "%pd" > + > + 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) > +{ > + 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; > + } > + > + return scmi_dt_read_channel_addr(scmi_node, addr, &size); > +} > + > +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 14d51e0746..722c2d2e3a 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 > @@ -347,7 +348,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 Fri Oct 23 02:37:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 02:37:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458777.1670822 (Exim 4.92) (envelope-from ) id 1xK59V-0008Rm-Ql; Fri, 23 Oct 2026 02:37:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458777.1670822; Fri, 23 Oct 2026 02: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 1xK59V-0008Re-MM; Fri, 23 Oct 2026 02:37:05 +0000 Received: by outflank-mailman (input) for mailman id 1458777; Fri, 23 Oct 2026 02:37:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK59U-0008P6-Ah for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 02:37:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK59T-00B5NI-AO for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:37:03 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adac81d-bab6-0a2a0a5309dd-0a2a4506a7da-14 for ; Fri, 23 Oct 2026 04:37:01 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adac84a-195a-0a2a45060019-9fe2fb159b12-3 for ; Fri, 23 Oct 2026 04:37:01 +0200 Received: from [10.213.11.11] (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowABXKu4+yNpqo_iFCw--.1153S2; Fri, 23 Oct 2026 10:36:53 +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 v7 2/4] xen/riscv: fix A/D bits in Xen's page-table mappings From: Zhang Zheng To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang In-Reply-To: <1792164866.8631fc262581453bbf619ec5b2062170.1a14559aa020008425@vates.tech> References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164866.8631fc262581453bbf619ec5b2062170.1a14559aa020008425@vates.tech> Date: Fri, 23 Oct 2026 10:37:21 +0800 Message-Id: <179272304115.337595.12904917917015859560.b4-review@b4> X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=816; i=zhangzheng@iscas.ac.cn; h=from:subject:message-id; bh=kc2zaGKYmCiccjH+nPyaXAH+en1p1LJ02E9kHLIMX5k=; b=owGbwMvMwCWmtfXriinfWuMYT6slMWTdOpHU5VCnI3EmU+vduV8x52MfZbTdX7ctVvxwxIxpG xZlvvli01HKwiDGxSArpsjC73XP3Of8z40cYSH7YOawMoEMYeDiFICJhNsx/K9pvfF4q8HlhbuL ftnbasgvfzQ7onXPh4scukWLeAXPemcwMuw5Ucegs/KS79mjFjbL+9fcjGuUauN+UP3zhsTZ/IV mP9gB X-Developer-Key: i=zhangzheng@iscas.ac.cn; a=openpgp; fpr=0F4ADE374CCFF9B1085654BE2AB5F5A894F6855E X-CM-TRANSID:qwCowABXKu4+yNpqo_iFCw--.1153S2 X-Coremail-Antispam: 1UD129KBjvdXoWrurW7Cr13try7tr18uw45Jrb_yoW3urg_u3 ZYkFWkKa43Wr4FvanxtF1xCF4Skr4jgw45XFyq9rn0yasxKr47CF9IvrySkF18Ja97Jr1x ur17ur4Fgas3ujkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb3AFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8w A2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJV W0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUtVWrXwAv7VC2z280aVAFwI0_Cr1j6rxdMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2 Y2ka0xkIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWU CwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCT nIWIevJa73UjIFyTuYvjfU7nmRUUUUU X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-16d1c6/1792723021-F6C7777B-1CE82341/0/0 X-purgate-type: clean X-purgate-size: 818 On Fri, 16 Oct 2026 17:34:18 +0200, Baptiste Le Duc wrote: > Xen does not handle page faults caused by clear A/D bits, so it presets > them when creating PTEs. pt_update_entry() does so, but three places build > leaf PTEs directly without going through it: setup_initial_mapping() (the > boot page tables), check_pgtbl_mode_support() (the temporary root entry > used to probe SATP mode support) and arch_pmap_map() (the fixmap). > > On implementations that fault on clear A/D bits (Svade), all three fault > on first access. For check_pgtbl_mode_support(), the fault is raised by the > instruction fetch right after the SATP write, before any trap handler is > set. > > [...] Tested-by: Zhang Zheng -- Zhang Zheng From xen-devel-bounces@lists.xenproject.org Fri Oct 23 02:37:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 02:37:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458776.1670816 (Exim 4.92) (envelope-from ) id 1xK59V-0008PP-Ip; Fri, 23 Oct 2026 02:37:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458776.1670816; Fri, 23 Oct 2026 02: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 1xK59V-0008PI-G4; Fri, 23 Oct 2026 02:37:05 +0000 Received: by outflank-mailman (input) for mailman id 1458776; Fri, 23 Oct 2026 02:37:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK59U-0008P7-Ag for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 02:37:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK59T-00B5NI-Cm for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:37:03 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adac81d-bab6-0a2a0a5309dd-0a2a4506a7da-16 for ; Fri, 23 Oct 2026 04:37:03 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adac84b-195a-0a2a45060019-9fe2fb15d096-3 for ; Fri, 23 Oct 2026 04:37:01 +0200 Received: from [10.213.11.11] (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowABXKu4+yNpqo_iFCw--.1153S3; Fri, 23 Oct 2026 10:36:53 +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 v7 3/4] xen/riscv: panic if the device tree advertises neither Svade nor Svadu From: Zhang Zheng To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang In-Reply-To: <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> Date: Fri, 23 Oct 2026 10:37:21 +0800 Message-Id: <179272304115.337595.14865693414645755406.b4-review@b4> X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=968; i=zhangzheng@iscas.ac.cn; h=from:subject:message-id; bh=So+yot9otXL5vbasQ7K/8eO8HyI+tia4WGs8od+lik8=; b=owGbwMvMwCWmtfXriinfWuMYT6slMWTdOpEhL3hZtHGWY73HeymT08xHTWILFpkKHtWvX6wwq e9UzJllHaUsDGJcDLJiiiz8XvfMfc7/3MgRFrIPZg4rE8gQBi5OAZjIPD+G/wk3/wr/+cNozF53 py11UuPdPwEvv+67cCN4w5GFtSa/12swMmzn6y01cLQr/32D0+tx3Mx9XtMv7RYR+6vOl56l9W7 tSm4A X-Developer-Key: i=zhangzheng@iscas.ac.cn; a=openpgp; fpr=0F4ADE374CCFF9B1085654BE2AB5F5A894F6855E X-CM-TRANSID:qwCowABXKu4+yNpqo_iFCw--.1153S3 X-Coremail-Antispam: 1UD129KBjvdXoW7GrWktrW8Cw13tF1fJw4Dtwb_yoWftrX_XF Wv9F18C3ySgF1rCan3JF15AF1xJrsrK3y8XrZ0grs3G34aqa45WFyFgryF9r1UJw43JF95 u34qqrsxGwsFkjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbkAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUGwA2048vs2IY02 0Ec7CjxVAFwI0_Gr0_Xr1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWxJVW8Jr1l84 ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUtVWrXwAv7VC2z280aVAFwI0_Cr1j6rxdMcvjeVCFs4IE7xkEbVWUJVW8JwAC jcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka0x kIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1V AY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAI cVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjfUYKsjUUUUU X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-16d1c6/1792723022-FE87577B-14976A82/0/0 X-purgate-type: clean X-purgate-size: 970 On Fri, 16 Oct 2026 17:34:19 +0200, Baptiste Le Duc wrote: > p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when > RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. > > The privileged spec allows exactly two schemes for updating the PTE A and D > bits: hardware sets them on access and on write, or accessing a page whose > A and/or D bit is clear raises a page fault so that software can set them > (ratified as Svade). Every implementation uses one of them, but platforms > designed before Svade and Svadu were ratified, such as the HiFive Premier > P550, may advertise neither. Xen then cannot tell which scheme is in > effect, so rather than guess, panic in riscv_fill_hwcap() when the device > tree advertises neither Svade nor Svadu, so that the device tree gets > fixed. > > [...] Tested-by: Zhang Zheng -- Zhang Zheng From xen-devel-bounces@lists.xenproject.org Fri Oct 23 03:08:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 03:08:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458793.1670835 (Exim 4.92) (envelope-from ) id 1xK5dN-0004Mf-0r; Fri, 23 Oct 2026 03:07:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458793.1670835; Fri, 23 Oct 2026 03:07: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 1xK5dM-0004MY-UK; Fri, 23 Oct 2026 03:07:56 +0000 Received: by outflank-mailman (input) for mailman id 1458793; Fri, 23 Oct 2026 03:07:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK5dM-0004MS-Cf for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 03:07:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK5dL-00FHW9-PK for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 05:07:55 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adacf85-2eae-0a2a0a5409dd-0a2a450796b2-2 for ; Fri, 23 Oct 2026 05:07:55 +0200 Received: from [74.125.224.44] (helo=mail-yx1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adacf8a-b4ea-0a2a45070019-4a7de02cb183-3 for ; Fri, 23 Oct 2026 05:07:55 +0200 Received: by mail-yx1-f44.google.com with SMTP id 956f58d0204a3-675617e81f9so483465d50.3 for ; Thu, 22 Oct 2026 20:07: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=1792724874; cv=none; d=google.com; s=arc-20260327; b=VsSgvb4DhumzRLcEeC5k7Aat3QePoxsFvcpBhlNKR89w0f7Ufnuai46D4NfGDJPhYl qC+PAd3TwGXDxb9rud2H7FwHByRdg1iP/Du4BRSahZlF2b+TfAw6n0z+IRR2/scVdMvS ZC0C7I3zvKAoVDuENkxMEvFRfuLvnTD2UDLgdRF4wzahVfDhzZx9xwvM48RPPwPpTIel ez1+MK2OlHVLpjfbe6rcR7M2QjtHUINi3rCrImOMbjfvtY6/VWdNAmoBX6Jy5JwFLE2K YVAagSQDEY8aQTcbItEp8CdcglMiukgy5gwHL5w6b7cIy1zxUzlnToRK5wI9g6PykSe9 6B1Q== 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=hgV4FpDL0VDAwuHx+GSLC+BPtqKn4ASJs6Viz9YKJlE=; fh=3CKQEljtludsAruFLrms6jIE/S6hEszVJBxpFWIkCPM=; b=gihe/4EZySI+qvd3ZWHhzUBJWY/NUrHk8UJftn3s/oIqUu1eOThnRWupv9Qn3itskg ScpSNFSd+Ax6J/xh5/fWwifaE2MW0PlkdDAlRgLLdXcdZEn5R+RiyUUNFgiwjdMITRc1 JHHadPPGSzFWhD94qmZSvdkqOj7fMisByVDY3v1UPx1qBehDQeOvcX/6CiMJaceM2wky 7tec+hGQfZaG/37xHh1iHhb1OY+y7Dl/h5E7MjhSes/deG7JzTMpHYhxd0hbN2lMPtpu P8PimewbGXtXpM+v1K2D6XywaOTutXDhTfWqHNrK6wE+UJBVWdPTyzxh7uOcgbU994t3 fKlg==; 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=1792724874; x=1793329674; 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=hgV4FpDL0VDAwuHx+GSLC+BPtqKn4ASJs6Viz9YKJlE=; b=drgHK5Y2fBRJSz3wKyGMcZAtCD+ljD3VprpDb+OkkIPwPr52XrHJY6RoTp8leRZPR5 shgYVFXgWP2L4g8IR13ZayZU1cVVbfuJVRDlHKHl4D9BB000nctKsSz2ObMrqp4SbPwm 3EYMEPqBacsgqTp0MWTfqyALDGB8nIoJcP+Tz7m2CHxwdpigJkWEjNic8H9+drb7nzxT M0cLSJ7jp8EaSljMguBCfq0GXqW6z/ia6LVcY/jSBzLPHuLY2WPKYrYvZFkmFKq7+8Uu 9PSfewLIwKPzHX//B8H4rtV3qrDok97gObXUK0Tl9otYJ4LJO7OTdwze9k9manS49KBE ldUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792724874; x=1793329674; 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=hgV4FpDL0VDAwuHx+GSLC+BPtqKn4ASJs6Viz9YKJlE=; b=tPL5dNoftxqZXjNMoDQ8Thifj6+ybNIfiiW93WVKZp8m09SDwol5S1ftY7Ejuc8PSu qzQ6lTIVScfNhQeqRsPFIU2pwFbjietJoUYol+OxJf6zwmZ3Vle4bL41w9qHaJLUH/1J 0Ate/Uekw0fnUJsqRKID8n4M4ZdsPev3lqf6qFeYQ2QPXoz1tbaeEWG8lEWm923zG1oq Ihpr/Z30go6dSck7zgFbj8tlBqkrg5lAa7Q5GnNix72Fd/dtjQ6VZPO7t/tI2xe/1OYz 2FMXTXfCGlg4ox6yo/zWwVNaWr+dND3KkVy1TAG9F3T/Wh3myeWJ/m/1AQpOVKYFROd+ cCnw== X-Forwarded-Encrypted: i=1; AKwUvBxAN20bgWT8jYfFNp9ZRXK//6OPpQYGoyHLtWPYh/ZSEtCULIJNwj58lmGZbON8/7OdJM7Cafp6Ii8=@lists.xenproject.org X-Gm-Message-State: AFq9FYKkNYPWSZakX1l2gRwBtSM1MnzXKcjD8C+l0EU1DVnNmPY5wi83 9F20YBooisj/dY2lfLRWWAsls/hkiCBK0m99kYmt+Vp/0V1K4H1O5P8PH0tptuplfWyVaEiUPt/ hJU7fXF7Ev7yOFafN+VUp6IIOI/dkUBs= X-Gm-Gg: AYBFou0oVWsGCmNYgWbxZCA7ITJtZBwDTjJJZgkzbmbdrThErlJxDvideqB6/C6KCyj wxPNnoA+H+SO2esdJCkcYK4Uw9kN5YLIW8/XWCiXrQxtBl68jkqCNNN5GLLirlS06N2xBvhqbML 2XtuQufopa6H+3sMvJ4LtEyurIhrAib7ip0Up7IAZQvyX6Px7TZfBUKQNHPLDqIP6Jj2QRaxWyb xX5WdNgYNK0LpVIG6FbT/6GcbEyYHl05/keboRXxHe/d4CsahoO7DAFZiwuDN5IfSW+CNydHyyQ uK/XRSvH/UwO0nEvsJoBjLvn6YXtexQv1ygwVIV+ggKNaMK//MffMdmwCmIukKNiuySnsG73KFy wRV5m10n1J5HIECDvODv+iWhShXboH3qlC1NJw+f81NlPJhifY+G8rWGqhPzDMrLzEfd1SAl3mY gEyjokFzQufCs6SzU2wVT4NkaE1APMNRuH0BodcAA1J+L1oIqaFfOuuso= X-Received: by 2002:a05:690e:458a:10b0:679:ad95:8ef8 with SMTP id 956f58d0204a3-67a35c2885bmr500156d50.62.1792724874233; Thu, 22 Oct 2026 20:07:54 -0700 (PDT) MIME-Version: 1.0 References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-11-2aa780a03524@toxicpanda.com> <179269910950894.2.12425346173477603662@toxicpanda.com> In-Reply-To: <179269910950894.2.12425346173477603662@toxicpanda.com> From: Willem de Bruijn Date: Thu, 22 Oct 2026 23:07:16 -0400 X-Gm-Features: AclHuK-kPKdrZO6IqfAWEst6DHPn5D-__xAfjpDX0uBuJFbspUZGaComuYzzAUg Message-ID: Subject: Re: [PATCH net-next v2 11/15] net: skbuff: refuse to segment a nested frag_list To: Josef Bacik Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Fernando Fernandez Mancera , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Willem de Bruijn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1792724875-3C817AE4-E68EFB52/0/0 X-purgate-type: clean X-purgate-size: 2395 On Thu, Oct 22, 2026 at 8:44=E2=80=AFPM Josef Bacik = wrote: > > On Wed, Oct 21, 2026 at 09:47:15PM -0400, Willem de Bruijn wrote: > > This patch became quite a bit more complex because of my request. > > More than I anticipated. > > > > Are you sure this first block is needed? > > No, it isn't. I took it out and ran three KUnit cases with a nested > frag_list under GSO_BY_FRAGS: a linear first member with the nested > bytes counted in its len, the same without them counted, and a paged > first member. They all still get -EINVAL, from the check in the clone > branch or the one in the frag walk. > > > this test for list_skb !=3D NULL is new. Previously this code already > > tested skb_headlen(list_skb) without it. Likely not needed for > > anything new in this patch? > > Same answer, the cases above pass without it too. With every member > checked as it's taken, list_skb can only run out if head_skb->len is > wrong for some other reason, which isn't what this patch is about. > > So done this way the patch comes down to the check you suggested in the > frag walk, plus skb_has_frag_list(list_skb) added to the existing > headlen check in the clone branch. The second one is needed: with only > the frag walk check, the frag_list_nested KUnit case still hits a NULL > pointer dereference in skb_segment(), because the linear member is > cloned, list_skb becomes NULL, and the next pass reads its headlen. > > The other option is to go back to the single walk up front from v1. > It's an extra pass over the frag_list, but it's one check in one place. > The difference in behaviour is without SG: there a nested frag_list > whose member doesn't match gso_size goes through the copy path, which > recurses, and a KUnit case for that gets correctly sized segments > today. The in-walk checks leave that alone and the up front walk would > refuse it. Nothing in the tree builds a nested frag_list either way. > > I lean towards the walk up front for v3 because it's simpler to read. > Would you be ok with that, or do you prefer the two in-walk checks? Given the complexity of skb_segment already, and how non-trivial the added inline checks are, I'm also okay with the up front walk. It only adds cost for GSO skbs that use a frag_list. Though that may include some relatively common cases, such as BIG TCP. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:48:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:48:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458812.1670845 (Exim 4.92) (envelope-from ) id 1xK7Cj-0008Uq-Vc; Fri, 23 Oct 2026 04:48:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458812.1670845; Fri, 23 Oct 2026 04: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 1xK7Cj-0008Uj-R7; Fri, 23 Oct 2026 04:48:33 +0000 Received: by outflank-mailman (input) for mailman id 1458812; Fri, 23 Oct 2026 04:48:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7Ch-0008T6-UN for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:48:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7Ch-006ryP-0R for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:48:31 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae6fb-8faa-0a2a0a5109dd-0a2a4506a352-38 for ; Fri, 23 Oct 2026 06:48:30 +0200 Received: from [40.107.74.107] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adae71b-195a-0a2a45060019-286b4a6b5a71-3 for ; Fri, 23 Oct 2026 06:48:29 +0200 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYRP286MB5946.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:2f0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Fri, 23 Oct 2026 04:48:25 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.016; Fri, 23 Oct 2026 04:48: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=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=nwuKZQ01gcMAnezMGltDUUaqrnwtnoz0R/cawn/hLIcGlkmOOEr7WFnqqLd7C+T+fcgGuSK6jkGCFMC8IwHs0THiV3BHA7oVCw2MvWxKytY1DLKOW6HZUpRq3SdwyzH4565OGssaJqlQuB6n/CBZocWFCvTsjp6giHLm6lItDyWF8N9pJxyvHugbmE+GwonLMC6mOhKdRPYusPXoZagFSMgxG2Awfq13asD0uL/WqcPal6yLbCx28d/XFJ+EhkLWX7fBmq5GqBdssK3A5ybPMsz8xa0xjpNKEEFmRHdPm/ROGmHVNTzyoroI1JmOj6mDBxS9B5YXZMYVp6AHl9UJdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KwHOlk5cGD/ygVVQmfIA8/k+P+ZJhK+XztwkDguMums=; b=KWzlNkNDmYPvQ5omI8Jtnr7eVNI9y89Nxdjbl0KiKJQ5uSBhasyaO+yYpJh7nWyBa9oGBNPWzUHOM3n8TUma431Ji+cS27UoI1q13vri5cEWl5I5Qk/gL528ubWIGle2hZuYzqNPNZ3Vgt1GoVMzyRrxkKqqkNtyQsCTLlx1x1bTaziLZhawNk6ueqZmaN9x80KmrSJr9uLhZKxY80hoi4dx1yx+XjFuDLVgKIChiEkkAWfgup3KwnSqJ3WSpeHbJ16C6qlt3XKS8CRBXBzyl5A8Pxq9tVm6MmlMshmv9Legh0HbvrpweXOirmBmxA8qChm55/DE8U3PVjrGs2tawA== 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=KwHOlk5cGD/ygVVQmfIA8/k+P+ZJhK+XztwkDguMums=; b=vjKR1YCnVWE2A1OIQfnx38Sl23zm66kfWnG3pCARSjfXxxDxKu03Rpqnr2LwUEAWdGIidv4PKaDHNimjDkcbqWCNObCa+vLTZ+UD2rbVK1FbiBe3wo0o5UK2mL8on+Dz/ZznwKfu4ioowJQLOYiU5i4wOrKNxUQfoqovAZ3kbEg= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: xen-devel@lists.xenproject.org Cc: Ryo Takakura Subject: [RFC 0/5] Introduce dynamic tracer using Livepatch Date: Fri, 23 Oct 2026 13:48:09 +0900 Message-Id: <20261023044809.162759-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TY4PR01CA0068.jpnprd01.prod.outlook.com (2603:1096:405:370::10) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYRP286MB5946:EE_ X-MS-Office365-Filtering-Correlation-Id: 3edbfa9e-d947-4e17-ad4f-08df30c0df87 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|6133799003|10067099003|18002099003|261021123027099003|261022105027099003|3023799007|261022075727099003|261021121427099003|261009223027099003|56012099006; X-Microsoft-Antispam-Message-Info: gyV0CWdoCMsv81PC48jaxe021P1D2ZtdGCK1SJyF4odDebZeafsF0B74yKPLfRgy+6FXfoK+bGy2Z6hhdVLW8cnlbP4VX9qDzrfaFaMhKb6vEZgWYJK1kJrsyl7BOlW70uiJ3vadRjXhybOHjDJVOUiJlH+LUu4JusvkcbLbO1ZppqwQ+SyUjJNstsvnxV13uvRN3w0JeLnMDaz0oJymVivTisGmwpiRjEG2tdClOYq8ItPAQG2TmWYjaOAkDph8MkKlvMPxoHD1Gg5tdsUfTwzPWBAXfGJzYogesfUjQUe2Mvoph0hH3hnlVRqlXYgJkUIfTGMk33zOh8Ob6OP9s91mZ+1VsajtMQbxZqKgfaKoXRgxMplr5kE+hvl5DgE3x0ZUh4051pDC4fnxrcgz5PTIcjCVkASyjnWRHGD+hFGNPlkQDv4eR3gFiOjv8r63mW7mwqDpykkFUoKpDs8dG625DPysAPoRYJr4CfIPvUklNuaWcz1nUuaDlAY0XPy/9/I742YMJaTkadxKIZS6p5bEDSTMxo7HDCV7ZQ4HUMo1wVrz5t4OTRhbfoPI++E22oS6W56Zc+07fu3xOzTjsimscVEiDTdEH5qBYI+KMqj3xbmPPwt4kVpw2DkdCqow X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(6133799003)(10067099003)(18002099003)(261021123027099003)(261022105027099003)(3023799007)(261022075727099003)(261021121427099003)(261009223027099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?DWW1XaStJuupxgC8rTlF60SuSDxpQ5D0vErjV8LIInafP3W0o0X0e9PmTsVY?= =?us-ascii?Q?w5EJgp4FeaqBUOSia1H0hT2FpBU9TNrgobE2bcB706rFg2rhboSO8h+T86Ki?= =?us-ascii?Q?agDcysgZMPzM/kHje3esdG71kNFvDqZk05qPly0wsaeNprVv53gz7Cm6c+dR?= =?us-ascii?Q?qpr0IJVZBSMFZvwxP53Qu4Ji0SldOunJBca4M6V481feKp3+E938dqOwb7LS?= =?us-ascii?Q?h3uhv1IKl5RMKoywvf161AxCEJvPtjfa1b4K/pXATzIV34D9E9OEukrzXLGP?= =?us-ascii?Q?ZmmHhoK/NDIbuhXomG8D8ytG1as6IMabSiDflN8gvr8rETSsbOAlx7zX7gzM?= =?us-ascii?Q?9A6+uhmbMpxeyoPNAV1Fsw3v2GQV8tby0JdXuEWKU9fqbCjxOrZON5ANpOvu?= =?us-ascii?Q?p+3ViPeQtr9QRGvAjEQ+UOjzwXtYFsi7QPhuMg9TnIThxkHJyZNyha84+ZX6?= =?us-ascii?Q?zePLnjue2zA0j8/evdtxTryhr01nvJOTgyIY5hbeJl+LLXJbw0phn4bIi5tk?= =?us-ascii?Q?9oEMJmLNeMNBF1v+M/nPAppQKeAJEd+dXlBdrsW4/AabXb6DU8rins2K8Tn9?= =?us-ascii?Q?cET39mAEG/S98GBW0pxK7NEaEbyXLyeXLhe8ntIdodJ/YyJQT22Bb098QyGr?= =?us-ascii?Q?FiPD3+HB+JcGbZwXa+1XsEr1OhA3QRWuMOfrgij6WxK1QESOVOr08KVbd4b9?= =?us-ascii?Q?N9MqlLpZKwx7rL8Md3UP+PEc+y+Jo8rlnOqdV9LY8MkCqKSXeNO9olwJeaKd?= =?us-ascii?Q?gLICD7EqCRu72aAHmMHxYuUZc8ynP37s4fQSyMC8SvNCIAN7u36txSkjzwK8?= =?us-ascii?Q?YiFHudM3/dxnt8LD0qpNQSa1k5/vyb+hur7XMpXOVRVj9MiKrZyJxQQN7mOk?= =?us-ascii?Q?FJb5LH6JzXTTariyvbGLs5/YeWw4DWXKZ6jDVrSPK7xGgSI+MQTj7F0x4Ls5?= =?us-ascii?Q?StIhv7xN/bNj9aTcTn/TTW88UYJeSqCqsCFskBzmI8fcHpzsIpv0/4mosIq6?= =?us-ascii?Q?07wKhwHM0nVaPRaXEqxiHfs9Tzj743WwKPP+I2WjV0JI8y8zPmnK35bgnXVc?= =?us-ascii?Q?6iiKmE332gEZdje5+gdWG70lLuXhCDtgOKquHHcbWFCstX7RBpzlZUrxWAwh?= =?us-ascii?Q?mu5tw483RatEKfuyIwvaz+9fc0NzZ/Bmc9pCfsN1WxPkVEza8A73ZmeOCcTc?= =?us-ascii?Q?CZDLWxygfsgbunR7q0fGSHC+zBY/9pTFI3EEUWI5/tlHgGMrIVqw/xKEW0oc?= =?us-ascii?Q?zHUdmZlHlJ066akduLp696ippTCtHzerKbTXUjQb16Gls87QfUxUvvUN3oiv?= =?us-ascii?Q?Y4cP9XHyP0HLMH6wZFwtdhNlF/Un/nvpjndigrck1dqgPsQtIjLfpO04D2DV?= =?us-ascii?Q?1OXSCxdLAgn0aBFkfOIS1hK2ceuHEhfs/ohvqusUMJVtLvhdvpLQblN1HJiP?= =?us-ascii?Q?Y5ajbQjBIS6ndW7Li1aFoslLjbqkPfxIU6T2Qj1g5oE0nAARujBPz9nCfoMr?= =?us-ascii?Q?ZBAel1r3ZAuIeerexRHmiWDW9AQLgp+EZ1P1/uiy4f2bVGijdEZDZIsBlwMO?= =?us-ascii?Q?A/8T99i+6ploaSEFHW1YRs/Lu+8oRGiU+gw/EVnbFIP+3/wVzx71HCdimZ9W?= =?us-ascii?Q?Rwtk1S6V4KsFrctBTkkbH1XQfI9gCX0RJim86T2EAlhAJ/b2iiue40isVqR4?= =?us-ascii?Q?pF+/gbK6U7e+k9SJ0sjhJ5O89q3x4hV16hcVjpjAyn3Ct4r1ZIBz8H+Dc9GF?= =?us-ascii?Q?vhsHise6JA=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 3edbfa9e-d947-4e17-ad4f-08df30c0df87 X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 04:48:25.2532 (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: hcAo/ASza4GwFCsyq7Ny2D5Z1i0A6sBbVsvYt1DEFMVbobvXSjRLJWRjQrJ71UFchnSXhlyQsaOxN0AovDKWBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYRP286MB5946 X-purgate-ID: tlsNG-16d1c6/1792730910-F540B77B-3976F16E/0/0 X-purgate-type: clean X-purgate-size: 4817 Hello! This RFC introduces a dynamic function tracing feature which I proposed at Xen Summit in September: https://xensummit2026.sched.com/event/2RDr8/improving-xen-traceability-more-than-just-livepatching The goal is to improve debugging/tracing by making Xen possible to attach callbacks to its functions. This series implements the infrastructure for attaching callbacks using Livepatch on x86 and arm64, as well as HypFS interface for controlling tracers. It is inspired by Linux ftrace: https://docs.kernel.org/trace/ftrace.html I appreciate any feedback on the implementation, as well as your experience trying it out. Thanks! # Implementation The implementation follows Linux ftrace's approach of reserving function entries that can be later patched for tracing at runtime. Those entries get patched with a branch instruction to a trampoline, which preserves registers before calling function callbacks. Livepatch is used for patching those reserved function entries. Since Livepatch operates on struct payload, it prepares a dedicated payload which can be used by tracers for requesting livepatch of the target function. Please see patch 2 and 3 for the detail. New tracers can be added by defining a struct tracer and registering it during Xen initialization. Each tracer can provide a function callback for tracing and optional callbacks for managing its state and output through the HypFS interface under /tracing. Please see patch 4 for an example implementation. # Configuration In addition to Livepatch and HypFS: CONFIG_LIVEPATCH=y CONFIG_HYPFS=y Enable the following configs: CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY=y or CONFIG_X86_PATCHABLE_FUNCTION_ENTRY=y CONFIG_LIVEPATCH_TRACER=y # Usage The interface is exposed HypFS /tracing directory. It follows the naming and usage of Linux ftrace: https://www.kernel.org/doc/html/latest/trace/ftrace.html#the-file-system available_tracers List registered tracers. current_tracer Read or select the active tracer. available_functions List functions available for tracing. set_function_filter Read, select, or clear the target function. tracing_on Enable or disable recording. trace Read or clear recorded output. ## Example // List the tracable functions. xenhypfs cat /tracing/available_functions // List the available tracers. Currently "nop" and "function" tracers are available. xenhypfs cat /tracing/available_tracers // Select the function to trace. xenhypfs write /tracing/set_function_filter xen_extra_version // Select the tracer. xenhypfs write /tracing/current_tracer function // Record calls to the selected function. xenhypfs write /tracing/tracing_on 1 // Call xen_extra_version(). cat /sys/hypervisor/version/extra // Stop recording and read the output. xenhypfs write /tracing/tracing_on 0 xenhypfs cat /tracing/trace // Reset. xenhypfs write /tracing/set_function_filter "" xenhypfs write /tracing/current_tracer nop xenhypfs write /tracing/trace "" Sincerely, Ryo Takakura Ryo Takakura (5): xen/arm64: livepatch: enable attaching callbacks xen/livepatch: Allow tracers to schedule livepatch xen/tracing: prepare a livepatch payload and its controling interface xen/tracing: Add a function tracer xen/x86: livepatch: enable attaching callbacks xen/arch/arm/Kconfig | 13 + xen/arch/arm/arch.mk | 3 + xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/insn.c | 5 + xen/arch/arm/arm64/livepatch-asm.S | 68 +++ xen/arch/arm/arm64/livepatch.c | 39 ++ xen/arch/arm/include/asm/arm64/insn.h | 1 + xen/arch/arm/xen.lds.S | 5 + xen/arch/x86/Kconfig | 13 + xen/arch/x86/Makefile | 1 + xen/arch/x86/arch.mk | 3 + xen/arch/x86/livepatch-asm.S | 60 +++ xen/arch/x86/livepatch.c | 33 ++ xen/arch/x86/xen.lds.S | 5 + xen/common/Kconfig | 12 + xen/common/Makefile | 6 + xen/common/function_trace.c | 274 ++++++++++ xen/common/hypfs_trace.c | 743 ++++++++++++++++++++++++++ xen/common/livepatch.c | 137 ++++- xen/include/xen/hypfs_trace.h | 42 ++ xen/include/xen/livepatch.h | 14 + xen/include/xen/livepatch_payload.h | 7 +- 22 files changed, 1478 insertions(+), 7 deletions(-) create mode 100644 xen/arch/arm/arm64/livepatch-asm.S create mode 100644 xen/arch/x86/livepatch-asm.S create mode 100644 xen/common/function_trace.c create mode 100644 xen/common/hypfs_trace.c create mode 100644 xen/include/xen/hypfs_trace.h -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458820.1670853 (Exim 4.92) (envelope-from ) id 1xK7G7-0001rb-EZ; Fri, 23 Oct 2026 04:52:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458820.1670853; Fri, 23 Oct 2026 04:52: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 1xK7G7-0001rU-Bz; Fri, 23 Oct 2026 04:52:03 +0000 Received: by outflank-mailman (input) for mailman id 1458820; Fri, 23 Oct 2026 04:52:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7G5-0001r3-Ht for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7G4-00FSb5-Ij for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:00 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7e7-e002-0a2a0a5209dd-0a2a4506e104-10 for ; Fri, 23 Oct 2026 06:52:00 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adae7ee-195a-0a2a45060019-aceafc1fa0c6-3 for ; Fri, 23 Oct 2026 06:52:00 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2411840A17; Fri, 23 Oct 2026 04:51:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48EF11F01825; Fri, 23 Oct 2026 04:51: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731118; bh=l5UCn3s3YyxcyE6vweegr4A1rPRcjt6h9F7KPsMd5KY=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=g9IF7uFF9+WPeewAagqf7C9jK+UL4Yc9xwbzrV2wTgTEZHIsI3StVz8RYNbRqLD1y ZT/z/gtLR8fmAUx8n1LLfM+C9U2C0s0iAoOqTE2eIrLCwS710pc4j+WCR7k6JpEXBi jybOBH0KSK6ReliEUHAaEcrL7hDF2YXHjUI3b52ci6q/qjWqiykJtkMTiqDnBskIDo tq1A+WGsMnhTQ3RmAr3ikdjzDWGycUSMt0zu3QzuiWBdQVfcurM1AuhUjja3xFQAFw abrc4XwH6LfzBGCKAbUY92A1FlhoYh3+SzUJX5SgFL6HeeykSWmDYZpB25LXRyy0ae vW8LVJ3g00YTg== Subject: Re: [PATCH net-next 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:51:56 +0000 Message-ID: <179273111683.3134.7255247218847744918@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-1-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-1-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Medium Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-16d1c6/1792731120-F7ACA77B-1AF79BD9/0/0 X-purgate-type: clean X-purgate-size: 5299 Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider. Critical: 0 · High: 0 · Medium: 1 · Low: 1 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [Medium] Missing Fixes: and Cc: stable tags on a data-integrity fix. - [Low] The new comment in skb_copy_and_csum_dev() reads: "On failure the rest of @to is zeroed; leave the checksum alone so the frame goes out… -- net: skbuff: make skb_copy_and_csum_bits() report unreadable frags skb_copy_and_csum_bits() now returns 0 or -EFAULT, hands the checksum back through a pointer, and is marked __must_check. On error, the callers in skb_segment(), the ICMP code, the IP append paths, sunvnet and sunrpc take the failure paths they already have. skb_copy_and_csum_dev() returns early without storing a checksum. With this change, software GSO of a devmem TCP skb fails instead of silently replacing the payload with zeroes. Link: https://lore.kernel.org/all/179148235783.434549.14322374227477832817@kernel.org/ > Link: https://lore.kernel.org/all/179148235783.434549.14322374227477832817@kernel.org/ > Suggested-by: Mina Almasry > Reviewed-by: Mina Almasry > Assisted-by: LLM > Signed-off-by: Josef Bacik [Severity: Medium] This fixes the silent payload replacement in the !sg && !csum branch of skb_segment(), but there is no Fixes: or Cc: stable tag. The commit message says commit ab9414ed70bd ("net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()") is what made the replacement silent. That commit carries: Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Cc: stable@vger.kernel.org Could stable trees take ab9414ed70bd without this patch? Devmem TX would then send a zeroed payload under a valid TCP checksum, and the peer would accept it. Other patches in this series carry Fixes: tags, for example "net: skbuff: reject a negative length in skb_copy_and_csum_bits()" and "net: skbuff: check csum_start against len in skb_copy_and_csum_dev()". Should this one also name ab9414ed70bd (or 65249feb6b3d) in a Fixes: tag and Cc stable, so that both changes are backported together? > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 93c2f440b9ec..a2b52a5a61a9 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c [ ... ] > @@ -4006,9 +4025,13 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to) > skb_copy_from_linear_data(skb, to, csstart); > > csum = 0; > - if (csstart != skb->len) > - csum = skb_copy_and_csum_bits(skb, csstart, to + csstart, > - skb->len - csstart); > + /* On failure the rest of @to is zeroed; leave the checksum alone so > + * the frame goes out with a bad one. > + */ > + if (csstart != skb->len && > + skb_copy_and_csum_bits(skb, csstart, to + csstart, > + skb->len - csstart, &csum)) > + return; [Severity: Low] Does this early return actually make the frame go out with a bad checksum? It skips the csum_fold() store, but nothing marks the checksum as invalid. The sanity check earlier in skb_copy_and_csum_dev() only bounds csstart by skb_headlen(): if (unlikely(csstart < 0 || csstart > skb_headlen(skb) || (skb->ip_summed == CHECKSUM_PARTIAL && csstart + skb->csum_offset + sizeof(__sum16) > skb->len))) { For CHECKSUM_PARTIAL, the field at csstart + csum_offset can therefore sit past the linear area. That puts it inside the region that skb_copy_and_csum_bits() zero-fills on failure: if (!skb_frags_readable(skb)) { /* Don't hand the caller a buffer with stale bytes in it. */ if (len > 0) memset(to, 0, len); return -EFAULT; } For UDP over IPv4, a checksum of 0x0000 means "no checksum". Wouldn't the receiver then accept the zeroed payload? The same applies to a CHECKSUM_NONE UDP skb sent without a checksum. The headers are copied intact, only the payload is zeroed, and nothing marks the frame as bad. The commit message makes the same claim: skb_copy_and_csum_dev() can't return an error, so it leaves the checksum alone and the frame goes out with a bad one. None of the current callers (ep93xx_eth, ec_bhf, ksz884x, 8139too, sc92031, via-rhine) sets netmem_tx. validate_xmit_unreadable_skb() therefore drops unreadable skbs before they reach these drivers, and the remaining failure case needs an skb whose lengths are inconsistent. Should the comment and the commit message be narrowed? Alternatively, this path could store a non-zero value at csstuff that is known not to match, for CHECKSUM_PARTIAL. The code is unchanged at the end of the series. > > if (skb->ip_summed == CHECKSUM_PARTIAL) { > long csstuff = csstart + skb->csum_offset; [ ... ] -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458821.1670856 (Exim 4.92) (envelope-from ) id 1xK7G7-0001ty-KR; Fri, 23 Oct 2026 04:52:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458821.1670856; Fri, 23 Oct 2026 04:52: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 1xK7G7-0001tZ-HT; Fri, 23 Oct 2026 04:52:03 +0000 Received: by outflank-mailman (input) for mailman id 1458821; Fri, 23 Oct 2026 04:52:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7G6-0001rB-9W for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7G5-00FSb5-MN for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:01 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7b8-e002-0a2a0a5209dd-0a2a4503e38a-48 for ; Fri, 23 Oct 2026 06:52:01 +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 6adae7f0-fae8-0a2a45030019-ac6904feb00a-3 for ; Fri, 23 Oct 2026 06:52:01 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 9D420600E2; Fri, 23 Oct 2026 04:51:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 956E51F01828; Fri, 23 Oct 2026 04:51: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731119; bh=tCmxTkBjLaIflZ6vc/WgmRL/W84MvLgumRnoI+JCkrM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=MyIzM/ThgfrEK0Tv/sB4VPSWUI8xCV5TBTMDrtUBNDSPFCoCaOC6dEJHOPtxJOVLf hPNa0L2Ezix2vvWGnP0u3T2/3ECMTvYm+enl+QExJ5Ek2PipD0e9MNu4D47tv9DsM3 shL/DSZmrOvTfzG69ud2CCLksfL9j5uBXg7sgsO2ZAyvbOBcey5+YdVea9Czs85uBD Hn71yae9pBxNA51ARczpsKByetm4SF4YMpOSkYPGqtcaF08uVz6lnpIOqme6ZuFetY kJMyBGyym/gDqIuep5PFtNCvXxm0OqiE9FK2lEGxq/1OvTaf8Vkgq9cwUbOfPpBVNG MBgowJLkBDbEw== Subject: Re: [PATCH net-next 02/15] net: skbuff: add skb_checksum_full() that reports failure From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:51:58 +0000 Message-ID: <179273111819.3134.1366212706664836361@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-2-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-2-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Medium Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-33051d/1792731121-77EC24E9-C7059AC1/0/0 X-purgate-type: clean X-purgate-size: 6723 Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider. Critical: 0 · High: 0 · Medium: 1 · Low: 1 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [Medium] The commit message says the skb_checksum() wrapper (net/core/skbuff.c, lines 3657-3664) "behaves as before for the… - [Low] The new kernel-doc for skb_checksum_full() (net/core/skbuff.c, lines 3555-3557) says it returns -EFAULT if "@skb has unreadable frags… -- net: skbuff: add skb_checksum_full() that reports failure This adds skb_checksum_full(). It returns -EFAULT for unreadable frags or a range past the end of the skb, and -EINVAL for a negative length, instead of returning a 0 checksum. skb_checksum() becomes a wrapper around it and keeps the old return-0-on-failure behaviour for callers that have not been converted yet. > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index a2b52a5a61a9..061c61422a38 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3545,12 +3545,31 @@ int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len) > EXPORT_SYMBOL(skb_store_bits); > > /* Checksum skb data. */ > -__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > +/** > + * skb_checksum_full - checksum a range of an skb > + * @skb: buffer to checksum > + * @offset: offset in @skb to start at > + * @len: number of bytes to checksum > + * @csump: the sum to add to; on success the range's sum is added to it > + * > + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb > + * has unreadable frags in the range or runs out before @len does. On > + * failure *@csump is not changed. > + */ [ ... ] > @@ -3558,13 +3577,13 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > copy = len; > csum = csum_partial(skb->data + offset, copy, csum); > if ((len -= copy) == 0) > - return csum; > + goto out; > offset += copy; > pos = copy; > } > > - if (WARN_ON_ONCE(!skb_frags_readable(skb))) > - return 0; > + if (!skb_frags_readable(skb)) > + return -EFAULT; [Severity: Low] This isn't a bug, but does the new kernel-doc match this check? The doc says -EFAULT is returned when @skb "has unreadable frags in the range". skb_frags_readable() only tests the skb-wide skb->unreadable bit, though, and this check runs before working out which frags or frag_list members the range touches. That leads to two cases: - On an unreadable skb, a zero-length range at offset >= skb_headlen() returns -EFAULT even though no bytes were requested. - A range that lies entirely in readable frag_list members, past the head's own unreadable frags, is rejected without those members being visited. The old skb_checksum() behaved the same way here. None of the callers converted later in the series seem to pass such ranges. Should the kernel-doc describe the skb-wide check? Or should the check move so it only applies when a page frag is actually in the range? [ ... ] > @@ -3606,14 +3625,17 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > > end = start + frag_iter->len; > if ((copy = end - offset) > 0) { > - __wsum csum2; > + __wsum csum2 = 0; > + > if (copy > len) > copy = len; > - csum2 = skb_checksum(frag_iter, offset - start, copy, > - 0); > + err = skb_checksum_full(frag_iter, offset - start, copy, > + &csum2); > + if (err) > + return err; [ ... ] > @@ -3621,9 +3643,23 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) [ ... ] > +/* skb_checksum() has no way to report failure, so it returns 0, which is a > + * valid checksum. Use skb_checksum_full() in new code. > + */ > +__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > +{ > + if (unlikely(skb_checksum_full(skb, offset, len, &csum))) { > + WARN_ON_ONCE(!skb_frags_readable(skb)); > + return 0; > + } [Severity: Medium] The commit message says the wrapper "behaves as before for the callers that haven't been converted: it returns 0 on failure and warns once if that was because of unreadable frags". Does that hold when the unreadable frags are in a frag_list member and not in the top-level skb? Before this patch, the frag_list loop recursed through skb_checksum(). An unreadable member hit the WARN_ON_ONCE() and returned 0. The parent then folded that 0 in with csum_block_add() and returned the partial sum of the readable parts. Now the member returns -EFAULT from skb_checksum_full() without a warning. The frag_list loop passes it straight up, and the wrapper only checks the outer skb: WARN_ON_ONCE(!skb_frags_readable(skb)); If the head is readable and only a member is unreadable, the warning is lost. Unconverted callers also get 0 for the whole range instead of the old partial sum. At this revision __skb_checksum_complete() still does: csum = skb_checksum(skb, 0, skb->len, 0); sum = csum_fold(csum_add(skb->csum, csum)); Could this pass validation whenever the pseudo-header sum folds to 0xffff, and then set skb->csum to 0 and csum_valid to 1? The later patch "net: skbuff: fail checksum validation when the skb can't be checksummed" converts that function. Other skb_checksum() callers stay unconverted at the end of the series and still see the changed value, for example net/netfilter/utils.c, nf_nat_proto.c, ipvs, icmp.c, ipmr.c, udp.c, mptcp and some drivers. The wrapper itself also never starts warning for nested failures. Separately, if the top-level skb is unreadable and the failure is the new -EINVAL for a negative @len, won't this WARN_ON_ONCE() blame unreadable frags for it? This mixed layout looks structurally possible. skb_gro_receive() links skbs onto frag_list without comparing their unreadable flags, and tcp_gro_receive() doesn't compare them either. It hasn't been shown to happen in practice. Should the wrapper warn on nested -EFAULT as well, or should the commit message be adjusted to describe the new behaviour? > return csum; > } > EXPORT_SYMBOL(skb_checksum); -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458822.1670870 (Exim 4.92) (envelope-from ) id 1xK7G8-0002Gx-Ry; Fri, 23 Oct 2026 04:52:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458822.1670870; Fri, 23 Oct 2026 04:52: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 1xK7G8-0002Gq-Ou; Fri, 23 Oct 2026 04:52:04 +0000 Received: by outflank-mailman (input) for mailman id 1458822; Fri, 23 Oct 2026 04:52:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7G7-0001rh-K6 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7G7-00FSfm-0U for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:03 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7b7-2eae-0a2a0a5409dd-0a2a450ce014-18 for ; Fri, 23 Oct 2026 06:52:02 +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 6adae7f1-f479-0a2a450c0019-aceafc1fc176-3 for ; Fri, 23 Oct 2026 06:52:02 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 1CE7440A17; Fri, 23 Oct 2026 04:52:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA1BB1F01825; Fri, 23 Oct 2026 04:51: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731121; bh=CsbqRFbRE+Tnrux6F3AjM6HXluABeMqzeEaYlLw6WYc=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=c3jfzhSqbD7sY+a+qNiZLDCDTwkahCRkVX3Bx9J17yBROTQfZ5guxDyoStV2azodH jNzKVKGtL8ZctkD3SUsnCZBM07+Ahfw8OsR/7puEJ5KFVmOqyuv4Iixi/0q7ut/vxY 02rjvTwFPn0pfopaWIJtCXBRB28d6ANN0H+6tFLi9DcIGAK3Oir4z5mXv5roQYRhlW b3AlCqQS7vBy00lEDbjkGWE/DpovU2idnTh53CoeiXOPshYz2uvzJPbVzqCTxOHwnb yU1wahoK+n0SpSm4HHp24AP6vrHv3zYF4RdSWwwK0RKOW2r486ekwy4u92zqPN2Gtv u1fT9+XDxfNGA== Subject: Re: [PATCH net-next 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:51:59 +0000 Message-ID: <179273111951.3134.3452028799437573017@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-3-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-3-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: High Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-d25034/1792731122-774D7A5B-1A44CD6C/0/0 X-purgate-type: clean X-purgate-size: 7577 Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider. Critical: 0 · High: 2 · Medium: 1 · Low: 1 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [High] The fix does not hold when conntrack checks checksums first. - [High] __skb_gro_checksum_complete() (net/core/gro.c:794-813) has the same false-accept defect this commit fixes in… - [Medium] The Fixes: tag is incomplete for stable backporting. - [Low] The block comment above __skb_checksum_complete() (net/core/skbuff.c:3891-3893) still says 'The new checksum is stored… -- net: skbuff: fail checksum validation when the skb can't be checksummed This commit switches __skb_checksum_complete() and __skb_checksum_complete_head() to skb_checksum_full(). When the skb data can't be checksummed, they now report a bad checksum. On that failure path csum_valid is cleared, and skb->csum and ip_summed are left alone. Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ > Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") [Severity: Medium] Is this Fixes: tag complete for stable backports? The likely remote trigger for __skb_checksum_complete() is unreadable devmem frags. skb_checksum() has returned 0 for those since 65249feb6b3d ("net: add support for skbs with unreadable frags"): if (WARN_ON_ONCE(!skb_frags_readable(skb))) return 0; The 20ddd0fd2fcd commit message also says skb_checksum() returns 0 "as they already do for unreadable frags". __skb_checksum_complete() checksums from offset 0 to skb->len. It can only run past the end if the skb lengths are inconsistent. With only Fixes: 20ddd0fd2fcd, stable trees from 6.12 onward that have 65249feb6b3d but not 20ddd0fd2fcd would not pick this up. Should 65249feb6b3d be listed as well? This patch also depends on the previous patch in the series ("net: skbuff: add skb_checksum_full() that reports failure"). Nothing in the tags records that dependency. > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 061c61422a38..40d2dd20d47d 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c [ ... ] > @@ -3886,10 +3894,17 @@ EXPORT_SYMBOL(__skb_checksum_complete_head); > */ > __sum16 __skb_checksum_complete(struct sk_buff *skb) > { > - __wsum csum; > + __wsum csum = 0; > __sum16 sum; > > - csum = skb_checksum(skb, 0, skb->len, 0); > + /* If the data can't be checksummed it can't be valid either. Leave > + * skb->csum alone, it's not a full packet checksum. > + */ [Severity: Low] The block comment above __skb_checksum_complete() still says: * zero. The new checksum is stored back into skb->csum unless the skb is * shared. On the new failure path, skb->csum is not stored back even for unshared skbs. That contradicts the new inline comment. skb_remcsum_process() ignores the return value of __skb_checksum_complete() and then uses skb->csum, so it relies on this post-condition. The return-value comments for __skb_checksum_validate_complete() and __skb_checksum_validate() in include/linux/skbuff.h also say: * non-zero: value of invalid checksum The new path returns the constant (__force __sum16)1 rather than a computed value. Should both comments be updated? > + if (skb_checksum_full(skb, 0, skb->len, &csum)) { > + if (!skb_shared(skb)) > + skb->csum_valid = 0; > + return (__force __sum16)1; > + } [Severity: High] Can leaving ip_summed set to CHECKSUM_COMPLETE here let a later validator accept the packet anyway? Callers have already replaced skb->csum with the pseudo-header sum before calling this function. nf_ip_checksum() does this when the hardware CHECKSUM_COMPLETE sum fails to validate: net/netfilter/utils.c:nf_ip_checksum() { ... case CHECKSUM_NONE: ... skb->csum = csum_tcpudp_nofold(iph->saddr, iph->daddr, skb->len - dataoff, protocol, 0); csum = __skb_checksum_complete(skb); ... } For an skb with unreadable frags, skb_checksum_full() fails. The skb then leaves this function with ip_summed == CHECKSUM_COMPLETE and skb->csum == psum. Conntrack does not drop on a bad checksum: nf_conntrack_in() nf_conntrack_tcp_packet() tcp_error() -> true return -NF_ACCEPT ret = -ret; -> NF_ACCEPT The packet then reaches tcp_v4_rcv()->skb_checksum_init()->__skb_checksum_validate_complete(): if (skb->ip_summed == CHECKSUM_COMPLETE) { if (!csum_fold(csum_add(psum, skb->csum))) { skb->csum_valid = 1; return 0; inet_compute_pseudo() produces the same psum, so this computes csum_fold(psum + psum). That is 0 exactly when psum folds to 0xffff, which is the condition the commit message says it closes. The sender controls it through the packet length or source address. Conntrack checksumming is on by default (nf_conntrack_checksum = 1). The commit message says: report a packet that can't be checksummed as having a bad checksum, so callers drop it the way they drop any other bad checksum. This caller doesn't drop it. Would it make sense to move ip_summed off CHECKSUM_COMPLETE (for example to CHECKSUM_NONE) on this path when the skb is not shared? That way later validators can't trust the stale pseudo-header sum. The series leaves this code as it is. > > sum = csum_fold(csum_add(skb->csum, csum)); > /* This check is inverted, because we already knew the hardware [Severity: High] Should __skb_gro_checksum_complete() in net/core/gro.c be converted too? It has the same false-accept pattern, its comment points to the comments in __skb_checksum_complete(), and the series doesn't change it: net/core/gro.c:__skb_gro_checksum_complete() { ... wsum = skb_checksum(skb, skb_gro_offset(skb), skb_gro_len(skb), 0); /* NAPI_GRO_CB(skb)->csum holds pseudo checksum */ sum = csum_fold(csum_add(NAPI_GRO_CB(skb)->csum, wsum)); ... NAPI_GRO_CB(skb)->csum = wsum; NAPI_GRO_CB(skb)->csum_valid = 1; ... } For a devmem skb with unreadable frags, skb_checksum() fires WARN_ON_ONCE(!skb_frags_readable(skb)) and returns 0. sum is then csum_fold(psum), which is 0 when psum folds to 0xffff. The path is: tcp4_gro_receive() skb_gro_checksum_validate() __skb_gro_checksum_validate_complete() __skb_gro_checksum_complete() skb_gro_incr_csum_unnecessary() For CHECKSUM_NONE skbs this ends in CHECKSUM_UNNECESSARY. For merged CHECKSUM_COMPLETE skbs, tcp_gro_complete() sets CHECKSUM_PARTIAL. In both cases TCP never validates the payload again, and GRO accepts the packet before the helpers changed here ever run. Every bad-checksum packet on such a queue also hits the WARN_ON_ONCE() from softirq context, which a remote sender can trigger. The WARN itself comes from 65249feb6b3d. The previous patch, "net: skbuff: add skb_checksum_full() that reports failure", says the following patches convert the core users. This net/core user isn't converted anywhere in the series. -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458823.1670880 (Exim 4.92) (envelope-from ) id 1xK7GA-0002Up-1O; Fri, 23 Oct 2026 04:52:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458823.1670880; Fri, 23 Oct 2026 04: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 1xK7G9-0002Ug-Ux; Fri, 23 Oct 2026 04:52:05 +0000 Received: by outflank-mailman (input) for mailman id 1458823; Fri, 23 Oct 2026 04:52:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7G9-0002H7-2S for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7G8-00FSb5-E4 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:04 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7e7-e002-0a2a0a5209dd-0a2a4506e104-14 for ; Fri, 23 Oct 2026 06:52:04 +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 6adae7f3-195a-0a2a45060019-ac6904fec71e-3 for ; Fri, 23 Oct 2026 06:52:04 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id D86CB600E2; Fri, 23 Oct 2026 04:52:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A92E71F01825; Fri, 23 Oct 2026 04:52: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="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731122; bh=BoB/A1sIi/INkgoVC9AAFNKr7YKhQUbQ+JtYOmccKaE=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ha4V+Px40uunuItMDirEmvN1G4w/6nhYdHlSNLpf8paKd/rUtTd+wHcsWbIWeh3GD LKrDwytd64GaIIfsmbD/j/9gf7BHplAqBgp3l/kTDVED007liwV2WGOermBWF5qfcO tLGgQLX1Y6A8QeXHVR2/tSCuONL96UW/Bjn/xiiVoz4Y4Kd/gnKCPhA0T96Io5fZu5 KqK5I2Zbhb6R/KGZKRp/We9eIpPMEBdMj1glD5VbZUY7eRcxsXRAOmp8cPanCmDJsJ SErKFtysFh+XDSmW/y5rDCe2OyDG+E5MBzBUz2TRTWAg+64uso+iw/+/rBv+IQDT7j N/2qfuwKE/wyg== Subject: Re: [PATCH net-next 04/15] net: skbuff: fail segmentation when a segment can't be checksummed From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:01 +0000 Message-ID: <179273112116.3134.13075947496257634766@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-4-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-4-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-16d1c6/1792731124-FE87577B-50A78BD3/0/0 X-purgate-type: clean X-purgate-size: 2518 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The commit fixes a real, user-visible TX bug but has no Fixes: tag (and no Cc: stable). -- net: skbuff: fail segmentation when a segment can't be checksummed This patch changes the sg && !csum software checksum path in skb_segment() to use skb_checksum_full(). The segmentation now fails with -EFAULT when a segment can't be checksummed. This covers devmem TCP skbs whose payload is in unreadable frags: skb_checksum() used to warn and return 0, so the TCP checksum didn't cover the payload. Link: https://lore.kernel.org/all/20261009-b4-skb-segment-nosg-unreadable-v1-1-7e2334a55fe8@toxicpanda.com/ > Found by the Sashiko AI review of an earlier fix for the same path with > SG off. > > Link: https://lore.kernel.org/all/20261009-b4-skb-segment-nosg-unreadable-v1-1-7e2334a55fe8@toxicpanda.com/ > Assisted-by: LLM > Signed-off-by: Josef Bacik [Severity: Low] Should this have a Fixes: tag, and possibly Cc: stable? Before this patch, the perform_csum_check branch of skb_segment() called skb_checksum() on segments that share the devmem skb's net_iov frags. zerocopy_fill_skb_from_devmem() in net/core/datagram.c never sets SKBFL_SHARED_FRAG, so the __skb_linearize() fallback is skipped and __skb_checksum() ends up here: if (WARN_ON_ONCE(!skb_frags_readable(skb))) return 0; That WARN is fatal with panic_on_warn. tcp_gso_segment() then writes a TCP checksum that doesn't cover the payload that goes out. This path became reachable when unreadable-frag TX skbs were added by: bd61848900bf ("net: devmem: Implement TX path") That looks like the right Fixes: target. Another patch in this series, "net: skbuff: fail checksum validation when the skb can't be checksummed", does carry a Fixes: tag. Without one here, the stable tooling won't pick up this fix. This patch also calls skb_checksum_full(), which is added by the earlier patch in this series, "net: skbuff: add skb_checksum_full() that reports failure". Could the commit message mention that dependency, so a backport takes both patches? -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458824.1670889 (Exim 4.92) (envelope-from ) id 1xK7GB-0002jM-Da; Fri, 23 Oct 2026 04:52:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458824.1670889; Fri, 23 Oct 2026 04:52: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 1xK7GB-0002jA-AA; Fri, 23 Oct 2026 04:52:07 +0000 Received: by outflank-mailman (input) for mailman id 1458824; Fri, 23 Oct 2026 04:52:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GA-0002YC-GA for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7G9-00FSfm-TN for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:05 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7e7-2eae-0a2a0a5409dd-0a2a4504ad1c-30 for ; Fri, 23 Oct 2026 06:52:05 +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 6adae7f4-b57f-0a2a45040019-ac6904fecc04-3 for ; Fri, 23 Oct 2026 06:52:05 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 5523E60211; Fri, 23 Oct 2026 04:52:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38EB01F01825; Fri, 23 Oct 2026 04:52: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731124; bh=0Z5cdUqpy3PAiZSjrshYDDPeo62NSWIKJChJ5XHEZtQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=gtywuCCzViksVx/fLRMNPaRhC+7Azt4LGhzFIUaIxUHgLmh6qAKYAlQ+dFo6TAnv0 CSMr8aTTkOHRXBDrDHPQP8OSHGYrP4NYaRcDoxnsihu2bqlpU5SdOPEvbihGUHvErn FGF47q6lb5ltvXRQWaAf/MUePuUhCEAbIxsGpk1n4YWg5zdqR3V7k4dJWQF/aLBd7f vtTtMFFQZphA4dC7SmgNUvriSY/sRYt7oVNXd43t/3IoJpSbIf/gP2VJ04Tqe8uKeT ToogJwAGheZySucUiE6FOLvKzglv13120NxEjPmcQQnh0uSJx7jet0MrYjUh6ja4sc KowqOxeCzFy2Q== Subject: Re: [PATCH net-next 05/15] net: skbuff: fail pskb_trim_rcsum() when it can't checksum the tail From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:02 +0000 Message-ID: <179273112276.3134.5794646357730297826@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-5-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-5-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-ebf023/1792731125-53EC6B50-9586D410/0/0 X-purgate-type: clean X-purgate-size: 5055 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The commit fixes a real CHECKSUM_COMPLETE corruption in pskb_trim_rcsum_complete() (net/core/skbuff.c) but has no Fixes: tag,… - [Low] In pskb_trim_rcsum_complete() (net/core/skbuff.c), the readable- head branch now returns skb_checksum_full()'s -EFAULT unconditionally. -- net: skbuff: fail pskb_trim_rcsum() when it can't checksum the tail This patch changes pskb_trim_rcsum_complete() to use skb_checksum_full() instead of skb_checksum(). If the checksum of the trimmed tail can't be computed, the error is now returned and callers drop the packet. Before this, 0 was subtracted from skb->csum. > pskb_trim_rcsum() can already fail, and its callers drop the packet > when it does. Use skb_checksum_full() and return its error. [Severity: Low] This isn't a bug, but should this commit carry a Fixes: tag? Before this patch, the readable-head branch of pskb_trim_rcsum_complete() only checked the top-level skb->unreadable bit. If the trimmed tail reached an unreadable frag_list member, skb->csum was left covering the trimmed bytes. That layout looks reachable. inet_frag_reasm_finish() keeps CHECKSUM_COMPLETE, and it links fragments onto frag_list when skb_try_coalesce() refuses them: net/core/skbuff.c:skb_try_coalesce() { ... if (skb_frags_readable(from) != skb_frags_readable(to)) return false; ... } The gap seems to go back to 65249feb6b3d ("net: add support for skbs with unreadable frags"). 2e357f002c61 ("net: Avoid checksumming unreadable skb tail on trim") only covered the top-level case. The commit message also mentions the "past the end of the skb" case. That case was a BUG() until 20ddd0fd2fcd turned it into a silent 0. Two sibling patches in this series fix the same consequence of 20ddd0fd2fcd, and both carry Fixes: 20ddd0fd2fcd: "net: skbuff: fail checksum validation when the skb can't be checksummed" "net: skbuff: add skb_crc32c_full() that reports failure" The commit message also doesn't say that this patch depends on the earlier "net: skbuff: add skb_checksum_full() that reports failure" patch. Could that dependency be noted for anyone backporting this? > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 88ed2dd99dc0..de433d452939 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -2829,9 +2829,13 @@ static int pskb_trim_rcsum_complete(struct sk_buff *skb, unsigned int len) > int delta = skb->len - len; > > if (skb_frags_readable(skb)) { > - skb->csum = csum_block_sub(skb->csum, > - skb_checksum(skb, len, delta, 0), > - len); > + __wsum csum = 0; > + int err; > + > + err = skb_checksum_full(skb, len, delta, &csum); > + if (err) > + return err; [Severity: Low] Should this fall back to CHECKSUM_NONE when only the trimmed bytes are unreadable? Take a head with skb->unreadable clear, where the tail [len, skb->len) lies entirely in an unreadable frag_list member. skb_checksum_full() recurses into that member and returns -EFAULT, and the packet is dropped. pskb_trim_rcsum_complete() already handles the case where the trimmed bytes are unreadable but the rest can be checksummed. It only does so when the top-level bit is set: if (len > skb_headlen(skb)) return -EFAULT; /* The trimmed bytes are unreadable, but the remaining packet can be * checksummed by software after trimming. */ skb->ip_summed = CHECKSUM_NONE; return 0; So the same data layout is either kept or dropped, depending on whether the unreadable flag is on the head or on a frag_list member. One way to get there is IP reassembly on a devmem/zcrx queue. If a readable first fragment is followed by an unreadable one, inet_frag_reasm_finish() produces a readable CHECKSUM_COMPLETE head with an unreadable frag_list member. When the UDP length is shorter than the datagram, the call chain is: __udp4_lib_rcv() pskb_trim_rcsum(skb, ulen) pskb_trim_rcsum_slow() pskb_trim_rcsum_complete() skb_checksum_full() -> -EFAULT UDP then drops the packet through short_packet. ___pskb_trim() would have dropped that member and cleared the unreadable bit: if (!skb_shinfo(skb)->nr_frags && !skb_has_frag_list(skb)) skb->unreadable = 0; That would leave the trimmed skb fully readable, so software could checksum it. Before this patch the packet was accepted. __skb_checksum_complete() recomputed the checksum over the trimmed skb and reported netdev_rx_csum_fault(). Would falling back to CHECKSUM_NONE when [0, len) is readable avoid both the drop and the old splat? [ ... ] -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458825.1670898 (Exim 4.92) (envelope-from ) id 1xK7GD-0002zr-Lj; Fri, 23 Oct 2026 04:52:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458825.1670898; Fri, 23 Oct 2026 04: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 1xK7GD-0002zg-H4; Fri, 23 Oct 2026 04:52:09 +0000 Received: by outflank-mailman (input) for mailman id 1458825; Fri, 23 Oct 2026 04:52:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GB-0002ok-U8 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7GB-008liq-Ar for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:07 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7df-8faa-0a2a0a5109dd-0a2a4509e050-26 for ; Fri, 23 Oct 2026 06:52:07 +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 6adae7f5-be1a-0a2a45090019-aceafc1fd5e8-3 for ; Fri, 23 Oct 2026 06:52:07 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 74513436D5; Fri, 23 Oct 2026 04:52:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A37D1F031E0; Fri, 23 Oct 2026 04:52: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731125; bh=Qv0jgGSSzQcSOMwhms6D75hZ9LTOezwa31oORyt9eG8=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=nFTbwa1UCVR6+1/TZhGahifx1EcAxAH7crNt6EWCgyjm/P4MwnTSAF1vJJEjYTY7c /qEU/aZte7oJ7YXIdQHKeEPzdN31vzLP6tckm1Aj3qZ+CcUuhDEiyH12H4smFGnl+W JNcpDCV2FCm4/0Qdy/YkjoZvwRue39W5lqTDUC+oFhCC4EScDxzvox5UD0qB65os6H TOGdqljus19TsLQQrz/TbVAswKSX3BtUkGS1pwqeOVYUZ6rTS+S6JVuO8LDAhkBrUL pKC5tDq19fXaSnxFVhq5Dj3aKjDqgscVrxve8w5aoPn7NcdYbxruoNlGYxyJp4r/TL DA2YJwSkr40DA== Subject: Re: [PATCH net-next 06/15] net: skbuff: add skb_crc32c_full() that reports failure From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:04 +0000 Message-ID: <179273112422.3134.14612188940817308301@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-6-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-6-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-bad1c0/1792731127-3B6D2034-FB0D8599/0/0 X-purgate-type: clean X-purgate-size: 5113 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The new kernel-doc for skb_crc32c_full() (net/core/skbuff.c, above line 3810) says it returns -EFAULT when "@skb has unreadable… - [Low] The commit message says skb_crc32c() 'becomes a wrapper that behaves as before', but its unreadable-frags WARN now covers less. -- net: skbuff: add skb_crc32c_full() that reports failure This commit adds skb_crc32c_full(). When the walk runs into unreadable frags or past the end of the skb, it returns an error instead of a CRC of 0. skb_crc32c() becomes a wrapper around it, and skb_crc32c_csum_help() is converted, so SCTP packets that can't be checksummed are dropped instead of being sent with a bogus CRC. > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index de433d452939..3b2a3747f009 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3788,23 +3788,41 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > EXPORT_SYMBOL(skb_copy_and_csum_bits); > > #ifdef CONFIG_NET_CRC32C > -u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) > +/** > + * skb_crc32c_full - CRC32C a range of an skb > + * @skb: buffer to read > + * @offset: offset in @skb to start at > + * @len: number of bytes to include > + * @crcp: the CRC to continue from; on success, updated with the range > + * > + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb > + * has unreadable frags in the range or runs out before @len does. On > + * failure *@crcp is not changed. > + */ > +int skb_crc32c_full(const struct sk_buff *skb, int offset, int len, u32 *crcp) > { [ ... ] > if (copy > 0) { > copy = min(copy, len); > crc = crc32c(crc, skb->data + offset, copy); > len -= copy; > if (len == 0) > - return crc; > + goto out; > offset += copy; > } > > - if (WARN_ON_ONCE(!skb_frags_readable(skb))) > - return 0; > + if (!skb_frags_readable(skb)) > + return -EFAULT; [Severity: Low] The kernel-doc above says -EFAULT means "@skb has unreadable frags in the range". Does this check actually look at the range? skb_frags_readable() only tests the flag for the whole skb: include/linux/skbuff.h:skb_frags_readable() { return !skb->unreadable; } Take len == 0 with offset >= skb_headlen(skb). A readable skb walks zero bytes and returns 0, but an unreadable skb returns -EFAULT here. Now take a range that lies entirely in readable frag_list children of an skb whose own frags are unreadable. That also fails here, before the frag_list loop runs. No current caller seems to hit this. skb_crc32c_csum_help() always starts inside the linear head and passes a positive len. Could the kernel-doc be reworded? Alternatively, this check could apply only when the remaining range reaches frags[]. skb_checksum_full(), added earlier in the series, has the same mismatch. [ ... ] > @@ -3844,19 +3862,36 @@ u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) > copy = end - offset; > if (copy > 0) { > copy = min(copy, len); > - crc = skb_crc32c(frag_iter, offset - start, copy, crc); > + err = skb_crc32c_full(frag_iter, offset - start, copy, > + &crc); > + if (err) > + return err; [ ... ] > +/* skb_crc32c() has no way to report failure, so it returns 0, which is a > + * valid CRC. Use skb_crc32c_full() in new code. > + */ > +u32 skb_crc32c(const struct sk_buff *skb, int offset, int len, u32 crc) > +{ > + if (unlikely(skb_crc32c_full(skb, offset, len, &crc))) { > + WARN_ON_ONCE(!skb_frags_readable(skb)); [Severity: Low] The commit message says skb_crc32c() "becomes a wrapper that behaves as before". Does the unreadable-frags warning still fire for frag_list children? Before this patch, the frag_list loop recursed through skb_crc32c(frag_iter, ...). An unreadable child therefore hit WARN_ON_ONCE(!skb_frags_readable(skb)) at the child level. Now the recursion goes through skb_crc32c_full(frag_iter, ...). The child returns -EFAULT without a warning, and this WARN_ON_ONCE() only tests the outer skb. So a readable parent with an unreadable frag_list child now returns 0 to sctp_compute_cksum(), siw_crc_skb() or batadv_bla_check_duplist() without warning. Before the patch it warned once. The return value is 0 either way, so only the diagnostic changes. skb_gro_receive() doesn't seem to check readability when it merges into frag_list, so this layout looks possible, but that hasn't been confirmed end to end. The skb_checksum() wrapper from earlier in the series has the same pattern. > + return 0; > + } > return crc; > } > EXPORT_SYMBOL(skb_crc32c); -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458826.1670908 (Exim 4.92) (envelope-from ) id 1xK7GE-0003EB-VE; Fri, 23 Oct 2026 04:52:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458826.1670908; Fri, 23 Oct 2026 04:52: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 1xK7GE-0003DJ-PK; Fri, 23 Oct 2026 04:52:10 +0000 Received: by outflank-mailman (input) for mailman id 1458826; Fri, 23 Oct 2026 04:52:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GD-0002yv-AG for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7GC-00FSfm-NU for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:08 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7e7-2eae-0a2a0a5409dd-0a2a4504ad1c-36 for ; Fri, 23 Oct 2026 06:52:08 +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 6adae7f7-b57f-0a2a45040019-aceafc1f8338-3 for ; Fri, 23 Oct 2026 06:52:08 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id D5111402B0; Fri, 23 Oct 2026 04:52:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBFA51F01825; Fri, 23 Oct 2026 04:52: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731126; bh=D30nNXRjiP8TsE/AFA9HAZ4TRwgaJqNqJTiotkgZq6k=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=Di3O8UiGH0C/7ezn1q4ouy3VhjZgorTtXE6VHIt0tgFf73H8bvspJh63fmQxRDkSA wWw3OMHBeED8MHBM+JVf5kCQU82ByFCHdeGBaboC1k+KtNo4FMSOlgumR0/atS4cui 6Lk5mPggW7ooNY0tDROOnVcwd2d4C6meXPjguASYmztXFEO4Ke9Yt5i2hEOgx83bWm fQ0y7muPVhmaMwiUpOBPduUB2aCGdHe0J5mE/oS7TYWpL3PcG1otRTek9zISJNsNvV i4q29w38VtOCrWJN+xCDhjWUVCYz4/2uxbtzkTTxgfRyTkW6yGGH7CFx+oQRtOenp3 YwRd5EnovhgRA== Subject: Re: [PATCH net-next 07/15] net: skbuff: let skb_zerocopy() copy a short skb without head_frag From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:05 +0000 Message-ID: <179273112552.3134.3914409238087921235@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-7-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-7-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Medium Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-ebf023/1792731128-534C3B50-18BEDB0E/0/0 X-purgate-type: clean X-purgate-size: 3422 Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider. Critical: 0 · High: 0 · Medium: 1 · Low: 0 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [Medium] The Fixes: tag points at the wrong commit, so stable kernels will not get this fix even though they still have a BUG() that an… -- net: skbuff: let skb_zerocopy() copy a short skb without head_frag This patch moves the !from->head_frag && !hlen check in skb_zerocopy() below the small-payload skb_copy_bits() path. A short copy from an skb without a head_frag, including a zero-length one, now succeeds. The motivating case is an Open vSwitch OVS_PACKET_CMD_EXECUTE request doing POP_ETH followed by USERSPACE, which ends up calling skb_zerocopy(user_skb, skb, 0, 0). Link: https://lore.kernel.org/all/179173804997.434549.4450793967361922984@kernel.org/ > That used to BUG(), and now the > upcall fails and the packet is counted as lost, with a WARN on > CONFIG_DEBUG_NET kernels. OVS_PACKET_CMD_EXECUTE only needs > CAP_NET_ADMIN in the user namespace that owns the network namespace, > so with the openvswitch module loaded any user can do this from their > own namespace. [ ... ] > Fixes: 433380f5ab8f ("net: skbuff: don't BUG() on a missing head_frag in skb_zerocopy()") [Severity: Medium] Is this the right commit for the Fixes: tag? 433380f5ab8f only turned the existing BUG_ON() into an -EFAULT return. It went in through net-next as part of the "net: skbuff: replace most BUG_ON()s with error returns" series, with no Fixes: or Cc: stable tag, so no stable tree has it. The ordering problem is older than that. Before 433380f5ab8f, skb_zerocopy() looked like this: BUG_ON(!from->head_frag && !hlen); /* dont bother with small payloads */ if (len <= skb_tailroom(to)) return skb_copy_bits(from, 0, skb_put(to, len), len); The BUG_ON() has been in that spot since af2806f8f90a1 ("net: Export skb_zerocopy() to zerocopy from one skb to another") in 2013. On those kernels, the path in the commit message reaches the BUG_ON(): ovs_packet_cmd_execute() __dev_alloc_skb(NET_IP_ALIGN + len, GFP_KERNEL) /* head_frag == 0 */ ... POP_ETH leaves skb->len == 0 ... ovs_dp_upcall() queue_userspace_packet() skb_zerocopy(user_skb, skb, 0, 0) BUG_ON(!from->head_frag && !hlen) With the current tag, stable tooling would only pick this up for trees that already return -EFAULT. Wouldn't every stable tree without 433380f5ab8f keep a BUG() that a user can trigger from their own namespace? Should this carry Fixes: af2806f8f90a1 instead, or the OVS Ethernet push/pop commit that made an empty-skb upcall reachable? It should also probably have Cc: stable and go through net rather than net-next. A stable backport would also need to move the old BUG_ON() below the len <= skb_tailroom(to) return, since those trees don't have the -EFAULT conversion. -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458828.1670913 (Exim 4.92) (envelope-from ) id 1xK7GF-0003Iv-E3; Fri, 23 Oct 2026 04:52:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458828.1670913; Fri, 23 Oct 2026 04:52: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 1xK7GF-0003I1-5V; Fri, 23 Oct 2026 04:52:11 +0000 Received: by outflank-mailman (input) for mailman id 1458828; Fri, 23 Oct 2026 04:52:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GE-00037i-CW for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7GD-00FSfm-Pi for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:09 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7e1-2eae-0a2a0a5409dd-0a2a4508cb7e-26 for ; Fri, 23 Oct 2026 06:52:09 +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 6adae7f8-f659-0a2a45080019-ac6904feabf6-3 for ; Fri, 23 Oct 2026 06:52:09 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 3CF3860233; Fri, 23 Oct 2026 04:52:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 533F41F031E1; Fri, 23 Oct 2026 04:52: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:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731128; bh=m4eUhHLp14jEKzi8uHnH2gScUY1iDl3d/EjgImmk3go=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=FTvdEGT0Wxsyij7WdwX3FaVHnPOWCyIiEujPXH8IHq8o2B9pQfwgTdK/NqLRVSwGy 6xl9sgCPeh3sDT42Jd5Cye+yN3RquBnykOVo4418+K2jHCYfLz48/p+OI7ElNdMYem 9F2nmCE9xUALydd23c5SeQXqyDkc5RL6ndhQFp6c2KPTJtFO2sDorBRB9Z+CwHAWC2 60XKTi0L8s4jcjD+jfnj8CeUVsy8S58WWc1hWxNNH+w1hsTzV77vM5qKxDQ31wA830 TmUg45gOWhwyMRxHJVJwKpvZf6kzS1J7GUdszwqdRcAFMSTtvn//dxwAV8UClBBQFR Vl0dNkv3k/v8w== Subject: Re: [PATCH net-next 08/15] net: skbuff: make skb_try_coalesce()'s len unsigned From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:06 +0000 Message-ID: <179273112692.3134.1759491419702666549@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-8-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-8-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-c1860d/1792731129-D775B87B-70DC75C0/0/0 X-purgate-type: clean X-purgate-size: 2645 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The commit message gets the bug's history wrong, so the single Fixes: tag (279877d86c82) is incomplete. -- net: skbuff: make skb_try_coalesce()'s len unsigned This changes the local len in skb_try_coalesce() from int to unsigned int, so a from->len above INT_MAX can no longer pass the skb_tailroom() check. It also adds an explicit delta < 0 test to the truesize WARN_ON_ONCE(), since that comparison is now unsigned. Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ > Before that commit skb_put() ran first, > and its overflow check caught such a length before anything was > copied. [Severity: Low] Is this accurate on all configurations? Before 279877d86c82, skb_try_coalesce() looked like this: if (len <= skb_tailroom(to) && skb_frags_readable(from)) { if (len) BUG_ON(skb_copy_bits(from, 0, skb_put(to, len), len)); len was already a signed int at that point. A from->len above INT_MAX passed the tailroom check then, the same way it does now. skb_put() then does: skb->tail += len; skb->len += len; if (unlikely(skb->tail > skb->end)) skb_over_panic(skb, len, __builtin_return_address(0)); On 32-bit, sk_buff_data_t is unsigned char *. A lowmem tail at or above 0x80000000 plus a len at or above 0x80000000 wraps below end, so skb_over_panic() is never called. skb_put() returns the old tail, and skb_copy_bits() runs with the negative len. That is the same large write past @to that the commit message attributes to 279877d86c82. On 64-bit, tail and end are u32 offsets. A from->len in the range [2^32 - tail, 2^32) also wraps tail below end and gets past the check. 279877d86c82 seems to have widened this window on 64-bit, but it did not open it. git blame shows that the signed len goes back to the introduction of the function: bad43ca8325f4 ("net: introduce skb_try_coalesce()") Could the commit message be corrected? Should a Fixes: tag for bad43ca8325f4 also be added? Without it, stable trees that don't contain 279877d86c82, including their 32-bit builds, may not get this fix. > Fixes: 279877d86c82 ("net: skbuff: don't BUG() when skb_copy_bits() fails in copy helpers") -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458830.1670924 (Exim 4.92) (envelope-from ) id 1xK7GH-0003lj-N6; Fri, 23 Oct 2026 04:52:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458830.1670924; Fri, 23 Oct 2026 04: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 1xK7GH-0003lQ-I6; Fri, 23 Oct 2026 04:52:13 +0000 Received: by outflank-mailman (input) for mailman id 1458830; Fri, 23 Oct 2026 04:52:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GG-0003Uy-3A for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7GF-006sSq-Ey for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7b7-bab6-0a2a0a5309dd-0a2a45019376-34 for ; Fri, 23 Oct 2026 06:52:11 +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 6adae7fa-5984-0a2a45010019-ac6904fea64a-3 for ; Fri, 23 Oct 2026 06:52:11 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id D5F536022C; Fri, 23 Oct 2026 04:52:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC8131F01825; Fri, 23 Oct 2026 04:52: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:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731129; bh=ALJG1SS2iy0WNzGYJ2ykwPhdXMhJmbb3CoA1YF8ffNc=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=LBiOMtrDWCpmJO/ji86Cm00kxg5nINn6Ygjd5c3AQDkNrnU1kFrfmscNk06E3Pllm OOf4zfyBdEEeDqjVeUn8Q+eUF71szWkujD/7zYvOuUSd+DzyyeTym8udRVjUdDBmFn hkja5jzp7viOvPROAMFnWXTePG3v+VngBOu3XUHJSy6M7/nm3pxc5J0/sNgSM9wdhf i/qQl8vhcojaX76gM2RTVgRT/lL/bDsHtetipEb+ognTO7kEWTZxhxaYVyKZ+jmfJd K+wurkGehCZVpXLsNjKas5F7UkTKzAqORqvEBQEBKPNpOVLIDLwroUbGm+ZFiaVXHD FZpL/xAHtvnZg== Subject: Re: [PATCH net-next 09/15] net: skbuff: check csum_start against len in skb_copy_and_csum_dev() From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:08 +0000 Message-ID: <179273112823.3134.12241973533522574538@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-9-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-9-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Medium Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-d62444/1792731131-C5341757-FE05F783/0/0 X-purgate-type: clean X-purgate-size: 2732 Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider. Critical: 0 · High: 0 · Medium: 1 · Low: 0 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [Medium] net: skbuff: incomplete headlen underflow check in skb_copy_and_csum_dev() -- > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -4103,7 +4103,11 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to) > else > csstart = skb_headlen(skb); > > + /* skb_headlen() underflows if data_len is bigger than len, so check > + * csstart against len as well. > + */ > if (unlikely(csstart < 0 || csstart > skb_headlen(skb) || > + csstart > skb->len || > (skb->ip_summed == CHECKSUM_PARTIAL && > csstart + skb->csum_offset + sizeof(__sum16) > > skb->len))) { > [Severity: Medium] This only closes the hole for the non-CHECKSUM_PARTIAL case. If skb->data_len > skb->len and ip_summed is CHECKSUM_PARTIAL, csstart comes from skb_checksum_start_offset() instead of skb_headlen(), so it can be anywhere up to skb->len while skb_headlen() has wrapped to about 4GB. Both the headlen comparison and the new skb->len comparison then pass, the csum_offset check passes too, and we go straight on to skb_copy_from_linear_data(skb, to, csstart) with nothing bounding csstart by the real linear area. skb_copy_and_csum_bits() then starts from int start = skb_headlen(skb), which is either negative, so the linear part is skipped and the frag reads are shifted by data_len - len bytes, or, once the difference exceeds INT_MAX, a bogus positive value that lets it copy from skb->data past the end of the linear data. The fallback isn't safe either. skb_copy_bits() also begins with int start = skb_headlen(skb), so sending such an skb down the existing fallback, as the changelog describes, bounds the writes to @to by skb->len but not the reads from the skb. Since the condition you really want to catch is data_len > len, would it be simpler to test that directly before computing csstart, and memset() @to rather than calling skb_copy_bits() in that case? Or should skb_copy_bits() and skb_copy_and_csum_bits() reject data_len > len themselves? -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458832.1670929 (Exim 4.92) (envelope-from ) id 1xK7GI-0003sX-EK; Fri, 23 Oct 2026 04:52:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458832.1670929; Fri, 23 Oct 2026 04: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 1xK7GI-0003rO-8S; Fri, 23 Oct 2026 04:52:14 +0000 Received: by outflank-mailman (input) for mailman id 1458832; Fri, 23 Oct 2026 04:52:13 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GH-0003ko-Hp for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7GG-006sSq-V3 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7f7-bab6-0a2a0a5309dd-0a2a45038fb8-6 for ; Fri, 23 Oct 2026 06:52:12 +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 6adae7fb-fae8-0a2a45030019-aceafc1fe3ae-3 for ; Fri, 23 Oct 2026 06:52:12 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 19B99436D5; Fri, 23 Oct 2026 04:52:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E2301F01829; Fri, 23 Oct 2026 04:52:10 +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:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731131; bh=297sVdh7jI9/YZVUTISisNh0xfIn+ptDdAeK7+MG+j4=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=RsVDi42x5d11Xzqr5TY5CMbXLnmsax0HywsBl/ckkPOsiwTAtg2HKqp1I0Gt0pNe5 o562TlDRdFBbd72heCdiENUI2gRkwkQmu4284CHf1aXb58ZwQNdM3kLzrxp+szYioX Xm8klKt3tLKcfAH4v2z2hprDFbJvqndr6XjUHJ6uWq/nqZHFS6/nvS8yHj0XwF2Ay8 pGjfemmlrmCJjlLw8g5JbeNJH5uuzLIcQAsA3I7UnSfPR90oeUcWLYsW52hkPI1u0K Vc3k0AafsJCnffpPlgHDfZHENet5iR2IKZSCJ7oV+Vp4IUC9qKYyDNn7y8LStW+QJx 5/p2ncCTH6e3Q== Subject: Re: [PATCH net-next 10/15] net: skbuff: reject a negative length in skb_copy_and_csum_bits() From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:09 +0000 Message-ID: <179273112973.3134.5343458615205155491@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-10-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-10-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-33051d/1792731132-6CCDB4E9-13F0EBB3/0/0 X-purgate-type: clean X-purgate-size: 5543 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The commit message's reason for dropping the `if (len > 0)` guard on the final zero-fill in skb_copy_and_csum_bits() (net/core/skbuff.c)… - [Low] The patch narrows the zero-fill promise in skb_copy_and_csum_bits()'s kernel-doc: "on -EFAULT the part of @to… -- net: skbuff: reject a negative length in skb_copy_and_csum_bits() This commit makes skb_copy_and_csum_bits() return -EINVAL, with a DEBUG_NET_WARN_ON_ONCE(), when it is given a negative len. It also drops the len > 0 guard on the final zero-fill. The kernel-doc now promises the zero-fill only for -EFAULT. Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ > Commit 417261779eab ("net: skbuff: don't BUG() on leftover length in > skb_copy_and_csum_bits()") guards its zero-fill against a negative @len > from a broken caller, but such a @len never gets that far. The head, > frag and frag_list copies all clamp their length to @len, so a negative > one has already turned into a huge copy, or an endless frag walk, by > then. [Severity: Low] Is this an accurate description of the old code? The head, frag and frag_list copies clamp to len only when they run. All three are skipped when offset is at or past the end of the skb's data. Take a linear skb with no frags, offset == skb->len and len == -1: copy = start - offset; /* 0, no head copy */ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) /* no frags */ skb_walk_frags(skb, frag_iter) /* empty */ In the parent commit, the negative len then reaches the final block unchanged: net/core/skbuff.c:skb_copy_and_csum_bits() { ... if (unlikely(len)) { DEBUG_NET_WARN_ON_ONCE(1); /* Don't hand the caller a buffer with stale bytes in it. */ if (len > 0) memset(to, 0, len); return -EFAULT; } ... } There, the len > 0 check is what prevents a memset of close to SIZE_MAX bytes. The code change itself looks right, because the new check on entry keeps len non-negative for the rest of the function. The Fixes: tag relies on this description of what 417261779eab guarded, though. Could the commit message say that the guard only covered the final zero-fill and not the clamped copies? > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 782a6bacd568..56cec58bccb7 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3678,9 +3678,10 @@ EXPORT_SYMBOL(skb_checksum); > * @len: number of bytes to copy > * @csump: where to store the checksum of the copied bytes > * > - * Return: 0 on success, or -EFAULT if @skb has unreadable frags or runs > - * out before @len does. On failure *@csump is not set and the part of > - * @to that couldn't be filled is zeroed. > + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb > + * has unreadable frags or runs out before @len does. On failure *@csump > + * is not set, and on -EFAULT the part of @to that couldn't be filled is > + * zeroed. > */ > int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > u8 *to, int len, __wsum *csump) > @@ -3692,6 +3693,14 @@ int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > __wsum csum = 0; > int err; > > + /* Everything below clamps copies to @len, so a negative one would > + * turn into a huge copy. > + */ > + if (unlikely(len < 0)) { > + DEBUG_NET_WARN_ON_ONCE(1); > + return -EINVAL; > + } [Severity: Low] This early return leaves to untouched, and the kernel-doc above now promises the zero-fill only for -EFAULT. Does skb_copy_and_csum_dev() need an update as well? Its comment still says that any failure zeroes the buffer: net/core/skbuff.c:skb_copy_and_csum_dev() { ... csum = 0; /* On failure the rest of @to is zeroed; leave the checksum alone so * the frame goes out with a bad one. */ if (csstart != skb->len && skb_copy_and_csum_bits(skb, csstart, to + csstart, skb->len - csstart, &csum)) return; ... } The drivers that call it (8139too, via-rhine, sc92031, ep93xx, ec_bhf, ksz884x) transmit to after it returns. The csstart checks keep skb->len - csstart non-negative as an unsigned value, but they don't keep it within INT_MAX. A corrupt skb with more than INT_MAX bytes past csstart would get -EINVAL here, and the bytes after csstart would go out stale. That also goes against the first patch in the series ("net: skbuff: make skb_copy_and_csum_bits() report unreadable frags"), which says "The zero-fill stays, so a caller that does send the buffer still doesn't leak anything." The drivers' own size limits keep valid skbs from getting here. Before this patch, the same corrupt input caused a huge copy instead. The comment in skb_copy_and_csum_dev() is still unchanged at the end of the series, including after "net: update comments that still describe the skb BUG_ON()s". Could that comment be updated? Alternatively, skb_copy_and_csum_dev() could zero the rest of to itself when the helper fails. [ ... ] -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458833.1670941 (Exim 4.92) (envelope-from ) id 1xK7GJ-0004Cm-V8; Fri, 23 Oct 2026 04:52:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458833.1670941; Fri, 23 Oct 2026 04:52: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 1xK7GJ-0004CA-Nb; Fri, 23 Oct 2026 04:52:15 +0000 Received: by outflank-mailman (input) for mailman id 1458833; Fri, 23 Oct 2026 04:52:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GI-0003uX-Ok for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7GI-008wg1-58 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:14 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7b7-2eae-0a2a0a5409dd-0a2a450ce014-34 for ; Fri, 23 Oct 2026 06:52:14 +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 6adae7fc-f479-0a2a450c0019-ac6904fed766-3 for ; Fri, 23 Oct 2026 06:52:14 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id AD1706022C; Fri, 23 Oct 2026 04:52:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 959C41F01825; Fri, 23 Oct 2026 04:52: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="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731132; bh=agkvCklKmEd8Wp6mVSMBoVqEMTNMmcycBQEcregNfVo=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=egaoWeXYUJlTrjLH3F6bQMXw18UbNdnbpS+dRSabHlQD9C/AeZOtHA9cr0o/UxpQU tmTHIqaypY0rM6WJSD3sGo7DnT1Zkr8pWqM0qo0GLWqTb1vJbqm1LLavuOtc6ORwyI kOLvXSjea4i2T8GXpLijTp9Fsh1/aEDZDShjnmghI9kkbFwOEsVxY0fNKf/0L01bxz +7UJ4e08bNKe/mS9VtdtX26PgFbKT316nG6h4msxi9zsqOnIW14ym2aEp7Sq/yXrcF oo3uzlQddM6jfX0uSqrGMxXJGIFIGpXL6Rdb4be6b/dOGBF+ErgxMYRdS70/6rL6od n8owJ7ZO8cU7A== Subject: Re: [PATCH net-next 11/15] net: skbuff: refuse to segment a nested frag_list From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:11 +0000 Message-ID: <179273113115.3134.9365887081510077540@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-11-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-11-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-d25034/1792731134-004CFA5B-EE728E73/0/0 X-purgate-type: clean X-purgate-size: 2202 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The commit message for "net: skbuff: refuse to segment a nested frag_list" says "Nothing in the tree is known to build such an skb;… -- net: skbuff: refuse to segment a nested frag_list This adds a check to skb_segment() that rejects an skb whose frag_list members have frag_lists of their own. It fails with -EINVAL and calls DEBUG_NET_WARN_ON_ONCE(), since the segmentation walk would otherwise run out of members and dereference a NULL list_skb. > Nothing in the tree is known to build such an skb; GRO flushes instead > of chaining an skb that already has a frag_list. Check for it up front [Severity: Low] Is the first half of this sentence accurate as a general statement? IP fragment reassembly appears to build exactly this layout. When the first fragment already has a frag_list, inet_frag_reasm_prepare() moves that frag_list under a new zero-length skb: net/ipv4/inet_fragment.c:inet_frag_reasm_prepare() { ... if (skb_has_frag_list(head)) { struct sk_buff *clone; ... clone = alloc_skb(0, GFP_ATOMIC); ... skb_shinfo(clone)->frag_list = skb_shinfo(head)->frag_list; skb_frag_list_init(head); ... skb_shinfo(head)->frag_list = clone; nextp = &clone->next; ... } The result is head -> frag_list[clone -> frag_list[...]]. That is the nested layout the new check in skb_segment() rejects. The GRO part is correct. dev_gro_receive() sets: NAPI_GRO_CB(skb)->flush = skb_has_frag_list(skb); Reassembled skbs are not GSO, so they don't normally reach skb_segment(). The narrower claim seems to be what's meant: no in-tree path builds a GSO skb with a nested frag_list. Could the commit message say that instead, and mention IP defrag as a known non-GSO source of nested frag_lists? -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458835.1670952 (Exim 4.92) (envelope-from ) id 1xK7GM-0004dO-BQ; Fri, 23 Oct 2026 04:52:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458835.1670952; Fri, 23 Oct 2026 04:52: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 1xK7GM-0004d4-68; Fri, 23 Oct 2026 04:52:18 +0000 Received: by outflank-mailman (input) for mailman id 1458835; Fri, 23 Oct 2026 04:52:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7GK-0004GI-Aq for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7GJ-008wg1-L4 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:15 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae7b7-2eae-0a2a0a5409dd-0a2a450ce014-36 for ; Fri, 23 Oct 2026 06:52:15 +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 6adae7fe-f479-0a2a450c0019-aceafc1fe3b2-3 for ; Fri, 23 Oct 2026 06:52:15 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id E299A436D5; Fri, 23 Oct 2026 04:52:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 050741F01829; Fri, 23 Oct 2026 04:52: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792731133; bh=azFOvOpPS9RZ120HsX52bxdBzg8kjxW7KcH0FOk6vxc=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=O7NZQ8FF6U3UOuTimWTmvUqmaQtqyLVbAEyVmIZaqkfWBBzHNo/Sue+FKa7kvDag9 nGpldSZO1RJeeeO4F/b6JyTA5GuQmwtOwKX2YAnRMGYPqKutIrABrHEG0WyLHhbOPa Kcv1pUAXpm4ncNeD8z3Pk1V28XYa9S70hu7aQYRvmMt7qgz/g45PKhuwHFJk3/nqAQ VA98nDMzOYmNGgDL/T48hpGLBUc4Fdk+jhHa7I5JOXrCF+tquW7nfEyu+ilOBrGK8q PTczCVynq1BGOc3PQKef6MlH8AGHhHHFgfz+ZtkZDeft78f0gAmzpMsD9QViEHZ3af YvoC9799xvoew== Subject: Re: [PATCH net-next 14/15] net/tls: don't BUG() on leftover length in __skb_nsg() From: netdev-bot+sashiko@kernel.org To: josef@toxicpanda.com Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, almasrymina@google.com, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Date: Fri, 23 Oct 2026 04:52:12 +0000 Message-ID: <179273113257.3134.13391569696975669516@kernel.org> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-14-41dbef50b9f7@toxicpanda.com> References: <20261019-b4-skbuff-bug-on-followups-v1-14-41dbef50b9f7@toxicpanda.com> X-sashiko-severity: Low Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-d25034/1792731135-036D6A5B-C5DB1CF1/0/0 X-purgate-type: clean X-purgate-size: 2307 Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] In net/tls/tls_sw.c, the comment above skb_nsg() is now out of date. -- net/tls: don't BUG() on leftover length in __skb_nsg() This patch replaces the BUG_ON(len) in __skb_nsg() with a DEBUG_NET_WARN_ON_ONCE() and an -EINVAL return. A range that runs past the end of the skb now fails the record in tls_decrypt_sg() instead of crashing the kernel. > diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c > index 312e51270f29..1c578ea47a1b 100644 > --- a/net/tls/tls_sw.c > +++ b/net/tls/tls_sw.c > @@ -142,7 +142,10 @@ static int __skb_nsg(struct sk_buff *skb, int offset, int len, > start = end; > } > } > - BUG_ON(len); > + if (unlikely(len)) { > + DEBUG_NET_WARN_ON_ONCE(1); > + return -EINVAL; > + } > return elt; > } > [Severity: Low] This isn't a bug, but should the comment above skb_nsg() be updated to cover the new return value? The comment directly below this hunk still says: net/tls/tls_sw.c: /* Return the number of scatterlist elements required to completely map the * skb, or -EMSGSIZE if the recursion depth is exceeded. */ static int skb_nsg(struct sk_buff *skb, int offset, int len) { return __skb_nsg(skb, offset, len, 0); } skb_nsg() returns whatever __skb_nsg() returns. The recursive frag_list calls also pass negative values straight up: if (unlikely(ret < 0)) return ret; So skb_nsg() can now return -EINVAL when the skb runs out before the requested range does. The only caller, tls_decrypt_sg(), already handles any negative value: if (n_sgin < 1) return n_sgin ?: -EBADMSG; So this doesn't change behavior at runtime. The comment is also still unchanged at the end of the series, including after the last patch, "net: update comments that still describe the skb BUG_ON()s". -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:52:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:52:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458877.1670961 (Exim 4.92) (envelope-from ) id 1xK7Gm-0006z9-M4; Fri, 23 Oct 2026 04:52:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458877.1670961; Fri, 23 Oct 2026 04: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 1xK7Gm-0006yy-Id; Fri, 23 Oct 2026 04:52:44 +0000 Received: by outflank-mailman (input) for mailman id 1458877; Fri, 23 Oct 2026 04:52:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7Gl-0006uW-JX for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:52:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7Gl-00FSjJ-0I for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:52:43 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae804-e002-0a2a0a5209dd-0a2a45018318-40 for ; Fri, 23 Oct 2026 06:52:42 +0200 Received: from [52.101.125.98] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adae817-5984-0a2a45010019-34657d6216d3-3 for ; Fri, 23 Oct 2026 06:52:41 +0200 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYRP286MB5946.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:2f0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Fri, 23 Oct 2026 04:52:37 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.016; Fri, 23 Oct 2026 04:52: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=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=hAxf8XsIn5+QdG2sQfi3C9FjG2nKn4SKJS4k2wUUeuUlZFIxltS4iCAQRcd8HnzbAblhZIXMnMT/rJ7DUbsT+QndkKndxLcEIVvbEmYi0wVletVJY+sz7sifzsqWyzlz6PMyg68jeAP+Yi7HpeCLwT0IQGEjUHj+zDRr08IP01LodbHfXQaoNmRui0lIXzQWlKN7R5Tu0PkH2EVecVwCk9JyhFJ3dLF1KILNTQTTlnl9KfwJLK0cMb8eNTbkaZc+FsztmQjHSmC9X9d6DYPzVDksnvVNEE52H0GWL2CO5jRozSB5lT9v+d4f8dONsHjeTdkZS80kl0ANeNf3prc/GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=B7ltYEKX+cKqsvP9h4OtOTgNQtNgp6o3XIpTxvBpIi8=; b=HbzLjZ26tRAajMSU+y3GNU7j2cQS4dQGZGm2sr7DUVD3JwDo7UQ/i2NmIKiO9Yq9742YMVJZqyg86Dx797AV5YKdX5dDUrnQiSZ/KbBvVcKlY98IF8kQqFXoxDzM26pF/ADPj5Gfy5Y89CQIE5lCmNHq5ktuQacvD4QVsWwFnSaVxZoZ0OYgmA3lfw6cv2+n2tsmNfPDB9GkfwUWhhJmvnMCIWe6TwB1P6WuwvHJHxLVvQjrH8Td7xJWVFGVYaw+A8D0uNS1TQmVHlA+ZF8Wk+J6Hgpd4BPeJW3IsTmO6zphaSZH9Kytnzlv/4GN+8efnLkBhOgxnbruY/dIZslDzw== 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=B7ltYEKX+cKqsvP9h4OtOTgNQtNgp6o3XIpTxvBpIi8=; b=g0r0d7yGMnKbTDI7j6d9QdEW5/w+RrW8lWxo67jyDEBuAjA+ShgH9obADfY6lg8ZARNHWbj92FlqRowp1uTA80vtnYszCS3jjEvdhojcKnOY2cdJWXSeYC6bLUbh9XjBkShsKM127v3EOCY15ibDASU35AXougVneBFk+4MtoPc= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, roger@xenproject.org, ross.lagerwall@citrix.com, Ryo Takakura Subject: [RFC 1/5] xen/arm64: livepatch: enable attaching callbacks Date: Fri, 23 Oct 2026 13:52:22 +0900 Message-Id: <20261023045222.163817-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20261023044809.162759-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP301CA0025.JPNP301.PROD.OUTLOOK.COM (2603:1096:400:381::12) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYRP286MB5946:EE_ X-MS-Office365-Filtering-Correlation-Id: 5d1247ef-7435-44d3-8283-08df30c1759b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|23010399003|1800799024|6133799003|10067099003|18002099003|261021123027099003|22082099003|261022105027099003|3023799007|261022075727099003|261021133027099003|261021130227099003|260925021311599003|260925021911599003|260925022911599003|261021135927099003|261021121427099003|261009223027099003|261022115727099003|261022113327099003|56012099006; X-Microsoft-Antispam-Message-Info: BIeYR45+uszKnZ2XZjVnfSfsVNvxU3SAZcsvIPDS4C9cKKL87xPOx3FNNJC9Ra7T1EGZgsVMhxcza5MLfgxrf4uP27hP10vWeaHvGDi7jpIa5vHesA+0gAc4jlWvQyiVtBxc4Vr1GBdUAjswwv3eN22cTdN9Sc36eY/AVVc5n4x/wdI3YoobbGQYyFvSdX8x/4hkPsvSD/EJC2EAIiYCPprOECuCss5w9keld38CC8oHiD9h9oZV7EDXDmuVc4pNmuwIgxPvnJ2sjNvgTG+ogny8tVF6HNuVCPclpoMYa0/lCzy1aH2PGV6QfARwuhrOgwPBnPIUHtBOiADZ07sUWXQEA6wTlR6goedEwK7AnLEOqz0xS+4dkALbFYAgVpT9O3nhqzG/SBVrPhkISwTkrB8DiifEjqQgFQe+wBTiaapbeO1aR1KYBRbJ9ezUo3qg3m9Safe3+FdnzVzjhNw0+xKSrR1ScqUV6XGCFt1KS8SQfRDd2zLUVEGouuZqZR5DT52naai5wXHtSUGnm+Yixw69FJjUtSGuFoIsHDCkWYNB98rvvDhm3kxy7w8d8witHQV9Ztd35uhjdEnAP55xj/AN9+3W9x1OMUIU45K6tpOBwiwj2nE1sdqMlouG6D+4vAUi12SgZuw6cVUfhYQn8LBsId8XRq8B/hQnTDQ8YVg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(23010399003)(1800799024)(6133799003)(10067099003)(18002099003)(261021123027099003)(22082099003)(261022105027099003)(3023799007)(261022075727099003)(261021133027099003)(261021130227099003)(260925021311599003)(260925021911599003)(260925022911599003)(261021135927099003)(261021121427099003)(261009223027099003)(261022115727099003)(261022113327099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?WZqNCmFqko6fYBtQwSszb07Xq/enqZq3AS/UEXJ7VbpV1xGuqyQmqMb23pKj?= =?us-ascii?Q?loH1IgZyNp8+7yfqAXAqhdouMuDXKMktRR8DgbnwVatP7yNuJ8Fx/rq6IhYY?= =?us-ascii?Q?teInlSxUIdIKYLF2EkT5U/UAL0qIFOItboUeTfHYPvAJ4pAED5NL1HiCh3Gj?= =?us-ascii?Q?BbzdfOOkpnVGJqaENOc4l2XY/BnXJCf8JyH4kA5IeizIyBKvZuEOvYJ9ELe1?= =?us-ascii?Q?VoSsHvyoeGJaeujBaTTc39RK5hNvhXcOchZJUXCkZGo0ScJDSEGdOfMpQdcO?= =?us-ascii?Q?KRY8WXNa9L0rsis0YcmqAlnOz9V63o0vR53pY3RB+KGi+vaNhOo9wl78w97T?= =?us-ascii?Q?cQo2LZX6bnOQyfbmLvqb2zAteTTogmpwKiFZMo2ziRosh/+dDojqtfB/QvxT?= =?us-ascii?Q?ECz0OiVNNSF6NzEERKaKjXeS03lcNjTA6SeYdxKwz100ep4IuJjgd00tl0Hx?= =?us-ascii?Q?biDgl8+w4NRH1XwrrBRWPPQ6hzpAnl3rfJD60zkqCghgFIKdQmlgPHZ6TDQY?= =?us-ascii?Q?+pwiqNXcG6hJYRyPRwE4Fb/mwrwa4xnbqA4Oz/cd3af/pwzaSuq3Oc8XkcCl?= =?us-ascii?Q?w89zEsdV8wgAxBtBlrOIy1x54hsYF3YFh1UWIH/pvt6PCxauZn9no6nmUNCi?= =?us-ascii?Q?6cInHKkIR/Fn7Z2//8y/KZ7PBztgRUmwddjIYQvkYzFrIqkrPvH5e1bI7hXB?= =?us-ascii?Q?NOla9/QMB6RsEottn2l0TfX0zYnzaur4d9D1B6Qs6GkGILZ1FP2YgAKbK4lR?= =?us-ascii?Q?g2LbXiO35JAz7w/Xm8QC6ZfbCG35018FicPXRCQ/TLohcnrusCSuTPhLgWpq?= =?us-ascii?Q?AE7/LT2or17KgPJFuNs+8pWfbVaarqorRD3xLFH/ArLmpREBnPqre9kTyG+b?= =?us-ascii?Q?3CkNFY0S/7koiKihYJ3JsG3EZOlGmQ0hCq7SzV9uvu4WIF9EVk3ZZjv5bqsb?= =?us-ascii?Q?fKmU6FJAASZluAWhoedx7KReAoqJJ9fy0GCmZUw3A31X4tRpeoP6MDb01kS8?= =?us-ascii?Q?JkWEr2Qr33ow1AN+2SY6M32BSrEvr3EHZjc1bcfGPWr76CIF7R9HakG3WIn1?= =?us-ascii?Q?R4Mz5/0/0FwgcTvDqQaiF1sSy44x35TRVRC5qAB7NdojO3ckfUwOqCbaRtEf?= =?us-ascii?Q?gZZp/OltV8yUyd73Yx8f0FhTiAO+EQ9/iuPut21ZHuac+tP0IphMVxZeLEKd?= =?us-ascii?Q?tqkxf4XzQF3iJn3UEhW9aA06nWAvfKikYXmYZLzTkB8XohngYCvQa09d3WrV?= =?us-ascii?Q?qRdo9keYx4AZOArPZ2tr0M5WmG7qYvIc+H+EMnxVmVdKu+4W7Fe0x40D/bcf?= =?us-ascii?Q?61k5Z18tZOhOfvNbL/XHi2b4dLxy28SW/lBulsMtHoF7EepxssBscpLe9UTY?= =?us-ascii?Q?yU/LFYp9klg3z4361kodJ0uEVNeDwcYkWWyTnYL3byOOA5O7J4gy1g+pJGQ5?= =?us-ascii?Q?/EnF5xGXeSNmdQ/rDQxkkjHuGeoC3soU3wSwRKOYWC8FnYo8iA0+sySsiXbV?= =?us-ascii?Q?YrtlCb1PTz3u9Iy1k2nSJLJLJiunMtaPHiTJDq3AaX5F/q0yLjGuqXAtS3F5?= =?us-ascii?Q?ob/vfYs0eWa6gyV6RwPbl/zGUXNZIfNt5BvZsLz18Gp+yhjNiKGrXs2Wif4c?= =?us-ascii?Q?ZW7QdZJwG3wVSKReQ0sKNVIkvhuxW8tdZuAavYiS3Nxv+PUyZ+iKYwnqif0f?= =?us-ascii?Q?iPerjlsRat3GGUMKrSsAoJtrpLJtVpIgMFitFO2NxOjteqPjzP5htmKlpqxa?= =?us-ascii?Q?pR7m6R02rw=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 5d1247ef-7435-44d3-8283-08df30c1759b X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 04:52:37.0674 (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: 1hJDebCg+WYZRMeZ5nn1V3AWPX9tkniGm+8HMYql6P1pmWC4OwcYQujBbddB5cINzBtLLGl64A1qaW4XnePAdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYRP286MB5946 X-purgate-ID: tlsNG-d62444/1792731162-1FC69757-54FF4759/0/0 X-purgate-type: clean X-purgate-size: 15814 Linux ftrace allows registering callbacks which is useful for debugging and tracing events. On Linux, it is done by reserving NOPs at function entry at compile time which can later be patched with a branch instruction to a trampoline. This patch introduces similar callback feature adopting linux-like approach of reserving 2 NOPs at function entry. When user requests the feature, the NOPs will be livepatched with: mov x9, lr bl xen_livepatch_trace_caller where xen_livepatch_trace_caller serves as a trampoline for saving registers before calling callback functions. Callback functions receive two arguments: ip: Address of the traced function parent_ip: Address where the traced function was called One can request the feature by specifying the section for struct livepatch_func as .livepatch.traces. Signed-off-by: Ryo Takakura --- xen/arch/arm/Kconfig | 13 +++++ xen/arch/arm/arch.mk | 3 ++ xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/insn.c | 5 ++ xen/arch/arm/arm64/livepatch-asm.S | 68 +++++++++++++++++++++++++++ xen/arch/arm/arm64/livepatch.c | 34 ++++++++++++++ xen/arch/arm/include/asm/arm64/insn.h | 1 + xen/common/Kconfig | 3 ++ xen/common/livepatch.c | 68 +++++++++++++++++++++++++-- xen/include/xen/livepatch.h | 8 ++++ xen/include/xen/livepatch_payload.h | 7 +-- 11 files changed, 205 insertions(+), 6 deletions(-) create mode 100644 xen/arch/arm/arm64/livepatch-asm.S diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index b9c5c40678..37fdbcc416 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -286,6 +286,19 @@ config PCI_PASSTHROUGH help This option enables PCI device passthrough +config ARM64_PATCHABLE_FUNCTION_ENTRY + bool "Reserve two NOPs at function entry for tracing" + depends on ARM_64 && LIVEPATCH && $(cc-option,-fpatchable-function-entry=2) + select HAS_LIVEPATCH_TRACE + default n + help + This option compiles Xen with -fpatchable-function-entry=2, which + reserves two NOP instructions at the beginning of functions. The NOPs + will be livepatched with a branch instruction to callback functions + registered by user. + + Enable this to use livepatch tracing feature. + endmenu menu "ARM errata workaround via the alternative framework" diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk index dea8dbd18a..940f1217c4 100644 --- a/xen/arch/arm/arch.mk +++ b/xen/arch/arm/arch.mk @@ -19,6 +19,9 @@ endif CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc $(call cc-option-add,CFLAGS-$(CONFIG_ARM_64),CC,-mno-outline-atomics) +# Reserve entries for livepatch tracing +CFLAGS-$(CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY) += -fpatchable-function-entry=2 + ifneq ($(filter command line environment,$(origin CONFIG_EARLY_PRINTK)),) $(error You must use 'make menuconfig' to enable/disable early printk now) endif diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile index 6491c5350b..7f52b10e66 100644 --- a/xen/arch/arm/arm64/Makefile +++ b/xen/arch/arm/arm64/Makefile @@ -12,6 +12,7 @@ obj-y += entry.o obj-y += head.o obj-y += insn.o obj-$(CONFIG_LIVEPATCH) += livepatch.o +obj-$(CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY) += livepatch-asm.o obj-y += smc.o obj-y += smpboot.o obj-$(CONFIG_ARM64_SVE) += sve.o sve-asm.o diff --git a/xen/arch/arm/arm64/insn.c b/xen/arch/arm/arm64/insn.c index 6b97a84ba7..dc3ddc6351 100644 --- a/xen/arch/arm/arm64/insn.c +++ b/xen/arch/arm/arm64/insn.c @@ -218,6 +218,11 @@ u32 __kprobes aarch64_insn_gen_nop(void) return aarch64_insn_gen_hint(AARCH64_INSN_HINT_NOP); } +u32 aarch64_insn_gen_move_reg(uint32_t rd, uint32_t rm) +{ + return 0xaa0003e0 | (rm << 16) | rd; +} + /* * Decode the imm field of a branch, and return the byte offset as a * signed value (so it can be used when computing a new branch diff --git a/xen/arch/arm/arm64/livepatch-asm.S b/xen/arch/arm/arm64/livepatch-asm.S new file mode 100644 index 0000000000..4f94e791a3 --- /dev/null +++ b/xen/arch/arm/arm64/livepatch-asm.S @@ -0,0 +1,68 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * xen/arch/arm/arm64/livepatch-asm.S + * + * Trampoline for livepatch tracer. + * + * If livepatch tracer is enabled, function entries are placed + * with two NOPs. arch_livepatch_apply_trace() will be livepatching + * those NOPs to: + * + * mov x9, x30 + * bl xen_livepatch_trace_caller + * + * x9 = traced function's original LR + * x30 = traced function + 8 + */ +FUNC(xen_livepatch_trace_caller) + /* + * Registers to save/restore: + * + * x0-x8 Function arguments + * x9 Original LR + * x29 Original FP + * x30 PC to return + */ + sub sp, sp, #96 + + /* Save function arguments */ + stp x0, x1, [sp, #0] + stp x2, x3, [sp, #16] + stp x4, x5, [sp, #32] + stp x6, x7, [sp, #48] + str x8, [sp, #64] + + /* Save LR, FP, PC */ + str x9, [sp, #72] + str x29, [sp, #80] + str x30, [sp, #88] + + /* + * xen_livepatch_trace_dispatcher(ip, parent_ip) + * + * ip: Address of the traced function. + * parent_ip: Address where the traced function was called. + */ + sub x0, x30, #8 + mov x1, x9 + bl xen_livepatch_trace_dispatcher + + /* Restore function arguments */ + ldp x0, x1, [sp, #0] + ldp x2, x3, [sp, #16] + ldp x4, x5, [sp, #32] + ldp x6, x7, [sp, #48] + ldr x8, [sp, #64] + + /* Restore FP, LR, PC */ + ldr x29, [sp, #80] + ldr x30, [sp, #72] + ldr x9, [sp, #88] + + /* Restore SP */ + add sp, sp, #96 + + /* ret x9 */ + .inst 0xd65f0120 + sb +END(xen_livepatch_trace_caller) diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c index 39159ba8b5..17753f4463 100644 --- a/xen/arch/arm/arm64/livepatch.c +++ b/xen/arch/arm/arm64/livepatch.c @@ -14,6 +14,10 @@ #include #include +#ifdef CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY +extern void xen_livepatch_trace_caller(void); +#endif + void arch_livepatch_apply(const struct livepatch_func *func, struct livepatch_fstate *state) { @@ -492,6 +496,36 @@ int arch_livepatch_perform_rela(struct livepatch_elf *elf, return -EINVAL; } +#ifdef CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY +void arch_livepatch_apply_trace(const struct livepatch_func *trace) +{ + uint32_t *new_ptr; + uint32_t insns[2]; + + new_ptr = trace->old_addr - (void *)_start + vmap_of_xen_text; + + insns[0] = aarch64_insn_gen_move_reg(9, 30); /* mov x9, lr */ + insns[1] = aarch64_insn_gen_branch_imm((unsigned long)trace->old_addr + ARCH_PATCH_INSN_SIZE, + (unsigned long)xen_livepatch_trace_caller, + AARCH64_INSN_BRANCH_LINK); + + memcpy(new_ptr, insns, sizeof(insns)); + clean_and_invalidate_dcache_va_range(new_ptr, sizeof(insns)); +} + +void arch_livepatch_revert_trace(const struct livepatch_func *trace) +{ + void *new_ptr = trace->old_addr - (void *)_start + vmap_of_xen_text; + uint32_t insns[2] = { + aarch64_insn_gen_nop(), + aarch64_insn_gen_nop(), + }; + + memcpy(new_ptr, insns, sizeof(insns)); + clean_and_invalidate_dcache_va_range(new_ptr, sizeof(insns)); +} +#endif /* CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY */ + /* * Local variables: * mode: C diff --git a/xen/arch/arm/include/asm/arm64/insn.h b/xen/arch/arm/include/asm/arm64/insn.h index ab290030ab..a83d8de0e4 100644 --- a/xen/arch/arm/include/asm/arm64/insn.h +++ b/xen/arch/arm/include/asm/arm64/insn.h @@ -82,6 +82,7 @@ u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr, enum aarch64_insn_branch_type type); u32 aarch64_insn_gen_hint(enum aarch64_insn_hint_op op); u32 aarch64_insn_gen_nop(void); +u32 aarch64_insn_gen_move_reg(uint32_t rd, uint32_t rm); /* Wrapper for common code */ static inline bool insn_is_branch_imm(u32 insn) diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 5b289e444f..7cf6937c2f 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -605,6 +605,9 @@ config TRACEBUFFER to be collected at run time for debugging or performance analysis. Memory and execution overhead when not active is minimal. +config HAS_LIVEPATCH_TRACE + bool + config LLC_COLORING bool "Last Level Cache (LLC) coloring" if EXPERT depends on HAS_LLC_COLORING diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 7515a040ad..70f601846f 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -198,6 +198,41 @@ static const char *cf_check livepatch_symbols_lookup( return n; } +#ifdef CONFIG_HAS_LIVEPATCH_TRACE +void __attribute__((patchable_function_entry(0, 0))) +xen_livepatch_trace_dispatcher(unsigned long ip, unsigned long parent_ip) +{ + const struct payload *data; + unsigned int i; + const struct livepatch_func *f; + + rcu_read_lock(&rcu_payload_lock); + + list_for_each_entry_rcu ( data, &payload_list, list ) + { + if ( data->state != LIVEPATCH_STATE_APPLIED || !data->is_trace ) + continue; + + for ( i = 0; i < data->nfuncs; ++i ) + { + f = &data->funcs[i]; + + if ( (unsigned long)f->old_addr != ip ) + continue; + + ASSERT(f->new_addr); + ((livepatch_trace_func_t)f->new_addr)((unsigned long)f->old_addr, parent_ip); + + goto out; + } + } + +out: + rcu_read_unlock(&rcu_payload_lock); +} + +#endif /* CONFIG_HAS_LIVEPATCH_TRACE */ + /* Lookup function's old address if not already resolved. */ static int resolve_old_address(struct livepatch_func *f, const struct livepatch_elf *elf) @@ -551,6 +586,9 @@ static int check_patching_sections(const struct livepatch_elf *elf) { unsigned int i; static const char *const names[] = { ELF_LIVEPATCH_FUNC, +#ifdef CONFIG_HAS_LIVEPATCH_TRACE + ELF_LIVEPATCH_TRACES, +#endif ELF_LIVEPATCH_LOAD_HOOKS, ELF_LIVEPATCH_UNLOAD_HOOKS, ELF_LIVEPATCH_PREAPPLY_HOOK, @@ -696,7 +734,14 @@ static int prepare_payload(struct payload *payload, struct virtual_region *region; int rc; - sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_FUNC); +#ifdef CONFIG_HAS_LIVEPATCH_TRACE + sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_TRACES); + payload->is_trace = !!sec; + + if ( !sec ) +#endif + sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_FUNC); + if ( sec ) { if ( !section_ok(elf, sec, sizeof(*payload->funcs)) ) @@ -721,6 +766,13 @@ static int prepare_payload(struct payload *payload, return -EOPNOTSUPP; } + if ( payload->is_trace && !f->new_addr ) + { + printk(XENLOG_ERR LIVEPATCH "%s: Trace new_addr is NULL\n", + elf->name); + return -EINVAL; + } + /* 'old_addr', 'new_addr', 'new_size' can all be zero. */ if ( !f->old_size ) { @@ -1460,7 +1512,12 @@ static int apply_payload(struct payload *data) continue; } - arch_livepatch_apply(func, state); +#ifdef CONFIG_HAS_LIVEPATCH_TRACE + if ( data->is_trace ) + arch_livepatch_apply_trace(func); + else +#endif + arch_livepatch_apply(func, state); state->applied = LIVEPATCH_FUNC_APPLIED; } @@ -1509,7 +1566,12 @@ int revert_payload(struct payload *data) continue; } - arch_livepatch_revert(func, state); +#ifdef CONFIG_HAS_LIVEPATCH_TRACE + if ( data->is_trace ) + arch_livepatch_revert_trace(func); + else +#endif + arch_livepatch_revert(func, state); state->applied = LIVEPATCH_FUNC_NOT_APPLIED; } diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h index 5dc8c61d37..ae34c938d6 100644 --- a/xen/include/xen/livepatch.h +++ b/xen/include/xen/livepatch.h @@ -26,6 +26,7 @@ struct xen_sysctl_livepatch_op; #define LIVEPATCH "livepatch: " /* ELF payload special section names. */ #define ELF_LIVEPATCH_FUNC ".livepatch.funcs" +#define ELF_LIVEPATCH_TRACES ".livepatch.traces" #define ELF_LIVEPATCH_DEPENDS ".livepatch.depends" #define ELF_LIVEPATCH_XEN_DEPENDS ".livepatch.xen_depends" #define ELF_BUILD_ID_NOTE ".note.gnu.build-id" @@ -86,6 +87,11 @@ void arch_livepatch_init(void); int arch_livepatch_verify_func(const struct livepatch_func *func); +typedef void (*livepatch_trace_func_t)(unsigned long ip, + unsigned long parent_ip); +void xen_livepatch_trace_dispatcher(unsigned long ip, + unsigned long parent_ip); + static inline unsigned int livepatch_insn_len(const struct livepatch_func *func, const struct livepatch_fstate *state) @@ -120,8 +126,10 @@ void arch_livepatch_revive(void); void arch_livepatch_apply(const struct livepatch_func *func, struct livepatch_fstate *state); +void arch_livepatch_apply_trace(const struct livepatch_func *trace); void arch_livepatch_revert(const struct livepatch_func *func, struct livepatch_fstate *state); +void arch_livepatch_revert_trace(const struct livepatch_func *trace); void arch_livepatch_post_action(void); void arch_livepatch_mask(void); diff --git a/xen/include/xen/livepatch_payload.h b/xen/include/xen/livepatch_payload.h index c6dc7cb5fa..3a81abe0de 100644 --- a/xen/include/xen/livepatch_payload.h +++ b/xen/include/xen/livepatch_payload.h @@ -52,9 +52,10 @@ struct payload { size_t ro_size; /* .. and its size (if any). */ unsigned int pages; /* Total pages for [text,rw,ro]_addr */ struct list_head applied_list; /* Linked to 'applied_list'. */ - const struct livepatch_func *funcs; /* The array of functions to patch. */ - struct livepatch_fstate *fstate; /* State of patched functions. */ - unsigned int nfuncs; /* Nr of functions to patch. */ + const struct livepatch_func *funcs; /* The array of functions to patch or trace. */ + struct livepatch_fstate *fstate; /* State of patched/traced functions. */ + unsigned int nfuncs; /* Nr of functions to patch or trace. */ + bool is_trace; /* Is a trace payload. */ const struct livepatch_symbol *symtab; /* All symbols. */ const char *strtab; /* Pointer to .strtab. */ struct virtual_region region; /* symbol, bug.frame patching and -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:54:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:54:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458891.1670970 (Exim 4.92) (envelope-from ) id 1xK7I9-00083o-3R; Fri, 23 Oct 2026 04:54:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458891.1670970; Fri, 23 Oct 2026 04:54: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 1xK7I9-00083h-03; Fri, 23 Oct 2026 04:54:09 +0000 Received: by outflank-mailman (input) for mailman id 1458891; Fri, 23 Oct 2026 04:54:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7I6-00082p-IA for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:54:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7I5-00CysQ-VH for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:54:05 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae86c-e002-0a2a0a5209dd-0a2a4508bb80-4 for ; Fri, 23 Oct 2026 06:54:05 +0200 Received: from [52.101.125.122] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adae86b-f659-0a2a45080019-34657d7a5bce-3 for ; Fri, 23 Oct 2026 06:54:05 +0200 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYYP286MB1715.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:fd::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 04:54:01 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.016; Fri, 23 Oct 2026 04:54: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=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=hBiw4vR+DAgUd7jTENUklIfb8beVK0JJ9JwIY+mrYTBOl/oi2RgdsPvig8om9l+UMEPlT6P5b2Rb0piVrBxn4j7zZ/qYfzeqmP3GTiD9I0ZBDoMjX546IRLy0Nq5t0J/6x8kL74OYP1EFMcnaKmJ8WkQw6jmPMyslMk06S70sF26U3FjkN9M01/TYzHTTpDtONdkQmjlINey8w4RUSIUc6XW402UxDlmqSMgJ6Gr9pJOf7C6bcD2fYXIVXX9LvT0E200L+lUIm1yDCiV+SWMdzS03wQYoVONQzE8sGhzVvz6yBqjKyFAgoWMd193k0RZGV8NrgsqnJVtSBsvGNDAlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xAdKilPb0/9LuUkjGbAwn7u5vPJDH2Al5yQD43o4oA0=; b=h5uehEbZlMj0k/8afK7sLPPQxuAucddfpL8fbA8utBVj2nLtFPwImWCw3Q61RxLeJm9M3dKYXm1RGWg5JtVZ9lkW3BMdv4kqmkct9bE3gSrubY7FibfSMr4M9UPDQYV2PbDtqq3yqS8hPvmBm0Wjo8qNFr22tv5l6LyUSR1WAgwL1q9sg+XSMCLnfff/pkMgUO6OTekJWT0g1kRi3+cKFzrZ1r67oLacitM+3S1WSJCsJP4/GHf08EyVbcXxfDk+0ZlZr1FbLwg6Sk4g24wxCwacBgvbEU5R0CQW+bR5b4+LjdAMQ2L5bxPFIcQZiH8NV6uxOhOKz404SDgSUHkIkQ== 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=xAdKilPb0/9LuUkjGbAwn7u5vPJDH2Al5yQD43o4oA0=; b=L8hXsUSNH3iC5wM/UiWVsiVYTNgHvn9odn8Psj1TQfJT08XHwU0vQlAflQ8axWVHol3gubSoVPfnwoQ7Qt+ECdH7vXEWTNMGCzfxyDAOsu5+caHb9Vs8iay2rGgnGmoeOugMjUU4bJIcjmombtF7kaH0QbUvLeFU5fwT21jcowc= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: xen-devel@lists.xenproject.org Cc: roger@xenproject.org, ross.lagerwall@citrix.com, Ryo Takakura Subject: [RFC 2/5] xen/livepatch: Allow tracers to schedule livepatch Date: Fri, 23 Oct 2026 13:53:46 +0900 Message-Id: <20261023045346.164171-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20261023044809.162759-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYWPR01CA0002.jpnprd01.prod.outlook.com (2603:1096:400:a9::7) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYYP286MB1715:EE_ X-MS-Office365-Filtering-Correlation-Id: adcc21f8-f078-41b9-b52d-08df30c1a7a5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|18002099003|22082099003|261022105027099003|261022075727099003|261009223027099003|261021123027099003|261021121427099003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: OjlHTy4xndyGBcuGnZKPdVfKNYblO+WWm2wB1dC3nH8OQwnIBbYDtB439hoyrMxGemAyErn1DF5/iQ7CeUXca9CWESApPcZ4s+cicLFAJT7q0Tb9IptwExq3COqf/3Dfo0xT+841/8o+VC+/kSenT8WvooaYmjjSX6+fr23rMZhDPrBNxJCQUcTSxeA61o+nseDL6O2tbQTUNEdfEY49oGyTz7XwqU/0SPNY8T//Q8y26s12oObo45F0HWh0rnKvxlERnRwS/xPLwHAdmKoxGFXNPN1Z6AY7ohT0vjBsBTN5/CbCZZNsSVuoXXUqXybz5+uvyDoMFlQkUdSZoXEqrKWhpBYZHnP7Gh+rrwjspVLqXkLkPurDTLbYQUSS8d9Aq8S+m3KGtwBmsoZw9GxVmZmNAMOYPuHTu9NL0DCOAukhFrRpFfAr1MCZpAhF40VNOPMJ5wOZwdVidhzx+kKiu59p+LuX/i/LH1QXBesIKnAwgKTPSwfuQy6QYC6HllXYBoNTwPfp7FbvA5VB7ooCiE/6wyKecQWkf+mn9YLFPOPujiFNI/kWTEkTWKOzxllto1eIAiE7M756enn6ssTNmTN+Sqrskm7mg2MFa3QSQwTXkWLsnttHqtzWEL4RygkQlxI/M+vHZRDjr7m22cnMHQfaXCmQ5yYNcgFqnzDUg6w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(18002099003)(22082099003)(261022105027099003)(261022075727099003)(261009223027099003)(261021123027099003)(261021121427099003)(10067099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?4KCOEWm6Gi0sMHUqN+14sRM+Ji6T4WypUqurLnsICu8fC64RWBCADnsMxIne?= =?us-ascii?Q?8xhkWIwQLSeLz72To8DZXsaNtE0RTNDN+spfanXtD7GZrhxD1MBvxzEgn9kf?= =?us-ascii?Q?cAOmeAy5hnQQr5JsED9F4mbqMsD3pdIuoFe3mnpQBEUBbIJeQSC5NP24wkyV?= =?us-ascii?Q?2noXPbY1YCzf4vYPB1cagnY6RhC/EQXbmjEY+wvuP5Dk2s0eAqN0cpPCJWnS?= =?us-ascii?Q?SNIdZwwnl91bMBaTsLVugp+4mzasiBk1H3EOe/5U8lKgAEmHa7lIatjMKgcu?= =?us-ascii?Q?bVknXE5wSGJwTJ0Mp+GGmdM1JnpWAU4Z+QiJqcyWv7zOKLiRHtcxazfe4rAg?= =?us-ascii?Q?EjkfnhwMs4modCvFR1vpdDFQ/fTm6g79xpmeUCcevx9s32SEueHgkLlEzW0l?= =?us-ascii?Q?IU5ZFW/+NitJfgGIHHJ7tMrXKvWg/LpzvDUSCXINTvR5mKvVSWyurMomaH5Y?= =?us-ascii?Q?y4sZtqjHXcnk92qIbRzGW3tTu1NpgFr+QoVeFW+mPe4GXV9BEyoM+ZXlIr7e?= =?us-ascii?Q?vEa4F7BcaaqoS/AvhJWN9a8VI2mfDl/wjJvUBZ/8j/ywyrSOrX+MfHBi9Ref?= =?us-ascii?Q?FFRtOEkvZ56PvkC/VjrQMEiDRkrXiE5hTVzZwu2sGqAiV93tZDq0aRmykk/P?= =?us-ascii?Q?5pGsSO0Y3pyziLPoJSE3QE1nHgz9Y8SNPIfzZSws2Y3BP2EyaXML9dZxt1nl?= =?us-ascii?Q?hi0U13BF3jhZNCteJm0mIvdbUHTmIZQ0uEjEpC+TJzBqEK1nTliAxCNYyw4f?= =?us-ascii?Q?RnvyHCG1zAIohhdupzupV4wULyvnN2MJYM8/2A+a7BN1qLbcKWWaqM9T603U?= =?us-ascii?Q?0L747kSIDf+Ra2xZxig6sG2RX2wYZu/fxfsDaw4dI/vuXSA1Nn9nAO7Byt+j?= =?us-ascii?Q?0+S+HKCpMEp+Oj629kYAs1QMKv9h7RaHJHKtO49MGh/TF2C/xH1GK4O1ildA?= =?us-ascii?Q?vk4kgSpojmAznfsS3rguAIZKUm9wXdOU56/j613an6FKvQMs1H5W0z/CdtP0?= =?us-ascii?Q?7eKZonuvNGG41ZjAb0zQhJS/UWvMmzXbaVszv0sOhdiSLgQQeIiSoFZ62xSD?= =?us-ascii?Q?vZFqKyFKyo5tACfL1M2operWOoqJsypWkURcpbxMOJQ5sNvoHKnebts8FISo?= =?us-ascii?Q?mlizuKWL+WAMpRt/fQXzN+CVgGs5CLQLOyaEtrPmu/ZE36bx2zMa4qP3GjM2?= =?us-ascii?Q?PonNGlOS8UGgwiFub29hoPMRHyCKAdw6lu/4ZdmG49OL/3216U4jt8x6dwHd?= =?us-ascii?Q?gyuk1IvjR+8+5Ec94tEporwzADDY31QAqkrZBpxJ6jryhnkx706pXA9XAXmZ?= =?us-ascii?Q?s60wAjP/6G7BS8OlvF8sRs9cuDtj6TTuXaoagY7B8yng9OdfON1a0o7dxoXy?= =?us-ascii?Q?6vOPrIY2QZpOFz2+baLLrRkPEYvWPitkcxAdQ1a7IM/dzyQkLgcyJvzgbetg?= =?us-ascii?Q?4EeT6iNhnOJee5NhLMHqYUVdURPFojGo/M8fRstKNLjBzi03+0pScstqehaX?= =?us-ascii?Q?ZuwhT5JyRwkoobJOf/Nuu0iohkrkSmjZBPHmgfvTqz5B8PSRA2kDcdAhx/xJ?= =?us-ascii?Q?yTn/mmy2PXfJUn25VtcewjE2H+PfnuERtK/5WOu2c9396RSlsi2IspsHrkTs?= =?us-ascii?Q?lKxKKa2McHjON5niGTOsXQq6kinFQ00IhzA5b5iVHwRNDGtsm6kUiWmQOhs0?= =?us-ascii?Q?1ofc/cdHQXWRbZf0DV3YiM36xexQXhwSK58X/qSuN3r2cVUEwtT2lvFlGUp3?= =?us-ascii?Q?tebzq4/Rzg=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: adcc21f8-f078-41b9-b52d-08df30c1a7a5 X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 04:54:01.0295 (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: UhF16uKx639UFTaGoaVxagUEPIAxjccRLrmZ8Bhna5vV9+lT+sJGUMAn8wZL+V2LQMubbBa+/ae5ruanJrP/CQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB1715 X-purgate-ID: tlsNG-c1860d/1792731245-D437587B-17EDFBCE/0/0 X-purgate-type: clean X-purgate-size: 3981 Tracers need to patch function entries without uploading a fully filled payload. Add TRACE_ON and TRACE_OFF for scheduling partially filled payloads from tracers. It lets tracers reuse the existing livepatch logic and keeps the payload uploaded by tracers separate from the ones uploaded by users. Signed-off-by: Ryo Takakura --- xen/common/livepatch.c | 60 ++++++++++++++++++++++++++++++++++++- xen/include/xen/livepatch.h | 5 ++++ 2 files changed, 64 insertions(+), 1 deletion(-) diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 70f601846f..a76403af59 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -49,6 +49,9 @@ static LIST_HEAD(applied_list); static unsigned int payload_cnt; static unsigned int payload_version = 1; +#define LIVEPATCH_TRACE_ON 100 +#define LIVEPATCH_TRACE_OFF 101 + /* Defines an outstanding patching action. */ struct livepatch_work { @@ -58,7 +61,7 @@ struct livepatch_work struct payload *data; /* The payload on which to act. */ volatile bool do_work; /* Signals work to do. */ volatile bool ready; /* Signals all CPUs synchronized. */ - unsigned int cmd; /* Action request: LIVEPATCH_ACTION_* */ + unsigned int cmd; /* Action request: LIVEPATCH_ACTION_* or LIVEPATCH_TRACE_* */ }; /* There can be only one outstanding patching action. */ @@ -1737,6 +1740,14 @@ static void livepatch_do_action(void) } break; + case LIVEPATCH_TRACE_ON: + rc = apply_payload(data); + break; + + case LIVEPATCH_TRACE_OFF: + rc = revert_payload(data); + break; + default: rc = -EINVAL; /* Make GCC5 happy. */ ASSERT_UNREACHABLE(); @@ -1823,6 +1834,51 @@ static int schedule_work(struct payload *data, uint32_t cmd, uint32_t timeout) return 0; } +int livepatch_schedule_trace_on(struct payload *payload, struct livepatch_func *func, unsigned long ip) +{ + void *old_addr; + int rc; + + spin_lock(&payload_lock); + if ( is_work_scheduled(payload) ) + { + rc = -EBUSY; + goto out; + } + + old_addr = func->old_addr; + func->old_addr = (void *)ip; + + payload->rc = -EAGAIN; + rc = schedule_work(payload, LIVEPATCH_TRACE_ON, 0); + if ( rc ) + func->old_addr = old_addr; + +out: + spin_unlock(&payload_lock); + + return rc; +} + +int livepatch_schedule_trace_off(struct payload *payload) +{ + int rc; + + spin_lock(&payload_lock); + if ( is_work_scheduled(payload) ) + { + spin_unlock(&payload_lock); + return -EBUSY; + } + + payload->rc = -EAGAIN; + rc = schedule_work(payload, LIVEPATCH_TRACE_OFF, 0); + + spin_unlock(&payload_lock); + + return rc; +} + static void cf_check tasklet_fn(void *unused) { this_cpu(work_to_do) = 1; @@ -1861,6 +1917,8 @@ static void noinline do_livepatch_work(void) ACTION(APPLY), ACTION(REVERT), ACTION(REPLACE), + [LIVEPATCH_TRACE_ON] = "TRACE_ON", + [LIVEPATCH_TRACE_OFF] = "TRACE_OFF", }; #undef ACTION unsigned int cpu = smp_processor_id(); diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h index ae34c938d6..1b927af8ee 100644 --- a/xen/include/xen/livepatch.h +++ b/xen/include/xen/livepatch.h @@ -140,6 +140,11 @@ struct payload; int revert_payload(struct payload *data); void revert_payload_tail(struct payload *data); +int livepatch_schedule_trace_on(struct payload *payload, + struct livepatch_func *func, + unsigned long ip); +int livepatch_schedule_trace_off(struct payload *payload); + #else /* !CONFIG_LIVEPATCH */ static inline int livepatch_op(struct xen_sysctl_livepatch_op *op) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:56:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:56:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458909.1670980 (Exim 4.92) (envelope-from ) id 1xK7Jy-000096-G1; Fri, 23 Oct 2026 04:56:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458909.1670980; Fri, 23 Oct 2026 04:56: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 1xK7Jy-00008z-Ah; Fri, 23 Oct 2026 04:56:02 +0000 Received: by outflank-mailman (input) for mailman id 1458909; Fri, 23 Oct 2026 04:56:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7Jw-00008r-CK for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:56:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7Jv-004l5c-PS for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:55:59 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae8b6-2eae-0a2a0a5409dd-0a2a4506824e-26 for ; Fri, 23 Oct 2026 06:55:59 +0200 Received: from [40.107.74.78] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adae8dc-195a-0a2a45060019-286b4a4e9860-3 for ; Fri, 23 Oct 2026 06:55:58 +0200 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYYP286MB5665.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:295::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 04:55:54 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.016; Fri, 23 Oct 2026 04:55: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=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=nT5uKeO5lUvrTCOto4F3AVpMiwmGSZuwiBzuS0prSfhUsLFfGqmCWc+giqZjHp7UOaCqlJGijDoCUE0qxDBUKvTwZ6espd6Ue8oDisvQppNgQjAKIvfrwnBOG0X5uKhaYSQOrcc0ZYauqFwxjrtjXYJcuQ/AvLuGAppnoWyJzT+tgRKl+L+Ey8s/caHR+ry1Q+SSxaTMSYtNVysVgrsF80aVjB37Yf76x8XZ5xIwND3p5qYN1tAgBsTKSHynMoyRhnQRKM34xLwszlU4h/jSQMwz5ue8RaZXZ0h9+nvTDyyqv7qD6yQ+I8TLiwjF2iBBhI0WmoEJOnOHuGHWrvhfJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rMDLJE58fBspR1Ur0/K2trhZGV+jlKomdmhc4KMqC34=; b=Clof73CyGbwPxZnf/I8qlvfs+MVAzorDgy9sJ6x4kZTQU+hEO3OQ05aJbpwKv4wu1h7eO6h3XWMdvtVi6hVOQ+bEtc0/gxSimewynXS18h3IvF6qyNX5tOnlMDzaeldtNhWdPLINU06eu9CuAjP1j8leU7Z/OSnOzQmz6OurzTqA3vXjWoekab+rUefTbST8QUMInEu+UI5MKJ1oxdSZeDkiEtOUyMpvYePUqQL9k7Yvj7xDlP0KZODwipP0zhGO27XZ8mJQvP2Uv7JyVlj+DaDJSmFkPcK3rVoHkSRC76TvfqHo5j0xB7MZOfn67XQR2247txLYnD+lcIaSFO/UDg== 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=rMDLJE58fBspR1Ur0/K2trhZGV+jlKomdmhc4KMqC34=; b=SIJ1aRCCXSWmGUn/4drpHOiXGeAbfdiOHfTOaeIBu4e63YqJZw8cU4o68ozouQNRDhraR55mm+RN5NCXkh5atPueTrBZxJRtFjsUncw0PnzPjIDsv+jAJBSQ1e5HuA8I3jiWCGKj2dpStFuvzBS8TLwLrce07vIrxGEv/UGwKX8= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, roger@xenproject.org, ross.lagerwall@citrix.com, jgross@suse.com, Ryo Takakura Subject: [RFC 3/5] xen/tracing: prepare a livepatch payload and its controling interface Date: Fri, 23 Oct 2026 13:55:43 +0900 Message-Id: <20261023045543.164658-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20261023044809.162759-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TY4P286CA0069.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:371::11) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYYP286MB5665:EE_ X-MS-Office365-Filtering-Correlation-Id: 17593c5d-b6b8-493e-fed2-08df30c1eb0f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|6133799003|18002099003|22082099003|3023799007|10067099003|5023799004|261009223027099003|261021123027099003|261022115727099003|261022113327099003|261021135927099003|261021121427099003|261022075727099003|261021133027099003|261021130227099003|261022105027099003|56012099006|260925022911599003|260925021311599003|260925021911599003; X-Microsoft-Antispam-Message-Info: nDO3I6MIMO6TOcf//tHaCQobfQtVJNh0FF0EZAUY4T+LE5WWpEBG+EkPpqSyqBysj3JYJU48E2XF6jDgjcqQhOD+pIcHLehFyntp9uOlpTo9hSyjBUAyacsF3K6NiFre4lLPPBip6ICUN//wX8oxgTYywjrLMByPQAxYhmBWxbn1d7Tc5dul+6rkCLLWU5eAfTyBLLTCFAQvXE70/V8eh7HFLu5h8Zp91LzfGk15u7ps3WXgZlnauG6oGdhQDU6+0WBhwtUn9TXtZi1In99kmgN0feWk1cfXBg/7Sdz776v8xSzi6g/t5Kno6ZEEut7FjL4YKUVmBdklsKHvPfXiXTXBCl31+UPxbvNPHuMWGtCkS4rq7M1saE36ZX5OlfL+uvbZbFkPqtdcOaHP8inWVUy7EjO314NHbdDvQzFnQDa5iLoZtixcgFBi+YnrUiw6IJfA5PrD9MN+k+5hH0k4LxeDqZlVO2JKmfWOQkMC1W7gaeHB/nJEuLYsRB0Tyni9k+QDZ5QoabT3SV36HHCB7fiBKpves4hshOuCe7Ger78Ac+XVYMj0HegEcHsqylGq9IYzLcS2GmIh5UXW0zsEzlhlCDyRd7b8xOPRaFkEt+gf1rAVlLZDn89yBo0lBeZnQLugvLlsmFmGiKg2AfPYqgXZhdDFssHlaBC2k8Khk4U= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(6133799003)(18002099003)(22082099003)(3023799007)(10067099003)(5023799004)(261009223027099003)(261021123027099003)(261022115727099003)(261022113327099003)(261021135927099003)(261021121427099003)(261022075727099003)(261021133027099003)(261021130227099003)(261022105027099003)(56012099006)(260925022911599003)(260925021311599003)(260925021911599003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?avrT0iujQZmbFJTYzITm9+H7RWtiMNDUXTbmaobkWNcUQaQ4Y44HL77Qo1lD?= =?us-ascii?Q?xLOh3zsws+nhUb1MbtzPSe6jLmCKsKmhhumG7Mv1D0zOz4w3qjWDmsvdx9Ky?= =?us-ascii?Q?6WM1KdPOpzhrxAK5k2/RmYHACo4aETNO2hKYI5a8XWTeBtpIKiw+tVIZ1nHk?= =?us-ascii?Q?E1GVO+V3VWq7rFFjvwxl8UGdWsfekydT8YUng522/LlUFbmRYEvfoE3C0HXo?= =?us-ascii?Q?hRnGUR4LxYrRMOcd+RI0V8aih0T970nOKfzPL1fCxWEKFr5+z9Beg45LTt16?= =?us-ascii?Q?5CkTF2IDJmpPtgJHw33IX+Qc0ATvWc95mZPerH/Libvhtn+acEjGGTsJRnd7?= =?us-ascii?Q?HLRivlVmQ/le8pgRK8nWI5ZmHH5C7MyrOHN10IcmH/KObX+BXUCXCmR3ocSs?= =?us-ascii?Q?l3FImukXVoHcw05FbWLTO5q8FY56L4BTsYM2Y4lZJ7ybPC3QJ6/bpTIGAPrr?= =?us-ascii?Q?o5kBW7yQiQNHns3KpeKn5mxIn6Hf668ZzdF5RugV5tstBCj3XpNb/gmlPjdn?= =?us-ascii?Q?8MulE2qQ9InjYuIVnY2daxQrE6M+tbWCwFYGycnHaTqWtErt7j6zZyuj8m7e?= =?us-ascii?Q?YPS0doOXlybBtx13SWmum1DPqROR1WeejypMIVTK45RtBfJ4Bo4Tb/Ggh71K?= =?us-ascii?Q?P2dwZRr5VDNNH9PxCq0VhB2+s8taKGBCckVrA3nMyFHJG40zKiCiV9wkhz/v?= =?us-ascii?Q?kaEZhehLwvwelXrQ5fOymOuSJTZ/K/S/3QU/ADeTNOUPM8L3V3kuVE9xmWIQ?= =?us-ascii?Q?9/8NThDpGRwHNsqJmGl6QhbZ/1ZJJMLf9nasbtOS2SPIx2cekLR5AA90j+6w?= =?us-ascii?Q?YplboZR91BvsRk4ewyiY6wCceA6+oNbw35PHN06YbstQIS9NncZqG+8g0ZgC?= =?us-ascii?Q?dG4P0unzFn6hRwMgBelugz46B0oRSA5Q19bf2MiWIEiGiGY1jILg2spVSQ6r?= =?us-ascii?Q?JuaiQyz5ppWdhzxpUolXqk7Ya6YfsVMkr/B9pUK2Iw3eTOr2PpoAmbCGzb3X?= =?us-ascii?Q?3YX/xO8iCexZckb/ZSRtR0hsY6OhkrJLQWoCH/Xljhw+grFp1c0YanB3XDYp?= =?us-ascii?Q?0Gd5VNNR7Ic6f4KKDwQoFDOxid9qShYSYnke4g+qeucniVxGUHlHvkZ0Jxpj?= =?us-ascii?Q?HdqTzfBvwkIqFzJAvCFin9MP2CvGVECISmUKbrVo+E0AifMkQRg2MJntBSKY?= =?us-ascii?Q?5FbNcaW4NONeFF6jHpZhX1J3XL32Lh5X9UNn8v0ZYYQyJdEmJsurcWeGOFgc?= =?us-ascii?Q?5z085ZdtYQ11kS2z7Av1CD4MEsg7s0i/Z+Og9U5nfVFzIQM7GS9h9Ks4xQP5?= =?us-ascii?Q?7aKRq2PNDVEQFgGOw/VDJ9KzFVymciScQdKfdqfS9pj7bRRDROzlzGfIWzRy?= =?us-ascii?Q?ve+jgEP4W3yW0hEaFqGQ3VTH2xI/8CI1uZTj4HCLxxMtIEcuzdpA3qq51xn/?= =?us-ascii?Q?/WkSoIe7wf3qoA/OKndjlpG3C1I3ciaRiS5sJohr+kORtvR5EHxaoTpID5iv?= =?us-ascii?Q?5E/hYORv59InrA8TJ881+xzLrV5NIYFAe6/SleG77Q6etXDrvzEzR8BwIvnj?= =?us-ascii?Q?0LWHjxh6JJn0kZA8l5TKIEQQR3cvbqHD6/oGthOXb/gL/fm1nbevBc3l5EVU?= =?us-ascii?Q?v29l6zyx7x/+B4YUTvVht6eimQWjSE0dRtlT3RZ69JJZX98A+gvRf3X+wSe2?= =?us-ascii?Q?axurg9bYpCCBajxRtP2FLqOwuomrpfE8IOkO/b/i+1jeEZLXcAyBWtSeYJQz?= =?us-ascii?Q?c60fK3TPpg=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 17593c5d-b6b8-493e-fed2-08df30c1eb0f X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 04:55:54.1452 (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: ltpb652elEbHlLMr3VM6f2TrRMIdHiZRzG0bWLfpsKtpsyPz6LC2LVgT2MA4C7YQdeg1dsuH1os5S1m4TuS1Hg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5665 X-purgate-ID: tlsNG-16d1c6/1792731359-1FACA77B-CC16EB0F/0/0 X-purgate-type: clean X-purgate-size: 26265 Introduce a shared livepatch payload that tracers can use to patch their target functions. The payload will be scheduled to the TRACE_ON/OFF path which will let tracers to request livepatch without satisfying the requirements for regular livepatch payloads. Every tracers are represented as struct tracer with optional callbacks for managing its state and output. Expose these operations through HypFS files under /tracing, following Linux ftrace's naming and usage: available_tracers: List registered tracers. current_tracer: Read or select the active tracer. available_functions: List functions available for tracing. set_function_filter: Read, select, or clear the target function. tracing_on: Read or change whether recording is enabled. trace: Read or clear output from tracers. Signed-off-by: Ryo Takakura --- xen/arch/arm/xen.lds.S | 5 + xen/common/Kconfig | 9 + xen/common/Makefile | 4 + xen/common/hypfs_trace.c | 741 ++++++++++++++++++++++++++++++++++ xen/common/livepatch.c | 9 + xen/include/xen/hypfs_trace.h | 42 ++ 6 files changed, 810 insertions(+) create mode 100644 xen/common/hypfs_trace.c create mode 100644 xen/include/xen/hypfs_trace.h diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index 613511390f..a85cab62af 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -61,6 +61,11 @@ SECTIONS *(.data.rel.ro) *(.data.rel.ro.*) + . = ALIGN(8); + __start_patchable_function_entries = .; + KEEP(*(__patchable_function_entries)) + __stop_patchable_function_entries = .; + . = ALIGN(4); __proc_info_start = .; *(.proc.info) diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 7cf6937c2f..ba118276f2 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -608,6 +608,15 @@ config TRACEBUFFER config HAS_LIVEPATCH_TRACE bool +config LIVEPATCH_TRACER + bool "Livepatch Tracer" + depends on HYPFS && HAS_LIVEPATCH_TRACE + default n + help + Enable dynamic tracers. Tracers attach/deattach their callback functions + using livepatch infrastructure. User can select the tracer and target + function through the HypFS interface exposed as /tracing. + config LLC_COLORING bool "Last Level Cache (LLC) coloring" if EXPERT depends on HAS_LLC_COLORING diff --git a/xen/common/Makefile b/xen/common/Makefile index f69d47d189..303016f250 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -79,6 +79,10 @@ obj-$(CONFIG_UBSAN) += ubsan/ obj-$(CONFIG_NEEDS_LIBELF) += libelf/ obj-$(CONFIG_LIBFDT) += libfdt/ +obj-$(CONFIG_LIVEPATCH_TRACER) += hypfs_trace.o +# Do not generate patchable entries for the tracer functions. +$(obj)/hypfs_trace.o: CFLAGS-y += -fpatchable-function-entry=0,0 + CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(objtree)/)$(KCONFIG_CONFIG) $(obj)/config.gz: $(CONF_FILE) gzip -n -c $< >$@ diff --git a/xen/common/hypfs_trace.c b/xen/common/hypfs_trace.c new file mode 100644 index 0000000000..d9e06e092e --- /dev/null +++ b/xen/common/hypfs_trace.c @@ -0,0 +1,741 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define MAX_TRACER_SIZE 100 + +static LIST_HEAD(tracer_list); + +/* + * Only one tracer callback can be registered at a time, targeting a + * single function. Multiple callbacks and multiple target functions + * are not currently supported. + */ +static bool trace_callback_registered; +static DEFINE_SPINLOCK(trace_callback_lock); + +/* Table of patchable functions generated by -fpatchable-function-entry. */ +extern const unsigned long __start_patchable_function_entries[]; +extern const unsigned long __stop_patchable_function_entries[]; + +/* + * .old_addr holds the address of the target function. + * .new_addr holds the address of the selected tracer's callback. + */ +static struct livepatch_func global_trace_func; + +static struct livepatch_fstate global_trace_fstate = { + .applied = LIVEPATCH_FUNC_NOT_APPLIED, +}; + +/* Nop tracer is the default tracer */ +static unsigned int cf_check nop_get_trace_size(struct trace_context *tr) +{ + return sizeof("# tracer: nop\n"); +} + +static size_t cf_check nop_print_trace(struct trace_context *tr, char *buf, size_t size) +{ + return scnprintf(buf, size, "# tracer: nop\n"); +} + +static struct tracer nop_tracer = { + .name = "nop", + .get_trace_size = nop_get_trace_size, + .print_trace = nop_print_trace, +}; + +/* + * Payload used by tracers for scheduling livepatch. + * + * It describes the target patch site through global_trace_func, + * with its patching state tracked by global_trace_fstate. + */ +static struct payload global_trace_payload = { + .name = "function-trace", + .funcs = &global_trace_func, + .fstate = &global_trace_fstate, + .nfuncs = 1, + .is_trace = true, +}; + +/* + * Context tracking the selected tracer, recording state, + * and references to the payload and target function used for patching. + * + * Initially, the nop tracer is selected as default. + */ +static struct trace_context global_trace = { + .current_trace = &nop_tracer, + .payload = &global_trace_payload, + .func = &global_trace_func, + .tracing_on = false, +}; + +/* Trim HypFS inputs */ +static char *strim(char *s) +{ + char *end; + + while ( isspace(*s) ) + s++; + + end = s + strlen(s); + while ( end > s && isspace(end[-1]) ) + end--; + + *end = '\0'; + return s; +} + +static bool tracing_is_on(void) +{ + return global_trace.tracing_on; +} + +static int tracing_set_on(bool on) +{ + const struct tracer *tracer = global_trace.current_trace; + int rc = 0; + + if ( global_trace.tracing_on == on ) + return 0; + + if ( on ) + { + if ( tracer->start ) + rc = tracer->start(&global_trace); + } + else + { + if ( tracer->stop ) + rc = tracer->stop(&global_trace); + } + + if ( !rc ) + global_trace.tracing_on = on; + + return rc; +} + +void trace_dispatch_callbacks(unsigned long ip, unsigned long parent_ip) +{ + livepatch_trace_func_t callback; + + if ( !tracing_is_on() ) + return; + + if ( !trace_callback_registered ) + return; + + if ( !global_trace_func.old_addr ) + return; + + if ( (unsigned long)global_trace_func.old_addr != ip ) + return; + + callback = global_trace_func.new_addr; + callback((unsigned long)global_trace_func.old_addr, parent_ip); +} + +int trace_register_callback(livepatch_trace_func_t callback) +{ + int rc = 0; + + spin_lock(&trace_callback_lock); + + if ( trace_callback_registered ) + { + rc = -EEXIST; + goto out_unlock; + } + + trace_callback_registered = true; + global_trace_func.new_addr = callback; + + out_unlock: + spin_unlock(&trace_callback_lock); + + return rc; +} + +int trace_unregister_callback(void) +{ + int rc = 0; + + spin_lock(&trace_callback_lock); + + if ( !trace_callback_registered ) + { + rc = -ENOENT; + goto out_unlock; + } + + trace_callback_registered = false; + global_trace_func.new_addr = NULL; + +out_unlock: + spin_unlock(&trace_callback_lock); + + return rc; +} + +static bool is_patchable_function_entry(unsigned long addr) +{ + const unsigned long *p; + + for ( p = __start_patchable_function_entries; + p < __stop_patchable_function_entries; p++ ) + { + if ( *p == addr ) + return true; + } + + return false; +} + +static void get_patchable_function_entries(const unsigned long **start, + const unsigned long **stop) +{ + *start = __start_patchable_function_entries; + *stop = __stop_patchable_function_entries; +} + +static struct tracer *trace_find_tracer(const char *name) +{ + struct tracer *tracer; + + list_for_each_entry( tracer, &tracer_list, list ) + if ( !strcmp(tracer->name, name) ) + return tracer; + + return NULL; +} + +static int trace_set_tracer(const char *name) +{ + const struct tracer *prev = global_trace.current_trace; + const struct tracer *new; + int rc; + + new = trace_find_tracer(name); + if ( !new ) + return -EINVAL; + + if ( new == prev ) + return 0; + + if ( prev->reset ) + { + rc = prev->reset(&global_trace); + if ( rc ) + return rc; + } + + global_trace.current_trace = &nop_tracer; + + if ( new->init ) + { + rc = new->init(&global_trace); + if ( rc ) + return rc; + } + + global_trace.current_trace = new; + + return 0; +} + +static int trace_set_filter(const char *name) +{ + struct payload *payload = global_trace.payload; + unsigned long ip = 0; + size_t len = strlen(name); + int rc; + + if ( len ) + { + ip = symbols_lookup_by_name(name); + if ( !ip || !is_patchable_function_entry(ip) ) + return -EINVAL; + } + + /* Schedule removal of the current patch. */ + if ( global_trace_fstate.applied == LIVEPATCH_FUNC_APPLIED ) + { + /* The requested function is already patched. Nothing to change. */ + if ( (unsigned long)global_trace_func.old_addr == ip ) + return 0; + + rc = livepatch_schedule_trace_off(payload); + if ( rc ) + return rc; + + /* Removal has been scheduled. Clear the previous filter name. */ + global_trace.filter_name[0] = '\0'; + } + + /* Clear the filter if no target function was requested. */ + if ( !ip ) + { + /* + * Keep global_trace_func.old_addr since livepatching + * might be in flight. Only clear global_trace.filter_name + * which will effectively update /tracing/set_function_filter. + */ + global_trace.filter_name[0] = '\0'; + return 0; + } + + /* + * Schedule patching of the requested function. + * A previously scheduled removal may still be in flight, in which case + * livepatch_schedule_trace_on() returns -EBUSY and the user must retry. + */ + rc = livepatch_schedule_trace_on(payload, global_trace.func, ip); + if ( rc ) + return rc; + + strlcpy(global_trace.filter_name, name, sizeof(global_trace.filter_name)); + + return 0; +} + +static HYPFS_DIR_INIT(tracing_dir, "tracing"); + +/* + * /tracing/available_tracers + * Lists the names of all registered tracers. + */ +static unsigned int available_tracers_size(void) +{ + const struct tracer *tracer; + unsigned int size = 0; + + list_for_each_entry( tracer, &tracer_list, list ) + size += strlen(tracer->name) + 1; + + return size; +} + +static int cf_check available_tracers_read(const struct hypfs_entry *entry, + XEN_GUEST_HANDLE_PARAM(void) uaddr) +{ + const struct tracer *tracer; + unsigned int size = available_tracers_size(); + unsigned int pos = 0; + char *buf; + int rc = 0; + + buf = xmalloc_array(char, size); + if ( !buf ) + return -ENOMEM; + + list_for_each_entry( tracer, &tracer_list, list ) + { + unsigned int len = strlen(tracer->name); + + memcpy(buf + pos, tracer->name, len); + pos += len; + buf[pos++] = ' '; + } + + buf[pos - 1] = '\0'; + + if ( copy_to_guest(uaddr, buf, size) ) + rc = -EFAULT; + + xfree(buf); + + return rc; +} + +static unsigned int cf_check available_tracers_getsize(const struct hypfs_entry *entry) +{ + return available_tracers_size(); +} + +static const struct hypfs_funcs available_tracers_funcs = { + .enter = hypfs_node_enter, + .exit = hypfs_node_exit, + .read = available_tracers_read, + .write = hypfs_write_deny, + .getsize = available_tracers_getsize, + .findentry = hypfs_leaf_findentry, +}; + +static HYPFS_VARSIZE_INIT(available_tracers, XEN_HYPFS_TYPE_STRING, + "available_tracers", 0, &available_tracers_funcs); + +/* + * /tracing/current_tracer + * Print and select the active tracer. + */ +static int cf_check current_tracer_read(const struct hypfs_entry *entry, + XEN_GUEST_HANDLE_PARAM(void) uaddr) +{ + const char *name = global_trace.current_trace->name; + + return copy_to_guest(uaddr, name, strlen(name) + 1) ? -EFAULT : 0; +} + +static int cf_check current_tracer_write(struct hypfs_entry_leaf *leaf, + XEN_GUEST_HANDLE_PARAM(const_void) uaddr, + unsigned int ulen) +{ + char buf[MAX_TRACER_SIZE + 1]; + char *name; + + if ( ulen > MAX_TRACER_SIZE ) + return -EINVAL; + + if ( copy_from_guest(buf, uaddr, ulen) ) + return -EFAULT; + + buf[ulen] = '\0'; + name = strim(buf); + + if ( !*name ) + return -EINVAL; + + return trace_set_tracer(name); +} + +static unsigned int cf_check current_tracer_getsize(const struct hypfs_entry *entry) +{ + return strlen(global_trace.current_trace->name) + 1; +} + +static const struct hypfs_funcs current_tracer_funcs = { + .enter = hypfs_node_enter, + .exit = hypfs_node_exit, + .read = current_tracer_read, + .write = current_tracer_write, + .getsize = current_tracer_getsize, + .findentry = hypfs_leaf_findentry, +}; + +static HYPFS_VARSIZE_INIT(current_tracer, XEN_HYPFS_TYPE_STRING, + "current_tracer", MAX_TRACER_SIZE + 2, ¤t_tracer_funcs); + +/* + * /tracing/available_functions + * Lists the names of functions whose entries can be patched for tracing. + */ +static int cf_check available_functions_read(const struct hypfs_entry *entry, + XEN_GUEST_HANDLE_PARAM(void) uaddr) +{ + const unsigned long *start, *stop, *p; + char namebuf[KSYM_NAME_LEN + 1]; + const char *name; + unsigned long size, offset; + int ret = 0; + char *buf; + unsigned int buf_size = 0; + unsigned int buf_pos = 0; + + get_patchable_function_entries(&start, &stop); + + for ( p = start; p < stop; p++ ) + { + name = symbols_lookup(*p, &size, &offset, namebuf); + if ( name ) + buf_size += strlen(name) + 1; + } + + if ( buf_size == 0 ) + { + char empty = '\0'; + if ( copy_to_guest(uaddr, &empty, 1) ) + return -EFAULT; + return 0; + } + + buf = xmalloc_array(char, buf_size); + if ( !buf ) + return -ENOMEM; + + for ( p = start; p < stop; p++ ) + { + name = symbols_lookup(*p, &size, &offset, namebuf); + if ( name ) + { + unsigned int len = strlen(name); + memcpy(buf + buf_pos, name, len); + buf[buf_pos + len] = '\n'; + buf_pos += len + 1; + } + } + buf[buf_pos - 1] = '\0'; + + if ( copy_to_guest(uaddr, buf, buf_size) ) + ret = -EFAULT; + + xfree(buf); + return ret; +} + +static unsigned int cf_check available_functions_getsize(const struct hypfs_entry *entry) +{ + const unsigned long *start, *stop, *p; + char namebuf[KSYM_NAME_LEN + 1]; + const char *name; + unsigned long size, offset; + unsigned int buf_size = 0; + + get_patchable_function_entries(&start, &stop); + + for ( p = start; p < stop; p++ ) + { + name = symbols_lookup(*p, &size, &offset, namebuf); + if ( name ) + buf_size += strlen(name) + 1; + } + + if ( buf_size == 0 ) + return 1; + + return buf_size ? buf_size : 1; +} + +static const struct hypfs_funcs available_functions_funcs = { + .enter = hypfs_node_enter, + .exit = hypfs_node_exit, + .read = available_functions_read, + .write = hypfs_write_deny, + .getsize = available_functions_getsize, + .findentry = hypfs_leaf_findentry, +}; + +static HYPFS_VARSIZE_INIT(available_functions, XEN_HYPFS_TYPE_STRING, + "available_functions", 0, &available_functions_funcs); + +/* + * /tracing/set_function_filter + * Print and select the target function. + */ +static int cf_check set_function_filter_read(const struct hypfs_entry *entry, + XEN_GUEST_HANDLE_PARAM(void) uaddr) +{ + const char *name = global_trace.filter_name; + + return copy_to_guest(uaddr, name, strlen(name) + 1) ? -EFAULT : 0; +} + +static int cf_check set_function_filter_write(struct hypfs_entry_leaf *leaf, + XEN_GUEST_HANDLE_PARAM(const_void) uaddr, + unsigned int ulen) +{ + char buf[KSYM_NAME_LEN + 1]; + char *name; + + if ( ulen > KSYM_NAME_LEN ) + return -EINVAL; + + if ( copy_from_guest(buf, uaddr, ulen) ) + return -EFAULT; + + buf[ulen] = '\0'; + name = strim(buf); + + return trace_set_filter(name); +} + +static unsigned int cf_check set_function_filter_getsize(const struct hypfs_entry *entry) +{ + return strlen(global_trace.filter_name) + 1; +} + +static const struct hypfs_funcs set_function_filter_funcs = { + .enter = hypfs_node_enter, + .exit = hypfs_node_exit, + .read = set_function_filter_read, + .write = set_function_filter_write, + .getsize = set_function_filter_getsize, + .findentry = hypfs_leaf_findentry, +}; + +static HYPFS_VARSIZE_INIT(set_function_filter, XEN_HYPFS_TYPE_STRING, + "set_function_filter", KSYM_NAME_LEN + 1, &set_function_filter_funcs); + +/* + * /tracing/tracing_on + * Enable or disable tracing by writing 1 or 0. + */ +static int cf_check tracing_on_read(const struct hypfs_entry *entry, + XEN_GUEST_HANDLE_PARAM(void) uaddr) +{ + char buf[] = "0"; + + buf[0] = global_trace.tracing_on ? '1' : '0'; + + return copy_to_guest(uaddr, buf, sizeof(buf)) ? -EFAULT : 0; +} + +static int cf_check tracing_on_write(struct hypfs_entry_leaf *leaf, + XEN_GUEST_HANDLE_PARAM(const_void) uaddr, + unsigned int ulen) +{ + char buf[sizeof("0\n") + 1]; + char *enabled; + + if ( ulen > sizeof("0\n") ) + return -EINVAL; + + if ( copy_from_guest(buf, uaddr, ulen) ) + return -EFAULT; + + buf[ulen] = '\0'; + enabled = strim(buf); + + if ( strlen(enabled) != 1 || (enabled[0] != '0' && enabled[0] != '1') ) + return -EINVAL; + + return tracing_set_on(enabled[0] == '1'); +} + +static unsigned int cf_check tracing_on_getsize(const struct hypfs_entry *entry) +{ + return sizeof("0"); +} + +static const struct hypfs_funcs tracing_on_funcs = { + .enter = hypfs_node_enter, + .exit = hypfs_node_exit, + .read = tracing_on_read, + .write = tracing_on_write, + .getsize = tracing_on_getsize, + .findentry = hypfs_leaf_findentry, +}; + +static HYPFS_VARSIZE_INIT(tracing_on, XEN_HYPFS_TYPE_STRING, + "tracing_on", sizeof("0\n"), &tracing_on_funcs); + +/* + * /tracing/trace + * Print the output from the current tracer. + */ +static unsigned int cf_check trace_getsize(const struct hypfs_entry *entry) +{ + const struct tracer *tracer = global_trace.current_trace; + unsigned int size; + + if ( !tracer->get_trace_size || !tracer->print_trace ) + return sizeof(""); + + size = tracer->get_trace_size(&global_trace); + + return size ? size : sizeof(""); +} + +static int cf_check trace_read(const struct hypfs_entry *entry, + XEN_GUEST_HANDLE_PARAM(void) uaddr) +{ + const struct tracer *tracer = global_trace.current_trace; + unsigned int size; + char *buf; + int rc = 0; + + if ( tracing_is_on() ) + return -EBUSY; + + if ( !tracer->get_trace_size || !tracer->print_trace ) + return copy_to_guest(uaddr, "", sizeof("")) ? -EFAULT : 0; + + size = tracer->get_trace_size(&global_trace); + if ( !size ) + return copy_to_guest(uaddr, "", sizeof("")) ? -EFAULT : 0; + + buf = xzalloc_array(char, size); + if ( !buf ) + return -ENOMEM; + + tracer->print_trace(&global_trace, buf, size); + + if ( copy_to_guest(uaddr, buf, size) ) + rc = -EFAULT; + + xfree(buf); + + return rc; +} + +static int cf_check trace_write(struct hypfs_entry_leaf *leaf, + XEN_GUEST_HANDLE_PARAM(const_void) uaddr, + unsigned int ulen) +{ + const struct tracer *tracer = global_trace.current_trace; + + if ( tracing_is_on() ) + return -EBUSY; + + if ( !tracer->clear_trace ) + return 0; + + return tracer->clear_trace(&global_trace); +} + +static const struct hypfs_funcs trace_funcs = { + .enter = hypfs_node_enter, + .exit = hypfs_node_exit, + .read = trace_read, + .write = trace_write, + .getsize = trace_getsize, + .findentry = hypfs_leaf_findentry, +}; + +static HYPFS_VARSIZE_INIT(trace, XEN_HYPFS_TYPE_STRING, "trace", sizeof("0\n"), &trace_funcs); + +int __init trace_register_tracer(struct tracer *tracer) +{ + if ( !tracer->name ) + return -EINVAL; + + if ( trace_find_tracer(tracer->name) ) + return -EEXIST; + + list_add_tail(&tracer->list, &tracer_list); + + return 0; +} + +static void __init initialize_hypfs_trace(void) +{ + int rc; + + rc = trace_register_tracer(&nop_tracer); + BUG_ON(rc); + + hypfs_string_set_reference(¤t_tracer, ""); + hypfs_string_set_reference(&available_tracers, ""); + hypfs_string_set_reference(&available_functions, ""); + hypfs_string_set_reference(&set_function_filter, ""); + hypfs_string_set_reference(&tracing_on, ""); + hypfs_string_set_reference(&trace, ""); + + hypfs_add_dir(&hypfs_root, &tracing_dir, true); + hypfs_add_leaf(&tracing_dir, &available_tracers, true); + hypfs_add_leaf(&tracing_dir, ¤t_tracer, true); + hypfs_add_leaf(&tracing_dir, &available_functions, true); + hypfs_add_leaf(&tracing_dir, &set_function_filter, true); + hypfs_add_leaf(&tracing_dir, &tracing_on, true); + hypfs_add_leaf(&tracing_dir, &trace, true); +} + +static int __init cf_check hypfs_trace_init(void) +{ + initialize_hypfs_trace(); + + return 0; +} +__initcall(hypfs_trace_init); diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index a76403af59..352a2df62c 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -26,6 +26,10 @@ #include #include +#ifdef CONFIG_LIVEPATCH_TRACER +#include +#endif + #include #include @@ -232,6 +236,11 @@ xen_livepatch_trace_dispatcher(unsigned long ip, unsigned long parent_ip) out: rcu_read_unlock(&rcu_payload_lock); + +#ifdef CONFIG_LIVEPATCH_TRACER + /* Call tracer callbacks. */ + trace_dispatch_callbacks(ip, parent_ip); +#endif } #endif /* CONFIG_HAS_LIVEPATCH_TRACE */ diff --git a/xen/include/xen/hypfs_trace.h b/xen/include/xen/hypfs_trace.h new file mode 100644 index 0000000000..11c4bba491 --- /dev/null +++ b/xen/include/xen/hypfs_trace.h @@ -0,0 +1,42 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef __XEN_HYPFS_TRACE_H__ +#define __XEN_HYPFS_TRACE_H__ + +#include +#include +#include +#include +#include + +struct payload; +struct tracer; + +/* State tracking the selected tracer and target function */ +struct trace_context { + const struct tracer *current_trace; /* Currently selected tracer */ + struct payload *payload; /* Payload used for uploading tracers */ + struct livepatch_func *func; /* Target function and tracer's callback address */ + bool tracing_on; /* Whether callbacks may record events */ + char filter_name[KSYM_NAME_LEN]; /* Name of the target function */ +}; + +/* Operations registered by each tracer */ +struct tracer { + const char *name; /* Name of the tracer */ + int (*init)(struct trace_context *tr); /* Called when this tracer is selected */ + int (*reset)(struct trace_context *tr); /* Called when this tracer is being deselected */ + int (*start)(struct trace_context *tr); /* Called before recording gets enabled */ + int (*stop)(struct trace_context *tr); /* Called before recording gets disabled */ + int (*clear_trace)(struct trace_context *tr); /* Clear recorded events at the user's request */ + unsigned int (*get_trace_size)(struct trace_context *tr); /* Required output buffer size */ + size_t (*print_trace)(struct trace_context *tr, char *buf, size_t size); /* Format recorded output */ + struct list_head list; /* Linked to 'tracer_list' */ +}; + +int __init trace_register_tracer(struct tracer *tracer); + +int trace_register_callback(livepatch_trace_func_t callback); +int trace_unregister_callback(void); +void trace_dispatch_callbacks(unsigned long ip, unsigned long parent_ip); + +#endif /* __XEN_HYPFS_TRACE_H__ */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:57:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:57:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458919.1670988 (Exim 4.92) (envelope-from ) id 1xK7L9-0000gC-Ru; Fri, 23 Oct 2026 04:57:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458919.1670988; Fri, 23 Oct 2026 04: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 1xK7L9-0000g4-OM; Fri, 23 Oct 2026 04:57:15 +0000 Received: by outflank-mailman (input) for mailman id 1458919; Fri, 23 Oct 2026 04:57:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7L7-0000fu-O8 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:57:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7L6-00CzBS-QV for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:57:12 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae922-e002-0a2a0a5209dd-0a2a45069c7e-4 for ; Fri, 23 Oct 2026 06:57:12 +0200 Received: from [40.107.74.100] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adae925-195a-0a2a45060019-286b4a6428b0-3 for ; Fri, 23 Oct 2026 06:57:11 +0200 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYYP286MB5665.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:295::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 04:57:08 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.016; Fri, 23 Oct 2026 04: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=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=vs61KkxE3lmS+y4WraoQ/Gpi6IGQ1kCnO6vFt/AC9Om4uMVbgK2KyY310i6GiE1dtDbPTyyhNwY/ojj8jeWMQYcTXF38Jad+0+Qn6zRIIg7Kdud0crUyKJKLNWaF38fQOeZfWCggPHTC/NZVPoiz7EZkLGsk8LINo9qjxP9NITVjIbpn0BNBRjEGgNzhw57Oq0Y+MNZ9nU9dt73hq+pTgw5UeT7UfAQfgGoN7NmCECAaAV9n4mL6hPhy+tVTywSw4b7m2OF5MUvJW4f5WYX5DcQq6LwVKQzFogUc1SIEjMGwwOoyWEl9Rpht1G2Rt6Hp80Wj13EwFdjGqhh1JN4XBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qnKv7oJzltLW6C26HaDuFk/xWeQEgKaGXCvC8U3iEFU=; b=AYUrWufR18zBiWjxonLtxk2jGCbrMmTQSQcODuK4JCSUg4XtDW+vyNyAXQi71GsdIy1eSLM1afbz9WfIvStd/OW27yfpmxuAt/BqKeT7XLnMojL10GklCcHohKnWp5UcyFxS4WN0XK0BIsIWK/4AWw6blGwx2xNe0RnJvUtIscJzHh69ShTjn3QuNGHRQVjHibf4T4F5a/9kV5Mns9K9oeZmVPy1IkYRZQLSANzj1aJCRuWXo0ufvxuuEl99zz8c44rmCdYnE5X890tNuG+oqdT7GSqciEqNHcVIi/OAw15ZXjEF7tnW0HftriinDxmpy+v1V0RwGpwkNqJYdapX4A== 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=qnKv7oJzltLW6C26HaDuFk/xWeQEgKaGXCvC8U3iEFU=; b=JFGR5ZN5Y6KswXAdU+Is9bs+dd4jEMvOThItGPevB+5/2cEcAP38+cuF/jU45ooDVrmnjpf0IeSqC3yM9vBGF7KUfR/O3hIDuPrCoAL3QCfV8kKRnKOaVOVysAdLkyJTsx3F07aILpR5Xr0TQlm5UBifH3+tBEOEU75043RETQY= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura 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, Ryo Takakura Subject: [RFC 4/5] xen/tracing: Add a function tracer Date: Fri, 23 Oct 2026 13:56:55 +0900 Message-Id: <20261023045655.164966-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20261023044809.162759-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0033.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:29d::7) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYYP286MB5665:EE_ X-MS-Office365-Filtering-Correlation-Id: e5e9af30-b6ed-44d0-82d3-08df30c21750 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|18002099003|22082099003|10067099003|261009223027099003|261021121427099003|261022075727099003|261022105027099003|56012099006|260925022911599003|260925021311599003|260925021911599003; X-Microsoft-Antispam-Message-Info: /vybvP0qEK5lPKLIzNfDVoWN6dRufC4xq+hbBTUAlWoYtMK1AZwZKQvTb9X6xWAG3zRCftdUxcHxAuD5Ja9XWGECxka+YxJZLNsNBvjct1TV5mn7oPrctChlgq8wCrRCSx15KeFRIYZYdnq/mI6RJzYl35bTxui4IS1uoPfpWb72at59AmlsNR9wxj/lcWdbeZAOYxE1E3uwLLdoz6ZlX5KY/rFjstvdmATTMijF+SB2P8e1arQTD7TVuhAJN/2aRE9fY43+XR1gkkIjy0LcGr+oF/hJL996ShuJ6aVbEGA+E7GtWOtfJosY4hIFoS/Eebh1Y57A1VVesqKScAzImTtSFrg/CmS857GMC2HA8WK7PXXlAvB9rJgKCG58VZOCzHuq40ZWs2Carz8sTfpD/Ckd7LepC6RcyeYLOtClC1SKALflZ/SXpE2I5xvnwADVINpLlW7btgWu0I+bs4grJCcg5AZ3UrWcnMcKPSp89yaWVJCb3F73q3/tpXakG6XpxqbGD4+q/il5C0opHU5Hhc6WC1Wp8LtJ5apitAFXOJLLUCq6XxFcrcnIEsSf4JVgMNN+RQtA7D7EBhssLNoTUkDVrX41pK0OZcY/qOYzx9IMmwUlVhLTE0QfqGGCVFQh2nOyZm/siCGcsvsbqGmY4Xkw9HidT0C1LdZ39dJGlyA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(6133799003)(18002099003)(22082099003)(10067099003)(261009223027099003)(261021121427099003)(261022075727099003)(261022105027099003)(56012099006)(260925022911599003)(260925021311599003)(260925021911599003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ShdadNF6fsCkp0IjVJSbTxujHTzqyS85iAoObGcB9eG9HvsdhMvUFx5wgjnh?= =?us-ascii?Q?GECWjbKK8K+ucHDgELWZbeKTOxPBfQMLJfZ2GgTfHDCE/KUXfETHGdCp9/NI?= =?us-ascii?Q?6WjIXgynpo59XxLTcAqSpqjyS57Bz2HC6GSYLU2qHHGWpBDevEZnWSqI5MW4?= =?us-ascii?Q?kT+js6dSWsO5iSZaZ5DiyMu3oXkTCs1aI1SOYpQLR7lcmqcex6gLJf12nKXl?= =?us-ascii?Q?nqtG8GyXH8N3SNiYMVcKYaHaUWPAvB3YDiKfBL6kUh83mKd0/JdxkngkJgSK?= =?us-ascii?Q?izdw84F1SV179FzWLwV1QD7xif/K2wzCCMUmHfMyFXCWNniqrdA9Css6prtg?= =?us-ascii?Q?Djm53buDemAEAsFP83jkoNNjrpue2CO6w8kz32FEjVQ/HFROpWZZo0NL7oce?= =?us-ascii?Q?S5M9Qw6iICEkNRhJrVJo9sGzNR+vL0HOxP2dtitS+OeUMGCmvzbAtYXWFIXD?= =?us-ascii?Q?66aPPzlL05/9wJgkpl6Pqcwsn6H/wwnNp6yrcyTjCBT3mEmYYavpZo7uioy5?= =?us-ascii?Q?nQyl0hVLU5/0FsmNOJpU1It45EZUCp/KaUWdnWldsHxcykw7rMYapwNCIWxu?= =?us-ascii?Q?jN8bvnt2zmg+jMWU7f0I5UEgGkZjaF1lXLh6TNV20LIprCv6NxZiKLk8fDhL?= =?us-ascii?Q?Nm8kErL9Xvy4HF1HkV8DTkgCEvYr7J4KnY6usBpvE7m4nXQClCjlT3BqmqMb?= =?us-ascii?Q?eJ+oVWjHigbTdZiv2gjXiUg6SpFXuMCAk4D8t6eX4DQVxUrzBNeAiL10iP/d?= =?us-ascii?Q?1CWkjNR8zWNYHbN6xQjsWMzdg7X9tdr1IYnfqsXoVoYD7lN87U57gb0jr8TL?= =?us-ascii?Q?4Kk2/zJL4UB57mjSmm67tzLitl7dgIZR3JIWPL4CEuU2J+EMmJLwSwsEXsDG?= =?us-ascii?Q?J5Ue5RPXbF4zIw9bsLLlEg1XbTjWeYVzDh0mcfNQvViolNIGzXKjilCGWVcJ?= =?us-ascii?Q?XwPltGBR+Z4uoV/73QWEif7IWXjiyyplrgawqP+lezaC1BLDe+gCVEV8bW8k?= =?us-ascii?Q?g2GaOoEcA/xHnDPLBem0atl8Q94Nz+ICw5xwLq6BIYFeUU4mUf0xjxYsn/XI?= =?us-ascii?Q?XIPhF6n8JmFiskDXEjp4oUANhosGfHmEfTjKkuyIAHNTF5mf9nbJpw3tQRWi?= =?us-ascii?Q?apzFUDK4OV/IiOFKrp4/eFjMU+6sFI5IJJkuvC4Mb1vN5gm27QAK/N2gHWEp?= =?us-ascii?Q?+/Op2azY8bukVe55rfBVfYU0t7NGjbsSbN/2JBk4aVub0SLv6ddXGP2TTwNJ?= =?us-ascii?Q?fAF/YBc9vAMLEyma6ZBZUuz4dhab7D61ChVZG/Dps8FqRV4aUUkd717Kigea?= =?us-ascii?Q?dMnkxoS+bwenOhQpLYw9TMpgRnQpwgp2XOZT94FZn3WMFcavSSkBMWD5Zb3N?= =?us-ascii?Q?fW+2rwJmCMziwe/XLJjg+j9a8d5+wykTTG4GhNBmfKZuhg1nXdMZMAc2oDsM?= =?us-ascii?Q?zQZoXgWzvvJTi9PSc7tRBp4UjxHyyO4ni0ShKyhgAxVQeGNuc1AaXRKsDsAr?= =?us-ascii?Q?dxmL7Z5MX3S60wR5vXJZvc1WaYZVZTXHN3lM/JvGIEBWyUtaxrupvM1hhtJ+?= =?us-ascii?Q?ojp2ZsYb6XR1JLSiWd3juvmcK/+v/uQ2qOktc2NdPxNEC98zTZ54ZY0VEuVZ?= =?us-ascii?Q?sEMp6YA2GMKfXXywRimi3ng/k0DQhbDnIyYE9AEMEPema1u0Pwvw1d3VzFRR?= =?us-ascii?Q?R5TOhD6918ziceu0ytS+OhZ6WXI540LJH/P04OQopN9+oUT5jO2j6u87gi10?= =?us-ascii?Q?iryYFW7t5w=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: e5e9af30-b6ed-44d0-82d3-08df30c21750 X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 04:57:08.3537 (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: Z53L81driH+O7GunVu7RvDvsWzAIiV3G484T571yEe+r1FZqpk7GVzCBMbFFe2mMzFphHcUA6Ps/LCQNKop2Zw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5665 X-purgate-ID: tlsNG-16d1c6/1792731432-FD00977B-79E504D4/0/0 X-purgate-type: clean X-purgate-size: 11054 Add a function tracer which records calls to the selected function. Each record includes the timestamp, CPU ID, and domain associated with the call. ~$ xenhypfs cat /tracing/trace # tracer: function # # entries-in-buffer/entries-written: 5/5 #P:1 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> in-irq # || / _--=> preempt-depth # ||| / # DOMAIN/VCPU PCPU |||| TIMESTAMP FUNCTION # | | |||| | | d0/v0 [000] nnn 0 442.074071: xen_extra_version <-do_xen_version d0/v0 [000] nnn 0 443.160035: xen_extra_version <-do_xen_version d0/v0 [000] nnn 0 469.897195: xen_extra_version <-do_xen_version d0/v0 [000] nnn 0 471.295576: xen_extra_version <-do_xen_version d0/v0 [000] nnn 0 472.052187: xen_extra_version <-do_xen_version The tracer is inspired by Linux ftrace's function tracer. Signed-off-by: Ryo Takakura --- xen/common/Makefile | 2 + xen/common/function_trace.c | 274 ++++++++++++++++++++++++++++++++++++ 2 files changed, 276 insertions(+) create mode 100644 xen/common/function_trace.c diff --git a/xen/common/Makefile b/xen/common/Makefile index 303016f250..435423f694 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -80,8 +80,10 @@ obj-$(CONFIG_NEEDS_LIBELF) += libelf/ obj-$(CONFIG_LIBFDT) += libfdt/ obj-$(CONFIG_LIVEPATCH_TRACER) += hypfs_trace.o +obj-$(CONFIG_LIVEPATCH_TRACER) += function_trace.o # Do not generate patchable entries for the tracer functions. $(obj)/hypfs_trace.o: CFLAGS-y += -fpatchable-function-entry=0,0 +$(obj)/function_trace.o: CFLAGS-y += -fpatchable-function-entry=0,0 CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(objtree)/)$(KCONFIG_CONFIG) $(obj)/config.gz: $(CONF_FILE) diff --git a/xen/common/function_trace.c b/xen/common/function_trace.c new file mode 100644 index 0000000000..5dd4ccdec0 --- /dev/null +++ b/xen/common/function_trace.c @@ -0,0 +1,274 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define FUNCTION_TRACE_CTX_NORMAL 0 +#define FUNCTION_TRACE_CTX_IRQ (1U << 0) +#define FUNCTION_TRACE_CTX_IDLE (1U << 1) +#define FUNCTION_TRACE_CTX_IRQS_OFF (1U << 2) +#define FUNCTION_TRACE_CTX_RESCHED (1U << 3) +#define FUNCTION_TRACE_RECORD_TEXT_SIZE (2 * KSYM_NAME_LEN + 128) +#define FUNCTION_TRACE_BUFSIZE 256 + +static const char function_trace_header[] = + "#\n" + "# _-----=> irqs-off\n" + "# / _----=> need-resched\n" + "# | / _---=> in-irq\n" + "# || / _--=> preempt-depth\n" + "# ||| /\n" + "# DOMAIN/VCPU PCPU |||| TIMESTAMP FUNCTION\n" + "# | | |||| | |\n"; + +struct function_trace_record { + uint64_t timestamp; /* Timestamp of when the event occurred */ + unsigned long ip; /* The address of the traced function */ + unsigned long parent_ip; /* The address where the traced function was called */ + unsigned int pcpu; /* pCPU */ + domid_t domid; /* Domain ID */ + unsigned int vcpuid; /* vCPU */ + unsigned int context_flags; /* Execution context */ + unsigned int preempt_depth; /* Preempt count */ +}; + +struct function_trace_cpu_buffer { + struct function_trace_record records[FUNCTION_TRACE_BUFSIZE]; + unsigned int head; + uint64_t written; +}; + +struct buffer_iterator { + const struct function_trace_cpu_buffer *buffer; + unsigned int start; + unsigned int count; + unsigned int next; +}; + +static DEFINE_PER_CPU(struct function_trace_cpu_buffer, function_trace_buffer); +static DEFINE_PER_CPU(bool, function_trace_recursing); + +static void cf_check function_trace_callback(unsigned long ip, unsigned long parent_ip) +{ + struct function_trace_cpu_buffer *buf; + struct function_trace_record *rec; + unsigned int ctx = FUNCTION_TRACE_CTX_NORMAL; + unsigned long pending; + + if ( this_cpu(function_trace_recursing) ) + return; + + this_cpu(function_trace_recursing) = true; + + buf = &this_cpu(function_trace_buffer); + rec = &buf->records[buf->head]; + + rec->preempt_depth = preempt_count(); + + if ( !local_irq_is_enabled() ) + ctx |= FUNCTION_TRACE_CTX_IRQS_OFF; + + pending = softirq_pending(smp_processor_id()); + if ( pending & ((1UL << SCHEDULE_SOFTIRQ) | + (1UL << SCHED_SLAVE_SOFTIRQ)) ) + ctx |= FUNCTION_TRACE_CTX_RESCHED; + + rec->timestamp = NOW(); + rec->ip = ip; + rec->parent_ip = parent_ip; + rec->pcpu = smp_processor_id(); + + if ( in_irq() ) + ctx |= FUNCTION_TRACE_CTX_IRQ; + + if ( is_idle_vcpu(current) ) + ctx |= FUNCTION_TRACE_CTX_IDLE; + + rec->context_flags = ctx; + rec->domid = current->domain->domain_id; + rec->vcpuid = current->vcpu_id; + + buf->head = (buf->head + 1) % FUNCTION_TRACE_BUFSIZE; + buf->written++; + + this_cpu(function_trace_recursing) = false; +} + +static int cf_check function_tracer_clear(struct trace_context *tr) +{ + struct function_trace_cpu_buffer *buf; + unsigned int cpu; + + for_each_online_cpu ( cpu ) + { + buf = &per_cpu(function_trace_buffer, cpu); + buf->head = 0; + buf->written = 0; + } + + return 0; +} + +static int cf_check function_tracer_init(struct trace_context *tr) +{ + int rc; + + rc = function_tracer_clear(tr); + if ( rc ) + return rc; + + return trace_register_callback(function_trace_callback); +} + +static int cf_check function_tracer_reset(struct trace_context *tr) +{ + return trace_unregister_callback(); +} + +static void format_ip(char *buf, size_t size, unsigned long ip) +{ + const char *name; + unsigned long sym_size, offset; + char namebuf[KSYM_NAME_LEN + 1]; + + name = symbols_lookup(ip, &sym_size, &offset, namebuf); + if ( name ) + snprintf(buf, size, "%s", name); + else + snprintf(buf, size, "0x%lx", ip); +} + +static unsigned int cf_check function_tracer_get_trace_size(struct trace_context *tr) +{ + unsigned int size = sizeof(function_trace_header) + 128; + unsigned int cpu, count; + struct function_trace_cpu_buffer *buf; + + for_each_online_cpu ( cpu ) + { + buf = &per_cpu(function_trace_buffer, cpu); + count = min(buf->written, (uint64_t)FUNCTION_TRACE_BUFSIZE); + size += count * FUNCTION_TRACE_RECORD_TEXT_SIZE; + } + + return size; +} + +static size_t cf_check function_tracer_print_trace(struct trace_context *tr, char *buf, size_t size) +{ + struct buffer_iterator *iters; + unsigned int cpu, nr_iters = 0; + uint64_t entries = 0, written = 0; + size_t pos = 0; + + iters = xzalloc_array(struct buffer_iterator, nr_cpu_ids); + if ( !iters ) + return scnprintf(buf, size, "# unable to allocate trace iterators\n"); + + pos += scnprintf(buf + pos, size - pos, "# tracer: function\n#\n"); + + for_each_online_cpu ( cpu ) + { + const struct function_trace_cpu_buffer *cbuf = &per_cpu(function_trace_buffer, cpu); + struct buffer_iterator *iter = &iters[nr_iters++]; + + iter->buffer = cbuf; + iter->count = min(cbuf->written, (uint64_t)FUNCTION_TRACE_BUFSIZE); + iter->start = cbuf->written >= FUNCTION_TRACE_BUFSIZE ? cbuf->head : 0; + + entries += iter->count; + written += cbuf->written; + } + + pos += scnprintf(buf + pos, size - pos, + "# entries-in-buffer/entries-written: " + "%"PRIu64"/%"PRIu64" #P:%u\n", + entries, written, num_online_cpus()); + pos += scnprintf(buf + pos, size - pos, "%s", function_trace_header); + + while ( pos < size - 1 ) + { + const struct function_trace_record *rec = NULL; + unsigned int i, selected = 0; + char func_str[KSYM_NAME_LEN]; + char parent_str[KSYM_NAME_LEN]; + char vcpu_str[32]; + uint64_t seconds; + unsigned int useconds; + + for ( i = 0; i < nr_iters; i++ ) + { + const struct buffer_iterator *iter = &iters[i]; + const struct function_trace_record *next_rec; + unsigned int idx; + + if ( iter->next == iter->count ) + continue; + + idx = (iter->start + iter->next) % FUNCTION_TRACE_BUFSIZE; + next_rec = &iter->buffer->records[idx]; + + if ( !rec || next_rec->timestamp < rec->timestamp ) + { + rec = next_rec; + selected = i; + } + } + + if ( !rec ) + break; + + iters[selected].next++; + + format_ip(func_str, sizeof(func_str), rec->ip); + format_ip(parent_str, sizeof(parent_str), rec->parent_ip); + + seconds = rec->timestamp / 1000000000ULL; + useconds = (rec->timestamp % 1000000000ULL) / 1000; + + if ( rec->context_flags & FUNCTION_TRACE_CTX_IDLE ) + snprintf(vcpu_str, sizeof(vcpu_str), "idle"); + else + snprintf(vcpu_str, sizeof(vcpu_str), "d%u/v%u", + rec->domid, rec->vcpuid); + + pos += scnprintf(buf + pos, size - pos, + "%14s [%03u] %c%c%c%3u %13"PRIu64".%06u: %s <-%s\n", + vcpu_str, rec->pcpu, + rec->context_flags & FUNCTION_TRACE_CTX_IRQS_OFF ? 'y' : 'n', + rec->context_flags & FUNCTION_TRACE_CTX_RESCHED ? 'y' : 'n', + rec->context_flags & FUNCTION_TRACE_CTX_IRQ ? 'y' : 'n', + rec->preempt_depth, seconds, useconds, func_str, parent_str); + } + + xfree(iters); + + return pos; +} + +static struct tracer function_tracer = { + .name = "function", + .init = function_tracer_init, + .reset = function_tracer_reset, + .clear_trace = function_tracer_clear, + .get_trace_size = function_tracer_get_trace_size, + .print_trace = function_tracer_print_trace, +}; + +static int __init cf_check function_trace_init(void) +{ + return trace_register_tracer(&function_tracer); +} +__initcall(function_trace_init); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 04:58:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 04:58:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458923.1670997 (Exim 4.92) (envelope-from ) id 1xK7MN-0001XA-3y; Fri, 23 Oct 2026 04:58:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458923.1670997; Fri, 23 Oct 2026 04:58: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 1xK7MN-0001X3-19; Fri, 23 Oct 2026 04:58:31 +0000 Received: by outflank-mailman (input) for mailman id 1458923; Fri, 23 Oct 2026 04:58:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7ML-0001Vg-Ek for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 04:58:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7MK-004lKN-Rm for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:58:28 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adae96c-8faa-0a2a0a5109dd-0a2a4507bf10-8 for ; Fri, 23 Oct 2026 06:58:28 +0200 Received: from [52.101.228.79] (helo=OS0P286CU011.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adae972-b4ea-0a2a45070019-3465e44f08f5-3 for ; Fri, 23 Oct 2026 06:58:28 +0200 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYYP286MB5665.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:295::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 04:58:22 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.016; Fri, 23 Oct 2026 04: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=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=E+dj1esqJJFrUPP9yd6LpRA4OnidB04JDaYWQFpTTpLR4pxjxYKKZ6GmOo0TFYalLyfXdMbe8fjXDgwieA/v764r/26517ItxO7NobmlKgBNPjWG5ja7vpjSSaaBbLXougpV7cFmBb6qVwfXzRyHAdl1sAFrYkpOi/DlWX+Tde8AkxPd/7fGYoh7OfUQCPOfBsdUJgCeqwRA/mqsqjjC7SDjhiXYLlQFISzYaeH2SNAtivZROnPBmnenp1+m5d0c1Qk0bm15CjJk04GJfS1JtBsEFPRonZFrokikU7WXrDG6rh8IBlgfGoshZB9GOyXC9/l2Zfb2umTCLKdnfBlbRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZlKIeSunT1jOHyfhh+rhjOJdcYlWVJgHKK+gdl4jasA=; b=cXXVvr4QzT4SqdvSuI7MxlMU9DLQP00OJW2OcRmkfleHL/BpJZmUsVoueFhz/SZ1zFsIkFq/OvL0Xi6lTgk4denuQDONU8e8FID7lNxg+p+l53byenjkJRDNkxrMAd99b8hhU6UKhfQS1kVo2FfqrdowzpzSLVFvyJfLu5DCpbyM7nugYZSAkgPXP+uFjVWQ2F/PqHkmoQekBYjK2oLqCHNUAuWdHqvGSSCSxAUND2duHQLar9t0t/TZLj2hBTwShW4wBl0iFg1hkwDS/MQRtWefTjw1kXKTlO77BDNH3crCo8HDTv5YQhKl8empmB/RC5jTz1WOmI51D7yDH/7VJA== 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=ZlKIeSunT1jOHyfhh+rhjOJdcYlWVJgHKK+gdl4jasA=; b=jGQB/OGfk0Gvr5sdu1CrAh3VUBxoRFhtO/XBBSydO2rqHoUHwkZ+hw+CIZo3DnRdz9lY7r5F4niEdvSicu7nysMwgvKex3Ogg0jr5Bmx5QPDUWJ91mZSZCWCSuwI3pRnRJT9xkrkB9NZ/PWsIOJLIr02ADbtwpTYR8HZE0/MVVg= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: xen-devel@lists.xenproject.org Cc: roger@xenproject.org, ross.lagerwall@citrix.com, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, teddy.astie@vates.tech, Ryo Takakura Subject: [RFC 5/5] xen/x86: livepatch: enable attaching callbacks Date: Fri, 23 Oct 2026 13:58:08 +0900 Message-Id: <20261023045808.165276-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20261023044809.162759-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0169.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:3c6::12) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYYP286MB5665:EE_ X-MS-Office365-Filtering-Correlation-Id: 487dcbf5-bfa3-4399-7c81-08df30c242e5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|6133799003|18002099003|22082099003|3023799007|10067099003|5023799004|261009223027099003|261021123027099003|261022115727099003|261022113327099003|261021135927099003|261021121427099003|261022075727099003|261021133027099003|261021130227099003|261022105027099003|56012099006|260925022911599003|260925021311599003|260925021911599003; X-Microsoft-Antispam-Message-Info: QH2In2uHRTEs9GYp84KyKDtTL3lGi9Vqjv4w1EFWZ+s3z+ea77b/y9Yo7qf0ItTwpUiuE7KbF48Ovxggk7C5dBOjvF3NXURDrWqFVT0ZrytO2X3SjtiAWX+LmsonJ7ePgloR5dJKJbE+IIaw+O51EKa29VVgD2vTlIIX4jcoor8L8uIWB19YtuIUQuYASZLncCfWUPCaGh9n8uFAmQSlRgWpdtQDmRkal3bjxq8AgCLoBJkFUiKJojteWelTZ6lffArqx1XpMpJzhGJAQBz6V0paUZ5HkuGwcy3jRXuwFrkv6dmv6u8fmAzzo0XzfZEDItafkQaif1cFKE84Dr3Xj8lYkV0aP2dA+VRBvJUSuuaYD7tEJbnvaDEEVck4/9FgQh9gFILX8f6cRkSbF7oVOuDtZvTUqMq1HYtPHDLla2QdQ7envFu3/FmYh32srl6tFMdLUzJa/tvPxEbqf1KJmLAQRV600n6W/CSCGpZEZptokt2EIvUdM/ZNtY8FVCdAQ6OsdoSvMTdI6BqXe2Xjeim+/tNliOm82NEOEkwZyEf/lIkUzc/zG3H9k/q4J8jpPE9++5KlUm4hWnvND1V58MS7+dKTHRYmPaTZ3Mp7Frc4TpXG0S7MFZ5kSS7Lg2qdsJ2vGncKkpYaWebiRqFUpJOVN4sZUh1Z4dgUdPR5mAs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(6133799003)(18002099003)(22082099003)(3023799007)(10067099003)(5023799004)(261009223027099003)(261021123027099003)(261022115727099003)(261022113327099003)(261021135927099003)(261021121427099003)(261022075727099003)(261021133027099003)(261021130227099003)(261022105027099003)(56012099006)(260925022911599003)(260925021311599003)(260925021911599003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?jOKD2MKU1bu7vHg76AmZDNBghNg9I9AZT1XKOmlNieYuPFEaj50+Uy6LTTL5?= =?us-ascii?Q?ZyuafUqjbDfK4vk617FYCGlruRZhBPxcUP1GyInlYS+fAZkLd68ZGKnm2nEB?= =?us-ascii?Q?ZTVaiy5Sifj3yCfG2DIKiXtXGjJoF4lxVHv0ylcDzsLbaaNjqdyQ1bejg0oe?= =?us-ascii?Q?mTualmYczU2N1mxoAi4UDexAbPZDtmgntHKQD8JBFUMNGYDhTIQTFJJtGzOk?= =?us-ascii?Q?uPOLccz63jWEUks10023dq5+/x2A0NU2yUULtJUEw0VJ7ml8JPAEUeJ0E4Lx?= =?us-ascii?Q?Qf8dbfpBwhQA56AfrpJiR5YWk2YxxLvG6lTXr2VEboXSoX6PEShsibuLFokC?= =?us-ascii?Q?AVeczsNFDDs0Ok7wAg+h6K7mduJkoUuhQz1SN1RpUo1cEXxVgd66NHl5uBtN?= =?us-ascii?Q?m/l4C2EZWzwAVBqYsftevXTgyixIQRabTsQQwCettXCS/Qr7shNxZQaBMlua?= =?us-ascii?Q?Xo4/0iGlWzWBUnPTXHr5d+6l3GWrOH/TRu7TifQiOLYnt6igsxhnDNptggro?= =?us-ascii?Q?CJtRie2JLO1z7tmKS3cpck7X28G4NmBJaahSj31LCzTe0T+9HTLDWGItawR8?= =?us-ascii?Q?JPsEveSWcwUTEqeKUsx0MFWK2RuVpPeKaavT/V1/dg0bF2ZF0UqIoyXrSr/0?= =?us-ascii?Q?I+D91Mw7xQUUZ3tMp5ucx3Rj3QuHB9L8UqyR8/ynjZcm4iHOVZlgBy1hqeUT?= =?us-ascii?Q?xXhuJq4Kwmu9/64TKHyjzT69E0MYuv4qTLVpNd+w4TGe83fl2wPEkZy7takI?= =?us-ascii?Q?PPHw3g+G0X07exZIwtvV+qO+jSdVw5cPOBWHepO+fHShVb1Yyq51djaW1Mpe?= =?us-ascii?Q?AUsU5SP2PdehVAGQaP+FcQvLTx4u2lA022c6pJm/GGGS+DooG50Um6/eKxT/?= =?us-ascii?Q?3QAK7Y6ldcZN7VJqOCTCmsMwfjtkutNHD8I93NgZ+oq2a5Z00BjUZ7VzRl5p?= =?us-ascii?Q?YZCC0N6XJnqcP7RmVfkLpD9BztTxiUcPM0x2UzKanExv3ollUkN5kbWtu4pq?= =?us-ascii?Q?oIGqYJOCcqSSi0Vr6L7fCE4tEJL1SWNh18X2yHDSYqQcfj27VTkBqbgY45dP?= =?us-ascii?Q?5ffIwW0n5BuFFRIEfSpJYS3x7uJDz0mHjrv2BCLO83EKYbd5q0PjjYj6Htr9?= =?us-ascii?Q?ebd/bD4eHxQIKrUTr1caOok9ZjbLOYOZrd2c6yJoFXuzhhMPzTpuatfw4pcv?= =?us-ascii?Q?+1jtBSeqrhIN9lN8JLSJNylzobG+GxZ3v4WQY1C/gLmRWPX5tGORVCu5+H9M?= =?us-ascii?Q?6HK9OMTmHfq95mtoKkP2QjNjeClareGJdKZR54w7tJFoQPAUOVIwF4C3olfq?= =?us-ascii?Q?66O21MiHI2M62WWcOn7Q2qAkn+Z3Me68mikFfeJvLKtrwYpKemFmjrW0T2//?= =?us-ascii?Q?PQ5i+37q5iBGzxzvUjO+3CZ59xyWZgktpC8qDGIHPkCh1nU5/gkrUJd7gKEU?= =?us-ascii?Q?ZhwTdWrUdWgnBuu7oqH6PCYApAaQpd58USkJp3/v8/NyDr6wXe3wVCZA69h9?= =?us-ascii?Q?qQA2A4xjSwmMCJBj6lzF4PdKzj1g63GfDz4DojNDNAduLTmjhD0e2ZpatGYl?= =?us-ascii?Q?KQO4Td4Mg8J4nkbnrwhqZIxMLn13xnC4Pv52pzOc+MS9XmOURmm3QPLxqk8A?= =?us-ascii?Q?zoBmFu0+ffs1B5AjsQoaunuMJw21oXvThsh/innS4JMBCAjLNtLfH21z9ZJt?= =?us-ascii?Q?U03zG3f4kNaFRBIT1I0hmCJ4Q+CRYf4OJ8EGVBv+iHYBVEFTtk1QOZod3FUL?= =?us-ascii?Q?OIxXhVxpCA=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 487dcbf5-bfa3-4399-7c81-08df30c242e5 X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 04:58:21.4674 (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: k21OgQlIRV8XNNNgPZOfEjxDKF1ZUUXke2HPyAFav/RX7WPy730Qb4+HhMAQL1DuvPb1i2noey+jKbwgn9Eejg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5665 X-purgate-ID: tlsNG-ef75cf/1792731508-358C1AE4-F122782A/0/0 X-purgate-type: clean X-purgate-size: 9681 Add x86 support for attaching callbacks following the ARM64 implementation. It reserves function entry(5 NOPs) and replaces them with: call xen_livepatch_trace_caller xen_livepatch_trace_caller serves as a trampoline for saving registers before calling xen_livepatch_trace_dispatcher where callbacks are invoked. Callbacks receive: ip: Address of the traced function parent_ip: Address where the traced function was called One can request the feature by specifying the section for struct livepatch_func as .livepatch.traces. This patch will also let x86 use the livepatch tracer. Signed-off-by: Ryo Takakura --- xen/arch/arm/arm64/livepatch.c | 5 +++ xen/arch/x86/Kconfig | 13 ++++++++ xen/arch/x86/Makefile | 1 + xen/arch/x86/arch.mk | 3 ++ xen/arch/x86/livepatch-asm.S | 60 ++++++++++++++++++++++++++++++++++ xen/arch/x86/livepatch.c | 33 +++++++++++++++++++ xen/arch/x86/xen.lds.S | 5 +++ xen/common/hypfs_trace.c | 4 ++- xen/common/livepatch.c | 2 +- xen/include/xen/livepatch.h | 1 + 10 files changed, 125 insertions(+), 2 deletions(-) create mode 100644 xen/arch/x86/livepatch-asm.S diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c index 17753f4463..b4ae381ef5 100644 --- a/xen/arch/arm/arm64/livepatch.c +++ b/xen/arch/arm/arm64/livepatch.c @@ -497,6 +497,11 @@ int arch_livepatch_perform_rela(struct livepatch_elf *elf, } #ifdef CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY +unsigned long arch_livepatch_trace_entry(unsigned long addr) +{ + return addr; +} + void arch_livepatch_apply_trace(const struct livepatch_func *trace) { uint32_t *new_ptr; diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index e5535ac484..bfb6a4d78e 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -355,6 +355,19 @@ config MICROCODE_SCAN_DEFAULT Enable if you have a Linux-based dom0 with microcode attached to the initramfs. +config X86_PATCHABLE_FUNCTION_ENTRY + bool "Reserve five NOPs at function entry for tracing" + depends on LIVEPATCH && $(cc-option,-fpatchable-function-entry=5) + select HAS_LIVEPATCH_TRACE + default n + help + This option compiles Xen with -fpatchable-function-entry=5, which + reserves five NOP instructions at the beginning of functions. The NOPs + will be livepatched with a branch instruction to callback functions + registered by user. + + Enable this to use livepatch tracing feature. + endmenu source "common/Kconfig" diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 2be90ea098..06b39b7530 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_PV) += ioport_emulate.o obj-y += io_apic.o obj-y += irq.o obj-$(CONFIG_LIVEPATCH) += livepatch.o +obj-$(CONFIG_X86_PATCHABLE_FUNCTION_ENTRY) += livepatch-asm.o obj-$(CONFIG_KEXEC) += machine_kexec.o obj-y += mm.o x86_64/mm.o obj-$(CONFIG_VM_EVENT) += monitor.o diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk index cd0602a79a..31af1a15c4 100644 --- a/xen/arch/x86/arch.mk +++ b/xen/arch/x86/arch.mk @@ -129,6 +129,9 @@ endif # Set up the assembler include path properly for older toolchains. CFLAGS += -Wa,-I$(objtree)/include -Wa,-I$(srctree)/include +# Reserve entries for livepatch tracing +CFLAGS-$(CONFIG_X86_PATCHABLE_FUNCTION_ENTRY) += -fpatchable-function-entry=5 + # The GNU assembler will interpret '/' as a comment start marker instead of a # divide for some ELF targets. Pass --divide when when available to signal '/' # is always used as an operator in assembly. diff --git a/xen/arch/x86/livepatch-asm.S b/xen/arch/x86/livepatch-asm.S new file mode 100644 index 0000000000..005765b476 --- /dev/null +++ b/xen/arch/x86/livepatch-asm.S @@ -0,0 +1,60 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include + + .text + +/* + * xen/arch/x86/livepatch-asm.S + * + * Trampoline for livepatch tracer. + * + * If livepatch tracer is enabled, function entries are placed + * with five NOPs. arch_livepatch_apply_trace() will be livepatching + * those NOPs to: + * + * CALL xen_livepatch_trace_caller + * + * 0(%rsp): traced function + 5 + * 8(%rsp): return address to the traced function's caller + */ +FUNC(xen_livepatch_trace_caller) + pushq %rbp + movq %rsp, %rbp + pushfq + + /* Preserve general-purpose registers. */ + pushq %rax + pushq %rcx + pushq %rdx + pushq %rsi + pushq %rdi + pushq %r8 + pushq %r9 + pushq %r10 + pushq %r11 + + /* + * xen_livepatch_trace_dispatcher(ip, parent_ip) + * + * ip: Address of the traced function. + * parent_ip: Address where the traced function was called. + */ + movq 8(%rbp), %rdi + subq $5, %rdi + movq 16(%rbp), %rsi + call xen_livepatch_trace_dispatcher + + /* Restore the saved state. */ + popq %r11 + popq %r10 + popq %r9 + popq %r8 + popq %rdi + popq %rsi + popq %rdx + popq %rcx + popq %rax + popfq + popq %rbp + ret +END(xen_livepatch_trace_caller) diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c index 5158e91f7e..1dfcc3e750 100644 --- a/xen/arch/x86/livepatch.c +++ b/xen/arch/x86/livepatch.c @@ -19,6 +19,10 @@ #include #include +#ifdef CONFIG_X86_PATCHABLE_FUNCTION_ENTRY +extern void xen_livepatch_trace_caller(void); +#endif + static bool has_active_waitqueue(const struct vm_event_domain *ved) { /* ved may be xzalloc()'d without INIT_LIST_HEAD() yet. */ @@ -365,6 +369,35 @@ int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type type) return modify_xen_mappings(start, start + pages * PAGE_SIZE, flag); } +#ifdef CONFIG_X86_PATCHABLE_FUNCTION_ENTRY +unsigned long arch_livepatch_trace_entry(unsigned long addr) +{ + if ( (is_endbr64((const void *)addr) || is_endbr64_poison((const void *)addr)) ) + addr += ENDBR64_LEN; + + return addr; +} + +void noinline arch_livepatch_apply_trace(const struct livepatch_func *trace) +{ + void *site = (void *)arch_livepatch_trace_entry((unsigned long)trace->old_addr); + const void *new_addr = xen_livepatch_trace_caller; + uint8_t insn[ARCH_PATCH_INSN_SIZE]; + int32_t val = new_addr - (site + ARCH_PATCH_INSN_SIZE); + + insn[0] = 0xe8; /* CALL rel32. */ + memcpy(&insn[1], &val, sizeof(val)); + memcpy(site, insn, sizeof(insn)); +} + +void noinline arch_livepatch_revert_trace(const struct livepatch_func *trace) +{ + void *site = (void *)arch_livepatch_trace_entry((unsigned long)trace->old_addr); + + memset(site, 0x90, ARCH_PATCH_INSN_SIZE); +} +#endif + void __init arch_livepatch_init(void) { void *start, *end; diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index 8f943e11ea..1f7d052c30 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -126,6 +126,11 @@ SECTIONS *(.data.rel.ro) *(.data.rel.ro.*) + . = ALIGN(8); + __start_patchable_function_entries = .; + KEEP(*(__patchable_function_entries)) + __stop_patchable_function_entries = .; + #if defined(BUILD_ID) && defined(EFI) && !defined(BUILD_ID_EFI) /* * No mechanism to put an PT_NOTE in the EFI file - so put diff --git a/xen/common/hypfs_trace.c b/xen/common/hypfs_trace.c index d9e06e092e..314cce09bc 100644 --- a/xen/common/hypfs_trace.c +++ b/xen/common/hypfs_trace.c @@ -141,7 +141,7 @@ void trace_dispatch_callbacks(unsigned long ip, unsigned long parent_ip) if ( !global_trace_func.old_addr ) return; - if ( (unsigned long)global_trace_func.old_addr != ip ) + if ( arch_livepatch_trace_entry((unsigned long)global_trace_func.old_addr) != ip ) return; callback = global_trace_func.new_addr; @@ -194,6 +194,8 @@ static bool is_patchable_function_entry(unsigned long addr) { const unsigned long *p; + addr = arch_livepatch_trace_entry(addr); + for ( p = __start_patchable_function_entries; p < __stop_patchable_function_entries; p++ ) { diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 352a2df62c..295a3ebd57 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -224,7 +224,7 @@ xen_livepatch_trace_dispatcher(unsigned long ip, unsigned long parent_ip) { f = &data->funcs[i]; - if ( (unsigned long)f->old_addr != ip ) + if ( arch_livepatch_trace_entry((unsigned long)f->old_addr) != ip ) continue; ASSERT(f->new_addr); diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h index 1b927af8ee..0e5af5fdc5 100644 --- a/xen/include/xen/livepatch.h +++ b/xen/include/xen/livepatch.h @@ -130,6 +130,7 @@ void arch_livepatch_apply_trace(const struct livepatch_func *trace); void arch_livepatch_revert(const struct livepatch_func *func, struct livepatch_fstate *state); void arch_livepatch_revert_trace(const struct livepatch_func *trace); +unsigned long arch_livepatch_trace_entry(unsigned long addr); void arch_livepatch_post_action(void); void arch_livepatch_mask(void); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 05:25:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 05:25:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458936.1671006 (Exim 4.92) (envelope-from ) id 1xK7mY-0000Bc-7e; Fri, 23 Oct 2026 05:25:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458936.1671006; Fri, 23 Oct 2026 05:25: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 1xK7mY-0000BV-4O; Fri, 23 Oct 2026 05:25:34 +0000 Received: by outflank-mailman (input) for mailman id 1458936; Fri, 23 Oct 2026 05:25:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK7mV-0000BP-Qq for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 05:25:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK7mU-006x6O-MS for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 07:25:30 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adaefb8-bab6-0a2a0a5309dd-0a2a450cba5a-46 for ; Fri, 23 Oct 2026 07:25:30 +0200 Received: from [52.101.125.96] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adaefc7-f479-0a2a450c0019-34657d60cab1-3 for ; Fri, 23 Oct 2026 07:25:29 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TY1P286MB3230.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2e6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 05:25: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.0546.017; Fri, 23 Oct 2026 05:25: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=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=nHlyzNtgnQJmsIJGgNPnHkb11MzfM6KenXOELPuMhDNAWEOwjF0fY4ieLOUGd0RNi5Xqe7ISoBO3jmM7mJi/8y/dL1X2UGa6K5q60CddlGXXrk/2mEJc2yMIneQ8khC9fm8gzD7flSOWJE05azPvxIYfGDgByk+PkP6S6YU2KkJTs7KLu+qTASFTc4bN64Mm8pl16Fq0XwB1gi8Ia0H7L0q1B491dqLyDm3wZe967w6MAQSa5luvHvI7KYoCHDheFmPZo03EWTyTVpzVGQYxzn83GrT1ZvIfPI985hJokR1+UTY38a004SsRH3+myr5M/jZkzEdvISdbqGGrHWMGfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ICqv5QkNvvUXkN0vbU1X7eA7aanhGm/joJd7RjGdd1s=; b=hIFRWmkXeu6GIaduSJwUdCW7x6icByJyXDRkfiNmkn0zjmeDMBylG5mHBeZhj/+HfQ+vKmcYRJ3vd4k0t7GUl4BFlRYnCrEBjZK6qoYPBxaxuk6ObOGDc96EsWne6elBgFX3XXWWBG8BVmZR/tnH7OAvvD0KgEOem7brPP/fC9EDk7uPtM5kAyAHXxRxtVI5/imo02mb9lqnHU7rSimgdIFzjK6l1/5BPww6zCl5bsb49rF2XRu67bv6BleYpzANuSzA4oEQAym6eEgKXFkaQpr/ZB5s3X0lNWV3JnkGMReYQzKJelNTCH74gvZsu5uM+9fZUIVy2biUOvyAqSOTeA== 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=ICqv5QkNvvUXkN0vbU1X7eA7aanhGm/joJd7RjGdd1s=; b=PaM4XOafe70iaeRLHOnz1IgxuDWuAn/8HCI1jn5qfj74ctdYeUvGPlJAnLqrCUZJ1mZl4wKqqhy8jjxp+3VjO4ekRwev1qULC7CyK83khJnYZ1xbyiB/BN0AgFt2kKK/iDen/2NYTwgDUxakm9KHZTgLFPBtI0iqcQiFhPAEYDY= From: Hirokazu Takahashi To: "Orzel, Michal" , "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" , "Mykyta_Poturai@epam.com" , Juergen Gross , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Dario Faggioli , George Dunlap Subject: RE: [PATCH v12 2/4] xen/sched: Link CPU topology to scheduler Thread-Topic: [PATCH v12 2/4] xen/sched: Link CPU topology to scheduler Thread-Index: AQHdX21XXIwRdrvZbEe9C8R0UTfp8LcH/XMAgAKWagA= Date: Fri, 23 Oct 2026 05:25:24 +0000 Message-ID: References: <20261019015749.48492-1-taka@valinux.co.jp> <20261019015749.48492-3-taka@valinux.co.jp> <0d758d59-1ac3-4833-aae6-8c181d5ec1e8@amd.com> In-Reply-To: <0d758d59-1ac3-4833-aae6-8c181d5ec1e8@amd.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP 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=valinux.co.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OS9P286MB7222:EE_|TY1P286MB3230:EE_ x-ms-office365-filtering-correlation-id: 613a841e-f2f1-4a5a-ac59-08df30c60a3f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|23010399003|366016|18002099003|22082099003|4143699003|261009223027099003|261022105027099003|10067099003|38070700021|56012099006; x-microsoft-antispam-message-info: kRFe7QkSxnjLM+94fJiUx/RMqZWb+xdCaFWhF/mzzROXNFFv3FBQToWN0xomnEndg9KY3tMHU79Ck+KJPK3DUyNlFpoCwmX+aAgUpOF7pnOCdd4+NdS57y+m6RVpWSnSQlCE4CCZAqDJX9Mdqqw/9H0fWbgvUpfniyklbUVmqi67Ljk0U3JAGTokPogkQPBvF+n9ox0IXLXtomb4tsu6XpVCM1iGpp2BO95fTPj2sLt8U8jwKXYULeiIRzPTVl0RXFqvutWX9wk4tuYu5ykJrpIlktIh+Z1++kRt+nJFy0dfZsRHYNejTdKBc0XvwTzD58YfI0T6Jd7BacEmFY3xwy5tNwyyeY/54KzBWn2uAxtT8DA0Ujlv24a4Idyl8wgas3nAaF6R3/SmZeio4IhsoKNgTPgVpbbpXY36VHqpWF7IMSAdvcwA5c1famt+XN7dR+uBRuk6M6lrruD+gGV+TTD1o4gmAR1YcjzdKQHubAtu1oxHUajE6JvOZd7YlTgkKs6+ceopl1pQZOkoG4sveNJ6Uws0O5FSEZMa26E68tIwaSsqWQnGq2HiTAmoDq+xyF7ijVGhTxDvXfgf74oW9li7jdnXAK8bUBzenIBOdyQ55/uPPrkDvu+LkM21b6QQFYHFYmwt/2hgnO5IsWZA1R1+Mw1kAonBB7z6YT40UrGhCvIFA30memdbvk3GzkapLyiyLcYXJRL0iNcXsTB+xN+tmaYp5IlBCYJep4cEB48= 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)(7416014)(376014)(1800799024)(23010399003)(366016)(18002099003)(22082099003)(4143699003)(261009223027099003)(261022105027099003)(10067099003)(38070700021)(56012099006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NFVvYVZzSERzZnpkU052MmsvaEh0Mll0VzB0SGQ4VExBN1BRMCs4ZEEvdGJ0?= =?utf-8?B?VFVRREVyemVtSXcxbm9RbHBlR245SklSRGtqTjU3d3Bqd0hSV0dZZ29uTDJh?= =?utf-8?B?SFZqaHBHaGlma1RPa01IbVNab1drWGdGS0phSy9vRFVFYXZFeFBwd0pva05y?= =?utf-8?B?SGZUektuZHRoSXMrY1ptVVJ1T2hudmd0c1FWZjNRVlVnWnB0TS8wNnM2bm9k?= =?utf-8?B?VVM1VTZFb2pWbU15Y01SZktPbDVVSnZyZXo0OGR1MDdTVFVDTXNlR0FGelpk?= =?utf-8?B?aG1adXluZ2hydjZDSlpoZURMSXNDd2lqbUQ3bkg2Q2VVZUNuMGpnL1N1Sm9i?= =?utf-8?B?enNPNHkwamxzeS9nalhZbjdnamRwRnZqbmptNFdZNjZIanloUld2U2lwMitq?= =?utf-8?B?TE9MdkZxbmpnTzkzYlc5cXhaNElrYmUzTlR3VGdSZDlWOGkvOUhUdEtRMWVD?= =?utf-8?B?eWh3K2JOV2E1ZmRoSFRYN3A0dUhUY3YvN1VWTnRORm1PK1c4WjZYUzNNMzg1?= =?utf-8?B?M2xNU1pTVHJIYzJ6cVBMY1JUUzRTbkRxUGowN0grS1pCTkdROFhWenUweDR2?= =?utf-8?B?eFhRc0txaUNPL25QTHgyUnpxeWZaNmRSdzhiMVRScEM1Y2g1V3M2UVpxZzZO?= =?utf-8?B?OTFhZUtwM3ZhTktXTkJ6UDVEN2szc2dtUFMzVmRtanBycHgvVEdnT29POFo0?= =?utf-8?B?R0MwWVFVR1ZpUmYrbzdzVG9iRGlMbWVCNkFUZHFxaWRmMlpOdlBLVUE4RGVT?= =?utf-8?B?WmpyaDZKcE10cFAwQlh5TDVlUDUxbnlwck9RbUxlb011MjdEcHphdStqV25G?= =?utf-8?B?Y0xiUTlNY2FMdkF3VUd3Mzlvb1ZOS2xXWmtnS3piaEdZWkNGSUhldUNMZ0FS?= =?utf-8?B?YnlUWEpMNktpWWQ0eXBMWW5wTGlmMWxVOWxHSVQ2OWZpa2tuMjlpRHVxNzhR?= =?utf-8?B?MzRVMXNKbVNSbjZJWHpaeWFaSnAyN20yc2w0SE9UMEFNOTBVSS9wQ1lONXZW?= =?utf-8?B?N015b2JKbzIwR1I5TzdZbXJxTTV5Tyt4bGFtRHRrekp6dlJrZUtYM01iUVJT?= =?utf-8?B?a2IyUFFGK1FHNHFKRWVCS2ZpTDJhSUdrVkhxTFFJaUlSMFNQYVNQWDhTOXUw?= =?utf-8?B?RVQzSkUvTmx0eTV3YUtSTk1IRDlmVmhOUDRpbXFnakpBZUhmTisyaGN6WFBC?= =?utf-8?B?b254S3Q0L1NtMnpOQU1KdVI3ZFRSN2ZaT3hIdGE4WnJTdkhZaDg5bWhEa1dL?= =?utf-8?B?UVBhRCt2QkRYOEN5TVRmQ2I3NHMwWmszS0ZvRytVZlY1cll3aVNuMFpaZzUw?= =?utf-8?B?STdoZng5dlpva0s3d2c3eTRvQjUzZlJOdmkxSVlEUFVYNVNaZXdtSUZuRVov?= =?utf-8?B?Q3BKSzlxYnE3clFEMEYyY2Z2cXdqRTRuWEhtNk5xUitWblVDZjRZTXJMcUxW?= =?utf-8?B?RVNUME9ydFowT0xtcFRwKzF0cStRTTd2NFJsdkV3azNpZEMrWERHZEY2Z3Zs?= =?utf-8?B?VzNBQkVGWmVSMlpGaXVDWU5lSEdWM1lmTlFXbTY4bDZGZGVSTitZcU1QU3NH?= =?utf-8?B?V0MyNitGL01XaHJicnRZVWw3S3YwRk5nYUZMcldMYTgyNkNMS2cwV0tKTEd4?= =?utf-8?B?OWhlT1N0SEdGaHYzSlB5VXBlOXI0cEl3S3YwaHA0VFg1T1dGNWp4Q0xVM1BE?= =?utf-8?B?YVFzMS9BZHNMUWUyS09BaGlWc3IzWTlNd0ZmRmRGcDlFeG0zR2kzTG5wdlZL?= =?utf-8?B?SFUya1dLUHd0dHE4dDhIZUN1bkxGNyt1MktvY0xCQ09OL2FSZUNLZSsvWEcx?= =?utf-8?B?cGN5L1BGdU5NUjdrYUg2Y2xvT3NSenlKNGx4Y2NvVDZpNGlwSGNyU1Z5SkFj?= =?utf-8?B?QkQ1WmlOR3drSDJqQjA0eWhZWXBYSW13SThDNEF6WXowZmhIQkhnSFdRRTJJ?= =?utf-8?B?RldUTTZ6bjZyMFg4ZlI0SU55dlFWVFpOSHFkSkhyWFFKeGd2eWJMb0lmVEhy?= =?utf-8?B?NmhWcGRtUGd0dENmVU14NVgyRUdReTRveTQ0Mno5ZTYrMVkzaU1Wa3VYRUhR?= =?utf-8?B?Z2tJalYvdmtDbGNuS29zaFNDcEJzcnhON2p1VTc2WHhDR2tLWEU0ZThuOU1Z?= =?utf-8?B?Y2pGUDVmOVhqR2VFK200RERVelBsMStzWFcwWDU0aVpuc01Qbk56M0lUL1Ns?= =?utf-8?B?bTMvc3B5TkF4WXlNMnA4SEprVEZ4SGtTME9RQ1dkZ2V6WVBLTFQ2QTZiQXVx?= =?utf-8?B?dk1XYWZQa0NYMVNrVnFORXI5djd1MEFxVWRRcTBqYmFUQWRlV0lDNjVORGxS?= =?utf-8?Q?of/bZP59uCM7sfXAeF?= 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: 613a841e-f2f1-4a5a-ac59-08df30c60a3f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2026 05:25:24.3389 (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: q2bohIwLho4boAjXb7NRQ4uneRbpxP3RaceJkeOhj2SK6zvkMp2jYZf3TmvoXC4SljiB00tEj1B2ogbMwXNnHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1P286MB3230 X-purgate-ID: tlsNG-d25034/1792733130-02EDAA5B-ED11A0DC/0/0 X-purgate-type: clean X-purgate-size: 5642 SGkgTWljaGFsLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNCj4gPiBkaWZmIC0tZ2l0 IGEveGVuL2FyY2gvYXJtL3NtcGJvb3QuYyBiL3hlbi9hcmNoL2FybS9zbXBib290LmMNCj4gPiBp bmRleCBkMzQzOTZmOWIxLi5jZjQ4NThlYjM3IDEwMDY0NA0KPiA+IC0tLSBhL3hlbi9hcmNoL2Fy bS9zbXBib290LmMNCj4gPiArKysgYi94ZW4vYXJjaC9hcm0vc21wYm9vdC5jDQo+ID4gQEAgLTkz LDEzICs5Myw3IEBAIHN0YXRpYyBpbnQgc2V0dXBfY3B1X3NpYmxpbmdfbWFwKGludCBjcHUpDQo+ ID4gICAgICAgICAgICF6YWxsb2NfY3B1bWFza192YXIoJnBlcl9jcHUoY3B1X2NvcmVfbWFzaywg Y3B1KSkgKQ0KPiA+ICAgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPiA+DQo+ID4gLSAgICAvKg0K PiA+IC0gICAgICogQ3VycmVudGx5IHdlIGFzc3VtZSB0aGVyZSBpcyBubyBtdWx0aXRocmVhZCBh bmQgTlVNQSwgc28NCj4gPiAtICAgICAqIGEgQ1BVIGlzIGEgc2libGluZyB3aXRoIGl0c2VsZiwg YW5kIHRoZSBhbGwgcG9zc2libGUgQ1BVcw0KPiA+IC0gICAgICogYXJlIHN1cHBvc2VkIHRvIGJl bG9uZyB0byB0aGUgc2FtZSBzb2NrZXQgKE5VTUEgbm9kZSkuDQo+ID4gLSAgICAgKi8NCj4gPiAt ICAgIGNwdW1hc2tfc2V0X2NwdShjcHUsIHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7 DQo+ID4gLSAgICBjcHVtYXNrX2NvcHkocGVyX2NwdShjcHVfY29yZV9tYXNrLCBjcHUpLCAmY3B1 X3Bvc3NpYmxlX21hcCk7DQo+ID4gKyAgICBpbml0X2NwdV9zaWJsaW5nX21hcChjcHUpOw0KPiBU aGUgY29tbWVudCBhYm92ZSB0aGUgY3B1X3NpYmxpbmdfbWFzayBkZWZpbml0aW9uIGlzIG5vdyBz dGFsZS4NCg0KWWVzLiBUaGlzIHBhdGNoIHJlbW92ZXMgdGhlIGNvbW1lbnQuDQoNCg0KPiA+ICsg ICAgZm9yX2VhY2hfcG9zc2libGVfY3B1KGNwdSkNCj4gPiArICAgIHsNCj4gPiArICAgICAgICB1 bnNpZ25lZCBpbnQgZmlyc3RfY3B1Ow0KPiA+ICsgICAgICAgIHN0cnVjdCBjcHVfdG9wb2xvZ3kg KnRvcG8gPSAmY3B1X3RvcG9sb2d5W2NwdV07DQo+ID4gKw0KPiA+ICsgICAgICAgIGZpcnN0X2Nw dSA9IGNwdW1hc2tfZmlyc3QodG9wby0+dGhyZWFkX3NpYmxpbmcpOw0KPiA+ICsgICAgICAgIEFT U0VSVChmaXJzdF9jcHUgPCBucl9jcHVfaWRzKTsNCj4gPiArDQo+ID4gKyAgICAgICAgaWYgKCBm aXJzdF9jcHUgPT0gY3B1ICkNCj4gPiArICAgICAgICB7DQo+ID4gKyAgICAgICAgICAgIHRvcG8t PnBoeXNfY29yZV9pZCA9IG5leHRfY29yZV9pZDsNCj4gPiArICAgICAgICAgICAgbmV4dF9jb3Jl X2lkKys7DQo+ID4gKyAgICAgICAgfQ0KPiA+ICsgICAgICAgIGVsc2UNCj4gPiArICAgICAgICB7 DQo+ID4gKyAgICAgICAgICAgIHRvcG8tPnBoeXNfY29yZV9pZCA9IGNwdV90b3BvbG9neVtmaXJz dF9jcHVdLnBoeXNfY29yZV9pZDsNCj4gPiArICAgICAgICB9DQo+IE5vIGJyYWNlcyBmb3Igc2lu Z2xlIGxpbmUgc3RhdGVtZW50cy4NCg0KT2theS4NCg0KPiA+ICsNCj4gPiArICAgICAgICBmaXJz dF9jcHUgPSBjcHVtYXNrX2ZpcnN0KHRvcG8tPmNsdXN0ZXJfc2libGluZyk7DQo+ID4gKyAgICAg ICAgaWYgKCBmaXJzdF9jcHUgPj0gbnJfY3B1X2lkcyApDQo+ID4gKyAgICAgICAgew0KPiA+ICsg ICAgICAgICAgICAvKiBDbHVzdGVyaW5nIGlzIG5vdCBzdXBwb3J0ZWQgKi8NCj4gPiArICAgICAg ICAgICAgdG9wby0+cGh5c19jbHVzdGVyX2lkID0gMDsNCj4gPiArICAgICAgICB9DQo+ID4gKyAg ICAgICAgZWxzZQ0KPiA+ICsgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgaWYgKCBmaXJzdF9j cHUgPT0gY3B1ICkNCj4gPiArICAgICAgICAgICAgew0KPiA+ICsgICAgICAgICAgICAgICAgdG9w by0+cGh5c19jbHVzdGVyX2lkID0gbmV4dF9jbHVzdGVyX2lkOw0KPiA+ICsgICAgICAgICAgICAg ICAgbmV4dF9jbHVzdGVyX2lkKys7DQo+ID4gKyAgICAgICAgICAgIH0NCj4gPiArICAgICAgICAg ICAgZWxzZQ0KPiA+ICsgICAgICAgICAgICB7DQo+ID4gKyAgICAgICAgICAgICAgICB0b3BvLT5w aHlzX2NsdXN0ZXJfaWQgPSBjcHVfdG9wb2xvZ3lbZmlyc3RfY3B1XS5waHlzX2NsdXN0ZXJfaWQ7 DQo+ID4gKyAgICAgICAgICAgIH0NCj4gTm8gYnJhY2VzIGZvciBzaW5nbGUgbGluZSBzdGF0ZW1l bnRzLg0KDQpPa2F5Lg0KDQo+ID4gKyAgICAgICAgfQ0KPiA+ICsNCj4gPiArICAgICAgICBmaXJz dF9jcHUgPSBjcHVtYXNrX2ZpcnN0KHRvcG8tPmNvcmVfc2libGluZyk7DQo+ID4gKyAgICAgICAg QVNTRVJUKGZpcnN0X2NwdSA8IG5yX2NwdV9pZHMpOw0KPiA+ICsNCj4gPiArICAgICAgICBpZiAo IGZpcnN0X2NwdSA9PSBjcHUgKQ0KPiA+ICsgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgdG9w by0+cGh5c19zb2NrZXRfaWQgPSBuZXh0X3NvY2tldF9pZDsNCj4gPiArICAgICAgICAgICAgbmV4 dF9zb2NrZXRfaWQrKzsNCj4gPiArICAgICAgICB9DQo+ID4gKyAgICAgICAgZWxzZQ0KPiA+ICsg ICAgICAgIHsNCj4gPiArICAgICAgICAgICAgdG9wby0+cGh5c19zb2NrZXRfaWQgPSBjcHVfdG9w b2xvZ3lbZmlyc3RfY3B1XS5waHlzX3NvY2tldF9pZDsNCj4gPiArICAgICAgICB9DQo+IE5vIGJy YWNlcyBmb3Igc2luZ2xlIGxpbmUgc3RhdGVtZW50cy4NCg0KT2theS4NCg0KPiA+ICBzdHJ1Y3Qg Y3B1X3RvcG9sb2d5IHsNCj4gPiAgICAgIGNwdW1hc2tfdmFyX3QgdGhyZWFkX3NpYmxpbmc7DQo+ ID4gICAgICBjcHVtYXNrX3Zhcl90IGNvcmVfc2libGluZzsNCj4gPiAgICAgIGNwdW1hc2tfdmFy X3QgY2x1c3Rlcl9zaWJsaW5nOw0KPiA+ICsgICAgdW5zaWduZWQgaW50IHBoeXNfY29yZV9pZDsN Cj4gPiArICAgIHVuc2lnbmVkIGludCBwaHlzX2NsdXN0ZXJfaWQ7DQo+IHBoeXNfY2x1c3Rlcl9p ZCBhbmQgY2x1c3Rlcl9zaWJsaW5nIGFyZSBvbmx5IHVzZWQgdG8gY29tcHV0ZSBlYWNoIG90aGVy LiBBcmUNCj4gdGhleSByZWFsbHkgbmVlZGVkPw0KDQpJIGtlcHQgdGhlbSBiZWNhdXNlIEkgcGxh biB0byBtYWtlIGl0IHBvc3NpYmxlIHRvIHNwZWNpZnkgImNsdXN0ZXIiIGZvciB0aGUNCmNyZWRp dDJfcnVucXVldWUgcGFyYW1ldGVyLg0KDQoNCj4gPiArICAgIHVuc2lnbmVkIGludCBwaHlzX3Nv Y2tldF9pZDsNCj4gPiArICAgIHVuc2lnbmVkIGludCBudW1fc2libGluZ3M7DQo+ID4gIH07DQo+ ID4NCj4gPiAgZXh0ZXJuIHN0cnVjdCBjcHVfdG9wb2xvZ3kgKmNwdV90b3BvbG9neTsNCj4gPiAr DQo+ID4gK3N0YXRpYyBpbmxpbmUgdm9pZCBpbml0X2NwdV9zaWJsaW5nX21hcCh1bnNpZ25lZCBp bnQgY3B1KQ0KPiA+ICt7DQo+ID4gKyAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0dFTkVSSUNf Q1BVX1RPUE9MT0dZKSAmJiBjcHVfdG9wb2xvZ3kgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAg IGNwdW1hc2tfY29weShwZXJfY3B1KGNwdV9zaWJsaW5nX21hc2ssIGNwdSksDQo+ID4gKyAgICAg ICAgICAgICAgICAgICAgIGNwdV90b3BvbG9neVtjcHVdLnRocmVhZF9zaWJsaW5nKTsNCj4gPiAr ICAgICAgICBjcHVtYXNrX2NvcHkocGVyX2NwdShjcHVfY29yZV9tYXNrLCBjcHUpLA0KPiA+ICsg ICAgICAgICAgICAgICAgICAgICBjcHVfdG9wb2xvZ3lbY3B1XS5jb3JlX3NpYmxpbmcpOw0KPiBj cHVfdG9wb2xvZ3lbXSBpcyBidWlsdCBmcm9tIGFsbCBDUFVzLCBzbyBhIENQVSB0aGF0IHRoZW4g ZmFpbHMgdG8gYm9vdA0KPiBzdGF5cyBpbiBpdHMgc2libGluZ3MgbWFza3MuIEkgdGhpbmsgYSBD UFUgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZXNlIG1hc2tzIG9ubHkNCj4gb25jZSBpdCBpcyBvbmxp bmUuDQoNClRoZSBvcmlnaW5hbCBjb2RlIHByaW9yIHRvIHRoaXMgcGF0Y2ggaW5pdGlhbGl6ZWQg dGhlIENQVSBzaWJsaW5nIG1hcCBpbiB0aGUgQ1BVX1VQX1BSRVBBUkUNCk5vdGlmaWVyIGJlZm9y ZSBicmluZ2luZyB1cCBhIHNlY29uZGFyeSBjb3JlLiBJIGFncmVlIHRoYXQgaXQgaXMgYXBwcm9w cmlhdGUgdG8gaW5pdGlhbGl6ZSBpdCBhZnRlcg0KdGhlIGNvcmUgaXMgYWN0dWFsbHkgYnJvdWdo dCB1cCwgc2ltaWxhciB0byBob3cgeDg2IFhlbiBkb2VzIGl0Lg0KDQpUaGFuayB5b3UsDQpIaXJv a2F6dSBUYWthaGFzaGkNCg== From xen-devel-bounces@lists.xenproject.org Fri Oct 23 06:42:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 06:42:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458949.1671023 (Exim 4.92) (envelope-from ) id 1xK8yr-0004Yp-M1; Fri, 23 Oct 2026 06:42:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458949.1671023; Fri, 23 Oct 2026 06:42: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 1xK8yr-0004Ye-Hs; Fri, 23 Oct 2026 06:42:21 +0000 Received: by outflank-mailman (input) for mailman id 1458949; Fri, 23 Oct 2026 06:42:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK8yq-0004YY-2s for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 06:42:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK8yo-00Bas8-8z for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 08:42:18 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb01b7-8faa-0a2a0a5109dd-0a2a4504aa04-36 for ; Fri, 23 Oct 2026 08:42:17 +0200 Received: from [52.101.193.51] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb01c7-b57f-0a2a45040019-3465c1331b23-4 for ; Fri, 23 Oct 2026 08:42:17 +0200 Received: from BN9PR03CA0111.namprd03.prod.outlook.com (2603:10b6:408:fd::26) by SJ2PR12MB9240.namprd12.prod.outlook.com (2603:10b6:a03:563::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.19; Fri, 23 Oct 2026 06:42:11 +0000 Received: from BN5PEPF00046989.namprd02.prod.outlook.com (2603:10b6:408:fd:cafe::5c) by BN9PR03CA0111.outlook.office365.com (2603:10b6:408:fd::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Fri, 23 Oct 2026 06:42:11 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN5PEPF00046989.mail.protection.outlook.com (10.167.245.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Fri, 23 Oct 2026 06:42:11 +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.53; Fri, 23 Oct 2026 01:42:11 -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.53; Fri, 23 Oct 2026 01:42:10 -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.53 via Frontend Transport; Fri, 23 Oct 2026 01:42: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=Zt/Gc3VJoEYY6LTtxg/98zPUqOvLSy2R3HrB3AdaQXNI35zDy5jvukuids5+SygssAGNoKSRgkXyi5ZquiKsV6HBCq96Hn//0ZQbSxP+jT1Kefxp+8jBj1WSfeMcFjSy1l4i/snbTVTw1KnvmyWkbaCQhLkkvUtLPg/g08p5kPWvO9sctWodN3hY1BymmVikOphrSs/81cztkB7jQl23gMX4pRYY6husaySEGYuHWqj8Nsr1xZpq0tCavtxLOSpQs+gUdlQo7Zgfsa8LzKqmQZg9839CbK2z8pNRSrmhQCwpfhnhHR+Q9YZJ9YRFTcVhBCPGJAsopZlGjpfLCp8ZCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5b+zrEmH1CSPIlxb1L1IesYcivOifJwEYUWzV0eeB90=; b=HYf8dJP77R+1yBwBE70Q2KcZHS07ZX7/DkO3o+w+7bHtcTuACY41xXbM3laiO5ldlCPUHH0RqK+Pko2//fiXRst8CKJxvrCcl63BdeJ53w7pqvKh/K+cgABRE7EUJKXEgWBlw4CRxtb39cbIY2dUUKCYtx4jvkDhh5KQ1nOH4O2mkG4woDk7yOUoYgG0JvkCNy7to1jaFuF1F0rNcWF06LqT1SP7fPs4Cz6WChhooN2PCXBrp4U0gliY574tfjn5r9eb/n84tw9Di+0HMbYn3SdD77/02ecZY9Zgsdp7IYT3Y4U7D1EazextIqi1gHA6oW+uG0u7qGuEH5csngDRHA== 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=5b+zrEmH1CSPIlxb1L1IesYcivOifJwEYUWzV0eeB90=; b=Rp4K+Oh3mcuaqdj9Dhu3wPfKz0X8JWdQTRwLRVta7Uyf1hySolsZjRRPqiymmrxDt9w5gggM7VyjM3amzwlz4gdda/Gb09jGFR7O4WFi7Bl9XiDoO+GNUbOJFueHIXNhgIpNXmmSqkDfp2VndXr4wX6DYg2bJ4BRNz+EuukwqFw= 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: <8e4131b5-18e7-484a-bc4f-f9e6f279606e@amd.com> Date: Fri, 23 Oct 2026 08:42:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver To: Ayan Kumar Halder , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis References: <20261021132640.599126-1-ayan.kumar.halder@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261021132640.599126-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN5PEPF00046989:EE_|SJ2PR12MB9240:EE_ X-MS-Office365-Filtering-Correlation-Id: 43cd7009-8267-4706-6ffe-08df30d0c445 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|23010399003|36860700016|261021123027099003|261022105027099003|56012099006|11063799006|261009223027099003|18002099003|22082099003|10067099003|261021121427099003; X-Microsoft-Antispam-Message-Info: GhVWzE3deQ05qQ47QTXlySKvx7Sn6L1Vup5tf92zl4RhyWlQ1x9qG7KfHC0WJPhQINQwEldTx2m3ySM5elDh5PHy5FBKV1uu2CFpAWF5ID2CIoh8BksWxS2nhEsQ7xrV1IwxSAqZbvaAVk+c+CBRHTzt+52xhJI/a1XHaPIajrgPQwY0/wkShDWAdmAdKztFjHp4pXziCa5GkbYQ5EClQ6lOnEex8odg6b5lKzx62jbtLSy173eWIKzQW2WH1A9S80lvTORv4CP3LbFZ+7qITCN7+r8FnpECO7ZIjlKmP4d75ZB9XJV7ElcUzO9rNaIUy+Kpw1uv4KM1JNVerHehdW6czhIVBeIGJPsGPAKx8hZ+dk3/ekxKmEaeTMin6tsU2WBPFvvLjKaOyCiMgNFLVs+GphK0yjCf34SC+kLv99LULJfjMiXvNf1fHee6OUltwvQTgL8Z3bPjaL3rDciIzuEqrHlqj2lXv21/D12WyGADo6JLr9CTlRLdOw4RTtKp3aC/QUCoud6ookKXBaBCH0BsHqSDZiHNerg3AgW/iehnUqSyuITnkK0FMf13KZSzNIWs6WlzHD1AHLBU1gCBaH8FExqIFd77A/9Ckt4pNaiyKdaPCluHdpj3WdyVKtEtgWOYM/4tMyUFbg6v2jI5bB4gnr7ao4QwkC0hCIkwFDh0K5B35gJwSC3y/bSXiILf9KiMf7w3Ogcucp59PNyQ4Q== 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)(1800799024)(82310400026)(23010399003)(36860700016)(261021123027099003)(261022105027099003)(56012099006)(11063799006)(261009223027099003)(18002099003)(22082099003)(10067099003)(261021121427099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: GKhKyKCqKbjj8tTjH6b0zCAtY0cny9gI4Ct9PesjrwX0XkTHG9SiDqNjclUmBPA8GLw5P+GtdXf3FtNaOqHJEGslywqs8Lt0KR8y/Ny+AfoGq2ytgrw6oUVdrckmeinnTONElQtbSIg541BxUihZ7Ik9oq59WLjQRgllNUZxO+Y+/Vmabv2XADUCso9lGhYwJbqg1qdN2yzBuKLUUUT0CQUhg3JlX78TPILqansrxQzkogWLhwhWDFFhZK6iyFFfQj59MU1Uu1DEbP0M4XjpDFTzS1K0AQerF81dyPAl730KNulk0t12JwR4HmL8BjRa7dqlFjqUjPeEWhBbs/DHRCY/QzRRHtMpldYd0SneL7VxmBrwxjZClvHOJt3WkjGSZX7CLX/nb2ny78wf1GpIfjmP8byUIezxa6snaeE9YL3lDr3TPyL0WAQhZKkte5YF X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 06:42:11.3691 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 43cd7009-8267-4706-6ffe-08df30d0c445 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: BN5PEPF00046989.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9240 X-purgate-ID: tlsNG-ebf023/1792737737-C12DCB50-F3A059E5/0/0 X-purgate-type: clean X-purgate-size: 3496 On 21-Oct-26 15:26, Ayan Kumar Halder wrote: > psci_init_0_2() stores the value returned by PSCI_VERSION in the global > psci_ver before checking that Xen supports it. When the firmware reports > a version other than 0.2 or 1.x, the function prints "Unrecognized PSCI > version" and returns -EOPNOTSUPP, but psci_ver keeps the rejected value > and psci_cpu_on_nr stays 0. > > psci_init() then tries the PSCI 0.1 fallback, which overwrites psci_ver > on success. When the fallback fails as well (the /psci node is not > compatible with "arm,psci", it has no "cpu_on" property, or Xen boots > with ACPI), psci_init() returns an error that smp_init_cpus() ignores, > and psci_ver still holds the rejected version. All the users of > psci_ver then consider PSCI as available: > - on arm64, smp_psci_init() installs call_psci_cpu_on() as the method > to bring up the secondary CPUs; > - on arm32, platform_cpu_up() calls call_psci_cpu_on() instead of the > platform specific cpu_up() callback; > - call_psci_cpu_off(), call_psci_system_off() and > call_psci_system_reset() issue their PSCI calls. > > As a result, Xen brings up each secondary CPU with an SMC using function > ID 0. An SMCCC compliant firmware refuses it, and Xen reports "Failed to > bring up CPU (error -1)" for each secondary CPU. > > Only set psci_ver once the version has been accepted, so that a rejected > version leaves psci_ver at 0 and Xen behaves as if PSCI was not > available. In the case above, Xen no longer issues any other PSCI call: > on arm64 the secondary CPUs using the "psci" enable-method are rejected > by smp_psci_init() and Xen boots on the boot CPU only; on arm32 > platform_cpu_up() uses the platform cpu_up() callback, if any. CPU_OFF, > SYSTEM_OFF and SYSTEM_RESET are not issued either, as when the PSCI 0.1 > fallback is used. > > Fixes: 4d3d72c01467 ("xen/arm: Initial support for PSCI-0.2") > Signed-off-by: Ayan Kumar Halder > --- > xen/arch/arm/psci.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > index 634d0d7467..a720cf8d41 100644 > --- a/xen/arch/arm/psci.c > +++ b/xen/arch/arm/psci.c > @@ -169,6 +169,7 @@ static int __init psci_init_0_2(void) > }; > int ret; > struct arm_smccc_res res; > + uint32_t ver; > > if ( acpi_disabled ) > { > @@ -191,16 +192,17 @@ static int __init psci_init_0_2(void) > } > > res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION); > - psci_ver = PSCI_RET(res); > + ver = PSCI_RET(res); > > /* For the moment, we only support PSCI 0.2 and PSCI 1.x */ > - if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 ) > + if ( ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(ver) != 1 ) > { > printk("Error: Unrecognized PSCI version %u.%u\n", > - PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver)); > + PSCI_VERSION_MAJOR(ver), PSCI_VERSION_MINOR(ver)); > return -EOPNOTSUPP; > } > > + psci_ver = ver; > psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON); > > return 0; The patch would be simpler if you just set psci_ver = 0 right before returning -EOPNOTSUPP. No need for the new local variable then. If you agree, I can change on commit. With that: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 23 07:06:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 07:06:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458954.1671032 (Exim 4.92) (envelope-from ) id 1xK9Ln-0007sA-EE; Fri, 23 Oct 2026 07:06:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458954.1671032; Fri, 23 Oct 2026 07:06: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 1xK9Ln-0007s3-BM; Fri, 23 Oct 2026 07:06:03 +0000 Received: by outflank-mailman (input) for mailman id 1458954; Fri, 23 Oct 2026 07:06:01 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK9Ll-0007rt-Js for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 07:06:01 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xK9Ll-00000009504-26RG; Fri, 23 Oct 2026 07:06: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.98.2) (envelope-from ) id 1xK9Ll-00000001CuC-0GkG; Fri, 23 Oct 2026 07:06: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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=br+qS364HHKSB/jSJ6eMmP9fQ9dH7eEayqVZcTWzhdg=; b=2B2KZMnDruCZ7JUCKEWRbLpd0E 3Kc1XFGP1wbie5f+Gs3Rf6bxc5BbEqyM6gVr5+K5F/bL1RCB4ujw3YTv8xOK1ENwOEVPahB+u8vcW EcA9y3f1wFPuRVWLX5ox+PDk6QpeOK+8/8j3pBfTGCWmWQr1702re3ptEGwHl25lXlRE=; Date: Fri, 23 Oct 2026 09:05:55 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v4 02/30] x86/mm: refuse to promote an L4 while the domain has no vCPU Message-ID: References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-2-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261019-asi-hvm-v4-2-b68b66652266@xenproject.org> On Mon, Oct 19, 2026 at 08:42:33PM +0100, George Dunlap wrote: > init_xen_l4_slots() puts the domain's per-domain L3 in slot 260 of the > L4s it fills. Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT > L3 slot at domain creation") a PV domain gets that L3 with its first > vCPU (pv_create_gdt_ldt_l1tab()). Only mapcache_domain_init() makes it > earlier, with the domain, and release builds skip that unless memory > hotplug is enabled or the host's memory reaches past the part of the > directmap PV guests can see. So in release builds on most hosts, an L4 > promoted before XEN_DOMCTL_max_vcpus has created the domain's vCPUs gets > a slot 260 entry made from a NULL page (0x803e900000000063), pointing > far beyond the host's memory. Won't it be more reliable long term to instead return an error from init_xen_l4_slots() when the per-domain L3 page is not present? It does seem like PV vCPU creation could change yet again in a way that the per-domain L3 is not allocated there, and then the check added in this patch will be moot. If we need the per-domain page-table to be allocated by this point, let's test for that, not indirectly testing whether vCPU 0 has been created. I also wonder, this is for PV only, but I assume for correctness purposes we should do the same check for HVM monitor tables also? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 07:45:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 07:45:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458966.1671040 (Exim 4.92) (envelope-from ) id 1xK9yD-0004nA-C5; Fri, 23 Oct 2026 07:45:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458966.1671040; Fri, 23 Oct 2026 07:45: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 1xK9yD-0004n3-9S; Fri, 23 Oct 2026 07:45:45 +0000 Received: by outflank-mailman (input) for mailman id 1458966; Fri, 23 Oct 2026 07:45:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK9yC-0004mx-P4 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 07:45:44 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xK9yC-000000095is-2HDs; Fri, 23 Oct 2026 07:45: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.98.2) (envelope-from ) id 1xK9yC-00000001xOe-0i6t; Fri, 23 Oct 2026 07:45: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=/jReY573GicXZtbME+gZPW5su2Q9Qb5iQsMIbgVS2nA=; b=rCAqTWJSaEvZZuBwDtWgfwhUwE FDqo8+6Xk+NYzHzMyhDtVH+PuXFWQdYErm38w3LVZL7AxB6tm6RwLYNXPfs6yKDWQmj+LbR/CTymL m/UU57ZTuDhkWMoDDoLLkJ6bMlsEhjBAvh/VWb6v5r4sWYSmtFuexhDFHfXf+nqWAHKY=; Date: Fri, 23 Oct 2026 09:45:41 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , Teddy Astie Subject: Re: [PATCH v4 07/30] x86/spec-ctrl: introduce Address Space Isolation command line option Message-ID: References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-7-b68b66652266@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20261019-asi-hvm-v4-7-b68b66652266@xenproject.org> On Mon, Oct 19, 2026 at 08:42:38PM +0100, George Dunlap wrote: > From: Roger Pau Monné > > Introduce the `asi=` command line option, and the opt_vcpu_pt_hvm and > opt_pvh_vcpu_pt_hwdom knobs plus the per-domain d->arch.asi.vcpu_pt > setting they control. 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 adds a boot-time warning that the feature is not functional and > is meant for development only. > > The mechanisms this option controls apply to HVM domains: an HVM vCPU > already runs on its own monitor table, so a per-vCPU per-domain area > needs no work at context switch. d->arch.asi.vcpu_pt is therefore only > ever set for HVM domains, a PVH hardware domain included; PV domains, > a PV hardware domain included, are unaffected. > > Besides the plain boolean, `pv=`, `hvm=` and `dom0=` select the features > for PV domains or HVM domains other than the hardware domain, or for the > hardware domain, PV or PVH. None of the features applies to PV domains, > so `pv=` has no effect, and `dom0=` acts on a PVH hardware domain only. > > The boot log gains "ASI features for ..." lines for Dom0 and HVM > domains, so hardware-domain-only configurations remain visible. > > 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, Claude Code:claude-opus-5-5 > Signed-off-by: George Dunlap I don't have a strong opinion on the comments below, I think it would be nice to adjust some as they likely lead to less churn in the followup patches. > --- > Changes in v4: > - Docs: "domains" throughout, not "guests" (Roger). > - Group the per-domain settings as one-bit fields of d->arch.asi > (Roger). > - Rename opt_vcpu_pt_hwdom to opt_pvh_vcpu_pt_hwdom: it acts on a PVH > hardware domain only (Jan). I would leave opt_vcpu_pt_hwdom as-is. The fact it only acts on a PVH hardware domain is a transient implementation short-coming. I don't think it's worth introducing a separate opt_pv_vcpu_pt_hwdom when PV dom0 support is added, or having to rename opt_pvh_vcpu_pt_hwdom -> opt_vcpu_pt_hwdom. > - parse_asi(): break in the success branch and fall through to > default:, rather than a default: label after an else (MISRA C:2012 > Rule 16.2; Jan). > - Message: enabling a knob adds a boot-time warning; it does not taint > (Roger). > - Add the pv= and dom0= sub-options here, beside hvm= (Roger). > > Changes in v3: > - HVM only: drop the PV knob and its interaction with XPTI. vCPU-PT > applies to HVM domains and to a PVH hardware domain; the Dom0 boot > log line says None for a PV one. > > Changes in v2: > - Added to the series > > Changes since the previously posted version: > - Include the hardware domain in the development warning and the boot > log summary. > - Make the opt_vcpu_pt_* knobs plain booleans preinitialised to false, > dropping the late -1 resolution. > - Documentation: mention possible protection against unmitigated > attacks, and state that hvm= does not affect the hardware domain. > - Rewrite the commit message. > --- > docs/misc/xen-command-line.pandoc | 29 ++++++++++ > xen/arch/x86/include/asm/domain.h | 6 ++ > xen/arch/x86/include/asm/spec_ctrl.h | 2 + > xen/arch/x86/spec_ctrl.c | 82 ++++++++++++++++++++++++++++ > 4 files changed, 119 insertions(+) > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index a6f08463d1..839d06da26 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -202,6 +202,35 @@ 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,dom0}=, > +> vcpu-pt= | vcpu-pt=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. > + > +The mechanisms currently implemented apply to HVM domains, including a PVH > +hardware domain. PV domains, including a PV hardware domain, are unaffected. I think we might want to drop this. It's an incomplete in-development feature: we don't need to mention explicitly what is and what is not implemented in the command line documentation for the time being. > + > +* `pv=`, `hvm=` and `dom0=` enable the features for PV domains or HVM domains > + other than the hardware domain, or for the hardware domain, PV or PVH. The > + plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain > + out. The forms naming no domain type (an un-suffixed `vcpu-pt=`) > + cover the hardware domain too. > + > +**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` gives each vCPU its own per-domain area: the per-domain slot of > + each vCPU's monitor table maps a region private to that vCPU. > + > ### asid (x86) > > `= ` > > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h > index 212daae1f5..12f79feb42 100644 > --- a/xen/arch/x86/include/asm/domain.h > +++ b/xen/arch/x86/include/asm/domain.h > @@ -474,6 +474,12 @@ struct arch_domain > /* Don't unconditionally inject #GP for unhandled MSRs. */ > bool msr_relaxed; > > + /* Fine grained ASI related options. */ > + struct { > + /* Give each vCPU its own per-domain area (HVM only). */ I would drop the HVM only part, it's a transient implementation limitation, not a design one. > + bool vcpu_pt:1; > + } asi; > + > /* 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..d84f985e82 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_pvh_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..66c878212a 100644 > --- a/xen/arch/x86/spec_ctrl.c > +++ b/xen/arch/x86/spec_ctrl.c > @@ -86,6 +86,10 @@ bool __ro_after_init opt_bp_spec_reduce = true; > > static bool __initdata opt_ibpb_alt; > > +/* Give each vCPU of an HVM domain its own per-domain area (vCPU-PT). */ > +bool __ro_after_init opt_vcpu_pt_hvm; > +bool __ro_after_init opt_pvh_vcpu_pt_hwdom; > + > static int __init cf_check parse_spec_ctrl(const char *s) > { > const char *ss; > @@ -487,6 +491,69 @@ 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_pvh_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_pvh_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; > + break; > + > + default: > + if ( (val = parse_boolean("pv", s, ss)) >= 0 ) > + /* PV domains are unaffected. */; You might want to print a message saying that the option is ignored for PV? It will go into the console buffer at least. > + else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) > + opt_vcpu_pt_hvm = val; > + else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) > + opt_pvh_vcpu_pt_hwdom = val; > + else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) > + { > + switch ( val ) > + { > + case 1: > + case 0: > + opt_pvh_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; > + break; > + > + case -2: > + s += strlen("vcpu-pt="); > + if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) > + { > + opt_vcpu_pt_hvm = val; > + break; > + } > + fallthrough; > + 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 +747,13 @@ 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\n", > + opt_dom0_pvh && opt_pvh_vcpu_pt_hwdom ? " vCPU-PT" : " None"); > +#ifdef CONFIG_HVM > + printk(" ASI features for HVM VMs:%s\n", > + opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); > +#endif opt_vcpu_pt_hvm is defined unconditionally, so you might as well use: if ( IS_ENABLED(CONFIG_HVM) ) printk(" ASI features for HVM VMs:%s\n", ... Which is a bit nicer than the ifdefs? > } > > static bool __init check_smt_enabled(void) > @@ -1866,6 +1940,9 @@ 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.asi.vcpu_pt = !pv && (is_hardware_domain(d) ? opt_pvh_vcpu_pt_hwdom > + : opt_vcpu_pt_hvm); > } > > void __init init_speculation_mitigations(void) > @@ -2158,6 +2235,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_pvh_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"); I wonder, could we add the warning in parse_asi() itself? I know if would then also trigger for asi=0, but would avoid having to remember to expand the condition here every time a new option is added? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 08:43:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 08:43:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458992.1671050 (Exim 4.92) (envelope-from ) id 1xKArZ-0004X8-2e; Fri, 23 Oct 2026 08:42:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458992.1671050; Fri, 23 Oct 2026 08:42: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 1xKArY-0004X1-Vl; Fri, 23 Oct 2026 08:42:56 +0000 Received: by outflank-mailman (input) for mailman id 1458992; Fri, 23 Oct 2026 08:42:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKArW-0004Wv-M1 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 08:42:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKArV-005Q2W-UV for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:42:53 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb1e05-e002-0a2a0a5209dd-0a2a4504e884-34 for ; Fri, 23 Oct 2026 10:42:53 +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 6adb1e0b-b57f-0a2a45040019-94a39b0c98f8-3 for ; Fri, 23 Oct 2026 10:42:52 +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 69N7Euvb2965191; Fri, 23 Oct 2026 01:42:48 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021083.outbound.protection.outlook.com [40.107.208.83]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4hf974c5wu-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 23 Oct 2026 01:42:47 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by LV3PR02MB10690.namprd02.prod.outlook.com (2603:10b6:408:27e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Fri, 23 Oct 2026 08:42: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%4]) with mapi id 15.21.0546.017; Fri, 23 Oct 2026 08:42: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=3lLZT2uOTMlMtegXPFOCQScjPsWxraWK9hiFWH7Bz yc=; b=f1gGTMiGNBhK91eVVQ87u+PFU42OK1pVynEL6pmpI7vJ20PHawCnJVIQv IE4ChUVbwVOPsGAjsLbpulmG7yn0C0aYZDb1HXAW7IEZ96CU0UVYP0hPrbtoz28/ Wr5aGLplKkwbePrMz4xzMNFvz0OR7N5aIiH9HI7lhpe+lUcctZ8YFHc+M5mtsPDg QumxXwTw3OhKrf5T/1xNRGskzTKBCcHCKC+LEZN50/C/QOigjLGOlMgLyEhIHrmu N5eflt2ik9aUhx78M7zkOhS/8wh1vLFF5piy4rCshKc5yzcmncnmwPA1QgNT9/jZ 0mhFAKjh7qUitfcey31JMpEIMBv7w== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ckC+IO9GaG9i0Qn4SgTKjKQtxFztEZrUeY/sTvvPe5MExAPimDPrhCalJvJohOlDcaZxcx2AELms+pjsTmEXc9smpjwQke9TQuecoSflzVOw6M/GNOYgcMHFuD+KNoIOtd9ANpnicUBK9TssL2rrx1uqTIpCk54Lw/E6oeMB6FD7vlr/vceUNMJ8qddSC5BbdyrIBA/g9TVRNXibQdIAebF8Nz4Jo7gc0ACJVxjgfLieHpybSsxYtTevBf3ObEo147x6VnL+SwNHwAQkOqq9tVdWwrY6suKjXLw1W+BNYjzXGamq1XGzkG/OJwcwbIRiK+tLnCSF9BOwA/uJsH7EQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3lLZT2uOTMlMtegXPFOCQScjPsWxraWK9hiFWH7Bzyc=; b=bN0KPhzFdIDShvQ4gVFCwrGilSUiF+6wJOBIHwikRDJ1K1yZkhm4Uu4Fx+CmqP7O2i6El/ZLeuXCmAlVWFE7oz+Ipo+j/6KQIJz0eCAl2aYMbkpcpjVfZs/EzVeodNd8GjSfyNz6y5bbFHjY39pwsYGLBDQq2AAtHDDNPc5GEA2JqfJ/dXdNtAgIJf/yOt++Coezbg/PYyrduNdLaszA8+LxllXyt/FKIYh8S/GoToOmabEwctQNbm+zgZa6ReGyonpatnLLBrd5npeB8vH4R8kN+PfKtTxX5+4/lSXub6Ue0bQoGgs4QSajZPkKXZlsoka/d3LXcTussToqYC0Dcw== 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=3lLZT2uOTMlMtegXPFOCQScjPsWxraWK9hiFWH7Bzyc=; b=LHlPG5KaLQeneo/SvMYGy+WqNsdhV57GyHJng9/f1WmrLDYs/eLaAn0fdvVXnnclf1s3gKd74zKP01o6BeqqWdXkjO5oXbOOmSgYq8MBS+vcYQVGUx+Fxs8jaWA+3rH51Ch2P2n05YasbRM1TSwSi8kFCWqNnCpBKufumixpzk6y+11Gk2lq0ZV1etNvGnFgWVWcjzEeK2mg9MA6/I8C7/6X0chZFXW/YZ79gaH4fHnBQhEXe9CgvgBrDbDLcqqDtMi0TID1xeSAF++iRvYuavCoKKfzN46VmRN3m9QF/Po9gpiGBH2J1dctPTRPGZSGdoIb1UalPRNaulcI2WsBvQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com; Message-ID: Date: Fri, 23 Oct 2026 09:42:39 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 00/28] i8259: improve qdev PIC modelling (and misc fixes) From: Mark Cave-Ayland To: Peter Maydell , 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 References: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Language: en-US In-Reply-To: <20261019120517.1448687-1-mark.caveayland@nutanix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR3P281CA0165.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a2::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_|LV3PR02MB10690:EE_ X-MS-Office365-Filtering-Correlation-Id: 9dbe548d-d037-4f41-dd9a-08df30e19bae 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|261022105027099003|261022075727099003|56012099006|261009223027099003|10067099003|261021123027099003|261021121427099003|22082099003|18002099003|6133799003|3023799007|261022113327099003; X-Microsoft-Antispam-Message-Info: 8v9DCGJVFigCfgeTIlXwV1lUbAsWpbrqRSoaBZpfBrWdcou0eeHo+znYDl3uD6/s/L/NZP4F+Tobmctbay9ukN2OVIAQkgXRAduFB5NEVA6nulXyIaomzdvdRGVVKopArUy5rr6QhzJUDoWQ1RHz8PlGngEZOsc42rMR46kxtCkVokn66/qIwggof3jhNAqeiwghKJ+nSDYYp8DhGv1LuSujjdK/3SaT+uuvJXvtmbaaZjnmqzHQpjYGB44xTWR9kcZlQdy+N4Pos2Zl6HkQMTcBshc1gIKXUqEsXVb35hbDY5rMGQmxN2kRrTU7KU+i5GjNgfzQauDYUoz2AnDPe+MHwaYhFEW6ihN5SLjbFr86XjVJY/6XkkYTkqirqwFVei3mwzZOqWarPUf3DTxFx1imllM71DjdPG08ZumcO9yX96CFVFeUS6HlFvjV3EyO0c4VEgv5BbAWes1JcaJsrU528uC6ODGg4W0ACLt95aaEpmKtsIaahh3cZAynITSjWHuEJSqwVmPSIiKxwQlzrVZspfjJXM527OQwOUVnClk2ElFH87+iFvPsyB8TK6SXd6QV27TQUekSF6n+uagKAvZJTy7CFMZjSCM5tJ2xnbP4Uid2GPmKf0nemOasZBngoYZ9UfomvZIFWuuUjB81BEXhQbTNybW7wnmfGVqReWM= 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)(261022105027099003)(261022075727099003)(56012099006)(261009223027099003)(10067099003)(261021123027099003)(261021121427099003)(22082099003)(18002099003)(6133799003)(3023799007)(261022113327099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QlY4VmYyWExOWjJTWUpHYk4vTHFKcGZUSXhxMDk3NCsxdjdpVXAwcXI5Vmli?= =?utf-8?B?bFFVa3lOb1BmOHpKbXc5U0p5QTUySlVIVFl3d3NWSVJNc21SZzN6QmQ1SmJr?= =?utf-8?B?bmhsTElmOTJuMU01UVhzelJXUjVqTW1IR3c0YzFGMlIwRzNhQ25jVDdVeXND?= =?utf-8?B?WDgzS1RXdDc2LzN6a0R3b2JnWEd2ZmU1U0loUXVOUnR0bzc1VmFBc2NyMHdL?= =?utf-8?B?YWQ4VlJweWZQcEU2c3IrcWNXZlNTa1JtbGRyNUQxZUt3ckdTbXJXckYvNjhr?= =?utf-8?B?Q1hTWitxWlhLZUFobFBadElGdU95Q045TFlnZEh2UkhvZDhEbnRCdW1yNUMv?= =?utf-8?B?b1VQbHRrWCs2NWQ3NWVjWUo1ZEZ6ZUdxWUE4b09ldWVYTTkwU1Nib1E2TzRN?= =?utf-8?B?OVQ2c2psOExlWHBvdUNxdzdzNUJqckg2WjRoQjEzYTRUelY0Ty8xVE1IdEFZ?= =?utf-8?B?NmsvTU1vOTVFelpjY1VxMWxLYitHRkRVOFk1c3lacDVzZVJxR2hxZnNMaTN1?= =?utf-8?B?c3NzdlRTd2UxSzNVSWZLMkRFd3Mra2p6NElXd25pbGVzUXpSQURJUmllazVU?= =?utf-8?B?VDQ3S2UyeXQxdUxSbGw3LzBrOHFhOGR5OFhad1k4ZnNCdVNuWTRmR1Z0K2p2?= =?utf-8?B?cmEzakJHSTdKbElPOER2TCtvSEtPR05NNVRIaUxRRGhlUVRWNnFiOHdCVXlj?= =?utf-8?B?ck5XRVBRaTA4cVFHcXl6OEgvTmZ0RWwwTUYybWFLOWx4aEluM1AzWmhlbTll?= =?utf-8?B?YzVkK1RoR0ZaOG5waVljZXpDSFN0bHdHdVNMWWJOSTdjd1FOdjBvOUIvUHFm?= =?utf-8?B?TXFNMkNhd0xyVUE1WDE0MG41ajd3QitqdE9aLys3OXdhb3NhNjdjeVBxS2ZM?= =?utf-8?B?WXQvOFNmUlQzWHN6ZXFFdm9FMVZaSVhUdlYrdUlUYTIyNXVldlcxNjRQR2g0?= =?utf-8?B?eU8yTUpleG91N1FIL0lXS3NIdUJwWmlDUzBxY01Pd3RlMjVTVklGUWV3bm1O?= =?utf-8?B?SCtUZnhBcUY3dHFTV2I5SkwybURMSGhUcHVYaHhuUWFVcUZmWDhVVFpvdFdt?= =?utf-8?B?UkpXejZ2bnRIbXM3VWFZUGpxM1ZiY3Y1QWg5cEk4bU81L1ozK3NKbnNsWFM3?= =?utf-8?B?YndpSDdOeDk3UnM1WHFWbTFsdlNDZzd4a2twUy94UlJycmx6eW1qMUlkNGtj?= =?utf-8?B?SEJYWGN3QzFpRlRaRW10WTMreDVpUEQ3ZGFmVytNLytRVFQ2ZzRTZS9ldHV2?= =?utf-8?B?bU1wV0dlSG0yenJsZ2JLcjRocmV1ZlFFQzIyRGNmRVlOOGVSYWFsMWxWS1Vp?= =?utf-8?B?eDhwdkxBcGFPbDRsWTZya0pweSt0QkRpVEFhUFByQzFBSFZmb1NvWUt4ZjJN?= =?utf-8?B?ODZ3QzR5cDRDV0pMendBdUl5SkQvY1JGRXR3VlJxdGdQY3VZalh2VWJtL3Jz?= =?utf-8?B?VVF4Zm94aXhCa1pkK0lGaXBndm55eTdmdDZZL3daSzBHa3M2MUlKZzYwOWlv?= =?utf-8?B?ZXJWTEFXY3ZKTDF0UjJsakNBSHZMczZhbTdoTVFGRVg3VDR1NThHK3pFdllJ?= =?utf-8?B?Y1BXcmxiWUM3Z1A0SDc1T3pBRzVKeVlKQ0ZBL1RYWTRocnFpYVJRSW9XTmtN?= =?utf-8?B?T0ZMZ0NZOWQ1UGJXN2hCSXVGODVCOElJTmNFUmc4UWJpQUkzQXJxdkR0d3cz?= =?utf-8?B?MzcxMGsrWWkwNnhESldCczhPWkY0ZVdMVHlPTHQ0cjhOWTFsRmZmNkp3bXNl?= =?utf-8?B?MUhmRFFaV3JhOTdnem9xaGVWWk0wL3BwUG9WOUlybXhUYmtXVUhJelI1Vysv?= =?utf-8?B?WW1MeFNCZUdkazRBMHhTbEkzbHFLLzhUakV5UTMzRkJjWWRaT0VjVEQ4U3ZP?= =?utf-8?B?dFRCYXUvZ2xKMDM1dW8vRTg5cUFUeTh4SGg5Y1ZkOENTaU4rbGxLc1U3ckpt?= =?utf-8?B?V2JxNXJCYk5kUlh0U0ZlZW5odGplNTFWSWo5UXltdEN6V2JVeERvUzNBcDV5?= =?utf-8?B?SnFGd3FESElrOWpLVVV4QzhhTGEwbUxwU2tMbGRSdVNlTWdjZkwrMnlMWGdt?= =?utf-8?B?WUNucGVLK0tSOHQ4cmE1WU1UajhTajRPQm9KNU1PSlFsRXZaTEgrQU5DRk92?= =?utf-8?B?QUxObzBjZzhvSGd3a1hucUdEZEFrOTl3b0tiS2NKSkV6cFZJRDd6VVlzMEhH?= =?utf-8?B?Mm5wM29sWVllZUVXa0d5eDE0Y1FEenM4SVlSVUVWL0FuWFRHbnh3a1k2RGFM?= =?utf-8?B?SENKQzNnMll3K1hzVklKQUc4MWxIQ3pyRk9MU2pKNlVSY05maForNENaMVQ5?= =?utf-8?B?N2xRdGsraEwxTkc2dm1hUmNNcG5WTHQzTmk3TitWTFlxRzhFRFRITmIrTVNz?= =?utf-8?Q?/albFR0l5ZSTk0kE=3D?= X-Exchange-RoutingPolicyChecked: 2DrViv8RUPfHTUYVFJRgCd0Ki7bBtlPt2VknGpfHkF+dfpHmMzwLfe11vVOwTA4rDSzTJra9G/2GgqC1dK4cUMNRCbYaoj54TkP4pI5Qs9SceX/vDeJtmid7xbsIwttdSn45gsuA7lMPvZke62IwFPxrmPMl9goa8LfpBrZmqT1gxM8qbiV1K+IYqieKs25j/++k3gXG/KtNMs4pbaoacdKzE+5GRR4EGQQ2E13SNgb8P9T2aIYkj8EF+NPWLY2y+mbVLXy6Sbs/wWcV/1wIjVEs8i+bCE119v5cHpXtxKuCqoEwEQmYz2abmBOItDbcAfZ09x2R6Z0YZmNr1XeaNQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9dbe548d-d037-4f41-dd9a-08df30e19bae X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 08:42:45.1274 (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: Jz7KD/ndaFRc5AyTe+gl4l/p+K6+KVYJHCQFIVp0f1d0h6Ho0vK3l8M7QlemPYwkTCni+Afb+M1LXy6Irlhpu2QC/1k7cGYvfOsOZUdm4Tw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR02MB10690 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDIzMDAzNCBTYWx0ZWRfX2J5uSaNbGaTX 1yvdw0zqeMMTsLV2mCpqhbM3MC4Qtlr9e2KRxKk6bYrakfRsAgsjC8xi7wj4CF75OtDLuTN5qnj SLfVAZ0HG3FXzI+6ZPZpP/mCCs5m4ASfk0u2Y1Cm2mLC0lmt1HAw/n0DXJ3f8nehKZh6Y99o2aO 7+iQmlQUUcqvIqo2nWpDJpWEHkhUONQgfsDdEPPwCU6GztYPTPiJDVV3kU4XEPPDNgtMkaCPBvE R3YVfY9FQOW/4apUFhB6L/P2g4CT9CYBUwpeYPuX5mYP+GHQJUSiya+QMNWKCxTjnwh9w8qKQEQ +2+koQyaPAHy/zCfBMRNSkXau3SedVFVHpKhdLsh+aTvb+rfpRrGtmtPKQK7R0xfVBHouwXy2xJ oHerFrUs78R8s+Ie5W5xT8+GRn/ZoN30Tw6mjQBblncnCxjEPIk5L6xgPkkOpbu6bKSu3iiwZ+I AYF/mzEeBw2la3Z59EA== X-Proofpoint-GUID: y_EuDdoQT9oWsVVCLl-TYaUXSKEsGtk6 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDIzMDAzNCBTYWx0ZWRfX4QOysaXreEa0 MtYKEC8iYTvVqAuYSUQHx6en2KiL0flObL3qNK62X2Mg5ZH9p6ecIKwFZPIAQlJGxjmBCt3dDlH uIYVVf3/8+ZaOeA69NJI4Mzo4ahjQEA= X-Authority-Analysis: v=2.4 cv=VaNir1p9 c=1 sm=1 tr=0 ts=6adb1e08 cx=c_pps a=JzGR8r3o28cAtrGeABx37g==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=K9gjxBCPemF015cAt-0A:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: y_EuDdoQT9oWsVVCLl-TYaUXSKEsGtk6 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-23_02,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1792744972-C18D1B50-B0B4A0DC/0/0 X-purgate-type: clean X-purgate-size: 4802 On 19/10/2026 13:04, Mark Cave-Ayland wrote: > 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 25). > > Signed-off-by: Mark Cave-Ayland > > [Patches still requiring review: 18-21, 23] > > v3: > - Rebase onto master > > - Add R-B tags from Peter > > - Introduce isa_realize() function in patch 18 and use it in patches 19 and > 21 to fix refcounting for ISA devices within the PIC container device > > - Don't pass input IRQ 2 from the primary PIC when implementing the cascaded > PIC configuration in patch 20 > > v2: > - Rebase onto master > > - Add R-B tags from Peter > > - Remove FIXME from commit message and rename trace event in patch 13 > > - Introduce a separate I8259State for TYPE_I8259 and KVMI8259State for > TYPE_KVM_I8259 as suggested by Peter > > - Keep but rename the associated classes for TYPE_I8259 and TYPE_KVM_I8259 > and move the DeviceRealize function into each one, instead of keeping it > in the parent class > > - Add patches to make variable names consistent when accessing > I8259CommonState from child objects > > - Update the comment on patch 19 to reflect that implementing the > cascaded secondary is actually a bugfix > > > Mark Cave-Ayland (28): > 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: rename PICClass to I8259Class > i8259.c: introduce TYPE_I8259 device > i8259.c: always use cs for I8259CommonState variables > kvm/i8259.c: rename KVMPICClass to KVMI8259Class > kvm/i8259.c: introduce TYPE_KVM_I8259 device > kvm/i8259.c: always use cs for I8259CommonState variables > i8259_common.c: always use cs for I8259CommonState variables > 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 > isa-bus.c: introduce isa_realize() function > 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 I8259State 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 | 11 +- > include/hw/isa/i8259_internal.h | 19 +- > include/hw/isa/isa.h | 1 + > include/hw/xen/xen.h | 2 +- > hw/i386/kvm/i8259.c | 250 ++++++++++++----- > hw/i386/pc.c | 2 +- > hw/i386/xen/xen-hvm.c | 40 ++- > hw/intc/i8259.c | 470 ++++++++++++++++++++------------ > hw/intc/i8259_common.c | 225 +++++++-------- > hw/isa/isa-bus.c | 5 + > stubs/xen-hw-stub.c | 2 +- > hw/intc/trace-events | 8 +- > 12 files changed, 648 insertions(+), 387 deletions(-) Thanks for helping review this series, Peter. Now it is fully reviewed, I'll send a PR for this from my qom-qdev queue later today, unless I hear any last minute objections from any x86 maintainers. ATB, Mark. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 09:26:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 09:26:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459009.1671059 (Exim 4.92) (envelope-from ) id 1xKBY0-0001GP-Cp; Fri, 23 Oct 2026 09:26:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459009.1671059; Fri, 23 Oct 2026 09: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 1xKBY0-0001GI-92; Fri, 23 Oct 2026 09:26:48 +0000 Received: by outflank-mailman (input) for mailman id 1459009; Fri, 23 Oct 2026 09:26:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKBXz-0001GB-1C for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 09:26:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKBXx-00C7B4-SC for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 11:26:46 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb2845-2eae-0a2a0a5409dd-0a2a450cb25c-44 for ; Fri, 23 Oct 2026 11:26:45 +0200 Received: from [40.93.201.53] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb2853-f479-0a2a450c0019-285dc9354111-3 for ; Fri, 23 Oct 2026 11:26:44 +0200 Received: from SJ0PR05CA0111.namprd05.prod.outlook.com (2603:10b6:a03:334::26) 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.546.19; Fri, 23 Oct 2026 09:26:38 +0000 Received: from SJ1PEPF000037A1.namprd04.prod.outlook.com (2603:10b6:a03:334:cafe::6d) by SJ0PR05CA0111.outlook.office365.com (2603:10b6:a03:334::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.3 via Frontend Transport; Fri, 23 Oct 2026 09:26:38 +0000 Received: from satlexmb08.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.546.15 via Frontend Transport; Fri, 23 Oct 2026 09:26:38 +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.53; Fri, 23 Oct 2026 04:26:37 -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.53 via Frontend Transport; Fri, 23 Oct 2026 04:26:35 -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=GMV0OLvgs3+1StzNMrRLuavMqh9rQyyaZZUh5aMouFfJvmCNaiZoUNukXfU/iGyfkIRocQ3WdoZ/FirLr/4cwVPI4C2DbcJcE9QQUxj3onoQSV3Zmqs3g3mp+c0mpFbrP3ldg0eOGP24MeNENkgJYNdVcQTWtSz1xEVe0ArtTDR3sBIT7GuhwnC1XLVfM9BsgcSepVY/qmtP6CwP2KbHQb3kujRu2UPTOF812FJsGDJaMoMJNHduk3PlF7DjQdPyrPDrcXbrDiQxjuC4CxV1afI+sCFSxxpwtYN5RA2CzjuzRmx54H0IEoq/CO3Tngirj/XPaH+dRBz3/1gZqOjpqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RJ+d/CHcr9ey5774wLha6b+iwnhehERCqPKf1kXEU9Y=; b=goAYM8UeywbuolFf0uBRHTw4Fd5nInOl/IO68Hf4oa8VIsmqQWj4sG1NTdfGzoO7hMPscVyoU1IIig4MsDA+d3Vc4qhcmUCCipSR//gdIZpAf9pr2NdsKyEZ2A8iLD6FnArjYBAKAVNZYycW031u0/7+9pAc3XdUOWuDB8oC6j+QOzv01bMnoneeJbS4Jb+lQgCUxx0DGPTBaKkokq1z2U9YQduCcfcphLb67t4NGUS2asNcoxpg+1uS3H2xOyWD+7W6ZXKhwrKCvcCGuEXcdXFPOGa+BmhiBMW4QbC86m4+Dfq+x77nZe54zLpfPtPrLGnkB7vY9dQ6RkHRiADRYw== 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=RJ+d/CHcr9ey5774wLha6b+iwnhehERCqPKf1kXEU9Y=; b=mbLns+HE+9a2w87XkdvmlmXD2Ot3bdEGrqdzLg6+uLnWSmchWyvpt2Xc7qCcRRMga81a0QbnFcJmUT+KrOqYRKdKPVkWvBCNZtHUQ8a2YdV7Nu8Ghzbi5E6p+JLEtlqBjIp68bEv1MRRIoQ4GMoyNC+EHD6/HDztAiezNznZ2ZM= 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: Fri, 23 Oct 2026 11:26:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] 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 References: <5bf81a2b31f182d1339e89fb65e445bc20b1a865.1792400044.git.mykyta_poturai@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <5bf81a2b31f182d1339e89fb65e445bc20b1a865.1792400044.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: SJ1PEPF000037A1:EE_|SJ0PR12MB6927:EE_ X-MS-Office365-Filtering-Correlation-Id: 76dae0f3-c092-4247-cd30-08df30e7bd9f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|82310400026|36860700016|11063799006|56012099006|261022075727099003|261022105027099003|261021121427099003|261021123027099003|261009223027099003|260925022911599003|260925021911599003|260925021311599003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: m0R+LZ1nXQKN20ifRFCS5aSz94lmWt8hM8UMnRxRZqiwtBCGoPBFZ2U8fNg4RtpQbniovHdd/AcMy6O4BaKGxeu9xpFZMc+om2xo8Dzd5TapZwXJC2Qv03wxGlgkmW3siBUFset6Ap5cnSXz3QNR4wUHaqistwb7M/TqmAQDCWItT1RGNMsuUXz3T5jDqrrlpquSx+WZ2B8lhPhWKq5FqjTD9HfYX3mZBP8Jq9sswGBmNM48kTW1MVRSHF2gfJaErVZLPtCFs2KVIXgPk8SWdpWBrkte2FC6My/8MRvY/Xof9txyr9r50Fb3GELsyNSLI07vEhnvZ1ncIizdRsLqjPVBVFKD848kofrhTK8rYK0upSP1MDlUXj+e/pm5lpBwdQ68SVQ3Ey5FtQqBU1EbLZ9jp5XeGDuzAAWkIGI2Msvgm2xNjX1bZ9M2xctn3S2AlaTpznXQwbRcmnbU/1P0sjHY4j4Pv39b5tLbvN5rW/vMnVNI5MIyYuwEy47gJ5dXCFwKtDf1w4/7nFykRt04V/uqldWCND5s7j+IdxnFT90fCTOvNay7rNl0xgfJW3HW0INtOSSEBxZmGeuT8neGIPblPtGIkgAiBXmLqM2LLxdnQFnQzAZlJu9GomOaJmlDoq6VZ4/6HVja6AWjNgCNpg== 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)(1800799024)(23010399003)(82310400026)(36860700016)(11063799006)(56012099006)(261022075727099003)(261022105027099003)(261021121427099003)(261021123027099003)(261009223027099003)(260925022911599003)(260925021911599003)(260925021311599003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: zUEmGwsVoHg4MbNNLWbT41hr7euzdTSc2CneR8pLkLU00YMkrIqMawjC4OyEu9PA7FV9WKqMlr06Za6yHdUyU9CFylhh0E5lQABFKTgVNE0J8zWpDAwS6cZMnv+dmJjGP9H9laW0SGj8T0WJNGCgUvSEIjT8sNahMUN5nTNogydF2t0f6wnD7//UHKEXahF8+aQKEOT5peOGLFqg5tP91Hc+7LqZgVQKlXnbpvUtXzgogJN6euwHu7lWFC0sAS1uh80fqer+rmUMpTaCzSiiaPPSdDLYQeM0nhSkKBsaWuTKmfEiKC6UWnzlZuHybnaa4/DQa7eoYmNRF2vdd7DvOw7+4daU3u6WAdQKw+B2Ij1Hs9yrCx1uJxDP/c9GUWtUYhJUrp+2/0vcoJxWePJhrlr5ZGVx/dbiDOELIIcrd8P6OHzZFUIkqoS3CyW2EqMt X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 09:26:38.5630 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 76dae0f3-c092-4247-cd30-08df30e7bd9f 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: SJ1PEPF000037A1.namprd04.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-d25034/1792747605-008CDA5B-FCEF4C82/0/0 X-purgate-type: clean X-purgate-size: 4361 On 19-Oct-26 10:59, 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/ > > V4->V5: > * drop dead domain lookup on the DT path > * remove assert on arm_smmu_deassign_dev error > * drop redundant IS_ENABLED(CONFIG_HAS_PCI) > * fix indentation > > 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 | 72 +++++++++++++++++++++++- > xen/drivers/passthrough/arm/smmu.c | 4 +- > xen/include/xen/device_tree.h | 5 +- > 4 files changed, 77 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..e1af615985 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -1493,6 +1493,75 @@ 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 ( d ) > + { > + /* > + * 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)); > + > + if ( arm_smmu_deassign_dev(d, devfn, dev) ) > + dev_err(dev, "Removing anyway\n"); > + } On a DT path d is always NULL. On a PCI path d is always non-NULL. So this entire block and ... > + > + arm_smmu_disable_pasid(master); ... this call can be moved to dev_is_pci branch. > + > + 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); No need to call this for PCI device. With the remarks fixed: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457861.1671084 (Exim 4.92) (envelope-from ) id 1xKCLa-00084C-P2; Fri, 23 Oct 2026 10:18:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457861.1671084; Fri, 23 Oct 2026 10:18: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 1xKCLa-000823-IZ; Fri, 23 Oct 2026 10:18:02 +0000 Received: by outflank-mailman (input) for mailman id 1457861; Thu, 22 Oct 2026 08:30:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJoC0-0006uO-Jr for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 08:30:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJoBz-003upZ-IN for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 10:30:31 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9c9a0-bab6-0a2a0a5309dd-0a2a45069cf2-36 for ; Thu, 22 Oct 2026 10:30:31 +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 6ad9c9a5-195a-0a2a45060019-aa0a817c6355-3 for ; Thu, 22 Oct 2026 10:30:30 +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-353-7m63-_WdN--ms9gOad-qrg-1; Thu, 22 Oct 2026 04:30:24 -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 4C984180060C; Thu, 22 Oct 2026 08:30:18 +0000 (UTC) Received: from jtomko.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EC8EA1956088; Thu, 22 Oct 2026 08:29: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=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=1792657829; 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=xexW0rNqv/GKFX03e5NGVfizRBWHHld9j1Z0S71dlRQ=; b=L/l0KIX/GpSI1rYtzQj5Zz8MLfXEfELkU+2GGh0j7S9nmYaLKqjdxOSm70skevOs4b4YQ7 +n70T1jEUcdq/1Ot6ie61WSg4Wupq4yF59GSTg5zv/a8t1sPHSBjQrqx+FLZKxbAw0Nm4V FVSGY8nhN7XDEUb9sd4E1tDxYzauFuE= X-MC-Unique: 7m63-_WdN--ms9gOad-qrg-1 X-Mimecast-MFC-AGG-ID: 7m63-_WdN--ms9gOad-qrg_1792657820 Date: Thu, 22 Oct 2026 10:29:47 +0200 From: =?iso-8859-1?B?SuFu?= Tomko To: Markus Armbruster Cc: devel@lists.libvirt.org, marcandre.lureau@redhat.com, qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?iso-8859-1?Q?C=E9dric?= Le Goater , Cornelia Huck , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?iso-8859-1?Q?C=E9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: Property types changed in this series Message-ID: References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <87tsmfkoej.fsf@pond.sub.org> <878q3qkz6f.fsf@pond.sub.org> MIME-Version: 1.0 In-Reply-To: <878q3qkz6f.fsf@pond.sub.org> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: IFx0eaVoljhUs-TL2N-vHXORC9Tr31UWu5ZKTX4cTiU_1792657820 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1792657830-F6C7777B-1BBAC0EA/0/0 X-purgate-type: clean X-purgate-size: 610 On a Thursday in 2026, Markus Armbruster via Devel wrote: >Libvirt developers: does libvirt use member @type of the reply of >qom-list, qom-list-properties, qom-list-get? > The code for getting CPU properties uses qom-list-get for new QEMUs, where it checks whether "type" is "bool". I think that can be easily converted to just check for the JSON type. Jano >I'm asking because Marc-Andr's work changes many values to add a more >useful replacement. I think we should deprecate @type. I'd like to >find out whether we need to preserve the values for the deprecation >grace period. > From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457450.1671072 (Exim 4.92) (envelope-from ) id 1xKCLa-0007v5-8a; Fri, 23 Oct 2026 10:18:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457450.1671072; Fri, 23 Oct 2026 10:18: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 1xKCLa-0007ux-4y; Fri, 23 Oct 2026 10:18:02 +0000 Received: by outflank-mailman (input) for mailman id 1457450; Wed, 21 Oct 2026 16:30:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJZCX-0004re-Mj for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 16:30:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJZCX-008U6r-3Y for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 18:30:05 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8e88a-bab6-0a2a0a5309dd-0a2a4502d226-18 for ; Wed, 21 Oct 2026 18:30:04 +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 6ad8e88b-6ca4-0a2a45020019-aa0a817cdd39-3 for ; Wed, 21 Oct 2026 18:30:04 +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-5-uVm7wy9uPnqna-YWwQgM4A-1; Wed, 21 Oct 2026 12:30:00 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8BB8C195396C; Wed, 21 Oct 2026 16:29:46 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CE23F18005B7; Wed, 21 Oct 2026 16:29:42 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 6C44321E6A04; Wed, 21 Oct 2026 18:29: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=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=1792600203; 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=gZqi5d3mOF1KjfwoAQKfIbSpBBQZDfbhPtfOzYqQUmI=; b=IVpoXcVS5nRf6ndwi0P3A8JbkHJFaAAk1xPNA+q2IUAlMjXBIkzN7WgYkt1QXjbpskdSde BaU7/gKrPSIi5l5OizqT4j3Jo262T89Mox/CVR/7+f3Njc8BrOYWzenRJlj5FurvRjPUtd Ax5C2lTSiFXxWwKh+kg9oftpShqvhc0= X-MC-Unique: uVm7wy9uPnqna-YWwQgM4A-1 X-Mimecast-MFC-AGG-ID: uVm7wy9uPnqna-YWwQgM4A_1792600194 From: Markus Armbruster To: marcandre.lureau@redhat.com Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Property types changed in this series (was: [PATCH v7 00/65] Hi) In-Reply-To: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> (marcandre lureau's message of "Tue, 20 Oct 2026 14:45:17 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> Date: Wed, 21 Oct 2026 18:29:40 +0200 Message-ID: <87tsmfkoej.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: B2kxSoh1jySj2AFfgWjLl2DM47pRus-WSSNVKDk2hMs_1792600194 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-purgate-ID: tlsNG-720697/1792600204-307C22AC-BAC6BB24/0/0 X-purgate-type: clean X-purgate-size: 2831 I used qom-list-types and qom-list-properties to list all properties and their types, then looked for changes. This can miss changes in dynamically created properties; see the note on qom-list-properties in qapi/qom.json. Moreover, I ran into a few QOM types where qom-list-properties is broken. 1. Close misses of QAPI type names change to actual QAPI type names old property type new property type --------------------------------------------- string str uint64_t uint64 uint64_t size int32_t int32 int size uint32_t uint32 [uint16] uint16List NotifyVMexitOption NotifyVmexitOption CXLFixedMemoryWindow CXLFixedMemoryWindowOptionsList 2. Incorrect QAPI type names change to correct ones old property type new property type --------------------------------------------- SgxEPC SgxEPCList QAuthZListRule QAuthZListRuleList X86CPUFeatureWordInfo X86CPUFeatureWordInfoList bool Pca9552LedState 3. Less than useful QAPI type names change to more useful ones old property type new property type --------------------------------------------- str Pca9552PinState str Pca9554PinState 4. Lazy crap old property type new property type --------------------------------------------- list linkList list strList list uint16List list uint32List list uint64List list uint8List struct any I'm not sure the first one is what it should be. I need to have a closer look at the last one. 5. Inventive crap old property type new property type --------------------------------------------- busnr uint8 guest statistics VirtioBalloonGuestStats loadparm str on|off|split OnOffSplit struct tm StructTm 6. An odd duck old property type new property type --------------------------------------------- str int32 This is pci-device property addr. See PATCH 54. On the way, I noted properties with anti-social names: QOM type name property name --------------------------------- acpi-ged memhp container[0] e500-spin e500 spin pv device[0] From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458989.1671090 (Exim 4.92) (envelope-from ) id 1xKCLb-00089z-0Y; Fri, 23 Oct 2026 10:18:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458989.1671090; Fri, 23 Oct 2026 10:18: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 1xKCLa-00087u-Qg; Fri, 23 Oct 2026 10:18:02 +0000 Received: by outflank-mailman (input) for mailman id 1458989; Fri, 23 Oct 2026 08:40:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKAow-0004VA-1h for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 08:40:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKAov-00EThL-7X for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:40:13 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb1d60-2eae-0a2a0a5409dd-0a2a450ca93e-42 for ; Fri, 23 Oct 2026 10:40:13 +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 6adb1d6b-f479-0a2a450c0019-aa0a817cb687-3 for ; Fri, 23 Oct 2026 10:40: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-433-gEH36swhMSWp1ifHI3FC6w-1; Fri, 23 Oct 2026 04:40:06 -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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A187518005AB; Fri, 23 Oct 2026 08:39:58 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2BC4018001CA; Fri, 23 Oct 2026 08:39:54 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id D776D21E6A04; Fri, 23 Oct 2026 10:39: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=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=1792744811; 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=0Pj6QyZW/xESjev5XVWjzENx6fIcmKFZWXFYVSlbY78=; b=eVyWOozqMdrr6xuX5tASdfgBjiqqgZUI1H3RwWdVsJwHvzUa58dD5XgCADIaPUnyhVGyPE QPI8HSsyUTvpVsKK7cLhDFwh8W5lsGA9+EaXTlfQnCd4+9Yx9C74CizZbUvJEi9DrDybFH V38uqlkXCyXZpWXHeHjxVuJpRWuqgO8= X-MC-Unique: gEH36swhMSWp1ifHI3FC6w-1 X-Mimecast-MFC-AGG-ID: gEH36swhMSWp1ifHI3FC6w_1792744801 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 07/65] qapi: add QAPITypeInfo struct definition In-Reply-To: <20261020-qom-qapi-v7-7-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:45:24 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-7-431a86b02b58@redhat.com> Date: Fri, 23 Oct 2026 10:39:51 +0200 Message-ID: <875wyshktk.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: EE-TOXB0iDzNbM18DocB-LSXE_LcLU905L737Z_S_x4_1792744801 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1792744813-03CD3A5B-AD6BD6F5/0/0 X-purgate-type: clean X-purgate-size: 4060 Marc-Andr=C3=A9 Lureau writes: > Introduce a minimal struct that pairs a QAPI type's internal name with > its "masked" introspection name. Generated constants of this type will > let QOM property registration carry a reliable reference to the QAPI > schema and possibly other associated data. > > The fields are populated in following commits. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau > --- > include/qapi/qapi-type-info.h | 31 +++++++++++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/include/qapi/qapi-type-info.h b/include/qapi/qapi-type-info.= h > new file mode 100644 > index 000000000000..6a6355568325 > --- /dev/null > +++ b/include/qapi/qapi-type-info.h > @@ -0,0 +1,31 @@ > +/* > + * SPDX-License-Identifier: GPL-2.0-or-later > + */ > + > +#ifndef QAPI_TYPE_INFO_H > +#define QAPI_TYPE_INFO_H > + > +#include "qapi/util.h" > + > +/** > + * QAPITypeInfo - QAPI type metadata > + * > + * @name: QAPI type name (e.g. "str", "OnOffAuto", "int32List"). > + * QOM uses this as the property type string. > + * @masked_name: Name of the type in the QAPI introspection schema, assi= gned by > + * scripts/qapi code generator (e.g. "368"). I figure "in the output of query-qmp-schema" would be clearer. > + * @lookup: QEnumLookup for this type, or NULL for non-enum types. > + * visit_type_enum(), qapi_enum_parse(), and qapi_enum_lookup() > + * all rely on it. "It" is ambiguous and easily misunderstod. Correct interpretation: the QEnumLookup. Incorrect interpretation: QAPITypeInfo member @lookup. QAPITypeInfo member @lookup is actually used by QOM property stuff in object.c. Or rather will be: PATCH 15+17. Do we need the second sentence? > + * @list: The list-type counterpart, or NULL if none exists. > + * str_type_info.list points to strList_type_info. qdev array > + * properties follow this to find the list type for their element= . This alludes to static const QAPITypeInfo *qdev_prop_qapi_type(const Property *prop) { if (prop->info->qapi_type) { return prop->info->qapi_type; } if (prop->info->element_info) { assert(prop->info->element_info->qapi_type); assert(prop->info->element_info->qapi_type->list); return prop->info->element_info->qapi_type->list; } return NULL; } These array properties don't have prop->info->qapi_type set, and instead retrieve it from their element type [PATCH 59]. Maybe something like "qdev array properties lack a QAPITypeInfo, and instead use their element QAPITypeInfo's @list to find it." Except all that isn't true at this point in the series. Consider adding it only when it is true. Ignorant question: could we set their prop->info->qapi_type at creation time? No need for qdev_prop_qapi_type() then. Hmm, I guess not, the obvious patch (appended) fails with "initializer element is not constant". > + */ > +typedef struct QAPITypeInfo { > + const char *name; > + const char *masked_name; > + const QEnumLookup *lookup; > + const struct QAPITypeInfo *list; > +} QAPITypeInfo; > + > +#endif /* QAPI_TYPE_INFO_H */ diff --git a/hw/core/qdev-prop-internal.h b/hw/core/qdev-prop-internal.h index 40fa4bc63f..18d982a212 100644 --- a/hw/core/qdev-prop-internal.h +++ b/hw/core/qdev-prop-internal.h @@ -40,6 +40,7 @@ void default_prop_array(ObjectProperty *op, const Propert= y *prop); */ #define DEFINE_PROP_ARRAY_INFO(_elem_prop_info, _elem_type) \ { \ + .qapi_type =3D _elem_prop_info.qapi_type->list, \ .element_info =3D &(_elem_prop_info), \ .element_size =3D sizeof(_elem_type), \ .get =3D get_prop_array, \ From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457799.1671079 (Exim 4.92) (envelope-from ) id 1xKCLa-0007zz-HL; Fri, 23 Oct 2026 10:18:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457799.1671079; Fri, 23 Oct 2026 10:18: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 1xKCLa-0007zb-CB; Fri, 23 Oct 2026 10:18:02 +0000 Received: by outflank-mailman (input) for mailman id 1457799; Thu, 22 Oct 2026 06:49:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJmcG-0007F3-Sc for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 06:49:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJmcG-001BlI-2K for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 08:49:32 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad9b1f4-8faa-0a2a0a5109dd-0a2a4505d124-26 for ; Thu, 22 Oct 2026 08:49:31 +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 6ad9b1fa-4cb1-0a2a45050019-aa0a857cca09-3 for ; Thu, 22 Oct 2026 08:49:31 +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-668-9wIN8bqtNjm5ZsV_6-4TKQ-1; Thu, 22 Oct 2026 06:49:26 +0000 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 2E93719560B2; Thu, 22 Oct 2026 06:49:18 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 725C81803A48; Thu, 22 Oct 2026 06:49:14 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 1B3A121E6A04; Thu, 22 Oct 2026 08:49: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=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=1792651770; 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=JADHWg0Jlsj3MBmuPMLUMpANIVwK+0qeu0X1mxgI0Mk=; b=ffV77D/0ReZDC2F4Zs2LkCXWakwzWO8FeMGwsFvj/L9lpSHqSI3lxP9aUl/RpSl2o6T2Ya hpQYzmHEeT1/p1K0V11YN8Hyo9lovmGf1WXspxItAQ+iwSlWqTRqHItUl3YjAgGxw28SqT omm60soW5Lfsstv1f+TN3erzAT3RegI= X-MC-Unique: 9wIN8bqtNjm5ZsV_6-4TKQ-1 X-Mimecast-MFC-AGG-ID: 9wIN8bqtNjm5ZsV_6-4TKQ_1792651761 From: Markus Armbruster To: devel@lists.libvirt.org Cc: marcandre.lureau@redhat.com, qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: Property types changed in this series In-Reply-To: <87tsmfkoej.fsf@pond.sub.org> (Markus Armbruster's message of "Wed, 21 Oct 2026 18:29:40 +0200") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <87tsmfkoej.fsf@pond.sub.org> Date: Thu, 22 Oct 2026 08:49:12 +0200 Message-ID: <878q3qkz6f.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: s_J0x-Iljg2GUajGPBWlschbCyzmrelUbS7sAzMAoZU_1792651761 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1792651771-F7CB82A1-FACECDB5/0/0 X-purgate-type: clean X-purgate-size: 3469 Libvirt developers: does libvirt use member @type of the reply of qom-list, qom-list-properties, qom-list-get? I'm asking because Marc-Andr=C3=A9's work changes many values to add a more useful replacement. I think we should deprecate @type. I'd like to find out whether we need to preserve the values for the deprecation grace period. Markus Armbruster writes: > I used qom-list-types and qom-list-properties to list all properties and > their types, then looked for changes. This can miss changes in > dynamically created properties; see the note on qom-list-properties in > qapi/qom.json. Moreover, I ran into a few QOM types where > qom-list-properties is broken. These are ast2700-a1, ast2700-a2, and several riscv CPUs. A fix for the latter has been queued. > 1. Close misses of QAPI type names change to actual QAPI type names > > old property type new property type > --------------------------------------------- > string str > uint64_t uint64 > uint64_t size > int32_t int32 > int size > uint32_t uint32 > [uint16] uint16List > NotifyVMexitOption NotifyVmexitOption > CXLFixedMemoryWindow CXLFixedMemoryWindowOptionsList > > 2. Incorrect QAPI type names change to correct ones > > old property type new property type > --------------------------------------------- > SgxEPC SgxEPCList > QAuthZListRule QAuthZListRuleList > X86CPUFeatureWordInfo X86CPUFeatureWordInfoList > bool Pca9552LedState > > 3. Less than useful QAPI type names change to more useful ones > > old property type new property type > --------------------------------------------- > str Pca9552PinState > str Pca9554PinState > > 4. Lazy crap > =20 > old property type new property type > --------------------------------------------- > list linkList > list strList > list uint16List > list uint32List > list uint64List > list uint8List > struct any > > I'm not sure the first one is what it should be. > > I need to have a closer look at the last one. > > 5. Inventive crap > =20 > old property type new property type > --------------------------------------------- > busnr uint8 > guest statistics VirtioBalloonGuestStats > loadparm str > on|off|split OnOffSplit > struct tm StructTm > > 6. An odd duck > > old property type new property type > --------------------------------------------- > str int32 > > This is pci-device property addr. See PATCH 54. > > On the way, I noted properties with anti-social names: > > QOM type name property name > --------------------------------- > acpi-ged memhp container[0] > e500-spin e500 spin pv device[0] From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459019.1671098 (Exim 4.92) (envelope-from ) id 1xKCLb-0008Jm-Do; Fri, 23 Oct 2026 10:18:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459019.1671098; Fri, 23 Oct 2026 10: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 1xKCLb-0008Ha-4M; Fri, 23 Oct 2026 10:18:03 +0000 Received: by outflank-mailman (input) for mailman id 1459019; Fri, 23 Oct 2026 10:05:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKC9A-0006T8-0i for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:05:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKC98-00CFhy-NN for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:05:10 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb3152-bab6-0a2a0a5309dd-0a2a4501a328-30 for ; Fri, 23 Oct 2026 12:05:10 +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 6adb3154-5984-0a2a45010019-aa0a817cd649-3 for ; Fri, 23 Oct 2026 12:05:10 +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-213-DdROSvANPzCaudLkmMT02A-1; Fri, 23 Oct 2026 06:05:04 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9704D1956057; Fri, 23 Oct 2026 10:04:56 +0000 (UTC) Received: from redhat.com (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 18FB21956088; Fri, 23 Oct 2026 10:04: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: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=1792749908; 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=Z1/M6fHwVdsOcXm3ypxN6/mMXkslI/t6HGQAVs7BRk8=; b=QngC8xHXH0OPqDivJ1ziVXbqfPysZl6EuqroX4C1Xv60D2iy54LisFw6iHKuWuY02UFdJt KkzbOmuyaoJSFcrN/qcETrsFise05H/oaxb+2wa9afNzphrFOidX7B6+tw65dhPZ9k75Ed qyN/gzwEOHKmQfumhcQi9iia8N5BhkU= X-MC-Unique: DdROSvANPzCaudLkmMT02A-1 X-Mimecast-MFC-AGG-ID: DdROSvANPzCaudLkmMT02A_1792749899 Date: Fri, 23 Oct 2026 11:04:29 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> MIME-Version: 1.0 In-Reply-To: <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: kcfTzFIk0uLkvAUfT7EwtmRpxYQBNQsRgy_KND10FzY_1792749899 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1792749910-BF262757-797D8A2D/0/0 X-purgate-type: clean X-purgate-size: 2026 On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-André Lureau wrote: > PciDevfn is a bit special, since it accepts integer and string as > setter, but only output integer as getter. > > Unfortunately, we can't declare an alternate str|int QAPI type for it, > since: branch 'string' can't be distinguished from 'integer' > > Rather than declaring it as "str", use the common type instead. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-André Lureau > --- > hw/core/qdev-properties-system.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c > index 5bfdfe1ab9d9..3381de1144d6 100644 > --- a/hw/core/qdev-properties-system.c > +++ b/hw/core/qdev-properties-system.c > @@ -904,7 +904,8 @@ static char *print_pci_devfn(Object *obj, const Property *prop) > } > > const PropertyInfo qdev_prop_pci_devfn = { > - .type = "str", > + /* The formatted string accepted by the setter is a CLI convenience. */ IIUC, this is not limited to the CLI, it will work anywhere the JSON syntax is permitted which is both CLI and QMP. libvirt uses this string syntax: -device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2","bus":"pcie.0","multifunction":true,"addr":"0x1.0x1"}' \ > + .type = "int32", > .description = "Slot and optional function number, example: 06.0 or 06", Changing the type to 'int32', where 99% of usage is input only and string based, is pretty unpleasant. Even more so that the description doesn't even mention encoding dev+function as an integer. > .print = print_pci_devfn, > .get = qdev_propinfo_get_int32, 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 Oct 23 10:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457344.1671067 (Exim 4.92) (envelope-from ) id 1xKCLa-0007sR-0l; Fri, 23 Oct 2026 10:18:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457344.1671067; Fri, 23 Oct 2026 10:18: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 1xKCLZ-0007sJ-Tv; Fri, 23 Oct 2026 10:18:01 +0000 Received: by outflank-mailman (input) for mailman id 1457344; Wed, 21 Oct 2026 14:45:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJXZI-0004Kd-Ac for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 14:45:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJXZH-008D0Q-NL for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 16:45:27 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad8cffe-2eae-0a2a0a5409dd-0a2a45088fba-16 for ; Wed, 21 Oct 2026 16:45: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 6ad8d006-f659-0a2a45080019-aa0a857c7b73-3 for ; Wed, 21 Oct 2026 16:45:27 +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-44-697RRaHWMcyjyp9VUObGAw-1; Wed, 21 Oct 2026 10:45:22 -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 0D26B18007EA; Wed, 21 Oct 2026 14:45:15 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 82B9030002CB; Wed, 21 Oct 2026 14:45:09 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 23A7921E6A04; Wed, 21 Oct 2026 16:45: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=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=1792593926; 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=JDM0WUBiT+rQ0E9Y++3yExU/xhUlliEDnE5RqvGKgRs=; b=C37bbNz6wMSkPQsgrfx68LjR0f81GgUfJiDywsZgD4J1OeWf7qjvg5h/qHPnqOej5XgYKi Z0OqeNavuSV7eULBtQcAspmk8v7wLMDUAzJD3tnSDC3+i+Yp9l1tU0VC9tT27qIa+I5faR TYMpuseS3wCK/hRFN/yaHjSlqyydKT0= X-MC-Unique: 697RRaHWMcyjyp9VUObGAw-1 X-Mimecast-MFC-AGG-ID: 697RRaHWMcyjyp9VUObGAw_1792593918 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 60/65] qdev: simplify DEFINE_PROP_ARRAY and remove generic array PropertyInfo In-Reply-To: <20261020-qom-qapi-v7-60-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:46:17 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-60-431a86b02b58@redhat.com> Date: Wed, 21 Oct 2026 16:45:07 +0200 Message-ID: <878q3rm7t8.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: cmujyOyO45fkJT8-FHsepChpQbF8kmsdz1gyUeSZDgg_1792593918 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c1860d/1792593927-D514E87B-8E98692A/0/0 X-purgate-type: clean X-purgate-size: 920 Marc-Andr=C3=A9 Lureau writes: > Change DEFINE_PROP_ARRAY, the macro now uses _arrayprop##_list to > resolve the typed list PropertyInfo (introduced in the previous patch) > instead of the generic qdev_prop_array. > > This means the element type and size information is carried by the > PropertyInfo itself rather than duplicated at each callsite. Since > the typed list PropertyInfos encode element_info and element_size, > the .arrayinfo and .arrayfieldsize fields are no longer set by the > macro (they will be removed from the Property struct in the next patch). > > Remove qdev_prop_array, which is now unused. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau I see the type of "gicv5" property "cpus" change from "list", which lazy bad, to "linkList, which is confused bad. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457639.1671122 (Exim 4.92) (envelope-from ) id 1xKCLm-0000wn-2r; Fri, 23 Oct 2026 10:18:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457639.1671122; Fri, 23 Oct 2026 10: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 1xKCLl-0000wW-UH; Fri, 23 Oct 2026 10:18:13 +0000 Received: by outflank-mailman (input) for mailman id 1457639; Wed, 21 Oct 2026 21:48:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJeAU-0005ut-Th for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 21:48:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJeAU-004iBK-0E for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 23:48:18 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad932fe-bab6-0a2a0a5309dd-0a2a4504889e-30 for ; Wed, 21 Oct 2026 23:48:17 +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 6ad93321-b57f-0a2a45040019-c387df82bc90-3 for ; Wed, 21 Oct 2026 23:48:17 +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 4EC8321EB7; Wed, 21 Oct 2026 21:48: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 5B295134A5; Wed, 21 Oct 2026 21:48: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 QC/lCh8z2WpAGgAAD6G6ig (envelope-from ); Wed, 21 Oct 2026 21:48: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"; 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"; 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=1792619297; 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; bh=BNmG7yJjoNt8Ptd0MZtdJ7UznCSNc7rDzGQLdC+cy7E=; b=hH9mrAs+lGttPEdAZ+jo0InqkNhclnMv4XuNiMRATQ4PjlVV0zHco/+SzKs//zx21BcZ/K gPu0KLnwEEX1Z4BuUxAoAQ4Hm37+RICdcey1Idy//GkMUwa2rBtB6PKj090lJ5XWPP/9Vx AhQn7VHS4+st9NoJTO/Ib6fBN3g+EAE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792619297; 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; bh=BNmG7yJjoNt8Ptd0MZtdJ7UznCSNc7rDzGQLdC+cy7E=; b=9cQhfpLxrrw1J+mL2fXF7dWeueIKBLqOgVoX8bbG6vEXm+t145ZqklRc9MpcrdGl4VNgyw BMHAlL5HI45kpsCg== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1792619296; 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; bh=BNmG7yJjoNt8Ptd0MZtdJ7UznCSNc7rDzGQLdC+cy7E=; b=y3Ubh2X8v83c46Ug5/Szywg+F1P/GtlKjE0xV5bUMccd2OWhBO7fSpO6+NqCmTeimSumdK hjoleivsMQWnwfKh8yWoMIfLwUHnB44MyISJD52I5zsQ/eAVdBeiML80E5uj5le6+8zWKs j0H8aFzZqWBDyaGYQZ0lLSc2X4HGdlg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792619296; 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; bh=BNmG7yJjoNt8Ptd0MZtdJ7UznCSNc7rDzGQLdC+cy7E=; b=Ebfsji5BJjia+pyQ2jigm735PEtXPc0WOy8PYwae8s9aXHfXlWXQoRYyNXFszm4Wz5Dy8b gIFDiHsVPzn+oFAQ== Message-ID: <08f938a3-8315-425e-86f8-3e622f035f3e@suse.de> Date: Wed, 21 Oct 2026 23:48:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-1-2aa780a03524@toxicpanda.com> Content-Language: en-US From: Fernando Fernandez Mancera In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-1-2aa780a03524@toxicpanda.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-11.79 / 50.00]; SUSE_INTERNAL_BYPASS(-9.00)[]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[netdev]; RCPT_COUNT_TWELVE(0.00)[14]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[suse.com,kernel.org,gmail.com,google.com,vger.kernel.org,lists.xenproject.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; DBL_BLOCKED_OPENRESOLVER(0.00)[toxicpanda.com:email,imap1.dmz-prg2.suse.org:helo] X-Spam-Score: -11.79 X-Spam-Level: X-Spam-Flag: NO X-purgate-ID: tlsNG-ebf023/1792619297-C2CCFB50-D985695D/0/0 X-purgate-type: clean X-purgate-size: 15265 On 10/21/26 3:46 PM, Josef Bacik wrote: > skb_copy_and_csum_bits() has no way to fail. When it reaches > unreadable frags it zero-fills the rest of the buffer and returns 0, > and since commit ab9414ed70bd ("net: skbuff: don't leave stale bytes in > skb_copy_and_csum_bits()") that 0 is the correct checksum for what's in > the buffer. Its callers can't tell the copy didn't happen. > > That matters in the !sg && !csum branch of skb_segment(). A devmem TCP > skb keeps its whole payload in unreadable frags, so every segment ends > up with a payload of zeroes, tcp_gso_segment() writes a valid TCP > checksum over it, and the peer accepts the zeroes as stream data. This > is reachable when both SG and TX checksum offload are turned off on a > device used for devmem TX: sk_setup_caps() still gives TCP SG and > HW_CSUM, so the dmabuf send is accepted, validate_xmit_unreadable_skb() > lets the skb through for a NETMEM_TX_NO_DMA device or a matching > binding, and software GSO segments it with neither feature. Before > that commit the segments carried uninitialized memory with a checksum > that almost never matched. > > This was reproduced with a test module rather than on devmem hardware: > skb_segment() on a TCPv4 GSO skb with 3000 bytes of payload in a page > frag marked unreadable, with features == 0, returns 3 segments whose > payloads are all zeroes, each with a checksum of 0, which is correct for > zeroes. There's no warning or error; the data is silently replaced. > With this patch skb_segment() returns -EFAULT. > > Make skb_copy_and_csum_bits() return 0 or -EFAULT and hand the checksum > back through a pointer, and make it __must_check so a new caller can't > ignore the failure. Running out of skb before @len returns -EFAULT > too; commit 417261779eab ("net: skbuff: don't BUG() on leftover length > in skb_copy_and_csum_bits()") made that a zero-fill and a checksum of 0. > Each caller takes the error path it already has for a failed copy: > > - skb_segment() fails the segmentation, as the csum branch already > does when skb_copy_bits() fails. > - icmp_glue_bits() and icmpv6_getfrag() return the error, so the ICMP > error isn't sent. > - __ip_append_data() and __ip6_append_data() drop the new skb and > return -EFAULT, as they do when getfrag fails. > - vnet_skb_shape() fails the same way it does when its skb_copy_bits() > call fails. > - xdr_skb_read_bits() returns 0 without consuming anything, as it does > when skb_copy_bits() fails, so desc.count stays non-zero and > csum_partial_copy_to_xdr() fails. csum_partial_copy_to_xdr() used > to checksum the bytes it hadn't copied before checking desc.count. > desc.offset and desc.count always add up to skb->len, so that only > ran when it was about to fail anyway, and on an unreadable skb > skb_checksum() would WARN. Drop it. > - skb_copy_and_csum_dev() can't return an error, so it leaves the > checksum alone and the frame goes out with a bad one. Its callers > are drivers that never see unreadable skbs anyway. > > The zero-fill stays, so a caller that does send the buffer still > doesn't leak anything. > > This was found by the Sashiko AI review of that commit, and > Mina suggested reporting the error from the helper rather than checking > for unreadable frags in skb_segment(). > > Link: https://lore.kernel.org/all/179148235783.434549.14322374227477832817@kernel.org/ > Suggested-by: Mina Almasry > Reviewed-by: Mina Almasry > Assisted-by: LLM > Signed-off-by: Josef Bacik Hm, I do wonder isn't this missing the Fixes tag for ab9414ed70bd and 417261779eab? I don't have a strong opinion but since ab9414ed70bd will be backported to stable (quite likely..) it makes sense to me. > --- > drivers/net/ethernet/sun/sunvnet_common.c | 10 +++-- > include/linux/skbuff.h | 4 +- > net/core/skbuff.c | 63 +++++++++++++++++++++---------- > net/ipv4/icmp.c | 9 +++-- > net/ipv4/ip_output.c | 11 ++++-- > net/ipv6/icmp.c | 7 +++- > net/ipv6/ip6_output.c | 11 ++++-- > net/sunrpc/socklib.c | 9 ++--- > 8 files changed, 83 insertions(+), 41 deletions(-) > > diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c > index 5cca95869052..4f229fcecc32 100644 > --- a/drivers/net/ethernet/sun/sunvnet_common.c > +++ b/drivers/net/ethernet/sun/sunvnet_common.c > @@ -1167,9 +1167,13 @@ static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, int ncookies) > > /* copy the rest, with csum calculation */ > *(__sum16 *)(skb->data + offset) = 0; > - csum = skb_copy_and_csum_bits(skb, start, > - nskb->data + start, > - skb->len - start); > + if (skb_copy_and_csum_bits(skb, start, > + nskb->data + start, > + skb->len - start, &csum)) { > + dev_kfree_skb(nskb); > + dev_kfree_skb(skb); > + return NULL; > + } > > /* add in the header checksums */ > if (skb->protocol == htons(ETH_P_IP)) { > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > index af1cbc2799b7..09db32f70b53 100644 > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -4277,8 +4277,8 @@ void skb_free_datagram(struct sock *sk, struct sk_buff *skb); > int skb_kill_datagram(struct sock *sk, struct sk_buff *skb, unsigned int flags); > int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len); > int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len); > -__wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to, > - int len); > +int __must_check skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > + u8 *to, int len, __wsum *csum); For consistency skb_copy_and_csum_bits() should use csump instead of csum in the prototype to match the implementation and kernel-doc parameter name. > int skb_splice_bits(struct sk_buff *skb, struct sock *sk, unsigned int offset, > struct pipe_inode_info *pipe, unsigned int len, > unsigned int flags); > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 93c2f440b9ec..a2b52a5a61a9 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3630,14 +3630,27 @@ EXPORT_SYMBOL(skb_checksum); > > /* Both of above in one bottle. */ > I guess we can now remove this comment. I mean the kernel-doc being added here makes it a bit redundant in my opinion. > -__wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > - u8 *to, int len) > +/** > + * skb_copy_and_csum_bits - copy data out of an skb and checksum it > + * @skb: source buffer > + * @offset: offset in @skb to start copying from > + * @to: destination buffer > + * @len: number of bytes to copy > + * @csump: where to store the checksum of the copied bytes > + * > + * Return: 0 on success, or -EFAULT if @skb has unreadable frags or runs > + * out before @len does. On failure *@csump is not set and the part of > + * @to that couldn't be filled is zeroed. > + */ > +int skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > + u8 *to, int len, __wsum *csump) > { > int start = skb_headlen(skb); > int i, copy = start - offset; > struct sk_buff *frag_iter; > int pos = 0; > __wsum csum = 0; > + int err; > > /* Copy header. */ > if (copy > 0) { > @@ -3646,7 +3659,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > csum = csum_partial_copy_nocheck(skb->data + offset, to, > copy); > if ((len -= copy) == 0) > - return csum; > + goto out; > offset += copy; > to += copy; > pos = copy; > @@ -3656,7 +3669,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > /* Don't hand the caller a buffer with stale bytes in it. */ > if (len > 0) > memset(to, 0, len); > - return 0; > + return -EFAULT; > } > > for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { > @@ -3688,7 +3701,7 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > } > > if (!(len -= copy)) > - return csum; > + goto out; > offset += copy; > to += copy; > } > @@ -3705,12 +3718,16 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > if ((copy = end - offset) > 0) { > if (copy > len) > copy = len; > - csum2 = skb_copy_and_csum_bits(frag_iter, > - offset - start, > - to, copy); > + err = skb_copy_and_csum_bits(frag_iter, offset - start, > + to, copy, &csum2); > + if (err) { > + /* The child zeroed its part; zero the rest. */ > + memset(to + copy, 0, len - copy); > + return err; > + } > csum = csum_block_add(csum, csum2, pos); > if ((len -= copy) == 0) > - return csum; > + goto out; > offset += copy; > to += copy; > pos += copy; > @@ -3722,9 +3739,11 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > /* Don't hand the caller a buffer with stale bytes in it. */ > if (len > 0) > memset(to, 0, len); > - return 0; > + return -EFAULT; > } > - return csum; > +out: > + *csump = csum; > + return 0; > } > EXPORT_SYMBOL(skb_copy_and_csum_bits); > > @@ -4006,9 +4025,13 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to) > skb_copy_from_linear_data(skb, to, csstart); > > csum = 0; > - if (csstart != skb->len) > - csum = skb_copy_and_csum_bits(skb, csstart, to + csstart, > - skb->len - csstart); > + /* On failure the rest of @to is zeroed; leave the checksum alone so > + * the frame goes out with a bad one. > + */ > + if (csstart != skb->len && > + skb_copy_and_csum_bits(skb, csstart, to + csstart, > + skb->len - csstart, &csum)) > + return; > > if (skb->ip_summed == CHECKSUM_PARTIAL) { > long csstuff = csstart + skb->csum_offset; > @@ -5057,11 +5080,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, > if (!csum) { > if (!nskb->remcsum_offload) > nskb->ip_summed = CHECKSUM_NONE; > - SKB_GSO_CB(nskb)->csum = > - skb_copy_and_csum_bits(head_skb, offset, > - skb_put(nskb, > - len), > - len); > + if (skb_copy_and_csum_bits(head_skb, offset, > + skb_put(nskb, len), > + len, > + &SKB_GSO_CB(nskb)->csum)) { > + err = -EFAULT; > + goto err; > + } > SKB_GSO_CB(nskb)->csum_start = > skb_headroom(nskb) + doffset; > } else { > diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c > index 90c0e22c29be..35008785e3d2 100644 > --- a/net/ipv4/icmp.c > +++ b/net/ipv4/icmp.c > @@ -364,12 +364,15 @@ static int icmp_glue_bits(void *from, char *to, int offset, int len, int odd, > DEFINE_RAW_FLEX(struct icmp_bxm, icmp_param, replyopts.opt.__data, > IP_OPTIONS_DATA_FIXED_SIZE); > __wsum csum; > + int err; > > icmp_param = from; > > - csum = skb_copy_and_csum_bits(icmp_param->skb, > - icmp_param->offset + offset, > - to, len); > + err = skb_copy_and_csum_bits(icmp_param->skb, > + icmp_param->offset + offset, > + to, len, &csum); > + if (err) > + return err; > > skb->csum = csum_block_add(skb->csum, csum, odd); > if (icmp_param->data.icmph.type <= NR_ICMP_TYPES && > diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c > index 3396f177a18d..f7da4538d05b 100644 > --- a/net/ipv4/ip_output.c > +++ b/net/ipv4/ip_output.c > @@ -1162,9 +1162,14 @@ static int __ip_append_data(struct sock *sk, > data += fragheaderlen + exthdrlen; > > if (fraggap) { > - skb->csum = skb_copy_and_csum_bits( > - skb_prev, maxfraglen, > - data + transhdrlen, fraggap); > + if (skb_copy_and_csum_bits(skb_prev, maxfraglen, > + data + transhdrlen, > + fraggap, > + &skb->csum)) { > + err = -EFAULT; > + kfree_skb(skb); > + goto error; > + } > skb_prev->csum = csum_sub(skb_prev->csum, > skb->csum); > data += fraggap; > diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c > index a95b0351824f..31ca3da80b1f 100644 > --- a/net/ipv6/icmp.c > +++ b/net/ipv6/icmp.c > @@ -322,9 +322,12 @@ static int icmpv6_getfrag(void *from, char *to, int offset, int len, int odd, st > struct icmpv6_msg *msg = (struct icmpv6_msg *) from; > struct sk_buff *org_skb = msg->skb; > __wsum csum; > + int err; > > - csum = skb_copy_and_csum_bits(org_skb, msg->offset + offset, > - to, len); > + err = skb_copy_and_csum_bits(org_skb, msg->offset + offset, > + to, len, &csum); > + if (err) > + return err; > skb->csum = csum_block_add(skb->csum, csum, odd); > if (!(msg->type & ICMPV6_INFOMSG_MASK)) > nf_ct_attach(skb, org_skb); > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c > index 25fe0ba98b1a..d259e7dca8ba 100644 > --- a/net/ipv6/ip6_output.c > +++ b/net/ipv6/ip6_output.c > @@ -1724,9 +1724,14 @@ static int __ip6_append_data(struct sock *sk, > skb->transport_header = (skb->network_header + > fragheaderlen); > if (fraggap) { > - skb->csum = skb_copy_and_csum_bits( > - skb_prev, maxfraglen, > - data + transhdrlen, fraggap); > + if (skb_copy_and_csum_bits(skb_prev, maxfraglen, > + data + transhdrlen, > + fraggap, > + &skb->csum)) { > + err = -EFAULT; > + kfree_skb(skb); > + goto error; > + } > skb_prev->csum = csum_sub(skb_prev->csum, > skb->csum); > data += fraggap; > diff --git a/net/sunrpc/socklib.c b/net/sunrpc/socklib.c > index d8d8842c7de5..5d780ad4ae3a 100644 > --- a/net/sunrpc/socklib.c > +++ b/net/sunrpc/socklib.c > @@ -49,7 +49,9 @@ xdr_skb_read_bits(struct xdr_skb_reader *desc, void *to, size_t len) > if (desc->need_checksum) { > __wsum csum; > > - csum = skb_copy_and_csum_bits(desc->skb, desc->offset, to, len); > + if (unlikely(skb_copy_and_csum_bits(desc->skb, desc->offset, > + to, len, &csum))) > + return 0; > desc->csum = csum_block_add(desc->csum, csum, desc->offset); > } else { > if (unlikely(skb_copy_bits(desc->skb, desc->offset, to, len))) > @@ -142,11 +144,6 @@ int csum_partial_copy_to_xdr(struct xdr_buf *xdr, struct sk_buff *skb) > desc.csum = csum_partial(skb->data, desc.offset, skb->csum); > if (xdr_partial_copy_from_skb(xdr, &desc) < 0) > return -1; > - if (desc.offset != skb->len) { > - __wsum csum2; > - csum2 = skb_checksum(skb, desc.offset, skb->len - desc.offset, 0); > - desc.csum = csum_block_add(desc.csum, csum2, desc.offset); > - } > if (desc.count) > return -1; > if (csum_fold(desc.csum)) > From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457649.1671127 (Exim 4.92) (envelope-from ) id 1xKCLm-0000zx-GO; Fri, 23 Oct 2026 10:18:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457649.1671127; Fri, 23 Oct 2026 10: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 1xKCLm-0000yj-7b; Fri, 23 Oct 2026 10:18:14 +0000 Received: by outflank-mailman (input) for mailman id 1457649; Wed, 21 Oct 2026 22:08:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJeUD-0000rG-Pa for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 22:08:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJeUD-007BDz-6g for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 00:08:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad937c9-2eae-0a2a0a5409dd-0a2a450beca4-40 for ; Thu, 22 Oct 2026 00:08:41 +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 6ad937e8-b7e8-0a2a450b0019-c387df83de84-3 for ; Thu, 22 Oct 2026 00:08: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 977F11F896; Wed, 21 Oct 2026 22:08: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 A8175134A5; Wed, 21 Oct 2026 22:08:39 +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 6b6qHOc32WqDLgAAD6G6ig (envelope-from ); Wed, 21 Oct 2026 22:08: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=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"; 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"; 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=1792620520; 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; bh=Rps3j/Ol+umElVM3i3J1CQ+c26rRYH3c8bCidpO4rlA=; b=FCQQFScAeE3XcQzfVRcAEtYT+0CUb93eoGGcBBOEZ3LkxGCzC5vhHADtH6oINhu4hLZCz0 no5fKOb+eGvnpteZZ+UAVS4vPJJulLGUayX7VLwA+o191PRNEXJJr7QwRKzQILuTkMrTg2 pqcD6j6ephaIzZ5iEGTTyFDaMhPsM2Y= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792620520; 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; bh=Rps3j/Ol+umElVM3i3J1CQ+c26rRYH3c8bCidpO4rlA=; b=+oI2jbf8oH/vyZFWBJqu6X7MmPpT3/1lgMz6u7vhzXJgtuqWdgyaSWGzCdxWKaHVyKi9EO fxrYBMZWu6TIlLDw== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1792620520; 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; bh=Rps3j/Ol+umElVM3i3J1CQ+c26rRYH3c8bCidpO4rlA=; b=FCQQFScAeE3XcQzfVRcAEtYT+0CUb93eoGGcBBOEZ3LkxGCzC5vhHADtH6oINhu4hLZCz0 no5fKOb+eGvnpteZZ+UAVS4vPJJulLGUayX7VLwA+o191PRNEXJJr7QwRKzQILuTkMrTg2 pqcD6j6ephaIzZ5iEGTTyFDaMhPsM2Y= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792620520; 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; bh=Rps3j/Ol+umElVM3i3J1CQ+c26rRYH3c8bCidpO4rlA=; b=+oI2jbf8oH/vyZFWBJqu6X7MmPpT3/1lgMz6u7vhzXJgtuqWdgyaSWGzCdxWKaHVyKi9EO fxrYBMZWu6TIlLDw== Message-ID: Date: Thu, 22 Oct 2026 00:08:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 02/15] net: skbuff: add skb_checksum_full() that reports failure To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-2-2aa780a03524@toxicpanda.com> Content-Language: en-US From: Fernando Fernandez Mancera In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-2-2aa780a03524@toxicpanda.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-11.79 / 50.00]; SUSE_INTERNAL_BYPASS(-9.00)[]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[netdev]; RCPT_COUNT_TWELVE(0.00)[14]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[suse.com,kernel.org,gmail.com,google.com,vger.kernel.org,lists.xenproject.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; DBL_BLOCKED_OPENRESOLVER(0.00)[toxicpanda.com:email,suse.de:email,imap1.dmz-prg2.suse.org:helo] X-Spam-Score: -11.79 X-Spam-Level: X-Spam-Flag: NO X-purgate-ID: tlsNG-42698a/1792620521-A9EC69EA-3FACEB8D/0/0 X-purgate-type: clean X-purgate-size: 6006 On 10/21/26 3:46 PM, Josef Bacik wrote: > skb_checksum() can't fail. When the range runs into unreadable frags > or past the end of the skb it returns 0, which is also a valid > checksum, so its callers can't tell the sum from a failure. For the > receive-side validation helpers that means a packet whose payload was > never checksummed can pass, and commit 20ddd0fd2fcd ("net: skbuff: > don't BUG() on leftover length in skb_checksum() and friends") made the > past-the-end case one of those instead of a BUG(). > > Add skb_checksum_full(), which adds the range's sum to *@csump and > returns 0, or returns -EFAULT for unreadable frags or a range past the > end of the skb, and -EINVAL for a negative length, leaving *@csump > alone. It's __must_check so a caller can't ignore the failure, and it > recurses into frag_list members through itself so a failure there > isn't lost either. > > skb_checksum() becomes a wrapper around it that behaves as before for > the callers that haven't been converted: it returns 0 on failure and > warns once if that was because of unreadable frags. The following > patches convert the core users, and the rest will follow per subsystem. > > Assisted-by: LLM > Signed-off-by: Josef Bacik Reviewed-by: Fernando Fernandez Mancera nit: AFAIU the new wrapper does not behave the same way as before in all situations. Now inside frag_list recursion a child that hits an error returns 0 and in the old code the parent never checks what the child returned. > --- > include/linux/skbuff.h | 2 ++ > net/core/skbuff.c | 56 +++++++++++++++++++++++++++++++++++++++++--------- > 2 files changed, 48 insertions(+), 10 deletions(-) > > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > index 09db32f70b53..969b1c3269ec 100644 > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -4279,6 +4279,8 @@ int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len); > int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len); > int __must_check skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, > u8 *to, int len, __wsum *csum); > +int __must_check skb_checksum_full(const struct sk_buff *skb, int offset, > + int len, __wsum *csump); > int skb_splice_bits(struct sk_buff *skb, struct sock *sk, unsigned int offset, > struct pipe_inode_info *pipe, unsigned int len, > unsigned int flags); > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index a2b52a5a61a9..061c61422a38 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3545,12 +3545,31 @@ int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len) > EXPORT_SYMBOL(skb_store_bits); > > /* Checksum skb data. */ > -__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > +/** > + * skb_checksum_full - checksum a range of an skb > + * @skb: buffer to checksum > + * @offset: offset in @skb to start at > + * @len: number of bytes to checksum > + * @csump: the sum to add to; on success the range's sum is added to it > + * > + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if @skb > + * has unreadable frags in the range or runs out before @len does. On > + * failure *@csump is not changed. > + */ > +int skb_checksum_full(const struct sk_buff *skb, int offset, int len, > + __wsum *csump) > { > int start = skb_headlen(skb); > int i, copy = start - offset; > struct sk_buff *frag_iter; > + __wsum csum = *csump; > int pos = 0; > + int err; > + > + if (unlikely(len < 0)) { > + DEBUG_NET_WARN_ON_ONCE(1); > + return -EINVAL; > + } > > /* Checksum header. */ > if (copy > 0) { > @@ -3558,13 +3577,13 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > copy = len; > csum = csum_partial(skb->data + offset, copy, csum); > if ((len -= copy) == 0) > - return csum; > + goto out; > offset += copy; > pos = copy; > } > > - if (WARN_ON_ONCE(!skb_frags_readable(skb))) > - return 0; > + if (!skb_frags_readable(skb)) > + return -EFAULT; > > for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { > int end; > @@ -3593,7 +3612,7 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > } > > if (!(len -= copy)) > - return csum; > + goto out; > offset += copy; > } > start = end; > @@ -3606,14 +3625,17 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > > end = start + frag_iter->len; > if ((copy = end - offset) > 0) { > - __wsum csum2; > + __wsum csum2 = 0; > + > if (copy > len) > copy = len; > - csum2 = skb_checksum(frag_iter, offset - start, copy, > - 0); > + err = skb_checksum_full(frag_iter, offset - start, copy, > + &csum2); > + if (err) > + return err; > csum = csum_block_add(csum, csum2, pos); > if ((len -= copy) == 0) > - return csum; > + goto out; > offset += copy; > pos += copy; > } > @@ -3621,9 +3643,23 @@ __wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > } > if (unlikely(len)) { > DEBUG_NET_WARN_ON_ONCE(1); > - return 0; > + return -EFAULT; > } > +out: > + *csump = csum; > + return 0; > +} > +EXPORT_SYMBOL(skb_checksum_full); > > +/* skb_checksum() has no way to report failure, so it returns 0, which is a > + * valid checksum. Use skb_checksum_full() in new code. > + */ > +__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __wsum csum) > +{ > + if (unlikely(skb_checksum_full(skb, offset, len, &csum))) { > + WARN_ON_ONCE(!skb_frags_readable(skb)); > + return 0; > + } > return csum; > } > EXPORT_SYMBOL(skb_checksum); > From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457660.1671132 (Exim 4.92) (envelope-from ) id 1xKCLm-00015n-S5; Fri, 23 Oct 2026 10:18:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457660.1671132; Fri, 23 Oct 2026 10: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 1xKCLm-00014K-MW; Fri, 23 Oct 2026 10:18:14 +0000 Received: by outflank-mailman (input) for mailman id 1457660; Wed, 21 Oct 2026 22:28:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJend-0003bJ-UL for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 22:28:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJend-007DK1-3t for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 00:28:45 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad93c8c-8faa-0a2a0a5109dd-0a2a4509a5de-10 for ; Thu, 22 Oct 2026 00:28:44 +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 6ad93c9c-be1a-0a2a45090019-c387df83c3de-3 for ; Thu, 22 Oct 2026 00:28:44 +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 416A91F8A6; Wed, 21 Oct 2026 22:28: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 542FE134A5; Wed, 21 Oct 2026 22:28: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 pi6BCZs82WoNQwAAD6G6ig (envelope-from ); Wed, 21 Oct 2026 22:28: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=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"; 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"; 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=1792621724; 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; bh=p7rHmKltDagdeXBwbSUIWnDSA+9oMoG0gueCO5tixVo=; b=qSvcmgVm+BSUT+Y2CtbZ0O4dYmTXb5CuLwxiciKZ7TyLwb9qMLpXghOQtlEaJb676BM20A tuwYQNJ59je6gI4w98ZmFtaV2EHe/E0dPVpkgebutLIvM7FKQP3sF9hkxnNUVNt/n9q403 aNKGiMs/5lp6H5pKxre3KuSRjDDnrj4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792621724; 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; bh=p7rHmKltDagdeXBwbSUIWnDSA+9oMoG0gueCO5tixVo=; b=LhWVhQb9vwHAQBOEPpo386fSUOryzcUDsS5CtY1E1yNEBmuKEf/PiG1e6lTwhmWMBVcSxz hsr7D6u1e11SKfBg== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=qSvcmgVm; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=LhWVhQb9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1792621724; 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; bh=p7rHmKltDagdeXBwbSUIWnDSA+9oMoG0gueCO5tixVo=; b=qSvcmgVm+BSUT+Y2CtbZ0O4dYmTXb5CuLwxiciKZ7TyLwb9qMLpXghOQtlEaJb676BM20A tuwYQNJ59je6gI4w98ZmFtaV2EHe/E0dPVpkgebutLIvM7FKQP3sF9hkxnNUVNt/n9q403 aNKGiMs/5lp6H5pKxre3KuSRjDDnrj4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792621724; 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; bh=p7rHmKltDagdeXBwbSUIWnDSA+9oMoG0gueCO5tixVo=; b=LhWVhQb9vwHAQBOEPpo386fSUOryzcUDsS5CtY1E1yNEBmuKEf/PiG1e6lTwhmWMBVcSxz hsr7D6u1e11SKfBg== Message-ID: Date: Thu, 22 Oct 2026 00:28:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-3-2aa780a03524@toxicpanda.com> Content-Language: en-US From: Fernando Fernandez Mancera In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-3-2aa780a03524@toxicpanda.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 416A91F8A6 X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Flag: NO X-Spamd-Result: default: False [-12.00 / 50.00]; SUSE_INTERNAL_BYPASS(-9.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)[]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RCPT_COUNT_TWELVE(0.00)[14]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; 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)[]; FREEMAIL_CC(0.00)[suse.com,kernel.org,gmail.com,google.com,vger.kernel.org,lists.xenproject.org]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TAGGED_RCPT(0.00)[netdev]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim] X-Spam-Score: -12.00 X-purgate-ID: tlsNG-bad1c0/1792621724-3A2C4034-1A0D296E/0/0 X-purgate-type: clean X-purgate-size: 3167 On 10/21/26 3:46 PM, Josef Bacik wrote: > __skb_checksum_complete() verifies a received packet with > skb_checksum(), which returns 0 when the range runs into unreadable > frags or past the end of the skb. 0 is a valid sum, so it's treated as > one: it adds skb->csum, the pseudo-header sum, and folds the result. > With a sum of 0 that's csum_fold(skb->csum), which is 0 whenever the > pseudo-header sum folds to 0xffff, so a packet whose payload was never > checksummed is accepted, marked csum_valid, and left with a wrong > CHECKSUM_COMPLETE value in skb->csum. > > __skb_checksum_complete_head() passes skb->csum in as the seed, so a > failure there folds 0 and the packet fails validation, but only because > skb_checksum() happened to drop the seed. > > Use skb_checksum_full() in both, and report a packet that can't be > checksummed as having a bad checksum, so callers drop it the way they > drop any other bad checksum. Clear csum_valid, and leave skb->csum and > ip_summed alone, since there's no full packet checksum to store. > > Found by the Sashiko AI review of the series that made skb_checksum() > return 0 for a range past the end of the skb. > > Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_checksum() and friends") > Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/ > Assisted-by: LLM > Signed-off-by: Josef Bacik Doesn't __skb_gro_checksum_complete() have the same problem? I think it could be fixed in this patch too. > --- > net/core/skbuff.c | 21 ++++++++++++++++++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 061c61422a38..40d2dd20d47d 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3860,9 +3860,17 @@ EXPORT_SYMBOL(skb_crc32c); > > __sum16 __skb_checksum_complete_head(struct sk_buff *skb, int len) > { > + __wsum csum = skb->csum; > __sum16 sum; > > - sum = csum_fold(skb_checksum(skb, 0, len, skb->csum)); > + /* If the data can't be checksummed it can't be valid either. */ > + if (skb_checksum_full(skb, 0, len, &csum)) { > + if (!skb_shared(skb)) > + skb->csum_valid = 0; > + return (__force __sum16)1; > + } > + > + sum = csum_fold(csum); > /* See comments in __skb_checksum_complete(). */ > if (likely(!sum)) { > if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE) && > @@ -3886,10 +3894,17 @@ EXPORT_SYMBOL(__skb_checksum_complete_head); > */ > __sum16 __skb_checksum_complete(struct sk_buff *skb) > { > - __wsum csum; > + __wsum csum = 0; > __sum16 sum; > > - csum = skb_checksum(skb, 0, skb->len, 0); > + /* If the data can't be checksummed it can't be valid either. Leave > + * skb->csum alone, it's not a full packet checksum. > + */ > + if (skb_checksum_full(skb, 0, skb->len, &csum)) { > + if (!skb_shared(skb)) > + skb->csum_valid = 0; > + return (__force __sum16)1; > + } > > sum = csum_fold(csum_add(skb->csum, csum)); > /* This check is inverted, because we already knew the hardware > From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1457672.1671138 (Exim 4.92) (envelope-from ) id 1xKCLn-0001BY-Bh; Fri, 23 Oct 2026 10:18:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1457672.1671138; Fri, 23 Oct 2026 10:18: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 1xKCLn-0001A1-3L; Fri, 23 Oct 2026 10:18:15 +0000 Received: by outflank-mailman (input) for mailman id 1457672; Wed, 21 Oct 2026 22:36:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xJevF-0004hu-Bd for xen-devel@lists.xenproject.org; Wed, 21 Oct 2026 22:36:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xJevE-000Y0i-Kq for xen-devel@lists.xenproject.org; Thu, 22 Oct 2026 00:36:36 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ad93ddc-bab6-0a2a0a5309dd-0a2a450bc544-48 for ; Thu, 22 Oct 2026 00:36:36 +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 6ad93e74-b7e8-0a2a450b0019-c387df828266-3 for ; Thu, 22 Oct 2026 00:36:36 +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 0FBE521F3C; Wed, 21 Oct 2026 22:36: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 273B5134FD; Wed, 21 Oct 2026 22:36: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 BuZaOnI+2WpvSgAAD6G6ig (envelope-from ); Wed, 21 Oct 2026 22:36: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=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"; 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"; 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=1792622196; 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; bh=iNzlXZ25cjHC8Y6LWtQ26Wk3I5gdPM3oyHxlgoDmVo4=; b=KsF2WCldQNsuqC3NqvKuKXOASQ1UngC5UEwN/QlKYkxKFaBdVR7LdQsZt8CKeBVK9xF4Zh tDxxsILXIxgE71dLzK5DJ8e444Oz6MXxFq91tZgFaq4ScaPo2st/+I/yTzlGEP/yS6wg9Y qmz2j0MRT88601TQpXVfnX+KJvmW3GE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792622196; 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; bh=iNzlXZ25cjHC8Y6LWtQ26Wk3I5gdPM3oyHxlgoDmVo4=; b=hXhw2CRuRRlRiG/T2l96Afr3T/8uJ+502OxDXlU4OnlPyazJLFenNVjawZo47rG0VPSY5N clk79m+E4JxVusDA== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1792622196; 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; bh=iNzlXZ25cjHC8Y6LWtQ26Wk3I5gdPM3oyHxlgoDmVo4=; b=KsF2WCldQNsuqC3NqvKuKXOASQ1UngC5UEwN/QlKYkxKFaBdVR7LdQsZt8CKeBVK9xF4Zh tDxxsILXIxgE71dLzK5DJ8e444Oz6MXxFq91tZgFaq4ScaPo2st/+I/yTzlGEP/yS6wg9Y qmz2j0MRT88601TQpXVfnX+KJvmW3GE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792622196; 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; bh=iNzlXZ25cjHC8Y6LWtQ26Wk3I5gdPM3oyHxlgoDmVo4=; b=hXhw2CRuRRlRiG/T2l96Afr3T/8uJ+502OxDXlU4OnlPyazJLFenNVjawZo47rG0VPSY5N clk79m+E4JxVusDA== Message-ID: Date: Thu, 22 Oct 2026 00:36:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 04/15] net: skbuff: fail segmentation when a segment can't be checksummed To: Josef Bacik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn Cc: Juergen Gross , Stefano Stabellini , Willem de Bruijn , Mina Almasry , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org References: <20261021-b4-skbuff-bug-on-followups-v2-0-2aa780a03524@toxicpanda.com> <20261021-b4-skbuff-bug-on-followups-v2-4-2aa780a03524@toxicpanda.com> Content-Language: en-US From: Fernando Fernandez Mancera In-Reply-To: <20261021-b4-skbuff-bug-on-followups-v2-4-2aa780a03524@toxicpanda.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-11.79 / 50.00]; SUSE_INTERNAL_BYPASS(-9.00)[]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_TWELVE(0.00)[14]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[suse.com,kernel.org,gmail.com,google.com,vger.kernel.org,lists.xenproject.org]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[netdev]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[toxicpanda.com:email] X-Spam-Score: -11.79 X-Spam-Level: X-Spam-Flag: NO X-purgate-ID: tlsNG-42698a/1792622196-A86CA9EA-C8231F68/0/0 X-purgate-type: clean X-purgate-size: 2104 On 10/21/26 3:46 PM, Josef Bacik wrote: > When the device can't checksum the protocol, skb_segment() computes > each segment's checksum in software with skb_checksum(). With SG on, > the segments share the original frags, and a devmem TCP skb keeps its > whole payload in unreadable frags. The devmem MSG_ZEROCOPY path never > sets SKBFL_SHARED_FRAG, so the __skb_linearize() fallback is skipped > too. skb_checksum() then warns and returns 0, and tcp_gso_segment() > writes a TCP checksum that doesn't cover the payload that goes out. > > That's reachable with tx-checksumming off and SG on: sk_setup_caps() > still gives TCP SG and HW_CSUM, so the dmabuf send is accepted, and > harmonize_features() strips the checksum features but keeps SG. > > Use skb_checksum_full() and fail the segmentation with -EFAULT when it > can't checksum a segment, as skb_segment() already does when it can't > copy one. > > Found by the Sashiko AI review of an earlier fix for the same path with > SG off. > > Link: https://lore.kernel.org/all/20261009-b4-skb-segment-nosg-unreadable-v1-1-7e2334a55fe8@toxicpanda.com/ > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- Reviewed-by: Fernando Fernandez Mancera Thanks! > net/core/skbuff.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 40d2dd20d47d..88ed2dd99dc0 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -5239,9 +5239,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, > > if (!nskb->remcsum_offload) > nskb->ip_summed = CHECKSUM_NONE; > - SKB_GSO_CB(nskb)->csum = > - skb_checksum(nskb, doffset, > - nskb->len - doffset, 0); > + SKB_GSO_CB(nskb)->csum = 0; > + if (skb_checksum_full(nskb, doffset, > + nskb->len - doffset, > + &SKB_GSO_CB(nskb)->csum)) { > + err = -EFAULT; > + goto err; > + } > SKB_GSO_CB(nskb)->csum_start = > skb_headroom(nskb) + doffset; > } > From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:18:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:18:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1458964.1671158 (Exim 4.92) (envelope-from ) id 1xKCMQ-0003iG-8z; Fri, 23 Oct 2026 10:18:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1458964.1671158; Fri, 23 Oct 2026 10: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 1xKCMQ-0003i1-2z; Fri, 23 Oct 2026 10:18:54 +0000 Received: by outflank-mailman (input) for mailman id 1458964; Fri, 23 Oct 2026 07:32:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xK9lh-0003YT-8Y for xen-devel@lists.xen.org; Fri, 23 Oct 2026 07:32:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xK9lg-009NJy-1t for xen-devel@lists.xen.org; Fri, 23 Oct 2026 09:32:48 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb0d9e-bab6-0a2a0a5309dd-0a2a4506bb8c-6 for ; Fri, 23 Oct 2026 09:32:47 +0200 Received: from [136.243.217.222] (helo=mail.cortex-media.de) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb0d9e-195a-0a2a45060019-88f3d9dea3d8-3 for ; Fri, 23 Oct 2026 09:32:46 +0200 Received: by mail.cortex-media.de (Postfix) id 1172638C055 for ; Fri, 23 Oct 2026 09:32: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=20250930 header.d=cortex-media.de header.i="@cortex-media.de" header.h="Date:To:From:Subject" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cortex-media.de; s=20250930; t=1792740766; bh=TvodcSkJBEqhD5iDxG0PyxnTMqS8yb0RTMWWNGDRxto=; h=Date:To:From:Subject:From; b=Hk/jBKr7vO++KYo02b/Al6x/rDMns+OS/n81mJYfMfj21N97QptOoa35eEYhPr4aC NhXafuiaY4G84yGot2hVAoIb3jH+BcjUmZ34hUwHNA5TVGRJZfOrFvtbQTIaLkZvcv +G5STEp9kpQPsHLzhAYQnTQlMuDOkrDcOErsGX6UefPjO80uQGthozNS0lgnGXvua8 obsv7Gop/enti4MYIUolLyYjX7sejGuPi0Dld0QG4LSq/gDDHuQ8ONYQ95uv1F2BKz Q0fIS0sKJV76Xbljoa42JogsPrMWlo3Ycpf8S4lAbkREJNhtfKxsjXc6fz55CdfPcx qQwWdqXc4XZgA== Content-Type: multipart/mixed; boundary="------------PZZxSv6fMb60yOagB00kKeOq" Message-ID: Date: Fri, 23 Oct 2026 09:32:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: xen-devel@lists.xen.org From: Peter Deggendorfer Subject: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot X-purgate-ID: tlsNG-16d1c6/1792740766-F5E0E77B-2CB7B020/0/0 X-purgate-type: clean X-purgate-size: 37627 This is a multi-part message in MIME format. --------------PZZxSv6fMb60yOagB00kKeOq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hey Xen Team, I'm hitting a reproducible hypervisor panic in the AMD non-fatal MCE polling path on a Ryzen 9 5950X (Zen 3). Eight occurrences since 2026-09-09, between 12 hours and 2 weeks apart, always CPU 2. Environment ----------- Xen:   4.20.4-pre (Debian 4.20.3+127-gc42374a105-0+deb13u1), and still        present in 4.20.5-pre (Debian 4.20.4+39-gf1e1321c87-0+deb13u1) dom0:  Linux 6.12.111+deb13-amd64 (Debian trixie), PV, 32 vCPUs CPU:   AMD Family 25 (0x19) Model 33 (0x21) Stepping 2, Ryzen 9 5950X,        microcode 0x0a201210 Cmdline: dom0_mem=4096M,max:4096M ucode=scan console_timestamps=datems The panic --------- (XEN) [2026-10-19 08:58:18.727] Xen BUG at arch/x86/cpu/mcheck/mce_amd.c:100 (XEN) CPU:    2 (XEN) RIP:    e008:[] mce_amd.c#mc_ec2type.part.0+0/0x10 (XEN) rbx: 0000000000000445   r12: 0000000000000011   r15: 0000000000000446 (XEN) Xen code around : (XEN)  90 90 90 90 90 90 90 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 (XEN) Xen call trace: (XEN)    [] R mce_amd.c#mc_ec2type.part.0+0/0x10 (XEN)    [] S mc_amd_recoverable_scan+0x39/0x40 (XEN)    [] S mcheck_mca_logout+0x42d/0x840 (XEN)    [] S amd_nonfatal.c#mce_amd_checkregs+0x1c/0x100 (XEN)    [] S smp_call_function_interrupt+0x4c/0x90 (XEN)    [] S do_IRQ+0x2a5/0x650 (XEN)    [] S common_interrupt+0x135/0x150 (XEN)    [] S cpu_idle.c#acpi_idle_do_entry+0x8a/0x140 (XEN)    [] S cpu_idle.c#acpi_processor_idle+0x1ef/0x650 (XEN)    [] S domain.c#idle_loop+0xc1/0x130 (XEN) Panic on CPU 2 The outlined mc_ec2type.part.0 contains nothing but the ud2, so this is the "unreachable" default branch of mc_ec2type() -- the extended error code matches none of MC_EC_TLB_TYPE, MC_EC_MEM_TYPE, MC_EC_BUS_TYPE. Across the eight occurrences, r12 appears to be the bank index from the loop in mcheck_mca_logout(), with rbx == 0x401 + 4 * r12 (MCi_STATUS) and r15 == rbx + 1. Three different banks are involved: 10, 17 and 23. Not a hardware defect --------------------- - Started within days of upgrading two hosts from Debian bookworm   (Xen 4.17) to trixie (Xen 4.20). They had run 3 years on 4.17 with no   incident. - Three different banks, so not a single failing block. - Updating to the current Debian package (4.20.5-pre, built 2026-10-16)   changed nothing. Possibly related: 532988dccc19 ("x86/mcheck: fix mca_allbanks updating"). Also possibly related on the Linux side: 0422b07bc4c2 ("x86/mce/amd: Filter bogus hardware errors on Zen3 clients"), where bogus MCA values on Zen 3 are filtered rather than treated as errors. https://ratatoskr.run/stable/2026/04/7143905 Diagnostics / workaround ------------------------ mce_verbosity=verbose yields nothing useful. max_cstate=1 made no difference. mce=false is the only thing that stops it, and it is what I'm running now. One more thing: the host does not actually reboot after the panic. "Reboot in five seconds" is printed, but the ring buffer continues with normal activity minutes later and the remaining 31 CPUs keep running. CPU 2 stays wedged, and "xl debug-keys t" then hangs. Afterwards dom0 and guest vCPUs start losing timer interrupts permanently (RCU stalls with a frozen timer-softirq count while dynticks keeps advancing), so VMs hang silently hours or days later. I've attached the full xl dmesg log of the last crash, and I'm happy to provide more if needed. I can also test patches. Thanks for your work, and thanks in advance for taking a look. Peter --------------PZZxSv6fMb60yOagB00kKeOq Content-Type: text/plain; charset=UTF-8; name="xl_dmesg.log" Content-Disposition: attachment; filename="xl_dmesg.log" Content-Transfer-Encoding: base64 KFhFTikgWzAwMDAwMDMxYjk3YjYwOGVdIFhlbiB2ZXJzaW9uIDQuMjAuNS1wcmUgKERlYmlh biA0LjIwLjQrMzktZ2YxZTEzMjFjODctMCtkZWIxM3UxKSAocGtnLXhlbi1kZXZlbEBsaXN0 cy5hbGlvdGguZGViaWFuLm9yZykgKHg4Nl82NC1saW51eC1nbnUtZ2NjIChEZWJpYW4gMTQu Mi4wLTE5KSAxNC4yLjApIGRlYnVnPW4gRnJpIE9jdCAxNiAxNDoyODo0NyBVVEMgMjAyNg0K KFhFTikgWzAwMDAwMDMxYjk4MTZjYzBdIGJ1aWxkLWlkOiBmNmIyNTg4OGU0MmRkMThlOTUx ZjMwOTdiYTg2MWM5OTk2YTViNzRjDQooWEVOKSBbMDAwMDAwMzFiOTgzOGE3ZV0gQ1BVIFZl bmRvcjogQU1ELCBGYW1pbHkgMjUgKDB4MTkpLCBNb2RlbCAzMyAoMHgyMSksIFN0ZXBwaW5n IDIgKHJhdyAwMGEyMGYxMikNCihYRU4pIFswMDAwMDAzMWI5ODY2Yzg4XSBCU1AgbWljcm9j b2RlIHJldmlzaW9uOiAweDBhMjAxMjEwDQooWEVOKSBbMDAwMDAwMzFiOTg4MTcyMF0gV0FS TklORzogUGxhdGZvcm0gdnVsbmVyYWJsZSB0byBFbnRyeXNpZ24gKFNCLTcwMzMsIENWRS0y MDI0LTM2MzQ3KSAtIGZpcm13YXJlIHVwZGF0ZSByZXF1aXJlZA0KKFhFTikgWzAwMDAwMDMx Yjk4Y2Y1OTJdIEJvb3Rsb2FkZXI6IEdSVUIgMi4xMi05K2RlYjEzdTINCihYRU4pIFswMDAw MDAzMWI5OGRjZDIwXSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIGRvbTBfbWVtPTQwOTZN LG1heDo0MDk2TSB1Y29kZT1zY2FuIGNvbnNvbGVfdGltZXN0YW1wcz1kYXRlbXMNCihYRU4p IFswMDAwMDAzMWI5OTAzMjMwXSBYZW4gaW1hZ2UgbG9hZCBiYXNlIGFkZHJlc3M6IDB4YmU4 MDAwMDANCihYRU4pIFswMDAwMDAzMWI5OTIwMTBhXSBWaWRlbyBpbmZvcm1hdGlvbjoNCihY RU4pIFswMDAwMDAzMWI5OTMzN2IwXSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4 eDE2DQooWEVOKSBbMDAwMDAwMzFiOTk0ZTI2YV0gIFZCRS9EREMgbWV0aG9kczogbm9uZTsg RURJRCB0cmFuc2ZlciB0aW1lOiAxIHNlY29uZHMNCihYRU4pIFswMDAwMDAzMWI5OTcxNjc4 XSAgRURJRCBpbmZvIG5vdCByZXRyaWV2ZWQgYmVjYXVzZSBubyBEREMgcmV0cmlldmFsIG1l dGhvZCBkZXRlY3RlZA0KKFhFTikgWzAwMDAwMDMxYjk5OWExNjJdIERpc2MgaW5mb3JtYXRp b246DQooWEVOKSBbMDAwMDAwMzFiOTlhZDBmZV0gIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMN CihYRU4pIFswMDAwMDAzMWI5OWMyYzA4XSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3Ry dWN0dXJlcw0KKFhFTikgWzAwMDAwMDMxYjk5ZGRkY2NdIEVuYWJsaW5nIFN1cGVydmlzb3Ig U2hhZG93IFN0YWNrcw0KKFhFTikgWzAwMDAwMDMxYjk5Zjk3MDBdIEZhaWxlZCB0byBjb252 ZXJ0IEU4MjAgUkFNIGU2Y2MwLWU3M2JkIHRvIFJFU0VSVkVEDQooWEVOKSBbMDAwMDAwMzFi OWExOWY3ZV0gRmFpbGVkIHRvIGNvbnZlcnQgRTgyMCBSQU0gZTZjYzAtZTczYmQgdG8gUkVT RVJWRUQNCihYRU4pIFswMDAwMDAzMWI5YTNlMDJhXSBYZW4tZTgyMCBSQU0gbWFwOg0KKFhF TikgWzAwMDAwMDMxYjlmZGVmOWVdICBbMDAwMDAwMDAwMDAwMDAwMCwgMDAwMDAwMDAwMDA5 ZWJmZl0gKHVzYWJsZSkNCihYRU4pIFswMDAwMDAzMWJhNTYyMjAyXSAgWzAwMDAwMDAwMDAw OWVjMDAsIDAwMDAwMDAwMDAwOWZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWJh YWY0NTk2XSAgWzAwMDAwMDAwMDAwZTAwMDAsIDAwMDAwMDAwMDAwZmZmZmZdIChyZXNlcnZl ZCkNCihYRU4pIFswMDAwMDAzMWJiMDg1NmQ2XSAgWzAwMDAwMDAwMDAxMDAwMDAsIDAwMDAw MDAwMDliZmVmZmZdICh1c2FibGUpDQooWEVOKSBbMDAwMDAwMzFiYjYxNmU5OF0gIFswMDAw MDAwMDA5YmZmMDAwLCAwMDAwMDAwMDA5ZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAw MDAwMzFiYmMwYzdhY10gIFswMDAwMDAwMDBhMDAwMDAwLCAwMDAwMDAwMDBhMWZmZmZmXSAo dXNhYmxlKQ0KKFhFTikgWzAwMDAwMDMxYmMxOWM1MDBdICBbMDAwMDAwMDAwYTIwMDAwMCwg MDAwMDAwMDAwYTIwZGZmZl0gKEFDUEkgTlZTKQ0KKFhFTikgWzAwMDAwMDMxYmM3MmNlMDRd ICBbMDAwMDAwMDAwYTIwZTAwMCwgMDAwMDAwMDAwYWZmZmZmZl0gKHVzYWJsZSkNCihYRU4p IFswMDAwMDAzMWJjY2JjYThjXSAgWzAwMDAwMDAwMGIwMDAwMDAsIDAwMDAwMDAwMGIwMWZm ZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWJkMjRjOTU2XSAgWzAwMDAwMDAwMGIw MjAwMDAsIDAwMDAwMDAwYmIzMGJmZmZdICh1c2FibGUpDQooWEVOKSBbMDAwMDAwMzFiZDdk Y2RmOF0gIFswMDAwMDAwMGJiMzBjMDAwLCAwMDAwMDAwMGJjYjBjZmZmXSAocmVzZXJ2ZWQp DQooWEVOKSBbMDAwMDAwMzFiZGQ2YzdiNl0gIFswMDAwMDAwMGJjYjBkMDAwLCAwMDAwMDAw MGJjYjRiZmZmXSAoQUNQSSBkYXRhKQ0KKFhFTikgWzAwMDAwMDMxYmUyZmU2ODJdICBbMDAw MDAwMDBiY2I0YzAwMCwgMDAwMDAwMDBiZDIwM2ZmZl0gKEFDUEkgTlZTKQ0KKFhFTikgWzAw MDAwMDMxYmU4OGZiZTBdICBbMDAwMDAwMDBiZDIwNDAwMCwgMDAwMDAwMDBiZTFmZWZmZl0g KHJlc2VydmVkKQ0KKFhFTikgWzAwMDAwMDMxYmVlODU3NThdICBbMDAwMDAwMDBiZTFmZjAw MCwgMDAwMDAwMDBiZWZmZmZmZl0gKHVzYWJsZSkNCihYRU4pIFswMDAwMDAzMWJmNDE1MGIw XSAgWzAwMDAwMDAwYmYwMDAwMDAsIDAwMDAwMDAwYmZmZmZmZmZdIChyZXNlcnZlZCkNCihY RU4pIFswMDAwMDAzMWJmOWE2ZTA2XSAgWzAwMDAwMDAwZjAwMDAwMDAsIDAwMDAwMDAwZjdm ZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWJmZjM5MDQ2XSAgWzAwMDAwMDAw ZmQyMDAwMDAsIDAwMDAwMDAwZmQyZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAz MWMwNGNhOGY2XSAgWzAwMDAwMDAwZmQ2MDAwMDAsIDAwMDAwMDAwZmQ3ZmZmZmZdIChyZXNl cnZlZCkNCihYRU4pIFswMDAwMDAzMWMwYTViNzI4XSAgWzAwMDAwMDAwZmVhMDAwMDAsIDAw MDAwMDAwZmVhMGZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWMwZmVkODM2XSAg WzAwMDAwMDAwZmViODAwMDAsIDAwMDAwMDAwZmVjMDFmZmZdIChyZXNlcnZlZCkNCihYRU4p IFswMDAwMDAzMWMxNTdmMjE4XSAgWzAwMDAwMDAwZmVjMTAwMDAsIDAwMDAwMDAwZmVjMTBm ZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWMxYjExM2QwXSAgWzAwMDAwMDAwZmVj MzAwMDAsIDAwMDAwMDAwZmVjMzBmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWMy MGE1MDVjXSAgWzAwMDAwMDAwZmVkMDAwMDAsIDAwMDAwMDAwZmVkMDBmZmZdIChyZXNlcnZl ZCkNCihYRU4pIFswMDAwMDAzMWMyNjliMTAyXSAgWzAwMDAwMDAwZmVkNDAwMDAsIDAwMDAw MDAwZmVkNDRmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWMyYzJjMzMwXSAgWzAw MDAwMDAwZmVkODAwMDAsIDAwMDAwMDAwZmVkOGZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsw MDAwMDAzMWMzMWJkMjk0XSAgWzAwMDAwMDAwZmVkYzIwMDAsIDAwMDAwMDAwZmVkY2ZmZmZd IChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWMzNzRmMjRlXSAgWzAwMDAwMDAwZmVkZDQw MDAsIDAwMDAwMDAwZmVkZDVmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAzMWMzY2Ux MWM0XSAgWzAwMDAwMDAwZmYwMDAwMDAsIDAwMDAwMDAwZmZmZmZmZmZdIChyZXNlcnZlZCkN CihYRU4pIFswMDAwMDAzMWM0MjcyYWI4XSAgWzAwMDAwMDAxMDAwMDAwMDAsIDAwMDAwMDIw M2YyZmZmZmZdICh1c2FibGUpDQooWEVOKSBbMDAwMDAwMzFjNDgwMmJhMl0gIFswMDAwMDAy MDNmMzAwMDAwLCAwMDAwMDAyMDNmZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAw MzFjODI0NjliY10gQUNQSTogUlNEUCAwMDBGMDVCMCwgMDAyNCAocjIgQUxBU0tBKQ0KKFhF TikgWzAwMDAwMDMxYzg3YjRmYjJdIEFDUEk6IFhTRFQgQkQxRUM3MjgsIDAwQ0MgKHIxIEFM QVNLQSAgIEEgTSBJICAgMTA3MjAwOSBBTUkgICAxMDAwMDEzKQ0KKFhFTikgWzAwMDAwMDMx YzkzMjU4MTRdIEFDUEk6IEZBQ1AgQkNCM0QwMDAsIDAxMTQgKHI2IEFMQVNLQSAgIEEgTSBJ ICAgMTA3MjAwOSBBTUkgICAgIDEwMDEzKQ0KKFhFTikgWzAwMDAwMDMxYzllMTc5MTBdIEFD UEk6IERTRFQgQkNCMzcwMDAsIDVGNkQgKHIyIEFMQVNLQSAgIEEgTSBJICAgMTA3MjAwOSBJ TlRMIDIwMTIwOTEzKQ0KKFhFTikgWzAwMDAwMDMxY2E5MGEwNGFdIEFDUEk6IEZBQ1MgQkQx RTcwMDAsIDAwNDANCihYRU4pIFswMDAwMDAzMWNhZTc2MzMwXSBBQ1BJOiBTU0RUIEJDQjQz MDAwLCA4Q0U5IChyMiAgICBBTUQgQW1kVGFibGUgICAgICAgIDIgTVNGVCAgNDAwMDAwMCkN CihYRU4pIFswMDAwMDAzMWNiOTc2OTAyXSBBQ1BJOiBTU0RUIEJDQjNGMDAwLCAzQjhFIChy MiAgICBBTUQgIEFNRCBBT0QgICAgICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAw MDAzMWNjNDY5ZjFjXSBBQ1BJOiBTU0RUIEJDQjNFMDAwLCAwM0YxIChyMiBBTEFTS0EgIENQ VVNTRFQgIDEwNzIwMDkgQU1JICAgMTA3MjAwOSkNCihYRU4pIFswMDAwMDAzMWNjZmM5YWFl XSBBQ1BJOiBGSURUIEJDQjM2MDAwLCAwMDlDIChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIw MDkgQU1JICAgICAxMDAxMykNCihYRU4pIFswMDAwMDAzMWNkYWJkNWQ0XSBBQ1BJOiBNQ0ZH IEJDQjM1MDAwLCAwMDNDIChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIwMDkgTVNGVCAgICAx MDAxMykNCihYRU4pIFswMDAwMDAzMWNlNWFmOTc4XSBBQ1BJOiBBQUZUIEJDQjM0MDAwLCAw MDY4IChyMSBBTEFTS0EgT0VNQUFGVCAgIDEwNzIwMDkgTVNGVCAgICAgICA5NykNCihYRU4p IFswMDAwMDAzMWNmMGEzNTI2XSBBQ1BJOiBIUEVUIEJDQjMzMDAwLCAwMDM4IChyMSBBTEFT S0EgICAgQSBNIEkgIDEwNzIwMDkgQU1JICAgICAgICAgNSkNCihYRU4pIFswMDAwMDAzMWNm YmZkOTU0XSBBQ1BJOiBJVlJTIEJDQjMyMDAwLCAwMEQwIChyMiAgQU1EICAgQW1kVGFibGUg ICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFswMDAwMDAzMWQwNmVlNmE4XSBBQ1BJ OiBGUERUIEJDQjMxMDAwLCAwMDQ0IChyMSBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkgQU1J ICAgMTAwMDAxMykNCihYRU4pIFswMDAwMDAzMWQxMWUxMjIyXSBBQ1BJOiBQQ0NUIEJDQjMw MDAwLCAwMDZFIChyMiAgICBBTUQgQW1kVGFibGUgICAgICAgIDEgQU1EICAgICAgICAgMSkN CihYRU4pIFswMDAwMDAzMWQxY2QzZTAyXSBBQ1BJOiBTU0RUIEJDQjI3MDAwLCA4MjEzIChy MiAgICBBTUQgQW1kVGFibGUgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFswMDAw MDAzMWQyN2M2MzNlXSBBQ1BJOiBDUkFUIEJDQjI1MDAwLCAxNzEwIChyMSAgICBBTUQgQW1k VGFibGUgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFswMDAwMDAzMWQzMzFmMTYw XSBBQ1BJOiBDRElUIEJDQjI0MDAwLCAwMDI5IChyMSAgICBBTUQgQW1kVGFibGUgICAgICAg IDEgQU1EICAgICAgICAgMSkNCihYRU4pIFswMDAwMDAzMWQzZTExYjg2XSBBQ1BJOiBTU0RU IEJDQjIzMDAwLCAwNTJDIChyMiAgICBBTUQgQXJ0aWNOT0kgICAgICAgIDEgSU5UTCAyMDEy MDkxMykNCihYRU4pIFswMDAwMDAzMWQ0OTA2OTg4XSBBQ1BJOiBTU0RUIEJDQjFGMDAwLCAz N0RDIChyMiAgICBBTUQgICBBcnRpY04gICAgICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4p IFswMDAwMDAzMWQ1M2ZiZTBjXSBBQ1BJOiBXU01UIEJDQjFFMDAwLCAwMDI4IChyMSBBTEFT S0EgICBBIE0gSSAgIDEwNzIwMDkgQU1JICAgICAxMDAxMykNCihYRU4pIFswMDAwMDAzMWQ1 ZWYyMGU4XSBBQ1BJOiBBUElDIEJDQjFEMDAwLCAwMTVFIChyNCBBTEFTS0EgICBBIE0gSSAg IDEwNzIwMDkgQU1JICAgICAxMDAxMykNCihYRU4pIFswMDAwMDAzMWQ2YTQ5MzI2XSBBQ1BJ OiBTU0RUIEJDQjFDMDAwLCAwMDdEIChyMiAgICBBTUQgQXJ0aWNESVMgICAgICAgIDEgSU5U TCAyMDEyMDkxMykNCihYRU4pIFswMDAwMDAzMWQ3NTNkYzFjXSBBQ1BJOiBTU0RUIEJDQjFB MDAwLCAxMEFGIChyMiAgICBBTUQgICBBcnRpY0MgICAgICAgIDEgSU5UTCAyMDEyMDkxMykN CihYRU4pIFswMDAwMDAzMWQ4MDJmZjM4XSBBQ1BJOiBTU0RUIEJDQjE5MDAwLCAwMEJGIChy MSAgICBBTUQgQW1kVGFibGUgICAgIDEwMDAgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAw MDAzMWQ4YjVmMWQ2XSBTeXN0ZW0gUkFNOiAxMzA5OTFNQiAoMTM0MTM1Mjgwa0IpDQooWEVO KSBbMDAwMDAwMzFlMzU1OGFlOF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQooWEVO KSBbMDAwMDAwMzFlM2FjMTUzYV0gRmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAw LTAwMDAwMDIwM2YzMDAwMDANCihYRU4pIFswMDAwMDAzMWY2MjJlOTEwXSBEb21haW4gaGVh cCBpbml0aWFsaXNlZA0KKFhFTikgWzAwMDAwMDMxZmQxYWRjNDBdIFNNQklPUyAzLjMgcHJl c2VudC4NCihYRU4pIFswMDAwMDAzMWZkNzI1NjkwXSBQQ0k6IE1DRkcgY29uZmlndXJhdGlv biAwOiBiYXNlIGYwMDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDdmDQooWEVOKSBb MDAwMDAwMzFmZTIxMjlmY10gUENJOiBNQ0ZHIGFyZWEgYXQgZjAwMDAwMDAgcmVzZXJ2ZWQg aW4gRTgyMA0KKFhFTikgWzAwMDAwMDMxZmU3OGQxZGFdIFBDSTogVXNpbmcgTUNGRyBmb3Ig c2VnbWVudCAwMDAwIGJ1cyAwMC03Zg0KKFhFTikgWzAwMDAwMDMxZmVkYzc2MTZdIFVzaW5n IEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIFswMDAwMDAzMWZmMzQ4NTZhXSBBQ1BJOiBQ TS1UaW1lciBJTyBQb3J0OiAweDgwOCAoMzIgYml0cykNCihYRU4pIFswMDAwMDAzMWZmOGI3 ZGI0XSBBQ1BJOiB2NSBTTEVFUCBJTkZPOiBjb250cm9sWzA6MF0sIHN0YXR1c1swOjBdDQoo WEVOKSBbMDAwMDAwMzFmZmU0NjBkZV0gQUNQSTogU0xFRVAgSU5GTzogcG0xeF9jbnRbMTo4 MDQsMTowXSwgcG0xeF9ldnRbMTo4MDAsMTowXQ0KKFhFTikgWzAwMDAwMDMyMDA5NDgxYTZd IEFDUEk6IDMyLzY0WCBGQUNTIGFkZHJlc3MgbWlzbWF0Y2ggaW4gRkFEVCAtIGJkMWU3MDAw LzAwMDAwMDAwMDAwMDAwMDAsIHVzaW5nIDMyDQooWEVOKSBbMDAwMDAwMzIwMTQzYzNkNl0g QUNQSTogICAgICAgICAgICAgd2FrZXVwX3ZlY1tiZDFlNzAwY10sIHZlY19zaXplWzIwXQ0K KFhFTikgWzAwMDAwMDMyMDFhYWRkMDBdIE92ZXJyaWRpbmcgQVBJQyBkcml2ZXIgd2l0aCBi aWdzbXANCihYRU4pIFswMDAwMDAzMjAyMDQwMjBhXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MjFd IGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQooWEVOKSBbMDAwMDAwMzIwMjYy MDJkZV0gSU9BUElDWzBdOiBhcGljX2lkIDMzLCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVj MDAwMDAsIEdTSSAwLTIzDQooWEVOKSBbMDAwMDAwMzIwMzEyN2M4MF0gQUNQSTogSU9BUElD IChpZFsweDIyXSBhZGRyZXNzWzB4ZmVjMDEwMDBdIGdzaV9iYXNlWzI0XSkNCihYRU4pIFsw MDAwMDAzMjAzYzE2YjZhXSBJT0FQSUNbMV06IGFwaWNfaWQgMzQsIHZlcnNpb24gMzMsIGFk ZHJlc3MgMHhmZWMwMTAwMCwgR1NJIDI0LTU1DQooWEVOKSBbMDAwMDAwMzIwNDcyOTUyOF0g QUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRm bCkNCihYRU4pIFswMDAwMDAzMjA1MjExNjgwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg YnVzX2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBbMDAwMDAwMzIwNWQ4 NjlhOF0gQUNQSTogSFBFVCBpZDogMHgxMDIyODIwMSBiYXNlOiAweGZlZDAwMDAwDQooWEVO KSBbMDAwMDAwMzIwNjJmNjA5ZV0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1 cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBbMDAwMDAwMzIwNjg4NTI4Nl0gU01QOiBBbGxv d2luZyAzMiBDUFVzICgwIGhvdHBsdWcgQ1BVcykNCihYRU4pIFswMDAwMDAzMjA2ZTFkZDJh XSBJUlEgbGltaXRzOiA1NiBHU0ksIDY2MDAgTVNJL01TSS1YDQooWEVOKSBbMDAwMDAwMzIw NzU5ZjYzMl0gQU1ELVZpOiBJT01NVSBFeHRlbmRlZCBGZWF0dXJlczoNCihYRU4pIFswMDAw MDAzMjA3YjBiMTIwXSAtIFBlcmlwaGVyYWwgUGFnZSBTZXJ2aWNlIFJlcXVlc3QNCihYRU4p IFswMDAwMDAzMjA4MDhjYjdhXSAtIE5YIGJpdA0KKFhFTikgWzAwMDAwMDMyMDg2MDM1MzBd IC0gSW52YWxpZGF0ZSBBbGwgQ29tbWFuZA0KKFhFTikgWzAwMDAwMDMyMDhiNzdhMWNdIC0g UGVyZm9ybWFuY2UgQ291bnRlcnMNCihYRU4pIFswMDAwMDAzMjA5MTU2YmVlXSAtIEhvc3Qg QWRkcmVzcyBUcmFuc2xhdGlvbiBTaXplOiAweDINCihYRU4pIFswMDAwMDAzMjA5NmQ3YzUy XSAtIEd1ZXN0IEFkZHJlc3MgVHJhbnNsYXRpb24gU2l6ZTogMA0KKFhFTikgWzAwMDAwMDMy MDljNWNmYzhdIC0gR3Vlc3QgQ1IzIFJvb3QgVGFibGUgTGV2ZWw6IDB4MQ0KKFhFTikgWzAw MDAwMDMyMGExZTFlYmFdIC0gTWF4aW11bSBQQVNJRDogMHhmDQooWEVOKSBbMDAwMDAwMzIw YTc1ZGI1MF0gLSBTTUkgRmlsdGVyIFJlZ2lzdGVyOiAweDENCihYRU4pIFswMDAwMDAzMjBh Y2Q2ZDIyXSAtIFNNSSBGaWx0ZXIgUmVnaXN0ZXIgQ291bnQ6IDB4Mg0KKFhFTikgWzAwMDAw MDMyMGIyNTY5YmNdIC0gR3Vlc3QgVmlydHVhbCBBUElDIE1vZGVzOiAweDENCihYRU4pIFsw MDAwMDAzMjBiN2Q3OWRjXSAtIER1YWwgUFBSIExvZzogMHgyDQooWEVOKSBbMDAwMDAwMzIw YmQ1MTM4NF0gLSBEdWFsIEV2ZW50IExvZzogMHgyDQooWEVOKSBbMDAwMDAwMzIwYzMyYzUz MF0gLSBVc2VyIC8gU3VwZXJ2aXNvciBQYWdlIFByb3RlY3Rpb24NCihYRU4pIFswMDAwMDAz MjBjOGFjZDM2XSAtIERldmljZSBUYWJsZSBTZWdtZW50YXRpb246IDB4Mw0KKFhFTikgWzAw MDAwMDMyMGNlMzE3ZThdIC0gUFBSIExvZyBPdmVyZmxvdyBFYXJseSBXYXJuaW5nDQooWEVO KSBbMDAwMDAwMzIwZDNiNDE0NF0gLSBQUFIgQXV0b21hdGljIFJlc3BvbnNlDQooWEVOKSBb MDAwMDAwMzIwZDkzMmRjY10gLSBNZW1vcnkgQWNjZXNzIFJvdXRpbmcgYW5kIENvbnRyb2w6 IDB4MQ0KKFhFTikgWzAwMDAwMDMyMGRlYjZlODhdIC0gQmxvY2sgU3RvcE1hcmsgTWVzc2Fn ZQ0KKFhFTikgWzAwMDAwMDMyMGU0M2E4NWNdIC0gUGVyZm9ybWFuY2UgT3B0aW1pemF0aW9u DQooWEVOKSBbMDAwMDAwMzIwZTliNzRjMF0gLSBNU0kgQ2FwYWJpbGl0eSBNTUlPIEFjY2Vz cw0KKFhFTikgWzAwMDAwMDMyMGVmMzU1NTRdIC0gR3Vlc3QgSS9PIFByb3RlY3Rpb24NCihY RU4pIFswMDAwMDAzMjBmNGIxOGIwXSAtIEhvc3QgQWNjZXNzDQooWEVOKSBbMDAwMDAwMzIw ZmE4YWYyMl0gLSBFbmhhbmNlZCBQUFIgSGFuZGxpbmcNCihYRU4pIFswMDAwMDAzMjBmZmZl ZTE0XSAtIEF0dHJpYnV0ZSBGb3J3YXJkDQooWEVOKSBbMDAwMDAwMzIxMDU3NmUxYV0gLSBW aXJ0dWFsaXplZCBJT01NVQ0KKFhFTikgWzAwMDAwMDMyMTBhZWNhODhdIC0gVk1HdWFyZCBJ L08gU3VwcG9ydA0KKFhFTikgWzAwMDAwMDMyMTEwNjNlZGVdIC0gVk0gVGFibGUgU2l6ZTog MHgyDQooWEVOKSBbMDAwMDAwMzIxMmUzYjBjMF0gU3dpdGNoZWQgdG8gQVBJQyBkcml2ZXIg eDJhcGljX21peGVkDQooWEVOKSBbMDAwMDAwMzIxMzQwZDgwOF0gQ1BVMDogMjIwMCAuLi4g MzQwMCBNSHoNCihYRU4pIFswMDAwMDAzMjEzOTczODFlXSB4c3RhdGU6IHNpemU6IDB4OTg4 IGFuZCBzdGF0ZXM6IDB4MjA3DQooWEVOKSBbMDAwMDAwMzIxM2YxNGZmMF0gQ1BVMDogQU1E IEZhbTE5aCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkDQooWEVOKSBbMDAwMDAw MzIxNDQ4ZGQ4Ml0gU3BlY3VsYXRpdmUgbWl0aWdhdGlvbiBmYWNpbGl0aWVzOg0KKFhFTikg WzAwMDAwMDMyMTRhMTU4ZjJdICAgSGFyZHdhcmUgaGludHM6IFNUSUJQX0FMV0FZUyBJQlJT X0ZBU1QgSUJSU19TQU1FX01PREUNCihYRU4pIFswMDAwMDAzMjE0ZmE2MjVjXSAgIEhhcmR3 YXJlIGZlYXR1cmVzOiBJQlBCIElCUlMgU1RJQlAgU1NCRCBQU0ZEDQooWEVOKSBbMDAwMDAw MzIxNTUzOGU0ZV0gICBDb21waWxlZC1pbiBzdXBwb3J0OiBJTkRJUkVDVF9USFVOSyBSRVRV Uk5fVEhVTksgSEFSREVOX0FSUkFZIEhBUkRFTl9CUkFOQ0ggSEFSREVOX0dVRVNUX0FDQ0VT UyBIQVJERU5fTE9DSw0KKFhFTikgWzAwMDAwMDMyMTYwNTlkYWVdICAgWGVuIHNldHRpbmdz OiBCVEktVGh1bms6IEpNUCwgU1BFQ19DVFJMOiBJQlJTKyBTVElCUCsgU1NCRC0gUFNGRC0s IE90aGVyOiBCUkFOQ0hfSEFSREVODQooWEVOKSBbMDAwMDAwMzIxNmJkNGZhYV0gICBTdXBw b3J0IGZvciBIVk0gVk1zOiBNU1JfU1BFQ19DVFJMIE1TUl9WSVJUX1NQRUNfQ1RSTCBSU0Ig SUJQQi1lbnRyeQ0KKFhFTikgWzAwMDAwMDMyMTc2Y2ZhZThdICAgU3VwcG9ydCBmb3IgUFYg Vk1zOiBJQlBCLWVudHJ5DQooWEVOKSBbMDAwMDAwMzIxN2M0MWNhMl0gICBYUFRJICg2NC1i aXQgUFYgb25seSk6IERvbTAgZGlzYWJsZWQsIERvbVUgZGlzYWJsZWQgKHdpdGhvdXQgUENJ RCkNCihYRU4pIFswMDAwMDAzMjE4NzQ2MzY2XSAgIFBWIEwxVEYgc2hhZG93aW5nOiBEb20w IGRpc2FibGVkLCBEb21VIGRpc2FibGVkDQooWEVOKSBbMDAwMDAwMzIxOGNjMDdhZV0gVXNp bmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciByZXYyIChjcmVkaXQyKQ0KKFhF TikgWzAwMDAwMDMyMTkyNTI0OWVdIEluaXRpYWxpemluZyBDcmVkaXQyIHNjaGVkdWxlcg0K KFhFTikgWzAwMDAwMDMyMTk3ZGUwMTJdICBsb2FkX3ByZWNpc2lvbl9zaGlmdDogMTgNCihY RU4pIFswMDAwMDAzMjE5ZGJmYzQyXSAgbG9hZF93aW5kb3dfc2hpZnQ6IDMwDQooWEVOKSBb MDAwMDAwMzIxYTMzYTAyNF0gIHVuZGVybG9hZF9iYWxhbmNlX3RvbGVyYW5jZTogMA0KKFhF TikgWzAwMDAwMDMyMWE4YjgwMzBdICBvdmVybG9hZF9iYWxhbmNlX3RvbGVyYW5jZTogLTMN CihYRU4pIFswMDAwMDAzMjFhZTNhOThjXSAgcnVucXVldWVzIGFycmFuZ2VtZW50OiBzb2Nr ZXQNCihYRU4pIFswMDAwMDAzMjFiM2JjMjBhXSAgY2FwIGVuZm9yY2VtZW50IGdyYW51bGFy aXR5OiAxMG1zDQooWEVOKSBbMDAwMDAwMzIxYjkzZmYzMF0gbG9hZCB0cmFja2luZyB3aW5k b3cgbGVuZ3RoIDEwNzM3NDE4MjQgbnMNCihYRU4pIFswMDAwMDAzMjI2MGM0YjcyXSBQbGF0 Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVA0KKFhFTikgWyAgICAwLjczNTA1NF0gRGV0 ZWN0ZWQgMzM5My42MDggTUh6IHByb2Nlc3Nvci4NCihYRU4pIFsgICAgMC43MzkyNTZdIEZy ZWVkIDEwMjRrQiB1bnVzZWQgQlNTIG1lbW9yeQ0KKFhFTikgWyAgICAwLjc0MDkzMF0gYWx0 IHRhYmxlIGZmZmY4MmQwNDA0NTMzYjggLT4gZmZmZjgyZDA0MDQ2MmY2NA0KKFhFTikgWyAg ICAwLjc1NDgxMF0gQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBbICAgIDAuNzU2 NDc2XSBJL08gdmlydHVhbGlzYXRpb24gZW5hYmxlZA0KKFhFTikgWyAgICAwLjc1ODE2NV0g IC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBbICAgIDAuNzU5ODUwXSBJbnRlcnJ1cHQg cmVtYXBwaW5nIGVuYWJsZWQNCihYRU4pIFsgICAgMC43NjE1NDFdIEVuYWJsaW5nIEFQSUMg bW9kZS4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVOKSBbICAgIDAuNzYzOTQ0XSBFTkFCTElO RyBJTy1BUElDIElSUXMNCihYRU4pIFsgICAgMC43NjU2MDZdICAtPiBVc2luZyBuZXcgQUNL IG1ldGhvZA0KKFhFTikgWyAgICAwLjc2NzQ3M10gLi5USU1FUjogdmVjdG9yPTB4RjAgYXBp YzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgWyAgICAwLjkxOTI1NV0gV2Fs bGNsb2NrIHNvdXJjZTogQ01PUyBSVEMNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjAw MF0gRGVmYXVsdGluZyB0byBhbHRlcm5hdGl2ZSBrZXkgaGFuZGxpbmc7IHNlbmQgJ0EnIHRv IHN3aXRjaCB0byBub3JtYWwgbW9kZS4NCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjAw M10gQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiAxMjggS2lCLg0KKFhFTikgWzIwMjYtMTAt MTggMTk6NTc6MzQuMDA1XSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAyNi0xMC0x OCAxOTo1NzozNC4wMDZdIFNWTTogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhF TikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDA4XSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5Q VCkNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjAxMF0gIC0gTGFzdCBCcmFuY2ggUmVj b3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4w MTJdICAtIE5leHQtUklQIFNhdmVkIG9uICNWTUVYSVQNCihYRU4pIFsyMDI2LTEwLTE4IDE5 OjU3OjM0LjAxM10gIC0gVk1DQiBDbGVhbiBCaXRzDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1 NzozNC4wMTVdICAtIFRMQiBmbHVzaCBieSBBU0lEDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1 NzozNC4wMTddICAtIERlY29kZUFzc2lzdHMNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0 LjAxOF0gIC0gVmlydHVhbCBWTUxPQUQvVk1TQVZFDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1 NzozNC4wMjBdICAtIFZpcnR1YWwgR0lGDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4w MjJdICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXINCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3 OjM0LjAyNF0gIC0gUGF1c2UtSW50ZXJjZXB0IEZpbHRlciBUaHJlc2hvbGQNCihYRU4pIFsy MDI2LTEwLTE4IDE5OjU3OjM0LjAyNV0gIC0gVFNDIFJhdGUgTVNSDQooWEVOKSBbMjAyNi0x MC0xOCAxOTo1NzozNC4wMjddICAtIE5QVCBTdXBlcnZpc29yIFNoYWRvdyBTdGFjaw0KKFhF TikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDI5XSAgLSBNU1JfU1BFQ19DVFJMIHZpcnR1YWxp c2F0aW9uDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wMzBdIEhWTTogU1ZNIGVuYWJs ZWQNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjAzMl0gSFZNOiBIYXJkd2FyZSBBc3Np c3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0 LjAzNF0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFHQg0KKFhFTikgWzIwMjYt MTAtMTggMTk6NTc6MzQuMDM2XSBhbHQgdGFibGUgZmZmZjgyZDA0MDQ1MzNiOCAtPiBmZmZm ODJkMDQwNDYyZjY0DQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wNDJdIEJyb3VnaHQg dXAgMzIgQ1BVcw0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDQ2XSBTY2hlZHVsaW5n IGdyYW51bGFyaXR5OiBjcHUsIDEgQ1BVIHBlciBzY2hlZC1yZXNvdXJjZQ0KKFhFTikgWzIw MjYtMTAtMTggMTk6NTc6MzQuMDUwXSBJbml0aWFsaXppbmcgQ3JlZGl0MiBzY2hlZHVsZXIN CihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjA1Ml0gIGxvYWRfcHJlY2lzaW9uX3NoaWZ0 OiAxOA0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDUzXSAgbG9hZF93aW5kb3dfc2hp ZnQ6IDMwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wNTVdICB1bmRlcmxvYWRfYmFs YW5jZV90b2xlcmFuY2U6IDANCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjA1N10gIG92 ZXJsb2FkX2JhbGFuY2VfdG9sZXJhbmNlOiAtMw0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6 MzQuMDU5XSAgcnVucXVldWVzIGFycmFuZ2VtZW50OiBzb2NrZXQNCihYRU4pIFsyMDI2LTEw LTE4IDE5OjU3OjM0LjA2MF0gIGNhcCBlbmZvcmNlbWVudCBncmFudWxhcml0eTogMTBtcw0K KFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDYyXSBsb2FkIHRyYWNraW5nIHdpbmRvdyBs ZW5ndGggMTA3Mzc0MTgyNCBucw0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDY0XSBB ZGRpbmcgY3B1IDAgdG8gcnVucXVldWUgMA0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQu MDY1XSAgRmlyc3QgY3B1IG9uIHJ1bnF1ZXVlLCBhY3RpdmF0aW5nDQooWEVOKSBbMjAyNi0x MC0xOCAxOTo1NzozNC4wNjddIEFkZGluZyBjcHUgMSB0byBydW5xdWV1ZSAwDQooWEVOKSBb MjAyNi0xMC0xOCAxOTo1NzozNC4wNjldIEFkZGluZyBjcHUgMiB0byBydW5xdWV1ZSAwDQoo WEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wNzFdIEFkZGluZyBjcHUgMyB0byBydW5xdWV1 ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wNzNdIEFkZGluZyBjcHUgNCB0byBy dW5xdWV1ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wNzRdIEFkZGluZyBjcHUg NSB0byBydW5xdWV1ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wNzZdIEFkZGlu ZyBjcHUgNiB0byBydW5xdWV1ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wNzhd IEFkZGluZyBjcHUgNyB0byBydW5xdWV1ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1Nzoz NC4wNzldIEFkZGluZyBjcHUgOCB0byBydW5xdWV1ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAx OTo1NzozNC4wODFdIEFkZGluZyBjcHUgOSB0byBydW5xdWV1ZSAwDQooWEVOKSBbMjAyNi0x MC0xOCAxOTo1NzozNC4wODNdIEFkZGluZyBjcHUgMTAgdG8gcnVucXVldWUgMA0KKFhFTikg WzIwMjYtMTAtMTggMTk6NTc6MzQuMDg1XSBBZGRpbmcgY3B1IDExIHRvIHJ1bnF1ZXVlIDAN CihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjA4N10gQWRkaW5nIGNwdSAxMiB0byBydW5x dWV1ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wODhdIEFkZGluZyBjcHUgMTMg dG8gcnVucXVldWUgMA0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDkwXSBBZGRpbmcg Y3B1IDE0IHRvIHJ1bnF1ZXVlIDANCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjA5Ml0g QWRkaW5nIGNwdSAxNSB0byBydW5xdWV1ZSAwDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1Nzoz NC4wOTNdIEFkZGluZyBjcHUgMTYgdG8gcnVucXVldWUgMQ0KKFhFTikgWzIwMjYtMTAtMTgg MTk6NTc6MzQuMDk1XSAgRmlyc3QgY3B1IG9uIHJ1bnF1ZXVlLCBhY3RpdmF0aW5nDQooWEVO KSBbMjAyNi0xMC0xOCAxOTo1NzozNC4wOTddIEFkZGluZyBjcHUgMTcgdG8gcnVucXVldWUg MQ0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMDk5XSBBZGRpbmcgY3B1IDE4IHRvIHJ1 bnF1ZXVlIDENCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjEwMF0gQWRkaW5nIGNwdSAx OSB0byBydW5xdWV1ZSAxDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4xMDJdIEFkZGlu ZyBjcHUgMjAgdG8gcnVucXVldWUgMQ0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMTA0 XSBBZGRpbmcgY3B1IDIxIHRvIHJ1bnF1ZXVlIDENCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3 OjM0LjEwNl0gQWRkaW5nIGNwdSAyMiB0byBydW5xdWV1ZSAxDQooWEVOKSBbMjAyNi0xMC0x OCAxOTo1NzozNC4xMDddIEFkZGluZyBjcHUgMjMgdG8gcnVucXVldWUgMQ0KKFhFTikgWzIw MjYtMTAtMTggMTk6NTc6MzQuMTA5XSBBZGRpbmcgY3B1IDI0IHRvIHJ1bnF1ZXVlIDENCihY RU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjExMV0gQWRkaW5nIGNwdSAyNSB0byBydW5xdWV1 ZSAxDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4xMTNdIEFkZGluZyBjcHUgMjYgdG8g cnVucXVldWUgMQ0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMTE0XSBBZGRpbmcgY3B1 IDI3IHRvIHJ1bnF1ZXVlIDENCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjExNl0gQWRk aW5nIGNwdSAyOCB0byBydW5xdWV1ZSAxDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4x MThdIEFkZGluZyBjcHUgMjkgdG8gcnVucXVldWUgMQ0KKFhFTikgWzIwMjYtMTAtMTggMTk6 NTc6MzQuMTIwXSBBZGRpbmcgY3B1IDMwIHRvIHJ1bnF1ZXVlIDENCihYRU4pIFsyMDI2LTEw LTE4IDE5OjU3OjM0LjEyMl0gQWRkaW5nIGNwdSAzMSB0byBydW5xdWV1ZSAxDQooWEVOKSBb MjAyNi0xMC0xOCAxOTo1NzozNC4xMjNdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBv bGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjEyN10g bXRycjogeW91ciBDUFVzIGhhZCBpbmNvbnNpc3RlbnQgdmFyaWFibGUgTVRSUiBzZXR0aW5n cw0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMTMwXSBtdHJyOiBwcm9iYWJseSB5b3Vy IEJJT1MgZG9lcyBub3Qgc2V0dXAgYWxsIENQVXMuDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1 NzozNC4xMzRdIG10cnI6IGNvcnJlY3RlZCBjb25maWd1cmF0aW9uLg0KKFhFTikgWzIwMjYt MTAtMTggMTk6NTc6MzQuMTM2XSBNVFJSIGRlZmF1bHQgdHlwZTogdW5jYWNoYWJsZQ0KKFhF TikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMTM3XSBNVFJSIGZpeGVkIHJhbmdlcyBlbmFibGVk Og0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMTM5XSAgIDAwMDAwLTlmZmZmIHdyaXRl LWJhY2sNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjE0MV0gICBhMDAwMC1iZmZmZiB3 cml0ZS10aHJvdWdoDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4xNDJdICAgYzAwMDAt ZmZmZmYgd3JpdGUtcHJvdGVjdA0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMTQ0XSBN VFJSIHZhcmlhYmxlIHJhbmdlcyBlbmFibGVkOg0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6 MzQuMTQ2XSAgIDAgYmFzZSAwMDAwMDAwMDAwMCBtYXNrIGZmZmY4MDAwMDAwMCB3cml0ZS1i YWNrDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4xNDldICAgMSBiYXNlIDAwMDgwMDAw MDAwIG1hc2sgZmZmZmMwMDAwMDAwIHdyaXRlLWJhY2sNCihYRU4pIFsyMDI2LTEwLTE4IDE5 OjU3OjM0LjE1M10gICAyIGJhc2UgMDAwYmNjYjAwMDAgbWFzayBmZmZmZmZmZjAwMDAgdW5j YWNoYWJsZQ0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMTU2XSAgIDMgZGlzYWJsZWQN CihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjE1OF0gICA0IGRpc2FibGVkDQooWEVOKSBb MjAyNi0xMC0xOCAxOTo1NzozNC4xNjBdICAgNSBkaXNhYmxlZA0KKFhFTikgWzIwMjYtMTAt MTggMTk6NTc6MzQuMTYxXSAgIDYgZGlzYWJsZWQNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3 OjM0LjE2M10gICA3IGRpc2FibGVkDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4xNjVd IFRPTTI6IDAwMjA0MDAwMDAwMCAoV0IpDQooWEVOKSBbMjAyNi0xMC0xOCAxOTo1NzozNC4x ODddIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb24gYWN0aXZlDQooWEVOKSBbMjAy Ni0xMC0xOCAxOTo1NzozNC4xODldIGQwIGhhcyBtYXhpbXVtIDY2NTYgUElSUXMNCihYRU4p IFsyMDI2LTEwLTE4IDE5OjU3OjM0LjE5MF0gKioqIEJ1aWxkaW5nIGEgUFYgRG9tMCAqKioN CihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjI2MV0gIFhlbiAga2VybmVsOiA2NC1iaXQs IGxzYg0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMjYyXSAgRG9tMCBrZXJuZWw6IDY0 LWJpdCwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHg0MjAwMDAwDQooWEVOKSBbMjAyNi0x MC0xOCAxOTo1NzozNC4yNjZdIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4p IFsyMDI2LTEwLTE4IDE5OjU3OjM0LjI2OF0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDFmZDgw MDAwMDAtPjAwMDAwMDFmZTAwMDAwMDAgKDEwMDE0NDcgcGFnZXMgdG8gYmUgYWxsb2NhdGVk KQ0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMjcxXSAgSW5pdC4gcmFtZGlzazogMDAw MDAwMjAzYjllNzAwMC0+MDAwMDAwMjAzZjFmZjVmZA0KKFhFTikgWzIwMjYtMTAtMTggMTk6 NTc6MzQuMjc1XSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDI2LTEw LTE4IDE5OjU3OjM0LjI3Nl0gIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZm ZmZmZmZmODQyMDAwMDANCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjI4MF0gIFBoeXMt TWFjaCBtYXA6IDAwMDAwMDgwMDAwMDAwMDAtPjAwMDAwMDgwMDA4MDAwMDANCihYRU4pIFsy MDI2LTEwLTE4IDE5OjU3OjM0LjI4M10gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODQyMDAw MDAtPmZmZmZmZmZmODQyMDA0YjgNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjI4N10g IFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODQyMDEwMDAtPmZmZmZmZmZmODQyMjYwMDANCihY RU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjI5MF0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZm ODQyMjYwMDAtPmZmZmZmZmZmODQyMjcwMDANCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0 LjI5NF0gIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQ0MDAw MDANCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjI5N10gIEVOVFJZIEFERFJFU1M6IGZm ZmZmZmZmODMzNjU3YjANCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjI5OV0gRG9tMCBo YXMgbWF4aW11bSAzMiBWQ1BVcw0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMzE3XSBJ bml0aWFsIGxvdyBtZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4N CihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjMyMV0gU2NydWJiaW5nIEZyZWUgUkFNIGlu IGJhY2tncm91bmQNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjMyM10gU3RkLiBMb2ds ZXZlbDogRXJyb3JzLCB3YXJuaW5ncyBhbmQgaW5mbw0KKFhFTikgWzIwMjYtMTAtMTggMTk6 NTc6MzQuMzI0XSBHdWVzdCBMb2dsZXZlbDogTm90aGluZyAoUmF0ZS1saW1pdGVkOiBFcnJv cnMgYW5kIHdhcm5pbmdzKQ0KKFhFTikgWzIwMjYtMTAtMTggMTk6NTc6MzQuMzI4XSBYZW4g aXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3 OjM0LjMzMF0gKioqIFNlcmlhbCBpbnB1dCB0byBET00wICh0eXBlICdDVFJMLWEnIHRocmVl IHRpbWVzIHRvIHN3aXRjaCBpbnB1dCkNCihYRU4pIFsyMDI2LTEwLTE4IDE5OjU3OjM0LjMz MV0gRnJlZWQgNjU2a0IgaW5pdCBtZW1vcnkNCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4 LjcyN10gWGVuIEJVRyBhdCBhcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9hbWQuYzoxMDANCihY RU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gLS0tLVsgWGVuLTQuMjAuNS1wcmUgIHg4 Nl82NCAgZGVidWc9biAgVGFpbnRlZDogICAgICBTIF0tLS0tDQooWEVOKSBbMjAyNi0xMC0x OSAwODo1ODoxOC43MjddIENQVTogICAgMg0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTgu NzI3XSBSSVA6ICAgIGUwMDg6WzxmZmZmODJkMDQwMjhhNjUwPl0gYXJjaC94ODYvY3B1L21j aGVjay9tY2VfYW1kLmMjbWNfZWMydHlwZS5wYXJ0LjArMC8weDEwDQooWEVOKSBbMjAyNi0x MC0xOSAwODo1ODoxOC43MjddIFJGTEFHUzogMDAwMDAwMDAwMDAxMDA0NiAgIENPTlRFWFQ6 IGh5cGVydmlzb3INCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gcmF4OiAwMDAw MDAwMDAwMDAwMDAxICAgcmJ4OiAwMDAwMDAwMDAwMDAwNDQ1ICAgcmN4OiAwMDAwMDAwMDAw MDAwMDAwDQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddIHJkeDogMDAwMDAwMDAw MDAwMDAwMCAgIHJzaTogMDAwMDAwMDAwMDAwMDAwMSAgIHJkaTogMDAwMDAwMDAwMDAwMDAw MA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSByYnA6IDAwMDAwMDAwMDAwMDAw MDEgICByc3A6IGZmZmY4MzIwMzZhODdjMzggICByODogIGZmZmY4MmQwNDA1OWFmMDANCihY RU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gcjk6ICAwMDAwMDAwMDAwMDAwMDAwICAg cjEwOiBmZmZmODMyMDM2YThiMDAwICAgcjExOiAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBb MjAyNi0xMC0xOSAwODo1ODoxOC43MjddIHIxMjogMDAwMDAwMDAwMDAwMDAxMSAgIHIxMzog ZmZmZjgzMjAzNmEzMzA0OCAgIHIxNDogZmZmZjgzMjAzNmFlYmI3MA0KKFhFTikgWzIwMjYt MTAtMTkgMDg6NTg6MTguNzI3XSByMTU6IDAwMDAwMDAwMDAwMDA0NDYgICBjcjA6IDAwMDAw MDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDBmNTA2ZTANCihYRU4pIFsyMDI2LTEwLTE5 IDA4OjU4OjE4LjcyN10gY3IzOiAwMDAwMDAxODZlODQ2MDAwICAgY3IyOiAwMDAwN2YxNjgy ZjY3YTA4DQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddIGZzYjogMDAwMDAwMDAw MDAwMDAwMCAgIGdzYjogZmZmZjg4ODE3YWEwMDAwMCAgIGdzczogMDAwMDAwMDAwMDAwMDAw MA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSBkczogMDAwMCAgIGVzOiAwMDAw ICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNzOiAwMDAwICAgY3M6IGUwMDgNCihYRU4pIFsy MDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gWGVuIGNvZGUgYXJvdW5kIDxmZmZmODJkMDQwMjhh NjUwPiAoYXJjaC94ODYvY3B1L21jaGVjay9tY2VfYW1kLmMjbWNfZWMydHlwZS5wYXJ0LjAp Og0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgOTAgOTAgOTAgOTAgOTAgOTAg OTAgOTAgPDBmPiAwYiA5MCA5MCA5MCA5MCA5MCA5MCA5MCA5MCA5MCA5MCA5MCA5MCA5MCA5 MA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSBYZW4gc3RhY2sgdHJhY2UgZnJv bSByc3A9ZmZmZjgzMjAzNmE4N2MzODoNCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4Ljcy N10gICAgZmZmZjgyZDA0MDI4YTY5OSBmZmZmODJkMDQwMjhjZmRkIGZmZmY4MmQwNDA1ODMy ZDAgZmZmZjgzMjAzNmFlMWVhMA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAg ICAwMDAwMDQ0NTAwMDAwMDAxIDAwMDAwMDAxZWU3MGMwMDEgZmZmZjgzMjAzNmFlYmQ3MCBm ZmZmODMyMDM2YWUxZWE4DQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddICAgIDAw MDEwMTAxMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4 MzIwMzZhODdjZTANCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gICAgMDAwMDAw MDgwMDAwMDAwMSBmZmZmODMyMDM2YThiMDAwIGZmZmY4MmQwNDA1ODhmODAgMDAwMDAwMDAw MDAwMDAwMg0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgICAwMDAwMDAwMDAw MDAwMGZiIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgyZDA0MDU4OGY4MCAwMDAwMDAwMDAwMDAw MDAwDQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddICAgIGZmZmY4MmQwNDAyOGEz NWMgZmZmZjgzMjAzNmE4N2RkNyBmZmZmODJkMDQwMmJmYzQ1IGZmZmY4MmQwNDA1ODhmODAN CihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gICAgZmZmZjgyZDA0MDI0MGU4YyAw MDAwMDAwMDAwMDAwMGZiIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgyZDA0MDMxMjNkNQ0KKFhF TikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgICBmZmZmODMyMDM2YTg3ZDQwIDAwMDAw MDAwMDAwMDAwMDAgODAwMDAwMDAwMDAwMDAwNSBmZmZmODMyMDM2YTg3ZDk4DQooWEVOKSBb MjAyNi0xMC0xOSAwODo1ODoxOC43MjddICAgIGZmZmY4MzFmZTY2YmZhYTAgMDAwMDAwMDAw MDE3YWEyZiAwMDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDI2 LTEwLTE5IDA4OjU4OjE4LjcyN10gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw MDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMjAzNmE4N2ZmZg0KKFhFTikgWzIwMjYtMTAt MTkgMDg6NTg6MTguNzI3XSAgICAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MmQwNDAyMDE5MTUg ZmZmZjgyZDA0MDQ2Njc2MCBmZmZmODJkMDQwNTg4ZjgwDQooWEVOKSBbMjAyNi0xMC0xOSAw ODo1ODoxOC43MjddICAgIDAwMDAyYTliNjA5NDc2ZTIgMDAwMDAwMDAwMDAwMDAwMiBmZmZm ODMyMDM2YTg4MDEwIGZmZmY4MzIwMzZhODgwNjgNCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4 OjE4LjcyN10gICAgZmZmZjgzMTM3NDBkYzAzMCBmZmZmODJkMDQwNTg4ZjgwIDAwMDAwMDAw MDAwMDAwMDIgMDAwMDAwMDAwMDAwMDAwMg0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTgu NzI3XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwNDggMDAwMDAwMDAwMDAw MDAwMCBmZmZmODMyMDM2YTg3ZWY4DQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43Mjdd ICAgIDAwMDAwMDAwMDAwMDAwNDggMDAwMDAwZmIwMDAwMDAwMCBmZmZmODJkMDQwMjg4M2Nh IDAwMDAwMDAwMDAwMGUwMDgNCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gICAg MDAwMDAwMDAwMDAwMDI0NiBmZmZmODMyMDM2YTg3ZTM4IDAwMDAwMDAwMDAwMDAwMDAgMDAw MDJhOWI2MDk0NzZlMg0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgICBmZmZm ODJkMDQwMjg4N2NmIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw MDAwMDAwMDAwDQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddICAgIGZmZmY4MmQw MDAwMDAwZmYgMDAwMDAwMDAwMDAwMDAwMiBmZmZmODJkMDQwNDY2NzYwIDAwMDAwMDAwMDAw MDAwMDINCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10gICAgMDAwMDAwMDAwMDAw MDAwMiBmZmZmODJkMDQwNDZiZGEwIDAwMDAwMDAwMDAwMDdmZmYgZmZmZjgyZDA0MDU4OGY4 MA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgICBmZmZmODJkMDQwNDY2NzYw IGZmZmY4MmQwNDAzMDJjZjEgZmZmZjgyZDA0MDU4OTA4MCBmZmZmODJkMDQwNTgyMjEwDQoo WEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikg WzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgICBbPGZmZmY4MmQwNDAyOGE2NTA+XSBSIGFy Y2gveDg2L2NwdS9tY2hlY2svbWNlX2FtZC5jI21jX2VjMnR5cGUucGFydC4wKzAvMHgxMA0K KFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgICBbPGZmZmY4MmQwNDAyOGE2OTk+ XSBTIG1jX2FtZF9yZWNvdmVyYWJsZV9zY2FuKzB4MzkvMHg0MA0KKFhFTikgWzIwMjYtMTAt MTkgMDg6NTg6MTguNzI3XSAgICBbPGZmZmY4MmQwNDAyOGNmZGQ+XSBTIG1jaGVja19tY2Ff bG9nb3V0KzB4NDJkLzB4ODQwDQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddICAg IFs8ZmZmZjgyZDA0MDI4YTM1Yz5dIFMgYXJjaC94ODYvY3B1L21jaGVjay9hbWRfbm9uZmF0 YWwuYyNtY2VfYW1kX2NoZWNrcmVncysweDFjLzB4MTAwDQooWEVOKSBbMjAyNi0xMC0xOSAw ODo1ODoxOC43MjddICAgIFs8ZmZmZjgyZDA0MDJiZmM0NT5dIFMgYXJjaC94ODYvaHZtL2h2 bS5jI19faHZtX2NvcHkrMHgxYTUvMHg0NzANCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4 LjcyN10gICAgWzxmZmZmODJkMDQwMjQwZThjPl0gUyBzbXBfY2FsbF9mdW5jdGlvbl9pbnRl cnJ1cHQrMHg0Yy8weDkwDQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddICAgIFs8 ZmZmZjgyZDA0MDMxMjNkNT5dIFMgZG9fSVJRKzB4MmE1LzB4NjUwDQooWEVOKSBbMjAyNi0x MC0xOSAwODo1ODoxOC43MjddICAgIFs8ZmZmZjgyZDA0MDIwMTkxNT5dIFMgY29tbW9uX2lu dGVycnVwdCsweDEzNS8weDE1MA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAg ICBbPGZmZmY4MmQwNDAyODgzY2E+XSBTIGFyY2gveDg2L2FjcGkvY3B1X2lkbGUuYyNhY3Bp X2lkbGVfZG9fZW50cnkrMHg4YS8weDE0MA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTgu NzI3XSAgICBbPGZmZmY4MmQwNDAyODg3Y2Y+XSBTIGFyY2gveDg2L2FjcGkvY3B1X2lkbGUu YyNhY3BpX3Byb2Nlc3Nvcl9pZGxlKzB4MWVmLzB4NjUwDQooWEVOKSBbMjAyNi0xMC0xOSAw ODo1ODoxOC43MjddICAgIFs8ZmZmZjgyZDA0MDMwMmNmMT5dIFMgYXJjaC94ODYvZG9tYWlu LmMjaWRsZV9sb29wKzB4YzEvMHgxMzANCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4Ljcy N10gICAgWzxmZmZmODJkMDQwMzAyYzMwPl0gUyBhcmNoL3g4Ni9kb21haW4uYyNpZGxlX2xv b3ArMC8weDEzMA0KKFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSAgICBbPGZmZmY4 MmQwNDAzMDRlZGM+XSBTIGNvbnRleHRfc3dpdGNoKzB4MWVjLzB4OTAwDQooWEVOKSBbMjAy Ni0xMC0xOSAwODo1ODoxOC43MjddDQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43Mjdd DQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10g UGFuaWMgb24gQ1BVIDI6DQooWEVOKSBbMjAyNi0xMC0xOSAwODo1ODoxOC43MjddIFhlbiBC VUcgYXQgYXJjaC94ODYvY3B1L21jaGVjay9tY2VfYW1kLmM6MTAwDQooWEVOKSBbMjAyNi0x MC0xOSAwODo1ODoxOC43MjddICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCihYRU4pIFsyMDI2LTEwLTE5IDA4OjU4OjE4LjcyN10NCihYRU4pIFsyMDI2LTEw LTE5IDA4OjU4OjE4LjcyN10gUmVib290IGluIGZpdmUgc2Vjb25kcy4uLg== --------------PZZxSv6fMb60yOagB00kKeOq-- From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:29:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:29:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459092.1671166 (Exim 4.92) (envelope-from ) id 1xKCWV-0006RS-5y; Fri, 23 Oct 2026 10:29:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459092.1671166; Fri, 23 Oct 2026 10:29: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 1xKCWV-0006RL-3B; Fri, 23 Oct 2026 10:29:19 +0000 Received: by outflank-mailman (input) for mailman id 1459092; Fri, 23 Oct 2026 10:29:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKCWU-0006QA-1B for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:29:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKCWS-005GKI-W7 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:29:17 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb36f5-e002-0a2a0a5209dd-0a2a4501d882-6 for ; Fri, 23 Oct 2026 12:29:16 +0200 Received: from [52.101.56.48] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb36fb-5984-0a2a45010019-34653830a063-3 for ; Fri, 23 Oct 2026 12:29:16 +0200 Received: from PH7PR17CA0059.namprd17.prod.outlook.com (2603:10b6:510:325::25) by MN0PR12MB6368.namprd12.prod.outlook.com (2603:10b6:208:3d2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Fri, 23 Oct 2026 10:29:11 +0000 Received: from BY1PEPF0002696A.namprd05.prod.outlook.com (2603:10b6:510:325:cafe::44) by PH7PR17CA0059.outlook.office365.com (2603:10b6:510:325::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.19 via Frontend Transport; Fri, 23 Oct 2026 10:29:11 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BY1PEPF0002696A.mail.protection.outlook.com (10.167.244.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Fri, 23 Oct 2026 10:29:10 +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.53; Fri, 23 Oct 2026 05:29:10 -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.53 via Frontend Transport; Fri, 23 Oct 2026 05:29: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=pM7Oi2aUUA/SfTRd/S+GS2WbK2glG+LdynilJx6+1vjO1EkzmcNuGOsvdPgRwdDkA/5WOFS2cBcWt5DdK77Y87xjTnJQBDVCc7BRMh1KE0qvawgnaOmI0psLNb289IAlWDOTHP2ThTzeBd5NvfhdwNLBu2GuDou0nJ8/10yUGU7+5ioKKl4sXRp/t+Tc+5V89WFKsFZFp/7uVhrJKvycchYWSWkc1Nb+eogDJ7EZLs0a3Y7Ry+S/yNX26VQmY3o701Hma7wbSaUmc94JG5+NnD3Epo4kccvJ+t9FA7pG57KE5F6dfovmOvUhqDu0Ai1gCMaoN8xJd+YCDNNRL2AtVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z85FzhDw98EF2IONjo3MUPpsoTPX1b6G+PCnPwD5v3c=; b=N5XFEx3lT8z4nrWA0wNBy82Jg7fybIbKmZY6MilhcawjshLybtfYk8H4Q7UDH1MTHoyXkfz9p/EYJgKT0ZtR0VHHZBQXhpL+f1HB/BXH1azSU9ROzss+mwcn29R93VsRj1R4N55gAPh9neJo40sPxciprYgu3FR+4AxL36xbwEYib6MiBFU2cxlV7++tzPsGMB/cBX74zx+5u5MHdVXW5MDlXe+1k95irc24hwUEgzMCGTgPnSRpS22LFAUcjgZYs7PBwj2hZH8uElj3KYJnRkWn2FhcKBvKjeaJy0jDBY+00SupZOhNrczFlqf1/LUyFypL1Tj2XaN2VgkHi0QOnQ== 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=Z85FzhDw98EF2IONjo3MUPpsoTPX1b6G+PCnPwD5v3c=; b=BKQaw4tNaM/01agBqrDv6JonBANNrfkOicZrkuLQQ+jE7JcaG3aS6J3zWaxe5TLMAiz+Dpw65+cR7oY81S9jjFKe0gf2f3yNh70bVFSoTo1mSWodNKL1RvIKt7BA/cViSLhRnEoWXMCwqles6Jmah8GCAP/v6C4sWGqg1fU4F78= 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: <77c01e6e-779d-4a52-b206-681b5ec064ae@amd.com> Date: Fri, 23 Oct 2026 12:29:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] xen/arm: populate a default P2M pool for new domains To: Julian Vetter , CC: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <1792138386.8631fc262581453bbf619ec5b2062170.1a143c59b630008425@vates.tech> <1792138612.8631fc262581453bbf619ec5b2062170.1a143c90ffa0008425@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1792138612.8631fc262581453bbf619ec5b2062170.1a143c90ffa0008425@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PEPF0002696A:EE_|MN0PR12MB6368:EE_ X-MS-Office365-Filtering-Correlation-Id: f55d956d-b524-439f-dd24-08df30f07a0d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|82310400026|1800799024|36860700016|376014|261021121427099003|6133799003|18002099003|22082099003|261009223027099003|4143699003|11063799006|10067099003|261022105027099003|56012099006|261022075727099003; X-Microsoft-Antispam-Message-Info: UmI7Z7dVUrzPYkLJ8fddC2+JYQt9SaF3CXBE6wtOgaZBrTQjDTqh98HurMylmqedPrOo+aE0TYcqnr4/eQYvJbUi6KjJgh8OVws394D5QWRiVrsMid4LU670jOuB9VQGcPisxTB66cY1uNZjPb+3FoIy1FVVBbyPcGpNPeuUbv0N15Hhd7drz5LvtbFWoPbay3sGyx9irT4NmSBDJDAE5ol/bzj4PNT+qihP4BdwdSPzHceox83FA/oSwg20U8dA/3shiDyJVbykJ+dMFY1qJh9TjS4f84CxINqGW+XNYAbxKe3LM4T882d5L70F18gerhd+4Go4fGA/aRzze0OKOsOD9XWImpN1aI5j2LJfwSZx9zYaU4BEgWnLwFIWbT98vI3PIQQJXJE6vB3rmG5tD0uXcx0z/4IapoHUmbaS2hxx9M93msQB6gz12z+bAHRdbEMafRDfsRlZnf8GhuLP/S1v3PdMF2wqTwxmEV5UOFy+nJxsKOtnt4cr7L+f4jxd9sCZEVD0MSsXkddaa8Lx2sb49jx94QtaqBSas/YTXfkE/2Z0yEyDur9EZtdooE/YpJY5PQj5wgr5k2ttdpiHgr6eLr1ki4J4OjHEt7DttPlyxTgEffkgannSSQyY5hDYTKPKeTuVWbOTdxQ+7vB4EOTBa/CCLL5JzRFMx/u4g4BqNo9lb9L+pp/BzCYtktu1TKfp4xdzMJv3UmSCyu7a0Q== 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)(82310400026)(1800799024)(36860700016)(376014)(261021121427099003)(6133799003)(18002099003)(22082099003)(261009223027099003)(4143699003)(11063799006)(10067099003)(261022105027099003)(56012099006)(261022075727099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: acmlVEQ6ugnH1OsiO1EXQ0tMTnL79JtOQBHhFilz5soXxt5Wht0nx9X1AgwnOhUpMv7whjDsLhT/L0GDaZCe1P/5mf7W/SPZOuaUzncIwNUagC45fB2BWuLXSnY3qart5BcWbMjYmS/4rkNIjQpCRvTKaN9kCncownc1Cgq97Ga8OB8O9SEVs/G/W0r2nmTwz+C29eRAwfZTfdi0LG/oJwnghZDZjjpKnM1wG+2TNHv3dIaqGl2y9BEhSUMA3kNw6yYnJQZk9MlsiMcv3yFUM5orXO5XQrkCopLhrRTZkr3P5sH84IFv03XU1cR/pGuXqQ2hXA88GJYVd57O474eoPgZkt0C6BHadXMfxwH6gD3sG3aN7xwbvlDq7BidQtHigoqby4/DB3OwFUsAyOsLX3Ig9JAvjr5qW5JCkzL8ezoC1Fo3ElF+qIuDEmWoJ/NM X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 10:29:10.6934 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f55d956d-b524-439f-dd24-08df30f07a0d 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: BY1PEPF0002696A.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6368 X-purgate-ID: tlsNG-d62444/1792751356-BE07B757-99BA5A1D/0/0 X-purgate-type: clean X-purgate-size: 2592 On 16-Oct-26 10:16, Julian Vetter wrote: > Since commit 9c962e07fb ("xen/arm: Clean-up in p2m_init() and > p2m_final_teardown()"), ARM domains start with an empty P2M pool. So, > populating the physmap fails, as no page tables can be allocated until > the pool is sized by, e.g., the toolstack. The history on Arm I found is as follows: - no dedicated P2M pool for domains - cbea5a1149 adds a dedicated P2M pool for non-hw domains - c7cff11888 adds initial P2M pool due to GICv2 requirements - 9c962e07fb removes the above > > Restore the call to add a small default pool of 16 pages in p2m_init() > again, as before 9c962e07fb. The hardware domain is skipped, as it > doesn't allocate its P2M pages from the page pool. Also skip it if LLC > coloring is enabled. The colors are only configured after domain > creation, so the pool pages would be allocated with the default colors. This does not say anything about why we need to have a default pool. The cover letter you sent mentions that x86 does that but does not rationalize why. Also, why 16 and not any other number (previously on Arm it was 16 due to GICv2 worst-case). And if we really need to have a default pool, then shouldn't we just initialize it to the default set in dom0less case by domain_p2m_set_allocation() and in xl case by libxl__get_required_paging_memory()? ~Michal > > Signed-off-by: Julian Vetter > --- > xen/arch/arm/mmu/p2m.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c > index 2cf35d8a37..de8dd26a72 100644 > --- a/xen/arch/arm/mmu/p2m.c > +++ b/xen/arch/arm/mmu/p2m.c > @@ -3,6 +3,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -1541,6 +1542,21 @@ int p2m_init(struct domain *d) > if ( rc ) > return rc; > > + /* Populate 16 pages to the P2M pages pool here. > + * > + * Skip the hardware domain, which allocates its P2M pages from the heap, > + * and LLC colored setups, as the domain's colors are only configured after > + * domain creation. > + */ > + if ( !is_hardware_domain(d) && !llc_coloring_enabled ) > + { > + spin_lock(&d->arch.paging.lock); > + rc = p2m_set_allocation(d, 16, false); > + spin_unlock(&d->arch.paging.lock); > + if ( rc ) > + return rc; > + } > + > return 0; > } > From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:51:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:51:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459105.1671176 (Exim 4.92) (envelope-from ) id 1xKCrX-0002sP-Nm; Fri, 23 Oct 2026 10:51:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459105.1671176; Fri, 23 Oct 2026 10:51: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 1xKCrX-0002sI-KU; Fri, 23 Oct 2026 10:51:03 +0000 Received: by outflank-mailman (input) for mailman id 1459105; Fri, 23 Oct 2026 10:51:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKCrW-0002rq-0p for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:51:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKCrV-005Jxi-5d for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:51:01 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb3c05-8faa-0a2a0a5109dd-0a2a4501b008-20 for ; Fri, 23 Oct 2026 12:51:00 +0200 Received: from [40.93.194.21] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb3c13-5984-0a2a45010019-285dc215a7e8-4 for ; Fri, 23 Oct 2026 12:51:00 +0200 Received: from BN1PR14CA0024.namprd14.prod.outlook.com (2603:10b6:408:e3::29) by DM4PR12MB8497.namprd12.prod.outlook.com (2603:10b6:8:180::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 10:50:52 +0000 Received: from BN6PEPF0000006F.namprd03.prod.outlook.com (2603:10b6:408:e3:cafe::72) by BN1PR14CA0024.outlook.office365.com (2603:10b6:408:e3::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.19 via Frontend Transport; Fri, 23 Oct 2026 10:50:51 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN6PEPF0000006F.mail.protection.outlook.com (10.167.248.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Fri, 23 Oct 2026 10:50:51 +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.53; Fri, 23 Oct 2026 05:50:42 -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.53; Fri, 23 Oct 2026 05:50: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.53 via Frontend Transport; Fri, 23 Oct 2026 05:50:41 -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=PscDW/IjrTHDc0Cp8Cd0HXiWAvYeVVS8u8o8K3gqyl0uh7BKR8C8xOjodkXLvkqD3EhjJFtBINiDtyvzbiLvdUMhcyHraVTz8VVBfhWKb3aobVuv+ZQpt5SMLttZBm6A0VgQ1ukREByr+gAhyplZuSrUuUNKCuLhGwuLsrALniN+6orqlFR1qkGd5XzJW56qX7j+XMb2X8E3kZ4lyRR/CNCt1NWGkHNs6qJGWsvWF+TTVjUBO8QO7h1Q/zcsrBYWiOGDnBqb/AsCoPebhUx/ekIlqBkh2M5UFzs0iMiEG9JvSjx8yyBIE4s32MZG1olUTmGovD2TyhFIO6nBZalNMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=G7De5DrU5rp2otcZmYE96HsjyySabRs7G0qpdpG+urc=; b=CyOw1xHE0KGkHB3Ki4HdcWZOqhBTPa9hO2iZlLcz1X/Xej+m7YUDOmN9ivQqG5BFp+bkjvNJQDOq4fE0pDdSy16JRPDt510frFf7wprz10h+jZ/wVin2inleG+Cr/l325NxvE1DoMLhxNm1bYTxNyFSFgy2GH9oLWeAKRxUkH/ZdWM3da7TlERKQ/l6Fk2zq3zTzwAKSLw4kjofdo8Qie996Rt8G362RKS6obg03fvREPRq/xAn6jufDsLqZIe7B0B8ksbk13uQwWfeQYh61bY17/T/5ERuZgWhR+AV1dQS+gNdlZXWzjpZUAI2z+RX/NQ8ysTasJvfxqaIq7Y552g== 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=G7De5DrU5rp2otcZmYE96HsjyySabRs7G0qpdpG+urc=; b=SEsnxL3yV5Qc6mkYIu67Ytld3ciUJaXDsgL0ksPx/ngXs+TSzNdkEvURmuLBzKWvt1+9avL2ZjPRWmbu4P1Z/tjHRdMHrDGT7yktgOtV+LLEDo4qk7I9enISuhZp/kBFePebIEpZRFwjU7bhqQeXnydP75C+64juXhh3uA2EkOo= 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: <9ea319f7-ad39-4955-a284-9092b63767b3@amd.com> Date: Fri, 23 Oct 2026 12:50:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/4] xen/arm: its: initialize host LPI state before activating ITSes To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <0afac276107d8b2a170489950d75e611c69a599b.1790707009.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <0afac276107d8b2a170489950d75e611c69a599b.1790707009.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: BN6PEPF0000006F:EE_|DM4PR12MB8497:EE_ X-MS-Office365-Filtering-Correlation-Id: 7677b5b6-6af5-4f34-25af-08df30f38173 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|23010399003|376014|1800799024|6133799003|22082099003|10067099003|18002099003|3023799007|11063799006|56012099006|4143699003|261009223027099003|261022105027099003|261021121427099003; X-Microsoft-Antispam-Message-Info: QQGJ304u7EOeUTOyIIZy2fMKkKxLHLQhSa6EEKCFLqhHR37Sb7lKmD+ogi0SHAxXi6vPoIDd0n3u4zLM9YW6Ub6y21/9ouS/pel4Gxu2GYSxoPdbE3q2sj7aqjXsZMSnqJmKzFmZ+PiALlOC/GeKc/o6dmfQCbucJfoairiul1ZCCL7YK0Aq1sBunf4jnRjz0SLeJLnSGmX46o2pf1SLwHmzkHclJuLFPhYzBlK9rETWYGOsK9w9rgVzdeOP4qxLoszaDcZyzIeIQw9O2UWMIxsNfWadKIswuz7X5oD4Ij8UIrbz4KknuYwKib0UGh+zyOATfRUUmeFOEtalHf6A5BvWD3vzvbRDaZ2jzWiuxXT2O/SJRm1o2zRTXBrB5Oa1pNNDMts10ICGKWzmcZ4+PkDeoaf58STeAJ75RnQKdrBYEo8ObXoJ1CexI40y2mMjvZqHUHDFUyZ2OaYDFA/c8+8ji0KZEVdeo+MEynAtNw0YVyh9/zBAA42JXssVAkalSJ5Jp0VYlaBW7WYuSnop6DYVGKK21smA19w1nvMbj4Zj4ITc4ldhxCajRTwrYsS64kECxhzogNNSXp6veZVO3oPf1HxgVWrei4hIb77EHFYdmRlcw8ZIfTJPyKW5JHBolsGKi3gB6U/l8qMRY+s0X3wnJABpux4tB63ufU5H9zxMZLeQJxNCPmXgQq3/kgHbDCm8qFjCikFyUfQvNy2CLA== 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)(23010399003)(376014)(1800799024)(6133799003)(22082099003)(10067099003)(18002099003)(3023799007)(11063799006)(56012099006)(4143699003)(261009223027099003)(261022105027099003)(261021121427099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Pe3+QjjgYOHyVCBhwVtl3nuUhdm6EwA+HHkGDrFtvZJFsQtOl+WIK3m2ez3k7572giGvUK5qXbdpeNXbAIqhRDUQBk+thu6rhms+4fxbRYoS+8izqflEXkpE+PNzsI/htQkVd5HOvLT8iL4z2DyGXquS1eug4G1NUngNOUMdsMxjoAi7bmBsyUaF/Qf+Kpx5LUBZ4pkHij+14YENKObGPTX4LSml/MMaQD3BBpWKEGCKX8AHhWG95LHN6wkKZRYmktgAmgOJG9JfnMgqYsTvD56A0AcnaXOppIiPvexxW5LA+EjL3CEEw4sFvSHovjf/A0ktnTO/lDpvSxckATrLafmK49IllPZSQNooev+0GnfjigUqrwxylqNakIC6qpTl8BU9I9Ui7LeDEvNHzkxn1mbjjILT3RAvDioJMxKPvlrkWOOlnb1/SRxlBTZUsAb0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 10:50:51.6464 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7677b5b6-6af5-4f34-25af-08df30f38173 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: BN6PEPF0000006F.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8497 X-purgate-ID: tlsNG-d62444/1792752660-1EA66757-C5325051/0/0 X-purgate-type: clean X-purgate-size: 1169 On 29-Sep-26 21:02, Mykola Kvach wrote: > 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 The only caller of gicv3_lpi_init_host_lpis() is now in -its.c file, so we should drop the stub (can be done on commit). Other than that: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:51:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:51:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459111.1671186 (Exim 4.92) (envelope-from ) id 1xKCsM-0003Ig-Vk; Fri, 23 Oct 2026 10:51:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459111.1671186; Fri, 23 Oct 2026 10: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 1xKCsM-0003IZ-SG; Fri, 23 Oct 2026 10:51:54 +0000 Received: by outflank-mailman (input) for mailman id 1459111; Fri, 23 Oct 2026 10:51:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKCsL-0003IJ-7x for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:51:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKCsK-009pkX-Dr for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:51:52 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb3c3a-8faa-0a2a0a5109dd-0a2a45028090-24 for ; Fri, 23 Oct 2026 12:51:52 +0200 Received: from [40.107.209.10] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb3c46-6ca4-0a2a45020019-286bd10a5679-3 for ; Fri, 23 Oct 2026 12:51:51 +0200 Received: from BN9PR03CA0955.namprd03.prod.outlook.com (2603:10b6:408:108::30) by IA0PPFAF883AE17.namprd12.prod.outlook.com (2603:10b6:20f:fc04::be1) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.19; Fri, 23 Oct 2026 10:51:46 +0000 Received: from BN6PEPF00000073.namprd03.prod.outlook.com (2603:10b6:408:108:cafe::81) by BN9PR03CA0955.outlook.office365.com (2603:10b6:408:108::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Fri, 23 Oct 2026 10:51:46 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN6PEPF00000073.mail.protection.outlook.com (10.167.248.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Fri, 23 Oct 2026 10:51:46 +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.53; Fri, 23 Oct 2026 05:51:46 -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.53; Fri, 23 Oct 2026 05:51:45 -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.53 via Frontend Transport; Fri, 23 Oct 2026 05:51: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=fHDagjJxmbznCIZO3ZbPQRIe4/B9rM2roMwlYT+DzzFLkH0y6xooCuOVSiygVp1/80H/2Nm8IJw33HubYl7gfQp/Kl5TvzQRPaqAL+qL9s/M9AqUbqdDnZSzx9mNXRkda6jY8ytR5HoTmbN2F7UiX2PufgaMY9IsOlgjMqvh3x9abynEX/i8J0KVNCXYWSyaWZQo5jqZyFEXPi3fl1YqF3fH7jTpsiuC3uUXfK2lbzE0JUZG1NHSIbmkF6QDGw/3VsSba4a4s7H6NmvYf1hCxAbr7xcq94YRSGP6xYJPGbATivW1sjltVvnepaBmNwECEOhlnT7XAMpBH3qXzXBbaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lAiXEQCjExiPtPM1a9kg9wHyqKh1FfG7IwLrLQIB2zQ=; b=IzyT8+t7Q7/QSRLMMfO/mYTYi5WnHlslqBWYfk9uiMComzGamoFS2amLtsj6KheZFFdHIOcVoq8mRWHDTmKfnyx03S04sjAbq98v50yfoSdD0MUWteIupcuqM4Y8qBhCUSTqnEcXajn0pOac9F1DLJQ1dUwyGv+XoDN8blElDd6z4om6jmsQZySMH0bFprWCMbkz44k+s/6B5WZbxrY4/cGb1qXCZczjG2TNAL1re3PEcGCgir/ZkN1a0FF49BaADP6qi2iLREKaYiAskEGg/Lfx0X9XFNOlAtiymVSu1XNjNocId2Y1BIrR00MJDhpeKpIVbCj8mmBgn2t7FlvnRA== 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=lAiXEQCjExiPtPM1a9kg9wHyqKh1FfG7IwLrLQIB2zQ=; b=SKasQy6BA1QMCN2PuB0Vz4V+LfAvH85sApmfPPmQRJtBSJniIMYNkiaBgq/lBWCgRwZkynEhMtvlPIZP5buy9qMXmmAwrg0Y05j9nXvmoAXPSCLvm8dxrR1G2iT+DfTRJE3GHtDAqz8geqyB9aKT8hwLsURqfghUWmtlq3vLDEk= 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: <121e0d73-34f2-41ea-8535-c465933884dd@amd.com> Date: Fri, 23 Oct 2026 12:51:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] xen/arm: its: separate ITS and host LPI quirk scopes To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <8f586eb079dc00fb2f4612349bf55d84bf52d105.1790707009.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <8f586eb079dc00fb2f4612349bf55d84bf52d105.1790707009.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: BN6PEPF00000073:EE_|IA0PPFAF883AE17:EE_ X-MS-Office365-Filtering-Correlation-Id: 2f4603a6-e24f-42e5-aace-08df30f3a1fc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|82310400026|36860700016|10067099003|261022075727099003|3023799007|261021121427099003|11063799006|56012099006|4143699003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: Lj894qtMzAl2vnJnLHJu9hjvkGPftbeWIWC1q8yPIN49NMB6julgNKABCfSjTz0lKr2NepnZ9ZYD84kT2PPBLfG4cyqPfBuyf3tKMCXTOPW+lg7TFQjeKvhPgOfjm91q6UjXTKP6iTerr6J1heU8+CLkHs+noK8TSb1nxlOnLoq/lM39Qjc2OtviLgWhkX7oBKsqHHDSGU9Dtmni8nMduBRk3gmqHOz99YSM2xEkjs3TC4GjOvfJPoju4Ielyo35DpmEhZ1M/KFgOZYXn/K7SCLFE8k1aBZye5jMzoqxnzQAIHZe1eIxkZHTimU0lX+qedqcM/jHcjtvAKnjTGWwoSXFh4ANzDFiGb3Nb4wR5dnAuyauLLnv9YC62by4RKI5p2jMDlocCHxgfFQqum4XdU9soTUFNA+EWKr7hJKEeGxRvhmBGNIAE7Ma1Rq3wuTyK0RvbBf95v9c/kAWylXMgGU+6B4WDVyj6VjVA2aJ062YBisOIH2julv8084CLucL/L+P31IHajfcKgTmAUM3GBcgEjhhnm/QrpKbo23jkV4my+OKi3m36dqQrH5URqf8yJ3mG43m7rx6hzXSRvbzjwGDbhO03B3wGs4KqFTvhQz04yb7vZe2pfG1A2O5geHu6OVGs6FCyD/2Brf5BMro/qLLLNHoguL79MKAAxB7vj3byvt+LwDXyV8jwq0JWQB6U1O9osjtxmo/1Lj74p+E4g== 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)(1800799024)(376014)(82310400026)(36860700016)(10067099003)(261022075727099003)(3023799007)(261021121427099003)(11063799006)(56012099006)(4143699003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: KnUjdEYKR7Cj78Q1GBEcPa7QKrpXcHl47jeTFxpz8+FuoxVbmoxDDtlfb6hEmXIl71ipWdQlapbtO2ahm2MOd/UoT1oqp1ke7T+LIQiarJ0keYcDvsMflR/g7lMYMN8KlovGrEQ9RlL3tIQMlb3/7McMlbqgysmH01DTDji57ZEdo7hc8OFWC64Pyh365jGF2paPRWaTUXIbD6vNRgcqg5MZkq51Jw2qoavGytdNwWZPU9AFvoq6pRTLRkeZL9WBDY+QKX4zMuBMxNP2lAfgiv/PK5HL+ZKX8aeMRBzaeU5nQ9Wxbbm3Wq4TGhWK7n4gGsUtp6lXrwnq3HBMuzdbsK0kY/LoKRLEyCDG1AU8V4H6JvnWO3YGThsRGhseulOxlpCksXfafT/2KJD+P+Dex12Uk/+mIhBd8YBSD67vcIKmuZvqIvfC99zn7PqFBFuf X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 10:51:46.2383 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2f4603a6-e24f-42e5-aace-08df30f3a1fc 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: BN6PEPF00000073.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPFAF883AE17 X-purgate-ID: tlsNG-720697/1792752712-31BC82AC-CBA2F3F1/0/0 X-purgate-type: clean X-purgate-size: 1589 On 29-Sep-26 21:02, Mykola Kvach wrote: > 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 Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:52:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:52:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459113.1671194 (Exim 4.92) (envelope-from ) id 1xKCsg-0003fM-9D; Fri, 23 Oct 2026 10:52:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459113.1671194; Fri, 23 Oct 2026 10: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 1xKCsg-0003fC-65; Fri, 23 Oct 2026 10:52:14 +0000 Received: by outflank-mailman (input) for mailman id 1459113; Fri, 23 Oct 2026 10:52:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKCse-0003dR-V4 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:52:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKCse-009pnr-Bn for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:52:12 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb3c55-8faa-0a2a0a5109dd-0a2a450aa556-2 for ; Fri, 23 Oct 2026 12:52:12 +0200 Received: from [40.93.196.30] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb3c5a-f2d2-0a2a450a0019-285dc41ee379-3 for ; Fri, 23 Oct 2026 12:52:11 +0200 Received: from CH2PR19CA0003.namprd19.prod.outlook.com (2603:10b6:610:4d::13) by LV9PR12MB9808.namprd12.prod.outlook.com (2603:10b6:408:2e7::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Fri, 23 Oct 2026 10:52:07 +0000 Received: from CH3PEPF0000000C.namprd04.prod.outlook.com (2603:10b6:610:4d:cafe::3e) by CH2PR19CA0003.outlook.office365.com (2603:10b6:610:4d::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.19 via Frontend Transport; Fri, 23 Oct 2026 10:52:06 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH3PEPF0000000C.mail.protection.outlook.com (10.167.244.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Fri, 23 Oct 2026 10:52:06 +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.53; Fri, 23 Oct 2026 05:52:06 -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.53 via Frontend Transport; Fri, 23 Oct 2026 05:52:05 -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=R0n0V6UBnyPfz7FLbJsiJKHa5QiFsu9ZRkaof1sUfnPoioH8SpqPIexV2F6IKmvAmieIIl1C+Fqi7O6OobbpIzxEfwHNM2SBsXJZxMaIGIkKKyVUqNqDiD0Lu8O4IKNACOszRhGft6r9JQNSpYZRJZW1TVd0JU43YQF5Jdxw8ITWVM2Vhne6EROqVqrJwovXTQWWRWVVCBS999XgWHYritbNrr44d3ocl4MojEVo7uLrWATM8/wFd7wRDXz3R52/xiCN7WPvOsgLNaaNjYQJGMRmjEQ4MG5fKxeTiNoodYqfB1maKdFtUcoPtTJdBqKv82hhiLby94LiDSkpUhGviw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S24wAEEkFSNTXc6VFJq1FbrVnyrx2dW8ML5AM0H0y7s=; b=Zk41vkR2gYWXcFS9OIFsaZDWF7V9i8eSJoyMqno+IsMMRPeveHy/x4R0uHx+gB3LK7TO6n8C+CO3Mi0oGTxWxecHwvGt6NA3vhFKZAQMfbXc4D2M5BLdCJBPPnDydgX0IIywB68+Ig647Uzs+ltcP9kbCkGYzbkAb3Ux0vn4Pptq2Wyi6j7xhEt4jv5x8p8G60vM4lL/YOiSKrQdY3NO6JWZSEtbXr4JRVHCfteDhmRSij7uLUh/nQuBkJ+VgxFxI9Z88NqFlzvnHoBZTroghfyxwXrTQeamnlTGpjqi5i4eV7p/h7eyL/0AWdGFRpT5UqZmFT4dwDKD+hpEix5HSg== 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=S24wAEEkFSNTXc6VFJq1FbrVnyrx2dW8ML5AM0H0y7s=; b=vBrQDpBOcEtkkWsooUaiT/vxQ8rDx1QXMFuh97MvSV0zmbXIYnm8MQuAoyuwRqT2wCiIYLQrIPF/efN+Y5JWhVe4FQamRfJcWkCRu4c486n64WliyQH/Cx3IR+0oEqoNCNEYSRXGvBwL/k+senhnPDhc2UUFdve0Hbcneoo65gc= 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: Fri, 23 Oct 2026 12:52:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/4] xen/arm: its: refactor ITS quirk matching 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: CH3PEPF0000000C:EE_|LV9PR12MB9808:EE_ X-MS-Office365-Filtering-Correlation-Id: 1b148db4-a79e-4aa5-7778-08df30f3ae3c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|23010399003|376014|1800799024|261021121427099003|18002099003|10067099003|22082099003|4143699003|11063799006|261022105027099003|56012099006; X-Microsoft-Antispam-Message-Info: 3iGf2zLfY0elm73sPnVUTObRbr4X1b83mUIhYXF0vn9Ttl+9MNcXjcdOxPptF4uonoIu+j/+3GUklz/fD+KU4b4ru4o7Yk/jyrkcl/KduKooCtGvd8gWBHKTgdoIawPcjHH9Rk6hJRLajEyM0rxNJHFY0Q2beg/2T9BaSwMUAgWdxGXeIpOmUSiZ2Y8euqYVwlgXzmdVLx9K5w/4hPY5dAZC8Qfb8Lu3ds/JdtnoeBlzkT1mk9gn/Eg/kgrSfNAbpRPNugkFCfd8YXgeT+KBA7NeAfo94QiXLBl74hSCeOlP73DxpcY58y1NhmWVPF1UgqnFuaDlPddeiCFSvBGyd1hqREQGJ87xPDxzeLWUj434ofMiCV0BENnXIUsAeKK1qiDth9zHuebf5SCD25xgslGDUK8FQbDDI04lPNkMyq1V5AsqobE42Ne087E6G1vgFRQxJNR+AHHb4qYoQjeuvl737icJs1vr122HGYOB5C719fWrIlF1VhQA5RDRwV3/oEbavdK4GqRjWCNbhfjnw0YVhw0yBjIn1Bcm7cVjDi5+hAEtBq5JpmoS4DTAB36xDOv0M12LFxSPTdx/gW2vcDbNlV3kUZ5uqJ8w4D8kMcGAgGwgmdivtw2Jc1l7hwrkASZkaH7j5J6Iev2sambm3H06qrlcVQ0u+t/2miVwzZRBaWnB+vPi9aSAEmsJ0wAXz9n/+Xgv5w0QC/6ZxAU+NA== 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)(23010399003)(376014)(1800799024)(261021121427099003)(18002099003)(10067099003)(22082099003)(4143699003)(11063799006)(261022105027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: fBN3LED2TWfUAzVTnpTkQ6KkJHDCe0RX82CB2LlnA+GOFAv+N3VJHhemrCJ9AJBiBOE6buVKQa3sbKsLPCaypY8Uy17BS4zYX5wV+PrESIYobjHXiBzSVIjxw06UslYKBzCWVkNjleWPapXgu6Yi2Tqka0Z+dZ9fo5H7iMJcw6oZUgURhRqx817HNuHbQRVjW9eP/0ofNF3Foc5NeNlx6vacBC92lRc4/7g2NlR2XSD1wCeVQOGwm98X4ewMnvS5kTzDjDTWmoMYxGT/f3BtBx6wpKkpd3Bw8wYSss0vTdXHcKbDu9UPO5AF8R51IImqrsIaEpwdPriEW/L0sVp9bh8dj1ezrGQUh25Zn2wv9HXl3PVymWIEMCireBfBeZui3nlbiE16LUMPRN3QsETQ/1FPtgG/waBv+pkNdi0BPu/HyEmZZStrPeGV5wJ+taul X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 10:52:06.7619 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1b148db4-a79e-4aa5-7778-08df30f3ae3c 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: CH3PEPF0000000C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR12MB9808 X-purgate-ID: tlsNG-4011c0/1792752732-591C5CFC-8B52FC25/0/0 X-purgate-type: clean X-purgate-size: 1362 On 29-Sep-26 21:02, Mykola Kvach wrote: > 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. Use BUG_ON() if a non-sentinel > entry has no matcher or the IIDR matcher receives no data. A broken > entry must stop Xen in both debug and release builds, as skipping a > required workaround could cause a failure later. 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 Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 23 10:52:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 10:52:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459119.1671202 (Exim 4.92) (envelope-from ) id 1xKCt2-0004AE-Gg; Fri, 23 Oct 2026 10:52:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459119.1671202; Fri, 23 Oct 2026 10:52: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 1xKCt2-0004A7-Dl; Fri, 23 Oct 2026 10:52:36 +0000 Received: by outflank-mailman (input) for mailman id 1459119; Fri, 23 Oct 2026 10:52:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKCt0-00048O-T6 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:52:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKCt0-005KPL-9p for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:52:34 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb3c6a-bab6-0a2a0a5309dd-0a2a45069462-26 for ; Fri, 23 Oct 2026 12:52:33 +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 6adb3c70-195a-0a2a45060019-34652e3371f3-3 for ; Fri, 23 Oct 2026 12:52:33 +0200 Received: from CH2PR14CA0024.namprd14.prod.outlook.com (2603:10b6:610:60::34) by SJ2PR12MB8718.namprd12.prod.outlook.com (2603:10b6:a03:540::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Fri, 23 Oct 2026 10:52:28 +0000 Received: from CH3PEPF0000000A.namprd04.prod.outlook.com (2603:10b6:610:60:cafe::34) by CH2PR14CA0024.outlook.office365.com (2603:10b6:610:60::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.16 via Frontend Transport; Fri, 23 Oct 2026 10:52:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH3PEPF0000000A.mail.protection.outlook.com (10.167.244.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Fri, 23 Oct 2026 10:52:28 +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.53; Fri, 23 Oct 2026 05:52:27 -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.53 via Frontend Transport; Fri, 23 Oct 2026 05:52: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=wLtp25724RDupFnBEsAKypbrjEA/pXhoVRUlHD3pUJBkRSF118uY689/3cLJtO/TRjICOqVsuNCUKVWjd5SuUx6jlDdP1IIJlRfKg2Hnx2QUy4Es1EdKixO6MjqirLqroQMq1eZZ/0JXLQU6WisxVHBUS+B5G29Qsbgw5YXGR5/JAj5+wEJMbxjVRi5NaJQd7WwmkEzx7B1TGWivHt6QjCAdi1Cb0GMingorNMGpol6lNN6KkgBL5Z2XiIhSDLpql0f6TaJeoWVIbTaKzLVIHJ5ZJhCb9A0eo/OzZZdkUjwqM5szABYZ55umMvJXM7G5TiZAWq5KUS+fnavJJjkS4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qcl2BdQpoSnalRbRZ10lzxEsEcEU0/DYvXRdD0A2BB4=; b=Joxi2wKegYdC5Swi+zj2WqxBtPy2SCPZfjMBRFLcH7/mo7p3belQuUam7O4LEOTAvKUWUrDxbbtwaplaJ30cXzqakVGzuXRbDckLH5c7RmtfnScx/4stYVoJ2qV4OPrjZkCcInWclFBs9klw8+38QbZ4twvIaW4X1NsF1zpoAiTG84rKJTmYVtp3eKjQwJKR2yF4Q7FzDkXkNQZYYtxFAzt+lDFIrUh/ZD4klddw9lw9Judag8JLk1euMpmoaRwXvD+GLlF7LnBKVwzR+wbC4amZLpEXKTKRBAqAz4W5u5ASTlejXyjdcOpy+UWikCIQ+8UBCx/LyYzfHaKmbKDhmg== 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=Qcl2BdQpoSnalRbRZ10lzxEsEcEU0/DYvXRdD0A2BB4=; b=104zltc9pQetc9ew9yIV53KnobZSKENVpXw5ZVCLFJX09VGXeLH8hgCSVKUKns/9vk8BT+uSp1jI8wBzrn7D+5TPRcDql0+fncvl9926NVExa04PhGarqQmkOKrsvaIvmnvVwBiEP3kwTXnDcBWF/IV56aHe7M/Li8K49A3Twf4= 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: <16371f23-f892-4a4a-a612-d3cca0247f9c@amd.com> Date: Fri, 23 Oct 2026 12:52:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes 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: CH3PEPF0000000A:EE_|SJ2PR12MB8718:EE_ X-MS-Office365-Filtering-Correlation-Id: 4a7cc58d-adb4-4f37-70d6-08df30f3bb09 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|36860700016|82310400026|23010399003|56012099006|4143699003|11063799006|261009223027099003|261021121427099003|10067099003|22082099003|18002099003|261022075727099003; X-Microsoft-Antispam-Message-Info: uOfp+Pz2UfihNYMnQjNSwRUOZ0cgVWd84K1zhfTtEHQcgYe68vjkhhbMKqK5ND9vu/c3XS8jevnFwVC090WEBwGiHe8lhgFXHKatG1UkDGWleA9TdpRX3zU3uHV2WJ+IQ5XqGV2UmNGeTPZWYli4SZ9qOUxDHBzTEQJDpLu9NtuXP3elzvg5FiL4vYsR6aXUObJSJOqY9UmFARoqzBSXK3jakDB9desyZdVMIv3bGitdiMSa0oWgqwDxe1DhdPQoULAzFAzH/bapIHVYjj/lh5EFn8r/kSIWneYE4yls5hEogyHZaG0l61nOjaPwRpkyTyp62Izwvawd6BbLFf3pPdIgUz//G3mwECrt+Sv0gyqix1jl3QFoxRdy0qGX0yEuYomDGT9ZE4jWMs2/vf50Vm6U4g0OqwDuF4W24SqDdyavcQhEXL4jCviCsHi3EEx1so1thAQwgt78ZqOUEtvTNtzvR8IGliv9ksKupCC9rjGPYPLGEMWgUOB1t9DrB6i0nDvv538cR6F0Jcn/pNjpzZrXxD75qip3OvJdGDKPfP/zTeAlrm1dLFlh7N+H3/GWI2jsTTuC7jVOl2I3WkneKH8HdAxQoVuTJfZEjO1/CDlKSUk6so2QhPbjBpbCwnbjIcIhqBXY6U1yuPN1D56fwYW2Umo7htkE6LjtS+CKbUy8sr/L0mCeeo5Eyamn/5NrzIyJzx8eT7czB6cOD6Bwgw== 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)(36860700016)(82310400026)(23010399003)(56012099006)(4143699003)(11063799006)(261009223027099003)(261021121427099003)(10067099003)(22082099003)(18002099003)(261022075727099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: e2yr/CAtF+iKH7owF8HiMowQgseDlibp/H0ECgIiMCHoZO6bgh2h4FELDAnpPxmouRairia5gKDZquBoJHY+Kr3eINkq0GRPMDJ8KI+vCDsZAQDYcb2qm/IwILMvYOPzsnNHxHv8w8yNkNXFwM3jG/I490NY1knz4WjzP/aCfScQMsIKfYOZx9PiwrCmABwaSkZYwKDrNXX66kvLi1Ukq4GU6jay0rpE1/3LR3MxolGhdTiyDHPefZmadeEweXFIouqCOtGx6epZQPkCtMeAJi8YV6ycmZbVcrT8/E5UKAqLAmyb2kaJ6JQ24wVTih2H8OUJoD43JXXprZR7cr08V1LGwv25f53I389JYObCMgvH+4SKs5XFZ1yflF7baDMZ1Ok/86ovYC6e9qP6fNi1ucn3hgCywuZ/A68BJN09rGKVii1tfGjYPZZUj6sDCB5D X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 10:52:28.2640 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4a7cc58d-adb4-4f37-70d6-08df30f3bb09 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: CH3PEPF0000000A.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8718 X-purgate-ID: tlsNG-16d1c6/1792752753-F7CCD77B-9ECFC86F/0/0 X-purgate-type: clean X-purgate-size: 1193 On 29-Sep-26 21:02, Mykola Kvach wrote: > 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 > Reviewed-by: Volodymyr Babchuk ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 23 11:09:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 11:09:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459143.1671212 (Exim 4.92) (envelope-from ) id 1xKD9Z-0006GV-V4; Fri, 23 Oct 2026 11:09:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459143.1671212; Fri, 23 Oct 2026 11:09: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 1xKD9Z-0006GO-RY; Fri, 23 Oct 2026 11:09:41 +0000 Received: by outflank-mailman (input) for mailman id 1459143; Fri, 23 Oct 2026 11:09:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xKD9Y-0006GI-OA for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 11:09:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKD9Y-00CRBX-4p for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:09:40 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb4073-2eae-0a2a0a5409dd-0a2a450cb4a4-4 for ; Fri, 23 Oct 2026 13:09:40 +0200 Received: from [52.101.66.135] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb4073-f479-0a2a450c0019-346542873e44-3 for ; Fri, 23 Oct 2026 13:09:40 +0200 Received: from AM0PR03MB6050.eurprd03.prod.outlook.com (2603:10a6:208:15d::10) by DU4PR03MB11142.eurprd03.prod.outlook.com (2603:10a6:10:5f2::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Fri, 23 Oct 2026 11:09:35 +0000 Received: from AM0PR03MB6050.eurprd03.prod.outlook.com ([fe80::657b:d5bb:c261:f9d]) by AM0PR03MB6050.eurprd03.prod.outlook.com ([fe80::657b:d5bb:c261:f9d%4]) with mapi id 15.21.0522.017; Fri, 23 Oct 2026 11:09: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=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=APyohjcKqvvADs9DGVC4QdDf6m8ImmZFG/yUqb1kU521IAkDCna6W75mP5Wi9sqIwp8aQiekFf4qcQIDC6ytEcF1kq+Z8CnNfWDOYSbel4E+SXJ5KlZ94STdgyiWppOw4mtnPBN/dPv9cRGwEWH5vDUat4y5lMOmUCZU8B+mR/+OxC03+vc/zzC+52V1b2Mt85l48oHcjHu/cNavr4w6BcSwlFeb5540H9z76xRQ09Z4nGkiQVUx+p13QcD375vyu+bhcdZtHORq3sjn/SN2f2qfXms1nOYC4cJ0Pv+asjO2vTZ1SzBin1Ka4vY2ov3zgReD1z5kuOVulyunIoqhRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7x1wOfUxu+7NF8wJ9lY1NYo9Inzl+n5Rp4VMchpDEsY=; b=NsFKtVBJj0RImqEJiIzospBAwLhDi50ZfgeAkoiLR8zkZie9+Duy6+Iy+ZAGFrGUq4e3Ywmbh6qE4YzJstwCM2XZQ3UW8aDlOVzkVs4UPT9EmIzOeQdkyB1AgGJBwMLY1Y91t+oAV6Oj+OB+TXMzFpU0hInZ+BiSM354Du9ZTcwv8NZHUHhodEpegT//NSuize343RZiMGVJj5w9o1CtTyYeDvZsa/i1tzwT8x9Fm0uorpxeeAIFUwUgE4CbxyyPMHDRv/3TqliVPtA9sMrSkUk6g0AicRf9NzwzlGpbS8TCGwArAIs/oQSf5CrP3Rx7uq2A7Hke7RhO5kSRJWRmaw== 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=7x1wOfUxu+7NF8wJ9lY1NYo9Inzl+n5Rp4VMchpDEsY=; b=ApcVoBL9ve6gl5wHzF94u8Pe3J5mxa6lu+XjYKr9m4tk7Mx9ZMQXXxrMSf2TigxTRKcJOGFnvOmTAV3fLKD9ulMgIXcjgc3zNFD70mjD6JWGQuj6bxqFtg5e8i6UYzA0pbFBU0GHjailevD6l9P1zcdTirTGsNtBRqPGSvX/TR9GP072EbUHXSuMOMdkZvDK7QrnOEikV0Q2qGm+dLTvhSPOl/9ZLDCim836/wAg0fLZ4zRlhtX5WYesZ1gXv1QTn5Ju/4mxHvgkOis41pm2s5XMrSZQFKviurl2zS5Dxri9VtcVd/J9YA/Ccf1UFMT8q3eZhSh4dH2Ncz3oyPNmMg== 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" , Alejandro Vallejo , Andrew Cooper , Jan Beulich Subject: [PATCH v5] common: dom0less-bindings: introduce XSM labels Thread-Topic: [PATCH v5] common: dom0less-bindings: introduce XSM labels Thread-Index: AQHdYt78vs0mWAZx8Uyiwl8OuJrbTw== Date: Fri, 23 Oct 2026 11:09:34 +0000 Message-ID: <20261023110933.2325318-1-Sergiy_Kibrik@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: AM0PR03MB6050:EE_|DU4PR03MB11142:EE_ x-ms-office365-filtering-correlation-id: c5a75acf-6475-4a86-ceb9-08df30f61eb6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|261021121427099003|6133799003|18002099003|10067099003|261021135927099003|11063799006|261009223027099003|261022105027099003|56012099006|261022075727099003|38070700021; x-microsoft-antispam-message-info: ljx4nsfRYorwNECGY8BJgzurZ6IYnOrlliSkct3i/cfGxjOUVMQDSY7ZIXx5nnw9/4qpGGxSsRBpvCoEtX6u6aFl/W52/Te1PFCAW0Jub1onRWRQ8XgkunyLb+mzv+QCh3uoHmrk4HhLMfyrsmFT1e6bsy4ECdzDQZj7uNl+tGtXvfZuoa2KoxTBIK+jgPBkCjCS4cyNUg9N9cFtly4NXFGHLDnwHF0WLix4q+Ku6cElbnub6sDXGVJ4kP0qbxnyJTfT4W+pjQwdZ+EiV9OdHBfzlGiFwJwYhf82ke3TU1Zk0Rm7HMY2uT1JsqPACAiuHplErYATdTI3qAyvHZPx1Alt/wlwBWd97OmPddmFdrEv6ZflSObEhywVjlmGOMQ+CdaqLAwLIrqTfjUXst6GSMrBLADWJVYzatVx8jl7kcWVITep2p9C67L6ASW7oMjDDDcGgXLMe9xbExLZXL10sKGqKM62bXStys50v/DRp85c3YFCxy7Lg6dXRLGnvkuc1fwhaba/1XdBA5UHcq+nOgpAWbgHH2/Ux5fippbzPpoGmcjDvi9+ZAxvMsbhLi4O39sdOqpNYJVQ/M6GJtoXZUuHSmgHXW6iQkXq2hrjgatMh85/POpqM0j/FG2SarC0Hg1Gn2DmPHbbicI0PBpiipbnHZASRdsEte3VtYGKJTbMqWgQnsjaFdH1HYUrRD0jY9WXzA2OFwKSZgB3nuHDeevbtr3AiDfJckfAoxOiFdM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR03MB6050.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(261021121427099003)(6133799003)(18002099003)(10067099003)(261021135927099003)(11063799006)(261009223027099003)(261022105027099003)(56012099006)(261022075727099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QXVWSTd5Rm1rOW45UTRyZ21WemJoaHlZR1pNUWs1aUt3djRaUGRNUWFFcWZI?= =?utf-8?B?UjNRYUMvMVFZVEZiL096OXZVUWt2encybEt2L3J3MWZaeXhodVhPQWlqenFI?= =?utf-8?B?WHB2cWx4ME81Y3B4L21OLyt5V1NySGlqdjZqT2VqNndSTC9JK3pEb3ZHYmhK?= =?utf-8?B?S3c5RWFscTNwa3FXcFdwbWJWUjQwZWxUS3V4NkFNejJqTGdEOVF0ajV1Y2V6?= =?utf-8?B?dnRHQktxWDdyM3IzWW5weFBDYytjR2QxcUNJMzZKUXZRS3E3UGNmS1VDK0dl?= =?utf-8?B?TDRUTnFNWnNMOUtYQlRQeU51NHBpWEI3Q21pOXV3emJTUWh1Z1AwM1ZJWVdt?= =?utf-8?B?b3BrOERUOFJ6M3EyamZiNmpYdjFBcEFONHRkL2dMYWZnNTltdGZ5ckV5NWJT?= =?utf-8?B?Mk1wQjRUWEhaSDY3cGxqck9PSkZyK0NwcGlGYVV5YkttSmNHY3RlOUpQMXlS?= =?utf-8?B?b2JnZjlaaDRycTFORVhuczBNNWNQdTluNTFnODQwK0p6QzdKM2lMTk5vckY2?= =?utf-8?B?eVVmL3Bjei9RL21LMklqTVQ2SEZYQU1lUllFMmZzK1Z3Q1pJMWVueUtkMEdh?= =?utf-8?B?dmlHVS9iVXB2TGFUQTN2RFlTcDlKTi8vS2JGTVVEc1d2QnB0MlRtODBUQzVx?= =?utf-8?B?a3AyaGxXSm5hR1ZtRmdIZzFTdmZMamcwOVFMM1duTGtOeG05RkpyVnFUNXAw?= =?utf-8?B?K2RuVmppamZjc044aTRBNTNtV25FaDY5eFVQV1RpQnJiOTVLOVVTYWhXbmVN?= =?utf-8?B?NWdJaWNkQ3p6Rzk0UXBnazRrWnNzUXZlNWZDOTZGMXY0bGFKMmc4MFhMK3JU?= =?utf-8?B?VnRmOVJuWkJybWpuVDA2bEl0dkRORXhmTkk2ZGxJYkN6NUN4Sm12TWFkaG5t?= =?utf-8?B?K1NwOStEU0xGakJLdE9YZWZIZkwwWEV0VG9nWW1tV1U5dit0TVhVR1VtV3Jn?= =?utf-8?B?MERmMU9URGtwZUVtUzlxYXlNOUk5VUgzb2EyZDkxc2MzSm1PSEk1RGdlSlVZ?= =?utf-8?B?T1o1L3pUWkUyeFdvMkxKeHIzMEliREFjQ2dwaUw0QVVzRjhWUlNTRHRoalZp?= =?utf-8?B?dVYrOG5iTnlUTkNrcXdjM05uakQwR3p1VDJ4MFg0VVQ5WkJkeXhTRVhFcXdz?= =?utf-8?B?cTlpRXhqekJBTE9DRC8zZ00vVElGZ1EwQXE3R3FyOEhaQStKSXdCRnA0UXhB?= =?utf-8?B?KytCZ0xZY1czV3pmSjNhZGh1RFVjTG9iaTc0K0ZDV1M0aExaSTJ3SlJ1andq?= =?utf-8?B?MnYwaytMYy94a3BlLzBxc3lXSmxEN3k1S0RhOXJVaHhsdi9Xa29sRGF3REpY?= =?utf-8?B?SWFiWjluZi9lTWpYYzdSbzhlUmlRWFg3UFE5TzVRUUg4alExcFdQQXEzOWpw?= =?utf-8?B?WUl5SnUwRzYxWFEwNlo5aEE1SlM4MERjNit0WWljaWc4VnIxQjMvdVhjMFA0?= =?utf-8?B?bDZFRFhERmFPSzl5cXI3TWduR1NyQUhIaGVzNHFzTkp4eE9xNUV3NXVYZDkz?= =?utf-8?B?RUlDdkFXcUN2aGZMY0dEdWpwNlBmdUJSK2FzMk9jU252c3oxb1pkSnVEYTVn?= =?utf-8?B?bHNYa3VjYnlTUEt3T2V5Y00wWjVqbDNaem5icjFVM254SjhBUEtHRmN0c3FJ?= =?utf-8?B?WnhoOHFPc2kwQ3NzbGVNdGhTcGsyYjkvWG9yWTdGN0ZJWjRWbVZrR1JYb1Rp?= =?utf-8?B?Q24wbC9Qa1F6RE1xUUl3M2poSVlEVmZSWGtPQ3cxdGluYmhlMEpRT0JBZVc0?= =?utf-8?B?VU5FQVVVSEYvY3NvY2wxVS9TbTJhOTZaclZWVjJ5ZUhtaGhuSVJpZjFWVjNa?= =?utf-8?B?dEVQNzRIa1I5ZytWVy9SNDlNK29rSllsVlRacW9DanlpTys3SVlRUDV2M2tj?= =?utf-8?B?akJqMzk0RXBzaXhWSDJKOUNHdVlnKzBrcVplVEdZZUNzT3RnUXhrYjliaXU5?= =?utf-8?B?ZmYzNGFzU1JxMUtRQW5GT1BIVFY3UkttQUJPekJIV3lmV016MjhuaDhlYVFv?= =?utf-8?B?WUFZNXF2YldlMmNrc2E2Y2JwOHNwU3JlODYzU2F0NlBEUmhlc0NaZnBJdS9O?= =?utf-8?B?c2wzT1dIVU9KRmlKQjZaNGdtYnBpZVM1dGdacG1OU0Fmdk1UdDVlZGlnZ0xO?= =?utf-8?B?elJWazhBd1hXM254VHl4OVYyUXByYzRRM0piRU1GQkVpOXhBbWZoT0Z2bWFy?= =?utf-8?B?aEM0ellTNExmSHpUTk9JMkFaR3N3S2gxRXhRWU9icWRkazgyRld3b2ZjZTgr?= =?utf-8?B?SndiT3lWc3JEcHBaMHhhUnkyZExqdWJQVUQyUlRvMXZLMzhCTDN6ZW5OMzhX?= =?utf-8?B?bFIxOEVsMCtZSEpSaExZSHNxbGlDYm5xR3ZBY09nQUVodFBhZXFzYnliYkJi?= =?utf-8?Q?4W4+mzuuYlef2Szc=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: AM0PR03MB6050.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5a75acf-6475-4a86-ceb9-08df30f61eb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2026 11:09:34.5145 (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: kn4TyVZLuk6MbNT1LraWB6/RbFh8mi4ALFSo9NehbO63bgVDOOrbgEJ+zcv2GgyFlxFE2LCZr8NZwXiYcB1bZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB11142 X-purgate-ID: tlsNG-d25034/1792753780-5113AA5B-A5F387CF/10/78276251493 X-purgate-type: spam X-purgate-size: 8064 QWRkICJzZWNsYWJlbCIgcHJvcGVydHkgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHNlY3VyaXR5IGxh YmVsIGZvciBhIGRvbWFpbg0Kd2hlbiBYU00gRmxhc2sgaXMgZW5hYmxlZCwgc2ltaWxhciB0byB4 bCBjb25maWd1cmF0aW9uIGZpbGVzLg0KDQpDdXJyZW50bHkgZ3Vlc3QgZG9tYWluIGNhbid0IGJl IGNyZWF0ZWQgYnkgWGVuIGluIGRvbTBsZXNzIGNvbmZpZ3VyYXRpb24gd2hlbg0KRmxhc2sgaXMg ZW5hYmxlZCwgYXMgZG9tYWluIGlzIGFzc2lnbmVkICJzeXN0ZW1fdTpzeXN0ZW1fcjp1bmxhYmVs ZWRfdCIgbGFiZWwNCmJ5IGRlZmF1bHQsIHdoaWNoIEZsYXNrIGRlbmllcyB0byBjcmVhdGUgYWNj b3JkaW5nIHRvIGN1cnJlbnQgcG9saWN5Lg0KDQpCZWNhdXNlIGNvZGUgZnJvbSBvdXRzaWRlIG9m IGZsYXNrIGNhbid0IGRpcmVjdGx5IGV4ZWN1dGUgaXRzIGludGVybmFsIEFQSQ0KYSBuZXcgWFNN IGhvb2sgbG9va3VwX3NpZCgpIGludHJvZHVjZWQgYXMgcGFydCBvZiBYU00gQVBJIGV4cG9zZWQN CnRvIHJlc3Qgb2YgWGVuLg0KDQpTaWduZWQtb2ZmLWJ5OiBTZXJnaXkgS2licmlrIDxTZXJnaXlf S2licmlrQGVwYW0uY29tPg0KUmV2aWV3ZWQtYnk6IEFsZWphbmRybyBWYWxsZWpvIDxhbGVqYW5k cm8uZ2FyY2lhdmFsbGVqb0BhbWQuY29tPg0KUmV2aWV3ZWQtYnk6IE1pY2hhbCBPcnplbCA8bWlj aGFsLm9yemVsQGFtZC5jb20+DQotLS0NCkNDOiBEYW5pZWwgUC4gU21pdGggPGRwc21pdGhAYXBl cnR1c3NvbHV0aW9ucy5jb20+DQpDQzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0 cml4LmNvbT4NCkNDOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQotLS0NCmNoYW5n ZXMgaW4gdjU6DQogLSBwcmludCBlcnJvciBjb2RlIGluIHBhbmljIG1lc3NhZ2UNCiAtIHJldHVy biAtRU9QTk9UU1VQUCBpbnN0ZWFkIG9mIC1FUEVSTSBpbiB4c21fbG9va3VwX3NpZCgpIHN0dWIg ZnVuY3Rpb24NCiAtIGFkZHJlc3Mgb3RoZXIgcmV2aWV3IGNvbW1lbnRzICYgYWRkIHRhZ3MNCmNo YW5nZXMgaW4gdjQ6DQogLSBpbnRyb2R1Y2UgWFNNIGhvb2sgYGxvb2t1cF9zaWRgDQogLSBhdCBT SUQgbG9va3VwIHJldHVybiBlcnJvciBpZiBzZWN1cml0eSBzZXJ2ZXIgbm90IGluaXRpYWxpemVk DQogLSBkb2N1bWVudCBwYW5pYyBpZiBEVFMgcHJvcGVydHkgaXMgdXNlZCBhbmQgRkxBU0sgZGlz YWJsZWQNCiAtIHBlciBNaWNoYWwncyByZXF1ZXN0IHBhbmljIGlmIEZMQVNLIGRpc2FibGVkIGlz IGxlZnQgdW5jaGFuZ2VkDQotLS0NCiBkb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3Rpbmcu dHh0ICAgICAgfCAgOCArKysrKysrKw0KIHhlbi9jb21tb24vZGV2aWNlLXRyZWUvZG9tMGxlc3Mt YmluZGluZ3MuYyB8IDEyICsrKysrKysrKysrKw0KIHhlbi9pbmNsdWRlL3hzbS9kdW1teS5oICAg ICAgICAgICAgICAgICAgICB8ICA4ICsrKysrKysrDQogeGVuL2luY2x1ZGUveHNtL2hvb2tzLmgg ICAgICAgICAgICAgICAgICAgIHwgIDIgKysNCiB4ZW4veHNtL2ZsYXNrL2hvb2tzLmMgICAgICAg ICAgICAgICAgICAgICAgfCAgOCArKysrKysrKw0KIDUgZmlsZXMgY2hhbmdlZCwgMzggaW5zZXJ0 aW9ucygrKQ0KDQpkaWZmIC0tZ2l0IGEvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5n LnR4dCBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQNCmluZGV4IDFkZmRm ZjBlNGYuLjdlZGNlOTY0MmUgMTAwNjQ0DQotLS0gYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVl L2Jvb3RpbmcudHh0DQorKysgYi9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0 DQpAQCAtMzQ4LDYgKzM0OCwxMiBAQCB3aXRoIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoNCiAg ICAgbm90IHBhc3NlZC4gVGhpcyBjb25maWd1cmF0aW9uIHJlcXVpcmVzIHN0YXRpYyBhbGxvY2F0 aW9uICh4ZW4sc3RhdGljLW1lbSkNCiAgICAgYW5kIGRpcmVjdCBtYXBwaW5nIChkaXJlY3QtbWFw KS4NCiANCistIHNlY2xhYmVsDQorDQorICAgIEEgc3RyaW5nIHByb3BlcnR5IHNwZWNpZnlpbmcg YW4gWFNNIHNlY3VyaXR5IGxhYmVsIHRvIHRoaXMgZG9tYWluLiBEb21haW5zDQorICAgIHdpbGwg YmUgY2xhc3NpZmllZCAidW5sYWJlbGVkIiBpZiB0aGlzIHByb3BlcnR5IGlzIG5vdCBzcGVjaWZp ZWQuDQorICAgIE5vdGU6IGJvb3Qgd2lsbCBmYWlsIGlmIHRoaXMgcHJvcGVydHkgaXMgcHJlc2Vu dCBidXQgRkxBU0sgaXMgZGlzYWJsZWQuDQorDQogVW5kZXIgdGhlICJ4ZW4sZG9tYWluIiBjb21w YXRpYmxlIG5vZGUsIG9uZSBvciBtb3JlIHN1Yi1ub2RlcyBhcmUgcHJlc2VudA0KIGZvciB0aGUg RG9tVSBrZXJuZWwgYW5kIHJhbWRpc2suDQogDQpAQCAtNDI1LDYgKzQzMSw3IEBAIGNob3NlbiB7 DQogICAgICAgICBtZW1vcnkgPSA8MCAxMzEwNzI+Ow0KICAgICAgICAgY3B1cyA9IDwyPjsNCiAg ICAgICAgIHZwbDAxMTsNCisgICAgICAgIHNlY2xhYmVsID0gInN5c3RlbV91OnN5c3RlbV9yOmRv bVVfdCI7DQogDQogICAgICAgICB2Y3B1MCB7DQogICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJ4 ZW4sdmNwdSI7DQpAQCAtNDU2LDYgKzQ2Myw3IEBAIGNob3NlbiB7DQogICAgICAgICAjc2l6ZS1j ZWxscyA9IDwweDE+Ow0KICAgICAgICAgbWVtb3J5ID0gPDAgNjU1MzY+Ow0KICAgICAgICAgY3B1 cyA9IDwxPjsNCisgICAgICAgIHNlY2xhYmVsID0gInN5c3RlbV91OnN5c3RlbV9yOmRvbVVfdCI7 DQogDQogICAgICAgICBtb2R1bGVAMHg0YzAwMDAwMCB7DQogICAgICAgICAgICAgY29tcGF0aWJs ZSA9ICJtdWx0aWJvb3Qsa2VybmVsIiwgIm11bHRpYm9vdCxtb2R1bGUiOw0KZGlmZiAtLWdpdCBh L3hlbi9jb21tb24vZGV2aWNlLXRyZWUvZG9tMGxlc3MtYmluZGluZ3MuYyBiL3hlbi9jb21tb24v ZGV2aWNlLXRyZWUvZG9tMGxlc3MtYmluZGluZ3MuYw0KaW5kZXggNDFkNzJkMGQ1OC4uMmQwNjFl NWJhNiAxMDA2NDQNCi0tLSBhL3hlbi9jb21tb24vZGV2aWNlLXRyZWUvZG9tMGxlc3MtYmluZGlu Z3MuYw0KKysrIGIveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1iaW5kaW5ncy5jDQpA QCAtMTEsNiArMTEsOCBAQA0KICNpbmNsdWRlIDxwdWJsaWMvYm9vdGZkdC5oPg0KICNpbmNsdWRl IDxwdWJsaWMvZG9tY3RsLmg+DQogDQorI2luY2x1ZGUgPHhzbS94c20uaD4NCisNCiBpbnQgX19p bml0IHBhcnNlX2RvbTBsZXNzX25vZGUoc3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgYm9vdF9kb21haW4gKmJkKQ0KIHsN CkBAIC0yMSw2ICsyMyw3IEBAIGludCBfX2luaXQgcGFyc2VfZG9tMGxlc3Nfbm9kZShzdHJ1Y3Qg ZHRfZGV2aWNlX25vZGUgKm5vZGUsDQogICAgIGJvb2wgaGFzX2R0YiA9IGZhbHNlOw0KICAgICBi b29sIGlvbW11ID0gZmFsc2U7DQogICAgIGNvbnN0IGNoYXIgKmRvbTBsZXNzX2lvbW11ID0gTlVM TDsNCisgICAgY29uc3QgY2hhciAqeHNtbGFiZWw7DQogDQogICAgIGlmICggIWR0X2RldmljZV9p c19jb21wYXRpYmxlKG5vZGUsICJ4ZW4sZG9tYWluIikgKQ0KICAgICAgICAgcmV0dXJuIC1FTk9F TlQ7DQpAQCAtMTQxLDUgKzE0NCwxNCBAQCBpbnQgX19pbml0IHBhcnNlX2RvbTBsZXNzX25vZGUo c3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlLA0KICAgICAgICAgcGFuaWMoIidsbGMtY29sb3Jz JyBmb3VuZCwgYnV0IExMQyBjb2xvcmluZyBpcyBkaXNhYmxlZFxuIik7DQogI2VuZGlmDQogDQor ICAgIGlmICggIWR0X3Byb3BlcnR5X3JlYWRfc3RyaW5nKG5vZGUsICJzZWNsYWJlbCIsICZ4c21s YWJlbCkgKQ0KKyAgICB7DQorICAgICAgICBpbnQgcmMgPSB4c21fbG9va3VwX3NpZChYU01fSE9P SywgeHNtbGFiZWwsIHN0cmxlbih4c21sYWJlbCksDQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZF9jZmctPnNzaWRyZWYpOw0KKyAgICAgICAgaWYgKCByYyApDQorICAgICAgICAg ICAgcGFuaWMoIkludmFsaWQgc2VjdXJpdHkgY29udGV4dCBmb3IgZG9tYWluOiAlcyAoJWQpXG4i LA0KKyAgICAgICAgICAgICAgICAgIHhzbWxhYmVsLCByYyk7DQorICAgIH0NCisNCiAgICAgcmV0 dXJuIGFyY2hfcGFyc2VfZG9tMGxlc3Nfbm9kZShub2RlLCBiZCk7DQogfQ0KZGlmZiAtLWdpdCBh L3hlbi9pbmNsdWRlL3hzbS9kdW1teS5oIGIveGVuL2luY2x1ZGUveHNtL2R1bW15LmgNCmluZGV4 IDYzMzE4NTlhZmEuLjdhMDVkMjA3OGMgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS94c20vZHVt bXkuaA0KKysrIGIveGVuL2luY2x1ZGUveHNtL2R1bW15LmgNCkBAIC04MjMsNCArODIzLDEyIEBA IHN0YXRpYyBYU01fSU5MSU5FIGludCB4c21fZG9tYWluX3Jlc291cmNlX21hcCgNCiAgICAgcmV0 dXJuIHhzbV9kZWZhdWx0X2FjdGlvbihhY3Rpb24sIGN1cnJlbnQtPmRvbWFpbiwgZCk7DQogfQ0K IA0KK3N0YXRpYyBYU01fSU5MSU5FIGludCB4c21fbG9va3VwX3NpZCgNCisgICAgWFNNX0RFRkFV TFRfQVJHIGNvbnN0IGNoYXIgKmN0eCwgdWludDMyX3QgbGVuLCB1aW50MzJfdCAqc2lkKQ0KK3sN CisgICAgWFNNX0FTU0VSVF9BQ1RJT04oWFNNX0hPT0spOw0KKyAgICAvKiBkdW1teSBwb2xpY3kg aGFzIG5vIHNlY3VyaXR5IGNvbnRleHRzICovDQorICAgIHJldHVybiAtRU9QTk9UU1VQUDsNCit9 DQorDQogI2VuZGlmIC8qIF9fWEVOX1hTTV9EVU1NWV9IX18gKi8NCmRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS94c20vaG9va3MuaCBiL3hlbi9pbmNsdWRlL3hzbS9ob29rcy5oDQppbmRleCBhMzMx ZjVmMGU1Li4zYzFiZWYzMDUzIDEwMDY0NA0KLS0tIGEveGVuL2luY2x1ZGUveHNtL2hvb2tzLmgN CisrKyBiL3hlbi9pbmNsdWRlL3hzbS9ob29rcy5oDQpAQCAtMTY5LDYgKzE2OSw4IEBAIFhTTV9I T09LKGludCwgYXJnb19yZWdpc3Rlcl9hbnlfc291cmNlLCBjb25zdCBzdHJ1Y3QgZG9tYWluICop DQogWFNNX0hPT0soaW50LCBhcmdvX3NlbmQsIGNvbnN0IHN0cnVjdCBkb21haW4gKiwgY29uc3Qg c3RydWN0IGRvbWFpbiAqKQ0KICNlbmRpZg0KIA0KK1hTTV9IT09LKGludCwgbG9va3VwX3NpZCwg Y29uc3QgY2hhciAqLCB1aW50MzJfdCwgdWludDMyX3QgKikNCisNCiAjdW5kZWYgWFNNX0hPT0sw DQogI3VuZGVmIFhTTV9IT09LMQ0KICN1bmRlZiBYU01fSE9PSzINCmRpZmYgLS1naXQgYS94ZW4v eHNtL2ZsYXNrL2hvb2tzLmMgYi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMNCmluZGV4IGQ2NWJhMGFl YWUuLjc0MTk2OWMwNjQgMTAwNjQ0DQotLS0gYS94ZW4veHNtL2ZsYXNrL2hvb2tzLmMNCisrKyBi L3hlbi94c20vZmxhc2svaG9va3MuYw0KQEAgLTE5NDksNiArMTk0OSwxNCBAQCBzdGF0aWMgaW50 IGNmX2NoZWNrIGZsYXNrX2dldF9kb21haW5fc3RhdGUoc3RydWN0IGRvbWFpbiAqZCkNCiAgICAg cmV0dXJuIGN1cnJlbnRfaGFzX3Blcm0oZCwgU0VDQ0xBU1NfRE9NQUlOMiwgRE9NQUlOMl9fR0VU X0RPTUFJTl9TVEFURSk7DQogfQ0KIA0KK3N0YXRpYyBpbnQgZmxhc2tfbG9va3VwX3NpZChjb25z dCBjaGFyICpjdHgsIHVpbnQzMl90IGN0eF9sZW4sIHVpbnQzMl90ICpzaWQpDQorew0KKyAgICBp ZiAoICFzc19pbml0aWFsaXplZCApDQorICAgICAgICByZXR1cm4gLUVBR0FJTjsNCisNCisgICAg cmV0dXJuIHNlY3VyaXR5X2NvbnRleHRfdG9fc2lkKGN0eCwgY3R4X2xlbiwgc2lkKTsNCit9DQor DQogc3RhdGljIGNvbnN0IHN0cnVjdCB4c21fb3BzIF9faW5pdGNvbnN0X2NmX2Nsb2JiZXIgZmxh c2tfb3BzID0gew0KICAgICAuc2V0X3N5c3RlbV9hY3RpdmUgPSBmbGFza19zZXRfc3lzdGVtX2Fj dGl2ZSwNCiAgICAgLnNlY3VyaXR5X2RvbWFpbmluZm8gPSBmbGFza19zZWN1cml0eV9kb21haW5p bmZvLA0KLS0gDQoyLjQzLjANCg== From xen-devel-bounces@lists.xenproject.org Fri Oct 23 11:10:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 11:10:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459153.1671220 (Exim 4.92) (envelope-from ) id 1xKDAK-0007jT-8d; Fri, 23 Oct 2026 11:10:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459153.1671220; Fri, 23 Oct 2026 11: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 1xKDAK-0007jM-5s; Fri, 23 Oct 2026 11:10:28 +0000 Received: by outflank-mailman (input) for mailman id 1459153; Fri, 23 Oct 2026 11:10:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKDAI-0007jG-Dv for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 11:10:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKDAH-00854m-JS for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:10:25 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb4099-bab6-0a2a0a5309dd-0a2a4502a36e-18 for ; Fri, 23 Oct 2026 13:10:24 +0200 Received: from [52.101.228.116] (helo=OS0P286CU011.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb409d-6ca4-0a2a45020019-3465e4747673-3 for ; Fri, 23 Oct 2026 13:10:23 +0200 Received: from TY7P286MB7234.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:363::12) by TY6P286MB7599.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:345::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Fri, 23 Oct 2026 11:10:19 +0000 Received: from TY7P286MB7234.JPNP286.PROD.OUTLOOK.COM ([fe80::9caa:1ff:d16c:e15f]) by TY7P286MB7234.JPNP286.PROD.OUTLOOK.COM ([fe80::9caa:1ff:d16c:e15f%6]) with mapi id 15.21.0546.017; Fri, 23 Oct 2026 11:10: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=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=Ouy8gZoMoYaVI+w2+QmZJoNjN+2LC7/EaSo/cZcS/jFYTZJmU3dY2VA6O4dxXaVIxGzzHdXTrScMQ23dh2YaRdcGZpjq7V+icw1EYGrVBT99a7cS9VLNQfoexs7Ao4kJ3hX1DaoVDre5uK6J1bdzISyuiJ7ijW0vtEyoJ6y6TjQDAofhaHHq9+3QgCz5pckFrVdNdQBPewKXqsE3VMHl85May8kP1sCWmTpcKruHIJZp0OUmdYC2WqP4D37ZQ3t7qZ+gAr9HiuFaVGwFEBsnbuaPkIMoDQxzPuvTj7Rk8C8rbbWe2Qf8FSqXqIAnQoTQISQtZtK9bCRqVkUH/M2m0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=x2AP9Dkl/sAM7dAAKIN7a5X8tS4AK4BR1ofX0yvkCAU=; b=yDyylg13LnYBitBQkT9j3eE5T9OmR4k0NS55K9A6l60CFPdC7vodOSbKp+INKErUnGBjogloZku3y8Gj2wp4M8vZUkeE0oPKQkV7JZMatgZKhJszEvA2nmDvhat9LpUoms4eLvI+PQWNKHOx7IfBsOu2NZYsR0aEbQIWso8T3lnvT6dBn/uGleWsjyz4+sz4cyVou9+puFCmsOi/NSCr84lE6yiOs2HJ6fPH/xBHnYUQC9lm64mbtiV2q3dmd0P2biyI+FyikcYAupfgtmEtOUwhWRMFcTddTBKUXbBEhd0HxLC+ABzH14c385nzsq5CfgDC366pBLrKzO9G4jnlwQ== 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=x2AP9Dkl/sAM7dAAKIN7a5X8tS4AK4BR1ofX0yvkCAU=; b=wdJAOQYzcEsZXCiEc5jHUkmCb/rfsIsZLUapzH7U1zRWDN6OtBXTpGGdPqL0TrMH2JLD79UTNPmmWxsuO+K/aVB4S4uibFJYmnTm6c5w5/1u0J2+ZF3MDjZl8lpX3xMg4SKcSEunkbw+jVVrneVZKTlMcd9hA6S9mKG6uiD5mZw= Authentication-Results: mx.microsoft.com 1; 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, Hirokazu Takahashi , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH] xen/arm: Fix sibling mask setup to only include online CPUs Date: Fri, 23 Oct 2026 20:09:25 +0900 Message-ID: <20261023110925.128195-1-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYWP286CA0007.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:178::15) To TY7P286MB7234.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:363::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY7P286MB7234:EE_|TY6P286MB7599:EE_ X-MS-Office365-Filtering-Correlation-Id: d45a9d6d-1c0a-4bbe-6339-08df30f63936 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|10070799003|1800799024|376014|366016|56012099006|261021135927099003|261021123027099003|10067099003|261021121427099003|18002099003|261022105027099003|261022075727099003; X-Microsoft-Antispam-Message-Info: naIB461FeClNNO+6dYewrmwv51WQ2ThfCpzWQfXKitxOYqsP1trcrHVRTt4qef5ywslLCx7IyqxUDzzoW9YG+6R9UH3k7zjyxKn1Av8H+4YF4r/ez+K+ANhtYVTHh3lu1EQQimWMbdPb8oNzBlyGhu6YGgiFlwGAdy0BZPhTST1IObnqxTEUfoJFVsNg6n7hHleaftkBV9unj1MDSK8qmTcsuOaESJYd3+jl6SK/9GgFdYUPuegsCIh7lQ/CvIWc66D6iWUiTZkOlcDFv8ySVE6SmXFgKzMFf92l+myNZFyTKpsix99rGVx5fo1kZNK71FZg9cuYsiyTvzN1/O7AV9P5S9zuXJXg29ohrtWA49/D1ny+xilYC5gMEUFg8A2GIp9divm1ygqnDwzXBgRZzkQY5Inx6mpiDQu2igefOLScM8emdKQi/dA/uhpjOzhmXHRHNMI4IdXKRlW//pwIV+yWz6YWd0DOOpG5HeaKK59iRQywT+A4Li4Q9wzzn6THcfHeyNrjPqyRlTZiQ03m4ga/gMLoPBr3zNIEfWVaCffvOpLQmIDZLbCpMf/GyvRz/AYrh0exl5lMhSf599HrtfzFpsokZj2LNRTSBxa+j/WhSE4X4seY/y/yfs93c0P5MSyEwfuY/7BqJk87yxNXk1iIiNCgsuNlenEIDpPEr7M= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY7P286MB7234.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(10070799003)(1800799024)(376014)(366016)(56012099006)(261021135927099003)(261021123027099003)(10067099003)(261021121427099003)(18002099003)(261022105027099003)(261022075727099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?20dXwNvZXgaj4lKGlue6sDT1yulTUHxQN3mO6IwT/d+m9CoGGpmEph1Kk7dx?= =?us-ascii?Q?V/mh+/zumjPlQlZbvh5nRSBtYjdDn5wh4KCsP8gPwBWB7X5NDOdvXTcGec86?= =?us-ascii?Q?Kqy3huVOMr1UTdOqI6JtFaPNoaR1Yj9PsFZvmxzxVjtkPMEue7I6WkpmZ55+?= =?us-ascii?Q?E2vMbQ073C3rCCh5GqEDPOJWMGr7yj4ms2v0Ud8cw2g9mjY6L7AGeJw6dgJ7?= =?us-ascii?Q?Sd5Hd/7MCdfyHKHjmRpZrSGONtAxSznmFZVRdQ0pJNdqcZwGiwn/1AifBU3Q?= =?us-ascii?Q?9XABSK6FJG0X81qMeVQuQ7ps8yuRr0xfMNyoulxWuXLxIWzdZDYeidLp/N4v?= =?us-ascii?Q?YTURZHi3NokscfLkQA4uKVbyVSYwq/CRdDRQaLZ64XxNz9VMEUS4Sxd7ZyZR?= =?us-ascii?Q?HfhCEGPa0skSXdbss6iDkvXoNe11XIreK9T5PvcY9Ksp6wYCceJ/9vYx2rP8?= =?us-ascii?Q?/whz95ml+U0dZP2Ed9HcdUNL3a1P8e+uezQeA65P09hCSQ90wTPWy248Q3Rv?= =?us-ascii?Q?eRGCTjNUuXlbEg0f8TNEyCCd7Y5cZPF44hYORZwQhbQs3GHPx3vyTGL+9Pra?= =?us-ascii?Q?ImfqEs0/bvAeqAq862cbQnMnvNJJOxIWdvb8STKms2VF58IaKt2FwCQLJ6kl?= =?us-ascii?Q?0TK1ki/zUzuMARP6tLq6nTemCQlVEyRe1nqrCZdkzTlOjDT4Bwo/2OTDyhG6?= =?us-ascii?Q?1hypI48XjwsF++bHzOVRsPRZyo19C/B4di3ZQxc3JRsTKWQt1R716utfHQ6/?= =?us-ascii?Q?9eom42ApFvkX/7097N37VkP/DyHQ3qls+N7g9lJ9QVHEmAzpCxxcKXmN0uIk?= =?us-ascii?Q?P9KaPyenUsZQBVvLlPsq8nxZJnsBI/w4zWTk0LXuNZZo26FunI1NDp6/jnkB?= =?us-ascii?Q?5kfSbZsiMNlunOL9QBiF5+vSl9PUa6jm2nqEMtxUCCFMGsed/TJdGGaOtZNT?= =?us-ascii?Q?JPN8i/6Bx3li/3tv1jERZg6cmXqxxRkG/MHUgPpJ22+2f/Du1YO/r7MCIjcg?= =?us-ascii?Q?BDAutsZIDb+sGPy5G6cbIuZEOb/ZKIgpXqzKcLpbwPibzSsOR/CU1fY/dhBf?= =?us-ascii?Q?PKIzedfkZwEQ4Lo3OAMZoLsfeFSvUciH3+v3YIq377OTKANpUHzRvkqJ4W5s?= =?us-ascii?Q?XFunjpf8AeZl1QpU0PNc37LVz4IIUoe/P6W/dO47UyrZbIZo34xC1vdUXrEq?= =?us-ascii?Q?++dF5LAy13/7HpqLbEE3qocNLO0iQQHWEJotVshvV682EM2zUAK9LQBcLNAF?= =?us-ascii?Q?58r35BRRPtzyrO9TutqQBjW+kkjZJ7fAyF2FCRevYRUD+1nKyB8n+dsUihtd?= =?us-ascii?Q?ayH1WcTISP52PvO8/ol/35YdEeQn0Ct3pphIYYo9yS+X0xosslt3hgCoUdz0?= =?us-ascii?Q?/I1gH+8+AyIIP0sXUTNjAbKYj+Jh48RD2br8eMCtJOgDzkugmzroILbXd+1n?= =?us-ascii?Q?Yvz8gayKp2MX4rFSocMY8WXpbAY7iZHkikC/ONqqs7kOgthpMuytcdBKs4wd?= =?us-ascii?Q?qMfIS2rSnxZFv8aEgRsOxldXlEXMq1/dm28emni89FO0i285jSfbfxNhl9/E?= =?us-ascii?Q?T4IS7x7B17tCQjg/UdmalRX9Y+4QOcnXLB6m0Ef4YMsaWFLQCg/h9X+V4JFD?= =?us-ascii?Q?rzb3TwCmMg1PuWYIQRLgSxMU0tHKgu/1G/dF9LF9+1RCpKKQaH8gXsse4JFY?= =?us-ascii?Q?sl/ixXC76Rx8XIzBXYZB0WmchQ7VbmLm4jEs4gStqnAAzwGMqb2/wIus56bm?= =?us-ascii?Q?GItD3gay22M7kwoY2pVscJl2yLj/fNb4Ydvc1Xj2kPeJB2isObqMo5bhp8an?= X-MS-Exchange-AntiSpam-MessageData-1: K8EICsTHgnmjzw== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d45a9d6d-1c0a-4bbe-6339-08df30f63936 X-MS-Exchange-CrossTenant-AuthSource: TY7P286MB7234.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 11:10:19.0840 (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: QCUEdpRNXDFX/vxn24z1qVFVdF/Cb1+V5Cn/8tfN9AJvC8RhPpwxJABAhllIvpTulGOwZJf0eZlvbqAVxqoOaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY6P286MB7599 X-purgate-ID: tlsNG-720697/1792753824-F20A82AC-B92E8ADB/0/0 X-purgate-type: clean X-purgate-size: 2011 Populate the CPU sibling map only with CPUs that are brought online. Currently, all CPUs in cpu_possible_map are added, which leaves CPUs that failed to boot in the sibling masks and may lead the scheduler to make incorrect decisions. Fixes: 701190abb3d5 ("xen/arm: Set correct per-cpu cpu_core_mask") Signed-off-by: Hirokazu Takahashi --- xen/arch/arm/smpboot.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 8c9072f3c1..2d01896cf0 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -91,15 +91,24 @@ static int setup_cpu_sibling_map(int cpu) !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) ) return -ENOMEM; + return 0; +} + +static void init_cpu_sibling_map(int cpu) +{ + unsigned int sibling; + /* * 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). + * are supposed to belong to the same socket. */ cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu)); - cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_possible_map); + cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_online_map); + cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu)); - return 0; + for_each_online_cpu(sibling) + cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, sibling)); } static void remove_cpu_sibling_map(int cpu) @@ -314,6 +323,7 @@ smp_prepare_cpus(void) if ( rc ) panic("Unable to allocate CPU sibling/core maps\n"); + init_cpu_sibling_map(0); } /* Boot the current CPU */ @@ -385,6 +395,8 @@ void asmlinkage noreturn start_secondary(void) set_current(idle_vcpu[cpuid]); + init_cpu_sibling_map(cpuid); + /* Run local notifiers */ notify_cpu_starting(cpuid); /* -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 12:56:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 12:56:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459235.1671229 (Exim 4.92) (envelope-from ) id 1xKEod-0003W2-IU; Fri, 23 Oct 2026 12:56:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459235.1671229; Fri, 23 Oct 2026 12:56: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 1xKEod-0003Vv-FX; Fri, 23 Oct 2026 12:56:11 +0000 Received: by outflank-mailman (input) for mailman id 1459235; Fri, 23 Oct 2026 12:56:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKEob-0003Vp-EF for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:56:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKEoa-00EM6L-Mr for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 14:56:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb5956-8faa-0a2a0a5109dd-0a2a4502a15c-18 for ; Fri, 23 Oct 2026 14:56: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 6adb5967-6ca4-0a2a45020019-b9ff1c2284d1-3 for ; Fri, 23 Oct 2026 14:56: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 1a168d535ab000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Oct 2026 12:56:05 +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 E71A982A2E; Fri, 23 Oct 2026 14:56: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=ZLWcUEBEofWWRS9WLLImboQAyObHzTFKKSQIHkkOuRE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=bu2xfvtCeDfYqBDr9sMZipwQWzEUjTV1ZX73qXBrZMM1wc2eCV7mgMcr9SllcTCgb88QDFv7+ V0PCRx/MOn4OwHZ3rTLUYGTkCoeItbFfiTMoHK78Z/E+CmfaV4b91mg6Rfaxfx3c6b/z9XCDdGB GDj+1yVw0pQzU76UmaqU8az9r+ln8B+/kpU0ZzvPq+lGgrX9ulcwGp2WYNbS0877FsVuYK8uFwL V64pdIDDNJJZcvqEKN0x3LbPWdOsDQIcCXnnHiO3havlLM49te8r46kemf4BfmWOKV5P0EO1vnh XLi51eZweyxNiS3If6hfSpbdLBzJ8POeUqAPgdJm3ILg== X-Zone-Loop: be2c76e1fb2a453991b5adf3bbc31cf14b4ea2c95aa3 x-campaign-type: default x-transaction-id: f321dc66-ee84-429c-b791-bc7e52416d0b x-swg-uid: 01-2c519718-70c5-473a-b614-20adb0191076 X-Mailer: Sweego Message-ID: <1792760165.8631fc262581453bbf619ec5b2062170.1a168d535ab000f79f@vates.tech> x-swg-bid: 1792760165.8631fc262581453bbf619ec5b2062170.1a168d535ab000f79f 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 v3 29/39] xen/riscv: prepare 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: <7f00946a6b1b67e79f94e3c665f8f0ce9d5d0e5a.1790779209.git.oleksii.kurochko@gmail.com> References: <7f00946a6b1b67e79f94e3c665f8f0ce9d5d0e5a.1790779209.git.oleksii.kurochko@gmail.com> Date: Fri, 23 Oct 2026 14:55:57 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792760159; l=4718; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=7vLr5WKKYQLUMiTtOiKwXp5adFr+HrjqZkyMG0wyIVM=; b=eF7gZrQogzCzp8f69qMg3dNBuqpX8NaDke2iQQyL2LyPiAP4nxYknq6nP2M/KZL1xpzAWyLqo 9y0aJ+5A2JxDw2/O/akfnwbKNtjJNhRaW5GTk9cRE61mPMkpzqufGMB 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: 1792760165149 X-purgate-ID: tlsNG-720697/1792760168-F0AA52AC-B296FFDC/0/0 X-purgate-type: clean X-purgate-size: 4718 > [ ... 64 lines skipped ... ] > diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c > index e31c9c2d24..229ab4b867 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 Nit: Why xen/sched.h? The stub doesn't dereference v, and asm/aia.h already forward-declares struct vcpu. If it stays: sched < sections, so it goes one line up. > [ ... 30 lines skipped ... ] > +#define imsic_vs_csr_write(c, v) \ > +do { \ > + csr_write(CSR_VSISELECT, c); \ > + csr_write(CSR_VSIREG, v); \ > +} while (0) > + > +/* > + * Leaf macros for the switchcase expansion pyramid below: > + * imsic_switchcase_break(ireg, op, v) - emit "case ireg: op(ireg, v); break" > + */ > +#define imsic_switchcase_break(ireg, op, v) \ > + case ireg: \ > + op(ireg, v); \ > + break > + > +/* > + * Generic switchcase expansion pyramid. > + * F is the per-operation leaf macro, ireg is the base register index. > + * Extra args (e.g. an operation and/or a value) are forwarded to F via > + * __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(); > + break; > + } > +} > + What does the switch buy? ireg only ends up as the value written to vsiselect, not as a CSR number, so it doesn't need to be a compile-time constant. imsic_vs_csr_write(ireg, val) does the same, without the 128 case labels and the macro pyramid. If there's a reason, it wants stating in a comment; otherwise please drop the pyramid (an ASSERT() on the range can stay if you want one). Typo (only if the macros stay): "Leaf macros" - there's only one here. And `case ireg:` / `op(ireg, v)` as well as c and v in imsic_vs_csr_write() want parenthesizing (MISRA 20.7). > [ ... 67 lines skipped ... ] > +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 */ Typo: s/a IMSIC/an IMSIC/ > [ ... 31 lines skipped ... ] > void imsic_migrate_vcpu(struct vcpu *v) > { > + struct imsic_vsfile_data vsfile_data = { > + .nr_eix = imsic_cfg.nr_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 > @@ -703,5 +849,18 @@ void imsic_migrate_vcpu(struct vcpu *v) > if ( v->arch.last_cpu == CPU_NONE ) > return; > > + /* > + * At this point, all interrupt producers are still using the old IMSIC > + * VS-file. > + */ > + > + vsfile_data.hgei = vgein_assign(v); > + > + /* We don't support SW interrupt files at the moment. */ > + BUG_ON(!vsfile_data.hgei); > + > + /* Zero-out new IMSIC VS-file */ > + imsic_call_on_cpu(v->processor, imsic_vsfile_local_clear, &vsfile_data); Nit: The comment restates the call; drop it. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 23 13:16:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 13:16:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459251.1671238 (Exim 4.92) (envelope-from ) id 1xKF85-0006dm-36; Fri, 23 Oct 2026 13:16:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459251.1671238; Fri, 23 Oct 2026 13:16: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 1xKF85-0006df-0M; Fri, 23 Oct 2026 13:16:17 +0000 Received: by outflank-mailman (input) for mailman id 1459251; Fri, 23 Oct 2026 13:16:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKF83-0006dZ-2r for xen-devel@lists.xen.org; Fri, 23 Oct 2026 13:16:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKF82-00AFrE-7B for xen-devel@lists.xen.org; Fri, 23 Oct 2026 15:16:14 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb5e18-2eae-0a2a0a5409dd-0a2a4503e772-22 for ; Fri, 23 Oct 2026 15:16:14 +0200 Received: from [52.101.52.47] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb5e1c-fae8-0a2a45030019-3465342fd122-3 for ; Fri, 23 Oct 2026 15:16:13 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN8PR03MB4932.namprd03.prod.outlook.com (2603:10b6:408:7c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.19; Fri, 23 Oct 2026 13:14: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%4]) with mapi id 15.21.0546.017; Fri, 23 Oct 2026 13:14: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=WOHS1ngNCy/6rNKKhFzvQxwMjmbyjKMS4Qgf6xjbdHk1MEN1Dii6xS2SZ1ihpOAQPNYoDfJYPNZzUaQa7/gWGZKquS4JvUygjp1mWEIXJbdcqYFvNpMRjh1cDYE/XgPILyUJDLiIZYvfhd6Qe9C+97TNcSg+ekeshFpKzHWe7HQRPdZS2wwDaURw5m36in2DY7hU1XpW1US7Q6ENN+FUwO+E5+knZ6moLX9ubD0qbweIiaOXIimZZauSMrGUrsZgMfzgY9J2ZbuUR7OIqtyaLZckLcQHBy8/VtnNpvdHf0NI08Iz+7MxkpQ6OGZqjkybJmQnYWiLXq//J+1PgxNE+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=nZHdye5F6y7DiYUJRfyFI2Ga+u4H2/fgm/+sThwYkB0=; b=yN4v6g2IwovMp6eZ+CYLf7xrCzdF5dHsZt4QUDfWBlHNfcbODT3QTlqmm2k9z1t7AJtmDQqIXzfeEajRqUNLZULSPBqEFyyKGbPwyV+AQAu62SG93BNKPQvm/SAtdP2/bYMDHV1yifoBs99jzF7D1Gfzq8CDwGlNxjUx4HEvcIUzqik3KbpNgjn3UYi4IdOK5FkN3hk+zXAJAqRT7Kz1Wwzm83JYICxCwdK1ao9VJSh7ZUOLey9tMODwY3EV5mU6dbbTCtE9evZKcbRoZ+iwqpqyyptnvLLS/Nwq9F8mROtpZ1SAgiYSUuw6O2hwVpP84BNHuZQgUeeGy1XaqU9n1w== 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=nZHdye5F6y7DiYUJRfyFI2Ga+u4H2/fgm/+sThwYkB0=; b=apEpCqQcwLAZ7eTDaYzFtctSNLnjuZuHeIu89ruN5FYOhJRexAgBQfNp4hMY4kZuQ6OjH+KJJs15Sc9h8+vV/AVq1E9FvLTEIJ6QPZINloeWmVI05ZYZl7IIS0lCoDfCvGlZCnCwZRlu5o2D9XYbLahJTyBj5cmzrEdduRH3qZc= 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, 23 Oct 2026 14:14:00 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Soham Dandapat Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Peter Deggendorfer , xen-devel@lists.xen.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: LO2P265CA0503.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::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_|BN8PR03MB4932:EE_ X-MS-Office365-Filtering-Correlation-Id: 2607fbf8-191e-4f9c-5c2d-08df31078340 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|261009223027099003|261021135927099003|261021123027099003|261022105027099003|261022075727099003|261021121427099003|10067099003|56012099006|6133799003|18002099003|22082099003|5023799004|11063799006; X-Microsoft-Antispam-Message-Info: hhzDmzqyRPn/FwDpQhJXqfnEOJ5HOf3pcWPNqtEFduZ/azXJ3PRPbLmH5SRahBWn9ahF6XwXBuLF5dXlgz7GHK20m3+r1I0hp5DUNsjLxV2M/240PBBnMKMS2G+L311CFQREOgb5bjRr3uWRuFhs7IOzhxMW7n4GVA658b1FKtm8h2c0o8XgekkFPVgMA64cfvwOIEEL4uqp+1L0h27eX4u6FLm7PT/Jrzzz8lU7YrEew4c1VveDp3X9g7NMl0mwjQuV1DjU9fkJufjDTTIoQ1Ktez2uX6xM72OSvGKIX3JBYnQrFnhC6TzV5soTHSmOtBxHppPrPoljsKotWe1KV1cNSyAv038SB0P3acStMIy9/BIScyyk+NFsQ8D0I3kwrWtTCU3UjQduhCyeKVCxgjuIqh/FNK7lfLaz29z+fhvDSnYvQinjCNiqAuD2xhVh1XDjXsCZ4cnyIATJUmw7DWWL7bI/6qDG006fEM2ZB3SqVCNfMyMregTicOf3ehqnLJtZOsKOxjLOxnPXUN3RN3M50NSjhT9wawyStbchLCG3wxoUj3PEvDpBfPUJNH113y94+PDbK+EJGEQtElqvYaJvbObsqNBmZiklBXxOqHQ= 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)(261009223027099003)(261021135927099003)(261021123027099003)(261022105027099003)(261022075727099003)(261021121427099003)(10067099003)(56012099006)(6133799003)(18002099003)(22082099003)(5023799004)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V3paMU85M2huY29sNmZnblR4c0pScC9TaStuN0xLU1ZhS2d4US9NaCtncUVS?= =?utf-8?B?MkRSdC8wTXNwSzJydjh5VUJMTkhzUjNldS9zUDVDNEhzMU44WGhhdWRUcGRn?= =?utf-8?B?UFpybENhbURxdGMvMzIrZ2xvOGgyQlRZMXNNY0NaNFJyYWFMM0VEd0tCK2Er?= =?utf-8?B?eDZHMXRzNjF3OG9tVXlhSDh4UkEvOVpFRjl1Q1hyS2NPb29VNS92dGVzdmdo?= =?utf-8?B?SWxKa0tFalF1ZytPYTlDNlZXSzlMQ05GYWFyVEIrV0NLSFF3Y1NucVZvS0xS?= =?utf-8?B?VWpRTzVNb28rdXQ3cUx1SEpmdkVaVFlEMG5EbVpyK2RxaG5HeU5BMUZ3cktq?= =?utf-8?B?MlpwY2hxdTdDTXN4cFdmbXEvcG85dmYrbkE1aUhIQUNVZlVyR09lQlR6Z1Ax?= =?utf-8?B?Q2k2SkUxdUZlUEVvek12b2pUeFZycmlNMnNtMWRsTnJ0bmlqUnYrV2pjY0k1?= =?utf-8?B?RkJZTnhGa2NjMTJ3VzEwVG9ISDRmMGxMVU4xYnFteHkxSFZjT2YwTjlVMENS?= =?utf-8?B?TVpaQ0hHV04rQldrVkpabFFjOXVmMXlubmV3QUJMMnJrK1J0SG9RaklYSlVT?= =?utf-8?B?V0p5VDJ5aDVjaWxHSDJQRVN6TGxyYW5xNE0yb01WdUhvdlMyZFI5WTNTa21G?= =?utf-8?B?OFhTRnc0WlNtcXBqYWZESlFLQ2xSNlp3VW0rU1ltYmRLTkpMdUREdWlNWXYw?= =?utf-8?B?UlI5RW9YZGxnSTFiNmdqVnlkL0tqSUpCRStqZ0hGSktxWmVySkdMTUNobFhv?= =?utf-8?B?QWpnemJ6ZGJyL2FGR2VQaTdoMmdSUUhGRTBKNXlVWHU1UlVRWGVsektRRXMz?= =?utf-8?B?NnVKcVZFd3R2Rkxubk9DanZmL0M3NGxPY1NDZVdmWVlzb29jSStCeDkwVUor?= =?utf-8?B?VVNrUlZuR0o2S0FwV1F6R2x4N0ZWZzd4azlCS3RhTEpoU0lDQnJwWFBmNHV3?= =?utf-8?B?bloxVFhFeitCbDcrT2s5eUZwTjVNeDJkdE1JQytzcnlhUENPUDFOTDgzWGhO?= =?utf-8?B?blF5RkhwZ0E5dFpMTXZoa21iZC9lbUhEQmlJbjlRcVozczFaMkRyNlg3OENw?= =?utf-8?B?b1dER21QWlk5c2N5ZXlhdnFTbEJKaE9sSlhBTmZ1ZkNNTnBiSHlycVE0MHc5?= =?utf-8?B?ZTRsYW5Iak5wUG5JNlZUNTVLL2hmZE5VUVpJYjd1dVBWeTN2ZzNFZlk2em4z?= =?utf-8?B?dm10Q24yU1h0V0hId0hrWlROVzNWMmpUQU02UWtLM21MSzByUjk4MG5BVjR2?= =?utf-8?B?Q3VHSHF6N3J2UmY3T1RpanA2TFYvcmIrSlI5UlpYbEIxRno3dVBqTno2WEE4?= =?utf-8?B?eGhDRnB2NWJyZXl5UUtGWVRjUDJvNEtZckxZRlY4R1FpaUpseDBwenRkakNB?= =?utf-8?B?dGkrd0FFYTV1U1NKUTR1SUpUbmVTMnB2V1NOZkoxeDdWRWEzTkhGQ0VxWXgw?= =?utf-8?B?cnZkYnNZTjVZbW56bkZlcFVPL2VLMkZpSThxNjNhVm1jejFERTJaNytYZW1m?= =?utf-8?B?NGRoc0xxYjkwVStUZmtTT3EzOWY4RVdhd2xwcm90bS85a2Y1OERnbEVMUnh0?= =?utf-8?B?RFpTOXhFOEpPTVcrYlJKYXhFaWNMM0dVc3VzMEtDQXM1c010OWFmcHJEOWVl?= =?utf-8?B?MFgzNDJGY1EzUGFxMGlTdWpTc2h0K2hjdEtPNXZNYUU3L1ZaWTJYZGdKOTdr?= =?utf-8?B?MFVOcjU4V2c3Rm84d3k2NW03SEtZMmh2NTluVjNJa25Bdk5FeTJTU0JKeDRn?= =?utf-8?B?WmQ1ODdTbTZNa1MzSC81WWJOZlF4ZGJHNzhVelpHdmVRTE10VHYzYjFuaTFm?= =?utf-8?B?UUlCOTVOa1IrQkV4ZThneFhhc1dlbUhUVy9uVm5pTlVVc2dDa3JSZXJKbUdv?= =?utf-8?B?eDFtd2hjQmFBSHBjdHJEMnB2dFdBSVh3REZ4VVc2UjlvVjBOL0E2Tm00dVJO?= =?utf-8?B?VXBMNmVyWjh2ZDl5by9pR1owZ3V6b0hibkJraG1iVm15Yjg2WWE4LzgvSU1l?= =?utf-8?B?RFB5ZTJ1WkxPUVYzYWJlM0NtaW1kZ2ZYaXYvWHNyOXY3YUFuMHdzS09USzFG?= =?utf-8?B?blIwVVhUUHo4YzJOdC9UeXNKMWlLME5ISDQ2Rk1rN2s2MW5KWEVLYXhITmQy?= =?utf-8?B?UU44V0NURGF6TDc4UWcwdDBnVWV4aUQ2andZbEFNaTU3YjdDejgybTFrY2F3?= =?utf-8?B?TWJ3dis2a1FCVm45V0dudmhsNm5waW4xNUpHcW9qU3dPMmFNNy9CRU9sRUJz?= =?utf-8?B?MTlOUFY3SnpwcWdHQnFUbURJQWtONGdnNmJzY05MbDFlc0crYllvWGdadjBj?= =?utf-8?B?SFZURGt6YVcvZzhHa1N0Y3dzWVU3WDRHZ0kxcW5uOXVTeG1RVXNhZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2607fbf8-191e-4f9c-5c2d-08df31078340 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 13:14:04.7259 (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: OkjOYu+80PpPgV9yhNjcYXxKBeG8a2FkHjMHYrj6Q/40pKfj6OYIp5qZeXNYynpHdy/3L2QmTgQSJ5zQHa2F1oqa+6OqKlkNAUfXGWggX44= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB4932 X-purgate-ID: tlsNG-33051d/1792761373-76CF84E9-E633BC51/0/0 X-purgate-type: clean X-purgate-size: 5019 On 23/10/2026 8:32 am, Peter Deggendorfer wrote: > Hey Xen Team, > > I'm hitting a reproducible hypervisor panic in the AMD non-fatal MCE > polling path on a Ryzen 9 5950X (Zen 3). Eight occurrences since > 2026-09-09, between 12 hours and 2 weeks apart, always CPU 2. > > Environment > ----------- > Xen:   4.20.4-pre (Debian 4.20.3+127-gc42374a105-0+deb13u1), and still >        present in 4.20.5-pre (Debian 4.20.4+39-gf1e1321c87-0+deb13u1) > dom0:  Linux 6.12.111+deb13-amd64 (Debian trixie), PV, 32 vCPUs > CPU:   AMD Family 25 (0x19) Model 33 (0x21) Stepping 2, Ryzen 9 5950X, >        microcode 0x0a201210 > Cmdline: dom0_mem=4096M,max:4096M ucode=scan console_timestamps=datems > > The panic > --------- > (XEN) [2026-10-19 08:58:18.727] Xen BUG at > arch/x86/cpu/mcheck/mce_amd.c:100 > (XEN) CPU:    2 > (XEN) RIP:    e008:[] > mce_amd.c#mc_ec2type.part.0+0/0x10 > (XEN) rbx: 0000000000000445   r12: 0000000000000011   r15: > 0000000000000446 > (XEN) Xen code around : > (XEN)  90 90 90 90 90 90 90 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 > 90 90 > (XEN) Xen call trace: > (XEN)    [] R mce_amd.c#mc_ec2type.part.0+0/0x10 > (XEN)    [] S mc_amd_recoverable_scan+0x39/0x40 > (XEN)    [] S mcheck_mca_logout+0x42d/0x840 > (XEN)    [] S > amd_nonfatal.c#mce_amd_checkregs+0x1c/0x100 > (XEN)    [] S smp_call_function_interrupt+0x4c/0x90 > (XEN)    [] S do_IRQ+0x2a5/0x650 > (XEN)    [] S common_interrupt+0x135/0x150 > (XEN)    [] S cpu_idle.c#acpi_idle_do_entry+0x8a/0x140 > (XEN)    [] S > cpu_idle.c#acpi_processor_idle+0x1ef/0x650 > (XEN)    [] S domain.c#idle_loop+0xc1/0x130 > (XEN) Panic on CPU 2 > > The outlined mc_ec2type.part.0 contains nothing but the ud2, so this is > the "unreachable" default branch of mc_ec2type() -- the extended error > code matches none of MC_EC_TLB_TYPE, MC_EC_MEM_TYPE, MC_EC_BUS_TYPE. I think it's safe to just drop the BUG(). That code is literally worse than useless, because if nothing else it's just hiding the diagnostics. I guess it means AMD have added new statuses. > > Across the eight occurrences, r12 appears to be the bank index from the > loop in mcheck_mca_logout(), with rbx == 0x401 + 4 * r12 (MCi_STATUS) > and r15 == rbx + 1. Three different banks are involved: 10, 17 and 23. > > Not a hardware defect > --------------------- > - Started within days of upgrading two hosts from Debian bookworm >   (Xen 4.17) to trixie (Xen 4.20). They had run 3 years on 4.17 with no >   incident. > - Three different banks, so not a single failing block. > - Updating to the current Debian package (4.20.5-pre, built 2026-10-16) >   changed nothing. > > Possibly related: 532988dccc19 ("x86/mcheck: fix mca_allbanks > updating"). > > Also possibly related on the Linux side: 0422b07bc4c2 ("x86/mce/amd: > Filter bogus hardware errors on Zen3 clients"), where bogus MCA values > on Zen 3 are filtered rather than treated as errors. > https://ratatoskr.run/stable/2026/04/7143905 >From above, you're on a Vermeer, not a Cezanne, so I don't think that Linux patch is relevant. However, your observation about "fix mca_allbanks updating" quite possibly is.  That was backported into Xen 4.20.1 as 247b708b1400a, and Debian has 4.20.3 Are you able to experiment with that patch reverted? Alternatively, are you able to experiment with the BUG() removed? > > Diagnostics / workaround > ------------------------ > mce_verbosity=verbose yields nothing useful. > max_cstate=1 made no difference. mce=false is the only thing that stops > it, and it is what I'm running now. The fact that mce=false isn't causing machine resets means it's clearly something the hardware thinks isn't fatal. But, I am concerned by the fact it's always on CPU 2, and multiple banks.  Is this true for both systems? > > One more thing: the host does not actually reboot after the panic. > "Reboot in five seconds" is printed, but the ring buffer continues with > normal activity minutes later and the remaining 31 CPUs keep running. > CPU 2 stays wedged, and "xl debug-keys t" then hangs. Afterwards dom0 > and guest vCPUs start losing timer interrupts permanently (RCU stalls > with a frozen timer-softirq count while dynticks keeps advancing), so > VMs hang silently hours or days later. I've recently noticed that crashing with interrupts off doesn't reboot any more.  I thought it was something local to my development, but apparently not if you're seeing the same. > > > I've attached the full xl dmesg log of the last crash, and I'm happy > to provide more if needed. I can also test patches. > > Thanks for your work, and thanks in advance for taking a look. > > Peter  Thankyou, ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 23 13:23:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 13:23:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459257.1671247 (Exim 4.92) (envelope-from ) id 1xKFFO-0008O8-PC; Fri, 23 Oct 2026 13:23:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459257.1671247; Fri, 23 Oct 2026 13:23: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 1xKFFO-0008O1-Mc; Fri, 23 Oct 2026 13:23:50 +0000 Received: by outflank-mailman (input) for mailman id 1459257; Fri, 23 Oct 2026 13:23:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKFFN-0008Nu-D4 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:23:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKFFM-00CqC0-Fa for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 15:23:48 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb5fcc-e002-0a2a0a5209dd-0a2a4503cfbe-44 for ; Fri, 23 Oct 2026 15:23: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 6adb5fe3-fae8-0a2a45030019-b9ff1c22ab73-3 for ; Fri, 23 Oct 2026 15:23: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 1a168ee7993000f79f.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Oct 2026 13:23:41 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 3A76A82A2E; Fri, 23 Oct 2026 15:23: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=+SB/8PrlB5OHIfE2Th+a8El9zCc4eoccXAwR9P9AS0Q=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=jr8VmSdMxV1I/IMr/8kjOQvQW1kylRvl41C3zhYyWj+eCK8F09Pgl291F+CGLjB4rpU+xAzkP YYQtd9i3ofQtrIdd9EjgIg5e4edJ/Z3rtZz/t2aGM6vCPC4p/Pkv1OPXG6jj4vlp5q3hoJznCuv b3QeCu5DVT0/D/fIvErwqZ7VXf6Pm7Dcj03f8ZfjNTFs8Vb5KA3l9xRseNXG3kTaABPjk/mMbC6 Bjfu07HanAVLTgV6Cb5tpQZBBN4g9MiBFDcwkvyInMNgRrV0YvMdx6n4ZLnmWcDZwnlGRoTGPzL pvtHuVlwjDUzx+mvoGwiuqrOWd2eqG7AzFZ/b38zHNDw== X-Zone-Loop: 9dda9f9242799d940dc150160b969d67b9782caa3ed5 x-campaign-type: default x-transaction-id: 333836d4-744e-4141-aad1-80e4bd6cbcb5 x-swg-uid: 01-66f12a99-64fd-4812-828b-b7c000cfce1f X-Mailer: Sweego Message-ID: <1792761821.8631fc262581453bbf619ec5b2062170.1a168ee7993000f79f@vates.tech> x-swg-bid: 1792761821.8631fc262581453bbf619ec5b2062170.1a168ee7993000f79f 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: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter Subject: [PATCH v2 0/1] xen/arm: populate a default P2M pool for new domains Date: Fri, 23 Oct 2026 15:23:34 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.182.1e3669d161aca86a.1a168ee7663.7593fa291705f890=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792761820777 X-purgate-ID: tlsNG-33051d/1792761828-6DED24E9-E1B867EE/0/0 X-purgate-type: clean X-purgate-size: 1791 ---=Part.182.1e3669d161aca86a.1a168ee7663.7593fa291705f890=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michal, thanks a lot for your review=2E I agree that in my previous patch I did neither explain the default pool, nor the 16 pages=2E I have refined the commit message and explained that on x86 a domain is "usable" directly after the XEN_DOMCTL_createdomain call, whereas on Arm there is an extra (mandatory) step to do that the toolstack needs to know about=2E Andrew's view was that this should be fixed in Xen, rather then in the tests (by calling p2m_set_allocation() there)=2E And you're also right that 16 is kind of meaningless, since, as far as I understand was just for the minimal GICv2 mapping=2E But, yeah, unfortunately, I couldn't use the formula from domain_p2m_pages() directly, because the RAM size of the domain isn't yet known in p2m_init()=2E I still use that formula but the RAM of the domain assumed to be 0=2E For small domains, I guess this is enough to hold all the stage-2 tables, but for bigger domains this needs tuning later by the toolstack=2E Not sure if this is acceptable? Signed-off-by: Julian Vetter Julian Vetter (1): xen/arm: populate a default P2M pool for new domains xen/arch/arm/mmu/p2m=2Ec | 24 ++++++++++++++++++++++++ xen/common/device-tree/dom0less-build=2Ec | 7 +------ xen/include/xen/domain=2Eh | 13 +++++++++++++ 3 files changed, 38 insertions(+), 6 deletions(-) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.182.1e3669d161aca86a.1a168ee7663.7593fa291705f890=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 23 13:27:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 13:27:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459266.1671257 (Exim 4.92) (envelope-from ) id 1xKFIO-0000Vp-9T; Fri, 23 Oct 2026 13:26:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459266.1671257; Fri, 23 Oct 2026 13: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 1xKFIO-0000Vi-6O; Fri, 23 Oct 2026 13:26:56 +0000 Received: by outflank-mailman (input) for mailman id 1459266; Fri, 23 Oct 2026 13:26:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKFIM-0000Vc-QP for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:26:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKFIM-005ljS-3F for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 15:26:54 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb607c-2eae-0a2a0a5409dd-0a2a4505c68c-40 for ; Fri, 23 Oct 2026 15:26:54 +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 6adb609d-4cb1-0a2a45050019-b9ff1c2399d3-3 for ; Fri, 23 Oct 2026 15:26: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a168f1512b000f79f.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Oct 2026 13:26:47 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id AEE5480A2A; Fri, 23 Oct 2026 15:26: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=re9ZAESsuhqaUOS9sdfxyzW0120b+/xqwVtfLS0UtFg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=i9rWkB2YjymCIgcgL+XYZRPxNR2ZRsIoB8UjwFcb1tWHb1+0Xp31xDhQTs23NoycAwP8Rixcx JKd8aSnKkgdtD+48Kc/wMrf33SdmWoZ7lT0iBfBj/i3Zrlg8fGyd8sN6gI4iBZ+0XhkmN//Ho2o 3weaVX2ac2tknuSUeL84zb9azkaREU6zFwYSYCgkWpfHgNhskAvmfHYA3+tVJN9wJUaHCdQ3+Ea lOa7/RlrAJ6/uKcNgjNy9r6VlRMfLmxqV1cohmOtpJKQLxcTIaI54iTNlk9LesxKzBqE09kdLzV P6VrK5lTq7Am1T6ZfRAZuXwcOlfA4KgZgqWL2z9SL//w== X-Zone-Loop: ec95b261c6fa3f38a73a2fe4a982453fc5cff748966b x-campaign-type: default x-transaction-id: 043b4718-86d1-40fa-917f-a3913b4ee4b0 x-swg-uid: 01-ce508661-b39b-40de-a137-8938f36bd21d X-Mailer: Sweego Message-ID: <1792762007.8631fc262581453bbf619ec5b2062170.1a168f1512b000f79f@vates.tech> x-swg-bid: 1792762007.8631fc262581453bbf619ec5b2062170.1a168f1512b000f79f 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: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter Subject: [PATCH v2 1/1] xen/arm: populate a default P2M pool for new domains Date: Fri, 23 Oct 2026 15:26:41 +0200 In-Reply-To: <1792761821.8631fc262581453bbf619ec5b2062170.1a168ee7993000f79f@vates.tech> References: <1792761821.8631fc262581453bbf619ec5b2062170.1a168ee7993000f79f@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.184.f70550542212459d.1a168f14ed4.f5dadc22baa78df7=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792762007253 X-purgate-ID: tlsNG-c201ff/1792762014-F6EB12A1-DC48A2DF/0/0 X-purgate-type: clean X-purgate-size: 5473 ---=Part.184.f70550542212459d.1a168f14ed4.f5dadc22baa78df7=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On x86, a domain can be populated directly after the XEN_DOMCTL_createdomain call=2E Sizing the pool is thus an optional tuning step for the toolstack (libxl: "the Xen minimum is for safety, not performance")=2E On ARM however, the P2M pool of a non-hardware domain starts empty=2E So, any toolstack must size the pool before populating the domain's physmap, otherwise no P2M tables can be allocated=2E This is an ARM specific step, which every toolstack has to know about=2E Instead, populate a default pool in p2m_init()=2E Ideally, it would match the formula used by dom0less (domain_p2m_pages()) and libxl (libxl__get_required_paging_memory()), but that depends on the amount of RAM for the given domain, which isn't known at domain creation=2E So, use the calculation but without depending on the amount of RAM for the domain, i=2Ee=2E, 1MByte per vCPU, plus 512KBytes for the extended regions= =2E Then dom0less and libxl set the full size, as they do today=2E Skip the hardware domain, which has no dedicated P2M pool=2E Also skip LLC colored setups, as the domain's colors are only configured after domain creation, so the pool pages would be allocated with the default colors=2E Signed-off-by: Julian Vetter --- Changes in v2: - Size the default pool based on the exisiting formula - Rewrite commit message to explain why a default pool is desirable --- xen/arch/arm/mmu/p2m=2Ec | 24 ++++++++++++++++++++++++ xen/common/device-tree/dom0less-build=2Ec | 7 +------ xen/include/xen/domain=2Eh | 13 +++++++++++++ 3 files changed, 38 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/mmu/p2m=2Ec b/xen/arch/arm/mmu/p2m=2Ec index 2cf35d8a37=2E=2Ed4971ba8d9 100644 --- a/xen/arch/arm/mmu/p2m=2Ec +++ b/xen/arch/arm/mmu/p2m=2Ec @@ -3,7 +3,10 @@ #include #include #include +#include +#include #include +#include #include =20 #include @@ -1541,6 +1544,27 @@ int p2m_init(struct domain *d) if ( rc ) return rc; =20 + /* + * Populate the P2M pages pool here=2E So, the domain is usable witho= ut the + * pool being sized first, as on x86=2E The toolstack, or dom0less, s= till + * sets the full size later=2E + * + * Skip the hardware domain, which has no dedicated P2M pool, and LLC + * colored setups, as the domain's colors are only configured after d= omain + * creation=2E + */ + if ( !is_hardware_domain(d) && !llc_coloring_enabled ) + { + unsigned long pages =3D + PFN_DOWN(domain_p2m_default_kb(0, d->max_vcpus) * SZ_1K); + + spin_lock(&d->arch=2Epaging=2Elock); + rc =3D p2m_set_allocation(d, pages, /* can_preempt */ false); + spin_unlock(&d->arch=2Epaging=2Elock); + if ( rc ) + return rc; + } + return 0; } =20 diff --git a/xen/common/device-tree/dom0less-build=2Ec b/xen/common/device= -tree/dom0less-build=2Ec index fcb438c50a=2E=2E21a13f9370 100644 --- a/xen/common/device-tree/dom0less-build=2Ec +++ b/xen/common/device-tree/dom0less-build=2Ec @@ -737,12 +737,7 @@ static void __init domain_vcpu_affinity(struct domain= *d, static unsigned long __init domain_p2m_pages(unsigned long maxmem_kb, unsigned int smp_cpus) { - /* - * Keep in sync with libxl__get_required_paging_memory()=2E - * 256 pages (1MB) per vcpu, plus 1 page per MiB of RAM for the P2M m= ap, - * plus 128 pages to cover extended regions=2E - */ - unsigned long memkb =3D 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 12= 8); + unsigned long memkb =3D domain_p2m_default_kb(maxmem_kb, smp_cpus); =20 BUILD_BUG_ON(PAGE_SIZE !=3D SZ_4K); =20 diff --git a/xen/include/xen/domain=2Eh b/xen/include/xen/domain=2Eh index aeb8b36ad1=2E=2E74dee32fb9 100644 --- a/xen/include/xen/domain=2Eh +++ b/xen/include/xen/domain=2Eh @@ -132,6 +132,19 @@ int default_initialise_vcpu(struct vcpu *v, XEN_GUEST= _HANDLE_PARAM(void) arg); int arch_get_paging_mempool_size(struct domain *d, uint64_t *size /* byte= s */); int arch_set_paging_mempool_size(struct domain *d, uint64_t size /* bytes= */); =20 +/* + * Default size of the P2M pool, in KBytes, for a domain with the given a= mount + * of RAM and number of vCPUs=2E + * Keep in sync with libxl__get_required_paging_memory()=2E + * 256 pages (1MB) per vCPU, plus 1 page per MiB of RAM for the P2M map, + * plus 128 pages to cover extended regions=2E + */ +static inline unsigned long domain_p2m_default_kb(unsigned long maxmem_kb= , + unsigned int nr_vcpus) +{ + return 4 * (256 * nr_vcpus + (maxmem_kb / 1024) + 128); +} + #else /* !CONFIG_ARCH_PAGING_MEMPOOL */ =20 static inline int arch_get_paging_mempool_size(struct domain *d, uint64_t= *size) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.184.f70550542212459d.1a168f14ed4.f5dadc22baa78df7=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 23 13:33:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 13:33:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459273.1671265 (Exim 4.92) (envelope-from ) id 1xKFOg-00029k-Tj; Fri, 23 Oct 2026 13:33:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459273.1671265; Fri, 23 Oct 2026 13:33: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 1xKFOg-00029d-QW; Fri, 23 Oct 2026 13:33:26 +0000 Received: by outflank-mailman (input) for mailman id 1459273; Fri, 23 Oct 2026 13:33:25 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKFOf-00029X-Nl for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:33:25 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xKFOf-00000009CNX-2ZzA; Fri, 23 Oct 2026 13:33:25 +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.98.2) (envelope-from ) id 1xKFOf-0000000Ccbq-0y6g; Fri, 23 Oct 2026 13:33: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" 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=mguQbioMgtMh+Hd/Llm9Ull5AdKxQv7LibED4N9dzC4=; b=vphwwyHwktwkR/i37udhfAMaNk ZxdZtOk+5sQCc9oWfMBF02zknv6eauES7LXgtJVKnUJTzhUWzow3sqRmLSk0EZUTCx1zPsNuQgjAd 7kjlIjPgc4hZBTNzHh3x7SBVjHBGGSaZ/irAsnzTr0tvirLyqLWUe0fIpoHacz+8RQ8w=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH] xen/vcpu: ensure no write when runstate handler is NULL Date: Fri, 23 Oct 2026 15:33:16 +0200 Message-ID: <20261023133316.64204-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 Both the normal and the compat versions of VCPUOP_register_runstate_memory_area allow registering a NULL handler as a way to signal deregistration of the previous area, and update_runstate_area() will skip the update when the handler is NULL. However when handling the VCPUOP_register_runstate_memory_area hypercall itself there's an unconditional attempt to update the newly registered runstate area, without taking into account whether it points to NULL. Skip such update if the user-provided handle is NULL. Signed-off-by: Roger Pau Monné --- xen/arch/x86/x86_64/domain.c | 4 ++++ xen/common/domain.c | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c index a02d4f569ee5..e4d49cbbfeb6 100644 --- a/xen/arch/x86/x86_64/domain.c +++ b/xen/arch/x86/x86_64/domain.c @@ -58,6 +58,10 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) rc = 0; guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); + /* NULL handle is deregistering the address. */ + if ( compat_handle_is_null(area.addr.h) ) + break; + if ( v == current ) { XLAT_vcpu_runstate_info(&info, &v->runstate); diff --git a/xen/common/domain.c b/xen/common/domain.c index 6b52713518da..30a17b8b7edb 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -2330,6 +2330,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) rc = 0; runstate_guest(v) = area.addr.h; + /* NULL handle is deregistering the address. */ + if ( guest_handle_is_null(area.addr.h) ) + break; + if ( v == current ) { __copy_to_guest(runstate_guest(v), &v->runstate, 1); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 13:51:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 13:51:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459295.1671274 (Exim 4.92) (envelope-from ) id 1xKFgJ-0005Lk-E1; Fri, 23 Oct 2026 13:51:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459295.1671274; Fri, 23 Oct 2026 13: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 1xKFgJ-0005Ld-BE; Fri, 23 Oct 2026 13:51:39 +0000 Received: by outflank-mailman (input) for mailman id 1459295; Fri, 23 Oct 2026 13:51:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xKFgH-0005LX-Pb for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:51:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKFgG-00FOUK-PI for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 15:51:36 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb6668-2eae-0a2a0a5409dd-0a2a4504b396-4 for ; Fri, 23 Oct 2026 15:51:36 +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 6adb6668-b57f-0a2a45040019-b9ff1c228cbb-3 for ; Fri, 23 Oct 2026 15:51: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 1a16907f005000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Oct 2026 13:51:30 +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 6270F82BC4; Fri, 23 Oct 2026 15:51:29 +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=pwcayrKNq12XtW4q5rh8elJhLg7t2tXGSuwyzMGCNNc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=PZ/+qbfglxuj+qUfhGzD2qUEYjb26NjLYgluTbJj9l46c+5b3GB7sUJkh7v/ZcmtU95ZdGwzZ gNUO5fZuNGQDXk2goSd1h5krTem4/Y0Y/QFkhL3uyBFW3jAUN1Yn73HBfclytuBq2H27HZAPExT wCcBR4H9p98EKdMsd78xrJrfxWXuDR57kqZf8YvDSKDbkzi10kBqMHbjnYUttrOxy6ek8dTiGD+ 1b18bbEZEKns1xbe3Bt2+UC/1wuOBvYhjinWDBHeTapydUYqhLIM2hQUequZ4JlCwfJw3XB6FyK veii5ijZKnIraMd8Y9UwX18cH7BCBf2tPQSbzBLGwVoA== X-Zone-Loop: d990d5e65dc03d8084f0ad9d138d0413aec4d4d253ea x-campaign-type: default x-transaction-id: 5e623cdc-d987-4d93-b241-44a7eb8df893 x-swg-uid: 01-c1df5276-8486-48a2-8350-dfe1dfc49b2e X-Mailer: Sweego Message-ID: <1792763490.8631fc262581453bbf619ec5b2062170.1a16907f005000f79f@vates.tech> x-swg-bid: 1792763490.8631fc262581453bbf619ec5b2062170.1a16907f005000f79f 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 v3 30/39] xen/riscv: implement APLIC-IMSIC-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: References: <2075cb10e5f6df787b29f2f087632c82b787a007.1790779209.git.oleksii.kurochko@gmail.com> Date: Fri, 23 Oct 2026 15:51:23 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792763484; l=14503; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ByT7kbjI8I1xqiNPT5/Vh3OaQRHptRG0hGjGa9deZ2c=; b=mNf6DM6HPXpL/GCJiwW8O1HLel9vGgwoZxIBxQAcvTyOVRJFDXYc9YaNHNa6YZbBKUqAHPoDh urFa95trpLXCGRUUzuXIb6yTaAS0V0kM+WV1fjPLxO5BV6dnYQC7Lph 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: 1792763489621 X-purgate-ID: tlsNG-ebf023/1792763496-C32CCB50-AB6CCD32/10/73395122804 X-purgate-type: spam X-purgate-size: 14503 On 2026-10-06 16:25:55+02:00, Oleksii Kurochko wrote: > On 9/30/26 6:23 PM, Oleksii Kurochko wrote: > > 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 hypervisor- > > 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. > > > > genmsi's Busy bit clearing only tells that the APLIC has sent the > > extempore MSI, not that it has arrived, so the sequence described in the > > AIA spec under "Synchronizing interactions between a hart and the APLIC" > > is split in two. aplic_genmsi_barrier() does the APLIC side, while > > imsic_aplic_sync() does the hart side: it clears the pending bit of the > > reserved identity before the genmsi write and spins on it afterwards, > > which is what tells that the extempore MSI, and hence every older MSI > > from this APLIC to this hart, has really arrived. Keeping the hart side > > in imsic.c leaves the APLIC code free of the IMSIC local CSR accessors. > > > > The last interrupt identity (nr_ids) is reserved for this purpose. > > > > Migration doesn't use the barrier at this stage, so imsic_migrate_vcpu() > > only references imsic_aplic_sync() to keep the compiler from complaining > > about it being unused. > > > > Signed-off-by: Oleksii Kurochko > > --- > > Changes in v3: > > - Rename from "xen/riscv: implement APLIC-hart sync barrier for vCPU > > migration", as the barrier waits for the MSIs to reach the hart's IMSIC. > > - Re-word the commit message, describing in it how the sequence is split > > between aplic_genmsi_barrier() and imsic_aplic_sync(). > > - Move imsic_aplic_sync(), imsic_local_is_pending() and imsic_csr_read() > > here from "xen/riscv: remap interrupts to new IMSIC VS-file", so that > > both halves of the synchronization sequence are introduced together. > > - s/aplic_hart_field/aplic_hart_index/ following the rename of the helper > > in "xen/riscv: implement virtual APLIC MMIO emulation". > > - Drop masking of sync_id with APLIC_TARGET_EIID, which could silently > > chop off bits; instead add BUILD_BUG_ON() and ASSERT() to make it > > explicit that sync_id always fits into the EIID field. > > - Drop the redundant parentheses around the macro argument in > > imsic_csr_read(). > > - Use unsigned int for isel in imsic_local_is_pending() and drop the > > redundant !! as the function returns bool. > > - Rename the unused argument of imsic_aplic_sync() to unused. > > --- > > Changes in v2: > > - New patch. > > --- > > --- > > xen/arch/riscv/aplic.c | 33 +++++++++++++++++++ > > xen/arch/riscv/imsic.c | 52 ++++++++++++++++++++++++++++++ > > xen/arch/riscv/include/asm/aplic.h | 3 ++ > > xen/arch/riscv/include/asm/imsic.h | 8 +++++ > > 4 files changed, 96 insertions(+) > > > > diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > > index 283e5d6046a6..5f9a894b5a76 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, > > @@ -183,6 +185,37 @@ 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; > > + > > + /* > > + * 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; > > + > > + 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); > > +} > > + > > static void __init aplic_init_hw_interrupts(void) > > { > > unsigned int i; > > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > > index f1e44dc56bb8..8e0273eab902 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); \ > > @@ -203,6 +210,15 @@ void imsic_irq_enable(unsigned int irq) > > */ > > ASSERT(!local_irq_is_enabled()); > > > > + if ( irq == imsic_cfg.sync_id ) > > + { > > + printk(XENLOG_WARNING > > + "irq%u is reserved for APLIC sync so shouldn't be set by %s\n", > > + irq, __func__); > > + > > + return; > > + } > > + > > spin_lock(&imsic_cfg.lock); > > /* > > * There is no irq - 1 here (look at aplic_set_irq_type()) because: > > @@ -241,6 +257,15 @@ void imsic_irq_disable(unsigned int irq) > > spin_unlock(&imsic_cfg.lock); > > } > > > > +static bool imsic_local_is_pending(unsigned int id) > > +{ > > + unsigned int 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) > > { > > @@ -387,6 +412,9 @@ static int __init imsic_parse_node(const struct dt_device_node *node, > > > > imsic_cfg.nr_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, 64); > > > > + /* Reserve last identity for APLIC-to-hart synchronization */ > > + imsic_cfg.sync_id = imsic_cfg.nr_ids; > > + > > /* Compute base address */ > > *nr_mmios = 0; > > rc = dt_device_get_address(node, *nr_mmios, &base_addr, NULL); > > @@ -497,6 +525,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 *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(); > > +} > > + > > static void cf_check imsic_vsfile_local_clear(void *data) > > { > > unsigned int i; > > @@ -862,5 +911,8 @@ void imsic_migrate_vcpu(struct vcpu *v) > > /* Zero-out new IMSIC VS-file */ > > imsic_call_on_cpu(v->processor, imsic_vsfile_local_clear, &vsfile_data); > > > > + /* Avoid an unused-function error until the barrier has a user. */ > > + (void)imsic_aplic_sync; > > + > > BUG_ON("unimplemented"); > > } > > diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h > > index 9018936ca95a..bfb510b2ae5e 100644 > > --- a/xen/arch/riscv/include/asm/aplic.h > > +++ b/xen/arch/riscv/include/asm/aplic.h > > @@ -94,6 +94,7 @@ > > #define APLIC_SETIPNUM_LE 0x2000 > > > > #define APLIC_GENMSI 0x3000 > > +#define APLIC_GENMSI_BUSY BIT(12, U) > > > > #define APLIC_TARGET_BASE 0x3004 > > #define APLIC_TARGET_LAST 0x3ffc > > @@ -177,4 +178,6 @@ struct aplic_regs { > > uint32_t aplic_hw_read_reg(unsigned int offset); > > void aplic_hw_write_reg(unsigned int offset, uint32_t value); > > > > +void aplic_genmsi_barrier(void); > > + > > #endif /* ASM_RISCV_APLIC_H */ > > diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h > > index 8130d125f5c3..f86407e21765 100644 > > --- a/xen/arch/riscv/include/asm/imsic.h > > +++ b/xen/arch/riscv/include/asm/imsic.h > > @@ -62,6 +62,14 @@ struct imsic_config { > > */ > > unsigned int nr_eix; > > > > + /* > > + * Interrupt identity reserved exclusively for APLIC-to-hart > > + * synchronization. > > + * > > + * Must not be allocated to any interrupt source. > > + */ > > + unsigned int sync_id; > > + > > /* MSI */ > > const struct imsic_msi *msi; > > > > > I think it also makes sense here to apply the following fixup patch: > > commit db57e94ed8405c98d7a21f4f88764fa5e0ea2d04 > (riscv-next-upstreaming-fixups) > Author: Oleksii Kurochko > Date: Tue Oct 6 15:59:52 2026 +0200 > > fixup! xen/riscv: implement APLIC-IMSIC-hart sync barrier for vCPU > migration > > In MSI delivery mode the MSI of APLIC source N carries identity N, by > which Xen recognises it in its own IMSIC interrupt file. A source > numbered sync_id or higher can't be told apart: its identity either > isn't implemented, so its MSIs are dropped, or is the one reserved for > the sync barrier, which it would satisfy early and whose pending bit > would swallow its interrupt. Limit the usable sources to those below > sync_id, and document how the identities of Xen's interrupt file are > allocated. > > diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > index 96aa4edb3958..86ff3cae984d 100644 > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -246,6 +246,7 @@ static int __init cf_check aplic_init(void) > uint64_t size, paddr; > const struct dt_device_node *imsic_node; > const struct dt_device_node *node = aplic_info.node; > + const struct imsic_config *imsic; > int rc; > > /* Check for associated imsic node */ > @@ -270,6 +271,22 @@ static int __init cf_check aplic_init(void) > panic("%s: failed to get number of interrupt sources\n", > node->full_name); > > + /* > + * In MSI delivery mode the MSI of source N carries identity N, by > which > + * Xen recognises it in its own IMSIC interrupt file. Hence the sources > + * numbered from sync_id on can't be used: their identities either > aren't > + * implemented or are the one reserved for the APLIC-IMSIC sync > barrier. > + */ > + imsic = imsic_get_config(); > + if ( aplic_info.num_irqs >= imsic->sync_id ) > + { > + printk(XENLOG_WARNING > + "%s: only %u of %u interrupt sources usable with %u > IMSIC identities\n", > + node->full_name, imsic->sync_id - 1, aplic_info.num_irqs, > + imsic->nr_ids); > + aplic_info.num_irqs = imsic->sync_id - 1; > + } > + > guest_aplic_num_sources = min(GUEST_APLIC_MAX_SOURCES, > aplic_info.num_irqs); > > if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) ) > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index ca5243826726..408b94b22ee9 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -533,7 +533,15 @@ static int __init imsic_parse_node(const struct > dt_device_node *node, > > imsic_cfg.nr_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, 64); > > - /* Reserve last identity for APLIC-to-hart synchronization */ > + /* > + * The identities of Xen's own interrupt file are allocated statically: > + * - the APLIC sources take 1 .. riscv,num-sources, as the MSI of > source > + * N carries identity N (aplic_init() drops the sources which > don't fit > + * below sync_id); > + * - the last one, nr_ids, is reserved for APLIC-to-hart > synchronization. > + * Anything else taking identities from this file has to stay clear of > + * both. > + */ > imsic_cfg.sync_id = imsic_cfg.nr_ids; > > /* Compute base address */ > > Any thoughts about it? LGTM, but I wonder why, as I said in the original patch, sync_id is really needed. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 23 14:02:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 14:02:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459318.1671283 (Exim 4.92) (envelope-from ) id 1xKFqA-0007CU-Gh; Fri, 23 Oct 2026 14:01:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459318.1671283; Fri, 23 Oct 2026 14: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 1xKFqA-0007CM-Cq; Fri, 23 Oct 2026 14:01:50 +0000 Received: by outflank-mailman (input) for mailman id 1459318; Fri, 23 Oct 2026 14:01:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKFq9-0007CG-Gg for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 14:01:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKFq8-00FQCg-Ml for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 16:01:48 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb68c9-bab6-0a2a0a5309dd-0a2a450bee26-10 for ; Fri, 23 Oct 2026 16:01:48 +0200 Received: from [74.125.82.47] (helo=mail-dl1-f47.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb68cb-b7e8-0a2a450b0019-4a7d522f8dd7-3 for ; Fri, 23 Oct 2026 16:01:48 +0200 Received: by mail-dl1-f47.google.com with SMTP id a92af1059eb24-150ef97e790so6553c88.1 for ; Fri, 23 Oct 2026 07:01: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=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=1792764106; cv=none; d=google.com; s=arc-20260327; b=EVjj2+Pso3r5G8ZLOwDqJOZeYXOpatPRRVXp7XWqoPPIJeMHpihQlor8k+lAa7miAX T5zsyrwdHZi2cypOwdfgPk2WQYnQnBxkSveQ3X+bgBKfSDxTTN8nsQOYXna7eBCABTQ2 m56cy6whtNkNyY4XXmTLZvR0YupreuVAcRt4wmraeUG9kN9rkKGxcyXN8VZ33qvBJ/30 r4n5uCz7aICXYFi4qmWv4eBFg9cp8FNMQOQ/jbJrQqfXiLnzqcx1j8pqpv9vV+Afq5X5 G/gWHKjFgA5RSGvbr6nf87EMjBSdR0AKTVaIBL8yGVswi1f5bS0kh+X4Kr2puoeHhaD/ FjmA== 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=AZ5unzVtyr6CfHrWvwZoGwosTQWFch4ButYqGt7D1j8=; fh=CdJwY7vLhaFeJUBnTIHxDpUghPGlWfwnlZvJ6LkRZqE=; b=V7GD+emnK1hEjXVqAMaFNKgzqiNU8/zRNVO4bHeYJFmSaXteEHXk8fPbzjR2Og29Ya NLc15IvBd8SRffm82iXTYr56c747I7zjXHg2R7wGhuuJf+wfngHuyY8/2jmppLrRaSqe lldSkKlxFZsLy9DDLrdXXclX05upNvYW88bzxzJDvlud0GCT1iYtUGRlfYZSV7Dq0Z8B JbL/y66Ab98uKfHfW1Xal5dQzbHfZl132434u16qJDMvs+KsQJQI02b6buJM6US8kOkF 6xpcghDoxMiRgG5Lf/kg1ELqKPCOggub6DUok6mFdTSXZSimXIH+sYKXh33aprKMqrga ylxA==; 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=1792764106; x=1793368906; 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=AZ5unzVtyr6CfHrWvwZoGwosTQWFch4ButYqGt7D1j8=; b=jO+u3VyfKQAvwpo9Vx8oDxA6slD0fpgjPZNVGJeV2caiGysWf4ugIfYIe5eyz53GEq NShww1G3w7mgZ0hoPoBfw3/gK7eYb8VtFBB+V/Z+RaOvgjLz4AT59g5U+7mgjHFKysYA Gu+eAZA9GJTkj1aUo/6JBQsHPLL4dMCWRBijiOoufaTA+Ax6kbaJKWTYDZ8H1AOHGSrU dBfGN0En8EShcZ2lFzlF9AvZ0CD+p8Z4KS4sG8RcldNOq51xYhoCqecEG98QBlrqI3Qm EHyd1J3m66QlCIbf11jHOyMYsutTImtTKjjWs320qT+PEkpKYBr49iKJTq33EkJaESrV z45A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792764106; x=1793368906; 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=AZ5unzVtyr6CfHrWvwZoGwosTQWFch4ButYqGt7D1j8=; b=UH5Kf80sYPduAyxBdcqCDfZKlpYpWx7EhuYvy939X63XKe3s4lbpXppI6dSBQvjy8A dc6YUsAARMgiMbG7sVaLEfgAoQt25yJAxWXaip5ukDrT/GArJ3ERU32/GE/72GbCZTS5 +eY1iYsL2SiJOGEawGdr2WGEHODbDIhFsRWchBUocRl4ylm+AqrQq+4uRRg8Qgj7DYT1 BYf1R+egg2qSqbpRRShVFs3oP0/jF3dXPHLiFzVJ+3LEJPt4DL/bPnfstPMt9D+ktPWI yLJxjydFrwGoozb/Vd89XVdIIOilU2nB42tWofRtUQ/Baq4Lv5H3PNGVVoDO4ZS2D1QI B32g== X-Forwarded-Encrypted: i=1; AKwUvBzygxUgHBLtoeZpamWPae4+Plp+tcwseZ8dxe1naJIAP60XSvuhgLQt7CJvUIWF0uc33vbEuWeHtEQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYLH+y0Tva+887+p3cyjh44mNraOZ9MH2hZHs/96k3y+MRYDZfZz YhKSrNAzQLY+k1gjreUgpctMuNUMF2DNNp3BErstshlertcQu2/IDeFGETGnKAPUrRUYixa79Vx bjkbCgs+TqDQSoATsRNr4sU+qtHPFaQynKOP7Js3b X-Gm-Gg: AYBFou1zJdVTPVwJAdL7iXHT8M9f2PESRZuKgWX3CD3E0cYP3Zb75507tfWwzb/YbYO 7ssiTJ0I2VNMDj0vwFkjs2/J13xI0vYgCV4QBvcE94ZAT/dowz9sLrO4LnQFFXnGi08kvjz+fci gEc5za6vdlspTKCrGAoI8Mzfzy7HRbm5KSdUDTy44eRfvnu0YM/nI7syIJxSHo/l07D5tpyRx66 RhZeedGw9uowlPNwT0hJBr7iU0Dafeo663BRrKi8fagcqPyLgrxejyvXrQkVZuhSryjif7pKuCS 8g3/8Z9pQJJlOH8G2+QJAoO4uJbDDOS39JU4ehtvLC9z5+uqfrVEZe+Az+Te4+6zzJLRyXoWt+R FjCE8r5QCfRuxZ0wnAWrrIMv5CzytRoAY1jbdgNOOogPWtCO0QxKBFt2vYVCgRQeNoERz X-Received: by 2002:a05:701b:4189:20b0:186:2ed4:45e1 with SMTP id a92af1059eb24-195f75291c4mr269263c88.7.1792764104890; Fri, 23 Oct 2026 07:01:44 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-2-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-2-41dbef50b9f7@toxicpanda.com> From: Mina Almasry Date: Fri, 23 Oct 2026 07:01:30 -0700 X-Gm-Features: AclHuK_0I1BOQb_enDLqQZci6PJ1fSRcgVvjvJoI-HqZD9AWV_ZZ1S_9BLYGvcw Message-ID: Subject: Re: [PATCH net-next 02/15] net: skbuff: add skb_checksum_full() that reports failure To: Josef Bacik Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1792764108-AA0C59EA-C1AA57B6/0/0 X-purgate-type: clean X-purgate-size: 4052 On Mon, Oct 19, 2026 at 6:50=E2=80=AFAM Josef Bacik = wrote: > > skb_checksum() can't fail. When the range runs into unreadable frags > or past the end of the skb it returns 0, which is also a valid > checksum, so its callers can't tell the sum from a failure. For the > receive-side validation helpers that means a packet whose payload was > never checksummed can pass, and commit 20ddd0fd2fcd ("net: skbuff: > don't BUG() on leftover length in skb_checksum() and friends") made the > past-the-end case one of those instead of a BUG(). > > Add skb_checksum_full(), which adds the range's sum to *@csump and > returns 0, or returns -EFAULT for unreadable frags or a range past the > end of the skb, and -EINVAL for a negative length, leaving *@csump > alone. It's __must_check so a caller can't ignore the failure, and it > recurses into frag_list members through itself so a failure there > isn't lost either. > > skb_checksum() becomes a wrapper around it that behaves as before for > the callers that haven't been converted: it returns 0 on failure and > warns once if that was because of unreadable frags. The following > patches convert the core users, and the rest will follow per subsystem. > Is it possible to stop sending 1 large series where some patches are related and some patches are not? Are the changes for segmentation in this series related to checksumming? > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > include/linux/skbuff.h | 2 ++ > net/core/skbuff.c | 56 +++++++++++++++++++++++++++++++++++++++++---= ------ > 2 files changed, 48 insertions(+), 10 deletions(-) > > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > index 09db32f70b53..969b1c3269ec 100644 > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -4279,6 +4279,8 @@ int skb_copy_bits(const struct sk_buff *skb, int of= fset, void *to, int len); > int skb_store_bits(struct sk_buff *skb, int offset, const void *from, in= t len); > int __must_check skb_copy_and_csum_bits(const struct sk_buff *skb, int o= ffset, > u8 *to, int len, __wsum *csum); > +int __must_check skb_checksum_full(const struct sk_buff *skb, int offset= , > + int len, __wsum *csump); > int skb_splice_bits(struct sk_buff *skb, struct sock *sk, unsigned int o= ffset, > struct pipe_inode_info *pipe, unsigned int len, > unsigned int flags); > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index a2b52a5a61a9..061c61422a38 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3545,12 +3545,31 @@ int skb_store_bits(struct sk_buff *skb, int offse= t, const void *from, int len) > EXPORT_SYMBOL(skb_store_bits); > > /* Checksum skb data. */ > -__wsum skb_checksum(const struct sk_buff *skb, int offset, int len, __ws= um csum) > +/** > + * skb_checksum_full - checksum a range of an skb > + * @skb: buffer to checksum > + * @offset: offset in @skb to start at > + * @len: number of bytes to checksum > + * @csump: the sum to add to; on success the range's sum is added to= it > + * > + * Return: 0 on success, -EINVAL if @len is negative, or -EFAULT if = @skb > + * has unreadable frags in the range or runs out before @len does. = On > + * failure *@csump is not changed. > + */ > +int skb_checksum_full(const struct sk_buff *skb, int offset, int len, > + __wsum *csump) > { > int start =3D skb_headlen(skb); > int i, copy =3D start - offset; > struct sk_buff *frag_iter; > + __wsum csum =3D *csump; Check for reverse christmas tree. > int pos =3D 0; > + int err; > + > + if (unlikely(len < 0)) { > + DEBUG_NET_WARN_ON_ONCE(1); > + return -EINVAL; > + } We don't normally go for these defensive checks. --=20 Thanks, Mina From xen-devel-bounces@lists.xenproject.org Fri Oct 23 14:03:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 14:03:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459324.1671292 (Exim 4.92) (envelope-from ) id 1xKFrR-0007iG-Ot; Fri, 23 Oct 2026 14:03:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459324.1671292; Fri, 23 Oct 2026 14: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 1xKFrR-0007i9-MF; Fri, 23 Oct 2026 14:03:09 +0000 Received: by outflank-mailman (input) for mailman id 1459324; Fri, 23 Oct 2026 14:03:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKFrQ-0007hz-P7 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 14:03:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xKFrQ-00000009CyB-2vzx; Fri, 23 Oct 2026 14:03:08 +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.98.2) (envelope-from ) id 1xKFrQ-0000000Daqu-0yiT; Fri, 23 Oct 2026 14:03: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=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=Wc3tn8C8x90b0BbNhFnMcCsKHf7Q9nHWOBW+BOOCRJQ=; b=y2AzbLjEQInr/OFjy7S7YAm/HM i9XSN6Y0xDserYwO88O8/c+nLPazKSWhr98StlqK1W99qST1ND6sbTUkDw91seZ+6v0quurJ3fDg5 l9zkHDVvymBYsT46fZs3NByBkVodW6zZpXaSkiguoaV1nExrNIDzG4fJnEMyf0hb/bkY=; Date: Fri, 23 Oct 2026 16:03:05 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] xen/vcpu: ensure no write when runstate handler is NULL Message-ID: References: <20261023133316.64204-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261023133316.64204-1-roger@xenproject.org> On Fri, Oct 23, 2026 at 03:33:16PM +0200, Roger Pau Monne wrote: > Both the normal and the compat versions of > VCPUOP_register_runstate_memory_area allow registering a NULL handler as a > way to signal deregistration of the previous area, and > update_runstate_area() will skip the update when the handler is NULL. > > However when handling the VCPUOP_register_runstate_memory_area hypercall > itself there's an unconditional attempt to update the newly registered > runstate area, without taking into account whether it points to NULL. Skip > such update if the user-provided handle is NULL. I've added: Fixes: 705ea2b54c35 ("New VCPUOP_register_runstate_memory_area hypercall.") Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 14:13:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 14:13:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459336.1671301 (Exim 4.92) (envelope-from ) id 1xKG11-00013M-L4; Fri, 23 Oct 2026 14:13:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459336.1671301; Fri, 23 Oct 2026 14: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 1xKG11-00013F-IL; Fri, 23 Oct 2026 14:13:03 +0000 Received: by outflank-mailman (input) for mailman id 1459336; Fri, 23 Oct 2026 14:13:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKG10-000139-UD for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 14:13:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKG0z-00APfm-SG for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 16:13:01 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb6b69-2eae-0a2a0a5409dd-0a2a45038ac4-18 for ; Fri, 23 Oct 2026 16:13:01 +0200 Received: from [74.125.82.49] (helo=mail-dl1-f49.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb6b6c-fae8-0a2a45030019-4a7d52318c05-3 for ; Fri, 23 Oct 2026 16:13:01 +0200 Received: by mail-dl1-f49.google.com with SMTP id a92af1059eb24-151de818519so4127c88.0 for ; Fri, 23 Oct 2026 07:13: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=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=1792764779; cv=none; d=google.com; s=arc-20260327; b=OtTy3+CEaJ9Y4J75PJF4mSgcwJ8TlevxYckuZgfa7aZ8fpcqJUIh+EOBLprrshx1Wi Um9Jk+7SKrjwbs/J5svcAQeLUwnPpN0NyaqUH2tpJXqkINKbvSVaEyUVxFxWqEG+FiXp eTQQco3vcM1C8mP6afMLpFiT2krgQjHOKw8MLLjZPDwXvjYzCGgthF7JXtv04Su9M8uy 8u9MF8gonK7pTDvsvAVb2qa6u/ssN4fpPU4Ld4bLacM0MHlPO9/tnm2nOfmJPB7uF1v8 uCMk06X03nUBXUbm5jeoEyWLtXMl4fs6uBZYT9A2B+Ps/TuQ3+QXOrM/dcN01rK0lZ14 KaJg== 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=xkLt3lfrbsQ7vfYdIskLImlrhPYw2t6MqVNHm8RXqsw=; fh=OJliEttHmb/xASVAeF1CSy2INZws7GMjffaELyUwywo=; b=BNV/3hiimZE6fEFek1J+POlMFxs7332nj6c5Z541kv4BjpVB82rNgeUsYO9BFV/ZGa zjrzbl1hklXOgZCVSAyu/JT8IscrV3MLfUxB/zUBega7m5CjAncVi5uhsTXOYoZYK4IL Z05vGunNk7APiRbUN5NnEKluUWzSzr9ryykBTG6oDXVVJD7oYhNLSsmLbxDmlGPhDQnp GeD6jN4ZVDj1Wgsu2rc1iRlnSRrrQvCKh5HxCFqy2jeF4JaVMw6NCWMAy9+JWfVoTpK/ 1ANp6PT0zl2+5DmI67cQsv5wQ6/CBIOWb4hvKJnoD/li1bYIKh33+chEdXtHJOQMVtXK i27w==; 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=1792764779; x=1793369579; 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=xkLt3lfrbsQ7vfYdIskLImlrhPYw2t6MqVNHm8RXqsw=; b=YvMyL0L8Ys/RfuQdYNrrBYuYswp2V56VkRQmRDYwDB6oXRnl78FLc4jIyMAURS5ZzX 5xG56DgH2/eh8j1RIbFqSAGYkQinyAVCtcloCJdCb1V8JtT8LxYC1WBp2ZPHrroCjNBP 1cmj+GNwFCqVvZL+qm+XLW6ZzvGhlOgSq3XFd3ayUrEQy2YuQI/YImgQRb/hldW1wGOB 6x8+fWmRyIobfty+wCiz9Rugo7/878ntU491jbQxWbcc/C8pwzi1q6i/uG9TyHAnLR6z oHTcLY7bJ0INe/wat9CVnXEhp/YsMp1TxXQKVePw4zyec2U8927t6GwAZl9RrgtG+plv UDsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792764779; x=1793369579; 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=xkLt3lfrbsQ7vfYdIskLImlrhPYw2t6MqVNHm8RXqsw=; b=ud9o6Bt2/YTqxTGvTCLg4po0RbXYVULFyOGn6+UC9ps1cDRqloPXmLvbXOS+KOaW7x 206OovJmrbnpv2jE5dNzvoM71bTw6zhImx4Gk/4VIvDhBoJGBZHEeOXudfCc8K+ZvpGn uzqGw5ROWyCSe3FySEgc9XKU+xSAlE1oRlVe18vrDpolloeT8Wcumj270v+UdAUs9qyS ygpm/rYXG+uZ+ZjNtArswSKVi+YSo9Wwm3uQ49ysJLMqjU8xWIfEvH3FckyhY9cst/w4 LyszOD/gfdSZelTzkRymu9hlvMizei9+cb0wS2iksTDcHWFuLDdoTSmxnxMIHgg7sGUh N8Ew== X-Forwarded-Encrypted: i=1; AKwUvByvPVNfjAKsM4JkEYDLTGKI2dhdOTQG+BG7kcpu+FxRJ7bjegdoPTfq/F4EVFTZmd1Vh7G8m9hBKO4=@lists.xenproject.org X-Gm-Message-State: AFq9FYIQeIJCVZ9QrrnVo6XyIA1gcL5hT9hyrgHy1NuiOCppn4U8iX21 C6BDfqlzgEEy3FyPo5fmC78a5mfr5ZEDFpPwRsdY7M7tP/m3/6iTFpZs4ISf5Mh/302yGRILq+r Z1RyD5jxi/cupZf8t3GU29SB/7K9YLhMPS2Bn9siY X-Gm-Gg: AYBFou2cg+e22IEeL1qBzBrIIrS/lGzW3sXrfVFnf37Avd47wx3M96L7j1JL3eX2wrl s7b2i5firtVMEESefon1QsTm+Dygs+s2v8AUJ/ZiNU3ex8LCk9Orpe8Y3K/UGLiPlW2jAybWzIZ HBVaz9sh2pxWrojMxcOL39jeHU3iwclmVuCiqmr0QKAXyjmiReKoKAupBmF6sh1Sr5TTLV+OUjh 8Jf4q5AbqCqgggaZwmDT9OARd4hI32jP9IpErb2AbBoNtloBYOVI/tUdfmgiUFo3o++uZc3aU5b Be3chQbNOu3hRwQl+GaEMNw6UOovk0BPTY8AV7NvGT8Uyyyt+uLXf0jYcItciWzOmGyLFbtqU+S pFfStUsYU01r+rpiXoaPWRF8tdIGOwVMXq731nPP6dNBvgpObPYS7O+vGY7T4Jlep1bF4 X-Received: by 2002:a05:7022:6ba5:b0:144:f802:8bf1 with SMTP id a92af1059eb24-195f96f6e3bmr421525c88.18.1792764777402; Fri, 23 Oct 2026 07:12:57 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-3-41dbef50b9f7@toxicpanda.com> <179273111951.3134.3452028799437573017@kernel.org> In-Reply-To: <179273111951.3134.3452028799437573017@kernel.org> From: Mina Almasry Date: Fri, 23 Oct 2026 07:12:39 -0700 X-Gm-Features: AclHuK-tcTcrResIEJF7frxNES1XOTcAYvLS5iUmn3CVJsSLoqeepm1x0REGvsg Message-ID: Subject: Re: [PATCH net-next 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed To: netdev-bot+sashiko@kernel.org Cc: josef@toxicpanda.com, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, jgross@suse.com, sstabellini@kernel.org, willemdebruijn.kernel@gmail.com, fmancera@suse.de, david.laight.linux@gmail.com, netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1792764781-750864E9-72C182E1/0/0 X-purgate-type: clean X-purgate-size: 927 On Thu, Oct 22, 2026 at 9:52=E2=80=AFPM wro= te: > > Thank you for your contribution! Sashiko AI review found 4 potential > issue(s) to consider. > > Critical: 0 =C2=B7 High: 2 =C2=B7 Medium: 1 =C2=B7 Low: 1 > > If you believe none of the issues are legitimate, please reply to each > issue of Medium severity or higher and explain why the AI is wrong. > If any of them are legitimate and you plan to respin, please let patchwor= k > know by including "pw-bot: cr" as a separate line at the end of your repl= y > (one such reply per series is enough). > > - [High] The fix does not hold when conntrack checks checksums first. > - [High] __skb_gro_checksum_complete() (net/core/gro.c:794-813) has the > same false-accept defect this commit fixes in=E2=80=A6 Both high's here seem like legitimate issue, al though the latter is maybe pre-existing. --=20 Thanks, Mina From xen-devel-bounces@lists.xenproject.org Fri Oct 23 14:14:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 14:14:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459343.1671311 (Exim 4.92) (envelope-from ) id 1xKG2p-0001c1-0D; Fri, 23 Oct 2026 14:14:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459343.1671311; Fri, 23 Oct 2026 14:14: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 1xKG2o-0001bu-TI; Fri, 23 Oct 2026 14:14:54 +0000 Received: by outflank-mailman (input) for mailman id 1459343; Fri, 23 Oct 2026 14:14:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKG2n-0001bo-Tj for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 14:14:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKG2n-00CzUs-AP for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 16:14:53 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb6bd2-bab6-0a2a0a5309dd-0a2a450c9ae0-12 for ; Fri, 23 Oct 2026 16:14:53 +0200 Received: from [74.125.82.45] (helo=mail-dl1-f45.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb6bdb-f479-0a2a450c0019-4a7d522d907b-3 for ; Fri, 23 Oct 2026 16:14:52 +0200 Received: by mail-dl1-f45.google.com with SMTP id a92af1059eb24-194d0c31715so11552c88.0 for ; Fri, 23 Oct 2026 07:14: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=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=1792764891; cv=none; d=google.com; s=arc-20260327; b=Zh9Clv85s2+wwkxcA77xmuFjXSJqVpOiNMafutAz+LCR5qlaLCSqj2grCyprrg5s3L pm9azRkUuDOcnuikzHK2fX9aOW3+mvVBdW+zL4JDPsYHWSXJfauPvn99MyKwA2bZ6HeN yk5C9blylz62j1MGVQMWIPdeFwNW1tzG0Y9VcMIh4R+PSYd6GyGocZ4+kVJLftoOInpG uqFYKGYwGqhhwus89tg0wj3I0jo1YE52Vy6GGVcqFUSjxroJt8rgMcd0cY3vsFDHdxf8 s5pVbkZr1pBlNRr+WIZhLQJPYRHcmefZuE0YzKIJqL19uKhl7sTf5LuYvpmlIx1mu0A2 Pqaw== 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=UX9XiJ/sX7H9VN90F3Ajif8yPiFt/xrbd1p2Jnn+V8U=; fh=OJ9mylx2JBzyO2BEyMqgd7O+vtLXT4S2AdO6tIKHjWs=; b=oIQouZONqX12qZyFlemZnKWn5rduyx5MPx5AGqCGz+0Y4/9zAPkv8JkGYMZIH3DYFb A3w8+oqMwx/MdYhPC4sSRxwdXd4L9Kk+NG5bZS11YQuKEHJjUuDa+JTYWPP8ehxidJTn 7TJ+X8KgYzk8Qy6V14ZwR7Yxr38cdVRP6gvyIQ78ow1Ld20d7XmPAF7vsLttyx5+EzjL pOtLS3UDlu12J/LQXh8UwO1Y7xtdGjP1/FCt7+3whISIi4bvePbOTSTLS8qzdM0Lt7o9 vF+7Ks8bx8AWTelQAGZ9q6a1EQ7sga4R/DjCK3NTm1psVIzwqDWTy5MkeTGVf0+r8bs9 1biQ==; 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=1792764891; x=1793369691; 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=UX9XiJ/sX7H9VN90F3Ajif8yPiFt/xrbd1p2Jnn+V8U=; b=Zts0LnzlQtdu+YpcqMZmrz0BtnIuaUs6P8lxvSVqIDNMpIHhnUb0AKOXTM8fjacxf5 eX8LBLZIYGE4eTKQ7v2lf0ZuvcKVwUfGZsW6YTCxbftxrQj6+cbFH9TCctY/IR1ZK/T4 ndm2gf5iAJpMn9dAaCGBUyD1MR/Rgj8gVoFzlrcMZWQUwjnnYOB/sfg2EmHeplfuGFUX 4Hqh3hUEkKk9bCX5wIVpxVABI98j98jroBH6gZyRFby4fV98BD/F0keu7hFDEoQJNpxs 6a8U5tP2q+zznORaKr09+vyD/W1eOWknCpBpEOTkL09hOUP2aM6fy7tIODe8Wov6W2h3 nDKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792764891; x=1793369691; 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=UX9XiJ/sX7H9VN90F3Ajif8yPiFt/xrbd1p2Jnn+V8U=; b=pZHRHvIAB8mbzB3sIYZDYw6rzSp23FVtgM2JGuFx1+0CbR92yH1fp5LEDoTVJJtcNj rVUR+ukCbZVwSi0IrQSeD3A78HBX0RiFw6PkKs1MNCxLU3othx1/vgpDv1kWXQwOWxfM 2sMYjn/6iu9g+4vIBU3aebQ0/XEmkKruHmOCaGJ0HbhE2YfQY7XZdc8FRnajQYmfAEpg yPEuLQuT8KIF7cd3jYVTZ+JSQWv9d55uHX3dEnuJEvaHiaEmvVg/kaQ9X3R9gmX2IC3G ANbtNjn6FHIZiJnEGs6PE/fvO4fmu/VIEipxbW/FlAs/JmOFL9a18/Gb8noWlA3z0b7+ FT3g== X-Forwarded-Encrypted: i=1; AKwUvBwBlhq4MY00ztZgskLZPIqnJyNJ1QYN8UnngAz/LUsaBKcNWFr//IQsvMdc97cvpvOdoEv3oF6a1dY=@lists.xenproject.org X-Gm-Message-State: AFq9FYL6uJvZIjYiZcPZucAtZtFlTpUjRyS34NRbABCpgtfBl7wTUE49 b3ND1iehEbbtw4Vv1opxSuSWxNTGh6JIQHl4lHEzNZlMK2eAWz1BGjH43g6z70UFEAzkqqWcQWT i0HiFtjcigVOzhftQwwzpS1lPMFVhZOh7ZQfs2mMZ X-Gm-Gg: AYBFou1axiuhwdduldAZad14dcCEP3+kAvwAFQPnnoov5WbjXW3PuBdQuDHKWC2Yjzj 4pIH60LVnnS0FX6GueGSR7S5vhPAns4aTxIuf0YiTUyaGNEo5Q/eOfP5OwAiDWW3ByHyvvroPkB gmDuMkv0Os1QRJxFza+Rs+kFD+ozglC6komxR+zFitV8Hb3dt+zgTWPd5MRRyHxUMloZZfEOlzK rXFda5CA81dvV90tq/j5XriV1LZigvG8j0uPK3/xyTzkMfd3Y1ubnXnYooZioqDjr5VVkEIc0lO Nv7xJW4ysZq7Oi95eVzgvBfaeVg0Nr93R+BrLMYAIvrLV3sUony2bf1oh1AEqiS0Q62NbiHFcCs 2Mn5lCKQwv1CQjb9uQb3ZqYZA8/NeiGne0mYFE1Iq405UBkPy7UlHRWNDFsekR6mg5lU= X-Received: by 2002:a05:701b:458d:b0:142:ef2c:c480 with SMTP id a92af1059eb24-195f01c4da6mr194592c88.17.1792764889782; Fri, 23 Oct 2026 07:14:49 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-4-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-4-41dbef50b9f7@toxicpanda.com> From: Mina Almasry Date: Fri, 23 Oct 2026 07:14:34 -0700 X-Gm-Features: AclHuK_2m3TNgrazOeFVO5X_G9cX4zSCYeyDyz_no9CuBf7VcXjYydnmobrYYP8 Message-ID: Subject: Re: [PATCH net-next 04/15] net: skbuff: fail segmentation when a segment can't be checksummed To: Josef Bacik Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1792764893-50F3BA5B-121F0844/0/0 X-purgate-type: clean X-purgate-size: 2362 On Mon, Oct 19, 2026 at 6:51=E2=80=AFAM Josef Bacik = wrote: > > When the device can't checksum the protocol, skb_segment() computes > each segment's checksum in software with skb_checksum(). With SG on, > the segments share the original frags, and a devmem TCP skb keeps its > whole payload in unreadable frags. The devmem MSG_ZEROCOPY path never > sets SKBFL_SHARED_FRAG, so the __skb_linearize() fallback is skipped > too. skb_checksum() then warns and returns 0, and tcp_gso_segment() > writes a TCP checksum that doesn't cover the payload that goes out. > > That's reachable with tx-checksumming off and SG on: sk_setup_caps() > still gives TCP SG and HW_CSUM, so the dmabuf send is accepted, and > harmonize_features() strips the checksum features but keeps SG. > > Use skb_checksum_full() and fail the segmentation with -EFAULT when it > can't checksum a segment, as skb_segment() already does when it can't > copy one. > > Found by the Sashiko AI review of an earlier fix for the same path with > SG off. > > Link: https://lore.kernel.org/all/20261009-b4-skb-segment-nosg-unreadable= -v1-1-7e2334a55fe8@toxicpanda.com/ > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > net/core/skbuff.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 40d2dd20d47d..88ed2dd99dc0 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -5239,9 +5239,13 @@ struct sk_buff *skb_segment(struct sk_buff *head_s= kb, > > if (!nskb->remcsum_offload) > nskb->ip_summed =3D CHECKSUM_NONE; > - SKB_GSO_CB(nskb)->csum =3D > - skb_checksum(nskb, doffset, > - nskb->len - doffset, 0); > + SKB_GSO_CB(nskb)->csum =3D 0; So I wonder if this needs to be a generic thing to do insidk of skb_checksum_full. It seems like the previous patch is complaining some fields in the skb are no-longer set correctly if we fail checksumming, like ip_summ. Maybe ->csum as well should not be left set to non-zero if skb_checksum_full fails. Anyway, Reviewed-by: Mina Almasry --=20 Thanks, Mina From xen-devel-bounces@lists.xenproject.org Fri Oct 23 14:37:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 14:37:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459377.1671320 (Exim 4.92) (envelope-from ) id 1xKGOo-0004lK-OM; Fri, 23 Oct 2026 14:37:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459377.1671320; Fri, 23 Oct 2026 14: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 1xKGOo-0004lD-Lc; Fri, 23 Oct 2026 14:37:38 +0000 Received: by outflank-mailman (input) for mailman id 1459377; Fri, 23 Oct 2026 14:37:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKGOm-0004l7-R2 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 14:37:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKGOm-005xL1-7v for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 16:37:36 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb7128-2eae-0a2a0a5409dd-0a2a450a9a5c-8 for ; Fri, 23 Oct 2026 16:37:36 +0200 Received: from [209.85.208.46] (helo=mail-ed1-f46.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb7130-f2d2-0a2a450a0019-d155d02e8ce6-3 for ; Fri, 23 Oct 2026 16:37:36 +0200 Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-6b1b12de661so12175a12.0 for ; Fri, 23 Oct 2026 07:37: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=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=1792766256; cv=none; d=google.com; s=arc-20260327; b=OfuFDZHYGvbNtbmpUaGLSHkKkWvAROh4hlZFivW9w+O/ZnYEq1DtgvrzlbRxxtmVlc oXmEAV4a2f47yEuwdPJQMYuHmGu5XYlf0Fi0DWTLYtllOzXW1NyOHgP5aCG79IMr2ZX+ jq3jJmabGErAhLbRWXkIwrReDpQegJOiDQ16Ezw4xo9JO3qWIu0mHGqqnGjTsU9LX2JK Xcc7bw5qmFS0jSarTXKgpimyxHKMa7/aqyPElI2pdDGZ6uzfxoh1xaol3i0mB6rZB10r RCgjZka+q3oCRIZXvRPMWcnL1+wCSQsDGQsFOWyfj56VW6Z14ZuOhG0esjYtSkM5JHDH ofdA== 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=TbyyQ/cVBjURwEkpwzvfBfCIIo+L2tVbdO6SgJnUJTQ=; fh=SW+8ZejeTBE2+9JuXfQboCoaPlVZgeA720cesd9C3AE=; b=Xz7nm5S94qyjf3r5XXyK8uCJhNLZS1k5rRgF5TtjG8Syamo8PkVAmBQKvkj9J7ucGI Hww1K8bE649duhf97M9TYgmgO0p2XwAkw8KOZp8CfxwX92FWyMTtmZ270fvPeKiC0zKr qovE1QCGvCi93rfbJPxywUf38d/T+KGjyb5pRFcl23mKb77xd5bcNS/QZvJuJk4tWR0I rkgmzponD1kSOLYfz95qvuNlcgJurQXqtSap9vZ5JfuYG3qXkKqzXDtPxf9q7GaolxMc pG/nxWoRMLW3cqjo26iO0T5zio+/PiauVjgcJ7xRIVzTciuar4dIdOGwV55ZiSzruvFs 5zxA==; 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=1792766256; x=1793371056; 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=TbyyQ/cVBjURwEkpwzvfBfCIIo+L2tVbdO6SgJnUJTQ=; b=YJdEIuzHXkpSMr754Gj/KLggzDhY9/AwTPVGt9k8SVu9qlTrv6PrTj+soLxCpoo599 Z53QyDQ9DpPXJsuk6ER+fyz6b0pjipa1EedDoEWVQP/K+nK76sHSrSYX11CWfq8j5zin vrXY5H6SojVSSur0McTGmhHLQ6YL8iluWEESQN5B4DCYq/008VhJ40PjX2Jcv9a7R0dp CCel1Zl4jsVAf4cM+RTnXIxi3MXBr+vzv0n49FdL3rveRJblEWnsqn19p7sH1bJNQvpZ our1t4iaKLHmkv7rIrZRnCASjSmXsB74ih4xqfwcTGWAmNkYX+K9SJoE7TtRduY3ZqQH P5Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792766256; x=1793371056; 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=TbyyQ/cVBjURwEkpwzvfBfCIIo+L2tVbdO6SgJnUJTQ=; b=s0mid5p3ffAEzKomn9qUz8+pYcxXy7Y5OkhwQ8eroXwu//+z/dFO4/SXXZY5lOc00m m1qVk4vKXBWdbg6KTYSSYcoLaGYG742Xq6UwB0sWehxrsigwbackU16zeSBVJ/4tC5j4 uo5KQ6ptpK7SMlNJvTH8UJ3Pnq5BPQxHyrVw/HPdQ+OoyDZCDPiQDke9A6Uzfli5iLmv VPTYPIP54Eb/BQhxjLiM5jiwMBFlPdJN3YTuDxPYR9FQ6pVgMIeqa3y/Op6FwLlVOvux ecT2916hf16pZX+9LXJTPUBiTRNl1Rx1E0wR5Y1GWnnA1zjGq8hTj7ryyIehjNudwM2p wf4w== X-Forwarded-Encrypted: i=1; AKwUvBxNzTlPGIQlN23TUm3qWbrbJwpFKFRNbMsJpd2rTxXGVp5t1iXaPE1MxfeQzTVBsm+S/4i43P8Yr4M=@lists.xenproject.org X-Gm-Message-State: AFq9FYKBUNVzbnmRG5HzPsxso57bXgeTl4JB+1lrMheqPwNyL1dAklWw ESc/bjSXbuEMeed/ou4Q5qLnwIzXNaqygvSQKLhdjGXyM4gdsJaYbX1zLml2lZQ5QcGsdw/f/hJ Kn/8+/8UbKLzhZersNqOLWLv0jxqXV1qzVa9Sc0D+ X-Gm-Gg: AYBFou3MWXZo6hRABmcrga96Y7JghG/XjAFp/k7N4BBI6iFDJSGrY/ykMXBgApW3p9q /k45fVQ7KxfM10w0l4hN2rOhnWNDht5YzqGSHuyKN0uRdYHOpKI3xxyWZcQAjYAynt9Ciq2xo9Y xnNgPyJR5hhdygPjeLL3cpgBfp9949oa2DPls/rXnrE6AB7XZ9wiWnkdMzgrBb9jIfhAHqkjHoE afTR3ZAqY5t+PodUObO9rA2BmYY/MIvCKGFf6FIrkmgGWvh9ejmVmQ+6mQgKpoIUtPlZY66PAQ3 8WEy/mnOU0TsBq22yRQpUs3Hmd4vmyFqP5eROMSsHGQ/iNRspKM3WBa9AXFOcMxnR43P34/y6Pm ++VUHLWsXy0nOV2P0M/l8HiAdGvAu18iOJzPLUUbtnA4bmZ39Y0+L9m5NXk4I2oBXEiU= X-Received: by 2002:aa7:d74a:0:b0:6a6:7385:3eac with SMTP id 4fb4d7f45d1cf-6b43503ae79mr48860a12.11.1792766255144; Fri, 23 Oct 2026 07:37:35 -0700 (PDT) MIME-Version: 1.0 References: <20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7@toxicpanda.com> <20261019-b4-skbuff-bug-on-followups-v1-3-41dbef50b9f7@toxicpanda.com> In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-3-41dbef50b9f7@toxicpanda.com> From: Mina Almasry Date: Fri, 23 Oct 2026 07:37:23 -0700 X-Gm-Features: AclHuK955ZVILJAXSd5ooCPOgIzdBikAhRIkvruYzZknz6V5xNQiHJHo5To2igs Message-ID: Subject: Re: [PATCH net-next 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed To: Josef Bacik Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Andrew Lunn , Juergen Gross , Stefano Stabellini , Willem de Bruijn , Fernando Fernandez Mancera , David Laight , netdev@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1792766256-512C8CFC-46F06BE9/0/0 X-purgate-type: clean X-purgate-size: 3641 On Mon, Oct 19, 2026 at 6:51=E2=80=AFAM Josef Bacik = wrote: > > __skb_checksum_complete() verifies a received packet with > skb_checksum(), which returns 0 when the range runs into unreadable > frags or past the end of the skb. 0 is a valid sum, so it's treated as > one: it adds skb->csum, the pseudo-header sum, and folds the result. > With a sum of 0 that's csum_fold(skb->csum), which is 0 whenever the > pseudo-header sum folds to 0xffff, so a packet whose payload was never > checksummed is accepted, marked csum_valid, and left with a wrong > CHECKSUM_COMPLETE value in skb->csum. > > __skb_checksum_complete_head() passes skb->csum in as the seed, so a > failure there folds 0 and the packet fails validation, but only because > skb_checksum() happened to drop the seed. > > Use skb_checksum_full() in both, and report a packet that can't be > checksummed as having a bad checksum, so callers drop it the way they > drop any other bad checksum. Clear csum_valid, and leave skb->csum and > ip_summed alone, since there's no full packet checksum to store. > > Found by the Sashiko AI review of the series that made skb_checksum() > return 0 for a range past the end of the skb. > > Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in skb_= checksum() and friends") > Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732= 895b@toxicpanda.com/ > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > net/core/skbuff.c | 21 ++++++++++++++++++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 061c61422a38..40d2dd20d47d 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3860,9 +3860,17 @@ EXPORT_SYMBOL(skb_crc32c); > > __sum16 __skb_checksum_complete_head(struct sk_buff *skb, int len) > { > + __wsum csum =3D skb->csum; > __sum16 sum; > > - sum =3D csum_fold(skb_checksum(skb, 0, len, skb->csum)); > + /* If the data can't be checksummed it can't be valid either. */ > + if (skb_checksum_full(skb, 0, len, &csum)) { > + if (!skb_shared(skb)) > + skb->csum_valid =3D 0; > + return (__force __sum16)1; > + } > + > + sum =3D csum_fold(csum); > /* See comments in __skb_checksum_complete(). */ > if (likely(!sum)) { > if (unlikely(skb->ip_summed =3D=3D CHECKSUM_COMPLETE) && > @@ -3886,10 +3894,17 @@ EXPORT_SYMBOL(__skb_checksum_complete_head); > */ > __sum16 __skb_checksum_complete(struct sk_buff *skb) > { > - __wsum csum; > + __wsum csum =3D 0; > __sum16 sum; > > - csum =3D skb_checksum(skb, 0, skb->len, 0); > + /* If the data can't be checksummed it can't be valid either. Le= ave > + * skb->csum alone, it's not a full packet checksum. > + */ > + if (skb_checksum_full(skb, 0, skb->len, &csum)) { > + if (!skb_shared(skb)) > + skb->csum_valid =3D 0; > + return (__force __sum16)1; > + } I think maybe we need to be careful here which are all the skb flags that we need to touch to indicate that the checksum failed. My LLM is recommending: if (!skb_shared(skb)) { skb->ip_summed =3D CHECKSUM_NONE; skb->csum_complete_sw =3D 0; skb->csum_valid =3D 0; } Seems ip_summed =3D *_NONE was caught elsewhere, but also maybe csum_complete_sw=3D0 makes sense. --=20 Thanks, Mina From xen-devel-bounces@lists.xenproject.org Fri Oct 23 15:47:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 15:47:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459471.1671375 (Exim 4.92) (envelope-from ) id 1xKHTp-0006Fe-PV; Fri, 23 Oct 2026 15:46:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459471.1671375; Fri, 23 Oct 2026 15: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 1xKHTp-0006FX-Mi; Fri, 23 Oct 2026 15:46:53 +0000 Received: by outflank-mailman (input) for mailman id 1459471; Fri, 23 Oct 2026 15:46:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKHTp-0006FR-1O for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 15:46:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKHTo-00Ffvh-EJ for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 17:46:52 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb813d-bab6-0a2a0a5309dd-0a2a450b94da-42 for ; Fri, 23 Oct 2026 17:46:52 +0200 Received: from [52.101.193.4] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb816b-b7e8-0a2a450b0019-3465c104d2b9-3 for ; Fri, 23 Oct 2026 17:46:52 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5663.namprd03.prod.outlook.com (2603:10b6:a03:27b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.19; Fri, 23 Oct 2026 15:46:48 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0546.017; Fri, 23 Oct 2026 15: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=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=KKSOnl+7sN4Jbpwys2XVMAy0rFGOxL/AK50oJYTWyoS8mJFt/rP4fpQu/BJTufgRP4cknLCmis6mMRefmyWUyObQKX1cDDqPN38iZT+JJtd2aUjcHiLR5LsS5spzJYcnyIAxFttX40FUrop0av0HKnL+fPF4V8lVCZ9709to6baZITEhq/wTF0bNUEGcx9CaXHuvql40IjB3/N1Xzp6uEyUmZc/5FF+Q0OspKoP/q3ST1qX8u7qw6S/VlaTSmr8uyqbP8cj2b+vRwkKO3UvrA7F3xm67ByhV47TYYFuVaM9PPJ5bFx6/CmTRX0l5jdWSylb4zP0OEHJYHBWF/YVKUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Sbn44joTs0DGvlSdbu8SyIdJZJ22F2VeNJN6Amc+Vog=; b=FFc6Uoba2/m4R4PAJ4DXmMwsV5YmClUkWuNlNTvQ0CK9/deVpJrhb2e5SZiR1kOc+zrhQngFBKkxZ1CUmnVXGeoipV/CpXh/DAWyLgMmEtUVnhgnycvaEDw7zAuB+1bjkBhHFW8T75UFJ739q0M9Q7VnOs9W9C92FoXwtb4mkPiDKv82hN4RFFeh+RvDcG2jbVMyAZCFLiNkNUqBLyERFO0Mu2WoW+Lay42yavbSHlKATTYIymUmX0ApyYZDXi5gZGe6Y9SmShFiumKb6yXwnZfKLRiq3aPIajULupJ/R7lmZZZURdVDdTYrxJkDGBTYRQm7VtWbU4NIH9yZnZkRww== 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=Sbn44joTs0DGvlSdbu8SyIdJZJ22F2VeNJN6Amc+Vog=; b=va6Z2fz9uhl/5VZJYDQiONdcn/CewZIE6hdRAL5YulSD2o3AY63vlOelJoYoWk8lC0jUv2rFZPAmluUE4cV+mUjNYiQYDxjf80nj9030DSayM5PZfj7LzkZehpDV2DV0Q8kA8R62Dar1661uv5fZhpy5duVNBxANHXgbf04+cTQ= 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, 23 Oct 2026 16:46:42 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] xen/vcpu: ensure no write when runstate handler is NULL To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20261023133316.64204-1-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: <20261023133316.64204-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0325.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5663:EE_ X-MS-Office365-Filtering-Correlation-Id: 94e848e3-12d5-4984-ef9d-08df311cd829 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|261013131602099003|261009223027099003|261022105027099003|261022075727099003|261021121427099003|10067099003|56012099006|18002099003|22082099003|11063799006; X-Microsoft-Antispam-Message-Info: rl8MD/WZf9V++InM+LVK+hRfntnX0KesRlsfdYBmK9usHqwYMmrq512wDfIKHIHWMzBzw2eZNq/YyXrVvH5VedS41MSywhp1UmcWh5N8iMskhbNpNWmVAL6xsjUQGKU1+My+lnX02xnZn8yJB7fAZrD0woL+D1JGY1z4RKMTAGM1V/CVssPXUjxAXemWH5dTctIEq0IGJelBP7e93sZBjclCVlagbnnp1kBYlCplZz7vaocanhC4HmSnETtAhGD0JbP0PSiqFA3SzKBKqGe5G9qSAwc3aW06XA11hJ4+FeTPPGbleg+mamJH4jWzwhamCkOD7Y67GYrFHRm1G82hv4DNOsb8dK9fGcwKETpPwRm65B/IoTJk2lJXqxKVI2re9YIQ5e5CCcY8m/0Qoa4UsCxyVJXHbBfDqVesVAocLyfDJyl4G0mEc7xhHb8/UeVDWBJNpwjvyeXp2q86C0a+OBC+NfLQcWjIH/rwcChiDDmaXKUP/04wlZxj915R/iryHW7jf5fF7x1phjCAJErfuhOk58ECbZlViJ1DBDxcUe10WQPm8Rbg+oke1Krq54pUc66EnPBgmv5EIQlQsAFEUWm7VJP1nhMKXBOwW0YF17TjJNS90FMSnFrwgEGnkBiCjaVFmMrBWL0ZyIogsB6fRYCsM/hHgpRQofknPBZfArA= 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)(261013131602099003)(261009223027099003)(261022105027099003)(261022075727099003)(261021121427099003)(10067099003)(56012099006)(18002099003)(22082099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UENsL1RGUGtnVDIyWTZwallLY01wakxTTkN6QVFUSFMzMGFjdy8xa3dFRmhI?= =?utf-8?B?K0Qyd25iNkF0dWk0RlMwVktIdFpHaUxkdVl5UzJHQXBaY3hOcTZncDhXVy84?= =?utf-8?B?SWUzNFJCZ3ZjSzJIYkNaRGlZWTZjT3ZJWklQSlYxcjRxeXRTbFVQYXVobnV0?= =?utf-8?B?ZUZhRkoxcnVZRzhmTFRaVHBKakJseWxZVkFzeC9mL01lUDhQcExZbk01bE1E?= =?utf-8?B?NHo4M3Ywc2pDTEVSY3lIckk3VGJYWnJZM1V1RWhvbUVIQ1hrVEVvWmZSSUVX?= =?utf-8?B?OFlRbjBhektaWnJyNmNsdEJtN0U3OXNCZjNsMjhVUitjUjlEejAwaUlYS2Q5?= =?utf-8?B?Qjg4aklqY2pLS0paUHdCY0p3SWhSRHNvU3hRRjZISk9TM1djZHZQSnFlWjlo?= =?utf-8?B?bEhncm5vOWExcDZSb0Z4SGN3cmdVME5vUW5RMGZkOGt4b2x3eWh2NTFJWnE2?= =?utf-8?B?QnR2ek9QTkMxbEF0SW9hZ0dFYmcvVWMrbU92Z0hWdUpnOE8rN1BqU01ockhz?= =?utf-8?B?bjVDNlJCY3N1dlJRVjhoZloxclRWdlE0YTZueFUvYWpvZnBlQUFtWTBmaEM3?= =?utf-8?B?NlkxWWY5UC9Bb25VbnhaaStpSWw1bE9QeXFRSkFmVlVKQVJXOTR6QWk5Q1d6?= =?utf-8?B?MHhlVnJ2QVBCYVY3SU1TN0dCS3lBNkZuUXhjSUh2Rzh1Q3VIUXpRb2h3dHJy?= =?utf-8?B?Si9QcWlqTTQ0cTI5bjBIa1A2Um45VGpPQjZHeC83WERlVm0yeXBYcS9vWjM0?= =?utf-8?B?WUNFN3UxYzhXMXRZTi9tYWNXQXhWYVBPUnA0MmJuVjFidDNWVUVsUTVCQ0w1?= =?utf-8?B?TGd1ZDJyb2Z6UElpVTY0WWY2ZVFuZzJIVndOMStEbHo2bFlLK1hCT2dZMnNk?= =?utf-8?B?Skh5ZDVNY29aNm9TdWZmU0kyYlQyMnRvRWhVTHorOGJ5V1Byajh1cEV2QzU3?= =?utf-8?B?RVRDSGVRSS9BNzdZWWpQb3R3QmFoMy9VUXhXajVocE42L0RNSHhWVlRvMHd2?= =?utf-8?B?MHZBOUVtTm9ObXVVZDdOQnFiVytHRGJoaUxmc2JyVG5vYndYSXVKdDB6QmRM?= =?utf-8?B?c2psZEhIK0NNMkRwdzJMa3pTRFVlNERGS21CanpUL3pSK2Qxdit6cHJlbkxU?= =?utf-8?B?TFhQbDR2VzhuWXRZekZvZG1XK0lCRWFBallLamJIRzFKODdXVUtHMUNVY0gy?= =?utf-8?B?TGhNTjIwcjlRRnd3a000Mm01Y3VnT1doZFBiVFdRcjlUU2tHYmJvRHhEZHF6?= =?utf-8?B?anVkS2JZU2FUcUQvUzlFT3crNHpEZHlKa1VRWmJwaDg2dWpTaUVaQ1A2OWU5?= =?utf-8?B?V0xYL2V3NHhuYm91c3NzUlJ2Y0hxN2tMSTROUEVuUjNIYTVoeHlYVEJEaEsr?= =?utf-8?B?MHc4ZUZ5aStpVDliT25hdkFHQmZBa2dkYmwyNUhrZ1F3L0wwWll6dUR5bGc4?= =?utf-8?B?TzBYams2elRLc0hKMzZDUWVGWXFRSUphazNQNWlSQ3hERCt4U3hrQkZ4eDlo?= =?utf-8?B?TEhsdkl1TVhHOW5DT0lid3lEOVFUSHVhdUVhREdrdXJ6T2FOVUhjVnRiV0Fu?= =?utf-8?B?MERJK0FjbUdObW83SG9CRGxjWURmRFBuVHZONjhqaHRSQnQ0U253QkZLZWdj?= =?utf-8?B?VlRSeWp6MHpTZHZWT01XWTBZUjl1a2VZcVRxNGwwbXRweUdrTmdQNXFBbjNt?= =?utf-8?B?Q3FES0xBOUpRaGZDbWRKajI0UXo0WlY0WHJkSDYreGM4eUIwclMvL2wwamJQ?= =?utf-8?B?QVFwT21LZGo2a2pNTXNHWDk1UWVFZjMrWWRPYURwY2wrMW5aNjFzQStISlF4?= =?utf-8?B?TmRyYTlSK1lTZVcyN3B4TzdRY0QraGdnb2FkUlBvUytyNEcyOER4RXdJQldx?= =?utf-8?B?Z2lwd1FxSlBmRzQ2NVVxMXIrMkI2Wi9Bb0x5M0ZDL3F3YTFaRXYzK0hJZ0V6?= =?utf-8?B?NUsxNXlJMm5LUExBQURtWnpGM3E2MHJ1dk1pdUswNjFERytKU2hmTVFWUHc5?= =?utf-8?B?WFJ0dmQwT2tONlozRHd5N0tIOU12OHhMUmtlWGU1SkllR2FZbXYxdzVMaGRk?= =?utf-8?B?cUhVc2NtR252VHpLUkhIRWVmbXM0TFVGZ1JXOSs1SGx6NDhtS0RINloxYnhQ?= =?utf-8?B?Q2tKL0VsK1MxeTVmaDlHYnJFenRST3RkYXVFTHpPeFBCVFlLREF6QmNvK3cv?= =?utf-8?B?NThKQXZZZVVNT2QwOW1SSzUzMWluMXBlYmpRQXJVK0lhbkZIVllObDFTQXZ3?= =?utf-8?B?UFQyek5hNnI5UERYeDk0ZVlsOG90V2MxS3Y5MTVvZktTNlVrRnVXOGNWWHRi?= =?utf-8?B?ZjhuWktPcWF5dG5NaVdpZ3h3M2Q3TlFiTDZQclZKcWtYUkJ4Z2JtcTRsTzli?= =?utf-8?Q?9Q2cmswuSZz6vKUs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 94e848e3-12d5-4984-ef9d-08df311cd829 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 15:46:46.7203 (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: WgZTYgV6Cjd6rTzOLh0AlydO3lVELTe+T726kz+t2Umywe21g+YzrCayFihMLwDSKLVLhWvIXvXBNuTJJBJ8OhclSijhtXtZXMgchvO0JgI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5663 X-purgate-ID: tlsNG-42698a/1792770412-AA4DB9EA-27E964D3/0/0 X-purgate-type: clean X-purgate-size: 3210 On 23/10/2026 2:33 pm, Roger Pau Monne wrote: > Both the normal and the compat versions of > VCPUOP_register_runstate_memory_area allow registering a NULL handler as a > way to signal deregistration of the previous area, and > update_runstate_area() will skip the update when the handler is NULL. > > However when handling the VCPUOP_register_runstate_memory_area hypercall > itself there's an unconditional attempt to update the newly registered > runstate area, without taking into account whether it points to NULL. Skip > such update if the user-provided handle is NULL. > > Signed-off-by: Roger Pau Monné > --- > xen/arch/x86/x86_64/domain.c | 4 ++++ > xen/common/domain.c | 4 ++++ > 2 files changed, 8 insertions(+) > > diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c > index a02d4f569ee5..e4d49cbbfeb6 100644 > --- a/xen/arch/x86/x86_64/domain.c > +++ b/xen/arch/x86/x86_64/domain.c > @@ -58,6 +58,10 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > rc = 0; > guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); > > + /* NULL handle is deregistering the address. */ > + if ( compat_handle_is_null(area.addr.h) ) > + break; > + > if ( v == current ) > { > XLAT_vcpu_runstate_info(&info, &v->runstate); > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 6b52713518da..30a17b8b7edb 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -2330,6 +2330,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > rc = 0; > runstate_guest(v) = area.addr.h; > > + /* NULL handle is deregistering the address. */ > + if ( guest_handle_is_null(area.addr.h) ) > + break; > + > if ( v == current ) > { > __copy_to_guest(runstate_guest(v), &v->runstate, 1); This is all horrible. I think you ought to add /* Update the newly-registered runstate area, best-effort */ to both of these hunks. I also think it would be easier to follow with the commit message structured in a different order.  I suggest: --8<-- The VCPUOP_register_runstate_memory_area hypercall tries to update the newly registered area, even when NULL is being registered.  If the guest happens to have memory mapped at 0 in the address space, this write will succeed. Ever since it's introduction in Xen 3.0, NULL is the initial state of the pointer, and guards the update of the runstate area in context_switch().  NULL has also been accepted as an input to the hypercall. It is unclear whether de-registration of the area was considered at the time, but the behaviour of the hypercall has always supported.  De-registering using NULL is a common pattern for other hypercalls, so formally make this the case for VCPUOP_register_runstate_memory_area by skipping the update if the area has been de-registered. --8<-- I think you also want an adjustment to the public header file to say that NULL can be used to de-register. Thoughts? ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 23 16:09:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 16:09:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459497.1671384 (Exim 4.92) (envelope-from ) id 1xKHpO-0001Pe-Ge; Fri, 23 Oct 2026 16:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459497.1671384; Fri, 23 Oct 2026 16: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 1xKHpO-0001PW-D7; Fri, 23 Oct 2026 16:09:10 +0000 Received: by outflank-mailman (input) for mailman id 1459497; Fri, 23 Oct 2026 16:09:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKHpN-0001PQ-LA for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 16:09:09 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xKHpN-00000009Fgs-2UOe; Fri, 23 Oct 2026 16:09: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.98.2) (envelope-from ) id 1xKHpN-0000000H3aw-0xLQ; Fri, 23 Oct 2026 16: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=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=k4NuFaJuMGHlk1YPEjGjLvezdUzxDmoBNx76b7+Ic1g=; b=jH6+pz4dnBUcuIzOJm90aC10Qc 4mbWWPpj6XPSKEpFvyZBUtIpcO37bOFP1Z2v8MbgPD8vXsJ2ssQfsu+U8eG/jBe9VZj8uYydmaABt CwSVyG506ETe4mWQYBDGORIuBkLLkSE4RobdbxKI6/X4BtmxmV3N7xmB79Rh5bL7p7KE=; Date: Fri, 23 Oct 2026 18:09:06 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, Jan Beulich , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] xen/vcpu: ensure no write when runstate handler is NULL Message-ID: References: <20261023133316.64204-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Oct 23, 2026 at 04:46:42PM +0100, Andrew Cooper wrote: > On 23/10/2026 2:33 pm, Roger Pau Monne wrote: > > Both the normal and the compat versions of > > VCPUOP_register_runstate_memory_area allow registering a NULL handler as a > > way to signal deregistration of the previous area, and > > update_runstate_area() will skip the update when the handler is NULL. > > > > However when handling the VCPUOP_register_runstate_memory_area hypercall > > itself there's an unconditional attempt to update the newly registered > > runstate area, without taking into account whether it points to NULL. Skip > > such update if the user-provided handle is NULL. > > > > Signed-off-by: Roger Pau Monné > > --- > > xen/arch/x86/x86_64/domain.c | 4 ++++ > > xen/common/domain.c | 4 ++++ > > 2 files changed, 8 insertions(+) > > > > diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c > > index a02d4f569ee5..e4d49cbbfeb6 100644 > > --- a/xen/arch/x86/x86_64/domain.c > > +++ b/xen/arch/x86/x86_64/domain.c > > @@ -58,6 +58,10 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > > rc = 0; > > guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); > > > > + /* NULL handle is deregistering the address. */ > > + if ( compat_handle_is_null(area.addr.h) ) > > + break; > > + > > if ( v == current ) > > { > > XLAT_vcpu_runstate_info(&info, &v->runstate); > > diff --git a/xen/common/domain.c b/xen/common/domain.c > > index 6b52713518da..30a17b8b7edb 100644 > > --- a/xen/common/domain.c > > +++ b/xen/common/domain.c > > @@ -2330,6 +2330,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > > rc = 0; > > runstate_guest(v) = area.addr.h; > > > > + /* NULL handle is deregistering the address. */ > > + if ( guest_handle_is_null(area.addr.h) ) > > + break; > > + > > if ( v == current ) > > { > > __copy_to_guest(runstate_guest(v), &v->runstate, 1); > > This is all horrible. > > I think you ought to add /* Update the newly-registered runstate area, > best-effort */ to both of these hunks. > > I also think it would be easier to follow with the commit message > structured in a different order.  I suggest: > > --8<-- > The VCPUOP_register_runstate_memory_area hypercall tries to update the > newly registered area, even when NULL is being registered.  If the guest > happens to have memory mapped at 0 in the address space, this write will > succeed. > > Ever since it's introduction in Xen 3.0, NULL is the initial state of > the pointer, and guards the update of the runstate area in > context_switch().  NULL has also been accepted as an input to the hypercall. > > It is unclear whether de-registration of the area was considered at the > time, but the behaviour of the hypercall has always supported.  > De-registering using NULL is a common pattern for other hypercalls, so > formally make this the case for VCPUOP_register_runstate_memory_area by > skipping the update if the area has been de-registered. > --8<-- > > I think you also want an adjustment to the public header file to say > that NULL can be used to de-register. > > Thoughts? LGTM, I will prepare v2 then, thanks a lot for the feedback. Roger. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 16:17:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 16:17:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459512.1671392 (Exim 4.92) (envelope-from ) id 1xKHxi-00038o-BQ; Fri, 23 Oct 2026 16:17:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459512.1671392; Fri, 23 Oct 2026 16: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 1xKHxi-00038h-8x; Fri, 23 Oct 2026 16:17:46 +0000 Received: by outflank-mailman (input) for mailman id 1459512; Fri, 23 Oct 2026 16:17:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKHxh-00038b-FN for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 16:17:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xKHxh-00000009FoG-1Z8t; Fri, 23 Oct 2026 16:17: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.98.2) (envelope-from ) id 1xKHxg-0000000HIWo-4AeE; Fri, 23 Oct 2026 16:17: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=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=91d6mOvZPpjsKDXzz8mQfsrDndJawH+XacKy+EAZdP8=; b=aFtz1MquU1dz62WgL0+1e4gSP1 yitzo4r62om5+mbal2Lky8BiNnPmGrGXZ24wy3P/RH6KmUcsqMgXa8+TVKOqw7MuhsTR5YVjfrWKf gM0CcmSEZGBB8Ncs3aUa1KVzqTBppTiQ7uniR9GTQda0asdCgzwXvEdlYpahcqgHfFUc=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v2] xen/vcpu: ensure no write when runstate handler is NULL Date: Fri, 23 Oct 2026 18:17:42 +0200 Message-ID: <20261023161742.67329-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 VCPUOP_register_runstate_memory_area hypercall tries to update the newly registered area, even when NULL is being registered.  If the guest happens to have memory mapped at 0 in the address space, this write will succeed. Ever since it's introduction in Xen 3.0, NULL is the initial state of the pointer, and guards the update of the runstate area in context_switch(). NULL has also been accepted as an input to the hypercall. It is unclear whether de-registration of the area was considered at the time, but the behaviour of the hypercall has always supported. De-registering using NULL is a common pattern for other hypercalls, so formally make this the case for VCPUOP_register_runstate_memory_area by skipping the update if the area has been de-registered. Fixes: 705ea2b54c35 ("New VCPUOP_register_runstate_memory_area hypercall.") Signed-off-by: Roger Pau Monné --- Changes since v1: - Reword commit message. - Comment on the runstate update attempt done in common_vcpu_op(). - Notice in the public headers that passing NULL deregisters any previous region. --- xen/arch/x86/x86_64/domain.c | 5 +++++ xen/common/domain.c | 5 +++++ xen/include/public/vcpu.h | 1 + 3 files changed, 11 insertions(+) diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c index a02d4f569ee5..533b0b21a00e 100644 --- a/xen/arch/x86/x86_64/domain.c +++ b/xen/arch/x86/x86_64/domain.c @@ -58,6 +58,11 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) rc = 0; guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); + /* NULL handle is deregistering the address. */ + if ( compat_handle_is_null(area.addr.h) ) + break; + + /* Update the newly-registered runstate area, best-effort. */ if ( v == current ) { XLAT_vcpu_runstate_info(&info, &v->runstate); diff --git a/xen/common/domain.c b/xen/common/domain.c index 6b52713518da..a1e4cb80871c 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -2330,6 +2330,11 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) rc = 0; runstate_guest(v) = area.addr.h; + /* NULL handle is deregistering the address. */ + if ( guest_handle_is_null(area.addr.h) ) + break; + + /* Update the newly-registered runstate area, best-effort. */ if ( v == current ) { __copy_to_guest(runstate_guest(v), &v->runstate, 1); diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h index f7445ac0b08a..403b81457c82 100644 --- a/xen/include/public/vcpu.h +++ b/xen/include/public/vcpu.h @@ -112,6 +112,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_t); * VCPU was last scheduled to run. * 3. New code wants to prefer VCPUOP_register_runstate_phys_area, and only * fall back to the operation here for backwards compatibility. + * 4. Passing a NULL handle will deregister the region. * @extra_arg == pointer to vcpu_register_runstate_memory_area structure. */ #define VCPUOP_register_runstate_memory_area 5 -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 23 17:27:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 17:27:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459555.1671401 (Exim 4.92) (envelope-from ) id 1xKJ2o-0003dc-0P; Fri, 23 Oct 2026 17:27:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459555.1671401; Fri, 23 Oct 2026 17:27: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 1xKJ2n-0003dV-TO; Fri, 23 Oct 2026 17:27:05 +0000 Received: by outflank-mailman (input) for mailman id 1459555; Fri, 23 Oct 2026 17:27:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKJ2l-0003dP-Tu for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 17:27:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKJ2k-00HTf9-Vm for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 19:27:02 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb98cb-e002-0a2a0a5209dd-0a2a4501d3d2-46 for ; Fri, 23 Oct 2026 19:27:02 +0200 Received: from [40.93.196.61] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb98e4-5984-0a2a45010019-285dc43d1df2-3 for ; Fri, 23 Oct 2026 19:27:01 +0200 Received: from PH8P220CA0024.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:345::20) by DM6PR12MB4250.namprd12.prod.outlook.com (2603:10b6:5:21a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.19; Fri, 23 Oct 2026 17:26:56 +0000 Received: from MW3PEPF00001655.namprd21.prod.outlook.com (2603:10b6:510:345:cafe::7) by PH8P220CA0024.outlook.office365.com (2603:10b6:510:345::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.19 via Frontend Transport; Fri, 23 Oct 2026 17:26:56 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MW3PEPF00001655.mail.protection.outlook.com (10.167.249.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.0 via Frontend Transport; Fri, 23 Oct 2026 17:26:55 +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.53; Fri, 23 Oct 2026 12:26:32 -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.53; Fri, 23 Oct 2026 12:26:32 -0500 Received: from [192.168.1.21] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Fri, 23 Oct 2026 12:26: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=FDJn27jVAIo40x3rKuD3X+DoTJBcsKoNo5zGGq4yF0mDh7RFMlT0IjC9jMgE5aCUADUuk/UOm2x5wyijd8+/39e4RB9+4GQ1Pdod3cuDCUbDYiL+BgvefFAysqMhSDew79VntBPX9bqazHUOV8t1oWxQ252a9h+ldYG2pB5iO43OntBhEvcDDdOaUswb4h/3xtWt0znOg3V0Aq1sAEqBtTQO/uyHVtbEL8o33xvM6cibt9pokAJTWDxjpNC0OnCeh5jYqejGW/rbUT14KvN3xssB0C82elscz0PscWp4ScA1wQamdMJ560XxpjuVfLXxKtvjCld5xQmJN15qOcBtQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TPSeXa+w24OvLipdyhvOs0Qo1zbsPLzxXW5BfqOpr4k=; b=ExOI4STwihMHpbNFsgayNMuOwkuvAOlJ/YOxntHT3inBhbpz9IhzJuiv0wELiNdVzcioVF+yK9u7pb4/K+LfNklIKLkar4kQqpfagxm06ASIBtT4jsHL7S2Wul7PhQlUcO1sC6WUH7Np2HMwpcKOqaMZkjA7EHVh9LjJTeAheu2DW68pomKWdzcMfKgNHN0AcPcyJ6vbAUcrmzIX7iwnMBQ2xgw2SjmiivuFtSZOwI7c2YRDrb146KoUmqk999G2aEcxT+m6EGokE5vR/4BMa8lAl4IJq8obg4xM+GkufjUcdAmcq6/pETgySG7MbyUp+uXtvH21KifbeX2SlDf19Q== 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=TPSeXa+w24OvLipdyhvOs0Qo1zbsPLzxXW5BfqOpr4k=; b=OSYYbRpwKGSwCC5u9Hp0tFxqEyxllZy8rtQ12q7RTwpbnDxjPChziDtzQVK77rEHHgwA8SWaNd6uYde+WMQNc2gUO0ofv9eVqDVpHBfPvsd7TEw2tvwSUr7jlnFojd96N42fwyolx5kzSILQcYRyTGn3FRVWRy0UyHc5nU+CJh8= 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: <2a597c4d-9ff6-461b-9a29-8d9feb76f827@amd.com> Date: Fri, 23 Oct 2026 18:26:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver To: "Orzel, Michal" , Ayan Kumar Halder , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis References: <20261021132640.599126-1-ayan.kumar.halder@amd.com> <8e4131b5-18e7-484a-bc4f-f9e6f279606e@amd.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <8e4131b5-18e7-484a-bc4f-f9e6f279606e@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: MW3PEPF00001655:EE_|DM6PR12MB4250:EE_ X-MS-Office365-Filtering-Correlation-Id: 73f8c2d9-62ae-432e-37be-08df312ad5bc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|82310400026|1800799024|376014|22082099003|18002099003|56012099006|4143699003|11063799006|261022105027099003|261021121427099003|10067099003|261009223027099003|261021123027099003; X-Microsoft-Antispam-Message-Info: CmvvWXmnbt216juuw89k3yDsPtJ1d6Z80lH9bnaqHmvz2Mg8OR/Vgo0ZGR7v31YAohm57DZ8OuT0xp7Mc6CI7IUbACeIVigHv8rNXGy1zSwBapJ5bW3KRqgRvwL0hypKUGPYXqsQhMjQdFyQeJksqMd3eokkW1QMx0umwF24chhPKz1V51zODhcOVlXSL2xWpDGIV/x1C9ifY9gmVl98rMKwzAhcyxamGDs84wn9PeDCERouLH0NuowzlD1zaXtyzbrqkXzE9rf8tMqNgFz6kU+bQE4SLkGuMgMVtEnD9dzrbZBJO0+a0EDFwwvz98BYAmL/tUD7wtxtKUxVqxlz/C/oq8asoc2XU5mREECIelsc6sdxNTcurNAcSSeXDt43L1MrZ0ehLbsaTg0DlCA7f1M6oJ6SDxXKOam3WTH+bm97jD0ae07LiDi4l9NqcUhpdPk2wtrLfo77fovNrsRnIIQogHV8giebjRGFAEhKvy05PoWeAr61frB+NiJREpeaniS30xh07jw684DS/hhfGeyv8RHiBL2vdA0Q8l+WgNFY6TBNzUXx9tDHsgAN5rDKDNIVk31++4wVVxck0aQu43ybnzzW7ScLrlnMMXd5PP7Dk23uLYNUjDT9tadSm7v1IL1MwUNK+5rONu/fyhFgY81zB3AxxzEWEpn5GzYqHb/a5dh2++ot7X9ZVN46aTkiXx3ux/DR/VHbSQmB0ejGfQ== 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)(36860700016)(82310400026)(1800799024)(376014)(22082099003)(18002099003)(56012099006)(4143699003)(11063799006)(261022105027099003)(261021121427099003)(10067099003)(261009223027099003)(261021123027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: JznNzjTzlKice+T0m3wlFgvCX6fdY6DNga5Pk5Yv1yGczOAEmJJuye7qGWfQis+Ah+plclaZuMYV7gxdYkeeqeanA/Hi1qEAAprmNqk3uIe8A3TQD4YDIJNUD9u6kVQmm5MPpzB04f+SplefIOOHD1gn3D1hdW2NjzH40xZvXAKyRBnlytiRcrjlirmxfkJgj1ot1nM7HiYP4DfqAfqalQVAFbvbTLnWp1CB7rlUn3+sctkfyjdbaDoghRY2ewMRrDEJXl8+ZImvGXzUsUJz+zu38tSbxZyncf9NP7BpYaKbiNt6OReOGadTCVtDKQRzzBiPqt32fIKxkwNfLPpBtQJgDy4luXYRg7YczTECIljwyZN716GAbFTPHeUJl31n2o9U10O+EWlGR41VLJkPFom8ADaIJ9mXqrJlKdS7b3qClojY37+MMmD1UAx/JsNc X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 17:26:55.2736 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 73f8c2d9-62ae-432e-37be-08df312ad5bc 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: MW3PEPF00001655.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4250 X-purgate-ID: tlsNG-d62444/1792776421-1D272757-61B6EAF2/0/0 X-purgate-type: clean X-purgate-size: 3689 Hi Michal, On 23/10/2026 07:42, Orzel, Michal wrote: > > On 21-Oct-26 15:26, Ayan Kumar Halder wrote: >> psci_init_0_2() stores the value returned by PSCI_VERSION in the global >> psci_ver before checking that Xen supports it. When the firmware reports >> a version other than 0.2 or 1.x, the function prints "Unrecognized PSCI >> version" and returns -EOPNOTSUPP, but psci_ver keeps the rejected value >> and psci_cpu_on_nr stays 0. >> >> psci_init() then tries the PSCI 0.1 fallback, which overwrites psci_ver >> on success. When the fallback fails as well (the /psci node is not >> compatible with "arm,psci", it has no "cpu_on" property, or Xen boots >> with ACPI), psci_init() returns an error that smp_init_cpus() ignores, >> and psci_ver still holds the rejected version. All the users of >> psci_ver then consider PSCI as available: >> - on arm64, smp_psci_init() installs call_psci_cpu_on() as the method >> to bring up the secondary CPUs; >> - on arm32, platform_cpu_up() calls call_psci_cpu_on() instead of the >> platform specific cpu_up() callback; >> - call_psci_cpu_off(), call_psci_system_off() and >> call_psci_system_reset() issue their PSCI calls. >> >> As a result, Xen brings up each secondary CPU with an SMC using function >> ID 0. An SMCCC compliant firmware refuses it, and Xen reports "Failed to >> bring up CPU (error -1)" for each secondary CPU. >> >> Only set psci_ver once the version has been accepted, so that a rejected >> version leaves psci_ver at 0 and Xen behaves as if PSCI was not >> available. In the case above, Xen no longer issues any other PSCI call: >> on arm64 the secondary CPUs using the "psci" enable-method are rejected >> by smp_psci_init() and Xen boots on the boot CPU only; on arm32 >> platform_cpu_up() uses the platform cpu_up() callback, if any. CPU_OFF, >> SYSTEM_OFF and SYSTEM_RESET are not issued either, as when the PSCI 0.1 >> fallback is used. >> >> Fixes: 4d3d72c01467 ("xen/arm: Initial support for PSCI-0.2") >> Signed-off-by: Ayan Kumar Halder >> --- >> xen/arch/arm/psci.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c >> index 634d0d7467..a720cf8d41 100644 >> --- a/xen/arch/arm/psci.c >> +++ b/xen/arch/arm/psci.c >> @@ -169,6 +169,7 @@ static int __init psci_init_0_2(void) >> }; >> int ret; >> struct arm_smccc_res res; >> + uint32_t ver; >> >> if ( acpi_disabled ) >> { >> @@ -191,16 +192,17 @@ static int __init psci_init_0_2(void) >> } >> >> res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION); >> - psci_ver = PSCI_RET(res); >> + ver = PSCI_RET(res); >> >> /* For the moment, we only support PSCI 0.2 and PSCI 1.x */ >> - if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 ) >> + if ( ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(ver) != 1 ) >> { >> printk("Error: Unrecognized PSCI version %u.%u\n", >> - PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver)); >> + PSCI_VERSION_MAJOR(ver), PSCI_VERSION_MINOR(ver)); >> return -EOPNOTSUPP; >> } >> >> + psci_ver = ver; >> psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON); >> >> return 0; > The patch would be simpler if you just set psci_ver = 0 right before > returning -EOPNOTSUPP. No need for the new local variable then. If you agree, I > can change on commit. With that: yes I agree with that. > Reviewed-by: Michal Orzel Thanks. - Ayan From xen-devel-bounces@lists.xenproject.org Fri Oct 23 17:28:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 17:28:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459561.1671411 (Exim 4.92) (envelope-from ) id 1xKJ4X-00048U-AZ; Fri, 23 Oct 2026 17:28:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459561.1671411; Fri, 23 Oct 2026 17:28: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 1xKJ4X-00048N-7b; Fri, 23 Oct 2026 17:28:53 +0000 Received: by outflank-mailman (input) for mailman id 1459561; Fri, 23 Oct 2026 17:28:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKJ4V-00048F-EA for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 17:28:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKJ4U-00FsIl-Rc for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 19:28:50 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb9932-bab6-0a2a0a5309dd-0a2a4501ca30-38 for ; Fri, 23 Oct 2026 19:28:50 +0200 Received: from [52.101.56.41] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb9950-5984-0a2a45010019-34653829be62-3 for ; Fri, 23 Oct 2026 19:28:50 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5816.namprd03.prod.outlook.com (2603:10b6:510:34::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.19; Fri, 23 Oct 2026 17:28:44 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0546.017; Fri, 23 Oct 2026 17:28: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=kXtIn3cTEaNNsrsGqDbTHoBq9qFPbasUIeX4/wYASm65plU6W9cJLwW8X3CU0kobA8W1SEsOwiNFjj31JDJaUrIvhDB3Tcgamso9e1OY6QZ23ft/ouTvrw3AzG6kPmM5r2mPOJrrfCI/JJvxRdBlTVYQ3O/Leq4FaWHANi1s+y2IeQvvupOTd8/rfMYZxgv7mbRu6GaP0zLjBHiDHlIv3UB/2VrEGwSi+1RHKFFFWTFVEwVuPCy2AFKnayGmWl9zc1BTizxUOtS68c8X8Q6kPPJwEIkFo6URFcEKSBRHrgXsrm9O3tSVsMhLIUNtJ69y1tv3TW6szhXS/SHYTIAxzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q0Gsq6CFTPoQfjGjNR58x+XGozGO2jJhMt+GsBY2Log=; b=Jb1EquT52YfCDkk8Fcz6OvpeGbWgTPO20l6fk/gKE3ykCtxm7xWmcf0UoGHh+1Oy+PEvdkXCDUOtbOYISKXPhf+AQfmy/TVnTo9LxNj+BimTpOK/RNG8BISNuPcIhcFc/OneU+vhOlkSXSfLDpfB0SZmFRvHrAvDsUYi1TIhgNRjLYYSPV+7Fe47wKVhb7V2RuYkn1bCAs/pwp6ZdCWdKJYXfapSTaSNEdFRk/LlDle2MqMfoctGXBdbRHOBD4M60DPFb0cYlBUxBMaRwBP7FxweGnEhWeaqOr6ssqJoxNv5Hgn2OUHBFxUEVD+Sw6trRh+NBRCjrb78kOLxpP/kWA== 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=q0Gsq6CFTPoQfjGjNR58x+XGozGO2jJhMt+GsBY2Log=; b=Bpd5UoM+r4JM5+UDT6iGFW/VR/9tmoM367tLuGGnbBsJzgN4jNfHkbaioIhaUO+eiDl/JVjQdPe3My2oco8uexMzdIJMJlbBoxHr+vp059vm9+Dtf5LDKSwnOMUaxG/bEBpSVGpwhqh+ApA9ZC3h//TjWplohBNAV4wHF7NvJ+g= 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, 23 Oct 2026 18:28:41 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v2] xen/vcpu: ensure no write when runstate handler is NULL To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20261023161742.67329-1-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: <20261023161742.67329-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0056.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2af::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_|PH0PR03MB5816:EE_ X-MS-Office365-Filtering-Correlation-Id: f85615e5-41eb-4aa9-046e-08df312b16d7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|56012099006|11063799006|261022075727099003|261009223027099003|261021121427099003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: C9HRpGo5j1N0D4ZzNgMzlx79b21PH1XxU4NDZnpxIn57kGTlQ3yCCWQ2Uhe4C7Qh5GrjSOwcT3a4ilQF3QT9xNbikP8CpiZc7pCCZUO6cYxuVWwdEBgnqQFKtAiiswBEmxyJiA70Agt2GnVLfcTsZsfdWLkCvre3F1vX30nsBlKztMviz61x055CJGbX5EMf3roDhLQamnpNLGdbb3FHik+5BdIVcMsvCEeWnNhbsZRpGXupykywiX4V1YzJcvCXAQjy9o73nFDzxxb2wUvyH/Z+Eeh/yMMQhIo55bk7+537lBOUA5onz+sEVOR52DLk2xKNb1YVpH2T3az8yKHxl+P6tQgHzeJVWLjq5mqEmVXS0NdMQbSy+ZSgFYSq9MX7N3VeDSaQf9QwWE/YLpyLq22gze15G50AIvEYNxOx1W683v+FSfIlDFAuA82gxLJtSPbf2Q9TzZ0cD/a9soIGignqoYqLumBj4VlUHebhT/rymZrXPaiQ0LU+pdM5ieT1Qqg8OopqPXam9qd6XwAKnd1IlXBacaoqJDkZkmpf7dBrMmR9o+1RwM+VatSgP3W/KGRqrwMPTvWFcT9aw50QDngoXAXnhmZfKextqkIgIvO+iCYt3BM1x9X69mcMBfZwHpmrsr+z6XhIdrNMjl+QBUWCMC5Af3OMyTxWtD+xl+M= 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)(56012099006)(11063799006)(261022075727099003)(261009223027099003)(261021121427099003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L0g1YWEyZWZPcXdJTE9mYmxJZGw5NVdQSkVOdG5MVUFiY1RMdnNnUkp5WnFl?= =?utf-8?B?cE1lTGFTTmtIN0xGamN4eXVuSzJsbURBMWs3Nkp5T0JvU0NxRTVjVk9GOGJU?= =?utf-8?B?Ty8wTndDZGxPYnM2UGNydzdmL0k0dHlnejNOcTV0VG50bGltdHNSNXRtWGVh?= =?utf-8?B?Y3dlcDNPMDNZWjZEVkNzendlK0U3TExZcDc3R1ppUjlidmZ6UnhjU3VZSmRr?= =?utf-8?B?RiszN0Q1Ty80S3U4bThHdEZEMFNsejFBOXNkcnJ4bDUzU2VkcUNkaTdYNVp2?= =?utf-8?B?UmdjTFVxSmhvVm9uMHhZdVdBeWJjR1BlTER2M21vdTBVTjg3SCtGQlAwZ1Za?= =?utf-8?B?ZkNlYVdKKzhqZDFONzFibExEVlAyTTBZekhrWEI4N1RkL3dqcy9TN1V4Yjl1?= =?utf-8?B?WnpwSmZIYzlkdW5WZUFjY2dJNW02M0tBZ2dLYXlveHczK3prZDZkUVZmT0RO?= =?utf-8?B?Ulg4cFY1cFBadFB6c0R3aEExZTNqM29naTVuVDVRNzVhaUtuUllWaW01UUo4?= =?utf-8?B?QjdWZHBhTUxtQ2hXSS9zOGROWnhkSmhBeFRDY2ZoWUhJWE9pS3ZEWUpUd0ow?= =?utf-8?B?SFBiNUlMeC9ldG1NNkJ1aEMwUFFRSGVtTjE4b3JyYm5PVUYvak5rSEM4N1Vu?= =?utf-8?B?bE8yTlVDcWo2UXJKWWFFRDdSVzAxRmdCYzUvNUZBU3dEMDdmRDc2Z002Ukdp?= =?utf-8?B?aTNhQ1hYRUZtMjNPbVJQcmRmYnRlUURYUUVnRU9yMWRuYURFNTJoRFpFVjJv?= =?utf-8?B?dmxuZkhBNGZWWDhnZlFKSmFjaFZYNk9DanRQemcwbjBjTkFpeTZpQXYrcDNX?= =?utf-8?B?UDFNWE10bHlVU2ZHZEZmZnZmQW9HTUlSeHBmTTNwSk85bHZlankwT3gzalE3?= =?utf-8?B?ZlJxcGZiYWJPM0Y2bk0rV2dtczloa0k3TXBRS0NBUHp3bTRCRjNqV3BwTzdX?= =?utf-8?B?WmdwWjBOdzRDaWcxN25tc1gxMWEyZk5hVHA2b3p4a1Q0RjBiaXZjN1o2Mzht?= =?utf-8?B?WGV6akZoTXpCL2NJNk4wbEtwM2VPa1N1eU5GK3BJRHpEeTAvLzJkVFRYVHQx?= =?utf-8?B?VHd3S2lKOEVRU3BXMTRNcnViZ2Jwejd5cTdob1NjVThMQnlpMnZhU3Qza2w4?= =?utf-8?B?SC83QXVkWHk5dUR0bVU5RjBpUjVEYk5SN2Jnajl1aHpZS3hNdXhkMGZScnN4?= =?utf-8?B?c1lKNzZMazlTd2lETS9mZzZHYTg1UThiNFhveDFMdmlEWk9iaTlOYTd3eWFS?= =?utf-8?B?cml6b0o5RWJ3eW9OWjRvUkQwNTZYcDRIZUxMNllDY25WMm82aUR0SEovVS9O?= =?utf-8?B?UVpQNDgxSE9GbEhabFRQbW91dGx2SGRJWEV2MkJleGpQdVhJNHhHb3ZPK3dP?= =?utf-8?B?RDRFUHZSdWM2b1hRcjRtelRySGlXUm9QNDJsM0QrV3didzJPSWQ4VEdaenJX?= =?utf-8?B?Q3lRbElkYmNaelUyWjZ2UlozeHBXVWYrZHlwMFR0cTRJaU95V2JTRGc0RTRH?= =?utf-8?B?Vnc3TVVabEw3V0lmRWZBVzhVWWJONEx1b0w1bUFnUEdjcVFOanZxUXZPSzVu?= =?utf-8?B?SnRWdm5VdGRiN3d1N3dVUGN2aVJocmgwN3NGQVpDb2V2TjJ0K3pHd2NYeDFr?= =?utf-8?B?dmd3MWNKMDdHYWJHLzg1Z3VDWkVnMVF4VEwxM1ZOVXdaNWVHYkNpRjI2b0s2?= =?utf-8?B?K0ozd3U0VUU0WU9JK0Vpckk4VjljSEkzdzAyS0Z0Kzc1bmlEN3U3aEZLQW1J?= =?utf-8?B?Um9COHdkVlhkWEJHekhNWDZwd0tyT2w0N1VxekFIWnlES21zL0RjVEVEWVRy?= =?utf-8?B?UkhucHJaN0JnUWtqNmt3RVhNZXNnM0lobWJiYmJndmZCMmZGZFFHVVJhQXpQ?= =?utf-8?B?amwxaTdQS1FFZkZ5bzIrTHhrdS91WXlrUWh4MEU3MkZJU05EZktCNFZHQWFo?= =?utf-8?B?M2V5cUc5QUozZzVjR0pFaUpWZGRjcEhuU0o5RXhVWUVZUVphSjdOYUJvbi82?= =?utf-8?B?YlNVYmhlNEJXRUtjUGRDVGRxbzZlT3IwY3A1eCtaWkZGbVNNL1lSZitaczJh?= =?utf-8?B?VFBwRTFVMWZBd0NDZlJMLzFxN2tNUTVwV00wQjdtNkdUTEFKT3NwSXRhNW5x?= =?utf-8?B?RCtQYWpDb01pVlpOMFNsSzR6ZXEzTlZueVU2MlcxR0xPcnJOa0EwMTNYemxG?= =?utf-8?B?dUdHVithZW93aDhVa09zR2orTVhoMEVBcVF0VkJsZmtNd3pHZmxZVVVDOGJP?= =?utf-8?B?Ykk0aVliRy9jTlRwNGtQMDdQOVpvSUZ3QjBycy9ndlFDVmxMOHBCQXFUaE1S?= =?utf-8?B?U3pWaXBCVk53TnRPY0Z6dE1FTzJIbGVhbC9PL1FsWXg1a2xhNGZ3R1VoYStP?= =?utf-8?Q?QDj+cvg3csjLo6Pw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f85615e5-41eb-4aa9-046e-08df312b16d7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 17:28:44.7104 (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: BDrQcHGGx2t8RuAHz2WcxkzbCOeA2Zbixb3Iof8nfERjdd1KWx895oAvc2KObQRYOLGBSdp5dN+stuqxRM03/Of4PGUGh+YGT4ii0zWJYYA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5816 X-purgate-ID: tlsNG-d62444/1792776530-1F46D757-9F79033B/0/0 X-purgate-type: clean X-purgate-size: 1100 On 23/10/2026 5:17 pm, Roger Pau Monne wrote: > The VCPUOP_register_runstate_memory_area hypercall tries to update the > newly registered area, even when NULL is being registered.  If the guest > happens to have memory mapped at 0 in the address space, this write will > succeed. > > Ever since it's introduction in Xen 3.0, NULL is the initial state of the > pointer, and guards the update of the runstate area in context_switch(). > NULL has also been accepted as an input to the hypercall. > > It is unclear whether de-registration of the area was considered at the > time, but the behaviour of the hypercall has always supported. "supported this." Sorry, I had a typo. > De-registering using NULL is a common pattern for other hypercalls, so > formally make this the case for VCPUOP_register_runstate_memory_area by > skipping the update if the area has been de-registered. > > Fixes: 705ea2b54c35 ("New VCPUOP_register_runstate_memory_area hypercall.") > Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Oct 23 19:27:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 19:27:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459308.1671455 (Exim 4.92) (envelope-from ) id 1xKKvX-0002fD-FS; Fri, 23 Oct 2026 19:27:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459308.1671455; Fri, 23 Oct 2026 19:27: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 1xKKvX-0002f5-Bl; Fri, 23 Oct 2026 19:27:43 +0000 Received: by outflank-mailman (input) for mailman id 1459308; Fri, 23 Oct 2026 13:55:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKFjZ-0005vH-NV for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:55:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKFjY-00AMN7-TP for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 15:55:00 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb670b-8faa-0a2a0a5109dd-0a2a450c9e54-44 for ; Fri, 23 Oct 2026 15:55:00 +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 6adb6733-f479-0a2a450c0019-aa0a817c99f7-3 for ; Fri, 23 Oct 2026 15:55:00 +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-479-CqSf_XYnNNmtmPh4ytbQ0A-1; Fri, 23 Oct 2026 09:54:53 -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 C62B3195395F; Fri, 23 Oct 2026 13:54:46 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7B7EC3000723; Fri, 23 Oct 2026 13:54:42 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 0863521E6A04; Fri, 23 Oct 2026 15:54: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=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=1792763699; 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=DjoH8evZxLD/oQi+kI32wJGQ4IzIUrG3x0m38hDozM8=; b=FB6PPRONVNlEGUB/jQq026ZGaiNgN9AqTzseEE5GqsutF8XLJiCE90MFgtFmKLbMj8H0BE 4f9I5VO3wk6Ul83t1LhSpYqK85kCC6Z0C1GR/wefyNAPKihIELB/13747m3RX/C1AoTC4b 0hPkVdmlitgUUBgEajjamy8Q36Yw7gI= X-MC-Unique: CqSf_XYnNNmtmPh4ytbQ0A-1 X-Mimecast-MFC-AGG-ID: CqSf_XYnNNmtmPh4ytbQ0A_1792763689 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 11/65] qom: add qapi_type field to ObjectProperty In-Reply-To: <20261020-qom-qapi-v7-11-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:45:28 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-11-431a86b02b58@redhat.com> Date: Fri, 23 Oct 2026 15:54:39 +0200 Message-ID: <87h5ica5eo.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: IBUX5bZjLuBYdwYSFbqahhtaT7EPK_6zAGHpdAWWKhs_1792763689 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1792763700-50520A5B-D69C33A8/0/0 X-purgate-type: clean X-purgate-size: 478 Marc-Andr=C3=A9 Lureau writes: > Add a const pointer to QAPITypeInfo in ObjectProperty. NULL for now, > but future patches will add means to make it non-null. The > QAPITypeInfo will then be used by QOM introspection to tie the > property to a QAPI type. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau Reviewed-by: Markus Armbruster From xen-devel-bounces@lists.xenproject.org Fri Oct 23 19:27:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 19:27:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459204.1671429 (Exim 4.92) (envelope-from ) id 1xKKvV-0001z4-UL; Fri, 23 Oct 2026 19:27:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459204.1671429; Fri, 23 Oct 2026 19:27: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 1xKKvV-0001w7-On; Fri, 23 Oct 2026 19:27:41 +0000 Received: by outflank-mailman (input) for mailman id 1459204; Fri, 23 Oct 2026 12:04:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKE0y-00062g-0m for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:04:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKE0x-00AEic-E3 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 14:04:51 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb4d52-2eae-0a2a0a5409dd-0a2a4504c106-30 for ; Fri, 23 Oct 2026 14:04:51 +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 6adb4d62-b57f-0a2a45040019-aa0a857cc531-3 for ; Fri, 23 Oct 2026 14:04:51 +0200 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-648-RNn1o_AYP7626sFnSx-wfw-1; Fri, 23 Oct 2026 08:04:48 -0400 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-48af4046a3bso857164f8f.2 for ; Fri, 23 Oct 2026 05:04:48 -0700 (PDT) Received: from redhat.com ([2a06:c701:73f6:2400:30a8:9e33:7d82:c035]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e37edce4fsm5022761f8f.6.2026.10.23.05.04.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Oct 2026 05:04: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=1792757090; 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=ktFG9S7cIu86S66z6woz0uEJeRaYlQD7UfoTSNONZWI=; b=S2kPSjLfswkW3Ui3xIO+tGRdKjde7UuboyKe4nd9SiW3pwvCp+DmA+bPsGEQxQvMX+lXgm 51hDMNY3Sw0Ikl2ujEMg3cosUeHuTxlVRo8XrNvYPSDbRd04ZQ6qHxRItUFTQXCRx/nd9a 3lw1bbqGLdOu4BHQgojdUARnmCRmZzU= X-MC-Unique: RNn1o_AYP7626sFnSx-wfw-1 X-Mimecast-MFC-AGG-ID: RNn1o_AYP7626sFnSx-wfw_1792757087 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792757087; x=1793361887; 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=ktFG9S7cIu86S66z6woz0uEJeRaYlQD7UfoTSNONZWI=; b=gB0P4livGXF736rxk7/1z4RfaMFv7Lpwpkct1Q15DIgg3uJmXRA+LpmFeL8OZAGGAD 0pSJxhSNAFDjQ2anV0lqih9gtrqU+E1cVQQzDyLm+niIn7VwSjOZ4ChHVFog0PkAdEee ptGVW2GDlb3haTTOmh/vR1Og+4XDaD1G8pbiOUOZStzIhjIYCsQP+hVJ5aSA3Zg4CL1M cte3rYUSZtvx4AMdpH8tFyRBclHiyw7SEHu/Drsc8QKwU7i0bXs7YWl+gO7fdz7i7z9V G4zlRcvCXgYg3d4p4cs98D6nfA6inIOzTUOzfBFLeIJ6Bzlx9Q8ua/M3J9Fxnjxm4Ci+ /qDg== X-Forwarded-Encrypted: i=1; AKwUvBwsuJPPyuKdOI3JkxBUrUwieeNGcfPVXVR6kRlJ6KdmXNkCLRYwywaKjCz1DVoHSOfUYMa9cw0fdU0=@lists.xenproject.org X-Gm-Message-State: AFq9FYL2rE3LncA0PPvzz11RiV8a9L4KFvDMZ3Q2IoxDWS3qssgL8bjb 2+ue5uaxZk6qpQLbM/emX9iBqkJwQmo0qxq6XKYmzuWt092nPRUhBbjYzY8k3wJpwIhUI2Cy9ig ubVH2Zog1/J54AlHGfADFJ3O7URXRSft42wi+SdTvikFAVmuHzgWNLp1ur7g37fbjgdrh X-Gm-Gg: AYBFou0Jf0C4A8k22MWL4DO2xbIBlpemp+BVUWXdbXqjDrexZ/l3/B0EoqctA/92ngJ Rfp8JKkPxsEpYLxpmonLDFLNrmqIpRiaP3IhLq7ocnBfNGmXCOG6lyTo4R1Q9rBJcJyFQRPaP0w boH9ShKp2a2RE8q1yzTva+XjJxFL+pk3FewZd1t2/yvKcg7MbqE9ecAHFx1kL4PZFnCYYYe07EK 0mRtofTYMIrPzZiGw69oLV87BMhVxqLq60IkMs0zbGqJdm/ynqb4hzu90QpcD3lVLqxV1u4stwS PpisLnzru+70qy7tiKT6cGsgwsOh5KlHrJOO1ieuIsZuUkqv6GddKxNGW+UjLKIlUjswr58= X-Received: by 2002:a05:6000:4a0a:b0:48e:1299:663f with SMTP id ffacd0b85a97d-48e385b0d95mr3400701f8f.56.1792757086768; Fri, 23 Oct 2026 05:04:46 -0700 (PDT) X-Received: by 2002:a05:6000:4a0a:b0:48e:1299:663f with SMTP id ffacd0b85a97d-48e385b0d95mr3400583f8f.56.1792757085931; Fri, 23 Oct 2026 05:04:45 -0700 (PDT) Date: Fri, 23 Oct 2026 08:04:36 -0400 From: "Michael S. Tsirkin" To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau Cc: Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , qemu-devel@nongnu.org, Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?iso-8859-1?Q?C=E9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?iso-8859-1?Q?C=E9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type Message-ID: <20261023072206-mutt-send-email-mst@kernel.org> References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Qx1QBoSGGKEhzTLDemWQri86wJSXDH2q13Y1MQwv9kw_1792757087 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1792757091-C30CDB50-DDC26F48/0/0 X-purgate-type: clean X-purgate-size: 3079 On Fri, Oct 23, 2026 at 03:39:22PM +0400, Marc-André Lureau wrote: > Hi > > On Fri, Oct 23, 2026 at 2:04 PM Daniel P. Berrangé wrote: > > > > On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-André Lureau wrote: > > > PciDevfn is a bit special, since it accepts integer and string as > > > setter, but only output integer as getter. > > > > > > Unfortunately, we can't declare an alternate str|int QAPI type for it, > > > since: branch 'string' can't be distinguished from 'integer' > > > > > > Rather than declaring it as "str", use the common type instead. > > > > > > Signed-off-by: Markus Armbruster > > > Signed-off-by: Marc-André Lureau > > > --- > > > hw/core/qdev-properties-system.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c > > > index 5bfdfe1ab9d9..3381de1144d6 100644 > > > --- a/hw/core/qdev-properties-system.c > > > +++ b/hw/core/qdev-properties-system.c > > > @@ -904,7 +904,8 @@ static char *print_pci_devfn(Object *obj, const Property *prop) > > > } > > > > > > const PropertyInfo qdev_prop_pci_devfn = { > > > - .type = "str", > > > + /* The formatted string accepted by the setter is a CLI convenience. */ > > > > IIUC, this is not limited to the CLI, it will work anywhere the JSON > > syntax is permitted which is both CLI and QMP. > > > > libvirt uses this string syntax: > > > > -device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2","bus":"pcie.0","multifunction":true,"addr":"0x1.0x1"}' \ > > > > > + .type = "int32", > > > .description = "Slot and optional function number, example: 06.0 or 06", > > > > > > Changing the type to 'int32', where 99% of usage is input only > > and string based, is pretty unpleasant. Even more so that the > > description doesn't even mention encoding dev+function as an > > integer. > > This is purely a metadata change, the setter still accepts both str & > int, so I don't think this change blocks this series. But I agree we > could do better. > > There are multiple options. We could keep declaring the property as > str instead. In this case, the getter should probably return a string > for consistency and correctness. This might surprise some existing > users though. > > We could introduce new properties like `devfn-str` and `devfn-int` > that alias the same value. > > We could also introduce a new structured QAPI type. > > Markus, what's your take? > > thanks I like the idea of a structured type. Will be handy for other things. > > > > > .print = print_pci_devfn, > > > .get = qdev_propinfo_get_int32, > > > > 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 Oct 23 19:27:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 19:27:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459180.1671424 (Exim 4.92) (envelope-from ) id 1xKKvV-0001u2-MX; Fri, 23 Oct 2026 19:27:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459180.1671424; Fri, 23 Oct 2026 19:27: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 1xKKvV-0001ts-IZ; Fri, 23 Oct 2026 19:27:41 +0000 Received: by outflank-mailman (input) for mailman id 1459180; Fri, 23 Oct 2026 11:39:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKDca-0002Wo-O9 for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 11:39:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKDca-008B5F-4J for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:39:40 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb4775-bab6-0a2a0a5309dd-0a2a4501aeba-32 for ; Fri, 23 Oct 2026 13:39:39 +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 6adb477a-5984-0a2a45010019-aa0a817ce147-3 for ; Fri, 23 Oct 2026 13:39:39 +0200 Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-617-loeKYFAsO7u3lfe1n9GFgA-1; Fri, 23 Oct 2026 07:39:36 -0400 Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-3ac76132001so696339a91.0 for ; Fri, 23 Oct 2026 04:39: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=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=1792755578; 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=BwZKJ1y9GJGdttliesnC6UNJffqn1NZdo/yH29SzxfQ=; b=Aqa7FbgG+y24GyAqMkXLrjublyxPemhdCvGAybNmKiR0JKJIM08rOFmhz8RUPT1S/oPtcE HvSEb2nUL8qJ9Ls9q2l3yzRH67H9Ig26L5X7U1MskK4yPoe81aDBWD8moPnxVR2Eb7K+dq zgiflRKszSi4EgaHr9Ory7liolUJzF8= X-MC-Unique: loeKYFAsO7u3lfe1n9GFgA-1 X-Mimecast-MFC-AGG-ID: loeKYFAsO7u3lfe1n9GFgA_1792755576 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792755576; x=1793360376; 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=BwZKJ1y9GJGdttliesnC6UNJffqn1NZdo/yH29SzxfQ=; b=CtgDB/K+zF6rC1cMOiEL3Kvy0bNDkO6lKP14dTT1yeuWTlkThdky0bPvcKmLXgJCsC 2ZmI64/5sxAZIHNoeP0XXWkjKAhFL3Qos5w+UGqap8jobwT1algxvW7YcpwfKTHRDPmM VhcnY51xc7CnrUxA2kIPPywG6fQJej/JK8qCBDfSc2XnWWw82eGDsElI3UM3+uFZDCg9 T7HMSJlai+5Avmm24CIGwjsyi378cFkMjMKN46toPvwgXs72mFhAdxPlTLd0+NvcwwfC E9bPvoEmvHLqXLQLJ4nQ1xiWbnfXwEmh4iJN17XAfJSorv+14tN7RlVY9s8DflGQ4xzW FD7g== X-Forwarded-Encrypted: i=1; AKwUvBw5zmUY9KaQWGuV6Knc6UQib5tud0z4UlrW+iHXJ7NC9FWGtdXNYqS+ZQha+1LiV7GgFO1dgEmbOUc=@lists.xenproject.org X-Gm-Message-State: AFq9FYJEVHPp1lHqa5skNIjHcb5Xyy3Y5chZoBxtSywVmaN/rsrfvZix O+szqJcrfKqR1vbwfjl3prjt9TbYAT8VEq3AqJ31/sBApLBNKb4IL4303mtXCEgPWRkUvec5U+P 1U7IqXUouvIN8RVwEI7wnr2vqzt4In7G70/z5vyjz2yZCsh+GdML4Pt4b0/dmg08k41gHB4FNgF CNFDI+kh8hl6foJ4qKU3ALw9NSM61Bd+2F2eR1SViwyt0= X-Gm-Gg: AYBFou3+1v7/6CzoeCzirNwkBTLt/ohRuRL/Er5jlUoAIBxXhYdt/dtvkGcq1ZTTL/X KPeLIMiiANjPkuhk3aD8zwyBhheuHW7EOdXNcWmvVutiKoXFMDJY0wQUoNVfi9qZ72c/WSs9mHY 1iOwE3Px6aXivPCPS0plq5GFWnDqEcb52ZyhnAybkGKBVAnwXvWvZy08HtanOndojXcf8XUv1Mw UIoi97/B+40ChT7jVfqlaa7MZnE2SyqgODZO7Olb3xhpz8Zf7hcH9Wn5767YaDdivZ1WGeg9P6c vQ== X-Received: by 2002:a17:90b:4d06:b0:3ac:ffb8:1809 with SMTP id 98e67ed59e1d1-3adce45dd72mr1525578a91.39.1792755575396; Fri, 23 Oct 2026 04:39:35 -0700 (PDT) X-Received: by 2002:a17:90b:4d06:b0:3ac:ffb8:1809 with SMTP id 98e67ed59e1d1-3adce45dd72mr1525520a91.39.1792755574796; Fri, 23 Oct 2026 04:39:34 -0700 (PDT) MIME-Version: 1.0 References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> In-Reply-To: From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Fri, 23 Oct 2026 15:39:22 +0400 X-Gm-Features: AclHuK9JciU6rOmPmxGP7LAL0cKom9fJOgwoGNnQZ4aTaCAv64YMDSwyPsEK5ck Message-ID: Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, Markus Armbruster , Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: r4RsJWxQfozpVUPVIOZfOwadISvpumVJwNP5L0fiElE_1792755576 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1792755579-BD87F757-F4D7F959/0/0 X-purgate-type: clean X-purgate-size: 2837 Hi On Fri, Oct 23, 2026 at 2:04=E2=80=AFPM Daniel P. Berrang=C3=A9 wrote: > > On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-Andr=C3=A9 Lureau wrote: > > PciDevfn is a bit special, since it accepts integer and string as > > setter, but only output integer as getter. > > > > Unfortunately, we can't declare an alternate str|int QAPI type for it, > > since: branch 'string' can't be distinguished from 'integer' > > > > Rather than declaring it as "str", use the common type instead. > > > > Signed-off-by: Markus Armbruster > > Signed-off-by: Marc-Andr=C3=A9 Lureau > > --- > > hw/core/qdev-properties-system.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties= -system.c > > index 5bfdfe1ab9d9..3381de1144d6 100644 > > --- a/hw/core/qdev-properties-system.c > > +++ b/hw/core/qdev-properties-system.c > > @@ -904,7 +904,8 @@ static char *print_pci_devfn(Object *obj, const Pro= perty *prop) > > } > > > > const PropertyInfo qdev_prop_pci_devfn =3D { > > - .type =3D "str", > > + /* The formatted string accepted by the setter is a CLI convenienc= e. */ > > IIUC, this is not limited to the CLI, it will work anywhere the JSON > syntax is permitted which is both CLI and QMP. > > libvirt uses this string syntax: > > -device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2","= bus":"pcie.0","multifunction":true,"addr":"0x1.0x1"}' \ > > > + .type =3D "int32", > > .description =3D "Slot and optional function number, example: 06.0= or 06", > > > Changing the type to 'int32', where 99% of usage is input only > and string based, is pretty unpleasant. Even more so that the > description doesn't even mention encoding dev+function as an > integer. This is purely a metadata change, the setter still accepts both str & int, so I don't think this change blocks this series. But I agree we could do better. There are multiple options. We could keep declaring the property as str instead. In this case, the getter should probably return a string for consistency and correctness. This might surprise some existing users though. We could introduce new properties like `devfn-str` and `devfn-int` that alias the same value. We could also introduce a new structured QAPI type. Markus, what's your take? thanks > > > .print =3D print_pci_devfn, > > .get =3D qdev_propinfo_get_int32, > > 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 Oct 23 19:27:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 19:27:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459130.1671419 (Exim 4.92) (envelope-from ) id 1xKKvV-0001rf-EF; Fri, 23 Oct 2026 19:27:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459130.1671419; Fri, 23 Oct 2026 19:27: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 1xKKvV-0001rY-Bb; Fri, 23 Oct 2026 19:27:41 +0000 Received: by outflank-mailman (input) for mailman id 1459130; Fri, 23 Oct 2026 10:54:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKCv4-0004pQ-3y for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 10:54:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKCv3-005Kpy-Gk for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 12:54:41 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb3ce3-8faa-0a2a0a5109dd-0a2a4507e456-38 for ; Fri, 23 Oct 2026 12:54:41 +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 6adb3cf0-b4ea-0a2a45070019-aa0a817cb833-3 for ; Fri, 23 Oct 2026 12:54:41 +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-599-ANvIGqWqN7OpnJEgondA-w-1; Fri, 23 Oct 2026 06:54:35 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 618EC19560B8; Fri, 23 Oct 2026 10:54:28 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8D153195608C; Fri, 23 Oct 2026 10:54:24 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 0B26921E6A04; Fri, 23 Oct 2026 12:54: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=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=1792752880; 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=X11SR+mruIiBcnKbbutBCQyUMtv+b/6VmMY3ImplTNE=; b=NxybvP/Q/0gjfNFstLBvUjAGnzsdblUZUNy1HKOhTZex3s9Q6YY36sfwWzd8flRaEv9yBV nmh5y7QUbPGyHZAjiUAErvEmO4kzaDDYjmBSnxrng93Gw5i7gzzONVhN+PKWfyeMfpQC5e bcN2JTBnSralgxqpyu68tJtUyaIYgnU= X-MC-Unique: ANvIGqWqN7OpnJEgondA-w-1 X-Mimecast-MFC-AGG-ID: ANvIGqWqN7OpnJEgondA-w_1792752871 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 10/65] meson: add qapi-type-infos-*.c/h to build In-Reply-To: <20261020-qom-qapi-v7-10-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:45:27 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-10-431a86b02b58@redhat.com> Date: Fri, 23 Oct 2026 12:54:21 +0200 Message-ID: <87ik2sg00y.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-MFC-PROC-ID: sFYQakt16P9lTdyDZfUKMEFoIIYxntCfgxAIr0OyFcU_1792752871 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1792752881-36CDFAE4-4BF2E4E4/0/0 X-purgate-type: clean X-purgate-size: 579 Marc-Andr=C3=A9 Lureau writes: > Add the per-module type-infos output files so they are compiled into > the build. > > Reviewed-by: Kostiantyn Kostiuk > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau I just messed with the previous commit, and nothing got recompiled even though I changed scripts/qapi/type_infos.py. Quite confusing, until I remembered that I also need this one for that. Let's squash it into the previous commit. From xen-devel-bounces@lists.xenproject.org Fri Oct 23 19:27:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 19:27:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459288.1671433 (Exim 4.92) (envelope-from ) id 1xKKvW-00021u-3D; Fri, 23 Oct 2026 19:27:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459288.1671433; Fri, 23 Oct 2026 19:27: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 1xKKvV-00020A-WA; Fri, 23 Oct 2026 19:27:41 +0000 Received: by outflank-mailman (input) for mailman id 1459288; Fri, 23 Oct 2026 13:47:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKFcF-00045o-Kz for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 13:47:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKFcF-00H1wJ-1u for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 15:47:27 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adb6561-bab6-0a2a0a5309dd-0a2a450abbf2-28 for ; Fri, 23 Oct 2026 15:47:26 +0200 Received: from [94.130.129.15] (helo=oxygen.pond.sub.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adb656e-f2d2-0a2a450a0019-5e82810f872a-3 for ; Fri, 23 Oct 2026 15:47:26 +0200 Received: from blackfin.pond.sub.org (p50902d79.dip0.t-ipconnect.de [80.144.45.121]) (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) (Client did not present a certificate) by oxygen.pond.sub.org (Postfix) with ESMTPSA id 5F19F1FFDF; Fri, 23 Oct 2026 15:47:24 +0200 (CEST) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 2402C21E6A04; Fri, 23 Oct 2026 15:47: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; none From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 09/65] qapi: add type-infos generator In-Reply-To: <20261020-qom-qapi-v7-9-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:45:26 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-9-431a86b02b58@redhat.com> Date: Fri, 23 Oct 2026 15:47:21 +0200 Message-ID: <87mrs4a5qu.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1792763246-5A3DCCFC-A8AB5D01/0/0 X-purgate-type: clean X-purgate-size: 14545 Marc-Andr=C3=A9 Lureau writes: > New QAPISchemaGenTypeInfoVisitor produces per-module > qapi-type-infos-*.h/c files. Each file declares QAPITypeInfo constants > pairing the QAPI type name with its masked introspection name. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau > --- > docs/devel/qapi-code-gen.rst | 92 ++++++++++++++++++++++++ > meson.build | 1 + > scripts/qapi/backend.py | 2 + > scripts/qapi/type_infos.py | 163 +++++++++++++++++++++++++++++++++++++= ++++++ > 4 files changed, 258 insertions(+) > > diff --git a/docs/devel/qapi-code-gen.rst b/docs/devel/qapi-code-gen.rst > index 77f08bb68cac..1cc5338a210a 100644 > --- a/docs/devel/qapi-code-gen.rst > +++ b/docs/devel/qapi-code-gen.rst > @@ -1250,6 +1250,9 @@ JSON array of strings. > To examine a type, start with a command or event using it, then follow > references by name. >=20=20 > +.. TODO document QOM introspection (qom-list, qom-list-properties, > + qom-get) and how it relates to QAPI type information. > + > The SchemaInfo for a command has meta-type "command", and variant > members "arg-type", "ret-type" and "allow-oob". On the wire, the > "arguments" member of a client's "execute" command must conform to the > @@ -2099,3 +2102,92 @@ Example:: > })); >=20=20 > [Uninteresting stuff omitted...] > + > + > +Code generated for type information > +----------------------------------- > + > +Type information is generated for user-defined types and their array > +types. With option --builtins, it is also generated for the built-in > +types. > + > +The following files are created: > + > + ``$(prefix)qapi-type-infos.c`` > + A ``QAPITypeInfo`` instance for each type listed above, providing > + a mapping between the QAPI type name and the masked name used by > + introspection, along with optional enum lookup table and array > + type pointers. > + > + ``$(prefix)qapi-type-infos.h`` > + Declarations for the above type info instances > + > +Each ``QAPITypeInfo`` struct has the following fields: > + > +``name`` > + The QAPI type name (e.g. ``"UserDefOne"``). > + > +``masked_name`` > + The masked name used in ``query-qmp-schema`` output. > + > +``lookup`` > + For enum types, a pointer to the corresponding ``QEnumLookup`` > + table. ``NULL`` for non-enum types. > + > +``list`` > + For types that have an array variant, a pointer to the array type's > + ``QAPITypeInfo``. ``NULL`` when no array type exists. > + > +These type info instances are used by QOM property registration > +functions (``object_property_add_qapi()``, > +``object_class_property_add_qapi_enum()``, etc.) to associate each > +property with its QAPI type. The ``qom-list`` and > +``device-list-properties`` QMP commands then expose the ``qapi-type`` > +field, giving management tools a formal type reference they can look > +up in the introspection schema. > + > +Example:: > + > + $ cat qapi-generated/example-qapi-type-infos.h > + [Uninteresting stuff omitted...] > + > + #ifndef EXAMPLE_QAPI_TYPE_INFOS_H > + #define EXAMPLE_QAPI_TYPE_INFOS_H > + > + #include "qapi/qapi-builtin-type-infos.h" > + > + extern const QAPITypeInfo UserDefOne_type_info; > + > + extern const QAPITypeInfo UserDefOneList_type_info; > + > + #endif /* EXAMPLE_QAPI_TYPE_INFOS_H */ > + $ cat qapi-generated/example-qapi-type-infos.c > + [Uninteresting stuff omitted...] > + > + const QAPITypeInfo UserDefOne_type_info =3D { > + .name =3D "UserDefOne", > + .masked_name =3D "1", Code generated right now has "32". Doesn't matter to readers, but using generated code verbatim eases maintenance a bit. > + .list =3D &UserDefOneList_type_info, > + }; > + > + const QAPITypeInfo UserDefOneList_type_info =3D { > + .name =3D "UserDefOneList", > + .masked_name =3D "[1]", Likewise. > + }; > + > + [Uninteresting stuff omitted...] > + > +For a modular QAPI schema (see section `Include directives`_), code for > +each sub-module SUBDIR/SUBMODULE.json is actually generated into :: > + > + SUBDIR/$(prefix)qapi-type-infos-SUBMODULE.h > + SUBDIR/$(prefix)qapi-type-infos-SUBMODULE.c > + > +If qapi-gen.py is run with option --builtins, additional files are > +created: > + > + ``qapi-builtin-type-infos.h`` > + Type info instances for built-in types > + > + ``qapi-builtin-type-infos.c`` > + Definitions for the above type info instances > diff --git a/meson.build b/meson.build > index bbef9d9c2932..e51fb7a37740 100644 > --- a/meson.build > +++ b/meson.build > @@ -3510,6 +3510,7 @@ qapi_gen_depends =3D [ meson.current_source_dir() /= 'scripts/qapi/__init__.py', > meson.current_source_dir() / 'scripts/qapi/parser.p= y', > meson.current_source_dir() / 'scripts/qapi/schema.p= y', > meson.current_source_dir() / 'scripts/qapi/source.p= y', > + meson.current_source_dir() / 'scripts/qapi/type_inf= os.py', > meson.current_source_dir() / 'scripts/qapi/types.py= ', > meson.current_source_dir() / 'scripts/qapi/visit.py= ', > meson.current_source_dir() / 'scripts/qapi-gen.py' > diff --git a/scripts/qapi/backend.py b/scripts/qapi/backend.py > index 49ae6ecdd33e..508ab2173539 100644 > --- a/scripts/qapi/backend.py > +++ b/scripts/qapi/backend.py > @@ -8,6 +8,7 @@ > from .features import gen_features > from .introspect import gen_introspect > from .schema import QAPISchema > +from .type_infos import gen_type_infos > from .types import gen_types > from .visit import gen_visit >=20=20 > @@ -63,3 +64,4 @@ def generate(self, > gen_commands(schema, output_dir, prefix, gen_tracing) > gen_events(schema, output_dir, prefix) > gen_introspect(schema, output_dir, prefix, unmask) > + gen_type_infos(schema, output_dir, prefix, builtins, unmask) > diff --git a/scripts/qapi/type_infos.py b/scripts/qapi/type_infos.py > new file mode 100644 > index 000000000000..b29e31d92640 > --- /dev/null > +++ b/scripts/qapi/type_infos.py > @@ -0,0 +1,163 @@ > +""" > +QAPI type info generator > + > +SPDX-License-Identifier: GPL-2.0-or-later > +""" > + > +from typing import List, Optional > + > +from .common import c_name, mcgen > +from .gen import QAPISchemaModularCVisitor, ifcontext > +from .schema import ( > + QAPISchema, > + QAPISchemaAlternatives, > + QAPISchemaBranches, > + QAPISchemaEnumMember, > + QAPISchemaFeature, > + QAPISchemaIfCond, > + QAPISchemaObjectType, > + QAPISchemaObjectTypeMember, > + QAPISchemaType, > +) > +from .source import QAPISourceInfo > + > + > +class QAPISchemaGenTypeInfoVisitor(QAPISchemaModularCVisitor): > + > + def __init__(self, prefix: str, unmask: bool): > + super().__init__( > + prefix, 'qapi-type-infos', > + ' * Schema-defined QAPI type info', > + ' * Built-in QAPI type info', __doc__) > + self._unmask =3D unmask > + self._schema: Optional[QAPISchema] =3D None > + > + def visit_begin(self, schema: QAPISchema) -> None: > + super().visit_begin(schema) > + self._schema =3D schema > + > + def _begin_builtin_module(self) -> None: > + self._genc.preamble_add(mcgen(''' > +#include "qemu/osdep.h" > +#include "qapi/qapi-builtin-types.h" > +#include "qapi/qapi-builtin-type-infos.h" > +''')) > + self._genh.preamble_add(mcgen(''' > +#include "qapi/qapi-type-info.h" > +''')) > + > + def _begin_user_module(self, name: str) -> None: > + type_infos =3D self._module_basename('qapi-type-infos', name) > + types =3D self._module_basename('qapi-types', name) > + self._genc.preamble_add(mcgen(''' > +#include "qemu/osdep.h" > +#include "%(types)s.h" > +#include "%(type_infos)s.h" > +''', > + types=3Dtypes, > + type_infos=3Dtype_infos)) > + self._genh.preamble_add(mcgen(''' > +#include "qapi/qapi-builtin-type-infos.h" > +''')) > + > + def _has_list(self, name: str) -> bool: > + assert self._schema is not None > + return self._schema.lookup_type(name + 'List') is not None Relies on QAPISchema._make_array_type()'s name =3D element_type + 'List' # reserved by check_defn_name_= str() Suggest to point to ._make_array_type() with a comment. There's another name + 'List' below, at [*]. One comment here could do, though. > + > + def _masked_name(self, name: str) -> str: > + assert self._schema is not None > + return self._schema.definition_introspection_name(name, self._un= mask) > + > + def _gen_type_info(self, name: str, > + ifcond: Optional[QAPISchemaIfCond] =3D None, > + with_lookup: bool =3D False, > + with_list: bool =3D False) -> None: > + c_id =3D c_name(name + '_type_info') > + masked_name_str =3D '"%s"' % self._masked_name(name) > + with ifcontext(ifcond or QAPISchemaIfCond(), > + self._genh, self._genc): > + self._genh.add(mcgen(''' > + > +extern const QAPITypeInfo %(c_id)s; > +''', > + c_id=3Dc_id)) > + self._genc.add(mcgen(''' > + > +const QAPITypeInfo %(c_id)s =3D { > + .name =3D "%(name)s", > + .masked_name =3D %(masked_name)s, > +''', > + c_id=3Dc_id, name=3Dname, > + masked_name=3Dmasked_name_str)) Simpler and clearer, I think: .masked_name =3D "%(masked_name)s", ... masked_name=3D self._masked_name(name)) > + if with_lookup: > + self._genc.add(mcgen(''' > + .lookup =3D &%(c_name)s_lookup, > +''', > + c_name=3Dc_name(name))) > + if with_list: > + self._genc.add(mcgen(''' > + .list =3D &%(list_id)s, > +''', > + list_id=3Dc_name(name + 'List_type_= info'))) [*] > + self._genc.add(mcgen(''' > +}; > +''')) Three variations of c_name(name maybe with suffix) in this function: c_name(name + '_type_info') c_name(name) c_name(name + 'List_type_info') Let's put just cname =3D c_name(name) at the beginning, and add the suffix within the template like we do in events.py, types.py, and visit.py, i.e. like this: self._genh.add(mcgen(''' extern const QAPITypeInfo %(cname)s_type_info; ''', cname=3Dcname)) > + > + def visit_builtin_type(self, > + name: str, > + info: Optional[QAPISourceInfo], > + json_type: str) -> None: > + self._gen_type_info(name, with_list=3Dself._has_list(name)) > + > + def visit_enum_type(self, > + name: str, > + info: Optional[QAPISourceInfo], > + ifcond: QAPISchemaIfCond, > + features: List[QAPISchemaFeature], > + members: List[QAPISchemaEnumMember], > + prefix: Optional[str]) -> None: > + self._gen_type_info(name, ifcond, > + with_lookup=3DTrue, > + with_list=3Dself._has_list(name)) > + > + def visit_array_type(self, > + name: str, > + info: Optional[QAPISourceInfo], > + ifcond: QAPISchemaIfCond, > + element_type: QAPISchemaType) -> None: > + self._gen_type_info(name, ifcond) > + > + def visit_object_type(self, > + name: str, > + info: Optional[QAPISourceInfo], > + ifcond: QAPISchemaIfCond, > + features: List[QAPISchemaFeature], > + base: Optional[QAPISchemaObjectType], > + members: List[QAPISchemaObjectTypeMember], > + branches: Optional[QAPISchemaBranches]) -> Non= e: > + assert self._schema is not None > + typ =3D self._schema.lookup_type(name) > + assert typ > + if typ.is_implicit(): > + return > + self._gen_type_info(name, ifcond, > + with_list=3Dself._has_list(name)) > + > + def visit_alternate_type(self, > + name: str, > + info: Optional[QAPISourceInfo], > + ifcond: QAPISchemaIfCond, > + features: List[QAPISchemaFeature], > + alternatives: QAPISchemaAlternatives) -> No= ne: > + self._gen_type_info(name, ifcond, > + with_list=3Dself._has_list(name)) All but one caller of ._gen_type_info() pass with_list=3Dself._has_list(name). The exception is visit_array_type(), where we let with_list default to False. Since .has_list(name) would surely be False there, we could do away with with_list and check ._has_list() in ._gen_type_info(). The array business complicates review of this patch and PATCH 07 a bit. It isn't actually needed until PATCH 59. I'd like you to delay it until then to get it out of the way here: * Create QAPITypeInfo without member @list in PATCH 07. * Don't generate member @list in PATCH 09. * Do both right before PATCH 59. Might also enable quicker merging of the bulk of this series. > + > + > +def gen_type_infos(schema: QAPISchema, > + output_dir: str, > + prefix: str, > + opt_builtins: bool, > + opt_unmask: bool) -> None: > + vis =3D QAPISchemaGenTypeInfoVisitor(prefix, opt_unmask) > + schema.visit(vis) > + vis.write(output_dir, opt_builtins) From xen-devel-bounces@lists.xenproject.org Fri Oct 23 20:45:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 20:45:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459670.1671465 (Exim 4.92) (envelope-from ) id 1xKM8t-0005hH-TK; Fri, 23 Oct 2026 20:45:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459670.1671465; Fri, 23 Oct 2026 20: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 1xKM8t-0005h9-Q9; Fri, 23 Oct 2026 20:45:35 +0000 Received: by outflank-mailman (input) for mailman id 1459670; Fri, 23 Oct 2026 20:45:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKM8s-0005h3-IN for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 20:45:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKM8r-007ANc-Ta for xen-devel@lists.xenproject.org; Fri, 23 Oct 2026 22:45:33 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adbc73e-8faa-0a2a0a5109dd-0a2a450c9546-18 for ; Fri, 23 Oct 2026 22:45:33 +0200 Received: from [52.101.52.67] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adbc76c-f479-0a2a450c0019-346534438153-4 for ; Fri, 23 Oct 2026 22:45:33 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BL1PR03MB6198.namprd03.prod.outlook.com (2603:10b6:208:31e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.19; Fri, 23 Oct 2026 20:45: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%4]) with mapi id 15.21.0546.017; Fri, 23 Oct 2026 20: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=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=TmfiXKHeoF8qoLPYnG5ksKXDlGv8vGBAsZF3CPU4eT0Tho7/9kCbR/uQXS2VfIth1jWbeoTtntVd1ng96Q2TjNk0Wc76hNQm5dD0OVrUjImnOjcUu0V8XEdYAFcxjmeJo7e/Vho7qaZO/387Lfuu6WdT6o0s16Lgxqy7GABJdxNzZS20/p3bzsyzgHpv1hevzEPi4GQSkAdHJi1ZiOwRD5zwXdMdz8X0VlxWPgu/9wDyjp2soBM4BZP6XyHl4MXEI90MhRH5b7kQ/iKiTEaag0YgyAqJeKpQF0ynBsmYPP1TpsTMY6sQE714VVSPsAQqF62dpzZ7/Q3BmvOVlBKpDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=I7PZkHn60XdeHX7oT1rGA0CwkzhY4drV+hn8lBp9BW4=; b=NuJjmbftTRkhMQZAoP0zbD5AYZLl8mbx4ptM3tZ21r33PgmMlLr9cKKKkXJIoLZwhHHcbQ4SbVBvXyOUWQ+yzFDsbTvoPz+v3WyCiXhLak2PPBNabfsRciBxKgqr3BD+lRI5/iliTJZ0zbJ0G3+joZaD12WwAblJxqVSIVFUP3zzNLq5NDJbs6F1Dj+9tl/yQcqPlP07y1PWWm97YNCz1AFXZWYOQ22u3ErhFjAz2UoVw6n5LLeKeMUMiZI/cME7gIFWkZw1HfIlARKNKwPE1FFymdlm3Wd+zEDiH9PYRQdK7jLqbrrt36HNAQRWLWYtDU2Nxew0V7vBTNBlsdPhRA== 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=I7PZkHn60XdeHX7oT1rGA0CwkzhY4drV+hn8lBp9BW4=; b=Mpti6Mnw7jNgvGzZFYzld/fUxov/yPFGSMth5BHUFes8PhqndGWfR8XIS1vYJ5vzv9ZlVLVK6DAZHkxhYjGN/OXILsR0OTjRORwhcM/Rre+HViorDBXJ/bqvP9bPm1quh7BSmG/jE7zX1s2u/6YnSTGb1GubpX7bm3o+9UbSdUI= 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, 23 Oct 2026 21:45:27 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: Teddy Astie , xen-devel@lists.xenproject.org References: <1792420048.8631fc262581453bbf619ec5b2062170.1a1548f6f6b0008425@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: <1792420048.8631fc262581453bbf619ec5b2062170.1a1548f6f6b0008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0443.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a9::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_|BL1PR03MB6198:EE_ X-MS-Office365-Filtering-Correlation-Id: c7582d9e-66c0-4c11-9bc3-08df314693ea X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|261022105027099003|56012099006|11063799006|5023799004|261021123027099003|261022075727099003|261021121427099003|261009223027099003|18002099003|22082099003|6133799003|10067099003; X-Microsoft-Antispam-Message-Info: UyRQETNfcdag7VECeHTr60lHmfpaj90O1KVi5npCOW7Me7dsE2EJwR/mmawQ9K1mlfLaT1/tBDnsOXyuQE7nfDJTkKDN8SQliSmNcpiOPh3nf1APU1hC3ilzgm6jbdnN9st+1+jaZjK8pESkiBG/3kxYrVf1EPRfJoI539C6XnhXaSibL3reU84Hxf/pa98u0S+TyGMAFy+iNqvl+06P2HT7t8mixdB2Ewz/CpDikN1igGhM++XByTPPPhK+QA05Zs7l6X3z36yXZ77AJ5sn6AoA8HeDW1W01CxEZoz+DhK645BHN8VsE4he/zXVdzFUL3gBsUPl1I8RK36ElVncSkZI2dLbVc+MR5ZT9QRYFBPLEZlgboi6dnS8nsGIWz4N6DtkhRpE1j6uKIMa5uh1KRB83VTSdHBkZ6E6jifkqRgidp7OGumT2K/K1mTyYAbkyM6fJBmOSeXxf8Qea5YY/x863ZZ71EKhugb/IQzbpuYLK0SK2wcX3iW8xVahqZbTyxJWWyd8RO5E3mxoNM0ta90J2sJhqbLpd4o3A6uFB9fOXLHah/jxUE+Ai4LyfYodUNgjI6mDvp+PLbuuSg+w6dDp3faS0j4mjk8zoY/JNuqxgpWqQyJXmjdt8z6sBThy8vaoM+B9WlJxiMmGu9In0KEX6rlGikL5DedCKT5y+9Q= 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)(366016)(23010399003)(261022105027099003)(56012099006)(11063799006)(5023799004)(261021123027099003)(261022075727099003)(261021121427099003)(261009223027099003)(18002099003)(22082099003)(6133799003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MExVSldvUnh0V1hQKy9QYjdnRFA5M0M1NFNZVmJvRWhKeklHNmxyekcydTRa?= =?utf-8?B?L1RPWVE1NVVFc0xpak9VNUdxM2UwbzJBU3RTc0QzL00zVm1OL1UrRHM3ZTht?= =?utf-8?B?M29ibGl4eGN1L3hBZldTRElPNmFXTzRCTG94QThkOFdacHJOSjRham5RK0p4?= =?utf-8?B?eGdHZzI5bEhiVndxcDNZaWVxajRhQkZVVzk4WGVHZzBWK3JXa1dvNklhczhq?= =?utf-8?B?bHBWNHRERFlaWjVJVmZDREFuWnRVYTZRZG9vNGMxaTZzNm56cjRwVHZlbys4?= =?utf-8?B?RTZEWlVXNncxZ1MwYS9CekdCK0pVMXlyVFNwaDdITVd4NmMvbUlhWi9idXZE?= =?utf-8?B?K0hrT1RhUExBdHFqcmF4cG92ZVBEcTA1dlY4RHlrdWNaUW0rSldSeE5XMHRG?= =?utf-8?B?VjROSkVIME5lMzNBcGpMMEZMazgveXl0N3BYa2hCanRiWjRLdzd4M0dkN013?= =?utf-8?B?UlVEVVdSOEY3T3p0MTNzN283a2pDcmozUTkzblJDTVFqRlFjUThreW16bVJF?= =?utf-8?B?WTlwS2Q5N202bHFtak1pRzRaQ01tY3lDcHEwMThMK2x6cXhIbjIrN05OejVX?= =?utf-8?B?Y0k5RnpxWEw2elJBRGROdXpkL3lvNnh2K0xMUDBYQ2lSMWlIQnpGZGxrWTNS?= =?utf-8?B?V0x3dTY2ampVWGxCUWVUWUJrcVI5R0p3anRXdW96UHEvY1VRMVB2bmxvQTZh?= =?utf-8?B?Q3Fidnc4MGJEZkhOSktmdG9pMGx5ZWpEa1h6OEVrVHp1SDJIWE1tQTFpVmZx?= =?utf-8?B?N0VFUlYvcVhNNUhBSFpPdTByVXRmeVdId1lSTC9LdXhNKzJUVjRoczdGaDlR?= =?utf-8?B?UkIxY0VOZVlBRGc3ZUhJRG5VL2d6aXJsZ2xqck9MV3h1WnZyV3FlZjg1Q1Nx?= =?utf-8?B?cmNCZWlNYjF0MEVSUTdSYUc3V1lkNE1oME40a0l4dElCUEZ2U2VJbG5yZ250?= =?utf-8?B?U2R6SitxeU9FWUVhS05XNm9Td29IbVBIWktDT3RkUWtuUkNmRklzODJJdTR1?= =?utf-8?B?OE1iWUhIenRYb2c5ak1IWTlnckI0T0ZReDU3Rk01UjJLN2puSUs5Tzk4UTg0?= =?utf-8?B?eC95RUYvcHVyTGlZMFpZRWZ0enlObTdWUHdjS3ZNTkQ5VE5RZVY5Zzh6OS9k?= =?utf-8?B?UmNsSUQwV2xzYUV0Yy9wUU45R3lUY0NldHViOFNPcUg0cmFlUGdvNDJNVXc4?= =?utf-8?B?d3IvNHc0RlBHdEZBZkhFSjV4Vk1zUmwvbHpuWUJyQzMxM1MwZTlpQkovNC9F?= =?utf-8?B?cGFzTi9yWlJSMlZHejNQc3ZqcElMdEQ0WGpKM0lWaTVUcWdlS0Z5MjI2OW54?= =?utf-8?B?Qmlxcy9QMUxyTUwxLzFBdDBmMFJXbHJrbE56aGZ3SjVlNGo5cU5Qb0s2N1dr?= =?utf-8?B?Q1BXVEpJdFFsUFo3Ry9DbG90cU9KKzlWUTFBbXJwK1RrSUw4M1orbmkrQklH?= =?utf-8?B?UUtRRWQrZEt3OEs5d0p4TTU0dksySDBBZjJmR3E0NjFLOTBXNmMrdzdpdy9n?= =?utf-8?B?Mit0UWJaUjJabmVHZ2R4ZTd1WlYyL1hpWXRpUnRKYmhGcnhyL0JBQktRR09j?= =?utf-8?B?bHdMdEYrWEUwTEFZaXhXVU9mTzNPcU5zZjhja0pOSnArcDRoMzhQOVhmejdX?= =?utf-8?B?UG5oRjUwNm5NcXd5NlpUREQ0SmtJTk5CQXhrd1JRVTFTRGZvMkNURS83YVVU?= =?utf-8?B?QWIzWUd2RnVDMHUzS2x1ZS9GY1N5Wk5yYXVJQU5Ec3gzdzlZWThJYTROME94?= =?utf-8?B?UDRWejN3MVJBbGhOK2VuVUlEdmN2OFR2cEJhS3loVUxhaWhvdW44YjdkaGJV?= =?utf-8?B?VmZDRWZtdFN0QnVDZ2pFNDliNjdOVUxHK3VnN3htNG52cGFNK2tOSEc5WXBT?= =?utf-8?B?Uks0Z1Z2TWs3Q01za3BWS2JudFZoODFyS2QzdmJoczZMZEJPUFREM1JVaGRI?= =?utf-8?B?bjhYOC9uN1pmcHVTdEVudi81aVFVeE15NUNUb3R6Z3BVdzI4dFZXczZ1UXpB?= =?utf-8?B?bUoyTXYvbFNnR0ZyT0dKTVJIWU51QjdISnN5bDQ4Tm8wTDBtbjREUmVRZm1a?= =?utf-8?B?Q25kb1F3c3FOVjNRcmVjTFIrWit5ZTduMWRpRE5wTnQ0ZUlUZWFNMmlRRE9z?= =?utf-8?B?Q05mRkNyL3RNTFgraEtBM1ArQ1JQc1F6K3NZTEFqd3BRR1FlbE82ZStSZTZr?= =?utf-8?B?dXcxSms5aHlmdnFiSU5JNC9qYWFRdThncnZXZFNOYisreG5JbU9JR3ZicGZk?= =?utf-8?B?WlZ3VU9INTVsLzkwR0QvRWRpQ0kzWDcxaVBldld0YXNQSHNnam9Xbk1EdTlK?= =?utf-8?B?WXhKR2JyVVRobU9MRzN4WG16cEJwL1pyRVVXQVAxSlhNL2FwcnlqdXZMYVR0?= =?utf-8?Q?63s9jgVZ8BocGnUU=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7582d9e-66c0-4c11-9bc3-08df314693ea X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 20:45:31.0929 (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: nvg/PFC58XGBsODdRvIaIqnIR/e8i/bgZeN50L30RwUPPnJTToGM0KjrerLbZxmM+1O6KqMFhjGgRGViwAVvuJhBIn9WHWuj/2TUgESuAmw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6198 X-purgate-ID: tlsNG-d25034/1792788333-5073FA5B-984118E6/0/0 X-purgate-type: clean X-purgate-size: 2699 On 19/10/2026 3:26 pm, Teddy Astie wrote: > The Intel SDM (Vol 3A-13.12.11, June 2026) says > >> The semantics of sending a self-IPI via the SELF IPI register >> are identical to sending a self targeted edge triggered fixed >> interrupt with the specified vector. > However, this is not expected to alter the ICR register. Having spoken to Intel, all Core/P-core's implement SELF_IPI using ICR, so do mutate the value. More recent Atom/E-core designs implement SELF_IPI differently, and do not mutate ICR.  From the testing I performed in Gitlab-CI, "More recent" is at least AlderLake and later, so Gracemont cores. Either way, this is conformation that both behaviours are legitimate, and it is certainly not a "bugfix" to change the behaviour. There might be enough reason to change the behaviour, as the Atom behaviour "feels" cleaner, and because it reduces the work we need to do in the SELF_IPI path, but a justification needs to be along these lines, not in terms of being a bugfix. Perhaps a better reason to make the change is because the VT-x architecture appears to not overwrite ICR, even on Core designs, and this would be a behavioural difference between APICV or not. > Fix the Xen behavior by sending the Self-IPI directly instead of > emulating it by modifying ICR register. > > Fixes: 21c4d089ba2a ("x86 hvm: x2APIC emulation") > Assisted-by: Claude Fable 5.1 > Signed-off-by: Teddy Astie > --- > Linux/KVM has a similar patch : > > KVM: x86: Do not change ICR on write to APIC_SELF_IPI > https://github.com/torvalds/linux/commit/d22a81b304a27fca6124174a8e842e826c193466 > > xen/arch/x86/hvm/vlapic.c | 21 ++++++++++++++++----- > 1 file changed, 16 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c > index 885f5d304b..bb105225e2 100644 > --- a/xen/arch/x86/hvm/vlapic.c > +++ b/xen/arch/x86/hvm/vlapic.c > @@ -963,6 +963,17 @@ static int cf_check vlapic_mmio_write( > return X86EMUL_OKAY; > } > > +/* > + * A write to the SELF IPI register sends a fixed, edge triggered IPI with > + * the given vector to the local APIC itself. Unlike an ICR write it doesn't > + * update the ICR, which is guest visible, in x2APIC mode even without any > + * intervention by Xen when APIC-register virtualization is in use. > + */ > +static void vlapic_self_ipi(struct vlapic *vlapic, uint32_t val) > +{ > + vlapic_ipi(vlapic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK), 0); > +} I'm not sure a wrapper is really worth it, but if you do care to continue with the patch, then you want a uint8_t vec here, and drop the mask. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Oct 23 21:07:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 21:07:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459691.1671475 (Exim 4.92) (envelope-from ) id 1xKMUA-0000Ax-MA; Fri, 23 Oct 2026 21:07:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459691.1671475; Fri, 23 Oct 2026 21:07: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 1xKMUA-0000Aq-Ij; Fri, 23 Oct 2026 21:07:34 +0000 Received: by outflank-mailman (input) for mailman id 1459691; Fri, 23 Oct 2026 21:07:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKMU8-0000Ak-Kt for xen-devel@lists.xen.org; Fri, 23 Oct 2026 21:07:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKMU7-009T51-RV for xen-devel@lists.xen.org; Fri, 23 Oct 2026 23:07:31 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adbcc58-2eae-0a2a0a5409dd-0a2a45069a36-26 for ; Fri, 23 Oct 2026 23:07:31 +0200 Received: from [136.243.217.222] (helo=mail.cortex-media.de) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adbcc8e-195a-0a2a45060019-88f3d9dea0d4-3 for ; Fri, 23 Oct 2026 23:07:26 +0200 Received: by mail.cortex-media.de (Postfix) id 0281238C02F; Fri, 23 Oct 2026 23:07:25 +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=20250930 header.d=cortex-media.de header.i="@cortex-media.de" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cortex-media.de; s=20250930; t=1792789646; bh=I81YkilJDSJzXJyKg6uTKnQGfb5yIohX81B5+L7ihoM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=oeJTHc6xJS8psZzGXkZ8PpnTt+a1sYuEbgtRSDWE/unquP0jkKg7v3tO1wpYN1bMM ypEPFKdYIBbTnIpEZaefcswAtozM+2qk/AHTI6EC82MLRyP5GuQ5z+Gjzhxc8MdmcN q27v3hhDbx71cY0WIGRhe1Z67CJ+PdxRQ1rBsn58kGeZmoWdwptCdLyHaLihBlyLZL vvGBbnx4pbtKvM8xoSDrWx67do7cdEuMVQGh3fdNy6XWpoIvzmDGkuqzbo3sxRFRBS /bw2ICDn3VxcP2YU3l4pQflqIBWPfxcCpVpmm+iNZfxnURNpYepGnNzOnIbJiYViOn 5D5gUN4hib+Yw== Message-ID: Date: Fri, 23 Oct 2026 23:07:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Andrew Cooper , xen-devel@lists.xen.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Soham Dandapat References: From: Peter Deggendorfer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1792789651-F6A7477B-600F3D03/0/0 X-purgate-type: clean X-purgate-size: 6453 Hi Andrew, Thanks a lot for the quick response. > On 23/10/2026 8:32 am, Peter Deggendorfer wrote: >> Hey Xen Team, >> >> I'm hitting a reproducible hypervisor panic in the AMD non-fatal MCE >> polling path on a Ryzen 9 5950X (Zen 3). Eight occurrences since >> 2026-09-09, between 12 hours and 2 weeks apart, always CPU 2. >> >> Environment >> ----------- >> Xen:   4.20.4-pre (Debian 4.20.3+127-gc42374a105-0+deb13u1), and still >>        present in 4.20.5-pre (Debian 4.20.4+39-gf1e1321c87-0+deb13u1) >> dom0:  Linux 6.12.111+deb13-amd64 (Debian trixie), PV, 32 vCPUs >> CPU:   AMD Family 25 (0x19) Model 33 (0x21) Stepping 2, Ryzen 9 5950X, >>        microcode 0x0a201210 >> Cmdline: dom0_mem=4096M,max:4096M ucode=scan console_timestamps=datems >> >> The panic >> --------- >> (XEN) [2026-10-19 08:58:18.727] Xen BUG at >> arch/x86/cpu/mcheck/mce_amd.c:100 >> (XEN) CPU:    2 >> (XEN) RIP:    e008:[] >> mce_amd.c#mc_ec2type.part.0+0/0x10 >> (XEN) rbx: 0000000000000445   r12: 0000000000000011   r15: >> 0000000000000446 >> (XEN) Xen code around : >> (XEN)  90 90 90 90 90 90 90 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 >> 90 90 >> (XEN) Xen call trace: >> (XEN)    [] R mce_amd.c#mc_ec2type.part.0+0/0x10 >> (XEN)    [] S mc_amd_recoverable_scan+0x39/0x40 >> (XEN)    [] S mcheck_mca_logout+0x42d/0x840 >> (XEN)    [] S >> amd_nonfatal.c#mce_amd_checkregs+0x1c/0x100 >> (XEN)    [] S smp_call_function_interrupt+0x4c/0x90 >> (XEN)    [] S do_IRQ+0x2a5/0x650 >> (XEN)    [] S common_interrupt+0x135/0x150 >> (XEN)    [] S cpu_idle.c#acpi_idle_do_entry+0x8a/0x140 >> (XEN)    [] S >> cpu_idle.c#acpi_processor_idle+0x1ef/0x650 >> (XEN)    [] S domain.c#idle_loop+0xc1/0x130 >> (XEN) Panic on CPU 2 >> >> The outlined mc_ec2type.part.0 contains nothing but the ud2, so this is >> the "unreachable" default branch of mc_ec2type() -- the extended error >> code matches none of MC_EC_TLB_TYPE, MC_EC_MEM_TYPE, MC_EC_BUS_TYPE. > I think it's safe to just drop the BUG(). > > That code is literally worse than useless, because if nothing else it's > just hiding the diagnostics. > > I guess it means AMD have added new statuses. > >> Across the eight occurrences, r12 appears to be the bank index from the >> loop in mcheck_mca_logout(), with rbx == 0x401 + 4 * r12 (MCi_STATUS) >> and r15 == rbx + 1. Three different banks are involved: 10, 17 and 23. >> >> Not a hardware defect >> --------------------- >> - Started within days of upgrading two hosts from Debian bookworm >>   (Xen 4.17) to trixie (Xen 4.20). They had run 3 years on 4.17 with no >>   incident. >> - Three different banks, so not a single failing block. >> - Updating to the current Debian package (4.20.5-pre, built 2026-10-16) >>   changed nothing. >> >> Possibly related: 532988dccc19 ("x86/mcheck: fix mca_allbanks >> updating"). >> >> Also possibly related on the Linux side: 0422b07bc4c2 ("x86/mce/amd: >> Filter bogus hardware errors on Zen3 clients"), where bogus MCA values >> on Zen 3 are filtered rather than treated as errors. >> https://ratatoskr.run/stable/2026/04/7143905 > From above, you're on a Vermeer, not a Cezanne, so I don't think that > Linux patch is relevant. > > However, your observation about "fix mca_allbanks updating" quite > possibly is.  That was backported into Xen 4.20.1 as 247b708b1400a, and > Debian has 4.20.3 > > Are you able to experiment with that patch reverted? > > Alternatively, are you able to experiment with the BUG() removed? I went with dropping the BUG() rather than the revert. Reverting 247b708b1400a should stop any bank from being read at all, which is effectively what mce=false already does here, so I don't expect it to tell us anything new. I'll run it too if you'd like. I'm not familiar with the Xen codebase, but I've built a package with mc_ec2type() changed to:     if ( errorcode & MC_EC_TLB_TYPE )         return MC_EC_TLB_TYPE;     printk(XENLOG_WARNING "MCE: unknown AMD error code %#x\n", errorcode);     return 0; Crashes have been 12 hours to 2 weeks apart, so it may take a while before I can report back. >> Diagnostics / workaround >> ------------------------ >> mce_verbosity=verbose yields nothing useful. >> max_cstate=1 made no difference. mce=false is the only thing that stops >> it, and it is what I'm running now. > The fact that mce=false isn't causing machine resets means it's clearly > something the hardware thinks isn't fatal. > > But, I am concerned by the fact it's always on CPU 2, and multiple > banks.  Is this true for both systems? To clarify one thing from my report: it is actually a single host whose complete hardware (board, CPU, RAM) was replaced on 2026-10-07, keeping only the disks and thus the installation. The crashes happened both before and after that swap. 10 more hosts with same hardware still run on bookworm (xen 4.17) for years now without any incidents. So yes, always CPU 2. The bank index varies: on the current hardware I have seen banks 23, 17 and 10 across four crashes, and banks 23 and 17 on the previous hardware. >> One more thing: the host does not actually reboot after the panic. >> "Reboot in five seconds" is printed, but the ring buffer continues with >> normal activity minutes later and the remaining 31 CPUs keep running. >> CPU 2 stays wedged, and "xl debug-keys t" then hangs. Afterwards dom0 >> and guest vCPUs start losing timer interrupts permanently (RCU stalls >> with a frozen timer-softirq count while dynticks keeps advancing), so >> VMs hang silently hours or days later. > I've recently noticed that crashing with interrupts off doesn't reboot > any more.  I thought it was something local to my development, but > apparently not if you're seeing the same. > >> >> I've attached the full xl dmesg log of the last crash, and I'm happy >> to provide more if needed. I can also test patches. >> >> Thanks for your work, and thanks in advance for taking a look. >> >> Peter > Thankyou, > > ~Andrew I have full xl dmesg logs for almost all crashes. Happy to send any of them. Peter From xen-devel-bounces@lists.xenproject.org Fri Oct 23 23:52:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Oct 2026 23:52:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459760.1671484 (Exim 4.92) (envelope-from ) id 1xKP3A-0003Zg-RI; Fri, 23 Oct 2026 23:51:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459760.1671484; Fri, 23 Oct 2026 23:51: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 1xKP3A-0003ZY-NQ; Fri, 23 Oct 2026 23:51:52 +0000 Received: by outflank-mailman (input) for mailman id 1459760; Fri, 23 Oct 2026 23:51:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKP38-0003ZS-QY for xen-devel@lists.xen.org; Fri, 23 Oct 2026 23:51:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKP37-006w85-St for xen-devel@lists.xen.org; Sat, 24 Oct 2026 01:51:49 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adbf297-bab6-0a2a0a5309dd-0a2a45098b6e-46 for ; Sat, 24 Oct 2026 01:51:49 +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 6adbf315-be1a-0a2a45090019-b9ff1c239191-3 for ; Sat, 24 Oct 2026 01:51: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-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a16b2d7d1b000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 23 Oct 2026 23:51:45 +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 EEB24832EA; Sat, 24 Oct 2026 01:51: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: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=t12f/kfcIuS1UuvlAAZxEViATrpNcezPK1lXDq1jo2E=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references:feedback-id; b=M2vGRv4NmbcAlKStAOPy1u7f/qT933dP20a32IAYI6tQlTxG2ibq0xa6r6ldJwUwrgtLeiycN qKlWj1belXU2EloayTfOer5zR/mZcyT6RNbdS4LR+d50PDR0dj3QmO34g7ADjkDTVbieCSTb6Xp ts3EgF3kUKt8x1IjjysurnTptzn0MjxPo7mUxPk3jadMde5PJYeAbO/hSlrg6VJ3I05KBU3I5/I FiucyiFL/eWVnLTkmxKHUEILX3EwKvx+niTy5CxiAkMA5wlcbgXPguaPA5lUJ3ZtOM4oJyvg/ZM UfNIi+oUZkDI1SVhmvvDOe8F7/3Rd8qwpNyVEpvndjZA== X-Zone-Loop: 77e2b26aa9bc97a31ab9dc03eb913de7b2037acdd1c4 x-campaign-type: default x-transaction-id: 78f5c49d-f7aa-4786-a4e4-8eeb2b215132 x-swg-uid: 01-5beb4dc9-497d-470c-88fa-8b0ee6f5657f X-Mailer: Sweego Message-ID: <1792799505.8631fc262581453bbf619ec5b2062170.1a16b2d7d1b000f79f@vates.tech> x-swg-bid: 1792799505.8631fc262581453bbf619ec5b2062170.1a16b2d7d1b000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Sat, 24 Oct 2026 01:51:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Peter Deggendorfer , xen-devel@lists.xen.org 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="------------HPs9k0OqWo0pZdNOODfPs53f" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792799504065 X-purgate-ID: tlsNG-bad1c0/1792799509-BD0CD034-2BB586DC/0/0 X-purgate-type: clean X-purgate-size: 10817 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------HPs9k0OqWo0pZdNOODfPs53f Content-Type: multipart/mixed; boundary="------------OdHE2kakfN399lAiUZJYVsx5"; protected-headers="v1"; hp="clear" Message-ID: Date: Sat, 24 Oct 2026 01:51:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Peter Deggendorfer , xen-devel@lists.xen.org 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: --------------OdHE2kakfN399lAiUZJYVsx5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjMvMTAvMjAyNiDDoCAxMjoyMCwgUGV0ZXIgRGVnZ2VuZG9yZmVyIGEgw6ljcml0wqA6 DQo+IEhleSBYZW4gVGVhbSwNCj4gDQo+IEknbSBoaXR0aW5nIGEgcmVwcm9kdWNpYmxlIGh5 cGVydmlzb3IgcGFuaWMgaW4gdGhlIEFNRCBub24tZmF0YWwgTUNFDQo+IHBvbGxpbmcgcGF0 aCBvbiBhIFJ5emVuIDkgNTk1MFggKFplbiAzKS4gRWlnaHQgb2NjdXJyZW5jZXMgc2luY2UN Cj4gMjAyNi0wOS0wOSwgYmV0d2VlbiAxMiBob3VycyBhbmQgMiB3ZWVrcyBhcGFydCwgYWx3 YXlzIENQVSAyLg0KPiANCj4gRW52aXJvbm1lbnQNCj4gLS0tLS0tLS0tLS0NCj4gWGVuOsKg IMKgNC4yMC40LXByZSAoRGViaWFuIDQuMjAuMysxMjctZ2M0MjM3NGExMDUtMCtkZWIxM3Ux KSwgYW5kIHN0aWxsDQo+ICDCoCDCoCDCoCDCoHByZXNlbnQgaW4gNC4yMC41LXByZSAoRGVi aWFuIDQuMjAuNCszOS1nZjFlMTMyMWM4Ny0wK2RlYjEzdTEpDQo+IGRvbTA6wqAgTGludXgg Ni4xMi4xMTErZGViMTMtYW1kNjQgKERlYmlhbiB0cml4aWUpLCBQViwgMzIgdkNQVXMNCj4g Q1BVOsKgIMKgQU1EIEZhbWlseSAyNSAoMHgxOSkgTW9kZWwgMzMgKDB4MjEpIFN0ZXBwaW5n IDIsIFJ5emVuIDkgNTk1MFgsDQo+ICDCoCDCoCDCoCDCoG1pY3JvY29kZSAweDBhMjAxMjEw DQo+IENtZGxpbmU6IGRvbTBfbWVtPTQwOTZNLG1heDo0MDk2TSB1Y29kZT1zY2FuIGNvbnNv bGVfdGltZXN0YW1wcz1kYXRlbXMNCj4gDQo+IFRoZSBwYW5pYw0KPiAtLS0tLS0tLS0NCj4g KFhFTikgWzIwMjYtMTAtMTkgMDg6NTg6MTguNzI3XSBYZW4gQlVHIGF0IGFyY2gveDg2L2Nw dS9tY2hlY2svIA0KPiBtY2VfYW1kLmM6MTAwDQo+IChYRU4pIENQVTrCoCDCoCAyDQo+IChY RU4pIFJJUDrCoCDCoCBlMDA4Ols8ZmZmZjgyZDA0MDI4YTY1MD5dIG1jZV9hbWQuYyNtY19l YzJ0eXBlLnBhcnQuMCswLzB4MTANCj4gKFhFTikgcmJ4OiAwMDAwMDAwMDAwMDAwNDQ1wqAg wqByMTI6IDAwMDAwMDAwMDAwMDAwMTHCoCDCoHIxNTogMDAwMDAwMDAwMDAwMDQ0Ng0KPiAo WEVOKSBYZW4gY29kZSBhcm91bmQgPGZmZmY4MmQwNDAyOGE2NTA+Og0KPiAoWEVOKcKgIDkw IDkwIDkwIDkwIDkwIDkwIDkwIDkwIDwwZj4gMGIgOTAgOTAgOTAgOTAgOTAgOTAgOTAgOTAg OTAgOTAgOTAgOTANCj4gKFhFTikgWGVuIGNhbGwgdHJhY2U6DQo+IChYRU4pwqAgwqAgWzxm ZmZmODJkMDQwMjhhNjUwPl0gUiBtY2VfYW1kLmMjbWNfZWMydHlwZS5wYXJ0LjArMC8weDEw DQo+IChYRU4pwqAgwqAgWzxmZmZmODJkMDQwMjhhNjk5Pl0gUyBtY19hbWRfcmVjb3ZlcmFi bGVfc2NhbisweDM5LzB4NDANCj4gKFhFTinCoCDCoCBbPGZmZmY4MmQwNDAyOGNmZGQ+XSBT IG1jaGVja19tY2FfbG9nb3V0KzB4NDJkLzB4ODQwDQo+IChYRU4pwqAgwqAgWzxmZmZmODJk MDQwMjhhMzVjPl0gUyBhbWRfbm9uZmF0YWwuYyNtY2VfYW1kX2NoZWNrcmVncysweDFjLzB4 MTAwDQo+IChYRU4pwqAgwqAgWzxmZmZmODJkMDQwMjQwZThjPl0gUyBzbXBfY2FsbF9mdW5j dGlvbl9pbnRlcnJ1cHQrMHg0Yy8weDkwDQo+IChYRU4pwqAgwqAgWzxmZmZmODJkMDQwMzEy M2Q1Pl0gUyBkb19JUlErMHgyYTUvMHg2NTANCj4gKFhFTinCoCDCoCBbPGZmZmY4MmQwNDAy MDE5MTU+XSBTIGNvbW1vbl9pbnRlcnJ1cHQrMHgxMzUvMHgxNTANCj4gKFhFTinCoCDCoCBb PGZmZmY4MmQwNDAyODgzY2E+XSBTIGNwdV9pZGxlLmMjYWNwaV9pZGxlX2RvX2VudHJ5KzB4 OGEvMHgxNDANCj4gKFhFTinCoCDCoCBbPGZmZmY4MmQwNDAyODg3Y2Y+XSBTIGNwdV9pZGxl LmMjYWNwaV9wcm9jZXNzb3JfaWRsZSsweDFlZi8weDY1MA0KPiAoWEVOKcKgIMKgIFs8ZmZm ZjgyZDA0MDMwMmNmMT5dIFMgZG9tYWluLmMjaWRsZV9sb29wKzB4YzEvMHgxMzANCj4gKFhF TikgUGFuaWMgb24gQ1BVIDINCj4gDQo+IFRoZSBvdXRsaW5lZCBtY19lYzJ0eXBlLnBhcnQu MCBjb250YWlucyBub3RoaW5nIGJ1dCB0aGUgdWQyLCBzbyB0aGlzIGlzDQo+IHRoZSAidW5y ZWFjaGFibGUiIGRlZmF1bHQgYnJhbmNoIG9mIG1jX2VjMnR5cGUoKSAtLSB0aGUgZXh0ZW5k ZWQgZXJyb3INCj4gY29kZSBtYXRjaGVzIG5vbmUgb2YgTUNfRUNfVExCX1RZUEUsIE1DX0VD X01FTV9UWVBFLCBNQ19FQ19CVVNfVFlQRS4NCj4gDQo+IEFjcm9zcyB0aGUgZWlnaHQgb2Nj dXJyZW5jZXMsIHIxMiBhcHBlYXJzIHRvIGJlIHRoZSBiYW5rIGluZGV4IGZyb20gdGhlDQo+ IGxvb3AgaW4gbWNoZWNrX21jYV9sb2dvdXQoKSwgd2l0aCByYnggPT0gMHg0MDEgKyA0ICog cjEyIChNQ2lfU1RBVFVTKQ0KPiBhbmQgcjE1ID09IHJieCArIDEuIFRocmVlIGRpZmZlcmVu dCBiYW5rcyBhcmUgaW52b2x2ZWQ6IDEwLCAxNyBhbmQgMjMuDQo+IA0KPiBOb3QgYSBoYXJk d2FyZSBkZWZlY3QNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0gU3RhcnRlZCB3aXRo aW4gZGF5cyBvZiB1cGdyYWRpbmcgdHdvIGhvc3RzIGZyb20gRGViaWFuIGJvb2t3b3JtDQo+ ICDCoCAoWGVuIDQuMTcpIHRvIHRyaXhpZSAoWGVuIDQuMjApLiBUaGV5IGhhZCBydW4gMyB5 ZWFycyBvbiA0LjE3IHdpdGggbm8NCj4gIMKgIGluY2lkZW50Lg0KPiAtIFRocmVlIGRpZmZl cmVudCBiYW5rcywgc28gbm90IGEgc2luZ2xlIGZhaWxpbmcgYmxvY2suDQo+IC0gVXBkYXRp bmcgdG8gdGhlIGN1cnJlbnQgRGViaWFuIHBhY2thZ2UgKDQuMjAuNS1wcmUsIGJ1aWx0IDIw MjYtMTAtMTYpDQo+ICDCoCBjaGFuZ2VkIG5vdGhpbmcuDQo+IA0KPiBQb3NzaWJseSByZWxh dGVkOiA1MzI5ODhkY2NjMTkgKCJ4ODYvbWNoZWNrOiBmaXggbWNhX2FsbGJhbmtzDQo+IHVw ZGF0aW5nIikuDQo+IA0KPiBBbHNvIHBvc3NpYmx5IHJlbGF0ZWQgb24gdGhlIExpbnV4IHNp ZGU6IDA0MjJiMDdiYzRjMiAoIng4Ni9tY2UvYW1kOg0KPiBGaWx0ZXIgYm9ndXMgaGFyZHdh cmUgZXJyb3JzIG9uIFplbjMgY2xpZW50cyIpLCB3aGVyZSBib2d1cyBNQ0EgdmFsdWVzDQo+ IG9uIFplbiAzIGFyZSBmaWx0ZXJlZCByYXRoZXIgdGhhbiB0cmVhdGVkIGFzIGVycm9ycy4N Cj4gaHR0cHM6Ly9yYXRhdG9za3IucnVuL3N0YWJsZS8yMDI2LzA0LzcxNDM5MDUNCj4gDQo+ IERpYWdub3N0aWNzIC8gd29ya2Fyb3VuZA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gbWNlX3ZlcmJvc2l0eT12ZXJib3NlIHlpZWxkcyBub3RoaW5nIHVzZWZ1bC4NCj4gbWF4 X2NzdGF0ZT0xIG1hZGUgbm8gZGlmZmVyZW5jZS4gbWNlPWZhbHNlIGlzIHRoZSBvbmx5IHRo aW5nIHRoYXQgc3RvcHMNCj4gaXQsIGFuZCBpdCBpcyB3aGF0IEknbSBydW5uaW5nIG5vdy4N Cj4gDQo+IE9uZSBtb3JlIHRoaW5nOiB0aGUgaG9zdCBkb2VzIG5vdCBhY3R1YWxseSByZWJv b3QgYWZ0ZXIgdGhlIHBhbmljLg0KPiAiUmVib290IGluIGZpdmUgc2Vjb25kcyIgaXMgcHJp bnRlZCwgYnV0IHRoZSByaW5nIGJ1ZmZlciBjb250aW51ZXMgd2l0aA0KPiBub3JtYWwgYWN0 aXZpdHkgbWludXRlcyBsYXRlciBhbmQgdGhlIHJlbWFpbmluZyAzMSBDUFVzIGtlZXAgcnVu bmluZy4NCj4gQ1BVIDIgc3RheXMgd2VkZ2VkLCBhbmQgInhsIGRlYnVnLWtleXMgdCIgdGhl biBoYW5ncy4gQWZ0ZXJ3YXJkcyBkb20wDQo+IGFuZCBndWVzdCB2Q1BVcyBzdGFydCBsb3Np bmcgdGltZXIgaW50ZXJydXB0cyBwZXJtYW5lbnRseSAoUkNVIHN0YWxscw0KPiB3aXRoIGEg ZnJvemVuIHRpbWVyLXNvZnRpcnEgY291bnQgd2hpbGUgZHludGlja3Mga2VlcHMgYWR2YW5j aW5nKSwgc28NCj4gVk1zIGhhbmcgc2lsZW50bHkgaG91cnMgb3IgZGF5cyBsYXRlci4NCj4g DQo+IA0KPiBJJ3ZlIGF0dGFjaGVkIHRoZSBmdWxsIHhsIGRtZXNnIGxvZyBvZiB0aGUgbGFz dCBjcmFzaCwgYW5kIEknbSBoYXBweQ0KPiB0byBwcm92aWRlIG1vcmUgaWYgbmVlZGVkLiBJ IGNhbiBhbHNvIHRlc3QgcGF0Y2hlcy4NCj4gDQo+IFRoYW5rcyBmb3IgeW91ciB3b3JrLCBh bmQgdGhhbmtzIGluIGFkdmFuY2UgZm9yIHRha2luZyBhIGxvb2suDQo+IA0KPiBQZXRlcg0K DQpDb3VsZCBiZSByZWxhdGVkLiBJIGp1c3Qgb2JzZXJ2ZWQgYSBteXN0ZXJpb3VzIG1jZSBy ZXBvcnQgb24gbXkgTGludXggDQpzeXN0ZW0gZG1lc2cgKFplbiAzIENQVSBhcyB3ZWxsLCBS eXplbiA3IDU3MDBYM0QpDQoNCj4gWzM5MjMwLjQ4MTgwOV0gW0hhcmR3YXJlIEVycm9yXTog U3lzdGVtIEZhdGFsIGVycm9yLg0KPiBbMzkyMzAuNDgxODEzXSBbSGFyZHdhcmUgRXJyb3Jd OiBDUFU6MSAoMTk6MjE6MikgTUMxMl9TVEFUVVNbT3ZlcnxVRXxNaXNjVnxBZGRyVnxQQ0N8 U3luZFZ8VUVDQ3xEZWZlcnJlZHxQb2lzb258U2NydWJdOiAweGZmZmZmZmZmYjg2MTY4OTAN Cj4gWzM5MjMwLjQ4MTgyM10gW0hhcmR3YXJlIEVycm9yXTogRXJyb3IgQWRkcjogMHgwMDAw MDAwMDAwMDAwMDAwDQo+IFszOTIzMC40ODE4MjVdIFtIYXJkd2FyZSBFcnJvcl06IElQSUQ6 IDB4MDAwMDAwMDAwMDAwMDAwMCwgU3luZHJvbWU6IDB4MDAwMDAwMDAwMDAwMDAwMA0KPiBb MzkyMzAuNDgxODMwXSBbSGFyZHdhcmUgRXJyb3JdOiBCYW5rIDEyIGlzIHJlc2VydmVkLg0K PiBbMzkyMzAuNDgxODMyXSBbSGFyZHdhcmUgRXJyb3JdOiBjYWNoZSBsZXZlbDogUkVTViwg dHg6IElOU04NCg0KSXQgc2VlbXMgdG8gYmUgbm9uLXNlbnNlLCBhbmQgdGhlIHN5c3RlbSBp cyBzdGlsbCB1cCBhcyBpZiBub3RoaW5nIA0KaGFwcGVuZWQuIE5vICNNQyBnb3QgZW1pdHRl ZC4NCg0KVGVkZHkNCg== --------------OdHE2kakfN399lAiUZJYVsx5-- --------------HPs9k0OqWo0pZdNOODfPs53f 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+p0QLLz9AFAmrb8w8FAwAAAAAACgkQZg+p0QLLz9Bz LAwAhmaPo8n7iu56ZRT2uBL5xu4VlWSgl88dUlfr4PlOWwOMis8qMXV/1kLNOG/eslmOMmYMTxlh zK+mZv0va+T0RPFwffrOv4+h0oLYsD1RqygO/FOUeEgmXDsV5OWhQYsl1eupEMyP0V7tCJ8QVKqu LkScv9vufhl7S1MFiiPnmkGNwiYabhvNnM8a8Vp2ri/UoRR7aDFJfmocWkAgq2lanzONP3GJ/LuV 08L6KBKMJt18B1cfRgNqzSF+AeRKjFV9ukigtLEo7zPTNCOV1XBifovkIh4ypiwDuYVrMa+IPwT7 t5AVM0L1z2tac+cBRLZ/Qcat4KJ9ifucead6sWsmSulRkK0DyA0WVOzhbg3wfASL6r7ek/UyoGlS Q+7AAW+qACtzvo1m7s+uucS+1ad9gjQF8tU34pAYsbHZcywXINxJCIls57gsNN5+t+Y0PsYwByDf u/rnlgBTRz6YKEjFaDVIsJ+hf/usD0HRgAglx4Y3IiV/HDvI3lMwZHlPNE05 =RdYB -----END PGP SIGNATURE----- --------------HPs9k0OqWo0pZdNOODfPs53f-- From xen-devel-bounces@lists.xenproject.org Sat Oct 24 00:28:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Oct 2026 00:28:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459773.1671492 (Exim 4.92) (envelope-from ) id 1xKPcg-0008Is-Rp; Sat, 24 Oct 2026 00:28:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459773.1671492; Sat, 24 Oct 2026 00: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 1xKPcg-0008Il-Ox; Sat, 24 Oct 2026 00:28:34 +0000 Received: by outflank-mailman (input) for mailman id 1459773; Sat, 24 Oct 2026 00:28:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKPcf-0008Ht-36 for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 00:28:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKPcd-00GciR-V9 for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 02:28:31 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adbfb6c-bab6-0a2a0a5309dd-0a2a450c81f2-16 for ; Sat, 24 Oct 2026 02:28:31 +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 6adbfbae-f479-0a2a450c0019-aceafc1f861a-3 for ; Sat, 24 Oct 2026 02: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 8364142A11; Sat, 24 Oct 2026 00:28:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7599F1F01825; Sat, 24 Oct 2026 00:28: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792801709; bh=Nz+ynd+hlMgjwkODFZJ1hw/LhOrWGJnsnmI/jpEtw2Q=; h=Date:From:To:cc:Subject; b=AAy9v9gHNsUJfIFsQnknpzacppSFD+iOtOhBUO1U3amEoyaGNNynR2zQLsrZRjR71 nHPo2fH1sTTGdn0pUOq9EB3zWkJy6L+M5rmf2C/jJgbJ4qN9FUocoXRRmQPGVB+rR8 In1iE4Jy2EbFN9Fi0sexlRIsDXOimlhXQXX0D+5kizF86aYMYuawmKebyGIiUbi7VR OYxOM8Q77CYQgoIVHemySxapvOTmFyO8ETJosuUVo1MrOKFqDlm3ILQnS6lkW8k69Y +fVhhOqvoVFa8Erh8+L8nsaEtLRy3YnwmnaeRrL7MpQvQzxs7DVdFYcuBP2GPyZ4UO FBJTgVTdhaBbw== Date: Fri, 23 Oct 2026 17:28:27 -0700 (PDT) From: Stefano Stabellini To: xen-devel@lists.xenproject.org cc: sstabellini@kernel.org, roger@xenproject.org Subject: [PATCH] xen/rangeset: Fix rangeset_remove_range() with e == ~0UL Message-ID: <863a0654-7a34-976a-4c08-159cc34c26bf@kernel.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1083893399-1792801708=:4086347" X-purgate-ID: tlsNG-d25034/1792801711-50F3BA5B-7B8D0F36/0/0 X-purgate-type: clean X-purgate-size: 1547 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1083893399-1792801708=:4086347 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT When the removal spans several ranges, the last one is trimmed by setting its start to e + 1, and destroyed if that leaves it empty. For e == ~0UL, e + 1 wraps to 0, so the range is kept as [0, end] and the removal adds everything below it. This is hit by pv_shim_shutdown(), whose iomem_deny_access(d, 0, ~0UL) on resume turns the guest's grant frame permissions into [0, highest grant frame]. arch_iommu_hwdom_init() can hit it too, for a PVH hardware domain with an E820 entry above its 48-bit iomem_caps. Destroy the range when it ends within [s, e] instead. Signed-off-by: Stefano Stabellini Acked-by: Roger Pau Monné --- xen/common/rangeset.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c index 0e3b9acd35..2c0c1bfc08 100644 --- a/xen/common/rangeset.c +++ b/xen/common/rangeset.c @@ -239,9 +239,10 @@ int rangeset_remove_range( destroy_range(r, t); } - x->s = e + 1; - if ( x->s > x->e ) + if ( x->e <= e ) destroy_range(r, x); + else + x->s = e + 1; } out: -- 2.43.0 --8323329-1083893399-1792801708=:4086347-- From xen-devel-bounces@lists.xenproject.org Sat Oct 24 08:52:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Oct 2026 08:52:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1459932.1671512 (Exim 4.92) (envelope-from ) id 1xKXTo-0000vP-TX; Sat, 24 Oct 2026 08:51:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1459932.1671512; Sat, 24 Oct 2026 08:51: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 1xKXTo-0000vI-Qy; Sat, 24 Oct 2026 08:51:56 +0000 Received: by outflank-mailman (input) for mailman id 1459932; Sat, 24 Oct 2026 08:51:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKXTn-0000vC-5b for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 08:51:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKXTm-001OFO-70 for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 10:51:54 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adc7183-2eae-0a2a0a5409dd-0a2a4508ca16-20 for ; Sat, 24 Oct 2026 10:51:53 +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 6adc71a9-f659-0a2a45080019-b9ff1c22841d-3 for ; Sat, 24 Oct 2026 10:51: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 1a16d1bed9a000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 24 Oct 2026 08:51:49 +0000 Received: from Skynet-1 (lfbn-gre-1-317-75.w90-112.abo.wanadoo.fr [90.112.38.75]) (Authenticated sender: olivier.lambert@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id C7C0E82379; Sat, 24 Oct 2026 10:51: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:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=JOLuLyZU26Pwp+uet98NHgtxrykDYq7LWYrKUWWwKbw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=N04XhRFg6Yt1vRs9dgaKgR9Bt3ZS5TsZV40VwIOpXG30dzxhJyr1e20g4zCY9VW8/FuYmn7hl sImlWcdr50TmhaAZxix0CenR7XBrqNR70Oo4/Ng77oXMq9s88pBvRNWTDEXVfOSYc/3+Ybneag7 xCc5HMWIEYDdSeOqK4JtyvZ+1ZeH9HmpxzgGMyMCklv+T303HpBq3him40LBi6ELCfQwBdm7COt nbfrpr+4i3Mqy50hDZhzSPj5R8zq3RFzHH5y902FE4ALqAfQ6TzjIcw/UkhO0rmsP4FH6SyilsM zZhrcFdkgjghEKvXzstHRDf9iQZKftOWJshVnYn5utpw== X-Zone-Loop: 94b0fa4a39b945b86288426c500b1aeb8218e1be9f95 x-campaign-type: default x-transaction-id: 098abf31-f35b-4344-a132-afeda1595b65 x-swg-uid: 01-9bfe38b6-f4fd-466b-8e1e-633a91088b31 X-Mailer: Sweego Message-ID: <1792831909.8631fc262581453bbf619ec5b2062170.1a16d1bed9a000f79f@vates.tech> x-swg-bid: 1792831909.8631fc262581453bbf619ec5b2062170.1a16d1bed9a000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Olivier Lambert To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross , Jason Andryuk , Baptiste Le Duc Subject: [PATCH v2 0/3] tools/libxenstat: small fixes in the Linux network collector Date: Sat, 24 Oct 2026 08:51:19 +0000 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.1b1.d251b75fffadc3b4.1a16d1be84c.16662fe5e2b4fa78=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1792831907921 X-purgate-ID: tlsNG-c1860d/1792831913-CEF5F87B-6A5414C3/0/0 X-purgate-type: clean X-purgate-size: 2374 ---=Part.1b1.d251b75fffadc3b4.1a16d1be84c.16662fe5e2b4fa78=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable While looking at xenstat_collect_networks() for commit 0c53660c1cf3 ("tools/libxenstat: don't lose all VIFs when dom0 has no Linux bridge"), I noticed a few more issues in xenstat_linux=2Ec: - getBridge() dereferences NULL when /sys/class/net can't be opened, - after a failed /proc/net/dev header check, the next call skips the check and parses the file anyway, - parseNetDevLine() doesn't initialise all of its outputs (cleanup, no functional change intended)=2E Patches 1 and 2 may be worth backporting=2E If so, patch 1 should go along with 0c53660c1cf3: without it, the empty bridge name would make every VIF disappear instead=2E Testing: libxenstat builds with the usual tools CFLAGS (including -Werror)=2E I also tested the series on an XCP-ng 8=2E3 host (Xen 4=2E17= =2E7, Open vSwitch), applied with 0c53660c1cf3 on top of its libxenstat and loaded via LD_LIBRARY_PATH: - xentop reports the same networks and counters with and without the series, - with /sys/class/net made unavailable in a private mount namespace, xentop no longer segfaults in readdir() called from xenstat_collect_networks(), - with an invalid /proc/net/dev bind-mounted over the real one, a second xenstat_get_node() call fails again instead of parsing the file=2E Changes in v2: - Patch 3: drop "fix" from the subject and add an Amends: tag, as it changes no behaviour (Baptiste Le Duc)=2E - Collect Baptiste's Reviewed-by on patches 1 and 2=2E v1: https://lore=2Ekernel=2Eorg/xen-devel/1792142033=2E8631fc262581453bbf6= 19ec5b2062170=2E1a143fd43ef0008425@vates=2Etech/ Olivier Lambert (3): tools/libxenstat: don't crash when /sys/class/net can't be opened tools/libxenstat: don't skip the /proc/net/dev check after a failure tools/libxenstat: clean up output initialisation in parseNetDevLine() tools/libs/stat/xenstat_linux=2Ec | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) --=20 2=2E53=2E0 -- Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions = Book a meeting with me: https://calrs=2Evates=2Etech/u/olivier-lambert web:= https://vates=2Etech ---=Part.1b1.d251b75fffadc3b4.1a16d1be84c.16662fe5e2b4fa78=--- From xen-devel-bounces@lists.xenproject.org Sat Oct 24 12:48:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Oct 2026 12:48:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460024.1671522 (Exim 4.92) (envelope-from ) id 1xKbAb-0002nQ-W0; Sat, 24 Oct 2026 12:48:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460024.1671522; Sat, 24 Oct 2026 12:48: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 1xKbAb-0002nI-Sz; Sat, 24 Oct 2026 12:48:21 +0000 Received: by outflank-mailman (input) for mailman id 1460024; Sat, 24 Oct 2026 12:48:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKbAZ-0002nC-RY for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 12:48:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKbAZ-008kNd-4l for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 14:48:19 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adca8f6-e002-0a2a0a5209dd-0a2a4502aa4c-14 for ; Sat, 24 Oct 2026 14:48:18 +0200 Received: from [40.93.196.7] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adca911-6ca4-0a2a45020019-285dc4076f99-3 for ; Sat, 24 Oct 2026 14:48:18 +0200 Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by EA8PPF2F8D191B6.namprd03.prod.outlook.com (2603:10b6:30f:fff5::848) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.21; Sat, 24 Oct 2026 12:48:14 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%4]) with mapi id 15.21.0546.021; Sat, 24 Oct 2026 12:48: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=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=wqhawciZI3ZsvoDJBmqQ6Eec2uSI6x/1q0rPivZWkyCNXIJlcAPf9+LZ8xwI5dWJ/71E85QQdtZT+tiUGcN/8T1FGeQhN5kAsp5tV3+amE880K34hDjMN5+Y2ONWxqctTdOzt5notmquXVagfzfnSeHyQtHupTqkJs/iAMGrlf8WXCmWQKaOeVExOh0/uR64p3PT7VbNREMBtRfyznAgadoN/xWQdLHZ2vNw5tR6vXSHNHAWQAJOPpyTufAtSCEQ4k2NC9vJWoIc+OJm3k1ZiZ48Zp2+Ix3xYzTScynCsNqxzwkFgOdCNqtanyuq5zDEnxo9QDm1VFkq6HigzlQLkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+6wJ5dhBAOBZQ2mx4yeO1L485WwM/LUvOP+swld0xVY=; b=wovNfzh+sjuVKQFyT4SYefoVAuEwmgqwGE5BL8VPPFmx3T/WVUqbYURm3yygsHu4tV39TD1Z8zp7PejGPiIkTI1w92i3J/hdVBrtLfmBjCTGx8gV/k2UcW9M2h0qgGZPrt8/6xlUArYGwO6yPjzXWMLm7WUbwUpI7CzvtFuAVIVFBCeVtOGSRzDRZ3qvLuUWThd7pzqKftkdVktfeVjW21neMBmIg8dJq+ZMd9VCR/rFT9A0DfoKl8RTSsfsPdAqSuX2xDd/ZktWNisFGXIvZZqHXj2R0Dn9zF8FGE8fjzHEUNi7MOQwLfoV/boiScorS2lmG9q/ckGAheYXMrqVZg== 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=+6wJ5dhBAOBZQ2mx4yeO1L485WwM/LUvOP+swld0xVY=; b=g8om6opuJ6VNRPXNsZWlL4ZxWwO1cxMJXQR7srMMpuPGDIcnOnNgdLa1xca/hVeb+l+VaW/7k7Bfe+KiwwxD+YNmeN189V2NKVRMLxrZv5I9ZI1pcqTlRNh2vS+DdRvkBN5I/XE2+mFlOAJ90eqPJUSNcdZ4grZ8eXKqh8fLGOA= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [RFC 1/5] xen/arm64: livepatch: enable attaching callbacks From: Bernhard Kaindl To: Ryo Takakura Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, roger@xenproject.org, ross.lagerwall@citrix.com In-Reply-To: <20261023045222.163817-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> <20261023045222.163817-1-takakura@valinux.co.jp> Date: Sat, 24 Oct 2026 14:48:05 +0200 Message-Id: <179284608595.1706038.12585790247811677658.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792846088; l=2648; i=bernhard.kaindl@citrix.com; s=20261024; h=from:subject:message-id; bh=rBQud2JZ54Lq/cnkK0AnIqqHQp8XMGEULCraHcKIzTE=; b=un4nxlIp9DHNDyJbgR0yFEWYRAHxZnGpgdbG9Ag0JS4rf6weMAGNrpWSZAZlKKDpd36OdtE5f TEppv0lNHnWAPvWYXa1uJNZaxq8UQu0k4VKCdkfdsTLWm0PedWCynln X-Developer-Key: i=bernhard.kaindl@citrix.com; a=ed25519; pk=oIjnI/us0Uh5d/WP18V5IQq/FrLPUp+W0JAhJ9QCQIs= X-ClientProxiedBy: VI5PEPF0000092B.AUTP296.PROD.OUTLOOK.COM (2603:10a6:808:1::836) To LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7707:EE_|EA8PPF2F8D191B6:EE_ X-MS-Office365-Filtering-Correlation-Id: 7f445a44-86a0-4b9f-698f-08df31cd10be X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|23010399003|4143699003|56012099006|5023799004|11063799006|261009223027099003|261021135927099003|261021133027099003|261021130227099003|261021123027099003|261021121427099003|261022113327099003|261022105027099003|261022075727099003|261022115727099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: tiWNweHh4bWL9xlcHX8HNTUomzY3dQK5F6c6EVs/6IDxpg2xuunsqvnpBE9q6cw3/5E7Ff8Y5rWX8c11iwpvrlfLrC7/UhJE1U/rGyA3zwEQRgjmH5ukDpklxTtkkK/TlExrfhU/sx5TyeiyXpv5IXQjUtAWON1AsvNyzSjRhf66d2JWXusM+FG8gJFqxt5+jFleqXHt1/T+x8WD+RdTyzcQzsRFgY1OVdT2W37SIJlLt3+eyEHRfqHkK3eK8YNuQ1gT5HajgYbbIQswS68hR0i3aeUqzNoFjXFZcGBfUuafh4RO717NP6kD4My9XylyIouWQsNeb3JxC4VmpNhypwWbJNXFDOL3r/jhL2kAgB4fnR7jiWQTJ/P4r3gXS6I1MGsqoD9yqA1eW5Y4VhQbaX8Vm/hCi0vYoIavZyBrM1aRGbMC0garTRMPEd8+H9ij/PdVWddexWZgCIanc9BYC8Pksh9THDQwpmEiSsN22CXOhHVbemQWsJsZ4sfgR6c0nD7jJ0iI728lBmOQeZXxyvBU9347FVNXdagSOkw/8M/W49MGwD72McuXcubGe61zk8Pmrqb19eoLOxl5wSJfFoaC7wFBNMz2F+90t9s5EfVoJHTOUAgBgdj5wM+8ZrAjgSoZo+qn0+r6tzUgWFE84qNHfRPnMwK2ZJxgrL4Oj04= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(23010399003)(4143699003)(56012099006)(5023799004)(11063799006)(261009223027099003)(261021135927099003)(261021133027099003)(261021130227099003)(261021123027099003)(261021121427099003)(261022113327099003)(261022105027099003)(261022075727099003)(261022115727099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U1JLaStab1pZQnFCV1pIdEhrdUllNFljQkxYTlJ4OWVrV3V6QUEzZ2lQbWE4?= =?utf-8?B?RUl2Ly9xMTd0V0gzOUtBU3g1VHZwM0tLd0hBcnVRa21sWjk4UGdxenBWZ085?= =?utf-8?B?Q2QwdmNteHUweXFVSi82SUdKUE1LSmpNck5tVXFqTW9aWHBuWFhZcmNqZk5G?= =?utf-8?B?OWlnMU1uTTNXZjM0ZTc1am5NMHh6TUQ3aEN2YmFBekF1cEVNVndCdGFWOWlv?= =?utf-8?B?QW5uSFRyK0pKOWFMb0RBc0VWYVJvUHlkMWJ2UlNJZ2gwZkd6YXZNa01STEpC?= =?utf-8?B?V05qTFdFTzk3bjh5dTVpdTUxNjRrcmhDZkcrVWlBQXpibEE4RXdzeXd6b01x?= =?utf-8?B?T1pnR0R5eUxuMlJFVXhxWHEyMnRrQnphMkZYUXFHTjJRMzFiNFNxYmczSjBR?= =?utf-8?B?NEZMZHV3OGtzallMeE4wbEtlNFRRTmI3bDZRZmVXYjNnSUd1YUE5NmV1L2RE?= =?utf-8?B?UWozbng2Mm03OGdMb3RUSkhySmRDMG1kL0NuYTBNWHppSFRkSitTYXBPRVpp?= =?utf-8?B?aXl5UFg0ZVZ3aTAxVE1VL0FoR1h5UlVsREgyM1RyMkZUYVB4NFJwNk9UdGhC?= =?utf-8?B?TUZDYmdhRXkwMndZdHR6TkpUd3Y3RTBkNEtMUk02UHAyMStSZjMxbWFkcVJo?= =?utf-8?B?bWFTelBJSURKMFZtNktFTWtpRGtuWjhPcVJYMU9YbmVQRFVKQzZhZytDUkxX?= =?utf-8?B?QTZMbEVUaFZGMEpFdFZhY25Ld3BkRWtXSG5pWDMvRE12TXBLT0YvNE0rOEJz?= =?utf-8?B?MEU0ZTJZQzBmWEc4b05JbThPRHM1NTdpNi8vY1FLSE82ZEtUSjRUZmRBNFI4?= =?utf-8?B?djZKRDBjYVY0TzR5RHRwMzdSWjBRLzVSVDNtak42ZGtGaUE4MVlJT1Y2L0Va?= =?utf-8?B?dGpDNmRjNEZmSHZvK0M0TGJZOWpXTzZYbHZoeGpPSjlvZjF3b0RyOHpJN1Vn?= =?utf-8?B?UGk5eUVjMDNaaTFVYXYwSHU5dEpzcEJubEdWa0tUbkpGaU1DdjdKaDhhQ29o?= =?utf-8?B?cGh0UWFuUUMwU1ZOZVNvc29FNmdYRXA3b3FJai9VQThKaWppNytlSWFOL29P?= =?utf-8?B?OEJrZ3RIU01DRVI4NCtKc1VLOUdYSHZLVWlRZ2Y1QUtDSlRuV3BudVkyVUFv?= =?utf-8?B?UFczTzhSWXJYUjFydnlBRnJobWtjci9YWVBHSjdNeWNsZlZpUjA1cGpXejVM?= =?utf-8?B?Zi9SK3hDaDh5ZGNzeXRiRjJMUnhOdTZrSWp5Q3ZPRVAvV3FTM2ZwTFg3YzIr?= =?utf-8?B?NkFpNnlDcmxHU1U2ckh5VTM1aGZTTjF3Lzg0S25RYmFuQ2JMUHZNZm5YQ2wv?= =?utf-8?B?Rk9kOHZDSVU0WHlkdi9yd3NBY05kTkF0c3A5Y2xuZS9vRU1ML2xacTZpOHAw?= =?utf-8?B?YVdLYk5BN0s4ekxjVUIvREFmMzJTNDlkSVhqMld3WHN4Q0V1eUVNdmVkZU9i?= =?utf-8?B?TEV2cVNDR3BOMTNDMFNxR2FERWR3UmtEK0hmWHEzcGRhRlR5T3FFREdXcHhX?= =?utf-8?B?OERNYjNqRjNCSklodXRmY3VGVkpCZHlPUDJ0OU03MTdYOU5VNFROK3NmSXdy?= =?utf-8?B?LytRME5yNEh3SWZJWnpRWkFhdVN2T29QUHBNYzVWUm92MGx6S3lpZW81UGpu?= =?utf-8?B?NGN4Mjd3MWhwMGtaRHIyT2NRY1dEV05XK1IwY3FJYUx1Ykp1ZENxVWVxa2Y4?= =?utf-8?B?WTJXcWFpcUVQZ2JiYWZYZjBYQmNrbWUveC9seHc1eXpydWRxL210ZE5FT0w3?= =?utf-8?B?cWVmNVVFUjQzeXo0MHRlUUVBTG84eUcvdnB5ODVqTVc5NU9tY29ZNmkvTmww?= =?utf-8?B?d3Z3NUNoNzM2Tms3bmh6Q0p5NGdsaDVwRzc3aHUwSXBZaDZTeG5uVHpWWG1y?= =?utf-8?B?QzdjeUNLUHFyWGk5eGcxak1VaUNRNU5wVmUwb1F5aUdCQ0pxUE84dG1zQ1lk?= =?utf-8?B?ZXFEY0pISjc1THJoVm1zZWFkTExyaU1uME5XTmxoalE1ajRvSU11UGp2VHVk?= =?utf-8?B?MjdTejhldFZOTkxjeXp1cFVvWHo0aGxDV0RpazVlcEVPWmNDYW5iNnpwbWU0?= =?utf-8?B?MDd6ZDdWSGhnWUxaRTFlbWVwQ2t5NEFyanhMWmVKVjkvYlBpdm5POTlPMDEx?= =?utf-8?B?V3NxU3pEV2txcjkySUFWV2FLU3U0YmVES3pqeFpLbXZZSm1YMXlpU09JdWFU?= =?utf-8?B?cUhSMHBFTmIyVVRjUUFxcTg1VXcxNldpRUtFaG84emEwV1JnNTQ1OTliSXly?= =?utf-8?B?bHI5S0NvUitsK0lqWTc5TExacitkZDB4UTYzd2Z0cWxZd1M3a0JEcjBzdW5T?= =?utf-8?B?NGUwSlV6U1BSNnMvZzdzdWxiN1djVUo5NEhibUxZczVURG5QTUxpZC9Ea0Va?= =?utf-8?Q?Y4woxH7BdPZQdXXc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f445a44-86a0-4b9f-698f-08df31cd10be X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2026 12:48:13.2051 (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: Bg6l+B657HQxUqNiLON6YOpc5KpDLsdWs7EfOwbGs7P83NA2MBcCV8XCCUAldC/9hEZfp/xFvdMJ8N4fjwsGlv6+jlpwELWQ5z6gTjeYayE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: EA8PPF2F8D191B6 X-purgate-ID: tlsNG-720697/1792846098-F26B72AC-093BA4FC/0/0 X-purgate-type: clean X-purgate-size: 2648 Hi Ryo, Thanks for posting this RFC. Having dynamic function tracing in Xen looks useful, and I'd like to help with reviews. I'm not yet deeply familiar with this part of the code, so I've used LLM assistance to help investigate it. I may have missed a check elsewhere; could you help me confirm whether the following concerns apply? --- a/xen/arch/arm/arm64/livepatch.c +++ b/xen/arch/arm/arm64/livepatch.c @@ -492,6 +496,36 @@ > +#ifdef CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY > +void arch_livepatch_apply_trace(const struct livepatch_func *trace) > +{ > + uint32_t *new_ptr; > + uint32_t insns[2]; > + > + new_ptr = trace->old_addr - (void *)_start + vmap_of_xen_text; > [...] > + memcpy(new_ptr, insns, sizeof(insns)); This copies eight bytes from the two-element instruction array, while uploaded trace descriptors still use the ordinary Arm livepatch verifier? For reference, the existing arch_livepatch_verify_func() in xen/arch/arm/livepatch.c contains this size check (not added by this patch): > if ( func->old_size < ARCH_PATCH_INSN_SIZE ) > return -EINVAL; > > return 0; With ARCH_PATCH_INSN_SIZE equal to four bytes, doesn't this accept a four-byte function without establishing that two reserved tracing NOPs are present? Is there another check on this path that I have overlooked? Could an assembly entry or another uninstrumented function consequently have executable instructions overwritten? If reverting then installs two NOPs, could that lose the original instructions rather than restore them? Would it make sense to validate the complete reserved tracing entry, including the actual branch destination and any conflicting livepatch, before allowing the write? Could the expected entry also be checked at application time, so that a modification after upload is not missed? Separately, could a callback or one of its helpers call the traced function again before the first callback returns? > + ASSERT(f->new_addr); > + ((livepatch_trace_func_t)f->new_addr)((unsigned long)f->old_addr, parent_ip); What would contain a recursion before Xen runs out of stack? Would a guard covering the pre-callback dispatcher work as well as the callback itself help, or is there an existing restriction on callback targets that would rule this out? I think marking the dispatcher itself non-patchable does not protect its callees or the callback's callees, so they should be protected too? Thanks for taking a look, and apologies if I have missed an existing safeguard. cu, Bernhard -- Bernhard Kaindl From xen-devel-bounces@lists.xenproject.org Sat Oct 24 14:10:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Oct 2026 14:10:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460066.1671530 (Exim 4.92) (envelope-from ) id 1xKcRW-00045V-JN; Sat, 24 Oct 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 1460066.1671530; Sat, 24 Oct 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 1xKcRW-00045O-Gc; Sat, 24 Oct 2026 14:09:54 +0000 Received: by outflank-mailman (input) for mailman id 1460066; Sat, 24 Oct 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 1xKcRV-00045I-MI for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 14:09:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKcRU-00FVbf-V8 for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 16:09:52 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adcbba6-bab6-0a2a0a5309dd-0a2a4507c48c-34 for ; Sat, 24 Oct 2026 16:09:52 +0200 Received: from [40.107.209.0] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adcbc2d-b4ea-0a2a45070019-286bd100dc8a-3 for ; Sat, 24 Oct 2026 16:09:50 +0200 Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by CH5PR03MB7888.namprd03.prod.outlook.com (2603:10b6:610:210::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.20; Sat, 24 Oct 2026 14:09:46 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%4]) with mapi id 15.21.0546.021; Sat, 24 Oct 2026 14:09: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=kHQ40X6P2qMfEveaH9K0r+kTlrvi39JuH4Ts2IX9zghHghD9knxUebuDv2hGeOKM5+RbcDJjdQ8HcbQRy0n+amvv6y2tvBiEiag6KxXWQlPyYTCfOYnZPVQHta+ry4pCzsoEMC+4coWBo0x5KZaW7ncxhan2SBNjNp6uJEg7TAMv6R7eKxNPNfmdlDwqOnxNVL0uRoV9JQ+HtNHcKRkzUgjJYwqPr6B2rDqKRW6xbr3hlruvs2xl22dlAJFksvE3/2y8oDXKTdqpR74fg6DL5h8E7v1U6btTNPKWsdyhNLIkpNJPfOsItYwqKrFo3NhXWLEldkBVXZqeiSGs5BrDSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KlELAyw88BPv+kxDeeyrgZ+PSMWomOIQZ9nCxcMKp4Q=; b=VtLTw0ho476qH+Pue6t+lNFv/AS7qEmxoEpk/u0eZYxELC51LtQCKVUCTgsK/z5S1Ia2f3WvBjr8xmVCPK9aoluRjj2PZP2wmnAToz5pkIifAmaJ/y7jMEIhcoFyGV+UNiOcxaA4X3yfvVzzyVTK6SftcNNg6FPpBQtX6u14kTy9ism2HMkdNaJjlvQEpRAsmvQCw+HM7zWXmCnd+/pWzbeKCHFVUw4T9TtpV8UfDocCrI6qtMUA7pAXTsrOcJIc7rxVmhitqExJ4wZHIRzbVer7ETaH49wynnB5YNPI6YxIbZOoXlofXo1Ch4NN67PHNg6H7md+PEdEUwgivWFF4Q== 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=KlELAyw88BPv+kxDeeyrgZ+PSMWomOIQZ9nCxcMKp4Q=; b=tB7e+rf5qedCXD/PD1kr70IeU2BzGRECXa9jf6h2EwURDAeqTfhB085bPPK9cVXpRzJDDav+ZEWLuNK6fC1kWi/j+aGFYDwlwLDY3sdhv3k1YgV9YklKYkqrKa1+0ti5S/9ohNQ079f3uNENdQ8r7k5CmKAQ/2KY+3vPHLTSwYs= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [RFC 2/5] xen/livepatch: Allow tracers to schedule livepatch From: Bernhard Kaindl To: Ryo Takakura Cc: xen-devel@lists.xenproject.org, roger@xenproject.org, ross.lagerwall@citrix.com In-Reply-To: <20261023045346.164171-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> <20261023045346.164171-1-takakura@valinux.co.jp> Date: Sat, 24 Oct 2026 16:09:36 +0200 Message-Id: <179285097671.1706038.6114522060925613675.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792850982; l=3785; i=bernhard.kaindl@citrix.com; s=20261024; h=from:subject:message-id; bh=NXsTzMUMfmR9IJQcdF8B/7/pZcg/Lnr/xNwou/wIkZY=; b=I4q/H2cvOVA9eSOZatnVoA+stOpS8yGuXgVvBc/4iK/BpP4mEAcdiVZHWp3rJ0bld+TEErvvu fnlgw9ayVfUAEEkmGSV/p2clh8OxIPNb4fmN+k8Q/POw0bNeQSnbV8U X-Developer-Key: i=bernhard.kaindl@citrix.com; a=ed25519; pk=oIjnI/us0Uh5d/WP18V5IQq/FrLPUp+W0JAhJ9QCQIs= X-ClientProxiedBy: VI5PEPF00000976.AUTP296.PROD.OUTLOOK.COM (2603:10a6:808:1::816) To LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7707:EE_|CH5PR03MB7888:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c8f5a78-7a08-4a04-93fb-08df31d87580 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|18002099003|22082099003|10067099003|56012099006|11063799006|4143699003|261009223027099003|261022105027099003|261022075727099003; X-Microsoft-Antispam-Message-Info: cQ4AH0YS6JcYsOdCK2MWpO6iOgoLETMnqwmP5vDIHKnV/dpp57MjSLtZNFi//BC70AoffZxNIckXU7LSKU69vfq9iKD8lbBB/Wynj8LHb0KfqQ+1OTDkA1hNoKSm7/8gE7PeseSaxuR5F91IVPmCRBMgL1MuWLgP6GENXMMPHp+ExcWFmUwN9h4F+DUugFFixncJz22C6KZzVYDh76RikIurTK5vbw1sfHRYUCqW1Kh212u/bn5xxp5ijNbMy/5usQInap+dtSit/LecsGp7IXrMPuwxgjdQ647UKrd82k7kj2jH/czvZmHd6I3ApbsdidYLC/TiWG/aZrnWNNjp3EANk2Y7cssV+JW4gTG6di9uIGMZ0rRjJ9LoHIJLe7zZZ9jv+29PL1Vf7JMp86PNyTKjL8EcUKqgYCSUCZzbLHnTCm01mEqaqN577+UsRZRf7RSxGcsWRDXXkv5/d4S8qYeImEP3j8/rzDkUJEaVKFvxHTqJqY0I23x46O7QDV5uzJG04sg7rg093o0a5yIy2VvJX+Jt6/HHF5BNYt4NrZEfJzlxd71BPgCj4RbRKoztTEEktdMnND51ftSP9eXRnIzcLfZhVUxMU7V6PeCgUaANAu6gXvZcGlB78XjPZIGFZKkEgQGyQrJyAvk8p5xd03ciEpB3KQ/Dj8r+UwDalNk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006)(4143699003)(261009223027099003)(261022105027099003)(261022075727099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Zk1WZVdZcjdqT2lLckR5THhWTmRzRGZsNXdUSEZFbytlR2VZdUovalNIVy8z?= =?utf-8?B?MnVHK2x6OXZOMFkrT3E0Qzh2WVcxTTV1ZWNhTTJIbUE3bTRzQkVmMVBMblVB?= =?utf-8?B?dndoVlVLbHB2Y0ZueGFqaVdOUEtXVGFJVTNBblFqdjdYb2lFNTFNMTZhYnRY?= =?utf-8?B?V2hhSUhrc21ZeUlOMWwxcndZdjdsNGRSQ1dLNmFPUkxpTVB6ZXNOcnR3ZmNy?= =?utf-8?B?Z2tRSTlNalJmUFVDdndTZEVjZ2tpeGVmalBtY3REQnJJdlBETU1yMHczUURa?= =?utf-8?B?NXFDRmdLY0Z3a0RNM1RnODFvaGZzVmowQ3dubGZaNjkwcW91aUNjaDJpRlRO?= =?utf-8?B?T04xS3NFbHRCc2pEMVJYakxJRTQ3ZktoUUZBYTNtYjFsS3hQeEZHd2Q1L2tx?= =?utf-8?B?MFh2ZCtnYlQrVTBjVDdCcHVibDlwbGxNWkg3UE1PZitKT2wzMUJFQUVrZHow?= =?utf-8?B?MjBkbTJhTTlXS0JSZ2tuOWlXeE5lbHZTbktWM2NsaDh5OTBjZ1FXOXYzcmtE?= =?utf-8?B?cHZPc1hNZDRiRXNOdEtTK1diVU1PLzBQWThUS205OThzRE13cW9QVW1SZzFD?= =?utf-8?B?K2N6bWwyNXNiR1lFUHVuOEg0WFJuWTJVaFlLaWYxaldWVDRHc0F2WVVYZTZv?= =?utf-8?B?RjZaaE5oOVJhOTBaZkFFUWx5ODd5Vy9IY29pZS9HYjNIYVE5WCtDSERSOVhk?= =?utf-8?B?NCtQMGpIMFhVRncvdUw2OVY2a1JRVWlLKzRrUlkxdWprTTlIT3U4L3hHK1VU?= =?utf-8?B?dmsrM05nZ3QwcnhoUnNkUjg0bU5rRXVnZzhwWW1idEY3L2kxbnF6MDVyeFN5?= =?utf-8?B?NkdjYWxnZ2xWK3kzTVFIR1hEaXlOVVZjMEpqZUNYUS9SMms2TDZDOVp3Vjh0?= =?utf-8?B?aGhRbytZaUdEM2FKV2lHNk5vY2Y3ZHV6TFpRMGxqd0NkZUNLUFM0VHFINnEw?= =?utf-8?B?eDVmUGsxWTN5VEQ1Y0FKNWFKOGRhMDMzSzFLMjBaMWpyRUNYQ3FhTjZNSHpB?= =?utf-8?B?L0d2NTF5UldZOFczbnY1ZWZlTXpDMEtSTW1zTlBTV3BqYjdxZWNRMFNyYmVH?= =?utf-8?B?Uno0ZWR5RCtiak1wbnUrb2NLNHhhWjJQb3Q0blVHdFpIbkptbFNKQUlIMWVL?= =?utf-8?B?eTVVcmMzMTNrUkM0eVkzY1cxS3Q3Ky9WT0Y2YWNWVzNoclorUlpvbXFzUllY?= =?utf-8?B?Ym4veVU0QnU3YVI2MS9DK2dGY25qaUx4ZVhuOVhIbC84cytCZS9hQld4VTRO?= =?utf-8?B?eklmTEVKWmd4Wk0xV0hDVm03L2QzeDhHRjI5TkQ5WEQ2cUJrTi9heGpoVThN?= =?utf-8?B?Und4ZmVmT3J0dTF0WVpWZk5sbmVjaS9ScGtYdG5wczZTYU5Dc1MrNFRwSjI3?= =?utf-8?B?aTd2dWNmWFhOM1h4R282Y2ZRajJ3YmtpM1F3RXY1MHhqTVJlNXRTZkkxNVFH?= =?utf-8?B?SERWdzE2c1Y3dldFdVliaFRxM0ROcFZNQmNoUmt1ZFdHTkdaYWpETEZZcE53?= =?utf-8?B?TkdDYlNqZUYwSGxHdGxBNGhTT0V2aUVUaDJ5UGZVeGJFa1VBdnlrNGsrVGV2?= =?utf-8?B?LzJEcmp0OXp3MnM4dEtVeXpUSlV6aXUwSStEcjhFdFJYZkd6UHlmaVJKQlIy?= =?utf-8?B?T2U0Zmt5Q3FNVVZBZEtBdFRxN0xycnh5enBoS28yYkI3ejl5UG15VEpTYy9t?= =?utf-8?B?MkhCU28zV0F3dElsS3YzNmErYzFSQzFTbjdKRE9OdVBxRGIvNldTRTBXbFRL?= =?utf-8?B?dU1GTFhjblJSdC9DckcxR211ZUVpNUJiU1hqUWFzVjgwUXFKNVFuUmZsaVh0?= =?utf-8?B?bDFZN3FISEZXMUVhWThWcUo2T1plajNLT1JyYnh5elJTYUJiK2Z4aThlSGIx?= =?utf-8?B?Rys3cm9pNkRCZlUzNUUyZjhTbG9zdVlBTUNyYk9zb3o4cXcxYjZFREdZc1Z0?= =?utf-8?B?emtsaFQ0akpGWnNiTjY4M1RvdU9xSmVUem4rNS93MURlei9VZUVoNkExQ3Rm?= =?utf-8?B?ZE13VHZ1amQwNFNjOGJxRXRQQzc3MXk0Zm1WV1pWai9zUi83elc3eTVSVkhD?= =?utf-8?B?WTZSV2MzNHNhK3hTWEpLQXhSU2Fidll0cUMvQW9oeFlRWVdiTUpHL3FoVmdn?= =?utf-8?B?NDdnQ2ZnSUw5amdEZFVURjk1L2pLMTZZbCs4YWNCbEdVSmZtMTQwMmFER01r?= =?utf-8?B?MVd1SHFxbXpvbTE3YjBrOXJoNk1rclFQUmNDS1g5WGZQemthVXhVOEhLRzJY?= =?utf-8?B?Z1c0NU9iMDFDUFFFZ0E5TGFMZUhpUGV1SVJxQjBxdkd5NnhHYnNJR2R4VXh0?= =?utf-8?B?MlpLLzBGYXp0RWtMclhHTmNReGFRLzFodFdjd0tlOFp5WE9Tc2VUNFhGOG1u?= =?utf-8?Q?0PjS7kcni2r1IFq4=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c8f5a78-7a08-4a04-93fb-08df31d87580 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2026 14:09:46.6399 (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: hEto7aDT1eICdjAKcvJDYRb7ybYpYmwyGHMjIxM3iXFZHpFPynZq2jLTuM3SLyKAfKUUjHbQB3GuojhAu3xiBEtvWYPhtJdJuOzRvfRvqOo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7888 X-purgate-ID: tlsNG-ef75cf/1792850991-3C411AE4-6BD14133/0/0 X-purgate-type: clean X-purgate-size: 3785 Hi Ryo, Thanks for adding this interface for tracers. I'd like to help with the review, although I'm still getting familiar with this code and have used LLM assistance. I may have missed part of the result-handling contract; could you help me check the following failure path? > --- a/xen/common/livepatch.c > +++ b/xen/common/livepatch.c > @@ -1823,6 +1834,51 @@ static int schedule_work(struct payload *data, uint32_t cmd, uint32_t timeout) > +int livepatch_schedule_trace_on(struct payload *payload, struct livepatch_func *func, unsigned long ip) > +{ > + void *old_addr; > + int rc; > + > + spin_lock(&payload_lock); > + if ( is_work_scheduled(payload) ) > + { > + rc = -EBUSY; > + goto out; > + } > + > + old_addr = func->old_addr; > + func->old_addr = (void *)ip; > + > + payload->rc = -EAGAIN; > + rc = schedule_work(payload, LIVEPATCH_TRACE_ON, 0); > + if ( rc ) > + func->old_addr = old_addr; Am I right that is_work_scheduled(payload) only detects work for this particular payload, rather than any work using the shared worker? For reference, the existing is_work_scheduled() in the same file ends with this check, which is not added by this patch: > return livepatch_work.do_work && livepatch_work.data == data; The existing schedule_work() instead has this global busy check: > /* Fail if an operation is already scheduled. */ > if ( livepatch_work.do_work ) > return -EBUSY; Could a request therefore pass the first check while another payload has work pending, set its own result to -EAGAIN, and then be rejected by schedule_work()? Failure to acquire the CPU-map lock seems to offer another path to the same outcome. The caller does receive the immediate submission error, but wouldn't payload->rc still suggest that an operation is pending, with no queued worker for this payload to complete it? The off helper appears to have the same result-handling question: > --- a/xen/common/livepatch.c > +++ b/xen/common/livepatch.c > @@ -1823,6 +1834,51 @@ static int schedule_work(struct payload *data, uint32_t cmd, uint32_t timeout) > +int livepatch_schedule_trace_off(struct payload *payload) > +{ > [...] > + payload->rc = -EAGAIN; > + rc = schedule_work(payload, LIVEPATCH_TRACE_OFF, 0); > + > + spin_unlock(&payload_lock); > + > + return rc; > +} Would publishing the submission error in payload->rc keep these rejected requests distinct from work that is still pending? To illustrate, I think this could be addressed with a small change like: --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -1861,7 +1861,10 @@ int livepatch_schedule_trace_on(struct payload *payload, struct livepatch_func *func, unsigned long ip) payload->rc = -EAGAIN; rc = schedule_work(payload, LIVEPATCH_TRACE_ON, 0); if ( rc ) + { func->old_addr = old_addr; + payload->rc = rc; + } out: spin_unlock(&payload_lock); @@ -1882,6 +1885,8 @@ int livepatch_schedule_trace_off(struct payload *payload) payload->rc = -EAGAIN; rc = schedule_work(payload, LIVEPATCH_TRACE_OFF, 0); + if ( rc ) + payload->rc = rc; spin_unlock(&payload_lock); Would this preserve the pending assignment before successful queuing, while leaving a terminal error when no operation was accepted? This only handles immediate submission failure; it would not reconcile the filter or target state with a later worker failure or make retargeting an applied payload safe. Thanks for taking a look; is there an intended status convention that would make this harmless? cu, Bernhard -- Bernhard Kaindl From xen-devel-bounces@lists.xenproject.org Sat Oct 24 14:14:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Oct 2026 14:14:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460074.1671540 (Exim 4.92) (envelope-from ) id 1xKcVf-0005bA-2j; Sat, 24 Oct 2026 14:14:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460074.1671540; Sat, 24 Oct 2026 14:14: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 1xKcVe-0005b3-WD; Sat, 24 Oct 2026 14:14:11 +0000 Received: by outflank-mailman (input) for mailman id 1460074; Sat, 24 Oct 2026 14:14:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKcVd-0005ax-Sh for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 14:14:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKcVd-00CpPD-9e for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 16:14:09 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adcbd24-e002-0a2a0a5209dd-0a2a45099204-8 for ; Sat, 24 Oct 2026 16:14:09 +0200 Received: from [52.101.193.22] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adcbd2f-be1a-0a2a45090019-3465c1165ccb-3 for ; Sat, 24 Oct 2026 16:14:08 +0200 Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by CH5PR03MB7888.namprd03.prod.outlook.com (2603:10b6:610:210::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.20; Sat, 24 Oct 2026 14:14:05 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%4]) with mapi id 15.21.0546.021; Sat, 24 Oct 2026 14:14: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=cXvkzzTgiP+PIJ/hqNMVRNo0U+o/K6E20eB62hd+/OKs4HJj61K1sAob6FHjhwNQyTZk12PSQaNiAbqOZAw+35iiVFTQ80Nu6xyq8M71p6ZdAU3FrEb/FqCJZez692+r0q3KFLR5QaF9Rg5xFOR7HLgR5K+PWfYKG1VzzEfwY+QHKBU9LWe+iNwJiV90xFbDoq6ftUN3aumjmZQB52Qh7CzD6ZTA/pFwolO+6a6FJo5nnIkycLDRgN+2vmXOcSmGPoraXxq3AOOGOkQsxjzI5oaelxN4LlXUZbrfwuLsy3npr2hMEKInXgEV2LxZDa1zcozhRi8nlIbQuy6jFEjc3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wGktxpiLJd+By9hMcQEkWdxSfmT0yiUXOtnLuesASFM=; b=avsfWq115dyHTK4nSCnmlDCnovZmHdGPa8+CWGBHsVLWc5HrXVJehkAL3j0XvXFoT6Mg7lkKSvpxJcuvHbi7GZFFQ+/0FaUj+xTKECCXpT2i9g1KDPetxqzWLScY+fIHyXYZOTS0t3agpZj3GxgS8ZYI3MccPF7TSrktaAgkijYwVPJ23OI+1KkZ6USEKzzm52Sm9Bg9IyXr/0ZAYSvA997DMylTguvwgFAC82reasI7Lueml93p7oV651bIFTtw+3MXIPqa4hoRNf9hMqg6sDgmrvD4aqo68kisgajoftK2KDmwzxt/Aqq2M1R2iawEceUKTH2wh1XcilJn7TT2Vg== 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=wGktxpiLJd+By9hMcQEkWdxSfmT0yiUXOtnLuesASFM=; b=oXFIs/8CO02S9tY191R9xRbc1uypo2Hkug7wYhNP3wV53qaB7rURSV9GSgKmrqP0+yr9bOynG4elb/8rwsLqdmNvf/SIODJeF4Wd/y8zRUOYS5G7S4kS5KDAy+OaBkK07P5rAZC/EvAIjAaktEiR7DAAWG0Nzwgar65WxnTDa3I= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [RFC 3/5] xen/tracing: prepare a livepatch payload and its controling interface From: Bernhard Kaindl To: Ryo Takakura Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, roger@xenproject.org, ross.lagerwall@citrix.com, jgross@suse.com In-Reply-To: <20261023045543.164658-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> <20261023045543.164658-1-takakura@valinux.co.jp> Date: Sat, 24 Oct 2026 16:13:58 +0200 Message-Id: <179285123800.1706038.4978498781229199186.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792851239; l=8586; i=bernhard.kaindl@citrix.com; s=20261024; h=from:subject:message-id; bh=TI0wo2frgW/d7qpZB28q/IUgZL2lkOPX8H2yk99frYI=; b=AzkqG+bEXeyBiI6Yq9SPfz8khXQxJAHI1IZB8bq449dLMvj4VbtmPcWvpoNnONPMlKFqFCoik 1DMj3HUeInlBG4x5M5jt/KZ68qXHQArtjRbLE9dwWwckoulUpj26CFC X-Developer-Key: i=bernhard.kaindl@citrix.com; a=ed25519; pk=oIjnI/us0Uh5d/WP18V5IQq/FrLPUp+W0JAhJ9QCQIs= X-ClientProxiedBy: VIZP296CA0024.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:2a8::12) To LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7707:EE_|CH5PR03MB7888:EE_ X-MS-Office365-Filtering-Correlation-Id: 1ae1dec5-9629-4b5d-323d-08df31d90fa1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|7416014|366016|18002099003|22082099003|6133799003|10067099003|3023799007|56012099006|11063799006|4143699003|261022115727099003|261009223027099003|261022105027099003|261022075727099003|261021121427099003; X-Microsoft-Antispam-Message-Info: +JW5eO2HdrfhIO/T25AO9X6FLoN33WjT7jQR2Iga+sU2RClzmAqAaQFJBSs90OlOc7Xp9MIcZqa18ckV//b0UDAbLDTVYDeuU7HGZZwW+zwo/bGiROUm2Rl/Ji3Tw07ATjWVu/CQz3ZGKsQWSPMMmp9Zdkn4Zl0rMOhuQM0q9YbgXvM5GIDm90MMY3q1dYUEUdKlf9U2ud7XYclGtQt0n6d+dzSdiqV9zryCY1uWyxDHoAZNVsCUSJLFYR1LDLJ+o6KsScBTd5XNW24tUqMx/SRotcILqkBJis4Ug2Jk+Xv5oyTd76wzss3nquTSXceDBPUzWEVgr9r9XLdwQhmTflo7ubH3IIrIkLobgTskL61kmhQcIYBMH6SUHnOMi1eU4iy99ivRDrzEwhkIHFw77XYxWq0C+wSt6LnwuL833FTRu5sLSJpRHDn6S/oCq4dfBFck1rSFuj6aK0dlNy4oUxVo9ypn8GYo7+sYsyjXAXVyCntN0Wg9jbvlyMPal7P7bhqy9cRgXRvSxcMod/ffV05ft17s25EXgLCDnUgEKuB0wFBbdznuVDc8havSb5XA/eEdI20ebEQgfFCRppQ24kyUkuWRc8yQA95dNmjQWLaI1U1kdQGghMT1jtMDJJnpwtj4OI64E05HMEcaBP0ibf3RX0bzeVIgwjOBP/dEbv8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(7416014)(366016)(18002099003)(22082099003)(6133799003)(10067099003)(3023799007)(56012099006)(11063799006)(4143699003)(261022115727099003)(261009223027099003)(261022105027099003)(261022075727099003)(261021121427099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZHZrTWFTMFd4czVYWEh6Q2FyNU5PSENzVnkxelk3bzIzQSsrRDRVVTJoYWdO?= =?utf-8?B?b0VxcVR6UzZXOUpGZUR4WnRKdkNXYzcraDlnbW95TUhNM1dkbStTVTVxRnBW?= =?utf-8?B?QUVtNVdMd1ZZazNlTWZJWXQ4bmVubkd3ZmoxN21zVXBxMHBjMjdMaXdkTGxm?= =?utf-8?B?RThtZ2RrUHhaZmJtWUlCejB4VVVVVkpVeGlhdUJ1VEUvYlB4MWwzWkJPWHls?= =?utf-8?B?NTBlaFV5R3ZJbjZ1WTZtSkl6bUk5SHd0WTFCSTJCL01xaHhUcDZEU3pxajBU?= =?utf-8?B?NkV6QlFrK1JNL21RWFZWWWczVVJUa1Y4aVpjREpWb3NCc1dxQzVoNUl4TFRv?= =?utf-8?B?cm82ZHhRZk54UmVNZFRhbnNoM3lqWXk5RmFiM0QydjRqVTcySVgzTThNS0l1?= =?utf-8?B?dHRaK2c1TTJpcjZFNTBWNFd5OFd5TGljcXdQQXRUdUZ0ODBKOCtPeUZvRWxG?= =?utf-8?B?K0lYSnpZcDh3NTd5ODdldHA5UGZqVWRuampaRm9wRFZtd2JWNXcyT2Y4Q2hX?= =?utf-8?B?MVhTRkFLTytFdW81L2xWeHNpRGFaSEpYdkgwNXdxc1dsd0VvN0g4Z293enk3?= =?utf-8?B?cWs4RGxHZDdHWWF5MVRUa2o1VzdvK3BVVThHUGJGcElwandPdnhBNmE0RG1U?= =?utf-8?B?L3N4cjV0eFV1bGh1ZFN0MFJtTCtTUGxpVndzT3B3RjRuemtzZVo1Uy9YREd1?= =?utf-8?B?RWVKOGNsb1AvbStXdjdYVXlIeE1wbytscWhBU3h1TmZGVUR0RG1qSFk1dXd6?= =?utf-8?B?T0JuS3VibkRvSU83cFd2K1VuRkM4MUtxbUgxWDhteHByK013cFN0M1Rrb21R?= =?utf-8?B?QkYvUnkzN3R3c1pTN1Fja0RpUUJUbXdFcmRPZzMzTUdMQVNIZFNuc0xyWkZq?= =?utf-8?B?Zis1QUxkTXhGSlBRK3NHNXdscjlMQS9ldTFnR0w3elZ5dUlDaE91VklMeFpJ?= =?utf-8?B?ejdVTk05UWhaL29RSlNrZjRNMktpanl3clo3UGU1SXVFb0pQZDNocGNSd3pO?= =?utf-8?B?TjJES2RodGtqVGFMV210OWhyOWlTOWlnV0pNb2g5cDNSMGUzRk9TV05OTGlO?= =?utf-8?B?YWd4RWVYTmVYMEFxSnd0eGxYanE4SFZMR0k1VnRmNEEwaEZzUGU5d0JzWTVs?= =?utf-8?B?Y3l4ZDRFd09vTW5QUjhIMUNPWjhHSkVNN24xc1ZOaTBwRVY4ZC91QjJBd3No?= =?utf-8?B?RWFPLzRIblVmeldEZERFbTR4U3Q1Zkt5OWVxaGtOWlVYRGVUUm45ZnVOUTlh?= =?utf-8?B?eENaT2ZrNC9Lb0p6VVcxK21qcmVWWkFwdVIzQ3hPVlIxSXh3Z2VtQ29EQTFq?= =?utf-8?B?S2ZpVXB2SHJyQ0xLQ21yZVk1WnlSSWRQOTJtZkJyZzBHempsSnhBb3M4L2pV?= =?utf-8?B?YzAyVnQzcFhiUkVBcTNzZG9teWlKZ3E2SUJpbXVSVjBtV1BJNHZlemRzN1Uz?= =?utf-8?B?WG1uUFRlbi9JS082TEovN1Jpajg0ZU9yZVZDQ1BrbUJ2V0dLc3d6R1JHcVNs?= =?utf-8?B?N280RU1YSEJocCtWbEFZOTRwZUxZK29sQWZBNDRER2o3YmhjOXp6NmRYd05v?= =?utf-8?B?RExMRDlCeGVDYy8wZ1JGK2xCdHZsRWlNUnJONEpKRWRySElEcnlzQTJsd1N3?= =?utf-8?B?YU5KNjdpQmhPdzFCSmk2UFc3c2oyRU1nbndhcHM5Qmxyd041UG04L1JRZDI4?= =?utf-8?B?bWl0RTIrODZkOU5zajhpczkrWEhud2xDTjNqK09YVUMycit5Sk1UNTZuR01S?= =?utf-8?B?aE9HS1lNbFNIblpzdzBEQkc1OWIxOTRBZHFvK3BHdlhrbVFGZ2ZTU2luOExH?= =?utf-8?B?dkxwQTltai9hUi83N29qcVdxYllvR29HS0NHK3kvRy9GT01kdzlQMHdaSFE4?= =?utf-8?B?VC9ubVhoUk55NjM1a3I4L0Z6QWNieGdkeWY4K0dWejJrRmpjTzY4QmZkQ1Rz?= =?utf-8?B?VGNuOW9HZHN2T05MUFZ0WDNKOCtKelc4QktFOXlXWUZmSk9ycUx4cEJwSW9a?= =?utf-8?B?aEVva1pzbzBGempoZ2tDaTVQMGxZYnM4b3Y4WWthRFNweitoQUlxcSszVnVI?= =?utf-8?B?U0VXL01TdEI1aE1odjEzSGFXaTJLU2NMZ2xaNXJZNm83cU45RytheTk5K2Zh?= =?utf-8?B?cjhsWUd6VFVFa3JRRFdKdStzcHREOVZleGIxNHdLcXd2dkZ0UkJiNGFyQS9u?= =?utf-8?B?L09pOHFoaFpxSDl6cTB4em9lelNVUFN3VUplS0tvaXNVa2l5QUk0ekMxWXV3?= =?utf-8?B?Um4zbXc3N2RFT0s1cGNkQy9TOTBPdVV3MFdZQkVidUlMZWF0UmdjakJNY2lP?= =?utf-8?B?RTJSeklxeDhoaGg4VkRvZlhCQjdmM1M1bDE4OU9LOEhCa2Q4d1ZkVjM2dFVi?= =?utf-8?Q?tzqecWJVStIUZbXw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ae1dec5-9629-4b5d-323d-08df31d90fa1 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2026 14:14:05.1024 (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: NT2cUvCB1k08zdfNOMbRVHdsdN4RyrZHq8ELWnNS5hiAdlgZ3ZldHytRyNk8YI/YQF8GT+xEopP0TReqfQ5Fn283MnDY5dgydL73ypxCkPo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7888 X-purgate-ID: tlsNG-bad1c0/1792851248-FD668034-06512BC5/0/0 X-purgate-type: clean X-purgate-size: 8586 Hi Ryo, Thanks for making the tracing controls available through HypFS. I'd like to help review this part too, although I'm still getting familiar with it and have used LLM assistance. I may have overlooked an existing synchronization rule; could you help me check these cases? > --- /dev/null > +++ b/xen/common/hypfs_trace.c > @@ -0,0 +1,741 @@ > +void trace_dispatch_callbacks(unsigned long ip, unsigned long parent_ip) > +{ > + livepatch_trace_func_t callback; > + > + if ( !tracing_is_on() ) > + return; > + > + if ( !trace_callback_registered ) > + return; > + > + if ( !global_trace_func.old_addr ) > + return; > + > + if ( (unsigned long)global_trace_func.old_addr != ip ) > + return; > + > + callback = global_trace_func.new_addr; > + callback((unsigned long)global_trace_func.old_addr, parent_ip); > +} What synchronizes this reader with callback removal on another CPU? The corresponding part of trace_unregister_callback() is: > --- /dev/null > +++ b/xen/common/hypfs_trace.c > @@ -0,0 +1,741 @@ > +int trace_unregister_callback(void) > +{ > + int rc = 0; > + > + spin_lock(&trace_callback_lock); > [...] > + trace_callback_registered = false; > + global_trace_func.new_addr = NULL; > + > +out_unlock: > + spin_unlock(&trace_callback_lock); Could CPU A pass the enabled and registered tests, then CPU B clear new_addr, before CPU A loads and calls it? Would that permit a NULL indirect call despite the writer's lock, since the reader does not take that lock? I wondered whether the existing payload RCU region might cover this, but the new dispatch appears after its unlock: > --- a/xen/common/livepatch.c > +++ b/xen/common/livepatch.c > @@ -232,6 +236,11 @@ xen_livepatch_trace_dispatcher(unsigned long ip, unsigned long parent_ip) > out: > rcu_read_unlock(&rcu_payload_lock); > + > +#ifdef CONFIG_LIVEPATCH_TRACER > + /* Call tracer callbacks. */ > + trace_dispatch_callbacks(ip, parent_ip); > +#endif Would an ordered publication and reader-lifetime protocol help here, including draining callbacks before unregister/reset completes? Could it cover registration as well, where the registered flag is currently set before the callback pointer? Merely checking the pointer for NULL would not seem to protect callback state already being used elsewhere. Separately, could a pending filter apply survive a successful clear? > --- /dev/null > +++ b/xen/common/hypfs_trace.c > @@ -0,0 +1,741 @@ > + /* Schedule removal of the current patch. */ > + if ( global_trace_fstate.applied == LIVEPATCH_FUNC_APPLIED ) > [...] > + /* Clear the filter if no target function was requested. */ > + if ( !ip ) > + { > + /* > + * Keep global_trace_func.old_addr since livepatching > + * might be in flight. Only clear global_trace.filter_name > + * which will effectively update /tracing/set_function_filter. > + */ > + global_trace.filter_name[0] = '\0'; > + return 0; > + } If I select a function and then clear the filter before the trace-on worker runs, wouldn't applied still be LIVEPATCH_FUNC_NOT_APPLIED? Could the clear therefore return success without canceling or removing anything, followed by the queued worker installing the original target while set_function_filter reports an empty filter? Would it make sense to track pending work explicitly and either return busy or arrange a safe cancellation/removal before accepting the clear? There seems to be a related completion-status question at the end of trace_set_filter(): > --- /dev/null > +++ b/xen/common/hypfs_trace.c > @@ -0,0 +1,741 @@ > + rc = livepatch_schedule_trace_on(payload, global_trace.func, ip); > + if ( rc ) > + return rc; > + > + strlcpy(global_trace.filter_name, name, sizeof(global_trace.filter_name)); Am I missing a place where the controls consume payload->rc after the worker finishes? The existing livepatch worker can fail during CPU rendezvous or application after submission has succeeded. Could the displayed name then describe a target that was never installed? The removal path clears the name before completion, which seems to allow the converse if removal fails. Could requested and installed state be kept separate until completion, with a way for the user to see the eventual result? What is the intended contract for changing current_tracer while tracing_on is still set? > --- /dev/null > +++ b/xen/common/hypfs_trace.c > @@ -0,0 +1,741 @@ > + if ( prev->reset ) > + { > + rc = prev->reset(&global_trace); > + if ( rc ) > + return rc; > + } > + > + global_trace.current_trace = &nop_tracer; > + > + if ( new->init ) > + { > + rc = new->init(&global_trace); > + if ( rc ) > + return rc; > + } > + > + global_trace.current_trace = new; Could a tracer change either be rejected while recording, or perform a stop-and-drain transition before reset and initialization? For a tracer using the optional start/stop hooks, wouldn't the present path leave recording reported as enabled without stopping the old tracer or starting the new one? What should tracing_on report if the new initialization fails and nop remains selected? One more target-validation question: what excludes discarded init functions from filter selection after boot? > --- /dev/null > +++ b/xen/common/hypfs_trace.c > @@ -0,0 +1,741 @@ > + if ( len ) > + { > + ip = symbols_lookup_by_name(name); > + if ( !ip || !is_patchable_function_entry(ip) ) > + return -EINVAL; > + } The new linker table appears to retain the compiler-generated entries without filtering out init functions: > --- a/xen/arch/arm/xen.lds.S > +++ b/xen/arch/arm/xen.lds.S > @@ -61,6 +61,11 @@ SECTIONS > + . = ALIGN(8); > + __start_patchable_function_entries = .; > + KEEP(*(__patchable_function_entries)) > + __stop_patchable_function_entries = .; For reference, the existing symbol_valid() in xen/tools/symbols.c retains symbols in init text too, and symbols_lookup_by_name() in xen/common/symbols.c returns matching addresses without an active-text check. Its non-FAST_SYMBOL_LOOKUP branch contains: > if ( !strcmp(name, symname) ) > return addr; Meanwhile free_init_memory() in xen/arch/arm/mmu/setup.c removes the init mapping and returns those pages to the heap when appropriate: > rc = destroy_xen_mappings((unsigned long)__init_begin, > (unsigned long)__init_end); > [...] > if ( !using_static_heap ) > { > init_domheap_pages(pa, pa + len); Could an init function's name and compiler entry therefore still pass this selection check after its code has been discarded? Since the Arm patcher writes through an alias of the original image's physical pages, could that write into memory which has already been reused? Would checking active text before accepting the target address rule out this case? To illustrate, I think this could be addressed with a small change like: --- a/xen/common/hypfs_trace.c +++ b/xen/common/hypfs_trace.c @@ -3,6 +3,7 @@ #include #include #include +#include #include #include #include @@ -266,7 +267,8 @@ static int trace_set_filter(const char *name) if ( len ) { ip = symbols_lookup_by_name(name); - if ( !ip || !is_patchable_function_entry(ip) ) + if ( !ip || !is_active_kernel_text(ip) || + !is_patchable_function_entry(ip) ) return -EINVAL; } Would this reject discarded init text before either scheduling path, using the same text-region safeguard as address-based symbols_lookup()? This only checks whether the target is currently active text. It does not validate reserved instruction bytes, reject overlapping livepatches, or establish the lifetime of a dynamically removable target. The pending operation and callback-lifetime questions above would still need their own solution. Thanks for looking through these questions. Is there a lifecycle, completion, or target-lifetime guarantee elsewhere that I have missed? cu, Bernhard -- Bernhard Kaindl From xen-devel-bounces@lists.xenproject.org Sat Oct 24 14:24:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Oct 2026 14:24:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460091.1671550 (Exim 4.92) (envelope-from ) id 1xKcfi-0007K9-3R; Sat, 24 Oct 2026 14:24:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460091.1671550; Sat, 24 Oct 2026 14: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 1xKcfh-0007K2-Vd; Sat, 24 Oct 2026 14:24:33 +0000 Received: by outflank-mailman (input) for mailman id 1460091; Sat, 24 Oct 2026 14:24:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKcfg-0007Jw-Aj for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 14:24:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKcff-00FXqa-Gq for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 16:24:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adcbf94-8faa-0a2a0a5109dd-0a2a4508acde-12 for ; Sat, 24 Oct 2026 16:24:31 +0200 Received: from [52.101.56.47] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adcbf9e-f659-0a2a45080019-3465382fc428-3 for ; Sat, 24 Oct 2026 16:24:31 +0200 Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by SJ0PR03MB998646.namprd03.prod.outlook.com (2603:10b6:a03:40c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Sat, 24 Oct 2026 14:24:27 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%4]) with mapi id 15.21.0546.021; Sat, 24 Oct 2026 14:24: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=HjgcKdEGmBatM2Lo4lTwC4Losfue4ua5MaEZezs7ZUjhjecqoYiX+TCrwL0mXkqjY/AfYgPTi4dHa5cedz4hSos0CGVDUYj94gA6LTD/jAm9Hl0kudZ6mii4W785vHGJRpB/PecoemRbN6fQobYbBj7Dx/eVOZbtNyjEFB75EkhpITo4WGpZJhQTgu8k8jAnxTdaKWQ18DmabhR36D/YaQJHUD06mlwLpfYrJV0WZTDV0P7qSz3jg4tpbmw7tPW2hiioyPC62U/O4qy+dqEhv75+ZM4qf68sObCJ8pdgn1q4BUM79ciQYCPBL/HmqtVjO18v+ihS877PHbJRoSeg4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i5GSCA2pJvjcuIIR1ofLXFbv/S35L8a2Th1hWUXAMl4=; b=TibvX/i2/FxWWgScxA6F5sC2skv9vjr/65Xr/wwJWDLIR66iMyXQ+Au9iPOvJ51bnpla1pGXv+gPWNFIX/3C4K+S/Osmk8d2QDWHlLXLavZJXTGtZMxmmYWo0iPxxCrtv3jsOX2UBpYW+1JMpMznXBtioseH806MiuGGYzqYTtE0GJNf/AlBmjVjU61UOh2X6kHWjBoJCGtFOO6tu4Cf5ypVqddaynwZDMChIimOvEUJ5bSI+bpninDJH+XiN/0msEPhsDe4m+QTxsQgQWUcNM5tGS/opJBYrpofcNScRGAU7cZRcQOdh/Bw41xUfb1pSuQPB7S5HC4w4sJ5PltQng== 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=i5GSCA2pJvjcuIIR1ofLXFbv/S35L8a2Th1hWUXAMl4=; b=kq4UfABF3imyNXdpSnhlQDF5E5OkQXmGMpR8uSVQQ9sWBsOlhpvzpO3+zDQpu3ewJSlsZINvFjVczSerxNAx1+wLFfj1Reyh4Bhyyr38pLmpZDS6l9AtjevM2u1j7rZgqjc08mM+eaFG1MUSwBzueU892P+cnKmTq1iTKJrhOQM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [RFC 4/5] xen/tracing: Add a function tracer From: Bernhard Kaindl To: Ryo Takakura Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org In-Reply-To: <20261023045655.164966-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> <20261023045655.164966-1-takakura@valinux.co.jp> Date: Sat, 24 Oct 2026 16:24:17 +0200 Message-Id: <179285185778.1706038.7602957469449476344.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792851860; l=5662; i=bernhard.kaindl@citrix.com; s=20261024; h=from:subject:message-id; bh=xK0gvg963YEcqBC2gZWFWbFM25fn0Hffi90fEOnOreE=; b=f+CInI2hMOm1/I3pfjZRQvcovX8r9UtCD1zyqsWLoQvT55ZeFkUAFlVhl0DkuNUhx2FXLP8nE GxW2+vr76GyBWPl0cII/rHkCttVO7n4OLQcDazy0FUaI6ENh2r25O5P X-Developer-Key: i=bernhard.kaindl@citrix.com; a=ed25519; pk=oIjnI/us0Uh5d/WP18V5IQq/FrLPUp+W0JAhJ9QCQIs= X-ClientProxiedBy: VIVP296CA0032.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:356::9) To LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7707:EE_|SJ0PR03MB998646:EE_ X-MS-Office365-Filtering-Correlation-Id: e7f14402-267e-4e03-6234-08df31da8190 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|261009223027099003|56012099006|4143699003|11063799006|10067099003|261021121427099003|18002099003|22082099003|3023799007|261022105027099003|261022075727099003; X-Microsoft-Antispam-Message-Info: Wylc5ICTrtSR9CSy/LBpTcqnCUu9iHn9L2OLWkmi+cWUZvwim+LXlQ7aa8ohIOXHeY7sI9M5fTxDmcq6ySR9IQvW4IG7Xp5lJYsLHRHWH8XZic4oiD5jsAl6ZI0f67yUPg6mLRCEUekRnZF72b/uLuM+1SLeNvxkdKXoM1Shb0+z0rCzgFyEqqS/6R/biPtCYn1TFrK+OLwF8g9nLkGPKEXQUsJ//LVjdBL0ZsNJqFqSe/kVx66O0S6CSmV2PW4Rk/N1Xq1E2hZ7yEJFHI9MLduNoW7R3qHWNoq7H/Qo9+e+GVhiaJoafrqkfIWV2F3vydw0AL1Q0mGKxo221LyyBAIrboRbjZ3noGmGOVcsQJ4sl++of7iS7lyTCriOaBWi/CAeQ5rNkUOdRnDRyQrufWhGfLNKUWkNx8VRmqtDupkqB/QP2UB4wmnjBdTgQ4M/gDNAs+fBnc+zVNh8EWN3gebBPTZtAeb0ReO+nyD2tlHfpZhsaeU+SrUgWmpSqEU4jrC1ZG9z1NdY4+GoQWesvTvFFEOn1SApnpD3OYDIBqRYSdz9orFA8AmE6vWGmLOLTMeQXt6DvcO8SqFKPj5vhHXX5MNLzDDQc9PkcdPmlvW5ylcSTrirXxG3E/sdpAj85EevibdJTMbiwqYOC46q+PUTwThpUCY1tJOpGPSFb/4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(261009223027099003)(56012099006)(4143699003)(11063799006)(10067099003)(261021121427099003)(18002099003)(22082099003)(3023799007)(261022105027099003)(261022075727099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RW5UR1dNcnRiVDJocTIxT3ZMN3lLR1NWK3RrWVc1bjVscWs5bHVxTWJEci9R?= =?utf-8?B?bngzcHZuTStSaTVUQmNiWG95OGR4OGFUa2VlT0NKWCtxMGdPeHpyeWlQRHRq?= =?utf-8?B?Q3hYUTVQR29ZSU5sWDJsbGhtUE9SL3BsUXhtbUhKeHZaY0pkV09GdDNCWTlZ?= =?utf-8?B?Qk84alF1enBpempjcm5uMWtlMnhGYnBIWXJvR0ZtRWRtQjdyYzlEZU9nZWpD?= =?utf-8?B?NzhTb3RKbGI4dXJSRWZKdmpVUzIyL3NoRHdER2xhNnBqT1RQTkJ2M0d2Q0Nm?= =?utf-8?B?RlpPVys0OFI0emUrb2ZqN0lBV2tqczhSVXJVSGdsVHhrcGs0SG13UDU2ZGZr?= =?utf-8?B?YVNTRHRCWHRHYnprNFNSenlIRnRWOGcwcEZNSTFncHV1TzE3ODFRd203T0dI?= =?utf-8?B?SXJrQ00zcm1Dc0E0eWtINVJmTW1KQm9tNSt5TFBoS3k5a0s1QnVSZUpxT1pj?= =?utf-8?B?RmxGdVUwcXB1ZC9idlVjVzExeHdwaW5OdnpPZnFzQVlaOGJxTlFncmJKLzFu?= =?utf-8?B?TmZTOTJkQWJlSWtBcUJxUVQzaVoyaTd1NHZRajdpaGlWbTd0dnV0WkxLVDhh?= =?utf-8?B?K1BSZ3V6SmVTdHZrdjVVUndpd29mSzZ6a2pVYUx1UHh1L2xHZnd5NUZLNm1Z?= =?utf-8?B?Nk1CK1ZwRGllUmVGajNkRjR5czFGUEhiNE1DZG9kK3c4dDdVSndXbHRURG12?= =?utf-8?B?RkJINng0U05sc2Z4L0U0aXhlclhta0FXWElXaVhINTc2bWdwbGVwU1JSYkxv?= =?utf-8?B?NHhDbzBDeVV6YnVoanBMNG13RDRaS2psS3NNNHlzbXgzRjVSL01qRU1sSGVK?= =?utf-8?B?RForTmxzU2V1ZHNVR1o3bElvQ2poZmQwdnJPajFUN0ppaEFzTzZjQURCRWtj?= =?utf-8?B?dXRCYnQ1OFp6MHBRSjAveGkwM3lUSlBFZ1dkT2NodEpyalBGWitSL0FuTTBC?= =?utf-8?B?aTBXRVdIMXY0UXpWMjFxMk5kY2RiZ3BRZnZGYjVjL0d4RzNkN3dGdVBhMFMx?= =?utf-8?B?bUdXOGVlYWJTbEFqcHhSY25BcnFaK2xheXQ5eDRocDNFUVhzYVJQbE5xS2lJ?= =?utf-8?B?UzVEYk90K2xxbnBVTndxRlE0OGVweFlteEgxRzlrcFB0Q3NPS2lkRUtucWR6?= =?utf-8?B?c3BxSjBGZUtyb3ZaV0JuTlFNZVlVTGs5T1J2a3I1OTBvclBIWVZaYXgxZjQx?= =?utf-8?B?Q3F1UkRFUkRXYjVYNDg4V0dlZ2V6M25pcVQxMUl5YlRJa0NVaFptYnNQbGxx?= =?utf-8?B?dnRFU1RZQzZhVGlDbjFnbnVIR1lkQ1RZMjc3Q0R0N1JTNHRjVjRvZlNYNWdz?= =?utf-8?B?TGdwZHZMUU9GaDVIZU5SVWtjRnhPcE9WT2FzRUNxalNSMitkdW84ZFVURnox?= =?utf-8?B?alFPY1NvSmFKbkRjaEV0M041UytmWnJ3V3FjMDZicjN0VlZ3aFJoZThveXVN?= =?utf-8?B?Z3VJMGF6MnJGYjJkZEtyODMzc3BkRE53UGZEZWVOdjd5TkoxVzBWbWVudW1w?= =?utf-8?B?SjVHVExtaFV1MWx4WDE0cXZPbWVyaSt6bVNrbkV3ZGx4YWlkTzR1WnFMOGdR?= =?utf-8?B?WU5iUEdtaUhseE54bEFIRGVQMmFmdFhqVVgvSlZ0clRTbHpMa0hVdW5wd1Fx?= =?utf-8?B?eTQwYWlEQTJrNVpWNmttYlc3NnJQNHNIY0hPVDlsaCs1YlJGOTNUTWNSQjBh?= =?utf-8?B?RzNKdkN2NHhaK0t5UjZZb0oxZDdsU29zR2JDMWZjc2laTWF6Q3BFZGZiQ0Rl?= =?utf-8?B?TmROM25IYTFJbzVDYmlrMUZKWkh2QmxqZlJJRnh0T0xvYU9ZRVdoUHFTV2pp?= =?utf-8?B?UVkva0Q3K09GZ2dWMjZiK1ZBZ3I3YStsWkNOS1RmS0JKNmdZbTZwVGRHQ3Nk?= =?utf-8?B?b1dybTkxaTZVTDMvcEpNNk5ubENkT3BYdVBZZHdQdUdsRmpTd3JpZ20vT2NO?= =?utf-8?B?SVQ3dENMelpaeit0K0k1NmlvNU5PQzY4V0FyOHFjSTdKUlB5Ykl2T2VxdnAw?= =?utf-8?B?UUpSSFVjQTlmOU9oNzNSVEFHdk1Wdmt0WVNZeXRvcGE1ckdvVDhueXFaZ1Fm?= =?utf-8?B?MDdZaXhIcFZwOVVtTlNjT1FwUndlTW0vNEYrYitQdDNOZ0hBLzl3UTNYVWV0?= =?utf-8?B?NmtWeDgxb3VXb283RUFxOEJydUVWYkFoekZaWkJGN1BDSXBCNHYySTVuOGdl?= =?utf-8?B?cnVtcExuR0NPUHYxL2tHSkl2T0tUY04zaW1JVE5ZTTB4OHdLc1dmamRVcUEv?= =?utf-8?B?cERkNTNsbkl2SUNnakI4TndZM3JxQ0RRWldQSjhLVnIwaHk2d3pZWitjUGlB?= =?utf-8?B?WGVicEptU0cyalNkMUFxWDgxa21RTURSeEwrazBWOWFMRHc1OXlsS2ZXU3Vy?= =?utf-8?Q?gPARVuubax//oOXw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7f14402-267e-4e03-6234-08df31da8190 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2026 14:24:25.8158 (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: PHzzg4H7YABFApDp+DvVLpWYFQOz3sw7gDqdYiUz5p1/GriWhGdq8tWNSC8/pdBvuvtcIpuUWzIFSBD6MMAFzuS7CmIqWlFAtCOEmXZdlcc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB998646 X-purgate-ID: tlsNG-c1860d/1792851871-CF15E87B-38CFF08C/0/0 X-purgate-type: clean X-purgate-size: 5662 Hi Ryo, Thanks for including a function tracer to try with the new interface. I'd like to help check the buffer handling, with LLM assistance as I'm still getting familiar with this area. I may have missed a guarantee around stopping recording; could you help me check the following? > --- /dev/null > +++ b/xen/common/function_trace.c > @@ -0,0 +1,274 @@ > + if ( this_cpu(function_trace_recursing) ) > + return; > + > + this_cpu(function_trace_recursing) = true; > + > + buf = &this_cpu(function_trace_buffer); > + rec = &buf->records[buf->head]; > [...] > + buf->head = (buf->head + 1) % FUNCTION_TRACE_BUFSIZE; > + buf->written++; > + > + this_cpu(function_trace_recursing) = false; What ensures that a callback which has already passed the dispatcher's tracing_on check has finished before another CPU reads or clears its buffer? The tracer registration does not appear to provide a stop hook: > --- /dev/null > +++ b/xen/common/function_trace.c > @@ -0,0 +1,274 @@ > +static struct tracer function_tracer = { > + .name = "function", > + .init = function_tracer_init, > + .reset = function_tracer_reset, > + .clear_trace = function_tracer_clear, > + .get_trace_size = function_tracer_get_trace_size, > + .print_trace = function_tracer_print_trace, > +}; For reference, tracing_set_on() in xen/common/hypfs_trace.c, introduced by the preceding patch, disables recording with: > if ( tracer->stop ) > rc = tracer->stop(&global_trace); > } > > if ( !rc ) > global_trace.tracing_on = on; Could an already admitted callback still hold a record slot when this clear resets its CPU's counters? > --- /dev/null > +++ b/xen/common/function_trace.c > @@ -0,0 +1,274 @@ > +static int cf_check function_tracer_clear(struct trace_context *tr) > +{ > + struct function_trace_cpu_buffer *buf; > + unsigned int cpu; > + > + for_each_online_cpu ( cpu ) > + { > + buf = &per_cpu(function_trace_buffer, cpu); > + buf->head = 0; > + buf->written = 0; > + } If that callback then finishes writing its old slot and updates head and written, could the reset counters describe a different slot from the one just filled? Could the print path likewise observe a partially written record? The per-CPU recursion flag seems useful for nesting, but wouldn't it leave these remote accesses unsynchronized? Would a stop-and-drain protocol shared with callback removal let read, clear, and reset operate only once the buffers are stable? There also seems to be a size-check consequence of a late writer: > --- /dev/null > +++ b/xen/common/function_trace.c > @@ -0,0 +1,274 @@ > + for_each_online_cpu ( cpu ) > + { > + buf = &per_cpu(function_trace_buffer, cpu); > + count = min(buf->written, (uint64_t)FUNCTION_TRACE_BUFSIZE); > + size += count * FUNCTION_TRACE_RECORD_TEXT_SIZE; > + } The existing hypfs_read() in xen/common/hypfs.c calculates the size and checks the guest-provided length before calling the reader: > unsigned int size = entry->funcs->getsize(entry); > [...] > ret = -ENOBUFS; > if ( ulen < size + sizeof(e) ) > goto out; > > guest_handle_add_offset(uaddr, sizeof(e)); > > ret = entry->funcs->read(entry, uaddr); The trace_read() callback in xen/common/hypfs_trace.c then samples the tracer size again, allocates that size, and later copies that amount: > size = tracer->get_trace_size(&global_trace); > [...] > buf = xzalloc_array(char, size); > [...] > if ( copy_to_guest(uaddr, buf, size) ) > rc = -EFAULT; If a final callback increases written between these two size samples, while the ring is not yet full, could the second size exceed the length already checked for the request? Would an owned snapshot, or a shared stable-size protocol, keep the checked length and copy consistent? Could the snapshot also use a stable CPU set? The sizing, clearing, and iterator construction each traverse for_each_online_cpu(), and the iterator retains buffer pointers while producing the output: xen/common/function_trace.c: > @@ -0,0 +1,274 @@ > + for_each_online_cpu ( cpu ) > + { > + const struct function_trace_cpu_buffer *cbuf = &per_cpu(function_trace_buffer, cpu); > + struct buffer_iterator *iter = &iters[nr_iters++]; > + > + iter->buffer = cbuf; > + iter->count = min(cbuf->written, (uint64_t)FUNCTION_TRACE_BUFSIZE); > + iter->start = cbuf->written >= FUNCTION_TRACE_BUFSIZE ? cbuf->head : 0; For reference, get_cpu_maps() in xen/common/cpu.c uses the CPU-hotplug lock rather than the HypFS lock: > bool get_cpu_maps(void) > { > return read_trylock(&cpu_add_remove_lock); > } Would it make sense to pin the relevant CPU set while taking a snapshot, and use that same snapshot for sizing and rendering? What should happen to records on a parked offline CPU? Could clearing only online buffers allow its old records to reappear when that CPU comes online again? It looks like there is a design question of the stop-and-snapshot contract to drain callbacks safely in their permitted contexts and preserve one snapshot across HypFS's size check and copy. Locking each traversal separately would still leave the gap between the two size samples. Thanks for checking these interactions. Is there an existing mechanism that already keeps the buffers and CPU set stable across these steps? cu, Bernhard -- Bernhard Kaindl From xen-devel-bounces@lists.xenproject.org Sat Oct 24 14:36:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Oct 2026 14:36:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460102.1671557 (Exim 4.92) (envelope-from ) id 1xKcrU-0000ct-0y; Sat, 24 Oct 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 1460102.1671557; Sat, 24 Oct 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 1xKcrT-0000cm-UZ; Sat, 24 Oct 2026 14:36:43 +0000 Received: by outflank-mailman (input) for mailman id 1460102; Sat, 24 Oct 2026 14:36:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKcrS-0000cg-3x for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 14:36:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKcrR-00DAEb-HD for xen-devel@lists.xenproject.org; Sat, 24 Oct 2026 16:36:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adcc274-2eae-0a2a0a5409dd-0a2a450b956a-4 for ; Sat, 24 Oct 2026 16:36:41 +0200 Received: from [40.93.195.63] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adcc278-b7e8-0a2a450b0019-285dc33f571a-3 for ; Sat, 24 Oct 2026 16:36:41 +0200 Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by MN6PR03MB7624.namprd03.prod.outlook.com (2603:10b6:208:4fb::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Sat, 24 Oct 2026 14:36:37 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%4]) with mapi id 15.21.0546.021; Sat, 24 Oct 2026 14: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=xtPDjdySQQwLPvmygHqtVTZGo9eDhkfIrFMswvjYE3bWjJCT7rsyHJV4f91PO5Dgt8FCA5fEzEgxuAKJKqY7P/mK1W2/HlWvLksREa6sA3HXXZfE6SMg8qpYLEl/B+df3SHFeXS7jgdI4qzRdfIhRouz5T3B6IzMxzl7smysCJE6vhhQdqB/dF5VKv1pOQL4e4k6QIU1J/BUfwHTg4SwtFZfnsTdYKB+Kezex1bpHLS0khp7FGf5N5RPLaBzIDakFmGNlBpijaQ4AFdELXYCruUyZhBGOv9HLLKO4BwjfomU+krrJzlX4RgXqAFFx60nX4u+IQb9ehVKPzW+BtgPEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SmCUBQtqTA/faNLlTkrF0Hobry2OualSC0eSMeuMgFQ=; b=yti74vuE/Mg06lT7weQb+C7GQ4vY9Qv/zzRKvCCtlpmZ9Bo1fwXJYa6RWdEOYhw2FYbcTAt0qIrRT4TGmP3hiPqcbjnm4WHr1TnXCV1HZbVa7o71AsYkbYuIgDRXVhUiVu0yQz+in2piKyAx0vY7SAPOtAEMJ5aq8uXE9PhhwE+OHciR8s+Zw/ehzRa4xflUFclxhr3ZH08+33YMIVv34U736xvNnOE8eYmCF8iZ2qH3WpVhtYkK2XQJlqnyiKNJ6BpI1gzz/TZzFJPXSaJpHGX1XyjvoScc94Il1vGlPWHNy4mdrKHP7Y1PQnBotQ/QStlGWDX14HA/HqeOWM08JQ== 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=SmCUBQtqTA/faNLlTkrF0Hobry2OualSC0eSMeuMgFQ=; b=DmOXdSdSEhy1JGoPRrFIUcNmIGgRdWadtvxDaXOQO9WKpws/IY/cuMN5nJTi7lITgk3ktoMcvtnhSZWpHX6dvC/4HGqyAHiRZrHaJYrEQTefFIkX5DoPz+d7BbG33fDUilvys4AgeW/kPKoKk3cvK0tGB+oi17hP3j0HuCT4dsw= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [RFC 5/5] xen/x86: livepatch: enable attaching callbacks From: Bernhard Kaindl To: Ryo Takakura Cc: xen-devel@lists.xenproject.org, roger@xenproject.org, ross.lagerwall@citrix.com, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, teddy.astie@vates.tech In-Reply-To: <20261023045808.165276-1-takakura@valinux.co.jp> References: <20261023044809.162759-1-takakura@valinux.co.jp> <20261023045808.165276-1-takakura@valinux.co.jp> Date: Sat, 24 Oct 2026 16:36:30 +0200 Message-Id: <179285259082.1706038.15527286146285697701.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792852592; l=8401; i=bernhard.kaindl@citrix.com; s=20261024; h=from:subject:message-id; bh=+fay1ejbAGa09W59MkkT5Kd1/LcFn5jvvQhnTsn0IaA=; b=UYy7qtRKJDf1ceZMBoQ32BdINJoaCeYyxvgsHsO0NOKH9kz+pj8/rzHu88JrT7xejqqh9271u ozenAtdAFLLBkqAdfPpQGQTUmF7HpxFRto6FcUyEjA0mIH/NZqf4D5V X-Developer-Key: i=bernhard.kaindl@citrix.com; a=ed25519; pk=oIjnI/us0Uh5d/WP18V5IQq/FrLPUp+W0JAhJ9QCQIs= X-ClientProxiedBy: VI1P190CA0039.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:1bb::20) To LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7707:EE_|MN6PR03MB7624:EE_ X-MS-Office365-Filtering-Correlation-Id: 0083b2e6-4f3f-4894-fff7-08df31dc3586 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|7416014|366016|261021121427099003|6133799003|18002099003|261021130227099003|22082099003|261022115727099003|261022113327099003|261021135927099003|3023799007|261021123027099003|261009223027099003|4143699003|11063799006|10067099003|261021133027099003|261022105027099003|56012099006|261022075727099003; X-Microsoft-Antispam-Message-Info: X3fubiCXlMY5Oqo5KkWEJcHXRwabFgctQjvBAZOIoeXnqtGnO3MYJCLBysLRWaZjigurMpI5795eIVaotTeqBRZgb65Iy3fVt8uQJinwcDzFvK3SHzu2dBkSLLsmPArUxCLiKvnFhrjq5jhg2rLOkGLvbayQn2FUrud+xOZtuU/RYRCBo+oZzj13GbZqzlQeLDJorfHsj2161WZLSsgKBkWb/+D7ejltjWZuVYQcFPmhhsWxjp94aled24R5W0LQoF3R8Bt74Nzz+a0o+chqK45sr9uocEcEcpipec2DZFay8vWnmPOCyRs+wHd69ZllZCyRw9zneQ+8/FLy3nSfQNe45Kid1PEX9J09BIoXz5PfsyEfRkDXcpb4/FYdq3Kxdn3sHjeG5fv5H7SsvZIrG7kvUP4sHRayIhAPKawFsnY/sKkq5iFaVbWAF8jHbH3VKPyIQf29854K8/+RyAyE4OYIIHxx/3yJV6kqLrPOfB/7mlj6gup200basLUv0bbCLS+K2/+ca5cTQGt6tt+8dmHBgNhXutBsIYyIGd+oLs4cYozotpjQYmgTIMrNMCyvxyqM8dA5W4WTdymNASl5k5COex5dhH7plSKE1eqkTPz4lXzj4xSmYCRaP94WVwrvk2d/DzK3aj6T+GH8Z7gMk2+bAHJ6zL3c7dIS+QZo6Ek= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(7416014)(366016)(261021121427099003)(6133799003)(18002099003)(261021130227099003)(22082099003)(261022115727099003)(261022113327099003)(261021135927099003)(3023799007)(261021123027099003)(261009223027099003)(4143699003)(11063799006)(10067099003)(261021133027099003)(261022105027099003)(56012099006)(261022075727099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NUVPUW9RYVkvTUJ3UTRKeUtHelF2RDBSZGJwNk1mZFhIZldranI5N2JCMlFW?= =?utf-8?B?dStoUU1UNjdnMXlzckM1NmQ1VnA2MUdCZXVtaTlrVDNZbzQxVUplekZnNE5X?= =?utf-8?B?eEtHZURvZXdtcFhnK1dOUTFKd0lmd21PVGJ6REhyN2RCSnUzZTFZRFJQVW92?= =?utf-8?B?Z0JmUCtrYnNGWTh0L05KdHRJNjFhYi82UloyOHIxRVJnWEFHTkQyR1lhZ25Y?= =?utf-8?B?TmlBajlpOUdXcmVBMEw0a1pWMVhqUWYyWlQzd2krTnBBdzFUWVpBZTBUN0tp?= =?utf-8?B?cnpLUGhVRlJab1hWcUc2UDlDNDc2NjFPb2t0OE96bTE4MW9jWDh4TEliWWR6?= =?utf-8?B?M21xQVI2VEZSU3lsRmw0M2E3eW9mSHBUUXFVcENoN3hSWVZSbEJvR2tPSCtV?= =?utf-8?B?d2JaZThaTjFDVE85ZFVwSDNpaGFrV3hkTkI1dVlZeTRwbmxuN0l0TFpvNmsw?= =?utf-8?B?NXNrRWQrT1MzZFFkdXZtWExFdFQ2KzhhelhaQzV2ekt1NWlaN3VidUdreXBy?= =?utf-8?B?SUFDK1hjRThlRW00Uk9kcTJCQ0taVEs0RjAvQTFHQjZ6ZmVCdThaZUVEZnQx?= =?utf-8?B?czJKYUxEc2xESldJYmZCLzNsbnlZTTh4UUMyT3FnZFF1UDd5bm5FZlUwZlM5?= =?utf-8?B?a2lzaHpEb1Vsd2NjVS94L1RhYVdBTkY0TzdaanpkWEc3WnVGdk9zMUZ5TXcx?= =?utf-8?B?aHFtZlUvRndHUGxMcENzbHZhazZGMy9RRFl5VllXU2RzV0J4ZzZidGhaME5P?= =?utf-8?B?NTRyR3dCSlZDd0lWcFBqZXhYZC8xdEZNVXBidU9ZTTJ1N0UrY1F6cmRTM0Iv?= =?utf-8?B?Q0FqaGo3Yjcvbi9SR25hekkxdHJRMGw1ZzFOa2dVc0FkR1N6QnByZWZVaTFm?= =?utf-8?B?bThWZFV5SHNUanB4QXZUNnZjUzN1RTF4K3hBVXpXMG1ZSjJwZXVpYm1jOUZK?= =?utf-8?B?TmZvNC8xN1ZSTXMzakFRcldVSVVzZE05VlNqUlZvVWVvakJFZ0dvbzR5Yita?= =?utf-8?B?bFl0eWd2bVAxM2c3Vml1V29kVUZ6bUZuT3NYOHFReGt2WTFnRFFXcHNYMThs?= =?utf-8?B?U3lJS3NGNjBDeXFZNW92K0Uzbys1NllTSWgvTk4yUXd5NWpLcG92NUNlQ3Ay?= =?utf-8?B?REM2SmJENStZYUlrOGdHcnpWWWU4Zzl4MjNRd1Arc0NvRUVPbCtleCs3bHl0?= =?utf-8?B?Nm80Q0gzMVpveThWU09LelNXeGowN3loblVsaWJFQzdlYkJJK2c1S2YrckNN?= =?utf-8?B?bGxKK2RWckxhMjAvazZQZlF4cUpoSXZNQzZFaDhOSmtCSW44V0dERWJIVUx4?= =?utf-8?B?VUkwYW5xZG56dFFwcjkzWDNTaTBBdWZwMWFUNnNxUkRWWm0wUEVvYWV4WnZx?= =?utf-8?B?TndCNXR4N0Q3eVQxNU55TWk3ZHlLT2RsR284aitXb0ttUGl0Q0dIZ1k4TXRZ?= =?utf-8?B?V2tKNERLTGZoVkZjRW9sVC9OeEJtR1N5NUVNM2VtNEVXR1lCS1VUN3dkSGVE?= =?utf-8?B?aXJJMHd2ZnNFeFJ6SkR1YWo4UE91am85NkJCZDZkUWF3NytCTjg4Szk2a0No?= =?utf-8?B?b2xFcWdmTzBjZ2dJWG5MRkswNmVlWWpYblE4eDN6TzdWWnlmc2ZwM3VGcTVt?= =?utf-8?B?UXVpOTlvUnB5MWluOG44b052a1FLZndERUF1RGRRdzNJV2loZldFSlo4Rm96?= =?utf-8?B?ZGpETDNXcEVBTzAvR3dTSkNMdnNPS0lZbmNJUTRHVDhiYURoRWxMUGlqSDBX?= =?utf-8?B?NG5jak5TMDFobTJqWnkwOHZzQ3JWdFRRem1yMVNSWG14ekViTFErb1hnZHRI?= =?utf-8?B?SWUwRU5FQ292ZlM5MDVHL2N4OE1NakxHQ0YrQlcwbzAwUWVjeCs0MnNzSFU4?= =?utf-8?B?djRhNXRPMFN0ODBVVnZwazU0RFplQnEwdU1vRjRaekl6M3lKajRxbENSbngx?= =?utf-8?B?eE9DVTc1N3ZGMXBlS25ST0VtT1NPYVcwbTVqTGFCODJNZXNvTmZNRjc5dkVP?= =?utf-8?B?MU9hQmNkSFhIUlQ0SG1kMUFaYm9sT1R4bmo2ckpCcjJCYkZTenZkck9hNmNw?= =?utf-8?B?L1VvOGZTaWVzQkV5SVhCaHR1ZDJOR2tTekh1a1ZNWjlacmh1MFRIaERma2lW?= =?utf-8?B?UHdJTHJkSmVCVWNCQWlVcDM4OU1MazFNTkc5K2p6Z2FZMFZ3dEpGM0J0UDBJ?= =?utf-8?B?Z084UEdwbTJsam40dnhOZzNmNk1jT21PNnZNRGorVHc2d1FZRWNPaWxLMDB6?= =?utf-8?B?eWpKejVjam5wU1dEM1dxRGtoQUx0R3NDL1FNRVVBaStNbTRoQ29Zb3BrZ2tC?= =?utf-8?B?ejBhSVVTTjBXWDBsNEJzSmgvcHg0L0hEdjJtWG9sWXhZUjdVQ2d3NkVoVjMz?= =?utf-8?Q?Xar/GAroAR1yB0Bo=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0083b2e6-4f3f-4894-fff7-08df31dc3586 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2026 14:36:37.2645 (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: 38wsK1nJfXSrSAvCyA1ITi8vk7TGtSZgTmVrLIH0CtEs0x545jWAUCIC3j8Zownj9haZ/XF+o9QC3l97f3ukHVhQoqrKARvTEnVDQQMavQ4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7624 X-purgate-ID: tlsNG-42698a/1792852601-AB4D39EA-6B3C4D94/0/0 X-purgate-type: clean X-purgate-size: 8401 Hi Ryo, Thanks for including x86 support alongside Arm64. I'd like to help review this part too, although I'm still getting familiar with these paths and have used LLM assistance. Could you help me check a few interactions with tracing itself and the existing x86 conventions? > --- a/xen/arch/x86/livepatch.c > +++ b/xen/arch/x86/livepatch.c > @@ -365,6 +369,35 @@ int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type type) > +#ifdef CONFIG_X86_PATCHABLE_FUNCTION_ENTRY > +unsigned long arch_livepatch_trace_entry(unsigned long addr) > +{ > + if ( (is_endbr64((const void *)addr) || is_endbr64_poison((const void *)addr)) ) > + addr += ENDBR64_LEN; > + > + return addr; > +} Could this helper itself be selected as a tracing target? It appears to be an ordinary function in an object compiled with patchable entries, and dispatch now calls it before reaching the callback: > --- a/xen/common/hypfs_trace.c > +++ b/xen/common/hypfs_trace.c > @@ -141,7 +141,7 @@ void trace_dispatch_callbacks(unsigned long ip, unsigned long parent_ip) > - if ( (unsigned long)global_trace_func.old_addr != ip ) > + if ( arch_livepatch_trace_entry((unsigned long)global_trace_func.old_addr) != ip ) > return; > > callback = global_trace_func.new_addr; If the helper is the selected target and recording is enabled, could this call enter the trampoline and dispatcher again, which then calls the helper again before the recorder's recursion guard is reached? What would contain that recursion before Xen runs out of stack? Would excluding the helper from instrumentation on both architectures help, together with checking the rest of the pre-callback dispatch path? The Arm64 helper introduced here looks relevant too: > --- a/xen/arch/arm/arm64/livepatch.c > +++ b/xen/arch/arm/arm64/livepatch.c > @@ -497,6 +497,11 @@ int arch_livepatch_perform_rela(struct livepatch_elf *elf, > #ifdef CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY > +unsigned long arch_livepatch_trace_entry(unsigned long addr) > +{ > + return addr; > +} To illustrate, I think the helper's compiler-generated tracing entry could be excluded with a small change like: --- a/xen/arch/arm/arm64/livepatch.c +++ b/xen/arch/arm/arm64/livepatch.c @@ -497,7 +497,8 @@ int arch_livepatch_perform_rela(struct livepatch_elf *elf, } #ifdef CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY -unsigned long arch_livepatch_trace_entry(unsigned long addr) +unsigned long __attribute__((patchable_function_entry(0, 0))) +arch_livepatch_trace_entry(unsigned long addr) { return addr; } --- a/xen/arch/x86/livepatch.c +++ b/xen/arch/x86/livepatch.c @@ -370,7 +370,8 @@ int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type type) } #ifdef CONFIG_X86_PATCHABLE_FUNCTION_ENTRY -unsigned long arch_livepatch_trace_entry(unsigned long addr) +unsigned long __attribute__((patchable_function_entry(0, 0))) +arch_livepatch_trace_entry(unsigned long addr) { if ( (is_endbr64((const void *)addr) || is_endbr64_poison((const void *)addr)) ) addr += ENDBR64_LEN; Would this remove these helpers from the compiler-generated entry table, using the same attribute as the dispatcher? It only excludes these two functions from compiler instrumentation; it does not provide a general recursion guard or audit their callees. Uploaded trace payloads would still need trace-site validation to enforce the same exclusions, rather than relying only on HypFS's entry-table check. Separately, does the new trampoline need the mitigation-aware RET abstraction used elsewhere in Xen? > --- /dev/null > +++ b/xen/arch/x86/livepatch-asm.S > @@ -0,0 +1,60 @@ > + popq %rax > + popfq > + popq %rbp > + ret > +END(xen_livepatch_trace_caller) For reference, the existing asm/asm-defns.h, included through asm/asm_defns.h, contains: > #ifdef CONFIG_RETURN_THUNK > # define RET jmp __x86_return_thunk > #else > # define RET ret > #endif With CONFIG_RETURN_THUNK enabled, wouldn't a literal ret here bypass the configured return thunk? To illustrate, I think this could be addressed with a small change like: --- a/xen/arch/x86/livepatch-asm.S +++ b/xen/arch/x86/livepatch-asm.S @@ -56,5 +56,5 @@ FUNC(xen_livepatch_trace_caller) popq %rax popfq popq %rbp - ret + RET END(xen_livepatch_trace_caller) Would this preserve the configured return convention with the existing include chain? I also wondered about the C stack alignment at the dispatcher call: > --- /dev/null > +++ b/xen/arch/x86/livepatch-asm.S > @@ -0,0 +1,60 @@ > +FUNC(xen_livepatch_trace_caller) > + pushq %rbp > + movq %rsp, %rbp > + pushfq > + > + /* Preserve general-purpose registers. */ > + pushq %rax > + pushq %rcx > + pushq %rdx > + pushq %rsi > + pushq %rdi > + pushq %r8 > + pushq %r9 > + pushq %r10 > + pushq %r11 > [...] > + movq 8(%rbp), %rdi > + subq $5, %rdi > + movq 16(%rbp), %rsi > + call xen_livepatch_trace_dispatcher For a build using the normal 16-byte C stack boundary, wouldn't the traced function enter with RSP eight modulo sixteen? The injected call then makes it zero, and these eleven pushes leave it eight immediately before calling C, rather than zero. Would that give the dispatcher the wrong incoming alignment in such a build? The existing xen/arch/x86/arch.mk makes the reduced boundary conditional: > # If supported by the compiler, reduce stack alignment to 8 bytes. But allow > # this to be overridden elsewhere. > $(call cc-option-add,CFLAGS_stack_boundary,CC,-mpreferred-stack-boundary=3) Could the trampoline establish the dispatcher's required alignment without assuming this reduction is active, and restore the exact original stack afterwards? Is there another build constraint which rules out the 16-byte case for this feature? Finally, could the x86 entry checks address the same restoration issue as the Arm64 path discussed on patch 1? > --- a/xen/arch/x86/livepatch.c > +++ b/xen/arch/x86/livepatch.c > @@ -365,6 +369,35 @@ int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type type) > +void noinline arch_livepatch_apply_trace(const struct livepatch_func *trace) > +{ > + void *site = (void *)arch_livepatch_trace_entry((unsigned long)trace->old_addr); > + const void *new_addr = xen_livepatch_trace_caller; > + uint8_t insn[ARCH_PATCH_INSN_SIZE]; > + int32_t val = new_addr - (site + ARCH_PATCH_INSN_SIZE); > + > + insn[0] = 0xe8; /* CALL rel32. */ > + memcpy(&insn[1], &val, sizeof(val)); > + memcpy(site, insn, sizeof(insn)); > +} > + > +void noinline arch_livepatch_revert_trace(const struct livepatch_func *trace) > +{ > + void *site = (void *)arch_livepatch_trace_entry((unsigned long)trace->old_addr); > + > + memset(site, 0x90, ARCH_PATCH_INSN_SIZE); > +} The existing arch_livepatch_verify_func() in this file checks the replacement space like this; these lines are not added by this patch: > uint8_t needed = ARCH_PATCH_INSN_SIZE; > > if ( is_endbr64(func->old_addr) || is_endbr64_poison(func->old_addr) ) > needed += ENDBR64_LEN; > > if ( func->old_size < needed ) > return -EINVAL; ARCH_PATCH_INSN_SIZE is five in asm/livepatch.h. Am I right that this checks space but not whether the original bytes are reserved tracing NOPs? Could an uploaded .livepatch.traces payload name a sufficiently large uninstrumented entry, have real instructions overwritten, and then lose them when revert substitutes five NOPs? Would shared trace-site validation for uploaded payloads and HypFS requests help establish the original bytes and reject overlapping ordinary livepatches? Could the applied offset and restoration state also be retained rather than inferred again from a potentially changed entry when reverting? Thanks for taking a look. I may have missed a guard or architecture constraint elsewhere, so I'd appreciate your view on these cases. cu, Bernhard -- Bernhard Kaindl From xen-devel-bounces@lists.xenproject.org Sun Oct 25 06:37:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 25 Oct 2026 06:37:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460430.1671568 (Exim 4.92) (envelope-from ) id 1xKrqe-0003A7-BM; Sun, 25 Oct 2026 06:36:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460430.1671568; Sun, 25 Oct 2026 06:36: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 1xKrqe-00039x-5R; Sun, 25 Oct 2026 06:36:52 +0000 Received: by outflank-mailman (input) for mailman id 1460430; Sun, 25 Oct 2026 06:36:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKrqc-00039r-Rn for xen-devel@lists.xenproject.org; Sun, 25 Oct 2026 06:36:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKrqb-00CqCQ-QS for xen-devel@lists.xenproject.org; Sun, 25 Oct 2026 07:36:49 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adda339-bab6-0a2a0a5309dd-0a2a4503d954-14 for ; Sun, 25 Oct 2026 07:36:49 +0100 Received: from [40.93.196.45] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adda37f-fae8-0a2a45030019-285dc42df94a-3 for ; Sun, 25 Oct 2026 07:36:49 +0100 Received: from BY5PR03CA0027.namprd03.prod.outlook.com (2603:10b6:a03:1e0::37) by AT6PR12MB026081.namprd12.prod.outlook.com (2603:10b6:170:113::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.21; Sun, 25 Oct 2026 06:35:01 +0000 Received: from BY1PEPF00026957.namprd05.prod.outlook.com (2603:10b6:a03:1e0:cafe::4e) by BY5PR03CA0027.outlook.office365.com (2603:10b6:a03:1e0::37) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Sun, 25 Oct 2026 06:35:01 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BY1PEPF00026957.mail.protection.outlook.com (10.167.244.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Sun, 25 Oct 2026 06:35:00 +0000 Received: from jim-System-Product-Name.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.53; Sun, 25 Oct 2026 01:34:56 -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=p4F0MHAOjqmYqJT5vh+kaJKzl5zXhu5EmskLsAmWzkERj3BN4w4MZXrNkKqAWihu0ve6eq3+NJKZgCHY3AB5z5g894ZoLfI/cRLHOe2Berv4Vr5EJQAhgS0nPsoey0F1Noaj/NHM2/h8Aqv7CLnNSdOrh1XSWgVBLoqiDYYR0aZ4K2GK4vWWGoxDWVkEPgRCfoNlKkxw2GESdd5JNhXdzLDdup/TEjmKg2anPtYWT6vIzoC3DGy8+DL6cnE1Z0c9+Bxr3rY0OPstCqeIeWhq/q/hGW5DBwwurtMzOQjGtvIPC4mzWpgjyMMt3kBdItZUyQfRv8K8jPx439/cRsk1aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9GijEse6hff60BEqBgFxft9+bDZ0t5yGKOBH3CY1qHc=; b=qsJzjSOFMlNRffqJzS3l9r23qQoKiaBgsbHhRJFIDoXLOQXT55l5sEXqxNuiGSOrBeWbBLPBwDA3m2ANAWZH6NaFxtvmeopG5q3ZQYOUHTvAQmbk3H06l8RsvD9hJLxH4qWBzJAWr6N+Rbb32956qorXrteHsGB4/ajLAtTig0/nmejOvCWBt2Jux/H9sK8r8T/Cjsvz/Itgiojwak1E5I+Ho39hXzszpANUxp9gbRzsItunScMTIQKocyAeMK/tcfioiaXBFHNSJQeEhT0YIGnXA94ZWVCffTVjc/YkpULSo08OcJLKMSJKGltj6PtoExUvsq5IQmPdP16mEyCe8w== 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=9GijEse6hff60BEqBgFxft9+bDZ0t5yGKOBH3CY1qHc=; b=d8WzNrgh8glFSoRvjPtCLSjgZuPyMN59tL/EoJyAMj2xiL5lRRewio14RH845LLo5iARGSIRWLKtM58D9Nw8GWsj5BfUJz6bJBTAG76jfQu3FRfBp/5Fo5WnZiT/QXtzP0gNZMHHRtKEGpoOe1YFbvG/1wL9frJfbW3YGF5xSRI= 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 From: Shuaidong Chen To: CC: Nicola Vetrini , Stefano Stabellini , Michal Orzel , Jan Beulich , Andrew Cooper , "Anthony PERARD" , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , Shuaidong Chen Subject: [XEN PATCH] automation/eclair: merge the two R14.3 invariant-condition deviations Date: Sun, 25 Oct 2026 14:34:43 +0800 Message-ID: <20261025063443.2489592-1-shuaidong.chen@amd.com> X-Mailer: git-send-email 2.34.1 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: BY1PEPF00026957:EE_|AT6PR12MB026081:EE_ X-MS-Office365-Filtering-Correlation-Id: 85aeca3e-fea7-4a9f-4573-08df32621849 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|82310400026|1800799024|7416014|36860700016|5023799004|11063799006|56012099006|261021123027099003|261021121427099003|261022113327099003|261022105027099003|261022075727099003|261009223027099003|261009221227099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: /UbQ3HmVc9DHScvY9NANC7W9TppRtvReIPlwXsCFvSFgJg/vQlT0hcaXcsVVEW4D4y6U9gafOJBQs8WdW7sAznta8Pe4mdGt/mxOi8KY9mSMOTpxSSYhPq22czrGXgf7T3ByGqNPIGZQI/pnDUWy5+6DUkispXlkchQ33r7RRpgDn0Y4c8nfrM508/AiO4NveJ0GeVK+AOMSjABZckURP8gvmGxkKI/LlG5hroJO0nUQYyLlzj9OwRjQlfUqz1gL/LSoYgJeS/+pPWni8aUtwSo6K8GwW02FZpAFEXiFHIyIWw6Zvwet5xdyY7juNANqrKxD0AlVD5il8eD3LgSY/LpzzxykFpvocJeDVTejfmtuz53Iq3HGY8eCjIlW1yWAZMkL1ZsMjrvXj7KFcdTb5fCBlBVF8Af8QdVzg+byXhtg8spvTdmmcpVCv+DVOg4Ob5l65pvezZzTXhjarCjzi/qXL+Xi1kraYei6CEk1vDg7clI0H45XW0UVf3EPjRwPZ2Ad2Am6TCPxIo4NC++tnegpwmlIInhul2ETsKVH241fmeptEAkTD05kjIRLAVC/iyxF5uDi7YR62btLikcAfOf4G3NAS7yW5rs0X6xIWgM8WIoCzt0lyCP7+VdGFyVml4wGq+NRNbWE/OEJQp30vz/mNr28v9EZj4iiabI8l42LSCac+tK5NAIqPUa9todMlE4tsD7fNOXGnZP/j3hccw== 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)(7416014)(36860700016)(5023799004)(11063799006)(56012099006)(261021123027099003)(261021121427099003)(261022113327099003)(261022105027099003)(261022075727099003)(261009223027099003)(261009221227099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: dz6Hs+WSrlVuDD6RagnzN+lmE8O6mRYYmSdn2m6VQbu7XRSfMCwS/e1vaUfpX4O2QGCzDbDWqyRNiwowQrX9hse51PuFxdFg8NZ0PGW9TXzu1ZTllOow1VZ01Pa4ckuBxn6VOgyzGWAuo1xzL3iAH/GV9/qQ5ZVOlOvKz/Yzc/KOzDGXz091CzbZZdqtioNoULerqhNhAXn7Ri901OBVd5SqXN1T8AI3kaFqpn3HMs6DJESnkoDrRMsBZry9cSi6LUeSxU4TWpjlB1KhqLbvY7aMXHIYB61J0jTGyxk5ZsEDOlXixSe/gJ+CALpNfjNTgqp38FixzOscCLfu+AoZhexZU7iKxrOnnvSHwnIVdAJSbiQ5vWL88Srb5OJfTkXT9re+bLqW9F7wtlfRNSUvAF+STbkzIf7RSfe97e+8pphOqc3xl1lo38DZO09quUhd X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2026 06:35:00.4264 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 85aeca3e-fea7-4a9f-4573-08df32621849 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: BY1PEPF00026957.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT6PR12MB026081 X-purgate-ID: tlsNG-33051d/1792910209-7448C4E9-A2B9A6BC/0/0 X-purgate-type: clean X-purgate-size: 3275 MC3A2.R14.3 ("Controlling expressions shall not be invariant") is deviated by two separate entries. One covers 'if' statements and conditional operators and places no restriction on where the invariant condition comes from. The other covers 'switch' statements, but only when the controlling expression is a 'sizeof' operator. The rationale recorded for the two is the same: the condition is deliberate. Nothing about a 'switch' makes an invariant condition less deliberate than the same condition in an 'if', so the 'sizeof' restriction reads as an artefact of that entry having been added for read_atomic() and friends in arch/x86/include/asm/atomic.h rather than as a considered limit. Fold switch_stmt into the general entry and drop the 'sizeof'-restricted one, which the general predicate now subsumes. Invariant 'switch' conditions that are not a 'sizeof' become deliberate as a result; that is the intent. Signed-off-by: Shuaidong Chen --- automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++------ docs/misra/deviations.rst | 8 ++------ 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 7f3fd35a33d..08a88ddfa62 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -472,12 +472,8 @@ activity." -config=MC3A2.R14.2,reports+={disapplied,"any()"} -doc_end --doc_begin="The XEN team relies on the fact that invariant conditions of 'if' statements and conditional operators are deliberate" --config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator))" } --doc_end - --doc_begin="Switches having a 'sizeof' operator as the condition are deliberate and have limited scope." --config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(switch_stmt)&&child(cond, operator(sizeof)))" } +-doc_begin="The XEN team relies on the fact that invariant conditions of 'if' statements, conditional operators and 'switch' statements are deliberate" +-config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator||switch_stmt))" } -doc_end -doc_begin="The use of an invariant size argument in {put,get}_unsafe_size and array_access_ok, as defined in arch/x86(_64)?/include/asm/uaccess.h is deliberate and is deemed safe." diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 32713172067..99a1b2332c2 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -458,12 +458,8 @@ Deviations related to MISRA C:2012 Rules: * - R14.3 - The Xen team relies on the fact that invariant conditions of 'if' - statements and conditional operators are deliberate. - - Tagged as `deliberate` for ECLAIR. - - * - R14.3 - - Switches having a 'sizeof' operator as the condition are deliberate and - have limited scope. + statements, conditional operators and 'switch' statements are + deliberate. - Tagged as `deliberate` for ECLAIR. * - R14.3 -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun Oct 25 12:33:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 25 Oct 2026 12:33:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460516.1671576 (Exim 4.92) (envelope-from ) id 1xKxPF-00037q-SU; Sun, 25 Oct 2026 12:32:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460516.1671576; Sun, 25 Oct 2026 12:32: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 1xKxPF-00037i-OG; Sun, 25 Oct 2026 12:32:57 +0000 Received: by outflank-mailman (input) for mailman id 1460516; Sun, 25 Oct 2026 12:32:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xKxPD-00037c-Ke for xen-devel@lists.xen.org; Sun, 25 Oct 2026 12:32:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKxPC-0005LN-NQ for xen-devel@lists.xen.org; Sun, 25 Oct 2026 13:32:54 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6addf6e2-bab6-0a2a0a5309dd-0a2a45098400-6 for ; Sun, 25 Oct 2026 13:32:54 +0100 Received: from [136.243.217.222] (helo=mail.cortex-media.de) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6addf6f6-be1a-0a2a45090019-88f3d9dece68-3 for ; Sun, 25 Oct 2026 13:32:54 +0100 Received: by mail.cortex-media.de (Postfix) id C2EF638C02F; Sun, 25 Oct 2026 13:32:53 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20250930 header.d=cortex-media.de header.i="@cortex-media.de" header.h="Date:Subject:From:To:Cc:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cortex-media.de; s=20250930; t=1792931574; bh=uxAYr7ITl+SPfggh3Gr9Eutbb0xY03icun1Q16xWkFA=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=W7Rim4vVBgyb0hdCoF5Zr0Xwb/GDPtT6vPRRoLshE9uCxST4J1gtU480sXD8O3nM0 DY/99FcNS2z6Oz5gt0k63y74gdp0OKoHRtQswf1zMIJma74bnbvJ9uGukXG2DUTijq XttDunXZa0eMOdrRD8oW5/1dJ9bzEEvlikmzE0RdqddobauBS1zgd0x1593Ug5nUEV lzdnZD9D8U9QPJyEcqMQFmVKE6Az9LVidffTNPdXFo2Sv/JeXxSUxIbxdBvjkTG3pO LNJpxu2z7YiaCzgY9joTz/MUF/OLe0QcKWVRtkNWumKHfDsYNnwjW1JOKHRN70Z7ly 4sskrdM/LNLyg== Message-ID: Date: Sun, 25 Oct 2026 13:32:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot From: Peter Deggendorfer To: Andrew Cooper , xen-devel@lists.xen.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Soham Dandapat References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1792931574-3AAD8034-4C9CDC7F/0/0 X-purgate-type: clean X-purgate-size: 8211 > Hi Andrew, > > Thanks a lot for the quick response. > > >> On 23/10/2026 8:32 am, Peter Deggendorfer wrote: >>> Hey Xen Team, >>> >>> I'm hitting a reproducible hypervisor panic in the AMD non-fatal MCE >>> polling path on a Ryzen 9 5950X (Zen 3). Eight occurrences since >>> 2026-09-09, between 12 hours and 2 weeks apart, always CPU 2. >>> >>> Environment >>> ----------- >>> Xen:   4.20.4-pre (Debian 4.20.3+127-gc42374a105-0+deb13u1), and still >>>         present in 4.20.5-pre (Debian 4.20.4+39-gf1e1321c87-0+deb13u1) >>> dom0:  Linux 6.12.111+deb13-amd64 (Debian trixie), PV, 32 vCPUs >>> CPU:   AMD Family 25 (0x19) Model 33 (0x21) Stepping 2, Ryzen 9 5950X, >>>         microcode 0x0a201210 >>> Cmdline: dom0_mem=4096M,max:4096M ucode=scan console_timestamps=datems >>> >>> The panic >>> --------- >>> (XEN) [2026-10-19 08:58:18.727] Xen BUG at >>> arch/x86/cpu/mcheck/mce_amd.c:100 >>> (XEN) CPU:    2 >>> (XEN) RIP:    e008:[] >>> mce_amd.c#mc_ec2type.part.0+0/0x10 >>> (XEN) rbx: 0000000000000445   r12: 0000000000000011   r15: >>> 0000000000000446 >>> (XEN) Xen code around : >>> (XEN)  90 90 90 90 90 90 90 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 >>> 90 90 >>> (XEN) Xen call trace: >>> (XEN)    [] R mce_amd.c#mc_ec2type.part.0+0/0x10 >>> (XEN)    [] S mc_amd_recoverable_scan+0x39/0x40 >>> (XEN)    [] S mcheck_mca_logout+0x42d/0x840 >>> (XEN)    [] S >>> amd_nonfatal.c#mce_amd_checkregs+0x1c/0x100 >>> (XEN)    [] S smp_call_function_interrupt+0x4c/0x90 >>> (XEN)    [] S do_IRQ+0x2a5/0x650 >>> (XEN)    [] S common_interrupt+0x135/0x150 >>> (XEN)    [] S >>> cpu_idle.c#acpi_idle_do_entry+0x8a/0x140 >>> (XEN)    [] S >>> cpu_idle.c#acpi_processor_idle+0x1ef/0x650 >>> (XEN)    [] S domain.c#idle_loop+0xc1/0x130 >>> (XEN) Panic on CPU 2 >>> >>> The outlined mc_ec2type.part.0 contains nothing but the ud2, so this is >>> the "unreachable" default branch of mc_ec2type() -- the extended error >>> code matches none of MC_EC_TLB_TYPE, MC_EC_MEM_TYPE, MC_EC_BUS_TYPE. >> I think it's safe to just drop the BUG(). >> >> That code is literally worse than useless, because if nothing else it's >> just hiding the diagnostics. >> >> I guess it means AMD have added new statuses. >> >>> Across the eight occurrences, r12 appears to be the bank index from the >>> loop in mcheck_mca_logout(), with rbx == 0x401 + 4 * r12 (MCi_STATUS) >>> and r15 == rbx + 1. Three different banks are involved: 10, 17 and 23. >>> >>> Not a hardware defect >>> --------------------- >>> - Started within days of upgrading two hosts from Debian bookworm >>>    (Xen 4.17) to trixie (Xen 4.20). They had run 3 years on 4.17 >>> with no >>>    incident. >>> - Three different banks, so not a single failing block. >>> - Updating to the current Debian package (4.20.5-pre, built 2026-10-16) >>>    changed nothing. >>> >>> Possibly related: 532988dccc19 ("x86/mcheck: fix mca_allbanks >>> updating"). >>> >>> Also possibly related on the Linux side: 0422b07bc4c2 ("x86/mce/amd: >>> Filter bogus hardware errors on Zen3 clients"), where bogus MCA values >>> on Zen 3 are filtered rather than treated as errors. >>> https://ratatoskr.run/stable/2026/04/7143905 >>  From above, you're on a Vermeer, not a Cezanne, so I don't think that >> Linux patch is relevant. >> >> However, your observation about "fix mca_allbanks updating" quite >> possibly is.  That was backported into Xen 4.20.1 as 247b708b1400a, and >> Debian has 4.20.3 >> >> Are you able to experiment with that patch reverted? >> >> Alternatively, are you able to experiment with the BUG() removed? > > I went with dropping the BUG() rather than the revert. > Reverting 247b708b1400a should stop any bank from being read at > all, which is effectively what mce=false already does here, so I don't > expect it to tell us anything new. I'll run it too if you'd like. > > I'm not familiar with the Xen codebase, but I've built a package with > mc_ec2type() changed to: > >     if ( errorcode & MC_EC_TLB_TYPE ) >         return MC_EC_TLB_TYPE; > >     printk(XENLOG_WARNING "MCE: unknown AMD error code %#x\n", > errorcode); > >     return 0; > > > Crashes have been 12 hours to 2 weeks apart, so it may take a while > before I can report back. After ~31 hours of uptime: (XEN) [2026-10-25 04:06:27.260] MCE: unknown AMD error code 0 No panic, no wedged CPU, no RCU stalls, no hung guests. Host and all VMs running normally. I also dumped /dev/mcelog in dom0 and got the following records: 00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 00000030: 0000 0000 0000 0000 0200 0000 0000 0000  ................ 00000040: 0010 0201 0200 0000 0000 0000 0200 0000  ................ 00000050: 1c01 0000 0000 0000 0000 0000 0000 0000  ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 000000a0: 0000 0000 0000 0000 0200 0000 0000 0000  ................ 000000b0: 0017 0201 0200 0000 0000 0000 0200 0000  ................ 000000c0: 1c01 0000 0000 0000 0000 0000 0000 0000  ................ 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > > >>> Diagnostics / workaround >>> ------------------------ >>> mce_verbosity=verbose yields nothing useful. >>> max_cstate=1 made no difference. mce=false is the only thing that stops >>> it, and it is what I'm running now. >> The fact that mce=false isn't causing machine resets means it's clearly >> something the hardware thinks isn't fatal. >> >> But, I am concerned by the fact it's always on CPU 2, and multiple >> banks.  Is this true for both systems? > > To clarify one thing from my report: it is actually a single host whose > complete hardware (board, CPU, RAM) was replaced on > 2026-10-07, keeping only the disks and thus the installation. The > crashes happened both before and after that swap. 10 more hosts > with same hardware still run on bookworm (xen 4.17) for years now > without any incidents. > > So yes, always CPU 2. The bank index varies: on the current hardware > I have seen banks 23, 17 and 10 across four crashes, and banks 23 and > 17 on the previous hardware. Regarding the output of /dev/mcelog: if my decoding is right, three things stand out. MCi_STATUS is zero, i.e. these banks are reporting nothing at all -- no error, no garbage value. Both records are again from CPU 2, and bank 23 is one of the banks that appeared in the panics, bank 16 is new. > >>> One more thing: the host does not actually reboot after the panic. >>> "Reboot in five seconds" is printed, but the ring buffer continues with >>> normal activity minutes later and the remaining 31 CPUs keep running. >>> CPU 2 stays wedged, and "xl debug-keys t" then hangs. Afterwards dom0 >>> and guest vCPUs start losing timer interrupts permanently (RCU stalls >>> with a frozen timer-softirq count while dynticks keeps advancing), so >>> VMs hang silently hours or days later. >> I've recently noticed that crashing with interrupts off doesn't reboot >> any more.  I thought it was something local to my development, but >> apparently not if you're seeing the same. >> >>> >>> I've attached the full xl dmesg log of the last crash, and I'm happy >>> to provide more if needed. I can also test patches. >>> >>> Thanks for your work, and thanks in advance for taking a look. >>> >>> Peter >> Thankyou, >> >> ~Andrew > > I have full xl dmesg logs for almost all crashes. Happy to send any of > them. > > Peter > From xen-devel-bounces@lists.xenproject.org Sun Oct 25 14:22:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 25 Oct 2026 14:22:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460554.1671585 (Exim 4.92) (envelope-from ) id 1xKz7R-00080f-5y; Sun, 25 Oct 2026 14:22:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460554.1671585; Sun, 25 Oct 2026 14:22: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 1xKz7R-00080Y-3K; Sun, 25 Oct 2026 14:22:41 +0000 Received: by outflank-mailman (input) for mailman id 1460554; Sun, 25 Oct 2026 14:22:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xKz7Q-00080S-7j for xen-devel@lists.xenproject.org; Sun, 25 Oct 2026 14:22:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xKz7P-00BCHi-46 for xen-devel@lists.xenproject.org; Sun, 25 Oct 2026 15:22:39 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ade109c-e002-0a2a0a5209dd-0a2a450bcb94-14 for ; Sun, 25 Oct 2026 15:22:38 +0100 Received: from [52.101.53.15] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ade10ad-b7e8-0a2a450b0019-3465350f114a-3 for ; Sun, 25 Oct 2026 15:22:38 +0100 Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by SJ0PR03MB5535.namprd03.prod.outlook.com (2603:10b6:a03:288::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Sun, 25 Oct 2026 14:22:35 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%4]) with mapi id 15.21.0546.021; Sun, 25 Oct 2026 14:22: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=lqpf0u8TAf+OG36PVIFMCmj7jFCRHVUDlPWO2j7/2ZvD2bZmtD7TtuG9Wng1oquwsoJvoiZubGbMlyyiyzc4oReAUAXtNkwgqk+4/2NaHKwZDenlpZ7qWe8QWqCB3uI41ULofjSlA6MDpeSWGrfKKrXFzfBIaWHDg8ZPvOSmzqJ+NXE4UWw/ZYVz89v+T9YTU5vllrfPCJpKvJShY+I5Z4NEjKkOamEziGuHjJwHve5tsZrI7OCEi6+ADJ713AyMG0ra1KrJc2sgidwPLQsPeWRULN7Lwy8RBSl+0Ut0npurGBbQ4kjbkhhw/avoZ54JRel2atz8kUtb32eYd3ysWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SJhgT4pCosswqxRtTGk+FOFKILZPh5Dm5CBivDPSDfo=; b=m2bWYUsGDtbSI2eWedi5xCUbJVSTaWcnOgGTQziN6u9gUmFL3HuacLL7Ma+gDSVgNHLdWZXyrXSHQhnPddZfrgRzix6OjwseSO7WCT/AI3/Qe/Vj6Qc5JiHUOwi5tvw62ThyrQW80UdkxWTLMLIoxJ2JZGszOXCQquuc0vyIUM4w04p4+5BbyvUAHK6YE7SJGohCLyJIi4ER7A3QidSzvY3Z2ozGamUQtONBgYqL+6vkOfN91uZrZw5dcBgGYjwk113gQL9He43f2UF/+Mv1hhoXCvjlHiQl0rmWdaenJ/WH4OcwPZBATfqXTmPhW5D2mx8ExH2d3vnXQoC5WtI9Hg== 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=SJhgT4pCosswqxRtTGk+FOFKILZPh5Dm5CBivDPSDfo=; b=T5lCxlXYyMKdq/SRLXzdUJBYUyvuiPu9CqcvpI9WaSCjVYuR5i8/kBGRoMEkswP6hrxl+qGC780AsiUgdcScvF8tAYlGn3kZKCH6lPba3NzM55XxjtDBTCNotqG2LzPF5aEcN1k0ujvRiRMKhFlfUhRc6QxtsRcmjpfS1tLqx5c= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH 2/6] x86/vlapic: Fix hardware virtualized APIC state after reset From: Bernhard Kaindl To: Teddy Astie Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Denis Mukhin In-Reply-To: <1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> <1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f@vates.tech> Date: Sun, 25 Oct 2026 15:22:24 +0100 Message-Id: <179293814412.1810895.12737475203049581172.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1792938149; l=5816; i=bernhard.kaindl@citrix.com; s=20261024; h=from:subject:message-id; bh=c0VYfaDAnCiIQ8J3/Mc4cnTCOhrWQQTko1/1oSQq+4Q=; b=+hyaS3ovnljiJkAYoyRQkHGKQ2QkhyKadCXPZBtz1nFciY+C3QmUKDqNRypgVR8r0pN5ukIYf rGPkadLcBN4DrOypIg4nk3BHIP8fLdX7PfufV0kBu68+KRs8+h8FC2o X-Developer-Key: i=bernhard.kaindl@citrix.com; a=ed25519; pk=oIjnI/us0Uh5d/WP18V5IQq/FrLPUp+W0JAhJ9QCQIs= X-ClientProxiedBy: VI6PEPF000001F7.AUTP296.PROD.OUTLOOK.COM (2603:10a6:808:1::905) To LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7707:EE_|SJ0PR03MB5535:EE_ X-MS-Office365-Filtering-Correlation-Id: 4a42b6dc-63a3-4121-f880-08df32a369e3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|4143699003|11063799006|56012099006|261021123027099003|261022113327099003|261022105027099003|261022075727099003|261009223027099003|260925022911599003|260925021911599003|260925021311599003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: DkD8gSbvc2c7/39xIz6Gudlc4wZBB09IgSAt8UPGMJ+HK/x7DxPXUBBkDpxN1YxLrk7KxrNhMnIK3pIww6rzSzi59RsMzWV4BQRz6Zmq6GoUKi4fCVzyPpcivMPSRwX5etsuvji4H4/7uUlAN0Tzvjx0G81xC9i9KH9R9j0pRnkaABkYRKmiIwjDvZ2kR+vsg4Dn2Ez338vaCJKt0sMk6KEL7/nUDx5uh4NiKOso+coJam2zuu83cAiop1SH4TONWnieqrA/jY/dm7kTMnNP7G5Rkej2/GxrGapvPVqkZ0recbidOCeoTEkcgz18bnpxfbV+TvbsjH2cW2jd+pTlqWmHUCSDNihJ1mnLA95bKIdUxhcWXgXrccxWLf7OKpyDEq6tN2GDIJEx3V/n20e6W59ciRc6dnv7DnvFOnEm8vipLXOVYKMWTJbUgf2qoue8PqgJznHYuxrhZoXSUmwqOuwVWeW3YzoOlD80tazYHFLEElkvlGXhKUXgxm2LagFE7nfSFKbwpVPWLPzrSmd7okB8A4dkVGQSsdxTEVTIm9Om9f2eLOVVCuuWrSnIGTAjIbjdthh5es7yPb3Ew3NMEIR02TqCC/YsXgADPrR8eb/JixeEkVTGgfMb/f5bhAVmdb/f7xyTLmCfU08Pr3ACeItTouGGwiH42d4ZEVTrQ9M= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(4143699003)(11063799006)(56012099006)(261021123027099003)(261022113327099003)(261022105027099003)(261022075727099003)(261009223027099003)(260925022911599003)(260925021911599003)(260925021311599003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cmNaMmk4SWZPY0xIT2xKL0kydUMyakFobHdjMmZNd1NieXlrMWY4T3RtbkRi?= =?utf-8?B?NFpKWmFTbFl4WjJkTEN0NDFEVk9uY1FRVFZub3hsTThkb1FsaWNzUmlXb0xF?= =?utf-8?B?TkRZWUc4LzZZeWJJUDMxbVdyWGdEZ1RqR2VvbkV0SXlTSnAyaWU0NFlQZVdP?= =?utf-8?B?dXVuZ2lWZkp6NmtyVG9VbVQ0c015TmlFSE01NHBYR1ZwRUJoR0sxYkFTY1Rr?= =?utf-8?B?dEJ5TGhpamJaRkpMTHQwMDl3cnA0RWZURGlVZ3VNa3o2ZmFUTlYzY1pxcmV1?= =?utf-8?B?MkM3MlRJdTd5OFVqcHNDR3FENmkrdUR5K1FhanpWcFZpdEU1QWp2ZUJFRzBL?= =?utf-8?B?ZG54WGV1c1ZUc1grbzJZM2xuN3ZUTGdoTVJady8waURhNjBhVExHaUZaendm?= =?utf-8?B?dEkycG9GSzhJQ3J6R2NXUGllbHhEZTdlVzNWeUxvZW9RLzFyNXN6MFlQWVFh?= =?utf-8?B?RTFrbk95ajhoS2JXVkJSU0p4RHozaW01K3RtQjFHWWhwb3ZidkhtQ2xEajln?= =?utf-8?B?U0REeUFhZHR6endBc3Z0OHl3MUMwWEoyWE5KVDJkUVBhaDUyQm9lK2piWFdm?= =?utf-8?B?aXlUVmdzdGpGWUExaDQ3UGR6aTZoQ0J2K09INTd4NjdYRGU5UE5oS2k2SGR3?= =?utf-8?B?VVZuSW5KS3RVTUsrRHFHNS9kdGJ4T2p4QVoxR2YwYWVGR3RZWklUdUpteEZR?= =?utf-8?B?cVJ3N2xOSXFkbVBKZE5oSENBZ2ZSOUJzUk1oSjcvUzdrakk3NUQ2bkZyV0FB?= =?utf-8?B?WFVPRjVYMzk3VmtmUlJ0TzR2TEJNbXhDdDJOZVBPZlo3MGtNT2IzdjBwS3ZV?= =?utf-8?B?RkxQM2k0MWNWTVpaeTJYTnRxVkc2VzJ6aG1zNHFjeUxwZWYrUDJqbzBYRWFV?= =?utf-8?B?VW9wdnFFOXMzaUJGWGI2b2hzMStYbDVQSTErUmdoSUVXdjZHUE5WZ1FhSFNO?= =?utf-8?B?Wkt4VVFZNTR0clNHeXh6QmZsZjhicGxheVhnWmZyN2FMQXRobHB1TXF3Y1Rx?= =?utf-8?B?bWNuRnFNb3NRaXBXMkFvOEtpRDB1V1d4eTFpTThLQzhWakdDdDdzUVptZkEw?= =?utf-8?B?SVhFamNyU21pOTlHUjdDVmFaelFvVWd6M3praG54cTB2bStHei9GVE5mRXN5?= =?utf-8?B?UmE4V3BscThIV0dlMU5IdndhakhsZWxGTnMvOEY3OTgvYlBZVk0zUjA4WVFh?= =?utf-8?B?N0tVdjloWHova2ZodTF2ZkE3MkNLaGErQnM1RDJZMEswem9kOHRnT0pydklu?= =?utf-8?B?dnA5NWlKOHFGZnpLUXRzSGI3NVdrWjAwblEwcWJWTWJvdkZaL2szMzFKOUJz?= =?utf-8?B?NzhDd1p5ZHJ2R1VIM3NzajlPYS95OEh6WlJlc2lnT2xwVFRkTzUvd0hxWjZk?= =?utf-8?B?QWx4blhZYU1TblI0VmtwcE4yaE15NkhucC9UNVoyYnlhU3pETlAzbExQMk12?= =?utf-8?B?OE1RUUpsbEhMZ3ZYb3VlQjR5cVc1c1BROCtJYjI4a1ZjZXFkRElnb0YrQUJF?= =?utf-8?B?TTBOYTBKQ1ZTZGROalZTNC9JNU1Xc2htU0V3MGdEOHJvNWtvUnNwdVlRRHFT?= =?utf-8?B?aGx1SkpMU0s0VldabEVzZ1VQQ05HQVllTmg3QjliMmxHeDU1cVR3VnM3cVlU?= =?utf-8?B?Z0J2RVBCZVdROGU5TGgxYStFZDQxaUFZNXdyaDY1Wk1lanZzVnNMOTBvbGRh?= =?utf-8?B?RC9uRlZtUlJnYUpwTjVSdnZKZ2djblJJQnp4a2hNZTNaM0liclJOd21hSHFj?= =?utf-8?B?TmprYlNuQXN3c2E5czRLN21ZQXBPTHprMmJaUVZnaktpZnNiOWpJNWVKcExm?= =?utf-8?B?NVZrVHREWDI3UTdQVmRyeW01SGlkcnAxVDl3WkUrdkRwcy84amYrSUhUSHMx?= =?utf-8?B?WDFjUWlMeG43WGxVQ1R3TFI4T1dLZTBmL0JxbHNWZ1M0N3MrMDFoaFdhOFV2?= =?utf-8?B?RjNWU0drK092WGtlVzR3ckdiRDlnT1FjRlVmeXlES01VdWZnaFQ1NGhvMXB4?= =?utf-8?B?UWRmYk5GMms1SGp6WHRoQ21Gam5wWE9oblE1KzF0TDU5eTllOTE2WkJIK0kz?= =?utf-8?B?VXNhVzhYZ2ZwWXVXMkw5Ry9ZK3ZDNncvbVROU3I1MGdXZkRZclI2VEFnQWQy?= =?utf-8?B?M01iVXhZbnd6OEppdGQrb29mRDU4RVRFa1AzQXZRVGp1cnlRU2RGaktNZmxh?= =?utf-8?B?d240bXJqYkZ6MVNmSmdrS2ROUkM1R1I2ai9mbnp0OHBZcUxuNGhlWFFmOEk1?= =?utf-8?B?bm4wTnpwaXRaUlVqRk9QeEp1NXc4WStsc0tVUXhtRkRVREc2TmtJd3NtVzFr?= =?utf-8?B?N0hIZHI3eGNGSjVNa3oyOFBpN1JvTTJIVlJtUWV6eGNqZzdDcmFvWUNKSTlw?= =?utf-8?Q?qRWU670xC07G5FyM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a42b6dc-63a3-4121-f880-08df32a369e3 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2026 14:22:35.0121 (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: jynlsqdZyqb3xQJLDjf6Ttz9p0jMGbk4KM+5geeNtvEt9jlglgqX5lmt2BpYTQMsxw59YoEgC9+abpZ2z2t0LBC1H2Hc+gNxZEAwvoLVeUQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5535 X-purgate-ID: tlsNG-42698a/1792938158-184CB9EA-F0933306/10/78276251493 X-purgate-type: spam X-purgate-size: 5816 To: Teddy Astie Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , roger@xenproject.org, Denis Mukhin Subject: Re: [PATCH 2/6] x86/vlapic: Fix hardware virtualized APIC state after reset In-Reply-To: <1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f@vates.tech> References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> <1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f@vates.tech> Hi Teddy, Thanks for the reset improvements. Could the new reset-time sync call use a dedicated discard operation instead? That would also cover suppressed postings without changing ordinary pending-interrupt queries. xen/arch/x86/hvm/vlapic.c: @@ -1429,6 +1432,13 @@ static void vlapic_do_init(struct vlapic *vlapic) > + /* > + * Drain the posted interrupt descriptor (and clear its ON bit) before > + * zeroing the IRR, so that vectors posted before the reset don't get > + * merged into the fresh IRR by a later sync. > + */ > + hvm_sync_pir_to_irr(vlapic_vcpu(vlapic)); PIR (Posted Interrupt Request) records pending vectors. ON means Outstanding Notification, while SN (Suppress Notification) suppresses non-urgent notifications, not the recording of interrupts. The switch-out hook sets SN for a non-blocked target. An IOMMU posting can then leave PIR nonempty with ON=0 before reset starts. The existing vmx_sync_pir_to_irr() in xen/arch/x86/hvm/vmx/vmx.c returns before touching PIR in that state: > if ( !pi_test_on(desc) ) > return; Consequently the new call can leave an old vector in PIR while reset clears IRR (Interrupt Request Register). It can later be transferred into the fresh IRR. This is a pre-existing reset gap, not a new regression introduced by this patch. Checking PIR as well as ON in vmx_sync_pir_to_irr() would add reads to ordinary pending queries, including hvm_vcpu_has_pending_irq(). Reset instead wants to discard the bits regardless of ON. What do you think? Would replacing the new call with this optional backend hook fit this patch better? diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@ -1433,11 +1433,11 @@ static void vlapic_do_init(struct vlapic *vlapic) return; /* - * Drain the posted interrupt descriptor (and clear its ON bit) before - * zeroing the IRR, so that vectors posted before the reset don't get - * merged into the fresh IRR by a later sync. + * Discard posted interrupts before resetting the APIC registers, + * including suppressed postings which have not set ON. */ - hvm_sync_pir_to_irr(vlapic_vcpu(vlapic)); + if ( hvm_funcs.reset_pir ) + alternative_vcall(hvm_funcs.reset_pir, vlapic_vcpu(vlapic)); vlapic_set_reg(vlapic, APIC_LVR, VLAPIC_VERSION); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2437,6 +2437,17 @@ static void cf_check vmx_sync_pir_to_irr(struct vcpu *v) } } +/* Discard posted interrupts without depending on notification state. */ +static void cf_check vmx_reset_pir(struct vcpu *v) +{ + struct pi_desc *desc = &v->arch.hvm.vmx.pi_desc; + + (void)pi_test_and_clear_on(desc); + + for ( unsigned int i = 0; i < ARRAY_SIZE(desc->pir); ++i ) + (void)xchg(&desc->pir[i], 0); +} + static bool cf_check vmx_test_pir(const struct vcpu *v, uint8_t vec) { return pi_test_pir(vec, &v->arch.hvm.vmx.pi_desc); @@ -3176,6 +3187,7 @@ const struct hvm_function_table * __init start_vmx(void) vmx_function_table.deliver_posted_intr = vmx_deliver_posted_intr; vmx_function_table.sync_pir_to_irr = vmx_sync_pir_to_irr; + vmx_function_table.reset_pir = vmx_reset_pir; vmx_function_table.test_pir = vmx_test_pir; } @@ -3212,6 +3224,7 @@ void __init vmx_fill_funcs(void) vmx_function_table.deliver_posted_intr = vmx_deliver_posted_intr; vmx_function_table.sync_pir_to_irr = vmx_sync_pir_to_irr; + vmx_function_table.reset_pir = vmx_reset_pir; vmx_function_table.test_pir = vmx_test_pir; } diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -218,6 +218,8 @@ struct hvm_function_table { void (*process_isr)(int isr, struct vcpu *v); void (*deliver_posted_intr)(struct vcpu *v, u8 vector); void (*sync_pir_to_irr)(struct vcpu *v); + /* Discard pending posted interrupts and notification state on reset. */ + void (*reset_pir)(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); The ON clear is before clearing PIR, preserving the required clear-ON-before-draining-PIR ordering (see vmx_sync_pir_to_irr()). The helper needs only the inline descriptor, so initial LAPIC setup can call it before VMCS creation. The hook is optional and installed for VMX posted-interrupt support, including the vmx_fill_funcs() entry. For the series as posted, and also with the suggested change above incorporated: Assisted-by: Copilot:gpt-6-astra-high, Copilot:gpt-6.1-sol-high-xhigh-max # review Reviewed-by: Bernhard Kaindl cu, Bernhard -- Bernhard Kaindl From xen-devel-bounces@lists.xenproject.org Mon Oct 26 02:38:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 02:38:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460719.1671595 (Exim 4.92) (envelope-from ) id 1xLAbf-00053F-FJ; Mon, 26 Oct 2026 02:38:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460719.1671595; Mon, 26 Oct 2026 02: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 1xLAbf-000537-8P; Mon, 26 Oct 2026 02:38:39 +0000 Received: by outflank-mailman (input) for mailman id 1460719; Mon, 26 Oct 2026 02:38:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLAbd-000531-CL for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 02:38:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLAbc-002ols-Ao for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 03:38:36 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adebc96-bab6-0a2a0a5309dd-0a2a45098dac-38 for ; Mon, 26 Oct 2026 03:38:36 +0100 Received: from [40.93.198.43] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adebd2a-be1a-0a2a45090019-285dc62b1a11-3 for ; Mon, 26 Oct 2026 03:38:35 +0100 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by DS6PR03MB023887.namprd03.prod.outlook.com (2603:10b6:8:521::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 02:38:32 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%4]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 02:38: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=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=tEg+TWHNEfcXw/j5f1wVltcggL5FBXnRO9oOZweXBMHw9XjySwijt1S8QcPdZ4xtrOSonSpT5/XfI7FSn0K7m5mIF+7AnVfAC0FemsxiJ7QPRz0xU2AXQmylkWhFAt6qVA/5sQ1HXYJeNSHOga+/kpZiOjiCZgRUo5P6AAfADaSuqn/mD1M1BHdG5aXVTNzJkVDw0wn+JTGKpBmog4k/uHJQn6jzhuGrplMmxU5OYhuMV9gGxQQLfzbBi2E8Fsgu1Z8V0hQBbCiqraLTnmxJVoyviqiDYeP73kg/7+HUC2fmwjYVJBZr8YG1O0kdo4XIJy/KQ6PJSlIh+yS1fh9uGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bo91kQ2+mIRGrhIWDBqPnGbh+YLfBhzhw+LXoFKZmiE=; b=WFjz0yfrmON7cFFLIEr6fLu3htzbrxFIdiS9bxrn8Ybp5MJBu/YewakMcQqsjjTCGUJ6ZgenZLa//RKsan+s+1+V+QxbjePZEaEOy73gsu2T1jZsHoDetacyDt89dM4Wk8S9fbc2pQS1krZxm6umKGGfYO92ICfdb5fehHSD+rVonargwKRwvnoZyo1QRmc9QK31c8x2VTNHTpjpIjfeMwuNXAzYEuaJ82sfVaKadytOnYo+gO9UQSJwZ8f1Yf0jc0VDlht1BJMT4PFQyRp3ncUEEanbCgv1qkz7GXbdnNyDiQaJ3kEY/WgI2IB3pWitlw+RQQt8KO/rr9NGlXl4bA== 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=bo91kQ2+mIRGrhIWDBqPnGbh+YLfBhzhw+LXoFKZmiE=; b=bfR0v2ljhswAz6m8IE6lbdAiqTBDy6BkGrra17FIX3d4WMlCRsWoJD4HmiO2EClDlLn3krWE5QRH6/mJGqiKI/xp70QYWbAn6T6XFNSuLg76LvvlcVanTPe6guI0B+apgY+utnaz5pv+rUc/qqPqzzDNN9UuNGR0EOKKx2bMlKY= Authentication-Results: mx.microsoft.com 1; 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: Ignore bits 11:0 of L1's MSRPM base address Date: Mon, 26 Oct 2026 10:38:21 +0800 Message-ID: <20261026023821.301182-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR01CA0034.apcprd01.prod.exchangelabs.com (2603:1096:4:192::9) To CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR03MB7889:EE_|DS6PR03MB023887:EE_ X-MS-Office365-Filtering-Correlation-Id: 9f0f7bef-07f0-4892-4b30-08df330a3991 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261022075727099003|261021121427099003|261021123027099003|10067099003|56012099006|18002099003|11063799006|5023799004; X-Microsoft-Antispam-Message-Info: 3X09mXYZlsJqhwiG/U54p/0+ZCm45Hk+kpFWt0E31U0IeZH50ujnzCmmZYSR0znNVPWV4hBv9AYGFoppRZq6VOtM/bTSqHBgzUISiPsubc2fUVmO+1c3VnvDdl//77I+DE9et9fg9dBx7bYT91a4/V36lJStdGPQ0GlGQQspeRBwVeos11BIPA2NYY2kuBcK5Ofglo0WNYhakAYrD9pnSLnExH41RkrVvCuzVj1Yy+0rTuSEBDbwrgVZdymko5MNvimvDbdx6b+dAEsA55dLRs5y84Us6UbSYzJcHweKfvVm5qgdLACCMk9LDQHXxgILp3Jxmsa1htmGSdh1vovhcIIca5t4duCcCmvAvXfu9x1Lkxsr+y6ZFL3OadKD/YzKaXS0U7bHvJ4e6GbT1mHzTjV5gzMMdFf62I4F0PP0iYCdxYFQxtnqI9zUPfgeq6FDz63EaQhm2IrcM+dU8vyvymAETEXVQfuULE64FPWSQVfbMKdy5TGYeWtr8+sR8WtW42N9CckBsfmf5NvmUWjb9MVhNkrZtO7KyMimrM111UQ4v5Mo8ua+fciWbY0/zxQCzlfzzMxNlB7XXEcSaS7soCE4hDFNxkFKbMUtek0UPJoj9qH7TWZK16N0b3c18qNslUdKVlxE75/z8yDFfBSmg3lfIUDUhE8J7RV3WG7Fk4s= 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)(1800799024)(376014)(261009223027099003)(261022075727099003)(261021121427099003)(261021123027099003)(10067099003)(56012099006)(18002099003)(11063799006)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?CTVG2DYkRbuosTfWgLZ6Tu7X8Lj3ImObpPTs77WMqKkxEGTOiWyxhDk3BJdw?= =?us-ascii?Q?KKTx3r0tNs+B30KltkPaTX+6aA5CceWXyjrRb890f9DdJ9Ueu+0+hUt/vz9U?= =?us-ascii?Q?bvBuEUrXAYwT9QduwCXVS28r8ZCojogNqPCEZphdC6QnpfPv+sBeBn55vti5?= =?us-ascii?Q?xOKx+k4J+qPCmtyotp1BVQ5FPKH2ViBCBVZUtDHshqo/tmbm65UUqrP7iV4F?= =?us-ascii?Q?knViYkvljIsTgMt/XPU+Dz/654N2w1RQIryXo3QNNboW6Spb3FGhVy2esZaT?= =?us-ascii?Q?lsMGtZx7HQqYw0EM9B9U4K4o5Xno5ExJ4Kfd+lJEbsqOyuUQ6UJ3mY/hpLCH?= =?us-ascii?Q?PShW/jqXiHcu1Vz55B6pPHW16740kZZH1U8rg892AtlHtmt1i6k/h3kuHv6t?= =?us-ascii?Q?yiwvuEgyVIOeC31JIil5SkGP5XhhwC50OyCpJkuuRf6wGFSwtHnFawZM6Lf2?= =?us-ascii?Q?pkNGtQcGlNVUwxfyif/vJehQYT78OZolgxQcLQQyV318c524CkeSeHJczAtg?= =?us-ascii?Q?1uawipSLlgLRrGug0MqaOhiL8tMfhLvVteou/BcFQxkwcKKGTMfijtPzqJix?= =?us-ascii?Q?Q4ZoZ8185N6RHsIPOUt+fKtg2LTMa0yMVPHpkQz7tXcw+ReB8YsR6FQES85u?= =?us-ascii?Q?Gi0u4JoDfZM8mkoi3esyFLeRHx+4xzQ5HOebH166i5opmiG/3HiEaV45sJ2d?= =?us-ascii?Q?MkQhjdJKXAyDlCnolt3kGLrnPoPma9o76di8RPTYU5CqCONQINiMo/Bny5zQ?= =?us-ascii?Q?8d66zuO8h5lnB7PQIfIVAQAEBK0+qPoSkJYXUXE7gR27lTdnYwRFWtocz4jf?= =?us-ascii?Q?iXaH6n4DzW2z9KC66PGIeJzjqLy6ciLrw+56+H5EmOIaHTwjRtu4K6JsyEY8?= =?us-ascii?Q?7lCYh5IK4x1b6f8i4ZiWme7uYCZAWZYIvWhVzI/0T8862TevzoCRWkLKsS8H?= =?us-ascii?Q?AaclPZHO76Lf7afr5OTB54LilKoB+8Pxa7OBIU+fVyAxWwy6AcHC8kgQXCSj?= =?us-ascii?Q?Y61nxY/FgsxthEXMFsFW3NqNpjz8L9HDT6Qj9HvZvmHAqNXCXrXEVYedaciF?= =?us-ascii?Q?QSoRDGaQkjyuccakaoFVHG5JvypZYucXOGyc6wdMUwtIwB8LtKlQa96FUAtX?= =?us-ascii?Q?YEHw5Je0OyC7rb7xh21BmnPWU2vRU3SPoFuYqPiRokIhklesP3LP2eNk3odT?= =?us-ascii?Q?G1hMkLZDniPfjarpUY9furm0IRHS6ByCOgRedbofWcqAexYgHq04008tG48o?= =?us-ascii?Q?diG0ZSE9JB0nJKkw5fhj8jSbDauPotjBxoWjbaWRPjpcxvUK6Ewq5Z/U04qz?= =?us-ascii?Q?6EJm4paODn24nSTjrFtlKR3uHH0R7EikO+vyGHkhH9hkEt/YOFvfrp/4OVke?= =?us-ascii?Q?5wL9jiOLj+Sn1o1R+RVnZ/PxY0AEAz3upd9dONRqqZmzsgGojKGabDJ9peRq?= =?us-ascii?Q?orEw43dMG2OUHX+3Is2+7VcvfdIWwD2WaI5FUIa3zYNnoguK0SrSzCOmswfF?= =?us-ascii?Q?1URiTlD9xHvyEAShrFxWqtH2X09EoBLhjo+DoseTJkp/47RMLV+j/5aE4gDH?= =?us-ascii?Q?WGJT/Fqe1jaWEJ+qKXVHepYfjUjQh9M7nXcc35npqN/MkZkPle/ctTJQExlm?= =?us-ascii?Q?be11lQFMl7N3VntDXMnvMBPJbMd1V/lGBdgPesTIdD85fPDaT2e03ougEy8L?= =?us-ascii?Q?cCGGCJsg493eVj5eQLCiPz2kZsiJd+Ib0hRp5yWlncLKSHp5+/SDDuUhSicT?= =?us-ascii?Q?zpoRWN3AUw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f0f7bef-07f0-4892-4b30-08df330a3991 X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 02:38:32.1154 (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: Q7kT7PubIGD3aZR4o38YU8yuwj94HabX+SBZMB4VnUEdKQQ8hk6vCl7esvU8fQN/lAMdrEH3i+iSVRTztrlu3fGtrgYxCaA44iU/dPhwdv4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS6PR03MB023887 X-purgate-ID: tlsNG-bad1c0/1792982316-39AC0034-CAF4B8EE/0/0 X-purgate-type: clean X-purgate-size: 2063 VMRUN ignores bits 11:0 of MSRPM_BASE_PA (APM volume 2, 24593 Rev. 3.44, section 15.11), but nsvm_vmrun_permissionmap() copies L1's MSR permission map from the address exactly as L1 wrote it. With any of those bits set, the copy starts at the wrong offset, so both the merged map and the intercept check on #VMEXIT use the wrong bits: L1 can miss intercepts it set or see ones it didn't, and the copy may run into the following page, giving a spurious VMEXIT_INVALID if that isn't RAM. Mask the address before copying. Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Stephen Cheng --- Notes: To reproduce, in L1: set MSR_PROT, set only FS_BASE's read bit in a page-aligned MSRPM, point MSRPM_BASE_PA at the map + 0x800, and run L2 doing RDMSR of FS_BASE. L1 should get VMEXIT_MSR; without this patch the RDMSR completes in L2 instead. The IOPM base, handled in the same function, doesn't need the same fix: all of its users convert it to a frame number first. xen/arch/x86/hvm/svm/nestedsvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 2b998e26bc..56d0f0fa4d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -309,8 +309,10 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v) ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm; + /* VMRUN ignores bits 11:0 of MSRPM_BASE_PA. */ ret = hvm_copy_from_guest_phys(svm->ns_cached_msrpm, - ns_vmcb->_msrpm_base_pa, MSRPM_SIZE); + ns_vmcb->_msrpm_base_pa & PAGE_MASK, + MSRPM_SIZE); if ( ret != HVMTRANS_okay ) { gdprintk(XENLOG_ERR, "hvm_copy_from_guest_phys msrpm %u\n", ret); base-commit: 4e3c0eeac5761c505f8229e82d265eb29957ca5c -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 03:03:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 03:03:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460730.1671603 (Exim 4.92) (envelope-from ) id 1xLAzo-00015M-BX; Mon, 26 Oct 2026 03:03:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460730.1671603; Mon, 26 Oct 2026 03:03: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 1xLAzo-00015E-8W; Mon, 26 Oct 2026 03:03:36 +0000 Received: by outflank-mailman (input) for mailman id 1460730; Mon, 26 Oct 2026 03:03:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLAzn-000158-GB for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 03:03:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLAzm-00CPQu-EJ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 04:03:34 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adec2e7-2eae-0a2a0a5409dd-0a2a45039aae-16 for ; Mon, 26 Oct 2026 04:03:33 +0100 Received: from [52.101.85.30] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adec303-fae8-0a2a45030019-3465551ec0e3-3 for ; Mon, 26 Oct 2026 04:03:33 +0100 Received: from DS1PR06CA0027.namprd06.prod.outlook.com (2603:10b6:8:23e::19) by SN7PR12MB8172.namprd12.prod.outlook.com (2603:10b6:806:352::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 03:03:28 +0000 Received: from CH7PEPF00000018.namprd21.prod.outlook.com (2603:10b6:8:23e:cafe::41) by DS1PR06CA0027.outlook.office365.com (2603:10b6:8:23e::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.18 via Frontend Transport; Mon, 26 Oct 2026 03:03:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH7PEPF00000018.mail.protection.outlook.com (10.167.244.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.0 via Frontend Transport; Mon, 26 Oct 2026 03:03:27 +0000 Received: from jim-System-Product-Name.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.53; Sun, 25 Oct 2026 22:03: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=ASDKMIqi6o8V7hMwuWJhFwXzE8jBxeuk2x1ndRPCBorlCCgiYSg8KsiujrMFZCet0NjvHmRq5l/PCAk6ZIanbxTbGdQ/U61N6mJACHm/a9WgLB0iqBvOoIWS5BSAnZkx5RTL3py300FOOCugrkYYdpPyO3T1XQe8n2f+O3ENSym3P0/JriLkEJb4d+eqkmRxg5At9VKDP15eX9AmTwCvqutQwtwKA9GJ1b2ohGHWVRTbK4nLUYLJ2yJ0XNO9eQ+n2KIKCESyzh8YNgnFW3p3jbHEhfE9rjFjSIG5A4tPQyhHEB0BCTSVOZ37w3kFoieJw1l+evlHk+Fx9iTMKwYAzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9GijEse6hff60BEqBgFxft9+bDZ0t5yGKOBH3CY1qHc=; b=jX51cplIU/1bvb1IwtwhKH9XPMjeMOt/kIubIp5YWWo9VloldsGzbkKw7ju7PraoR1HXN45C008MeO8NGs0hPDC8NjSBYDSZOfELa7WbQORM0MqVVFTc+bNqeRGJG9Jd9vTnCJOoPPlwNrhA6T3cva1lQljpyrhyTptsKGNxk4Yyz2214B9BQ0N7Rk+FSs1TNVQMwTzXw40Be3jz8Dz8ohmwYNWyeVmArcZ5DPDtPBFiMAAp6nNTGz2J9ZDMBsxmH8tsiu/BPxf4VXdKooEx536XsMDCOV6uFeL6j6x2dh/2xINDYix6pbNaCJ7iOfsa0wEnUyw00ETEw411JbMiZg== 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=9GijEse6hff60BEqBgFxft9+bDZ0t5yGKOBH3CY1qHc=; b=kRnhhCrLFwZlNMUMMUpU+63LIJdTrAgUQsf5d2hcUkfnbPaAYCf1/iG+sdmWORzQRoSZx2iXA/4YPzzAh9Qn/KjrH9H5Musfis/5Lg5b+U1fGKOb31TG+l4oxv+27hXuu4rOXOBTEdWSmIM5GI51vRsL/mQ/vzxx8NzBLkLXZpc= 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 From: Shuaidong Chen To: CC: Nicola Vetrini , Stefano Stabellini , Michal Orzel , Jan Beulich , Andrew Cooper , "Anthony PERARD" , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , Shuaidong Chen Subject: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations Date: Mon, 26 Oct 2026 11:03:09 +0800 Message-ID: <20261026030309.2507461-1-shuaidong.chen@amd.com> X-Mailer: git-send-email 2.34.1 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: CH7PEPF00000018:EE_|SN7PR12MB8172:EE_ X-MS-Office365-Filtering-Correlation-Id: 8373a895-ae89-45ba-41ee-08df330db55a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|23010399003|1800799024|82310400026|36860700016|261009223027099003|261009221227099003|261022113327099003|261022105027099003|261022075727099003|261021121427099003|261021123027099003|10067099003|56012099006|18002099003|5023799004|11063799006; X-Microsoft-Antispam-Message-Info: eKJT5L2LFE87U8/n1kYLjUjmRfrhqZKwFtqwVfeG5+hw/CNHBeyH2thazhMFuHiehuHYZA9H7NvtGLQoXrbyp+YSyZctYgVmsmFB22SoC+zzb0RCL0MnfXXH/3rUJY7K3lSaydX751AMYvN2v/lcNUdMvr3oiMwCxoT/ay/XEoyvU2d/u5jJzBI/YIbpN2laGKrPXiSPhweHNzi1KQe9wLkdGAt0UhJpOyjYptj3aEwxGWBFgUA+cwILkALF3QePCk8Dz8zOxMhrizbhoJIaSXu4i1/Db/25Y2yLwAiEvtHAzffD+I9EfcnyXMsOqrggIavjeliN3KhtHugbozU9MDZturzeXzHBCz5hdtTx/PtSnooG8yNG9t8Gc/HQRkYwjtWijsFjD8HC5Msy8bG1WCPeibFReRK79fH1BK6a+9TY0zljRevOcVZwkAEE7BZAzIXV1l7PrnzF75WrlnQnas+QkXuNygJprcUV2JpvNcjmuGHwnem1b5NvrAbKeypK1el1MEFrciXwrIIXHILgXVDM0rSUxO2AlB6fsnmXKp7aZ42moyal1zXyhpur/j/rinUehkzU/VFnxHsowclP7ZlO6glJ2sc9KljjTXaa5hKIjOYPrZpND8XPTTZuWtq7/poXm8lxEQuhDyn0LIztKSJs3sUE6iUMtEHGBGaGDD6gQy3I0mgguBkZ6Ba5LqYlmh4hMJ00rn8P+rWtfHlu5Q== 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)(23010399003)(1800799024)(82310400026)(36860700016)(261009223027099003)(261009221227099003)(261022113327099003)(261022105027099003)(261022075727099003)(261021121427099003)(261021123027099003)(10067099003)(56012099006)(18002099003)(5023799004)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: UVjEwvfgvZWu/zxekXA/2h5Nf9PQsLcCr8WS4yCGK2AWawjKPBRt1ufzT0fI+Vb5ohgp6mb3V41jTBRlTRegL15BE56N2+gozRzqr2rr70kVsFkvjQYeH+eeBkvep1jWUQfzO6Bdj4aWm7OMmaJYDYll9/dOOGLFMvJFXQhhpU389nKaSjmhn4umZml5xnjNouPBb2sTeBqXXtLg9MyM6b0Y6e5orYVjWKRBOIE6lsAECfD8t4KRgqiUDDX6UHAwznHGThDVjAH5oMI/NuSKXwrAvX84Mkt7UfKFuvG8g6pHFyOLr/GeTjta8hZSHs0vhWbrSlKiI+q7uCJjfrg2sRjGqaMjeh53FjYfirJssHrT9/gfsQs/IkPuuFdwcMCdK2HLHQUpB5ZUyPH5JsTNDwrbPaDz0p0MPUBqJ/IC5VBc9pXlIVIAE7YiX6c+1Kop X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 03:03:27.9768 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8373a895-ae89-45ba-41ee-08df330db55a 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: CH7PEPF00000018.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8172 X-purgate-ID: tlsNG-33051d/1792983813-778C54E9-64D34F87/0/0 X-purgate-type: clean X-purgate-size: 3275 MC3A2.R14.3 ("Controlling expressions shall not be invariant") is deviated by two separate entries. One covers 'if' statements and conditional operators and places no restriction on where the invariant condition comes from. The other covers 'switch' statements, but only when the controlling expression is a 'sizeof' operator. The rationale recorded for the two is the same: the condition is deliberate. Nothing about a 'switch' makes an invariant condition less deliberate than the same condition in an 'if', so the 'sizeof' restriction reads as an artefact of that entry having been added for read_atomic() and friends in arch/x86/include/asm/atomic.h rather than as a considered limit. Fold switch_stmt into the general entry and drop the 'sizeof'-restricted one, which the general predicate now subsumes. Invariant 'switch' conditions that are not a 'sizeof' become deliberate as a result; that is the intent. Signed-off-by: Shuaidong Chen --- automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++------ docs/misra/deviations.rst | 8 ++------ 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 7f3fd35a33d..08a88ddfa62 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -472,12 +472,8 @@ activity." -config=MC3A2.R14.2,reports+={disapplied,"any()"} -doc_end --doc_begin="The XEN team relies on the fact that invariant conditions of 'if' statements and conditional operators are deliberate" --config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator))" } --doc_end - --doc_begin="Switches having a 'sizeof' operator as the condition are deliberate and have limited scope." --config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(switch_stmt)&&child(cond, operator(sizeof)))" } +-doc_begin="The XEN team relies on the fact that invariant conditions of 'if' statements, conditional operators and 'switch' statements are deliberate" +-config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator||switch_stmt))" } -doc_end -doc_begin="The use of an invariant size argument in {put,get}_unsafe_size and array_access_ok, as defined in arch/x86(_64)?/include/asm/uaccess.h is deliberate and is deemed safe." diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 32713172067..99a1b2332c2 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -458,12 +458,8 @@ Deviations related to MISRA C:2012 Rules: * - R14.3 - The Xen team relies on the fact that invariant conditions of 'if' - statements and conditional operators are deliberate. - - Tagged as `deliberate` for ECLAIR. - - * - R14.3 - - Switches having a 'sizeof' operator as the condition are deliberate and - have limited scope. + statements, conditional operators and 'switch' statements are + deliberate. - Tagged as `deliberate` for ECLAIR. * - R14.3 -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 06:01:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 06:01:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460757.1671612 (Exim 4.92) (envelope-from ) id 1xLDlM-0002fH-CG; Mon, 26 Oct 2026 06:00:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460757.1671612; Mon, 26 Oct 2026 06: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 1xLDlM-0002f9-8K; Mon, 26 Oct 2026 06:00:52 +0000 Received: by outflank-mailman (input) for mailman id 1460757; Mon, 26 Oct 2026 06:00:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLDlK-0002f3-Rv for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 06:00:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLDlJ-00H1BM-Ox for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:00:49 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adeec83-8faa-0a2a0a5109dd-0a2a450595ce-20 for ; Mon, 26 Oct 2026 07:00:45 +0100 Received: from [130.76.144.163] (helo=clt-mbsout-02.mbs.boeing.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adeec85-4cb1-0a2a45050019-824c90a3b50e-3 for ; Mon, 26 Oct 2026 07:00:38 +0100 Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 69Q60Za2005321; Mon, 26 Oct 2026 02:00:36 -0400 Received: from clt-av-01.mbs.boeing.net (clt-av-01.mbs.boeing.net [144.115.64.247]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 69Q60Q7x005249 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Oct 2026 02:00:27 -0400 Received: from localhost (localhost [127.0.0.1]) by clt-av-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_RELAY) with SMTP id 69Q60P3I010594; Mon, 26 Oct 2026 02:00:25 -0400 Received: from A6432926.boeing.com (a6432926.nos.boeing.com [10.191.242.9]) by clt-av-01.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_RELAY) with ESMTP id 69Q60IiK010298; Mon, 26 Oct 2026 02:00:19 -0400 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=boeing-s1912 header.d=boeing.com header.i="@boeing.com" header.h="From:To:Cc:Subject:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1792994437; bh=eVTKD9hb+427DYCjbfL0vWk9SDVwZ2YRtZbvyety0/Q=; h=From:To:Cc:Subject:Date:From; b=GAoio6nFdTRF8+tOdUV8R5COnLm1lL/v1o/JeCYSx7e1zmbQUu1R/urhw39hGug5U ftBp+UH9E/3i9qDWS/+TJdD2upz4XHOKBSW6+SBRFBeT0r4fSra/c1PfS6etue9gNF 8oKP23fTRdfPME9k9Atiq+IZzhPey2gVVhZyj+CMMf/oJJmPx4EHwS+87jiYsjM9DE BGgfBhRERfC9SFsX8/yqbAdFCl0tN20jDN1iqlBgVFNL75wZCyD24y05bJqmm+/U/b 6/Ff/Pc9wvlCMj/1UAUxLoyPyclO6D0ijAKPSrjrWUwiVEFISJTvFVD+sA+xAamWBY zX0W6ksz0GQjg== From: peter kang To: xen-devel@lists.xenproject.org Cc: anderson.choi@boeing.com, matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com, Peter Kang , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [XEN PATCH] xen/page_alloc: scrub each page in unprepare_staticmem_pages Date: Mon, 26 Oct 2026 15:00:08 +0900 Message-ID: <0caeae8b795439ba7f9d466571f0d125b924feaa.1792992356.git.peter.kang@boeing.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-purgate-ID: tlsNG-c201ff/1792994439-738BE2A1-610167B3/0/0 X-purgate-type: clean X-purgate-size: 1394 From: Peter Kang unprepare_staticmem_pages() can unprepare multiple pages in a static memory range. When need_scrub is true, each page must be scrubbed before it is marked static. The loop currently passes the base pointer pg to scrub_one_page() on every iteration. For a multi-page range, this repeatedly scrubs page 0 and leaves the remaining pages unscrubbed, so a guest can later read stale data from pages 1..nr_mfns-1 of a static or static-shared bank. Pass &pg[i] to scrub_one_page() so each iteration scrubs the page it is processing. This ensures every page in the range is scrubbed before it is marked static. Fixes: 4a9e73e6e53e ("xen/arm: static memory initialization") Signed-off-by: Anderson Choi --- xen/common/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2682fff9cc..426bd11c2e 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -2941,7 +2941,7 @@ void unprepare_staticmem_pages(struct page_info *pg, unsigned long nr_mfns, if ( need_scrub ) { /* TODO: asynchronous scrubbing for pages of static memory. */ - scrub_one_page(pg); + scrub_one_page(&pg[i]); } pg[i].count_info |= PGC_static; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:18:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:18:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460785.1671634 (Exim 4.92) (envelope-from ) id 1xLEyJ-0003ia-Jy; Mon, 26 Oct 2026 07:18:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460785.1671634; Mon, 26 Oct 2026 07:18: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 1xLEyJ-0003iT-H1; Mon, 26 Oct 2026 07:18:19 +0000 Received: by outflank-mailman (input) for mailman id 1460785; Mon, 26 Oct 2026 07:18:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEyI-0003i1-2w for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:18:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEyH-003Mc1-Fm for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:18:17 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefeb3-bab6-0a2a0a5309dd-0a2a4505e26e-30 for ; Mon, 26 Oct 2026 08:18:17 +0100 Received: from [40.107.201.53] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefeb8-4cb1-0a2a45050019-286bc93529fb-3 for ; Mon, 26 Oct 2026 08:18:17 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by DS6PR03MB235817.namprd03.prod.outlook.com (2603:10b6:8:418::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:18:14 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:18: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=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=LRz+n1fV4FdueZ28Yy0I71M0wplELay1oFsFAdUYtKm9e8s4ZJG92gvBjQzs8Ldt3fERlX1+kFpGu/p9TWNa/1XZ5F0OpnsSXxgXJzYajfdACkJB2OoXJ7kH4sgbKL4qcVcR5lASvr9X8lh/cYiJ1H9+cNIiY1YTTqWjtDHZDvy0/HuzHGyVK2vm8DOoce/S+EZSPZo3ztirlOquBvqF42qRs34N3oEL28l19TW4xucFSAo9k9uG+oBjkxwxTYXSdQd+PnGYqqXPt6mmo/mHv1HsIGbOJxt+QiHxBmKituhrhd8PnjBBp/GN9v1McT51+dE/0MIS0Yoir36Q1HJf5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uOROdr3Lsj2WWcWL/9pNfOId1Ctpk0JV6ASZ1lvZtqo=; b=q8cSowPU6HZvURRCNWe3aIV+Rtj8Ih5TnB1UqtAEAMuhmkPYvuMiaHs96E6p1gdrZhQBlsa8A0fA8K4SImML+VPJBEFEPA8C9WUGDWgEwlP9Ubukuzt0TkyYI25BvhNFSiINzoZKaKhnBtah4UZEo0Rdw6WTwDCw/ReF2rBGHN4rhJbeBmYMDRpJLRbzMY8EUQzDLuXUNmuMxOiLslL90RTAlucPnWfXf+1uvMpoxdTHrCVFRGDeTdXJYtSmwc2V8K4zndNV2rKE5B/aJHbKGsVGzIFuqdMNnSQoXJr1yCcx11KHljqcnA1h1J74i86RJ6q7q6a7XqKHPSEIA9vX0w== 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=uOROdr3Lsj2WWcWL/9pNfOId1Ctpk0JV6ASZ1lvZtqo=; b=uIT0i8MvSbEIQF12wpvg/bbHYtNpGTyPErsfqdv0kNJz+NDtXGPTVYOklWtF5+m/lA1abAQcSmzXVsmZbzd+tqNtW5+VUSoeGRT+EnMY59zCKrDBSi0dU0VFfJBwxoRKW9vJRfHj2XEJuFTaR0P6rs6jBsKalIfZnC8tAt52E4c= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 1/8] x86/nestedvmx: Preserve hardware access bits in reflected EPT violations Date: Mon, 26 Oct 2026 15:17:47 +0800 Message-Id: <50dc000032bd10afa369f9ce83fcfa237aba957a.1792997742.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: FR2P281CA0186.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9f::20) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|DS6PR03MB235817:EE_ X-MS-Office365-Filtering-Correlation-Id: bef12410-81c7-4a15-325d-08df33314c20 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261022105027099003|261021121427099003|261021123027099003|10067099003|56012099006|3023799007|22082099003|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: 5n9jwZcN62MZ6FjMkC5Is4C3FldMWDH0ZSb9E0bwGLjcmNHrkSNjlFZkhB50+wqFJkav7+gN2wUjPi6DlMG0chT/wxSSHUKi64grbQu77dhCoGHxHHRUn7ojMFQL4oE91mdYexY5qpJgVPVoHAtQziIHoE0W7f8bbobdLzdSdq2DAZ6jx616fuI7pXg1XZex2Amhq/VBMKBa6/3ZqbZLyMylGktAPXgIA1Z1ulHAg/qO6rR43cvIrXE/clnunZT6JHD4rURsOGX1ncIvWQOij3kAVkBWtTpKZBF2kzNNliJA4VTbdN+elhowjJM/lOsRGL8A/4je8gQjC23GM9CvTHLz+9CzLX7F6goQiu0gqx1Fu6NaHgFSvu6vfpy2KU4mRLzct0Qk11//qJ0iEi9X5rSoS7k0yRqZYhdZnas2L5x30GkNHgRrmKKovHaJrCVV3DoqudKDchcuG2D/h2hJhSIHqAerjXfNB1j9QvytuI1Z35W56wsu6mN/nsGBQo9SqRC+lMGAkFuW27AKwb2OzhE/3ay9YbKsay44zeJxJDz3YnhcTtXW0njBOtiSS5JimOSzF/InvMW+dT6eFiLyqkAHo0GLIxX96AJMqzpxJqR5q2TFfxrrRY1Sg88Z5jyr/nSFGaSZmLlUezRJmu0ejmKLB+2FPD3M/PXog758K9A= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(261009223027099003)(261022105027099003)(261021121427099003)(261021123027099003)(10067099003)(56012099006)(3023799007)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?l9w5yx8ga3VUqt1QFZ4CLLl8pmAkmvcfOtVU+8YLUS9kUyCNNsdzYIIYT+M7?= =?us-ascii?Q?PcRdgbJL2ArAXL62U7UVCFbRopbrKCaC27fMv4KeNHgum8/qWMNaQmsrMVMq?= =?us-ascii?Q?Qd87EF34ImaWlMrXWUJeIsTlkTgAq7zHVurLC7w9tSy8xbdO93binsVcUF+N?= =?us-ascii?Q?+76qq/V0/zJ/R2wLK01mIr6C+KhH5mG0A9lmckzVRdWJVMmXV5hf6kuNf0Wt?= =?us-ascii?Q?qbTtKZdjm9h7cfALH7ZqigjEnGU6G4c+NQMfIXAJfWbiDJ3ZIo+lI1GJ7vya?= =?us-ascii?Q?U9EXXzJt85+GmXSrWi72FrBeauVhtkJ4NCAqM3mkTwD+XheW4TWWsl1gpy+p?= =?us-ascii?Q?Vleqdix74Vr9tJtcAJzQcIemqkQKpMKqJhg68G4WhVeI7fvf4bUEHLOf8AN2?= =?us-ascii?Q?vJutDBtseXpChp7JlCB36wFM5p3edpehkzRhKXWuy31Mqz1H3G94EcTk8D8G?= =?us-ascii?Q?rmBkFC/OORoOULB633iZuA8LP77rfBUqfSEe2c0f/9Q5e/Gb23iwBoW2U//y?= =?us-ascii?Q?yP1ZkX/eonSP1oso05zGesXgHGO8TqQNjVx7cozlMQJ3XIk0WV0rZzEPtWSK?= =?us-ascii?Q?KvmSw0Ur38agbsbz3VYKToFmXVRgVA52YjXdpPVtxd6Hex686wCp4FbMgSV+?= =?us-ascii?Q?MgVd0tRj1YggvrLrVDeSllCGWiYQAwq0aj1X44dt4vVd++yo5OApDmgwjnci?= =?us-ascii?Q?migrrYC3lRLcNqy5ZCfrCdXBKzSY+RwQDYnfIaAtE85OufDBXeZRV9RVb34k?= =?us-ascii?Q?L/0bbq6dP56o1PovRa3kJvx6/C0CndroLux2UAFWnD+q+8Sj1Bj5tipeIoFy?= =?us-ascii?Q?ZwtCO9rktpZ7cmFyx9P6rG9LpeOtTwva++UlAW6Od2PkYqQoeieVWecCR+qR?= =?us-ascii?Q?nBKKX3cI1jUOAs693HiwPp9C6aST3Nj9S/AplvlYCqOOZ7/6RrlRMZWVppsy?= =?us-ascii?Q?TmfvwtSmLYNxaSEHImiujfHkf6a4W8co/uV0AjzofAwZRZJ9rh/NhUCdRDll?= =?us-ascii?Q?W5zb+ZM/nUxDQO2stmO5VDA3QchWONVAfQgXKoCwXo9k7zKSSdAfVAEkg3ui?= =?us-ascii?Q?CWQeSTNDPKY5IhXkzx61Z04gDONhKQyLhECGOw7iLOm/J3spfDAYKcQqg9WP?= =?us-ascii?Q?2XMJebG6TXwdwoRlnM/H6iX+rY70EMpwaZ7VoTJObxWcgPTSH3MasN7Pf0VJ?= =?us-ascii?Q?7F9YSm4TCnX3t5mjSU/cPCsUwrBraDkw6RsGNHtPrewVHkPRGBeM2vmsPBhV?= =?us-ascii?Q?5MWERJuQBVS0IZoVw3sWvd/nLsEthOZcgefgxlNWq/vUE1YRwgBs7ct6hxeK?= =?us-ascii?Q?vYzceaBRtdsEXbtKpRNYiZ7vTzo+Q0dxmvtnJc7somiIxyHfRLwmcFw7wuYl?= =?us-ascii?Q?TwqJynZyNG6S3oxMwIBFBO0Ts7S72MFW2ioo5Z8REHHcEmMfpAH3alchMSoy?= =?us-ascii?Q?ZC6DwNSqLp5Ewatigk4m7e8UbDV7FqNtk8Z65tPQBag36VtS2k9YOAQ2tuOD?= =?us-ascii?Q?i4gOoFEgbgPwTzj7gg5xRPnZZbCavj6VULR/Hj78dnxWdv3nL7i2g8YlGhKp?= =?us-ascii?Q?rHVbQGKhzubOBehRAevtIjbxk2LT7urGNcifB+/GfH9kwSirEfQP49Ua/YE/?= =?us-ascii?Q?cDDEkBXVnCzHPSWnYZk9XzERaTGNl7wv9970EwEoyXKGaY3YOHZWeF6x7Qs3?= =?us-ascii?Q?QZX3+mHf0P/vrB8FlY9anU/zJNU38Ht3dMZWCqkSzuuwIgd1/5vttdU4tRg+?= =?us-ascii?Q?KZBUJ78Gmw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bef12410-81c7-4a15-325d-08df33314c20 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:18:13.6269 (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: AUE350QmjjjI15w5XZlCZomHfnlDqpyiB76rHbEoagehlyowHRdg7QSnH7qVjvkEE8a2aUkhN2WQVsDecuF4ew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS6PR03MB235817 X-purgate-ID: tlsNG-c201ff/1792999097-F60AA2A1-7D3E4CEB/0/0 X-purgate-type: clean X-purgate-size: 1909 From: Chunjie Zhu nept_translate_l2ga() rebuilds the exit qualification handed to L1 from rwx_acc, which is derived from the npfec set up by ept_handle_violation(). That function deliberately treats every write violation as a read as well (read_access = q.read || q.write), because the SDM leaves bit 0 undefined for read-modify-write accesses. As a result, a plain write by L2 that violates L1's EPT is reflected to L1 with bits 0 and 1 both set, whereas bare metal reports only bit 1 (data write). The widened access bits are an L0 implementation detail for its own permission checks and should not leak into L1's view. Keep bits 0-2 of the qualification as reported by hardware, and only replace the GPA permission bits (3-5) with those from L1's EPT entries. rwx_acc is still used for the permission check itself. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/hap/nested_ept.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/hap/nested_ept.c b/xen/arch/x86/mm/hap/nested_ept.c index d88d677825f1..e116d8254824 100644 --- a/xen/arch/x86/mm/hap/nested_ept.c +++ b/xen/arch/x86/mm/hap/nested_ept.c @@ -255,7 +255,12 @@ int nept_translate_l2ga(struct vcpu *v, paddr_t l2ga, rc = EPT_TRANSLATE_VIOLATION; /* Fall through to EPT violation if permission check fails. */ case EPT_TRANSLATE_VIOLATION: - *exit_qual = (*exit_qual & 0xffffffc0) | (rwx_bits << 3) | rwx_acc; + /* + * Keep the access bits (0-2) as the hardware reported them. rwx_acc + * treats every write as a read too, which is not what L1 would see + * on bare metal for a plain write. + */ + *exit_qual = (*exit_qual & 0xffffffc7) | (rwx_bits << 3); *exit_reason = EXIT_REASON_EPT_VIOLATION; break; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:18:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:18:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460787.1671643 (Exim 4.92) (envelope-from ) id 1xLEyQ-00040X-28; Mon, 26 Oct 2026 07:18:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460787.1671643; Mon, 26 Oct 2026 07:18: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 1xLEyP-00040L-Uo; Mon, 26 Oct 2026 07:18:25 +0000 Received: by outflank-mailman (input) for mailman id 1460787; Mon, 26 Oct 2026 07:18:24 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEyO-0003yO-PM for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:18:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEyO-00FYxb-6K for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:18:24 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefebc-e002-0a2a0a5209dd-0a2a4502d00a-12 for ; Mon, 26 Oct 2026 08:18:24 +0100 Received: from [52.101.43.53] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefebe-6ca4-0a2a45020019-34652b35a76c-3 for ; Mon, 26 Oct 2026 08:18:23 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by DS0PR03MB989640.namprd03.prod.outlook.com (2603:10b6:8:42d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:18:20 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:18: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=WuHMNDm5VMzhCRxFnceL8RVGBbzdWssoqJ1W+/vI6BxYTfbnI16EO0W7+ainvBToOlRYXY6++t1TvnLBFLZUV2aa215BdTQ+5d9wZjWV43mM7uAHFUYb98+g5rRcOIwkuSBzQ4E9rlkqcs0lvxJ29AZqmw/v5keuSqIW8CZltilw+TxxjH9XfXT0J03s0p2iWKNgPF/kCPOY5BRl4oVJYI6CjaYgj4hwWDXQDXkRmJRommviWpxh8+mxaIk38yPW0Y6AURTa2ohJqOFcsXtlFTqPVwU8GYkNMUqdjBUqNlU5F/aHeWdCTYNZ5aDl1fP3SbGkKZzrLPvtBBfHrCoTBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LIpvwqXiW4c9cb/0X0lfQu2ZpnfZOAOIuulOf744hT4=; b=xoL+3sPtGTubXWhHy+PsJytlTQ9HUMM5hROSzGpywhyQFhPrEoQ9Gwh71kMaBC9/xDx+pQFFot7Fh/8FG1hE4/WBSXyWqzNeZsk1jrLtg7TOr9v8zaGXPvp7NJuLume+PkgGvGYSFciemxYNvNvwymBaJExY68lj6u8VrEFl84Nb2glYsZIw+OBI0nkFCjYA4oQkX1jYV1vtBGWRHNHY7p0g9nvSfJs8CMYIGqtZIvVysDa296EsqcpQnLyLjDdcqyAblnKRzUHIkIH0TWDSDR2PE//XQ6AcAL4ZZC6xaH8Lu1xhlshM8CPUpQfARc+anVgJTsHHxhm/VBbIXL6T7g== 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=LIpvwqXiW4c9cb/0X0lfQu2ZpnfZOAOIuulOf744hT4=; b=aBtMg1NmYZ+VbaBXpbUaK14rUhhiJ+V6Dxr4WZbd2vAvSkbxKlvVeHznL7+NTYW8M2phoNppH2j0TWU0hO3McjS0WScCTV3zHU0/ge9RxsbJaJxOhV0vV5dl/wT/FkY893qPf9a9BVt2exxIaUW0cJaa64LrjRmbljSs4baoR3I= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 2/8] x86/nestedvmx: Implement nhvm_hap_walk_L1_p2m2 Date: Mon, 26 Oct 2026 15:17:48 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI3PR03CA0002.apcprd03.prod.outlook.com (2603:1096:4:297::9) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|DS0PR03MB989640:EE_ X-MS-Office365-Filtering-Correlation-Id: 72eacd58-1b4b-48aa-befd-08df33315037 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261021135927099003|261021121427099003|261021123027099003|261022105027099003|10067099003|56012099006|22082099003|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: IMmS1zqpvXCL6jeaM4Fykn/HW215Uon9JJ4cE/vqk75IKPbagGkk3VY/5IVyJbXtBaWLvDLOQgzuPACKVQ3m1TmjeeXb+EcJ4AoPr8oBZrJOs3tLyf+hFYG1yCDxUSBVO25nsVANmLMr3GTJLclHxuMM6M6OK47B0ff3DtEmmBLcwGPKCBD0gAen8NdjzF9XkBcKTp8K4GP1XacfaoBgJZ/jPvYcJUMxWsi+Sve9A09lsBBRNjUqOyj0rBuw0+5zj+GmIj1Mi/BPVzENZeMgcAyLO4/tZVsTg/pFRjpoKA3M4dAGmxXU9S9mKR87egaAgBJ0gtUvkipqL7UMlZtxr9joMnNgkiC0tdCsF22PynlD9FYibnyncvfciPnRMH47qGOCInGaQdsMfUKflt0dlFsibBjDx5HrUxux//HReupr3SncZ0Z/04SmkB0ppfOgLJCTRqsAIH0gb/t9W3thB39ltF86Aep0eZdJBvuIa7l/g2UpOWQEvBYKoyfIanO1pCcNgtYyB0S7hXQCnDpqtWPnV4dJSoYT8QZRzo2TWWT23+JZiEyJBmBELh0ncR8oQNByoyhMpB3FioKwWNWemAOH2BSQ9LDLOJaoHz7h0EhwBHptjgWtMWGh133uEq09AuQfaJFAZbu5JVVEguPQVSfFZ1a/KQJp1ElGmmZSteg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(261009223027099003)(261021135927099003)(261021121427099003)(261021123027099003)(261022105027099003)(10067099003)(56012099006)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?rwZzSgFPeG/+02WFwZV8LXE9Ism3A0GqAglV9rOoh8WimAUf8xgFQ5acJ0bF?= =?us-ascii?Q?qwrHNvDHVasPQ1HQt9TkFpjK/Uf4Yc5UirGn+atppujxajiATxku9k2QyUo7?= =?us-ascii?Q?axaTHua3ruk0p72Rr2uphrKD1hF7iLlxYu3KnQTYqf9U/0DtFAW2jTGoCUd4?= =?us-ascii?Q?ZhUaUl3rnHLh5INnt20TPCEw8EQnzkouWq1yWPqhvSY/2Eg6pR8p8UHcYwu5?= =?us-ascii?Q?lVWGLahsI3o+8qgeDOv4wVjkkfV5ZGMqyvm7/UOS6Gkcb0ph/VOxPAXNPgLH?= =?us-ascii?Q?LuzOLnyz+TF4ZiJ/nnhkGIOleoFIdUNyaba2HTF4C+YSFt2YOy3OhUoIzR6V?= =?us-ascii?Q?SrpadXTWmZ6S403fJHL8ezSxwcabUuAAuxGWO8Cong+xsv8l3JrixNPryxwm?= =?us-ascii?Q?N3ekz+YO2p+8JMQlCJG6cqYaHHC2CuOKlTmmGB5vYESBitI+hD7xyb+spFPR?= =?us-ascii?Q?X/R7Graln0Zhe2kodvFQVLvTJU4yoMk4sDN/hP6pfEBzgKrFfyV7QTk7Q5A3?= =?us-ascii?Q?zf8NaMqM5TI5dCmGNfcxOBRCS90MeQ6jWC/6OwMDQPYRiEa9+pjLeXh9/ZUD?= =?us-ascii?Q?Sj4IfTLf2QzEcfiYW/0vZoC90pJ+O9z8xmSKGDavDxjz0E4hZRHvdzkYSaFc?= =?us-ascii?Q?3GjcqdosAty0h4Iqdcs9Yjl+gXS6BY9pSKe5tpMLKDGpyjIi4sIDSnPxDBLo?= =?us-ascii?Q?QB3/Y6CfJtVQKtVgnBP4MYbD1TONOQ6xAalnqiAZHs3Ox2YQisdKGCuChdwv?= =?us-ascii?Q?Igo8xxyJ02+j60UXG/Hbna+lrALiWnJ2Qu9qAfgnz0rmGFn8HN5ygajq0LGk?= =?us-ascii?Q?YIGq+8wUr1SIBwvSXp3ttSSIS/pr2oglVYQAQLPPxxw3rtTCHALmpjST4bVV?= =?us-ascii?Q?Sq8V8uCCFKiCRwULpB7sVeqHlN4kRj02D1Hz1mO8Xl34ZQjF8hqT49ii5jJh?= =?us-ascii?Q?1Rj9y2kX2F3LwquBkj21XvZMHm1XdmgIchJ+WuAqZtBZIYn1s/ZgDngUzIHO?= =?us-ascii?Q?o1CYwfVu0TYkTNd1nL6S8omGP4NueQT8lpK+293bJIOqQfj7oeJzY7oFRXSz?= =?us-ascii?Q?MEHsBgcygUv+mqQLOVyj8w4WA7m/KeZNkak2voW+r56GZlQFpxk49RcPSt3t?= =?us-ascii?Q?L70APQOGppq33DG3uLa8AIjxZs3iC8GPZQyIslYvV0xLK+D9MkPtn2L6iTaJ?= =?us-ascii?Q?oQ6dDgAwfhX+5mg/quEax4EBzAY3P7UbAW0KMtvNrOzq9fIm4MgSTxikK0cO?= =?us-ascii?Q?06tmJc3Vpl8Is9BL/yaGwXylgbaOArIBb6mkNk3Jd/rXqHH2oAAphMgi7ckU?= =?us-ascii?Q?A78ZLQddhc2AaEBOLbNWjjHVEt+cERi7rhD3phBE6bQTXC20yLnZg1Wvrctz?= =?us-ascii?Q?t8EEd7XJBrTD0ONfRpN9mMsZ5uh9FD2g8D2jp2D5T0LGwCWQctvYCKSj+pSZ?= =?us-ascii?Q?SardVjKpET2dhKz5HiWSFi3WVvU3dar8WZwWHOxqmGHitEYA6g1/IepyJ7qO?= =?us-ascii?Q?ca7BZjG/s+6c36hmnpWJ7fIbUFUIKVtAsePWct11w8jCDgl5G+PIbrqP0z21?= =?us-ascii?Q?FS7JZc3JWJ0AP/tNv4jlMc1Shlp2EYDmWsg2PbBmX/bgnfcCCbrNeJQx3QRj?= =?us-ascii?Q?ER1KkEBqa88oM78uvdiAnptQCwqBSwjkqkh0b2l8ji5i2yMET8l6mVSmAR98?= =?us-ascii?Q?YEGgO2ziIpl6TlrVR8mHvciqRCdYLizvRj6MTH5cR9KxLS7tWbUVHQzRnhlt?= =?us-ascii?Q?t9FbOE6p7g=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 72eacd58-1b4b-48aa-befd-08df33315037 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:18:20.3278 (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: NM0fBY+OfaFgpbhhsXThDdv6eegvl11uEDR28VHlk3EgNM36kh0M7CIIGMs0+XknQQcOKi7Mcs1FejQODiJ8AA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB989640 X-purgate-ID: tlsNG-720697/1792999103-F3EBB2AC-C4237FCF/0/0 X-purgate-type: clean X-purgate-size: 6545 From: Chunjie Zhu p2m_get_page_from_gfn() on a nested p2m calls nestedhvm_hap_nested_page_fault2(), which walks L1's paging structures via hvm_funcs.nhvm_hap_walk_L1_p2m2. Only SVM provides this hook. On VMX it is NULL, so the alternative_call() ends up as a #UD in L0 and the host panics. It is reachable from an L2 guest. An EPT violation on MMIO makes L0 emulate the access, and the emulator walks L2's pagetables through the nested p2m. nhvm_hap_walk_L1_p2m2 nestedhvm_hap_nested_page_fault2 p2m_get_page_from_gfn hap_p2m_ga_to_gfn_4_levels paging_gva_to_gfn hvmemul_map_linear_addr hvmemul_write hvm_hap_nested_page_fault Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/vmx/vmx.c | 1 + xen/arch/x86/hvm/vmx/vvmx.c | 39 ++++++++++++++++++++++++- xen/arch/x86/include/asm/hvm/vmx/vvmx.h | 7 ++++- xen/arch/x86/mm/hap/nested_ept.c | 10 +++---- 4 files changed, 50 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 3c7374a9ff42..ed4ff56e7797 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2892,6 +2892,7 @@ static struct hvm_function_table __initdata_cf_clobber vmx_function_table = { .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources, .update_vlapic_mode = vmx_vlapic_msr_changed, .nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m, + .nhvm_hap_walk_L1_p2m2 = nvmx_hap_walk_L1_p2m2, #ifdef CONFIG_VM_EVENT .enable_msr_interception = vmx_enable_msr_interception, #endif diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 29e48387a110..8d6e0c66f38e 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -2355,7 +2355,8 @@ int cf_check nvmx_hap_walk_L1_p2m( vmx_vmcs_enter(v); __vmread(EXIT_QUALIFICATION, &exit_qual); - rc = nept_translate_l2ga(v, L2_gpa, page_order, rwx_rights, &gfn, p2m_acc, + rc = nept_translate_l2ga(v->domain, nhvm_vcpu_p2m_base(v), L2_gpa, + page_order, rwx_rights, &gfn, p2m_acc, &exit_qual, &exit_reason); switch ( rc ) { @@ -2383,6 +2384,42 @@ int cf_check nvmx_hap_walk_L1_p2m( return rc; } +/* + * As nvmx_hap_walk_L1_p2m(), for a walk of a specific nested p2m that is not + * tied to a VM exit (e.g. L0 emulation reading L2's pagetables). There is + * no EPT violation to reflect to L1, so only the result is reported. + */ +int cf_check nvmx_hap_walk_L1_p2m2( + struct p2m_domain *nested_p2m, paddr_t L2_gpa, paddr_t *L1_gpa, + unsigned int *page_order, uint8_t *p2m_acc, struct npfec npfec) +{ + unsigned long gfn; + uint64_t exit_qual = 0; + uint32_t exit_reason; + uint32_t rwx_rights = + (npfec.insn_fetch << 2) | (npfec.write_access << 1) | npfec.read_access; + + switch ( nept_translate_l2ga(nested_p2m->domain, nested_p2m->np2m_base, + L2_gpa, page_order, rwx_rights, &gfn, + p2m_acc, &exit_qual, &exit_reason) ) + { + case EPT_TRANSLATE_SUCCEED: + *L1_gpa = (gfn << PAGE_SHIFT) + (L2_gpa & ~PAGE_MASK); + return NESTEDHVM_PAGEFAULT_DONE; + + case EPT_TRANSLATE_VIOLATION: + case EPT_TRANSLATE_MISCONFIG: + return NESTEDHVM_PAGEFAULT_INJECT; + + case EPT_TRANSLATE_RETRY: + return NESTEDHVM_PAGEFAULT_RETRY; + + default: + gdprintk(XENLOG_ERR, "GUEST EPT translation error!\n"); + BUG(); + } +} + void nvmx_idtv_handling(void) { struct vcpu *v = current; diff --git a/xen/arch/x86/include/asm/hvm/vmx/vvmx.h b/xen/arch/x86/include/asm/hvm/vmx/vvmx.h index da10d3fa9617..2e0ac5798d5d 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vvmx.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vvmx.h @@ -89,9 +89,14 @@ bool cf_check nvmx_ept_enabled(struct vcpu *v); #define EPT_TRANSLATE_MISCONFIG 2 #define EPT_TRANSLATE_RETRY 3 +struct p2m_domain; + int cf_check nvmx_hap_walk_L1_p2m( struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa, unsigned int *page_order, uint8_t *p2m_acc, struct npfec npfec); +int cf_check nvmx_hap_walk_L1_p2m2( + struct p2m_domain *nested_p2m, paddr_t L2_gpa, paddr_t *L1_gpa, + unsigned int *page_order, uint8_t *p2m_acc, struct npfec npfec); /* * Virtual VMCS layout @@ -193,7 +198,7 @@ void nvmx_set_cr_read_shadow(struct vcpu *v, unsigned int cr); uint64_t nept_get_ept_vpid_cap(void); -int nept_translate_l2ga(struct vcpu *v, paddr_t l2ga, +int nept_translate_l2ga(struct domain *d, uint64_t eptp_base, paddr_t l2ga, unsigned int *page_order, uint32_t rwx_acc, unsigned long *l1gfn, uint8_t *p2m_acc, uint64_t *exit_qual, uint32_t *exit_reason); diff --git a/xen/arch/x86/mm/hap/nested_ept.c b/xen/arch/x86/mm/hap/nested_ept.c index e116d8254824..f8563156b6d0 100644 --- a/xen/arch/x86/mm/hap/nested_ept.c +++ b/xen/arch/x86/mm/hap/nested_ept.c @@ -136,13 +136,13 @@ static int ept_lvl_table_offset(unsigned long gpa, int lvl) } static uint32_t -nept_walk_tables(struct vcpu *v, unsigned long l2ga, ept_walk_t *gw) +nept_walk_tables(struct domain *d, uint64_t eptp_base, unsigned long l2ga, + ept_walk_t *gw) { int lvl; uint32_t rc = 0, ret = 0, gflags; - struct domain *d = v->domain; struct p2m_domain *p2m = d->arch.p2m; - gfn_t base_gfn = _gfn(nhvm_vcpu_p2m_base(v) >> PAGE_SHIFT); + gfn_t base_gfn = _gfn(eptp_base >> PAGE_SHIFT); mfn_t lxmfn; ept_entry_t *lxp = NULL; @@ -209,7 +209,7 @@ out: /* Translate a L2 guest address to L1 gpa via L1 EPT paging structure */ -int nept_translate_l2ga(struct vcpu *v, paddr_t l2ga, +int nept_translate_l2ga(struct domain *d, uint64_t eptp_base, paddr_t l2ga, unsigned int *page_order, uint32_t rwx_acc, unsigned long *l1gfn, uint8_t *p2m_acc, uint64_t *exit_qual, uint32_t *exit_reason) @@ -220,7 +220,7 @@ int nept_translate_l2ga(struct vcpu *v, paddr_t l2ga, *l1gfn = gfn_x(INVALID_GFN); - rc = nept_walk_tables(v, l2ga, &gw); + rc = nept_walk_tables(d, eptp_base, l2ga, &gw); switch ( rc ) { case EPT_TRANSLATE_SUCCEED: -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:18:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:18:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460784.1671626 (Exim 4.92) (envelope-from ) id 1xLEyD-0003VZ-Ea; Mon, 26 Oct 2026 07:18:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460784.1671626; Mon, 26 Oct 2026 07: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 1xLEyD-0003VS-A5; Mon, 26 Oct 2026 07:18:13 +0000 Received: by outflank-mailman (input) for mailman id 1460784; Mon, 26 Oct 2026 07:18:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEyB-0003VM-Sa for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:18:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEyB-003Mc1-00 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:18:11 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefeaa-bab6-0a2a0a5309dd-0a2a4505b722-44 for ; Mon, 26 Oct 2026 08:18:10 +0100 Received: from [40.93.201.42] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefeb0-4cb1-0a2a45050019-285dc92ab773-3 for ; Mon, 26 Oct 2026 08:18:10 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by DS0PR03MB989640.namprd03.prod.outlook.com (2603:10b6:8:42d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:18:06 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:18: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=uAuW0GF914EbcsHOHm6rlG78zhlxOaEd9hTww3QEOWCJmFvL3gvTmkZ1gZd7vbvU1Qic7V78LY+4dNnGn1O6HuzYwNxDu6LgqXQOEHaK8PtNsbZpCWPjulf1ikUtzi56D26Co8BudLRVnTP5ON++KhqdiDGzflr1qh5UV2pI7Ff81bbvP1q4DUNCC9vYj1/vEopQ0lY4ZM9eVXzQN/Y7wc7U5tLwF27Wna0bZU5zoch1szJ4kTxaBd9fJaQcoyADCsmm58/4yrqzvvMUxJZtM7iMdR0vK5O7qfCkae1e6Shfhd1FVhNkuYHpdex0vIS5CVmW3y2wyy3oS2FddbDfeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MZ4b6/zSvCbyu9Tayf7mShTmi92eHn/QkrGHSZfCc2U=; b=pKowiQFYZYbwm7WD+Jra9eJCdRejY28qJ4AjhmyVvrNvX+G2JFgOsLQZe7EX4v4qFe5LKLHcEY0/fVDwfR0FD8PfzjkU4cqc05d1An6PbXcCepTAtR8Uhkhf9uoFB4TEFiUkinNfFDgZKaEClzd+f+PVFg8R2b0Q+ufLmr8KL4PAUfvmvIfh8UTajP+8sT4vPrhrX5ASc95NqcMLOnXfAfYj9+0b3aYCO88iHipeoqPLyH5vspc48QleIB1rCHG1QDQwoXL87dfa2ay8QbOj3yDeTWmlT/T+8WX9SNyvB35zuJpdwmtb1WMo14Ch5WrX8SK0dWYDcu2cthl5awdLEg== 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=MZ4b6/zSvCbyu9Tayf7mShTmi92eHn/QkrGHSZfCc2U=; b=ev/thFQy3XQTQIueRaiouGJTlFqvc9pg54XlwwCDxvkV8BFHUiN91t7a565GYRp5rvbld+oc/GNLCErPNemJS8GH4CAiB9QDOVpp08mcoamk/ZwdBd2qsEOpU3syw2MQ05JNDMjTMHtjxAFDv1R78lFPIROppOYPq+Whwo+OuY0= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 0/8] x86/nestedvmx: Fix nested VMX bugs Date: Mon, 26 Oct 2026 15:17:46 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2P153CA0014.APCP153.PROD.OUTLOOK.COM (2603:1096:4:140::6) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|DS0PR03MB989640:EE_ X-MS-Office365-Filtering-Correlation-Id: 4498ab00-f662-4c6a-51dd-08df33314748 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261021135927099003|261022075727099003|261021121427099003|261021123027099003|261022105027099003|10067099003|56012099006|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: 0qVHgh4OA7liO8xLeZA416A7eE7y3KeaI2Yw02yQx9V0xfw9Eix6KZbWDj0/o84eQbg0pEu40Me0BL3RjubCggdzF4UGwhERKpgtdpAztW0j/PRm1D+KpPpXeyKyXz6Z8FvgIBQOSTm4imwTjyy/ykwZQkgO2C1hZngzrif12RQ3eaFj7LHAJZY5+nGilvU7L9lXlhGRrl9Opsefwm2zPxofZ4Mmma1kTss2rR4RYxLgHjCAqfjm6dMlZNNHMr5UmIQQStmJUbDe5TYFphKMPt9teHMtFVMfRX5AYowE0GzGV8LGtQ7zSkIba5TSQ1JZ6RbG0bBXY1RncYFe9HHCjoMXxwba31qIzL5Cz+NfRMEj6R21Yb/+rXqVQ8Dby70Qg0rs/SXvF/DlnObLeGmHW9qCLbbVNcGZIUmh+G25vtf3q6ln0iZxR2v0sJ/eleTv3Gsq+johkA26aCnqC8q3CMLNrH4CdIKJ6UguXzUNzHgBg+Lil7bnc1axFilJ6CxIR1YmUJz4ysFClmGKhEwnaxKEqcwdnsKdG9X4QP9hmZ07iC7Yed7htGkw9ZIhMWs2nCq/MBngtJhCHzXI5XC9exnrKG+Ng7ew8HdPac349mTJNge9n9arJfo3ZnTdVYfiTYGQC/so0SlEOlwmwHHsv40kxGURxmij5NGrelf/xEI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(261009223027099003)(261021135927099003)(261022075727099003)(261021121427099003)(261021123027099003)(261022105027099003)(10067099003)(56012099006)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/uM238C/wNqMAmIMjuGX5sE4uOtQwhgDENYlS/SpLEY40tPkEKIMbLq3rjJY?= =?us-ascii?Q?2/2K5WyywbjOcpeyMaRWrvtID0nheh2Xi7Y1GUbquDfCZKGscadH+bK7N7nh?= =?us-ascii?Q?lM+2cmeIrPhGEJToPvtHWRP/3nhw4dUt+1YplUOUCNzU6JsU+vSMPIs1+Ptw?= =?us-ascii?Q?StXF8+LLEt+dclYWqlYeEu8rMyxTP6Ic6z1e7NaWVomF5QY07NJsXJVIAQPG?= =?us-ascii?Q?ZYKpbUTIV+85f9SbaoiMzMwJznrGWkDely6HyIOSjl8x4KFDfd4nwXizia6Y?= =?us-ascii?Q?xSXk4jzOFCF05r/L0vve1cUT3WwGHrPZc+DPuOvXEhmDKTlbpmGoWpYmEyKw?= =?us-ascii?Q?I1VBYcaWeixlbBE+8KCyBUDIWhv/AweZzQW4mlJsjD+7udv9Lw3Aq6lCC1Hb?= =?us-ascii?Q?Y6lFmOsQxnG8ZkgDjulK0Dqnw8ccST2TYMbGyWVljVX9Wbw5glpP/47S0QkX?= =?us-ascii?Q?r1EZOVSdtylKbRm4wuyALdX1VJJdEPwEdoGGsCcW4eNFDUZAQkx8BL+7eMG9?= =?us-ascii?Q?5v9U7VZhEjnAE0ENpiIYxQEOKQSRm5Pt8KP/PXm69sN5Pce1BnMIECwDPDch?= =?us-ascii?Q?k1FlHZwIfdEco2xlMvNmbpQ64pMwllDKSQ4K2yW/ZsR9GcVlr6c6cIyie9sY?= =?us-ascii?Q?0YwvoLNbW3gOwq3BpBPdyqpYsDBiafp6x7V/z7GjBvTJ1jEeHzhgReXu8Orh?= =?us-ascii?Q?jtDOH7hKJrlLS50bpfkgAErRkxWHfOi2zYv7TdVdHoTi77Q/as6kFOhMfj4q?= =?us-ascii?Q?CrB7Yt7Sk0Z5MMGFJ0ufiTvPsQYtXdIuHIvFnyW/IXdcS/OrLRuFfHu8jYtL?= =?us-ascii?Q?RtSd2bFpgC0PtIg3stS2mEwt459vkt4IRT3Q/Nh06y4GOsPH4fhfeQSV5/w8?= =?us-ascii?Q?mU4iYz7ja6aL9cUk3QPiUwLzRtxK9MWSYwR1mqBr15U+l0RzvfSy18kKqigk?= =?us-ascii?Q?emqUD3272URojisEB6BAU1mp98nMfpdPmDyMkTDkPdFa1v1uWSInWcoT27dh?= =?us-ascii?Q?ZfVBCFZgXTLa8wxKIcbQqVe+RcB6skcOC53KFBNj3JOsDs22yTglgOFWjXL+?= =?us-ascii?Q?iv84YwNOK57bRHw7q76r/zwRNq1Oe60/Lc0JRWKTBO6qrzbCcK4nbbyRWw04?= =?us-ascii?Q?UXX+mAAkqln2kjqjrb8ZxKgpCCQkOk4wK18wx30/rJV5SvDK2qGfpF3HD/oS?= =?us-ascii?Q?TrdWB348m2V/plXlOSGDaQM3aKsrVzODxGH8qd8RxXFc9f6M8WJN/c38Epuw?= =?us-ascii?Q?BVTlkGnZbkzYwz0VAg9UNDF13ufw73s9roHyJsDte/aHIzXYO+kJCXG4TQUX?= =?us-ascii?Q?TS1m4Is5rYyLXmcLF7DhWDSsUU6MEQhxwW0YU4rEWt3aTrAZUvbO3JRCRnWU?= =?us-ascii?Q?IQOU6J4Rk+fj2BUj7IkDrfxX8Y6POtGxYS57GOXcVNZc5A6miytBa0B/Vr7k?= =?us-ascii?Q?YSpmHRR8dgyK3lgNjXIo7/8mVau7TiacMXwphOJjF7TSOCI61WtGcECObNYR?= =?us-ascii?Q?PE9r44LufBZcgMOuJ/aMze4WKatMcBC2w1xEBZUQrnvCVXn3laV29Z2+i6h0?= =?us-ascii?Q?yQeghuSmXjQfWw2hkP+iC1kv/fAH7ixh8M3b0/NIZFRyvBPWg3eyPdns9ueX?= =?us-ascii?Q?QZdN05ZMyTEgskY8mZsYgfRY+MfPGMP3EcIxRplOmN5f+0JiA7l96Rxeac6y?= =?us-ascii?Q?6fu1eHdtLgW1YwP9KI2GCc/btJyNE3nz2hKpfHwuN1brcLNNHDEbFrIZW4kK?= =?us-ascii?Q?/MredomqQw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4498ab00-f662-4c6a-51dd-08df33314748 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:18:05.5187 (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: Scu2GAfQh69sWJsUyXNIv4vTWInsQcJXzvK5pCcNX2ls6F7dduT4Q06ynoNs+ttmUx7tQxxHRElNIt5mmzs0EA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB989640 X-purgate-ID: tlsNG-c201ff/1792999090-732B32A1-001E9F28/0/0 X-purgate-type: clean X-purgate-size: 2120 From: Chunjie Zhu This series fixes several bugs found while running nested VMX guests (L1 Xen running an L2 guest) on top of Xen: - Patch 1: stop leaking L0's widened access bits into the EPT violation exit qualification reflected to L1. - Patch 2: implement the missing nhvm_hap_walk_L1_p2m2 hook on VMX; the NULL hook causes a #UD and host panic when L0 emulates an L2 access. - Patch 3: emulate L2 accesses that hit the APIC-access dummy page against L1's vLAPIC instead of mapping the page directly. - Patch 4: reflect EPT holes hit during L2 emulation to L1 as EPT violations rather than injecting a bogus #PF into L2. - Patch 5: load L2's EFER on VM entry and restore L1's on VM exit, so L2 neither sees L0's LME nor fails VM entry with invalid guest state. - Patch 6: invalidate EPT caches after flushing a nested p2m, to avoid L2 walking stale paging-structure caches into freed pages. - Patch 7: retry a nested page fault if the np2m changes while L1/L0 p2m are being walked without the np2m lock held. - Patch 8: fix several nested VPID problems. Chunjie Zhu (8): x86/nestedvmx: Preserve hardware access bits in reflected EPT violations x86/nestedvmx: Implement nhvm_hap_walk_L1_p2m2 x86/nestedvmx: Emulate L2 accesses to L1's LAPIC page x86/nestedvmx: Reflect EPT holes hit during L2 emulation to L1 x86/nestedvmx: Load L2's EFER on VM entry and restore L1's on VM exit x86/p2m: invalidate EPT caches after flushing a nested p2m x86/nestedhap: Retry nested page fault if the np2m changes during walk x86/vmx: Fix nested VPID handling xen/arch/x86/hvm/hvm.c | 6 ++ xen/arch/x86/hvm/vmx/vmx.c | 5 +- xen/arch/x86/hvm/vmx/vvmx.c | 110 ++++++++++++++++++++++-- xen/arch/x86/include/asm/hvm/vmx/vvmx.h | 11 ++- xen/arch/x86/mm/hap/nested_ept.c | 19 ++-- xen/arch/x86/mm/hap/nested_hap.c | 52 ++++++++++- xen/arch/x86/mm/p2m.c | 17 +++- 7 files changed, 200 insertions(+), 20 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:18:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:18:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460792.1671652 (Exim 4.92) (envelope-from ) id 1xLEyd-0004Ss-91; Mon, 26 Oct 2026 07:18:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460792.1671652; Mon, 26 Oct 2026 07:18: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 1xLEyd-0004Sl-6C; Mon, 26 Oct 2026 07:18:39 +0000 Received: by outflank-mailman (input) for mailman id 1460792; Mon, 26 Oct 2026 07:18:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEyb-0004Rq-RQ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:18:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEyb-00FZ2s-87 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:18:37 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefec2-e002-0a2a0a5209dd-0a2a4508b668-10 for ; Mon, 26 Oct 2026 08:18:37 +0100 Received: from [52.101.46.66] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefecb-f659-0a2a45080019-34652e425fda-3 for ; Mon, 26 Oct 2026 08:18:36 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by BL4PR03MB8107.namprd03.prod.outlook.com (2603:10b6:208:590::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:18:33 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:18: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=g3sh2B1qY6dVYDdvuUQN1Al4Szhw5h3seRh1CuYBbeOlq04/dy2Pd7QAWwmXX91BRX6ZVu2QypIuCXUcuG4ame3D4KWPqFIMJRPSUMDAqLc2ouPHdX5VhxM6ayZDDY7mRpxkMJHYlVM7vrX8CVtavPs7laB4s1/GOkE/qAnRTa5LumHxcfi/uEHx52980VWseuLV8sOy7ZLbd8GWpHWPHtSedfOYMqimPqAUJqFnq+lfhPAjYIbylsoTTyyLmgOytWsSFsnQrDpUfeY1rzuzwOyr366mMsxItYWqigfNlsULb7MBUFTtZ9+2d8kza9qt/sw4w6I2Xl54I//8sMRVUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5ZDuCpDYvdU7mV/NT2kdqpjM+lsi+Sd9ryo9lHvaES8=; b=bHHvg0GuxuOkX6wA1uBx4WVvoHxf0aPiwkU/Wv5gC0YrLuGeywnsNQ17vnU7PQKKeD/jaMAs4TUZUNHVVb78B0DfekdT51EWlMor7g/78dB7UHuQ5rtIy2S+Lg5DhwXf1PVEkN3dVjkVqt0ryRxcNVmkoGjPPgA/ZXbSjXqldeBDy0Ya4Iq77Srea6a6NifRZBvIjm4y4LJaXRCyvDJ6rBsdOIxuPzvj8lHqch72/QD0fCifxi9+d7xqw2S4yofReiWq1AoMaaBmzXwLa/IN0ENJctANNGcqIsyV1sJ6vzNDYYY4kIplHtPq2CB/gZqvDyV4LYo6oYU/N+DNZZuGcw== 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=5ZDuCpDYvdU7mV/NT2kdqpjM+lsi+Sd9ryo9lHvaES8=; b=nRf72hr3Z0WRue/iEBux5T6Xd/TATaFXAsVntPGuXCPmh/+5bsvBCVfQxDcYbXHKyADmQwHyH3rt6MrHUy6PEHjbrn/HCvYV4fXiuUY50p31+caFT4OwkkX5HXWFaJVOhmC5h9csUffzra1QB9iqQikrR2OMtdBurB+5wwGhCOM= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 3/8] x86/nestedvmx: Emulate L2 accesses to L1's LAPIC page Date: Mon, 26 Oct 2026 15:17:49 +0800 Message-Id: <5056987209476136839c156c97f8862aa585a6eb.1792997742.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0157.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:cd::14) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|BL4PR03MB8107:EE_ X-MS-Office365-Filtering-Correlation-Id: 02ba7e9c-3c66-4f29-806c-08df33315790 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|261009223027099003|261021121427099003|261022075727099003|261022105027099003|10067099003|56012099006|18002099003|22082099003|11063799006; X-Microsoft-Antispam-Message-Info: efaOh62da9jvXRLw/+SdgsduXOMICyMu72CFYqcFZ7+dQB0RKmUHZAIlpmzhK68y01LPVNY59w4yN5YT8l61pO4XtnxXxVlAtn6FDXQF3+zme1C+nU+WZ9+D03T8pIML1kgnIqmX7t+HMxgbGyDlrpYyuNC6s4BjJ6p33Gsf3rsw9Fzlg/LnjGXRpOemsg+15WpFV1bLjJFh1MaYxDi7TGfZYcaZvMTvKreMsPfAgV3V/g0q0os/dSetqlvNAIFglvodTssUNmjUSUe8L2ZpjCaUr586jufMPZJzvovJK2jvdXxYm0RGpMZOeOqH7aCfuRgA1x4xXewvHDrcIspu00fpLfkHMy6HH9uhxta8iRtOdr5zye0T+M0R/XWstWJ+8ZZixf2AspOKS/ExKBPGCX+vX9AdNZWViyVidh+hwTyc+UJIzx3A0WYmmKp96yb5AkBmrWgrJk3Hx+stylJVKnyaKIlI61cu3DKZRSPJMU9+hTiojyBSFFgTMwAOynDYIpK+J3L3IgSEuZZ9YgpeRZebL+3Cz5rO67DwaFHs4lN7d2gQXEI2yJLbaTOsRi1FEshguiFlMzvmkfpDKiUXCHbLHg12i/iEcYYiIDys7KY12xYksDuNvhYOIxHRN3r/5usmP/WcxbJPcVA3TWs3Te43MaL+Bq02ExXx/xWj3oU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(261009223027099003)(261021121427099003)(261022075727099003)(261022105027099003)(10067099003)(56012099006)(18002099003)(22082099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?x6mzLwvtPT1HXRGow6jbPH3e+CarreXC/lGaO3E2LbnLpMgD6//qgXP/Jn/G?= =?us-ascii?Q?Tq8Qn4AYI9NCvXikrxk/kka4cW/WlgHEU18d2dbZ1OA2NMGoLopdc5wZlmKK?= =?us-ascii?Q?qWAWum8G+Y+A4SmPWbLhUgzF1rqyms5KdT95pWIEyG4Wwf/GTvS/LFkXu0ko?= =?us-ascii?Q?b4Mc3HKDjEiCmr4vHha1WXvx+lKKh5bL8ornlsRc2dyM3qBYVIfucxKS+1qr?= =?us-ascii?Q?boIOL3hj2HsePqXs8Vc+hmHP720xiqZIMXASUMwg3m6ou8NdkQKZc2ILdF6W?= =?us-ascii?Q?T7WuLU94H0hauotf21Ds6+yPbGsn22qEjVc8pF4u9A1rz/JfFU41vN3dw6JE?= =?us-ascii?Q?JiIURk5zuSX9CUX40XHE5ZLzlKoSw3opfUcsuDGijt6SZsCs2sDnoQpgnwUJ?= =?us-ascii?Q?NZ+8LkYmAnpt0dH+eFmM5kEqOt0k2Z5iscexr8HdnKJHexDEcPt3I7gLV19I?= =?us-ascii?Q?bXr7NE5u7jy1Tn6POYR0DIbytXVZgd08eU020s1dvT9CoP1JBVHLlmpsSYCV?= =?us-ascii?Q?CYIsdn2ZxB7uPRp2mz9HhlLXMjXkePvEnoGL7gFD0Y+GtwuxZQF7ETQkK9Rw?= =?us-ascii?Q?NPzE96xuwJBzxvWWrNHSONKghhmhSvVh/rewBtJyim2KqrtB6bHobYeLHyJv?= =?us-ascii?Q?JPJZZFpZJTklZ4KUYKDK2jV0z/XkLbKxtYKQEt6fxNPoTuuueyoCZNLthjBR?= =?us-ascii?Q?LVRlZmljaGpQ4pqjSWMI0lxBLLfgLMu00BO5Lfou5y91bHc/maE5BoXnPk+S?= =?us-ascii?Q?aAtVkJSB3j36tihm9Hmu85lc6Nn1KBeZFZA+Vi9sEsKd31KmPXSNLGc0SYpV?= =?us-ascii?Q?Duef62E2lopDsCwcy/b/4atCVC9cWNXRZL1Ps0vvROKaUZRoQnCmNaSr2f2i?= =?us-ascii?Q?sV/ZuL992djAfci3dy+yOo5kbxTuOUa/pnuvRIFVcJcAU2fIYcmoZDjkeb/2?= =?us-ascii?Q?ZkoKARz1kGWQcZDKIXmv1FuSc+iXVn30RsID+0bwbIwo5OWhxbZq8t5w4ula?= =?us-ascii?Q?L/O276HSwuvCXR/G1KScm2MDZ+ZIGZbH5aN55qVUxpsxZkjZWsHQVFTUbBNz?= =?us-ascii?Q?Ciat019P2IvO/B6FcY1Q+LEynDLCXXG5UvHUWGIBZ2wROzmbXmB++r2tz6iw?= =?us-ascii?Q?BMcqWwwgvlhaKDeShRBDQ8/HIoNChokci6jSk0w/+ehzUaY7PdPi93ol0+co?= =?us-ascii?Q?a3vSQ8ZqbLorJEnuHjdp9ZyJY7SmqQa4obsDZ/3kvomxFlDn9tAIwJAR/CAn?= =?us-ascii?Q?+7sP6yA6Jm5eBw3lohmO4qzyZi21bTdC1s0npYrbGFvidgp4FRgKwno08cp2?= =?us-ascii?Q?MyYDpoTF3F1YsHllPmUApQ0fYrnE05aAgXFKyO9qJyWN2iSK7HHY8baK83/+?= =?us-ascii?Q?xYpppfbvhwZ8bQysxZbE3JtzZee7kyzYECJrpx6dzTIEy1/y65x7utkMOh+t?= =?us-ascii?Q?yul1Zkkt/YFat8xYWfBSHfm2o18mw+eBiALuoebiKGTGI95xReZxi/MiqxJT?= =?us-ascii?Q?LtnTWrmjOEnhz+4dRvSxuYiAVOjyh0YFBef339fq3GCe7Y6cv/YBin658UwK?= =?us-ascii?Q?VAerBypPSss7ffjhdXYMEPX39aJ4tGmyF6vvoPCk1hLXXy/C2NTGQyC6DxDi?= =?us-ascii?Q?LEWmbb2v6pB9e4lsjPw20ASyWEjQwc97goaHS3tJd/N+FUFmWKgz3jPeUgUz?= =?us-ascii?Q?0H1uUozue47W7oSQdZsxDEbUD7kd2zB2JWxmuD6gGsrazQVhlOFQ/QEGsDRa?= =?us-ascii?Q?4j1OS4gNjg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02ba7e9c-3c66-4f29-806c-08df33315790 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:18:32.9509 (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: cTBQaFqv0b3iMsYr1MxSBcCpHiSaEOb7wTgD4eB78EXpGb/k4yayN5Z5zzOBFpqI+fBaIxDozCdtgbMQVF5qHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8107 X-purgate-ID: tlsNG-c1860d/1792999117-D654487B-0134DAFD/0/0 X-purgate-type: clean X-purgate-size: 1474 From: Chunjie Zhu Return NESTEDHVM_PAGEFAULT_MMIO when the L0 p2m entry is the APIC-access page, so that the access faults and is emulated against L1's vLAPIC. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/hap/nested_hap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c index 42d588f08821..72706cebaedf 100644 --- a/xen/arch/x86/mm/hap/nested_hap.c +++ b/xen/arch/x86/mm/hap/nested_hap.c @@ -17,6 +17,7 @@ #include #include +#include #include "private.h" @@ -115,6 +116,17 @@ static int nestedhap_walk_L0_p2m( mfn = get_gfn_type_access(p2m, L1_gpa >> PAGE_SHIFT, p2mt, p2ma, 0, page_order); + /* + * With APIC-access virtualisation, Xen backs the LAPIC page of L1 with a + * dummy page. L2 must not touch it directly: the access is to L1's + * emulated LAPIC, so let the caller emulate it. + */ + rc = NESTEDHVM_PAGEFAULT_MMIO; + if ( *p2mt == p2m_mmio_direct && cpu_has_vmx && + !mfn_eq(p2m->domain->arch.hvm.vmx.apic_access_mfn, _mfn(0)) && + mfn_eq(mfn, p2m->domain->arch.hvm.vmx.apic_access_mfn) ) + goto out; + rc = NESTEDHVM_PAGEFAULT_DIRECT_MMIO; if ( *p2mt == p2m_mmio_direct ) goto direct_mmio_out; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:18:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:18:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460796.1671661 (Exim 4.92) (envelope-from ) id 1xLEym-0004wq-JQ; Mon, 26 Oct 2026 07:18:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460796.1671661; Mon, 26 Oct 2026 07:18: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 1xLEym-0004vm-EP; Mon, 26 Oct 2026 07:18:48 +0000 Received: by outflank-mailman (input) for mailman id 1460796; Mon, 26 Oct 2026 07:18:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEyk-0004pP-RB for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:18:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEyk-00FZ5v-7b for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:18:46 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefeca-8faa-0a2a0a5109dd-0a2a4502b5b0-42 for ; Mon, 26 Oct 2026 08:18:46 +0100 Received: from [40.107.201.50] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefed4-6ca4-0a2a45020019-286bc93271f9-3 for ; Mon, 26 Oct 2026 08:18:46 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by MN6PR03MB7549.namprd03.prod.outlook.com (2603:10b6:208:4ff::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:18:42 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:18: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=saGmxlO/jijHtQxfsdP0nnqaWw2U0j0xnwwZnjwtC+gzRkaz1r3Ja9fCey2cSwT79WuJnGYKi5DD0gcSJgqGzU1qWMia9F08jTko8aCdrKw+I0pLonkVlyMzIF6+yceuip/vffaNptCb5oLdO/NUvg4OkDqQmc520siHSWCq0sKHjn84dW6y4cGWoRIt5NED0GYTYkER5Vyk0Bz5VmjxEliYb/5QsZYGwLD1qeNTeYOx5Rfk+TSKHHteTEwf6clDh6/LVzspgewieyrySuFOXwtEpBOLXkppvhVH2nNJLD/4y8XmlROO4K1baQApDA9dmO5Z9L3SsXfKVRAJ8VezyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+Qm6MOAPPFM5h91qqxn9EYsE3cBuyr47YCYET4IV7cU=; b=d0wQ3QqQ5g/S7uMZf658oWfRYeUJSs7/vKWo4nTBgxQsxYYTGwQ0NXzS6j4yZaT8yFlqCuqHSmsZZGR/E9uFHU3CyolyDyVdRSKcRTeoFpuVR3Opm/JYsURpmcoa1TzMuKILIwr3mcdMkLnH0RaE5QuHZ+BPSTPBPACnbMK/mVkUEW5Wy33PoEf3nubMeFFQ22Z+HEHwGZzmlYuBkKSH4C9suV+01Sy9UMh6J7QgkslJK40gJKy44YnZ+7tNj4WsX4PM07c6HdhMg6Xhyo+lb6Tp5lIT2Cs7A7Sf510rgjWe/OoAbLa6gxfPwNsArFED808YeG6c1oSSMCQ8L+U/qw== 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=+Qm6MOAPPFM5h91qqxn9EYsE3cBuyr47YCYET4IV7cU=; b=ZuJSp850ft+NREVzdl4QUktV+cFJtK2NOlPu0+UQzXvCZ1AOkJ1lm8q3wBGxzVS5xnBFD1eOURjHmLbgXmp/VW/DARTpfDUF3iWUXpwwr0SIy2rGmaEcYrZlgbcJJ44mmUfYlHLrolysMkjFcj2jWRiAQvYOxA2nzs70a7ovRog= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 4/8] x86/nestedvmx: Reflect EPT holes hit during L2 emulation to L1 Date: Mon, 26 Oct 2026 15:17:50 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2PR04CA0212.apcprd04.prod.outlook.com (2603:1096:4:187::8) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|MN6PR03MB7549:EE_ X-MS-Office365-Filtering-Correlation-Id: 7aeb2e05-d079-49ea-4ad6-08df33315d1b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|11063799006|56012099006|261021121427099003|261021123027099003|261022105027099003|261022075727099003|261009223027099003|10067099003|18002099003|22082099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: ihXSyr5M3WE8fkRh9Ix9XOOj8ejOkei9Dl0wxB5Yrqh0HisvudE1Rrcy84S0vJDufkcDBA1WXA+ZjXBGQBhLVZhQeuF0i8POqme5vj3hURwAGsWsrcoLy/uCXX6CFjU/NSDn2E2gu6HQADQ7a6ZXJXPfF+KMM069QtMzNHYtX3gfR+JTpcVlZSUjjOCi9wuvWgIUN2m0L+hHw4mj9NbpbjOhSjWIxdozzzpAfdrKH9b6gPuvzHi02IRrd1IeePNsFFQoFP+pcUWpnvUAUIExN1HLq3j1V6LqWR+518m14bugPStrw1D12pR877QQn7tV9z8Z4kktCwFKy8+PsYz62LlBS0+e1AHx/YMgHiPm0mU+kmmOMPjf3gp/nEXEDJ92ofL8VIGkRk+TYiLmqG2FThZzIAPZXKeO/ixLnDwKWEO1eizdVgH6fqzKItR8H/5tQBGzRk3Pn9vh7gAwyyXzRsx5Unt01Ewrv+7uwXBtNYVVTftuvdiKXLCC89ncbvJKRBWY+rNbGjvA8RMwd1IThnl2BMot79lbPeizmoRC8Ju18NYEZXfvCHLVZ2g2+hHRYGIOHHMnl4GAQSHdHA6y3caySFDfixmmM+yJsMi6o9j/kMn6yozTTg5HMC3rG3NJVf6I7aIPJrB1JP8mgodi2CGnY7Dtvk04h4gsl+P2TFw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(11063799006)(56012099006)(261021121427099003)(261021123027099003)(261022105027099003)(261022075727099003)(261009223027099003)(10067099003)(18002099003)(22082099003)(6133799003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uyGE8AEcHqhFNwDBbn4si4A8WfzOSJ5TZBRKrxk6jIUQGy0QRGJRALZ3lRKy?= =?us-ascii?Q?jHysNMDZW4DLl7RO5ZSji2CSI/IQd6/QolXqCPn2MwbesAvib4hgqNSr780I?= =?us-ascii?Q?RYptBG//LVLktabTWMWvxUdq+XjeCZCqO8fi61TKJlWffsuGh/FL0Nbh1ca8?= =?us-ascii?Q?z3PeSP2BCGd7yBYMCewZ7mDYh2xAJw5HQtBGzCNMlnhMkCzOhoz/dSghLaxk?= =?us-ascii?Q?upywpdH15qsyr7E9euZ5ZbYy3Bjtpvvj01iIXXP4gwk6mbMXETi8Z3USt3KW?= =?us-ascii?Q?zV9gXSfafkzIZULodB7YgLDz+bbDG8extK5UWPZ2ONKClA8L+U4EWry8Zn96?= =?us-ascii?Q?mA+Elw9Vmb7nRbIkCJZjG1GJaVy821QWA4KkNhzM3fQXopGE6EXgCO573ilm?= =?us-ascii?Q?/UgUtYn3PpVeoO2ght/JZpmcEjs8IT+1BqeUgoGQSaT7kO+XoXyQb16qQKZL?= =?us-ascii?Q?nE0y9+g3O/6qHuHD86iLNPHBN7z8tNIT1L06BF21oNXjgQOSDdfJzl+Q2z8R?= =?us-ascii?Q?UCi91dsUITFblz+q2bSJG1iGGanl2+OiSOOBFgr/o+XrE5AvJvZ2YjczmD/u?= =?us-ascii?Q?CzBgyyZjBZIqtP+rPb3Sw6m4KWHogI4OFX7qCJKT2ForEYeLyWe5rJ2G5ZL2?= =?us-ascii?Q?9iXhNT4dT4cnDVfPf1ok1WHncWbPRII0j817ZKpx/yD7Cvic1LwqJ1/yTmT5?= =?us-ascii?Q?TKs2rUfkb53+mtQ014qdsdKN0MbgfFntkO1yeeEj5eUt7g5gs7JKTV+9BFWS?= =?us-ascii?Q?MCrW73r5JuNOPyiAZW9BDnAr5e6GJ/bZluXT2k++TM87vQuhc9st6ev/RyGw?= =?us-ascii?Q?lQfTi8ccMkPS26hnt8sZX0c9zSDOjOGWpMQC1Ymkgdmw8CbfAXuTnnQ+dQi9?= =?us-ascii?Q?fiO+DJ+vG6zbHEASdairQacj2qWSiXOAH8eMfE63sikiHstzkHUose+C1y7d?= =?us-ascii?Q?nkZMBfsKX+WFnPAZJp3pNURmbj0wSsXAcUy8qRnkiwg+q+QM//VZ49x4eEjR?= =?us-ascii?Q?wOSNTY+G7v5Dg3pHYl38u+zcelqkJ7m2cYjFS2V53H6gNUTausMIlSbOzssY?= =?us-ascii?Q?TukgRvUuITApLrOf16X/ONNAnLIqvJZBGy6s81/jhAnNPYKzesOyegA4F9R+?= =?us-ascii?Q?b/xhFDKrhio8vWQad6DravwsRyDx++zEhXtjKKmgKJAs2Jn0rVicqTeQOlmq?= =?us-ascii?Q?NyPBLkXp7HSpvjn/rUWJS6fU45FJE8JhPK905C5Bj/fCKlFPx8XLSg2iUheK?= =?us-ascii?Q?UjTitWaj+rjE5yuw8/A4IOQ9dJOKXJFlSTODyJIed4zjyvzZcQbDv0JHa6vj?= =?us-ascii?Q?R1yZrKP/wKmSyaCecuCMiEulFFJxXyulV1AGlqrK/QtB5B+XU5XQjuAGWkgR?= =?us-ascii?Q?oOE4m3kmGTDkmkEXnernyye4bI4+nL+trkk5kdnzMmFYJXC21FVk5bLThqmr?= =?us-ascii?Q?apsxJ6OgkuTOdL/mK4H+oIA5lSCDAO/Mc7hkgWGmMaIR4pnh7qQaj2IIJl9o?= =?us-ascii?Q?RK4ibYYa4gcGa0V5SwK6mIPgwWu7FUprvuscS26AoMFbE3Ic/jmMXYrKLIl2?= =?us-ascii?Q?jl8xiJh+V921c7IjhzCo+ngibDX6GI67KYx6nJodw96/RbxUnBsESc40LM7J?= =?us-ascii?Q?MeMEY2tFj8rCX+XKBwt9OmK35sWLUsjhm6nNW2sxxo4JL+CRhq5aMGECaaHN?= =?us-ascii?Q?aztFWuu6IgeC6r2xSuTJB7D7qXz1LniVJWvHs5dy+806088oWOkWtOKCjgvX?= =?us-ascii?Q?3G0YkVGAxg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7aeb2e05-d079-49ea-4ad6-08df33315d1b X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:18:42.1032 (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: LeMCafmupSBSrLGO27tCtWC2tT+4uD4zHkn3JkPvRAzSdrJjOdb27/uyF+XfFKOgP+j4ubsiBT1rWr5OSvSCKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7549 X-purgate-ID: tlsNG-720697/1792999126-30FCE2AC-BB5D2974/0/0 X-purgate-type: clean X-purgate-size: 5932 From: Chunjie Zhu When L0 emulates an L2 instruction, e.g. a `movs` from MMIO, it translates the other operand with paging_gva_to_gfn(). For an n2 vCPU this walks L2's pagetables and then L1's EPT. If L1's EPT has no mapping for the resulting L2 GPA, the walk returns NESTEDHVM_PAGEFAULT_INJECT and paging_gva_to_gfn() returns INVALID_GFN. The emulator then injects #PF into L2, although L2's own pagetables map the address. L2 is blamed for a fault that is L1's to handle. Reflect the hole to L1 as an EPT violation instead: * paging_gva_to_gfn() calls nvmx_reflect_emul_ept_violation() on INJECT. If the current L2 exit is an EPT violation, it records the missing GPA and sets nv_vmexit_pending. * sync_vvmcs_ro() reports that GPA to L1 as the guest-physical address of the violation, together with the exit qualification computed by the L1 EPT walk. * hvm_inject_event() drops events for L2 while a virtual vmexit to L1 is pending, so the emulator's #PF does not stay in vmcs02. L1 can then fix its EPT and resume L2, which re-executes the instruction. Signed-off-by: Chunjie Zhu Assisted-by: Claude:claude-sonnet-5 --- xen/arch/x86/hvm/hvm.c | 6 +++++ xen/arch/x86/hvm/vmx/vvmx.c | 30 +++++++++++++++++++++++++ xen/arch/x86/include/asm/hvm/vmx/vvmx.h | 4 ++++ xen/arch/x86/mm/p2m.c | 6 ++++- 4 files changed, 45 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index ef9c7cd05777..b38f8dd68733 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1801,6 +1801,12 @@ void hvm_inject_event(const struct x86_event *event) } } + /* L2 is about to exit to L1; an event for L2 would only be lost. */ + if ( nestedhvm_enabled(curr->domain) && + nestedhvm_vcpu_in_guestmode(curr) && + vcpu_nestedhvm(curr).nv_vmexit_pending ) + return; + alternative_vcall(hvm_funcs.inject_event, event); } diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 8d6e0c66f38e..dc8bcbeea033 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1290,7 +1290,12 @@ static void sync_vvmcs_ro(struct vcpu *v) { set_vvmcs(v, EXIT_QUALIFICATION, nvmx->ept.exit_qual); set_vvmcs(v, VM_EXIT_REASON, nvmx->ept.exit_reason); + + if ( nvmx->ept.gpa_valid ) + set_vvmcs(v, GUEST_PHYSICAL_ADDRESS, nvmx->ept.gpa); } + + nvmx->ept.gpa_valid = false; } static void load_vvmcs_host_state(struct vcpu *v) @@ -2384,6 +2389,31 @@ int cf_check nvmx_hap_walk_L1_p2m( return rc; } +/* + * L0 is emulating an L2 instruction triggered by an EPT violation, and L1's + * EPT has a hole for another address the instruction accesses. Report that + * hole to L1 as the EPT violation, instead of blaming L2 with a #PF. Called + * after nvmx_hap_walk_L1_p2m() returned NESTEDHVM_PAGEFAULT_INJECT. + */ +bool nvmx_reflect_emul_ept_violation(struct vcpu *v, paddr_t L2_gpa) +{ + struct nestedvmx *nvmx = &vcpu_2_nvmx(v); + unsigned long reason; + + if ( v != current || !nestedhvm_vcpu_in_guestmode(v) ) + return false; + + __vmread(VM_EXIT_REASON, &reason); + if ( (uint16_t)reason != EXIT_REASON_EPT_VIOLATION ) + return false; + + nvmx->ept.gpa = L2_gpa; + nvmx->ept.gpa_valid = true; + vcpu_nestedhvm(v).nv_vmexit_pending = 1; + + return true; +} + /* * As nvmx_hap_walk_L1_p2m(), for a walk of a specific nested p2m that is not * tied to a VM exit (e.g. L0 emulation reading L2's pagetables). There is diff --git a/xen/arch/x86/include/asm/hvm/vmx/vvmx.h b/xen/arch/x86/include/asm/hvm/vmx/vvmx.h index 2e0ac5798d5d..92c8a8144527 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vvmx.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vvmx.h @@ -38,6 +38,9 @@ struct nestedvmx { bool enabled; uint32_t exit_reason; uint32_t exit_qual; + /* Violation raised by L0's emulation, not by the L2 access itself */ + bool gpa_valid; + paddr_t gpa; } ept; uint32_t guest_vpid; struct list_head launched_list; @@ -94,6 +97,7 @@ struct p2m_domain; int cf_check nvmx_hap_walk_L1_p2m( struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa, unsigned int *page_order, uint8_t *p2m_acc, struct npfec npfec); +bool nvmx_reflect_emul_ept_violation(struct vcpu *v, paddr_t L2_gpa); int cf_check nvmx_hap_walk_L1_p2m2( struct p2m_domain *nested_p2m, paddr_t L2_gpa, paddr_t *L1_gpa, unsigned int *page_order, uint8_t *p2m_acc, struct npfec npfec); diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 61b2d3fbd4df..ae13d36fdab7 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -25,6 +25,8 @@ #include #include #include +#include +#include #include #include #include @@ -1675,7 +1677,7 @@ unsigned long paging_gva_to_gfn(struct vcpu *v, .write_access = *pfec & PFEC_write_access, .insn_fetch = *pfec & PFEC_insn_fetch, }; - int rv; + int rv = NESTEDHVM_PAGEFAULT_DONE; uint64_t base, gen; /* translate l2 guest va into l2 guest gfn */ @@ -1700,6 +1702,8 @@ unsigned long paging_gva_to_gfn(struct vcpu *v, { if ( base != p2m->np2m_base || gen != p2m->np2m_generation ) goto again; + if ( rv == NESTEDHVM_PAGEFAULT_INJECT && cpu_has_vmx ) + nvmx_reflect_emul_ept_violation(v, pfn_to_paddr(l2_gfn)); return gfn_x(INVALID_GFN); } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:19:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:19:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460811.1671669 (Exim 4.92) (envelope-from ) id 1xLEz2-0005dj-TQ; Mon, 26 Oct 2026 07:19:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460811.1671669; Mon, 26 Oct 2026 07: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 1xLEz2-0005dX-QR; Mon, 26 Oct 2026 07:19:04 +0000 Received: by outflank-mailman (input) for mailman id 1460811; Mon, 26 Oct 2026 07:19:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEz1-0005c9-I2 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:19:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEz0-003MoA-V8 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:19:02 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefeca-e002-0a2a0a5209dd-0a2a4507cc14-48 for ; Mon, 26 Oct 2026 08:19:02 +0100 Received: from [40.93.194.7] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefee5-b4ea-0a2a45070019-285dc20798f2-3 for ; Mon, 26 Oct 2026 08:19:02 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by LV3PR03MB7586.namprd03.prod.outlook.com (2603:10b6:408:286::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.21; Mon, 26 Oct 2026 07:18:59 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:18: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=A8Bnc+2Gk4aQreutl8m8oIcOUiHcId4Y2w9jxQ8/aMLN7218DWDieXqkLZA0dUuucmNvrfvS3jvEd77LoS/cPvmTV994LBwDv5EQjzTE65OYoyBPHm1bgUC1FJxy30j2e3AL7ty+mfLMWdFgTsxmgcpA+5hmQH1n655YRS9SIsgHC1FcEo3Lrvj4BuThR53IalSMm3sA2NRMfpH5+FVTT7+etDIbAs/kSYQoFWwFrOQbsX2BuVF8uokIfQF0H0644cC6c1NwDf1JrtQetkZsuo0wdp+eobQ0pdeIdfCCGGjmNmFlJGnCeuO8WoQF1sY2HHVteHhyb7PWkXEad1oUCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4Rjw15GNe9uAxxOV8gF02IelZ4k42KeUNkkvV94GvCw=; b=ZLH3Fz1BAuVuubniLB5GyDMm9P/Y1TtBVgGdQpr9j9i3/k+Ng2sbU46zq7H5rdYZOFnix4bOAWtGaJNXcJlCOV3j/HDwXcTm+V7HkOSwM99gb/Ff3HoGdllGMuxYQP7c1PiqgaCZq5PFC5JOVrhk7SWmPS9JKmO04o7F31Y4TyyDOjoEtGquVMolA0tgaYUQzAqJnntF7AH46zoKi7wkaaga7bRRUMo+oMXCYa8tjXJ8SL6aMNpJOHDSakQsP+S1UhHkxzGZ2LUxQF5E83cg+nOXxhHYhnK3Uy5W4U82zuAZ6lRQgcUVzbu7NNT9LC9G6THFLgG2eNhb4aLsCeZTZQ== 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=4Rjw15GNe9uAxxOV8gF02IelZ4k42KeUNkkvV94GvCw=; b=JD2+clawBQswBrKlqhGgZJTRmssYPDCDsBdMXB/NYJbCy+zMtsRpJKHlxXve7kU3oYNFAehgpqv/NKI2c7aq8oJyLvOdyEc1tikzcDcOLNtfD2up6jfR1JGXqJ8dYHSl0OATtU00rdroYm56eYvNmnA2/HhIj6Q8qOL3wrSIEHA= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 6/8] x86/p2m: invalidate EPT caches after flushing a nested p2m Date: Mon, 26 Oct 2026 15:17:52 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JH0PR01CA0091.apcprd01.prod.exchangelabs.com (2603:1096:990:58::11) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|LV3PR03MB7586:EE_ X-MS-Office365-Filtering-Correlation-Id: 0b47141a-728f-4f34-9d36-08df33316730 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|22082099003|18002099003|6133799003|56012099006|10067099003|11063799006|261021121427099003|261022105027099003; X-Microsoft-Antispam-Message-Info: NIna8I5h6J8WX0+oyZwoVhUaNurl3pgkv6qHRBKWE+MlU2klVv8p5JfSsYdLp9kMK7udrfrVMg/04cnQBUnZ7JVL7s+OwK3dJHhk/PTknQeCGxnVdsUhNOZCr21eWosNEkhmZoOqS90oowZ3gtnBrfH405qwdDJlIvFEHlBfgN1CAjRdUVfhVeUtZ3KWJniBYLIChqVB4O+peJohR7y0n67JgfDc6iF8EuBlh5iHJ9eksOIhxhd3xgeKROFzRi+7QzbvJX1ZeSKEuUbkU02Iwk1M/d0SUpGRxVzJqZbSKvn5ilAaVMlLfRlzpxMHQaCTlOyq95FLQFd8boRyMmwIbX9ElzlFVJuOukfjZPvLsGWEXndC4/IvgA7VKxYAkWX1ylaFycWf0kJGMM6Wl6bwJgWpFmD9hc/LB4wvyYMjwTvbl1moSFHmNBX+0H8PrAAL/736whzTuFMSpGyfposSnmHKpGl1sqA7znKTHCScrDGLj8Y6/f75i9nFPFQHAOomMGeK+tYH1b/2Xl2XwehvW8d8HO4dISrRBhZ3hCGCpVvCdlFSh1Qb/FCyFdpqTNOMo1OjJtOoWo96mQG481akC32wq/49sQI0b2fGoED6+4volHVsbS3JtcsXe91hmpGTdzXdzCGmgOldms+tkmWfdKzENefRhVq2jdNCieRcLKk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(22082099003)(18002099003)(6133799003)(56012099006)(10067099003)(11063799006)(261021121427099003)(261022105027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OIVvLlu9/06B5z6i4d6nxakGrWm/7tUI3x+CA4ZObd/dlhTHnyQYPhgr5ZDf?= =?us-ascii?Q?soTNHuSsQVgtyW6IXIjkxoNhs9qqVrTgejQWKuRIFJ3XZlOlThtwLYa7h/M0?= =?us-ascii?Q?SctzBz2zHUaMg1X8WiQQfkiq2mHouTwKf+waNlNxcu/6ytkfaMVNlCCPCquQ?= =?us-ascii?Q?D/TmwIPG9MU0JpwG6vPCQNdRGMrzkjNNDVj4NlDgxDLafuDaHUmTrV1JSgRa?= =?us-ascii?Q?lhsUJVk64qx/qr9fjkyioWVtNp0C5JMYuvUfaBDng+alKSua5WP4j80pY929?= =?us-ascii?Q?JKvqW57kFR7kHOpXR3AlxWwG/B5AzkIO1kwhvuiJwboLUORTlLKeB+mI6Ph1?= =?us-ascii?Q?4NDdGNN1qyvuj6hFUwVVLQLjy3JDU/zYjoVOREpNthZp4u5t3bVPQHEBr2xm?= =?us-ascii?Q?YoTMahk27Gz9Adu/AqrwSt70x167Q7ciL4ZH43GaNjmL14GLMxJ+Z6hARi7d?= =?us-ascii?Q?yZ6QqGXPxdEO6Dqj4OOwxdmnnOXvAAXyMtJYGySJQ6qsb7HAjCZV4FFZDOTI?= =?us-ascii?Q?fcE9eMqoMcDGVQc3xUPuDtnw5sNA7g+qLSS2xJput+eSS7TgsjtsXB8oAFGn?= =?us-ascii?Q?h+xOyeoTX/qz585855+BE+Mg5gylO1dQOM7b8IZ3xm4R3LwB3Z19GudNAdWT?= =?us-ascii?Q?lCrpu2exG2tJo4HhJYa4vm06uFG0WcdoX9B1LKEhafRSXTFzCNvjlFkStn6R?= =?us-ascii?Q?j9TYzbQ4auLrcQQjPfbsjRQsJCydFyk1RmAmihbklsUt3u/p5ABzdGGVMVSN?= =?us-ascii?Q?wLqze30BVjRSBjjUlDxd5Pd4Tw/CiJXds/WSDsjP6kUGgEnMCEM1nAaivyP+?= =?us-ascii?Q?0OPyFVB6qDjLW1M45tR3sCHCR1bJqx40mjixSMx3qPNZ2681bCiYJl76Q/gg?= =?us-ascii?Q?FE53Tff3qIBEYVQDfZWPy37DUSiuQ52wXf2atGt8Yjebfgi0K5BF0Hmj5VDA?= =?us-ascii?Q?tmkECZOKzruKWtfBagHfTXzo+vLoclv+1RqVYmoDFVv/vWAEJjRtwUIHCCyU?= =?us-ascii?Q?mbGkeH2WomSn67kb09YsqRMnZ5KNYGKzBMa7e4OP+wLyEFO2YHRdDAns4YE/?= =?us-ascii?Q?BEAYHcYgVhb0ExeEKnoaTWbHtqNW0aDf5Us5G3Unbm3IYxDy6EcM8mAh1FE3?= =?us-ascii?Q?P1WsIHwr0lR9aVgg5KiPGhOnSI+x+Gm9ANmQVyhFFz6nNJSVJTqZnViEwNu6?= =?us-ascii?Q?g+4dlIzhCOLLSmHoQY58+z8GrpinkMjmDXtBtTpLyX3NxW9RFAEdM++CFgEq?= =?us-ascii?Q?2DrcQm74vWTlUctT8SLPstxGA/7EBBJjwJ+nJyAUIUdvakb1faQJ67C+hT3L?= =?us-ascii?Q?ClxQ+nOHwrINII7xjOZ2/dRSWIGLq8Dn3xr/JXgSa4gSC1048DKL8MhjHT2I?= =?us-ascii?Q?viA8eq/12yK5hNeXNvi8YGjV7da5h0vYyV7AjMq/hWQBHF2h0QRMhG0GtFK3?= =?us-ascii?Q?DCxUjUdSgpLeilHSqn5vuv8tmqVglKmypAdl/5xUGF8pdUnBE1xBCGD0AePp?= =?us-ascii?Q?OC+Es+ImUk8dfrTue8N5xay1XbNyzrrdnOMdIbcMnOedPflduGjGyqAVB6mq?= =?us-ascii?Q?XQ9qcoXYQ1zbDlM5fcuZ/hm3y5Bw+KfYZSEQe+Y/187nLMn4mRj3+7JAsmxW?= =?us-ascii?Q?jg8JnAJclPzbgRZEzJc5TPiYGCihoIpU7WssUdhbBE7nRKt7QzW+nnjGDKfM?= =?us-ascii?Q?oVTEXrQozVM3C7gU83HnYParSxk30BKeotWhIEZ26z3SzhUet5t/PkBnb6aR?= =?us-ascii?Q?ADQx/kCdsA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b47141a-728f-4f34-9d36-08df33316730 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:18:59.0294 (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: m0KX0fN6UBz1/L+1W8tJRZJyH4zywJtxraktVkL399foRz1kqctDrhfD62Vqc0DY+dvFmlf59nk+KwUviYpa3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7586 X-purgate-ID: tlsNG-ef75cf/1792999142-346CAAE4-1FBE3EB4/0/0 X-purgate-type: clean X-purgate-size: 2390 From: Chunjie Zhu p2m_flush_table_locked() keeps the np2m root page, so the EP4TA is unchanged, clears it, and returns the remaining page-table pages to the paging pool. The only invalidation it triggers is nestedhvm_vmcx_flushtlb(), whose IPI handler does hvm_asid_flush_core() and drops the cached nv_p2m. That only flushes VPID/ASID-tagged translations. EPT paging-structure caches and guest-physical mappings are tagged by EP4TA and survive. After the flush they can still point at the freed np2m pages. vmx_vmenter_helper() issues INVEPT only if the CPU is set in hostp2m->ept.invalidate. ept_sync_domain_prepare() sets that mask only when an already-present host p2m entry changes. Nested flushes (L1 INVEPT, np2m LRU recycle, p2m_flush()) never set it. Filling non-present np2m entries afterwards doesn't set it either. Once those freed pages are reused, or scrubbed (0xc2 pattern on debug builds), L2 walks through stale cached pointers and can fetch or read garbage. In practice this showed up as L2 guests executing 0xc2c2c2c2. Mark every CPU in the host p2m's ept.invalidate mask at the end of p2m_flush_table_locked(), so each CPU does an INVEPT on its next VM entry. The cost is paid only when a flush actually happens. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/p2m.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index ae13d36fdab7..fbaa69d4f43f 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1446,6 +1446,17 @@ p2m_flush_table_locked(struct p2m_domain *p2m) d->arch.paging.free_page(d, pg); } page_list_add(top, &p2m->pages); + + /* + * The root page is kept (so the EP4TA is unchanged) and the other tables + * are freed for reuse, but INVVPID/ASID flushes don't cover the EPT + * paging-structure caches or guest-physical mappings, which are tagged by + * EP4TA. Without an INVEPT, a walk can follow a cached pointer into a + * freed (possibly reused or scrubbed) table. vmx_vmenter_helper() does + * the INVEPT on every pCPU's next VM entry. + */ + if ( cpu_has_vmx && nestedhvm_enabled(d) ) + cpumask_setall(p2m_get_hostp2m(d)->ept.invalidate); } /* Reset this p2m table to be empty */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:19:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:19:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460815.1671679 (Exim 4.92) (envelope-from ) id 1xLEzE-00063H-5L; Mon, 26 Oct 2026 07:19:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460815.1671679; Mon, 26 Oct 2026 07:19: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 1xLEzE-000638-2R; Mon, 26 Oct 2026 07:19:16 +0000 Received: by outflank-mailman (input) for mailman id 1460815; Mon, 26 Oct 2026 07:19:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEzD-00062U-Az for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:19:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEzC-004ZqH-OC for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:19:14 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefede-bab6-0a2a0a5309dd-0a2a4505d366-46 for ; Mon, 26 Oct 2026 08:19:14 +0100 Received: from [52.101.56.35] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefef1-4cb1-0a2a45050019-346538231dc8-3 for ; Mon, 26 Oct 2026 08:19:14 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by MN6PR03MB7549.namprd03.prod.outlook.com (2603:10b6:208:4ff::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:19:12 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:19: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=rUoHRlCOb5Sr91iXFQj86sS+cWB3kRfAFdu/ptlvgqgwwA03f5AtLWuFhOmVT5TDVFtsg2Uki35CpSsPslVaaLDmmupDFly0SoBYw3HOrEmj1IiNe81K7YOf47cY214ICJjzaxnVZv6gDpgtytNplgycDin3cluQpjQlpaJ9EY1Se9d1WMye6cuM7fyarY/Gv8+XSbeY9mSHpGISgr5ptQp2b0u/UP2BQQCnVQBSoYQ1rvTIOHv+WavMY41kUZnvpWZZI874/K7p0hTqFkcTHQtFp58kSxAe7hu67o4a6ORLUn6o+dp+pfVKwW7gFUPN8wcO6c8eNYm45hiwc61K7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Khj/KRTU4lyxeIU4dIXAw6vp1YA31vzVRgbSAA0KGDo=; b=g8uFdyddl6wEzZahZK7lcDsewCzEQqgFLW1Z99fwXKN0go69qnOFau86TFX0ef+VU7GtRbuS4Q+ngkRoYDouRskCf7fCrGAU+UaAnkB87S5WHRvGIMjRZDJpavQLAd7RzcDFXnGT64Gztwq4PwDFBZE8ynnqIAWzgw8zHLKkqo3UI0qX+yFQzLMLzSETdXnZkPfBHKZbH0gv+uPDN4Qxgvoji8DWkoEgM6lx4HAbpzqBrDyVpl5xTI8sWhXYmM9EUoO3+cmYlrHW8zy91xxWPTVBUfX4iMrLRUs7XDSUmWQQ6UBkINwVKZx61/4+bCoKWh86j/xLn66ok3XGs+warg== 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=Khj/KRTU4lyxeIU4dIXAw6vp1YA31vzVRgbSAA0KGDo=; b=fh0bkxozFDK6ycdxXohsjV5AxjNfj013faIelb59hiKznWcFzOfVB0YeD1RltIrs7sBBNKdGwKHhqigd74V7vDLHgcRm4KLhgrghIRZXpRJo734uuo8KcplwwmgGREIC3ey9qvObnGhkPJUpl2ViEEPLMDar4uM/9eLAZ+Ljl40= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 7/8] x86/nestedhap: Retry nested page fault if the np2m changes during walk Date: Mon, 26 Oct 2026 15:17:53 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0044.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:ca::18) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|MN6PR03MB7549:EE_ X-MS-Office365-Filtering-Correlation-Id: 0de06610-90ea-475d-5f9f-08df33316ef7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|11063799006|56012099006|261021121427099003|261021123027099003|261022105027099003|261022075727099003|261009223027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: CmEy4ldlJ8ky4VZtDq2QwGQPxPDME7pdmmujSljwoEcCPh6fOD35C1NEULLaO2g8p0nMKIHEZn9RICpgJQ+iiU0i40xY+fbtMzuGhYe//F5/6J417SACPc1kMqFX5WuI26S9QTeZWD0YVdI3dDNnx4e08MSdTEEyaCRDCxgWjsDjZjitGuunF5Cw5uP9Ig6J5gx64fH1EKOZWMQ4FqFrCSqfIj6cedk/QbPzIWiXJaQ5v5L0h5BHzl5ysMek64FL9LwuW4Gi6P/whzP9FvtejJlttHHrWmGF/YL455SkGRsbM5WdaS/JRXmzoCS+coA+wDnn3wYY9ecj+hC9BTMCtXMG/lE5QiZVnK8LAU7/+tqC4/AjXMev5L7rzWl0Pi8ze7qpw6N9ftAGOBfZ8a8Uz6HM0QnkBlyte6U03pNJOZ7ntZEvGXmW7tsGMZ4kaVhjKbeWOGZIreqG3mWHpDS0RzvdR20rpq7dG52qCifIHk/XcWSrCuRK4KkPNJsR9o5qaT6XS6kk9X3CJbsC5ZCTowXxUTDSXo5AZCGEbJWnQY+QskN9MCj4XmSDIVKwv8hd0NH70mXgf5cER8CZL+g8A7CTUNwSo5DbuWJx0mL7+dUgC70eqehMEVH5hCQwiPHxACqbh21sjLHfDoJN2OS4yCbIc7YemZPHh7TJUdI8u7A= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(11063799006)(56012099006)(261021121427099003)(261021123027099003)(261022105027099003)(261022075727099003)(261009223027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ywDPY/dd6GUTordgNIppKKJwtG2KkSn1e6wd/fBND8z4s/Ib1wp6D4Jg5ANn?= =?us-ascii?Q?uJ+7fQwzujyLYoSJlIFOHtmCQi2y7TFMwp4UwTurKN4pu6BCJKPCk/vlO2tF?= =?us-ascii?Q?18lm1szpJz49hu9Vk8hKqVmLe3sl5Jp74NBUFU1k4HehWvCWFIGtIE3MpcQY?= =?us-ascii?Q?GX9Tno7j1oNvL7ZkKQ5AnHBmc00eVohGLDR0Du+mj71vf3VUIWpY2fuc9HDi?= =?us-ascii?Q?OudAM/oCOoAHHVMTWgYywUXkUIsJrmnm8GCP3yTixfO7GBHTr7Mx0drEA3aB?= =?us-ascii?Q?kCRhuHKv6nzIEsRlhX3oJIJdqSg/xRQpUgmQhW2cgSVuuUag9RFk9YpA3Nml?= =?us-ascii?Q?3peI85vf41PJEk6ezlQdxQEExJz0IpNro6agrCzwp2z5n8vR8YCnONEmp92g?= =?us-ascii?Q?LbXfdURvSbDaEQ+q8TB7X3m69HGFNSAu4mX2rIhaoUl7aMEvTaAg1zI6cXyN?= =?us-ascii?Q?CefT+4jF/gzfu1GU0kUZCuALj6HJ9g98ipDJCufUy9ft7xVw0lVyfgzNuXEL?= =?us-ascii?Q?ehWC0sqqSkCi5hCB7Y8r9bFl0AwIgN0oJmns7Pa6LETERbLmdK6vcd9OXf08?= =?us-ascii?Q?k581Mdkh9p0iythGNJCoTNJvebugR0rMZ6xPXiM7S6xAkJ70U08iIXGDdDWK?= =?us-ascii?Q?zvcmXiDHiGNfp05njWkDGvMT8ppYIud6dXcgVB+lt9+MbCMBqbIyszxrVvFM?= =?us-ascii?Q?MZ+fVsBBFumJjP8UP3hCzyg5NPdjJxG7IQyTK6jZAkLmPFxLn8I1MzYvdzvm?= =?us-ascii?Q?apIqwJrDA7p2FxCaTOGlF8ICwIBMjBVZEJ/ItsGpJ2VB2JckfzeHbUI/x5Sg?= =?us-ascii?Q?HUWuoKyHHU83Vwc/2D1/nmGaTD9SNb1R1bYvM0ECyQblyKXtw6tNLXkM5IaP?= =?us-ascii?Q?iSjjC5OtXuQuCc4i1zfzXT8yxCJT4s6wqXAylzhGe4CYAdRUcUZVcT7q6mX3?= =?us-ascii?Q?d5SWmJiN27B8wIczd1OdKKsTpgQUrl/73BtNxXsjzh8TgmP3AqFFdBD3rHqW?= =?us-ascii?Q?rogB7ScWMLD1pAEcHaDsysvgwxmp3TNPRNj+HPHbFu4+Vwl6HUA/XTlNgCXc?= =?us-ascii?Q?Z6AUnHbersHRaN1g++ECipuqy+wHDnbfBaIvAFMGnNQMxcJPaPsOXmAs9Mcr?= =?us-ascii?Q?h5Gby420pf3LM7rcxKz2eFoFGOpUNBR7pM1mDBEbawkoftR5/wzg5ptGgzJN?= =?us-ascii?Q?k8cLMDmdbvxXg7SgWVQOonYV6gtkjA7wNUk0AP8ugXWqScT4ibgVc1NSnEbH?= =?us-ascii?Q?lJFxvHGYQwpXOruiTmymmIgpp/Q7sbcjBbiz4Zhzb1isCo4yKvE1Iee/Sb9t?= =?us-ascii?Q?43d0UsEztOJrzJ4rqLYXtoYspR8+2F08llyJvaBR0CueXobsDQG6ueeX8Icf?= =?us-ascii?Q?5DpjHWvUyM43F196R4azPPEsj34i2LqrxttQT1GxjWKANtugzzSri8OIXW1S?= =?us-ascii?Q?UQeWUM1X1Qz+RzuDzsCGxcgsr/7+cCgzDVPighOBosTGHt1isIFL0qI+MUgz?= =?us-ascii?Q?OBNvOgiuotk21JCYrHfm5liwo+0hM1a54w1cTqsSi3eeUdatKfwcORuXqwF+?= =?us-ascii?Q?3euSmXh9XdVannNVW+TF2B78CDqTSySKQlTkkW1dYdQDT/3V4fE1a2A+Yj8D?= =?us-ascii?Q?GisMRvOdhEci6t1/F69U7vzWBQqaN1uOyxFtMqAErAcvq/xtSDWiRdEgIkES?= =?us-ascii?Q?KoP3KHQJDmW02oNz+FXn0mmenOKYmGRGz65CSlJ94Q15hC0mDkZktrGSrqzG?= =?us-ascii?Q?9m4CVXlxgA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0de06610-90ea-475d-5f9f-08df33316ef7 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:19:12.3306 (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: vEpZdbV+YXNr9uWKHUDIwbRMe4A69dQ7edDKOj6fjLrYcH+7hVwSN0gSz3k/ZTy9g74bwmT1q0GHi/VkGc26Qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7549 X-purgate-ID: tlsNG-c201ff/1792999154-714AC2A1-29E04ADE/0/0 X-purgate-type: clean X-purgate-size: 3953 From: Chunjie Zhu nestedhvm_hap_nested_page_fault() walks the L1 and L0 p2m tables without holding the nested p2m lock, and only afterwards looks up the np2m with p2m_get_nestedp2m_locked() to install the result. If L1 changes its EPT/NPT base or the np2m is flushed or reassigned during the walk (np2m_base / np2m_generation change), the translation computed from the old tables may be installed into a np2m that now represents a different L2 address space, leaving a stale or wrong mapping. Snapshot np2m_base and np2m_generation before the walk, and re-check them after each walk step (L1 and L0) via the new nestedhap_np2m_changed() helper. Re-check them again, together with the np2m identity, once the np2m lock is retaken for nestedhap_fix_p2m(). On any mismatch, drop the lock and retry the whole fault from the start. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/hap/nested_hap.c | 40 +++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c index 72706cebaedf..1f09c706dda5 100644 --- a/xen/arch/x86/mm/hap/nested_hap.c +++ b/xen/arch/x86/mm/hap/nested_hap.c @@ -101,6 +101,19 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m, } } +static bool nestedhap_np2m_changed(struct p2m_domain *p2m, + uint64_t base, uint64_t generation) +{ + bool changed; + + p2m_lock(p2m); + changed = p2m->np2m_base != base || + p2m->np2m_generation != generation; + p2m_unlock(p2m); + + return changed; +} + /* This function uses L1_gpa to walk the P2M table in L0 hypervisor. If the * walk is successful, the translated value is returned in L0_gpa. The return * value tells the upper level what to do. @@ -176,16 +189,26 @@ int nestedhvm_hap_nested_page_fault( p2m_type_t p2mt_10; p2m_access_t p2ma_10 = p2m_access_rwx; uint8_t p2ma_21 = p2m_access_rwx; + uint64_t np2m_base, np2m_generation; if ( *L2_gpa >> v->domain->arch.cpuid->extd.maxphysaddr ) return NESTEDHVM_PAGEFAULT_INJECT; p2m = p2m_get_hostp2m(d); /* L0 p2m */ + retry: + nested_p2m = p2m_get_nestedp2m_locked(v); + np2m_base = nested_p2m->np2m_base; + np2m_generation = nested_p2m->np2m_generation; + p2m_unlock(nested_p2m); + /* walk the L1 P2M table */ rv = nhvm_hap_walk_L1_p2m(v, *L2_gpa, &L1_gpa, &page_order_21, &p2ma_21, npfec); + if ( nestedhap_np2m_changed(nested_p2m, np2m_base, np2m_generation) ) + goto retry; + /* let caller to handle these two cases */ switch (rv) { case NESTEDHVM_PAGEFAULT_INJECT: @@ -203,6 +226,9 @@ int nestedhvm_hap_nested_page_fault( rv = nestedhap_walk_L0_p2m(p2m, L1_gpa, &L0_gpa, &p2mt_10, &p2ma_10, &page_order_10, npfec); + if ( nestedhap_np2m_changed(nested_p2m, np2m_base, np2m_generation) ) + goto retry; + /* let upper level caller to handle these two cases */ switch (rv) { case NESTEDHVM_PAGEFAULT_INJECT: @@ -249,7 +275,19 @@ int nestedhvm_hap_nested_page_fault( p2ma_10 &= (p2m_access_t)p2ma_21; /* fix p2m_get_pagetable(nested_p2m) */ - nested_p2m = p2m_get_nestedp2m_locked(v); + { + struct p2m_domain *current_p2m = p2m_get_nestedp2m_locked(v); + + if ( current_p2m != nested_p2m || + current_p2m->np2m_base != np2m_base || + current_p2m->np2m_generation != np2m_generation ) + { + p2m_unlock(current_p2m); + goto retry; + } + + nested_p2m = current_p2m; + } nestedhap_fix_p2m(v, nested_p2m, *L2_gpa, L0_gpa, page_order_20, p2mt_10, p2ma_10); p2m_unlock(nested_p2m); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:19:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:19:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460822.1671687 (Exim 4.92) (envelope-from ) id 1xLEzT-0006Z5-CL; Mon, 26 Oct 2026 07:19:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460822.1671687; Mon, 26 Oct 2026 07:19: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 1xLEzT-0006Yy-9e; Mon, 26 Oct 2026 07:19:31 +0000 Received: by outflank-mailman (input) for mailman id 1460822; Mon, 26 Oct 2026 07:19:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEzS-0006Y9-0P for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:19:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEzR-004Ztt-DR for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:19:29 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefef9-e002-0a2a0a5209dd-0a2a4502be40-42 for ; Mon, 26 Oct 2026 08:19:29 +0100 Received: from [40.93.198.49] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adefeff-6ca4-0a2a45020019-285dc6318dca-3 for ; Mon, 26 Oct 2026 08:19:29 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by CH3PR03MB724106.namprd03.prod.outlook.com (2603:10b6:610:346::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:19:25 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:19: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=iwOmmIggGRj9QmIINJVD9X2dDMhwiJbYEcX1PXoqvmdU6n5nG6S5zXA9aKgwd0nUQUhG/G65/YQCMZQ8afAYINTGMzGgEgbwjrZWtuAzxGAk1LvGZsUEnPtF9dE3LeNON4E2ukl7rFAP4FHUIf7pC723EXLlCBrDAAbAl1VECEsUK3UZRX0+O4ezRqagcFhskgt0urRkcYnDpHLfN4haZIRD0EK9inqt+6ZiKIsH4jyYXW+5a9jnQuqeQNkkelCBQPTq7EQEammdsDFBOV0cPiphnk8YzfLkAOXSw6Yq/dh/XZPTCDiBT/UOsx8AnBGmTIz+5X+g3xoq+2UdEG2dfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aNNSJ5mfb8V73tXKnW51NLcrpjhWgm5pA8gz9jyDcdY=; b=y474i8bFeRjdKOTAChgMpVHAgg73rjyUv1DDSpNtLekxPuOHEk8SeGMX9/yd0NeQ9LThd1CccYZS3poNBXerbVt6hchrfXlt75ZrLSbo1PNIoxgul4akg4Br1+6K9uzoFXvI2zUq1/V9eFLYritEZNat6NwVSXBLxW+aSs18dN2zArUMhac5PlLHCP8G0UUVWZ2N8C1V97oY7feW2mWlIFD3l69+H39hvmMMdlmV0dVzGbSM12UYB+kkq5wDsfkwJxibQzWwApqg8w/BvetNxxemAFt359ZP8D22SkqhcB/pB6yNAsmkYEkvzahgR+8m1s9JjtZC4pfw3lRzIy5Okg== 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=aNNSJ5mfb8V73tXKnW51NLcrpjhWgm5pA8gz9jyDcdY=; b=ZHSZAWqMuO86UiokWfiNVvg/hyqxxZI0WK0DGHXELDP4uNqTi71ADQAiG185WWAvQ8RUntjDVefNl8Nai9zoE54n33mMH9WVgiLUaS/X0DW75efj8EeBPmTTqvh0YYvP9ZgMLWbDO/C3KfHKMEKKqLzhqkh0mTVVp2R/TyjVF5I= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 8/8] x86/vmx: Fix nested VPID handling Date: Mon, 26 Oct 2026 15:17:54 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0106.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:cf::17) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|CH3PR03MB724106:EE_ X-MS-Office365-Filtering-Correlation-Id: 83102bdd-77aa-41be-aa37-08df333176b8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|11063799006|5023799004|56012099006|261009223027099003|261022105027099003|261021123027099003|261021121427099003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: KPTSjEMgBsmGSvJQRAZG4lgBw69tul0EB5waIIhrwdrRE/zwyVGvJ/loV7Iweo1TgZ2Jey/Tu8GDcAhqR13n53ttxUWdK7e3YGH/a3hqcJrro4yfodQfefShL43bpXARvZJOqAjBRF2MTsa056rS4pQ/KYzbQdtPMOSj++PU1ZJE3MiHcRw5Yey3VdKfjwEJ+vfFgCLB4tBV0DQDhFJ/IGzrHjwiuOu1R/wbjNXf1VgMZmTuFFjnIJD6r2IARdKLv5q3fHUQgUP29dMuHp3aAnKJd063jWkG369y6Fl3qNAM+VRc3fEn2YcdsFGjPGDDyFFmTNOIYB0bQTGmSBSxNLlR6w++dIm1gXSwOULob0nlMWDA+b+LTS8QUtAEvanMY8VqJyVTahuoyzGU8gHSNN3HylPddXlCOmXcVKbgdJJfe0GA3lHB0Imb1jYYDhPsO+jlZoFIvGaHqHir/HE3KCWRbY1U+aKUzz1cAmT6WZLEpVDUni9u+B/qgMA/rIikI6ImKt3Nge/DIkVmdnNCzXjD4xztVj5QXSGa6JUhYC7m109W1+NjN6rkKSc67lVzvZMTV5FjNfo/5BV/wp4DXYLhMbIL+2406NY/eYqn2irar/EPOk7a12pm7MdfaGh22rO0M+Jpdhfncz86+NeAZuLEEMRBtRDErXGhXVsc8PA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(11063799006)(5023799004)(56012099006)(261009223027099003)(261022105027099003)(261021123027099003)(261021121427099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?MaBVi6+xg9UGqkIareT2lOHBWJNrF4DPzJBkvJ2fuF3ZrMIudn+uNLe4EPHl?= =?us-ascii?Q?qHqGU+Ui2LWc8ODOXsS/WOQCylMM6oMqbV3XN63V3UlaVtZEpNEvcjI3TDvY?= =?us-ascii?Q?uEB9iktIk2telKYExO36VdwnnrFSrPiKKR8Dba04KIqeW/YjDcYx0p6zNgpr?= =?us-ascii?Q?Wi5mBSohjkRwCD5aQY4nCo/KAgxVImtnfLtI8kGiaCTs28h4YBbuMT7+Tdc2?= =?us-ascii?Q?1Upz8Vlnr/qtNlmpnatX9kNCfgNjFXWqRbmkbZrycmy4AGPipBZHHrU47Rps?= =?us-ascii?Q?K6TTa6eEFvzApl9LwHsY8x8lGwO/RFZOmU+K+n/rDS6v4XuWHtVHWmxwwlNS?= =?us-ascii?Q?vhccPxNZCQd7ScVGmloYPxNE6C0aw3sWWRFvT8cnPUxaY6Qou/hTM9Gok4RQ?= =?us-ascii?Q?OObkzqG6ZDfp/tzEFar8qiOQJOL9OigfPUQl+AQ3OkrhlUKqwn2JsWKMStIR?= =?us-ascii?Q?LZgk1q4b7wnuDkK+Gy4QdzGsZ/G0toKihwpMUVtXxgowHcxXi9InOlLRpuJf?= =?us-ascii?Q?8QWF2sId802gmO7PnMG5GF0nTWK/xAD0VqwnOd/GYzjZk57dB1kwK6uFIK+A?= =?us-ascii?Q?Jp5UbBOORWU8IzsDxWuOcFeNySadJn78+xbsoeaa1/aVkV+/ewftRJkReEgk?= =?us-ascii?Q?D00vxKFdWcDafLqrsu1Q3YqF1zcCk+fyWKTbBhl57sxyB33Xyeb1+V/qN3GY?= =?us-ascii?Q?RpQwGjkik2rp641fTzYY0CLs4ZFG24Njof6CszwBC1ztgHTeuFXv3u3DL1Aj?= =?us-ascii?Q?drqrIBjGBS9IIlr1zQn4uJGMoDTK2N1Pz1Abe1v81oKSYELGGAFIY8ytrgTQ?= =?us-ascii?Q?A+Vxz243h/XE0sHEEMe7qKAXCwAygULsbVmHbv7+EPksZFyWMXcmbF0FVtAN?= =?us-ascii?Q?hYqqw7QmIUIq1PSdpQrgubFGjgfpTyDtfDuijsP1LII6zuC5uW9QKTbjeKwS?= =?us-ascii?Q?WfPzX5xTsuIjNXCctDmkkT408s3KHggdZaMkeMaYG8nk/YYEUfwV0Sy5ENzW?= =?us-ascii?Q?s4D8TZm/SGcJb51IdRlWYY892YNSJFnHzh2rRtU0ab+SHeZ9Z9JjqF+46Kar?= =?us-ascii?Q?dH8oV8M2RBQUVjspCrATi+n9zOKGGuFmsybOQmeKeEme/N9gXF1w3vVFyGHv?= =?us-ascii?Q?QGNWTe5VCKbVto0PCXhFGwNejbzJlSiL/p+1wxYr6xmK8ZG4OkXeXhJTS8xq?= =?us-ascii?Q?yI/Vg1h7DXs/7pqLt9egAMwAZoasOatNbVx09TZ6dfHvaNftHdAANEmKY8zd?= =?us-ascii?Q?og1eVPrwZPE9D1ZZzb62jBVEBx38A6nifEVu+4FHnTJBHbBpx/TcHbMoIy5f?= =?us-ascii?Q?GxAfghdvegpMy5Ajdb43LtKhaduhwRm7afCdpYC9igvCp5DRN4Kq58qXZNAV?= =?us-ascii?Q?RpWN7ts1jNZI/I25t7Hq4j8xuscz4hD7RTmQQOwEoZCw7LfMY6B96bepgspf?= =?us-ascii?Q?Yflk6kVetONFb69acVFHTp5AalZn03X97bN+R04tnnuuE1nqce4ZGqfVnejv?= =?us-ascii?Q?3fc6bXOxiTuqn9QPIzBgfHDjqLmN/HeiRFy3/FbCJEK3JvgGfRlpEk1Kltl4?= =?us-ascii?Q?9KLP273A/NO7ORzsKV6daP5mBTXVriI85BO289NyuB/pmVBaJpLTOj7AT1nB?= =?us-ascii?Q?cWfwHiO5lqCzRgvpKtJ0e9ZNlmEooH9JgC08bACbF41tr3jG6HylewkK05Xs?= =?us-ascii?Q?Z7TWMyLXjB5tDSTP6Uq7HKRFxlyvA6ZTMMUWe8opCZTpgZ2MxUPhHnlDxbeZ?= =?us-ascii?Q?7BO3DWNWRA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83102bdd-77aa-41be-aa37-08df333176b8 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:19:25.2724 (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: k9pQj/coxG9vwP/cSjvIBqg4PiEBK1CIIsFpq2f66IR6d+Wb8697vsZaTct7nVVGoRwq6Gu6/ZUNPukYY2zWtg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR03MB724106 X-purgate-ID: tlsNG-720697/1792999169-F3EBB2AC-D7A5B996/0/0 X-purgate-type: clean X-purgate-size: 4229 From: Chunjie Zhu Some nested VPID problems: * nept_get_ept_vpid_cap() ORed NVPID_CAP_BITS into the low half of IA32_VMX_EPT_VPID_CAP. The VPID capability bits (INVVPID support and types) live in bits 32 and up, so the low-half write advertised unrelated EPT capabilities to L1 and never the intended INVVPID ones. Shift them into place. * virtual_vmentry() only tracked the L2 VPID when L1 enabled VPID. When L1 does not use VPID, all of L2's linear mappings are tagged with VPID 0 and must be invalidated on every virtual VM entry, so flush the n2asid in that case as well. * vmx_vmenter_helper() jumped over the whole ASID/EPT invalidation block when the CPU lacks VPID, which also skipped the EPT invalidation that has nothing to do with VPID. Skip only the VPID part. * Require VPID hardware support for nested virt. Without VPID, every virtual VM entry/exit flushes the whole TLB, which makes nested VMX too slow to be useful. Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- xen/arch/x86/hvm/vmx/vvmx.c | 11 ++++++----- xen/arch/x86/mm/hap/nested_ept.c | 2 +- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ed4ff56e7797..8b06a462602d 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -4943,7 +4943,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) vmx_pi_do_resume(curr); if ( !cpu_has_vmx_vpid ) - goto out; + goto skip_vpid; if ( nestedhvm_vcpu_in_guestmode(curr) ) p_asid = &vcpu_nestedhvm(curr).nv_n2asid; else @@ -4975,6 +4975,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) if ( unlikely(need_flush) ) vpid_sync_all(); + skip_vpid: if ( !paging_mode_shadow(curr->domain) ) { struct ept_data *ept = &p2m_get_hostp2m(currd)->ept; @@ -5017,7 +5018,6 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) inv == 1 ? single->eptp : 0); } - out: if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) ) lbr_fixup(); diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index d1bfc1f23612..6c2629f20742 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1264,12 +1264,14 @@ static void virtual_vmentry(struct cpu_user_regs *regs) __vmwrite(EPT_POINTER, get_host_eptp(v)); /* nested VPID support! */ - if ( cpu_has_vmx_vpid && nvmx_vpid_enabled(v) ) + if ( cpu_has_vmx_vpid ) { struct nestedvmx *nvmx = &vcpu_2_nvmx(v); - uint32_t new_vpid = get_vvmcs(v, VIRTUAL_PROCESSOR_ID); + uint32_t new_vpid = nvmx_vpid_enabled(v) ? + get_vvmcs(v, VIRTUAL_PROCESSOR_ID) : 0; - if ( nvmx->guest_vpid != new_vpid ) + /* Without VPID, every virtual VM entry invalidates linear mappings. */ + if ( !new_vpid || nvmx->guest_vpid != new_vpid ) { hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); nvmx->guest_vpid = new_vpid; @@ -2909,9 +2911,8 @@ void nvmx_set_cr_read_shadow(struct vcpu *v, unsigned int cr) void __init start_nested_vmx(struct hvm_function_table *hvm_function_table) { - /* TODO: Require hardware support before enabling nested virt */ hvm_function_table->caps.nested_virt = - hvm_function_table->caps.hap; + hvm_function_table->caps.hap && cpu_has_vmx_vpid; } /* diff --git a/xen/arch/x86/mm/hap/nested_ept.c b/xen/arch/x86/mm/hap/nested_ept.c index f8563156b6d0..18d5de870013 100644 --- a/xen/arch/x86/mm/hap/nested_ept.c +++ b/xen/arch/x86/mm/hap/nested_ept.c @@ -101,7 +101,7 @@ uint64_t nept_get_ept_vpid_cap(void) if ( !cpu_has_vmx_ept_exec_only_supported ) caps &= ~VMX_EPT_EXEC_ONLY_SUPPORTED; if ( cpu_has_vmx_vpid ) - caps |= NVPID_CAP_BITS; + caps |= (uint64_t)NVPID_CAP_BITS << 32; return caps; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:19:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:19:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460823.1671697 (Exim 4.92) (envelope-from ) id 1xLEzV-0006q4-PU; Mon, 26 Oct 2026 07:19:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460823.1671697; Mon, 26 Oct 2026 07:19: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 1xLEzV-0006ps-L3; Mon, 26 Oct 2026 07:19:33 +0000 Received: by outflank-mailman (input) for mailman id 1460823; Mon, 26 Oct 2026 07:19:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLEzU-0006hb-As for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:19:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLEzT-00C7G5-GW for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:19:31 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adefefe-8faa-0a2a0a5109dd-0a2a4504871e-12 for ; Mon, 26 Oct 2026 08:19:31 +0100 Received: from [52.101.61.2] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adeff02-b57f-0a2a45040019-34653d024212-3 for ; Mon, 26 Oct 2026 08:19:31 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by DS0PR03MB7727.namprd03.prod.outlook.com (2603:10b6:8:1f1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:18:50 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:18: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=OD6g8Ez03TDz+dSyxr/rb4VsRH7ch4R43ivggtKUUWpdcdTg2ogmqBvlMbON83AnX8xIUqw9elU03tGMZ7htr5fz7zJtl2uYDkgACXltvShPiSyM0/2X1YwGNd2XfU1VKOuWmm7QD5xqhtay6n8JGdX6arxkpl5JM9gcHvGdyq9b4wkChe17nqyCTHMpTt+cL76sf9wigUfa8z4XULYDvx7v3tSlgdUTfMHmsORt2QQnc3Q00Swe9++t7529FhOJjwDd48up46GpGTyZz2pMpGcgI5oqH2l5ogNZFqYUUpjmUDKWvECcePpc/qmIQ9PPS/ezynzvn15hLwZZfzRmCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LF25T8OiSrwYhtuxYaa3NNRoM8wSX7qmAHj8AJcAOEM=; b=pVb6t+vy77j3+k/CqrurOQc+RlrtgBe/NeYpN0tHYoCosm3KKHFwL7J7AP7/ddUU8SYW2JygFAX4WpqaF0MY1XPkUui2pGAUS/Lm75Rw96h3Q4pwfMurcOpDKgoNQEgXDax52Yf3LZyh8dN0PXibiYXlGHvw2R0hR98womkqQacst9wqdu/Ug0EOwPOmiNPlcyYF0rikWnfxmtVFwFT/nfe0l8qXcqkgUitrkYPHBrAV5lY+K+5hJSCsXvPD3wb9CHr0tjZEZD+On3eJrQOrWdhG9mJ1sZOpPxsRmR5t40u16X6YLhr3T6WCNTzt3WGQ2fu9qhJK7UbiiP+D3+J9yw== 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=LF25T8OiSrwYhtuxYaa3NNRoM8wSX7qmAHj8AJcAOEM=; b=ILptrI0eJtAOWhc/5xOR2PNPHbSqyUrK7gnpRPVOjyjY9M59Yb7Ajgv2mXKLnM3I4ncd7+hM++oC1QKTS8FtC1E6HaXDVl7SSv4SXj+kRtjrflVunNL4wzxTjOvjgaXbYELqcwIsffQZIRI7OkCOQM7ke7JS1CRr0ueL2NiEPCk= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Chunjie Zhu Subject: [PATCH V1 5/8] x86/nestedvmx: Load L2's EFER on VM entry and restore L1's on VM exit Date: Mon, 26 Oct 2026 15:17:51 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2PR02CA0129.apcprd02.prod.outlook.com (2603:1096:4:188::19) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|DS0PR03MB7727:EE_ X-MS-Office365-Filtering-Correlation-Id: 7f2a10f2-6e99-4471-c03d-08df33316225 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261021121427099003|261021123027099003|261022105027099003|260925021311599003|260925021911599003|260925022911599003|10067099003|56012099006|22082099003|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: 7pD4I8BVlDlZ9nvmyvv0dWML2vhKZE4Lvpe95WyzlzIjZJzFUK/+EUXTaWWPghLEqo6rubb3HDlrjZWFtSiZQ0hatNV4Mh9/8qUso8XCJ140Av/bm6QD+D9dMiEfRk+idHcCyMh4tPjohGOjQkhfiNrKCBO/qB8GCyHiXex21gKUjpBdUI35OnQl1v3uaTXTk+X3DX0sAP17eyBB3XS3+ap9SbTHi/w/pJY7gDrqa25iuVSWqxswhdap4xjXPcOeQ/I1d4YrmYEAhVe/myi52d6u4ki+Rju52pWHRCR9+az/brbQMnVyaO2KQEYXbHPxEg3V24zxwhEw1coSkG0wwr+niGfvlLcmi28jUPbdyK90DSfnnX+SuDtD68WCZTfOTmquBN2islu3FL4BqhJFMwz8+3hWdRTFl+VOq0XzNXAQf1cpaMbbuao3NiCIiabYPD3T/iB0CbnqW44xwlpaicUb24GZTb7MYI0KqlqMlxjr6QqQgrBxI5Zj6EIna1NzPVqOeRK+NF/I1dR5r5MgpcwWrXjv8wt4Q7aiN0Vmu9wDA8AipLndWCErlW/xhGTaG/UHsLvYBqg5uv/7Bi5ZMe7NK2SvXe5MtLUDzPyP6tU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(261009223027099003)(261021121427099003)(261021123027099003)(261022105027099003)(260925021311599003)(260925021911599003)(260925022911599003)(10067099003)(56012099006)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2mSL5NTkAseCI+PMNhoxHRCgR296+JpNsPiEmHN8nfkfSIsubfWBAx3HkcLg?= =?us-ascii?Q?nUvc/lg4XVzZaw4uAH61nc7tpOmquwy6d9sbmfl7dy0yad7RSBEfVhiG+Ew3?= =?us-ascii?Q?22Etnzts7Ull4IXmrGAnTMZqSJpbv1Dn7YYO/ngFrf8otZVKm3bu11ABRMOw?= =?us-ascii?Q?ZGnB2Hs47UXbgdxOhaMAmDXyZReFIdsQ7ftaUpnyyS5+OtwCBxehhAUy67Ms?= =?us-ascii?Q?Vff9yEVVre1c/pQxEga+EoBCKS3WELYHAnz17nOhAftpS9dn/C1vyTpDbs2E?= =?us-ascii?Q?jElOi1DQMnD3DvvE2ywma8Ex8qK2Lk5xultpqGCvKtELzEGZ2hnLsZuGmydz?= =?us-ascii?Q?tY6pLizHEDcQy80dhnFjyRS3eQDDGQpiNQSKAvMnJbE/uZ4isog5QErmthNG?= =?us-ascii?Q?tD/FbvCe48vzzKe6/D3Qkl/OInHaGeACjg74GMH0rezDVCH0KUQl7QYp2Ksf?= =?us-ascii?Q?TVk5ZCEmcFbsi9XQhMYeBqLAeb83W5AfQ9ZRG5H8mv5XXWdJ8+TqGg00jgrm?= =?us-ascii?Q?x2UYBE83MN7rVoc/uwRzVdgeaALy7RvxjAtbQKgGuc4mBNtBKHDVuZvQkV5u?= =?us-ascii?Q?Ai2mW7z2VEeVdDtcsy4mD3uteugzMTJCWK80XCSdXDvsWdkYjdYtqR3G5f6N?= =?us-ascii?Q?9kz96LRTms/iOKgEFnfx7P3oVhLLmNZ2OLMb1cr0hkJ3QXs7Yr5fdLVXByBb?= =?us-ascii?Q?lMAyHvaFF6m7sptSd7cruFJtGaq5ws+/em7F/5ItcU2T5t2rHEVu64FSZIzY?= =?us-ascii?Q?FTQAu4s+jjo2zTpwowmKRIbD1Y48e9Fp/G7QYrIvSI263Tt7K9V1TcoZgPmd?= =?us-ascii?Q?eTKgsI/CCy2dq0Ie6epldyua4nvHetV1/dLhing+LYfVlQ2AyNbN5dumFEwD?= =?us-ascii?Q?28qyjDtpUS+mhgXo3S9GdMLpkgKklIQzT6MW15VSP3PmaVm+NAZyAI+GbdtW?= =?us-ascii?Q?PDcdM4Pp032P3MB8TULBDweuLmvS04XM+nJoXlmpXLotgRt7/z/R0NbdTq/n?= =?us-ascii?Q?+GgRAcBy28yjeoibc6WaHgtgg2ndwnjiJa/nKAtJt9hkZFPTwNDujiZ/WX2r?= =?us-ascii?Q?exROfpXdRciCFacRGTMZFtFtwY2p+Jq4AMNZ0zgBZ6go1B7o1o14DrFeF+kF?= =?us-ascii?Q?ORcUkhPMpW7bi0nNAC+HlD31LptjhLXaHRgzKdOOOHvlcIqEYt5XXpvReote?= =?us-ascii?Q?O0F7SXVgNuMtFAJgCH2ptMVV4wKzehGOfkSCGGYIdZZV4mBrtzdOYP3BsSH/?= =?us-ascii?Q?1tlL2G0OXELT41NAb103ShLkAGSAycUi+EOrrJvPA8BjfgCk9aJwxV24S+J5?= =?us-ascii?Q?HulnzixuZgZ7klkyrJZGQXCBvIAAkh0MzewHLFT69KDOdI/mGLrjvF8cQmA9?= =?us-ascii?Q?tB6lw3yqGvH/UkZ4eI+tw/uRBI9h/F63EC0RaRE5llhs9pSB7vCR8NCsCJpG?= =?us-ascii?Q?8P3e6fqq8CiQumRSm3sogV/BxN8P4AkrwYTqAHpRI9XRWYpaS9c+f9zAXhoV?= =?us-ascii?Q?JjSueBUfFkwgZs8Z5HEQCe19+rnWq+NOnUi90Gju2BUudVyuLiu3hg96vEhC?= =?us-ascii?Q?Y84GJj9lTe2RygalDDC190CzkcGikN8SYYmEweCp0wQuv3PDqLFjqlDn/0Xp?= =?us-ascii?Q?JCLPmwM2RI7GkMlVLjy+HzdMA0e5uhnMrWaJiE7fo3Mksoru5WG2oYsLhlfE?= =?us-ascii?Q?Qq2QMODS73TSapV0pRUEYdMibs4+NZwEOI5G/IcUI6eEpnI/H+A+9EA2tuwu?= =?us-ascii?Q?OMQmDxxnpQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f2a10f2-6e99-4471-c03d-08df33316225 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:18:50.4083 (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: nNwWA+Til8WBv7SwUrYd0Y/GYjrm3HwW4N89YAOs4adBIahgLritbpK9fpvrdGFjcVctW9km/83AStJuq8utIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7727 X-purgate-ID: tlsNG-ebf023/1792999171-52ECEB50-6CD23DD8/0/0 X-purgate-type: clean X-purgate-size: 4060 From: Chunjie Zhu nvmx_update_entry_control() strips VM_ENTRY_LOAD_GUEST_EFER from the vmcs02 entry controls, and virtual_vmentry() only derives EFER.LMA/LME from VM_ENTRY_IA32E_MODE. As a result: * While L2 runs, hardware EFER is L0's own value (LME set), and since vmx_update_guest_efer() clears the RDMSR intercept when guest_efer matches the value it believes is loaded, L2's RDMSR of EFER is passed through and returns LME=1 even though L2 never set it. * L0's v->arch.hvm.guest_efer has LME cleared for a non-64bit L2, so L2 never sets LME in L0's view L2 Linux AP trampolines read EFER and skip the WRMSR if LME is already set. L0 therefore never sees LME, and when L2 enables CR0.PG it is treated as legacy PAE paging. PDPTEs are loaded from what is really a PML4, and VM entry fails: vmentry failure (reason 0x80000021): Invalid guest state (2) PDPTE0 = 0x0000000023604063 EFER(VMCS) = 0 which crashes the L1 domain ("Unhandled nested vmexit: reason 2147483681"). Fix this by: * Forcing VM_ENTRY_LOAD_GUEST_EFER in vmcs02 (when the CPU supports it), so hardware EFER, and hence passthrough RDMSR, matches guest_efer. * In virtual_vmentry(), taking guest_efer from vmcs12 GUEST_EFER when L1 set VM_ENTRY_LOAD_GUEST_EFER, preserving LME for an unpaged L2, with LMA still following IA32E_MODE. Then push it to hardware with hvm_update_guest_efer(). * In virtual_vmexit(), restoring guest_efer from vmcs01 GUEST_EFER so that L2's SCE/NXE/LME bits don't leak into L1. Signed-off-by: Chunjie Zhu Assisted-by: Claude:claude-sonnet-5 --- xen/arch/x86/hvm/vmx/vvmx.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index dc8bcbeea033..d1bfc1f23612 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -695,6 +695,12 @@ static void nvmx_update_entry_control(struct vcpu *v) shadow_cntrl &= ~(VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_GUEST_EFER | VM_ENTRY_LOAD_PERF_GLOBAL_CTRL); + /* + * Always load L2's EFER from v->arch.hvm.guest_efer, so hardware (and + * passthrough RDMSR) agrees with it rather than showing L0's own EFER. + */ + if ( cpu_has_vmx_efer ) + shadow_cntrl |= VM_ENTRY_LOAD_GUEST_EFER; __vmwrite(VM_ENTRY_CONTROLS, shadow_cntrl); } @@ -1220,13 +1226,24 @@ static void virtual_vmentry(struct cpu_user_regs *regs) lm_l1 = hvm_long_mode_active(v); lm_l2 = !!(get_vvmcs(v, VM_ENTRY_CONTROLS) & VM_ENTRY_IA32E_MODE); - if ( lm_l2 ) - v->arch.hvm.guest_efer |= EFER_LMA | EFER_LME; + if ( get_vvmcs(v, VM_ENTRY_CONTROLS) & VM_ENTRY_LOAD_GUEST_EFER ) + { + /* + * L2 may have EFER.LME set while still unpaged (LMA clear), e.g. an + * AP trampoline which skips the WRMSR because it reads LME already + * set. Keep it, or enabling paging later is treated as legacy PAE. + */ + v->arch.hvm.guest_efer = get_vvmcs(v, GUEST_EFER) & ~EFER_LMA; + } else v->arch.hvm.guest_efer &= ~(EFER_LMA | EFER_LME); + if ( lm_l2 ) + v->arch.hvm.guest_efer |= EFER_LMA | EFER_LME; + load_shadow_control(v); load_shadow_guest_state(v); + hvm_update_guest_efer(v); if ( lm_l1 != lm_l2 ) paging_update_paging_modes(v); @@ -1452,6 +1469,15 @@ static void virtual_vmexit(struct cpu_user_regs *regs) lm_l2 = hvm_long_mode_active(v); lm_l1 = !!(get_vvmcs(v, VM_EXIT_CONTROLS) & VM_EXIT_IA32E_MODE); + /* Don't leak L2's EFER (SCE, NXE, LME) into L1. */ + if ( cpu_has_vmx_efer ) + { + unsigned long efer; + + __vmread(GUEST_EFER, &efer); + v->arch.hvm.guest_efer = efer; + } + if ( lm_l1 ) v->arch.hvm.guest_efer |= EFER_LMA | EFER_LME; else -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 07:31:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 07:31:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460845.1671707 (Exim 4.92) (envelope-from ) id 1xLFAs-0003Dr-RM; Mon, 26 Oct 2026 07:31:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460845.1671707; Mon, 26 Oct 2026 07:31: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 1xLFAs-0003Dk-N6; Mon, 26 Oct 2026 07:31:18 +0000 Received: by outflank-mailman (input) for mailman id 1460845; Mon, 26 Oct 2026 07:31:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLFAr-0003Db-8n for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 07:31:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLFAp-00C9Yk-7t for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 08:31:15 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf01ba-2eae-0a2a0a5409dd-0a2a4507dd16-26 for ; Mon, 26 Oct 2026 08:31:14 +0100 Received: from [52.101.229.86] (helo=TY3P286CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf01b6-b4ea-0a2a45070019-3465e5564c31-3 for ; Mon, 26 Oct 2026 08:31:05 +0100 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TY7P286MB7251.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:363::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 07:31:00 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 07:31: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=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=UM0EvOJZZk0cWyC9VQDYYZDx2nrTmaCw7p/gOaKveUN7kPQcYIOupbsAMTJmbHrcWGQ8Pe8mNKV8bzcAzRyZyD4orgdRl0j0UaTYZiExDUCsEU3t4rH2SQh/2ERqBq53mUpZa+tOt/UGjnWi59/3NN6DEDyWzg80DjXjC2Tgpslf5+eOuYaiaau96YSFS5/E3jWvmEoyEegbwgf1ueY4cwpm9Vabxiy2h6p18lNqE8s3C+kQetHkwmCju8STc1+U4HWQhwT95rHVuMVxga1EMcwXRMKMXsY/1c58tT/Tn+hQdKOEZ98oLpfkowuSv/LTHHfJ4OF1rZcnvZ+94OfjDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=m0fqivY6ZI1eL/B17AbOGNjXYhEJdhi/nBwLdhFJg9M=; b=vRcjbhpveX2ibalUjnYjhqa3l5+vBeY4cEOjBmMClNtWcWPD0PPmZ6b/623qvB9IxW2Dlilvi2xegsARJLY2ZIKqENtVkIAAe3zRo5d+hb6zgevuLCKWkFJJ1q3DyGRbJnyjSP9YoKu0ETjShBo8fCNekrJF4nkGkQVnuRWsjcSPkHx7A5xw43wR3nxai3+afVP7aYII+ce4mB7zerqBCpXBosEfXU0q8f4LC3+14VBIPXGp1zH5v4x9+XVE1YM6nEVYxdX5/4soE4NsRv6dtxDUefPj1KGXkx8mNXAMtNhkWa9iWvSnr/XTUNaLf/30h0OyBxw6S9prJJ++DyvV1w== 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=m0fqivY6ZI1eL/B17AbOGNjXYhEJdhi/nBwLdhFJg9M=; b=I2NwlvB8VcRJAVazRER0Zzve6Im4neCGQ2EsUCyp6xnjLNAsNCIUhdRTq+Dg3V9kX/W8y2AoilBI/AplU9NMx9GHHm34pYtMuB2UIbA41Mtnb1iOdWIiFv7fnjb2AYk3Khk5h8GV4eRGSkGyphx+iJrOjRRDQLpJEBXoghqc32U= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: bernhard.kaindl@citrix.com Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, roger@xenproject.org, ross.lagerwall@citrix.com Subject: Re: [RFC 1/5] xen/arm64: livepatch: enable attaching callbacks Date: Mon, 26 Oct 2026 16:30:22 +0900 Message-Id: <20261026073022.110170-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <179284608595.1706038.12585790247811677658.b4-review@b4> References: <179284608595.1706038.12585790247811677658.b4-review@b4> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TY6P301CA0021.JPNP301.PROD.OUTLOOK.COM (2603:1096:405:3bf::11) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TY7P286MB7251:EE_ X-MS-Office365-Filtering-Correlation-Id: 815b5655-5853-4487-d7b1-08df3333157c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|366016|18002099003|6133799003|22082099003|3023799007|56012099006|5023799004|261021123027099003|10067099003|261009223027099003|261022105027099003|261021133027099003|261021135927099003|261021130227099003|261022113327099003|261021121427099003|261022075727099003|261022115727099003; X-Microsoft-Antispam-Message-Info: X6LDRQryRinXZrPjfpsHHudEqkIToMc3JWiQnAMqqyH8P6ueptfx+5807CISfbrNAZyZXESG3WoDJTpwcbOVlyLYXyPVJM5iWCpcXkFgvzc6MCDHHjVzeTcHYFs3J7OXMcjVbPTPDCyyX+r6Gb9QKyHQ1NkgCNrnz0egZjDg8Wlkgb64AESm2SktyJ/k7AmN9XAcPSFTv5F4pCe1gOaNqDonKmIM6XRrsaFFNuGix/UUs+LurYMY+hO/OuhbrbfSQBbZS42xCU7i8mLvfQfmzCuS6tVfzg9UZSkRMCqSGuV+hZFUm8kuFsyHp0gL7q5ZPxzAsuyGtHJZS3Zy1b7GQxmHrUAs2jWG4UzM0vC18eJF1e7aHA4B1XCsEfQ9vh9GK9El9b2+lcO1YgXVTgbzxLaGgs+Thabt6Tsg8dtotXyEHzWzgeLLrZl/nkexqNdBUgauzc9JcfPLolix7B0Z0KWWXx6c/q9ymTyGWULIUPZfeqb/8VESVW/W21CamEz4wF3yRtHGafjVQWCm1OcrNoLFELAOBsjE1vf1JkIYlZnKN5WO3Pe83yHZZ1jp5NQyOCMfrmOaGpmuGHvSJEK0DWt6Si6qd6l9AaOoKj0kTQ457QJy3q4W9RF2K/VFRzZ8Up2Ofx0gIfTagOTpU91tITDEyaYRVi4gZrH8x9rNPXs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(7416014)(1800799024)(366016)(18002099003)(6133799003)(22082099003)(3023799007)(56012099006)(5023799004)(261021123027099003)(10067099003)(261009223027099003)(261022105027099003)(261021133027099003)(261021135927099003)(261021130227099003)(261022113327099003)(261021121427099003)(261022075727099003)(261022115727099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?64KnRX2lfNrqRDqQE6VeoY5SiupiJOTdSCnitcj6lpPD2komZ+HW3ouBKz0N?= =?us-ascii?Q?l0LRaKT23Thxzuw4jys4kUqbfpqdOm/sbECj2OcclnfLi4siB+7jNvDQUfKO?= =?us-ascii?Q?RWv2n1qvC26oa2u4FoE+b5bapRd7FEGS5eC2Ml0f5eCxJakiCmJDob85bpTb?= =?us-ascii?Q?+tmDuwdidLpoiP1Qkwo/MNFiNTqb5ezW3t7mjGa63PX5ptc6msPMv+hmheV+?= =?us-ascii?Q?zRWgQmH5CHUwAxTpRHpt6H3s8SIHybHT0VokTiWdmcRCBFptNw55ZgcBjA81?= =?us-ascii?Q?S0bdYYQIejjF5ho/3Emc+NSrvoMHETtTqk8TffA1NdKyHDc8hRebu/ulIOio?= =?us-ascii?Q?hIMdzh3tMPx+h1dLcsMW2g7lq755EotL50g4us0yMl8kxGMZfnLHhqff4HxM?= =?us-ascii?Q?tMZBk+Z9VFiFQvtgpW4hGad3gAn8rX5hYDXcNxddOET03b00iSnulE1YDHCy?= =?us-ascii?Q?HhuiLW2jGZ7knkdUlQG94tWc7TWVaXedBFq9istIaAxeP1Gy4cPhRqrr/oGL?= =?us-ascii?Q?b3u1oql5jYcoQLYzp2/Z5K5yCRQUiZCto2udUQPrWCbrZiTrTn5rZ1m28Anl?= =?us-ascii?Q?RqnN3IQSYJAgvB4aEB4TvKHNtLQaxU+cDR3EbkYgaCuH0gTgWpadffhnHO55?= =?us-ascii?Q?iVGMocfcUVr/O4lwqV44Vq0IxJAT/Ple09QaGc2kfS3t7zSAUTnDVY8ADeMd?= =?us-ascii?Q?nsAspHds87SS4m4j+uHISCMXcQkjJyAFX97qVkhPlYVqG+RwYq9wbtCjUpiW?= =?us-ascii?Q?qzsziQ4sOIrqO7U09BhxwsWgujzdOVF2USbJ8jsBJGvwWDv1Mxjj+oqC4RdT?= =?us-ascii?Q?zbDeQ8pfgU9Z/N0QZvkWoyUtufgJECJlJlJYwNfnzL2z3vmWFqFxoeN6pRlt?= =?us-ascii?Q?f7ea2gigHZTIzVi0mtGCP0fJnFPGnowpVpRdR7Zk1djZ4k+PdRq2giR7T2HU?= =?us-ascii?Q?y/IzTEz0vnfQXLB31n/obS6Ks0pHzSXVFe29EzfZw/Tqr+IP+uuiupO5emGG?= =?us-ascii?Q?AGJQ427bVSlAfDuVipVFsn0Q7mTvBz7LNrJA9naFMbv4gonPPHY6JYh/mU/h?= =?us-ascii?Q?pyhTYhQ6DmGSPz+0+CQVs3RmnAtsU8EVMh9VAilGqEvG8bCWOHVQ48qdXjfo?= =?us-ascii?Q?1VeYxDyVi2P1EY1QRsV4SLycP5L+/raduDOVOY7pLMdj9YENqJVEo0YgC4UE?= =?us-ascii?Q?2GCYmiuBXK0QQiLSwjbjShptupzHA2Q+AcqcU4g09Y9LpdjtRgG+l/rRCf8E?= =?us-ascii?Q?YUqE7rxjZj7f9jnyQAdB1eKTNCwIirXdynDW7nM5+mXi/HnP+A8f+ezG5ncj?= =?us-ascii?Q?IZWrRVJHk+/kDKWF7m2q5JsjeyI4LHv/FkOw6eCW0N1XWlHmwJFy5pRRKYEE?= =?us-ascii?Q?Ap+ZqlA5sjT6ssDjVjAsbSGWVwfdpcvnjBpXgS7ThvT7ckA0mvWVZKaDmrKP?= =?us-ascii?Q?ADU3pUxwHIJoZGJak8XbgZWmvtv8Uw+MjgjryCAbAhLVxL7OezajgdAGE5lE?= =?us-ascii?Q?opg9eRjiaCdzHCMvxS8jJjUqXzau0U/r36tBadlGEX1yfio7afN4J0ACpKQQ?= =?us-ascii?Q?mY7MAvdiLhJxt7likPrpXjcqfIy9Q+ig7Y0SrQulT1pfxuMNEz2vLWwP2uDC?= =?us-ascii?Q?cpCxAgQKAw/crziZM72h4BqYRN60/J8VQM/Hp8+WiUVybcSGFt4nOSpq1YD+?= =?us-ascii?Q?3mL2P5oz2+vi5zcTi/g8vGMOAuARBLLOM1yQas4BiZLaR5NZUgiCwAEOm6wG?= =?us-ascii?Q?e7qDSXi7ag=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 815b5655-5853-4487-d7b1-08df3333157c X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 07:31:00.7571 (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: aLe7+bgSH64Ed6EUnmEhrAFF4tJtngztJqAUY3gcVzryu5iJSj1Dx+ihHnJOC8tN9inlBIesTbtRbRjlPrWHaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY7P286MB7251 X-purgate-ID: tlsNG-ef75cf/1792999870-A66DAAE4-197AA972/0/0 X-purgate-type: clean X-purgate-size: 5037 Hi Bernhard! Thank you for your feedback. I'm still going through your comments on the other patches. I'll reply as I work through them. On Sat, 24 Oct 2026 14:48:05 +0200 Bernhard Kaindl wrote: >--- a/xen/arch/arm/arm64/livepatch.c >+++ b/xen/arch/arm/arm64/livepatch.c >@@ -492,6 +496,36 @@ >> +#ifdef CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY >> +void arch_livepatch_apply_trace(const struct livepatch_func *trace) >> +{ >> + uint32_t *new_ptr; >> + uint32_t insns[2]; >> + >> + new_ptr = trace->old_addr - (void *)_start + vmap_of_xen_text; >> [...] >> + memcpy(new_ptr, insns, sizeof(insns)); > >This copies eight bytes from the two-element instruction array, while >uploaded trace descriptors still use the ordinary Arm livepatch verifier? > >For reference, the existing arch_livepatch_verify_func() in >xen/arch/arm/livepatch.c contains this size check (not added by this patch): > >> if ( func->old_size < ARCH_PATCH_INSN_SIZE ) >> return -EINVAL; >> >> return 0; Thank you for pointing this out. Yes, the check is insufficient. >With ARCH_PATCH_INSN_SIZE equal to four bytes, doesn't this accept a >four-byte function without establishing that two reserved tracing NOPs >are present? Is there another check on this path that I have overlooked? No, I didn't add any other check. >Could an assembly entry or another uninstrumented function consequently >have executable instructions overwritten? If reverting then installs >two NOPs, could that lose the original instructions rather than restore >them? Yes, I think both could happen. >Would it make sense to validate the complete reserved tracing entry, >including the actual branch destination and any conflicting livepatch, >before allowing the write? Could the expected entry also be checked at >application time, so that a modification after upload is not missed? Thanks you for the suggestion. How about adding a helper on the upload/apply/revert paths that checks if the function's entry is in the expected state? ---- BEGIN IDEA ---- /* * Make sure the patch site is in the expected state. * * patched = false: expect NOP + NOP. * patched = true: expect MOV + BL. */ static int arch_livepatch_verify_entry(unsigned long addr, bool patched) { const uint32_t *entry = (const uint32_t *)addr; uint32_t expected[2]; uint32_t branch; /* * Assembly functions and C functions excluded from instrumentation * lack reserved NOPs. */ if ( !is_patchable_function_entry(addr) ) return -EINVAL; /* * Generate the expected BL instruction with its destination * set to the trampoline. */ branch = aarch64_insn_gen_branch_imm(addr + ARCH_PATCH_INSN_SIZE, (unsigned long)xen_livepatch_trace_caller, AARCH64_INSN_BRANCH_LINK); /* Make sure the destination is within the branch range */ if ( branch == AARCH64_BREAK_FAULT ) return -EINVAL; if ( patched ) { /* * Before reverting, make sure the site is as we patched: * mov x9, lr * bl xen_livepatch_trace_caller */ expected[0] = aarch64_insn_gen_move_reg(9, 30); expected[1] = branch; } else { /* * Before applying, make sure the site is as we reserved: * nop * nop */ expected[0] = aarch64_insn_gen_nop(); expected[1] = aarch64_insn_gen_nop(); } /* Reject the (un)patching if the site is not as we expected */ if ( entry[0] != expected[0] || entry[1] != expected[1] ) return -EINVAL; return 0; } ---- END IDEA ---- Note that is_patchable_function_entry() was introduced in patch 3/5 for checking whether the function at the given address is traceable. I'll move the function to this patch. >Separately, could a callback or one of its helpers call the traced >function again before the first callback returns? > >> + ASSERT(f->new_addr); >> + ((livepatch_trace_func_t)f->new_addr)((unsigned long)f->old_addr, >> parent_ip); > >What would contain a recursion before Xen runs out of stack? Would a >guard covering the pre-callback dispatcher work as well as the callback >itself help, or is there an existing restriction on callback targets >that would rule this out? There is no restriction preventing the recursion right now. >I think marking the dispatcher itself non-patchable does not protect >its callees or the callback's callees, so they should be protected too? I see that marking the dispatcher alone is insufficient. I'll add a guard that covers the dispatcher and callback following your suggestion. >Thanks for taking a look, and apologies if I have missed an existing >safeguard. Thank you for pointing this out as well. Sincerely, Ryo Takakura From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:02:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:02:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460889.1671759 (Exim 4.92) (envelope-from ) id 1xLGai-0002iC-5h; Mon, 26 Oct 2026 09:02:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460889.1671759; Mon, 26 Oct 2026 09:02: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 1xLGai-0002i5-2a; Mon, 26 Oct 2026 09:02:04 +0000 Received: by outflank-mailman (input) for mailman id 1460889; Mon, 26 Oct 2026 09:02:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLGag-0002hz-P2 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:02:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGaf-00DHMm-Ma for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:02:01 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1702-2eae-0a2a0a5409dd-0a2a45088264-16 for ; Mon, 26 Oct 2026 10:02:01 +0100 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1709-f659-0a2a45080019-d1558031cdd2-3 for ; Mon, 26 Oct 2026 10:02:01 +0100 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a20bdaf39cso27875975e9.1 for ; Mon, 26 Oct 2026 02:02: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-48e3ecd39a9sm15397193f8f.46.2026.10.26.02.02.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:02: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=1793005321; x=1793610121; 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=Oi5FAnr/gjjQLIwAVs9y0r51/dbuSsrtiocWI+nOvN0=; b=KeA1fNoJ0e9pRnDaiUr62AhdzqM8XsiN8e8go0OwsZY3NQa6glZAhWxmTHdzM4r3Vn qQXGI4CdomkbxN4t1D/znxgt6CqtZRWmYavlEfbamhJMMDhWwbbsDyhzifpLtSbDx3lB OU0AliAeT4LOHIpuF2qPxj8INEwe0XjdR9UMiARKuvb6unp1849pgNYxr5hYHZukli+K PHXnp4xtwIwMgoOKrxZgJWINPJuimaZgebwniJaZlKzh4T3g5zpxT0sIxnOhddIiRKY8 cLfPdhBYinIR5zWSiNmcQQcuvxPPokl06jwrnhtnPqYqIPL88yBiojgtW2I9vojFpxF9 tMhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793005321; x=1793610121; 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=Oi5FAnr/gjjQLIwAVs9y0r51/dbuSsrtiocWI+nOvN0=; b=BztQ3L7M7CMYIfX6AEKvj1eNkxjKlgzJMxDnl7AF1E7gHTJufHxfcZghAMOZsvH5p4 YScj2UvJEevPy90WWlYdmShufxuM+hXpfssHNww/Aj54uiMwiloUznOiMx8li02GTCbr pDHdmXGyi6qXD9nZx6sYOthiFgE0Dgc/bfD1iqKOyKeDpOZre5vBFxX/kE41RpSXZP4M odTXEGPs8UqeLkU5KALrW7PpAO/V08qaP0fVmARD40YHoQUXSnTUDP24QAty1noMcxgq vbkuDaDwByh+Uq9YuzKlQ/eBf9pbfGxNMPaAYHnF/3MFtYgoy9KVOIPHZKcJB75bmGWg KyFg== X-Forwarded-Encrypted: i=1; AKwUvByF3+QPBHHYjs0qNt8f0I+CIeS5Ov1NtB845QXNBBBTfAbH0ass51chO68N+XUB+SD7T68Z+K7FbwY=@lists.xenproject.org X-Gm-Message-State: AFq9FYI9WICOpWcLbqU/Bfhnx+zM2f3PH8iNLt+BLkQCVyw8+U22PJF6 30bqAgVxPa0snNaaL+W1EJHjPxdyvUlUELimGHsxpdieDR5pgg8NcZoofEtQPtLx8g== X-Gm-Gg: AYBFou3kChX1ZsPhipJflQ2dsf/IlAiVvyOgr2cwHQs0r382h4j38+QyCzQLtYEDHOl kw5sK5ds0A+QOOBvMRcLrR+hmJruL/xAgHdMbVeh3uaereAbdqKc9BK/z8LqVaVNm6PUuesaFK3 r1SP3IaSgPSHshpLjTe+HCt+pTCXcDucDRkswDTxH/g9BqVe/iSru4RRNcs+aGzqVrWzOA4n8xs 2l1+p0NeQjbh9iTdt148PtJ6ZhRzYga+O0X8Ic/xo+7UOhaiz3D5YH/P41c2kdScPExqYVB630H etc5DzgZPLOfhLReLr9OogiPc7FIid0kPRjPpYZoR5hZXe4G0JunUxWCljZJrULXr4b+zpVNIc5 Rmao8qMAtLpjZbbFggU1H69vfRQpDamCKqzqj3/0FTmfQZR85rMFKYfI3vEMIGk4HKw2hJjj5lB kbOWIphTsYFVs+FprOdjsYWmJ7wYlKeZL0Ao5D1CaMy9TQART5tn0ljjXrqKTCKJE9ShYkoDwj3 63Sjlx9mjTcPtnfhGJ2jlBU3HfrnDwDaK70OLWIRMir8Ceplioby3wTYeRghquBuc9ENbpcfQcN 8KdGUezRVsn/N2AVGra7lCEN/lm/IqjziURFlsKBorGN X-Received: by 2002:a05:600c:83c7:b0:4a1:e92b:ae4a with SMTP id 5b1f17b1804b1-4a35aca5824mr105924985e9.21.1793005320840; Mon, 26 Oct 2026 02:02:00 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 10:01:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] make: add use of $(realpath ) in top and main Rules.mk files To: Elliott Mitchell 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: <0b38e7ba64831575c2f2533c69e00da79c4bc958.1792436534.git.ehem+xen@m5p.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: <0b38e7ba64831575c2f2533c69e00da79c4bc958.1792436534.git.ehem+xen@m5p.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793005321-CF55C87B-789035C8/10/78276251493 X-purgate-type: spam X-purgate-size: 350 On 19.10.2026 21:02, Elliott Mitchell wrote: > Date: Sat, 17 Oct 2026 12:25:36 -0700 > > Without this "/.." tend to accumulate in $(XEN_ROOT) and eventually > things start breaking. "breaking" as in what exactly happening? Jan > Address this before something subtlely breaks. > > Signed-off-by: Elliott Mitchell From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:05:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:05:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460896.1671767 (Exim 4.92) (envelope-from ) id 1xLGeK-0003Lo-Nd; Mon, 26 Oct 2026 09:05:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460896.1671767; Mon, 26 Oct 2026 09:05: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 1xLGeK-0003Lh-Kq; Mon, 26 Oct 2026 09:05:48 +0000 Received: by outflank-mailman (input) for mailman id 1460896; Mon, 26 Oct 2026 09:05:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLGeK-0003LI-5J for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:05:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGeJ-002SQf-IK for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:05:47 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf17e5-8faa-0a2a0a5109dd-0a2a450c8c6e-34 for ; Mon, 26 Oct 2026 10:05:47 +0100 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf17eb-f479-0a2a450c0019-d155dd33ece9-3 for ; Mon, 26 Oct 2026 10:05:47 +0100 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48e4831c028so1158334f8f.0 for ; Mon, 26 Oct 2026 02:05: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-48e3ebcb8e0sm14649379f8f.29.2026.10.26.02.05.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:05: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=1793005547; x=1793610347; 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=1JcGUxa8bXH2iNtwlafKecMCddrq/yu2MDsWjfcGsfk=; b=D1yYJnTOtz0pofuUQ2skm7YrGo6dKAUlQr4wFMuxP6/j3iI5P0vyAyW3l1+7J+WsDn VJ7fTKt9AasUxlx/0jSScvH1uMArf5yWThSdK+janrmL5WD2iq/Ji9mCym82C7ldlTGq rO/l6EeoWWRBEYPPXrsTelmiZVT39yaxJ2v4mlz5fs8R8kIP1FMt2vdexkP/uTn98MZa MsWJi5H8xFzoTbEFFfLFseFmcH+6rFX7q7D/LSS8QLIsCR3KVKmUIvY0LhBYc5Au/xLO t+erwuYeC1q1XftbYDOaaaP7mErA6+SAnAL22ipxh3iF+Ts54IKJLCxWvoatLcu2E65J JdCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793005547; x=1793610347; 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=1JcGUxa8bXH2iNtwlafKecMCddrq/yu2MDsWjfcGsfk=; b=ZK8q71BishVKNVcBz2x04FqFUW9JCR+jTxbLQVpcUKxe6dMmb+7jp8BnSq9DJqqnPO xcCe9NH9wSC40ua3xKmQI5088UqeyImCDmRWgmr8X4e3VIthNHq8cgVefEeflsgS9Ye/ c81OObZfG9HWoAtO9qCYVoaZOAeyXnmhdBBUqasP8zjcRwqh3QpPI4xMkPCgkkZgw/Sy FIWNuRl7jFlhwiTFcC/UmrtZdX9zTib6RVRgKEm9Fb3XL64SNLMfHsWIAUcyGO3r31uT BsbUPiVzqFaZYDJguJGhBE6mRPVbRI1rHfAHy5MNSAD/9WUaETH/LqugZCoB9weDGR+O 2y8Q== X-Forwarded-Encrypted: i=1; AKwUvBygKKUaay4uUS9e0s6a7uEqLuUbZ+f0/xgP7D0H5ONW5E4yaG9cNp/nNXQ1dCyY1lHKxD3Jjsu9loE=@lists.xenproject.org X-Gm-Message-State: AFq9FYI37CFL4WULP4djC4TBcN5YGmltbXD+vgqkSpznMi+ODjkrA/1d SPoeXcja3oIdhKQMemo/9lpChwEnTQcwd+Bl/Fgme19fLX9wuG6yQeY0i6yilyVLvA== X-Gm-Gg: AYBFou0tlKmGQS7B4G5u/9AxDtdEl8Tdwo05oa1irShs/U4NFllLKByjmz3HpsxobjZ 4zGRssmBQGNHrcwzTN3oAMP5jZA3Fo4jCrIRue3XA/uikch+ITvoGcPrlpE0zc9iq2A0P7PXv31 SJVvnXpYydKlU/daIKSec1xXvTEiUlfFscRgY9xQGCUxvbZYuQxys7KhwRvGO7x7wFgb/7Y3B+8 5TgpZG6JSFRQqQfOEI9G2/poIaUzE5kbCjznPmykRgy7DsBSvI3+bbhRggoJGnacFpRCy4IiOo6 2reuiEsMM0VBAh/bv7vVPboj06EfLtRYk952FSjAgj2YiESDngncsderj5q5wf5f650rVrTZITd PdRxBaZdDTHFaRY03rfbe4ydozdIrow/uHBZ3gGRh4SYvpWeElsVlcfA1LcW/ugmIQ5DrRLjYGy XgwE8snDjieW+R8CxGkgRrLZQ55EAgor2/zDc7L5rTENjPQl+ffdd1z9JOnpdK5SX2ISJKx/BsU P+hduZWH+D8K9Fh7Ui2NoPLaJufqyDmQVQMrhPd3icNvsFnixKBvTwlLAx8QH9HAmxWVB6QUn55 IkOqSdRX7nhuZsALEiIAwiqeAnUR2HhKlESrG2LT1vE= X-Received: by 2002:a5d:490c:0:b0:48d:c186:dcc6 with SMTP id ffacd0b85a97d-48e3eb8ea66mr7920142f8f.57.1793005546816; Mon, 26 Oct 2026 02:05:46 -0700 (PDT) Message-ID: <0fc3eb31-1aac-4b0e-8f9a-ae947dabe81d@suse.com> Date: Mon, 26 Oct 2026 10:05:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] Config.mk: record hash of SeaBIOS tag To: Elliott Mitchell 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: <9771fce7e080b2d64fd9535b6e38d70781eb2de3.1792436534.git.ehem+xen@m5p.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: <9771fce7e080b2d64fd9535b6e38d70781eb2de3.1792436534.git.ehem+xen@m5p.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1793005547-03AD4A5B-E0A8233B/10/78276251493 X-purgate-type: spam X-purgate-size: 1072 On 19.10.2026 21:02, Elliott Mitchell wrote: > Date: Sun, 18 Oct 2026 14:12:43 -0700 > > Recording the tag as a comment, but directing git at the hash allows > bypassing downloading tags (git does not selectively download tags). > While remote branches get prefixed with the remote name. The result is > identical, the tag is simply a reference to the hash. I don't quite get what the win is. The middle sentence also feels, to me, unrelated to anything else here. The fact that ... > --- a/Config.mk > +++ b/Config.mk > @@ -220,7 +220,8 @@ MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git > MINIOS_UPSTREAM_REVISION ?= 26ceb2daf95dd9e7fed9c83d36be3aaf1a0fa8a1 ... we use a hash here, for example, doesn't warrant ... > SEABIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/seabios.git > -SEABIOS_UPSTREAM_REVISION ?= rel-1.17.0 > +# rel-1.17.0 > +SEABIOS_UPSTREAM_REVISION ?= b52ca86e094d19b58e2304417787e96b940e39c6 ... the use here. IOW if this is to be pursued, more explanation is going to be necessary. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460904.1671776 (Exim 4.92) (envelope-from ) id 1xLGpF-0005GM-LO; Mon, 26 Oct 2026 09:17:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460904.1671776; Mon, 26 Oct 2026 09: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 1xLGpF-0005GF-Ir; Mon, 26 Oct 2026 09:17:05 +0000 Received: by outflank-mailman (input) for mailman id 1460904; Mon, 26 Oct 2026 09:17:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLGpE-0005G9-Nk for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:17:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGpD-004yPQ-TZ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:17:03 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1a88-e002-0a2a0a5209dd-0a2a4501c2e6-36 for ; Mon, 26 Oct 2026 10:17:03 +0100 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1a8e-5984-0a2a45010019-d1558035c5a6-3 for ; Mon, 26 Oct 2026 10:17:02 +0100 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a20a37703bso20802035e9.1 for ; Mon, 26 Oct 2026 02:17: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-4a35a0aa097sm199195505e9.3.2026.10.26.02.17.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:17: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=1793006222; x=1793611022; 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=pkYVOE+KTU5yhmG9VnOr3WKgKHikxZLRzv9/tv3cFiQ=; b=V2Z107F3LxYwWyKZWP3sBQk9SVgyHuiWb+zM3Ac1K69MDD2gA+DVTsWM/DvgdXe5EW 1TY1IPow0OhPtEWfTfUbHHKYODnTjWDak9+9fyEujim/Fcn2drP3+muDcbSyPRPXaLDZ raadnHo8bzvE0rwwR/6CcAuBjWPSbGfZPdf516aPtqjQZjnrABDOlERxCc+1CW08JywZ hJAeahPnLHizzjoAosszTraKagGPaB8ReTP+aifJJcAolD81ACG6DkZA04A0m15CmgnC 6d6wZgHUYlZILzFALHyRD4Htcd4cpHqb89oOxu9uhTVbcr131rdBZhHK5mJ7DltIXzPF NmPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793006222; x=1793611022; 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=pkYVOE+KTU5yhmG9VnOr3WKgKHikxZLRzv9/tv3cFiQ=; b=0ztCxS1m2uJfaCRpaIxbe7bR4APJswBI8PAYPTxNhjZKXkmcDRE8CXaFddGAyOSV+r it/hscWvBInmqwLnVpwC+VEi8ZZQYv+mREgsutjB4gTi2SvRwqTkpx9Ho8yIt4pqOIkE hUuEf8RT13nWUvE10RYFuh2dD6tPB8jS9CxFztYWrRPbdb4zjHxddhz1QCBq3UTp8CWS 0N06Rfo7dFm5WoQ+Af8Dz7koAlPBRxv+qsjWNRBzHwS+cVjtNCVc7kX5/FGKrogsoZdS ZUn2y1/rWkbcz4IiqXops02MR97pZoQ5Jl0+/H5GEAfZf0RGU9gt1Udm/rgpXlyHFMOE IXXA== X-Forwarded-Encrypted: i=1; AKwUvBwHXo/qqe6ltzWwt0SJj6/rdy4u5tLeQcFP9tc/lSh7iGEthrXyqfhFK7+28g1Y8fH/STxBvca2I1g=@lists.xenproject.org X-Gm-Message-State: AFq9FYL86NSyLxQI4bgGORaXRfTRlG2zLnNSfUBNardycqXpGQiWPO8p T7EpH8FCUnwGWHwtQxSDsGzUahG0ku4YeELbR/G4kVD4vhJTcmra0MvPixszsdLx4Q== X-Gm-Gg: AYBFou1n8FRrR3xS1v4O2rMtfDFiRgTymGSNccXlwV8qEh5UkvnmgwQQOVTa0kGBeG2 t8Ifvc/zhZcLPEhFqdLv1TS/sFWh1Kv1NemTYAqR0h5QFqUen8e10jXd//eRmpFwaAW+cax2+Co 9AKORc41SbBgBYw6rb67qwd05nkSE0n2U2+U2uR+FwQG7Sbav58rF49k1M3YfHtb0zQqQAc4reo ftjKJ+TnSnoS3msQNEmSzma/IeEACRe4XfPs8XPM0JQjP3Z+LSQ6I/3j8YiKVzUKKmsnSHof7mq eVsC2qPrCBOdBueVNshsonAOK0vaLrtff110AyXHXkAKOEaca5W2iqPwUUr4TQvYtbg/FmMvJR4 3JiPri56itiSXFL6d1Gfg1D5FlDSsOOQq8mclz1SPctbJWAuZmgVhXpWwIWwb94A6qfARLBndyI 2MV47vNzYQBuC+8OQbrhBetzCP0gFWgp13hB4m4wI21c1tTfcRHAzwAbs7ZA8Jw+gieslZtdZcr 6hiAzUWFIH7z/HOUwk7KiPn7DBs723/W2kvTFSkyJEwvLKMwJAzzDZ1obFM8C0Lo2GTA/p8qXhp zFVuBC972Xca42rvniObJyhRliq3pq6GEh77cXp7e6U= X-Received: by 2002:a05:600c:8183:b0:4a1:d893:263e with SMTP id 5b1f17b1804b1-4a35acaa170mr93744585e9.28.1793006221778; Mon, 26 Oct 2026 02:17:01 -0700 (PDT) Message-ID: <2d97c039-ac94-4504-86de-4a0b945f8b9c@suse.com> Date: Mon, 26 Oct 2026 10:17:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 4/6] arm/sysctl: Implement cpu hotplug ops To: Mykyta Poturai Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Teddy Astie , "Daniel P. Smith" , "xen-devel@lists.xenproject.org" References: <2fb71ea8cfe221f25b1dbbb50bdc5a74be09194c.1792480416.git.mykyta_poturai@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: <2fb71ea8cfe221f25b1dbbb50bdc5a74be09194c.1792480416.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1793006222-BE27A757-6DE1ECD9/10/78276251493 X-purgate-type: spam X-purgate-size: 543 On 20.10.2026 11:39, Mykyta Poturai wrote: > --- a/xen/arch/arm/smp.c > +++ b/xen/arch/arm/smp.c > @@ -44,6 +44,15 @@ void smp_send_call_function_mask(const cpumask_t *mask) > } > } > > +/* > + * We currently don't support SMT on ARM so we don't need any special logic for > + * CPU disabling > + */ > +bool arch_cpu_keep_online(unsigned int cpu) > +{ > + return true; > +} According to the Kconfig dependency, isn't this unreachable code when ARM && (HAS_ITS || TEE)? I.e. a new Misra rule 2.1 violation? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:17:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:17:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460912.1671787 (Exim 4.92) (envelope-from ) id 1xLGpz-0005nP-UO; Mon, 26 Oct 2026 09:17:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460912.1671787; Mon, 26 Oct 2026 09:17: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 1xLGpz-0005nI-Qu; Mon, 26 Oct 2026 09:17:51 +0000 Received: by outflank-mailman (input) for mailman id 1460912; Mon, 26 Oct 2026 09:17:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGpy-0005lg-Do for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:17:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGpx-00DLTX-Kh for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:17:49 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1aa7-8faa-0a2a0a5109dd-0a2a4508d8cc-42 for ; Mon, 26 Oct 2026 10:17:49 +0100 Received: from [40.93.198.68] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1abb-f659-0a2a45080019-285dc64436a3-3 for ; Mon, 26 Oct 2026 10:17:49 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by MN2PR03MB4959.namprd03.prod.outlook.com (2603:10b6:208:1a3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Mon, 26 Oct 2026 09:17:42 +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.0546.021; Mon, 26 Oct 2026 09:17: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=DMGHwWZY2vjnt+41DevG+x9kvEamZOWK18MG+vwjUPhDPkWbCFB8mr9spcxweeE4kMUxRa73WYzD9LMw7uAON3ZfRndd3DhCMtXv068hAVmxlhPriw2QaAck1KlkIm2xXmnVNyXRTc8J6V0pqqbC1C0Et4w6Zf7v4j4Q/9wzP82PCFyZqwlw4gN8uDXMIWYARkpln6pBTVylqRpl8BcBRmOjdgwnseTq7jkYoWEsIP1YJ5Wt7yr6ppJp4M2GDxztiakPbzRDGN9NZHoEAktJrFCEdVG/8m7VCy6wbhGa2KEcET30kaoupBNU7Vdc8FWvyZ9Feb5KGfzCNVi9yL9fJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E0wegR8SwtKYPW3eDFMZD1yep5qX9R/veXwzvzH8zwE=; b=Ytr2Sz62Ui0p0uDJcDsEvgIyfGtFQRzkETmsGyq2nMThCyThWf9FipU9EChVCYo8bH2tWP3N6G9QoljcpiCeh7Inx5lj40+g0b1vQi+Ublwd4tSjI2kFdy/NTws9vcGH1VHc8HLktOqghRUbShrMKaTs+CT3tHO2uBuKC0WxvFgAhoA1WUHDX7fTQT59+hwfijAQgOv57fds1J0DWJQwineMeewp23n2HmKMyHGRwFcGNYAqj8JX5+u/gZCafvjf9TUcGSpKM10PcQOmJir7x3tJrAOl1JtHB/6NEB67gTwbIFNVRCWdrWeFdN3IgJBGxWeIEBCeXwnsYiVJkq8cDA== 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=E0wegR8SwtKYPW3eDFMZD1yep5qX9R/veXwzvzH8zwE=; b=oLN56wbuWg9khY1LlgpuovE6Gj4ztdBnQTCUG6D8iAfL5a9sCzmvPXHID60pSO4fBqD+4VdiCdEbeBXuOy0thvwy3dkRfmm+TZQaB1RkwnR3/OuUeLioxH0ueLnxV9h1lAeoRH4s8cved42g9pDPfrx/4A7GIVOCi9hZ+dQG+0s= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 0/7] x86/kexec: Secure Boot support Date: Mon, 26 Oct 2026 09:20:10 +0000 Message-ID: <20261026092017.3880869-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0279.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37a::18) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|MN2PR03MB4959:EE_ X-MS-Office365-Filtering-Correlation-Id: c84c9cd0-f1ce-4469-73de-08df3341fc67 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|6133799003|18002099003|261022105027099003|261022075727099003|11063799006|261021123027099003|10067099003|261021121427099003|261009223027099003|261022115727099003|56012099006; X-Microsoft-Antispam-Message-Info: pGhNHBiLUhkzqaJrr9h1m1ChHrhMQrFze1UJ3x4GEDEWjaARzEvkR6QfpYzRwRaIzyg9kR6xrtDBOYcY1yywhqxZIWCvkLrC6c7YzRvHomaceqzKkHKWbnndYUXzRpruHN6aMQKTXArnHNihIA/lgqC3aXfwvUbd/EfSVvJz1Wxg8TkfHfxelIc4WNeHI/KZrlgba5NH9zcsbqpHDVgEAP+MvqCK5fSIf+gBAUuXGjCEcANTbdJmsgXtQz7qhEqzpOlfJJx+SzWGbYWteHP/zUO9CrkfbH8HT0W2+gqoyRAVkJm6BDxZYrD86dTP9T9vnKhpifvxBbeOdgsIKLqU7K0fP7WhEW19ssqUz0EvxOViRtdf85fMM4ZmSoWKQEnmljqdDK+o+7p4lw9mOKmMmq3zeBDu4+Q/GBj6JPDUMOQSap3Comz6I977W1dfwUcxoLz4CuOBhiW91vkm+sEhkRYPczmoigBVn3WmtEew1raichleKGAXTVxiaDajdEpDxgwVoK7Fw+T7UvE3VSFQ/tYlieWjQpvRUUJlgLWOmCumPUuiJooGrykBqw6etooHkb8y0XdalmPwwVmZzOE67xlxtQfUALYd9uWtXaErQtNgqFzI2g6z/WfLvIaUnEJ8HJjpfbSRA17vxbqXxCn9dEO71QMbQFCh8LHzfvuZhrg= 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)(23010399003)(366016)(376014)(1800799024)(6133799003)(18002099003)(261022105027099003)(261022075727099003)(11063799006)(261021123027099003)(10067099003)(261021121427099003)(261009223027099003)(261022115727099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?S9w9lmQOEBeSvXaCZK1x3IKP3QZAw+Cf73oNfx4Dj6ODyATbvrqD9TjwSj+T?= =?us-ascii?Q?cp/NrRYP30VfL3Rd4aOx91/XpcZItm8juxfxqrsf6ODDoYwvKnOpE9j/X/Y5?= =?us-ascii?Q?Q+FJ55EgczmmkQJ5HZqeTbW/AfUwZhQgWNnJHK4UCG/weFCO/h8M9c5GtV9b?= =?us-ascii?Q?DK4GEaQLU9+2RYsX+0AnM4PoTIAe1RifGKHoCQZoMn32R/pYShfubScn4mPt?= =?us-ascii?Q?OnyOz4b9rFOCvv+ENcqfxDFYhlIXXFOOIW3HaVr8clr6b5jeJM0apkoeWv2P?= =?us-ascii?Q?1frLX8BUDJRRNIE33DunUE4Pz515OLEG7b1o5/HqeUsn9sz90CYlGVRCz0w6?= =?us-ascii?Q?mp5IuKCLyLlGPyGfQwsV84Z9xp2/xd5Ieg85gLfU8dHa89TXFHj8QV+oaQ/F?= =?us-ascii?Q?WaYuMlPt79+YnAOteTpUqFSF327bLYeGWQjVGerjo2PIBNv+92j5uhnXP0ie?= =?us-ascii?Q?Tqgu2fEVALrN9jASfmXuywC5f0uc/lFUVosBoJcvTDpseyP3REUVTJ/LN9uN?= =?us-ascii?Q?AXWrfXN852kMgWhICFRZKxNO6tlSlL1Vp5oUVqEnEwr92GE/YeIOnau+T7HP?= =?us-ascii?Q?dVjyseXaqIUGk8NqIl4We1qXWD+RZyw/he5No1ezcOlTYqzPfRi0PVOrlXhW?= =?us-ascii?Q?42UznyyD77J4t6Zw46xTGsNgX6AeJmhHZWnvbUVf/qbW1nHvtjLhCqnjSGh2?= =?us-ascii?Q?4twb9nkieXsH0iDePJOQ7QDeuPm52yO7ktkMfyoc/BsDgQpfGYbuwieGjycQ?= =?us-ascii?Q?xxHSgeOXgOePaOdmyRP/cXEVF4lKOhEK+BrjLognRuLx3ql0naLdBBxFO+Im?= =?us-ascii?Q?3bVwPOKr63GUFdlABSM9CmAbkfvirrKAaKhpRjIGZ/5LCXGMNXb8ddpk4jMX?= =?us-ascii?Q?YmYwQBfPEFhI1l+91BecW5Aiw2nHddaIJhod1A4nS6rBtUuKvh0OggenUA/o?= =?us-ascii?Q?AewSrzXhgj4zLmV3324Zw+/moFkcgTGunMBky2cE+BmRuyzwDcq4qTYdOdo2?= =?us-ascii?Q?5uzgcdEnwyEhhZYtwRcwiQQ8o2bGvp8j83r1SU6quKTVCimRq9bsfOJ/RlQZ?= =?us-ascii?Q?rBdqd4OMYHPVl+9r7eLg+DWFjLYaxiC1dZNNbRoxIvLhPpju/TtPg4nrgPH3?= =?us-ascii?Q?8dDH6VkpF2NhBtuFNHjErpM6o+xZ81qQBv2TZpz/hev1mUbaxrM+H1jKgTUC?= =?us-ascii?Q?saO7U2qqp1AbpRz4IXPqbupsMNqyxIHhle+69DRA3InTV94kIIVJCeBe4syS?= =?us-ascii?Q?qd9jYamI6uAtrUG+fyQkp9KaL1UliIew71Fg6jtc+Ok3ihgGpXgd7+ht+TsT?= =?us-ascii?Q?728/2g8TPcfewSQ0OxyEyY5jAHyNo78eU+3Ul5FEH+xfPQwbqsnUvjTzP6uZ?= =?us-ascii?Q?xjq1EhEAfhaZ98HO55CpnE3k5ZmYLfzNJH4fMjwfxj6fmmjBnMNVej12ytzb?= =?us-ascii?Q?lnhZmQlJBs5C2fuWG4j1ra0xxg5CnpmOBsA1FjI6Ap9FWQxmokH2rVrckT4J?= =?us-ascii?Q?8RgQTv2ZfBs+XXQFgcHb0va+82Yv5xeWFUQC8svRv7u/pqJQIyD13P27eRQA?= =?us-ascii?Q?46rUkFocYFxeFa3w/iuz9TuJgj3ZcBv/tpb7v1xpVNgwswrWFrYr2KyJtnKd?= =?us-ascii?Q?1SU2KSwjt4gOQZLRpKQ7yguu04V5wTMCuDxiOtoEeJ/TXSNaruRGGDP8F0th?= =?us-ascii?Q?plChUvUPzx4eiNpHZCsY9BiVBX/yJv8N+otk//9OSiMYCpXVxnBUkR7op0BU?= =?us-ascii?Q?8o4TeyB7dA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c84c9cd0-f1ce-4469-73de-08df3341fc67 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:17:41.1268 (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: 1hrUHyPcl2KTvQUA7NDCJ8GfY36FnKP/Pn4eoWDHzDfH3fURKBvdLrMej9PWg949iIgCKkHS+PS55UfdoalLsw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB4959 X-purgate-ID: tlsNG-c1860d/1793006269-CC37587B-27991ABA/0/0 X-purgate-type: clean X-purgate-size: 1794 These changes allow loading and booting an EFI kexec crash kernel. For this new EFI kexec type, userspace won't provide purgatory code. Instead Xen jumps directly to the new kernel. Signature validation is done by the dom0 kernel. Xen then calculates a digest for all the segments stored in memory. This digest is verified again during execution. This digest check obviates the need for Xen to verify Secure Boot signatures directly. Changes in v3: - Review comments Changes in v2: - Addressed review comments for specific patches Kevin Lampis (2): x86/kexec: Pass boot params directly to new kernel x86/kexec: Zero GPRs before entering Ross Lagerwall (5): x86/kexec: add digest checks x86/kexec: rename setup_header to bzimage_header x86/kexec: add new struct kimage_segment x86/kexec: Support non-page-aligned kexec segments x86/kexec: Implement new EFI load type tools/libs/ctrl/xc_kexec.c | 2 +- xen/arch/x86/Makefile | 1 + xen/arch/x86/bzimage.c | 47 +---- xen/arch/x86/include/asm/bzimage.h | 44 +++++ xen/arch/x86/include/asm/kexec.h | 9 + xen/arch/x86/include/asm/machine_kexec.h | 2 +- xen/arch/x86/kexec.c | 58 +++++++ xen/arch/x86/machine_kexec.c | 3 +- xen/arch/x86/x86_64/kexec_reloc.S | 23 +++ xen/common/kexec.c | 38 ++++- xen/common/kimage.c | 208 ++++++++++++++++++----- xen/include/public/kexec.h | 12 +- xen/include/xen/kimage.h | 20 ++- 13 files changed, 367 insertions(+), 100 deletions(-) create mode 100644 xen/arch/x86/include/asm/kexec.h create mode 100644 xen/arch/x86/kexec.c -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:17:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:17:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460913.1671792 (Exim 4.92) (envelope-from ) id 1xLGq0-0005q2-6J; Mon, 26 Oct 2026 09:17:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460913.1671792; Mon, 26 Oct 2026 09: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 1xLGq0-0005ph-1B; Mon, 26 Oct 2026 09:17:52 +0000 Received: by outflank-mailman (input) for mailman id 1460913; Mon, 26 Oct 2026 09:17:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGpy-0005mO-No for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:17:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGpy-00DLTX-43 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:17:50 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1ab5-8faa-0a2a0a5109dd-0a2a450bda0a-32 for ; Mon, 26 Oct 2026 10:17:50 +0100 Received: from [40.107.208.60] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1abc-b7e8-0a2a450b0019-286bd03ca113-4 for ; Mon, 26 Oct 2026 10:17:49 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DS1PR03MB7991.namprd03.prod.outlook.com (2603:10b6:8:21b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 09:17: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%3]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 09:17: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=Ftd6RKBWpPbdcPEQji4cvv6NTbjMvdzMSXL20m+4/Yb5k3tjnOlvASIxdJHHoUYi4HyNQN3Uuu2AdqQi8w35ENxNoMlgSnuQxHu1RdleKNoJ03Y488+J+iCA7E3uibA1OO+obbs6nacD56XrXFQCAl/d2oFe17hVUcXeAZtJFhs53yWiYcBW7HRhHlbuh4cdofScqSuVdphTRZ4OTSuNVn2nBHBLmYSRB8kyKFRYiHF+HJNN3SB0UaZBcGZDCI4qIKHY3C0wgFRrd0Qg6xov1RVqrA50mYnPhJgxtYia2QFd5efRzMdP6FzLDOFSkD20pVTA4ILdqD9emKNN8bbspg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pQKpg0FcY1WqH3GQcUzAyEh301CnfBHGqKg1GHGRaso=; b=l276Z00JOMyY/9Kslas8U0/UW+kby5kyc5F/8/2DHyznsSVuy5/oAlQddfJfOY61XYHiB5L28a/oPiSk28j13deAKOfhgQs5fezE0UtsCnEciuNcl5P+d+3leQw+lUfcsRDCWe0HPSy2K8EIgu65NJNK3sacgBCS703/Yq947T8ninCZskUgmVd5Oj6Gj0K4a4r+GiD0DF2HyD3rH1vHwx2OlbV9RH7KZ7BL6STk9m94LaU2VsMi9UiW2TqTw3jqKI77QpzOQeWM/O9syGCZ4hX++rz05U9YPiMO26UvXedsaZD9nogIycTjtgEW+OK+ug4oJKX54CWDDEGac3ih5Q== 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=pQKpg0FcY1WqH3GQcUzAyEh301CnfBHGqKg1GHGRaso=; b=FR0JVMVBcW1Mox6XORTqjwFXEoMYqs//9VZuFhl1HORkkA92sQBySlzqqiBzlO8ZwhMmSR+hwkU97VCHHHt5F9M3ErvYuwlZo/niS9Gtus6TPk8OBCr9PwUbkLIgiKfCwW8q6mdxLZcyjnyNhuXur9go28I3AkmKUjqKcL/J1N4= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 1/7] x86/kexec: add digest checks Date: Mon, 26 Oct 2026 09:20:11 +0000 Message-ID: <20261026092017.3880869-2-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261026092017.3880869-1-kevin.lampis@citrix.com> References: <20261026092017.3880869-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0282.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37a::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_|DS1PR03MB7991:EE_ X-MS-Office365-Filtering-Correlation-Id: b3265369-4c26-4382-14e9-08df3341fee1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|261009223027099003|261022115727099003|261022075727099003|261022105027099003|261021121427099003|10067099003|56012099006|22082099003|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: rwUSjGn1RPLXyBX1QucTdJuurm18nPGWsZMDXXmbiOlSiNrlchiLKqov1byjUtCkih+M2MSaOygZcH38ruqSH0h9bEFr6o7Eozk0nP0j/3GkKwSm5m8FMgEH2IDGDSwuHQWl30VU0gos1+S78BE6zSYO9TYzxZuu076KcN4rP8kApwhZz0rCglYaL3QY9OldQUhJmRk8YNguVfppcVGR8tZ4hvD4/73Nv3/eitdMSt7uosJpeDKheQWHDOWUgwDD8cUya5H2Ahf+84zkLm4OhZOqPSKq6QD/8/yA8rvC06B/dsJfFhORsRcAPiHReFqHOMbYkoHlAqdStmIenSWLd3JStYAhO3LsssrYdt3/lBDv2nDFZqk6B8tJ3uFE5/wiVbut5TKXENViAPQccREYPvDbTSp81niexFv7PFEzp+lQf1EgTsYxOVOetJ4HTc+IckFZr5MdYejU1t7r9e2pP/brf6AqdXx5uJkoGrcaGrNTzUCQcVJBXartqs0XSWQeFK27u4BHS4e5ZJogtw/0Vl8WKnkJ2hGWrJymHQLFlW2xCNH8Tr+LoH/tujjUBwIVCDOiDppXxHLvqugxyD5bmElbgJqXN+LaMQz91q5/5+cbkVTdglS42/PvvjKGid5iTk9ve4Buj1cUdVNZseKIEaGpQUHTMppKuemiCphXaSU= 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)(23010399003)(376014)(366016)(1800799024)(261009223027099003)(261022115727099003)(261022075727099003)(261022105027099003)(261021121427099003)(10067099003)(56012099006)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Vf5PQnHcQpFn//LAq51jyZynHyIxgdpczVwiaoUhg63m5mdIX0DqULxTWxnE?= =?us-ascii?Q?TmsFTS8oChvRT6Cc47o7/Rn83E/VCXdK+0AMR57wFjY3CQog9mLFBFVtQP8M?= =?us-ascii?Q?UVfZDTRRTl9rJajHmHpUYUfFurdWzOFssySf2YQAD2q8/I1i3kpqs4t17IRn?= =?us-ascii?Q?DZleO4smgzUGDrVGocHq4/94H2IkyAeSBQ9PbNdnkcbOheK0P2DIdYTb6Aa2?= =?us-ascii?Q?l7bg+JXCtC+b6DiZgbIL5plUGuLlyg+cj5QOAuXyKEbXwN7dkRr8Aep96mji?= =?us-ascii?Q?sBsg62wYDkPdPn5OhVgq5qwi8tz6U2mJ1m2RUteCJhgOj+moB0Nk9ff4H1d4?= =?us-ascii?Q?fBoFvyPRrSckaoMsXo1wn8a+Hdekg0eI/cwWMCPzQEzlsaea+u9OmZD4alO1?= =?us-ascii?Q?5O6HEaw73ndLeI4VFTeLQ72KpVHBOocCDKoOKr15pdtK4+ZsebwBhdZsu4JA?= =?us-ascii?Q?9pq4Gg3FfSxSmKOg3X5C5pn4F1eN/ggp4Dwvh++9xbC3lEBi1lOYJx58uSLh?= =?us-ascii?Q?HL9MFMAGPrFdxhBMXAXu6+Wr04FUVL1cWLttGL3Hs6u+sTkCH7XP1qV2CKBB?= =?us-ascii?Q?ZMPQ/sLgC5ADYp01uOEXVt0hcLlJEsyTA8vaENdSzAZ1Iae9cTLrdh7Np4Jx?= =?us-ascii?Q?cx0rfAf3M+oWG9tEfWcAfFXJXN/KfwfZS/J2/UaSa5FNPaUPegd4VUv4T53J?= =?us-ascii?Q?GW2nA9C1WoO0LxiZL/oma+58YOTq64IQN+kR7GdL1Pi8pX31cdFSB75szaGh?= =?us-ascii?Q?gPdw1TsXwAi0vXR1fGBhubzkEeJjV6kC70QZej5Cj6llX4Ob63pKEvMYIiiJ?= =?us-ascii?Q?lEEZkepSgkfQai104wFUjnrvZ/eTYLKlyiUm81ruonKUi3xrWh68goZHPqs3?= =?us-ascii?Q?Y0KNPMvx0QitujjBtll8dbVHq91jtdGFiBRXqPbd+8sVGDFchDoYG+u/HrT0?= =?us-ascii?Q?M0ZTQw5e2PDVfGR1uFtnrqwVWltb3np1PIYxbYi1osI6t7udAZP56kiBWBqS?= =?us-ascii?Q?EZWFl374srBWeDB9Tbn1kHN2dg+13Ted8Co3G1WhTAnPCKA8bIi8JKFRr9vD?= =?us-ascii?Q?y4+oJ25pb9s4mHg62/m0xAMm4muzi68/W8a9cfujvFGxiXhrbpfLxRNMuM4L?= =?us-ascii?Q?Noe+jEoza9AMZZMIIhdL5XjLGak5xdoUvRkcFETST4k9i089Md13uVX4tnti?= =?us-ascii?Q?T6RtQ00BUMRQi7E4xy8LlPpT6bbOBHCaUco47XP8fKvpXW9gC0/59vEdrIE3?= =?us-ascii?Q?O2dpcfzAVkc7dzRKM0ZfOg7ku3a/0Z4rCe07whUsPz0fXeMjckxeDOpo8qYW?= =?us-ascii?Q?B9OdvwMpg4FfHGw0xSu8s7E7aMWfhpmbyIXRDuZUFtFjApjf046zdGKl8wOR?= =?us-ascii?Q?hYHwox2Fe/P/CG+9tZWXs8r3YqujPH9WaJIefe9Hqn43FFHYT5MozhQrSP3J?= =?us-ascii?Q?RKm413XFTY1k2Ye1/G9b4G67RIvTgPRcTdG8c86jxnCrwtEPclNmVWQeUBzs?= =?us-ascii?Q?fmPaBKpOQyoNfygqzFIiK3d+En8/uBeeHNwGmbXu8TZtVptOD6wlefyO1BlR?= =?us-ascii?Q?VMtHzVABu9KtTKrPRgQgh/QQGMJIm5SEBE0PgkMZO7qYO58SqXL9H77CGJiv?= =?us-ascii?Q?l98UJ6Fwi0HnW+9OqgrXdQHCJ//5G8wd5Js6AYH4G2yL3zhTtKCtHzV6Ro/Z?= =?us-ascii?Q?nvaA8xd4g5+bbopcfTd3UfoBylCwMD4EHq2Vz+QNyF+DM2FGoTaV1OHGqqUX?= =?us-ascii?Q?gim23lm9oA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3265369-4c26-4382-14e9-08df3341fee1 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:17:45.2637 (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: cL0gafFRrQTkKJg/sZtrIqGPiRgJClLgkcpmfmQpsT7okSx0YpBQO+zkV6vWRHTwEaBNXWktyRDM+SUYgtea5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS1PR03MB7991 X-purgate-ID: tlsNG-42698a/1793006270-2C59A9EA-077C22F3/0/0 X-purgate-type: clean X-purgate-size: 5624 From: Ross Lagerwall As part of the work to support UEFI Secure Boot we must ensure that the kexec image data has changed between loading and executing the image. However, this is also a good check to perform generally. During kexec load, calculate a digest over all the kexec segments. This digest is stored and verified again later prior to entering the image. Signed-off-by: Ross Lagerwall Signed-off-by: Kevin Lampis --- Changes in v3: - Reword the commit message to make it clear that digest checks are only part of the kexec strategy. Changes in v2: - Reword the commit message - Change the "kexec digest failed" error message - Remove the `!= 0` from the call to kimage_verify_digest() - Remove include sha2.h from kimage.h - Remove error checking from kimage_calc_one_digest() because map_domain_page() doesn't fail - Change kimage_calc_digest() to a void return too - Remove references to KIMAGE_SHA256_REGIONS It was a purgatory thing which is not used anymore - Fix style on `for ( s = 0; s < image->nr_segments; s++ ) {` - Add newlines and indentation to digest check fail message - Make kimage_verify_digest() a bool return value --- xen/common/kexec.c | 8 +++++ xen/common/kimage.c | 73 ++++++++++++++++++++++++++++++++++++++++ xen/include/xen/kimage.h | 6 ++++ 3 files changed, 87 insertions(+) diff --git a/xen/common/kexec.c b/xen/common/kexec.c index 8ccaef1e0258..68f4c2cb2671 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -389,6 +389,12 @@ void kexec_crash(enum crash_reason reason) if ( !test_bit(KEXEC_IMAGE_CRASH_BASE + pos, &kexec_flags) ) return; + if ( !kimage_verify_digest(kexec_image[KEXEC_IMAGE_CRASH_BASE + pos]) ) + { + printk(XENLOG_ERR "kexec digest failed, aborting kexec crash transfer\n"); + return; + } + kexecing = true; if ( kexec_common_shutdown() != 0 ) @@ -940,6 +946,8 @@ static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg) if ( ret < 0 ) goto error; + kimage_calc_digest(kimage, kimage->digest); + ret = kexec_load_slot(kimage); if ( ret < 0 ) goto error; diff --git a/xen/common/kimage.c b/xen/common/kimage.c index a0e4e67df7ee..6e009529ae01 100644 --- a/xen/common/kimage.c +++ b/xen/common/kimage.c @@ -818,6 +818,79 @@ int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, return result; } +static void kimage_calc_one_digest(struct sha2_256_state *ctx, + xen_kexec_segment_t *segment) +{ + paddr_t dest; + unsigned long sbytes; + + sbytes = segment->buf_size; + dest = segment->dest_maddr; + + while ( sbytes ) + { + unsigned long dest_mfn; + void *dest_va; + size_t schunk, dchunk; + + dest_mfn = dest >> PAGE_SHIFT; + + dchunk = PAGE_SIZE; + schunk = min(dchunk, sbytes); + + dest_va = map_domain_page(_mfn(dest_mfn)); + sha2_256_update(ctx, dest_va, schunk); + unmap_domain_page(dest_va); + + sbytes -= schunk; + dest += dchunk; + } +} + +void kimage_calc_digest(const struct kexec_image *image, + uint8_t digest[SHA2_256_DIGEST_SIZE]) +{ + struct sha2_256_state ctx; + unsigned int s; + + if ( image->type == KEXEC_TYPE_DEFAULT ) + { + /* TODO implement digest calculation for normal kexec */ + return; + } + + sha2_256_init(&ctx); + + for ( s = 0; s < image->nr_segments; s++ ) + kimage_calc_one_digest(&ctx, &image->segments[s]); + + sha2_256_final(&ctx, digest); +} + +bool kimage_verify_digest(const struct kexec_image *image) +{ + uint8_t digest[SHA2_256_DIGEST_SIZE]; + + if ( image->type == KEXEC_TYPE_DEFAULT ) + { + /* TODO implement digest check for normal kexec */ + return true; + } + + kimage_calc_digest(image, digest); + + if ( memcmp(digest, image->digest, sizeof(digest)) != 0 ) + { + printk(XENLOG_WARNING "kexec digest mismatch:\n" + " expected %" STR(SHA2_256_DIGEST_SIZE) "phN\n" + " got %" STR(SHA2_256_DIGEST_SIZE) "phN\n", + image->digest, digest); + return false; + } + + return true; +} + int kimage_load_segments(struct kexec_image *image) { int s; diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h index fccba1d88d5c..8ed89d4fa306 100644 --- a/xen/include/xen/kimage.h +++ b/xen/include/xen/kimage.h @@ -11,6 +11,7 @@ #include #include +#include #include #define KEXEC_SEGMENT_MAX 16 @@ -37,6 +38,8 @@ struct kexec_image { /* Address of next control page to allocate for crash kernels. */ paddr_t next_crash_page; + + uint8_t digest[SHA2_256_DIGEST_SIZE]; }; int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, @@ -52,6 +55,9 @@ mfn_t kimage_entry_mfn(kimage_entry_t *entry, bool compat); unsigned long kimage_entry_ind(kimage_entry_t *entry, bool compat); int kimage_build_ind(struct kexec_image *image, mfn_t ind_mfn, bool compat); +bool kimage_verify_digest(const struct kexec_image *image); +void kimage_calc_digest(const struct kexec_image *image, + uint8_t digest[SHA2_256_DIGEST_SIZE]); #endif /* __ASSEMBLER__ */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:18:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:18:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460915.1671805 (Exim 4.92) (envelope-from ) id 1xLGqA-0006M1-Fk; Mon, 26 Oct 2026 09:18:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460915.1671805; Mon, 26 Oct 2026 09:18: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 1xLGqA-0006Lp-B5; Mon, 26 Oct 2026 09:18:02 +0000 Received: by outflank-mailman (input) for mailman id 1460915; Mon, 26 Oct 2026 09:18:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGq8-0006Jt-Iy for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:18:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGq7-00FxFv-VJ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:17:59 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1abe-e002-0a2a0a5209dd-0a2a450290ba-24 for ; Mon, 26 Oct 2026 10:17:59 +0100 Received: from [52.101.201.53] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1ac5-6ca4-0a2a45020019-3465c9353e53-3 for ; Mon, 26 Oct 2026 10:17:58 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by EA3PR03MB455330.namprd03.prod.outlook.com (2603:10b6:303:30a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 09:17:55 +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.0546.021; Mon, 26 Oct 2026 09:17: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=GJoi/eX1kWY8BfQxEn3d8azvW2oeOiCBPUEEMQiTD4zgSKgeDZZ3MaR6uy+nGqIPjRF1somitiPF9mWohfFh5XAP87KeXtyYqTMqvLEOTOJ1IbgIHgM4Pg+MMgSVlhj/ikQiTAje6SZCHM0Evnt+hO1+1sPbdv1yirgdNiyBgG4q7d1mk4oVKWKCKQFJ8ASA9FqGF+61f6jXn59jiXJntqJn6pslJxLNDsr1FiKR5QB+tRijNkj0fzW9KvyDBBn6BJRKCz7IVMoSdP6xCdba6M6HcR53uctniD3365vPR628loFY6nU5mf1FnpCipcaBwucyFFAvMSqG6REyA/tvpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+bMm40wYYoEWuhZeXhJyKdJ2OStFlJlW/9XssLOh4h0=; b=MGJ2uqSVRLUHnoFxd9ATpJ4cvnfrif9ZomLfk7R7k4frA0zjUr7TJzTsIAcopYCIIejOKyThbi9+FvnSfGtypy0eEFH8AWhLkKm5C+NjWSmvpIkp1iUp8sTZdsKZ0XR5PnUsdzpHuLme1cTTi8WMV/zEYKzkipvoraubtcFCp/qS3cIF7Hzf3Af+63Q4HE2TmrLPQttuAns8DAEW3jxhZyO/fv+j+20ZY8zxK+IYtF2obX/GoIyafrhp4Qn7GEgJHs8b67/yMlue7OzU/PEeyzwZ3m8e0B93wST63ri/fTdLlePL5mh1ywIYoruhYZcZBuT3FOJXIQfky9Iq/64r3g== 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=+bMm40wYYoEWuhZeXhJyKdJ2OStFlJlW/9XssLOh4h0=; b=aLZlxuRVzdaXFFeTqI7GX+ZZQnUNEn58gxjoUj1P4DOECL47wIBsOAZZiwpc3bp/4IAEZsPh09psmRrp+h9SB5PZeTmWchv195+8mdHy22uujdI4TtHwIJaPZP1is3gLatzvNJ5qmzjPaCJIWcw4+gsQsI9bzM24oaSqqrL5ixU= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 3/7] x86/kexec: add new struct kimage_segment Date: Mon, 26 Oct 2026 09:20:13 +0000 Message-ID: <20261026092017.3880869-4-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261026092017.3880869-1-kevin.lampis@citrix.com> References: <20261026092017.3880869-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P302CA0010.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c2::18) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|EA3PR03MB455330:EE_ X-MS-Office365-Filtering-Correlation-Id: b99bf522-2d8d-491a-cfa1-08df33420455 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261022115727099003|261022075727099003|261021121427099003|261021123027099003|261022105027099003|260925021311599003|260925021911599003|260925022911599003|10067099003|56012099006|6133799003|22082099003|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: 372pl3QR3OGmH/U1pWDr6UQchMhv+I2kmseFuwe6xQR45d6RHiauQRHvJ3MQU0LK7kUk2Or1gFv/NhlauC8a9gTJPNhtvWk+ouBN2v2ETrdIWDZzR+42xcvkr7GkGLfz933ezu0wzShOJTakSgF8kIs4fCHv6zFjHwvqtnQEkzPtTLH2XfJYDtUg2Jd153sQx4eA9hCP+2MORcnkcf8JQ98Kobvv9DS0zUlr6HjQcy8QdwVCRyz6N+CrAkml8UdXrJoO92POfVl579wHJltg8aKYzIQoVR7LET2FVyseGpZXfBFLNa73vQcZrJ8IbK+PRunmVGxfV9Lc+mUoJDXqIh6eb9e6nokmVogtC5vuxK2h7YGCx6z5dsCspG6dsvfT/4keSPt2Sec0WSt+eyK+n2xmKizqr5VNBs3QDwTBwdVKwl98G9HwUgjKq6ikbjOaWzA3E5FdzUv0ypJcfORcVG65ASZeSCjs+wPmGB+G5yAXgXyt3Bz6M5aVmO285gsJpRMd/ZUGy8rnzWMGkFRv/aOfCkbIRhVlpmTrOa8WSdFVG/bWlzPH68/hMJc0MJDtEBlhqeCqk3QvklzqLNzlobQDGC0xxxu2kxQsESb1WvTEpTq2L79KdH4PuaH1dFmnuvgqX5gZEvMbk8DZNFhSFXs8ubKLpzeuNu/Pabw3vrg= 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)(23010399003)(1800799024)(376014)(261009223027099003)(261022115727099003)(261022075727099003)(261021121427099003)(261021123027099003)(261022105027099003)(260925021311599003)(260925021911599003)(260925022911599003)(10067099003)(56012099006)(6133799003)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?0dUzME5YYoz2Lebs8i+0URyr4B5kEJq9KEoaV25Z4J37kW5sewraC5L9Voj6?= =?us-ascii?Q?g5PJeV/SVzc4v6A+rdHFEKcDccLXXw2NPPeDnRke2BbHZsacWvAcFy+DR9MC?= =?us-ascii?Q?GkNES8aUa/xxokcFwwtt19CKObhuiuZwOFc3NOnWcLb6VKBHbyAwk2s8a1it?= =?us-ascii?Q?zJMw2db4Jgkvw9LYHR7hyOjXMwAiAA3CuT5bg4CVEAhRD/aLzpdM+fetsKfK?= =?us-ascii?Q?Vey+QdRok9rKIbo1DatPhM8N5sjMG8UbawdzaP/gUK36JMGB9u7ChcHqMUZi?= =?us-ascii?Q?Eo/rvYJ+BRIre9pFb8/UdVr6dBXZ7lV5HPmSJLjWi4+00g6RvNSRuLI4DS89?= =?us-ascii?Q?rrvwIPZxIGFquUyw0cVkPAcWXzPSJVtHwqi0WOOxCB6pw2n9r44OgueD0Zjc?= =?us-ascii?Q?GhGsQ21JbjmHn54ixe5E2Ks87HOAWlUjJkB1RrP/cgD8kEcxNMVYB9d2uhHr?= =?us-ascii?Q?W1PZCee6yPk8LBdYvKshQFuA5dToYyqd78j2gMM98TbGGd6TypQmi67mdTtN?= =?us-ascii?Q?Tk1pfV+cLCmJfYy0ZmGkqajjXKLm1FecpcnJivBHycNVPd/lowIPzgb92U7B?= =?us-ascii?Q?FnLk7bMzaMl5nnkKU+FSCNY9ozStWc2rGWvVcGFd7Cnz86VtXOor8UcRq9Ow?= =?us-ascii?Q?/PwGqIoXrqPoCBkcuYUYTwOR4aoxMzXdqmBz1/7BTEQCdW79QXdYPGLlUQDp?= =?us-ascii?Q?efWXkS/opUovB8jeI0hz8nPGhifE1b7zl8TUuudalaZTuiyNZpRVT6VHqpBT?= =?us-ascii?Q?NWyZ3yfQNd+zsVEd7/VSMJF1QACO9cOanvGhI2WAyqD5/KkoFUyqWPI8eai4?= =?us-ascii?Q?YKD3kBrMoV3KvJwCI5fWJ1P6Ye5ay+cn2U/G3+o41ddPa0V/r/ylr+Y/Sdxo?= =?us-ascii?Q?GICbxYz49MirsfVmlEfNfM72Tre/E/0K7Qtl1hJPs7ton/9NLSs0MaWnjs2j?= =?us-ascii?Q?dAxEoHHag9psnHxSEx6bU+Vy7LIbOk07EjXE6cRaq9R1Gzpz/m1Ni+g2bxd3?= =?us-ascii?Q?Vt5DuE6FFv+FsaB4RjrseGewrVuoQZQvax7SKjAokfAdKuJa+NKKWkGxP/SP?= =?us-ascii?Q?Izq0rtG1btD2ezierVM67bsXPJy5Ya7xNtLPVHmSWT7xfLq7i/kMlatuGKcA?= =?us-ascii?Q?8GjWA4uKz/bMF4wLLC5AnqzyRDmRaNdtk49aAQ7eUmFmer9VYJPNSVewkFST?= =?us-ascii?Q?DM0bGWwAc8Q1lLDJ4/MDy1uOdRoKyKgQgDg7QCWaSN0L+sRm4MlwfV6vLrYE?= =?us-ascii?Q?mnLJhW0AxVqdEe73W9FBSe/aOv7p949BuwFv946EWpUsCky9vh4XIxC9QrHm?= =?us-ascii?Q?5NhIXmOVcYyzY3RwHyAJprrxUyLQdfGG4D7qVb3HM5b6AZE22TPm+co5hqCW?= =?us-ascii?Q?z0xjezdKQlCwJptGOYJ5u0kNnLmiBzsSj0A7teBdww7r4/xXiJVLfBeypMtN?= =?us-ascii?Q?b2Ki/JmeY7TkoUj0iNLnZ7hJ7hO4p2Xo0Z85axBToEiITZDSfqD2nRmarS8v?= =?us-ascii?Q?vMaRnF4F1by2X7AzrK/bsJyT+uhSER4UL17GeqXqNIkde1bYztIL1Cu3UhoF?= =?us-ascii?Q?JjDIc3ooEx5T8DJdox+vgst2UNBDNXeqcIUthUd3XynNAwr/bBKTUc476n0V?= =?us-ascii?Q?QPHO80cpH20go5EF3I5fyIsDAU3+CWl7A7X6v6M0W7Ro5EIKKd4vT8V3Et9Y?= =?us-ascii?Q?PiJlLwXWLp91lWfVCUzceVaTrttCWXhzhC4YJIQJQskprwf7gcUM1Po/ax5w?= =?us-ascii?Q?8zHlkZSUpw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b99bf522-2d8d-491a-cfa1-08df33420455 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:17:54.4210 (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: 9bqT0SHUb1UI1kQuN2uQ+yJSpUK5dyR42/94Wu7w434YrGkGab56Mne0GKcBZfy738KIdueTM4Y93Au/YCIbaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: EA3PR03MB455330 X-purgate-ID: tlsNG-720697/1793006279-F20A82AC-3BE05A78/0/0 X-purgate-type: clean X-purgate-size: 8217 From: Ross Lagerwall New struct for internal use because Secure Boot code needs to add an extra field in a future patch. Signed-off-by: Ross Lagerwall Signed-off-by: Kevin Lampis --- Changes in v3: - kexec_load: move variable `i` into loop scope - kexec_load: Add blank line after tmp_seg declaration - kexec_load: Don't initialise tmp_seg - (Jan) I decided not to change uint64_t to size_t/paddr_t because it would require pulling in more headers and I don't want to add more complexity here. Changes in v2: - Read into a local xen_kexec_segment_t variable and fill in segments[i] manually instead of casting from a different sized type - Remove union and _pad from new `struct kimage_segment` type - Swap xen_kexec_segment_t to struct kimage_segment in separate patch --- xen/common/kexec.c | 19 ++++++++++++++----- xen/common/kimage.c | 25 +++++++++++++------------ xen/include/xen/kimage.h | 11 +++++++++-- 3 files changed, 36 insertions(+), 19 deletions(-) diff --git a/xen/common/kexec.c b/xen/common/kexec.c index 68f4c2cb2671..c92c464fe0ec 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -917,7 +917,7 @@ static int kexec_load_slot(struct kexec_image *kimage) static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg) { xen_kexec_load_t load; - xen_kexec_segment_t *segments; + struct kimage_segment *segments; struct kexec_image *kimage = NULL; int ret; @@ -927,14 +927,23 @@ static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg) if ( load.nr_segments >= KEXEC_SEGMENT_MAX ) return -EINVAL; - segments = xmalloc_array(xen_kexec_segment_t, load.nr_segments); + segments = xmalloc_array(struct kimage_segment, load.nr_segments); if ( segments == NULL ) return -ENOMEM; - if ( copy_from_guest(segments, load.segments.h, load.nr_segments) ) + for ( unsigned int i = 0; i < load.nr_segments; i++ ) { - ret = -EFAULT; - goto error; + xen_kexec_segment_t tmp_seg; + + if ( copy_from_guest_offset(&tmp_seg, load.segments.h, i, 1) ) + { + ret = -EFAULT; + goto error; + } + segments[i].h = tmp_seg.buf.h; + segments[i].buf_size = tmp_seg.buf_size; + segments[i].dest_maddr = tmp_seg.dest_maddr; + segments[i].dest_size = tmp_seg.dest_size; } ret = kimage_alloc(&kimage, load.type, load.arch, load.entry_maddr, diff --git a/xen/common/kimage.c b/xen/common/kimage.c index 6e009529ae01..dc4730622371 100644 --- a/xen/common/kimage.c +++ b/xen/common/kimage.c @@ -81,7 +81,7 @@ static struct page_info *kimage_alloc_zeroed_page(unsigned memflags) static int do_kimage_alloc(struct kexec_image **rimage, paddr_t entry, unsigned long nr_segments, - xen_kexec_segment_t *segments, uint8_t type) + struct kimage_segment *segments, uint8_t type) { struct kexec_image *image; unsigned long i; @@ -206,7 +206,7 @@ out: static int kimage_normal_alloc(struct kexec_image **rimage, paddr_t entry, unsigned long nr_segments, - xen_kexec_segment_t *segments) + struct kimage_segment *segments) { return do_kimage_alloc(rimage, entry, nr_segments, segments, KEXEC_TYPE_DEFAULT); @@ -214,7 +214,7 @@ static int kimage_normal_alloc(struct kexec_image **rimage, paddr_t entry, static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry, unsigned long nr_segments, - xen_kexec_segment_t *segments) + struct kimage_segment *segments) { unsigned long i; @@ -236,7 +236,7 @@ static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry, { paddr_t mstart, mend; - if ( guest_handle_is_null(segments[i].buf.h) ) + if ( guest_handle_is_null(segments[i].h) ) continue; mstart = segments[i].dest_maddr; @@ -664,7 +664,7 @@ found: } static int kimage_load_normal_segment(struct kexec_image *image, - xen_kexec_segment_t *segment) + struct kimage_segment *segment) { unsigned long to_copy; unsigned long src_offset; @@ -698,7 +698,7 @@ static int kimage_load_normal_segment(struct kexec_image *image, return ret; dest_va = __map_domain_page(page); - ret = copy_from_guest_offset(dest_va, segment->buf.h, src_offset, size); + ret = copy_from_guest_offset(dest_va, segment->h, src_offset, size); unmap_domain_page(dest_va); if ( ret ) return -EFAULT; @@ -717,7 +717,7 @@ static int kimage_load_normal_segment(struct kexec_image *image, } static int kimage_load_crash_segment(struct kexec_image *image, - xen_kexec_segment_t *segment) + struct kimage_segment *segment) { /* * For crash dumps kernels we simply copy the data from user space @@ -747,7 +747,7 @@ static int kimage_load_crash_segment(struct kexec_image *image, if ( !dest_va ) return -EINVAL; - ret = copy_from_guest_offset(dest_va, segment->buf.h, src_offset, schunk); + ret = copy_from_guest_offset(dest_va, segment->h, src_offset, schunk); memset(dest_va + schunk, 0, dchunk - schunk); unmap_domain_page(dest_va); @@ -763,12 +763,13 @@ static int kimage_load_crash_segment(struct kexec_image *image, return 0; } -static int kimage_load_segment(struct kexec_image *image, xen_kexec_segment_t *segment) +static int kimage_load_segment(struct kexec_image *image, + struct kimage_segment *segment) { int result = -ENOMEM; paddr_t addr; - if ( !guest_handle_is_null(segment->buf.h) ) + if ( !guest_handle_is_null(segment->h) ) { switch ( image->type ) { @@ -794,7 +795,7 @@ static int kimage_load_segment(struct kexec_image *image, xen_kexec_segment_t *s int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, uint64_t entry_maddr, - uint32_t nr_segments, xen_kexec_segment_t *segment) + uint32_t nr_segments, struct kimage_segment *segment) { int result; @@ -819,7 +820,7 @@ int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, } static void kimage_calc_one_digest(struct sha2_256_state *ctx, - xen_kexec_segment_t *segment) + struct kimage_segment *segment) { paddr_t dest; unsigned long sbytes; diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h index 8ed89d4fa306..0841b6f32114 100644 --- a/xen/include/xen/kimage.h +++ b/xen/include/xen/kimage.h @@ -18,12 +18,19 @@ typedef paddr_t kimage_entry_t; +struct kimage_segment { + XEN_GUEST_HANDLE(const_void) h; + uint64_t buf_size; + uint64_t dest_maddr; + uint64_t dest_size; +}; + struct kexec_image { uint8_t type; uint16_t arch; uint64_t entry_maddr; uint32_t nr_segments; - xen_kexec_segment_t *segments; + struct kimage_segment *segments; kimage_entry_t head; struct page_info *entry_page; @@ -44,7 +51,7 @@ struct kexec_image { int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, uint64_t entry_maddr, - uint32_t nr_segments, xen_kexec_segment_t *segment); + uint32_t nr_segments, struct kimage_segment *segment); void kimage_free(struct kexec_image *image); int kimage_load_segments(struct kexec_image *image); struct page_info *kimage_alloc_control_page(struct kexec_image *image, -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:18:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:18:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460917.1671812 (Exim 4.92) (envelope-from ) id 1xLGqC-0006as-LG; Mon, 26 Oct 2026 09:18:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460917.1671812; Mon, 26 Oct 2026 09: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 1xLGqC-0006al-IZ; Mon, 26 Oct 2026 09:18:04 +0000 Received: by outflank-mailman (input) for mailman id 1460917; Mon, 26 Oct 2026 09:18:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGqA-0006M6-Iv for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:18:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGq9-00DLXQ-W4 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:18:02 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1ac8-8faa-0a2a0a5109dd-0a2a450b96aa-6 for ; Mon, 26 Oct 2026 10:18:01 +0100 Received: from [52.101.56.3] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1ac8-b7e8-0a2a450b0019-346538035adb-3 for ; Mon, 26 Oct 2026 10:18:01 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DS6PR03MB967558.namprd03.prod.outlook.com (2603:10b6:8:4f7::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 09:17:59 +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.0546.021; Mon, 26 Oct 2026 09:17: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=U5VRO6JhTSI2dpqi03AOtjhidklWhYKxNjKwWX5BsIwer0n3mKDFHJi9qAZGY0g8OWqD0UFK/34nL+6lXYLcYgmYARPHtdsesJs0R9bEbuzSzaGQ1dzHQHOaZmgf7ToWtdr3V0w1F1mCyNq9KixPdvtdHVYJW0U2V8nyFqJ85EPXcAxG3+NMzCQpRmediisVFAhr/FToViurBm5HSkef4Izi5gEYJLnuaO/RC4Z2AOhQjQVMEDNx94t+vXo/xru0sLfV3rt41Chtr7ZYT/7pceXIpCt6vxzBaJaIBoPun6dKr/tiymRbnOvZq/2uc264+UChG8RMdiGJXD9hbYtwmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HtMBovw2cKtncPnk+tv7LyxgTHciKbQm4Vgw2i66//g=; b=nX+Lxo/skooN6MWpRP//ReAVrLW3xmbxlg5obCBPlXcLx9YKxANX08ikH2npsy9LGReM83yiX2yD7LKo4l6lKix7BWrUvFXcAFwjTie8YpvoLD1XjAKCRCi1LWLWLJ8mlOldAtxmLgz+LLzSrRlRo0uz0FuW+P2lZSm6aIyRpNwlh0H9mAVTjsELmmToyzr9whR3fByWt0SYOnP3U8+YYRPo9ixEx9Ub1vNsr9QE/xphlgmQFbstI/Gmtig5rNWaUChZ5vn/Q1bCepOCUJ6v7XFvDAP2yUdLF86QbIG+PsnQf3eUsguiDC/c5eqSrLv8Cno8yWY9woik0omxsvkvdA== 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=HtMBovw2cKtncPnk+tv7LyxgTHciKbQm4Vgw2i66//g=; b=rrpszTp1AnP1OAVtA/99b2TfitS2q82igub+6kvn15bUTnnr59r+4+9TT5cA+hicZAogasQUe8LXlq5aFZnlVrHBo4P8YC/L47gin52S54AfqGke4RnNtJb8NHC5/6JBC2Xw+lF+T3o86TmI9tHrbvH7xC5lLikD1nlHcx9hvMk= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 4/7] x86/kexec: Support non-page-aligned kexec segments Date: Mon, 26 Oct 2026 09:20:14 +0000 Message-ID: <20261026092017.3880869-5-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261026092017.3880869-1-kevin.lampis@citrix.com> References: <20261026092017.3880869-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P302CA0013.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c2::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_|DS6PR03MB967558:EE_ X-MS-Office365-Filtering-Correlation-Id: 8f95bacb-b4c3-44e2-8aa0-08df334206e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|6133799003|10067099003|18002099003|22082099003|56012099006|11063799006|261021123027099003|261009223027099003|261022105027099003|261022115727099003|261022075727099003|261021121427099003|260925022911599003|260925021911599003|260925021311599003; X-Microsoft-Antispam-Message-Info: VOSZ+7le3qgaVOs/WCZ5SJMDQDA9oLOcW2qF+4tPfm+rKv+dVeQq59XDfX5vl2eQjyXUcs83zXSd/7cnMAKBN/QhTxgjIIusPbM2g06IJiSDkr1+MbVB04AFm6OSLJ4SorZlccY4oH0ZT54N6SAjHXBA2ODnZi55UgqS7YAfmFxHDhMjiVvcagoOAsNKkXeuSi8+FUzG3Iqqskw8kVHkZ8eXb+yp+feydSPqzc6kLKqO1+ZohwN4tiG3lP+jBJvkqdzu1a0WbkIkAWxZEhC7USSXp/zOKBR0VOXKwN0jODNe/NNa127C6Myl9UtuhBrBQ8MFgUNg4hNJJrLDDEQnXzEnueQBunqT+D4WwYyDubqqf8Gm9Fbtb52SrJb3x4SD+/Swi8nAhLCDrtfahcjf/WX63dZ6E8QabOWbkA8gh6XqlJm5HfuqYW6ayB4/o8LfiAJjHa/Kk5pf4YwqKqQSBsFuCL9D/Ovh9w1Cts11q2unW2Bj50MjYZHbBgKxdszc9Sykm8Zh1m4PFV2OFdn1LKCyUGbRvaVs0Ud4jyCZtuL3Mbym/4TNJU+ddVH9PYeiJLXC9pCWhz41MogorIN7oF4JfJ0aDJmiM/6TUgXHxtQBqSDB1ytYNdOVKyiXiQHlEyGerB3LWSRsZgmdmQve3ByFLOZLSVBuN8u0mpuZK4I= 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)(376014)(23010399003)(6133799003)(10067099003)(18002099003)(22082099003)(56012099006)(11063799006)(261021123027099003)(261009223027099003)(261022105027099003)(261022115727099003)(261022075727099003)(261021121427099003)(260925022911599003)(260925021911599003)(260925021311599003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ASqu1EPXzKyu9HvKdZfCuiB7K+LUF5Nmqcu4MPXB46RRKO4CmwvZbmrYUzu3?= =?us-ascii?Q?K40Ql4EFTYpUbT6h54SLIMfj+xUrpEYCOg2AjbmnwU1YogWAw4Y/9qT3rWZ2?= =?us-ascii?Q?TRepmtKHxuvX3cAKlX1n3bxiG24lQq4i6BB3GYsmtp1eb2r16rCV7Qm755y/?= =?us-ascii?Q?bnXcLdzA2HCuyl+bzMuzVEgzOOhAMu4Bb1MXfNdCltXjPLKzj+PVZLCxm5N7?= =?us-ascii?Q?NE2r0NGw97MiXJ1gxFBe8V7dka80E8R/sbxGfhiWDtta+wuX7l7QYgni/c4T?= =?us-ascii?Q?+mmOPx0RP6CggVfDQPZb1Eq8BKeL2pc+LbRIb1ymFCxBjBLJWiUHHIH8aSxr?= =?us-ascii?Q?zHsmdNCjxhSxB9WFJYo89D5kToudt5lAM8G2Z9YdDJOSjHxIl1rIpXuJfpio?= =?us-ascii?Q?HV+fJdEkVD+YGXCpIGmbTNxxd4BX3arMdlRrrWmpEkBiFVxtncrs6D2y8ZV9?= =?us-ascii?Q?EUBcxkkEdkRwzwnCwCX7VC+6MCvJUnadvHEAtRlcCKFaN1eC+ZQZUCkHFXYp?= =?us-ascii?Q?HvfKYl2TqGqr0CJjWZwCApCnnP6QKYzlnFI4U5BacH5suVNL8s2LBU7FDBIG?= =?us-ascii?Q?T4yxXdsIARfs4UBp4oiyfne6FDAeAjxsJOedN2VX7kRv5UyBm7NLsFtGvgjC?= =?us-ascii?Q?8VWJ6MvJohDzJQ5S0keA7E1IsGdJihRm7/WmhARqU8L+FwnI8HfITY27WQKN?= =?us-ascii?Q?mO2GY7OApPaqayYw6G1gZr5SClbbS/9FRcYwG6WdGaLfhDgYYh85urMbDgPs?= =?us-ascii?Q?e6YfN6V3uxMW8aGcPyNjr5ldoeuJtLL57zKT7RmYBf2GPOjh4YcWPUfhF6v8?= =?us-ascii?Q?xUr3apgzAsPY3i+nB+oJEGE2BQlFitiQvJFlVfunnzVkIJ7U3VxasouNqkhH?= =?us-ascii?Q?ed8hW2de0g/d50hDoTVuDEyz3UDDnFDFdH+bXOsAhSY+UbuMQ7b9yExs1uXO?= =?us-ascii?Q?JrLf53NluQ5URPDogCdtswNMpHDHUWHi+0895tsk53VH7QFz9P8tOHd7Hnpz?= =?us-ascii?Q?HsIFgrXyp0hWB0j6F39AGJUFJOkawtoD+rICtwrWDK7JxWphHC8VSCuj8sPv?= =?us-ascii?Q?1Z2OgZKkmK2KjFUO8gwBWMJ7r3oiwEb5rfaZCnlO8yKhY8f8UBVjHvc32WM9?= =?us-ascii?Q?EldkReMCzxKuujK7tPoMVAI/ajyjQnydk+Wo/ADF5Ty+OVd1nnXXgt5rRBZz?= =?us-ascii?Q?mI+1SZEAZ/7HOXAWCcQmrZ8nJkGn3ZO55A4OhJXto9+RydAyNpWK4a1OCuIN?= =?us-ascii?Q?b/Jx19nexqTgVmOFcu+kL+W+g/HzCopVsvA/JSxB3+bkVtTWO+wxjJN9mC11?= =?us-ascii?Q?iNxzO2VoPL9oAcga9yvnIUuW0hAwGotMhma7IHEKlJwDO1kuefwnFrGj4Z3V?= =?us-ascii?Q?ZY3zR80Yu4JoUCueHNU3RRc3piNcYOrgidYSchJw9dzDvHTRWjGCtKX1E2Wy?= =?us-ascii?Q?esxBk1M4Y/j1IoNZR/1Rczs7L7uf9we5A3hrwJzZMGsmJgus4PWSY5aWQyZ1?= =?us-ascii?Q?VTi8jWORPttlNU0u8/GFPaXIpWZXK2Wzn6jaFhH+Wr9mfY6SNYrYc3J4lU4b?= =?us-ascii?Q?Soswww7JsnYQE5Y+S+MRRqI1K85Bxu41edKxPpNRi/yzLhzVTMV5fpetisv5?= =?us-ascii?Q?GCEjM0EUhC3dba2M/4dP9scUxzIvuUQp1ACCnzydmUlOq//fMh8jrc9U7xEt?= =?us-ascii?Q?jqH1SRAi4isRVfpfe5RCpXRyAP2pwui0A4PpZAFsFLbNkEZd9gsEtXTifvMy?= =?us-ascii?Q?esLEk+3K/Q=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f95bacb-b4c3-44e2-8aa0-08df334206e1 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:17:58.7044 (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: yiTDrCkI/FSbQPHwVsQcenu/5JDqMPApx2YKAMUzDkn9n8L8ZdibOs9wD9g/jbm8LePiNvtD56W68VM2hBkM+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS6PR03MB967558 X-purgate-ID: tlsNG-42698a/1793006281-AAAD89EA-FC1C4B6A/0/0 X-purgate-type: clean X-purgate-size: 4673 From: Ross Lagerwall With Secure Boot, userspace passes in the entire kernel loaded for verification purposes. However, the kernel's startup32 function needs to be aligned (e.g. to 16 MiB) and this results in the start of the segment not being page-aligned (depending on where the startup32 function lands in the kernel binary). Relax this restriction in Xen to support this use case. Signed-off-by: Ross Lagerwall Signed-off-by: Kevin Lampis --- Changes in v3: - No changes Changes in v2: - Remove error handling around map_domain_page because it doesn't fail --- xen/common/kimage.c | 47 +++++++++++++++++++++++++++++++--------- xen/include/xen/kimage.h | 1 + 2 files changed, 38 insertions(+), 10 deletions(-) diff --git a/xen/common/kimage.c b/xen/common/kimage.c index dc4730622371..d4a695a2bdb9 100644 --- a/xen/common/kimage.c +++ b/xen/common/kimage.c @@ -725,12 +725,14 @@ static int kimage_load_crash_segment(struct kexec_image *image, */ paddr_t dest; unsigned long sbytes, dbytes; + unsigned int dest_offset; int ret = 0; unsigned long src_offset = 0; sbytes = segment->buf_size; dbytes = segment->dest_size; dest = segment->dest_maddr; + dest_offset = segment->dest_offset; while ( dbytes ) { @@ -740,24 +742,26 @@ static int kimage_load_crash_segment(struct kexec_image *image, dest_mfn = dest >> PAGE_SHIFT; - dchunk = PAGE_SIZE; + dchunk = PAGE_SIZE - dest_offset; schunk = min(dchunk, sbytes); dest_va = map_domain_page(_mfn(dest_mfn)); - if ( !dest_va ) - return -EINVAL; - ret = copy_from_guest_offset(dest_va, segment->h, src_offset, schunk); - memset(dest_va + schunk, 0, dchunk - schunk); + if ( dest_offset ) + memset(dest_va, 0, dest_offset); + ret = copy_from_guest_offset(dest_va + dest_offset, segment->h, + src_offset, schunk); + memset(dest_va + dest_offset + schunk, 0, dchunk - schunk); unmap_domain_page(dest_va); if ( ret ) return -EFAULT; - dbytes -= dchunk; + dbytes -= dchunk + dest_offset; sbytes -= schunk; - dest += dchunk; + dest += dchunk + dest_offset; src_offset += schunk; + dest_offset = 0; } return 0; @@ -798,6 +802,26 @@ int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, uint32_t nr_segments, struct kimage_segment *segment) { int result; + unsigned int i; + + for ( i = 0; i < nr_segments; i++ ) + { + paddr_t mend; + + /* + * Stash the destination offset-in-page for use when copying the + * buffer later. + */ + segment[i].dest_offset = PAGE_OFFSET(segment[i].dest_maddr); + + /* + * Align down the start address to page size and align up the end + * address to page size. + */ + mend = segment[i].dest_maddr + segment[i].dest_size; + segment[i].dest_maddr &= PAGE_MASK; + segment[i].dest_size = ROUNDUP(mend, PAGE_SIZE) - segment[i].dest_maddr; + } switch( type ) { @@ -824,9 +848,11 @@ static void kimage_calc_one_digest(struct sha2_256_state *ctx, { paddr_t dest; unsigned long sbytes; + unsigned int dest_offset; sbytes = segment->buf_size; dest = segment->dest_maddr; + dest_offset = segment->dest_offset; while ( sbytes ) { @@ -836,15 +862,16 @@ static void kimage_calc_one_digest(struct sha2_256_state *ctx, dest_mfn = dest >> PAGE_SHIFT; - dchunk = PAGE_SIZE; + dchunk = PAGE_SIZE - dest_offset; schunk = min(dchunk, sbytes); dest_va = map_domain_page(_mfn(dest_mfn)); - sha2_256_update(ctx, dest_va, schunk); + sha2_256_update(ctx, dest_va + dest_offset, schunk); unmap_domain_page(dest_va); sbytes -= schunk; - dest += dchunk; + dest += dchunk + dest_offset; + dest_offset = 0; } } diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h index 0841b6f32114..86250f29394e 100644 --- a/xen/include/xen/kimage.h +++ b/xen/include/xen/kimage.h @@ -23,6 +23,7 @@ struct kimage_segment { uint64_t buf_size; uint64_t dest_maddr; uint64_t dest_size; + unsigned int dest_offset; }; struct kexec_image { -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:18:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:18:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460920.1671822 (Exim 4.92) (envelope-from ) id 1xLGqM-00074I-19; Mon, 26 Oct 2026 09:18:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460920.1671822; Mon, 26 Oct 2026 09: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 1xLGqL-00074A-TR; Mon, 26 Oct 2026 09:18:13 +0000 Received: by outflank-mailman (input) for mailman id 1460920; Mon, 26 Oct 2026 09:18:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGqK-0006zX-DN for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:18:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGqJ-003mGA-Q6 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:18:11 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1ac6-bab6-0a2a0a5309dd-0a2a4507d31c-48 for ; Mon, 26 Oct 2026 10:18:11 +0100 Received: from [52.101.56.40] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1acc-b4ea-0a2a45070019-3465382892ea-3 for ; Mon, 26 Oct 2026 10:18:05 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SJ0PR03MB6518.namprd03.prod.outlook.com (2603:10b6:a03:38e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 09:18:03 +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.0546.021; Mon, 26 Oct 2026 09:18: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=jxcLzP4Q6ej5D5k75coi8/S1tSQvbVBBRZkSoC+KY577M1EVgZlnkRZyNhNv21z+6eiyQovMj0QqFVdwGaZKMwE7vGIoPK0aWMizocqZG2+vWFBoKBlV9q4OONhxj9Fbmz3aS/neOi9t9I+tGj4Zi3m64xCaNeGW7WB3GulRj4GSUWycLhaoQ3mv+w8gfxVup0FspdY328MFAD2D+WTCUQxxqH+hA9LZeqHidB8xDXxVk+4whtLm5WgDcyPhTVUdtnKW4UDmZmqn3Dmgu6uu+5yyyObVHoXHF0elS9aQ0RJPtUKiJaPjnW5I/hxZAKkzuDCJYPpInKu5xQ32qmmiIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mIaXzZ88ptf5Jemx1JWKT89PyZkADCbFMZY+QLrAMTg=; b=FjTsZ2tlUQZcFpKi/OwsyBxofryGHnwrHKnWPeoKcfkORludvU3U8fyXpQEO83NMudBxD+Avj0jqPURgzYfjsPKOAsf1yCWLunqncWCXOgisM9KeEWE5HX1gDPypMd3flK5pQOVDN+nN72uIaBjSX40zjU3oW+q3c6z0FQbmc5sRdfaZh30JntUfGp5WmDvGLyEcR3vYHaCkAItKY/ofuLCw35St1fpLryHqXv/FnGxGCNedNUgUPOPbr/m4cmcbvz/6k5HWf7ac7EWSMoCUs9+QrshNWx0bAjXw/Fc8cyiqCk7t6qHOOkxEaIJ0IYlU4wRAuiHMjSUr5IyZ+0GMZg== 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=mIaXzZ88ptf5Jemx1JWKT89PyZkADCbFMZY+QLrAMTg=; b=qTGY43utJBkFcBdtBXY3dLRCZHlS3fLxVvkNc9jyFFAAM77ZM0jhigwan0axyNbwGwPACcvsGKM8Y9J/yjRjE8gWnzSu5ZyUyLBwjgWA7A83XnrDs//horuuPpnAI1upWzhYMHo9Fvd011XjS0EF8Yd4zf8zzPtwei6znBkXbeE= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 5/7] x86/kexec: Implement new EFI load type Date: Mon, 26 Oct 2026 09:20:15 +0000 Message-ID: <20261026092017.3880869-6-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261026092017.3880869-1-kevin.lampis@citrix.com> References: <20261026092017.3880869-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0021.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::22) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|SJ0PR03MB6518:EE_ X-MS-Office365-Filtering-Correlation-Id: 9044d93c-e194-4241-c2d4-08df33420957 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|261009223027099003|261021121427099003|261022075727099003|261022115727099003|261022105027099003|261021135927099003|261021123027099003|10067099003|56012099006|3023799007|6133799003|18002099003|22082099003|11063799006; X-Microsoft-Antispam-Message-Info: YfZ/Yqssc7Bvai7Nw5SJ897ylLpUXIC6gIcuaAaXcSCQQ/Iejtq7pLNiRdUxvxgh6LNc1I6lusnhcKg9a87O4IuV8k/Ol02oupl3ehxmTjMJ03auDgVJXrYA+cOwnPuoNc9h2EiLJZt/8Gto1xQftmnS1kM27XnfNn1BpkdQx1+Dt4Bu57DYCc09gcLzC2AJQr+muwMSIUOhqAhk7EcbSi9eaux1xIqWystUWSrwjRw3jsowDb305ZCB2y5r3Fnbf03ITm59PgRDvJw5myzrDph8F5nxgB0/DitBmV12oE1KA6fw4FZRtLl4P3WVBbNnm5UcI/JRY1jtdx1CXyAcSXa5ikI6CZT0uo0QJmGWtQ4uOY6aiZUiJYJ2PrC5fPazDZS4y0RBKyB2cyCZ4vEsNlozrQ8OvGiK0PqfdDv/FUQlbyOn2u5rcYy5ygd5vvZ7gEMTTQCVzvJ+iEGR6uSvMJppLAKYx7LRjhYshi5klrm/3QOV1V/yNRIZ4z6eTYoTuZSoZebBoghkjootmtEx62iEQtrNEqEq8iEPVpR8hm2oDA/OCL/kNZhRT4PX+xPWsMxBqGhKi1dIznPslwaf++MeP8bO9Xq3SUW/RyEWyzl4cXEolMFYZGlv9IYDuRZAf0J3WZNs0MSYJZaq/ou0YSt5zpK6dft1EoDUNvDaZ3E= 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)(23010399003)(366016)(376014)(1800799024)(261009223027099003)(261021121427099003)(261022075727099003)(261022115727099003)(261022105027099003)(261021135927099003)(261021123027099003)(10067099003)(56012099006)(3023799007)(6133799003)(18002099003)(22082099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?96VLbpxs/X0An9OejG0mlbP4hp5CXZcAx1sCr/IxBbG2dZo6vnQFCLzACrJ5?= =?us-ascii?Q?vZB49+5O+kMO8kXqLz54vPbG4SRk45M8v8o/wVNOTW0ylRv7HjzbAhL1pWug?= =?us-ascii?Q?oqrXh0ooDfNp8/mIgsS6GHoSBfet7bbYKBLTUGML7CeGz3eHbrL8gZAXPXK6?= =?us-ascii?Q?PBa0Rout81AE7/F6khj0X88MHo+cgHzi1Jr/3ZSoxjWBRrxzptsvTU9FzY3r?= =?us-ascii?Q?Fiur+/Tb5UZDRZAxUSMOPX1km68dJfbwZ898en/9oFD14WI4brZ+bHqqolkp?= =?us-ascii?Q?fWpt9RrU5CpLO3lincb039rQ0tOWbLwMQEyXp7sGWJXta60SWPbmwmniGj92?= =?us-ascii?Q?PTv8AVxnEHm1kTKqhXd/JNfq6dMbnqvS3qxNoThXmqVgbE6dRGNFU/7aLkwC?= =?us-ascii?Q?kvOQPcqGw5lPkQzkQ0PPLkyu4nsID8k3H04MVKVC2eBtsimmvm+miYUD9Y8I?= =?us-ascii?Q?QaGhwNt1mGrzRUL30Ws32rtPxHmrTYnADwAFnAx+nVauYv2+xH6DNz/8F0Ku?= =?us-ascii?Q?2kTwOq9tH1XA7vBH2rY3CKXkBIsI8k+td+0otBJkvHSSPxTQEWGaFMUDPp1u?= =?us-ascii?Q?wdwocpePBJDad3akMUhuaIl9TyOncXQ2BuIaG3GNJLZhOkLmiIscaQijwQEO?= =?us-ascii?Q?TdzEN9W2jCon+3D9gdNm/3IgJODcdaNk5tujDm/AeVBWufaunlzC2Tlvh397?= =?us-ascii?Q?CHntCTCKwDr1ZsSsCfqBuepD9qpmNqBqYzb6xyes+ieoiFpaQ0h15FWph9R6?= =?us-ascii?Q?F2igzR42e21XkedLMNl/pHPa5vrBYsfCmKxAF7GJ/32km5V/WIXCycYW2OCJ?= =?us-ascii?Q?fVSmiBVnigimY5TukRrPl+nTl8hQ6njG4AS7tgbIBZ90tFjvvaGjQsKEO7ps?= =?us-ascii?Q?Zpe2CFaTYqa9A+qzCQaZqk5mBoLu2VH0plIjvyScXM38w/mH5czt8/m3ODAy?= =?us-ascii?Q?Zvz1SA+JE7b+1TSC5fwCWuCept50EN1k/3MHeM2IxWDa1BHDWjJ8Z/H4en19?= =?us-ascii?Q?C7vPmSyz7UVNysONqRswbMgyI/ppF0+LXLRvZkJPuMUmtvvESYHcOuxiOM1T?= =?us-ascii?Q?G7jBxeQYRvR/Z8Yck6KqEptRcp/UV22ZgREeeSLTxFFDJrGNycW7pUDTEfcb?= =?us-ascii?Q?x5WKxJrKf4GE3izlaaFv9fhjRfMfEMrwSOWI8vzkxKqd30pAuiKa4lAlaKYe?= =?us-ascii?Q?L60cT0t2a4Sh7TKjjRkLEfUOipi+lpAB6ylIo8GXM9pAOtCvY4oTe187apbo?= =?us-ascii?Q?Rg4Us5BVlIg78dDUz/UypPNUL6ZFLyc1XKeIOVrRmSm9pGVVZJfvMjG3pWyz?= =?us-ascii?Q?ysxC1zuGmkGJH4GxxjK1c9riQWokI1uJSBVn3l0ylGShyh+EdB5Av3TamPos?= =?us-ascii?Q?zg7zQxdr/mRUZvhoixp9M7ZI4ArCTPALp2988AXWD3lIi/isfFZRzBjRGFU/?= =?us-ascii?Q?NFNlRhN4jMb6mPHtYJItDd3mJZypSr7E0HF5SJ2snfdvpAxzLjPeLqsTl2Go?= =?us-ascii?Q?5h8ao7v4xIHDhPQD+zS9ZFxdhsRR3wH00qew1s7vJ7EtlrtBXFQC8x2M8d1/?= =?us-ascii?Q?uFHZWAstFC8TGjyoa5tTtz2ocbI9aVbUmr6XurAn9GketrFBE3TugZ4GkXhA?= =?us-ascii?Q?hl2Usp3dNrQazy57wAryh4OEpylSbpynYSy0a+YvZaTtFTEtZ5wnX74PEGqi?= =?us-ascii?Q?RrvRhF79QLAHZu+yhYzDaOmXHsn3jV4+sJESd556wK32zUi+9K6Haa914NEI?= =?us-ascii?Q?5dhfHTjKkQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9044d93c-e194-4241-c2d4-08df33420957 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:18:02.9451 (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: JljX1z0IRO42mMqgC8Lsn6mDtRL2OajudUPqwDOswWTFtirzXh48U4oYXDk8bLSWuo82pYa3r8qMlXpdvwHV9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6518 X-purgate-ID: tlsNG-ef75cf/1793006286-35AC0AE4-2CEEA0F0/0/0 X-purgate-type: clean X-purgate-size: 14600 From: Ross Lagerwall Add new EFI load type for kexec. This load type is suitable for use when Secure Boot is enabled. When this load type is used, the caller should not pass purgatory as one of the kexec segments. Instead, Xen will prepare any glue code needed internally. The new load type only works for Linux bzImages using the x86 64-bit boot protocol documented at linux/Documentation/arch/x86/boot.rst. Signed-off-by: Ross Lagerwall Signed-off-by: Gerald Elder-Vass Signed-off-by: Kevin Lampis --- Changes in v3: - Makefile: insert kexec.o alphabetically - kimage_find_kernel_entry_maddr: use MB() macro - public/kexec.h: Don't use anonymous union This required a new change to tools/libs/ctrl/xc_kexec.c Changes in v2: - Move kimage_find_kernel_entry_maddr to arch specific kexec.c file Didn't add stubs for other archs because CONFIG_HAS_KEXEC is x86 only - When parsing kernel entry check for header magic and boot protocol version - When parsing kernel entry use setup_sects instead of ROUNDUP - Update commit message to explain new kexec type only works for x86 linux - Rename kexec_image->boot_params to entry_arg - Use size_t for return type of kernel_alignment_offset() - Remove error handling around map_domain_page because it doesn't fail --- tools/libs/ctrl/xc_kexec.c | 2 +- xen/arch/x86/Makefile | 1 + xen/arch/x86/include/asm/bzimage.h | 5 ++ xen/arch/x86/include/asm/kexec.h | 9 ++++ xen/arch/x86/kexec.c | 58 +++++++++++++++++++++++ xen/common/kexec.c | 11 ++++- xen/common/kimage.c | 75 +++++++++++++++++++----------- xen/include/public/kexec.h | 12 ++++- xen/include/xen/kimage.h | 2 + 9 files changed, 143 insertions(+), 32 deletions(-) create mode 100644 xen/arch/x86/include/asm/kexec.h create mode 100644 xen/arch/x86/kexec.c diff --git a/tools/libs/ctrl/xc_kexec.c b/tools/libs/ctrl/xc_kexec.c index a4e8966adc32..d54353b2ddc9 100644 --- a/tools/libs/ctrl/xc_kexec.c +++ b/tools/libs/ctrl/xc_kexec.c @@ -88,7 +88,7 @@ int xc_kexec_load(xc_interface *xch, uint8_t type, uint16_t arch, load->type = type; load->arch = arch; - load->entry_maddr = entry_maddr; + load->p.entry_maddr = entry_maddr; load->nr_segments = nr_segments; set_xen_guest_handle(load->segments.h, segments); diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 2be90ea09880..cd08180c37e1 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_PV) += ioport_emulate.o obj-y += io_apic.o obj-y += irq.o obj-$(CONFIG_LIVEPATCH) += livepatch.o +obj-$(CONFIG_KEXEC) += kexec.o obj-$(CONFIG_KEXEC) += machine_kexec.o obj-y += mm.o x86_64/mm.o obj-$(CONFIG_VM_EVENT) += monitor.o diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h index 8c54b21d0685..e363cc9a4f84 100644 --- a/xen/arch/x86/include/asm/bzimage.h +++ b/xen/arch/x86/include/asm/bzimage.h @@ -47,4 +47,9 @@ struct __packed bzimage_header { uint32_t payload_length; }; +static inline size_t kernel_alignment_offset(void) +{ + return offsetof(struct bzimage_header, kernel_alignment); +} + #endif /* __X86_BZIMAGE_H__ */ diff --git a/xen/arch/x86/include/asm/kexec.h b/xen/arch/x86/include/asm/kexec.h new file mode 100644 index 000000000000..04b7eee4c1a9 --- /dev/null +++ b/xen/arch/x86/include/asm/kexec.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef ASM_X86_KEXEC_H +#define ASM_X86_KEXEC_H + +struct kexec_image; +int64_t kimage_find_kernel_entry_maddr(struct kexec_image *image); + +#endif /* ASM_X86_KEXEC_H */ diff --git a/xen/arch/x86/kexec.c b/xen/arch/x86/kexec.c new file mode 100644 index 000000000000..52d2c50fb3b5 --- /dev/null +++ b/xen/arch/x86/kexec.c @@ -0,0 +1,58 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include + +/* + * Find the entry point to the new kernel, we need to map the crash region into + * memory in order to read the kernel header. + */ +#define KERNEL_SEGMENT_IDX 0 +int64_t kimage_find_kernel_entry_maddr(struct kexec_image *image) +{ + uint64_t dest_maddr; + uint32_t alignment, magic; + uint16_t version; + void *dest_va; + const struct bzimage_header *hdr; + int setup_sects; + size_t kern16_size; + + dest_maddr = image->segments[KERNEL_SEGMENT_IDX].dest_maddr + + image->segments[KERNEL_SEGMENT_IDX].dest_offset; + + dest_va = map_domain_page(maddr_to_mfn(dest_maddr)); + + hdr = (const struct bzimage_header *)dest_va; + magic = hdr->header; + version = hdr->version; + alignment = hdr->kernel_alignment; + setup_sects = hdr->setup_sects == 0 ? 4 : hdr->setup_sects; + kern16_size = (setup_sects + 1 ) * 512; + + unmap_domain_page(dest_va); + + if ( magic != 0x53726448 || version < 0x0202 ) + return -EINVAL; + + /* + * Ensure the kernel alignment is a valid LOAD_PHYSICAL_ADDR, + * which ranges from 2MiB to 16MiB on 64-bit systems + * as defined in the kernel x86 Kconfig + */ + if ( alignment % MB(2) != 0 || + alignment < MB(2) || + alignment > MB(16) ) + return -EINVAL; + + if ( (dest_maddr + kern16_size) % alignment ) + { + printk(XENLOG_WARNING "kernel dest addr 0x%lx is not aligend to 0x%x\n", + dest_maddr + kern16_size, alignment); + return -EINVAL; + } + + return dest_maddr + kern16_size + 0x200; +} diff --git a/xen/common/kexec.c b/xen/common/kexec.c index c92c464fe0ec..2ad09cbdc1f3 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -757,6 +757,7 @@ static int kexec_load_get_bits(int type, int *base, int *bit) *bit = KEXEC_FLAG_DEFAULT_POS; break; case KEXEC_TYPE_CRASH: + case KEXEC_TYPE_CRASH_EFI: *base = KEXEC_IMAGE_CRASH_BASE; *bit = KEXEC_FLAG_CRASH_POS; break; @@ -856,6 +857,7 @@ static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg) break; case KEXEC_TYPE_CRASH: + case KEXEC_TYPE_CRASH_EFI: kexec_crash(CRASHREASON_KEXECCMD); /* Does not return */ break; } @@ -946,7 +948,7 @@ static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg) segments[i].dest_size = tmp_seg.dest_size; } - ret = kimage_alloc(&kimage, load.type, load.arch, load.entry_maddr, + ret = kimage_alloc(&kimage, load.type, load.arch, load.p.entry_maddr, load.nr_segments, segments); if ( ret < 0 ) goto error; @@ -957,6 +959,13 @@ static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg) kimage_calc_digest(kimage, kimage->digest); + if ( load.type == KEXEC_TYPE_CRASH_EFI ) + { + ret = kimage_efi_setup(kimage, load.p.parameters); + if ( ret < 0 ) + goto error; + } + ret = kexec_load_slot(kimage); if ( ret < 0 ) goto error; diff --git a/xen/common/kimage.c b/xen/common/kimage.c index d4a695a2bdb9..b31f205176db 100644 --- a/xen/common/kimage.c +++ b/xen/common/kimage.c @@ -19,6 +19,7 @@ #include #include +#include #include /* @@ -104,29 +105,6 @@ static int do_kimage_alloc(struct kexec_image **rimage, paddr_t entry, INIT_PAGE_LIST_HEAD(&image->dest_pages); INIT_PAGE_LIST_HEAD(&image->unusable_pages); - /* - * Verify we have good destination addresses. The caller is - * responsible for making certain we don't attempt to load the new - * image into invalid or reserved areas of RAM. This just - * verifies it is an address we can use. - * - * Since the kernel does everything in page size chunks ensure the - * destination addresses are page aligned. Too many special cases - * crop of when we don't do this. The most insidious is getting - * overlapping destination addresses simply because addresses are - * changed to page size granularity. - */ - result = -EADDRNOTAVAIL; - for ( i = 0; i < nr_segments; i++ ) - { - paddr_t mstart, mend; - - mstart = image->segments[i].dest_maddr; - mend = mstart + image->segments[i].dest_size; - if ( (mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK) ) - goto out; - } - /* * Verify our destination addresses do not overlap. If we allowed * overlapping destination addresses through very weird things can @@ -212,9 +190,10 @@ static int kimage_normal_alloc(struct kexec_image **rimage, paddr_t entry, KEXEC_TYPE_DEFAULT); } -static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry, - unsigned long nr_segments, - struct kimage_segment *segments) +static int do_kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry, + unsigned long nr_segments, + struct kimage_segment *segments, + uint8_t type) { unsigned long i; @@ -248,8 +227,28 @@ static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry, } /* Allocate and initialize a controlling structure. */ - return do_kimage_alloc(rimage, entry, nr_segments, segments, - KEXEC_TYPE_CRASH); + return do_kimage_alloc(rimage, entry, nr_segments, segments, type); +} + +static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry, + unsigned long nr_segments, + struct kimage_segment *segments) +{ + /* Verify we have a valid entry point */ + if ( (entry < kexec_crash_area.start) + || (entry > kexec_crash_area.start + kexec_crash_area.size)) + return -EADDRNOTAVAIL; + + return do_kimage_crash_alloc(rimage, entry, nr_segments, segments, + KEXEC_TYPE_CRASH); +} + +static int kimage_crash_alloc_efi(struct kexec_image **rimage, paddr_t entry, + unsigned long nr_segments, + struct kimage_segment *segments) +{ + return do_kimage_crash_alloc(rimage, entry, nr_segments, segments, + KEXEC_TYPE_CRASH_EFI); } static int kimage_is_destination_range(struct kexec_image *image, @@ -421,6 +420,7 @@ struct page_info *kimage_alloc_control_page(struct kexec_image *image, pages = kimage_alloc_normal_control_page(image, memflags); break; case KEXEC_TYPE_CRASH: + case KEXEC_TYPE_CRASH_EFI: pages = kimage_alloc_crash_control_page(image); break; } @@ -781,6 +781,7 @@ static int kimage_load_segment(struct kexec_image *image, result = kimage_load_normal_segment(image, segment); break; case KEXEC_TYPE_CRASH: + case KEXEC_TYPE_CRASH_EFI: result = kimage_load_crash_segment(image, segment); break; } @@ -831,6 +832,10 @@ int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, case KEXEC_TYPE_CRASH: result = kimage_crash_alloc(rimage, entry_maddr, nr_segments, segment); break; + case KEXEC_TYPE_CRASH_EFI: + result = kimage_crash_alloc_efi(rimage, entry_maddr, + nr_segments, segment); + break; default: result = -EINVAL; break; @@ -1039,6 +1044,20 @@ done: return ret; } +int kimage_efi_setup(struct kexec_image *image, uint64_t parameters) +{ + int64_t rip; + + rip = kimage_find_kernel_entry_maddr(image); + if ( rip < 0 ) + return -EINVAL; + + image->entry_arg = parameters; + image->entry_maddr = rip; + + return 0; +} + /* * Local variables: * mode: C diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h index abb2a49238f1..25eef43dab53 100644 --- a/xen/include/public/kexec.h +++ b/xen/include/public/kexec.h @@ -54,13 +54,16 @@ * - kexec into a regular kernel, very similar to a standard reboot * - KEXEC_TYPE_DEFAULT is used to specify this type * - kexec into a special "crash kernel", aka kexec-on-panic - * - KEXEC_TYPE_CRASH is used to specify this type + * - KEXEC_TYPE_CRASH or KEXEC_TYPE_CRASH_EFI are used to specify this type + * - in case of KEXEC_TYPE_CRASH_EFI the first segment will point to the + * full kernel to load and entry point will point to boot params * - parts of our system may be broken at kexec-on-panic time * - the code should be kept as simple and self-contained as possible */ #define KEXEC_TYPE_DEFAULT 0 #define KEXEC_TYPE_CRASH 1 +#define KEXEC_TYPE_CRASH_EFI 3 /* * Perform kexec having previously loaded a kexec or kdump kernel @@ -167,7 +170,12 @@ typedef struct xen_kexec_load { XEN_GUEST_HANDLE(xen_kexec_segment_t) h; uint64_t _pad; } segments; - uint64_t entry_maddr; /* image entry point machine address. */ + + /* Image entry point machine address or parameters in case of EFI. */ + union { + uint64_t entry_maddr; + uint64_t parameters; + } p; } xen_kexec_load_t; DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t); diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h index 86250f29394e..fdda0a89a53a 100644 --- a/xen/include/xen/kimage.h +++ b/xen/include/xen/kimage.h @@ -48,6 +48,7 @@ struct kexec_image { paddr_t next_crash_page; uint8_t digest[SHA2_256_DIGEST_SIZE]; + uint64_t entry_arg; }; int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch, @@ -66,6 +67,7 @@ int kimage_build_ind(struct kexec_image *image, mfn_t ind_mfn, bool kimage_verify_digest(const struct kexec_image *image); void kimage_calc_digest(const struct kexec_image *image, uint8_t digest[SHA2_256_DIGEST_SIZE]); +int kimage_efi_setup(struct kexec_image *image, uint64_t parameters); #endif /* __ASSEMBLER__ */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:18:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:18:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460922.1671831 (Exim 4.92) (envelope-from ) id 1xLGqN-0007J8-7Z; Mon, 26 Oct 2026 09:18:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460922.1671831; Mon, 26 Oct 2026 09:18: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 1xLGqN-0007Iv-3h; Mon, 26 Oct 2026 09:18:15 +0000 Received: by outflank-mailman (input) for mailman id 1460922; Mon, 26 Oct 2026 09:18:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGqL-00072e-R9 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:18:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGqL-00FxK6-7b for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:18:13 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1ad5-e002-0a2a0a5209dd-0a2a4509ebd2-0 for ; Mon, 26 Oct 2026 10:18:13 +0100 Received: from [52.101.48.45] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1ad3-be1a-0a2a45090019-3465302d0efa-3 for ; Mon, 26 Oct 2026 10:18:12 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by MN2PR03MB4959.namprd03.prod.outlook.com (2603:10b6:208:1a3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Mon, 26 Oct 2026 09:18:08 +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.0546.021; Mon, 26 Oct 2026 09:18: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=yKt/e1WNMqd8B57FcOFjSzq+Xr4PeV9GMSWyCPMx1kYlUHYa8M2TmXbKut057el2nXprJLgOD2bwI3Q7lhnasRxoqxamtrk1wW+rFJympdfKS6JpxEvm0bZCDHX3l9tLh26PZLXfOl/GqexFePKKBNgXOcS5QdbI/F4bmGAh8AJoVk6FE8q1gtcSum+D8FqZn17u2LUZIRf1iGDYMZhUTw3n2Y2rlxR/XAIkVvOj8abBm/hoW/G0bMdPv8mc7g9sLflprxeUun7q16FdEen5YZCZHO/qNIv9xZel2/98U0FXEn5Zks0gOGf9/MlaTxX4BuJmphE6ttm1BUeeusQM+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=oOjev09aQTNY8dAemGzi70+Y2cPv21By6/8CxrKPdPA=; b=DT1Qlxr0CSd7rlFTdVOeenTQ2GxguDUXjF2WruaqbKdNllPj0rpqWQT8oNiUcX0DYnCivWjzeU0LV52lljj8qfEydvfcPTWq3RJMxuObAh5952Tw2yXmVE9CRp6NiDwwCfhmv2h6uZ5z424pH/ij+5jnGbESenDOPf95M7ZqMs5oOuEZcYpPjSOZhhhKChpy0hI4qJ/dJMrUzz7klIUZn+P0WVcHpe6cKe8/LL8NHLxNvazrjoR5Tv+ohecFBMqn7gVvflNIgfga/JmvLjJeKEK/y4hUuiZvYO7E0LxCeglPrH9OHjsAngz8ucBSGdCnkL+zNi/qLsGaNe7lg9KxdA== 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=oOjev09aQTNY8dAemGzi70+Y2cPv21By6/8CxrKPdPA=; b=DofId1iDpPE+u0s2VTyy4QJv7lUqk46BbrQXER9Zyg10dFkWIobLA5FLIpIEUO3cd7Ck27jccwbqdORKrP4Ju5Z13Y3OR82knol6VHKcx3Vtm6B107wI5a8O7Nox0ezDlPBP7q4Y1l8NwbW6Et89HPxIZQCxUqCcnEQC6NsAafc= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 6/7] x86/kexec: Pass boot params directly to new kernel Date: Mon, 26 Oct 2026 09:20:16 +0000 Message-ID: <20261026092017.3880869-7-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261026092017.3880869-1-kevin.lampis@citrix.com> References: <20261026092017.3880869-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0024.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::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_|MN2PR03MB4959:EE_ X-MS-Office365-Filtering-Correlation-Id: cd788df0-db5c-42c0-740d-08df33420ca1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|22082099003|18002099003|261022105027099003|261022075727099003|11063799006|261021123027099003|10067099003|261021121427099003|261009223027099003|261022115727099003|56012099006; X-Microsoft-Antispam-Message-Info: tSEsbtOFh1kUu/7+2OCi6Lrq8GjehVRredpKtz5oYes65l7ugtRmnBgEsCF2wJJIfiOZMlSpAiirHzo24TdA5KFbWfZZlcdMmsO3lhQTPOpuU0tPCciAdoTpe0HEYlsUGVqsR+xp7fS5TidmitIwgYlhn5DPtqOTrmtzG9iicn8UvwfhsDywXv4QphlJEmzo8i9ZGPN4gyjZvmVz9pmhQps3bhynL2vCC/hut3f2LXUocOe+85dNCW7BDcJ8+CcsxFIlYAVWZJI4zUHbr4rD0AXSlqBBBA2o5XecLowDMEvjHaoOM7wYa4q01xqR4xY84ckBKGIeTrxHvft2OkvHZLF/JZ0zC3VHM80J11EhKyWwG2dIpBa2oQfj3THdB8D58nJB7kjhhKcOo1+HzzGejuYR/HnkrCubnHJmBGheTY7knvHzLZxr3PgGmBFLetcdC/itVe7Vnn/X6M5i1lz76NMxKnof7V1yJEKhAjlDqVRAv+ccqDyMDEAjGYaCL+sI2WVcZlFDbLqrO1IvnmYu7Ky8b3l+zwcXfTM6ayuAmbjnveHqm8jsY086LCYxf7M0Vcnyo10U5TrtH7vfXn5rGhjB4LiT9WxkdI3kPBJv4Xzbcx5l/8u6KC+MnLI9prq53OYEg0faTI58KyR1PM9XxsgBZdYjcvXZyPMjvwp1IsM= 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)(23010399003)(366016)(376014)(1800799024)(22082099003)(18002099003)(261022105027099003)(261022075727099003)(11063799006)(261021123027099003)(10067099003)(261021121427099003)(261009223027099003)(261022115727099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?riyR6+hcDA+XBzbh5eCMKerSNU29Vx+Uw7OIAMteuVWpxtU/nn1AHZBgGnhu?= =?us-ascii?Q?3O+/3lPE7hDwbDlcUTMCqEWOXI+Kj5/eIJE8H0AxYpL1NRAXi5nZfrI8Y6ty?= =?us-ascii?Q?CzpzCq8nn71e40cC+KuFV5ImQsGX/Y4+d4ob9rIQ3/W9APhUbvfr4bJgv5TD?= =?us-ascii?Q?Ft4LHbVWTKqY7JJuOY+4VLCbG0o0ojtkLPoilQeHzsndubBQMmTSTpkMiylt?= =?us-ascii?Q?0rEO1yaRorhmAnb6ekHFKqtMmSpoagWpfG0frH0FJpnQi0ctuVXawjfC76PD?= =?us-ascii?Q?7Y/H74G7jWGkuCURK4TyuaOY2K7hYjJ+Ih/K+J12sD2JxwF7dF5WMejzWLiF?= =?us-ascii?Q?WySWeqAQJMgEdrq0ZlJjFkv/ESQ23vSwXH4sFu6DN3srrhv0v4Q2FUek/rH3?= =?us-ascii?Q?Nh/nh4s5rnZ76pIfvaR5k/pfDbWjL7bBz6bG0tsBf1Dp/9vc882StnpLVQ/e?= =?us-ascii?Q?OknGFkYee7MOaue9nmqWHZH5FrsTRgHZEyuwRRyurtf7vYQsPN03aqb0/rd9?= =?us-ascii?Q?UVpyeMxUk+9ErrTODn3y1iKdmGKkmC+INLLExlVMP7Udnjg6gLuSM6LKA6w0?= =?us-ascii?Q?C802NpRPiuiH8fQ1HoUnx6uFQ+FCNCfalpzSWHiTjgN4lJqX4WP6sQfm60vE?= =?us-ascii?Q?pgJN9du72ZSPnG1qGqSj1fxv1eUdzSUbjt3Dt9/riW80REDpYUfzU5180Mtu?= =?us-ascii?Q?mt2ztNUmNEDBDKEAZdAGh5FBz0Vr0BtXGl8niexJHdV7b8HECr48eVrbTD3x?= =?us-ascii?Q?EzOCtelzBIvPki+7CXHCsd/IIBCG/bJ1aFQLYbIohlWNQfC2yxpa14Cc/4Tu?= =?us-ascii?Q?PayPMevFdf/c+noFOeznuEdr9yVh123dAqcnlgGedsFBZv7lR6PkzBa857Eq?= =?us-ascii?Q?bwC0RNBpU1v6Mdmw+973ICmKFpfl0uzNkakHiE671r42jszNrYjftat5Vk/b?= =?us-ascii?Q?MhJGPtzbdbjA/CIGly/HMq/WVUPivlmfJq5/Otnn+mQEju+QF9iTJ6mNkZWU?= =?us-ascii?Q?CdI65ry4qphD87R/RTiHZQGoMb0uhDR3DOev56zWQ83ovwMXZnjyL58q82s6?= =?us-ascii?Q?Fej6RZA+O+hhmvb01ny1U5tFHc/93FWQ6g0FsUVNpz1QNFNFdIPNhK07+99R?= =?us-ascii?Q?m9Jy7G3FYABxrBC7yBTQ234M0oOcFkNV2r+TW6bLxg/bHCtMaNEhaRrWW3uq?= =?us-ascii?Q?/wjHDl0lebuGLqxAYqvabyOOc6rVTxhMt27Js7h1Xdoo2tIrl1NZJMLLNIat?= =?us-ascii?Q?l/jXGLRkSHbqbMEmBHRygKf0V7kEKNF7NLaKSB7g/g3t4L/pTN8bOtxMAqTW?= =?us-ascii?Q?yIRlyiCDsA163LMvsG/7myLcvgbYb6HBozrN68VDflfSsYRYKm4EdyR8B9Yv?= =?us-ascii?Q?Kg99VVNGLB5b3HvlP9i1obK1B11Qv0i1VqEitCFEfUA8T8p5JD3gzEwN/gMZ?= =?us-ascii?Q?3FfhDIxi3OQsFfZPjajX14ijGg4GOlbkWGN4sIFmUs2PVKCem1iqhRMZHj4s?= =?us-ascii?Q?Aas1UPAniOrqDu8cWM4y78COi5wV5fqdM+4l7LWDTVIzTyzvvnP6hzusKuB5?= =?us-ascii?Q?7cwQRjlHriAlEml+GAVoIcVM2EY2x1tuhXtzfq0is1+WYCeFEM1eOGeyQjQA?= =?us-ascii?Q?nD/e5OWdYevD2bt9llqpmMnEOK5baEdpMEr9FjI4/7RAc8qR7mDUdvzomEdb?= =?us-ascii?Q?EOBbjh/tE6lCuznBYJBrM77PDN9foCzZuELfKjvjOa0bRPvKRII7HWyaXmUf?= =?us-ascii?Q?ib1nmZ4JYQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd788df0-db5c-42c0-740d-08df33420ca1 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:18:08.3489 (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: wf6n9C/vlZSMzH+yeURvff76L/phMQsMx/WHQxGwkY++kUfQLKAuFZpglhErTcDNUJfmMGKEB0alQSf9mf6H8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB4959 X-purgate-ID: tlsNG-bad1c0/1793006293-39AC0034-382CC2A4/0/0 X-purgate-type: clean X-purgate-size: 2450 When doing kexec on an EFI image there is no purgatory and kexec_reloc.S hands off straight to the new kernel. To facilitate this the Linux kernel boot params need to be passed through %rsi. Signed-off-by: Kevin Lampis --- Changes in v2: - Rename kexec_image->boot_params to entry_arg - Fix indentation --- xen/arch/x86/include/asm/machine_kexec.h | 2 +- xen/arch/x86/machine_kexec.c | 3 ++- xen/arch/x86/x86_64/kexec_reloc.S | 3 +++ 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/include/asm/machine_kexec.h b/xen/arch/x86/include/asm/machine_kexec.h index 3e189acf2464..010e0c704626 100644 --- a/xen/arch/x86/include/asm/machine_kexec.h +++ b/xen/arch/x86/include/asm/machine_kexec.h @@ -7,7 +7,7 @@ extern void kexec_reloc(unsigned long reloc_code, unsigned long reloc_pt, unsigned long ind_maddr, unsigned long entry_maddr, - unsigned long flags); + unsigned long flags, unsigned long arg); extern const char kexec_reloc_end[]; diff --git a/xen/arch/x86/machine_kexec.c b/xen/arch/x86/machine_kexec.c index 038670922d47..67ca3e09bece 100644 --- a/xen/arch/x86/machine_kexec.c +++ b/xen/arch/x86/machine_kexec.c @@ -199,7 +199,8 @@ void machine_kexec(struct kexec_image *image) kexec_reloc(page_to_maddr(image->control_code_page), page_to_maddr(image->aux_page), - image->head, image->entry_maddr, reloc_flags); + image->head, image->entry_maddr, reloc_flags, + image->entry_arg); } int machine_kexec_get(xen_kexec_range_t *range) diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S index 1d023733a916..0f163862b858 100644 --- a/xen/arch/x86/x86_64/kexec_reloc.S +++ b/xen/arch/x86/x86_64/kexec_reloc.S @@ -41,6 +41,7 @@ FUNC(kexec_reloc, PAGE_SIZE) /* %rdx - indirection page maddr */ /* %rcx - entry maddr (%rbp) */ /* %r8 - flags */ + /* %r9 - entry arg */ movq %rcx, %rbp @@ -104,6 +105,8 @@ FUNC(kexec_reloc, PAGE_SIZE) movq %rdx, %rdi call relocate_pages + movq %r9, %rsi /* entry arg */ + /* Need to switch to 32-bit mode? */ testq $KEXEC_RELOC_FLAG_COMPAT, %r8 jnz .L_call_32_bit -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:18:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:18:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460927.1671840 (Exim 4.92) (envelope-from ) id 1xLGqS-0007k6-HB; Mon, 26 Oct 2026 09:18:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460927.1671840; Mon, 26 Oct 2026 09:18: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 1xLGqS-0007jz-E6; Mon, 26 Oct 2026 09:18:20 +0000 Received: by outflank-mailman (input) for mailman id 1460927; Mon, 26 Oct 2026 09:18:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGqR-0007fn-9i for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:18:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGqQ-00FxNL-Mi for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:18:18 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1ad5-e002-0a2a0a5209dd-0a2a4509ebd2-14 for ; Mon, 26 Oct 2026 10:18:18 +0100 Received: from [40.93.198.9] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1ad8-be1a-0a2a45090019-285dc609e92a-3 for ; Mon, 26 Oct 2026 10:18:18 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by BN9PR03MB6107.namprd03.prod.outlook.com (2603:10b6:408:11c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 09:18: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.0546.021; Mon, 26 Oct 2026 09:18: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=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=C9XnjKejJXNqlHkeVtEsD8+MQK3p4oHP2djQIVN+YM00fW/ZRyZwzTKg8+5eRUI1yqaHO/5xRVJfaLhVV4QNXS1o1fr5G5icY9C7dEf+CY5xqWGaDGNIG3nHf2VXPiiSinllGHehtJV13r+l9S+tkhYM7XZU6F3bqg1U2D7RFlC4hnfmJxVqISM8+4cjjDijhJOSF+PgUoJtGqXD/ap99uUffIN4eJ/HFm/rwyRFEBgfnI0v+6oqLQgcXHdtmdEzRFQiSFMAID8AxZNkX9oD52khv+cEsAQS0/0xCryiDmzDjW/aH2sVKrQGGpox70mN2+Tan4Nq6x1CnugsIoIEjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+QK2huaQ/+7qvVYWQkaTSEYAhJc1eYzXY5Cdn6C9Xnk=; b=QWPT2v885hgSWj0DJvaCKcddRC3RlcyNUgqNWTa1m5V5ZgPM2ndOHpzOD/K1h8UIcE0HUCqvbZyFZyVCy+oc1lAYI4+rq3HMa5mtwNrc+1A0bJ8gnEj2ZHdL5nRsJFZ0J47MiibIlSGOn9LLOn2SdOSj6jqUg3rJCsZHDGTJJA15Bdv3OWoVNEV9cWhY50hQ+w0QBeAqohmjBlSRgBrPKoAQ50jzgE6+j/mzwceGVcl1pQ10AYR6GzvTs3gvxvN8tCEj3EsuIqAWAqldosxjWOolhGwrjaoQ3xQzCTAKuDZXZArjjm4sEtWsZPT03AONlcS7ckJ466T7RgK0UJhN9Q== 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=+QK2huaQ/+7qvVYWQkaTSEYAhJc1eYzXY5Cdn6C9Xnk=; b=seQO7xPz07pffnAEDjTp3ZPiq386E2ACyxEhvAX45pDz537tvyugOwFnhShJpM9RxHSNbvNnDEL1qYkSz/2NfuvAikWrvpyveZFApGsqi0d1W7b953x1TybQUMSVxSb63sKXye5asbo4FOeFj1MZ3ekEXmFDxP8jUmfKnsK/z6Y= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 7/7] x86/kexec: Zero GPRs before entering Date: Mon, 26 Oct 2026 09:20:17 +0000 Message-ID: <20261026092017.3880869-8-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261026092017.3880869-1-kevin.lampis@citrix.com> References: <20261026092017.3880869-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0277.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:195::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_|BN9PR03MB6107:EE_ X-MS-Office365-Filtering-Correlation-Id: e181fa3e-754d-4807-0866-08df33420f8f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|261009223027099003|261021121427099003|261022115727099003|261022075727099003|10067099003|56012099006|22082099003|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: uIvWDk9UndiEjk2u5LAvsCwUGqvCOO+OxHMLsyhQl7iBKR0ub+8X7ss0qLXLtjDrYm67ihn6vMjTJcMxEVdwuh8jlRsJJHyqHlZ+57QPqB7jsLFTuOQRJAS58EAjPDuUHzYUcK54b3OHPg8nQLXaqHKr++39qxZ0MDoSJH8hr2I5zff9CzxYB7LtzwOpCXMHeyD9yKdqrLg87wlaJStGz1EwyqMhYve4s19XrGKQC7I5BSNYJUGaIKO8yg6bsdUv6TGldoia1uFydRL7s1ViNnS/VkbPek27FIyBmJK11Mi+c6gz1x2BK/Cwb/tmKC8fBf3mcOEZmbNVF1mgyb3lLPIDtJfUrNcrGsbmY1PmFNhmE5xet950xo1n7HIiUSS8DOBd/pFVEA3gswLCHH9y8D9H/8fWVF7V8+quqygVCwUnNg958tWFruIQxQ8qEk2sl1ea4js4irgbU8xwuSgPBW0v1Wvj4VDPEUWdyOPQCfQmcj+hJYK3iBAaFKdRfWP8qRMVR2s52RDxZWMidRcKkbpQIkalfHg5Hw5Ms0fdXqlKnhU8H5BxR1I7Wyf9CUr0KBLwsMLXw5Ksia0Xi+yjuYXV+jn1cEgiIazh7fmQDkyR+2YOd3iiXgwrlEhS57pE2ovNjflJvnkvB+lq6qizRAweJZKHFMv7J07bvhjXuzQ= 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)(23010399003)(366016)(1800799024)(376014)(261009223027099003)(261021121427099003)(261022115727099003)(261022075727099003)(10067099003)(56012099006)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?vJA1LYvBcYQkvFhencQEKSlACzELstY5LHdLEMh1/FsT8NqXR5reNkDMCxNj?= =?us-ascii?Q?yI7DJew1CXQvJTfI5EM7Xy1DEmbBf9JbtlYq0gkIrp7QnLDsXD5K3u8mzSvH?= =?us-ascii?Q?DewLavI4/ckOvFWvPczv3D/mK3Uu7BqoF+D/jPPLR8maRffMnO18qeLjg8eE?= =?us-ascii?Q?0RsFk9h5McArCE7pWLTLvYH3uqp8OFJsRNIS7v0PeuGvOWtiNyofIbFmKrGu?= =?us-ascii?Q?RlmD1JNy8FA3MO5qdfftrjLXud3q6SxJQEYk44JxyQhKicZsSqmEklL7zH5r?= =?us-ascii?Q?qIkuoTj5HlIsrYozq8wRAwoI6PBifIqgPR8Far7ETFADMWZRluYwM8T932xp?= =?us-ascii?Q?FxI5XeewqmC0YSEHUO8InXJ//nQ54FNxoopACFxEZU+e24MKk9383SRJBy0b?= =?us-ascii?Q?wP02TrVeWJ9XTfvuzT/yl/nr8vt4ZxaAuFZLZYfUQWQYibAVHcXeJLpuj1/z?= =?us-ascii?Q?1Osa9q+tTogrkRzwn4LCN5Y1cl57yn6xM7Z+mQwjWCwL5HMk1SZ7lSWFziIR?= =?us-ascii?Q?EZ8KA54nVUW0o65rc9k1i+SFypwuAv1RuLmALuL6XWef/yPVD32r00NRrv+/?= =?us-ascii?Q?znuoFhJEb397I9b8a/hMygXVyCD0avhxxliyPp77zpDGx6Xi5Rr3tMIHC8Mb?= =?us-ascii?Q?ZSiW8myDvPrQRNip7ToZS8x9NYydSU/fAGhHkMMPalARwYiOjIgrfb/eM8cV?= =?us-ascii?Q?+uZ+EK5IVKaR5As29QG/jQmA9GvD3KQKQg7YaBCdVzem/+CFCq3aSBNK4+fH?= =?us-ascii?Q?+3zWI/ki4vIkn8sJUEEZ9A4RUolTyo1bGTs1ajjA+dPzjpxv4Q0i86IYCgXP?= =?us-ascii?Q?xGMTdyA1pAAPfaRhgeSAwwWTRUCrKqHBDl7cAtbCuwXglgCWE/WFY1PLygMe?= =?us-ascii?Q?QAPmtN5uSiPP/o30C4NH3LAhnwTv4TI3dhJDb6LHy3RLN2SxX6HuvpAdsJjn?= =?us-ascii?Q?XxOoTTGRSx99VplZ479eqmVwJIC+fybGtDqzlqupTGAn3AOYZr0W+RW9DUxb?= =?us-ascii?Q?YA2W8wVVJzZUZLRXswYslx8eVozo/Jlt5mcm0pSsUJ6YG3MLyo9GqL7RaKb2?= =?us-ascii?Q?7xYOsCvcTRXsS0a0OtpGv6BNcKp0ojJlaPzwX2DZ3/vH01AX0geLjSAN6ktm?= =?us-ascii?Q?R+mge1YI8IIlkyA+ZkhBI9i8eXYna5Y8rVRwyiO+v6aOWHbsVISaZwieVguV?= =?us-ascii?Q?puMyYsoGqcHvU9qyTwfiBXjeh1hRagg8QbStPHcResZipnbtK15uxdpECbQ2?= =?us-ascii?Q?JLi81qijEckLl0YSHDmSjFPK8dGmqt6ghKeopkF25HsANNGYa46EEVabZQuV?= =?us-ascii?Q?kLC9y5RqyZ+yttqqD9+J+DZd4M31FJXDlFFwSdiIWsEyKWHsS2/RzX2wsjuY?= =?us-ascii?Q?wEZDrFLEUBffUu1gJbR48pnLvavhusk2QGgJzhewITuZrFqUVNoez5215M1l?= =?us-ascii?Q?0zo2ceM+GMKhsxHz202I1+4Vdtrb1JQIMd25C+UhbC80UZ1xRPAcv2xc+4/4?= =?us-ascii?Q?PS7TaISkC6dMzLm4kME9mFKQkR/xw9AdxoLVtJKwqBSiNLBUUcgPxIsJYvu+?= =?us-ascii?Q?sW20+j00l6jCdwH9lTUjdC55UeqCcpZaVE09OuG2iayCvhb4ckpswl4gdQfr?= =?us-ascii?Q?XjDlekiubJknLTP+75XOYnjD3RNBKKH/Jzd3SCIb542E+wPV3x4drVqevpgK?= =?us-ascii?Q?EvZgD9MKgNZE3nJ/Dg/7wGBlpJBcB4hhNtrcRUm+x2sbzsewB+pK/J6jaI+f?= =?us-ascii?Q?Vqvz0+Lmiw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e181fa3e-754d-4807-0866-08df33420f8f X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:18:13.2550 (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: p9qeM3kVQR0/LWFTu4VCwUxx44XmNe7HAOEVzEt0mZgj23SrUWGPntT1UXqxGoM3Qq6HKL2JJXg7A5v6qv+XnQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB6107 X-purgate-ID: tlsNG-bad1c0/1793006298-FD26A034-BB5DCE56/0/0 X-purgate-type: clean X-purgate-size: 1903 Purgatory zeros these general purpose registers before jumping to the new kernel. When doing kexec on an EFI kernel there is no purgatory so we need to zero the registers here instead. This change shouldn't affect the functionality of legacy kexec. Signed-off-by: Kevin Lampis --- Changes in v3: - No changes Changes in v2: - Move the 32bit lines to the correct place - Reword the patch subject line - Fix indentation --- xen/arch/x86/x86_64/kexec_reloc.S | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S index 0f163862b858..ed1cf15e6c94 100644 --- a/xen/arch/x86/x86_64/kexec_reloc.S +++ b/xen/arch/x86/x86_64/kexec_reloc.S @@ -111,6 +111,20 @@ FUNC(kexec_reloc, PAGE_SIZE) testq $KEXEC_RELOC_FLAG_COMPAT, %r8 jnz .L_call_32_bit + xor %edi, %edi + xor %eax, %eax + xor %ebx, %ebx + xor %ecx, %ecx + xor %edx, %edx + xor %r8d, %r8d + xor %r9d, %r9d + xor %r10d, %r10d + xor %r11d, %r11d + xor %r12d, %r12d + xor %r13d, %r13d + xor %r14d, %r14d + xor %r15d, %r15d + /* Jump to the image entry point */ jmp *%rbp @@ -127,6 +141,7 @@ FUNC(kexec_reloc, PAGE_SIZE) lea compatibility_mode(%rip), %rax push $0x10 push %rax + lretq END(kexec_reloc) @@ -204,6 +219,11 @@ FUNC_LOCAL(compatibility_mode) xorl %eax, %eax movl %eax, %cr4 + xor %edi, %edi + xor %ebx, %ebx + xor %ecx, %ecx + xor %edx, %edx + /* Jump to the image entry point. */ jmp *%ebp END(compatibility_mode) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:19:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:19:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460958.1671849 (Exim 4.92) (envelope-from ) id 1xLGrG-0000jY-PW; Mon, 26 Oct 2026 09:19:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460958.1671849; Mon, 26 Oct 2026 09:19: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 1xLGrG-0000jR-Ml; Mon, 26 Oct 2026 09:19:10 +0000 Received: by outflank-mailman (input) for mailman id 1460958; Mon, 26 Oct 2026 09:19:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGrF-0000iz-2V for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:19:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGrE-00FxYX-FR for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:19:08 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1b01-e002-0a2a0a5209dd-0a2a45088bf6-38 for ; Mon, 26 Oct 2026 10:19:08 +0100 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 6adf1b0b-f659-0a2a45080019-b9ff1c229f55-3 for ; Mon, 26 Oct 2026 10:19:08 +0100 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 1a1778197af000f79f.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 09:19:04 +0000 Received: from [192.168.1.52] (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 56EB982E11 for ; Mon, 26 Oct 2026 10:19:03 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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: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=vwL6ftjvVCFatnUdYp6455+bimafOORok6hd2b8tj9o=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=LCtTCX60LPCPDB5Q0gPTHqWB16J+/URvYIcMzdncCuLG2uW9HYPB3EyGrL9oNFMmjR8iMFnN+ hcBy3Q5/Se5z57hWvi/Yp3aEbjLfiRAtKakbDduweELHgxCQnUdKihudryKe+A6cfC+1yU82KbK NAVMxaLp2ZuLxCIwHEPQDEQCL6sggT6UOtQcvS+Yh9rwda/STQpBibPaW1njYmopxm+to33bkNh ujmW06sjf5ZlflF2KzlCrQdpBFh4kNdqJmXSPJbQxyKHDpugdckdMlBcsCAEoEy2MXTut46TImJ ExtI+hliHbZ2xl2/5Thha4YH7Cg/j6C1pPnAHjEU6urw== X-Zone-Loop: 17cd69dfe47890628f903a01c8e32b3a2c6cb7391704 x-campaign-type: default x-transaction-id: d4ec5ffa-4673-42c0-bf15-ca13758c7367 x-swg-uid: 01-3343c12f-4795-47de-b4fc-b7599556818b X-Mailer: Sweego Message-ID: <1793006344.8631fc262581453bbf619ec5b2062170.1a1778197af000f79f@vates.tech> x-swg-bid: 1793006344.8631fc262581453bbf619ec5b2062170.1a1778197af000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 26 Oct 2026 10:19:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/3] tools/libxenstat: small fixes in the Linux network collector To: xen-devel@lists.xenproject.org References: <1792831909.8631fc262581453bbf619ec5b2062170.1a16d1bed9a000f79f@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: <1792831909.8631fc262581453bbf619ec5b2062170.1a16d1bed9a000f79f@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: 1793006343400 X-purgate-ID: tlsNG-c1860d/1793006348-D614687B-2E02210C/0/0 X-purgate-type: clean X-purgate-size: 1752 I might be wrong but it seems the v2 patches have not been sent On 10/24/26 10:56 AM, Olivier Lambert wrote: > While looking at xenstat_collect_networks() for commit 0c53660c1cf3 > ("tools/libxenstat: don't lose all VIFs when dom0 has no Linux bridge"), > I noticed a few more issues in xenstat_linux.c: > > - getBridge() dereferences NULL when /sys/class/net can't be opened, > - after a failed /proc/net/dev header check, the next call skips the > check and parses the file anyway, > - parseNetDevLine() doesn't initialise all of its outputs (cleanup, no > functional change intended). > > Patches 1 and 2 may be worth backporting. If so, patch 1 should go along > with 0c53660c1cf3: without it, the empty bridge name would make every > VIF disappear instead. > > Testing: libxenstat builds with the usual tools CFLAGS (including > -Werror). I also tested the series on an XCP-ng 8.3 host (Xen 4.17.7, > Open vSwitch), applied with 0c53660c1cf3 on top of its libxenstat and > loaded via LD_LIBRARY_PATH: > - xentop reports the same networks and counters with and without the > series, > - with /sys/class/net made unavailable in a private mount namespace, > xentop no longer segfaults in readdir() called from > xenstat_collect_networks(), > - with an invalid /proc/net/dev bind-mounted over the real one, a second > xenstat_get_node() call fails again instead of parsing the file. > > Changes in v2: > - Patch 3: drop "fix" from the subject and add an Amends: tag, as it > changes no behaviour (Baptiste Le Duc). > - Collect Baptiste's Reviewed-by on patches 1 and 2. > > v1: https://lore.kernel.org/xen-devel/1792142033.8631fc262581453bbf619ec5b2062170.1a143fd43ef0008425@vates.tech/ > From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:19:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:19:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460966.1671858 (Exim 4.92) (envelope-from ) id 1xLGrt-0001GK-31; Mon, 26 Oct 2026 09:19:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460966.1671858; Mon, 26 Oct 2026 09:19: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 1xLGrs-0001GB-Vj; Mon, 26 Oct 2026 09:19:48 +0000 Received: by outflank-mailman (input) for mailman id 1460966; Mon, 26 Oct 2026 09:19:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLGrq-0001F9-Uz for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:19:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGrq-004yrd-BZ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:19:46 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1b2d-e002-0a2a0a5209dd-0a2a450a9462-20 for ; Mon, 26 Oct 2026 10:19:46 +0100 Received: from [52.101.85.47] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1b2e-f2d2-0a2a450a0019-3465552f9788-3 for ; Mon, 26 Oct 2026 10:19:45 +0100 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by BLAPR03MB5489.namprd03.prod.outlook.com (2603:10b6:208:299::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 09:17:50 +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.0546.021; Mon, 26 Oct 2026 09:17: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=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=qQjKSwBkOCfMbTtOac1T7XYa17hAOjIYhlMX/pCbyCvHS2fywLJAJkLgGPC5al3cvLOkfeot+tCu/POe/QY3l5sY1X6OhndeKJiwccZ/Q2sbg4kzVIFf/G4MDGWbwm+lObcvTCXu0Laljf6JW6/bhqUDQowJYrGT/pbsU+Edfa1YCuapxfrFsiwZjZd4gUhaMmwk9bKaJMU8xrfJ6c+w2pxXFwI6z2yDt5WnRQBobrUL8MfsMe4E016BtWgMJ86frnH0EujCTiHTdFetY5Jziv3lYraChIMy+IvBNjhgYxIttJdy5X9kW55kyYm5WiWCYEzVNX3QjbZRx5jV+AoQfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8Q4cakGw4L+4MXxU0t1Dsdi4OfcnAS0SKvjzDpHV5T4=; b=RrIGyOAc224TILKTh9AEJb52SaXlpwLOqnyxnaFX3bvDKTjeHtYilAed+dwdiBC6xPzW6wQ8DjH9NMe04uZhDdV4WtItcCnlIuJfaQqJpoCECl95Lxmb7MO2C0ZEZL9QTyfJWrR+MAoMv8i1f5Pg/Qk7olKkFELP6ntd5Ssyd/1y6Zu/OB+OPaBHIutessstVrxkxpRLSrjR7d1KhtVHl8s4NuTzIFVUTwSq0LHm/MR3Moc6XThdYE69AZgJ3MHjwM5s6LFZbFKT0CVFT6u495Jjuvxkk62I2TQAtPuKlZBClQYTu6ZegTdehIngP/8ThoA74P5UgE3cxgJhXFBYBA== 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=8Q4cakGw4L+4MXxU0t1Dsdi4OfcnAS0SKvjzDpHV5T4=; b=g8750+JPdJ/Xbvz032QcT+roUdQ4fp58I7mC+LGwkvEZQ8HzNVkKrlEYjbD3Hq3W2csHBtnkhM2PIzfNs2NlzL76tJqahv4GvVkOi0np86IfKpm7Kv869D6a+zVOjhLNYGoCidyvIZj0OVgrT/VeJVRXKtr8IJAalgZ9OXS/EDc= Authentication-Results: mx.microsoft.com 1; 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, roger@xenproject.org, teddy.astie@vates.tech, ross.lagerwall@citrix.com, Kevin Lampis Subject: [PATCH v3 2/7] x86/kexec: rename setup_header to bzimage_header Date: Mon, 26 Oct 2026 09:20:12 +0000 Message-ID: <20261026092017.3880869-3-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20261026092017.3880869-1-kevin.lampis@citrix.com> References: <20261026092017.3880869-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0271.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37a::7) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|BLAPR03MB5489:EE_ X-MS-Office365-Filtering-Correlation-Id: 82912230-4a85-46b2-d2a1-08df3342019f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|11063799006|56012099006|261021123027099003|261021121427099003|261022115727099003|261022075727099003|261009223027099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: BIq7QwU8q6R/z6BhHFthYqzsOg8gOfneUF7Qzi/paTuiWn5hEDowI7NzbC+BkbUztvfk60QrcxPUmLfVXe9ge9w7+aSfc+Iwf/99rqneQo7ixdPB/OBxqWs1wLsJ0xxhr/Y5xpkP29Lbld+4gk4Q+9T+7h/5Yu6Hi3oRmCWodbEQMF7cGFg8EdLgXv7irvLQ8GJ99Z05nZKB7GTUbZ5hSh2oPOCTSqYz5tK0MnCxNORlq4InMwBAbDV7mUzkO3GxkWplBGcKLDFGUf4xNlrDVbm3Ki7d4+noRQGB5N5f6Ab3prbZQaoDxGQKV62arIHo2hOjqxnQYHROYkRD03EyJjb9+4uho1lIGauhmlOiIyjFlNoO1HwF9S8BLLruaRtkBhdPRZR2Z8pIgnzn/+rc7K25J+xcQsYjSKsB06Xdyfbw8lnsvrERGc725pSkvjanxE/vkQgbXJrzbY/qUSPFvPHYtPBnS1RaOHLw6JhfstXZjB8+NPJ5qaO77/yleKpNoKAf6VVaUDKF9NIAq3g66Jb3ZZZ6nseo8tDOFinHfSsh737ektg5ljnUVtLjvcFpdlibsXl/l+J6WuD+tMImChRU8kVfvFsEQ1E9aG4W2ehjamZDlPHQQBwSWFfq6pDvLwFaqcyfb0eN/dc40MvSS49AMN8B/xSGwGxWzZMuYgg= 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)(11063799006)(56012099006)(261021123027099003)(261021121427099003)(261022115727099003)(261022075727099003)(261009223027099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yQL9RBcf3Eg2ZpbrfEAjvZSVgxXXiqujmt/T2QtxfOFyzI3W3B3OE9eXOQ1u?= =?us-ascii?Q?6Nn+h1+VBrCYrpRVSFILnbYqLfsh6/eVNL3/Se5XUrE3XxaUrvB+rQ34mtL2?= =?us-ascii?Q?lCOPZmaApBYyxyy/aa1KnELpa2zsEvHw32Bf2alS+8MpIdOwHkBsKirI/4qf?= =?us-ascii?Q?SOHf4mmo8bxZs88ebOhplFf0rclYolooJMeJFx0CTsphpLD2+f2qOlDPGfVJ?= =?us-ascii?Q?XLvZegbbtPcx6m+82BmgFXRSlXHfnne9LF42PDolKqRGF606wx8UWu4GiPrv?= =?us-ascii?Q?hirGkMmJOYPXckhtzGa4VWpsj4zvd9YQ6mDI5/wXG2R234EnrambkS5nazGn?= =?us-ascii?Q?el9QRJBKeeiE+wkqiMgUbtZ8+02EU793Dyr7V/KTytOrb9cQ9DG2EJyTEC3v?= =?us-ascii?Q?8YhHWVUVkdqOVGdBTKYy3NYlzJNCFyeA29bj7bDZKOWzccImIjWhXHtGraOl?= =?us-ascii?Q?u+j63pCeOPrAKfKgPGHs3F6SEiM2iDWs8VON4RQuCUxD/DLWDbe7xembmqKX?= =?us-ascii?Q?gNr4E+QL5QL16BmGTRMPYt1mKGoZOZTNwyo1QNxLJ1RdnGUoZjJ5tD6Z8jOM?= =?us-ascii?Q?EtDfN7JUVEyqkoDmxBUQhFu4FjM8SqFraW79Xns6dG4K3oxcK1vEHZITFjnX?= =?us-ascii?Q?cYcTS1da4RbDxqhK8wi9TOA03HlR1YW0vKeT7twKc/+r2usQkMuy7jx3nw5R?= =?us-ascii?Q?tY3NBf33FA1GOL9f7N/hrIS2xWMXYZnunM0Gr2qPcziyaoP51Wur4VOmqFsf?= =?us-ascii?Q?TukyIyKq8NMe4tEzeNsX9XHQDNsbt2g4BSosYQ953tAiJUmE/b6G93kZIqao?= =?us-ascii?Q?OcruhK9OYjex7nlR9gp6CUkDnSZUmTULBvnn1lgIWwLxKrIWWJj0obXzY5B9?= =?us-ascii?Q?pYtRS9YXOJ7TniRwmLawxQOoUtqRg5+rmA/UhLdm+++vHM034eos2PJEisp7?= =?us-ascii?Q?UXtREoE6EwDiM7OwT+1Rw4ANwwnM0hgQ2FAIYWHjMod4/HyIS2Dy2bmoHg02?= =?us-ascii?Q?btm85XIt4KqVYZX/1Sj4Lc2fxIN1x5TA5/aK7eABAvnCneUCNWRxEzC03xGT?= =?us-ascii?Q?RmCai6wC1H3WR3uM5fJExN9YuuHzWpPd5Y/1hZaVl4qqJYu9J/nZtXK3+YaJ?= =?us-ascii?Q?Aufp1CDB6IHvkF9dJh3bory9ObIhE2eqy567mDlpJeYa1YknkKxOgATR5Ox8?= =?us-ascii?Q?f8olpUmwqW4O+X8SsgRTKd1kOm+dDXnANAH9OmVTugU95CDt2+c+iPLSvl2S?= =?us-ascii?Q?eE8JNzglNuLcbgkft57TE9y2BDSrj8W+V/fYXyy0HA+dnad8LHsL2OqUAh9R?= =?us-ascii?Q?ivrIaKn1SnY43rBdmgOKSgJ4w7oAuqZGUyt+lKooTgGuyvQImrIFi1qW+gmG?= =?us-ascii?Q?MIAZqiN8by7QHyZXI0c8vEB1EI/aIfhRWte76Y3LJYFRl7J3Oc+OGGhaAyl9?= =?us-ascii?Q?SqDoKRARdVHpWxauv9YQNQQcbBydSsb+sL4ID8tazytj1h2cisDxS1wCB7Vb?= =?us-ascii?Q?B5BW463+7ZFl3v2LscvNXJwkud7pTijaMW1uroGhU1bs8dJ0NAWKdP2+w8fL?= =?us-ascii?Q?DEhacf3+2+V8Y80ZYvciutwa8ZBLoxTl/n0f5gRROT5y3uFv8drPMcbyiTi2?= =?us-ascii?Q?+Y4kq/iQ1MEKQHoFPNRJsZvaEbfnOqTZHWrML190MxDPiy2OsVYdsNnrK6kU?= =?us-ascii?Q?Y4WD8Eybb0rhc6Ypfo6fqE/hKItUyliiz7WPCHP2yodSDy0IG2OsT3c5RGcy?= =?us-ascii?Q?E0veF0ageA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82912230-4a85-46b2-d2a1-08df3342019f X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:17:49.8670 (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: 1bQKKVb3FrsRS/ANdv55I5Q6MWaNxfw2XO3tGzYFzf4shz2P+VC52rKRE68VGv2COOMdcPlB5d/vhGQUQmn/Mg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5489 X-purgate-ID: tlsNG-4011c0/1793006386-585CBCFC-F562BFFC/0/0 X-purgate-type: clean X-purgate-size: 5641 From: Ross Lagerwall The newly named bzimage_header is moved to a header file because part of it will be needed for Secure Boot kexec. Signed-off-by: Ross Lagerwall Signed-off-by: Kevin Lampis Reviewed-by: Andrew Cooper --- Changes in v3: - No changes Changes in v2: - Remove unneeded casts - Move setup_header to appropriate header file bzimage.h - Renamed setup_header to less generic name bzimage_header --- xen/arch/x86/bzimage.c | 47 +++--------------------------- xen/arch/x86/include/asm/bzimage.h | 39 +++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 43 deletions(-) diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c index 66f648f311e4..02433ac46f0b 100644 --- a/xen/arch/x86/bzimage.c +++ b/xen/arch/x86/bzimage.c @@ -13,48 +13,9 @@ static __init unsigned long output_length(void *image, unsigned long image_len) return *(uint32_t *)(image + image_len - 4); } -struct __packed setup_header { - uint8_t _pad0[0x1f1]; /* skip uninteresting stuff */ - uint8_t setup_sects; - uint16_t root_flags; - uint32_t syssize; - uint16_t ram_size; - uint16_t vid_mode; - uint16_t root_dev; - uint16_t boot_flag; - uint16_t jump; - uint32_t header; -#define HDR_MAGIC "HdrS" -#define HDR_MAGIC_SZ 4 - uint16_t version; -#define VERSION(h,l) (((h)<<8) | (l)) - uint32_t realmode_swtch; - uint16_t start_sys; - uint16_t kernel_version; - uint8_t type_of_loader; - uint8_t loadflags; - uint16_t setup_move_size; - uint32_t code32_start; - uint32_t ramdisk_image; - uint32_t ramdisk_size; - uint32_t bootsect_kludge; - uint16_t heap_end_ptr; - uint16_t _pad1; - uint32_t cmd_line_ptr; - uint32_t initrd_addr_max; - uint32_t kernel_alignment; - uint8_t relocatable_kernel; - uint8_t _pad2[3]; - uint32_t cmdline_size; - uint32_t hardware_subarch; - uint64_t hardware_subarch_data; - uint32_t payload_offset; - uint32_t payload_length; - }; - -static __init int bzimage_check(struct setup_header *hdr, unsigned long len) +static __init int bzimage_check(struct bzimage_header *hdr, unsigned long len) { - if ( len < sizeof(struct setup_header) ) + if ( len < sizeof(struct bzimage_header) ) return 0; if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) @@ -73,7 +34,7 @@ static unsigned long __initdata orig_image_len; unsigned long __init bzimage_headroom(void *image_start, unsigned long image_length) { - struct setup_header *hdr = (struct setup_header *)image_start; + struct bzimage_header *hdr = image_start; int err; unsigned long headroom; @@ -106,7 +67,7 @@ unsigned long __init bzimage_headroom(void *image_start, int __init bzimage_parse(void *image_base, void **image_start, unsigned long *image_len) { - struct setup_header *hdr = (struct setup_header *)(*image_start); + struct bzimage_header *hdr = *image_start; int err = bzimage_check(hdr, *image_len); unsigned long output_len; diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h index 7ed69d39103d..8c54b21d0685 100644 --- a/xen/arch/x86/include/asm/bzimage.h +++ b/xen/arch/x86/include/asm/bzimage.h @@ -8,4 +8,43 @@ unsigned long bzimage_headroom(void *image_start, unsigned long image_length); int bzimage_parse(void *image_base, void **image_start, unsigned long *image_len); +struct __packed bzimage_header { + uint8_t _pad0[0x1f1]; /* skip uninteresting stuff */ + uint8_t setup_sects; + uint16_t root_flags; + uint32_t syssize; + uint16_t ram_size; + uint16_t vid_mode; + uint16_t root_dev; + uint16_t boot_flag; + uint16_t jump; + uint32_t header; +#define HDR_MAGIC "HdrS" +#define HDR_MAGIC_SZ 4 + uint16_t version; +#define VERSION(h,l) (((h)<<8) | (l)) + uint32_t realmode_swtch; + uint16_t start_sys; + uint16_t kernel_version; + uint8_t type_of_loader; + uint8_t loadflags; + uint16_t setup_move_size; + uint32_t code32_start; + uint32_t ramdisk_image; + uint32_t ramdisk_size; + uint32_t bootsect_kludge; + uint16_t heap_end_ptr; + uint16_t _pad1; + uint32_t cmd_line_ptr; + uint32_t initrd_addr_max; + uint32_t kernel_alignment; + uint8_t relocatable_kernel; + uint8_t _pad2[3]; + uint32_t cmdline_size; + uint32_t hardware_subarch; + uint64_t hardware_subarch_data; + uint32_t payload_offset; + uint32_t payload_length; + }; + #endif /* __X86_BZIMAGE_H__ */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:20:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:20:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460972.1671868 (Exim 4.92) (envelope-from ) id 1xLGsZ-0002n8-Ey; Mon, 26 Oct 2026 09:20:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460972.1671868; Mon, 26 Oct 2026 09:20: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 1xLGsZ-0002n1-Ax; Mon, 26 Oct 2026 09:20:31 +0000 Received: by outflank-mailman (input) for mailman id 1460972; Mon, 26 Oct 2026 09:20:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLGsY-0002mn-Eb for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:20:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGsX-002W7F-Rc for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:20:29 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1b50-8faa-0a2a0a5109dd-0a2a4505bd04-36 for ; Mon, 26 Oct 2026 10:20:29 +0100 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 6adf1b5d-4cb1-0a2a45050019-d155802ab1f7-3 for ; Mon, 26 Oct 2026 10:20:29 +0100 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a2153c8525so16326575e9.3 for ; Mon, 26 Oct 2026 02:20: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-4a4cb7bece3sm125050545e9.10.2026.10.26.02.20.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:20: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=1793006429; x=1793611229; 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=gZZtdeo0r13OowMhI6KbVaMLgC5sVk5HN/T3NQ7FqB4=; b=gMWrFm+t1mAaxAIh+sF73jIl7RthmR0/Cc9SHERBMlVxGgVe1PyTpaINv5mn0WiQxy DKBHF/Nm7DHmdAVhKkOx+gzfCCDYY8yCDYi01PIvgwblj7bHZKxKHv4IjtUdu95PFLXQ 8aWhT82G/MBW3/e4FEMGNDC7LO0bcH094uZ1PoWurnKW4dG192xcpV820DWMYydZklBc dsHjyXOlR3c+aXh1XkC4RB+PAlPwHy/WjDwr4/1k+Ck5GyskJ/5NmFll+Wk6U2jXJCTK dwpDzXOoqFPKnbGIAlgjwveH5KvFkIG/bVZ01K2sQeJVSWEyuivPUI0hWB3u2vldv897 Aa4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793006429; x=1793611229; 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=gZZtdeo0r13OowMhI6KbVaMLgC5sVk5HN/T3NQ7FqB4=; b=u8WngVNj2pVLNNTuwYg8BjoDCbGzJ1J7BnfkQ8nY3BDL+Wyh1L3VId8byYfEj6BpdQ Z4ZQdsJu2gD2vg6kokBEQH4LycwUmHgCEOj6f/vHue2V5V9XVCvscJjYH6nAXRyZIewl RttS2R/aVSJy0bLQcabpnU7Q0PmtOUMYdFwdq5mee8qFv8+t3Y9RIkPlGoMXH5OrrSwQ BgpXjbX47idqWJxnZXsC+Qw+8D9Hf0PyCoTskgp4XY/6vlL+1GXL+c/TnjtLt9T/qE/a QxHfBicbo5pV8cXr/v1AiMvyh0A5th7Bw+ElrPlIuhKUQzIRT+6JGCnMWmrjqXzmxN9Z TdOQ== X-Gm-Message-State: AFq9FYLvKyLgojdt2OVMcz/ejZPfx7/phTp2Rfv5EJ33l8LFa1+fztgH teK/rdKCdN9FjFLLmApeZlWAaviOkM0M6xR59F70TqHV7mhzSaCmRPcFBuorUqKrWA== X-Gm-Gg: AYBFou2ZVdA+DhmUP50bFMTCBeY34kl4V4JtpGogJ/rCnTbu/8GoH037KjircHaRNAr SDRNdabJgQJ9b9Fiv1QKDLHPVPyxo+zz9hxk4wsIx9ZES25iQYPY5aTfqpIHJiAT6jKLG6lU0pE aZ0Ma9vY5BxmjS7rQcvNmtL/l8D+QHMh9I1kX7tzSzHvteB6pwvPvkCHYSyxdG68dXcQSWjeMYj Djd+fqm5awc3tYpPaamiJlAKsmGJNx+J+VKqdg6+1Ao5jwkXirax9IS6GFsf30G183PuhOIAPie +03bEcXLtFHHAApBaD/9POQftwlNlBCeCrG1cvVXfz95plqUpEUMRAEG2u7RBTrt2eJ7w/w2j4s IrDc+2q9GwF0Fj9pMN2kQ61KaneQ35k+1fHujlkG/yyXifN3i1KEuf+q7s4+d3kdHwNMZIKpuHM P5QVrXIOIar+a51dBHzdnhOJ9MyMBhFXCQkE69OIHSuEDPZW4UPkCNWen8OXu6v5l08HsejyMfq hC8DSJ6Xiwsb1KhLezvobfwMHK9PajIVsAVm7LNTZYvmtaSycYb1ibdpiueyez7sQ/Tv8+NEvEX PE24XWyDrcY0LvMN4p+TmoL2mYQAJxy+rYanEjlE1oY= X-Received: by 2002:a05:600c:c09a:b0:4a4:3a2d:15da with SMTP id 5b1f17b1804b1-4a43a2d1805mr72509195e9.15.1793006429226; Mon, 26 Oct 2026 02:20:29 -0700 (PDT) Message-ID: <8bb8d015-b9f5-419f-bfd4-e2810eda4fba@suse.com> Date: Mon, 26 Oct 2026 10:20:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 4/6] arm/sysctl: Implement cpu hotplug ops To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Teddy Astie , "Daniel P. Smith" , Mykyta Poturai References: <2fb71ea8cfe221f25b1dbbb50bdc5a74be09194c.1792480416.git.mykyta_poturai@epam.com> <87y0bpte78.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: <87y0bpte78.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793006429-F64B42A1-908E9BB5/10/78276251493 X-purgate-type: spam X-purgate-size: 920 On 23.10.2026 03:09, Volodymyr Babchuk wrote: > Mykyta Poturai writes: >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -648,8 +648,8 @@ config SYSTEM_SUSPEND >> >> config CPU_ONLINE_OFFLINE >> bool "CPU online/offline support" if EXPERT >> - depends on X86 >> - default y >> + depends on !ARM || (!HAS_ITS && !TEE) > > I don't think this is correct, unless RISC-V also support this. I think this can be looked at both ways: Yours or "RISC-V implements arch_cpu_keep_online()" (even if only as a stub right now). If there were constraints there, they'd be added here as a 2nd "depends on" if and when the stub is converted to a proper function. > Maybe introduce HAS_CPUONLINE_OFFLINE as we do for similar features? Irrespective of the above that's certainly an option. It might also help with the unreachable code issue pointed out earlier. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:26:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:26:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460981.1671875 (Exim 4.92) (envelope-from ) id 1xLGyT-0003Nl-0B; Mon, 26 Oct 2026 09:26:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460981.1671875; Mon, 26 Oct 2026 09: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 1xLGyS-0003Ne-Tu; Mon, 26 Oct 2026 09:26:36 +0000 Received: by outflank-mailman (input) for mailman id 1460981; Mon, 26 Oct 2026 09:26:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLGyR-0003NY-NV for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:26:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGyQ-002XOf-Se for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:26:34 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1cc4-8faa-0a2a0a5109dd-0a2a450397c2-24 for ; Mon, 26 Oct 2026 10:26:34 +0100 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 6adf1cca-fae8-0a2a45030019-d155dd35f04f-3 for ; Mon, 26 Oct 2026 10:26:34 +0100 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48e04773687so808517f8f.2 for ; Mon, 26 Oct 2026 02:26: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 5b1f17b1804b1-4a35a0a9cafsm192708315e9.5.2026.10.26.02.26.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:26: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=1793006794; x=1793611594; 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=gaGO36gSEPYcn7Mp3rAIMpcHZaeEsH3//SiEMxr+Bos=; b=S15jnX6GUIfYZd6us7zC4EwMbiBVefNZ+nozuComtNN9U53rgN0lJHOCc4kr11ck18 lGI927JRcRJJ0/b/ND6JLezTf2dvVx69vg4Sxd6It7qMnQRjtrSX1Lko7LQKjWPowoQc 4r19SXmPk8Us0MllrWVMh5Iv9p/DQFv5J7iHsCrxfd1GrcpTDNLm7PthNmvvVcS4RtCw 6Bi/wWEZzLV0Jv7q7ef/fNtV/biIJJ0ZC4lHKbrSeBuf8kzGHLukN2qHvbPWan6CTZHC r417CQHI80kXNRkEpmG/bdmeeYeVv8kwV9AbAf/nlb1+sD67bk6M6Ivfhnuf4r3P8aCG MtWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793006794; x=1793611594; 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=gaGO36gSEPYcn7Mp3rAIMpcHZaeEsH3//SiEMxr+Bos=; b=RCX8EbcEuR3hlaaH/D67P2EZ+1B373UGVpVZ84Qe2BzWAeSZc3V1r6qysQ57nEbFoX Fpq3i5sC3jjZETnPiBm+pFc+AowSkSyWJuUG25agbgiQvGlpSpkFEAPkJMusN5gKz483 arlOZvzCSulvLJqPErP3dTKqCbmKqMTi1E61QocsuxXam5LhVIyvMxZAGtLlDewgoXAz cDtWinc7Jp4uTuNjwe+x7R8gMQ7WaU1gAOUIKEpxfDbLfgX/0+b9//gGI1S1wVxw6JLm LWozNwifF2nTMCPtV1DSbYSTe/s8XSxag+B7D6FxfXXBJS6b9ZHXVGwYm/2CQ2gP7AeC IRgQ== X-Forwarded-Encrypted: i=1; AKwUvBwNnOIyClore8WfPHKyH8rCt0eA/LCZegiE/LzGsp/z5Bb6oVYEeLK3famzi+q9Mg/0MP+cgVUwgnk=@lists.xenproject.org X-Gm-Message-State: AFq9FYJSBK4MlxpFpnKlG2Tm+IXQ2pAyricKhe7JD4lDL5VGY4SQVT69 hh3oeOf9NEtO081WGcwzDnuuZqppTOMp8NrwhlkPAnQlOaCZo8nrCpPDtahrNasuzg== X-Gm-Gg: AYBFou275aXUGLFTsYCclxWGaCDJd47cLUUJLKbimsTwzs2JzHqWJUhAPMGoXlfqQ3T N6dMRG7JMkOVjQtD5/L8/D9tAEL6FSsfxjk32YtF0STRlrfviLsmwLoK/mFdYC8dCJJ77uxFh6x v6h5M1zzqjUH2PxjLLb/U0uUoqaEn+kG9ow/4tbV9wEtsn6ZbCTpIIJKA+gdtVRq4NCvYJLpItW 5v+z2DqEkxeZOdnPh5cILpxdtIIUvl26/gAMG/LcN0gMCKfKoML/t7rntu3o+QoehozcI24Cbyo vr2ZBn2x7PdunHKitWWP2Dh4xaz1oKzvcjIsZEDLE7jp9p337Dld/UiJsisjdIWkQhLmJjFM4w6 ItEdjJM08XMeut9bCORRruOHTmtllm80rHtXmTzBnaJH9rqw7mWT9BjfI9aw57h7RVWccFpJVcb kjNMmZgqj4WbJsgVwP3ymjFN9iFWOW/EAJWL0dNMDHPjFXSEvk04xC2roImNz9nsXjZhohrDlI0 tPyVVvOb3oPSBTbT0cevBkTtiQB4REm/eNho64xyAGOm0JygGZdvA4kWdHMc2I3SE9AUBe7twZK zzDocXGwtrLXNxQGtfrFECQd8JhDnuRQW3xaARiYGH8= X-Received: by 2002:a05:600c:4704:b0:4a2:1612:637a with SMTP id 5b1f17b1804b1-4a35acbd575mr120992755e9.16.1793006794187; Mon, 26 Oct 2026 02:26:34 -0700 (PDT) Message-ID: <6ae519b7-61a5-4bb3-ba58-2685cc953556@suse.com> Date: Mon, 26 Oct 2026 10:26:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/4] xen/riscv: use pte_is_valid() in pte_is_mapping() To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164866.8631fc262581453bbf619ec5b2062170.1a14559a8f00008425@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: <1792164866.8631fc262581453bbf619ec5b2062170.1a14559a8f00008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1793006794-750864E9-C9FA785C/10/78276251493 X-purgate-type: spam X-purgate-size: 1222 On 16.10.2026 17:34, Baptiste Le Duc wrote: > Use pte_is_valid() instead of open-coding the PTE_VALID check. > > No functional change. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > Reviewed-by: Oleksii Kurochko > --- > Changes since v6: > - no changes, already reviewed and waiting to be merged. > --- > Changes since v5: > - no changes, already reviewed and waiting to be merged. One of these isn't correct: You moved the patch ahead in the series, which changed ... > --- a/xen/arch/riscv/include/asm/page.h > +++ b/xen/arch/riscv/include/asm/page.h > @@ -187,7 +187,7 @@ static inline bool pte_is_mapping(pte_t p) > /* See pte_is_table() */ > ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); > > - return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); > + return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); > } ... patch context here. That's a non-trivial rebase, not a "no change". Further, "waiting to be merged" isn't quite correct either: There's still an ack missing. Which is only coming now: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:27:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:27:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460986.1671885 (Exim 4.92) (envelope-from ) id 1xLGzM-0003pI-8e; Mon, 26 Oct 2026 09:27:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460986.1671885; Mon, 26 Oct 2026 09:27: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 1xLGzM-0003pB-5R; Mon, 26 Oct 2026 09:27:32 +0000 Received: by outflank-mailman (input) for mailman id 1460986; Mon, 26 Oct 2026 09:27:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLGzL-0003p1-0B for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:27:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLGzK-00FznV-6I for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:27:30 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1d01-2eae-0a2a0a5409dd-0a2a4505d214-2 for ; Mon, 26 Oct 2026 10:27:30 +0100 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 6adf1d01-4cb1-0a2a45050019-d155802adda2-3 for ; Mon, 26 Oct 2026 10:27:30 +0100 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a2084d62cdso21662815e9.1 for ; Mon, 26 Oct 2026 02:27: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-4a35a5698f1sm182719755e9.8.2026.10.26.02.27.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:27: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=1793006849; x=1793611649; 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=1yxdFSvoGm1tiD5mW+muhqSQWQzX3PlEBtKQexFJe5U=; b=Wqb3CE78sKYsKINbVhs6CWqSwSYnQsWmAnfgU+vqbr2Mv/wURWsEzjWYm+b3wlzyAr H/Qkg62PGIVuQPR15Je6f9SuaL+U+QwHrkHPkG3pJXBBA2yqK7G9MzD0QncdEdrVDatU eObVWL+n4PWA84z3DHEv81Ti6g05mzSXehBKoSXkQC2vBc7/EcbrQzMDfn4/kobmTE1O MItYzdtShX5p3Imsxq7jvG87RP+Qvx7D/joJXgI+kcIRV+Dzm5QtQ8Q6pLwI2EJFbXOy AYSRO6vZ3WPVEXzPpqNnCQPD1ZaUOafNNVtS6Ss0CD36bmgeoXeK0pFQYmQNpRdUVO4X 4hOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793006849; x=1793611649; 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=1yxdFSvoGm1tiD5mW+muhqSQWQzX3PlEBtKQexFJe5U=; b=xB/vVibjvIxkpM4rnT6TWyK318DP0g7uetf60l9zaMeIrfE1koY0tEkkuOq2UUxsN4 xxiXcbIZEfIwxjmjHuHxx+Q52CAGzmOxDYys6zDc1MpdxwsH/HunZ2GrYRO5z8RYWxNH iOztCkFdPjTvWHwFmPDlD0mDf6aPtNBt0lQxQCRR7CpbbFn5cYjNF1FQ0V4Ve3cdImlR 0KyhVv8US2BasLfMFwzJnSI3LHWDRMMniyPRd+MGwR0YbGOiXOGu2/TjTcoT+tCjE07O X5D+cDc8ZHpHCfDtYgef1SoC6F03tVlsjoiwMCjrBxnEk27SF3hOhbctW4F85fbliopE 1ZGw== X-Forwarded-Encrypted: i=1; AKwUvByexTqa/Ue9VoNvL+/8hJ/I3QsZr/sVQttGM3jQ3f9R12VksiTeIxBS0QakmzTsDrhqic00Xv1onXc=@lists.xenproject.org X-Gm-Message-State: AFq9FYKiuRHWBnf9mcdKJq8daLz7jtQlAWDJb3D4TfR111dd9Cg8nGPR GjYm2ejCV4YVONcEkttcPNU4t1hZvK6PYLQum2lIOeUh3LxH97VDuvON94pqA5afhA== X-Gm-Gg: AYBFou3FGUngv8SfwC0/VB+8f6ZGXO/4XuIp/2IBhOe6+fogmeDzmqVZYi/a7rnEuvT bi6zGcyOygKJ64v+EApwjwhgSRfbMxDYsyQKX3r3RpGJO1UiNoEbA/0lXbVOcON9afsIdyOAj2l Q6M8TOi3e0bR2spSqIRB2aCShNtMyJYgmxgGYlPZ/peersSe8NeMU1HRpw2CgsKoo55zcmwfZmD h4WWj29k3hHBKflLuZfV8fzEwQs5nG+sst6yxF+van090aulYHzwIx2Ppi//G0Y47vvnaXa/Moj X22+ESCVkoHrCdcpvqcJnOoMlK+JAeOPlY7+saVI7Aw2EAD9gXvQ0MhGVCLCT3WUgrrBV/N0j9B 1emRrXJCHekWwVsOlOiE9yIZj93RhUOqOdaB5MzYAnKO6eEfgJka4sdkvrdHP1zQiry2OopJW3B 3ldrgqL9UXs31yxkwUN1sP42/8AmU5eDqTt2Inur1dh8EKmHCgv1De7iTzMPXt7Ank6Z4pJjE6f Cj3DCbgoD4gZy9o0m93Y1DwXdrdAbUgAsx7m2U6o6qXT+Vj9aj7jjBO+vragB73b8C9iuJ6LQ8s HAjM/ZcK3xKtF+iumFC4iwP4i6GnvEn6DkX2BXoeIoWoSpmYjRgOZCAnqHrWk39e X-Received: by 2002:a05:600c:524c:b0:4a0:1c94:7042 with SMTP id 5b1f17b1804b1-4a35ac8bdc6mr111086315e9.8.1793006849580; Mon, 26 Oct 2026 02:27:29 -0700 (PDT) Message-ID: <5bd6b475-5f3b-4a25-b140-427005a4e1ef@suse.com> Date: Mon, 26 Oct 2026 10:27:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 2/4] xen/riscv: fix A/D bits in Xen's page-table mappings To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164866.8631fc262581453bbf619ec5b2062170.1a14559aa020008425@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: <1792164866.8631fc262581453bbf619ec5b2062170.1a14559aa020008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793006850-738BE2A1-CF54284F/10/78276251493 X-purgate-type: spam X-purgate-size: 2318 On 16.10.2026 17:34, Baptiste Le Duc wrote: > Xen does not handle page faults caused by clear A/D bits, so it presets > them when creating PTEs. pt_update_entry() does so, but three places build > leaf PTEs directly without going through it: setup_initial_mapping() (the > boot page tables), check_pgtbl_mode_support() (the temporary root entry > used to probe SATP mode support) and arch_pmap_map() (the fixmap). > > On implementations that fault on clear A/D bits (Svade), all three fault > on first access. For check_pgtbl_mode_support(), the fault is raised by the > instruction fetch right after the SATP write, before any trap handler is > set. > > Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build > PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in > all cases for consistency with pt_update_entry() which sets it at runtime. > > 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 check_pgtbl_mode_support() to > use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. > > pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one > of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by > masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also > carries A and D, a reserved PTE with A or D set would no longer be caught. > Mask with the V, R and W bits explicitly instead, and factor the check out > into pte_has_reserved_rwx(). > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") > Fixes: f89e1a170299 ("xen/riscv: introduce asm/pmap.h header") > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > Reviewed-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:29:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:29:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1460993.1671893 (Exim 4.92) (envelope-from ) id 1xLH10-0004vs-JI; Mon, 26 Oct 2026 09:29:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1460993.1671893; Mon, 26 Oct 2026 09: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 1xLH10-0004vj-Fp; Mon, 26 Oct 2026 09:29:14 +0000 Received: by outflank-mailman (input) for mailman id 1460993; Mon, 26 Oct 2026 09:29:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLH0y-0004vY-F4 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:29:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLH0x-00HGtY-Ks for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:29:11 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1d63-2eae-0a2a0a5409dd-0a2a45098f88-24 for ; Mon, 26 Oct 2026 10:29:11 +0100 Received: from [40.107.209.29] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf1d64-be1a-0a2a45090019-286bd11d1a5a-3 for ; Mon, 26 Oct 2026 10:29:10 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB7986.namprd03.prod.outlook.com (2603:10b6:303:276::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 09:29: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%4]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 09:29: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=Gq6vVpb2p0pG6VxXQ7FsDNWCWFlnoBPqNaY7tQSotYPvoanhWDX2UQWzlYPX4+exkx6K2JRC1GYD/PyKIEO/xlO1Yfvc/qyEIfolRWf9nfjKsPuCYRj3KCx3VZhFkppyrIfz8572zVt/QEFeA88IF0npfsd1qjCBaQ7YJgFPVD56dwkRQWyi0La1kpRGbJ1uKPPgK57vfc0S/+agoZSSO0rOEOuSioIM3Z0Sx2+tJkfZ+yewVmU7ujJaDr1EKumqlQgyTz7XjFYethX50tSXA3uU/U0hCxt19VQVZ55s/sWoMPIb9zlL283QwxxMJbowJWb3SaDzh5MozeG+Z1DMbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gxw3faFySc2Vebb0SR0LoNqsfTts2GI2iOQHqAX/rhk=; b=Yp42qEGXO6UcB0G8E+SQqTzgs5HhNWO3+Zs5pk5mJXEszZLzXxOflcpeHuWb39D1eKC2zXvvyckDFSXqbZyzuxniCdL8M+BlYOdWlVBnE7xb2/axCJI3HUYbeXHfnCTDzk3QGrwN/BPp2ISGzOYy3VUARIOk2Jm5lSdNIV55sXHbyOM4Q+XUzr2EgaIZKgFTgOOxhZlcCPz02E1SwmdSfZsW6gs2QzG6eKwyz6e7bSv+91jxL+MlkIijf7Nb3yg3oOBcw2t/iCpFP5SF/Znelt481CIIX9bjU3tjXFvFc5nN9CrE0CHJOIbMhm0XRx6w523vS5079Z0zISp5CP0riA== 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=gxw3faFySc2Vebb0SR0LoNqsfTts2GI2iOQHqAX/rhk=; b=XcpuCVPTEVYkmH7s3vS9DF07NbIatzbwwzFa8kpP+8JM18H8GW77Tu0+IV1IctMWT2eXbHFMbs33S5rfEJNVC/KflsPhHEBnlDyUM4KIdB4E15DYzAvRS2qfD6PQi/8B+Ve5FrEoKWnCUtAPkHljUR3f+7O+Hhs2rtrVi8aivB4= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <432e0fba-0765-4c2c-866f-faff8cd04926@citrix.com> Date: Mon, 26 Oct 2026 09:29:04 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper Subject: Re: [RFC 0/5] Introduce dynamic tracer using Livepatch To: Ryo Takakura , xen-devel@lists.xenproject.org References: <20261023044809.162759-1-takakura@valinux.co.jp> 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: <20261023044809.162759-1-takakura@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0008.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::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_|CO1PR03MB7986:EE_ X-MS-Office365-Filtering-Correlation-Id: 548a784f-8fba-4a22-4b38-08df33439538 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261022075727099003|261022105027099003|261021121427099003|10067099003|56012099006|3023799007|6133799003|22082099003|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: NYGUucxBoP/iVDOsbie1yty9OD+tdewFWUSYw2ZHAneyvVqq0Dtb1/v4DcMsRtPIPg96df6poVR54Kn+ujyTqzP/oXMbEgZSVgQA+3JYGDe4h1gpsDPGUMrAYTuOW2rR6FtdT+5eWZC30l/l3f2d26ndAyoUK/8B3AenNhtBYhYBOtmIZ2nyGAKhCuKqNlnoaQgDDpmipR5BXfeFcIVsL+qyTcasEwZCP5z9PTeY+O8bWe+0/wo+8y0ZPv9eHo3yK0nZ0XYxFV7OCbm7nEqGK/onhl8uFQV1EsFirzcRT6vYLx4sL4Qx4ZPNS11A+DpDcXmicBZzvXZC6D47h1c+j4Y6vglUnq1DA01eyaNVLYfmNmNDaJVs6tNvnHYcuqHCPXr3Hgm4w2Wq4ZPIdYT0mB+uixt/CNadlkyy9Tpzl59PbNruLcfvlklRR9H6I4Rr5jNSe1v7FGY963AkRFvgCPwJXY4XeCVA/YAqjS5Pe+UHBW+42iq3oGwmtzxUrCFnTFdfzbNQsugNX7n+5nlYPwMhfOuQuHvL5I6R8VaH55r70aEHrXh9m6UsQEVCxDqGJiNyGMKu0smrT9mQugJo91UBYgrD7D3QQBTd73+WNh29Q2RObdbHXCsWIdiYFJfF 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)(261009223027099003)(261022075727099003)(261022105027099003)(261021121427099003)(10067099003)(56012099006)(3023799007)(6133799003)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T002eTk0RDJZeloyYVFDN1c3cEUrTE1DVEdWbWVMTlBoMFAzTWZDbm4zRlRX?= =?utf-8?B?a0NXUVpmSzViVFcyNzNaaVUzZGxjbVVyOW1vVFQvMW5aVTZoUlhBL1pUWHRU?= =?utf-8?B?NmhJNUxHeVJjNjJGTVZsYVo0U0x4eFNhYUhsbFdKcFpXM0M2SEdJc1ZUcHhw?= =?utf-8?B?dE90ZS9PNjF1WE9lY3p5ZE1oRy93WVhqVzI5SXJ3MmUyRVRMUW5MVk9pQURt?= =?utf-8?B?T3dQOXR4NDFaZzZEbkVldmNmRmNjSHFsWHF4dURXakVHdloyRmhScUdRZ3kz?= =?utf-8?B?bUt1WllRWVVOWDlvejB1ekwwQW93RkRwaHFxVXZ6VDczd0JZUU5RbTVlZ1NN?= =?utf-8?B?K0hyeGhnMFhCaGtxa3JVd0JPQnlhWmR1ZlhxV2JhOUVac3MxN002NE55VXU0?= =?utf-8?B?dW1pYkZiSVpNY3JEWHV4MmN1ZnpzRHVYWUpkRllDMUtmUXpMT1hCQis5RXFF?= =?utf-8?B?Y211K0E5N2VQbE1rN29tZFllY1NmOHhxb3hEYmlHYVNJTjZSeUZoSjM4YjlB?= =?utf-8?B?czFDOTNpNXQ1cGRyUkRZbWNkSEl1cmFmb0hUUFF5c0c1Nkd4bFI1OEVUSXZ0?= =?utf-8?B?U3NySVEzTUQ5dVA5TUlRcW04Z1dTOVJ4SG41RHZwV1pQTDJZZ01nNTZvLzUz?= =?utf-8?B?czVhbG9KK1l5aWtYTU42UEJTMnladGYvY2ZZUXMyb0NJYkJHYU1jV3d2dStk?= =?utf-8?B?eWQ3MmEwdlljSUZMcFU4UGljaEtnSDZOUEVGODBvV09jOXJrMlByZkgvd2pH?= =?utf-8?B?ekR2cHQ3cHpLZWExWkFoVXMwR0IzNE9tek5td2ZvKytMQW5GdVlPVjFYaG9K?= =?utf-8?B?eTU2MGRDZjQwT0dCVUhBaXZQQStYSW51bWJnVWNDcTMvR1RCYTN1bThpWUhW?= =?utf-8?B?cGhqeVI1ZG5kZTR1SzN0V3hob090c1NsNnF1YXI2UXhPYkxER3BwM0YzVVlI?= =?utf-8?B?dTFaRWlXZUNZWEtacHJiYUZ2eUdiWVQrblNmQm1Jd2xtVGdESGk3Sng2VWNw?= =?utf-8?B?MjBsUzFodVlxM2xmSkxSVW5wVWNhb0hsdjh3c1VFcktPQ1hQb2VSanl2TU9E?= =?utf-8?B?WEdJOVpNREh1ZU1FN3ZxNitYRkJBSUMvS1BZcWNQb2JGUjJrMjA3VXBzQVRj?= =?utf-8?B?VkluVnRkcGZUTHZEUWN0SHFDUUxuampLOGYweUJJam50cXh1ZENHTTRjSktr?= =?utf-8?B?NDVqb1FhaWZBeHdabXlyYUlscDJma2c0Z01xWGFLaEJMa1dtU1B6KzkyVkhL?= =?utf-8?B?MGJmYnRsUXErQ2JIMHlSYnBTd3plV1pZWDhpMVRQeElIR0dkWC9CQnJBc0h0?= =?utf-8?B?bWZOOFY3VC84WmFleEozTmxGRE9ETlh0dXNacENlS080N3FlNFY0bGpNOHQw?= =?utf-8?B?bkdWM1ZZNnNsQjNRK0l5TE8zNE8rc2NVUS82akJMTmNScUk4d2xhZUlnUmY3?= =?utf-8?B?dE5kS3VoS0VHSWZ2R3M1RTFUV1BrSXhXSFJtb1M5a3Y0NGlTZ3N5eFVpK1Ra?= =?utf-8?B?Sm9wamhiZ29ORjNoT1c3UjNDQ2R4N1JBNlVuNHYvY3VqcjBCYVdQZzl1ZkRV?= =?utf-8?B?ZnNCcUY4WmhJdkpUSTEyQ0JVUHRkVlVJOVM4d2RFSnpIOWRDYUNaQzR6alVP?= =?utf-8?B?YkZ6VVA3dFJFbWt3YTdyRjhpVHdIZHFLQnVKUXcwSjVQN2NSZld6WXlkTHFB?= =?utf-8?B?M01YaFlCQTBVVG9vQkQ3RkRubXNmMG9HUER3K3dCYmgrSTUraWNFUERVdUZ5?= =?utf-8?B?WWg3QitOaWJGNHAwTC9iWDhMUnhCbDRTSE9yYlFmU3ZUTFowdHpUUnkrY2x1?= =?utf-8?B?aDl6TjI1bGxuZGNhQVhrOVJRRnJzQjZXdWlWY3BacVZsMnZnQ0lZR21COVZh?= =?utf-8?B?c1kwOFY4dnhIVE9PRU42Qnp5MzNZQ2lkeFhtSHdmakRkVHJLZFU3U2toRDFS?= =?utf-8?B?SHlicGhmMHZDODdic3RLWHc1NkFaNmV0M0x3YkpPS0lINHBmUlFRTHNDNmtP?= =?utf-8?B?UG1ZZHU0a0tURHd5dXFOTzREeWtjRlZPaVFIN1NRMkd4UzQ0bXhobkd6dFc5?= =?utf-8?B?Uldzc1plNzNZeUxDSjJzc3VPTGxOSXBQRlhJOWJBR0o2U1NUWFJDL0w5b1lB?= =?utf-8?B?ZXRJdFlnY2drMEpWY1F5UUF4eGwrcm5PaEMzNUx6anJFT1l2aHRJaWNwa0xQ?= =?utf-8?B?YnhJY2JNa1dJbmFHNGR5R0RpRVNQYlo4Nm5GRlNvNU4vSFFydUNKcW80TTRw?= =?utf-8?B?dk9pZWJtaEN0S2piRm4rZ0JvWXp4MTRDWHloNEZ6cXJndFpoaDZYNXRMWUJY?= =?utf-8?B?YUpMY1ordFpaT1dCa1YwbjBjUmtMcGg0YVh2V2hrRXk5MUcyeEdCQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 548a784f-8fba-4a22-4b38-08df33439538 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 09:29:07.1107 (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: Vz38g1z8v50syswQOzikq6dVNRgcalvqpwsQ1BJQf2qGP1WHw27qeq65cWs6w8cKGoXgHwks5eDvZDjlth2Kz484dP2FJWOdQcAfGmZA66c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7986 X-purgate-ID: tlsNG-bad1c0/1793006950-BF0DD034-F560598C/0/0 X-purgate-type: clean X-purgate-size: 2158 On 23/10/2026 5:48 am, Ryo Takakura wrote: > # Configuration > In addition to Livepatch and HypFS: > > CONFIG_LIVEPATCH=y > CONFIG_HYPFS=y > > Enable the following configs: > > CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY=y > or > CONFIG_X86_PATCHABLE_FUNCTION_ENTRY=y > > CONFIG_LIVEPATCH_TRACER=y This ends up having two almost-identical symbols, depending on architecture, where really this is a common piece of functionality.  It also conflates several different tasks. I think what you want is something like this: In xen/Kconfig, create CC_HAS_PATCHABLE_FUNCTION_ENTRY which performs the $(cc-option,-fpatchable-function-entry=0,0) check. You are also going to need a GCC_PATCHABLE_FUNCTION_ENTRY_BROKEN symbol, because of https://godbolt.org/z/sde4faxaz.  See the ASM_GOTO_OUTPUT for another example of this pattern.  Just use a plain version check rather than tying it to XEN_IBT; this is a new feature and people wanting to use it can use a new enough compiler, and it avoids variability depending on other options. You also want a HAS_PATCHABLE_FUNCTION_ENTRY in xen/common/Kconfig, which you select from the main config x86/ARM/etc in each patch where you add the architecture support. You want the single visible entry LIVEPATCH_TRACER which depends on HAS_PATCHABLE_FUNCTION_ENTRY and CC_HAS_PATCHABLE_FUNCTION_ENTRY.  You want to make the text architecture-neutral.  Instead of the exact number of NOPs, just say "reserves space" which will be entirely fine; the target audience for Kconfig text is sysadmins/distro integrators, not developers. Finally, you want PATCHABLE_FUNCTION_ENTRY which is selected by LIVEPATCH_TRACER, which triggers the Makefile changes. As a general note, you don't need "default n" lines in Kconfig.  That is the default. All together, this separates "can the compiler do it?" from "does the user want it?" from "what to do when the user wants it". Separately, you have a number of MISRA violations which you're introducing in your series.  I see you've got cf_check, which suggests you have built in GitlabCI.  Have you also run Eclair? ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:32:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:32:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461000.1671902 (Exim 4.92) (envelope-from ) id 1xLH3z-0006sX-3j; Mon, 26 Oct 2026 09:32:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461000.1671902; Mon, 26 Oct 2026 09:32: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 1xLH3z-0006sQ-0t; Mon, 26 Oct 2026 09:32:19 +0000 Received: by outflank-mailman (input) for mailman id 1461000; Mon, 26 Oct 2026 09:32:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLH3y-0006sK-L1 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:32:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLH3x-00HHrn-OT for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:32:17 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf1e1d-2eae-0a2a0a5409dd-0a2a450aae2a-18 for ; Mon, 26 Oct 2026 10:32:17 +0100 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 6adf1e21-f2d2-0a2a450a0019-d155dd31e969-3 for ; Mon, 26 Oct 2026 10:32:17 +0100 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48bbb06e746so1367119f8f.3 for ; Mon, 26 Oct 2026 02:32: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-48e3ece5e4asm15092766f8f.59.2026.10.26.02.32.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:32: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=1793007137; x=1793611937; 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=qHZ4nHZIxY5bOG20vVfClMtLKxpG5JqFZuL2RP/Af00=; b=Azi6GfTP5YiFNWzh28QdnaudM2z3X61Jnk2+hjp6R7HKssIrVDm7ILPkPmSEFUznF/ sTso11ZVNk2jywKUMb4qwbj9C+64BNAB/WdBytotKVIWBNOeKyVYsoo7vHwE4/A1c9ob SsoY0+MVWA3tvUNE0t4Z9EpMFzzySyAcm+cEQfQSXkmXIGqKXtSmgg3whlP/MQszhSLE tbn2VVOZLwQp9onM7LmzKzUGVBbvAOB/Z2LXjuIg6y0pmli1vkVW8VLprB2tnnwwIEF5 ST+IoOnux38S0gaqdhUYdyzwOqXJ/k+iYbB7LMI+wbyg2x7iuok9BrQVnEhqHq7u39YD d6QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793007137; x=1793611937; 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=qHZ4nHZIxY5bOG20vVfClMtLKxpG5JqFZuL2RP/Af00=; b=Gui8IdjTdPXdP9Yog4JNBZfRX6T0BuUm+1qmi/OvXVKEoqGmgbaDV9yJMlHoxjXouN F5lnl4vtKV22/wVzXYCoYZ/e7vp6e1263YSOg72eAigg1qXIFt3EJUanU0DcYdb0gAyr ZCVB1Nu1mS1aev31+N4Ut9o0l+XTw4fIfd+NhkhL7siGMEJ5U2m5EzTlJlotKZvL0ave oOBz5wffEbtdMZgxoswlZrxWPPZ27EbgR4tRn9xiT3GiwI9ykZ8iOA2+mX0SQGSY507H 4hrywwVRY3PHVGOS0pUxmaI8libMm8QcOtvFqmFRR2+NcYrDFHO8GB4GejNo0wfbnrvU E3HA== X-Forwarded-Encrypted: i=1; AKwUvBwOAE4DTH9jZS39OaRZHT0+ol438jkV/Lh154nKtDxleJ4TJLqb28RJDdvDjFPpX6dNqGmSVQoisfU=@lists.xenproject.org X-Gm-Message-State: AFq9FYLLNWIPPe59ZJf6JiDQWDJ9aY1mY80GjCCSZuY1TvBozIesb3JV 6QlkcsQPnuPd78Rwn04shlUSoI8V//8mZ3inF0okMtdxT9i3eMozf4iRSEhoIK6oPw== X-Gm-Gg: AYBFou0uK+npCDPgbmEzxAFV0q78awMz4KqoUR7d6o7v/E3GcUgWPQ8LwhIw9MHcpWE 8mErRQv+IshC1QPYZPnxZADwP+8Soazzu7p9ip4dO6HcqnTtgjzI2mMwJh119zxsbxM/hjLGHwm nNLkqFQj2J57EFkz1h4N+kTXu7CAAtXGk3OKCjrMOdLFrfk/rT1eJOZTRctE+A5N8UnlZZnQrUX 4g4uCCMy+uanl2qEnStZ3KfylVbRC+mLc+pz0zOqdZrfRUP4dKe/0ElbVhsVhd1kaiU01/xs6CB iYL2GqbYzrc2zOt6rcNYOXEM+bSoWWsvBXzwAVBxagE1h11VilLBnph7bz4fWk0AmPJ5CYvZy+Z PQ+yO2lnA0mFa15YHJ1Oqsz1NXJqCqJ/HNjLxYVvvn9wIleS0L9AKxxSnCrFg0rOfrc7OC6sHkz hlUn/+lo7sPv2ko+WPTopltu866nB8rbkCixDWHQ2BCL+mfiRfo0rb553vskyIEaqef3hvkoBkL LPNNH3gHc6jDk/H/ZTebptjAsz+kExqz/QoT08vFheQgMY9aehjGJTHXqheXl5LszEcgQoLIlDp i5VGdz5duEPxA1CPC9PGSyNJFQiLi6AK5kJTNEYJz4X0Q8VYJYSIenchmJYUwDQy X-Received: by 2002:a05:6000:2c0f:b0:48d:b940:af7a with SMTP id ffacd0b85a97d-48e3eba36d3mr11605824f8f.55.1793007137015; Mon, 26 Oct 2026 02:32:17 -0700 (PDT) Message-ID: <4526ac23-ca7c-40e2-a9d6-9d366369d3bb@suse.com> Date: Mon, 26 Oct 2026 10:32:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/4] xen/riscv: panic if the device tree advertises neither Svade nor Svadu To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@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: <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793007137-518C5CFC-CAA5D9BC/10/78276251493 X-purgate-type: spam X-purgate-size: 2737 On 16.10.2026 17:34, Baptiste Le Duc wrote: > p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when > RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. > > The privileged spec allows exactly two schemes for updating the PTE A and D > bits: hardware sets them on access and on write, or accessing a page whose > A and/or D bit is clear raises a page fault so that software can set them > (ratified as Svade). Every implementation uses one of them, but platforms > designed before Svade and Svadu were ratified, such as the HiFive Premier > P550, may advertise neither. Xen then cannot tell which scheme is in > effect, so rather than guess, panic in riscv_fill_hwcap() when the device > tree advertises neither Svade nor Svadu, so that the device tree gets > fixed. > > Add Svadu to the known ISA extensions so it can be told apart from Svade. > The comment above the enum asks for new extensions to go at the bottom to > avoid shuffling, a leftover from Linux where the IDs were macros with > explicit values. Nothing depends on the enum values, so have the comment > say that multi-letter extensions follow the order of riscv_isa_ext[]. > > Suggested-by: Jan Beulich Did I, really? Iirc I left open whether to go the panic() route or the alternative one. Based on Andrew's clarification as to pre-Svad{e,u} behavior, I think I further tried to indicate that synthesizing the correct extension may be preferable, to allow older systems' DTs to be used as-is. In any event ... > @@ -674,6 +675,22 @@ void __init riscv_fill_hwcap(void) > "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " > "wire up this platform's pause equivalent in cpu_relax()\n"); > > + /* > + * The privileged spec allows exactly two schemes for updating the PTE A > + * and D bits: > + * 1) hardware sets them on access and on write; > + * 2) accessing a page whose A and/or D bit is clear raises a page fault, > + * so that software can set them (ratified as Svade). > + * > + * Every implementation uses one of them, but may predate the extensions > + * and advertise neither. The device tree is then ambiguous: Xen cannot > + * tell which scheme is in effect, so panic and have the device tree > + * fixed. > + */ > + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && > + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > + panic("Device tree advertises neither Svade nor Svadu, A/D bits update scheme unknown\n"); ... this message leaves the observer to figure out what to do about the situation. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:45:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:45:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461013.1671936 (Exim 4.92) (envelope-from ) id 1xLHGI-0001DZ-Bg; Mon, 26 Oct 2026 09:45:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461013.1671936; Mon, 26 Oct 2026 09: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 1xLHGI-0001DS-8v; Mon, 26 Oct 2026 09:45:02 +0000 Received: by outflank-mailman (input) for mailman id 1461013; Mon, 26 Oct 2026 09:45:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLHGH-0001DI-8c for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:45:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLHGF-006S9P-33 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:44:59 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf210b-bab6-0a2a0a5309dd-0a2a4509a38e-38 for ; Mon, 26 Oct 2026 10:44:59 +0100 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 6adf211a-be1a-0a2a45090019-b9ff1c23ac83-3 for ; Mon, 26 Oct 2026 10:44:58 +0100 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 1a177994ca9000f79f.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 09:44:57 +0000 Received: from [192.168.1.52] (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 2692081E10 for ; Mon, 26 Oct 2026 10:44:57 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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: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=7QvpdUDrZdrwMQVG3ZRT7tn1V+A7P6A5DqfERLNesiI=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=icEKVm0B1+wnPUGLLguLfKF8VjeVoDHKHzOQGYpaHV7oB0RoOXI3zQ1yBaHrrVtfe0tfb0Uoz crdsC2eAQxJUyzM+hgsoNZ9M9ACrOpVa6F4rZ/I2yKaN65H3szVAeYbTqVzL5AJT5X/DFOYt7GT nzmign3HB1FHh0RpnbKtV1C7d6++koNZuNkxTBv9WomlsQNC6ndX/zyDqUxAjiUhR7AyGiXBqAC idw5kKNaCfZO2wpEaCHQkVlBmI8o7YSslWhQkl2GLSg7/XXDPxLtszZhuEpkNgU7HUP0FCtuupn gF22QOLeE9E6ZsPKoCse27BPJ0hXiRqEBBFuk9Nsrr/g== X-Zone-Loop: d06c2ff08f76a6c7c7c12966eff2d75f6aef98129d22 x-campaign-type: default x-transaction-id: 61a27c6d-5ca9-4e80-9928-06e963b05895 x-swg-uid: 01-b373ea8e-0d90-40af-8fd7-ab88e4b3c80a X-Mailer: Sweego Message-ID: <1793007897.8631fc262581453bbf619ec5b2062170.1a177994ca9000f79f@vates.tech> x-swg-bid: 1793007897.8631fc262581453bbf619ec5b2062170.1a177994ca9000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 26 Oct 2026 10:44:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/4] xen/riscv: panic if the device tree advertises neither Svade nor Svadu To: xen-devel@lists.xenproject.org References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> <4526ac23-ca7c-40e2-a9d6-9d366369d3bb@suse.com> Content-Language: en-US From: Baptiste Le Duc 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: <4526ac23-ca7c-40e2-a9d6-9d366369d3bb@suse.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: 1793007897196 X-purgate-ID: tlsNG-bad1c0/1793007899-FD26A034-D393E72E/10/78276251493 X-purgate-type: spam X-purgate-size: 1435 On 26.10.2026 10:32, Jan Beulich wrote: > On 16.10.2026 17:34, Baptiste Le Duc wrote: >> Suggested-by: Jan Beulich > > Did I, really? Iirc I left open whether to go the panic() route or the > alternative one. Based on Andrew's clarification as to pre-Svad{e,u} > behavior, I think I further tried to indicate that synthesizing the > correct extension may be preferable, to allow older systems' DTs to be > used as-is. In any event ... No, you didn't, sorry. I misread your "The outlier is when DT lacks any information" as "panic when DT lacks any information", while you had just agreed to probing in exactly that case. I'll drop the tag. For v8 I plan to: - trust the DT whenever it advertises Svade and/or Svadu, without probing. - probe only when it advertises neither, set the probed extension in riscv_isa, and print a warning asking for the DT to be updated. Does that match what you had in mind? >> + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && >> + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) >> + panic("Device tree advertises neither Svade nor Svadu, A/D bits update scheme unknown\n"); > > ... this message leaves the observer to figure out what to do about the > situation. Agreed. With the above the panic() goes away, and the warning will name the extension to add to "riscv,isa". Thanks, Baptiste From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:52:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:52:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461021.1671952 (Exim 4.92) (envelope-from ) id 1xLHN7-0003cx-2i; Mon, 26 Oct 2026 09:52:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461021.1671952; Mon, 26 Oct 2026 09:52: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 1xLHN7-0003cq-04; Mon, 26 Oct 2026 09:52:05 +0000 Received: by outflank-mailman (input) for mailman id 1461021; Mon, 26 Oct 2026 09:52:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLHN6-0003ck-6I for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:52:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLHN5-00DSJ4-Is for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:52:03 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf22b9-2eae-0a2a0a5409dd-0a2a450bea3a-24 for ; Mon, 26 Oct 2026 10:52:03 +0100 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf22c3-b7e8-0a2a450b0019-d155dd32bd8f-3 for ; Mon, 26 Oct 2026 10:52:03 +0100 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48e0d1c095dso1602254f8f.1 for ; Mon, 26 Oct 2026 02:52: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-48e3ecde7easm15709315f8f.52.2026.10.26.02.52.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02: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=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=1793008323; x=1793613123; 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=sM7mexgU8u63/2C0FKJMWIK3SPvQk+d8wiFjNOgEY3Q=; b=U1hmuSogX8murpiMLQO/jm627+7fPnGJ130HnKe+PUxjZalYRbRUYeF43Lr5V8kZE9 eT1aA7PS5M5ZNtSdXz/gZAopY45iu4SkYKuUrhB5e/nmThFI9sssssocxVyx6I26oEkV ipO5w+ELe8WJC2rGLl7APQbfyBL5V0q61D6uxx6BJNXVmtf88OBAVj+G9QmsQNp+L1jk LbQWlj7YzSCSQaVuy4z4vUK7nyA7HYNvOmcu/bM/b7DK8FwvsExm2XcgvizqldP03dpq yJ9nwANYnWQJga5920JTzFGxqQ4AqdakaIr0Q+40I7gWoCTiEWhdE/NUUFiDPs+m3sP0 Ii0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793008323; x=1793613123; 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=sM7mexgU8u63/2C0FKJMWIK3SPvQk+d8wiFjNOgEY3Q=; b=mPQrGstb5pzQrd5VWEmjfAoIm9MMlZbLAQN6wkpK14Awd2dBT24NYfAgOu3Ao4KZ17 d1/9o83iNFOMSPpp/aX2zD1C8MQo73W+R7JmB1Mk8iGgJMAJCJtmqLQAIZRU8n9VTjf7 08I0kGoeiTVDwJMolZC1CDwj791hFDvUjQLtvpaVARw9uACEQ+U1uVAmUXasw3KRwVuD Z/Ss+8XfbaHJ5bRiQX7NpOEyc95N8AMeLisV2ByqKf5JZzRhDtq6UjL+ARrPdHF/Mqm/ Ofn/UHfPHCXo4CisUkJcjnjtDEnEHqidiPMjbfPECn0wgOjzbZmc6l+8KFB72yg1e3TH Ncxg== X-Gm-Message-State: AFq9FYIokkiNpb6s2TvnEl9ws7MeJfVkyFEne+LpbGQ1TiMuJXLdES4Z WMoOggwCbTC75QM4q6pXK3IUnl9Ye+CXYTNJIxnahXiB1oIheNK4fJFF0iC6W36hlTnyvK7L/pr mkYzGSA== X-Gm-Gg: AYBFou1k1srZUGPFZ90CQBpolYiz2eejdMHSavVV1g8HE2R7cx3rkvXE7XPUHS/x2iu lTuWyiN0o08UtMWaucL2V2oEUC+aYRhsswvmXR5WthA5UVRy8Zq/bDz4+dMvX6wrke+E1IqzqXv m1nrlms269vV3p5WF0sGq1gyUP9ptNULLeIxYbUienD4DobSzQSc7OiqpvD5jSFnI+iJr2jfpj4 rTMA426hXXZREBUKTUhgnCX3Vj+V0kCbx92TGgU7u+zje/6/UKCLcxG69Q/lTiIQ0h0j5pa9cG7 aaMDN5viHVV8sIc/+L/RxKgNRYiRX5nuqhC6mo0sPXTx09ySGvB7btTkyEp3nuj6rAOmInnSujj zh/rYCHrygJE3/najJ8KuGybEyDhVRamZmiNZwd95hzLC+/dV1SH5MApnyk/abwpBkprJSoLVRS gvm1UabVYAQg/dWzNzu8cPcl5sur8nlLBSmIJ4qGc7ahrS0XvLITnHrN+9JmqaU22NYQqdsyoy3 rkjmrk9cSFic/bl0nzYR12vXbecwMjoEs4p3PBABKVD2pei6jpJh+92g1GIkbL169JU90BtIVlV mEBIpAYUaCjcvcPe9ws5BPEPbZHpPnHA4l3dNQC0A3Yz X-Received: by 2002:a5d:452a:0:b0:48e:21f7:79ff with SMTP id ffacd0b85a97d-48e3eb97396mr8140147f8f.33.1793008322762; Mon, 26 Oct 2026 02:52:02 -0700 (PDT) Message-ID: <32dc00b1-f91c-43a1-a1fe-f0bebbb76d3b@suse.com> Date: Mon, 26 Oct 2026 10:52:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/4] xen/riscv: panic if the device tree advertises neither Svade nor Svadu To: Baptiste Le Duc References: <1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech> <1792164867.8631fc262581453bbf619ec5b2062170.1a14559ab900008425@vates.tech> <4526ac23-ca7c-40e2-a9d6-9d366369d3bb@suse.com> <1793007897.8631fc262581453bbf619ec5b2062170.1a177994ca9000f79f@vates.tech> 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: <1793007897.8631fc262581453bbf619ec5b2062170.1a177994ca9000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1793008323-ABED69EA-0B36E5ED/10/78276251493 X-purgate-type: spam X-purgate-size: 1132 On 26.10.2026 10:44, Baptiste Le Duc wrote: > > On 26.10.2026 10:32, Jan Beulich wrote: >> On 16.10.2026 17:34, Baptiste Le Duc wrote: >>> Suggested-by: Jan Beulich >> >> Did I, really? Iirc I left open whether to go the panic() route or the >> alternative one. Based on Andrew's clarification as to pre-Svad{e,u} >> behavior, I think I further tried to indicate that synthesizing the >> correct extension may be preferable, to allow older systems' DTs to be >> used as-is. In any event ... > > No, you didn't, sorry. I misread your "The outlier is when DT lacks any > information" as "panic when DT lacks any information", while you had just > agreed to probing in exactly that case. I'll drop the tag. > > For v8 I plan to: > - trust the DT whenever it advertises Svade and/or Svadu, without probing. > - probe only when it advertises neither, set the probed extension in > riscv_isa, and print a warning asking for the DT to be updated. > > Does that match what you had in mind? Yes. (Optionally probing unconditionally and panic()ing upon mismatch between HW and DT.) Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 09:59:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 09:59:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461029.1671962 (Exim 4.92) (envelope-from ) id 1xLHUN-0004qd-Qr; Mon, 26 Oct 2026 09:59:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461029.1671962; Mon, 26 Oct 2026 09: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 1xLHUN-0004qW-No; Mon, 26 Oct 2026 09:59:35 +0000 Received: by outflank-mailman (input) for mailman id 1461029; Mon, 26 Oct 2026 09:59:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLHUM-0004qQ-Cp for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 09:59:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLHUL-0058kQ-Pe for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:59:33 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf2475-2eae-0a2a0a5409dd-0a2a4504ae38-24 for ; Mon, 26 Oct 2026 10:59:33 +0100 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf2484-b57f-0a2a45040019-d1558031e15d-3 for ; Mon, 26 Oct 2026 10:59:32 +0100 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49d0da752ffso24569525e9.3 for ; Mon, 26 Oct 2026 02:59: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-4a35a0bae01sm226954415e9.7.2026.10.26.02.59.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 02:59: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=1793008772; x=1793613572; 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=AW/xpGGPAnmK3nHQv8mlURNxAldKG7tmwti3PO5CfB0=; b=C4boDrDwqprUZNtut+FQ/9cJxsgWSLsvQUbkq6xy5U+4rhiy8ZyYgMh0DGCPEijOC6 x41/IsYIAKtDvZOP4D23vmmnJ4JzKBgnL6wfiXLKStEqz1B99//Q3GDLRr6aOdl4bbWN kcuiM5RMpkSLwi37CQFv9xjyK5ijwxifCMQFHRzPWB3p8g2gnI/IlHDwLfjmkyK5T0T8 FijKV6gd2TYzFPDdpqLzGssEVmKmPotACA6ByYR3U6mJSEoagp7Cm1y7RUzdCD5fpdCY jj0BK0g/WcN5q2y0v2FKR+dyhFybGKBVB7PWUbGZ1Hit0UJOc3ikPriHdKBE3P95xWZD qkQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793008772; x=1793613572; 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=AW/xpGGPAnmK3nHQv8mlURNxAldKG7tmwti3PO5CfB0=; b=YSLvOhcnKdxYCM9zw1+NZC12FriupbGbWZrF/J228HD4zN/HTV8ll4aEFoRN7GlCHQ JEPPydunAMuVo/9K3OXUX2KDlBycsV9jiHZ6VPD8M/aUBb3JKxrhMeWfC4Ha/la3kBOC gw0rVyaNhWQsfJH24cZg1iXZb9djNILdb1mOCaoPYbBaMzAaZYKoydJV9Ab2tVH6q/tD PDGRlGng86/3MgzX22UuKfCJTjyPiPxtJdMrz4v7yJBjCTRZgAbwAv5hiPWt1O6evY7P iTrcKPE4tJDyuxCgCqhY+4yPs6xCylmmEZn4sQ3otT+/hlwuv9+NmwYYOCG/nJ76KeyG bE6A== X-Forwarded-Encrypted: i=1; AKwUvBx5EPCmEBUajkwwV0FVXO/ROQi3Wi3AhpAaDwr4WOs4mJvTmrGPBmf27RY/XQVF3ahAItiebVAhrMI=@lists.xenproject.org X-Gm-Message-State: AFq9FYKKJTbZfowlPz6RXbM1CMO/4UjdJOcFWDNqoAV/B6ADS5a9oFUj Aq6WqnpIjkVJDaAEDXfmHDU6cOs1olRVZog0fZr3OIZErRRw8zbg/is3EDViPBIbMg== X-Gm-Gg: AYBFou0iWsa6zHCdggdqrmGQCvIOsbMa9GhXMtg0A/9Ed0/dN4X+b79kkZBIYAeJtMy bdiHEWlITlwNJJ2C+f0GENSaEOlbus9KwT+63HmEftDdMA/PAVNm+jcRYTkoRyU6EjUWAHK8JQT qqbCmUqc0oVjgtjF6qvWe6h4FOFEFrv0epkUUSNaFSgaxGPmJi09Zdq0t5hUS0NRzYNv4CIzvrl v4earDSoWmpegXm6OqILHlNaVrC0P5w7Vl5IW0DQnwNTVCtBXtD3WXQWkpATvB2KH8WqKSjDGd+ aNZwbTNEnPrTiJQAPpTr054575OaqHsUD2OjREZQ6/vkgNN0MvBbCQhIwlo6KV19ODjrr/tMECJ rjRJkQFPet2Gu2NsdIbVPBC0USkH4OUDdbJisM1N+1cu+H8k1G32ZjWexnLo+zFlLk0v1MQ0LTq HHuzrt2DtxtrCYHTO09Hy1dG83J45RwAs/J4poLLoI6ERkrq4k1Ljw7VlO43H7xVEvFCoVdfCJh MzRJbI9GbBHHfDyJS3wE7shtFDEIZEhp8f9Eag/oW1xm/UAky5J4FZSvvNQC58UZkdAwMalwrP0 QLJotiyMyckfa8nXg3Svt1GEtYt/coo8716qoPgUJcxi X-Received: by 2002:a05:600c:524c:b0:4a0:1c94:7042 with SMTP id 5b1f17b1804b1-4a35ac8bdc6mr112596445e9.8.1793008772497; Mon, 26 Oct 2026 02:59:32 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 10:59:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86/hvm: Propagate emulated CR2 writes to the VMCB To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261020213315.3641133-1-stefano.stabellini@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: <20261020213315.3641133-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1793008773-512DCB50-B78DED77/10/78276251493 X-purgate-type: spam X-purgate-size: 629 On 20.10.2026 23:33, Stefano Stabellini wrote: > hvmemul_write_cr() updates guest_cr[2] but, unlike every other writer of > it, doesn't call hvm_update_guest_cr(). On SVM, CR2 is loaded from > the VMCB, so the emulated write never reaches the guest, and the next > VMExit overwrites guest_cr[2] with the stale VMCB value. > > Signed-off-by: Stefano Stabellini Especially as this looks to affect not just (or even not at all) nested, I think there should have been a Fixes: tag here. I see the change was already committed without, but I think this wants backporting nevertheless. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 10:04:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:04:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461040.1671970 (Exim 4.92) (envelope-from ) id 1xLHYv-0006nQ-Em; Mon, 26 Oct 2026 10:04:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461040.1671970; Mon, 26 Oct 2026 10:04: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 1xLHYv-0006nJ-CA; Mon, 26 Oct 2026 10:04:17 +0000 Received: by outflank-mailman (input) for mailman id 1461040; Mon, 26 Oct 2026 10:04:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLHYt-0006nD-Ot for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:04:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLHYt-000BD5-5j for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:04:15 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf2598-8faa-0a2a0a5109dd-0a2a450bbcde-18 for ; Mon, 26 Oct 2026 11:04:15 +0100 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 6adf259e-b7e8-0a2a450b0019-d155802ee0cd-3 for ; Mon, 26 Oct 2026 11:04:15 +0100 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a3517554f7so17368895e9.2 for ; Mon, 26 Oct 2026 03:04: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-4a35a0cc374sm190781715e9.9.2026.10.26.03.04.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 03:04: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=1793009054; x=1793613854; 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=nCy6WRUFpl6zKU+eACKqrRPCwL9Wyxk81Q/SdeQ+jrs=; b=EVaPb1cyeqSM334RnmWEo4e5ysP+ESmN1rTDqIaCbgR2KUIocndxfoe8Dyn/hJKNGL jrDhxFtZXrMjdKHK4GP4F9Dhp7CXSItV5HiqIkltzrIbW3WVqQVhs6NlXsbRVdEzVjQX 2v2x7ay3TTfwiWVRMd5kQMWaaljLFXxfKVSjm0WCkyGs93sPRSJM7x1EbgPEhyyi4LHf TlGiJFTsqHI11Buy0TNAZEhy639oglaWhD946ualSyd5TWGlZg7Wmc5qKKTjENTRIRSZ Hy3/SgYIjA0WS2iRQDh8K1jalEWoh7v/evrkRU8z9xcbumYqOzOUbnkChvUqLWFXsOpB 8Y5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793009054; x=1793613854; 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=nCy6WRUFpl6zKU+eACKqrRPCwL9Wyxk81Q/SdeQ+jrs=; b=QMHDUETzAdufvy1wxfWTpOBsUE0ORnKIUY+TDNL25ImmmZm5684zvbZiF+IisIuaBE tRpM2sbVAe//cHZflsglZ0SCzPrTnQPp1xJn25EVyL14LT2Z2KLtfqMOMCuuJiq26xca 4N9w0jbQwQtiu7P7982ivl/7nf3mZfxlAPH12cIzovfkO5RJrVSVVmrZoFtCY/HwXNfV nsvUM4emUfJPUxw8AkDJSVugT2wljf8UYWN4ZdnYQrcEfbAyeqC4OYwFdkqnOex3auVC IwTL/b3iAUFUkvERMtW3jNDRFo5xwIQRV+o/qM3gLWlmFfjcbakElOlbz8F7z8z25jrF 8x9A== X-Forwarded-Encrypted: i=1; AKwUvBwNEkI1UUONy/eJauDvZkb7AJRPg1nxtSZM4UcdBY4kc+fssBrGTSZbb8zmbkau42wns00g2NyeBj4=@lists.xenproject.org X-Gm-Message-State: AFq9FYI/GYS8jSFFfv261j2ItFj57eU/VTu0eZVjJ9oYESVJf0vcR/wj FI/OZIJgcUA//cy0eLKca3cOKaKcAzTzlk64Og2oozuxxVYWnNSXi+kmvrpbLifkEw== X-Gm-Gg: AYBFou0epU/6DPkxdCYVb8AA6ex2WNoZ+VLHRrJg08NRbux3U9isjkfdby85TbJcOBv HZUc6GLWPBu0OdVe9CT65d6veGD74r3UohScRb8dHenYfpDypNM8dUHP6TdASEKu1yZmn5/lNv9 D9JrQ1tv14qYup0bGSiOMoc4FoaKsinflzGI2olBsA/Z8AwX7x4FB9SuuYw3Y3JnaUBNyCjjpxS e3ml/WW8uRAdsJac2qpxchuR7Fq8OSIlF511JiQ1YZ7K9u6wE6pmp0+kkLGMD2LCAIlAr0dwuXm P4lB55ECCwvZJ8MJC/P25gPvd/Y/Sp1wBwy6gBb6yqnyBglzzKpS4WX0K7k4gPqdcVm6QrjlYEs Llj4dS4rSxgFALKDDiC4IIOvUDt6cMzCoWKEeR/H0T+ZAn2hk/p5Chzqa5lUA9b1dCdOJtdrd5p RAn7jSigMzljmdf7j7FMnlw555MOt/Q7mYuSSkbkj+fguTMAlgDuO/2UUfk/yWnBmwttGpVYiWC CClo8h/wTVFGfqhvurzsWvBhz2Z3uQM9Lq8H/nF+Pk2Ejyfr1xY3UNz5KsJS2GTsPWN9O5NS5ET beX1deuVNxN61eT4XCcMaI5EHMByyQLsxxpsfLTmZyIC X-Received: by 2002:a05:600c:530f:b0:4a3:2f35:38b4 with SMTP id 5b1f17b1804b1-4a35ac8b2a7mr123321495e9.10.1793009054532; Mon, 26 Oct 2026 03:04:14 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 11:04:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/amd/iommu: Don't swap the IVMD read and write permissions To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, Teddy Astie , xen-devel@lists.xenproject.org References: <20261020220821.3681692-1-stefano.stabellini@amd.com> <1792571797.8631fc262581453bbf619ec5b2062170.1a15d9aee9c000f79f@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: <1792571797.8631fc262581453bbf619ec5b2062170.1a15d9aee9c000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793009055-1B6D29EA-1BFE42BC/10/78276251493 X-purgate-type: spam X-purgate-size: 1692 On 21.10.2026 10:36, Teddy Astie wrote: > Le 21/10/2026 à 00:10, Stefano Stabellini a écrit : >> Per the IVMD Flags definition, bit 1 is IR and bit 2 is IW, matching >> ACPI_IVMD_READ and ACPI_IVMD_WRITE. parse_ivmd_block() takes iw from >> the former and ir from the latter, so a unity range firmware declares >> read-only is mapped write-only, and vice versa. >> >> Ranges with both permissions, including Xen's own, are unaffected. >> >> Signed-off-by: Stefano Stabellini >> --- >> xen/drivers/passthrough/amd/iommu_acpi.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c >> index 4688908824..fe3dee872c 100644 >> --- a/xen/drivers/passthrough/amd/iommu_acpi.c >> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c >> @@ -414,8 +414,8 @@ static int __init parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block) >> exclusion = true; >> else if ( ivmd_block->header.flags & ACPI_IVMD_UNITY ) >> { >> - iw = ivmd_block->header.flags & ACPI_IVMD_READ; >> - ir = ivmd_block->header.flags & ACPI_IVMD_WRITE; >> + iw = ivmd_block->header.flags & ACPI_IVMD_WRITE; >> + ir = ivmd_block->header.flags & ACPI_IVMD_READ; >> } >> else >> { > > That probably wants a Fixes: note. > Fixes: e941abd7cab1 ("ACPI: eliminate duplicate IVRS definitions") Argh, I did screw up there. > With that, > Reviewed-by: Teddy Astie This was committed with an A-b of Roger's, but such an ack was never (publicly) provided. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 10:05:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:05:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461045.1671981 (Exim 4.92) (envelope-from ) id 1xLHaP-0007ON-PD; Mon, 26 Oct 2026 10:05:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461045.1671981; Mon, 26 Oct 2026 10:05: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 1xLHaP-0007OG-Lg; Mon, 26 Oct 2026 10:05:49 +0000 Received: by outflank-mailman (input) for mailman id 1461045; Mon, 26 Oct 2026 10:05:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLHaO-0007Nq-Ne for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:05:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLHaN-005AER-VC for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:05:47 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf25f0-8faa-0a2a0a5109dd-0a2a4508e8d2-40 for ; Mon, 26 Oct 2026 11:05:47 +0100 Received: from [40.93.194.52] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf25fa-f659-0a2a45080019-285dc2341bbe-3 for ; Mon, 26 Oct 2026 11:05:47 +0100 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DS0PR03MB989237.namprd03.prod.outlook.com (2603:10b6:8:394::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 10:05: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.0546.021; Mon, 26 Oct 2026 10:05: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=Q7aNocEFJvS2lFha0B7svs8bzD+tRFKxrZUCDeQW0IyAuljBXVTDokoeayrMZT9f319TiRb6orevBVXdZ7CuK4zGD0z2Vg+ssVEB082cgNMFY6RjnRWCaIDMPZrc+OejD6reVJ6tQJyVOwgKG+xdxdGkOuOh7FGf3Nbqz2+QHf52bq8Mq7Mzwt06j4x73885LpFKswX63Z2G5EXtta3U6HyRYdu/vU+pm2WgIyOc0ihRV4UTG0om7N+zJI2t2nd00wOxtXqaT1UkjzSyJ6VG+ozK4T8hErYu4TtV10NpL1c0d0jQc/X9BX/SgpUpQJivqsaIgwa6M4LjBlhoA50JAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IkgMGXHgq+whQ54tDu7rb8WaTh0/w/JBnU2v8L9bT4k=; b=tnPQ67prVzVLtu8rutxYrePg9BAqm6CZ5VtbYwfk4XBNv5azj0ycB2+0C9Ip6QeF9rZpdXK3Q5RsvkEiAGmH6pJFv/pCBcRDJbchrvgS7ZeSfnZWbgtzX316ZTXIT6ir/+4T/8kVOUjYXparVW36JCm/XZu2Ef8wMemIrNY/1KGi/LshkgQwytJw6JQUWcWj1cZr8ChAl9ivpYcY46VoGAAsDDwZyH8Xuq/c1gcoQm2yJuf9NZtFrmsK0l0htVl02LdrRtl0JxFW8DgdzavYx1pzo53H2jp8sBpSMs7RCEXsizPsaAXfbHVJA71c4Qlx//Q+Yc5kOdrIXkdQaFAa+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=IkgMGXHgq+whQ54tDu7rb8WaTh0/w/JBnU2v8L9bT4k=; b=KvpHncD65XMyUBzQeq7zQ5AbiNY9LRcz6YRMF/lS6zlLMas2XkuiE3cu6sJZkNxhWgy1Br92UgtXsH2NjpoJkix5Hvf77ahLrBhDgK0Ex+4sgDw6mNydHnYYnXyNpVPrygJH3B5G0dj+AI4tmBVn20oBjXJm8oaTsGi8Y9iFc/E= 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: Mon, 26 Oct 2026 10:05:39 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Ignore bits 11:0 of L1's MSRPM base address To: Stephen Cheng , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie References: <20261026023821.301182-1-stephen.cheng@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <20261026023821.301182-1-stephen.cheng@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PR1P264CA0021.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19f::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_|DS0PR03MB989237:EE_ X-MS-Office365-Filtering-Correlation-Id: 194387a4-4465-40b2-16a8-08df3348b2c7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|261009223027099003|261021121427099003|261022075727099003|261021123027099003|10067099003|56012099006|18002099003|22082099003|11063799006|5023799004; X-Microsoft-Antispam-Message-Info: 9cbPXoH/ILopDxr3wxi09AQBYTH/bS9+pgb4KHtt+1Thg+ZkHDzZZXnhS0/LUDxIFKp9wHM54sSWE/mb0pusAucsEkH8ESpFHd59jJjnlyLA7Rpa93as/VMeEfiPdOUiKk1pcIg+pzTIDof6Wulsn3QgtSHHgeuxMW99939Mq9ocaKZVgp4qb4YjpPLgubT5oQI7yZ5YkGu9Xrg6MvU+ucuONFEQKMut7XeN4pCzRsUE/MtGT9i9EQIV0psj4uMLMhsn1+BkNzbDlaWVwO3qg9vsx15tjHE2utupjQpWxHDtXDcnCZ0tzHCQ+89KInpiLPqdyS/vH+Elj5voqJfg3q86dGJsTmeFPCn+gafjjuspx+R44Odv4ZQV9NV1OZLv2p4m02PdTR6/pfNVwnxuDo0VZsYe80jOiobB0KZbk5yZnGjToEhG6gNpMgJ3hFmjVQwKTOiWlBIfMd7mI6U2kaUcQl/7KukISAZfxKGIf60zGntp8ZQtWSrNfVJBNZjw1tvyKarphsxXEvhK1Ge6BoxlmgcA7NbPlXiaulgiMFGPudg9nwYtmWQnEXtU4/PZilGYHMve3vggjJxIidJ8r+mYUVKYPq+kvcS4iKjISMcA4pJzi+7jZzwDe7Svnp5dsnqLjGLvSj7w/DRXsttgynBheNlr1ydvszWG/xmnTaQ= 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)(261009223027099003)(261021121427099003)(261022075727099003)(261021123027099003)(10067099003)(56012099006)(18002099003)(22082099003)(11063799006)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OENvKzRRajd6dEc0YTk0VXpwRkdSZXdVUGN6akM0bElnWk9xend1VFdoZ0V0?= =?utf-8?B?enFXaVJsZ2JaeVpmTmc0VUpQb3k4L2l3K2FwcjhOaUFNdlJKM01GeW9MMHZq?= =?utf-8?B?ODlGWTZ1dUF3NnBYd0hWRkc4a3NzbnBYQTZMNTFLWVg1NVVLOVhpSk1teFFZ?= =?utf-8?B?b2RTTW83OU02THhLYW5lM04rbExkdjIwK01VZE9WSWdEMnJyYWxOR2VVeE5z?= =?utf-8?B?bG1GRjJoMmVIUnNwUGRYYWR3ZFdyd3BXWDFDQTJmUkdRVUlIdk9YT1k2UFZS?= =?utf-8?B?K1FXT1E2WmxVeVpJbGhDZlJVNE9HckJVamVMOTgyNFNQcXVCZ3N1N0pRN1ZR?= =?utf-8?B?a1J2RFBrOCtaMUc4c2pISnNiQWgxM2lYMUJ2cjhTMGRpQURlTWxUQkk1dHVL?= =?utf-8?B?S2hTL25obE14R0JsdnpwSzFSdzRUVS9aUHpWazZVNkkwaTRhdXBrODZHYXpY?= =?utf-8?B?bG0ySk9yY3NoVXRsc0R0Yml5cXp0clU5VUVlb1lPUlBaeEZmZTFFZTI0c0tG?= =?utf-8?B?ZTNrQ1UxZWxmejUxbEJLQTJKd3lkMUo4b2lLdVFZT1Y4K1hNUkp4V0QzZnJO?= =?utf-8?B?SXhYeFJpcklVZ29RRGZtM2dmNFpKTzBRaFE2cEtTcUhNNjI2cnhQTjBpSGZx?= =?utf-8?B?OWtRYkFZYWtvL1VENTVqci8yWVlGSUhJdUxseVRyeUJ1b013eDNuY1hRTmpE?= =?utf-8?B?a3NMSkhBbmtkWGxYSnozN1RKSys1T0RwTHd6L2NYdGNSTHVrblJ5bEljSkh4?= =?utf-8?B?aXVRSjBuakVwNStMNlRsMW8rM0NVa0RrMk1VNXh3L0YwQk40L0R1eHlkTHBw?= =?utf-8?B?MUlHSjFQK1N3Y0Uwd2tHWVRaV1lWTFF5QkxhTU5lQjh1cjcvK3d0azArMlBi?= =?utf-8?B?aXJJUVhkUXVVdTgzZTJSUzJtZ1VxbEcwMlp5VUVhNXptdlN1MEJSUUpMMjNt?= =?utf-8?B?K1hqMlE5Z0s3aVJqT0Y4TUpLczcwdHZEN010RmFCMTFGM2FGcDh4MEt0T2th?= =?utf-8?B?dEhoanFESXpOWU9WMGlYaUYwR0Q2bW8xSU5kaFc5Q2NvOERzeExQM0VzZmY5?= =?utf-8?B?VjNkNG5JMHdUQnpPUWZLbDZxQ3FpMHBxdE40OU92cUtlT2pGMkJJWUJsL1Za?= =?utf-8?B?UG5zWitqdm1rQnlTYXY2MTdMMmlHOXlMN3h6V2dEc3ZjK1A4SG02Z1VSY1ZV?= =?utf-8?B?TG9NYmpsamkwNzRrQktYZWFmaENVeXR3MFZCem5xaE45azExTldvemJxUklM?= =?utf-8?B?TTJhbU0wTDBuSmFSQnNIYjRxUEN1d1pycHFmL1NNaUxFYUVxUkM3WmJrV1lX?= =?utf-8?B?RXlVZU1FOVRlSkM0anJ6bEdubytxZ3A1U0lZSGlSR2pJYm1zT1hFRlY1dkFJ?= =?utf-8?B?d25rTHUvenZDNzVZWGtDdDIrd2cwNXNUQnBobmYwSkF2cFd3STJXM2F4blpv?= =?utf-8?B?dTFzbXQ0V0RPMEFtdk1YY3NSK0EyMFZGSVUva2ViU0tQYUFnK1FRWTNoSDI2?= =?utf-8?B?T1RFYXFEeGtodHlFb29Hc09FTWk0NHBBYVJJNnJNMkZMYmo0NUhzTUIrSWRt?= =?utf-8?B?TW1jZHJHSisxSDJDdU1wbUhoTHJSU1UwM0MxTW1HZm1UWDkrNGlZRzVRMndl?= =?utf-8?B?dHlaZGVrTjhBYmRPNkljc0ZZaWNteXh2YnJROEhWZVcrcUZPVG5nVG92SEx3?= =?utf-8?B?Q0RXdDZVVEhOaEJCOTViMEtkL2VDN3p5VnBuU3BQVTVBUTdnUmZUZWVJYndU?= =?utf-8?B?aXBDaERXaTVOVndiNEFvS0hLTEo1d2pESlRwMENLc0FaMXVpNGduc0FTYzNw?= =?utf-8?B?eWdoc3ZIRXRxcnF1aVVDeUcrNzZ6MUZHQ1UrcmgxbEZxaWlTeEhIclhWK2Y5?= =?utf-8?B?STRFSnVUanpHR0V2VkVaeE5NSko2UEhPZ3lDYzY2NERKQzZkb3BUNmphcHdV?= =?utf-8?B?VXJ5VDg4Rk1kNmVGR3NCb3E1VlVsQXRVU0RXMWVyRXgvRVREYVR3RURBT240?= =?utf-8?B?a2xMcGNqUWRhM0lWQ203U1E0ZWVVK1I3WVAvbHdIMllSbE5jNEtVcS9mS3E3?= =?utf-8?B?ZC8vd01kVHduYTlLakdvU0twY3ZFNUgzdVRLd0NSVHoraFpCRFg0cU5CVU5j?= =?utf-8?B?UTlzWVltK1BLb3RIbFoxd2VBNXVldGNCVFYvNmFPbzVDbVVZY0wzOG53UndO?= =?utf-8?B?QnJRNWVOeDU0SlhUV3JEWkw5NDFyVlJNUkRsQlZpWVM0dGc1NkJFRytYN2NW?= =?utf-8?B?ZFR5Y1ZlVmhTQTZxMzJsTnNlU2VQak9IRENtR3V6S3Iyb3FyVldWWnBqblhO?= =?utf-8?B?dnptcGZtSVBIdzUzVitzVW03WGRxbG9xaE9sd20yQkZ1U3RUK242Qk5KKzJI?= =?utf-8?Q?rsnE2gyw72b9fuys=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 194387a4-4465-40b2-16a8-08df3348b2c7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 10:05:44.1790 (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: KFYOJAHRwe5s2ioBtGlO4n0jPm3a+kbKMlzsVLsb41VmSVvFDALGEnBY3QsidNpFfi6IVZ3rciNGjQOzD6BeH47rO70h27iwuN2aR4vFDcE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB989237 X-purgate-ID: tlsNG-c1860d/1793009147-CC97287B-F52311CC/0/0 X-purgate-type: clean X-purgate-size: 2484 On 10/26/26 2:38 AM, Stephen Cheng wrote: > VMRUN ignores bits 11:0 of MSRPM_BASE_PA (APM volume 2, 24593 Rev. 3.44, > section 15.11), but nsvm_vmrun_permissionmap() copies L1's MSR permission > map from the address exactly as L1 wrote it. With any of those bits set, > the copy starts at the wrong offset, so both the merged map and the > intercept check on #VMEXIT use the wrong bits: L1 can miss intercepts it > set or see ones it didn't, and the copy may run into the following page, > giving a spurious VMEXIT_INVALID if that isn't RAM. > > Mask the address before copying. > > Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") > Assisted-by: Claude:claude-opus-5-5 > Signed-off-by: Stephen Cheng > --- > > Notes: > To reproduce, in L1: set MSR_PROT, set only FS_BASE's read bit in a > page-aligned MSRPM, point MSRPM_BASE_PA at the map + 0x800, and run L2 > doing RDMSR of FS_BASE. L1 should get VMEXIT_MSR; without this patch the > RDMSR completes in L2 instead. > > The IOPM base, handled in the same function, doesn't need the same fix: > all of its users convert it to a frame number first. > > xen/arch/x86/hvm/svm/nestedsvm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > index 2b998e26bc..56d0f0fa4d 100644 > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -309,8 +309,10 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v) > > ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm; > > + /* VMRUN ignores bits 11:0 of MSRPM_BASE_PA. */ > ret = hvm_copy_from_guest_phys(svm->ns_cached_msrpm, > - ns_vmcb->_msrpm_base_pa, MSRPM_SIZE); > + ns_vmcb->_msrpm_base_pa & PAGE_MASK, > + MSRPM_SIZE); > if ( ret != HVMTRANS_okay ) > { > gdprintk(XENLOG_ERR, "hvm_copy_from_guest_phys msrpm %u\n", ret); > > base-commit: 4e3c0eeac5761c505f8229e82d265eb29957ca5c The commit title and message could perhaps be more precise - writing L1's MSR permission map, etc. is vague and could refer to either L0-L1 or L1-L2 (or sometimes even L0-L2) depending on the context. With that tweaked, Reviewed-by: Ross Lagerwall From xen-devel-bounces@lists.xenproject.org Mon Oct 26 10:07:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:07:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461052.1671989 (Exim 4.92) (envelope-from ) id 1xLHcQ-00086s-4O; Mon, 26 Oct 2026 10:07:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461052.1671989; Mon, 26 Oct 2026 10:07: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 1xLHcQ-00086l-1B; Mon, 26 Oct 2026 10:07:54 +0000 Received: by outflank-mailman (input) for mailman id 1461052; Mon, 26 Oct 2026 10:07:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLHcP-00086f-AC for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:07:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLHcO-002fmy-NA for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:07:52 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf2677-bab6-0a2a0a5309dd-0a2a450ac042-2 for ; Mon, 26 Oct 2026 11:07:52 +0100 Received: from [209.85.218.50] (helo=mail-ej1-f50.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf2678-f2d2-0a2a450a0019-d155da32a9fb-3 for ; Mon, 26 Oct 2026 11:07:52 +0100 Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-c169ae1cb26so589901466b.1 for ; Mon, 26 Oct 2026 03:07: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-48e3ebcb902sm16175077f8f.24.2026.10.26.03.07.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 03:07: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=1793009272; x=1793614072; 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=uVoqQ6RIPgM65w22oOHXYi39Fuub3PS56mQpRz0rWxg=; b=VyH8d70q9o2zrfl5TxDle7oRrDxrTcxzkk8tgPoSL/fjLUCfVwcS2oA+W8JD0Rd6lG 0s9G3koCx/stgdf7TJii96uGQwusCRQgbbv1fi+ygaAC2CePRPU4Gav4KoFBGscMayHW Lh1J5OBNNd7Lfx8kCOM7qfC8wdUU5EkWOZTD82eqTGOGPYe/5cYbUPmTndB5HuJr9f4u uA0KJ/KfK+fPFDx6MupckAXGYAL2quEcPb5LXJ1tH8ejqEEirfk8yQw24FR/tMIYh15o SOBt2IedbEWrBrlMWBBGKphK5QTpsikQxQnxCCJLwJZ0lBjtg2aeCLaHHTeYZ60p4DGQ g43g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793009272; x=1793614072; 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=uVoqQ6RIPgM65w22oOHXYi39Fuub3PS56mQpRz0rWxg=; b=LgrUXkPaatnbsstffmBvo8xWP2eXBaTla6Bt8LnwdnMzijkqDCfj6LzOgY+8lSal6a G8zrZmv7oM2Lhleuz/roCoSlxjoEEqCghVZid/pkyIfALAnc5Cxy9We/yNus2qO+HryR 2qP3STDi4yBiE5pMBLPmI5kCKiP2RNuZ5bINGfQmwzpSIN4h2j/lBjABy14lvFGg/vz8 rPBZbptlJWbJg3ao7/VoMp+PlPpuuzirNHT3OSmI+fablGjL6R7SrCsCCVanp3ZhjgBs HKgd+T5vjwPZ15cJx2NGfip/8l1JfOcdMvhvmowVUnW5TVtD0JHHQQ3XMa8Dx1hoSa3+ otnA== X-Forwarded-Encrypted: i=1; AKwUvBz3XU0yBDnWt0pl+pjJsVDldk93u0SmKKWfj6K86ROeVScrKFQdHDidItbpJm7XZHCrGjoB+eQyyRQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYJvpSUqzIhp4ivPbW6nAcYf6O3i1SlMwol2lSgGYuHCX/ZKFecH lxr4PcMMxtFVXgHqFs2A5L08NXwJ9mogq57oLCjMz92c55MLKKeoT40hje9zRD6aLA== X-Gm-Gg: AYBFou0RV6Ae1bgPgWQZry5Zb5kxjSwS/Q34E1NPw/m+gju5hDg66gnSYmUk5HahvSd OHFOZ+E7gPoS16IhsHl3as/EEjIBLcbn/1GIq+5zCKv3uO9XofCemLjrToQnUKwud+a5glZq960 oojQuSruYxdSHISPPWP9cvLzsAy+ZQCEmir7Aka505b0NDkxBgcZKaqmEPnf9tMqAvFQN6yFWMd hkPQsS2Gop4fy2qv817KAzPDljdXO7/pZvbcGChTTz/KRfvYmdE1g+spf20iAwa44PrncxF7ltc WGPvyMppeJXtl3RfqrzBuuVaUzmwU/YuYi1E2XWVfpQUW78IMrrn3225duejSE8KWOwbdXDxb5N 6C8K0wY/Ou4zJ4TUichlyBjPi+wi47mB6cWwQDRY7+VxQF62v86hISXhmNNsuvDp3JPi1QZIqNn Wzsg5on3JxObP7nyluCL9Cqs/szN5TniUa9WwEKrN+U3Wsh63Yi4ELVMZP7t/HAh8gcJzqdNd6c MeI3b4yn/V+8tIUyHXwFLyzHF0wBXw3rwKIeV2uM+QCFXKTTsavBfRI3KcE/AowCpDo0UXfJgCb donsXUomIkQcNMUG3osEki/D8G5GcQe2qeCs8VDHuTId X-Received: by 2002:a17:907:9711:b0:c2a:ac35:95fb with SMTP id a640c23a62f3a-c46bddb8aacmr753802766b.24.1793009272130; Mon, 26 Oct 2026 03:07:52 -0700 (PDT) Message-ID: <0d3071fd-fa44-4769-90cd-8fe8779c3fde@suse.com> Date: Mon, 26 Oct 2026 11:07:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/rangeset: Fix rangeset_remove_range() with e == ~0UL To: Stefano Stabellini Cc: roger@xenproject.org, xen-devel@lists.xenproject.org References: <863a0654-7a34-976a-4c08-159cc34c26bf@kernel.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: <863a0654-7a34-976a-4c08-159cc34c26bf@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1793009272-4B8D5CFC-B7945C59/10/78276251493 X-purgate-type: spam X-purgate-size: 969 On 24.10.2026 02:28, Stefano Stabellini wrote: > When the removal spans several ranges, the last one is trimmed by > setting its start to e + 1, and destroyed if that leaves it empty. For > e == ~0UL, e + 1 wraps to 0, so the range is kept as [0, end] and the > removal adds everything below it. > > This is hit by pv_shim_shutdown(), whose iomem_deny_access(d, 0, ~0UL) > on resume turns the guest's grant frame permissions into [0, highest > grant frame]. arch_iommu_hwdom_init() can hit it too, for a PVH > hardware domain with an E820 entry above its 48-bit iomem_caps. > > Destroy the range when it ends within [s, e] instead. > > Signed-off-by: Stefano Stabellini > Acked-by: Roger Pau Monné This again could have done with a Fixes: tag. Yes, digging out offending commits is extra work, but if patch authors don't do so, someone else will (often) need to do so in their stead. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 10:20:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:20:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461060.1672001 (Exim 4.92) (envelope-from ) id 1xLHon-0003qK-7Z; Mon, 26 Oct 2026 10:20:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461060.1672001; Mon, 26 Oct 2026 10:20: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 1xLHon-0003qD-4i; Mon, 26 Oct 2026 10:20:41 +0000 Received: by outflank-mailman (input) for mailman id 1461060; Mon, 26 Oct 2026 10:20:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLHol-0003q7-Iq for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:20:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLHok-003yqv-QS for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:20:38 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf296f-e002-0a2a0a5209dd-0a2a450a8378-14 for ; Mon, 26 Oct 2026 11:20:38 +0100 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf2973-f2d2-0a2a450a0019-d155dd2cf031-3 for ; Mon, 26 Oct 2026 11:20:35 +0100 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48e04773687so838556f8f.2 for ; Mon, 26 Oct 2026 03:20: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-48e3ecdfd8dsm14757039f8f.56.2026.10.26.03.20.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 03:20: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=1793010034; x=1793614834; 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=npRG4y4emhj6KoE99osvHlRJ2HugQIzycJNLMCGEoAk=; b=X5iByLTngZgrP6dY57bpyP8ULiIp8bHBLp6BVmmSHny3nC+Tic2P+OJatAoLs7PC2X Oeh1v3+V0f9KlGYYKDPG1c+QZ0yzFv5D653BZPzi3fqKr3eSN+4vwJUwePvT7ULtZd3g CxxXUfvwnAb+jgsVd+avJkBjuNzwotoao3crDu8+xAj6QvU4LGkvZBDpoeI6mEHa7MpK Qi2SD/9r6ST3xgy1JzjXAm9qTcPSStJx1V+4gz7rm04JWf+IXvk1S3395/HEi4xzoDfR iX5H8VmY1le+c3hQMb5yqzk9l6hMAu6G5uG7u53vDhKAnMagbjmk/JWpKpLKQ0V1oDqe piPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793010034; x=1793614834; 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=npRG4y4emhj6KoE99osvHlRJ2HugQIzycJNLMCGEoAk=; b=mWdX6lZgG6Z8G+1+eG1zqFn7vkbwvBxgXl403WCGzqoribNyxriIoybfsVWxOFio97 dzSPLMAhjuTeqzlGV2G3dnU2Q0DFBqqRPtQ4m3fn6NbgMzup9+9cLHRI47X0C+lK6RyZ 4WPWgM+s6XIdiWvWSpC7wdXEZZFNBJffUGxw1+xjDT++tCSBdThJ3zKOD/VrNG6kyP2j tJ3uKKr+i8y1kwQ41GhIGJOeMfSACgvnkswgmSabM6bIGEldED/JTxvTljKSFYy0o/gp atSjhYc6Kk0uUmUcXPtG0AulYpEO8RWLgPBBVsrADqQycbJdGotV7TrbJ+ZMneW7zVch 5HPw== X-Forwarded-Encrypted: i=1; AKwUvBwXB2YftJY/d1NzP85Iab2YIMj4QDrg0/zmnJzw9DXctDRzUWep3WtEX8bnIyM9HGqe3TiFVyw/iHo=@lists.xenproject.org X-Gm-Message-State: AFq9FYKqwPIpIDIxKBSqDbD8mxMbEJZNcU8Wn3AawcP2wR9H4e6T47qY 1mVO2nfW9Xqt5gQHYveQGiyjYGlbpObASJ9hjXhO3De0oaJkI/Vq2x0cn6pOWI3ePg== X-Gm-Gg: AYBFou0lRIuKFV6F8MyXMJwkadNqqu/1EQSgxl5xlfuZL2YbKrTLT4U0fY9FO6ofZvc 9VI31IPf7z5PUZaoaiIlKpXU4LL4fT37Z+AF4OP1h3+tkI0sLM8aar3ZyD8QDssS93mzWeaJhk+ IlQCA9ocGblnC/ne+GgVOdSQ4581cpsm5mlWxRbmkxz7XUwbfGV5Q0GLSTjmTV14rzlNrlN0ps6 60cvj9cBOBV/Dn996wFM0GF2hC5EaMUoMhYNxfMlGDmkHaEB/q/l4eYwc61jnJIPgrwSDWk7iDt 7ygu5fSp7EsUD6O4mg3Kc348Z0aUZnq4EeJQ3UEzB1OdQJHSvvxbNvx74hMBXxYj6zHDngaSCJx YZtMB5kXXOurnvEfzCeprTpTqN7vep2ftOFNzyfnlH2FZl0b4aDSnotGMXjEie+a0jGjZXNjkcF DFsTwhtKoUBXXto2kkY/xukjejhceSK4vAiT806QMPhUYFYonqYl3J8YddIoLhhfIZqhNU09QOJ zaxHmpj3D1P0O9LZvg9lXQK33gpwXoR2DpC3GQXGeZ4q2y4/IGkwnq4ivjRcx5JVcgoN+1AKomm tpJRAl7vGSq4lLzCncZ4hpo64GgOmi5mGBymAORn+7f/ X-Received: by 2002:a05:600c:8b62:b0:4a2:150f:1610 with SMTP id 5b1f17b1804b1-4a35acd5f91mr100881745e9.23.1793010034559; Mon, 26 Oct 2026 03:20:34 -0700 (PDT) Message-ID: <572b2fb5-1cee-442f-a81f-9a667adb5c4b@suse.com> Date: Mon, 26 Oct 2026 11:20:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Ignore bits 11:0 of L1's MSRPM base address To: Stephen Cheng Cc: Ross Lagerwall , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20261026023821.301182-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: <20261026023821.301182-1-stephen.cheng@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793010035-538D5CFC-1CA41B4C/10/78276251493 X-purgate-type: spam X-purgate-size: 383 On 26.10.2026 03:38, Stephen Cheng wrote: > VMRUN ignores bits 11:0 of MSRPM_BASE_PA (APM volume 2, 24593 Rev. 3.44, > section 15.11), As before - section titles please alongside (or in place or) section numbers. I'm looking at 3.45, and it is mere luck that section numbers didn't change there. Then, on top of Ross'es R-b: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 10:28:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:28:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461071.1672015 (Exim 4.92) (envelope-from ) id 1xLHwa-0005J9-65; Mon, 26 Oct 2026 10:28:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461071.1672015; Mon, 26 Oct 2026 10:28: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 1xLHwa-0005J2-2y; Mon, 26 Oct 2026 10:28:44 +0000 Received: by outflank-mailman (input) for mailman id 1461071; Mon, 26 Oct 2026 10:28:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLHwY-0005Iu-KV for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:28:42 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xLHwY-0000000EZ3z-3Bqj for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:28:42 +0000 Received: from mail-lj1-f169.google.com ([209.85.208.169]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xLHwY-00000001srr-2v9J for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:28:42 +0000 Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-3ab28f3e4dcso31510091fa.0 for ; Mon, 26 Oct 2026 03: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" 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=dkW7G0VtuBqBdkVDSE4JuBU6fPDgpB58bfQi0jx+Tq8=; b=QlrXhYgz6mT7n3t9eAR7tPPGbU 1G67lVIrX12UhF2X6C5+S2IyINFBBg9rU9OjVClQ1yhL/NxeZhoFRf5Cly0clJyng86f885IN90Zx YuOgarr/zDZnPW7Ka3dtlkAv8BQfmZCf2UYpSnmhDwfE2BD/iF+3yD8Gp9UHrLqKZYfo=; X-Gm-Message-State: AFq9FYKWM58O/Ct2I/9kdru5tpZ3q4GVCAFXf2cs/JPVqLipzdrRVfoo FgI5y1TnoW37bNl4NTID+o9TV/9nV2li7wtHxa/pWVC491MkA7OldKhDPCzzJJ48fWKFfdeDOFZ qyU/yqR7OX4a2t5+kXSDetCGCB65tgyw= X-Received: by 2002:a05:651c:1613:b0:3a9:89aa:618a with SMTP id 38308e7fff4ca-3ac6fd095c8mr15239661fa.12.1793010521438; Mon, 26 Oct 2026 03:28:41 -0700 (PDT) MIME-Version: 1.0 References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-2-b68b66652266@xenproject.org> In-Reply-To: From: George Dunlap Date: Mon, 26 Oct 2026 10:28:29 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9gSrJt3oJl87YE5AYr1LbY7_3e_CNfbqbvI9lC1JYPM_mWEjaxWkI5AaA Message-ID: Subject: Re: [PATCH v4 02/30] x86/mm: refuse to promote an L4 while the domain has no vCPU To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 23, 2026 at 8:06=E2=80=AFAM Roger Pau Monn=C3=A9 wrote: > > On Mon, Oct 19, 2026 at 08:42:33PM +0100, George Dunlap wrote: > > init_xen_l4_slots() puts the domain's per-domain L3 in slot 260 of the > > L4s it fills. Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT > > L3 slot at domain creation") a PV domain gets that L3 with its first > > vCPU (pv_create_gdt_ldt_l1tab()). Only mapcache_domain_init() makes it > > earlier, with the domain, and release builds skip that unless memory > > hotplug is enabled or the host's memory reaches past the part of the > > directmap PV guests can see. So in release builds on most hosts, an L4 > > promoted before XEN_DOMCTL_max_vcpus has created the domain's vCPUs get= s > > a slot 260 entry made from a NULL page (0x803e900000000063), pointing > > far beyond the host's memory. > > Won't it be more reliable long term to instead return an error from > init_xen_l4_slots() when the per-domain L3 page is not present? > > It does seem like PV vCPU creation could change yet again in a way > that the per-domain L3 is not allocated there, and then the check > added in this patch will be moot. If we need the per-domain > page-table to be allocated by this point, let's test for that, not > indirectly testing whether vCPU 0 has been created. > > I also wonder, this is for PV only, but I assume for correctness > purposes we should do the same check for HVM monitor tables also? Eventually we modify init_xen_l4_slots to take a `struct vcpu*`; if there are no vcpus, we can't pass it anything. For vcpu_pt domains, that would technically be fine, I think, since the L3 is written in on context switch anyway. But we would still need some sort of fall-back if d->vcpus[0] =3D=3D NULL but d->arch.perdomain_l3_pg !=3D NULL. Is it worth trying to figure out how to handle that case, just to save us time in case we change the vCPU creation again? We could change this patch to check `d->arch.perdomain_l3_pg` instead; if we end up backporting this it certainly does make the check more robust. But we'd still have to add the vcpu check later. -George From xen-devel-bounces@lists.xenproject.org Mon Oct 26 10:40:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:40:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461078.1672024 (Exim 4.92) (envelope-from ) id 1xLI8A-0000Ed-5L; Mon, 26 Oct 2026 10:40:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461078.1672024; Mon, 26 Oct 2026 10: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 1xLI8A-0000EW-2B; Mon, 26 Oct 2026 10:40:42 +0000 Received: by outflank-mailman (input) for mailman id 1461078; Mon, 26 Oct 2026 10:40:40 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLI88-0000EQ-Qv for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:40:40 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xLI88-0000000EZHa-3mlj for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:40:40 +0000 Received: from mail-lj1-f171.google.com ([209.85.208.171]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xLI88-00000002Dw8-3TTU for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:40:40 +0000 Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-3a9e87ba696so19210121fa.0 for ; Mon, 26 Oct 2026 03:40: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" 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=PDVXdjlBnsIgkPufjuXTGDuKs8wTcNJwdjI9Ossk4Ho=; b=23AfMNNsK8ztYkRFdc+YRkgjUX 0PZ4jbkpAEHRVRFQgrwgRCcXmDRH8hIEzJveAOHnqSL1POBIV7GV3C2mXN0MrBKJW7TFzqoxwDFq9 m9dTWLVA7urFRgKpGLDgrp4EKfg7WPN4H6ymQb54NQ8SIwEHXfjlEW6VbcKDCAbVOp/I=; X-Gm-Message-State: AFq9FYIC3fFNdV9NiQ37mZCT0sOHeSYAD1JscEchu5FMZiLm64NSi6C0 NrpaG3QGjuePn5EI7Ilu4K4uXiU/zMabVx2Y0KjGXCuAvEoZ/X5TZlyVEqblJg///v67j90Cpeu QC2lGGWO2cAR8V8R62S0taj3sSRqwsAw= X-Received: by 2002:a05:651c:a143:b0:3ab:540b:f4a7 with SMTP id 38308e7fff4ca-3ac6fcaf492mr11573601fa.8.1793011239462; Mon, 26 Oct 2026 03:40:39 -0700 (PDT) MIME-Version: 1.0 References: <20261019-asi-hvm-v4-0-b68b66652266@xenproject.org> <20261019-asi-hvm-v4-7-b68b66652266@xenproject.org> In-Reply-To: From: George Dunlap Date: Mon, 26 Oct 2026 10:40:26 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_EfQHBJBWOqFsab6hOGIz1p4KcKIa6xSIyNzGHLOD5HxaE7ex1_-ejfmI Message-ID: Subject: Re: [PATCH v4 07/30] x86/spec-ctrl: introduce Address Space Isolation command line option To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 23, 2026 at 8:45=E2=80=AFAM Roger Pau Monn=C3=A9 wrote: > > --- > > Changes in v4: > > - Docs: "domains" throughout, not "guests" (Roger). > > - Group the per-domain settings as one-bit fields of d->arch.asi > > (Roger). > > - Rename opt_vcpu_pt_hwdom to opt_pvh_vcpu_pt_hwdom: it acts on a PVH > > hardware domain only (Jan). > > I would leave opt_vcpu_pt_hwdom as-is. The fact it only acts on a PVH > hardware domain is a transient implementation short-coming. I don't > think it's worth introducing a separate opt_pv_vcpu_pt_hwdom when PV > dom0 support is added, or having to rename opt_pvh_vcpu_pt_hwdom -> > opt_vcpu_pt_hwdom. Yes, I think you're right; in the end an option which says, "Turn on vcpu_pt if dom0 a PVH domain, but not if it's a PV domain" is terribly useful. > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-= line.pandoc > > index a6f08463d1..839d06da26 100644 > > --- a/docs/misc/xen-command-line.pandoc > > +++ b/docs/misc/xen-command-line.pandoc > > @@ -202,6 +202,35 @@ 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) > > +> `=3D List of [ , {pv,hvm,dom0}=3D, > > +> vcpu-pt=3D | vcpu-pt=3Dhvm=3D ]` > > + > > +> Default: `false` > > + > > +Offers control over whether the hypervisor will engage in Address Spac= e > > +Isolation, by not having potentially sensitive information permanently= mapped > > +in the VMM page-tables. Using this option might avoid the need to app= ly > > +mitigations for certain speculative related attacks, at the cost of ma= pping > > +sensitive information on-demand. It might also offer some protection = against > > +unmitigated speculation-related attacks. > > + > > +The mechanisms currently implemented apply to HVM domains, including a= PVH > > +hardware domain. PV domains, including a PV hardware domain, are unaf= fected. > > I think we might want to drop this. It's an incomplete in-development > feature: we don't need to mention explicitly what is and what is not > implemented in the command line documentation for the time being. This seems to me a kind of difference in taste. I prefer the documentation to be always accurate according to that state in the tree; having the documentation change as the code changes helps you see at a big picture how things are progressing. In any case, I doubt we'll get vcpu_pt implemented by the next release, so we'll want a statement like this in there anyway, won't we? > > +* `pv=3D`, `hvm=3D` and `dom0=3D` enable the features for PV domains o= r HVM domains > > + other than the hardware domain, or for the hardware domain, PV or PV= H. The > > + plain boolean does all three: `asi=3D1,dom0=3D0` leaves the hardware= domain > > + out. The forms naming no domain type (an un-suffixed `vcpu-pt=3D`) > > + cover the hardware domain too. > > + > > +**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` gives each vCPU its own per-domain area: the per-domain sl= ot of > > + each vCPU's monitor table maps a region private to that vCPU. > > + > > ### asid (x86) > > > `=3D ` > > > > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/a= sm/domain.h > > index 212daae1f5..12f79feb42 100644 > > --- a/xen/arch/x86/include/asm/domain.h > > +++ b/xen/arch/x86/include/asm/domain.h > > @@ -474,6 +474,12 @@ struct arch_domain > > /* Don't unconditionally inject #GP for unhandled MSRs. */ > > bool msr_relaxed; > > > > + /* Fine grained ASI related options. */ > > + struct { > > + /* Give each vCPU its own per-domain area (HVM only). */ > > I would drop the HVM only part, it's a transient implementation > limitation, not a design one. Same idea: It's true as of this patch, and it's likely to be true in the next release. Better to document it rather than have someone search down the implementation and determine that it's ignored for PV. > > @@ -487,6 +491,69 @@ static int __init cf_check parse_pv_l1tf(const cha= r *s) > > } > > custom_param("pv-l1tf", parse_pv_l1tf); > > > > +static int __init cf_check parse_asi(const char *s) > > +{ > > + const char *ss; > > + int val, rc =3D 0; > > + > > + /* Interpret 'asi' alone in its positive boolean form. */ > > + if ( *s =3D=3D '\0' ) > > + opt_pvh_vcpu_pt_hwdom =3D opt_vcpu_pt_hvm =3D true; > > + > > + do { > > + ss =3D strchr(s, ','); > > + if ( !ss ) > > + ss =3D strchr(s, '\0'); > > + > > + val =3D parse_bool(s, ss); > > + switch ( val ) > > + { > > + case 0: > > + case 1: > > + opt_pvh_vcpu_pt_hwdom =3D opt_vcpu_pt_hvm =3D val; > > + break; > > + > > + default: > > + if ( (val =3D parse_boolean("pv", s, ss)) >=3D 0 ) > > + /* PV domains are unaffected. */; > > You might want to print a message saying that the option is ignored > for PV? It will go into the console buffer at least. Yes, I think so. > > @@ -680,6 +747,13 @@ static void __init print_details(enum ind_thunk th= unk) > > opt_pv_l1tf_hwdom ? "enabled" : "disabled", > > opt_pv_l1tf_domu ? "enabled" : "disabled"); > > #endif > > + > > + printk(" ASI features for Dom0:%s\n", > > + opt_dom0_pvh && opt_pvh_vcpu_pt_hwdom ? " vCPU-PT" : " None= "); > > +#ifdef CONFIG_HVM > > + printk(" ASI features for HVM VMs:%s\n", > > + opt_vcpu_pt_hvm ? " vCPU-PT" : " None= "); > > +#endif > > opt_vcpu_pt_hvm is defined unconditionally, so you might as well use: > > if ( IS_ENABLED(CONFIG_HVM) ) > printk(" ASI features for HVM VMs:%s\n", ... > > Which is a bit nicer than the ifdefs? Ack > > @@ -2158,6 +2235,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_pvh_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"); > > I wonder, could we add the warning in parse_asi() itself? I know if > would then also trigger for asi=3D0, but would avoid having to remember > to expand the condition here every time a new option is added? I'm OK with that. -George From xen-devel-bounces@lists.xenproject.org Mon Oct 26 10:49:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:49:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461090.1672040 (Exim 4.92) (envelope-from ) id 1xLIGc-0001UJ-1A; Mon, 26 Oct 2026 10:49:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461090.1672040; Mon, 26 Oct 2026 10:49: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 1xLIGb-0001UC-Ud; Mon, 26 Oct 2026 10:49:25 +0000 Received: by outflank-mailman (input) for mailman id 1461090; Mon, 26 Oct 2026 10:49:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLIGa-0001T0-Qw for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 10:49:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLIGZ-00Cpdf-36 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:49:23 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf3026-bab6-0a2a0a5309dd-0a2a4501a5b8-34 for ; Mon, 26 Oct 2026 11:49:22 +0100 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 6adf3032-5984-0a2a45010019-a237832feddc-3 for ; Mon, 26 Oct 2026 11:49:22 +0100 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 961EF4EE009A; Mon, 26 Oct 2026 11:49:22 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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=1793011762; b=FC9yYpFOo78Hl/+J7mOA3jW+Zj+B7TXPM7Lup9BVz8Xq3ltJpQoFC/LOhPGGbiTfH0X7 blENp7g4WMyfgEwb45ZpWEacjBwhv3vptBnSn2OJDJdK+tGMV9He4lNS/g6mlgJuG74Cn o0ueBWTv1AANHigYp2MW0MQ30t5ZTDTl+rmFH9QV7Intfo0OGyehax/6FVerXhaIxSbgi 89fzmRQ5sOJZ9PBiAmWFqvojbO/g34LmQeGUDDvocetKPWF/jAr6OSTcyZuuizSSSN5Mp OolmHnHOqbajvBZEjSU+BOKTMC/BJOC/cfdZWf6nO9E3GKNmRefBHOuaMqD8ch5xDLf4X aEIUHAhMtcGK25FTabIDvjjusmqASK5r3IuW+RC8cODeLOHJ7kbEYPg6fzbFk2qpTD2EJ Q9qSzobqQOwaf8GrTEd+gxCuiuk/Zq+Fum712Q8P7PLVke2cCHh7iitEAwbIhtxeQdkKk hpycTADNPzh5pjjpOuU1Q2DAIlMMlq5kFwy2SSDYPGtpCCj8WFsy5Ppdzl+m7ahE0Krfj 7uRXuV9PWJeC3aKs7Dz6q2tt74LiIONpghHglHQ4J6V0iWvJqGtMyfy9AkJtGJ1ojQaU5 g67goTrNkhliBiTnmyilmKZjKUAMyoIr0rxLhxBYklu4nZp+O3mfvMXSaqs7TFM= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1793011762; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=pGeqiRbBcJZmwJHs0M8oZ31tUUfyu6RxU8e5//3ky9k=; b=x1VidAV2Z1l+thqyHYEI219K/UX/odTdZrjJiGu+EmVdsg5H35xtLDniI+6DbkJsAk7M wZCYjXLBAcy5WDHapkKnsiM1xAl/eAG2lQyUcfn8jeM+33aasX7KmMnqSeE7p18M/Rfcg p0lbmQH0jv/Zd9rZJhfteuAyihfQZeWGMP7W2aiApSMBsfzdOR8YFGYgVoPaxzfIhwrOC lBoV0B9ibC0jSWaaALOc5Ux4PHkY/J+8ItWmxozlnssWxIpLppPsJXfr0wvcvB57vv/Yd rAgiQnIYfTQ74/vtuHtwgNoqPaLhzJVhlBDGRArbnOPvlWGZ8vVY5fxE+P2/vLFydqlFD +FMFm2H7fGUmlxTbrptpRp2wbCKzvfxJVUYv1mwXyqauff6OTWre1BKHVtpN6hTXuXTzv e0LyKyzHnaDhEeBUTbSGQqkd0Trk94PBzmg9Z9ywoVu1r8Fz/Tt4cTHGAmNzblsVB+oiO vGW8ajZDmt2AxhmdnM+3+D79s16OlVp8l5xgExjDc1mEm/PSxoNAeegreVIffx2+COstY znEaRmgCA0BfA5F5Fd9TRh8UvHRKj5Uq1Rtzlpq1KKzcI3wd7cgAox/XZeecwDpv/sTen V+lmuB1Emhu+hOMbXnL7+jiqhUweVLkS/CDJmQ/dVJUgDH02zUoDturtTKZ4KzE= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Mon, 26 Oct 2026 11:49:22 +0100 From: Nicola Vetrini To: Shuaidong Chen Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Michal Orzel , Jan Beulich , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang Subject: Re: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations In-Reply-To: <20261026030309.2507461-1-shuaidong.chen@amd.com> References: <20261026030309.2507461-1-shuaidong.chen@amd.com> Message-ID: <806ad55d683fcef1ec04c7b90965b363@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-d62444/1793011762-BCB45757-20D8D37C/0/0 X-purgate-type: clean X-purgate-size: 3740 On 2026-10-26 04:03, Shuaidong Chen wrote: > MC3A2.R14.3 ("Controlling expressions shall not be invariant") is > deviated by two separate entries. One covers 'if' statements and > conditional operators and places no restriction on where the invariant > condition comes from. The other covers 'switch' statements, but only > when the controlling expression is a 'sizeof' operator. > > The rationale recorded for the two is the same: the condition is > deliberate. Nothing about a 'switch' makes an invariant condition less > deliberate than the same condition in an 'if', so the 'sizeof' > restriction reads as an artefact of that entry having been added for > read_atomic() and friends in arch/x86/include/asm/atomic.h rather than > as a considered limit. > > Fold switch_stmt into the general entry and drop the > 'sizeof'-restricted > one, which the general predicate now subsumes. Invariant 'switch' > conditions that are not a 'sizeof' become deliberate as a result; that > is the intent. > > Signed-off-by: Shuaidong Chen Assuming maintainers are ok with this relaxation: Acked-by: Nicola Vetrini > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++------ > docs/misra/deviations.rst | 8 ++------ > 2 files changed, 4 insertions(+), 12 deletions(-) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl > b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 7f3fd35a33d..08a88ddfa62 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -472,12 +472,8 @@ activity." > -config=MC3A2.R14.2,reports+={disapplied,"any()"} > -doc_end > > --doc_begin="The XEN team relies on the fact that invariant conditions > of 'if' statements and conditional operators are deliberate" > --config=MC3A2.R14.3,statements+={deliberate, > "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator))" > } > --doc_end > - > --doc_begin="Switches having a 'sizeof' operator as the condition are > deliberate and have limited scope." > --config=MC3A2.R14.3,statements+={deliberate, > "wrapped(any(),node(switch_stmt)&&child(cond, operator(sizeof)))" } > +-doc_begin="The XEN team relies on the fact that invariant conditions > of 'if' statements, conditional operators and 'switch' statements are > deliberate" > +-config=MC3A2.R14.3,statements+={deliberate, > "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator||switch_stmt))" > } > -doc_end > > -doc_begin="The use of an invariant size argument in > {put,get}_unsafe_size and array_access_ok, as defined in > arch/x86(_64)?/include/asm/uaccess.h is deliberate and is deemed safe." > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 32713172067..99a1b2332c2 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -458,12 +458,8 @@ Deviations related to MISRA C:2012 Rules: > > * - R14.3 > - The Xen team relies on the fact that invariant conditions of > 'if' > - statements and conditional operators are deliberate. > - - Tagged as `deliberate` for ECLAIR. > - > - * - R14.3 > - - Switches having a 'sizeof' operator as the condition are > deliberate and > - have limited scope. > + statements, conditional operators and 'switch' statements are > + deliberate. > - Tagged as `deliberate` for ECLAIR. > > * - R14.3 -- 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 Oct 26 10:53:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 10:53:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461098.1672049 (Exim 4.92) (envelope-from ) id 1xLIKf-0003Ez-G5; Mon, 26 Oct 2026 10:53:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461098.1672049; Mon, 26 Oct 2026 10: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 1xLIKf-0003Es-DM; Mon, 26 Oct 2026 10:53:37 +0000 Received: by outflank-mailman (input) for mailman id 1461098; Mon, 26 Oct 2026 10:53:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLIKe-0003El-8L for xen-devel@lists.xen.org; Mon, 26 Oct 2026 10:53:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLIKd-00CqTS-E0 for xen-devel@lists.xen.org; Mon, 26 Oct 2026 11:53:35 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf312c-bab6-0a2a0a5309dd-0a2a4502d596-6 for ; Mon, 26 Oct 2026 11:53:35 +0100 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf312f-6ca4-0a2a45020019-d155dd34c910-3 for ; Mon, 26 Oct 2026 11:53:35 +0100 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48df4e9d2d4so1628678f8f.3 for ; Mon, 26 Oct 2026 03:53: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-48e3ebcb9cesm16404094f8f.27.2026.10.26.03.53.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 03:53: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=1793012015; x=1793616815; darn=lists.xen.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=P5VXy3Jq0W6UUJoLekGL4KjcTVX70TQ0tOiUDRg1tCo=; b=KTTnkl9ZkL+YqPH5rmaVdW+voZVIBE2FBE84oRpOf19QjrLmQjbKMagSU463pAoKVg rJl68onV8cKAYZlQcb9gKKPiINYAUuQDTxdrr+FdZyLyVZIbbPD5fjjxAaRbl+WVl1iy No2gVhQwDH+jCKD4JZaqNJB5+et9qIFA2Rh3BR3exWcqxHPrp+Lv+59fisa45Yn0G+1z lRO6PYBjJi5iSlrdckezAQa9PcD7Qq5NeIwFrpxeDTCqwG0JKoYN42VmcZtEaUXA2Bgx puZYAlBr1cnDuLhnxf90whFEhJ7BG7vMSGPoNXJjEjX4A+eUWsPsT3COpYOIKB1NGOGz xkQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793012015; x=1793616815; 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=P5VXy3Jq0W6UUJoLekGL4KjcTVX70TQ0tOiUDRg1tCo=; b=F5mQFFhYSp9uKs7RgHblsJrOjgOCA/9FEF+0aHkCPI7n4+8g84SFH04+sMG7r3GFLU c4uiu0o1UmQwb+E4P+ofzRcn8Wja6GuUnp2RWBSHLI1/WODyOoJSR8gNhmpUDa9r1vzc Em1TDU5lFvXyujzUPJqb7yasiCcj1HLV9EbXvUTrBaaZzUt79Pv6kZk7/Rt5deYUzyZi JRWSZSlJXno9+pTC7gBCUSHry7q8Xoqx+fxDvxFihTVlWaDJqnxYfGTvRnaHSO3CMKrP s9vjNcvzosW7SfarTTkHcnwrC5x4PT4t0GeXkCi6FHKkSVG838THE4Pv41UEySU/4SyM dFHw== X-Forwarded-Encrypted: i=1; AKwUvBz/USkD27tSlV8Sf+3sP+moyXd2oHmZxB6W+RMt0OuBY3HJBHLSSqUNXVSPMwaAB91PnHLmKicGn78=@lists.xen.org X-Gm-Message-State: AFq9FYIwQKcQa+k2y2fc2mXaB1UPU7jFEq3E4l6ZlUbNEdvyshjv6Ta9 5lbxl4T9uhj+zA4vmf0fJpgcyWrkTTMp/3s4D+I21YHJ0vc3z0RvOynFM/zov+Byrw== X-Gm-Gg: AYBFou3VzzjxyOzwSDkOgDNJ79GZ4VyIQKwqVVmLs2NoxW8IHrMWlKLHlgs5RkfJkK1 U31Yo/ME33wCN5FrumBYZ7rHblAFZLbdcInJ7HN4VJ8od5MzPM8MGoMsszIZmTYuN/zhUGlnNSP QdQfh1PaYOmW1P2zVv0AIanu97dqnzviaypBBf8bvqrrrK4GR1QyUpEK+jU/23Aa7/po0BiQHzi Q0WLqR1PivUfqXjxXdwozPhz1b8iIbq7DsvIPbjamguBUHl1iT1gn6s69F5Fa+0TaUO7h5YQd9c DeqSo5sxLAas1yk8rQlRGt4Faqgcbl6qASWJEFoJbZwjhFNC4/gwp3kOE3IqaPPcllLN1Mw3FMz l4FKFHg8wo8wYOZrUNY4N9y5eYLp10jbVfQkxXcrTMWTZGQcOyn5ZGRc4sVpJ5EsP1Cel/QILk0 RkaaSYPnMVbhel6942BOgDsb200Hi2vAxakohu+xR7ZDpGlztfGUVlLCpTrnoWR3esXWIB6Tl3e lNJQmzhJ0JjVYGk0AUu0WLPe7yR54ndjv+24pHwnmL3On+PtwVpmB+MocLra+JudFKhPLPJMhFB VF4wnGudYWC+ObtJuKlMbVwKUwqhO2tGZ8Y7QQsVx0U= X-Received: by 2002:a05:6000:4b14:b0:48b:10c8:2181 with SMTP id ffacd0b85a97d-48e3eb932b2mr11946300f8f.27.1793012014518; Mon, 26 Oct 2026 03:53:34 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 11:53:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Peter Deggendorfer Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Soham Dandapat , Andrew Cooper , xen-devel@lists.xen.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: 8bit X-purgate-ID: tlsNG-720697/1793012015-321D72AC-DEFD27F6/10/78276251493 X-purgate-type: spam X-purgate-size: 8293 On 25.10.2026 13:32, Peter Deggendorfer wrote: > >> Hi Andrew, >> >> Thanks a lot for the quick response. >> >> >>> On 23/10/2026 8:32 am, Peter Deggendorfer wrote: >>>> Hey Xen Team, >>>> >>>> I'm hitting a reproducible hypervisor panic in the AMD non-fatal MCE >>>> polling path on a Ryzen 9 5950X (Zen 3). Eight occurrences since >>>> 2026-09-09, between 12 hours and 2 weeks apart, always CPU 2. >>>> >>>> Environment >>>> ----------- >>>> Xen:   4.20.4-pre (Debian 4.20.3+127-gc42374a105-0+deb13u1), and still >>>>         present in 4.20.5-pre (Debian 4.20.4+39-gf1e1321c87-0+deb13u1) >>>> dom0:  Linux 6.12.111+deb13-amd64 (Debian trixie), PV, 32 vCPUs >>>> CPU:   AMD Family 25 (0x19) Model 33 (0x21) Stepping 2, Ryzen 9 5950X, >>>>         microcode 0x0a201210 >>>> Cmdline: dom0_mem=4096M,max:4096M ucode=scan console_timestamps=datems >>>> >>>> The panic >>>> --------- >>>> (XEN) [2026-10-19 08:58:18.727] Xen BUG at >>>> arch/x86/cpu/mcheck/mce_amd.c:100 >>>> (XEN) CPU:    2 >>>> (XEN) RIP:    e008:[] >>>> mce_amd.c#mc_ec2type.part.0+0/0x10 >>>> (XEN) rbx: 0000000000000445   r12: 0000000000000011   r15: >>>> 0000000000000446 >>>> (XEN) Xen code around : >>>> (XEN)  90 90 90 90 90 90 90 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 >>>> 90 90 >>>> (XEN) Xen call trace: >>>> (XEN)    [] R mce_amd.c#mc_ec2type.part.0+0/0x10 >>>> (XEN)    [] S mc_amd_recoverable_scan+0x39/0x40 >>>> (XEN)    [] S mcheck_mca_logout+0x42d/0x840 >>>> (XEN)    [] S >>>> amd_nonfatal.c#mce_amd_checkregs+0x1c/0x100 >>>> (XEN)    [] S smp_call_function_interrupt+0x4c/0x90 >>>> (XEN)    [] S do_IRQ+0x2a5/0x650 >>>> (XEN)    [] S common_interrupt+0x135/0x150 >>>> (XEN)    [] S >>>> cpu_idle.c#acpi_idle_do_entry+0x8a/0x140 >>>> (XEN)    [] S >>>> cpu_idle.c#acpi_processor_idle+0x1ef/0x650 >>>> (XEN)    [] S domain.c#idle_loop+0xc1/0x130 >>>> (XEN) Panic on CPU 2 >>>> >>>> The outlined mc_ec2type.part.0 contains nothing but the ud2, so this is >>>> the "unreachable" default branch of mc_ec2type() -- the extended error >>>> code matches none of MC_EC_TLB_TYPE, MC_EC_MEM_TYPE, MC_EC_BUS_TYPE. >>> I think it's safe to just drop the BUG(). >>> >>> That code is literally worse than useless, because if nothing else it's >>> just hiding the diagnostics. >>> >>> I guess it means AMD have added new statuses. >>> >>>> Across the eight occurrences, r12 appears to be the bank index from the >>>> loop in mcheck_mca_logout(), with rbx == 0x401 + 4 * r12 (MCi_STATUS) >>>> and r15 == rbx + 1. Three different banks are involved: 10, 17 and 23. >>>> >>>> Not a hardware defect >>>> --------------------- >>>> - Started within days of upgrading two hosts from Debian bookworm >>>>    (Xen 4.17) to trixie (Xen 4.20). They had run 3 years on 4.17 >>>> with no >>>>    incident. >>>> - Three different banks, so not a single failing block. >>>> - Updating to the current Debian package (4.20.5-pre, built 2026-10-16) >>>>    changed nothing. >>>> >>>> Possibly related: 532988dccc19 ("x86/mcheck: fix mca_allbanks >>>> updating"). >>>> >>>> Also possibly related on the Linux side: 0422b07bc4c2 ("x86/mce/amd: >>>> Filter bogus hardware errors on Zen3 clients"), where bogus MCA values >>>> on Zen 3 are filtered rather than treated as errors. >>>> https://ratatoskr.run/stable/2026/04/7143905 >>>  From above, you're on a Vermeer, not a Cezanne, so I don't think that >>> Linux patch is relevant. >>> >>> However, your observation about "fix mca_allbanks updating" quite >>> possibly is.  That was backported into Xen 4.20.1 as 247b708b1400a, and >>> Debian has 4.20.3 >>> >>> Are you able to experiment with that patch reverted? >>> >>> Alternatively, are you able to experiment with the BUG() removed? >> >> I went with dropping the BUG() rather than the revert. >> Reverting 247b708b1400a should stop any bank from being read at >> all, which is effectively what mce=false already does here, so I don't >> expect it to tell us anything new. I'll run it too if you'd like. >> >> I'm not familiar with the Xen codebase, but I've built a package with >> mc_ec2type() changed to: >> >>     if ( errorcode & MC_EC_TLB_TYPE ) >>         return MC_EC_TLB_TYPE; >> >>     printk(XENLOG_WARNING "MCE: unknown AMD error code %#x\n", >> errorcode); >> >>     return 0; >> >> >> Crashes have been 12 hours to 2 weeks apart, so it may take a while >> before I can report back. > > After ~31 hours of uptime: > > (XEN) [2026-10-25 04:06:27.260] MCE: unknown AMD error code 0 > > No panic, no wedged CPU, no RCU stalls, no hung guests. Host and all > VMs running normally. > > > I also dumped /dev/mcelog in dom0 and got the following records: > > 00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > 00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > 00000030: 0000 0000 0000 0000 0200 0000 0000 0000  ................ > 00000040: 0010 0201 0200 0000 0000 0000 0200 0000  ................ > 00000050: 1c01 0000 0000 0000 0000 0000 0000 0000  ................ > 00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > 00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > 00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > 00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > 000000a0: 0000 0000 0000 0000 0200 0000 0000 0000  ................ > 000000b0: 0017 0201 0200 0000 0000 0000 0200 0000  ................ > 000000c0: 1c01 0000 0000 0000 0000 0000 0000 0000  ................ > 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................ > > >> >> >>>> Diagnostics / workaround >>>> ------------------------ >>>> mce_verbosity=verbose yields nothing useful. >>>> max_cstate=1 made no difference. mce=false is the only thing that stops >>>> it, and it is what I'm running now. >>> The fact that mce=false isn't causing machine resets means it's clearly >>> something the hardware thinks isn't fatal. >>> >>> But, I am concerned by the fact it's always on CPU 2, and multiple >>> banks.  Is this true for both systems? >> >> To clarify one thing from my report: it is actually a single host whose >> complete hardware (board, CPU, RAM) was replaced on >> 2026-10-07, keeping only the disks and thus the installation. The >> crashes happened both before and after that swap. 10 more hosts >> with same hardware still run on bookworm (xen 4.17) for years now >> without any incidents. >> >> So yes, always CPU 2. The bank index varies: on the current hardware >> I have seen banks 23, 17 and 10 across four crashes, and banks 23 and >> 17 on the previous hardware. > > Regarding the output of /dev/mcelog: if my decoding is right, three > things stand out. MCi_STATUS is zero, i.e. these banks are reporting > nothing at all -- no error, no garbage value. Well, things can't quite be that way: If MCi_STATUS was zero, the first check in mc_amd_recoverable_scan() would prevent mc_ec2type() from being reached in the first place. Its caller also checks MCi_STATUS_VAL to be set. What I find puzzling is this: errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC); ectype = mc_ec2type(errorcode); With errorcode (and mc_ec2type()'s parameter type) being uint16_t, what use is it to include MCi_STATUS_MSEC in the mask? (Yet that's likely unrelated to the issue at hand.) Considering how mc_ec2type() works, I see no reason why status couldn't be passed to it directly (with the parameter type widened to uint32_t). Then the BUG() there could perhaps become BUG_ON(errorcode). > Both records are again > from CPU 2, and bank 23 is one of the banks that appeared in the > panics, bank 16 is new. Isn't it possible that the lack of 532988dccc19 ("x86/mcheck: fix mca_allbanks updating") simply hid the issue previously? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:00:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:00:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461111.1672067 (Exim 4.92) (envelope-from ) id 1xLIRR-0005Yo-Br; Mon, 26 Oct 2026 11:00:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461111.1672067; Mon, 26 Oct 2026 11:00: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 1xLIRR-0005Yh-8l; Mon, 26 Oct 2026 11:00:37 +0000 Received: by outflank-mailman (input) for mailman id 1461111; Mon, 26 Oct 2026 11:00:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLIRP-0005YY-KA for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:00:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLIRO-006id1-QH for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:00:34 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf32cf-e002-0a2a0a5209dd-0a2a4502c906-28 for ; Mon, 26 Oct 2026 12:00:34 +0100 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf32d2-6ca4-0a2a45020019-d155dd34bd8d-3 for ; Mon, 26 Oct 2026 12:00:34 +0100 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48e0d1c095dso1648387f8f.1 for ; Mon, 26 Oct 2026 04:00: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-48e3ebcb902sm16480172f8f.24.2026.10.26.04.00.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:00: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=1793012434; x=1793617234; 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=ei7vttzd16p5T1ZrEZ/u/MoBXfEEiqIvkZTZGi05x10=; b=CcmUl1GnBFLFIo7L2yVOkEW4vXLfEtKfRmYHSL3PRrQsJ+cXdyIPKbpOAC6hlvvSQw 9ZI+rovZndhmOTHrd7WlwR11/s6kPEnjWmx6kd+vXrB9xk/mhR7EFkOKTcZlBKEvsgJx Nav5xWraAh+pmXJvhUn78kLYOh/3zUXiBlVnVUl4arChlcOyCxuzNVvjbywZyJu3nJi/ quuzUewEvpE7FXQwVoyaQ8lTuV3E86VZI5W5rxAqVF4A9KBNIn/JlINdgC8IwQFnyEPW xcF82atMmlKBH8tnDMl+UIvyWGYNSfLJTHf1SDsSy/U2+1BiO+jO1KiPrQYfXifCiqyS 8nvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793012434; x=1793617234; 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=ei7vttzd16p5T1ZrEZ/u/MoBXfEEiqIvkZTZGi05x10=; b=NDZEUA1eZPTPRYbhxgRuxZyYfMQt6NErJWc0PmRpFkc0yRN92kRPBAQq/EMbqSwbUf gtoYfCBenuXTwIoCSPYoQA+9B0wCJ2+knEa5io7NSj6goyOTYEhveG8DlWjyBXvqZpsF fVyQUPZviu/NtpslcjyWdKIPp9wQI7WTRkYED6H0tK32u385fmLgRWYh5C7BydZ953wM aBA2aQKthmJLHbLwhG24x1bsk0Zm0qLrNJJuOSQu0TNW4LZyIw8LaKDdxIi2My+trXhY bDPIRQ+ivxXXM29VrNq4MJVy+vwu4ycYaz/uWJrGZnHeOH1r52ckhL4hHtsA7AJPByPl m73w== X-Forwarded-Encrypted: i=1; AKwUvBy5rBFre8vcUL14qXGBogj0/Er+x98aqpGO4L5tXjy82raPGqma/9qlCM8sZSo4c2mghBnxoXoqtqY=@lists.xenproject.org X-Gm-Message-State: AFq9FYIOMSF5m3GPOf4KkxIHPijNhHEDBiPP11+ZaHUdgZZRgLS1BRBO fOIS38Ibihg6gJgQV9ZqJpijGolFAxg7mv7YaSFE2j2Ta91R9ClF7M+afTck2jmlrA== X-Gm-Gg: AYBFou0k8ZNs12QgoO2iF/09MaV37dAdL4lTuaiI6J6au9A0+VUcBq5Ft99qXS0gfy1 oY8UduFQHx1+D/zO2wSsvDyvU0tTj+TfY07K9fIf5/FTmzE/4pK5abkSdz7MKrxRsuvt3K8lbTb Odv84nAqgKPHvgZ/zG9E+Vqfy86u8+tNuRQBESbQBIK5n5j1ls75IcHSjjte0i9yYwzwJJiTsFg /EseXwqvgMjNXgLVNu1tRiLRu/S9rGuwswZWWr+y7rlMGqG5K5WlqY/eDFbzsSDimK0wwOMpKkY YCibWrGg0/QqUq8SIPGX1OYOuUhzCLuhmmpYepJov/ZpN09J4Rh4lbu1gXMNEJ1DMH2QqOSDQC3 EFDdwq4cei+XJnH1vQ8icuLU3C7o4bfUMOUtsof7w6XgfCGF93pDKWMt/ex7KOsJvWawNiZj9Jn Jf3/E/p3FQZhFzWYGgFptzc3PEDXc9n5+OnN3D9YTOilwKSX/bqFKfqjXXxH9vmGrkwoTPaH1rY S8v2B0RLSNZ374lwCSOklLvggjexrHOib3iwhEkOa+CzAMgzUbHryaktezjTdV9XmxlYWllnv+1 N54l2mQvT7RKG/ej73q7FJ9Xi890ESpohEQhyV/ksx0= X-Received: by 2002:a05:6000:4285:b0:48e:bf0:352 with SMTP id ffacd0b85a97d-48e3eb4676cmr14524867f8f.5.1793012433986; Mon, 26 Oct 2026 04:00:33 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 12:00:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/page_alloc: scrub each page in unprepare_staticmem_pages To: peter kang Cc: anderson.choi@boeing.com, matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com, Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <0caeae8b795439ba7f9d466571f0d125b924feaa.1792992356.git.peter.kang@boeing.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: <0caeae8b795439ba7f9d466571f0d125b924feaa.1792992356.git.peter.kang@boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1793012434-F24B62AC-235FEE46/10/78276251493 X-purgate-type: spam X-purgate-size: 1140 On 26.10.2026 07:00, peter kang wrote: > From: Peter Kang > > unprepare_staticmem_pages() can unprepare multiple pages in a static > memory range. When need_scrub is true, each page must be scrubbed > before it is marked static. > > The loop currently passes the base pointer pg to scrub_one_page() on > every iteration. For a multi-page range, this repeatedly scrubs page 0 > and leaves the remaining pages unscrubbed, so a guest can later read > stale data from pages 1..nr_mfns-1 of a static or static-shared bank. > > Pass &pg[i] to scrub_one_page() so each iteration scrubs the page it > is processing. This ensures every page in the range is scrubbed before > it is marked static. > > Fixes: 4a9e73e6e53e ("xen/arm: static memory initialization") > Signed-off-by: Anderson Choi The patch itself is fine, but the tags aren't: The patch needs your own S-o-b, and in the vast majority of cases the first S-o-b should match From:, while the last S-o-b should match the sender. Also please update the Cc: list - you've used a stale address for Roger. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:05:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:05:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461118.1672076 (Exim 4.92) (envelope-from ) id 1xLIW5-0006SD-Qw; Mon, 26 Oct 2026 11:05:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461118.1672076; Mon, 26 Oct 2026 11:05: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 1xLIW5-0006S6-OS; Mon, 26 Oct 2026 11:05:25 +0000 Received: by outflank-mailman (input) for mailman id 1461118; Mon, 26 Oct 2026 11:05:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLIW4-0006S0-3z for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:05:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLIW3-002qxv-Gl for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:05:23 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf33e8-2eae-0a2a0a5409dd-0a2a4509e9ca-36 for ; Mon, 26 Oct 2026 12:05:23 +0100 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 6adf33f3-be1a-0a2a45090019-d1558033cd6e-3 for ; Mon, 26 Oct 2026 12:05:23 +0100 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a20bdaf39cso29306665e9.1 for ; Mon, 26 Oct 2026 04:05: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-4a35a574088sm173363975e9.9.2026.10.26.04.05.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:05: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=1793012723; x=1793617523; 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=gRd9NLigJ/Lfv+mIBIIn60b6XHzhKUKIv5UMPZtc1vo=; b=R0owN+3ZboIZ6CDaIbYczzyvuGL4DOvig8VNShcSclTEjPVtfFAZ1BmOIdmJAahm6Q apiHZUDy3XQaSPeU/9Sl3+okw31pCHMI4hSFW34KKE4FVk1B3NnAkqOCky9Xfk/T2GSw k2TDcbcItjwcd788XSvqrjpY0R2J2F3fz/S3atbis2Ox6Ua+CYNwozNXRbiI5dLRj1Fo b/JzESOcYQrCR0GtZ7yTJIfWesxt4cYqqxX7OBgCcl4fL+jolhKaoOZqPI46nd5Ppub1 VDlnCTqNLF/+RY3G8/VHxTBeukAvwRKOcXdnSPK2rMPgBtSkXiJoDA5UQzXCb0ozgFNa stQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793012723; x=1793617523; 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=gRd9NLigJ/Lfv+mIBIIn60b6XHzhKUKIv5UMPZtc1vo=; b=2XtOeGi7OettNGT3J4S2UqoZn1s1m+FVw+VOsrR3qSg2bip3f91mwMIohiiWQUTd3s Bkr5dJLVzBODRsdFDO6O2ihfdfMNd/h2YQPko7FCcnrjmjSLc73he9XlkALsUHjZwSDn cAmiUPeCqd3IN+2rx8sgZPUOcKz4j55l2qEmpbBjIoNmvoWHccc8k5f86SYU41XnNLB6 Vf/0icdtbKg/PqE4zE4t2Nzv3do/pNbr8qPxLRO3SCSJnSKkASZxtcqv112PzkGtllKl 7jpx0sMPYW5DSjumejD9o0z05/L5N9/GKgECPpDcbcA+Ftbrsp1UH+C0Fy47RVxwMRtV bapQ== X-Forwarded-Encrypted: i=1; AKwUvBwUgF/XMnz4Woz1sYElvN9u1bZp3DLzva2reuf0WWDPl049zsH6El+24yPpcqJY3DgJtI7eIz1ruuA=@lists.xenproject.org X-Gm-Message-State: AFq9FYIjQXylJWFfz6wGaEBmr1mE9AIswn9gOY33/n8NMWpsSMpOx928 93zIFw4x+hj0iuH7jUYTgIGZs/wRtoB8G36UT3ICxiDj09t766J+8Ow8z2pgVqyfHw== X-Gm-Gg: AYBFou2XD0LEjGewoAoBjOvz2NxIsMR0pJBVI76oBslxWJUjbLx0CGYu/JxvuQ0P0pM I6SuhPIm6K2tTMoeR8HKR1D7Hd9MxaCty/N7Eme9X2W7foWu17Arw34A/4E2/YyrqVT9FIJIrh7 2cPeGmse7CX0s4jGgsBcyrFSYTPP5wTBgbGcgC2eT6xXlfvynL/KuF0ujerR7kFoz/HpO7DyhZB 3AEumFaGOywQdbAeisPPv5P4cwk2MZtcXyjuXeXrAG6HWhbNQaznX5AQYZUcgfr8N5bnuN7V0l2 b+YoH+anxZLAJb9AUsgXm0+X1GTwMMAwDi4Tgx62695niXyNnbtAaSCgSNs2d3Zbyhzgmoyjie/ oxi4fvrwwNKpuyLRkI1sA2xy9kyWUuxT0obEdToPvSfLcDCwVT8or7gFFMr9Rop7sqqZH5g4PLj 5eUfmGYeXWkmBhSvkOkAN7AB/R3fx7nKfo+5KFGxDTSAAAx+pdvs8Iy26ZGStgpK1a9yM4J89mC Cwudt7RyeXHeyAivPeDOC5vkM7elepZ6Kt2B55drqPvtnhnrMo12ewxNO35gMOOqhvZNukUWTv8 pCG0gU/tyDFGaRjiH9DRhI4zt5fdytp1KnXYbmqOGVVBGc/90ZkwKHhvHZv7pWsV X-Received: by 2002:a05:600c:3d92:b0:4a1:d8fc:8165 with SMTP id 5b1f17b1804b1-4a35aca3f99mr113389125e9.20.1793012722177; Mon, 26 Oct 2026 04:05:22 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 12:05:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] automation/eclair: generalize the noreturn function-pointer deviation To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "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-bad1c0/1793012723-BE6DA034-B1C3890A/10/78276251493 X-purgate-type: spam X-purgate-size: 839 On 19.10.2026 10:51, Dmytro Prokopchuk1 wrote: > The R11.1 safe cast only matched void noreturn (*)(void *). Accept a > conversion where noreturn is omitted and the signature is otherwise > compatible. canonical() covers typeof destinations, and > compatible_deep_unqualified keeps the parameter and return types aligned. > > Discarding noreturn does not change the calling convention. Code after > the call is unreachable when every possible callee is noreturn. Leaving > that code in place is a tolerated Rule 2.1 violation. The full rationale > is in docs/misra/deviations.rst. > > Signed-off-by: Dmytro Prokopchuk Acked-by: Jan Beulich # docs/misra/*.rst I'll be happy to drop the scope restriction upon seeing an A-b / R-b from Nicola for the .ecl change. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:09:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:09:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461124.1672084 (Exim 4.92) (envelope-from ) id 1xLIaF-0007S4-BA; Mon, 26 Oct 2026 11:09:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461124.1672084; Mon, 26 Oct 2026 11:09: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 1xLIaF-0007Rx-8W; Mon, 26 Oct 2026 11:09:43 +0000 Received: by outflank-mailman (input) for mailman id 1461124; Mon, 26 Oct 2026 11:09:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLIaE-0007Rr-Rf for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:09:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLIaE-002rn0-1c for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:09:42 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf34ea-bab6-0a2a0a5309dd-0a2a4502afd0-26 for ; Mon, 26 Oct 2026 12:09:42 +0100 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf34f1-6ca4-0a2a45020019-d155dd2ce4e0-3 for ; Mon, 26 Oct 2026 12:09:37 +0100 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48df54150dfso1520824f8f.0 for ; Mon, 26 Oct 2026 04:09: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-48e3ebcb851sm13574772f8f.26.2026.10.26.04.09.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:09: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=1793012977; x=1793617777; 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=jXp73Q06dDpky/Pakzf4g5UPTalodca1jVmDxhyWTr4=; b=Vge9Gm79AcMtKS46Pz0GRCql9dDNBQCPIBWTGp/Efd1lksawMVa3wqH2furzfkN02n xzXeKX5w8fif4MmYjtVjCJnMBGtYqhWLwel4MbWqR3aZvbUp00JvHAMERM7rRwxbDgVr mKUwKdSUK9c/JRUwXTZgd6d2QFJPG90bwSIxbzgic4DwlW8uo4N4UtqmKdHDPwpQ15MW E4N3w3POWwCrDWNQ83za7rRoQRFGGHWzD3Na+JpE4YdeQsYsiJgwlNma+5QOWWXYGyAD ymBY5o5n+nevwYvkuxvlreSWgR6eNI0SaN4ychd2X9Gi1hXLiaTa90aeWFrRwzecJomR kDXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793012977; x=1793617777; 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=jXp73Q06dDpky/Pakzf4g5UPTalodca1jVmDxhyWTr4=; b=wRo/YLbl7IureV3roaDbKwZb2v+wJsvMwVn0c483zLLYqvE/YjxGx/93IhtmdXBMEq RL8NPTkIplZ6NcpHKgLzl5jJR1Ak8+FNRCDPj2rejpGIgGe1UJV7+ezZ6P/QwYSw9Qq1 yL0E1mmsnIFXf3ecoAbPkiSoMEuZN5G/zQMEq/+/bEHL8RiJs/f61dElNAAGhJjtzgZi psPZbtu7jaHc4mlTXY9k2+aGFUcnltVgAaeDTJTPvRzBjM0OMAXiEbI6MozR6AaieFYW mKfAdT7br3tp3/CVHMklWldazC93ZtXDkIexUtBC9fu3Bw5EYrRLteCpd1RYV+w2NB48 4XGA== X-Forwarded-Encrypted: i=1; AKwUvBxobbSyS9EjkfeyhL9MCIf00+K89xdpaDtLa6qKLZ1SILECGTF4u8EZqLLNqE4FSOh23Tz11tgOxRU=@lists.xenproject.org X-Gm-Message-State: AFq9FYL51X0xXD0iRfLbsM0OM2ucy6AIeEjmwpR17NT9BGkik4j/3RXl vnUY2tayF0ACXa/Az6BeUm+N0v9jVTpbu6OMFKPyJ8eJSk86UZGh1f9XMAOnh4Mi1A== X-Gm-Gg: AYBFou2LcTb3RFsJ5nde1tnvhNZlDYeEJ/26JKrJ/jhQwzrPcpTCLGw41vFwNZEER8V BuilAK4kzvPSyKIDkRcBiDQ0e00fqRyRg6HGCDXfoMQbjV3nmMuPgAf7RBYbq+8VB351PNIZMfd DjfADaOHf21QdjKqxbUY18+lDvZaYO2VRxcKjONAG+Hkk1DlM4ltT4kWEsW+DwDFlqF9xV8UhCg nV/1jeAsc3ss+3n00tAUL+ayush9nOJYtTv+Q0aQXFksMUABNkRbOkMUWrt7i1YL48ofcFyfN0e ZIUNRMlJnhfOnfqXcK0/217vlmJMTOehh4WBK/f6oqE/nDJoGLsr8EytGGGlR40XnwhlbVa5TYf /iLjLafU7M92poPmjiH+YoAAZnbsjtiblWcnA7DtFKcLaI769jXqg2vhBe/OAXoTTK7Tn7OvT+B 9SKKEXJOdZ4NmVUA7ZDAAE7utzoTVMjU9nLqSr3Blpvc7sYtd7hcPNjnTjehHs9ia8hcCeT/f6Q oOx01BKEnmbcxS5Ah6bmC23kZDHcIN2fWiEHOhtFDcBuGfnSO0mcIpQ7PfCO01kKuMfIHEzGPJb puYcBdRaoPaozyHFomVT0DRM9te1CJATRoZTl2Zr9+IKzld8fwSaqfd9iTAnA9mmOA== X-Received: by 2002:a05:6000:27c9:10b0:48d:f3a4:a6aa with SMTP id ffacd0b85a97d-48e3eb926cemr8757404f8f.35.1793012976668; Mon, 26 Oct 2026 04:09:36 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 12:09:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] misra: deviate C library-style functions from Misra C:2012 rule 11.8 To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "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-720697/1793012977-66CB22AC-559AF4B3/10/78276251493 X-purgate-type: spam X-purgate-size: 1854 On 19.10.2026 12:41, Dmytro Prokopchuk1 wrote: > bsearch(), memchr(), strchr(), strpbrk(), strrchr() and strstr() all > accept a const pointer/object but return a non-const pointer to the > matched element or byte, matching their standard C library interfaces. > The casts in these implementations strip const so that callers searching > a non-const object get back a mutable pointer. Fixing this would require > changing the public API, so document these uses as deviations instead. Imo "public API" is misleading here, as it could mean "public interface", which isn't affected here at all. Then ... > Update docs/misra/rules.rst to note that this class of double-use > library functions is deviated on a per-function basis. > > Signed-off-by: Dmytro Prokopchuk Acked-by: Jan Beulich Albeit there another minor remark: > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -450,6 +450,14 @@ write or not" > -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(hvm_guestcopy)&&text(^.*__hvm_copy.*HVMCOPY_to_guest doesn't modify.*$)))"} > -doc_end > > +-doc_begin="Functions bsearch(), memchr(), strchr(), strpbrk(), strrchr() and > +strstr() accept a const pointer/object and return a non-const pointer to the > +matched element or byte, matching their standard C library interfaces. The > +casts in these implementations strip const so that a search of a non-const > +object yields a mutable pointer. This use is deemed safe." > +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(^xen/include/xen/bsearch\\.h$||^xen/lib/(memchr|strchr|strpbrk|strrchr|strstr)\\.c$)))"} > +-doc_end Can't we fold strchr and strrchr here, e.g. as simple as (memchr|str+chr|strpbrk|strstr)? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:13:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:13:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461132.1672094 (Exim 4.92) (envelope-from ) id 1xLIe3-0000it-Ro; Mon, 26 Oct 2026 11:13:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461132.1672094; Mon, 26 Oct 2026 11:13: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 1xLIe3-0000im-Oo; Mon, 26 Oct 2026 11:13:39 +0000 Received: by outflank-mailman (input) for mailman id 1461132; Mon, 26 Oct 2026 11:13:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLIe2-0000ig-Vl for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:13:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLIe2-00DiwI-8n for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:13:38 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf35bf-bab6-0a2a0a5309dd-0a2a4509e6ea-44 for ; Mon, 26 Oct 2026 12:13:38 +0100 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf35e2-be1a-0a2a45090019-d155dd29d006-3 for ; Mon, 26 Oct 2026 12:13:38 +0100 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48e20ed3b9dso2600377f8f.2 for ; Mon, 26 Oct 2026 04:13: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-48e3ebd48fasm15816506f8f.31.2026.10.26.04.13.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:13: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=1793013218; x=1793618018; 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=NQEqAWQAVAbqs2L97mpoqqquPJquF7CTY+1JaDokM0Y=; b=INwc0z6pqAotxllcsOdbRj+pn+gUqdHA+/rQQlpe1kDRUIkjcL5WVQvVgkNULJgO6T dZXSnS38qElXaJCrVfXwIgB+GN80lbmXWGq837G/3lhk8W4SwC7DLaOrWqKIAPD4W+TR H4S7bWxHdXiqrRwG+yaa+Wn6RPnJTsYwKzJvISz/EjFx20kJVC7luJN1oNCkUxwJZCIW F6eeL8H/9BEFiW09Nu/hA4nGkMVgGhCyj8ZnfPOyEMhnYI90A93f1zVPF0ugLCqhHxiv FwtSvWk7g+zOCuHvxw2XvhdydbrQmat0tj/cNiNWg2tDQpH9OGVNALrkwGbUlwNs8w3O iY6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793013218; x=1793618018; 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=NQEqAWQAVAbqs2L97mpoqqquPJquF7CTY+1JaDokM0Y=; b=yArMecOktnUiu7jd891S1zvXzStOCiJz+28YdREUBrlHeLJNOayCdeYpUneX0zIjmB bgj36bm7+ERNsNctEpl6o5UmB4JOQ11dXVZlARMoarj8EgRdOo5jzIHJ88nn159U33rG bk3ow+jxFVG16v/Sif5SaLBWHShfySUHqdqdV+CwPqFTVXQi3xZVZRDarRx5GABCoWce 4TmAsXGrFekcJIm+DjyoaWA3PXxDn4VVEpfn+pmaJBg4TeSCSqEubexufBa9+sx+X5PP t71L0mjNWEl2VpDtQTLaWo59czAY9aOagQvIg2/eoNehxNWFGAdCwpr2W1L0QH1ZXKsQ b2fg== X-Forwarded-Encrypted: i=1; AKwUvBwuxxCj/Fnlc3Rt0th+IvupnGAX7icHWqaZ8SIAtmvISxQP+JDsbCa93fy6JFTC58u10LH/xLyV5OY=@lists.xenproject.org X-Gm-Message-State: AFq9FYJMjGVDYG0FmuVKMXQ6PKb0dcPX/qRCUsF1uxH920NM0+ovwO+1 Jcuban1vTEH+mbmdcaN9cyo2DuPP/ThqblBwfPx8NL07bKsi+ng2JGw9/EtT5yNUQA== X-Gm-Gg: AYBFou3x127UJQVnSo1DwU7EbPHDky5uOW+/Ti9r+rhHeZzZibzGm1UwoMAAOO2HCCm 3RWVqw2xGyoVioPw8dbSYkOc9s3ExLCIClkvklq4/anbkeRP6NiTl5knNKVQs2eMSgIeNBxOieZ HzksqxSXDIXeGzngkfPK3KYoLA6C9S+T9UODBR3NrwMbnYbFL1DMmwphZzyuY38j0rJKt62opAS r06OWBvAC9m1Z9Tef7N0MZbOwflqvuMTPYXt164vCHAdWDmjdoipygF1HXtAXablXjYebGqK/OL depy/cxSDOteHHeB3SB7wFTjZapxzXwpwU1hKfEmqluk/X9KelwJT9xDEV3FC9Py87OIvXPt358 htrcayewOBd2w5NZfVB1kkHnZpYpeiV79yCAOdu6Sn/IF5zfIcHnRqCtzjH1aQ4Icc961A5pAyW ZTrFx55do9ChANe/WM83CvRMOxxoK4e1LnCxtkwLcDi7y+opIsvAo0zBvEhOBq1WXpE8QOf1/62 Acxk97DBBocfxIdowhmov6XcivXZwIeNcaqRPCFviwLFJxf0TIVSbcFlEBcZTXyDgGsDDAgb0Mt kJLir4riUw7QM+wR2QLbKg4xEYjJTGlg0wJAple7zSic X-Received: by 2002:a5d:4886:0:b0:48d:f460:2c62 with SMTP id ffacd0b85a97d-48e3eb8c120mr8654988f8f.33.1793013217544; Mon, 26 Oct 2026 04:13:37 -0700 (PDT) Message-ID: <83187933-b4cd-46df-b428-368d6f71cfaa@suse.com> Date: Mon, 26 Oct 2026 12:13:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic To: Dmytro Prokopchuk1 Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "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-bad1c0/1793013218-FC610034-D738E71D/10/78276251493 X-purgate-type: spam X-purgate-size: 3176 On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote: > MISRA C Rule 10.1 states: "Operands shall not be of an inappropriate > essential type". > > The result of relational, equality and logical negation operators has > type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5), so using > it as an operand of +, -, * and their assignment forms has well-defined > semantics. > > Update ECLAIR configuration to tag such uses as safe. > > Update deviations.rst and rules.rst accordingly. > > Signed-off-by: Dmytro Prokopchuk > --- > Current patch resolves all ARM Rule 10.1 violations (actually, there were only two), > and resolves around 55 x86 violations. > > Test CI pipeline: > https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2963748389 > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 5 +++++ > docs/misra/deviations.rst | 6 ++++++ > docs/misra/rules.rst | 2 ++ > 3 files changed, 13 insertions(+) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 6cdb10a129..8bfb1a0f89 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -335,6 +335,11 @@ still non-negative." > -config=MC3A2.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"} > -doc_end > > +-doc_begin="The result of relational, equality and logical negation operators has type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5), > +so using it as an operand of an arithmetic operator is well defined and well known to all Xen developers." > +-config=MC3A2.R10.1,etypes+={safe, "stmt(operator(add||sub||mul||add_assign||sub_assign))", "src_type(ebool||boolean)"} > +-doc_end Why the restriction to add/sub/mul? The text ... > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -347,6 +347,12 @@ Deviations related to MISRA C:2012 Rules: > well-known to all Xen developers to be a comparison with 0. > - Tagged as `safe` for ECLAIR. > > + * - R10.1 > + - The result of relational, equality and logical negation operators has > + type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5), so using > + it as an operand of an arithmetic operator has well-defined semantics. > + - Tagged as `safe` for ECLAIR. ... here is less strict, albeit ... > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -387,6 +387,8 @@ maintainers if you want to suggest a change. > compilers' extensions) > - Implicit conversions to boolean for conditionals (?: if while > for) and logical operators (! || &&) > + - Results of relational, equality and logical negation operators > + (0 or 1) used as operands of arithmetic operators (+ - *) ... it's again more strict here, yet at the same time somewhat ambiguous: Are all arithmetic operators meant, or merely those named in parentheses? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:27:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:27:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461141.1672102 (Exim 4.92) (envelope-from ) id 1xLIre-00039R-3X; Mon, 26 Oct 2026 11:27:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461141.1672102; Mon, 26 Oct 2026 11:27: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 1xLIre-00039K-0G; Mon, 26 Oct 2026 11:27:42 +0000 Received: by outflank-mailman (input) for mailman id 1461141; Mon, 26 Oct 2026 11:27:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLIrc-000354-98 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:27:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLIrb-000SAC-6J for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:27:39 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf3919-2eae-0a2a0a5409dd-0a2a450a9a50-24 for ; Mon, 26 Oct 2026 12:27:39 +0100 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf392a-f2d2-0a2a450a0019-d1558031c98b-3 for ; Mon, 26 Oct 2026 12:27:39 +0100 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a20bde60a0so23829615e9.3 for ; Mon, 26 Oct 2026 04:27: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-48e3ecd8c05sm20166262f8f.49.2026.10.26.04.27.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:27: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=1793014058; x=1793618858; 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=NIke+zQbhnjT6EriiY1LasI+Y32faj088B2DokbT1lg=; b=BmctXon3/L6wfnMGd/tX/oVl/gHJQSo0GgaqOvgulS7Ck3sN/qzPOumLfRWk1xkKtu ttgKSHWdYVqKto6p0ejYaMm0ORLzd5h8kUHTOskCZVWJEFDggbsWTSK2E0z13UXYiKWM QxcSMUvV1C6hLI24Ytj2D8MhTDlhkLoTGnjSXqycbSpEmy8ok1tMh7U43LE8VhpZbIty 8MWRL6pIS3PO7dwdZArpebfUmVkclUDzmoWA76YeRy4qQq3ECz1ayGzr/19JYYA7iNdp IKiJiUJGaqwjfpjrBf8v2pgQgLI9G8cutAeAsgvmejOLYQlltaInodajTf/T+E7HLTyq NvEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793014058; x=1793618858; 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=NIke+zQbhnjT6EriiY1LasI+Y32faj088B2DokbT1lg=; b=B1BFlFZJFRKHIctbMewXA8sGbyq9Jmp20W0z6eAPBuMpiVxjf5RdXhwQJn5/uvA13+ JIThz18J24sFi1CEMoJ2AUYTkSpB4/U4r+CXnEzul0xrmd0S5fRxqFxaxof5iFbgXBdW NlOhOBhwM0QVsyQu9gSKiTMV/r6qBPGi3+AgouMXcamb0p2l6Es9jVR/bE2riPOGzLKM LK/j+o8Lxstjmy6w2hoorcm9Z7KrKWC5NTIrQIOwpHKjw4m4OzDG7w3ttprCv8cLY901 UXRvIHjcOn7gdH4Qw7pod6Jo6VLB3ctM02BBuwcL16NVcAHTwGbv+4/2HSaxBbetnYnU psRA== X-Forwarded-Encrypted: i=1; AKwUvBw/YSSB7R8Wj7HkcR0uU9xRnaQgAvjNfxiqt7+5rJeBbozyMXvhy/wKwTcIJyIGBMrcKVffS9zLojQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYIuwuyaGZYD4J25OLz7Uvh0xpsl+mYVI0TIMnezkHYtf3HX+kKT I3tuWzDLENxJEaHd2rFahHVCCOIG54Z1iwjSQ5SvYeQjJvbgxFGwtVj+zzZjmhvgDQ== X-Gm-Gg: AYBFou3GtTmrQ8JOHueQvbjMtclcpNzGzlxXtpI1DRa3mmKilt3ii0yst4aY8V3L61y uxPEuf7LMHheWN3r4Yo4WhRQKJredwCAeEC1To/bVIcYy2Ea7xaABijtyqw6dszET8zpuZomjri J2dSFJbj7qH57k4m0+5aYGwZKQFS5JtcaR3R48DRoornyz0OXbTSiI71Px9qlG2C6r5tymuQI6e tQ1eDlEo5tyh5c1mJDUjYxLEHHLHQUAbdOzeDjjIhszgrhDUGbDz3Tifn7tp70TWX5riksGjoVP ZXHk/dk1CFPKzMMfMBgnVHEo9pzYjSpfBxTSvZ2+dJdgVan+qQno8OsVcaQn7CK8T7CcZvcGAxY BiG2o8t7FktfjnExF1/axYnpfdVc68H/b1BgoZnvrVS2R0+2qY67O9VMSrvXrIpYm1yGMw3tr6E k/kvrgphWsvda7tmT/1klSocbkNXsekRfuFAy7UTQf/usgKZGD3On1tfomraFnRLv+VM8aoOkyY +BrTHUJ4KFxcuG7rMtW3ebZqjfsaAURZuloZqZA8OHruEYitSf99bBQwEyoRycvigCHEjHW+Sgk RDq+d+TxPHLD6YsXl+toqUmVUYHAPKCGVy3ihf3WH+ZO X-Received: by 2002:a05:600c:a06:b0:4a2:40:7f35 with SMTP id 5b1f17b1804b1-4a35acaaacfmr119777995e9.31.1793014058506; Mon, 26 Oct 2026 04:27:38 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 12:27:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/nestedsvm: remove dead code for shadow-paging L1 hosts 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: <20261020030509.308211-1-chunjie.zhu@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: <20261020030509.308211-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793014059-51EC2CFC-AFD55368/10/78276251493 X-purgate-type: spam X-purgate-size: 2699 On 20.10.2026 05:05, chunjie.zhu@citrix.com wrote: > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -304,21 +304,12 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) > /* 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) ) > - { > - /* host nested paging + guest shadow paging. */ > - /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ > - } > else > { > - /* host shadow paging + guest shadow paging. */ > - > - /* Reset MMU context -- XXX (hostrestore) not yet working*/ > - if ( !pagetable_is_null(v->arch.guest_table) ) > - put_page(pagetable_get_page(v->arch.guest_table)); > - v->arch.guest_table = pagetable_null(); > - /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ > + /* host shadow paging + guest shadow paging cannot happen */ > + BUG_ON(paging_mode_shadow(v->domain)); How's "guest shadow paging" relevant here; the BUG_ON() solely depends on "host", doesn't it? IOW I think the comment wants wording differently. Also, nit: Please correct comment style while touching comments. Furthermore: Why would the check be relevant only on the "else" path? It could equally well live ahead of it, with the comments in if() and "else" then talking of just the guest mode. (All comments apply elsewhere as well.) > @@ -1341,12 +1319,14 @@ nestedsvm_check_intercepts(struct vcpu *v, struct cpu_user_regs *regs, > /* l2 guest intercepts #PF unnecessarily */ > return NESTEDHVM_VMEXIT_INJECT; > } > - if ( !paging_mode_hap(v->domain) ) > - /* host shadow paging + guest shadow paging */ > - return NESTEDHVM_VMEXIT_HOST; > + else > + { > + /* host shadow paging + guest shadow paging cannot happen */ > + BUG_ON(!paging_mode_hap(v->domain)); > > - /* host nested paging + guest shadow paging */ > - return NESTEDHVM_VMEXIT_INJECT; > + /* host nested paging + guest shadow paging */ > + return NESTEDHVM_VMEXIT_INJECT; > + } > case VMEXIT_VMMCALL: > /* Always let the guest handle VMMCALL/VMCALL */ > return NESTEDHVM_VMEXIT_INJECT; This results in (apparently) un-annotated fall-through. As both if() and "else" now return NESTEDHVM_VMEXIT_INJECT, those return-s want folding. Then also please add a blank line between return and next case. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:42:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:42:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461152.1672113 (Exim 4.92) (envelope-from ) id 1xLJ6H-0006Rz-CY; Mon, 26 Oct 2026 11:42:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461152.1672113; Mon, 26 Oct 2026 11:42: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 1xLJ6H-0006Rs-87; Mon, 26 Oct 2026 11:42:49 +0000 Received: by outflank-mailman (input) for mailman id 1461152; Mon, 26 Oct 2026 11:42:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLJ6F-0006Rm-Td for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:42:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJ6F-002y8W-AV for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:42:47 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf3ca9-8faa-0a2a0a5109dd-0a2a4508ca28-32 for ; Mon, 26 Oct 2026 12:42:47 +0100 Received: from [52.101.48.39] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf3cb5-f659-0a2a45080019-34653027c449-3 for ; Mon, 26 Oct 2026 12:42:46 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB6598.namprd03.prod.outlook.com (2603:10b6:a03:38a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 11:42:42 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 11:42: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=sW7fkIPRyvszBsgYAJJoiLiXx30Jo//QbG2ibJ68RoUToum2rvrBMbH1dqpY1Di9K6PM7RHz5UuI7CJJZLXoFE/0kCWoXwiGqgPSehVxpGxwm+1uXF4FKdLwXGAOLeQsy02/N0fYdoOaQrqnUIE0ZnGpNGa9RpkfuHuJI9C66Ui3y+gcyibWxKCYzYt2q+m4ZqDLXj2oswWWVtMWDxOYUOie3RYyi2asT1FJjJW+yhISD3nEib8s8zN0Xr/zDqm6OtjxBpqNB0vE5Fm3k1pZSleoOTc7q4I3sCFDdsGph1Awh8/JKH05rAJhLSCJ6jaoSYeseLFxRjzCf6+czgXekQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FukvoVM4ETQ9fcfHekUbRmCsHm3zWnmvZr0oaIU+IKE=; b=b98Wz+JYtJMxy10qsGunVaUPiz7dGeacOcq6yRpzbqAX09duCSAyaoNlWtvAbdGu/agVMxpuhnHKqwu3FY9a73K+XY9jH6MbobBDUf2dtG1Iuuf+oazs582LGHBrkL2nWTxUwGvDPMwZPHKQhU93yYOiJOaOWqwVctXf3cwX7zk5XTRWHZPnutC8FO5I7mfSkkzo5AHdm7K8qk2qDG47sA6ZQvrGNKEYaHVJtNmIrxiQwrAlWg7YcrauW5v7M/CGxF2W/VX0DaHvVQvgDxoPgFG3Gc9kGIaaxBUSVxDU6mH3uktizaDy+E6/V0sIQOrQUJF674nGXIp3/W0HUnLu7Q== 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=FukvoVM4ETQ9fcfHekUbRmCsHm3zWnmvZr0oaIU+IKE=; b=y9/hJRXHvpDXqv8nyhk1Hq/UYkOVwu3iuSj92xBS0MXdQ5qPWC2PltHmp7m6sVgWcfRQGEG1zE7NOJlelzlcadAqCfNYOYO0AirZXmfab+rtfLAKsm13bk/9ARjqWtQ9QdzdeYsCo5LyZBGCwCD6HPh3tSdaJz9/vkPiVGfT73A= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <97d772f1-322f-43f6-a793-fdbba16c7f04@citrix.com> Date: Mon, 26 Oct 2026 11:42:37 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , roger@xenproject.org, ross.lagerwall@citrix.com, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, anthony.perard@vates.tech, jbeulich@suse.com, teddy.astie@vates.tech Subject: Re: [RFC 5/5] xen/x86: livepatch: enable attaching callbacks To: Ryo Takakura , xen-devel@lists.xenproject.org References: <20261023044809.162759-1-takakura@valinux.co.jp> <20261023045808.165276-1-takakura@valinux.co.jp> 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: <20261023045808.165276-1-takakura@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0608.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:314::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_|SJ0PR03MB6598:EE_ X-MS-Office365-Filtering-Correlation-Id: 3796448b-2cca-4e64-08a0-08df33563e55 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|23010399003|366016|1800799024|4143699003|11063799006|56012099006|261021130227099003|261021133027099003|261021121427099003|261021123027099003|261022105027099003|261022115727099003|261021135927099003|261022113327099003|261022075727099003|261009223027099003|260925021311599003|260925021911599003|260925022911599003|10067099003|18002099003|22082099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: AR3xJEjv0zGvWOA+by6aPIFRlVCPyHeifvkVDNNxbgddGtiiqWUqqXWsnLUoHaR/PUhd7ilvDbZwczDcEcFzt9DaPI4YqJZoosTVQuxaGLfP4KEKiXRxXI75cIvjKtzSo4liD7/UoTqXEvB0SqAE8Giu9WqD3V9ymCZ2zSnyirTWUQBXDIUCIRdUXNMfGX6efnw1HeZKqzHoNtIcC6acXWi7DA7mLYgqTx/ncA9seN1fKVJjTs3XjxhR3ZZFWRQYMK/Slx0l22MfkHjU4/1NhlIDMb0NDLoEXYAYtUyC96qzdKgs6pSOEQe3D6wgC3pQr3lMaQVTjT/6hsbfiG5lnswuDTGZ3e7QXm+8geLpXGyax/irBdQFh5Xu0QUaD/F+Ehc+qr97P2WNsTSG1Sw2hUZ37UylFsIq/6EANvyCFTomAv0N0cbJaB7L7brlIGQOfbtBudnig/S1nljnq7uI8RngErKgiBCsiQuso4fM25jN7Zn5EEd7lW1XhEAzh9HACX2G5VQUCX8DfjZXE0BI2VmpglYjuENsrwM9XVIVDqUYpL2TYhYoK0wlEKJHU1NZWJtq6zTxYKmBPIwgMN6skc+s+RsZ/2hDPpMw4MqOwn0j6tMNC6OXTZ5GBA1qr3WilMHAnPVZa5FqY7ibDnA/5HVVO+SuqL/i6dfZKHGAk2c= 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)(7416014)(23010399003)(366016)(1800799024)(4143699003)(11063799006)(56012099006)(261021130227099003)(261021133027099003)(261021121427099003)(261021123027099003)(261022105027099003)(261022115727099003)(261021135927099003)(261022113327099003)(261022075727099003)(261009223027099003)(260925021311599003)(260925021911599003)(260925022911599003)(10067099003)(18002099003)(22082099003)(6133799003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RHk1NU1NalkrV1I2WkFZT1d6L1phTnJoaEVGdno0VlNwSmZHQ3MzK0ovZGR3?= =?utf-8?B?R05QVlZBNzNRVG1qbW1FVS94UmdaaFA1WnBkQjM0RHg0cTZoVDk3dEtVRmJ1?= =?utf-8?B?d0h5d21leUUraTZFUDhHNTBtSjQwMm9CdGNYL215dmlrY0tBKzA4TUFEOWtM?= =?utf-8?B?MnpGK0JScGFPY0sxMWJDWnZkOGU2aVdCM29iVEhlZ3FENW03cHlHcU5VS1p1?= =?utf-8?B?RHFnL1E5bDNWUmQ0T0w0ZE5QMEppMnRaV0ozN3l4SzNQZURRRlhkbnY3dzZw?= =?utf-8?B?UXJWTy9ERTVYQVFhR0lXM3EyaVNIbUdQdHk1dEhNVHpjcDZ6cXd2WkN3WVVU?= =?utf-8?B?RXF6MFphZWhGc0VqemU5U0VLOUZMenRDRkVRZEVNZWhsb3dSYkpCU2YyV0JK?= =?utf-8?B?d2hyT1dpVzMrclhzR2dndmxEVGExSXczdDluaE9yUmZoWTBpMjk3YXlOSzdF?= =?utf-8?B?eWI4d0s5UkQ2NG1GSCtLYUMyMDdXdXRQM0ZSRUtiY2xuNFN2Z1hEYWVqR1FL?= =?utf-8?B?OXNJSS9DTkwxYTNFNi9HRndWbXhKVnpUL3ovbGJHRlcxMnRXRG1TQ085ZFl2?= =?utf-8?B?b0ZPS1RWNHJBSTFqa2lHRFZlY1I2WG9GaXloenk5OGJYU0laQlJjMGY1U29z?= =?utf-8?B?YWZVOWxrcWhCSGszNDJqajZvSTRna1pNaWNEOGxaSGV6SVhZTFl6elBiZnRB?= =?utf-8?B?WWdxWDY3V1lwWmVRU01FbjdyUXBvTnhONjVzL3UxNmxKUlk4M2w3dnNjbStv?= =?utf-8?B?Z2l4ZG9vVHd0Z2dNVndITmsvZCtUd0hVTnJjRm9lU0R1bGZma2ZxTC9hcXo2?= =?utf-8?B?YmFKeU4zbXgycFB3cmgrVVFoWGZ3Y0Q2MDVyc1VXNHpRS00rVE5ZNHZ3ME1a?= =?utf-8?B?Z0djNkhpUEdockRIVzFrdXJ0NDlKMmN2WXpnU1RzNGlGc3ZCckhRWE5xWnpS?= =?utf-8?B?ZkxBWmEwRkNsNXhOcHNtMklzNFZRNXdTc01leGxUSVNOSStzcGpFT0hmdFJo?= =?utf-8?B?WSs3QlZYYUFNazNVRmZRTG1HbGJoR3RTR29DSWlLV0JoZi80QjF0RHI2VkUv?= =?utf-8?B?RTBqT3BnM1ptVXJsbjNkNml5S2dHN3pXSnBtOGhLMTIrcUxvRHFRSEFKWmg1?= =?utf-8?B?Qm1lMERodGthektIK0JTaGZDZmNKOXYzUU9aZVRQeTU0ZzN5WDBzVVNKQTRl?= =?utf-8?B?ZkxwOVBrdDh2V29KckJUR2VnNjY4clZ2Q240SEhpb1hZdVFKZlhqaTBtSE43?= =?utf-8?B?MEMzZWtCWlMzSnVFem9kSlpxNVBaOHJVSjBzZ3N5RnVhUVhiR21EMjJMY3Jo?= =?utf-8?B?QWl3WFVURHpGWUlJZXphSDJyRXY5WUpBQnc2L3I2VHc0SDladXdIZ3FaVnhX?= =?utf-8?B?UGYyaW9jRlQvY0lGajdza2ZHS1JVbmJMOFpuUVFaYVhoNElKMmpvYmJCY0Vm?= =?utf-8?B?SUNLbGc2QStyK0JoM3B5WnkrL2RndVlZSXFVbnA2U3FFUDZlamlqbEMrQjIw?= =?utf-8?B?ZDNTdXc5SVlHeDBYRjBaWFlWbHRVRHhBbU03RU5kZ2NWWTlPL216ZFRRVEVD?= =?utf-8?B?WGtTcmhLVWZ3ODE2cmNHSEJPOTZaRHZ2bHhZMXVrVzFaWGQ1a3pjYmh2T2FH?= =?utf-8?B?TExFSVJ6MFM4UEZKR0E0WE5XemdpZUdUckVHeFpQWllNaVJaT0NCUDQ5Y0l6?= =?utf-8?B?U0JQNGJ0VFIxMWJiNzZ3RTR6RWlBQlV0SUdzdklrSTlhRUlaVlNVWDNzVFBO?= =?utf-8?B?VGpqdUE4Zi84Zjk4eXkxSWcvZTZxWlNrbUxiMGJiL0FzZFdXakFGa2dyR0g2?= =?utf-8?B?ZTVyWlFDQy9NNzhkTnNNUHBESytrL2FJcTRLUlFLckcrRXRHNFp0aXVMOUFW?= =?utf-8?B?dzVNNGZBYzY1MnEyYjVjYjVueWNDOGs1VS9iUDFRTmE5V28xVGcwTXhKQkd0?= =?utf-8?B?UlJDc0hhYjR6R05ScGdiK3owdSsrdDA5Z0dIRnlkaVJRRTVxSWtBUXl5eXZG?= =?utf-8?B?WWZYZWhHdnNhS3Z4d1FFQmhmemhIaTYwenVJZ1d6S3VDZ0pscEVDS1k0NVh6?= =?utf-8?B?b1M4OWh2WlAvdUQ5U2VneCtUM2xxbUUvUXV1aFF3eXNPTTRxd0FCaHd3NVgw?= =?utf-8?B?ZmRzRzhsNG9oRmxIdDBrN0tKMEhZNkhmRFNMNE85Unl1aXMzUS9IV1FETEM2?= =?utf-8?B?dVc2d2FocUJrYTR0VTFMU3pTalV2M2huWmp5R3FaamJxa0x0ZFA1SlNZN2tZ?= =?utf-8?B?eDIwelpQWFlybDZVczJXSE9jTHNkdGszUTJMSzNMWGVIS1BPUGI1dDNtd3lO?= =?utf-8?B?WkpSQnBMYjgvbHJ3VzRWTEdJY3ovVXhRWm1jUmRmaUcwbVNLWkRGdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3796448b-2cca-4e64-08a0-08df33563e55 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 11:42:41.7150 (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: 5hOItfT0t++zAYdNDDmYkzG/inSDFhxJjIbEild4Q5PJmcAxG4V1QrRFfF+Dtf7a5EJJ2hdbxTYfSNKaouXCIF1Ykb9dFVnFUvKvKNvdUD4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6598 X-purgate-ID: tlsNG-c1860d/1793014967-CD94A87B-1F5DB433/0/0 X-purgate-type: clean X-purgate-size: 5085 On 23/10/2026 5:58 am, Ryo Takakura wrote: > diff --git a/xen/arch/x86/livepatch-asm.S b/xen/arch/x86/livepatch-asm.S > new file mode 100644 > index 0000000000..005765b476 > --- /dev/null > +++ b/xen/arch/x86/livepatch-asm.S > @@ -0,0 +1,60 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include > + > + .text > + You need ".file __FILE__" too.  IIRC this is a workaround for a binutils bug. > +/* > + * xen/arch/x86/livepatch-asm.S > + * > + * Trampoline for livepatch tracer. > + * > + * If livepatch tracer is enabled, function entries are placed > + * with five NOPs. arch_livepatch_apply_trace() will be livepatching > + * those NOPs to: > + * > + * CALL xen_livepatch_trace_caller > + * > + * 0(%rsp): traced function + 5 > + * 8(%rsp): return address to the traced function's caller Somewhere in this comment needs to say that all GPRs need preserving. Except...  Looking at arch_generic_hweightl(), my notes about __attribute__((no_caller_saved_registers)) say GCC >= 7 and 8 is already a minimum for the (broken) patchable function entry, let alone the fixed one. So I think you don't need an ASM trampoline at all.  I think you can merge xen_livepatch_trace_caller() and xen_livepatch_trace_dispatcher() and just tell the compiler to spill all ABI registers. Also, the xen_ prefixes are redundant.  Just name the function livepatch_trace_caller(). > + */ > +FUNC(xen_livepatch_trace_caller) > + pushq %rbp > + movq %rsp, %rbp > + pushfq > + > + /* Preserve general-purpose registers. */ > + pushq %rax > + pushq %rcx > + pushq %rdx > + pushq %rsi > + pushq %rdi > + pushq %r8 > + pushq %r9 > + pushq %r10 > + pushq %r11 > + > + /* > + * xen_livepatch_trace_dispatcher(ip, parent_ip) > + * > + * ip: Address of the traced function. > + * parent_ip: Address where the traced function was called. > + */ > + movq 8(%rbp), %rdi > + subq $5, %rdi > + movq 16(%rbp), %rsi > + call xen_livepatch_trace_dispatcher > + > + /* Restore the saved state. */ > + popq %r11 > + popq %r10 > + popq %r9 > + popq %r8 > + popq %rdi > + popq %rsi > + popq %rdx > + popq %rcx > + popq %rax > + popfq > + popq %rbp > + ret > +END(xen_livepatch_trace_caller) Just in case there's a problem doing this all in C... No need for pushf or popf at all.  Flags are undefined at function boundaries. Please drop the q suffixes; they're all unnecessary here. The ret needs to be RET for speculative mitigations.  (It's emitted as JMP which will be turned back into a RET on safe system.) > diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c > index 5158e91f7e..1dfcc3e750 100644 > --- a/xen/arch/x86/livepatch.c > +++ b/xen/arch/x86/livepatch.c > @@ -19,6 +19,10 @@ > #include > #include > > +#ifdef CONFIG_X86_PATCHABLE_FUNCTION_ENTRY > +extern void xen_livepatch_trace_caller(void); > +#endif You don't need ifdefary around declarations. > + > static bool has_active_waitqueue(const struct vm_event_domain *ved) > { > /* ved may be xzalloc()'d without INIT_LIST_HEAD() yet. */ > @@ -365,6 +369,35 @@ int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type type) > return modify_xen_mappings(start, start + pages * PAGE_SIZE, flag); > } > > +#ifdef CONFIG_X86_PATCHABLE_FUNCTION_ENTRY > +unsigned long arch_livepatch_trace_entry(unsigned long addr) > +{ > + if ( (is_endbr64((const void *)addr) || is_endbr64_poison((const void *)addr)) ) > + addr += ENDBR64_LEN; > + > + return addr; > +} > + > +void noinline arch_livepatch_apply_trace(const struct livepatch_func *trace) > +{ > + void *site = (void *)arch_livepatch_trace_entry((unsigned long)trace->old_addr); > + const void *new_addr = xen_livepatch_trace_caller; > + uint8_t insn[ARCH_PATCH_INSN_SIZE]; > + int32_t val = new_addr - (site + ARCH_PATCH_INSN_SIZE); > + > + insn[0] = 0xe8; /* CALL rel32. */ > + memcpy(&insn[1], &val, sizeof(val)); > + memcpy(site, insn, sizeof(insn)); > +} Why noinline?  These are out-of-line anyway by being cross-TU, but in a theoretical world where we had working LTO, I don't see any problem with them being inlined. > + > +void noinline arch_livepatch_revert_trace(const struct livepatch_func *trace) > +{ > + void *site = (void *)arch_livepatch_trace_entry((unsigned long)trace->old_addr); > + > + memset(site, 0x90, ARCH_PATCH_INSN_SIZE); > +} > +#endif This wants to be a 5 byte NOP, not 5x 1-byte NOPs. I see that GCC is still doing the slow thing.  Clang is doing it's code generation more sensibly. Use the add_nops() function. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:45:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:45:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461160.1672121 (Exim 4.92) (envelope-from ) id 1xLJ8m-00078a-Ob; Mon, 26 Oct 2026 11:45:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461160.1672121; Mon, 26 Oct 2026 11:45: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 1xLJ8m-00078T-Ks; Mon, 26 Oct 2026 11:45:24 +0000 Received: by outflank-mailman (input) for mailman id 1461160; Mon, 26 Oct 2026 11:45:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJ8l-00078N-8d for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:45:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJ8k-002yeP-LU for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:45:22 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf3d4a-e002-0a2a0a5209dd-0a2a45068d2a-16 for ; Mon, 26 Oct 2026 12:45:22 +0100 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf3d4f-195a-0a2a45060019-d155dd36e958-3 for ; Mon, 26 Oct 2026 12:45:19 +0100 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48bbb06e746so1461297f8f.3 for ; Mon, 26 Oct 2026 04:45: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-48e3ece5e4asm15746738f8f.59.2026.10.26.04.45.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:45: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: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=1793015119; x=1793619919; 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=32CklU4osfQOyiDdLtBdvFTw2mbtForZG4idG0fPPjk=; b=YUCzyx3IzsOxnx0/g15k8Ag1u7K/Qcp7Y/NjJn/WfCNlJWvMEXNkt0ATQVkeDHcILx boCduWoPOPKRaqvGMeAsVxNoAvfdwts3EH4uBPat/ZXfowT92Vx88xO4dMimgDEyRxGh Ic7camErTOq8V6qGJxHh+YTgn2uU8n9EU0f6yHIgqWpNXPg6OzAlMBwGJnKktD4aGrnL 2SINDaS3sdNv5kN6jr2WKdwRVtJFx+BV/PYwlT0vCLKFAh22XeDej3bl9dgieBf4uofO LCzudjbM3beUDpUcFD7nHDeo8fXLJdWQULnsjS3R7b+lLARAFA96albsOsDeeIFxeuTl xYBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793015119; x=1793619919; 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=32CklU4osfQOyiDdLtBdvFTw2mbtForZG4idG0fPPjk=; b=JuGCxJIMtA501UvKMosnrgwpuBSMmank6LpTidQueClA/JI/zJmJ9tuA5A0ygZz2Rk 4LVuadgCq1/G/uIHACopJ3D26HFJbfyqF+xw2dhsykMz1bBCCWf5/fXcRc/SmMRxKig4 b1Z6ivCiOo44a0AsZBbb5DyGnENLRIzpo8gcl9jMAQ8msGXe6ggVLlZB04IbaUYAToCU P/tfu3CHNCeaqnhxkuNeJkm4MzJhWqDRexZLyl+h85N3GVA2yz28GZ77Bmucpm+M6pwu lf4nPOCk6257e4g44Ey3IG/vA/gkZpul9ANwQyyKhvGgvuJnh/yWuLKV4jieAo6VzT4B Sq6Q== X-Forwarded-Encrypted: i=1; AKwUvBwwl/V1nIFD+Klyl8fh1Xy+RgYFO2bu0cJPmsgcrZOa5/eEgmfxZeAOQTpWrESCXX3Ux5xRFuOnK2E=@lists.xenproject.org X-Gm-Message-State: AFq9FYKTEaaDAkzhAD6+fy/Be/Fb4v6NOaPjAlus3vhzYjx4hknUnso+ W6LMZG0idswqxpzU7cvN/9qraT9jqvKQaHc6l2XM2tgr8OwSUFyxNy8tlArPUe9fpCFB2UUJn+D IyBb4xA== X-Gm-Gg: AYBFou15tLS3AhORi58c4fR55rwHAt+78N7egkenNws7xaA+zth6RjeLnhOmis65Lfc GA79bZ8YpHBtBH+VrpiLOFZF2crg/K2/RWI2Aj8gMx74nq8QeUK23U63mwlz3FRtgsevs8SF0IN dKeHZ4Ka3oRB7awBzj/hOOKDEG/Zzta9CYG52lnvTzsVqd0mz9OWkePROyDKtTpLbL/wObZwMP4 1ka45TgxbYlxZzavFcYPUnnqJ6hHISHx0pjcaHc9Xz4FU+J1MVCNPURTRTJDF1V4lWVXfGE0LL/ UZusVAZQyDBgpmmnJB9+6xr1PESnyPZ+Al4p28tWg654fKJGK7OEoJEFvposiREIhE0hQ+eJpsQ l6mLYENxlnJhyd8V8SWAMrSTrhKZ0xL7T7/8W5hnudd/1wdpuVNDRMWHAuMQWn3rK2kIvUx1i6c w4AGD0F0TJCMNminRyP17BzkicuRI6qyw3DNOMiL83bnI4s5Bcf2KSBX9VBMq3v2+dMgy2j5Z39 87qrqLeJl7jKb30YGVB3B+V29L7xAsugl9rUawJHoJlwnf73ROOaFl/ME23nfylhjVKPJr21LHW zxxyTzMUO7Byyc0+Tvt+sACYRioTvIrYUMjLuEpiCECt X-Received: by 2002:a05:6000:4809:b0:48b:11df:c496 with SMTP id ffacd0b85a97d-48e3eb8ecb2mr12085181f8f.28.1793015119054; Mon, 26 Oct 2026 04:45:19 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 12:45:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/altp2m: pause the vCPU before taking the altp2m list lock To: lluisbessasanz References: <20261020072806.465449-1-lluisbessasanz@proton.me> Content-Language: en-US Cc: evilbootloader@proton.me, xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Tamas K Lengyel 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: <20261020072806.465449-1-lluisbessasanz@proton.me> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1793015119-FEC7777B-224265F8/10/78276251493 X-purgate-type: spam X-purgate-size: 3536 On 20.10.2026 09:28, lluisbessasanz wrote: > From: Lluís Bessa > > p2m_switch_vcpu_altp2m_by_id() takes the altp2m list lock and then > updates the vCPU's EPTP. For a vCPU other than current, > vmx_vcpu_update_eptp() -> vmx_vmcs_enter() pauses it and waits in > vcpu_sleep_sync() until it is off its pCPU, with the lock still held. > > A vCPU on its way off its pCPU may need the p2m lock: context_switch() > updates its runstate area, which for an area registered by guest virtual > address (VCPUOP_register_runstate_memory_area, as Linux does) is a copy > to guest memory and needs a p2m lookup. A vCPU handling a log-dirty > write fault holds the host p2m lock in p2m_change_type_one() and waits > for the altp2m list lock in p2m_altp2m_propagate_change(). That closes > a cycle: > > dom0 vCPU, vm_event_resume() -> p2m_altp2m_check(): > holds the altp2m list lock, waits for vCPU X to be descheduled > vCPU X, context_switch() -> update_runstate_area(): > waits for the host p2m lock > vCPU Y, hvm_hap_nested_page_fault() -> p2m_change_type_one(): > holds the host p2m lock, waits for the altp2m list lock > > A vm_event consumer switching views in its responses > (VM_EVENT_FLAG_ALTERNATE_P2M) hits it with a Linux HVM guest while QEMU > tracks dirty VRAM for a VNC client. The dom0 vCPUs involved spin in Xen > and stop handling interrupts, and dom0 hangs. > > Pause the vCPU before taking the lock, like > p2m_switch_domain_altp2m_by_id() does with domain_pause_except_self(). > The pause in vmx_vmcs_enter() then finds the vCPU already descheduled. > Only vm_event_resume() switches another vCPU's view, the other callers > switch current and are unaffected. > > Signed-off-by: Lluís Bessa > Co-Authored-By: Claude Opus 5.5 The code change itself looks good to me, but as to the tags: The latter one wants to be Assisted-by: and move ahead of your S-o-b (tags want to be chronologically ordered). And then there's the issue of sender and (last) S-o-b not agreeing. Yes, the "real" names are pretty similar, yet even if they were identical that still wouldn't mean it's one and the same person. Is there a reason you can't use an S-o-b matching the email address you send from? You also would have wanted to Cc maintainers plus perhaps Tamas. Added now, and hence retaining full patch contents below. Jan > --- a/xen/arch/x86/mm/altp2m.c > +++ b/xen/arch/x86/mm/altp2m.c > @@ -220,6 +220,17 @@ bool p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int idx) > if ( idx >= d->nr_altp2m ) > return rc; > > + /* > + * Updating another vCPU's EPTP (vmx_vmcs_enter()) waits until that vCPU > + * is off its pCPU. Wait for it before taking the altp2m list lock: the > + * vCPU may need the p2m lock to get off its pCPU (to update its runstate > + * area in guest memory), while a vCPU handling a log-dirty fault holds the > + * p2m lock and waits for the altp2m list lock in > + * p2m_altp2m_propagate_change(). > + */ > + if ( v != current ) > + vcpu_pause(v); > + > altp2m_list_lock(d); > > if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) ) > @@ -230,6 +241,10 @@ bool p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int idx) > } > > altp2m_list_unlock(d); > + > + if ( v != current ) > + vcpu_unpause(v); > + > return rc; > } > From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:52:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:52:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461170.1672130 (Exim 4.92) (envelope-from ) id 1xLJFP-0000w9-H1; Mon, 26 Oct 2026 11:52:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461170.1672130; Mon, 26 Oct 2026 11:52: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 1xLJFP-0000w0-Di; Mon, 26 Oct 2026 11:52:15 +0000 Received: by outflank-mailman (input) for mailman id 1461170; Mon, 26 Oct 2026 11:52:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJFO-0000vu-5D for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:52:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJFN-002zsk-Hl for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:52:13 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf3ee7-bab6-0a2a0a5309dd-0a2a4501b7d2-8 for ; Mon, 26 Oct 2026 12:52:09 +0100 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 6adf3ee8-5984-0a2a45010019-d155dd2fe4bf-3 for ; Mon, 26 Oct 2026 12:52:09 +0100 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48df54150dfso1547662f8f.0 for ; Mon, 26 Oct 2026 04:52: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 5b1f17b1804b1-4a35a2c0458sm188873725e9.11.2026.10.26.04.52.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:52: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=1793015528; x=1793620328; 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=W3lWXWhlqI6TLAxn555Tg9OnJIpaUZQVPl1obFcjvBU=; b=IrO+cZ5RiXHFXcibN6wYlzyjaOqe3KBvcuCfYTYYgXyLHwi4y1a/vTF1RLvJAQgBGF FJDHyHD7eqb8xSLrHOutwG8986ibVN6cy59ubKxRwA17RGmb17nGrM2riw7iPmWLVGAJ 0H7ynPnqRy5ATzqO4rbgnSG0v6jNv2ex+S0k3jU83SOQElUdRwsrlb/SuvTDQmLZAJRF OATqlnNxIzwvLn/aUNm5v4ma0NimgAU0wV8DIVv3G8qPvEMeye6ky9DsVQcK93a0gR/m KrDr4DmYufs13IHwTfawaR90ZexJflM6yTAQNen0PAyEubXXqQCx7l9pkhrj3Eab24s1 30xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793015528; x=1793620328; 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=W3lWXWhlqI6TLAxn555Tg9OnJIpaUZQVPl1obFcjvBU=; b=dpGUu9V0SjFDyV2gIPrH9XnG0qPILjRj/i51YtzteKTjTnyFillzv23sm/HJeJxhcr VcN3t4XZJjVyfRM2t3MZzrXj34IOJWEkBqWNUzsVjGCQP14pqoJqnwB9PBRPBwOFDYc1 CSI7vauxU2v/DI7dkv2R/zCf5Yqlqc99AIdWxtuvvjiZDcZW3B5sHXfbysjDhLnXtSzA w52xzd8qFu8NEeUJy8SWzAuq92PoyfPB3iGTAGeAhAlUWVl/nAa2eUNbcGQDTE43GrY6 uC3AsIX4AIVWcfl9iXYNSaWowgAX3BgVEhyBt1Dpm6W0eh/Zt2dD5lsixCZSXCk78IbG ky1g== X-Forwarded-Encrypted: i=1; AKwUvBz8RkSKy7Elvxy1iai6sWqUj3nJNU26wIrIe6uuLi1c+/7D89+d6ItKwbKFIVZrbTocTd5Jt0dJVlU=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ8emJoIj9fEBzBvzs6wHVWl+/qatpIxZyWGpqcl2MPiA3VJNoO eFtq+WCWlaaBQFI3aj4ugMVDP7LtNOLBOXq1ZbSwO2OMVgh5q0SMF1x3mlBTSzmDBA== X-Gm-Gg: AYBFou2DQbL0u4hqVisUKJzgzd7n8CBAGILpdOXdvmAQPLZR6Qz9fpVffonfvB3/LpY 71im9EX8u3eS2Xfa6H1WvFrPaSoXHLU2lylftlgPunidK4ZB/EQ9C7yBUJzkMWRKaPKfDjr1QlU V0etcAKgeNIoj+dLBBlhDRW5T4zPKTwpGyX5cJ3w/tgLxcBLjqUDOpLfod7gxRnSMqXhonYMRRl iBVg9V9zU+G9nH0a1zBKUGF8cjYBjhvdh4lnjUIl6GS989gWz3fy98hBEA3HkpfvMGstZydFtJj EqJ+VTKdQ0xLywvYVIty6t49vAOz61tTcAdjWfU5OJv3YRnUJk9lltR531coQqdboHhJeOferxO jBOslsdqmu6bCbDypaNmAVNt8ahqfOOhBA8PDw+3QRLcG/V4HiPCP9vvw7LGArEdbMo3tCaiCXY qOx2SalM/6gSmDYaeModwLpMhuNJW34bu84B3OmqiuHonAeXXQsh+boMI0V8dZr6iyjtNA4HjmV hDetRrT1iknLXlhppORxc7DxZfYqXd/PPB3zkzrNc9uMjkNSwjMT4XKinmlSk0xpbR7615lgWOa KCl1OEkUqoFHkSxHhsgFc8oLrhbI/eKolMADwNVmeMDy X-Received: by 2002:a05:600c:1c0b:b0:4a1:d10c:7170 with SMTP id 5b1f17b1804b1-4a35acbf94amr164558055e9.31.1793015528555; Mon, 26 Oct 2026 04:52:08 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 12:52:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/np2m: flush the np2m on an SVM nested TLB flush To: Stephen Cheng Cc: Ross Lagerwall , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <7757cb6d-78d2-4d73-bfee-f9d5db8f15a1@citrix.com> <20261021021028.123867-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: <20261021021028.123867-1-stephen.cheng@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1793015529-C4B45757-6E2FBA08/10/78276251493 X-purgate-type: spam X-purgate-size: 1512 On 21.10.2026 04:10, Stephen Cheng wrote: > On SVM, L1 flushes what is cached from its nested page tables by setting > TLB_CONTROL or using a new ASID on VMRUN. Either sets nv_flushp2m, which > p2m_get_nestedp2m_locked() handles by only dropping nv_p2m. Since np2ms > are shared between vCPUs, the lookup then finds the np2m for the same > N_CR3 and reuses it as is, so L2 keeps the mappings from before L1 changed > its NPT. > > The obvious fix, flushing nv_p2m (the np2m this vCPU used last) before > dropping it, is not enough. It covers a vCPU re-entering the same N_CR3, > but not one entering an N_CR3 whose np2m another vCPU filled: on its > first VMRUN (nv_p2m is NULL), with an ASID new to it, or when switching > N_CR3. > > Instead, flush the np2m for the incoming N_CR3 before reusing it, as > nested VMX does via np2m_flush_base() on INVEPT. > > Fixes: 6df4b481b0c5 ("x86/np2m: implement sharing of np2m between vCPUs") > Signed-off-by: Stephen Cheng > Assisted-by: Claude:claude-opus-5-5 > Reviewed-by: Ross Lagerwall Tags want ordering differently: For one, it wasn't Ross who indicated that he used Claude for the review. See docs/process/sending-patched.pandoc. And then tags want sorting chronologically anyway: You can't possibly sign-off on a patch before having finished making use of AI assistance. With that adjusted (can be done while committing): Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 11:57:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 11:57:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461175.1672140 (Exim 4.92) (envelope-from ) id 1xLJK6-0001eg-2B; Mon, 26 Oct 2026 11:57:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461175.1672140; Mon, 26 Oct 2026 11:57: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 1xLJK5-0001eZ-UX; Mon, 26 Oct 2026 11:57:05 +0000 Received: by outflank-mailman (input) for mailman id 1461175; Mon, 26 Oct 2026 11:57:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJK4-0001eT-Tx for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 11:57:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJK1-00D3sv-RX for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:57:01 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf3ff4-bab6-0a2a0a5309dd-0a2a4505dee0-42 for ; Mon, 26 Oct 2026 12:56:58 +0100 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 6adf400a-4cb1-0a2a45050019-d155802eb9f8-3 for ; Mon, 26 Oct 2026 12:56:58 +0100 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a208d93758so33589475e9.3 for ; Mon, 26 Oct 2026 04:56: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-4a35a0aa097sm209436265e9.3.2026.10.26.04.56.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 04:56: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=1793015818; x=1793620618; 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=CnLmwNwP/O4q7mGg8UAOdyNk5IZGlVFRmJBWjhG0gWk=; b=bWot1zx/OCBCR2W+QCNn1B2qBByGCzX9eAo2sNU6jl/dc45OnpcLCgUuq+paC/MKgx 9onK0CmcMg44hXSdilgkDPeqJVFnMqXs+Y7Bji/zADSrZ5lU3y0VQbKjperCnbBuK1eC wL29o4JCnIwu+I8Ya523KROrKsrmq62iiBUWHsTZTSHdZ+m2yrz+osKP4jAlBH3qaZuy ReqPclrXw4ZZglts7op8B5IR1iuFxEb4cVe12c8IxzuWm+HCRShVBBGsxmRU/DroY1rK +Hf94Q6kwFn/d/Wx5NvfMftlRfABbKsifxBKGXhBqEZTvz9+8W8LSIHFFjkF1ky5e6cw tzAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793015818; x=1793620618; 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=CnLmwNwP/O4q7mGg8UAOdyNk5IZGlVFRmJBWjhG0gWk=; b=LpV91PqefAW9MQT29pOdkkAHH45how7aoUSmjOqE4ghoZ7udgY5O06Xhslhwa/Ckqz wPaLPOWcllJ5Kpz+mlis0LU6pMVJsqmfeUkHJlF7wRUwtfSp6JEi0DEe62vru9YJW9hJ uo5bE884jCIG0YzdvK8Sh/xvzY2Yx9il0fFjOuIRAphIMQiAdBpCfWE6Qk4mSqU2omF7 PZZRoWRPZwjFKuO1do93VJc+CJiCNY9kb6z/i42/fTu8L1HCVLFk0+YPg9FppgULEme5 LoAcIilp6wFb6r2gcbm3pupHdfXwc2iS5XYvLsefU4KJPkeGT1twvYWqtZ930gMxUvya cZfA== X-Forwarded-Encrypted: i=1; AKwUvByrbWa5+1F2bTvwHo5lX/9pqzEzB+FmYuHgJlBLdNqB343pA9N376XOti3i1STvzy2sbVNl8HtUyxY=@lists.xenproject.org X-Gm-Message-State: AFq9FYLFwrIwZnLkIX+up70pMZkPuiPkCpX59rn1MgXkWp1jEtl0hU7z EeJWk+41h74NsSpvtmbXb4oju2SO92HwhJhvOnsmNTKc9iGZ7ECKxexgeZBt7wNlHA== X-Gm-Gg: AYBFou0PlAE9E0H0t75CHSt5J413LdRy5At4l0pUBHPaY13aL+ABp6JdRRDNQ4Z6gDW NhOhBGiCXnOectwi5nbpTTrkWmOTod5iGXLWE41Az1JbTByCd8KOXOFZ5Rh78r6JL1L6o6en3dF uYtozLCgLWTIDuLe3cQMQ90Tn2GisFEaKnhghnHpkWSSq+icYlsK87eAJFCrSiXo1Yf94dqFZEw H5DWMpLafyKkEJMLO1UEqZAFBWxfe0+xJSLyUG8cMzbeZKHZuLtkR21XiYmt3vwlEdMEw4OS/0i nA/6v4vGvJ8NV4VOq0//RBXo0j8IAwoWQyItcQHjvxMo/WrBh9/9Y9AvtT3GupBRVOZ7E9zgp9b dzlyW8eu47Irt8zXRw9M+/ISN0Bzt80eze9g3t6G7qad9C4pTBxOmJ5D+cX83eE+SSWBEtdjAJQ DZltZiudyJmsdKSvgS17GJRFekIiEHCOOGRqsVUe36GcfZmrRTNepwdH4asBIVZjTbJPs/QOcAE qjycwNH2iE2UIymk1ODw6AdP7gvo+4BbeQixWh8CO266uNs6wGPgMIDSDiul1WLoJ9CnymaCsI0 SmoyqDA9pq7KotTGmfmJ71zc65WKyGKG8eK484SjxBonQndcPngas0Zcs1TuZRebNw== X-Received: by 2002:a05:600c:19d4:b0:4a3:59c9:a750 with SMTP id 5b1f17b1804b1-4a35ac90dcemr106254855e9.9.1793015818075; Mon, 26 Oct 2026 04:56:58 -0700 (PDT) Message-ID: <00f95d00-3d43-4e85-92e9-0b1cba4f0c4f@suse.com> Date: Mon, 26 Oct 2026 12:56:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 5/5] xen/x86: livepatch: enable attaching callbacks To: Andrew Cooper , Ryo Takakura Cc: roger@xenproject.org, ross.lagerwall@citrix.com, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, anthony.perard@vates.tech, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261023044809.162759-1-takakura@valinux.co.jp> <20261023045808.165276-1-takakura@valinux.co.jp> <97d772f1-322f-43f6-a793-fdbba16c7f04@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: <97d772f1-322f-43f6-a793-fdbba16c7f04@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793015818-F429B2A1-0F197BA6/10/78276251493 X-purgate-type: spam X-purgate-size: 1846 On 26.10.2026 12:42, Andrew Cooper wrote: > On 23/10/2026 5:58 am, Ryo Takakura wrote: >> +FUNC(xen_livepatch_trace_caller) >> + pushq %rbp >> + movq %rsp, %rbp >> + pushfq >> + >> + /* Preserve general-purpose registers. */ >> + pushq %rax >> + pushq %rcx >> + pushq %rdx >> + pushq %rsi >> + pushq %rdi >> + pushq %r8 >> + pushq %r9 >> + pushq %r10 >> + pushq %r11 >> + >> + /* >> + * xen_livepatch_trace_dispatcher(ip, parent_ip) >> + * >> + * ip: Address of the traced function. >> + * parent_ip: Address where the traced function was called. >> + */ >> + movq 8(%rbp), %rdi >> + subq $5, %rdi >> + movq 16(%rbp), %rsi >> + call xen_livepatch_trace_dispatcher >> + >> + /* Restore the saved state. */ >> + popq %r11 >> + popq %r10 >> + popq %r9 >> + popq %r8 >> + popq %rdi >> + popq %rsi >> + popq %rdx >> + popq %rcx >> + popq %rax >> + popfq >> + popq %rbp >> + ret >> +END(xen_livepatch_trace_caller) > > Just in case there's a problem doing this all in C... > > No need for pushf or popf at all.  Flags are undefined at function > boundaries. > > Please drop the q suffixes; they're all unnecessary here. > > The ret needs to be RET for speculative mitigations.  (It's emitted as > JMP which will be turned back into a RET on safe system.) Just for completeness: "will" as in "will eventually"; see my still pending "x86: re-inline RET used in assembly code" (with me doing C side work still pending feedback for that initial, smaller change). Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:15:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:15:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461188.1672148 (Exim 4.92) (envelope-from ) id 1xLJbg-0005u5-Jk; Mon, 26 Oct 2026 12:15:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461188.1672148; Mon, 26 Oct 2026 12: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 1xLJbg-0005ty-GT; Mon, 26 Oct 2026 12:15:16 +0000 Received: by outflank-mailman (input) for mailman id 1461188; Mon, 26 Oct 2026 12:15:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJbe-0005sn-JH for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:15:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJbd-000bdn-Hj for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:15:13 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf444d-bab6-0a2a0a5309dd-0a2a4502a08c-2 for ; Mon, 26 Oct 2026 13:15:10 +0100 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf444e-6ca4-0a2a45020019-d155802aadf2-3 for ; Mon, 26 Oct 2026 13:15:10 +0100 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a2d6cf958bso9669905e9.1 for ; Mon, 26 Oct 2026 05:15: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-4a5ea0df763sm101543055e9.3.2026.10.26.05.15.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05:15: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=1793016910; x=1793621710; 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=LalU7iE11Nk9uJ1lkqiCjCv4odKPqiVHYWjeF26cbIA=; b=WunRt3ss2XhB08VweH7XOhHN9WOlq+fRjrMlTDLJhxT68jVTOh3ovJgozOznX7UaNM TParFHjxV8WudN4PMYLasprfO/T8ymwxTtkwGxoOyVBG4lX1iBRWc3hFlVq95AYSQp24 Nj/j8yvRoTur/ctv9t6pfr/vQoN7UJqa5DC46rdldnfE4WLcriDh8do+sfrvogkxn40t p6kPIW5rM6SvepbDUSqK1P7fs1jN03TTS8Q6vcukshIK3VSR+QNXwSXb9V/xQCzq9zvr A30SdR2JnUIZx5dm4lTFkRStsFhTyTZ0gFycAZSlXQhsjr31FeoeHN8XiOM75nLhgpFI B7mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793016910; x=1793621710; 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=LalU7iE11Nk9uJ1lkqiCjCv4odKPqiVHYWjeF26cbIA=; b=0m2Tuj9Wnx7wo+8lzLH4UBdJrCtmK2Zu3uMvLlCDAr/WtB91nnfR+Y08oyRpBImBol F2S2xXUzSXEPlzbUVMCC3tbqhtxFmCVJvzvgS0m/gF5lOUBuw2jsK4tTEimquoBfxl33 Uz2f7P5OVyI6YKDFZd1dFjT/5rbGGeJSf7z5lr0+Ol9sa0HevpPouYu5H7+SxJL+Wlnr p7yFGGWdJ7JwOTAgUL/U2mPkQcFTR7XHVneAcEvO9yF6Xv8LGu+OQ2oRqHUv30y1efmr ZOyDngng1oqbJunRqF9u0cmzh6vjrDGFGiDeJwQSsmnxIRruFyu8YtWLKtdakOX2w9jf o6Mg== X-Forwarded-Encrypted: i=1; AKwUvByRmED/bMC06JnqF/a9PLlhno9eTsNl+pwkdo5QSr032yPkMD5qswnllJYzTqcLK4JC/5yCafiw12g=@lists.xenproject.org X-Gm-Message-State: AFq9FYK0eohLsiUuGyIwe+F90ySByuQznp1Z3plQWu/q5O6Pg5u6XT1U ppJQGAuearbgPZU4bQhNeDq0lLvJoy22oZ0B1DshmOU6Tm9eT/C5RuL1MoATfvM2Lw== X-Gm-Gg: AYBFou1y7JaCs45dEr6NAvxTKSU3HUeAfCKsufE0uSMqzllTqjNsEtfM+xi3sxh/NzN YQCvfzsgjpGe5zIfGoZ1FcwDWZ1/PW2pMlkrqLRoWy0Njdsv9XxIKRvR4L6l5A0+zG4ZcFClalE 2+XjWK3FyYgJLfWZNesdzt0S0vbPPtC/dy2xKtxSnGkamMs6Q+HtwmlNX/C8AXAebJj3HzwT8ws yW3giClZa1ce7K95QoUhtF0Tv+e52Ztu+ceiDJKC868IWkEZ3T6HAngempfBWpjhn6JfS0Kxx3k QrtB+Ta1NBfSnKsZmP9Ii8WM/deD7xNAtWyKEw3QSJhE+WNFik7sjK221qsy1Kp1rCwU6zt3CTY 2LncTa8yH+Wf5rdyddWhQySAYXHGcinBE7qAKU470athQaBhDAL/7jODp9bB/gL0cJqt9AMQBIM mxJvgOxKsJyN+r4yANlVmaRC5KmpZea17qTJgvmbBa/E/b+U2MchMfIcPLk9byjHnd67rgFFyiH oCMCdViZzeOLJ47a69gS/GPiN87LtcRNt6IE2U+wkPsChI42fvVaYaNpBIXZw9lPuJK/ajspsdd c7/hkyu+0hnbzTyk33Cbl8xCELhiT9062LVaGD7MFpsm X-Received: by 2002:a05:600c:524d:b0:4a3:59c2:b41e with SMTP id 5b1f17b1804b1-4a7444042ecmr15246445e9.4.1793016909457; Mon, 26 Oct 2026 05:15:09 -0700 (PDT) Message-ID: <84fee7e4-ee15-4e56-8db3-f5d2db5ec2e2@suse.com> Date: Mon, 26 Oct 2026 13:15:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/desc: build boot GDT descriptors with a macro To: Furkan Caliskan Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261020135722.45714-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: <20261020135722.45714-1-frn1furkan10@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1793016910-319CB2AC-3275584F/10/78276251493 X-purgate-type: spam X-purgate-size: 3076 On 20.10.2026 15:57, Furkan Caliskan wrote: > The raw 64-bit constants in boot_gdt[] and boot_compat_gdt[] hide what > each descriptor actually is. Replace them with a GDTE() macro, modelled > on Linux's GDT_ENTRY_INIT(), plus named GDTE_FLAGS_* constants and a > GDTE_FLAT() helper for flat segments. > > No functional change. Can this be "upgraded" to "No change in generated code" or some such? Else: Are there changes in generated code? > --- a/xen/arch/x86/desc.c > +++ b/xen/arch/x86/desc.c > @@ -27,32 +27,67 @@ > > #define SEL2GDT(sel) (((sel) >> 3) - FIRST_RESERVED_GDT_ENTRY) > > +/* > + * Expands to a brace-enclosed initializer for seg_desc_t; only use it > + * inside an initializer list. > + * > + * flags: bit layout matches its position in the descriptor's high dword > + * bits 0-3 : type > + * bit 4 : s (0 = system, 1 = code/data) > + * bits 5-6 : dpl > + * bit 7 : p (present) > + * bit 12 : avl > + * bit 13 : l (64-bit code segment) > + * bit 14 : d/b > + * bit 15 : g (granularity: 0 = byte, 1 = 4KiB) > + */ > +#define GDTE(flags, base, limit) \ > + { (((uint64_t)(limit) & 0x0ffffULL) | \ > + (((uint64_t)(base) & 0x0ffffffULL) << 16) | \ > + (((uint64_t)(flags) & 0x0ffULL) << 40) | \ > + (((uint64_t)(limit) & 0xf0000ULL) << 32) | \ > + (((uint64_t)(flags) & 0xf000ULL) << 40) | \ > + (((uint64_t)(base) & 0xff000000ULL) << 32)) } As you only ever use this for GDTs, the macro name here is okay. However, ... > +/* Common flag combinations (same values Linux uses for equivalent segments) */ > +#define GDTE_FLAGS_RING0_CS64 0xa09b /* P DPL0 S code RX A, L, G */ > +#define GDTE_FLAGS_RING0_DS32 0xc093 /* P DPL0 S data RW A, G */ > +#define GDTE_FLAGS_RING1_CS32 0xc0bb /* P DPL1 S code RX A, G */ > +#define GDTE_FLAGS_RING1_DS32 0xc0b3 /* P DPL1 S data RW A, G */ > +#define GDTE_FLAGS_RING3_CS32 0xc0fb /* P DPL3 S code RX A, G */ > +#define GDTE_FLAGS_RING3_DS32 0xc0f3 /* P DPL3 S data RW A, G */ > +#define GDTE_FLAGS_RING3_CS64 0xa0fb /* P DPL3 S code RX A, L, G */ > +#define GDTE_FLAGS_PERCPU 0x0091 /* P DPL0 S data RO A */ > + > +/* Xen maps every flat segment across all of memory. */ > +#define GDTE_FLAT(flags) GDTE(flags, 0, 0xfffff) ... nothing in any of these constants is GDT-specific, and the FLAGS infix isn't very useful there either (albeit I probably also wouldn't outright insist on its dropping). As to the GDTE_FLAGS_* constants' comments: The P and S bits (which are only ever set) are mentioned, while the D/B bit (which varies) isn't. For the constants themselves, there's clearly redundancy with asm/desc.h's _SEGMENT_* constants. Possibly those could be used here, perhaps eliminating the need for those comments. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:17:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:17:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461195.1672158 (Exim 4.92) (envelope-from ) id 1xLJe3-0006Ye-Vk; Mon, 26 Oct 2026 12:17:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461195.1672158; Mon, 26 Oct 2026 12:17: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 1xLJe3-0006YX-Rj; Mon, 26 Oct 2026 12:17:43 +0000 Received: by outflank-mailman (input) for mailman id 1461195; Mon, 26 Oct 2026 12:17:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJe2-0006XM-Es for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:17:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJe1-000c4v-Ni for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:17:41 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf44dc-e002-0a2a0a5209dd-0a2a45079fe6-36 for ; Mon, 26 Oct 2026 13:17:41 +0100 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf44e5-b4ea-0a2a45070019-d1558033e807-3 for ; Mon, 26 Oct 2026 13:17:41 +0100 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-49d05d51553so20053605e9.2 for ; Mon, 26 Oct 2026 05:17: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-4a35a033702sm155233405e9.2.2026.10.26.05.17.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05:17: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=1793017061; x=1793621861; 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=H+W6PeX4GmvRkkb4eOw+rF2gvfiA8AP/aK0Rnf/ufRI=; b=T7ceZ322/Om+bm2iJR/EL/X2oMsMDIDUVIo8MNlfoQu+nF/4nPODRhmuZRhi6zjYIm 0dDYGybAMH70qOVuOYmFqsw6bBdCkgX61FKqaivktS8Tw4WxNpKZAR4OU+PSaI8wDOLr 1+R0uwHH5e0ZMNBJjtoehcay5XWtPXRv++Q+dYraTqWW7vWZ93fsQ4UWOnAngdpTIz0S oWyNI/TkJDoAp4D9b96Yd3C9AZ3P9Mqjn13l0erBfMaxxKRAQRPN2xnES7JfytXkEY0N sw1op9g8IGLheov8VdEisZnswf+r+y8pPN8Nh57myTmUROjPTJDkQUGV9in+zA+oJlOS lX5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793017061; x=1793621861; 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=H+W6PeX4GmvRkkb4eOw+rF2gvfiA8AP/aK0Rnf/ufRI=; b=pF9I38rIhPN6CY2e/MnTd3E0Ory5hLVYBvpU+oI/noc3RNr0Fa8WmQmaYEsOgPKlzb USVnAp8yaH8QWcoRBQswcH/OlBvnPC5+1gLusERhaBM1pTrogeDPuwQL4muQ9VCMPlYS d5nDZAjCILTONzwxpyCwgJBLIvoBF7pnzQXpIJYIQLNxrt/Bd4qd22WzZ+UPdlxAedI3 hh0DtYhm9WUlSP54x1zSNn1ts8uZqpZRb7meVOAU5MggVy55Mxoz/EFwparTJGZiOBy0 IrZ36L9Bdk4+ield79xsoUn89eCNwyxVqSi3CCUuIcc2wsXavjaKmEk73m6IM3xqIpVB vhfQ== X-Forwarded-Encrypted: i=1; AKwUvBy3G4f8V8FMIq4XkenqPLbacp5diwFq8qKrRUiSwZQfXlTXkjtUmG7o4CgAZdOKSkiW1G77Dt109/E=@lists.xenproject.org X-Gm-Message-State: AFq9FYL7occENmfgYF2vLs8hkR6kZU4gZvjOtG7VZc6AL+gpkQsMHXUB K9WKBbxxgGyfTBT6QgnteqSG9ljaV9KLK/1fsLj6abF7nlBB8drdDLI2BrgROMgFYQ== X-Gm-Gg: AYBFou2KajWCx8UreXsAPD4xnoAgHe4I3nlGl8vQBYZHag9UwJRD+Mp5pJOu56Cs30g qcUSiVawhYSlJHpWrFyqEgDZ87OTiV/pIosTlFiPSZBfAPOvBlE8pryTIHE9Ltssrl+cB4l88Np ybBwBidlajbbBtp5gAkTUXCkr2KTBBPd88LVrBAzyUIXbREK18t9b7t+u81QK5/uyveFRfWoONJ CBxuQcO4K6McBw16OA985VMjM3OFIeSqz2Ars9UegYg7zER0wcOHuPNKWSBM357MqkuCJPBjgMf 8irVCc6pzDmzZkkxBXtKV+s7VjN9fu/m9WPbB34lqIiUNFkGdmUFp6ln705zg+hJbafOfCl2x+Q Wp3//mZb6FrPaXlgzNWvpco9xYt8rchVCJjZywCDznn4S/DvvrHfMq0dN4kU6ws+IJ+2i7hxcaF SpyhfmYGJIjJL6U00d+QaXT1wtbYZ6CV1HD4DSR/tYeaR1unxX8KMAIfcHmL4vOIfZ6bkAMmmvA UXvBnYmQK5nB4ZkuPSg5PsAybLwYNuEw0xl0pX+NTuGaP+M7rQlR31uNNfwOe5jxJuiSvYvs4Id OQLFUJTqhLeitRWaCMD3XLogIfQ0j6rCW7cKmG2zSn0ORxQC798Xjs4sAVKi2I0b X-Received: by 2002:a05:600c:1c0b:b0:4a1:d10c:7170 with SMTP id 5b1f17b1804b1-4a35acbf94amr166524585e9.31.1793017061004; Mon, 26 Oct 2026 05:17:41 -0700 (PDT) Message-ID: <061c669b-e130-4b73-a748-46d58432e49f@suse.com> Date: Mon, 26 Oct 2026 13:17:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nestedhvm: Inline nestedhvm_vcpu_in_guestmode() To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1792515236.8631fc262581453bbf619ec5b2062170.1a15a3be15b000f79f@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: <1792515236.8631fc262581453bbf619ec5b2062170.1a15a3be15b000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1793017061-35EC6AE4-912AD6AD/10/78276251493 X-purgate-type: spam X-purgate-size: 533 On 20.10.2026 18:53, Teddy Astie wrote: > --- a/xen/arch/x86/include/asm/hvm/nestedhvm.h > +++ b/xen/arch/x86/include/asm/hvm/nestedhvm.h > @@ -28,11 +28,15 @@ static inline bool nestedhvm_enabled(const struct domain *d) > return IS_ENABLED(CONFIG_HVM) && (d->options & XEN_DOMCTL_CDF_nested_virt); > } > > +static inline bool nestedhvm_vcpu_in_guestmode(struct vcpu *v) > +{ > + return vcpu_nestedhvm(v).nv_guestmode; > +} While converting the function, can't its parameter also be pointer-to-const? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:24:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:24:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461203.1672165 (Exim 4.92) (envelope-from ) id 1xLJk8-0000AC-Hx; Mon, 26 Oct 2026 12:24:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461203.1672165; Mon, 26 Oct 2026 12:24: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 1xLJk8-0000A2-FJ; Mon, 26 Oct 2026 12:24:00 +0000 Received: by outflank-mailman (input) for mailman id 1461203; Mon, 26 Oct 2026 12:23:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJk7-00008p-Ox for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:23:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJk6-000Gwq-VM for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:23:58 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4653-8faa-0a2a0a5109dd-0a2a450b83d2-42 for ; Mon, 26 Oct 2026 13:23:58 +0100 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf465e-b7e8-0a2a450b0019-d155dd35d1b3-3 for ; Mon, 26 Oct 2026 13:23:58 +0100 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48e46e449e8so907787f8f.3 for ; Mon, 26 Oct 2026 05:23: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 ffacd0b85a97d-48e3ece14a1sm16607999f8f.57.2026.10.26.05.23.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05:23: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=1793017438; x=1793622238; 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=9+WOblBuGcpBDYdT4/csXL+quaz/UKWre6wr3qb2qb4=; b=KbkXEeyKJyUy4f3z5E6LFOtUq7U3J4EKgQAsUaQcAGr/j4Z6JTNf4p1g+/R8MbClDX vXNl5vjIlauCOaCXyZsURtTQ5YRRsq/BXIWSxxgsr7oLCGSYEjt7/YMY9vHSRPiG7VOl aLClLLttckIEE7zg1/lUmaPFh+1mD4SE6pRw5Mln67VS1I3XdxyIiRJ6XEFFoDNmKuNr SdVTYFe1sRS0Jw2VeLQtkRof6D9TuC7AKkp5IiKyu7S3GEx0mFYNQuc4c0jc1z17kur0 j4WZnybDjgUWbjtyZvvNBp3Qdq1I4/M8IgNJo8aZB/AmpTf80J75FzpCA4fcuv2EI3FD oGyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793017438; x=1793622238; 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=9+WOblBuGcpBDYdT4/csXL+quaz/UKWre6wr3qb2qb4=; b=o4UT3TKp2CD3fb6qZErhKhVYX7pwRrPI08p2UyP/iBTBgLU3taWHK67oM2xLTutBho sZaBtvKT86qaBagYN0x4cQTvV8xygu2O+zCO7scGP9xu99dJJR9U4IdFTajP8eRN7aXS /p1Ki8NNRVXvfJ2B63f+gN0ShsO/yd/2BfDKqYmSyMbISM+qhzOfTLNg2IVGikmbHjHh zmIA0R/Gs8mo7xBeKnrt1+ET03n/8JxTlYarZS2T9AGwbm7rpBQIXu5VLFP+tqF4RYqc Cbp/GdRPfq6OxZSIrerRmQPi69Ksb3GTPD0rBbKHsVckNlzS5m7fsYng/jtTt+RETEdc 89Mw== X-Gm-Message-State: AFq9FYL5TLRCevUuhaty9UnBvtp/X/aGuYwdRzjaE+1cIc0E706zlw5f r58u+1IG1tXMkV5dfe3ICS5W2BfqRclK3wTExRY/xVthcmgoVE+w02W9NeNDRy14RA== X-Gm-Gg: AYBFou0X97KLO4c2abvlKkBnOlN0CpnY5B8U70ILA443RnfezoYw2lCtoo6LQ2LlYUW BzoJy7HMGSnXbN0Xnopj654a4hP3MRuLeJ1ZMpCeYF2SKs6oxLckl5KnyPNSYs5jPwAFNVW0jDd N3MXH9J4WbwhVMjKeAOq3D7Sexj6FviL5jw87iQ76bDZiF/xz9YYNXfRDiF/G7eMtrVwtnihz9l 4WMBJJ2QTQGSMdnzCKB9AOl+wTGAK4TDRtnMd9wk0Vh/TUseTazYUSCWUHLeNQtEuYK9ttkUp7a ghiHhTi0JI+uk8kVAet5v50X0e3p8We9pwoecePENeb/nvJ4r6n/CI7hd2zLVnMCg4fC33hqt/d HVK50wjrkuse373Ux+BlEteV1+ZszUhixRD8u42T8/29YrPLKr7eFliqgsDFZQNo6yEd7aNKdmP ZNPjIU/IH03KCY+PLgC0edvNFGPSrmdWoCYst8vcTgGwzXZ8+1JSSxPoEzQw4xSeBJ7ZJr4Si9r 9ps5N5fWONVY+rqOE7cbAoAn2IJPCAzI/Pv/xrS/rv1k//U2lizs2NQB0VMXRq0gLht2bthNf/Q EiSVrGJwCFLQqHjxhpTTwkVaMeAZ/zqk8oJRJFdgX8w= X-Received: by 2002:a05:6000:24c8:b0:48d:f831:2681 with SMTP id ffacd0b85a97d-48e3eb922a2mr12101013f8f.38.1793017438312; Mon, 26 Oct 2026 05:23:58 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 13:23:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/bzimage: Check that the payload lies within the image To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech References: <20261020214825.3655848-1-stefano.stabellini@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793017438-1B6D29EA-AA7A4643/10/78276251493 X-purgate-type: spam X-purgate-size: 798 On 21.10.2026 11:30, Roger Pau Monné wrote: > On Tue, Oct 20, 2026 at 02:48:25PM -0700, Stefano Stabellini wrote: >> @@ -65,6 +67,15 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) >> hdr->version >> 8, hdr->version & 0xff); >> return -EINVAL; >> } >> + >> + payload_start = (hdr->setup_sects + 1) * 512UL + hdr->payload_offset; > > Do you really need the UL, doesn't it get auto-promoted to unsigned long > already? Without taking the type of .setup_sects into account, the suffix may appear necessary. But yes, the field being a 8-bit one, the multiplication can't overflow when done in 32 bits, so no suffix is needed (and generated code may - at least in principle - be slightly better without the suffix). Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:27:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:27:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461209.1672175 (Exim 4.92) (envelope-from ) id 1xLJng-0000rc-Vr; Mon, 26 Oct 2026 12:27:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461209.1672175; Mon, 26 Oct 2026 12: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 1xLJng-0000rV-T3; Mon, 26 Oct 2026 12:27:40 +0000 Received: by outflank-mailman (input) for mailman id 1461209; Mon, 26 Oct 2026 12:27:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJnf-0000rP-TZ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:27:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJne-000drW-Tu for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:27:38 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4731-2eae-0a2a0a5409dd-0a2a4509dc20-28 for ; Mon, 26 Oct 2026 13:27:38 +0100 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4739-be1a-0a2a45090019-d155dd33c071-3 for ; Mon, 26 Oct 2026 13:27:37 +0100 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48b042c0759so1646013f8f.2 for ; Mon, 26 Oct 2026 05:27: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-48e3ebd4d8dsm17455189f8f.36.2026.10.26.05.27.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05:27: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=1793017657; x=1793622457; 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=IpomNrNH8qnnrRyjYkppSWS+I4DgFqYEFVp4DNFHbVU=; b=IUsGoKFbVsQ5zUBJuAjqUW5WYKdEhyt7D0N6cg1l6Xbc2uBzMQTbviWJ5M2GOy5rWr ZpRUQAz8on+ab4cp/Vl/Dgi28svn4CTSolwyXcvll0RD9LgG5FQRr1wwct5Ygz/C8LZ/ tx7BGSwMuPaewreaAjLCgxdNp9ZfZNLE1BjXhBe23PkFvJMPuCx/bhTWj0G//HuREXYi dXZeZ3iY44V5ae8WyySky+sTtCuUlQbqGpnUEP4bpnu3QclZBcrrEbgAEDLydWY/vZzl jxAk7K/iRMG3g0lySG5N+lKspF+MoS5LrzLAw0VSL4+YXyJHgHsgv7MtEygQovseGYmz sV1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793017657; x=1793622457; 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=IpomNrNH8qnnrRyjYkppSWS+I4DgFqYEFVp4DNFHbVU=; b=todOpF8hhbgoSezyrEdAX5BlY3GGeOcFaKjGbIfV1bORxk4ksDN4G27/RyA4ieoV90 nKHvGy2vfgeo41F47o6hjF4iVnQQ5EZ53ydJGkB+qI1GIWleCWIaqlpmfP8qZV42RdOW +bMWXSZO1WySpj6jPOc3CPHGYGFyCV2ZfDNitTEak2mjrGjSlLVMWV1jIIDdYMv8Ync+ xPwwF887tFAJh5zfiw2WthwQF1aXR5atRrA2BVJXp6FPx8b9I8LZeKUHa+ejWUu3rUsQ bk/P1GMpQTM6y7TgXpJv+RZNulTjKHulHd+47HhZUfbaIR8PsYTPOhFwq7IxZbYJGrkW R/yA== X-Forwarded-Encrypted: i=1; AKwUvBzG19QSJpJAtM/tgRj5DRMPnGxkNocUAQto0/c2953DzS4ABFMrvlWkXAWUksWCASjcHqh1EPBn168=@lists.xenproject.org X-Gm-Message-State: AFq9FYLeMt+ds4S1yGXy6Og+d+ZD/5ahzcPQ+y/qfIQk4uOa3vr4s2Dl H6oBysWmJ+kPILV2hIhEgt/enRInJ6M3XnLWq8j+Sh3fXoyNPzfRAAhq2PYEQ1kS3Q== X-Gm-Gg: AYBFou1LWiytr1GUFLLqSK0U45I0Pu6vvP6th/jro7mSbkcbdaQTvGMMO2UdREWGzsr 24aulG+0I3EtDsGk7D3soWo/DfRiKbj1m4A0yT/Ay0KwwiFIkVzzNXjNs34eHgnpGHjvssmmoy0 ae9Cx99uJosUXCSrZO9kUJh1+IkFmnEUFmD7eQ6uT1o4+8GU/VkLcTN6An8Fw4S5T6M3OthIKQN cb1chvm7IA7XwHXrH8hoyVVGEYXvGIVHIwujW25Ls/1sgjhkvWhoPCJb/R71U+/3nUDDJCx/yKp oMCoArgBC47WW2/Gqx8zqnWzubuLLytZYg4UZ4Gsb4GyLAC/md4GVhUrSj6v/fNzNIvb78Y5WHm kdPJ3RvOr9jEZNUZ9SQnp/k5pvWLkgrv12acsmjUKdaC5OfczhMUWupD+dD3ZY2nCFbT7gmjOeR P9qXYCpM77QydNs/q+VhXbXFIyqlH8/kIMTIdWDYPRZJVHVLTTXVl8zAtCA6i/NLqxbWToJHUbW iOFzGNgVypxuJPIqQ1HY7xL5TOAgL4TzFdAB/dBF1AcU98gNsK2K2bQKQyOZVpwTshdL3EasdUj Y/5dbzeAYQfVlGewknYs/iY9QFET5p5bJk9iXfYYvuQ= X-Received: by 2002:a05:6000:24c5:b0:48c:69bd:e971 with SMTP id ffacd0b85a97d-48e3eb859dcmr12181717f8f.16.1793017657229; Mon, 26 Oct 2026 05:27:37 -0700 (PDT) Message-ID: <25409f5f-bf65-473b-93e2-07070295093f@suse.com> Date: Mon, 26 Oct 2026 13:27:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/amd/iommu: Skip IO-APICs missing from the IVRS in shared IRT mode To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, Teddy Astie , xen-devel@lists.xenproject.org References: <20261020215941.3667346-1-stefano.stabellini@amd.com> <1792572666.8631fc262581453bbf619ec5b2062170.1a15da83071000f79f@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: <1792572666.8631fc262581453bbf619ec5b2062170.1a15da83071000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1793017657-3ACDF034-4845F589/10/78276251493 X-purgate-type: spam X-purgate-size: 768 On 21.10.2026 10:51, Teddy Astie wrote: > Le 21/10/2026 à 00:02, Stefano Stabellini a écrit : >> When an IO-APIC with entries isn't described by the IVRS, >> ioapic_id_to_index() returns MAX_IO_APICS. With per-device interrupt >> remapping tables this is fatal, but in shared mode parse_ivrs_table() >> only logs it and then uses MAX_IO_APICS as an index, reading and writing >> one past the end of ioapic_sbdf[]. >> >> Skip such an IO-APIC instead. It is left without interrupt remapping, >> which is what the rest of the code already assumes for an IO-APIC with >> no index. >> >> Signed-off-by: Stefano Stabellini > > Reviewed-by: Teddy Astie Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:28:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:28:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461214.1672184 (Exim 4.92) (envelope-from ) id 1xLJo4-0001VT-AM; Mon, 26 Oct 2026 12:28:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461214.1672184; Mon, 26 Oct 2026 12:28: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 1xLJo4-0001VM-7j; Mon, 26 Oct 2026 12:28:04 +0000 Received: by outflank-mailman (input) for mailman id 1461214; Mon, 26 Oct 2026 12:28:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLJo2-0001TM-He for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:28:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJo1-000Htn-UJ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:28:01 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4735-2eae-0a2a0a5409dd-0a2a450bcd94-18 for ; Mon, 26 Oct 2026 13:28:01 +0100 Received: from [40.107.162.83] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4751-b7e8-0a2a450b0019-286ba2532f5d-3 for ; Mon, 26 Oct 2026 13:28:01 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by DB9PR03MB7793.eurprd03.prod.outlook.com (2603:10a6:10:2be::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 12:27:59 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0546.019; Mon, 26 Oct 2026 12:27: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=sxzBcfHuQy2OqW7l2P/Ip8MHjBZn8LU77da7ILNJGg3u4VNFrgmX5yV+0adq5jlPrT1nca3vbzEUQ16r0d5+t4Q16IQRlHRFfH96ix6++Th2+cmdrmLGyCzVIck9B+ncZw1a+lUefsa5fUQejrgq26X3H2BSStvSnwLhvkjnXNMxGvt6JWPCjNmvKCe9Jd853uYiowb4R6M18J4ImmKBWgNLwYCz7uquipl3odUwzpZLOQYXIt7y8Q/n5ix5bHhU90awiiyJrnFC1U9SitYlH9FauJr9KLsIGAHEnfFgGakBpedDke8FX8EbWRW4fNoJOa1tYATP/lKPzLjg1Arxbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ahk2kZMQlYAsjLgIv69OmotXK+AZTCfAtfzin+W5rgU=; b=yuiwV+jiRLB+8Y+mJxpVGRpUvqA9s6+XEqJ1VXMEL8dXWhaslpOylHGSi5HJwTfI6Exi0Yu9mGpeXSEgubXxwHPVog7TM+o+p0oeBmUESh7nwZ3wNrAmMmTi7CS0dNIhoeTMLesYXmRriZoyqN0whNY3kuLXJ9+xG7PZ3kqgmid5Ls04NvSiCycQGPxJCdLCRAvR25h7GSD6sxx/b2zQXfFcT3hJ+PLhfZFW+7bstmvLjm1FN9c5dGCZQVOoc3SgMaLg8DNB0UvYZwtOe22Br1l9XNm0Dc2ovdje/Fn6lctexf9Crrnbfhw3ry5zDMTNsfYQsfuBlCHyttJZ081UAA== 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=Ahk2kZMQlYAsjLgIv69OmotXK+AZTCfAtfzin+W5rgU=; b=lIrauv8zVgF7cv2IwSgBPL54o9aedZTMx6421+Ia3NXr1Tzu8Na4gD/F1RMUeoDBlqtT1xuw0rl2XOxTtH4woT64/sNO+uBaQcJXB/t05OUZIpi/YVnjjoXCoR6Ae9GhIWy3iv9I0bQpGgs5+NUOBJRQz4BPW3VaqmIgg+MkKyPVcisq+SwgSLFdYtVWAQBa8LbMc6JnTQKfc7sa3Lb4NCbYcEsl4GzVjF6D4D31YoYr21twzX8cPRavDvURcauWXiheWwNWdZ4Eu8YfRN3M5o+7J5xEmSJ6CU2IvKkzSFVW4XhH6i8lApBA63Z4ZUpSNxuG+VQTPmJjsMTrDyXNqg== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Jan Beulich , Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand Subject: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Topic: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Index: AQHdZUVvbuj2+I/wmEeMfHolzOWTxg== Date: Mon, 26 Oct 2026 12:27:59 +0000 Message-ID: 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: AS2PR03MB9076:EE_|DB9PR03MB7793:EE_ x-ms-office365-filtering-correlation-id: 328c8121-a95b-421d-2fff-08df335c926c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|18002099003|56012099006|11063799006|261021121427099003|10067099003|261009223027099003|261021123027099003|38070700021|260925022911599003|260925021911599003|260925021311599003; x-microsoft-antispam-message-info: J/V9seyFNlXf0AtYa2ZzT/HKH7ogo0LpjEvmEykc+zzbOe3HnB9WmMlCUrnjuARmPMubUz6n9+nFA7lOrLE5YE4f7Pccwm4J1zDQU3UOFfj2y6KICXmpmaiwPmSrITpMIwM8veQcgrxN8EdGJYRs3BIVc0uBjF839EC0cH6bC9tlIvrejunNBQKmee3ddMQ2rvzR3fxaYZy6eIrtJIPPjUahWwpPIOHdnkEln6wSvWkoH1qgo6VKqlpZegVT+up4vvZ7+zJ/k1fjOHMe1LmFedv3rOhWfs6VObwuAqvd7l1O8ndLaYr2xyCIacxohn5iD2YPJlPYcU2yNlRS1F2a5skFtf3vZu/24VrK3IPpXS7r4fodK5xB1D4C91zy9hUIHb/uvm5ULD4OQ+A1jdBfqlAK0o/S6d1awucaO75/OePCsqK9V1aBYO8Q7pUbVX+dV4wb1OHaZgQHyLLSpJtIsIo6QR5RdiIpGfESygo3VRsOkxIeusNVgdZU56BQh94Jpcw/8j8CdcQMkaISmwXxIdpgLoIS4fsD8kFUmVsfJjPWK16S825BRaze3+0Svps+MEvweA0G+9tMqAjpvDlJEoFC8ziqQzSHSPoYDxUZufrsV3tlkWX9OmiCAqAcG/WBSsucH42NDVDks1e6z0EVlT68oMoGHNvxZCWbQ2QNcdk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(18002099003)(56012099006)(11063799006)(261021121427099003)(10067099003)(261009223027099003)(261021123027099003)(38070700021)(260925022911599003)(260925021911599003)(260925021311599003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MEJ0MStIK2FVTEthYVF2d2tPVFVtbm5tUHVCQUM5SVVoNHN2OGEyZ0JlSDln?= =?utf-8?B?eHVudmYrWEU1eUwwcXN5TSsxK0ZGSjJPTmdGU09HWEpXY29JdW1PUmZHWm9s?= =?utf-8?B?c3d3QWVFdTZscmNtOS9teXVUYzcxYnArVUdabkNnWTFlN1NWMEsvM1llRERk?= =?utf-8?B?eDkzeGNyd1I4c1VzaGlmM1BvSjJMczI2bFZ0RW5wakhxdkFRU0JOQ2Rxd2R3?= =?utf-8?B?dlRLUUxESitUcDkrMFB3cnNQb0E5d3BoTStKemplcWdVdlg3SWNDUloxelVS?= =?utf-8?B?SlczSXgrNW1WV3FLaFcxbTllVUVWb1RKM1J4YmR4UWhiTjduelRmWkFXQWQz?= =?utf-8?B?OStqOFFJMWg0K0FXZ1ZMUFZrYkxwcTFaRHZYdW8zUjhNZndSdkg5dTNYbWhw?= =?utf-8?B?b2JtWnJ5UU00djhWeStRVDRmWGdwc3lnNzJFUHpnRG1QbDl1alh1Njczckw4?= =?utf-8?B?Q0wwd0dKb2ZDY0JhNlI0MDlyMDhvbmV3VDdmYWdiZWczTjBPMXhwSFhKWFQv?= =?utf-8?B?US96WUY5V1QzWTQvY1NXeUh3R25vVEpzNWZzdkEyVzZsTFg3UEhBTUdBWFlJ?= =?utf-8?B?czd1S0JFQU9lZHpjRVVEalV3MC9jVXEwS2hLckU2NWFIM0NPUzFJNENlSFJ1?= =?utf-8?B?RHdEYWF4ejlPanc0TTdiQUFWcmtDNGhnV2J4NWZnU2dPTStwNXRFK1kvSU5M?= =?utf-8?B?TktIYmUraVBXZ3NoQkdpWHBJb0E1SXhkcHMwVGRJNzFENlNkTVI1TlFWeUJm?= =?utf-8?B?dkxqdG9Idm85RUpyTzdXZ2hrYU9RTXp3KzVsbGNtakhrUFdvTWhtWHJnM0ZG?= =?utf-8?B?RkVhblN2eFZxOG0zTWlJcjBoSmZFcWErSW1oS0FlMU5XUVRxcXVNbllIWGFs?= =?utf-8?B?M3U0ZENEYjF2WWZIaHVUb1ZGTE50bStnVURmK28xQy8vSXZTUU5GenAwWnBF?= =?utf-8?B?Q0xMVzRFL3FwQnZzWmFzWVZvRTZiQm03a0xrWFdHelVwa0JYR1FhT3ltQWhQ?= =?utf-8?B?blVlUGd0QXRMaHV0QW5ERVhQZXUzYkd6Zkphd3lHREJZeXFnbVJRd29KRS9u?= =?utf-8?B?V0h2Q0RmVkF1MFNaUFJ4Rnc5OGF0TUJKSEFQUFZCMFd0WWR0UEJUM0taaE52?= =?utf-8?B?K2hxeDBtby9ZS0ZITVRTZ1RYSDdQbmtJNTY4QXVEWUk1RWMvbmtTdWZ0VS9p?= =?utf-8?B?eUJWVkd1alVGekx2RGc0SG1nSC9tUENzWjIrWFJiZkxmZ1B5T04wZmZIUWNm?= =?utf-8?B?UTR3MENjckJzd2tLL1JDQWJSdDZjcjgxSjJ4Q1JEanMzdUZGV2xTaXZmN0J4?= =?utf-8?B?MFQxVS9IZ0RvZXZjTWF1K01CQ3k4TXpMbC9venk3eVZ5WmFuRm5HcFVOZHRh?= =?utf-8?B?NDVXSzRRK2NmVXdTaUxVdzQ4UDNwQUJUWWRxZTFFVXh0UVlxMExVTlF2amp5?= =?utf-8?B?Q2ptNHo1dEdQU0NFRnB5VDhGUGlmRlp2L3E3Q09LY1ZOaTlORG5odjkxdUdi?= =?utf-8?B?N0tVMUJsc0Y4dGRRN3dXUXNjY01LeVRmQm4rMnFWemdJSkZKMmxYaWY0UEds?= =?utf-8?B?UWtLVTRVYVJZMXRmaDNyRG5MVXF0MncrdStzZkR4dk9oYkZ3a1J0dXRiTnhX?= =?utf-8?B?aVNDQk9MYkt3cnVQdCtkSFg0QjJpTDM0aTdmT2t5MGFHT1EwYlB3Umh6cWo3?= =?utf-8?B?NEVZN2Qxbm5xOUMwOXNpRlVoRXZIQUMzRzJDQTJ4NEdrQU9Vd2IxQ0RsUzNl?= =?utf-8?B?Q2pSQXhKODJIZmVCRUVqcS9UUkV4cjRtbjlhZUNDOFhFa0ZvbW1UaE4zdFNy?= =?utf-8?B?b0h0MjEzMVBYWnBvcnI2aHMrMDNtRFRqRkUzOUlITlUvbzFraG9CZEh1OHpp?= =?utf-8?B?dnNNcC9jNWdlNGw1aWE0RzMzbUhNWmtQb05UVm5jU010cE85bjRJKzl0SkRT?= =?utf-8?B?NmtaMzRTUVl2NVNqMXMrM0dlclBCTWlLR0Z5UFROWERxVllsYVpWNnRaRFkz?= =?utf-8?B?bTdJZDJ0bkV3cXVtRVkxemhFMVlSamtPNUFKaS9NYllFcFlRK1Iza21qUmZq?= =?utf-8?B?RjU1UHJLUUo3cGRsWXBXbWdqRmxoZ2N1ZEZLT0dPSEtmbkJxUXAwSWVlcTNP?= =?utf-8?B?QWNxbXNBempBMFNSalR1MExML2UxZ1BsUDdQWXFlemVEMG42WUNINEEyakZO?= =?utf-8?B?UHkweHdJT1dxWTdlTjdHYU5WaFBmRjdxVk9vK1ZMV0EvbXBMYWE5RGN0OGdy?= =?utf-8?B?dW5ybFkrRzllbnhZVXJIRmlXVFlMQWxNMHpMRlVsNkh2ZFEvandTOWZoMHdR?= =?utf-8?B?QXEzOTJEV2hNaHJxMis3clhpeGRjUnBIS0dOU3BhL3F0cWQ5WTMyMGViOEVx?= =?utf-8?Q?0ikRFSXsyfEpoI+M=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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 328c8121-a95b-421d-2fff-08df335c926c X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 12:27:59.6329 (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: c7jiRrPAOdXMBZy4N0bXJrj4wYSAM2mvEroAsKyer9mp9sGCNayvjNyGi+S2u6VnyuLjVul3Njb16Kv5v6Sxeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7793 X-purgate-ID: tlsNG-42698a/1793017681-1B6D29EA-3B404F3E/0/0 X-purgate-type: clean X-purgate-size: 2090 VGhpcyBpcyBwcmVwYXJhdG9yeSB3b3JrIHRvIG1ha2UgdlBDSSBNU0ktWCBmdW5jdGlvbmFsIG9u IEFybS4gU3BsaXQgdGhlDQp2UENJIE1TSS1YIGNvZGUgc28gdGhhdCBpbnRlcmNlcHRpbmcgdGhl IE1TSS1YIHRhYmxlIGFuZCBQQkEgc3RheXMgeDg2DQpvbmx5LCB3aGlsZSB0aGUgTVNJLVggY2Fw YWJpbGl0eSBoYW5kbGluZyBiZWNvbWVzIGNvbW1vbi4gTm8gZnVuY3Rpb25hbA0KY2hhbmdlIGlu dGVuZGVkLg0KDQpUaGlzIGlzIGEgY29udGludWF0aW9uIG9mIHdvcmsgZG9uZSBieSBSYWh1bCBm cm9tIEZlYnJ1YXJ5IDIwMjJbMV0uDQoNClRoZSBhcHByb2FjaCBpcyBpbnZlcnRlZCwgaW5zdGVh ZCBvZiBtb3Zpbmcgb3V0IHRoZSB4ODYgcGFydHMsIG1vdmUgb3V0DQp0aGUgY29tbW9uIG9uZXMg dGhhdCB3aWxsIGJlIG5lZWRlZCBvbiBBcm0uIFN1YnNlcXVlbnQgYXJtIHBhdGNoZXMgZm9yDQpy ZWZlcmVuY2UgY2FuIGJlIGZvdW5kIGhlcmVbMl0uDQoNClsxXSBodHRwczovL2xvcmUua2VybmVs Lm9yZy94ZW4tZGV2ZWwvY292ZXIuMTY0NDkzNzQwNS5naXQucmFodWwuc2luZ2hAYXJtLmNvbS9U LyN0DQpbMl0gaHR0cHM6Ly9naXRodWIuY29tL3N0ZXdkay94ZW4vdHJlZS9wY2llLXBhc3N0aHJv dWdoLWFybS12cGNpLXYyNg0KDQpSYWh1bCBTaW5naCAoMSk6DQogIHZwY2kvbXNpeDogbW92ZSBo ZWxwZXJzIHRvIGNvbW1vbg0KDQpTdGV3YXJ0IEhpbGRlYnJhbmQgKDIpOg0KICB2cGNpL21zaXg6 IG1vdmUgbXNpeCByZWdpb24gcmVtb3ZhbCB0byBtc2l4LmMNCiAgdnBjaS9tc2l4OiBtb3ZlIGNv bW1vbiBtc2l4IGNvZGUgdG8gY29tbW9uIGZpbGUNCg0KIHhlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz bS9tc2kuaCAgICAgIHwgIDIxIC0tLQ0KIHhlbi9hcmNoL3g4Ni9tc2kuYyAgICAgICAgICAgICAg ICAgIHwgICAyICstDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11LmggfCAgIDIg Ky0NCiB4ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlICAgICAgICAgICB8ICAgNiArLQ0KIHhlbi9k cml2ZXJzL3ZwY2kvaGVhZGVyLmMgICAgICAgICAgIHwgIDMwICstLS0tDQogeGVuL2RyaXZlcnMv dnBjaS9tc2kuYyAgICAgICAgICAgICAgfCAgIDMgKy0NCiB4ZW4vZHJpdmVycy92cGNpL21zaXgu YyAgICAgICAgICAgICB8IDE5NyArKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiB4ZW4vZHJp dmVycy92cGNpL21zaXhfY29tbW9uLmMgICAgICB8IDIwMiArKysrKysrKysrKysrKysrKysrKysr KysrKysrDQogeGVuL2RyaXZlcnMvdnBjaS9wcml2YXRlLmggICAgICAgICAgfCAgIDIgKw0KIHhl bi9pbmNsdWRlL3hlbi9tc2kuaCAgICAgICAgICAgICAgIHwgIDIxICsrKw0KIHhlbi9pbmNsdWRl L3hlbi92cGNpLmggICAgICAgICAgICAgIHwgICA1ICsNCiAxMSBmaWxlcyBjaGFuZ2VkLCAyODIg aW5zZXJ0aW9ucygrKSwgMjA5IGRlbGV0aW9ucygtKQ0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4v ZHJpdmVycy92cGNpL21zaXhfY29tbW9uLmMNCg0KLS0gDQoyLjU1LjANCg== From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:28:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:28:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461215.1672190 (Exim 4.92) (envelope-from ) id 1xLJo4-0001Y5-Ij; Mon, 26 Oct 2026 12:28:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461215.1672190; Mon, 26 Oct 2026 12:28: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 1xLJo4-0001Xu-Dn; Mon, 26 Oct 2026 12:28:04 +0000 Received: by outflank-mailman (input) for mailman id 1461215; Mon, 26 Oct 2026 12:28:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLJo2-0001TS-PO for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:28:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJo2-000Htn-5y for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:28:02 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4735-2eae-0a2a0a5409dd-0a2a450bcd94-20 for ; Mon, 26 Oct 2026 13:28:02 +0100 Received: from [40.107.162.83] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4751-b7e8-0a2a450b0019-286ba2532f5d-4 for ; Mon, 26 Oct 2026 13:28:02 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by DB9PR03MB7793.eurprd03.prod.outlook.com (2603:10a6:10:2be::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 12:28:00 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0546.019; Mon, 26 Oct 2026 12:28: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=bDsIIDkLwJLoa8xss8NuToPoT/5Us5WQIbBITC8A+9wreqHMndOAY4PjormcT6F45ppQJ4Eehl7f6fZJHNQLD/iXPpPLiNV8k8OlMin7KiX6NWsHQquhengNIGaAbbJXSVtJXT4oN0W51F0NppqVo9+Ywh7s0RJkFIY3BWya3wF/6zfr5o+Bd9gKq7MYqi4x+M8stR02cynz5rr/83ilaouX38obDx1KooZ2e56evLYUgIflnWBP5CxcVKrEJPv23uW6kMcdx7R9iAQBfT3FdbV/31LFoZoXBZuANG7Yb50lZPxSUWk9SyXud3bYeLW8m/5E1GCDEsywayST1ORiNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uJs+WFpev3akBFRF+sJ2ujKnrr/5HAnuZXXVTr+5cjU=; b=jHtpRv/DzailNhhC4ldpTIgDhroQM7pApdHTTx+cvDCQ7AX5Imm05kpxr/nbMPCfahOOBaKKbHSX29umRJvF8fjwmBpc2q0Hq03BVtf4PyGLO3iwVx1D3ytaqUxQTAzyKNzWf5o1x7ezFeEmWK0uj1p69F5WleZ9IMlnC9B/Yu6Pq81ddQewxdPg+TX3uzfIh//LUr7/O/16IQUpxuoPI2iKqcVwp7FJzwyDmCH/TkdU61q3+dozDEUauMsEnYVFmOxS1CcvzuWe4hLuqQVHu0TJCfbVOksfm4aS0ZgpWgXb31iF+ING9+Sl5MJutiAQv2gneie/CQ0HB/yTJXrnGQ== 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=uJs+WFpev3akBFRF+sJ2ujKnrr/5HAnuZXXVTr+5cjU=; b=rNSzvtSwL7f7C7rZmjceX3W2QhcqIVfuw3QH4P0uT1Yx1n93kv9K5w+38nSVoutQogSTStCVAS+v4oZCo8vAntGqedzD1NnA2q3en/t1Z+2ze4CZtDkxLa9p3mGEEd9Fyc82/m1umnsWjSxcAuY8qfJxxh4VVgscOVUx9tQ6AWFth+y+JsJoSyAt0E73aeVkT292z0QT8vwc9+SyTwdFn27xA+u6dmtisDlmEJIVXBZvcpqCgnTyghZbyVF6MhLDwgmHdpbJwmwSraoAYLMSb3WYGkzikZbpTkHg9qiB9eFX+C7yYDdhmRI8G3zQFHOUM3WB3nUJxPiTt4H7VsctjA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Mykyta Poturai Subject: [PATCH v1 2/3] vpci/msix: move msix region removal to msix.c Thread-Topic: [PATCH v1 2/3] vpci/msix: move msix region removal to msix.c Thread-Index: AQHdZUVw/fA35GNZ9kyzCDEBJXJ5MA== Date: Mon, 26 Oct 2026 12:28:00 +0000 Message-ID: <2531af333e3f44e2f47a8871fcd55fe3644774e2.1793012250.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: AS2PR03MB9076:EE_|DB9PR03MB7793:EE_ x-ms-office365-filtering-correlation-id: 07685698-b8b5-4354-a831-08df335c92d3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|22082099003|18002099003|56012099006|11063799006|261021121427099003|10067099003|261009223027099003|261021123027099003|261022105027099003|38070700021; x-microsoft-antispam-message-info: ESSZN6wVayzMiI31PkQmo6E8Qh+yGBIOUhH2t/6Es+hOT7e/iokEYHOhaAgKO3qGTGSUti+ALcW2+O1Azvg2pH4r/K8yOSsUaLRO2kBPdTtCNxVjIRJM750xmEaK4hOBZSlRt+u0pkQ7IipEb2jwfEi7WrDFilggbIm/A5+GDSba1xW402ItNYQWBt+IemeIuvBW+lbwb6i34Vp5hJ+A93f5cjaoFFMCyTXfKqocTVivn1fDD+LPHdXk+lenFn6W7+MELkJdx3m32WUeY4a8eLRnrzFE6TYRomOQ97RkzTI3r5AqT76KtntBDi5Ac/oKrrbuoxlxqs/ZVb/PfpAIoq30IohT0t2sPSdO3UkHbWvRDgnwTlTJYyDXZEXEjeE6QNG4tUSngBelou8rqcORRsrhUtIrkwavfRDpAqIrjC0phBm4uRZ2IDbTuvSIMvS9CEPH2LQDhCynDK3Hr2mfmAfTglsIqZxpQJCQwMzBWz1KxudFs94aQIdClQ6gPM++IA8fBfRZ2gOvwXA4GRJB8Hr9TiK7Pe5zEcJgbxKrzyETZD1GF+0Ya/aHIrLfHChfqMMmduw6w6iismCXGOcdoPMOpw2eTUT+l1vHinOkOzZwDLtZpg7kRrOGeRe5NtLMbq6T3mj98MC98ZinSZ351k0sPpc2hJKslVoiZCllD9X5ios6q7P2brG51rTjEvVCJJq2JN6aVrFa6URYUu0j8CnwHJ2TUjvpAqV8Y8Yd9ng= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(22082099003)(18002099003)(56012099006)(11063799006)(261021121427099003)(10067099003)(261009223027099003)(261021123027099003)(261022105027099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bXlaOFVGSFV0eUg3ZG1sZ1ZaTWdxM1QvSUxPRjVoMXVvdHp3VlhQNDFxMjZ0?= =?utf-8?B?QytmV2U3SllESHdNUyt2bGdzSGxlWDFYTHE4SjRzLzh3U2FrU2xZbnM1dHJr?= =?utf-8?B?WU0zam55QjRNWWcvNHUzM0tLRGJTMzM0c1dtVGNkeHZiaDlZQ3Vjb1lZcVdS?= =?utf-8?B?UUU1Vk9VeE1CaHc3c0xMMU00YVFBMGhKSUR3Um1vbFVidkE5UGVvZTVFVG5Z?= =?utf-8?B?a0prYTVROGM3OUIrUG9URVYrVGdNQzlNcUl6bkMwNU53ZXhOQkEyNW9heXc5?= =?utf-8?B?bFhDNXI4ekJibHlYUjVMTTdlZmE5UWgrWU9yV0kvWlZsQWhqUFFITFB0WHRi?= =?utf-8?B?RnYzR3BtOVdva1RwZGRNSHBzeTQyeGJCMjFGcmhqcEJJaVlxRUMrb0JUdldi?= =?utf-8?B?WXQyb2ljTnNYSUg3cnBGeVhRVmlCWmluOFRhK0pjMXR5dHpKdGhSUWZkQTNY?= =?utf-8?B?ZGREQUM0THpxUXB4UFpXN2hUWU43K2xvSlcydUpnMGFXNVlia3BJVnJrT25L?= =?utf-8?B?VVFhNytJbUlteTlzZTBtQVZ6L0R2ckJzNEZpdVNVaUFSclRuRExVZEZuMytq?= =?utf-8?B?VUZkYnVaZXRkajNvZCtEUFNldEt1RzUyK0FEbHZEWmJOUWxtZDR2TzVmUnFr?= =?utf-8?B?R2MvbjJGZGU2VXBjTm9zeEtOUFViTDBUVXRGKzRkeWZYUXM0TzBROHp3ZmJE?= =?utf-8?B?TjVZTTJRcHlrRWlMb2U1VXM2UXcxWWE3cHpYKyt1dmVRTHRJWm5qL1FpcHV4?= =?utf-8?B?TElmZGQxSnQyYi9VVThnS21KSzYxVDJGZ3UzaVluclBnVHh1MHIwdm5RVUcx?= =?utf-8?B?aVdWbDdUU2xWWjJIbkZZOFJwU2FzZ1pZZ3JXUHdVR3AzZThHNzljNERobHRa?= =?utf-8?B?cFZQUmJhRlB4dTIzS1FxUFFGS3dyUktiOHVQeHhrbnRhaXUxc2ZVQUVxdXJF?= =?utf-8?B?ME1Ha21MOUpTNFNkN2NIaitod0djakM0L0hWblU0VGQxSVNGcVZNL2xxUUR4?= =?utf-8?B?RXM2ZnlaSVdTVGtKd2xuQitrajdzbGNJdWhzUmVyMGk5RlRIcDNVZDZSdXFr?= =?utf-8?B?eDN6VkxtQ1owVzY2WTFyczZPa0Z6bnFTQ25RNDJUaFJFYko2QnQ3SmsxYUpG?= =?utf-8?B?cUJNcVlSTWVrVTdkTlBsQmdUck1hQlBzcDJWeG5aYWN6bHlDUDJWV21vcWYv?= =?utf-8?B?V2YvRkxWZ25raDVqNnVtb2MzSm9VdFBFTUpKZE5PdmlCcm5sYlpJa09meThn?= =?utf-8?B?amJIbjN3R1RhbUE2N1J1eW9lbnpQa2pZd044RjA3ZUJ6UTFaa0RzQ3FpWklt?= =?utf-8?B?eEt4NmplZXJPY1pIMDdrZWw1N3RHaUVZd1ZPVm1EaUhuVDNFSzg5dlVVb0dm?= =?utf-8?B?eDdwVTlHbW1CWkplakdJSHlidXliTTAyK3ZpMTY4aUE2M25uV0FRZHMrMDhL?= =?utf-8?B?REd6ZG1yWTVjVzFQWXZPdjM0bmJOUHRTVDBjK3FIVlVrTTNkQnltMWZVMlBG?= =?utf-8?B?S1Z3S3ZkZkJuVWk1VFN6MVdiNmVyR09samZwU2I1NW04Rlh0eTNlTWc2RGVV?= =?utf-8?B?ZCtpVjAvdmR5TVFQQTl2eEVON3ZxV0FieDY4MjExZmdsYnZ1TWpLQXZRbEc0?= =?utf-8?B?OU9RUG84ZncvSm84S28wMEZBakZZeFZVWlRTMHR1Tm1PeTNVRlpWOENmTGF2?= =?utf-8?B?dHpZTVNpcDVGQ3ZJeUtQR1I0NW1UNzVVOS9RRk92a2hrQk9yQTZ3MC9FNW9R?= =?utf-8?B?ZTh3elcrbndjbEtOT2VBZ09VVEZFejJ4azVaTDZBRG5IaVBwSlBWWW1oUTJq?= =?utf-8?B?N3lZcWpKbnJZN0NZbnVXbGZyOE9YRHVJb2puZkpZTG1HVWkrYnhERmFyN0dx?= =?utf-8?B?dkNyN2ZtbDlYeDJvTzJDMFY0cTJrQXNMb0ZwcEdYYmdGeC9kS3lBeEV2dmEv?= =?utf-8?B?U25xdjlWL2lPTGw5ZHNaTlhBRXhjYllsMWdncDJhZndpWVJRL0NNckZpRCtM?= =?utf-8?B?azkxa0J3RkxTbWxLN204ZUJvcXVPamoycTFtY08xbERyTlNUUCtKRmZ3Tmho?= =?utf-8?B?VUkwdlRIMnR5T3RPcmY5aXRzUGFHMEx2VXFadU9pK1FXVEc3b0hFU1R4ZWZN?= =?utf-8?B?Q3oyQkV5UlA0aCt6a3F5R210aUFHS0E4bTBaZFZBR2ZnbEJkb29kc1p1L2o1?= =?utf-8?B?VHoxQmlLeGtpUXlWZ1d1U3NtUEtobk5rQjN3eVlYVVk5b2Y2UlozWWRVWUQy?= =?utf-8?B?NTdaczVxN1Rrck5nQ2UwQXZIcy9uZElmSG51SndGSE9rc0g4d01sem5KeUpZ?= =?utf-8?B?dzNOYlgyNFRnNzJhSlVvQVdGeWFVNEdNOENqOXhnSXlkVEhpM3pHS1NCSFBx?= =?utf-8?Q?lSodu2E8tRrriVZc=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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07685698-b8b5-4354-a831-08df335c92d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 12:28:00.3036 (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: Goznz1QESGDhaLErpJkWVpVXdxPf24zEdisDmxWyfslqb7nwJsK0LcXVBLtTlgk0L7/RmrLK58iTPLhRZcdSZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7793 X-purgate-ID: tlsNG-42698a/1793017682-194C39EA-D696F052/0/0 X-purgate-type: clean X-purgate-size: 5768 RnJvbTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCg0K VGhpcyBjb2RlIHdvbid0IGJlIHVzZWQgb24gQXJtLg0KDQpTaWduZWQtb2ZmLWJ5OiBTdGV3YXJ0 IEhpbGRlYnJhbmQgPHN0ZXdhcnQuaGlsZGVicmFuZEBhbWQuY29tPg0KU2lnbmVkLW9mZi1ieTog TXlreXRhIFBvdHVyYWkgPG15a3l0YV9wb3R1cmFpQGVwYW0uY29tPg0KLS0tDQogeGVuL2RyaXZl cnMvdnBjaS9oZWFkZXIuYyAgfCAzMCArKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiB4 ZW4vZHJpdmVycy92cGNpL21zaXguYyAgICB8IDM1ICsrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrDQogeGVuL2RyaXZlcnMvdnBjaS9wcml2YXRlLmggfCAgMiArKw0KIDMgZmlsZXMg Y2hhbmdlZCwgNDIgaW5zZXJ0aW9ucygrKSwgMjUgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQg YS94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jIGIveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0K aW5kZXggN2U1ZjRiOGEwMC4uOWUxOWU0MWQwYSAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Zw Y2kvaGVhZGVyLmMNCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCkBAIC0zMTAsNyAr MzEwLDYgQEAgc3RhdGljIGludCBtb2RpZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRl diwgdWludDE2X3QgY21kLCBib29sIHJvbV9vbmx5KQ0KICAgICBzdHJ1Y3QgdnBjaV9oZWFkZXIg KmhlYWRlciA9ICZwZGV2LT52cGNpLT5oZWFkZXI7DQogICAgIHN0cnVjdCBwY2lfZGV2ICp0bXA7 DQogICAgIGNvbnN0IHN0cnVjdCBkb21haW4gKmQ7DQotICAgIGNvbnN0IHN0cnVjdCB2cGNpX21z aXggKm1zaXggPSBwZGV2LT52cGNpLT5tc2l4Ow0KICAgICB1bnNpZ25lZCBpbnQgaSwgajsNCiAg ICAgaW50IHJjOw0KIA0KQEAgLTQwNSwzMCArNDA0LDExIEBAIHN0YXRpYyBpbnQgbW9kaWZ5X2Jh cnMoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25s eSkNCiAgICAgICAgIH0NCiAgICAgfQ0KIA0KLSAgICAvKiBSZW1vdmUgYW55IE1TSVggcmVnaW9u cyBpZiBwcmVzZW50LiAqLw0KLSAgICBmb3IgKCBpID0gMDsgbXNpeCAmJiBpIDwgQVJSQVlfU0la RShtc2l4LT50YWJsZXMpOyBpKysgKQ0KLSAgICB7DQotICAgICAgICB1bnNpZ25lZCBsb25nIHN0 YXJ0ID0gUEZOX0RPV04odm1zaXhfdGFibGVfYWRkcihwZGV2LT52cGNpLCBpKSk7DQotICAgICAg ICB1bnNpZ25lZCBsb25nIGVuZCA9IFBGTl9ET1dOKHZtc2l4X3RhYmxlX2FkZHIocGRldi0+dnBj aSwgaSkgKw0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2bXNpeF90YWJs ZV9zaXplKHBkZXYtPnZwY2ksIGkpIC0gMSk7DQotDQotICAgICAgICBmb3IgKCBqID0gMDsgaiA8 IEFSUkFZX1NJWkUoaGVhZGVyLT5iYXJzKTsgaisrICkNCi0gICAgICAgIHsNCi0gICAgICAgICAg ICBjb25zdCBzdHJ1Y3QgdnBjaV9iYXIgKmJhciA9ICZoZWFkZXItPmJhcnNbal07DQotDQotICAg ICAgICAgICAgaWYgKCByYW5nZXNldF9pc19lbXB0eShiYXItPm1lbSkgKQ0KLSAgICAgICAgICAg ICAgICBjb250aW51ZTsNCi0NCi0gICAgICAgICAgICByYyA9IHJhbmdlc2V0X3JlbW92ZV9yYW5n ZShiYXItPm1lbSwgc3RhcnQsIGVuZCk7DQotICAgICAgICAgICAgaWYgKCByYyApDQotICAgICAg ICAgICAgew0KLSAgICAgICAgICAgICAgICBncHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KLSAgICAg ICAgICAgICAgICAgICAgICAgIiVwcDogZmFpbGVkIHRvIHJlbW92ZSBNU0lYIHRhYmxlIFslbHgs ICVseF06ICVkXG4iLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICZwZGV2LT5zYmRmLCBzdGFy dCwgZW5kLCByYyk7DQotICAgICAgICAgICAgICAgIHJldHVybiByYzsNCi0gICAgICAgICAgICB9 DQotICAgICAgICB9DQotICAgIH0NCisjaWZkZWYgQ09ORklHX0hBU19QQ0lfTVNJDQorICAgIHJj ID0gdnBjaV9yZW1vdmVfbXNpeF9yZWdpb25zKHBkZXYpOw0KKyAgICBpZiAoIHJjICkNCisgICAg ICAgIHJldHVybiByYzsNCisjZW5kaWYNCiANCiAgICAgLyoNCiAgICAgICogQ2hlY2sgZm9yIG92 ZXJsYXBzIHdpdGggb3RoZXIgQkFScy4gTm90ZSB0aGF0IG9ubHkgQkFScyB0aGF0IGFyZQ0KZGlm ZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4 LmMNCmluZGV4IDA1MDU2YjVlYTEuLjRhMWU3NTYxZjYgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVy cy92cGNpL21zaXguYw0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCkBAIC01OTAsNiAr NTkwLDQxIEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgaHZtX21taW9fb3BzIHZwY2lfbXNpeF90YWJs ZV9vcHMgPSB7DQogICAgIC53cml0ZSA9IG1zaXhfd3JpdGUsDQogfTsNCiANCitpbnQgdnBjaV9y ZW1vdmVfbXNpeF9yZWdpb25zKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KK3sNCisgICAg Y29uc3Qgc3RydWN0IHZwY2lfbXNpeCAqbXNpeCA9IHBkZXYtPnZwY2ktPm1zaXg7DQorICAgIHN0 cnVjdCB2cGNpX2hlYWRlciAqaGVhZGVyID0gJnBkZXYtPnZwY2ktPmhlYWRlcjsNCisgICAgdW5z aWduZWQgaW50IGksIGo7DQorICAgIGludCByYzsNCisNCisgICAgLyogUmVtb3ZlIGFueSBNU0lY IHJlZ2lvbnMgaWYgcHJlc2VudC4gKi8NCisgICAgZm9yICggaSA9IDA7IG1zaXggJiYgaSA8IEFS UkFZX1NJWkUobXNpeC0+dGFibGVzKTsgaSsrICkNCisgICAgew0KKyAgICAgICAgdW5zaWduZWQg bG9uZyBzdGFydCA9IFBGTl9ET1dOKHZtc2l4X3RhYmxlX2FkZHIocGRldi0+dnBjaSwgaSkpOw0K KyAgICAgICAgdW5zaWduZWQgbG9uZyBlbmQgPSBQRk5fRE9XTih2bXNpeF90YWJsZV9hZGRyKHBk ZXYtPnZwY2ksIGkpICsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1z aXhfdGFibGVfc2l6ZShwZGV2LT52cGNpLCBpKSAtIDEpOw0KKw0KKyAgICAgICAgZm9yICggaiA9 IDA7IGogPCBBUlJBWV9TSVpFKGhlYWRlci0+YmFycyk7IGorKyApDQorICAgICAgICB7DQorICAg ICAgICAgICAgY29uc3Qgc3RydWN0IHZwY2lfYmFyICpiYXIgPSAmaGVhZGVyLT5iYXJzW2pdOw0K Kw0KKyAgICAgICAgICAgIGlmICggcmFuZ2VzZXRfaXNfZW1wdHkoYmFyLT5tZW0pICkNCisgICAg ICAgICAgICAgICAgY29udGludWU7DQorDQorICAgICAgICAgICAgcmMgPSByYW5nZXNldF9yZW1v dmVfcmFuZ2UoYmFyLT5tZW0sIHN0YXJ0LCBlbmQpOw0KKyAgICAgICAgICAgIGlmICggcmMgKQ0K KyAgICAgICAgICAgIHsNCisgICAgICAgICAgICAgICAgZ3ByaW50ayhYRU5MT0dfV0FSTklORywN CisgICAgICAgICAgICAgICAgICAgICAgICIlcHA6IGZhaWxlZCB0byByZW1vdmUgTVNJWCB0YWJs ZSBbJWx4LCAlbHhdOiAlZFxuIiwNCisgICAgICAgICAgICAgICAgICAgICAgICAmcGRldi0+c2Jk Ziwgc3RhcnQsIGVuZCwgcmMpOw0KKyAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQorICAgICAg ICAgICAgfQ0KKyAgICAgICAgfQ0KKyAgICB9DQorDQorICAgIHJldHVybiAwOw0KK30NCisNCiBp bnQgdnBjaV9tYWtlX21zaXhfaG9sZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiB7DQog ICAgIHN0cnVjdCBkb21haW4gKmQgPSBwZGV2LT5kb21haW47DQpkaWZmIC0tZ2l0IGEveGVuL2Ry aXZlcnMvdnBjaS9wcml2YXRlLmggYi94ZW4vZHJpdmVycy92cGNpL3ByaXZhdGUuaA0KaW5kZXgg MjkwN2Y2YjQwZi4uYTE2M2VmZThmZiAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvcHJp dmF0ZS5oDQorKysgYi94ZW4vZHJpdmVycy92cGNpL3ByaXZhdGUuaA0KQEAgLTg3LDYgKzg3LDgg QEAgdm9pZCBjZl9jaGVjayB2cGNpX2h3X3dyaXRlMTYoDQogICAgIGNvbnN0IHN0cnVjdCBwY2lf ZGV2ICpwZGV2LCB1bnNpZ25lZCBpbnQgcmVnLCB1aW50MzJfdCB2YWwsIHZvaWQgKmRhdGEpOw0K IA0KICNpZmRlZiBfX1hFTl9fDQoraW50IHZwY2lfcmVtb3ZlX21zaXhfcmVnaW9ucyhjb25zdCBz dHJ1Y3QgcGNpX2RldiAqcGRldik7DQorDQogLyogTWFrZSBzdXJlIHRoZXJlJ3MgYSBob2xlIGlu IHRoZSBwMm0gZm9yIHRoZSBNU0lYIG1taW8gYXJlYXMuICovDQogaW50IHZwY2lfbWFrZV9tc2l4 X2hvbGUoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KIA0KLS0gDQoyLjU1LjANCg== From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:28:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:28:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461216.1672196 (Exim 4.92) (envelope-from ) id 1xLJo5-0001e6-0g; Mon, 26 Oct 2026 12:28:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461216.1672196; Mon, 26 Oct 2026 12:28: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 1xLJo4-0001dh-Nv; Mon, 26 Oct 2026 12:28:04 +0000 Received: by outflank-mailman (input) for mailman id 1461216; Mon, 26 Oct 2026 12:28:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLJo3-0001Tf-1A for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:28:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJo2-000Htn-Dc for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:28:02 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4735-2eae-0a2a0a5409dd-0a2a450bcd94-24 for ; Mon, 26 Oct 2026 13:28:02 +0100 Received: from [40.107.162.83] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4751-b7e8-0a2a450b0019-286ba2532f5d-5 for ; Mon, 26 Oct 2026 13:28:02 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by DB9PR03MB7793.eurprd03.prod.outlook.com (2603:10a6:10:2be::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 12:28:00 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0546.019; Mon, 26 Oct 2026 12:28: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=IG4FolDwOTv/L8Eu2sO8Vfl4DfmVWVUiAQSZA9d1Wp07Y9k9u+8TgSzrK1M9rs3Vb+LbjOoWN2D6yWUZXK2j7xTAltqReiC/5ajvGI/m5zD0CoCbGza+I6IkkuzkASTzm+mWXM32XIOI+S5ZajXkLNeQ4+ozFmlo9DwqfWUIXG7jgJ/F3kOQgz6XvpbLzMi5/Vgazz1fhR39ks310nGfwkQ4l5Sh3IV2RFH0bVyBJ4T1X4I5h8FeaC+EqHjrvImBU+8JxrEN8Q4vsf+jHLmCi5JquL8zL3od6nVLzCugoW/WwKDW+8BxvUqWKjNlcwF0AZfe2pbGEvRDO/4z2QdWkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XxPz9fAW4k+o2b3KErd9e8gSA7RABkWRKMRB3aHqN6g=; b=oaXXAKv+NKxKHph0S9h9tkQG0GxqDGrXVKHcBXeI8aG+VtKh7dPFS/qoII2SfL7PNMuplcoW35ptsSNIRA1wSvFTQcPU2T2pmZTOK3nMY4yMkPEs2PNlAEotSVLBh4tHNSBOIk1cpG+UvuPoZsDfja5E9HwQEIYxQg9QlXWvkuqZJT/UmqDfNqwqlw317xw/Bdk/l6JoVug7/uEHZGRMjr/h8CKfHJ7HdVfoWljwBPWKtdSyvFhIWdKxlWQeWjL81/lmwckUkKay+ssqVnoMUqIiFMOiNnhetQVuZpLx3Q/jCdHKwkwyea+7zWrZi7iUiJTuKQxJNev9I0OHa59Ziw== 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=XxPz9fAW4k+o2b3KErd9e8gSA7RABkWRKMRB3aHqN6g=; b=AgPXHEBWjOhzrnmlF3Fd8U7K5A1RUQZzE0kpz7xdaoZTLndag4D5fgv+UZy5R9dtYw0rovbGELaYXmOMBisTJp10TIbjNuulWzZyvdcTJpUDSWi+HZL9k565P6S30tzJ9HMwSFj/rUfJ+s3/qq8svdB20Lhop0lubRcLQj+972lVjbvgiLH7zYj6TBN9DNmd05u5VBdAl/uLIEO8O3uPf/LTXXlvhC5hqUY4KoytWuzwB2GyZcbFtu3L6xCygFExsCjsaxhFHI37VpsZ9RqY75SL2fINrtJOVjWN6RByBiTwwy+Ay8IS1wWKKncEPGN1GNaVOg4bQbBO529g4HQw7Q== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Rahul Singh , Jan Beulich , Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand , Mykyta Poturai Subject: [PATCH v1 1/3] vpci/msix: move helpers to common Thread-Topic: [PATCH v1 1/3] vpci/msix: move helpers to common Thread-Index: AQHdZUVw86OFDAh+gU+B9obs/ZE7IA== Date: Mon, 26 Oct 2026 12:27:59 +0000 Message-ID: <688f3bb393590fc5bfb54328112fde1359bf44c4.1793012250.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: AS2PR03MB9076:EE_|DB9PR03MB7793:EE_ x-ms-office365-filtering-correlation-id: f13edb1a-6a4c-416e-964f-08df335c92b4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|22082099003|18002099003|56012099006|5023799004|11063799006|261022075727099003|261021121427099003|10067099003|261009223027099003|261021123027099003|261022105027099003|38070700021; x-microsoft-antispam-message-info: dmo/Xz3CoaPFf8MD2TJ6zHI7+PugampzV23zJuCm4L9g+EBvORoUpX6PctWMynQ28F1giZnVpIELYN81xn4o3cFNr/8O+wHfvMdiEPgOywNDxsHEnYzVahnq32+dlI1saXust+cH2T5y3Np2oMRf8TF/yVWDopt2+ceGvPqU01vGpKnvSHOZBeTqVglU6piioKlLQQpKWlEbgAiKk8nTEc09dR87X2K96zA7jxvPcIaoGlJhgZ0J9bx/qJ5YKnPEjIA7IUs/gMf5jRQUGmvc0dhw1ZxgD/V155AoPXjAb1zQmzfH+lGBA6NUl5YNAIeNRVK5dxB2krUeufG3ehtheezNeeLPePNMg/Epv1+BoYb6qRmDzP+Z2P7NZMP+DCetKwUIZHLW450HPEhmYYvRBXbDwADoXe5ZW/tzAfAOaBd87rE/Nbw+D6V8MpdgkDyjJ78rUuQ6X0ASW3IlHojWAKEv3knn9ZMFBSyAB1jo4zeMsc1t+uP4+NaOzpBwyVcJ/o3OG1ynPfhHVovokMnLk9McN3J3wvsUIzcEzglvAINYbQghS5DNK7FIzbrpTS5t6B8E7AmZyOjuOcvVjCUopfjD8VtpzUSMw75RzJGOTkT5g1PKLeOdHMsRmAPVlMNfOqaR0dv2D6jM6x2B6GT3WKoJiL3py6ZQZZwFj0EjL25CQrq/BmDMQ4nCU0JRjT2fVnZDlNwFObQFuf5kIiNyBwbtYMB0rzjZCL48kTcYVrU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(22082099003)(18002099003)(56012099006)(5023799004)(11063799006)(261022075727099003)(261021121427099003)(10067099003)(261009223027099003)(261021123027099003)(261022105027099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?M1JWcThHRzdmK0F3aTFKeDJvbEN0V2NScXBJVUE3QWZkRmFBVkxyelRLQnls?= =?utf-8?B?cndJeXFYTXRaTm9pRUNXVzMxTGxURldTbzlMTnBIRFBOM3N0YzNNa2E4cGI1?= =?utf-8?B?K0szR2RocHlGUy9Jb1ljQUdBUWxMU01ScVZvMzZ5R0pPeDJiNExqYWo5Mmha?= =?utf-8?B?Z1h3RzA0b1hsdmtRWEdYaUw5WHpscmx5VzUwQ0xqM1BmNmhScUZ0SDMzb2NV?= =?utf-8?B?WW9KaHNwZ1pXTk5FbWFOUDhuSjJ0THowSTB0a0RDdTlQUmdrRkYybFZtUERw?= =?utf-8?B?V0I0Znc5amRQVUhjTHZCK2tGaENWM2toM0pNclZ4b0ZlK25IZkIramgzeEpY?= =?utf-8?B?YlBQek8wdHU1VkJ3ZEJMcFNHVDloay8rRS9kMmQ4cSs0QlAyYS8reXFYQ1pt?= =?utf-8?B?VmNhYUVDZHhIT0k1eXU3QlN6ajBiWVAzNUFLVld2dlg0ZHFSNFdodno5SnVR?= =?utf-8?B?THZWWUdqYU5lK2s2cUU0YUhrZ2dSVm9kU0M4Mk4ySndJOGNrYTJ3T0JaWTdW?= =?utf-8?B?N0VVYXBZWDhUNVdCcXhucmg4bkhEVlhQaWhzZmhESXVSS2pPMm1Nbm5FUjlJ?= =?utf-8?B?WHhvVGYxcVcxL0ErYjhkTDY1MzNNTDdxY0RrM2o0WlU0UnJzT1hhRWpVM09F?= =?utf-8?B?OXN1NzYyTVFRMTVDWDNTc0M0dE91bHA0cFF1UzAzRDR5TlBqOFJQcVRYSnRV?= =?utf-8?B?dHlLdk5RdHJoN0NuM1pQMU9XZjJrUkh2aTNSR0MwOUUwUEQ2MzlhcUdPOGl0?= =?utf-8?B?dmtsNW5XSmFob0tLUnBRaFB5VmptU09LaTFJb1dobEZyRzFwMEtXbGMwL0Zs?= =?utf-8?B?b0dYWnVJTjBtZ2RSU1lPWmhQTmZhTWxhaEtpLy9jNDh1YjBMSnpaYnRmV0JH?= =?utf-8?B?aWgrdnU1U0dHMXR6ZFhJN0pmbVA3THlwWG85WXFpMkpBRXVtWElVMjY5WkZo?= =?utf-8?B?TTRPeGN0S08yMTladmpLR3dhamU3WjRZMUsrZkoyVHpqUEJOaDRNTERwZ1Q4?= =?utf-8?B?MERaQ0MxeHFacGZBTGlXSGtZWXpSR3M0N1h6M0hnc0l4bmdZOGt6TFd4T09m?= =?utf-8?B?aFNFUkxOZlM5cDB6V0RzTSt0eTZ2Unk0eXFseUVkOWJmNTZDQVo1djk3dXpK?= =?utf-8?B?MlYrU2d2OTAvbDh1eFd0a0I1OVVOL0VZM1J2YXBBaE5IZVNIOFdMdmVNMlhM?= =?utf-8?B?bXRzVUhyZCtYWERxdStQRmJRMHF1UjBKRXYzVzJicENNRDVPNWxpMEVqR3dD?= =?utf-8?B?cmRUa3BFcTNhdjl0K3NYODhZQlA3cmpsYmFKNXMvbkZrbE5jaHJaa0RhaHkw?= =?utf-8?B?VjZ0T1lYOTdOeC9FV1JESXgxV3huUEhlN09pSUtVV21lV3JmaUZuUkcvNVZM?= =?utf-8?B?Zm1ibHJ5TXRBWm9DNTh1a1BoOWRaTjEwWG5iNlFCK1BaTXZRcEwrWDRoVEF4?= =?utf-8?B?OTErdGhZeStjUUVEZFdLQTI5RHpUcTByS2xTcStDajhUdlU4TUxqejkvQ1FK?= =?utf-8?B?WU9VNVZZaVFBYmpDZGZNNGtBTWd1bzZ0aitxQmZ3d0ZuSmN0WDhtOGw5MFgz?= =?utf-8?B?enpRSDdtK0toSm4zbmtuL25PeitSengwYTI0c0NUVmtLb2Z1cWMzb29yWERU?= =?utf-8?B?QnZTVndjWDhFNHNVU3N0d254a1BqZ1RaQW5CdUFPTUFhcHQ4bWNlSnNQR3FN?= =?utf-8?B?VVFmTjA3dVZIQXlDQnlVeVhhTlh5UGpPQ0lmRDA1YXNLUFcrczBQeE8xU0R2?= =?utf-8?B?eUcxSWVhYlZwbzFLVGpCdm1JYzJKZmVZNklEZ3lQSnd3YWxJdHZNNVQ2d1NE?= =?utf-8?B?OUNXOGpUVTFmN3VxLzVsUlRHekZaVENXeXk2QXU3eUN5RWg4WTBVQ2Ixc1kw?= =?utf-8?B?SG1la3FYdi90eEo1OEFialdodG9RTk9ndDhveTdnTVAzQTR6UTRHTTNVRG9q?= =?utf-8?B?RW1xSHRvVkhxbWVIZ2hQdTRxeU9TNEJwUUpFajZrTWl4Q3ZJL3FLeXA0c0Jw?= =?utf-8?B?eDhtMHVJN1lhYWZqVXhETzRXekRVU1hHQjN6bzR3MzJFbDhsUkpxWENyWkdM?= =?utf-8?B?VFhZMTkvOWlRU0VKY3hSV2pDWmhNdlZXSnA1RmtkTWdDaWFtU3YzVEdFK2ls?= =?utf-8?B?b0hrRTlOVkZIN2tCQzlwMFhpSmZ2eUdtM3Y0UEx2TFFtRUZzeUlITVc5bExv?= =?utf-8?B?SFBEbzM1dTM4Q2xybW52VFg1TlkvdDdsR0Nka3hWUXA3ZVlLTjNndWdqNncr?= =?utf-8?B?Q2cwT0Zneit0VThhcXBRR2s5WWtlUUZzYk85Q1JYdDlVaHlXOEpqYkRoT1hQ?= =?utf-8?B?dHBsTlNWTC9oQ3dzV3Y1UHcrZFZQK3NBYmNzZURvOW96a3VvLy9lV1A3Ymk2?= =?utf-8?Q?tQzra82Kxp5XrwFg=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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f13edb1a-6a4c-416e-964f-08df335c92b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 12:27:59.9861 (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: 0RoQ9lc3cTkBaXl5U0zEYLKtjk6BMzt2NBJi5wgM390maHgi1qO80Ny9Fh/ID1AFFfZtYv+wzuhbSuWHZpaimw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7793 X-purgate-ID: tlsNG-42698a/1793017682-A96C29EA-C34772D2/0/0 X-purgate-type: clean X-purgate-size: 7234 RnJvbTogUmFodWwgU2luZ2ggPHJhaHVsLnNpbmdoQGFybS5jb20+DQoNCnZQQ0kgTVNJLVggaGVs cGVycyB0byBiZSB1c2VkIG9uIEFybSBhcmUgbW92ZWQgdG8gYSBjb21tb24gaGVhZGVyLg0KDQpT aWduZWQtb2ZmLWJ5OiBSYWh1bCBTaW5naCA8cmFodWwuc2luZ2hAYXJtLmNvbT4NClNpZ25lZC1v ZmYtYnk6IFN0ZXdhcnQgSGlsZGVicmFuZCA8c3Rld2FydC5oaWxkZWJyYW5kQGFtZC5jb20+DQpT aWduZWQtb2ZmLWJ5OiBNeWt5dGEgUG90dXJhaSA8bXlreXRhX3BvdHVyYWlAZXBhbS5jb20+DQot LS0NCiB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNpLmggICAgICB8IDIxIC0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIHhlbi9hcmNoL3g4Ni9tc2kuYyAgICAgICAgICAgICAgICAgIHwgIDIgKy0N CiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXUuaCB8ICAyICstDQogeGVuL2RyaXZl cnMvdnBjaS9tc2kuYyAgICAgICAgICAgICAgfCAgMyArLS0NCiB4ZW4vZHJpdmVycy92cGNpL21z aXguYyAgICAgICAgICAgICB8ICAyICstDQogeGVuL2luY2x1ZGUveGVuL21zaS5oICAgICAgICAg ICAgICAgfCAyMSArKysrKysrKysrKysrKysrKysrKysNCiA2IGZpbGVzIGNoYW5nZWQsIDI1IGlu c2VydGlvbnMoKyksIDI2IGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2 L2luY2x1ZGUvYXNtL21zaS5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL21zaS5oDQppbmRl eCA2ZmI2NjNiMmU3Li44MThmYTcyOTI4IDEwMDY0NA0KLS0tIGEveGVuL2FyY2gveDg2L2luY2x1 ZGUvYXNtL21zaS5oDQorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNpLmgNCkBAIC0x NDcsMjcgKzE0Nyw2IEBAIGludCBtc2lfZnJlZV9pcnEoc3RydWN0IG1zaV9kZXNjICplbnRyeSk7 DQogICovDQogI2RlZmluZSBOUl9IUF9SRVNFUlZFRF9WRUNUT1JTIAkyMA0KIA0KLSNkZWZpbmUg bXNpX2NvbnRyb2xfcmVnKGJhc2UpCQkoKGJhc2UpICsgUENJX01TSV9GTEFHUykNCi0jZGVmaW5l IG1zaV9sb3dlcl9hZGRyZXNzX3JlZyhiYXNlKQkoKGJhc2UpICsgUENJX01TSV9BRERSRVNTX0xP KQ0KLSNkZWZpbmUgbXNpX3VwcGVyX2FkZHJlc3NfcmVnKGJhc2UpCSgoYmFzZSkgKyBQQ0lfTVNJ X0FERFJFU1NfSEkpDQotI2RlZmluZSBtc2lfZGF0YV9yZWcoYmFzZSwgaXM2NGJpdCkJXA0KLQko KGJhc2UpICsgKChpczY0Yml0KSA/IFBDSV9NU0lfREFUQV82NCA6IFBDSV9NU0lfREFUQV8zMikp DQotI2RlZmluZSBtc2lfbWFza19iaXRzX3JlZyhiYXNlLCBpczY0Yml0KSBcDQotCSgoYmFzZSkg KyBQQ0lfTVNJX01BU0tfQklUIC0gKChpczY0Yml0KSA/IDAgOiA0KSkNCi0jZGVmaW5lIG1zaV9w ZW5kaW5nX2JpdHNfcmVnKGJhc2UsIGlzNjRiaXQpIFwNCi0JKChiYXNlKSArIFBDSV9NU0lfTUFT S19CSVQgKyAoKGlzNjRiaXQpID8gNCA6IDApKQ0KLSNkZWZpbmUgbXVsdGlfbXNpX2NhcGFibGUo Y29udHJvbCkgXA0KLQkoMVUgPDwgTUFTS19FWFRSKGNvbnRyb2wsIFBDSV9NU0lfRkxBR1NfUU1B U0spKQ0KLSNkZWZpbmUgbXVsdGlfbXNpX2VuYWJsZShjb250cm9sLCBudW0pIFwNCi0JKChjb250 cm9sKSB8PSBNQVNLX0lOU1IoZmxzKG51bSkgLSAxLCBQQ0lfTVNJX0ZMQUdTX1FTSVpFKSkNCi0j ZGVmaW5lIGlzXzY0Yml0X2FkZHJlc3MoY29udHJvbCkJKCEhKChjb250cm9sKSAmIFBDSV9NU0lf RkxBR1NfNjRCSVQpKQ0KLSNkZWZpbmUgaXNfbWFza19iaXRfc3VwcG9ydChjb250cm9sKQkoISEo KGNvbnRyb2wpICYgUENJX01TSV9GTEFHU19NQVNLQklUKSkNCi0NCi0jZGVmaW5lIG1zaXhfY29u dHJvbF9yZWcoYmFzZSkJCSgoYmFzZSkgKyBQQ0lfTVNJWF9GTEFHUykNCi0jZGVmaW5lIG1zaXhf dGFibGVfb2Zmc2V0X3JlZyhiYXNlKQkoKGJhc2UpICsgUENJX01TSVhfVEFCTEUpDQotI2RlZmlu ZSBtc2l4X3BiYV9vZmZzZXRfcmVnKGJhc2UpCSgoYmFzZSkgKyBQQ0lfTVNJWF9QQkEpDQotI2Rl ZmluZSBtc2l4X3RhYmxlX3NpemUoY29udHJvbCkgCSgoKGNvbnRyb2wpICYgUENJX01TSVhfRkxB R1NfUVNJWkUpICsgMSkNCi0NCiAvKg0KICAqIE1TSSBEZWZpbmVkIERhdGEgU3RydWN0dXJlcw0K ICAqLw0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tc2kuYyBiL3hlbi9hcmNoL3g4Ni9tc2ku Yw0KaW5kZXggODgzMWNlMDY4Yy4uNWU0ZTg5YjNjMCAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL3g4 Ni9tc2kuYw0KKysrIGIveGVuL2FyY2gveDg2L21zaS5jDQpAQCAtMjEsNiArMjEsNyBAQA0KICNp bmNsdWRlIDx4ZW4vaW9jYXAuaD4NCiAjaW5jbHVkZSA8eGVuL2tleWhhbmRsZXIuaD4NCiAjaW5j bHVkZSA8eGVuL3Bmbi5oPg0KKyNpbmNsdWRlIDx4ZW4vbXNpLmg+DQogDQogI2luY2x1ZGUgPGFz bS9hcGljLmg+DQogI2luY2x1ZGUgPGFzbS9nZW5hcGljLmg+DQpAQCAtMjksNyArMzAsNiBAQA0K ICNpbmNsdWRlIDxhc20vaXJxLXZlY3RvcnMuaD4NCiAjaW5jbHVkZSA8YXNtL3NtcC5oPg0KICNp bmNsdWRlIDxhc20vZGVzYy5oPg0KLSNpbmNsdWRlIDxhc20vbXNpLmg+DQogI2luY2x1ZGUgPGFz bS9maXhtYXAuaD4NCiAjaW5jbHVkZSA8YXNtL3AybS5oPg0KIA0KZGlmZiAtLWdpdCBhL3hlbi9k cml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdS5oIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gv YW1kL2lvbW11LmgNCmluZGV4IDUyZjc0ODMxMGIuLmJhMjI1MDZmNTggMTAwNjQ0DQotLS0gYS94 ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXUuaA0KKysrIGIveGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvYW1kL2lvbW11LmgNCkBAIC0yNiw4ICsyNiw4IEBADQogI2luY2x1ZGUgPHhlbi90 YXNrbGV0Lmg+DQogI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KICNpbmNsdWRlIDx4ZW4vZG9tYWlu X3BhZ2UuaD4NCisjaW5jbHVkZSA8eGVuL21zaS5oPg0KIA0KLSNpbmNsdWRlIDxhc20vbXNpLmg+ DQogI2luY2x1ZGUgPGFzbS9hcGljZGVmLmg+DQogDQogI2luY2x1ZGUgImlvbW11LWRlZnMuaCIN CmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL21zaS5jIGIveGVuL2RyaXZlcnMvdnBjaS9t c2kuYw0KaW5kZXggZjczNjA1NGIyYi4uMGVkMzlhNmRlOSAxMDA2NDQNCi0tLSBhL3hlbi9kcml2 ZXJzL3ZwY2kvbXNpLmMNCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvbXNpLmMNCkBAIC0xOCwxMSAr MTgsMTAgQEANCiANCiAjaW5jbHVkZSAicHJpdmF0ZS5oIg0KIA0KKyNpbmNsdWRlIDx4ZW4vbXNp Lmg+DQogI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KICNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPg0K IA0KLSNpbmNsdWRlIDxhc20vbXNpLmg+DQotDQogc3RhdGljIHVpbnQzMl90IGNmX2NoZWNrIGNv bnRyb2xfcmVhZCgNCiAgICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGlu dCByZWcsIHZvaWQgKmRhdGEpDQogew0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvbXNp eC5jIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCmluZGV4IDViMDE4NTlhY2YuLjA1MDU2YjVl YTEgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92cGNpL21zaXguYw0KKysrIGIveGVuL2RyaXZl cnMvdnBjaS9tc2l4LmMNCkBAIC0yMSw5ICsyMSw5IEBADQogDQogI2luY2x1ZGUgPHhlbi9pby5o Pg0KICNpbmNsdWRlIDx4ZW4vbGliLmg+DQorI2luY2x1ZGUgPHhlbi9tc2kuaD4NCiAjaW5jbHVk ZSA8eGVuL3NjaGVkLmg+DQogDQotI2luY2x1ZGUgPGFzbS9tc2kuaD4NCiAjaW5jbHVkZSA8YXNt L3AybS5oPg0KICNpbmNsdWRlIDxhc20veDg2X2VtdWxhdGUuaD4NCiANCmRpZmYgLS1naXQgYS94 ZW4vaW5jbHVkZS94ZW4vbXNpLmggYi94ZW4vaW5jbHVkZS94ZW4vbXNpLmgNCmluZGV4IGM5MDNk MDA1MGMuLjRlOTIyOTY1ZGUgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vbXNpLmgNCisr KyBiL3hlbi9pbmNsdWRlL3hlbi9tc2kuaA0KQEAgLTcsNiArNywyNyBAQA0KIA0KICNpbmNsdWRl IDxhc20vbXNpLmg+DQogDQorI2RlZmluZSBtc2lfY29udHJvbF9yZWcoYmFzZSkJCSgoYmFzZSkg KyBQQ0lfTVNJX0ZMQUdTKQ0KKyNkZWZpbmUgbXNpX2xvd2VyX2FkZHJlc3NfcmVnKGJhc2UpCSgo YmFzZSkgKyBQQ0lfTVNJX0FERFJFU1NfTE8pDQorI2RlZmluZSBtc2lfdXBwZXJfYWRkcmVzc19y ZWcoYmFzZSkJKChiYXNlKSArIFBDSV9NU0lfQUREUkVTU19ISSkNCisjZGVmaW5lIG1zaV9kYXRh X3JlZyhiYXNlLCBpczY0Yml0KQlcDQorCSgoYmFzZSkgKyAoKGlzNjRiaXQpID8gUENJX01TSV9E QVRBXzY0IDogUENJX01TSV9EQVRBXzMyKSkNCisjZGVmaW5lIG1zaV9tYXNrX2JpdHNfcmVnKGJh c2UsIGlzNjRiaXQpIFwNCisJKChiYXNlKSArIFBDSV9NU0lfTUFTS19CSVQgLSAoKGlzNjRiaXQp ID8gMCA6IDQpKQ0KKyNkZWZpbmUgbXNpX3BlbmRpbmdfYml0c19yZWcoYmFzZSwgaXM2NGJpdCkg XA0KKwkoKGJhc2UpICsgUENJX01TSV9NQVNLX0JJVCArICgoaXM2NGJpdCkgPyA0IDogMCkpDQor I2RlZmluZSBtdWx0aV9tc2lfY2FwYWJsZShjb250cm9sKSBcDQorCSgxVSA8PCBNQVNLX0VYVFIo Y29udHJvbCwgUENJX01TSV9GTEFHU19RTUFTSykpDQorI2RlZmluZSBtdWx0aV9tc2lfZW5hYmxl KGNvbnRyb2wsIG51bSkgXA0KKwkoKGNvbnRyb2wpIHw9IE1BU0tfSU5TUihmbHMobnVtKSAtIDEs IFBDSV9NU0lfRkxBR1NfUVNJWkUpKQ0KKyNkZWZpbmUgaXNfNjRiaXRfYWRkcmVzcyhjb250cm9s KQkoISEoKGNvbnRyb2wpICYgUENJX01TSV9GTEFHU182NEJJVCkpDQorI2RlZmluZSBpc19tYXNr X2JpdF9zdXBwb3J0KGNvbnRyb2wpCSghISgoY29udHJvbCkgJiBQQ0lfTVNJX0ZMQUdTX01BU0tC SVQpKQ0KKw0KKyNkZWZpbmUgbXNpeF9jb250cm9sX3JlZyhiYXNlKQkJKChiYXNlKSArIFBDSV9N U0lYX0ZMQUdTKQ0KKyNkZWZpbmUgbXNpeF90YWJsZV9vZmZzZXRfcmVnKGJhc2UpCSgoYmFzZSkg KyBQQ0lfTVNJWF9UQUJMRSkNCisjZGVmaW5lIG1zaXhfcGJhX29mZnNldF9yZWcoYmFzZSkJKChi YXNlKSArIFBDSV9NU0lYX1BCQSkNCisjZGVmaW5lIG1zaXhfdGFibGVfc2l6ZShjb250cm9sKSAJ KCgoY29udHJvbCkgJiBQQ0lfTVNJWF9GTEFHU19RU0laRSkgKyAxKQ0KKw0KIGludCBwZGV2X21z aXhfYXNzaWduKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCiBpbnQg cGRldl9tc2lfaW5pdChzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQogdm9pZCBwZGV2X21zaV9kZWlu aXQoc3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KLS0gDQoyLjU1LjANCg== From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:28:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:28:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461217.1672199 (Exim 4.92) (envelope-from ) id 1xLJo5-0001jL-8P; Mon, 26 Oct 2026 12:28:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461217.1672199; Mon, 26 Oct 2026 12: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 1xLJo5-0001iM-1M; Mon, 26 Oct 2026 12:28:05 +0000 Received: by outflank-mailman (input) for mailman id 1461217; Mon, 26 Oct 2026 12:28:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLJo3-0001Tp-An for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:28:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJo2-000Htn-Lx for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:28:02 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4735-2eae-0a2a0a5409dd-0a2a450bcd94-26 for ; Mon, 26 Oct 2026 13:28:02 +0100 Received: from [40.107.162.83] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4751-b7e8-0a2a450b0019-286ba2532f5d-6 for ; Mon, 26 Oct 2026 13:28:02 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by DB9PR03MB7793.eurprd03.prod.outlook.com (2603:10a6:10:2be::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 12:28:00 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0546.019; Mon, 26 Oct 2026 12:28: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=Y9HPhoewhiWrTwoLketj5hxz1OSZIhN8grJz0tQNIGQc0KEH5Q76Vd0BuDuWJJ3jlt+TNzzlbUAsx9WyGnTjsKgJ2O/WHEKjIF6jAyozRcKjeMLeeYQcpjDnhOdFJ1yZ68ZSrjIG+JBtYl3jIKwtZHNUPbN7LojJqWNVbnj9MpYrAGeChnTUQHtv48I3O1GhX7ZSVgtxdxAD3K6PEPVY2h8T7bqkIr2e7/9yb5pd+X8dLRq/x+Zjj5oVU/ldCpED45rvqB5puiQABz4KLXVTn4YpEK7aAEM7QMb4MWOsdT5DvwYCAzyszKCIuNjCpi7ed+R3a7gZXQU/U2yEiDa57A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R2kuvxglWSsodC2EQkNQevOPx8z5dsEueO1hQvrarGA=; b=CJijiP7/A8vGAuNwxiup6wxkfRnw76FrPsv0XqcyP6g8XjJ+se64jdPOCjc8/zVXbkukicwpmXM4Sl342eDNew4Bke13Hk+9BcgBa/+2Reah6005i+okUpTlyxADxCnmvVvgX0dldzArCYYlmpWViX89ao5zmbhmMoiMdPz+N5hYDqbhTdL0aXQ64sw/N7o932pnX4AxOdFJpdDJB2l0L13rEComQ3xQsFqHTrfFyS/afxbrUVMsxSkWRjjJKO9A4JOpPz3N8YtMAhrNry463s63hJjorPln0LiK2V43qrRZOVLRzK/vwo7yPXykcpJD+XN2p24i83vmZOEipIUO2Q== 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=R2kuvxglWSsodC2EQkNQevOPx8z5dsEueO1hQvrarGA=; b=JkP4FKnQGkNr+QFQ2tptjzSkfpRxNfxAPiGhsN00LvOnqy+2pKJHZNENBSOCHzoD2ziQVy4jRSXfxVU5eq+unCWcrxBaq6nuyxsgJtjtdSPHPF4WG66zGsqTlzfWAyFWUJQA/pV8MgWHcRecIlNpDpMxXCfs9qeq0i0yldKsqYsTFeQ1/mgm1TTaDl+DWnEKmZRVzHcWu/AXzGTEAPpyT6fBij0vk3hHFynRSFlB4sSTJ+oDMBoymtcNe6d5W5oCRny3Ocse/1U1P+l+CS3v7hfvIbo89q60gKYFPock9YUZGC5ED4alsDDZWWDCVE9ah1F7n8d0L3tGbiqXEVo//Q== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Mykyta Poturai Subject: [PATCH v1 3/3] vpci/msix: move common msix code to common file Thread-Topic: [PATCH v1 3/3] vpci/msix: move common msix code to common file Thread-Index: AQHdZUVwUMGkH3kGdkC4PzUi9GTbHA== Date: Mon, 26 Oct 2026 12:28:00 +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: 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: AS2PR03MB9076:EE_|DB9PR03MB7793:EE_ x-ms-office365-filtering-correlation-id: 02c9412a-266d-4971-3778-08df335c930d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|22082099003|18002099003|56012099006|11063799006|261022075727099003|261021121427099003|10067099003|261009223027099003|261021123027099003|261022105027099003|38070700021|260925022911599003|260925021911599003|260925021311599003; x-microsoft-antispam-message-info: AYRTw1YMRtYOv1T5ytbrrmW5ZTN7Cm7aRI087/Xijfv0EZNe+mwB+Hpg5gkCqMlc4yKBhE1PISZDt+lGldmz8EiQNSasAhfFpDSzHMa+hE7DPJDBZWpQDp/BacyDCTCMBcTRH1x/TQ5ZIUglgrAElUEBNTooooGu6055RTuLGm26kMur3Y6ZpINgfvdyd0e1/hbuvUSymMK86AjoIWOEXF/S7Ntwm9DYll6XMGRgVyUr1pnfRjrmbMTxrHr0MjewLPhteEVz5WD07Gax6CzU+SvDljjtGQNNlxwCn4XFOL+QE7MZLfOGxLLY5jZWPX4rfBvAQPSq1IHqCHzOQ964eWx3IFkf1tgNfEkOjVwfMLrx/Slvr+DWabhWt5Q7wiIlPpcd4VcaDvL0Z3PQLZxO950Pwtkb6u/P4mWZvCQ2HlIapdT0JXJd9V7hknApMAx1iyEx4U/F8AYmqdQyD3JFbXPmFBNaqonmzvs9rjoP2DrllOxaUW5Wc4ceQphQGDlVs+9LdASa64NTob0gJq8znhr0q9MiWOEK2YwdYeK8nXfxCHUTr2xDUXywgicKz1rbvulveACh8IY0z5YZRH3J1dP7CxKF5a04Ku1EPxhhxt7iJESZqAFHjR2EmCUfaqKEOOdlUsVURKbE0evNYYNbAmJg42q7MW5qg09Bpi80JorE+ayIB6iW7oBSCuo9UYoFpRoFdxv8rw9/LPBRz3KKSKcLfDua5m51GsxiShhNQsI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(6133799003)(22082099003)(18002099003)(56012099006)(11063799006)(261022075727099003)(261021121427099003)(10067099003)(261009223027099003)(261021123027099003)(261022105027099003)(38070700021)(260925022911599003)(260925021911599003)(260925021311599003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cnRHZWZRZEMrN1RpcVJNbDR6dnY2Q1gvVXZ6S3Rlaml4cFFvNDNpaUJEQkpa?= =?utf-8?B?UThIMXhYaWRSTmE3REY3c0ljNlFYNmZLa3RhSTJnL2NmRTg2ZVp0a2dMSzN5?= =?utf-8?B?MEJLVkFrNkVUaWt4Vlh5c20zRlVmVFpmTnF0RFd4K2RaV2V2NGJ2WlMveUE3?= =?utf-8?B?VEFVcFhFdDFzWm5IQ1dNMFk4UmZvNnRrb2NOcmFpcWxXSC9oUXBvaWVNNjMy?= =?utf-8?B?TUo1OTQwcmtZYTJQQVQyYk5BUWVSMVlPbysyWm0xSDRJL3k3RTJxN1RFa09m?= =?utf-8?B?ZnBCdVNsZWVDekNDNExRNkppZWVDbkFEcnhVMUQ0UUJORmlUSVhpelR2Qm9P?= =?utf-8?B?OG5UbW9EWlVla2VSc0pxZmN4ZVVEVHlka3c4TlJiUk9ZNk1ta0ZRTkhRVGtQ?= =?utf-8?B?YUN4QXF0RUxhMTJZUVNHMzZEQm5TdGxjQVZ1TG9ZN1h0R0Q1Q2hXSVdhdkZ6?= =?utf-8?B?MlowMVI0cmFady9jOWR5S3RXUkpPbHpOa2lCaGUrdVA3dEJ4cWdpKzQ3TXpE?= =?utf-8?B?WURRcjIzdlFOWnYxV2M1YWlWVm5vRGZUVkIrSllYSnBva1MzWjl4WjFUU1hR?= =?utf-8?B?ZVNteUpyekVHeW90UkJMMkNyYkhXL1FEOUlaT2lqZElNUkNpY09NR1hqd2Vy?= =?utf-8?B?OGM0dlRuNytleDJ6YnVNNlZSdkw0SjIwaXhueE9SQ2s2UmhMZmpYV3VTbitm?= =?utf-8?B?N05oc05JQ1JYalRBYSsza3AwMUFtTk5FMkZnVUlqbFN6Ujc4ZkhHU1hvbU1h?= =?utf-8?B?VEZqRGU0Zzl3QUpGVC9LbjRham5rMUFjVjBJa3BMNG5nQXViMTc0S0xQS0xl?= =?utf-8?B?YVZ2Q2tOalZJaERRZVRTdUZ5ZHE5MUVaMWFpMnBIQmxab2MwT002RWo0OWxC?= =?utf-8?B?TUhZbWxLUCsyMHNRZC9LWGhob0RGZVJsR0poakMyMW1BZHczdUhtL01NMkFC?= =?utf-8?B?SWkyOEY3Q005S2g5TXZiMkdBOGZVc3hBVVhIUUxpakpyNzBQTzVVTDBZYkxm?= =?utf-8?B?VlRpY1BHK1JEQ0tKS1A4a0JZQTZUaWorZEp2SlBBdkhNamZWM3JjZVdQSlpJ?= =?utf-8?B?Y1g3RzU4eWZ1RG03emRSYVVQNzVrbUdhREgwSC9ybjhOL1RFeDZDRktMV2F2?= =?utf-8?B?eHRCVmVYR0tyZ01PT1hYUVlvR0xEcG5wQWt4OHo2VEI4RGpnQ3NTZG1maEFN?= =?utf-8?B?MEVBMzZJWktCK2I4ajNxZmpKWDNocGNPdDllKzJaUnRBYzVjN1FlZmNBVUk5?= =?utf-8?B?L0FyLzNUVGdkNjAxVUpMUXdmRjBFM1ZSb2svNnV0QWkrdFI2VzNwUVJNNWxQ?= =?utf-8?B?VDl6aW1UYTdPWldkaTIvcURxMTNOT3lLRmltdDVMeW1PR05Rd1I4Qy9ySnJT?= =?utf-8?B?VGlsN1J0YW90UndxeVBqcjVMc21pS2xJcERIVWZ4ZEI1QW00d2NTNkNHRXJi?= =?utf-8?B?UlZsYmNxL2JvSitkajZldnNYNENVb3N3UHNWdG9FNm1UZW85Nk1LYXd1dzlT?= =?utf-8?B?R01qS0Y3MUVqejVHNVY3c3R1QWtwYk01R2NuMEdObURZTG5WWEF4QjdtcG90?= =?utf-8?B?b1dDbC9qNGhJWE05V1FXcWJFa2V0OXNmYWJJS0I4Q0xLTzRjSXhMcGZvaldh?= =?utf-8?B?ZjZqejE5NWptOGZBT3NFWGdZdzd2NTAwd2RFc3JlS0NJblFhL3NUVzlTY3VF?= =?utf-8?B?Tzh2aDBqVEtYV3lGSlBsVThKdWJTYVU2aVMzVkYzZk00NE1ZcEFqSkhBek1X?= =?utf-8?B?MFB3ZTNMZnBiM1h3YWxFY1JTczdnck81QklpYXFoT1BPWm9zL3gybU5qWWk0?= =?utf-8?B?Y0FDRE4zQUxSVGhQSjloa3p4akJURmRqU2phNWp6MmVIc0k5aWFnTDgyOUVG?= =?utf-8?B?djF5amFheit2eHc0UDdTUjdZZEx4N0plN09XeE1yOUVsb1BlZFEwZHZuczc3?= =?utf-8?B?c3BOejJ2Mm5oMWRRVERXUS85T0ZrUk5OMVpCQzBMOGJGLzlNRE96a21mNzd1?= =?utf-8?B?Yk90M1BaTWg1YUsxRFM1RnFmN1VvTVZ3Vmk2Rko4NWZ6K0Rja1dlbGh1aVJi?= =?utf-8?B?SzRlL0QvL1VDenhOa3NrL0ttc0dWYzlERHFKbmJERG5FVzYxYzYweCtCM0wr?= =?utf-8?B?UXhPNyt5azMzY2VqQXAxeFd6Nm14TWFGQWFwZzF1U1lQci9YU2pMSFBHV1lQ?= =?utf-8?B?YkFJZGp2bmxRQlZuYU9BQ0tqYm92eHQyTTR3ZStwR0FXRnJ5MEc1N2srYkp1?= =?utf-8?B?a2ZvMW0yajQ5MkkzNlRpVWh6QXhlVXRPakhvcC8xQnBYVEVBNS8rTk5aMXpT?= =?utf-8?B?QWp3VmxZR29JM3BraFQvU0s4VEZIYmhxNDJOeGVxWUtXek95MnFVUVU0VlVz?= =?utf-8?Q?MqxL95XPDtubPHO4=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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02c9412a-266d-4971-3778-08df335c930d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 12:28:00.6717 (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: kkfDyb7j/e6HhZaBuTEhAl337T4mapoJz8mgKkJB0zGr963WEN8ODBsF/u3GVvWelYoU3lUqBg0xwdUWD1KVIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7793 X-purgate-ID: tlsNG-42698a/1793017682-A90CD9EA-4CE22828/0/0 X-purgate-type: clean X-purgate-size: 21434 RnJvbTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCg0K dlBDSSBNU0ktWCBjb2RlIGRlYWxpbmcgd2l0aCBpbnRlcmNlcHRpbmcgdGhlIE1TSS1YIHRhYmxl cyBhbmQgUEJBIHdvbid0DQpiZSB1c2VkIG9uIEFybS4gTW92aW5nIHRoaXMgY29kZSB3b3VsZCBy ZXN1bHQgaW4gYSBsYXJnZSBkaWZmc3RhdCwgc28NCmluc3RlYWQgd2UgbW92ZSB0aGUgY29tbW9u IGNvZGUgdG8gYSBjb21tb24gbXNpeCBmaWxlIHRvIGFjaGlldmUgYQ0Kc21hbGxlciBkaWZmc3Rh dC4NCg0KU2lnbmVkLW9mZi1ieTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJh bmRAYW1kLmNvbT4NClNpZ25lZC1vZmYtYnk6IE15a3l0YSBQb3R1cmFpIDxteWt5dGFfcG90dXJh aUBlcGFtLmNvbT4NCi0tLQ0KIHhlbi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUgICAgICB8ICAgNiAr LQ0KIHhlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jICAgICAgICB8IDE2MCArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIHhlbi9kcml2ZXJzL3ZwY2kvbXNpeF9jb21tb24uYyB8IDIwMiArKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS94ZW4vdnBjaS5oICAgICAg ICAgfCAgIDUgKw0KIDQgZmlsZXMgY2hhbmdlZCwgMjE1IGluc2VydGlvbnMoKyksIDE1OCBkZWxl dGlvbnMoLSkNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMvdnBjaS9tc2l4X2NvbW1v bi5jDQoNCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlIGIveGVuL2RyaXZl cnMvdnBjaS9NYWtlZmlsZQ0KaW5kZXggOTc5M2E0ZjliMC4uYjQwMjZjZWM4MSAxMDA2NDQNCi0t LSBhL3hlbi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUNCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvTWFr ZWZpbGUNCkBAIC0xLDMgKzEsNyBAQA0KIG9iai15ICs9IGNhcC5vDQogb2JqLXkgKz0gdnBjaS5v IGhlYWRlci5vIHJlYmFyLm8NCi1vYmotJChDT05GSUdfSEFTX1BDSV9NU0kpICs9IG1zaS5vIG1z aXgubw0KK29iai0kKENPTkZJR19IQVNfUENJX01TSSkgKz0gbXNpLm8NCitvYmotJChDT05GSUdf SEFTX1BDSV9NU0kpICs9IG1zaXhfY29tbW9uLm8NCitpZmVxICgkKENPTkZJR19YODYpLHkpDQor b2JqLSQoQ09ORklHX0hBU19QQ0lfTVNJKSArPSBtc2l4Lm8NCitlbmRpZg0KZGlmZiAtLWdpdCBh L3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCmluZGV4 IDRhMWU3NTYxZjYuLmFiMDg1M2Y3MGQgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92cGNpL21z aXguYw0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCkBAIC0zNiwxNiArMzYsNiBAQA0K ICAgICAgUEZOX0RPV04oYWRkcikgPD0gUEZOX0RPV04odm1zaXhfdGFibGVfYWRkcih2cGNpLCBu cikgKyAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1z aXhfdGFibGVfc2l6ZSh2cGNpLCBucikgLSAxKSkNCiANCi1zdGF0aWMgdWludDMyX3QgY2ZfY2hl Y2sgY29udHJvbF9yZWFkKA0KLSAgICBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWdu ZWQgaW50IHJlZywgdm9pZCAqZGF0YSkNCi17DQotICAgIGNvbnN0IHN0cnVjdCB2cGNpX21zaXgg Km1zaXggPSBkYXRhOw0KLQ0KLSAgICByZXR1cm4gKG1zaXgtPm1heF9lbnRyaWVzIC0gMSkgfA0K LSAgICAgICAgICAgKG1zaXgtPmVuYWJsZWQgPyBQQ0lfTVNJWF9GTEFHU19FTkFCTEUgOiAwKSB8 DQotICAgICAgICAgICAobXNpeC0+bWFza2VkID8gUENJX01TSVhfRkxBR1NfTUFTS0FMTCA6IDAp Ow0KLX0NCi0NCiBzdGF0aWMgdm9pZCB1cGRhdGVfZW50cnkoc3RydWN0IHZwY2lfbXNpeF9lbnRy eSAqZW50cnksDQogICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCBwY2lfZGV2 ICpwZGV2LCB1bnNpZ25lZCBpbnQgbnIpDQogew0KQEAgLTc0LDcgKzY0LDcgQEAgc3RhdGljIHZv aWQgdXBkYXRlX2VudHJ5KHN0cnVjdCB2cGNpX21zaXhfZW50cnkgKmVudHJ5LA0KICAgICBlbnRy eS0+dXBkYXRlZCA9IGZhbHNlOw0KIH0NCiANCi1zdGF0aWMgdm9pZCBjZl9jaGVjayBjb250cm9s X3dyaXRlKA0KK3ZvaWQgdnBjaV9tc2l4X2FyY2hfY29udHJvbF93cml0ZSgNCiAgICAgY29uc3Qg c3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCByZWcsIHVpbnQzMl90IHZhbCwgdm9p ZCAqZGF0YSkNCiB7DQogICAgIHN0cnVjdCB2cGNpX21zaXggKm1zaXggPSBkYXRhOw0KQEAgLTgz LDkgKzczLDYgQEAgc3RhdGljIHZvaWQgY2ZfY2hlY2sgY29udHJvbF93cml0ZSgNCiAgICAgdW5z aWduZWQgaW50IGk7DQogICAgIGludCByYzsNCiANCi0gICAgaWYgKCBuZXdfbWFza2VkID09IG1z aXgtPm1hc2tlZCAmJiBuZXdfZW5hYmxlZCA9PSBtc2l4LT5lbmFibGVkICkNCi0gICAgICAgIHJl dHVybjsNCi0NCiAgICAgLyoNCiAgICAgICogQWNjb3JkaW5nIHRvIHRoZSBQQ0kgMy4wIHNwZWNp ZmljYXRpb24sIHN3aXRjaGluZyB0aGUgZW5hYmxlIGJpdCB0byAxDQogICAgICAqIG9yIHRoZSBm dW5jdGlvbiBtYXNrIGJpdCB0byAwIHNob3VsZCBjYXVzZSBhbGwgdGhlIGNhY2hlZCBhZGRyZXNz ZXMNCkBAIC0xMzgsMjAgKzEyNSw2IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIGNvbnRyb2xfd3Jp dGUoDQogICAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAgICB9DQotDQotICAgIC8qIE1ha2Ug c3VyZSBkb21VIGRvZXNuJ3QgZW5hYmxlIElOVHggd2hpbGUgZW5hYmxpbmcgTVNJLVguICovDQot ICAgIGlmICggbmV3X2VuYWJsZWQgJiYgIW1zaXgtPmVuYWJsZWQgJiYgIWlzX2hhcmR3YXJlX2Rv bWFpbihwZGV2LT5kb21haW4pICkNCi0gICAgew0KLSAgICAgICAgcGNpX2ludHgocGRldiwgZmFs c2UpOw0KLSAgICAgICAgcGRldi0+dnBjaS0+aGVhZGVyLmd1ZXN0X2NtZCB8PSBQQ0lfQ09NTUFO RF9JTlRYX0RJU0FCTEU7DQotICAgIH0NCi0NCi0gICAgbXNpeC0+bWFza2VkID0gbmV3X21hc2tl ZDsNCi0gICAgbXNpeC0+ZW5hYmxlZCA9IG5ld19lbmFibGVkOw0KLQ0KLSAgICB2YWwgPSBjb250 cm9sX3JlYWQocGRldiwgcmVnLCBkYXRhKTsNCi0gICAgaWYgKCBwY2lfbXNpX2NvbmZfd3JpdGVf aW50ZXJjZXB0KG1zaXgtPnBkZXYsIHJlZywgMiwgJnZhbCkgPj0gMCApDQotICAgICAgICBwY2lf Y29uZl93cml0ZTE2KHBkZXYtPnNiZGYsIHJlZywgdmFsKTsNCiB9DQogDQogc3RhdGljIHN0cnVj dCB2cGNpX21zaXggKm1zaXhfZmluZChjb25zdCBzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBs b25nIGFkZHIpDQpAQCAtNjk0LDE1MSArNjY3LDI0IEBAIGludCB2cGNpX21ha2VfbXNpeF9ob2xl KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KICAgICByZXR1cm4gMDsNCiB9DQogDQotc3Rh dGljIGludCBjZl9jaGVjayBjbGVhbnVwX21zaXgoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYs IGJvb2wgaGlkZSkNCit2b2lkIHZwY2lfbXNpeF9hcmNoX2NsZWFudXAoc3RydWN0IHZwY2kgKnZw Y2kpDQogew0KLSAgICBpbnQgcmM7DQotICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+dnBj aTsNCi0gICAgY29uc3QgdW5zaWduZWQgaW50IG1zaXhfcG9zID0gcGRldi0+bXNpeF9wb3M7DQot DQogICAgIGlmICggdnBjaS0+bXNpeCApDQogICAgIHsNCiAgICAgICAgIGxpc3RfZGVsKCZ2cGNp LT5tc2l4LT5uZXh0KTsNCiAgICAgICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0gMDsgaSA8IEFS UkFZX1NJWkUodnBjaS0+bXNpeC0+dGFibGUpOyBpKysgKQ0KICAgICAgICAgICAgIGlmICggdnBj aS0+bXNpeC0+dGFibGVbaV0gKQ0KICAgICAgICAgICAgICAgICBpb3VubWFwKHZwY2ktPm1zaXgt PnRhYmxlW2ldKTsNCi0NCi0gICAgICAgIFhGUkVFKHZwY2ktPm1zaXgpOw0KLSAgICB9DQotDQot ICAgIGlmICggIWhpZGUgKQ0KLSAgICAgICAgcmV0dXJuIDA7DQotDQotICAgIHJjID0gdnBjaV9y ZW1vdmVfcmVnaXN0ZXJzKHZwY2ksIG1zaXhfY29udHJvbF9yZWcobXNpeF9wb3MpLCAyKTsNCi0g ICAgaWYgKCByYyApDQotICAgIHsNCi0gICAgICAgIHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBw OiBmYWlsIHRvIHJlbW92ZSBNU0lYIGhhbmRsZXJzIHJjPSVkXG4iLA0KLSAgICAgICAgICAgICAg IHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIHJjKTsNCi0gICAgICAgIEFTU0VSVF9VTlJFQUNI QUJMRSgpOw0KLSAgICAgICAgcmV0dXJuIHJjOw0KICAgICB9DQotDQotICAgIC8qDQotICAgICAq IFVucHJpdmlsZWdlZCBkb21haW5zIGhhdmUgYSBkZW55IGJ5IGRlZmF1bHQgcmVnaXN0ZXIgYWNj ZXNzIHBvbGljeSwgbm8NCi0gICAgICogbmVlZCB0byBhZGQgYW55IGZ1cnRoZXIgaGFuZGxlcnMg Zm9yIHRoZW0uDQotICAgICAqLw0KLSAgICBpZiAoICFpc19oYXJkd2FyZV9kb21haW4ocGRldi0+ ZG9tYWluKSApDQotICAgICAgICByZXR1cm4gMDsNCi0NCi0gICAgLyoNCi0gICAgICogVGhlIGRy aXZlciBtYXkgbm90IHRyYXZlcnNlIHRoZSBjYXBhYmlsaXR5IGxpc3QgYW5kIHRoaW5rIGRldmlj ZQ0KLSAgICAgKiBzdXBwb3J0cyBNU0lYIGJ5IGRlZmF1bHQuIFNvIGhlcmUgbGV0IHRoZSBjb250 cm9sIHJlZ2lzdGVyIG9mIE1TSVgNCi0gICAgICogYmUgUmVhZC1Pbmx5IGlzIHRvIGVuc3VyZSBN U0lYIGRpc2FibGVkLg0KLSAgICAgKi8NCi0gICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcih2cGNp LCB2cGNpX2h3X3JlYWQxNiwgTlVMTCwNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICBtc2l4 X2NvbnRyb2xfcmVnKG1zaXhfcG9zKSwgMiwgTlVMTCk7DQotICAgIGlmICggcmMgKQ0KLSAgICAg ICAgcHJpbnRrKFhFTkxPR19FUlIgIiVwZCAlcHA6IGZhaWwgdG8gYWRkIE1TSVggY3RybCBoYW5k bGVyIHJjPSVkXG4iLA0KLSAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYs IHJjKTsNCi0NCi0gICAgcmV0dXJuIHJjOw0KIH0NCiANCi1zdGF0aWMgaW50IGNmX2NoZWNrIGlu aXRfbXNpeChzdHJ1Y3QgcGNpX2RldiAqcGRldikNCit2b2lkIHZwY2lfbXNpeF9hcmNoX3JlZ2lz dGVyKHN0cnVjdCB2cGNpX21zaXggKm1zaXgsIHN0cnVjdCBkb21haW4gKmQpDQogew0KLSAgICBz dHJ1Y3QgZG9tYWluICpkID0gcGRldi0+ZG9tYWluOw0KLSAgICB1bnNpZ25lZCBpbnQgbXNpeF9v ZmZzZXQsIGksIG1heF9lbnRyaWVzOw0KLSAgICB1aW50MTZfdCBjb250cm9sOw0KLSAgICBzdHJ1 Y3QgdnBjaV9tc2l4ICptc2l4Ow0KLSAgICBpbnQgcmM7DQotDQotICAgIG1zaXhfb2Zmc2V0ID0g cGRldi0+bXNpeF9wb3M7DQotICAgIGlmICggIW1zaXhfb2Zmc2V0ICkNCi0gICAgICAgIHJldHVy biAwOw0KLQ0KLSAgICBjb250cm9sID0gcGNpX2NvbmZfcmVhZDE2KHBkZXYtPnNiZGYsIG1zaXhf Y29udHJvbF9yZWcobXNpeF9vZmZzZXQpKTsNCi0NCi0gICAgbWF4X2VudHJpZXMgPSBtc2l4X3Rh YmxlX3NpemUoY29udHJvbCk7DQotDQotICAgIG1zaXggPSB4emFsbG9jX2ZsZXhfc3RydWN0KHN0 cnVjdCB2cGNpX21zaXgsIGVudHJpZXMsIG1heF9lbnRyaWVzKTsNCi0gICAgaWYgKCAhbXNpeCAp DQotICAgICAgICByZXR1cm4gLUVOT01FTTsNCi0NCi0gICAgbXNpeC0+dGFibGVzW1ZQQ0lfTVNJ WF9UQUJMRV0gPQ0KLSAgICAgICAgcGNpX2NvbmZfcmVhZDMyKHBkZXYtPnNiZGYsIG1zaXhfdGFi bGVfb2Zmc2V0X3JlZyhtc2l4X29mZnNldCkpOw0KLSAgICBtc2l4LT50YWJsZXNbVlBDSV9NU0lY X1BCQV0gPQ0KLSAgICAgICAgcGNpX2NvbmZfcmVhZDMyKHBkZXYtPnNiZGYsIG1zaXhfcGJhX29m ZnNldF9yZWcobXNpeF9vZmZzZXQpKTsNCi0NCi0gICAgLyogQ2hlY2sgdGhhdCB0aGUgcmVmZXJl bmNlZCBCQVIocykgcmVnaW9ucyBhcmUgdmFsaWQuICovDQotICAgIGZvciAoIGkgPSAwOyBpIDwg QVJSQVlfU0laRShtc2l4LT50YWJsZXMpOyBpKysgKQ0KLSAgICB7DQotICAgICAgICBjb25zdCBj aGFyICpuYW1lID0gKGkgPT0gVlBDSV9NU0lYX1RBQkxFKSA/ICJ2ZWN0b3IiIDogIlBCQSI7DQot ICAgICAgICBjb25zdCBzdHJ1Y3QgdnBjaV9iYXIgKmJhcnMgPSBwZGV2LT52cGNpLT5oZWFkZXIu YmFyczsNCi0gICAgICAgIHVuc2lnbmVkIGludCBiaXIgPSBtc2l4LT50YWJsZXNbaV0gJiBQQ0lf TVNJWF9CSVJNQVNLOw0KLSAgICAgICAgdW5zaWduZWQgaW50IHR5cGU7DQotICAgICAgICB1bnNp Z25lZCBpbnQgb2Zmc2V0ID0gbXNpeC0+dGFibGVzW2ldICYgflBDSV9NU0lYX0JJUk1BU0s7DQot ICAgICAgICB1bnNpZ25lZCBpbnQgc2l6ZSA9DQotICAgICAgICAgICAgKGkgPT0gVlBDSV9NU0lY X1RBQkxFKSA/IG1heF9lbnRyaWVzICogUENJX01TSVhfRU5UUllfU0laRQ0KLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgOiBST1VORFVQKERJVl9ST1VORF9VUChtYXhfZW50cmll cywgOCksIDgpOw0KLQ0KLSAgICAgICAgaWYgKCBiaXIgPj0gQVJSQVlfU0laRShwZGV2LT52cGNp LT5oZWFkZXIuYmFycykgKQ0KLSAgICAgICAgew0KLSAgICAgICAgICAgIHByaW50ayhYRU5MT0df RVJSIERFVl9CVUdfUFJFRklYDQotICAgICAgICAgICAgICAgICAgICIlcHA6IE1TSS1YICVzIHRh YmxlIHdpdGggb3V0IG9mIHJhbmdlIEJJUiAldVxuIiwNCi0gICAgICAgICAgICAgICAgICAgJnBk ZXYtPnNiZGYsIG5hbWUsIGJpcik7DQotIGludmFsaWQ6DQotICAgICAgICAgICAgeGZyZWUobXNp eCk7DQotICAgICAgICAgICAgcmV0dXJuIC1FTk9ERVY7DQotICAgICAgICB9DQotDQotICAgICAg ICB0eXBlID0gYmFyc1tiaXJdLnR5cGU7DQotICAgICAgICBpZiAoIHR5cGUgIT0gVlBDSV9CQVJf TUVNMzIgJiYgdHlwZSAhPSBWUENJX0JBUl9NRU02NF9MTyApDQotICAgICAgICB7DQotICAgICAg ICAgICAgcHJpbnRrKFhFTkxPR19FUlIgREVWX0JVR19QUkVGSVgNCi0gICAgICAgICAgICAgICAg ICAgIiVwcDogTVNJLVggJXMgdGFibGUgYXQgaW52YWxpZCBCQVIldSB3aXRoIHR5cGUgJXVcbiIs DQotICAgICAgICAgICAgICAgICAgICZwZGV2LT5zYmRmLCBuYW1lLCBiaXIsIHR5cGUpOw0KLSAg ICAgICAgICAgIGdvdG8gaW52YWxpZDsNCi0gICAgICAgIH0NCi0NCi0gICAgICAgIGlmICggKHVp bnQ2NF90KW9mZnNldCArIHNpemUgPiBiYXJzW2Jpcl0uc2l6ZSApDQotICAgICAgICB7DQotICAg ICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgREVWX0JVR19QUkVGSVgNCi0gICAgICAgICAgICAg ICAgICAgIiVwcDogTVNJLVggJXMgdGFibGUgb2Zmc2V0ICUjeCBzaXplICUjeCBvdXRzaWRlIG9m IEJBUiV1IHNpemUgJSNseFxuIiwNCi0gICAgICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIG5h bWUsIG9mZnNldCwgc2l6ZSwgYmlyLCBiYXJzW2Jpcl0uc2l6ZSk7DQotICAgICAgICAgICAgZ290 byBpbnZhbGlkOw0KLSAgICAgICAgfQ0KLSAgICB9DQotDQotICAgIHJjID0gdnBjaV9hZGRfcmVn aXN0ZXIocGRldi0+dnBjaSwgY29udHJvbF9yZWFkLCBjb250cm9sX3dyaXRlLA0KLSAgICAgICAg ICAgICAgICAgICAgICAgICAgIG1zaXhfY29udHJvbF9yZWcobXNpeF9vZmZzZXQpLCAyLCBtc2l4 KTsNCi0gICAgaWYgKCByYyApDQotICAgIHsNCi0gICAgICAgIHhmcmVlKG1zaXgpOw0KLSAgICAg ICAgcmV0dXJuIHJjOw0KLSAgICB9DQotDQotICAgIG1zaXgtPm1heF9lbnRyaWVzID0gbWF4X2Vu dHJpZXM7DQotICAgIG1zaXgtPnBkZXYgPSBwZGV2Ow0KLQ0KLSAgICBmb3IgKCBpID0gMDsgaSA8 IG1heF9lbnRyaWVzOyBpKyspDQotICAgIHsNCi0gICAgICAgIG1zaXgtPmVudHJpZXNbaV0ubWFz a2VkID0gdHJ1ZTsNCi0gICAgICAgIHZwY2lfbXNpeF9hcmNoX2luaXRfZW50cnkoJm1zaXgtPmVu dHJpZXNbaV0pOw0KLSAgICB9DQotDQogICAgIGlmICggbGlzdF9lbXB0eSgmZC0+YXJjaC5odm0u bXNpeF90YWJsZXMpICkNCiAgICAgICAgIHJlZ2lzdGVyX21taW9faGFuZGxlcihkLCAmdnBjaV9t c2l4X3RhYmxlX29wcyk7DQogDQotICAgIHBkZXYtPnZwY2ktPm1zaXggPSBtc2l4Ow0KICAgICBs aXN0X2FkZCgmbXNpeC0+bmV4dCwgJmQtPmFyY2guaHZtLm1zaXhfdGFibGVzKTsNCi0NCi0gICAg LyoNCi0gICAgICogdlBDSSBoZWFkZXIgaW5pdGlhbGl6YXRpb24gd2lsbCBoYXZlIG1hcHBlZCB0 aGUgd2hvbGUgQkFSIGludG8gdGhlDQotICAgICAqIHAybSwgYXMgTVNJLVggY2FwYWJpbGl0eSB3 YXMgbm90IHlldCBpbml0aWFsaXplZC4gIENhcnZlIGEgaG9sZSBmb3INCi0gICAgICogdGhlIE1T SS1YIHRhYmxlIGhlcmUsIHNvIHRoYXQgWGVuIGNhbiB0cmFwIGFjY2Vzc2VzLg0KLSAgICAgKi8N Ci0gICAgcmV0dXJuIHZwY2lfbWFrZV9tc2l4X2hvbGUocGRldik7DQogfQ0KLVJFR0lTVEVSX1ZQ Q0lfQ0FQKE1TSVgsIGluaXRfbXNpeCwgY2xlYW51cF9tc2l4KTsNCiANCiAvKg0KICAqIExvY2Fs IHZhcmlhYmxlczoNCmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL21zaXhfY29tbW9uLmMg Yi94ZW4vZHJpdmVycy92cGNpL21zaXhfY29tbW9uLmMNCm5ldyBmaWxlIG1vZGUgMTAwNjQ0DQpp bmRleCAwMDAwMDAwMDAwLi5iMzhkZTQ4NTc5DQotLS0gL2Rldi9udWxsDQorKysgYi94ZW4vZHJp dmVycy92cGNpL21zaXhfY29tbW9uLmMNCkBAIC0wLDAgKzEsMjAyIEBADQorLyogU1BEWC1MaWNl bnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KKy8qDQorICogSGFuZGxlcnMgZm9yIGFj Y2Vzc2VzIHRvIHRoZSBNU0ktWCBjYXBhYmlsaXR5IHN0cnVjdHVyZSBhbmQgdGhlIG1lbW9yeQ0K KyAqIHJlZ2lvbi4NCisgKg0KKyAqIENvcHlyaWdodCAoQykgMjAxNyBDaXRyaXggU3lzdGVtcyBS JkQNCisgKi8NCisNCisjaW5jbHVkZSAicHJpdmF0ZS5oIg0KKw0KKyNpbmNsdWRlIDx4ZW4vaW8u aD4NCisjaW5jbHVkZSA8eGVuL2xpYi5oPg0KKyNpbmNsdWRlIDx4ZW4vbXNpLmg+DQorI2luY2x1 ZGUgPHhlbi9zY2hlZC5oPg0KKw0KKyNpbmNsdWRlIDxhc20vcDJtLmg+DQorDQorc3RhdGljIHVp bnQzMl90IGNmX2NoZWNrIGNvbnRyb2xfcmVhZCgNCisgICAgY29uc3Qgc3RydWN0IHBjaV9kZXYg KnBkZXYsIHVuc2lnbmVkIGludCByZWcsIHZvaWQgKmRhdGEpDQorew0KKyAgICBjb25zdCBzdHJ1 Y3QgdnBjaV9tc2l4ICptc2l4ID0gZGF0YTsNCisNCisgICAgcmV0dXJuIChtc2l4LT5tYXhfZW50 cmllcyAtIDEpIHwNCisgICAgICAgICAgIChtc2l4LT5lbmFibGVkID8gUENJX01TSVhfRkxBR1Nf RU5BQkxFIDogMCkgfA0KKyAgICAgICAgICAgKG1zaXgtPm1hc2tlZCA/IFBDSV9NU0lYX0ZMQUdT X01BU0tBTEwgOiAwKTsNCit9DQorDQorc3RhdGljIHZvaWQgY2ZfY2hlY2sgY29udHJvbF93cml0 ZSgNCisgICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCByZWcsIHVp bnQzMl90IHZhbCwgdm9pZCAqZGF0YSkNCit7DQorICAgIHN0cnVjdCB2cGNpX21zaXggKm1zaXgg PSBkYXRhOw0KKyAgICBib29sIG5ld19tYXNrZWQgPSB2YWwgJiBQQ0lfTVNJWF9GTEFHU19NQVNL QUxMOw0KKyAgICBib29sIG5ld19lbmFibGVkID0gdmFsICYgUENJX01TSVhfRkxBR1NfRU5BQkxF Ow0KKw0KKyAgICBpZiAoIG5ld19tYXNrZWQgPT0gbXNpeC0+bWFza2VkICYmIG5ld19lbmFibGVk ID09IG1zaXgtPmVuYWJsZWQgKQ0KKyAgICAgICAgcmV0dXJuOw0KKw0KKyAgICB2cGNpX21zaXhf YXJjaF9jb250cm9sX3dyaXRlKHBkZXYsIHJlZywgdmFsLCBkYXRhKTsNCisNCisgICAgLyogTWFr ZSBzdXJlIGRvbVUgZG9lc24ndCBlbmFibGUgSU5UeCB3aGlsZSBlbmFibGluZyBNU0ktWC4gKi8N CisgICAgaWYgKCBuZXdfZW5hYmxlZCAmJiAhbXNpeC0+ZW5hYmxlZCAmJiAhaXNfaGFyZHdhcmVf ZG9tYWluKHBkZXYtPmRvbWFpbikgKQ0KKyAgICB7DQorICAgICAgICBwY2lfaW50eChwZGV2LCBm YWxzZSk7DQorICAgICAgICBwZGV2LT52cGNpLT5oZWFkZXIuZ3Vlc3RfY21kIHw9IFBDSV9DT01N QU5EX0lOVFhfRElTQUJMRTsNCisgICAgfQ0KKw0KKyAgICBtc2l4LT5tYXNrZWQgPSBuZXdfbWFz a2VkOw0KKyAgICBtc2l4LT5lbmFibGVkID0gbmV3X2VuYWJsZWQ7DQorDQorICAgIHZhbCA9IGNv bnRyb2xfcmVhZChwZGV2LCByZWcsIGRhdGEpOw0KKyAgICBpZiAoIHBjaV9tc2lfY29uZl93cml0 ZV9pbnRlcmNlcHQobXNpeC0+cGRldiwgcmVnLCAyLCAmdmFsKSA+PSAwICkNCisgICAgICAgIHBj aV9jb25mX3dyaXRlMTYocGRldi0+c2JkZiwgcmVnLCB2YWwpOw0KK30NCisNCitzdGF0aWMgaW50 IGNmX2NoZWNrIGNsZWFudXBfbXNpeChjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgYm9vbCBo aWRlKQ0KK3sNCisgICAgaW50IHJjOw0KKyAgICBzdHJ1Y3QgdnBjaSAqdnBjaSA9IHBkZXYtPnZw Y2k7DQorICAgIGNvbnN0IHVuc2lnbmVkIGludCBtc2l4X3BvcyA9IHBkZXYtPm1zaXhfcG9zOw0K Kw0KKyAgICB2cGNpX21zaXhfYXJjaF9jbGVhbnVwKHZwY2kpOw0KKw0KKyAgICBpZiAoIHZwY2kt Pm1zaXggKQ0KKyAgICAgICAgWEZSRUUodnBjaS0+bXNpeCk7DQorDQorICAgIGlmICggIWhpZGUg KQ0KKyAgICAgICAgcmV0dXJuIDA7DQorDQorICAgIHJjID0gdnBjaV9yZW1vdmVfcmVnaXN0ZXJz KHZwY2ksIG1zaXhfY29udHJvbF9yZWcobXNpeF9wb3MpLCAyKTsNCisgICAgaWYgKCByYyApDQor ICAgIHsNCisgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiBmYWlsIHRvIHJlbW92 ZSBNU0lYIGhhbmRsZXJzIHJjPSVkXG4iLA0KKyAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwg JnBkZXYtPnNiZGYsIHJjKTsNCisgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KKyAgICAg ICAgcmV0dXJuIHJjOw0KKyAgICB9DQorDQorICAgIC8qDQorICAgICAqIFVucHJpdmlsZWdlZCBk b21haW5zIGhhdmUgYSBkZW55IGJ5IGRlZmF1bHQgcmVnaXN0ZXIgYWNjZXNzIHBvbGljeSwgbm8N CisgICAgICogbmVlZCB0byBhZGQgYW55IGZ1cnRoZXIgaGFuZGxlcnMgZm9yIHRoZW0uDQorICAg ICAqLw0KKyAgICBpZiAoICFpc19oYXJkd2FyZV9kb21haW4ocGRldi0+ZG9tYWluKSApDQorICAg ICAgICByZXR1cm4gMDsNCisNCisgICAgLyoNCisgICAgICogVGhlIGRyaXZlciBtYXkgbm90IHRy YXZlcnNlIHRoZSBjYXBhYmlsaXR5IGxpc3QgYW5kIHRoaW5rIGRldmljZQ0KKyAgICAgKiBzdXBw b3J0cyBNU0lYIGJ5IGRlZmF1bHQuIFNvIGhlcmUgbGV0IHRoZSBjb250cm9sIHJlZ2lzdGVyIG9m IE1TSVgNCisgICAgICogYmUgUmVhZC1Pbmx5IGlzIHRvIGVuc3VyZSBNU0lYIGRpc2FibGVkLg0K KyAgICAgKi8NCisgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcih2cGNpLCB2cGNpX2h3X3JlYWQx NiwgTlVMTCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICBtc2l4X2NvbnRyb2xfcmVnKG1z aXhfcG9zKSwgMiwgTlVMTCk7DQorICAgIGlmICggcmMgKQ0KKyAgICAgICAgcHJpbnRrKFhFTkxP R19FUlIgIiVwZCAlcHA6IGZhaWwgdG8gYWRkIE1TSVggY3RybCBoYW5kbGVyIHJjPSVkXG4iLA0K KyAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIHJjKTsNCisNCisgICAg cmV0dXJuIHJjOw0KK30NCisNCitzdGF0aWMgaW50IGNmX2NoZWNrIGluaXRfbXNpeChzdHJ1Y3Qg cGNpX2RldiAqcGRldikNCit7DQorICAgIHN0cnVjdCBkb21haW4gKmQgPSBwZGV2LT5kb21haW47 DQorICAgIHVuc2lnbmVkIGludCBtc2l4X29mZnNldCwgaSwgbWF4X2VudHJpZXM7DQorICAgIHVp bnQxNl90IGNvbnRyb2w7DQorICAgIHN0cnVjdCB2cGNpX21zaXggKm1zaXg7DQorICAgIGludCBy YzsNCisNCisgICAgbXNpeF9vZmZzZXQgPSBwZGV2LT5tc2l4X3BvczsNCisgICAgaWYgKCAhbXNp eF9vZmZzZXQgKQ0KKyAgICAgICAgcmV0dXJuIDA7DQorDQorICAgIGNvbnRyb2wgPSBwY2lfY29u Zl9yZWFkMTYocGRldi0+c2JkZiwgbXNpeF9jb250cm9sX3JlZyhtc2l4X29mZnNldCkpOw0KKw0K KyAgICBtYXhfZW50cmllcyA9IG1zaXhfdGFibGVfc2l6ZShjb250cm9sKTsNCisNCisgICAgbXNp eCA9IHh6YWxsb2NfZmxleF9zdHJ1Y3Qoc3RydWN0IHZwY2lfbXNpeCwgZW50cmllcywgbWF4X2Vu dHJpZXMpOw0KKyAgICBpZiAoICFtc2l4ICkNCisgICAgICAgIHJldHVybiAtRU5PTUVNOw0KKw0K KyAgICBtc2l4LT50YWJsZXNbVlBDSV9NU0lYX1RBQkxFXSA9DQorICAgICAgICBwY2lfY29uZl9y ZWFkMzIocGRldi0+c2JkZiwgbXNpeF90YWJsZV9vZmZzZXRfcmVnKG1zaXhfb2Zmc2V0KSk7DQor ICAgIG1zaXgtPnRhYmxlc1tWUENJX01TSVhfUEJBXSA9DQorICAgICAgICBwY2lfY29uZl9yZWFk MzIocGRldi0+c2JkZiwgbXNpeF9wYmFfb2Zmc2V0X3JlZyhtc2l4X29mZnNldCkpOw0KKw0KKyAg ICAvKiBDaGVjayB0aGF0IHRoZSByZWZlcmVuY2VkIEJBUihzKSByZWdpb25zIGFyZSB2YWxpZC4g Ki8NCisgICAgZm9yICggaSA9IDA7IGkgPCBBUlJBWV9TSVpFKG1zaXgtPnRhYmxlcyk7IGkrKyAp DQorICAgIHsNCisgICAgICAgIGNvbnN0IGNoYXIgKm5hbWUgPSAoaSA9PSBWUENJX01TSVhfVEFC TEUpID8gInZlY3RvciIgOiAiUEJBIjsNCisgICAgICAgIGNvbnN0IHN0cnVjdCB2cGNpX2JhciAq YmFycyA9IHBkZXYtPnZwY2ktPmhlYWRlci5iYXJzOw0KKyAgICAgICAgdW5zaWduZWQgaW50IGJp ciA9IG1zaXgtPnRhYmxlc1tpXSAmIFBDSV9NU0lYX0JJUk1BU0s7DQorICAgICAgICB1bnNpZ25l ZCBpbnQgdHlwZTsNCisgICAgICAgIHVuc2lnbmVkIGludCBvZmZzZXQgPSBtc2l4LT50YWJsZXNb aV0gJiB+UENJX01TSVhfQklSTUFTSzsNCisgICAgICAgIHVuc2lnbmVkIGludCBzaXplID0NCisg ICAgICAgICAgICAoaSA9PSBWUENJX01TSVhfVEFCTEUpID8gbWF4X2VudHJpZXMgKiBQQ0lfTVNJ WF9FTlRSWV9TSVpFDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6IFJPVU5E VVAoRElWX1JPVU5EX1VQKG1heF9lbnRyaWVzLCA4KSwgOCk7DQorDQorICAgICAgICBpZiAoIGJp ciA+PSBBUlJBWV9TSVpFKHBkZXYtPnZwY2ktPmhlYWRlci5iYXJzKSApDQorICAgICAgICB7DQor ICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgREVWX0JVR19QUkVGSVgNCisgICAgICAgICAg ICAgICAgICAgIiVwcDogTVNJLVggJXMgdGFibGUgd2l0aCBvdXQgb2YgcmFuZ2UgQklSICV1XG4i LA0KKyAgICAgICAgICAgICAgICAgICAmcGRldi0+c2JkZiwgbmFtZSwgYmlyKTsNCisgaW52YWxp ZDoNCisgICAgICAgICAgICB4ZnJlZShtc2l4KTsNCisgICAgICAgICAgICByZXR1cm4gLUVOT0RF VjsNCisgICAgICAgIH0NCisNCisgICAgICAgIHR5cGUgPSBiYXJzW2Jpcl0udHlwZTsNCisgICAg ICAgIGlmICggdHlwZSAhPSBWUENJX0JBUl9NRU0zMiAmJiB0eXBlICE9IFZQQ0lfQkFSX01FTTY0 X0xPICkNCisgICAgICAgIHsNCisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiBERVZfQlVH X1BSRUZJWA0KKyAgICAgICAgICAgICAgICAgICAiJXBwOiBNU0ktWCAlcyB0YWJsZSBhdCBpbnZh bGlkIEJBUiV1IHdpdGggdHlwZSAldVxuIiwNCisgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNi ZGYsIG5hbWUsIGJpciwgdHlwZSk7DQorICAgICAgICAgICAgZ290byBpbnZhbGlkOw0KKyAgICAg ICAgfQ0KKw0KKyAgICAgICAgaWYgKCAodWludDY0X3Qpb2Zmc2V0ICsgc2l6ZSA+IGJhcnNbYmly XS5zaXplICkNCisgICAgICAgIHsNCisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiBERVZf QlVHX1BSRUZJWA0KKyAgICAgICAgICAgICAgICAgICAiJXBwOiBNU0ktWCAlcyB0YWJsZSBvZmZz ZXQgJSN4IHNpemUgJSN4IG91dHNpZGUgb2YgQkFSJXUgc2l6ZSAlI2x4XG4iLA0KKyAgICAgICAg ICAgICAgICAgICAmcGRldi0+c2JkZiwgbmFtZSwgb2Zmc2V0LCBzaXplLCBiaXIsIGJhcnNbYmly XS5zaXplKTsNCisgICAgICAgICAgICBnb3RvIGludmFsaWQ7DQorICAgICAgICB9DQorICAgIH0N CisNCisgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCBjb250cm9sX3JlYWQs IGNvbnRyb2xfd3JpdGUsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgbXNpeF9jb250cm9s X3JlZyhtc2l4X29mZnNldCksIDIsIG1zaXgpOw0KKyAgICBpZiAoIHJjICkNCisgICAgew0KKyAg ICAgICAgeGZyZWUobXNpeCk7DQorICAgICAgICByZXR1cm4gcmM7DQorICAgIH0NCisNCisgICAg bXNpeC0+bWF4X2VudHJpZXMgPSBtYXhfZW50cmllczsNCisgICAgbXNpeC0+cGRldiA9IHBkZXY7 DQorDQorICAgIGZvciAoIGkgPSAwOyBpIDwgbWF4X2VudHJpZXM7IGkrKykNCisgICAgew0KKyAg ICAgICAgbXNpeC0+ZW50cmllc1tpXS5tYXNrZWQgPSB0cnVlOw0KKyAgICAgICAgdnBjaV9tc2l4 X2FyY2hfaW5pdF9lbnRyeSgmbXNpeC0+ZW50cmllc1tpXSk7DQorICAgIH0NCisNCisgICAgcGRl di0+dnBjaS0+bXNpeCA9IG1zaXg7DQorDQorICAgIHZwY2lfbXNpeF9hcmNoX3JlZ2lzdGVyKG1z aXgsIGQpOw0KKw0KKyAgICAvKg0KKyAgICAgKiB2UENJIGhlYWRlciBpbml0aWFsaXphdGlvbiB3 aWxsIGhhdmUgbWFwcGVkIHRoZSB3aG9sZSBCQVIgaW50byB0aGUNCisgICAgICogcDJtLCBhcyBN U0ktWCBjYXBhYmlsaXR5IHdhcyBub3QgeWV0IGluaXRpYWxpemVkLiAgQ2FydmUgYSBob2xlIGZv cg0KKyAgICAgKiB0aGUgTVNJLVggdGFibGUgaGVyZSwgc28gdGhhdCBYZW4gY2FuIHRyYXAgYWNj ZXNzZXMuDQorICAgICAqLw0KKyAgICByZXR1cm4gdnBjaV9tYWtlX21zaXhfaG9sZShwZGV2KTsN Cit9DQorUkVHSVNURVJfVlBDSV9DQVAoTVNJWCwgaW5pdF9tc2l4LCBjbGVhbnVwX21zaXgpOw0K Kw0KKy8qDQorICogTG9jYWwgdmFyaWFibGVzOg0KKyAqIG1vZGU6IEMNCisgKiBjLWZpbGUtc3R5 bGU6ICJCU0QiDQorICogYy1iYXNpYy1vZmZzZXQ6IDQNCisgKiB0YWItd2lkdGg6IDQNCisgKiBp bmRlbnQtdGFicy1tb2RlOiBuaWwNCisgKiBFbmQ6DQorICovDQpkaWZmIC0tZ2l0IGEveGVuL2lu Y2x1ZGUveGVuL3ZwY2kuaCBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCmluZGV4IDg3N2FhMzkx ZDEuLjA3YjM4OGE5OTggMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQorKysg Yi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQpAQCAtMTk5LDYgKzE5OSwxMSBAQCBib29sIHZwY2lf ZWNhbV93cml0ZShwY2lfc2JkZl90IHNiZGYsIHVuc2lnbmVkIGludCByZWcsIHVuc2lnbmVkIGlu dCBsZW4sDQogYm9vbCB2cGNpX2VjYW1fcmVhZChwY2lfc2JkZl90IHNiZGYsIHVuc2lnbmVkIGlu dCByZWcsIHVuc2lnbmVkIGludCBsZW4sDQogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBs b25nICpkYXRhKTsNCiANCit2b2lkIHZwY2lfbXNpeF9hcmNoX2NvbnRyb2xfd3JpdGUoDQorICAg IGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1bnNpZ25lZCBpbnQgcmVnLCB1aW50MzJfdCB2 YWwsIHZvaWQgKmRhdGEpOw0KK3ZvaWQgdnBjaV9tc2l4X2FyY2hfY2xlYW51cChzdHJ1Y3QgdnBj aSAqdnBjaSk7DQordm9pZCB2cGNpX21zaXhfYXJjaF9yZWdpc3RlcihzdHJ1Y3QgdnBjaV9tc2l4 ICptc2l4LCBzdHJ1Y3QgZG9tYWluICpkKTsNCisNCiAjZW5kaWYgLyogX19YRU5fXyAqLw0KIA0K ICNlbHNlIC8qICFDT05GSUdfSEFTX1ZQQ0kgKi8NCi0tIA0KMi41NS4wDQo= From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:28:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:28:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461246.1672219 (Exim 4.92) (envelope-from ) id 1xLJov-0003Xf-Tq; Mon, 26 Oct 2026 12:28:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461246.1672219; Mon, 26 Oct 2026 12:28: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 1xLJov-0003XY-Qy; Mon, 26 Oct 2026 12:28:57 +0000 Received: by outflank-mailman (input) for mailman id 1461246; Mon, 26 Oct 2026 12:28:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLJot-0003X0-L2 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:28:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJot-00D9vl-1f for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:28:55 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4778-e002-0a2a0a5209dd-0a2a4507d5ca-20 for ; Mon, 26 Oct 2026 13:28:54 +0100 Received: from [52.101.57.59] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4785-b4ea-0a2a45070019-3465393b327d-4 for ; Mon, 26 Oct 2026 13:28:54 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA0PR03MB5388.namprd03.prod.outlook.com (2603:10b6:806:b7::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 12:27: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%4]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 12:27: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=N+yIvZ9jRoXzAuSy3gxEvhMMUiU4YDFqytfyzvr2LqXLB8/rpsvIgCIkEOJZEX20GcGevMDcouD/rRRNfd/pDn3jnsxA0IhDqBcTktuuXRf3VtG2039a5cN69aqA+py3RxreybdjynFdynFcrb9SWLaMwXrWBXgG3DWEhi60VJpoQjbkr2FCcTtSndHbhzLxwOgBHk0Z7fz9NLFTUFoVFFyBoG/kWqOK+3Qf7uC+IA7xFqxc4h/Fp5AiBxmBEp8YlTPRo5jAMU1cmztEvpQDelWju3ol7KC61TFqHEhnYDBMswo6nYPdjvb17WmFiWiymx5Yv6lOg5ivvnEUAumUSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rLu55oHVPlEXT/mOqQatch9k/iuiR883DkdVQXZjfCs=; b=zB96S97u1SAGKqylcwkevnv4O9Z98RSuYT+YJQBBiugEsoTJHSoRZVWD93uYe149hObqzZ/SxPRtpD+3bKNq/y8CsfvcTzMGL9Qm/gmslpm5lEtctknX68St6BAbawQURFdc6CZeltl39EoZaLkOTA+W0qgUZhbelUqP++hdjBvYuGOHfOygF1A+mlgA2jhjIyzdAXcEXnSiq60ABsYaVV713wlIwBxVljr4JGbHsAANgRSs7RL7QpZRc9g3bSFL3C/xzo3D7221XMWqq9nFabRlqIbxwFAoKSfBtnvhVQjMQtzvh6tb7ub3fFoBGrj0DJvFALKfAFD76beTuV+5DA== 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=rLu55oHVPlEXT/mOqQatch9k/iuiR883DkdVQXZjfCs=; b=juBd68xhXagf1fxfaAKRnzO0mMJE5admeYXRTIrjssCb55WF3B3H/pYrAZ2K8eODA7PZpZhq9/EumIRcQuyCL3g6hITryC3KJ5PyytkUPHr5sRGsBdBIH9zpXMrwaYYHfxjuwMMutxLuaQBY3B+iPF/6zuZ/FWoQMX4WyspIusg= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0ee66940-5e5b-407e-81fe-de0e47842bbf@citrix.com> Date: Mon, 26 Oct 2026 12:27:17 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, roger@xenproject.org, teddy.astie@vates.tech Subject: Re: [PATCH] x86/desc: build boot GDT descriptors with a macro To: Furkan Caliskan , xen-devel@lists.xenproject.org References: <20261020135722.45714-1-frn1furkan10@gmail.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: <20261020135722.45714-1-frn1furkan10@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0316.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:395::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_|SA0PR03MB5388:EE_ X-MS-Office365-Filtering-Correlation-Id: 49161fc9-a3ce-44a3-c5f5-08df335c7b58 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|18002099003|22082099003|56012099006|11063799006|261021121427099003|261021123027099003|261022105027099003|10067099003|261009223027099003; X-Microsoft-Antispam-Message-Info: DynWQLEB2KBB2nwxPWti+7biHoZ027KyvY5vcZKvN/E3g5c5syXBT+2HCGiKD1u9z57NnbKbce9KtX2hwwNclqOgNYCMsSo7jidzjk27geo59QEAtBV8c9KsAyzOoxIbmI7qsViEsCIcFkQDk7sCSo+Wby0rGHoH6bPAUG67WQvFXw+htnAVJRfXM30ZWPL76XtC0d30QMMysjsQMYvZCP63Mc0gyelYT0EbXPblNqdH1/q89vPJ+JrnPFHoQtYBIsxrfemB0wo4GMI5HaKgURFqO4K2BQvkHamFS5dxQ/95vNIpi/yNINGXffDmOIiGF4gQS8K2eSTJKmWF9RJANpOB09Q4yB+EsgFBOptAw+HBwbXCHYAw0r6O2Rsl6qIN/9ah2YT8dpQK8K2VhOjQCdZVIT99OuNxLE8CyyxYwGsnqLALIZhDRsNGYgPK7OsZQNcBJON6dfl2eBcNzyJgfUp5FU+ajFRpn8k1NI5GndJdsNfwcTJKgmiRkwX7ZOOYTAOnI59sJ5AD8t0rovZtUMSdyy+ZsCDNDHgoXaZ8vpAFtR5yTsgNtAcWry76ld36i5L5R3egSBhmL3wYsaa69qYw6ood/LNx+7Yk9TqUo77D3QdezrmUc6/vPSA+EmfVkqktvopp4Z06e5Jdnz7Z0DHflRDFzKO9NpMlMaZGKBw= 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)(18002099003)(22082099003)(56012099006)(11063799006)(261021121427099003)(261021123027099003)(261022105027099003)(10067099003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TkdkQ1A4ZzAwdGE0QTdmTC9EdGRHa0Z5SHplZWovajZ1clZJY0l6d3lWa0kx?= =?utf-8?B?aVRXT0NObzl4QzQ3eVhGSUsrYk9ja0tSZzVwODVyaXZaWjFMYmI0YmZoTGVY?= =?utf-8?B?SlluQzFqVytKbkVqdHE5RFJLZDgxdjRwN2owNi9kRWdZYTdFaENPckFhcllk?= =?utf-8?B?WFA1N21tODQ2U0pMc0VNYnFDM2FVaDVwS2toWTVyNCtxaXRjVk5OQ2locWNJ?= =?utf-8?B?TGZFaG94VTh5ZGZoWWs3Y2hnREM4NFVEYWZGc2hNYlF2VW56WU1SN2t4QjF5?= =?utf-8?B?VVM1YWZlRW1qMGJYMDBOdzZ5WUtvN09QN0pBTGxoVkZEdzV4SGpoWTNSN1VK?= =?utf-8?B?RHRzN3R2MlZIOGd6R01wbld2RjM3V3RDa1g3QzdMZHZmTWlmR05kc1E5Z2V3?= =?utf-8?B?YjhLVzNydXBtd2VTYm1BZzg4YlF6ZGloZTJVcmFGYzA0ZUpoVWRiZkhyUmIy?= =?utf-8?B?c0M2Zzkzd1VZdkVwZE5MQzNneS9UcDBZZEF1Q3N0dXpBUXdPRE5Vakt1N0Jn?= =?utf-8?B?TTNWd3pLSU15dXdpWnhDNW5mK0o0YVJPN3VOWkdLeXJQT0VsTUhaRUUvaTZx?= =?utf-8?B?aW0wdXlISGVFd1NKcFd1Y2hFY3ZIejBKY1NLdy9zZEFUa2tmbWw0U2VTQ0JX?= =?utf-8?B?T0x1cEtYdnNFVUVPTzAzdFpHQ0NkR3puRnBsQ1pFVDdZa0Z2RTJod3VCdHFZ?= =?utf-8?B?SXZCeWtKeTdjZlpCVkVSZmJSQTFDRkg1UlBYRUFydWhTZFRXTndiQlNhMXBm?= =?utf-8?B?YTRtZWtzaTBkMDh4TTAra1NSK21jZ1lWUU94YVVUZWZXWHJ2c29McGxjbG5u?= =?utf-8?B?aG1UY3F2UjRTbDZGZWVpK0k2aS9ZN0RKVklqcGZjb0plTzcwMllSUEJHbEhh?= =?utf-8?B?bXhUR3hrMDVDL0dZSCt2VWFsWlhLNENrSW95blpyaGw3dmI5Q0FnSUh1enZ4?= =?utf-8?B?aW9xNGVHcXNzeGljeDZpeXArY0hyUS92TFl5ek5VcVNza0Z4QWN3SENkTmly?= =?utf-8?B?Z1h1Q09iUXhGdWFNb2tEeDJRMy9vazBsRGkvTStiMEptckZpRytqVnZwQTBz?= =?utf-8?B?Y2VQZUJHM25lYkZsRnkvdWw4SXcwRDNEemhEQ3d4LzM1Rzc2VTRVWGVzOGYx?= =?utf-8?B?dFh0RHBzMGRZWEhlaGVpNDM2aXJpSjNsMDdJMVoxLzlRTVE4SEg0M1VRZjJi?= =?utf-8?B?TnJxTVJaUnozaUZMU292UlI4OG9RaWxqNmVoTDB3NGJFL01RN3g1TWFublhs?= =?utf-8?B?Q2dSZjQwRVVYY205cHBkNkRLTkRPaUptdmlPKzB2KzFyaGZ3cE9CcW9YQVpa?= =?utf-8?B?TmpKRUN6czhadGRkV3NqSHZ2RDFYZHBLemErZHZiVkl0aVMxYVcwL3ZNMmhF?= =?utf-8?B?WFplM3AraGFid3h4ckExeXYrb2I0blNMRllUK3pZZnZ0SXZHOEJ5NHFhR2M0?= =?utf-8?B?NnhySmlPSGFFY3dISTMyK1hlY1FFVE10cVpGRnRPVkxQODJzdHo4SE1EN21S?= =?utf-8?B?eVBwR2J4L2xwbVg2b3JpZWNMdnBDU2RCSlZ0a1hnZDZybGUyQTN0S1RXYmE2?= =?utf-8?B?bitQSCsvNStEUDVVOVZGRk1mL2hpTUJKZW1IM0ZzRUV4Mmc3RVhtdlZYbGJB?= =?utf-8?B?Z3FIS3pKc25YRkZaSXdMNmNpWWJJL21xQlQ0SmZERHZ3TjFkWkl6aTZyL3g5?= =?utf-8?B?bXhkR2hadGh0MmhMbXVoRzh2aTJyb3JWb2p4UzZUdnpBNnFuWVJzOGxBdWJ4?= =?utf-8?B?aThpczVramFRcW5CSlZHcjlxZ0ZLa0tLUFNtQkg2dFdIQnoyUXBXSGNFVVdF?= =?utf-8?B?UURkMzU3UHNjZTlvclRwL3BKNWtSaEhtMnN0OFpKb0dvU2Q0am01Zitub25a?= =?utf-8?B?dm9YSW9WVGRMeHBDRXVDVWhtVGhLdXByOEltNEMwSjdmZjloVis5cWNyTHhk?= =?utf-8?B?b2pHU2MrTXVUa1JHOUg1WVhDczhjdEZXMHZTcDlMTlF2aEpjUnlBbm92R05M?= =?utf-8?B?NjY5WHY1SnJZR3hKcEx4bW9iVkZ5VFhzalVlSmN6ZTBaZndmVFlBZVpNNzNE?= =?utf-8?B?MXVlalo2TzFkYk5CUW5DQmIvZnc1ZEZ0QnVoK2xjYVQvOTBuOWx3ZWJ0TGEr?= =?utf-8?B?eWtTSm9KWjhEQVBqKzdqZmVvcE9BNHQwMzJ5aWZWZnZRSEdVcjJma0RXMUZk?= =?utf-8?B?cGxjS052dXF1amVxVWNRYml5SERLZTRNTmNES09uNnJTMlFuRmdjUFFoYWJP?= =?utf-8?B?MEQrTzc4eGVWQThxV2RiczdsNER4UktOandiRWtKbVJNT2dYYnBocEVuNndw?= =?utf-8?B?Y0drKzNiOXQreUk4NUZ2czhBbGdzbXBuVFFvWkJWYlltYWZwRGdzUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49161fc9-a3ce-44a3-c5f5-08df335c7b58 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 12:27:21.0080 (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: qQDyTD26bLaheoDw74p+dfSprcU0Ax39Vl7H//WO0fjhwHwZdhk7u07lIbQQ02sQ06RJgUtemf2lEgmg+6vPq+/e2aFrWcIMfvVxeBWtTIo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5388 X-purgate-ID: tlsNG-ef75cf/1793017734-A64DBAE4-7D2341C5/0/0 X-purgate-type: clean X-purgate-size: 6039 On 20/10/2026 2:57 pm, Furkan Caliskan wrote: > The raw 64-bit constants in boot_gdt[] and boot_compat_gdt[] hide what > each descriptor actually is. Replace them with a GDTE() macro, modelled > on Linux's GDT_ENTRY_INIT(), plus named GDTE_FLAGS_* constants and a > GDTE_FLAT() helper for flat segments. > > No functional change. > > Signed-off-by: Furkan Caliskan > --- > xen/arch/x86/desc.c | 61 +++++++++++++++++++++++++++++++++++---------- > 1 file changed, 48 insertions(+), 13 deletions(-) > > diff --git a/xen/arch/x86/desc.c b/xen/arch/x86/desc.c > index 9f63928154..647affb6a3 100644 > --- a/xen/arch/x86/desc.c > +++ b/xen/arch/x86/desc.c > @@ -27,32 +27,67 @@ > > #define SEL2GDT(sel) (((sel) >> 3) - FIRST_RESERVED_GDT_ENTRY) > > +/* > + * Expands to a brace-enclosed initializer for seg_desc_t; only use it > + * inside an initializer list. > + * > + * flags: bit layout matches its position in the descriptor's high dword > + * bits 0-3 : type > + * bit 4 : s (0 = system, 1 = code/data) > + * bits 5-6 : dpl > + * bit 7 : p (present) > + * bit 12 : avl > + * bit 13 : l (64-bit code segment) > + * bit 14 : d/b > + * bit 15 : g (granularity: 0 = byte, 1 = 4KiB) > + */ > +#define GDTE(flags, base, limit) \ > + { (((uint64_t)(limit) & 0x0ffffULL) | \ > + (((uint64_t)(base) & 0x0ffffffULL) << 16) | \ > + (((uint64_t)(flags) & 0x0ffULL) << 40) | \ > + (((uint64_t)(limit) & 0xf0000ULL) << 32) | \ > + (((uint64_t)(flags) & 0xf000ULL) << 40) | \ > + (((uint64_t)(base) & 0xff000000ULL) << 32)) } > + > +/* Common flag combinations (same values Linux uses for equivalent segments) */ > +#define GDTE_FLAGS_RING0_CS64 0xa09b /* P DPL0 S code RX A, L, G */ > +#define GDTE_FLAGS_RING0_DS32 0xc093 /* P DPL0 S data RW A, G */ > +#define GDTE_FLAGS_RING1_CS32 0xc0bb /* P DPL1 S code RX A, G */ > +#define GDTE_FLAGS_RING1_DS32 0xc0b3 /* P DPL1 S data RW A, G */ > +#define GDTE_FLAGS_RING3_CS32 0xc0fb /* P DPL3 S code RX A, G */ > +#define GDTE_FLAGS_RING3_DS32 0xc0f3 /* P DPL3 S data RW A, G */ > +#define GDTE_FLAGS_RING3_CS64 0xa0fb /* P DPL3 S code RX A, L, G */ > +#define GDTE_FLAGS_PERCPU 0x0091 /* P DPL0 S data RO A */ > + > +/* Xen maps every flat segment across all of memory. */ > +#define GDTE_FLAT(flags) GDTE(flags, 0, 0xfffff) > + > __section(".data.page_aligned") __aligned(PAGE_SIZE) > seg_desc_t boot_gdt[PAGE_SIZE / sizeof(seg_desc_t)] = > { > /* 0xe008 - Ring 0 code, 64bit mode */ > - [SEL2GDT(__HYPERVISOR_CS)] = { 0x00af9b000000ffff }, > + [SEL2GDT(__HYPERVISOR_CS)] = GDTE_FLAT(GDTE_FLAGS_RING0_CS64), > > /* 0xe010 - Ring 0 data */ > - [SEL2GDT(__HYPERVISOR_DS32)] = { 0x00cf93000000ffff }, > + [SEL2GDT(__HYPERVISOR_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING0_DS32), > > /* 0xe018 - reserved */ > > /* 0xe023 - Ring 3 code, compatibility */ > - [SEL2GDT(FLAT_RING3_CS32)] = { 0x00cffb000000ffff }, > + [SEL2GDT(FLAT_RING3_CS32)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS32), > > /* 0xe02b - Ring 3 data */ > - [SEL2GDT(FLAT_RING3_DS32)] = { 0x00cff3000000ffff }, > + [SEL2GDT(FLAT_RING3_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING3_DS32), > > /* 0xe033 - Ring 3 code, 64-bit mode */ > - [SEL2GDT(FLAT_RING3_CS64)] = { 0x00affb000000ffff }, > + [SEL2GDT(FLAT_RING3_CS64)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS64), > > /* 0xe038 - reserved */ > /* 0xe040 - TSS */ > /* 0xe050 - LDT */ > > /* 0xe060 - per-CPU entry (limit == cpu) */ > - [SEL2GDT(PER_CPU_SELECTOR)] = { 0x0000910000000000 }, > + [SEL2GDT(PER_CPU_SELECTOR)] = GDTE(GDTE_FLAGS_PERCPU, 0, 0), > }; > > #ifdef CONFIG_PV32 > @@ -60,29 +95,29 @@ __section(".data.page_aligned") __aligned(PAGE_SIZE) > seg_desc_t boot_compat_gdt[PAGE_SIZE / sizeof(seg_desc_t)] = > { > /* 0xe008 - Ring 0 code, 64bit mode */ > - [SEL2GDT(__HYPERVISOR_CS)] = { 0x00af9b000000ffff }, > + [SEL2GDT(__HYPERVISOR_CS)] = GDTE_FLAT(GDTE_FLAGS_RING0_CS64), > > /* 0xe010 - Ring 0 data */ > - [SEL2GDT(__HYPERVISOR_DS32)] = { 0x00cf93000000ffff }, > + [SEL2GDT(__HYPERVISOR_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING0_DS32), > > /* 0xe019 - Ring 1 code, compatibility */ > - [SEL2GDT(FLAT_COMPAT_RING1_CS)] = { 0x00cfbb000000ffff }, > + [SEL2GDT(FLAT_COMPAT_RING1_CS)] = GDTE_FLAT(GDTE_FLAGS_RING1_CS32), > > /* 0xe021 - Ring 1 data */ > - [SEL2GDT(FLAT_COMPAT_RING1_DS)] = { 0x00cfb3000000ffff }, > + [SEL2GDT(FLAT_COMPAT_RING1_DS)] = GDTE_FLAT(GDTE_FLAGS_RING1_DS32), > > /* 0xe02b - Ring 3 code, compatibility */ > - [SEL2GDT(FLAT_COMPAT_RING3_CS)] = { 0x00cffb000000ffff }, > + [SEL2GDT(FLAT_COMPAT_RING3_CS)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS32), > > /* 0xe033 - Ring 3 data */ > - [SEL2GDT(FLAT_COMPAT_RING3_DS)] = { 0x00cff3000000ffff }, > + [SEL2GDT(FLAT_COMPAT_RING3_DS)] = GDTE_FLAT(GDTE_FLAGS_RING3_DS32), > > /* 0xe038 - reserved */ > /* 0xe040 - TSS */ > /* 0xe050 - LDT */ > > /* 0xe060 - per-CPU entry (limit == cpu) */ > - [SEL2GDT(PER_CPU_SELECTOR)] = { 0x0000910000000000 }, > + [SEL2GDT(PER_CPU_SELECTOR)] = GDTE(GDTE_FLAGS_PERCPU, 0, 0), > }; > #endif > I don't see this as an improvement.  All you're doing is putting a layer of indirection, and moving the attributes away the comment explaining what they are, and the attributes are still raw. If you really want to macro this up, then at least use INIT_GDTE_SYM() from XTF or MiniOS.  That way you get things in a legible form at the end. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:34:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:34:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461251.1672230 (Exim 4.92) (envelope-from ) id 1xLJu4-0005Rb-HX; Mon, 26 Oct 2026 12:34:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461251.1672230; Mon, 26 Oct 2026 12:34: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 1xLJu4-0005RT-Df; Mon, 26 Oct 2026 12:34:16 +0000 Received: by outflank-mailman (input) for mailman id 1461251; Mon, 26 Oct 2026 12:34:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLJu2-0005RN-UL for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:34:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLJu1-00GiSy-VF for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:34:13 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf48b3-2eae-0a2a0a5409dd-0a2a4505cc36-36 for ; Mon, 26 Oct 2026 13:34:13 +0100 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf48c5-4cb1-0a2a45050019-d1558030a9fd-3 for ; Mon, 26 Oct 2026 13:34:13 +0100 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a2072b9832so20621425e9.1 for ; Mon, 26 Oct 2026 05:34: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-48e3ebcb90dsm14817858f8f.22.2026.10.26.05.34.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05: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=1793018053; x=1793622853; 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=6pFjLNmWXuu2WEFu2QcsD11soqSfI8L3JokaqcvE5hw=; b=dZubWSsawlC2h4oVyO8yOR8/u828ht8TL5kmcicGlUhMiC7fhlE1APFN1+jEuCQVM1 ffUp7Lu/iNde8j5nNgkYG2hxOb+3whbWcOzJriuTBx+8/h3w/sx70EdmpY7GcdUxBuce 0Z3wIlYAU/TDxCiAzQP7XgW5FBaty4SXNrCZ1zAKdjm/Jm4SPXH/2rYTBKCae508xAGB u5aHq0zMDZsiFDWzn7Nb36L6ut2DM+8UtyJU+WUa6661/Y2iMIjjomR5WmQgCG+G8Poh 7mTs2RYYpw6kWhPElr0rzhf6hkDNJkpLygHBsB6NNT6VGgFwm0/qSCLfxJItdHaaYpIt skQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793018053; x=1793622853; 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=6pFjLNmWXuu2WEFu2QcsD11soqSfI8L3JokaqcvE5hw=; b=p4v4PtuZlGLwKhh89p4pmSA53bc6DiRzVhrNuKYhcHex2hn3Zc5pThboTP3ZEdjlgA RZlAUoIfZpPMsYS9ubcoPPEoG/jDI7rbirMaLkyx1sQwfcXzFp0WQxUoioRPAFJdHhN3 pdlEylUGwJ+bclTEuRQAjm8KaA0P+rAsSDbpGO20Qkr6TiKNbK45VGBXQvoFiBXu4lKP ICH9KnWzJUtfeoAI7BmeKYyF/UxNQhn5XI4Z8cDhbW9U/nTfCuH6FfSCD5c9GKDzHpVN zq5lTorj53Bf5RqCRTbOBYdGJi/Pw7pGpqEjmbOenTQLh13Teszj4npWgATVM8ofQqYW 0Xfg== X-Forwarded-Encrypted: i=1; AKwUvBySAuRoaGCNnAoomNBwrcD7j3CFUI1klFxA8t952MTDigNMYJrbavUp5ztV7r/inG47JhxGv4MT8Nc=@lists.xenproject.org X-Gm-Message-State: AFq9FYK7e2L4Qn9V1l765x72aqXQA7N7ERLT3TeXRbdlolC/1/xDljCH lFZYxWXsQJXeVp3GCIC59jZVh7gA8A25rpTV9RVHUc7LQd5VPdVr6mC4A5qzcAdmCA== X-Gm-Gg: AYBFou38EkZTXDxZLovejfUpeGQfmypne99GtDstNWP0y+99BeISdJ0HSq53BgaW4WZ FkLX2XkocJU2GJWDXGW/DO+YBDK16gxzcGZJsELgHjB2LSKR4YGeeteFzO79nUD8OrOxkWQ3kY4 TIPh826K16Fu4pQxZ7L4oGktlxe6wQqPmiwHMNWrWs5Zp+Ti3nkFlvIcpEWmcCPoXOh0H8oLvyO 1F2EsrLZNYknEJV2ssqQpFUQTATvu++/8CY301ObY0zPoco5+nkWEpZo5FKhpM/kNNWClJwX9zm sJQQZSLljDyvAFZCrs9o5h+ISpMXfv6X491eqryQIcq6XLJZWWIB8JIoIFAIw6dbt7q+8rbkYgG ZNW1KTjrA+ZRZeWbxin5lDbrmK4/UMjQbxqKfFShR8UM7ybbcEriBtb37j3qnqG2sMjY5VnZlFO HSfwg3eGoN65Pwkd7LbQQsnlxLz40R+NjBT8AfvqKtuyx+BaVGGVv1pzXopx6kSkaWPBya+6veI oPlRo8Vw2niibvrFw1vGIqUv29wr57RYGA+aHujMjmbeqonYASRA8KYSM86bVJQ7AEnjC44YSEc qQZ2suX/L+48p1ulWuMDoZrSI1b26GBiT5gIBZ/wIiH6KQ/EfzFU9vCUXPjYjI/mlw== X-Received: by 2002:a05:600c:3395:b0:4a2:1104:7ca7 with SMTP id 5b1f17b1804b1-4a35ac99833mr79836015e9.11.1793018053241; Mon, 26 Oct 2026 05:34:13 -0700 (PDT) Message-ID: <8b2fa10a-17ac-4807-b9d2-874f84a85efc@suse.com> Date: Mon, 26 Oct 2026 13:34:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code To: Mykyta Poturai Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand , "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-c201ff/1793018053-F62AB2A1-F5BD3DD4/10/78276251493 X-purgate-type: spam X-purgate-size: 1664 On 26.10.2026 13:27, Mykyta Poturai wrote: > This is preparatory work to make vPCI MSI-X functional on Arm. Split the > vPCI MSI-X code so that intercepting the MSI-X table and PBA stays x86 > only, This likely is related to peculiarities of Arm's interrupt handling, yet on the surface I can't see why not intercepting MSI-X table accesses would be safe. Would it be possible to extend background here a little? > while the MSI-X capability handling becomes common. No functional > change intended. > > This is a continuation of work done by Rahul from February 2022[1]. > > The approach is inverted, instead of moving out the x86 parts, move out > the common ones that will be needed on Arm. Subsequent arm patches for > reference can be found here[2]. > > [1] https://lore.kernel.org/xen-devel/cover.1644937405.git.rahul.singh@arm.com/T/#t > [2] https://github.com/stewdk/xen/tree/pcie-passthrough-arm-vpci-v26 > > Rahul Singh (1): > vpci/msix: move helpers to common > > Stewart Hildebrand (2): > vpci/msix: move msix region removal to msix.c > vpci/msix: move common msix code to common file > > xen/arch/x86/include/asm/msi.h | 21 --- > xen/arch/x86/msi.c | 2 +- > xen/drivers/passthrough/amd/iommu.h | 2 +- > xen/drivers/vpci/Makefile | 6 +- > xen/drivers/vpci/header.c | 30 +---- > xen/drivers/vpci/msi.c | 3 +- > xen/drivers/vpci/msix.c | 197 ++++++--------------------- > xen/drivers/vpci/msix_common.c | 202 ++++++++++++++++++++++++++++ Nit: New file's names want to use dashes in favor of underscores. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:44:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:44:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461258.1672239 (Exim 4.92) (envelope-from ) id 1xLK3y-0007pC-DW; Mon, 26 Oct 2026 12:44:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461258.1672239; Mon, 26 Oct 2026 12:44: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 1xLK3y-0007p4-9g; Mon, 26 Oct 2026 12:44:30 +0000 Received: by outflank-mailman (input) for mailman id 1461258; Mon, 26 Oct 2026 12:44:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLK3x-0007oy-HL for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:44:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLK3w-0073VM-N6 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:44:28 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4b2c-e002-0a2a0a5209dd-0a2a4505dd78-0 for ; Mon, 26 Oct 2026 13:44:28 +0100 Received: from [52.101.52.52] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4b2a-4cb1-0a2a45050019-346534347b7b-3 for ; Mon, 26 Oct 2026 13:44:27 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA0PR03MB5612.namprd03.prod.outlook.com (2603:10b6:806:b8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 12:44: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%4]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 12:44: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=hniKO16MqvuLtZq9tLexzSiQ3XB1tXNdSz2VHAnPMLJVTfWCE4TIChQB1u1/uZzb7OA9M+dQNreVZxFjsjOLQreP8JhYlTERcR6CkpZaJtXWnCXlkT96opM97+4ydCv0dsz91LbERdQ73nu1ZJkXJd4LWX0M7fXKil+t7EuCuotQOvAPxC0Ws8g2O5dAGWcWogHIUwjzn6k14gne7xZerTBOwRKoILtTd7I2CoXAMutQyCgt0PzgH/saGpn3V86PKlFHlBHwlkIKouliX5UK3zBg9z79IvRxCs+SeCMdFTcUiutl5nsWIdUsn0GAd37okB5g13nhXrmD8UJeLTZC5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2AF6Dgqzg7xsQOZ3aEJveKiggQcWSgysRWMaFgu5ZEA=; b=zDxbeAxTP3rCG+1XBU732jHnjLm+0uqZUqX2lFBFgMQ9B5uQxYjUeZrOgvd3zBFdW2VUK0rLNC/6KAYpQAne7te+WYPkvh1FF+FAI2rkG0RS3Mq9ALI7RHdhryDrE/p/D06Ni+XqVJ4K7N74i0d+XUi/yfH6NIt5dhgUVQ5naL0zfJMARAACbRgCd7XuANcteJhTFAWaIc/cU5pyqbLtH5Tcv+ZrayQOhAePMPujgI3aYVN6xHarOW5OMAA/TyuJIdxzH3vLZJpU/4T4vZ9M0Tq2dm/8tV19fagLESOBwWCqNjQVvdCQR9fIz+MYpP/v+3cFjPfI5Ifa0gl8n3HG7w== 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=2AF6Dgqzg7xsQOZ3aEJveKiggQcWSgysRWMaFgu5ZEA=; b=tPoheoHMPCkVPZPjeWDeMf6umVoQpgLkVPOvWr2NEE7bn5QP7KLrwUvhdnBnSSlITiIygXwcLPYpWljYma9SIFElN4rz/8dA00gHFtpr1dpY2CPqLDBq5WxFeEjBU4k82Q5Z2LY4BDsfa6YLSuj0pja3AO02Al1OweW/6FXum7s= 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: Mon, 26 Oct 2026 12:44:19 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Rahul Singh , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand Subject: Re: [PATCH v1 1/3] vpci/msix: move helpers to common To: Mykyta Poturai , "xen-devel@lists.xenproject.org" References: <688f3bb393590fc5bfb54328112fde1359bf44c4.1793012250.git.mykyta_poturai@epam.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: <688f3bb393590fc5bfb54328112fde1359bf44c4.1793012250.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PR3P191CA0004.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:54::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_|SA0PR03MB5612:EE_ X-MS-Office365-Filtering-Correlation-Id: d7c7a6fd-1817-4406-d4da-08df335edd46 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|366016|18002099003|22082099003|56012099006|11063799006|4143699003|10067099003|261022105027099003; X-Microsoft-Antispam-Message-Info: 24hoe/nRDaSQWlLH/APoGtVoJ1U8NLXI4eV5VTfd41aWjN3HbEwl8uC8HClixme7kwRx27iw7i68Xw3hPL8zmOFTVnusviYIo2kmSH5M1rMnY2+Y6b8UtS8DsJw0niAZD77mviKjShKlmq3m09RerMXHO4INq65aN2VnFDBgd27I/H+vARTevr4uPTO7apmZ4UjoIB3hIGML5AwrzuMiRqpsqvouuFe8QZHiBmCD4AVqHtYP/6+X2Ad3jmm1CzjB6bnY5ccF5CokZ3dDQo8EhVhlpYw4hl/gZddIs3vZ+jzjk2xJxeMa+GWcJxTIlE7y3BpSuLjXy6eWlhXghtQxtxH79S39L3J3kR3oDGG8fJUNZ9DnL6BlkRImTxaNRp0FetkNu8cDLM4vK/cb+qgYbOa/wSp7S+GqGDNFx2037nMVLy91YoXmM1uv/MHSFHRskBZe11ajYzwHaJu+/BtdkbF5y/faM3AzUJGYpJ/d830pZ8hrh9Xo7THlPqNlZlbKYnnxpddllhWI1nlXvMl1gcQIz+CovQONhAPzONcC5Vvp2/h4FP8L1TIkMlp/xhHfeOgXjsy2ugce7msra8/3Rr1phPObeY+9Q4MQqvwh4gvQ2RwAQqcLePd4yPRr67KCv/ER84TtqF+t5xH6zfH1IHYiNpHHvSsXZRGhYDIj7tc= 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)(7416014)(1800799024)(366016)(18002099003)(22082099003)(56012099006)(11063799006)(4143699003)(10067099003)(261022105027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SnYzZENSWnR5U1crVnp1bW9BbDN0UEVDSzBpVzNVRzBkRHVqaWlkVDhLU3hB?= =?utf-8?B?K0RDRnNXTU8xdGJsWWJPZHZQMzN3ZUlZMmpHR1ZmSVhlNEMyOHhxdUpNODNI?= =?utf-8?B?WXpxWFNrSzVybVd5cnBidU1ML3lUV0lxNzVaZXpMWlorb015NzFieXNOYzhT?= =?utf-8?B?dGY0SU8yaEpVVlVzQWxkKytnSHZxeDVuVWE3UTZ6d1N5aUt2VzltYTlrUDg5?= =?utf-8?B?S1JpZDlzTDVob0hnN3F1ZzBxT3pVckoxZVBKdzJWM25EclRhb1lmTDcwejNn?= =?utf-8?B?bkZaYzZhdlVVSm5Kd21lbGhReGJJUFZlam5MbVN5Zm5PTlZXN2pMb2w0ZEVF?= =?utf-8?B?bmVIZnhUdEx1Rms3cG5IMnFzTDV4NHVTT241c3VKUmJUVW9vZ3FIdDdVWnlt?= =?utf-8?B?S3JsUzdiZWtKVTA2aWNjL3R3enRPUVVmeW8yKzBuL1l2R29pTDc1OGtoSFlV?= =?utf-8?B?TEI2SzVpZkRMQmhES085cUdsekdhaSt1R0xYc1hyYzVMOEtHYUdERVRGZzJk?= =?utf-8?B?NlEvT2o3ZzV1dGNFU1ZtQWdYdTZHL3dDNkZTdmMxOUZnNHZ1b09iRmxnbGdr?= =?utf-8?B?bzZHdXdIeXhpdWo2T0NvUnU1VE91Sk1HTituMEdmQks1WlVHMnFVRHZ6RW16?= =?utf-8?B?MlBjUWhtMWtWV1laem9vVnZwNnE0TzBhSFN4WUF3NHNUdGZCZC9OcXdROC96?= =?utf-8?B?eDZDQW53K01ZZ1pGNEQ5RVgwTWl5RENiMXo0ZUx4V1U4YTRxTGhiS1E2Z0dz?= =?utf-8?B?TGtMQitnSGFHS3JIaVB4MlRnQTQ2Y2ZaZ0RtVGozSzh6SDJVMnAwRTJRTVJo?= =?utf-8?B?bUVMRFd0bkpsQlBBN0dETC9qd1QvMzlMdmFwSFh3VHRXRVJ3ZVdIOTlsNTND?= =?utf-8?B?MmRESkhqZnE1WFhtSml5ZGlPSDRGWEh6UFdpaWFxQkUvRWtKNEpqUXhSOWFu?= =?utf-8?B?cXl2UG9yaVlaNjNLZVRyZTVEUGdYMHJJc2RNVGRBZUZ4aUg4NXNBbzRBZ0JE?= =?utf-8?B?aWsvNzRyZVdoMVJrNmVOWDJkWUc1V3FOcFVTVHpWd1FkQjZpV2U0WnRGY05O?= =?utf-8?B?TjZEWXQ3RGhTUDB0N2VhQWJNR1hDcUkxL1JmM2YzRlB1RkpOSENVdGRFaFEr?= =?utf-8?B?MUlKaVJrM2VrWElwdWNvZXNGMzJyT1JIWEZKUnowQ3ZDQ0dEdWFxSEhNTkg5?= =?utf-8?B?OFhnSTN5RjRPaWcydTZJNzhKSHlKMHRLaXVDcXg4ZjVqVmpZK1hTVEhNbGVP?= =?utf-8?B?TDFhL2JYU0ZyNDcyaXhwbXRsL3pkZ2I3U2dOL3NRd1VHWWoxNDVTWlE3dzhN?= =?utf-8?B?eXlJR3JtSFlCZVVGM2FkRWs2UDhKaTBTVFgyUXAvL3JydzllcGsrM3RyWndB?= =?utf-8?B?UDBaaUZtVXJUQzFNeFhReElFMGpxai9Xa1huQ0ptNnpvQU4vMGhjdFRoeFU3?= =?utf-8?B?SU00MGsrWjBwV251a1kzZ3Z2Skx2QWdwWGUwZGdFNHBZdU5OakNVNFk0TE00?= =?utf-8?B?SStlL3AxTHA1SHVsWm5QaWNUUnIvaWFLajdBZkMwaDFwQXBYY1BpZTRHdDlq?= =?utf-8?B?OVp6bHhWdWxCUTJtV2J2bU03VlNIWExwVUxtR0tFNThhbk5HMEJaeGdYSk5C?= =?utf-8?B?elh5R2hiaCtGQ1NNbTdRNGFhVTRnaHd6NXBMM1htRDJWQjdzMjRUZkovU29W?= =?utf-8?B?dm9VT0pISkdXTDcwMEVxcVBoNTRKZnJIa08xS0ppYTRzNnR1azhKdEZabEhr?= =?utf-8?B?bGRPdDNzMmZoZldWZE9uSFVLYm11TW5yQUVsMkliVTM3emhObEtPSG1DMlVC?= =?utf-8?B?T3VSSFJ5UnB1UzdpS1JERWk3VUVHLzVlaWxZcko2VE1YYllLeG9EajdaMEVn?= =?utf-8?B?djFOSmFRZUtGWG1uV2hWK3EyNTRuMHYwMUVvVGJEbHBVZ3RLcmpRaTZrd0ND?= =?utf-8?B?b2ZMdVV0VEdrUm5vWDJtOXdSWVBkTXc2RHBmQjI1OGxhcGNMSWdrV0JaTTZn?= =?utf-8?B?aTArTjEwb1pDY2w4eUFMUEZsSjN0SUJuUitHMkxSYnJldndUODVVaVZDU3VL?= =?utf-8?B?MnJkNzdqZFlRVHB3cDBzM1ZZbWkrdkFjc0tzNFJOL1ZId0Yvb2xFdnVHblVS?= =?utf-8?B?a0RwT3AwQzRGWmRBLzZ6SEx5NDY0OFVpQ2J0T2JoOVAwbkVIb01zT09mMits?= =?utf-8?B?SnRURHd5RXJoaFU1c3hPQkZ1b05yU3BubWNDc01PSzNPZHpkTVZscHdQalE1?= =?utf-8?B?a3ZHWjZSY1I4YVY5RXI5U1BIaEZWbzQzTUJiQmhVMWRLd3loNTVWbjQrYUFl?= =?utf-8?B?UHlXcGo1SWdCQjZDclZmbDdVK3Z3aE9ORmVEVDVEQWxJalBuZkE5UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7c7a6fd-1817-4406-d4da-08df335edd46 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 12:44:24.2874 (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: fiVJa+0RiLQG5YY8Og6NmmvK1R8xStzHUafHgjgX8eA+VEFr9i17V9IBNjLB86bgaK+7yd+559MD2HHgtjqqEEWfc9v8+4jhIrLgwwWJru0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5612 X-purgate-ID: tlsNG-c201ff/1793018667-738BE2A1-25543DD5/0/0 X-purgate-type: clean X-purgate-size: 441 On 26/10/2026 12:27 pm, Mykyta Poturai wrote: > diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c > index 8831ce068c..5e4e89b3c0 100644 > --- a/xen/arch/x86/msi.c > +++ b/xen/arch/x86/msi.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include Please keep the headers sorted. Probably best fixed up on commit, by whomever takes this patch. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:45:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:45:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461265.1672246 (Exim 4.92) (envelope-from ) id 1xLK4m-0008MY-Ok; Mon, 26 Oct 2026 12:45:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461265.1672246; Mon, 26 Oct 2026 12:45: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 1xLK4m-0008MR-Lz; Mon, 26 Oct 2026 12:45:20 +0000 Received: by outflank-mailman (input) for mailman id 1461265; Mon, 26 Oct 2026 12:45:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLK4l-0008M4-BJ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:45:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLK4k-00E0Pk-Nr for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:45:18 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4b3e-2eae-0a2a0a5409dd-0a2a450b8d28-46 for ; Mon, 26 Oct 2026 13:45:18 +0100 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4b5e-b7e8-0a2a450b0019-d155dd35acd8-3 for ; Mon, 26 Oct 2026 13:45:18 +0100 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48e3b22e971so1289172f8f.0 for ; Mon, 26 Oct 2026 05:45:18 -0700 (PDT) Received: from [192.168.1.109] ([85.107.102.204]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ebd4bc5sm16141257f8f.34.2026.10.26.05.45.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05: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="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=1793018718; x=1793623518; 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=dfrgde6/9Gl+b3+4NAwY8dGist6ThWQHNYcUVUJ+lDc=; b=ZFRUF1PP4i3dGFVCEBIhHz+Tgki3ynQLiURP+dMeuO+HQeg6o3uNQDnyJ15ZjWDqd7 7kn9sO4gZDWlbtF+2o1iuP7fzVfHgOoHeeow5+PFNEVjNCgPmzAkVC2doeSfKlQooDgr 0MEcDXVWOPGDldyUXyRWeOZpXSBXf/xQe3+l2ul6xehejGeh3EQ0yofbzw9Dg6n61P2J gO66ADnBbjR0SkOtDbOqyUDhfWWebOKGccxIVqvmkf8nLSQZcO+BgFcy/UQlUTc1IqcM 9AmcRgL1CSZXGYr1l4Vcb3ep5p10jAJFY1oMaUdmZix+V6lkd4jE43dYpxgwfZmGNSj7 v+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793018718; x=1793623518; 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=dfrgde6/9Gl+b3+4NAwY8dGist6ThWQHNYcUVUJ+lDc=; b=GdwHDnJKYSjBqvZEfkJqpgGz7Von2Qzu2lVxbdufJe7TjMgs8TMx3b3/D2bpYihkkL aoRBblGbfa+f3yaYWayZRVxLL1LcHukI0aXDoYSVGpMKfOBuBmPkgdJPYm4fZDexETHQ EZeM9BCxreg8L6sfIuWf7MnSK1fSqPZJLMVQFZcAfoOsvZvUKG3ZGY2lpdy7zFOw0X1m 7o1XHPBjbdBJEnOHD4fdZzNw0gngaDe5gANkYGkhD1LMpHFevSJsl915SfHoTOlItGLz g0D4ROGuXaxr9YQ2YhHLbZUH+vpDvXK1dhqsbDwJn/t+cTZucFXko4gan20SxcWV3uyw CTTA== X-Forwarded-Encrypted: i=1; AKwUvBzTmriNuKDyBnjM+K7HFI6z4DpNAS7QmdXG/GMIkb/h/hNhrih3h0kYktOS18JXvKNr+7DWFtmkRFg=@lists.xenproject.org X-Gm-Message-State: AFq9FYK0+YU08NbEd9m4xV3LkDQ0D3wz7GiWo/0F88GkB+rC9ZNgjagD ROY4P4NieIzF8nf6Y1kRPSUCLeQkCO5gXKbjXGk6dmc0D9vGNQTO3bAR X-Gm-Gg: AYBFou1bgluhH28xylnx2rE2XTlpU7NYFhaJYxJMC+Gv9riUAtIe1tjZLom8Dnagdot IlbEYFtpQC4/JqVMl779jzuPMNO2sb3qARLLsIOkbpVKz2B8JUiV9FOR3RlNxn0dmrAzvzQRuf4 ibvmbyxz9SK9c50sPFxmpDKwEQNjEHk5W64X/4TKHfw7dG6o+nywm3Z+NbGQw6yvNggkdO70lNn +SmVMWtJT8YQOfe5Wi9nAUV3eE+hdAVilvGVgTAkjmJegVE8mIRHZvHKNJgNWW8y8vRlBGFTVib /2WJ2NAm50dtC5J/pac7eK9bMg824weY+m4uYxp9+80FcS1eO6oXvsg4w6rHo1B2/aCGrb9O31A 2gzWLTokVmywbSu9GDUUxwLX8lbukvYAsnkjZxuc62W9LAeGMbKBj/zcon3eNHLkPobKlnpAzDR IjUs+ph7XGqvY/VyQa891cnvnDTIO5ERfZi8bGaz+gy8PFMVItqKtI2Jgc106n8Jy5fNO6YWqgR tO6InyM2vu0fip6VRg+YFAKvnc2G8Ffif6HPNgNpm9mjDfpzGNnEDOp84mSQOpZejoGmA9uP99P xnhM86DD X-Received: by 2002:a05:6000:40ca:b0:48d:faa6:cedf with SMTP id ffacd0b85a97d-48e3eb9c0e9mr11904889f8f.56.1793018717694; Mon, 26 Oct 2026 05:45:17 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 15:45:12 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/desc: build boot GDT descriptors with a macro To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261020135722.45714-1-frn1furkan10@gmail.com> <84fee7e4-ee15-4e56-8db3-f5d2db5ec2e2@suse.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <84fee7e4-ee15-4e56-8db3-f5d2db5ec2e2@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1793018718-AAAD89EA-123EF7BC/0/0 X-purgate-type: clean X-purgate-size: 3717 On 10/26/26 15:15, Jan Beulich wrote: > On 20.10.2026 15:57, Furkan Caliskan wrote: >> The raw 64-bit constants in boot_gdt[] and boot_compat_gdt[] hide what >> each descriptor actually is. Replace them with a GDTE() macro, modelled >> on Linux's GDT_ENTRY_INIT(), plus named GDTE_FLAGS_* constants and a >> GDTE_FLAT() helper for flat segments. >> >> No functional change. > > Can this be "upgraded" to "No change in generated code" or some such? Else: > Are there changes in generated code? I compared the generated code before and after, and it is identical. I'll state that in v2. > >> --- a/xen/arch/x86/desc.c >> +++ b/xen/arch/x86/desc.c >> @@ -27,32 +27,67 @@ >> >> #define SEL2GDT(sel) (((sel) >> 3) - FIRST_RESERVED_GDT_ENTRY) >> >> +/* >> + * Expands to a brace-enclosed initializer for seg_desc_t; only use it >> + * inside an initializer list. >> + * >> + * flags: bit layout matches its position in the descriptor's high dword >> + * bits 0-3 : type >> + * bit 4 : s (0 = system, 1 = code/data) >> + * bits 5-6 : dpl >> + * bit 7 : p (present) >> + * bit 12 : avl >> + * bit 13 : l (64-bit code segment) >> + * bit 14 : d/b >> + * bit 15 : g (granularity: 0 = byte, 1 = 4KiB) >> + */ >> +#define GDTE(flags, base, limit) \ >> + { (((uint64_t)(limit) & 0x0ffffULL) | \ >> + (((uint64_t)(base) & 0x0ffffffULL) << 16) | \ >> + (((uint64_t)(flags) & 0x0ffULL) << 40) | \ >> + (((uint64_t)(limit) & 0xf0000ULL) << 32) | \ >> + (((uint64_t)(flags) & 0xf000ULL) << 40) | \ >> + (((uint64_t)(base) & 0xff000000ULL) << 32)) } > > As you only ever use this for GDTs, the macro name here is okay. However, ... > >> +/* Common flag combinations (same values Linux uses for equivalent segments) */ >> +#define GDTE_FLAGS_RING0_CS64 0xa09b /* P DPL0 S code RX A, L, G */ >> +#define GDTE_FLAGS_RING0_DS32 0xc093 /* P DPL0 S data RW A, G */ >> +#define GDTE_FLAGS_RING1_CS32 0xc0bb /* P DPL1 S code RX A, G */ >> +#define GDTE_FLAGS_RING1_DS32 0xc0b3 /* P DPL1 S data RW A, G */ >> +#define GDTE_FLAGS_RING3_CS32 0xc0fb /* P DPL3 S code RX A, G */ >> +#define GDTE_FLAGS_RING3_DS32 0xc0f3 /* P DPL3 S data RW A, G */ >> +#define GDTE_FLAGS_RING3_CS64 0xa0fb /* P DPL3 S code RX A, L, G */ >> +#define GDTE_FLAGS_PERCPU 0x0091 /* P DPL0 S data RO A */ >> + >> +/* Xen maps every flat segment across all of memory. */ >> +#define GDTE_FLAT(flags) GDTE(flags, 0, 0xfffff) > > ... nothing in any of these constants is GDT-specific, and the FLAGS infix > isn't very useful there either (albeit I probably also wouldn't outright > insist on its dropping). Agreed. Following Andrew's feedback as well, v2 will drop the packed flag words and the GDTE_FLAGS_* names altogether, and instead spell out each descriptor's attributes symbolically at the use site. > > As to the GDTE_FLAGS_* constants' comments: The P and S bits (which are only > ever set) are mentioned, while the D/B bit (which varies) isn't. For the > constants themselves, there's clearly redundancy with asm/desc.h's _SEGMENT_* > constants. Possibly those could be used here, perhaps eliminating the need > for those comments. I'll look at reusing the _SEGMENT_* constants from asm/desc.h for the attribute bits rather than introducing new ones, and make sure D/B is covered, since it varies between the entries. > > Jan Thanks, Furkan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:46:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:46:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461272.1672256 (Exim 4.92) (envelope-from ) id 1xLK6B-0000U1-2l; Mon, 26 Oct 2026 12:46:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461272.1672256; Mon, 26 Oct 2026 12:46: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 1xLK6A-0000Tu-Vy; Mon, 26 Oct 2026 12:46:46 +0000 Received: by outflank-mailman (input) for mailman id 1461272; Mon, 26 Oct 2026 12:46:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLK69-0000Tk-Qm for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:46:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLK68-00Gl6b-Ql for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:46:44 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4bb0-e002-0a2a0a5209dd-0a2a450ce702-20 for ; Mon, 26 Oct 2026 13:46:44 +0100 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 6adf4bb4-f479-0a2a450c0019-d155802bbcc2-3 for ; Mon, 26 Oct 2026 13:46:44 +0100 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a5087a5348so11073585e9.0 for ; Mon, 26 Oct 2026 05:46: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-4a35a574088sm179134745e9.9.2026.10.26.05.46.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05:46: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=1793018804; x=1793623604; 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=4DqwgDtm0VrpC9d2Gf/RO9010Vq2WzDmFecRqT+51tE=; b=A7J41baKyqrlgWQxbbVluDVZvYrUTpIpe/PfuOCnHnaf2xuRoVAn24FcC6jsb1ZWOR tnSHUKgfygEehZNIFKEAlZPRWqwECG1vbJ4iLB9ps3takb9y4xgF14ZaOat7nKDh21TE 6tnb7XMi6T/bj2XWmYcnEFBFOjL73+Az3Cs1mPj7UNAbMqwZVn8ssJCJjb/L7loHmvB3 1Uye8peUHZNEWcHhe/rtL2M40SnaZ8J7n8QzIOxWv8UKvolvRNh9OsDK9jtQbbL4QXMJ darFaPV2x19mAAyNBbF21ZsMbnEke6O6E1UHONGnkRWLEYgPFaIBS9BmxCrLzdLMpk8o N9Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793018804; x=1793623604; 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=4DqwgDtm0VrpC9d2Gf/RO9010Vq2WzDmFecRqT+51tE=; b=bj7KAMYYA57Muyimycix3UCJnw7IaDw7ie68JREEysqgTZnyQIv3ew8na+ipFwwdtg a8FCFRA6GGzLBoiDz9nyPCn8q54NmsmeiRMYxZtZHmJfoVSxa1yrCee6UTrIugxXz8Ky pX/RpxlrrR33H872YugnurzcKBnRytlMDDxiObCItegI0c07KCTxqBqRlbXeCRpTcdw5 xtF/nrlIQlrZ3g2gLJRf4xVTxKGKWDKILlknDIBhdBWmQPpb+O4jaeoZm0HjJRQnEQAA 5IPx/teJji0jiPGm1dKoMzQ9SrGsUBhQ4QLKcb+ZN+tW+pen99EhOSmPbtRR4iYbiDlV aIsQ== X-Forwarded-Encrypted: i=1; AKwUvByu8zKZmqe2X5asOuK+qB8N7UlrBLz4o9PBCTvNPpkuSIy9P3FTufFcMvpbgZSji6+vvLwnoJUjCBE=@lists.xenproject.org X-Gm-Message-State: AFq9FYIKPHTJoxMNx/H+sKpHMsxexDfmmLULZnKBGIJ3DnIFK1bO4Wlx b0X1XsGpTzllAHQLf5jWt4sOkdWFTh/wzIrYYa5qeoSPx5M8iNIJh2IGOtQu3ht9OQ== X-Gm-Gg: AYBFou0bJxuR3sn4cntIcHkj3iyF+9weWZ3tCf66hvHI1FIQXgaDppPSpkxs0qy4C5m RABhU6KSASAjdFc3akQs5jIGdo+filBTqP/AvuZSscP6HZXf94ewuDkf1x7QcrGVuLq7g1F3azi cI7GDCFPABYOykU+3MU5eh3X3KSBO0RJmrW52dJyhuqi/z8nvTmDQPDnlQhq5b7IQn6CObWshks gmC9eNccAy32Y2dZzJxPCivOI2sBX0Yr0t1bpyIq0k7lH6688aFcxcFXl+3Rywo+T5xkCc+Hw16 0fEMhZvNZ6LMoMhGU/2OO0NZ/BUE6ujBZDMc/5IgXp97bU8iakmmu5+GIO6XkgAVMo9MOXTec85 naBw+CXl/bVh9bC/Bx+rybBpNlwRpAgmT5Ixe2dQ8osAIlqtKArszmQs16DlTOHVn1wLYFOFO+c xLOAObAVSj/EZhr76K+6CBmC6wOIom3ZJVA4R3LD0stQ8RDOQUO4eoroO7Ti80GwkgOIuZD9fWZ nlPGgrLPseRIi2DP1zd5e8pSVIpgUxOz98Xal0NdHAOpzY6MsfMb7pHIVI0+3CY/H3kolIVqF98 21axbJBjTNN4fTZohusH1jJBGGeM1QATvaxDjlveNb8= X-Received: by 2002:a05:600c:c173:b0:4a2:883:4adb with SMTP id 5b1f17b1804b1-4a35ac9ea4amr114004315e9.22.1793018804087; Mon, 26 Oct 2026 05:46:44 -0700 (PDT) Message-ID: <23ca037f-d7cd-4140-a991-ef51bc095d60@suse.com> Date: Mon, 26 Oct 2026 13:46:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/sched: Fix the sorted insertion in sched_domain_insert_unit() To: Stefano Stabellini Cc: dfaggioli@suse.com, jgross@suse.com, gwd@xenproject.org, xen-devel@lists.xenproject.org References: <20261020223534.3703199-1-stefano.stabellini@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: <20261020223534.3703199-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1793018804-76CDBA5B-E8D32FCB/10/78276251493 X-purgate-type: spam X-purgate-size: 1329 On 21.10.2026 00:35, Stefano Stabellini wrote: > The loop links the new unit in front of the unit whose successor has a > higher unit_id, rather than after it: inserting 1 into {0, 2} gives > {1, 0, 2}. Stop at the first unit with a higher unit_id instead. > > I think it usually works because guest vCPUs are typically inserted in > order. Plus I can't seem to be able to spot anything which depends on any particular ordering (except for sched_domain_insert_unit() itself). > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -489,8 +489,7 @@ static void sched_domain_insert_unit(struct sched_unit *unit, struct domain *d) > > for ( prev_unit = &d->sched_unit_list; *prev_unit; > prev_unit = &(*prev_unit)->next_in_list ) > - if ( (*prev_unit)->next_in_list && > - (*prev_unit)->next_in_list->unit_id > unit->unit_id ) > + if ( (*prev_unit)->unit_id > unit->unit_id ) > break; > > unit->next_in_list = *prev_unit; Part of the problem may also be that "prev_unit" doesn't look to properly describe the purpose of the variable: We insert before prev_unit, when the name (to me at least) suggests we mean to insert after it. IOW I think a rename (together with the correction of the condition) may help here. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:48:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:48:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461277.1672266 (Exim 4.92) (envelope-from ) id 1xLK8C-0001Pl-EB; Mon, 26 Oct 2026 12:48:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461277.1672266; Mon, 26 Oct 2026 12:48: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 1xLK8C-0001Pd-AJ; Mon, 26 Oct 2026 12:48:52 +0000 Received: by outflank-mailman (input) for mailman id 1461277; Mon, 26 Oct 2026 12:48:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLK8B-0001PW-6z for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:48:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLK8A-004TSc-Cc for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:48:50 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4c2c-bab6-0a2a0a5309dd-0a2a4507a068-24 for ; Mon, 26 Oct 2026 13:48:50 +0100 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4c31-b4ea-0a2a45070019-d155dd31e0d4-3 for ; Mon, 26 Oct 2026 13:48:49 +0100 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48b001cd92bso1666298f8f.2 for ; Mon, 26 Oct 2026 05:48:49 -0700 (PDT) Received: from [192.168.1.109] ([85.107.102.204]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ecdd5b3sm16198035f8f.53.2026.10.26.05.48.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05:48: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=1793018929; x=1793623729; 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=VhOZNQNujrPuv3qbMef5fbbVAHZBux3NnjGIV32TQHQ=; b=IO0o7xfoE1++JICzsD16v6GzdBIfUgfHrKqrbo5ndOgdxaC9itwOvyybNnweyya+XV YXAQnw24BTPQxF58rfDoxPXGxth8OGjV0Lzup2rkqZaF+Heb/Zcb9gQ8E0Nb0vvnDnSE cPk2coJLgY7rFeLru6JTEIkAx+W+xOHd0jOo0k2TYsUBLufGUZPnS78QADwhsy3fFnWb cxiMwQvYuUIep03UYK3QM+dc+4p2bD9FxdhG4P5nSb9xBoeJXWAf2SBNHRHkf/1n3uXb w4uTJ3XNJzmZv6g94AtF8kgDnPZdjfWfjeOxOO00poj1cRAGYxjWBEKaTn9nccCOEWxk j5Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793018929; x=1793623729; 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=VhOZNQNujrPuv3qbMef5fbbVAHZBux3NnjGIV32TQHQ=; b=n7O0uzEgTvz5e8I3XpkfrTFkpnH+n3uOtZ84pzlItuTRSr5JRr+YQNxhm+IFTghYwY mxkU3GIx8/5l03SCIouk6O9dDZhWrk2qrc1Tlmi6mTR4HJUL5oKeQ8JFzn9B4JnxPYk6 uSTBJJvHn57KZSlc/1Kml5BX2l+obVN3exQJXE6O3wqvWO8oxRyyUyds4o1SV1+0Us01 2ooJ0cPg8z0bbJ7mN/L5lkxk8hguIz8Yt8gcY8xcIC7GVKbOUw4SCxKZZwfi1i9G9+/7 N/SquhK+2CnSOpr7Q5hWjjDS1yFtDiVPrAhFxqTj2SUrPywoCmkVO4OYWCSRvzcgQObd 1nsw== X-Forwarded-Encrypted: i=1; AKwUvBzu52TjZpUasBZlAH53OktDR7/ElgilvQllmDIcsmSwG2jn6q/7dqCCNi3UitkPThUUw0kBDacyIrw=@lists.xenproject.org X-Gm-Message-State: AFq9FYLHzCCLMrqKZibVNFVGvrvJBryyz3bc0uAtqzMDwH4Dc74SFzuW S74ldSVLv4co2Cb6IRY9WsY6mApoXyYNS3Ew1khGSHJm24HJ05IdVa8E X-Gm-Gg: AYBFou3G1oxES/r0FXghZIGH1BYrsDtx7WplHlt3fR51W4KV5v9iv0c49/oKRTIQ8mZ /6GZzr0xyqW1jdQv5jlgtSuSgr2vh0dHVViU5a7xDsry04bORrpN0BdTQGw1KQu4lL/Ml0SwYBf CnnI9t6Zp1Pz1+9GUlRW7/YsmzKJr9n2M5/eXWaPqHhcxmLAy149Zh4+vhR/E/GgxI56imX/liZ SZp/odneLvU8pVj7Pj7+7jDzrBKFtgPvCDE9ZHFyMxcFjmBSNZcNvIAr5FDUYaatopDBc6nmHbL Sq4MDHc2h/0soyGWAZ2RbQF53qnIgSQdvA5TPrpngaOW24kIMBl9Xl2JbbWtVUb3F/eoXS9jojG mnsZU5o/KOhb2UMkbDMl2+St/DaCannP/nFwrixhqUfWaeJ0Y1HRmfGkJ4qFNXsrFIQTOu1zSus M+uTOCUZrmVTTLc7uNxjExbBRhn1CNQWzB+RE4pqfNFxyYZLNURpEEHJYHasyb2Y8NrisHLlshI b8c7ZBfrgTAJqJ2nug7vOfStb4QBdOBAkxd35U+j1DRu7Mi5i+JyN7euqpSbFE= X-Received: by 2002:a05:6000:29d6:b0:48d:f14a:9182 with SMTP id ffacd0b85a97d-48e3eb75c4cmr7596099f8f.20.1793018929268; Mon, 26 Oct 2026 05:48:49 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 15:48:45 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/desc: build boot GDT descriptors with a macro To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, roger@xenproject.org, teddy.astie@vates.tech References: <20261020135722.45714-1-frn1furkan10@gmail.com> <0ee66940-5e5b-407e-81fe-de0e47842bbf@citrix.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <0ee66940-5e5b-407e-81fe-de0e47842bbf@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793018929-35EC6AE4-1B55349B/0/0 X-purgate-type: clean X-purgate-size: 6284 On 10/26/26 15:27, Andrew Cooper wrote: > On 20/10/2026 2:57 pm, Furkan Caliskan wrote: >> The raw 64-bit constants in boot_gdt[] and boot_compat_gdt[] hide what >> each descriptor actually is. Replace them with a GDTE() macro, modelled >> on Linux's GDT_ENTRY_INIT(), plus named GDTE_FLAGS_* constants and a >> GDTE_FLAT() helper for flat segments. >> >> No functional change. >> >> Signed-off-by: Furkan Caliskan >> --- >> xen/arch/x86/desc.c | 61 +++++++++++++++++++++++++++++++++++---------- >> 1 file changed, 48 insertions(+), 13 deletions(-) >> >> diff --git a/xen/arch/x86/desc.c b/xen/arch/x86/desc.c >> index 9f63928154..647affb6a3 100644 >> --- a/xen/arch/x86/desc.c >> +++ b/xen/arch/x86/desc.c >> @@ -27,32 +27,67 @@ >> >> #define SEL2GDT(sel) (((sel) >> 3) - FIRST_RESERVED_GDT_ENTRY) >> >> +/* >> + * Expands to a brace-enclosed initializer for seg_desc_t; only use it >> + * inside an initializer list. >> + * >> + * flags: bit layout matches its position in the descriptor's high dword >> + * bits 0-3 : type >> + * bit 4 : s (0 = system, 1 = code/data) >> + * bits 5-6 : dpl >> + * bit 7 : p (present) >> + * bit 12 : avl >> + * bit 13 : l (64-bit code segment) >> + * bit 14 : d/b >> + * bit 15 : g (granularity: 0 = byte, 1 = 4KiB) >> + */ >> +#define GDTE(flags, base, limit) \ >> + { (((uint64_t)(limit) & 0x0ffffULL) | \ >> + (((uint64_t)(base) & 0x0ffffffULL) << 16) | \ >> + (((uint64_t)(flags) & 0x0ffULL) << 40) | \ >> + (((uint64_t)(limit) & 0xf0000ULL) << 32) | \ >> + (((uint64_t)(flags) & 0xf000ULL) << 40) | \ >> + (((uint64_t)(base) & 0xff000000ULL) << 32)) } >> + >> +/* Common flag combinations (same values Linux uses for equivalent segments) */ >> +#define GDTE_FLAGS_RING0_CS64 0xa09b /* P DPL0 S code RX A, L, G */ >> +#define GDTE_FLAGS_RING0_DS32 0xc093 /* P DPL0 S data RW A, G */ >> +#define GDTE_FLAGS_RING1_CS32 0xc0bb /* P DPL1 S code RX A, G */ >> +#define GDTE_FLAGS_RING1_DS32 0xc0b3 /* P DPL1 S data RW A, G */ >> +#define GDTE_FLAGS_RING3_CS32 0xc0fb /* P DPL3 S code RX A, G */ >> +#define GDTE_FLAGS_RING3_DS32 0xc0f3 /* P DPL3 S data RW A, G */ >> +#define GDTE_FLAGS_RING3_CS64 0xa0fb /* P DPL3 S code RX A, L, G */ >> +#define GDTE_FLAGS_PERCPU 0x0091 /* P DPL0 S data RO A */ >> + >> +/* Xen maps every flat segment across all of memory. */ >> +#define GDTE_FLAT(flags) GDTE(flags, 0, 0xfffff) >> + >> __section(".data.page_aligned") __aligned(PAGE_SIZE) >> seg_desc_t boot_gdt[PAGE_SIZE / sizeof(seg_desc_t)] = >> { >> /* 0xe008 - Ring 0 code, 64bit mode */ >> - [SEL2GDT(__HYPERVISOR_CS)] = { 0x00af9b000000ffff }, >> + [SEL2GDT(__HYPERVISOR_CS)] = GDTE_FLAT(GDTE_FLAGS_RING0_CS64), >> >> /* 0xe010 - Ring 0 data */ >> - [SEL2GDT(__HYPERVISOR_DS32)] = { 0x00cf93000000ffff }, >> + [SEL2GDT(__HYPERVISOR_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING0_DS32), >> >> /* 0xe018 - reserved */ >> >> /* 0xe023 - Ring 3 code, compatibility */ >> - [SEL2GDT(FLAT_RING3_CS32)] = { 0x00cffb000000ffff }, >> + [SEL2GDT(FLAT_RING3_CS32)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS32), >> >> /* 0xe02b - Ring 3 data */ >> - [SEL2GDT(FLAT_RING3_DS32)] = { 0x00cff3000000ffff }, >> + [SEL2GDT(FLAT_RING3_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING3_DS32), >> >> /* 0xe033 - Ring 3 code, 64-bit mode */ >> - [SEL2GDT(FLAT_RING3_CS64)] = { 0x00affb000000ffff }, >> + [SEL2GDT(FLAT_RING3_CS64)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS64), >> >> /* 0xe038 - reserved */ >> /* 0xe040 - TSS */ >> /* 0xe050 - LDT */ >> >> /* 0xe060 - per-CPU entry (limit == cpu) */ >> - [SEL2GDT(PER_CPU_SELECTOR)] = { 0x0000910000000000 }, >> + [SEL2GDT(PER_CPU_SELECTOR)] = GDTE(GDTE_FLAGS_PERCPU, 0, 0), >> }; >> >> #ifdef CONFIG_PV32 >> @@ -60,29 +95,29 @@ __section(".data.page_aligned") __aligned(PAGE_SIZE) >> seg_desc_t boot_compat_gdt[PAGE_SIZE / sizeof(seg_desc_t)] = >> { >> /* 0xe008 - Ring 0 code, 64bit mode */ >> - [SEL2GDT(__HYPERVISOR_CS)] = { 0x00af9b000000ffff }, >> + [SEL2GDT(__HYPERVISOR_CS)] = GDTE_FLAT(GDTE_FLAGS_RING0_CS64), >> >> /* 0xe010 - Ring 0 data */ >> - [SEL2GDT(__HYPERVISOR_DS32)] = { 0x00cf93000000ffff }, >> + [SEL2GDT(__HYPERVISOR_DS32)] = GDTE_FLAT(GDTE_FLAGS_RING0_DS32), >> >> /* 0xe019 - Ring 1 code, compatibility */ >> - [SEL2GDT(FLAT_COMPAT_RING1_CS)] = { 0x00cfbb000000ffff }, >> + [SEL2GDT(FLAT_COMPAT_RING1_CS)] = GDTE_FLAT(GDTE_FLAGS_RING1_CS32), >> >> /* 0xe021 - Ring 1 data */ >> - [SEL2GDT(FLAT_COMPAT_RING1_DS)] = { 0x00cfb3000000ffff }, >> + [SEL2GDT(FLAT_COMPAT_RING1_DS)] = GDTE_FLAT(GDTE_FLAGS_RING1_DS32), >> >> /* 0xe02b - Ring 3 code, compatibility */ >> - [SEL2GDT(FLAT_COMPAT_RING3_CS)] = { 0x00cffb000000ffff }, >> + [SEL2GDT(FLAT_COMPAT_RING3_CS)] = GDTE_FLAT(GDTE_FLAGS_RING3_CS32), >> >> /* 0xe033 - Ring 3 data */ >> - [SEL2GDT(FLAT_COMPAT_RING3_DS)] = { 0x00cff3000000ffff }, >> + [SEL2GDT(FLAT_COMPAT_RING3_DS)] = GDTE_FLAT(GDTE_FLAGS_RING3_DS32), >> >> /* 0xe038 - reserved */ >> /* 0xe040 - TSS */ >> /* 0xe050 - LDT */ >> >> /* 0xe060 - per-CPU entry (limit == cpu) */ >> - [SEL2GDT(PER_CPU_SELECTOR)] = { 0x0000910000000000 }, >> + [SEL2GDT(PER_CPU_SELECTOR)] = GDTE(GDTE_FLAGS_PERCPU, 0, 0), >> }; >> #endif >> > > I don't see this as an improvement.  All you're doing is putting a layer > of indirection, and moving the attributes away the comment explaining > what they are, and the attributes are still raw. > > If you really want to macro this up, then at least use INIT_GDTE_SYM() > from XTF or MiniOS.  That way you get things in a legible form at the end. > > ~Andrew Fair point. I'll fix it in v2. Thanks, Furkan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:50:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:50:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461286.1672275 (Exim 4.92) (envelope-from ) id 1xLK9K-0002Ea-Ok; Mon, 26 Oct 2026 12:50:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461286.1672275; Mon, 26 Oct 2026 12: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 1xLK9K-0002EA-J8; Mon, 26 Oct 2026 12:50:02 +0000 Received: by outflank-mailman (input) for mailman id 1461286; Mon, 26 Oct 2026 12:50:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLK9J-0001yv-3r for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:50:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLK9I-00DErJ-GU for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:50:00 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4c51-e002-0a2a0a5209dd-0a2a4501ae8a-48 for ; Mon, 26 Oct 2026 13:49:59 +0100 Received: from [52.101.62.70] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4c76-5984-0a2a45010019-34653e468f5b-3 for ; Mon, 26 Oct 2026 13:49:59 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA0PR03MB5612.namprd03.prod.outlook.com (2603:10b6:806:b8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 12:49: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%4]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 12:49: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=XqYc4okohwNu94nmeYJXFizX5K+kFcW0thZEipVm8K4ovOhZJbk8l2LoC7uiPVXGN5WS4FJPR59Li/YnOsj7smDv/3n+6zIwh5bgXS+iPMRDCTq5L2qWiHLG049RDz8610iYqJhaZ35YlyUknYqXyd/iM30Kor8Ga717CCPU/5jGBJ/Pi0kvXJm4Xk0LJycUInrRT+qJRfsMAnEZhMUQKODwf+VWK9r+InFoPtfZJKVyepYmwMpZTLr1eML68JCoicmX7yzsRmtqEdiQxglD1J0VWZW/2V5YBgSn3aYmyCjGLayQqf7qIYtrpNC0KC2M7LISJP98p6p2C/1OjQNBzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Kw+oGxNrfMzqMMVBbkT4NqPGIvzCMbdGvACS0aRtnQY=; b=FIDtScy7gpwGmIFP+6E4ZCMHqnHBvftTTS2ss4d9WRO/Pu+psWzAD2fBf9xuzc2PRFXojSzuhTu1im3ycCo7MBrxKF7drbyAXiYcS4Y+kTRyzGsp5zmaU2NfpJLVaWtllQaPXS2zXkb8hXaQKhTuO3n71ax+nBZWIXxn+mOEb4YMs3Ni061EK7+17YRw4vKlWEirNuxTHkQGN3O9SgPrKi5l5A+2k9NA7QwsTbaY1WMHgpFrBNfvmtpdBLaJ7xjpEirhKK6Cz0LO0KLNaDESL3j68aSCkoEp/0Z1AyAFUvWW9uYmxFkuCluvN3ASCwZ5tG5nE1Jl9Grz21V4L7oFfw== 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=Kw+oGxNrfMzqMMVBbkT4NqPGIvzCMbdGvACS0aRtnQY=; b=RUOzG8BrWD76Bu2ix/bUGEOMfKEvcgJ9lc+K999o4KARXl5B1FzSYJvh0Q37PKdRx+WTZWHBGD8grumrDaK3Z4PRTArQJNtaW8axdgXCR240Ec0A3kvYyJDBdV+hWueaC7JwunziRkicyXGAD+HbIJZOTV1T9RMyXs421HaJkXI= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <25716378-3592-471f-a972-8446c32e29bd@citrix.com> Date: Mon, 26 Oct 2026 12:49:35 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stewart Hildebrand , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v1 3/3] vpci/msix: move common msix code to common file To: Mykyta Poturai , "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: LO4P265CA0084.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bd::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_|SA0PR03MB5612:EE_ X-MS-Office365-Filtering-Correlation-Id: 6827bc3f-5f50-475e-ff52-08df335f98bf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|18002099003|22082099003|56012099006|11063799006|4143699003|261021121427099003|10067099003|261009223027099003|261022105027099003|261021123027099003; X-Microsoft-Antispam-Message-Info: gyCzm74RtW1sAwE479p8GEsYV7WEatZCDbOUvSADeCuGKMafsdjeQ9mU3iip/lfdDRXC3HosBums+IR679EoUsDgYzfVf/SOCe5CsoWHI1WaLX++kAzm53cgG3Wpx9S7BJcNmn9oqneCx6jufl8foEjKWXYz11tqCVQ0CxuFhEUYggvhIdX+jdXzHAoqGfgZvJVz5/dxbrIRcjJBd5y1zTr6tFD3/vFMudSU3y+hAS6qMexS/ncal+f8Vid2JlOp+IHN2K3YjY2wbN5D1uGUVbdKw2rcRN/Dop2xlNL1dr0TILmbBHoEUfvNycrDZFG4aISbE+yDF/OTSXFynqiRd6+FxaU3kkoxpMjUj8pCJ66w5dZKj6YxN0rnZbZafp2QIeAZM37oG9PY+Iy8sQfD/YtF5gENStMo2GpPvqRwdmjx1OXybrN1Ca7RzQPlGkW8T1l95GF/WG4LQ+vHnr9C4q5WPZwIrNbHSGnXhU3WChTp4eOuSIZ66xu5WnQIpGVbB4mXRbIfymbzCpTwItkOmz5+lrPnDpKWLmcb9ITycOL6XPxGOoinaKLWI2R2+YHYhFkiicSfkOCM6XT0AjU6tbcnW1y4finO90zuryHTQnxQhCg/q1liMAEnOC3oCp3X/gX4r74kcs/1fWMbifnf2bFCRALBfbOo6nl6FrhrZE0= 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)(18002099003)(22082099003)(56012099006)(11063799006)(4143699003)(261021121427099003)(10067099003)(261009223027099003)(261022105027099003)(261021123027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MTZNNUxUOXM4T3MrTjVZaCt3a2NRbEx5b1ZKL1gzSmszL0RyK2dVNEtFZ1Fa?= =?utf-8?B?cCs2MEE1cVNaM3cwbCtKSjNPWFV4ZlVwd1BHZExxRGVIWXc4a0ZnTE44dnAv?= =?utf-8?B?enVxLzlObFBEZzRoWTRvZk52eUpQWkZweEljd1ovcW9XV0c1RmNPcmZObmc0?= =?utf-8?B?Q1BRaHlvNTlveTdmLzZmQXQ4MmNaNWFyNzlOQUdrWlh4NFlITm9nSjQ1Sndh?= =?utf-8?B?VzR6SUxjMmQ5a3grOHZjVkNKSkg4VHZYeHZHOFpaUUtyNU11Si9JVndkbmxS?= =?utf-8?B?SnZaMEp0eWZ2VDRYaitBTnVwdXkxSHduMzVBV01WYUFsMk9JUzA4eHJVdFFF?= =?utf-8?B?TEErV0xnRmtFQVN2ZnJZNnUwTDRFN0VNbVc3UUhlWXBxVHhhSEk4SFd2eEpn?= =?utf-8?B?eDR6L0FyOGd0eFE1YUFUS3FTUmlNSytyR2tiK3I2bHpubjVGbTBtczFHdmU0?= =?utf-8?B?MmdGM09ub1Q3eVJTU3h4THdUNTc5OGh0YlJaSCtURnhpTUtQY2UzdG5qUDZj?= =?utf-8?B?WGJJNy9BOWtKUnRrQ3JkN0NkWk5lZU1ackRrcXhMSUNrTG9mdnhDMDE1OGt2?= =?utf-8?B?bjRFeVV5YVI0WmtOMk9nVHFKNDZtOVY5SGVjZzkwNGUvcjRIeDNMOWlCaEdV?= =?utf-8?B?V3VBdnBGcWp1YVNCMkZ3VXZkZ2RJRk51dC9BRDlkVE05QzVOMS9ncmc5bDZL?= =?utf-8?B?ZVZGVHlabkJjem4wOHE3VzVYc1o2SFdkVTRpbCtSalBVTGlUblFUU0swMTVz?= =?utf-8?B?eW13cnNUTzhXUjU2QTdxQm5tZzRpSFRyVHhiY2lwRC9EcDFjTjN0c3FBWDF1?= =?utf-8?B?bitUVkc0aGNrMFByc0tEZlQ4TGpjMDFhdWJVRlN5eUtyRE9kakd0elBHSDhV?= =?utf-8?B?VlRtUjljY0psOEhFWjFYYUtiU1dBRVhiZ1VUSlhFWHZEYzRzNWxlMWgxTC9F?= =?utf-8?B?NW9nQTRMcW1HZnBQZWtONE5Va1JVcGVmdE44c3NGcGpYYjZsWkUxNm56bFFZ?= =?utf-8?B?SWFVVjdyS1dBUVFmN2MybmJPcXNreDJDK09hcmtOTmJHeUw5dW9sdUt6bVJO?= =?utf-8?B?RFRodTN4bHU3a1ZDbEd1UDFxaWNxVlNQOVhJcEMxZC9ydWVnUWgvSUVSc3Rh?= =?utf-8?B?S1hibWl6N1BWYUhMNkRyV3kxWVZqVmllZmsyRWdncm1KZkMyNVZQWGR5TURW?= =?utf-8?B?Y2JPRUhxT3RITnUzT2dUWnZwNkVpS0RjYzBLUFo0UHZrRGxXUE45ckZYd01Y?= =?utf-8?B?dEVOVloyU00razVub25NaDh5RFJrcFA3c0RVc0FrL0I0akU5cGJsRmRyQU5z?= =?utf-8?B?a05jQitOVkg1dWduRWtYWUtLT2k3SjRYY3RBa253d2NsdERqZ2J6bnQxNjM0?= =?utf-8?B?TmNKUDJicmp0dDVFYllGL0hTblByQXoySmxtV21FQlJvTGNFd1hneEdoK3Mw?= =?utf-8?B?WlVJUWwwZ29UTDIvRE9kUTV0Um9DcjVXdWNlRzBWMlM2YmV3dFk3cG45NVZm?= =?utf-8?B?aTlEWTZ4VmpWRUx2SGpEaytuYTJPN1VaY3NUOFZuRW55d2xaOElMeW5aU0pN?= =?utf-8?B?QlFVQmZPaE1iemszK2twTENJSGFCMXRjeUJmZnBaeU96VGdYc29kd0Z2QlF4?= =?utf-8?B?UjA3d0R6SWI5MTN4RCs5bUtTUW5SdFN6bHo0TnBSOHNLdmF6SStWMFR0N3p2?= =?utf-8?B?d0M0S0w0dFdNSTlXOXJxZk1NSHlzVDA2SFBZUUJESXdUM1h6YXBzckpMQWJa?= =?utf-8?B?c1JZU2E1ajNZbEt6VmRSMGs4R0FuS25oV0FzYUR0WWxGS0YwNWxxcXdHeXhO?= =?utf-8?B?V0xVU1loc3J4aVlIaDRRYWVlM2RHTjI3VUpaZk93K0JMTlNQVTZaZGh0SVhB?= =?utf-8?B?YnVSK2o3dENOdkwwbjB6MVJXN21mMVE2ZXp3RDlHQjJ1SHAzMVBPLzlxWlVy?= =?utf-8?B?QW9CaUFDNG0vbG81RExsdGVpN0VBRTJsdHZjd3VTQmxKZEt5MHUwSllVUjgr?= =?utf-8?B?S203V29qYTZobVpnWmc4QU5MU08vdndTbWc1Z0VGOG81T0VQQjJRZFYvNUlM?= =?utf-8?B?Q0dBSGRuNG9LRStoc0xkb3k2WkV0T1MwQisxMzZPMFhOZkI1R3VRZzArV1p1?= =?utf-8?B?MjJQbUF6eFZuN3hMenUyM3BScnIwODZRQTJVbVpLTHhQMFNuVnRYYXFBdTdO?= =?utf-8?B?ZDhzWXVrNVBFRUZqb21vbzQ0bDZyeE9DWWhXRGdybjNtMWkrZEtydnFSVlEx?= =?utf-8?B?YldwVFVyU0F2V0xEY3htZDd1YnYwOVlOZlpXTys3NUgrNG1tSGJvd0NMK2RY?= =?utf-8?B?Wis4ZzFETWNpSE5PSk1zcVMzOEFYT2lmeTVrVURTcCtlT3c0ZUtmZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6827bc3f-5f50-475e-ff52-08df335f98bf X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 12:49:38.9093 (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: glG0C20Zg5c0VmKO0J4bB+pLcAUADks4gdwH+T7pYenq4ZAw34PQzi6x/PkvIrYR71oFegenY3/8qu+L/PimF1XCOg+/nMZveMc+8/QOxfc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5612 X-purgate-ID: tlsNG-d62444/1793018999-BE27A757-46A22C8A/0/0 X-purgate-type: clean X-purgate-size: 1053 On 26/10/2026 12:28 pm, Mykyta Poturai wrote: > From: Stewart Hildebrand > > vPCI MSI-X code dealing with intercepting the MSI-X tables and PBA won't > be used on Arm. Moving this code would result in a large diffstat, so > instead we move the common code to a common msix file to achieve a > smaller diffstat. > > Signed-off-by: Stewart Hildebrand > Signed-off-by: Mykyta Poturai > --- > xen/drivers/vpci/Makefile | 6 +- > xen/drivers/vpci/msix.c | 160 +------------------------- > xen/drivers/vpci/msix_common.c | 202 +++++++++++++++++++++++++++++++++ > xen/include/xen/vpci.h | 5 + > 4 files changed, 215 insertions(+), 158 deletions(-) > create mode 100644 xen/drivers/vpci/msix_common.c Please arrange things to make the best structural sense after the change, not to optimise for minimised diffstat. The diffstat is an instantaneous review burden.  Good longterm structure is far more important. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 26 12:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 12:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461295.1672283 (Exim 4.92) (envelope-from ) id 1xLKDl-0003in-B5; Mon, 26 Oct 2026 12:54:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461295.1672283; Mon, 26 Oct 2026 12: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 1xLKDl-0003ig-7y; Mon, 26 Oct 2026 12:54:37 +0000 Received: by outflank-mailman (input) for mailman id 1461295; Mon, 26 Oct 2026 12:54:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLKDk-0003ia-Kz for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 12:54:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKDk-00DGVw-1U for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:54:36 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4d8b-bab6-0a2a0a5309dd-0a2a450781a8-0 for ; Mon, 26 Oct 2026 13:54:35 +0100 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 6adf4d8b-b4ea-0a2a45070019-d155dd32a4eb-3 for ; Mon, 26 Oct 2026 13:54:35 +0100 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48df0fa43c5so1883681f8f.0 for ; Mon, 26 Oct 2026 05:54: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-48e542ed998sm1467706f8f.13.2026.10.26.05.54.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 05: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=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=1793019275; x=1793624075; 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=LBiyLP//XSZ4+Wyu2aKcsffqK+m6lmydk2jU1KnCmPE=; b=Af1i9WZHM9laXYnGqpqbb6FWY0M1RQ+Jpb0Ooh8+E4jX5AF27NheeC1A42aR/diAcp DcoGIAW7DKdkmF8H+zO0gnqzajsuyT0we3QXQGguo/eApwFKrXi4uDyXo97ayCxyEduG Ml3jBm2TMyfhKTnc62bUtbySf/OvmKsrIHXC4Wpw7uPaL+1oryvh0AQsYkHzIfxBvmKw Exa0n8KrPnp/7JdzycE/Vj84aqaFrph8cfeb1fo57RZ5QknbLHMaPFXuycug2SJLhtAF Mf8dwYoryv5qfZ7j0XUySIPgpME1DdyjVLebp/wzhN8D1KDOaxesHKqRGgWQg2q2RW+i W0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793019275; x=1793624075; 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=LBiyLP//XSZ4+Wyu2aKcsffqK+m6lmydk2jU1KnCmPE=; b=Ya0ZPbEv+qbwWzPAjPkdUuiruCSeKgssu3uALqOERwef+Q8PuHfn7YP1y/gVdWhvx9 QybLLaTiOQ9LTUFjrg3XrJsdYiRDKg48LUkqHpFVneNouJBEfR5F9ktc2OaDyEpBK/6j /3LTNfwuha3DPaMdKLWyZDmI1PZrJbZAejLCn78sIxVMqoqKb2BWD33qv4h12MAUhQGf MFuAYdJKN3CgTytMeB2jQHSbxDda2Cc38dVpU/KLDSvg727x0rsbodtpGyGr8sCSo8Ax yWv2yC5lumFHGo419v39TRZ22z/0heGQwz/u9uf8jdjb9XpC3OM0nvXRat4kNHvB+4xK Wb7A== X-Forwarded-Encrypted: i=1; AKwUvBxB9UzlvMh9UIZiwzm9XKXjh2cFTe3QtbhxM/EdGHYbrlJ9ye8a1oqpGSiPXW8q+Ld/ZumNUMwcjAc=@lists.xenproject.org X-Gm-Message-State: AFq9FYKXVviEPKN6NDZTrhttSDbfeGPr64ym/CWPRC0+srz42KgUJiB4 wxV9BC+W5eG0Gik6kp4H4x9bdqRxBihpnZvZ5k0O/gK720l94ykxP8CfQgOqX9/21A== X-Gm-Gg: AYBFou234PbxvUvRStGA9HdnGhsgh1+w6AJBC1CWj138JONGezr1KfrwP7CjatilQXe lV2RjUhLVLnCYtPY4irdCaoyXECpAKHdUA4V64vtwwBoCHbXant7Gap8LNg4qhP0t46foMmtDLd lnQQHITbpFDQDCVSxzxNrJvJurj4Bopz15wOWZ99kVEsd4qeW4li4RYS5MgKLjvbfWhDdAMrj2B gFCKR6c6Eq71ihshlwKQ29muCv+SMAdUkqBa9Z6SNZkMpOLI2+HaLqsEorlA+SOqOKsSyujMk9h uQujuErb3ssoKU5ci+bVUA6uOM99v3GAnSq0qH5vaFNSxT4ue91gNxO+1ETxJA7YIV1N4UloF0z yGVjWzOaY8vNj6w8BJeINdDOyM4qhZjhMkJvg0itOMt+weRPTc1EKVAd1dMhKP70moJk2XlnRLT NlsQTtJh9tZ3HWyd6wXkcYATV1RGTHQY0tma/d71WX8gpw0nPDsTcqV7+aaOsjeUxUUttazcA7P fOD7pLTF+WQSZMReDof118wC6hSog8PLtCiSwz3f2CQP1veXMjlPYXHPicJaCWSpsdMfBwgFgHC FKC6VWIAPAAadyz4xnp6u0ivn+kDgL+O7qfjEoi9B+hkRikE43TXBRtNcfxeum7e X-Received: by 2002:a05:6000:240e:b0:48d:f4ef:62e7 with SMTP id ffacd0b85a97d-48e3eab73b1mr14981130f8f.0.1793019275267; Mon, 26 Oct 2026 05:54:35 -0700 (PDT) Message-ID: <4fcb71df-a0ec-48bb-90e7-a073c06b05f3@suse.com> Date: Mon, 26 Oct 2026 13:54:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86/svm: Apply the virtual-8086 IOPL check to INT n only To: Stefano Stabellini , Andrew Cooper Cc: Ross Lagerwall , Stefano Stabellini , xen-devel@lists.xenproject.org, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech References: <20261020224123.3710391-1-stefano.stabellini@amd.com> <86d6b7b5-41f2-41b4-8710-7356c78fd15e@citrix.com> <192c430b-565b-4b89-957b-01b80ede9049@citrix.com> <2f51c577-86b9-2d20-2032-f9d56b344f47@kernel.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: <2f51c577-86b9-2d20-2032-f9d56b344f47@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793019275-A4CCFAE4-576B6596/10/78276251493 X-purgate-type: spam X-purgate-size: 4338 On 22.10.2026 22:29, Stefano Stabellini wrote: > On Thu, 22 Oct 2026, Andrew Cooper wrote: >> On 22/10/2026 2:55 pm, Ross Lagerwall wrote: >>> On 10/20/26 11:41 PM, Stefano Stabellini wrote: >>>> In virtual-8086 mode with IOPL < 3, INT n raises #GP(0).  INT1, INT3 >>>> and INTO are not affected. They are delivered normally. >>>> >>>> svm_emul_swint_injection() applies the check to all of them, so an ICEBP >>>> raises #GP instead of #DB.  It also reports the IDT entry in the #GP >>>> error code instead of 0. >>>> >>>> Limit the check to INT n and use error code 0. >>>> >>>> Signed-off-by: Stefano Stabellini >>>> --- >>>>   xen/arch/x86/hvm/svm/svm.c | 5 ++++- >>>>   1 file changed, 4 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >>>> index 71e48351f2..df74531d1a 100644 >>>> --- a/xen/arch/x86/hvm/svm/svm.c >>>> +++ b/xen/arch/x86/hvm/svm/svm.c >>>> @@ -1153,9 +1153,12 @@ static void svm_emul_swint_injection(struct >>>> x86_event *event) >>>>        * 32bit OS.  Someone with many TUITs can see about reading the >>>> TSS >>>>        * Software Interrupt Redirection bitmap. >>>>        */ >>>> -    if ( (regs->eflags & X86_EFLAGS_VM) && >>>> +    if ( type == X86_ET_SW_INT && (regs->eflags & X86_EFLAGS_VM) && >>>>            MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) >>>> +    { >>>> +        ec = 0; >>>>           goto raise_exception; >>>> +    } >>>>         /* >>>>        * Read all 8/16 bytes so the idtr limit check is applied >>>> properly to >>> >>> I think this is correct. The check could perhaps move earlier to avoid >>> needing >>> to reset ec to 0. >>> >>> I do wonder though if there are other cases in the function where ec >>> needs to >>> be reset to 0? The pseudocode in the APM seems to have at least one >>> other case. >> >> I confirmed, and indeed it is #GP[0] not #GP[sel].  Also that >> ICEBP/INT3/INTO are not subject IOPL like this. >> >> I agree with Ross that this wants moving earlier; between the CR0.PE >> check and deciding idte_size.  The comment also wants adjusting, so I >> think it wants to look like this: >> >> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >> index 71e48351f22c..c83b28d29727 100644 >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -1140,6 +1140,17 @@ static void svm_emul_swint_injection(struct >> x86_event *event) >>      if ( !(vmcb_get_cr0(vmcb) & X86_CR0_PE) ) >>          goto raise_exception; /* TODO: support real-mode injection? */ >>   >> +    /* >> +     * In vm86 mode, INT $N is subject to IOPL. >> +     * >> +     * TODO: It is also subject to CR4.VME=1, which would require >> reading the >> +     * TSS Software Interrupt Redirection bitmap. >> +     */ >> +    if ( type == X86_ET_SW_INT && >> +         regs->eflags & X86_EFLAGS_VM && >> +         MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) >> +        goto raise_exception; >> + >>      idte_size   = lm ? 16 : 8; >>      idte_offset = trap * idte_size; >>   >> @@ -1147,16 +1158,6 @@ static void svm_emul_swint_injection(struct >> x86_event *event) >>      ec = (trap << 3) | X86_XEC_IDT | >>           (type == X86_ET_PRIV_SW_EXC ? X86_XEC_EXT : 0); >>   >> -    /* >> -     * TODO: This does not cover the v8086 mode with CR4.VME case >> -     * correctly, but falls on the safe side from the point of view of a >> -     * 32bit OS.  Someone with many TUITs can see about reading the TSS >> -     * Software Interrupt Redirection bitmap. >> -     */ >> -    if ( (regs->eflags & X86_EFLAGS_VM) && >> -         MASK_EXTR(regs->eflags, X86_EFLAGS_IOPL) != 3 ) >> -        goto raise_exception; >> - >>      /* >>       * Read all 8/16 bytes so the idtr limit check is applied properly to >>       * this entry, even though we don't look at all the words read. >> >> >> I'm happy to adjust this on commit if you're happy? > > Yes please, thank you! Can we also have Fixes: 897d59a426f1 ("x86/svm: Introduce svm_emul_swint_injection()") then, please? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:02:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:02:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461305.1672292 (Exim 4.92) (envelope-from ) id 1xLKLP-00062J-0T; Mon, 26 Oct 2026 13:02:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461305.1672292; Mon, 26 Oct 2026 13:02: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 1xLKLO-00062C-U0; Mon, 26 Oct 2026 13:02:30 +0000 Received: by outflank-mailman (input) for mailman id 1461305; Mon, 26 Oct 2026 13:02:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLKLO-000626-4O for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:02:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKLM-005kF3-UB for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:02:29 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4f5a-8faa-0a2a0a5109dd-0a2a4501ab8c-46 for ; Mon, 26 Oct 2026 14:02:28 +0100 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf4f64-5984-0a2a45010019-c387df83a13e-3 for ; Mon, 26 Oct 2026 14:02:28 +0100 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 491121F461; Mon, 26 Oct 2026 13:02: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 E928313408; Mon, 26 Oct 2026 13:02:25 +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 4jNRLWFP32puWgAAD6G6ig (envelope-from ); Mon, 26 Oct 2026 13:02: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=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type: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-Type:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1793019748; 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; bh=VgucDQGlpzyRpthc04g7/oRg6NX1oBAdxDc/UgjwdQw=; b=JJ17nvYMH3Y9kIckqy6Y5tJHT+fxv7TDUxcVfKccWHoD50mqQbH+hNM2c2hvMMjr/kBmMY oXpu9UOTuwrkToNMxTLQys1MhXYd4kAzwIqHxFz3hF3W+PS7xhIKY4h/VKbLYDyripnlMG GSL+hGu0ouKDyR1+nDCWhv1EumU3ogE= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1793019748; 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; bh=VgucDQGlpzyRpthc04g7/oRg6NX1oBAdxDc/UgjwdQw=; b=JJ17nvYMH3Y9kIckqy6Y5tJHT+fxv7TDUxcVfKccWHoD50mqQbH+hNM2c2hvMMjr/kBmMY oXpu9UOTuwrkToNMxTLQys1MhXYd4kAzwIqHxFz3hF3W+PS7xhIKY4h/VKbLYDyripnlMG GSL+hGu0ouKDyR1+nDCWhv1EumU3ogE= 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 , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Haiyang Zhang , Wei Liu , Dexuan Cui , 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 , 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 , xen-devel@lists.xenproject.org Subject: [PATCH v5 00/12] x86/msr: Drop 32-bit MSR interfaces Date: Mon, 26 Oct 2026 14:02:11 +0100 Message-ID: <20261026130223.773129-1-jgross@suse.com> X-Mailer: git-send-email 2.56.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Flag: NO X-Spam-Level: X-Spamd-Result: default: False [-10.80 / 50.00]; SUSE_INTERNAL_BYPASS(-9.00)[]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; 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,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,arndb.de,linuxfoundation.org,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)[93]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo] X-Spam-Score: -10.80 X-purgate-ID: tlsNG-d62444/1793019748-BE664757-1015C63E/35/110847 X-purgate-type: clean X-purgate-size: 10483 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.4 as of 2026-10-26. IMHO at least patches 2 and 3 should be applied rather sooner than later in order to avoid new instances of the 32-bit variants of the *_safe() functions creeping in again. Changes in V2: - dropped already applied patches - added patch 1 - rebased Changes in V3: - small fixes in patches 4 and 13 - rebased Changes in V4: - rebased Changes in V5: - patch 9 of V4 has been applied - rebased Juergen Gross (12): 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 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 | 6 +-- arch/x86/kvm/vmx/main.c | 2 +- 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 | 40 +++++++-------- 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 | 22 ++++---- 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/edac/intel-bff.c | 4 +- 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 | 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 | 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 ++-- 140 files changed, 567 insertions(+), 685 deletions(-) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:03:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:03:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461314.1672302 (Exim 4.92) (envelope-from ) id 1xLKMS-0006am-Dg; Mon, 26 Oct 2026 13:03:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461314.1672302; Mon, 26 Oct 2026 13:03: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 1xLKMS-0006af-9T; Mon, 26 Oct 2026 13:03:36 +0000 Received: by outflank-mailman (input) for mailman id 1461314; Mon, 26 Oct 2026 13:03:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLKMQ-0006ZD-CF for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:03:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKMP-00Go75-P3 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:03:33 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf4f9a-2eae-0a2a0a5409dd-0a2a4501e768-32 for ; Mon, 26 Oct 2026 14:03:33 +0100 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 6adf4fa5-5984-0a2a45010019-c387df82b894-3 for ; Mon, 26 Oct 2026 14:03:33 +0100 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 2536A222CD; Mon, 26 Oct 2026 13:03: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 97E0E13408; Mon, 26 Oct 2026 13:03: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 Hlb2G6JP32pnWwAAD6G6ig (envelope-from ); Mon, 26 Oct 2026 13:03: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; none Authentication-Results: smtp-out1.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 , Haiyang Zhang , Wei Liu , Dexuan Cui , 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 , Zhongqiu Han Subject: [PATCH v5 11/12] treewide: convert rdmsrq() from a macro to an inline function Date: Mon, 26 Oct 2026 14:02:22 +0100 Message-ID: <20261026130223.773129-12-jgross@suse.com> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261026130223.773129-1-jgross@suse.com> References: <20261026130223.773129-1-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 2536A222CD X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spam-Level: X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[] X-Spam-Flag: NO X-Spam-Score: -4.00 X-purgate-ID: tlsNG-d62444/1793019813-1E27A4F7-6FB9BB1B/0/0 X-purgate-type: clean X-purgate-size: 169504 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: Rafael J. Wysocki (Intel) # ACPI, cpufreq, powercap, thermal Acked-by: Sean Christopherson Acked-by: Reinette Chatre # resctrl Reviewed-by: Zhongqiu Han # cpufreq Acked-by: Ilpo Järvinen # pdx86 Reviewed-by: K Prateek Nayak # amd-pstate Tested-by: K Prateek Nayak Reviewed-by: Yazen Ghannam # mce, amd64_edac --- 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 | 6 ++-- arch/x86/kvm/vmx/main.c | 2 +- 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 | 34 +++++++++---------- 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 | 22 ++++++------ 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/edac/intel-bff.c | 4 +-- 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 +- 139 files changed, 488 insertions(+), 490 deletions(-) diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index eb2e853e950a..6a13af13ca59 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -2046,7 +2046,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 54b13faba116..0cc060c7a9e6 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 a55646fcb846..0972690c7d45 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 7aa5a5b652a2..29c120b4ed0c 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); @@ -983,7 +983,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 4e344fb1ae3e..c2e15b490bba 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -852,7 +852,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; @@ -1734,10 +1734,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); @@ -1745,19 +1745,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); @@ -1769,7 +1769,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 0a34d674df59..20e96e6c649c 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -2974,7 +2974,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; } @@ -3533,7 +3533,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) { /* @@ -6367,8 +6367,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 @@ -6525,7 +6524,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; @@ -8104,7 +8103,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 8444670cee4a..b3b6ea4679ac 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -3356,7 +3356,7 @@ static int intel_pmu_drain_arch_pebs(struct pt_regs *iregs, bool corrupted = false; 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 0b446d8912e4..68d184ea5bcf 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); *br = (struct perf_branch_entry){ .from = msr_lastbranch.from, 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 49349afee611..2478d93e2e45 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; } @@ -934,7 +934,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"); @@ -993,12 +993,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 */ @@ -1621,7 +1621,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 1b460cf27a10..65834b182b7a 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -645,7 +645,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); } @@ -658,7 +658,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); } @@ -6373,7 +6373,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 e274802ef062..20642560f965 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -1678,11 +1678,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); } } @@ -1836,7 +1836,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 b90e6f487533..0a3f2e9e77ba 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()) { @@ -676,7 +676,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); @@ -710,7 +710,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 1ee4b127004d..e1e5d32c6286 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1880,7 +1880,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 3972966cb023..1714bd67604d 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; @@ -1115,7 +1115,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 000ebee2d247..5696cfce34d4 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"); @@ -3288,7 +3288,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 9bd50c68cd7e..631d3cef9fa0 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); @@ -607,7 +607,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); } @@ -620,7 +620,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); @@ -1356,7 +1356,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; } @@ -1947,10 +1947,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 50b1614968be..33d54728a5a3 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; } } @@ -2207,7 +2207,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 9f09d388ed20..7d481d28fcdb 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -1017,7 +1017,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 9e440e30c179..b3d4529799da 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; @@ -67,7 +67,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 80a7f41cf3ad..bbe881cf4492 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -377,7 +377,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 9f0efbe94793..ce98631561da 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -766,7 +766,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 eb690ba90180..c6cba46626e7 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 e91650af44c2..e429f9296e23 100644 --- a/arch/x86/kvm/msrs.c +++ b/arch/x86/kvm/msrs.c @@ -1215,7 +1215,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 136069dfcd44..1b2150534c04 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4758,8 +4758,8 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags) vmcb_mark_all_clean(svm->vmcb); 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); } /* if exit due to PF check for async PF */ @@ -5620,7 +5620,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/main.c b/arch/x86/kvm/vmx/main.c index d75170a6199e..3d8fa36fb74f 100644 --- a/arch/x86/kvm/vmx/main.c +++ b/arch/x86/kvm/vmx/main.c @@ -909,7 +909,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) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 516ba03bf608..89cc051d8aff 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -7371,8 +7371,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 fb7ad53855f1..49ec015b5114 100644 --- a/arch/x86/kvm/vmx/pmu_intel.c +++ b/arch/x86/kvm/vmx/pmu_intel.c @@ -323,7 +323,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); @@ -787,7 +787,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 @@ -816,7 +816,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); @@ -831,7 +831,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 82eb891f684c..aa8d23ba1204 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; } @@ -2907,7 +2907,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) @@ -2927,7 +2927,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; @@ -4504,7 +4504,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); /* @@ -4516,11 +4516,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); } @@ -7897,7 +7897,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) { @@ -8545,7 +8545,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 32563a91fba9..a55336c4ebfc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7097,7 +7097,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 @@ -7129,7 +7129,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; } @@ -7141,7 +7141,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 65110b2ee1a1..d97ec1b0bf91 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 bd70c4d0b774..816511de0d64 100644 --- a/arch/x86/virt/svm/sev.c +++ b/arch/x86/virt/svm/sev.c @@ -173,7 +173,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; @@ -277,7 +277,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; @@ -542,7 +542,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; @@ -582,7 +582,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; @@ -682,7 +682,7 @@ void snp_enable_rmpopt(void) * Per-CPU RMPOPT tables cover at most 2 TB. Program each core's * RMPOPT_BASE with the start of RAM to optimize up to 2 TB. */ - rdmsrq(MSR_AMD64_RMPOPT_BASE, base); + base = rdmsrq(MSR_AMD64_RMPOPT_BASE); if (!(base & MSR_AMD64_RMPOPT_ENABLE)) for_each_cpu(cpu, cpu_primary_thread_mask) wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, @@ -716,7 +716,7 @@ int __init snp_rmptable_init(void) * SnpEn set across shutdown), in which case snp_prepare() bails without * disabling CPU hotplug, so disable it here. */ - rdmsrq(MSR_AMD64_SYSCFG, val); + val = rdmsrq(MSR_AMD64_SYSCFG); if (val & MSR_AMD64_SYSCFG_SNP_EN) cpu_hotplug_disable(); @@ -742,8 +742,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"); @@ -776,13 +776,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"); @@ -818,7 +818,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) { if (probe_segmented_rmptable_info()) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 96ced0494b68..ab473c13a3dd 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -1570,7 +1570,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 2e74a000cdc7..057d83ee8f44 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 4bedfbfc18b6..9b50f57034a1 100644 --- a/drivers/cpufreq/amd-pstate.c +++ b/drivers/cpufreq/amd-pstate.c @@ -647,8 +647,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 17158cb25dd8..4681d0a51fac 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); } @@ -1359,7 +1359,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; @@ -1736,7 +1736,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); } @@ -2030,7 +2030,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; } @@ -2038,7 +2038,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; } @@ -2046,7 +2046,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; } @@ -2077,7 +2077,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); @@ -2093,7 +2093,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); @@ -2104,7 +2104,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( @@ -2112,7 +2112,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; } @@ -2460,8 +2460,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); @@ -3652,7 +3652,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"); @@ -3708,7 +3708,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 0c0d11c72925..0c7a545c0db6 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/edac/intel-bff.c b/drivers/edac/intel-bff.c index adf2ec343129..3513cb8855ea 100644 --- a/drivers/edac/intel-bff.c +++ b/drivers/edac/intel-bff.c @@ -252,13 +252,13 @@ static int __init bff_init(void) if (!cpu_feature_enabled(X86_FEATURE_MCA)) return -ENODEV; - rdmsrq(MSR_IA32_MCG_CAP, mcg_cap); + mcg_cap = rdmsrq(MSR_IA32_MCG_CAP); if (!(mcg_cap & MCG_TES_P)) return -ENODEV; if (!cpu_feature_enabled(X86_FEATURE_CORE_CAPABILITIES)) return -ENODEV; - rdmsrq(MSR_IA32_CORE_CAPS, core_caps); + core_caps = rdmsrq(MSR_IA32_CORE_CAPS); if (!(core_caps & MSR_IA32_CORE_CAPS_BFF_RESET)) return -ENODEV; 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 d8225242c73f..25c88dbf3750 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 a045a384b949..c70efc7301a5 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -2123,35 +2123,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; @@ -2179,7 +2179,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) @@ -2191,7 +2191,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)) @@ -2211,7 +2211,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) @@ -2465,7 +2465,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); } @@ -2474,7 +2474,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); } @@ -2483,7 +2483,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); } @@ -2552,7 +2552,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. @@ -2592,7 +2592,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 d6686d03056a..e70f51dd14b9 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.56.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:06:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:06:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461323.1672309 (Exim 4.92) (envelope-from ) id 1xLKPc-0007Mv-Uf; Mon, 26 Oct 2026 13:06:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461323.1672309; Mon, 26 Oct 2026 13:06: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 1xLKPc-0007Mo-Ro; Mon, 26 Oct 2026 13:06:52 +0000 Received: by outflank-mailman (input) for mailman id 1461323; Mon, 26 Oct 2026 13:06:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLKPb-0007Ld-By for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:06:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKPa-003E0O-Hd for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:06:50 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf5069-2eae-0a2a0a5409dd-0a2a4501db4e-14 for ; Mon, 26 Oct 2026 14:06:50 +0100 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 6adf506a-5984-0a2a45010019-d1558031d9d9-3 for ; Mon, 26 Oct 2026 14:06:50 +0100 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a35db1f202so13488045e9.3 for ; Mon, 26 Oct 2026 06:06: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-4a35a5822a7sm200556725e9.11.2026.10.26.06.06.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 06:06: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=1793020010; x=1793624810; 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=XjzpRtJCLLAF5cHo+M935TSFiH8JPHWUr5T6NqDLR+o=; b=QYbXFZV2dgePAmgtbFjJQiojrhSVDLTjoLUWamgD+c0OqioPuX9bMkD27C1CyjMtgZ CzQkIeElHwmszg0j7xhXXgKMKnNyL9qLVwaT4i5aZfEcZTi3CjdkDrNFR1aHxlkOxpQ6 VhV7YgaZnD4H2bzAJgM8Gzelkut+o5ba8C6BbpHU8epS8SvM7AKoVVQIaLcbdGsTYdw8 /dOuveq8bsGBMe75O7zMdvBztp/S5wuGZnEea5B+gLNtPA5aeEezHvrChPGnQ6n0eXiY NDomT8izHiLqMuNJofKCAYQMkiqxK1I7j2lLgFpO2BDbgGJB7/v+kqbBVD6Y8NHinEPr IZ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793020010; x=1793624810; 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=XjzpRtJCLLAF5cHo+M935TSFiH8JPHWUr5T6NqDLR+o=; b=VN3623G/smBbkn9cjWz+2IV9htAfh+mNpIYmz0ZYuzMzYxFhKn+f6wJyDjpFEnaW+H NyrcOOPgJzar+la0znVtDKV2g95c89os6VbvSqFfSM3rgAxDAz+uyFfulIEYfDoAqHUs 6Hc/hUvG4QC94SYif0+bMHi+MwGk1WOnEDXariJ9h338fjYQvUs0CbIFRHlfvqaaSjzW RqCYb7BMUgjEJWZ4MzQrpwi3K0+orGnkXhKfrWGWKtEkBkSHiwOYy3n+t/thDWFrDjQK KWKfkZrRMi5dFGykhkv2Uthtw66G3UhPnl9JnThmOttc9A9DWUYSVjTL/aK//1E5K+AB WOOQ== X-Forwarded-Encrypted: i=1; AKwUvBwyCDa7Kw0q1tzLXDK25Xfg0ng1+yF3x9kPEViPjaiUpdVqRSvXyfMXfKcdbOeMCAJvhaXRMKLfI/0=@lists.xenproject.org X-Gm-Message-State: AFq9FYKn9IeFEsWulzg2jh71UkD28cgz8PrvP5vPbePFMi4Mfxh0bgZA D6l52W+pLXwK9DGSM3EbKwKRSmgaKzHZTsfunS4cDGFmrFfN563zI/knK3sg6aKYkQ== X-Gm-Gg: AYBFou3CKqR7rsjSFTedbDJWjgVRPNdchSt4L09u0/ba2WkZl9VDpBpejKALYDQMWB0 zGiWLaybsLNF2tlTJiQW4WFCA6SImxjMR/GwxVTsaFh/sF4TdesTxGqx976+PNJPAe7d0eckEF4 qnx2YtKP6SwwPQZoSrsxJF1/2ST55Gaix3aJWSXzZ/kbAjqwCzPq9+B/WNouCTZbATG31p3TVdy LRvy36xUUhZSM7TTEa43XPi1yx8isGUHQyxpLy8Lj9BiAO3S7u0UT9cQ080o947QRJFkadyTS4n dmeP4q2SYo7/Ea7UKMzspMYvvFggVRgkUru6rrcTUih2PYc2VkVQsirrwW4hkjY32gCm7szuQO7 z90w1rgFkFtko8YTugC7B6BkDzMMd0K0UXU1vWY9bSno5vHTpKR96Smm6+D0rVjSVfffhNOZ1ml p0F+TmO3qg/c9+uMe2X6mef2c3ERIzBG5/5ubuTUxQisLqRMiVp/Z/BOZUAatk6+dhpW3cn2/zY SvpsGNHyZKgTCbHXjtZhkV0V3zNrg1Ms3xcZQLRcLl6ALfGi6xqIy6p4tnJiIp6thdcvOm/1jsd HHkjkLCoSWxAqx4GruCFI/ySgIK+9paZhdR/UXzeViSo X-Received: by 2002:a05:600c:524d:b0:4a1:a45a:88f with SMTP id 5b1f17b1804b1-4a35acb07c5mr113287045e9.20.1793020009781; Mon, 26 Oct 2026 06:06:49 -0700 (PDT) Message-ID: <47d6f426-6751-4a32-a187-2fb8a5347091@suse.com> Date: Mon, 26 Oct 2026 14:06:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/vcpu: ensure no write when runstate handler is NULL To: Roger Pau Monne Cc: Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261023161742.67329-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: <20261023161742.67329-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1793020010-C475B757-ABCCE2FF/10/78276251493 X-purgate-type: spam X-purgate-size: 1464 On 23.10.2026 18:17, Roger Pau Monne wrote: > --- a/xen/arch/x86/x86_64/domain.c > +++ b/xen/arch/x86/x86_64/domain.c > @@ -58,6 +58,11 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > rc = 0; > guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); > > + /* NULL handle is deregistering the address. */ > + if ( compat_handle_is_null(area.addr.h) ) > + break; > + > + /* Update the newly-registered runstate area, best-effort. */ > if ( v == current ) > { > XLAT_vcpu_runstate_info(&info, &v->runstate); While likely unnecessary in this x86-only handling, ... > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -2330,6 +2330,11 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > rc = 0; > runstate_guest(v) = area.addr.h; > > + /* NULL handle is deregistering the address. */ > + if ( guest_handle_is_null(area.addr.h) ) > + break; > + > + /* Update the newly-registered runstate area, best-effort. */ > if ( v == current ) > { > __copy_to_guest(runstate_guest(v), &v->runstate, 1); ... if we make null an official "de-register", then imo the earlier guest_handle_okay() also wants bypassing in the null case. An arch could - in principle - reject a null handle. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:12:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:12:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461331.1672320 (Exim 4.92) (envelope-from ) id 1xLKUy-00010y-Ha; Mon, 26 Oct 2026 13:12:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461331.1672320; Mon, 26 Oct 2026 13:12: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 1xLKUy-00010r-EH; Mon, 26 Oct 2026 13:12:24 +0000 Received: by outflank-mailman (input) for mailman id 1461331; Mon, 26 Oct 2026 13:12:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLKUx-00010l-7r for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:12:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKUw-000n4I-G9 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:12:22 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf51a9-bab6-0a2a0a5309dd-0a2a4503b6ac-36 for ; Mon, 26 Oct 2026 14:12:22 +0100 Received: from [40.93.196.43] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf51ae-fae8-0a2a45030019-285dc42b0c3a-3 for ; Mon, 26 Oct 2026 14:12:16 +0100 Received: from DS1P221CA0008.NAMP221.PROD.OUTLOOK.COM (2603:10b6:8:451::7) by CY8PR12MB7561.namprd12.prod.outlook.com (2603:10b6:930:94::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 13:12:12 +0000 Received: from CH7PEPF00000018.namprd21.prod.outlook.com (2603:10b6:8:451:cafe::9f) by DS1P221CA0008.outlook.office365.com (2603:10b6:8:451::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Mon, 26 Oct 2026 13:12:11 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH7PEPF00000018.mail.protection.outlook.com (10.167.244.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.0 via Frontend Transport; Mon, 26 Oct 2026 13:12:11 +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.53; Mon, 26 Oct 2026 08:12:11 -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.53 via Frontend Transport; Mon, 26 Oct 2026 08:12: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=ShIbJXUphFfBpyfG//cpFNKTR73qU/vJkUb+BT1gMtShllfAis4sYIPvAnw+rfDLCpuLHupx+I8OafRsVBudXlVZhgvvxDbBo27SzH8xZOPcn3Fb15RrDWUOK9hjVMeicFHlQ7xY4vJlp836g9eYaGzYibX/eNpk+xAoW7h0IUaxOnBxf3oYZ58onL8u8/E9cr078PBhNTJMA+FGpIy/UYoLWZw9iL/0xVWtUt93DA6HscmCVGNx9PYDsy+LAgrKdrq0pVHvMbMUrt4HyQqwXga7QvS+v1Sx2GXXD0V4S9I5wbdL7/SG4RbeLCuzRS1XILOsYlF3siEVOZ4epMLzzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1L5hpLtlJskaYdjEaq3r1Xa0w1uhEaH1HjVThLS280Q=; b=Ihqec8wLr2btcPTCmXr29N8bW7p84OJq6X6bUAT4e34uToG1QZ03Z8Tj3xGUGRb8Jl4U5F6SjTWQbbOgfbPIZrWTQ5l8kCF0fgBMiY5kISD+v6rzNOBMf1wHZEZPd78dHlML+4YEqk8ivbqtlO1VduSIKBeXhaS1X5sr8lqE45wYN0Px+32LfDcNhiHaqoZ3Vl6wUYcbYY1+vheYyHGi1xeBx7+rV3Ql+hrFQP+poycSch8qXEDuu3WwfcbpjteMe9QYuBtVL1g7WfL6OYI4WaWOHP/oWkvlUZx7tjr+Xa0R2mDFMVTxTMBIq6J71bSCo7DEYz2T014+VnFRjzCS6w== 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=1L5hpLtlJskaYdjEaq3r1Xa0w1uhEaH1HjVThLS280Q=; b=XmEHA4BgsWL2y4METN2Otq+08tzOKdzYQR32bzfogUbSpXpzMkdDKNnHxnTIL+Jzi6m6HoYlXgdIVV/TTBaZIVEUwF6PlNvPd1pg8t/Um/eJwHNA3A13QrLgEJ0zgvL+1my9WZTpu0pQtUK72vEsQv0S0pH9wiqny3H+erO2YPM= 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: <92c60d77-5f7b-4742-b473-84126fd6168b@amd.com> Date: Mon, 26 Oct 2026 14:12:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] xen/arm: populate a default P2M pool for new domains To: Julian Vetter , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1792761821.8631fc262581453bbf619ec5b2062170.1a168ee7993000f79f@vates.tech> <1792762007.8631fc262581453bbf619ec5b2062170.1a168f1512b000f79f@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1792762007.8631fc262581453bbf619ec5b2062170.1a168f1512b000f79f@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PEPF00000018:EE_|CY8PR12MB7561:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e3f88f2-1c81-4c1f-f7ff-08df3362bf2e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|1800799024|82310400026|36860700016|261009223027099003|261021121427099003|261022105027099003|261021123027099003|10067099003|56012099006|6133799003|18002099003|22082099003|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: wqSwOADt06xUdZ86f2ZV19R1M2dmu9m7oDMB0W69HEdzobew8VzUgJUzGtY33sFam8BoodEEdq2vQuOJReQQfweO0uwrHHD97kF1xqnVd3V/KTYnXPb1CEjnd5vyiLt2GH6dWXTDXkQVasva3PPsuPxB/9oSOUDtL4a6SXtC13aAbFJ1UXEZgCUp5AuYFJXUB9StGKB5bT/o4xRLx9cRjk71Lx7cdAzA7E70KegbZX3+oHTPLp/NTnRzSCGYyScakWiebhy/3m5Vw3yys5zrVoUi17HYHC47TsNE6D/wk9Y2hS25hXhXctPpPwfmKVml0lMJ4q2YT8fvnGFOkddTnM0xMRIW6V37nTGZK1jmE8OGllpYqw1cZpyI/MTSb5zy8R/46XCdeKEar9ADvoiAp6CHmyj2m67sDFhPNtX8XMslMJZ3Z+R/4kO96QtItCzmmaVeZhsr0qzbOJBTQjzkGRyvGllrfocMxSLrxHTXAsF1xlS5dic0q+pP2IDLrsqDNFx+59mO1XdjGJOrEikLi9RFHfOiW1oRm4M9xaRLxF63wU+EEeljz5s9i5+seLgUsoM2CrttyCDIbQZfNmJIDn/qXnK7xKYXIlokVWaQnX5q9Czz2VJ/3YKLnOhLscauiX+6QeS6rQajKKY5upAcqDxUBbJvGUt2giRZMpLKNNl74BXRfC6x/Zscp/6QxYDOP+JSwh8rhz7yR2nw3RtxJQ== 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)(23010399003)(376014)(1800799024)(82310400026)(36860700016)(261009223027099003)(261021121427099003)(261022105027099003)(261021123027099003)(10067099003)(56012099006)(6133799003)(18002099003)(22082099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: lhLd7dr7M2tDiGeDyLudGWLeKMQk+HutC6FW8h0tDDTzdiamScO/ulgAARIW9aubCB8xss0mRh24bH9Zd0nua7fSiK3KEh2PeQ7YHUzbE7LGcJV7iriGdC2GCOAAHUo+oStbmlutKKq+BMiWW3GxBAf38pKwHMlRcn6Q2go4ZHn9l7CsXluNfaC1GrtfaM8WJkpfeFQ1YK/TTn3zFYLC/MUtHgAXejktyADI4XUVarDv+soANiXDLEUzRzyp/AE9pQM5HVrBPUD8IwzcWPOyEslfS/bW++kJ5ch9Uz1SCrNDVex5visYDEPH0JS9KYbnoVY/1UdkgT9Q7CGsAsTg6/tCAYL010e9XpZKufKzoTzGSzlI0Opd7G6BCNUYfgUk8kdqhMAKUQqb39j2spuMOYa3meHE2+52UbtlxqxiPhzrjpCnG9KVNGIP1aLGAkK1 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 13:12:11.6680 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3e3f88f2-1c81-4c1f-f7ff-08df3362bf2e 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: CH7PEPF00000018.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7561 X-purgate-ID: tlsNG-33051d/1793020342-75C804E9-6389899A/0/0 X-purgate-type: clean X-purgate-size: 5612 On 23-Oct-26 15:26, Julian Vetter wrote: > On x86, a domain can be populated directly after the > XEN_DOMCTL_createdomain call. Sizing the pool is thus an optional tuning > step for the toolstack (libxl: "the Xen minimum is for safety, not > performance"). > > On ARM however, the P2M pool of a non-hardware domain starts empty. So, > any toolstack must size the pool before populating the domain's physmap, > otherwise no P2M tables can be allocated. This is an ARM specific step, > which every toolstack has to know about. > > Instead, populate a default pool in p2m_init(). Ideally, it would match > the formula used by dom0less (domain_p2m_pages()) and libxl > (libxl__get_required_paging_memory()), but that depends on the amount of > RAM for the given domain, which isn't known at domain creation. So, use > the calculation but without depending on the amount of RAM for the > domain, i.e., 1MByte per vCPU, plus 512KBytes for the extended regions. > Then dom0less and libxl set the full size, as they do today. > > Skip the hardware domain, which has no dedicated P2M pool. Also skip LLC > colored setups, as the domain's colors are only configured after domain > creation, so the pool pages would be allocated with the default colors. > > Signed-off-by: Julian Vetter > --- > Changes in v2: > - Size the default pool based on the exisiting formula > - Rewrite commit message to explain why a default pool is desirable > --- > xen/arch/arm/mmu/p2m.c | 24 ++++++++++++++++++++++++ > xen/common/device-tree/dom0less-build.c | 7 +------ > xen/include/xen/domain.h | 13 +++++++++++++ > 3 files changed, 38 insertions(+), 6 deletions(-) > > diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c > index 2cf35d8a37..d4971ba8d9 100644 > --- a/xen/arch/arm/mmu/p2m.c > +++ b/xen/arch/arm/mmu/p2m.c > @@ -3,7 +3,10 @@ > #include > #include > #include > +#include > +#include > #include > +#include > #include > > #include > @@ -1541,6 +1544,27 @@ int p2m_init(struct domain *d) > if ( rc ) > return rc; > > + /* > + * Populate the P2M pages pool here. So, the domain is usable without the > + * pool being sized first, as on x86. The toolstack, or dom0less, still > + * sets the full size later. > + * > + * Skip the hardware domain, which has no dedicated P2M pool, and LLC > + * colored setups, as the domain's colors are only configured after domain > + * creation. > + */ > + if ( !is_hardware_domain(d) && !llc_coloring_enabled ) > + { > + unsigned long pages = > + PFN_DOWN(domain_p2m_default_kb(0, d->max_vcpus) * SZ_1K); domain_p2m_default_kb helper would better convert to pages right away, given that all the callers eventually need pages, not size in kb. > + > + spin_lock(&d->arch.paging.lock); > + rc = p2m_set_allocation(d, pages, /* can_preempt */ false); I'm not sure if this design is correct (I know I asked "why can't we set the allocation right away" but at that time I did not consider the worst case). In the domain creation happening at runtime, this call can take a lot of time in the worst case (e.g. 128 vCPUs) and is not preemptable unlike XEN_DOMCTL_set_paging_mempool_size. Maybe indeed it's better to come up with a sane default, given that toolstacks still have to size it up to take into account the RAM size. FWICS x86 HAP uses 256 pages. We could use this value too. Does other Arm maintainers have any opinion here? > + spin_unlock(&d->arch.paging.lock); > + if ( rc ) > + return rc; > + } > + > return 0; > } > > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index fcb438c50a..21a13f9370 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -737,12 +737,7 @@ static void __init domain_vcpu_affinity(struct domain *d, > static unsigned long __init domain_p2m_pages(unsigned long maxmem_kb, > unsigned int smp_cpus) > { > - /* > - * Keep in sync with libxl__get_required_paging_memory(). > - * 256 pages (1MB) per vcpu, plus 1 page per MiB of RAM for the P2M map, > - * plus 128 pages to cover extended regions. > - */ > - unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128); > + unsigned long memkb = domain_p2m_default_kb(maxmem_kb, smp_cpus); > > BUILD_BUG_ON(PAGE_SIZE != SZ_4K); > > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h > index aeb8b36ad1..74dee32fb9 100644 > --- a/xen/include/xen/domain.h > +++ b/xen/include/xen/domain.h > @@ -132,6 +132,19 @@ int default_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg); > int arch_get_paging_mempool_size(struct domain *d, uint64_t *size /* bytes */); > int arch_set_paging_mempool_size(struct domain *d, uint64_t size /* bytes */); > > +/* > + * Default size of the P2M pool, in KBytes, for a domain with the given amount > + * of RAM and number of vCPUs. > + * Keep in sync with libxl__get_required_paging_memory(). > + * 256 pages (1MB) per vCPU, plus 1 page per MiB of RAM for the P2M map, > + * plus 128 pages to cover extended regions. This is Arm formula but the header is common. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:14:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:14:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461336.1672328 (Exim 4.92) (envelope-from ) id 1xLKWr-0001aH-RJ; Mon, 26 Oct 2026 13:14:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461336.1672328; Mon, 26 Oct 2026 13: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 1xLKWr-0001aA-Og; Mon, 26 Oct 2026 13:14:21 +0000 Received: by outflank-mailman (input) for mailman id 1461336; Mon, 26 Oct 2026 13:14:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLKWr-0001Zr-3m for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:14:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKWq-000nYu-9S for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:14:20 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf521e-bab6-0a2a0a5309dd-0a2a45088566-38 for ; Mon, 26 Oct 2026 14:14:20 +0100 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf522c-f659-0a2a45080019-d1558033c8db-3 for ; Mon, 26 Oct 2026 14:14:20 +0100 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4956869750eso19732015e9.2 for ; Mon, 26 Oct 2026 06:14: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-4a35a04ad39sm515439785e9.1.2026.10.26.06.14.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 06: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: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=1793020460; x=1793625260; 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=/nk6Dsi0r/4StCZS3toktvBtDFUiooqfEfEnNAIbM2s=; b=eJ9LL4lIWMac94G8dnwJxvQ6aRCGz+j5cJ/hNZuxG6Do9PyMKYJiDh+4gcxu6QF2hy xGT6Vaq0XBC5mU+bG7j6BYKGPu17LrE4j0D108d9pKyemejElwXMZGwvYtu4zs0JvVoX USfHe6I2tkYJ/poBYJQw7fcjQpy/xN46a7x2GpZsK2AmDBD+9NWjBdpyiuHf4X4oBf/U Klj5iSIt6m2EgsyqJeWz6LOsSk1dgjNhH23EStP3eifEdASRGe7zxG5L8bG1EvD6iHAw 1rahWHJ164fUgDlUPzwmYVVPQjElZBrRWnzPrUjgsxUHt+QqVnxEGjYQnr/OiMTMVMUV PXbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793020460; x=1793625260; 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=/nk6Dsi0r/4StCZS3toktvBtDFUiooqfEfEnNAIbM2s=; b=YFtzeMPiHrSEj8YPMB/U/X/9VSnKINHi7M4gPE4deGfhFXzzm489UryzpvGTlUtbOg i2oBaKs85viRHPxnjGLfYfWprkwjBCsmy/+LpiqQrZUxcVY8kD6mloyE05bl8CyFZA5e sVALG0xdRpefUwAWLiVl280f5DPghzI9UOeR8bI0eWfz0y6oii1hZjLpnLUHLw7dW4cJ FCBLH9ahiBzvU8mNvVRMKy1LP/MAii7OMci7RILtnw+CTbw82QViW0jTDaRfiUmmR/mG 6DcmR4gqbqGAXMozbQoXzSONL6EWq/Af/E5KnpMVncmdMS9CPm+TFO8xHCwYPTGU2zoW fy3g== X-Forwarded-Encrypted: i=1; AKwUvBxa+m+5FOlGZiT5LSxn7dICcwQk0/wX5PRvbVqZ2Vh6X8j/iI6U7S20Cjp/cbWQVWNthvo+9dx6bNU=@lists.xenproject.org X-Gm-Message-State: AFq9FYLMTx45OREgvLgk/BzaDRM5xwYeesPuqFVGgP87+nULNGKwhErY E39E0GlDch9gmL+p1FpnSdyA2DWnsYmDKBUlRaH7zLB2qsopRvPLb4j0Tmw057GXmQ== X-Gm-Gg: AYBFou0pQ1TIS2zB3cjV/sMOPemd2cJiTI9LnOY0+LDiXrknba4wWZYBs9iXxQ4EyM3 kRZE/2KKRFAC4IRwOWwDUzlermt27Jw96wS8S9pNN4exEvUBv+PTFyZKVsj7WWMEIQlWMPQ8Ed9 /ZET9GydedqgG1izAZm6nqGkq8F9Ez3Atw6AbvF+T5KccJvqlVeQrQae4lmNqeGVT8APn7AZXIC 2f3UCLM+kLX8rEwJnhMyfwZAa0cLPJgdE76q3Zu7qWmadalUfekUCgWFPj1CLNQdjrhEaGlkpuf 8Hwnk3TvEuZ+XCNf8DeOCb/GuHJjSbjQkZ6lQ0PjTQUy+Q/6svxOeqsTBSyfaJnop2Wn5akLqhz Cy5v3cLjv/cRmwCOreVlv4nE2X5jAITu5Xdme+FtTTt8CTnZKo5TpbD5mT7Sto8g7BPZd8tk27g IfNMulkX+XQD9CCHrB3P8egeUn7UGljnZQCDN168Duw5qXEd7yJGwYldxfklPc+exLXW/jKTvg8 zCmG0bexhmrrmVmkrDtWRBHBzUVHvL7OQDOW3YIaBO0CZ5FCAaTt6YSXMrqTfWX7jYLMQcAD1z8 QSv6gfzKX35KzC3OdJPf3jLWZAc+w1TzXaFxlbW6aGs= X-Received: by 2002:a05:600c:1c2a:b0:4a1:dfaf:f465 with SMTP id 5b1f17b1804b1-4a35ac3a7d9mr160303825e9.4.1793020459649; Mon, 26 Oct 2026 06:14:19 -0700 (PDT) Message-ID: <67e298cd-3b84-4476-9dd3-607e505effe6@suse.com> Date: Mon, 26 Oct 2026 14:14:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations To: Shuaidong Chen , Stefano Stabellini Cc: Nicola Vetrini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org References: <20261026030309.2507461-1-shuaidong.chen@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: <20261026030309.2507461-1-shuaidong.chen@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793020460-CE14687B-07ABDAF3/10/78276251493 X-purgate-type: spam X-purgate-size: 1719 On 26.10.2026 04:03, Shuaidong Chen wrote: > MC3A2.R14.3 ("Controlling expressions shall not be invariant") is > deviated by two separate entries. One covers 'if' statements and > conditional operators and places no restriction on where the invariant > condition comes from. The other covers 'switch' statements, but only > when the controlling expression is a 'sizeof' operator. > > The rationale recorded for the two is the same: the condition is > deliberate. Nothing about a 'switch' makes an invariant condition less > deliberate than the same condition in an 'if', so the 'sizeof' > restriction reads as an artefact of that entry having been added for > read_atomic() and friends in arch/x86/include/asm/atomic.h rather than > as a considered limit. Well, if ( 1 ) can make sense, especially when 1 is the expansion of e.g. IS_ENABLED(). Otoh switch ( 1 ) doesn't make a lot of sense, even when it's as a result of the expanding IS_ENABLED(). I agree that limiting to just sizeof() is unnecessarily strict; alignof(), for example, should about always be usable where sizeof() is. Yet making if() and switch() equal is imo going too far. I realize though that it may be difficult to find a suitable boundary. Stefano - do you possibly still have notes from the discussions long ago? > Fold switch_stmt into the general entry and drop the 'sizeof'-restricted > one, which the general predicate now subsumes. Invariant 'switch' > conditions that are not a 'sizeof' become deliberate as a result; that > is the intent. > > Signed-off-by: Shuaidong Chen What you don't say at all: Does this help with any remaining violations? Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:15:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:15:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461343.1672338 (Exim 4.92) (envelope-from ) id 1xLKYC-0002Al-9W; Mon, 26 Oct 2026 13:15:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461343.1672338; Mon, 26 Oct 2026 13:15: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 1xLKYC-0002Ad-4f; Mon, 26 Oct 2026 13:15:44 +0000 Received: by outflank-mailman (input) for mailman id 1461343; Mon, 26 Oct 2026 13:15:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLKYB-0002AV-D2 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:15:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKYA-0079fO-Pm for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:15:42 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf5276-2eae-0a2a0a5409dd-0a2a4508d88a-42 for ; Mon, 26 Oct 2026 14:15:42 +0100 Received: from [209.85.208.47] (helo=mail-ed1-f47.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf527e-f659-0a2a45080019-d155d02fb495-3 for ; Mon, 26 Oct 2026 14:15:42 +0100 Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-6af9a90e4bbso3188934a12.0 for ; Mon, 26 Oct 2026 06:15:42 -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-c46bd66ca8asm323389166b.57.2026.10.26.06.15.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 06:15: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-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=1793020542; x=1793625342; 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=9W11/s1CImm7wmuaKsIjWUPwVtLZDt22f8HicGbUAGc=; b=ESngmktZQk/GTxZ4EdwwXWfL92kdkkpnhiMmtn9QQP7Bo3dDxaX2YjVUzJrDiJzlPn d/RsCMcthVdHlyIKlZiEjGnmfaAb2aSuUzNqqUobC5Vzdpnhw1t/aZYck2xraYA291md m3HXsc24A6pGBBYIk38H+hhGjnG0eg3L8NJswKTKSdIpb6anpxDoyGtuCElgBnQyz9nx m3hb1PVCO6iF6b7hqwIcRUMqf/6Lk2N1O9Ug+9UMUQ68nTwKjhLaor8CDh/ALz5ANwmJ TJeqStFhEIN7pN4AhqdasH6TJQwy3g5lgVpf2jqLeB8j2o0sfMO1HX81qOQ9VBazfWkZ KVUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793020542; x=1793625342; 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=9W11/s1CImm7wmuaKsIjWUPwVtLZDt22f8HicGbUAGc=; b=nFwVCrcPON27KTVV8atd9jHjyS7dsBqauY/zOjeEjPrp/0YhVj54O/n18hy4ZnOdxB zUMGrCNQ4zvF0rJQ9uIpBz9QKdoaH08/JyxLa40qndVf/oWUc2BpuliDr+1x35L8AXgU mHgxFLBElimYyJvfNdg/IHLG1VRTGTHDZ2szLdgAmQZZfb6zSkUGZo5aWU7R4TXhGhDA 5n4M+Z9reO5c+ZhVWszy1p6fALnksH8JMju6JJAMU2a27+nE2Aku4xm89Wue7HV6KhcK dCOmo0N6ASRR4HI+BC66w607U4ZfXv1XbFur79VjtAv89xQHqxRK1fqyDkCeqSPVS42O hMiA== X-Forwarded-Encrypted: i=1; AKwUvBzMqQOxwSLDgbuJfgzwgkwCfyy+eCd8tRun5o4LQT50HerRf5R4IMFacrZjCSYPki3zuy0/JGaVQ+4=@lists.xenproject.org X-Gm-Message-State: AFq9FYKd1PcyRLbTblFkO5KK4DbqkKbLBuj9wj3kp79ZFDBP9yKdf7yJ VF8BMZRVVzS9tyWSLa/2zsijPC66lzuaTRBRkM8QBYBX0RYHU9bVPU7ww1/JGarrwdM= X-Gm-Gg: AYBFou0s4/4kjFMk8nT7mQq7CHPSnfqwoS2SmpirYayYS9TRTveMBnC7Tds4x2iO/9T kLkqUP3eGaYBH40s+XoyJAyMCZNPQ9CeakNyxsdqzrD3qQky2uHYGAkBFPB1tIrc71zxyjPuQ+g r5cpBLhiF9oTvrv+RYaIojxG8FfzvB3mzZPgRiBstLvkyzSGQhiTVTs1iVGU0gGJmHcpPs9T4QP +4Uv8DEsYUieGzhSMR46ZLnfHRuJkmFiwyn8fklSnw8dcSapYxWf9JkStkz4YS2tZ28R6AMpp2N wIqR7Vcv9BPXPpJk3dRe+iJU/cGXyukd6trjVtlCQptqllXxJGGulB/1JJc/0m5zgtMo4LQkzNo ig5LJZm8tdM5BlEeWxtT+x+iV0k/jYkA0iTIa+on6spfS+2D3ZE0O2KcnN6iKyHfxmPU9Z6VAsf qxzI565HV/vlfnWtn5chSpm/m3s2wGNbtVhvo9Ae4yjYrDsIqs/Dav6fHOiTNIviZ4lUH6q+iHs fauD6wGlUMFAoeVaMYhQ2XRUfQxZD/Ec2vyxmLzdbmkn5zYdI3qX0wQfMYV0N2fNO3ga71JsCdb jczfFn7wTtK7XiafG91KLoBkp81R/WqytbHH53Ri2GVgtFotU2J5L52AVu5uUxVGb/6VOeA9alt tSaVlOA== X-Received: by 2002:a17:906:d54a:b0:c40:aa04:18d0 with SMTP id a640c23a62f3a-c46bdd971cemr762427766b.17.1793020542119; Mon, 26 Oct 2026 06:15:42 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 14:15:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/sched: Fix the sorted insertion in sched_domain_insert_unit() To: Jan Beulich , Stefano Stabellini Cc: dfaggioli@suse.com, gwd@xenproject.org, xen-devel@lists.xenproject.org References: <20261020223534.3703199-1-stefano.stabellini@amd.com> <23ca037f-d7cd-4140-a991-ef51bc095d60@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: <23ca037f-d7cd-4140-a991-ef51bc095d60@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------d8gZnwJpcRcwiQFyzTKdC0KR" X-purgate-ID: tlsNG-c1860d/1793020542-CFCD387B-5DB7C2C9/35/110847 X-purgate-type: clean X-purgate-size: 9790 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------d8gZnwJpcRcwiQFyzTKdC0KR Content-Type: multipart/mixed; boundary="------------TN007YJtl77CItgyr5IQc0wk"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich , Stefano Stabellini Cc: dfaggioli@suse.com, gwd@xenproject.org, xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH] xen/sched: Fix the sorted insertion in sched_domain_insert_unit() References: <20261020223534.3703199-1-stefano.stabellini@amd.com> <23ca037f-d7cd-4140-a991-ef51bc095d60@suse.com> In-Reply-To: <23ca037f-d7cd-4140-a991-ef51bc095d60@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= --------------TN007YJtl77CItgyr5IQc0wk Content-Type: multipart/mixed; boundary="------------SGxOss243zLeNP0DHZoa0zda" --------------SGxOss243zLeNP0DHZoa0zda Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMTAuMjYgMTM6NDYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyMS4xMC4yMDI2 IDAwOjM1LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+PiBUaGUgbG9vcCBsaW5rcyB0 aGUgbmV3IHVuaXQgaW4gZnJvbnQgb2YgdGhlIHVuaXQgd2hvc2Ugc3VjY2Vzc29yIGhhcyBh DQo+PiBoaWdoZXIgdW5pdF9pZCwgcmF0aGVyIHRoYW4gYWZ0ZXIgaXQ6IGluc2VydGluZyAx IGludG8gezAsIDJ9IGdpdmVzDQo+PiB7MSwgMCwgMn0uIFN0b3AgYXQgdGhlIGZpcnN0IHVu aXQgd2l0aCBhIGhpZ2hlciB1bml0X2lkIGluc3RlYWQuDQo+Pg0KPj4gSSB0aGluayBpdCB1 c3VhbGx5IHdvcmtzIGJlY2F1c2UgZ3Vlc3QgdkNQVXMgYXJlIHR5cGljYWxseSBpbnNlcnRl ZCBpbg0KPj4gb3JkZXIuDQo+IA0KPiBQbHVzIEkgY2FuJ3Qgc2VlbSB0byBiZSBhYmxlIHRv IHNwb3QgYW55dGhpbmcgd2hpY2ggZGVwZW5kcyBvbiBhbnkNCj4gcGFydGljdWxhciBvcmRl cmluZyAoZXhjZXB0IGZvciBzY2hlZF9kb21haW5faW5zZXJ0X3VuaXQoKSBpdHNlbGYpLg0K DQpzY2hlZF9tb3ZlX2RvbWFpbigpIHJlbGllcyBvbiB0aGUgc2VxdWVuY2UgaW4gYSBzdWJ0 bGUgd2F5Og0KDQogICBpZiAoIHVuaXQtPnVuaXRfaWQgKyBncmFuID09IHYtPnZjcHVfaWQg KQ0KICAgICAgIHVuaXQgPSB1bml0LT5uZXh0X2luX2xpc3Q7DQoNCj4gDQo+PiAtLS0gYS94 ZW4vY29tbW9uL3NjaGVkL2NvcmUuYw0KPj4gKysrIGIveGVuL2NvbW1vbi9zY2hlZC9jb3Jl LmMNCj4+IEBAIC00ODksOCArNDg5LDcgQEAgc3RhdGljIHZvaWQgc2NoZWRfZG9tYWluX2lu c2VydF91bml0KHN0cnVjdCBzY2hlZF91bml0ICp1bml0LCBzdHJ1Y3QgZG9tYWluICpkKQ0K Pj4gICANCj4+ICAgICAgIGZvciAoIHByZXZfdW5pdCA9ICZkLT5zY2hlZF91bml0X2xpc3Q7 ICpwcmV2X3VuaXQ7DQo+PiAgICAgICAgICAgICBwcmV2X3VuaXQgPSAmKCpwcmV2X3VuaXQp LT5uZXh0X2luX2xpc3QgKQ0KPj4gLSAgICAgICAgaWYgKCAoKnByZXZfdW5pdCktPm5leHRf aW5fbGlzdCAmJg0KPj4gLSAgICAgICAgICAgICAoKnByZXZfdW5pdCktPm5leHRfaW5fbGlz dC0+dW5pdF9pZCA+IHVuaXQtPnVuaXRfaWQgKQ0KPj4gKyAgICAgICAgaWYgKCAoKnByZXZf dW5pdCktPnVuaXRfaWQgPiB1bml0LT51bml0X2lkICkNCj4+ICAgICAgICAgICAgICAgYnJl YWs7DQo+PiAgIA0KPj4gICAgICAgdW5pdC0+bmV4dF9pbl9saXN0ID0gKnByZXZfdW5pdDsN Cj4gDQo+IFBhcnQgb2YgdGhlIHByb2JsZW0gbWF5IGFsc28gYmUgdGhhdCAicHJldl91bml0 IiBkb2Vzbid0IGxvb2sgdG8NCj4gcHJvcGVybHkgZGVzY3JpYmUgdGhlIHB1cnBvc2Ugb2Yg dGhlIHZhcmlhYmxlOiBXZSBpbnNlcnQgYmVmb3JlDQo+IHByZXZfdW5pdCwgd2hlbiB0aGUg bmFtZSAodG8gbWUgYXQgbGVhc3QpIHN1Z2dlc3RzIHdlIG1lYW4gdG8NCj4gaW5zZXJ0IGFm dGVyIGl0LiBJT1cgSSB0aGluayBhIHJlbmFtZSAodG9nZXRoZXIgd2l0aCB0aGUgY29ycmVj dGlvbg0KPiBvZiB0aGUgY29uZGl0aW9uKSBtYXkgaGVscCBoZXJlLg0KDQpJIGFncmVlLiBN YXliZSAibmV4dF91bml0Ij8NCg0KDQpKdWVyZ2VuDQo= --------------SGxOss243zLeNP0DHZoa0zda 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----- --------------SGxOss243zLeNP0DHZoa0zda-- --------------TN007YJtl77CItgyr5IQc0wk-- --------------d8gZnwJpcRcwiQFyzTKdC0KR 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/Ey8FAmrfUn0FAwAAAAAACgkQsN6d1ii/Ey8Q xgf+OTn/CxoqfvAJql02tJ3Il/kMeOySftZcuuEwWhzRr24jEyvTD9Jn7m9ALDD+CHS99j6HeppG yDO+kbxVp3YiNwO2T5imRog67DSY5q5kJ1UvIB2++XK3bHZeTILPIppDM8eH/7jbG2jbBwZtt/Pe 06m52Ku7MODbUafH8qZizfVc1Zn9b5AOb/vbhnXbzw/l2yVeXgtNO/RxSagEA9YDCKzSLA1e2teV djsozRm7+KlAPhSJeCr1scYm6JMkdcejlJZiqaKDnUjVPuoAqNauQ67HTqKaAMFKZ81P54Z4LGX4 K2ybd9AY4S0ogEdptfwS/xMnzhQSetCrCUukLWvMNA== =2jEx -----END PGP SIGNATURE----- --------------d8gZnwJpcRcwiQFyzTKdC0KR-- From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:25:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:25:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461351.1672345 (Exim 4.92) (envelope-from ) id 1xLKhi-0004RP-48; Mon, 26 Oct 2026 13:25:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461351.1672345; Mon, 26 Oct 2026 13:25: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 1xLKhi-0004RI-10; Mon, 26 Oct 2026 13:25:34 +0000 Received: by outflank-mailman (input) for mailman id 1461351; Mon, 26 Oct 2026 13:25:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLKhg-0004R6-3C for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:25:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKhf-00E7qq-CT for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:25:31 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf54c6-e002-0a2a0a5209dd-0a2a450aa2b4-12 for ; Mon, 26 Oct 2026 14:25:31 +0100 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf54ca-f2d2-0a2a450a0019-d155dd32e401-3 for ; Mon, 26 Oct 2026 14:25:31 +0100 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48df54150dfso1615513f8f.0 for ; Mon, 26 Oct 2026 06:25: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-48e3ebc39a8sm17375163f8f.11.2026.10.26.06.25.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 06: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=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=1793021130; x=1793625930; 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=hd/R/G5waAjta1bG/JloZRSe+IvgMCS1Vi84kc1JB8M=; b=T2WQqA1oX79YjO0W8+1ci+CKN7jJTyIkXoGc0y8P8i4yFvOMqatJyt5084kk4eE3Cz VB3UmKl+D9d9ZjD49z8Z8Sh7lOsgGsQp7/BI+nwQGci9QC/keln2KpcHYuVWTFHRlS6P /VFNrsDFIUgdSAuhtNeivPjkfHLfxE2rH2T4ZcaivNcItjBdAh+ftZcHBKfcP5aC11fr v4M5ki8G8TQSthME2eXjilBCl1hz1RRoI061Kn283AE6XTXByAyys0gNeASkU6lQBzcu PuY1VxF6OjwoLlNDDdjilQRc8fjGxlQCxtcqbWIKnzmknbYCygKOnOv5Fc7XjgQBADp8 Zl/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793021130; x=1793625930; 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=hd/R/G5waAjta1bG/JloZRSe+IvgMCS1Vi84kc1JB8M=; b=YkX7BN69A/Hur9ajI1gl20HMOv2FbWku0oUsyZYlVBwd6ZRr6MuvzvGabjnOAxbf8Y 1CxJ+yTTA4OMeTvrGIzLZd6u2qHvF51qRmUBCqfCt6WNHPT/iF+YliZzfJyGagRErTKh pt/V6uCE7cDm5jJrPKe1l6XVbVBXN6HmxjQf0xq+Y7Ub7G+h8FawDkzG+lXGh9i/xctk Q6YGEWeoi5SR/LwmbtvZPxF3asgCGwpjZC84tLN0rl/+4nA4ievRaiMXV3b4BwKJIFqL kCE32GtFJwXXf+75VfOGkoSb8pRibjxsw1ZW+1+2p6U1aEsSw6yBbhjWk1YtQHvZi7UL uWbw== X-Forwarded-Encrypted: i=1; AKwUvByGoR3RgqLGOoYr8m46y7oh8A5Ptbe9rKHXpRHlDj4c9wieaOASuyKm7Wx+ayOLmAkhPCD+DuQsA40=@lists.xenproject.org X-Gm-Message-State: AFq9FYK7yffYVl9hYOs8aFB+k5BYWUslyc9xmJHgLKb+OnbgFWuD0Htk MnuKcnvXGynoUt6oI2ceYCRX3lDJJ+3PJ3t5E6dpBwkvUyGlVkXhZDM5ni7M2o2Q9g== X-Gm-Gg: AYBFou0Wb6U9kbMCNfQH4hQxAgbH6McJ0JOi8V31gm7bdLTIGP/S+VllXsvsyaSCDGN N6FPB0GMxSnFCQUOLhLkMDYF0q5168zL7121g0/WggzC/7jXjcJcXS7RyqwblNl479kaiPVj/J2 AlyXZ53SH+uPL/3qJIe6OW+UFWP5N9xaice6WPE6bTl8dUXB8GlFKNd2zJCZn8Mm1m48/eg7V/L WymYeB/pOc5GWehiEZ2jIOKJ085Bia95K8qR6qeBmZ4pQ2a39/8OtQ+HM5/DhhvqW+S6vlH/Uvr PkZTQ5VAqmLM+ThaBDs+bZC6V5bOkhaJTUKbQsj5i43rd6e38M4nP+Ab2dZ/YIrpXE8phJK98eH nW8GYv6/GBvrcW4xfdlKGhkHDB3CFH+ZYBsNtLT8fuuJ66P4fwqSx93Xkv1K7lLFHL6AdpJNG5L MoUiaL5O9GHlfbJkYOidph2kx5Y+HVJ9n9ecNxG2EM28dv6H8jtJNphJ76WXCKCcrp/qpLwaXr2 R5bimpEchBJ29LjWbteISd7kdGgN6vw+Xe+1mt9TS46R5jZ3KgPb8OZFGt5YyLxIC07uN2Gm6X4 1v193f74ExibG7Ppk3zBi9OE8UpjDO7WHSzNIhNSePLlTYe5U/6bzjtFNcjDaGWDpg== X-Received: by 2002:adf:fa12:0:b0:48e:28bd:e1ad with SMTP id ffacd0b85a97d-48e3eb8f9fdmr8566357f8f.30.1793021130462; Mon, 26 Oct 2026 06:25:30 -0700 (PDT) Message-ID: <13d05dec-f7ba-4625-940a-b89b346610c6@suse.com> Date: Mon, 26 Oct 2026 14:25:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/amd/iommu: record the IOMMU for alias DeviceIDs To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261020221214.3683476-1-stefano.stabellini@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: <20261020221214.3683476-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793021131-4B8D5CFC-97529A22/10/78276251493 X-purgate-type: spam X-purgate-size: 1391 On 21.10.2026 00:12, Stefano Stabellini wrote: > add_ivrs_mapping_entry() marks an alias DeviceID valid and may give it > an interrupt remapping table, but records the IOMMU only for the > aliased device. If no IVHD entry names the alias DeviceID itself, > amd_iommu_setup_device_table() passes a NULL IOMMU to > amd_iommu_set_intremap_table(), and Xen crashes at boot. > > Signed-off-by: Stefano Stabellini The description deals with only part of what's needed for justification. What's missing is analysis of the safety of the change being made: There may very well be logic somewhere which relies on alias entries to be NULL. If there were (which I seem to have a faint recollection of), this change wouldn't be safe to make, and checks may instead be necessary to add elsewhere to circumvent the (vaguely described) boot time crash(es). Jan > --- a/xen/drivers/passthrough/amd/iommu_acpi.c > +++ b/xen/drivers/passthrough/amd/iommu_acpi.c > @@ -104,6 +104,10 @@ static void __init add_ivrs_mapping_entry( > > /* Assign IOMMU hardware. */ > ivrs_mappings[bdf].iommu = iommu; > + > + /* Requests using the alias go through the same IOMMU. */ > + if ( !ivrs_mappings[alias_id].iommu ) > + ivrs_mappings[alias_id].iommu = iommu; > } > > static struct amd_iommu * __init find_iommu_from_bdf_cap( From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:25:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:25:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461355.1672355 (Exim 4.92) (envelope-from ) id 1xLKi0-0004jT-Bb; Mon, 26 Oct 2026 13:25:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461355.1672355; Mon, 26 Oct 2026 13:25: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 1xLKi0-0004jL-7i; Mon, 26 Oct 2026 13:25:52 +0000 Received: by outflank-mailman (input) for mailman id 1461355; Mon, 26 Oct 2026 13:25:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLKhy-0004iW-8i for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:25:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLKhx-00DNay-KI for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:25:49 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf54d6-bab6-0a2a0a5309dd-0a2a450ae88c-30 for ; Mon, 26 Oct 2026 14:25:49 +0100 Received: from [52.101.69.96] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf54dd-f2d2-0a2a450a0019-346545601e59-3 for ; Mon, 26 Oct 2026 14:25:49 +0100 Received: from DB5PR03MB10049.eurprd03.prod.outlook.com (2603:10a6:10:4a0::9) by DB9PR03MB7212.eurprd03.prod.outlook.com (2603:10a6:10:228::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 13:25:47 +0000 Received: from DB5PR03MB10049.eurprd03.prod.outlook.com ([fe80::9240:92cd:d9da:bf9e]) by DB5PR03MB10049.eurprd03.prod.outlook.com ([fe80::9240:92cd:d9da:bf9e%7]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 13:25: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=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=dgf5hGDG2z9AWHJvv7+rkd3cxYkTwudQrWwJBy22gvCCXf6LkionpXEbw0XxutZ6QPUPvtPlDYf2y/yVfrD7464vQPupIK4QwHTONZ0MYNGmYToCQ0WG5UGPfUPFebb8g8ZYTqvT+FDAsFTBg/OB+PmLG9lEX25SydQ+CqLjb8T0DjJLfqXxDm83j9ZmpEXzJZcrsu4GeFEx0rUuYkT6uR466tW1Olx3HoVEbEqjtwtVQk/uBZnErv70ntqB5tQXsO7/ncObyny5bo9DduuPumMHHhlvTWzEfaD6+nSQi1/9RAF7WoyMUcEBCQi/UjwyPQ7Gt0ZGn/syANAI3oWIGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t+MYzgUOpIBvdKGtiejpP31vPoplzCjuNPQukK5VP10=; b=ZZMiLGz+mpnFgEVRjqZnXrYnv1bG9DpDwOnmefS5G1xFpo0mHBZiebHqi7z3uVej8F1CcIKCVrPrw4WjD2y/AA7uhMnukvXwe/KbvWuepQuec7/G6KLkjQ0bZvCxsNxopembeRODdCRH3zV5BTOoCU6wNidQQPQWkAT+wUpICJ2I+Y07wfq8wBygcuqhs04cYEpsZ1QejATEE5IGOVq3hBhPoe4tjDw4dHJ428RVN70uLmZbNpq5TyBntWGk/Nws/1SeRRtvF/IW9RNtSy8RTwUzmBesOby0HQ4Oc4H8An253ToqzR9MSwVr+BAuVz9sbiKswjdlNkiTs6wE0poW2g== 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=t+MYzgUOpIBvdKGtiejpP31vPoplzCjuNPQukK5VP10=; b=K5YCvv8rlyCXOb5vdsuilYtOy2Vjyhq/KKGHi3pCD4a6Qn49035dvL3vTpIivHVgne4ni6LkxvvM+7XQcjz5VbILWfQQCP+rgYGreIcyaFsPbYxo3ofGZSbzsGsWMC3yOAXy/CWc+SAiyAnyGc4Tw1KnYx0Nhnd6+xhyvQxIpqcXhk0NYUnuNiHAMBeZRayvq0AppFQpNDRAg9AwaF0mJfNKmQCjfk3PJotoWkHXNWjztgAH+Ol42T9DguZlXyvIMZDxkEE2WJae4LPPdQH1tl9Rur5lMfRt1nmpk6hKfGhHrNjCcKOgWIvUU+B6wbuWp3vQgdZDRzx0ts0oF8/pUw== From: Leonid Komarianskyi To: "xen-devel@lists.xenproject.org" CC: Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Leonid Komarianskyi Subject: [PATCH] xen/arm: smmuv3: invalidate TLB when freeing a VMID Thread-Topic: [PATCH] xen/arm: smmuv3: invalidate TLB when freeing a VMID Thread-Index: AQHdZU2CvV133olROUKhJSegs8l4mg== Date: Mon, 26 Oct 2026 13:25:47 +0000 Message-ID: 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: DB5PR03MB10049:EE_|DB9PR03MB7212:EE_ x-ms-office365-filtering-correlation-id: 905a10e2-a78e-46e9-2663-08df3364a56d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|261009223027099003|261022075727099003|261021121427099003|261021123027099003|261022105027099003|10067099003|56012099006|18002099003|5023799004|11063799006|38070700021; x-microsoft-antispam-message-info: MAqTaUepNbqGERSJsXaqedd+wF6ZhCbOCBAWtD77vfvhrCiRdzKkNA9R8KJhko/9GESZuqR7R6jjCaK88e0STaTGMUl/WtOHyjwiymjM/2HNb7ncAA1jmHPdRzPXT8PFY4pFAkP7yztGL5ICMh4AKqq2IlpqQVMrWj4+EC2MvQd6pG7NAIyN4eZCJ/jEWPZtzI9MVrCR9/VrBBXBdNrJ8eS30A5HcqnnNBcaILClAruFZpkBeDAfLYt2NYp3+rj5gVYHESMmBF3LCgsnSW2FGouBawiggyjfhFtCHmJizG3Saa8cy26Yn+tQQJXlZbC0j15yVUhm7CJgml+v0Q+YyUABwo5hEbJk+fMLzuzv0tFPSoLPVUKc/KBcmTwiT1uZUOC9SqFAarx0Ms6ywjgSlhHci5LtoCt8Rjo6RxjopaSZAnk/9240xp+t+gaBtoqOf1ubYw8czRSwN7dtjSt6m39mrdEgO1HP3GNGiRZ3zHmBIWlfxjbeutjA7eq1qfbSoIohzAEt2PBN/adTBMVJ6jnhmXatx8fVchCbIUn+p+IVpTaZyPInz4w5dCrUDPRjTJILxNt0VIyFOP5nQgq9/QGPzS6nChJjWtXsd7ExEojEYMGt3p3CBHo6DwoBvRE6OdQtR60rpwxlBgBWDjnXtviPAv3Y9UES8YX9cyX53V4sjeiluB+vbHylcmzP2rQcx18oVvEt51KgYSTD8BUVnvNIVPQ4HLA6/TC8kye4aJM= 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)(366016)(23010399003)(1800799024)(376014)(261009223027099003)(261022075727099003)(261021121427099003)(261021123027099003)(261022105027099003)(10067099003)(56012099006)(18002099003)(5023799004)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?XoiGtppzdq04TD1PcHcgS4gPIr4oZ8Hv2mSVNQ4A/jIApVHK2g/17yLnQK?= =?iso-8859-1?Q?TEp8sRrHde1KyC2rQDbXAtRAy0CrKw9OwSk3GOZxj5wy22PgCEMuG6qdls?= =?iso-8859-1?Q?b8RnLs2qPQUCxtcEOwRk5PE8O58mPEm5SCkmIUAQgumQ0bNCifn6K5Qiea?= =?iso-8859-1?Q?YDbMMD4z7oKBGp4l6z2qNPFGGg08gTrv5TqcmrZlZOgpzg/83t2f1Li3RJ?= =?iso-8859-1?Q?wwTJc8sXxd+SZXkvaU0ngJRfKVR/UL9kbeezolnt01DbOD1THQdecE0YEz?= =?iso-8859-1?Q?cfO3p+THFFSV9ADtKcmhL2T4tEc+bVTQ6bHXNUuolMdsbrYWh1IIOMBTg2?= =?iso-8859-1?Q?wfM9t5zQwzOZMHAjKLe6TSY/A4b4/U4kIau7td0AiR6atGKaK9D5GJ+jYZ?= =?iso-8859-1?Q?WBF1s/tn/v0SicRY1gQQ1TKws98B+G82VyS8exePovotxgJkLzuTxbIUp2?= =?iso-8859-1?Q?ggP+DFTTfB77rhzrlVqNH7q/c211byOKZ+SctsS9Urgp2d9Z/Mmt/RMFey?= =?iso-8859-1?Q?KdAt3tOdBR9cDKgTXnmdHECqRcTfCJx7BzqS8yeCSlut20wtIV6ro4IgE9?= =?iso-8859-1?Q?0FoNE2fWprpd+74ny0/wGRhQBeNQeJ8RfeDdcx7y8lQN8Bo8CoOXI/aL4p?= =?iso-8859-1?Q?k5SAYtlrqoMPhAR3HCYuDmRiBKbg64TxTX81lDxiqQrdFVBv+cCjJf95t/?= =?iso-8859-1?Q?r7OVD6lPOhUnINFxcHARD5fV0JIIlVlRaDAOuOWW9Obj3YuwAWl67CyUj6?= =?iso-8859-1?Q?7fIRYpgz3EoRqAt/5Ip59asD857kBeye8gI5pOTe8S/OmpPYAtUzbZ0Sid?= =?iso-8859-1?Q?42tIIbj6OPuWWdUCfrL3oScEi9X+odCX2WHe4sUSkf5C/620vTWVPtA3fe?= =?iso-8859-1?Q?SHcU/b/xo3+/3E3sPwHgc9fKSd9agkZvpEpWBpzV1jR5B52dcjdtAHBO6x?= =?iso-8859-1?Q?VS7sGqwvvHl9KwR6XCoEenwZtTqHR+boIxZ9Wa674BP6+eqpGnJUj2UuCg?= =?iso-8859-1?Q?RAXer5Dy1/TFDiaYnbp5OPkt7XPjZRLxv+I15vE9sHI7ChqSPLYHjb6u55?= =?iso-8859-1?Q?gdFLhEMPSmjNN2MYMcF638HV9zd4LtTc7Mu/o/cyC6NWUsFzUnGNy1ncs5?= =?iso-8859-1?Q?ye6id8WhvSC1Xnb/yaARfhOpOk3Q2iZ4Qb+53lRkEwXwEOKMSupWpXG/OB?= =?iso-8859-1?Q?gjA1+Q+F67MI0BiD1laKNk7EP+01LufclGk80g5xpnAeTbeBHotlbJSm6F?= =?iso-8859-1?Q?ivB/v7C3RJirZ7SxbiIhyr3xXmLpVqeYpIcLjOZONwEl67YPKSZpJ9uB0M?= =?iso-8859-1?Q?kGC5ezhXcrHpUW14ci+Pk46NyrJ80rqUYk75iHgPEflCc/mpcc/hPNKHSb?= =?iso-8859-1?Q?QXWPAxDEkjxrxul3zmWHNZfaImGYoNNTGgp6FKYKF0uvCHheWu+Dt5OqU1?= =?iso-8859-1?Q?HZKECMDcxj4nZHBbiHmNI9Y2UHYcq4HTudANxtP8sGjULQXvj0Lnyu/wDp?= =?iso-8859-1?Q?JAXRpIZE92yKJ4cHRQnVPpF+yxZ9yYeIHmsotFUGRE0C/f/J1jNoA3l5eq?= =?iso-8859-1?Q?OCblcX+rQhT0gv/5IFBWLWIPu+BFDATVymcyl5od8hNN4me3VEN9E7RUiu?= =?iso-8859-1?Q?HpZJ5Bj2gCYe6gPZ3/5HXfZ3ZYuBbGv3YDg59xIF0athZyKWuohX/4uNGn?= =?iso-8859-1?Q?q/7nDwO4pBlzLSdqnG8x/meTD0kcOkuKHnDUcogYJo6zgM/LHJNqYZW1vD?= =?iso-8859-1?Q?RumdPTrurYwPPQdREC9I4qMPKd9eBKssH39GljEh1piDygSpGH5wIYsqNm?= =?iso-8859-1?Q?t8uhbfDtF9Bjwp4OrxxjWwHf7Kvmbl4=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: DB5PR03MB10049.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 905a10e2-a78e-46e9-2663-08df3364a56d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 13:25:47.4927 (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: B6HtMPT4ml98pKsvRJuwU5WkWQzNELWBsmkbqcPOjbilj7zeMji6lzhPmnZbcD/kSfbCkt9DgnYh2EtAK7Rmk0d5/nCYq8p0flnpkx5iupg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7212 X-purgate-ID: tlsNG-4011c0/1793021149-58DC7CFC-2E9C5313/0/0 X-purgate-type: clean X-purgate-size: 2292 arm_smmu_domain_free() releases the VMID without invalidating the SMMU TLB entries tagged with it. The VMID allocator (arm_smmu_bitmap_alloc) always returns the first free VMID, so a new domain usually gets the same VMID as the domain that was just destroyed. As a result, DMA from a device assigned to the new domain can use stale TLB entries and access memory of the old domain, which may already be in use by Xen or by another domain. In Linux, this invalidation is done by free_io_pgtable_ops(), which calls the tlb_flush_all callback (arm_smmu_tlb_inv_context()) before the VMID is released. The call was dropped when the io-pgtable code was removed during the port to Xen, and nothing replaced it. Linux guests that modify their P2M early in boot (e.g. by mapping shared_info in the xen_guest_init initcall) hide the problem, because the resulting IOTLB flush clears the stale entries. However, guests without Xen support (e.g. Linux with CONFIG_XEN disabled) do not modify the P2M early in boot, so the device keeps using stale SMMU TLB entries. This was observed as GPU rendering corruption after "xl destroy" and "xl create" of the same guest with CONFIG_XEN disabled. To fix the problem, issue a TLB invalidation for the VMID before releasing it. Fixes: b3be6ffb009c ("xen/arm: smmuv3: Remove Linux specific code that is n= ot usable in XEN") Signed-off-by: Leonid Komarianskyi --- xen/drivers/passthrough/arm/smmu-v3.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthroug= h/arm/smmu-v3.c index bf153227dbd..93176e2fb21 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.c +++ b/xen/drivers/passthrough/arm/smmu-v3.c @@ -1153,8 +1153,14 @@ static void arm_smmu_domain_free(struct iommu_domain= *domain) struct arm_smmu_device *smmu =3D smmu_domain->smmu; struct arm_smmu_s2_cfg *cfg =3D &smmu_domain->s2_cfg; =20 - if (cfg->vmid) + if (cfg->vmid) { + /* + * Invalidate all entries tagged with this VMID + * before it can be handed to another domain. + */ + arm_smmu_tlb_inv_context(smmu_domain); arm_smmu_bitmap_free(smmu->vmid_map, cfg->vmid); + } =20 xfree(smmu_domain); } --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 13:58:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 13:58:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461392.1672391 (Exim 4.92) (envelope-from ) id 1xLLDp-0003Qu-AW; Mon, 26 Oct 2026 13:58:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461392.1672391; Mon, 26 Oct 2026 13:58: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 1xLLDp-0003Qn-86; Mon, 26 Oct 2026 13:58:45 +0000 Received: by outflank-mailman (input) for mailman id 1461392; Mon, 26 Oct 2026 13:58:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLLDo-0003Qh-Ba for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 13:58:44 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xLLDm-0000000EceM-48dn; Mon, 26 Oct 2026 13:58:42 +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.98.2) (envelope-from ) id 1xLLDm-00000008U2F-2W98; Mon, 26 Oct 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" 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=sxcw94eKA0wjnPTph24T5En/FWyWMxv+119D5gujHCA=; b=NwLd1yG+yVilD/Qcegee3boVrb kpP0/Kak4f+k+0Vc75LCPRXBWNj1ipeq5g+aoDp/ba/LrNBQu0h8a9Rw4At01in1UKu+MTlv66Cml lBlb1ChohZWkG7HM2mjC2n1+KDmNSQqY3sTi9oDn3iog4x+7WlSszzj8pwuvYmsTvb8g=; Date: Mon, 26 Oct 2026 14:58:24 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] xen/vcpu: ensure no write when runstate handler is NULL Message-ID: References: <20261023161742.67329-1-roger@xenproject.org> <47d6f426-6751-4a32-a187-2fb8a5347091@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <47d6f426-6751-4a32-a187-2fb8a5347091@suse.com> On Mon, Oct 26, 2026 at 02:06:48PM +0100, Jan Beulich wrote: > On 23.10.2026 18:17, Roger Pau Monne wrote: > > --- a/xen/arch/x86/x86_64/domain.c > > +++ b/xen/arch/x86/x86_64/domain.c > > @@ -58,6 +58,11 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > > rc = 0; > > guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); > > > > + /* NULL handle is deregistering the address. */ > > + if ( compat_handle_is_null(area.addr.h) ) > > + break; > > + > > + /* Update the newly-registered runstate area, best-effort. */ > > if ( v == current ) > > { > > XLAT_vcpu_runstate_info(&info, &v->runstate); > > While likely unnecessary in this x86-only handling, ... > > > --- a/xen/common/domain.c > > +++ b/xen/common/domain.c > > @@ -2330,6 +2330,11 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > > rc = 0; > > runstate_guest(v) = area.addr.h; > > > > + /* NULL handle is deregistering the address. */ > > + if ( guest_handle_is_null(area.addr.h) ) > > + break; > > + > > + /* Update the newly-registered runstate area, best-effort. */ > > if ( v == current ) > > { > > __copy_to_guest(runstate_guest(v), &v->runstate, 1); > > ... if we make null an official "de-register", then imo the earlier > guest_handle_okay() also wants bypassing in the null case. An arch > could - in principle - reject a null handle. Yes, it could en theory be possible, albeit I think it's very unlikely we gain anything similar to x86 PV elsewhere. Would you be OK with: diff --git a/xen/common/domain.c b/xen/common/domain.c index 6b52713518da..b41be89cd0b9 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -2324,12 +2324,21 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) if ( copy_from_guest(&area, arg, 1) ) break; + /* NULL handle is deregistering the address. */ + if ( guest_handle_is_null(area.addr.h) ) + { + runstate_guest(v) = area.addr.h; + rc = 0; + break; + } + if ( !guest_handle_okay(area.addr.h, 1) ) break; rc = 0; runstate_guest(v) = area.addr.h; + /* Update the newly-registered runstate area, best-effort. */ if ( v == current ) { __copy_to_guest(runstate_guest(v), &v->runstate, 1); Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:04:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:04:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461399.1672400 (Exim 4.92) (envelope-from ) id 1xLLJ9-0005Dv-TS; Mon, 26 Oct 2026 14:04:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461399.1672400; Mon, 26 Oct 2026 14:04: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 1xLLJ9-0005Do-Qf; Mon, 26 Oct 2026 14:04:15 +0000 Received: by outflank-mailman (input) for mailman id 1461399; Mon, 26 Oct 2026 14:04:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLLJ8-0005Di-J9 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:04:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLLJ7-00DUjC-5v for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:04:13 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf5ddc-2eae-0a2a0a5409dd-0a2a4502ec76-2 for ; Mon, 26 Oct 2026 15:04:12 +0100 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 6adf5ddc-6ca4-0a2a45020019-b9ff1c129969-3 for ; Mon, 26 Oct 2026 15:04:12 +0100 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 1a178869cb4000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 14:04:10 +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 740E7821B9; Mon, 26 Oct 2026 15:04:09 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=WGhq4g4rSrDWDVfqAZMue0dtY75qGL7ROykWVYh7cCA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=plLT6Eg50HSoBCoM6GemAkMaBp9T2crMlYGxTzkaYH6FgeS/DAPA5p0JcwgbrfDRDegh6t0fw DaBlBphIdkTt/5hKrI6DeqmoPnmFY7F2CW6lx9vL7ww1c7wGU+mEyns6JuvBuRf9Osc6Ev+1z8n re39/2eephJg3KnHhF7gelXpZlSDHL52q9ozK6kLbrNORW4qSqSjcMR8aN2ej4ZRT7I0S89rPnp uh5Mee9wtjpwVXCrrHfL9sKIYQxlWsgoqIk8V82Exj8YNPrg5qoVHeL4U0Jj5+uDzc+M1M3A2wi GtBUd89DaVC8hv3sT5vLwPR4fQTfENa7eRry7QOUw62w== X-Zone-Loop: 1a784bf09fc48d749180fc623575353443dd217353e4 x-campaign-type: default x-transaction-id: 681b8edf-8b9f-44ee-a907-4df23e0212a2 x-swg-uid: 01-8bcdb3c5-2372-4b11-a5cf-7788ffb469c2 X-Mailer: Sweego Message-ID: <1793023450.8631fc262581453bbf619ec5b2062170.1a178869cb4000f79f@vates.tech> x-swg-bid: 1793023450.8631fc262581453bbf619ec5b2062170.1a178869cb4000f79f 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] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write Date: Mon, 26 Oct 2026 15:03:35 +0100 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.1f7.52f58276526bd76a.1a178869a09.d31f7ca2ca9038a6=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793023449615 X-purgate-ID: tlsNG-720697/1793023452-F22A92AC-C08B0402/0/0 X-purgate-type: clean X-purgate-size: 2959 ---=Part.1f7.52f58276526bd76a.1a178869a09.d31f7ca2ca9038a6=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The Intel SDM (Vol 3A-13=2E12=2E11, June 2026) says > The semantics of sending a self-IPI via the SELF IPI register > are identical to sending a self targeted edge triggered fixed > interrupt with the specified vector=2E However, this doesn't require altering the ICR register=2E On most Intel processors (at least Core/P-Core), it does alter ICR, but it's not the case on AMD and Atom/E-Core ones, and APICv Self-IPI appears to follow a similar behavior=2E For consistency, adjust the Xen behavior to send the Self-IPI directly instead of emulating it by modifying ICR register=2E It also clarify the logic=2E Assisted-by: Claude Fable 5=2E1 Signed-off-by: Teddy Astie --- I haven't check if APICv Self-IPI doesn't alter the ICR, this is mostly based on what suggest Andrew's comment [1]=2E Intel SDM doesn't actually tell much if ICR is modified by APICv Self-IPI but behavior pseudo-code suggest that ICR is not considered at all, hence Self-IPI is done differently=2E [1] https://lore=2Ekernel=2Eorg/xen-devel/b236e564-c2fd-44d1-93ee-8bb87e2e= 2c0f@citrix=2Ecom/ v2: - adjust commit message, drop Fixes - drop vlapic_self_ipi() function - reorganize vlapic_apicv_write() --- xen/arch/x86/hvm/vlapic=2Ec | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/hvm/vlapic=2Ec b/xen/arch/x86/hvm/vlapic=2Ec index 885f5d304b=2E=2E7d6b1a6e0d 100644 --- a/xen/arch/x86/hvm/vlapic=2Ec +++ b/xen/arch/x86/hvm/vlapic=2Ec @@ -970,11 +970,13 @@ int vlapic_apicv_write(struct vcpu *v, unsigned int = offset) =20 if ( vlapic_x2apic_mode(vlapic) ) { - if ( offset !=3D APIC_SELF_IPI ) - return X86EMUL_UNHANDLEABLE; + if ( offset =3D=3D APIC_SELF_IPI ) + { + vlapic_ipi(vlapic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK),= 0); + return X86EMUL_OKAY; + } =20 - offset =3D APIC_ICR; - val =3D APIC_DEST_SELF | (val & APIC_VECTOR_MASK); + return X86EMUL_UNHANDLEABLE; } =20 vlapic_reg_write(v, offset, val); @@ -1050,9 +1052,8 @@ int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr,= uint64_t val) case APIC_SELF_IPI: if ( val & ~APIC_VECTOR_MASK ) return X86EMUL_EXCEPTION; - offset =3D APIC_ICR; - val =3D APIC_DEST_SELF | (val & APIC_VECTOR_MASK); - break; + vlapic_ipi(vlapic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK), 0); + return X86EMUL_OKAY; =20 case APIC_EOI: case APIC_ESR: --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.1f7.52f58276526bd76a.1a178869a09.d31f7ca2ca9038a6=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:05:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:05:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461405.1672411 (Exim 4.92) (envelope-from ) id 1xLLK2-0005i3-7n; Mon, 26 Oct 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 1461405.1672411; Mon, 26 Oct 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 1xLLK2-0005hv-2i; Mon, 26 Oct 2026 14:05:10 +0000 Received: by outflank-mailman (input) for mailman id 1461405; Mon, 26 Oct 2026 14:05:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLLK0-0005fW-P6 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:05:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLLK0-005wRu-62 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:05:08 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf5e0c-8faa-0a2a0a5109dd-0a2a450484c8-18 for ; Mon, 26 Oct 2026 15:05:08 +0100 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 6adf5e13-b57f-0a2a45040019-d1558029b4d4-3 for ; Mon, 26 Oct 2026 15:05:08 +0100 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a4dc547987so6009905e9.0 for ; Mon, 26 Oct 2026 07:05: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-4a35a0a476bsm136413335e9.3.2026.10.26.07.05.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 07:05: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=1793023507; x=1793628307; 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=S/QgXP0DzeKLRuvqaHQS5LxEJxYqR60Yay7rdZ3OGD0=; b=Msgd/ljaNTiGIqOU1M60sZ27ayR8m17H7JnHj1q6n7Qqa78KSQSbKGUelkgMSUs/xs i47tdZdhZz2S2M4da7PRiRf4GF5Q+edpb5cBQzWcDNJU70I1KswODRdLjGlTrQiPkGOa 6B9JRW8V1VBMFbwQ0Z22OnOzIQwhlgkd8y3G7LAMADMn8iHAsFouMET4ENFlU41p9ocT Nur4VepSgeU0L1lkFOlcT4Ga2Yb8eKs+71TjndJ7OwG70ShBO3qVKZLT4mXleY6oimP9 xgTyrdrXXNzousdRtGeZ3Gp0jT+4cI1ZGkzFodb5DlTzEC4VANAPnXpUbrVul8uc5ivs Zi/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793023507; x=1793628307; 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=S/QgXP0DzeKLRuvqaHQS5LxEJxYqR60Yay7rdZ3OGD0=; b=BsY/F57BplQwH9HVekEQEhRuh17aTxhogzMKSQC9spzsDOcD1lUSkV1e8Y9AOmm68a gQgC1By6ok1L7GInUsm4lTFv6I9g8eIHEcspTpyjBQVPmeBTZnXroPlWhr13vxeST91h DVfC3W2aiBQ3oiJ9xlyQaVDWW7J446KumKwtEzKcDbb65fuO4peFXSbDbVl8pqVuEFYQ wtmhcKW+5rNw+QM8e+1XCX44gD9dd04jJYkD+bcp2UIcdYw1xxn5SyJ08/sP2LmCiLHj rbrPCVdRgJU863i3VbN/1KwCBUAETNt6cC1xXPlNf7nnid9p6cCBnx365FMrkR5gUlqi zHUw== X-Forwarded-Encrypted: i=1; AKwUvBzIcxuYIO/tUGskpSIdJ+dnq+5U9+fL3yL4uZuQmvDJRuFuC7EejFpyip3GB36DetpJ18w8WRVUMm0=@lists.xenproject.org X-Gm-Message-State: AFq9FYItw/BOiHi0jufHK0n1IYU0HPv7699tDyrEGy6fkWSeok6OR38J m/R+xnGovEDNazBbT35VXb862suHvkfcNErhGCYNexsMywcuVD2Z6puIjHSGaGTZCA== X-Gm-Gg: AYBFou1FbRZtoz+WRv/ZZMlaprW0MujJVcRsPFlC+DtwQa3IxvrWB5kQw8EI0OvYQsL eqa7t+EGPghKLLCJrC6KtkRCaHIwYpuW6/TVbkJFMQsrVjd2z9hhQliEfdlYutMZiVu/Xe62EkW kLQuerAMJFhp4OKI6lSq+GwvzaIPf2E5jGO9KTksmw1V7pJFoRl4YTc7fB4qQz581qTjitGDziz Yzo5k3DT1BE/vLjSQ7JcbPyqNzCEgs9r4hv4XgQsLNnPaFRERIgQS0cgIDIpIHxuD4BT5LXM14w XTwGfqO6wUGbgEhmbusfKvg7wCreXrvOqWrc7bN7v0KcGCxLJIlyprbdu8V16s5HA7hJddKrdpU KfE2j2gpK7vNQt0eA4Ha5Pp3ba9XDCtUeWK6Y80QtHseCcCuhY9Wm05fIVkAU4gfEcFjnRCeyYs Xu0llV824b0+e7VTjE6GceNBu2fGgwigY1NF4cvAyoP0mxsHav3saoQ+EA+WULoJKcBJVw0knP/ gNum8+karPRvhnf77Qqm7zM37hIsv3RrvN1xziWdEu6NSoZZSOHIIvCqx/OyFR3UEiwk48sbyFd p4F+ooyvaBECFEwL/HBrlkvFoQijT3omfZ+LhqOVRHA= X-Received: by 2002:a05:600c:c056:b0:4a4:4d57:8462 with SMTP id 5b1f17b1804b1-4a44d578602mr82347305e9.24.1793023507391; Mon, 26 Oct 2026 07:05:07 -0700 (PDT) Message-ID: <535e56a1-c9ad-4866-ac11-ebf9fe0115bc@suse.com> Date: Mon, 26 Oct 2026 15:05:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/vcpu: ensure no write when runstate handler is NULL To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261023161742.67329-1-roger@xenproject.org> <47d6f426-6751-4a32-a187-2fb8a5347091@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-ebf023/1793023508-524CBB50-8EEB535D/10/78276251493 X-purgate-type: spam X-purgate-size: 2725 On 26.10.2026 14:58, Roger Pau Monné wrote: > On Mon, Oct 26, 2026 at 02:06:48PM +0100, Jan Beulich wrote: >> On 23.10.2026 18:17, Roger Pau Monne wrote: >>> --- a/xen/arch/x86/x86_64/domain.c >>> +++ b/xen/arch/x86/x86_64/domain.c >>> @@ -58,6 +58,11 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) >>> rc = 0; >>> guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); >>> >>> + /* NULL handle is deregistering the address. */ >>> + if ( compat_handle_is_null(area.addr.h) ) >>> + break; >>> + >>> + /* Update the newly-registered runstate area, best-effort. */ >>> if ( v == current ) >>> { >>> XLAT_vcpu_runstate_info(&info, &v->runstate); >> >> While likely unnecessary in this x86-only handling, ... >> >>> --- a/xen/common/domain.c >>> +++ b/xen/common/domain.c >>> @@ -2330,6 +2330,11 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) >>> rc = 0; >>> runstate_guest(v) = area.addr.h; >>> >>> + /* NULL handle is deregistering the address. */ >>> + if ( guest_handle_is_null(area.addr.h) ) >>> + break; >>> + >>> + /* Update the newly-registered runstate area, best-effort. */ >>> if ( v == current ) >>> { >>> __copy_to_guest(runstate_guest(v), &v->runstate, 1); >> >> ... if we make null an official "de-register", then imo the earlier >> guest_handle_okay() also wants bypassing in the null case. An arch >> could - in principle - reject a null handle. > > Yes, it could en theory be possible, albeit I think it's very unlikely > we gain anything similar to x86 PV elsewhere. Would you be OK with: Yes, this is fine with me: Reviewed-by: Jan Beulich Jan > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -2324,12 +2324,21 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > if ( copy_from_guest(&area, arg, 1) ) > break; > > + /* NULL handle is deregistering the address. */ > + if ( guest_handle_is_null(area.addr.h) ) > + { > + runstate_guest(v) = area.addr.h; > + rc = 0; > + break; > + } > + > if ( !guest_handle_okay(area.addr.h, 1) ) > break; > > rc = 0; > runstate_guest(v) = area.addr.h; > > + /* Update the newly-registered runstate area, best-effort. */ > if ( v == current ) > { > __copy_to_guest(runstate_guest(v), &v->runstate, 1); > > Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:06:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:06:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461412.1672419 (Exim 4.92) (envelope-from ) id 1xLLLY-0006GZ-Fj; Mon, 26 Oct 2026 14:06:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461412.1672419; Mon, 26 Oct 2026 14:06: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 1xLLLY-0006GS-D3; Mon, 26 Oct 2026 14:06:44 +0000 Received: by outflank-mailman (input) for mailman id 1461412; Mon, 26 Oct 2026 14:06:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLLLW-0006GM-Ov for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:06:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLLLW-000c5A-5V for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:06:42 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf5e71-e002-0a2a0a5209dd-0a2a450be02a-4 for ; Mon, 26 Oct 2026 15:06:42 +0100 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 6adf5e71-b7e8-0a2a450b0019-b9ff1c12a95f-3 for ; Mon, 26 Oct 2026 15:06:42 +0100 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 1a17888e252000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 14:06:39 +0000 Received: from [192.168.1.52] (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 5500982EC5; Mon, 26 Oct 2026 15:06:38 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=djw2QxPds94pGLugen6+El3ECWShTp8nUm5eIsTN8/4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=AdGqESOlKnjJrDXEiRb7GJWB6D3XTs12bHKr5RVjKZ2utnUNhWdK/v8JJrIyJ6+rhkfSSwhaa XIZIpjdtZ8TDOaUaXnSi6N9tMoIIW8gOQ8scMQ3+ys4LXfodrtdmztS24aM/8k5bb2PeKXMGqFI B5kReBQTvRyjVvdEYiM/+sUKkAsy0T6HjBEwS5mHP0qCbrMCIBKFjoiziSmA0kHCn1BR0wYNqHz MyPxTLyjWPEFXQPwPTa7j0mxKth2N0hWb4P7LS0tLW6WrGY0clyGLYrrzODUqnN6FKAf+0E9ZhT 1KfEpCC3ZIHtMLr+tac1ONMD4/LoMjeI4u+TCEtN4ApQ== X-Zone-Loop: 443a7e1da17fe878ed71ad2153ebae0473ca668f1620 x-campaign-type: default x-transaction-id: e0ba788d-5ff4-4b3e-9ae2-69e890530320 x-swg-uid: 01-42c11d37-ede3-4281-bb04-111bbc591ecf X-Mailer: Sweego Message-ID: <1793023599.8631fc262581453bbf619ec5b2062170.1a17888e252000f79f@vates.tech> x-swg-bid: 1793023599.8631fc262581453bbf619ec5b2062170.1a17888e252000f79f 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 v3 31/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: <45011daea86267b8f4b707bc7de6357b0712fb08.1790779209.git.oleksii.kurochko@gmail.com> References: <45011daea86267b8f4b707bc7de6357b0712fb08.1790779209.git.oleksii.kurochko@gmail.com> Date: Mon, 26 Oct 2026 15:06:29 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793023593; l=3944; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=viqPS50PsFoz/TkblGzIMI54ljn0gloQUKzoXBVka3c=; b=Sp+u2rPvy7J5VqE/tF3imPcnwhnGayedeMzC8yUVnLSqb3Ol21wwX7PFnrReYYkuq2u0q7KjT e0mzpOVwzGQB8UiFf3qIVBsDiXzw/exETyGybwDOTSHDJqphiCoUbpI 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: 1793023598552 X-purgate-ID: tlsNG-42698a/1793023602-A94C39EA-5AB75359/0/0 X-purgate-type: clean X-purgate-size: 3944 > Once the new IMSIC VS-file has been zeroed out, it has to be mapped into > the guest's G-stage in place of the old one. 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. > > Taking a h/w guest interrupt file (assigning it, zeroing it out, mapping > it into G-stage and recording it in the vCPU's IMSIC state) is factored > out into imsic_vsfile_acquire(). > > The relevant translation tables at all IOMMUs would also have to be > updated so that MSIs for this virtual interrupt file are sent to the new > physical interrupt file, but that is skipped for now as there is no IOMMU > support for RISC-V. > > Synchronize with the APLIC to ensure that no straggler MSIs will arrive at > the old interrupt file by running imsic_aplic_sync() on the pCPU which owns > that file. > > If the new file can't be mapped into the guest, release the guest > external interrupt number imsic_vsfile_acquire() took for it instead of > leaking it. vgein_release() takes the pCPU explicitly instead of relying > on v->processor, as on migration v->processor already refers to the new > pCPU while the number to be released may belong to the old one. > > 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. > > Implement imsic_update_state(), which records the vCPU's guest > interrupt file id together with the pCPU owning the file. The two are > read as a pair, e.g. by imsic_migrate_vcpu() and the IMSIC context > switch hooks, so they are updated under vsfile_lock as a single unit. > > imsic_map_guest_file() and vgein_release() are stubs for now. I have the feeling this patch does more than its subject says: besides retargeting the APLIC and adding the sync, it introduces imsic_vsfile_acquire() (assign + clear + G-stage map + state update), imsic_update_state() and the error path, which relies on two stubs, imsic_map_guest_file() and vgein_release(). At this point vgein_assign() is still BUG_ON("unimplemented") too, so none of the new code can actually run, and the error path can't be reviewed against the real vgein_release(). Also, until "introduce IMSIC h/w interrupt file attaching to vcpu", no vCPU ever owns a h/w file, so imsic_migrate_vcpu() can only hit the CPU_NONE check. Wouldn't it be simpler to move the two already-acked patches and the attach first, so that no stubs are needed and each migration step is written against its real callees when it lands: - Add basic VGEIN management for AIA guests (real vgein_assign() and vgein_release(); the reason for the explicit cpu argument of vgein_release() would then have to go into this commit message) - Map IMSIC interrupt file for vCPUs (real imsic_map_guest_file()) - Implement continue_new_vcpu() and set hstatus.VSXL - Attach a h/w interrupt file to a vCPU on its first run, introducing imsic_vsfile_acquire() and imsic_update_state() with their first user (acquire, vaplic_reconfigure_target(), set hstatus.VGEIN) - Prepare new IMSIC VS-file (on top of imsic_vsfile_acquire()) - Implement APLIC-IMSIC-hart sync barrier for vCPU migration - Remap interrupts to the new IMSIC VS-file (APLIC retarget + sync) - Save/clear old VS-file, restore, SGEI wake-up as today A side benefit: attach no longer has to be squeezed into the finished migration code, so imsic_vsfile_move() with its first_attach argument and the goto set_vgein go away. Attach stays a plain sequence, and imsic_migrate_vcpu() simply reuses imsic_vsfile_acquire(). Migrating a vCPU which has already run would still hit the trailing BUG_ON("unimplemented") until the restore patch, but that is no worse than the panic() it hits today. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:18:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:18:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461421.1672428 (Exim 4.92) (envelope-from ) id 1xLLX1-0000Qq-KM; Mon, 26 Oct 2026 14:18:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461421.1672428; Mon, 26 Oct 2026 14: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 1xLLX1-0000Qj-Hj; Mon, 26 Oct 2026 14:18:35 +0000 Received: by outflank-mailman (input) for mailman id 1461421; Mon, 26 Oct 2026 14:18:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLLX0-0000Qd-FG for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:18:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLLWz-00EI2D-BJ for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:18:33 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6132-e002-0a2a0a5209dd-0a2a450a8c42-12 for ; Mon, 26 Oct 2026 15:18:33 +0100 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 6adf6138-f2d2-0a2a450a0019-b9ff1c12b335-3 for ; Mon, 26 Oct 2026 15:18:33 +0100 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 1a17893baae000f79f.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 14:18:29 +0000 Received: from [192.168.0.158] (cpc92322-cmbg19-2-0-cust1759.5-4.cable.virginm.net [86.26.38.224]) (Authenticated sender: andriy.sultanov) by mail2.vates.fr (Postfix) with ESMTPSA id F320282DF1; Mon, 26 Oct 2026 15:18:28 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=2G9amNGzEGj9H/n3Fwm1IC8Oq+GlWmiIYg8/y4uJpeU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=I3dYMxkYTfSKZ4t38QTtxpLm95qLdOFZAxr8grMa2wsqjyKWAIbPxQiaFwyvG5X3rIbVjVlZp CdixKWpLfUg3vVDWeDfOnFqwHPft6enNKqCNVVQRRYf3y6Bxp7i2yJQ60sWdovdtYd7axZX9qGp /lAOmYhSkI8HOxJGyaY1ZGR0XeBAcYe7xhNx7lOM61HWWRzrqDSjxDcXdzVf9lkYoKu3vhF2y+z OZu7uuRtcRrdIY3wdfwwyBMi1zj48NFMlgEtWEhbfJmuLDR+pZ1QjwuTqRryeZuaHFekGcBA7SL aTkItYXSlHhY7rFcWQ0Yv+jieYkiLSzyNl6eQdd2tK0g== X-Zone-Loop: 3d0d07d9f5ed8f56d38dbc10239c8cc406ceea75d25b x-campaign-type: default x-transaction-id: 56ff71c1-8b76-4e76-994e-f9fcb2de2e95 x-swg-uid: 01-111e260b-8b58-4aeb-85bd-49678707e836 X-Mailer: Sweego Message-ID: <1793024310.8631fc262581453bbf619ec5b2062170.1a17893baae000f79f@vates.tech> x-swg-bid: 1793024310.8631fc262581453bbf619ec5b2062170.1a17893baae000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 26 Oct 2026 14:18:28 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tools/ocaml/libs/xs: Create FDs with the correct CLOEXEC status To: Andrew Cooper , Xen-devel Cc: Guillaume Thouvenin , Andrew Mbugua References: <20261012201857.714448-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Andrii Sultanov In-Reply-To: <20261012201857.714448-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793024309177 X-purgate-ID: tlsNG-4011c0/1793024313-528DDCFC-43245F50/0/0 X-purgate-type: clean X-purgate-size: 2285 On 10/12/26 21:19, Andrew Cooper wrote: > ... rather than editing them after the fact. > > This capability exists from Ocaml 4.05 which is also our minimum supported > version. > > Signed-off-by: Andrew Cooper > --- > CC: Andrii Sultanov > CC: Guillaume Thouvenin > > Found while reviewing the other FD handling patch. > --- > tools/ocaml/libs/xs/xs.ml | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml > index addccc80099b..a088d67a8cb6 100644 > --- a/tools/ocaml/libs/xs/xs.ml > +++ b/tools/ocaml/libs/xs/xs.ml > @@ -155,9 +155,8 @@ exception Failed_to_connect > let daemon_open () = > try > let sockaddr = Unix.ADDR_UNIX(daemon_socket) in > - let sock = Unix.socket Unix.PF_UNIX Unix.SOCK_STREAM 0 in > + let sock = Unix.socket ~cloexec:true Unix.PF_UNIX Unix.SOCK_STREAM 0 in > Unix.connect sock sockaddr; > - Unix.set_close_on_exec sock; > make sock > with _ -> raise Failed_to_connect > > @@ -169,8 +168,7 @@ let domain_open () = > with Unix.Unix_error(_, _, _) -> > "/proc/xen/xenbus" in > > - let fd = Unix.openfile path [ Unix.O_RDWR ] 0o550 in > - Unix.set_close_on_exec fd; > + let fd = Unix.openfile path [ Unix.O_RDWR; Unix.O_CLOEXEC ] 0o550 in > make fd > > let close xsh = Xsraw.close xsh.con > > base-commit: 0d3bb3c98bc99ec1c84ebb3df71b6e18daebff4f The change on its own is fine - there's no functional impact. But as far as I can tell, these functions are not used anywhere (they haven't been used in xapi in a long time), so there's limited utility in this cleanup. Regarding your question from the original thread, if this patch was intended as an answer to it: > Where do these sockets come from?  What flags where they opened with? The sockets that are dumped come from xenstored.ml:process_special_fds:       let (cfd, _addr) = Unix.accept fd in The default is keep-on-exec, so there shouldn't be any need to call Unix.clear_close_on_exec in the patches suggested by Andrew Mbugua. Acked-by: Andrii Sultanov From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:27:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:27:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461430.1672437 (Exim 4.92) (envelope-from ) id 1xLLfK-0002aU-CU; Mon, 26 Oct 2026 14:27:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461430.1672437; Mon, 26 Oct 2026 14:27: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 1xLLfK-0002aN-9w; Mon, 26 Oct 2026 14:27:10 +0000 Received: by outflank-mailman (input) for mailman id 1461430; Mon, 26 Oct 2026 14:27:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLLfJ-0002aH-4u for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:27:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLLfI-003Tx6-8y for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:27:08 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6336-2eae-0a2a0a5409dd-0a2a45019c3a-26 for ; Mon, 26 Oct 2026 15:27:08 +0100 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 6adf633b-5984-0a2a45010019-b9ff1c238c99-3 for ; Mon, 26 Oct 2026 15:27:08 +0100 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 1a1789b9cee000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 14:27:06 +0000 Received: from [192.168.0.158] (cpc92322-cmbg19-2-0-cust1759.5-4.cable.virginm.net [86.26.38.224]) (Authenticated sender: andriy.sultanov) by mail2.vates.fr (Postfix) with ESMTPSA id 9AAE0815DF; Mon, 26 Oct 2026 15:27:05 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=nG5rk/XCmLLCdy72Z2Rxc8o8MJJTUEimEtqQOHP1kl4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=e0P5exl/rOhMjPFOHKPSbIUaI89mHW8+f21nEFYosL7yyRBAuglp/xoWg5CuMX/4wuJLfUaYW 9uz4vRVEmm3dlKTZUxNGuiAM2w1S62ngQVemUqquLfmw+2ZJAbHCWVN/qseeK2pKuA1KC5LtpAJ fp1BC1+KiMie7qnRM2TXx93bfQ1bjSfatyteyAF8UD0No7BP3VS12jhEeFEsq6vptSQqCopHZ4F mqpf3EUuNPj5E04EQXQNcZwSzhnXA3Vanv+y9N+tbDKiPqvMp71hr3OCJboj+kbTNZTZLLEdQn7 wNkE/HFrtDg9+iOQ8TfJkKVp0oFDJezxceI3gDHS7Yrg== X-Zone-Loop: de4719b29853a81784b2b3c27fdb095bded3d3337d60 x-campaign-type: default x-transaction-id: 751cd7c4-e334-4ce3-8d86-fd199ba56c2c x-swg-uid: 01-b668e449-76e8-4764-94a6-ef0753998cf8 X-Mailer: Sweego Message-ID: <1793024826.8631fc262581453bbf619ec5b2062170.1a1789b9cee000f79f@vates.tech> x-swg-bid: 1793024826.8631fc262581453bbf619ec5b2062170.1a1789b9cee000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 26 Oct 2026 14:27:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] tools/ocaml: bindings needed to build ARM domains To: Andrew Cooper , Julian Vetter , xen-devel@lists.xenproject.org Cc: Guillaume Thouvenin , Anthony PERARD References: <1792679039.8631fc262581453bbf619ec5b2062170.1a163ff5306000f79f@vates.tech> <9019a85e-c121-4d21-95fb-078765e0c3d8@citrix.com> Content-Language: en-US From: Andrii Sultanov In-Reply-To: <9019a85e-c121-4d21-95fb-078765e0c3d8@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793024825853 X-purgate-ID: tlsNG-d62444/1793024828-1DC79757-02AFC2B0/0/0 X-purgate-type: clean X-purgate-size: 876 On 10/22/26 21:57, Andrew Cooper wrote: > But, I think now is about the right time to put this in as a real test > to run in CI.  What I did was a gross hack, but in principle all we need > to do is install it into $(DESTDIR)$(LIBEXEC)/tests and it should get > picked up and run automatically in Gitlab CI. > > What I can't find is anything which can truly pretty-print an Ocaml > object without some external structural definition.  To test the > bindings, we need to reference every part of them in Ocaml code (and > have it not crash), to confirm that we built the correct structure in C. There's no nice generic way to do this, I'm afraid. It's a common complaint... It can technically be done with PPX-es (e.g. https://github.com/ocaml-ppx/ppx_deriving#plugin-show), but it's going to be fairly painful to integrate this into Xen given our reqs. From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:48:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:48:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461442.1672449 (Exim 4.92) (envelope-from ) id 1xLM0F-000740-2B; Mon, 26 Oct 2026 14:48:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461442.1672449; Mon, 26 Oct 2026 14:48: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 1xLM0E-00073t-Vo; Mon, 26 Oct 2026 14:48:46 +0000 Received: by outflank-mailman (input) for mailman id 1461442; Mon, 26 Oct 2026 14:48:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLM0C-00073n-LH for xen-devel@lists.xen.org; Mon, 26 Oct 2026 14:48:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLM0B-0065Za-ME for xen-devel@lists.xen.org; Mon, 26 Oct 2026 15:48:43 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6846-e002-0a2a0a5209dd-0a2a4507ed84-22 for ; Mon, 26 Oct 2026 15:48:43 +0100 Received: from [136.243.217.222] (helo=mail.cortex-media.de) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf684b-b4ea-0a2a45070019-88f3d9deb668-3 for ; Mon, 26 Oct 2026 15:48:43 +0100 Received: by mail.cortex-media.de (Postfix) id 21D7838C02F; Mon, 26 Oct 2026 15:48:42 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20250930 header.d=cortex-media.de header.i="@cortex-media.de" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cortex-media.de; s=20250930; t=1793026123; bh=9x1YqTvOf8CN380pGUIOysGSQJKE8dA8qzqMb1mNDME=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=kN+4z15I5D0acYTxmpmmWd/ENm4spU8+1ES4MvL7bQySEEqkPx2PqL430KeK8viC2 On23cql3WRq5eDOY/ie1aJCePy3g7n9MfVBsKBp8IxZEo+gbqKVlkPtj8QdT6l5NkY ZCm92F024Yk+g51wQP4qm4E5v/bm5Dm4DcgfnreZ3m2P1XuYCS6Mmt3LyQ2FZozyPb MfvrPZjmcK5bQLs30xNbwYf9HMUe1s9yKq0VjcEG94fcomxPFd8mdvtlj/D4cscXPW Jj5FxX1izDbO3a3SI2O97UhnFWyHXrvx35Dp8M3o2DI4cM36I2LjdS7S6bKvB8TG86 kXJdU3k0QQj3w== Message-ID: <8138ed44-727f-45bc-9673-9684e922595b@cortex-media.de> Date: Mon, 26 Oct 2026 15:48:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Soham Dandapat , Andrew Cooper , xen-devel@lists.xen.org References: From: Peter Deggendorfer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793026123-370DDAE4-07F399A8/0/0 X-purgate-type: clean X-purgate-size: 10091 Am 26.10.2026 um 11:53 schrieb Jan Beulich: > On 25.10.2026 13:32, Peter Deggendorfer wrote: >>> Hi Andrew, >>> >>> Thanks a lot for the quick response. >>> >>> >>>> On 23/10/2026 8:32 am, Peter Deggendorfer wrote: >>>>> Hey Xen Team, >>>>> >>>>> I'm hitting a reproducible hypervisor panic in the AMD non-fatal MCE >>>>> polling path on a Ryzen 9 5950X (Zen 3). Eight occurrences since >>>>> 2026-09-09, between 12 hours and 2 weeks apart, always CPU 2. >>>>> >>>>> Environment >>>>> ----------- >>>>> Xen:   4.20.4-pre (Debian 4.20.3+127-gc42374a105-0+deb13u1), and still >>>>>         present in 4.20.5-pre (Debian 4.20.4+39-gf1e1321c87-0+deb13u1) >>>>> dom0:  Linux 6.12.111+deb13-amd64 (Debian trixie), PV, 32 vCPUs >>>>> CPU:   AMD Family 25 (0x19) Model 33 (0x21) Stepping 2, Ryzen 9 5950X, >>>>>         microcode 0x0a201210 >>>>> Cmdline: dom0_mem=4096M,max:4096M ucode=scan console_timestamps=datems >>>>> >>>>> The panic >>>>> --------- >>>>> (XEN) [2026-10-19 08:58:18.727] Xen BUG at >>>>> arch/x86/cpu/mcheck/mce_amd.c:100 >>>>> (XEN) CPU:    2 >>>>> (XEN) RIP:    e008:[] >>>>> mce_amd.c#mc_ec2type.part.0+0/0x10 >>>>> (XEN) rbx: 0000000000000445   r12: 0000000000000011   r15: >>>>> 0000000000000446 >>>>> (XEN) Xen code around : >>>>> (XEN)  90 90 90 90 90 90 90 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 >>>>> 90 90 >>>>> (XEN) Xen call trace: >>>>> (XEN)    [] R mce_amd.c#mc_ec2type.part.0+0/0x10 >>>>> (XEN)    [] S mc_amd_recoverable_scan+0x39/0x40 >>>>> (XEN)    [] S mcheck_mca_logout+0x42d/0x840 >>>>> (XEN)    [] S >>>>> amd_nonfatal.c#mce_amd_checkregs+0x1c/0x100 >>>>> (XEN)    [] S smp_call_function_interrupt+0x4c/0x90 >>>>> (XEN)    [] S do_IRQ+0x2a5/0x650 >>>>> (XEN)    [] S common_interrupt+0x135/0x150 >>>>> (XEN)    [] S >>>>> cpu_idle.c#acpi_idle_do_entry+0x8a/0x140 >>>>> (XEN)    [] S >>>>> cpu_idle.c#acpi_processor_idle+0x1ef/0x650 >>>>> (XEN)    [] S domain.c#idle_loop+0xc1/0x130 >>>>> (XEN) Panic on CPU 2 >>>>> >>>>> The outlined mc_ec2type.part.0 contains nothing but the ud2, so this is >>>>> the "unreachable" default branch of mc_ec2type() -- the extended error >>>>> code matches none of MC_EC_TLB_TYPE, MC_EC_MEM_TYPE, MC_EC_BUS_TYPE. >>>> I think it's safe to just drop the BUG(). >>>> >>>> That code is literally worse than useless, because if nothing else it's >>>> just hiding the diagnostics. >>>> >>>> I guess it means AMD have added new statuses. >>>> >>>>> Across the eight occurrences, r12 appears to be the bank index from the >>>>> loop in mcheck_mca_logout(), with rbx == 0x401 + 4 * r12 (MCi_STATUS) >>>>> and r15 == rbx + 1. Three different banks are involved: 10, 17 and 23. >>>>> >>>>> Not a hardware defect >>>>> --------------------- >>>>> - Started within days of upgrading two hosts from Debian bookworm >>>>>    (Xen 4.17) to trixie (Xen 4.20). They had run 3 years on 4.17 >>>>> with no >>>>>    incident. >>>>> - Three different banks, so not a single failing block. >>>>> - Updating to the current Debian package (4.20.5-pre, built 2026-10-16) >>>>>    changed nothing. >>>>> >>>>> Possibly related: 532988dccc19 ("x86/mcheck: fix mca_allbanks >>>>> updating"). >>>>> >>>>> Also possibly related on the Linux side: 0422b07bc4c2 ("x86/mce/amd: >>>>> Filter bogus hardware errors on Zen3 clients"), where bogus MCA values >>>>> on Zen 3 are filtered rather than treated as errors. >>>>> https://ratatoskr.run/stable/2026/04/7143905 >>>>  From above, you're on a Vermeer, not a Cezanne, so I don't think that >>>> Linux patch is relevant. >>>> >>>> However, your observation about "fix mca_allbanks updating" quite >>>> possibly is.  That was backported into Xen 4.20.1 as 247b708b1400a, and >>>> Debian has 4.20.3 >>>> >>>> Are you able to experiment with that patch reverted? >>>> >>>> Alternatively, are you able to experiment with the BUG() removed? >>> I went with dropping the BUG() rather than the revert. >>> Reverting 247b708b1400a should stop any bank from being read at >>> all, which is effectively what mce=false already does here, so I don't >>> expect it to tell us anything new. I'll run it too if you'd like. >>> >>> I'm not familiar with the Xen codebase, but I've built a package with >>> mc_ec2type() changed to: >>> >>>     if ( errorcode & MC_EC_TLB_TYPE ) >>>         return MC_EC_TLB_TYPE; >>> >>>     printk(XENLOG_WARNING "MCE: unknown AMD error code %#x\n", >>> errorcode); >>> >>>     return 0; >>> >>> >>> Crashes have been 12 hours to 2 weeks apart, so it may take a while >>> before I can report back. >> After ~31 hours of uptime: >> >> (XEN) [2026-10-25 04:06:27.260] MCE: unknown AMD error code 0 >> >> No panic, no wedged CPU, no RCU stalls, no hung guests. Host and all >> VMs running normally. >> >> >> I also dumped /dev/mcelog in dom0 and got the following records: >> >> 00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> 00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> 00000030: 0000 0000 0000 0000 0200 0000 0000 0000  ................ >> 00000040: 0010 0201 0200 0000 0000 0000 0200 0000  ................ >> 00000050: 1c01 0000 0000 0000 0000 0000 0000 0000  ................ >> 00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> 00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> 00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> 00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> 000000a0: 0000 0000 0000 0000 0200 0000 0000 0000  ................ >> 000000b0: 0017 0201 0200 0000 0000 0000 0200 0000  ................ >> 000000c0: 1c01 0000 0000 0000 0000 0000 0000 0000  ................ >> 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................ >> >> >>> >>>>> Diagnostics / workaround >>>>> ------------------------ >>>>> mce_verbosity=verbose yields nothing useful. >>>>> max_cstate=1 made no difference. mce=false is the only thing that stops >>>>> it, and it is what I'm running now. >>>> The fact that mce=false isn't causing machine resets means it's clearly >>>> something the hardware thinks isn't fatal. >>>> >>>> But, I am concerned by the fact it's always on CPU 2, and multiple >>>> banks.  Is this true for both systems? >>> To clarify one thing from my report: it is actually a single host whose >>> complete hardware (board, CPU, RAM) was replaced on >>> 2026-10-07, keeping only the disks and thus the installation. The >>> crashes happened both before and after that swap. 10 more hosts >>> with same hardware still run on bookworm (xen 4.17) for years now >>> without any incidents. >>> >>> So yes, always CPU 2. The bank index varies: on the current hardware >>> I have seen banks 23, 17 and 10 across four crashes, and banks 23 and >>> 17 on the previous hardware. >> Regarding the output of /dev/mcelog: if my decoding is right, three >> things stand out. MCi_STATUS is zero, i.e. these banks are reporting >> nothing at all -- no error, no garbage value. > Well, things can't quite be that way: If MCi_STATUS was zero, the first > check in mc_amd_recoverable_scan() would prevent mc_ec2type() from > being reached in the first place. Its caller also checks MCi_STATUS_VAL > to be set. > > What I find puzzling is this: > > errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC); > ectype = mc_ec2type(errorcode); > > With errorcode (and mc_ec2type()'s parameter type) being uint16_t, what > use is it to include MCi_STATUS_MSEC in the mask? (Yet that's likely > unrelated to the issue at hand.) Considering how mc_ec2type() works, I > see no reason why status couldn't be passed to it directly (with the > parameter type widened to uint32_t). Then the BUG() there could perhaps > become BUG_ON(errorcode). You're right, my conclusion was wrong. One more data point, from an hour ago: (XEN) [2026-10-26 13:13:42.050] MCE: unknown AMD error code 0x1000 So it isn't always 0. The uint16_t truncation might explain the first (MSEC bits dropped), but 0x1000 is a non-zero code that still matches none of MC_EC_BUS_TYPE / MC_EC_MEM_TYPE / MC_EC_TLB_TYPE. /dev/mcelog right afterwards showed three records, banks 17, 14 and 16, all CPU 2 (status zero, as above). Banks seen so far across panics and log lines: 10, 14, 16, 17, 23. With the BUG() dropped, the host has now logged this twice with no panic, no wedged CPU and no hung guests. Everything is running normally. Regarding passing status as uint32_t and BUG_ON(errorcode): with today's 0x1000, bits 0-31 are non-zero but none of the type bits is set, so that BUG_ON would still trigger. So unless 0x1000 is a known type that mc_ec2type() should handle, I think the poller shouldn't BUG on an unclassifiable code at all. >> Both records are again >> from CPU 2, and bank 23 is one of the banks that appeared in the >> panics, bank 16 is new. > Isn't it possible that the lack of 532988dccc19 ("x86/mcheck: fix > mca_allbanks updating") simply hid the issue previously? That is exactly what I suspect. This host, and 10 more with identical hardware, ran for years on Xen 4.17 without a single incident. The first panic came within days of upgrading this one to 4.20; the others are still on 4.17 and still fine. If no bank was being collected before, nothing could have reached mc_ec2type() -- so the condition may well have been there the whole time, just never looked at. Would it help if I logged the full MCi_STATUS of the first read, i.e. in mcheck_mca_logout() right after the MCi_STATUS_VAL check, together with CPU and bank number? Peter From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:52:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:52:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461450.1672458 (Exim 4.92) (envelope-from ) id 1xLM3q-0000Ct-Hp; Mon, 26 Oct 2026 14:52:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461450.1672458; Mon, 26 Oct 2026 14:52: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 1xLM3q-0000Cm-F6; Mon, 26 Oct 2026 14:52:30 +0000 Received: by outflank-mailman (input) for mailman id 1461450; Mon, 26 Oct 2026 14:52:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLM3o-0000Cd-6p for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:52:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLM3n-00EOqz-Cu for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:52:27 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6921-2eae-0a2a0a5409dd-0a2a4506974c-16 for ; Mon, 26 Oct 2026 15:52:27 +0100 Received: from [52.101.83.80] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf6925-195a-0a2a45060019-34655350084f-3 for ; Mon, 26 Oct 2026 15:52:21 +0100 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by DBAPR03MB6632.eurprd03.prod.outlook.com (2603:10a6:10:17d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 14:52:19 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 14:52: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=Dhd9DDzNDVKC24mYO0j7DRhf9uZ1H59FUBvf1Wca4TvMjqaD77iIu+NCtYVYXF5ItEBpxRx7lLAE++xuccyYgE2WCWo3qYyzRFkspGdxw/Gn0yoyLWMMEmYnggv8ImJOYI0kqJy4FFPm5SB/ZtNSuZkTlNosK+fpRExWheNdFbFF/l1z+2bnJx9+qan1Dz0c94b520lYh5+YMmnloFzMt27z8qHFgQBm75TW7vDMEh/JE2YCpy/oQLaoLDadJ0e/p7c2yeWuoqz4cSsHN0VOM/CqFVclBxengRC5ABTnTexcT8Rqabd6H6EJv3IISWtmRs9bcVA8BuMNWmmmZ1fuzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9gEhsmRvSo80Zf+IiN3sJZpaqxO6q14tB6eJa/JTniU=; b=WGpotDPZEit9jIGIXcmQb8bchZW/DMs6sNn3Ycj9y+w7Tg9CUOUW8ktUg5Qm6YsqzCK6aI71pGoZEdU3LF/SJvEba/+iDfpMhZueLFndaqP3CQspvupyaUlCSbSO39o8IBU4eOqURQ3xnrxdY176PSgOPkpaOQwP4nUaHGWp6khJBnRd5bxiv1Ij89GKTnk6GJ42XZg0xn5xfMR/mYWlDdN8ll66LlvxslTUjirkSCEjuL6JLu3HZqbbtiD9fH261YvCQd2BqVPBhYTlC3EYg2j3y+4CFBl5FtkPBNVZXyfWCKAbypN7ybMAmU09VlavbZ47d9ax3fWzrZ3iJDuTHA== 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=9gEhsmRvSo80Zf+IiN3sJZpaqxO6q14tB6eJa/JTniU=; b=t1WD087jTScJmhohw7sEb9HrLjNUoqjIHjIuBOiUsJtsmY0dpZMingtKSlR0v5CMyCoIBcBiowEAjv31n7uG+3HXBbP7W0Sd3HjB4AShgzV+sS+DA9m8hiyYz1+ezT5vC4vqU0x5khShxCWQrta2KWNBvI+Bjs6UxYLgalXSxvl6YAN+3VjCTODGkUq5e//AB8McLEVN0kxW0ID0T8qS9aDOMVxeq2l1OZtDC+iXdmlsQ1uVDgi0dN4M0aIgLLHm1gJn+xoI4CrUv+PHTSqLz53ZDPbi9tO32a8tUPk3JeqNxdTxwfao32sCyKtsWaGTQsxvHUquFllAL5i2bGpplg== From: Oleksii Moisieiev To: Jan Beulich , Oleksii Kurochko CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Teddy Astie , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Topic: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Index: AQHdUnGcfnmLH64VckKy7OjAkXrKMLbuqNIAgCFle4A= Date: Mon, 26 Oct 2026 14:52:19 +0000 Message-ID: References: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.git.oleksii_moisieiev@epam.com> In-Reply-To: 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: GVXPR03MB11113:EE_|DBAPR03MB6632:EE_ x-ms-office365-filtering-correlation-id: 97a0c159-6d49-46de-04a2-08df3370bbf1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|1800799024|366016|261026140227099002|261026121527099002|38070700021|4143699003|11063799006|56012099006|261009223027099003|261021135927099003|261022105027099003|261021121427099003|261022075727099003|10067099003|18002099003|22082099003|6133799003; x-microsoft-antispam-message-info: jWXm3kG/KqU9mOJ+jZmSP3xVxndLiJGJbHBYFGPOpG/KNeQNhX8q/DbDN8LtZZn10LJnTbVS8ebXd8nIPSC5EM1X4JxNwjTs0Hdq7T5n3ghFWFVUsM7+/TGjDPi+4bTR6DWhyoH9rJURanrXye6j+shzW1NFOQW2/tQjoI/qx8j5Wr8mBcgLa+1+UPEE2QhABCQgVwN7B63LwzEG7Pt5C3/F7L5zW2iOXY7rk6bEPR4gAzg+8lIIPTpv+A8U7c48fQOLtpRNdk13Mgp9Tl73PXZlclyZ2vWCY2zqcauFZgDj5+TGGl5hMbn++yPOkkkMChqazxXE95+DRjzuqnMUMhCy15D3ZFay+I8c1SWFKd0lcV7ShEfhHby8a72/hM4ubg3DyCqwJ9Zn7KVESntYnFyRON1B0OHv0/48NMHXfQaJazcI3w86GSxzP9L0LZXJ/VSAJ8+K7o7RKHs4w8vT+qQP93TOWqxz1+VTlcL77uLCtxOs5TDlsRJf+fRoLMyvLVnnjqDwJrnMSVxvAZC/FxLyFfoujKq05iqg1PGa0vYGF/EQREwkFayMAB+TMP1jYrLCpt4hBKHYCFCOy5gMiVCGUvWxNdq6gWLM0yRrBP7cv6sjlsSjcpQVqmTmZeIk7VgcX2Hg3rFfs6acwQ1X9967YZB6KzwcjznQljs86uhD+rmreQk1N4bh/hJmOfF+Cman1l7g0ca0ZNWj4+QEtVTs3qcJYGScQiTnfyxDcGk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(1800799024)(366016)(261026140227099002)(261026121527099002)(38070700021)(4143699003)(11063799006)(56012099006)(261009223027099003)(261021135927099003)(261022105027099003)(261021121427099003)(261022075727099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?amIvNlQzT2JXTDFCWDFoSVVBNVhIWTRBUmVVYjB4c25HMEFzd3plc0dRUmRO?= =?utf-8?B?M1JtaEdjbnMxbCtWd3JQRU1YUkRtZFhzb1Q1VkNxWFdzakxTMW45Z3BQYzhh?= =?utf-8?B?ZjloNzhPbXNjSGo3bGFhZ0hEY09tcHRKZUl2QlQ4ZzVLanVjOFVkQXhuc0lp?= =?utf-8?B?bHo5eGw1aUJzalk1QjZsL2hMc3h4blFVbGR2OXVzRGtIL2lnS2FRNTdmY2VY?= =?utf-8?B?V25qUWt0VENNVktmK0NQaDU5WnBPZUtQZDFneWVuayt3UjlmMXZlOEc2dVMx?= =?utf-8?B?QVZPbE1uYWdFWGVxOVNCQ2w2MzZzY3BPL0NFN0U3R1N4WW1Ra3REdG9FTkJi?= =?utf-8?B?dlBONGpDazQ4NWJvL3VUSXRmNy9iRmJKdWFpVzM5ZW1udjVyem5iMzB4eU5j?= =?utf-8?B?LytuOVZHTXM2cHNTTklzQkZZRDZmanJMam4wcEo4ejJ3NkZ3M2tvQkt5YXNw?= =?utf-8?B?T2ZXVlp1QVU0RFVLU0ZTd1FVdHBvSGJQYXdIRXJobExaOE9HbUJuQ2ptT2R4?= =?utf-8?B?dWZ5ejFKblZyOTVjVUdEYXY0TFZXa3FZWE50R1hzdmM0ZlBWcWpGV3R4a1Nj?= =?utf-8?B?U01KY3VpMnp3VkxmZmJ5aFdRSjRGR0FUcVJFa1htSEp4ZjJsZmlOVU1NWEds?= =?utf-8?B?VExJRkNLenEyM1JhVkF5RUNVRVFtMkNtdjd3RTFzalJMa2FzdzkvUE5paUMx?= =?utf-8?B?S2o3VlJ1U3RxYXEzM2pXcm11TmFoeEJ5VVpxd0paWFk2SFBqWVFEcTNNMDM3?= =?utf-8?B?c3IvRlF1MWhpNWtPc0hBSy9FaU0xVEV1c1lCR0RRNlZxczNUbmlTZDd4Z21T?= =?utf-8?B?U2l4VjF3eUh0a1A3K0ptekdPcmNqNnhFWVlGaTRBL1JhZ2U0RXlCWkVxRUtV?= =?utf-8?B?OGF5L3Fza3pJUEhSNlBQVEJIZmxPRXNrRVd1UG1MYy9PYlNxaFZZM3p5UUFZ?= =?utf-8?B?TTlZcEFJcERLeHNFQ2FxTGpOL2VTNFh6dHFLQ3pjOTNSVjRlNFVNay8ya0l0?= =?utf-8?B?Q2pEMEVWZFEwc2trN3FzbHlGNVVOc2VQWGJndXpjV0F2cXEyaTcvbGN5UnJw?= =?utf-8?B?R0R3T1VqUkpNQUF6UmcrdWZQL0czK1g5UzhQZjFCeUxPbWpGV0FUa055dmhq?= =?utf-8?B?NVh0TzcrRlczcmhtMlYrNG0xcnFnWUMzek4zWXF2cElDdWZHZ1BzN3E4KzJm?= =?utf-8?B?U21IdjZUdVNIeGNFaTkzTFJ3RHZwQ3hQVkdZa2ZzTzR2RmZVTTgwMlhjVXZs?= =?utf-8?B?N2EwN2dZTCtMNEFGMTNMN0QrYUV4eVJ5U1haWlFlRm14QnRRSlVNM0NOaWtO?= =?utf-8?B?VGViRUoya05hV1lIVG1vN1cyTDZqMHNnM0RLb1R6aURlQW5maS9ERDJRUmdS?= =?utf-8?B?RG9lRlN5Vm9lakd6SDg0SjF1YVlsM2ZvTUc1cXRpSFZWdjdGMVpuQy80cHda?= =?utf-8?B?T2xoNC9DZ0NrclhMcHJmS1llTHdLS21zWjF2dEVuQ085REhoM0RLZlhLK1c0?= =?utf-8?B?dWhtb1JQMTlPV0FTZFh3RUlLemwxb3IyMmEyRFgrZmFLdkJ1Z2xFQzN0QURq?= =?utf-8?B?R005aUlhQUFsa1l3cjBadXI3VjRLMk1tT1kvRlhMS1liMFc0Q0l6dVdKcGw4?= =?utf-8?B?VTFnMWFhL095VWQzTklTYnZNdlBHZmFWUnYzY2RhOFdzYlRra3FxVHAyZUwz?= =?utf-8?B?SGVLbW44b0hnaVYySUlsT1hvRU1mRll0WGwvWFNzaTFjSHQyTk5zK3pNdy81?= =?utf-8?B?T0ZYWjBKRmhaeW5NcWp2NVRIZm9Ib0lYdmhGRTU5UlFWWDRDT1FaNmt0eXdT?= =?utf-8?B?c0IvUk9TRG9RekY4MDkvZ0d6MldyZ2huRmQ1WDFTUm9US2hteXZ3a2s3ZjhP?= =?utf-8?B?VUVnekIrTHZuVGphbTZ6Q3ZVYmNDTUcxZjR6UDFOWGxxMDgzN1o5SXYvSzNi?= =?utf-8?B?b0VYTzBDVHMrQjRIdEdqbTZWdlJQSGVYcWJrMER0VFRSc1JGNlhSb1pISzZN?= =?utf-8?B?N2hEV05zRnJ0clloZ2R5UkpvZlFoZXRZSlpLNW05Y0pFVzVMeE5BN1pRTDE3?= =?utf-8?B?ejMveG9XQ09XcFRwR1N0MFo0empoRXk0TFkrYVhUbzBpbTBtSWhCMW9DblB3?= =?utf-8?B?UlQ3VHNkVVI5c1FRR0lZWFRyV0FEM1d0djZDUFAxREFBUzdrZFZvUWNJQnJt?= =?utf-8?B?RCtWNko2WkFPaFlnOVlqV1FvUkRuSzRPSmpPZWN2eURRYTJMRHR4TVFxVUhY?= =?utf-8?B?Y2laSkpyc0s2cEJqdnRmak9tazVCQVFZaUhlWStXN1Q5UVRSc2J6SkVxQThN?= =?utf-8?B?VEhDTDJtUmdRZ0FTcGwyODZZOVZtdHBqNkpyWTI4Y0Q2NURWWmw1YTR3UzQ2?= =?utf-8?Q?l6S3pwtErjossE6E=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <7E4AF48006B2A9489BCF8D2B2FA012C6@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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97a0c159-6d49-46de-04a2-08df3370bbf1 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 14:52:19.1891 (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: eHJyLHdyjes8pTAYw3GdKLch5GhKtDuPs9YlRW2Kg5BX+mgEdp5uuccsnzEjtTYXcTIm7gByBypvLkCWyjFU8AKhCQmHH/EB7hmoxlnXK7o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6632 X-purgate-ID: tlsNG-16d1c6/1793026341-1F8CB77B-370629D5/10/78276251493 X-purgate-type: spam X-purgate-size: 10682 DQpIaSBKYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gSSdtIHByZXBhcmluZyB2NiByaWdo dCBub3cuIE15IHBsYW5zIGZvciB0aGUgDQpjaGFuZ2VzIGFyZSBvdXRsaW5lZCBiZWxvdy4NCg0K T24gMDUvMTAvMjAyNiAxMTo1MiwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDAyLjEwLjIwMjYg MTU6MjYsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gVGhpcyBjb21taXQgaW50cm9kdWNl cyBhIG5ldyBLY29uZmlnIG9wdGlvbiwgYENPTkZJR19ET00wX0JPT1RgLCB0bw0KPj4gYWxsb3cg Zm9yIGJ1aWxkaW5nIFhlbiB3aXRob3V0IHN1cHBvcnQgZm9yIGJvb3RpbmcgYSByZWd1bGFyIGRv bWFpbiAoRG9tMCkuDQo+PiBUaGlzIGZ1bmN0aW9uYWxpdHkgaXMgcHJpbWFyaWx5IGludGVuZGVk IGZvciB0aGUgQVJNIGFyY2hpdGVjdHVyZS4NCj4gSSAoc3RpbGwpIHdvbmRlciB3aHkgdGhpcyB3 b3VsZCBiZSwgYnV0IHdlbGwgLi4uDQpGb3IgdjYsIEknbSBnb2luZyB0byBkZXNjcmliZSB0aGlz IGFzIGEgY29tbW9uIG9wdGlvbiBmb3IgbGVnYWN5IERvbTANCmJvb3QsIHdpdGggQXJtIGltcGxl bWVudGluZyB0aGUgY29kZSBleGNsdXNpb24gaW5pdGlhbGx5LiBNeSBpbW1lZGlhdGUNCnVzZSBj YXNlIGlzIGFuIEFybSBkZXBsb3ltZW50IHdoZXJlIGd1ZXN0cyBhcmUgbGF1bmNoZWQgdGhyb3Vn aA0KZG9tMGxlc3MgYW5kIGxlZ2FjeSBEb20wIGJvb3QgaXMgbm90IG5lZWRlZC4gSSdtIGdvaW5n IHRvIGNsYXJpZnkgdGhhdA0KdGhpcyB1c2UgY2FzZSBtb3RpdmF0ZXMgdGhlIGluaXRpYWwgQXJt IGltcGxlbWVudGF0aW9uLCByYXRoZXIgdGhhbg0KbWFrZSB0aGUgaW50ZXJmYWNlIEFybS1zcGVj aWZpYy4gSXMgdGhhdCBzY29wZSBPSz8NCj4+IEEgbmV3IEtjb25maWcgc3ltYm9sLCBgSEFTX0RP TTBgLCBoYXMgYmVlbiBhZGRlZCBhbmQgaXMgc2VsZWN0ZWQgYnkNCj4+IGRlZmF1bHQgZm9yIEFS TSBhbmQgWDg2IGFyY2hpdGVjdHVyZS4gVGhpcyBzeW1ib2wgc2lnbmlmaWVzIHRoYXQgYW4NCj4+ IGFyY2hpdGVjdHVyZSBoYXMgdGhlIGNhcGFiaWxpdHkgdG8gc3VwcG9ydCBhIERvbTAuDQo+IE9s ZWtzaWkgLSB3aGF0J3MgeW91ciB0YWtlIHRvd2FyZHMgUklTQy1WIGhlcmU/IFNob3VsZCBpdCBz ZWxlY3QgdGhlIG5ldw0KPiBzeW1ib2wgcmlnaHQgYXdheSBhcyB3ZWxsPw0KSW4gdGhlIHN0YWdp bmcgYnJhbmNoIFJJU0MtVidzIHN0YXJ0X3hlbigpIGRvZXMgbm90IGhhdmUgYSBsZWdhY3kgRG9t MCANCmNvbnN0cnVjdGlvbiBwYXRoLg0KSSdtIHRoZXJlZm9yZSBnb2luZyB0byBsZWF2ZSBIQVNf RE9NMCB1bnNlbGVjdGVkIG9uIFJJU0MtViBhbmQgZXhwbGFpbg0KdGhhdCBzZWxlY3Rpb24gc2hv dWxkIGFjY29tcGFueSBpbXBsZW1lbnRhdGlvbiBvZiBsZWdhY3kgRG9tMCBib290Lg0KSXRzIGV4 aXN0aW5nIEhBU19ET00wTEVTUyBzZWxlY3Rpb24gZG9lcyBub3QgcHJvdmlkZSB0aGF0IHBhdGgu DQpEb2VzIGl0IHNvdW5kcyBvayB0byB5b3U/DQo+PiBUaGUgYERPTTBfQk9PVGAgb3B0aW9uIGRl cGVuZHMgb24gYEhBU19ET00wYCBhbmQgZGVmYXVsdHMgdG8gJ3knLiBGb3INCj4+IGV4cGVydCB1 c2VycywgdGhpcyBvcHRpb24gY2FuIGJlIGRpc2FibGVkIChgQ09ORklHX0VYUEVSVD15YCBhbmQg bm8NCj4+IGBDT05GSUdfRE9NMF9CT09UYCBpbiB0aGUgY29uZmlnKSwgd2hpY2ggd2lsbCBjb21w aWxlIG91dCB0aGUgRG9tMA0KPj4gY3JlYXRpb24gY29kZSBvbiBBUk0uIFRoaXMgaXMgdXNlZnVs IGZvciBlbWJlZGRlZCBvciBkb20wbGVzcy1vbmx5DQo+PiBzY2VuYXJpb3MgdG8gcmVkdWNlIGJp bmFyeSBzaXplIGFuZCBjb21wbGV4aXR5Lg0KPj4NCj4+IFRoZSBBUk0gYm9vdCBwYXRoIGhhcyBi ZWVuIHVwZGF0ZWQgdG8gcGFuaWMgaWYgaXQgZGV0ZWN0cyBhIG5vbi1kb20wbGVzcw0KPj4gY29u ZmlndXJhdGlvbiB3aGlsZSBgQ09ORklHX0RPTTBfQk9PVGAgaXMgZGlzYWJsZWQsIHByZXZlbnRp bmcgYW4gaW52YWxpZA0KPj4gYm9vdC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1v aXNpZWlldiA8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+PiBBY2tlZC1ieTogSmFuIEJl dWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBOb3R3aXRoc3RhbmRpbmcgdGhlIGFjaywgYSBm ZXcgZnVydGhlciBjb21tZW50cy4NClRoYW5rcyBmb3IgdGFraW5nIGFub3RoZXIgbG9vay4gU2lu Y2UgdjYgd2lsbCBjaGFuZ2UgdGhlIHg4NiBwcm9tcHQgYW5kDQp0aGUgaGFuZGxpbmcgb2YgdGhl IGNvbW1vbiBEb20wIG9wdGlvbnMsIEknbSBnb2luZyB0byBsZWF2ZSB0aGUgZWFybGllcg0KQWNr ZWQtYnkgb3V0IHBlbmRpbmcgY29uZmlybWF0aW9uIHRoYXQgaXQgc3RpbGwgYXBwbGllcy4NCj4+ IC0tLSBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gKysrIGIveGVuL2FyY2gvYXJt L2RvbWFpbl9idWlsZC5jDQo+PiBAQCAtNDMsOCArNDMsMTAgQEANCj4+ICAgI2luY2x1ZGUgPGFz bS9ncmFudF90YWJsZS5oPg0KPj4gICAjaW5jbHVkZSA8eGVuL3NlcmlhbC5oPg0KPj4gICANCj4+ ICsjaWZkZWYgQ09ORklHX0RPTTBfQk9PVA0KPj4gICBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5p dGRhdGEgb3B0X2RvbTBfbWF4X3ZjcHVzOw0KPj4gICBpbnRlZ2VyX3BhcmFtKCJkb20wX21heF92 Y3B1cyIsIG9wdF9kb20wX21heF92Y3B1cyk7DQo+PiArI2VuZGlmDQo+PiAgIA0KPj4gICAvKg0K Pj4gICAgKiBJZiB0cnVlLCB0aGUgZXh0ZW5kZWQgcmVnaW9ucyBzdXBwb3J0IGlzIGVuYWJsZWQg Zm9yIGRvbTAgYW5kDQo+PiBAQCAtMTIzLDYgKzEyNSw3IEBAIHBhZGRyX3QgX19pbml0IGh3ZG9t X2dldF9mZHRfYWxsb2Nfc2l6ZSh2b2lkKQ0KPj4gICAgICAgcmV0dXJuIEFDUElfRE9NMF9GRFRf TUlOX1NJWkU7DQo+PiAgIH0NCj4+ICAgDQo+PiArI2lmZGVmIENPTkZJR19ET00wX0JPT1QNCj4+ ICAgdW5zaWduZWQgaW50IF9faW5pdCBkb20wX21heF92Y3B1cyh2b2lkKQ0KPj4gICB7DQo+PiAg ICAgICBpZiAoIG9wdF9kb20wX21heF92Y3B1cyA9PSAwICkNCj4+IEBAIC0xMzUsNiArMTM4LDcg QEAgdW5zaWduZWQgaW50IF9faW5pdCBkb20wX21heF92Y3B1cyh2b2lkKQ0KPj4gICANCj4+ICAg ICAgIHJldHVybiBvcHRfZG9tMF9tYXhfdmNwdXM7DQo+PiAgIH0NCj4+ICsjZW5kaWYNCj4+ICAg DQo+PiAgIC8qDQo+PiAgICAqIEluc2VydCB0aGUgZ2l2ZW4gcGFnZXMgaW50byBhIG1lbW9yeSBi YW5rLCBiYW5rcyBhcmUgb3JkZXJlZCBieSBhZGRyZXNzLg0KPj4gQEAgLTE4NjIsNiArMTg2Niw3 IEBAIGludCBfX2luaXQgY29uc3RydWN0X2RvbWFpbihzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg a2VybmVsX2luZm8gKmtpbmZvKQ0KPj4gICAgICAgcmV0dXJuIDA7DQo+PiAgIH0NCj4+ICAgDQo+ PiArI2lmZGVmIENPTkZJR19ET00wX0JPT1QNCj4+ICAgc3RhdGljIGludCBfX2luaXQgY29uc3Ry dWN0X2RvbTAoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICAgew0KPj4gICAgICAgc3RydWN0IGtlcm5l bF9pbmZvIGtpbmZvID0gS0VSTkVMX0lORk9fSU5JVDsNCj4+IEBAIC0xODkzLDYgKzE4OTgsNyBA QCBzdGF0aWMgaW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tMChzdHJ1Y3QgZG9tYWluICpkKQ0KPj4g ICANCj4+ICAgICAgIHJldHVybiBjb25zdHJ1Y3RfaHdkb20oJmtpbmZvLCBOVUxMKTsNCj4+ICAg fQ0KPj4gKyNlbmRpZg0KPj4gICANCj4+ICAgaW50IF9faW5pdCBjb25zdHJ1Y3RfaHdkb20oc3Ry dWN0IGtlcm5lbF9pbmZvICpraW5mbywNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlKQ0KPj4gQEAgLTE5NDQsNiArMTk1MCw3 IEBAIGludCBfX2luaXQgY29uc3RydWN0X2h3ZG9tKHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8s DQo+PiAgICAgICByZXR1cm4gY29uc3RydWN0X2RvbWFpbihkLCBraW5mbyk7DQo+PiAgIH0NCj4+ ICAgDQo+PiArI2lmZGVmIENPTkZJR19ET00wX0JPT1QNCj4+ICAgdm9pZCBfX2luaXQgY3JlYXRl X2RvbTAodm9pZCkNCj4+ICAgew0KPj4gICAgICAgc3RydWN0IGRvbWFpbiAqZG9tMDsNCj4+IEBA IC0yMDAxLDYgKzIwMDgsNyBAQCB2b2lkIF9faW5pdCBjcmVhdGVfZG9tMCh2b2lkKQ0KPj4gICAN Cj4+ICAgICAgIHNldF94c19kb21haW4oZG9tMCk7DQo+PiAgIH0NCj4+ICsjZW5kaWYgLyogQ09O RklHX0RPTTBfQk9PVCAqLw0KPiBJdCdzIG5vdCByZWFsbHkgYSBsb3Qgb2YgY29kZSB3aGljaCBp cyBiZWluZyByZW1vdmVkLCB3aGljaCBtYXkgc3VnZ2VzdCB0aGlzDQo+IGlzIGdldHRpbmcgdG9v IGZpbmUtZ3JhaW5lZC4gKFByaW1hcmlseSwgZm9yIG5vdykgQXJtIG1haW50YWluZXJzIHdpbGwg bmVlZA0KPiB0byBqdWRnZS4NCg0KSSdtIGdvaW5nIHRvIGxpbWl0IHRoZSBzY29wZSB0byBleGNs dWRpbmcgbGVnYWN5IERvbTAgY29uc3RydWN0aW9uIGFuZA0KaXRzIHByaXZhdGUgYm9vdCBvcHRp b25zLiBJJ20gYWxzbyBnb2luZyB0byBleGNsdWRlIHRoZSBhZGRpdGlvbmFsDQpEb20wLW9ubHkg bWVtb3J5LCBTVkUgYW5kIGNhY2hlLWNvbG9yaW5nIGNvZGUgaWRlbnRpZmllZCBieSBNaWNoYWws IGFuZA0KbWFrZSBBcm0gQUNQSSBkZXBlbmQgb24gRE9NMF9CT09ULiBTaGFyZWQgZG9tYWluIGNv bnN0cnVjdGlvbiB3aWxsDQpyZW1haW4sIHNpbmNlIGRvbTBsZXNzIGhhcmR3YXJlIGRvbWFpbnMg YWxzbyB1c2UgaXQuIEknbSBnb2luZyB0byByZW1vdmUNCnRoZSBjbGFpbSB0aGF0IHRoaXMgZWxp bWluYXRlcyBhbGwgdW5yZWFjaGFibGUgY29kZSBvciBlc3RhYmxpc2hlcw0KTUlTUkEgY29tcGxp YW5jZS4NCg0KPg0KPiBJIGZ1cnRoZXIgd29uZGVyIGhvdyBtdWNoIHVucmVhY2hhYmxlIGNvZGUg aXMgbmV3bHkgaW50cm9kdWNlZCBieSB0aGlzLCB3aGVuDQo+IHRoZSBuZXcgb3B0aW9uIGlzIGVu YWJsZWQuIHNldF94c19kb21haW4oKSAodmlzaWJsZSBpbiBwYXRjaCBjb250ZXh0IGFib3ZlKQ0K PiBpcyBwb3NzaWJseSBvbmx5IHRoZSBmaXJzdCBleGFtcGxlLg0KDQpJIGNoZWNrZWQgdGhlIGNh c2Ugd2l0aCBET00wX0JPT1Q9bi4gY3JlYXRlX2RvbVVzKCkgc3RpbGwgY2FsbHMNCnNldF94c19k b21haW4oKSBmb3IgYSBkb20wbGVzcyBkb21haW4gd2l0aCBYRU5fRE9NQ1RMX0NERl94c19kb21h aW4gc2V0Lg0KU2ltaWxhcmx5LCBjb25zdHJ1Y3RfZG9tVSgpIGNhbGxzIGNvbnN0cnVjdF9od2Rv bSgpIGZvciBhIGhhcmR3YXJlDQpkb21haW4uDQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vc2V0dXAu Yw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3NldHVwLmMNCj4+IEBAIC00OTEsMTEgKzQ5MSwxOCBA QCB2b2lkIGFzbWxpbmthZ2UgX19pbml0IG5vcmV0dXJuIHN0YXJ0X3hlbih1bnNpZ25lZCBsb25n IGZkdF9wYWRkcikNCj4+ICAgDQo+PiAgICAgICBkb19pbml0X2Jvb3R0ZXN0cygpOw0KPj4gICAN Cj4+IC0gICAgLyogQ3JlYXRlIGluaXRpYWwgZG9tYWluIDAuICovDQo+PiAtICAgIGlmICggIWlz X2RvbTBsZXNzX21vZGUoKSApDQo+PiArICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRE9NMF9C T09UKSAmJiAhaXNfZG9tMGxlc3NfbW9kZSgpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgLyog Q3JlYXRlIGluaXRpYWwgZG9tYWluIDAuICovDQo+PiAgICAgICAgICAgY3JlYXRlX2RvbTAoKTsN Cj4+ICsgICAgfQ0KPj4gICAgICAgZWxzZQ0KPj4gLSAgICAgICAgcHJpbnRrKFhFTkxPR19JTkZP ICJYZW4gZG9tMGxlc3MgbW9kZSBkZXRlY3RlZFxuIik7DQo+PiArICAgIHsNCj4+ICsgICAgICAg IGlmICggaXNfZG9tMGxlc3NfbW9kZSgpKQ0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0df SU5GTyAiWGVuIGRvbTBsZXNzIG1vZGUgZGV0ZWN0ZWRcbiIpOw0KPj4gKyAgICAgICAgZWxzZQ0K Pj4gKyAgICAgICAgICAgIHBhbmljKCJOZWl0aGVyIGRvbTAgbm9yIGRvbTBsZXNzIG1vZGUgd2Fz IGRldGVjdGVkLCBhYm9ydGluZ1xuIik7DQo+PiArICAgIH0NCj4gSWYgSSB3YXMgbWFpbnRhaW5l ciBvZiB0aGlzIGNvZGUsIEkgd291bGQgYXNrIGZvciB0aGUgZmlndXJlIGJyYWNlcyB0byBiZQ0K PiBvbWl0dGVkIC0gdGhlIGlubmVyIGlmKCkgY2FuIGVhc2lseSBiZSAiZWxzZSBpZiIuDQpJJ20g Z29pbmcgdG8gdXNlIE1pY2hhbCdzIHByb3Bvc2VkIHNlcXVlbmNlOiBjaGVjayBpc19kb20wbGVz c19tb2RlKCkNCm9uY2UsIG90aGVyd2lzZSBjcmVhdGUgRG9tMCBpZiBET00wX0JPT1QgaXMgZW5h YmxlZCwgb3RoZXJ3aXNlIHBhbmljLg0KVGhpcyByZW1vdmVzIHRoZSBleHRyYSBicmFjZXMgYW5k IHRoZSByZXBlYXRlZCBkZXRlY3Rpb24uDQo+PiAtLS0gYS94ZW4vY29tbW9uL0tjb25maWcNCj4+ ICsrKyBiL3hlbi9jb21tb24vS2NvbmZpZw0KPj4gQEAgLTI2LDYgKzI2LDE1IEBAIGNvbmZpZyBE T00wTEVTU19CT09UDQo+PiAgIAkgIFhlbiBib290IHdpdGhvdXQgdGhlIG5lZWQgb2YgYSBjb250 cm9sIGRvbWFpbiAoRG9tMCksIHdoaWNoIGNvdWxkIGJlDQo+PiAgIAkgIHByZXNlbnQgYW55d2F5 Lg0KPj4gICANCj4+ICtjb25maWcgRE9NMF9CT09UDQo+PiArCWJvb2wgIkRvbTAgYm9vdCBzdXBw b3J0IiBpZiBFWFBFUlQgJiYgIVg4Ng0KPiBMaWtlIGFscmVhZHkgaW5kaWNhdGVkIGluIHJlcGx5 IHRvIHYzIEknbSBpcnJpdGF0ZWQgYnkgdGhpczogV2hhdCB1c2UgaXMNCj4gdGhlIHNlbGVjdCBv ZiBIQVNfRE9NMCBvbiB4ODYgd2hlbiB0aGVuIHlvdSBleGNsdWRlIHg4NiBoZXJlPyBJIHRoaW5r IGl0DQo+IG5lZWRzIHRvIGJlIGNsYXJpZmllZCB3aGV0aGVyLCBhcyB0aGUgY29tbWl0IG1lc3Nh Z2Ugc2F5cywgdGhpcyBpcyBnb2luZw0KPiB0byBiZSBBcm0tb25seSBvciBvZiBicm9hZGVyIHVz ZS4gSW4gdGhlIGxhdHRlciBjYXNlIHRoZSAhWDg2IGhlcmUgd291bGQNCj4gd2FudCBsZWF2aW5n IG91dDsgdGhlIGRlc2NyaXB0aW9uIHRoZW4gd291bGQgd2FudCB0byBjbGFyaWZ5IHRoYXQgbWFr aW5nDQo+IHg4NiByZXNwZWN0IHRoZSBvcHRpb24gaXMgYSBUT0RPIGl0ZW0gKHBvc3NpYmx5IHBh cnQgb2YgdGhlIGh5cGVybGF1bmNoDQo+IGVmZm9ydCkuDQo+DQo+IEluIHRoZSBmb3JtZXIgY2Fz ZSBtb3JlIHF1ZXN0aW9ucyBhcmlzZSwgbGlrZSB3aHkgdGhpcyB3YW50cyB0byBiZSBhDQo+IGNv bW1vbiBvcHRpb24gaW4gdGhlIGZpcnN0IHBsYWNlLiAoQnV0IHNpbmNlIGZyb20gYW4gYWJzdHJh Y3QgcG92IHRoaXMgaXMNCj4gYSBjb21tb24gY2hvaWNlLCB0aGlzIGNhc2UgbGlrZWx5IGRvZXNu J3Qgd2FudCBwdXJzdWluZyBhbnl3YXkuKQ0KDQoNCkknbSBnb2luZyB0byBrZWVwIHRoZSBvcHRp b24gaW4gY29tbW9uIEtjb25maWcsIHdpdGggQXJtIGFuZCB4ODYNCnNlbGVjdGluZyBIQVNfRE9N MCwgYW5kIHJlbW92ZSAhWDg2IGZyb20gdGhlIGV4cGVydCBwcm9tcHQuIEknbSBhbHNvDQpnb2lu ZyB0byBleHBsYWluIGluIHRoZSBoZWxwIHRleHQgYW5kIGNvbW1pdCBtZXNzYWdlIHRoYXQgaW1w bGVtZW50aW5nDQp0aGUgb3B0aW9uIG9uIHg4NiByZW1haW5zIGEgVE9ETywgcG90ZW50aWFsbHkg YXMgcGFydCBvZiBIeXBlcmxhdW5jaC4NCg0KV2l0aCB0aGlzIHJldmlzaW9uLCB4ODYgd2lsbCBz dGlsbCBidWlsZCBhbmQgYm9vdCBsZWdhY3kgRG9tMCBldmVuIHdoZW4NCkRPTTBfQk9PVD1uLiBJ J20gZ29pbmcgdG8gcHJlc2VydmUgaXRzIERPTTBfTUVNIHNldHRpbmcgYW5kIGRvbTANCmNvbW1h bmQtbGluZSBwYXJzZXIgd2hpbGUgdGhhdCByZW1haW5zIHRoZSBjYXNlLg0KDQo+IEphbg== From xen-devel-bounces@lists.xenproject.org Mon Oct 26 14:57:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 14:57:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461457.1672467 (Exim 4.92) (envelope-from ) id 1xLM88-0000pU-3k; Mon, 26 Oct 2026 14:56:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461457.1672467; Mon, 26 Oct 2026 14:56: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 1xLM88-0000pN-1A; Mon, 26 Oct 2026 14:56:56 +0000 Received: by outflank-mailman (input) for mailman id 1461457; Mon, 26 Oct 2026 14:56:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLM87-0000pH-77 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 14:56:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLM86-007Tc5-8K for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:56:54 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6a30-bab6-0a2a0a5309dd-0a2a450c9032-22 for ; Mon, 26 Oct 2026 15:56:54 +0100 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf6a35-f479-0a2a450c0019-286b9f55a736-3 for ; Mon, 26 Oct 2026 15:56:54 +0100 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by AS8PR03MB8805.eurprd03.prod.outlook.com (2603:10a6:20b:53e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 14:56:51 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 14:56: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=FJZMKEvKB66oK71ApW0FeYed8/ZrESoURDheLPeyoxB4yOJWY2CoHrK3jyxCPWpLmeZFfjdb+I7hOoteuAEznZcNUR5kQ3man4WjFpx/eOVrCCtAoUbfa+ZVAvjtqatwQapJUIjvDQ2y8cSYyvdCVtCaBUDioYW1v6mg3D8B64i7zK5nYEASsKWkPumhIzLyG5WPcboPnh/IGLm3ZRYbjGddajyuyGApT79u64/3Jj2iE29qRfTW04VCE00/fW1XogENWR1VzaS9OkSTaRPtlxV6aeKxQA/eIlNcoQOML9+uwnFmRkwpfS8KaqQ5nElWwpD4LUPvaV5voXI4tPCwlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SOMWKkz0ULDbHMNFW8NRN3y9WQvoJjDCfNdHGVKYAkA=; b=xFmoA0xOBFquXuijSSF5g6COn4/319atJA5rZIvNfV7M/ml6eBLne0sVJbhXOVL8oblm/2E6M8/ngoFslJH3omRTlcvPUNGwjDhCdI49ns2uMjmCXc0J4arcirqwJsumefGeLBmbv6cyNVQzoaAY/1cFm0jJ1yBHZ+As3hd/71KRSdw0zBg3g+WodhWrj8tQM3P9RORLqGBPkXqVsNLBpXtp2ENGDULcKGxxiPykeD/vhX33gVcYVDXv8YzWq0M1DiM1chCOrxWAbtXBz0UyFJlzfq91tjg4xDvN0OcMRQI+5KDSsGIGXbH3G9jqt7UuK+OMX1ysEgZ92ndwwYiDiA== 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=SOMWKkz0ULDbHMNFW8NRN3y9WQvoJjDCfNdHGVKYAkA=; b=osacA5C9ADWiyQsG+TGyALS7El2O6XBEJ9H5kuEaE9WlPc1IgKL9iKs+P0gORdn+T8J9yodRRFXlWyo5KKRJ5KM5CcKnJjuC/nVsmMSbf8R79lTfpKJ/Aoy1kss1AlDkYQUCLntBC4a8u/scMSevY4GRGOUBMtSfpDe0FtV9d+iZplI7oMpdoPFbiJQgPm87uWvYD/fBqv45Ivohki4yXApU9BTei8oDBmxUCBfNM6GNzhtljsF3WHTpRQ/J1L5l8uyrHaDnyuFBmXn92+Ipl3kysUoXog/w554dkNpPooyuMEMm7ZLsFSGSjFUhaTF8xdWqVRLmBqoZa0nAIFX74A== From: Oleksii Moisieiev To: "Orzel, Michal" , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Julien Grall , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Teddy Astie , Volodymyr Babchuk Subject: Re: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Topic: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Index: AQHdUnGcfnmLH64VckKy7OjAkXrKMLbwa0mAgB+kSQA= Date: Mon, 26 Oct 2026 14:56:51 +0000 Message-ID: <6b6b3754-cbfb-4d44-9435-9954bff46ed8@epam.com> References: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.git.oleksii_moisieiev@epam.com> <3aa383cb-5850-4975-8054-cade5afd38ea@amd.com> In-Reply-To: <3aa383cb-5850-4975-8054-cade5afd38ea@amd.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: GVXPR03MB11113:EE_|AS8PR03MB8805:EE_ x-ms-office365-filtering-correlation-id: b73e86b2-1769-4a12-7016-08df33715df8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|7416014|38070700021|261026140227099003|11063799006|4143699003|56012099006|261009223027099003|261021135927099003|261021121427099003|261022105027099003|261021123027099003|261022075727099003|10067099003|18002099003|22082099003|6133799003|261026121527099003; x-microsoft-antispam-message-info: lq/x/tzPTQfx+jVdEOls8J9VuDGjGy9vkiNLBBkbhDz7Sh0pj3lZfMapLFXsgK8jO2pmsdn92Nr8ev+sGpa38q8mrya7gkLfNNhMohKoYJb/Ws05RdtIbjl2isDd+75McDs7C8t4AJ53MMc8pQxFYEqfdmDEIdRJ9fyYBLbeSFcVFmQsyQMJxAeQdRul2VCfbPaC4agp7SKeVFLnR1Ordg1GXku88IqueoLyGIK/a/qbJuu4UMmnm4Ivk0j04Em8vPTDP4rENXBB80liFPze9WWDbjhUrduWE+WkKQCNJgBTQNE5susLrC+VYB2Zz7+dgLdtBYQggFaMJ37twRGnT9JSDcyzE5v1thhEJJI7kDXrtGJkVOaa+I8RLYjt21acPPQum/7dLysAwKFuvE7cPT6Yx4AGJlnwJsiQ89KnmypLrEBgD8sm7BVWBQbxaoaA8RruC4DlC8U1U8LMmYnQJ9ePVeXcRghU+A9ZPAatoox5FSmhqHodyMo/NBCiKJsCqbu+wTnIxTqNkVJKTMvZ08Xwe3IuBxqykkQIkaNGWWEyFPlJkuLQP3EEBQ70Ngfmxt7A3SPU5vNru7WN8jmh7C9yWt+6LfICUXwfoDt5AnYXsJzKGfyV8DUOpyPGMsGlkSzH2VrkNcA+UBpcncNgRS15JZ7gBGCXM3cJ8v+2U+tExHN0AK1n29RRKQetXkb+Xw8MANzfeLKSE4BP/c47La82mKeOWPJ7aatzlOxVl7A= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(7416014)(38070700021)(261026140227099003)(11063799006)(4143699003)(56012099006)(261009223027099003)(261021135927099003)(261021121427099003)(261022105027099003)(261021123027099003)(261022075727099003)(10067099003)(18002099003)(22082099003)(6133799003)(261026121527099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Z2p3ZXgwWWxpU3VBTFBqTlV4TEN1ODhZMlZnNGt4TlhFYWIxejFBUk5PRjNR?= =?utf-8?B?OEpWLzMzTnk3ZThvOWdWWnhmbUkxVnVEQTZQVkVtS2x4cDJQamJZa1paWjla?= =?utf-8?B?SFVad1dycGM5ZEUrRHJhS2pFY3F0aW5KblhCdVFlcHQwTk5xWGJqTkdmRERL?= =?utf-8?B?VUdWZ2NKWVJYLytNajVyUWI2NFpNUmlqcE40eXhsclh3b2hWOEZoUElWbHVn?= =?utf-8?B?ckl5clM4ODhVNllwby9oa3ZvS3NtdU9NelRwNWdXRmhCQXZGKzdldWtMeDg0?= =?utf-8?B?SUx3YVFyWm9ScW5WVC9leUVTMmN1bTFBaklvTFY4clc1SjY1TmR2dTlCQ3M4?= =?utf-8?B?VkpNUXhtWFlLcEpkWHk1dXA4UFNKTjE5YzFRTExYbVAxU1U5TkRNUmszTDkx?= =?utf-8?B?S3UvYitWM3p0R2R2MWJTaEMxclhyaWo3ZjlmTmRFaDBqaUpYYzlEci9yWWtt?= =?utf-8?B?NzJoTnhyNnIwbHk0WFhRS1RPd2J6c09ZekdISzZHRHBhcFl3UjU2NGlkU3Ja?= =?utf-8?B?RTlzdkJnVHNnNUNLWU5RQitIRTR1YkdoTWduaENYbFVObFd4Y1VQM0hNbEpZ?= =?utf-8?B?YTIxS01wckFBeVpWdDVndmtpaHJIZmlqWldTRG5XVmk0L3JBYnJrSDVEMG1n?= =?utf-8?B?aTF3dmQyUGlYUlgySi9MdTdkc2lZd2JURyttUXFvdmt3UlhMcEpGNUQ4RDlR?= =?utf-8?B?ZHo0MmJJckJIZGEyVjFocUhiaEhnTmRkOHVmOS85N3NGNHF5OHhtUllYeW1o?= =?utf-8?B?VnF1M05mNnpzdFVFNzVXb3Q2VGE4aGhteDlJLytzZVRrUFVMM1BzTTAwUXNC?= =?utf-8?B?bml1YzBvZUZZQVN6b1F3RzJOWnRjMjg5TnhUY0dEN1lXZWJrcGF6ai9ST2E5?= =?utf-8?B?cFdxTFZSTkcyMmVBVE9xamR6VDRoalBKNTRXazNiZW1PbXI2ZVMxdytiM29v?= =?utf-8?B?L3poN09hNjJmV3VObFRNNHRQTXR6MTNVbnJLT2NoQkpxRmpjSkkrQ094SXlr?= =?utf-8?B?VkVxN0UxeE16ZmNYbkhFWmN2NHRSTGliL21oUmxVZzk3VXlXZnJwOU5KS0JO?= =?utf-8?B?Y2wwSmFtaDk0eUZnWlAzRk81ZE1nUHg4WWd0dDlBTjM1eHMzLzlyZEJ0SE5E?= =?utf-8?B?T3Q3M0pVTHQwclB5R3poVjE0YUFiY1ZHeHlVamNFY0U1Q1paeHhubDBMY1JI?= =?utf-8?B?TkJGS3ZEYnNvUENNMVlxQnRKYUhUY2I3UndtalBuSHR5dHJrNVg0M2d6QmV6?= =?utf-8?B?QVliNkRPVE1ybG56SUU1emJjeVdGVjE3ZkxId0tSQ1V5QW5pT2pSa1k2MDBt?= =?utf-8?B?QlI4N1JnV0RMS08vbHhQSm9hS0htUnlBeGlsMUNYNlJ5SFR5RTlXdEJCTmRD?= =?utf-8?B?anZ5L0ZhRlQyZmU4ZXF0Z2RqVXBocVhIMHpXOEVIUFFyUXc4S0pWWGlHVDNT?= =?utf-8?B?eDFTam04K3UwMkg3bllYVFVlYnYwQnQwQ3BEcmlNcFZRSkVhRkZoTDZ5aElM?= =?utf-8?B?eEVOWkpMVEFCWEV0MnZVSFdTSlE5NU5JWk92V24zQzh6RktPVEI2M2VNTXJz?= =?utf-8?B?aVNDK0J2UTVrWDRlVThpQnEzVCtEN3ZiTVFBVyt6Wi9ZbVhPRnk0dzFDSlVL?= =?utf-8?B?bHI0dy9YYy9mWjZMWXpsSWZJSm0reWJUM3JaOFczNkNIZHU0d09QWVZGYWND?= =?utf-8?B?dHhhV3RvanZ5RXRGYnpVOUplTUV5ci9za2pIcnV1WW1BcW5Nc2NVRmdnV2dE?= =?utf-8?B?WitYcFNKdG5ySzFBS2sycWUyR0xvYkl2eDRmMWlaNm01aFJtQXJFUTBjWGpX?= =?utf-8?B?YjFORFNpVjRnRmJhVUxXRXFJVCtYV1F3M3UxbWhzNElJK0NUV3NtMlgrODhm?= =?utf-8?B?Sk51RzErQU9LeXVRTHZyZytVTEZlS3diZS9vZ2tMNXNZcitSWmprUndBYlVR?= =?utf-8?B?UnVlOGtXYmdlbGorazM2cnd4LzhhS1ErWFgzamNMdTBoODlPK0s5NERpV1JD?= =?utf-8?B?QWw0L2ZXeisybGVYOXVnWFVEWnFxZGJCWk1PTlU5eDdHbHVjcThwL2V0VFFl?= =?utf-8?B?d0IvQSttbC9pekM1QTh2UEpsSlg3Rkx1WDRtdk4yWGRqV2dXc1hrYmt2dHlj?= =?utf-8?B?b3hkUjYySWVhWUNlYks4U0tvcVBaVmdtb2YvdmlmTEhERnVFVmpuZmZjV3M0?= =?utf-8?B?djZqSlJmK3MzdkdIYTZRRjZLeVBKcXZFdUxTekdmbXRydHBEL2gvUWxsT1FY?= =?utf-8?B?OU8velZrT3pxcE9vNVRsUDV1Zk5CdFBpZFFVRlcrMjZZNmJRUmxITFRvNExk?= =?utf-8?B?bHVmNExXeFhtcGhPU0o3alhyU3Q4UnVLUWZrNExPVDlPSVdKTzlxU3pZaXpM?= =?utf-8?Q?x2NMuaOzZBz98CLw=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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b73e86b2-1769-4a12-7016-08df33715df8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 14:56:51.0704 (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: gX5FNIU/lL25QGv1ZRamR4lxUeCT4kfB5jG9dBtGqaeygBl4/ZXX+CllI8ZxR193jkzmgvlaqxhVnVh+tX5BuLXnTHiC1eVCMCWH9gYekFc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8805 X-purgate-ID: tlsNG-d25034/1793026614-51B35A5B-9C4AFCE8/10/78276251493 X-purgate-type: spam X-purgate-size: 13240 SGkgTWljaGFsLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIEknbSBwcmVwYXJpbmcgdjYgcmln aHQgbm93LiBNeSBwbGFucyBmb3IgdGhlIA0KY2hhbmdlcyBhcmUgb3V0bGluZWQgYmVsb3cuDQoN Ck9uIDA2LzEwLzIwMjYgMTQ6NDQsIE9yemVsLCBNaWNoYWwgd3JvdGU6DQo+DQo+IE9uIDAyLU9j dC0yNiAxNToyNiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBUaGlzIGNvbW1pdCBpbnRy b2R1Y2VzIGEgbmV3IEtjb25maWcgb3B0aW9uLCBgQ09ORklHX0RPTTBfQk9PVGAsIHRvDQo+PiBh bGxvdyBmb3IgYnVpbGRpbmcgWGVuIHdpdGhvdXQgc3VwcG9ydCBmb3IgYm9vdGluZyBhIHJlZ3Vs YXIgZG9tYWluIChEb20wKS4NCj4+IFRoaXMgZnVuY3Rpb25hbGl0eSBpcyBwcmltYXJpbHkgaW50 ZW5kZWQgZm9yIHRoZSBBUk0gYXJjaGl0ZWN0dXJlLg0KPj4NCj4+IEEgbmV3IEtjb25maWcgc3lt Ym9sLCBgSEFTX0RPTTBgLCBoYXMgYmVlbiBhZGRlZCBhbmQgaXMgc2VsZWN0ZWQgYnkNCj4+IGRl ZmF1bHQgZm9yIEFSTSBhbmQgWDg2IGFyY2hpdGVjdHVyZS4gVGhpcyBzeW1ib2wgc2lnbmlmaWVz IHRoYXQgYW4NCj4+IGFyY2hpdGVjdHVyZSBoYXMgdGhlIGNhcGFiaWxpdHkgdG8gc3VwcG9ydCBh IERvbTAuDQo+Pg0KPj4gVGhlIGBET00wX0JPT1RgIG9wdGlvbiBkZXBlbmRzIG9uIGBIQVNfRE9N MGAgYW5kIGRlZmF1bHRzIHRvICd5Jy4gRm9yDQo+PiBleHBlcnQgdXNlcnMsIHRoaXMgb3B0aW9u IGNhbiBiZSBkaXNhYmxlZCAoYENPTkZJR19FWFBFUlQ9eWAgYW5kIG5vDQo+PiBgQ09ORklHX0RP TTBfQk9PVGAgaW4gdGhlIGNvbmZpZyksIHdoaWNoIHdpbGwgY29tcGlsZSBvdXQgdGhlIERvbTAN Cj4+IGNyZWF0aW9uIGNvZGUgb24gQVJNLiBUaGlzIGlzIHVzZWZ1bCBmb3IgZW1iZWRkZWQgb3Ig ZG9tMGxlc3Mtb25seQ0KPj4gc2NlbmFyaW9zIHRvIHJlZHVjZSBiaW5hcnkgc2l6ZSBhbmQgY29t cGxleGl0eS4NCj4+DQo+PiBUaGUgQVJNIGJvb3QgcGF0aCBoYXMgYmVlbiB1cGRhdGVkIHRvIHBh bmljIGlmIGl0IGRldGVjdHMgYSBub24tZG9tMGxlc3MNCj4+IGNvbmZpZ3VyYXRpb24gd2hpbGUg YENPTkZJR19ET00wX0JPT1RgIGlzIGRpc2FibGVkLCBwcmV2ZW50aW5nIGFuIGludmFsaWQNCj4+ IGJvb3QuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogT2xla3NpaSBNb2lzaWVpZXYgPG9sZWtzaWlf bW9pc2llaWV2QGVwYW0uY29tPg0KPj4gQWNrZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz dXNlLmNvbT4NCj4+DQo+PiAtLS0NCj4+DQo+PiBDaGFuZ2VzIGluIHY1Og0KPj4gLSByZWJhc2Vk IG9uIHRvcCBvZiB0aGUgbGF0ZXN0IHN0YWdpbmcuDQo+PiAtIGFkZCBBY2sNCj4+DQo+PiBDaGFu Z2VzIGluIHY0Og0KPj4gLSBjaGFuZ2UgTWlzcmEgcnVsZSB0byAyLjEgZnJvbSAyLjIgaW4gZGVz Y3JpcHRpb24NCj4+IC0gcmVtb3ZlIGV4dHJhIGRlcGVuZGVuY2llcyBmb3IgQVJNIGFyY2hpdGVj dHVyZSBmcm9tIERPTTBfQk9PVA0KPj4gLSByZXBocmFzZSBET00wX0JPT1QgaGVscCBieSBhZGRp bmcgaHlwZXJsYXVuY2gNCj4+IC0gRE9NMF9CT09UIGlzIG1hbmRhdG9yeSBmb3IgeDg2IGFyY2hp dGVjdHVyZQ0KPj4NCj4+IENoYW5nZXMgaW4gdjM6DQo+PiAtIHJlcGhyYXNlIGVycm9yIG1lc3Nh Z2Ugd2hlbiBkb20wbGVzcyBtb2RlIHdhc24ndCBkZXRlY3RlZCB3aGlsZSBkb20wDQo+PiBpcyBk aXNhYmxlZC4NCj4+IC0gcmVwaHJhc2UgaGVscCBtZXNzYWdlIGZvciBET00wX0JPT1QgY29uZmln IG9wdGlvbg0KPj4gLSB1cGRhdGUgRE9NMF9CT09UIGRlcGVuZGVuY2llcyBmb3IgWDg2DQo+Pg0K Pj4gQ2hhbmdlcyBpbiB2MjoNCj4+IC0gZGVjaWRlZCBub3QgdG8gcmVuYW1lIEhBU19ET00wIChI QVNfT1BUSU9OQUxfRE9NMCB3YXMgYW5vdGhlciBvcHRpb24NCj4+IHN1Z2dlc3RlZCBpbiBNTCkg YmVjYXVzZSBpbiB0aGlzIGNhc2UgSEFTX0RPTTBMRVNTIHNob3VsZCBiZSByZW5hbWVkDQo+PiBl aXRoZXIuDQo+PiAtIGZpeCBvcmRlciBvZiBIQVNfRE9NMCBjb25maWcgcGFyYW1ldGVyDQo+PiAt IGFkZCBIQVNfRE9NMCBvcHRpb24gdG8geDg2IGFyY2hpdGVjdHVyZS4NCj4+DQo+PiBDT05GSUdf RE9NMF9CT09UIEtjb25maWcgb3B0aW9uIHdhcyBpbnRyb2R1Y2VkIHRvIG1ha2UgdGhlIERvbTAN Cj4+IHJlZ3VsYXIgKGxlZ2FjeSkgZG9tYWluIGFuIG9wdGlvbmFsIGZlYXR1cmUgdGhhdCBjYW4g YmUgY29tcGlsZWQgb3V0DQo+PiBmcm9tIHRoZSBYZW4gaHlwZXJ2aXNvciBidWlsZC4NCj4+DQo+ PiBUaGUgcHJpbWFyeSBtb3RpdmF0aW9uIGZvciB0aGlzIGNoYW5nZSBpcyB0byBlbmhhbmNlIG1v ZHVsYXJpdHkgYW5kDQo+PiBwcm9kdWNlIGEgY2xlYW5lciwgbW9yZSBzcGVjaWFsaXplZCBoeXBl cnZpc29yIGJpbmFyeSB3aGVuIGEgY29udHJvbA0KPj4gZG9tYWluIGlzIG5vdCBuZWVkZWQuIElu IG1hbnkgZW1iZWRkZWQgb3IgZGVkaWNhdGVkIHN5c3RlbXMsIFhlbiBpcw0KPj4gdXNlZCBpbiBh ICJkb20wbGVzcyIgY29uZmlndXJhdGlvbiB3aGVyZSBndWVzdHMgYXJlIHByZS1jb25maWd1cmVk IGFuZA0KPj4gbGF1bmNoZWQgZGlyZWN0bHkgYnkgdGhlIGh5cGVydmlzb3IuIEluIHRoZXNlIHNj ZW5hcmlvcywgdGhlIGVudGlyZQ0KPj4gc3Vic3lzdGVtIGZvciBib290aW5nIGFuZCBtYW5hZ2lu ZyBEb20wIGlzIHVubmVjZXNzYXJ5Lg0KPj4NCj4+IFRoaXMgYXBwcm9hY2ggYWxpZ25zIHdpdGgg c29mdHdhcmUgcXVhbGl0eSBzdGFuZGFyZHMgbGlrZSBNSVNSQSBDLA0KPj4gd2hpY2ggYWR2b2Nh dGUgZm9yIHRoZSByZW1vdmFsIG9mIHVucmVhY2hhYmxlIG9yIHVubmVjZXNzYXJ5IGNvZGUgdG8N Cj4+IGltcHJvdmUgc2FmZXR5IGFuZCBtYWludGFpbmFiaWxpdHkuIFNwZWNpZmljYWxseSwgdGhp cyBjaGFuZ2UgaGVscHMgYWRoZXJlIHRvOg0KPj4NCj4+IE1JU1JBIEM6MjAxMiAgUnVsZSAyLjE6 ICJBIHByb2plY3Qgc2hhbGwgbm90IGNvbnRhaW4gdW5yZWFjaGFibGUgY29kZSINCj4gQnV0IHdp dGggdGhpcyBwYXRjaCB5b3Ugd2lsbCBpbnRyb2R1Y2UgYSBsb3Qgb2YgdW5yZWFjaGFibGUgY29k ZSBhbnl3YXkuDQoNCkknbSBnb2luZyB0byByZW1vdmUgdGhlIHN0YXRlbWVudCB0aGF0IHRoZSBw YXRjaCBlbGltaW5hdGVzIGFsbA0KdW5yZWFjaGFibGUgY29kZSBvciBlc3RhYmxpc2hlcyBNSVNS QSBjb21wbGlhbmNlLiBUaGUgZGVzY3JpcHRpb24gd2lsbA0KaW5zdGVhZCBleHBsYWluIHRoYXQg aXQgZXhjbHVkZXMgbGVnYWN5IERvbTAgY29uc3RydWN0aW9uIGFuZCBpdHMNCnByaXZhdGUgYm9v dCBvcHRpb25zLiBTaGFyZWQgZG9tYWluLWJ1aWxkaW5nIGNvZGUgd2lsbCByZW1haW4sIHNpbmNl DQppdCBpcyBhbHNvIHVzZWQgYnkgZG9tMGxlc3MgZ3Vlc3RzLiBJcyB0aGF0IHNjb3BlIE9LPw0K DQo+PiBJbiBhIGJ1aWxkIGNvbmZpZ3VyZWQgZm9yIGEgZG9tMGxlc3MgZW52aXJvbm1lbnQsIHRo ZSBjb2RlIHJlc3BvbnNpYmxlDQo+PiBmb3IgY3JlYXRpbmcgRG9tMCB3b3VsZCBiZSBjb25zaWRl cmVkICJkZWFkIGNvZGUiIGFzIGl0IHdvdWxkIG5ldmVyIGJlDQo+PiBleGVjdXRlZC4gQnkgdXNp bmcgdGhlIHByZXByb2Nlc3NvciB0byByZW1vdmUgaXQgYmVmb3JlIGNvbXBpbGF0aW9uLA0KPj4g d2UgZW5zdXJlIHRoYXQgdGhlIGZpbmFsIGV4ZWN1dGFibGUgaXMgZnJlZSBmcm9tIHRoaXMgdW5y ZWFjaGFibGUNCj4+IGNvZGUuIFRoaXMgc2ltcGxpZmllcyBzdGF0aWMgYW5hbHlzaXMsIHJlZHVj ZXMgdGhlIGF0dGFjayBzdXJmYWNlLA0KPj4gYW5kIG1ha2VzIHRoZSBjb2RlYmFzZSBlYXNpZXIg dG8gdmVyaWZ5LCB3aGljaCBpcyBjcml0aWNhbCBmb3INCj4+IHN5c3RlbXMgcmVxdWlyaW5nIGhp Z2ggbGV2ZWxzIG9mIHNhZmV0eSBhbmQgc2VjdXJpdHkuDQo+Pg0KPj4gLS0tDQo+PiAgIHhlbi9h cmNoL2FybS9LY29uZmlnICAgICAgICB8ICAxICsNCj4+ICAgeGVuL2FyY2gvYXJtL2RvbWFpbl9i dWlsZC5jIHwgIDggKysrKysrKysNCj4+ICAgeGVuL2FyY2gvYXJtL3NldHVwLmMgICAgICAgIHwg MTMgKysrKysrKysrKy0tLQ0KPj4gICB4ZW4vYXJjaC94ODYvS2NvbmZpZyAgICAgICAgfCAgMSAr DQo+PiAgIHhlbi9jb21tb24vS2NvbmZpZyAgICAgICAgICB8IDEyICsrKysrKysrKysrKw0KPj4g ICA1IGZpbGVzIGNoYW5nZWQsIDMyIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pDQo+Pg0K Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9LY29uZmlnIGIveGVuL2FyY2gvYXJtL0tjb25m aWcNCj4+IGluZGV4IDA2Mjg5MDA1ZjQuLjZkMDkzNmIzNTMgMTAwNjQ0DQo+PiAtLS0gYS94ZW4v YXJjaC9hcm0vS2NvbmZpZw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL0tjb25maWcNCj4+IEBAIC0x OCw2ICsxOCw3IEBAIGNvbmZpZyBBUk0NCj4+ICAgCXNlbGVjdCBHRU5FUklDX1VBUlRfSU5JVA0K Pj4gICAJc2VsZWN0IEhBU19BTFRFUk5BVElWRSBpZiBIQVNfVk1BUA0KPj4gICAJc2VsZWN0IEhB U19ERVZJQ0VfVFJFRV9ESVNDT1ZFUlkNCj4+ICsJc2VsZWN0IEhBU19ET00wDQo+PiAgIAlzZWxl Y3QgSEFTX0RPTTBMRVNTDQo+PiAgIAlzZWxlY3QgSEFTX0dSQU5UX0NBQ0hFX0ZMVVNIIGlmIEdS QU5UX1RBQkxFDQo+PiAgIAlzZWxlY3QgSEFTX1NIQVJFRF9JTkZPDQo+PiBkaWZmIC0tZ2l0IGEv eGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jIGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5j DQo+PiBpbmRleCA3MmQ1MzE2MTgwLi5jYzkzMmQ3Njg2IDEwMDY0NA0KPj4gLS0tIGEveGVuL2Fy Y2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxk LmMNCj4+IEBAIC00Myw4ICs0MywxMCBAQA0KPj4gICAjaW5jbHVkZSA8YXNtL2dyYW50X3RhYmxl Lmg+DQo+PiAgICNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+DQo+PiAgIA0KPj4gKyNpZmRlZiBDT05G SUdfRE9NMF9CT09UDQo+PiAgIHN0YXRpYyB1bnNpZ25lZCBpbnQgX19pbml0ZGF0YSBvcHRfZG9t MF9tYXhfdmNwdXM7DQo+PiAgIGludGVnZXJfcGFyYW0oImRvbTBfbWF4X3ZjcHVzIiwgb3B0X2Rv bTBfbWF4X3ZjcHVzKTsNCj4+ICsjZW5kaWYNCj4gV2hhdCBhYm91dCB0aGUgb3RoZXIgZG9tMC1v bmx5IG9wdGlvbnM6IGRvbTBfbWVtIChhbmQgQ09ORklHX0RPTTBfTUVNKSwNCj4gZG9tMC1sbGMt Y29sb3JzIGFuZCBkb20wPXN2ZT8NCkknbSBnb2luZyB0byBndWFyZCBBcm0ncyBkb20wX21lbSBz dG9yYWdlIGFuZCBwYXJzZXIgd2l0aA0KQ09ORklHX0RPTTBfQk9PVCBhbmQgbWFrZSBET00wX01F TSBkZXBlbmQgb24gRE9NMF9CT09UIHx8IFg4Ni4gVGhlIHg4Ng0KZXhjZXB0aW9uIHByZXNlcnZl cyBpdHMgY3VycmVudCBiZWhhdmlvciB1bnRpbCBpdCBpbXBsZW1lbnRzIHRoZQ0Kb3B0aW9uLCBh cyBkaXNjdXNzZWQgaW4gbXkgcmVwbHkgdG8gSmFuLg0KDQpGb3IgZG9tMD1zdmUsIEknbSBnb2lu ZyB0byBndWFyZCBBcm0ncyBhcmNoaXRlY3R1cmUtc3BlY2lmaWMgRG9tMA0KcGFyc2VyIGFuZCBv cHRfZG9tMF9zdmUsIGFuZCBleGNsdWRlIHRoZSBjb21tb24gZG9tMCBwYXJhbWV0ZXINCnJlZ2lz dHJhdGlvbiBvbiBBcm0gd2hlbiBET00wX0JPT1Q9bi4gR3Vlc3QgU1ZFIHN1cHBvcnQgd2lsbCBy ZW1haW4NCmF2YWlsYWJsZSwgYW5kIG90aGVyIGFyY2hpdGVjdHVyZXMgd2lsbCBrZWVwIHRoZWly IGV4aXN0aW5nIHBhcnNlcg0KYmVoYXZpb3IuDQoNCkZvciBkb20wLWxsYy1jb2xvcnMsIEknbSBn b2luZyB0byBndWFyZCB0aGUgcHJpdmF0ZSBEb20wIGNvbG9yIGFycmF5cw0KYW5kIHBhcmFtZXRl ciBwYXJzZXIgd2l0aCBDT05GSUdfRE9NMF9CT09ULiBYZW4gY29sb3JpbmcgYW5kIGd1ZXN0DQpj b2xvcmluZyB3aWxsIHJlbWFpbiBhdmFpbGFibGUuDQo+PiAgIA0KPj4gICAvKg0KPj4gICAgKiBJ ZiB0cnVlLCB0aGUgZXh0ZW5kZWQgcmVnaW9ucyBzdXBwb3J0IGlzIGVuYWJsZWQgZm9yIGRvbTAg YW5kDQo+PiBAQCAtMTIzLDYgKzEyNSw3IEBAIHBhZGRyX3QgX19pbml0IGh3ZG9tX2dldF9mZHRf YWxsb2Nfc2l6ZSh2b2lkKQ0KPj4gICAgICAgcmV0dXJuIEFDUElfRE9NMF9GRFRfTUlOX1NJWkU7 DQo+PiAgIH0NCj4+ICAgDQo+PiArI2lmZGVmIENPTkZJR19ET00wX0JPT1QNCj4+ICAgdW5zaWdu ZWQgaW50IF9faW5pdCBkb20wX21heF92Y3B1cyh2b2lkKQ0KPj4gICB7DQo+PiAgICAgICBpZiAo IG9wdF9kb20wX21heF92Y3B1cyA9PSAwICkNCj4+IEBAIC0xMzUsNiArMTM4LDcgQEAgdW5zaWdu ZWQgaW50IF9faW5pdCBkb20wX21heF92Y3B1cyh2b2lkKQ0KPj4gICANCj4+ICAgICAgIHJldHVy biBvcHRfZG9tMF9tYXhfdmNwdXM7DQo+PiAgIH0NCj4+ICsjZW5kaWYNCj4+ICAgDQo+PiAgIC8q DQo+PiAgICAqIEluc2VydCB0aGUgZ2l2ZW4gcGFnZXMgaW50byBhIG1lbW9yeSBiYW5rLCBiYW5r cyBhcmUgb3JkZXJlZCBieSBhZGRyZXNzLg0KPj4gQEAgLTE4NjIsNiArMTg2Niw3IEBAIGludCBf X2luaXQgY29uc3RydWN0X2RvbWFpbihzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qga2VybmVsX2lu Zm8gKmtpbmZvKQ0KPj4gICAgICAgcmV0dXJuIDA7DQo+PiAgIH0NCj4+ICAgDQo+PiArI2lmZGVm IENPTkZJR19ET00wX0JPT1QNCj4+ICAgc3RhdGljIGludCBfX2luaXQgY29uc3RydWN0X2RvbTAo c3RydWN0IGRvbWFpbiAqZCkNCj4gVGhpcyBtYWtlcyBkb20wX3NldF9sbGNfY29sb3JzKCkgdW5y ZWFjaGFibGUuIFRoZSBzYW1lIGdvZXMgZm9yDQo+IHByZXBhcmVfYWNwaSgpIHdpdGggQUNQST15 LCBhcyBkb20wbGVzcyBpcyBEVCBvbmx5LiBBQ1BJIHNob3VsZCBiZSBwcmV2ZW50ZWQNCj4gd2hl biBET00wX0JPT1Q9bi4NCg0KSSdtIGdvaW5nIHRvIGd1YXJkIGRvbTBfc2V0X2xsY19jb2xvcnMo KSB3aXRoIENPTkZJR19ET00wX0JPT1QgYXMgd2VsbCwNCndoaWxlIHJldGFpbmluZyB0aGUgY29s b3JpbmcgaGVscGVycyB1c2VkIGJ5IGRvbTBsZXNzIGd1ZXN0cyBhbmQNCnJ1bnRpbWUgZG9tYWlu IGNvbmZpZ3VyYXRpb24uDQoNCkknbSBhbHNvIGdvaW5nIHRvIGFkZCBET00wX0JPT1QgdG8gdGhl IGRlcGVuZGVuY2llcyBvZiBBcm0ncyBBQ1BJDQpvcHRpb24uIFRoYXQgcHJldmVudHMgQUNQST15 IHdoZW4gRE9NMF9CT09UPW4gYW5kIGV4Y2x1ZGVzIHRoZSBBcm0gQUNQSQ0Kb2JqZWN0cywgaW5j bHVkaW5nIHByZXBhcmVfYWNwaSgpLCBmcm9tIHRob3NlIGJ1aWxkcy4gSXMgdGhhdCB0aGUNCnNl cGFyYXRpb24geW91IGhhZCBpbiBtaW5kPw0KDQo+PiAgIHsNCj4+ICAgICAgIHN0cnVjdCBrZXJu ZWxfaW5mbyBraW5mbyA9IEtFUk5FTF9JTkZPX0lOSVQ7DQo+PiBAQCAtMTg5Myw2ICsxODk4LDcg QEAgc3RhdGljIGludCBfX2luaXQgY29uc3RydWN0X2RvbTAoc3RydWN0IGRvbWFpbiAqZCkNCj4+ ICAgDQo+PiAgICAgICByZXR1cm4gY29uc3RydWN0X2h3ZG9tKCZraW5mbywgTlVMTCk7DQo+PiAg IH0NCj4+ICsjZW5kaWYNCj4+ICAgDQo+PiAgIGludCBfX2luaXQgY29uc3RydWN0X2h3ZG9tKHN0 cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSkNCj4+IEBAIC0xOTQ0LDYgKzE5NTAs NyBAQCBpbnQgX19pbml0IGNvbnN0cnVjdF9od2RvbShzdHJ1Y3Qga2VybmVsX2luZm8gKmtpbmZv LA0KPj4gICAgICAgcmV0dXJuIGNvbnN0cnVjdF9kb21haW4oZCwga2luZm8pOw0KPj4gICB9DQo+ PiAgIA0KPj4gKyNpZmRlZiBDT05GSUdfRE9NMF9CT09UDQo+PiAgIHZvaWQgX19pbml0IGNyZWF0 ZV9kb20wKHZvaWQpDQo+PiAgIHsNCj4+ICAgICAgIHN0cnVjdCBkb21haW4gKmRvbTA7DQo+PiBA QCAtMjAwMSw2ICsyMDA4LDcgQEAgdm9pZCBfX2luaXQgY3JlYXRlX2RvbTAodm9pZCkNCj4+ICAg DQo+PiAgICAgICBzZXRfeHNfZG9tYWluKGRvbTApOw0KPj4gICB9DQo+PiArI2VuZGlmIC8qIENP TkZJR19ET00wX0JPT1QgKi8NCj4+ICAgDQo+PiAgIC8qDQo+PiAgICAqIExvY2FsIHZhcmlhYmxl czoNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vc2V0dXAuYyBiL3hlbi9hcmNoL2FybS9z ZXR1cC5jDQo+PiBpbmRleCAxNmY4OTlkZmY1Li5lYTljMDM3ZmJhIDEwMDY0NA0KPj4gLS0tIGEv eGVuL2FyY2gvYXJtL3NldHVwLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9zZXR1cC5jDQo+PiBA QCAtNDkxLDExICs0OTEsMTggQEAgdm9pZCBhc21saW5rYWdlIF9faW5pdCBub3JldHVybiBzdGFy dF94ZW4odW5zaWduZWQgbG9uZyBmZHRfcGFkZHIpDQo+PiAgIA0KPj4gICAgICAgZG9faW5pdF9i b290dGVzdHMoKTsNCj4+ICAgDQo+PiAtICAgIC8qIENyZWF0ZSBpbml0aWFsIGRvbWFpbiAwLiAq Lw0KPj4gLSAgICBpZiAoICFpc19kb20wbGVzc19tb2RlKCkgKQ0KPj4gKyAgICBpZiAoIElTX0VO QUJMRUQoQ09ORklHX0RPTTBfQk9PVCkgJiYgIWlzX2RvbTBsZXNzX21vZGUoKSApDQo+PiArICAg IHsNCj4+ICsgICAgICAgIC8qIENyZWF0ZSBpbml0aWFsIGRvbWFpbiAwLiAqLw0KPj4gICAgICAg ICAgIGNyZWF0ZV9kb20wKCk7DQo+PiArICAgIH0NCj4+ICAgICAgIGVsc2UNCj4+IC0gICAgICAg IHByaW50ayhYRU5MT0dfSU5GTyAiWGVuIGRvbTBsZXNzIG1vZGUgZGV0ZWN0ZWRcbiIpOw0KPj4g KyAgICB7DQo+PiArICAgICAgICBpZiAoIGlzX2RvbTBsZXNzX21vZGUoKSkNCj4gTWlzc2luZyBz cGFjZSBhZnRlciAoKSBhbmQgYmVmb3JlICkNCnRoYW5rIHlvdS4gd2lsbCBmaXguDQo+PiArICAg ICAgICAgICAgcHJpbnRrKFhFTkxPR19JTkZPICJYZW4gZG9tMGxlc3MgbW9kZSBkZXRlY3RlZFxu Iik7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAgICAgICAgcGFuaWMoIk5laXRoZXIgZG9t MCBub3IgZG9tMGxlc3MgbW9kZSB3YXMgZGV0ZWN0ZWQsIGFib3J0aW5nXG4iKTsNCj4+ICsgICAg fQ0KPiBUbyBhdm9pZCBjYWxsaW5nIGlzX2RvbTBsZXNzX21vZGUoKSB0d2ljZSwgaG93IGFib3V0 Og0KPg0KPiAgICAgIGlmICggaXNfZG9tMGxlc3NfbW9kZSgpICkNCj4gICAgICAgICAgcHJpbnRr KFhFTkxPR19JTkZPICJYZW4gZG9tMGxlc3MgbW9kZSBkZXRlY3RlZFxuIik7DQo+ICAgICAgZWxz ZSBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0RPTTBfQk9PVCkgKQ0KPiAgICAgICAgICBjcmVhdGVf ZG9tMCgpOw0KPiAgICAgIGVsc2UNCj4gICAgICAgICAgcGFuaWMoIk5laXRoZXIgZG9tMCBub3Ig ZG9tMGxlc3MgbW9kZSB3YXMgZGV0ZWN0ZWQsIGFib3J0aW5nXG4iKTsNClRoYW5rIHlvdSBmb3Ig dGhlIHN1Z2dlc3Rpb24uIEkgd2lsbCB1c2UgdGhpcyBhcHByb2FjaC4gV2lsbCBhbHNvIHJlbW92 ZSANCmV4dHJhIGJyYWNlcyBzdWdnZXN0ZWQgYnkgSmFuLg0KPiB+TWljaGFsDQoNCg0KSSBoYXZl IGNoZWNrZWQgdGhlIHByb3Bvc2VkIGltcGxlbWVudGF0aW9uIHdpdGggdGhlIGZvdXIgQXJtNjQN CkRPTTBfQk9PVC9ET00wTEVTU19CT09UIGNvbWJpbmF0aW9ucywgd2l0aCBTVkUgYW5kIExMQyBj b2xvcmluZyBlbmFibGVkDQphbmQgQUNQSSByZXF1ZXN0ZWQuIEkgYWxzbyBjaGVja2VkIEFybTMy IHdpdGggRG9tMCBlbmFibGVkIGFuZCBkaXNhYmxlZCwNCmFuZCB4ODYgd2l0aCBib3RoIERPTTBf Qk9PVCBzZXR0aW5ncy4NCg0KQmVzdCByZWdhcmRzLA0KT2xla3NpaQ0K From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:13:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:13:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461466.1672476 (Exim 4.92) (envelope-from ) id 1xLMNw-00049x-E3; Mon, 26 Oct 2026 15:13:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461466.1672476; Mon, 26 Oct 2026 15: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 1xLMNw-00049q-Am; Mon, 26 Oct 2026 15:13:16 +0000 Received: by outflank-mailman (input) for mailman id 1461466; Mon, 26 Oct 2026 15:13:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLMNv-00049k-Ak for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:13:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMNu-0019i9-8e for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:13:14 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6e08-e002-0a2a0a5209dd-0a2a45088cf0-4 for ; Mon, 26 Oct 2026 16:13:14 +0100 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 6adf6e09-f659-0a2a45080019-b9ff1c22aa8f-3 for ; Mon, 26 Oct 2026 16:13:14 +0100 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 1a178c5c430000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:13:09 +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 52D2880B3A; Mon, 26 Oct 2026 16:13:08 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=iatSUdW2mlO9nQz8JRk1LDg4FfK4DpBAe1GEKe6muPs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=GMvy9vJUqtCxfEfakizbuJeM1xmX1leMgUmb9IiY/6ij7dbJgTRnS6jo6HluH/8QSC1e0LlsI 3PUu4X/wRZYoqFJEhJkE3Lq4+7P3hp6i+cYzmimM32g2jqMP5tHInrdzhDzT+WQwBskcg7lkBAH LuGeieBbSS/A3q1P2cAip09i73ELVtvR6aXrd2aaXch7t7BR3fTAMDjVze5FWK7UO2PPqmBj3eZ qv50ISx27cfdyOlCL2BffC87w/vIZLO7idvsoVpIBmaZIeRQ3E7pKlrvMIOOQ0zczLrNQqwpPUh 8R5I2kik7LQwFAf29oTkBICG5CCqhii18X+uAjilvOVA== X-Zone-Loop: 7b922eb86e50017a5dc0b769ff6f8a83e75e26b98bf1 x-campaign-type: default x-transaction-id: 9ee35364-d986-47ef-a1a0-5066cd8a31e8 x-swg-uid: 01-6001e8c7-95bc-46a1-b4dc-e93032f0e406 X-Mailer: Sweego Message-ID: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> x-swg-bid: 1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v8 0/5] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Mon, 26 Oct 2026 16:12:57 +0100 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=1793027331; l=6170; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=+ygeDYlhAEEZb/ne4HCijBBafqK3Z6fn8WKd2M5jn04=; b=rCTs1bTJQ+s5LttaXKZ/r3gfsb/kYswFDVmNWdNrl0HUwUo6pzOgGt3A+WzrrPP2qMZ1d/ib6 Wsv24Yx7Z08BVquMDmgTePIDNFly9VyIlkt0sr+p8CM+nDiW4HKb0mF 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: 1793027588540 X-purgate-ID: tlsNG-c1860d/1793027594-D574B87B-78773A5A/0/0 X-purgate-type: clean X-purgate-size: 6172 This series introduces bug 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: Use pte_is_valid() in pte_is_mapping() 2: Fix A/D bits in Xen's page-table mappings 3: Look up the exception table for any trap taken in Xen context 4: Probe the A/D update scheme if the DT advertises neither Svade nor Svadu 5: Rework the A/D bits comment in p2m_set_pte_flags() Patch 3 is a subset of "xen/riscv: look up the exception table for any trap taken in Xen context" from Oleksii's vAPLIC/vIMSIC series, without the parts depending on earlier patches of that series. Test CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2990357496 --- Changes since v7: - Replace the panic when the DTS advertises neither Svade nor Svadu with a probe of the A/D update scheme in that case only, recording the probed extension so that such device trees can be used as-is. The device tree is trusted otherwise, as discussed with Jan (patch 4). - Add patch 3, so that the store page fault raised by the probe on Svade hardware is fixed up. - Move the p2m_set_pte_flags() comment rework last (patch 5). - Collect trailers: A-by on patches 1 and 2, T-by on patch 2 and R-by on patch 5. - Link to v7: https://patch.msgid.link/1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech --- Changes since v6: - Drop the boot time probe of the A/D update scheme and trust the device tree. Xen now panics when the DTS advertises neither Svade nor Svadu (patch 3). - Patch 4 no longer changes when A/D are preset, it only reworks the comment, since patch 3 guarantees the DTS advertises the scheme in effect. - Reorder the series so the already reviewed patches come first. - Patch 2: add a second Fixes tag for arch_pmap_map(). - Patch 1: rebase, as the reorder changed its context. - Link to v6: https://patch.msgid.link/1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech --- Changes since v5: - Replace "xen/riscv: always preset A/D bits in G-stage PTEs" with a boot time probe of the A/D update scheme (patch 1). It checks the result against the Svade/Svadu DT binding and records the probed scheme when the DT advertises neither, instead of trusting the DT alone. - Split the p2m_set_pte_flags() comment rework out into its own patch (patch 2). - Patches 3 and 4 unchanged and are waiting to be merged. - Link to v5: https://patch.msgid.link/1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech --- Changes since v4: - Drop patches merged upstream: ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"") - Collect trailers. - Rebase patches on top of staging. - Link to v4: https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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 --- Baptiste Le Duc (4): xen/riscv: use pte_is_valid() in pte_is_mapping() xen/riscv: fix A/D bits in Xen's page-table mappings xen/riscv: probe the A/D update scheme if the DT advertises neither xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() Oleksii Kurochko (1): xen/riscv: look up the exception table for any trap taken in Xen context xen/arch/riscv/cpufeature.c | 69 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 ++++--- xen/arch/riscv/include/asm/page.h | 35 +++++++++-------- xen/arch/riscv/mm.c | 11 +++--- xen/arch/riscv/p2m.c | 45 +++++++++------------ xen/arch/riscv/traps.c | 28 ++++++++++--- 6 files changed, 141 insertions(+), 60 deletions(-) --- base-commit: 46678752be2d97f61317d793408a59927a429847 change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:14:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:14:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461473.1672485 (Exim 4.92) (envelope-from ) id 1xLMPS-0004iY-Qm; Mon, 26 Oct 2026 15:14:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461473.1672485; Mon, 26 Oct 2026 15:14: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 1xLMPS-0004iR-Nx; Mon, 26 Oct 2026 15:14:50 +0000 Received: by outflank-mailman (input) for mailman id 1461473; Mon, 26 Oct 2026 15:14:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMPR-0004iJ-NE for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:14:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMPQ-003d5Y-PF for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:14:48 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6e59-8faa-0a2a0a5109dd-0a2a4508df58-40 for ; Mon, 26 Oct 2026 16:14:48 +0100 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 6adf6e68-f659-0a2a45080019-b9ff1c238a77-3 for ; Mon, 26 Oct 2026 16:14:48 +0100 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 1a178c7355f000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:14:43 +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 B3CBE815DF; Mon, 26 Oct 2026 16:14:42 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=wjEhviDbcT9pueHXVGdYgzTkA0vnOrtJ8lu8wj6hDgI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=cl/AkVMm6tuP7u2ff56WU60KpqsWkRBbcnUoEit04kHMoLtTV58dam7H8nYv2ApCxlYo8c9AD 48gmf94xX+JxzLM7ewUNrLKZAqMtn0r2/b2B6Y8iIBlP0OHIjwrCGp6D9JiuIbwspghD2bXtS0G n30shmqAUf42cL+uqJj1te5vRwC0ifgV9SQFAFTEFpFGinkfsbmpkngYzbP8qMlt7sz4uYlm+7y CfRXqzDiFl9VnAn287HwTHSGtxDg9En4QcBr/GGp2qqT3HQTJhDUhA6+Ch6ZvJes1tYJdtqH33A zAqD0FCK5XMYbY8MV2Vj7IoYSJxDpHAvoXQbWBzhD30Q== X-Zone-Loop: 2de933f4cb81fa1905198a0746675615d4f21e7a3708 x-campaign-type: default x-transaction-id: ae68d5d8-619e-46d3-81b7-56caea521fbd x-swg-uid: 01-6e1abd89-f7e5-4f1d-beea-d5ea9e4d58be X-Mailer: Sweego Message-ID: <1793027683.8631fc262581453bbf619ec5b2062170.1a178c7355f000f79f@vates.tech> x-swg-bid: 1793027683.8631fc262581453bbf619ec5b2062170.1a178c7355f000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v8 1/5] xen/riscv: use pte_is_valid() in pte_is_mapping() Date: Mon, 26 Oct 2026 16:14:33 +0100 In-Reply-To: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793027331; l=1365; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=TR/botraZWIEW3mqExx0XFYiNlY/hru2IatTX7DUjvI=; b=MoZU/esrYk8YjmKuafvbQM8nrTwtLuNkSuV1hWfopxzFcgMX0fALYWkhmyHKvDcOPooNm69dj nP9pZfb44pQBaCEiuZ2AVdT7/IWkyJ0Mm/OMD6j6Ea4U/C/jYQulQhr 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: 1793027682927 X-purgate-ID: tlsNG-c1860d/1793027688-CEF5F87B-57C29B8B/10/78276251493 X-purgate-type: spam X-purgate-size: 1367 Use pte_is_valid() instead of open-coding the PTE_VALID check. No functional change. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes since v7: - collect A-by. --- Changes since v6: - rebase, as moving the patch ahead in the series changed its context in pte_is_mapping(). --- Changes since v5: - no changes, already reviewed and waiting to be merged. --- Changes since v4: - rebase on top of staging. --- Changes since v3: - no changes. - add trailers. --- Changes since v2: - new patch. --- xen/arch/riscv/include/asm/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index b465a90325..c8bb334b85 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -187,7 +187,7 @@ static inline bool pte_is_mapping(pte_t p) /* See pte_is_table() */ ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); - return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); + return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); } static inline bool pte_is_superpage(pte_t p, unsigned int level) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:14:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:14:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461474.1672494 (Exim 4.92) (envelope-from ) id 1xLMPX-0004wW-11; Mon, 26 Oct 2026 15:14:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461474.1672494; Mon, 26 Oct 2026 15:14: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 1xLMPW-0004wO-UC; Mon, 26 Oct 2026 15:14:54 +0000 Received: by outflank-mailman (input) for mailman id 1461474; Mon, 26 Oct 2026 15:14:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMPV-0004vo-Q1 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:14:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMPV-00DhdS-6h for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:14:53 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6e6b-e002-0a2a0a5209dd-0a2a4508c308-2 for ; Mon, 26 Oct 2026 16:14:53 +0100 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 6adf6e68-f659-0a2a45080019-b9ff1c238a77-4 for ; Mon, 26 Oct 2026 16:14:53 +0100 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 1a178c7373e000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:14:44 +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 55E4D81DAB; Mon, 26 Oct 2026 16:14:43 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=BEakajGWIf4LAv0+KdHp6x8rDSwbOS2sEWIM5GTzxlI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=cBWH6k1M+xwapho8bUp5WAL+HJH0rH1z230l696ANNB9KQcvmY7zLKRbt0v7IexfAdgGJEoQm sY1rtBm7EaQkBKfo6jp5THQYIno1ZwA73+rFdoKunj8YdlyHYW3+9V81muGQ3jbfkPbolx4MKgp Q/pGc/p3OStjajel8SFd+764TuWk5lpeIZB6mCuhXGK4NL7R97Ig7oc3NhsFTkruJBKk3uWFpSi vuZPDuU0bxz0WBumf017DRMsugZi2CFCNQ51lhOXD+1BYasusz9cQwIlAgMmJBQVq0/+7IkKo93 zktGS69Zbb8RjHx5hEwHWjZbn4uwfY++RjpvIW0I01Ww== X-Zone-Loop: e35bf4dbb0f12bb4a17d10a26a0ab471ea6b595f8f5e x-campaign-type: default x-transaction-id: ff6cdbcc-aebf-46ef-9970-30530ccb3459 x-swg-uid: 01-0613efb9-1d56-44ea-80bb-626674cd8285 X-Mailer: Sweego Message-ID: <1793027684.8631fc262581453bbf619ec5b2062170.1a178c7373e000f79f@vates.tech> x-swg-bid: 1793027684.8631fc262581453bbf619ec5b2062170.1a178c7373e000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v8 2/5] xen/riscv: fix A/D bits in Xen's page-table mappings Date: Mon, 26 Oct 2026 16:14:34 +0100 In-Reply-To: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793027331; l=8050; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=z2JA5ykm5jV3OWJlXaV6V4FclNBYupnFTEqpKHl8hJU=; b=jvzkOplkM3u99GMDbajurUUlsQuoad9RAE6VgqclDRnPsvuZKo5KVhD4+J014TW/OlRkv/ntS IGglk5XGfVWAD61rznvUH8LoezqwMbROZb7ytCKvEU2VHWbuAiqFw5P 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: 1793027683537 X-purgate-ID: tlsNG-c1860d/1793027693-DFAD487B-C812CC5C/10/78276251493 X-purgate-type: spam X-purgate-size: 8052 Xen does not handle page faults caused by clear A/D bits, so it presets them when creating PTEs. pt_update_entry() does so, but three places build leaf PTEs directly without going through it: setup_initial_mapping() (the boot page tables), check_pgtbl_mode_support() (the temporary root entry used to probe SATP mode support) and arch_pmap_map() (the fixmap). On implementations that fault on clear A/D bits (Svade), all three fault on first access. For check_pgtbl_mode_support(), the fault is raised by the instruction fetch right after the SATP write, before any trap handler is set. Add PTE_ACCESSED and PTE_DIRTY to PAGE_HYPERVISOR_RO, and build PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX on top of it. PTE_DIRTY is set in all cases for consistency with pt_update_entry() which sets it at runtime. 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 check_pgtbl_mode_support() to use PAGE_HYPERVISOR_RX for its temporary root entry. 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, 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. pte_is_table() and pte_is_mapping() both assert that a PTE doesn't use one of the two reserved encodings, (V=1, W=1, R=0) and (V=1, X=1, W=1, R=0), by masking it with PAGE_HYPERVISOR_RW. Now that PAGE_HYPERVISOR_RW also carries A and D, a reserved PTE with A or D set would no longer be caught. Mask with the V, R and W bits explicitly instead, and factor the check out into pte_has_reserved_rwx(). Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") Fixes: f89e1a170299 ("xen/riscv: introduce asm/pmap.h header") Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko Tested-by: Zhang Zheng Acked-by: Jan Beulich --- Changes since v7: - collect A-by and T-by. --- Changes since v6: - add a 2nd Fixes tag, as arch_pmap_map() was introduced by a later commit. --- Changes since v5: - no changes, already reviewed and waiting to be merged. --- Changes since v4: - rebase on top of staging. - add a missing changes line in "Changes since v3". --- Changes since v3: - rebase patch 2/6 which modified wrong indentation. - change commit message to address review comments. - rename pte_is_reserved() to pte_has_reserved_rwx() --- Changes since v2: - add fixes commit ref. - add A/D bits to PAGE_HYPERVISOR_RO and derive PAGE_HYPERVISOR_RW/RX from it for consistency with runtime. - introduce pte_is_reserved() to factor out the reserved-encoding assert shared by pte_is_table() and pte_is_mapping(). - reword commit title --- 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 | 33 +++++++++++++++++---------------- xen/arch/riscv/mm.c | 11 +++++------ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index c8bb334b85..f9e59e61de 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -46,12 +46,12 @@ #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 | PTE_DIRTY) +#define PAGE_HYPERVISOR_RW (PAGE_HYPERVISOR_RO | PTE_WRITABLE) +#define PAGE_HYPERVISOR_RX (PAGE_HYPERVISOR_RO | PTE_EXECUTABLE) #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW /* @@ -161,31 +161,32 @@ static inline bool pte_is_valid(pte_t p) * X W R Meaning * 0 0 0 Pointer to next level of page table. * 0 0 1 Read-only page. - * 0 1 0 Reserved for future use. + * 0 1 0 Reserved for future use. [1] * 0 1 1 Read-write page. * 1 0 0 Execute-only page. * 1 0 1 Read-execute page. - * 1 1 0 Reserved for future use. + * 1 1 0 Reserved for future use. [2] * 1 1 1 Read-write-execute page. + * + * So if V=1 and W=1 then R also needs to be 1 as R = 0 is reserved for + * future use ([1], [2]). */ +static inline bool pte_has_reserved_rwx(pte_t p) +{ + return (p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) == + (PTE_VALID | PTE_WRITABLE); +} + 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(!pte_has_reserved_rwx(p)); return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID); } static inline bool pte_is_mapping(pte_t p) { - /* See pte_is_table() */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); + ASSERT(!pte_has_reserved_rwx(p)); return pte_is_valid(p) && (p.pte & PTE_ACCESS_MASK); } diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c index 06f0406781..6f7dcd10b2 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -140,19 +140,18 @@ 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 pte_flags = PTE_LEAF_DEFAULT; + unsigned int pte_flags = PAGE_HYPERVISOR_RW; unsigned long addr = is_identity_mapping ? page_addr : virt_to_maddr(page_addr); pte_t pte_to_be_written; index = pt_index(0, page_addr); - if ( is_kernel_text(addr) || - is_kernel_inittext(addr) ) - pte_flags = PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) + pte_flags = PAGE_HYPERVISOR_RX; if ( is_kernel_rodata(addr) ) - pte_flags = PTE_READABLE | PTE_VALID; + pte_flags = PAGE_HYPERVISOR_RO; pte_to_be_written = paddr_to_pte(paddr, pte_flags); @@ -197,7 +196,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.56.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:14:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:14:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461475.1672504 (Exim 4.92) (envelope-from ) id 1xLMPZ-0005Bp-7q; Mon, 26 Oct 2026 15:14:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461475.1672504; Mon, 26 Oct 2026 15:14: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 1xLMPZ-0005Bf-4f; Mon, 26 Oct 2026 15:14:57 +0000 Received: by outflank-mailman (input) for mailman id 1461475; Mon, 26 Oct 2026 15:14:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMPX-000587-V7 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:14:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMPX-003d6B-Bw for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:14:55 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6e68-2eae-0a2a0a5409dd-0a2a450197f4-18 for ; Mon, 26 Oct 2026 16:14:55 +0100 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 6adf6e6e-5984-0a2a45010019-b9ff1c229eb1-3 for ; Mon, 26 Oct 2026 16:14:55 +0100 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 1a178c73927000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:14:44 +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 CFC8C815DF; Mon, 26 Oct 2026 16:14:43 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=t+sYHvCIm+RgMaIUIOoBUgA8H4OGZB50SGJyJUcLCR8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=VER+rCJKjd9Ir8L9fZ5tx9jZnHY0DBzo/pI64r+XoTfbSvzJlLkkp9++tUqpaLVU0nlIahbW4 chbupQTmI0GAfbBuvq8FhKPrMVHL7Jk/MMUrZkEvAXRCjrXE9GwZgrGtV00+18QHzR9ggwPP73H d825PoGpCgS4mzAQTOOYnYyyE9Ak8KaV5WU7tm6IkW2jiWbQP1w4oXEYcJmJnWTdG3zdZo6iv8+ hyr0LEq7+HKGlAYF0Uk1q6Yi6Tpy0vZyBZfzBLrmGhRnpFpDDsp7LR2rD6z/4Xb6eRqb+Rub4Mc RkyDoDDB+GhTeRjQTZHvFYtNIbBXh2hai0dsR4qf91tA== X-Zone-Loop: 3b1306b5a00d61bd7c75e80f7dcee9acd7d8c45c7d27 x-campaign-type: default x-transaction-id: 1f1c4991-2807-499a-8576-ea5da85cc1c6 x-swg-uid: 01-4109e937-9acb-45d0-a3fc-b8b5bd1af557 X-Mailer: Sweego Message-ID: <1793027684.8631fc262581453bbf619ec5b2062170.1a178c73927000f79f@vates.tech> x-swg-bid: 1793027684.8631fc262581453bbf619ec5b2062170.1a178c73927000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v8 3/5] xen/riscv: look up the exception table for any trap taken in Xen context Date: Mon, 26 Oct 2026 16:14:35 +0100 In-Reply-To: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793027331; l=4280; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ynAPBxEe/se6dosPBRPOshvwbc043xikGQQ7S5foXVM=; b=0GnQZgaD4G+8xSfn7Y6gVoCK3zvhzwmVV/jC+HWZnZDEbDdEwyk76m6I9NylOX0Cuyu/KZVdj A35uan9etfmB0/AiXtudVFpriZu5zclSL2nPSsGol2e3dvDQSSU4Onj 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: 1793027684041 X-purgate-ID: tlsNG-d62444/1793027695-BCF47757-7AB22778/10/73395122804 X-purgate-type: spam X-purgate-size: 4337 From: Oleksii Kurochko do_trap() consulted the exception table only for CAUSE_ILLEGAL_INSTRUCTION, which covers csr_read_safe() but not a probing access faulting with a page fault cause: it would reach do_unexpected_trap() instead of its fixup. There is no such access yet, the A/D update scheme probe will be the first. Move the lookup ahead of the cause switch, and only do it for exceptions taken in Xen context. Both other cases must skip it: - Traps taken from the guest: sepc is then a guest address, which the guest can point at an address listed in the exception table, making Xen act on an entry fully under guest control. Entries are matched by exact address, so this needs no more than a numerical collision. - Interrupts: 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. Returning early skips check_for_pcpu_work(), which is correct: that only runs for traps taken from the guest. Cache the "trap came from the guest" test in a local as it is now used three times. Signed-off-by: Oleksii Kurochko [Baptiste: drop the parts depending on the vAPLIC/vIMSIC series, adapt the commit message] Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v7: - new patch, needed by the A/D update scheme probe of the next patch, whose store page fault would otherwise not be fixed up. Taken from: https://patch.msgid.link/4e2b4e7a99f4d2133ff92559303d19382749de7a.1790779209.git.oleksii.kurochko@gmail.com - commit message adapted to this subset: drop the hlv/hlvx and EX_TYPE_TRAP_INFO parts and the paragraph on the guest page fault BUG_ON(), whose code isn't taken; mention the from_guest local, which this subset introduces. - apply my v3 review suggestion to the commit message: state up front that the lookup is only done for exceptions taken in Xen context and list traps taken from the guest and interrupts as the skipped cases. --- xen/arch/riscv/traps.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 10d6855d91..dd53454f23 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -195,12 +195,33 @@ void do_trap(struct cpu_user_regs *cpu_regs) { register_t pc = cpu_regs->sepc; unsigned long cause = csr_read(CSR_SCAUSE); + bool from_guest = cpu_regs->hstatus & HSTATUS_SPV; + + /* + * A synchronous trap taken in Xen context may come from a probing access + * like csr_read_safe(), covered by an exception table entry which resumes + * execution past the faulting instruction. + * + * Traps taken from the guest must never be fixed up: sepc is then a guest + * address, which the guest could point at an address listed in the + * exception table, making Xen act on an entry fully under guest control. + * + * Interrupts must be excluded too: one taken at an address which happens + * to be listed in the exception table would otherwise be "fixed up" as if + * the access itself had faulted, silently skipping it. + * + * Returning early skips check_for_pcpu_work() below, which is correct: + * that only runs for traps taken from the guest. + */ + if ( !from_guest && !(cause & CAUSE_IRQ_FLAG) && + fixup_exception(cpu_regs) ) + return; switch ( cause ) { case CAUSE_VIRTUAL_SUPERVISOR_ECALL: /* CAUSE_VIRTUAL_SUPERVISOR_ECALL should come from VS-mode */ - BUG_ON(!(cpu_regs->hstatus & HSTATUS_SPV)); + BUG_ON(!from_guest); vsbi_handle_ecall(cpu_regs); break; @@ -219,9 +240,6 @@ void do_trap(struct cpu_user_regs *cpu_regs) break; } - if ( fixup_exception(cpu_regs) ) - break; - fallthrough; default: if ( cause & CAUSE_IRQ_FLAG ) @@ -253,7 +271,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) break; } - if ( cpu_regs->hstatus & HSTATUS_SPV ) + if ( from_guest ) check_for_pcpu_work(); } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:14:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:14:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461476.1672513 (Exim 4.92) (envelope-from ) id 1xLMPb-0005QA-Gc; Mon, 26 Oct 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 1461476.1672513; Mon, 26 Oct 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 1xLMPb-0005Q3-CS; Mon, 26 Oct 2026 15:14:59 +0000 Received: by outflank-mailman (input) for mailman id 1461476; Mon, 26 Oct 2026 15:14:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLMPZ-0005De-Hu for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:14:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMPY-003d6B-Uo for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:14:56 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6e68-2eae-0a2a0a5409dd-0a2a450197f4-26 for ; Mon, 26 Oct 2026 16:14:56 +0100 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 6adf6e6e-5984-0a2a45010019-b9ff1c229eb1-4 for ; Mon, 26 Oct 2026 16:14:56 +0100 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 1a178c73a5d000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:14:44 +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 5548F81DAB; Mon, 26 Oct 2026 16:14:44 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=05V3BzR+6x5zjvavbuAwm43Wko/6HMSUKNP4NRC4DXs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Q8uN5jupVx6Fe/yI8zifA3Nz5E0nBlEy+O2H0Ho4JR1gO9s1ZdaJoDgotvmLOolJTDR238n2E fSLv6ZiHzOKkhEQ8z72OgLc4NWpg9RwNZ3LiH+xpKadyRf1ADtt22plS9DggBzqrT/3dbTJ2eVq Ykih6TDtdsJ+AuqoGdTKbHqWuLH+3OkVlz2TbRxlqvtoDok4wB4eYXT27ijdIu/Op5gLReVW6zA ydFtXvormMFihCSNeY0giCxOl++IHRXHHCW21gmiOkcAC5XcQal//PGzobLByCx4SQm5/0/jJ1z OBjVxs4V4xpIXT3ArtGPRGRnd5zVH/rgfK/n2P/NYkcA== X-Zone-Loop: 2e04acb81c36d885181dc10a34c70001e62d75c9ce61 x-campaign-type: default x-transaction-id: 5ce385fc-d648-46d9-97b9-dfa73fc5e218 x-swg-uid: 01-daeb0d01-50e0-4a8a-809d-41e5a8712c4c X-Mailer: Sweego Message-ID: <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> x-swg-bid: 1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither Date: Mon, 26 Oct 2026 16:14:36 +0100 In-Reply-To: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793027331; l=7572; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=q6jMm0V5keRQlKbvNoUn72l63KmhPB1IAcGOzTgqX84=; b=LXkIdw0zxbbgRP9v+l2VtKF0Ii24w/+/6kP//6J7vOnDQ4B0P7JKUZKvm2mIGSkysPFqpvVmh JRqA4EYimWrBDy5iiKqoPVzG9fOyuVNM2RKEzuECEuqRFlDdGfZVB1C 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: 1793027684540 X-purgate-ID: tlsNG-d62444/1793027696-C4F47757-39436220/0/0 X-purgate-type: clean X-purgate-size: 7574 p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. The privileged spec allows exactly two schemes for updating the PTE A and D bits: hardware sets them on access and on write, or accessing a page whose A and/or D bit is clear raises a page fault so that software can set them (ratified as Svade). Every implementation uses one of them, but platforms designed before Svade and Svadu were ratified, such as the HiFive Premier P550, may advertise neither. Trust the device tree when it advertises Svade and/or Svadu, as for any other extension. When it advertises neither, probe the scheme in effect and record the matching extension in riscv_isa, so that such device trees can be used as-is, and warn naming the extension to add to "riscv,isa". Introduce probe_hw_ad_update(): alias a local variable through the FIX_MISC fixmap slot with its A and D bits clear, then store to it under an exception table fixup. Hardware updating is in effect if the store completes and the D bit is then set. The probe fails otherwise, whether the store faults or completes leaving the D bit clear. The D bit is checked rather than the A bit, as the A bit may be set speculatively. The PTE is written directly rather than through set_fixmap(), which presets the A/D bits. Add Svadu to the known ISA extensions so it can be told apart from Svade. The comment above the enum asks for new extensions to go at the bottom to avoid shuffling, a leftover from Linux where the IDs were macros with explicit values. Nothing depends on the enum values, so have the comment say that multi-letter extensions follow the order of riscv_isa_ext[]. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v7: - probe the A/D update scheme when the device tree advertises neither Svade nor Svadu and record the probed extension, instead of panicking. - drop Suggested-by. - update the patch's title/body accordingly. --- Changes since v6: - drop the probe and trust the device tree, only panic when it advertises neither Svade nor Svadu. - update the patch's title/body accordingly. - put svadu between svade and svpbmt in riscv_isa_ext_id. - rewrite the enum riscv_isa_ext_id comment. --- Changes since v5: - new patch, probe the A/D bits update scheme instead of trusting the device tree alone. --- xen/arch/riscv/cpufeature.c | 69 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 ++++--- 2 files changed, 76 insertions(+), 6 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 3d5bbd2228..49cbd0a6fe 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -20,6 +20,7 @@ #include #include +#include #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -200,6 +201,7 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { RISCV_ISA_EXT_ENTRY(ssaia, ANY), RISCV_ISA_EXT_ENTRY(sstc, NONE), RISCV_ISA_EXT_ENTRY(svade, NONE), + RISCV_ISA_EXT_ENTRY(svadu, NONE), RISCV_ISA_EXT_ENTRY(svpbmt, NONE), }; @@ -630,6 +632,51 @@ const char *get_guest_isa_str(void) return guest_isa_str; } +/* + * Probe whether hardware updates the PTE A/D bits by writing to a local + * variable through an alias mapping whose A and D bits are clear. + * + * Check the D bit rather than the A bit, as the A bit may be set + * speculatively while the D bit can't. + * + * Under Svade, the store raises a page fault instead, so use the extable to + * handle it. + */ +static bool __init probe_hw_ad_update(void) +{ + unsigned int probe_target; + vaddr_t va = FIXMAP_ADDR(FIX_MISC) + PAGE_OFFSET(&probe_target); + pte_t *entry = &xen_fixmap[FIX_MISC]; + bool d_set = false; + + ASSERT(!pte_is_valid(*entry)); + + /* + * Any page in use will do, so alias the stack page this code runs on, + * with A and D clear. Store to a variable of its own, so that nothing + * the compiler relies on gets overwritten. + */ + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(&probe_target)), + PTE_VALID | PTE_READABLE | PTE_WRITABLE)); + flush_tlb_one_local(va); + + asm_inline goto ( + "1: sw zero, 0(%[va])\n" + ASM_EXTABLE(1b, %l[out]) + : + : [va] "r" (va) + : "memory" + : out ); + + d_set = read_pte(entry).pte & PTE_DIRTY; + + out: + write_pte(entry, (pte_t){}); + flush_tlb_one_local(va); + + return d_set; +} + void __init riscv_fill_hwcap(void) { unsigned int i; @@ -674,6 +721,28 @@ void __init riscv_fill_hwcap(void) "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " "wire up this platform's pause equivalent in cpu_relax()\n"); + /* + * The privileged spec allows exactly two schemes for updating the PTE A + * and D bits: + * 1) hardware sets them on access and on write; + * 2) accessing a page whose A and/or D bit is clear raises a page fault, + * so that software can set them (ratified as Svade). + * + * Every implementation uses one of them, but may predate the extensions + * and advertise neither. In that case, trust the hardware probe. + */ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) + { + bool hw_update = probe_hw_ad_update(); + + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, + riscv_isa); + printk(XENLOG_WARNING + "Device tree advertises neither Svade nor Svadu, probed %s: add it to \"riscv,isa\"\n", + hw_update ? "svadu" : "svade"); + } + 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 2973eb13a5..b0a23be18e 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -8,13 +8,13 @@ #include /* - * These macros represent the logical IDs of each multi-letter RISC-V ISA - * extension and are used in the ISA bitmap. The logical IDs start from - * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single - * letter extensions and are used in enum riscv_isa_ext_id. + * Logical IDs of RISC-V ISA extensions, used as bit positions in the ISA + * bitmap. * - * New extensions should just be added to the bottom, rather than added - * alphabetically, in order to avoid unnecessary shuffling. + * Single-letter extensions use IDs below RISCV_ISA_EXT_BASE and are sorted + * alphabetically. Multi-letter extensions start from RISCV_ISA_EXT_BASE and + * follow the same order as riscv_isa_ext[] (see the ordering rules described + * above it). */ #define RISCV_ISA_EXT_BASE 26 @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_ssaia, RISCV_ISA_EXT_sstc, RISCV_ISA_EXT_svade, + RISCV_ISA_EXT_svadu, RISCV_ISA_EXT_svpbmt, RISCV_ISA_EXT_MAX }; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:15:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:15:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461478.1672522 (Exim 4.92) (envelope-from ) id 1xLMPe-0005hI-Ql; Mon, 26 Oct 2026 15:15:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461478.1672522; Mon, 26 Oct 2026 15:15: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 1xLMPe-0005h9-Nd; Mon, 26 Oct 2026 15:15:02 +0000 Received: by outflank-mailman (input) for mailman id 1461478; Mon, 26 Oct 2026 15:15:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMPd-0005fI-Bg for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:15:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMPc-00ESEG-Oj for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:15:00 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6e6b-e002-0a2a0a5209dd-0a2a4508c308-16 for ; Mon, 26 Oct 2026 16:15:00 +0100 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 6adf6e74-f659-0a2a45080019-b9ff1c1288f5-3 for ; Mon, 26 Oct 2026 16:15:00 +0100 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 1a178c73b94000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:14:45 +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 A082F81E53; Mon, 26 Oct 2026 16:14:44 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=kbx7FuSDc06ZBA43oBu6G+26e9mYroFRMBqi6Ps0vuU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=lsvoqg+3RjD+DEYUJ9yXQVHB4uPBYC3I+WaPrBUBrL90X4xpUixuTI29ZXzz5aFOvTgECrjTv +pQrgSSFfF4SxjbKyM9+UCOOGRerkAxpgP93nLtFjQRmzgHh+yAJDFcG0xonvbNHuiWtj8lVUXl dbYJubvg4Rzfrzf3ySCOnxBtpsrnyEl4NDZhJD6dSAQoYOwSLuEAmFDdT7twv5t5yT6FkpxO+NP i0HHiKwvlAXDCiUnFtxZFPWXr37rvGqqlPO+7N+Dn01FRCrKuuqD3enToKtwNif+f9DhEWjV3HM rA4WEk78f293yp0mQk6qnf2O450cOe+amOwCnw4DGH3w== X-Zone-Loop: d7d220821e69ed06eedb9f2381061f70adb9e84aaf55 x-campaign-type: default x-transaction-id: 80be7ad3-14bf-4d8b-8bbe-13ce78bfed0d x-swg-uid: 01-03d6eaac-5398-4723-a137-2008d35b89b5 X-Mailer: Sweego Message-ID: <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73b94000f79f@vates.tech> x-swg-bid: 1793027685.8631fc262581453bbf619ec5b2062170.1a178c73b94000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v8 5/5] xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() Date: Mon, 26 Oct 2026 16:14:37 +0100 In-Reply-To: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793027331; l=5135; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=vuOMNvviSt4a7TWW5Qv+CGfm+79pNznRqgcCowdji6Q=; b=yptX/IkJuN/jXRyCCBnJuJO2rpZkHeGdjuNS6SNCGwnUtuiqr1yOW2HBsR/7uAgG3XzMSBCZy pdL3EVBzv8YBS5OGd78Zddmel6FVT9/GMXpOEPPmXhKwBYbQOus32xr 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: 1793027684846 X-purgate-ID: tlsNG-c1860d/1793027700-D795A87B-6FCBA36E/10/73395122804 X-purgate-type: spam X-purgate-size: 5137 The comment in p2m_set_pte_flags() quotes the spec at length to describe the two A/D bits schemes, and its TODO mixes two things: why A/D are preset today (OpenSBI delegates the resulting page faults to a lower privilege mode, so Xen would take them with no handler) and what remains to be done. Summarize the two schemes as a short list. The reason for presetting A/D is not future work, so move it out of the TODO, next to the schemes. The TODO now keeps only the later work, handling these page faults instead of presetting A/D, which only concerns Svade as A/D page faults cannot happen otherwise. Also note that presetting the A/D bits is harmless when the device tree advertises both Svade and Svadu and the platform uses hardware A/D updating. No functional change. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko --- Changes since v7: - collect R-by. - move the patch last, as the previous patch now records Svade whenever the CPU faults on clear A/D bits, instead of riscv_fill_hwcap() panicking when the device tree advertises neither Svade nor Svadu. --- Changes since v6: - drop the change to preset A/D unless only Svadu is advertised, as riscv_fill_hwcap() now panics if the device tree advertises neither Svade nor Svadu. The patch only reworks the comment. - update the patch's title accordingly. --- Changes since v5: - new patch, split out of "xen/riscv: always preset A/D bits in G-stage PTEs". --- xen/arch/riscv/p2m.c | 45 +++++++++++++++++++-------------------------- 1 file changed, 19 insertions(+), 26 deletions(-) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 3d195294d5..a2d81a9c8a 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -591,35 +591,28 @@ static void p2m_set_pte_flags(pte_t *e, p2m_type_t t) 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. + * A RISC-V implementation can either: + * 1) Update the 'A' and 'D' PTE bits in hardware. + * 2) Generate a page fault when 'A' and/or 'D' is clear, so that + * software can set them. * - * 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. + * (1) needs nothing more as it is handled by hardware. For (2), set 'A' + * and 'D' up front: OpenSBI delegates such page faults to a lower + * privilege mode, so they would be raised in Xen, which has no handler + * for them. * - * 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. + * If both Svade and Svadu are advertised and the CPU updates A/D in + * hardware, presetting them is harmless. * - * 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. + * TODO: Xen on RISC-V currently makes no use of the information that + * handling such page faults could provide, which would be useful + * for several use cases such as demand paging, cache-flushing + * optimizations, memory access tracking, etc. + * + * 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 the page faults that occur due to + * unset A/D bits. */ if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) e->pte |= PTE_ACCESSED | PTE_DIRTY; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:17:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:17:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461506.1672531 (Exim 4.92) (envelope-from ) id 1xLMRm-00074c-5u; Mon, 26 Oct 2026 15:17:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461506.1672531; Mon, 26 Oct 2026 15: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 1xLMRm-00074U-2W; Mon, 26 Oct 2026 15:17:14 +0000 Received: by outflank-mailman (input) for mailman id 1461506; Mon, 26 Oct 2026 15:17:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMRl-00074H-80 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:17:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMRk-007XYD-Kv for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:17:12 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf6eea-8faa-0a2a0a5109dd-0a2a45048ee2-30 for ; Mon, 26 Oct 2026 16:17:12 +0100 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 6adf6ef8-b57f-0a2a45040019-d1558035bd81-3 for ; Mon, 26 Oct 2026 16:17:12 +0100 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a4d7ae1ae9so14739515e9.1 for ; Mon, 26 Oct 2026 08:17: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-48e3ecdfd8dsm16088086f8f.56.2026.10.26.08.17.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 08: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-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=1793027832; x=1793632632; 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=wh9DCh6BnCIe7U1+Jq4ZLGGkRv6UNGL+JzO2IuJFWE8=; b=N0/D77AxLlt09awgnAr3ChXgWawWkZH2i0pRVy+5vqcGKj7DpPHqxqZfc8ptjwHfF3 UWvz6AWSXWU30TopWh5Ms700nkEJRDUVOb2l+HY3rm0Q5Ln3UGl4SsLIuVF8oEVhuCWA 5snPQm3qR7iFCFSOrptDvEC0D3ij+p9NOgula3pLJ3NFaRPa22J0rV8xpOp1lYUeB79v /gmTETiMy5VODfrxp1Te/4rJo3xR6lPlVjiCyxsZbPmWRnnZ6uG+oRCcT9j5us9DTNgH E74HifIhIFcjanQ9HhpbzgJ0x4jlh5yKNje31GENDj3nBVuOlF/mBt4qvYh1EEkneQpq N+pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793027832; x=1793632632; 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=wh9DCh6BnCIe7U1+Jq4ZLGGkRv6UNGL+JzO2IuJFWE8=; b=C7OCKKhg/P3Zwu9FurNdFeezyG2cPQjTTLH/pW057xtiCOZwsdYH/3J1m42tVDVFNZ N1D91KVD/SQqoQFZZVlHWNI/Hpg0kAd4x1weIs6gKjY73O1q039VdisjoyVRjYStWgJ9 Mp7f/UZciOu4NRBpvFqeu/2exjn4k7R8mugKhnp5Keq32u9wnbAtDbh4bLuZOor1BP+3 hCoKeM03rrAEtnyZ7RJUruXGN4y878TJhoveuiqF9sdXevj3l7uivaD09B877pz4XiJQ 3zT/c8UaPimtKgtg91vJpHSjl1JtFolz3Hl/l+Q0VxzE3wFMoMAf7N8ErgA6pfMBg4vq jAKw== X-Forwarded-Encrypted: i=1; AKwUvBw0jo2XjTm/J8ChfK4M5cXqqjOC2M1ga6lIx//4Hj2679p5UVNU34e8FXSDK9nnN8cOUVTWrd5JVdU=@lists.xenproject.org X-Gm-Message-State: AFq9FYI53V4cotHT0QYrVYdGHTTSMwn7C+SeXOuI2Js7/o/ur49WvqSw VCkFXEZXKcnVzUuCr069le5PaqN6tGxuI+WzaET8UDtTq/McM6dJwjXTs/TClCHvdQ== X-Gm-Gg: AYBFou19Jj285mXraU7Z49V55TU40sV/4ZtRMMYSK2werVnZfLLC0rxcBxXadOJffbI /ys9fI9+mHp3mlNsl1Uv4CtuCyJzWULlGcSGZa9rU1b48DiMWUiW/OgG3yYvfdp2vzNoWplzz7n DfEJRzOrawmsNCbpX5Wmcjqu1hb3uo+QSbxYEsmKcO96erb+drI5TPX/HferzFm+9x4InHg8oLC qERW92WXMoIwGEE0kDH6HTUkpDA7r9WAJR9wPQYzeQVLPuDSXeKi1+nQ7HOPsAbMXkdwal1HlD8 25zJNVuBMC4xcosnP20aa6AbKzURYDqmN63xk1dRj/GCkvHURL8PfGbe0s9SdjtH9/5TKNmRt1S caZClazPLcjMdXJTHg+RAj9B3AGY3VAXvNTGXaEZTeVoRBD3G0edjZjttFmv7sWN/LT6BNchUYD 0rPUPO3BzEJ97tDZcFjzWnqQgvupgcCsXYePZ5Z4xmykraQDUxOFEKkzFG8h7cDxNhgg1IWNJEd JzNcmd6zkWhCBf7sfVTKZITW+lMwO7rQ0KXm2cPDP8z17Rcn3OhvataHshBpv1aiVMyNWhJymp/ oPjVy9kmnpahOv9lQxItD5xdOdQRSBB5JTw3D3SFuBs= X-Received: by 2002:a05:600c:474a:b0:4a1:d97e:cd60 with SMTP id 5b1f17b1804b1-4a35ac91f2amr140871985e9.16.1793027831844; Mon, 26 Oct 2026 08:17:11 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 16:17:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot To: Oleksii Moisieiev , Oleksii Kurochko Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Teddy Astie , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1793027832-C36C2B50-B319CB12/10/78276251493 X-purgate-type: spam X-purgate-size: 1553 On 26.10.2026 15:52, Oleksii Moisieiev wrote: > On 05/10/2026 11:52, Jan Beulich wrote: >> On 02.10.2026 15:26, Oleksii Moisieiev wrote: >>> This commit introduces a new Kconfig option, `CONFIG_DOM0_BOOT`, to >>> allow for building Xen without support for booting a regular domain (Dom0). >>> This functionality is primarily intended for the ARM architecture. >> I (still) wonder why this would be, but well ... > For v6, I'm going to describe this as a common option for legacy Dom0 > boot, with Arm implementing the code exclusion initially. My immediate > use case is an Arm deployment where guests are launched through > dom0less and legacy Dom0 boot is not needed. I'm going to clarify that > this use case motivates the initial Arm implementation, rather than > make the interface Arm-specific. Is that scope OK? >>> A new Kconfig symbol, `HAS_DOM0`, has been added and is selected by >>> default for ARM and X86 architecture. This symbol signifies that an >>> architecture has the capability to support a Dom0. >> Oleksii - what's your take towards RISC-V here? Should it select the new >> symbol right away as well? > In the staging branch RISC-V's start_xen() does not have a legacy Dom0 > construction path. > I'm therefore going to leave HAS_DOM0 unselected on RISC-V and explain > that selection should accompany implementation of legacy Dom0 boot. > Its existing HAS_DOM0LESS selection does not provide that path. > Does it sounds ok to you? FTAOD - my earlier question was to the other (RISC-V) Oleksii. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:24:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:24:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461515.1672540 (Exim 4.92) (envelope-from ) id 1xLMYy-0000lE-Sb; Mon, 26 Oct 2026 15:24:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461515.1672540; Mon, 26 Oct 2026 15: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 1xLMYy-0000l7-PB; Mon, 26 Oct 2026 15:24:40 +0000 Received: by outflank-mailman (input) for mailman id 1461515; Mon, 26 Oct 2026 15:24:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMYx-0000l1-LU for xen-devel@lists.xen.org; Mon, 26 Oct 2026 15:24:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMYw-001BgA-R2 for xen-devel@lists.xen.org; Mon, 26 Oct 2026 16:24:38 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf70ae-e002-0a2a0a5209dd-0a2a4505ea64-22 for ; Mon, 26 Oct 2026 16:24:38 +0100 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 6adf70b6-4cb1-0a2a45050019-d155dd2ba838-3 for ; Mon, 26 Oct 2026 16:24:38 +0100 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-48dfaa3fa12so10793f8f.0 for ; Mon, 26 Oct 2026 08:24: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-4a35a5822a7sm208618255e9.11.2026.10.26.08.24.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 08:24: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=1793028278; x=1793633078; darn=lists.xen.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=LInYRTx0Us5Xo7p6ZCOOB9+2275ARbSTj2x2CtbVzGI=; b=AdKL39DxnKCbzZvEmFdmblRzgHyghgPEEv6C7Npwvcp2SullbUQ70g+PPBPTvbm+mR hqagClZGEO8SF9ydwGHwF8a/T0DfwNgEE8WNngZ4TDGlyEXG9QZtX34jHkh1An9DxXtP gmOCxj2AUld3jc0XpDGkb2tHWl0uu9OFXv1Udp2sNxBRMkohuruItNM/q0M8xv0MEUBo 3lsRzVyuhnRn7xDJBHajz6dXwAveuhYf35EnWC1+vCHFJk5M+DMWQvXMaYp3+Km3cV+y m+jxUAhRNlKvJ3mI7qyuJ53SETPx+fupPSwJ+ptLgBde8Z74HP/1CpItUET72eBdQo5O pk8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793028278; x=1793633078; 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=LInYRTx0Us5Xo7p6ZCOOB9+2275ARbSTj2x2CtbVzGI=; b=LPyVV147C4rSL/RAOmmcktilqGclIFateh4g+0Ff/dUX9TIDh4VdObV0YCv4LHScjP 2jiqfP7rh12TC3348Hrnfs8XEgx5dC3d/tIav0+as6kzMElE+Qrsm07+gaeSPiWVuqhU d+w6y68Q3KG00yNF+LU4sH9YT5tYecvZX1olzAtNyChFfKpJ12iy+GO7EfiYC+P5WXwA 06vVURKxC/06HIXf3/jQNqPkYdpDDe3UbSM7s071dwy+KK3G6nMrTTozNTvPAYBOe7u6 3g6Lu9zbwPkTB+/ryIItU0xuczIDoHpjjX3HPyhvfKJCeNo0mLCGOfHTl3IGJcuGtmQS RPDA== X-Forwarded-Encrypted: i=1; AKwUvBy4weOyJvSL5lXFK8dw+4pcZaVJpkz86X285kD7RbTw30irEat8sp9pp4lYCGHUlwRXhOhnaPMJxs0=@lists.xen.org X-Gm-Message-State: AFq9FYLdOm8gWY8Q7oE0bCoCr/J+BTHeqm4hP5uPWZcoe588mj3JCbZo F14RBhhkmTxE9ScYHTIu9wvC3ixkAD5k4ci2k+heQFvo3UylaaFsuz0U2SvTE8Mh/Q== X-Gm-Gg: AYBFou1a5OukRtSc1O9GoOnEZ5zaDsiM637UN1FlleVtblGbia3otLai983PiYfIKOB U+1I52/s/Q9gnmRMwe95eRegztOxfqO+l5trR0Btpqhc657uV3p+WgDUjwv70V9b491cq4wJMIp LJ4keiVtGk4HeL6XMziWY4O6ORXNoJMsVJHqFhN/f4iLymYqF46553nrlpIPcPOLs5qjPq+v6av SUjm6lDawcIaRHcXpHsY0chLJVpQKVKfQSaZ33gdwvPqfPzfkiCZlKFyjk2OoE3tK6IeGwiAtvj Egr1OGUpHSVTPc4w/u/kQUNM9B2t2L8wNkGFDNOqIIKQ1j7yKcs6QUaLI5HNglTASkKvO3cBW7B 7fZZFE6quipgk6LWeTaw50xbbH6XDLqbsjrtPPbvr7PvrCnX9N1scl4h7/Jxk/s3LVokBwmClz6 36dAwJGHjbKjFnkdjqrMG35WgwbybcUykjAKYwPBk3pvqfLkuPhwEGhxKqq3Dzb/2EOeDf2Jb1t KeaXQebz494dcUd8AJsOqlM+D9obDeorJbC2rzWr6Lk+Nj2tshOWIo3u+hb/eLkMqejUs7gU0bT my8K4oCmHHC4pPNZN4QXhQQyZ72sDE0zKlhBGsPYGJfW X-Received: by 2002:a05:600c:a318:b0:49f:c5aa:9ef4 with SMTP id 5b1f17b1804b1-4a7c0b3f6c2mr35275e9.8.1793028278084; Mon, 26 Oct 2026 08:24:38 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 16:24:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Peter Deggendorfer Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Soham Dandapat , Andrew Cooper , xen-devel@lists.xen.org References: <8138ed44-727f-45bc-9673-9684e922595b@cortex-media.de> 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: <8138ed44-727f-45bc-9673-9684e922595b@cortex-media.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793028278-2491C2A1-6075BB4B/10/78276251493 X-purgate-type: spam X-purgate-size: 3498 On 26.10.2026 15:48, Peter Deggendorfer wrote: > Am 26.10.2026 um 11:53 schrieb Jan Beulich: >> On 25.10.2026 13:32, Peter Deggendorfer wrote: >>> Regarding the output of /dev/mcelog: if my decoding is right, three >>> things stand out. MCi_STATUS is zero, i.e. these banks are reporting >>> nothing at all -- no error, no garbage value. >> Well, things can't quite be that way: If MCi_STATUS was zero, the first >> check in mc_amd_recoverable_scan() would prevent mc_ec2type() from >> being reached in the first place. Its caller also checks MCi_STATUS_VAL >> to be set. >> >> What I find puzzling is this: >> >> errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC); >> ectype = mc_ec2type(errorcode); >> >> With errorcode (and mc_ec2type()'s parameter type) being uint16_t, what >> use is it to include MCi_STATUS_MSEC in the mask? (Yet that's likely >> unrelated to the issue at hand.) Considering how mc_ec2type() works, I >> see no reason why status couldn't be passed to it directly (with the >> parameter type widened to uint32_t). Then the BUG() there could perhaps >> become BUG_ON(errorcode). > > You're right, my conclusion was wrong. > > One more data point, from an hour ago: > > (XEN) [2026-10-26 13:13:42.050] MCE: unknown AMD error code 0x1000 > > So it isn't always 0. The uint16_t truncation might explain the first > (MSEC bits dropped), but 0x1000 is a non-zero code that still matches > none of MC_EC_BUS_TYPE / MC_EC_MEM_TYPE / MC_EC_TLB_TYPE. > > /dev/mcelog right afterwards showed three records, banks 17, 14 and 16, > all CPU 2 (status zero, as above). Banks seen so far across panics and > log lines: 10, 14, 16, 17, 23. > > With the BUG() dropped, the host has now logged this twice with no > panic, no wedged CPU and no hung guests. Everything is running > normally. > > Regarding passing status as uint32_t and BUG_ON(errorcode): with > today's 0x1000, bits 0-31 are non-zero but none of the type bits is > set, so that BUG_ON would still trigger. So unless 0x1000 is a known > type that mc_ec2type() should handle, I think the poller shouldn't BUG > on an unclassifiable code at all. I disagree. That code, aiui, is to decide whether something the hardware reported as uncorrectable can still be recovered from. Seeing an error code of unknown type therefore has to be treated as fatal. Whether that is by keeping that BUG() or by some other means is secondary; continuing to run Xen is putting all of the system's data at risk, even if in your particular instance(s) you didn't observe further anomalies. >>> Both records are again >>> from CPU 2, and bank 23 is one of the banks that appeared in the >>> panics, bank 16 is new. >> Isn't it possible that the lack of 532988dccc19 ("x86/mcheck: fix >> mca_allbanks updating") simply hid the issue previously? > > That is exactly what I suspect. This host, and 10 more with identical > hardware, ran for years on Xen 4.17 without a single incident. The > first panic came within days of upgrading this one to 4.20; the others > are still on 4.17 and still fine. If no bank was being collected > before, nothing could have reached mc_ec2type() -- so the condition > may well have been there the whole time, just never looked at. > > Would it help if I logged the full MCi_STATUS of the first read, i.e. > in mcheck_mca_logout() right after the MCi_STATUS_VAL check, together > with CPU and bank number? Yes please. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:26:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:26:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461525.1672548 (Exim 4.92) (envelope-from ) id 1xLMaX-0001Ib-9b; Mon, 26 Oct 2026 15:26:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461525.1672548; Mon, 26 Oct 2026 15: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 1xLMaX-0001IU-6g; Mon, 26 Oct 2026 15:26:17 +0000 Received: by outflank-mailman (input) for mailman id 1461525; Mon, 26 Oct 2026 15:26:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMaV-0001IO-CD for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:26:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMaU-006BTv-Ku for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:26:14 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf7115-e002-0a2a0a5209dd-0a2a450ce056-4 for ; Mon, 26 Oct 2026 16:26:14 +0100 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf7116-f479-0a2a450c0019-d155dd2ad08a-3 for ; Mon, 26 Oct 2026 16:26:14 +0100 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48e20ed3b9dso2845453f8f.2 for ; Mon, 26 Oct 2026 08:26:14 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3eb8f387sm16698010f8f.4.2026.10.26.08.26.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 08:26: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=1793028374; x=1793633174; 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=tdQM2eFSNPWefP4bSj4yFfMadKxs4191VpFssPoFQ8M=; b=c+YBReD0HWSNHe36yC+2L4wlNXREQX0+X7EIKkgMDGXX6Sn+HObWYrrcBsQ9Y+yyMN 2+Mr9jr38swjMrFxjpYmWzRTQeDnaGuFpo4qWxEFtYIA2CTXvuq1kdK2A8fkrhdVB8eE HyEaeW5GmXawNbhh/TXKCRyfCgDMLFSFc2ls7M0b505jRZQCijuQNBPl2NmbwHM5rp3q SmM3Iq1B5YzVLZuTQsUh+5qbfo7F78ya4L9cgHjiVzITSxbnd3zJ3Q5r5PLjTIvzT/kL 5w242VjmYyTSQf4dpOB6vzkrX0YhUQTHBlGNjZHCZmk2dJiVmCycq6NibxtRGVBIPnxo AebQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793028374; x=1793633174; 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=tdQM2eFSNPWefP4bSj4yFfMadKxs4191VpFssPoFQ8M=; b=g+R803z3i5sDvIMIAErhm71oay+cLhFxDPX9hDvWXGHy4/lrj4IjNSekFzccpuJKgO qo2kn3XOj+H/fSx5EO0FUSoRw/ivAHoNazP2N+xKyvLbGFc0OKNQlZiKmlKszXYg9+ag uVXnu/HEH4qEDzYxipa0fuKD0JZAQNiCjPbHB+h6hF0ZgF1tzYLgfS5rkqxy03sf/fca vvVLUFPDkexbLR7oAY19k43ku90HFowILN0pCCEEaQ4D0pOGaqB9ylAzyPfwTgyIvWTy XaWK12J6XoWqjpseuRdXw/U7iTh1KdxH3Hs1w/cFCBnSEM/Y61ARdzJ/PGJ2sg0Yvqr1 /Wmg== X-Forwarded-Encrypted: i=1; AKwUvBzjKINtZR3bLV/NLAx38LSteSXn1q/W6Peo5eGqGCoUt1kooOc3Yb5oN2e8tCSxPVNVbey4hNMuJ7s=@lists.xenproject.org X-Gm-Message-State: AFq9FYIeyhU/kvuOVTOrLlKeumE8pVfKnXYPq2UMHNKhnjFpttu3hADY Ge1SHSN3SoA+WAKVLCtSF+hc56nYmLu/+8VwZmvjJt3e3CokWHzczq0s X-Gm-Gg: AYBFou2ed30wQUUTxMbEAS2p+3WwntViNi3NbncuUh1ZO7qr/D9ue3IGpUy29N9qRoL LD7f45yHVV3b4qw2U65CN26VdUY8flaNmpypxQcrtbJQ2NyFCL1/Ud6wuvOR7uEwAdSxICilyIg USZ+4wIflA87PB+3mt0FIiqGJ7GG5spLtNr+Vkyj7oB1llP6CQl/akpORBLcvAsnLamj+t4PD/0 aFCrA9YowLMbvj4CSgpWzLGoTfOpuG/JcZKwb8Hf3rXoHcRC5dKcl7aS8m7+XVsdk3U0V+Vbg6M dpQEPKNIoq8Fx5wefdhXDuCRDYxV9tm0xZQnY/LAz0/UllEhHVS4HLJtL5bDQaMST4vRhOUfq8n aRLKLOpcYFiDyAOZ3BBrEFJ6eud8JJeTq25zfutllI1wZrW02iynH1N2CFo4TvtmaTYre0HAqf2 z8Pt1utMVeHHBr7JJznxHmZb5/tKeKRpmf5+mDDRYZYXGJlNjdy4MsCO1Y7alpx9JrPwoh/jckz IEnxR7/DoUkJvgB0Spd4JpxEiB2lNRFT7RA/kWqQAwjRwyw+2M1O0rEoYdGFkKbO1dJ8vVstU3y +Z2q6ctR4vZnyZburoi6792j72Ho X-Received: by 2002:a05:6000:2709:b0:48c:7ee3:e07d with SMTP id ffacd0b85a97d-48e3eb9c260mr8439500f8f.52.1793028373965; Mon, 26 Oct 2026 08:26:13 -0700 (PDT) Message-ID: <1cd34b77-95a4-4ed2-a200-6b6e914fe9d5@gmail.com> Date: Mon, 26 Oct 2026 16:26:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 3/5] xen/riscv: look up the exception table for any trap taken in Xen context To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027684.8631fc262581453bbf619ec5b2062170.1a178c73927000f79f@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1793027684.8631fc262581453bbf619ec5b2062170.1a178c73927000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1793028374-020C1A5B-F74F022A/10/73395122804 X-purgate-type: spam X-purgate-size: 2462 On 10/26/26 4:14 PM, Baptiste Le Duc wrote: > From: Oleksii Kurochko > > do_trap() consulted the exception table only for CAUSE_ILLEGAL_INSTRUCTION, > which covers csr_read_safe() but not a probing access faulting with a page > fault cause: it would reach do_unexpected_trap() instead of its fixup. > There is no such access yet, the A/D update scheme probe will be the first. > > Move the lookup ahead of the cause switch, and only do it for exceptions > taken in Xen context. Both other cases must skip it: > > - Traps taken from the guest: sepc is then a guest address, which the > guest can point at an address listed in the exception table, making Xen > act on an entry fully under guest control. Entries are matched by exact > address, so this needs no more than a numerical collision. Nit: Identations here and .. > > - Interrupts: 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. ... looks incorrect a little bit. An extra space should be dropped. > > Returning early skips check_for_pcpu_work(), which is correct: that only > runs for traps taken from the guest. > > Cache the "trap came from the guest" test in a local as it is now used > three times. > > Signed-off-by: Oleksii Kurochko > [Baptiste: drop the parts depending on the vAPLIC/vIMSIC series, adapt > the commit message] > Assisted-by: Claude:claude-opus-5-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v7: > - new patch, needed by the A/D update scheme probe of the next patch, > whose store page fault would otherwise not be fixed up. Taken from: > https://patch.msgid.link/4e2b4e7a99f4d2133ff92559303d19382749de7a.1790779209.git.oleksii.kurochko@gmail.com > - commit message adapted to this subset: drop the hlv/hlvx and > EX_TYPE_TRAP_INFO parts and the paragraph on the guest page fault > BUG_ON(), whose code isn't taken; mention the from_guest local, which > this subset introduces. > - apply my v3 review suggestion to the commit message: state up front > that the lookup is only done for exceptions taken in Xen context and > list traps taken from the guest and interrupts as the skipped cases. > --- LGTM: Reviewed-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:35:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:35:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461530.1672558 (Exim 4.92) (envelope-from ) id 1xLMjl-0003Uk-3H; Mon, 26 Oct 2026 15:35:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461530.1672558; Mon, 26 Oct 2026 15:35: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 1xLMjl-0003Ud-0f; Mon, 26 Oct 2026 15:35:49 +0000 Received: by outflank-mailman (input) for mailman id 1461530; Mon, 26 Oct 2026 15:35:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMjk-0003UX-2C for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:35:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMji-00EVeq-Vz for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:35:47 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf733f-bab6-0a2a0a5309dd-0a2a45088c1c-34 for ; Mon, 26 Oct 2026 16:35:46 +0100 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 6adf7352-f659-0a2a45080019-d1558032e15c-3 for ; Mon, 26 Oct 2026 16:35:46 +0100 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a7992e2f7dso1896905e9.3 for ; Mon, 26 Oct 2026 08:35:46 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a359fbc718sm169888085e9.2.2026.10.26.08.35.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 08:35: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: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=1793028946; x=1793633746; 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=ArKdPa6IZ/yJ/dSMZV5e1/c7JYalaff2uxtu7hJz/Hw=; b=kXykSvy5v3wcEZFXbxdQh2sEg78O7qJ3q15oOkINkXxWC0XUJOgZo6Cb7YADwjczCN jdG2cF78zsQKuq02whnSn5ocanSjb9Z0yWCAmghnxh7RYUsRJCkZuo5fvV19Ylaq8K6F b4fLAg8B2O/3e4HB13joHVsHaLWPgL4tskO/bTMT35oj25xFaBhIEbKvepcCorD1y50I lJbUsWA1dBFXCjlQwqrkv90Tp/N+czQT/RznnrZSfb9bkBC5a+pU+fYvIojMrNNJEMNT 2rFTtNf8gTICmBjB/TbXsbnjQQzNfFGEgaPjZqSfEZRyTx5phJW6nF0T2YUktJ5LxuMT Zmew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793028946; x=1793633746; 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=ArKdPa6IZ/yJ/dSMZV5e1/c7JYalaff2uxtu7hJz/Hw=; b=BYp4dIBw5rt6v/Yl2les9tbA8IYhS4WHBo3ExJQ/HSk7foUipy9JbN05J6i+i/cHY/ vfMYCSBPqZ3eQjE6/mODDd/SUDO/5vZSS86TWiEc7usIFR4/ngxViHMZ8gmZf4zM1pn3 2QR5rNgNxL9m9QvjxOZ6d064adRwKqIEh2/Dj1P3FIMk40FBvfvnFLJICsVGIf80wfem LCKjO3D7WaXHaxTqOIVTBhPIDDCTyLuvDFsckmwlFV63/mjdIP6lvl5BdnXOtvGJBgtA wKWPjjlg2SfXr70JcKNc3YOzTzWYqPQVv0DtShXYgoclX+QGx2OJSs2d3biTUScpI49l Bq4g== X-Forwarded-Encrypted: i=1; AKwUvBxAQjXjnYZd5s3nfWeo1kB8pwLYyxIl1sLJV1Nc28SFhgC4vgPIi48TMzRyBraiVMgPwbiynQ+tVRc=@lists.xenproject.org X-Gm-Message-State: AFq9FYJJXL8i7ToKqnCAU6QsggPZz8ReDD6IjD3ZLjGXMDUe+9zgWVgH Y+Ha8KkfHUFGgTFnbAxQEvFPgKbwXxjaBLlL5wKuetE8MeWBO2oIVxYN X-Gm-Gg: AYBFou1z1x0BsScNkGmSKY9IDpGRri98ewx2+pgBkzzng8Q+vRBK0yBO+mhQOApQ0Um jhPOJRPN+dAUjxo/+3Ht7GO4vaqJonI6dX60U33djPgW8hSNtB642ngcnvzutMtUHQ6Pi6LwqUw wkirYYU/d9GF8ReUxTZ1BzMTYKfPH2T+UJuhSvT8/+KbS6w2sYxxK2xPIveCvgdwR2N68GFV+3G T1SE21lbNjaEIn+9qcW4y7csqehAR2S62dQHoZOUaHySVn1sHZo9DPO4+YOOmIBp9nhrJpv3fUl VVuL/wXz/JJZvHKudEQuprdLnFW9kpQCtV8nHx3s1XDaswXxjL/Qo6lhiDMuwlDRbySEC41+UVR lgdU1IsiMtODle3g36AwZqX4x1jnyrLwf5fRqJJSOgvGdID7mXfUutr4BZz9SZcY9tmRRC3nncO 2zwB2VPCabXo7UjsEUjjHthZ8x24PyLIIHZ6OuWhtmNQwSqyImMqD/BBqCsifPVxwUQCuLtYFrn YN199Y2BhYfKphI9ydqwkCG8B3dyOMQKzgrbF3oghx1RWxFcA0kVvxjMf5gexJU7IJu9C7eIqd1 s7HJ4oFuG1prbxAG2kLU8HuHi1q7 X-Received: by 2002:a05:600c:1987:b0:4a2:1612:636e with SMTP id 5b1f17b1804b1-4a35ac8b2b2mr122043565e9.5.1793028946126; Mon, 26 Oct 2026 08:35:46 -0700 (PDT) Message-ID: <9986e03e-bf09-46b6-9d2a-82a1864a59b5@gmail.com> Date: Mon, 26 Oct 2026 16:35:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793028946-CCB7187B-A912828A/10/73395122804 X-purgate-type: spam X-purgate-size: 4651 On 10/26/26 4:14 PM, Baptiste Le Duc wrote: > > +/* > + * Probe whether hardware updates the PTE A/D bits by writing to a local > + * variable through an alias mapping whose A and D bits are clear. > + * > + * Check the D bit rather than the A bit, as the A bit may be set > + * speculatively while the D bit can't. > + * > + * Under Svade, the store raises a page fault instead, so use the extable to > + * handle it. > + */ > +static bool __init probe_hw_ad_update(void) > +{ > + unsigned int probe_target; > + vaddr_t va = FIXMAP_ADDR(FIX_MISC) + PAGE_OFFSET(&probe_target); > + pte_t *entry = &xen_fixmap[FIX_MISC]; > + bool d_set = false; > + > + ASSERT(!pte_is_valid(*entry)); > + > + /* > + * Any page in use will do, so alias the stack page this code runs on, > + * with A and D clear. Store to a variable of its own, so that nothing > + * the compiler relies on gets overwritten. > + */ > + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(&probe_target)), > + PTE_VALID | PTE_READABLE | PTE_WRITABLE)); > + flush_tlb_one_local(va); > + > + asm_inline goto ( I think that generally this code should be wrapped by "#ifdef CONFIG_CC_HAS_ASM_GOTO_OUTPUT" but we can keep it as is here as we don't use output operands. > + "1: sw zero, 0(%[va])\n" > + ASM_EXTABLE(1b, %l[out]) > + : > + : [va] "r" (va) > + : "memory" > + : out );> + > + d_set = read_pte(entry).pte & PTE_DIRTY; > + > + out: > + write_pte(entry, (pte_t){}); > + flush_tlb_one_local(va); > + > + return d_set; > +} > + > void __init riscv_fill_hwcap(void) > { > unsigned int i; > @@ -674,6 +721,28 @@ void __init riscv_fill_hwcap(void) > "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " > "wire up this platform's pause equivalent in cpu_relax()\n"); > > + /* > + * The privileged spec allows exactly two schemes for updating the PTE A > + * and D bits: > + * 1) hardware sets them on access and on write; > + * 2) accessing a page whose A and/or D bit is clear raises a page fault, > + * so that software can set them (ratified as Svade). > + * > + * Every implementation uses one of them, but may predate the extensions > + * and advertise neither. In that case, trust the hardware probe. > + */ > + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && > + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > + { > + bool hw_update = probe_hw_ad_update(); > + > + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, > + riscv_isa); > + printk(XENLOG_WARNING > + "Device tree advertises neither Svade nor Svadu, probed %s: add it to \"riscv,isa\"\n", > + hw_update ? "svadu" : "svade"); > + } > + > 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 2973eb13a5..b0a23be18e 100644 > --- a/xen/arch/riscv/include/asm/cpufeature.h > +++ b/xen/arch/riscv/include/asm/cpufeature.h > @@ -8,13 +8,13 @@ > #include > > /* > - * These macros represent the logical IDs of each multi-letter RISC-V ISA > - * extension and are used in the ISA bitmap. The logical IDs start from > - * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single > - * letter extensions and are used in enum riscv_isa_ext_id. > + * Logical IDs of RISC-V ISA extensions, used as bit positions in the ISA > + * bitmap. > * > - * New extensions should just be added to the bottom, rather than added > - * alphabetically, in order to avoid unnecessary shuffling. > + * Single-letter extensions use IDs below RISCV_ISA_EXT_BASE and are sorted > + * alphabetically. Multi-letter extensions start from RISCV_ISA_EXT_BASE and > + * follow the same order as riscv_isa_ext[] (see the ordering rules described > + * above it). > */ > #define RISCV_ISA_EXT_BASE 26 > > @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { > RISCV_ISA_EXT_ssaia, > RISCV_ISA_EXT_sstc, > RISCV_ISA_EXT_svade, > + RISCV_ISA_EXT_svadu, > RISCV_ISA_EXT_svpbmt, > RISCV_ISA_EXT_MAX > }; > Generally, looks good to me: Reviewed-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:39:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:39:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461535.1672567 (Exim 4.92) (envelope-from ) id 1xLMnA-000433-HI; Mon, 26 Oct 2026 15:39:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461535.1672567; Mon, 26 Oct 2026 15:39: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 1xLMnA-00042w-EQ; Mon, 26 Oct 2026 15:39:20 +0000 Received: by outflank-mailman (input) for mailman id 1461535; Mon, 26 Oct 2026 15:39:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLMn9-00042q-9e for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:39:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMn8-00HJiQ-FE for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:39:18 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf741f-bab6-0a2a0a5309dd-0a2a4508b600-12 for ; Mon, 26 Oct 2026 16:39:18 +0100 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 6adf7426-f659-0a2a45080019-b9ff1c2294b9-3 for ; Mon, 26 Oct 2026 16:39:18 +0100 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 1a178ddb234000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:39:17 +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 6A66582E5C; Mon, 26 Oct 2026 16:39:16 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=W9cgPuSnp07sqtpr6b1HIev5P/fXUAKXUDQbiH6pCjk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=HumwHu07t01mlJLs5kgW1CZdMkXGahoMiSH1Ode+BFfQ+kngx5wEXa+4TIRcFje/wyUGBqUyV zlNFhiFSGekU9QiF7YEk0e3tkv3dM9N85968HGt5Qspa4W5D3YL10RzL/KOqxocVfeVqvyKUAOf akObij6IFcSfRI8yTP7K2yQmMazRj2NfK6MHT0/k7+Y6OCg0oc8N0MW1FW3GJ+qr27qYULd1hdL hgqLe4kKu4RV+Ssvcy9kZo+6YB8jy5QWwcAXY4dfQ3ehDbGZWiswNVAog0/2FOmJovCRiqEmFro OFUo85Zrcd0El7HYdsrMyagj1jeA4vXpFeJWOChExdOg== X-Zone-Loop: ae3a0b935d09a42b17fe36e8469aa5274c6015090df5 x-campaign-type: default x-transaction-id: bfd348b4-d08c-46a4-9aec-6f74a87729ac x-swg-uid: 01-847c607d-7c8a-4aef-b33f-bce16f3c4efa X-Mailer: Sweego Message-ID: <1793029157.8631fc262581453bbf619ec5b2062170.1a178ddb234000f79f@vates.tech> x-swg-bid: 1793029157.8631fc262581453bbf619ec5b2062170.1a178ddb234000f79f 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] x86/nestedhvm: Inline nestedhvm_vcpu_in_guestmode() Date: Mon, 26 Oct 2026 16:38:25 +0100 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.200.1a5b3fe219041a6.1a178ddaed4.db010e8b2648ab06=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793029156564 X-purgate-ID: tlsNG-c1860d/1793029158-CFCD387B-4D3766D1/0/0 X-purgate-type: clean X-purgate-size: 2115 ---=Part.200.1a5b3fe219041a6.1a178ddaed4.db010e8b2648ab06=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This function just returns vcpu_nestedhvm(v)=2Env_guestmode and would be better inlined to improve codegen=2E Signed-off-by: Teddy Astie --- v2: - make vcpu const - remove non useful comments xen/arch/x86/hvm/nestedhvm=2Ec | 7 ------- xen/arch/x86/include/asm/hvm/nestedhvm=2Eh | 7 +++++-- 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/hvm/nestedhvm=2Ec b/xen/arch/x86/hvm/nestedhvm= =2Ec index bddd77d810=2E=2E3205277e81 100644 --- a/xen/arch/x86/hvm/nestedhvm=2Ec +++ b/xen/arch/x86/hvm/nestedhvm=2Ec @@ -15,13 +15,6 @@ =20 static unsigned long *shadow_io_bitmap[3]; =20 -/* Nested VCPU */ -bool -nestedhvm_vcpu_in_guestmode(struct vcpu *v) -{ - return vcpu_nestedhvm(v)=2Env_guestmode; -} - void nestedhvm_vcpu_reset(struct vcpu *v) { diff --git a/xen/arch/x86/include/asm/hvm/nestedhvm=2Eh b/xen/arch/x86/inc= lude/asm/hvm/nestedhvm=2Eh index ea2c1bc328=2E=2E8a2a0fbb3c 100644 --- a/xen/arch/x86/include/asm/hvm/nestedhvm=2Eh +++ b/xen/arch/x86/include/asm/hvm/nestedhvm=2Eh @@ -28,11 +28,14 @@ static inline bool nestedhvm_enabled(const struct doma= in *d) return IS_ENABLED(CONFIG_HVM) && (d->options & XEN_DOMCTL_CDF_nested_= virt); } =20 -/* Nested VCPU */ +static inline bool nestedhvm_vcpu_in_guestmode(const struct vcpu *v) +{ + return vcpu_nestedhvm(v)=2Env_guestmode; +} + int nestedhvm_vcpu_initialise(struct vcpu *v); void nestedhvm_vcpu_destroy(struct vcpu *v); void nestedhvm_vcpu_reset(struct vcpu *v); -bool nestedhvm_vcpu_in_guestmode(struct vcpu *v); #define nestedhvm_vcpu_enter_guestmode(v) \ vcpu_nestedhvm(v)=2Env_guestmode =3D 1 #define nestedhvm_vcpu_exit_guestmode(v) \ --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.200.1a5b3fe219041a6.1a178ddaed4.db010e8b2648ab06=--- From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:39:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:39:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461541.1672576 (Exim 4.92) (envelope-from ) id 1xLMnf-0004SF-On; Mon, 26 Oct 2026 15:39:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461541.1672576; Mon, 26 Oct 2026 15:39: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 1xLMnf-0004S8-M2; Mon, 26 Oct 2026 15:39:51 +0000 Received: by outflank-mailman (input) for mailman id 1461541; Mon, 26 Oct 2026 15:39:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLMne-0004Rs-FY for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:39:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMnY-003iI9-S7 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:39:49 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf7440-8faa-0a2a0a5109dd-0a2a4503e1b0-4 for ; Mon, 26 Oct 2026 16:39:44 +0100 Received: from [40.107.162.75] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf7440-fae8-0a2a45030019-286ba24bf175-3 for ; Mon, 26 Oct 2026 16:39:44 +0100 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by VI1PR03MB6270.eurprd03.prod.outlook.com (2603:10a6:800:139::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.20; Mon, 26 Oct 2026 15:39:42 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 15:39: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=JnfmSM8NhbtgOjrhTXHS11YFFR3JrmetY2mlQ3VbiJTKr6L/8g1nMriVdNd6lDzgahniYpfo1a3yhGPRiTA4JxXKdDhf60m+jREVgy3Ld84/UNE0G7K+Gt8rOoDl3U+kYhETP2K07PqAB4mhtM5bQEjY7kcmPKi1zFmOpWx0eo/wdBYf/Il7Pw0LN3aL5MZMOMY63CoibnE45ObmTjPeCtRsZGz7RZvXMambjV81ElVPOJM25iqERuEA4NbzCTKBvIq2BJJfd9khJYG4jcRJvwB7oCs0v9bH6C3jOzbojgQO15X5FXYtSTcWjES05g2eAbwj82hWf0hjsrDY9G/lPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vxxltKE1h6mF5AT/bWiUH/+eoHghOgv92+KRFNeT0fA=; b=sLqy4lnhqMktDuwURSD4CN2rMQON0O2OkBxYsVdiCcaufY9tZxxFfKvUYo8V2lH9dkkMjMzVW4cz2/RoAr2x46gQ9rQls/J2xmCC6cPgv4Tstz6luQnc+0S8DUlVTED0wwLeB5PSandKYLKvyG0zpbKiprGV56+jk0hnQcAZL+4cgctBWgHKhmexzcGEDRxfMYRpB/PJ24MRXngVyqQv6ztqhoJUJZzzhVXNmPBI9Cllyp1UKqZ5v08KVy1zedj++JIh5+LodNRKVhidgNK9ZKCOm0kSQ0/hAEti4bcEGrAcGIDpn9j6nb4NsQKucCjjKUWv4lU2jmDtcDkogna8MA== 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=vxxltKE1h6mF5AT/bWiUH/+eoHghOgv92+KRFNeT0fA=; b=QNs/yOHk8YL7RjG0iqsn9MqXl1+bxaN8suCKxLNew3e+1UxMcKzpd3GsOTkTNherDOBUfv7e1Ebe/Ze4pbCAXNrrf5VRncqX4P4GzN0fyNjW2GI04OF5A4GDMyp8jhtZwUrYQNDj4tOduwRrtv4b8rqcqXppamNpdWsrZt+S1RW0hKCJ8aXWti/scKYWzwKJjBOY7TY1o/nLUu+VtOEK9r4sNsvycelasvhdIv09PfWZY39/i3iZMsYbtAKSNO+WS7nf923+CZWEG1bTz8b+q9/7NJavM7Lwrev2H815p4sDzrQnpNRRVGoUDGBmueWFl6MOATI/OMTHKz8KuZTMkQ== 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 v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdYG8PUG4uC8qBAkeMIAyIqnSgzLcP/48A Date: Mon, 26 Oct 2026 15:39:40 +0000 Message-ID: <8d8985e3-fd09-4664-abaa-c3c0f4ca33d6@epam.com> References: <87mrs5tc1g.fsf@epam.com> In-Reply-To: <87mrs5tc1g.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: GVXPR03MB11113:EE_|VI1PR03MB6270:EE_ x-ms-office365-filtering-correlation-id: fb47f049-2a28-40d7-9520-08df337759c5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016|23010399003|261026135527099003|38070700021|261026140227099003|260925022911599003|261026130827099003|260925021311599003|260925021911599003|4143699003|56012099006|11063799006|261021135927099003|261009223027099003|261022113327099003|261022075727099003|261021123027099003|261021133027099003|261021130227099003|261021121427099003|261022105027099003|261022115727099003|10067099003|261026121527099003|22082099003|18002099003|6133799003|3023799007; x-microsoft-antispam-message-info: X6aMMIWldHcqYuDbSumhncOR9DPNHg9JKrfpWftZljvn6Dnb1X9zl1VD4FhUEA6rAzAHoQvj4FmmMhATxpKbEKQx3HYMMjxeesVtWkFGt3zA3gftXxP4ESs6Apmn7oW66c5MMC6ObO2uKevefCWjfWu4rIp+RzUZ5moqbE7OQCSeJfnFY0jepKbCTNdBST8cxkJxISY6Cv7wHBx0Ktfzby+JfD1roF32YQaP+iRPCWZuyX4yx23qBwO+LsdOabrv7t5eHavtH/r7cTziyCZbjrAdcKquVgr35ozspeBV0bu9Smz1HmGvcFXydIQerdn9MTOJvVizkgnjLf1WW94AGknKhBl2ZUg01LDOKYnPLtchRO/dtil9Opm1sq4LwFDs1Lr8StQJSq5RB1jDdTE+9ln/TgK3miha+ILFSCM3LxHR3cSnbhSJ8DZyqQNg6XYQu1ztu5ePoDS8G/v4ywJe6tnTTrmx2hLt4U2bCxY8vNGWYmz1BrPG3iCL8WPUsLVBJAg67dLtkZ5Y+o5KmbPt6ehL2SjRIS0zH4mm013E3ityeE8l+PNHCJ6FTFAkL6jqaTLlSzsqsmiz4MYwmUSy3n0uIoiSfOzd1s7926OCehbsYpTMYme4PS/0v51ICPOR58iOsZxHpAhfcdQlmZ/j9C4DO1Jz6vMQOPHXqJgUbBODNYuKy6wpZZQYEHWM7y/XlegEYcNpiyKEcwzYf/1mFmdvBUjP3p4woJwNlBxP+Ag= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016)(23010399003)(261026135527099003)(38070700021)(261026140227099003)(260925022911599003)(261026130827099003)(260925021311599003)(260925021911599003)(4143699003)(56012099006)(11063799006)(261021135927099003)(261009223027099003)(261022113327099003)(261022075727099003)(261021123027099003)(261021133027099003)(261021130227099003)(261021121427099003)(261022105027099003)(261022115727099003)(10067099003)(261026121527099003)(22082099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WDJid05qUlVzOVBrWmxvb0M0RjZOWGNNdjNwcGp4Y0pwU2xFU3pPdGZ6SlVR?= =?utf-8?B?WnVwT3pKZ01GbWtBLzRZQ2szR2MwalAreVVwbE95eWdUS29aMHdsVjBrMnF0?= =?utf-8?B?VUxvTUVXUnl0OXRoWG9RUVVGbVZFTkplVktTbE52OW5OdEFIRER6MFQrKzUz?= =?utf-8?B?alQxS0tEQU02c2EwM0M5MVlGbEtrMmUzNmZRS0ZXQ2ZuYTJwdUdvTndvZEFt?= =?utf-8?B?eG1CZGFPQ0gwT1BnRVhnN21LcjZPb1dIbktXMlR6SS9FQUN3UzhJWThuUVJM?= =?utf-8?B?KzZQdlAzUlNJMHNhNjM2Ym1Zb0dNUVVkdEdCMFZVL2RnRFk3OG1TdUpzRG5D?= =?utf-8?B?QnNkUjJKY2JpcTF4WlRtVE5NV2pjWjRobFZieTZXOE16Tld5MDVCUjBEb0pM?= =?utf-8?B?MDlTODVpWGgyOEFJWUNnSEhKUWRRSm8xS0VSVGsrMHlmb0xORnp5VjVpMFkw?= =?utf-8?B?cFFKWGo1eDJBdGZCM0VQcUptL3d5djJpUTR4aUhMZXk1bXFhelF3UFBDUFlC?= =?utf-8?B?TDJUN2w3c21uOWYvUXkrdWdjMGJyQitaUm1FTFBtbkRUaWVQRkRLT2pjTXVN?= =?utf-8?B?MU5XcUE0YlVkSHhlVlFXMDVzUndsTW5TZS9PZkpSSWI1NGJYeVhNT1NSTzZs?= =?utf-8?B?UVdlUktqT0FYdS8xZXB4NEFIUmpKOUlQaTBFTEtTd2ZjbHF4cDMyc1pPdVBO?= =?utf-8?B?Y3ZnWWFxRnZLdVJEVlVxTHUwaGdFdEprRDdyeURmbWhYa0tJTGJHWUErbk5L?= =?utf-8?B?UW9sZCtwU2IvNmJKWkhNSGJvNzUvYWwzR0F2Zk5tTDBKN0lOdWRRUFRaV3pz?= =?utf-8?B?RkVjRlJiOTczcURRdFV4S05RMVYzU014dGVDUVpRRHV3MjFablc2Z2VSVTVW?= =?utf-8?B?UFZtNGpQd2VBd0hOSC84Z1hidmNyeHNXMlYvQjMzVUlhM0NMaVQ1TTNsNGVl?= =?utf-8?B?RGVybUU5cHBiejJNR3hDRm5tUXBWRVNjMyswbDBPbzV5aDFwam9kc05RbU5m?= =?utf-8?B?d0hkOHJzejhFRUdzY0VHcTZGTVkyWVAwY3hHeTBXaENIbmx5QWlTZjA1RFJ2?= =?utf-8?B?Z2RTRFdJMDNGdDhLdmlWaC8rQ3hSbnM2cVBOMXcrME9pZk1SMS84ZVZFK21T?= =?utf-8?B?WEFUSVhSRjlwQmxzVGg1T2FvQVlhdTh2QVl0NlpvbnkrNE4yQ2JUR1ZCM3Jz?= =?utf-8?B?Ynp2azQ2Zmd3NUMvbE9ndVpBSlBqUGhRRHRFMTVLY3VkOTVCYm45dGhiVmly?= =?utf-8?B?V1FpQmxNbEJQMkdCMVJrZEdVZmZwUVBNTGZIVUkvdyt6a2dUekw0RTZkbDUy?= =?utf-8?B?NEZOTnh4T2pTWDJkUFJKV0tRZTYwNSticURYV01PZXRsNlBUK09sNWFaVk9x?= =?utf-8?B?ZkxiZ0dJSStaSVdBVFhjSFB2dmJlV2JNcjF2dU9UdDlURlBWZldXb3lkc1B4?= =?utf-8?B?N05sTW1aSnlaRkV4WjBxSkZ1cm5POWtuS2hjYU9icUQ5TVhQQitxT2kwMk1n?= =?utf-8?B?aTh4MERaRVJJYkNDdFdFT0U3ZUNhTEdFTmJLbXF4YmRObjltaTRZVis1aXh0?= =?utf-8?B?QUlLVHhqdEE4WXAwdTFnaFVqZG9hWFJ4bnpSbVVmNmNPakxrRVNVM2RPbE1Z?= =?utf-8?B?bzZkMjdUcnAvSkUyMzV0RFBWZERoVExWUCtIYVJCWVRiNDVWcGRYQy9jT2FG?= =?utf-8?B?b0xYOFhwUWM0dTJIeWV4RUJIYU11dzJHQWRhNFl0TnBCUXFxOXQ2anlCM3Mz?= =?utf-8?B?T3RhK0U3alFhMnpQcUJXdUthYUxyY2NEZmNnbFl4ZTBteVFpeHo1U1Z0WkhY?= =?utf-8?B?U1dHd3M1Y2l2dHVONVBRamp3dGRSekoyejlRdTh2eUkzR3JWMitkNnYvcWg1?= =?utf-8?B?SnJBZWJiNnJEeEVLaExWQ0dGdmxoV0NMZ0o0TTJyazFoOVdHK3FkQk5ZcUNS?= =?utf-8?B?bFZVUHl2UjlTWnIrMktXMkFXeHVWWnVEcU1hNzhZQ09NSXBqbTBxazF0bm9t?= =?utf-8?B?QjVtb0hnUGZlODJNak9OcGlBeGY2czB3ZUJKTDJncFJHbVh2NkpsTHFXeVRJ?= =?utf-8?B?cFhJNU9ZTDRVbVZxQ01oNzg3RzVVOEMremlZNFFRS3lKUlZzZmZvU2lrQ3Fy?= =?utf-8?B?c3BnU1lQUDVRNjRBS0NnRU8zM0ZmQVNnbUFwdWw2dDRtRnlWVGZVdGJZcVFj?= =?utf-8?B?VkwwRUlIaWdQM0h6Q0g2NW9JNVdrWi96aDZvb0xLOVJHVVFMVXh4dERNc2pZ?= =?utf-8?B?OG5uK29zcjQ3Mm8vT0xzMTRBNmNHeDE0cW82bCtOTGhzUGI2VEFKZklpaXdu?= =?utf-8?B?YmxEaXlUcm9XVW9ZTytXTHY5ZzFaQUIwYnpab0pUUFhYQmlWMENIMGE1R256?= =?utf-8?Q?CXomH2wChLw6MHG0=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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb47f049-2a28-40d7-9520-08df337759c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 15:39:40.9741 (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: 2ojvBO1HVcPv7BApfVX94nyEHEz2/JgUKnysJLzn0Xg6Xri4GPC1fNiprbubkbei1i1RmklOFZ+J68R4QAXS2U4f9wDo0T3Om5HrCGzICYM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6270 X-purgate-ID: tlsNG-33051d/1793029184-762FD4E9-D5D3296E/0/0 X-purgate-type: clean X-purgate-size: 48054 SGkgVm9sb2R5bXlyLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIEkgYWdyZWUgd2l0aCB0 aGUgbW9zdCBvZiB5b3VyIGNvbW1lbnRzLCBqdXN0IA0KZmV3IG1vcmUgcXVlc3Rpb25zIGxlZnQ6 DQoNCk9uIDIzLzEwLzIwMjYgMDQ6NTYsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPiBIaSBP bGVrc2lpLA0KPg0KPiBPbGVrc2lpIE1vaXNpZWlldiA8T2xla3NpaV9Nb2lzaWVpZXZAZXBhbS5j b20+IHdyaXRlczoNCj4NCj4+IFRoaXMgcGF0Y2ggaW50cm9kdWNlcyBTQ0kgZHJpdmVyIHRvIHN1 cHBvcnQgZm9yIEFSTSBFTDMgVHJ1c3RlZCBGaXJtd2FyZS1BDQo+PiAoVEYtQSkgd2hpY2ggcHJv dmlkZXMgU0NNSSBpbnRlcmZhY2Ugd2l0aCBtdWx0aS1hZ2VudCBzdXBwb3J0LCBhcyBzaG93bg0K W3NuaXBdDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0u YyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+IG5ldyBmaWxlIG1vZGUg MTAwNjQ0DQo+PiBpbmRleCAwMDAwMDAwMDAwLi5lMzY3NDVhODVlDQo+PiAtLS0gL2Rldi9udWxs DQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5jDQo+PiBAQCAtMCww ICsxLDExOCBAQA0KPj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkg Ki8NCj4+ICsvKg0KPj4gKyAqIFNNQy9IVkMgc2htZW0gdHJhbnNwb3J0IGltcGxlbWVudGF0aW9u IHVzZWQgYnkNCj4+ICsgKiBTQ0kgU0NNSSBtdWx0aS1hZ2VudCBkcml2ZXIuDQo+PiArICoNCj4+ ICsgKiBPbGVrc2lpIE1vaXNpZWlldiA8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+PiAr ICogQ29weXJpZ2h0IChjKSAyMDI1IEVQQU0gU3lzdGVtcw0KPj4gKyAqLw0KPj4gKw0KPj4gKyNp bmNsdWRlIDx4ZW4vZXJyLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9pby5oPg0KPj4gKyNpbmNsdWRl IDxhc20vaW8uaD4NCj4+ICsNCj4+ICsjaW5jbHVkZSAic2NtaS1wcm90by5oIg0KPj4gKyNpbmNs dWRlICJzY21pLXNobWVtLmgiDQo+PiArDQo+PiArc3RhdGljIGlubGluZSBpbnQNCj4+ICtzaG1l bV9jaGFubmVsX3N0YXR1cyhjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9f aW9tZW0gKnNobWVtKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJuIChyZWFkbCgmc2htZW0tPmNoYW5u ZWxfc3RhdHVzKSAmDQo+PiArICAgICAgICAgICAgU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5F TF9GUkVFKSA/IDAgOiAtRUJVU1k7DQo+PiArfQ0KPj4gKw0KPj4gK2ludCBzaG1lbV9wdXRfbWVz c2FnZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtLA0KPj4g KyAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lkICpkYXRh LCB1bnNpZ25lZCBpbnQgbGVuKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJldDsNCj4+ICsNCj4+ICsg ICAgaWYgKCAobGVuICsgb2Zmc2V0b2Yoc3RydWN0IHNjbWlfc2hhcmVkX21lbSwgbXNnX3BheWxv YWQpKSA+DQo+PiArICAgICAgICAgU0NNSV9TSE1FTV9NQVBQRURfU0laRSApDQo+PiArICAgIHsN Cj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBXcm9uZyBzaXplIG9mIHNtYyBt ZXNzYWdlLiBEYXRhIGlzIGludmFsaWRcbiIpOw0KPiAib2YgdGhlIFNNQyBtZXNzYWdlIi4gQWxz bywgbG9va3MgbGlrZSBpdCBpcyBvdmVyIDgwIGNoYXJhY3RlcnMuDQphZ3JlZWQgd2l0aCBib3Ro LiB0aGFuayB5b3UuDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4g Kw0KPj4gKyAgICByZXQgPSBzaG1lbV9jaGFubmVsX3N0YXR1cyhzaG1lbSk7DQo+PiArICAgIGlm ICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIHdyaXRlbF9y ZWxheGVkKDB4MCwgJnNobWVtLT5jaGFubmVsX3N0YXR1cyk7DQo+PiArICAgIC8qIFdyaXRpbmcg MHgwIHJpZ2h0IG5vdywgYnV0ICJzaG1lbSJfRkxBR19JTlRSX0VOQUJMRUQgY2FuIGJlIHNldCAq Lw0KPj4gKyAgICB3cml0ZWxfcmVsYXhlZCgweDAsICZzaG1lbS0+ZmxhZ3MpOw0KPj4gKyAgICB3 cml0ZWxfcmVsYXhlZChzaXplb2Yoc2htZW0tPm1zZ19oZWFkZXIpICsgbGVuLCAmc2htZW0tPmxl bmd0aCk7DQo+PiArICAgIHdyaXRlbChwYWNrX3NjbWlfaGVhZGVyKGhkciksICZzaG1lbS0+bXNn X2hlYWRlcik7DQo+IFdoeSBkbyB5b3UgbWl4IHdyaXRlbCgpIGFuZCB3cml0ZWxfcmVsYXhlZCgp IGhlcmU/DQoNClRoZSBtYWluIGlkZWEgdGhhdCBJJ20gZmlsbGluZyB1cCBTQ01JIGhlYWRlciBp bmZvcm1hdGlvbiBmb2xsb3dpbmcgDQpEZXZpY2UgbWVtb3J5IG9yZGVyaW5nIGFuZCBleGVjdXRl IF9faW93bWIgYmVmb3JlIHN0b3JlIGluIHRoZSBsYXN0IA0Kd3JpdGVsIGNhbGwuDQoNCg0KPj4g Kw0KPj4gKyAgICBpZiAoIGxlbiA+IDAgJiYgZGF0YSApDQo+PiArICAgICAgICBtZW1jcHlfdG9p byhzaG1lbS0+bXNnX3BheWxvYWQsIGRhdGEsIGxlbik7DQo+PiArDQo+PiArICAgIHJldHVybiAw Ow0KPj4gK30NCj4+ICsNCj4+ICtpbnQgc2htZW1fZ2V0X3Jlc3BvbnNlKGNvbnN0IHZvbGF0aWxl IHN0cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW0sDQo+PiArICAgICAgICAgICAg ICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lkICpkYXRhLCB1bnNpZ25lZCBp bnQgbGVuKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJlY3ZfbGVuOw0KPj4gKyAgICBpbnQgcmV0Ow0K Pj4gKyAgICAvKg0KPj4gKyAgICAgKiBGaXJzdCB3b3JkIG9mIG1zZ19wYXlsb2FkIGNhcnJpZXMg dGhlIHJldHVybmVkIHN0YXR1czsgZXhjbHVkZSBpdCBmcm9tDQo+PiArICAgICAqIHJlY3ZfbGVu IHNvIG9ubHkgdGhlIHByb3RvY29sIHBheWxvYWQgaXMgY29waWVkIGJhY2sgdG8gdGhlIGNhbGxl ci4NCj4+ICsgICAgICovDQo+PiArICAgIGludCBwYWQgPSBzaXplb2YoaGRyLT5zdGF0dXMpOw0K Pj4gKw0KPj4gKyAgICBpZiAoIGxlbiA+PSBTQ01JX1NITUVNX01BUFBFRF9TSVpFIC0NCj4+ICsg ICAgICAgICBvZmZzZXRvZihzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtLCBtc2dfcGF5bG9hZCkgKQ0K Pj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAg ICAgICJzY21pOiBXcm9uZyBzaXplIG9mIGlucHV0IHNtYyBtZXNzYWdlLiBEYXRhIG1heSBiZSBp bnZhbGlkXG4iKTsNCj4gIm9mIHRoZSBpbnB1dCBTTUMgbWVzc2FnZSINCisxDQo+PiArICAgICAg ICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXQgPSBzaG1lbV9j aGFubmVsX3N0YXR1cyhzaG1lbSk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIHJl dHVybiByZXQ7DQo+PiArDQo+PiArICAgIHJlY3ZfbGVuID0gcmVhZGwoJnNobWVtLT5sZW5ndGgp IC0gc2l6ZW9mKHNobWVtLT5tc2dfaGVhZGVyKTsNCj4+ICsNCj4+ICsgICAgaWYgKCByZWN2X2xl biA8IDAgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAg ICAgICAgICAgICAgICJzY21pOiBXcm9uZyBzaXplIG9mIHNtYyBtZXNzYWdlLiBEYXRhIG1heSBi ZSBpbnZhbGlkXG4iKTsNCj4gIm9mIHRoZSBTTUMgbWVzc2FnZSINCj4NCj4gQWxzbywgSSBhbSB3 b25kZXJpbmcgaWYgeW91IHJlYWxseSBuZWVkIHRvIHByaW50IHRoaXMgZXJyb3IgbWVzc2FnZXMg aW4NCj4gdGhlIGZpcnN0IHBsYWNlLg0KPg0KVGhlc2UgZ2VuZXJpYyBtZXNzYWdlcyB3ZXJlIHZl cnkgaGVscGZ1bCBpbiBkZXRlcm1pbmluZyB0aGUgZXhhY3QgZXJyb3IuIA0KRm9yIGV4YW1wbGUs IHRoaXMgZnVuY3Rpb24gcmV0dXJucyAtRUlOVkFMIGJvdGggaWYNCg0KICBsZW4gPj0gU0NNSV9T SE1FTV9NQVBQRURfU0laRSAtICBvZmZzZXRvZihzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtLCBtc2df cGF5bG9hZCkgIGFuZCBpZiByZWN2X2xlbiA8IDANCiAgDQpIb3dldmVyLCBpZiB5b3UgdGhpbmsg dGhleSBhcmUgZXhjZXNzaXZlLCBJIGNhbiByZW1vdmUgdGhlIHByaW50cyBhbmQgcmV0dXJuIGRp ZmZlcmVudCBlcnJvciBjb2RlcyBpbnN0ZWFkLg0KDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZB TDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICB1bnBhY2tfc2NtaV9oZWFkZXIocmVhZGwoJnNo bWVtLT5tc2dfaGVhZGVyKSwgaGRyKTsNCj4+ICsNCj4+ICsgICAgaGRyLT5zdGF0dXMgPSByZWFk bCgmc2htZW0tPm1zZ19wYXlsb2FkKTsNCj4+ICsgICAgcmVjdl9sZW4gPSByZWN2X2xlbiA+IHBh ZCA/IHJlY3ZfbGVuIC0gcGFkIDogMDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gc2NtaV90b194ZW5f ZXJybm8oaGRyLT5zdGF0dXMpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgIHsNCj4+ICsg ICAgICAgIHByaW50ayhYRU5MT0dfREVCVUcgInNjbWk6IEVycm9yIHJlY2VpdmVkOiAlZFxuIiwg cmV0KTsNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAg aWYgKCByZWN2X2xlbiA+IGxlbiApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5M T0dfRVJSDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IE5vdCBlbm91Z2ggYnVmZmVyIGZvciBt ZXNzYWdlICVkLCBleHBlY3RpbmcgJWRcbiIsDQo+PiArICAgICAgICAgICAgICAgcmVjdl9sZW4s IGxlbik7DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4g KyAgICBpZiAoIHJlY3ZfbGVuID4gMCApDQo+PiArICAgICAgICBtZW1jcHlfZnJvbWlvKGRhdGEs IHNobWVtLT5tc2dfcGF5bG9hZCArIHBhZCwgcmVjdl9sZW4pOw0KPj4gKw0KPj4gKyAgICByZXR1 cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+PiAr ICogbW9kZTogQw0KPj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsgKiBjLWJhc2ljLW9m ZnNldDogNA0KPj4gKyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10YWJzLW1vZGU6IG5p bA0KPj4gKyAqIEVuZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmly bXdhcmUvc2NtaS1zaG1lbS5oIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0K Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+IGluZGV4IDAwMDAwMDAwMDAuLjcyMjI2M2FhNzcN Cj4+IC0tLSAvZGV2L251bGwNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNo bWVtLmgNCj4+IEBAIC0wLDAgKzEsNDUgQEANCj4+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmll cjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBBcm0gU3lzdGVtIENvbnRyb2wgYW5k IE1hbmFnZW1lbnQgSW50ZXJmYWNlIGRlZmluaXRpb25zDQo+PiArICogVmVyc2lvbiAzLjAgKERF TjAwNTZDKQ0KPj4gKyAqIFNoYXJlZCBNZW1vcnkgYmFzZWQgVHJhbnNwb3J0DQo+PiArICoNCj4+ ICsgKiBDb3B5cmlnaHQgKGMpIDIwMjQgRVBBTSBTeXN0ZW1zDQo+PiArICovDQo+PiArDQo+PiAr I2lmbmRlZiBBUk1fRklSTVdBUkVfU0NNSV9TSE1FTV9IXw0KPj4gKyNkZWZpbmUgQVJNX0ZJUk1X QVJFX1NDTUlfU0hNRU1fSF8NCj4+ICsNCj4+ICsjaW5jbHVkZSA8eGVuL3N0ZGludC5oPg0KPj4g Kw0KPj4gKyNkZWZpbmUgU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5FTF9GUkVFICBCSVQoMCwg VUwpDQo+PiArI2RlZmluZSBTQ01JX1NITUVNX0NIQU5fU1RBVF9DSEFOTkVMX0VSUk9SIEJJVCgx LCBVTCkNCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIHsNCj4+ICsgICAgdWludDMy X3QgcmVzZXJ2ZWQ7DQo+PiArICAgIHVpbnQzMl90IGNoYW5uZWxfc3RhdHVzOw0KPj4gKyAgICB1 aW50MzJfdCByZXNlcnZlZDFbMl07DQo+PiArICAgIHVpbnQzMl90IGZsYWdzOw0KPj4gKyAgICB1 aW50MzJfdCBsZW5ndGg7DQo+PiArICAgIHVpbnQzMl90IG1zZ19oZWFkZXI7DQo+PiArICAgIHVp bnQ4X3QgbXNnX3BheWxvYWRbXTsNCj4+ICt9Ow0KPiBTaG91bGQgaXQgYmUgX19wYWNrZWQ/DQpU aGUgbGF5b3V0IGFscmVhZHkgbWF0Y2hlcyB0aGUgc2hhcmVkLW1lbW9yeSBmb3JtYXQgd2l0aG91 dCBwYWRkaW5nOg0KRXZlcnkgZml4ZWQgbWVtYmVyIGlzIGEgdWludDMyX3Qgb3IgYW4gYXJyYXkg b2YgdWludDhfdCwgYW5kIHRoZQ0KbWFwcGluZyBpcyBwYWdlIGFsaWduZWQuDQoNClRoZXJlZm9y ZSBfX3BhY2tlZCB3b3VsZCBub3QgY2hhbmdlIHRoZXNlIG9mZnNldHMsIGJ1dCB3b3VsZCByZWR1 Y2UgdGhlDQpzdHJ1Y3R1cmUncyBhbGlnbm1lbnQgZ3VhcmFudGVlLiBJIHdvdWxkIHByZWZlciB0 byBrZWVwIHRoZSBuYXR1cmFsDQphbGlnbm1lbnQgYW5kIGFkZCBjb21waWxlLXRpbWUgb2Zmc2V0 IGNoZWNrcyB0byBkb2N1bWVudCB0aGUgdHJhbnNwb3J0DQpsYXlvdXQuIERvZXMgdGhhdCBhZGRy ZXNzIHlvdXIgY29uY2Vybj8NCj4+ICsNCj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1fTUFQUEVEX1NJ WkUgUEFHRV9TSVpFDQo+PiArDQo+PiAraW50IHNobWVtX3B1dF9tZXNzYWdlKHZvbGF0aWxlIHN0 cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW0sDQo+IEkgYW0gbm90IHN1cmUgaWYg dm9sYXRpbGUgbWFrZXMgc2Vuc2UgaGVyZSwgdGFraW5nIGludG8gYWNjb3VudCB0aGF0DQo+IHRo aXMgaXMgX19pb21lbSBhbnl3YXkuDQo+DQo+IEFsc28sIHNobWVtX3B1dF9tZXNzYWdlIHNvdW5k cyB0byBnZW5lcmljLi4uIE1heWJlIHNjbWlfcHV0X21lc3NhZ2U/DQoNCkFncmVlZC4gdm9sYXRp bGUgbG9va3MgdW5uZWVkZWQgaGVyZS4gSSB3aWxsIHJlbW92ZSB2b2xhdGlsZSBhbmQgdXNlIA0K c2NtaV97Z2V0L3B1dH1fbWVzc2FnZSBmdW5jdGlvbiBuYW1lcy4NCg0KDQo+PiArICAgICAgICAg ICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRhdGEsIHVuc2lnbmVk IGludCBsZW4pOw0KPj4gKw0KPj4gK2ludCBzaG1lbV9nZXRfcmVzcG9uc2UoY29uc3Qgdm9sYXRp bGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwNCj4+ICsgICAgICAgICAg ICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRhdGEsIHVuc2lnbmVk IGludCBsZW4pOw0KPiBCYXNpY2FsbHkgdGhlIHNhbWUgY29tbWVudHMgYXMgZm9yIHByZXZpb3Vz IG9uZS4NCisNCj4+ICsjZW5kaWYgLyogQVJNX0ZJUk1XQVJFX1NDTUlfU0hNRU1fSF8gKi8NCj4+ ICsNCj4+ICsvKg0KPj4gKyAqIExvY2FsIHZhcmlhYmxlczoNCj4+ICsgKiBtb2RlOiBDDQo+PiAr ICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4gKyAqIGMtYmFzaWMtb2Zmc2V0OiA0DQo+PiArICog dGFiLXdpZHRoOiA0DQo+PiArICogaW5kZW50LXRhYnMtbW9kZTogbmlsDQo+PiArICogRW5kOg0K Pj4gKyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1t dWx0aWFnZW50LmMgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5j DQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAwMC4uNmM0NmY2Y2Qz Ng0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt c21jLW11bHRpYWdlbnQuYw0KPj4gQEAgLTAsMCArMSw3OTIgQEANCj4+ICsvKiBTUERYLUxpY2Vu c2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBTQ0kgU0NNSSBt dWx0aS1hZ2VudCBkcml2ZXIsIHVzaW5nIFNNQy9IVkMgc2htZW0gYXMgdHJhbnNwb3J0Lg0KPj4g KyAqDQo+PiArICogT2xla3NpaSBNb2lzaWVpZXYgPG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29t Pg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNSBFUEFNIFN5c3RlbXMNCj4+ICsgKi8NCj4+ICsN Cj4+ICsjaW5jbHVkZSA8eGVuL2FjcGkuaD4NCj4+ICsNCj4+ICsjaW5jbHVkZSA8eGVuL2Rldmlj ZV90cmVlLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9pbml0Lmg+DQo+PiArI2luY2x1ZGUgPHhlbi9p b2NhcC5oPg0KPj4gKyNpbmNsdWRlIDx4ZW4vZXJyLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9saWJm ZHQvbGliZmR0Lmg+DQo+PiArI2luY2x1ZGUgPHhlbi9zdHJpbmcuaD4NCj4+ICsjaW5jbHVkZSA8 eGVuL3BhcmFtLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KPj4gKyNpbmNsdWRlIDx4 ZW4vdm1hcC5oPg0KPj4gKw0KPj4gKyNpbmNsdWRlIDxhc20vZmlybXdhcmUvc2NpLmg+DQo+PiAr I2luY2x1ZGUgPGFzbS9zbWNjYy5oPg0KPj4gKw0KPj4gKyNpbmNsdWRlICJzY21pLXByb3RvLmgi DQo+PiArI2luY2x1ZGUgInNjbWktc2htZW0uaCINCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9jaGFu bmVsIHsNCj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+IElmIGFsbCBhZ2VudF9pZHMgbGFy Z2UgdGhhbiBVSU5UOF9NQVggYXJlIGludmFsaWQsIHdoeSBkbyB5b3UgbmVlZA0KPiB1aW50MzJf dCBoZXJlPw0KDQpBY2NvcmRpbmcgdG8gdGhlIERFTjAwNTZGIGRvY3VtZW50Og0KDQpodHRwczov L3N1cHBvcnQuYXJtLmNvbS9kb2N1bWVudGF0aW9uL2RlbjAwNTYvZi8/bGFuZz1lbg0KDQphZ2Vu dF9pZCBpcyB1aW50MzJfdMKgIGluIFNDTUkgbWVzc2FnZXMuDQoNCj4+ICsgICAgdWludDMyX3Qg ZnVuY19pZDsNCj4+ICsgICAgZG9taWRfdCBkb21haW5faWQ7DQo+PiArICAgIHVpbnQ2NF90IHBh ZGRyOw0KPiBwYWRkcl90DQorMS4gdGhhbmtzLg0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9zaGFyZWRf bWVtIF9faW9tZW0gKnNobWVtOw0KPj4gKyAgICBzcGlubG9ja190IGxvY2s7DQo+PiArICAgIHN0 cnVjdCBsaXN0X2hlYWQgbGlzdDsNCj4+ICt9Ow0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX2RhdGEg ew0KPj4gKyAgICBzdHJ1Y3QgbGlzdF9oZWFkIGNoYW5uZWxfbGlzdDsNCj4+ICsgICAgc3Bpbmxv Y2tfdCBjaGFubmVsX2xpc3RfbG9jazsNCj4+ICsgICAgdWludDMyX3QgZnVuY19pZDsNCj4+ICsg ICAgYm9vbCBpbml0aWFsaXplZDsNCj4+ICsgICAgdWludDMyX3Qgc2htZW1fcGhhbmRsZTsNCj4+ ICsgICAgdWludDMyX3QgaHlwX2NoYW5uZWxfYWdlbnRfaWQ7DQo+PiArICAgIHN0cnVjdCBkdF9k ZXZpY2Vfbm9kZSAqZHRfZGV2Ow0KPj4gK307DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBzY21p X2RhdGEgc2NtaV9kYXRhOw0KPj4gKw0KPj4gK3N0YXRpYyBib29sIHNjbWlfaXNfdW5kZXJfeGVu X3NjaShjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUpDQo+PiArew0KPj4gKyAgICBj b25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnA7DQo+PiArDQo+PiArICAgIGZvciAoIHAgPSBu b2RlLT5wYXJlbnQ7IHA7IHAgPSBwLT5wYXJlbnQgKQ0KPj4gKyAgICAgICAgaWYgKCBkdF9kZXZp Y2VfaXNfY29tcGF0aWJsZShwLCAieGVuLHNjaSIpICkNCj4+ICsgICAgICAgICAgICByZXR1cm4g dHJ1ZTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIGZhbHNlOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0 aWMgaW50IHNlbmRfc21jX21lc3NhZ2Uoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbl9pbmZvLA0K Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2 b2lkICpkYXRhLCBpbnQgbGVuKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IGFybV9zbWNjY19yZXMg cmVzcDsNCj4+ICsgICAgaW50IHJldDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gc2htZW1fcHV0X21l c3NhZ2UoY2hhbl9pbmZvLT5zaG1lbSwgaGRyLCBkYXRhLCBsZW4pOw0KPj4gKyAgICBpZiAoIHJl dCApDQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4gKyAgICByZXNwID0gYXJtX3Nt Y2NjXzFfMV9zbWMoY2hhbl9pbmZvLT5mdW5jX2lkLCAwLCAwLCAwLCAwLCAwLCAwLCAwKTsNCj4+ ICsNCj4+ICsgICAgaWYgKCByZXNwLmEwID09ICh1bnNpZ25lZCBsb25nKUFSTV9TTUNDQ19JTlZB TElEX1BBUkFNRVRFUiApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsg ICAgaWYgKCByZXNwLmEwICkNCj4+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsNCj4+ICsN Cj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgZG9fc21jX3hm ZXIoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbl9pbmZvLCBzY21pX21zZ19oZWFkZXJfdCAqaGRy LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqdHhfZGF0YSwgaW50IHR4X3NpemUs IHZvaWQgKnJ4X2RhdGEsIGludCByeF9zaXplKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJldCA9IDA7 DQo+PiArDQo+PiArICAgIEFTU0VSVChjaGFuX2luZm8gJiYgY2hhbl9pbmZvLT5zaG1lbSk7DQo+ PiArDQo+PiArICAgIGlmICggIWhkciApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZjaGFuX2luZm8tPmxvY2spOw0KPj4gKw0KPj4gKyAgICBw cmludGsoWEVOTE9HX0RFQlVHDQo+PiArICAgICAgICAgICAic2NtaTogYWdlbnRfaWQgPSAlZCBt c2dfaWQgPSAleCB0eXBlID0gJWQsIHByb3RvID0gJXhcbiIsDQo+PiArICAgICAgICAgICBjaGFu X2luZm8tPmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnR5cGUsIGhkci0+cHJvdG9jb2wpOw0KPj4g Kw0KPj4gKyAgICByZXQgPSBzZW5kX3NtY19tZXNzYWdlKGNoYW5faW5mbywgaGRyLCB0eF9kYXRh LCB0eF9zaXplKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBjbGVhbjsN Cj4+ICsNCj4+ICsgICAgcmV0ID0gc2htZW1fZ2V0X3Jlc3BvbnNlKGNoYW5faW5mby0+c2htZW0s IGhkciwgcnhfZGF0YSwgcnhfc2l6ZSk7DQo+PiArDQo+PiArY2xlYW46DQo+PiArICAgIHByaW50 ayhYRU5MT0dfREVCVUcNCj4+ICsgICAgICAgICAgICJzY21pOiBnZXQgc21jIHJlc3BvbnNlIGFn ZW50X2lkID0gJWQgbXNnX2lkID0gJXggcHJvdG8gPSAleCByZXM9JWRcbiIsDQo+PiArICAgICAg ICAgICBjaGFuX2luZm8tPmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnByb3RvY29sLCByZXQpOw0K PiBZb3Ugd2lsbCBwcmludCB0aGlzIGV2ZW4gaWYgc2VuZF9zbWNfbWVzc2FnZSgpIGZhaWxzLiBJ IHRoaW5rIGl0IHNob3VsZA0KPiBnbyBiZWZvcmUgImNsZWFuOiIgbGFiZWwuDQo+DQo+IEFsc28s IG1heWJlICJjbGVhbnVwOiIgPw0KKzEuIEl0J3MgYmV0dGVyIHRvIHBsYWNlIGRlYnVnIHByaW50 IGJlZm9yZSAiY2xlYW4iIGxhdmVsLg0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9jaygmY2hhbl9p bmZvLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiAr c3RhdGljIHN0cnVjdCBzY21pX2NoYW5uZWwgKmdldF9jaGFubmVsX2J5X2lkKHVpbnQzMl90IGFn ZW50X2lkKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY3VycjsNCj4+ICsg ICAgYm9vbCBmb3VuZCA9IGZhbHNlOw0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2soJnNjbWlfZGF0 YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArICAgIGxpc3RfZm9yX2VhY2hfZW50cnkoY3Vyciwg JnNjbWlfZGF0YS5jaGFubmVsX2xpc3QsIGxpc3QpDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlm ICggY3Vyci0+YWdlbnRfaWQgPT0gYWdlbnRfaWQgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAg ICAgICAgIGZvdW5kID0gdHJ1ZTsNCj4+ICsgICAgICAgICAgICBicmVhazsNCj4+ICsgICAgICAg IH0NCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5u ZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgaWYgKCBmb3VuZCApDQo+PiArICAgICAgICByZXR1cm4g Y3VycjsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRp YyBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphY3F1aXJlX3NjbWlfY2hhbm5lbChzdHJ1Y3QgZG9tYWlu ICpkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB1aW50MzJfdCBhZ2VudF9pZCkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwg KmN1cnI7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKnJldCA9IEVSUl9QVFIoLUVOT0VO VCk7DQo+PiArDQo+PiArICAgIHNwaW5fbG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2Nr KTsNCj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShjdXJyLCAmc2NtaV9kYXRhLmNoYW5uZWxf bGlzdCwgbGlzdCkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBjdXJyLT5hZ2VudF9pZCA9 PSBhZ2VudF9pZCApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgaWYgKCBjdXJyLT5k b21haW5faWQgIT0gRE9NSURfSU5WQUxJRCApDQo+PiArICAgICAgICAgICAgew0KPj4gKyAgICAg ICAgICAgICAgICByZXQgPSBFUlJfUFRSKC1FRVhJU1QpOw0KPj4gKyAgICAgICAgICAgICAgICBi cmVhazsNCj4+ICsgICAgICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICAgICAgY3Vyci0+ZG9t YWluX2lkID0gZC0+ZG9tYWluX2lkOw0KPj4gKyAgICAgICAgICAgIHJldCA9IGN1cnI7DQo+PiAr ICAgICAgICAgICAgYnJlYWs7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ICsNCj4+ICsg ICAgc3Bpbl91bmxvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArDQo+PiAr ICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIHJlbGlucXVpc2hf c2NtaV9jaGFubmVsKHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWwpDQo+PiArew0KPj4gKyAg ICBBU1NFUlQoY2hhbm5lbCAhPSBOVUxMKTsNCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZzY21p X2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4gKyAgICBjaGFubmVsLT5kb21haW5faWQgPSBE T01JRF9JTlZBTElEOw0KPj4gKyAgICBzcGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlz dF9sb2NrKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBtYXBfY2hhbm5lbF9tZW1vcnko c3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCkNCj4+ICt7DQo+PiArICAgIEFTU0VSVChjaGFu bmVsICYmIGNoYW5uZWwtPnBhZGRyKTsNCj4+ICsgICAgY2hhbm5lbC0+c2htZW0gPSBpb3JlbWFw X25vY2FjaGUoY2hhbm5lbC0+cGFkZHIsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpOw0KPj4gKyAg ICBpZiAoICFjaGFubmVsLT5zaG1lbSApDQo+PiArICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4+ ICsNCj4+ICsgICAgY2hhbm5lbC0+c2htZW0tPmNoYW5uZWxfc3RhdHVzID0gU0NNSV9TSE1FTV9D SEFOX1NUQVRfQ0hBTk5FTF9GUkVFOw0KPj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21p OiBHb3Qgc2htZW0gJWx4IGFmdGVyIHZtYXAgJXBcbiIsIGNoYW5uZWwtPnBhZGRyLA0KPiBZb3Ug d2lsbCBuZWVkIHByb3BlciBmb3JtYXQsIG5vdCAiJWx4IiBmb3IgY2hhbm5lbC0+cGFkZHINCkFn cmVlLiB3aXRoIHBhZGRyX3QgSSB3aWxsIHVzZSBQUklwYWRkciBmb3JtYXQuDQo+PiArICAgICAg ICAgICBjaGFubmVsLT5zaG1lbSk7DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ ICsNCj4+ICtzdGF0aWMgdm9pZCB1bm1hcF9jaGFubmVsX21lbW9yeShzdHJ1Y3Qgc2NtaV9jaGFu bmVsICpjaGFubmVsKQ0KPj4gK3sNCj4+ICsgICAgQVNTRVJUKGNoYW5uZWwpOw0KPj4gKw0KPj4g KyAgICBpZiAoICFjaGFubmVsLT5zaG1lbSApDQo+PiArICAgICAgICByZXR1cm47DQo+PiArDQo+ PiArICAgIGlvdW5tYXAoY2hhbm5lbC0+c2htZW0pOw0KPj4gKyAgICBjaGFubmVsLT5zaG1lbSA9 IE5VTEw7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpzbWNf Y3JlYXRlX2NoYW5uZWwodWludDMyX3QgYWdlbnRfaWQsDQo+PiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBmdW5jX2lkLCB1aW50NjRfdCBh ZGRyKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCwgKmN1cnI7 DQo+PiArDQo+PiArICAgIHNwaW5fbG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsN Cj4+ICsNCj4+ICsgICAgLyogQ2hlY2sgaWYgY2hhbm5lbCBhbHJlYWR5IGV4aXN0cyB3aGlsZSBo b2xkaW5nIHRoZSBsb2NrICovDQo+PiArICAgIGxpc3RfZm9yX2VhY2hfZW50cnkoY3VyciwgJnNj bWlfZGF0YS5jaGFubmVsX2xpc3QsIGxpc3QpDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlmICgg Y3Vyci0+YWdlbnRfaWQgPT0gYWdlbnRfaWQgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAg ICAgIHNwaW5fdW5sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4gKyAgICAg ICAgICAgIHJldHVybiBFUlJfUFRSKC1FRVhJU1QpOw0KPj4gKyAgICAgICAgfQ0KPj4gKyAgICB9 DQo+PiArDQo+PiArICAgIGNoYW5uZWwgPSB4bWFsbG9jKHN0cnVjdCBzY21pX2NoYW5uZWwpOw0K Pj4gKyAgICBpZiAoICFjaGFubmVsICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgc3Bpbl91bmxv Y2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArICAgICAgICByZXR1cm4gRVJS X1BUUigtRU5PTUVNKTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2tfaW5pdCgm Y2hhbm5lbC0+bG9jayk7DQo+PiArICAgIGNoYW5uZWwtPmFnZW50X2lkID0gYWdlbnRfaWQ7DQo+ PiArICAgIGNoYW5uZWwtPmZ1bmNfaWQgPSBmdW5jX2lkOw0KPj4gKyAgICBjaGFubmVsLT5kb21h aW5faWQgPSBET01JRF9JTlZBTElEOw0KPj4gKyAgICBjaGFubmVsLT5zaG1lbSA9IE5VTEw7DQo+ PiArICAgIGNoYW5uZWwtPnBhZGRyID0gYWRkcjsNCj4+ICsgICAgbGlzdF9hZGRfdGFpbCgmY2hh bm5lbC0+bGlzdCwgJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QpOw0KPj4gKw0KPj4gKyAgICBzcGlu X3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgcmV0dXJuIGNo YW5uZWw7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGZyZWVfY2hhbm5lbF9saXN0KHZv aWQpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjdXJyLCAqX2N1cnI7DQo+ PiArICAgIC8qDQo+PiArICAgICAqIENhbGxlZCBvbmx5IG9uIHRoZSBfX2luaXQgZXJyb3IgcGF0 aCwgYmVmb3JlIGFueSBydW50aW1lIHVzZXJzIGV4aXN0LA0KPiBUaGVuIHlvdSBjYW4gcHV0IHRo aXMgZnVuY3Rpb24gaW50byBfX2luaXQgYXMgd2VsbA0KKzENCj4+ICsgICAgICogc28gbm8gb3Ro ZXIgdGhyZWFkIGlzIGl0ZXJhdGluZyBjaGFubmVsX2xpc3QuIEtlZXAgdGhlIGxvY2sgZm9yIHRo ZQ0KPj4gKyAgICAgKiB3aG9sZSBkcmFpbiBmb3IgY2xhcml0eSBhbmQgdG8gYXZvaWQgbWlzbGVh ZGluZyByZWFkZXJzIGFib3V0IHBvc3NpYmxlDQo+PiArICAgICAqIGNvbmN1cnJlbnQgYWNjZXNz Lg0KPj4gKyAgICAgKi8NCj4+ICsgICAgc3Bpbl9sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0 X2xvY2spOw0KPj4gKyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoY3VyciwgX2N1cnIsICZz Y21pX2RhdGEuY2hhbm5lbF9saXN0LCBsaXN0KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBsaXN0 X2RlbCgmY3Vyci0+bGlzdCk7DQo+PiArICAgICAgICB4ZnJlZShjdXJyKTsNCj4+ICsgICAgfQ0K Pj4gKyAgICBzcGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICt9 DQo+PiArDQo+PiArc3RhdGljIGludCBfX2luaXQNCj4+ICtzY21pX2R0X3JlYWRfY2hhbm5lbF9h ZGRyKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2NtaV9ub2RlLCB1NjQgKmFkZHIsDQo+PiArICAg ICAgICAgICAgICAgICAgICAgICAgICB1NjQgKnNpemUpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qg ZHRfZGV2aWNlX25vZGUgKnNobWVtX25vZGU7DQo+PiArICAgIHVpbnQzMl90IHBoYW5kbGU7DQo+ PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIHJldCA9IGR0X3Byb3BlcnR5X3JlYWRfdmFy aWFibGVfdTMyX2FycmF5KHNjbWlfbm9kZSwgInNobWVtIiwgJnBoYW5kbGUsDQo+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEsIDEpOw0KPj4gKyAgICBp ZiAoIHJldCA8IDAgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgc2ht ZW1fbm9kZSA9IGR0X2ZpbmRfbm9kZV9ieV9waGFuZGxlKHBoYW5kbGUpOw0KPj4gKyAgICBpZiAo ICFzaG1lbV9ub2RlIHx8DQo+PiArICAgICAgICAgIWR0X2RldmljZV9pc19jb21wYXRpYmxlKHNo bWVtX25vZGUsICJhcm0sc2NtaS1zaG1lbSIpICkNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFM Ow0KPj4gKw0KPj4gKyAgICByZXQgPSBkdF9kZXZpY2VfZ2V0X2FkZHJlc3Moc2htZW1fbm9kZSwg MCwgYWRkciwgc2l6ZSk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiBy ZXQ7DQo+PiArDQo+PiArICAgIGlmICggISpzaXplIHx8ICFJU19BTElHTkVEKCpzaXplLCBTQ01J X1NITUVNX01BUFBFRF9TSVpFKSB8fA0KPj4gKyAgICAgICAgICFJU19BTElHTkVEKCphZGRyLCBT Q01JX1NITUVNX01BUFBFRF9TSVpFKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhY RU5MT0dfRVJSICJzY21pOiBpbnZhbGlkIHNobWVtIHJhbmdlIGZvciAlc1xuIiwNCj4+ICsgICAg ICAgICAgICAgICBzY21pX25vZGUtPmZ1bGxfbmFtZSk7DQo+PiArICAgICAgICByZXR1cm4gLUVJ TlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+ PiArLyoNCj4+ICsgKiBIYW5kbGUgRG9tMCBTQ01JIHNwZWNpZmljIERUIG5vZGVzDQo+PiArICoN Cj4+ICsgKiBNYWtlIGEgZGVjaXNpb24gb24gY29weWluZyBTQ01JIHNwZWNpZmljIG5vZGVzIGlu dG8gRG9tMCBkZXZpY2UgdHJlZS4NCj4+ICsgKiBGb3IgU0NNSSBtdWx0aS1hZ2VudCBjYXNlOg0K Pj4gKyAqIC0gc2htZW0gbm9kZXMgd2lsbCBub3QgYmUgY29waWVkIGFuZCBnZW5lcmF0ZWQgaW5z dGVhZCBpZiBTQ01JDQo+PiArICogICBpcyBlbmFibGVkIGZvciBEb20wDQo+PiArICogLSBzY21p IG5vZGUgd2lsbCBiZSBjb3BpZWQgaWYgU0NNSSBpcyBlbmFibGVkIGZvciBEb20wDQo+PiArICov DQo+PiArc3RhdGljIGJvb2wgc2NtaV9kdF9oYW5kbGVfbm9kZShzdHJ1Y3QgZG9tYWluICpkLCBz dHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUpDQo+IEFsc28gX19pbml0Pw0KKw0KPj4gK3sNCj4+ ICsgICAgc3RhdGljIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2VfbWF0Y2ggc2htZW1fbWF0Y2hlc1td IF9faW5pdGNvbnN0ID0gew0KPj4gKyAgICAgICAgRFRfTUFUQ0hfQ09NUEFUSUJMRSgiYXJtLHNj bWktc2htZW0iKSwNCj4+ICsgICAgICAgIHsgLyogc2VudGluZWwgKi8gfSwNCj4+ICsgICAgfTsN Cj4+ICsgICAgc3RhdGljIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2VfbWF0Y2ggc2NtaV9tYXRjaGVz W10gX19pbml0Y29uc3QgPSB7DQo+PiArICAgICAgICBEVF9NQVRDSF9QQVRIKCIvZmlybXdhcmUv c2NtaSIpLA0KPj4gKyAgICAgICAgeyAvKiBzZW50aW5lbCAqLyB9LA0KPj4gKyAgICB9Ow0KPj4g Kw0KPj4gKyAgICBpZiAoICFzY21pX2RhdGEuaW5pdGlhbGl6ZWQgKQ0KPj4gKyAgICAgICAgcmV0 dXJuIGZhbHNlOw0KPj4gKw0KPj4gKyAgICAvKiBza2lwIHNjbWkgc2htZW0gbm9kZSBmb3IgZG9t MCBpZiBzY21pIG5vdCBlbmFibGVkICovDQo+PiArICAgIGlmICggZHRfbWF0Y2hfbm9kZShzaG1l bV9tYXRjaGVzLCBub2RlKSAmJiAhc2NpX2RvbWFpbl9pc19lbmFibGVkKGQpICkNCj4+ICsgICAg ew0KPj4gKyAgICAgICAgZHRfZHByaW50aygiICBTa2lwIHNjbWkgc2htZW0gbm9kZVxuIik7DQo+ PiArICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICAvKiBkcm9w IHNjbWkgaWYgbm90IGVuYWJsZWQgKi8NCj4+ICsgICAgaWYgKCBkdF9tYXRjaF9ub2RlKHNjbWlf bWF0Y2hlcywgbm9kZSkgJiYgIXNjaV9kb21haW5faXNfZW5hYmxlZChkKSApDQo+PiArICAgIHsN Cj4+ICsgICAgICAgIGR0X2RwcmludGsoIiAgU2tpcCBzY21pIG5vZGVcbiIpOw0KPj4gKyAgICAg ICAgcmV0dXJuIHRydWU7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIGZhbHNlOw0K Pj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IHNjbWlfYXNzaWduX2RldmljZSh1aW50MzJfdCBh Z2VudF9pZCwgdWludDMyX3QgZGV2aWNlX2lkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHVpbnQzMl90IGZsYWdzKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfbXNnX2Jh c2Vfc2V0X2RldmljZV9wZXJtaXNzaW9uc19hMnAgdHg7DQo+PiArICAgIHN0cnVjdCBzY21pX2No YW5uZWwgKmNoYW5uZWw7DQo+PiArICAgIHNjbWlfbXNnX2hlYWRlcl90IGhkcjsNCj4+ICsNCj4+ ICsgICAgY2hhbm5lbCA9IGdldF9jaGFubmVsX2J5X2lkKHNjbWlfZGF0YS5oeXBfY2hhbm5lbF9h Z2VudF9pZCk7DQo+PiArICAgIGlmICggIWNoYW5uZWwgKQ0KPj4gKyAgICAgICAgcmV0dXJuIC1F SU5WQUw7DQo+PiArDQo+PiArICAgIGhkci5pZCA9IFNDTUlfQkFTRV9TRVRfREVWSUNFX1BFUk1J U1NJT05TOw0KPj4gKyAgICBoZHIudHlwZSA9IDA7DQo+PiArICAgIGhkci5wcm90b2NvbCA9IFND TUlfQkFTRV9QUk9UT0NPTDsNCj4+ICsNCj4+ICsgICAgdHguYWdlbnRfaWQgPSBhZ2VudF9pZDsN Cj4+ICsgICAgdHguZGV2aWNlX2lkID0gZGV2aWNlX2lkOw0KPj4gKyAgICB0eC5mbGFncyA9IGZs YWdzOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gZG9fc21jX3hmZXIoY2hhbm5lbCwgJmhkciwgJnR4 LCBzaXplb2YodHgpLCBOVUxMLCAwKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBzY21p X2R0X2Fzc2lnbl9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzdHJ1Y3QgZHRfcGhhbmRsZV9hcmdzICphY19zcGVjKQ0KPj4gK3sN Cj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsgICAgdWlu dDMyX3Qgc2NtaV9kZXZpY2VfaWQgPSBhY19zcGVjLT5hcmdzWzBdOw0KPj4gKyAgICBpbnQgcmV0 Ow0KPj4gKw0KPj4gKyAgICBpZiAoICFkLT5hcmNoLnNjaV9kYXRhICkNCj4+ICsgICAgICAgIHJl dHVybiAwOw0KPj4gKw0KPj4gKyAgICAvKiBUaGUgYWNjZXNzLWNvbnRyb2xsZXJzIGlzIHNwZWNp ZmllZCBmb3IgRFQgZGV2LCBidXQgaXQncyBub3QgYSBTQ01JICovDQo+PiArICAgIGlmICggIXNj bWlfZGF0YS5kdF9kZXYgfHwNCj4+ICsgICAgICAgICAhZHRfbm9kZV9wYXRoX2lzX2VxdWFsKGFj X3NwZWMtPm5wLCBzY21pX2RhdGEuZHRfZGV2LT5mdWxsX25hbWUpICkNCj4+ICsgICAgICAgIHJl dHVybiAwOw0KPj4gKw0KPj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsN Cj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ ICsgICAgcmV0ID0gc2NtaV9hc3NpZ25fZGV2aWNlKGFnZW50X2NoYW5uZWwtPmFnZW50X2lkLCBz Y21pX2RldmljZV9pZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNDTUlfQkFT RV9ERVZJQ0VfQUNDRVNTX0FMTE9XKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICB7DQo+ PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBj b3VsZCBub3QgYXNzaWduIGRldiBmb3IgJXBkIGFnZW50OiVkIGRldl9pZDoldSAoJWQpIiwNCj4+ ICsgICAgICAgICAgICAgICBkLCBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCwgc2NtaV9kZXZpY2Vf aWQsIHJldCk7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJmFnZW50X2No YW5uZWwtPmxvY2spOw0KPj4gKyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0 aWMgaW50IGNvbGxlY3RfYWdlbnRfaWQoc3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5l bCkNCj4+ICt7DQo+PiArICAgIGludCByZXQ7DQo+PiArICAgIHNjbWlfbXNnX2hlYWRlcl90IGhk cjsNCj4+ICsgICAgc3RydWN0IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRfcDJhIGRhX3J4 Ow0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9hMnAgZGFfdHg7 DQo+PiArDQo+PiArICAgIHJldCA9IG1hcF9jaGFubmVsX21lbW9yeShhZ2VudF9jaGFubmVsKTsN Cj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsg ICAgaGRyLmlkID0gU0NNSV9CQVNFX0RJU0NPVkVSX0FHRU5UOw0KPj4gKyAgICBoZHIudHlwZSA9 IDA7DQo+PiArICAgIGhkci5wcm90b2NvbCA9IFNDTUlfQkFTRV9QUk9UT0NPTDsNCj4+ICsNCj4+ ICsgICAgZGFfdHguYWdlbnRfaWQgPSBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsNCj4+ ICsgICAgcmV0ID0gZG9fc21jX3hmZXIoYWdlbnRfY2hhbm5lbCwgJmhkciwgJmRhX3R4LCBzaXpl b2YoZGFfdHgpLCAmZGFfcngsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGRh X3J4KSk7DQo+PiArICAgIGlmICggYWdlbnRfY2hhbm5lbC0+ZG9tYWluX2lkICE9IERPTUlEX1hF TiApDQo+PiArICAgICAgICB1bm1hcF9jaGFubmVsX21lbW9yeShhZ2VudF9jaGFubmVsKTsNCj4+ ICsgICAgaWYgKCByZXQgKQ0KPiBPbiBlcnJvciwgWGVuJ3MgY2hhbm5lbCB3aWxsIGJlIG1hcHBl ZCBzdGlsbC4gSXMgdGhpcyBpbnRlbmRlZCBiZWhhdmlvdXI/DQpJdCByZW1haW5zIG1hcHBlZCB3 aGVuIGNvbGxlY3RfYWdlbnRfaWQoKSByZXR1cm5zLCBidXQgdGhlIGV4aXN0aW5nDQpjYWxsZXIg Y2xlYW5zIGl0IHVwLiBzY21pX3Byb2JlKCkgbWFya3MgdGhlIG1hbmFnZW1lbnQgY2hhbm5lbCBE T01JRF9YRU4NCmJlZm9yZSBkaXNjb3ZlcnkuIElmIGRpc2NvdmVyeSBmYWlscywgaXQganVtcHMg dG8gZXJyb3IsIGNhbGxzDQp1bm1hcF9jaGFubmVsX21lbW9yeShjaGFubmVsKSwgdGhlbiBmcmVl X2NoYW5uZWxfbGlzdCgpLiBUaHVzIHRoZSBjdXJyZW50DQpwcm9iZSBmYWlsdXJlIHBhdGggZG9l cyBub3QgbGVhayB0aGUgbWFwcGluZy4NCg0KDQpPbiBzdWNjZXNzZnVsIGRpc2NvdmVyeSB0aGUg bWFuYWdlbWVudCBtYXBwaW5nIGlzIGRlbGliZXJhdGVseSByZXRhaW5lZA0KZm9yIHN1YnNlcXVl bnQgcGVybWlzc2lvbiBhbmQgcmVzZXQgcmVxdWVzdHMuIFNlY29uZGFyeSBkaXNjb3ZlcnkNCm1h cHBpbmdzIGFyZSBhbHdheXMgcmVtb3ZlZCBieSBjb2xsZWN0X2FnZW50X2lkKCksIHdoZXRoZXIg dGhlIHRyYW5zZmVyDQpzdWNjZWVkcyBvciBmYWlscy4NCg0KPj4gKyAgICAgICAgcmV0dXJuIHJl dDsNCj4+ICsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAiaWQ9MHgleCBuYW1lPSVzXG4i LCBkYV9yeC5hZ2VudF9pZCwgZGFfcngubmFtZSk7DQo+PiArICAgIGFnZW50X2NoYW5uZWwtPmFn ZW50X2lkID0gZGFfcnguYWdlbnRfaWQ7DQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsN Cj4+ICtzdGF0aWMgaW50IF9faW5pdCBjb2xsZWN0X2FnZW50cyhzdHJ1Y3QgZHRfZGV2aWNlX25v ZGUgKnNjbWlfbm9kZSkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqYWdl bnRzLCAqbm9kZTsNCj4+ICsgICAgdW5zaWduZWQgaW50IGNvdW50ID0gMDsNCj4+ICsNCj4+ICsg ICAgLyogVXNlIHRoZSBjb25maWd1cmF0aW9uIGNvbnRhaW5pbmcgdGhpcyBtYW5hZ2VtZW50IGNo YW5uZWwuICovDQo+PiArICAgIGZvciAoIGFnZW50cyA9IHNjbWlfbm9kZS0+cGFyZW50OyBhZ2Vu dHM7IGFnZW50cyA9IGFnZW50cy0+cGFyZW50ICkNCj4+ICsgICAgICAgIGlmICggZHRfZGV2aWNl X2lzX2NvbXBhdGlibGUoYWdlbnRzLCAieGVuLHNjaSIpICkNCj4+ICsgICAgICAgICAgICBicmVh azsNCj4+ICsNCj4+ICsgICAgQVNTRVJUKGFnZW50cyk7DQo+PiArDQo+PiArICAgIGR0X2Zvcl9l YWNoX2NoaWxkX25vZGUoYWdlbnRzLCBub2RlKQ0KPj4gKyAgICAgICAgaWYgKCBkdF9ub2RlX25h bWVfaXNfZXF1YWwobm9kZSwgImFnZW50cyIpICkNCj4+ICsgICAgICAgICAgICBicmVhazsNCj4+ ICsNCj4+ICsgICAgaWYgKCAhbm9kZSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhY RU5MT0dfRVJSICJzY21pOiBtaXNzaW5nIGFnZW50cyBub2RlXG4iKTsNCj4+ICsgICAgICAgIHJl dHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArICAgIGFnZW50cyA9IG5vZGU7DQo+PiArDQo+ PiArICAgIGlmICggZHRfY2hpbGRfbl9hZGRyX2NlbGxzKGFnZW50cykgIT0gMSB8fA0KPj4gKyAg ICAgICAgIGR0X2NoaWxkX25fc2l6ZV9jZWxscyhhZ2VudHMpICE9IDAgKQ0KPj4gKyAgICAgICAg cmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+PiArICAgIGR0X2Zvcl9lYWNoX2NoaWxkX25vZGUoYWdl bnRzLCBub2RlKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsIGFn ZW50ID0gew0KPj4gKyAgICAgICAgICAgIC5hZ2VudF9pZCA9IFNDTUlfQkFTRV9BR0VOVF9JRF9P V04sDQo+PiArICAgICAgICAgICAgLmRvbWFpbl9pZCA9IERPTUlEX0lOVkFMSUQsDQo+PiArICAg ICAgICB9Ow0KPj4gKyAgICAgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+ICsg ICAgICAgIGJvb2wgZGlzY292ZXI7DQo+PiArICAgICAgICB1aW50MzJfdCBsZW47DQo+PiArICAg ICAgICB1NjQgc2l6ZTsNCj4gdWludDY0X3QNCj4NCj4NCisxDQo+PiArICAgICAgICBpbnQgcmV0 Ow0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCAhZHRfZGV2aWNlX2lzX2NvbXBhdGlibGUobm9kZSwg InhlbixzY21pLWFnZW50IikgfHwNCj4+ICsgICAgICAgICAgICAgIWR0X2RldmljZV9pc19hdmFp bGFibGUobm9kZSkgKQ0KPj4gKyAgICAgICAgICAgIGNvbnRpbnVlOw0KPj4gKw0KPj4gKyAgICAg ICAgZGlzY292ZXIgPSAhZHRfZmluZF9wcm9wZXJ0eShub2RlLCAicmVnIiwgJmxlbik7DQo+PiAr ICAgICAgICBpZiAoICFkaXNjb3ZlciApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAg aWYgKCBsZW4gIT0gc2l6ZW9mKHVpbnQzMl90KSB8fA0KPj4gKyAgICAgICAgICAgICAgICAgIWR0 X3Byb3BlcnR5X3JlYWRfdTMyKG5vZGUsICJyZWciLCAmYWdlbnQuYWdlbnRfaWQpICkNCj4+ICsg ICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiAr ICAgICAgICBpZiAoICFkdF9wcm9wZXJ0eV9yZWFkX3UzMihub2RlLCAiYXJtLHNtYy1pZCIsICZh Z2VudC5mdW5jX2lkKSApDQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+ PiArICAgICAgICByZXQgPSBzY21pX2R0X3JlYWRfY2hhbm5lbF9hZGRyKG5vZGUsICZhZ2VudC5w YWRkciwgJnNpemUpOw0KPj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgICAgIHJl dHVybiByZXQ7DQo+PiArDQo+PiArICAgICAgICBpZiAoIGRpc2NvdmVyICkNCj4+ICsgICAgICAg IHsNCj4+ICsgICAgICAgICAgICAvKiBSZXNvbHZlIHRoZSBJRCBiZWZvcmUgaW5zZXJ0aW5nIGl0 IGludG8gdGhlIGNoYW5uZWwgbGlzdC4gKi8NCj4+ICsgICAgICAgICAgICBzcGluX2xvY2tfaW5p dCgmYWdlbnQubG9jayk7DQo+PiArICAgICAgICAgICAgcmV0ID0gY29sbGVjdF9hZ2VudF9pZCgm YWdlbnQpOw0KPj4gKyAgICAgICAgICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgICAgICAgICAg cmV0dXJuIHJldDsNCj4+ICsgICAgICAgIH0NCj4+ICsNCj4+ICsgICAgICAgIC8qIEd1ZXN0IGNv bmZpZ3VyYXRpb25zIGVuY29kZSBhZ2VudCBJRHMgaW4gYW4gZWlnaHQtYml0IGZpZWxkLiAqLw0K Pj4gKyAgICAgICAgaWYgKCBhZ2VudC5hZ2VudF9pZCA+PSBVSU5UOF9NQVggKQ0KPj4gKyAgICAg ICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4gKyAgICAgICAgY2hhbm5lbCA9IHNtY19j cmVhdGVfY2hhbm5lbChhZ2VudC5hZ2VudF9pZCwgYWdlbnQuZnVuY19pZCwNCj4+ICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWdlbnQucGFkZHIpOw0KPj4gKyAgICAgICAg aWYgKCBJU19FUlIoY2hhbm5lbCkgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHBy aW50ayhYRU5MT0dfRVJSICJzY21pOiBDb3VsZCBub3QgY3JlYXRlIGNoYW5uZWwgZm9yICVzOiAl bGRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIG5vZGUtPmZ1bGxfbmFtZSwgUFRSX0VSUihj aGFubmVsKSk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIFBUUl9FUlIoY2hhbm5lbCk7DQo+PiAr ICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICBjb3VudCsrOw0KPj4gKyAgICAgICAgcHJpbnRr KFhFTkxPR19ERUJVRyAic2NtaTogQWdlbnQgJXUgU01DICVYIGFkZHIgJWx4XG4iLA0KPj4gKyAg ICAgICAgICAgICAgIGFnZW50LmFnZW50X2lkLCBhZ2VudC5mdW5jX2lkLCAodW5zaWduZWQgbG9u ZylhZ2VudC5wYWRkcik7DQo+IFdoeSBjYXN0IHRvIHVuc2lnbmVkIGxvbmc/DQpXYXMgdXNlZCB0 byBtYXRjaCAlbHguIFVzaW5nIFBSSXBhZGRyIHdpbGwgZHJvcCB0aGUgbmVlZCBvZiBjYXNpbmcu DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIGNvdW50ID8gMCA6IC1FSU5WQUw7DQo+ PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgc2NtaV9kb21haW5faW5pdChzdHJ1Y3QgZG9tYWlu ICpkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9j cmVhdGVkb21haW4gKmNvbmZpZykNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwg KmNoYW5uZWw7DQo+PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIGlmICggIXNjbWlfZGF0 YS5pbml0aWFsaXplZCApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgLyoN Cj4+ICsgICAgICogU0NNSSBzdXBwb3J0IGlzIGNvbmZpZ3VyZWQgdmlhOg0KPj4gKyAgICAgKiAt IEZvciBkb20wOiB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQgcHJvcGVydHkgdW5kZXIgdGhlIHhlbixz Y2kgY29udGFpbmVyDQo+PiArICAgICAqIC0gRm9yIGRvbTBsZXNzOiB4ZW4sc2NpLWFnZW50LWlk IGluIHRoZSBkb21haW4gbm9kZQ0KPj4gKyAgICAgKiBUaGUgY29uZmlnLT5hcmNoLmFybV9zY2lf dHlwZSBhbmQgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQNCj4+ICsgICAgICogYXJlIGFs cmVhZHkgc2V0IGJ5IGRvbWFpbl9idWlsZC5jIG9yIGRvbTBsZXNzLWJ1aWxkLmMNCj4+ICsgICAg ICovDQo+PiArDQo+PiArICAgIGlmICggY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9PSBYRU5f RE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkUgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiAr DQo+PiArICAgIGNoYW5uZWwgPSBhY3F1aXJlX3NjbWlfY2hhbm5lbChkLCBjb25maWctPmFyY2gu YXJtX3NjaV9hZ2VudF9pZCk7DQo+PiArICAgIGlmICggSVNfRVJSKGNoYW5uZWwpICkNCj4+ICsg ICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAi c2NtaTogRmFpbGVkIHRvIGFjcXVpcmUgU0NNSSBjaGFubmVsIGZvciBhZ2VudF9pZCAldTogJWxk XG4iLA0KPj4gKyAgICAgICAgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkLCBQ VFJfRVJSKGNoYW5uZWwpKTsNCj4+ICsgICAgICAgIHJldHVybiBQVFJfRVJSKGNoYW5uZWwpOw0K Pj4gKyAgICB9DQo+PiArDQo+PiArICAgIHByaW50ayhYRU5MT0dfSU5GTw0KPj4gKyAgICAgICAg ICAgInNjbWk6IEFjcXVpcmUgY2hhbm5lbCBpZCA9IDB4JXgsIGRvbWFpbl9pZCA9ICVkIHBhZGRy ID0gMHglbHhcbiIsDQo+PiArICAgICAgICAgICBjaGFubmVsLT5hZ2VudF9pZCwgY2hhbm5lbC0+ ZG9tYWluX2lkLCBjaGFubmVsLT5wYWRkcik7DQo+PiArDQo+PiArICAgIC8qDQo+PiArICAgICAq IERvbTAgKGlmIHByZXNlbnQpIG5lZWRzIHRvIGhhdmUgYW4gYWNjZXNzIHRvIHRoZSBndWVzdCBt ZW1vcnkgcmFuZ2UNCj4+ICsgICAgICogdG8gc2F0aXNmeSBpb21lbV9hY2Nlc3NfcGVybWl0dGVk KCkgY2hlY2sgaW4gWEVOX0RPTUNUTF9pb21lbV9wZXJtaXNzaW9uDQo+PiArICAgICAqIGRvbWN0 bC4NCj4+ICsgICAgICovDQo+PiArICAgIGlmICggaGFyZHdhcmVfZG9tYWluICYmICFpc19oYXJk d2FyZV9kb21haW4oZCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByZXQgPSBpb21lbV9wZXJt aXRfYWNjZXNzKGhhcmR3YXJlX2RvbWFpbiwgcGFkZHJfdG9fcGZuKGNoYW5uZWwtPnBhZGRyKSwN Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkZHJfdG9fcGZuKGNoYW5u ZWwtPnBhZGRyICsNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0NNSV9T SE1FTV9NQVBQRURfU0laRSAtIDEpKTsNCj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+ICsgICAg ICAgICAgICBnb3RvIGVycm9yOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGQtPmFyY2guc2Np X2RhdGEgPSBjaGFubmVsOw0KPj4gKyAgICBkLT5hcmNoLnNjaV9lbmFibGVkID0gdHJ1ZTsNCj4+ ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArZXJyb3I6DQo+PiArICAgIHJlbGlucXVp c2hfc2NtaV9jaGFubmVsKGNoYW5uZWwpOw0KPj4gKyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ ICsNCj4+ICtpbnQgc2NtaV9kb21haW5fc2FuaXRpc2VfY29uZmlnKGNvbnN0IHN0cnVjdCB4ZW5f ZG9tY3RsX2NyZWF0ZWRvbWFpbiAqY29uZmlnKQ0KPj4gK3sNCj4+ICsgICAgaWYgKCBjb25maWct PmFyY2guYXJtX3NjaV90eXBlICE9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORSAmJg0K Pj4gKyAgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgIT0gWEVOX0RPTUNUTF9DT05G SUdfQVJNX1NDSV9TQ01JX1NNQ19NQSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGRwcmludGso WEVOTE9HX0lORk8sICJzY21pOiBVbnN1cHBvcnRlZCBBUk1fU0NJIHR5cGVcbiIpOw0KPj4gKyAg ICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7 DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgc2NtaV9yZWxpbnF1aXNoX3Jlc291cmNlcyhz dHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJldDsNCj4+ICsgICAgc3RydWN0 IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCwgKmFnZW50X2NoYW5uZWw7DQo+PiArICAgIHNjbWlfbXNn X2hlYWRlcl90IGhkcjsNCj4+ICsgICAgc3RydWN0IHNjbWlfbXNnX2Jhc2VfcmVzZXRfYWdlbnRf Y2ZnX2EycCB0eDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhZC0+YXJjaC5zY2lfZGF0YSApDQo+PiAr ICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgYWdlbnRfY2hhbm5lbCA9IGQtPmFyY2gu c2NpX2RhdGE7DQo+PiArDQo+PiArICAgIHNwaW5fbG9jaygmYWdlbnRfY2hhbm5lbC0+bG9jayk7 DQo+PiArICAgIHR4LmFnZW50X2lkID0gYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQ7DQo+PiArICAg IHNwaW5fdW5sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgY2hhbm5l bCA9IGdldF9jaGFubmVsX2J5X2lkKHNjbWlfZGF0YS5oeXBfY2hhbm5lbF9hZ2VudF9pZCk7DQo+ PiArICAgIGlmICggIWNoYW5uZWwgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVO TE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBVbmFibGUgdG8gZ2V0IEh5cGVydmlz b3Igc2NtaSBjaGFubmVsIGZvciBkb21haW4gJWRcbiIsDQo+PiArICAgICAgICAgICAgICAgZC0+ ZG9tYWluX2lkKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiAr DQo+PiArICAgIGhkci5pZCA9IFNDTUlfQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OOw0K Pj4gKyAgICBoZHIudHlwZSA9IDA7DQo+PiArICAgIGhkci5wcm90b2NvbCA9IFNDTUlfQkFTRV9Q Uk9UT0NPTDsNCj4+ICsNCj4+ICsgICAgdHguZmxhZ3MgPSBTQ01JX0JBU0VfQUdFTlRfUEVSTUlT U0lPTlNfUkVTRVQ7DQo+PiArDQo+PiArICAgIHJldCA9IGRvX3NtY194ZmVyKGNoYW5uZWwsICZo ZHIsICZ0eCwgc2l6ZW9mKHR4KSwgTlVMTCwgMCk7DQo+PiArICAgIGlmICggcmV0ID09IC1FT1BO T1RTVVBQICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gcmV0 Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgdm9pZCBzY21pX2RvbWFpbl9kZXN0cm95KHN0cnVj dCBkb21haW4gKmQpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVs Ow0KPj4gKw0KPj4gKyAgICBpZiAoICFkLT5hcmNoLnNjaV9kYXRhICkNCj4+ICsgICAgICAgIHJl dHVybjsNCj4+ICsNCj4+ICsgICAgY2hhbm5lbCA9IGQtPmFyY2guc2NpX2RhdGE7DQo+PiArICAg IHNwaW5fbG9jaygmY2hhbm5lbC0+bG9jayk7DQo+PiArDQo+PiArICAgIHJlbGlucXVpc2hfc2Nt aV9jaGFubmVsKGNoYW5uZWwpOw0KPj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBG cmVlIGRvbWFpbiAlZFxuIiwgZC0+ZG9tYWluX2lkKTsNCj4gWW91IGNhbiB1c2UgIiVwZCINCisN Cj4+ICsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZGF0YSA9IE5VTEw7DQo+PiArICAgIGQtPmFyY2gu c2NpX2VuYWJsZWQgPSBmYWxzZTsNCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJmNoYW5uZWwt PmxvY2spOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgYm9vbCBzY21pX2hhbmRsZV9jYWxsKHN0 cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gK3sNCj4+ICsgICAgdWludDMyX3QgZmlkID0g KHVpbnQzMl90KWdldF91c2VyX3JlZyhyZWdzLCAwKTsNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hh bm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsgICAgc3RydWN0IGRvbWFpbiAqZCA9IGN1cnJlbnQt PmRvbWFpbjsNCj4+ICsgICAgYm9vbCByZXMgPSBmYWxzZTsNCj4+ICsNCj4+ICsgICAgaWYgKCAo IXNjaV9kb21haW5faXNfZW5hYmxlZChkKSkgfHwgKCFkLT5hcmNoLnNjaV9kYXRhKSApDQo+PiAr ICAgICAgICByZXR1cm4gZmFsc2U7DQo+PiArDQo+PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5h cmNoLnNjaV9kYXRhOw0KPj4gKyAgICBzcGluX2xvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0K Pj4gKw0KPj4gKyAgICBpZiAoIGFnZW50X2NoYW5uZWwtPmZ1bmNfaWQgIT0gZmlkICkNCj4+ICsg ICAgew0KPj4gKyAgICAgICAgcmVzID0gZmFsc2U7DQo+PiArICAgICAgICBnb3RvIHVubG9jazsN Cj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBhcm1fc21jY2NfZ3Vlc3Rfc21jKHJlZ3MpOw0KPj4g KyAgICByZXMgPSB0cnVlOw0KPj4gK3VubG9jazoNCj4+ICsgICAgc3Bpbl91bmxvY2soJmFnZW50 X2NoYW5uZWwtPmxvY2spOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gcmVzOw0KPj4gK30NCj4+ICsN Cj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0IHNjaV9tZWRpYXRvcl9vcHMgc2NtaV9vcHMgPSB7DQo+ PiArICAgIC5kb21haW5faW5pdCA9IHNjbWlfZG9tYWluX2luaXQsDQo+PiArICAgIC5kb21haW5f ZGVzdHJveSA9IHNjbWlfZG9tYWluX2Rlc3Ryb3ksDQo+PiArICAgIC5yZWxpbnF1aXNoX3Jlc291 cmNlcyA9IHNjbWlfcmVsaW5xdWlzaF9yZXNvdXJjZXMsDQo+PiArICAgIC5oYW5kbGVfY2FsbCA9 IHNjbWlfaGFuZGxlX2NhbGwsDQo+PiArICAgIC5kb20wX2R0X2hhbmRsZV9ub2RlID0gc2NtaV9k dF9oYW5kbGVfbm9kZSwNCj4+ICsgICAgLmRvbWFpbl9zYW5pdGlzZV9jb25maWcgPSBzY21pX2Rv bWFpbl9zYW5pdGlzZV9jb25maWcsDQo+PiArICAgIC5hc3NpZ25fZHRfZGV2aWNlID0gc2NtaV9k dF9hc3NpZ25fZGV2aWNlLA0KPj4gK307DQo+PiArDQo+PiArc3RhdGljIGludCBfX2luaXQgc2Nt aV9jaGVja19zbWNjY192ZXIodm9pZCkNCj4+ICt7DQo+PiArICAgIGlmICggc21jY2NfdmVyIDwg QVJNX1NNQ0NDX1ZFUlNJT05fMV8xICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhF TkxPR19XQVJOSU5HDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IE5vIFNNQ0NDIDEuMSBzdXBw b3J0LCBTQ01JIGNhbGxzIGZvcndhcmRpbmcgZGlzYWJsZWRcbiIpOw0KPj4gKyAgICAgICAgcmV0 dXJuIC1FTk9TWVM7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0K Pj4gKw0KPj4gK3N0YXRpYyBpbnQgX19pbml0IHNjbWlfZHRfaHlwX2NoYW5uZWxfcmVhZChzdHJ1 Y3QgZHRfZGV2aWNlX25vZGUgKnNjbWlfbm9kZSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNjbWlfZGF0YSAqc2NtaV9kYXRhLA0KPj4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1NjQgKmFkZHIpDQo+PiAr ew0KPj4gKyAgICB1NjQgc2l6ZTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVh ZF91MzIoc2NtaV9ub2RlLCAiYXJtLHNtYy1pZCIsICZzY21pX2RhdGEtPmZ1bmNfaWQpICkNCj4+ ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHVuYWJsZSB0byBy ZWFkIHNtYy1pZCBmcm9tIERUXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4g KyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiBzY21pX2R0X3JlYWRfY2hhbm5lbF9hZGRyKHNj bWlfbm9kZSwgYWRkciwgJnNpemUpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgX19pbml0IGlu dCBzY21pX3Byb2JlKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2NtaV9ub2RlLCBjb25zdCB2b2lk ICpkYXRhKQ0KPj4gK3sNCj4+ICsgICAgdTY0IGFkZHI7DQo+PiArICAgIGludCByZXQ7DQo+PiAr ICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWw7DQo+PiArICAgIHVuc2lnbmVkIGludCBu X2FnZW50czsNCj4+ICsgICAgc2NtaV9tc2dfaGVhZGVyX3QgaGRyOw0KPj4gKyAgICBzdHJ1Y3Qg c2NtaV9tc2dfYmFzZV9hdHRyaWJ1dGVzX3AyYSByeDsNCj4+ICsNCj4+ICsgICAgQVNTRVJUKHNj bWlfbm9kZSAhPSBOVUxMKTsNCj4+ICsNCj4+ICsgICAgLyoNCj4+ICsgICAgICogT25seSBiaW5k IHRvIHRoZSBTQ01JIG5vZGUgcHJvdmlkZWQgYnkgWGVuIHVuZGVyIHRoZSB4ZW4sc2NpIGNvbnRh aW5lcg0KPj4gKyAgICAgKiAoZS5nLiAvY2hvc2VuL3hlbi94ZW5fc2NtaV9jb25maWcvc2NtaSku IFRoaXMgYXZvaWRzIGJpbmRpbmcgdG8gZmlybXdhcmUNCj4+ICsgICAgICogU0NNSSBub2RlcyB0 aGF0IGJlbG9uZyB0byB0aGUgaG9zdCBPU1BNIGFuZCBrZWVwcyB0aGUgbWVkaWF0b3Igc2NvcGVk IHRvDQo+PiArICAgICAqIFhlbi1wcm92aWRlZCBjb25maWd1cmF0aW9uIG9ubHkuDQo+PiArICAg ICAqLw0KPj4gKyAgICBpZiAoICFzY21pX2lzX3VuZGVyX3hlbl9zY2koc2NtaV9ub2RlKSApDQo+ PiArICAgICAgICByZXR1cm4gLUVOT0RFVjsNCj4+ICsNCj4+ICsgICAgaWYgKCAhYWNwaV9kaXNh YmxlZCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAic2Nt aTogaXMgbm90IHN1cHBvcnRlZCB3aGVuIHVzaW5nIEFDUElcbiIpOw0KPj4gKyAgICAgICAgcmV0 dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0ID0gc2NtaV9jaGVja19z bWNjY192ZXIoKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsN Cj4+ICsNCj4+ICsgICAgcmV0ID0gc2NtaV9kdF9oeXBfY2hhbm5lbF9yZWFkKHNjbWlfbm9kZSwg JnNjbWlfZGF0YSwgJmFkZHIpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICByZXR1 cm4gcmV0Ow0KPj4gKw0KPj4gKyAgICBJTklUX0xJU1RfSEVBRCgmc2NtaV9kYXRhLmNoYW5uZWxf bGlzdCk7DQo+PiArICAgIHNwaW5fbG9ja19pbml0KCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xv Y2spOw0KPj4gKw0KPj4gKyAgICBzY21pX2RhdGEuZHRfZGV2ID0gc2NtaV9ub2RlOw0KPj4gKw0K Pj4gKyAgICBjaGFubmVsID0gc21jX2NyZWF0ZV9jaGFubmVsKFNDTUlfQkFTRV9BR0VOVF9JRF9P V04sIHNjbWlfZGF0YS5mdW5jX2lkLCBhZGRyKTsNCj4+ICsgICAgaWYgKCBJU19FUlIoY2hhbm5l bCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByZXQgPSBQVFJfRVJSKGNoYW5uZWwpOw0KPj4g KyAgICAgICAgZ290byBvdXQ7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgLyogTWFyayBhcyBY ZW4gbWFuYWdlbWVudCBjaGFubmVsIGJlZm9yZSBjb2xsZWN0aW5nIGFnZW50IElEICovDQo+PiAr ICAgIGNoYW5uZWwtPmRvbWFpbl9pZCA9IERPTUlEX1hFTjsNCj4+ICsNCj4+ICsgICAgLyogUmVx dWVzdCBhZ2VudCBpZCBmb3IgWGVuIG1hbmFnZW1lbnQgY2hhbm5lbCAqLw0KPj4gKyAgICByZXQg PSBjb2xsZWN0X2FnZW50X2lkKGNoYW5uZWwpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAg ICAgICBnb3RvIGVycm9yOw0KPj4gKw0KPj4gKyAgICAvKiBTYXZlIHRoZSBhZ2VudCBpZCBmb3Ig WGVuIG1hbmFnZW1lbnQgY2hhbm5lbCAqLw0KPj4gKyAgICBzY21pX2RhdGEuaHlwX2NoYW5uZWxf YWdlbnRfaWQgPSBjaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsNCj4+ICsgICAgaGRyLmlkID0gU0NN SV9CQVNFX1BST1RPQ09MX0FUVElCVVRFUzsNCj4+ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAg ICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+PiArICAgIHJldCA9 IGRvX3NtY194ZmVyKGNoYW5uZWwsICZoZHIsIE5VTEwsIDAsICZyeCwgc2l6ZW9mKHJ4KSk7DQo+ PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdvdG8gZXJyb3I7DQo+PiArDQo+PiArICAg IG5fYWdlbnRzID0gU0NNSV9GSUVMRF9HRVQoU0NNSV9CQVNFX0FUVFJfTlVNX0FHRU5ULCByeC5h dHRyaWJ1dGVzKTsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogR290IGFnZW50 IGNvdW50ICVkXG4iLCBuX2FnZW50cyk7DQo+PiArICAgIHJldCA9IGNvbGxlY3RfYWdlbnRzKHNj bWlfbm9kZSk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdvdG8gZXJyb3I7DQo+ PiArDQo+PiArICAgIHJldCA9IHNjaV9yZWdpc3Rlcigmc2NtaV9vcHMpOw0KPj4gKyAgICBpZiAo IHJldCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJTQ01JOiBt ZWRpYXRvciBhbHJlYWR5IHJlZ2lzdGVyZWQgKHJldCA9ICVkKVxuIiwNCj4+ICsgICAgICAgICAg ICAgICByZXQpOw0KPj4gKyAgICAgICAgZ290byBlcnJvcjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4g KyAgICBzY21pX2RhdGEuaW5pdGlhbGl6ZWQgPSB0cnVlOw0KPj4gKyAgICBnb3RvIG91dDsNCj4+ ICsNCj4+ICtlcnJvcjoNCj4+ICsgICAgdW5tYXBfY2hhbm5lbF9tZW1vcnkoY2hhbm5lbCk7DQo+ PiArICAgIGZyZWVfY2hhbm5lbF9saXN0KCk7DQo+PiArb3V0Og0KPj4gKyAgICByZXR1cm4gcmV0 Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0IGR0X2RldmljZV9tYXRjaCBz Y21pX3NtY19tYXRjaFtdIF9faW5pdGNvbnN0ID0gew0KPj4gKyAgICBEVF9NQVRDSF9DT01QQVRJ QkxFKCJhcm0sc2NtaS1zbWMiKSwNCj4+ICsgICAgeyAvKiBzZW50aW5lbCAqLyB9LA0KPj4gK307 DQo+PiArDQo+PiArRFRfREVWSUNFX1NUQVJUKHNjbWlfc21jX21hLCAiU0NNSSBTTUMgTUVESUFU T1IiLCBERVZJQ0VfRklSTVdBUkUpDQo+PiArICAgICAgICAuZHRfbWF0Y2ggPSBzY21pX3NtY19t YXRjaCwNCj4+ICsgICAgICAgIC5pbml0ID0gc2NtaV9wcm9iZSwNCj4+ICtEVF9ERVZJQ0VfRU5E DQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+PiArICogbW9kZTogQw0K Pj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsgKiBjLWJhc2ljLW9mZnNldDogNA0KPj4g KyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10YWJzLW1vZGU6IG5pbA0KPj4gKyAqIEVu ZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0u aCBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oDQo+PiBpbmRleCAxNGQ1MWUwNzQ2Li43 MjJjMmQyZTNhIDEwMDY0NA0KPj4gLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgN Cj4+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oDQo+PiBAQCAtMzI5LDYgKzMy OSw3IEBAIERFRklORV9YRU5fR1VFU1RfSEFORExFKHZjcHVfZ3Vlc3RfY29udGV4dF90KTsNCj4+ ICAgDQo+PiAgICNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FICAgICAgMA0K Pj4gICAjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUMgIDENCj4+ICsj ZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUNfTUEgIDINCj4+ICAgDQo+ PiAgICNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1Y4Ul9FTDFfTVNBX05PTkUgICAgMA0K Pj4gICAjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9WOFJfRUwxX01TQV9QTVNBICAgIDEN Cj4+IEBAIC0zNDcsNyArMzQ4LDkgQEAgc3RydWN0IHhlbl9hcmNoX2RvbWFpbmNvbmZpZyB7DQo+ PiAgICAgICB1aW50OF90IGFybV9zY2lfdHlwZTsNCj4+ICAgICAgIC8qIElOICovDQo+PiAgICAg ICB1aW50OF90IHY4cl9lbDFfbXNhOw0KPj4gLSAgICB1aW50MTZfdCBwYWQ7DQo+PiArICAgIC8q IElOICovDQo+PiArICAgIHVpbnQ4X3QgYXJtX3NjaV9hZ2VudF9pZDsNCj4+ICsgICAgdWludDhf dCBwYWQ7DQo+PiAgIH07DQo+PiAgICNlbmRpZiAvKiBfX1hFTl9fIHx8IF9fWEVOX1RPT0xTX18g Ki8= From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:41:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:41:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461550.1672585 (Exim 4.92) (envelope-from ) id 1xLMpQ-0006JA-6r; Mon, 26 Oct 2026 15:41:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461550.1672585; Mon, 26 Oct 2026 15: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 1xLMpQ-0006J2-3y; Mon, 26 Oct 2026 15:41:40 +0000 Received: by outflank-mailman (input) for mailman id 1461550; Mon, 26 Oct 2026 15:41:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLMpO-0006Iw-FI for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:41:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMpN-00HKAZ-Ns for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:41:37 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf74aa-e002-0a2a0a5209dd-0a2a450cb294-14 for ; Mon, 26 Oct 2026 16:41:37 +0100 Received: from [52.101.65.134] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf74b1-f479-0a2a450c0019-34654186413b-3 for ; Mon, 26 Oct 2026 16:41:37 +0100 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com (2603:10a6:150:2a9::22) by GVXPR03MB10612.eurprd03.prod.outlook.com (2603:10a6:150:220::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 15:41:34 +0000 Received: from GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf]) by GVXPR03MB11113.eurprd03.prod.outlook.com ([fe80::13a1:97f6:9d2b:f8cf%6]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 15:41: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=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=OtBdBWghVU8KrGtV9MrknkKBq0woRTSl/YsyWh6mEzSS9o5yHAXi9RSim5ueHRJWRu9V6DVVduJnG7fYeYTovnNRz14PZKuP/oY4gCaTpTAAo4slSu5fKuBX5+kg7K3stquw6wB+ijoouDiy/8csPDC/kcdkkUmdY21P50uBrIhd6zWXCcJd8BDTT84wfMHg+HQ+zQNfm0kSsQWBYSnAhtWIvszP+tOp9f/HxcuhKWSto4RvoLpZ+53nsBJmuIekPH/moe+QDwFEAFkQkvt62PfHv2tHm6MEKaqRtsi3LMZucnOZ9OIO3ijc46DPezW/0QTKlMPTasaU5uzLwjjz5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eFdg5ZLtLFCMoHfU8GnwoxZIZFHCyAoIbazF6uMH77g=; b=GC34slGUYUmGkstmg42+skHw9EGo9SoLoychs2LlAUF7Mb5RObZbWU3YvHNV/RwEwIcmVDJaLwVs0V2JwRg2lPtqsefS7iLvX6wPGPwJTGs3NkB2DkLz/7aOntjsNsEP2hIi9Nl6LMaDCfCmeNVWd72cfKhNzCYAiSv3U6A+HrdsmpSx0qrUm7JZdCM1iRYtwRraHvepau5jdC1dhEveJMSzfws9qxFHyCWuhT/7NeL5VXI47yBt64WVy/Go+g+7X1OJOeZCgtCaVVi5GlB9glCNvFW3KY39pEP2gqOkyZJxkhGc/62z+hQEPn28TKG2a+auEscLYnNFJcf9j34NZg== 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=eFdg5ZLtLFCMoHfU8GnwoxZIZFHCyAoIbazF6uMH77g=; b=flBGVFmS6aAbOJyHrNPLnCGX0OwIPgI9wAZHiTNLcSmR1BpWrxsS+3QgmVne4qDvGy233iSqZOGhEB9bxjytRNQ/qHUQX3uFv79Wy5vte1WVX3uJRp4hldZQUvnQlmrbtBRfspunlAN3+M3hvd1gWqFEBcu0VfNZ4QaTdtEijIlm0Cgct8bNBXGwofFKU1nlXT5hY23dOcBuRvBt5DrIw37rNgZFZeQxW9m+DHUhNrdtf7Cp633rGvnG0+xIdY8eit4yWMU3Q4MdEKlZV3hltpHdo+laNJwMDN59nHx+iQ96is6rnl2ImsDCDzDMUSeJmBNnlczOUyM2yrSkV2gqMA== From: Oleksii Moisieiev To: Jan Beulich , Oleksii Kurochko CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Teddy Astie , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Topic: [PATCH v5] xen/arm, xen/common: Add Kconfig option to control Dom0 boot Thread-Index: AQHdUnGcfnmLH64VckKy7OjAkXrKMLbuqNIAgCFle4CAAAbygIAABtAA Date: Mon, 26 Oct 2026 15:41:33 +0000 Message-ID: <5de9bede-c621-4ee7-b3b2-6e4ded12d023@epam.com> References: <41d073a1c07e10f0d86da4a31e7a91b7ffadd8d3.1790947567.git.oleksii_moisieiev@epam.com> In-Reply-To: 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: GVXPR03MB11113:EE_|GVXPR03MB10612:EE_ x-ms-office365-filtering-correlation-id: b4774672-09b4-45ce-6020-08df33779cb5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|7416014|376014|23010399003|1800799024|261022105027099003|261022075727099003|10067099003|56012099006|261026140227099003|22082099003|18002099003|261026121527099003|11063799006|4143699003|38070700021; x-microsoft-antispam-message-info: FuGJLD/bYAU0zhmsbd8GY4vEn1TO9Trk0ENnByyECUIyvbq9TBe/UrXGlVzdpzOre+6hL6dKft6I5W5e94WKv8A4kHFiQDNj6dOO2V8lfJtHH3YRRADiposHeWgpLPTGp0FA2M1Zf+1f3Uy4qMH2Sf7grSHGoDK6bBJnKcq989jKaFz+z4eoT2ZGBpjW0bvQdJUrw7svh95ptyyM2157TdBMPjCx2vZ/D0p+i6WsJztTNk+Ekq0JBTyuM8InPvW9a4ULwm1IgqPHJNj5SObhEC5ohSxixcy2bpv2+Vn0fp0lK1mVG/Bb5RafvCdifiAHgqtkibm2aLTPbCon9zy8EwehpFsuwnLKohOCdS4LXIUCdK4+NlxC15LjNl1HjZxrM8+dbfHLM51FYDIzSqN5Huo99gwGr5T1fWL+cN7AUoCXUleawyxX7QSTEmslD4ZCuDBRrSEZwK4uiBxn6G8QCr03MAvQGBIYeU7e9OrrKv/QBMu0+i7DJQ4qaChjrn9E8tM3NPZM78vKm2vUFwykYZVpIgODduIAhTFHaXB2ttkH36htgAvO6wMm/FVh58e4rOTPdjt90ooTEONbS5wqfpAY0dAYbuSNThjw74oShXZ7fEVqI0/gUhuRA2FTAbs05sPChbpRhTnmDEOvjOGh7bK7D2kuF8UBUff2TR5OZE0BPv1VbM20GeMdoPf8KIuqpXyxfQxpB/sfmDdC1Dl+YvNgap5SMF05GsMzSERJpdA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR03MB11113.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(23010399003)(1800799024)(261022105027099003)(261022075727099003)(10067099003)(56012099006)(261026140227099003)(22082099003)(18002099003)(261026121527099003)(11063799006)(4143699003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NTBFTVF1UHZNMGZwVFNMcHUyQVdQVFBPeEVodS80K3Q0amkyVnJFRTZxdk1r?= =?utf-8?B?eVd3OXFlYU0xdnpPZSs1OStlM3pESU1SVGxXNWUzS3Azcjk2WVR1ME9RWk9S?= =?utf-8?B?Vy9OdVM3YmhaQXVPMUtGSy80UXpQKzV5bXhidEtGR1I4QnpIdlNkZ285TE9Q?= =?utf-8?B?c2RmVVBUMmhWRDdlekJKaUl5aEV4TmpwVUEwSlRQQjg0aDFMZndOMGhzWGs5?= =?utf-8?B?Y3FaVXZacFIxL0ZuUlhCY3NvUmdGQkxKMDJtd2ZYeTRFL1FITkdobFp0M2Rw?= =?utf-8?B?clg3cWVvZHlmT1ZxYmtnSGNNa2hGaFF1ZEZNMFVCOGp1VWkycVIzKzZEMDRM?= =?utf-8?B?RUZtcHJhSXVyZldONzBKSHI2Q0tkTGJLQUxjLzFXbE9GbjRKWEw4WHF5cUNk?= =?utf-8?B?bFB6RzRRSFpYYUx6Mnl0NFZXcVZ4WlBiVEZjMXduc084NnRUWlIxMkZvakli?= =?utf-8?B?UDVaZ2wzdkZvZ3JvTU1VNXpBbGdCZmpGeFgwdlVKVDM4TGNwVlM0b1hQS0pZ?= =?utf-8?B?MVF3Y0pnWUdLamNBcm5UcjVuaE9XM3VtYUI4QWZ5ZHFLNE1SUW9xSjVxNkFx?= =?utf-8?B?M1RPeVJFNmovZVlhYVlpSWIxZmUvUkZLV20wcnVUUE5YeXo3SndPMmNNSmdL?= =?utf-8?B?ZkJ2blBYUWlXNEYyUWxKeDNZc0lRQlJkeWJyd3l6VE9Uc2NmZUpFVG04TE9E?= =?utf-8?B?NnpzcE1uYmowakJ0eXA0d1Q4WWI1Z1NZL1RhYkpMNWQrencwZVozblBpSU51?= =?utf-8?B?RU5veWNYbFVhdFFOMko3N0pSYkxUaXd1QlZ4WUJ4aDlZQ05vKzVXMnpDMzFx?= =?utf-8?B?RVRvcWc4a1d3WnB5MUVVQzVZRDVMWUh0SmxsRUtBb3hrS3JYb3AxSkVRWUlm?= =?utf-8?B?Y0MxK0l1ZmFNWTFEeUNaWjJRRVZWV1BDYXZibk4yeVExM3RnUkhIOHRLSEZD?= =?utf-8?B?VG8yNTdFemhveDZRd0M5Y09pdTNhckQ3TU5hK1ROYUplb2RCakwrVzJGd3lF?= =?utf-8?B?Y1Y3Rk8xZ1FCUlVMaVphR0R2ckg2TEo3bWt2THU5MW9ZaVdqendGam1xQVRQ?= =?utf-8?B?ZXlXeHVJRG9XYzc2a0tQYytjTFpOcnIwWnNiYld4OGs5dXhCZisvR1ZRMkhr?= =?utf-8?B?YVhIWC9KU1VHWG5mUkJhVjJteVF5Ykczb3RhNUluMGlzUmgyOXhyajlyZkhV?= =?utf-8?B?eitSYjl1MythVC9WQkdCK0t5bHVKc1BKN1dDalQ3QndoU2xaMlNUbHRmN21q?= =?utf-8?B?YnIyREpFYW91RGI0a0I5SWZUZnY0VThjcTdLbEZvWng3aEQxSEtWREVxRllu?= =?utf-8?B?aFpLSWNhZmdOY2NYMm5INURkendsWDl1aHNyTSt4bC9CYmlhWEwrNUpzNkZ4?= =?utf-8?B?Z09KWnlabTFWcW9GM2YvZy9NVk5QVmE1bmMxTEttbEhvZ2ppQXd6bUdvd2RI?= =?utf-8?B?cjkzVk5SNHB3Slk3K3BJRmVoenppQ3NlYjF6T2pnZk1rT0c2dXVsL240Y28y?= =?utf-8?B?bFN5ZVhkR0NCTUhvZmhuK3RGQ2hDL0NwOWRuS2xRRzNvR0F4RVVwc0J0U3Rq?= =?utf-8?B?TlVMMzhWNjY4dUVpU3NpOHZNSlNvcVYxR0NvTC9oVzU0aHpWcFprQmNEMjFv?= =?utf-8?B?OElmbEFjOFNISWFrUkpBbHJ1K2dTRHJyTTBFVnpZV2k5VDlJL3pkeTM1UWw5?= =?utf-8?B?aUg1eG5mSGU3cU5XYUkvRmxSckVFN2wvTkdWWlRLbGtvcDNjaEhHQTl2VWhz?= =?utf-8?B?QTl6djJwWk1qaC9Bb05jNHlXd201WlVpSU1qMVdxYjY0a3o1STN2UWx6T3dS?= =?utf-8?B?akRtd1BFMStFb2VoZUZsWjFVUFRsWVNBTUNNc0hNZjVWYXRoR2NSbVVwb1lm?= =?utf-8?B?NHdWYUJSQmRzQU15MXd1bmsyWEF6QnRUNGg0L0ZOWkw1Qm44dGkxNXBFUVFi?= =?utf-8?B?Y2VWQ3M4bWs0SCtJa3oxc0oxemdGeVBkd014TGJqM3l6QXFNUTl4RERqejZk?= =?utf-8?B?TXEvSGN3V252UzNvV1pvM0pYQUl3QzJOa2IvUmNHMSs5a21DMzRTeU82YnNN?= =?utf-8?B?N1dPaWxmajdObEtDK3Z1a203VTYyYk9LWjB5OGRxVHl0YUtHSW9IVEVtYU1y?= =?utf-8?B?ZEZLRWVWNDVkVldZd1BRdVpiaEFCOGdqVExqUjVUT3pCMEd0bFpFNjY3OEJI?= =?utf-8?B?V1h4WXJXRWxqY3d2bTlpN1RUN2Fhc1o2Y2dJYlN2alJ1ZTlTUVowL1JNbzNr?= =?utf-8?B?WFMzczBVWWQyaGtYWkhjcE9MdFgrZjlZdEV1bHU0cGtWYkZuazhLWEM5TGJB?= =?utf-8?B?bE96TWw5azVOTnZsUFF1ditidGdTbDFwdDRHYWVlbi9GNWZzRU5OeUJTUHFn?= =?utf-8?Q?usS21wxy7kM2RR+k=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <7B4241D3EEF72F40A4B82593F1AEEC69@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: GVXPR03MB11113.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4774672-09b4-45ce-6020-08df33779cb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2026 15:41:33.2965 (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: WPYMXbVkSTTR0USK7ouDq61c/FarsTh5sYc/d1YNs8mnuzGRjm0dslSVPnzbljdqCxYAWF1fPZ7LsBLMpbIK2LNPiX9MD7hJPsEnZInPvLo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB10612 X-purgate-ID: tlsNG-d25034/1793029297-020C1A5B-EE03D2EF/0/0 X-purgate-type: clean X-purgate-size: 2262 DQpPbiAyNi8xMC8yMDI2IDE3OjE3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjYuMTAuMjAy NiAxNTo1MiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBPbiAwNS8xMC8yMDI2IDExOjUy LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAwMi4xMC4yMDI2IDE1OjI2LCBPbGVrc2lpIE1v aXNpZWlldiB3cm90ZToNCj4+Pj4gVGhpcyBjb21taXQgaW50cm9kdWNlcyBhIG5ldyBLY29uZmln IG9wdGlvbiwgYENPTkZJR19ET00wX0JPT1RgLCB0bw0KPj4+PiBhbGxvdyBmb3IgYnVpbGRpbmcg WGVuIHdpdGhvdXQgc3VwcG9ydCBmb3IgYm9vdGluZyBhIHJlZ3VsYXIgZG9tYWluIChEb20wKS4N Cj4+Pj4gVGhpcyBmdW5jdGlvbmFsaXR5IGlzIHByaW1hcmlseSBpbnRlbmRlZCBmb3IgdGhlIEFS TSBhcmNoaXRlY3R1cmUuDQo+Pj4gSSAoc3RpbGwpIHdvbmRlciB3aHkgdGhpcyB3b3VsZCBiZSwg YnV0IHdlbGwgLi4uDQo+PiBGb3IgdjYsIEknbSBnb2luZyB0byBkZXNjcmliZSB0aGlzIGFzIGEg Y29tbW9uIG9wdGlvbiBmb3IgbGVnYWN5IERvbTANCj4+IGJvb3QsIHdpdGggQXJtIGltcGxlbWVu dGluZyB0aGUgY29kZSBleGNsdXNpb24gaW5pdGlhbGx5LiBNeSBpbW1lZGlhdGUNCj4+IHVzZSBj YXNlIGlzIGFuIEFybSBkZXBsb3ltZW50IHdoZXJlIGd1ZXN0cyBhcmUgbGF1bmNoZWQgdGhyb3Vn aA0KPj4gZG9tMGxlc3MgYW5kIGxlZ2FjeSBEb20wIGJvb3QgaXMgbm90IG5lZWRlZC4gSSdtIGdv aW5nIHRvIGNsYXJpZnkgdGhhdA0KPj4gdGhpcyB1c2UgY2FzZSBtb3RpdmF0ZXMgdGhlIGluaXRp YWwgQXJtIGltcGxlbWVudGF0aW9uLCByYXRoZXIgdGhhbg0KPj4gbWFrZSB0aGUgaW50ZXJmYWNl IEFybS1zcGVjaWZpYy4gSXMgdGhhdCBzY29wZSBPSz8NCj4+Pj4gQSBuZXcgS2NvbmZpZyBzeW1i b2wsIGBIQVNfRE9NMGAsIGhhcyBiZWVuIGFkZGVkIGFuZCBpcyBzZWxlY3RlZCBieQ0KPj4+PiBk ZWZhdWx0IGZvciBBUk0gYW5kIFg4NiBhcmNoaXRlY3R1cmUuIFRoaXMgc3ltYm9sIHNpZ25pZmll cyB0aGF0IGFuDQo+Pj4+IGFyY2hpdGVjdHVyZSBoYXMgdGhlIGNhcGFiaWxpdHkgdG8gc3VwcG9y dCBhIERvbTAuDQo+Pj4gT2xla3NpaSAtIHdoYXQncyB5b3VyIHRha2UgdG93YXJkcyBSSVNDLVYg aGVyZT8gU2hvdWxkIGl0IHNlbGVjdCB0aGUgbmV3DQo+Pj4gc3ltYm9sIHJpZ2h0IGF3YXkgYXMg d2VsbD8NCj4+IEluIHRoZSBzdGFnaW5nIGJyYW5jaCBSSVNDLVYncyBzdGFydF94ZW4oKSBkb2Vz IG5vdCBoYXZlIGEgbGVnYWN5IERvbTANCj4+IGNvbnN0cnVjdGlvbiBwYXRoLg0KPj4gSSdtIHRo ZXJlZm9yZSBnb2luZyB0byBsZWF2ZSBIQVNfRE9NMCB1bnNlbGVjdGVkIG9uIFJJU0MtViBhbmQg ZXhwbGFpbg0KPj4gdGhhdCBzZWxlY3Rpb24gc2hvdWxkIGFjY29tcGFueSBpbXBsZW1lbnRhdGlv biBvZiBsZWdhY3kgRG9tMCBib290Lg0KPj4gSXRzIGV4aXN0aW5nIEhBU19ET00wTEVTUyBzZWxl Y3Rpb24gZG9lcyBub3QgcHJvdmlkZSB0aGF0IHBhdGguDQo+PiBEb2VzIGl0IHNvdW5kcyBvayB0 byB5b3U/DQo+IEZUQU9EIC0gbXkgZWFybGllciBxdWVzdGlvbiB3YXMgdG8gdGhlIG90aGVyIChS SVNDLVYpIE9sZWtzaWkuDQo+DQo+IEphbg0KDQpTb3JyeS4uLg0KDQotLS0NCg0KT2xla3NpaQ0K From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:44:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:44:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461558.1672593 (Exim 4.92) (envelope-from ) id 1xLMs1-0006pQ-JE; Mon, 26 Oct 2026 15:44:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461558.1672593; Mon, 26 Oct 2026 15:44: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 1xLMs1-0006pJ-G5; Mon, 26 Oct 2026 15:44:21 +0000 Received: by outflank-mailman (input) for mailman id 1461558; Mon, 26 Oct 2026 15:44:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLMrz-0006pD-Bz for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:44:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMry-00HKqF-P1 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:44:18 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf7531-bab6-0a2a0a5309dd-0a2a4501e60e-14 for ; Mon, 26 Oct 2026 16:44:18 +0100 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf7552-5984-0a2a45010019-d155dd31e4c7-3 for ; Mon, 26 Oct 2026 16:44:18 +0100 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48df54150dfso1718141f8f.0 for ; Mon, 26 Oct 2026 08:44: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-48e3eb8f305sm15934623f8f.3.2026.10.26.08.44.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 08:44: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=1793029458; x=1793634258; 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=H8FH/yACPBdDQ7puvZM/CecliNc8NkDm+G5loaHvK/c=; b=T9xjJXwE662enmUXGwoPlJoBxLka+If2r12OB1af+OI8pZRg9iLXt6EqXOlk0WMi7q M6Zxjhl/Vu/V+9jxRUpFrS25aag98Kf0bn0bAXAiMyzU4r2yd26+t09BA9f31e7xs7CQ HGgHs88KboUBio2qvfXjFCmYyKS26Z7+9tUIJXiZhEdvjekPOx6YOAhrwMt8N9jMyDxk Dh5b0CfFrT1rDmKGCQHg7ajvNbSauI0LGPMPPdnH4hKqhADwpAMmkGbAXQPP1IJ714CL bRsT19cJjK2rsOICAz3oLg9j1OKZFEbk0j06brWzdbXUaStv9bK4+cIibxTntHahWGRs 40Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793029458; x=1793634258; 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=H8FH/yACPBdDQ7puvZM/CecliNc8NkDm+G5loaHvK/c=; b=MAMK28CTmuboHWl5DD6Z3wSddIJocgFpsN5NkJ7r1E981k5SC2tvPx0YLv7RsQ07zt R1aljUZHXfB9o929wU+or1+WDg+NMbyqYnO6raXQu5bnajLCelQdIju8JWON/oMV9dwG 3tmwhVWSE5/Wd7VcBOmNlL5M2Xu6AR5Sgp+EaYRUoFz2ka8KhTLpsSi8OdPHISvYpEFr nz4q9Wq3k3KDvY6krVfBP9sCNPj7+Y+DkAa22ZaIYBCoIJHIyPy0wh+p78AM1zXkXyGl xjNSwTkSm2N04T4c9GKT8MEjTt3OT+1Ug+/2r6tG+BwGeD91OtPlOcmj1iLyg/P7Djtw N0PQ== X-Forwarded-Encrypted: i=1; AKwUvBwk3j604FJSckAtrQqar23Hi+fmLAPb7wbqZPCgOHYesTo+TyHXcJ3acN5sM5z1zRk2nJ9rgRaHfvs=@lists.xenproject.org X-Gm-Message-State: AFq9FYIeLj7g5FHee353X3YAdGNgE1xa5iBQTmhfdkVbujDCw83Vb5ji WyhfwnJ5JX7rLMWA/RfZ8FRIBPWrbxk99wFwiCHcQECIQHNyNPG3gm/Rd65BBByJzg== X-Gm-Gg: AYBFou3/PCiUR+neyWmW5NipCkDiHvfGMOHotXwcdAfySQESUq98zWJ/UBUiBm7jNRN D/s7WmsWtNMtphzLnHcE7iTgDbXQjaRtx9SMT0U8GIGUKetMka63KSEQ4yZ6PvI3xCoN6UuJg1/ 0s0k93YaelVsRThkn6WdlCJJA7gFAoEFFhRFFBjq1cBewS1KPyikDcJRLR3zniGq9Tve+pMHbwL wij+nWkjVpLbDjDzUunpE9hN0EnC2GZ+0nECDcBJxDdxu1XOdTEARDOPtwD4PTzCDrcYjdsD4n/ EE9jukU7GCYCUdYR0K6Tc4OzVGirqVl3p/IR1CsHNNrsV6NQMPVBE+Q9E/0W82k2u06uqjqqqA9 XIznYfH5kkqBN6DAl2pRUkLAcaI4NsDrCw0KKYYnxcYh7LGNEubAMjMf4vjRWfLzZ+FAEVfXC9K 9xeSWt2REUCvQSX5viZYIuMHclg2Vt2abTafyZ8FRp2GmdgK5eIoF6GTi0xCXja5MJ/IHk3LOXC yUw2zF9i0ZbodeRFCWqxD8IPdE7GIORr8G+iUy3l8Cc0nRAiZ+pmJHAgVTPu3DF7ICTVeI6BQTj kuQVa/gWS3qWOTqtzZsNV67C+OINdpBG9PsDPZ/y0Ks= X-Received: by 2002:a05:6000:22ca:b0:488:6561:b324 with SMTP id ffacd0b85a97d-48e3eb7e535mr12525043f8f.9.1793029458162; Mon, 26 Oct 2026 08:44:18 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 16:44:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Oleksii Kurochko Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> <9986e03e-bf09-46b6-9d2a-82a1864a59b5@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: <9986e03e-bf09-46b6-9d2a-82a1864a59b5@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1793029458-C4D44757-3DD06567/10/78276251493 X-purgate-type: spam X-purgate-size: 1541 On 26.10.2026 16:35, Oleksii Kurochko wrote: > On 10/26/26 4:14 PM, Baptiste Le Duc wrote: >> +/* >> + * Probe whether hardware updates the PTE A/D bits by writing to a local >> + * variable through an alias mapping whose A and D bits are clear. >> + * >> + * Check the D bit rather than the A bit, as the A bit may be set >> + * speculatively while the D bit can't. >> + * >> + * Under Svade, the store raises a page fault instead, so use the extable to >> + * handle it. >> + */ >> +static bool __init probe_hw_ad_update(void) >> +{ >> + unsigned int probe_target; >> + vaddr_t va = FIXMAP_ADDR(FIX_MISC) + PAGE_OFFSET(&probe_target); >> + pte_t *entry = &xen_fixmap[FIX_MISC]; >> + bool d_set = false; >> + >> + ASSERT(!pte_is_valid(*entry)); >> + >> + /* >> + * Any page in use will do, so alias the stack page this code runs on, >> + * with A and D clear. Store to a variable of its own, so that nothing >> + * the compiler relies on gets overwritten. >> + */ >> + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(&probe_target)), >> + PTE_VALID | PTE_READABLE | PTE_WRITABLE)); >> + flush_tlb_one_local(va); >> + >> + asm_inline goto ( > > I think that generally this code should be wrapped by "#ifdef > CONFIG_CC_HAS_ASM_GOTO_OUTPUT" I don't follow why you say this when ... > but we can keep it as is here as we don't > use output operands. ... right afterwards you explain why it isn't needed. Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:45:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:45:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461563.1672603 (Exim 4.92) (envelope-from ) id 1xLMt5-0007Jb-RS; Mon, 26 Oct 2026 15:45:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461563.1672603; Mon, 26 Oct 2026 15: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 1xLMt5-0007JU-Oi; Mon, 26 Oct 2026 15:45:27 +0000 Received: by outflank-mailman (input) for mailman id 1461563; Mon, 26 Oct 2026 15:45:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLMt4-0007JO-QR for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:45:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLMt4-001FRc-6h for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:45:26 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf758b-bab6-0a2a0a5309dd-0a2a45019bd4-14 for ; Mon, 26 Oct 2026 16:45:26 +0100 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 6adf7595-5984-0a2a45010019-b9ff1c238c8b-3 for ; Mon, 26 Oct 2026 16:45:26 +0100 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 1a178e3435d000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 15:45:22 +0000 Received: from [192.168.1.52] (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 8B48282DF1; Mon, 26 Oct 2026 16:45:21 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=3iTpoL8EcMZ4L6Ryf3agD04fX5xoZ/qbbHE9UjQiYj0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=FdsCSts1p6trT95a7xdNiC7vcQtVRkneTGMRNThLQSmhR2bTzn7rCQzIIZOyUslwm2I2gUlZi JZ12lveeFRMCipRt139hEH9TQ2yWjszXX63QBezdM1EszvLuwD9o6GzihpNAf/k5Y78Yw7enN0g OWoYLPnP97qn9VqD5qiTg8kZtPQj7uNeSUOl/ewprx6ah1tJPZJqFzKFMO0pTqSa7CxCMaN5/Dl v24jp7uGwopf6uiepZQ8WGsWS3diPUIZ0+4GEREjh/Wd1d5Joqw+l9hvTyUqqemoe1oodMjBM6D gZYekzajlW39HukHpn/c6lM/C8KK68FY+rfb1Q3NBeeA== X-Zone-Loop: 2b38d39917260e345895130d6d7d5b60655f269e6d48 x-campaign-type: default x-transaction-id: f0212e72-3b36-4ee9-bf9b-50bd82370a21 x-swg-uid: 01-89386fc9-5936-45e4-b249-1ceef817d0d8 X-Mailer: Sweego Message-ID: <1793029522.8631fc262581453bbf619ec5b2062170.1a178e3435d000f79f@vates.tech> x-swg-bid: 1793029522.8631fc262581453bbf619ec5b2062170.1a178e3435d000f79f 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 v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang In-Reply-To: <9986e03e-bf09-46b6-9d2a-82a1864a59b5@gmail.com> References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> <9986e03e-bf09-46b6-9d2a-82a1864a59b5@gmail.com> Date: Mon, 26 Oct 2026 16:45:16 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793029516; l=1759; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=JZk+aPlATWEyKnEQluI9lZT6R5vUUhJ41ClUJtJF5cc=; b=V3PfGUG9r7rUnsCizTJOdZDry9AfUoVnyWm5YQ1xJfxjxsEn1pZppatxzAC8Yfm5UlnlsovdW 1JV6PVMPurMCVXBp+i5Y7aB+ymaPGGmIjX0QjDft65A7orE/OAEUWY+ 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: 1793029521759 X-purgate-ID: tlsNG-d62444/1793029526-C5146757-CB8363EF/0/0 X-purgate-type: clean X-purgate-size: 1759 On 2026-10-26 16:35:44+01:00, Oleksii Kurochko wrote: > On 10/26/26 4:14 PM, Baptiste Le Duc wrote: > > > +/* > > + * Probe whether hardware updates the PTE A/D bits by writing to a local > > + * variable through an alias mapping whose A and D bits are clear. > > + * > > + * Check the D bit rather than the A bit, as the A bit may be set > > + * speculatively while the D bit can't. > > + * > > + * Under Svade, the store raises a page fault instead, so use the extable to > > + * handle it. > > + */ > > +static bool __init probe_hw_ad_update(void) > > +{ > > + unsigned int probe_target; > > + vaddr_t va = FIXMAP_ADDR(FIX_MISC) + PAGE_OFFSET(&probe_target); > > + pte_t *entry = &xen_fixmap[FIX_MISC]; > > + bool d_set = false; > > + > > + ASSERT(!pte_is_valid(*entry)); > > + > > + /* > > + * Any page in use will do, so alias the stack page this code runs on, > > + * with A and D clear. Store to a variable of its own, so that nothing > > + * the compiler relies on gets overwritten. > > + */ > > + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(&probe_target)), > > + PTE_VALID | PTE_READABLE | PTE_WRITABLE)); > > + flush_tlb_one_local(va); > > + > > + asm_inline goto ( > > I think that generally this code should be wrapped by "#ifdef > CONFIG_CC_HAS_ASM_GOTO_OUTPUT" but we can keep it as is here as we don't > use output operands. > Yes I didn't see any sense to use it as, from my understanding, its aimed to be use when we want to have label as output operand which is not our case here. > [ ... 81 lines skipped ... ] > Generally, looks good to me: Thanks! -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Oct 26 15:57:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 15:57:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461569.1672611 (Exim 4.92) (envelope-from ) id 1xLN55-0001HP-Rq; Mon, 26 Oct 2026 15:57:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461569.1672611; Mon, 26 Oct 2026 15: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 1xLN55-0001HI-PH; Mon, 26 Oct 2026 15:57:51 +0000 Received: by outflank-mailman (input) for mailman id 1461569; Mon, 26 Oct 2026 15:57:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLN54-0001HC-QN for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 15:57:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLN53-00DoXa-SP for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:57:49 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf787c-bab6-0a2a0a5309dd-0a2a450882ba-8 for ; Mon, 26 Oct 2026 16:57:49 +0100 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf787d-f659-0a2a45080019-d155dd34c92b-3 for ; Mon, 26 Oct 2026 16:57:49 +0100 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48df4e9d2d4so1904597f8f.3 for ; Mon, 26 Oct 2026 08:57:49 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ebc3cfasm17406383f8f.17.2026.10.26.08.57.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 08: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=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=1793030269; x=1793635069; 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=JFhhu5ovKUBIg9TAMhLW10LefbdjfH3YcvGTaCA2Ej4=; b=dVlZPLdJCnsJ+uCczB/wCksFsTZPW/ExwUJ/Ujxxvcd6tiz8gfrFnUJv85UkeG7qvX WAkBQ71CbDXWuu0Mm2r/pDMNV1ZkPxCV7F9E5ojyMfQl1LOUbiGiPzy0eBVv3Y8vn2Db G8dTKkJyqttIxe7TDMqWHtEQnEy5mmXsI0o/W0ykmxXGMhgT2MVuEjYklHs+Wxkb1OeZ rw0VFvxdOAHc0bSYrcYcF4wiDCCc2nFjCSQQuLB+W4ZnX8bdCpYvu+dp7THWwWbRsEBz s5PcAHpMBIU5BiVKRYg+aD3GSqYlqTc7S3M5BxUuGG8R4V+Y5BDZSmVhzhwpZhdjQubS eYIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793030269; x=1793635069; 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=JFhhu5ovKUBIg9TAMhLW10LefbdjfH3YcvGTaCA2Ej4=; b=HoDmWGufk/lFo3K2ZVxxq9zwo4CnRh4bP5uyOhVatYWMchSZEnPWtFPjjc937JyebN YY/mM+IF8ma2qAvH8KSzDhs5e6Ptgb+StjeFvQ3uGAVBXj3kAAATRy5JhUrBIl71bPLf MK90mM2vj6RrVqxkHWPRvqkZKQCd0q23Xf201w6wFL7vUuCoHv+s2TzXE5tKJKLO1EsQ ZHnkO2NejM6E0qH8+pTIwK7D6GeQjl9G1qHnn+z3DzW7BvAFEpTuVy+dJcpgGDNTUBie uPkH3dg7TeuNqpC8NDlFmtT3pFo+qta09oDW17lDC8H8/S8ZvutWzcQ3GIAWPsHt/VJ2 oOlQ== X-Forwarded-Encrypted: i=1; AKwUvBz1Fyj285kK7fCWo7/4Y5CNzJypll5gmEMMiR8Ytv5ScKILbaDv/Q30pguCqfvgwS49PeaME6Xg+KE=@lists.xenproject.org X-Gm-Message-State: AFq9FYL2MgPR6ax1h/ezjKtmHBRgRRuv7zPiYSvVfFc7/xbHZib4X20f 5r4upxvZ+OJM0ywwj7thREUB8RGnxOgqp+1ygedyK7JeD/WNogjnevoi X-Gm-Gg: AYBFou3A447x1Ppx4vz3oXipxCj/jBMOtvXjuF1LZJKEFjioAVtvzzrg/dE6qKj8qA/ cL1fiN+TN1taatXrb5RZbV8rUHdJhz7KuEWcm8U/pHH1AsXRuyTXT/qsd21zozdf03ak2iHC+9h 49mPTyxT1rB1ZyOz4gLhEjr7Jcj6DH42q+uexDtaFVQgiRDpuJKVl/hfFvfTMODyoG4mUcuqtHm vayGRpbHp9jaxwoEJfv816wzczbDP0CEq3R1/j/lHlLYAIkbBprJfJ1v2s1c/LHfbJD8R48du2t kmQR/oRV7l9PlpEpEUJqirSfFacrmIh7/c+RhjKyfW4ocsfpzPWR6APgwQffooTaaXUqi7DpE8L 3LpY5pjJ2NYpn97KEUYpv1tNYOV7lKm1+w42jJhct+FkUeXsxbnInS//0J18zrs11DrX8gmp3SS KLrhF5Z0lcQZwY3tbw8e7n4KFv/i6ryH2Th4jfC1t/NfG+y/4ky889w0jRcD+SsB+IykBAxQ9nF sAscFFGwsjjwFTnR2ZDoJGgCkqMjHnWVinda3osULz5Mx0/SeINKPxyocpWN59SKj6fC1sc0+MQ 2kjMLjdx+tYGX2l2++Oxto1DdtBz X-Received: by 2002:a5d:5d10:0:b0:48d:f485:5f34 with SMTP id ffacd0b85a97d-48e3eba1377mr13336006f8f.45.1793030269118; Mon, 26 Oct 2026 08:57:49 -0700 (PDT) Message-ID: <812f1dac-216f-4fef-8213-1b7c8caeb2c7@gmail.com> Date: Mon, 26 Oct 2026 16:57:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/ns16550: identify XScale UARTs from device tree To: Zhang Zheng , xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <3e8fac86f88d9d3d002b86469b87c20aea53fcef.1792467713.git.zhangzheng@iscas.ac.cn> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <3e8fac86f88d9d3d002b86469b87c20aea53fcef.1792467713.git.zhangzheng@iscas.ac.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793030269-CC57487B-E4830916/10/73395122804 X-purgate-type: spam X-purgate-size: 4299 On 10/20/26 5:45 AM, Zhang Zheng wrote: > Identify XScale UARTs using intel,xscale-uart, since IER bit 6 has other > meanings on some UART variants. Keep UUE set when writing IER so the > UART stays enabled when switching to polling, and enable RTOIE along > with receive interrupts. > > Signed-off-by: Zhang Zheng > --- > xen/drivers/char/ns16550.c | 29 +++++++++++++++++++++-------- > xen/include/xen/8250-uart.h | 2 ++ > 2 files changed, 23 insertions(+), 8 deletions(-) > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index be388c8e65..1f54155d67 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -64,6 +64,7 @@ static struct ns16550 { > bool intr_works; > bool force_polling; > bool dw_usr_bsy; > + bool xscale; > #ifdef NS16550_PCI > /* PCI card parameters. */ > bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > @@ -168,6 +169,14 @@ static void ns_write_reg(const struct ns16550 *uart, unsigned int reg, u8 c) > } > } > > +static void ns_write_ier(const struct ns16550 *uart, u8 ier) Nit: please use uint8_t in new code. > +{ > + if ( uart->xscale ) > + ier |= UART_IER_UUE; > + > + ns_write_reg(uart, UART_IER, ier); > +} > + [...] > > #ifdef CONFIG_ARM > @@ -749,16 +759,16 @@ static int __init check_existence(struct ns16550 *uart) > * there's no point trying anything else. > */ > scratch = ns_read_reg(uart, UART_IER); > - ns_write_reg(uart, UART_IER, 0); > + ns_write_ier(uart, 0); > > /* > * Mask out IER[7:4] bits for test as some UARTs (e.g. TL > * 16C754B) allow only to modify them if an EFR bit is set. > */ > scratch2 = ns_read_reg(uart, UART_IER) & 0x0f; > - ns_write_reg(uart,UART_IER, 0x0F); > + ns_write_ier(uart, 0x0f); > scratch3 = ns_read_reg(uart, UART_IER) & 0x0f; > - ns_write_reg(uart, UART_IER, scratch); > + ns_write_ier(uart, scratch); > if ( (scratch2 != 0) || (scratch3 != 0x0F) ) > return 0; check_existence() is only reached from ns16550_parse_port_config() (i.e. never for a DT-described UART), and for MMIO UARTs it returns early anyway, so uart->xscale is always false here. I don't mind the conversion for consistency, but then please mention it in the description, together with the 0x0F -> 0x0f / missing blank style changes. > > @@ -2034,6 +2044,8 @@ static int __init ns16550_uart_dt_init(struct dt_device_node *dev, > > uart->dw_usr_bsy = dt_device_is_compatible(dev, "snps,dw-apb-uart"); > > + uart->xscale = dt_device_is_compatible(dev, "intel,xscale-uart"); > + > #ifdef CONFIG_ARM > uart->vuart.base_addr = uart->io_base; > uart->vuart.size = uart->io_size; > @@ -2055,6 +2067,7 @@ static const struct dt_device_match ns16550_dt_match[] __initconst = > DT_MATCH_COMPATIBLE("ns16550"), > DT_MATCH_COMPATIBLE("ns16550a"), > DT_MATCH_COMPATIBLE("snps,dw-apb-uart"), > + DT_MATCH_COMPATIBLE("intel,xscale-uart"), > DT_MATCH_COMPATIBLE("brcm,bcm2835-aux-uart"), > { /* sentinel */ }, > }; > diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h > index d13352940c..5709a6c91b 100644 > --- a/xen/include/xen/8250-uart.h > +++ b/xen/include/xen/8250-uart.h > @@ -42,6 +42,8 @@ > #define UART_IER_ETHREI 0x02 /* tx reg. empty */ > #define UART_IER_ELSI 0x04 /* rx line status */ > #define UART_IER_EMSI 0x08 /* MODEM status */ > +#define UART_IER_RTOIE 0x10 /* Receive timeout interrupt enable (XScale) */ This line is 81 characters long. Perhaps something like "/* rx timeout (XScale) */" to also match the style of the surrounding comments? > +#define UART_IER_UUE 0x40 /* UART unit enable (XScale) */ A side question, not for this patch: Linux uses a 32-byte FIFO for PORT_XSCALE (https://elixir.bootlin.com/linux/v7.3/source/drivers/tty/serial/8250/8250_port.c#L147), while here fifo_size will end up being detected as 16. Is that intentional? The code change itself looks fine to me. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:20:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:20:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461579.1672620 (Exim 4.92) (envelope-from ) id 1xLNRE-0006VS-Kz; Mon, 26 Oct 2026 16:20:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461579.1672620; Mon, 26 Oct 2026 16:20: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 1xLNRE-0006VL-IO; Mon, 26 Oct 2026 16:20:44 +0000 Received: by outflank-mailman (input) for mailman id 1461579; Mon, 26 Oct 2026 16:20:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLNRD-0006TK-Mz for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:20:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLNRC-006J1i-PU for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:20:42 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf7dce-e002-0a2a0a5209dd-0a2a450290ba-18 for ; Mon, 26 Oct 2026 17:20:42 +0100 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf7dda-6ca4-0a2a45020019-d155802fb9cf-3 for ; Mon, 26 Oct 2026 17:20:42 +0100 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4a208d93758so37454765e9.3 for ; Mon, 26 Oct 2026 09:20:42 -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-4a74d7f18a3sm25746745e9.1.2026.10.26.09.20.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2026 09: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=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=1793031642; x=1793636442; 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=sXJzzQv6ATpOpBIhYviVedyogXog06fauC4uO8Ai1RA=; b=cMwnB9qWzBPxuJswGkG4kCuYooxIxWl7pBoW1Ru9LEf5i2Vtf6Q08Ty1uSQhplNDkO lhP6HH6VYeIP4KGTgP4u7JOnMbkZ9lCFZ4PwLJY0DWOvqyahiiGSjUPdn9FLKNZK6FFi MIonFoxLRbJZud4DTAxVIWM7Wt1iyJRstIsI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793031642; x=1793636442; 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=sXJzzQv6ATpOpBIhYviVedyogXog06fauC4uO8Ai1RA=; b=nUyaDh7OBg0bJitc4tqQATQldg15UVlBZGlhOGYlaSDYiZ8qMv/FzT33tLwdssrqy7 XXG/fCsO9qRfjTAYEnffmB25V1GqiFdjmTIBDsMPsLuIFT/17HLGaDmYP5C+tH6EnZck hr7p3MVKyNwJxc5IFetlSDIdSklZbIuzgjx02oLNMbQOpbL5sOlGDS/VGHKR4fiGZtFk EYej+wr79tm/iK6u6NAMT04I79hBWx4VfFM2bkav4ie1BDtNUj73O4b+8xg6CIaRJMJt U0EUMeSO8O17eJcb4AgcG4kJPR75qbx+BoNOPX5O1p/OWEgPzRFGzggdOGvBmt3mljqf gmBw== X-Gm-Message-State: AFq9FYK9iFyF5T+915sgLufiUBoNnNonqh18cPH7Aepf21UpDL8jVdNF /jXjS8SkUalmMF8P9yi/uqJ6XoZD5LbROaoBLpF2p8u8GkoCW1n78BL/+EKxatUUsNAjWR6INTT M/n8YsrU= X-Gm-Gg: AYBFou0YhIlrLy5f/hDb2IV/2rlJUEqJ+XxVqJ4w0w1u0NEzm8Nd10gTygE8NQkmX0w TC0B9G45fuWo4ygxb7AjgEFamn7OPKU7ZIEjKl3EeuMLd0uTs/nLP1qHhYhJhDE/ZIOMHnJHrd9 XBmFp5oQy/QRRGwe+PWF4/l4S0kDN5MVO+8Q19K0YpXd835k9S+88k4EQPdM2m8tG0Qqxn2KdC9 LhRUVLZRG9vHzNNfbp1pIJh/veLvwuHG7Hmkb7dXnDwXszAi3SPNysYWPf9Tn6WEuDgtZRRvmyr 1jAUsLieuXi9bCzY3R22TqapQVuB8Udhtem9i9HFpDvJ4a2K/jVCiuhdjvW5OIjf/+f8IdpKFgA STCa/DA2a0pUZlUp4/vblVF7ws1dhZzcMQgEcgjkWUqAsqviImmUCSNURXFSZU0BuoWAEbXKt54 pFCBHcgdDFFw1hq4c1g6LYUO2D3Y/d4Adhca7EWntrnJtZwk1eZr6z1Pw/v4GwjerTqWosx6A4o y2g9AWpECwKvHJr46QlOVgA4pk1B9fZXADNYo+QjpxsKgQCLE+XakzyNrMAMN38GKjvGZQ2233t H7n9ZmEvYHeQjBi5sRNCqsxRKLc8dacqT870wE1107MM5IFaB2M= X-Received: by 2002:a05:600c:4f0f:b0:4a0:27eb:49b with SMTP id 5b1f17b1804b1-4a35acba87fmr162105375e9.30.1793031641681; Mon, 26 Oct 2026 09:20:41 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Julian Vetter Subject: [PATCH] tools/ocaml: Gitlab CI test for bindings Date: Mon, 26 Oct 2026 16:20:39 +0000 Message-Id: <20261026162039.1188760-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-720697/1793031642-307C22AC-EACD06FC/0/0 X-purgate-type: clean X-purgate-size: 4449 ... as building and interpreting Ocaml objects in C is rather fragile. For C producing objects for Ocaml to consume, one trick to check validity is Gc.compact() which forces a major sweep, walking all objects. If this doesn't segfault, then we at least got the pointer <-> integer aspect right. For now, start with a very simple version call. (Re)introduce tools/ocaml/tests and add test-ocaml-bindings which is installed into $(DESTDIR)$(LIBEXEC)/tests to be picked up automatically with the other dom0 tests. Signed-off-by: Andrew Cooper --- CC: Andrii Sultanov CC: Guillaume Thouvenin CC: Julian Vetter https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2990559670/test_report --- tools/ocaml/Makefile | 1 + tools/ocaml/tests/Makefile | 8 +++++++ tools/ocaml/tests/bindings/.gitignore | 1 + tools/ocaml/tests/bindings/Makefile | 34 +++++++++++++++++++++++++++ tools/ocaml/tests/bindings/main.ml | 19 +++++++++++++++ 5 files changed, 63 insertions(+) create mode 100644 tools/ocaml/tests/Makefile create mode 100644 tools/ocaml/tests/bindings/.gitignore create mode 100644 tools/ocaml/tests/bindings/Makefile create mode 100644 tools/ocaml/tests/bindings/main.ml diff --git a/tools/ocaml/Makefile b/tools/ocaml/Makefile index 7252eb23d798..e570e30a6e8d 100644 --- a/tools/ocaml/Makefile +++ b/tools/ocaml/Makefile @@ -3,6 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk SUBDIRS := libs SUBDIRS += xenstored +SUBDIRS += tests .NOTPARALLEL: # targets here must be run in order, otherwise we can try diff --git a/tools/ocaml/tests/Makefile b/tools/ocaml/tests/Makefile new file mode 100644 index 000000000000..e9f3557f1219 --- /dev/null +++ b/tools/ocaml/tests/Makefile @@ -0,0 +1,8 @@ +XEN_ROOT = $(CURDIR)/../../.. +include $(XEN_ROOT)/tools/Rules.mk + +SUBDIRS-y := +SUBDIRS-y += bindings + +.PHONY: all clean install distclean uninstall +all clean distclean install uninstall: %: subdirs-% diff --git a/tools/ocaml/tests/bindings/.gitignore b/tools/ocaml/tests/bindings/.gitignore new file mode 100644 index 000000000000..6e9a7f429b49 --- /dev/null +++ b/tools/ocaml/tests/bindings/.gitignore @@ -0,0 +1 @@ +test-ocaml-bindings diff --git a/tools/ocaml/tests/bindings/Makefile b/tools/ocaml/tests/bindings/Makefile new file mode 100644 index 000000000000..75f8babbafca --- /dev/null +++ b/tools/ocaml/tests/bindings/Makefile @@ -0,0 +1,34 @@ +XEN_ROOT = $(CURDIR)/../../../.. +OCAML_TOPLEVEL = $(CURDIR)/../.. +include $(OCAML_TOPLEVEL)/common.make + +OBJS = main + +OCAMLINCLUDE += \ + -I $(OCAML_TOPLEVEL)/libs/xb \ + -I $(OCAML_TOPLEVEL)/libs/mmap \ + -I $(OCAML_TOPLEVEL)/libs/xc \ + -I $(OCAML_TOPLEVEL)/libs/eventchn + +LIBS = \ + unix.cmxa \ + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/mmap $(OCAML_TOPLEVEL)/libs/mmap/xenmmap.cmxa \ + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/eventchn $(OCAML_TOPLEVEL)/libs/eventchn/xeneventchn.cmxa \ + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xc $(OCAML_TOPLEVEL)/libs/xc/xenctrl.cmxa \ + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xb $(OCAML_TOPLEVEL)/libs/xb/xenbus.cmxa \ + -ccopt -L -ccopt $(XEN_ROOT)/tools/libs/ctrl + +PROGRAMS = test-ocaml-bindings +OCAML_PROGRAM = test-ocaml-bindings + +test-ocaml-bindings_LIBS = $(LIBS) +test-ocaml-bindings_MLSORTED = $(shell $(OCAMLDEP) -sort $(OBJS:=.ml)) +test-ocaml-bindings_OBJS = $(test-ocaml-bindings_MLSORTED:.ml=) + +all: test-ocaml-bindings + +install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests + $(INSTALL_PROG) test-ocaml-bindings $(DESTDIR)$(LIBEXEC)/tests + +include $(OCAML_TOPLEVEL)/Makefile.rules diff --git a/tools/ocaml/tests/bindings/main.ml b/tools/ocaml/tests/bindings/main.ml new file mode 100644 index 000000000000..785837e270ad --- /dev/null +++ b/tools/ocaml/tests/bindings/main.ml @@ -0,0 +1,19 @@ +open Printf + +let xch = Xenctrl.interface_open () + +let test_xenversion () = + let ver = Xenctrl.version xch in + printf "Xen version: %d.%d%s\n" ver.major ver.minor ver.extra + + +let () = + printf "Test Ocaml Bindings\n%!"; + + test_xenversion (); + + printf "Starting GC.compact()\n%!"; + Gc.compact (); + printf "GC done\n"; + + () base-commit: 46678752be2d97f61317d793408a59927a429847 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:27:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:27:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461585.1672629 (Exim 4.92) (envelope-from ) id 1xLNX3-00078I-7b; Mon, 26 Oct 2026 16:26:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461585.1672629; Mon, 26 Oct 2026 16: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 1xLNX3-00078B-4z; Mon, 26 Oct 2026 16:26:45 +0000 Received: by outflank-mailman (input) for mailman id 1461585; Mon, 26 Oct 2026 16:26:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLNX1-000785-Pm for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:26:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLNX0-007iNI-VF for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:26:42 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf7f1a-8faa-0a2a0a5109dd-0a2a45038550-40 for ; Mon, 26 Oct 2026 17:26:42 +0100 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 6adf7f42-fae8-0a2a45030019-b9ff1c12b64f-3 for ; Mon, 26 Oct 2026 17:26:42 +0100 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 1a1790908d4000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 16:26:37 +0000 Received: from [192.168.0.158] (cpc92322-cmbg19-2-0-cust1759.5-4.cable.virginm.net [86.26.38.224]) (Authenticated sender: andriy.sultanov) by mail2.vates.fr (Postfix) with ESMTPSA id C09C981D36; Mon, 26 Oct 2026 17:26:36 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=R6I2EqCiYHw5uUSgZETXcCUbfXX6QPtH9rUWpXBi6pc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=k0JIbbz6KzlgAm1+ip7f59vGvmRXu1aah1v2TnRuyTSXNgaBLG/nsycuMWvTrXS3BdNe3VDYi U6EL6l+TxEkwG1mwx5wO9g8F6KdU6FHJ/3ytMkDiNjirG1hisUGIT3dFzzMIBXSaIGe3/IoRjSq VEJs+Ip0AvHuO29u95CLJmpKMfUCJ1VO7TqayOKUS2pFc+HwmWC8wV721wnlscE0Pcyw6wl/r45 ZKASuEH8/o8dS9Dr+2PJEsCMsDdnChqKk+16xb4UyvNxbWcd00Npv1lu1tAwuZarCR0kfOWMrAX 8BpCE0nceOSFGRm9oAIVs5+py8QELlcoYf1H0HLC8zsw== X-Zone-Loop: 44b07b4f2a695872c0b6b30c7a2a6d30ce3900b319f0 x-campaign-type: default x-transaction-id: b2e3c8f8-498e-4ce3-9485-7f934734110e x-swg-uid: 01-e30dbad8-0ad2-46de-bb7d-9a628a4a6f70 X-Mailer: Sweego Message-ID: <1793031997.8631fc262581453bbf619ec5b2062170.1a1790908d4000f79f@vates.tech> x-swg-bid: 1793031997.8631fc262581453bbf619ec5b2062170.1a1790908d4000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 26 Oct 2026 16:26:36 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tools/ocaml: Gitlab CI test for bindings To: Andrew Cooper , Xen-devel Cc: Guillaume Thouvenin , Julian Vetter References: <20261026162039.1188760-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Andrii Sultanov In-Reply-To: <20261026162039.1188760-1-andrew.cooper3@citrix.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: 1793031996978 X-purgate-ID: tlsNG-33051d/1793032002-77AF14E9-3A7BB412/0/0 X-purgate-type: clean X-purgate-size: 4803 On 10/26/26 16:20, Andrew Cooper wrote: > ... as building and interpreting Ocaml objects in C is rather fragile. > > For C producing objects for Ocaml to consume, one trick to check validity is > Gc.compact() which forces a major sweep, walking all objects. If this doesn't > segfault, then we at least got the pointer <-> integer aspect right. > > For now, start with a very simple version call. (Re)introduce > tools/ocaml/tests and add test-ocaml-bindings which is installed into > $(DESTDIR)$(LIBEXEC)/tests to be picked up automatically with the other dom0 > tests. > > Signed-off-by: Andrew Cooper > --- > CC: Andrii Sultanov > CC: Guillaume Thouvenin > CC: Julian Vetter > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2990559670/test_report > --- > tools/ocaml/Makefile | 1 + > tools/ocaml/tests/Makefile | 8 +++++++ > tools/ocaml/tests/bindings/.gitignore | 1 + > tools/ocaml/tests/bindings/Makefile | 34 +++++++++++++++++++++++++++ > tools/ocaml/tests/bindings/main.ml | 19 +++++++++++++++ > 5 files changed, 63 insertions(+) > create mode 100644 tools/ocaml/tests/Makefile > create mode 100644 tools/ocaml/tests/bindings/.gitignore > create mode 100644 tools/ocaml/tests/bindings/Makefile > create mode 100644 tools/ocaml/tests/bindings/main.ml > > diff --git a/tools/ocaml/Makefile b/tools/ocaml/Makefile > index 7252eb23d798..e570e30a6e8d 100644 > --- a/tools/ocaml/Makefile > +++ b/tools/ocaml/Makefile > @@ -3,6 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk > > SUBDIRS := libs > SUBDIRS += xenstored > +SUBDIRS += tests > > .NOTPARALLEL: > # targets here must be run in order, otherwise we can try > diff --git a/tools/ocaml/tests/Makefile b/tools/ocaml/tests/Makefile > new file mode 100644 > index 000000000000..e9f3557f1219 > --- /dev/null > +++ b/tools/ocaml/tests/Makefile > @@ -0,0 +1,8 @@ > +XEN_ROOT = $(CURDIR)/../../.. > +include $(XEN_ROOT)/tools/Rules.mk > + > +SUBDIRS-y := > +SUBDIRS-y += bindings > + > +.PHONY: all clean install distclean uninstall > +all clean distclean install uninstall: %: subdirs-% > diff --git a/tools/ocaml/tests/bindings/.gitignore b/tools/ocaml/tests/bindings/.gitignore > new file mode 100644 > index 000000000000..6e9a7f429b49 > --- /dev/null > +++ b/tools/ocaml/tests/bindings/.gitignore > @@ -0,0 +1 @@ > +test-ocaml-bindings > diff --git a/tools/ocaml/tests/bindings/Makefile b/tools/ocaml/tests/bindings/Makefile > new file mode 100644 > index 000000000000..75f8babbafca > --- /dev/null > +++ b/tools/ocaml/tests/bindings/Makefile > @@ -0,0 +1,34 @@ > +XEN_ROOT = $(CURDIR)/../../../.. > +OCAML_TOPLEVEL = $(CURDIR)/../.. > +include $(OCAML_TOPLEVEL)/common.make > + > +OBJS = main > + > +OCAMLINCLUDE += \ > + -I $(OCAML_TOPLEVEL)/libs/xb \ > + -I $(OCAML_TOPLEVEL)/libs/mmap \ > + -I $(OCAML_TOPLEVEL)/libs/xc \ > + -I $(OCAML_TOPLEVEL)/libs/eventchn > + > +LIBS = \ > + unix.cmxa \ > + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/mmap $(OCAML_TOPLEVEL)/libs/mmap/xenmmap.cmxa \ > + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/eventchn $(OCAML_TOPLEVEL)/libs/eventchn/xeneventchn.cmxa \ > + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xc $(OCAML_TOPLEVEL)/libs/xc/xenctrl.cmxa \ > + -ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xb $(OCAML_TOPLEVEL)/libs/xb/xenbus.cmxa \ > + -ccopt -L -ccopt $(XEN_ROOT)/tools/libs/ctrl > + > +PROGRAMS = test-ocaml-bindings > +OCAML_PROGRAM = test-ocaml-bindings > + > +test-ocaml-bindings_LIBS = $(LIBS) > +test-ocaml-bindings_MLSORTED = $(shell $(OCAMLDEP) -sort $(OBJS:=.ml)) > +test-ocaml-bindings_OBJS = $(test-ocaml-bindings_MLSORTED:.ml=) > + > +all: test-ocaml-bindings > + > +install: all > + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests > + $(INSTALL_PROG) test-ocaml-bindings $(DESTDIR)$(LIBEXEC)/tests > + > +include $(OCAML_TOPLEVEL)/Makefile.rules > diff --git a/tools/ocaml/tests/bindings/main.ml b/tools/ocaml/tests/bindings/main.ml > new file mode 100644 > index 000000000000..785837e270ad > --- /dev/null > +++ b/tools/ocaml/tests/bindings/main.ml > @@ -0,0 +1,19 @@ > +open Printf > + > +let xch = Xenctrl.interface_open () > + > +let test_xenversion () = > + let ver = Xenctrl.version xch in > + printf "Xen version: %d.%d%s\n" ver.major ver.minor ver.extra > + > + > +let () = > + printf "Test Ocaml Bindings\n%!"; > + > + test_xenversion (); > + > + printf "Starting GC.compact()\n%!"; > + Gc.compact (); > + printf "GC done\n"; > + > + () > > base-commit: 46678752be2d97f61317d793408a59927a429847 Acked-by: Andrii Sultanov From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:28:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:28:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461592.1672639 (Exim 4.92) (envelope-from ) id 1xLNYl-0007q5-IA; Mon, 26 Oct 2026 16:28:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461592.1672639; Mon, 26 Oct 2026 16:28: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 1xLNYl-0007py-F0; Mon, 26 Oct 2026 16:28:31 +0000 Received: by outflank-mailman (input) for mailman id 1461592; Mon, 26 Oct 2026 16:28:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLNYj-0007ps-Ki for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:28:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLNYj-00Dtzl-19 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:28:29 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf7f99-e002-0a2a0a5209dd-0a2a4508b5e4-32 for ; Mon, 26 Oct 2026 17:28:28 +0100 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 6adf7fac-f659-0a2a45080019-b9ff1c22a0e7-3 for ; Mon, 26 Oct 2026 17:28:28 +0100 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 1a1790aac26000f79f.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 26 Oct 2026 16:28:24 +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 0518382E36; Mon, 26 Oct 2026 17:28:24 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=cL/zlKoI2SbWUiMKOLPEqgrJA1LEZBSaQyK3Tjf77j4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=kjMrrcf4oAFB0fuGq+EPDI4Yrsaf4mfn2TrFW1zT2Rx0ukEQKYlQEVOkkxuGlWV5E6A8NjV2K DNjDxBUSUn3cYR5W6kmFNABbS2ZYhtHZwfU60LtkZMGycbKvJJrv6hDOpIOL0w7qMYBgV/1kH/6 KKriVC8yGN93mmXI80ZLcrL3Bfn9tm2okcT3vjh1/NPs97ffq5k9LhdzCyvDlSHCx2Gg1vBE2j0 r7IQ+iX8lCmP1U7ft5G78sQ4PArw1d2PDc+9dwkmeruYFOPVBjx2isiMFuZI/QY5lwo7of+7O2l COZlWEpUb+PubfMJ8M9UZTNXCDeGaEvHAmK4W7zqOpDQ== X-Zone-Loop: 24e3090cd211466bc203b827b0f0c8dfbb707bb693a8 x-campaign-type: default x-transaction-id: 6ca10939-989f-4ca7-ab0c-e001082a4d40 x-swg-uid: 01-7f22080c-3dbf-487b-aa30-e3d5efb8f886 X-Mailer: Sweego Message-ID: <1793032105.8631fc262581453bbf619ec5b2062170.1a1790aac26000f79f@vates.tech> x-swg-bid: 1793032105.8631fc262581453bbf619ec5b2062170.1a1790aac26000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 26 Oct 2026 17:28:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] x86/vlapic: Fix hardware virtualized APIC state after reset To: Bernhard Kaindl Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Denis Mukhin References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> <1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f@vates.tech> <179293814412.1810895.12737475203049581172.b4-review@b4> 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: <179293814412.1810895.12737475203049581172.b4-review@b4> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------9BsBj9Td2zo0ekrIU7xai3qA" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793032104185 X-purgate-ID: tlsNG-c1860d/1793032108-CF75B87B-E7FA3B53/10/78276251493 X-purgate-type: spam X-purgate-size: 14118 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------9BsBj9Td2zo0ekrIU7xai3qA Content-Type: multipart/mixed; boundary="------------P09eaBqWh67iXQKJFFAcbuwv"; protected-headers="v1"; hp="clear" Message-ID: Date: Mon, 26 Oct 2026 17:28:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] x86/vlapic: Fix hardware virtualized APIC state after reset To: Bernhard Kaindl Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Denis Mukhin References: <1792504313.8631fc262581453bbf619ec5b2062170.1a1599536d8000f79f@vates.tech> <20261020135333.38064-2-teddy.astie@vates.tech> <1792504425.8631fc262581453bbf619ec5b2062170.1a15996ec68000f79f@vates.tech> <179293814412.1810895.12737475203049581172.b4-review@b4> 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: <179293814412.1810895.12737475203049581172.b4-review@b4> --------------P09eaBqWh67iXQKJFFAcbuwv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjUvMTAvMjAyNiDDoCAxNToyNywgQmVybmhhcmQgS2FpbmRsIGEgw6ljcml0wqA6DQo+ IFRvOiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4NCj4gQ2M6IHhlbi1k ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZywgSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2Uu Y29tPiwNCj4gICBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPiwg cm9nZXJAeGVucHJvamVjdC5vcmcsDQo+ICAgRGVuaXMgTXVraGluIDxkbXVraGluQHhlbi5v cmc+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi82XSB4ODYvdmxhcGljOiBGaXggaGFyZHdh cmUgdmlydHVhbGl6ZWQgQVBJQyBzdGF0ZSBhZnRlciByZXNldA0KPiBJbi1SZXBseS1Ubzog PDE3OTI1MDQ0MjUuODYzMWZjMjYyNTgxNDUzYmJmNjE5ZWM1YjIwNjIxNzAuMWExNTk5NmVj NjgwMDBmNzlmQHZhdGVzLnRlY2g+DQo+IFJlZmVyZW5jZXM6IDwxNzkyNTA0MzEzLjg2MzFm YzI2MjU4MTQ1M2JiZjYxOWVjNWIyMDYyMTcwLjFhMTU5OTUzNmQ4MDAwZjc5ZkB2YXRlcy50 ZWNoPg0KPiAgIDwyMDI2MTAyMDEzNTMzMy4zODA2NC0yLXRlZGR5LmFzdGllQHZhdGVzLnRl Y2g+DQo+ICAgPDE3OTI1MDQ0MjUuODYzMWZjMjYyNTgxNDUzYmJmNjE5ZWM1YjIwNjIxNzAu MWExNTk5NmVjNjgwMDBmNzlmQHZhdGVzLnRlY2g+DQo+IA0KPiBIaSBUZWRkeSwNCj4gDQo+ IFRoYW5rcyBmb3IgdGhlIHJlc2V0IGltcHJvdmVtZW50cy4gQ291bGQgdGhlIG5ldyByZXNl dC10aW1lIHN5bmMNCj4gY2FsbCB1c2UgYSBkZWRpY2F0ZWQgZGlzY2FyZCBvcGVyYXRpb24g aW5zdGVhZD8gVGhhdCB3b3VsZCBhbHNvIGNvdmVyDQo+IHN1cHByZXNzZWQgcG9zdGluZ3Mg d2l0aG91dCBjaGFuZ2luZyBvcmRpbmFyeSBwZW5kaW5nLWludGVycnVwdCBxdWVyaWVzLg0K PiANCj4geGVuL2FyY2gveDg2L2h2bS92bGFwaWMuYzoNCj4gQEAgLTE0MjksNiArMTQzMiwx MyBAQCBzdGF0aWMgdm9pZCB2bGFwaWNfZG9faW5pdChzdHJ1Y3QgdmxhcGljICp2bGFwaWMp DQo+PiArICAgIC8qDQo+PiArICAgICAqIERyYWluIHRoZSBwb3N0ZWQgaW50ZXJydXB0IGRl c2NyaXB0b3IgKGFuZCBjbGVhciBpdHMgT04gYml0KSBiZWZvcmUNCj4+ICsgICAgICogemVy b2luZyB0aGUgSVJSLCBzbyB0aGF0IHZlY3RvcnMgcG9zdGVkIGJlZm9yZSB0aGUgcmVzZXQg ZG9uJ3QgZ2V0DQo+PiArICAgICAqIG1lcmdlZCBpbnRvIHRoZSBmcmVzaCBJUlIgYnkgYSBs YXRlciBzeW5jLg0KPj4gKyAgICAgKi8NCj4+ICsgICAgaHZtX3N5bmNfcGlyX3RvX2lycih2 bGFwaWNfdmNwdSh2bGFwaWMpKTsNCj4gDQo+IFBJUiAoUG9zdGVkIEludGVycnVwdCBSZXF1 ZXN0KSByZWNvcmRzIHBlbmRpbmcgdmVjdG9ycy4gT04gbWVhbnMNCj4gT3V0c3RhbmRpbmcg Tm90aWZpY2F0aW9uLCB3aGlsZSBTTiAoU3VwcHJlc3MgTm90aWZpY2F0aW9uKSBzdXBwcmVz c2VzDQo+IG5vbi11cmdlbnQgbm90aWZpY2F0aW9ucywgbm90IHRoZSByZWNvcmRpbmcgb2Yg aW50ZXJydXB0cy4gVGhlDQo+IHN3aXRjaC1vdXQgaG9vayBzZXRzIFNOIGZvciBhIG5vbi1i bG9ja2VkIHRhcmdldC4gQW4gSU9NTVUgcG9zdGluZyBjYW4NCj4gdGhlbiBsZWF2ZSBQSVIg bm9uZW1wdHkgd2l0aCBPTj0wIGJlZm9yZSByZXNldCBzdGFydHMuDQo+IA0KPiBUaGUgZXhp c3Rpbmcgdm14X3N5bmNfcGlyX3RvX2lycigpIGluIHhlbi9hcmNoL3g4Ni9odm0vdm14L3Zt eC5jIHJldHVybnMNCj4gYmVmb3JlIHRvdWNoaW5nIFBJUiBpbiB0aGF0IHN0YXRlOg0KPiAN Cj4+ICAgICAgaWYgKCAhcGlfdGVzdF9vbihkZXNjKSApDQo+PiAgICAgICAgICByZXR1cm47 DQo+IA0KPiBDb25zZXF1ZW50bHkgdGhlIG5ldyBjYWxsIGNhbiBsZWF2ZSBhbiBvbGQgdmVj dG9yIGluIFBJUiB3aGlsZSByZXNldA0KPiBjbGVhcnMgSVJSIChJbnRlcnJ1cHQgUmVxdWVz dCBSZWdpc3RlcikuIEl0IGNhbiBsYXRlciBiZSB0cmFuc2ZlcnJlZA0KPiBpbnRvIHRoZSBm cmVzaCBJUlIuIFRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgcmVzZXQgZ2FwLCBub3QgYSBuZXcN Cj4gcmVncmVzc2lvbiBpbnRyb2R1Y2VkIGJ5IHRoaXMgcGF0Y2guDQo+IA0KPiBDaGVja2lu ZyBQSVIgYXMgd2VsbCBhcyBPTiBpbiB2bXhfc3luY19waXJfdG9faXJyKCkgd291bGQgYWRk IHJlYWRzDQo+IHRvIG9yZGluYXJ5IHBlbmRpbmcgcXVlcmllcywgaW5jbHVkaW5nIGh2bV92 Y3B1X2hhc19wZW5kaW5nX2lycSgpLg0KPiBSZXNldCBpbnN0ZWFkIHdhbnRzIHRvIGRpc2Nh cmQgdGhlIGJpdHMgcmVnYXJkbGVzcyBvZiBPTi4NCj4gDQo+IFdoYXQgZG8geW91IHRoaW5r PyBXb3VsZCByZXBsYWNpbmcgdGhlIG5ldyBjYWxsIHdpdGggdGhpcyBvcHRpb25hbA0KPiBi YWNrZW5kIGhvb2sgZml0IHRoaXMgcGF0Y2ggYmV0dGVyPw0KPiANCg0KTG9va3MgZ29vZCB0 byBtZSwganVzdCBhIHNsaWdodCBhZGp1c3RtZW50IEkgd291bGQgYWRkLg0KDQo+IGRpZmYg LS1naXQgYS94ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5jIGIveGVuL2FyY2gveDg2L2h2bS92 bGFwaWMuYw0KPiAtLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5jDQo+ICsrKyBiL3hl bi9hcmNoL3g4Ni9odm0vdmxhcGljLmMNCj4gQEAgLTE0MzMsMTEgKzE0MzMsMTEgQEAgc3Rh dGljIHZvaWQgdmxhcGljX2RvX2luaXQoc3RydWN0IHZsYXBpYyAqdmxhcGljKQ0KPiAgICAg ICAgICAgcmV0dXJuOw0KPiAgIA0KPiAgICAgICAvKg0KPiAtICAgICAqIERyYWluIHRoZSBw b3N0ZWQgaW50ZXJydXB0IGRlc2NyaXB0b3IgKGFuZCBjbGVhciBpdHMgT04gYml0KSBiZWZv cmUNCj4gLSAgICAgKiB6ZXJvaW5nIHRoZSBJUlIsIHNvIHRoYXQgdmVjdG9ycyBwb3N0ZWQg YmVmb3JlIHRoZSByZXNldCBkb24ndCBnZXQNCj4gLSAgICAgKiBtZXJnZWQgaW50byB0aGUg ZnJlc2ggSVJSIGJ5IGEgbGF0ZXIgc3luYy4NCj4gKyAgICAgKiBEaXNjYXJkIHBvc3RlZCBp bnRlcnJ1cHRzIGJlZm9yZSByZXNldHRpbmcgdGhlIEFQSUMgcmVnaXN0ZXJzLA0KPiArICAg ICAqIGluY2x1ZGluZyBzdXBwcmVzc2VkIHBvc3RpbmdzIHdoaWNoIGhhdmUgbm90IHNldCBP Ti4NCj4gICAgICAgICovDQo+IC0gICAgaHZtX3N5bmNfcGlyX3RvX2lycih2bGFwaWNfdmNw dSh2bGFwaWMpKTsNCj4gKyAgICBpZiAoIGh2bV9mdW5jcy5yZXNldF9waXIgKQ0KPiArICAg ICAgICBhbHRlcm5hdGl2ZV92Y2FsbChodm1fZnVuY3MucmVzZXRfcGlyLCB2bGFwaWNfdmNw dSh2bGFwaWMpKTsNCj4gICANCj4gICAgICAgdmxhcGljX3NldF9yZWcodmxhcGljLCBBUElD X0xWUiwgVkxBUElDX1ZFUlNJT04pOw0KPiAgIA0KPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gv eDg2L2h2bS92bXgvdm14LmMgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYw0KPiAtLS0g YS94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYw0KPiArKysgYi94ZW4vYXJjaC94ODYvaHZt L3ZteC92bXguYw0KPiBAQCAtMjQzNyw2ICsyNDM3LDE3IEBAIHN0YXRpYyB2b2lkIGNmX2No ZWNrIHZteF9zeW5jX3Bpcl90b19pcnIoc3RydWN0IHZjcHUgKnYpDQo+ICAgICAgIH0NCj4g ICB9DQo+ICAgDQo+ICsvKiBEaXNjYXJkIHBvc3RlZCBpbnRlcnJ1cHRzIHdpdGhvdXQgZGVw ZW5kaW5nIG9uIG5vdGlmaWNhdGlvbiBzdGF0ZS4gKi8NCj4gK3N0YXRpYyB2b2lkIGNmX2No ZWNrIHZteF9yZXNldF9waXIoc3RydWN0IHZjcHUgKnYpDQo+ICt7DQo+ICsgICAgc3RydWN0 IHBpX2Rlc2MgKmRlc2MgPSAmdi0+YXJjaC5odm0udm14LnBpX2Rlc2M7DQo+ICsNCj4gKyAg ICAodm9pZClwaV90ZXN0X2FuZF9jbGVhcl9vbihkZXNjKTsNCj4gKw0KPiArICAgIGZvciAo IHVuc2lnbmVkIGludCBpID0gMDsgaSA8IEFSUkFZX1NJWkUoZGVzYy0+cGlyKTsgKytpICkN Cj4gKyAgICAgICAgKHZvaWQpeGNoZygmZGVzYy0+cGlyW2ldLCAwKTsNCj4gK30NCj4gKw0K DQpJIHdvdWxkIHJhdGhlciBpbnRyb2R1Y2UgcGlfY2xlYXJfb24oKQ0KDQpzdGF0aWMgaW5s aW5lIHZvaWQgcGlfY2xlYXJfb24oc3RydWN0IHBpX2Rlc2MgKnBpX2Rlc2MpDQp7DQogICAg IGNsZWFyX2JpdChQT1NURURfSU5UUl9PTiwgJnBpX2Rlc2MtPmNvbnRyb2wpOw0KfQ0KDQpB bmQgd3JpdGUgdm14X3Jlc2V0X3BpcigpIGFzIDoNCg0KLyogRGlzY2FyZCBwb3N0ZWQgaW50 ZXJydXB0cyB3aXRob3V0IGRlcGVuZGluZyBvbiBub3RpZmljYXRpb24gc3RhdGUuICovDQpz dGF0aWMgdm9pZCBjZl9jaGVjayB2bXhfcmVzZXRfcGlyKHN0cnVjdCB2Y3B1ICp2KQ0Kew0K ICAgICBzdHJ1Y3QgcGlfZGVzYyAqZGVzYyA9ICZ2LT5hcmNoLmh2bS52bXgucGlfZGVzYzsN Cg0KICAgICBwaV9jbGVhcl9vbihkZXNjKTsNCg0KICAgICBmb3IgKCB1bnNpZ25lZCBpbnQg aSA9IDA7IGkgPCBBUlJBWV9TSVpFKGRlc2MtPnBpcik7ICsraSApDQogICAgICAgICB3cml0 ZV9hdG9taWMoJmRlc2MtPnBpcltpXSwgMCk7DQp9DQoNCg0KTm90IHN1cmUgd2hpY2ggaXMg YmVzdCBoZXJlIGJldHdlZW4gd3JpdGVfYXRvbWljIChtb3ZxKSBhbmQgeGNoZy4NCkFsdGVy bmF0aXZlbHksIHdlIGNhbiBhbHNvIHVzZSBgQUNDRVNTX09OQ0UoZGVzYy0+cGlyW2ldKSA9 IDA7YC4NCg0KPiAgIHN0YXRpYyBib29sIGNmX2NoZWNrIHZteF90ZXN0X3Bpcihjb25zdCBz dHJ1Y3QgdmNwdSAqdiwgdWludDhfdCB2ZWMpDQo+ICAgew0KPiAgICAgICByZXR1cm4gcGlf dGVzdF9waXIodmVjLCAmdi0+YXJjaC5odm0udm14LnBpX2Rlc2MpOw0KPiBAQCAtMzE3Niw2 ICszMTg3LDcgQEAgY29uc3Qgc3RydWN0IGh2bV9mdW5jdGlvbl90YWJsZSAqIF9faW5pdCBz dGFydF92bXgodm9pZCkNCj4gICANCj4gICAgICAgICAgIHZteF9mdW5jdGlvbl90YWJsZS5k ZWxpdmVyX3Bvc3RlZF9pbnRyID0gdm14X2RlbGl2ZXJfcG9zdGVkX2ludHI7DQo+ICAgICAg ICAgICB2bXhfZnVuY3Rpb25fdGFibGUuc3luY19waXJfdG9faXJyICAgICA9IHZteF9zeW5j X3Bpcl90b19pcnI7DQo+ICsgICAgICAgIHZteF9mdW5jdGlvbl90YWJsZS5yZXNldF9waXIg ICAgICAgICAgID0gdm14X3Jlc2V0X3BpcjsNCj4gICAgICAgICAgIHZteF9mdW5jdGlvbl90 YWJsZS50ZXN0X3BpciAgICAgICAgICAgID0gdm14X3Rlc3RfcGlyOw0KPiAgICAgICB9DQo+ ICAgDQo+IEBAIC0zMjEyLDYgKzMyMjQsNyBAQCB2b2lkIF9faW5pdCB2bXhfZmlsbF9mdW5j cyh2b2lkKQ0KPiAgIA0KPiAgICAgICB2bXhfZnVuY3Rpb25fdGFibGUuZGVsaXZlcl9wb3N0 ZWRfaW50ciA9IHZteF9kZWxpdmVyX3Bvc3RlZF9pbnRyOw0KPiAgICAgICB2bXhfZnVuY3Rp b25fdGFibGUuc3luY19waXJfdG9faXJyICAgICA9IHZteF9zeW5jX3Bpcl90b19pcnI7DQo+ ICsgICAgdm14X2Z1bmN0aW9uX3RhYmxlLnJlc2V0X3BpciAgICAgICAgICAgPSB2bXhfcmVz ZXRfcGlyOw0KPiAgICAgICB2bXhfZnVuY3Rpb25fdGFibGUudGVzdF9waXIgICAgICAgICAg ICA9IHZteF90ZXN0X3BpcjsNCj4gICB9DQo+ICAgDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJj aC94ODYvaW5jbHVkZS9hc20vaHZtL2h2bS5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt L2h2bS9odm0uaA0KPiAtLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZtL2h2bS5o DQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9odm0vaHZtLmgNCj4gQEAgLTIx OCw2ICsyMTgsOCBAQCBzdHJ1Y3QgaHZtX2Z1bmN0aW9uX3RhYmxlIHsNCj4gICAgICAgdm9p ZCAoKnByb2Nlc3NfaXNyKShpbnQgaXNyLCBzdHJ1Y3QgdmNwdSAqdik7DQo+ICAgICAgIHZv aWQgKCpkZWxpdmVyX3Bvc3RlZF9pbnRyKShzdHJ1Y3QgdmNwdSAqdiwgdTggdmVjdG9yKTsN Cj4gICAgICAgdm9pZCAoKnN5bmNfcGlyX3RvX2lycikoc3RydWN0IHZjcHUgKnYpOw0KPiAr ICAgIC8qIERpc2NhcmQgcGVuZGluZyBwb3N0ZWQgaW50ZXJydXB0cyBhbmQgbm90aWZpY2F0 aW9uIHN0YXRlIG9uIHJlc2V0LiAqLw0KPiArICAgIHZvaWQgKCpyZXNldF9waXIpKHN0cnVj dCB2Y3B1ICp2KTsNCj4gICAgICAgYm9vbCAoKnRlc3RfcGlyKShjb25zdCBzdHJ1Y3QgdmNw dSAqdiwgdWludDhfdCB2ZWN0b3IpOw0KPiAgICAgICB2b2lkICgqaGFuZGxlX2VvaSkodWlu dDhfdCB2ZWN0b3IsIGludCBpc3IpOw0KPiAgICAgICBpbnQgKCpwaV91cGRhdGVfaXJ0ZSko Y29uc3Qgc3RydWN0IHZjcHUgKnYsIGNvbnN0IHN0cnVjdCBwaXJxICpwaXJxKTsNCj4gDQo+ IFRoZSBPTiBjbGVhciBpcyBiZWZvcmUgY2xlYXJpbmcgUElSLCBwcmVzZXJ2aW5nIHRoZSBy ZXF1aXJlZA0KPiBjbGVhci1PTi1iZWZvcmUtZHJhaW5pbmctUElSIG9yZGVyaW5nIChzZWUg dm14X3N5bmNfcGlyX3RvX2lycigpKS4NCj4gDQo+IFRoZSBoZWxwZXIgbmVlZHMgb25seSB0 aGUgaW5saW5lIGRlc2NyaXB0b3IsIHNvIGluaXRpYWwgTEFQSUMgc2V0dXANCj4gY2FuIGNh bGwgaXQgYmVmb3JlIFZNQ1MgY3JlYXRpb24uIFRoZSBob29rIGlzIG9wdGlvbmFsIGFuZCBp bnN0YWxsZWQNCj4gZm9yIFZNWCBwb3N0ZWQtaW50ZXJydXB0IHN1cHBvcnQsIGluY2x1ZGlu ZyB0aGUgdm14X2ZpbGxfZnVuY3MoKSBlbnRyeS4NCj4gDQo+IEZvciB0aGUgc2VyaWVzIGFz IHBvc3RlZCwgYW5kIGFsc28gd2l0aCB0aGUgc3VnZ2VzdGVkIGNoYW5nZSBhYm92ZQ0KPiBp bmNvcnBvcmF0ZWQ6DQo+IA0KPiBBc3Npc3RlZC1ieTogQ29waWxvdDpncHQtNi1hc3RyYS1o aWdoLCBDb3BpbG90OmdwdC02LjEtc29sLWhpZ2gteGhpZ2gtbWF4ICMgcmV2aWV3DQo+IFJl dmlld2VkLWJ5OiBCZXJuaGFyZCBLYWluZGwgPGJlcm5oYXJkLmthaW5kbEBjaXRyaXguY29t Pg0KPiANCj4gY3UsIEJlcm5oYXJkDQo+IA0KDQpUZWRkeQ0K --------------P09eaBqWh67iXQKJFFAcbuwv-- --------------9BsBj9Td2zo0ekrIU7xai3qA 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+p0QLLz9AFAmrff6cFAwAAAAAACgkQZg+p0QLLz9DT 1Qv/ZOll3NOBtBPdtmrIrsYknX/XxQKLIypyLZXXqMKvNUrPHtNyM2FI+729j6C0I5C6UdvzFdZv fHHriFvr+f8op7KfVkmuEpxR9fO0+hLiGoWrauYyd8kr+cdiWWg76IVNP9PP5NwRQxG4dtESlC3H baIgx3n/XhLsh2afPv2rvZ3zWPa5/TN0m9JmKtHXSkt58ML2rIZE2iu9YYiDCEl8ln/vGhVdC3bL BFijs7xTIpIvXcghIc9rBwurft+GMElftllG10r8YQHZqJBfaLZkYvgTEWpDDBhBa7kMJdE/zvqY nFTMe7xOrPFFf4o2RAWofLX1jBqGnAJWZfuhdMaH/7m4Jhab0iznVmkNGP+zdlWARBnyFr/YlHM/ tzFbnd8hADuAW4CTx4Bv+KVk37BcBiiK0Extk4Qrlr47KUhHYuvoOA5OC2KkirFNleBSqiLQj2Pz NXVkAOSfVJjrDi7gyEciHgNRMKdtk0KDR8r+MsWmxSnMwNnjlXCYt6oQox4C =3id0 -----END PGP SIGNATURE----- --------------9BsBj9Td2zo0ekrIU7xai3qA-- From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:46:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:46:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461600.1672649 (Exim 4.92) (envelope-from ) id 1xLNq3-0002U9-4L; Mon, 26 Oct 2026 16:46:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461600.1672649; Mon, 26 Oct 2026 16:46: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 1xLNq3-0002U1-07; Mon, 26 Oct 2026 16:46:23 +0000 Received: by outflank-mailman (input) for mailman id 1461600; Mon, 26 Oct 2026 16:46:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLNq1-0002Tv-Fd for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:46:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLNq0-0058YT-7c for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:46:20 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf83d1-8faa-0a2a0a5109dd-0a2a4503dc86-16 for ; Mon, 26 Oct 2026 17:46:20 +0100 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf83dc-fae8-0a2a45030019-d155dd2fc854-3 for ; Mon, 26 Oct 2026 17:46:20 +0100 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48c4d870d54so1917725f8f.2 for ; Mon, 26 Oct 2026 09:46:20 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ece13aasm16238676f8f.58.2026.10.26.09.46.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 09:46: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=1793033180; x=1793637980; 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=OVqijri3Coex1U/Y+HLIuqBZhqmkYm1Dyejt+PNag44=; b=XemL/NC1vKv9u+PPFGSEUsNRGUkk9AGEa1YhOFhSgjzk0TBXLKRE1tM+jfmWb+PlVA yrZzkJHRU8SqPKMCLooDDqWhaODTpBsR6fILBL6hSY2aFt8eW+6BQjb2yO+QPo1LtZUl A8/wj6i0zFE6ItC4cyY129gRheUNamNOpuopjpZlU+WBUFAHVEJtpRfO17EzppbmcKlu /zkm8qeh1QkyPNwU4I0yfWEjHZcUKOfpDEgEJK3EzQlhU8Ifk1WsGlJ38qX0QTd2iYTd 9jRF+XVkkYgBUfdkAl0CaWa5/qaddf1Oegysyxp2KHB1xJL3sTfmMAO4dOsVOdwBMmPK Dv4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793033180; x=1793637980; 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=OVqijri3Coex1U/Y+HLIuqBZhqmkYm1Dyejt+PNag44=; b=D82UEsgW6g/XdoQG74SFEwI7up3GdscqUzh3IxH3fJDIPd2l4/Hx4dPQIjX5EMd+aL I8dP2v/ArwckivtJ4QWALHbXs6aJpt4TSHshBshKLLOOzv78VCtJdP/o38G5HLZYtr49 06L0kT81DIDUH+S5T3F2X0qo6/RN3eZZNwg8YxJrY8XiDOLVjpugFqPf2GZ0+DoNup6a 5qEaTUtmCvBCs/a23/Se8+YiuaRZZ29xOnyjJtCA48qJoS0OqBCZo4BCJEzSzg22jWwq soCt5IO0uAjupw/neuRv5bWlxtd8TImcoWvDL0k/4YDvgvbHBCR2XAyqcAzBoaplTkv/ FmlQ== X-Forwarded-Encrypted: i=1; AKwUvByHCsEqQpL163ynjP7JriH0Op5YS627QQgkMpzdRFyXzNepmImq6FOXYFx4zN32syeArieKrN7sX+w=@lists.xenproject.org X-Gm-Message-State: AFq9FYK2C9BG6neb61G0pAqiUnq5m2yRzVA0D8rIb/7g5GGEEFkDmEH4 hUDlznmOQDlh4U+9ac2kJot0sCIdMhZahm/y3VTziQP+Bd1SjdrJCZQo X-Gm-Gg: AYBFou1gV31btqIrRwLKtDUoa/AN8d9tA5T5bnfid2ksXiYSrmUmhJzlIDjn+JaT10b r6fBJbXOSeRo8/H59AvFV4dAtaZmSzkXUx/Wwlcb84rkH5e61vAW3s+AiCXc1WeJ9RvhNOemLJc rlUFdSWRAjWE/cUsEARoOK8xze38KRIBbj3t2qZ6pXnUkMaCZ4E6cpbB53lh/u0znZgGTMqo6b/ PsCfiQUJvVVElB64SYtAX/b3DJiBVZeLo+GOoBXd0Y/20uAfEzy//SEvtLn83TvCdCJPXSmmynO IQ/IvgUc3h3gPROSyBrQMbVTD7Xlvuu6ka/KvNNDP7b0XDroUCvkpDJ1XT9n7IR3KhOU1NiMnzK M++h6kWyTgA/jQdhSWUdxusrZdGcC+SCGW8WLQAtApS/DWATmgAXBXKJSyCXDkh7K6qfPzsOzyh Xur8gHIvt4z+t6mbsF+RKY+ltSXFjYrVkF9y0OUi9wlWGBmIvad8T0FLa+z9NbA++XSGQfVx4BS OLMIBDPQ3SH2wHYHi7A11vGUcKAXyjo6NSZWPmIR4ObWCbYkhNuhequgBhYBRRWGLtD9LkmB98B NPBCyH7yAS8WtAT+/Rqe4l5Iviqq X-Received: by 2002:a05:6000:2410:b0:48e:44c7:bf0f with SMTP id ffacd0b85a97d-48e44c7bfeemr12077412f8f.25.1793033179324; Mon, 26 Oct 2026 09:46:19 -0700 (PDT) Message-ID: <9bd50f03-721f-4750-915f-e7ea7553cc92@gmail.com> Date: Mon, 26 Oct 2026 17:46:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] xen/ns16550: drain TX before reinitializing the UART To: Zhang Zheng , xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <938aadfc32c531f934291fdff3763cdefd5849e6.1792467713.git.zhangzheng@iscas.ac.cn> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <938aadfc32c531f934291fdff3763cdefd5849e6.1792467713.git.zhangzheng@iscas.ac.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1793033180-778F24E9-9E076842/10/73395122804 X-purgate-type: spam X-purgate-size: 3119 On 10/20/26 5:45 AM, Zhang Zheng wrote: > Drain pending output before resetting FIFOs. Bound the wait to avoid > hanging boot if the UART never reports empty. > > Wait for TEMT (which already implies THRE on a 16550) to ensure > transmission has finished before reconfiguration. uart->lsr_mask normally > checks only THRE, which indicates room for more output. > > Signed-off-by: Zhang Zheng > --- > xen/drivers/char/ns16550.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index 1f54155d67..29f784280e 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -410,6 +410,12 @@ static void ns16550_setup_preirq(struct ns16550 *uart) > static void __init cf_check ns16550_init_preirq(struct serial_port *port) > { > struct ns16550 *uart = port->uart; > + cycles_t start; > + /* > + * Too early for proper time calibration, assume a 5GHz CPU and let it wait > + * about 1s, with still reasonable timeout on a slower CPU. > + */ > + cycles_t timeout_ticks = 5UL * 1000 * 1000 * 1000; Shouldn't we use here ULL? 5UL * 1000 * 1000 * 1000 > MAX_unsingned_long on 32-bit platforms, at least, for arm33 and riscv32 unsigned long is 4-byte type? Also, I think that the comment should be updated as get_cycles() doesn't count CPU cycles: - on RISC-V it reads the time CSR, which ticks at the timebase frequency. E.g. on SpacemiT K1 that's 24MHz, so the "about 1s" becomes ~208s; with QEMU virt's 10MHz it's ~500s. - on Arm it reads CNTPCT, again typically in the tens of MHz range, with similar results. So it won't be 1s for that arch-s. Also for Arm and RISC-V preinit_xen_time() runs before console_init_preirq(), so time is already usable at this point if I am not mistaken something so "Too early for proper time calibration" sounds incorrect. > > #ifdef CONFIG_HAS_IOPORTS > /* I/O ports are distinguished by their size (16 bits). */ > @@ -427,6 +433,15 @@ static void __init cf_check ns16550_init_preirq(struct serial_port *port) > #endif > } > > + /* > + * Drain firmware/early-console output before changing line settings or > + * resetting FIFOs. Wait for TEMT so the shift register is empty too. > + */ > + start = get_cycles(); > + while ( !(ns_read_reg(uart, UART_LSR) & UART_LSR_TEMT) && This is done before pci_serial_early_init() (called from ns16550_setup_preirq()), so for a PCI UART (specified via / or found via "pci") whose decoding hasn't been enabled by firmware, the LSR read may still return all ones. With TEMT set in that value, the wait is then simply skipped. That's harmless, but perhaps worth a word in the description or a code comment. > + get_cycles() - start < timeout_ticks ) > + cpu_relax(); > + > ns16550_setup_preirq(uart); > > /* Check this really is a 16550+. Otherwise we have no FIFOs. */ ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:47:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:47:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461608.1672656 (Exim 4.92) (envelope-from ) id 1xLNrJ-0002zd-Bf; Mon, 26 Oct 2026 16:47:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461608.1672656; Mon, 26 Oct 2026 16: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 1xLNrJ-0002zW-93; Mon, 26 Oct 2026 16:47:41 +0000 Received: by outflank-mailman (input) for mailman id 1461608; Mon, 26 Oct 2026 16:47:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLNrI-0002zQ-Ia for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:47:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLNrH-007lt5-VN for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:47:39 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf8419-e002-0a2a0a5209dd-0a2a4507d02e-26 for ; Mon, 26 Oct 2026 17:47:39 +0100 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf842b-b4ea-0a2a45070019-d155dd31c890-3 for ; Mon, 26 Oct 2026 17:47:39 +0100 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48c4d870d54so1918546f8f.2 for ; Mon, 26 Oct 2026 09:47: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-48e3ebcb902sm18257927f8f.24.2026.10.26.09.47.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 09:47: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=1793033259; x=1793638059; 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=iAf5uxPV3dqLf1y5npVN1ioosjLkGMccQTf7bTfhxSI=; b=Al5cAL/H+XiVnYWAs5XxiwuawgX5QG7gMmeFSD505ptcJl+uXJ8QF7lthSfKwGFDQf TDtCVqaszyLtWxk8aVO8O7Ws+ySgVeFAPW0NW8rYS6xp02CpGQkQoghkzKlqiuDJca68 DMYvs3qhl3GcPYoOjfXPDdbvDwvuled5UA/cVEQlSHX68ltrvcNRdDFY+gvo/HL6kdKW YzoZoIXgApOK+SsTLgRAwGbywRmpBOHBKKhMMtXqGC6o1Mr7JRn+DAa3FB0w8S3DeY4X yKueV0/K0YMtL9/fWjWHWPp/RujnjsgV0LqRbqAX2VdU/OLRO7pW/oRwY7xRSiDIhjqI ry5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793033259; x=1793638059; 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=iAf5uxPV3dqLf1y5npVN1ioosjLkGMccQTf7bTfhxSI=; b=XLe/0B3uMEEEd8AOLh6UmXvimvY+nKKQojB5/fl/KrSi/9FSRt9HX/rqBOtoYvpiTO 1TVJcc8Gr+WJnDlp+kpOMpJolSHpTTgeHMfNFsO5QJYsuf1+iS2gdyWzYdkkH1D1Px0y 2aa5PElCawKSq32zWfgmN2hYjl9ysm7FdOLfdncL1A39nb+1J2TsePuJehE6hUBOAAZE l9NKlLz9LPqd27YDcEhmmnipIc4xL63Vz74oH29a2wbBIyUmD/AcOPUTD7uIWHrhuB7L dxZZJjRLHIpNJ2Yf+HXPsy/SjqwqJZrrPQAViUWXurWmv6bslt5rDUhb4sXogYV1hla+ XKdw== X-Forwarded-Encrypted: i=1; AKwUvBzd2oge9XLAss/Wmdz6/lWj6I/4GqyE0En3yq2bDZPuUZsROksJbGW1jxck6zoYSNI0yeALUXv+png=@lists.xenproject.org X-Gm-Message-State: AFq9FYK03kaM7xDszfwy3lGoXD5QkL6XV11SbhsnWph03O7DclTtjwqK sLUC+4RfHeWcIf0co6iTR3s3SjMOk9F42HkBCzxSMgTk8hNVhgOVuIFBY+AxLPW17JXdLOUXF0k FNzqfsg== X-Gm-Gg: AYBFou39kncfBmr7WGqdRO4Slvs/A6nPXyjA99XRan75ATujyDZkgjDMkY/Trj8xBBW T60C4iiPJr3i+1WMOhl37nRB9Kt8tqD3d+al7xkIYl4OhuWydNB5izKtxaUwiWJd3SpDlVsAssd okpylO63Y0UaVU7TtWKAy3jBHQXqVQPLVGdDUQ9M+yALHTbREmxGdkxOjW4stnIPSB35xLKXt0Z u1+UUuuqVTD7SCz5Vq+ks9JxpI8u3CJHU3KaWBYQz3Mn/3BP84zzCJFBOya3eTmefTLtSZ+Mgf1 7hiALV/F3qGUKaTj70dA7yVp3CQhrB4TUyQ/eP/abe0pbG3JpeM0AGO5Dd+0KmZVzyeKnivLDs8 JsliW9RkQ7JmPrt8kSYtTxSX44qnEcwusRUyeglefbnm6pKuSeIeEmbdTS5FoocrYstyucZh4zT ZlbICQqOsVR5uwJcyNfFB8jrw1tjJkoEBe5fj7i/yMwBRQH/6GlIQud6pBrFdCJyIero69gYmqD h7CZ8ucgpjptNWgnww3FUvCjoIXgffoixHspe068ohl5APAxZvhJ1eAWxarcIbyR2r0c83vpOzo 2q69wF8eX5udKeo/LYbeUHNJuGGwHLvrlvSPre07A4w= X-Received: by 2002:a05:6000:612:b0:48d:b650:69aa with SMTP id ffacd0b85a97d-48e3eba5700mr13927070f8f.50.1793033259069; Mon, 26 Oct 2026 09:47:39 -0700 (PDT) Message-ID: <21702cbe-7506-4b2c-a0e9-80d9fabb33c8@suse.com> Date: Mon, 26 Oct 2026 17:47:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/nestedhvm: Inline nestedhvm_vcpu_in_guestmode() To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1793029157.8631fc262581453bbf619ec5b2062170.1a178ddb234000f79f@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: <1793029157.8631fc262581453bbf619ec5b2062170.1a178ddb234000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1793033259-A5CC7AE4-363BC314/10/78276251493 X-purgate-type: spam X-purgate-size: 259 On 26.10.2026 16:38, Teddy Astie wrote: > This function just returns vcpu_nestedhvm(v).nv_guestmode and would > be better inlined to improve codegen. > > Signed-off-by: Teddy Astie Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:50:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:50:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461615.1672665 (Exim 4.92) (envelope-from ) id 1xLNtj-0004pf-N1; Mon, 26 Oct 2026 16:50:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461615.1672665; Mon, 26 Oct 2026 16: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 1xLNtj-0004pY-KM; Mon, 26 Oct 2026 16:50:11 +0000 Received: by outflank-mailman (input) for mailman id 1461615; Mon, 26 Oct 2026 16:50:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLNti-0004pS-Qa for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:50:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLNti-001PPF-7F for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:50:10 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf84be-bab6-0a2a0a5309dd-0a2a4503c6e2-6 for ; Mon, 26 Oct 2026 17:50:10 +0100 Received: from [40.93.194.14] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf84c0-fae8-0a2a45030019-285dc20ed227-3 for ; Mon, 26 Oct 2026 17:50:09 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH2PR03MB5285.namprd03.prod.outlook.com (2603:10b6:610:9c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.21; Mon, 26 Oct 2026 16:50: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%4]) with mapi id 15.21.0546.021; Mon, 26 Oct 2026 16:50: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=u+0kV90Pi01Li5qywppNXXtLIiXETQNQrytXcSZjmLcgry9Zb0V3Ax1vf6pa2666dSryTGpKiz3B2AGf2v88KFSm5uLeGlTDsELMyQplVwT70i3A+hmpEWiYe0oIveGrDcbj+AQL3mGFs/LzTlueJy3oKwQHEgaRyPiwlJUkWj2PMEks6LwJslmR55znI4sDMHFtDgFVG4KP+aPrZzeiJlIOGfY2xd5wBLABUCf8aKcn6e3yQbVOEQHL3OtckSupM2l/FojDrSBVyZONSLjrAbM35eaaYxQxWeLGXCdkFkQ0x+XkH4Gn89bMze9bzKVpTaAbVHyHYVvSmHr3Ahe/8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yMdyQ6Hqa9K3PllenI77mVJV2eRPTEtGoPhOlGD45OM=; b=rG1+2QKLylBxjKP3ijm6g243/UvEqmKDOhp3lN1WJJFFr8kCddVB6Bw3+1fMMmza7/0YyJCrqz1Yej6oIxukCCEPPGRuwMfEwdpwI7a0UhdnMOr+mJ+qY0cLV6dn+zWVRP1klWFUszUO3sKVnsDW2d//6duY9rX5OUiLpveeLeI5iZnQPUUPJMie0k4grHgV4++TBJIYRZgLPU98WoN+TOTPGaj/WcMMl4PVtY+bv5D041koyRPiM/xC4n4uQ3i+LV5SDZFP5Tps5iHYlN+URWFc5pZ+Ft9FGozxbC6RSElKLTXVIqFSmIJ6nw8ljs57AbUFjcRiWuhkwpehrvvFvA== 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=yMdyQ6Hqa9K3PllenI77mVJV2eRPTEtGoPhOlGD45OM=; b=dfm4yhzbJDJTV2o2CGDxADRopLdUVF97L83Mutgyorr2qMbCDa8lZY0wmzhk3CBQgH2DZ6QLMaVxcC/FB1ug7KGLlFUd4+N2IXph3Jc+ZTw9xstu71UvzwxUXH8bM/Kl2aTf0jflbNNhU+m5YeO1uYC/QXzvhr54v/01g350Uyw= 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: Mon, 26 Oct 2026 16:50:03 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Guillaume Thouvenin , Andrew Mbugua Subject: Re: [PATCH] tools/ocaml/libs/xs: Create FDs with the correct CLOEXEC status To: Andrii Sultanov , Xen-devel References: <20261012201857.714448-1-andrew.cooper3@citrix.com> <1793024310.8631fc262581453bbf619ec5b2062170.1a17893baae000f79f@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: <1793024310.8631fc262581453bbf619ec5b2062170.1a17893baae000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0014.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::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_|CH2PR03MB5285:EE_ X-MS-Office365-Filtering-Correlation-Id: aa6ef994-f8ab-49de-1b88-08df3381308c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|261026140227099003|4143699003|56012099006|11063799006|261021123027099003|261022075727099003|261021121427099003|261022105027099003|261009223027099003|261022113327099003|261026121527099003|18002099003|22082099003|6133799003|10067099003; X-Microsoft-Antispam-Message-Info: XP93IzkoNtYfpoOd1mVrouLBJvGUl7Aw59xdVSkZWLpD2enu6VPXL2c5na1TlEYDd++ivizB+ae5YIE2wwuI0g0jy74xcS6DrmCsbn1GDzeE4igzkgzbs6JJ/lynQ1EEmlWiWdLcwpdyf/vWTIz8ll5Ndi7KCx7NDbsaVrPjXGGNPqJ3QMPUkWOjHJMCjBZ6Lg4n9Vkn4EEHohoE58PLSFza3wRYZ16e7RMktqe7og+WxZCHPsApf/Zpm2Ce8g987MVWDqx4OkBhFfkMkXxyflQ3n9gU7b0jvlO4ESSDRFeEOqpwj+AeZJcrmPUfzJPze68vRnxgB4bAxEgBXnDiC115fKeeJFBSzVK9qRB25+wzcqrUN2XRw4Z8MKPLy4/0rpKC/5GNq0luNEDy4t07XcXQO3evX00qAXG1D+YfwrzgcRVZSDSzz3URfD5cDFzcDS4L7FxLUzU8JWkCFs5W12eUMLFs4yTtoEkdQc8IVTSWLGvTPRCjDb+UDULX8fAiECK00DHeuEB6nbIobdmvvIbb00ucyzPjH4vDf2vmgRhrBLx8zbGYMqmdNQbNN+oo4Hx/tDspvwuOq80/de9gth1C+7p9HQiHWxLT5GSjQZHPtAkyziphAWNgr91Z54wM7X1V/X72RfgXIGjhw51MC4aPr9/rViw2Yd+mPDWJFDY= 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)(261026140227099003)(4143699003)(56012099006)(11063799006)(261021123027099003)(261022075727099003)(261021121427099003)(261022105027099003)(261009223027099003)(261022113327099003)(261026121527099003)(18002099003)(22082099003)(6133799003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bG5VbUJuTlplMTlSNk03SHdYKzlNRmdtNUZWNkhpUjhLcml5anBOSlZzNUxZ?= =?utf-8?B?QVBIQjZPYWZRbXYwMXRVTHliaEdzN2txUFJaQlUxVEhnNXV4SnhrYlhFRklv?= =?utf-8?B?Q2pvQlNETy93OHNCZ25qVXU5Z3ZueGNxbDlaaU0zVE95dlhjZjZKV3pzWTN4?= =?utf-8?B?aEs2a21PZzZlaHNWcGxkTmZmQlVjZDlCcHFHOHgrRnBnWFJLRjEyREVSTDR2?= =?utf-8?B?WU0wblhBcWtRNlpaOUdsWUIydFRkdE5xQmxHWnNiTXBiN2lXWmVBTzBVM0ln?= =?utf-8?B?enpRdUw2OTNZamltVDdMUW84WXYvUXgxczdZSkpxTWZPdURwV0lySVJmbHRu?= =?utf-8?B?NTY0Q2dmcnJ0M1BzL0VZSWsza2phaENsVjBJUy9UaFpzNC9NQnUzNUN4SHRP?= =?utf-8?B?WHF2bTVUUk5vZU5zSGhsODVCcUNwa1M2UU5jTDF3dmdDR0U1R1RLM3pkamhO?= =?utf-8?B?RWgrSWxweFhKaUlBSlhpQjJ5MEdHZTRrZnNIM2xuSjFTN1FJMWFCTHVXdGJP?= =?utf-8?B?REdUWTNzcWlOdFFRdHVQWDIzVDNONFE4Z3YwUnVOZDdEbXpRYVFwM1VqMGxw?= =?utf-8?B?L2ZSMk03SHdFTUhMK2twWDVjbHpnSXZNL1BtWW5MRG8vVWUxR0pEYmdLS05I?= =?utf-8?B?THBmWEZja2s4dkc5YWRJbFQ5SjJuSGxOeFIrSTR1eVMraEdtak1uVktYZU8y?= =?utf-8?B?L0cwV1l1VERyeXZnQTNsK1Mwd2M4dnhvKzVadk1XNmFobmk0a1hGZlY3bllP?= =?utf-8?B?YSsxZTNReHNGRUZEWjc5d3d5bGQ0OTFxcmdQdTdSRGo2YXYybDZ1WnBwTUcz?= =?utf-8?B?eHF5VnR6Mm1EN1N1UGl6QUo3R002QWZNOFNyMTZFcFphUlBnbUhyNTlQbW15?= =?utf-8?B?M1V2Y0d5TUlxdlZrelFjcjRmekVLWW85S3QrcVJLSWNHQ0JtaVdBc0FaOFRL?= =?utf-8?B?M0JMNDNKL0E0NGhvUWpJcjh0aXVpNzNud3QyZ1lvdHUvVS9jNit5QkxpVElt?= =?utf-8?B?T041bkhwZ0tydDlRcUpxeHpjS08ycHNkZURJRHdXeVIrMWNIdno2VVM3NTVF?= =?utf-8?B?L0V2TmJ6OVMzQVplbDBwQWJYd2F5Y3I0SThzTkJJRXdLVzdNQmVLWVFQQXl1?= =?utf-8?B?UG8zcm9OTDk4SytNc2xlcjZDV25BYVNod2dVTXN6cExpZWtGVDhqTTJ3RVJG?= =?utf-8?B?aDYxRWlSWU9pTndnc2JCSVNORVZoME5kVWw2OUoxZlBqSGRVNVloeWxibXV4?= =?utf-8?B?TXFDOENOU3BTVStXQlVjVVRlYVJXWFJ6SXdsZnZMSytmZWtPcnZkWjh3Tkc0?= =?utf-8?B?KzVDVG5NZ21TQ3hNWlZCZmdwNzdIVkNFVHJiMnJjc2EzM29SZnBNUDhYck0r?= =?utf-8?B?N1BYMUcrQ3Nhb2xMem9paCtSMStaQnJIQWNvOUNFdGdqTGpFcjgxWjdaMTNN?= =?utf-8?B?eUkvTUVvRGRydUNxcGRNOE5VditVOUxoU0pCTHkwOW5KMm5pOXBoWXY1c2hO?= =?utf-8?B?TVpMeEJHUy9YeGxFemJ4ZHdXZ2NXeERobjlBV2szMmpLTS9IWW9DWHpuNHFN?= =?utf-8?B?SHNKaFNBdGdmNVc5bGh5N01vU3VhbGlGVXY2eC9icHRJUDlYTnd2L2lzSG1n?= =?utf-8?B?Qk04a2JMVngwbU1ZblkyZTB5OEMvWjZ3M25KQkZtTkp4WXk5SGVoQk9sUm14?= =?utf-8?B?TDhVazA2V21pc2NQbHdlWGh5dVU3OFlrdjlqRit4ZGV3SlpRTVFudmN0R0FM?= =?utf-8?B?NldjRUFjcjFIQ3R0NHNKVWxkd3VwaU5YOUJ5TFdaR1hmd0FSYXFZWDlVajVl?= =?utf-8?B?MDN0REJRZUxKYXVFMFVVSnN5YkJLeTBmZmZNNWZCV01TTW15Qi9qYXF0em5y?= =?utf-8?B?V2d4NE9ScTF4bzlHNDhXSW1wNWRYbEVSVjNSdXY5OWE4RjlzMGYxSnhVUHRE?= =?utf-8?B?VXFLN2JzQUdzY0NiOVV1d3p0V3JqaHdTMlVIMzd0ODU3czFSS3RpZ1Z6WlNa?= =?utf-8?B?dEFUc0NyN0RjL2dVNDJrdVNsUmdDL0VRYm9UdVRSU3hvdC9JVkZjdmlIL0k1?= =?utf-8?B?NXdNeXVWaGZhSG1WRElaWnFRRk1iYjZrWk41WnYvb1RjRzQvSmNLM24xeEds?= =?utf-8?B?Sm5jaUx2dGM2YVRuL3J0THhYdktscjhMQjZVdXZrdTMrY01IdDMxRXMwMncz?= =?utf-8?B?UU5yVGU3NnAyR2tDQzR3Q3c0V21PaUxPT1laVmcwOEhxTkpYeXVKNHJMWGkz?= =?utf-8?B?UDR3d3REZ0dnb1BzZ0xUR1VnNldraG1WcURNQjhXRXUrRGRyOTZTajdsN1cz?= =?utf-8?B?bFpUWVk1TzhYM1ZBNlY2am5oZWNqbmQ3UVRmVTlpUjRLWlVsb01hZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa6ef994-f8ab-49de-1b88-08df3381308c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 16:50:06.8972 (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: mFJVjlto5nzicdSVDh0YF1jjEF8MtmIRqfYDmwrhsJTdetn9n1QX++PVUeQq4ppmUbNB0iYzad7SeS1RsD+QMfEXOPRwMR1khxq/1TbYG8w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5285 X-purgate-ID: tlsNG-33051d/1793033410-7428D4E9-0AE4A5BF/0/0 X-purgate-type: clean X-purgate-size: 2694 On 26/10/2026 2:18 pm, Andrii Sultanov wrote: > On 10/12/26 21:19, Andrew Cooper wrote: > >> ... rather than editing them after the fact. >> >> This capability exists from Ocaml 4.05 which is also our minimum >> supported >> version. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Andrii Sultanov >> CC: Guillaume Thouvenin >> >> Found while reviewing the other FD handling patch. >> --- >>   tools/ocaml/libs/xs/xs.ml | 6 ++---- >>   1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml >> index addccc80099b..a088d67a8cb6 100644 >> --- a/tools/ocaml/libs/xs/xs.ml >> +++ b/tools/ocaml/libs/xs/xs.ml >> @@ -155,9 +155,8 @@ exception Failed_to_connect >>   let daemon_open () = >>     try >>       let sockaddr = Unix.ADDR_UNIX(daemon_socket) in >> -    let sock = Unix.socket Unix.PF_UNIX Unix.SOCK_STREAM 0 in >> +    let sock = Unix.socket ~cloexec:true Unix.PF_UNIX >> Unix.SOCK_STREAM 0 in >>       Unix.connect sock sockaddr; >> -    Unix.set_close_on_exec sock; >>       make sock >>     with _ -> raise Failed_to_connect >>   @@ -169,8 +168,7 @@ let domain_open () = >>       with Unix.Unix_error(_, _, _) -> >>         "/proc/xen/xenbus" in >>   -  let fd = Unix.openfile path [ Unix.O_RDWR ] 0o550 in >> -  Unix.set_close_on_exec fd; >> +  let fd = Unix.openfile path [ Unix.O_RDWR; Unix.O_CLOEXEC ] 0o550 in >>     make fd >>     let close xsh = Xsraw.close xsh.con >> >> base-commit: 0d3bb3c98bc99ec1c84ebb3df71b6e18daebff4f > The change on its own is fine - there's no functional impact. But as > far as I > can tell, these functions are not used anywhere (they haven't been > used in xapi > in a long time), so there's limited utility in this cleanup. Agreed, but it's still better to have code be correct, in case anyone else is using it. Independently, we should see about pruning the libraries which aren't used.  Sadly, they're all mutually entangled. > > Regarding your question from the original thread, if this patch was > intended > as an answer to it: > > > Where do these sockets come from?  What flags where they opened with? > > The sockets that are dumped come from xenstored.ml:process_special_fds: > >       let (cfd, _addr) = Unix.accept fd in > > The default is keep-on-exec, so there shouldn't be any need to call > Unix.clear_close_on_exec in the patches suggested by Andrew Mbugua. > > Acked-by: Andrii Sultanov > Thanks. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:50:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:50:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461617.1672675 (Exim 4.92) (envelope-from ) id 1xLNu1-00058f-25; Mon, 26 Oct 2026 16:50:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461617.1672675; Mon, 26 Oct 2026 16: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 1xLNu0-00058S-VL; Mon, 26 Oct 2026 16:50:28 +0000 Received: by outflank-mailman (input) for mailman id 1461617; Mon, 26 Oct 2026 16:50:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLNtz-00057l-6X for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:50:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLNty-007maV-Jc for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:50:26 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf84ab-bab6-0a2a0a5309dd-0a2a4506e580-30 for ; Mon, 26 Oct 2026 17:50:26 +0100 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf84d2-195a-0a2a45060019-d155dd34b8d7-3 for ; Mon, 26 Oct 2026 17:50:26 +0100 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48c4be28b82so2875238f8f.2 for ; Mon, 26 Oct 2026 09:50: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 ffacd0b85a97d-48e3eb8f387sm17114713f8f.4.2026.10.26.09.50.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 09:50: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=1793033426; x=1793638226; 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=NBEMOmrN7MEm9XYrrW5HlBqeWVevPN52g4DT1cnFz3I=; b=gWzKY9rFCRb3ZZacqe0CZYFOaMYA0im2JgX0lPppD+4XDZjXCvZ4Q3ityY67zaCmDl Q5duR1lB8mn1ldJjFB+k1VBnbecR+gGK9mP+KKSCyaj9N7xeTEfmVPyiiXsZZ1+8qvEO IRJSJRFzd3bbOl6x5HUgCCkt008g31hRycSpS5EShf/KcB/aaARCf11Sb/rFEpH6Raku qsgsztGjC+lGxP5/ZgSvxSBNXA4TI4Mg037ye/hlFWifVXpA7oDYS6QfabVHYB1SVd8W 6Cbn+y9umXXg6iycHvP7H/sLVjyyHFeCJxW+I4lhzt68oMB9N73pMxB2LbGxqS14B3iU 9L9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793033426; x=1793638226; 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=NBEMOmrN7MEm9XYrrW5HlBqeWVevPN52g4DT1cnFz3I=; b=IdZmKXtfcT4WNNB2/j/EfKEx9p09M8nP1Rz8gi8noz9Nk7/rPO/4zGs7u6X1i1kBbW QIWQIu+KCFgG4eqNw4lRUM/M3EsQW/XFwFVd5AEvTUngpTehGZaCJ1kQVpsf4YmsyVzI CZ46W8ddCHVymq4Dtx40CS9vG9AAp6u1JGk3sMasIIdQqkB4hZ7foTb2D3nDQZOIFCN6 Nu6TN+v7hzMWX6TzRybqlBEUpTZRHner+277lhsoIT7HwKQbjD4job9s9902y9EqnAg1 zdxBX2SxuxeJT4Gql8q6bpVyA9CwZ36UhjtREMpNbp8S72uT4ctOjZ61YAHaPwrH0rS7 LH9Q== X-Forwarded-Encrypted: i=1; AKwUvBw/U1JmrVR+iucoqfT4qiQ9GsyD8j/9QeKPNY0iIrSyW77xBZRm0HS019RcH+8mQOS/z2OK0DgewbI=@lists.xenproject.org X-Gm-Message-State: AFq9FYIYywlsrTBlTT0ZiN3GsUH4o08RjdnVrMLvoN47k9srBvAASVhH Wqz+FcCKMFZbktsvF0d7Z1rSYJZpinoHkKcu51wBvFuSqx2RaXk6R8XFRvj1pJJgSQ== X-Gm-Gg: AYBFou2TPBAb/8pI1xJ6WfirQ84oJkFnMFyUKiTSvVHkTCAe4ofNKgumGojMhwZdNcK 4QGI+0kxV5ZXsCSz+9Yf1J0qGKLxwtchGKEBmIRoThyzRhawuvcAr3nYMrp+GLcXX5de59paio8 VXHbzsuB59hJ9BSy+pzpnpHG0hhuQ5G/szE9TXsKX1evlwr9oj3XkIKrUjFgz+sjphoBBOQgZCs haJCTFpoWTj3xurp9PeVA7ndhToa8do7HgoL9cpnqrploRtAvYseybUna8JhgQ+uMZbXfxTQ0Sb spwXp1eAKcTC930FR6dRmcqjKga9XQDu/P307Eto9K6mNyfOswuQoPSioypIG4o0a7YTqmMRgeq 3imYyPSHcIOTokALvduJ+18BZ5/9L+SgbDRnhVbA5RSgJs5m3saydV+nPmvQXlE+uzHcYvIZ4fE HBMe7J+stLheWSmKtzyT27mCrIhCzCKJPCimeYZFlrDEMWHMOyn4jD13WEOfhIzGJ8xA2rxJ6Fl drEfU//cF6Z+F+mBZeDRCBhTQNzdcMYQD1dHz1Akim4ulqPnaevP0TYIKNbpJtA0KDCnth+6+6Q UI69wYOFMvnf+X1wWtp2odD89AJxq4WNw55yedWpHtn96w== X-Received: by 2002:a05:6000:4308:b0:48e:d88:55f4 with SMTP id ffacd0b85a97d-48e3eb455a7mr13290843f8f.2.1793033425937; Mon, 26 Oct 2026 09:50:25 -0700 (PDT) Message-ID: <8e1b5c97-c1b0-4982-aca4-d13def6590b4@suse.com> Date: Mon, 26 Oct 2026 17:50:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 3/5] xen/riscv: look up the exception table for any trap taken in Xen context To: Oleksii Kurochko Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027684.8631fc262581453bbf619ec5b2062170.1a178c73927000f79f@vates.tech> <1cd34b77-95a4-4ed2-a200-6b6e914fe9d5@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: <1cd34b77-95a4-4ed2-a200-6b6e914fe9d5@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1793033426-F440377B-4312BC21/10/78276251493 X-purgate-type: spam X-purgate-size: 2687 On 26.10.2026 16:26, Oleksii Kurochko wrote: > On 10/26/26 4:14 PM, Baptiste Le Duc wrote: >> From: Oleksii Kurochko >> >> do_trap() consulted the exception table only for CAUSE_ILLEGAL_INSTRUCTION, >> which covers csr_read_safe() but not a probing access faulting with a page >> fault cause: it would reach do_unexpected_trap() instead of its fixup. >> There is no such access yet, the A/D update scheme probe will be the first. >> >> Move the lookup ahead of the cause switch, and only do it for exceptions >> taken in Xen context. Both other cases must skip it: >> >> - Traps taken from the guest: sepc is then a guest address, which the >> guest can point at an address listed in the exception table, making Xen >> act on an entry fully under guest control. Entries are matched by exact >> address, so this needs no more than a numerical collision. > > Nit: Identations here and .. > >> >> - Interrupts: 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. > > ... looks incorrect a little bit. An extra space should be dropped. Things are indeed off-by-1 in your reply, but in Baptiste's original mail all looks fine. >> Returning early skips check_for_pcpu_work(), which is correct: that only >> runs for traps taken from the guest. >> >> Cache the "trap came from the guest" test in a local as it is now used >> three times. >> >> Signed-off-by: Oleksii Kurochko >> [Baptiste: drop the parts depending on the vAPLIC/vIMSIC series, adapt >> the commit message] >> Assisted-by: Claude:claude-opus-5-5 >> Signed-off-by: Baptiste Le Duc >> --- >> Changes since v7: >> - new patch, needed by the A/D update scheme probe of the next patch, >> whose store page fault would otherwise not be fixed up. Taken from: >> https://patch.msgid.link/4e2b4e7a99f4d2133ff92559303d19382749de7a.1790779209.git.oleksii.kurochko@gmail.com >> - commit message adapted to this subset: drop the hlv/hlvx and >> EX_TYPE_TRAP_INFO parts and the paragraph on the guest page fault >> BUG_ON(), whose code isn't taken; mention the from_guest local, which >> this subset introduces. >> - apply my v3 review suggestion to the commit message: state up front >> that the lookup is only done for exceptions taken in Xen context and >> list traps taken from the guest and interrupts as the skipped cases. >> --- > LGTM: > > Reviewed-by: Oleksii Kurochko Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 16:59:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 16:59:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461629.1672684 (Exim 4.92) (envelope-from ) id 1xLO2c-0006hU-Sy; Mon, 26 Oct 2026 16:59:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461629.1672684; Mon, 26 Oct 2026 16: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 1xLO2c-0006hN-Pg; Mon, 26 Oct 2026 16:59:22 +0000 Received: by outflank-mailman (input) for mailman id 1461629; Mon, 26 Oct 2026 16:59:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLO2b-0006hH-Mg for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 16:59:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLO2a-005AQQ-IO for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:59:20 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf86d5-e002-0a2a0a5209dd-0a2a4505a7a4-40 for ; Mon, 26 Oct 2026 17:59:15 +0100 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf86e3-4cb1-0a2a45050019-d155dd33f1ce-3 for ; Mon, 26 Oct 2026 17:59:15 +0100 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48c4649b35bso3329665f8f.3 for ; Mon, 26 Oct 2026 09:59: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-48e3ebc39b3sm18064083f8f.10.2026.10.26.09.59.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 09:59: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=1793033955; x=1793638755; 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=GMQ+7WlzWIwRlrJ4BmOSjoJg3SFkTQUxLpOzCWcGRxo=; b=c2ln4F2J6YpDBdoOcgcX4Y5wgD9qzdQKdUTbVz1MMBnMfaBjdeGo7js05QXakmhRAn YXffTbed5VhC3mTpcw7/AV1qXkl7Y8jJPZQ86St4CJtLsytNQG/BcslmUaB/BX7kxbF3 JqB/lbbzDGflm/5PMrRnDw5InRiZ3sn6oWc7M4dWrts+xmkuzbWniaq9eqd7MzF862er ER4ouamqXB5hgE+ANxx0OSVvQ1kTevpdlYyhmYzAMUzaLJO+w3K4IMEPBMTzUT791145 svPi5qDvfKPEQVViSFLUqRAiA3pa12uq2tZUyuDKbDstJKhGGJQKmaxemEsZjXzEt3Kx 8shA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793033955; x=1793638755; 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=GMQ+7WlzWIwRlrJ4BmOSjoJg3SFkTQUxLpOzCWcGRxo=; b=zRUtocncY+9NF/dWYFIcAsiPuz0Pm0RcUQ5quaJKkLgYJOW9WPv3RqsHKpd0eW6i5L lebldazJ9Oly7Rm/C/kO41YPgeNUm2P98FnTEdWua3zfYlHG/S7QnLqAnGMdNS0XneCo YOUhZ7v/oz0mYorszdTiDj2H5iUykynPS5iatvCsUHNHLtXaBBisPbF31HqLsxNwkEdO V81UUWq/Bbzg53puWhL6X/tfFX6a3IisbQhzbZUn58ykeSYHptPoZpl6YMbs/Avmnh+f TwWDF93g92CtxiDgnZb7Beu6Q2gs2HnauS3eGpvLywePJb0h8TH6e/3VIGRWSW9LgAc5 FiNw== X-Forwarded-Encrypted: i=1; AKwUvBw7Ug0eaEPa3TgYF95JBbQEDLZ2k29lf265tmkem0vA844PcWoOxvNoAYiWj3cdEGoyhwH7Q9aTpF0=@lists.xenproject.org X-Gm-Message-State: AFq9FYKnmet3O7VTx0tYTNj8oRXGlrexekXnfQpIP7Na06/5+LCr8b9E nz5322usvmpLycgH5B00SWwimWyLjBcH8LVGzKShPy1Tv84XznWMcfggZ8KSZKMVHQ== X-Gm-Gg: AYBFou3I9EDJoU3NTwP4ynx3ExTiGI6F3/uG13KmCKqGf5b51CU7jyJlN0dSBuqdnLd Yqkwi80vMZqpTEacT5jYDG9eiRCr1ErE5lL8Ep7D7Pl0wcpAUaluEpka6teGaP+XAenkNqTPqoh Ryc6TfuDtAfB59Y2NrTvs6XMbSl8hHX8fE6FACi7jooe+zW2V26/iaBB3ASl8mpvIq/PHXDkOzL t+sR707GyEo0BpO51MGARJx0DMQbx8I6huM92lIiQ7khOFB3Y5Zid7vc/e1WA7PBY/64nsxxs9P 4BmhUCXN/t7YerSg85hhM6qJdHxRLm4pAaxf+fmZtEzOAclIxib79u0rTdVxvk8wjqDlD7Oftf5 cs1khLHnoxIZ+waJa/oyLJs9+KBMw93mHEd4svWpBprluaz8w/JvNHsXEOW9yt1cCyiodog5MDO tB44PFAZ86ApMdJVQhR2Ukdo2DIMTx9TTtlK3GZHHJ1jNC2c7c/aMHCsIxvmXEUpbRfVSKl8voE 1yHqd2u4+Yhq4f8nuykwvhD98+QMFaTxYNWQz6FSCPBIMqoKnKzn6oem99zq3eLenOnQdXgq7WS B9FFNRHA+Fydqn3WJBjzQbz/A2jtHSjQsgwR1Ftox4o= X-Received: by 2002:adf:e193:0:b0:48e:3ebc:d242 with SMTP id ffacd0b85a97d-48e3ebcd6c3mr13437490f8f.37.1793033954814; Mon, 26 Oct 2026 09:59:14 -0700 (PDT) Message-ID: <462a149d-9a4a-49c7-8db4-96e99463a47b@suse.com> Date: Mon, 26 Oct 2026 17:59:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Baptiste Le Duc , Oleksii Kurochko Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> <9986e03e-bf09-46b6-9d2a-82a1864a59b5@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: <9986e03e-bf09-46b6-9d2a-82a1864a59b5@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793033955-71CA82A1-83F4F3D1/10/78276251493 X-purgate-type: spam X-purgate-size: 1109 On 26.10.2026 16:35, Oleksii Kurochko wrote: > On 10/26/26 4:14 PM, Baptiste Le Duc wrote: >> +/* >> + * Probe whether hardware updates the PTE A/D bits by writing to a local >> + * variable through an alias mapping whose A and D bits are clear. >> + * >> + * Check the D bit rather than the A bit, as the A bit may be set >> + * speculatively while the D bit can't. Following Andrew's clarification, I don't think this is relevant anymore (but I also don't mind it to stay the way it is): If we observed the A bit set (and no fault), we can still deduce Svadu, no matter whether the update was due to an architectural or a speculative access. Svade would implicitly disallow speculative updates of A, as exceptions may only be raised for architectural accesses (unless there are provisions in the spec that I'm unaware of). Both of you: Please clarify whether you want this change to go in as-is, or whether this wants updating again. > Generally, looks good to me: > > Reviewed-by: Oleksii Kurochko Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Oct 26 17:00:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 17:00:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461635.1672693 (Exim 4.92) (envelope-from ) id 1xLO3Z-0008EC-5U; Mon, 26 Oct 2026 17:00:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461635.1672693; Mon, 26 Oct 2026 17:00: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 1xLO3Z-0008E5-2E; Mon, 26 Oct 2026 17:00:21 +0000 Received: by outflank-mailman (input) for mailman id 1461635; Mon, 26 Oct 2026 17:00:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLO3X-0008Dv-Jx for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 17:00:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLO3W-00HVgU-Pv for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 18:00:18 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adf8721-e002-0a2a0a5209dd-0a2a4508cf70-8 for ; Mon, 26 Oct 2026 18:00:18 +0100 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adf8721-f659-0a2a45080019-d155dd29b97c-3 for ; Mon, 26 Oct 2026 18:00:17 +0100 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48e0d885929so2144085f8f.3 for ; Mon, 26 Oct 2026 10:00: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-48e3ebcb9cesm18300319f8f.27.2026.10.26.10.00.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2026 10:00: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=1793034017; x=1793638817; 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=EU9qzBj3Qx+LtSG4rL+zWiwoGCFOX1fxvjpbTQiQ6VQ=; b=FUy7rUMdMgiRbdBbgd+dItPhoMJbFP10mzFqhnJEE6v9Kq8DhWD1gOooImQpaJ1PUF cuqBWJoN7ut9rj7mYxuNgY2FZWGWxI9fGP0n+8LW7nZF0ODiZNkIiGkmiflOmKyU3AKb fy58XgZX/l/4U8oKdcMioLXqP5e0PQwDzUGruA7UqbV1rEUGSv7i4IRnj0JRfyrJw4m+ Wk3PKVHL1wApdx/2h08tRa6DcNFPPSXiKSSXhThZegmo62PsIE2ZEEdzSCszTyIhCnW6 3kEf2J8OueMa1brqxbITsgHRpdK2ikY2DpEMbCXS1mlanQlURnJh+qFLlKTzjcJ1zyRL KLlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793034017; x=1793638817; 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=EU9qzBj3Qx+LtSG4rL+zWiwoGCFOX1fxvjpbTQiQ6VQ=; b=G05ddPnfAGDgekgIai91frZXisJbgNTx2ld1mS73b0/nt2SSLSw0jhlRNJDgln19x1 NKPnaSm9w2b0aa0uyhiATyl5jKq6WOt9kfF17mN/CXwSKctQ9KXyMoKrLMFCTYPbmaUx tZRMw5SkHiFRGAmW5l4JaPs7h2ooktXNOG0iqzYCWJ17j8GIZ5nNEPZ2w8BbUI8se6Ug uqSun3y2o7ph3q+OsufBQMX0srBeyYOWH3wyVgMluY5quvtAChn+hztxF5EzsDuHTAQC f+78zAAXpUiJVaeZ/Y8O/RqGh51cGP40Pv1xQx50e7m/FcpB+/BTMPMrPHui4/TyVoYO fqTQ== X-Forwarded-Encrypted: i=1; AKwUvByRjIREjLEexJVkWHBcCF4+aa03CexfOWJc80amq6RlpoospZncsr6GA18RN5XaOXXbS7V6h0WIYWc=@lists.xenproject.org X-Gm-Message-State: AFq9FYKEwpbPqIbSPC7YFk+5yg4asqcTecqKAX3NAfvl3a+GKeWS/RNc qkYUS+oKsH9u98rsWDQupkXqJL4CQjIr91i+XAdi9QEsZxRD4vXp+94CbWUoLDhrpA== X-Gm-Gg: AYBFou3HvmCubCjK7wfaEGGOoz60thAYF/NDHxSOeAj0dmfu5xmMgx5VMQinXtvCXIp 8NZmyQcAxyZvRIoHhdJTm087fBj0bNUDFnXjndD11PUKHGk7xSavQGLMYNdQT5Lp2Ow1tcEO5BN JcbNwr/eIppS1qARpki1MuUxpPyj5gexavymiPqH97dAs1HqkpiK2VmkyGDkd/VovnfckvOclj6 QYNlWLoESQCKaV6xZ+GDTBnFusVx3yO0jnk2ac0TsAeKIIkYjPaYaBZMMQsAUi8TZSPkhuEZhWM 3iY2FAzCUNKflUsN35ckjy8KA2PFZERGXHxLxOdyRiWYXz6y5DWYDdGuG+RZsrlrWNRQ32h2szJ o/VylMt1/QvV5P7xIHpNYpjmG3TZz9izAFcPsERljX0/clnuLn1DKzPQu8XbXfnqW3+Ne/Z3STo 1dGB6ihd8gcFz79dcC+kXTPzldrxI8qHOyEj8fBOazDXqAwV1TfqTNRcp2jjGpdIj1PI7NX79EO SgGmRGyy6wVt/g0PSVsmHZWDRtB56C6WLhExCw9BRgB45eh4IZFe8IAGDlsogSyO1tUUkX/gOlG AlV9op8Lsl/IJQNv/NoBi+ZE37Redp2hoD3Z55wbEfrm X-Received: by 2002:a05:6000:27c9:10b0:48e:d88:55e5 with SMTP id ffacd0b85a97d-48e3eb457f9mr10319124f8f.6.1793034017023; Mon, 26 Oct 2026 10:00:17 -0700 (PDT) Message-ID: Date: Mon, 26 Oct 2026 18:00:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 5/5] xen/riscv: rework the A/D bits comment in p2m_set_pte_flags() To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , xen-devel@lists.xenproject.org References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73b94000f79f@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: <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73b94000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793034017-CCB7187B-8D8C9AC8/10/78276251493 X-purgate-type: spam X-purgate-size: 1084 On 26.10.2026 16:14, Baptiste Le Duc wrote: > The comment in p2m_set_pte_flags() quotes the spec at length to describe > the two A/D bits schemes, and its TODO mixes two things: why A/D are preset > today (OpenSBI delegates the resulting page faults to a lower privilege > mode, so Xen would take them with no handler) and what remains to be done. > > Summarize the two schemes as a short list. The reason for presetting A/D is > not future work, so move it out of the TODO, next to the schemes. The TODO > now keeps only the later work, handling these page faults instead of > presetting A/D, which only concerns Svade as A/D page faults cannot happen > otherwise. > > Also note that presetting the A/D bits is harmless when the device > tree advertises both Svade and Svadu and the platform uses hardware > A/D updating. > > No functional change. > > Assisted-by: Claude:claude-opus-5-5 > Signed-off-by: Baptiste Le Duc > Reviewed-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Oct 26 20:44:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 20:44:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461675.1672743 (Exim 4.92) (envelope-from ) id 1xLRXy-0006Zb-Jn; Mon, 26 Oct 2026 20:43:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461675.1672743; Mon, 26 Oct 2026 20:43: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 1xLRXy-0006ZJ-F9; Mon, 26 Oct 2026 20:43:58 +0000 Received: by outflank-mailman (input) for mailman id 1461675; Mon, 26 Oct 2026 20:43:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLRXx-0006ZD-2V for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 20:43:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLRXw-00F9aL-8a for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 21:43:56 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adfbb6c-2eae-0a2a0a5409dd-0a2a450c96c8-34 for ; Mon, 26 Oct 2026 21:43:56 +0100 Received: from [209.85.208.44] (helo=mail-ed1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adfbb8c-f479-0a2a450c0019-d155d02ce1fb-3 for ; Mon, 26 Oct 2026 21:43:56 +0100 Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6afbc363efeso5094016a12.3 for ; Mon, 26 Oct 2026 13:43: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:To:Subject:Message-ID:Date:From:Reply-To:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1793047436; cv=none; d=google.com; s=arc-20260327; b=gtiZjH3lO4axl3rVLdo6Uuar9qjYl7iwjM++pJj1aXiLo6XjfU15C8mOX6YKHbpQMJ Jtrf8CxibAyX8UKXqW5hel9VAahp4127151zZy52q7AEgkbgI58mDK3qdcv6f5e4cwGw fhDpI4f9e4bEGXOV9u/ESkbIaIWoPD3jwhmHM9Prdv668y2akrZABRL8pTW4DICWZ5Z6 ZX7Zs5f1owU6WmwJaFMFiuI+DvOjWkDVCsljbAz66iWuNd4kzZmOfXb5JJqY8PrYFDPy 8gqQV3NJxTxnGKENyZ6u4OhluIehWCn16hXvxk3qdxniMXp4dY0ak9sRvdkcEwEnsIlR YtDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:to:subject:message-id:date:from:reply-to :in-reply-to:references:mime-version:dkim-signature; bh=xTu6Sr8zNPkiNfTD8K1PlSAdCzZhpYHoWI/G69n+X68=; fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=; b=K3eCEDCi1jjJo4Rwn4B/kTblVcBW0nHbX3UkWODfy9p/C/YttlJFhqQtZFJ9KUIkpX cHVlVnFGhad+SjuihclKHOoJh4B1bngksJkyeXHDhTOenNYuIZOwwSAuj0jvMlU56r2/ NXcyUd6YH8UwCd7oozDT+bsUEnEIpKXF8FyUQWAeE4hJGF3fBaDWy4Unj3PvNL04o9n+ BtWcZO4q3tyZLG7wuh9RoJW1wzcKlCI2J+ZyWmmp5R0uhKmxwWEoozavUPK4efukmacO Ok7Eh3EWKb5U74kG8GrTr6RK2Bjj4yrj0MpwhO9v3rlrtpukKagBedzvsaIYBc8j38hr F99g==; 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=1793047436; x=1793652236; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:to:subject:message-id:date :from:reply-to:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=xTu6Sr8zNPkiNfTD8K1PlSAdCzZhpYHoWI/G69n+X68=; b=lmBLWaKgADlDGtBq+xz62ePvTuFT98jOwo/vh+vRxiVUS78+NmUb2Nnj7dvB2jGGm5 3kjLWjpHU9ijOFISDa84g8aZNy/iyQeuiSgdz7rdU+OZ5vrDsPuVVISD2iXznHJh5yy8 ELY7w55bp8wK/+993OTA+/JMjxSo7HAjh/svNWVMCAN0hh19ZWvID6Sg1Yl57TZu3CTi A3B4t/zGX8SHu3UhRWH1MrrYGwC7JPnp8RMsKImg2boP02BglNmcKON6Dc7pEPH/aeCW 9xyc6RZ4gxsGaHD68gIQIIN5SPaOzPDm6/J+tUXqJsTn+46jHMQRB/oCUxUjjaS9Rmtw OnqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793047436; x=1793652236; h=content-transfer-encoding:content-type:to:subject:message-id:date :from:reply-to: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=xTu6Sr8zNPkiNfTD8K1PlSAdCzZhpYHoWI/G69n+X68=; b=ZOhm0wHv6iMlFVrBIXKh2NHQ9v7gKKko3aaq0EOQ7vYQ2eWdDgQ5RWAgpKdmUAgAMv YqDH4Ix/GChhOYk/Y8kZJFhMsACKbRNTF3O/uICWjLyoLUmwU9vcUKsJa5QIK+Es0uGF bAT5sqIZX+m7EqW7Q5JDa34a0FFTBt0/f0ks8cuFE3MLicVXIaZlEw+IpXl2z/QhmoI1 6erUkF1OlutDaNy/50CKc4VC0XUimUuTQJ9/a5aZ6uRUbp543ipcsiJnGGU5M9zTusLr MMJAnOSzRhXGVHw0zR2bNbQFp03funyVAHJnQ4T2yL5Q0+K1kqpgfUgttZlXdC/tuRiP /Faw== X-Gm-Message-State: AFq9FYIa8icayFfqCNhsl9oHAD8GX9nf9koaPAlkUtmhRyb61qpzzuI0 4i52KIKzcnXgx8r1kXMSBBcJjZKe7312ni+y1i3xAo7sGJDilDNB3UFGmXdCnVouiFjUMr+DLA3 59Avd81HQUMhYQdEEEOzVzjwsDXQdwz41uLzRRsY= X-Gm-Gg: AYBFou1egOQgW5287fOPo61k2pp1qj+dbww/cxx8feQOdbvK+If1WCYBnKgM4pXTXcP 8PpYU2aFdYZ9rWtdpo9DaQdCt35V1TDnp777CzW2pvEur/v9oT5lQ+dxPIaXTDqkB43L1DnuGHT LSurNi3qRHtH3PuDKGXz51mQREFxUqVc8kAsjKOzunG5usShRA4YYJXL1blYt/IJkISTHJoPmba hSAnoIr4S7dVF3tuXKcqY4nuOPWdLypYIDSzcmsYOnn0qbu3dNxmOHOQ2uhZIJTdX4DgQ4oMGnu tUK4Zbz/ONond8LAoHItz3MdbzW+vnWqkMXytLfyjABwmw93brmun1TYxsAkMXOcsmyc5bRAHbX 6rXIjm12pq6KXMNpOJKPlUTD9yUExz3tIx4VMJ7jjYeMhsAkRsGSbqFHfKvfReJX2yRWXt4O1ci G/dt0yDlH538OMPhjxs4IwSAYHWxXBcMZvLlwFEicfOKSlNiUVkCSb8g== X-Received: by 2002:a05:6402:c4de:20b0:6aa:f0e:a15f with SMTP id 4fb4d7f45d1cf-6b442fff666mr6024755a12.38.1793047435692; Mon, 26 Oct 2026 13:43:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: ludloff@gmail.com From: Christian Ludloff Date: Mon, 26 Oct 2026 21:43:44 +0100 X-Gm-Features: AclHuK_j_9pfylA1mjSSzjo0x_fKp2ZJtJP4sHTIuJg5kkb2cpY2yEe0AgJN88I Message-ID: Subject: Re: [PATCH] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1793047436-00ECAA5B-25DC1A56/0/0 X-purgate-type: clean X-purgate-size: 874 On Tue, Oct 20, 2026 at 1:40=E2=80=AFAM Christian Ludloff wrote: > > > It looks like it's a behavioural difference between Core and Atom. > > Core modify ICR, while Atom do not. > > For Core there might be more nuance yet. > > I seem to have an ICL result for "does not". > > And I seem to have two SKL machs (same > stepping, same ucode) that... disagree with > each other. Some sort of config thing...? > > Maybe Intel can explain. > > I consider "does not" the cleaner behavior, > unless a compelling explanation is offered. Andy =E2=80=93 as discussed off list, both were cases of a sneaky HV put in place by the mach FW. So for the thread subject we got closure. Sorry it took a little longer to track down =E2=80=93 in the process the authors of the FW stack did receive a belated dose of Spectre fallout. -- C. From xen-devel-bounces@lists.xenproject.org Mon Oct 26 22:10:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 22:10:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461703.1672751 (Exim 4.92) (envelope-from ) id 1xLStY-00045Q-IV; Mon, 26 Oct 2026 22:10:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461703.1672751; Mon, 26 Oct 2026 22: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 1xLStY-00045J-Fb; Mon, 26 Oct 2026 22:10:20 +0000 Received: by outflank-mailman (input) for mailman id 1461703; Mon, 26 Oct 2026 22:10:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLStW-00045C-Ne for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 22:10:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLStV-006yIc-MU for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 23:10:17 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adfcfa5-bab6-0a2a0a5309dd-0a2a45099286-34 for ; Mon, 26 Oct 2026 23:10:17 +0100 Received: from [40.93.196.47] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adfcfc7-be1a-0a2a45090019-285dc42f70a3-3 for ; Mon, 26 Oct 2026 23:10:16 +0100 Received: from CY5PR22CA0047.namprd22.prod.outlook.com (2603:10b6:930:1d::34) by SA3PR12MB7782.namprd12.prod.outlook.com (2603:10b6:806:31c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 22:10:12 +0000 Received: from SN1PEPF000397B1.namprd05.prod.outlook.com (2603:10b6:930:1d:cafe::9b) by CY5PR22CA0047.outlook.office365.com (2603:10b6:930:1d::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Mon, 26 Oct 2026 22:10:12 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF000397B1.mail.protection.outlook.com (10.167.248.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Mon, 26 Oct 2026 22:10:11 +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.53; Mon, 26 Oct 2026 17:10:10 -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.53; Mon, 26 Oct 2026 17:10:10 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 26 Oct 2026 17: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=IxCP5WFZ/AFiy3AI6JhA6N0d+qRdDWER01kw176POt+AFUQHneBfIDIdOgAAWrFLX1NWsqned+Q+d7e1ioiR6M9we/81jQjMtq3cCe97DDeDrjVA72cqJQ45VdYcN0bYCo9XWMg8F6TLF+Z7PYvaOTjqjExbvg7FMFV57fEBRck1bozuTFOfJofGUuh9iVVht5G2KhA9rfadzSDpNhZ7xeYkueCiws0XQguMhyPSMsAwhNPV9rjr8sse+auE3yqUIkcVjpqQvIkSTuZJrj4uQCeT5XZy9pREqIIBRTW37Cm07u1WsbxoQC4nUtbodyPVsZUKyjwO5sryygPKWMtgUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OgRuL5osHe+qZq2ftiIHHB4CIWGBlYNFTN/IHvgSaa0=; b=pThDfYlnLWWYEyq9Wb8DHk2tGbwY6o4ydCKWo8+QAiOl/ConJPbZspbjpegmNHoqsakKMjT+Pwie8/QoBS/+0r525tZjGlVC2kqGmT3FasnmH++Gbn6ttJDA+g0VsKiqRkOf8GFM34qVuQnjrcJfYZGdE2t6LYVkO7aGzDmQolN0oyXROt9wvlCXDI16NnH/QbUP3RjQZS1k5eZbz+ZWKP+j3NaCx5Jvr3o1ARwJlSYS0fPdQ5p0CNl9mFMq9c+ACSzihWR5yvarLfAJv0jpYwd5MONc3DI6RIi+STFRxvK9ZoPJmysa562HA/zUNEMGW5TklgCOisMosUrwSWWgSA== 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=OgRuL5osHe+qZq2ftiIHHB4CIWGBlYNFTN/IHvgSaa0=; b=KKoHmQmlMaxHueRFSkGwfZXZmU5EKEqpxXgL95fgKy5U8BpO8fHXcJi+TI1IiAHVdyi3fDqjK5JvgPVy2yFo1UFe1aWsAnXdQA2/IobnXYfoMl7U2ptAQcnUGs5ozz8lzogUbKsV0H4av1AqxOPxmz0E90pLBWxXOEu/cSYvfng= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , , , , , Subject: [PATCH v2] x86/bzimage: Check that the payload lies within the image Date: Mon, 26 Oct 2026 15:10:08 -0700 Message-ID: <20261026221008.1143527-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020214825.3655848-1-stefano.stabellini@amd.com> References: <20261020214825.3655848-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF000397B1:EE_|SA3PR12MB7782:EE_ X-MS-Office365-Filtering-Correlation-Id: bb0fbb6d-9809-4d14-510a-08df33ade757 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|23010399003|376014|82310400026|261026140227099003|11063799006|56012099006|261022075727099003|261021121427099003|261022115727099003|261022105027099003|10067099003|261021123027099003|22082099003|18002099003|261026121527099003|3023799007; X-Microsoft-Antispam-Message-Info: 0j4bo7iSdOYuxlvK8sHcJex/012Ra5qTtlMDN61sPRikgu1mraBAkLxh9X+c4DlsZlCRD/gTNMLdmqX1pvmHW5DQJSKVVkWCZU0AnQnkoPsmX0h7y0p5U3M0UElyRgqosJ9TgDdL0D9/ozdhyb76Hhwnq+zPDA4YxECLKjMjGuORaaAM8/CHRtERNHpwK43AdRobL+z6cHyYxtcUtmin7ro4OEj4zK0l/HTn72cyvYSPKMsd6/ReKq8Fdy/R6xCG06wLMNg3wssU1hheXfst2dkYWrsEpbR8+3urAEeeD0bUxPoXqAIcNIwnSLRriq/vRnkF9FwyAGkqe0ascOjsWPewzy1yjN6DmgS4PR5BbrjCEsoLtaF4D913LVzyxVznFjCjxXg0841NS59PDsEJ8qeU14xfULfYxXZlMTjFVGR/ulRNu4O0vnax2EE0uRXNaAoeoc3IvDfkJzr50SjSNFkul1J07aRnkEw0Uvm4sPOnyYmpym1QTrVFJVcu2O0PAf8I5wtzlWYiBGl7IT57q9xHWw+ByKuhuasfK3wvw6Aorj0QU57coNjsjcr+ZbhhUwLM69rigxuYYzR0hgoC2fhlKESW45xpJ8JFcMJYpfMPBCM8aEwUpt1ee9RR7sJvpiaM2rQhqX/B5xgzGBmCz8sXitv3i2gEEMnHgloT9a8BYm23wU6jwYU63rsrAlgfJZjmLP+EFVd7GEvTCrFNlg== 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)(376014)(82310400026)(261026140227099003)(11063799006)(56012099006)(261022075727099003)(261021121427099003)(261022115727099003)(261022105027099003)(10067099003)(261021123027099003)(22082099003)(18002099003)(261026121527099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ZPQ6CaQ63kZWNgvgiPA75mSLB1Mcj3SyGCFXmqtLjSXI0nar6+icD1Dm+FvamIbQTp0GI61gBRTY1MgeI49HD6mYAtN6Tjqiho7+RmJiEUas6ZYwgCsdiITPSGGOeJ95eEe4Kv9nZLyD1ypYaAokfZtWz7xxmCAKv4Nr8MU/vtKuiQpXtNxwzjYU6OsF00//QBT3VpX4KI9FQA4XtOZvhJ/wORvfLuo0bHGqZGt7v8kI3k/2eAwAHj31qT7vf0/7Gfa+WhvxMfob7IYVyfeXzkLJYQtXY7mlFDQO9R131M1+QU5OjqEFkHWGGf+slwPin6x+Lvs46i/AWkZfqEPZO/JMuMI8V/vrojlPflKI9mq2JEH2aFUsGHsoI0QAtK02kcHF2ci5BBDiq61ttma3/Bf6GwvkMbe4psm3t1skfoe0rUCECCqq1L7eDRMVDYaP X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 22:10:11.3184 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bb0fbb6d-9809-4d14-510a-08df33ade757 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: SN1PEPF000397B1.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7782 X-purgate-ID: tlsNG-bad1c0/1793052617-BC2F4034-F956AC34/0/0 X-purgate-type: clean X-purgate-size: 2422 bzimage_check() doesn't validate setup_sects, payload_offset or payload_length against the image size. A truncated or malformed bzImage therefore makes bzimage_headroom() and bzimage_parse() read beyond the end of the boot module, which shows up as a fatal page fault, a bogus headroom, or a decompression failure, rather than as a bad image. Reject such a header up front. bzimage_parse() passes bzimage_check() a length which includes the decompression headroom in front of the image, so subtract it to check against the image alone. Signed-off-by: Stefano Stabellini --- Changes in v2: - drop the UL suffix: setup_sects is 8 bits wide, so the multiplication cannot overflow, and the offset is now computed the same way as where bzimage_headroom() and bzimage_parse() use it - reword the error message - drop the dereferences from the comment xen/arch/x86/bzimage.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c index 66f648f311..41f19221ac 100644 --- a/xen/arch/x86/bzimage.c +++ b/xen/arch/x86/bzimage.c @@ -54,6 +54,8 @@ struct __packed setup_header { static __init int bzimage_check(struct setup_header *hdr, unsigned long len) { + unsigned long payload_start; + if ( len < sizeof(struct setup_header) ) return 0; @@ -65,6 +67,15 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) hdr->version >> 8, hdr->version & 0xff); return -EINVAL; } + + payload_start = (hdr->setup_sects + 1) * 512 + hdr->payload_offset; + if ( payload_start > len || hdr->payload_length > len - payload_start ) + { + printk("bzImage payload %#x@%#lx past the image size (%#lx)\n", + hdr->payload_length, payload_start, len); + return -EINVAL; + } + return 1; } @@ -107,7 +118,8 @@ int __init bzimage_parse(void *image_base, void **image_start, unsigned long *image_len) { struct setup_header *hdr = (struct setup_header *)(*image_start); - int err = bzimage_check(hdr, *image_len); + /* image_len also counts the headroom ahead of image_start. */ + int err = bzimage_check(hdr, *image_len - (*image_start - image_base)); unsigned long output_len; if ( err < 0 ) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 23:40:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 23:40:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461731.1672760 (Exim 4.92) (envelope-from ) id 1xLUIS-00007h-PL; Mon, 26 Oct 2026 23:40:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461731.1672760; Mon, 26 Oct 2026 23:40: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 1xLUIS-00007a-Le; Mon, 26 Oct 2026 23:40:08 +0000 Received: by outflank-mailman (input) for mailman id 1461731; Mon, 26 Oct 2026 23:40:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLUIR-0008Su-3K for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 23:40:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLUIQ-00EeOt-91 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 00:40:06 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adfe4d1-e002-0a2a0a5209dd-0a2a45068ecc-12 for ; Tue, 27 Oct 2026 00:40:05 +0100 Received: from [40.107.209.61] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adfe4d3-195a-0a2a45060019-286bd13d1fa2-4 for ; Tue, 27 Oct 2026 00:40:05 +0100 Received: from SJ0PR05CA0128.namprd05.prod.outlook.com (2603:10b6:a03:33d::13) by IA4PR12MB9762.namprd12.prod.outlook.com (2603:10b6:208:5d3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 23:40:01 +0000 Received: from CO1PEPF00018866.namprd03.prod.outlook.com (2603:10b6:a03:33d:cafe::99) by SJ0PR05CA0128.outlook.office365.com (2603:10b6:a03:33d::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.7 via Frontend Transport; Mon, 26 Oct 2026 23:40:01 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CO1PEPF00018866.mail.protection.outlook.com (10.167.249.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Mon, 26 Oct 2026 23:40:00 +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.53; Mon, 26 Oct 2026 18:39:59 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 26 Oct 2026 18:39: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=L2jNLnWBXlUH4tfKsHhu7NA8BxxgBPZ6jLYXMgU1BQoArO6GzvsQ2Sb8sacP1sClb8pubJkwYh//mZNWlH4EImcbQcn0FqF0Jv+YqZo9FS3/WEkIrCCd/oUVkIZe4gmMpY51LtQlRyMqHKTglY/fS3sHVQZzoFHkWR4y4YpOHSzppnySjNA8Vk/L5qFfJ5wh8n4Vz2dH4Cu+WtGqRy5me8qx7puwDsvY6R1pvQxEH8zyOOIZ/c0aQW+6V0XRcgj8mkV8/u7tqC139a+rUld/dmhVz3V2EtmqJY+IyAOPQ1+a3E0N1b5A+UsBTrlNDo3yszaSGuNKeXUvUxbxBoDRuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ahjVg/6HXjNeC9J3Powm8bLZ+kSAojsaF2JTC35Yw3o=; b=erVn3ZqjSODOGnyom7m6vQpMBf4ArGInUEFWZ5NM3xoL91e7z6FYhg9U10pIZqIVVHm51ArTpFXMuERjyamtir2NBaKo6h7y9fpq1rWfIsChJeelo/kPxje17rCX6fLOY7QTRCmDVeSY+dzRayxT2zYftH2KSq2xD6CE74jMMJ3osyALGZtXPk7ed+NWzBe+kqjxAw99CBETH8JvpfsJgilL+iN08f5DbFX14zE68X41cRv3LC5VArhSM2ZDqieskLe9Pk4hZ8VqDVPQoYOdeNd4tHBwRp2cq9E1/yOXbsuR4YXjl9K5clR9TQNYcOPlHeGu5D/OsZf+7rwYrC9O4w== 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=ahjVg/6HXjNeC9J3Powm8bLZ+kSAojsaF2JTC35Yw3o=; b=dxSbexO7VrJcjkqyLxMA20v5QK+mIaHQR8yzlRlyY/KecSdVElzS5u1aiRi3StRTsBnwwL+GiU3DrSdpzuTzzJ+7DjrPbfoKZlFiYF60rvsshOpANRimNcwRbxL1Juao3zhakQ2jhCyjqsQQZoa8nGt0BXpO0Mti1utfpispDo8= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , , , , Subject: [PATCH v2] xen/sched: Fix the sorted insertion in sched_domain_insert_unit() Date: Mon, 26 Oct 2026 16:39:36 -0700 Message-ID: <20261026233936.1330117-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020223534.3703199-1-stefano.stabellini@amd.com> References: <20261020223534.3703199-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF00018866:EE_|IA4PR12MB9762:EE_ X-MS-Office365-Filtering-Correlation-Id: 215c1f2c-5a17-427f-aee4-08df33ba7397 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|23010399003|36860700016|261026140227099003|11063799006|56012099006|261021121427099003|261022105027099003|261021123027099003|10067099003|261009223027099003|22082099003|261026121527099003|18002099003; X-Microsoft-Antispam-Message-Info: Q3LMM7i1m9jc/ZjsaTt7wsNPIrbrRWvT+03OMP9iwsRfEwXu2E2zj5eC/OGzJhhRZHg/TgAIYDKppOUA4KaYePjSFkBe8HJmA/EVm7MJlvr0Qfnk8xikHqkX2RjegYK5jRUE+36C6t4fxfNDfodPzvmJtWIADlscoUDHie21CIJ2OuHIB6D6m3TA5PNx8ITCjxVOdZt+ynSxmRQkKqsYG3v9LUlFbWG4+lF3C8DR+lWDwrI4+kCRfGped+xpD0kG8XfE3QSVCb0c0yZq7vpQoNLr7YeKQYc/+Grt2x8GD+FoGin278lTteUtT8jdI241WU9i3qG27KoOA0lLxDS/SmLaFvPkg4Bv3wRKbZAu+KVn4e8QjsQDgf05GWbfdejKeRRlLaAlR3dBtqbaAf1wt9h9QOdDjVjLr8n+CmvfaZRldDpGtZTzsAorpPwxJOdPNTmItzaSrV9K5CI/U3GQgSdcYlO5InCIZaKWM2HwbWxEAQbrsEH1ZYzDBs1lCrm4yzE510mN0Kn5xq4S9pTTYGsYPRpaZIiEyEkcMD/eun8ytzMdvAZLATWc/F5FYoWe4aMQUaxu5yf/uRn+jOeycJiGlMGHrzSXYZ5QmaFuLef95i6xOGQCLit7hIfe3eSDIiDVGk2dKsaxnCHmAEf3buaWfYESI77v4SABn3SICzfpMbzo9S8LpZ3xrWMul51kPLb/UByNWzd2fDKSp6I9wA== 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)(1800799024)(376014)(23010399003)(36860700016)(261026140227099003)(11063799006)(56012099006)(261021121427099003)(261022105027099003)(261021123027099003)(10067099003)(261009223027099003)(22082099003)(261026121527099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ttE9pvfBDh+r8NdnXNza6ccRtzuLdLWq6BNuWnKCi3WEskozMn8pzqU7/ks+QYkAV1NDqhjg1vczhJbnGIOjaDLM2cH7FnC58SRVGaCdfssZQgUqcVwqrorerDWwaXtsquzoxxuHVVNI1+/+tp3B7xH04WE3zc5fAHVp+MiD/Fwg/QGz+QyYHwjB7bHAZj5WtdDJE+gxE42lFlMHm41l4nQMIKEel9KMIs7ry4X+XdkKUXGkV632rU90l4GM464uiJb2ffXlHO22+RifpLXqdTKbxozthzaDB3bHC/jPJZrKp7N+hBuJiK5WazAV54HLq8xI0HSjEKetsy/Kl7IxWEIAA1TmUNfpiZR1lI/o6ITGFFTJ8Set7obQHyG6hf/fDOplVK4PENAIMjAYXgeJJi0Wzs9fxke/rxR1O9UrFmrtbzdxKzzUrT3lJC1vvMa6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 23:40:00.4799 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 215c1f2c-5a17-427f-aee4-08df33ba7397 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: CO1PEPF00018866.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR12MB9762 X-purgate-ID: tlsNG-16d1c6/1793058005-FC20077B-C68682F4/0/0 X-purgate-type: clean X-purgate-size: 1836 The loop links the new unit in front of the unit whose successor has a higher unit_id, rather than after it: inserting 1 into {0, 2} gives {1, 0, 2}. Stop at the first unit with a higher unit_id instead. This goes unnoticed as long as units are inserted in unit_id order, as guest vCPUs typically are. Also rename prev_unit to next_unit: the new unit is linked in front of *next_unit, not after it. Fixes: 141db7fd4d2d ("xen/sched: build a linked list of struct sched_unit") Signed-off-by: Stefano Stabellini --- Changes in v2: - rename prev_unit to next_unit - add a Fixes tag - reword the second paragraph of the commit message xen/common/sched/core.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c index 0b072bdee6..88ae40f954 100644 --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -483,18 +483,17 @@ static struct sched_unit *sched_alloc_unit_mem(void) static void sched_domain_insert_unit(struct sched_unit *unit, struct domain *d) { - struct sched_unit **prev_unit; + struct sched_unit **next_unit; unit->domain = d; - for ( prev_unit = &d->sched_unit_list; *prev_unit; - prev_unit = &(*prev_unit)->next_in_list ) - if ( (*prev_unit)->next_in_list && - (*prev_unit)->next_in_list->unit_id > unit->unit_id ) + for ( next_unit = &d->sched_unit_list; *next_unit; + next_unit = &(*next_unit)->next_in_list ) + if ( (*next_unit)->unit_id > unit->unit_id ) break; - unit->next_in_list = *prev_unit; - *prev_unit = unit; + unit->next_in_list = *next_unit; + *next_unit = unit; } static struct sched_unit *sched_alloc_unit(struct vcpu *v) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Oct 26 23:59:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Oct 2026 23:59:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461742.1672770 (Exim 4.92) (envelope-from ) id 1xLUbK-0002Kn-9o; Mon, 26 Oct 2026 23:59:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461742.1672770; Mon, 26 Oct 2026 23:59: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 1xLUbK-0002Kg-62; Mon, 26 Oct 2026 23:59:38 +0000 Received: by outflank-mailman (input) for mailman id 1461742; Mon, 26 Oct 2026 23:59:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLUbJ-0002Ka-Lk for xen-devel@lists.xenproject.org; Mon, 26 Oct 2026 23:59:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLUbI-001mTq-KW for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 00:59:36 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adfe968-e002-0a2a0a5209dd-0a2a45038f2e-0 for ; Tue, 27 Oct 2026 00:59:36 +0100 Received: from [40.107.209.42] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adfe966-fae8-0a2a45030019-286bd12a1e58-3 for ; Tue, 27 Oct 2026 00:59:35 +0100 Received: from BN9PR03CA0058.namprd03.prod.outlook.com (2603:10b6:408:fb::33) by CH1PR12MB9648.namprd12.prod.outlook.com (2603:10b6:610:2b0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Mon, 26 Oct 2026 23:59:31 +0000 Received: from BN1PEPF00018546.namprd05.prod.outlook.com (2603:10b6:408:fb:cafe::3c) by BN9PR03CA0058.outlook.office365.com (2603:10b6:408:fb::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Mon, 26 Oct 2026 23:59:31 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN1PEPF00018546.mail.protection.outlook.com (10.167.248.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Mon, 26 Oct 2026 23:59:30 +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.53; Mon, 26 Oct 2026 18:59:30 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 26 Oct 2026 18:59:29 -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=DPU7hfR9d0myahnPwxUYUCceN7j3pbzBi+Q/JI4G8h8Y9sOAEhgHz5peGKPm1deH8nBpKONZbwwwpo/6gC2o2MFUpQTDWgIRPvqNxgHd9n313L2if3etVjXdYk7DLkMwhkzzICtY4pey0ZKF4AB/Ez+NHe0dEfHFkQQTViagryPKQjnJIpHKIZPybadf6bUe4Cg9SfRRdLVDXEnOVCYVuqsluXbSmFfd3Fw3hXqNid+9uQH6KhjZpbQmASsL+q+kMeXNyzZsXhjyiQtmInT5GaC9XW1RPV4gGTfzqHFrf1TrRVMspl3g2bi+yta15Ha0X2/kIr1A4GVbJCMM8mCJ1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TWgMMYm6qraa7yW0VlmJDne9MS3CBCB+gTW/oD8hbgw=; b=LASdTsR/ERZal9GOdhfObaYIl0la3PujmrDM5Szoi6Ksh5k7NA7OciRGjZqJ19/FivcqqirvkLdHlomKHrft+o4SQxYJgAFlWrziTOXGz5LKQ4GMBlqq/8jT4LovN7C6droc35TecseC02cxfxQ88VRan4HF3ZaVARCBgMShHr2HLPehtrNJVdf4dgWOBPsPv4SGS8pzVSJwC1JxvIQBmIyHwh9o4W+nQRhJsQ4vj/GUQMwmzRSXjsngU8B0aydZZt35hh3sgVmEbtcb9a81UUyIIY54U9emZi+IVYG/CHDc6QawbY3Z376jE8ISzOqjH+7Y+cd/6YEeqAHX9HoO6g== 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=TWgMMYm6qraa7yW0VlmJDne9MS3CBCB+gTW/oD8hbgw=; b=jqWvVCOZsccj5jWiix4Cc74E501AEdPQ7mo1JilLKe2eugph2sBzA0uPqF0BmCn2T49k5Q7sXDfUIhOMpYr3k36B6K1YiNUc8BwPcNaTyKVD0pow4fjlAuCxtIBDSqX/ZG8Zc/KzEVt3Wj7dPJtRWV3cuQ4NCWu2GaU8R6lM4dM= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , , , , , Subject: [PATCH v2] xen/amd/iommu: record the IOMMU for alias DeviceIDs Date: Mon, 26 Oct 2026 16:59:26 -0700 Message-ID: <20261026235926.2105578-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261020221214.3683476-1-stefano.stabellini@amd.com> References: <20261020221214.3683476-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00018546:EE_|CH1PR12MB9648:EE_ X-MS-Office365-Filtering-Correlation-Id: d0f0e4ea-5063-4d6b-99ee-08df33bd2d16 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|82310400026|23010399003|1800799024|6133799003|18002099003|22082099003|261026140227099003|10067099003|11063799006|5023799004|56012099006|261009223027099003|261022075727099003|261022105027099003|261021121427099003|261026121527099003; X-Microsoft-Antispam-Message-Info: zrB6f7I9YuWLKXUL18K6a/PMc8mUNXfFsCXquwM/Tf9jYAcGJx0hOhc7Px+5HDT+bAIZdG5JcnJWxFRcipvDkodi7ynz2SSUu3ftUEVHudCvd6UMXqB79UeGQ0j9MCqXoesGK9mjEJ+XR8vLayGIkbQ0dpYOtpECxz8ZCy9weIr54M4jNVmqBMMHk+7zaFXqdejjeASnCEiQZKgTfptHwmmqvfO0TnMtAAQgIvdprJiUCpOxLZFLp2tQhHB2TCU4MfhIRjvhjQS9qjlDR3iDBjymf9BHKalVeCFo56GjRitaCPvBOEhwBhshEoHaWEo0vIvDI6QbS6ru8Tzj8ZZ6/Vj0svJXyw3TtO7QM7h14OaxA1ZBqHAuINAaq+4Zn/9Oav/hnyHL7fQdrk1uFO/S34SH/uHkhx01hOLqqIgNaDtfhivxUrB5SeqHyHWHd8D9OYVxGzPl4+lUnJFIQOolvL7UJvtbO5PPqfTyfphxC+cMOKQ5HO3bzWdqexX6poQNHbbJSUcQNCSHzG2j/3zngIoz3vHmzG+WG9adtsjN/CFYYMh8xSurJPHGSz+DuHhBzLBZsFxlU9SQhPfycWvHtzySrqJI/0dXKVxx0bnfpO424C9mallpYKlTy3rKA+uaF35uTP8RhUfw+tgRVTTRUaIkguyUQgNhUWo3+3Rqt2Bm45PBefEV37JyqsnOqPSXDZySmtgFbANQYzFYtzmbyg== 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)(23010399003)(1800799024)(6133799003)(18002099003)(22082099003)(261026140227099003)(10067099003)(11063799006)(5023799004)(56012099006)(261009223027099003)(261022075727099003)(261022105027099003)(261021121427099003)(261026121527099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: FvgV1rR9k8DWCqWHE0llZDTVIGyl+ADHIeXz6iALF/9XH9ayiGI5iaindmhI8Ub3+pKmPNMZgprZXSvkNjw4rK/OYnhSedVlLLEMHTpyBhC4y0HuKeZB0p/XkVHFjy44N7K8d5Oc6NRzS/UYk+Nw5GpMc+IyFNj/UsTIkMCKIvjNqgapWWAV8ftNuVUO/UDoR62sLXL1IaWX+ojStHs2EiZghadLn/qBRwDeh5NFWZWOYCH2HtQRMAlyFHDLgbYUCY4uGnJe5GyFHdjwtcF+J0U75XHoTo6tYfV1PJHeJ7lLYxP1+VuxYnxXf8YISeZat7SxXz8/gdzCytcJiNoWlTjglkH82o18LRepbR9gPoUdP5LwHVjjehvdswe9BJw9KGXx3tPvKYKXd9MSVDU9zMAlhh+7BFwvAFwynpZjs9dtrvPFjjWbmZEmfLkPHJKm X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2026 23:59:30.7811 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d0f0e4ea-5063-4d6b-99ee-08df33bd2d16 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: BN1PEPF00018546.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9648 X-purgate-ID: tlsNG-33051d/1793059176-74C884E9-0F62AE7B/0/0 X-purgate-type: clean X-purgate-size: 1834 add_ivrs_mapping_entry() marks an alias DeviceID valid and may give it an interrupt remapping table, but records the IOMMU only for the device using the alias. If no IVHD entry names the alias DeviceID itself, amd_iommu_setup_device_table() passes a NULL IOMMU to amd_iommu_set_intremap_table(), which dereferences it at boot. Record the IOMMU for the alias too, as was done before the interrupt remapping rework. Nothing relies on it being NULL: the alias is then handled like any other DeviceID. Its remapping table is freed on cleanup and dumped by the 'V' key, a device at the alias DeviceID can be added instead of failing with -ENODEV, and reserved ranges, already recorded for the alias as well, are reported once under it. A NULL check at the crash site instead would leave the alias device table entry without interrupt remapping. Fixes: a3713b97e8e1 ("AMD IOMMU: Rework of interrupt remapping") Signed-off-by: Stefano Stabellini --- Changes in v2: - describe the crash precisely, and why nothing relies on the alias entry's IOMMU being NULL - add a Fixes tag xen/drivers/passthrough/amd/iommu_acpi.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c index d118b36d80..d8ff4d24da 100644 --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -104,6 +104,10 @@ static void __init add_ivrs_mapping_entry( /* Assign IOMMU hardware. */ ivrs_mappings[bdf].iommu = iommu; + + /* Requests using the alias go through the same IOMMU. */ + if ( !ivrs_mappings[alias_id].iommu ) + ivrs_mappings[alias_id].iommu = iommu; } static struct amd_iommu * __init find_iommu_from_bdf_cap( -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 00:13:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 00:13:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461752.1672778 (Exim 4.92) (envelope-from ) id 1xLUoi-0005nj-Kz; Tue, 27 Oct 2026 00:13:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461752.1672778; Tue, 27 Oct 2026 00: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 1xLUoi-0005nc-I6; Tue, 27 Oct 2026 00:13:28 +0000 Received: by outflank-mailman (input) for mailman id 1461752; Tue, 27 Oct 2026 00:13:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLUog-0005nW-T3 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 00:13:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLUog-007ANf-1o for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 01:13:26 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adfec89-2eae-0a2a0a5409dd-0a2a45078e02-10 for ; Tue, 27 Oct 2026 01:13:25 +0100 Received: from [52.101.57.62] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adfeca4-b4ea-0a2a45070019-3465393e6634-3 for ; Tue, 27 Oct 2026 01:13:25 +0100 Received: from CYZPR14CA0014.namprd14.prod.outlook.com (2603:10b6:930:8f::12) by IA5PR12MB999277.namprd12.prod.outlook.com (2603:10b6:208:608::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 00:13:22 +0000 Received: from SN1PEPF000397AF.namprd05.prod.outlook.com (2603:10b6:930:8f:cafe::84) by CYZPR14CA0014.outlook.office365.com (2603:10b6:930:8f::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Tue, 27 Oct 2026 00:13:21 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SN1PEPF000397AF.mail.protection.outlook.com (10.167.248.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 00:13:21 +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.53; Mon, 26 Oct 2026 19:13:20 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 26 Oct 2026 19:13:19 -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=AwNNXjRaO1Z7CuqCddIMg8GYlqUY6JrpgegxcBXaDqlenJgxo6lcYs5vQUXQ0w1d4H9uBedjaUf7iRqeU9Qcnx6i8BVy+Ny3gvUYfJaNgPS/rb98joCYQXoApvFlKk7jiTi/ogxd/r/z0r3W0qN94DJrioHecVoPPDN6/SWSukl8zZ0tu568rLCv07FhCIcJUnNCH9Qy3IfnJxfEMNfwiYrKnDm7yw8Z/RnVwrXtfTK6cJxRaIKGc1T3YsHtkOYGS2j8w3/Yc6s5Atrk3Ef3S9Q8aMoLyy5kC+/9mehHg8fDJTPijhrsMPu4R+YW0iNNDsA252z8hGvQjn3WwbYUTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YKWyD/YCXCvvIxGVkobaSjoSlS4NRyj9YHykWk+m4uk=; b=pEg5dGBKUiZS5MRDOwDEGigVw5/ogttrE1500cCrn+WHOxDvcGMKirA6ueY4HP11r1SqncpaZt4clegY5+8QTy3EiXJY8qXPWuUXfKSW2bAUhApv3v+e6PBWlzJ2fFmlCovDEDoFvFn4iYA8PWObHBJ6gptR+O1C9sOTNDnaB7ZbNWWAc5LijJu4NCKaM2EnQoUSxdNuHDA+T7yFbLx2ipr3NFX2OVTfdE7QMVAm2Va7EQpJJhG21ePN9NoZg9wbHtM55gM7QKk89MZ3KyGx1/Y6vwKNNEo5L50IjENVDrHehKvwnokyUSTjfRFyRambp2N5t6axiVZ9beKHh5ZgNQ== 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=YKWyD/YCXCvvIxGVkobaSjoSlS4NRyj9YHykWk+m4uk=; b=IUWlBfLjzHLRwS6UOG5wLwWEdZsEudLYC39+MepsM/mYgm/IEslzXzItLzv+BT5XIUjpOglrezkeWqCVOpOjF715F417SqCGUjTEw8EBSVxkp77Iq0RjlvNffmyZIIM9lgXomdnotpQyF+7MtKWMlV5CQ6MMK2SWATYo1VpNVSM= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , , , , , , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/mcheck: keep the banks past the end of the CMCI map polled Date: Mon, 26 Oct 2026 17:13:15 -0700 Message-ID: <20261027001315.2614976-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF000397AF:EE_|IA5PR12MB999277:EE_ X-MS-Office365-Filtering-Correlation-Id: aa2f0620-dd83-40a2-eaa0-08df33bf1bf7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|23010399003|376014|36860700016|261026140227099003|11063799006|56012099006|261021123027099003|261021121427099003|261022105027099003|261009223027099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: Wn6QECMABzWji5XHpzPvKPyluIQA2oqnCQZ2pWCw0qnJlKZTYMwACmgbkI2PsGbtDP1waNJCe1usSnECaQgg8F2hyi8VLRjr1n2buZY8zBXF5fvxD33wa9DzSyP9wqGN4VkoA7kIopB4ZT92fihh3LgMrE2+RjUIba19PoYHn4k3Mrh9fzXFjkGqc3t0xdW7PzLR+GkLDqKn8xKY6uf4sQApnCU4yXKqzWpWLKjqiOZPXbXESj68F/c6QXBV77hUK+66ilo4UbhtLQEjdf+1/Vb1aOKnBfQleNoWNrIUzIXDBY7/JoFzIaA2/jP8yA+fNG8t/WDcbvCbo971PzeQhCOEin0MsF/ucw8T2ROyeQzbOv4C7qXZP7yxbRybSo9aL7syNHWRfy8/6ODg8hVatQxM4NArHXAypAGZBlsDypJNFjhBVLqNXKk8fAHOSMq82Xts1ODZwWoj0y/ifMWU02j/i6af2hfCdEfyuN9xxFl/a+GL2Y7WbL9eQloaZeRJPKHtVoQ74UIPFZXjhgetGSsbEeIGtJHc4oPNDhNGnjg4IVADFDhQCvjeHznVgGMUunftlb5rJZwQg8TFqt+c1sj4zcWFolfTwdKW3JXU92tjsL9E9QAyyu5B/lkQ+1JemnYkaazDiOVPJTeY+Cd952O6k7fUPz3Luw6lw5C0ZaelKuCzzups7XFllH0Z56ILuuxZXN+pB4TrzjpgiYzK5A== 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)(1800799024)(23010399003)(376014)(36860700016)(261026140227099003)(11063799006)(56012099006)(261021123027099003)(261021121427099003)(261022105027099003)(261009223027099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: xA7zG7M1e8ckRnR7IQgh/8ib9hXoihmSWXX2sldKw1U+hX7imNakC5v9NM337jmHC9vDWYylrSd/BoEeP6HTyHK4FdPfynLWFm6kPOx/+ioDGOdbtsAWoG/TM1uptWoci0iyr6VsO1bqT9eeQ9Q1b2dl96lQszLVLcOJflszrazVhZgeod49TBPnrqhwxAQAe5IYn3Eeg4dSEcqXp0v1t1xPMjSqXhDdHYFFPBI+d46uAR2TFaNH5mWlSVMMyJPVJaVw4xZnZxyS1oZhhMs1iuGFf4xQ2VEG0trI6WlFibEdKZNRH/21X4O2ZZorjkdh/spSfNkbfh+dX1xY/3iD0Xwtgyr4AFXP5HoFkZMWiIan0t/bDkI+k16bpcX8yPV7MsLINy58Rinogpxe4A7vCwI0GN5ejcfYgDtmyQn5Xq8nqo5t65C2El0SQsvc7//M X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 00:13:21.0299 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aa2f0620-dd83-40a2-eaa0-08df33bf1bf7 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: SN1PEPF000397AF.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA5PR12MB999277 X-purgate-ID: tlsNG-ef75cf/1793060005-A7AD0AE4-8892929A/0/0 X-purgate-type: clean X-purgate-size: 1502 bitmap_copy() copies whole words, so in set_poll_bankmask() it clears the banks past the end of the CMCI map that bitmap_fill() had just set, leaving them neither polled nor reported by CMCI. Set those bits after the copy instead. Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU") Signed-off-by: Stefano Stabellini Reviewed-by: Jason Andryuk Acked-by: Roger Pau Monné --- xen/arch/x86/cpu/mcheck/mce.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 1888f22d15..f9a1389516 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -621,9 +621,14 @@ static void set_poll_bankmask(struct cpuinfo_x86 *c) { const struct mca_banks *cmci = per_cpu(no_cmci_banks, cpu); - if ( unlikely(cmci->num < mb->num) ) - bitmap_fill(mb->bank_map, mb->num); bitmap_copy(mb->bank_map, cmci->bank_map, min(mb->num, cmci->num)); + /* + * Banks past the end of the CMCI map are not reported by CMCI + * either, so they need polling. Set them after the copy, which + * works in whole words and would otherwise clear them again. + */ + if ( unlikely(cmci->num < mb->num) ) + bitmap_set(mb->bank_map, cmci->num, mb->num - cmci->num); } else { -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 00:49:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 00:49:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461766.1672788 (Exim 4.92) (envelope-from ) id 1xLVN2-0002YJ-7W; Tue, 27 Oct 2026 00:48:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461766.1672788; Tue, 27 Oct 2026 00:48: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 1xLVN2-0002YC-3d; Tue, 27 Oct 2026 00:48:56 +0000 Received: by outflank-mailman (input) for mailman id 1461766; Tue, 27 Oct 2026 00:48:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLVN1-0002Y6-5c for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 00:48:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLVN0-004jzL-BB for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 01:48:54 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adff4f2-bab6-0a2a0a5309dd-0a2a4508b494-4 for ; Tue, 27 Oct 2026 01:48:53 +0100 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 6adff4f4-f659-0a2a45080019-346534186fca-4 for ; Tue, 27 Oct 2026 01:48:53 +0100 Received: from MW4PR04CA0388.namprd04.prod.outlook.com (2603:10b6:303:81::33) by IA1PR12MB8493.namprd12.prod.outlook.com (2603:10b6:208:447::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Tue, 27 Oct 2026 00:48:47 +0000 Received: from EA8PEPF00000006.namprd05.prod.outlook.com (2603:10b6:303:81:cafe::2) by MW4PR04CA0388.outlook.office365.com (2603:10b6:303:81::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Tue, 27 Oct 2026 00:48:47 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by EA8PEPF00000006.mail.protection.outlook.com (10.167.249.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 00:48:46 +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.53; Mon, 26 Oct 2026 19:48:46 -0500 Received: from amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Mon, 26 Oct 2026 19:48: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=wSB/kAUmUTfMnF/Pg/c1Tc5fuYUtIvC3fapWQw0rB4sFKQg277a7K7AWvsPfJtVEnL8YkmFp+yWQtEuwM2AQA2xeoeB1qyP3WfPfc0sWWdnpsNYfN6hfSj5G75ujfOL/d+W8p46YxxNhp4wfMXPwxqiTuhk+WxhhtymjQ18Fu+Wh9+TQjxPBsHvmI3RFmcaIaFw5LjvHqDnjQM2uKnf/qvOkKwTIiJJITNM6lD40C1H1G/Sle7dh6+BTFNu5sdkeCYxo5ifzULr9LdBTlSR4eCoQ6bPY9AJ3NG5Y+egjGPtpfjzTc70Jk1QliVcYBtGwUu/uHWGjJxbBHkBtksll/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=eZoj1zyk8OBPcH6joxfnnOehLiVgwqs7MPa/ikvEln0=; b=Tzb6ETIRyeNBhYP0NyHg3mmApcvoxj47ipfV8rPJCsEfCPHGHne5i7yJ37YLbgV7IALCB2Wsh0rch9vVV70qTc6vNZqBeJHBGlIpn6I7ge1i5Vr+bLKis9CLUJEFd61N/vWTb+/oSIiab0EPJisOA2Xxbl90rm+nSRmrkx4/i0zhFQ2mhEwf6z6C9/Y1+TCw8Vu6ljAQcupUvMsktzQmIdswTnGwBb6Aq9PpxW5A6IxKuo/UkxlM970l4k7qUryQA39NDRgj+kGzgUDgHGZaGYhE1ymupJfprHOImaZ4ZaavbKiUxLiGhBTenuL30DKijBI96O6XE4brT5TDt7FI7Q== 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=eZoj1zyk8OBPcH6joxfnnOehLiVgwqs7MPa/ikvEln0=; b=u3D5eMLp64gHV0QL/IQ2gsfm+/O1IN6/mz63EEcozOvghmaDAfdkoppG+xCYBlcMicxitXPD9zt+wfCje1UHPGJurr2CTrbj4qF80v1ALNxjFyexQlG4ZK7x6/YIu2ysiMsDvyFr4qs51k+vkSbmICf/z6MhQAu8+AL956vWSV4= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , , , , Subject: [PATCH] x86/mce: don't call an unregistered address check Date: Mon, 26 Oct 2026 17:48:42 -0700 Message-ID: <20261027004842.18508-1-stefano.stabellini@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: EA8PEPF00000006:EE_|IA1PR12MB8493:EE_ X-MS-Office365-Filtering-Correlation-Id: c27a2b5a-758b-4ee5-7814-08df33c40f25 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|23010399003|376014|18002099003|10067099003|11063799006|261021121427099003|261009223027099003|261021123027099003|56012099006; X-Microsoft-Antispam-Message-Info: i+dL4Lj6TJtUVvVeLC3AmzLaumGahYwZX0qPDeGkqGSYIk5nevgvuJqYjpMlDOpgiR+QsLblJgkP3fvrmY4kHhUMMTUp3gBcH1d7OvcWbOM2ct3vCb6UiSQIP6oE2lula/ndgd8iAvJhSg/rm7ckriKH50+rvn2LkSM0wjRajYrm+FLLULGIvVkFb4aldEeLsCIbHtWKD1eQE0EcnEaXCmegH19+p+M5jFqzyWpa7lCF9Khxv0dr9T1X89Q073WKPgPWyIdVQn3ykZgjGjC8iPoM9xMS+tOl2srH2fyf1d7a3P4ozH5HXMxGcLf1iT2Me38rv1PWK21FmVmnmlk7Gcie66KKdROTbdDomU77h95TqUSh9Kw1YYX92VbnbhmAePMaygFB9y7wLHJ7zHtgKY66VA0LllrIGDst9AeepW0N+6OWs9Kkw4N+Ecjg6NWYR/3PThrq61B9EBkelVIcmYX8AQxa/RKd+hxRizuTGRmfbKGhp9+DBYyX3GlRwbVonPdh2qvZ7nI/KCWGoelhd90S8ljN42Cf4MUO6RLwgyUn6vYy9prQk1Of/6JEfcyl0yudlx4DiCkz6WkdFbZoF6Zp7bE59BojYZ/JISIbhXssStydwQZzk2TmtA0WFVdxggmuly+l5kAqzIBtMZrsGVkOoPN2JhyR1EtQK9Hvc3ZXXzdyrEq2+IufbbQZe2xj/5dJ7iyugEhuQpHLxFlp6Q== 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)(82310400026)(36860700016)(23010399003)(376014)(18002099003)(10067099003)(11063799006)(261021121427099003)(261009223027099003)(261021123027099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +SSxE/D/ayt2WlRLoiH/T9PRrrA42tjJAc+0sKjwhxrBgoXOJBJ6o+zWZJACINwZUEqooEk1VaY1NjD7rNkdZJHFP2iNWQuU43nCTiujDeb4ittznjQBSM9Hfh+NdEckLMGea/jHSK4+czYgydAW6wx4hciS9lU5+wNobiABJ2EoHmXPt7bSMwovOx0DpXSHDdCWwYapkJfHYHpXuop+tlBBEE6SwaDL6NDhr1Ole5uVb9mRHogevdlb/otMebF6bBbg0j9larXX8tPYdwhp/67NCRhyoH3fsn3P/p+gFh4UNrMQP9ssbC3rXouhfDZ2C3La2VtO4WDeCRpRrlkuXzKtSUFZF++sgqXQPF9rX33U/KoOq4FDaUKUb+iKEMLwJObTw8/TANGvg33WvAjLG2HOj5fE4MCoqzZVxUbTGuCmansiqIcNq6PoaaaIgsOh X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 00:48:46.9279 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c27a2b5a-758b-4ee5-7814-08df33c40f25 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: EA8PEPF00000006.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8493 X-purgate-ID: tlsNG-c1860d/1793062133-D514E87B-886C9D64/0/0 X-purgate-type: clean X-purgate-size: 1969 Family 0Fh registers no check_addr callback, yet mca_init_bank() and mc_memerr_dhandler() call it unconditionally. With altcall the NULL pointer is patched to ud2, so on such a CPU the first bank reporting a valid address traps inside the machine check path. Treat a missing callback as the address not being physical. The recoverable_scan callback, also not registered on family 0Fh, is already guarded through "recover". Fixes: 9595ef77ab11 ("Implement page offline recovery action for AMD") Signed-off-by: Stefano Stabellini --- xen/arch/x86/cpu/mcheck/mcaction.c | 3 ++- xen/arch/x86/cpu/mcheck/mce.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/mcheck/mcaction.c b/xen/arch/x86/cpu/mcheck/mcaction.c index bf7a0de965..96febefd0c 100644 --- a/xen/arch/x86/cpu/mcheck/mcaction.c +++ b/xen/arch/x86/cpu/mcheck/mcaction.c @@ -41,7 +41,8 @@ mc_memerr_dhandler(struct mca_binfo *binfo, int vmce_vcpuid; unsigned int mc_vcpuid; - if ( !alternative_call(mce_callbacks.check_addr, bank->mc_status, + if ( !mce_callbacks.check_addr || + !alternative_call(mce_callbacks.check_addr, bank->mc_status, bank->mc_misc, MC_ADDR_PHYSICAL) ) { dprintk(XENLOG_WARNING, diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 1888f22d15..8c984c61d2 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -192,6 +192,7 @@ static void mca_init_bank(enum mca_source who, struct mc_info *mi, int bank) if ( (mib->mc_status & MCi_STATUS_MISCV) && (mib->mc_status & MCi_STATUS_ADDRV) && + mce_callbacks.check_addr && alternative_call(mce_callbacks.check_addr, mib->mc_status, mib->mc_misc, MC_ADDR_PHYSICAL) && (who == MCA_POLLER || who == MCA_CMCI_HANDLER) && -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 01:19:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 01:19:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461777.1672796 (Exim 4.92) (envelope-from ) id 1xLVqc-0006Jy-FF; Tue, 27 Oct 2026 01:19:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461777.1672796; Tue, 27 Oct 2026 01: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 1xLVqc-0006Jr-Cb; Tue, 27 Oct 2026 01:19:30 +0000 Received: by outflank-mailman (input) for mailman id 1461777; Tue, 27 Oct 2026 01:19:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLVqa-0006Jl-SV for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 01:19:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLVqa-00FaIi-9K for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 02:19:28 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6adffbd2-e002-0a2a0a5209dd-0a2a450be6a4-36 for ; Tue, 27 Oct 2026 02:19:28 +0100 Received: from [40.107.200.5] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6adffc1e-b7e8-0a2a450b0019-286bc8057d63-3 for ; Tue, 27 Oct 2026 02:19:28 +0100 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by IA1PR03MB8286.namprd03.prod.outlook.com (2603:10b6:208:5d6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 01:16:23 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%4]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 01:16: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=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=yd7+9jQyjiUpABAWAY8DnnEVjua2h2ImB82Q7O2oxT3kGnsduDF38jrurJhfkXb7OZ66HdP2uykX4upQCtU6YfCOvlFP7JU7jwllb1oCzCbynkkNFS2WFnZ/F5uAf27jLogCNhtlwt32dOhPnsiH0abkxpG0cb+igl+S8ie4jJRm+KCpAgoGlz1Z5ujxFa6xSnpx3rvkL65ZT9dd/AyK2sRIaVFbvdz4HHhdm0NmF/ZYMcqCBku2bhGMdjbN6ylCxzUve7dfrbDJDhLrx2weEbXytv2f6HDkML+Z5UzZswii3way1FJFTQr+fSDN2pUkUgLsFxA7kIEgbzrY9mOFvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Avm3pNueSvCWDc0rcC+pqLww0AITH4pWts4SeFG/fdI=; b=yqWMiVJQahDY/XtYAhVuuU6r35N58Eq9yJIF6f+X4EgxhBWGMGEHunnBGVXHKD/Z5koVqaXht9KaT9dB5NI2JdRjeNu4IrJ4rRAf3SGlEGJEM9nXR8yLV5iyB535ruNx9vDOF7aKndNPx1u52lv4Lwc9/dhcrejqs1OKWq1FODP8K3Vt0iayh6Sty5gsQrBirmZKOufsRIyOSxlcAlXsR7XoOzDt5bZi5g99DiGVlYLYgedKprPcs62Ft8uh3Ml/cETmMbbQDo1Sa+gQi/34XJ162q7J0VZ6u9YtQF/mmPOSZoQhzQx/FAVt+olxMDKc3gSKIhIs+gDz6LZWsqCuVA== 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=Avm3pNueSvCWDc0rcC+pqLww0AITH4pWts4SeFG/fdI=; b=MvOdf9kYC6wUGQYPToD7Gl0Wt5ycZPqlew4IV+I11QYNJBi47VFw84pPbpcFn2RlQeZDl+siGrie48bjk1WBr8UibRem9tkvRg2JxMZIxk3IRZcV4Eebl69W1Vb/x/rH3rgn5dTt7PQL6mOFsYwj+knb0hULT8t5MCMKj0I8EjA= Authentication-Results: mx.microsoft.com 1; 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 v2] x86/nSVM: Ignore bits 11:0 of MSRPM_BASE_PA in L1's VMCB for L2 Date: Tue, 27 Oct 2026 09:16:10 +0800 Message-ID: <20261027011610.364945-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR01CA0039.apcprd01.prod.exchangelabs.com (2603:1096:4:193::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_|IA1PR03MB8286:EE_ X-MS-Office365-Filtering-Correlation-Id: 2386f249-bdea-4b54-917c-08df33c7e98d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|18002099003|56012099006|5023799004|10067099003|11063799006|261009223027099003|261021123027099003|261021121427099003; X-Microsoft-Antispam-Message-Info: 8Foio6tyZPU36lEiphDnx6YysoEXo/0rPf1FSPHv10UEGSW7Kbe99N1SIhXOjjgt+d1YTFPCyjUb7X8+aaztZ34PddJb3F12AXzFp8/hrT0mseJFJLM8Ld/0TdBTw1TRh7gtN2nVoGE6Nsj5RLZElf1EG36aLMdfanc9cXIhtohPrUqztRW7JMyVJiWUyz1gVF95y6IWx76mPnCcG1rVqnwZQlc2Odh1wbHiGiwwwIgKH8v77Goy7uwVYQDN0r0uc4hdwivaIBsdzK0N2dEQ8mbYlHOc5fCjGTrgCbGiU/dk0oA7V+3ctXKNHorVrwgD5Y9u0ekuLcSRkTI4a1JKvahcc9UCUj8QPRt1N3HHxyw+ltp6+BiY0usAMPyzJXe283X9qTXPsGfKwxVRGuxRGKG1q8SIpogYDIEL9RYMgFeDwtbHPt+n6GILPGAdsVxC3CBoRRr+XuBpxAKBLx7Q5OL5B+uE2sIo/CiuXqKk/FAYjXfBgNB4ORwL5iVc54n/HCrlqgbQChAb3Fw9033geHPlzD3VfyCop+NWN5JCoxgcZ2rSzN+D/VvQi2wT6WT8tc7e5IulucIe18ernLgmypK0L0/2gF4Zfbxr+r/qvJga+N40ctvd415D0XGyrguUU8vo+lRd5foqYsUNl/+9qYJifYnDqe1R4EzPZzMT2DE= 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)(23010399003)(376014)(1800799024)(366016)(18002099003)(56012099006)(5023799004)(10067099003)(11063799006)(261009223027099003)(261021123027099003)(261021121427099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?1YBkqpBwq8Nu0+HgnPwzg/10rZSu92U/4O9yd6rWn8uVOxL6VTlX1kK+Dt3+?= =?us-ascii?Q?1Dkz6IozdBgK/VQbudWQ3/aT2cSrJEOZ1U1yEiXHqsRK+R2Al9wSF9tLlm6X?= =?us-ascii?Q?wrp8PlzOz8q80iWthRg50Dagtw+vhS9U/yXHNV6mzOBJEwTR1kwhyK4jULmU?= =?us-ascii?Q?KAbf2FaSdR5fVlgdeW1dl6vj3ZJiZuTKiZG/0bRt03ew51qqGNmdvizg8Cyv?= =?us-ascii?Q?D0vX18PpEcKV2BeDWCTq891n6jzGyKk375RFPvagBbiUvYAu9YosASuiLRJL?= =?us-ascii?Q?A8ZtSVTSXL172Q+rnYh72EyBDKJtYyaVzi0rIFCcwikyFghdU55f0I6iyFQw?= =?us-ascii?Q?KVhM0btxgx64oameYRP4Xv5w6qeHHx5R/zxD+BehrlAZ4E7O9Nk8deipyUyR?= =?us-ascii?Q?oZYXDRFvCy7ux5mS+8F3jRyKbSstgqs9gbLGJBz4YwNlt998MTbmqD+mY9JE?= =?us-ascii?Q?cuZsfDJSgt58XikgEgZ8oUEtUUmfb71zj8VcJxXauJxvFpIAnnubSDYvjMxC?= =?us-ascii?Q?k9sLNh73Ivdt/20PWN/ztRim8MBB2svMD0nDv95GrwhmAJpVHiB82lbNw4gI?= =?us-ascii?Q?RD0ZaSH3wvS+m1qO6t+K7crbdaewcLmzlaU+28VLlv1c++rfIgjdEpZRChTN?= =?us-ascii?Q?ZauPPLA00s1C5JME98+hSWReGKFvtgumEWX0Pa/zxlVmO389b2C5oVa5m4HR?= =?us-ascii?Q?PQ/PSoI1PIhUm26E8HE39tNkLsOivYdz0w8U4rtJcJOcde1At83mNRLU2q+k?= =?us-ascii?Q?IQkS8PFJiSmG7RsFUqK8c0xhNZEw0rB7WC6TkAfZVyt99QB/mGzvnV2JBZr4?= =?us-ascii?Q?xj/ZnG+rUwZg6vVVlqt+pEU7dL23ju7ofLFfSyA1W2rNGdq0bH2KwbfEE4QX?= =?us-ascii?Q?xcKvaRjbAIdSGJ1eHiRGKuau1Mdn9N73WURxQlFFzwvXogBIm20+4jkNoH8Z?= =?us-ascii?Q?db3kurSEtp17ZSH5bvq1Sh7GgleB3PiUuM/pAZpKa42ffcBuFfDykoa4MJSx?= =?us-ascii?Q?wOgC39qMAVjytffPemZoKz2BR+M8U2Jfaqheifsym4c905zlValIV84yoTFE?= =?us-ascii?Q?imCl3j9NxHHmnZmn/NOEpqxIxt1OWYPuSZy0RZENb4JlUPeIx/rHS56jGrPM?= =?us-ascii?Q?GaEnoA0JN2Y6VF0orwmsTEPCy8PcCRRsLj7IZp2YQT4NYs81IUBoTwHOvZx4?= =?us-ascii?Q?H95bx0lr2EdfLt+L/Kabuap7lFJ3XkbdFZ23dI6NCxA9ztLi0ZFXvCKC39To?= =?us-ascii?Q?pO3lopoIta6VU43k+BPG2X8ee0hJwNyiJh5PxC7ZCYUPMO2J1Nq3NFx1qEQN?= =?us-ascii?Q?kL58DHZapUnxGzA6XXIFdectOPMX8/6f/Bl5V2qJBxp81DWlUQzpFIs3rEH9?= =?us-ascii?Q?1chLNqqlioUdR789N2x0vjqW6z/Z8ElfKZMMfIhTvDCqgIO+1pB6Dn524FWS?= =?us-ascii?Q?Dd2jj2GMltP9nc5u3b8Ck/WfE2UzH5nqs4D1Q2UuRm2jsKCNIJOlXgXONoT9?= =?us-ascii?Q?/q+3BSfRMkko9HQO/HTOIGkhI09Ud2wqcEw2ifmrFao9txJhsmOdJAIoPEaa?= =?us-ascii?Q?B5m0NSLdBaniD8rhdvw6TxusHlMPhB1slN+FzBVkC/oim4b88o5YVm6pm3Tz?= =?us-ascii?Q?/KTVBkB+DdGvBo36g7uZZ/ExREknptwDYRXGAojYNXKfV2hK7r46B0YlnMkO?= =?us-ascii?Q?3Fr2zOaw0xkFT2Z6YP1n7UAJdBPH0vX3iP5ifcibpWNjL9JSpcJvdHJXW03q?= =?us-ascii?Q?30LsTYuCzg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2386f249-bdea-4b54-917c-08df33c7e98d X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 01:16:22.2583 (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: NVxuCkN0boX/XEeh9Q6y6iH0/u4M9vYzDMvCgDeCRAsn4LcerBJUy64JVp51jDxIcp/XOt/OvXgU7/CbOfJ5glQENGbdjFrcAd82U81Ta+E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8286 X-purgate-ID: tlsNG-42698a/1793063968-1A2C49EA-3EBDD0AC/10/78276251493 X-purgate-type: spam X-purgate-size: 1945 VMRUN ignores bits 11:0 of MSRPM_BASE_PA (APM volume 2, 24593 Rev. 3.44, section 15.11 "MSR Intercepts"). On L1's VMRUN of L2, nsvm_vmrun_permissionmap() copies the MSR permission map which L1 set up for L2 from MSRPM_BASE_PA exactly as L1 wrote it. With any of those bits set, the copy starts at the wrong offset, so both the map L0 runs L2 with and the intercept check on #VMEXIT use the wrong bits: L1 can miss intercepts it set or see ones it didn't, and the copy may run into the following page, giving a spurious VMEXIT_INVALID if that isn't RAM. Mask the address before copying. Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Stephen Cheng Reviewed-by: Ross Lagerwall Acked-by: Jan Beulich --- Notes: v2: - Say which permission map: the one L1 sets up for L2 (Ross). - Add the APM section title (Jan). xen/arch/x86/hvm/svm/nestedsvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 2b998e26bc..56d0f0fa4d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -309,8 +309,10 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v) ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm; + /* VMRUN ignores bits 11:0 of MSRPM_BASE_PA. */ ret = hvm_copy_from_guest_phys(svm->ns_cached_msrpm, - ns_vmcb->_msrpm_base_pa, MSRPM_SIZE); + ns_vmcb->_msrpm_base_pa & PAGE_MASK, + MSRPM_SIZE); if ( ret != HVMTRANS_okay ) { gdprintk(XENLOG_ERR, "hvm_copy_from_guest_phys msrpm %u\n", ret); base-commit: 4e3c0eeac5761c505f8229e82d265eb29957ca5c -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 01:39:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 01:39:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461788.1672805 (Exim 4.92) (envelope-from ) id 1xLW9w-0001Ob-3t; Tue, 27 Oct 2026 01:39:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461788.1672805; Tue, 27 Oct 2026 01:39: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 1xLW9w-0001OU-0R; Tue, 27 Oct 2026 01:39:28 +0000 Received: by outflank-mailman (input) for mailman id 1461788; Tue, 27 Oct 2026 01:39:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLW9u-0001OO-EN for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 01:39:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLW9t-00Epwe-O3 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 02:39:25 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae00081-2eae-0a2a0a5409dd-0a2a45098440-28 for ; Tue, 27 Oct 2026 02:39:25 +0100 Received: from [52.101.201.57] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae000cc-be1a-0a2a45090019-3465c9391108-4 for ; Tue, 27 Oct 2026 02:39:25 +0100 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by SA1PR03MB6468.namprd03.prod.outlook.com (2603:10b6:806:1c3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 01:37:21 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%4]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 01:37: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=QMy0M+EMgCfG8QsuZRj8KDzx6zgMRFYV9FMASnCBoiaH+Q9TVHryL9YcjShRpIv7j2av3ZrIM/DLP1c3EkHhPU6AX/juPxT9oeW4roTuF4Sfn55VBrIH2mue1wjigqdMlCTaHuM8WNUsqnmsrWbybEnTaXnq9pFJyGZsxv6deuBloO4l3Z2mJELVAdtWBknbROTIUvWZ7zynQ98m1MS88Yucy6sDMCWiBdqK+zXr2AFCQmC3NtR4WGWB3DAg3Cu7of7V+uNNza2iXmLa0uhAoFA1clOKFQNVBZWU5NVHnDkG7Wu77tFGx9XTOFN74OmY56wIVrVCQ5fe2DY/RI7o3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SpHk3+bXZZlKt/sxGgx4NuVmP4uBBP/3Ad/eXgoALyw=; b=HIohBI+g3dEF5S2Wy046UVF2wLv8ig+qwtWRpwYubASpY8K8CG6QrsUC12GV8lCKCrRoMVnZcOnfOMKXh2lNyXMQ6va74msWVRrUPWwtGteQkI7FTKUlI9X1Oh7S3OjNNYnm/N9xtC9ZOyublsAzUcFUFpcZjZZ9BOLZ4eFadtm0nsqJy8yQBtvJ1hawGYC7uhsQefZaMKvgYkEzZNKB3OGvy3C5Twlo1sq5y3I9dv6DXrJjc8ENsq8NwuVjFo5CWAVJiphgBpDWCQ/nbft9pZVMkA8SSFZuwewd6iw/aZDku7bDEzE05+dweZqx+4fzcsvkPM9Rnab6SyCt7yW4uw== 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=SpHk3+bXZZlKt/sxGgx4NuVmP4uBBP/3Ad/eXgoALyw=; b=p6PyQXucHzBprKgzJ6YMaeecfjBjI/NMlAQDvDQizWnHwiikFqA0qAC7AHVXH7XKY4KtK0XSrOyLGvjVHDMLXKUzvaBXPVmchG41Un9LCbn/0k+Q+tYniqkWfzfLQvNkfhfh6Bkrp4EM0s84hCgkvSOWpuBouPTbRajHOdzp/LI= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Stephen Cheng To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Ross Lagerwall , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH v2] x86/np2m: flush the np2m on an SVM nested TLB flush Date: Tue, 27 Oct 2026 09:37:03 +0800 Message-ID: <20261027013703.367380-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0103.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:cf::14) To CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR03MB7889:EE_|SA1PR03MB6468:EE_ X-MS-Office365-Filtering-Correlation-Id: a43d5969-679d-4306-9cfb-08df33cad7a0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|261026121527099003|18002099003|56012099006|11063799006|261022105027099003|261009223027099003|10067099003|261026140227099003; X-Microsoft-Antispam-Message-Info: kwo2XSQO3rbBXi5391hglnywV8lACJyo+BaCGetpWKwgGsoUt0kXwXAyiOW8TKa2/qkRsewhvXg9Qm9YWOJYLvzegCEW4EiMyjZz1OH0ggiSeXY2P5ksKHlpMjkoQzkwOaCxhhJS98yJi/kqfKc/J1phvSOyzEEQ5kuSJPcxuc9UUaaYEHeoW+A1sxlCBCNNWI5WAg6gJAcJz5t7w7+WuTavTAYoetkekGvciwo5yFmmsLJItBmGOydRgrEAdjO+vxCOt9IKOVx5sPUDLQiNA+LZ7E5sYNqj1CaTUmvvki7+wCS26r3cANzr7eO6Sjdx0V1MqHmKRxqYw6GZ+a+0SVm3mSQ7SMpSJL3FdkWlkQimazAvBbzOy0NbjnK4pt93WipnglcQX67nKlPwdjWIG5LUHxLqV32utarHw4pPpIJ6v4/wnRAddRK+aHMB6AfL7HNdss164FA19ckBrQtegcLW7ZUj8RyvDA7nJgxjxViAwudI1BgMo/5eg8Ih/2W1e6YweThaM4QWqcMhwJ4i25PeMPsAeq3viIYdVILzzhE0FLhnMwLHSY5P8VASEyXvC34NeHP80DG+GJUMAlGTXmXM5VQyJnQsoOtsXR9TudtrNFXqIV4o5MWoYk0k22UeOuEcFejKUnJVjNTH2sfvVvBf8PXtUKkEmeAzHOJE7fs= 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)(23010399003)(376014)(1800799024)(366016)(22082099003)(261026121527099003)(18002099003)(56012099006)(11063799006)(261022105027099003)(261009223027099003)(10067099003)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GUC2Y7cl0seUdfFkIE4up/X0I2YZs75qYor+wVIkG2CqxipUwPKt9XxoMTMv?= =?us-ascii?Q?C/yR537MoBMPZ6/qMkmrmWM4lF02b68KG1aa2RT890y9eY5hADMPQBK/03SJ?= =?us-ascii?Q?vcIPysFSPKgpm3yAMRmwl1TL1YmBVvMi6D8cE/J+3FY7XzBA/Ez/mn1d6yF9?= =?us-ascii?Q?9f//Vj0YIYmG7/NWtvzhetvfAantY7riDkXrjRSllz6bHP9GKAFVmoYSB3I3?= =?us-ascii?Q?K16j/w8bm/h0TIBbDQidh048ccS7BBtTi8tWJ+uoGb9q58udAbAynzAhhNiW?= =?us-ascii?Q?1EaQ+re2gA13UsFM1p3pgwJvE2aC0yXtZXLZqL545nJnZg4bqmSBEuTkANe+?= =?us-ascii?Q?DFDEQjsZVTkN79OmTGQSUU0V6qpB/vL9xXylVRjwVvBhhRkpi/07g76KLzua?= =?us-ascii?Q?0zUptgCwXT1cHxFAGL/aRy4FUnCUEHinAx+NIaCovxvDd7CzrqyBKYFE43fn?= =?us-ascii?Q?EeHLY8oiu2mkt2KqQ4LCy1mJGoQ01T7TDEa5aK8uuS87Yov5SmYIvaoPiB5s?= =?us-ascii?Q?ZIuuwbGVomWTU++qqVSUQmWMqBAlF2WXEpseDraKzf+pnqE5dvqNIbJl29pI?= =?us-ascii?Q?JcN2GOSI4QAo6PEhkIDcAwXk/ydcc39Q6VvgxPByl6WhB47M2asWALsmiIl0?= =?us-ascii?Q?Jws+ppU3yqXMdhPkic7plfpXis+OwUofU5Npt00cL9HMbXTMkDBDCAWhPNBH?= =?us-ascii?Q?I9mGitkNMnxvSElEUPSKbzKTXyNAb9/qfDqt48iI4SgCn/z+XA+hUtkUXvHQ?= =?us-ascii?Q?o2daA9UnsfAjsYt7UPJPN4B4u+7g+RdHs6406CLXpTMg7ESdC+KowULVmaAg?= =?us-ascii?Q?SXtIkezGfyYHORNxgjtDwG6yi0Re77XEhwb7LxVdBtEYibulv8sOzWeioSc9?= =?us-ascii?Q?/hwjRhiw8Jaww9ABoi63LfL5lDe+rtMgr3PXHHMTZwTitGDDWwbltKWdL8gK?= =?us-ascii?Q?HBmtVOWQdFWlU4AjC/tKcB4qziejVdxbmb658TaTkAZ/TMl3T3jw8R/fyPCh?= =?us-ascii?Q?hshf2YGM2oB04pIfgbzMh3DEdyGbcr26zfYAYVgHD763zSNBWFGpfVwugeSu?= =?us-ascii?Q?lwcoUNkGL3WCDvJ0PpMcQpjGw5jprD+7/IIibD/vsMTscfQo6JJ6Vv1SdS7H?= =?us-ascii?Q?/aEhNFDmIbM08t0uj5/SF/qNvFE8qOuGu4dhCzQ7Oo4NfQ27r22TVyeGGSLl?= =?us-ascii?Q?1MhKt+++qRdBZN1BGpGd/CDv0lV77KVJBntqQEvfZoxGjsaK/GVUIR8pNUB2?= =?us-ascii?Q?JZuNA4qEfRiBILyw+JcdocGMxMWJx6ILsDjcrMJsU/AsMkLiMmGRNhlt5eTc?= =?us-ascii?Q?4VU0CYazl2FklpnvW3X6uhUHh5MSL0R4Yr8pHrkSHwwu1Hta4eh2DOZ0+D39?= =?us-ascii?Q?HjYH4CSSjXcMNyjI5gxBVYHBTyZc9xYiE3Sk1P1yKyyY+md4pGdqwqhBFELr?= =?us-ascii?Q?vlhq0lG6hJTGKBJ0o1a6cMQAH/l2T/gPLwsAhZq3T27JVxcYTLEAtApn397T?= =?us-ascii?Q?9DTNh0030NOvC3yxTQsCA47Vkf7vsAiXr071mYdFSXjOKFslRZRxy7BGnkOI?= =?us-ascii?Q?NCYqrO8Xjpu6/9P9EIBuf3yzgRYU77Hg54kgztpRsI0H04+ybLrnpAp+J7TL?= =?us-ascii?Q?SntJix8wHNeQ+6uu9oEdYHZ5Wl8zaroD4UcYUEQbqMRH7PemhKNIPBdDAFgF?= =?us-ascii?Q?HRRGzOIzH1/rXxmn39t2UuAyiJPX1F0Zq0nwiYN30d75DMHmq0sQS0ick+Tb?= =?us-ascii?Q?TWKADGsZdg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a43d5969-679d-4306-9cfb-08df33cad7a0 X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 01:37:20.8665 (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: /xWXkh1zYoLjDwWTAkqHyDWw0SJyJFzNncy5JQ2SYDDuVXK+afZ9iMPTYZy/GoGOolew1po8bUvfc8tGHjX1vAcpRvoq6ZEnZhro7nIrSfA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6468 X-purgate-ID: tlsNG-bad1c0/1793065165-FDA6E034-3CC03670/10/78276251493 X-purgate-type: spam X-purgate-size: 865 On 26.10.2026 12:52, Jan Beulich wrote: > Tags want ordering differently: For one, it wasn't Ross who indicated that > he used Claude for the review. See docs/process/sending-patched.pandoc. And > then tags want sorting chronologically anyway: You can't possibly sign-off > on a patch before having finished making use of AI assistance. > > With that adjusted (can be done while committing): > Acked-by: Jan Beulich Thanks, Jan. Yes, Assisted-by: should go right before my Signed-off-by:. Could the committer please reorder the tags when committing: Fixes: 6df4b481b0c5 ("x86/np2m: implement sharing of np2m between vCPUs") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Stephen Cheng Reviewed-by: Ross Lagerwall Acked-by: Jan Beulich Stephen From xen-devel-bounces@lists.xenproject.org Tue Oct 27 04:26:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 04:26:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461813.1672814 (Exim 4.92) (envelope-from ) id 1xLYlO-0008JY-KL; Tue, 27 Oct 2026 04:26:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461813.1672814; Tue, 27 Oct 2026 04:26: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 1xLYlO-0008JR-H8; Tue, 27 Oct 2026 04:26:18 +0000 Received: by outflank-mailman (input) for mailman id 1461813; Tue, 27 Oct 2026 04:26:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLYlM-0008JL-GL for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 04:26:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLYlL-0015So-M6 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 05:26:15 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae02777-8faa-0a2a0a5109dd-0a2a450c8c28-32 for ; Tue, 27 Oct 2026 05:26:14 +0100 Received: from [130.76.184.179] (helo=phx-mbsout-02.mbs.boeing.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae027e3-f479-0a2a450c0019-824cb8b373ea-3 for ; Tue, 27 Oct 2026 05:26:13 +0100 Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 69R4Q8wd048548; Mon, 26 Oct 2026 21:26:10 -0700 Received: from phx-av-01.mbs.boeing.net (phx-av-01.mbs.boeing.net [137.136.102.153]) by phx-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 69R4Q4BT048524 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 26 Oct 2026 21:26:04 -0700 Received: from localhost (localhost [127.0.0.1]) by phx-av-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_RELAY) with SMTP id 69R4Q4qC027441; Mon, 26 Oct 2026 21:26:04 -0700 Received: from A6432926.boeing.com (a6432926.nos.boeing.com [10.191.242.9]) by phx-av-01.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_RELAY) with ESMTP id 69R4PwCq027213; Mon, 26 Oct 2026 21:25:59 -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=boeing-s1912 header.d=boeing.com header.i="@boeing.com" header.h="From:To:Cc:Subject:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1793075170; bh=yNF0nH1bHsqEI3gUKUcz6VAeO/dpQ8c3fM8UfEcgqJc=; h=From:To:Cc:Subject:Date:From; b=b0dBLwu4lOSWweOj7kASYqnFDxkLGITGZcqg3n9/KolQWI3cUhNI/+tt600+6GEiQ 0ssCcGSbMBygCgQxjd54DvMBcc3qaiYNSFsFx4aoE3KG2aZqRWbqbKVxJyp1kR2QxH BuX5YoX1/Sz06tr5BfD/GfczIUHfdaAF/2HxM+jLIecjGH5iBlgKW/6ibimTudTVrC Ea/zWPkA32h8MIbAbjF9ebzRNdTcFB9U4Zo/RYTCtYJ3m91ZzjU2Z9fUrRs+Hz/DwR YZAuL9GgHaguZDsaqneGfulVDHG8gK/dPy0mTIGmsRbrTlM/DYzcCiG0aZeVgG1ubN LBYyO4ZwoU9vw== From: peter kang To: xen-devel@lists.xenproject.org Cc: anderson.choi@boeing.com, matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com, Peter Kang , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [XEN PATCH v2] xen/page_alloc: scrub each page in unprepare_staticmem_pages Date: Tue, 27 Oct 2026 13:25:07 +0900 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-purgate-ID: tlsNG-d25034/1793075174-766DEA5B-643A3388/0/0 X-purgate-type: clean X-purgate-size: 1470 From: Peter Kang unprepare_staticmem_pages() can unprepare multiple pages in a static memory range. When need_scrub is true, each page must be scrubbed before it is marked static. The loop currently passes the base pointer pg to scrub_one_page() on every iteration. For a multi-page range, this repeatedly scrubs page 0 and leaves the remaining pages unscrubbed, so a guest can later read stale data from pages 1..nr_mfns-1 of a static or static-shared bank. Pass &pg[i] to scrub_one_page() so each iteration scrubs the page it is processing. This ensures every page in the range is scrubbed before it is marked static. Fixes: 4a9e73e6e53e ("xen/arm: static memory initialization") Signed-off-by: Peter Kang --- Changes: v1 -> v2 - Use Peter Kang's Signed-off-by. - no code change --- xen/common/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2682fff9cc..426bd11c2e 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -2941,7 +2941,7 @@ void unprepare_staticmem_pages(struct page_info *pg, unsigned long nr_mfns, if ( need_scrub ) { /* TODO: asynchronous scrubbing for pages of static memory. */ - scrub_one_page(pg); + scrub_one_page(&pg[i]); } pg[i].count_info |= PGC_static; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 04:29:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 04:29:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461818.1672824 (Exim 4.92) (envelope-from ) id 1xLYo7-0000Wt-2S; Tue, 27 Oct 2026 04:29:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461818.1672824; Tue, 27 Oct 2026 04: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 1xLYo6-0000Wl-TQ; Tue, 27 Oct 2026 04:29:06 +0000 Received: by outflank-mailman (input) for mailman id 1461818; Tue, 27 Oct 2026 04:29:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLYo5-0000Wf-7k for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 04:29:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLYo4-002B3m-GH for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 05:29:04 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0286f-8faa-0a2a0a5109dd-0a2a4503dca2-22 for ; Tue, 27 Oct 2026 05:29:04 +0100 Received: from [52.101.228.81] (helo=OS0P286CU011.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0288d-fae8-0a2a45030019-3465e4516ee7-3 for ; Tue, 27 Oct 2026 05:29:03 +0100 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYCP286MB3114.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:291::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 04:28:55 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 04:28: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=VCpqzGQYEItApqZ97YYw7HgKAmkUOv0ceU432xjDK6nDUsc3pWnDpVEc2dpXcEnRTcBEPoF7FosGPVg2hFGv2WJoeRhSq7Jn+nbZit91zAFrD9Fbizk+XjsbRAc94mU8d7grC8zKe/aQcl1HY5RfgZcPYWqknGyzr116UPvJ/l2e57GqPkt8szeWYT4ZGZWoX+5K4nwl+36wpUzWkuVZtzopAj/C25N+l2vwuV6p5JzHthKuplLIFF1v7iYdhDgTv/FPyIUQ7qdz/yjgtCig0RSkylTm4vc0dYjs7QwCi4j1x0eAwXAirPJq+m/J6P5j6GWKbjBz6JTCsy2KD+//Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zr759BuwwDGEuJ+z0Ji8Hf2hWcNNQ0bAZKTXvbfVcFE=; b=dxgWF2pFjGiKONiwiPsZrYd/wTqgrnfUqgw6aKMrQYmrCyU5E2XOHfuMkLNq9y98Ycps9WDx346j6VJTUsmfMMy8MO24wq3QjFBv5WYIAX7CpjAX+xOjr42iHAGLij3IYv2BLmaR36l1kWi19+nO5Ew2rR+cepxGoylNT5iR9H5GpkNqxjDu5u668YzRLzqm8BRApkWrmLTv0Kz4G6RLr8KXKVkbMchFzth4mMVLCAUU5yxAc9gI1laH7q2+mmUPSlW2PNgC+3TMMRyQZywbKggnrihuwCQY1ky0qCQldAPvv96CgRDubXesWS6ZFVlyxZqW1h5lcmk23cU+eRPqCw== 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=Zr759BuwwDGEuJ+z0Ji8Hf2hWcNNQ0bAZKTXvbfVcFE=; b=pYA6sDgaZTi74vwehTNT2vyp1cmnTi5BYV6AKzFyBNuMoa3qcHVSqonWk9WYS8z1LDQmc/XmMgcq+6jPEwwX662QKfsQc1oHX9L5n42bMBVQHgRi+PT99lxPLTMZJtwtiXW9A4VfBj6PCvxM5EWcpj/xZ8d0DevA/Tvg0rKg+ug= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: bernhard.kaindl@citrix.com Cc: xen-devel@lists.xenproject.org, roger@xenproject.org, ross.lagerwall@citrix.com Subject: Re: [RFC 2/5] xen/livepatch: Allow tracers to schedule livepatch Date: Tue, 27 Oct 2026 13:27:40 +0900 Message-Id: <20261027042740.57797-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <179285097671.1706038.6114522060925613675.b4-review@b4> References: <179285097671.1706038.6114522060925613675.b4-review@b4> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP301CA0073.JPNP301.PROD.OUTLOOK.COM (2603:1096:405:7d::11) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYCP286MB3114:EE_ X-MS-Office365-Filtering-Correlation-Id: fefa8dc7-60e7-4368-80f9-08df33e2cf9c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|261009223027099003|261022105027099003|261022075727099003|261021121427099003|10067099003|56012099006|261026121527099003|6133799003|22082099003|18002099003|261026140227099003; X-Microsoft-Antispam-Message-Info: RE7K5lUrL1rqE5SAGzhvGyRJ6P63mauX65AWPBu1OE3k/qD4yUzS57n8eJCeY7Dk8Ev3KyOM+ISQjWM1GbuEJetTB6o84NzvhUlww2VjKY+P+ij5yjjEvuzgzDx0N1wkHkAh1UHJM3jN/M5EEocFvxC+2z+rteJCNfxeDds620oy/QVlsBPi3k+gyR69NhI6cVY0+Hyit3cnbycx3rAYOThztAUSM162BxKxPDGM6P7Ar540EqbFASS6RU0iIlcGpmfIMsPncMqoY8zIicGEMMvHEHlLvu8kOlQinjSER9VLwT35wOzxW4QsNQkrwuY+oNcsCRfTRde6ggYTHng6koOlU0dlaqJA1QHY6/aaeV/J6MdSvR1UAxB2ZURmr909e0wV7Bpd+9ew9Hkdl2tQZ5FhJv6tQWNjTRitldbCVLi9OVeFU8ABND4KOLQEEtqEgdHLNIl6TCfnH/yZmHRt7rNiwknP9G4a2cpQa7kenMx7GuSgSn+0EFJLqYR3n3XryA+9h8EKEtAFDV4il74IGaMv8fR9RWAR4KBLa1Sfzi29ow94heYO5pfGpn/aL+m9oyRDd49In1HMNcev9Cnl5u/Dg5fVaf5ErIIs804YIDKVta5unYW1XMS4P6si30O7gey+DnZdgOlwJU/fnncIg+oX6QK9aVOWa2SzJwabUDY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(261009223027099003)(261022105027099003)(261022075727099003)(261021121427099003)(10067099003)(56012099006)(261026121527099003)(6133799003)(22082099003)(18002099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HiI4QGtWyYBIF9maFsYH36K7nj77E3YSyLbeXOVDZEnHf9Ywpnqywyj+0G9C?= =?us-ascii?Q?yjdWh7Eh0ZsuZ98nxTUyKNWIOvopZvx6/rNz7KxMyxG4HQyi9u+VciibtF3m?= =?us-ascii?Q?DjFDFSuiiE0nsJQF95oJw7zzRzuBUYRfZizIUBjf8qUd08PZKk2Htee93dPc?= =?us-ascii?Q?ZDBg0p2KCfLFoZXjC/Wvp0NaCnj5iIiwIeUHmQT7q7aDzm7WLdvGYl4KX+FL?= =?us-ascii?Q?gS4FZXrcHYqE4MthPBD68ZCO4hCnbghlK/dkD5kdEqVVnU1f8ZYXVPhvPL6h?= =?us-ascii?Q?cNd/mK5C7IzO3Jh7pCz99hmUGyNnQrLh6ILQ8Qp6sFLwBvD/W63fd8CkAPov?= =?us-ascii?Q?P/frYB106pEndfNPvBL4pZ5IoMHiNw5bES722drqAoMA0OqZqXaS2pjRb7x0?= =?us-ascii?Q?B2q01DhkCPZ6wKuTKrmRxpaSt0MaYQ8Ttawdo5Jpple3KngN6gdOEw+7v06p?= =?us-ascii?Q?N3vrCnTCLrDdiEH4ahWVGVCJGV4W5uyQzwm6+s1JJZ7NyYyXC2O9lAPncsJ5?= =?us-ascii?Q?z2k2lnKZ1W2XmnvXwR/dzt05y2pfyuNIbWS1dsy7UyR8gSNJmHLEGpEJ0CTr?= =?us-ascii?Q?brwvJDwX8LmE7P43wCj+M8UFoQz5d5ms4K/CXtpFxeC/auAUUu4W5BqY80Ii?= =?us-ascii?Q?zG3nlBUdmLcSROLQ1d2UVqkACkv2axavYG+bvSoHq1l9Qa5tRSSyezxHKHGX?= =?us-ascii?Q?t1hZ8RPO46qVzdFcyw/2PvdR85vd8RL7SO/v6K0gwDrHFW/V9BYdxUitlR7I?= =?us-ascii?Q?i2mBnqhPYHiW2nqFuZidrcmk7Bw0UkU/Hi1GuElwylLG6iduXAe5TX0asoGQ?= =?us-ascii?Q?9jtE8iZwJZULlrfQxPUEhewgYlFEWfX43FmjdCUVdsaA/Qvs1vPZLvbfnC9l?= =?us-ascii?Q?W2apf8NZJN0elMItGG6nwpZ4fQhgxaYw27SvUZRCwmfVRsnrFR0vejzgA0sJ?= =?us-ascii?Q?VnlqCX9oFlEJXVNsBOYEqw8N9q+I8nJF4wTxTlw+JO7k59YJ0MozXWZxIkat?= =?us-ascii?Q?STL0zq4/5iUyeheXO2BayDSQubLrO/eua2t/gOxZrp8DiUOXIdCx5pSdRvop?= =?us-ascii?Q?wh65YhoNuFcjkkiiP1frXszBSqyNcbqT+KJ7K6BKx0ZyN36Ga/AJ1vygwhkU?= =?us-ascii?Q?pCYKe2AuJ7PTT+BdxdLDxVuYapYwPjYN5Dtj+oFYxzoEGn4eG8gs1y/J9Emg?= =?us-ascii?Q?h17lHzAiP1A6DWY0pldfqwiFjcxVcFo5a8uV91FiV+UwkjMitSIeUhlXBVCq?= =?us-ascii?Q?+g2W5ZQD7QbPkeWIc2NXZqqy1YT/Jme5YnEWVdg30c5u7Qgco4UzxBR/mg4b?= =?us-ascii?Q?RWIxqnbfZ9R8PEWrxFtfEi/tJBFEe5EMU9KhQzk9qeNDPm7TFHab/IYs9Twn?= =?us-ascii?Q?Muji90Uc17BHCyw85XPQP5au/JPcM5autzmsRobLWFGUcupan52MaT5+o4lw?= =?us-ascii?Q?4qfi8/NYZtJW6mtndgY2L14awny9t1wf4pzgCBnbQe9GeuSgEDf2/2KJr6HX?= =?us-ascii?Q?xB+3PcB1Q/YXq36yAP0DroKbSJvvhBFxpATPs+moTq+is7a2U11fBgdQvuCe?= =?us-ascii?Q?cbRnzZ0cENwAEUCIQYIrOwe+RlYpawQeIOU99CVMM5LFvf6mTWXok4GpjXWX?= =?us-ascii?Q?NvMTaUMLxxZocKJReBg6TDchZKf3gQp1ZU33RD3H76MR5aENLR1sPQoS92tM?= =?us-ascii?Q?DSh6gYsfMCRIZwrbawQb0w5eRS3HLB48exn/I15Em/hqq9chYCUpRCuL5Zws?= =?us-ascii?Q?6fbT53GY0A=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: fefa8dc7-60e7-4368-80f9-08df33e2cf9c X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 04:28:54.9606 (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: OKxC1/smEA8Kr14pu+J7p2/xPNnQUqN54w4Q8V7h41GES73g5HLQZAxgXlyRprG2lDvhJNvt6sPIf52cKi732A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB3114 X-purgate-ID: tlsNG-33051d/1793075343-6D0D94E9-15BB7F57/0/0 X-purgate-type: clean X-purgate-size: 4774 On Sat, 24 Oct 2026 16:09:36 +0200 Bernhard Kaindl wrote: >> --- a/xen/common/livepatch.c >> +++ b/xen/common/livepatch.c >> @@ -1823,6 +1834,51 @@ static int schedule_work(struct payload *data, >> uint32_t cmd, uint32_t timeout) >> +int livepatch_schedule_trace_on(struct payload *payload, struct >> livepatch_func *func, unsigned long ip) >> +{ >> + void *old_addr; >> + int rc; >> + >> + spin_lock(&payload_lock); >> + if ( is_work_scheduled(payload) ) >> + { >> + rc = -EBUSY; >> + goto out; >> + } >> + >> + old_addr = func->old_addr; >> + func->old_addr = (void *)ip; >> + >> + payload->rc = -EAGAIN; >> + rc = schedule_work(payload, LIVEPATCH_TRACE_ON, 0); >> + if ( rc ) >> + func->old_addr = old_addr; > >Am I right that is_work_scheduled(payload) only detects work for this >particular payload, rather than any work using the shared worker? Yes, it only checks for this particular payload. >For reference, the existing is_work_scheduled() in the same file ends >with this check, which is not added by this patch: > >> return livepatch_work.do_work && livepatch_work.data == data; > >The existing schedule_work() instead has this global busy check: > >> /* Fail if an operation is already scheduled. */ >> if ( livepatch_work.do_work ) >> return -EBUSY; > >Could a request therefore pass the first check while another payload >has work pending, set its own result to -EAGAIN, and then be rejected >by schedule_work()? Failure to acquire the CPU-map lock seems to offer >another path to the same outcome. > >The caller does receive the immediate submission error, but wouldn't >payload->rc still suggest that an operation is pending, with no queued >worker for this payload to complete it? Yes, payload->rc will keep indicating that the request is pending. >The off helper appears to have the same result-handling question: > >> --- a/xen/common/livepatch.c >> +++ b/xen/common/livepatch.c >> @@ -1823,6 +1834,51 @@ static int schedule_work(struct payload *data, >> uint32_t cmd, uint32_t timeout) >> +int livepatch_schedule_trace_off(struct payload *payload) >> +{ >> [...] >> + payload->rc = -EAGAIN; >> + rc = schedule_work(payload, LIVEPATCH_TRACE_OFF, 0); >> + >> + spin_unlock(&payload_lock); >> + >> + return rc; >> +} Yes, it has the same issue. >Would publishing the submission error in payload->rc keep these rejected >requests distinct from work that is still pending? > >To illustrate, I think this could be addressed with a small change like: > >--- a/xen/common/livepatch.c >+++ b/xen/common/livepatch.c >@@ -1861,7 +1861,10 @@ int livepatch_schedule_trace_on(struct payload *payload, >struct livepatch_func *func, unsigned long ip) > payload->rc = -EAGAIN; > rc = schedule_work(payload, LIVEPATCH_TRACE_ON, 0); > if ( rc ) >+ { > func->old_addr = old_addr; >+ payload->rc = rc; >+ } > > out: > spin_unlock(&payload_lock); >@@ -1882,6 +1885,8 @@ int livepatch_schedule_trace_off(struct payload *payload) > > payload->rc = -EAGAIN; > rc = schedule_work(payload, LIVEPATCH_TRACE_OFF, 0); >+ if ( rc ) >+ payload->rc = rc; > > spin_unlock(&payload_lock); > > >Would this preserve the pending assignment before successful queuing, >while leaving a terminal error when no operation was accepted? This >only handles immediate submission failure; Thank you. This looks good to me. I'll include your fix in the next version. >it would not reconcile the >filter or target state with a later worker failure or make retargeting >an applied payload safe. Thank you for pointing this out as well. I see that the failure after scheduling needs to be handled separately. I'll think how to handle those cases for the next version. >Thanks for taking a look; is there an intended status convention that >would make this harmless? When implementing these two functions, I followed the pattern in livepatch_action(). And docs/misc/livepatch.pandoc says that -EAGAIN indicates "operation in progress". Leaving payload->rc at -EAGAIN after failing schedule_work() appears to be inconsistent with that convention. Would it make sense to fix the error handling in livepatch_action() as well? Suggested fix: --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -2276,6 +2276,8 @@ static int livepatch_action(struct xen_sysctl_livepatch_action *action) data->rc = -EAGAIN; rc = schedule_work(data, action->cmd, action->timeout); + if ( rc ) + data->rc = rc; } break; Sincerely, Ryo Takakura From xen-devel-bounces@lists.xenproject.org Tue Oct 27 04:38:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 04:38:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461824.1672831 (Exim 4.92) (envelope-from ) id 1xLYwi-0002Pq-Pk; Tue, 27 Oct 2026 04:38:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461824.1672831; Tue, 27 Oct 2026 04:38: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 1xLYwi-0002Pj-Mt; Tue, 27 Oct 2026 04:38:00 +0000 Received: by outflank-mailman (input) for mailman id 1461824; Tue, 27 Oct 2026 04:37:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLYwg-0002PX-VW for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 04:37:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLYwf-00F6Vl-Ow for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 05:37:58 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae02a84-e002-0a2a0a5209dd-0a2a4501a05a-12 for ; Tue, 27 Oct 2026 05:37:56 +0100 Received: from [52.101.229.93] (helo=TY3P286CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae02aa1-5984-0a2a45010019-3465e55d2bf1-3 for ; Tue, 27 Oct 2026 05:37:56 +0100 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by OSCP286MB5196.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:34b::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 04:37:49 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 04:37: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=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=jl+FF+vLk/5xlOBcO+70QzMiLFCkwqL3n/uJ0HuJV8vnAraWeljKN8dwtmwxnxSUpbSeF1HaHBu9S5ruNLv4Nms8Msq99SdRXwzNP1+EfXQbcfXyPAM+DspDc83lcvc2y8FBedYvsQYuUqmOz8nKpbOsFz90ZNIkXsSpnAK+Ow2pryTdY4W21Da83sGq5mYBgTf8wwTdwPnM08AdLrttTUUYBKYOpy+cmFGFxDLDMXDnrPI28X4emLYTvhN7+A5myZNYpArvSEZBNgtRLOYJ0M/5jigo+FjoLZk2QI4CxpYeFgseZPzBIZi5UH+3yi2zgFofv1RWD6YbtoiuIfKg/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=Q7AyfO7OGwR4iO2s1aRgusgKklpML9RkuNBYW53UCV8=; b=djFZSOto3doTS7JHo4mDRcCdrf0WS8gBRaWTw5dYkruFjTGVCgcida0eWfRC3InayqRNZAaooXoLSibNhTMS0uzQg3qX2iPBPULwjqQNx0ECQlLrNCLCt6GQ4OZ+3rSD8avXQNoyiNqqoyQ7po9/iZycBUo+xXarE7UbT+txGiBI2iH2oMtRG7i8PJb8OZuWcjVFJPhVoKeao1uPr23UqnGVd7+OwqRbrnAbh95xJdhnu/npm/GXPf9zybWQFwEUW9rrSZABUhptPZnPj+BBdyTMKb/gTHNeaGPLVeAVxK5eEYBe8g2xrPDLQiyn0zSTEmYcxrYEsvP3DPe/vOHt7g== 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=Q7AyfO7OGwR4iO2s1aRgusgKklpML9RkuNBYW53UCV8=; b=gPM3r1909Tx6bT7k3H16xlXM5FRdfOmXH0/QLridb/YUDmaIv52J3bTgS8gTlYuW3VeWksDLwlKKwn9yrsIkSkt0oUJXbJbr/x9qS9bQ1kMQLTO1JbgOZTTVUt69HlEQA6iLTEbv/tFNhEw0PNwwOurXfM+iCs458x7Xl2xh1PE= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: andrew.cooper3@citrix.com Cc: xen-devel@lists.xenproject.org Subject: Re: [RFC 0/5] Introduce dynamic tracer using Livepatch Date: Tue, 27 Oct 2026 13:37:30 +0900 Message-Id: <20261027043730.60174-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <432e0fba-0765-4c2c-866f-faff8cd04926@citrix.com> References: <432e0fba-0765-4c2c-866f-faff8cd04926@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYWP286CA0024.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:262::9) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|OSCP286MB5196:EE_ X-MS-Office365-Filtering-Correlation-Id: ade18ff2-38a8-4e69-e434-08df33e40e2d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|261026121527099003|56012099006|261022075727099003|261021121427099003|261022105027099003|261009223027099003|10067099003|22082099003|18002099003|6133799003|261026140227099003|3023799007; X-Microsoft-Antispam-Message-Info: YDAZEvN83ThzVdgyn/B/OfCDc9JHqOiU4TAjASm3OyDPr0Rf7dp9VePLLLhWeWEhadDOdZH62Mlv2k+uAqIvMVgk1RcvRtHl6+4bckmxfcR0Q0hn6cx++HehX3AyrPefxmYzcajsVXwtOPSME01NNSxtQlXlgsUY4aGtBmSWlFMx+ty/LcwCa167eqZH4RKU6wlVhDxZzVgek6czYanT1P0/0DLsQcrcfo26oX0mBooq84CscIItmzBuOhK1FGbKjyxArMuv1JkNfGwxiK0Bgvyqn2d9rI7sqbZdB56InZV7jrv82uI5lCK2mhpu+qvMrAZlpARBuooeBJE5WlhD7P4pIBABvxI1NDCVW5kR8kngBVw48wNyj1+LmC6R5YaFwEO1IwYxagB/LMFIUbNxJVrT5L46lR0Fk0+Nr2xvQ/p4ATabuH17GTh01G0SZegX5rzooPg5iyfezvLQIGhGLjVarmqJ4oOw5ctq5Do6OP9Qhb1NcNCgf3v326igHRa0h2ktBRFOsm1AT8b86f2Hoo/fuxsT5E2J83hJnqnelTKQNHHn3A/ii4ucfa6LqItb2LjpbeZLUqRhzwWjTcgL/MNNa8lyCOHfMopftGdYrPI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(261026121527099003)(56012099006)(261022075727099003)(261021121427099003)(261022105027099003)(261009223027099003)(10067099003)(22082099003)(18002099003)(6133799003)(261026140227099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?oFcp4LKlj0BnWzPHwgBhPNTnJ/EHXxZwLbOfgeabmTEZ64PCinnLHtpLBNEx?= =?us-ascii?Q?CXb0/qf+7jqmu4sfZnIwFVVo4aSXr1vXSgiKruS8jWWl/MJnWpS5C1wixYDe?= =?us-ascii?Q?BvHoH4gmCPDDfBnIOZtliIz1oTbKtX2pxFy6dxejxOKBC1xlUMZNgtXhZxtL?= =?us-ascii?Q?ARA0dfzTXHc8XcORg/McxaNHXe4mqM184YyqB/HByBzT1zBjA6JfGvpwbgds?= =?us-ascii?Q?i4iCdAIdgV2+HaBwW5eSvNa3DKjD/ZSaPVMFUobUdYJR1Fu/43icYolyjrdc?= =?us-ascii?Q?p5tvMhCi29dgjPY68skenuLgqdPbVlVxfXEswoz07P8xuIGbT2khH34cg6P7?= =?us-ascii?Q?iwIDMjlovcxckqHjG2aPrEVjfrVI5Edv8O9ZqFRrzmnKUt7XRfxfWmMFW+ek?= =?us-ascii?Q?Y1Y24PuNTzUBuNtvLGd54d2+nV9SRgSo++vbKHiY6zxjwhGGc5DjkWn5v27v?= =?us-ascii?Q?ee6ADVbU+ygUxCZTNv12TswItH8MtN2gzz4Md5h+40MNxTB5KW2Wjh0S9Bu8?= =?us-ascii?Q?9+yU1EIofXwpAJYzpN6QbNMqgfjcog6rc2+VlaZtgx6Jlz4hBquVu79qQPqT?= =?us-ascii?Q?156YtO5EqU3aNN+4p04YI1iT5CId3OdLL4AznT2/s3LMafmkAbCpJK3FW92G?= =?us-ascii?Q?b5OVlyQMRSjRqHQ+3tQfJiPDixuu0aJFka6FciPeUQsjZ3PnaScy78XAauiY?= =?us-ascii?Q?McJC09NKnsY65clRDqa1dXMMjjGmHmJn5ef/dv5rrs13KX3Oym9p2xvE/ybB?= =?us-ascii?Q?XrQH+KT826gzyp+Xf2Q4tFHjjJwYFvtEloxoSnq53EEfGoh/+7AqEbagYcX4?= =?us-ascii?Q?V6VduVnltgyImp4qkoh6YYRQUfzn9BC2thSNckblhZ7dSKxfB3UGQS/vzqon?= =?us-ascii?Q?Ngqjiv8kGbBCx8nDWFZXYyNfux0D850r6E/V4RpzUt1NGRNSpWYL1bl/PbKr?= =?us-ascii?Q?DMi0YaGPSCR5EjLnEOv0ul3/C5g4V7KoMDSYP6nGASFu35855YkUPDc9zSKY?= =?us-ascii?Q?K6uEi1ky0l51ZhH9UJ3MW2sTAaxOBhxb8BfpsupQURf8USIpGd4tXMyA0T24?= =?us-ascii?Q?eshT577dNJM4dDoZ0+Nnf4k+1wUTou+/BqmdbtBGQxq1pBuWMtTloDfBfJr7?= =?us-ascii?Q?NmehqGQSzqXkc7Fwqe5uMtd+Ww9jXHWzJyP4zs+9YeaZfD7Z8v5P4nT0kds1?= =?us-ascii?Q?qSM3NvE/xBk67ETwApwgiXCK3GdyxKiekfnZJ+wHimYdtXbruyajlySYqwIt?= =?us-ascii?Q?Cvzft6rJcjs1Z0ObZgpTb6jNdcw9zriINxq/vXNUGkqHmcjF2elJU3daXoPW?= =?us-ascii?Q?V/c5LKXGqszJw5Vu2bYofPUWbq74TfKZp6eKlI2PMDkVfGG19AP3Ic4GCFEY?= =?us-ascii?Q?oOFBlEdaUplB3Bh40LoqjoIEe4q8b+qwsB/9ZSGJq9jEr7jbM7mN6jxGXPs/?= =?us-ascii?Q?XVeNr874LeH9jL0dfBND0elSo0teVwSjipQ3sNw2/qCjSkG/71yl3swiVT+s?= =?us-ascii?Q?Y0FP7saflcIobCHnUK2/SG2+fvIOKeulnzmdaxc/RYTIoZQYCsghfRhhdwE/?= =?us-ascii?Q?e8aS81FBDDxTlDVwzO/gqhaQSCc0VnTVUp7jCHWlxY0CRKtI8Nbk3wuI5uPc?= =?us-ascii?Q?jQbs/vdU6L8qIuoZuoaRq04O9nXX/+Zgeueb+dWfowxKcouzRAw3gxGhVrtf?= =?us-ascii?Q?nikqn2alRr10PuE1GHn03HyaSfZTh1tds67KxfuuZCTkCTTuPA+49ml7b7nZ?= =?us-ascii?Q?PX2dVXUD3w=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: ade18ff2-38a8-4e69-e434-08df33e40e2d X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 04:37:49.4180 (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: fHKAiIR5GOceDhYWhw4HT8iOZvLReThFcSBPso7yV1miunLmE7tWDyqtaZ/WrSA10cuZzcbuszwT6v7UCgRpTw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSCP286MB5196 X-purgate-ID: tlsNG-d62444/1793075876-C495A757-36BC20BF/0/0 X-purgate-type: clean X-purgate-size: 3075 Hi Andrew! On Mon, 26 Oct 2026 09:29:04 +0000, Andrew Cooper wrote: >On 23/10/2026 5:48 am, Ryo Takakura wrote: >> # Configuration >> In addition to Livepatch and HypFS: >> >> CONFIG_LIVEPATCH=y >> CONFIG_HYPFS=y >> >> Enable the following configs: >> >> CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY=y >> or >> CONFIG_X86_PATCHABLE_FUNCTION_ENTRY=y >> >> CONFIG_LIVEPATCH_TRACER=y > > >This ends up having two almost-identical symbols, depending on >architecture, where really this is a common piece of functionality. It >also conflates several different tasks. Thank you for the feedback in detail. It was very helpful. The suggested config layout makes much more sense. >I think what you want is something like this: > >In xen/Kconfig, create CC_HAS_PATCHABLE_FUNCTION_ENTRY which performs >the $(cc-option,-fpatchable-function-entry=0,0) check. Understood. >You are also going to need a GCC_PATCHABLE_FUNCTION_ENTRY_BROKEN symbol, >because of https://godbolt.org/z/sde4faxaz. See the ASM_GOTO_OUTPUT for >another example of this pattern. Just use a plain version check rather >than tying it to XEN_IBT; this is a new feature and people wanting to >use it can use a new enough compiler, and it avoids variability >depending on other options. I didn't know about the compiler behaviour. Thank you for the detail. I'll make sure to check the acceptable compiler version and add a version check as you suggest. >You also want a HAS_PATCHABLE_FUNCTION_ENTRY in xen/common/Kconfig, >which you select from the main config x86/ARM/etc in each patch where >you add the architecture support. Understood. >You want the single visible entry LIVEPATCH_TRACER which depends on >HAS_PATCHABLE_FUNCTION_ENTRY and CC_HAS_PATCHABLE_FUNCTION_ENTRY. You >want to make the text architecture-neutral. Instead of the exact number >of NOPs, just say "reserves space" which will be entirely fine; the >target audience for Kconfig text is sysadmins/distro integrators, not >developers. Understood. And I'll revise the feature description as well. >Finally, you want PATCHABLE_FUNCTION_ENTRY which is selected by >LIVEPATCH_TRACER, which triggers the Makefile changes. Understood. >As a general note, you don't need "default n" lines in Kconfig. That is >the default. I see. I'll make sure to remove them. >All together, this separates "can the compiler do it?" from "does the >user want it?" from "what to do when the user wants it". Understood! I'll make those changes in the next version. >Separately, you have a number of MISRA violations which you're >introducing in your series. I see you've got cf_check, which suggests >you have built in GitlabCI. Have you also run Eclair? Thank you for pointing this out. My apologies for the violations. I wasn't aware of the tests and haven't run either of them. I added the cf_check following the existing code that I referred to when preparing this series. I'll make sure to run those tests before sending next version. Sincerely, Ryo Takakura From xen-devel-bounces@lists.xenproject.org Tue Oct 27 06:17:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 06:17:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461804.1672840 (Exim 4.92) (envelope-from ) id 1xLaUY-0007ud-Og; Tue, 27 Oct 2026 06:17:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461804.1672840; Tue, 27 Oct 2026 06: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 1xLaUY-0007uW-Lc; Tue, 27 Oct 2026 06:17:02 +0000 Received: by outflank-mailman (input) for mailman id 1461804; Tue, 27 Oct 2026 03:19:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLXiT-0007I4-2h for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 03:19:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLXiS-004yKJ-1r for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 04:19:12 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae017c0-e002-0a2a0a5209dd-0a2a4509b8d8-46 for ; Tue, 27 Oct 2026 04:19:12 +0100 Received: from [209.85.214.173] (helo=mail-pl1-f173.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0182e-be1a-0a2a45090019-d155d6adc4a8-3 for ; Tue, 27 Oct 2026 04:19:11 +0100 Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2e5fb79ce82so23269635ad.0 for ; Mon, 26 Oct 2026 20:19:11 -0700 (PDT) Received: from visitorckw-work01.c.googlers.com.com (55.11.81.34.bc.googleusercontent.com. [34.81.11.55]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2eae6c3b67bsm2337455ad.52.2026.10.26.20.19.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2026 20:19: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:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1793071150; x=1793675950; 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=S5gJzH23fh/nKBiSObpCi+vZMP2u0y30tbWtykkO/f4=; b=b3Fy06htmGpGrQJTOO14irawXGNSrHV159EiSegHgpzICpeja8Okc5+oa5+WMUlTRY hty6IDCGfmmSiUGg81rE1Q91oIUIX9cOle9ypJNPGpegyrEN/ytZj0WzLUdIQK0hlYb3 1F8Mq866dP9TAAi2wPTrDpin5lWuhayai6M7AjiIBsOm6BrAS6agW+qnnOvSGOHpEBfT mIjoPBLUCYL3wFqO26S8pkKWhNr6wM//MONZ9hcQvu8UcWzHWWpVdJgclSxYsw9l9LWI GRbKspbs2DwwD6LfYkgBAuuR3FT0V8utALW7VcwmTYGpM8fOQ6DJJzEQ6fagd0Qzw9T2 7mPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793071150; x=1793675950; 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=S5gJzH23fh/nKBiSObpCi+vZMP2u0y30tbWtykkO/f4=; b=kK8WTpQRiZdtQzdVm4xted+77NhgUNFok4IrELfeqK+wzKiLEcTpbhuMPHvK47j4Em rTJZiuDMYCWVXIipRPqTcdyvo7hloi6kNYiGbxs5QwL1dhTJtMcXwmRHmYJAM4xUtxu3 wC5om6QmDGDP8oDIOcnRVZ/o3g7H+Hxe4YuN798zr6pplYO0y/Cjf+8U45cyr5iTgkoo o9sxysL6/u2aPKsWDM+l5YLn85L1cuCWsaZ6dVkTrRpKUCkl2AEOOeFDI+dLncqByHkS nTL+gvXH4Ae+urUPuro9cxm6/lo/uxjtvmM78ba/5ACkAKBWXT9G032O78MhG0pO6Xep vK7A== X-Gm-Message-State: AFq9FYI8Tb42sFROM2q+xK+zyJUYOk457rlC4gFbnILrTaTCL5lHT0CP FWUD/EswKcmqnJlESgHkUeoL4VjVUMTHIzM4OA24+o1G4HqCBxIeCQX7tOnzR6+a X-Gm-Gg: AYBFou36ZftvcRamp25pya1uILMx8XdMVfG7aLKz8HZC3oJIjB94GGqFO9uJ8SJFkit fqxczMcttsZoo4p6I8yY7tsZ0IeAdOll4O5wVVFqgqjwPHam60dCDvmeQUxvbp+WCVWbFlHw/5U kLty53R/8IaFWTSqzmxUwqTYx0CXoMWMnhZBDApjJb7vitiFj2d4viSWq7w9flxFad8W2xE8jlA UNXNYFHxO2naedKODnuCRUEPHzofeR1P1oKL/DO3TpxyMmetgczrKxIFFYldwHjPkS6/qMebg8W oBSkfg5XecZ+x4sJYpbnpS66MNjxbZKTaDuWQp4v2kkSyJ3sYPjc5WYZ2h4VQjYt9EX3Zb8VUAx BCg3cHMfj3omwQf0SLeE7Qf3f43fYXZG7XqiwoEeMRkdd4tIvY7IFnmDEBRRhAqgqAyXD58Z1xH NqyYkbB7FdNyclwFAyuVT0AnHtNIVDQHlmF3P8j7AreJlIVusFXTaPef3bHt8e0yGEJ5uaVTLrY 5JtRs9DVFYrWJkrDbAjjB2hywRXSxMv137hin2q4nHaXP7yW85Ui335xbkwYzQW3D0FplGn4Oyy ixBP+1A/OXizj+jsr5iafXyU2VLFxaZFky5agVInTk3NAmlIkg== X-Received: by 2002:a17:902:da85:b0:2ea:71a7:7f21 with SMTP id d9443c01a7336-2ea9c6c245fmr67368925ad.13.1793071149905; Mon, 26 Oct 2026 20:19:09 -0700 (PDT) From: Kuan-Wei Chiu To: xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, marscheng@google.com, jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com, Kuan-Wei Chiu Subject: [PATCH] xen/dt: Only parse direct child nodes of /reserved-memory Date: Tue, 27 Oct 2026 03:18:55 +0000 Message-ID: <20261027031855.2671912-1-visitorckw@gmail.com> X-Mailer: git-send-email 2.56.0.307.g5fe7bd680c-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1793071152-3A4DB034-815C6872/0/0 X-purgate-type: clean X-purgate-size: 1663 process_reserved_memory() uses device_tree_for_each_node(), which walks all descendants of /reserved-memory rather than just its direct children. However, a child node such as nvmem-rmem can contain nvmem-layout and cell subnodes whose reg properties specify internal offsets rather than physical memory addresses. Parsing these subnodes records invalid reserved memory regions and fails the overlap check when bitfield cells share the same offset. Ignore nodes with depth != 1 in process_reserved_memory_node(). Fixes: d96594eef39a ("xen/arm: keep track of reserved-memory regions") Signed-off-by: Kuan-Wei Chiu --- xen/common/device-tree/bootinfo-fdt.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c index ca64daf4cd..eea35325f7 100644 --- a/xen/common/device-tree/bootinfo-fdt.c +++ b/xen/common/device-tree/bootinfo-fdt.c @@ -185,8 +185,13 @@ static int __init process_reserved_memory_node(const void *fdt, int node, u32 size_cells, void *data) { - int rc = process_memory_node(fdt, node, name, depth, address_cells, - size_cells, data); + int rc; + + if ( depth != 1 ) + return 0; + + rc = process_memory_node(fdt, node, name, depth, address_cells, + size_cells, data); if ( rc == -ENOSPC ) panic("Max number of supported reserved-memory regions reached.\n"); -- 2.56.0.307.g5fe7bd680c-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 07:07:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 07:07:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461847.1672850 (Exim 4.92) (envelope-from ) id 1xLbGs-0006T2-Ad; Tue, 27 Oct 2026 07:06:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461847.1672850; Tue, 27 Oct 2026 07:06: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 1xLbGs-0006Sv-7h; Tue, 27 Oct 2026 07:06:58 +0000 Received: by outflank-mailman (input) for mailman id 1461847; Tue, 27 Oct 2026 07:06:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLbGq-0006Sp-LM for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 07:06:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLbGp-002xYi-NX for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:06:55 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae04d8c-8faa-0a2a0a5109dd-0a2a450cda1a-18 for ; Tue, 27 Oct 2026 08:06:55 +0100 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae04d8f-f479-0a2a450c0019-d1558036d88a-3 for ; Tue, 27 Oct 2026 08:06:55 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a210470b49so30660725e9.2 for ; Tue, 27 Oct 2026 00:06: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 ffacd0b85a97d-48e3ebc3cfasm21004237f8f.17.2026.10.27.00.06.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 00:06: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=1793084815; x=1793689615; 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=UBRrLU2xKYMZIrbRSHA32mAmR8fDYQPg/bOWs1ci48w=; b=LQ6E8snBx6Z/YGh5TlAeEPrWrrWHJS1mHu99l9IuxDJ1c6I+dqjyrfUdclM8JoifHk XHXDS32XCxVFwXz+z8RwXFsXSsc0skZXLMPtsvI7mwbCE174/G2bwKqi6AzQCx1SKpDE QSZQ9dewQHXKkYyMFTP/wUsOhF3Jt5wJCAVAccI6YucVbYJ26ayhydii3xUP8t/Dq413 nqx4ih5yZNsuQ4LdQyaBPPueQAg3qKNhNYGhMtxn/lGq19+87gFslztEB9CXn1CSkhps 7t0XZaZaoVCwm61YPh5jOaRLr4yBqn4TO5jbKQ3rbCOMmHY8GVm2adaE+oHHFVYgG0T/ Pp5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793084815; x=1793689615; 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=UBRrLU2xKYMZIrbRSHA32mAmR8fDYQPg/bOWs1ci48w=; b=pBxXHph+tEKsVDx9qfBziijJ28AlOLe+wrLct1EIYNlSfzxRs4pE4RLzUdT5xo6lb3 H+iizAgtiCaSWrv04RxTjvu05EPBMqYl1idTYB3E6oDi3i3tPWVdOiYiaQtDNjxehRvm bu9UHDiEUZj54RIObOscHtAr5qOLjs4P34SUodDJSd9ceoMabSW0PLQdUeLD69FavKSs WmM7zLcLpiWPK4bW71lne/IA1oOion/Pnz0Xv1Iwg4PzhFy3q4ZMihCVHJku36NuIyV7 ubn/pIG/yC+Y/mUeRWIZM5M4NZMDpC0U4VFAgZbwT0yufaqXsiansM3GOf0ES/0DYMZ9 n7ug== X-Gm-Message-State: AFq9FYJrPwWhJQ+T/ANIs/WK9NnHX2+xY0Y4VINeJ0/RMHajJsaGnLwg TMx1IJek4XIB/QAOcr5AwKDjvV4E3yl7+GJgPLf1CDSM9swUfbkH7UVCmH6YpXZjer+CNeQ+G/V ZC0pvUA== X-Gm-Gg: AYBFou12xD5qP3/PXKsE60b0FVdyOeNUskXhuR48eYAuWoIyVGloqEGSyiZVZSB+n7Z P5XMphRqw2woyvTTuKX1gH0PogyQvrf9lQ3sCbYXlFaH31pjOENoHQEgDKuHchLcWC62ae7LeWc L7/5+FSmcMdCXyQW3vEDAFyzkgUuzbo9kwxkdV40Vv8eiqJ9L0GCi/b1edJbRV7raTSw4dQ99vQ jQqzfmAaCtWZLawXG0LJLTrGPf5lYgXmfvExMPLvAPHLdzqNCc4/Qc7y3vObBHrLVBgGVl0+kxc m7yv1F6H3hjnFCnfimqPEOd6vyXdLq6osWGBsU3b7t/PnnFRLExbvBNVU4Au2NeyYNxA8OARapH IZ4OxKvCqH1jN6ewQAVP7q5cTqi55YgRyxsnZS852YIENiG3jw7Ahb/BL1fQ8dwVp96ElaYG2wv NHkWizdxQEATMrFUNImIOGjymzzpgMOdWt3jVSNsZ9e3UFolEccOwS7zDCgu9+A8lify8dh5aD5 ANUAvMDIfioPXIzT8p617QianC1J+yTdY0Eg1GYRsGr9f+9nVLim6qWUY8Jr79Hkrb4AAcdWaHN fwyk6hTe9es3rTmL2wXYNSGnYcetFJIW/XZrj1Fs5jVzsEVPlwo71hBJ/WN+IvemQQ== X-Received: by 2002:a05:600d:14:b0:4a4:6fdb:cc42 with SMTP id 5b1f17b1804b1-4a46fdbcc53mr113293195e9.11.1793084814989; Tue, 27 Oct 2026 00:06:54 -0700 (PDT) Message-ID: <3dd54a18-a731-4c08-b848-8de6d620e406@suse.com> Date: Tue, 27 Oct 2026 08:06:53 +0100 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?= , Yehyeong Lee From: Jan Beulich Subject: [PATCH] x86/mm: special-case IOMMU (un)mapping failure path in _get_page_type() Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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: 8bit X-purgate-ID: tlsNG-d25034/1793084815-02ADCA5B-4D12D225/10/78276251493 X-purgate-type: spam X-purgate-size: 2727 The error path put in place to address XSA-291 was broken by the re-work done for XSA-299: With PTF_partial_set not passed in (since PGT_partial is clear for a page undergoing a type change) and the page not having PGT_validated set just yet, _put_page_type() would fail its consistency check for non-dying domains. Introduce yet another flag to indicate use of the function from _get_page_type()'s recovery path. Fixes: c40b33d72630 ("x86/mm: Don't drop a type ref unless you held a ref to begin with") Reported-by: Yehyeong Lee Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1088,6 +1088,7 @@ get_page_from_l1e( * more information. */ #define PTF_partial_set (1 << 0) +#define PTF_recovery (1 << 1) #define PTF_preemptible (1 << 2) #define PTF_defer (1 << 3) #define PTF_retain_ref_on_restart (1 << 4) @@ -2812,15 +2813,21 @@ static int _put_page_type(struct page_in * *not* fully validated, continuing would almost certainly * open up a security hole. An exception to this is during * domain destruction, where PGT_validated can be dropped - * without dropping a type ref. + * without dropping a type ref. Another exception is on error + * paths from _get_page_type(), where the type ref was already + * put in place, but PGT_validated isn't set yet (page + * validation still pending). * - * If the latter, do nothing unless type PGT_partial is set. - * If it is set, the type count must be 1. + * In the domain destruction case, do nothing unless PGT_partial + * is set. If it is set, the type count must be 1. + * + * In the _get_page_type() error path case operate normally, + * again also including the type count sanity check. */ - if ( !(flags & PTF_partial_set) ) + if ( !(flags & (PTF_partial_set | PTF_recovery)) ) BUG_ON((x & PGT_partial) || !((x & PGT_validated) || page_get_owner(page)->is_dying)); - else if ( !(x & PGT_partial) ) + else if ( (flags & PTF_partial_set) && !(x & PGT_partial) ) return 0; else BUG_ON((x & PGT_count_mask) != 1); @@ -3097,7 +3104,7 @@ static int _get_page_type(struct page_in if ( unlikely(rc) ) { - _put_page_type(page, 0, NULL); + _put_page_type(page, PTF_recovery, NULL); goto out; } } From xen-devel-bounces@lists.xenproject.org Tue Oct 27 07:16:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 07:16:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461854.1672859 (Exim 4.92) (envelope-from ) id 1xLbPm-0008Cv-4H; Tue, 27 Oct 2026 07:16:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461854.1672859; Tue, 27 Oct 2026 07:16: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 1xLbPm-0008Co-1I; Tue, 27 Oct 2026 07:16:10 +0000 Received: by outflank-mailman (input) for mailman id 1461854; Tue, 27 Oct 2026 07:16:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLbPk-0008Ci-Ot for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 07:16:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLbPj-009JWF-Tl for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:16:07 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae04f9a-bab6-0a2a0a5309dd-0a2a4509c80e-34 for ; Tue, 27 Oct 2026 08:16:07 +0100 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 6ae04fb1-be1a-0a2a45090019-d1558030d848-3 for ; Tue, 27 Oct 2026 08:16:01 +0100 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a210470b49so30719305e9.2 for ; Tue, 27 Oct 2026 00:16: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-4a35a2d9280sm243047375e9.13.2026.10.27.00.16.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 00:16: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=1793085361; x=1793690161; 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=Uewbo8Z2JjHZoFIUBtycp8zjmlIrt0H3keDQ45XzbCo=; b=BxptJ1uJH8QFABpkJJeQIXtbMSGTUznXubZp5i1jur8NlhEPoWCc/l/SdYiags8Cjj w1vl/l/lbhlXOfchkVA32xTiNMaOwq3SFAsX19KmuJEQZIhzQLOhVnXom5otbfu4jhh/ DG435RL7h9tjPTecvSQalELy18XRgfLIQTRFpG4GM71jFRN3zwef4XwVUVHpvDz9rjya 5CLaRDCs+Y/6w6jWFMx0h2NRMHDAexfLRXvfX5V5L3ExrFJ4AOZ12aZT8XUCNULQrIyd 2rFH1TJi6di5+aIqH1rBd/gzUKkANHuI6adE08+snr5mb4C+8CHZZ0N841gJSbt/2Fbf f3kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793085361; x=1793690161; 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=Uewbo8Z2JjHZoFIUBtycp8zjmlIrt0H3keDQ45XzbCo=; b=i+CM2FdepYgnRq0Pdpr5NkFxngr1e0FgChiMZ3gfUptScsI6vRmMxglnlrtYGjuGpk 9qaVf5oOpZMKpClWZtHYOicyVuzYfR1ssUWs68P55KWn+77fAX3Oi6Dus8GWX+/lbLAs wMEZRD96sGWFXSUlKLyQdggchanmCdOuyTl7rTxNBtDf0ckVCOb5xcAibUg4pIfWAhm7 kPHYONkB7+J8vpO6l5caR+90FkyQDLHDnW3w/mv+lngd+zaa5u0AFcWdvrRsC0drD8jO 343qSgMzGstjfBp9MJHl1RdVUhaxL5JmXdDkd9mKPCcmeg1C2SHMCVrgV40BErLb7qgj vOeQ== X-Forwarded-Encrypted: i=1; AKwUvBxyI+LCR8x6r4MBBvPxqBfMlfQE3/gdbvqsTKYpJsk2CPXeTdkK51+gwCITPsIBp2Ec86+qE9jE5kQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYIQ70jgH1vsd85DwfJGmtgOHZAVZinye0iI5ft+RCQaGLsulN0X KVH326ulyo9kmzcFbsXAdASZ6WwWIUdFJGNBiQI37wf4m18laarB8vx5Nd/MS/kN1w== X-Gm-Gg: AYBFou00HY84u2u180eMozUc/dwNVB7XKwQwmxykaHroSCezQUevD9MV14LecmMtF71 6UN+QV2hAv/HY+kEDnX6AUfZx7WRY/YAxBpBSIhf3SiQDwemq2zzUSzClscThgbKw3gIC5CV6W3 /nNyQ7TOmHXpiyC580oaJqOfClc4tq2BmmC/sf9Lt19VeCYHkOQrOJ6zTTrhaqgsyLh2l0yzRyj Ep8W+X1WkARw1N+QKKI10HPYYDoGGckVj/e+i7GJvIitI1T9CYQxNaYmUhGQ3tfwpkEmB6YkBGj Zd/hTcKwdm/xv9KOqlDTXddXLyt2F8hcQMvjIrZKXh6k0cH1pCYQWzRqj5OytMBSRwgVtP0qHkO Kj/rWzXOT92MnguS1PP3//ixp5sxv25qEXu/d0S0DZt8u1M/Bz75Mt+N8cUgWlafS9S81KUWAPT bGT3mv59Y8aEkoDe5+z7V/gJQ7fQG9RXRkmiDo0PSGG9RdsoUcD+RftAEZcX9RlzJMgVsg/GJNE tS51jPFcwrsYtooF5bt4wNuw6SJyj6GaWkcx2+kdWdjkUOF/oD7kgDnK02uq/GdRSfnEhzuHl+Z 1BwrcpVpMOkB4vpB78GHez4aKbO64RpZCFBcfFIZygk= X-Received: by 2002:a05:600c:4f55:b0:4a2:a9:ed5a with SMTP id 5b1f17b1804b1-4a35ac9a6d5mr185685095e9.8.1793085361241; Tue, 27 Oct 2026 00:16:01 -0700 (PDT) Message-ID: <9c9bf7aa-1c8b-42ab-85c7-ad87464d3cb4@suse.com> Date: Tue, 27 Oct 2026 08:16:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] xen/page_alloc: scrub each page in unprepare_staticmem_pages To: peter kang Cc: anderson.choi@boeing.com, matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com, 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-bad1c0/1793085361-BDCC7034-421FE9BF/10/78276251493 X-purgate-type: spam X-purgate-size: 901 On 27.10.2026 05:25, peter kang wrote: > From: Peter Kang > > unprepare_staticmem_pages() can unprepare multiple pages in a static > memory range. When need_scrub is true, each page must be scrubbed > before it is marked static. > > The loop currently passes the base pointer pg to scrub_one_page() on > every iteration. For a multi-page range, this repeatedly scrubs page 0 > and leaves the remaining pages unscrubbed, so a guest can later read > stale data from pages 1..nr_mfns-1 of a static or static-shared bank. > > Pass &pg[i] to scrub_one_page() so each iteration scrubs the page it > is processing. This ensures every page in the range is scrubbed before > it is marked static. > > Fixes: 4a9e73e6e53e ("xen/arm: static memory initialization") > Signed-off-by: Peter Kang Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Oct 27 07:27:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 07:27:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461861.1672868 (Exim 4.92) (envelope-from ) id 1xLbaH-0001aE-11; Tue, 27 Oct 2026 07:27:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461861.1672868; Tue, 27 Oct 2026 07:27: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 1xLbaG-0001a7-Ua; Tue, 27 Oct 2026 07:27:00 +0000 Received: by outflank-mailman (input) for mailman id 1461861; Tue, 27 Oct 2026 07:27:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLbaG-0001a1-4D for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 07:27:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLbaD-005Uww-MX for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:26:57 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae05228-e002-0a2a0a5209dd-0a2a45038950-36 for ; Tue, 27 Oct 2026 08:26:57 +0100 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae05241-fae8-0a2a45030019-a237832feae4-3 for ; Tue, 27 Oct 2026 08:26:57 +0100 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 6C1BB4EE022E; Tue, 27 Oct 2026 08:26:56 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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=1793086017; b=g5f7x+TBNmTgFgY4bdNTIW4kYjto59SPZXdvH9j+ZeWTAym4n1GU2vNmmnwZI4G8uFd+ rSAMAKLslnmk5IY49s4XTKYghOY09c49zD/S4qP+XfiV1WLmxrqa4TDC/Sq10hF49sO9G MNO6eaKS2TPAworOHwOymUigr7mdxQTy9GhI2wZISOK+3x3XpHlNI7IRRrZaARpWGaJnm WRqn4pEkknuRzgomFkA8Jmk9iFqYcY63h5SwOCav0T03xHufRU4/U5pXQpCU2jHudyKCc vvh0RxJwdaxNFEv/x/7zW3BSfvQLZR8Tq33ZW0Ja3gFwMG7mae2zy3PSrir0x+oGGJdt3 wFko8by6N74vvBuEMsTAuoAHTyrTZK8798nCIvtOCdkxS15E9W2LNKLfeJfq0XLZDz0HH Ux5Mu80WT5Z7l8HO4xcbb8klbmDyXM8tfJpavPtQgVaZFjkfmo59JaYl0eoEBbzchecsi l//M/afnpCn5A384ZTpWXhDY+Rn1QJVlYrBXWXbKSjFhneTymINx864k0oC1f/8gWSo2f 4CKx0N6DpWhcqPZuQkfL4lQxWeu9YL5mhRemJv7PynZYzGXt66vFMx3hHU0TkA5MOldfs XJePDQs2fnBekeQR3sYoVY2GtxTlM+X6Tys2/iqKumORrxEI+FbLvgbVwEtfSH8= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1793086017; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=nE5ezc6sMX5qgETh/sc+Htd7hJpEx+RLXPTxbs7ktBI=; b=4LjDyEkhSvoZtSyd3E+VKdu5dMPLcXRfEnfUa9re3cnQ2mJcmyMN1vl0xsWkmuyxV625 l36I+FyjsljuKSTYwoq71T6LHsJseH9nrGUB2rpTltAhJceDouuL2rOzCG1NwHq83z1PB f8hJvR2MHyCjV+wgxbJ2soF7YYpHsF87OHlPWC1mUlQXwEmIViINVZiF0A1KEIXub9y9u HYdGi9OaMui/njdn7NR87XrFH8wuvPSncZhxHL3eWuDOdUIrKfnNa+lE3gNXW+OqRaBd6 FLP8v2d21juTKky1/swptzqCbthV+zyhtoeOdxVdTDvV3Dah44ZMJC5z9RhmqgEAtg6vJ 5fujOUj2KJsAdjjbvxY7xUY2ekUWgrWcSNsBBFJdmalTpjUUjyaeeKiwLT9nbshUd6PfZ CZFeaya5y+bYy6xBtDwI7DsD6eCdjuqslYxPL6JsGYdIrMk2IvX9SKdffDpBF+1AYXkcj u+SXKahxDmNYIodvNEOLb/XkW+J75z6WGOf7HNAcSsU/VU2vxmmrRBTrXKPTtZcoRa+Ay LozEAq1VAZ1QZt+fy1xxVI22Q6AUwL/Z8vtPQ+ebVtmGJdN7eA7ORdP8AtF0rjM2VVGS3 lZWM9dbJBiU56xJKOv8lZFcEPUtxcG6ytu1WYQ5APZ9pin9Roi7UJ1Ovz32/3oU= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 27 Oct 2026 08:26:56 +0100 From: Nicola Vetrini To: Dmytro Prokopchuk1 Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3] automation/eclair: generalize the noreturn function-pointer deviation In-Reply-To: References: 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-33051d/1793086017-6CEDA4E9-4B343F01/0/0 X-purgate-type: clean X-purgate-size: 5428 On 2026-10-19 10:51, Dmytro Prokopchuk1 wrote: > The R11.1 safe cast only matched void noreturn (*)(void *). Accept a > conversion where noreturn is omitted and the signature is otherwise > compatible. canonical() covers typeof destinations, and > compatible_deep_unqualified keeps the parameter and return types > aligned. > > Discarding noreturn does not change the calling convention. Code after > the call is unreachable when every possible callee is noreturn. Leaving > that code in place is a tolerated Rule 2.1 violation. The full > rationale > is in docs/misra/deviations.rst. > > Signed-off-by: Dmytro Prokopchuk Acked-by: Nicola Vetrini # automation/eclair_analysis/.* > --- > Changes in v3: > - Reworded the deviation text per Jan's review: "noreturn omitted but > an > otherwise compatible signature", "all of the possible callees", and a > tolerated Rule 2.1 violation > - rules.rst: use '(void *)' spelling > > Changes in v2: > - do not claim that discarding noreturn leaves compiler behavior > unchanged > - write that code after the call is unreachable, and that Xen's > behavior > is the same (whether the compiler deletes that code or leaves it) > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +++++---- > docs/misra/deviations.rst | 12 ++++++++---- > docs/misra/rules.rst | 8 +++++--- > 3 files changed, 18 insertions(+), 11 deletions(-) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl > b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 6cdb10a129..c7a800c62f 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -394,11 +394,12 @@ constant expressions are required.\"" > } > -doc_end > > --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void > (*)(void *)' is safe > -because the semantics of the 'noreturn' attribute do not alter the > calling convention or behavior of the resulting code." > +-doc_begin="The conversion from a noreturn function pointer to a > function > +pointer with noreturn omitted but an otherwise compatible signature > does > +not alter the calling convention." > -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(canonical(__function_pointer_types)))&&from(expr(skip(!syntactic(), > + ref(property(noreturn)))))&&relation(compatible_deep_unqualified)"} > -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." > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 6bcc2adf95..76be6b3251 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -392,10 +392,14 @@ Deviations related to MISRA C:2012 Rules: > - Tagged as `safe` for ECLAIR. > > * - R11.1 > - - 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, parameters > handling remain > - consistent. > + - The conversion from a noreturn function pointer to a function > pointer > + with noreturn omitted but an otherwise compatible signature > does not > + alter the calling convention. The callee does not return, so > code > + following a call through the resulting pointer is unreachable. > The > + compiler may delete that unreachable code when it can see that > all > + of the possible callees are noreturn, or it may leave the code > in > + place. Xen's behavior is the same in either case. Code left in > place > + is a tolerated violation of Rule 2.1. > - Tagged as `safe` for ECLAIR. > > * - R11.2 > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index a59cf1782e..5f9fe4c860 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -435,9 +435,11 @@ maintainers if you want to suggest a change. > and any other type > - 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. > + and '(void *)' are permitted. Conversions from a noreturn > function > + pointer to a function pointer with noreturn omitted but an > otherwise > + compatible signature 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 Tue Oct 27 07:29:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 07:29:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461870.1672876 (Exim 4.92) (envelope-from ) id 1xLbcP-0002M2-E2; Tue, 27 Oct 2026 07:29:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461870.1672876; Tue, 27 Oct 2026 07: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 1xLbcP-0002Lv-BR; Tue, 27 Oct 2026 07:29:13 +0000 Received: by outflank-mailman (input) for mailman id 1461870; Tue, 27 Oct 2026 07:29:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLbcO-0002Lp-8v for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 07:29:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLbcN-005VVl-MB for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:29:11 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae052ae-8faa-0a2a0a5109dd-0a2a450c8304-46 for ; Tue, 27 Oct 2026 08:29:11 +0100 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae052c7-f479-0a2a450c0019-a237832fe184-3 for ; Tue, 27 Oct 2026 08:29:11 +0100 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 49EB94EE022E; Tue, 27 Oct 2026 08:29:11 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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=1793086151; b=CaYBndRMeLUfa1FbjkCb3WF6y1GMPB4SM5NqR9hl3XlGph1HD7fL06BrJMYiZsFRbmdr ZVgwRJxG9BCpLZNERxopJdigqHnIMZA2sMOHLubwW2ysOKsMluWGiI2pgzbUZmrPfIIG2 ADmUbg8cwfzu5htjXlBUB8j4sdFG4Qe/blPXxMKXXe1fZ3G2tMCs46962MEU819OFYL1p q5miXR5bN0aXxzizTvjmULksDcqGtc+KiCs7P+9sZncJX9phNce698+aKEqduP+SShC4q +STwW/OcYtxA0VEN1mGbh7IMDHWgb+aJv6wAvRlNbTLOYcclXqwOhzZyDRCCNdpMUpA+/ DcvNkkwvTqf8VJtz18GF0cOj2ix3rJtCF88ISpyFFp3FfPzw7+FjXiiM3Az84SqGfyI/n Iq+u24lyZ6UfPrl+EigKdl8OaL1VycdrPKtGD8Rrer5bqKrWfiquYvTCRGqPDLVmRoDTV VnBAdSCiQJYcmA7ty2dHqFPAEBgmmFE8n2UfqOnPvYw1C5VF8rw75MCxHcBts2T/sw6WE EDmzzhzk0VgxQ0pz/UCvagGUaih4/zHQOUpBRNTFUTy9ClDYnyTwRFzsgg+e3Pq1h+gFD wrMWqm192zFIMRyKpolZSESShAHFdJ9DCaoVsBvVALWioUUlcF+60hopm50bHvE= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1793086151; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=JD64DCt70R+8twG03cuSbjIAx9xyVL3Bb+Ti/daCYPE=; b=0um4HkNhIcplWVRaj20+CtHD+8eTYF+zV8qf+SnyXPo+fGKCmh6hz3kchYOgfbj5dur5 JO89QE/tf5lxDwUvSHddrgp5lyZyrgZElsyaHCkOfgoC+8IxlyTzZvDz5oT0PVtitpfwI 3mXSpDSRZSvxX4WzIZBnNCXiLuySA7mUCfYZBn4mzqKF4L5NV05YTAYijkCN9jCerf690 NUjQntwR9FAWKaJveizNwqDUNsvLdKgvn3ECdmkvoXHj4WRMzTLzyjeW+aIRvuinGUdwE aVkRjzoG/irCMpY16KcZA2kwWtU7sFWTzFgqlkmYN1lHn7Y8fhOtw0a0AWLfVylM6dIXW l+r/+Q68vHsdRxpmQGMMNujjYUfG3JqZMCnPkVtF77OF956D2v/QTTvkSSikHPRt6uuX1 31PGxP9di6lsng7xpZm6nKeLUCdOCJcZ02ZTFz6MdXzVmpvKwEqr9EnGhHY5kfet7Zkt8 fSu9cTWaO/OyHWmJsTl6QYNIz6MSYVZZRo4sima+GiJ0N7iekJZMtvo42fANwVbfQBtNy dlZyXUd5k/ibPp7WHoMvsmO5D1L2i+eehbCaEkqwAvQ5zPlJAWZmTQifMsyOGX8eJMb0i VCOlDv5jzrx9jT3KtT4gfe7RwRP8GEJbLDcxmdoEgRvZKuowXWFCoKXStdILQoo= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 27 Oct 2026 08:29:11 +0100 From: Nicola Vetrini To: Dmytro Prokopchuk1 Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v2] misra: deviate C library-style functions from Misra C:2012 rule 11.8 In-Reply-To: References: Message-ID: <9cef9d25d9c1dc136db0e356db4e98c3@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-d25034/1793086151-776D6A5B-B0FD8E9D/0/0 X-purgate-type: clean X-purgate-size: 4844 On 2026-10-19 12:41, Dmytro Prokopchuk1 wrote: > bsearch(), memchr(), strchr(), strpbrk(), strrchr() and strstr() all > accept a const pointer/object but return a non-const pointer to the > matched element or byte, matching their standard C library interfaces. > The casts in these implementations strip const so that callers > searching > a non-const object get back a mutable pointer. Fixing this would > require > changing the public API, so document these uses as deviations instead. > > Update docs/misra/rules.rst to note that this class of double-use > library functions is deviated on a per-function basis. > > Signed-off-by: Dmytro Prokopchuk Reviewed-by: Nicola Vetrini # automation/eclair_analysis/.* > --- > Changes in v2: > - dropped memchr_inv() from the deviation (not a standard function) > - anchored the file patterns and grouped the xen/lib files, as > suggested by Nicola > - narrowed the justification to the casts in the function bodies > > Link to v1: > https://patchew.org/Xen/4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro._5Fprokopchuk1@epam.com/ > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++ > docs/misra/deviations.rst | 9 +++++++++ > docs/misra/rules.rst | 6 +++++- > 3 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl > b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 6cdb10a129..ed8bad0cb0 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -450,6 +450,14 @@ write or not" > > -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(hvm_guestcopy)&&text(^.*__hvm_copy.*HVMCOPY_to_guest > doesn't modify.*$)))"} > -doc_end > > +-doc_begin="Functions bsearch(), memchr(), strchr(), strpbrk(), > strrchr() and > +strstr() accept a const pointer/object and return a non-const pointer > to the > +matched element or byte, matching their standard C library interfaces. > The > +casts in these implementations strip const so that a search of a > non-const > +object yields a mutable pointer. This use is deemed safe." > +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(^xen/include/xen/bsearch\\.h$||^xen/lib/(memchr|strchr|strpbrk|strrchr|strstr)\\.c$)))"} > +-doc_end > + > -doc_begin="This construct is used to check if the type is scalar, and > for this purpose the use of 0 as a null pointer constant is > deliberate." > -config=MC3A2.R11.9,reports+={deliberate, > "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))" > } > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 6bcc2adf95..68de2d8dd1 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -436,6 +436,15 @@ Deviations related to MISRA C:2012 Rules: > readability. > - Tagged as `safe` for ECLAIR. > > + * - R11.8 > + - Functions bsearch(), memchr(), strchr(), strpbrk(), strrchr() > and > + strstr() accept a const pointer/object and return a non-const > pointer > + to the matched element or byte, matching their standard C > library > + interfaces. The casts in these implementations strip const so > that a > + search of a non-const object yields a mutable pointer. This use > is > + deemed safe. > + - Tagged as `safe` for ECLAIR. > + > * - R11.9 > - __ACCESS_ONCE uses an integer, which happens to be zero, as a > compile time check. The typecheck uses a cast. The usage of > zero or other > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index a59cf1782e..00378c474e 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -473,7 +473,11 @@ maintainers if you want to suggest a change. > * - `Rule 11.8 > `_ > - Required > - A cast shall not remove any const or volatile qualification > from the type pointed to by a pointer > - - > + - Some standard C library-style functions are inherently > double-use, > + accepting a const argument and returning a non-const pointer > into > + it so that callers searching a non-const object get back a > + mutable pointer. The casts that implement this are deviated per > + function. > > * - `Rule 11.9 > `_ > - Required -- 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 Tue Oct 27 07:37:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 07:37:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461876.1672885 (Exim 4.92) (envelope-from ) id 1xLbkS-00049m-5a; Tue, 27 Oct 2026 07:37:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461876.1672885; Tue, 27 Oct 2026 07:37: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 1xLbkS-00049f-2x; Tue, 27 Oct 2026 07:37:32 +0000 Received: by outflank-mailman (input) for mailman id 1461876; Tue, 27 Oct 2026 07:37:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLbkQ-00049Y-Hh for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 07:37:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLbkP-0032jn-N0 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:37:29 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae054b0-bab6-0a2a0a5309dd-0a2a450cea50-24 for ; Tue, 27 Oct 2026 08:37:29 +0100 Received: from [40.107.209.56] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae054b8-f479-0a2a450c0019-286bd1388338-3 for ; Tue, 27 Oct 2026 08:37:29 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) 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.546.22; Tue, 27 Oct 2026 07:37:26 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 07:37: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=LGoQakp2plG52f5GTpgZ9RMznxLvea4Zfo5j0GQGBX2worxtMLxtqeVzxsH5OKf4QetnoTXV7TGrvQ0V4HvdPoNzPcRNdoIFbMYmyOAnYFawf7cBkkJHb2DANcW1rOR0K5C+g48TOjlZ2Drtk6khtg2NrtU9TlXqXlkx1wpjIa+HFfCBEXjbj+Lq2PRSxE+KTNCtCmFxo2EZEJeG7u99CKFkXl+wJ76vr66YNkZeytC2WCoFI9ihSLQY7KCDDf94YpYMQ0pg+NvBTP3k1T4t/akCgU0uOHA2PCAyReIunVSu7/7pk8z6/UAvQ1PZUTy8Ho65lj2XLDSLwMjuPXRAFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8zW+732l9B3YnoxzPySgT67ee/VoumKVrKpfiMot4hk=; b=xs76j4S9mXQkG+T3fw2lpIsMp+0exuBZ74bsozTbReaqQ6Py56wxZ394JZRZivvwdvX3AecARMv6+BfQ0BD3zOJ5J28Ad/UhdgQtYJV2emJziUrj7zKyVBZei532nCmVnIjWM5Q3Q7nJbYl8psItEs7BEZdHNrr7w9+QQIOZa9RaiqQzqCIhmiLNvcQ8cVW7RYn8M2dlr+gf9XSKO3+dDmenwAlCldQw9Pw5hsrCDJjeTI138CfBkvQ11l8d7sQGeQRxgLfbaXr1UnahvkTed8JoxajIeKM3XLH8W7Nginhpe980agAL9w94+jKjxNyziciGJQfKpYnGFV5DYGxLvQ== 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=8zW+732l9B3YnoxzPySgT67ee/VoumKVrKpfiMot4hk=; b=KNdVgEpCuHf2qZEkNuLO5jp5sbwTdU7T/QOlnFZeJjtmifAXvrFhH3CvVn9yqGUokTujVz+qUZuu+bRVxndTLmCybdPLW0imR1gLcmjkPKEtFPc2fdP5mpHGqOBe7roWr90H6xJp5+cdAOrDkW9iXoYRzxCXzzxEFOCYxzr6o88= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: jbeulich@suse.com Cc: andrew.cooper3@citrix.com, chunjie.zhu@citrix.com, jason.andryuk@amd.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org Subject: [PATCH v2] x86/nestedsvm: remove dead code for shadow-paging L1 hosts Date: Tue, 27 Oct 2026 15:37:11 +0800 Message-Id: <20261027073711.30963-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JNAP275CA0072.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:4f::23) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|PH9PR03MB150476:EE_ X-MS-Office365-Filtering-Correlation-Id: 1c322a45-7a4e-48d9-dc2e-08df33fd2581 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|261026121527099003|11063799006|56012099006|261009223027099003|261021121427099003|261022105027099003|10067099003|261021123027099003|18002099003|22082099003|261026140227099003; X-Microsoft-Antispam-Message-Info: HMz1Jk3Vid6PachHFuDAwpJ7mZ3OSgcNzmhgXj8fpgqZqV99xji0lYg6JksQE/ToHJU8BIYrTrdjFqkAT3xXDubNLf2fg2JiSzbiCThdl+w9Aj5vaN/USRNpNlCK86R0/gEMTBxVOOlh0zF1e9UBfaoAPkQTQJ60WfuQsXPxMtA/VnV11Z7+2qu07I8pCfO5MZxCXi7E1ZbY2jbI2J1Skjl1KD6wUpLh24FnII8s6LYY0wIDV2D9/0LXQanZowlM/wBVfUlMXvlEupD+3PFKzH6u05n8OM06poJS2hnRPVihAfEndQdHm6QVJLblmDXz0ucUc8GMSe+UcNZQuwvi6QsQGbUDN70SnWCjt2KaPqwB8PMQ8+gZmPsOspCTdY4LppdIHJVcJ0EUGbizsN0AQQm+DAtIq3O8lsfjj2t2iXm1xqwnKGr910zg7zb1MaplLEBW5VyAXrToGCjNdYVTfGBrmT2P2yG/LYZNoi7VfdB2cgl5XQggS7WqIfj9+KDex4vYI8EPah1RIP9hubhSci34zPFh54YjvnqOosjHEUiJitvcTOvmRkyGExfAYj2JE65/8lMFZOgPZi1HaTjdl4uwnuE5n4+6EMpMUg/Rkv7GDCV0S+I/hTrYFF2ffTQuo8cG75O2Nrj4zYYShA92snLrwsGpThdXn0tHVuppfeg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(261026121527099003)(11063799006)(56012099006)(261009223027099003)(261021121427099003)(261022105027099003)(10067099003)(261021123027099003)(18002099003)(22082099003)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?LGVSVqb68P0KkSBpqpkNACUP3w+DTQOPhqqyKMBGMXUdff477FWtir3frQZm?= =?us-ascii?Q?m1I8dpBhiyRrTjjPsuwjpak0Q5QSDmjiVXiZ2xuX77WVvKHkMb5GOS4JCulY?= =?us-ascii?Q?GRuqSDjLg0D7/o4RNrRyqBom9EgpEUzAjwM5QnVc07Ugwmh5m9qShI6KeFjQ?= =?us-ascii?Q?OpTSF2OyDYIowVcmn0oGY7IB0E6F39aBUU7xfb5BHe0l3O5R3JMrG1CTvZH8?= =?us-ascii?Q?WXcWfdFIQ18EFIdugQe1dnCUTp2v7l3GGSjXFqBxHbEeLbE/1NFdFg1rr9iy?= =?us-ascii?Q?jka8umxtn/bh80ecmLXklqU4VjKyqrjdhaceRD9YHP8QOE4Q23Bz0zCctIm+?= =?us-ascii?Q?/hYF+RYZsuOGkkaJ5hOhqaF9Ox/Lpogvc5542vefNnyl6VOGwsX352DfZa5/?= =?us-ascii?Q?1F0TjfMytIVZAxrLd68OLHFTNd9JO2YOh13EV60ciypOtbJt2KViS/xLG253?= =?us-ascii?Q?aTGDMKlZTxOoENoCVmDt1YRyHLIG6x9ikq9DyEHSMvT5Aa8PB/D1laOsTaSO?= =?us-ascii?Q?clUzrX5SKqsmm/g0emzu0CYTnbF6kLl9Zk/Swm+MeqU85eDpCwM4pzNp+vka?= =?us-ascii?Q?W7vSi4FUG2SvVPT+j38Ce6V0+/I9aKrSrvNoAZHwyP9MeAsZagdMXjw0saMS?= =?us-ascii?Q?mRBAPiWePuLI/rPFJkVaOjne96IEvaQyfk7qnh1axmWtyc8ngHJsajeFbDhn?= =?us-ascii?Q?hXpg/JPIVUzFQ0RcpMIkphzc+wo+dVye/uiI58GltP5y7J4MGQKN7iC2q5v0?= =?us-ascii?Q?ISApOYFsrnlv2t1iHm1s8h2vmQzazJJKQfqFLfI/zX2W5sMPhyYe61tmtKws?= =?us-ascii?Q?CSyd3YKF3OwBhUA2V09rzJACXSYqmK6RsmCE/dHyCA0J4YXXvcgRH2HfM0+P?= =?us-ascii?Q?Qu3/hJx4Rtl4KP8ypzXxVZaWaW/s2ztJziq7V+k292xNn3UT46vr+4QoMP5Q?= =?us-ascii?Q?5tMR87DKdS6aMTdG7pNxRmw3bIZNlqH1gafr4BzqVHM2dnORJMX5sYNNXe/a?= =?us-ascii?Q?ftnPSNi+CvWsokguvvmGjHaCma7SYUozy7cOqxOXuMV4J4cKRF6lTzJq0sUn?= =?us-ascii?Q?bbFY/tJg3t2ohMEeOk5xOIsDXPqw1Wt9Jvo3Qv6XJv0YqCJ9MPM+Knktm30I?= =?us-ascii?Q?qezHp+/TC88SI1Y1O3bnJjQM7SXEhri7Zkdt42V9i61uyaVyGZHxRrSyV4Wt?= =?us-ascii?Q?aMXy40+Sl47thJJYI5AKqIgPFRd/iUXNAkcJw5REltxfFbJnspjMtWTBKMZJ?= =?us-ascii?Q?2NdupdxDCEiBHgiRmeP30OoD5iAtckZAdRDn3wpnvCMckGFblrW8BLJF0sG6?= =?us-ascii?Q?xmjsBHCYHTC/b8b3Xqz9Z3mUXBwYxRVlPYZQ5mIHKLKGVuielFrJwCaEHQeq?= =?us-ascii?Q?FQhKkX8VgBSr9FflhVurkpph9AIsx5Ryk7uD4DhoxrOQJm8PbSfILGYkIgbq?= =?us-ascii?Q?WCDk1uAseQF4OEIRRTob/b+0eCvZsR1N07ng9vLkmNnhHYVLQnQnqtT5YfZc?= =?us-ascii?Q?m57YIX2DAZI1EAtH4SWDrmWFj5Bb9/Qm0jPtkYELqbN5q9fc1byOuoSHswNQ?= =?us-ascii?Q?yf9HRIdPabgsr9Y6zfgtO67EyE6SqhB4fc0ECj2ZAlSybSGkxJ8IASJjz2yd?= =?us-ascii?Q?UgbHOfSv5OVKAwTXvL4wBu+VdXQRwH0qm1N+OlHgYGgBGm3ZBFd6fon41VPd?= =?us-ascii?Q?KxCZ3IpZf2xqZEb6IXw2LtBy2d+dbQxQcO5eJ2wsa/vofmMMGPZ3euUztB5g?= =?us-ascii?Q?YZcWlqtGLQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c322a45-7a4e-48d9-dc2e-08df33fd2581 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 07:37:25.9962 (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: xmpGn2d9dePB2MGz52/b2AxbqHeILDEXmD02TtDgTGwPt0SC3HPqENVUyPTgUaji+tUN3KEaY0D4zw4iyOjKUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH9PR03MB150476 X-purgate-ID: tlsNG-d25034/1793086649-77ED2A5B-0966C5ED/0/0 X-purgate-type: clean X-purgate-size: 10465 From: Chunjie Zhu Nested virtualization on a domain is only permitted together with HAP: sanitise_domain_config() rejects XEN_DOMCTL_CDF_nested_virt requested without XEN_DOMCTL_CDF_hap, since shadow paging is too slow to be usable as the L0 paging mode underneath an L1 hypervisor. This means the host (L0) can never be in shadow paging mode while nested_virt is enabled, i.e. paging_mode_shadow(v->domain) is always false in this context. The nested SVM code still had incomplete/speculative handling for the 'host shadow paging + guest shadow paging' case in nsvm_vcpu_hostrestore(), nsvm_vmcb_prepare4vmrun(), nsvm_vmcb_prepare4vmexit() and nestedsvm_check_intercepts(). Remove it, and assert the host paging mode with a single BUG_ON(paging_mode_shadow(v->domain)) ahead of the guest paging mode checks, so the remaining comments only describe the guest mode. In nestedsvm_check_intercepts()'s #PF handling, fold the two identical NESTEDHVM_VMEXIT_INJECT returns. Also drop the now always-true paging_mode_hap() check from svm_nested_features_on_efer_update(), and the stale "shadow-on-shadow" TODO in paging_update_nestedmode(). No functional change. Signed-off-by: Chunjie Zhu --- v2: * Move the BUG_ON(paging_mode_shadow()) ahead of the guest paging mode checks; comments now describe only the guest mode. * Fix comment style in touched comments. * Fold the identical NESTEDHVM_VMEXIT_INJECT returns in the #PF case and add a blank line before the next case. xen/arch/x86/hvm/svm/nestedsvm.c | 125 ++++++++++++------------------- xen/arch/x86/mm/paging.c | 1 - 2 files changed, 48 insertions(+), 78 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 2b998e26bcff..ea30c777451d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -237,27 +237,10 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) hvm_update_guest_cr(v, 2); /* CR3 */ - /* Nested paging mode */ - if ( nestedhvm_paging_mode_hap(v) ) - { - /* host nested paging + guest nested paging. */ - /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ - } - 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. */ - } - else - { - /* host shadow paging + guest shadow paging. */ + /* Nested virt requires HAP, so the host is never in shadow mode. */ + BUG_ON(paging_mode_shadow(v->domain)); - /* Reset MMU context -- XXX (hostrestore) not yet working*/ - if ( !pagetable_is_null(v->arch.guest_table) ) - put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_null(); - /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ - } + /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ rc = hvm_set_cr3(n1vmcb->_cr3, false, true); if ( rc == X86EMUL_EXCEPTION ) hvm_inject_hw_exception(X86_EXC_GP, 0); @@ -517,10 +500,13 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) v->arch.hvm.guest_cr[2] = ns_vmcb->_cr2; hvm_update_guest_cr(v, 2); + /* Nested virt requires HAP, so the host is never in shadow mode. */ + BUG_ON(paging_mode_shadow(v->domain)); + /* Nested paging mode */ if ( nestedhvm_paging_mode_hap(v) ) { - /* host nested paging + guest nested paging. */ + /* Guest uses nested paging. */ vmcb_set_np(n2vmcb, true); nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); @@ -532,13 +518,14 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( rc != X86EMUL_OKAY ) gdprintk(XENLOG_ERR, "hvm_set_cr3 failed, rc: %u\n", rc); } - else if ( !paging_mode_shadow(v->domain) ) + else { - /* host nested paging + guest shadow paging. */ + /* Guest uses shadow paging. */ vmcb_set_np(n2vmcb, true); /* Keep h_cr3 as it is. */ n2vmcb->_h_cr3 = n1vmcb->_h_cr3; - /* When l1 guest does shadow paging + /* + * When l1 guest does shadow paging * we assume it intercepts page faults. */ /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ @@ -548,16 +535,6 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( rc != X86EMUL_OKAY ) gdprintk(XENLOG_ERR, "hvm_set_cr3 failed, rc: %u\n", rc); } - else - { - /* host shadow paging + guest shadow paging. */ - vmcb_set_np(n2vmcb, false); - n2vmcb->_h_cr3 = 0x0; - - /* TODO: Once shadow-shadow paging is in place come back to here - * and set host_vmcb->_cr3 to the shadowed shadow table. - */ - } /* DRn */ if ( !clean.dr ) @@ -1030,35 +1007,35 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) ns_vmcb->event_inj.raw = 0; + /* Nested virt requires HAP, so the host is never in shadow mode. */ + BUG_ON(paging_mode_shadow(v->domain)); + /* Nested paging mode */ if ( nestedhvm_paging_mode_hap(v) ) { - /* host nested paging + guest nested paging. */ + /* Guest uses 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 + /* + * 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_shadow(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; + * hence we keep the ns_vmcb->h_cr3 value. + */ } else { - /* host shadow paging + guest shadow paging. */ + /* Guest uses 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; - /* 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. */ + /* + * Stop intercepting #PF (already done above + * by restoring cached intercepts). + */ + ns_vmcb->_cr3 = n2vmcb->_cr3; } /* LBR virtualization - keep lbr control as is */ @@ -1260,40 +1237,35 @@ nestedsvm_check_intercepts(struct vcpu *v, struct cpu_user_regs *regs, return NESTEDHVM_VMEXIT_HOST; case VMEXIT_NPF: + /* Nested virt requires HAP, so the host is never in shadow mode. */ + BUG_ON(paging_mode_shadow(v->domain)); + if ( nestedhvm_paging_mode_hap(v) ) { + /* Guest uses nested paging. */ if ( !is_intercepted ) return NESTEDHVM_VMEXIT_FATALERROR; - /* host nested paging + guest nested paging */ return NESTEDHVM_VMEXIT_HOST; } - if ( !paging_mode_shadow(v->domain) ) - { - if ( is_intercepted ) - return NESTEDHVM_VMEXIT_FATALERROR; - /* host nested paging + guest shadow paging */ - return NESTEDHVM_VMEXIT_HOST; - } - /* host shadow paging + guest shadow paging */ - /* Can this happen? */ - BUG(); + + /* Guest uses shadow paging. */ + if ( is_intercepted ) + return NESTEDHVM_VMEXIT_FATALERROR; + return NESTEDHVM_VMEXIT_HOST; case VMEXIT_EXCEPTION_PF: - if ( nestedhvm_paging_mode_hap(v) ) - { - /* host nested paging + guest nested paging */ - if ( !is_intercepted ) - /* l1 guest intercepts #PF unnecessarily */ - return NESTEDHVM_VMEXIT_HOST; - /* l2 guest intercepts #PF unnecessarily */ - return NESTEDHVM_VMEXIT_INJECT; - } - if ( paging_mode_shadow(v->domain) ) - /* host shadow paging + guest shadow paging */ - return NESTEDHVM_VMEXIT_HOST; + /* Nested virt requires HAP, so the host is never in shadow mode. */ + BUG_ON(paging_mode_shadow(v->domain)); - /* host nested paging + guest shadow paging */ + /* + * Guest uses nested paging and L1 doesn't intercept #PF: it is + * L0's business. Otherwise (L2 intercepts #PF unnecessarily, or + * guest uses shadow paging) hand it to L1. + */ + if ( nestedhvm_paging_mode_hap(v) && !is_intercepted ) + return NESTEDHVM_VMEXIT_HOST; return NESTEDHVM_VMEXIT_INJECT; + case VMEXIT_VMMCALL: /* Always let the guest handle VMMCALL/VMCALL */ return NESTEDHVM_VMEXIT_INJECT; @@ -1566,7 +1538,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_shadow(v->domain) && cpu_has_svm_vloadsave ) { vmcb->virt_ext.fields.vloadsave_enable = 1; diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c index 4bb8d169de1c..7c6df8d5d07c 100644 --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -932,7 +932,6 @@ void paging_update_nestedmode(struct vcpu *v) /* nested-on-nested */ v->arch.paging.nestedmode = hap_paging_get_mode(v); else - /* TODO: shadow-on-shadow */ v->arch.paging.nestedmode = NULL; hvm_asid_flush_vcpu(v); } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 07:46:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 07:46:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461881.1672894 (Exim 4.92) (envelope-from ) id 1xLbsf-0005ye-TO; Tue, 27 Oct 2026 07:46:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461881.1672894; Tue, 27 Oct 2026 07:46: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 1xLbsf-0005yV-QH; Tue, 27 Oct 2026 07:46:01 +0000 Received: by outflank-mailman (input) for mailman id 1461881; Tue, 27 Oct 2026 07:46:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLbse-0005yP-EJ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 07:46:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLbsd-006lzZ-Nw for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:45:59 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae056b5-bab6-0a2a0a5309dd-0a2a45059682-8 for ; Tue, 27 Oct 2026 08:45:59 +0100 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae056b7-4cb1-0a2a45050019-d155dd35ed06-3 for ; Tue, 27 Oct 2026 08:45:59 +0100 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48afcfc4bf5so3125398f8f.1 for ; Tue, 27 Oct 2026 00:45: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-4a35a0bae01sm306058545e9.7.2026.10.27.00.45.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 00: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:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1793087159; x=1793691959; 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=J2WbXD4M+iilIIFHWtN5R4d1yNKj6k64QH84G9Pk9wU=; b=QVtVVp66gRDfITvy5wNTvIdjpO/V+beCIH9Y9QLxlYjmlcyDkPqyfIl6IFKPHvav/X cMNvezQSx/mLQEjLhdNLAnSinKEHPa7YalZBxc5JxB7blX6JH51rVoxZsRSGMzTFJtlq Ga0Osvf9ZstsY27Du6yGmvaM/d754+qT+5iG86vmfztmzVKsjYAAQYU8Y8869J24Corv 0O1U4flmvskBp+esauq6btQJj5Rz8jriwV6OxchpvwHbyVdq1mxNpS2Zii1kBOUHmUqU I4jyyjPB43i4XhPSj+PdzgMcNhu6pvLPr+21LKPQI94J4mAbv9xuKLFlvAWn1C5S+f17 mIJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793087159; x=1793691959; 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=J2WbXD4M+iilIIFHWtN5R4d1yNKj6k64QH84G9Pk9wU=; b=av3bpa+1ZlB3uCm3CzzrAAhCw8mVtdR064PxuwbxkTEE/ivrlLDYl3t7/K225anK6F Zhrgr0y9VHx5SuvGMpewcIf5LDiG4NnDOGg6nYKFMcPLd9/PgGLOxV1PmRggeAnauTh4 d6v+dSG5dltTIpZJ1liMB7xoNqX+dtnRScbs2l46H+kKODoBAWL6v3qK7sTj+x87oKKV Sf5j6au+zVSn5n4YzH7jYdPt7lVu971eARR6kAAXOMPsHKbMEO32v7QJSqrFKYmQJUuF HelKD0bYqe1jSHwoNARbc/73AYgnqpvMqyGNtcqOS8UHOM7sOWR6eJKJYukTD30PcMdq ieaA== X-Forwarded-Encrypted: i=1; AKwUvBwdXTz9fU8CdaE4cYCsgAOYB4A4V8ao5s8symMcoxn6xv/Uv1m1INBVNMDQ4zUwGfEKHYquB3f88BI=@lists.xenproject.org X-Gm-Message-State: AFq9FYI0T3LAQNos33QgI97jzbT9Nzcvpu9gbVZIr55wRAxx/fhvRFz9 0cb8l4GJg46+xMzxsLbNUXpH+qUlXOoVDmhZ6+L2lkbtvNL2ngAgHq4xS8fCpCGdNw== X-Gm-Gg: AYBFou0hxthe0mugaHnHJ8uXcuED5H4/Fx+ToLMrQ2+WDRrLlUI2u1EqSdoojGtbucu LbpgaT8XP999aYXm5x7YHa4a2bZIeoEwarOCTZJ75Fst8jnTianvrq3N8P9uN713bMF5l6h/iNs SIpX3NB2E0BAjt8R0pqJbjL+LK5mQQ2g5PznLWww7iSRySDWRzl4n0954lYEGGyuxZA8eysL26x zR1BBR7eFomXzwvtkNx0/ccXyUq+Rf9X6VofW4vrCE5r5fVHXle0pmZmSUvkwwmYX4oTstfMRGi C9wraPH/I9OwoOXIFk/Bkxx5nDmqx/zfXibJBK079nX+NHSk/ECT+/QGXdL8TJVU23QVjmldq2g +9ePT3u+WzLDatZOVhto1LZ0d15qbMYmYOHNfylznNNXWz4oclR9hDgqIzIQWk1QgFHye08P0K7 bBq7eBWgpt/OG2VNJN+BPA66HmPUcr7QtYqJKOVCLU1+MuHgqH3nsqi+E7JsNUubccrwRIPd6WJ JXejUy/sL0XPEuSAYgjeMBQgXp9gkffU2IemwwKccO9D+4xoVx30n7xP+NqLVnB8Hg29+CYU+Ak YvvUOvrGhuUALD/Upt7JKItXRXKY6o6TDkzHmoEAqV8= X-Received: by 2002:a05:600c:3114:b0:4a3:5a55:f454 with SMTP id 5b1f17b1804b1-4a35acc772dmr167243505e9.19.1793087159001; Tue, 27 Oct 2026 00:45:59 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 08:45:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/nestedsvm: remove dead code for shadow-paging L1 hosts To: chunjie.zhu@citrix.com Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261027073711.30963-1-chunjie.zhu@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: <20261027073711.30963-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793087159-247132A1-695B8FF1/10/78276251493 X-purgate-type: spam X-purgate-size: 1612 On 27.10.2026 08:37, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > Nested virtualization on a domain is only permitted together with HAP: > sanitise_domain_config() rejects XEN_DOMCTL_CDF_nested_virt requested > without XEN_DOMCTL_CDF_hap, since shadow paging is too slow to be usable > as the L0 paging mode underneath an L1 hypervisor. This means the host > (L0) can never be in shadow paging mode while nested_virt is enabled, > i.e. paging_mode_shadow(v->domain) is always false in this context. > > The nested SVM code still had incomplete/speculative handling for the > 'host shadow paging + guest shadow paging' case in > nsvm_vcpu_hostrestore(), nsvm_vmcb_prepare4vmrun(), > nsvm_vmcb_prepare4vmexit() and nestedsvm_check_intercepts(). Remove it, > and assert the host paging mode with a single > BUG_ON(paging_mode_shadow(v->domain)) ahead of the guest paging mode > checks, so the remaining comments only describe the guest mode. > > In nestedsvm_check_intercepts()'s #PF handling, fold the two identical > NESTEDHVM_VMEXIT_INJECT returns. > > Also drop the now always-true paging_mode_hap() check from > svm_nested_features_on_efer_update(), and the stale "shadow-on-shadow" > TODO in paging_update_nestedmode(). > > No functional change. > > Signed-off-by: Chunjie Zhu Two formal things only for now (will look at the patch itself later): Please send new versions of patches as roots of new threads, not in reply to any earlier thread. And please adhere to the To: vs Cc: separation there, too. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 07:53:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 07:53:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461890.1672903 (Exim 4.92) (envelope-from ) id 1xLc01-0007rS-Na; Tue, 27 Oct 2026 07:53:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461890.1672903; Tue, 27 Oct 2026 07: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 1xLc01-0007rL-Kn; Tue, 27 Oct 2026 07:53:37 +0000 Received: by outflank-mailman (input) for mailman id 1461890; Tue, 27 Oct 2026 07:53:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLbzz-0007rD-T7 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 07:53:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLbzy-0035Jz-Qf for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:53:34 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae05874-8faa-0a2a0a5109dd-0a2a4507d4c6-34 for ; Tue, 27 Oct 2026 08:53:34 +0100 Received: from [52.101.43.4] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0587d-b4ea-0a2a45070019-34652b042dd0-3 for ; Tue, 27 Oct 2026 08:53:34 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by SN7PR03MB7034.namprd03.prod.outlook.com (2603:10b6:806:32e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 07:53:30 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 07:53: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=Tq0sY4dCEfFKLYVb0tRP/CEoaFQEsDlkpa99R/9cXykjdtpFYUu4cy2ble0se0ZssuhhMMzz32JYbTgY2lsa04sKz/t6soq/79QZ5B40PixFLSM0xMBa3/7oB+DrqQKBNQfrhEhzLMhmGjMR1MrqVlWsvFzLVRyY2oIecwliHW8glrKbjSh7TzQdfTKnGhz7lWyDoC9P3ziyPK1R3PS5zomnHDL+ScD9IXityTkLWMiP/L8PDzpviqdNUixJ0xWVV5PPOm35JehxmmG37uXz7KSeZ7ZesGVWB+mb6OHKAv54k0iZZelukG/k3C03nz4Iwphdca1eiQr+a70KrLaCpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r041lpjHkU0V4ON9JHKWLIN1qB0Kz/prrrf3gRWQr00=; b=bwdVgyfyrIaivl0zrbDNci3Ueb2kbJ7qUOZP8JUsJ0QnfsVwumFQo1M0/IP0YDk4b+dMiJiO3vGzkGS78zAG7Vq/KjgYJChvbR/eZgLGGXZqwR6hMO7mWEOThWTlNyeOQzlpch/FzUHujwV9E3orqfg+UHhOQDh7FkdI7yzPVLTn/02ShqCRwGyGimWt7MvfyrG8u82L5NU4YgOcnZLXQe5C9XrbTs2vv8gOXbWx7lxoeMD+Dw0xlX926r7FpXLsCu/Yx8VXz9AHdp3KsS9KeJ0maAVLrTmI5S+XnX/Zd+/HAJme0JdZWcnaNd19lJ7PESu8n1fZj04cnKAEkklB0w== 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=r041lpjHkU0V4ON9JHKWLIN1qB0Kz/prrrf3gRWQr00=; b=Wj3YOXdAhq47gNvq6+lYTqVtLUDctiWE4qLarhY9n+xwTr342qi/1IkddSSdMaKzNF/gB80JxhzzGmgaXtCI/dzS+ttvTsPgfABIz5MbNxHX7N6bI+/rILBupJu1YmOaV4hoaveGw/62vn69a5XsoSGYM2Yy0zTKUdw1DuJynHc= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: teddy.astie@vates.tech Cc: andrew.cooper3@citrix.com, chunjie.zhu@citrix.com, jason.andryuk@amd.com, jbeulich@suse.com, roger@xenproject.org, teddy.astie@vates.tsczsss, xen-devel@lists.xenproject.org Subject: [PATCH v2] x86/nestedsvm: Expose SpecCtrl to L1 when L0 virtualises MSR_SPEC_CTRL Date: Tue, 27 Oct 2026 15:53:17 +0800 Message-Id: <20261027075317.38284-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <1792508477.8631fc262581453bbf619ec5b2062170.1a159d4bf40000f79f@vates.tech> References: <1792508477.8631fc262581453bbf619ec5b2062170.1a159d4bf40000f79f@vates.tech> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0151.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:cd::10) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|SN7PR03MB7034:EE_ X-MS-Office365-Filtering-Correlation-Id: 1e35aa56-8463-4a6e-d2f8-08df33ff63bf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|261009223027099003|261021123027099003|261022105027099003|261021121427099003|10067099003|56012099006|261026121527099003|6133799003|22082099003|18002099003|5023799004|11063799006|261026140227099003; X-Microsoft-Antispam-Message-Info: ftXorj0WnS1PJfV7XAC/pp+BZmapletdizPYACCNN8hb6C1a5ZW+wIth5IR6lLh8rsnImekIb3mHfUf2/E4nfZIt3+x2qmDXpyIwN/2hAvRsHVzlrZxCEIB/sPQq5n/8mHcflvrPp2TJ1a90w9GeDe3fzgf6mgqlK2W6BQ7Ge1Tm+L36BmnLM/6l7VHL758+dvFbO1BmHbAW/SxOyOIVYQtqvUyDJbedP+LwR9CAWhFeaO2Ol8SXky8fVUS4KdOfpgDF2Lcgl5AHapR8yzKiJ+f1YFFVaFiUfLd0tc6pofMH9INNSkmtJ1djSEdMPBXK+qe4MVPCjgp9QUWvl8xqnYHWkNwYvxcogZ4uLQELwmoyqTNbY7mG10pn66+lc0sGettUHvZQyA0RRgpzL5PPMyt3bPp0qgFXhsGbGvuVlMd5h1jN8Gd+IdjBI09+d/RntLPf6tEKIRjyF5aTFLBwI9iIPLe/Y2ndZOej/Rnando+cJLwNsj2akYhZcUTZ+LKMuhyVV3bpKoYVTvhAo0OjCMJ1rPTfPRH/objFNiwrTqByZQuW8ZmmB9HF/O9/MpHX209m+/4zVjNsDyGye1GGJflRWqfd7HR9W1ul0Cjjs1bb8Xb2as8GO7IdcLTZ/lpoA2IPsEfYvigBUF3FWzxeWXjIumVhEFlNYtdpg8q4EI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(261009223027099003)(261021123027099003)(261022105027099003)(261021121427099003)(10067099003)(56012099006)(261026121527099003)(6133799003)(22082099003)(18002099003)(5023799004)(11063799006)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sBs1L24qlrTh7wJFN/PkfpIGOXjB6fGqV9MbIMaQ2GWY/BTEA8Y0HNFNPu+L?= =?us-ascii?Q?EDeHBc0Yutlqkwg/iCnzFi5OhLWN5S4PIO0yOkIPac9KdIRlKwrsq2SVi+zZ?= =?us-ascii?Q?qlZm9oiSBM9zjtn586IFcc6BYZscAYpd9NQONu+/pauP5UUTPZqFm4H9bnat?= =?us-ascii?Q?kz+ExvS7CvCuYZ4oRHB4vRHqDGNLJcpd0qaPXZuU2Ts8TcbEnR7KP3Dnv9Zs?= =?us-ascii?Q?JFl1GagzGcoVDTpwtbWW2snwQzFTj3uoUvHMDoP6UBr+P7TRiX/c42gj+cY1?= =?us-ascii?Q?FTAaeFR8OM6/2aBwvrI5d2qXftfLmHTpST0+gAkjjeHJWlG+qQyH9B4j/07t?= =?us-ascii?Q?pxtV4t2sZ+17Rjo7O+o5VSij3RvGjJsmETut8DH+Mz/qQwkfmtkm2SC2/C13?= =?us-ascii?Q?R+Heiqwu97lKMMf12PjFvSL2Fzhqz+0gP7kMhUM0PdLeA/VXUFY2i/aMbO/Y?= =?us-ascii?Q?ruSXLhYS+nKYPdmlyXNFqaPkp3acVrRQHKmfTrENSCgw8A6ZmRwDIs4PmbQp?= =?us-ascii?Q?doQuKuFKVQUyW6pqtSVaLqCEfyniA9EgjJZfEQfKiiOO3PrV2yE8JikrWXmD?= =?us-ascii?Q?w3pDcPNshPz7XuDEx6mAA02zThBt18TOiEul18h1RMBkqdEUkV/Ak/vKIQpe?= =?us-ascii?Q?/G23WeaiYxQrTvPW/3wAZmo/jR0s566ZWxRWgBgfPOVUUG2tT0P2M/ZUFHmO?= =?us-ascii?Q?VmkW98gOJ9bwmqqmqZ+eZ4mW2bIYcja8izizUuOzuq9FMHD0arJQdeOpTdl5?= =?us-ascii?Q?OE3Q+Z4aRCav9lxu35gzPY+tGfySoI/bTgvpwGdtRgOWOHJMhGlOK/wSLXN1?= =?us-ascii?Q?TQwZ8nGQ/JT2U4P4duLk6ozoFwBwfUvC+0QyRd1jxBeJXzCg/cNiLbw2loMP?= =?us-ascii?Q?pTVvnMbIeIDQZdqdD4qFJG/Dwzc5NKhV/aFAnC4NQQ6q2l1MSLMLg5IAnlKL?= =?us-ascii?Q?TgdhUXw9oJ/yKJi9N6rfxWSxGXr69yYih4uhp/z77gROVr8eAeZ5ENPil/0Y?= =?us-ascii?Q?Kt7HKPKS4ccZ5GR9qtZOrN0ZrMsOyWL+TKsoo6cDDWMOZZ1AbKvoNMVsZmFD?= =?us-ascii?Q?md1GRqJLgG2Xjf6TQjbvw03xmewQ1o9ii8okcpUsn7LCS1E13Ii6r61laDjA?= =?us-ascii?Q?l53Jb84pYPPZ/FWLPXdmux2ZTWpeyFuqoRXqfvozUm17z46t1x6elu3VcdWu?= =?us-ascii?Q?AF2vLfkit40mB+7LNuKLy0TjDH0eJQP7dv1NKoft59JkrZMgVM/m/kE3S/tv?= =?us-ascii?Q?9trhMrcUHzCv/yJwGsyrilh/o+72qT5dsLbXdj7HYiXtXfSxKGAd0VfH+pHW?= =?us-ascii?Q?Q+HtgHWhrunPs2TJt1er28ildiXSbyPZjXZTlpWgbJAKnkTqyASdv6kyJf7A?= =?us-ascii?Q?hV7fUaBjwI/PMA4fCJO7Q9Et1QD+cuf79OsAuadYnyMbYHr6s/wCmrGOw19O?= =?us-ascii?Q?hRrZy6Bgkm1JcP01u58DmOfyOkLQm1c1GpWmBA1FQGqfXJOjv5zVlOWKAyQ8?= =?us-ascii?Q?whl2sYFfggb0jmN9q7kgaYJeRANkFgFwlG7YO0weO3xuyGedgk//BRUGKo+H?= =?us-ascii?Q?rCUqf8p8ww/iSaKPdVsFsEOaZ80agD5ClkX1gGuZyVFH4lvpy+7X4K25wqpp?= =?us-ascii?Q?UzEuqltBm3FFfD4mGlzjNg4NxAaAtWFBZYEts7dhMgrkQ4Jp561WFUQNVH/N?= =?us-ascii?Q?QlrROqfQQ2gWaS2+yDw8Lq5FMK5PJVq+v95jkZd+NBxsBVGgA73A8Pb4gdiG?= =?us-ascii?Q?y4g8NA6qAA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e35aa56-8463-4a6e-d2f8-08df33ff63bf X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 07:53:29.7046 (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: WhdUc3S1rI838XKyfH9qADJEOKLxYa+wWu2J711LEZa8B0DOmIoH9HWlEJ4RbJ4i71GjYJ1OXG/pbps6x9eJOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR03MB7034 X-purgate-ID: tlsNG-ef75cf/1793087614-37AD0AE4-9A6D4591/0/0 X-purgate-type: clean X-purgate-size: 6044 From: Chunjie Zhu Previously L0 did not expose the SVM SpecCtrl bit, forcing L1 to intercept and emulate MSR_SPEC_CTRL accesses from L2 in software, which is functionally correct but suboptimal. Per APM vol.2 rev 3.44 "SPEC_CTRL Virtualization", hardware supports combining host and guest SPEC_CTRL values via VMCB.spec_ctrl with a logical OR while a guest runs, and saves the (possibly guest-modified) value back into VMCB.spec_ctrl on #VMEXIT. Handle VMCB.spec_ctrl across nested VMRUN/#VMEXIT, and expose the SpecCtrl bit to L1 if L0 virtualises MSR_SPEC_CTRL for HVM guests (X86_FEATURE_SC_MSR_HVM, which on AMD implies hardware support for the bit). Otherwise IBRS is hidden from L1 and there is nothing to do, so SpecCtrl is not required for nested virt. Update docs/designs/nested-svm-cpu-features.md with the rationale. Signed-off-by: Chunjie Zhu --- v2: * Don't require SVM SpecCtrl for nested virt (Teddy): on AMD, X86_FEATURE_SC_MSR_HVM already implies hardware support, and without it IBRS is hidden from L1. * Only expose SpecCtrl to L1 when X86_FEATURE_SC_MSR_HVM is set. * Update the design doc and commit message accordingly. docs/designs/nested-svm-cpu-features.md | 12 ++++++++++++ xen/arch/x86/cpu-policy.c | 10 +++++++++- xen/arch/x86/hvm/svm/nestedsvm.c | 23 +++++++++++++++++++++++ 3 files changed, 44 insertions(+), 1 deletion(-) diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md index 482edca2b5f5..6c1925e062f4 100644 --- a/docs/designs/nested-svm-cpu-features.md +++ b/docs/designs/nested-svm-cpu-features.md @@ -114,3 +114,15 @@ leaf 8000000A:edx L0 uses the hardware virtual GIF to virtualize the GIF of both L1 and its L2, which removes the need to shadow it in software. + +- 20 `SpecCtrl` *MSR_SPEC_CTRL virtualisation*: Not required for L0, provide + to L1 if L0 virtualises MSR_SPEC_CTRL + + Without MSR_SPEC_CTRL virtualisation in L0 (hardware without + MSR_SPEC_CTRL, or `X86_FEATURE_SC_MSR_HVM` disabled), IBRS is hidden + from the L1 and there is nothing for nested virt to do, so the feature + is not required. When L0 does virtualise MSR_SPEC_CTRL (see + `X86_FEATURE_SC_MSR_HVM`, which implies hardware support for this + bit), provide it to L1 so that L1 can use the same hardware + virtualisation for its own L2 guests, instead of intercepting and + emulating MSR_SPEC_CTRL accesses from L2. diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index 48a3185eed8d..88f5a949e583 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -845,9 +845,17 @@ static void __init calculate_hvm_max_policy(void) (1u << SVM_FEATURE_NRIPS) | (1u << SVM_FEATURE_FLUSHBYASID) | (1u << SVM_FEATURE_PAUSEFILTER) | - (1u << SVM_FEATURE_DECODEASSISTS)); + (1u << SVM_FEATURE_DECODEASSISTS) | + (1u << SVM_FEATURE_SPEC_CTRL)); /* Enable features which are always emulated. */ p->extd.raw[0xa].d |= (1u << SVM_FEATURE_VMCBCLEAN); + + /* + * SpecCtrl is only meaningful if Xen virtualises MSR_SPEC_CTRL for + * HVM guests, which implies hardware support. + */ + if ( !boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ) + p->extd.raw[0xa].d &= ~(1u << SVM_FEATURE_SPEC_CTRL); } guest_common_max_feature_adjustments(fs); diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index e896c9a0f29f..0c4ce9312415 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -417,6 +417,16 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) /* TSC offset */ n2vmcb->_tsc_offset = n1vmcb->_tsc_offset + ns_vmcb->_tsc_offset; + /* + * SPEC_CTRL: When in host mode, the host SPEC_CTRL value is in effect + * and writes update the host SPEC_CTRL register. On a VMRUN, the + * processor loads the guest SPEC_CTRL register value from the VMCB or + * VMSA. For most guests, processor behavior is controlled by the logical + * OR of the two registers. (APM vol.2 rev 3.44 + * "SPEC_CTRL Virtualization"). + */ + n2vmcb->spec_ctrl = n1vmcb->spec_ctrl | ns_vmcb->spec_ctrl; + /* Nested IO permission bitmaps */ rc = nsvm_vmrun_permissionmap(v); if ( rc ) @@ -988,6 +998,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct nestedsvm *svm = &vcpu_nestedsvm(v); struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; + struct vmcb_struct *n1vmcb = nv->nv_n1vmcx; struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; /* Cache guest physical address of virtual vmcb @@ -999,6 +1010,18 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* Pausefilter - keep it as is */ + /* + * SPEC_CTRL: on real hardware, only the guest's own SPEC_CTRL bits are + * ever saved back to the VMCB on #VMEXIT (APM vol.2 rev 3.44 "SPEC_CTRL + * Virtualization"); the OR with the host's bits is a transient + * execution-time effect, never written back into the guest register. + * Here, n2vmcb->spec_ctrl was seeded with n1vmcb's bits OR'd in at VMRUN + * time (see nsvm_vmcb_prepare4vmrun()), and will still contain them if L2 + * never wrote the MSR itself. Mask those back out so L1's own SPEC_CTRL + * doesn't leak into, and persist in, L2's saved state. + */ + ns_vmcb->spec_ctrl = n2vmcb->spec_ctrl & ~n1vmcb->spec_ctrl; + /* Nested IO permission bitmap */ /* Just keep the iopm_base_pa and msrpm_base_pa values. * The guest must not see the virtualized values. -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 08:00:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 08:00:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461908.1672913 (Exim 4.92) (envelope-from ) id 1xLc6R-0001hc-SV; Tue, 27 Oct 2026 08:00:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461908.1672913; Tue, 27 Oct 2026 08:00: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 1xLc6R-0001hU-PM; Tue, 27 Oct 2026 08:00:15 +0000 Received: by outflank-mailman (input) for mailman id 1461908; Tue, 27 Oct 2026 08:00:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLc6Q-0001hN-6m for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:00:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLc6P-00GLX6-8n for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:00:13 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae05a09-bab6-0a2a0a5309dd-0a2a4506be84-34 for ; Tue, 27 Oct 2026 09:00:13 +0100 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 6ae05a0b-195a-0a2a45060019-d1558036bc39-3 for ; Tue, 27 Oct 2026 09:00:12 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a5087a5348so19795415e9.0 for ; Tue, 27 Oct 2026 01:00: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-4a35a58a0e2sm309555845e9.13.2026.10.27.01.00.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 01:00: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=1793088011; x=1793692811; 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=7mqbVy1lo+ZEPVHpu4o7s6EKWxL+/qNkX9Qsfvi5qIM=; b=VtnERbqTQFJBV5Ya1AND1+O4x1ha+Hq/fbhBKTDswhdxywEwo2RO823bxz3Wga2s8x MQzqXmHhAcMSFcnjfciioG9CgseX4VddKz8dryG6Z7rMlgtbb4MhAOIYfpIl2mFgJtFF MDo97btxFAwXZ3QtRJafm87WJ4uLYzdpSvll22h1eTjcI7qvfL+0LDwPJU5IOjDMdblT 7l7DFdFhJdRQuPohr28vdbpJ+RTA3MUfw0LN20iYmQvIXdG+NP5dwa40K8ikU9txl/UZ s+1mtsn5aN2UosyHPozkKJrS4OTD4hQyE3PML5x0InVaBOrq3UEAIjMb1u/A9wgncA6c B9Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793088011; x=1793692811; 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=7mqbVy1lo+ZEPVHpu4o7s6EKWxL+/qNkX9Qsfvi5qIM=; b=2M3oJclVM53fGEnCX+2ICAv/9z/U6CeSoJNLyCTqNw7Knvgxw7+96jhxOt3PdwwwJW P35S45UdyFaumlhJM4M5M2G3e+tTPwdfZNGRTK7pqx1B1yK02JcA5dWFitWFLirL2IkW /BhQA4oyu3/Vzv4XyKtHnO5a0mrmu8WJUPy5hMrnKNttL5+tUW/QFVu/FmUXeC2i118/ LQUV92Xe7tNDLlgX1nhJ67uvmGGVFPOqxi9RKK2CWn5rFQN1NvoBORY691707eidmObw GEKuVT5SfuYNxN6jIO6Czo0KeLvIhI7KjV+q8+QN48eQA7YbwnLQ/BCV53LtdB0NWhKE sQfA== X-Forwarded-Encrypted: i=1; AKwUvBz5yoPsIvXnAQD9kCw7YhQhcWBCrBlxVmxUacHQ18LzOXPrugHnNicBMSH8mf3+C4hRpBd4xaPMf0c=@lists.xenproject.org X-Gm-Message-State: AFq9FYJFRsJubUYbLpoh0iJoMBOb7w2KK56aHuKTlK97FpHRkDtHkGPX 7AsOkDKztl2ztFvU7Xf9ihgK4myDOP7efIlK9bkCh9x3VN27JMnzUJra98CS9Jy0nQ== X-Gm-Gg: AYBFou3H9Nwz3Yt87SR/OgPsj8Ud7XUGFhUnddqHnjnSjuXzD2H3Pp7BJefCeqKzMZ2 DJxUma01o6Q/DEu6dnCTpR9nac5OMWI7Gdm5sswlOoQfvOWtSCvWQGf47id26u4XtIpJCPh7vbz 7ew4fxhyEZr6G/WLfnyIOm9DBxzyL7amFWjAJhq5mEx115Jf3QMfe2SI6DsUuu35wdkE8GpnAMZ OoTaU1eOeLfZB/bk2dW+PhoroEepZLrUzvTk+AypcznnNsqByzKCG7PEHOmfuaoeB3aetfZt6bL p+XtHfNHu1IHlwz9LGAEKQEfY5eZD9kS3slbhWSI4snEi9wnqbH0O5IX1dJDIiamjw9eHPdmfx4 mcvfvpIQ1lej6YgfIPt6wXpgZz79muoVIHZOjefaKTwy7K8ekMowGqCDqIcfIT2cn+XatNoWMgT j+n1Crx/EqXZdR4FVVtQxyHzf+HKDJgQ1Dkw6Mh2RvIMVpRgveyxpXlRLM9cDg/X4nRM2hjOcMQ WUJ9n+64fTTBrZBIbAszFwdTn6T0eF2PoG5qWf46NeFfzLwGPmoDVvW7e9daJLFu/TTQSZm190C G+5Bmv8nCBC0h+t+y+7xFj3Mwc8ExCMENEcChEX3bwM= X-Received: by 2002:a05:600c:4583:b0:4a2:1197:1de0 with SMTP id 5b1f17b1804b1-4a35ac963edmr187957485e9.19.1793088011015; Tue, 27 Oct 2026 01:00:11 -0700 (PDT) Message-ID: <876cbf88-4212-465e-86eb-fb26bd9cb591@suse.com> Date: Tue, 27 Oct 2026 09:00:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT To: chunjie.zhu@citrix.com Cc: jason.andryuk@amd.com, roger@xenproject.org, teddy.astie@vates.tech, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <20261016070611.255322-1-chunjie.zhu@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: <20261016070611.255322-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1793088012-F76C877B-B0DE7D8C/10/78276251493 X-purgate-type: spam X-purgate-size: 2138 On 16.10.2026 09:06, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > When V_NMI_ENABLE is set, the processor manages V_NMI and V_NMI_MASK > automatically (including on IRET), and writes both back to the VMCB on > VMEXIT (APM vol.2 rev 3.44, "NMI Virtualization"). > > nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally) > V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never > copied back, so L1 kept seeing whatever it had last written, regardless of > what happened in L2. > > Copy both back when L1 has enabled vNMI for its guest. > > Fixes: 86a203ab8d38 ("x86/svm: Support vNMI on capable hardware") > Signed-off-by: Chunjie Zhu I was meaning to apply this, but ... > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -1027,12 +1027,19 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > /* > * 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. > + * enabled in L1. With vNMI enabled, the processor manages V_NMI and > + * V_NMI_MASK itself and writes both back on #VMEXIT (APM vol.2 rev 3.44, > + * "NMI Virtualization"). > */ > 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; > + if ( ns_vmcb->_vintr.fields.vnmi_enable ) > + { > + ns_vmcb->_vintr.fields.vnmi_pending = n2vmcb->_vintr.fields.vnmi_pending; > + ns_vmcb->_vintr.fields.vnmi_blocking = n2vmcb->_vintr.fields.vnmi_blocking; > + } > > /* Interrupt state */ > ns_vmcb->int_stat = n2vmcb->int_stat; ... except for the bottom patch context, the code being altered doesn't exist in staging at all. It also didn't change recently, so I wonder what code base you took this from. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 08:10:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 08:10:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461913.1672921 (Exim 4.92) (envelope-from ) id 1xLcGR-0003gb-OF; Tue, 27 Oct 2026 08:10:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461913.1672921; Tue, 27 Oct 2026 08:10: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 1xLcGR-0003gU-LY; Tue, 27 Oct 2026 08:10:35 +0000 Received: by outflank-mailman (input) for mailman id 1461913; Tue, 27 Oct 2026 08:10:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLcGQ-0003gO-CJ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:10:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLcGP-005daN-IZ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:10:33 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae05c72-2eae-0a2a0a5409dd-0a2a450c862c-38 for ; Tue, 27 Oct 2026 09:10:33 +0100 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae05c79-f479-0a2a450c0019-d155dd33b1c2-3 for ; Tue, 27 Oct 2026 09:10:33 +0100 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48afbd2c386so2312915f8f.3 for ; Tue, 27 Oct 2026 01:10: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-48e412cc164sm19938128f8f.7.2026.10.27.01.10.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 01:10: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=1793088633; x=1793693433; 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=ivyUnSuwG8PYayePp1Zdplo99Wd3rzPbyajl18yj4W8=; b=Fsqcw4EoVT0dky/i/hfFgOLdfeQ6LW5oN9NaMzF2kkso/lEnr2RnmzSkr9rQm2flwQ AwdWt4U6Ts6HHfzAJSpz10Auoh/Q1Z0c2vM+LdQ/KTBMysxPuAhcBHs1Rk36yoPgJjN0 /Apb1DxuuXAZutzNH4Sk/r+BGvkM1YsDChQqzNvwo4EW9eA0qyhM5DS5/xLRLZGAifdI JidurtRKiuH6nV2gyfxZDB2Td+uzw9vnXwy8m66VUY3qEUKxAACneXfpv9486lutr7mF P4CCu7rxhtF0WOsXHATtY6PZteXAmPV1Gb5Of8zz4Bo+85c6GrjmJIOeheBFk5m3V3jl CPNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793088633; x=1793693433; 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=ivyUnSuwG8PYayePp1Zdplo99Wd3rzPbyajl18yj4W8=; b=SL46i7Kl6WaYPdiJMg73MyOQVoEPOEuWpZFxPAgHGNwnDiBLZ7XoSV/5YAj5Tiyeuc ZTYjr4OEGNMPifV4OAd8BjfN7uQgKZ9LEJer6YiCUuXgjkXwswtWJ3pBLklnJWlZ1Ykn pRuuu+a9La2oiclFABHF0BDt6f0q5BcB61hGc9MiNkSCcyP56SlkHEzwK9c0m0xcA2c0 z1XxW0zD+UlKLWjZ+RLz/6G9bGwDda67XbB7rOh0M+OZi1jlknLCUAuWaDPw1pYAFvfG fbi95r2YAg2R5NdkPk+OlcLEoXM2sveNgGymamJrsEUwWOO8GQGjzPshTkAAutOMlheD 2Cew== X-Forwarded-Encrypted: i=1; AKwUvBxJZNhy1E4eIWGSDy3D1ksRDKsKa++33kw2i0mr5qpuR4ghNqY7sMJBAHVoyRtkDznK/6jj6CFl0Vw=@lists.xenproject.org X-Gm-Message-State: AFq9FYKnL1erT2PaOxUPGcBXVdbV/mE5JwCLy5+8CABUki//csV6wM9Y q+Ynv6gGHg/e0a7SU9kn+X8f10s2EB4W+GGSCvGTUsnn2NpTZ2tMwhrgwWLEFkjJYg== X-Gm-Gg: AYBFou2fcn1usXKQ48K6Z+5iwpxmAxxgVNBYKyhmb7PAi3fBiq5Zia/VhM5+7/QcWqX nk9EWdnUcLjcSb7pYoTwFNMgYCTWWSiXYoFYTDX0tkiW0y6FnJ/dppEd62TILpio8q+4X3h0CwB hEfKygjbuJiuvvJByYIwGoprKxoAAMVA54kx2pZNHcQz3zh3fWPXB+xl4cIzkTxKGwLQtPdUMc5 Yqp2LadM1UvXrkFRnc9qtsIm1aUA7jMPNW0ak5iLNkeD6LNWGkGUL9TSSDBphQqazy38V0nZRex eDBf216HnZ2NB03nHF4atAfh7MwbfsbjnFyvjXmr5SMbp39E2oKteED8gkulgODERN94n76z42z iV3wMo8pQAslgVXghOSJ+cQtIolfypaWd5kWUwesQWWwuiR+fc576tR6R8ssvXPxytIUsU1Qd7U PsY9GfOLibZkzArBLDguVxMjBNsEhpyq0Wh232NTPeBUgA/lfX5w8vz6lVRuLMzSPOaNnkf6VGk u4gy3QFfn3ug/SiQBECbyMTo1b+wFiAfOHk0v4XiPhwpELfStkRdE/3jZYdA3PB3Ddw8CdCHQFo 0DUebhCvK5oDbie5FH8FG7Nn0UoymrwogYbTLSnKiQok X-Received: by 2002:a5d:5e8d:0:b0:48e:6f:19b9 with SMTP id ffacd0b85a97d-48e3eb83497mr14619789f8f.23.1793088632628; Tue, 27 Oct 2026 01:10:32 -0700 (PDT) Message-ID: <6ba22489-5cca-47e1-b1fb-f0b5c2f18b16@suse.com> Date: Tue, 27 Oct 2026 09:10:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] xen/page_alloc: scrub each page in unprepare_staticmem_pages To: peter kang Cc: anderson.choi@boeing.com, matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com, 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/1793088633-50B3DA5B-E0B4D414/10/78276251493 X-purgate-type: spam X-purgate-size: 759 On 27.10.2026 05:25, peter kang wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -2941,7 +2941,7 @@ void unprepare_staticmem_pages(struct page_info *pg, unsigned long nr_mfns, > if ( need_scrub ) > { > /* TODO: asynchronous scrubbing for pages of static memory. */ > - scrub_one_page(pg); > + scrub_one_page(&pg[i]); > } > > pg[i].count_info |= PGC_static; I had to re-base this change over commit 6ff0cfbfd4f7 ("mm: allow page scrubbing routine(s) to be arch controlled"), dating back to July last year. Please can you make sure to submit patches against the tip of staging, and in particular not against any older (release) branch? Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 08:14:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 08:14:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461920.1672930 (Exim 4.92) (envelope-from ) id 1xLcK5-0004H0-9c; Tue, 27 Oct 2026 08:14:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461920.1672930; Tue, 27 Oct 2026 08: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 1xLcK5-0004Gt-6r; Tue, 27 Oct 2026 08:14:21 +0000 Received: by outflank-mailman (input) for mailman id 1461920; Tue, 27 Oct 2026 08:14:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLcK3-0004Gn-H5 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:14:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLcK2-003Alg-D0 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:14:18 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae05d53-bab6-0a2a0a5309dd-0a2a450ab8ec-12 for ; Tue, 27 Oct 2026 09:14:17 +0100 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 6ae05d59-f2d2-0a2a450a0019-b9ff1c2389a9-3 for ; Tue, 27 Oct 2026 09:14:17 +0100 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 1a17c6c9c7f000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 27 Oct 2026 08:14:15 +0000 Received: from [192.168.1.97] (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter) by mail2.vates.fr (Postfix) with ESMTPSA id 5F665829D8; Tue, 27 Oct 2026 09:14:14 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=mP1E4f/D/4/Sg6JJ6IW5yxH/NtEy4J0g69BwIujVRoM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=I12N7Fs5HAwmWeLcUN90mf++k3QjHxUVD12XVzQnRUsTZBByw52xyKTd/XjRII7Xm9Uh1S7zY YutBIUx0rqYVgKHI5YJRhutVFOYznW6siaoJSSqiihMQ7kXV7y7hpAWCMDV6zvpyNL0UNXTlcXH OOlWUTkiatB2OZceV68v9F4jiNDtWzgqRIzVGOVGkiJ1+luG1hOEfmnmhZCNF4yvtYd9LDGAUKB RNP9g8VHiwxV5n50SkPJSVCpcVH77ZdSaxgN7oNKd2uFLXecePgPIjw912EQrekHo2oZ7s8satl /MB2+p6yGUfR7gnsufdFSwRExwVen8o8eVuDwFDrdaRg== X-Zone-Loop: 18d3fa0d6c09877fa4b2405245f58df04b8f3328bdb1 x-campaign-type: default x-transaction-id: 681e509e-e1a3-4f59-9a3a-255811de0d37 x-swg-uid: 01-5373029a-9905-403a-b339-dd407479fd19 X-Mailer: Sweego Message-ID: <1793088855.8631fc262581453bbf619ec5b2062170.1a17c6c9c7f000f79f@vates.tech> x-swg-bid: 1793088855.8631fc262581453bbf619ec5b2062170.1a17c6c9c7f000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 27 Oct 2026 09:14:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tools/ocaml: Gitlab CI test for bindings To: Andrew Cooper , Xen-devel Cc: Andrii Sultanov , Guillaume Thouvenin References: <20261026162039.1188760-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Julian Vetter In-Reply-To: <20261026162039.1188760-1-andrew.cooper3@citrix.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.21e.76e20aae512521d0.1a17c6c99f1.ebcbb46c7156d688=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793088854513 X-purgate-ID: tlsNG-4011c0/1793088857-5A5DBCFC-FF5BEFF7/0/0 X-purgate-type: clean X-purgate-size: 826 ---=Part.21e.76e20aae512521d0.1a17c6c99f1.ebcbb46c7156d688=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > + printf "Xen version: %d=2E%d%s\n" ver=2Emajor ver=2Eminor ver=2Eextra > + > + > +let () =3D > + printf "Test Ocaml Bindings\n%!"; > + > + test_xenversion (); > + > + printf "Starting GC=2Ecompact()\n%!"; > + Gc=2Ecompact (); > + printf "GC done\n"; > + > + () >=20 > base-commit: 46678752be2d97f61317d793408a59927a429847 Thank you Andrew, I will add the other test next to this one=2E Acked-by: Julian Vetter -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.21e.76e20aae512521d0.1a17c6c99f1.ebcbb46c7156d688=--- From xen-devel-bounces@lists.xenproject.org Tue Oct 27 08:18:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 08:18:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461928.1672939 (Exim 4.92) (envelope-from ) id 1xLcOP-00058z-Q4; Tue, 27 Oct 2026 08:18:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461928.1672939; Tue, 27 Oct 2026 08:18: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 1xLcOP-00058s-NH; Tue, 27 Oct 2026 08:18:49 +0000 Received: by outflank-mailman (input) for mailman id 1461928; Tue, 27 Oct 2026 08:18:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLcOO-00058m-8G for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:18:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLcON-003Bhv-GT for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:18:47 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae05e5a-e002-0a2a0a5209dd-0a2a4508bf94-40 for ; Tue, 27 Oct 2026 09:18:46 +0100 Received: from [40.93.195.10] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae05e64-f659-0a2a45080019-285dc30a2600-3 for ; Tue, 27 Oct 2026 09:18:46 +0100 Received: from BL0PR12MB4754.namprd12.prod.outlook.com (2603:10b6:208:8e::26) by DM3PR12MB9351.namprd12.prod.outlook.com (2603:10b6:8:1ac::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 08:18:41 +0000 Received: from BL0PR12MB4754.namprd12.prod.outlook.com ([fe80::ebe5:87e:6d95:580c]) by BL0PR12MB4754.namprd12.prod.outlook.com ([fe80::ebe5:87e:6d95:580c%4]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 08:18: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=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=emHTi+Iuor0GtPzEY/WCIHjfwaJHPTaW/w18Ad2rGTeovXqLmI4kZ80876kymiOb0RNfQxWHgtLM+gBldziKa9j9GMJBj0mbvWz/uAsl5OJXrwta6puiatuEATrvRJ70xovvi9Xgz3U+3U01UK9hUuLA/hdQ34lMFcIt1eMRXCAc2OqX4c063kpWYnXAmc3NvNhJNjddbXD7TQU9s+9WIUwTuBF2OQfRhQHP+oyZbYydM3j8quZ+TRp89eMnf/DRJ4DpThogNQxGLwLdDerTZdcgrBtNGIgiwrA2KDlGybx8j4mpnV3Rq/tmk1a2ExurMgrVvxRmEtTdJn16UztLpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nr1TFgrkX5oNNpNc1S5p8yeuodf6f8dd0a+oIT7WHgs=; b=VrkOWjH/zMk8aYNECL8LdjD/Euck6kpDh3uUWmuYTlW1vMbVA/y1ea+Ba5NSBM0FXrGF0OMuL14MAc5qpcdkkMbL+7G28N8QeIyOEv8vh1klJ6bAiHfUOMRrkWiMdo1SQxpeZJifEKKSYfzBPOCalEh0gLOYXg7JpVs/391wycUjqOxlS6+Y2kpgIf1dvklzkaAwH/EcyElWt97lgZlJoIao5iLhIUFp66PS3KceKLLAml62RAUgx/cEtR8LJU2woeZQbYjhO5hc0UElIRmeCbVgDLJG7prU80Www2Yb3sVJl8yEsTAuQ4evtONhfqTpdThMiKmRtdW1yZCVn5VLXw== 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=Nr1TFgrkX5oNNpNc1S5p8yeuodf6f8dd0a+oIT7WHgs=; b=XuKe75Pqf+VMiTBzv1Dx6z3waxmKklzGgOtEq+NlJ2VZNACDr1jrrhaNT5lxbgw1DPRTBZgbSdCwErAJIVzwg5wOMsMdubu/u54rUV0+/CB47YsUS6HdjYg3Yj6HG6lTe4v7GKySfH5SwWJkIrhwy6TwAviy+e5jRnn5evpBrlk= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <321e7082-5cd2-4a41-9c49-ff091d9ceade@amd.com> Date: Tue, 27 Oct 2026 16:18:32 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations To: Jan Beulich , Stefano Stabellini Cc: Nicola Vetrini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org References: <20261026030309.2507461-1-shuaidong.chen@amd.com> <67e298cd-3b84-4476-9dd3-607e505effe6@suse.com> Content-Language: en-US From: "Chen, Shuaidong" In-Reply-To: <67e298cd-3b84-4476-9dd3-607e505effe6@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TP0P295CA0003.TWNP295.PROD.OUTLOOK.COM (2603:1096:910:2::9) To BL0PR12MB4754.namprd12.prod.outlook.com (2603:10b6:208:8e::26) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL0PR12MB4754:EE_|DM3PR12MB9351:EE_ X-MS-Office365-Filtering-Correlation-Id: d59ebb2c-da6d-44fb-5f8d-08df3402e8ed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|6133799003|18002099003|261026121527099003|22082099003|10067099003|5023799004|56012099006|11063799006|4143699003|261009223027099003|261021121427099003|261022075727099003|261021123027099003|261022105027099003|261021135927099003|261026140227099003; X-Microsoft-Antispam-Message-Info: ecsWPfzxvHTVFJ+v+p8TTtBdOiN70iOryVDZ7fhdcW5iQns0HXHfkUWS+9SJf5kSkAMSEPMbLYCxHluDc7ojxaYYRpuuR2Tn6FTZs6bGAJHILcFKMIjeEEB3VpSHaxAE9ESsigGCdnDh6UgI0sLFFWOHXWfcpy6nJIECxs0v+ayjXNjkmDl8hmeV5mQs3Tg2VoFEMxYED+jdg96E/Wg8teFmjloRtYE7EFBx/TC0H3p2EiygkQVx+nfnvMYV4dWw44rQUwu9q5bvsps0HYSrmhOR4orUhWaCMapjYPBzslBotdcqikbNV2HPlRXJaEwhL+PmrvLYrYl0Ka83P3Rnch74Nc3y2KLoKdqZaVEgKmneB7Y1W+a1HJny1yDMh4OQ+yvMcx/O3VPak2u3XmLkwlvyMmHdRaYLXB8a5WTXK+jxt9lWSobY+aqclpWtnptk6Hno59BqPaubSjcZ2nGok3HCBfRJjpx6RJOWu+ggjvUzhPf7Js7g8PH6pgQdrJ+1jDuJj458DUk4s2eirAwEDEaI++F8CFIq4CbPjJ8k0ucab+sJxk40U1dcXVS+JGktckUhmuZsYHehH1e4bLOUEDiIIPDyO4tov6KVNcWt2z4DEaE6ZTuQjygZ5XPaT0c4bbmbio92r1XaNoghOU4Z6NFQKWVfOpISURCwygu+flc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL0PR12MB4754.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(6133799003)(18002099003)(261026121527099003)(22082099003)(10067099003)(5023799004)(56012099006)(11063799006)(4143699003)(261009223027099003)(261021121427099003)(261022075727099003)(261021123027099003)(261022105027099003)(261021135927099003)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b0hVQVpwZHdUb0JGMllsTENvSUF6TGhyQm5TQmhhaW15ZTAxa2pTbWc1cXFL?= =?utf-8?B?WkkzY1JubUZrdkpoU1FBaVA0OE9wbG5heTYwUnNvKzBPV1I0YUdlbmNYSUcy?= =?utf-8?B?dXlaaXBiMjJvVVdjQmFMR09vZnBVMkgrTkxvLzcxWWs2UGRCK2ZneWIrVkk5?= =?utf-8?B?aytUQlBTYU1hRCtWL1FxT3RuMHdpamlEdENQOGpxS1FFK3c2cE5XU0QzVzdB?= =?utf-8?B?alRMTWxzS2IyZTJwS1I0UUo4QW9ISVlaeWxWMFpTbXh3a0VidzZSSnpkbndt?= =?utf-8?B?Um5QNFMvamJqbjNUL2h6bE1Rekt3dk1aSmJCTlplaTNvbmlINzhJa1JHY2Zt?= =?utf-8?B?RUQvUDBiekQwZlp0TDEyanhWRzYwVTZHeStrVXNJZmo5a1YwK3B6a21JT0xZ?= =?utf-8?B?cVI5LzcrQ2tLZDhUenREREllSmE3bEFHZDVwQm02ZHlsRmUwZmlkS0xlZ1hO?= =?utf-8?B?VUVjRysvaWQvV2Vtdk40dmYwMTRyeU9IdURhcUEyMDE5clQ5VlZwRWo0aWVm?= =?utf-8?B?M0tVTkZWanc0cEgwUEp6blErNkp1SlVHdkcyQytVTFdSZk9GeW9oT0RMWmJG?= =?utf-8?B?Q0pwV2ZRMlVTOFhhUzRyNGdteGI3akwzRnlKTmRtc1daTnFaWjR0Q0dOVDJa?= =?utf-8?B?TVFHUlU5eTBrWDlsL1BtbzFrb1FQM1ptQkF4Q0VJenVaQ29vT01yTUEyQnBC?= =?utf-8?B?TVdJQWtJR0RqSjlJQnJ1ekxGd3RHbFhWYmg0Nk84YjlwRE9iOS96ZVFHWXNl?= =?utf-8?B?T2xrTm83aWpscjVlNko4RG4yZlJWSCtEeFdBRjJHV3d3OXJ0SVpWOGMrTDVk?= =?utf-8?B?S0U2UzcwY2dZSmpiaGZmU2FXRFZNbEFsL1h3V21LT0R1eUxOVG5EaEpqVUhD?= =?utf-8?B?eEhTbkVoNjhTUDFROXRQMnBsWGdWL0YzVWFTZm9ycnJNM0plYWd2WXdMbGRs?= =?utf-8?B?OFpyS3dSOGJiSmd4cWlkQjVEZ0lhMUxsRG84ZUlDQVhUZE5GVTVaaEUyRTJq?= =?utf-8?B?a091NUJUZnpyWUVBaHRiZkRsV2Z4clpnQU9WUVdpVTdsSlRoU1dGZU9BYnJ5?= =?utf-8?B?YmEvaVZkNFpyTTdhRDJPUjh0Q3I5M1NiM3JsL2hOYTRtOUJ3UGJ6aEhjUHJk?= =?utf-8?B?cGxITEJyRnNEYm1tR01ZSWMrMjhnOFhmL2Q2RzJXajlVT1U1RnJsb2YxRGRR?= =?utf-8?B?MWtQY0V4LzBxdkU1R2VBZnExczgraHB0TGZ3YVk4Z3pDazBjOFBmdG1DT2xk?= =?utf-8?B?Y1pzeE13YzRLQWN1MWNGVVUyKzBzWXlNdzF5ckszYm9IMkdKZFh3b0VQbUdR?= =?utf-8?B?d2szR3pzK3ZSNk5STVIwZ2FnVHZuanJCNnZvQnNlNkxlZG5QMU5BSkpua3Rk?= =?utf-8?B?ZHpDTWdwR1dDeU9VS2VUbHg4cmJiQlJscDVUTlFYVFgyQ2ViNWFiakl3UDVV?= =?utf-8?B?RW12bDVGNndhQVgvcmhMck1ZSnBQQTl2KytYUm1VTklSQXM1dVhIZVZNUkND?= =?utf-8?B?TXFUWk44b3d2ZEl2U2VFU0ltdFhBNDg0NzROZUZZQTdlUm42Q1hhNEV6aVhi?= =?utf-8?B?MUJZVk5SdkRoZlEra2d3Vmtkc1h2a0J4aG9TYi9nOHFVanc5OGpVT1BsbmFo?= =?utf-8?B?aklueHQ4MWIwN0NKRGhmSjY3bStxNTZKdzFkYjZRT01NZUYzTlgvNTNUZWd4?= =?utf-8?B?MnZmTHBCWlk4MGo0bWdWNTBQd0hBNmhMeHZrb3Jyb1VhaUkwV1JJTzFWbzN1?= =?utf-8?B?RzN3SzRoajExRzFtOU5QcVM2TW4wZmlML2o5VS9Na091MG1aKzNmSkFaSlRs?= =?utf-8?B?blJzUDgxWTV0Szk0WXpVUU5OVnRObEZ3RUNHOVIzcm9hUm8zTDNPNmxmMk9w?= =?utf-8?B?a1FZV2hlWTBoTGFpeW55MVVObGJ6RFNjM2RyRHVwbWxsaE5XMnpzWWMvZjRI?= =?utf-8?B?bm5Cc2JZZ0FZbTJYQkVZOHlkU3M5MkRoRVFnTG4xL0prSk5KdlRlUlVDdDBP?= =?utf-8?B?Zi82bEdNKzFTZG5LMncxTVR0Y25rZmtuU1BGZk5VRFB1ZWNCUDV6aFpqaEdH?= =?utf-8?B?dXRtMkhsZVZZT29KNEZMMkQ0bzNBRERzYm9teTdhOXpuTzN1MkJrSkEyTUV1?= =?utf-8?B?T2lURWVSdEUxYVZ1Y3A3NGtjMCtOTnI0Vlp6SlRXTGV1ODZzL093ZFpMR3lz?= =?utf-8?B?T2NTMXBOTGEyT2F2UHo5Mm0xbURNU0FwWVhjOW9EQU4vbTB2SjZZS29pakU1?= =?utf-8?B?aktzc1lXOUc0aEliYVlDSUFCSEhESnB1cTBxTjh0YWhFK2hycEJaWWs3TFpW?= =?utf-8?Q?aAM7HvNBDq6xJ0eRyA?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: d59ebb2c-da6d-44fb-5f8d-08df3402e8ed X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB4754.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 08:18:41.5911 (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: kWJf85ThKSSYSCBlq8tbUTK5FJIn9lSgnypMjYbLO0fqbpOWRyQ776ZEWZYUvSEjhhWRuuWD7xL39DfYY7qAog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9351 X-purgate-ID: tlsNG-c1860d/1793089126-CEF5F87B-5C80A99E/0/0 X-purgate-type: clean X-purgate-size: 4215 On 10/26/2026 9:14 PM, Jan Beulich wrote: > On 26.10.2026 04:03, Shuaidong Chen wrote: >> MC3A2.R14.3 ("Controlling expressions shall not be invariant") is >> deviated by two separate entries. One covers 'if' statements and >> conditional operators and places no restriction on where the invariant >> condition comes from. The other covers 'switch' statements, but only >> when the controlling expression is a 'sizeof' operator. >> >> The rationale recorded for the two is the same: the condition is >> deliberate. Nothing about a 'switch' makes an invariant condition less >> deliberate than the same condition in an 'if', so the 'sizeof' >> restriction reads as an artefact of that entry having been added for >> read_atomic() and friends in arch/x86/include/asm/atomic.h rather than >> as a considered limit. > Well, > > if ( 1 ) > > can make sense, especially when 1 is the expansion of e.g. IS_ENABLED(). > Otoh > > switch ( 1 ) > > doesn't make a lot of sense, even when it's as a result of the expanding > IS_ENABLED(). I agree that limiting to just sizeof() is unnecessarily > strict; alignof(), for example, should about always be usable where > sizeof() is. Yet making if() and switch() equal is imo going too far. I > realize though that it may be difficult to find a suitable boundary. > Stefano - do you possibly still have notes from the discussions long ago? > >> Fold switch_stmt into the general entry and drop the 'sizeof'-restricted >> one, which the general predicate now subsumes. Invariant 'switch' >> conditions that are not a 'sizeof' become deliberate as a result; that >> is the intent. >> >> Signed-off-by: Shuaidong Chen > What you don't say at all: Does this help with any remaining violations? > > Jan Yes, and let me give the full context, since the motivation comes from downstream safety work rather than from the upstream analysis. On safety branch one of the techniques we rely on there is to pin build-time configuration to compile-time constants, so that the code which the intended configuration can never reach is removed by the compiler rather than merely left untested.  That matters for us in two ways: code eliminated at compile time does not enter the coverage denominator, and - more importantly - it is not in the binary at all, so it does not have to be carried through the whole qualification chain. Two examples: https://gitlab.com/amd-xen-safety/xen/-/commit/160dac43f554733a68d83c38cc1d0e73b3b7bff0 https://gitlab.com/amd-xen-safety/xen/-/commit/e0eccfa7184b7acee23916cd5cb2a3b5afa101f2 A side effect of this is that some of those constants end up as the controlling expression of an switch statement, which then trips R14.3. > Otoh switch ( 1 ) doesn't make a lot of sense Agreed in the abstract, and I would push back on anyone writing that by hand.  But that is not what happens here.  The sources still read   switch ( gt->gt_version )   switch ( opt_bootscrub ) exactly as upstream wrote them, against what upstream intends as a runtime-variable value.  The constant only appears after a build configuration specialises that value.  So the construct is not a pointless switch on a literal; it is ordinary upstream code that a particular configuration has made invariant - which is precisely the situation the existing 'deliberate' deviation for if statements and conditional operators already covers. Of course the other alternative: rewrite those switches as if/else chains, which the existing deviation would already cover it, and the violations gone. Technically that works. The reason I would rather not is that it is churn in common code for no functional reason, carried indefinitely as a delta against upstream, and it makes every subsequent rebase of the safety branch more expensive. Having seen that a deviation for switch already exists - restricted to sizeof - extending it to switch in general seemed the smaller and more honest change: it states that an invariant switch condition is deliberate, just as the project already states for if and for the conditional operators. -Shuaidong From xen-devel-bounces@lists.xenproject.org Tue Oct 27 08:53:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 08:53:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461935.1672948 (Exim 4.92) (envelope-from ) id 1xLcvG-0002sJ-9i; Tue, 27 Oct 2026 08:52:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461935.1672948; Tue, 27 Oct 2026 08:52: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 1xLcvG-0002sC-6g; Tue, 27 Oct 2026 08:52:46 +0000 Received: by outflank-mailman (input) for mailman id 1461935; Tue, 27 Oct 2026 08:52:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLcvF-0002s6-50 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 08:52:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLcvD-0071Lk-Mp for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:52:43 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae06642-e002-0a2a0a5209dd-0a2a450399e4-36 for ; Tue, 27 Oct 2026 09:52:43 +0100 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 6ae0665b-fae8-0a2a45030019-c387df8399b6-3 for ; Tue, 27 Oct 2026 09:52:43 +0100 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 288521F7E6; Tue, 27 Oct 2026 08:52:42 +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 D38AE13319; Tue, 27 Oct 2026 08:52:41 +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 COoeLFlm4GpaKwAAD6G6ig (envelope-from ); Tue, 27 Oct 2026 08:52: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=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=1793091163; 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=3NxTD9fOBgAuMUX3NOVUDP3OcV9V5L8vJVjDS3OLevI=; b=bYvTEXQMiXO7f8dUvdWJY4ZcU6Cdxw/MEppPWMu7dyfeTP4XGaq1ZHZ5A57zIXArkKb+4a w8vws9pdDRArWwjAxwCIpEX8mxIo8N4cXjc7waIOa5z70NK+T1dFmeJiMZimPFetxKl4f6 AGSAGIroKLCFSrABMTrse/cHqbZl7RI= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1793091162; 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=3NxTD9fOBgAuMUX3NOVUDP3OcV9V5L8vJVjDS3OLevI=; b=D7sG0OyJKieQDx3Ey0amykMrjgkaj7gtWblEG5/kD9YPr475dmq2G3/FsVekqu1xUGktSR sfZmBw62yFG4PXD7msaPczJLS2f/eJJLs3RdaK1Xzqdn+q6nw7KJwtgsAwTLX/YMV1rXaz HfSmItjztiYg5pL6G5FYiX0PICHvl6g= Message-ID: Date: Tue, 27 Oct 2026 09:52:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/sched: Fix the sorted insertion in sched_domain_insert_unit() To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: dfaggioli@suse.com, gwd@xenproject.org, jbeulich@suse.com References: <20261020223534.3703199-1-stefano.stabellini@amd.com> <20261026233936.1330117-1-stefano.stabellini@amd.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: <20261026233936.1330117-1-stefano.stabellini@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Dc9wEcxUdbZ3pyLSgEnr0b0c" X-Spam-Flag: NO X-Spam-Level: X-Spamd-Result: default: False [-9.69 / 50.00]; SUSE_INTERNAL_BYPASS(-9.00)[]; NEURAL_SPAM_LONG(3.50)[0.999]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; 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:email,amd.com:email]; HAS_ATTACHMENT(0.00)[] X-Spam-Score: -9.69 X-purgate-ID: tlsNG-33051d/1793091163-770F64E9-E8517DA5/35/110847 X-purgate-type: clean X-purgate-size: 8518 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Dc9wEcxUdbZ3pyLSgEnr0b0c Content-Type: multipart/mixed; boundary="------------RlbGuVpJ031jMbXc7NDv2vJB"; protected-headers="v1" From: Juergen Gross To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: dfaggioli@suse.com, gwd@xenproject.org, jbeulich@suse.com Message-ID: Subject: Re: [PATCH v2] xen/sched: Fix the sorted insertion in sched_domain_insert_unit() References: <20261020223534.3703199-1-stefano.stabellini@amd.com> <20261026233936.1330117-1-stefano.stabellini@amd.com> In-Reply-To: <20261026233936.1330117-1-stefano.stabellini@amd.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= --------------RlbGuVpJ031jMbXc7NDv2vJB Content-Type: multipart/mixed; boundary="------------u4xyw1YSnap0ZaX3W6h2Ob1f" --------------u4xyw1YSnap0ZaX3W6h2Ob1f Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjcuMTAuMjYgMDA6MzksIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gVGhlIGxv b3AgbGlua3MgdGhlIG5ldyB1bml0IGluIGZyb250IG9mIHRoZSB1bml0IHdob3NlIHN1Y2Nl c3NvciBoYXMgYQ0KPiBoaWdoZXIgdW5pdF9pZCwgcmF0aGVyIHRoYW4gYWZ0ZXIgaXQ6IGlu c2VydGluZyAxIGludG8gezAsIDJ9IGdpdmVzDQo+IHsxLCAwLCAyfS4gU3RvcCBhdCB0aGUg Zmlyc3QgdW5pdCB3aXRoIGEgaGlnaGVyIHVuaXRfaWQgaW5zdGVhZC4NCj4gDQo+IFRoaXMg Z29lcyB1bm5vdGljZWQgYXMgbG9uZyBhcyB1bml0cyBhcmUgaW5zZXJ0ZWQgaW4gdW5pdF9p ZCBvcmRlciwgYXMNCj4gZ3Vlc3QgdkNQVXMgdHlwaWNhbGx5IGFyZS4NCj4gDQo+IEFsc28g cmVuYW1lIHByZXZfdW5pdCB0byBuZXh0X3VuaXQ6IHRoZSBuZXcgdW5pdCBpcyBsaW5rZWQg aW4gZnJvbnQgb2YNCj4gKm5leHRfdW5pdCwgbm90IGFmdGVyIGl0Lg0KPiANCj4gRml4ZXM6 IDE0MWRiN2ZkNGQyZCAoInhlbi9zY2hlZDogYnVpbGQgYSBsaW5rZWQgbGlzdCBvZiBzdHJ1 Y3Qgc2NoZWRfdW5pdCIpDQo+IFNpZ25lZC1vZmYtYnk6IFN0ZWZhbm8gU3RhYmVsbGluaSA8 c3RlZmFuby5zdGFiZWxsaW5pQGFtZC5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdy b3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------u4xyw1YSnap0ZaX3W6h2Ob1f 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----- --------------u4xyw1YSnap0ZaX3W6h2Ob1f-- --------------RlbGuVpJ031jMbXc7NDv2vJB-- --------------Dc9wEcxUdbZ3pyLSgEnr0b0c 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/Ey8FAmrgZlkFAwAAAAAACgkQsN6d1ii/Ey83 9Qf/VmGyvkR7a2lImubpWGHWEI6vAemdcSllT8VosCrkGvGM7FMYhTlpzToMcQYJSFGQBpHyQKF4 C/TuXbWMGBICohWngCme2tdkNTJu776An3m45R4jr49JZmgTo/ie/4ZBFnXi+qChpMh36JvWNbSg fwknlgpcTvGzoFV8dKiV8j6e6oc2kDbHNgi90E4Rfw7v5qWSgj6Pbty/+FL/PidlhU5Jphkubp8y Usnesv+H8oQtLHpWqsKLhSqdAKC3bNK1MF+3SXc0fjmqHp5+D5AmWNSCBmG/aFCBoY93YK1Qu2oo d5vwEwwmxn1Q5pwcIWV9TJLs4PMpPtT5tAM+sV1a9Q== =ykd/ -----END PGP SIGNATURE----- --------------Dc9wEcxUdbZ3pyLSgEnr0b0c-- From xen-devel-bounces@lists.xenproject.org Tue Oct 27 09:03:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 09:03:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461945.1672958 (Exim 4.92) (envelope-from ) id 1xLd5U-00057U-AK; Tue, 27 Oct 2026 09:03:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461945.1672958; Tue, 27 Oct 2026 09:03: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 1xLd5U-00057N-6w; Tue, 27 Oct 2026 09:03:20 +0000 Received: by outflank-mailman (input) for mailman id 1461945; Tue, 27 Oct 2026 09:03:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLd5T-00057H-9I for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:03:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLd5S-003Lvq-EQ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:03:18 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae068c7-8faa-0a2a0a5109dd-0a2a450c9a7c-40 for ; Tue, 27 Oct 2026 10:03:18 +0100 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae068d6-f479-0a2a450c0019-d155dd34f064-3 for ; Tue, 27 Oct 2026 10:03:18 +0100 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48e04773687so1262406f8f.2 for ; Tue, 27 Oct 2026 02:03:18 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3eb8f37csm17545198f8f.8.2026.10.27.02.03.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 02:03: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: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=1793091798; x=1793696598; 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=dxjO1Kv2vQzQyD/gkkSr+kz1ao5O4z6geQtsdpKJpt0=; b=GCAhdSESawOWqyzTfl9yqznlhhA59j9QHHiQ6zeWQt3TfYx6PHTq7zYWwHYDSbdxLA MD7EnXp5s4/cAQX52SPFDxVa7eV5FmfGll9+eL0A4LfO9vnaN6tXP0ts9G2wo3tN7EtW yWzaZuGR5LTmbcZmT3m2rCSB2eguCh2wVJSMen4w2JXL3866+lTsiw86cr6BvN+6tOwY ChXFbIpQsmboMPcaFuU7S5LyIyvcxPB3o1PQUYtv5gkTKTOJlUrrtYakCDCSuQ8fVyHa psBov7qEmwezPfhDLpiAuvtkuFyiRIz7A00IHQ9YImGwNo1uj/WYsX3rxtH88RWEAUU7 J+KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793091798; x=1793696598; 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=dxjO1Kv2vQzQyD/gkkSr+kz1ao5O4z6geQtsdpKJpt0=; b=ZGAQPwvuryMXemC/eiJ53T/TUffMo5KoHGxMmsVca2rmBqxc1vS1XrNKB2X9aO1fLN 6G99gTY8FmRBO7xmrtj1J0UJpF5iuAJz09JWDplylQryO0NZ2LZN6pKSaJTXG02kHWpJ YeZAIJy3GcKuuthQkiWeIzBZhO0rLfI2DrK7U9YKwCZxUz5j5EPo2yfTL75EEsRJDzPV DLuat98PtJYR4rzFmZRsaMyds6ECYDp3Q4YeEvlnLcBJ531wk2C8WicGSQ5/fOftHZkB 2QsSEUWQTZ3DfTZpmyGLAxGiezC3JcT2nNBjCWn/5di49FenfHhTh6b92Mihv+oLUtJ0 C2XA== X-Forwarded-Encrypted: i=1; AKwUvByw2arbIR8DEW113ccDrp6ZOxhrgf3tdyKhKgtrjIZ3Un/p211dBjjnw5j6J3liqD8pGmioL4a1PKY=@lists.xenproject.org X-Gm-Message-State: AFq9FYJLq/Qm6Aw28bVrmBWJfR5PuvFqyo2HtC1KKy7LxQKBj/JRTWRF mqyNpUHvB5yaB5URTQGU18AUP8Q4EczeUbFq25bxgDJn1qx+8CYIoqPL X-Gm-Gg: AYBFou1CGgYShhTTjGVuv1cAsMumsnrBgMHzyCSDDxyfGpX1vWdWGbdsmjphzZhSbUX kCcwcNKxVdE3CLpmDjBcg1bnBPplslYFqPdY/3Sq3IUOPBNuoy147tYJmqZN5MeLT1VVT/XuKG/ IinZAJy1rAVl0jAtHjtpH+GNTen+U5Tp2047bqKqFFB2gbIssmon8fuClAjXU/3NM86SaxAVo6A ZoSqfQflYrtmfi4iaRWCD6RLN1MXUuGy8SJQF68rHMmg59vHzVNwMmWvBhMshxSp0pU5yvNS9Tz u1ZkwgHr+fQRNIP3pkxwIR5GtOqjzBkjRgEGIvwsAM5+S6YrNABnqtua1hzcN10WN9n0zouz9+c dAYARvSjpO6+X5XEBM8UmsqWywLInPHOxIgSb1pFddP41xNzBPlklMP/eXX/w5KY96AhSBv6cZq mXUUttOG/a7sm7yeWE+AYyjO+nO2+nEisPy3CAvCRrj6EA7V/BG9KxS8U/tn5St8ZB7plGYWHLT WmG5PUK5ceOkbDmK/z5NA5aVQzW1TeJ97wXNK8hUKljmdTNM3/1hLyRFwUoEzTFCC4PHvRtD6o6 m/n8XmPgbbP3CHD/zYjg99+Xyjgx8g== X-Received: by 2002:a05:6000:29ce:b0:48d:eb6b:9d0f with SMTP id ffacd0b85a97d-48e3eb6153emr9966461f8f.11.1793091797475; Tue, 27 Oct 2026 02:03:17 -0700 (PDT) Message-ID: <6c0d9aa3-fb6e-4916-bea2-033f3f9dad96@gmail.com> Date: Tue, 27 Oct 2026 10:03:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Jan Beulich , Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> <9986e03e-bf09-46b6-9d2a-82a1864a59b5@gmail.com> <462a149d-9a4a-49c7-8db4-96e99463a47b@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <462a149d-9a4a-49c7-8db4-96e99463a47b@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1793091798-028DDA5B-48ADD289/10/78276251493 X-purgate-type: spam X-purgate-size: 1810 On 10/26/26 5:59 PM, Jan Beulich wrote: > On 26.10.2026 16:35, Oleksii Kurochko wrote: >> On 10/26/26 4:14 PM, Baptiste Le Duc wrote: >>> +/* >>> + * Probe whether hardware updates the PTE A/D bits by writing to a local >>> + * variable through an alias mapping whose A and D bits are clear. >>> + * >>> + * Check the D bit rather than the A bit, as the A bit may be set >>> + * speculatively while the D bit can't. > > Following Andrew's clarification, I don't think this is relevant anymore > (but I also don't mind it to stay the way it is): If we observed the A > bit set (and no fault), we can still deduce Svadu, no matter whether the > update was due to an architectural or a speculative access. Svade would > implicitly disallow speculative updates of A, as exceptions may only be > raised for architectural accesses (unless there are provisions in the > spec that I'm unaware of). > > Both of you: Please clarify whether you want this change to go in as-is, > or whether this wants updating again. I'd prefer to update it: the statement itself is true, but it isn't a reason to check D rather than A, since, as you say, observing A set without a fault would equally imply Svadu. If you're fine adjusting it while committing, the second paragraph could become: Check the D bit, as it is set only once the store through the alias has been performed. (or just be dropped), with the matching sentence in the description ("The D bit is checked rather than the A bit, as the A bit may be set speculatively.") dropped as well. Otherwise Baptiste, please send an updated version. ~ Oleksii > >> Generally, looks good to me: >> >> Reviewed-by: Oleksii Kurochko > > Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Oct 27 09:13:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 09:13:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461954.1672967 (Exim 4.92) (envelope-from ) id 1xLdFG-0007B8-5B; Tue, 27 Oct 2026 09:13:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461954.1672967; Tue, 27 Oct 2026 09:13: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 1xLdFG-0007B1-24; Tue, 27 Oct 2026 09:13:26 +0000 Received: by outflank-mailman (input) for mailman id 1461954; Tue, 27 Oct 2026 09:13:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLdFE-0007Av-M9 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:13:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLdFD-005sJn-VT for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:13:23 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae06b31-2eae-0a2a0a5409dd-0a2a4508c8b2-0 for ; Tue, 27 Oct 2026 10:13:21 +0100 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 6ae06b30-f659-0a2a45080019-b9ff1c12956d-3 for ; Tue, 27 Oct 2026 10:13:21 +0100 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 1a17ca29f29000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 27 Oct 2026 09:13:14 +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 D66B181AA4; Tue, 27 Oct 2026 10:13:13 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=s81T04xv/lgrEsv7kGYqY0NyshC4bxFPb0CsU3Jb5TY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=V1sBpF+PYiLclLo3Cmkxxcsh8G9zjrn8V0nBhmlBfzqEhfQzu0naUoWQs/rL8ySV2NcAXGHTB cxrMHwXZ21ijTPpPbBQbYaC+gsh76dFI4X3nFwsNshDc8EJskI7IVO2xUUlUscgaid/YcF+5gdc R+X9WsB3uRsJOc40WoYHGxuCQlT9bteFIvSfYBV6I5uiIjdcHWn5mc3t1W2RpoznxQhk08SK0GG f2eLiNgCj4f9UuSvi2gT7yJVuf2dGYtRv+xRK6GFhjQZLD8Hjmd8JExGT+lfj6QFq1KQFkqhKOQ +c3F+GiaCPJ5PDk4j427eOYFuZ4yOwintnsp+IQdH0HQ== X-Zone-Loop: e18cba564b67b2882393d7e2eff66ee061de2d761204 x-campaign-type: default x-transaction-id: 92650ad0-e08e-42e2-9398-b9193ab18e84 x-swg-uid: 01-00fe84fa-15ef-4463-9a5c-9d4a876a88ac X-Mailer: Sweego Message-ID: <1793092394.8631fc262581453bbf619ec5b2062170.1a17ca29f29000f79f@vates.tech> x-swg-bid: 1793092394.8631fc262581453bbf619ec5b2062170.1a17ca29f29000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 27 Oct 2026 10:13:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 4/5] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Oleksii Kurochko , Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org References: <1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech> <1793027685.8631fc262581453bbf619ec5b2062170.1a178c73a5d000f79f@vates.tech> <9986e03e-bf09-46b6-9d2a-82a1864a59b5@gmail.com> <462a149d-9a4a-49c7-8db4-96e99463a47b@suse.com> <6c0d9aa3-fb6e-4916-bea2-033f3f9dad96@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: <6c0d9aa3-fb6e-4916-bea2-033f3f9dad96@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: 1793092394081 X-purgate-ID: tlsNG-c1860d/1793092401-D6F5F87B-94CA2F81/10/78276251493 X-purgate-type: spam X-purgate-size: 1986 On 10/27/26 10:03 AM, Oleksii Kurochko wrote: > > > On 10/26/26 5:59 PM, Jan Beulich wrote: >> On 26.10.2026 16:35, Oleksii Kurochko wrote: >>> On 10/26/26 4:14 PM, Baptiste Le Duc wrote: >>>> +/* >>>> + * Probe whether hardware updates the PTE A/D bits by writing to a >>>> local >>>> + * variable through an alias mapping whose A and D bits are clear. >>>> + * >>>> + * Check the D bit rather than the A bit, as the A bit may be set >>>> + * speculatively while the D bit can't. >> >> Following Andrew's clarification, I don't think this is relevant anymore >> (but I also don't mind it to stay the way it is): If we observed the A >> bit set (and no fault), we can still deduce Svadu, no matter whether the >> update was due to an architectural or a speculative access. Svade would >> implicitly disallow speculative updates of A, as exceptions may only be >> raised for architectural accesses (unless there are provisions in the >> spec that I'm unaware of). >> >> Both of you: Please clarify whether you want this change to go in as-is, >> or whether this wants updating again. > > I'd prefer to update it: the statement itself is true, but it isn't a > reason to check D rather than A, since, as you say, observing A set > without a fault would equally imply Svadu. > > If you're fine adjusting it while committing, the second paragraph could > become: > Check the D bit, as it is set only once the store through the alias > has been performed. > > (or just be dropped), with the matching sentence in the description > ("The D bit is checked rather than the A bit, as the A bit may be set > speculatively.") dropped as well. Otherwise Baptiste, please send an > updated version. I prefer to change it too, I will send the patch today. > ~ Oleksii > >> >>> Generally, looks good to me: >>> >>> Reviewed-by: Oleksii Kurochko >> >> Acked-by: Jan Beulich Thanks!> From xen-devel-bounces@lists.xenproject.org Tue Oct 27 09:14:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 09:14:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461959.1672976 (Exim 4.92) (envelope-from ) id 1xLdGO-0007eK-Cr; Tue, 27 Oct 2026 09:14:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461959.1672976; Tue, 27 Oct 2026 09: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 1xLdGO-0007eD-AG; Tue, 27 Oct 2026 09:14:36 +0000 Received: by outflank-mailman (input) for mailman id 1461959; Tue, 27 Oct 2026 09:14:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLdGM-0007e4-Ly for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:14:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLdGL-003OBO-RZ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:14:33 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae06b79-e002-0a2a0a5209dd-0a2a4503a574-4 for ; Tue, 27 Oct 2026 10:14:33 +0100 Received: from [52.101.43.65] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae06b75-fae8-0a2a45030019-34652b41aa4b-3 for ; Tue, 27 Oct 2026 10:14:33 +0100 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by CH3PR12MB9344.namprd12.prod.outlook.com (2603:10b6:610:1c8::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 09:14:26 +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.0546.021; Tue, 27 Oct 2026 09: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" 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=FEvmPLYn9MTdl01jn9UBgFj6GUn3vHC86wh0disLEGBS+pv/7XEvumqMnW7nV+92wDeB7HUmYh8Xr8hKvnWiWJZVYtANO0gc7fKjOVdICVg4mVyK3+0Giz/+hop7RkE/qd3bEItcRUpMJHkYYIVL3K06hMg+llKEiX7q/p/9sr2lTpC9u5eKTRM33oKG4RLvIxDnMwQR8Bh+UE7I1mv1KRxIAGeqSoukdLddS6NsS/nG8baEqSCw4GyUgW8EVoVJopBxy0aL7Su9wh78IZgncsitydt7J8KJEnKeCtC9FFIihaXUjdAQ2qgssBWoYJuVB//2h37sKBDtDNEXL5sNtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7eTzM7Z9E3YUeaaRAPgQs78ap9xohOPO6LchaalJcjc=; b=iw5/bDaWFj0tknfwt6WbnFF62QulW5+el0UVurrbFpgybtq/9CZ2otPtXaKvyOkgEjNE9sacWTrESwA2v5uvBpjawctSeRKkuH9+Ai+xwlqh/Pyr/6MHEWV9L2HAFSyTypo0YCEy5p7cIMEjmdwqFaUy9YXXtC11ZNCvhnLps5UEXO/tg3y/o8NYUfmJGJxPRMB/tgI1WHRQ0yjETWD26H+pu83ExqZfVtlA169GMreG2yEe7vVylvlGZ8Nzg/soW9WIGnHhbNHTAMl3vYXOEiAABrqH5Ort8pJw5/HnozCd0AymFtZs+f+/R7nv1l7CmOGMFn5cfi4o4C0QTljqBw== 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=7eTzM7Z9E3YUeaaRAPgQs78ap9xohOPO6LchaalJcjc=; b=OGFPmL7hf1JBSnoMFMGQjSmEMyqE93DRVCydu9FzHQnJX5783THU/oovw7KI8VqczEPqns8M1vOT9ZxxMcR4ONJcUiffQr0rgKzQl6W6tjfJEwJCo5aJvBQA0SXLf1hQGpy+gaeNoP/OErmb+BKGz/4rvSBBWCFNmGi9UceCCKc= 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, 27 Oct 2026 10:14:21 +0100 Message-Id: Cc: "Nicola Vetrini" , "Michal Orzel" , "Andrew Cooper" , "Anthony PERARD" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Doug Goldstein" , "Grygorii Strashko" , "Penny Zheng" , "Ray Huang" , Subject: Re: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations From: "Alejandro Vallejo" To: "Chen, Shuaidong" , "Jan Beulich" , "Stefano Stabellini" X-Mailer: aerc 0.17.0 References: <20261026030309.2507461-1-shuaidong.chen@amd.com> <67e298cd-3b84-4476-9dd3-607e505effe6@suse.com> <321e7082-5cd2-4a41-9c49-ff091d9ceade@amd.com> In-Reply-To: <321e7082-5cd2-4a41-9c49-ff091d9ceade@amd.com> X-ClientProxiedBy: MR1P264CA0202.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:57::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_|CH3PR12MB9344:EE_ X-MS-Office365-Filtering-Correlation-Id: 03814793-c61d-4a06-2af6-08df340ab26d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|7416014|366016|1800799024|261009223027099003|56012099006|261022105027099003|261021123027099003|261022075727099003|261021121427099003|261021135927099003|10067099003|261026121527099003|6133799003|22082099003|18002099003|5023799004|11063799006|4143699003|261026140227099003; X-Microsoft-Antispam-Message-Info: Q01OHklSg4ODDVoLItdge6JVeAC79uBJ8hNeUZWWvHYkqKlSIhtHlhEb2RCU2ucSup9kSA90w+c3DnYNQZ7v7taqXUwHXA3RB4ZEcp0uxLQRVHmqHf6R4MglB6tdDlX1zI8JLt7vfJ+S+wyLOp4DDqw+DJM7kjPMEwWZO/vCgiYw6IcRcMi+d9TcehbpfexzyN/hzHx4GlenPXJyaqrwTODUa54SZmAPmJFuKUTJr0wMyRHnd/3UI7+dwNvAPDCAiN04sJHzsZjd/uSIErFZizPgw3KTcORZVY9YxlW5eMbiE1dKRSyTjOfL7PrQwMtOYVGXVNVNhhgBjFFz828dtdqd9+tTQ6hojCINv3rpKrDJ4oHrW6MByb08qhQgjBs8L7vUb6RwwJKBNO6H24KvPlOD/VWZ0awnMtODfOkmcokui66+nbpbVqDqBfjcCNYtnhB3Bnm2ugmcP0bSOCi9TH4fFrbGLGLwxv085OwZjgodgfh1dBdHjbRKorD4UBA+s3ACN9a8wSgmg1PUAA1VdF9YNbwggyQRn3XeRZWnGZ3zWE1NYRDIRTx/OuPuW/2ZnvEECTrgKUS2Q7xMg8erVZxOOS4BQbaaX9NV5mTMXRDTGFfuunw5BOYPZdKVFqmGzIqapCYFUxECZRkDpTT29DjRkX7R4gotTI9gy3Rsy6Q= 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)(23010399003)(376014)(7416014)(366016)(1800799024)(261009223027099003)(56012099006)(261022105027099003)(261021123027099003)(261022075727099003)(261021121427099003)(261021135927099003)(10067099003)(261026121527099003)(6133799003)(22082099003)(18002099003)(5023799004)(11063799006)(4143699003)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bGtxcFdRbnM5c1R4dkk2WDAvUUNpOEdyNDNVNk9UWkJ3NmFuZ2R3bkl1UVlu?= =?utf-8?B?c2VocjRRS2ZKVmpGcUtvcWlIUldUeE5Gb3U2MzFkWW8vUHdZMytxcnpxSnhr?= =?utf-8?B?ZU9XUVdobUxtYXFRa3UwRUhYZ1ZGKy8ya0Q2RTFTUCtuZEpjNTczOXRXZHp3?= =?utf-8?B?YWRNNVorUGhrcURIQThoUEp4MlJlOUc5NmxCa0ZscStheUNBa0VUY1NsdmVq?= =?utf-8?B?WkNqbzhXMkVRSHM2bDRMSzkvbWlacU11aXhHdlF3ajNOYjdEZlNnT09qZkRx?= =?utf-8?B?QzVEM3BwNlJvQjBEQ1hXZGtteW0rU1pNMU04N3hMRm9oZndNKzFBSldBRC8w?= =?utf-8?B?Ymdqb3Bwem8xc0RBZWVSbmZDZVk0TnhrUmVHa3lDenNOVDJINDhSeHZBa3lC?= =?utf-8?B?ZzdLNC9kWkR0N0lqM0k3YjVCV1Y3eVZORHFNejRWNGtqTnZDU2YxRzBSVkhK?= =?utf-8?B?U3VqRWttcHVqTWcvVkpOT2xHaENLcEduOXRhVXlLTWc0Nm51SXJBOXowVnFu?= =?utf-8?B?aXVUT01hODVyWURBNkI0dVFNSW01SzJDNXJ1WVdpN1hrZE1GMVdkL280dnFM?= =?utf-8?B?eVNtZGFYY2J4bUtsc1VmQ3RablpQUllPVXR5RHFRK1A5dmFLZDVxYmZJdTdk?= =?utf-8?B?eXU3cy91cHhZMGZ2MGlHR0Q4dTMyMzFlSG8vMTMwU2E2Sm52cnhOTERHcGQ2?= =?utf-8?B?T0JZTDI4bUFQMERUakcyeCtRNFRUUzFKTDk2aWR6Q25RcGMrZDR6c2EybmpB?= =?utf-8?B?MEhPTVlaK2ZVMWlvTms5eFowMUlTR2RMOGZJcWV2YW1rdzRiWjBJK2NUaXdP?= =?utf-8?B?TFVTaUZ2QjY5ZTE2WG9RL2ZNa2tvMyt4TUFlM3FzOGw3SklCWEtIc1UyK3M5?= =?utf-8?B?SmJkVGcrYU9YUmQrNndRVXNvNFdDd3g5elM0Z2NWeXNGaFZoTHBHbkIya1NW?= =?utf-8?B?T3lSSDQ1OVRXK1BvcTUrL2FKV0VVcTJjVjZvSk5jWU5PeTZCcDlZc0gyWnZt?= =?utf-8?B?dnlFY29mZlo4N05NU3ZTUU53L2Nra2swTVNrUGdtL3ZzbXdYK3VzT0FXbSsz?= =?utf-8?B?Q05lY2ZMbU9ZSDJVOEhIN2czRXJESG5DSnhtbnA4Y0FMWlUvOC9lZVRPV3d2?= =?utf-8?B?a213SzlFWWp0Nk5yRzFDY3h3clpyb1IyTURFSnJZSnZoZ09sQ1JGZk5XTWx1?= =?utf-8?B?MU40bWk3T2VwTitPUVJ6WG5Odzc1RjBLUUc2dll1V1JLWGQrMzVIZDZtUHRU?= =?utf-8?B?MDFlRi85OW5uUTVPZURYS1dVSEE1cEQyc3VKaUkvTWMvSDMzekRIN3F0K2Ny?= =?utf-8?B?dVN6QzZWY0tnWjA3T2xxSTMwdllIWm9Wb2l5VGZJVE9UQjYxc2lQT00zWmcw?= =?utf-8?B?UWM1MHh3MlVvdERHM2dRMksxeG5KL3k1VjlsZGtnd2preFFRWVhJVGgvQTJx?= =?utf-8?B?SjhBVEZCc3k2eFRDdHdsSzBkR25RMUtkbmJYM0dwV2pSb1hueS96QTRNQkFs?= =?utf-8?B?YUFTdUZheUxyaDUxTzIwcVdVbElqdDRzN3BUREFiM1VWRjVrNVE2LzVDclhT?= =?utf-8?B?WkR1Q1VkZjVVaWI3aTBsNDJDa3VsejRKbkl0aERkWnl0TlNEeTlvSXpFMHFh?= =?utf-8?B?VWo4UzIzNCtjU29paHlyb3o0M3dOMStsbnl3SndDQXZNTTNjWE4rbUptOHlw?= =?utf-8?B?WG9HaXQzYjVMYXlxNUFJS1c2aTA0bUpDcmlCNysxbGRvamNZbThoSjR0UElK?= =?utf-8?B?VndXWDZwUWZEeEdWb3JyQ3B1NUJ0RkZhWFEyOU9MRWQ0MTRxQ1d3N1lJS0lo?= =?utf-8?B?N2lPaElNY3pTdmVjZHA4MG1XbTJ4WE5MaDgxQnF0aGZlRFNod1g1REJ4SHdk?= =?utf-8?B?SEMxdHZ3UG5ZRWlCanNGVkZxMTd2VFdPR3Rlcjc5cEdDY3hzdVhROFNpZGMv?= =?utf-8?B?Sm5VZFFzSzZQOXJGaW1ZVUxuZWFabmxKQm11a25WS2dRcXZVdThkQ2ZscTR2?= =?utf-8?B?anp4dWhIeGJEbmx4ZnJ3d29BOENyL3duR3lLMTNUdmpzdzRINXZHWm44MWNY?= =?utf-8?B?ckhzRGNtYXZOT2NkWEVpYnZyM3NaZm5oWVg5Q2hJWjI1UTZtUjUxY0NGeW8w?= =?utf-8?B?U3lVdldDYTU2K05HSys0TGNhbUEwZ0w3Z3dOUUZkQVdkZWlSRDVFNnh0aDBr?= =?utf-8?B?bTJhbjExa2t0dkpMV0tkSGp5QmlsNmZQNlNyNUNKRmFtU2RZU2MvWlNxRUZx?= =?utf-8?B?U0JqSDUrRVdDZ0dONEQ4SzYwWUptTXNZZVNKS2hrSEI5TVUybFpYbThjU0JP?= =?utf-8?B?RC9XMGlnc0h0bWdJTkVFWjQ4eUE1SHJQR2xiZDBBZXBWbTk4MFZZUT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03814793-c61d-4a06-2af6-08df340ab26d X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 09:14:25.9593 (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: +gobGKvdMHa7+7jrb5uBJeP+PVhRg1A7E3qC+ZIg4HP3CtdkF/vIXzLGEmVSb3nZsKHk3bcOK3SaxToH1Yc4CA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9344 X-purgate-ID: tlsNG-33051d/1793092473-774F44E9-B440E92A/0/0 X-purgate-type: clean X-purgate-size: 5715 On Tue Oct 27, 2026 at 9:18 AM CET, Chen, Shuaidong wrote: > > On 10/26/2026 9:14 PM, Jan Beulich wrote: > > On 26.10.2026 04:03, Shuaidong Chen wrote: > >> MC3A2.R14.3 ("Controlling expressions shall not be invariant") is > >> deviated by two separate entries. One covers 'if' statements and > >> conditional operators and places no restriction on where the invariant > >> condition comes from. The other covers 'switch' statements, but only > >> when the controlling expression is a 'sizeof' operator. > >> > >> The rationale recorded for the two is the same: the condition is > >> deliberate. Nothing about a 'switch' makes an invariant condition les= s > >> deliberate than the same condition in an 'if', so the 'sizeof' > >> restriction reads as an artefact of that entry having been added for > >> read_atomic() and friends in arch/x86/include/asm/atomic.h rather than > >> as a considered limit. > > Well, > > > > if ( 1 ) > > > > can make sense, especially when 1 is the expansion of e.g. IS_ENABLED()= . > > Otoh > > > > switch ( 1 ) > > > > doesn't make a lot of sense, even when it's as a result of the expandin= g > > IS_ENABLED(). I agree that limiting to just sizeof() is unnecessarily > > strict; alignof(), for example, should about always be usable where > > sizeof() is. Yet making if() and switch() equal is imo going too far. I > > realize though that it may be difficult to find a suitable boundary. > > Stefano - do you possibly still have notes from the discussions long ag= o? > > > >> Fold switch_stmt into the general entry and drop the 'sizeof'-restrict= ed > >> one, which the general predicate now subsumes. Invariant 'switch' > >> conditions that are not a 'sizeof' become deliberate as a result; that > >> is the intent. > >> > >> Signed-off-by: Shuaidong Chen > > What you don't say at all: Does this help with any remaining violations= ? > > > > Jan > Yes, and let me give the full context, since the motivation comes from > downstream safety work rather than from the upstream analysis. > > On safety branch one of the techniques we rely on there is to pin build-t= ime > configuration to compile-time constants, so that the code which the > intended configuration can never reach is removed by the compiler > rather than merely left untested.=C2=A0 That matters for us in two ways: > code eliminated at compile time does not enter the coverage > denominator, and - more importantly - it is not in the binary at all, > so it does not have to be carried through the whole qualification > chain. > > Two examples: > > https://gitlab.com/amd-xen-safety/xen/-/commit/160dac43f554733a68d83c38cc= 1d0e73b3b7bff0 > https://gitlab.com/amd-xen-safety/xen/-/commit/e0eccfa7184b7acee23916cd5c= b2a3b5afa101f2 > > A side effect of this is that some of those constants end up as the > controlling expression of an switch statement, which then > trips R14.3. > > > Otoh switch ( 1 ) doesn't make a lot of sense > > Agreed in the abstract, and I would push back on anyone writing that > by hand.=C2=A0 But that is not what happens here.=C2=A0 The sources still= read > > =C2=A0 switch ( gt->gt_version ) > =C2=A0 switch ( opt_bootscrub ) > > exactly as upstream wrote them, against what upstream intends as a > runtime-variable value.=C2=A0 The constant only appears after a build > configuration specialises that value.=C2=A0 So the construct is not a > pointless switch on a literal; it is ordinary upstream code that a > particular configuration has made invariant - which is precisely the > situation the existing 'deliberate' deviation for if statements and > > conditional operators already covers. > > Of course the other alternative: rewrite those switches as > if/else chains, which the existing deviation would already cover it, and= =20 > the violations gone. Technically that works. > > The reason I would rather not is that it is churn in common code for no=20 > functional > reason, carried indefinitely as a delta against upstream, and it makes > every subsequent rebase of the safety branch more expensive. > > Having seen that a deviation for switch already exists - restricted to > sizeof - extending it to switch in general seemed the smaller and more > honest change: it states that an invariant switch condition is > deliberate, just as the project already states for if and for the > conditional operators. > > -Shuaidong To build further on this. add_sized() is one such case (already covered by the disappearing exception. There are existing cases in the upstream tree where this is or will be the case, but due to their being inside macros become invisible to Eclair. Or my (still not resent) cpu_vendor() series, I rely on placing X86_VENDOR_X constants as invariant expressions in switch statements. Even if nothing does it today, MISRA would be prohibiting constification of any global that happens to go in a switch for no particular benefit. IOW: This isn't about hardcoded values, it's about IS_ENABLED() gating and DCE. On the specifics of the patch, it's not exclusive to switches. I'd much rather see it extended to for loops as well. for ( unsigned int i =3D 0; i < NR_MAX_FOOS; i++ ) ... Where having NR_MAX_FOOS be zero is effectively a guard on the whole loop. Today we need explicit early IS_ENABLED()-gated exits to keep Eclair happy on some such statements, and that's just strictly worse. Shuaidong had to recently fix these violations in our tree because the spirit of the existing exception is needlessly exclusive to "if" statements. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Oct 27 09:22:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 09:22:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461970.1672984 (Exim 4.92) (envelope-from ) id 1xLdON-0001Tp-8m; Tue, 27 Oct 2026 09:22:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461970.1672984; Tue, 27 Oct 2026 09:22: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 1xLdON-0001Ti-5p; Tue, 27 Oct 2026 09:22:51 +0000 Received: by outflank-mailman (input) for mailman id 1461970; Tue, 27 Oct 2026 09:22:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLdOM-0001Tc-9i for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:22:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLdOK-002yUr-Vv for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:22:48 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae06d65-2eae-0a2a0a5409dd-0a2a4508ad64-14 for ; Tue, 27 Oct 2026 10:22:48 +0100 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 6ae06d68-f659-0a2a45080019-d155802be8d4-3 for ; Tue, 27 Oct 2026 10:22:48 +0100 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49d05d51553so26739575e9.2 for ; Tue, 27 Oct 2026 02:22: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-4a359f3e00asm439124475e9.0.2026.10.27.02.22.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 02: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=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=1793092968; x=1793697768; 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=wIjBBo79S2AMMUpc5vtcnZ3n4BdrhlDOoBz1xVGUElg=; b=fmiPbS8U12e/iSVhMWgHWgSAJpUIi6+b02YF/L+TR0mACMBaG2ZtjOx1w3hZmZmWUh UmWJCBQ1sNLrq25itIDBsETlDdA3wisEduFdVRD4RXXn9mpV3wDChZL84/3fcwKtlZDo 5CiMhymaWHE7AXl09nqNYDg3VdvCyWybGf/+44HAYHTa2yKQ+PO4bTbDfE2+kRivaFtj k2uT1mCQTFK4o271CXKbpgTcgP/Of81hk3P/XYmCYXHfEclGxmTYXxAMa4cnH/2QYvcH Wnj2RaEPpQBCZZqinb+oOy9tc5fHYsQ1kNPimLULhjZ/5JrYCJcSkOk7QbhvVfLEyVTB 84MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793092968; x=1793697768; 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=wIjBBo79S2AMMUpc5vtcnZ3n4BdrhlDOoBz1xVGUElg=; b=LEb3yHHI0yRyvEdActQydS4dDpY2IK2pLy4f3/XRty8llbCQQ7uAaFBYHyMrMXTqRr F5C9tGG24c+mmm4Ec5GAGyo0U8gA9yTy97dUzl3LH3sCMeyzWwO8j8St7Pcr/I7rp4RD FuIhi5+XE74ijxepT3/cdNj14wrJ7PefhJEe/FgRIAbAHC8o1SFb9t9uJGk9UigrmVNa 8bgPESJ3KWNPqzwzq1cqJP86AD53AL9PeH2ZC3xkulcHUsQqtV4ACh4w/7rBwrwfWtYk hpk5/4lba6owAoJ6ABpYqZARf1ErZaVGi8nPjDBW6MRBBA2wgLzl5APW1QmIyrymGgmu KYlA== X-Forwarded-Encrypted: i=1; AKwUvBwWdVUznVc5R86Zznse3Xp467pgkb+qigLcyE2inCTSl6YGXRP4O4eOFtwA5LfXNRn3OLqG2JkquL8=@lists.xenproject.org X-Gm-Message-State: AFq9FYJBCcCMW/bO6VOW3xb0MMIK+cu3oTOhIWUqQZDpkaDnNDxywO5R H75+AhBK9ZbbFnya6xPiARSnAMOIO3tlBEkzjr2iTTyY08EHruzlhkGHFzMFlAl8fDZkLwvHmRg XHFDWVg== X-Gm-Gg: AYBFou3093T6e+sGrNcpHLsezPk3FUQkcLBxRb3QVkwY7zSXE+pUW3Ip6hbGIR+otkB K/KIbzTi5pSAnr7bZZmyjvHqS4frW2lA024uTTK2hA6aDJzv5Y47Z9+L3g4BqvziedDb2uXXnT9 bi36SfHLU2z7bJyPwn754NgulFwJBXIBxTfev4fWgVtgi2ZqQTQp0EieNJmzGVgkj9gmS4+GMS7 yBTvfBgCiyzIlDe8sDqxePSf83sJ+CqaS0kg7huEsPsMGp9Z7WUbpsf8AooTifYETQ5fgm9zCIt wf8IsY/qwp7bQHDKfbQ//4EjnNNaQQL52hJFYrKwxi+IEchTSLETpjw1z8pra2kn8WPX2Q5Kwan b8tFo254tPG1hiS3WDOgema7LFyXjf/uGW3Otsr3+hMZbs8L2lKeFZ3Wo0307btAzQHL2FasnXC Ys9/YajbzGYS+Q9dPTNdLFof0QrmsV/HzvvPksVO93dl16WJCI6nYz2tNN7t8i5QsfNEBrk9E4E gho7/0vWCOTGvH2/aQJ+uBipoNKzFM/DBR/NySAgPGj6Vfp420Vxqxv76S45gakqF80eKJlq6cz +Y3LM8Ok5OG3NzG/Od0RMLvJeeytC9wDbnQs5ba10cU= X-Received: by 2002:a05:600c:4ece:b0:4a1:6517:ccf1 with SMTP id 5b1f17b1804b1-4a35ac9d116mr177942045e9.9.1793092967824; Tue, 27 Oct 2026 02:22:47 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 10:22:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Ping: [PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() From: Jan Beulich To: Andrew Cooper Cc: Nicola Vetrini , "xen-devel@lists.xenproject.org" 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793092968-CE74387B-E0CFD134/10/78276251493 X-purgate-type: spam X-purgate-size: 1023 On 03.09.2026 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 This is now the only violation left for this rule, after "automation/eclair: generalize the noreturn function-pointer deviation" has gone in. Can we please get this one sorted as well, to then also mark the rule as clean? Thanks, Jan > --- 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 Tue Oct 27 09:28:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 09:28:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461976.1672994 (Exim 4.92) (envelope-from ) id 1xLdTP-0002Cl-RR; Tue, 27 Oct 2026 09:28:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461976.1672994; Tue, 27 Oct 2026 09: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 1xLdTP-0002Ce-Ok; Tue, 27 Oct 2026 09:28:03 +0000 Received: by outflank-mailman (input) for mailman id 1461976; Tue, 27 Oct 2026 09:28:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLdTO-0002CX-DF for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:28:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLdTN-008QhG-ED for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:28:01 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae06e9c-8faa-0a2a0a5109dd-0a2a450ba98a-24 for ; Tue, 27 Oct 2026 10:28:01 +0100 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 6ae06ea1-b7e8-0a2a450b0019-d155802df139-3 for ; Tue, 27 Oct 2026 10:28:01 +0100 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a140e7405dso39696955e9.3 for ; Tue, 27 Oct 2026 02:28: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-4a359f3e00asm439533775e9.0.2026.10.27.02.27.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 02:28: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=1793093281; x=1793698081; 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=VGF4ZXOcbT75XAXsS7LhoOIPs2suawsrKKPub0ubSNY=; b=dE6Op46a30Mt4doHD+6sGHgdnCRipBdGrgS/s/K8ol1xWxV3GfudDwCdfYPY0nFltc no/5PO3vprj4ZBl6UQTnUNAj6FLsBTXIvP7+QAU/NVZyQSgs8zZoTCPf77F3vVsodyC2 o50bFROeF2MMFQ7lvl/+lvL69qpx8AjzVfJOCwEK1ZNbq1qfTR91nZbveCJ+Cx0A8LwQ zXLVRrELJwpqIxLsdcxAesSvajvVSg1IlO2iuSW3leHAhwcWrkuix62mwvy5Ow31al1T ttLOVNL9NLGlrFU3brZh9ucSZqvWanNclCjVP/L2HyEdYvkWMPRILxB2xsV/c8LQJ/M4 m32Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793093281; x=1793698081; 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=VGF4ZXOcbT75XAXsS7LhoOIPs2suawsrKKPub0ubSNY=; b=D3MjvxadNxZmyk5a0BbuBdH/7rZMCLC4qASs3aDwp0yBpZid/Ol6ybcZCC4sAgqDtv 7DDvN5xLC+tF10wS1R6No+qhbqgJQL43NcLJNUheVV8TmGZbfLOXcc15PAcyoKblUNdm eh7jgz+alqCgEnxLEI1FEnk/OK5rZ+O0b1vp7uLBcn7KbVSm9sGejGEPgs/gGgYFzMmI Myl9q6tb5VM8/WkrFyl7wiO84qSGGJSOKh1BF4IiHsX8Q1wyPu37ERa0K1TGBScuQRRu WCD1SivP6Lje2TCDGxJ6PPHj/0/up2PAMr+3Kx2R/I/w7rGrhPIgB1p7mjKODyalPL4L 6C+w== X-Forwarded-Encrypted: i=1; AKwUvBwiZHstV8/cd0NT8tA2GKHxvy3tDwSl5Q8bFXnp4N+c10x/c0iLk5a7weYt9ebI4UZClMAzS1DFmgM=@lists.xenproject.org X-Gm-Message-State: AFq9FYIXeaIxgI6mfmLYN8ziNjdvXc2TBrX97no/x/rwYvMV2A6TjV9g hc+OcDIBEmUbFEV+mj+BZ4+/oUmWDsFt+YBkmaK+0Y4vIGuWKDTSbjT3MXsSBDutIg== X-Gm-Gg: AYBFou0fLkxCjefzquKzPOgjsiae3G2+XYbt5zWwWXGRtqWe0pLlMns/mOBU+dEKHNC t3C7sfZawTpiOwDoJZPruLPFoB6ayUcJkBtlQlvCjqLTfkOW42eEBrCwtBthLiv18XVCbQ9+Vj4 8t6H4ryhy92ICTATcJkMUXYnABIxjAMvi4/VuDlnznblhAV7d43yXGJu9Zvnd2ck0jpTaNSsKME q96wocWcR+ndjFEu0rrzjPRQDCQSqEbxjwZtFd65fLTaFmou438/F90oUeOx/zqUZ2bf3XmrvDu cD2GiFvPvbc2UY8jWSoscewdLWUvNR83epYlMj1O1UUZBaHK/zQBff+rLALltZ+Q8ICj8QC6g9T jFqFbI2sx7k3GWOnjAo2V1fL1Ihvd+lzw+lNgfSsYgPIIlyHfeWiTW9zB4Aw/mJC/WBbCqUFWem yKPLKmH1CBIvbgAizlkxh1ZS4u/o16JUu18OAGTRIPTGAw/ESBhCcdN0mIXVQJZ6c5WJE4MsmsA jQJfoMghlrMLn+nfsMwqND3pQKOcPpgFFQsJsDXjfXLaxpbV9oeN3ivn2iQgOek2bT6LVp3qQkr qISYvmlzxWhjpK2Bemk3UOWK2dtLGIT/ODW416pocys= X-Received: by 2002:a05:600c:4e43:b0:4a3:5991:719 with SMTP id 5b1f17b1804b1-4a7776698f9mr61479765e9.31.1793093280736; Tue, 27 Oct 2026 02:28:00 -0700 (PDT) Message-ID: <2e3545bc-7ab0-43d7-9a8f-7c8c30180df6@suse.com> Date: Tue, 27 Oct 2026 10:27:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations To: "Chen, Shuaidong" Cc: Nicola Vetrini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org, Stefano Stabellini References: <20261026030309.2507461-1-shuaidong.chen@amd.com> <67e298cd-3b84-4476-9dd3-607e505effe6@suse.com> <321e7082-5cd2-4a41-9c49-ff091d9ceade@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: <321e7082-5cd2-4a41-9c49-ff091d9ceade@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793093281-AA0C59EA-D9E6DCA9/10/78276251493 X-purgate-type: spam X-purgate-size: 4585 On 27.10.2026 09:18, Chen, Shuaidong wrote: > On 10/26/2026 9:14 PM, Jan Beulich wrote: >> On 26.10.2026 04:03, Shuaidong Chen wrote: >>> MC3A2.R14.3 ("Controlling expressions shall not be invariant") is >>> deviated by two separate entries. One covers 'if' statements and >>> conditional operators and places no restriction on where the invariant >>> condition comes from. The other covers 'switch' statements, but only >>> when the controlling expression is a 'sizeof' operator. >>> >>> The rationale recorded for the two is the same: the condition is >>> deliberate. Nothing about a 'switch' makes an invariant condition less >>> deliberate than the same condition in an 'if', so the 'sizeof' >>> restriction reads as an artefact of that entry having been added for >>> read_atomic() and friends in arch/x86/include/asm/atomic.h rather than >>> as a considered limit. >> Well, >> >> if ( 1 ) >> >> can make sense, especially when 1 is the expansion of e.g. IS_ENABLED(). >> Otoh >> >> switch ( 1 ) >> >> doesn't make a lot of sense, even when it's as a result of the expanding >> IS_ENABLED(). I agree that limiting to just sizeof() is unnecessarily >> strict; alignof(), for example, should about always be usable where >> sizeof() is. Yet making if() and switch() equal is imo going too far. I >> realize though that it may be difficult to find a suitable boundary. >> Stefano - do you possibly still have notes from the discussions long ago? >> >>> Fold switch_stmt into the general entry and drop the 'sizeof'-restricted >>> one, which the general predicate now subsumes. Invariant 'switch' >>> conditions that are not a 'sizeof' become deliberate as a result; that >>> is the intent. >>> >>> Signed-off-by: Shuaidong Chen >> What you don't say at all: Does this help with any remaining violations? >> >> Jan > Yes, and let me give the full context, since the motivation comes from > downstream safety work rather than from the upstream analysis. > > On safety branch one of the techniques we rely on there is to pin build-time > configuration to compile-time constants, so that the code which the > intended configuration can never reach is removed by the compiler > rather than merely left untested.  That matters for us in two ways: > code eliminated at compile time does not enter the coverage > denominator, and - more importantly - it is not in the binary at all, > so it does not have to be carried through the whole qualification > chain. > > Two examples: > > https://gitlab.com/amd-xen-safety/xen/-/commit/160dac43f554733a68d83c38cc1d0e73b3b7bff0 > https://gitlab.com/amd-xen-safety/xen/-/commit/e0eccfa7184b7acee23916cd5cb2a3b5afa101f2 Just to mention - both pages give 404, presumably to anyone outside of AMD. > A side effect of this is that some of those constants end up as the > controlling expression of an switch statement, which then > trips R14.3. > > > Otoh switch ( 1 ) doesn't make a lot of sense > > Agreed in the abstract, and I would push back on anyone writing that > by hand.  But that is not what happens here.  The sources still read > >   switch ( gt->gt_version ) >   switch ( opt_bootscrub ) > > exactly as upstream wrote them, against what upstream intends as a > runtime-variable value.  The constant only appears after a build > configuration specialises that value.  So the construct is not a > pointless switch on a literal; it is ordinary upstream code that a > particular configuration has made invariant - which is precisely the > situation the existing 'deliberate' deviation for if statements and > > conditional operators already covers. > > Of course the other alternative: rewrite those switches as > if/else chains, which the existing deviation would already cover it, and > the violations gone. Technically that works. > > The reason I would rather not is that it is churn in common code for no > functional > reason, carried indefinitely as a delta against upstream, and it makes > every subsequent rebase of the safety branch more expensive. Plus replacing switch() by if/else chains impacts code readability. > Having seen that a deviation for switch already exists - restricted to > sizeof - extending it to switch in general seemed the smaller and more > honest change: it states that an invariant switch condition is > deliberate, just as the project already states for if and for the > conditional operators. We may need to find a middle ground here. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 09:39:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 09:39:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1461983.1673002 (Exim 4.92) (envelope-from ) id 1xLdeA-0004er-Rc; Tue, 27 Oct 2026 09:39:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1461983.1673002; Tue, 27 Oct 2026 09:39: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 1xLdeA-0004ek-OL; Tue, 27 Oct 2026 09:39:10 +0000 Received: by outflank-mailman (input) for mailman id 1461983; Tue, 27 Oct 2026 09:39:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLde9-0004ee-CY for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 09:39:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLde8-001xyd-D8 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:39:08 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae07137-bab6-0a2a0a5309dd-0a2a450be28c-14 for ; Tue, 27 Oct 2026 10:39:08 +0100 Received: from [52.101.83.130] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0713b-b7e8-0a2a450b0019-34655382f1e3-3 for ; Tue, 27 Oct 2026 10:39:08 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by DB8PR03MB6204.eurprd03.prod.outlook.com (2603:10a6:10:139::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 09:39:05 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0546.019; Tue, 27 Oct 2026 09:39: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=lUS70TBfgwiHIZrnIUBiHHmLnUogVkZM8lmmmvy5RN0St0oclcCNj69HOGicE7/IAIr9ZnFtqwPd86wWitjzbzgEPo2xQGwOLwHKbVb6HFD6lSJLkB86v1JC1ng1HglLksM8lZRFJyrMGsHd8maShV+vsLyIdCiQ0xLPikY80zH/4P1yBG/fSHnkrKYd+oGdbqvrDypbU6Z5gbT0zjPwwBOGEevC7iaTTqJNotte+xhY//bobQQXkxvcn6N2SlcSJRAUyxUWediK112D3OZnmMPvtifuRJmqSUmBG8xqsx8fAXncKRiQltufTfHECLbq/ezY3Orwf0pubtZJYEbIdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zs+rNXfxKdI34rPisFtEQGl7/0ZgToIo7kHNoA9PQYI=; b=Phf0gdLsKk1LBIk0X9icUJa9xvno15u5x74FdlBRVQxaVtL9pZ/lfL5Uooc3VIv8lmhD+5V7n75CW9WquAxQYpKZ9iJL5eo7Bxay+oolYulIPFMnkzIjFLALm6wDxb0OAxnvj+12Qd73q3oHTZuxIWVo8AGpfFKwCZYILhbibw+5hjs33uZKOlxRivSlgC2m26iVMs24u4vQp8TT/CAw7N0I6Vz+W5BHF2xU+biMlHQF4Cn7Uu5VJa5UQk08pEdqDJaheloLLZNFB96yrEUs958LfEx+RKcw+EJ2hhEgNWT9x7Iu5mPYmuyoPnzJ/4PS33jSPDLrBJUlxBQUpEWb2Q== 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=zs+rNXfxKdI34rPisFtEQGl7/0ZgToIo7kHNoA9PQYI=; b=u4ewLoNdZA+8o8KozRZ94xneOtGfoBv47Qsp83gzyqxlp28QPlydwiwICPnWDe7ILjMke6aKtOPNfikcEzYh2evRDAhs6cWQMmYEWHinAuGgUlL+7BnNDc0OUQM04/jCIu607QLUjousrumKiifwc3au6SYmBxor34p6qkYRnGluFkQdZauKX7P3aJPLighBBcHbZEuY1sPm6b/jmupf8fmIf+lrar+7lpiyy6FdEZrEoBDYwSyZyqvrnvq6y4jn6H/dYKdP6mNfgpt8/8zt0fBjO3zMnv0vu2ZWe71A2hd4o9QM3wq1ANGdjrDe4/+bAzCjnEb1joh/D2T4bnk0fA== From: Mykyta Poturai To: Jan Beulich CC: Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Topic: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Index: AQHdZUVvbuj2+I/wmEeMfHolzOWTxrcPwg+AgAFhaAA= Date: Tue, 27 Oct 2026 09:39:05 +0000 Message-ID: References: <8b2fa10a-17ac-4807-b9d2-874f84a85efc@suse.com> In-Reply-To: <8b2fa10a-17ac-4807-b9d2-874f84a85efc@suse.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: AS2PR03MB9076:EE_|DB8PR03MB6204:EE_ x-ms-office365-filtering-correlation-id: 0601374c-be28-48da-6bb8-08df340e2442 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|7416014|376014|261009223027099003|261022105027099003|261022113327099003|261021123027099003|261021130227099003|261022075727099003|261021133027099003|261021121427099003|261022115727099003|261021135927099003|260925021311599003|260925022911599003|10067099003|260925021911599003|56012099006|261026121527099003|4133799003|6133799003|22082099003|18002099003|261026135527099003|4143699003|261026140227099003|11063799006|38070700021|261026130827099003; x-microsoft-antispam-message-info: tF2XWnVfsGVIbACWjbAtDdEHVbu6AsKvgjmNgysfQW/Zlu3CM+rfksenGBOjb+w3ZszxCxp51wHErjafKFLDWuzaMRMQVp1rcSU9csXsBkFRCjTHBa2nnnBB+YFNvD79tSUIWTmxOiydkwxnGY0IWJpixdcn0lZrD84R8lKoS2Ai+emvT56IeHy2WkAmNhiddmfD9BEHj7vV3wNb6Na91Xwe0HfWTA4O2aCgXSAPRtGXn6r/ZnX49x60/0u34ANPo+5CtBOBp2xxS+FOx/CuiGJCdumjfPlv/2BLF1VyLrn2T1lT/lQwbc3GCM5oH+so3HOSWl1OcgJ/fV+gLopEI3SHh03MSyGqdMYcqAh06CkgDosdufeoXyCxoamuNeWsJTDUaPmjnlk6ZCyYRY8yHiRBNHJ+ZqsbFIBQ/m+yt1Aon2bxh37mXnDaX4agBsf70D82kC3YDZUo5jqV7VBw8KfU47a/DwrJwLYUi+3lbPty6tJeMfhplvBi8BWkwujtdp5UBtWb6/Hoy4qjyuROcQuobej7DKJAxxVmEiyy5/hU1oSslLRBZrkNB5c7pizi83H8GTODSfogT9+R2D/bMAKyrXNuMRw5MqNH+9mSBZCph2uQPEd2AGbWGXiu08D1t/NQqjB1wH7ACyTnuThb6eUILKmvZR+NfZREz3/5FSU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(7416014)(376014)(261009223027099003)(261022105027099003)(261022113327099003)(261021123027099003)(261021130227099003)(261022075727099003)(261021133027099003)(261021121427099003)(261022115727099003)(261021135927099003)(260925021311599003)(260925022911599003)(10067099003)(260925021911599003)(56012099006)(261026121527099003)(4133799003)(6133799003)(22082099003)(18002099003)(261026135527099003)(4143699003)(261026140227099003)(11063799006)(38070700021)(261026130827099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RzRrcjMzUnBrbm5MbkNic0JBL3JYMXpKSXFtN3lXUmNFWkg4am11SHpibXVT?= =?utf-8?B?dFBQS0pUVkxOZU9GVnJlRmk2alR4QU5obnhtRjZPYzRiL2VDNENmY3dCVU9x?= =?utf-8?B?QmJ5U3JvbWo2eEtkMGoyMHJtOUpFUHc4ek9KekMwMG02QmdvVDczampTNWI1?= =?utf-8?B?Sm12eHg3eEZkOUZ0QktqZ2Q0eVRwYWR0RGN1SGhnREtjVHc0QjVTdWR3UzVj?= =?utf-8?B?ZDBUZ2RrSnRHU2N1d3UxOVQzQ0FtWGZzamFZQ2Q0N0UyeTBpNk1tb1d2L1dY?= =?utf-8?B?UnFJWURqZnoreGZSRVgzR3FBTWJaaXA2eVRPYzRUOW1OSnJLd1lSSjBiT2xD?= =?utf-8?B?M2RUeG1TSTRsME5iajFacHlMWTFYK1lCSVFiV1dlN1F5bWFPRXFiRUdhRmFJ?= =?utf-8?B?MkNLcHZ3YnhEYlBmTm5TbEJUY3dpSE1BaTlRSXJxTTRudXY4cFNKQlVsdEk4?= =?utf-8?B?aVdSYmIxWXQzWHRaVktDWGQveFB0MnU5U1BnbThRNUp2T3g2MnJJWVVDcVhv?= =?utf-8?B?em5lRStSb2VneFBpSzRYd0lFb1lhL25NU3dHNUdBWFY5eHdmSTVZNEVobG9M?= =?utf-8?B?RktoZC9RdEhPb05MU1FRVmc4SXFtcEpsYVFSaERJbzVQb05HYUNvNUNpamVE?= =?utf-8?B?TXZBS1JaNDhEaDN2KzRHK01hdGNodlZKMUFxMzkySlZURjdCenNTNEZ2dmZJ?= =?utf-8?B?aDlBWUw0RlZZL1JyKzZHWURSWWpZNDIxa2YzSjhUandtWHhyRWxlQ3Q4RHRU?= =?utf-8?B?dWo3VktISWNtT0lqbXRYelh5SzROVmN3NVlqVmQzSVBBQys1VWJhSks3eU4x?= =?utf-8?B?VUY5SHk3MWVXQWpJVUxIRk0zcWljYlVpOVJTTUpaVkhpOG9kKzlubFRmQ1FD?= =?utf-8?B?T3Q2ckZubDJZRTlkTVZCT3AvT1VWK2FMTWhXaFIzaWxKNEQzTWFGKzNFUVJV?= =?utf-8?B?bWUwOXl5c0F3K1N0TFgvTUQyVkN6U0lHOWI3M0tGeTJTRkY3dEJRYk0wK3R4?= =?utf-8?B?dmxMVFFPS1RjUjdVdHVXcENHdDVwOC9tUzgrTWlvd3ZXVERCYmdiQnRtOU5J?= =?utf-8?B?WXlzM05LUGEwWmxhUmVJKzhNdTBzNVpGejNsNDRUQWgxVUVVMjh3ZFBMdW41?= =?utf-8?B?MFMvUkxETzdJWWlLMnJjQW9oeFJPZ2RWdEVZdUVIQ0JJK2lZaDhKNSsrZW4r?= =?utf-8?B?MUVGWXlMOEtWSm0xajU0VHBCVVJZc3dqMHdvLzgvK3hJMEpWeXNFa1p5NFlN?= =?utf-8?B?OC9wcldzTEN2L2dLV2VVcmZZM1k2RVpyT2F0T3NVK0VwSzlSYUx4VmcxSjBy?= =?utf-8?B?NHJHZEQ2cE9hcVVBQm9PNEpOZXR5dXVSYU9lL1hYMkdLSU9HNTd4elh6YkZR?= =?utf-8?B?QmpBWWhFZVhEcU1uMDhTQk5kV0VRVldBLzN1T2c1TkhzU2tjYW9SQjRhWlJJ?= =?utf-8?B?cUJEYWsvdk05djVTMC9sNTBrdTk4QkZDL3prRmpVanRFeURiSUhvWVRoSU9u?= =?utf-8?B?ZUoyZlNxWUd1SWI1RXVtemhFVFRsNkdQeVZmekNleGtrMFJoRVhubTJUMlJx?= =?utf-8?B?QmVzallOb1NDekVRTDg0d2JJdWtPZEdDczlzNmFzeEx4SFdVVUdUSFZGWFdI?= =?utf-8?B?Kzh6SE81T09UeHRiTldFTXQ2clNzZUdmVG1EMDNRbXJ5UWFOZWxWdFZ0WmNT?= =?utf-8?B?VjVqQ3p6UmxMelIydm5SUDBuSUY5RU9KT2E0dTVGN1dVVU16SDIyL05PaHQv?= =?utf-8?B?QTV5NmZnTzZ0WkxRZ2hYOTMyYmJ5K1NnRm9rbmlTdXJnSVBmTzUrYXBhQlJ5?= =?utf-8?B?VGdZcjNyYVh2V0V5MzFYdkxqQlNKajlWZm1uODZEQ0szZldEb0R2a2ZVR1Ax?= =?utf-8?B?bGNzZGkwb3Bua2ZrK1VtWm9sT1hoMXNuVjFlbmswaDlVS2JuSFNnbFdKMGpw?= =?utf-8?B?T2lKMUFtTThUYVE3aHVPUkdQNzE0Qm4yM2liQURlMnFhUFduS0lBaHVxS0kr?= =?utf-8?B?SytOZ3ZNSVUyNXRudzVhN0ROYWZ4U3lRSGM5MDZGaHNGQjQ0YUcwNEd2RzBo?= =?utf-8?B?SHkwNXNKN0tjTHQ2UnlRN2trQ05kMjYwSmRyTlFyaHB3UU9EZmRLeXcxd2pn?= =?utf-8?B?anJQYXZUWllmU3YrSFJsQ05GWmVHN2krNHlqcHAzNWV5bXo0Y0tVenU2WVgr?= =?utf-8?B?M2I1OFBkYnA2QTMyVjUzb2liZWdLdGRJQXJVaDRlc3dhYzNsdld3UnJWTXll?= =?utf-8?B?ZFM1VzNaZ2tDUVVaQUIrUUpBNVZ4b1k4d243eS85bm9KeVZjWjN0QU1mQ0xD?= =?utf-8?B?c3NvbmFLZmVwaEhyYWxRc1NTN2pMdTNxNjVCaVpoZ0xKdDBudE84QT09?= Content-Type: text/plain; charset="utf-8" Content-ID: <6C1D42B7A0E4A74487342A5C7D1B48EF@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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0601374c-be28-48da-6bb8-08df340e2442 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2026 09:39:05.2125 (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: nqoA5KrRHbIij/7xFMitU14KtT1oCTjTMlzeMKw941QOrIMdMgOS5m2OQQd5dKp9+2752tJsoFX9A0TEpIYGgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6204 X-purgate-ID: tlsNG-42698a/1793093948-190CD9EA-A649E81E/0/0 X-purgate-type: clean X-purgate-size: 3096 DQoNCk9uIDEwLzI2LzI2IDI6MzQgUE0sIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNi4xMC4y MDI2IDEzOjI3LCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+IFRoaXMgaXMgcHJlcGFyYXRvcnkg d29yayB0byBtYWtlIHZQQ0kgTVNJLVggZnVuY3Rpb25hbCBvbiBBcm0uIFNwbGl0IHRoZQ0KPj4g dlBDSSBNU0ktWCBjb2RlIHNvIHRoYXQgaW50ZXJjZXB0aW5nIHRoZSBNU0ktWCB0YWJsZSBhbmQg UEJBIHN0YXlzIHg4Ng0KPj4gb25seSwNCj4NCj4gVGhpcyBsaWtlbHkgaXMgcmVsYXRlZCB0byBw ZWN1bGlhcml0aWVzIG9mIEFybSdzIGludGVycnVwdCBoYW5kbGluZywgeWV0DQo+IG9uIHRoZSBz dXJmYWNlIEkgY2FuJ3Qgc2VlIHdoeSBub3QgaW50ZXJjZXB0aW5nIE1TSS1YIHRhYmxlIGFjY2Vz c2VzDQo+IHdvdWxkIGJlIHNhZmUuIFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGV4dGVuZCBiYWNr Z3JvdW5kIGhlcmUgYSBsaXR0bGU/DQo+DQoNCkhpLA0KDQpPbiBBcm0gbW9zdCBvZiB0aGUgd29y ayBpcyBkb25lIGJ5IHRoZSBJVFMsIHNvIHRoZSBvbmx5IHRoaW5nIHRoZSBkZXZpY2UNCm5lZWRz IHRvIHdyaXRlIHRvIHRoZSBkb29yYmVsbCByZWdpc3RlciBpcyB0aGUgRXZlbnRJRC4gSW50ZXJy dXB0DQp0cmFuc2xhdGlvbiBpcyBmdWxseSBjb25maWd1cmVkIGluIHRoZSBJVFM7IGl0IHdpbGwg cmVqZWN0IGludmFsaWQNCkV2ZW50SURzIGFuZCBhbHNvIGhhcyBhIHNpZGViYW5kIERldmljZUlE LCBzbyBtaXNjb25maWd1cmVkIGRldmljZXMNCmNhbm5vdCB0cmlnZ2VyIGVhY2ggb3RoZXIncyBp bnRlcnJ1cHRzLiBNZW1vcnktd2lzZSBldmVyeXRoaW5nIGlzIGdhdGVkDQpieSB0aGUgSU9NTVUs IHNvIGEgd3JvbmcgZG9vcmJlbGwgYWRkcmVzcyB3b3VsZCBub3QgcG9zZSBhbnkgcmlzayBlaXRo ZXIuDQoNClNvIHRoZXJlIGlzIG5vIG5lZWQgb3IgYmVuZWZpdCBpbiB0cmFuc2xhdGluZyBhbnl0 aGluZyBoZXJlLg0KDQo+PiB3aGlsZSB0aGUgTVNJLVggY2FwYWJpbGl0eSBoYW5kbGluZyBiZWNv bWVzIGNvbW1vbi4gTm8gZnVuY3Rpb25hbA0KPj4gY2hhbmdlIGludGVuZGVkLg0KPj4NCj4+IFRo aXMgaXMgYSBjb250aW51YXRpb24gb2Ygd29yayBkb25lIGJ5IFJhaHVsIGZyb20gRmVicnVhcnkg MjAyMlsxXS4NCj4+DQo+PiBUaGUgYXBwcm9hY2ggaXMgaW52ZXJ0ZWQsIGluc3RlYWQgb2YgbW92 aW5nIG91dCB0aGUgeDg2IHBhcnRzLCBtb3ZlIG91dA0KPj4gdGhlIGNvbW1vbiBvbmVzIHRoYXQg d2lsbCBiZSBuZWVkZWQgb24gQXJtLiBTdWJzZXF1ZW50IGFybSBwYXRjaGVzIGZvcg0KPj4gcmVm ZXJlbmNlIGNhbiBiZSBmb3VuZCBoZXJlWzJdLg0KPj4NCj4+IFsxXSBodHRwczovL2xvcmUua2Vy bmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMTY0NDkzNzQwNS5naXQucmFodWwuc2luZ2hAYXJtLmNv bS9ULyN0DQo+PiBbMl0gaHR0cHM6Ly9naXRodWIuY29tL3N0ZXdkay94ZW4vdHJlZS9wY2llLXBh c3N0aHJvdWdoLWFybS12cGNpLXYyNg0KPj4NCj4+IFJhaHVsIFNpbmdoICgxKToNCj4+ICAgIHZw Y2kvbXNpeDogbW92ZSBoZWxwZXJzIHRvIGNvbW1vbg0KPj4NCj4+IFN0ZXdhcnQgSGlsZGVicmFu ZCAoMik6DQo+PiAgICB2cGNpL21zaXg6IG1vdmUgbXNpeCByZWdpb24gcmVtb3ZhbCB0byBtc2l4 LmMNCj4+ICAgIHZwY2kvbXNpeDogbW92ZSBjb21tb24gbXNpeCBjb2RlIHRvIGNvbW1vbiBmaWxl DQo+Pg0KPj4gICB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vbXNpLmggICAgICB8ICAyMSAtLS0N Cj4+ICAgeGVuL2FyY2gveDg2L21zaS5jICAgICAgICAgICAgICAgICAgfCAgIDIgKy0NCj4+ICAg eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11LmggfCAgIDIgKy0NCj4+ICAgeGVuL2Ry aXZlcnMvdnBjaS9NYWtlZmlsZSAgICAgICAgICAgfCAgIDYgKy0NCj4+ICAgeGVuL2RyaXZlcnMv dnBjaS9oZWFkZXIuYyAgICAgICAgICAgfCAgMzAgKy0tLS0NCj4+ICAgeGVuL2RyaXZlcnMvdnBj aS9tc2kuYyAgICAgICAgICAgICAgfCAgIDMgKy0NCj4+ICAgeGVuL2RyaXZlcnMvdnBjaS9tc2l4 LmMgICAgICAgICAgICAgfCAxOTcgKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAgIHhl bi9kcml2ZXJzL3ZwY2kvbXNpeF9jb21tb24uYyAgICAgIHwgMjAyICsrKysrKysrKysrKysrKysr KysrKysrKysrKysNCj4NCj4gTml0OiBOZXcgZmlsZSdzIG5hbWVzIHdhbnQgdG8gdXNlIGRhc2hl cyBpbiBmYXZvciBvZiB1bmRlcnNjb3Jlcy4NCj4NCj4gSmFuDQo= From xen-devel-bounces@lists.xenproject.org Tue Oct 27 10:13:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 10:13:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462008.1673056 (Exim 4.92) (envelope-from ) id 1xLeBQ-0002vG-SW; Tue, 27 Oct 2026 10:13:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462008.1673056; Tue, 27 Oct 2026 10:13: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 1xLeBQ-0002v4-PZ; Tue, 27 Oct 2026 10:13:32 +0000 Received: by outflank-mailman (input) for mailman id 1462008; Tue, 27 Oct 2026 10:13:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLeBP-0002uD-Qm for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:13:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLeBP-00Gogq-6W for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:13:31 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae07947-8faa-0a2a0a5109dd-0a2a450cc374-20 for ; Tue, 27 Oct 2026 11:13:31 +0100 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 6ae0794a-f479-0a2a450c0019-d155802ae49e-3 for ; Tue, 27 Oct 2026 11:13:31 +0100 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a35a60499eso25321485e9.0 for ; Tue, 27 Oct 2026 03:13: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-4a35a0bb112sm274976505e9.8.2026.10.27.03.13.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 03:13: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=1793096010; x=1793700810; 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=1pxpMjEb0hQvd2R+JRIp+EazxhcsEOeZfVTyOgnj35M=; b=aG0lbPhQ9oa9WUXMroYrumwShMj3d8kYgxHDKtOoiZ1+lkCrOGwZeBSozDBOF79/qv 5AAT2yUsSI2zcUR65CGiT1Yq8JyiWatxmN51J6687O0F+KERFsxvyyI/x5KXBIwnzu+5 iJy7dECbUUb0ANUJJnah5aVRF3zyFUgfui3a/BE7izYqqmsvhMGlqpjDCNHcM81OEpjc uv165QAzbzvp9EmtlaDeFHc3VwBAFUe9dx5syNXk47q/ESOkEGz4Ag/NwomiABlP+dyn ifzhtY4NfWwXezntdNfr+zzDv2L4EhEL/XTM98EpwJdAqKmIfTH7XsK5Y0vhMJ+ONKSN Wt/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793096010; x=1793700810; 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=1pxpMjEb0hQvd2R+JRIp+EazxhcsEOeZfVTyOgnj35M=; b=Rt5Xg7aMgVENU3potVLy4IZ5ogFdLnqczTjWTVAj3QkaM3G2wtjAroi79x6VKHjPoi vvyw34ZXExF078sh8bAdJVRGPIre5L2waJMNRFzUO38Ep8XHSsOh5FaRoasti+qx9RKc xq8tWQdgtORkWRm+kvTg07cCikLN/jI4pMiDC7AW7YbZ3s1kez+OlEFQjracya6pqFic xfZSMAYZaHtUebzm4WV/+7jiR03Si180Hxb64OT+eYNs+nhfFNB/WmUkifcp9c0+wGn8 RWZaICParF8wLHeMaPS3EtKQXtUhjnuegvS4butD/2EEjscjRiovwulFKtrCh5YS1JOu 1gBg== X-Forwarded-Encrypted: i=1; AKwUvBwq4OIE9O4csY8D/Fv3tCAwF7qySvmm/YzUf7cexUbxNNtU+8w9TJ249OcMS0BJgz7EppaxFoE0l2Y=@lists.xenproject.org X-Gm-Message-State: AFq9FYKdr2kEADh1Hf3d2PVZWJ93fndrV7+cr8LLzVhccNOlrd4Iw8AD cgeWtXCjWl2pyusJxkOapu4IdxV0yjoxn4PLFKai9QsU6nSDKrNd2kUD0/ghCr3q0Ze2lqvdHT+ WZ24yzA== X-Gm-Gg: AYBFou1VEziPQXihU3wR6HwgsLs1R/5mhWpO2YgywhtqBXLKj1OYGr+faxlpqVV3hm6 pnXvnaLaHdXqPmRfwyZMewcQMx7FdoMIvR778T+v0aGzNv8AEIecusu5sGr27+MurNoUPqWLtq/ pMQ9ThbXUH86Mk5IFaqjVN3PRkR6oZXVMZN9NHMnoRtu/Viip6+wKhBlsWog5uNcn/mW0PbcF3v qhum4aLC2tVb9SM+oTjVkjVgoVqQ5gnIocMZpuTUEPvzLgaAq69LRnmTZ9hCaqh4ebdRzvWCAtu YD44Caky6EatBdMcLiMcpTUANV3H7POUOycFhJTA6Aytl//2rhq4hLRnYlCD51Q1DqU8M14Mfcg voHwqdrE5J0t6ppl0OOs6mr8us+o4QjtZPyfD1PJKR6AZSz3/KvwJxzUricUHm3Bl3x8c1AlpWe KxsfUM64C6BtqwwO2c5nJDQV80MLlrqcGMLg9UCOQj/4hsP7HTUvr1oW7FjAWnl/Vi+3URTWGwB t+kqiXKyloon5Jv/L9sC+/gg8ND9a6s/mxeFmeAlxdeZ3YNpWXtTCr9j6FQ7f9XbKXG6MtjaUHv KCGTzu172Z3m/A4VkPTiLGxBpRYR9acfcHvc4ZT9w6JH X-Received: by 2002:a05:600c:6384:b0:4a2:526b:d410 with SMTP id 5b1f17b1804b1-4a35aca72e2mr163241535e9.13.1793096010457; Tue, 27 Oct 2026 03:13:30 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 11:13:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/4] x86: record SSP at non-guest entry points To: Andrew Cooper Cc: Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <26f23087-e864-47de-84b9-0e3dc10dc941@suse.com> <78ead290-fbf6-4aa8-b918-1f53abe2dfca@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: <78ead290-fbf6-4aa8-b918-1f53abe2dfca@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1793096011-50B3DA5B-1B96B508/10/78276251493 X-purgate-type: spam X-purgate-size: 2934 On 16.10.2026 19:12, Andrew Cooper wrote: > On 27/07/2026 11:26 am, Jan Beulich wrote: >> --- a/xen/arch/x86/include/asm/asm_defns.h >> +++ b/xen/arch/x86/include/asm/asm_defns.h >> @@ -220,9 +220,11 @@ static always_inline void stac(void) >> >> #ifdef __ASSEMBLER__ >> /* >> - * Push and clear GPRs >> + * Push and clear GPRs. >> + * >> + * Use sites may override ssp to 0. It should never be overridden to 1. >> */ >> -.macro PUSH_AND_CLEAR_GPRS >> +.macro PUSH_AND_CLEAR_GPRS ssp=IS_ENABLED(CONFIG_XEN_SHSTK) >> push %rdi >> xor %edi, %edi >> push %rsi >> @@ -233,6 +235,9 @@ static always_inline void stac(void) >> xor %ecx, %ecx >> push %rax >> xor %eax, %eax >> + .if \ssp >> + rdsspq %rcx >> + .endif >> push %r8 >> xor %r8d, %r8d >> push %r9 >> @@ -259,12 +264,18 @@ static always_inline void stac(void) >> xor %r14d, %r14d >> push %r15 >> xor %r15d, %r15d >> +#ifdef CONFIG_XEN_SHSTK >> + push %rcx >> +#endif >> .endm > > I don't like the ssp= parameter here.  It's invasive at may callsites, > doesn't 0 the value in all Ring3 frames anyway, and the asymmetry makes > the construct fragile.  Furthermore, the manual register scheduling > really isn't necessary on CPUs where it's not a NOP. > > I suggest having this: > > +#ifdef CONFIG_XEN_SHSTK > +        rdsspq %rcx > +        push  %rcx > +#endif > > always filling in the value.  rdsspq is pretty close to free (frankly, I > would be surprised if it wasn't subject to mov elimination in the > pipeline, given how tightly coupled SSP needs to be to RSP for CALL/RET > uops to work). I can make that change, but I didn't code it that way from the start as there continues to be no evidence of what you say (no matter how plausible it reads): None of the latency / throughput documents I can find lists RDSSP. >> --- a/xen/arch/x86/include/asm/cpu-user-regs.h >> +++ b/xen/arch/x86/include/asm/cpu-user-regs.h >> @@ -11,6 +11,15 @@ >> */ >> struct cpu_user_regs >> { >> +#ifdef CONFIG_XEN_SHSTK >> + /* >> + * This points _at_ the corresponding shadow stack frame; it is _not_ the >> + * outer context's SSP. That, if the outer context has CET-SS enabled, >> + * is stored in the top slot of the pointed to shadow stack. >> + */ >> + uint64_t entry_ssp; >> +#endif > > This needs to say "only valid for interrupt Ring0" or so.  Even as > written using the ssp= parameter, there will be a non-zero value here on > some Ring3 entries. The value being non-zero doesn't mean it's invalid. It may point to the very top of the shadow stack, which is still a valid value. If you want this made explicit, I can add "only meaningful when having interrupted Ring0" or some such. Please clarify. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 10:18:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 10:18:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462016.1673064 (Exim 4.92) (envelope-from ) id 1xLeGC-0003je-Cm; Tue, 27 Oct 2026 10:18:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462016.1673064; Tue, 27 Oct 2026 10:18: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 1xLeGC-0003jX-9w; Tue, 27 Oct 2026 10:18:28 +0000 Received: by outflank-mailman (input) for mailman id 1462016; Tue, 27 Oct 2026 10:18:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLeGB-0003jR-6b for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:18:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLeGA-0066CK-Ja for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:18:26 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae07a72-e002-0a2a0a5209dd-0a2a4508a1f0-4 for ; Tue, 27 Oct 2026 11:18:26 +0100 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae07a6c-f659-0a2a45080019-d155802de039-3 for ; Tue, 27 Oct 2026 11:18:20 +0100 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a3517554f7so27461565e9.2 for ; Tue, 27 Oct 2026 03: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 5b1f17b1804b1-4a359fbc718sm216547825e9.2.2026.10.27.03.18.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 03: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: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=1793096300; x=1793701100; 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=GJQ7loJXaL1zYoq9547GYZzn7EyCf30kF0nJ+j5ZqX4=; b=HGGvwH+Zsd7kPj7+xTAVyqhmW6Av9xaK31/e9twGwXxNbxkeE/M9QlRaZc3eGL4nlH kzzgO3/uZhH/N6JdWyFQBJppku6B84i68pkZ6GMd4b7ru+14pvDKx4hkQ/FaFum3NSAy Tbvu+hl37b75uD5ZZL5KvOUf+F0RYfcSBb8CITZjJA4uX4+E44oevHxYZGGrDVEqBVmv CT6Tl8S3F1z7mhcxG/yGLjnq1piiuGXerC4rLSvzYwt7V9rbf4fe2bHnj3nqFgfN7veN RtIgf7Zwmy/2zlso+QkXf/b9EwkEysGEvH1tg8WQvsS6rHMf+QjsbT9DdcqMRUcEeYtz tuEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793096300; x=1793701100; 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=GJQ7loJXaL1zYoq9547GYZzn7EyCf30kF0nJ+j5ZqX4=; b=uxfmy/f7rvZ0Q2PaClQ/HYesud6ElLA4qhVumXiFBvf6LjgLy7x8ByZwUCnZZyQsvF LIxHv6YjJNvme9wTyE74zglSkljQJ7iY1FSOHGGOXsqLjv/qOWTgwAMrMixipanxOp+H at6aFAzZjkQIo/Qwdz8BUhBniwEEriUtxFVGARMwXUQg0lODUu29dOZhIV6DCftJ4RO4 GCnVMNp0g7g4YIXG/jV+/vPnxBcgLQ4g9g/oIN7xs50iXBH5UzHjGMS2JF+p/Vwp/G/w B15+LUe97Hl1ByTUIciGye/yjTh8AFbEaEtdhUCapAGD2uCwFVRZfqkoVaCPBCzMQkY7 V2XQ== X-Forwarded-Encrypted: i=1; AKwUvBzWHSdwbB4I2zyQATi4mU7CdYbga8uBHli9Tbxclst/2KnK498+DpWHB8zcxf7uVdi0p9EoN14Qquc=@lists.xenproject.org X-Gm-Message-State: AFq9FYKPE96qiNtj7pAsJLZul0HygBnRRivy7T7dfP9fKQeAyWSSJQjt oXkOAHHAq5Iehh6WIy13vSpjw/yywPUFsl6j1QXdn0Tt2uOB6e3WEcWzOwMgVKgTVg== X-Gm-Gg: AYBFou0Kwf6NYQ22qrLSn8KVHzLBenSnikoDn098JbSqU1W+N4qIU2NFMSI1Gf9Knt8 hY3yAMYK7b/9c30krn/9lIrCljUDCYVZQ/vyc85W8L7xgQy91STFxnKbYrxMKz7S9J4DdRpUKjp UghOciq+0T5Azghj/zF5uum4In4pJOZC24ucmILnAWaLOH7ax4eXrEYTIcaayivwOTRQYRrKm39 De4Jer8LQTC0fY6Hjs/oaAdP+eHPM+NFDpr+ulhRQtKaR4xFo+rQ14B5jIQeBDptutBuBXV6ceD qy3z5rRPYX3+siGmMorfSyPZ8l3AL3y70QWOynatoHb+h+Li0z1odvHQ9HT90/w/GRckVcjfgZX 5drdv4ao2oHlEKU7F3MrpIQtK8zokHKTqjXE26FCPWHJZKm+ZVTzp/2bql5aVHk1r0vxInF+eBc zKbyfamvIh8kCPXZEIdWE24y9sP1bWwUAamnJg4gxdgThtC9bHShVs7XTpcpBA/sUDOMgNYucW5 /VFvyFHzYNgF1H3ehuyjrclOEt3XT7iEt3USooMVx7temke79GlqMpekBNHDuB19wKt8dVgRfpW iQv2x771gbBmwfGfDh15MgbVNlxUtHKnQOOzzZo+cv5RYNKoWlKGqO0IQIOA7th68A== X-Received: by 2002:a05:600c:530f:b0:4a3:2f35:38b4 with SMTP id 5b1f17b1804b1-4a35ac8b2a7mr198614425e9.10.1793096300231; Tue, 27 Oct 2026 03:18:20 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 11:18:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/4] x86: record SSP at non-guest entry points From: Jan Beulich To: Andrew Cooper Cc: Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <26f23087-e864-47de-84b9-0e3dc10dc941@suse.com> <78ead290-fbf6-4aa8-b918-1f53abe2dfca@citrix.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: 8bit X-purgate-ID: tlsNG-c1860d/1793096300-CE74387B-F70C115A/10/78276251493 X-purgate-type: spam X-purgate-size: 2415 On 27.10.2026 11:13, Jan Beulich wrote: > On 16.10.2026 19:12, Andrew Cooper wrote: >> On 27/07/2026 11:26 am, Jan Beulich wrote: >>> --- a/xen/arch/x86/include/asm/asm_defns.h >>> +++ b/xen/arch/x86/include/asm/asm_defns.h >>> @@ -220,9 +220,11 @@ static always_inline void stac(void) >>> >>> #ifdef __ASSEMBLER__ >>> /* >>> - * Push and clear GPRs >>> + * Push and clear GPRs. >>> + * >>> + * Use sites may override ssp to 0. It should never be overridden to 1. >>> */ >>> -.macro PUSH_AND_CLEAR_GPRS >>> +.macro PUSH_AND_CLEAR_GPRS ssp=IS_ENABLED(CONFIG_XEN_SHSTK) >>> push %rdi >>> xor %edi, %edi >>> push %rsi >>> @@ -233,6 +235,9 @@ static always_inline void stac(void) >>> xor %ecx, %ecx >>> push %rax >>> xor %eax, %eax >>> + .if \ssp >>> + rdsspq %rcx >>> + .endif >>> push %r8 >>> xor %r8d, %r8d >>> push %r9 >>> @@ -259,12 +264,18 @@ static always_inline void stac(void) >>> xor %r14d, %r14d >>> push %r15 >>> xor %r15d, %r15d >>> +#ifdef CONFIG_XEN_SHSTK >>> + push %rcx >>> +#endif >>> .endm >> >> I don't like the ssp= parameter here.  It's invasive at may callsites, >> doesn't 0 the value in all Ring3 frames anyway, and the asymmetry makes >> the construct fragile.  Furthermore, the manual register scheduling >> really isn't necessary on CPUs where it's not a NOP. >> >> I suggest having this: >> >> +#ifdef CONFIG_XEN_SHSTK >> +        rdsspq %rcx >> +        push  %rcx >> +#endif >> >> always filling in the value.  rdsspq is pretty close to free (frankly, I >> would be surprised if it wasn't subject to mov elimination in the >> pipeline, given how tightly coupled SSP needs to be to RSP for CALL/RET >> uops to work). > > I can make that change, but I didn't code it that way from the start as > there continues to be no evidence of what you say (no matter how > plausible it reads): None of the latency / throughput documents I can > find lists RDSSP. Oh, also: You implicitly indicate then that the code size increase for those entry sequences then isn't a problem either, in your opinion. I can accept that, sure, yet my personal view is that it isn't helpful to have unnecessary insns anywhere, no matter how cheap they may be. They're never zero cost. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 10:18:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 10:18:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462020.1673073 (Exim 4.92) (envelope-from ) id 1xLeGb-00047F-Lh; Tue, 27 Oct 2026 10:18:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462020.1673073; Tue, 27 Oct 2026 10: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 1xLeGb-000478-Ie; Tue, 27 Oct 2026 10:18:53 +0000 Received: by outflank-mailman (input) for mailman id 1462020; Tue, 27 Oct 2026 10:18:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLeGa-00046y-2T for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:18:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLeGZ-0066Ng-FS for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:18:51 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae07a89-bab6-0a2a0a5309dd-0a2a450acc2c-10 for ; Tue, 27 Oct 2026 11:18:51 +0100 Received: from [52.101.57.10] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae07a89-f2d2-0a2a450a0019-3465390ae847-3 for ; Tue, 27 Oct 2026 11:18:50 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH4PR03MB7627.namprd03.prod.outlook.com (2603:10b6:610:241::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 10:18:48 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 10:18: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=nFazbLi73J3qaYMDN+0Fwb4+f3+O2i6j8Nmf6lqzX2d8yMN80CoDfQfjVeoFaHwV7z8cLP4foyVJqGDudPMTIC6J8cPDvzKyuGgDOSiSMrwquE2zN72LeGR6oSN2Kx0SGFd5zFohiRXMUdwoBUxPYFTD8XX/PA+9F/qfCz7DrUXCqss75sRYJPPzC+ThgvuRVsL+3yhBaWW+rsx36EjEKA4XqAnL3JiAg6/Z+MBskhrq/j33P8KF2dw0ZAAxTIjl0PTOPay+Ko+hNbTwV/QIlgIJ6AoyXnzucrCVK+XmxklUZQ9tpxBzUbsOZ+XqpJxU58i7QIxXu+vF/F6T5RqNKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pf56grjtOfLmzjioLIubPA79mHi4tW9LpOI/3/Tl2Zg=; b=WixFkNBe6Myzv4DIOlXFKzgdLWkWSaLnYQ94t4Ly65dBWSaok7mDT9NzYk2yAryyWXRffJa/5LArR3nv9KPMepBq8WYZVwYeLnTcKRGKOGKuu5GrISdGTalUaN5/N18KbcDAO1n4tcpx1NHwjbpyoifgroLO/GQ4zUsJItrqSl4Rzn4Fcj9kwb+NE4WkQRzmT6VqHP5hk/df2S4Srrtm7cyed3HqUr6RyAkZnOHC1j8xNR82WjHiOftNC2Grgynar2c2ez9Hl3/4jxE4iG7712Mp4SQpsPAYu66XSTaJsmHPUlyS3Dri7p/0IbvxN6c5IqN4ZQH2ZRsSJfnmWxX2jQ== 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=pf56grjtOfLmzjioLIubPA79mHi4tW9LpOI/3/Tl2Zg=; b=vL3T0hIOZ/aCdBKkhx9C6Vsbha6o8wu4BVPToBVZ1VToCnwyGsGttvo9Yp7mME7mteWMNEyoRVCPeUBvKXsm/T5xL3hkRbgoq0n8g7sElbg+6zSESkkRSqoICscST6Pn3BaWFT/YM0gXdxyPnPxSLsFNuKO05dM31Z8FyjXXJqs= 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: Tue, 27 Oct 2026 10:18:44 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org Subject: Re: [RFC 0/5] Introduce dynamic tracer using Livepatch To: Ryo Takakura References: <432e0fba-0765-4c2c-866f-faff8cd04926@citrix.com> <20261027043730.60174-1-takakura@valinux.co.jp> 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: <20261027043730.60174-1-takakura@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0218.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:374::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_|CH4PR03MB7627:EE_ X-MS-Office365-Filtering-Correlation-Id: 5c58b44a-dbc9-4bcd-5d72-08df3413b04a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|261026140227099003|4143699003|56012099006|11063799006|261009223027099003|261022105027099003|261021121427099003|261022075727099003|18002099003|22082099003|261026121527099003|10067099003|3023799007; X-Microsoft-Antispam-Message-Info: GOtdfVeOIzVEgeYOiMG3AiTY/txKW+IFEescOcqb+4/Ny0HbSra1zK4k5fl16r2Tm9qhMAc2i7AJad0T/VtoHh3FNlBxnw066ck7ZUIWcafUsOE+Nu8BJFdoAjVM15/warKQRgBMJZB1xmOVNOFwrj5c+GLPhVU2rSM28hXpTtTafjTutYDg2lDyD7dgOuxr8/bqvt323Nlsl1Ip5SQdGUzWMYWEinYC8UYbFFfXBJP+Kw+IZGuDRHDFrJzbGA3Axtmi5Q4gGzSpmQ0AoqbFWpcO+SqY8bL1iIdNJOSaVJKEjKgrCT6BWSQ/yCamR7dYdxwdMgZYT9ZGY4tMETrxtbH2VzyBv5tj8dwpiMfdlhc85RbLILzxdNbGd4/+3lktMRx+44TmKIhtDiudi0rt/WsQNlbXr6Y/MEoNAsQLDYaLS8F9PHjUKhQwGd5cX+LQhP7xanyXgd9uqef4XCV0ljooIpt3JANSFlaFnSXr4+yz2N90BI3b3vYMQAfr3XJPMQOK8RE6ueFk9rwqiLYYdVN2D8nQhBnzFbl1xgDQwmPBkM78+tzBDoPI9S20GsuzXZpaqBWiAkg1osec1RuEr0SbutvxAaclGQji7DvrKw+Wh6gECbiFZTsK70XpYFU4 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)(261026140227099003)(4143699003)(56012099006)(11063799006)(261009223027099003)(261022105027099003)(261021121427099003)(261022075727099003)(18002099003)(22082099003)(261026121527099003)(10067099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NUJmTnhxZ3g2TTVHUWxJSXRtazJaVUx6d24vcDU5bUhMT0tjL0VnMTN6NE5h?= =?utf-8?B?bEdPOHoxTHNnLzZBZGt2QWFaTkJ1b1dpYTNBQmYrMU9ZZ0Y3M0t0azBVKyt5?= =?utf-8?B?UTI0VDJveEFUYTZYTVdYQitWY21GdjBMTFR1ZndsU0Iva3hxOVRncExaWW9i?= =?utf-8?B?bDRIZzRKVElVWUppVmtMZTFhQTFoYzZySGxuUlRqdzVPcS9MZERvcjlXbklT?= =?utf-8?B?UU42TGQxZFpEb0MrWlRXRG8zNFdSUEpJQStRVnBSaGloRDNkMHJodGxHM1I3?= =?utf-8?B?czErRWtYZGJvRWRJRGdTNVBmQTYxV2UrOFVCRUdPMm8wY2pucTNiMEM5TU04?= =?utf-8?B?YS82dUY2VFlFb0d2TlJEZGxqNys2NHZRM3FRME03bmJ2Z2t6TU9QVys1VFpz?= =?utf-8?B?SjFSV1dQeUdibEpLVUlCMFVzSHJhbmVyR0IrZ0xCUHJBSmlDSldmaUlRQ0FK?= =?utf-8?B?YURBcWhmSi9HUzg5aE1WZDJWVTZGejVlV1g5RVJBYVV1S21CMElrQTQ4YzNw?= =?utf-8?B?WTRaRk9LWkxtWEtiVnRpQXJlMUpudzdqcHpHR0gxZWN2UHZYLzVpUDZNNGo3?= =?utf-8?B?K2g4V29XdFQwa1NPMlFpUlRGSi9Sb2ZjY2JKVXhlZktkTU9oclZQZnFxU2VN?= =?utf-8?B?bTc5d2pzUHVzZlVGbk0vUHlDM2ZqS096RElocWRlaU1SbDA3QVY0U1hodytC?= =?utf-8?B?NGRRU0NQWGhLK0drcjA4dTEwakhiblZOWTZtS2hWS2tOUHBzU0R2aGtldHNF?= =?utf-8?B?NXIwalVnRVJwQ2VuQ2pnNFExOEtnVlF1Zy91N0Y1OHZwQzNQRkpsYStVRmFz?= =?utf-8?B?akxuR1Uxb2s2bk5wYjNlNGNjR3MyenJhODVHTmJQSzdWWVA0Yit3c2l2YXNV?= =?utf-8?B?NXZ4ejNvanRPanQ4OEE2aUoyWUJzVGc1SGxFK3NuMXd4dERmaFg3ekVaU2V3?= =?utf-8?B?L1YvZng5NFR4QXBISzNsWEx4bmN3TkFFdmxiVlQxdjdsL1E0WHpZeDRLa3Z1?= =?utf-8?B?a3dSN3E5cWxubkphWHkvN0dwT0pVY1lmOTNsTXJVQkhrRXFESEluQTFGQmh0?= =?utf-8?B?d3Z6bjFYYzZFcHgzUkR3Ylp3VEZuWVN5eEloQjdUOWNPR0xwb1o3SzkrNTVu?= =?utf-8?B?YUR4dTZVRjc5TXlTeFk3cm42ZStwV1puNklDMHYyODZuY1p0ZENUZmF2alJz?= =?utf-8?B?bVFVK1hQZmZxSUxWb0E4cWJhcHhpSS9PWVgvVWUrRnVGMy94Nk0xUkduczZF?= =?utf-8?B?MVhlMWJRQzZrUTJidE53UFp2dlpsR09DeFZHRm5jUFJWRnl6RStLZ1BUMTNF?= =?utf-8?B?UmVrRDVGcHRFQ2Q3T1NzN1Q1WTBhQUlOc1psYU01a3JvTUNsSkxEcjNiSXFQ?= =?utf-8?B?N0szbFNpSGhwL1orUlVybEtJcE9tbGZZUUxTcEZQc1Bjalh2R09jQnZpajhI?= =?utf-8?B?czUydHJpQjEvejYwYXR0WlVvcFUwTVJKWWxWbTh5eW8xYy9JeXplbmsvY2hr?= =?utf-8?B?alVldzkwU2tVMGd5Uml2MlEvMGgwMk9IYjBIR1M3Mi9hcWtTYm5KNWJGWnVq?= =?utf-8?B?cVNIeHNyU1Y5OUxESllQMDJCMWNWbjVheFZCZk1hL1g1WE02bmhCaGJjVUUw?= =?utf-8?B?SmQyS2w0Nk14RTZ1WXYvNVMyQjlPekJDL2toNDRqT3Fid2wwaytxLzYxN0JL?= =?utf-8?B?TTRONmc5Mm8yUVhOaGhlaERtWWZNNWgyMjZKbUpWVG1tWll3Tm5yQ2puQktZ?= =?utf-8?B?V0FJSnJIRnBwb2MwZFdkSEZGUTN5NU5QUlNSSnpPTmpsSW5SLzBBTDFFVzZy?= =?utf-8?B?am5seTNFSUpDVllkOEI3VUl3anN0WVAyenk5Q1luUmNEb21MWUlmWDlBd0c0?= =?utf-8?B?TTJ5dE9hRkpVTHNXTVZhSVVsd29VZWFmb1FYUFlQa2dKNjRBS0R1WmNqTmVi?= =?utf-8?B?aTU5cXJvSjRYL2lrVXZRcWxZellwQWtOdWplL1hKVUc4ZGJKY1ZnOVd1YVE2?= =?utf-8?B?RmNDZHVzRHR2WjduOGQ3RXFlQ3hSakdRZzl2RTRQa1pja096azB0b2lBNDZv?= =?utf-8?B?SWtTcTVQUFlObDgrbkJzcTdRaEV3Qnk0VTRnMVkvZStEMHdmQXVSNFBuZDBt?= =?utf-8?B?Y2dOYkRFaW95SjlnWXZlaTgrd2k4QVZlRzROS05TRW5raVNLZGxCT2ZFQjh6?= =?utf-8?B?clFkbXB2S2UxakNIWEJQd3JMNEMxcnVlczMzZnMwRGFWWnJjbGRuOStvcjJX?= =?utf-8?B?d0VvTnVyc1lsaElWTmptdFF6djNYT3p4T05wY29sUXZ1enZ0N0RMVWk0V1Vr?= =?utf-8?B?L0c4YUMyc2hGT1JnKy9lallIbjZnbTlTZ3NtOE80NWF3OHdpSUNxdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c58b44a-dbc9-4bcd-5d72-08df3413b04a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 10:18:47.8144 (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: 8qP1rQCIuyi/RXBw7QvWac8eBEANaar//SqICpjWN1CmYaBJg396VngqHEt5zZEGvJKJ2sqMmwZNQKqu/FfmParII3/+cpcDnNEAXzmWumE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7627 X-purgate-ID: tlsNG-4011c0/1793096331-502F0CFC-6B33B757/0/0 X-purgate-type: clean X-purgate-size: 1603 On 27/10/2026 4:37 am, Ryo Takakura wrote: >> You are also going to need a GCC_PATCHABLE_FUNCTION_ENTRY_BROKEN symbol, >> because of https://godbolt.org/z/sde4faxaz. See the ASM_GOTO_OUTPUT for >> another example of this pattern. Just use a plain version check rather >> than tying it to XEN_IBT; this is a new feature and people wanting to >> use it can use a new enough compiler, and it avoids variability >> depending on other options. > I didn't know about the compiler behaviour. Thank you for the detail. > I'll make sure to check the acceptable compiler version and add a version > check as you suggest. https://maskray.me/blog/fpatchable-function-entry seems to have a blow-by-blow of the bugs. The ordering with respect to ENDBR instructions is the only issue which will affect Xen, I think.  We don't use COMDAT, or BTI on ARM yet. Clang support seems to have been mostly correct at the point of being added, which is rather more than can be said for the GCC side. >> Separately, you have a number of MISRA violations which you're >> introducing in your series. I see you've got cf_check, which suggests >> you have built in GitlabCI. Have you also run Eclair? > Thank you for pointing this out. > My apologies for the violations. I wasn't aware of the tests > and haven't run either of them. I added the cf_check following > the existing code that I referred to when preparing this series. > I'll make sure to run those tests before sending next version. Do you have an account on Gitlab to run the CI testing?  If not, reach out on Matrix. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Oct 27 10:21:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 10:21:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462031.1673083 (Exim 4.92) (envelope-from ) id 1xLeJA-0005py-6O; Tue, 27 Oct 2026 10:21:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462031.1673083; Tue, 27 Oct 2026 10:21: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 1xLeJA-0005pr-2O; Tue, 27 Oct 2026 10:21:32 +0000 Received: by outflank-mailman (input) for mailman id 1462031; Tue, 27 Oct 2026 10:21:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLeJ8-0005pj-MI for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:21:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLeJ8-009t3x-2n for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:21:30 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae07b28-2eae-0a2a0a5409dd-0a2a4501c952-4 for ; Tue, 27 Oct 2026 11:21:30 +0100 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae07b29-5984-0a2a45010019-d155dd2dad59-3 for ; Tue, 27 Oct 2026 11:21:29 +0100 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48e10a70540so2294314f8f.1 for ; Tue, 27 Oct 2026 03:21: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-48e3ebd47basm23953227f8f.32.2026.10.27.03.21.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 03: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=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=1793096489; x=1793701289; 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=sgioH1x09sJmztOki28uCEJQQXiJJrrtGbmK3k9wkpc=; b=HiJSB7P4R67r5WpvfeT0XHFmoMuLFJvFE5dlj2HbwiawiTKyUMMiW/6OKRalmDXDdq mgvIGDwPsdiyIwS808q8DTBQcJ7pjPGD65i0RFZXyC3Wil7YI8JxRkIYHf6G/lUlksw9 jQJozE7U4z8iU5JFUy2oeduYvsGxfpzrd/maVpviIaHTRUTRhww3opkmzZXSen3G672H E0Iykp+QUFc19ptjt+4tUM9Rup6E8rJs+OdZT2GKu1QHUioSpbrKclLcrEVixXCjb6VD tHM6azzecggpcPxVCKp4obxCgCDeBSC5RgiimQ7kMfBrAguAjDWEy9QXdcUfGmKcf4y0 26ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793096489; x=1793701289; 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=sgioH1x09sJmztOki28uCEJQQXiJJrrtGbmK3k9wkpc=; b=eJIewPr6/LOGeBhdB3Kd56tUVdLFpjBz7nUtSZSeCXgPxVZDDn6gsCIu0Ctp0YmHiM JWLIJzdKED9pwHXPy8x5fIM3hC7Ef8i1ILQHea0c3ssukr++eA/Hb3t0QN13DmHz1Xo8 m5yJY9i0Iwtx4teZbCXWIGJxuzv9AdIjZyfXVkN5WtpJcXcqmTlNkpup/eZIyMlY82WX F0zYmoIe4DIVDhJ8AstTS+vOdBrGYyivSIi4XlcLNAtmn8Ochm1oWEBXKdii+s2Mwaly GDmyljGRbhTzwwPakypXxj/iJecLPKTvnvzI73mmS7Bw902HohoUMiadwLe9sL0rze4+ ly3A== X-Forwarded-Encrypted: i=1; AKwUvBypruFY6401r4LLXSaKBXzuEB23i4sjMYVeVJgxsbTB0I1ndgvr218zXOMzSlNhAZzJgP6ndp4Yj6M=@lists.xenproject.org X-Gm-Message-State: AFq9FYLAzGaZQx4cwY8IQVaJzO0pXfpCeZDW05YhDO86jJELxFNRET02 NpGj7jCCcFDWl/6QNhjd7dSCmFyetwZMgsXMLJUEAg7G2vzhHXDvR5SOzAv8VHk9Cw== X-Gm-Gg: AYBFou3D0MEeeV6HBBB5vKL7/o1mH4RD7MJ1QbFVNKfwVuh7oGRdJK/pxyjkPzbpvME vTcSXtjDJau/G/FLVuHHrFiy7GWb8S0WzIqFq+3GXfUSlErzObkQzJUrNmxlih7qQQZAvPcgzrd J+lsdhN8TWYtlhzyV0hw/rS06CR+CKJXWQ7FszvV6qMtQNM6Yv9Q1aI6ZUQqsrQESY3dnDMabRs A8BmD0MFQrjw/u8YM05bEHovuW9xC6R0RC/8iPior4/1sO7CIpUe1qnLTDl9x+MoadxSEd4M7Kw AQbfm+ogK9jkMfOs2FoegjCq/1fv15EhXGe316tCLfOeNECllL2SCzU2tN4VSFTENtJfg2fXNPW lqPvDL18HLQZ3NfbA/ebFRj48825l7UVvogh/W5kAU6COKsfQ3mzeXJLXCKReKCLUTPAEfIXtX9 w+c1hVSEL6qz3/otYzvAhsU3HKdvR9Jj3/TNoxxWwqqW0xdlagbdID/bdtKcnzxuemoz/kZH6ce JZ0a9nZkhtTglXlmGLB/7mI3ZDnfDu2q3lobD2SrvgLa9MJ6c6EvmRb32pj7gF3k2Undq+R7JHk cIsMxGcmGUoJSynnzgMdHkKNEU8vJcPXWm198QxpxHZRh8l1XxYsdieujaUoJiM1ow== X-Received: by 2002:a05:6000:2501:b0:48d:f14a:9173 with SMTP id ffacd0b85a97d-48e3eb247a8mr16833625f8f.8.1793096489354; Tue, 27 Oct 2026 03:21:29 -0700 (PDT) Message-ID: <97a123f8-92e8-4ff8-bb3b-a48ad2fe1392@suse.com> Date: Tue, 27 Oct 2026 11:21:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code To: Mykyta Poturai Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand , "xen-devel@lists.xenproject.org" References: <8b2fa10a-17ac-4807-b9d2-874f84a85efc@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-d62444/1793096489-1EA66757-B4882DFB/10/78276251493 X-purgate-type: spam X-purgate-size: 1064 On 27.10.2026 10:39, Mykyta Poturai wrote: > On 10/26/26 2:34 PM, Jan Beulich wrote: >> On 26.10.2026 13:27, Mykyta Poturai wrote: >>> This is preparatory work to make vPCI MSI-X functional on Arm. Split the >>> vPCI MSI-X code so that intercepting the MSI-X table and PBA stays x86 >>> only, >> >> This likely is related to peculiarities of Arm's interrupt handling, yet >> on the surface I can't see why not intercepting MSI-X table accesses >> would be safe. Would it be possible to extend background here a little? > > On Arm most of the work is done by the ITS, so the only thing the device > needs to write to the doorbell register is the EventID. Interrupt > translation is fully configured in the ITS; it will reject invalid > EventIDs and also has a sideband DeviceID, so misconfigured devices > cannot trigger each other's interrupts. Memory-wise everything is gated > by the IOMMU, so a wrong doorbell address would not pose any risk either. And a guest fiddling with the mask bits behind Xen's back isn't a problem either? Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 10:51:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 10:51:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462045.1673091 (Exim 4.92) (envelope-from ) id 1xLemT-0002UH-Be; Tue, 27 Oct 2026 10:51:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462045.1673091; Tue, 27 Oct 2026 10:51: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 1xLemT-0002UA-93; Tue, 27 Oct 2026 10:51:49 +0000 Received: by outflank-mailman (input) for mailman id 1462045; Tue, 27 Oct 2026 10:51:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLemS-0002U4-BI for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 10:51:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLemR-006DqU-3V for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:51:47 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae08232-2eae-0a2a0a5409dd-0a2a4501979a-26 for ; Tue, 27 Oct 2026 11:51:46 +0100 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae08242-5984-0a2a45010019-d155dd33d0a4-3 for ; Tue, 27 Oct 2026 11:51:46 +0100 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48e20ed3b9dso3603856f8f.2 for ; Tue, 27 Oct 2026 03:51: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-48e3ebd4ba7sm22256148f8f.33.2026.10.27.03.51.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 03:51: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=1793098306; x=1793703106; 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=BmcB+jm8qoXpN3NNg9Da3f6QRhX7AatPegTJgXcy+4s=; b=Q36Qes0nvdKfl6gb6O5+kLopbLHdmACAzxsCB4s/J0K0Ecigs17+PqYZ3gewmSuUlm O+oauH1zdL/M7hLBPqdR6x2OLHMCuz1A5YmNRmRohYVQ8dXlZP46mBKSxxz+oXcdIuUf iKJb852l8LRnFaOFIfaCf78CwGiZ+iHm6WdnbmHBWSMl6I8hVqYX4CU/PPJqG0QOXIaG ztGX2bxYH0t2ihbaBVYIJe6DscNquNmblm/Qyp9c0g9D0NBEyzYXn4kEK5WEwDGaYlQp Fd3hcBFcp/ViGifpoeXPR82dCDvsPbT+3z61WyWgKtK6MJQB0OpDvVa3NAnUscX1TlHD nGDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793098306; x=1793703106; 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=BmcB+jm8qoXpN3NNg9Da3f6QRhX7AatPegTJgXcy+4s=; b=t8859auemr+YHq2XvS7tZO9Hx0M2VfdUePUeSDH9zPoph+Ao3LrONPUsLjObnOEW4J yewwesdW0dsqJMpk9PUIb25FNPzRErB9zAaP7twy66sCOfOL4ZA95owUEYDnCigh198H uyM6FA9Z9bJ8ECVwejgbSZkx6E7d0ht7v29cVfKbKeF8AvpYiDfeEPsBiqXUDzuRVXrc 0VSu9DTHVdLfZuMHhKixuKbYX6z0gQ0MgR8ip1zbHZ8IAvG8NXKa4yjwjlt5jZQ/C3lP BcyTXI3ETW/sSLY501J8FAR5AMwxyQy7ASGfm8vZOByeXh3/k1MGy85pc6Z0okHgrRDk ED+g== X-Forwarded-Encrypted: i=1; AKwUvBzRuaiiw57pJ2aXAaSjMwC/urgN1KzDE9Qp+e6Q65fxWgXDRYS3Dx+v2eQfGIdjaGKINBW4NwC2wY0=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ8IRja5nWGmBV379AQKN+vZudBrAHMif05FTMZNFCYnGQUyYkv 8X0P/Wf/d/Qcmwb3FXK8/AS1NnNfsjVwAlO8vUtB4PP5N8j74huw0M2aMGBNH7eTqQ== X-Gm-Gg: AYBFou1uXPA7MyYCX3aR44/BSQ39wq+DGFEtF4tm5eRQdG377GxqeT/qdlk41PQYQUF 45KsywRm0GK66Pz+NKykKe3m2RN2o89qHFhg8CAUFADnT7nMlbGF5ZrAjS+IEdN9SRVIsFkdbMI Ud0U+YMOpqT7AsGxsutq0qkURJKL8Y3Bqu4rMlTD3TEsMqf+VXK1p/LAXyB929eHtIMtgbY6JyN nzVHrf6wUvw4g9FdwdrI15/qThBI1oVg5mj0NWN246FZsyKlc4gh3CcLOEJbidy5ZTlF/V59I8C ofks/lGVgaP+JNVMzgRToT08k59lEVPBr5/O+MXqNU5vc8E4kJwMTD3VCE5uL75ufrVDt2l2Nem ibKrUYhu77JBTU/QRGAONi4HLRQcE1//xgjZmnO4MuF/v/UDEdSen0ORLSNZpnb9t9m0wUz6CMD pf8+IX9Tl7C0dlOuw9OI49XGDQODrXOvMkxfgr7fUgUqYFJgbRmh8LA62dJMr4AT/ZyhUvZ460s KanXbhbjbE9tXH2ATLWz75PRW+O9KoQz2lw08V0B8ZNT2lUQNVJZ8B/lLmyi7rgTZPIylnOi3tB Ue3XEaPoVEzUqQL7fua8SwQDKsQ5oQwngJSLaeg6VS1c X-Received: by 2002:a05:6000:29d6:b0:48d:ef0e:b791 with SMTP id ffacd0b85a97d-48e3eb9c106mr12760447f8f.54.1793098306321; Tue, 27 Oct 2026 03:51:46 -0700 (PDT) Message-ID: <19979fff-0554-4ec8-969b-6fe50606b1b1@suse.com> Date: Tue, 27 Oct 2026 11:51:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/bzimage: Check that the payload lies within the image To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261020214825.3655848-1-stefano.stabellini@amd.com> <20261026221008.1143527-1-stefano.stabellini@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: <20261026221008.1143527-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1793098306-BEC61757-C3420459/10/78276251493 X-purgate-type: spam X-purgate-size: 1893 On 26.10.2026 23:10, Stefano Stabellini wrote: > bzimage_check() doesn't validate setup_sects, payload_offset or > payload_length against the image size. A truncated or malformed bzImage > therefore makes bzimage_headroom() and bzimage_parse() read beyond the > end of the boot module, which shows up as a fatal page fault, a bogus > headroom, or a decompression failure, rather than as a bad image. > > Reject such a header up front. bzimage_parse() passes bzimage_check() a > length which includes the decompression headroom in front of the image, > so subtract it to check against the image alone. > > Signed-off-by: Stefano Stabellini > --- > Changes in v2: > - drop the UL suffix: setup_sects is 8 bits wide, so the multiplication > cannot overflow, and the offset is now computed the same way as where > bzimage_headroom() and bzimage_parse() use it Upon looking again, I think this may have been a mistake: > @@ -65,6 +67,15 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) > hdr->version >> 8, hdr->version & 0xff); > return -EINVAL; > } > + > + payload_start = (hdr->setup_sects + 1) * 512 + hdr->payload_offset; The multiplication can't overflow, but the addition can. Question is what the behavior should be in that case: Adding back the UL suffix would allow payload_start to go beyond 4Gb, but that may not be what is intended. The alternative would be to check for overflow in the calculation (easiest by way of using __builtin_add_overflow(), yet then needing adjustment when backporting to 4.20). > + if ( payload_start > len || hdr->payload_length > len - payload_start ) > + { > + printk("bzImage payload %#x@%#lx past the image size (%#lx)\n", As we prefer messages to be terse, may I suggest to also drop "the"? Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 11:03:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 11:03:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462055.1673100 (Exim 4.92) (envelope-from ) id 1xLexU-0004S1-9w; Tue, 27 Oct 2026 11:03:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462055.1673100; Tue, 27 Oct 2026 11:03: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 1xLexU-0004Ru-6w; Tue, 27 Oct 2026 11:03:12 +0000 Received: by outflank-mailman (input) for mailman id 1462055; Tue, 27 Oct 2026 11:03:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLexT-0004Ro-0j for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:03:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLexS-002Fnu-2c for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 12:03:10 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae084ea-2eae-0a2a0a5409dd-0a2a4507a010-18 for ; Tue, 27 Oct 2026 12:03:10 +0100 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 6ae084ed-b4ea-0a2a45070019-b9ff1c2296ab-3 for ; Tue, 27 Oct 2026 12:03:09 +0100 Received: from mail2.vates.fr [37.26.189.201] (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a17d072ce5000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 27 Oct 2026 11:03:04 +0000 Received: from leducb.tail4c4a28.ts.net (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 0EE89820E6; Tue, 27 Oct 2026 12:03:02 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=GHrn8JzqfFdS1QWuyOv4h1sCqJkl/0Qh3n1D3SlFHn4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=DuAbWu84EzFl+3SvvojSeQizm7z3o5l9dpM1PhYv0zH2LQZtHWH8adQFvp6t7boQou9GqPWLD ogorbPoHVyvipk6lKvTJ+dYZj0dVQJ0F8YLDVo7jmdhw1tEfem1li97Y6K2OHx89NezYQ4ryX4o pW599xGtKAqZM2leVDeFpXRfrgoZjOcOH19ZgwEoOTTjx5TeMlx2amaidVPAMwzAmnArO1cKjxb Wy8lR6tVeuzRaugqPiFfUKdp/BXBnI4Nd2YFIc03dmdhcBEtyAO3oRpK+ScKx0nSklrwwobVfwX Mq9kTijoVKFZKarhRqu8WCP/wmlRhwIhylAmjQfI2TDg== X-Zone-Loop: 7fbe0b3f88b2d1d113de88f0d9c6065b25976a4640c7 x-campaign-type: default x-transaction-id: f875c0f3-3859-4a1f-9d78-49d4959c9a9f x-swg-uid: 01-725ba01c-96cf-4410-8975-d67cb5ee57a3 X-Mailer: Sweego Message-ID: <1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f@vates.tech> x-swg-bid: 1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v9 0/1] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Tue, 27 Oct 2026 12:03:00 +0100 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=1793098626; l=5837; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=fbE0TlemhAO0yNoNm9JL114Ej6kVAOZ1i304EUZ6HsM=; b=8oyt/FIGYqiwdbm3VcEpcxzZhp9IF+M89dOoiAonYbsMs5oBsC2LHqyqh1h/ws6UX60IgxBKo KRmfNPXKRGXAJyDhj6xDI6Vh/Z1lbNSjMfEqPZKZrp2aarT0c0DyIyU 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: 1793098982266 X-purgate-ID: tlsNG-ef75cf/1793098990-A46CAAE4-E0531856/0/0 X-purgate-type: clean X-purgate-size: 5839 This series introduces bug 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: Probe the A/D update scheme if the DT advertises neither Svade nor Svadu Test CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2993878414 --- Changes since v8: - Drop patches merged upstream: 999c2ca1ab ("xen/riscv: use pte_is_valid() in pte_is_mapping()") 8e34f567ef ("xen/riscv: fix A/D bits in Xen's page-table mappings") 73b802624a ("xen/riscv: look up the exception table for any trap taken in Xen context") 8a9a4bcd7c ("xen/riscv: rework the A/D bits comment in p2m_set_pte_flags()") - Probe through a read-only alias of the Xen image and check the A bit, as A being set by a speculative access still implies Svadu. - Link to v8: https://patch.msgid.link/1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech --- Changes since v7: - Replace the panic when the DTS advertises neither Svade nor Svadu with a probe of the A/D update scheme in that case only, recording the probed extension so that such device trees can be used as-is. The device tree is trusted otherwise, as discussed with Jan (patch 4). - Add patch 3, so that the store page fault raised by the probe on Svade hardware is fixed up. - Move the p2m_set_pte_flags() comment rework last (patch 5). - Collect trailers: A-by on patches 1 and 2, T-by on patch 2 and R-by on patch 5. - Link to v7: https://patch.msgid.link/1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech --- Changes since v6: - Drop the boot time probe of the A/D update scheme and trust the device tree. Xen now panics when the DTS advertises neither Svade nor Svadu (patch 3). - Patch 4 no longer changes when A/D are preset, it only reworks the comment, since patch 3 guarantees the DTS advertises the scheme in effect. - Reorder the series so the already reviewed patches come first. - Patch 2: add a second Fixes tag for arch_pmap_map(). - Patch 1: rebase, as the reorder changed its context. - Link to v6: https://patch.msgid.link/1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech --- Changes since v5: - Replace "xen/riscv: always preset A/D bits in G-stage PTEs" with a boot time probe of the A/D update scheme (patch 1). It checks the result against the Svade/Svadu DT binding and records the probed scheme when the DT advertises neither, instead of trusting the DT alone. - Split the p2m_set_pte_flags() comment rework out into its own patch (patch 2). - Patches 3 and 4 unchanged and are waiting to be merged. - Link to v5: https://patch.msgid.link/1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech --- Changes since v4: - Drop patches merged upstream: ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"") - Collect trailers. - Rebase patches on top of staging. - Link to v4: https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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 --- Baptiste Le Duc (1): xen/riscv: probe the A/D update scheme if the DT advertises neither xen/arch/riscv/cpufeature.c | 65 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 ++++--- 2 files changed, 72 insertions(+), 6 deletions(-) --- base-commit: b07838dc463c18f9ca78806d0f05164b02d1cd14 change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Oct 27 11:05:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 11:05:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462061.1673110 (Exim 4.92) (envelope-from ) id 1xLezp-0004yA-Ku; Tue, 27 Oct 2026 11:05:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462061.1673110; Tue, 27 Oct 2026 11:05: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 1xLezp-0004y3-IG; Tue, 27 Oct 2026 11:05:37 +0000 Received: by outflank-mailman (input) for mailman id 1462061; Tue, 27 Oct 2026 11:05:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLezo-0004xu-Cf for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:05:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLezn-003Juk-Hs for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 12:05:35 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae08575-e002-0a2a0a5209dd-0a2a4505c590-40 for ; Tue, 27 Oct 2026 12:05:35 +0100 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 6ae0857f-4cb1-0a2a45050019-b9ff1c128f69-3 for ; Tue, 27 Oct 2026 12:05:35 +0100 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 1a17d0971ae000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 27 Oct 2026 11:05:33 +0000 Received: from leducb.tail4c4a28.ts.net (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 3430D820E6; Tue, 27 Oct 2026 12:05:32 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=PT15VaLPQa1+M2sgojHYFV8k1ZQ3KNrlXSntnylr0co=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Hl56DOaxPaLsHEs2901dQzl3LrJz2zOAEqXpVUxMcjGKtnSqcncCj8hFA2tw8vbttUIGTGQG+ PkYdd8tISwkoz0xpLE8SU1v9zE3uIyAypebgoCc5y2AcY+MgNPX1nKpSqfFo2rr4qbY9LfCToeH 6OuuYPeum/loLNis3eGzkJNr0/oPdhd1DX7rv0ACOlBPLOmSlWjxhnTDD3XiAp6uBTxSpCcbMek X1PH77dMOrhEGOq4CZg6+p69+06wjQYp4mymsNUjdl7zUWsZIU5oZK3/xAtyqMP5nf5+s08sJpk WKdoHW6R/G+UhQUGgG/osIMW5Li52COuJy96Ol6UBIvw== X-Zone-Loop: 3fa9f7167ab24b9b29b2dc641988fc4d8670c5d0c408 x-campaign-type: default x-transaction-id: 02f24144-540c-4a34-93d2-fc3e9f2336b8 x-swg-uid: 01-3cdc8bb9-c379-4ea0-98cb-6f380d6796df X-Mailer: Sweego Message-ID: <1793099133.8631fc262581453bbf619ec5b2062170.1a17d0971ae000f79f@vates.tech> x-swg-bid: 1793099133.8631fc262581453bbf619ec5b2062170.1a17d0971ae000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v9 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither Date: Tue, 27 Oct 2026 12:05:23 +0100 In-Reply-To: <1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f@vates.tech> References: <1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793098626; l=7517; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=3rZ1dIdVPL3WhgcAMJzO96FO9XwGlFTCRP5G1QD7gkI=; b=DymiJQfxJ1dOhupSWIT8D5CQ7jK4bhwZsekri3dkcDWFXp6vI5wcK3E2Au5+RTDWghmkqGwYg YKeyHqcapngCQ6xGnMu6LdbFwpRo1m493+00+GAU9sX4BCr3lq/M4LY 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: 1793099132416 X-purgate-ID: tlsNG-c201ff/1793099135-F4EA12A1-1882050B/0/0 X-purgate-type: clean X-purgate-size: 7519 p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. The privileged spec allows exactly two schemes for updating the PTE A and D bits: hardware sets them on access and on write, or accessing a page whose A and/or D bit is clear raises a page fault so that software can set them (ratified as Svade). Every implementation uses one of them, but platforms designed before Svade and Svadu were ratified, such as the HiFive Premier P550, may advertise neither. Trust the device tree when it advertises Svade and/or Svadu, as for any other extension. When it advertises neither, probe the scheme in effect and record the matching extension in riscv_isa, so that such device trees can be used as-is, and warn naming the extension to add to "riscv,isa". Introduce probe_hw_ad_update(): alias the first page of the Xen image read-only through the FIX_MISC fixmap slot with its A and D bits clear, then load from it under an exception table fixup. Hardware updating is in effect if the load completes and the A bit is then set. The probe fails otherwise, whether the load faults or completes leaving the A bit clear. The A bit being set by a speculative access still implies Svadu, as Svade only allows A to be set by software. Add Svadu to the known ISA extensions so it can be told apart from Svade. The comment above the enum asks for new extensions to go at the bottom to avoid shuffling, a leftover from Linux where the IDs were macros with explicit values. Nothing depends on the enum values, so have the comment say that multi-letter extensions follow the order of riscv_isa_ext[]. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v8: - probe through a read-only alias of the Xen image and check the A bit, as A being set by a speculative access still implies Svadu. --- Changes since v7: - probe the A/D update scheme when the device tree advertises neither Svade nor Svadu and record the probed extension, instead of panicking. - drop Suggested-by. - update the patch's title/body accordingly. --- Changes since v6: - drop the probe and trust the device tree, only panic when it advertises neither Svade nor Svadu. - update the patch's title/body accordingly. - put svadu between svade and svpbmt in riscv_isa_ext_id. - rewrite the enum riscv_isa_ext_id comment. --- Changes since v5: - new patch, probe the A/D bits update scheme instead of trusting the device tree alone. --- xen/arch/riscv/cpufeature.c | 65 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 ++++--- 2 files changed, 72 insertions(+), 6 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 3d5bbd2228..a19244493a 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -20,6 +20,7 @@ #include #include +#include #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -200,6 +201,7 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { RISCV_ISA_EXT_ENTRY(ssaia, ANY), RISCV_ISA_EXT_ENTRY(sstc, NONE), RISCV_ISA_EXT_ENTRY(svade, NONE), + RISCV_ISA_EXT_ENTRY(svadu, NONE), RISCV_ISA_EXT_ENTRY(svpbmt, NONE), }; @@ -630,6 +632,47 @@ const char *get_guest_isa_str(void) return guest_isa_str; } +/* + * Probe whether hardware updates the PTE A/D bits by reading through an alias + * mapping whose A and D bits are clear. Observing A set, even by a speculative + * access, implies Svadu, as Svade only allows A to be set by software. + * + * Under Svade, the read raises a page fault instead, so use the extable to + * handle it. + */ +static bool __init probe_hw_ad_update(void) +{ + vaddr_t va = FIXMAP_ADDR(FIX_MISC); + pte_t *entry = &xen_fixmap[FIX_MISC]; + bool a_set = false; + + ASSERT(!pte_is_valid(*entry)); + + /* + * Any mapped page will do, as the alias is read-only, so alias the first + * page of the Xen image, with A and D clear. + */ + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(_start)), + PTE_VALID | PTE_READABLE)); + flush_tlb_one_local(va); + + asm_inline goto ( + "1: lw zero, 0(%[va])\n" + ASM_EXTABLE(1b, %l[out]) + : + : [va] "r" (va) + : "memory" + : out ); + + a_set = read_pte(entry).pte & PTE_ACCESSED; + + out: + write_pte(entry, (pte_t){}); + flush_tlb_one_local(va); + + return a_set; +} + void __init riscv_fill_hwcap(void) { unsigned int i; @@ -674,6 +717,28 @@ void __init riscv_fill_hwcap(void) "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " "wire up this platform's pause equivalent in cpu_relax()\n"); + /* + * The privileged spec allows exactly two schemes for updating the PTE A + * and D bits: + * 1) hardware sets them on access and on write; + * 2) accessing a page whose A and/or D bit is clear raises a page fault, + * so that software can set them (ratified as Svade). + * + * Every implementation uses one of them, but may predate the extensions + * and advertise neither. In that case, trust the hardware probe. + */ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) + { + bool hw_update = probe_hw_ad_update(); + + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, + riscv_isa); + printk(XENLOG_WARNING + "Device tree advertises neither Svade nor Svadu, probed %s: add it to \"riscv,isa\"\n", + hw_update ? "svadu" : "svade"); + } + 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 2973eb13a5..b0a23be18e 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -8,13 +8,13 @@ #include /* - * These macros represent the logical IDs of each multi-letter RISC-V ISA - * extension and are used in the ISA bitmap. The logical IDs start from - * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single - * letter extensions and are used in enum riscv_isa_ext_id. + * Logical IDs of RISC-V ISA extensions, used as bit positions in the ISA + * bitmap. * - * New extensions should just be added to the bottom, rather than added - * alphabetically, in order to avoid unnecessary shuffling. + * Single-letter extensions use IDs below RISCV_ISA_EXT_BASE and are sorted + * alphabetically. Multi-letter extensions start from RISCV_ISA_EXT_BASE and + * follow the same order as riscv_isa_ext[] (see the ordering rules described + * above it). */ #define RISCV_ISA_EXT_BASE 26 @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_ssaia, RISCV_ISA_EXT_sstc, RISCV_ISA_EXT_svade, + RISCV_ISA_EXT_svadu, RISCV_ISA_EXT_svpbmt, RISCV_ISA_EXT_MAX }; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 11:35:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 11:35:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462080.1673120 (Exim 4.92) (envelope-from ) id 1xLfSt-0001Wo-Vp; Tue, 27 Oct 2026 11:35:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462080.1673120; Tue, 27 Oct 2026 11: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 1xLfSt-0001Wh-SC; Tue, 27 Oct 2026 11:35:39 +0000 Received: by outflank-mailman (input) for mailman id 1462080; Tue, 27 Oct 2026 11:35:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLfSs-0001Wb-Um for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:35:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLfSs-003QG7-4T for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 12:35:38 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae08c7f-2eae-0a2a0a5409dd-0a2a4507e4ea-48 for ; Tue, 27 Oct 2026 12:35:37 +0100 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae08c89-b4ea-0a2a45070019-d155dd33cd13-3 for ; Tue, 27 Oct 2026 12:35:37 +0100 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48dfc0421d9so3406197f8f.1 for ; Tue, 27 Oct 2026 04: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-48e3ebc3c5bsm22992317f8f.9.2026.10.27.04.35.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 04: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=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=1793100937; x=1793705737; 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=IcCI4frMu7p5QnsKC66MEafUJj1B+BfRNflTPN5BE34=; b=SY1dW+jd6ePHLEzXAsRl7IwPh1lzPvRRvD5GWy0DbIAy0r4dLWNyq8um2YCApaeGtI 1mSmk7c27zOQiaJLPYSXwEJWIPBp8MXpwGe7g3iDwt9HcPbywRhW8j+kecy0Wi64IYIm c38CBCTT5BvJMB+pPJTG0nVaUlmPXQ9RSMo1Ge8wPPi5PBmHGD31Kdk5ZrJaFnioDQZG ONABbjZZUgIHD4bjzAiWGp0XQMq79/hv/w6cCukUuMG7mWqrvEEvvyVgXAaEyJ5jAfj4 cG+PHgjrLNiJXmOQFkU9eCuIRPkS3KyGk1hgAUzTxAST8vzf5Pm5QilhMiDTWjqNw72M 913g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793100937; x=1793705737; 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=IcCI4frMu7p5QnsKC66MEafUJj1B+BfRNflTPN5BE34=; b=UzG6n8AajmLNJLU1SYx7EeYod1rB4GpU/NIplEK2REjv10jKiYY314llZY8VPJorGf fh9XyIlgLQpvcNJwg58kskTiDE25433y6HILfMp5l2SACJuNBDSnXV0zfha99ythrjy+ dG8l7DKkhRAV26h478RepINCjygqbnYodxCzDIzftKlxL07hmdoowwIdrnzDvAb4dxDd eaYJX0gw3ase8pY12Zl9j40HhUSkO++nc2JXXKWks18ZTgrBxguC7fKGACqndYNNF/ct 30L45/uQE36LrOtVAbS5LzlnWx0rMEi6RjXHbtqnWXs1vz5sZSYa5JXWFmzmLsD9N6Vo al+A== X-Forwarded-Encrypted: i=1; AKwUvBxI4BoIG8G76CqhwAaltK9+va2XkKdRnaUu411VkRuviVrEM1JcQ5tnJ9XyBuNgd5mnONIeA2wrUk0=@lists.xenproject.org X-Gm-Message-State: AFq9FYJPdsjgEZ4+aDxZ3RVly2Aa3IWcYdODqWu1w7CfwGXAiFqjinpi u0ZreFhN+AALMn4XEDddeKM61djOdyURzwrAKCMssrNkkkxTK2/Oam0oKjwkmlwWPg== X-Gm-Gg: AYBFou0tSSCC6A3iOGgLJAxKpWr8O6sNKlXi54wOP5/Ag2ogKRvCWRTDu8ja20lAekJ 5UxR161wY8PjAU7/0PzN+L69vE/jsBnYqQ9bZ2KSk0WLT8y3mOIx4d2HSLYLeC3L3ivSTDVPrEu Gfthel/1xGEEan+JywNrK9pkT7EejspwKTnPC8kZj96rfPrEl2bQFrWBZJRPjj2Hc0mdKpL6sq5 r6HA3UYCIqX90ZolRO5f6lM7/DSJmseWeHiAafuZFcV8MXHoxEwmEbXpGNRtK+1bpMGgnxKNqwN 9nFdrJiMyS+RD2yJFgDTmTdP1PIwQuC7imAOJk50rK020JUnX1+3+Kjld6s3PMu6v+6DNeDImFy Wq5uRT9Epx3Hue4Sbq7EWljTB4UX55uc0QSlXZig+Nst4Z7+mTlzxPyRn4Hkh3JrVsW69bFbXXC bW5eWXlQbz6G0xVfHricwcBjS1qzJ769/BKMflrXAzrxxEo8eOirPvRz6FPeJ8Hd5gHhl2iutfa uMkuLMGPgo2bjb3i+PlpbIKBKrDBUkjZkH/GhuL2hndL1PmWytQpcC0a3b+WloULjk02rwx9xvC ZCgYyO8neJY9FtgECBgmmiIl564kX8VNoY8SLw6SiM0= X-Received: by 2002:a05:6000:26c7:b0:48e:824:f0b9 with SMTP id ffacd0b85a97d-48e3eb945b1mr20069682f8f.45.1793100937013; Tue, 27 Oct 2026 04:35:37 -0700 (PDT) Message-ID: <79b56256-3df6-40b6-9827-d23347b9c6ed@suse.com> Date: Tue, 27 Oct 2026 12:35:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/amd/iommu: record the IOMMU for alias DeviceIDs To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261020221214.3683476-1-stefano.stabellini@amd.com> <20261026235926.2105578-1-stefano.stabellini@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: <20261026235926.2105578-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1793100937-A4ECEAE4-81484B34/10/78276251493 X-purgate-type: spam X-purgate-size: 2825 On 27.10.2026 00:59, Stefano Stabellini wrote: > add_ivrs_mapping_entry() marks an alias DeviceID valid and may give it > an interrupt remapping table, but records the IOMMU only for the device > using the alias. If no IVHD entry names the alias DeviceID itself, > amd_iommu_setup_device_table() passes a NULL IOMMU to > amd_iommu_set_intremap_table(), which dereferences it at boot. Also possibly amd_iommu_alloc_intremap_table(), as it looks. > Record the IOMMU for the alias too, as was done before the interrupt > remapping rework. Nothing relies on it being NULL: the alias is then > handled like any other DeviceID. Its remapping table is freed on > cleanup and dumped by the 'V' key, a device at the alias DeviceID can > be added instead of failing with -ENODEV, and reserved ranges, already > recorded for the alias as well, are reported once under it. A NULL > check at the crash site instead would leave the alias device table > entry without interrupt remapping. What about find_iommu_for_device(), for example? That does check .iommu to be non-NULL, and hence behavior there is being altered by the change. Maybe to the better, but that's not obvious to me. amd_iommu_get_reserved_device_memory() has a similar, related check. > --- a/xen/drivers/passthrough/amd/iommu_acpi.c > +++ b/xen/drivers/passthrough/amd/iommu_acpi.c > @@ -104,6 +104,10 @@ static void __init add_ivrs_mapping_entry( > > /* Assign IOMMU hardware. */ > ivrs_mappings[bdf].iommu = iommu; > + > + /* Requests using the alias go through the same IOMMU. */ > + if ( !ivrs_mappings[alias_id].iommu ) > + ivrs_mappings[alias_id].iommu = iommu; Comment and code are out of sync as long as the assignment is conditional. Question is which way this needs adjusting, and hence why you added the conditional in the first place. Which extends to other aspects of this function, when called with an alias_id (or bdf) which was previously seen: Should we reject such (early in the function)? Should later data override earlier one? Perhaps what we want here is /* Requests using the alias go through the same IOMMU. */ if ( ivrs_mappings[alias_id].iommu ) ASSERT(ivrs_mappings[alias_id].iommu == iommu); ivrs_mappings[alias_id].iommu = iommu; ? Furthermore, if there's an issue with .iommu, why would there not be the same issue with the other fields set by this function? (Else if some of the fields can be relied upon only when ivrs_mappings[n].dte_requestor_id == n, then I think this would need writing down somewhere.) See e.g. amd_iommu_setup_domain_device(): It uses get_dma_requestor_id() to determine DTE and ivrs_dev, and passes that ivrs_dev to use_ats(). If this is an alias, ivrs_dev->block_ats won't be properly set. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 11:49:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 11:49:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462100.1673175 (Exim 4.92) (envelope-from ) id 1xLfg5-000404-Gx; Tue, 27 Oct 2026 11:49:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462100.1673175; Tue, 27 Oct 2026 11:49: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 1xLfg5-0003zx-E1; Tue, 27 Oct 2026 11:49:17 +0000 Received: by outflank-mailman (input) for mailman id 1462100; Tue, 27 Oct 2026 11:49:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLfg4-0003zr-QU for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 11:49:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLfg4-007ayf-08 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 12:49:16 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae08fae-e002-0a2a0a5209dd-0a2a4509901a-28 for ; Tue, 27 Oct 2026 12:49:15 +0100 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae08fbb-be1a-0a2a45090019-d155802ba95e-3 for ; Tue, 27 Oct 2026 12:49:15 +0100 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a2072b9832so5233975e9.1 for ; Tue, 27 Oct 2026 04:49: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-4a35a59d238sm250462765e9.14.2026.10.27.04.49.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 04:49: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=1793101755; x=1793706555; 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=KJsryMwUXNjp1wqMYv8rG+hvdO+kdmsn+noLtH+2PCs=; b=gR9dlFIFbFI8O/hDGNDA2rnTS+ikNyxvxsDafWpkSHQYUszzSdlXXVlKpNAEyL2kKr s975N7htqpuRp4fF8OBrl5Onzpn6+IwgE8s3I1q5RjWJTCayCkWFbCUyN33fDsJfIhW7 jox1dE+VfVMcgH1uOdtuanNLeG9g93byKWA3/WZyh/5TvKL53Exm98gdyhaa3Qq2AE24 ExVQF/Fu8BrdST2vWegFWkBMPgBo9EagIbwf4ZLuCzrR92xcYE+AWylbgYKymlbGH97K 3qoY+Nkp3nD7JbdBxfUzYur9bpqCJ92NrrtrxlOkLj5+KRI6PJUNcuM4EaGsmxY0v+D6 LV/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793101755; x=1793706555; 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=KJsryMwUXNjp1wqMYv8rG+hvdO+kdmsn+noLtH+2PCs=; b=k/8Pi1CNji9Kfg9eKnspr5QynSB2nJTEnUxs+LjV2VGLlUwFQUa7NrvSnDwRhIv2lN rED+YtE+pqEGTxQQuFGs40oZIjz9jW6p5k07F0oXU6EI577js89AQcGl6Hk0lYF4E9Sh ipjx+MMKzZl/X8MRH9zLh7c/IRClxely9g9UNAsKbmTfuQg7N4o15LIi/ABtiKcb1mYa GfpYGQSTtxK2VKHnEVNBHizsIIBWGqpvkr7v/E7hjy4cvWsiJcUhPqGWUNruWtvwZWAd 0PYqUF+/Oy/lvagYhKqB0c+Yn2bTsc528xv6VAjU+nwtVwWsH561DbjFD40GjjkGnwZD QQKg== X-Forwarded-Encrypted: i=1; AKwUvByQX8KXVIiSDk0jRcks6LwNysdlMAhkWQN23tlv8QcH4y/0lOUev8A09OsfHiJvclkunrMoP7Zn0Hw=@lists.xenproject.org X-Gm-Message-State: AFq9FYKi4HQQBbWY4fisjHU+rD/nIcj/1MTL0lf5chRGs5+y952BPN3S Fi/vlgFnh+BPHhQ24yy9mU6+6MkiFNRkM2RNOMEyObT0zvRNAaSfXyrMQYvyJBmfnb0b6kKVn9T i5Ftm7w== X-Gm-Gg: AYBFou3bRddtELDK3Mcxamry8L9qXWr3HYSc+R7bieDaJPCmwqiJECiB9SivJ9Goeu8 TjZvulsGRW/a9Iym/PHVkeaD2KTXuFFsMbI+t8c0kJuc/A3jLKz8YVU7uIkIIYEFILeKy1eAvOa Ndcohel2xdS5HX9Hrqww9C2L/z9PYx8vtzu0TtP7JZU6Y2BYeqDbxtmzt3vHP5DC6E4EWmKjlLR jW0UmJd4qNK0aMW4DrZLcnoVRTArJKE7whzqXLdKzwkctkyIy8F+4/1IWF7FIxwa+ucjSkl+icb VDEv/KD8g+IKCq/3OUF3thqr5Nw0hT141V4pJuh4Qm6JH8jmp/TdjIxVASBPVrgnkBbKTW8a/8y BiXvS3lDlQTQhJSMd3Mc7Z/mkUMt0FmLF8Nq6mtxvQKLCXZFWwJ8VbqNbGaekTALUd3bA/JuUrp 8S3G3xgBm7eXY1Q91qDh0bJOj03IzFGv6eZ822qJWy3zGmXN188kM3T65HhkkU5gM5aXeyId6hD aeXxDSsWj+LrCC4kq2fsyY151z/VR9MYRQUYVGSgM1lYd6jntb9a/ZHt1HYAWCQoCDZikTkq1iz mxx6yNR/cZvyNq2QQNatYx7hVMRJ5rOvWAzL2nwC21dv X-Received: by 2002:a05:600c:a117:b0:4a1:c6f5:2450 with SMTP id 5b1f17b1804b1-4a7c1f63e7amr36279485e9.17.1793101755325; Tue, 27 Oct 2026 04:49:15 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 12:49:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mcheck: keep the banks past the end of the CMCI map polled To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, jason.andryuk@amd.com, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20261027001315.2614976-1-stefano.stabellini@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: <20261027001315.2614976-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1793101755-3ACDF034-940A5F29/10/78276251493 X-purgate-type: spam X-purgate-size: 848 On 27.10.2026 01:13, Stefano Stabellini wrote: > bitmap_copy() copies whole words, so in set_poll_bankmask() it clears > the banks past the end of the CMCI map that bitmap_fill() had just set, > leaving them neither polled nor reported by CMCI. Set those bits after > the copy instead. May I suggest "bitmap_copy() copies whole words, so in set_poll_bankmask() it may clear banks past the end of the CMCI map that bitmap_fill() may just have set, leaving them neither polled nor reported by CMCI. Set those bits after the copy instead." > Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU") > Signed-off-by: Stefano Stabellini > Reviewed-by: Jason Andryuk > Acked-by: Roger Pau Monné No further tags needed, as it looks. Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 12:21:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 12:21:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462120.1673185 (Exim 4.92) (envelope-from ) id 1xLgAu-0001aL-0y; Tue, 27 Oct 2026 12:21:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462120.1673185; Tue, 27 Oct 2026 12:21: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 1xLgAt-0001aD-S8; Tue, 27 Oct 2026 12:21:07 +0000 Received: by outflank-mailman (input) for mailman id 1462120; Tue, 27 Oct 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 1xLgAr-0001Zr-TO for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 12:21:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLgAr-00HDsD-5q for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 13:21:05 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae09726-bab6-0a2a0a5309dd-0a2a450ba964-28 for ; Tue, 27 Oct 2026 13:21:04 +0100 Received: from [209.85.216.44] (helo=mail-pj1-f44.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae095c5-b7e8-0a2a450b0019-d155d82ce0aa-3 for ; Tue, 27 Oct 2026 13:15:03 +0100 Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-3856d6fbcb3so2680750a91.2 for ; Tue, 27 Oct 2026 05:15:02 -0700 (PDT) Received: from yhlee-960QFG.Davolink ([2406:5900:1044:110c:df24:cbdb:a2dc:d464]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cd8cc9073c2sm2915176a12.0.2026.10.27.05.14.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2026 05: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=20251104 header.d=isslab-korea-ac-kr.20251104.gappssmtp.com header.i="@isslab-korea-ac-kr.20251104.gappssmtp.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=isslab-korea-ac-kr.20251104.gappssmtp.com; s=20251104; t=1793103301; x=1793708101; 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=1s6Zqp4u3sfnKK/Y6nM0BOKcsidnRWEc87L5yFDAZSw=; b=ABxqKfrZY06t/5Fy3Bwkiip6n0lMZ6HK/uNfu/9y4iA53m3phbZU9JOnO99tCs+ylz wTFOWTcmsynVUlAa8GYE4ahLm3Kqd6uhw+3YQGCOv0iKhNERHKib3ppaYFghJRVGgPj8 h1ZE0YT6RD9mUBV+Z/A/6L6mfmbNMfgSnIgjat3m4Y2GzpZR/NW/rayub0z+LjlsewGY GRznsIqmCi3wKZSInbh0/y4bTDJCviLf62iEqqU76nGGGAzf4KmIRlMLnHV+yrmu7SMe WLqTnw3SRqnfiD1W6xzqojhYnWUkkEr2cUYpn3d46v0VOcD/+wGuXZ/gizZUaAJrIFDN AU6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793103301; x=1793708101; 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=1s6Zqp4u3sfnKK/Y6nM0BOKcsidnRWEc87L5yFDAZSw=; b=Zys2A3QrMtdBdRNXcMsTXoDODMVIgeLBshZFQJwIDBazRjklEQFttb3TZJto+lZf+y 6L8pubi0QIjovU8RaXqDCRzOttoNnr6Xl9w4v8FIMAmkn7j5Nci2Pf/cgnXvKDFDjD57 W3tDrFDaZFD3vCi+gLafIJmS5aqeoK7tfJXIfhRH9PmeFX8mXfI6+qG28zD3UAspMghF uFWu0BLmkMGgQP8lYdId+VqNPjhzALHOcCGcua7cuoBty7VLvL7t4X8xMmAuVgBO9Rw7 pdZ6m0LiWFOOx6lM+Ab+X96ASsbkyYO2xXTM7VKwuFRIi4kmrW5W2df9ywkrygT8zwtF wUzg== X-Forwarded-Encrypted: i=1; AKwUvBzY7JvtTsNeNqZdKwOxoZ2hxbxchSz8G7pnOaAMWkBhBkK2mzZrnVI28eCVNa/1kMNhx/Epz7XHEhs=@lists.xenproject.org X-Gm-Message-State: AFq9FYLSw9iAxRKlgGGqbIk4avmyqY7zK8ZJg0OYOsHHT+lfdtP4gf+c /M+MBZ90rXrPGloUZXB0rR/e5ZSKhDY5298cWwCC7w/QU3yQkcG1elmu+mPKEyIG6tE= X-Gm-Gg: AYBFou0/WareucmOAuRq2k5EGfj4yi6CrdGwIZaf3MNscqrVx+Fn4A083qrwOt0uzWt d7Evggl4RpOCnFD7/T6QNy6Z3KMw1FGRhCTq4mVnWnjsKyDHribwIMNuyPGPcqnR8l0reBbdFLs mEETu8b9x2Hzw8k82c0YrmMBoCbfon0UUE8vkFdqTz/DaN1SqGLtTWuYa0oIhmGS5OzvK0lDemu FTQEcd4jnfUUFoUSUb9XBLRTeM/nyWg6dcVKvkH5kurN+MmElLGpXvqm58D2XHNBmjyJJqglxHS rkITUJo5RGklYgTmxpraupH5p3FjklSMV1gGo9BcLUrqkEe7W/4wDzRUSn+DbpFg5DxEY9NPn2K eKduXlhr9P94NjYa72mly+JLrRtPMJ/rvtG7vnRnHNle9+xU0HoVaADhvfQHcklSOqugIN/ttPH mNmIMQe51b6r+cI0JufE4iPLjw6R0tJ3dvrt6x/5/LAeuntZGNPzvBD3pl1RY1Yt1bCS7HwpSw+ P8lKxNe7Wli5ArSTZR2ge3f57FbI+JUyB691eHZAHRv9eccA1xxBifnOS7vBwllModEcrQ0cOIy y4W7I020jGmVRiSYRGdOzagvzydqu5+O2nVHiDrQfgm7+lnYF0zl+3rcAAc3ik9hbA== X-Received: by 2002:a17:90b:2542:b0:3ac:adce:60a8 with SMTP id 98e67ed59e1d1-3ade9b2cf27mr7977855a91.5.1793103301318; Tue, 27 Oct 2026 05:15:01 -0700 (PDT) From: Yehyeong Lee To: Wei Liu , Paul Durrant Cc: Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , xen-devel@lists.xenproject.org, netdev@vger.kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org, Yehyeong Lee Subject: [PATCH] xen-netback: wait for RCU readers before freeing queues on error Date: Tue, 27 Oct 2026 21:14:38 +0900 Message-ID: <20261027121438.1266207-1-yhlee@isslab.korea.ac.kr> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793103303-1B4D39EA-D2B392F4/13/0 X-purgate-type: clean X-purgate-size: 6308 The connect() error path frees vif->queues without first waiting for RCU readers, unlike backend_disconnect() which publishes num_queues = 0, calls synchronize_net() and only then frees the array. The net device is registered in xenvif_alloc() during probe, so it is already live when connect() runs. xenvif_get_stats64() and xenvif_get_ethtool_stats() read it through the usual stats paths, taking rcu_read_lock(), sampling num_queues with READ_ONCE() and then dereferencing vif->queues[i]. A guest can drive connect() into the error path by handing the backend a bad ring reference or event channel for one of its queues, which makes connect_data_rings() fail and connect() jump to err: with num_queues still counting the queues already set up. The error path calls vfree(vif->queues) without a preceding synchronize_net(), so a reader that has already sampled a non-zero num_queues and loaded the vif->queues pointer goes on to dereference the freed vmalloc array. KASAN catches the read of the freed queue array in xenvif_get_stats() while a guest repeatedly forces the error path and dom0 reads /proc/net/dev. Generic KASAN labels a freed vmalloc region vmalloc-out-of-bounds, since the use-after-free label is reserved for slab and page objects: [ 160.524029] ================================================================== [ 160.527557] BUG: KASAN: vmalloc-out-of-bounds in xenvif_get_stats+0x28f/0x390 [ 160.530848] Read of size 8 at addr ffffc90005de06a8 by task cat/10519 [ 160.533831] [ 160.534844] CPU: 1 UID: 0 PID: 10519 Comm: cat Not tainted 7.3.0-kCTLwide2-15482-g21a7f44fd076-dirty #2 PREEMPT(full) [ 160.534849] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 160.534855] Call Trace: [ 160.534868] [ 160.534870] dump_stack_lvl+0x64/0x80 [ 160.534885] print_report+0xd0/0x630 [ 160.534918] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 160.534933] ? xenvif_get_stats+0x28f/0x390 [ 160.534938] kasan_report+0xce/0x100 [ 160.534943] ? xenvif_get_stats+0x28f/0x390 [ 160.534947] xenvif_get_stats+0x28f/0x390 [ 160.534952] dev_get_stats+0x2db/0xb50 [ 160.534961] ? dev_seq_printf_stats+0x446/0x7b0 [ 160.534979] dev_seq_printf_stats+0x9e/0x7b0 [ 160.534982] ? __pfx_dev_seq_printf_stats+0x10/0x10 [ 160.534987] ? dev_seq_next+0xe0/0x1b0 [ 160.534990] ? __pfx_dev_seq_next+0x10/0x10 [ 160.534993] ? __asan_memcpy+0x3c/0x60 [ 160.534997] dev_seq_show+0xf/0x30 [ 160.535000] seq_read_iter+0x8f3/0x1190 [ 160.535018] ? alloc_pipe_info+0x2c2/0x430 [ 160.535030] seq_read+0x267/0x3d0 [ 160.535033] ? __pfx_seq_read+0x10/0x10 [ 160.535038] ? __pfx_do_mmap+0x10/0x10 [ 160.535054] proc_reg_read+0x1ab/0x270 [ 160.535077] vfs_read+0x177/0xa20 [ 160.535085] ? __pfx_vfs_read+0x10/0x10 [ 160.535089] ? vm_mmap_pgoff+0x24b/0x310 [ 160.535108] ? __pfx_vm_mmap_pgoff+0x10/0x10 [ 160.535116] ? fdget_pos+0x1ca/0x4b0 [ 160.535124] ksys_read+0xf7/0x1c0 [ 160.535128] ? __pfx_ksys_read+0x10/0x10 [ 160.535132] do_syscall_64+0xe2/0x4b0 [ 160.535141] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 160.535149] RIP: 0033:0x463aa1 [ 160.535156] Code: 00 4c 89 d2 4c 89 c6 e9 fd fd ff ff 0f 1f 44 00 00 31 c0 c3 0f 1f 44 00 00 f3 0f 1e fa 80 3d ec 22 1a 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec [ 160.535168] RSP: 002b:00007fff303dbeb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 160.535176] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000463aa1 [ 160.535178] RDX: 0000000000010000 RSI: 00007f9becf9f000 RDI: 0000000000000003 [ 160.535180] RBP: 00007fff303dbee0 R08: ffffffffffffffff R09: 0000000000000000 [ 160.535182] R10: 0000000000000022 R11: 0000000000000246 R12: 00007f9becf9f000 [ 160.535183] R13: 0000000000010000 R14: 0000000000000001 R15: 0000000000000000 [ 160.535186] [ 160.535188] [ 160.636633] The buggy address belongs to a vmalloc virtual mapping [ 160.639416] Memory state around the buggy address: [ 160.641738] ffffc90005de0580: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 [ 160.662534] ffffc90005de0600: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 [ 160.665865] >ffffc90005de0680: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 [ 160.669222] ^ [ 160.671430] ffffc90005de0700: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 [ 160.674771] ffffc90005de0780: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 [ 160.678102] ================================================================== Mirror the teardown that backend_disconnect() already performs. Snapshot num_queues, publish num_queues = 0, call synchronize_net() to wait for in-flight readers, and only then deinit and free the array using the snapshot. Fixes: b17075d5c198 ("xen-netback: fix race condition on XenBus disconnect") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee --- drivers/net/xen-netback/xenbus.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index e020f44ac2c717..d1c9e38cfb8ef2 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -835,10 +835,21 @@ static void connect(struct backend_info *be) return; err: - if (be->vif->num_queues > 0) + if (be->vif->num_queues > 0) { + unsigned int num_queues = be->vif->num_queues; + xenvif_disconnect_data(be->vif); /* Clean up existing queues */ - for (queue_index = 0; queue_index < be->vif->num_queues; ++queue_index) - xenvif_deinit_queue(&be->vif->queues[queue_index]); + + /* + * Mirror backend_disconnect(): publish num_queues == 0 and + * synchronize_net() so RCU stats readers finish before the free. + */ + be->vif->num_queues = 0; + synchronize_net(); + + for (queue_index = 0; queue_index < num_queues; ++queue_index) + xenvif_deinit_queue(&be->vif->queues[queue_index]); + } vfree(be->vif->queues); be->vif->queues = NULL; be->vif->num_queues = 0; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 13:14:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 13:14:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462145.1673194 (Exim 4.92) (envelope-from ) id 1xLh0V-0000fy-OQ; Tue, 27 Oct 2026 13:14:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462145.1673194; Tue, 27 Oct 2026 13: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 1xLh0V-0000fq-L7; Tue, 27 Oct 2026 13:14:27 +0000 Received: by outflank-mailman (input) for mailman id 1462145; Tue, 27 Oct 2026 13:14:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLh0U-0000fk-KR for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 13:14:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLh0T-00HNN6-MY for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:14:25 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0a3b1-bab6-0a2a0a5309dd-0a2a45049b84-0 for ; Tue, 27 Oct 2026 14:14:25 +0100 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0a3b1-b57f-0a2a45040019-d1558031b4ee-3 for ; Tue, 27 Oct 2026 14:14:25 +0100 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a4dc547987so11679715e9.0 for ; Tue, 27 Oct 2026 06: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 5b1f17b1804b1-4a35a59d238sm255249985e9.14.2026.10.27.06.14.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 06: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=1793106865; x=1793711665; 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=rC8YWz43OylJBksbuwH2nBU++iirUvgS87OVq8asVeo=; b=Jr/vB8wB3uMLKuP7wJ82SLL69RrJpZYKDmos1FiW0L6CWAFUHZ1FoYkGsywNWSs+VI XWceDWCHbYPhZIcwsWY6r0QQTB6Qk4whcGbkLTLhrVflw4j7YMDujAQr7JWiLGUGBVY9 PqfG8SgV9kGRy39gjAyrsITUjLGle2H3CyRGN2qOl60+VZ9dKYmwfh14Sna3NI5sI7H+ 8CxRl7l27u2h0NxFW/4b40cYMXM1yzauVJSkJB7U5KP7ZggCgYLW6rQR7UZlGeqpPrZy 5ukKGCsHrTJJFUU/Bu+pQcxH+rp/iCt1qgm7uSqu9VZbDxhrjBDnVnOq7m/5yWJMb0zy 5DHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793106865; x=1793711665; 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=rC8YWz43OylJBksbuwH2nBU++iirUvgS87OVq8asVeo=; b=BK2AOzU1ofzgk7cVwB9Nf9m58Uk3o5cdrW8zxN8bTbpumRTQlFnXvPJtZqkTsszLgi YU8+uVw1jrBUIbP66XMPGNT/o3DfA89L9gVWM861ux7QAjQef2Z47T+DCEOfiXLLJ1xQ 8PRZr643rz59TmplcQgrxnDyXto6TU6XWo7iKs81likO4NrnVU8S5l+ZEdpQp+OkmxzQ +rgHnhcV9dyUTDYnI23HLiMKbOYoV2zSqEKCVArw8GdcmJAMd8zIij+TXnFgHY3HlCzx 3yqhy3TWMhZj+YEuJwtZAnIxrr/1QZS36IdR/CabEdCj+S4R6B7cg9ro6yWshcOyf4dM JbSg== X-Forwarded-Encrypted: i=1; AKwUvBx9UW2dylAv8q4fCu6qMrDqsuBjb07WQKjJGtqZebLL8OjdsFLo2IUYrIPKw4FTDNfsSIdBS8r0pzE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJVnAoDaVc7kXPe3jvkYNrqixnxaEHdFTyGPHOhiNNJCD02Ccvr RUffdb3IWKpRTU5sX9eONybr3jFckEDUf2+YBPmu/qcGkSnM0EZDMt/4frUDoW1jng== X-Gm-Gg: AYBFou2gRRYF2qDTFakY8Ng9Mtgl/gcA4v7Wlw/0NvQRd2292EmEbiOZrWDkyLrJ3TU 4jJl97nsxYzTKjp/T+WH01ZZCWVsuRcXrMABXikdugYWAuY++b7Q0R9amY8SExXFWNmUV37n9Ix TWckLMOcrTAvRdzZzcxz/OAQHFiqEFPQBXO/kPxoElZQCxg6KuJFeo1IgSZNat1fMRi6Ya3jnev j7EDwt0uLt8HRLcuzhSr+GskC4aItKolx7JCvTiZ52SZKAZIK98IxJEvWUf1z5JwYni1raY3c7P yQTnooU3KxWrzyRfsLzYf+xV3AXf2A/Qp08IYZD2woyXu9qh7O348GPYCXzen72EpbGCcrmKrsQ y2clUxjdg4KliOqYeV8mxVVoZB/nH8oN2z+WBBpBtifSDenQuVk7juV11E14KmXrpPxlrPgLkw4 TRU6OUgIIQQzWhBoxbicVJOujk4AFo8RLScC5qis8mdeWgxdpEwqxgD2Gh63/Tzd6w/D5xcz6FI oNdyi5Qxmev6ygwvu7+IuIICKE7SkYLEw68NJak/8d86VP/muZWr0dgihHSytPMgS2TfJ7wKiLf 5SnwCqyeB4C9zvi2/MNWOh91iA+qATuztTtCDOT0UPv1 X-Received: by 2002:a05:600c:8b6d:b0:4a7:669c:c988 with SMTP id 5b1f17b1804b1-4a7669cc9d8mr73308985e9.23.1793106864613; Tue, 27 Oct 2026 06:14:24 -0700 (PDT) Message-ID: <1d1d678b-dbcf-4d4d-be3f-aab973fbe0c6@suse.com> Date: Tue, 27 Oct 2026 14:14:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mce: don't call an unregistered address check To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, xen-devel@lists.xenproject.org References: <20261027004842.18508-1-stefano.stabellini@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: <20261027004842.18508-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1793106865-516D2B50-574D34CD/10/78276251493 X-purgate-type: spam X-purgate-size: 755 On 27.10.2026 01:48, Stefano Stabellini wrote: > Family 0Fh registers no check_addr callback, yet mca_init_bank() and > mc_memerr_dhandler() call it unconditionally. With altcall the NULL > pointer is patched to ud2, so on such a CPU the first bank reporting a > valid address traps inside the machine check path. > > Treat a missing callback as the address not being physical. The > recoverable_scan callback, also not registered on family 0Fh, is > already guarded through "recover". With this mentioned, perhaps also mention .info_collect? > Fixes: 9595ef77ab11 ("Implement page offline recovery action for AMD") > Signed-off-by: Stefano Stabellini Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Oct 27 13:26:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 13:26:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462157.1673206 (Exim 4.92) (envelope-from ) id 1xLhBo-0002ea-NN; Tue, 27 Oct 2026 13:26:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462157.1673206; Tue, 27 Oct 2026 13:26: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 1xLhBo-0002eT-Ko; Tue, 27 Oct 2026 13:26:08 +0000 Received: by outflank-mailman (input) for mailman id 1462157; Tue, 27 Oct 2026 13:26:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLhBm-0002e4-Pv for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 13:26:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLhBl-007uwB-Va for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:26:05 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0a66c-e002-0a2a0a5209dd-0a2a4508b364-4 for ; Tue, 27 Oct 2026 14:26:05 +0100 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0a66d-f659-0a2a45080019-d155dd2ae51e-3 for ; Tue, 27 Oct 2026 14:26:05 +0100 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso2682850f8f.1 for ; Tue, 27 Oct 2026 06:26: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-48e3eb8f36asm23072904f8f.1.2026.10.27.06.26.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 06:26: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: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=1793107565; x=1793712365; 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=p8GC62F5OBI5s+qwxFjFkNM08oTK+HZwe67OJQDmjAo=; b=fkY4LvbU2MBGnU9SDq+YhqX/dGK/ZhuHSAplhCpPwhGEMzrv2l+ik6lq9V4AxD94qO LM4uFlmcgu368KBqFZCJuOY94zNOkq/En2yE2YbHUGEj39JBIe/jFRe/bUrm5YbgwhU5 nBfof+lFvK+iJmo5mznoxDeILtVlG1YxShfM3GMa21MDAcagN2liBMInClkMVAAP8dT0 m2RfqEG2s0vtE6Y8GkHANXXmjXu9kNu1FKhsWjEeG9z0pKfVZjjwA9i9FwRZWgUZNmLh AnXYibjG11rjeeIcFtxdpd8BK9WFNnuLUyo8R5Q4FW4pvTc69s6mYVAPBBdDDwpm2u2V 9N8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793107565; x=1793712365; 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=p8GC62F5OBI5s+qwxFjFkNM08oTK+HZwe67OJQDmjAo=; b=WEqfBEooO47Of1RdrwzaunARXo3kU8HyIIMXNCCSkqeTC2BEJ7nmSykoeASIn199kK ouxvRMlPuHDJKlWsLmh81IZYFOr69fuXc6Zf3edlg/G4UkEMuV56c1zFvPbmcDPplS7y KxTUBUYUmnf5EGR+9ZyGuXWWX3RKHLNgkGAf4vVML0Qo978+L9B8ziZsnjriuALIS65Q p6z6rZ6xCmaBSbr+830RQ4b2rm5dpf3s2i6vLGXkA6zK/3iWkvPpQfPa1amx30rKgZH/ qmhW3WdXqVaAVH480vsuqnDZXgee62OGuzcNY0K9reBsH6Hk7ZR7o+XwTDbninIQg98M 77vw== X-Gm-Message-State: AFq9FYJJ8W81sOMhbkKPp64FeCnKRnRwk6nY+1FmIeJA2RjSfGJCckGa ojz0pCkdnDwRf1fMdp7YQZP71YZBQgnS0wqATdxIE3il17Q/gdnxKhHLrj9cOavBwvpMAAdZ2Ve KqUa6rw== X-Gm-Gg: AYBFou1xjPhAaaqVJjdqSUDnWcKOYlqLyqm9+WCTMHaWKZB/KD/vRH4aPnLri6WwT/l wOzOxPwUXVhTLLTiH8ztb4rqk57fDEoBRQbg8Y3iUsQnmAcaz5O30aVnNvrRfeV2GeamuF9Vtxl 9NeR8i+vT8xtUHuROYKQdx7eRi9QUlRO3g1GgXuS0hWN+dqTQ4UQSQdABSIuZz0xDCsTeckPoWI a06CkIje6bmOEzvDat0lpzC14qYXqJfPHrfmfHluxP4jAUogwvIilpmiBvdlTT20zqJKKIsZXPs g1/QPtAsr55n3tPlDHOUJKkblfRHycADs5CNsSTcylp5Mn8BlBghfSOvX0loR0rdjCvk1DZWqtG /s+j2PHu2cnGgJkicYkc7Y2XGVJTe6Wjlf8JtkoGeHtwk0wrJuIjhhxlrm2TR0xQgM3c/z69NUk uVn36m7sqrI2O7pXFecO90RgrMR+UTtfLKN0rhBp3ceB9SK/CRPUGP+vzjbO+cHekexSTXRxhug 9sRT9uFYaE/brWEA4YXgPJoopJAsDOFfipkPl3gYggUDDi+3ILMzlrs6rAecj+nWNjpKf3YxLGq LcLPLZfpBML813LQ3gCHF3pVG1XUmAAvxh8psm7ByiqP X-Received: by 2002:a05:6000:298d:10b0:48a:f404:695e with SMTP id ffacd0b85a97d-48e3eba0b4fmr13057242f8f.50.1793107565106; Tue, 27 Oct 2026 06:26:05 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 14:26:04 +0100 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/MCE: purge mce_amd.h Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1793107565-D6D4087B-595ABBE0/10/78276251493 X-purgate-type: spam X-purgate-size: 1507 The sole two declarations there aren't needed, as the functions aren't reference from outside of mce_amd.c. (This also addresses two Misra rule 8.7 violations, just that we apparently didn't accept that rule for some reason.) Signed-off-by: Jan Beulich --- If it wouldn't result in more churn, I would have been inclined to also drop at least the mc_ prefixes of both functions. --- a/xen/arch/x86/cpu/mcheck/mce_amd.c +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c @@ -56,7 +56,6 @@ #include "mce.h" #include "x86_mca.h" -#include "mce_amd.h" #include "mcaction.h" #include "vmce.h" @@ -101,7 +100,7 @@ mc_ec2type(uint16_t errorcode) return 0; } -bool cf_check mc_amd_recoverable_scan(uint64_t status) +static bool cf_check mc_amd_recoverable_scan(uint64_t status) { bool ret = false; enum mc_ec_type ectype; @@ -131,7 +130,8 @@ bool cf_check mc_amd_recoverable_scan(ui return ret; } -bool cf_check mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype) +static bool cf_check mc_amd_addrcheck(uint64_t status, uint64_t misc, + int addrtype) { enum mc_ec_type ectype; uint16_t errorcode; --- a/xen/arch/x86/cpu/mcheck/mce_amd.h +++ /dev/null @@ -1,7 +0,0 @@ -#ifndef _MCHECK_AMD_H -#define _MCHECK_AMD_H - -bool cf_check mc_amd_recoverable_scan(uint64_t status); -bool cf_check mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype); - -#endif From xen-devel-bounces@lists.xenproject.org Tue Oct 27 13:28:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 13:28:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462165.1673215 (Exim 4.92) (envelope-from ) id 1xLhDb-0003Ae-21; Tue, 27 Oct 2026 13:27:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462165.1673215; Tue, 27 Oct 2026 13: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 1xLhDa-0003AX-VF; Tue, 27 Oct 2026 13:27:58 +0000 Received: by outflank-mailman (input) for mailman id 1462165; Tue, 27 Oct 2026 13:27:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLhDY-0003AR-Cy for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 13:27:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLhDX-007vXg-Q3 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:27:55 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0a6cb-bab6-0a2a0a5309dd-0a2a4506a696-46 for ; Tue, 27 Oct 2026 14:27:55 +0100 Received: from [52.101.62.67] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0a6d7-195a-0a2a45060019-34653e43b451-3 for ; Tue, 27 Oct 2026 14:27:54 +0100 Received: from BN9PR03CA0740.namprd03.prod.outlook.com (2603:10b6:408:110::25) by SJ0PR12MB6941.namprd12.prod.outlook.com (2603:10b6:a03:448::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 13:27:27 +0000 Received: from BN2PEPF0000A88F.namprd04.prod.outlook.com (2603:10b6:408:110:cafe::58) by BN9PR03CA0740.outlook.office365.com (2603:10b6:408:110::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Tue, 27 Oct 2026 13:27:26 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF0000A88F.mail.protection.outlook.com (10.167.248.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 13:27:25 +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.53; Tue, 27 Oct 2026 08:27:25 -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.53; Tue, 27 Oct 2026 08:27:25 -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.53 via Frontend Transport; Tue, 27 Oct 2026 08:27: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=l93f7Ky9MhjiYbNIItbBhRYmEC5WRa1fT5MU9ee/1Cn9kpn20KBlZYozqeEefBJu/tKp5iH/kldL0HwcEaoIjai/lViqvG+KuEY2ANyjfyZL3BNgqXXseSYWGxUhGnvQe1ybSnSJ7O6PG3k2G1qhPcuJ2QKmAw+VOkEY+S2bUNC/twnOit1Ra6I3LHzBAj83eSS1HWw/6RlDCZaleSrX7DweyGUBd0R8C/IY8SqHNM2zIt0c2+K7oUHxTyrDMoCw3J5tqL4DOI60LWjeS+u2jDjTZIdYNtuNjvbi+sO7WbtkuNWmYaTRuwxJaS1ct8e5Q0tlHE3MsHLS9fgoMGs+eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/nY8jl+8X9fgjGf++R0V+RqjAbDRWNwf395vyKfYKDI=; b=nmVJp1Ry5Wt3z3sN4ZkWnfkdQtRz2x7LNY6FsZCg5KxlHyl7QdE+iVWDLMzca4yVYrvUBaE3S3lL06UnRyujgnBjBw2oZXlqcxTlHcTcdblzS36ktKxaiD0tnA8aA9ae0CV9n1qs7SRKls5/Z7CkS7lE2YE+nPy4/5i1xLkA+ZoH39EvAQQuCVhKAXt8XGcifYaH7RTYvlUif+2QGMbp6EM9T7LPYkasehXETjwSXJoFx+8WFpNeVN+WchLyxDtuLYsFfdUccHK3sjNLUxGZ0H3I4ykMBJ8u0GExx8nlPj436xftQj1cIEzIdO83QiBdDwfUVo3uC0fxeVLaTFStGA== 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=/nY8jl+8X9fgjGf++R0V+RqjAbDRWNwf395vyKfYKDI=; b=Dq3mWjBcH4pSFp9AS4l4SudXHwnElVqSlGBNaP6t48IM3wEfuZ3Fe7MQLWZSiJojD/Ju6iuvs67N/hD5ySTQl7wXMJgpFy38nu+KT2nX6jm6TNLvykEgTQPBOhZZg9EnM6ADkBOZjWqQtHU8kyan7/vw2DYXpkF8HK0L6ukinaQ= 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: <75922cc3-907f-4de4-b330-bfd76e0b097d@amd.com> Date: Tue, 27 Oct 2026 14:27:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/dt: Only parse direct child nodes of /reserved-memory To: Kuan-Wei Chiu , CC: , , , , , References: <20261027031855.2671912-1-visitorckw@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261027031855.2671912-1-visitorckw@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF0000A88F:EE_|SJ0PR12MB6941:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d067f9c-bae5-492b-68be-08df342e0a7f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|82310400026|1800799024|23010399003|18002099003|22082099003|10067099003|56012099006|11063799006|261021123027099003|261009223027099003|261021121427099003|261022105027099003|261021135927099003|261026140227099003; X-Microsoft-Antispam-Message-Info: SvhfBkYgql70mDJKUTyXlmhgqsbAKQCqtvBglcnEGQIGKcAgaE8FSfHhLpGD6Ka/XOZqt2Irn23S70HBEsrH4RdpujtHnvp++KcgvbNSRvHIejVhfPV+KIdXU8QVHdrc87nBHvGC0ZtTzFbn/hX5xY4154fgKk5ZO8MFrxsA+oI9EdVEwChHcyOE36IurrnfYQa6hUA7KmA5oXRewGnr1vSnfGGqsEIAED/UIkscvZUCoMZk3bScVVXvZg61GlaTs8X92wkTE9txjON62/iGJrUwLTVoqOxv+SoAZw6jL2Obi8JidSD5DWOlynE+l9gA3mcF+s2d27JjKxUua7SV0mslWdSbelDA0fhirOVdGLzMC4cUmknlXhCvpbOVYDW5PADqsgTIcQ1UR1S3kq+jRvcDpcUg7LOdSunvcv4yYQJYzy3jyWdlP/rxqm71Yj6sRydwC6m7wkNnjPiLsqN3LRLbXgejAwBneBQ6/4LsOgW+HJhvtstY4FHbyAoKvQTV6rfoqcyRh2JAnnfq+1240MouA8oAQdfiP1eOGJ7Z1kwixkRCAxfod5Ds6hB8ycbaI++qhU/mIc0ylzJdwOvhyIwAvCmwVf7pwIdmWywqxFfmUg5VjyKT6hCgo7cnNubatOmofYNhHH9tn+67NWfXR0PObOAequ1nc/Z/E+5WE5nGTRWDM+oRbNW7HDa7W+c4mOMflGDL0ppsHGfYZyzl0g== 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)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006)(261021123027099003)(261009223027099003)(261021121427099003)(261022105027099003)(261021135927099003)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: avTog1gqGs0khZC8mFjxJfUNWyi53v35+Z8v6CYmTovQHU33Sq7qOgekCvYEaja4LQQUsbftqCr5wJSMnonCVj3lDFlNLIJiVM5wbHUWzK22veNgIUd4iiLda0vpghdv9770nolmCgbCBMal8TKwo3E28aNscEGpU3Avw3OFEgXPuJr78Nr5kPb1hf88emf9e2DYJ4KqIYaIeQYq9XbGqjtKrAlLQ9h/qNOCLZKhVI5Oz/ECxNk8o2yg05qnbiIT7nN6HbQpyQAjsIfqQqLJBqxbeua9PA1IJ2bcSSFzjCGwBi0OAfW3MO5VBIl2EcamvTJ6K1DsX/ysUxiDEnf1z8ZSeYqmU8zZw0nqzG0Z8Ui90zKswpHJCvHz5RiGK3X8lChFZV62G+u+OphwMFcNWHB/a7Ehs4bbvlD0QS7CBALvGJpR+kdy0DtkcMXFZ1+C X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 13:27:25.8732 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2d067f9c-bae5-492b-68be-08df342e0a7f 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: BN2PEPF0000A88F.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6941 X-purgate-ID: tlsNG-16d1c6/1793107674-F7ECC77B-9F538EE7/0/0 X-purgate-type: clean X-purgate-size: 1994 On 27-Oct-26 04:18, Kuan-Wei Chiu wrote: > process_reserved_memory() uses device_tree_for_each_node(), which walks > all descendants of /reserved-memory rather than just its direct children. > However, a child node such as nvmem-rmem can contain nvmem-layout and > cell subnodes whose reg properties specify internal offsets rather than > physical memory addresses. Parsing these subnodes records invalid > reserved memory regions and fails the overlap check when bitfield cells > share the same offset. > > Ignore nodes with depth != 1 in process_reserved_memory_node(). > > Fixes: d96594eef39a ("xen/arm: keep track of reserved-memory regions") > Signed-off-by: Kuan-Wei Chiu > --- > xen/common/device-tree/bootinfo-fdt.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c > index ca64daf4cd..eea35325f7 100644 > --- a/xen/common/device-tree/bootinfo-fdt.c > +++ b/xen/common/device-tree/bootinfo-fdt.c > @@ -185,8 +185,13 @@ static int __init process_reserved_memory_node(const void *fdt, int node, > u32 size_cells, > void *data) > { > - int rc = process_memory_node(fdt, node, name, depth, address_cells, > - size_cells, data); > + int rc; > + It would be easier to understand with the comment like: /* Only direct children of /reserved-memory describe memory regions */ > + if ( depth != 1 ) > + return 0; > + > + rc = process_memory_node(fdt, node, name, depth, address_cells, > + size_cells, data); > > if ( rc == -ENOSPC ) > panic("Max number of supported reserved-memory regions reached.\n"); I will change on commit. Thanks for the submission. Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Oct 27 13:30:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 13:30:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462174.1673226 (Exim 4.92) (envelope-from ) id 1xLhGA-0004vx-Hz; Tue, 27 Oct 2026 13:30:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462174.1673226; Tue, 27 Oct 2026 13:30: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 1xLhGA-0004vq-Eb; Tue, 27 Oct 2026 13:30:38 +0000 Received: by outflank-mailman (input) for mailman id 1462174; Tue, 27 Oct 2026 13:30:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLhG9-0004vb-7B for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 13:30:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLhG8-006mZs-Gc for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:30:36 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0a776-e002-0a2a0a5209dd-0a2a45029e88-32 for ; Tue, 27 Oct 2026 14:30:36 +0100 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 6ae0a77c-6ca4-0a2a45020019-b9ff1c12b587-3 for ; Tue, 27 Oct 2026 14:30:36 +0100 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 1a17d8e2a00000f79f.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 27 Oct 2026 13:30:31 +0000 Received: from [192.168.1.52] (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 5E55381AE5 for ; Tue, 27 Oct 2026 14:30:30 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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: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=coJyJBawLVcNXq76/JPzGF/XDQABCkKh8rlZBfRYcMM=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=uIiQiJnFJ9Q1jJcykYzZ99Yn8TVOKqFvY86IhuPY7M6te3UXtP27cXngj/XqED8/WEE/Rk/Pq /Qo4dn8wxN+ABGvOa4+iSe3n0hZ5WfDG8GLSydDdryhEBi0ksPaouZn7CwnpTtNkl7rqUqXkGrw Ib2idZh6E2cVzNzCpqnHhcL0kMC+W3xXJUnwvcdESk7gk8O8jX4s0dwCmUIBFQiaxn8RrAvWV/6 LxIpIGYmcLGYNF1q8cha16zjJ0yhlP13wNDfP3PAOGuOyaXTmu5yWMb+/5yo96S2tIQNVSrlTwM zYAfPDYd1dVoIug3ehIBJg1uVOtxgYqQclusv+PVh5qg== X-Zone-Loop: b835981ab4889636448c5d56c810a0f110a547c7fcf0 x-campaign-type: default x-transaction-id: edbd1323-add0-4bcd-b627-f4f94b27200f x-swg-uid: 01-4370e3ba-196d-48a3-905b-a792114768c4 X-Mailer: Sweego Message-ID: <1793107831.8631fc262581453bbf619ec5b2062170.1a17d8e2a00000f79f@vates.tech> x-swg-bid: 1793107831.8631fc262581453bbf619ec5b2062170.1a17d8e2a00000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 27 Oct 2026 14:30:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/MCE: purge mce_amd.h To: xen-devel@lists.xenproject.org References: Content-Language: en-US From: Baptiste Le Duc 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: 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: 1793107830427 X-purgate-ID: tlsNG-720697/1793107836-672B12AC-4BCB21E8/10/78276251493 X-purgate-type: spam X-purgate-size: 1734 LGTM: Reviewed-by: Baptiste Le Duc On 10/27/26 2:28 PM, Jan Beulich wrote: > The sole two declarations there aren't needed, as the functions aren't > reference from outside of mce_amd.c. (This also addresses two Misra rule > 8.7 violations, just that we apparently didn't accept that rule for some > reason.) > > Signed-off-by: Jan Beulich > --- > If it wouldn't result in more churn, I would have been inclined to also > drop at least the mc_ prefixes of both functions. > > --- a/xen/arch/x86/cpu/mcheck/mce_amd.c > +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c > @@ -56,7 +56,6 @@ > > #include "mce.h" > #include "x86_mca.h" > -#include "mce_amd.h" > #include "mcaction.h" > #include "vmce.h" > > @@ -101,7 +100,7 @@ mc_ec2type(uint16_t errorcode) > return 0; > } > > -bool cf_check mc_amd_recoverable_scan(uint64_t status) > +static bool cf_check mc_amd_recoverable_scan(uint64_t status) > { > bool ret = false; > enum mc_ec_type ectype; > @@ -131,7 +130,8 @@ bool cf_check mc_amd_recoverable_scan(ui > return ret; > } > > -bool cf_check mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype) > +static bool cf_check mc_amd_addrcheck(uint64_t status, uint64_t misc, > + int addrtype) > { > enum mc_ec_type ectype; > uint16_t errorcode; > --- a/xen/arch/x86/cpu/mcheck/mce_amd.h > +++ /dev/null > @@ -1,7 +0,0 @@ > -#ifndef _MCHECK_AMD_H > -#define _MCHECK_AMD_H > - > -bool cf_check mc_amd_recoverable_scan(uint64_t status); > -bool cf_check mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype); > - > -#endif From xen-devel-bounces@lists.xenproject.org Tue Oct 27 13:31:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 13:31:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462182.1673233 (Exim 4.92) (envelope-from ) id 1xLhH9-0005TE-PY; Tue, 27 Oct 2026 13:31:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462182.1673233; Tue, 27 Oct 2026 13: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 1xLhH9-0005T7-Mo; Tue, 27 Oct 2026 13:31:39 +0000 Received: by outflank-mailman (input) for mailman id 1462182; Tue, 27 Oct 2026 13:31:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLhH8-0005Sy-BT for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 13:31:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLhH7-00AW2F-OQ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:31:37 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0a7ad-2eae-0a2a0a5409dd-0a2a4505cb14-40 for ; Tue, 27 Oct 2026 14:31:37 +0100 Received: from [40.107.162.140] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0a7b8-4cb1-0a2a45050019-286ba28c680f-3 for ; Tue, 27 Oct 2026 14:31:37 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by AS8PR03MB9413.eurprd03.prod.outlook.com (2603:10a6:20b:5a0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 13:31:31 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0546.019; Tue, 27 Oct 2026 13:31: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=uJZo/aYEM9s9vPXaNA0I+4kNzJsj5y6ddbhtD+gHXy02R72rnM5vbQ05v/yZ0FQnZdKa31a4/bXt/VeRELrS8rVtFFDK3o+nT7tbjNUyk0CHPA0fjxGqQBOTAFdAr7+TwBlikHiN8hBxIRdAhwOyL1tNTa1DCFYV/UzdNIJKadUHdvDkoowfQWtD4TRNmttlJDJvaI2KDC6TPMHkZL9/gRSIsvmV6xXXsCPLm3sftmsQKz9oQBMXMFIrV0+b9So8s9Z+pTrxvP/nmWDpHHQ1sZuFe1NmzwRBHP+IG5n4Wq714PY0CDiW6uvgYYLhl83oAG+CW7OtVLu87SGJ/GREFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XIp39SQ7NSugR9Jc4fizztCFQJkzMs69QMeYd6QUALo=; b=ucbIkvYEv8oIZTflKG6MWgWsPu/iLTdWvaSlJ4W405IOE2BBiFvc16zlf4JtknyRpBiUedrqKQFA6RzRRJYB5ZF8/7wbruwV6vzeSOmDnvUw5Jn60qKdiUyKtPkNHYkEPvYbYF/SH7IhktAmd0uFn8WA/PdqCtMlc3o4JcqV26ceAOBtkEdgcBvERclGQruTovLztcBnZI+QG5PZ4IDCDD57prbCpsE2iD0uBOfQR0Gc9L0+OVx9YCDoPPkZA9qbAPLDYC5DavII3nTwgapZxyJeFi4+sHUuO778u0Yj9hqPS2vvamt2oeqXHFSYXrPKZcpVwYI0F+qUE3u3rwBwMA== 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=XIp39SQ7NSugR9Jc4fizztCFQJkzMs69QMeYd6QUALo=; b=tyND+OmHoeBzwA056wUuoB4CyuPamITXXSvXVcwB2ai1nEsADStg3AjUMBneswvnzI2wc7+O9AzUyv3D3IN1v9tlrWaqZY2gbhj8WTqSJa1sllVJDZSqrgDBah20YyFviEszanJZB5hRbC82vhrd/dSIyNehuOiIP5ypRhFzVI0M0RUh8hWa5VhjLp8B4iOnr8DHT6lAb9MCmBc8+kuMRvWW1OMn2Y8Y+ME7OEJeHvXq3gbS5QIpiPYYsm+4PTrGqgYMfDCIrV7rbPALiEutRHRdHLKghm0l2YFYvnMRITzV6mTBPdPalRHNoFCYWJ9ZokCqE7fsZuXrOfJLQWm1EQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Rahul Singh Subject: [PATCH v6] xen/arm: smmuv3: Add support for removing devices Thread-Topic: [PATCH v6] xen/arm: smmuv3: Add support for removing devices Thread-Index: AQHdZhd6qHbitDeIwk6I1fMybh5L7A== Date: Tue, 27 Oct 2026 13:31:31 +0000 Message-ID: <099ab694a01c3550e65853ed4cca06efd7043d68.1793107742.git.mykyta_poturai@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: AS2PR03MB9076:EE_|AS8PR03MB9413:EE_ x-ms-office365-filtering-correlation-id: 92c79d3e-3fe8-4cd0-2294-08df342e9ce1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|6133799003|18002099003|261026140227099003|56012099006|11063799006|261022105027099003|261021123027099003|10067099003|261021121427099003|261009223027099003|261022075727099003|260925021911599003|261026121527099003|38070700021|260925021311599003|260925022911599003; x-microsoft-antispam-message-info: 07lyBTItKAgLpmsZAdSgfoKI9PXZCUND5375idOl6u5C+pp1c8KBQUBB+h3nVAWbxx7cWNSqTuxKLXFpPJaEoV96ObiTBmZTGrektyf4cXIMR12YvchTIt35Ku5wIfUbaWaFKyVCsh3V7sbFTKA+LQXbhBXlfGVNGS8HRNJzVbQrgZckfGOUtE3wjxZQWRSaiL/5yJ52I92fKrtnWIalCoruWYhGNs1FtYmD6qRMhgDls5rhAleQt4Y3kKm92dvyUS1CrT2BPBdIUR6F1hCFSzNIRNt4LOnB8eTVBZLyssEDpXcuABMty2TLQhPUFdEUnTPJVhsyNwwQJqyylNFQBSypCbZSseZFq3EFSr80oEGIvRlTnV2NP4yBm8mQ7wsDLVXTH3V9lJS9YEvPaiPW2wiMMPH8q/pElokVrh29zJzMaqiPoyorAfLdEAVXRh12QmV7niERcuCi514hNtW++tRgClTXgEvyLTwfRAtOeDT023Hi8NGpYt2RaSUe6xX62GYHovgumYOkjSPPFWXKW4xdRShTpxEYvhE0QfAwzsI4Rtn7qbFYp5MBxlp2/8ZfdbXkZUnwK3belT8nX9Ritrl6TIbhSKcgSdxmkXJ5Y1do06NQcUUX6D2PXlMtmWKRxzKm3NuMNZ0i/fALQWYEyZPz/yvS229yhoXelaeOPn8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(6133799003)(18002099003)(261026140227099003)(56012099006)(11063799006)(261022105027099003)(261021123027099003)(10067099003)(261021121427099003)(261009223027099003)(261022075727099003)(260925021911599003)(261026121527099003)(38070700021)(260925021311599003)(260925022911599003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WVFrUW9PVXJNcHVKaGxSQkdGQ1hicGhUdU0vVUdVRDNVNktoVUtxNXlYclUx?= =?utf-8?B?U3luOUpwbkZENkVlcTNnVHVpb3hOU29SV1pMY3UyVlpaTzJGZUYwNXM4N09N?= =?utf-8?B?eW5Hc0l3a09IckhNVlhoSnNWTEZhRVpCSlhWMWRwc3pOb0lvMUtKcVF2STJN?= =?utf-8?B?YXVnUW5qRTQvbENydEN1Tk5qYzlYRjVEUlgvMzdlRlhFZU93cEpuRjZBYm1s?= =?utf-8?B?OGZpVTQyVnRSandUNDZSWCt0UDNLSTYzR1BkUklqRm50eGRmTzFISWxTbkxn?= =?utf-8?B?dCtjZEtlS29JdVpYeTBhTnRsTENLckwzdDdWT3M4czI5N0hZSlpDL2ZPbmRY?= =?utf-8?B?d1NLdUMzVTViWkNLYkZlQjB2b1NOaDZDZkZxb2t5SGV5THZISW9Kb3NUKzlY?= =?utf-8?B?ck93QUU3a2Z5MGZvdVlIR1pDbkFITGI1Q1l2YW5VVmgwMGhFdjAzeE9OcTFn?= =?utf-8?B?eE5NbUo5Nk1UM0lPck9Xb0ozN09VODFNVTJwdHpONG9QVHNYME4xWk9nazBl?= =?utf-8?B?QmltQ3VBWVp0c2lqdXo3MUdqUytVdmJjQmtSVWZnOHFjMW1WbzlGL0Zvand2?= =?utf-8?B?UUNjRHljdlJjYXZTQkNnT3YxMlkwcGVaMXR0V1JvQ29oTCtFOHRNU1JLR3dt?= =?utf-8?B?aUw4MXBVS3UvMmFLSGpPa3pqSnZ0a3R3dCtOMnZKZG9iUFI2YmsxeVk2WHhO?= =?utf-8?B?OVVxYThJK3ByUXpaVWV6WVlGWSt6NFRrUGVpRmMyaG1aSlBGbmxlSGU1YXdm?= =?utf-8?B?QkRvTDZJVkFyTHJsbDdlV2FLMGlVUVoyOUIycDVCNnJuNDlPWHVjN0x3L1du?= =?utf-8?B?bzZlcDk4OTZ5NUh5MStSSHEvdHhpam03NzZRZnFBTVlkNlJCWW9iU0tSRVdR?= =?utf-8?B?RGJ1SzhNc2lhaE1RaGdVUkdYSjNKMm9KRW9NanYyUnNVb3UyMHM5WFluUWpY?= =?utf-8?B?K3NDQ29tSGZjNXhyZjFGV2xVdVJ2WjRpbzlrVXhxcE1tM0cwbFRDQk9lS2x6?= =?utf-8?B?ZXlwWWRJWDRtR3Z5ZSt5NUN1Q0Z1Q3BWeGVhdmxXcnJmSFhsTStFRXVaRnJp?= =?utf-8?B?NWFTZmtpeFR2dHJOejRHWGVTbGM5UzB2c2c1TGJ4dUVhTGpoWWFsZm1JSXBo?= =?utf-8?B?VmFZYXNOcjNqbDJHSVpyR24yMmVtSXplOEQwYzVqMi8yL0VpcWVXdERqUkwx?= =?utf-8?B?UjYwSFkvcTdobVEyTXRRU245WDZrUjUxL0lFak55M3llYlpNZmFTd0FvM0pU?= =?utf-8?B?aXRqTksrZTJ3bDNmTDBJZ1Rub0pvWEQrREtrWnVESjhTeUpYNWJleEVSb2lX?= =?utf-8?B?cXdLamljUURVZWpTWDJKMUc0SWNvR2t2OFNsL0N2bGtVOENjUk5IZ1lwamN3?= =?utf-8?B?NTlqRWtrRmloMlArZ0NoR2pkRE1OdDRTcDNtY1lPVGNzMkFVRTZPYithSy9S?= =?utf-8?B?blNDYjc3Q0laMndhbFJReE01KzFYMEpEMG5KSTNFNmhUcXJraEFnQnJaUzBI?= =?utf-8?B?UFhmdEFZSXE4K2gva0FaRDVwRzlKcGxtVXh6enAyTFlXOXlheUxUYmptZy9i?= =?utf-8?B?YW1kRjk1aHBHM2xQMnhhbmZvZDRVRHBaWmFYV0IyR3ovS1B3YUNxbkdsZlhs?= =?utf-8?B?S2VodlYvejNJakEydzJJVG96dHdmNG40dDY5aWwwRmR1U3gyMHpVUktza1pN?= =?utf-8?B?QzBaTFVQZ2dHbUIyZit2S0NNU1NWR1NsU0lXVzh4NS9GakRrY082KytnNzNz?= =?utf-8?B?VVpTQVpWR1A4WS9wb1RXZmd5VGtTVG9nbG15UE91LzlTT0xyQjRNYnB1RVZM?= =?utf-8?B?Q1hmSWR0a0c0QmIxazVRYS93L21vS1lIL3dNeVhGaVd5bXA0ZWxYYlhpNWht?= =?utf-8?B?OG5HRU5nWXhXUVYyM3JVdU1JQ1JQNVNpNlFoL3V2WXZocmc5V1M4OFdNMmVZ?= =?utf-8?B?UXhHYmZXTXpzRWROT1FibVR0RjJUSndPbFAzOUpvT2pMcUJmbnZDMkhkaklY?= =?utf-8?B?Mi9RVjVPWk1JRklHMkE5U3hIOXNtRlBWakRzanVNYzNQbEpDZlhvb1ZSTzJV?= =?utf-8?B?QVg4ajRxME1Lbk5xYnFyOFF5ZTY0S1BjN3hjcjNGbUc4UkpacC9tcTBSUEkw?= =?utf-8?B?TTcwS1Rtc1lnRFFjLzEwQVVVV3hwUDdkQ3hJaFRwT2FZc1llV3lhMC9Tc1I1?= =?utf-8?B?dWd2REQwaGlSdEplcjlFL1VlQnZZNmFpamRqQlJLalgxemtnQzhCcEVFdjVO?= =?utf-8?B?ZW1QQXcyT1FySzlzcDhSQUdvMUViUGJRdjdaZGZ2dVpIb3F3M0dCSFJlUHdY?= =?utf-8?B?dUU1b29lRXZ0UGd5VGZ4Qkh1NEFsc0tiWkc1bERpc09GVzZpeFp4QT09?= 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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 92c79d3e-3fe8-4cd0-2294-08df342e9ce1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2026 13:31:31.4564 (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: 55T8gED9lzLcpJ0QEpaa8ISIC6il2QLTY559EIRdWal0QTK0CNO9b0dtO1fFZM+qmSfEqREBIAxF2w+pg3dfyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9413 X-purgate-ID: tlsNG-c201ff/1793107897-F4EA12A1-1C3A035B/0/0 X-purgate-type: clean X-purgate-size: 8512 QWxsb3cgZm9yIHJlbW92aW5nIGRldmljZXMgZnJvbSBTTU1VdjMuIGFybV9zbW11X2RlYXNzaWdu X2RldiBoYW5kbGVzDQptb3N0IG9mIHRoZSB3b3JrIGJ5IGRpc2FibGluZyBBVFMgYW5kIHplcm9p bmcgU1RFcy4gQWRkaXRpb25hbGx5LCB1bnNldA0KdGhlIGR0X2RldmljZV9pc19wcm90ZWN0ZWQg ZmxhZyBhbmQgZnJlZSBubyBsb25nZXIgbmVlZGVkIHNtbXVfbWFzdGVyLg0KRnJlZSBpb21tdV9m d3NwZWMgZm9yIFBDSSBkZXZpY2VzIG9ubHksIGZvciBEVCBkZXZpY2VzIGl0IGlzIGhhbmRsZWQg YnkNCmdlbmVyaWMgSU9NTVUgbGF5ZXIuDQoNClJld29yayBkdF9kZXZpY2Vfc2V0X3Byb3RlY3Rl ZCB0byBhY2NlcHQgYSBib29sZWFuIHBhcmFtZXRlciwgdXBkYXRlDQpjYWxsc2l0ZXMuDQoNClNp Z25lZC1vZmYtYnk6IE15a3l0YSBQb3R1cmFpIDxteWt5dGFfcG90dXJhaUBlcGFtLmNvbT4NClJl dmlld2VkLWJ5OiBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnplbEBhbWQuY29tPg0KLS0tDQoNClRl c3RlZCBvbiBRRU1VIHdpdGggU1JJT1Ygc2VyaWVzWzFdIGJ5IHJlcGVhdGVkbHkgZW5hYmxpbmcv ZGlzYWJsaW5nDQpWRnMuDQoNClsxXTogaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vY292ZXIuMTc3 MjgwNjAzNi5naXQubXlreXRhLl81RnBvdHVyYWlAZXBhbS5jb20vDQoNClY1LT5WNjoNCiogbW92 ZSBkZWFzc2lnbiBhbmQgZGlzYWJsZV9wYXNpZCBpbnRvIHRoZSBQQ0kgYnJhbmNoDQoqIHNldCBk ZXZfaW9tbXVfcHJpdiB0byBOVUxMIGZvciBEVCBkZXZpY2VzIG9ubHkNCiogY29sbGVjdCBSQg0K DQpWNC0+VjU6DQoqIGRyb3AgZGVhZCBkb21haW4gbG9va3VwIG9uIHRoZSBEVCBwYXRoDQoqIHJl bW92ZSBhc3NlcnQgb24gIGFybV9zbW11X2RlYXNzaWduX2RldiBlcnJvcg0KKiBkcm9wIHJlZHVu ZGFudCBJU19FTkFCTEVEKENPTkZJR19IQVNfUENJKQ0KKiBmaXggaW5kZW50YXRpb24NCg0KVjMt PlY0Og0KKiBzL3U4L3VpbnQ4X3QvDQoqIGFzc2VydCBwY2lkZXZzX2xvY2tlZA0KKiBhc3NlcnQg ZGVhc3NpZ25tZW50IGlzIG9ubHkgcmVhY2hhYmxlIGJ5IFBDSQ0KKiBmaXggYnVpbGQgZXJyb3Ig d2l0aCBIQVNfUENJPW4NCg0KVjItPlYzOg0KKiBmcmVlIGZ3c3BlYyBmb3IgcGNpIGRldmljZXMN CiogcmVtb3ZlIHRlc3Rpbmcgbm90ZSBmcm9tIGNvbW1pdCBtZXNzYWdlDQoNClYxLT5WMjoNCiog Y2hlY2sgZm9yIHBoYW50b20gZnVuY3Rpb25zDQoqIHNpbXBsaWZ5IHBjaS9kdCBkZXZpY2Ugc3Bs aXQNCiogaW1wcm92ZSBlcnJvciBoYW5kbGluZw0KKiBkb24ndCB0cnkgdG8gZnJlZSBtYXN0ZXIg Zm9yIHVucHJvdGVjdGVkIGRldmljZXMNCiogcmV3b3JrIGR0X2RldmljZV9zZXRfcHJvdGVjdGVk DQotLS0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vaXBtbXUtdm1zYS5jIHwgIDIgKy0N CiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jICAgIHwgNjAgKysrKysrKysr KysrKysrKysrKysrKystDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUuYyAgICAg ICB8ICA0ICstDQogeGVuL2luY2x1ZGUveGVuL2RldmljZV90cmVlLmggICAgICAgICAgICB8ICA1 ICstDQogNCBmaWxlcyBjaGFuZ2VkLCA2NSBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQ0K DQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL2lwbW11LXZtc2EuYyBi L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9pcG1tdS12bXNhLmMNCmluZGV4IGZhOWFiOWNi MTMuLjA2NDhmOWI0MDcgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0v aXBtbXUtdm1zYS5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vaXBtbXUtdm1z YS5jDQpAQCAtMTM2Nyw3ICsxMzY3LDcgQEAgc3RhdGljIGludCBpcG1tdV9hZGRfZGV2aWNlKHU4 IGRldmZuLCBzdHJ1Y3QgZGV2aWNlICpkZXYpDQogICAgICAgICB9DQogDQogICAgICAgICAvKiBM ZXQgWGVuIGtub3cgdGhhdCB0aGUgbWFzdGVyIGRldmljZSBpcyBwcm90ZWN0ZWQgYnkgYW4gSU9N TVUuICovDQotICAgICAgICBkdF9kZXZpY2Vfc2V0X3Byb3RlY3RlZChkZXZfdG9fZHQoZGV2KSk7 DQorICAgICAgICBkdF9kZXZpY2Vfc2V0X3Byb3RlY3RlZChkZXZfdG9fZHQoZGV2KSwgdHJ1ZSk7 DQogICAgIH0NCiAjaWZkZWYgQ09ORklHX0hBU19QQ0kNCiAgICAgaWYgKCBkZXZfaXNfcGNpKGRl dikgKQ0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LXYzLmMg Yi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vc21tdS12My5jDQppbmRleCBiZjE1MzIyN2Ri Li4yMzJkZjI0MjFjIDEwMDY0NA0KLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3Nt bXUtdjMuYw0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL3NtbXUtdjMuYw0KQEAg LTE0OTMsNiArMTQ5Myw2MyBAQCBzdGF0aWMgaW50IGFybV9zbW11X2Fzc2lnbl9kZXYoc3RydWN0 IGRvbWFpbiAqZCwgdTggZGV2Zm4sIHN0cnVjdCBkZXZpY2UgKmRldiwNCiBzdGF0aWMgaW50IGFy bV9zbW11X2RlYXNzaWduX2RldihzdHJ1Y3QgZG9tYWluICpkLCB1aW50OF90IGRldmZuLA0KIAkJ CQkgc3RydWN0IGRldmljZSAqZGV2KTsNCiANCitzdGF0aWMgaW50IGFybV9zbW11X3JlbW92ZV9k ZXZpY2UodWludDhfdCBkZXZmbiwgc3RydWN0IGRldmljZSAqZGV2KQ0KK3sNCisJc3RydWN0IGFy bV9zbW11X21hc3RlciAqbWFzdGVyOw0KKwlzdHJ1Y3QgaW9tbXVfZndzcGVjICpmd3NwZWM7DQor DQorCWZ3c3BlYyA9IGRldl9pb21tdV9md3NwZWNfZ2V0KGRldik7DQorCWlmICggIWZ3c3BlYyAp DQorCQlyZXR1cm4gLUVOT0RFVjsNCisNCisJbWFzdGVyID0gZGV2X2lvbW11X3ByaXZfZ2V0KGRl dik7DQorCWlmICggIW1hc3RlciApDQorCQlyZXR1cm4gLUVOT0RFVjsNCisNCisjaWZkZWYgQ09O RklHX0hBU19QQ0kNCisJaWYgKCBkZXZfaXNfcGNpKGRldikgKQ0KKwl7DQorCQlzdHJ1Y3QgcGNp X2RldiAqcGRldiA9IGRldl90b19wY2koZGV2KTsNCisNCisJCS8qIElnbm9yZSBjYWxscyBmb3Ig cGhhbnRvbSBmdW5jdGlvbnMgKi8NCisJCWlmICggZGV2Zm4gIT0gcGRldi0+ZGV2Zm4gKQ0KKwkJ CXJldHVybiAwOw0KKw0KKwkJQVNTRVJUKHBjaWRldnNfbG9ja2VkKCkpOw0KKw0KKwkJaWYgKCBh cm1fc21tdV9kZWFzc2lnbl9kZXYocGRldi0+ZG9tYWluLCBkZXZmbiwgZGV2KSApDQorCQkJZGV2 X2VycihkZXYsICJSZW1vdmluZyBhbnl3YXlcbiIpOw0KKw0KKwkJYXJtX3NtbXVfZGlzYWJsZV9w YXNpZChtYXN0ZXIpOw0KKwl9DQorCWVsc2UNCisjZW5kaWYNCisJew0KKwkJaWYgKCAhZHRfZGV2 aWNlX2lzX3Byb3RlY3RlZChkZXZfdG9fZHQoZGV2KSkgKQ0KKwkJew0KKwkJCWRldl9lcnIoZGV2 LCAiTm90IGFkZGVkIHRvIFNNTVV2M1xuIik7DQorCQkJcmV0dXJuIC1FTk9ERVY7DQorCQl9DQor DQorCQlkdF9kZXZpY2Vfc2V0X3Byb3RlY3RlZChkZXZfdG9fZHQoZGV2KSwgZmFsc2UpOw0KKwkJ ZGV2X2lvbW11X3ByaXZfc2V0KGRldiwgTlVMTCk7DQorCX0NCisNCisJZGV2X2luZm8oZGV2LCAi UmVtb3ZlZCBtYXN0ZXIgZGV2aWNlIChTTU1VdjMgJXMgU3RyZWFtSWRzICV1KVxuIiwNCisJCSBk ZXZfbmFtZShmd3NwZWMtPmlvbW11X2RldiksIGZ3c3BlYy0+bnVtX2lkcyk7DQorDQorCXhmcmVl KG1hc3Rlcik7DQorDQorCS8qDQorCSAqIEZvciBEVCBkZXZpY2VzIHRoZSBmd3NwZWMgaXMgZnJl ZWQgYnkgaW9tbXUgc3Vic3lzdGVtLCBidXQgZm9yIFBDSQ0KKwkgKiBkZXZpY2VzIHdlIG5lZWQg dG8gZnJlZSBpdCBoZXJlDQorCSAqLw0KKwlpZiAoIGRldl9pc19wY2koZGV2KSApDQorCQlpb21t dV9md3NwZWNfZnJlZShkZXYpOw0KKw0KKwlyZXR1cm4gMDsNCit9DQorDQogc3RhdGljIGludCBh cm1fc21tdV9hZGRfZGV2aWNlKHU4IGRldmZuLCBzdHJ1Y3QgZGV2aWNlICpkZXYpDQogew0KIAlp bnQgaSwgcmV0Ow0KQEAgLTE1NzEsNyArMTYyOCw3IEBAIHN0YXRpYyBpbnQgYXJtX3NtbXVfYWRk X2RldmljZSh1OCBkZXZmbiwgc3RydWN0IGRldmljZSAqZGV2KQ0KIAkJfQ0KIA0KIAkJLyogTGV0 IFhlbiBrbm93IHRoYXQgdGhlIG1hc3RlciBkZXZpY2UgaXMgcHJvdGVjdGVkIGJ5IGFuIElPTU1V LiAqLw0KLQkJZHRfZGV2aWNlX3NldF9wcm90ZWN0ZWQoZGV2X3RvX2R0KGRldikpOw0KKwkJZHRf ZGV2aWNlX3NldF9wcm90ZWN0ZWQoZGV2X3RvX2R0KGRldiksIHRydWUpOw0KIAl9DQogDQogCWRl dl9pbmZvKGRldiwgIkFkZGVkIG1hc3RlciBkZXZpY2UgKFNNTVV2MyAlcyBTdHJlYW1JZHMgJXUp XG4iLA0KQEAgLTI4NjcsNiArMjkyNCw3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgaW9tbXVfb3Bz IGFybV9zbW11X2lvbW11X29wcyA9IHsNCiAJLnVubWFwX3BhZ2UJCT0gYXJtX2lvbW11X3VubWFw X3BhZ2UsDQogCS5kdF94bGF0ZQkJPSBhcm1fc21tdV9kdF94bGF0ZSwNCiAJLmFkZF9kZXZpY2UJ CT0gYXJtX3NtbXVfYWRkX2RldmljZSwNCisJLnJlbW92ZV9kZXZpY2UJCT0gYXJtX3NtbXVfcmVt b3ZlX2RldmljZSwNCiB9Ow0KIA0KIHN0YXRpYyBfX2luaXQgaW50IGFybV9zbW11X2R0X2luaXQo c3RydWN0IGR0X2RldmljZV9ub2RlICpkZXYsDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvYXJtL3NtbXUuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FybS9zbW11LmMN CmluZGV4IGQ2M2M5MDE1NTEuLjRkMmY3MWYxNTIgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy9w YXNzdGhyb3VnaC9hcm0vc21tdS5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0v c21tdS5jDQpAQCAtODI1LDcgKzgyNSw3IEBAIHN0YXRpYyBpbnQgYXJtX3NtbXVfZHRfYWRkX2Rl dmljZV9sZWdhY3koc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSwNCiAJaWYgKCAhZGV2X2lz X3BjaShkZXYpICkNCiAJew0KIAkJLyogWGVuOiBMZXQgWGVuIGtub3cgdGhhdCB0aGUgZGV2aWNl IGlzIHByb3RlY3RlZCBieSBhbiBTTU1VICovDQotCQlkdF9kZXZpY2Vfc2V0X3Byb3RlY3RlZChk ZXZfbm9kZSk7DQorCQlkdF9kZXZpY2Vfc2V0X3Byb3RlY3RlZChkZXZfbm9kZSwgdHJ1ZSk7DQog CX0NCiANCiAJZm9yIChpID0gMDsgaSA8IGZ3c3BlYy0+bnVtX2lkczsgKytpKSB7DQpAQCAtODYy LDcgKzg2Miw3IEBAIHN0YXRpYyBpbnQgYXJtX3NtbXVfZHRfcmVtb3ZlX2RldmljZV9sZWdhY3ko c3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSwNCiANCiAJaWYgKCAhZGV2X2lzX3BjaShkZXYp ICkNCiAJCS8qIFByb3RlY3RlZCBieSBkdF9ob3N0X2xvY2sgYW5kIGR0ZGV2c19sb2NrIGFzIGNh bGxlciBob2xkcyB0aGVzZSBsb2Nrcy4gKi8NCi0JCWRldl9ub2RlLT5pc19wcm90ZWN0ZWQgPSBm YWxzZTsNCisJCWR0X2RldmljZV9zZXRfcHJvdGVjdGVkKGRldl9ub2RlLCBmYWxzZSk7DQogDQog CWtmcmVlKG1hc3Rlcik7DQogCXJldHVybiAwOw0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hl bi9kZXZpY2VfdHJlZS5oIGIveGVuL2luY2x1ZGUveGVuL2RldmljZV90cmVlLmgNCmluZGV4IDA2 ZDc2NDM2MjIuLjc2YWUxZTY3NGEgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vZGV2aWNl X3RyZWUuaA0KKysrIGIveGVuL2luY2x1ZGUveGVuL2RldmljZV90cmVlLmgNCkBAIC0zMDAsOSAr MzAwLDEwIEBAIHN0YXRpYyBpbmxpbmUgZG9taWRfdCBkdF9kZXZpY2VfdXNlZF9ieShjb25zdCBz dHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmRldmljZSkNCiAgICAgcmV0dXJuIGRldmljZS0+dXNlZF9i eTsNCiB9DQogDQotc3RhdGljIGlubGluZSB2b2lkIGR0X2RldmljZV9zZXRfcHJvdGVjdGVkKHN0 cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2aWNlKQ0KK3N0YXRpYyBpbmxpbmUgdm9pZCBkdF9kZXZp Y2Vfc2V0X3Byb3RlY3RlZChzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmRldmljZSwNCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9vbCBwcm90ZWN0ZWQpDQogew0K LSAgICBkZXZpY2UtPmlzX3Byb3RlY3RlZCA9IHRydWU7DQorICAgIGRldmljZS0+aXNfcHJvdGVj dGVkID0gcHJvdGVjdGVkOw0KIH0NCiANCiBzdGF0aWMgaW5saW5lIGJvb2wgZHRfZGV2aWNlX2lz X3Byb3RlY3RlZChjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmRldmljZSkNCi0tIA0KMi41 NS4wDQo= From xen-devel-bounces@lists.xenproject.org Tue Oct 27 14:02:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 14:02:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462200.1673243 (Exim 4.92) (envelope-from ) id 1xLhkr-0002An-1Y; Tue, 27 Oct 2026 14:02:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462200.1673243; Tue, 27 Oct 2026 14: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 1xLhkq-0002Ag-Uf; Tue, 27 Oct 2026 14:02:20 +0000 Received: by outflank-mailman (input) for mailman id 1462200; Tue, 27 Oct 2026 14:02:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLhkp-00029V-S4 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:02:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLhkn-006s6k-Oc for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 15:02:17 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0aeda-8faa-0a2a0a5109dd-0a2a4502c90a-44 for ; Tue, 27 Oct 2026 15:02:17 +0100 Received: from [40.93.194.53] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0aee7-6ca4-0a2a45020019-285dc23555da-3 for ; Tue, 27 Oct 2026 15:02:17 +0100 Received: from CH0PR03CA0232.namprd03.prod.outlook.com (2603:10b6:610:e7::27) by DM3PR12MB9325.namprd12.prod.outlook.com (2603:10b6:0:46::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 14:01:57 +0000 Received: from BN1PEPF00018073.namprd04.prod.outlook.com (2603:10b6:610:e7:cafe::8a) by CH0PR03CA0232.outlook.office365.com (2603:10b6:610:e7::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Tue, 27 Oct 2026 14:01:56 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN1PEPF00018073.mail.protection.outlook.com (10.167.245.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 14:01: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.53; Tue, 27 Oct 2026 09:01:56 -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.53; Tue, 27 Oct 2026 09:01:55 -0500 Received: from APPOL-18KY0J4.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 27 Oct 2026 09:01: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=qXy9kQznZ+/tUTekcTHLOQVGnIZ9tdAS1e6jS0eLkYTUAHgyWXkrS3oEZjk+iaXdn2/DvuonL9iLcCFdh6RZrTperHkgYsWeoAJ/UHAjFsMXX4JQjTXX3o3OLPAv+sRahVZTzJKexwtG+qRNWj923a+xlVD4yiIXfxB84TJbSg/2lR+prBN/ibhu03UvDHXfuqwfNDLdErp+hbLD1nlaxPHEKa7WV+sutjPjEEfSBMH7XQ8HzBnl11YRazWGYWFe4goxrTI6NqPgvJCJm7arVTRG/lcK0ctuf8GDg6IlG/+hn4p3NecnbymQuJPjT9ZCcA5UsisCZuMHUQFT35bDpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vfx1sLfat0z31OyZ0i435/xRrzrAwm1ta/dChDVIAPU=; b=ECooy6thGGmHswODFowXBMoGfMDgK+jpuLpwDTLBSs2MmhPeLjriG559QLq5jHr/h+vfY79GFybWuoLzoZp+WL9vOeHVyf/FZTdksOcl32A2y200QUGjk5Of2OX9qK9kDZfSJj1seSMLRpewyPrJPDIQ+LQLVjzZOGd29x4DZazsg9yuF4BtLWx+G5bX+QKp8/y+SW9LkHpkTzC2/+BEzq7lTKOeWAW5KOGSxfXD++Elph+3OvJiDw5cHFLccsSxQqB2Vil/cAZTYgFD/0NDBx4rLqgkhih4TbHx2sztPPLS8RDGtlLf7v1WAKl5hMcLKnM/mYVE3QJ8UVQqI1ml7Q== 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=vfx1sLfat0z31OyZ0i435/xRrzrAwm1ta/dChDVIAPU=; b=2vabEF+1zypjWFqclm5k8lViFblPgNdNEAQ2/DrMVAXgzJD4PYPtgUzQKt/iJtHJ85F4wqA9lT/OvJPacp6QD1bzMgqjRbfgMsLEOSKI4LG2a2i1rKZXbinvAb6A8YOvlcXwlfJQ4ZXP3hTtw59ZAwJvPKv4uCcxScJXgsPKeQw= 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 From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: [PATCH] xen/dt: Drop unused function parameters Date: Tue, 27 Oct 2026 15:01:18 +0100 Message-ID: <20261027140118.176266-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: BN1PEPF00018073:EE_|DM3PR12MB9325:EE_ X-MS-Office365-Filtering-Correlation-Id: 25cf9c3d-a0ca-49c0-ad3e-08df3432dca3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|23010399003|376014|1800799024|18002099003|261026140227099003|261021121427099003|56012099006|11063799006|10067099003|261021123027099003|261009223027099003|261022105027099003|261022075727099003|261021135927099003|261026121527099003; X-Microsoft-Antispam-Message-Info: Z/biwJNxTLZjpDykNnCnKSI8cOksU3Owsp00OsVZxp+DVZOasciJSaR2+ArAsZ7l4mAc/9yFrn4XD/kpa++3Abik0cIIj5QrV+B0XEhGW7eq2hF2GEgVsmJU1lTOThzpiZBhg23bu2aTIMPt34p48KUKyN/xi2ekOVnCUHC4EkFVWbrvRhJy+Q0cprkROzl8pFJo+JjHXkiocKkp9AQLW8oXFNcl2CDuV1aet/E4ZtWI8Q5tAuWj5DTHUJzjr2KO10X/WNb1qj5QLoV4FI9cm/7fxv6AYGbJjCQu51qLJsOJYlglJ3gwURc3i1ue7jhymgrraPd49qExvpCi4fmirHRFu0M7yWPeu1un+05T94LF9q5vPdmFXq5F1VeotUXbXtfj/oDg73dPNVHrObHIGevpGQ0BHFC2szhDKWQ3JvWz3jWmgU5KgjbgDxK6J5N6LPV+DIiXgwmePySxX+xCC36NCIgPFKiDlxKmB8j/KNyPTFaTuqO6qAI3857IP2n8kBPh534zKCQQpULHLnfMdA3vIZeh6CKkp/xNdlZ0cEYQIk9maA2VxGAzv9/y0Q5WO8uNV2+unhEQPsgDKCzr9ESGeLoabmpudF2n0lJ8aCFcDobEZ58zsxVXcE5tCkKOp0YfwqPGc7mqVZ4b3ZXwrQDvCFZYOSV8EQfwmfLgeDWmSBLwOHcqtXLxbcQatmmZbMHmDRODqRhqmTC298pGfw== 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)(23010399003)(376014)(1800799024)(18002099003)(261026140227099003)(261021121427099003)(56012099006)(11063799006)(10067099003)(261021123027099003)(261009223027099003)(261022105027099003)(261022075727099003)(261021135927099003)(261026121527099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: GpTHMYhlNsNYhGYByLQmzvFQbuoIsw4uYNZapfXvBnsMRgXi5jFxTAQjmZn+BhslcztR0T0cjoIiusWoSUkfiIb5CP65BCd/kjfgYtPIRVBsNUG1D0LZ/7IxDiMiQ9g7YBpT3l3YQrpBkhIrUpxd2PmmufaNYST7SalSC0IhLMewtv9Bk0JqKcXh2CfYJvakfkwwHldsh9hjGKMgwz0cxo/cYc5RRsfMsybm3sVERLkC4RmKikK77pfUqHbcfjc1QaacRHjFde6VKIxh3X3g2OQo8FRuApEwmy/K0Uh9XD7MGZt5YEwT8IXm5cEiVwJPTRqH45Otd4dfaWTG8gdp59fyXB8iSaNL71ERz+HQWXDX/uSwQtJrBHkIAsdxQiJXSQO26NTqULTXwo0ffOKTfboK4Qol3VTocvssoUYyAlrurmbdU2SYY8k8dmfFnOy6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 14:01:56.4158 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 25cf9c3d-a0ca-49c0-ad3e-08df3432dca3 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: BN1PEPF00018073.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9325 X-purgate-ID: tlsNG-720697/1793109737-30DC12AC-394D02A1/0/0 X-purgate-type: clean X-purgate-size: 4291 - drop `name` and `depth` from process_memory_node(), - drop `name`, `depth`, `address_cells` and `size_cells` from process_reserved_memory(), - drop `name` from process_chosen_node() and process_domain_node(). No functional change. Signed-off-by: Michal Orzel --- xen/common/device-tree/bootinfo-fdt.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c index 94ebf12fd646..1064cea4e9b4 100644 --- a/xen/common/device-tree/bootinfo-fdt.c +++ b/xen/common/device-tree/bootinfo-fdt.c @@ -171,7 +171,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node, } static int __init process_memory_node(const void *fdt, int node, - const char *name, int depth, u32 address_cells, u32 size_cells, struct membanks *mem) { @@ -191,8 +190,7 @@ static int __init process_reserved_memory_node(const void *fdt, int node, if ( depth != 1 ) return 0; - rc = process_memory_node(fdt, node, name, depth, address_cells, - size_cells, data); + rc = process_memory_node(fdt, node, address_cells, size_cells, data); if ( rc == -ENOSPC ) panic("Max number of supported reserved-memory regions reached.\n"); @@ -201,9 +199,7 @@ static int __init process_reserved_memory_node(const void *fdt, int node, return 0; } -static int __init process_reserved_memory(const void *fdt, int node, - const char *name, int depth, - u32 address_cells, u32 size_cells) +static int __init process_reserved_memory(const void *fdt, int node) { return device_tree_for_each_node(fdt, node, process_reserved_memory_node, @@ -279,7 +275,6 @@ static void __init process_multiboot_node(const void *fdt, int node, } static int __init process_chosen_node(const void *fdt, int node, - const char *name, u32 address_cells, u32 size_cells) { const struct fdt_property *prop; @@ -343,7 +338,6 @@ static int __init process_chosen_node(const void *fdt, int node, } static int __init process_domain_node(const void *fdt, int node, - const char *name, u32 address_cells, u32 size_cells) { const struct fdt_property *prop; @@ -389,18 +383,17 @@ static int __init early_scan_node(const void *fdt, */ if ( !efi_enabled(EFI_BOOT) && device_tree_is_memory_node(fdt, node, depth) ) - rc = process_memory_node(fdt, node, name, depth, - address_cells, size_cells, bootinfo_get_mem()); + rc = process_memory_node(fdt, node, address_cells, size_cells, + bootinfo_get_mem()); else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") ) - rc = process_reserved_memory(fdt, node, name, depth, - address_cells, size_cells); + rc = process_reserved_memory(fdt, node); else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) || device_tree_node_compatible(fdt, node, "multiboot,module" ))) process_multiboot_node(fdt, node, name, address_cells, size_cells); else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") ) - rc = process_chosen_node(fdt, node, name, address_cells, size_cells); + rc = process_chosen_node(fdt, node, address_cells, size_cells); else if ( depth == 2 && device_tree_node_compatible(fdt, node, "xen,domain") ) - rc = process_domain_node(fdt, node, name, address_cells, size_cells); + rc = process_domain_node(fdt, node, address_cells, size_cells); else if ( depth <= 3 && device_tree_node_compatible(fdt, node, "xen,domain-shared-memory-v1") ) rc = process_shm_node(fdt, node, address_cells, size_cells); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 14:08:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 14:08:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462212.1673251 (Exim 4.92) (envelope-from ) id 1xLhqg-0002y9-ND; Tue, 27 Oct 2026 14:08:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462212.1673251; Tue, 27 Oct 2026 14:08: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 1xLhqg-0002y2-Kh; Tue, 27 Oct 2026 14:08:22 +0000 Received: by outflank-mailman (input) for mailman id 1462212; Tue, 27 Oct 2026 14:08:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLhqf-0002xw-KA for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:08:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xLhqf-0000000GREW-2D3G; Tue, 27 Oct 2026 14:08: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.98.2) (envelope-from ) id 1xLhqf-000000031qU-0ZSF; Tue, 27 Oct 2026 14:08: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=/IFxrvO/QyB13axdXdeqAsYL0qIlyGHknuq2EgtFIPk=; b=ZFbGjFGse6I3+0SvE74nvag96W uj/+FvwldTVNuEZlXYLXlfeSso+e8QEZ8p7A0hwanD7qKWAZd7coileStsba1PqhHHXkOu/KRMHqH smJI6aJHm0qHegXuKV9h8Jj8qlTG9ux8aAuF3SCHdDiVlXZsDZvZ+y2mmMgBDtAlg5xw=; Date: Tue, 27 Oct 2026 15:08:18 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH] x86/kexec: Annotate more noreturns Message-ID: References: <20261006105445.511099-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: <20261006105445.511099-1-andrew.cooper3@citrix.com> On Tue, Oct 06, 2026 at 11:54:45AM +0100, Andrew Cooper wrote: > kexec_reloc() does not return. Plumbing this property upwards lets us mark > machine_kexec() and machine_reboot_kexec() noreturn too. > > Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Oct 27 14:20:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 14:20:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462219.1673261 (Exim 4.92) (envelope-from ) id 1xLi2E-0005kM-N3; Tue, 27 Oct 2026 14:20:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462219.1673261; Tue, 27 Oct 2026 14: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 1xLi2E-0005kF-KO; Tue, 27 Oct 2026 14:20:18 +0000 Received: by outflank-mailman (input) for mailman id 1462219; Tue, 27 Oct 2026 14:20:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLi2D-0005k9-Ba for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:20:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLi2C-006wlr-C3 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 15:20:16 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0b31b-2eae-0a2a0a5409dd-0a2a4509d152-28 for ; Tue, 27 Oct 2026 15:20:16 +0100 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0b320-be1a-0a2a45090019-d155802ec58c-3 for ; Tue, 27 Oct 2026 15:20:16 +0100 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a20a37703bso32493305e9.1 for ; Tue, 27 Oct 2026 07:20:16 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ebcb9cesm24210505f8f.27.2026.10.27.07.20.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 07:20: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=1793110815; x=1793715615; 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=x91tNUCmNoQh58/o7wKid6hcocDTO4IZ8Jm7zMD4Bqc=; b=IeNEgX3+/dGZZKtBwljeRUplR1BjMM5cgcPYuXUFxhGxwpU1jwuED//s9kupQ71Yzu DhLcTqoqm/X4/xqhCpw16XkMQOsHJfI1O2muhmJssex9pSwKhUJNQbNLwCE6orEjvMb6 wrIChkcUFl/FteEn0Nm45p2uMXSVMsUKJJgmAu0Vh7zfu/LJVFUxoWZvf4ffLbkQMJRf JeEsMC8pfORJoxbrrlx2hBR5WSKC4Ki7DPGLxrzT1QXtnFIzTdybgLaxv7iYC5I3t+2t 5ZnFAQVWO9YjoiuHQ1vbtgyEdE2QnS030m9BXQ0gStojJWgiZzAd1oR5n5IsOcQjf1yL jQbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793110815; x=1793715615; 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=x91tNUCmNoQh58/o7wKid6hcocDTO4IZ8Jm7zMD4Bqc=; b=ddKiWr9XGMM0wZXCgCwqED6NEG3EGruMHZDIdnUvDxON+S8DrzhKS68ecbl9p7qNnZ Bim7fsiKIyDIZW1MGwCPghsHQTQOf7914VbeuMdDqS0oVaJC6+0zICiv6/obXqhh1OxQ IpFPnTV9yVREEIulSAYmSRaD/gejO3gmGyqJ7OkTH8h2P6cGrRIQlmBi9Xj010SjX1vk 37ael43Dfis5QvBmO/8XCniWfidevaDRmjsNZ5TZB7UMGyC1lxGaG2coIQnWu07/WEQ1 tLocTguSqZKyrOH9r4xFjiwS5T1JMZB9jJheniaBcNMHA6Fz5Q1m/6c2IE402oXg4Arm RKlA== X-Forwarded-Encrypted: i=1; AKwUvBzRztmwArLQ8MKVryEvC4DsGv1xoEvTZVd+CRE273EOkimC5kznlsjx9Z4+9lTWhq/vtgI3EGy6CRI=@lists.xenproject.org X-Gm-Message-State: AFq9FYKYQrUvd2Gwvuk7swLcA9s/x21j007Tvg+XUNW0DIWJm+XFYWbM J7Mp8jURqc7s60MW5pcBEDyvvKkQoeGjNoMI4uHBIvSLfI3XugWvDz7U X-Gm-Gg: AYBFou2T8AojHAebzwFtSQgZ8E194FaAdI1E5gS3DNu9HvbQZJq1tMWGTReUVmD4blr ryuvZPbIVQcQe5TRd0p1c2nhTNs2KO/eoY1k/voUs/R8hwpM8lHRuffZ+NGS1sz73+X6l4/6ra4 ZBGzKNpNKJBQart0KY5gStD3gZATSUBkOrpKRxmwz92uY2vI/G3TRFLBuza8MRorSKO+joN72Zg usfhRIMMK1ryNV+DwKrKH8b5NfRNGM0c7hPNBSpJaGKwhHxYt32B16Vw+8YKGOYURzPFj9szN/N IH3Yjhhe1axL/H5DjJKOFUWvJE7/xyUK2gXfzIzS9sMsb1gNH1lHzBP4E8RVah/tP8aAdMQ6CsU eTQnl/gT5JAZ7demzZ8zIka0YRNiWtIygme98G9Ees9sRE/JM+UqoRescbMdUoSQnSQLHToBwP6 /TgKq+pMAEd118QOD6IV8bkkRouXNFCRHZYkcw3+4/IF1KiHkmqmoWeQcm0RYV+7hcilhTx60Ux tlBLmRFDfdsrNJz6Y9wuAeXceSEzl62WW1tkWVCravKv3HA8yBlIz7BETz9nhg2TJcHZAwdoUHs Cz8IujXfbGhH9LND+w9zF2qf4zjn X-Received: by 2002:a05:600c:621b:b0:4a2:59:f568 with SMTP id 5b1f17b1804b1-4a35ac95a53mr186795355e9.14.1793110815139; Tue, 27 Oct 2026 07:20:15 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 15:20:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/dt: Drop unused function parameters To: Michal Orzel , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis References: <20261027140118.176266-1-michal.orzel@amd.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20261027140118.176266-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1793110816-3A2C4034-5BAFCF4F/10/73395122804 X-purgate-type: spam X-purgate-size: 438 On 10/27/26 3:01 PM, Michal Orzel wrote: > - drop `name` and `depth` from process_memory_node(), > - drop `name`, `depth`, `address_cells` and `size_cells` from > process_reserved_memory(), > - drop `name` from process_chosen_node() and process_domain_node(). > > No functional change. > > Signed-off-by: Michal Orzel LGTM: Reviewed-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Oct 27 15:02:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 15:02:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462236.1673269 (Exim 4.92) (envelope-from ) id 1xLign-0003QH-PM; Tue, 27 Oct 2026 15:02:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462236.1673269; Tue, 27 Oct 2026 15:02: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 1xLign-0003QA-Mf; Tue, 27 Oct 2026 15:02:13 +0000 Received: by outflank-mailman (input) for mailman id 1462236; Tue, 27 Oct 2026 14:54:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLiZI-0002Fk-H0 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 14:54:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLiZH-004Zki-UF for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 15:54:27 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0bb1d-bab6-0a2a0a5309dd-0a2a4509aca0-26 for ; Tue, 27 Oct 2026 15:54:27 +0100 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 6ae0bb22-be1a-0a2a45090019-aa0a857c4e8d-3 for ; Tue, 27 Oct 2026 15:54:27 +0100 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-192-nyqVetLPM2uBg4ZbpUvWIg-1; Tue, 27 Oct 2026 10:54:19 -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 56DB7195411B; Tue, 27 Oct 2026 14:54:11 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.2]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4F9C31800495; Tue, 27 Oct 2026 14:54:06 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id CEB8121E6A04; Tue, 27 Oct 2026 15:54:03 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-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=1793112866; 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=bkID89a/6OklaXaMWn8rSBHoX2XDYtn2gJ9CrOvW2W4=; b=Qad7e6l5K6yFAqY9KwewCpfZCID+eIFqAkdN71fCAiB0i/8cf/h3fvojyDp3Zakm2nJMzI qmALLLR4cL7gRQTJ2h8CTYRowZ20omrKSvFGH5m+Kmvqv8swc9LO+vMZpcWIg9/kbApPrI i9sceznoPtIcaKKhI6tL84F8NGBKX7M= X-MC-Unique: nyqVetLPM2uBg4ZbpUvWIg-1 X-Mimecast-MFC-AGG-ID: nyqVetLPM2uBg4ZbpUvWIg_1793112855 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: Daniel P. =?utf-8?Q?Berrang=C3=A9?= , qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type In-Reply-To: (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Fri, 23 Oct 2026 15:39:22 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> Date: Tue, 27 Oct 2026 15:54:03 +0100 Message-ID: <87zevz5h4k.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: 91Y4Tj9o-zW5oQO_m_1de6uyDcPWRpGuWWaU5IKLys4_1793112855 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1793112867-39EC6034-AC7D13AC/0/0 X-purgate-type: clean X-purgate-size: 11369 Marc-Andr=C3=A9 Lureau writes: > Hi > > On Fri, Oct 23, 2026 at 2:04=E2=80=AFPM Daniel P. Berrang=C3=A9 wrote: >> >> On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-Andr=C3=A9 Lureau wrote: >> > PciDevfn is a bit special, since it accepts integer and string as >> > setter, but only output integer as getter. Yes. See below. >> > Unfortunately, we can't declare an alternate str|int QAPI type for it, >> > since: branch 'string' can't be distinguished from 'integer' Yes, except with trickery; more on this below. >> > >> > Rather than declaring it as "str", use the common type instead. >> > >> > Signed-off-by: Markus Armbruster >> > Signed-off-by: Marc-Andr=C3=A9 Lureau >> > --- >> > hw/core/qdev-properties-system.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-propertie= s-system.c >> > index 5bfdfe1ab9d9..3381de1144d6 100644 >> > --- a/hw/core/qdev-properties-system.c >> > +++ b/hw/core/qdev-properties-system.c >> > @@ -904,7 +904,8 @@ static char *print_pci_devfn(Object *obj, const Pr= operty *prop) >> > } >> > >> > const PropertyInfo qdev_prop_pci_devfn =3D { >> > - .type =3D "str", >> > + /* The formatted string accepted by the setter is a CLI convenien= ce. */ >> >> IIUC, this is not limited to the CLI, it will work anywhere the JSON >> syntax is permitted which is both CLI and QMP. >> >> libvirt uses this string syntax: >> >> -device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2",= "bus":"pcie.0","multifunction":true,"addr":"0x1.0x1"}' \ >> >> > + .type =3D "int32", >> > .description =3D "Slot and optional function number, example: 06.= 0 or 06", .print =3D print_pci_devfn, .get =3D qdev_propinfo_get_int32, .set =3D set_pci_devfn, .set_default_value =3D qdev_propinfo_set_default_value_int, }; The property is backed by an int32_t. In include/hw/core/qdev-properties-system.h: #define DEFINE_PROP_PCI_DEVFN(_n, _s, _f, _d) \ DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_pci_devfn, int32_t) It's only ever used for PCI device property "addr". Its .get() simply visits it. This is why qom-get returns an integer: --> {"execute":"qom-get","arguments":{"path":"/machine/unattached/devic= e[4]/pm", "property": "type"}} <-- {"return": "PIIX4_PM"} --> {"execute":"qom-get","arguments":{"path":"/machine/unattached/devic= e[4]/pm", "property": "addr"}} <-- {"return": 11} Its .set() is a handwritten visit of an alternate of 'str' and 'int32', where 'str' gets parsed as DEV.FN into int32. This is why QMP device_add accepts both JSON string and JSON number (HMP device_add and -device only do string). QAPI doesn't let us define such an alternate type, as you wrote in your commit message, but handwritten visits fly below that radar. This is of course too clever by half. Goes back to commit 768a9ebe188 (qdev: accept both strings and integers for PCI addresses) in v1.1. Its .print() prints it like DEV.FN. Its only user is "info qtree". >> Changing the type to 'int32', where 99% of usage is input only >> and string based, is pretty unpleasant. Even more so that the >> description doesn't even mention encoding dev+function as an >> integer. > > This is purely a metadata change, the setter still accepts both str & > int, Yes. .type is only used as @type argument for object_class_property_add() and object_property_add(). They store it in ObjectProperty member @type. Visible externally in QOM introspection (ObjectPropertyInfo and ObjectPropertyValue member type). Also in help, but let's ignore that for a minute. Before the series, QOM instrospection shows type "str" for PCI device property "addr". For reading, that's a lie: qom-get and qom-list-get return an JSON integer, not a JSON string. For writing, it's merely incomplete: qom-set accepts a JSON string in addition to a JSON integer. Does it matter? To make use of QOM introspection's type, you have to hardcode so much silly stuff, what's one more case? With this patch, it shows type "int32". Less wrong. Again, does it matter? The change could conceivably break a client. I figure the risk is small. Is "less wrong" worth even a small risk? > so I don't think this change blocks this series. I figure it's no worse than the other type values the series changes. Let's discuss them under my Subject: Property types changed in this series (was: [PATCH v7 00/65] H= i) Date: Wed, 21 Oct 2026 18:29:40 +0200 Message-ID: <87tsmfkoej.fsf@pond.sub.org> > But I agree we > could do better. > > There are multiple options. We could keep declaring the property as > str instead. In this case, the getter should probably return a string > for consistency and correctness. This might surprise some existing > users though. I.e. ditch numeric suppport for numeric addresses, right? Incompatible change. Do we care? If we don't, we should be honest about it and mark qom-get unstable. > We could introduce new properties like `devfn-str` and `devfn-int` > that alias the same value. Compatibility break. If breaking compatibility is okay, I'd rather use the opportunity to get rid of cleverness, and go with your first option. > We could also introduce a new structured QAPI type. What kind of type do you have in mind? > Markus, what's your take? >From a QAPI/QMP point of view, the clean way to support "either string or numeric address" is an alternate type. Trouble is the generator rejects such an alternate, as you pointed out in your commit message. Why is that? docs/devel/qapi-code-gen.rst: An alternate type is like a union type, except there is no discriminator on the wire. Instead, the branch to use is inferred from the value. An alternate can only express a choice between types represented differently on the wire. So, we can't have two 'str' branches (both JSON string), or a 'str' and an 'enum' branch (same). But 'int32' and 'str' are different on the wire (JSON number and JSON string), so what's going on? This: commit c0644771ebedbd8f47f3c24816445e30111d226b (tag: pull-qapi-2017-05-31) Author: Markus Armbruster Date: Mon May 22 18:42:15 2017 +0200 qapi: Reject alternates that can't work with keyval_parse() =20 Alternates are sum types like unions, but use the JSON type on the wire / QType in QObject instead of an explicit tag. That's why we require alternate members to have distinct QTypes. =20 The recently introduced keyval_parse() (commit d454dbe) can only produce string scalars. The qobject_input_visitor_new_keyval() input visitor mostly hides the difference, so code using a QObject input visitor doesn't have to care whether its input was parsed from JSON or KEY=3DVALUE,... The difference leaks for alternates, as noted in commi= t 0ee9ae7: a non-string, non-enum scalar alternate value can't currently be expressed. =20 In part, this is just our insufficiently sophisticated implementation. Consider alternate type 'GuestFileWhence'. It has an integer member and a 'QGASeek' member. The latter is an enumeration with values 'set', 'cur', 'end'. The meaning of b=3Dset, b=3Dcur, b=3Dend, b=3D0, = b=3D1 and so forth is perfectly obvious. However, our current implementation falls apart at run time for b=3D0, b=3D1, and so forth. Fixable, but n= ot today; add a test case and a TODO comment. =20 Now consider an alternate type with a string and an integer member. What's the meaning of a=3D42? Is it the string "42" or the integer 42? Whichever meaning you pick makes the other inexpressible. This isn't just an implementation problem, it's fundamental. Our current implementation will pick string. =20 So far, we haven't needed such alternates. To make sure we stop and think before we add one that cannot sanely work with keyval_parse(), let's require alternate members to have sufficiently distinct representation in KEY=3DVALUE,... syntax: =20 * A string member clashes with any other scalar member =20 * An enumeration member clashes with bool members when it has value 'on' or 'off'. =20 * An enumeration member clashes with numeric members when it has a value that starts with '-', '+', or a decimal digit. This is a rather lazy approximation of the actual number syntax accepted by the visitor. =20 Note that enumeration values starting with '-' and '+' are rejected elsewhere already, but better safe than sorry. =20 Signed-off-by: Markus Armbruster Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake Reviewed-by: Marc-Andr=C3=A9 Lureau However, keyval_parse() + its input visitor can't express everything QAPI even with such alternates outlawed. From util/keyval.c: * Design flaw: there is no way to denote an empty array or non-root * object. While interpreting "key absent" as empty seems natural * (removing a key-val from the input string removes the member when * there are more, so why not when it's the last), it doesn't work: * "key absent" already means "optional object/array absent", which * isn't the same as "empty object/array present". * * Design flaw: scalar values can only be strings; there is no way to * denote numbers, true, false or null. The special QObject input * visitor returned by qobject_input_visitor_new_keyval() mostly hides * this by automatically converting strings to the type the visitor * expects. Breaks down for type 'any', where the visitor's * expectation isn't clear. Code visiting 'any' needs to do the * conversion itself, but only when using this keyval visitor. * Awkward. Note that we carefully restrict alternate types to avoid * similar ambiguity. We commonly use keyval syntax together with JSON: if the input starts with '{', it's assumed to be JSON, else keyval. See qobject_input_visitor_new_str(). This lets you fall back to JSON when keyval can't express what you want. Beware, there *are* uses of keyval without a JSON fallback. As the commit message I quoted says, we could permit alternates that are ambiguous with keyval. The keyval visitor could then pick a branch (you can't express the others), or it could refuse to pick (you can't express any of them). In the particular case of PCI device property "addr", picking str would be fine: same behavior as the handwritten visit in in set_pci_devfn(). But once we permit such alternates, nothing but conscientious testing with keyval syntax will stop us from adding interfaces that don't work or work the wrong way. Hmm. I need to think about this some more if we want to explore this direction. [...] From xen-devel-bounces@lists.xenproject.org Tue Oct 27 15:11:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 15:11:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462247.1673279 (Exim 4.92) (envelope-from ) id 1xLipU-0005C1-LQ; Tue, 27 Oct 2026 15:11:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462247.1673279; Tue, 27 Oct 2026 15:11: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 1xLipU-0005Bu-Im; Tue, 27 Oct 2026 15:11:12 +0000 Received: by outflank-mailman (input) for mailman id 1462247; Tue, 27 Oct 2026 15:09:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLio1-0004AA-Jt for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 15:09:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLio0-0030Uy-Px for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 16:09:40 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0beac-bab6-0a2a0a5309dd-0a2a4507dc46-36 for ; Tue, 27 Oct 2026 16:09:40 +0100 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 6ae0beb3-b4ea-0a2a45070019-aa0a857c7109-3 for ; Tue, 27 Oct 2026 16:09:40 +0100 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-438-7XFlFRhPPtuZJx-cX-8Sxg-1; Tue, 27 Oct 2026 11:09:34 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 46A391954B0B; Tue, 27 Oct 2026 15:09:28 +0000 (UTC) Received: from redhat.com (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E918918002B1; Tue, 27 Oct 2026 15:09: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=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=1793113779; 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=YxsqXTT/2SkHCopDBU3zcdHUWKG0aEgc5S4iUgZigFw=; b=EMLjalLGTYrNlCmGo2atTSKdh+ic+WcxN8E92twoOTqF6Og6d7Ro1qC5G68B9x+KITzduw qiYY1++St98785pl7l2SO/CwiUAv/+7ZqPLTHo6xDN2dpBAexTzzjZeL5IPdb2fNqv7OC5 4yce7LK74VH32Pa60OAsm6URxDJgQqY= X-MC-Unique: 7XFlFRhPPtuZJx-cX-8Sxg-1 X-Mimecast-MFC-AGG-ID: 7XFlFRhPPtuZJx-cX-8Sxg_1793113770 Date: Tue, 27 Oct 2026 15:08:58 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Markus Armbruster Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> <87zevz5h4k.fsf@pond.sub.org> MIME-Version: 1.0 In-Reply-To: <87zevz5h4k.fsf@pond.sub.org> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: mQ8bNV-fIRDeTLG1M-bytuz87OfuxQ-PSBI2t19bn2g_1793113770 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793113780-362C4AE4-A878F55A/0/0 X-purgate-type: clean X-purgate-size: 2583 On Tue, Oct 27, 2026 at 03:54:03PM +0100, Markus Armbruster wrote: > Marc-André Lureau writes: > > > Hi > > > > On Fri, Oct 23, 2026 at 2:04 PM Daniel P. Berrangé wrote: > >> > >> On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-André Lureau wrote: > >> > PciDevfn is a bit special, since it accepts integer and string as > >> > setter, but only output integer as getter. snip > > But I agree we > > could do better. > > > > There are multiple options. We could keep declaring the property as > > str instead. In this case, the getter should probably return a string > > for consistency and correctness. This might surprise some existing > > users though. > > I.e. ditch numeric suppport for numeric addresses, right? > > Incompatible change. Do we care? > > If we don't, we should be honest about it and mark qom-get unstable. > > > We could introduce new properties like `devfn-str` and `devfn-int` > > that alias the same value. > > Compatibility break. If breaking compatibility is okay, I'd rather use > the opportunity to get rid of cleverness, and go with your first option. > > > We could also introduce a new structured QAPI type. > > What kind of type do you have in mind? IMHO the root cause design flaw here was to overload 'addr' as a way to set both the slot number and function number, as using one property for two pieces of data is a well known anti-pattern we caution against. IOW, we should have had 'slot' and 'function' as separate properties from the start. >From a CLI POV, we could easily change 'addr' to mean only the slot number, since it is always parsed in string format without the magic (slot << 4) | function encoding. Then add a 'function' prop The challenge is the impact on QMP with strict typing, as ideally int format would soley represent the slot number, but today the int format is encoded (slot << 4) | function. So anyone relying on int format in QMP would silently have a semantic change if we altered what 'addr' means. Deprecating 'addr' entirely and adding brand new 'slot' and 'function' properties would be a significant disruption to a syntax which has been documented for years (decades). 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 Tue Oct 27 16:00:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 16:00:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462279.1673288 (Exim 4.92) (envelope-from ) id 1xLjbD-0004p0-7q; Tue, 27 Oct 2026 16:00:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462279.1673288; Tue, 27 Oct 2026 16:00: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 1xLjbD-0004os-3q; Tue, 27 Oct 2026 16:00:31 +0000 Received: by outflank-mailman (input) for mailman id 1462279; Tue, 27 Oct 2026 16:00:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLjbB-0004lJ-LG for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 16:00:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLjbA-003Aeq-TU for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 17:00:28 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ca8f-bab6-0a2a0a5309dd-0a2a450ad92a-26 for ; Tue, 27 Oct 2026 17:00:28 +0100 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0ca9b-f2d2-0a2a450a0019-d1558030dd04-3 for ; Tue, 27 Oct 2026 17:00:27 +0100 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a2084d62cdso33987595e9.1 for ; Tue, 27 Oct 2026 09:00: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-4a35a06da5fsm181873905e9.3.2026.10.27.09.00.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 09:00: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: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=1793116827; x=1793721627; 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=8U5GvTpkVic94/1J/YTWB4OnxFRMVDxVMye/dFrKuVM=; b=SuXZliYBECKEKgm9N4Y6UMP9yUCLZ4p4cPBcbAbU/KAv1OhhjubgPC8l83JsLGKyyp NScXoKIBDS/9rds8zNXVUGhW9qGQBS9L/gclzgPanoHR2hcOE7H51uQbemujAtT0N5JK gFaxy7u3TdUfggF5bwL7jloAr4oUQEnXr6hXQN+yjdRMhDF18IBNLbEEokETl96xtUoV yqb0nt+sQm55RUCz41v2gklOWogOn61OyX//u+RHDCmkmNQwYOiT5+0OPOk+1E3bPuZ2 ZafOmwXhiqs9zIAdfv7LGE1/CM2p0QXDRK9F8fucFLCOrgvE1RYdRFiBk4nD5Gxx/Mxa IZpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793116827; x=1793721627; 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=8U5GvTpkVic94/1J/YTWB4OnxFRMVDxVMye/dFrKuVM=; b=j8iUVhxH3JoeTz/HsueckOpAp8ZPMFzxCoYPxE1cAdPbfWR/6gbTBxeHVY0aCl5Nqj 9GJUXe/9W1QMm3y2HxedU4kN9W1QOUCKea978+u3A3M5S7arqUJFtwJxXO8+5VfNq8bi tTv2c+WAYACItYcLBcJ5QrFZQGVElzhF5YBRo8sgfxszqMSPoLXPckb+kDv7X0nEdUzm t+RBV5xOuXwCOzYiuC34roDo+fbIY8ZY1hz2I/NYh6TQ3jYOgUfl2kBCliub5pjyv7U3 qeEN7tidgXaSKi3c/jtNaRqZ9fRTSEj/cF9KjXAP1wAwk6R5OnvjjeXQqbLkZv9frbVL Hs/w== X-Gm-Message-State: AFq9FYL77WzYGKbGRR4AnhscCXgsF21WPxYLBU2yjgUZLnQzIM5hpG51 KAdcfAXQ3pteGZvRZS3cp67vVWJYElmwQjpDTY1whX14DNobDrN6DUs32zoiY92re4Am8uanq3p 0wExjYg== X-Gm-Gg: AYBFou3BmMdmzAB7yix1E2MjP1NX6bJR1ihm7zk5C5kKFKk4jc0oJpMJnjZCPNlBFU0 DBiOi6GAW6Sh8T75mvRzN5P8TNKtjxingrvpL3h6aChxvFd+gaEV2HwKbJcJ+STZlB13dPlV5f4 n1rUQKuY7ZoHU9A0+qwBwAptsfllK4ojt+xKiFKHveQbS3N/1cTc1DB0ZIL9591lC2lnrl35S1p T1zta20pOoBxw41O7a9Rt9vk7isVmQtUtzWValiLRZ//l3CxXXCHqirUbRaUROMjTFkW/4gRLsy 3iGr/lZlFEKc6KqG9QuQ2bje/UK4qnfGgq+74IAswvZe1P0e9h+g33jWgjGzryOFJKh/Wx3hfkv tr2ozFRYZoL1Uv7Eq3zCP+XEOFxr+4Zx3DeFwLA0izN3fs4TxlfT5GYgZAOF32vDNmdkPRVJ5tz g0SSXsYJGPCYv+jQxFA3FByCvZhTxMHg2cKZX8NKdQ4QZOFJNmb0DXTVBxtVvNzcgahw2yQpxnk Vbctphbb8zD2I8EqAOCvZVH9Z9hnLDtOCYClAyl77/iLfMQTCcrgY9WvcazrEY5dWOTjphYTwc1 u6j3rWhre0BeWgaCSIt6YHvhq9h/MNn30WVMiW4tADU= X-Received: by 2002:a05:600c:524c:b0:4a0:1c94:7042 with SMTP id 5b1f17b1804b1-4a35ac8bdc6mr197087525e9.8.1793116825984; Tue, 27 Oct 2026 09:00:25 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 17:00:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Anthony PERARD , Juergen Gross , msd-xenproject.org@msd.im From: Jan Beulich Subject: [PATCH] libxl: simplify and correct domain ID and CPU pool ID parsing Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1793116827-524DFCFC-A1D8B175/10/78276251493 X-purgate-type: spam X-purgate-size: 2554 strtoul(), with a radix of 10, already guarantees that the string parsed consists of just digits (and leading whitespace). No need to do that check in advance. All which needs doing is a check for a leading digit, to exclude the case of leading whitespace. This in particular avoids a domain ID argument of "" to be mis-treated as a reference to Dom0. While similar mis-treatment isn't present there, do the same simplification also in the adjacent qualifier_to_id(). Fixes: ef496b81f033 ("libxl: postpone backend name resolution") Reported-by: Msd Signed-off-by: Jan Beulich --- This retains prior behavior as to leading (and trailing) whitespace (none permitted). Whether that's intended behavior I don't know. The "end != ..." checks are likely paranoia: If the first character is a digit as per isdigit(), strtoul() should have consumed it. Likely there are more similar issues elsewhere, as many invocations of strto*() pass NULL as endptr argument. --- a/tools/libs/light/libxl_utils.c +++ b/tools/libs/light/libxl_utils.c @@ -91,16 +91,16 @@ int libxl_name_to_domid(libxl_ctx *ctx, int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, const char *name, uint32_t *domid) { - int i, rv; - for (i=0; name[i]; i++) { - if (!CTYPE(isdigit, name[i])) { - goto nondigit_found; - } + int rv; + + if (CTYPE(isdigit, *name)) { + char *end; + + *domid = strtoul(name, &end, 10); + if (end != name && !*end) + return 0; } - *domid = strtoul(name, NULL, 10); - return 0; - nondigit_found: /* this could also check for uuids */ rv = libxl_name_to_domid(ctx, name, domid); return rv; @@ -108,22 +108,15 @@ int libxl_domain_qualifier_to_domid(libx static int qualifier_to_id(const char *p, uint32_t *id_r) { - int i, alldigit; + if (CTYPE(isdigit, *p)) { + char *end; - alldigit = 1; - for (i = 0; p[i]; i++) { - if (!isdigit((uint8_t)p[i])) { - alldigit = 0; - break; - } + *id_r = strtoul(p, &end, 10); + if (end != p && !*end) + return 0; } - if (i > 0 && alldigit) { - *id_r = strtoul(p, NULL, 10); - return 0; - } else { - /* check here if it's a uuid and do proper conversion */ - } + /* check here if it's a uuid and do proper conversion */ return 1; } From xen-devel-bounces@lists.xenproject.org Tue Oct 27 16:13:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 16:13:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462293.1673298 (Exim 4.92) (envelope-from ) id 1xLjo2-0006l8-B5; Tue, 27 Oct 2026 16:13:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462293.1673298; Tue, 27 Oct 2026 16: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 1xLjo2-0006l1-7h; Tue, 27 Oct 2026 16:13:46 +0000 Received: by outflank-mailman (input) for mailman id 1462293; Tue, 27 Oct 2026 16:13:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLjo1-0006kv-9c for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 16:13:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLjo0-00H8XC-Mi for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 17:13:44 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0cdac-8faa-0a2a0a5109dd-0a2a4505d1da-30 for ; Tue, 27 Oct 2026 17:13:43 +0100 Received: from [209.85.208.53] (helo=mail-ed1-f53.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0cdb7-4cb1-0a2a45050019-d155d035d407-3 for ; Tue, 27 Oct 2026 17:13:43 +0100 Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-6af9a9451daso120220a12.0 for ; Tue, 27 Oct 2026 09:13: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-6b497ff5fddsm183154a12.2.2026.10.27.09.13.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 09:13: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=1793117623; x=1793722423; 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=mA1hqY03EkOXNfP+5Q1cRy5m3KVRfUK/vEk4Bk/8Tbs=; b=VZ2/RMoq0ivyzER4gLdtJL/CEFYGXhLVai/LHXY7iBMcelO6CnZwq92a5yJOlOAtxK LWdhRb3/R+ydM3M5jlPZQAnqV/b1UoPqR0cjxlyLBPi1Tewv3K0IP6/TiBPtaih/6mmD /cpLL2/LIjChdXq65fiPLRLJS5UXwPomRdRPbwO8jzXLqlnnbsUF7dJcjwp2plWGBFAX 8WHAAJwlM1fTFrI7zbeoV2+PRuVZIWX8vcY0EAcy6WcBz5sPQy7WJR+gVAmJgfpLNI89 UvSnMZi4kiLg8lFA0QHgdAeONW4kTIx/1Ezgg5NjjGvNpERDHhYClVHkc/XpKMlwiQ4l 96UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793117623; x=1793722423; 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=mA1hqY03EkOXNfP+5Q1cRy5m3KVRfUK/vEk4Bk/8Tbs=; b=HMb0VwoUtr1YMyUNAuQWIgt3QeSpyaRqCZ8ApkLJoFdX/ShQClgDMnfGX3ssPZA+GA QN5IUL11aX8GHs2tw/4ncyVvQBpcr0kGLLFS3bS+DmUE7wLTZLYYtDp26XykMinzI9Rg GqcD17hYOwC9fNJjV0PjEdQZ5wGyyVVmBwiHBNW1INUSQiOCmJtu3utTCG6riq62S4fN npAceZhPtQSLgHwPA8nFy5IbHJ/lLPKVU5a0uaCeIYjd2+aeXXYiaaGSK314SJxawT2P AwsmfAEQverU8pg0DU2XKOj6A2Cub7wYa+JaeiXQIVdhFgD7IEPxqPbFTA2pKB5ahoJJ imhQ== X-Forwarded-Encrypted: i=1; AKwUvBwiRWPK6zWa3XS62Aeu9lhSS/6UDfNdn8/s75GvuPwbxc8YE4fpQhg5DXC8amqNtBb4dSkzYUI78GY=@lists.xenproject.org X-Gm-Message-State: AFq9FYK0atcEtvlA5jSm/jJ7w74I5vERTnzTm5L8jXBjeHYmi0pCRnTR YbuAckK0iTbI0GCxPXv4xCeimNZP47k/hfYKYmF2D/CZL7gLnyYX+Wqf4AD5Lb56uQjpTMW3Sgc DGq4siJE= X-Gm-Gg: AYBFou2Gm1Kli4nqdW/MCVozY7sP/mb2XAt5DEv0BnXtEGRyMArnF65TFEV680LfjMZ 25OtTkjMuX/DMfIuSMFMJCC1mkQFR+KZ74XOjraChWBXGqUIB8CSsBFyMCQn0Ka9WVWVSX+Gdt9 fYkGZGvLGiVS2HRBu0xqSdB+o5bmvmslskU1KnAbh1w0iEwZFNUdHiqgNVnWktnfvuJ4FvGT/WB S1bRW9YcteZawCdDMQtE2d/i3sDhePckU1/ATZ1BtOIPuVFRRPgmeUeXQb+dlkoJGFYgH7alaiP PkIB7Wtinp8ikP1AScEcM/Az7GeL7P20FpEtd7h8ZitHn4RkGUoauX3sMfeHKwi0V3oTsDB097z h3HM7HJfPGAclqCGy5eVi86IGM0HpPllMS4USak8neHyxT7pTr/1tSDNfAyZFyi6TBSNpDZ7BtB 5PT6njY3YNETzEhsB9S9Ba3nP8cBtr9+L8lup6VNp7bu6nMb4fzwSRahAoYekapJ31BGJs3diWK ZjA7axSWlK90qOl/qtU8H1q9ks4K1aHDy5cde1BP2ySB5bqjQwZr2eWH4t9zUGIHCSTOlArnu1u mFwlJe6pIfZ2NST/k6ZN2xuOoXw8JkHBFBiY3ykD9SngsR/M4VMyz39cWrqoebQO5glnsDhJ0r2 Kpv2YScr+t6Lmv278N8/mX5m6w6NJSIKTS8RkFU546UAYib8jT9hn0ks= X-Received: by 2002:aa7:d6da:0:b0:6aa:e46b:2ca with SMTP id 4fb4d7f45d1cf-6b442ff19aamr7654152a12.30.1793117623180; Tue, 27 Oct 2026 09:13:43 -0700 (PDT) Message-ID: <959ff80d-2b77-46d3-8915-787dfc320203@suse.com> Date: Tue, 27 Oct 2026 17:13:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] libxl: simplify and correct domain ID and CPU pool ID parsing To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Anthony PERARD , msd-xenproject.org@msd.im 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="------------BAOQ7Prd09dvACa3qk5vOKfv" X-purgate-ID: tlsNG-c201ff/1793117623-F56AD2A1-BAA2C807/35/110847 X-purgate-type: clean X-purgate-size: 9119 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------BAOQ7Prd09dvACa3qk5vOKfv Content-Type: multipart/mixed; boundary="------------MNo1ULlcZYrmbkYP060bHSSI"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Anthony PERARD , msd-xenproject.org@msd.im Message-ID: <959ff80d-2b77-46d3-8915-787dfc320203@suse.com> Subject: Re: [PATCH] libxl: simplify and correct domain ID and CPU pool ID parsing 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= --------------MNo1ULlcZYrmbkYP060bHSSI Content-Type: multipart/mixed; boundary="------------Wbah3hmEVLghQFgFJAJJnwqR" --------------Wbah3hmEVLghQFgFJAJJnwqR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjcuMTAuMjYgMTc6MDAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBzdHJ0b3VsKCksIHdp dGggYSByYWRpeCBvZiAxMCwgYWxyZWFkeSBndWFyYW50ZWVzIHRoYXQgdGhlIHN0cmluZyBw YXJzZWQNCj4gY29uc2lzdHMgb2YganVzdCBkaWdpdHMgKGFuZCBsZWFkaW5nIHdoaXRlc3Bh Y2UpLiBObyBuZWVkIHRvIGRvIHRoYXQgY2hlY2sNCj4gaW4gYWR2YW5jZS4gQWxsIHdoaWNo IG5lZWRzIGRvaW5nIGlzIGEgY2hlY2sgZm9yIGEgbGVhZGluZyBkaWdpdCwgdG8NCj4gZXhj bHVkZSB0aGUgY2FzZSBvZiBsZWFkaW5nIHdoaXRlc3BhY2UuDQo+IA0KPiBUaGlzIGluIHBh cnRpY3VsYXIgYXZvaWRzIGEgZG9tYWluIElEIGFyZ3VtZW50IG9mICIiIHRvIGJlIG1pcy10 cmVhdGVkIGFzDQo+IGEgcmVmZXJlbmNlIHRvIERvbTAuDQo+IA0KPiBXaGlsZSBzaW1pbGFy IG1pcy10cmVhdG1lbnQgaXNuJ3QgcHJlc2VudCB0aGVyZSwgZG8gdGhlIHNhbWUNCj4gc2lt cGxpZmljYXRpb24gYWxzbyBpbiB0aGUgYWRqYWNlbnQgcXVhbGlmaWVyX3RvX2lkKCkuDQo+ IA0KPiBGaXhlczogZWY0OTZiODFmMDMzICgibGlieGw6IHBvc3Rwb25lIGJhY2tlbmQgbmFt ZSByZXNvbHV0aW9uIikNCj4gUmVwb3J0ZWQtYnk6IE1zZCA8bXNkLXhlbnByb2plY3Qub3Jn QG1zZC5pbT4NCj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2Uu Y29tPg0KPiAtLS0NCj4gVGhpcyByZXRhaW5zIHByaW9yIGJlaGF2aW9yIGFzIHRvIGxlYWRp bmcgKGFuZCB0cmFpbGluZykgd2hpdGVzcGFjZSAobm9uZQ0KPiBwZXJtaXR0ZWQpLiBXaGV0 aGVyIHRoYXQncyBpbnRlbmRlZCBiZWhhdmlvciBJIGRvbid0IGtub3cuDQo+IA0KPiBUaGUg ImVuZCAhPSAuLi4iIGNoZWNrcyBhcmUgbGlrZWx5IHBhcmFub2lhOiBJZiB0aGUgZmlyc3Qg Y2hhcmFjdGVyIGlzIGENCj4gZGlnaXQgYXMgcGVyIGlzZGlnaXQoKSwgc3RydG91bCgpIHNo b3VsZCBoYXZlIGNvbnN1bWVkIGl0Lg0KDQpJJ2QgZHJvcCB0aGUgdGVzdCwgYXMgaXQgcmVh bGx5IGlzIHJlZHVuZGFudC4NCg0KV2l0aCBvciB3aXRob3V0IGRyb3BwaW5nIGl0Og0KDQpS ZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJn ZW4NCg== --------------Wbah3hmEVLghQFgFJAJJnwqR 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----- --------------Wbah3hmEVLghQFgFJAJJnwqR-- --------------MNo1ULlcZYrmbkYP060bHSSI-- --------------BAOQ7Prd09dvACa3qk5vOKfv 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/Ey8FAmrgzbYFAwAAAAAACgkQsN6d1ii/Ey8X Fgf8CJzDq8BWI4jVE222EltnffPeCBWE4udh5Wx8OfYJGUEKnXzpw9YLZaIEVVU6/D8aaQfKplPa ElMa1XT9GyWfejSRG2ZJgdHUQlQrXKmiGWOXaAEDlpwXtWn9v9dTbmW2/4fxA4GO499wvQpo5nTk LaBJk+ToeRkKAmfm+d1a/RLNxGJmePNYmtkFHAQc6QuLZR2ftiR98TYvnH4nIl3d/nxk3BnJRn26 +rcQfZdqRUW/ifqKdTNaMU24CC7u0PZv1I9WIr723Az0FyiKuX2l9xlgjJVp5oWKqT5Jqi9QMvrd gHsFgXVh6tWLzGgJA9Y79WRDrVjV2vxJneWRWJwuug== =mFxr -----END PGP SIGNATURE----- --------------BAOQ7Prd09dvACa3qk5vOKfv-- From xen-devel-bounces@lists.xenproject.org Tue Oct 27 16:51:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 16:51:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462313.1673307 (Exim 4.92) (envelope-from ) id 1xLkO9-0004vZ-07; Tue, 27 Oct 2026 16:51:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462313.1673307; Tue, 27 Oct 2026 16: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 1xLkO8-0004vS-SU; Tue, 27 Oct 2026 16:51:04 +0000 Received: by outflank-mailman (input) for mailman id 1462313; Tue, 27 Oct 2026 16:51:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLkO6-0004vM-Qh for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 16:51:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLkO6-008VeO-0T for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 17:51:02 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0d66f-bab6-0a2a0a5309dd-0a2a450aca9e-20 for ; Tue, 27 Oct 2026 17:51:01 +0100 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0d675-f2d2-0a2a450a0019-d1558030a83e-3 for ; Tue, 27 Oct 2026 17:51:01 +0100 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a5720b0a57so7338825e9.0 for ; Tue, 27 Oct 2026 09:51:01 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ebd4ba7sm23973485f8f.33.2026.10.27.09.51.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 09:51: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=20260707 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=20260707; t=1793119861; x=1793724661; 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=EPpWdhpY2EJkduoNS3BQPxQ1U6Ru9YMHlhkJUTYsMzE=; b=N91V94IBSz154INetHOmyUJE1BSDJq/57Qv2EKxPk670Ao7WLOFPFgM4iZJQLSUjYd TU4cjYZRlTT5ncVW123G7+wCHXJuLJMa/V+fwMF2x7fDfopGOEzDKnjhevpjX33iPG14 e/HtHsBIlP+Wim6EWa63u5DsG7Y0PS62N3Bl+1/PmLtq1xczhzAdq5vNx9pjbPLCzOxy ehULq21JpqTO7rCGG7ckHd0WMGtUTfInfxXNOWIBd5YXXdjC259OKjwHpeOjYMGi9YvT SnHRUcchL2wVqVksiFICkeIzyFg1zELOKT9jXUVsrjueW17zh7u8Xw7X3kI8kKYjWWab dFjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793119861; x=1793724661; 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=EPpWdhpY2EJkduoNS3BQPxQ1U6Ru9YMHlhkJUTYsMzE=; b=1jrpPo+A31xVZQqbsjgj6XKXl945MBvrTQ3jDBF5qbgOZ6s+pHeJMVMY1Ls75lMXVs EdqmTNTlRLtTm/IFVlwqMwUqrDHJmF3Q1xavh4zOIfIz2cfiW6Wa+CFniP7RPXPWY8F9 J4CFK9TIKlCrZTqmRF1FZKe+LH5XESaq5QsBuj4dpdALFciFFkSCV+1Abx/5Wimbwcfu kOjsIBK2Id1dbxCbHaRxhGP1s5GkRciA8KBxCmPoUCWxzYGeBAuH3GtjkxfUD+tQD3Ir iu/h6CEVomKMn3ABdfUNnqQJYUUWchSN8SAimh/ZG2wFh022pbb9pPAc0hrH2V/Eppgg Wp2Q== X-Forwarded-Encrypted: i=1; AKwUvBz1623OqhT0glFo2A4i35nR7wiHCf4OY0exxrYgsPRBZG5jc8rnmJccvv4PiuuFORj/i/sCDTUKK8w=@lists.xenproject.org X-Gm-Message-State: AFq9FYLDHBA8Z2kU31WkJ2LqnCXwSioddpl7+cPARuCRKd5KcCfjBM0q K2UhLuZpH7KVhs4PN8q6Z7Y6ybJP28JOmk9PlTAMqk5qdlVZaGWPh3QX X-Gm-Gg: AYBFou2UPmSY8obRi6TrTxWzV2XtksEEStBflyT0um9yXtNSckAI3e/iQoj80vO8x4+ nAQXKiwBaArDSIiYD7Xm7GnNTxpqDeW++m1OcfP+6jExoIRhbJJHya3PQ6h4xJNKVC1Ks8sPUE4 z1ckQ5V0Hpcx4fvPYV77PWbHzzTqGDufp5IGbO1/TZsjw1J3Zx7BGDe7iyHKnguJLJzgoOFMwxU QGRU610/VNyJd9miszS4LKx+QRq2rurGaXFDm7DXAnd1sjpdgg4IL7JJjsV+6H6+bOgmMgwazzv A8/gMHHr3JGiA//Lu9kPA0nXjYfpoNiHawFjR4Y/boJQDTYM2xXlzloJqhpsHKV+ui5xK+nTzTt sjcgIA9dTdoX5y+gQSQUiZXnftyT2OK+6fyDHyj6x2YZsngyp/P0wUn5LusQMqsWph50Wt0b+BF binNRRmW/qEORdj86AD1KMrBtt6rqgrh4xJ4U2Z3k1Wcs9no0ClPlB+Kq94A4jDoNEoRgaJ6OdG 216HX6O+yvr7kZtw+mpmn9eI/1hWD5oWsTLF5xc/A9YT/+YSV+6unVEEsZhKpitYZDs8VSYOBgL 2BklStqZRvwHzbS6qKRmlFFmhziW X-Received: by 2002:a05:600c:c117:b0:4a2:f58:9a82 with SMTP id 5b1f17b1804b1-4a7c58f3472mr67601915e9.13.1793119861170; Tue, 27 Oct 2026 09:51:01 -0700 (PDT) Message-ID: <5ada3d12-5569-4e14-8178-815da3665a52@gmail.com> Date: Tue, 27 Oct 2026 17:51:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/6] automation/qtb: add unit tests for the QTB framework To: Baptiste Le Duc , xen-devel@lists.xenproject.org Cc: Doug Goldstein , Stefano Stabellini References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793119861-4BAD4CFC-2F88EB2E/10/73395122804 X-purgate-type: spam X-purgate-size: 5046 On 8/27/26 11:42 AM, Baptiste Le Duc wrote: > The QTB framework is meant to be extended: new test types, new machines and > new device trees aim to be added by other people. > > Add pytest coverage of the framework's functions, and of the console-test > type's config validation and expect/retry loop, so that such changes get > immediate feedback and existing behaviour does not silently regress. Nothing runs these tests, though: there is no CI job for them, and the container from patch 1 doesn't even have pytest. So the feedback only comes if whoever changes the framework has pytest and the QTB fork installed locally and remembers to run them. Probably, we want to consider to have a separate job for that (mainly question to CI maintainers then)? Nit: probably "immedidate feedback" will be clearer if this part ... > > The suite covers 100% of the framework's statements, so a new code path > added without a test shows up as a coverage drop. Running the suggested pytest-cov command gives 99% here: Name Stmts Miss Cover Missing ----------------------------------------------------------------------------------------- ... automation/scripts/qtb/riscv/paths.py 32 1 97% 50 ... automation/scripts/qtb/riscv/xen_dt.py 26 1 96% 21 ----------------------------------------------------------------------------------------- TOTAL 592 2 99% ============================== 51 passed in 0.22s ============================== Not a problem as such, but the commit message shouldn't claim 100%. > > The tests are meant to be run locally, from the Xen tree root: ... and part below will be moved up.> > python3 -m pytest automation/scripts/qtb/riscv/unit/ > > and, with pytest-cov installed, the coverage report is: > > python3 -m pytest --cov=automation/scripts/qtb \ > automation/scripts/qtb/riscv/unit/ > > The tests drive fakes rather than QEMU, so they need no artifacts to run. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > 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 ++++ > 8 files changed, 629 insertions(+) [...] > diff --git a/automation/scripts/qtb/riscv/unit/test_machine.py b/automation/scripts/qtb/riscv/unit/test_machine.py > new file mode 100644 > index 0000000000..68a1564072 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/unit/test_machine.py > @@ -0,0 +1,60 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +"""Unit tests for RiscvTestMachine QEMU argument assembly.""" > + > +from __future__ import annotations > + > +from stat import S_IEXEC > +from unittest import mock > + > +from ..machine import RiscvTestMachine > +from ..config import MACHINE_MEMORY, BinariesConfig > + > + > +def _binaries(tmp_path): > + xen = tmp_path / "xen" > + xen.write_bytes(b"") > + return BinariesConfig(xen=xen) > + > + > +def _machine(mc) -> RiscvTestMachine: > + """Build the machine with QtbMachine.__init__ stubbed out (it spawns QEMU).""" > + with mock.patch("qemu.qtb.QtbMachine.__init__", return_value=None): > + return RiscvTestMachine(mc, timeout=30) > + > + > +def test_init_forwards_cpus_to_qtbmachine(tmp_path, make_machine): > + mc = make_machine(name="machine", binaries=_binaries(tmp_path)) > + > + with mock.patch("qemu.qtb.QtbMachine.__init__", return_value=None) as base_init: > + vm = RiscvTestMachine(mc, timeout=30, log_dir="/logs") > + > + assert vm.machine_conf is mc > + assert base_init.call_args.kwargs == { > + "memory": MACHINE_MEMORY, > + "cpus": mc.pcpu, > + "mirror_console": False, > + "timeout": 30, > + "log_dir": "/logs", > + } Many of the tests check how the code is written rather than what it does: the exact keyword arguments passed to QtbMachine.__init__() here, the exact dtc argv in test_dt.py, the number of expect_exact() calls of the attempts loop in test_console_test.py. With everything else mocked out, these mostly restate the implementation, so each change asked for in review of patch 3 (mirroring the console, dropping attempts, ...) has to be repeated here, without the tests catching anything real in between. FWIW, all 51 tests pass for me (Debian trixie container from patch 1 plus python3-pytest). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Oct 27 17:32:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 17:32:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462331.1673314 (Exim 4.92) (envelope-from ) id 1xLl1v-0002Gh-0i; Tue, 27 Oct 2026 17:32:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462331.1673314; Tue, 27 Oct 2026 17:32: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 1xLl1u-0002Ga-UQ; Tue, 27 Oct 2026 17:32:10 +0000 Received: by outflank-mailman (input) for mailman id 1462331; Tue, 27 Oct 2026 17:32:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLl1s-0002GB-MC for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 17:32:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLl1s-007Sxb-2p for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:32:08 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0e017-bab6-0a2a0a5309dd-0a2a45058e7a-2 for ; Tue, 27 Oct 2026 18:32:08 +0100 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0e017-4cb1-0a2a45050019-d1558036dd89-3 for ; Tue, 27 Oct 2026 18:32:08 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a2084d62cdso810885e9.1 for ; Tue, 27 Oct 2026 10:32:07 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ebc3a1csm24334241f8f.16.2026.10.27.10.32.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 10:32: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=20260707 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=20260707; t=1793122327; x=1793727127; 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=BPFJ5JiP/ElLTx62+FRfNGsv7fzfBK63m/+szJKtrA4=; b=q78vTKLNbY/pFSOqcIKg8pUglkpRSKJ4avRNmNePx7t+1nYK7lGUBValpH4ln2iavu HSCviIqiY0o5iHmO3g+dtJLh4Yzfi6nBLo0aSmtsrBm58bwie0f1z+9zhu8EBpjwpcub UO3avpYsLnFAxqgyPnBxoR5CBrbKK5dc2ejfgnhYRncGuEsmjGb/AuBu2hi3YARzBvnh fuWVC6LarrHlIhVlrS+EkQydAIPk+NLcAm5nPW3zw83HnBnpthSSs6rNdUXiByKXUFO3 ZGbKWcbZqJaEwiiykeoOLoHkBXJ0z3xNI1M93Dad3F48wUM6GXJplilLh71NKrsiqfaA rC+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793122327; x=1793727127; 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=BPFJ5JiP/ElLTx62+FRfNGsv7fzfBK63m/+szJKtrA4=; b=tb5NA4k+R6ChtZ+lpCrEc6DlzImsl3LmeaxyVFRnvRt14w9mebrVRvLv23jGzqV7Da rMh5tAs3MJXDxGpQo/qkke1qeA3oYqT0HXJCNQtyLor8HmEJqvdGrGlLezzDA/zGjQB0 Vpg1Rm6noJZo9S9FCLYMwlzUYWrqlsLUdqfpYoQB+mbpTACN/V5kQtTyowRrkHJDnj9m 5cG75eBk/ghrkJ3Jexz9fUXfuuJANCraUJc60G/AFVQsYeIuCEVYdhfQ2hcJeXSFLhJN 4W0jYC13HIromfBv417mG1HyEHk2uf9Nd3HCbBpsxMB70hL1NVYOzUK3VC+1qfmTsMEk 1n3g== X-Forwarded-Encrypted: i=1; AKwUvBx+RflJZawqrK+6pVNJq2uULJH4o9meW9taNU6/8hw/t3pP+VPiS1h+etGgQV+CC9tMRn17luqpTkw=@lists.xenproject.org X-Gm-Message-State: AFq9FYIm6/hC0i4QZy17U0qXfpRB8z2TyCn+vOoMnXSXZlN/kxj2byKc MMrGPGcfqiSKkDt4OGWDLFhIgEqbbK/liniaJjb2yi8w40XA38K9dkgU X-Gm-Gg: AYBFou12hIAgFGd5Ox9O5tQyeKzgPbndM+UHbv5erW6TBO7Tiak10tZxD11TJYZo7w8 6vjKOO/QWR7HzE/TLZqb4K+8jsIQmR/TwXJ5+TCtApCNn1xbhuQoIBQq0/36U3ZaQv85pk0HvpJ loFyLve4iEqJcBL0oQ2o2pAHsZu5wjpDK4BZcMs35maU05+aWF0GVQI2ioH2T7rDjgsbLr1GKuY xv3tElPkt4fvqlFDSVJanU40cXw1Mv8xYTFD7IbTqzet3pqlt1Fo2U/c4MhicCt3A3Q3rhEcGTg vH4kbDrMGF4RRF6n8MXD/mlvXhybUrr4HVrwagc8cPeUCnYG5dN/Bt17yqoDYkVkNxL1Jqu5gCo CfwJc7D4Pzn/um2P2RQHHcditfpLEO8ygg2/CzPDZ3aCKabLr3VobipnYAMtngOJPdjCeBOzqYM Pa6dRSiRUdIwjnZC4Mnv2cyv7/lmQiLIv3d073xh0Q4Cwfl5J1ejaoEDwDSca63zWhkRV2fdYPC yPRpaO6bCi098qkhHFO9iz1DFj6o8Q8AZQP/fnyH5fYmDqXuP+famJfAE20d+9Sz7fTz98maiF2 dDtp1qXiJo2T/GTkIkTV2wiRs4JL X-Received: by 2002:a05:600c:c173:b0:4a2:1a:a129 with SMTP id 5b1f17b1804b1-4a35acb9b05mr180537885e9.35.1793122327306; Tue, 27 Oct 2026 10:32:07 -0700 (PDT) Message-ID: <1fcacfcb-2775-4a4f-ac38-d7ed9a143e99@gmail.com> Date: Tue, 27 Oct 2026 18:32:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/6] automation/qtb: add QTB framework README To: Baptiste Le Duc , xen-devel@lists.xenproject.org Cc: Doug Goldstein , Stefano Stabellini References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793122328-F76BD2A1-31CB49CC/10/73395122804 X-purgate-type: spam X-purgate-size: 7418 On 8/27/26 11:42 AM, Baptiste Le Duc wrote: > Document the qtb riscv64 test framework in a README. I understand that you are trying to introduce things so they could be traceble. But probaly it makes mentioned in cover letter or somewhere else that thre is README which probably should be read first for easier understanding of the patch series. > > It covers: > - the core concepts (machine, test type, test) and how they map to files > - the source files layout > - the CLI: `qemu_smoke_riscv64.py `, with "console-test" > as the type > - the config files: the machine catalog and a type's own `.yaml` > - the Jinja2 device-tree templates under dts/ > - how to add a test (config-only) and how to add a new test type. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > automation/scripts/qtb/riscv/README.md | 182 +++++++++++++++++++++++++ > 1 file changed, 182 insertions(+) > create mode 100644 automation/scripts/qtb/riscv/README.md > > diff --git a/automation/scripts/qtb/riscv/README.md b/automation/scripts/qtb/riscv/README.md > new file mode 100644 > index 0000000000..c173714d75 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/README.md > @@ -0,0 +1,182 @@ > +qtb riscv64 test framework > +========================== > + > +A small framework that boots Xen under QEMU on riscv64 and drives it to a > +pass/fail verdict automatically from its console output. > + > +It is built on QEMU's qtb (QEMU Test Bench) Python package, which gives > +programmatic control of a QEMU process over QMP and qtest, plus access to the > +consoles. > + > +What it does > +------------ > + > +1. Reads a machine description (what to boot: cpus, Xen command line) and a > + test description (what to assert). > +2. Generates the host device tree. > +3. Launches QEMU with Xen. > +4. Reads the console and checks what Xen printed. > + > +Core concepts > +------------- > + > +- Machine: test-agnostic description of what to boot. Reusable across test > + types. `config.yaml` -> `MachineConfig`. > +- Test type: a `RiscvQtbTest` subclass implementing the logic of a kind of test > + (e.g. `console-test`). Identified by `type_id`. See `console_test/`. > +- Test: one named, runnable instance of a type: a machine plus the type's > + parameters. Lives in the type's `.yaml`. > + > +A test type owns a config file describing its tests, each test names a machine > +from the shared catalog (`config.yaml`) and layers its own parameters on top. > + > +Layout > +------ > + > +``` > +qemu_smoke_riscv64.py CLI entry point ( run | list) > + > +qtb/riscv/ This framework > + __init__.py Public API > + qtb_test.py RiscvQtbTest ABC every test type derives from > + config.py Machine catalog parser -> MachineConfig > + xen_dt.py Generates the host device tree from its Jinja2 template > + dt.py Compile .dts -> .dtb with dtc > + paths.py Path resolution (pkg-relative) > + machine.py RiscvTestMachine: assembles the QEMU command line > + > + config.yaml The machine catalog (shared across test types) > + dts/ Jinja2 device-tree templates (host, common) There is only one template, qemu-host.dts.j2, nothing "common". > + > + console_test/ The console-test type > + __init__.py > + console_test.py ConsoleTest implementation > + console-test.yaml Its tests > + > + unit/ pytest unit tests of the framework logic itself > +``` > + > +How a type is selected > +---------------------- > + > +The test type is the first positional argument (`qemu_smoke_riscv64.py console-test run > +...`). The CLI builds one subcommand per entry of `TEST_TYPES` (`__init__.py`), > +named after the type's `type_id`. > + > +Each type declares the `config_file` it reads its tests from. > + > +Prerequisites > +------------- > + > +- `qemu.qtb`, QEMU's Python package (`python/` in the QEMU tree) qemu.qtb isn't in QEMU's python/ (it isn't upstream yet, as the cover letter says), so this sends people to the wrong place. Please point to the fork and the commit used by the container in patch 1, or better, say that the simplest way to get all prerequisites is that container, and show how to run a test in it with containerize. > +- `jinja2`, `pyyaml`, `pexpect` > +- `dtc` (device-tree-compiler) > +- `qemu-system-riscv64` > +- the `xen` binary a machine boots > + > +CLI usage > +--------- > + > +Run from `automation/scripts/`, or give the full path from the Xen tree root > +(`./automation/scripts/qemu_smoke_riscv64.py ...`), which is what CI does. Neither works without QTB_BINARIES_DIR unless xen is copied to automation/scripts/qtb/riscv/binaries/ (see my reply to patch 3), and the README doesn't say where to put it. > + > +``` > +# List every test the type defines in its config: > +./qemu_smoke_riscv64.py console-test list > + > +# Run one test (drives it to PASS/FAIL, exit 0/1): > +./qemu_smoke_riscv64.py console-test run dom0less-1smp-0domu-1vcpu-aplic-imsic-null \ > + --log-dir qtb-logs > +``` > + > +`--log-dir` (run only) collects the QEMU process log, the qtest log, and each > +console as `con.log`: `con0.log` is Xen's own console, the only one wired There is no qtest log: QtbMachine passes "-qtest-log none". The riscv64-qtest-.log file is QEMU's stdout/stderr; "qtest" comes from the machine name. > +up today. Omit it to write no logs. `-v/--verbose` raises the > +log level to debug. > + > +Config files > +------------ > + > +`config.yaml` is the machine catalog. `binaries:` are build artifacts resolved > +under `binaries/` (overridable with `$QTB_BINARIES_DIR`); absolute paths pass > +through. This reads as binaries/ at the top of the tree, while it is actually automation/scripts/qtb/riscv/binaries/. > + > +Machine entries omit any optional field left at its default. > +Here are the parameters: > + > +- `pcpu` (required): host physical cpus. > +- `mmu_type` (default `sv48`): Xen host MMU type. See my reply to patch 2: Xen doesn't use this. > +- `xen_bootargs` (default `""`): Xen command line. > + > +`.yaml` describes the tests of that type. > + > +`console-test` > +-------------- > + > +A test names a machine and maps a console index to the string(s) expected on > +that console: index 0 is Xen's own console (`con0`, logged as `con0.log`). > + > +``` > +machine_catalog: config.yaml # the catalog to resolve machine names against > +tests: > + dom0less-1smp-0domu-1vcpu-aplic-imsic-null: > + machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null # a name in config.yaml > + expect: > + 0: [All set up] # Xen itself must print "All set up" > +``` > + > +Logic, per console: > + > +1. read the console > +2. wait for each expected string in turn, in the order listed > +3. bound each wait by `timeout` seconds, retrying a timed-out wait up to > + `attempts` times See my reply to patch 3: nothing is retried, attempts only multiplies the timeout. [...] ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Oct 27 17:44:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 17:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462342.1673323 (Exim 4.92) (envelope-from ) id 1xLlDz-0004DQ-2B; Tue, 27 Oct 2026 17:44:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462342.1673323; Tue, 27 Oct 2026 17:44: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 1xLlDy-0004DJ-Ve; Tue, 27 Oct 2026 17:44:38 +0000 Received: by outflank-mailman (input) for mailman id 1462342; Tue, 27 Oct 2026 17:44:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLlDy-0004DD-9a for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 17:44:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlDx-007Uhr-Im for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:44:37 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0e2ff-2eae-0a2a0a5409dd-0a2a450187c6-20 for ; Tue, 27 Oct 2026 18:44:37 +0100 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0e305-5984-0a2a45010019-d1558034c093-3 for ; Tue, 27 Oct 2026 18:44:37 +0100 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a5b2be99a8so973615e9.2 for ; Tue, 27 Oct 2026 10:44:37 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a92b8812c5sm5417535e9.10.2026.10.27.10.44.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 10:44: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=20260707 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=20260707; t=1793123077; x=1793727877; 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=UzKo6N7xpNZSBsrrRX7mBe8GZGHcmawe26oyD0gzeeI=; b=BnwE3imBlNFTjMBGgDTzs+26J5m+XeyyIKBbief/YN38z2hn9873bDUWMINeksbU3i NrM4LOQoBDYvptR+Vj07AvR6s7UrvtUP+XEHzLJMuHWyoc9bxDe5x43cjO8cfCB1gQCB garfCt70nHuaJ9Uw/Pfxgd/0PIMQD+a9ARE34gyz0ShkvrDwVsA+w6VU0m45FT7y8jX5 a5GjSnA9FrMkgEMs4Xk6wU4yoDnIZbfQMI8t2oY32gAIgLvUn+puZM0lkliDiSHpcswc oG11SGQrAEoH6+mD/CeHWg743dNi8kTsbVRbrdjZ2tCYnMJ/jniz7hOtuO10rGhYvB8R zsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793123077; x=1793727877; 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=UzKo6N7xpNZSBsrrRX7mBe8GZGHcmawe26oyD0gzeeI=; b=wX45Pyocggti1FXMut3xV+TOb/F+o1z5th7aZkwtuwX99kDUs+onAsRFbFQpVpsE3z GC2svCvboVJptSF1vuCgQWjnBirmb5xl99E4FJ5gC7GJVjAcMDQWRlTV6j/TQUKi1i7p igfBlM7Dw0yAApP9AYYH4jYvbVpOdJHFxTGRdo/Zq1L7HmFwzqNGm5GCIhxRklKdGmon rhqKUZJDdhJ+/8jiuaLZMcUI3U/GWwsV5PvpwOPA1oGgezWiQUGtE8aqQ60KsycrA6Sv Z9+wNqYl9yfIwMBXd/oLXnHvA9gA0j0OgQKwuEzf9GYGGObWl86e4fW+35nN7I9h7wRZ FTtg== X-Forwarded-Encrypted: i=1; AKwUvBzImfwASJhi4R3f/SpMh7IHvzPfajLBr/jqSLmHJNvMePhLGYJvz9VVEJ+cTVXI/MP+SjEDnKAkpKU=@lists.xenproject.org X-Gm-Message-State: AFq9FYICoaVvFGXcMI/6/h9Pq/oRAxM2FN20euWNGUVR2vdT1zc/b9R0 foxrarQiZWSZ1ya79TMU4vAwwACFDaFDNE0FSC59wCvPEggyFk/hTaLB X-Gm-Gg: AYBFou2l5HbWXsplQVFwbYOJfyE6nIQZLVymi9slsWA9jeDRZV2xwUXRchQ+9l86iCB Qx3tKE/Anz9tNgamiyACVxl6R+OJfXBog3KGoAYry9Qrh6X0jXc+/bX51i/0ocy5W54DYiTQHHS 2opyb9UsBUqPnjElatO1V+1IoRL8/Y9h3jJq6+3Uawq61n2UgJtVyCWpRw1RF5KFOy0fIKTNZKQ E3eSF6ZUiZtjQ+PtqWvwac8x0XobT/Qvudy8DLBrJs7cF6NsfWjAX5sNuIDqnP+iOAWGkAzUXtv me3e2YxtKbox07CqHeZje/EsiZmVY4G6e07MTTXu/4+C0Ag43xyWFrPkWf/MbE+P/RRP0Sd2Ivf a7ubqup87pyu7msez6sLoAL1FgIhP442GXCbUibcmuSx7PzIRP+c0uiJbdUgAB42AOD2NwvLIMN qIXsiibu8W+5KnFTRZg9t64gI1MYhDDMK8fsrTjQzDCIo1mCOx66WptPwScMR/x+CsDJ+GBMtOu RDSAjkJ/T1oPFyKb8f/7PWxHibQzkQ7G4IcSr210dzWQBA+qLxjMA4q1PZKmZhmS+33Qdt4sjp3 dTIlc7IE9RD8XwHCXv30MgS0lHGO X-Received: by 2002:a05:600c:c091:b0:4a2:150f:1605 with SMTP id 5b1f17b1804b1-4a5015ef800mr140944135e9.24.1793123076950; Tue, 27 Oct 2026 10:44:36 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 18:44:35 +0100 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: Baptiste Le Duc , xen-devel@lists.xenproject.org Cc: Doug Goldstein , Stefano Stabellini References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1793123077-1FE68757-E2D33FC3/10/73395122804 X-purgate-type: spam X-purgate-size: 897 On 8/27/26 11:42 AM, Baptiste Le Duc wrote: > 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} See my reply to patch 1: if the container lives in automation/build/, this override and ARTIFACTS_REGISTRY aren't needed. > 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 The same goes for this one if the framework defaults to binaries/ at the top of the tree (see my reply to patch 3). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:14:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:14:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462357.1673334 (Exim 4.92) (envelope-from ) id 1xLlgq-000076-AM; Tue, 27 Oct 2026 18:14:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462357.1673334; Tue, 27 Oct 2026 18: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 1xLlgq-00006z-5l; Tue, 27 Oct 2026 18:14:28 +0000 Received: by outflank-mailman (input) for mailman id 1462357; Tue, 27 Oct 2026 18:14:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlgo-00006t-RB for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:14:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlgo-00556j-8F for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:14:26 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0e9da-8faa-0a2a0a5109dd-0a2a450580e0-26 for ; Tue, 27 Oct 2026 19:14:26 +0100 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 6ae0ea01-4cb1-0a2a45050019-aa0a817c889b-3 for ; Tue, 27 Oct 2026 19:14:26 +0100 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-651-ogOcdw8xNomqQoUIrQuolg-1; Tue, 27 Oct 2026 14:14:15 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6EFF81955BF1; Tue, 27 Oct 2026 18:14:10 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8D1DC18005AD; Tue, 27 Oct 2026 18:14: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=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=1793124864; 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=caBZVIE/hSguJ/sxrRpKGVVVydsKnFLoXQm6GdDdBq0=; b=C3/RgCrsuaoT6deF5d+L8VTH/NOkEUt2B/U/zTLA6a9GBtLYIWxcMfp7BT0X/1hC/2mf/c UF/TJua3jfEYlaBz+ND+ffk+jDroBRvH8bg7ZIrX/jAPaH7+0rSqCk7sLkPucnaYTGEt5/ hbzGDrCSl9czz92hNqCvGpjjausx9F8= X-MC-Unique: ogOcdw8xNomqQoUIrQuolg-1 X-Mimecast-MFC-AGG-ID: ogOcdw8xNomqQoUIrQuolg_1793124851 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 00/11] hw: mark virtualization related machines & accelerators as secure Date: Tue, 27 Oct 2026 18:13:49 +0000 Message-ID: <20261027181400.1752951-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: SJRNZwynIFML59hhLezod6Z6NyBiu4eZJKOC1koHnNU_1793124851 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793124866-245122A1-964B4F1E/0/0 X-purgate-type: clean X-purgate-size: 1547 This is the machine type and accelerators patches pulled out of the bigger series and split per target / accelerator: https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg03555.html Note this only deals with marking leaf types. All parent types are implicitly also considered secure if any leaf is secure. A future series will explicitly mark parent types too. Daniel P. Berrangé (11): hw/arm: mark 'virt' as a secure machine hw/i386: mark 'microvm', 'i440fx', 'q35' as secure machines hw/loongarch: mark 'virt' as a secure machine hw/ppc: mark 'pseries' as a secure machine hw/riscv: mark 'virt' as a secure machine hw/s390x: mark 's390x-ccw-virtio' as a secure machine hw: mark xenpv, xenpvh, xenfv as secure machines hw/nitro: mark 'nitro' machine as secure accel/kvm: mark kvm accelerator as secure accel/xen: mark xen accelerator as secure accel/nitro: mark 'nitro' accelerator as secure accel/kvm/kvm-all.c | 1 + accel/nitro/nitro-accel.c | 1 + accel/xen/xen-all.c | 1 + 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 | 1 + hw/nitro/machine.c | 1 + hw/ppc/spapr.c | 1 + hw/riscv/virt.c | 1 + hw/s390x/s390-virtio-ccw.c | 1 + hw/xenpv/xen_machine_pv.c | 2 +- include/hw/i386/pc.h | 1 + 15 files changed, 16 insertions(+), 3 deletions(-) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:14:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:14:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462358.1673343 (Exim 4.92) (envelope-from ) id 1xLlgt-0000Ki-GB; Tue, 27 Oct 2026 18:14:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462358.1673343; Tue, 27 Oct 2026 18: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 1xLlgt-0000KZ-CE; Tue, 27 Oct 2026 18:14:31 +0000 Received: by outflank-mailman (input) for mailman id 1462358; Tue, 27 Oct 2026 18:14:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlgr-0000KH-S5 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:14:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlgr-00BJQB-8y for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:14:29 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea01-2eae-0a2a0a5409dd-0a2a4503b752-8 for ; Tue, 27 Oct 2026 19:14:29 +0100 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 6ae0ea04-fae8-0a2a45030019-aa0a857cd98b-3 for ; Tue, 27 Oct 2026 19:14:29 +0100 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-508-P2CkRgR_M8Cknl4287nnmA-1; Tue, 27 Oct 2026 14:14:23 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7115D195411E; Tue, 27 Oct 2026 18:14:19 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D5A0B18005B0; Tue, 27 Oct 2026 18:14:10 +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=1793124868; 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=AjGVXU5aS/ksj0LQ/51NqYabIHtfhW7qM9VfFUaebJo=; b=eirGs5UhTUM+gyhj+CW/AenbixCDMQxNV1jdXDS8tohDmerLKpaIogUEQxtPxSKq/f+Fyh 3PnZvZMN8+cKpXnKRpePU1Hc31Q2j2USa3FERjlQDrScBtqcJV3qcCWMnXQy3P/ymy9rTJ FVTSGeEAlZZoKAzQlgQVZ8ZAbziKGYY= X-MC-Unique: P2CkRgR_M8Cknl4287nnmA-1 X-Mimecast-MFC-AGG-ID: P2CkRgR_M8Cknl4287nnmA_1793124860 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 01/11] hw/arm: mark 'virt' as a secure machine Date: Tue, 27 Oct 2026 18:13:50 +0000 Message-ID: <20261027181400.1752951-2-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: UCmsMctetuTqV8rw8KomZLnDU3lftXuECXguhaKjNrs_1793124860 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1793124869-6ECCB4E9-EED47C1C/0/0 X-purgate-type: clean X-purgate-size: 822 The 'virt' arm machine is already declared secure in docs/system/security.rst, due too its intended usage in virtualization scenarios. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- hw/arm/virt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 0d56197dace..43b9212edc2 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -133,6 +133,7 @@ static void arm_virt_compat_default_set(MachineClass *mc) .parent = TYPE_VIRT_MACHINE, \ .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \ .is_available = target_base_arm, \ + .secure = true, \ }; \ static void MACHINE_VER_SYM(register, virt, __VA_ARGS__)(void) \ { \ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:14:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:14:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462360.1673351 (Exim 4.92) (envelope-from ) id 1xLlh1-0000cD-Pa; Tue, 27 Oct 2026 18:14:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462360.1673351; Tue, 27 Oct 2026 18: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 1xLlh1-0000c1-Md; Tue, 27 Oct 2026 18:14:39 +0000 Received: by outflank-mailman (input) for mailman id 1462360; Tue, 27 Oct 2026 18:14:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlgz-0000b0-VM for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:14:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlgz-007Z83-C7 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:14:37 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0e9f9-e002-0a2a0a5209dd-0a2a450bdddc-48 for ; Tue, 27 Oct 2026 19:14:37 +0100 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 6ae0ea0c-b7e8-0a2a450b0019-aa0a857c9b57-3 for ; Tue, 27 Oct 2026 19:14:37 +0100 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-648-DAvRLKr5NMGyM-khrW0W2g-1; Tue, 27 Oct 2026 14:14:31 -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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7DE8C1800747; Tue, 27 Oct 2026 18:14:27 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C10C91800586; Tue, 27 Oct 2026 18:14: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=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=1793124875; 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=c8HnPQcFtU7MhJRZ/6L5s11AsfWMBibuK6w1Kgqphf8=; b=hWbXkW5kZx8SU/EJ4dFQPQa23RCl3PyA8z6AfoD3j971c5GQC8oOEzPINBnGkIzqmgL+ww lbhYrMY9KaL2KKQS+H40/EKRPi+pb+Dgkx66eFk9khkjzOmtG1Hp/+qgZXvsG+Z+x7HSTT /RVocpX/sXFmfwZoDaR7k/ymsvn0ouo= X-MC-Unique: DAvRLKr5NMGyM-khrW0W2g-1 X-Mimecast-MFC-AGG-ID: DAvRLKr5NMGyM-khrW0W2g_1793124868 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 02/11] hw/i386: mark 'microvm', 'i440fx', 'q35' as secure machines Date: Tue, 27 Oct 2026 18:13:51 +0000 Message-ID: <20261027181400.1752951-3-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: otQgT7mrGDIjpAgBicGFDQDB0LDgNoBxWtGZmx61-sM_1793124868 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793124877-1A8D99EA-972E30F0/0/0 X-purgate-type: clean X-purgate-size: 1410 The 'microvm', 'i440fx', 'q35' i386 machines are already declared secure in docs/system/security.rst, due too their intended usage in virtualization scenarios. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- hw/i386/microvm.c | 1 + include/hw/i386/pc.h | 1 + 2 files changed, 2 insertions(+) diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c index a49de337497..342aa7a9dd0 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/include/hw/i386/pc.h b/include/hw/i386/pc.h index 8edec62a1af..4ac489d2ffa 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -330,6 +330,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.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:14:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:14:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462361.1673361 (Exim 4.92) (envelope-from ) id 1xLlh9-0000uf-0z; Tue, 27 Oct 2026 18:14:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462361.1673361; Tue, 27 Oct 2026 18:14: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 1xLlh8-0000uT-T6; Tue, 27 Oct 2026 18:14:46 +0000 Received: by outflank-mailman (input) for mailman id 1462361; Tue, 27 Oct 2026 18:14:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlh7-0000sq-8W for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:14:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlh6-007Z83-LZ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:14:44 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea11-e002-0a2a0a5209dd-0a2a4505ec72-8 for ; Tue, 27 Oct 2026 19:14:44 +0100 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 6ae0ea13-4cb1-0a2a45050019-aa0a817cc331-3 for ; Tue, 27 Oct 2026 19:14:44 +0100 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-657-0gT1TLqPOlSDXO7RRLjcLg-1; Tue, 27 Oct 2026 14:14:39 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 331831955F08; Tue, 27 Oct 2026 18:14:35 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CED5818005B0; Tue, 27 Oct 2026 18:14: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=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=1793124883; 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=KwxbuGUzltatEV1ySNqyNWJngrA4WQvavQfW4tIYbRA=; b=VYwgsmVjUoPuE5k6H7gIfFiiiCcM82NoskchE6gM85Aq4rtf8EcAS0bwvDgl6NGOMVYQoP Ep0rRVyEUbK3NC0RWZPmoAaPYp4BTUUmq9RQcLvECKj5bi/R3lF1w/wV03bzTiGCvVz0SL sWjUVa6L9AL3NTpbXpbUqjWKKq5Yhp4= X-MC-Unique: 0gT1TLqPOlSDXO7RRLjcLg-1 X-Mimecast-MFC-AGG-ID: 0gT1TLqPOlSDXO7RRLjcLg_1793124876 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 03/11] hw/loongarch: mark 'virt' as a secure machine Date: Tue, 27 Oct 2026 18:13:52 +0000 Message-ID: <20261027181400.1752951-4-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: D32mVhDY3EiEtUY0T4QVwqpwT2yVabgIamfKsPA7gHE_1793124876 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793124884-F6EB12A1-5BE4D252/0/0 X-purgate-type: clean X-purgate-size: 894 The 'virt' loongarch machine is already declared secure in docs/system/security.rst, due too its intended usage in virtualization scenarios. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- hw/loongarch/virt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 9c5371af9de..c83c0b6cb19 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) \ { \ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:14:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:14:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462367.1673368 (Exim 4.92) (envelope-from ) id 1xLlhG-0001MP-76; Tue, 27 Oct 2026 18:14:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462367.1673368; Tue, 27 Oct 2026 18:14: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 1xLlhG-0001MI-4D; Tue, 27 Oct 2026 18:14:54 +0000 Received: by outflank-mailman (input) for mailman id 1462367; Tue, 27 Oct 2026 18:14:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlhF-0001Iz-Ai for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:14:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlhE-0055Bi-Nk for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:14:52 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea15-8faa-0a2a0a5109dd-0a2a450ab6da-4 for ; Tue, 27 Oct 2026 19:14:52 +0100 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0ea1b-f2d2-0a2a450a0019-aa0a857c5327-3 for ; Tue, 27 Oct 2026 19:14:52 +0100 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-472-hFjnCr8qMIidUk_D93z-dw-1; Tue, 27 Oct 2026 14:14:47 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BA8621955BC4; Tue, 27 Oct 2026 18:14:42 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 835921800586; Tue, 27 Oct 2026 18:14: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=1793124891; 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=OR3eA/OEI8JQI9niPlwkL7rz2xDS90J8dFRNMLbMsFA=; b=cjMheI3yeWba4m+k+DRnp2aMMYGxfEut/Hmh1VnHF0KlLUWyHcT/asidHqrmjtc5w84kUO Ue2M3RpEzQWeJ1nFEOOn08Yql4zs38TYUf7YDWhHPJxo8MhaYwGoXAZbyA5o3Uspk3XsTW zAUp+d4H+mwbEQHNJqpxZLtH2FtAP1A= X-MC-Unique: hFjnCr8qMIidUk_D93z-dw-1 X-Mimecast-MFC-AGG-ID: hFjnCr8qMIidUk_D93z-dw_1793124882 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 04/11] hw/ppc: mark 'pseries' as a secure machine Date: Tue, 27 Oct 2026 18:13:53 +0000 Message-ID: <20261027181400.1752951-5-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: CabroUcxOAbs9gn_uNMc6O5Vxv_ncNL3e-NXfqREHdY_1793124882 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1793124892-4ACDBCFC-140E72FD/0/0 X-purgate-type: clean X-purgate-size: 1072 The 'pseries' ppc machine is already declared secure in docs/system/security.rst, due too its intended usage in virtualization scenarios. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- hw/ppc/spapr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 6d994644865..7fe3202f635 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) \ { \ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:15:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:15:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462374.1673378 (Exim 4.92) (envelope-from ) id 1xLlhQ-0001tz-EV; Tue, 27 Oct 2026 18:15:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462374.1673378; Tue, 27 Oct 2026 18:15: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 1xLlhQ-0001tr-BQ; Tue, 27 Oct 2026 18:15:04 +0000 Received: by outflank-mailman (input) for mailman id 1462374; Tue, 27 Oct 2026 18:15:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlhP-0001rJ-95 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:15:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlhO-007ZBC-Lq for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:15:02 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea11-e002-0a2a0a5209dd-0a2a4505ec72-26 for ; Tue, 27 Oct 2026 19:15:02 +0100 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 6ae0ea25-4cb1-0a2a45050019-aa0a817cd3cd-3 for ; Tue, 27 Oct 2026 19:15:02 +0100 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-55-Q22TEt-IN-y5e0rsPUvSgQ-1; Tue, 27 Oct 2026 14:14:54 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CCFFD1955E87; Tue, 27 Oct 2026 18:14:50 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 14FD91800586; Tue, 27 Oct 2026 18:14: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=1793124901; 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=ffR5lWwVfMJeNQwVyhdMmRrcn+pHfvHRaFQfo9M/AZg=; b=fk9LpYFGJNBJWaq+0minf+0kb3b+x4RroDRunbGzBszah9Q9ZnAI9sbWPuMAsIf5icc82a J0Sp85aDOZGgvN8QVZIKV5axrZ5Im+eZwTIKe8cjYLQPnPXE/LvjLEqXb7qNAcCQTC/Neu j/4V3Ebh6+CeAA0VtMy77CYQte/y0zs= X-MC-Unique: Q22TEt-IN-y5e0rsPUvSgQ-1 X-Mimecast-MFC-AGG-ID: Q22TEt-IN-y5e0rsPUvSgQ_1793124891 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 05/11] hw/riscv: mark 'virt' as a secure machine Date: Tue, 27 Oct 2026 18:13:54 +0000 Message-ID: <20261027181400.1752951-6-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: T9sF2exUL9sJQxf-Y1__3jSXqYIj7z_uTQsNFqqOr6k_1793124891 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793124902-F6CB02A1-75BF7327/0/0 X-purgate-type: clean X-purgate-size: 855 The 'virt' riscv machine is already declared secure in docs/system/security.rst, due too its intended usage in virtualization scenarios. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- hw/riscv/virt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index d4b501802f6..489ebae4105 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), -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:15:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:15:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462388.1673387 (Exim 4.92) (envelope-from ) id 1xLlhe-0002TL-Mb; Tue, 27 Oct 2026 18:15:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462388.1673387; Tue, 27 Oct 2026 18:15: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 1xLlhe-0002TC-In; Tue, 27 Oct 2026 18:15:18 +0000 Received: by outflank-mailman (input) for mailman id 1462388; Tue, 27 Oct 2026 18:15:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlhd-0002SO-6t for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:15:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlhc-007ZBC-Jb for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:15:16 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea2e-e002-0a2a0a5209dd-0a2a4503d5c4-4 for ; Tue, 27 Oct 2026 19:15:16 +0100 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 6ae0ea33-fae8-0a2a45030019-aa0a857cb97d-3 for ; Tue, 27 Oct 2026 19:15:16 +0100 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-172-wPdDHKoBORCP-8DA1EmsCg-1; Tue, 27 Oct 2026 14:15:09 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7DEE31956063; Tue, 27 Oct 2026 18:15:05 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5BF2E18002B1; Tue, 27 Oct 2026 18:14: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=1793124915; 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=x0eL0OHLT754EdZ0DXSCF0DHaRsDNV6qcq8Lkd2hMBk=; b=X8PacgRt/jGdUd3UFkDNxCtIcM9o3Sxpxp2XqdU4pwZXgymV6TXK/gD6bAPUjuBs0JYW7/ xTHnvukqMF0Ip5V41HujRFRPpMnC8LeRax8S8adAFN042MRjhdeiVZuY05g+H8yTnHr2uB VBwjY/GWY675yzSmabYSGILyRhMIUEw= X-MC-Unique: wPdDHKoBORCP-8DA1EmsCg-1 X-Mimecast-MFC-AGG-ID: wPdDHKoBORCP-8DA1EmsCg_1793124905 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 07/11] hw: mark xenpv, xenpvh, xenfv as secure machines Date: Tue, 27 Oct 2026 18:13:56 +0000 Message-ID: <20261027181400.1752951-8-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: 4MN5QMw7tgA29GbgyQ85uh06L_e1d5jV-NGk57kWAdA_1793124905 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1793124916-6F6C64E9-04C91303/0/0 X-purgate-type: clean X-purgate-size: 2273 The Xen machines are already declared secure in docs/system/security.rst, due too their intended usage in virtualization scenarios. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- hw/arm/xen-pvh.c | 1 + hw/i386/pc_piix.c | 4 ++-- hw/i386/xen/xen-pvh.c | 1 + hw/xenpv/xen_machine_pv.c | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c index f05956c1662..6b85eced1bb 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/pc_piix.c b/hw/i386/pc_piix.c index 63c4667ea37..e801325dd6e 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -667,6 +667,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 ab90c83a830..d81575b4c9b 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/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c index c406821c34c..e0620a096ee 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) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:15:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:15:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462392.1673397 (Exim 4.92) (envelope-from ) id 1xLlhs-0002zn-1d; Tue, 27 Oct 2026 18:15:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462392.1673397; Tue, 27 Oct 2026 18:15: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 1xLlhr-0002zX-Ty; Tue, 27 Oct 2026 18:15:31 +0000 Received: by outflank-mailman (input) for mailman id 1462392; Tue, 27 Oct 2026 18:15:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlhq-0002wG-KI for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:15:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlhq-008gUu-0t for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:15:30 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea3f-2eae-0a2a0a5409dd-0a2a4501c514-4 for ; Tue, 27 Oct 2026 19:15:29 +0100 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 6ae0ea40-5984-0a2a45010019-aa0a817c9a39-3 for ; Tue, 27 Oct 2026 19:15:29 +0100 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-161-zdO1gxORNhKJ7rxNn7TBjQ-1; Tue, 27 Oct 2026 14:15:18 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1E99B1955F00; Tue, 27 Oct 2026 18:15:13 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D0B1218002B1; Tue, 27 Oct 2026 18:15: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=1793124928; 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=LUwBxGM3xjpChBFYaFDJkfG6EUPdlIElSL7fPYhzNRY=; b=WhnXh1YTJPj0WmoiiQDfXmyjxDXkIdy19kt/FrPTvggBjcu7dEZzrb02o+oQa5n11Xos/X MzLdLF9yyIx19Ejdln9/K/Bjd2/IXbNIDT4mHfSzU/wZ1AJkex3WSaMWv/hR1NliehPOru C1XKIkaXYHjkYOXd7WiTNMkooyuguG8= X-MC-Unique: zdO1gxORNhKJ7rxNn7TBjQ-1 X-Mimecast-MFC-AGG-ID: zdO1gxORNhKJ7rxNn7TBjQ_1793124913 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 08/11] hw/nitro: mark 'nitro' machine as secure Date: Tue, 27 Oct 2026 18:13:57 +0000 Message-ID: <20261027181400.1752951-9-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: SldckWX38lpkcQLH91i2bgdOrvYhKeiFVc66la9-NSI_1793124913 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1793124929-BE867757-F789BBAD/0/0 X-purgate-type: clean X-purgate-size: 708 Unlike the 'nitro-enclave' machine which provides emulation, the 'nitro' machine is used with a real AWS deployment and thus is considered to be secure. Signed-off-by: Daniel P. Berrangé --- hw/nitro/machine.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/nitro/machine.c b/hw/nitro/machine.c index 88d01960a01..2e88e150c93 100644 --- a/hw/nitro/machine.c +++ b/hw/nitro/machine.c @@ -261,6 +261,7 @@ static const TypeInfo nitro_machine_info = { .parent = TYPE_MACHINE, .instance_size = sizeof(NitroMachineState), .class_init = nitro_machine_class_init, + .secure = true, }; static void nitro_machine_register(void) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:15:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:15:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462393.1673406 (Exim 4.92) (envelope-from ) id 1xLlhu-0003Fc-9A; Tue, 27 Oct 2026 18:15:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462393.1673406; Tue, 27 Oct 2026 18: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 1xLlhu-0003FU-4F; Tue, 27 Oct 2026 18:15:34 +0000 Received: by outflank-mailman (input) for mailman id 1462393; Tue, 27 Oct 2026 18:15:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlhs-000355-FC for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:15:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlhr-004Wcg-Qq for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:15:31 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea2c-bab6-0a2a0a5309dd-0a2a45028bcc-26 for ; Tue, 27 Oct 2026 19:15:31 +0100 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 6ae0ea42-6ca4-0a2a45020019-aa0a857c8075-3 for ; Tue, 27 Oct 2026 19:15:31 +0100 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-622-IAhZ7yWWMa6sTZNfrhwzSA-1; Tue, 27 Oct 2026 14:15:24 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B70581954236; Tue, 27 Oct 2026 18:15:20 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6FD8418002B1; Tue, 27 Oct 2026 18:15: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=1793124930; 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=4Pm6nA/KY6PE4TLQmdMM8j973NLZ7jXiNqYHwm4lj4k=; b=Qfn+8pLwelcbBtQaeElxutL2s95nNh5lqAo8Z7PN5tvzZChCAW7+Z2vM2FbFBsVRrC3WCF BI9N3mQrw2locDoEIP6wlI8vm1pL8apq0kT2+yumjocO4+gCXPgInJpCNscxnX3e4OsEzy Et4RO6qyDyoZo5BeB+h9mTO7axxD9Zg= X-MC-Unique: IAhZ7yWWMa6sTZNfrhwzSA-1 X-Mimecast-MFC-AGG-ID: IAhZ7yWWMa6sTZNfrhwzSA_1793124921 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 09/11] accel/kvm: mark kvm accelerator as secure Date: Tue, 27 Oct 2026 18:13:58 +0000 Message-ID: <20261027181400.1752951-10-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: pjSYcQVMyPnGibHzAabnmIz6rN6yGZ3r7lYKeTjkfX0_1793124921 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1793124931-678BC2AC-EDC79C09/0/0 X-purgate-type: clean X-purgate-size: 710 KVM is servicing virtualization use cases which must provide security and actively maintained. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- accel/kvm/kvm-all.c | 1 + 1 file changed, 1 insertion(+) diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index db8fba53f33..66bc7f3a83a 100644 --- a/accel/kvm/kvm-all.c +++ b/accel/kvm/kvm-all.c @@ -4353,6 +4353,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) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:15:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:15:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462399.1673414 (Exim 4.92) (envelope-from ) id 1xLli5-0003n0-Fx; Tue, 27 Oct 2026 18:15:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462399.1673414; Tue, 27 Oct 2026 18:15: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 1xLli5-0003mm-CR; Tue, 27 Oct 2026 18:15:45 +0000 Received: by outflank-mailman (input) for mailman id 1462399; Tue, 27 Oct 2026 18:15:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLli4-0003kR-MG for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:15:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLli4-004Wcg-2n for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:15:44 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea1b-bab6-0a2a0a5309dd-0a2a45098164-40 for ; Tue, 27 Oct 2026 19:15:43 +0100 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 6ae0ea4e-be1a-0a2a45090019-aa0a857c70a9-3 for ; Tue, 27 Oct 2026 19:15:43 +0100 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-650-cEwpYKv8NwSl2l1n83HM6Q-1; Tue, 27 Oct 2026 14:15:32 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5AB521955F61; Tue, 27 Oct 2026 18:15:28 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1369118002B1; Tue, 27 Oct 2026 18:15: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=1793124942; 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=buIH4vNJ8worC1Ayihr2YWFbS43gZwwGin2hAsqsREk=; b=VOtzyEFtzKrXYlzDeYF7GYoL+u9NHQCwsj2HgIxg2cXn1Wx5ySmHfi1PbEoPL7lb2ttn72 uwhLQtxu16hVFLsJFLhT1YgOwEgDCquwccqYaZ4tCtH77Jq0vWTpJ6X3wyUiWn2xRwwuJP GkhxbKOLZuGqxZGzK/5TjL680ka+ly8= X-MC-Unique: cEwpYKv8NwSl2l1n83HM6Q-1 X-Mimecast-MFC-AGG-ID: cEwpYKv8NwSl2l1n83HM6Q_1793124928 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 10/11] accel/xen: mark xen accelerator as secure Date: Tue, 27 Oct 2026 18:13:59 +0000 Message-ID: <20261027181400.1752951-11-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: FiR699LnkIG_qRnMIjHheB5xzvst3tMwKXaKthwrUcc_1793124928 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1793124943-BD0CD034-07AF5424/0/0 X-purgate-type: clean X-purgate-size: 718 Xen is servicing virtualization use cases which must provide security and actively maintained. Reviewed-by: Marc-André Lureau Signed-off-by: Daniel P. Berrangé --- accel/xen/xen-all.c | 1 + 1 file changed, 1 insertion(+) diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c index bb2d02cb221..94f20e1d29a 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) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:15:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:15:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462400.1673420 (Exim 4.92) (envelope-from ) id 1xLli5-0003pp-Q6; Tue, 27 Oct 2026 18:15:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462400.1673420; Tue, 27 Oct 2026 18:15: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 1xLli5-0003pP-KO; Tue, 27 Oct 2026 18:15:45 +0000 Received: by outflank-mailman (input) for mailman id 1462400; Tue, 27 Oct 2026 18:15:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLli5-0003m4-2Q for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:15:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLli4-00A0QI-Ew for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:15:44 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ea3a-8faa-0a2a0a5109dd-0a2a450782e8-38 for ; Tue, 27 Oct 2026 19:15:44 +0100 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 6ae0ea4f-b4ea-0a2a45070019-aa0a857c8a7d-3 for ; Tue, 27 Oct 2026 19:15:44 +0100 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-518-JOn5XFgQOvy5Nv457LYFkw-1; Tue, 27 Oct 2026 14:15:40 -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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 575E019541AE; Tue, 27 Oct 2026 18:15:36 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id BABAD1800586; Tue, 27 Oct 2026 18:15: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=1793124943; 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=sKIoYOrDenZa1R+DPeUDUjirn8ohaLCMSKPzoV+nbNc=; b=cbFCtvZLAs+OGZ1vuUxvL4ObaB1iDrYiyYqxyuwjA8oFSyKmBr2avgqKq7htXwSd+oh3Mv Il4hTG9wX66wRSqiAJovKO/2RBWvQod9X9LFJD/fn2Jq93gu42QDYHSgrPd/wX4aiptcXC w2FAGSksDy7x2nbzVWZ95GbTe6q/TT4= X-MC-Unique: JOn5XFgQOvy5Nv457LYFkw-1 X-Mimecast-MFC-AGG-ID: JOn5XFgQOvy5Nv457LYFkw_1793124936 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 11/11] accel/nitro: mark 'nitro' accelerator as secure Date: Tue, 27 Oct 2026 18:14:00 +0000 Message-ID: <20261027181400.1752951-12-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: frP-mv7qXLL7aQiVPP80aKP4Cb1zvGeZqLMQNWI2uUQ_1793124936 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793124944-37CD7AE4-FD513CCA/0/0 X-purgate-type: clean X-purgate-size: 666 The 'nitro' accelerator is used with a real AWS deployment and thus is considered to be secure. Signed-off-by: Daniel P. Berrangé --- accel/nitro/nitro-accel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/accel/nitro/nitro-accel.c b/accel/nitro/nitro-accel.c index a1e97a9162e..a1489b8019a 100644 --- a/accel/nitro/nitro-accel.c +++ b/accel/nitro/nitro-accel.c @@ -251,6 +251,7 @@ static const TypeInfo nitro_accel_type = { .parent = TYPE_ACCEL, .instance_size = sizeof(NitroAccelState), .class_init = nitro_accel_class_init, + .secure = true, }; module_obj(TYPE_NITRO_ACCEL); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:20:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:20:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462428.1673432 (Exim 4.92) (envelope-from ) id 1xLlmL-0006yc-8D; Tue, 27 Oct 2026 18:20:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462428.1673432; Tue, 27 Oct 2026 18:20: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 1xLlmL-0006yV-4j; Tue, 27 Oct 2026 18:20:09 +0000 Received: by outflank-mailman (input) for mailman id 1462428; Tue, 27 Oct 2026 18:20:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlmK-0006sN-Bt for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:20:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlmJ-00BK1W-LC for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:20:07 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0eb34-e002-0a2a0a5209dd-0a2a450580a6-42 for ; Tue, 27 Oct 2026 19:20:07 +0100 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 6ae0ea29-4cb1-0a2a45050019-aa0a857ca1b9-3 for ; Tue, 27 Oct 2026 19:15:06 +0100 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-576-6LQe5KMvNl2nCJ5O0yFuYg-1; Tue, 27 Oct 2026 14:15:01 -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 0ACCB18052C5; Tue, 27 Oct 2026 18:14:58 +0000 (UTC) Received: from berrange.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2AFAB18005B4; Tue, 27 Oct 2026 18:14:51 +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=1793124905; 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=SjzJ86NcoOOpiqoXBZbehS0Nmy6hg8V1H9Fb+oCNfGQ=; b=iRhpMCrpmb93p78yttMF8+Fa4PKWrnSrZBkisJzWBrrsU4r9Sw3HUgWqS2xPiPMc6z3fVZ Zzk0UYMhnsJuB54rDaZ2KJCTxUOQrhL13Bib65gwk/Fbqx68SfDgaXKHEXit0EugYMrbWz ldId09VlzCA4SVJpUcMYTvhKW9j+OXI= X-MC-Unique: 6LQe5KMvNl2nCJ5O0yFuYg-1 X-Mimecast-MFC-AGG-ID: 6LQe5KMvNl2nCJ5O0yFuYg_1793124898 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Subject: [PATCH 06/11] hw/s390x: mark 's390x-ccw-virtio' as a secure machine Date: Tue, 27 Oct 2026 18:13:55 +0000 Message-ID: <20261027181400.1752951-7-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-1-berrange@redhat.com> References: <20261027181400.1752951-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: 6pODIZH3Q7Nl21E_0QSktPJ4qTNmuxh9X8RZ-SRlyQM_1793124898 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793124907-73CB82A1-3E95BA19/0/0 X-purgate-type: clean X-purgate-size: 1225 The 's390x-ccw-virtio' s390x machine is already declared secure in docs/system/security.rst, due too its intended usage in virtualization scenarios. Reviewed-by: Marc-André Lureau Acked-by: Cornelia Huck Signed-off-by: Daniel P. Berrangé --- hw/s390x/s390-virtio-ccw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index fda5ecc9ad3..15b16ba99d0 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -986,6 +986,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) \ { \ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:25:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:25:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462439.1673442 (Exim 4.92) (envelope-from ) id 1xLlri-0007bM-Vi; Tue, 27 Oct 2026 18:25:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462439.1673442; Tue, 27 Oct 2026 18:25: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 1xLlri-0007bD-Rj; Tue, 27 Oct 2026 18:25:42 +0000 Received: by outflank-mailman (input) for mailman id 1462439; Tue, 27 Oct 2026 18:25:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlrh-0007b6-3O for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:25:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlrg-00A1uE-GY for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:25:40 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ec9f-bab6-0a2a0a5309dd-0a2a4503b5bc-14 for ; Tue, 27 Oct 2026 19:25:39 +0100 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 6ae0eca2-fae8-0a2a45030019-cddcb4830b48-3 for ; Tue, 27 Oct 2026 19:25:39 +0100 Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69RIIJGg3486811 for ; Tue, 27 Oct 2026 18:25:38 GMT Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4hjjbtbuga-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 27 Oct 2026 18:25:37 +0000 (GMT) Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-93caf7856ffso13215885a.3 for ; Tue, 27 Oct 2026 11:25:37 -0700 (PDT) Received: from [192.168.69.229] (82-67-153-177.subs.proxad.net. [82.67.153.177]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ecd37f4sm28457361f8f.44.2026.10.27.11.25.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 11: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=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:References:Cc:To:Content-Language: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= 4XLiomQ5/ZQQqJIKi2eA86vXUSMhCvCaUYYNDKbeFLY=; b=I+FxSk9Sr95xLB2X uwvSjsPgTHMJgc5OGaqC61pP5R0e2i4mo3aJTnNe4SNlZwvqaVbnQPRf8dnhsN2C 8SkDkD0vXIE79p33s/2Sjm5JbtgpTFjp5cAv2XjDL15Kl5HNPFAFi0ogUkxy7p65 o1OhVdAZXnayylAEEW1OCEXaOtX7swCII77TaEZjk7uNQHd+KEZoeCTiw7fSP3o5 5hEQIWpJBSqgnHQdbgPpeBrNrdcSIoXM+wDgDomcgLWJHZ7ZVKccvdIJBFgA+E86 tUEI6pyQl96fQ+jqOGz3r+T2V/+ywGOFkwQlsNfchB6EeF0f8sMDTPeJmeONgkl6 DcpFQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1793125537; x=1793730337; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=4XLiomQ5/ZQQqJIKi2eA86vXUSMhCvCaUYYNDKbeFLY=; b=j7M4Y7NOc1qZwpaNywVIN1zWVO9qSDhJcnm4qz6m14KV+fR0fV57rTERTEh0aFnFE1 xkE1WSz2IV/kE33YV8Rm8eTPOH4B3b9B/xT+MuHwJCL3vBCaexcF378YyUn/YCNcBYsn QQctlFQ7R9WSBuNCyKjNIDxZLn2qy2/1PYQ2kdVxHi6EvhtwTEWLYj//cqkoQxol8Cfy GZGxN9sd7EV5y0YIyvUgsfJMtxGSlohIBlbROdrSppK5iPuXgv5f84FCMrE+JDnSm9EU 6eWql8/kefOJveP5VbY0h/7rak13bLBqMxvHNOed5PlW0PswEDuoVT6qnRUXzEsiXHxQ r2zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793125537; x=1793730337; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4XLiomQ5/ZQQqJIKi2eA86vXUSMhCvCaUYYNDKbeFLY=; b=UruyY/xcQdK6oMJCjlHls6NkaWdt7ifnibH4orQJWXK9LRFoxxBWLQ6WuL/gw+QnQF Iz7W76a5TkkUdlNHKvfFgBvwRPSAtoF0a7IOiMfXRKS9+Nlae7Gu0RYo5y67MjUyNj9S XNJ2Ar2cWRTIJfiD/u1nkq9T80eZmvSmCa5l9blcHFJxsMVTAl52jTYPJq0SilaxYhAS bZ65ARHB4TN3TLh1pLsX4/5Yo/xkj5tD/fuihGgFLCtXqceAisGywUTL93bbvNnF3Gbh jG3TQhhZSSFNY8FbbVaXyj4yWo4qlZgBbb3qLf/Zts5oFSSzRaDnQyGcJ7PJugLaUTvY 98Lg== X-Forwarded-Encrypted: i=1; AKwUvBw9YLs1wNTg6Z757rzR+rF1ledG7217nrynLaJbmvU6pEcthv9lXgx6G8//KMijTqchwS/dTxUpVMQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYIQNoH3W9GJUjVauGSq7d0DxljCWKwvUO9b0CwKYW8IMcRUaUvt Ng6QXdBetA0sh65bfiPNmluPTD49judsdNe4lnVDXWGSyuz9D43cIInhsOnv5zBGJGFdenEffJn +wMBHuz75YENTvjOTXt6/Wk9tzc9yd/U0H1CTmQRBPU7Pjzt4tGy8H14dhzXA1oXorHBHMA== X-Gm-Gg: AYBFou0YT8IX8/5jmMQXPOsCklJ7sNH5UJDCLuocIw2djXX9QcnAOYJT8FtOmzh3gSr FI69DRtclxpNa9Q+13DFqJO4Y/ubq6RqVhrrNPoAqiQyS5Km6l2bBpUyZr/cGrmbMbgEJfjKEAY nvP3F9e6JCs+U0r69FUIqjdX1KVLWwqeFA7W4Tm2qv0FE19JuxWxG8C/f29GLT3L19hy9r5iX9B J8M4v0YdeupC6tEgSVzVjXc1Qrh+DlaOjLglRwUOQYRzQeI82RAnoPTIYLqam4zv1eddxQ1isVT YXG8U3RS1oLth9qxB9jHoRfnqIikrgDy5yZx/rId/B9wXM/u1SgVHJUyB4Y86MY6tx790Tf7FDK hxT7GnQjispRAmSWfv8w9TJc66hJ7qQjygVCqcnw0tZM+jZhKgWn8zzVniYhP1TupTMLhqxTJJt AMt3n0s9fJ3wDn3VToTekVLuA= X-Received: by 2002:a05:620a:2987:b0:93e:5247:f61e with SMTP id af79cd13be357-940ef8bbf03mr1581123785a.25.1793125537157; Tue, 27 Oct 2026 11:25:37 -0700 (PDT) X-Received: by 2002:a05:620a:2987:b0:93e:5247:f61e with SMTP id af79cd13be357-940ef8bbf03mr1581119785a.25.1793125536648; Tue, 27 Oct 2026 11:25:36 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 19:25:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/11] hw/arm: mark 'virt' as a secure machine Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= References: <20261027181400.1752951-1-berrange@redhat.com> <20261027181400.1752951-2-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20261027181400.1752951-2-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Info: AW1haW4tMjYxMDI3MDA3MiBTYWx0ZWRfX9HIDZJqv5+oq vIQc9yAPgOqHom3zNZEu3UPQ3it64DNdMdmLykfvcVfV3OkpFYfR1J2AaNNeBRFyiO+Hn48eAX4 w8GZx9l0KK8F3KfRp5zY5mqBquo/FAM= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI3MDA3MiBTYWx0ZWRfX+g48qS2dcbxZ s4J+9RXlz1A54lq30Et2LJlMr4t/4fUTd7z0irm9wuZIoy9tnhueyL74Bp4lQ5w13c4g+gL/5hz Lf4CBN7EbiqmD9Rv95MkXxWfFVXDsaJFcxlBftpohV+s91lkAipoGiA4TSnhMjp4E3KVHg8DKCx kUvHFBJGoikU3NJXaRx/ONYhBsnHyzAGLU1m81QXdvJHsk4/l68jLj6Sq1+Hx4oK0GgRgnMWfQ6 yOk/yApt/R7kTEPHDX/gWhQ1Hlb9Y+wJcRN1pqFl1OyoVqBJW3w2YCP1uKyIacQTJ347YFBaW1s WuqEpyOQiw1KPXgkKu1CdSlkvpx5XkN2Ogw8ETVaa4L5Ero6KZNWlR2NSeVib53uoIcOCj4OyWG vIimnh1UlFDuOaTJA49Ibbxg/mx8HIBrAnRQwigNPIjV81OPpfAdFzcQcui7WSrBEkNFiH2W2jf 6TYUIWchVP2xmgynMRw== X-Proofpoint-ORIG-GUID: Xlm50UgvYdN0UI-k7U8L1vNO1Rj_js9_ X-Proofpoint-GUID: Xlm50UgvYdN0UI-k7U8L1vNO1Rj_js9_ X-Authority-Analysis: v=2.4 cv=XaIcX455 c=1 sm=1 tr=0 ts=6ae0eca1 cx=c_pps a=hnmNkyzTK/kJ09Xio7VxxA==:117 a=nz36NW0qrpeEijYxj/H2Ew==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=20KFwNOVAAAA:8 a=EUspDBNiAAAA:8 a=XauY5eRjrSQ0cOF71_8A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=ZXulRonScM0A:10 a=PEH46H7Ffwr30OY-TuGO:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-27_05,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 priorityscore=1501 clxscore=1015 lowpriorityscore=0 suspectscore=0 impostorscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610270072 X-purgate-ID: tlsNG-33051d/1793125539-6FAC44E9-66BB097C/0/0 X-purgate-type: clean X-purgate-size: 456 On 27/10/26 19:13, Daniel P. Berrangé wrote: > The 'virt' arm machine is already declared secure in > docs/system/security.rst, due too its intended usage in virtualization > scenarios. > > Reviewed-by: Marc-André Lureau > Signed-off-by: Daniel P. Berrangé > --- > hw/arm/virt.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Philippe Mathieu-Daudé From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:26:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:26:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462441.1673450 (Exim 4.92) (envelope-from ) id 1xLls6-0007ue-6z; Tue, 27 Oct 2026 18:26:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462441.1673450; Tue, 27 Oct 2026 18:26: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 1xLls6-0007uS-2R; Tue, 27 Oct 2026 18:26:06 +0000 Received: by outflank-mailman (input) for mailman id 1462441; Tue, 27 Oct 2026 18:26:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLls4-0007u8-DR for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:26:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLls3-007aE8-JH for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:26:03 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0eca9-e002-0a2a0a5209dd-0a2a4504d1fa-14 for ; Tue, 27 Oct 2026 19:26:03 +0100 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0ecba-b57f-0a2a45040019-cddcb483f236-3 for ; Tue, 27 Oct 2026 19:26:03 +0100 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 69RIHPCq2945808 for ; Tue, 27 Oct 2026 18:26:01 GMT Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4hjrq6aevp-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 27 Oct 2026 18:26:01 +0000 (GMT) Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-93909014c85so17524685a.0 for ; Tue, 27 Oct 2026 11:26:01 -0700 (PDT) Received: from [192.168.69.229] (82-67-153-177.subs.proxad.net. [82.67.153.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a94c6d9aeesm405515e9.7.2026.10.27.11.25.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 11:25: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=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:References:Cc:To:Content-Language: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= sBoNYG2/VLOCXr5s8H72Fe6tRbiTjTU85h25ejei/N0=; b=mD8CnZgQxE1oa5j9 qoKXWXheKVZzLxGFCQd69cVdXqPCuWdkXjtlYVB1vx1TpHS4ssqwqthhF4DWGHJ0 pvrzS9FXFH9ZIjGLBLuPqbb6Qa23faQ7wjIwvQ0CHr4TVyUctIEUdCjtiGeh27fp UUCi0qykQM2tjuwixbr2fuk2AVp/UwYUVoZ8+gduFzvLxTBKdLpC6pR3tM/7q2C4 XAS+3ilcyVcxwQQxbWc/6VcuUbkm567kosgeRC1AOdYsVsLteX89eCWUAAW1YYJG 2xB17lmoRe6Wm2/gtcgLnzc5MVnPDGHTJR3QXJpWzv/WiTRrUzm7DDu0VkE1g2zK HkMDrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1793125561; x=1793730361; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=sBoNYG2/VLOCXr5s8H72Fe6tRbiTjTU85h25ejei/N0=; b=OeJDcC7b/GbX/itaXNPmfwb7aoOQDrpznNnsSiwzBqgFmzVksCmdzOu6Bs0+jR5Dej Ts2OmhgI+bERxldq08ArtQSkSTjeKaSLxb4FhxBuEEWCgk6dCTMiSFQBMrx5q1RkeM6b 7Bow0PYpTRO9pUuimCNR5/SieUUs/NkCNArQ/DvAyUD3HP5CE4rC1+mkZkYTM0oX2S7R QH2lYZk5Vo1myN7wjIJ9ZMG/9dQjiVR2XjWifrWckXcoZ+kiiA9ZiP9gaenl8BUUst9A KabM68KKsoEi5KFVN/Z0aGiavg4iblIS48W2tI2zlAu7+B50WSzkszbq3ogAXm4FFz6k 89Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793125561; x=1793730361; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sBoNYG2/VLOCXr5s8H72Fe6tRbiTjTU85h25ejei/N0=; b=170o3w3V9RnQ3A7KOVcYqM/+amtMHwnxqGeWq7qK+4ZzrtcdNTZmmwF4zN3iAJndnw sG+qyptn3iSI1/VugsGSBb+Eq4uqeu4U2opEX5k87s3XpBfhVa7VXGUwKpZb2UhHRKTQ yiBsw3R6UbAiPrvBQXFNpCLADDGsf4U7c+NVI7zYdhWoVllRbGllzZTtlM5lTOgFq5MU 8m+p1XtIEkJZE9dtr7Hza8PmlEVGXoY78WOClJ3lLMpDb7gzwSrorRj27wD31erP0ol9 F2rTNe8kAfI4GKKJ3DTu9rQKpaR+XYUUpu5+q8uRdSaWLyGCBEUF2KkIU+2ZCoa1B/DU u4mg== X-Forwarded-Encrypted: i=1; AKwUvBzqNuYcFHo8/9qbMjXBB1UIXMuEF7xV3xkdrDEiNwiwlXHCMYtAMANUIkNoTtMKKNmaugDPBabm8+0=@lists.xenproject.org X-Gm-Message-State: AFq9FYIzM/M4lAI7WCO3lMH3YghivKT0fzdVg0aH/TujO431A6aU/f0T IZFcCQcRLetL7aho+eI3ycJ0fTHccvUbdl5AEUQrsJhc1R769TwmZh98P6Ma0xUsuECJbMjyBL4 e3/qePN8MC/I2jeJ/CPGCmLNbqHP/gpV1+Q4t/hMW3S5vdTyxj9MQOMIZUDsjeZ1rynxK5A== X-Gm-Gg: AYBFou0szmuMwSBsSAUh5Z5MLWKcXSQU3+upibI+sxbdb3pieIhHzqGMML7oyqojzQG rZtWM1MIRwwJ5nzBWZ3sHadEDLXfxy3MomyiRCJ1ucORW0zhKUpgkDyl0Q2ZpqM8anc1/l9Zdwl A+ICskqRdl+CnXI77S/Qgw2qDc3QISrDMwlsc6o60WfG1WaaYsjQjlIitTyn9d7mkvgrnhc4iPV oUDbaDlcmYEGkxh2q/g2/abGj9CqfnRKYv+uWSjbDU/KviTYDAhf/leWUUukFi5xtAjS6BMD301 wtK22FKkVADdjjc02hI8vaabDz+u/mKluxz0AslYK6UZEgeCWCqrThvr09NDlyd+lJiPHrj/tg2 LGsJTmeZTyeH3oC2THYoYuU8PLWQgLDu58C+6Hnk99fuGZFELhQ== X-Received: by 2002:a05:620a:1b98:b0:93c:6f0e:8468 with SMTP id af79cd13be357-940ef8f0788mr1681987485a.43.1793125561024; Tue, 27 Oct 2026 11:26:01 -0700 (PDT) X-Received: by 2002:a05:620a:1b98:b0:93c:6f0e:8468 with SMTP id af79cd13be357-940ef8f0788mr1681982485a.43.1793125560576; Tue, 27 Oct 2026 11:26:00 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 19:25:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/11] hw/nitro: mark 'nitro' machine as secure Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato References: <20261027181400.1752951-1-berrange@redhat.com> <20261027181400.1752951-9-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20261027181400.1752951-9-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=RYwFmFtv c=1 sm=1 tr=0 ts=6ae0ecb9 cx=c_pps a=qKBjSQ1v91RyAK45QCPf5w==:117 a=nz36NW0qrpeEijYxj/H2Ew==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=20KFwNOVAAAA:8 a=EUspDBNiAAAA:8 a=ZVfvRXNSK-DTiSIkpbsA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=NFOGd7dJGGMPyQGDc5-O:22 X-Proofpoint-GUID: r5OLTR1I_0zoMfmptNXaOuN-4NH3xaTN X-Proofpoint-Spam-Info: AW1haW4tMjYxMDI3MDA3MyBTYWx0ZWRfX2/60nCREqqX/ Q7BkKN1pNl5tKvxnGezC4Py0puVoQUQ4qFAjh2jnp4CNbUNrihWCrDTyT6bAuRjn65jg+8+aSZh 5Ap4Qr4lD0kn85GPqW/Ds3bpqR1S0bY= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI3MDA3MyBTYWx0ZWRfX7LJqPL9qyB0+ GogZzpq8CyoFUzCofayMvAuRbbF/WAFx2DyU1uLeLKiukiXPL9kJKUbK2uOuoKLdPHOKxaikZQr a/MbiF9A0J2+VMm7zaTYMAk8Lcchu8wiSR1wYTSiM2Fdl856xjfL7JEHgbEfiNJcH05wAHSCMg5 hwOjHMQDng4Yu7mYuxaV6vkXjVyVqCTEqZ0qVxNppvu2S8hcK+dHwA2juT0XiiRKDkVZF415hHg nzTnDrw8bhpbEDDAMQyu5/+2wucsDJ9zb+4IZf6AZDkywOJ/1k6wDnYRXtyukx3TDusgejlkOv4 iQwmI/JWihmTE6tvELfX4mniXOCCLvht7iAETqn0SC5LIODTqp8OF5n6e6dv8GwJ0p/s9eUONH1 +lUW7tbtzZtauw492BeMkQyhWN0P+jOMHTR7wHPe4VKHa5f2ad/9oMKq56St3lbn7v3yr3aGR4M pj/1H41E9nIJsrDRb2Q== X-Proofpoint-ORIG-GUID: r5OLTR1I_0zoMfmptNXaOuN-4NH3xaTN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-27_05,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 spamscore=0 phishscore=0 bulkscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610270073 X-purgate-ID: tlsNG-ebf023/1793125563-C20D5B50-5F1A3756/0/0 X-purgate-type: clean X-purgate-size: 414 On 27/10/26 19:13, Daniel P. Berrangé wrote: > Unlike the 'nitro-enclave' machine which provides emulation, the > 'nitro' machine is used with a real AWS deployment and thus is > considered to be secure. > > Signed-off-by: Daniel P. Berrangé > --- > hw/nitro/machine.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Philippe Mathieu-Daudé From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:26:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:26:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462446.1673459 (Exim 4.92) (envelope-from ) id 1xLlsN-0008Jw-E6; Tue, 27 Oct 2026 18:26:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462446.1673459; Tue, 27 Oct 2026 18:26: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 1xLlsN-0008Jm-A2; Tue, 27 Oct 2026 18:26:23 +0000 Received: by outflank-mailman (input) for mailman id 1462446; Tue, 27 Oct 2026 18:26:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlsM-0008JG-52 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:26:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlsL-00A20J-I2 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:26:21 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0ecc2-bab6-0a2a0a5309dd-0a2a4506813e-16 for ; Tue, 27 Oct 2026 19:26:21 +0100 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 6ae0eccc-195a-0a2a45060019-cddcb483b512-3 for ; Tue, 27 Oct 2026 19:26:21 +0100 Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69RIIC5j3486395 for ; Tue, 27 Oct 2026 18:26:19 GMT Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4hjjbtbukw-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 27 Oct 2026 18:26:19 +0000 (GMT) Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-93cbf2fd504so10166685a.2 for ; Tue, 27 Oct 2026 11:26:19 -0700 (PDT) Received: from [192.168.69.229] (82-67-153-177.subs.proxad.net. [82.67.153.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a94c021080sm519415e9.2.2026.10.27.11.26.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 11:26: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=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:References:Cc:To:Content-Language: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= rqvwCdeTzalXFMsGrT6m3x8p0RbZtnSwh+wuiUwhRpU=; b=GaFTzCbcWdxFOmss X1hmR8YF6qkazqrBr89HLjt0dkNHrMsLmj3744a08FVuScFjDSrh90yi+m6ZeHCY 0UU8XuK/tqDgKN3RSD51unGb7rW3rJME5p/5c9VYMUezsjXivQeV6CVILayDkRcq JLjRk9jyADcT2aDITWoEnGmWdrylCSBBaK0tddTBmypy5aWG+2SsEgLOKgWKl0Lb k7urQDtU6nDl3DhBQFdEpiDoVSYkUYp63o5VwexRSFmejyX3p9EUSdEMxhmVurEb BmDEPz4ceTwm795g/6NeGg2NqqIpv20jutiW1SkgQhCA4mSk+hSOSAthzCu+7L6b Dn8PDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1793125579; x=1793730379; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=rqvwCdeTzalXFMsGrT6m3x8p0RbZtnSwh+wuiUwhRpU=; b=HY5xecYKnlRfsu5jgRN/vHsocpvu7+pY/pKfGj8RUlPc6ATj9HxKqoiB34qSAAHNI/ D86UP4gUJe6mxT5Tfn7kgV5wbguTbqCfFyzes69nwnPhBQ9uQaBwba4Ow6BGgFEzBwN8 /sYa+fEUKtuCdFuWv/u1HZcO0ZAhmyeWIVssCG3OzhY2E7YecxjujAKAbB4WErfk/AUL 0Z0sVS+3a0YqS3+WlIlQdtjzeTqykSdI/SWO2v+cm32uYQEAlH8vd/aOYLapGUi76P+3 QTdLwjx95Z7AsHbLCpwK5E7XV75MSOq2BYAilBdEzfSci8HRqc8IWs8lcQIf48+Dgz9U kA9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793125579; x=1793730379; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rqvwCdeTzalXFMsGrT6m3x8p0RbZtnSwh+wuiUwhRpU=; b=yOw+zsVdk27olISGjUdWlwDxNSYoQ4piantjFwi+9v1EOPuZGaoJQS3ddDAbe3inB3 teXzSCQUEuRtsbj8gBMQafNnm8sxVDnbZB+CO3NSK2p+2PpDgotjqnh7AYrCzYKXGMYw IWbVtnmS7MalTkcZ6V9ocLhTiG67pR/EA2pRbBFpLtkTZGpPvckCu+QACCrJ5fZVhWW7 WkLnLP90+F/FeY7w1iPwilb6Fc0KStdVq4mh5tFjb928FKMBgxobwpQt3tMFkoe0DFxV 4MeDLfahvNhJOr1Y9sibZVo0wOnLlLkxqxm8zAGh1Hfs8+dTv4PelkRsVsTTGbwRr8/5 4OTw== X-Forwarded-Encrypted: i=1; AKwUvByZQ4op64TdcLMFrBSIxi70GFfospCtX0B3nMaMRqN70VkCkeA4Ll8zv+P6vnnEYofvbBiS8Cp/GSc=@lists.xenproject.org X-Gm-Message-State: AFq9FYJDAMvtjuoJd7Hkq7u0L5AoXr9ll+gvR0nVpCbQ1LPWi89m/XOX mo5T+c/bIuDBIzPqM6DqhUO6EpcJzv1Bur5eny/bzsSuSwJybxZMzfhDmF/Hf0qgJ6p5afIk4xe vNjvFMN1mbDOlI6Qd2lrFBzaGe2C/S9oHzdQssoPlJbq6B4PJYe5AH+kBjKWckteMWWuofw== X-Gm-Gg: AYBFou0Z4U8BLfDZ7JDDPxlfcBPIqPj6SFztA81W5APVPf09hkRaj1m/FMpcBCN8yZZ 7d2ux5cSZia3H+QZ8MyS31J+Ka34mzeKBHXzqMxKK7Jz/qiBelM3QfKbnVs4/2M0FPaQ0p3Dd8R eV5lcYSo2Q9ONYI16rM/wSsZHooEEvvMjxxGB5INKIyNCgxGLS5kmBGe6JzksSy8dFXVUYVuOY7 +71ivgV/6nsReNnrZDYWcMvXPezJIEO6FKFr9i5djN+p+YXAhy6TbN/D+bnai3U345uKVwkPSMZ 93vrd1g92jpjxAVUc+xaxVrLh8GDNfa5fxlXIVkAz6r237C2Orfmgw8qkbtGz6eoKgVSer+LbwR 8WO76sUQh/mGDRh7HuaXNjbyjpP5teInQ9MraXnlx6tMQ051Z1A== X-Received: by 2002:a05:620a:4689:b0:93f:2e08:6420 with SMTP id af79cd13be357-940ef930089mr1680121685a.38.1793125579131; Tue, 27 Oct 2026 11:26:19 -0700 (PDT) X-Received: by 2002:a05:620a:4689:b0:93f:2e08:6420 with SMTP id af79cd13be357-940ef930089mr1680116985a.38.1793125578678; Tue, 27 Oct 2026 11:26:18 -0700 (PDT) Message-ID: Date: Tue, 27 Oct 2026 19:26:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/11] accel/nitro: mark 'nitro' accelerator as secure Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato References: <20261027181400.1752951-1-berrange@redhat.com> <20261027181400.1752951-12-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20261027181400.1752951-12-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Info: AW1haW4tMjYxMDI3MDA3MiBTYWx0ZWRfX3cwscTLu+HHE tId2sklur1KqQwGl9/NHEERgsIHtznV+eaqVnAYRDmuFwMrmcCxe1CmPwu1GskZaRHIcwC8Yl8c iXRfWzUbDnqGWC6aFVl1J/jXl1w0HLk= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI3MDA3MiBTYWx0ZWRfXzdh90naxrkLB wFnUX9GyJbkfZAqwfuZ5lGdtJhiOr/dYt2D7naVhBV6g5JPpZYIbw9UUYj5OmiJT1JNiguBURRl t7SgJ5SXHMyZcnhE/a3P8Ro9y8V/5irQ23RKvGMSberdbmpLxy8OWUOfjonaT4FUixOjRJmb2Eb lrDZ5tQzrQ35GWs+5tORwVejGqyl3fMX2UHAenUEA1xVzfPkm/8JduJyrhm7J4VZry/ED8oTqnM j5VnrCbDs5BUxW/4kwpGp0c/9UpoBvDfqfVb4tdC3swHf+hVLzYSQ1APoqyL+y2emahjjEZBHhM O/8cZuxuPGtvo4uRZuH+8c/wmYK+S4yo25ec7sR7UTMsB4wQ3keW42923WCAy2VhVSJTPWWS62c nLESr+2OMk/3x8R9El1dzH6v36RHSRSgFtqHfjc+JZuuD/5P/sjkoFw2pObIMoPG9bKa/3+Ll3P rVIri6/IFKM3MsUHHzg== X-Proofpoint-ORIG-GUID: DwSLMXGMCboJ_EUrs3_vZ7-5ptZmkv5- X-Proofpoint-GUID: DwSLMXGMCboJ_EUrs3_vZ7-5ptZmkv5- X-Authority-Analysis: v=2.4 cv=XaIcX455 c=1 sm=1 tr=0 ts=6ae0eccb cx=c_pps a=50t2pK5VMbmlHzFWWp8p/g==:117 a=nz36NW0qrpeEijYxj/H2Ew==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=20KFwNOVAAAA:8 a=EUspDBNiAAAA:8 a=nhBbSb_fY9f1tbuIA-YA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=IoWCM6iH3mJn3m4BftBB:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-27_05,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 priorityscore=1501 clxscore=1015 lowpriorityscore=0 suspectscore=0 impostorscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610270072 X-purgate-ID: tlsNG-16d1c6/1793125581-F74C977B-48B5FC0A/0/0 X-purgate-type: clean X-purgate-size: 361 On 27/10/26 19:14, Daniel P. Berrangé wrote: > The 'nitro' accelerator is used with a real AWS deployment and > thus is considered to be secure. > > Signed-off-by: Daniel P. Berrangé > --- > accel/nitro/nitro-accel.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Philippe Mathieu-Daudé From xen-devel-bounces@lists.xenproject.org Tue Oct 27 18:26:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 18:26:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462451.1673468 (Exim 4.92) (envelope-from ) id 1xLlsb-0000Iw-PW; Tue, 27 Oct 2026 18:26:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462451.1673468; Tue, 27 Oct 2026 18:26: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 1xLlsb-0000Ip-Ma; Tue, 27 Oct 2026 18:26:37 +0000 Received: by outflank-mailman (input) for mailman id 1462451; Tue, 27 Oct 2026 18:26:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLlsa-0000Hl-BL for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 18:26:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLlsZ-0057Jy-O7 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:26:35 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0eccc-2eae-0a2a0a5409dd-0a2a4503cfc4-8 for ; Tue, 27 Oct 2026 19:26:35 +0100 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 6ae0ecda-fae8-0a2a45030019-cddcb4834744-3 for ; Tue, 27 Oct 2026 19:26:35 +0100 Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69RIHRZx2639301 for ; Tue, 27 Oct 2026 18:26:34 GMT Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4hjqf5tt5t-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 27 Oct 2026 18:26:33 +0000 (GMT) Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-93f322ef7d3so17564685a.0 for ; Tue, 27 Oct 2026 11:26:33 -0700 (PDT) Received: from [192.168.69.229] (82-67-153-177.subs.proxad.net. [82.67.153.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a94e6b8656sm23975e9.10.2026.10.27.11.26.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 11:26: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=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:References:Cc:To:Content-Language: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= 5gtNOSL9DkqGrvLv5HiCmciZ411PQzVsYtj0F/yuWWM=; b=mhWx35R6EzRfQjVN 1xH7p7SD7YTepkSQKvJRjnJdAwgY3XESWxBjR4e7n6msb3JPozQgoQDg0IxUxvi9 hh1y0NovGCLazoZMOvJYn2VAHMfRpp6z5/xUwqSWFKtr/SwyQiyWAJkZ36GJbrcZ tjsFwvJyI61eqNejUo0z1ji7yPaKzlLipLt9pj3r4nEbWVn/Fzz09FJXK9JSFAbZ ZzwCiBOs6tcDrhMUPVudgOC8nrmUw8KJgoNXP6ql2E1i1/5zSNRRCklwLpyCRxdA XYxo2Z62g5QP2nNWOWLa+A6cCrxb3JWGzPLY6TIq1iZnyMlyQiHezOf0cPJEU92M nJptmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1793125593; x=1793730393; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=5gtNOSL9DkqGrvLv5HiCmciZ411PQzVsYtj0F/yuWWM=; b=HzQKgl7IL0bLB1kNurWRrKRG6ENY4OZxmGOWOaC6GTaU3LGh8oUi4ME3ypKsZIkTOQ 2UtJv83rAd5V1dPzxtYsiVLREJCW3NzkrNhabsMo7NFlpuQLOpTyuuHetiBBBKlkMAVU ddF53yOIQD3+Ou6FDh3yl7oZe3JuW6rcuexbiDbONDfFxNDXaWe1WJ7wXNH4xIsSHuQL 4MEqek8j8U3FdK+NR/cYRFhu5RaBq36x2dRyT/PhJ/ra1NJL9norsJvOz1CFK5LGqFWT kWPP6ZBc03Qife4ojO0YQJ9I4NfQwvBT9pbHNIHf/gejPQfrdzXsC4tkc1eNVuLPF618 Md6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793125593; x=1793730393; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=5gtNOSL9DkqGrvLv5HiCmciZ411PQzVsYtj0F/yuWWM=; b=OaK4j3mgGiURMbgihFfhiiPDbXDCcq/ne6B926pI+7NmNhyfLAo0FBg7GA+bcJMrPk KIPjG3F9HnKO5MenGPZj+QPdZ6DA1DH4oSK39H5ZgjVJtKrGk8K6uNRecKJM0M62BEa8 5sHajERTFStBz1cpaSr5yhTbYIjjMEVSMB2ZXxvf4bbnxH+37Mi2zx2+0YX6a8Lotose BQhEpj99uJMJXxZniGicfHyabW4z9pZE2pcrWTccnfBVPGw+dzGJN/whiYM59ukmm+vt 6ObD1mvI/dtL4lWYrD0Il8Reh1yH2kfqlJlWGs3qUxN37I0xFbwLaSLpoMCM9B54R61v mPfA== X-Forwarded-Encrypted: i=1; AKwUvBwNBuM/pNn4vUjlqW5w9F7Bt5ZxLUzCnGPENTGlFohJm8zZwZ1uWBQhgbHQTq6KZcG2eQUYJXdFaxI=@lists.xenproject.org X-Gm-Message-State: AFq9FYIaXCzFqJJJWU11p8VGJmoeEtuuHM3xM3BrwcXD8/pR9wOBG9+w es10K/WVY2lXr4BT2pOTEloUARXBl+IVb7cf0D5iidrWcr7hchGvCsyv+hDN6+jcYoZX600aXfM zxeNihOqhzC03YLuE3PWDaI5P2fJXP7Ne6BrHOhYfRbSOYO6+9g2fTk1jlDpz0hGt+T1gxw== X-Gm-Gg: AYBFou1Ern0A2f8kx3QQbpR62F9vFne1QmJpUl/ofkiUMfFl4X4H7J+qCPYiIBvars1 Av2XNPrYpjsV6d4+lJcTnaZfkVI+07TgOMKamc0DPbuO9hMEnqH40m54ZXVdNeWLL9xqvpaBVld eCS7itbYvtXTmEimQDw2avULGKAg0eWKmkjm2WE7TdTOHL2GOUjvKFhLiKO93tDfXeJqgvm99fa OH0tB2CYzEs1gJKLXrqlN1w8nOrN7VHKZ5fzISL/bZBdF5v/BY4AGnQuExFuQlDRcYt5lZ+6qoV fK4Kz/a4ICHkozk4wwkrDTFrSaVNICCYJN94o5Jpt/ZTLhQnmiTt82n6ns5QFG1BNFn+85c7ky3 vEXMSP2Vm8xNXmuA01oABVqUYKQSf9OoN9V3UdE15OeBSNQ69TQ== X-Received: by 2002:a05:620a:2b4e:b0:93f:24c5:f561 with SMTP id af79cd13be357-940ef9457cbmr1583431785a.33.1793125592760; Tue, 27 Oct 2026 11:26:32 -0700 (PDT) X-Received: by 2002:a05:620a:2b4e:b0:93f:24c5:f561 with SMTP id af79cd13be357-940ef9457cbmr1583427885a.33.1793125592323; Tue, 27 Oct 2026 11:26:32 -0700 (PDT) Message-ID: <5ca7722a-cd6d-47eb-b8ec-4c93ef4d4699@oss.qualcomm.com> Date: Tue, 27 Oct 2026 19:26:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/11] accel/kvm: mark kvm accelerator as secure Content-Language: en-US To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato , =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= References: <20261027181400.1752951-1-berrange@redhat.com> <20261027181400.1752951-10-berrange@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20261027181400.1752951-10-berrange@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Info: AW1haW4tMjYxMDI3MDA3MyBTYWx0ZWRfX55QNVfX78GiZ Xrx/yMNT781snm4NwEv0oH/GmXaJMBYn0RuEdihFi3GU6rBjZszRyQo8omsrbJojDZrHjpNo8Gv EzsqmDydapDAWJwLsVEFDec15+ubWho= X-Proofpoint-ORIG-GUID: Z_hKpElPpi61y3DTO9m2mXsKRqDDwO5B X-Proofpoint-GUID: Z_hKpElPpi61y3DTO9m2mXsKRqDDwO5B X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI3MDA3MyBTYWx0ZWRfX7K5cakEiReow LSl99XZKqjqr0vh8UFtNZGGe/onFfcsBeM/vRLmZTlpFxZKnaP6Kbf6XwVJn4VoA90V76COmu3v 01CsSOsD4g2sea1EduSUDNLKZtKRGc05QRJu5A5FzaeNuTwXeRN+wp1aEG++EeQxpwi9KIdmXJ3 /sjV6T427E45RvppjknbgT08AyIvAGP1HpJJlkF+85/khh9KGa+x/ddiGq80j+FMmUG+c9c9yeJ v3AV7e/kjFGSdNmp0vN2kEzsqtcZekHVfnAurmU2R++SLtNB5cwAtNVZxVtrHkGt0Mvl+dQxtGg 44zUv32oR41zzglGH8Rwkg6C/NsqUFfaa7REqHbqs9gF28N4FPEEbouuWPLxmbFISc2z9KDfHOU vzAsW/SYCvAN92+ReVCIWyWnNosxiLFbIJ9m8ZgWx6GHjTP650mNpIxcGOpA9KtOvA9n5IK+x9K aieS3iOCgeRWcFngrvQ== X-Authority-Analysis: v=2.4 cv=UOFIjyfy c=1 sm=1 tr=0 ts=6ae0ecd9 cx=c_pps a=hnmNkyzTK/kJ09Xio7VxxA==:117 a=nz36NW0qrpeEijYxj/H2Ew==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=20KFwNOVAAAA:8 a=EUspDBNiAAAA:8 a=R0rOnUjNbK5cqpqgS9oA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=ZXulRonScM0A:10 a=PEH46H7Ffwr30OY-TuGO:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-27_05,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 suspectscore=0 adultscore=0 clxscore=1015 impostorscore=0 spamscore=0 phishscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610270073 X-purgate-ID: tlsNG-33051d/1793125595-6F4C74E9-63965E81/0/0 X-purgate-type: clean X-purgate-size: 419 On 27/10/26 19:13, Daniel P. Berrangé wrote: > KVM is servicing virtualization use cases which must provide security > and actively maintained. > > Reviewed-by: Marc-André Lureau > Signed-off-by: Daniel P. Berrangé > --- > accel/kvm/kvm-all.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Philippe Mathieu-Daudé From xen-devel-bounces@lists.xenproject.org Tue Oct 27 19:19:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 19:19:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462525.1673492 (Exim 4.92) (envelope-from ) id 1xLmi0-0003Y0-Td; Tue, 27 Oct 2026 19:19:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462525.1673492; Tue, 27 Oct 2026 19:19: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 1xLmi0-0003Xt-Qv; Tue, 27 Oct 2026 19:19:44 +0000 Received: by outflank-mailman (input) for mailman id 1462525; Tue, 27 Oct 2026 19:19:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLmhz-0003Xn-3D for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:19:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLmhy-00A8cT-GL for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 20:19:42 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0f924-2eae-0a2a0a5409dd-0a2a4506811a-38 for ; Tue, 27 Oct 2026 20:19:41 +0100 Received: from [40.107.201.34] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0f94c-195a-0a2a45060019-286bc922ea2c-4 for ; Tue, 27 Oct 2026 20:19:41 +0100 Received: from CH5PR04CA0012.namprd04.prod.outlook.com (2603:10b6:610:1f4::28) by IA1PR12MB8312.namprd12.prod.outlook.com (2603:10b6:208:3fc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 19:19:32 +0000 Received: from LV8PEPF0000005F.namprd02.prod.outlook.com (2603:10b6:610:1f4:cafe::6d) by CH5PR04CA0012.outlook.office365.com (2603:10b6:610:1f4::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Tue, 27 Oct 2026 19:19:31 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by LV8PEPF0000005F.mail.protection.outlook.com (10.167.245.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 19:19:31 +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.53; Tue, 27 Oct 2026 14:19:31 -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.53; Tue, 27 Oct 2026 14:19:31 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 27 Oct 2026 14:19: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=EVfF/vXqg1FUTwiaHYL6nYQXsL4vFljioTQ5XHYK1J1c1ibKoKCu7AZGhhFlyf0WPfrhtM1ODn0P8myeEcxv/eHQhUVSrHRxns4Gu0rm2Lmz+fdsOW8bt9AqrXqZkTJDxsW8SxjMRjEmSEzYANbt6p9ZeR/Ox3QxYUBYig1W2oIyIx2ltklrXIq3M2B8Z5pqqQ9pAcB8vlpyoRgU77faTMIpQrNdRcpDT5CQ1WOsco4uC/vbyjbmbS6l16gJDXTswygzhWaj6epFu45gpTMzcZrGWE04T3SHnDiqfu01uMGBKMKtM2FQbpiYdt63jFzJWKBchv6yHKItLpmqoIsD7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xgLw99O5rK3mJ3/D1pRGmjU8Ajn00l6hs94fnBFb4cY=; b=AXrQK8ZNP9BheFIxWzfZaFlcD7qrVKyxw0zJNXtzehkPG6O6UON1ogBiLHc40JlPUpSeZkjnnUqEWS+cK4ffrEPnD5j5vA5yThc7JAVIlMtSMq8syCN0WrRateMlqjIMZpN8DBqylcS378wzW6HpB9V6hEk+Ik5DSV1M915sHlyhE3DmQcew7yY5BnPh+c6W4dJcweBJtSlCPbCAB6AeIONmoCadnPPK+cldc1/7xKkL6ELlFG2dBwYiW3ztoyUJh9LFMwqD4XqS8EAFvbcqeo6ZqXadSZ8kYZfYjI2eb1N+eROSO9XX36A70i9vrQJ047zkMAuVt3deJ39+JB7R1w== 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=xgLw99O5rK3mJ3/D1pRGmjU8Ajn00l6hs94fnBFb4cY=; b=A2+hv2fwXcZLjcs+yw90nfEHwvhJZ2WMp3xJw04XD5GDyIh21BxV8ojlomkmA0z7qC2+zc1igmWjnfclSH+ERCQXAvf3JHzLm3Ycvj5aIud7PaULUzKERp6yrcCgq1NY5ZiyvYkbJqihc1BI9AiDrNC/z0Ju/157P46BVPG2Scc= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , , , , , , Subject: [PATCH v2] x86/mcheck: keep the banks past the end of the CMCI map polled Date: Tue, 27 Oct 2026 12:19:24 -0700 Message-ID: <20261027191924.1844282-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261027001315.2614976-1-stefano.stabellini@amd.com> References: <20261027001315.2614976-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV8PEPF0000005F:EE_|IA1PR12MB8312:EE_ X-MS-Office365-Filtering-Correlation-Id: c7df3a36-25fd-4f66-ea55-08df345f3a68 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700016|23010399003|1800799024|11063799006|56012099006|261021121427099003|261022105027099003|261021123027099003|261009223027099003|10067099003|22082099003|18002099003|261026140227099003; X-Microsoft-Antispam-Message-Info: QgO8qOF4/H71ZgNjWPA0ltVR5jcSv/UUbF4tCFcoNidIIcUDgLWZ4GeCN+4bPN/y5QpCxaAFj2DMTWJ9DUDUQ7brlZw6eULbXusthhqWBfRQ3yL4A+PsJ2rRThstIxIwAQerL1vQ+/09Yp5rk3DPLeRRSOIKAeyRq9EbtqPIJ6yefuWCYb6RmAbYOnPsGE7Ptj6Whq0+6zp9Q4ZKw1NMdsWVf2Yg9qd+AXmilhm6FV3t0sxs/omWrw2LKUafRSqeBDrVl0TKERxRE5mnuwb2spqR361rvWnmmzKRlK4uPgzMpaiy7j39+1H+bK7SXIMD3xw8HqjvHJ8MaJKz7kuMhk9HVJoY4JAR1e1AtGJS6tCmAp1dQmzW0C+bI6EkZXR0CMKm7rW8BX+JptV7r5/ZMuxXQhvsmmQFIillJviKeWDXMaKxuJ4/RNi/VE0hr8MYMcTMZofNpZP9NJhprsd0a/H295pFLPr4lI2lpK46WaqW7Qr1PTJhqxb/+vI2X78Gbh+HfoUZo0zwTOf+687WYG7KDWrX/ed9dbBAV5yT8puj+UA2KYvaUJQdwFSH6uMZfC4HZ23C25nxmYaJ8pvpMu6KzKdaiylmSqkh0/nd9XEq4oKXV9x4sFHy4fL6JagbL1Ok9VjdCzo9AXxpqy/vunLBbK73wo9tnVnP9j6eTI+nyTgOl5DhMEQlzsDrs4VQ7J7/e0ViqEzndSdoa9f/+Q== 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)(36860700016)(23010399003)(1800799024)(11063799006)(56012099006)(261021121427099003)(261022105027099003)(261021123027099003)(261009223027099003)(10067099003)(22082099003)(18002099003)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: vo1E8RZ6/kL56FLQq3E9/1F7cElWua84OJcMHpjNgt5wJBPoIhhkvjrCxe23oh3r6HfIs4BTZsA95/Nzbz5tFK/XhbtmJXEB9S+OcncedAfiRGDGzwCcsa9nX75F/v54ZiovkVw/B2Y1DPlKkWAbwh8W060MCKfPmxXbDe2cy88hOabIoPeVGEK2WihosqxxYVLt7frtMHhX5Ymsl2jkD7pwRka02K026UBb8mey31VHcYTbqcr1lmrfcPRPBOB1cXZgCgWCYbvrwD71UnIArBeGr82YT53E78oA/kYmawaFiCpxSvprDcgGY8WQFBOAyiHsXvL79qN1qYkW41MPsY/wz3p8Uk2+Srzpykrhflz7S8E8Mgqicy2oYCOc9YKp02E3IWqGzTdVSgSnR+mvcvdPplZ7dsgVAiWvNrdrKx2xKY8MS8Is++lWPvvWSSLH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 19:19:31.5869 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c7df3a36-25fd-4f66-ea55-08df345f3a68 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: LV8PEPF0000005F.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8312 X-purgate-ID: tlsNG-16d1c6/1793128781-F7ACA77B-ED7B0BEB/0/0 X-purgate-type: clean X-purgate-size: 1565 bitmap_copy() copies whole words, so in set_poll_bankmask() it may clear banks past the end of the CMCI map that bitmap_fill() may just have set, leaving them neither polled nor reported by CMCI. Set those bits after the copy instead. Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU") Signed-off-by: Stefano Stabellini Reviewed-by: Jason Andryuk Acked-by: Roger Pau Monné --- v2: - reword the commit message as suggested by Jan --- xen/arch/x86/cpu/mcheck/mce.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 1888f22d15..f9a1389516 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -621,9 +621,14 @@ static void set_poll_bankmask(struct cpuinfo_x86 *c) { const struct mca_banks *cmci = per_cpu(no_cmci_banks, cpu); - if ( unlikely(cmci->num < mb->num) ) - bitmap_fill(mb->bank_map, mb->num); bitmap_copy(mb->bank_map, cmci->bank_map, min(mb->num, cmci->num)); + /* + * Banks past the end of the CMCI map are not reported by CMCI + * either, so they need polling. Set them after the copy, which + * works in whole words and would otherwise clear them again. + */ + if ( unlikely(cmci->num < mb->num) ) + bitmap_set(mb->bank_map, cmci->num, mb->num - cmci->num); } else { -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 19:43:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 19:43:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462540.1673501 (Exim 4.92) (envelope-from ) id 1xLn55-0008LG-Ni; Tue, 27 Oct 2026 19:43:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462540.1673501; Tue, 27 Oct 2026 19: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 1xLn55-0008L9-Kd; Tue, 27 Oct 2026 19:43:35 +0000 Received: by outflank-mailman (input) for mailman id 1462540; Tue, 27 Oct 2026 19:43:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLn54-0008L3-Ch for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 19:43:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLn53-003evf-Pb for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 20:43:33 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae0fed4-2eae-0a2a0a5409dd-0a2a4506e512-10 for ; Tue, 27 Oct 2026 20:43:33 +0100 Received: from [40.93.201.59] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae0fee3-195a-0a2a45060019-285dc93b4422-3 for ; Tue, 27 Oct 2026 20:43:33 +0100 Received: from BN9PR03CA0376.namprd03.prod.outlook.com (2603:10b6:408:f7::21) by LY0PR12MB281605.namprd12.prod.outlook.com (2603:10b6:404:21d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 19:43:28 +0000 Received: from BL2PEPF000352CF.namprd02.prod.outlook.com (2603:10b6:408:f7:cafe::29) by BN9PR03CA0376.outlook.office365.com (2603:10b6:408:f7::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.17 via Frontend Transport; Tue, 27 Oct 2026 19:43:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL2PEPF000352CF.mail.protection.outlook.com (10.167.249.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 19:43:27 +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.53; Tue, 27 Oct 2026 14:43:27 -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.53; Tue, 27 Oct 2026 14:43:27 -0500 Received: from xsjstefanos-lx01 (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.53 via Frontend Transport; Tue, 27 Oct 2026 14:43: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=kpwWC40N/KQNEi7DByonJMlF+WDa3F0PoSdBoSzGPdCNvMB0CfapvSEpLvh1h/fq7PRhvvd5CaTmoDvF1d34e38L9hhzHJ8mZMlzTUguBjES4euOnyd9BupiBKERBwciwVoJsMjGfIDX/nl2AcdzKGicDZvmoZMR4oWY6B9ftslOGfDnyr3R0/nP4zDHWSWirKo+hJ1IZmy0X8vM4j8nTdREsjCmayWAqQUxK0Q5yrGlKnBhAmOVWv+CgLhzZi6dFjaJGlr8JuHhIFDuZ67Wc+fKq6DsNq5dgthnSQI1bigmTKqODUhKlXUDP6zQ+8rx0dyngT1FEo7qotwMwbmD1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jJibnbfwoo+ksIv0m66Pm5Kz9nJ7BlLjd5ziZav4PpA=; b=mRKElIcdnLtfoGaDd+QehBMRwgD/mRQm9lRoUa98qb5ps3XOuEm4vVZh2+QrOBzKrUOJcbfHYlghtbHnfpOiU0xbnCoafrVQcm6mn5MBEJmeefoCX+Q1isRyE6Z+7DhmciCDdaArto/ZJo8x8wc8VIqbPyA0qOaZKPT6Ls3z1blXxpU5MvmWME1SklwBFiF6ll1uqrJ3Lh+lUQXnJIsxHphqgMeu15D33sTTuHY0wthd7WtdIDjgiqLOFLuQhNj7RzgERFSbFmzCEIjZRBvmaWZmCvPlfqnZl3BwonWQtGyN0ct5FC1VeXEi5hW+6WQUxrYW5g1eoWT+/iCwUs+h6g== 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=jJibnbfwoo+ksIv0m66Pm5Kz9nJ7BlLjd5ziZav4PpA=; b=L5PolJALloCuXkHSsL/7ld05RlyKhcy0sFPZiRvmXKG4ZJeGHHXQdlJun8oCeBKxpa5gNiYl33cEJ2bj/+jK6CevcBhgR0Ns2RAiRrbYKXaC6OhJ0RUxm5DtA6Hf5lg6DYsYCkpSCav+01/yCCgiMMOiNbjs0wBQ9bRU5VmYdCI= 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 Date: Tue, 27 Oct 2026 12:43:25 -0700 From: Stefano Stabellini To: Jan Beulich CC: Stefano Stabellini , , , , , Subject: Re: [PATCH v2] x86/bzimage: Check that the payload lies within the image In-Reply-To: <19979fff-0554-4ec8-969b-6fe50606b1b1@suse.com> Message-ID: <6df73c0e-0d78-d7e4-3837-e4622271f02e@amd.com> References: <20261020214825.3655848-1-stefano.stabellini@amd.com> <20261026221008.1143527-1-stefano.stabellini@amd.com> <19979fff-0554-4ec8-969b-6fe50606b1b1@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL2PEPF000352CF:EE_|LY0PR12MB281605:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f82c602-ab69-4736-2dc3-08df34629289 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|1800799024|23010399003|82310400026|18002099003|261026121527099003|22082099003|3023799007|4143699003|56012099006|11063799006|10067099003|261021121427099003|261022115727099003|261021123027099003|261022105027099003|261022075727099003|261026140227099003; X-Microsoft-Antispam-Message-Info: RjABOAc3tWf4Xn9qKC6Ke1MjAHadDcYGK+C0zA7Gqm40ZgouOSDiPBbvKFVxo2n5kE27H4MlI1vT6mqvlHNWJhd82nhPy5POVgQAvGqqIsi9gNCuOf2IUMvelMrAsECeWXTE0VZeUSvGRQhgNZkY83bexk9iLOBOlZ61Q6TfD8Ha7qz4fxX+3P+8X9ulH+Pwr+y6fzyTuxBXu7kFdo8+cOGn1MjgtLTm//zDa8m73JDHxyBvF3hxynaETs7f2FWztIVNA0GTXbMi335xH5TuPyMY7C9OgNfXoR6gUxkouN2MZ7nZpziXUHZbuDOcqSBqBcCXRGzcmh8WjSd7LxiR54GlkVv30xqSPZvJubRanasr8+xFYr3LVwe1r0ifZYx1YSQqgn/KQNG8QF5vWHjEdWJTOxNFcL0pP7ZqlFHFCom++AUMe5dstIrMv0HQVgUCzwBV7IZgn1ntuh1Cjg6GNvE3T761HBe31un1FhEby5sbgHtHivGmXb+Y0nXeIkDFk4Nz5mEDaNHGtnWhZR4Q6nCI+SbIxrLgJnoB0ZlMaQYWVHvG6neA9kgP//Yzc4za5WYf8nX0hCA2wldu9B2H3Se1J9F68eJoTMDSig1kXDXGr6Fe/xtCgJpxtVhg4HV0csI9vWJvcCrdHYpFcm0OP1A8vp3QItwX0b6xyzsTDvGVimZRQiE4Hcp5SXipezHevQhfzKTJZBU+UnApVm7HuQ== 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)(23010399003)(82310400026)(18002099003)(261026121527099003)(22082099003)(3023799007)(4143699003)(56012099006)(11063799006)(10067099003)(261021121427099003)(261022115727099003)(261021123027099003)(261022105027099003)(261022075727099003)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EbfS6TaOsNgd7gbcFZ1Qt0mo1b+Bcj1aYV06dY73Us7XAFihIB0V2qOve/XssMD0xla42VoLp7yhqUl7qNGEhRY6/DmSwhYvbb3lOOBEtQ+FSvMhHpEhM0jpJaQfC6W1ckWIgtqO1x0F8gXeCiPUnHkuNoAmDFGHSFZV9LIFe9XnxaVkvYUJMiIYoeMb+7pMSaD7gy6kzScJO2PIjxGTrGee/bBvhYY3JoJJsPaMxiSTpFkvgIdBKHaI4ZUIYhdcGNIpww73UbUmbIrPdBT1iIAOOC99MTcv5jXnnSC0KrL7hp2RAyTmvsXPYvmf2G5EVJ9NvQjQRbKnWjquKOjJputFLN919zvFCvrS6Qsqke4ZFhhWd3Gx7QRRar8kEkHyXNc5ykZH9mLDdzKKTQUammsoAO3RoG4jRzhaaEJf3BxRjVp/hoNRRW7M4PpXRAMm X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 19:43:27.9342 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4f82c602-ab69-4736-2dc3-08df34629289 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: BL2PEPF000352CF.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LY0PR12MB281605 X-purgate-ID: tlsNG-16d1c6/1793130213-F6A7477B-C27D1372/0/0 X-purgate-type: clean X-purgate-size: 4694 On Tue, 27 Oct 2026, Jan Beulich wrote: > On 26.10.2026 23:10, Stefano Stabellini wrote: > > bzimage_check() doesn't validate setup_sects, payload_offset or > > payload_length against the image size. A truncated or malformed bzImage > > therefore makes bzimage_headroom() and bzimage_parse() read beyond the > > end of the boot module, which shows up as a fatal page fault, a bogus > > headroom, or a decompression failure, rather than as a bad image. > > > > Reject such a header up front. bzimage_parse() passes bzimage_check() a > > length which includes the decompression headroom in front of the image, > > so subtract it to check against the image alone. > > > > Signed-off-by: Stefano Stabellini > > --- > > Changes in v2: > > - drop the UL suffix: setup_sects is 8 bits wide, so the multiplication > > cannot overflow, and the offset is now computed the same way as where > > bzimage_headroom() and bzimage_parse() use it > > Upon looking again, I think this may have been a mistake: > > > @@ -65,6 +67,15 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) > > hdr->version >> 8, hdr->version & 0xff); > > return -EINVAL; > > } > > + > > + payload_start = (hdr->setup_sects + 1) * 512 + hdr->payload_offset; > > The multiplication can't overflow, but the addition can. Question is what > the behavior should be in that case: Adding back the UL suffix would allow > payload_start to go beyond 4Gb, but that may not be what is intended. The > alternative would be to check for overflow in the calculation (easiest by > way of using __builtin_add_overflow(), yet then needing adjustment when > backporting to 4.20). What about this From: Stefano Stabellini Subject: [PATCH v3] x86/bzimage: Check that the payload lies within the image bzimage_check() doesn't validate setup_sects, payload_offset or payload_length against the image size. A truncated or malformed bzImage therefore makes bzimage_headroom() and bzimage_parse() read beyond the end of the boot module, which shows up as a fatal page fault, a bogus headroom, or a decompression failure, rather than as a bad image. Reject such a header up front, including one whose payload offset overflows the 32-bit calculation bzimage_headroom() and bzimage_parse() use. bzimage_parse() passes bzimage_check() a length which includes the decompression headroom in front of the image, so subtract it to check against the image alone. Signed-off-by: Stefano Stabellini --- Changes in v3: - reject a payload offset whose 32-bit calculation wraps; the addend is at most 256 * 512, so a wrapped sum is smaller than payload_offset - drop "the" from the error message Changes in v2: - drop the UL suffix: setup_sects is 8 bits wide, so the multiplication cannot overflow, and the offset is now computed the same way as where bzimage_headroom() and bzimage_parse() use it - reword the error message - drop the dereferences from the comment --- xen/arch/x86/bzimage.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c index 66f648f311..a0cba65000 100644 --- a/xen/arch/x86/bzimage.c +++ b/xen/arch/x86/bzimage.c @@ -54,6 +54,8 @@ struct __packed setup_header { static __init int bzimage_check(struct setup_header *hdr, unsigned long len) { + unsigned int payload_start; + if ( len < sizeof(struct setup_header) ) return 0; @@ -65,6 +67,16 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) hdr->version >> 8, hdr->version & 0xff); return -EINVAL; } + + payload_start = (hdr->setup_sects + 1) * 512 + hdr->payload_offset; + if ( payload_start < hdr->payload_offset || + payload_start > len || hdr->payload_length > len - payload_start ) + { + printk("bzImage payload %#x@%#x past image size (%#lx)\n", + hdr->payload_length, payload_start, len); + return -EINVAL; + } + return 1; } @@ -107,7 +119,8 @@ int __init bzimage_parse(void *image_base, void **image_start, unsigned long *image_len) { struct setup_header *hdr = (struct setup_header *)(*image_start); - int err = bzimage_check(hdr, *image_len); + /* image_len also counts the headroom ahead of image_start. */ + int err = bzimage_check(hdr, *image_len - (*image_start - image_base)); unsigned long output_len; if ( err < 0 ) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 20:14:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 20:14:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462551.1673511 (Exim 4.92) (envelope-from ) id 1xLnZ8-0004z4-1r; Tue, 27 Oct 2026 20:14:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462551.1673511; Tue, 27 Oct 2026 20:14: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 1xLnZ7-0004yx-VN; Tue, 27 Oct 2026 20:14:37 +0000 Received: by outflank-mailman (input) for mailman id 1462551; Tue, 27 Oct 2026 20:14:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLnZ7-0004yr-1c for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 20:14:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLnZ5-003j01-Ca for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:14:35 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae10606-e002-0a2a0a5209dd-0a2a4504deba-34 for ; Tue, 27 Oct 2026 21:14:34 +0100 Received: from [52.101.46.62] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae10629-b57f-0a2a45040019-34652e3ed0d2-3 for ; Tue, 27 Oct 2026 21:14:34 +0100 Received: from MW4PR04CA0372.namprd04.prod.outlook.com (2603:10b6:303:81::17) by LV2PR12MB5846.namprd12.prod.outlook.com (2603:10b6:408:175::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 20:14:29 +0000 Received: from SJ1PEPF00002315.namprd03.prod.outlook.com (2603:10b6:303:81:cafe::63) by MW4PR04CA0372.outlook.office365.com (2603:10b6:303:81::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Tue, 27 Oct 2026 20:14:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00002315.mail.protection.outlook.com (10.167.242.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Tue, 27 Oct 2026 20:14:28 +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.53; Tue, 27 Oct 2026 15:14:26 -0500 Received: from amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Tue, 27 Oct 2026 15:14: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=a8n0aVYRVvPprDEU6pzhAsBtH+MSQMKwl7w9ps9fLm9nCFXKDGnL0VNun9c9nkV0NDY0fzF8C9zf9kwRIffLFWrgC0uExS4LzT0kUrFkbIWs6OLC39m+6w7SUGK2RxORc4lE23NFm7l9HlQjKVpO7bvQgWCY5z4U+t1cZkI241FUnZpwPNZlnMWLi873Y1ugLDXU0BYaKx2bjbj28BrfdUVZ420fF8081OmmJokCWSVLYSjzvVUb+KcsCdU5bBrzXef96bDXzGXNxihO4xTJlYSgRmIDED9mPOLPNCbzBr/0eBk3GD/Jp1NsUg2tZO3R0wedzrjvTRl+/gDUe1oWsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tc0VsvVfm6WuHGRWbAbKWgEuDSYq25/YDozURZfCBg8=; b=BdC/fMDnpQuMOUcIqdmn6GdwEMzBAyTszl8sepv4SdnVwHj3JHb+FxgZYJF58OYbhdLlHX1K0CxWoclnpoHyJwjUWFSHgYMM/T31X45IlJ/y6JIBzjlkwKdB4E9xSQ2JlBeFnD8zu6PJ8dWpbTtyrX9qg+FYE2VkMyC+gWCro43qVdrXnlJG//bK2l4PFlYF+QHulV3t2BGcJr/xtzVZqRp3hH7RcmoOVAsci+Gyp1mBgEZNC5nCSlkzRXCe5u+22HbFeq+NnsSpLD2/p/LIUV23Pw3r/fjr7KxHHMP09hq2CnoaYrmjFYTzcHrv2aBcQo6eMupx5fpVNdS1NTB4QQ== 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=tc0VsvVfm6WuHGRWbAbKWgEuDSYq25/YDozURZfCBg8=; b=a86l1vgB0VcRMm1FSdkGZ6/17NrdXZBlK0FiMaMHEEaiMtRGoQmVqYJQhXuafAAtpJQZbJJOd9Fl/VD7DeUaTFJ/NEiBExy2+zLuRjuUxnpEGzaY71oRG8N2I7CgtUuJlY49/LhWKhJHITCajEfu/8tbk9T6njec6X/eo3RW94I= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , , , , , Subject: [PATCH v3] xen/amd/iommu: record the IOMMU and device flags for alias DeviceIDs Date: Tue, 27 Oct 2026 13:14:25 -0700 Message-ID: <20261027201425.2405102-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261026235926.2105578-1-stefano.stabellini@amd.com> References: <20261026235926.2105578-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002315:EE_|LV2PR12MB5846:EE_ X-MS-Office365-Filtering-Correlation-Id: dfe0eb05-0ec3-4c68-4316-08df3466e759 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|23010399003|376014|82310400026|261026121527099003|11063799006|5023799004|56012099006|261021121427099003|261022105027099003|261009223027099003|10067099003|22082099003|18002099003|3023799007|261026140227099003; X-Microsoft-Antispam-Message-Info: 1v/8oGrmocFKO0ZNts583Whtl++0FvQWwzInPZq1xwgOpbfFPVx0rRX6UYhPzlkvZoIRCs6JXbiI2DYRYWYZTgexExhPNSd2W7VMKUJb+RBDQgXp/Dfln7spT4U4OGdjHbIh87uQegg9DlpiWYREIOsdgRooHKzgNmk13rXpXJ4DlsDK89Nmq/216dxt2Lm+qaBILRPSH1919q71m/AQ/aQi4MC9tCiI4trL4ELBfRMGWGyVhLa9VF/OKCnfyVNhm7aHpQJbcEUUUdH/ziiZH87n66EVA7jmjoCRbgHCaDrXW8feCou0kurP6gAlN1FvwxxB/RJDGF/aULdUzUvCsngwLSgSVL5sITsXtDKrcvkNpMUJJRpXy/hBggV+52V+Rkokd3yZi1FiP3Sq7yxccSjWE99F21i9qfe+NavHqm3RAZGR2+Ohq3a2Vo9mZuM7kc0RwMbQNqR8w+sVGoa1y6Vf8JIF61gZfNB4NfcJLDlWprGflJOuNLc8HwYWp3dUlpiJGfKTEyHeEICZsw2zWiuWjbcKDMMw8S2x/cuLcE+V3y2oaAKLYBdSAyTY2MmXoL6sTk3r1Zh2Vu86woWxba3FzPQcMSiu0YpbRZnmsFeFNor5PaBsTI2bdzYQH5OXIOxFgcwcRuW/7ensRV6kJ5zfw2Bh+GjOQsmk6ojly0tj4xmlKx7/DrNKdlx0cInbJMOGUSY/O4XGNBblSihRCQ== 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)(376014)(82310400026)(261026121527099003)(11063799006)(5023799004)(56012099006)(261021121427099003)(261022105027099003)(261009223027099003)(10067099003)(22082099003)(18002099003)(3023799007)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ow7mL4yN0uYzW1AO2s1AbXTMLYbmjjRs5F1+8RzTUTCoqZwTp7m5BJCKFxDVfW3GpX4AqDgKl/PTrevPhtiDem5G3K12uWd9T3mjdLBkAQ2qXgLS76Ftf6/mYON3AMTuZU1lLrCrpfBA5Yoks4d0SOCjhy/E2Q5eDAYgPpGkca8+HsyI+lxlA6gt8eXRY0UsIzBABEp/yvM1PFl7/5rqp9FuA+Wiu4Wih2HfZlsQ1spWFZ/6NRSBMSz06IT/MP506dqcT7TWrptYNnScV5mCan5Z7YuK8tdguvG7KeLqUbnjFPLf5OiV9ahCC6VQ3zIhf1Hk+RXIaLivmdAlZ3zOsB678h4V4oBHO1sS9M9tZWak/ZptBBmsW/gtp8gCgKb//xG4YuF+U12Q5ouCAj0YasPDIUDOk6JdTv0ppFEdc/x3rQ+QsHXw5nIp6bPZlJtQ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 20:14:28.1314 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dfe0eb05-0ec3-4c68-4316-08df3466e759 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: SJ1PEPF00002315.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5846 X-purgate-ID: tlsNG-ebf023/1793132074-C08D9B50-08C6F774/0/0 X-purgate-type: clean X-purgate-size: 3091 add_ivrs_mapping_entry() marks an alias DeviceID valid and may give it an interrupt remapping table, but records the IOMMU and the IVHD device flags only for the device using the alias. If no IVHD entry names the alias DeviceID itself, amd_iommu_setup_device_table() passes a NULL IOMMU to amd_iommu_set_intremap_table(), which dereferences it at boot, and the alias's DTE, the one applying to requests using the alias, is set up without the device's pass-through and SysMgt settings. Give the alias the IOMMU and the device flags too, as was done before the interrupt remapping rework, and as Linux does. Fixes: a3713b97e8e1 ("AMD IOMMU: Rework of interrupt remapping") Signed-off-by: Stefano Stabellini --- On v2, Jan asked about: - amd_iommu_alloc_intremap_table(): not reached for the alias, which already has a table when interrupt remapping is on. When it's off, amd_iommu_set_intremap_table() doesn't use the IOMMU. - find_iommu_for_device(): before, an unnamed alias crashed at boot with interrupt remapping on. With it off, a device at the alias failed to be added (-ENODEV), or got function 0's entry copied over the alias's, losing its unity maps. It now returns the alias's IOMMU, and an IVMD naming the alias is applied instead of ignored. - amd_iommu_get_reserved_device_memory(): the alias is no longer skipped. For XENMEM_RDM_ALL its ranges are reported once under it, not once per device using it. - Earlier vs later entries: later entries still win, so an alias entry can now override the device flags of an earlier entry for the alias itself. The alias's IOMMU is asserted to match, as suggested. - Other fields: device_flags is now set for the alias. The rest are either the alias's own or already recorded for it; block_ats is never set by alias entries, so using the alias's is OK. Changes in v3: - record the alias's IOMMU unconditionally, asserting that one recorded earlier matches - also record the device flags for the alias Changes in v2: - describe the crash precisely, and why nothing relies on the alias entry's IOMMU being NULL - add a Fixes tag --- xen/drivers/passthrough/amd/iommu_acpi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c index d118b36d80..e60dd675d7 100644 --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -104,6 +104,15 @@ static void __init add_ivrs_mapping_entry( /* Assign IOMMU hardware. */ ivrs_mappings[bdf].iommu = iommu; + + /* + * Requests using the alias go through the same IOMMU, and the alias's + * DTE is the one applying to them. + */ + if ( ivrs_mappings[alias_id].iommu ) + ASSERT(ivrs_mappings[alias_id].iommu == iommu); + ivrs_mappings[alias_id].iommu = iommu; + ivrs_mappings[alias_id].device_flags = flags; } static struct amd_iommu * __init find_iommu_from_bdf_cap( -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 20:18:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 20:18:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462558.1673520 (Exim 4.92) (envelope-from ) id 1xLncN-0005f3-F0; Tue, 27 Oct 2026 20:17:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462558.1673520; Tue, 27 Oct 2026 20: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 1xLncN-0005ew-CK; Tue, 27 Oct 2026 20:17:59 +0000 Received: by outflank-mailman (input) for mailman id 1462558; Tue, 27 Oct 2026 20:17:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLncL-0005eq-UD for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 20:17:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLncL-007nwe-B7 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:17:57 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae106d6-2eae-0a2a0a5409dd-0a2a450cb3fe-16 for ; Tue, 27 Oct 2026 21:17:57 +0100 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 6ae106f5-f479-0a2a450c0019-d155802ee02e-3 for ; Tue, 27 Oct 2026 21:17:57 +0100 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a3517554f7so2253095e9.2 for ; Tue, 27 Oct 2026 13:17:57 -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-48e3ebcb958sm24982630f8f.21.2026.10.27.13.17.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2026 13: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=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=1793132277; x=1793737077; 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=ATh9wI+eZXV8F4DwxJkBeu2dfkL4E8a3k8cFUhbqXxI=; b=TAW9OJWl+YLYK/efPqym3JPt+6EvddtSLre9nvHl626YxbU/pEds3HcFkh1rGtgL0Z dvGZtKuA6MTLELMWzb/8TlAh3v07W7cn/VaH4DmuSu4pNZnrVhGOYEPs9//2HYoPwyLw OT5RzoaVd1OpzaWyrFECrbboTKvQ+pbtWKsVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793132277; x=1793737077; 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=ATh9wI+eZXV8F4DwxJkBeu2dfkL4E8a3k8cFUhbqXxI=; b=1IiSPWYSF0N4bx0vQn83GcZSpWM2Y8Fo3EPWR7c0ojNOYfhFQ7P2+MTDQn8BAeFYqb VJ1O2kmdbJLiNrgvuKY42c2sRJCFaIgx4aRwl0wBYyucHQ3wr8jvf+WbscA5WeY8q4/O M31HrI9wnnGjcid2R0DEg2z1b1MSD0LNKanQUw+0vGuMeluY018K4Vb2HjEqcw9DvfQA mTJbBMKAapWNQNSsw/TJV9l/1Jbt/Kz8AQgzR2w7ugeaWeHmGb8q6C7Py7fjy9bcXyYT bm/0Jx23mjFLYHGeAYsCrgCdjrfcyPbZDe1r182MLW3RK3y3IZ0Aa7RTvvCWznmbzDaY eZNg== X-Gm-Message-State: AFq9FYItmycbxKKwArh8r/pvApQ5k6bwJSjsqC0DTbqDvnNxEk/YIohz OUuoI1Gtyi5oJTiYtkemwbSrEiER2y68g9mkXTPKZA84q9cqluG1LGIFqu6eHKTMRC1iOUf9dFx reMK9 X-Gm-Gg: AYBFou1tuQe289PoKgFBWxfCeJ6zz5larQux5Ey8auItMIAMibAYMCtJtDXkMVTWV+W 0DNyCDlT+uAHU9XskESrZWCqqUUinBdrR6VsKh1f+b8o+R0t/HkTT2d26yyqAFngq6X8gxkhHu6 L7imQRY4NkHoFZdhMxfGePhUiNFsRYwZf28F47zXZMkmR7gpTmfDnjClwfOt/BX5er0qxyIPeTp w9gOeNV53X9Q9MKcIyZpBn8Bx/xT2uwMS43z3Hy7FGD6bDahTRlJa2bQIyiemAlNUfK6yaSGWSE BsWoGQoZXy4eMghxoM/XeX4SyNeVYvfT6USZaaK5TLYrDyPGp+k0XADlL/LrNxcarj3+38JlRDH mSl06udS6eqljlJ0Ppn5v30tKondKHSb72BDnOKybTgXMhfLadtfcou2pe7LRXCONY1DxIbF5md 5d3982jA64kFh88n2YJpthEPJm6YgaXcwmLjv8eIK7xfYv5fslVhtaGmDiiPrp2wSw0Gcvm4Lu3 bNV5Yd8csafKpXzUjKronitqo3z3JPGq6c3Pbac5FzTphWDJZdBiSOkMcZx/FeGkbhiIQ9PcJYE lolMA224r3sXih+gbCtY3NkN0AT2Xg== X-Received: by 2002:a05:600c:4705:b0:4a1:7c56:d4e2 with SMTP id 5b1f17b1804b1-4a966587157mr804115e9.16.1793132276137; Tue, 27 Oct 2026 13:17:56 -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] xen/vcpu: Improve code generation for VCPUOP_register_runstate_memory_area Date: Tue, 27 Oct 2026 20:17:54 +0000 Message-Id: <20261027201754.1307173-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/1793132277-768DDA5B-9F666EBE/10/78276251493 X-purgate-type: spam X-purgate-size: 3367 Both XLAT_vcpu_runstate_info() and __copy_to_guest() are common paths in their respective cases, but the optimiser can't/doesn't merge them. Rearrange the code to do so explicitly. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie Bloat-o-meter reports: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-110 (-110) Function old new delta common_vcpu_op 1943 1902 -41 compat_vcpu_op 967 898 -69 and the size of the stack frame doesn't change at all. --- xen/arch/x86/x86_64/domain.c | 13 ++++++------- xen/common/domain.c | 11 +++++------ 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c index 533b0b21a00e..1510d593b18c 100644 --- a/xen/arch/x86/x86_64/domain.c +++ b/xen/arch/x86/x86_64/domain.c @@ -44,6 +44,7 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { struct compat_vcpu_register_runstate_memory_area area; struct compat_vcpu_runstate_info info; + struct vcpu_runstate_info runstate, *rs; area.addr.p = 0; @@ -64,16 +65,14 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) /* Update the newly-registered runstate area, best-effort. */ if ( v == current ) - { - XLAT_vcpu_runstate_info(&info, &v->runstate); - } + rs = &v->runstate; else { - struct vcpu_runstate_info runstate; - - vcpu_runstate_get(v, &runstate); - XLAT_vcpu_runstate_info(&info, &runstate); + rs = &runstate; + vcpu_runstate_get(v, rs); } + + XLAT_vcpu_runstate_info(&info, rs); __copy_to_guest(v->runstate_guest.compat, &info, 1); break; diff --git a/xen/common/domain.c b/xen/common/domain.c index b41be89cd0b9..2e6a1f9b98f7 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -2318,7 +2318,7 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) case VCPUOP_register_runstate_memory_area: { struct vcpu_register_runstate_memory_area area; - struct vcpu_runstate_info runstate; + struct vcpu_runstate_info runstate, *rs; rc = -EFAULT; if ( copy_from_guest(&area, arg, 1) ) @@ -2340,15 +2340,14 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) /* Update the newly-registered runstate area, best-effort. */ if ( v == current ) - { - __copy_to_guest(runstate_guest(v), &v->runstate, 1); - } + rs = &v->runstate; else { - vcpu_runstate_get(v, &runstate); - __copy_to_guest(runstate_guest(v), &runstate, 1); + rs = &runstate; + vcpu_runstate_get(v, rs); } + __copy_to_guest(runstate_guest(v), rs, 1); break; } base-commit: 8b0a70ddd29dec2f86a49c21e3664a21e281e859 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462571.1673533 (Exim 4.92) (envelope-from ) id 1xLoN9-0004lW-Ts; Tue, 27 Oct 2026 21:06:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462571.1673533; Tue, 27 Oct 2026 21: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 1xLoN9-0004lP-Qz; Tue, 27 Oct 2026 21:06:19 +0000 Received: by outflank-mailman (input) for mailman id 1462571; Tue, 27 Oct 2026 21:06:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoN7-0004lE-OW for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoN7-000vfm-1n for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:17 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11248-8faa-0a2a0a5109dd-0a2a450ab3f8-2 for ; Tue, 27 Oct 2026 22:06:17 +0100 Received: from [52.101.84.103] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11248-f2d2-0a2a450a0019-346554675b98-4 for ; Tue, 27 Oct 2026 22:06:16 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by VI2PR03MB10907.eurprd03.prod.outlook.com (2603:10a6:800:270::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 21:06:14 +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.0546.021; Tue, 27 Oct 2026 21: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=kOUicMGSUJZ2X7IYPTVE2EAGf9sr0epv7UoBFKrjqWAWR88kn6/8k3kjxhjeXlfjuwGSPTsphdV4CVrCZupolAd3vzqkkwUv323iF5hVcIINBUuLUwD6o1k220Y1rYs755ddYsPsIKi+mOONe0seYHVX4od9lKUu9wnomrNwLfxBAfLOXT1xs/FOxpT9xDAMVafHmFGl33QpkVUtHXnikdP3dvnwKVk5Tf5oBXMUQ6OIVkJXg0Gta+5xbHg0wF/dJDGJWMvf2L1DRQT+Ut9hrOUnXzjBpSpfNtopMOtpN4s+ARhkg1SAUCDuYrUtq3PUAU4NMvcqHZJraD+YlZN+Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4cyfaumX1w4tjPFbwgfNutCF5GcE99xOV7lTNRVbeK8=; b=is9ls//issebgEZSLq01G1ovEaHv8vUhqtnze1k2KZjkwSM3teODgtLbzYW87nvsOcQxbfUYQSxx0pCLFYiexMUpKChO55waCDlBOFsyQ1Cu0JdRWpLAfSoDLtBJMP6PMy0ypIQtWrrxaEG8bWvqEbxvnlHJNN2+an0kisIbzLomiEy3I15DZfsh1fuCwT0w23o9dz6YO7ZWHUiep8CBoEonHRydsv9Mcpl4dC/XXF1S1fybcR8q9imXL3ije3k88AMbAtAxsVJQw+89nqAnJlL9j3jocD5YyRzZg/UGrnm2FLr/Cc5DkZ5ty6ZJIDi7MfGCCvtJciTV6+QAlwVpmQ== 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=4cyfaumX1w4tjPFbwgfNutCF5GcE99xOV7lTNRVbeK8=; b=ME89FqHftpUq/LL7qVjrgjKt1GW21uh6bR/GutXjP3+5pmHVFFSbpiYFBtwEhxZ/BLV71MaE8TVD+qkOCIwtIg7D6d8yyg6PSRde2ZCrFeuiKOiZEQZNp1tQMp8a5/kxv1b/zBkVH8mEeyWTq9IRxVXyKBafORyqLZ9avdg18VImNmnZ3hcuCG7xYVM3Kh5y4I+Lyn8s1+AQ0+/8jNz3EEbOWGIMw+4Q8Tuq62ccJ4xvHOp5J9wBTv5myQ9IDF0TBEqyGq4j8QlqvzYd03a472DgYjf+x2f8NYNy3y0UASOV1rjA6QROfND6SAsR7bMO0Sn5oH4ttVkIjNGTppyICQ== 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: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Julien Grall , Luca Fancellu Subject: [PATCH v13 01/14] xen/arm: Add suspend and resume timer helpers Date: Tue, 27 Oct 2026 23:05:50 +0200 Message-ID: <8f526c4c563a61ee4d4700b545dfafb3530d108d.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|VI2PR03MB10907:EE_ X-MS-Office365-Filtering-Correlation-Id: 38d97da9-4649-4e66-235c-08df346e22eb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|261009223027099003|261022105027099003|261021121427099003|261021123027099003|261022075727099003|10067099003|56012099006|261026121527099003|3023799007|6133799003|22082099003|18002099003|11063799006|261026140227099003; X-Microsoft-Antispam-Message-Info: wTSvFWBtkHVJZ4BJ5EgHXToENkLmw9rJmu4bHCRDZ/2MFD7/TQPO6IhZXxudCFo6qfOVynNP958vBe//fgSLSTXk/tg2wWSGKWCOOhRNBoyBON73ycSjWoAYt/T3lqrsZksFg7L+yxw7y52j480Us1GjtsvATNdaOJVJhFllbQgW27GNmghS4LrpUgaH+IPUxi3jPJVQAgq54rCspJguFcnI+JCESe8MzI6AEhF+KzxMzNX/Q3ETFHVt280xcbEk5G/Xr5u3BmOIp60NTekUI8Zw6u8lWFAk3mgOSzkvd3EwZOqQ/mvVdqmpaX/JD9oInLlZSXrkzf1e9/hvNoF5IZ7aSsmS6eRo1MwbRkFr6JgSVni2hRGTWj3/tbHBClHZjxbcNFcjZxnQ9W24FaWSAlqhTZwcu9JpqimmpglHdMlqL0rShKIhGtLz594vDknS8WdhVb17pvspIJwY7bspEzw3/OiL2r+8pnsPHu84672JE9XhmRO67d4qODTghC3mzfUr1ilF6DVgxS04Vk6uUuiem+cg8IuDDWr9q2UremMd/2rAUB9YqrKC1skL9MdBcX+VAMCuLIVAXV1FN7MVXbB+GoLNXNaGfaQ98uFX8va35jxEL1um5BHayOQaVlUrb0gdlK0IXVwwr750Utb11opijr3DmEMRNrV8md45WkE= 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)(376014)(366016)(23010399003)(1800799024)(261009223027099003)(261022105027099003)(261021121427099003)(261021123027099003)(261022075727099003)(10067099003)(56012099006)(261026121527099003)(3023799007)(6133799003)(22082099003)(18002099003)(11063799006)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7VHLSPprJSf5vq2MrsaBx4iOhOiz/mpoN3tMa2W9rGK+hGj6feygbxrdjpDp?= =?us-ascii?Q?/pbwo1DF9l0PWZYGS2XJrzgdIUnTy4K4AuW5x3ekLCIFRC9E4lRJwmryQrhs?= =?us-ascii?Q?Ph3x9uegMSjaYM5ZokX63F1Z3fINrBc+a3yIv7wI3wrTpSjOVBt3hdrNYmOg?= =?us-ascii?Q?SwutfMxIMRqAEUn+jb6nsDn2/hRm7j4A0ZKpMXssSQ4ZaUKqNq6rlAeF9h5C?= =?us-ascii?Q?MIgrGQyqUcgzmCF1KPECd5cIQptEAnOtxP+/Fdy+NEle3W7fdAFa1K52hn6I?= =?us-ascii?Q?TMVcdIyC6ML4pODfkMrO7rEnkgBq0V2pB3B39eCD+2bajX+CYW8j3qd9Hdo8?= =?us-ascii?Q?lwp1VEwHEKhL8e3VewjkUpHmOGy3v576kjgBYQW9j4gjmC5lUNlEDbXyAIDN?= =?us-ascii?Q?V+WGBGqiZV/TDnLwlX/5BmEbCpc7UGPi02H8BQErAp1wi7RY7iUe5RJ/QiCG?= =?us-ascii?Q?UzZ2P1V30x3xEf2Ui4DXOCqnhp3dK4vs3K0zCx4lVr202LrpkXAMPvCnZoNA?= =?us-ascii?Q?s7jdLNZjYtgwrIH0I6yOcFKnA/f4J0OpcmLx8hTuHOEvUKoB5qXUdtwXbOb2?= =?us-ascii?Q?v/3RW59P6iaxhA4nFN0DWv2voZWfwri4+abkLwvV0yiMkDj2p56NLlGK2Mao?= =?us-ascii?Q?uwX9Y9e1aqHccZhD/OECe6xl8jYz3SltP+2Z6ubKTvSKiteldjd2sJ2rPhk6?= =?us-ascii?Q?PLP/mhBAebR8OYsNm04P94YBda5fy0HXLkK8qf19Hx6Xs2AMh8EFT/9tV0SS?= =?us-ascii?Q?d/3fnasZIRJslduPB3WZQzPnALV3W4dNTaaJjS6c0Gox/iB7pcuTmSbz64kD?= =?us-ascii?Q?zd3kZQ9E7y3ICpZJJfoP+ob+BdWcL1v6LxdiWov1vVn/p/XOfd20WD+l1Ta/?= =?us-ascii?Q?zPzdZQNKpozsY2Nk2V+y8UZIGAC2DUD2x4kSw756IMVjGBQaq/IOJwznvKr7?= =?us-ascii?Q?mnqKbNWCbpY/4imjc+DNxm+D1S+sAge+qpT1baUSL6QK+2MWZfAAoaKPBc1A?= =?us-ascii?Q?HbUfh0G7kfqLsUSLAR3F28Pru+1+Dm5ebVuBl7fKQQg0dTb7hEpvuuN9gzHF?= =?us-ascii?Q?2kS+dT4M+IJT2DB3+BqukRunTcv75/1UFAmqJZSvRUxrZKYvDLWiSCtWEjg3?= =?us-ascii?Q?XABGW2vMPuPpH1+vKzdw7k5og3yHDgGTUQGG0yER07ddXV6TV5avm4SrgAZ+?= =?us-ascii?Q?J11Zda+UHozfToE2OiNxcw4mHqJ0tNnsjURCUY7k7pc0UJm3NuBYhyxWcnsa?= =?us-ascii?Q?6HKs876t2US1h2biD0XBNwQbG/VfV//Mdo7q3g6/j5pmh0IIUxoLW2FZC9RZ?= =?us-ascii?Q?bnpPdCbjdJPe3U7FF+Y+aurNx9N2CuT+cBkeIa9NiHE7amVQCIr1lcbyIWsx?= =?us-ascii?Q?sJS7j/S6O5CQWbkE2cmbc7sWdpa4ukmYX001qfALug3y5rK0G1wGITSL0pBq?= =?us-ascii?Q?WUUIiwMX1eJAdPGmDx/27hY9z+pL+jVYnC6Nh9hBuQsBMC0AJJLhas2iA7pX?= =?us-ascii?Q?w5gpVBf1OZMf/dN37dTH0FTFZfjMbbB9ho3YewG1R4qvYK1H83G/BeSngMw0?= =?us-ascii?Q?knNiJ1zNHLVvjyMmuUqE8nGeIO9LseKNMicOdXvAGC7ZGnlAQ5KYz1kqdOdu?= =?us-ascii?Q?AGzuByGtR/RhJtmpN9QfaeXc59nE6AaXvUcNfff0wsZzjJjupYMnoJ+X0Yl3?= =?us-ascii?Q?i+yAjqUFNxAGLYwEFLxT7f0yV+ZiQ2/niEk7oJ2e0nH3BmHfNeqN3hVjNEio?= =?us-ascii?Q?mqlYgB/1MQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 38d97da9-4649-4e66-235c-08df346e22eb X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:14.7736 (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: nN/DSVu9bfFy8hoKcjj8nEEViYRYJ0+EfeQhXSkuYUrCuM5b9Z+9zqtNGNI3IQAdgERSJaGWFC2wlxWQMGL0UA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR03MB10907 X-purgate-ID: tlsNG-4011c0/1793135177-59FDECFC-7B2CC868/0/0 X-purgate-type: clean X-purgate-size: 5064 From: Mirela Simonovic Timer interrupts must be disabled while the system is suspended to prevent spurious wake-ups. Suspending timers in Xen consists of disabling the physical timer and the hypervisor timer on the current CPU. The virtual timer does not need explicit handling here, as it is already disabled on vCPU context switch and its state is restored per-vCPU on the next context restore. Resuming consists of raising TIMER_SOFTIRQ, which prompts the generic timer code to reprogram the hypervisor timer with the correct timeout. Xen does not use or expose the physical timer, so it remains disabled across suspend/resume. Introduce a new helper, disable_phys_hyp_timers(), to encapsulate disabling of the physical and hypervisor timers. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykola Kvach Acked-by: Julien Grall Reviewed-by: Luca Fancellu --- Changes in V7: - Dropped EL1/EL2 wording; use "physical timer" and "hypervisor timer" - Renamed helper to disable_phys_hyp_timers() to reflect its actual scope - Clarified virtual timer handling (disabled on vCPU switch-out, restored on context restore) and added comments in suspend/resume paths - Added resume comment explaining which timers are restored by TIMER_SOFTIRQ --- xen/arch/arm/include/asm/time.h | 5 ++++ xen/arch/arm/time.c | 44 ++++++++++++++++++++++++++++----- 2 files changed, 43 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/time.h index fd79dd31eb..7ffa0b5ac9 100644 --- a/xen/arch/arm/include/asm/time.h +++ b/xen/arch/arm/include/asm/time.h @@ -106,6 +106,11 @@ void preinit_xen_time(void); void force_update_vcpu_system_time(struct vcpu *v); +#ifdef CONFIG_SYSTEM_SUSPEND +void time_suspend(void); +void time_resume(void); +#endif /* CONFIG_SYSTEM_SUSPEND */ + #endif /* __ARM_TIME_H__ */ /* * Local variables: diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index 295afa685a..edd41b6e31 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -311,6 +311,14 @@ static void check_timer_irq_cfg(unsigned int irq, const char *which) static DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, irq_hyp); static DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, irq_virt); +/* Disable physical and hypervisor timers on the current CPU */ +static inline void disable_phys_hyp_timers(void) +{ + WRITE_SYSREG(0, CNTP_CTL_EL0); /* Physical timer disabled */ + WRITE_SYSREG(0, CNTHP_CTL_EL2); /* Hypervisor's timer disabled */ + isb(); +} + /* Set up the timer interrupt on this CPU */ void init_timer_interrupt(void) { @@ -321,9 +329,7 @@ void init_timer_interrupt(void) WRITE_SYSREG64(0, CNTVOFF_EL2); /* No VM-specific offset */ /* Do not let the VMs program the physical timer, only read the physical counter */ WRITE_SYSREG(CNTHCTL_EL2_EL1PCTEN, CNTHCTL_EL2); - WRITE_SYSREG(0, CNTP_CTL_EL0); /* Physical timer disabled */ - WRITE_SYSREG(0, CNTHP_CTL_EL2); /* Hypervisor's timer disabled */ - isb(); + disable_phys_hyp_timers(); hyp_action->name = "hyptimer"; hyp_action->handler = htimer_interrupt; @@ -348,9 +354,7 @@ void init_timer_interrupt(void) */ static void deinit_timer_interrupt(void) { - WRITE_SYSREG(0, CNTP_CTL_EL0); /* Disable physical timer */ - WRITE_SYSREG(0, CNTHP_CTL_EL2); /* Disable hypervisor's timer */ - isb(); + disable_phys_hyp_timers(); release_irq(timer_irq[TIMER_HYP_PPI], NULL); release_irq(timer_irq[TIMER_VIRT_PPI], NULL); @@ -390,6 +394,34 @@ void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds) /* XXX update guest visible wallclock time */ } +#ifdef CONFIG_SYSTEM_SUSPEND + +void time_suspend(void) +{ + /* CNTV already disabled by virt_timer_save() during vcpu context switch. */ + disable_phys_hyp_timers(); +} + +void time_resume(void) +{ + /* + * Raising TIMER_SOFTIRQ triggers generic timer code to reprogram the + * hypervisor timer with the correct timeout (not known here). + * + * Xen doesn't use or expose the physical timer, so it remains disabled + * across suspend/resume. + * + * The virtual timer state is restored per-vCPU on the next context switch. + * + * No further action is needed to restore timekeeping after power down, + * since the system counter is unaffected. See ARM DDI 0487 L.a, D12.1.2 + * "The system counter must be implemented in an always-on power domain." + */ + raise_softirq(TIMER_SOFTIRQ); +} + +#endif /* CONFIG_SYSTEM_SUSPEND */ + static int cpu_time_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462573.1673551 (Exim 4.92) (envelope-from ) id 1xLoNB-0005AQ-Gy; Tue, 27 Oct 2026 21:06:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462573.1673551; Tue, 27 Oct 2026 21:06: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 1xLoNB-0005AI-DJ; Tue, 27 Oct 2026 21:06:21 +0000 Received: by outflank-mailman (input) for mailman id 1462573; Tue, 27 Oct 2026 21:06:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNA-0004nr-8J for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoN9-007tzZ-L9 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:19 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11240-2eae-0a2a0a5409dd-0a2a450c8962-12 for ; Tue, 27 Oct 2026 22:06:19 +0100 Received: from [40.107.162.98] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1124b-f479-0a2a450c0019-286ba262326c-3 for ; Tue, 27 Oct 2026 22:06:19 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by VI2PR03MB10907.eurprd03.prod.outlook.com (2603:10a6:800:270::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 21:06:17 +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.0546.021; Tue, 27 Oct 2026 21:06: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=sw2KQw7ba1lHVghHJDx2WtJad0I+FH/7Wp7Q9KroUfTatcsDDBfL3A7hiAHfztGhwOd05CHQSxmywVTSs1akTpSKqX4Pp973g75H3FxmTW7R5PErkkIP/Ypp0MFeyhQ9jqdrhqWXAEpwAYDUc8SrPsLfbcPYebbZtLL680U5lKd7C3imRtV8vYO8XvzbhbvhvG4oCvsA4MIBSMmM9iHobR3W0DY+vJh/ufWUXj1MtPtep5wSQQimP+6acQ04LZ3aJNpo4BLjcQZOHCJLws1ta/MWTJI6w3ROy9BotZJp81gwdwH1+vN4//dKRf4JtwGltrWKbZKUZEnxRmkX0ygMBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FsJSjRIECtXvMDO50Vke4Bgv0nquvP569kSMyvgY9uc=; b=RGOQPjm24PScUxRb+6SgeVJWqBkPMsYiRhNOCs1wxD2QEwtZCNY9loNzQpqtEndNANzbTVAgO4GQpuScIvncN4kv2htssP5Lj5Drut9yydXY2AjPTU6TfA2zki3MkmcYgj65LNcYAkTVu6UlVIrlh/MOFFVQUUxrzSnbp92IT0qBT06KzdnsfSxhFaa04/ECW0Z7GlP8Ym/2hfH+brbR0thr6Ak20wOpXPJvLT4+W+gp7Fkfaa8pNy/LVD+oA39ISwlJ2EXvkWsvEPi2mQBO80v4+Xgm1Ti+/ZLImh1noUt2uzULV1l80Fi1wMVmhmClCcuNCwgdUI6GAEfMC48n6A== 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=FsJSjRIECtXvMDO50Vke4Bgv0nquvP569kSMyvgY9uc=; b=LUU8DXxa3FVa82NkefVNCCS5N8/yxcawZuqQoh8LzRC6gEWS/EgNdDxBvouSPQMJ/iV+KH8FhpxUKumc86zTMFhKtGGJarDhw5Z5hzzZri0852gvD5EhSurMWDpw6DVjoKKysk2t+QQ7+tI3vrB3qhHB08EEcHFxVOBsPAXw+eylx/Ek3rTz0X+MPb8+QYtIAdD2ibnQzPFqzrTq7+15Te+KCuzD/GT+eUflFdbIxbMvDr3or68gh4x6qvHw8LsBQEMaz3JOV8gfqSBxIhxMWpeEP9gONXCF3OhEZDlW0CSSYTFf+9drKxjCNhgqcMJYp/6PaufvWDRJTXFz8dTERQ== 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: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai Subject: [PATCH v13 02/14] xen/arm: gic-v2: Implement GIC suspend/resume functions Date: Tue, 27 Oct 2026 23:05:51 +0200 Message-ID: <5c1fdca65fcd1862fe7b7ae314c33832ced6c01b.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|VI2PR03MB10907:EE_ X-MS-Office365-Filtering-Correlation-Id: c9f9b912-da1a-4e87-622e-08df346e24bc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|261009223027099003|261022105027099003|261021121427099003|261021123027099003|261021135927099003|261022075727099003|10067099003|56012099006|261026121527099003|6133799003|22082099003|20046099003|18002099003|11063799006|261026140227099003; X-Microsoft-Antispam-Message-Info: E+WOl6iEnF0/VMNGox8I2lRKyaafLrBvmWMmCV5EEq12REgbrjoyzFrLOt50g56b/5BeIr/u+k1YAaEXTKvOYiucsOke8FpDdEs2pLs3t8WxxSMJKesITCeO8m0wTtZeggJzxzTHaX3pA4yMP1AZKoV4u3qY7hUlDM/FMrfAfZPIMfkGftBXZChBNfamJqIm3WcNcBBIiwZpZiH8j6qubgE5KEFkxAtUe7/wH7wnOIrPy4F3Fq8p8mwXsCkCdclbboH5YO6vgOJ+Eu7cIqU9xIxRVeHzhW5sD5Gpxqk28mCX8cznZOgbKNManQ9Qa+hKiPyyyy1leA7J3LEIaJAZTI8YDZ+7E+dfNqkcJoAWQB3JiXuBNc4sBT3Xx/LcmgLOkIvzh5Q7BdDZ5bv96P6GoRCSwXDt5QPco0u1uhN7INsZSFsSpi1O4/Yc//QK2aaJ2LClvBjU99sZhHhsxJjbyD6VC/++wiv1R/KexKg9SQXo9vuYkPDegnNiih4wrSigbzD22489QkJplytgw8pFW0yiOhB2VGa3UXlkr7ic86ZcxAI2HETR2clguZredO9fLTg0BhGf3veuXVyUXmWleQWkAg0JTUxXc3AZwfNVwmd56kirNky3FMVguTKMSQfFExvHMLscBiqpsHnE5eVWZQFPATl2Uh/w6pX/S1JHSDA= 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)(376014)(366016)(23010399003)(1800799024)(261009223027099003)(261022105027099003)(261021121427099003)(261021123027099003)(261021135927099003)(261022075727099003)(10067099003)(56012099006)(261026121527099003)(6133799003)(22082099003)(20046099003)(18002099003)(11063799006)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xD79HIGYHjZpvpJXCABeyQQJ3p+QqYcqb5WpECwPhv2N7f1zPDWgZY7oEahy?= =?us-ascii?Q?ZojncOTUWoHxUAv2rwZPmeCxkMjmlhIfN/gjyb90o6hAb0nYnWUbQ+wNBdRZ?= =?us-ascii?Q?aGudozXX6A0e25rYnEK0mVZAL5VgS55x1HinVzrbeP9Qy509conefZnbPWp7?= =?us-ascii?Q?fGNnzVOdb3kWJk+7tltPS1HXozeGaIFZs8dAJARwWq7I0QNuerp6gkmgpArO?= =?us-ascii?Q?v76QcLEzjN4s/RwFdy46pCQW2ORvZ+9P0C3Vt1+lclXaa1KPrDae5yiMI+qP?= =?us-ascii?Q?Ds1cdtx4e08r1Rl9b86XBa2lTxcz6w+KJvt5cYd5pMwcOTeCRWo1UjVSGgEk?= =?us-ascii?Q?G+Lzyz8OZh1B5rqj56bYiVSW8x5XhYbEYwLI6RUrQvJXv0cT+e5C+f2FmUXt?= =?us-ascii?Q?hrnDOLPvtBw59gX4YN9IoWJp5kAzKRKIBdZeac0oRnJzV1SBFHPFK9y33d4q?= =?us-ascii?Q?+SwcHpGQvOUc8ICKcT5mga0Ica8RBmGTh0NEOyn078NSWA86uHsM/6MhVsWC?= =?us-ascii?Q?Qbn+n9WoEwtNCVM5pnGO7wbyWmncl5YxP3CadVNCag5pz7xk5wndgzm9uuOH?= =?us-ascii?Q?Sy4eP3scNxiycy7CvHwt9woYEHBxu1nLXMX9OkRK9RQ6wP8xGOZWdDhnU/2l?= =?us-ascii?Q?Z4UAj3PDD9o+bBytBeCMQZM5miJMVYB2sVBSDEpzHEy3L+9m/fFYz0UtsbUl?= =?us-ascii?Q?Ow8A6Z4OVh/28+omnYTIGyYkKXj5oPLygE1GOULIb62pGTNWTWHPslrOAV5c?= =?us-ascii?Q?+w3jOOJnACF4xs1vS0ZDd7AN+FSI2esqDNIxw/sY8Q4tlH9V3sg27SH1WoQX?= =?us-ascii?Q?needmvtaCKvhiZpuvuc0KLWCsftIEdIDMLE/Sv8hLrhZ0VvvLvuUghjmdzGA?= =?us-ascii?Q?R3WJ5Yj/+xESbHo1Sz07mUW35fvycS/DDGwlbc6MT6q6BbhyhrsUsFviZwr0?= =?us-ascii?Q?Sh8pbCGnswieMFuDKbcCscHhB88+U+i2OdVhUuRl70uPjqSCYM5VxTjEQ0a7?= =?us-ascii?Q?zu3dVhMgyCQV4HWQ5SFoKqc04ZQPPqwD+OGNwaOj5510X4IvWpC8Lrv2tS5C?= =?us-ascii?Q?pg7ID6zldR88y/0BYyjEHs/mGQznWjxoEjamBdaR46u+tVsEA8Cg2lC0U6ia?= =?us-ascii?Q?URlEsRJ3mMyk1r+NQO85mm1R4llJhbaPqgRIdMQkuTLTHecDFWBrP0vJU6yZ?= =?us-ascii?Q?TrncRXAloflXHyjTzhY5lRYU64paZIDVCuxjyhnJngW7Id3NqwA5fx7ieETw?= =?us-ascii?Q?TXDsv0IA1OuLS7q/nQjIoeEljmeMxEKDoIHm2YQwGtyOkatlOtCksBBBphUg?= =?us-ascii?Q?6f+jF2YKW1dA+HZnAkzs4KjIUxaVH8/u/oYn6MHzQVonsaTG2pyM8ihwWW5l?= =?us-ascii?Q?XBykwM66H405vMfFJHe/tOGj8mqCDxhUXg9lZM8KgiG5oe5JJdrrz98OD4Xy?= =?us-ascii?Q?u+o9TGJuvL7yRNssFvuE7bXqi2Q/HrH4kegidbB28gQh4DUKkG0lJf4O9GWV?= =?us-ascii?Q?AICFh0DSItvWJxnyGk3JcJ0ia0lhvqAcbFXnBVcvzY+JLzYy4AA4cGMxBYkd?= =?us-ascii?Q?SjwV/h0sCBLkkl1s4kiJq5EBK3asxovboggReav3yNju/jVIxGCHjRyweRM5?= =?us-ascii?Q?wxbM8RfEs58+xwdOkyb+4SYAH0eps6XTrEsERJMT9y/aMyXXsESiS70p10TW?= =?us-ascii?Q?r48lyvMlocAfBEbeFfBhkT8EHzBP7NANnhRJ+OQs0zqfQn2DxTZZMc0DQnuA?= =?us-ascii?Q?iqfZNtcLCQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9f9b912-da1a-4e87-622e-08df346e24bc X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:17.8429 (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: msJJPuzd0itY7tyNmshefIWi+focWPkV/euDrz4ew/Stw5e5v+FTc7lf5Mpcc5SRQf07LZfkgGOo9jf2nNn/Yg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR03MB10907 X-purgate-ID: tlsNG-d25034/1793135179-010C9A5B-D00A1D47/0/0 X-purgate-type: clean X-purgate-size: 15652 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. Do not save or restore physical pending interrupt state, including SGIs and PPI/SPI pending bits in GICD_ISPENDR. Before this point, device drivers must stop normal I/O and quiesce non-wakeup interrupt sources. Earlier events must have been handled or remain recorded outside the GIC. The platform must preserve wakeup events throughout suspend entry and sleep if the GIC loses state. Level sources still asserted after resume become pending again. Edge events need state retained outside the GIC; saving GICD_ISPENDR would not cover events arriving after the read. Keep the Distributor and CPU interface control state unchanged during suspend entry. GICv2 wakeup signals depend on Distributor group enables, and firmware may check pending interrupts through the CPU interface before accepting SYSTEM_SUSPEND. Leave shutdown and wakeup setup to firmware. Disable the interfaces while restoring their state on resume. CPU-interface active-priority state is not restored. Xen enters this path with local IRQs disabled and must have no active-priority context to replay after resume. If any visible GICC_APRn bit is still set, abort suspend with -EBUSY without changing the GIC control registers. This does not apply to distributor active state. With GICv2 EOImode==1, EOIR only drops the interrupt priority; final deactivation is a separate step. For guest-routed interrupts, Xen can have already EOIed the physical IRQ while deactivation is still pending on the vGIC/GICV path. Therefore GICD_ISACTIVER is preserved as architectural in-flight interrupt state. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in V13: - Use size_t for GICD word-access offsets to match the suspend code (MISRA Rule 10.3). No functional change. - Cast the APR mask to uint32_t; it contains at most 32 bits (MISRA Rule 10.3). No functional change. - Leave the CPU interface and Distributor control state unchanged during suspend entry, including when the active-priority check fails. - Explain why pending interrupt state is not saved and document the device and platform requirements for preserving events. 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. 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. Changes in V8: - disable cpu interface + distributor before suspend - change 0xffffffff to GENMASK; - cosmetic changes; 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 | 232 ++++++++++++++++++++++++++++++++- xen/arch/arm/gic.c | 29 +++++ xen/arch/arm/include/asm/gic.h | 12 ++ 3 files changed, 271 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index 87eda9d322..67caf1c70a 100644 --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -118,12 +118,12 @@ static inline void writeb_gicd(uint8_t val, unsigned int offset) writeb_relaxed(val, gicv2.map_dbase + offset); } -static inline void writel_gicd(uint32_t val, unsigned int offset) +static inline void writel_gicd(uint32_t val, size_t offset) { writel_relaxed(val, gicv2.map_dbase + offset); } -static inline uint32_t readl_gicd(unsigned int offset) +static inline uint32_t readl_gicd(size_t offset) { return readl_relaxed(gicv2.map_dbase + offset); } @@ -1108,6 +1108,225 @@ static int gicv2_iomem_deny_access(struct domain *d) return iomem_deny_access(d, mfn, mfn + nr - 1); } +#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 as the + * minimum supported BPR value. Table 4-47 maps that Xen-visible BPR value + * to the visible GICC_APR bits. Avoid reading APR registers outside + * that visible range. + * + * This covers both GICv2 with and without Security Extensions. + */ + apr_bits = 1U << (7 - (bpr & 0x7)); + nr_aprs = DIV_ROUND_UP(apr_bits, GICV2_APR_BITS_PER_REG); + + ASSERT(nr_aprs <= GICV2_NR_APRS); + + for ( i = 0; i < nr_aprs; i++ ) + { + unsigned int bits = min(GICV2_APR_BITS_PER_REG, + apr_bits - i * GICV2_APR_BITS_PER_REG); + uint32_t mask = (uint32_t)GENMASK(bits - 1, 0); + uint32_t apr = readl_gicc(GICC_APR + i * 4) & mask; + + if ( !apr ) + continue; + + printk(XENLOG_ERR "GICv2: suspend aborted: GICC_APR%u=%#08x\n", + i, apr); + return -EBUSY; + } + + return 0; +} + +static int gicv2_suspend(void) +{ + unsigned int i, blocks = DIV_ROUND_UP(gicv2_info.nr_lines, 32); + int ret; + + /* + * Keep the CPU interface and Distributor control state unchanged. + * Firmware may use them to detect pending interrupts and wakeup events + * before entering system suspend. Local IRQs are already disabled. + */ + gic_ctx.cpu.ctlr = readl_gicc(GICC_CTLR); + gic_ctx.cpu.bpr = 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 SecurityExtn and + * Group 1 in Xen's Non-secure view with SecurityExtn, and in both cases + * the relevant state is visible through GICC_APRn. The APR layout is + * implementation-defined, so only test the bits visible from Xen's CPU + * interface view instead of reading every possible APR register. + */ + ret = gicv2_check_active_priorities(gic_ctx.cpu.bpr); + if ( ret ) + return ret; + + gic_ctx.cpu.pmr = readl_gicc(GICC_PMR); + + /* + * Do not save PPI/SPI pending state. Drivers must quiesce non-wakeup + * sources and handle or retain earlier events before this point. The + * platform must retain wakeup events outside the GIC if its state can + * be lost, including edge events during suspend entry. Level sources + * still asserted after resume become pending again. + */ + gic_ctx.dist.ctlr = readl_gicd(GICD_CTLR); + + for ( i = 0; i < blocks; i++ ) + { + struct irq_block *irqs = gic_ctx.dist.irqs + i; + size_t j, off = i * sizeof(irqs->isenabler); + size_t nr_regs = ARRAY_SIZE(irqs->ipriorityr); + + if ( i == blocks - 1 ) + nr_regs = DIV_ROUND_UP(gicv2_info.nr_lines - i * 32, 4); + + irqs->isenabler = readl_gicd(GICD_ISENABLER + off); + + /* + * Save distributor active state as part of the hypervisor-owned + * physical interrupt state. In GICv2 EOImode==1, EOIR only drops the + * priority; final deactivation is separate. For guest-routed + * interrupts, Xen may have EOIed the physical IRQ while the guest/vGIC + * side still owns the deactivate step. Therefore GICD_ISACTIVER can + * legitimately remain set even though transient SGI pending state and + * CPU-interface active-priority state are expected to be quiesced here. + */ + irqs->isactiver = readl_gicd(GICD_ISACTIVER + off); + + off = i * sizeof(irqs->ipriorityr); + for ( j = 0; j < nr_regs; j++ ) + irqs->ipriorityr[j] = 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 = i * sizeof(irqs->itargetsr); + for ( j = 0; j < nr_regs; j++ ) + irqs->itargetsr[j] = readl_gicd(GICD_ITARGETSR + off + j * 4); + } + + off = i * sizeof(irqs->icfgr); + for ( j = 0; j < ARRAY_SIZE(irqs->icfgr); j++ ) + irqs->icfgr[j] = readl_gicd(GICD_ICFGR + off + j * 4); + } + + return 0; +} + +static void gicv2_resume(void) +{ + unsigned int i, blocks = DIV_ROUND_UP(gicv2_info.nr_lines, 32); + + gicv2_cpu_disable(); + /* Disable distributor */ + writel_gicd(0, GICD_CTLR); + + for ( i = 0; i < blocks; i++ ) + { + struct irq_block *irqs = gic_ctx.dist.irqs + i; + size_t j, off = i * sizeof(irqs->isenabler); + size_t nr_regs = ARRAY_SIZE(irqs->ipriorityr); + + if ( i == blocks - 1 ) + nr_regs = DIV_ROUND_UP(gicv2_info.nr_lines - i * 32, 4); + + writel_gicd(GENMASK(31, 0), GICD_ICENABLER + off); + + off = i * sizeof(irqs->icfgr); + for ( j = 0; j < ARRAY_SIZE(irqs->icfgr); j++ ) + writel_gicd(irqs->icfgr[j], GICD_ICFGR + off + j * 4); + + off = i * sizeof(irqs->ipriorityr); + for ( j = 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 = i * sizeof(irqs->itargetsr); + for ( j = 0; j < nr_regs; j++ ) + writel_gicd(irqs->itargetsr[j], GICD_ITARGETSR + off + j * 4); + } + + off = 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 = DIV_ROUND_UP(gicv2_info.nr_lines, 32); + + gic_ctx.dist.irqs = 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) { @@ -1315,6 +1534,11 @@ static int __init gicv2_init(void) spin_unlock(&gicv2.lock); +#ifdef CONFIG_SYSTEM_SUSPEND + /* Allocate memory to be used for saving GIC context during the suspend */ + gicv2_alloc_context(); +#endif /* CONFIG_SYSTEM_SUSPEND */ + return 0; } @@ -1358,6 +1582,10 @@ static const struct gic_hw_operations gicv2_ops = { .map_hwdom_extra_mappings = gicv2_map_hwdom_extra_mappings, .iomem_deny_access = gicv2_iomem_deny_access, .do_LPI = gicv2_do_LPI, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = gicv2_suspend, + .resume = gicv2_resume, +#endif /* CONFIG_SYSTEM_SUSPEND */ }; /* Set up the GIC */ diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index c4bda435bd..30087b5938 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -464,6 +464,35 @@ int gic_iomem_deny_access(struct domain *d) return gic_hw_ops->iomem_deny_access(d); } +#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_suspend + * 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/gic.h index 9af05da6aa..d01249069f 100644 --- a/xen/arch/arm/include/asm/gic.h +++ b/xen/arch/arm/include/asm/gic.h @@ -307,6 +307,12 @@ extern int gicv_setup(struct domain *d); extern void gic_save_state(struct vcpu *v); extern void gic_restore_state(struct vcpu *v); +#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, @@ -458,6 +464,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 */ }; extern const struct gic_hw_operations *gic_hw_ops; -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462574.1673560 (Exim 4.92) (envelope-from ) id 1xLoNE-0005PH-TN; Tue, 27 Oct 2026 21:06:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462574.1673560; Tue, 27 Oct 2026 21:06: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 1xLoNE-0005P6-PU; Tue, 27 Oct 2026 21:06:24 +0000 Received: by outflank-mailman (input) for mailman id 1462574; Tue, 27 Oct 2026 21:06:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNC-0005NW-Rp for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNC-0005yu-8a for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:22 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11225-e002-0a2a0a5209dd-0a2a4505a020-18 for ; Tue, 27 Oct 2026 22:06:22 +0100 Received: from [52.101.83.138] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1124d-4cb1-0a2a45050019-3465538a2d37-3 for ; Tue, 27 Oct 2026 22:06:22 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by VI1PR03MB9914.eurprd03.prod.outlook.com (2603:10a6:800:1c1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 21:06:19 +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.0546.021; Tue, 27 Oct 2026 21:06: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=PjjNYB+yuN3+JQ5snlvFW4zBkNSLm3IpJ1WJaDk6EEiZEFloguR2PdXGEOaOWwUarHDceJk+aV2K74QWv0wSwath9vA9iKTDGXMulxgdAB3wnR+eKqueyhW17j7SaN/MpZcmsZ0qFeUqX/W1Wcn2mJKjKZ8ZHTjPjBn09T8GSXg14KhzlvnVsZHSfWh40ugO6J8uaPtvidDvKYzLNzbNlcim9s0fZzYGBO521YQqYYmC4AhKgtx7leQTeGphJgqMqIlChbHLVeR7XNApeJ4+H/O7CvY7DZcUkpzwpPrcdW/tXYUWIgEmPJlgUjUXx6AtTRIKsEEq/U9a5FmXgn01GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GLtMWURpXJd1G4agtjp/HEofRi9wCVlpWZUFho8rMKQ=; b=b+vFG6dqfKTavpJRiqBPkkl1S8varfwSYrWaeV51G0ccxohMz9F9M4Nsuit3j7YMjw1JePziu4lojkEbdzr/MAzvZXtDIJ3+rV9/aFIRlK/ez+nfXq0nEPSTeiFdwYOIVCo4v+a18a+IHLnrNLGvs0lSZh0DfvSG5b9XYuQwpXVbuuNjjFWW/e05XAMp88hJMCQWaKb5W0Bk6fMRFCCDMLAKBe4ENvnBEWVQ04zQ6fbcvShaM0vLyEqIFp244WBWruFC1RZzGhT3ty+dRE3XncuBkjCHT6LWa9nfKclkHISGsJU92xP77wwz0BAr7PD1kv7XEVajY4wSYuh9LUKlEQ== 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=GLtMWURpXJd1G4agtjp/HEofRi9wCVlpWZUFho8rMKQ=; b=mJBxlsKGuPLHIjl/DDVW9vG+yDIUUxN8tOtz+VtEkBqJ0e7FP0VFSfmBEaC6IJ7tIpOxx/sMKntwMEDWt8QgxAWS+t1HXFOCYfj2wpRnDunN005qi9dvGiowW/l6HjzKnP8BR4cSl1aX57RGtVx8qhNxvKJhvg5ZtL6rVKh5QbbZ0aRk+niyV1T17aaJFw4xD1Yn+7mdSO33ccNz1qn560t+ZZnGiOzTwVPs1SNvthmBl5pNRJQIPDn2GGFRdZY61aaQsq18iTY/rqA9e/IolYBqhXDatwKSOPCGw53p9/1tu9Kgc6/ra3KaayNEhRfUqJd1GWBUap68qgqC5ytCZQ== 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 , Luca Fancellu Subject: [PATCH v13 03/14] xen/arm: gic-v3: tolerate retained redistributor LPI state across CPU_OFF Date: Tue, 27 Oct 2026 23:05:52 +0200 Message-ID: <5fbe90be9e32464bf0f03f50614e65fd899d608c.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|VI1PR03MB9914:EE_ X-MS-Office365-Filtering-Correlation-Id: 0775597e-174e-436a-b233-08df346e257c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|261021123027099003|261009223027099003|261022075727099003|261021121427099003|261022105027099003|10067099003|56012099006|261026121527099003|6133799003|22082099003|18002099003|11063799006|261026140227099003; X-Microsoft-Antispam-Message-Info: 1NbvMK9bFpbS5PD+B0Q38DNVtARU7tjzHEsUzDOzA35p+N56lkcyQwMucZBUMrXi5UFxxHx+npbwMf2P/ahlwHAZs1fVtUbln+KZxIOvr/lmt0/+H8zI85oYW3roNlQSFpkFcfAVlVAdkGIv9+TC7Vreyskx1rD7+5HnhTjXj9g/Yrk1sqrHalZFFGwDdnHFE+U//MD09UjJcbDlt/Lp2Gl1jwdBRd2f+jsVrYm7FhVIDkfSwhOgo76aD/tfsFkr0yg2FvzwtX76s4ZhP0sIfOZVNgPmcXbkmeg36LC9yqBh5Pf69axwwXn/POIaL2JtIKv1gnT93EZJj7lMY+r2+JltrjI1AD8eDZ86zozLLqOdUcvcE3HOLDEwIgOaHmijYzXsNHc3P7o6TKdfEkuMmoGDmB1t5TgUbcV/I1RfJK2UyAyxmHrXud1Qw/MbxmQXhcAlwiGmZAjahINmYw/Kb1Ew0JUwEt8W4Va5/lGpDmReLwB4nuObKTu1kPwGnz67RUjcccboYuOh8vbfF3uAzFh+I9Vq+Cjb7qoxTn/QngYQur04PRZNanogi7hDzrTjnMVvX7rJ+E6g3zRNDWCZgolaiTul5XUgryEsO2DSvP4ZmKsQ33SZX6735dFihsMpjePyBSHzwrBnrASVdijakcVcmjdwteZYlSe3xLNqLRk= 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)(261021123027099003)(261009223027099003)(261022075727099003)(261021121427099003)(261022105027099003)(10067099003)(56012099006)(261026121527099003)(6133799003)(22082099003)(18002099003)(11063799006)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?WtLNB3mhBFA7PCuS5C7fdvOX+DXrei6fJNXDrOWTDi+EIbFiBN8xrrhE/ya8?= =?us-ascii?Q?P+qc2YYxeODPwkK5jIeXU5PLMb3iAsygeyf44B8RSXu29ChyTPEuqEfQCK8N?= =?us-ascii?Q?1fCIxmrANJ3nOovZSIRKNke6DYwMeitgqj+A32dafkU/wqf4oI9yo6bdksHa?= =?us-ascii?Q?bN9is73639CYe2iTjO9Hb85oUk3L9zO7XWYOVrJRtpIUt4wUKYlJSQpa54C8?= =?us-ascii?Q?wPHc09oVDOL0+GVetw+AWq3oQMDEhc9K27XBL9R2UhA7DZJ6/XWcnQ1mft57?= =?us-ascii?Q?fd7mzIOTRf1uWhbHvqds3QK2OcGC80aYtyxMpZEcdB23wMC6vKQVsK1YVDxB?= =?us-ascii?Q?qcB4TYkLh7zVz8Q5VLNxnXPW1tzhI0Mt12AseqQynbv0iq3SFMoHmpV/wxn6?= =?us-ascii?Q?c2lNqlBlJAjg5eGaBa1yEnnbgf70OjXQ6BgG7+eZc2gVhjMVAh7hmgSk6idw?= =?us-ascii?Q?S/YO8du1pNXtIWc4mPUfTOo1qC0Lq+vTLJFIspv+001hQ0D+UhTs7goxVm2k?= =?us-ascii?Q?1m4qv2LEwINMtxaEs3WbGucVWS+nh4fQXCe7RSirlQONDIHNhEYUrYys7HVr?= =?us-ascii?Q?gR5V5utgRhHrtPqBYWLxGi+tpNAJ4ChgYczGWmkRyRx4yOChwo32N4+ThZzb?= =?us-ascii?Q?5aqfw9cLHlxoGE1dQROgsnG8156lugDstVg94HsvDTIhQze1mQgHai3z16De?= =?us-ascii?Q?fhdUSGilmDT+p/NuVuacZ7vSIpd6E4PD/FnGal2inc4J/ox45XQSJC8kDd1J?= =?us-ascii?Q?fgj/V8x4EpULqZwsGaCe1tJNRnaWUBIn2L9eO7X0Z6B4NYStLPRb4rUFIey9?= =?us-ascii?Q?D2o9nPz/70d+wv7umllVZ2Qsg1jfFnKTSLarEwgiLLdND8I2Tr3iJ1Ia1N0A?= =?us-ascii?Q?6WQw6vGwMFEkwMnFozLLSq7l20xl+fUtTmcwTL1rBPydq92THEJLWXZNZKPX?= =?us-ascii?Q?yeUToMSeF3RE/qqOyFSiMCmYSPWGNo30n4M0Dtgo1/Zc80Xw1jWmPrml9zBd?= =?us-ascii?Q?X1mf5uRt877+JbhiER2JyXF2PV+UD1TF/4qETAnLA/IvoCHjdPjStyzhixYQ?= =?us-ascii?Q?zis6lDFtLqyEIqKHdvlq1PXuio8JgUpFwAzb/XHXAJkqtqS3W1b+ZW53VPVR?= =?us-ascii?Q?tfnHFJJZHrRj4jAYR+hkX+nCZG4jqy4TKS0to3T+jn7M1V/I9K3z2QmgBf5s?= =?us-ascii?Q?9Fme9Syz9t8owsALDwjhfpcIQikYb7lE1DF5CQqRfTp5B6n4pSPC2z+664rF?= =?us-ascii?Q?kjMzwaTX6JKxitGolLKv+AW+jp+OkvZ6kCVpWDAMK/eiF5spCyG6+0h+HQxv?= =?us-ascii?Q?/zszZSGClrJjf9Beg45t5tb5Ha4UqPQm8GPskJpzkPM0QQKr3XVAU4R3t1dq?= =?us-ascii?Q?1UMVVq7KS9rJmjePUPUkrnK8emx3dNBYPt0oPifMhcpEjaoAjgO9PDaOw7uK?= =?us-ascii?Q?MqdJAHQrocGmu0UUtkJAfgrwhFrG4Vi42Onby3i8vVrckA2hEXqgulZgmYTk?= =?us-ascii?Q?Yx/B11czB7fFnxsGHJ0WxjCD3WZoH9ORnha4UZnhpIioGgFmWW8HSrAuS4jj?= =?us-ascii?Q?irx0IlHBb2tVavPlMplekI0cmGLEK5pwYyfAhgupepO+x/+CIpji48IpTlrF?= =?us-ascii?Q?C4AA859y5nKZZ0lrygvbNscUndh8LzEU0Oi9q9NLDrRPd8AB+KRfHpL9aArl?= =?us-ascii?Q?rCA8CK9MYNVWHljUWLJ46Xu3X0s+csl6lOL9b899khYjOeNG89eoQCsoJ3WN?= =?us-ascii?Q?Lt+PlPCsfg=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0775597e-174e-436a-b233-08df346e257c X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:19.0735 (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: OoYD72LaEYdbVlPfCaoexYFbEa7uCf69oVHjcUbzsQmpCKfSww4aCcMdPrBizE5flI48jz7TcyuQOkOwatQB3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB9914 X-purgate-ID: tlsNG-c201ff/1793135182-72EB12A1-EB541994/0/0 X-purgate-type: clean X-purgate-size: 10189 PSCI does not guarantee that a GICv3 redistributor is powered down across 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 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 reinitializing 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 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. Handle that case in the LPI setup path instead of assuming a fully reset redistributor. 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 == 1 is UNPREDICTABLE. After clearing EnableLPIs, software must wait for GICR_CTLR.RWP == 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. 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 GIC 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 needs 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=1 -C gic_distributor.GICR-clear-enable-supported=1 and on Orange Pi 5. Signed-off-by: Mykola Kvach Reviewed-by: Luca Fancellu --- Changes in v13: - Document the pending-table lifetime requirement for CPU hotplug. Changes in v10: - Drop unrelated gicv3_populate_rdist() printk() format cleanups to keep 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 func - cosmetic changes --- xen/arch/arm/gic-v3-lpi.c | 84 +++++++++++++++++++++++++++++++++- xen/arch/arm/gic-v3.c | 15 ++++-- xen/arch/arm/include/asm/gic.h | 4 ++ 3 files changed, 97 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c index 1cf49430ea..1a893d3ab2 100644 --- a/xen/arch/arm/gic-v3-lpi.c +++ b/xen/arch/arm/gic-v3-lpi.c @@ -76,6 +76,13 @@ static struct { struct lpi_redist_data { paddr_t redist_addr; unsigned int redist_id; + /* + * System suspend keeps the per-CPU area and this table. + * TODO: CPU hotplug must handle the table's lifetime when freeing the + * per-CPU area. A redistributor may still use it with EnableLPIs set, + * so the table must remain allocated and its pointer must be retained + * until the redistributor no longer uses it. + */ void *pending_table; }; @@ -99,6 +106,13 @@ 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)) +#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 value. + */ +#define GICR_PENDBASER_XEN_MASK GENMASK_ULL(51, 16) + void __init gicv3_lpi_update_host_flags(uint32_t flags) { host_lpi_flags |= flags; @@ -337,6 +351,60 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_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 = readq_relaxed(rdist_base + GICR_PROPBASER); + pendbase = readq_relaxed(rdist_base + GICR_PENDBASER); + + return ((propbase & GICR_PROPBASER_XEN_MASK) == + (gicv3_lpi_expected_proptable() & GICR_PROPBASER_XEN_MASK)) && + ((pendbase & GICR_PENDBASER_XEN_MASK) == + (gicv3_lpi_expected_pendtable() & GICR_PENDBASER_XEN_MASK)); +} + +static int gicv3_lpi_disable_lpis(void __iomem *rdist_base) +{ + uint32_t reg = 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 the bit + * cleared. Where clearing is supported, RWP must reach 0 before touching + * PROPBASER/PENDBASER again. + */ + wmb(); + + ret = gicv3_do_wait_for_rwp(rdist_base, GICR_CTLR_RWP); + if ( ret ) + return ret; + + reg = 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. @@ -419,7 +487,21 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base) /* Make sure LPIs are disabled before setting up the tables. */ reg = readl_relaxed(rdist_base + GICR_CTLR); if ( reg & GICR_CTLR_ENABLE_LPIS ) - return -EBUSY; + { + if ( gicv3_lpi_tables_match(rdist_base) ) + return -EBUSY; + + ret = gicv3_lpi_disable_lpis(rdist_base); + if ( ret == -EBUSY ) + { + printk(XENLOG_ERR + "GICv3: CPU%u: LPIs still enabled with unexpected redistributor tables\n", + smp_processor_id()); + return -EINVAL; + } + if ( ret ) + return ret; + } ret = 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 cca49d2a2a..7e4b485f11 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -293,7 +293,7 @@ static void gicv3_enable_sre(void) } /* 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 = false; @@ -317,17 +317,22 @@ static void gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit) } while ( 1 ); if ( timeout ) + { dprintk(XENLOG_ERR, "RWP timeout\n"); + return -ETIMEDOUT; + } + + return 0; } 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); } 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); } static void gicv3_wait_for_rwp(int irq) @@ -883,7 +888,7 @@ static bool gicv3_enable_lpis(void) return true; } -static int __init gicv3_populate_rdist(void) +static int gicv3_populate_rdist(void) { int i; uint32_t aff; @@ -951,7 +956,7 @@ static int __init gicv3_populate_rdist(void) gicv3_set_redist_address(rdist_addr, procnum); ret = gicv3_lpi_init_rdist(ptr); - if ( ret && ret != -ENODEV ) + if ( ret && ret != -ENODEV && ret != -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/gic.h index d01249069f..c1727ad12e 100644 --- a/xen/arch/arm/include/asm/gic.h +++ b/xen/arch/arm/include/asm/gic.h @@ -307,6 +307,10 @@ extern int gicv_setup(struct domain *d); extern void gic_save_state(struct vcpu *v); extern void gic_restore_state(struct vcpu *v); +#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); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462572.1673539 (Exim 4.92) (envelope-from ) id 1xLoNA-0004o2-6T; Tue, 27 Oct 2026 21:06:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462572.1673539; Tue, 27 Oct 2026 21:06: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 1xLoNA-0004nl-0v; Tue, 27 Oct 2026 21:06:20 +0000 Received: by outflank-mailman (input) for mailman id 1462572; Tue, 27 Oct 2026 21:06:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoN7-0004lD-OW for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoN6-000vfm-MQ for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:16 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11248-8faa-0a2a0a5109dd-0a2a450ab3f8-0 for ; Tue, 27 Oct 2026 22:06:16 +0100 Received: from [52.101.84.103] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11248-f2d2-0a2a450a0019-346554675b98-3 for ; Tue, 27 Oct 2026 22:06:16 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by VI2PR03MB10907.eurprd03.prod.outlook.com (2603:10a6:800:270::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 21:06:13 +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.0546.021; Tue, 27 Oct 2026 21:06: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=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=vtxyPTgZuYl9ql6U1V8Q1cEWYyKMCysnq0Yj9BG7UMqa/yWLrTEnFlIEScww31LWeH9pkJB1X0x/3Ddj0HRwxiPraF0fexanUnTawSBsbt6gHzEtcB8GKV9edAgtZus3ljmitHWt9iD0z7XnB/UDMNEQwUeh8nQ2EY1cnuXBQRIXqZdtwROZJZHFdgVBLD5hxRiyBiD2v+00a6opnOUYzxA6qrBo6DveIgPh1vFbafAQCyYPtEW8dqYC9KUFye+HhqTi1P3yzT/sudwxuY5yqqNIdiOjVLuvZmfnFf474cF9rIgw/IqlZqWb/rQf6aRxJlYaIRNgoHN6IYeb/7DmlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Wa0JMW9G/IqvEMmQqcXGvzM+tli7vKqaDENpOLO8vpQ=; b=dfzQ45HFYEDpha7Un1J8FT7h33oPi7r8OK2S6/1ySd5WKoI6ckKBSv3ShWwe5nFInrXmFz1XrtNem1fNXeaAxAeClL+KW57xhbanqyUBN1fDYWbf8mO4/Lx4ik2d2yumT4J0XlvHfwqMbafotl+FKrOSk8mAehthWrIwjYt/WI42fd+Vt31RtuxIKQUC5IZXEG5qE4poVk3F26RWjnxm0rikFQLsV35Y8HdNcQ0ZoMtPvFAOtD4HaEkr/OKBH9HUZ+3nbxG1jzmtF4TUs83yj4xISTVhkZZSj3S4htdrixOleGfQ7OP2SHlxPWozx+aqylr1O5yWpVLLaZSdOubmhw== 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=Wa0JMW9G/IqvEMmQqcXGvzM+tli7vKqaDENpOLO8vpQ=; b=GYMz/OuIDQYoGMYJFurkZH47yCScHmW7JafHgyTBvc95poy03CLBR2JnC0RpnWGyRvTgnBqn3rwJJ0UKj2cqzZ4DHcsVpbixKmUBlX6AYRQ/v1crR6BuQZVbuLIVSC7Sie1LojwdL9UCfl3Gfk+U+hp9TNOxJPCtCSvdh3NEW5HcKU+sf11B31CelQG62V74z8u0fsPggO5WupmJhej19lsVBVVCLET62n3/bP8PQ2daZvVr5oRhDvbaopRBc+yW7zhu1yFIX7NlkT1PkM6hsfCKqAudRCQfW7rrRcB9vvrvprE2fo13RV13nCMYsbIN3iTL9IIbu0gMZuEjZDLYUA== 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 , Rahul Singh , Mykyta Poturai Subject: [PATCH v13 00/14] Add initial Xen Suspend-to-RAM support on ARM64 Date: Tue, 27 Oct 2026 23:05:49 +0200 Message-ID: X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|VI2PR03MB10907:EE_ X-MS-Office365-Filtering-Correlation-Id: 667d5e9d-170a-4d42-29af-08df346e21dc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|366016|23010399003|1800799024|261009223027099003|261009221227099003|261009223327099003|261022105027099003|261009221727099003|261021121427099003|261009220027099003|261021123027099003|260925021911599003|261021135927099003|261022075727099003|260925021311599003|260925022911599003|10067099003|56012099006|261026121527099003|6133799003|18002099003|5023799004|11063799006|261026140227099003; X-Microsoft-Antispam-Message-Info: sa/c61pX41Kq6Ui4in0sQazEj/Zp2i97PsLBjjEO2as2ykPnVdalJ1C+91MWuirpFbKmFVIoto/bXjf0nnpa4daG/T9AaB6WwzUaCm3rZFn9cPqohDwLqCKB/VcRGlWUTiGcEgCcerAJcelWXYZYQ2rxHmpn8UITTFBogLlz3HTmblO0Ry25Apaiyi6b2sDT2AP56ZtBw3J+SamG6nIWDTCrkN7q47pieZuYtCVm2SZMZNJz9z7t17gCrcizcOnFip4K2mLQ5c5aO2noo9GH3plXvGZBBxnytcPdcSc2xRxeqgnnan49n/XnPQP6dZOPq8djOXclqWzSchXpDzvWubtPzzxky4XRFCULmXf+WUsyANPXu+jhpcZkOGoTALe8Mug53VCBf1i8PpA2TBDdW47IpebyoUkT4BK9u9UvzTGGMT4qplvzNaUO/f9qC6GHV+p4ZhECo2hJZ3eUbLuXVI7mCADjPyp1lx5/4GpSshSlFDAD0fr3oHW+LsDzMqK8tGpMPiIx2/MMAHsVnd0JIEv3Qrs7cX/1Sg72/4nCKGmbnk35O/7+dJe0ZMvtRDPcIO3wIqbf0NtmJnOxerQSVBvL5VtRkwc+ezF2zq3R7YipiKpVoefY7zf6h7+gGzpt6oFTAepgvcZk72Ef9T3yHg/HpTwq2sGROrFS7sz+8og= 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)(7416014)(376014)(366016)(23010399003)(1800799024)(261009223027099003)(261009221227099003)(261009223327099003)(261022105027099003)(261009221727099003)(261021121427099003)(261009220027099003)(261021123027099003)(260925021911599003)(261021135927099003)(261022075727099003)(260925021311599003)(260925022911599003)(10067099003)(56012099006)(261026121527099003)(6133799003)(18002099003)(5023799004)(11063799006)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ewgo5DRi1ML8+DLOEDwufqbkNcuZL/UejmEjs8lWIdglD7DmCnSTenpVAVFy?= =?us-ascii?Q?KrOxry2TQYTdA6CzYfHVJCrzHA/DGt7/ZVTqiiLi0aZlpP6LGTvnxl3ht+/F?= =?us-ascii?Q?aZPgf2A6g1ajxUNWX3yhMHVAk3bzLPeWuwk2ayPiH2+JiNXdHkeo9t3BOPTJ?= =?us-ascii?Q?B5ckpxQMEytegn/TNyqI2pVONs1wYgpkMGOE3OkdQLc5gdg2IYoAKgUPMRYs?= =?us-ascii?Q?EE7Jy22+hq/4YBA/lwj56SEv6oxyX7Ic96zBHOpvLW7eBhIGWULPRzjDe/AH?= =?us-ascii?Q?aNhc1WHUBDyqWrfDa8qJDc/DYh0pQrl5WSH0Cx/t2iyjiI+UGMa9otn+ucu0?= =?us-ascii?Q?ZgR2UuZBqJVnV6ZFWfua2sMEsaOfxaw0o+uEhykq4JfHH6v247Elr2U8rEex?= =?us-ascii?Q?ZUWLkH5BGxOEw0M347PmjOHypwKikEc66feh9ZFVx2TJdCy+8DsCkCCExQYe?= =?us-ascii?Q?KWUf1oeAdXYoxOABkbvKSCI1vXKBdDphdwwmxXTigB62jcrCOaSm5U/QeN+l?= =?us-ascii?Q?FhVAJxZMUPi7kScR4zvl9WeL95Am3zbX6HJnshyWh/nXFUIHOLOOGNwhqxig?= =?us-ascii?Q?gcDKZI4IheZeIptA6PfAWo8CIohZBWYIdaVufmnAU3eNNnZTezL5dBNzdQJM?= =?us-ascii?Q?N9RXkf12VsBdaCczy0a6lJc83yCX6IAORphyz/gR3+MzFyxxYKDjNYvAz+6w?= =?us-ascii?Q?8cQ1z/ikzEeH/ESFhDFheNCkVQEm2HEBZSWidLjUIbdYA4W2AK417nM6KXnv?= =?us-ascii?Q?t9pZX4cVYHnRCnbk30Xx84nRAXRIhtLdVyg9PalPC0a8XfNTELI8YumlrcbB?= =?us-ascii?Q?lMCK+aJCwfOiT5NJi6acXbbQDdLAgn4sHC5yY3TeRmUNu6uS4NzM7kwrcanf?= =?us-ascii?Q?eg6jy2xBXStPpdHe/4X6ZF4bL4wShizQPQsivVzFDuUAl3Ln0EA5umP1NJWW?= =?us-ascii?Q?byiLgYRdm0nI7TM5DoL7Ua/h5iUewvoNeifVxsbiAmAp8LvVQnNcM1NPQeNm?= =?us-ascii?Q?3R8JbyKtiNqs6iVnYXlOadR+8/oW3Fb6ri5jtvMWt9E88t7CwbVSfe9U3/rR?= =?us-ascii?Q?tp8yZ31bONh+C2E92QP/yBA/h0lVUiYLPYFBKU3nx/vYLuO5W8f31htm9Rtd?= =?us-ascii?Q?BQp3kwTK8uAYAjNGe43/9gJAGk1uCnMD/43i/cw73IrmdO/7SDLlABwAaERT?= =?us-ascii?Q?5T2fQq9gG+D14U8eg+pPfc80pwQPl3ErEOZz0DmUHsIwYssfFUOsYQyRd/uF?= =?us-ascii?Q?87OGR2/WFyBSwd0dDk0oRfGBOLxeoGYxs/rSr8pIfUbY4xBHZ8vQOeN1lkE1?= =?us-ascii?Q?JofEgFIdxFP0ArBrLH2qOVnrrN2wjrSjXvDcpb04CcD4YrOAkJUydy6aYTbN?= =?us-ascii?Q?59Vb6pmIrlOq6H4TPaxUm+PbOiXyuRu9oXZ2d/Uej710HEUNFd6EaJceCyTt?= =?us-ascii?Q?PgwD2Y1dAjKB5fWvH4tY1wkYCTT4+nJxU6vDHCTWrh5w8Vmv3ffYClISRUW7?= =?us-ascii?Q?BUyM7SJpEFs3W1s6qVR4VIbMPnGcobZNIxc1AnylYwmsnpuQzcNE/1vxp0Fq?= =?us-ascii?Q?aOU1q8JlsC0dbibsNxa1D5V2XaEg3Fde6jluyQfgNLi5xfX/zw5ucFqg5znU?= =?us-ascii?Q?omI+Ak0Nz1nKMcmLEJA9KfcvRfvh/X2CELaZC93mBGLJ65DmQCLyfeTiFeYS?= =?us-ascii?Q?lFCp4KJ72MhrO2fvtx8/wkDWLQy7jk+nWURf1QESaKXpxK4RGbCh4NhJS3WW?= =?us-ascii?Q?bNYn7nbZ9g=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 667d5e9d-170a-4d42-29af-08df346e21dc X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:13.0287 (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: wrp/g9juFzqpAyp3QPPDl4gmYcGGFH7Wc2BxM2fJCKG9OsvUjq6tZJyHivh3jxLKJfEYFIWy3BGQ1xgl7FuZrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR03MB10907 X-purgate-ID: tlsNG-4011c0/1793135176-58FC6CFC-89448A69/0/0 X-purgate-type: clean X-purgate-size: 10684 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_SUSPEND, which can currently only be selected when UNSUPPORTED is set, and thus the host suspend backend is neither enabled by default nor built in supported configurations. The separate HAS_HWDOM_SYSTEM_SUSPEND policy bit only changes how ARM treats SHUTDOWN_suspend from the hardware domain; it does not enable 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 as PSCI_DENIED rather than hidden through PSCI_FEATURES. A non-control domain needs a control domain to resume it; otherwise its request is denied. Key updates in this series: - Introduced architecture-specific suspend/resume infrastructure - Integrated GICv2/GICv3 suspend and resume, including memory-backed context save/restore with error handling - Added time and IRQ suspend/resume hooks, ensuring correct timer/interrupt 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/resume - 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/-/pipelines/2996178037 Tested on H3ULCB (R-Car Gen3) and Orange Pi 5 (Rockchip RK3588S). --- TODOs: - Enable "xl suspend" support on ARM - Add suspend/resume CI test for ARM (QEMU if feasible) - Add PCI suspend/resume and save/restore R-Car Gen4 PCIe OSID state --- Detailed changelogs can be found in each patch. Changes in v13: - Rebase onto current master and update the arm_smccc_smc() call. The API update has no functional effect. - Add a patch to defer freeing per-CPU areas until resume failure cleanup is complete. Remove the redundant RCU barrier before restarting CPUs. - Keep the GICv2 CPU interface and Distributor control state unchanged on suspend entry. Document the requirements for preserving pending events. - Check GICv3 active priorities before disabling the interfaces. Panic if the redistributor fails to enter sleep, as suspend cannot safely abort. - Update SMMUv3 queue and interrupt handling based on the Linux suspend/resume fixes. Preserve unread events and check reset errors. Panic if rollback fails or if the SMMU cannot be disabled after a probe reset failure. The probe and reset fixes also apply with CONFIG_SYSTEM_SUSPEND disabled. - Block host suspend when Xen uses R-Car Gen4 PCIe, since its OSID state is not restored. - Deny SYSTEM_SUSPEND for non-control domains if no control domain exists to resume them. - Fix MISRA issues in GICv2/GICv3/ITS, FF-A, SMMUv3 and the host suspend path. Type and name changes, explicit return-value discards and comment updates have no functional effect. The SMMUv3 error checks above change failure handling. - Document the LPI pending-table lifetime requirement for CPU hotplug and clarify that IPMMU suspend/resume was tested only on H3ULCB (R-Car Gen3). 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 redistributor before restoring CPU/virtual interface state on abort paths. - Refine ITS resume so MAPC is replayed only for ITS-backed collections and 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 simplify the resume trampoline/context hand-off. - Re-apply boot CPU errata/workaround handling after SYSTEM_SUSPEND and move set_init_ttbr() declaration to asm/mmu/mm.h. - Update patch 12 details: shorten SYSTEM_SUSPEND blocker logs, use %pd for control-domain logging, mark serial_suspend_available as __ro_after_init, 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 from 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 patch 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 failure. - 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-register 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 (8): xen/arm: gic-v3: tolerate retained redistributor LPI state across CPU_OFF xen/percpu: defer freeing per-CPU areas after resume failures 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 | 232 ++++++++++- xen/arch/arm/gic-v3-its.c | 146 ++++++- xen/arch/arm/gic-v3-lpi.c | 87 +++- xen/arch/arm/gic-v3.c | 484 ++++++++++++++++++++++- 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/pci/pci-host-rcar4.c | 4 + xen/arch/arm/psci.c | 39 +- xen/arch/arm/suspend.c | 203 ++++++++++ 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 | 125 +++++- xen/common/Kconfig | 3 + xen/common/domain.c | 7 +- xen/common/percpu.c | 9 + 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 | 317 ++++++++++++--- xen/drivers/passthrough/arm/smmu-v3.h | 1 + xen/include/xen/list.h | 14 + xen/include/xen/serial.h | 1 + xen/include/xen/suspend.h | 2 + 38 files changed, 2295 insertions(+), 120 deletions(-) create mode 100644 xen/arch/arm/suspend.c -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462575.1673569 (Exim 4.92) (envelope-from ) id 1xLoNG-0005dP-4c; Tue, 27 Oct 2026 21:06:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462575.1673569; Tue, 27 Oct 2026 21:06: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 1xLoNF-0005d9-WD; Tue, 27 Oct 2026 21:06:26 +0000 Received: by outflank-mailman (input) for mailman id 1462575; Tue, 27 Oct 2026 21:06:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNE-0005Oe-Ht for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoND-000vfm-V9 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:23 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11248-8faa-0a2a0a5109dd-0a2a450ab3f8-6 for ; Tue, 27 Oct 2026 22:06:23 +0100 Received: from [52.101.84.110] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1124f-f2d2-0a2a450a0019-3465546e8498-3 for ; Tue, 27 Oct 2026 22:06:23 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PA4PR03MB7248.eurprd03.prod.outlook.com (2603:10a6:102:10e::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 21:06: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.0546.021; Tue, 27 Oct 2026 21:06: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=weHTYAXxufKCmA58N24JSroAzi+8kapvuf0GGjtv665+3t/HB+2xy/jChVNSle6ZgxpUP8Nkgcf15XQ4+S+Eok97bsQkhFYhklclnUUWzHT+G4WFDZQmrSHCaZRw1N/v2XGtaKeB/ZeXSGx9TKRjBCtSfrS/ekgmc0LNH/b1N5/jWti3P6SaPEf6y2/tLGfOmYixkIDiyKasFmm1U4IYwlepsRC8Vs/WPhZi6R+g6/B3sbkeDhkVS6QmvwqvsQGuC0Sq5AKXWJk0GwBV2l57j1kNPCvWvDRtrmI+X2JRbtG6W+esxZIvAb7OrVmiL4L0nHJDH53n6DmyUgNz2jpN6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MtpFdnNv8BeIMFzC1ZCCM4xby+yu82MO+Np34s0G850=; b=mZyMP9fjEBVIP3/iNwdxiDtSqCXInccE3wsh9e/Y3He29OTVdniA9ZlrN5BBLEvhvqIfu8fsXiTJfkEdEZKLCF0LYnX/QuuJ/9OHupvSdGi7Mnn6lrxI+XKbCJ9tmH3JROfu0p+XCThGuAQQbygW/IWsRe26MsqK2A81amJpylxKPYf8I2Vj2tiHgjaOr5NFgsf5lMDqLM2DdPfQErgZIEOxeKANBZhNgnXuuxzpv7okFkZIOd5LY9PGaAgyfniuMmoCJnru4g5cmg86G1ZQ7d5hXTd3N4LKQ+H0dmnfH/88+iA5hCZLRq33KjnUvEyjdISCEYJR5oC+rCZY6NVERw== 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=MtpFdnNv8BeIMFzC1ZCCM4xby+yu82MO+Np34s0G850=; b=bYUVgoaSmrz7YVNHJCm7aTGaQNYsQY+eP7TMZ/RyHowxgdTMvZrkD2Tl2kf/LWRYhihmCDfcsgq77NGjwqsSS4eywEWO8//4TIkApnfDQNKeqOlo2PRPCjcV379Q3xcU5mL3O18UatYfw9BZRgIwy9WOMeciLjGAiS7MuerN1AnNaJu0h0XlXhnQtcoZWazxBrwgA6bSBBfpCO9c8VrK6i6HayISPHpOx524YDv9zZVpKb0m8WIQs6jytAVQvAmOkFrkLx2Wgck9vx84cJrxxNzw09bE7UUNovG8VVOLpvK2COesol4kqVhHSvwUPuBdLWGNOEt36MD02TZy96naBQ== 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: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v13 04/14] xen/percpu: defer freeing per-CPU areas after resume failures Date: Tue, 27 Oct 2026 23:05:53 +0200 Message-ID: <3f0239435a9013b5ea35dda4ddd0253ef42e26ee.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PA4PR03MB7248:EE_ X-MS-Office365-Filtering-Correlation-Id: 2acbcd48-c2aa-442b-f7ce-08df346e2643 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|18002099003|22082099003|261026121527099003|10067099003|11063799006|56012099006|261021121427099003|261022075727099003|261022105027099003|261026140227099003; X-Microsoft-Antispam-Message-Info: mOrxtybOJJl16KCB3OEtoxOii0VcGlS3DAnjloGkIY7fFkwiCo/YNWBpeXQkm4A4Zw05/IeGQN1E6Ly4ZGUwMvMr3WIEYikD5Zu0l3MHDgnfy7YhsjgTubEGXr+JNMGrVbj2RnqyvNGJFH1Di6TdHgNzElQrnkV+rah2kRNW76YMDOa7zUIXuaFlSFGKkgdOqkHqqdi6zFh8YpiQp1BaHMSeQMUgTLkb7wU1JtUTa0MhS3EtYYVMJqvTd8WoLw0FY985c2o9dhmW1+UTjVfUlxESiK0/2Mi5X8I/Z0KUMshaxbMRp4wV/cfmIRt8IjMGMWJNXWHbXmf9CfuQKehLGWboDOj9eN9SxGCxaDhFZM8+eW+ysZYu2fm3g82/OO1D1/AX94TctKbcmONPa2jaFLe+CFBge0ZKhmjMdMEmK4r2fqqqxFS1qmQ1eHSiV1o3krXkqmV1P2HD96SYiOdbbrLCHAD0qEtF0Ctr3xM96FV6bsK43B1GK+5dUAMKsvn0frY4RKRNrikURXJQH8Bvg7ZYc2H+fwtYUrqUWvOb1lY6/fSBjmb75yRQ2RjShaVCH7QousApuOdIEovjdS1xesFkbIcOJ0nLCHQ7TYtuCbPTN/hEV3Z37ku7AkLDOQD35+BDzBrvARvYVEE6dM7msWY10p5Pytf6wqTae5tGj2o= 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)(18002099003)(22082099003)(261026121527099003)(10067099003)(11063799006)(56012099006)(261021121427099003)(261022075727099003)(261022105027099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ja4K+PN+lQhzRh2LgCuUw0gn5N+DmdwJz1Z5L1AHnxWlwrzZFa8i/YeajIzA?= =?us-ascii?Q?W3lgZ2tjPpKVcMpX+YQTgVQ4qYQz0+xE7g+++tS36cayrBdANooikJV0NnLF?= =?us-ascii?Q?TyX4fh+q0WoCvz4EGNo7ioA45bXliSQQoeZRjlSOjCK/LU1uJVIQewTqvAUl?= =?us-ascii?Q?rhbPP11jAoG2iwDj+C7XzGQQ5OCQHbfs7FJ65qX1qrufp870MhTRmY7OsZef?= =?us-ascii?Q?odbw/LONgYAkmInYK/Qikv+tXNtDl+OnGiyBPlLJQgtokB+UL0uXaBstZxZD?= =?us-ascii?Q?XB/aIxGSrUNvG7pNLk1wHfQYxlfhcCD3EnsSP9rYjh/JoemdDBrqbPKrO55Z?= =?us-ascii?Q?WAH5EHu/dPO5P9EWQrTRhBQvWz1ywNPGaUzX2iPG7zuaRpfyDlF5mVAmlEyT?= =?us-ascii?Q?IF+Vb3mRZEwI0UTtkRs4Utq5DNsfJu4+iO5du3UGSfvu/gdz6jPKjDo8iXW/?= =?us-ascii?Q?drGzYHibSB9FvHfB3qaoCfTZ88hhWItus/U1VNctidfsLIc1uICVoWQxZl9W?= =?us-ascii?Q?XGlPBdRCp/GHItPWa4s2b+A9JtuedNFn7OWs8BGa0Ugsj/aeRAhtNoYGZYRh?= =?us-ascii?Q?UajZiQLx/128M1XfcLZxfcmegFAMMqZ+vvHKeB/o7Ku18KqybWJ5Rbv5K21h?= =?us-ascii?Q?gG8tLKaBzgkYgRmBd54WSQ/Avnt3ATMd7W2yt3QUG4rPQ0tIetLT0Z/ToEq3?= =?us-ascii?Q?tW+8wIr4CUUAVg/CFX46x7rE5nJ/L6Be+P/nSz73eko90Bx1vbTnxdoHqh7h?= =?us-ascii?Q?lrWX84ZlAco5QstJH7vkS93qGzjmHYKnIlUdLv3I3BhVLaBOahsWd0FOI7og?= =?us-ascii?Q?6QcqVexz6UCzOmT2hgo55jBgJiiiy5o0IyGhFeVQ1zEXZ5NLmWtaffeghOyD?= =?us-ascii?Q?koIn1ftLA/9ExtTqXQvTgtONA9n0/lVIvRHAyOVP6RMAzIlfWkx8nddSGMrb?= =?us-ascii?Q?BjL8OJLE2UkHOiWMPy0Y9kg3OTxX0DOu6BdtHbCqnjKLG0A7mnQxQI4H1pLJ?= =?us-ascii?Q?g6z2crDPzuE1NhXWX70hY94OEb52JCbmyb5DZig8P6kGiDq22gTsw7Bmlc5Y?= =?us-ascii?Q?XlKj9EJHkcmzDwfDBIdOFLu4BzWobUl8QnkXlhXSnbS3chsbJBkk+mKryPn3?= =?us-ascii?Q?FN2l2X9eScpfv6sM5GgbpGp01wZj2hMIn7pH0R951oCsnv/JTJeDH4fM8Aj3?= =?us-ascii?Q?/hanF61okuA7kzhZP7cA8yTeiRYqQ3Adhq1YmbM8FBPHd2BowhY7IH7UDfFa?= =?us-ascii?Q?Io8JeABJyC63MJCDMI/kqjJBCwZtRbJIi17uNu3LvWtfgZQXues/hdw6S9jW?= =?us-ascii?Q?iWojkjPgwoTWPthLE6nlts9zTelA2NhEvKJQ9u5bxK6G/HBMqXqyy+/3ma3V?= =?us-ascii?Q?6dEMpBUXAE0AqDxCQSnrddWufDeeQvP/N+AvzD72cwLkxNnZ2MTXyuWbeYFU?= =?us-ascii?Q?JQgoU+BJLEI4w0fDDvD7hRc2F+V+4+6w8C+J4N5nQCCOaXXRfZGqJUHm6D4p?= =?us-ascii?Q?NdXXFk/viIFVHyCevQCpsgL726p9KikE1zi9oIAnLQjIcKdxxkrzZ6ZkWtoy?= =?us-ascii?Q?hDwgkujSyUDWW08Feddem60ACvNrc3jNDoEveCCsl3AehXZ2htiQj0dLKiO4?= =?us-ascii?Q?2nBJ5N7a04MXdqN4OJlV0LfpcX+LQKME3319m80Ecb9mOpCPQ918D6XB5FgV?= =?us-ascii?Q?srr8HgYvhS9YR13TjmDMhjMFlHn3dsSU2c/DQU4w5M/9UxJaktr0wNDyw9ND?= =?us-ascii?Q?quN+n0zr6w=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2acbcd48-c2aa-442b-f7ce-08df346e2643 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:20.3792 (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: /BKRxF/B1JWrMkuHyyCL4trwSAwJG4O428Gk/UMIY2vGvVCTOL/nIcTO0AidgZcQSxKQl2osdgOg9Q/uUY3KOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7248 X-purgate-ID: tlsNG-4011c0/1793135183-4ACDBCFC-E950136F/0/0 X-purgate-type: clean X-purgate-size: 1722 When a CPU fails to come back during system resume, cpu_up() sends CPU_UP_CANCELED. After trying the other CPUs, enable_nonboot_cpus() sends CPU_RESUME_FAILED for the same CPU. On architectures which do not park offline CPUs, both notifications queue free_percpu_area(). The release metadata, including the rcu_head, is stored in that CPU's per-CPU area. The first callback may already have freed the area when the second notification arrives, or the same rcu_head may be queued twice. The CPU_RESUME_FAILED callbacks also need the area to clean up timers and CPU-pool state. Skip the per-CPU release for CPU_UP_CANCELED during resume. Let CPU_RESUME_FAILED release the area after the other cleanup callbacks. This prepares the common code for Arm system suspend. x86 parks offline CPUs and does not take this release path. Signed-off-by: Mykola Kvach --- Changes in v13: - New patch. --- xen/common/percpu.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/xen/common/percpu.c b/xen/common/percpu.c index f180f37253..e957c3c58d 100644 --- a/xen/common/percpu.c +++ b/xen/common/percpu.c @@ -82,6 +82,15 @@ static int cf_check cpu_percpu_callback( break; case CPU_UP_CANCELED: + /* + * On resume, CPU_RESUME_FAILED is sent after all CPUs have been + * tried. Keep the area alive for its cleanup callbacks and let + * that notification release it. + */ + if ( system_state == SYS_STATE_resume ) + break; + fallthrough; + case CPU_DEAD: case CPU_RESUME_FAILED: if ( !park_offline_cpus && system_state != SYS_STATE_suspend ) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462576.1673577 (Exim 4.92) (envelope-from ) id 1xLoNH-0005sV-Ij; Tue, 27 Oct 2026 21:06:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462576.1673577; Tue, 27 Oct 2026 21:06: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 1xLoNH-0005sM-Ey; Tue, 27 Oct 2026 21:06:27 +0000 Received: by outflank-mailman (input) for mailman id 1462576; Tue, 27 Oct 2026 21:06:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNF-0005ZP-PD for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNF-0005yu-6G for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:25 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11235-e002-0a2a0a5209dd-0a2a4506a068-10 for ; Tue, 27 Oct 2026 22:06:25 +0100 Received: from [52.101.72.137] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11250-195a-0a2a45060019-346548894169-3 for ; Tue, 27 Oct 2026 22:06:25 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:23 +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.0546.021; Tue, 27 Oct 2026 21:06: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=uj3M1Nr15jfBhNlUXlZcT/hHY+hH+1qAm7OYeIQlgdOxJ/DDzlZCCMZ636ark1ZPD8fQ3PWWIYSDEDpsxOeobvxeb6x7FPW8JI4deare2wxVl4/cP4rfLeyI32JmsOjqZPzQYksPKtMWm+LVQLUxbn7ZiFy2sAOKJVa7l/nJORRoBRIUYRQbT8CeVhSH6BTgm7juI7VOZqgxwoNEss6vMSvmELOFquKp899/Qu0DUQQ9xJOji9/3WTrgttwxFGSjI9QDjI4J0c++1Np7cpeM8+Ed+e5Zq8h8eXqQUIAp9oHvH/XFaNTsehMSsktT6I5anEJprG7/M8p9EGIz02cVzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GMlcH0m+z/nxinRLh1GdlU1E0fMbGxX0okLxzqtnYz0=; b=EqyGatJ+K68akSN3ztrrLgSWvXdBWFCj8lu9dAYISwdYeKK7x4eToCi2ZVaA4UApY4uO1wj3xd3NVjoVND4enMndWnIRACFwgUz8lanwinEHFbtUgV2JeNoCi5mojUOAOEU1OMEzTkIY5gDYaBDbx2VRzL5NJSdNTf8bsGfKgZTWrUXcmCuuuzIKCCt3rIM+FlTirbaOd/M3plVExV4eMdFQyUQ46Dmq1O7o48r7GfxDZLw5RfAk4d/VHOVDswjpwkG4TAZ2ae5wE/taNT8SES5qicZT27ZDw1zrvHq/wDLbX9+Lj7U7ozyDOaLnciWQJvuXnlI6Kkn4J1aS82Zhtw== 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=GMlcH0m+z/nxinRLh1GdlU1E0fMbGxX0okLxzqtnYz0=; b=ld5hQz/4OpDiSYglpYdlfUmU7TBghSpu2AjhpUtetLQ3H4K4n6rd/TXcS+a5U8puPtEGsmOvJqDnH+L7l28QqUz+f+0EDYtVf7pYAp2q15CaHQy0bYzo+z+FNsMO+ipAzJapFy1sfe8/f6K6hfMFvJv0xjjTw144vpJU2dBoAb8WKXY3oUQ/iJfPAxUP8CbGv9oAHFnKkqB/j6wb8gAVXZyKCqc8rGLYYs06juMvfZ4iQWseoS9PS6DU3yXCZ1bU5jFo4Z267qy/Fo7knM2GVDuTR3rGC/TSR1+QWvl8NMRv9BoyH30dtrT3djIQTAO6VbCKVgfZF1P9oFIauuaWmg== 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?= , Luca Fancellu Subject: [PATCH v13 06/14] xen/arm: gic-v3: add ITS suspend/resume support Date: Tue, 27 Oct 2026 23:05:55 +0200 Message-ID: <02f04c5c50f87acbbb4d180f2f1dcacae60eadbd.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: 731656b3-f3ee-4a7a-7026-08df346e27d1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|7416014|376014|261026121527099003|260925021311599003|261022075727099003|260925021911599003|11063799006|56012099006|261009223027099003|261021135927099003|260925022911599003|261021123027099003|261021121427099003|261022105027099003|22082099003|18002099003|10067099003|3023799007|261026140227099003; X-Microsoft-Antispam-Message-Info: wKN0ZeMnUCDkqUjnTj6+glItLyTU51Ps+xxushBe/ZcleTpbOSP5SuRzh5YbZIZjuqz3o3OYSz0IciERd1tRXBSMIBAiJSv73A1fWXyg371T0pJnBG4Aw+mc7dKT0EAbxZ5d5k72FtdgvhgFTez+eXFMluSz4CNJAENJl+mowOiEOymr+A3a9ljqfDevxpkj3LpKbL/nqzoeS6FZF3WKOdm+YGAFSt5TxMKcFC2Tb4SCAXSt8DtTmMJvtLRViM6cWzNATGLkrWZn+HBXanigzoJsNMK+X+pPM5YVMUbwdXQQZJABSF8P6G4OdjSC99G5sOwjugJ2do1GnBsmbGyeFFccwNEAxCLGde64hONU7olwHwKHKhKAPwc6LFFcMVG5gWwPY91TX1WBH6Jg5VUWVYfCxU/kAvOsELtpJoWbmvEbdfGExQwy48tlMLqw6BUJUw4wT3MmhsW2WfdJFPB1GqEfaxZDtucHdvOz1bvvh2TWvcj3EyqPIBEyo8KJLWQQkIKveG5kEOALk0ayNYJ4jlvKOixSdb0WpRDrZzNPdZcmbmIQreFnEMPtqOvAXMt92MxOmRueWPyvkTlV0rjrzMyLKg9mbw7jNUhJwX3Oc538fg8sh6NvGqdI0MOryGcx2sAoyln6E4whPlsSdi8kWiCB86a5Q95nmL8qGb4VOKI= 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)(23010399003)(366016)(1800799024)(7416014)(376014)(261026121527099003)(260925021311599003)(261022075727099003)(260925021911599003)(11063799006)(56012099006)(261009223027099003)(261021135927099003)(260925022911599003)(261021123027099003)(261021121427099003)(261022105027099003)(22082099003)(18002099003)(10067099003)(3023799007)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Q0TAZ6OZ3TfQCGfc6eoPCm41hCjy5S8yqt+Bzoke6OPE07MPfqG7wv6G4m2I?= =?us-ascii?Q?84FWyquxtfQptStWsIA2nUjcwBv+J+UUW0OKcdkpOPDkjsx6D4DUhalsleS1?= =?us-ascii?Q?uBP81wXMt4l5NNdafvcN8A0C3QacaemVIC9yhCUjcWcoRoU9t8SVqAFO1pGd?= =?us-ascii?Q?67TM7Mg9RfwjymWJ0xqNWiFKk/gEmVifJNkCTtYicTjGMdDh8sZ1SgZNlo+h?= =?us-ascii?Q?7aSb7FfYM63jH5GRSFNta5tMjTMssM0nGQ4H2c49NKxDH/RzvGpBjGL0XNOf?= =?us-ascii?Q?osjJNGk4ebMW+s/zierrTnUvZDTf3sNGkjfoZK3h8y+blTIGoAiiuagja5Mp?= =?us-ascii?Q?GT5/BLYyos0LG0X10eE2iuh38GQVPc4CcorBYCu0AJhjFv5ry4IS8KAfdbkr?= =?us-ascii?Q?nmcSApVjIFsMpeqE+jYIz3cw76rNT/6gZfe4y8BVu7K+HcnpOKZDfrfS9+h+?= =?us-ascii?Q?FtE38TWZKjPUoXJtN3KCVUbSMAauiby+v0Q65yiEPA0RPr3f3lVK/wM2taW7?= =?us-ascii?Q?iyNdCQrHJfP717HcF8tky1XNU+eIYfnMaXHk1xwIhT+enTOVsg3pzvSTlSRR?= =?us-ascii?Q?1etUkiMkcvl0a3zYLVumYXzGTxYcdqcNoV20pd+wyG9+p8iKoz0iwSsgnHc8?= =?us-ascii?Q?HnE9oLDXYcWfUskdQCba9RJtvGnHq33/TQhxSrNd0xiiEJKCjXf8vDblUoMU?= =?us-ascii?Q?hrc7NAkqy3rdSWcgvmg4/1ewUa49dypI6vtqOmqxpDOR4VV5C/LTZIuMQedL?= =?us-ascii?Q?IS6+webrlsyRfEojfi/cxgXFA++CZbDlAXj/R0e+bg302QtnP08D4/i52ulA?= =?us-ascii?Q?BxiIhXpiJXcCWcposPFzaTl28039A+H9rjeYn7bZl5iw4JylX1+eRHGtzZg2?= =?us-ascii?Q?LZb5khwKixh5GTipXwQagsnvtKQMfYJV7eD4O6IRLHceBN/Lk1vyDcEzCY73?= =?us-ascii?Q?E5iKvsDRVmqQcFYzGJsa1HOgT2+Ts7F5rQzExObIW3PiYtFG5/W/76hwrRPZ?= =?us-ascii?Q?zx8vlEt+XfRJDGZLa1P9fCKRKCK1MNoOhWRJRtwqFgwaxUhJW3axuNwGMSzJ?= =?us-ascii?Q?GuHymnSLwRe+BhEckU+0Ai6g9VDIQXPvtU0EuMCfJhCTi9QDsBZlVjjewbZz?= =?us-ascii?Q?oVwVKGCxrJelCnzfHlJqslZopyu1P0KzoEYnQvDTkgLOEEnLhRr8fvuVSHli?= =?us-ascii?Q?F79t1UshKG6wGnDAEONWe7WEkwW4ILkvxTd908iNZ0Wmcfvlwj0kCbbj0AQL?= =?us-ascii?Q?71B3hX67stHLS8XGcbG8tXVpeNXnOJ//SRofDVeTRj5cGqc+LIMVXvWqLxkj?= =?us-ascii?Q?kpbtikauuDo5vDR+l+SLBD5zvqu/o7d7/tDCB1VRJrTygqk6x6KO5xozvWm4?= =?us-ascii?Q?am/jzeFtEZQ58PmIECfPIZoF9g/daHDjGaOu8gJaqXmmAOVaW3Ezwp906cW6?= =?us-ascii?Q?nt+C7mq4jHdCpY+tM0RpznBnXF2kl4KkHIeIZBEZ4iWnc7YzgTGD1StgA9kD?= =?us-ascii?Q?kY23ZwsGHLHKxyo7Wxas2BHxBjdRGzzZyVHJPStN0iNQBHXDt+CTi28ny5/p?= =?us-ascii?Q?jjLDKlgCI2jzKCvdTwjryO9jpv6/fHfbAjxSAFlD+RkcVoYO2CtfeBk3Ujpl?= =?us-ascii?Q?PNQl6y/zQYCyw29L6HK6HB2f+ndMU9C4gjLl5xygkhFjIwXrN1i3S+kHF2ns?= =?us-ascii?Q?w2NEw+IdHLq0lBa0zBIwxPEZYaZvgEq4xVuBZyESE9dsGu4BtSb/UCVXIlD/?= =?us-ascii?Q?Lre9SHJ+Fg=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 731656b3-f3ee-4a7a-7026-08df346e27d1 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:23.0219 (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: 6qm7FwHhH1qziLYvAGqgOiYZbIwCd/ozChGNykI8BRF1c8BjZ7K5d0DpxOpufe34TtXC8O+13IS1HQRhCdzBlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-16d1c6/1793135185-F72C677B-5E3BB557/0/0 X-purgate-type: clean X-purgate-size: 11279 Handle system suspend/resume for GICv3 with an ITS present so LPIs keep working after firmware powers the GIC down. 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. Add list_for_each_entry_continue_reverse() in list.h for the ITS suspend error path that needs to roll back partially saved state. 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 in V13: - Cast GITS_CTLR_QUIESCENT to uint32_t before inverting the mask, so the operation matches the 32-bit CTLR value (MISRA Rule 10.3). No functional change. 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 == cpu assumption explicit in the ITS resume path. - Use "unpredictable" instead of "undefined" in the CBASER/BASER restore comment. Changes in V9: - fix the ITS suspend/resume coding-style nits; - preserve the saved GITS_CTLR state while masking the read-only QUIESCENT bit. 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 | 13 +++ xen/arch/arm/include/asm/gic_v3_its.h | 28 +++++ xen/include/xen/list.h | 14 +++ 4 files changed, 192 insertions(+), 9 deletions(-) diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c index f44ee21293..f214a52ad4 100644 --- a/xen/arch/arm/gic-v3-its.c +++ b/xen/arch/arm/gic-v3-its.c @@ -375,6 +375,22 @@ static int its_send_cmd_inv(struct host_its *its, return its_send_command(its, cmd); } +static int gicv3_its_setup_collection_single(struct host_its *its, + unsigned int cpu) +{ + int ret; + + ret = its_send_cmd_mapc(its, cpu, cpu); + if ( ret ) + return ret; + + ret = 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) { @@ -383,15 +399,7 @@ int gicv3_its_setup_collection(unsigned int cpu) list_for_each_entry(its, &host_its_list, entry) { - ret = its_send_cmd_mapc(its, cpu, cpu); - if ( ret ) - return ret; - - ret = its_send_cmd_sync(its, cpu); - if ( ret ) - return ret; - - ret = gicv3_its_wait_commands(its); + ret = gicv3_its_setup_collection_single(its, cpu); if ( ret ) return ret; } @@ -1276,6 +1284,126 @@ int __init gicv3_its_init(unsigned int host_lpi_bits) return 0; } +#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 = its->its_base; + + /* + * By the time Xen reaches gic_suspend(), every domain is already in + * SHUTDOWN_suspend, so ITS-targeting interrupt sources are expected + * to have been quiesced by the owning OS before SYSTEM_SUSPEND. + */ + /* Preserve saved GITS_CTLR state, excluding read-only QUIESCENT. */ + its->suspend_ctx.ctlr = readl_relaxed(base + GITS_CTLR) & + ~(uint32_t)GITS_CTLR_QUIESCENT; + ret = gicv3_disable_its(its); + if ( ret ) + { + writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR); + goto err; + } + + its->suspend_ctx.cbaser = readq_relaxed(base + GITS_CBASER); + + for ( i = 0; i < GITS_BASER_NR_REGS; i++ ) + { + uint64_t baser = readq_relaxed(base + GITS_BASER0 + i * 8); + + its->suspend_ctx.baser[i] = 0; + + if ( !(baser & GITS_VALID_BIT) ) + continue; + + its->suspend_ctx.baser[i] = 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 cpu) +{ + void __iomem *base = its->its_base; + unsigned int i; + int ret; + uint64_t typer; + unsigned int col_id = cpu; /* Xen currently uses col_id == 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 = 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 = 0; i < GITS_BASER_NR_REGS; i++ ) + { + uint64_t baser = 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 = 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-backed + * 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 = smp_processor_id(); + int ret; + + list_for_each_entry( its, &host_its_list, entry ) + { + ret = gicv3_its_resume_single(its, cpu); + if ( ret ) + panic("GICv3: ITS@%"PRIpaddr": failed to restore during resume: %d\n", + its->addr, ret); + } +} + +#endif /* CONFIG_SYSTEM_SUSPEND */ /* * Local variables: diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index a653c5d14b..2708926929 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -2241,6 +2241,10 @@ static int gicv3_suspend(void) gicv3_disable_interface(); + ret = gicv3_its_suspend(); + if ( ret ) + goto out_enable_iface; + ret = gicv3_disable_redist(); if ( ret ) { @@ -2289,6 +2293,13 @@ static int gicv3_suspend(void) #endif return 0; + + out_enable_iface: + gicv3_hyp_enable(true); + WRITE_SYSREG(gicv3_ctx.cpu.grpen, ICC_IGRPEN1_EL1); + isb(); + + return ret; } static void gicv3_resume(void) @@ -2406,6 +2417,8 @@ static void gicv3_resume(void) gicv3_redist_wait_for_rwp(); + gicv3_its_resume(); + WRITE_SYSREG(gicv3_ctx.cpu.sre_el2, ICC_SRE_EL2); isb(); diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h index edc002f187..cb730b3845 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) +#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_SHIFT) @@ -135,6 +140,13 @@ struct host_its { */ uint32_t quirk_flags; 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 }; /* Map a collection for this host CPU to each host ITS. */ @@ -211,6 +223,11 @@ 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); +#ifdef CONFIG_SYSTEM_SUSPEND +int gicv3_its_suspend(void); +void gicv3_its_resume(void); +#endif + #else #ifdef CONFIG_ACPI @@ -273,6 +290,17 @@ static inline int gicv3_its_make_hwdom_dt_nodes(const struct domain *d, return 0; } +#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 */ #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 != (head); \ (pos) = list_entry((pos)->member.next, typeof(*(pos)), member)) +/** + * list_for_each_entry_continue_reverse - iterate backwards from the given 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) = list_entry((pos)->member.prev, typeof(*(pos)), member); \ + &(pos)->member != (head); \ + (pos) = list_entry((pos)->member.prev, typeof(*(pos)), member)) + /** * list_for_each_entry_from - iterate over list of given type from the * current point -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462577.1673584 (Exim 4.92) (envelope-from ) id 1xLoNI-0005v8-3D; Tue, 27 Oct 2026 21:06:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462577.1673584; Tue, 27 Oct 2026 21:06: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 1xLoNH-0005uR-NM; Tue, 27 Oct 2026 21:06:27 +0000 Received: by outflank-mailman (input) for mailman id 1462577; Tue, 27 Oct 2026 21:06:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNH-0005kg-0z for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNG-005OFk-78 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:26 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11235-bab6-0a2a0a5309dd-0a2a4509d276-24 for ; Tue, 27 Oct 2026 22:06:26 +0100 Received: from [52.101.65.101] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11251-be1a-0a2a45090019-3465416568af-3 for ; Tue, 27 Oct 2026 22:06:26 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:24 +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.0546.021; Tue, 27 Oct 2026 21:06: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=jbK5Y/2C5iQLFH3EjE4cvHao+pRjdqApFKuqr9VbvsdXQPIqhEP2g8+wk5iyIz+l9VkdnUjX+MSohxlSiDUN/IjxssuKe3G5R8kMKCK1GbX9grbPqODuWzrCj4mnVb6ysnrpmMZrpeiSaUH6AXlXhKFH5gbSW8vPqvzL74dOt4t0TuKC02USbXMiI8clBAC1xV6v9cZ9w5AFfVQ/8VM/oL307YWuEHizvByeQwDqPoTnkU8Bl1+SMwHC79L7miYAZMHQF+wxGv8Bwbj36DAptwDZznQRUP9q6VS2z9bQTVo+mezo7WaWAsBqd3TWkF2iVnoabCjiPLctzjqurOjR5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jcYFN5ETNzqH2h22XKFCQYA6dn1VHCIQVqzHW6lS7TQ=; b=h/8kyb7uJl/QQvEjtzFSctGD+CwmLAig91Y0lYZ+cRnx25zcf7oWoHPUu3WjjyWSZXPT85KpCfrF2F/PgiZei+VC6H/G3Ln7534V/AUmnA2T6T2JJ3VNvsjsNKc14Zr0NwDX6VbOCWm98Qfe2h6tiG7Ob97m1Ghg1KVBZCYFNKs3HMfAV9UAXTaVa/kN3mt7qNegCDLbX6BMa1qZ8GQd3XfNarqEW7MrifiiJDSyCDls8YbKZg5FH7piprFG50vwqHO3EdurEdjG1oPpXJ4OoI0PHHKEJB8eQ2hY2++n1KD1X5sGgXjLb7Emw1QJ4RisBmeXlLdPwswTp2kk3fUjFA== 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=jcYFN5ETNzqH2h22XKFCQYA6dn1VHCIQVqzHW6lS7TQ=; b=QFy0A/VMU2pHHvWPaB/MZjmpoW7bxBDpF2SGdgeaiB9AtpPB69QUalM/x1qBsHO9nnxhS/tAPEvxoLdp7k++eJcz3M/yJGBuGfDL+O9WpCpNxdKMsbT4lg2mikT9OiTeIJQCBshr7ab4RsDotma/7Z3KVQHuOQLHo6KS6d/9lJgOHQCllFkV0lvRx2o0tEAQdOGNkhnUP+f9igAbwlhEwrMR9Qs7BqCfVnOL/3G5T/KxyycQTxjKo3Qddhd6dDgYYHsygTs6hH5DQ4068OJfgQCK9wgT9oGSwK3FCGWeDiK6bp4POgn8WcEC3+4BWfLabBjVHdtuEG7qB8oB2Jw/tA== 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: Volodymyr Babchuk , Bertrand Marquis , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel , Luca Fancellu Subject: [PATCH v13 07/14] xen/arm: tee: keep init_tee_secondary() for hotplug and resume Date: Tue, 27 Oct 2026 23:05:56 +0200 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: 025b9ab8-5c0a-4ba0-4ff1-08df346e289e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|11063799006|56012099006|261021123027099003|261021121427099003|22082099003|18002099003|6133799003|10067099003; X-Microsoft-Antispam-Message-Info: c3WXQMkXxXNnXXHQz2Bb+gLC+EzYOmHtym9Q7h7Zfg0EgcWhVKE4jgwnR3ESeLm8oYRWgd2BT2XC7oHizwMtWlB2lu3Tc3GG4eepyYlzETEbsfGiq3QGVWl1ALwcfzrivpdosEWAq0hx5KICDTYv5YT19n90zG8eR1PYD+nDQ9LapcuFrtOjx/wxFVRNZSfTlxtXGtwvKfxBqntGu11Azxbz59VuoUh2jxT70bs9ar+tnxeWqj/9YWcz0ZJUJk/SbpvzN3Z7RUx1emHR2kcbPQVIB63eiccR6+qkUNnI0lwsELa0gfp8O/fQQXu8jNoOPUo0i1lnzSgOSzn9xOyvw7Z1VniCQ9R5bZDHg3WwAeeNh58lChE7uousADmBR6VvEVlnKYU9HNPmNrrERO/dbVssJpWZz9QeKCaIyoqdYTI6JJloCCxST3E3PyTu4UnGOfPSViccjp6SYBlbqWGeKJnHsVuincabGPYJElphV3AVSGB3OsIzToBvnpef/mtMd5Xm2XsIXCdrrQbBg92MXrEhF2S3pqwsDK9OyB8NbPGr9etifFIJzoZBesQoJvd6Sg5yhpz1zkQTAr1nlKOZ/UNyjQQlbTHDSKFhieX9or9LsFqE2NBZCXKQ4FICniz84ASowUp8LkyHDa1kTR/91J5k+YYRTRR4DBXywN2yXk0= 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)(23010399003)(366016)(1800799024)(376014)(11063799006)(56012099006)(261021123027099003)(261021121427099003)(22082099003)(18002099003)(6133799003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?4aThXRUYOB5pUEKZt9DpY++xLBoED9mXNMedksBDl75kSZDtuvf6f4z4yKpE?= =?us-ascii?Q?NjBgwjwHT3qSp5sNP1oFsGYvm/Jz21iaeaRgVF4W1B68RG5fHvjKNtEbNIbv?= =?us-ascii?Q?hoxQopGb9Qm7w9Ob7lSgTZDdh1vUzj36p5uTe3tTTCwg18KDhkyNlBFxRFDG?= =?us-ascii?Q?nB3UYNuocC6QWKWWtmpDxUEiTI3UoGPNCBkZ91P8Jd30IH2ALQYG8wLA/3Xv?= =?us-ascii?Q?AmSAw/TmXKNh1J2xmrFhKWcYYhzbq31vrUDCBhRSAG7kXDlN8F/whaylTVOk?= =?us-ascii?Q?SROxH7EDxH+IB4PpMkp5idu+s43l81GOvgleI6POjXega/5OkZe82bYiSBis?= =?us-ascii?Q?WzXkfnIRO5np/HiXohomPuNu7ca4EZHKzs27ctBlqqSEq24jb1pm1X8wm1t6?= =?us-ascii?Q?dgtaZT2DxH4xVhyBTfkJSFYN07siWWAezGTm+ogHqgseFUV2mELAUbVodLFL?= =?us-ascii?Q?EOQbvLOpLWX4OMwjft2EeVDjn1S+NqYFJbZ5Ho4nuwmC91CHZANWjr4mj17I?= =?us-ascii?Q?9nSxKGmSDxrsIEn4lcpmrftOxDn7lNlgQ3HFiPL4fVRQY2rpsRl90MrKDbzm?= =?us-ascii?Q?ndr5NsK8m3FtKdujcUdoKyYrQrwwynw2R+cvdzjTlL7hfxi3947BKr5XjZry?= =?us-ascii?Q?ii9UZN5AW6pCddKPEdSjbG0MgnfvJvh7HXqe2BObU34l46h0XihWP3dM0n+8?= =?us-ascii?Q?2Nk+DnZps4vWgk/aywOXWON5JtZN36mVXkFZHLYeFDNcuJ3D4cvZQflTv9lY?= =?us-ascii?Q?8um2qJ0Xiq2rUzeIiO8kpZaq+PN/ekyedIfjB5fMkmWLwqPE9/V149rWfXS0?= =?us-ascii?Q?vQkbw1HyZ+p9JZyjt40wiQHwm/B4wpWJUa7pDjGA0tBThzXXrapY09xo9pUu?= =?us-ascii?Q?MERy/MXPNrZBkVidHv+vUR3g2xhgldK9LGfR2ph/gB4u4rOnK1sjyqknU0L+?= =?us-ascii?Q?nMZ6AL59AyeZ/BjT0KOdCL7rwzUc3wcjSE86bfgS+l8BdvNGfNz1FOuWRhWQ?= =?us-ascii?Q?AGrghMm4yQJUxkseqPX+MKBUJVZj+pQHrIU6EmBS3mxlllNwnz8QxB/Riq6F?= =?us-ascii?Q?dC3vVZ7NPeAqx9R4z1OM/yKu2mvXR1V2InRgYhT8CNI2XLe8JdFWLBI9AaSQ?= =?us-ascii?Q?XhJiNAYL5Z9jjJRFBT0leBZZBqhdD3AVLT5iDljte1Nw4oPOJRojkY1TbnFn?= =?us-ascii?Q?XF9LknDhb0fM4bX5tAHwREv1k2gKVCkpU1jCW36CxJdRgkJAizIdozYuctUw?= =?us-ascii?Q?3/DJ3bQKXv6JFY/330FEAT+1odYTLyxn0+LWelAmmx8MyeEI46A83XJehiPY?= =?us-ascii?Q?uvywHhmdxhtnuiR+tlixs++ZQwQ4tgTZMbDsy6ZFYGAKexgy8IVYpwd6kipt?= =?us-ascii?Q?9czrLg5097wIZZTqVTp/kOD/0BfbajaBwq5WaNz9D3Hb2l5UaBTghZQxAqYv?= =?us-ascii?Q?kIor+MZhaH5X9X0sW1ar/wsVrUglCUAKbrEsvxzjI1GtKfeJ6VZic3oU8Hxb?= =?us-ascii?Q?HuCXJjKGpHiVdRqYLj1tKDc429UMuiFi64o251eHQLEgsvJVQPhqC5UXlzER?= =?us-ascii?Q?Y4h4Ft2s48YRufgSOOsLoZZCK87HqThOyvtvGlnvTsuHcftiUVRNhLravM5z?= =?us-ascii?Q?q+FOZQrzzPiU1TSv136VSRDGgkrvjRCjjeP3x1+HMp5R+mfXb9sCOXKCV4CD?= =?us-ascii?Q?SlCnbADkgEw/NG1FBMcDXoHLWJ3v/xIvNafJt3V/jwcz75Pdz7tfevVbKqmr?= =?us-ascii?Q?V0eNOp1ooQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 025b9ab8-5c0a-4ba0-4ff1-08df346e289e X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:24.3739 (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: SPN+u+0kwvZ7Qa2nWCmNAJwuxY/rBCnfwp4WHI66VgX3SWBfQBl5oZxkxlgoJUedIuqdp6bugiQ2HVqQ3bbX8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-bad1c0/1793135186-3A2C4034-69D3D118/0/0 X-purgate-type: clean X-purgate-size: 1017 init_tee_secondary() was marked __init and freed after boot. Calling it from the CPU hotplug/resume path then executed discarded code, which could crash Xen. Drop __init so the TEE mediator secondary init can run safely on hotplugged and resumed CPUs. Signed-off-by: Mykola Kvach Reviewed-by: Luca Fancellu Reviewed-by: Bertrand Marquis Reviewed-by: Volodymyr Babchuk --- xen/arch/arm/tee/tee.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c index 8501443c8e..00e561fc78 100644 --- a/xen/arch/arm/tee/tee.c +++ b/xen/arch/arm/tee/tee.c @@ -128,7 +128,7 @@ static int __init tee_init(void) presmp_initcall(tee_init); -void __init init_tee_secondary(void) +void init_tee_secondary(void) { if ( cur_mediator && cur_mediator->ops->init_secondary ) cur_mediator->ops->init_secondary(); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462578.1673596 (Exim 4.92) (envelope-from ) id 1xLoNJ-0006IN-8Y; Tue, 27 Oct 2026 21:06:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462578.1673596; Tue, 27 Oct 2026 21:06: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 1xLoNJ-0006Hb-31; Tue, 27 Oct 2026 21:06:29 +0000 Received: by outflank-mailman (input) for mailman id 1462578; Tue, 27 Oct 2026 21:06:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNH-0005sf-OA for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNH-007tzZ-4G for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:27 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1124e-2eae-0a2a0a5409dd-0a2a4508e5fe-4 for ; Tue, 27 Oct 2026 22:06:27 +0100 Received: from [52.101.70.143] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11252-f659-0a2a45080019-3465468f96f5-3 for ; Tue, 27 Oct 2026 22:06:27 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by GV1PR03MB10428.eurprd03.prod.outlook.com (2603:10a6:150:168::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 21:06:22 +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.0546.021; Tue, 27 Oct 2026 21:06: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=sFlOCO0DEv4D533UiHOU5MV+qW/J6bzMLAK7SokbA6Z/f7Ccv15fiQHo1yX/i7wYVWr5be/88Nuy5GCrgkOgQckVjs3LgQel2nd0STK4mcteqvmNRjflNDmkIMfaTevGBqPmEpIa43rexmjVNnbRtL+vWBVrd9InnBgdQYUo0hfyMNyAq9fIfb4A++/3wmh5vGtdH5uaG4iu7mw6iW8aJ6x/mYKYcXGIt4u+NccwkPs3Z1C9wcaeLx2ZiwgB+nZ4uSDzoCRrLORyIT45hTu3GaVNf70PyX56IbTIBn3FLS8UTIXp9oQvkZ1cV21wwcROjKiRVmrRhqW7KEGznaXWUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZdpgfDex7pJyiNeN08FNRagArxgc9rcXre8jLdw1tLg=; b=OiI8HTxfYEr9QKRAwIr8a1aWUbUV+MmqVskAaYyR88iNqAVb+hW0qaaB7ortUaupBezErhyW9i1AWr9EqFCI/UhKI9lGs6/WytH8MpfufZBUJsJZMODhIf6Qj0Tkmc9TEqYyWWX7RxOVopAjE9qMedqE8vWiPibJ57vx1dLCBkBCaKOWzBdApk0VxxlPWfZOXR9kpBpIyUYnuM/Hipwii61G9mtRkgM+ICM/bx2fjWRgs2WxWNogTQBb13JcEHHgWuJeWB6vamaXR4fCKxqEl5Ed/gz2hcA8HuyCwyVd1J1bniY26fmXviVy6UxA3pF0Ksr6DXDGCU9m9Z+iWzdsWg== 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=ZdpgfDex7pJyiNeN08FNRagArxgc9rcXre8jLdw1tLg=; b=PXLM0fktfvCLwW6Ufb5eiSE5KS5VV5tnYxRAGP3s/dFfBlwxQw7VVXI5JmgFBKyAIKXbsEKbNJyHJ26qbfVGRUFlWccNDNMJ+jwE+EKNI+QHyRZtrgADBRoSyZUJp97z/VMh1aTY93/w7KzIC8uPHa+NTtsH43Vf5A5lwAOyrXdGr6+bdDBW+lwt5P478f3YKecxiRzwSHHxqBICtDy1ttH0QQtZthgvU2XF0vC7KiC591xK8Mtg/oxXp4V9I+P2acDMmFvlnguOSZQHXUdM6vvA3xYSopsSfJS+O6ovovDjBoXauS97rgtWHL5LuubfU26l5/J2RMNRus+KY4XdIQ== 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 v13 05/14] xen/arm: gic-v3: Implement GICv3 suspend/resume functions Date: Tue, 27 Oct 2026 23:05:54 +0200 Message-ID: <25db7c4451729a8c6e35b5e8f7a473c42eeac7a9.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|GV1PR03MB10428:EE_ X-MS-Office365-Filtering-Correlation-Id: 2f3f1c6b-2459-47c7-930c-08df346e26f4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|22082099003|18002099003|261026121527099003|3023799007|5023799004|11063799006|10067099003|261021121427099003|261021135927099003|261009223027099003|261022075727099003|261022105027099003|56012099006|261021123027099003|261026140227099003; X-Microsoft-Antispam-Message-Info: YJJ3Q7OfqoXsfm7+weJrnrLhgpcnWBUu31ZjyQsnWY8bpoE3aw4BAZKVpcpHVZDVv2txCeRnC6Ak0okHe0FftVCUErnMAGJ3/OKbGI0l6gN7OMruXd/XQi7fG3OUwjT3AoUp+o8nbobVpvn1HgGe9a1J/+ReQLuHvJFegNXLDLXprbaL5Eh082toWJTsRovTFHCBQRmeSLOwpGEObkDAzL+O0XY8E9JYMsbOlj3kJ0ZtF2ks25r2W+EL6F23dEzUz8JSH/ba0wZhkUIXtuAISm+GEZTAj4GHnbeEib1nkRT/DVzhgl7IVBWEetpf/bPZMsE+Tt2Ulqh2DDC5fwlYjhEHtzctFTO49KPifU54w30Ra3431vEFoVXOg6raCKPbiSD5Vuro/vJ6SRH6BbxP+6yjq4CoMTiMDHT9ZgJe5tsL2VmLvxi7j/j2B13FnJO6HOnMgbkd393CCc2j+7k/bjWEqocASSRvK5fSoHcD3dncsEFJcvcvc1NsuiuGEzQ7JAs+VbC9mJIQzCHQFgYYsYhpIlA8/Zs7ZwY45IxjQIKZnGH3DEtq4hXPnBBD0avNzbzNtSR8Y9goXjZ+yu9kZDFPBQvX1oIzB9X4AOe9eltjRullcUmp5v3S3Y1E438U2fhH3rCy59wRYGrH0t33NIWcdFUyVnsVm25Wy7NO8JI= 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)(376014)(23010399003)(1800799024)(366016)(6133799003)(22082099003)(18002099003)(261026121527099003)(3023799007)(5023799004)(11063799006)(10067099003)(261021121427099003)(261021135927099003)(261009223027099003)(261022075727099003)(261022105027099003)(56012099006)(261021123027099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5LeaDi9A8sZQRDJTRjtDhLGL1lgAv6Y/Xj9/ZJ0wKMgLuMQ5+wKlfCjjCAdC?= =?us-ascii?Q?j8k1uLz/Ws+i0B9YfZfjVlQn6ei3Zeh2Ono3eiNyReviuT3Qe59PWvEm81US?= =?us-ascii?Q?VRFxGqrsQvxYOaZZp8vLhDjo3gCKkg/uuL9cJ2fEWt8z0jGQlMwQvuR1Ry2V?= =?us-ascii?Q?BjTUgBKh36w3ctRm7JBOIA10QVruvIaJt7V2RBCqO3Mv9FajxdcF4hBwHWj9?= =?us-ascii?Q?8Cr+NmSqqQzdzpj7GCrii/7qQ3oGtmON3WO2ofFx401qZDekWkn3wMAw3Y/C?= =?us-ascii?Q?ibcnY7N0muEBqMAiFMxyeOUzDVedJzu0j8U96bZ2Wm2Yx3PBE5lBQCiMbK+h?= =?us-ascii?Q?L7DMq3op/Lv6RwCW2LZG6pCj0bh0OphQMJUhKFtES74L9cHiymay9XMZW47+?= =?us-ascii?Q?71TffJkhzo7IfRKjUqfcExEfIS9tQxy6nEVrsYZy37/vnkgyzTEHHjf/UCNQ?= =?us-ascii?Q?6MWPNkLJusuGXsSrvORazv+sN/705loH8SNC2+cnRfAAyn8alBzxnCRV07aq?= =?us-ascii?Q?DukbubM3vKsrkt7xrsgCmhP/a846NW5fsByzdUeJApZ87TxZvzgRBQvV/wQN?= =?us-ascii?Q?QSCOjFaCaQhU9e/rqTj8eXXvivIO7QNRXcygPAD/yygbNmZP7D0LC6nzcsBJ?= =?us-ascii?Q?nbFq8u22eIH/NrJYjb1eQ7xMkf9McLxYDc1f2uLhYsz24iFb8iUrb93KSthV?= =?us-ascii?Q?ptddT1zP5xdZJ0znQ5O2JmNAaD1auo6GWnb+Hw66cwsXOCOGyyXIO7AEZPvM?= =?us-ascii?Q?/5vakOgzwNajx1ZgDzI8kBZ26KvyI62CLvU8Dh1zi7KS2w6RAjj9xiLEmK4/?= =?us-ascii?Q?ITkB9E4HuViNIbd2nUCqCPeky2YnMzWdjtkmzW1KclWPoCeicoNJ7qD4tmS9?= =?us-ascii?Q?6ekOHGbZYyOyEtyYyop8xo+EUfPmh9cbCr8t6r4BzQac9o8873j6qRM5PVqC?= =?us-ascii?Q?27XlFYh2Ez1ZNZzq55hbKtmqhk4YssaCiULYqNKI1BnCIymYguTw1JWVigIx?= =?us-ascii?Q?Hrzw7gYj+Y72i9XIvCYeZ+R4X4Z/8nIp15QmJDpypzE0VyBzpX4ZtMc16Szz?= =?us-ascii?Q?ju7DvyP/+33i8/2jiwP9IuHWnmq03rgedTCLcsQvBi/8K7ZufwnLgkYQ7WF6?= =?us-ascii?Q?cDLwiGOe7iDU7JaOz39mt1mQ8xfGMq9xts/JzaEJMlmVFH/z/Lt/MfT5oNCw?= =?us-ascii?Q?LLS4xtZjGgCDInWNHH6g3GSqgOkQhvWJumNBGKRRTv6Lt+8GBK4ENueAmHCO?= =?us-ascii?Q?PMRikP8o+p/P6BuVNi1XyzEFaiQTK32xaV46fdkLWZ80OurCiK8SkVvbT2m3?= =?us-ascii?Q?uS0Na/H9F6bGUJRpibBybEfanAY1pwvPrTC2FUh84IYGh9CKwULhDAn0rebD?= =?us-ascii?Q?/noCDwCw/0PTvpWeKV6H8L7UcFhyh7jqMD/RpGq5Zg8YHVpv1SPY9X+S1zXC?= =?us-ascii?Q?K1IOtuYol8s85YixixQymb1dQqtogEzuUkyri1JO2BVfxW+P06WChg+nYSmS?= =?us-ascii?Q?TcEjoM+F9pHwktJmDgrxcrinWQAVspfUVo9pK0olW6NMhMQpOEJ0lZQ8Fpxk?= =?us-ascii?Q?sUUdZoZmpNQ7QHAJUGlEPARMnw6aM0QaJlULtLoHzSPcAEkoSVmLNv9ELSVc?= =?us-ascii?Q?9tRUpWn9xw2xPjreOHk7h/c41vKyf9cVlwSJe9xia2zAduPo8h84RPhc57H7?= =?us-ascii?Q?SH7MeoN1348GEVR+sWicYB60baIqbfv97Yxg4okJdC0jjbB5wnZYK/fC12Vb?= =?us-ascii?Q?Hfr3N6UwtQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f3f1c6b-2459-47c7-930c-08df346e26f4 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:21.5863 (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: vE2fpkzQeOmCEu79me0685WMy6c3QC6RlBUBDpaLldf1y9Iu1JKVX3/7fiBhmqbs1Qilfuwwil+kGgBps2jHSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10428 X-purgate-ID: tlsNG-c1860d/1793135187-CF95A87B-64F3F3FC/0/0 X-purgate-type: clean X-purgate-size: 22789 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. Have gicv3_suspend() panic if the Redistributor does not set GICR_WAKER.ChildrenAsleep before the timeout. Clearing ProcessorSleep while ChildrenAsleep is still zero is UNPREDICTABLE, so Xen cannot safely undo this transition and restore the CPU interface. Keep error reporting in gicv3_disable_redist(), including the CPU. Check active priorities before disabling the CPU and virtual interfaces, while local IRQs are masked. Return directly on failure, without changing the interfaces or requesting Redistributor sleep. Signed-off-by: Mykola Kvach --- Changes in V13: - Use uint32_t for the CTLR argument of the active-priority check (MISRA Rule 10.3). No functional change. - Cast saved CPU register values to uint32_t to avoid implicit narrowing (MISRA Rule 10.3). No functional change. - Rename the SPI/eSPI helper parameters from is_espi to espi so they do not hide the is_espi() helper declared in asm/irq.h. Use the same name for the GET_SPI_REG_OFFSET() macro parameter (MISRA Rule 5.3). No functional change. - Rename nr_irqs to nr_block_irqs in all SPI block helpers and in gicv3_suspend()/gicv3_resume() to avoid hiding the global nr_irqs (MISRA Rule 5.3). No functional change. - Panic in gicv3_suspend() if the Redistributor sleep request times out. - Log the CPU at error level on a sleep timeout. - Check active priorities before disabling the interfaces and return directly on failure. This is safe because local IRQs are already masked: Xen's IRQ handler cannot acknowledge new interrupts, and pending interrupts alone do not change active priorities. - Capitalize the comments noted in review. - Use fallthrough instead of comments in the active-priority check. 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 path; - avoid saving/restoring reserved GICD_IPRIORITYR and GICD_IROUTER entries 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. 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 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 | 456 ++++++++++++++++++++++- xen/arch/arm/include/asm/arm64/sysregs.h | 5 + xen/arch/arm/include/asm/gic_v3_defs.h | 3 + 4 files changed, 464 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c index 1a893d3ab2..3dd07db007 100644 --- a/xen/arch/arm/gic-v3-lpi.c +++ b/xen/arch/arm/gic-v3-lpi.c @@ -519,6 +519,9 @@ static int cpu_callback(struct notifier_block *nfb, unsigned long action, switch ( action ) { case CPU_UP_PREPARE: + if ( system_state == SYS_STATE_resume ) + break; + rc = 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 7e4b485f11..a653c5d14b 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1128,12 +1128,12 @@ out: return res; } -static void gicv3_hyp_disable(void) +static void gicv3_hyp_enable(bool enable) { register_t hcr; hcr = READ_SYSREG(ICH_HCR_EL2); - hcr &= ~GICH_HCR_EN; + hcr = enable ? (hcr | GICH_HCR_EN) : (hcr & ~GICH_HCR_EN); WRITE_SYSREG(hcr, ICH_HCR_EL2); isb(); } @@ -1240,7 +1240,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); } @@ -1979,6 +1979,448 @@ 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 */ + 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 */ + 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 = DIV_ROUND_UP(gicv3_info.nr_lines, 32); + + /* The spec allows for systems without any SPIs */ + if ( blocks > 1 ) + { + gicv3_ctx.dist.irqs = xzalloc_array(struct dist_irq_block, blocks - 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 = gic_number_espis() / 32; + gicv3_ctx.dist.espi_irqs = xzalloc_array(struct dist_irq_block, blocks); + 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 = 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 == 0 and an access is Non-secure accesses to this + * register are RAZ/WI. + */ + if ( !(readl_relaxed(GICD + GICD_CTLR) & GICD_CTLR_DS) ) + return 0; + + deadline = NOW() + MILLISECS(1000); + + writel_relaxed(readl_relaxed(waker) | GICR_WAKER_ProcessorSleep, waker); + while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) == 0 ) + { + if ( NOW() > deadline ) + { + printk(XENLOG_ERR "GICv3: CPU%u: Redistributor sleep timeout\n", + smp_processor_id()); + return -ETIMEDOUT; + } + + cpu_relax(); + udelay(10); + } + + return 0; +} + +#define GET_SPI_REG_OFFSET(name, espi) \ + ((espi) ? GICD_##name##nE : GICD_##name) + +static void gicv3_store_spi_irq_block(struct dist_irq_block *irqs, + unsigned int i, unsigned int nr_block_irqs, + bool espi) +{ + void __iomem *base; + unsigned int irq, nr_priority_regs; + + ASSERT(nr_block_irqs && nr_block_irqs <= 32); + nr_priority_regs = DIV_ROUND_UP(nr_block_irqs, 4); + + base = GICD + GET_SPI_REG_OFFSET(ICFGR, espi) + i * sizeof(irqs->icfgr); + irqs->icfgr[0] = readl_relaxed(base); + irqs->icfgr[1] = readl_relaxed(base + 4); + + base = GICD + GET_SPI_REG_OFFSET(IPRIORITYR, espi); + base += i * sizeof(irqs->ipriorityr); + for ( irq = 0; irq < nr_priority_regs; irq++ ) + irqs->ipriorityr[irq] = readl_relaxed(base + 4 * irq); + + base = GICD + GET_SPI_REG_OFFSET(IROUTER, espi); + base += i * sizeof(irqs->irouter); + for ( irq = 0; irq < nr_block_irqs; irq++ ) + irqs->irouter[irq] = readq_relaxed_non_atomic(base + 8 * irq); + + base = GICD + GET_SPI_REG_OFFSET(ISACTIVER, espi); + base += i * sizeof(irqs->isactiver); + irqs->isactiver = readl_relaxed(base); + + base = GICD + GET_SPI_REG_OFFSET(ISENABLER, espi); + base += i * sizeof(irqs->isenabler); + irqs->isenabler = readl_relaxed(base); +} + +static void gicv3_restore_spi_irq_config(struct dist_irq_block *irqs, + unsigned int i, + unsigned int nr_block_irqs, bool espi) +{ + void __iomem *base; + unsigned int irq, nr_priority_regs; + + ASSERT(nr_block_irqs && nr_block_irqs <= 32); + nr_priority_regs = DIV_ROUND_UP(nr_block_irqs, 4); + + base = GICD + GET_SPI_REG_OFFSET(ICFGR, espi) + i * sizeof(irqs->icfgr); + writel_relaxed(irqs->icfgr[0], base); + writel_relaxed(irqs->icfgr[1], base + 4); + + base = GICD + GET_SPI_REG_OFFSET(IPRIORITYR, espi); + base += i * sizeof(irqs->ipriorityr); + for ( irq = 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_block_irqs, bool espi) +{ + void __iomem *base; + unsigned int irq; + + ASSERT(nr_block_irqs && nr_block_irqs <= 32); + + base = GICD + GET_SPI_REG_OFFSET(IROUTER, espi); + base += i * sizeof(irqs->irouter); + for ( irq = 0; irq < nr_block_irqs; irq++ ) + writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq); +} + +static void gicv3_disable_spi_irq_block(unsigned int i, bool espi) +{ + void __iomem *base; + + base = GICD + GET_SPI_REG_OFFSET(ICENABLER, 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 espi) +{ + void __iomem *base; + + base = GICD + GET_SPI_REG_OFFSET(ISENABLER, espi); + base += i * sizeof(irqs->isenabler); + writel_relaxed(irqs->isenabler, base); + + base = GICD + GET_SPI_REG_OFFSET(ICACTIVER, espi) + i * 4; + writel_relaxed(GENMASK(31, 0), base); + + base = GICD + GET_SPI_REG_OFFSET(ISACTIVER, espi); + base += 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=%#" + PRIregister"\n", n, apr); + + return -EBUSY; +} + +static int gicv3_check_active_priorities(uint32_t ctlr) +{ + unsigned int pribits = 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 relevant + * here. Use ICC_CTLR_EL1.PRIbits for the physical CPU interface, not + * 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 = gicv3_check_ap1r(3, READ_SYSREG(ICC_AP1R3_EL1)); + if ( ret ) + return ret; + ret = gicv3_check_ap1r(2, READ_SYSREG(ICC_AP1R2_EL1)); + if ( ret ) + return ret; + fallthrough; + case 6: + ret = gicv3_check_ap1r(1, READ_SYSREG(ICC_AP1R1_EL1)); + if ( ret ) + return ret; + fallthrough; + default: + return gicv3_check_ap1r(0, READ_SYSREG(ICC_AP1R0_EL1)); + } +} + +static int gicv3_suspend(void) +{ + unsigned int i, nr_block_irqs; + void __iomem *base; + int ret; + struct redist_ctx *rdist = &gicv3_ctx.rdist; + + /* Save GICC configuration */ + gicv3_ctx.cpu.ctlr = (uint32_t)READ_SYSREG(ICC_CTLR_EL1); + gicv3_ctx.cpu.pmr = (uint32_t)READ_SYSREG(ICC_PMR_EL1); + gicv3_ctx.cpu.bpr = (uint32_t)READ_SYSREG(ICC_BPR1_EL1); + gicv3_ctx.cpu.sre_el2 = (uint32_t)READ_SYSREG(ICC_SRE_EL2); + gicv3_ctx.cpu.grpen = (uint32_t)READ_SYSREG(ICC_IGRPEN1_EL1); + + ret = gicv3_check_active_priorities(gicv3_ctx.cpu.ctlr); + if ( ret ) + return ret; + + gicv3_disable_interface(); + + ret = gicv3_disable_redist(); + if ( ret ) + { + /* + * Clearing ProcessorSleep before ChildrenAsleep is set is + * UNPREDICTABLE, so do not try to restore the CPU interface. + */ + panic("GICv3: Cannot safely abort suspend after a sleep timeout\n"); + } + + /* Save GICR configuration */ + gicv3_redist_wait_for_rwp(); + + base = GICD_RDIST_BASE; + + rdist->ctlr = readl_relaxed(base + GICR_CTLR); + + rdist->propbase = readq_relaxed(base + GICR_PROPBASER); + rdist->pendbase = readq_relaxed(base + GICR_PENDBASER); + + base = GICD_RDIST_SGI_BASE; + + /* Save priority on PPI and SGI interrupts */ + for ( i = 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) + rdist->ipriorityr[i] = readl_relaxed(base + GICR_IPRIORITYR0 + 4 * i); + + rdist->isactiver = readl_relaxed(base + GICR_ISACTIVER0); + rdist->isenabler = readl_relaxed(base + GICR_ISENABLER0); + rdist->igroupr = readl_relaxed(base + GICR_IGROUPR0); + rdist->icfgr = readl_relaxed(base + GICR_ICFGR1); + + /* Save GICD configuration */ + gicv3_dist_wait_for_rwp(); + gicv3_ctx.dist.ctlr = readl_relaxed(GICD + GICD_CTLR); + + for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) + { + nr_block_irqs = min(32U, gicv3_info.nr_lines - i * 32); + gicv3_store_spi_irq_block(gicv3_ctx.dist.irqs + i - 1, i, nr_block_irqs, + false); + } + +#ifdef CONFIG_GICV3_ESPI + for ( i = 0; i < gic_number_espis() / 32; i++ ) + gicv3_store_spi_irq_block(gicv3_ctx.dist.espi_irqs + i, i, 32, true); +#endif + + return 0; +} + +static void gicv3_resume(void) +{ + int ret; + unsigned int i, nr_block_irqs; + uint32_t dist_ctlr; + void __iomem *base; + struct redist_ctx *rdist = &gicv3_ctx.rdist; + + dist_ctlr = 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 = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) + gicv3_disable_spi_irq_block(i, false); + +#ifdef CONFIG_GICV3_ESPI + for ( i = 0; i < gic_number_espis() / 32; i++ ) + gicv3_disable_spi_irq_block(i, true); +#endif + + gicv3_dist_wait_for_rwp(); + + for ( i = NR_GIC_LOCAL_IRQS; i < gicv3_info.nr_lines; i += 32 ) + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4); + + for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) + { + nr_block_irqs = min(32U, gicv3_info.nr_lines - i * 32); + gicv3_restore_spi_irq_config(gicv3_ctx.dist.irqs + i - 1, i, nr_block_irqs, + false); + } + +#ifdef CONFIG_GICV3_ESPI + for ( i = 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 = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) + { + nr_block_irqs = min(32U, gicv3_info.nr_lines - i * 32); + gicv3_restore_spi_irq_routing(gicv3_ctx.dist.irqs + i - 1, i, + nr_block_irqs, false); + } + +#ifdef CONFIG_GICV3_ESPI + for ( i = 0; i < gic_number_espis() / 32; i++ ) + gicv3_restore_spi_irq_routing(gicv3_ctx.dist.espi_irqs + i, i, + 32, true); +#endif + } + + for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) + gicv3_restore_spi_irq_state(gicv3_ctx.dist.irqs + i - 1, i, false); + +#ifdef CONFIG_GICV3_ESPI + for ( i = 0; i < gic_number_espis() / 32; i++ ) + gicv3_restore_spi_irq_state(gicv3_ctx.dist.espi_irqs + i, i, true); +#endif + + writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR); + gicv3_dist_wait_for_rwp(); + + ret = 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 reprogramming. + * Return -EBUSY so callers can ignore this case. + */ + if ( ret && ret != -ENODEV && ret != -EBUSY ) + panic("GICv3: Failed to re-initialize LPIs during resume\n"); + else if ( ret == -EBUSY ) /* Extra checks, just to be sure */ + { + base = GICD_RDIST_BASE; + if ( readq_relaxed(base + GICR_PROPBASER) != rdist->propbase || + readq_relaxed(base + GICR_PENDBASER) != 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 = GICD_RDIST_SGI_BASE; + + writel_relaxed(GENMASK(31, 0), base + GICR_ICENABLER0); + gicv3_redist_wait_for_rwp(); + + for ( i = 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) { @@ -2053,6 +2495,10 @@ static int __init gicv3_init(void) gicv3_hyp_init(); +#ifdef CONFIG_SYSTEM_SUSPEND + gicv3_alloc_context(); +#endif + out: spin_unlock(&gicv3.lock); @@ -2092,6 +2538,10 @@ static const struct gic_hw_operations gicv3_ops = { #endif .iomem_deny_access = gicv3_iomem_deny_access, .do_LPI = gicv3_do_LPI, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = gicv3_suspend, + .resume = gicv3_resume, +#endif }; static int __init gicv3_dt_preinit(struct dt_device_node *node, const void *data) diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index f6ece8f972..ae2476426c 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 +#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/include/asm/gic_v3_defs.h index 2081b2fe8f..1cf3758386 100644 --- a/xen/arch/arm/include/asm/gic_v3_defs.h +++ b/xen/arch/arm/include/asm/gic_v3_defs.h @@ -92,12 +92,15 @@ #define GICD_TYPE_LPIS (1U << 17) #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) #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) #define GICR_WAKER_ProcessorSleep (1U << 1) #define GICR_WAKER_ChildrenAsleep (1U << 2) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462579.1673605 (Exim 4.92) (envelope-from ) id 1xLoNK-0006a4-N9; Tue, 27 Oct 2026 21:06:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462579.1673605; Tue, 27 Oct 2026 21:06: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 1xLoNK-0006ZD-GX; Tue, 27 Oct 2026 21:06:30 +0000 Received: by outflank-mailman (input) for mailman id 1462579; Tue, 27 Oct 2026 21:06:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNI-0005xw-89 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNH-005OFk-KL for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:27 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11235-bab6-0a2a0a5309dd-0a2a4509d276-28 for ; Tue, 27 Oct 2026 22:06:27 +0100 Received: from [40.107.130.136] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11253-be1a-0a2a45090019-286b82882d1a-3 for ; Tue, 27 Oct 2026 22:06:27 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:25 +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.0546.021; Tue, 27 Oct 2026 21:06: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=SthwZoA+WXgTF4EabfrpjryhAm3eLNwGsjO0FPTKDKOCflwBauPFeqOou2MVwLb6t1e9m/yjhDh21RX6C+K1vMjj4nCu46TdPICyADzFBtZxufNWTq9MmiCC2r1rTY1De/m2hoVETKvGn0W+2C/FrJVdaJU3JLQ5lJsPQqg6/AYCvbsLz/jQIPVjuAj9i8LzxPQmkIy2nCawMvX2sOtCugwsiVfGbr2+uP4pW9zopNRDSVRGSkvRRm5JTLWWZRaf7SHQ0FCKJhOafPTldKPM33ZfkBgrSi5c1Q/NIgUjLxnhN032m4SJzvlGv/AO/yTirXLtOiOZDC+6qwI0HurFuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0Et0H87hEBuDsVwPppgKnBp8dGaGZd5gonKbZ69I+lA=; b=kN8/6OXNmxpoxFnTI9ATTL9QA4He+oUT9eAP9HMP2nKwF2eWqHhX4Wi3jGcJbg6gH8ho/EHKF/Ey4keKsPieoQ2hSgI8gsasxm3cXP0puv/Cg/iAnR9Bemikd6HPNh15xkdXEKXYF5tMZyJYRRaHXAz2qYYv6PnBUTSFftcJfmmJEljCy5x46Kf/9Tan/COiVSF0o36KzjbjnlmTwxjiPCed30L06opxmtxFKqw93+pyz6V3i/HS8sf4cguLreQaop6iBE1P/LCOhSVIzLTNH6vt6imS2ZBmk9XhD0sKUf7JOjRHQM8veP+/OZwfnQKOpA0mm8lXzKZot4DU+qU1XA== 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=0Et0H87hEBuDsVwPppgKnBp8dGaGZd5gonKbZ69I+lA=; b=DZacm/pMILoh0PCsWna9v5Y8+FtaTvh/ExSGye8aoJ/W6iWTpru89pHwiunEfMDcG2cyKGGstfCEkrOl640r2Dy1EP1hdoufi5oFFDhPmpb3RW6plGoSHz7OWTOttlUBVtUMcYk2FJe4pgnIj4El9+6j8N0Jl7KY5E7tiJbu5bQ1RMgXJUPPUBnk/R6Eg0fKtQOVC1LuWwkI/c4niqqFjWAxsgg6m5N4dhUv2lXeWIfOKei8ocydahI17NyKZwt2TECraTE4N3zkmtqBlyMJRm4KecQ/V10bfxWOYxwhiNVV0mLatp4rBqh6ZRzIxX+blaoc/ugwmYL5QXfYThTcgA== 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: Volodymyr Babchuk , Bertrand Marquis , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel , Luca Fancellu Subject: [PATCH v13 08/14] xen/arm: ffa: fix notification SRI across CPU hotplug/suspend Date: Tue, 27 Oct 2026 23:05:57 +0200 Message-ID: <4ed322025f241009d8c099369e6be39fce35a669.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: 16faceb4-1dea-4624-87b9-08df346e296f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|261026121527099003|11063799006|56012099006|261009223027099003|261021123027099003|261021121427099003|261022105027099003|22082099003|18002099003|10067099003|261026140227099003; X-Microsoft-Antispam-Message-Info: rtMKOT2z5hr9yfT+zQfaWF4f237dA5cn8MNAHLW4L7S/2ZIXQIGtaX7ngNzMkVIq66GCNyg9yM1o1aKQlXgS8FIo9bUqqLHjaoA/xh5A0Crvg4RO5+v2d8xqPVPnqtfr8eaSOxRCSS1zNyAYIU2K7JYqlPFEeZgXdqZrP/1IbSyT8SZMpNubKGKhe1GXI6CKa6uoTTv29ecgXCXx0D0FxxW/qrRudERqGuVbSQ75B026QjmICKGPh15YXuOOTs/j27XYiefPMPpWzW3HeFQiIl20xH2SJSCb6qIrc/6P8BmFNccbvAomfwS/98V++j/+gp3ca/Geo0A6iAd5I/sS0GpCoqcB+jBqnrYbW3O+rYC+4QRuJ9hIMze/eRJt9TPlpwyVk2dNi47MuKb5bqmAJ2Umu+E52lbcj8EQO+b1TUs9UwNmi0P5Q56CDB0zXa8vn2tX5ThvpOc7CsLdgfKuNyZGZNFI94xoNgFM2uAs++QD78/uoU6VRvG9Pgi9BjAHv+irArjr7CizPXKKreTOOXdsc+tDYBRrA3ce0wrxEW/tR8OCXOWld9aii0tXFCFL11MJnH16zuC5s5uEKCDYTbyKC4yNRRJFg1gRCT7uibCNHWrDumIbLVeyBFN+VM59nGs+fAzbGDhH/xd3MTDkyl+cVWsvGh0fwvAOX0fJ57Q= 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)(23010399003)(366016)(1800799024)(376014)(261026121527099003)(11063799006)(56012099006)(261009223027099003)(261021123027099003)(261021121427099003)(261022105027099003)(22082099003)(18002099003)(10067099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Ji4OEmZCcrfzyhH6Omo8ssnbQOdemisJE8wfdvjZxyGxlqitZWkVRz9lBnzd?= =?us-ascii?Q?gKtdvwOMb9+l3F+dIeedypNFRCN5Ip3lYwXvRyOw88WZwtVSDPZxX14NAZ2K?= =?us-ascii?Q?SywmQk72XcpizWop0Qi0mj/YkZE09EENKEG/3t1Z7HzG5VD5JAq7jhUx7NLZ?= =?us-ascii?Q?/kX7/YzHrHuOmgDL8MWoebFjkKl7b0N8DocJf1+PhRO/nocz3Z1DE4WUjucV?= =?us-ascii?Q?h260iGyv9qfiCXSibAZnoZc+x0qCmdkreJ4Ag6dNr1g1+YBfrAH/VZkOKukb?= =?us-ascii?Q?nDeWYmYKrCT9bTqYaaefsb3lGzVCptoSc8acLD+5tXTEPZ7usFXfjf2fqLwa?= =?us-ascii?Q?C28Yj/H2SoAHxyYluxENVCFZwd1RnxztV1cZAxQ1w0SB2TgK5wjCJpA9eyEE?= =?us-ascii?Q?595TVXhVxLR5w9fjmoet71JkN0vtu9RhZeJqNb+Aip7g/1bDw313u/VPe7aL?= =?us-ascii?Q?/Z1hBnXPal9/LwikACovvaSpiOGLHZVClP6kyM6N0DWm6t9VcEmMAUFFJpDo?= =?us-ascii?Q?4WaqzLI9Yt31MpXSL1UMg2mkrMPdp5Xvw6iFGS4k3BYgmmG4yXrobN5G81gb?= =?us-ascii?Q?s31mJrucKOv01+AwF0vvIQ9ybj68xAAWoKML+LRMXndGvF9Bui9nqfVI+FX4?= =?us-ascii?Q?hEtibtFhgd13oI967EVKxuFMo2NVmhemuI5ezSRROAAWT4BQx/rZ9XggC2He?= =?us-ascii?Q?m8+ZAu9eKR7bOTafJzuouUMGybhA/+9xHOsH84iueOn+XvlqIqbbJ0nmhaHx?= =?us-ascii?Q?ARIsVPmK3kqY2SvdQYZ57OzrjD+RzUp0kqqyWRbjFbLpJCSZRyEfYbz69RlX?= =?us-ascii?Q?/maVKubAz4tqT5ZE4y4koN0G0kPtNfmFZOaHFjckUBZjpTkPr0EehopKNv0N?= =?us-ascii?Q?kgNegyr4UpR/lRNIjthkkTMhnq9NvwVGOaVZvrZyqlogFOHez/Hc8jDpcqiE?= =?us-ascii?Q?7hc6+qnyk3CMdA+mESNo3qPzDFHBpfj/ob919Z8l4Vs02dfFrX2WmF+qFSRf?= =?us-ascii?Q?Wr5qM9tuvEYjwiEUmNZezP6RMLuy+4vkCszFf15kcVHKR+tlX9QgYUZnoRDg?= =?us-ascii?Q?dUybLR4k508d6peGHFeGX/eBGtLzjedxouIQQJv0G1d3g6CzKpMkQfqCB+UR?= =?us-ascii?Q?7r8fN3DvW7rlmfIJ9gO6qvf+SEeTlY8ub1n2PqV3SrwRW69DPjPwcRw1I4nM?= =?us-ascii?Q?vZYT/VyYiAdBhrc9/v288+mWdSxTgpiLa3tXCiktdCN7SLxxHz8wazTlGHUn?= =?us-ascii?Q?tQqmfMUPSeKP0bl6g//o03rGnFiQM2to4UjBNsW76bziIey7uouEyBjTVr89?= =?us-ascii?Q?4on4hbz3PwBF17YDdlH+vxzK5hlwzNYkz7kz1Re3XvIUvG1kjevkQwL+Wl2m?= =?us-ascii?Q?nxZKM5aW2hqiRAKIzdN3OyDxioImQe2s0Ubt4CtkrxgsuwHKHHV12CBvppaH?= =?us-ascii?Q?1222w6M59YCoF3eQqtBfAohiXcujZmZ1zfbD07DMovIE5R7J+Sf6wShC7CFU?= =?us-ascii?Q?om5rWxljfQkEuY4+9vHpewdm6aL19Y6j96UnmhazMvV3FQjX2Dn9/ATlfmuA?= =?us-ascii?Q?TtIlwg5Z1Jv+L0FQsnXNdC+tZJCXkw48HgEYihtY6x+qrXrl08ZF3/ZMNfm7?= =?us-ascii?Q?W/OzujnmZX2j4GPwsAcCER+KZ+sbKKP9Ccu86WIdg12vikPC8VLDkkMC+zfz?= =?us-ascii?Q?t8BJlalq+Ps/QlPeZSL579LMQkPz1yB1dQjtAfLiAk5m/hyFgS5Y+Lc04XMC?= =?us-ascii?Q?Sq6sx1Gl4w=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16faceb4-1dea-4624-87b9-08df346e296f X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:25.6972 (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: /4jJczvET56amPGzhu/26zUUgtYA251oCCcKVy5CiiqD+uoCLQ7HyeRc/fSqlnFOelQGBlyYZFh2MHz0yQIjnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-bad1c0/1793135187-BEEDE034-89904F3B/0/0 X-purgate-type: clean X-purgate-size: 3727 The FF-A notification SRI interrupt handler was not correctly tied to CPU hotplug and suspend/resume. As a result, CPUs going offline and back online could end up with stale or missing handlers, breaking delivery of FF-A notifications. Signed-off-by: Mykola Kvach Reviewed-by: Luca Fancellu Reviewed-by: Bertrand Marquis --- Changes in V13: - Use false for free_on_release (MISRA Rule 10.3). No functional change. - Explicitly discard request_sri_irq()'s result on secondary CPUs. The helper logs errors, preserving the existing behavior (MISRA Rule 17.7). No functional change. - Explain why the notifier ignores other CPU events (MISRA Rule 16.4). No functional change. --- xen/arch/arm/tee/ffa_notif.c | 63 +++++++++++++++++++++++++++++------- 1 file changed, 51 insertions(+), 12 deletions(-) diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index c64bc39f03..1ec455d2ad 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -360,10 +360,28 @@ static int32_t ffa_notification_bitmap_destroy(uint16_t vm_id) return ffa_simple_call(FFA_NOTIFICATION_BITMAP_DESTROY, vm_id, 0, 0, 0); } -void ffa_notif_init_interrupt(void) +static DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, sri_irq); + +static int request_sri_irq(void) { int ret; + struct irqaction *sri_action = &this_cpu(sri_irq); + + sri_action->name = "FF-A notif"; + sri_action->handler = notif_irq_handler; + sri_action->dev_id = NULL; + sri_action->free_on_release = false; + + ret = setup_irq(notif_sri_irq, 0, sri_action); + if ( ret ) + printk(XENLOG_ERR "ffa: setup_irq irq %u failed: error %d\n", + notif_sri_irq, ret); + + return ret; +} +void ffa_notif_init_interrupt(void) +{ if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI ) { /* @@ -376,14 +394,37 @@ void ffa_notif_init_interrupt(void) * pending, while the SPMC in the secure world will not notice that * the interrupt was lost. */ - ret = request_irq(notif_sri_irq, 0, notif_irq_handler, "FF-A notif", - NULL); - if ( ret ) - printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n", - notif_sri_irq, ret); + (void)request_sri_irq(); + } +} + +static void deinit_ffa_notif_interrupt(void) +{ + if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI ) + release_irq(notif_sri_irq, NULL); +} + +static int cpu_ffa_notif_callback(struct notifier_block *nfb, + unsigned long action, + void *hcpu) +{ + switch ( action ) + { + case CPU_DYING: + deinit_ffa_notif_interrupt(); + break; + default: + /* Ignore other CPU events. */ + break; } + + return NOTIFY_DONE; } +static struct notifier_block cpu_ffa_notif_nfb = { + .notifier_call = cpu_ffa_notif_callback, +}; + void ffa_notif_init(void) { const struct arm_smccc_1_2_regs arg = { @@ -416,13 +457,11 @@ void ffa_notif_init(void) return; } } - ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL); - if ( ret ) - { - printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n", - irq, ret); + + if ( request_sri_irq() ) return; - } + + register_cpu_notifier(&cpu_ffa_notif_nfb); fw_notif_enabled = true; } } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462580.1673613 (Exim 4.92) (envelope-from ) id 1xLoNL-0006oa-Rq; Tue, 27 Oct 2026 21:06:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462580.1673613; Tue, 27 Oct 2026 21:06: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 1xLoNL-0006ni-N8; Tue, 27 Oct 2026 21:06:31 +0000 Received: by outflank-mailman (input) for mailman id 1462580; Tue, 27 Oct 2026 21:06:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNJ-0006LO-MR for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNJ-005OFk-2l for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:29 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11224-bab6-0a2a0a5309dd-0a2a45048502-30 for ; Tue, 27 Oct 2026 22:06:29 +0100 Received: from [52.101.65.143] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11254-b57f-0a2a45040019-3465418fbeaa-3 for ; Tue, 27 Oct 2026 22:06:28 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:27 +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.0546.021; Tue, 27 Oct 2026 21:06: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=tWGfpj2G0xRSTcZuZfnxDb0mk5h502pScavdxQjIt8Tj2H2b8DFs4aX0qq1sSxylW0pl8KQoXUsUBP7xDqDGOxPdlGMkhFdI4YdcekAt2eAGJi8LuxAKGRrlWzS9BobE69xcAYyRDKGi9VIH8qPLVl2heUEMopUuG6eyPqs7EBwEPhIzh5cQkv2JcznAlmhUiwo+UH9qSjy4qWpVbBIrVghZK3hh8nq4YXi1mxwI2sWon8pCpIAubJLDcwJsXnyzvveRWhcJAqaqwBYLQbKf7RmFHhOTETFkox8l0CV24dL0HIn0hm41mOmNTiH2N5FwAMTpCKtY1d0Y1LlWr6kMHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=m/6MV74rIhh8XGalMTquS7ei+eHrk33o7L0PNoZVBG8=; b=VZ/ddsSwcG31eQHFsDXBFG9Wgf8DDyJync0NywYgjm17rgRBOPAv5yqj2mESgQ+vYnHHQcF8SQVv4ZsJFcGoPxZqsoB4qov+iONAkScr1fyjuchA88OF1Dk6zn47ejlZdLAC1FrZP9/FOw828M3NbFYVevqrkRwKndPfZ/U6w/UqfHC2fumQK2bqF6+iuOd9l2LO7VK3r9BWFRTXxKJ3m6FGmSfot6DPSf/IbZZaHOQxTCEa5InIgGu1KPD498j9ZiJSZXxnVKqGck/iJrU74XYwfGG+ZUqZxUsSJDRRG8iSD23LOgqcayYL3guw6Dap/LWwmcEskr6SjV691rRfIg== 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=m/6MV74rIhh8XGalMTquS7ei+eHrk33o7L0PNoZVBG8=; b=NTIdlWjRIvvbsNO+vw4TvKJtwY6vrf5ZKtDaN2NstYEzKZd7JM8DIttIB6EyLWgzsOuYKk+rPb6suYmmP2fmHO80o6YCpYgprV7SPr+gj+1IPNZ20E9jnaWREhClC95R7Gw0MqDxST3vzlJKKhhQx7tKjFZViUAj9A4X33rzJ6cwz3+ktv2PRq1AaSrRdULYE/BWu/KsI7QHqoCL53QqZpHJEoLeJBWZ4rmzdkvCxLjAnYCJqBUPDPsYN1b5o7VdOyHOubNNcPZXRs4p5dPm3s3gPvK31D+Gcd9OjL894dULY2eLhHsxTBIpFz669mTAuV8Qa3iBSX99/qU2K8h9KA== 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: Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Luca Fancellu Subject: [PATCH v13 09/14] iommu/ipmmu-vmsa: Implement suspend/resume callbacks Date: Tue, 27 Oct 2026 23:05:58 +0200 Message-ID: <3f8f4ecf30d38d589c2d08f5b2676bda93f8d880.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: 611fc1c6-8d38-4a15-b7fa-08df346e2a3b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|261026121527099003|261022075727099003|11063799006|5023799004|56012099006|261009223027099003|261021123027099003|261021121427099003|261022105027099003|22082099003|18002099003|6133799003|10067099003|261026140227099003; X-Microsoft-Antispam-Message-Info: JSFdbEdVmGYn3Jui5eGZM1FC9XKKs4n5TXUZLmnPaXu05MPBFKsn917nlzoRlNMJm0/SeCVqSKijv7DulaNiQaYX2zr7QyXRiBLakfZQIvZDhN4f9gPN373oB34BryVp2JlwQqpG4iFLccaZA3m08tb7wmnrDMREoH1xOMsYzokzx6B+801C8WL/Jm0jnCqk1oza31Ej5XxiDiDeBIALbDjLIjU7/1PrWoPfWpWTbUIiXuPQy+FNjmB5UTmEbhJPaEFSZWSok9+oK4+4NSiXqkgH/fBedr7NOraPIUtPUftHXM70JRU9my668vMX7uVHJKXI62eIkd4yIcbmEXc93j9Rnpkuol+dlTukpt9eVn3IWmLrQGjy9NYJehyXYCneSp9W3ayxNocqnx1VqyMp0Qe+a0Ac79er89T+LQDVXJ6zXYdRliVwXmJOSCLxhPKq8lmMGKVr3hdJ8MpcKHm3U7p7vbYPYYP7xwLMeT6hDL9kv7M42N8aYrheccwGWvRFeDXGjdN4UqzTPEAPptD0xmIhP4rwZ0ampMAZA81VAEEI3NZ1E0KXdp/2ovvEaNAAS0llbqgcvyKvlvVkr2TFJ0XeRm2urFq/KX60pMNGtHqPX5oBi37s3H/GroED2YYQfQQP5XSDFjBz0IH53OWseROJUc+/lu1Jw+nR5tKtm+s= 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)(23010399003)(366016)(1800799024)(376014)(261026121527099003)(261022075727099003)(11063799006)(5023799004)(56012099006)(261009223027099003)(261021123027099003)(261021121427099003)(261022105027099003)(22082099003)(18002099003)(6133799003)(10067099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?y445bxpIcvYMbqRO4cKjIwmbk/MTsZfXIEzsltLPS0IM52eELo2PVlZNF0ws?= =?us-ascii?Q?gbZD30jILfrUcmMGPldbtceR74MP7HGDiJv1AYAeyGOWFaJl/HY9sjF1pE3i?= =?us-ascii?Q?mV6EcytnNsLWFdX0Eebsbs9Cms2J3AjWKtE6fzVX0mVaBEnsaoYcTikizAih?= =?us-ascii?Q?ca7isjlhxas6qB4FyAi5/zrGXP2kU6GUsUa29aVVKGOUq806ScAAE4v4G5R0?= =?us-ascii?Q?1WXb2E07pyd8Apgx/LdjfbRrl9slKQms47rhKYkXjg+Qo3GL918/RWdrYM3r?= =?us-ascii?Q?rGuuapTMpsP3xhoXXj4NDD+8CujS7P/LXWJ/bw5FanwayaLTzbEcodkrHaXg?= =?us-ascii?Q?WTWK60NanmLOinaDCuP6DXfwc2TT8sXz8O89/Mqn2hkIMOTpjGaIkpg1GHrv?= =?us-ascii?Q?zDxYShuHAkj8V9dCz13MVn6bRMHqPFdeZEygQ3/MsoCtXl5kk/WRfGHwmJ/E?= =?us-ascii?Q?sLYqsIUjOmfx+nWoUJtBPaogTxVes5YglJHQoF7XSmu91TgIssoCftc8U6Lb?= =?us-ascii?Q?irPOettIgpSpJsCccEG8jibvWbm0oziBRKVzGxZ1YFNVkbfV+TzM4h8FrzYI?= =?us-ascii?Q?rAfQMQu0n/DawudbQ+yp/mNI6RjggCAQembHARky6YSe/MiFmCG8ygtLkAcO?= =?us-ascii?Q?I7c9sUIOTP5D+hrCW4mTRNXHIFPY/pWXpXWX1h5GGfpP+SM1efrL5JcLQyj9?= =?us-ascii?Q?ACsovsNJRvw72+vqT0XCS8FPoTCWUku39EpMRLvYdx0+zI4iOUdKxbmk8G9c?= =?us-ascii?Q?SulqdjRQkgKuiQ3zdjwPnCc2cQkLxN3TW7vfimhWKXTzTsr9JXruk+xeft0F?= =?us-ascii?Q?wdoRrhKq5+hj/DcsxAWE/VNxtiPQ0sQt6BChsa1NL7lAohdSQ8SpKvlL0/Va?= =?us-ascii?Q?ITOPcmFAv6zFp8gU1jxmjZXzyUJ4AWfbcCP4DXblxqrE8Oswo+l+hc+9DDaF?= =?us-ascii?Q?EENk6N32WStCaFiZbLt6DScgJ8SRbwUS5PwnqJ54T70x9ueXGcLqtGPVBrYp?= =?us-ascii?Q?/53rg1AbnZSQhAXlDEGEvlFz3lpQspJwJ6SPq50gNFA3YEOgSeaqH4ZVmtTS?= =?us-ascii?Q?uYaalriYhHlISkSP47SR9Lf9stovihAqy2s6vYJgnO+QO3z9WGeQ7qYcuOdZ?= =?us-ascii?Q?zH4YMecElUHChQFkpgShKMblxBDgvavEovUyEeUyJEH40emxzxZ0xJ/0PP5g?= =?us-ascii?Q?xl9oUOFiWmiD0BOqzQGKRckbHI1VgXXsj5S6Z+Z1+ZnNTCgrOWtzhiwb1Jas?= =?us-ascii?Q?8ziup62riG4xReGfjRMCoqW7bjTM5kbn1vlgxhT/TNV1F3NBu6nW8ClOQVFf?= =?us-ascii?Q?Q4Kbt8vpWqiy0bpUIRzqQlOPC/6VVja7HFcQKS8xyQ5+tOw8DJBglrl1UWxH?= =?us-ascii?Q?HvBvBJTOzy3sExzME16/BQo9TRLX+4Md7XWXW19OxNB1eZCHqxa0LzT069Qg?= =?us-ascii?Q?meL2CUgmImYsx6Jp57YlDsKehvgzWTlvfPhrS9URmXrdENyHk3DdKW0/HWjl?= =?us-ascii?Q?8Pcvk8Diz4MuJrGFM951NI7wEdSMw0vzwyhWZvHU+OyvSJACOm5WtN5I8BUE?= =?us-ascii?Q?qwbRXVQQHoxaPmdVRySIXOomRQl88XAnCFqSZJTsrIvSzHHNJqGcH8CjFbnW?= =?us-ascii?Q?SjvrN1Ls4wUVMf1qk0PUJaZc9V5Qpni7qTkVQM0SeYx7eUaD0VztvlUuOQGE?= =?us-ascii?Q?OULKQp1aQbDpPtjRhMmESEPtYaXC1djBOdSNL+bG6k8h9cQImSVO+As1q/pi?= =?us-ascii?Q?h7lqEUtJmQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 611fc1c6-8d38-4a15-b7fa-08df346e2a3b X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:27.0461 (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: eQlurBOLrRsCuxZBH7LH7xrQkw8knmRCZJ9e/DJr/pPbvlXTsLilmL8Psy/l6S1idWlxsVCZUJF2kcfnrhPgaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-ebf023/1793135189-526CAB50-0A84E958/0/0 X-purgate-type: clean X-purgate-size: 14548 From: Oleksandr Tyshchenko Store and restore active context and micro-TLB registers. On resume, restore Root IPMMU context state before restoring Cache IPMMU micro-TLB state. Cache IPMMUs select Root contexts through their micro-TLB configuration, so restoring Cache micro-TLBs before the Root context registers are restored can expose stale or uninitialized context state. Tested only on H3ULCB (R-Car Gen3). Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Mykola Kvach Reviewed-by: Luca Fancellu --- Changes in V13: - State that suspend/resume was tested only on H3ULCB (R-Car Gen3). Changes in V10: - Iterate over registered IPMMUs in reverse order during resume so Root IPMMU context state is restored before Cache IPMMU micro-TLB state. Changes in V9: - set dt_device_set_protected() only after ipmmu_alloc_ctx_suspend() succeeds, so DT devices do not remain protected on allocation failure. Changes in V7: - moved suspend context allocation before pci stuff --- xen/drivers/passthrough/arm/ipmmu-vmsa.c | 323 +++++++++++++++++++++-- 1 file changed, 308 insertions(+), 15 deletions(-) diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c index fa9ab9cb13..2e54fa63d6 100644 --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c @@ -71,6 +71,8 @@ }) #endif +#define dev_dbg(dev, fmt, ...) \ + dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__) #define dev_info(dev, fmt, ...) \ dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__) #define dev_warn(dev, fmt, ...) \ @@ -130,6 +132,24 @@ struct ipmmu_features { unsigned int imuctr_ttsel_mask; }; +#ifdef CONFIG_SYSTEM_SUSPEND + +struct ipmmu_reg_ctx { + unsigned int imttlbr0; + unsigned int imttubr0; + unsigned int imttbcr; + unsigned int imctr; +}; + +struct ipmmu_vmsa_backup { + struct device *dev; + unsigned int *utlbs_val; + unsigned int *asids_val; + struct list_head list; +}; + +#endif + /* Root/Cache IPMMU device's information */ struct ipmmu_vmsa_device { struct device *dev; @@ -142,6 +162,9 @@ struct ipmmu_vmsa_device { struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX]; unsigned int utlb_refcount[IPMMU_UTLB_MAX]; const struct ipmmu_features *features; +#ifdef CONFIG_SYSTEM_SUSPEND + struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX]; +#endif }; /* @@ -547,6 +570,249 @@ static void ipmmu_domain_free_context(struct ipmmu_vmsa_device *mmu, spin_unlock_irqrestore(&mmu->lock, flags); } +#ifdef CONFIG_SYSTEM_SUSPEND + +static DEFINE_SPINLOCK(ipmmu_devices_backup_lock); +static LIST_HEAD(ipmmu_devices_backup); + +static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX]; + +static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu, + unsigned int utlb) +{ + return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb))); +} + +static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu) +{ + struct ipmmu_vmsa_backup *backup_data; + + dev_dbg(mmu->dev, "Handle micro-TLBs backup\n"); + + spin_lock(&ipmmu_devices_backup_lock); + + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) + { + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); + unsigned int i; + + if ( to_ipmmu(backup_data->dev) != mmu ) + continue; + + for ( i = 0; i < fwspec->num_ids; i++ ) + { + unsigned int utlb = fwspec->ids[i]; + + backup_data->asids_val[i] = ipmmu_imuasid_read(mmu, utlb); + backup_data->utlbs_val[i] = ipmmu_imuctr_read(mmu, utlb); + } + } + + spin_unlock(&ipmmu_devices_backup_lock); +} + +static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu) +{ + struct ipmmu_vmsa_backup *backup_data; + + dev_dbg(mmu->dev, "Handle micro-TLBs restore\n"); + + spin_lock(&ipmmu_devices_backup_lock); + + list_for_each_entry( backup_data, &ipmmu_devices_backup, list ) + { + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev); + unsigned int i; + + if ( to_ipmmu(backup_data->dev) != mmu ) + continue; + + for ( i = 0; i < fwspec->num_ids; i++ ) + { + unsigned int utlb = fwspec->ids[i]; + + ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]); + ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i]); + } + } + + spin_unlock(&ipmmu_devices_backup_lock); +} + +static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *domain) +{ + struct ipmmu_vmsa_device *mmu = domain->mmu->root; + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; + + dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->context_id); + + regs->imttlbr0 = ipmmu_ctx_read_root(domain, IMTTLBR0); + regs->imttubr0 = ipmmu_ctx_read_root(domain, IMTTUBR0); + regs->imttbcr = ipmmu_ctx_read_root(domain, IMTTBCR); + regs->imctr = ipmmu_ctx_read_root(domain, IMCTR); +} + +static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *domain) +{ + struct ipmmu_vmsa_device *mmu = domain->mmu->root; + struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id]; + + dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->context_id); + + ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0); + ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0); + ipmmu_ctx_write_root(domain, IMTTBCR, regs->imttbcr); + ipmmu_ctx_write_all(domain, IMCTR, regs->imctr | IMCTR_FLUSH); +} + +/* + * Xen: Unlike Linux implementation, Xen uses a single driver instance + * for handling all IPMMUs. There is no framework for ipmmu_suspend/resume + * callbacks to be invoked for each IPMMU device. So, we need to iterate + * through all registered IPMMUs performing required actions. + * + * Also take care of restoring special settings, such as translation + * table format, etc. + */ +static int __must_check ipmmu_suspend(void) +{ + struct ipmmu_vmsa_device *mmu; + + if ( !iommu_enabled ) + return 0; + + printk(XENLOG_DEBUG "ipmmu: Suspending...\n"); + + spin_lock(&ipmmu_devices_lock); + + list_for_each_entry( mmu, &ipmmu_devices, list ) + { + if ( ipmmu_is_root(mmu) ) + { + unsigned int i; + + for ( i = 0; i < mmu->num_ctx; i++ ) + { + if ( !mmu->domains[i] ) + continue; + ipmmu_domain_backup_context(mmu->domains[i]); + } + } + else + ipmmu_utlbs_backup(mmu); + } + + spin_unlock(&ipmmu_devices_lock); + + return 0; +} + +static void ipmmu_resume(void) +{ + struct ipmmu_vmsa_device *mmu; + + if ( !iommu_enabled ) + return; + + printk(XENLOG_DEBUG "ipmmu: Resuming...\n"); + + spin_lock(&ipmmu_devices_lock); + + /* + * IPMMUs are registered with list_add(), with Root IPMMU probed first. + * Walk backwards to restore Root contexts before Cache micro-TLBs. + */ + list_for_each_entry_reverse( mmu, &ipmmu_devices, list ) + { + uint32_t reg; + + /* Do not use security group function */ + reg = IMSCTLR + mmu->features->control_offset_base; + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECGRP); + + if ( ipmmu_is_root(mmu) ) + { + unsigned int i; + + /* Use stage 2 translation table format */ + reg = IMSAUXCTLR + mmu->features->control_offset_base; + ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_S2PTE); + + for ( i = 0; i < mmu->num_ctx; i++ ) + { + if ( !mmu->domains[i] ) + continue; + ipmmu_domain_restore_context(mmu->domains[i]); + } + } + else + ipmmu_utlbs_restore(mmu); + } + + spin_unlock(&ipmmu_devices_lock); +} + +static int ipmmu_alloc_ctx_suspend(struct device *dev) +{ + struct ipmmu_vmsa_backup *backup_data; + unsigned int *utlbs_val, *asids_val; + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); + + utlbs_val = xzalloc_array(unsigned int, fwspec->num_ids); + if ( !utlbs_val ) + return -ENOMEM; + + asids_val = xzalloc_array(unsigned int, fwspec->num_ids); + if ( !asids_val ) + { + xfree(utlbs_val); + return -ENOMEM; + } + + backup_data = xzalloc(struct ipmmu_vmsa_backup); + if ( !backup_data ) + { + xfree(utlbs_val); + xfree(asids_val); + return -ENOMEM; + } + + backup_data->dev = dev; + backup_data->utlbs_val = utlbs_val; + backup_data->asids_val = asids_val; + + spin_lock(&ipmmu_devices_backup_lock); + list_add(&backup_data->list, &ipmmu_devices_backup); + spin_unlock(&ipmmu_devices_backup_lock); + + return 0; +} + +#ifdef CONFIG_HAS_PCI +static void ipmmu_free_ctx_suspend(struct device *dev) +{ + struct ipmmu_vmsa_backup *backup_data, *tmp; + + spin_lock(&ipmmu_devices_backup_lock); + + list_for_each_entry_safe( backup_data, tmp, &ipmmu_devices_backup, list ) + { + if ( backup_data->dev == dev ) + { + list_del(&backup_data->list); + xfree(backup_data->utlbs_val); + xfree(backup_data->asids_val); + xfree(backup_data); + break; + } + } + + spin_unlock(&ipmmu_devices_backup_lock); +} +#endif /* CONFIG_HAS_PCI */ + +#endif /* CONFIG_SYSTEM_SUSPEND */ + static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) { uint64_t ttbr; @@ -559,6 +825,9 @@ static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) return ret; domain->context_id = ret; +#ifdef CONFIG_SYSTEM_SUSPEND + domain->mmu->root->reg_backup[ret] = &root_pgtable[ret]; +#endif /* * TTBR0 @@ -615,6 +884,9 @@ static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain) ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH); ipmmu_tlb_sync(domain); +#ifdef CONFIG_SYSTEM_SUSPEND + domain->mmu->root->reg_backup[domain->context_id] = NULL; +#endif ipmmu_domain_free_context(domain->mmu->root, domain->context_id); } @@ -1338,10 +1610,11 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) struct iommu_fwspec *fwspec; #ifdef CONFIG_HAS_PCI + int ret; + if ( dev_is_pci(dev) ) { struct pci_dev *pdev = dev_to_pci(dev); - int ret; if ( devfn != pdev->devfn ) return 0; @@ -1358,17 +1631,24 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) if ( !to_ipmmu(dev) ) return -ENODEV; - if ( !dev_is_pci(dev) ) + if ( !dev_is_pci(dev) && dt_device_is_protected(dev_to_dt(dev)) ) { - if ( dt_device_is_protected(dev_to_dt(dev)) ) - { - dev_err(dev, "Already added to IPMMU\n"); - return -EEXIST; - } + dev_err(dev, "Already added to IPMMU\n"); + return -EEXIST; + } - /* Let Xen know that the master device is protected by an IOMMU. */ - dt_device_set_protected(dev_to_dt(dev)); +#ifdef CONFIG_SYSTEM_SUSPEND + if ( ipmmu_alloc_ctx_suspend(dev) ) + { + dev_err(dev, "Failed to allocate context for suspend\n"); + return -ENOMEM; } +#endif + + /* Let Xen know that the master device is protected by an IOMMU. */ + if ( !dev_is_pci(dev) ) + dt_device_set_protected(dev_to_dt(dev)); + #ifdef CONFIG_HAS_PCI if ( dev_is_pci(dev) ) { @@ -1377,26 +1657,28 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) struct pci_host_bridge *bridge; struct iommu_fwspec *fwspec_bridge; unsigned int utlb_osid0 = 0; - int ret; bridge = pci_find_host_bridge(pdev->seg, pdev->bus); if ( !bridge ) { dev_err(dev, "Failed to find host bridge\n"); - return -ENODEV; + ret = -ENODEV; + goto free_suspend_ctx; } fwspec_bridge = dev_iommu_fwspec_get(dt_to_dev(bridge->dt_node)); if ( fwspec_bridge->num_ids < 1 ) { dev_err(dev, "Failed to find host bridge uTLB\n"); - return -ENXIO; + ret = -ENXIO; + goto free_suspend_ctx; } if ( fwspec->num_ids < 1 ) { dev_err(dev, "Failed to find uTLB"); - return -ENXIO; + ret = -ENXIO; + goto free_suspend_ctx; } rcar4_pcie_osid_regs_init(bridge); @@ -1405,7 +1687,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) if ( ret < 0 ) { dev_err(dev, "No unused OSID regs\n"); - return ret; + goto free_suspend_ctx; } reg_id = ret; @@ -1420,7 +1702,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) { rcar4_pcie_osid_bdf_clear(bridge, reg_id); rcar4_pcie_osid_reg_free(bridge, reg_id); - return ret; + goto free_suspend_ctx; } } #endif @@ -1429,6 +1711,13 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) dev_name(fwspec->iommu_dev), fwspec->num_ids); return 0; +#ifdef CONFIG_HAS_PCI + free_suspend_ctx: +#ifdef CONFIG_SYSTEM_SUSPEND + ipmmu_free_ctx_suspend(dev); +#endif + return ret; +#endif } static int ipmmu_iommu_domain_init(struct domain *d) @@ -1490,6 +1779,10 @@ static const struct iommu_ops ipmmu_iommu_ops = .unmap_page = arm_iommu_unmap_page, .dt_xlate = ipmmu_dt_xlate, .add_device = ipmmu_add_device, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = ipmmu_suspend, + .resume = ipmmu_resume, +#endif }; static __init int ipmmu_init(struct dt_device_node *node, const void *data) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462581.1673619 (Exim 4.92) (envelope-from ) id 1xLoNM-0006xD-Hz; Tue, 27 Oct 2026 21:06:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462581.1673619; Tue, 27 Oct 2026 21: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 1xLoNM-0006vC-9r; Tue, 27 Oct 2026 21:06:32 +0000 Received: by outflank-mailman (input) for mailman id 1462581; Tue, 27 Oct 2026 21:06:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNK-0006ZE-MT for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNK-0005yu-36 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:30 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11225-e002-0a2a0a5209dd-0a2a4505a020-28 for ; Tue, 27 Oct 2026 22:06:30 +0100 Received: from [40.107.130.81] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11255-4cb1-0a2a45050019-286b8251fecc-3 for ; Tue, 27 Oct 2026 22:06:29 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:28 +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.0546.021; Tue, 27 Oct 2026 21:06: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=ART4KfMsLaOtRXPTE2jSBNnYlSja7LjHA/bfuaVSX4m9hyszDlLJxTUCn3raU53sgwezHEcncxHk9urmAspR4Jmm6bSVJxJ4VmTG6f3qLQayZ08YdDRPfyiYAB0eKf+9g1AFD7IM882YX6g8wxqg4vtlUgeDMU2Hduhimp5vUCfC2oq6x/Ew6BcBeS7Vc7VyyLiJXAAPY3Rl6CjftU3kzzSY5Z611QaYLDpj+3EB39moidiKwSw/gTNvHXKUu0WHgBGkmkR1kNyYLc2W3UyEfJNeeHOWOriOUQ7eYNbDQrwH73FUInogliqWBXUmM/AgDCAoZNXTgvg1KZ1My5sbMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yNFRi8E/OouwXg5Rg4YSbngcg1S9nFeb9I2j8RLHvag=; b=cvitjFRcTu7BYYPHXSr/ibYAzjhrSmWQosUWW3bXytoz101Gq+C4MioHDwisUHwvVj2/BLux2YJ6UkWGvZecGuicQN93h5D+zv8+7N/hO127PAPma9FWiQa7vo/MHadQZhDoHGZoE852deJCqscT8gy0kbR99UO9Sd2D1affvizANdgj7WFf65Y8+0eYf51Fs4gwIrpbwWa1ew9hYY7POASMeHvHFbRAkXBZ1bDk990izRq+/bkYEy5lYUhXTp/ZChftDpNvLfqiDUHiwH5wpPODvytfFQm/kOi6S2xHv5eZJCiR+IToljVF+IdxLNsS1gSLbJNG3kDMFTODQNbV0Q== 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=yNFRi8E/OouwXg5Rg4YSbngcg1S9nFeb9I2j8RLHvag=; b=JWO7ktr08nfKW6h5a+3N4jxsI94R89hCLd8xNgj9VX/27MzoCIe3YWRO+4duZGuKhmTd98FNIfT0ZP1xgfTGtZgRFnT7vTOyZC8DtiKEMls4XUxIsU8ESUM07bJZLdhdrk94VFfc7C20fcyr8GDd628+XawNfqymMRh+7SdMfKB1klfIfXhNT1G9QeuUsrwvJBz+mVZf49Xmef3TYwZfLEqibkIu9enMdbRWz0bHlmyh6ys9tO0eWRAxW31+2gUaA/e1+y8+ygue2/uBoLSoRjCCHiZl8aV2Ys+cCeRIHoJjTLSleaNPIy7LSKefviwBVBlwMy3XwvJqkE7GETVQhQ== 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: Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Pranjal Shrivastava Subject: [PATCH v13 10/14] xen/arm: smmu-v3: add suspend/resume handlers Date: Tue, 27 Oct 2026 23:05:59 +0200 Message-ID: <6b6566eae874fcc3a92a0730f0d0e5b84f7745a1.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: 582a36bc-8042-4e5f-f8d6-08df346e2b00 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|261026121527099003|261022075727099003|11063799006|56012099006|261009223027099003|261021135927099003|261021123027099003|261021121427099003|261022105027099003|22082099003|18002099003|6133799003|10067099003|3023799007|261026140227099003; X-Microsoft-Antispam-Message-Info: pyopd39vxYoufvudCpOvhQD+mumDzh/3d7NV9oPbmJNA7HaSzSUMIlmHTz4lPCA2s9tJT1sFhapY0VSuUx4bIcdeLkzq5YJ7H3BKXcisdfF7e6nZj7kEXYGNn3jQXkfc8ZWL8/6wMxrwsFLykVtGyqgjVHkfYSl0Ck85FV0jVLf7cUXONXvUigknfz1k4Wc+buDLppF3J5r0NdhRn4Fb0lozpKZMH3vN1pUDY8Emnmz3jeSfL1XCC6+eIezWwLwgK08TzHzVtXIgSxz7Ob1PHxL+vctOIiX7Lig1U54sCcNAqDUcSesqBA8KFTNsfa1woZyyWWJQziCEgvIumFkI+upx/CXdqQJ5+C358o/rlStrxLoNmHEUWVg74O/4JPBMpIHBgSaqYx9u/rAfOzfh1TvjoXlnTeXRxmWBvdnOe/gyimk6vyvqqa/Mz/umq0PG7dflUgXGbzV7KPELaSlQGGBQiKHi3biY9lxR4Z18jJ8NFnw6S9JANAAJkOOIX2GI2TgSH9eWj6OEWI6saDB7Qiyl5mtiNQU59eNhXu/D0jlKRSUm8q5/8dVHAPV0OXegbZjruGHrVsC+hl8J2hVyo1IP6xCukqhEs79g0zqLaFQw+p/3gJSUqbTIfGRR59Na 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)(23010399003)(366016)(1800799024)(376014)(261026121527099003)(261022075727099003)(11063799006)(56012099006)(261009223027099003)(261021135927099003)(261021123027099003)(261021121427099003)(261022105027099003)(22082099003)(18002099003)(6133799003)(10067099003)(3023799007)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?YIOFf2SyBdOe1jyDJHv2uo8uBrA8JVvNZaKUla2gU1LHaFml6oj9p/83Ee+F?= =?us-ascii?Q?qAM9Cx3FfontizfkwGwQ4lm117opWxsRMiASbR7jgELO3Hb2qdUW3xWP5Erv?= =?us-ascii?Q?q89pORs0zyyFmPOfJpuYR8Ymdoin23Ut114FmYiYTZQxGNWfKv9vpEXDkDZS?= =?us-ascii?Q?WdWtIWQhsEMB6UBJ+ZKiv+Bw+piw4uSbiVZXSZ9e1wtrBIa5+OCuHZjTEQpu?= =?us-ascii?Q?EJKOVzeP3/dcRVPD5Ly44IHJ0fSJYVv/MdRoP11vCOUwK8n5Wk4CjF61t+X4?= =?us-ascii?Q?Ri/EPAhI5LlTNvyjlSsNblLxdvcDnkDCHwoFfRjcIBGDbo8UrF7Mfy4kfc8G?= =?us-ascii?Q?4FCXnwEpKHcDvWtwVcglDwkyuvMGehswTNDoSJ4IPuZmePeWmPvCW5LpYgHd?= =?us-ascii?Q?oi1bJzM2zSeFws/6Ol4lpldr6R/wgDAph0uMoc7AolcaLkOjDj58p2HLWGZC?= =?us-ascii?Q?8VES0N2WY/fvtwmmK+oUSv05YCucTHBytMEaBglWx40opGeR/4o/GFgM1sps?= =?us-ascii?Q?lq/dQl14WJLi+eFOxYfKB3pvCd10JKKDKNWU3qmBKQeXUbwwJVI5OW6Kz1nm?= =?us-ascii?Q?1lgc4yO3nC2TyG6RpKGowN66rONhP4tK/9niuFyC4R6DUsIVOoPQXZY6dli8?= =?us-ascii?Q?2KPwZjMA85JmTVw6fv3OVPuEiscjSGNpIBDSJbhiF7lDKiqS0Hm4f7QN2BMt?= =?us-ascii?Q?1wSreXBRY/ENbXyHFQPvrGsdXd0zWQYjecZnI4kSaESP0urCKtic0KZIZAw1?= =?us-ascii?Q?bIicH/In6QFpP3aQ1IaaSNGZavLwmd/y4xrJp8Gmo2whgdjEOh1EYIiD/dQI?= =?us-ascii?Q?HApiqEW9BJHayVD8Fd32CAm5c+DPwcF7HIYjhoxx6aMLNvZKUIl3k6Fv9Q8G?= =?us-ascii?Q?xfSHbERpbTNvWh0xgmNCsle4lAILHMyZ37d3MVmWnCAevUcxyBjT4Xq+SVKb?= =?us-ascii?Q?xQJ0fR+pYQrbDaye2In31FqNSN5y0hPENInsJseF3xp8j2RkYO3CjPyzQZ0b?= =?us-ascii?Q?gkAjlQzbuy0a1e16zOxSB5ij3TBxcuYSYJf4HgqYbBvOnjvk9V6NZXV13rgr?= =?us-ascii?Q?Q+QxT4axIYi6RKvNaXHjF51965B220FemKxyw8N7q5gleYcKqEwUHTeq+Z7w?= =?us-ascii?Q?1soTK6ZZ3yo6IGDNI+oZn2I/SoXyUH4CDH4nzKXG08eA8hudbHTdHxjwvmA4?= =?us-ascii?Q?X3X2HLdIQ/i9w2A5PzE8+T/ofsqjbcCEXcuaUmJjsFjpFBBTTwsOkqF9Tfzm?= =?us-ascii?Q?mvNTuYExMpsNTNd8SV0f6Q7S4gIVLd31VN+Cmu2P7GLxHWt6+1FtBNHswVJH?= =?us-ascii?Q?/nG5tG2vAGGM9oiCfxD/sAKF+HrFElGcPG5Ud5ijSTmdKrkZSPGK8i2Mj1Ws?= =?us-ascii?Q?vXPgtVqUjRamcRdDLjxeOxGblC8tEtE2dz6lUhvdLemxDe4zKP9dfKXOrBDQ?= =?us-ascii?Q?JF70XNpwAItq3nlwnGjaecJ/y5iMlfIj3CZ/wGGCgxgl9IYMzE5mOm7ThfJ/?= =?us-ascii?Q?JV31rhwAyRxrXKRZqi4woo1+v83njCn4okEySY7Z8lq2q3saVx4T1P7UMtQ/?= =?us-ascii?Q?2eYuigwqD30Mzjb9m+8/nOsKnEYi3IxcY0HP12fYXroqBu3CuTJTfhHG5bzK?= =?us-ascii?Q?/+5dV56Tt/1iF4yOppOs8dEhdEf+DtpyXG1HHW/9ks/X9lm2beFHvqsKFBcr?= =?us-ascii?Q?uYK/meVIS9KiNuKk9iArCdT4gDZbX29AqDjmCCPzPxsi11A9SY8wcn4oIcWP?= =?us-ascii?Q?KFBNDZb6mQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 582a36bc-8042-4e5f-f8d6-08df346e2b00 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:28.3607 (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: UPl/53uRyjKo+Ys32yKHwWtNo4XfEztfKvswRyAnXs/bk3EMhEsgSJ1tyfRatLlyRUhPYjEHtrkLw5yEjCVMWQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-c201ff/1793135190-724B42A1-E903F8A9/0/0 X-purgate-type: clean X-purgate-size: 20792 Add system suspend/resume callbacks for the Arm SMMUv3 driver. During suspend, set GBPA.ABORT and disable the translation interface and EVTQ/PRIQ, while keeping CMDQ enabled. Save the queue producer indices after the disable acknowledgements, then issue CMD_SYNC to wait for all earlier commands to complete. Disable interrupt generation before stopping CMDQ, and handle any remaining global errors before the SMMU loses power. If the initial GBPA update fails, leave that SMMU enabled and restore only the previously suspended devices. For later failures, restore the current SMMU as well. Before each rollback reset, wait for EVTQ/PRIQ to stop and save their producer indices. This also covers a CR0ACK timeout before the normal suspend path has saved the indices. Failure to stop the queues or to reset during rollback is fatal, since the host suspend error path allows domains to run again. Check GBPA and CMD_SYNC errors in reset so an incomplete restore is not reported as successful. Resume uses arm_smmu_device_reset() to restore the SMMU registers and queue indices, invalidate cached configuration and translations, and enable the SMMU. Schedule tasklets for unread queue entries: enabling interrupts does not report events that were recorded before the interrupt source was enabled. Prevent pending GERROR interrupts from accessing CMDQ while it is reset. Probe also changes with CONFIG_SYSTEM_SUSPEND disabled. Request IRQ handlers only after the queues and tasklets are ready. If reset fails during probe, call arm_smmu_device_disable() before freeing resources, since queues may already be enabled. Panic if disabling fails: the SMMU may still access the queue memory. The GERROR guard is also compiled in, but is cleared before handlers are registered and stays clear after probe. Reset now returns GBPA and CMD_SYNC errors in these builds too. Clear MSI target addresses on both probe and resume, also without CONFIG_MSI. Arm IHI0070G.b, sections 6.3.21 and 6.3.30, specify that these addresses reset to UNKNOWN and that zero disables MSIs while allowing wired IRQs. The corresponding IRQ_CTRL and IRQ_CTRLACK enable bits must both be clear before writing these registers. Disable interrupt generation and wait for IRQ_CTRLACK, as described in section 6.3.16, before clearing the addresses. Xen currently does not support SMMUv3 MSI interrupts or PCI ATS/PRI. Active MSI configuration restore and ATS/PRI endpoint suspend handling remain outside this patch. Link: https://lore.kernel.org/r/20260929034510.2023173-1-praan@google.com/ Based-on-patch-by: Pranjal Shrivastava Assisted-by: Codex:GPT-6 Signed-off-by: Mykola Kvach --- Changes in V13: - Rename __init_or_smmu_suspend to init_or_smmu_suspend to avoid a reserved macro name (MISRA Rule 21.1). No functional change. - Check arm_smmu_device_disable() after a probe reset failure (MISRA Rule 17.7). Panic if disabling fails, before freeing queue memory. - Adapt the relevant fixes from v11 of the Linux SMMUv3 suspend series. - Request IRQs after the queues and tasklets are ready, only during probe. - Disable the SMMU on probe-time reset failure before freeing resources. - Check GBPA and CMD_SYNC errors in reset, and make a failed rollback reset fatal before the host suspend error path can resume domain execution. - Leave the current SMMU enabled if the initial GBPA update fails; restore only the previously suspended devices. - Clear MSI target addresses on probe and resume, also when using wired IRQs, and document the register requirements from IHI0070G.b. - Save EVTQ/PRIQ producer indices after confirming that the queues have stopped, both during suspend and before rollback reset. Cover a CR0ACK timeout before the normal snapshot. Schedule tasklets after reset to process unread entries without waiting for a new interrupt. - Keep GERROR handling available until interrupt generation is disabled, then gate its IRQ handler before stopping CMDQ. Handle remaining global errors before power-off and allow the handler again once CMDQ is restored. - Drop Luca's Reviewed-by tag because the patch has changed. Changes in V11: - Keep arm_smmu_update_gbpa() and arm_smmu_device_reset() in init text when CONFIG_SYSTEM_SUSPEND is disabled. Changes in V10: - Disable SMMU interrupt generation during suspend before disabling the SMMU interface, matching the resume/reset path which re-enables IRQ_CTRL. Changes in V9: - Use CMD_SYNC in suspend instead of polling CMDQ_CONS, so the suspend path waits for command completion rather than only command consumption. - Document that arm_smmu_setup_irqs() is probe-only and that future Xen SMMUv3 MSI support will need to restore SMMU IRQ_CFGn registers on resume. - Restore the reference to Pranjal's Linux runtime/system sleep series and clarify that MSI/ATS/PRI resume handling is outside the supported Xen path. - Prefix the subject with xen/arm for consistency with the rest of the Arm suspend/resume series. Changes in V8: - Honor ARM_SMMU_FEAT_SEV when draining the CMDQ during suspend, matching the existing runtime CMD_SYNC path. - Fold the suspend rollback reset path into a helper and rename the error reporting to describe suspend rollback rather than resume. - Treat SMMU reset failure during resume as fatal instead of logging and continuing with a potentially unusable IOMMU. - cosmetic changes --- xen/drivers/passthrough/arm/smmu-v3.c | 308 +++++++++++++++++++++----- xen/drivers/passthrough/arm/smmu-v3.h | 1 + 2 files changed, 258 insertions(+), 51 deletions(-) diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c index bf153227db..58530ef2d1 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.c +++ b/xen/drivers/passthrough/arm/smmu-v3.c @@ -94,6 +94,12 @@ #include "smmu-v3.h" +#ifdef CONFIG_SYSTEM_SUSPEND +#define init_or_smmu_suspend +#else +#define init_or_smmu_suspend __init +#endif + #define ARM_SMMU_VTCR_SH_IS 3 #define ARM_SMMU_VTCR_RGN_WBWA 1 #define ARM_SMMU_VTCR_TG0_4K 0 @@ -903,10 +909,10 @@ static void arm_smmu_priq_tasklet(void *dev) static int arm_smmu_device_disable(struct arm_smmu_device *smmu); -static void arm_smmu_gerror_handler(int irq, void *dev) +/* The caller must serialize with the IRQ handler. */ +static void arm_smmu_handle_gerror(struct arm_smmu_device *smmu) { u32 gerror, gerrorn, active; - struct arm_smmu_device *smmu = dev; gerror = readl_relaxed(smmu->base + ARM_SMMU_GERROR); gerrorn = readl_relaxed(smmu->base + ARM_SMMU_GERRORN); @@ -948,6 +954,14 @@ static void arm_smmu_gerror_handler(int irq, void *dev) writel(gerror, smmu->base + ARM_SMMU_GERRORN); } +static void arm_smmu_gerror_handler(int irq, void *dev) +{ + struct arm_smmu_device *smmu = dev; + + if (!read_atomic(&smmu->gerror_blocked)) + arm_smmu_handle_gerror(smmu); +} + static void arm_smmu_combined_irq_handler(int irq, void *dev) { struct arm_smmu_device *smmu = dev; @@ -1814,8 +1828,8 @@ static int arm_smmu_write_reg_sync(struct arm_smmu_device *smmu, u32 val, } /* GBPA is "special" */ -static int __init arm_smmu_update_gbpa(struct arm_smmu_device *smmu, - u32 set, u32 clr) +static int init_or_smmu_suspend +arm_smmu_update_gbpa(struct arm_smmu_device *smmu, u32 set, u32 clr) { int ret; u32 reg, __iomem *gbpa = smmu->base + ARM_SMMU_GBPA; @@ -1836,6 +1850,20 @@ static int __init arm_smmu_update_gbpa(struct arm_smmu_device *smmu, return ret; } +static void arm_smmu_clear_msi_cfg(struct arm_smmu_device *smmu) +{ + /* + * IHI0070G.b, sections 6.3.21 and 6.3.30: ADDR resets to UNKNOWN. + * ADDR == 0 disables MSIs while allowing wired IRQs. The corresponding + * IRQ_CTRL and IRQ_CTRLACK enable bits must be clear before writing. + */ + writeq_relaxed(0, smmu->base + ARM_SMMU_GERROR_IRQ_CFG0); + writeq_relaxed(0, smmu->base + ARM_SMMU_EVTQ_IRQ_CFG0); + + if (smmu->features & ARM_SMMU_FEAT_PRI) + writeq_relaxed(0, smmu->base + ARM_SMMU_PRIQ_IRQ_CFG0); +} + #ifdef CONFIG_MSI static void arm_smmu_free_msis(void *data) { @@ -1864,13 +1892,7 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu) int ret, nvec = ARM_SMMU_MAX_MSIS; struct device *dev = smmu->dev; - /* Clear the MSI address regs */ - writeq_relaxed(0, smmu->base + ARM_SMMU_GERROR_IRQ_CFG0); - writeq_relaxed(0, smmu->base + ARM_SMMU_EVTQ_IRQ_CFG0); - - if (smmu->features & ARM_SMMU_FEAT_PRI) - writeq_relaxed(0, smmu->base + ARM_SMMU_PRIQ_IRQ_CFG0); - else + if (!(smmu->features & ARM_SMMU_FEAT_PRI)) nvec--; if (!(smmu->features & ARM_SMMU_FEAT_MSI)) @@ -1911,7 +1933,8 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu) static inline void arm_smmu_setup_msis(struct arm_smmu_device *smmu) { } #endif /* CONFIG_MSI */ -static void __init arm_smmu_free_irqs(struct arm_smmu_device *smmu) +static void init_or_smmu_suspend +arm_smmu_free_irqs(struct arm_smmu_device *smmu) { int irq; @@ -1995,19 +2018,38 @@ err_free_evtq_irq: return ret; } -static int __init arm_smmu_setup_irqs(struct arm_smmu_device *smmu) +static int arm_smmu_enable_irqs(struct arm_smmu_device *smmu) { - int ret, irq; + int ret; u32 irqen_flags = IRQ_CTRL_EVTQ_IRQEN | IRQ_CTRL_GERROR_IRQEN; - /* Disable IRQs first */ - ret = arm_smmu_write_reg_sync(smmu, 0, ARM_SMMU_IRQ_CTRL, - ARM_SMMU_IRQ_CTRLACK); - if (ret) { - dev_err(smmu->dev, "failed to disable irqs\n"); + if ( smmu->features & ARM_SMMU_FEAT_PRI ) + irqen_flags |= IRQ_CTRL_PRIQ_IRQEN; + + /* Enable interrupt generation on the SMMU */ + ret = arm_smmu_write_reg_sync(smmu, irqen_flags, + ARM_SMMU_IRQ_CTRL, ARM_SMMU_IRQ_CTRLACK); + if ( ret ) + { + dev_warn(smmu->dev, "failed to enable irqs\n"); return ret; } + return 0; +} + +static int arm_smmu_disable_irqs(struct arm_smmu_device *smmu) +{ + return arm_smmu_write_reg_sync(smmu, 0, ARM_SMMU_IRQ_CTRL, + ARM_SMMU_IRQ_CTRLACK); +} + +/* Probe-time only; reset has configured the queues and disabled IRQs. */ +static int init_or_smmu_suspend +arm_smmu_setup_irqs(struct arm_smmu_device *smmu) +{ + int ret, irq; + irq = smmu->combined_irq; if (irq) { /* @@ -2028,22 +2070,7 @@ static int __init arm_smmu_setup_irqs(struct arm_smmu_device *smmu) } } - if (smmu->features & ARM_SMMU_FEAT_PRI) - irqen_flags |= IRQ_CTRL_PRIQ_IRQEN; - - /* Enable interrupt generation on the SMMU */ - ret = arm_smmu_write_reg_sync(smmu, irqen_flags, - ARM_SMMU_IRQ_CTRL, ARM_SMMU_IRQ_CTRLACK); - if (ret) { - dev_warn(smmu->dev, "failed to enable irqs\n"); - goto err_free_irqs; - } - return 0; - -err_free_irqs: - arm_smmu_free_irqs(smmu); - return ret; } static int arm_smmu_device_disable(struct arm_smmu_device *smmu) @@ -2057,18 +2084,31 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu) return ret; } -static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) +static int init_or_smmu_suspend +arm_smmu_device_reset(struct arm_smmu_device *smmu, bool resume) { int ret; u32 reg, enables; struct arm_smmu_cmdq_ent cmd; + ret = arm_smmu_disable_irqs(smmu); + if (ret) { + dev_err(smmu->dev, "failed to disable irqs\n"); + return ret; + } + + /* A pending GERROR IRQ must not access CMDQ while it is reset. */ + write_atomic(&smmu->gerror_blocked, true); + arm_smmu_clear_msi_cfg(smmu); + /* Clear CR0 and sync (disables SMMU and queue processing) */ reg = readl_relaxed(smmu->base + ARM_SMMU_CR0); if (reg & CR0_SMMUEN) { dev_warn(smmu->dev, "SMMU currently enabled! Resetting...\n"); WARN_ON(!disable_bypass); - arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0); + ret = arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0); + if (ret) + return ret; } ret = arm_smmu_device_disable(smmu); @@ -2107,10 +2147,15 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) return ret; } + /* GERROR handling can use CMDQ again once its registers are restored. */ + write_atomic(&smmu->gerror_blocked, false); + /* Invalidate any cached configuration */ cmd.opcode = CMDQ_OP_CFGI_ALL; arm_smmu_cmdq_issue_cmd(smmu, &cmd); - arm_smmu_cmdq_issue_sync(smmu); + ret = arm_smmu_cmdq_issue_sync(smmu); + if (ret) + return ret; /* Invalidate any stale TLB entries */ if (smmu->features & ARM_SMMU_FEAT_HYP) { @@ -2120,7 +2165,9 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) cmd.opcode = CMDQ_OP_TLBI_NSNH_ALL; arm_smmu_cmdq_issue_cmd(smmu, &cmd); - arm_smmu_cmdq_issue_sync(smmu); + ret = arm_smmu_cmdq_issue_sync(smmu); + if (ret) + return ret; /* Event queue */ writeq_relaxed(smmu->evtq.q.q_base, smmu->base + ARM_SMMU_EVTQ_BASE); @@ -2163,17 +2210,18 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) } } - ret = arm_smmu_setup_irqs(smmu); - if (ret) { - dev_err(smmu->dev, "failed to setup irqs\n"); - return ret; + /* Register handlers only after their queues and tasklets are ready. */ + if (!resume) { + ret = arm_smmu_setup_irqs(smmu); + if (ret) { + dev_err(smmu->dev, "failed to setup irqs\n"); + return ret; + } } - /* Initialize tasklets for threaded IRQs*/ - tasklet_init(&smmu->evtq_irq_tasklet, arm_smmu_evtq_tasklet, smmu); - tasklet_init(&smmu->priq_irq_tasklet, arm_smmu_priq_tasklet, smmu); - tasklet_init(&smmu->combined_irq_tasklet, arm_smmu_combined_irq_tasklet, - smmu); + ret = arm_smmu_enable_irqs(smmu); + if (ret) + goto err_free_irqs; /* Enable the SMMU interface, or ensure bypass */ if (disable_bypass) { @@ -2190,10 +2238,18 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) goto err_free_irqs; } + /* IHI0070G.b, section 6.3.16: re-enabling IRQs does not replay events. */ + if (resume && !queue_empty(&smmu->evtq.q.llq)) + tasklet_schedule(&smmu->evtq_irq_tasklet); + if (resume && (smmu->features & ARM_SMMU_FEAT_PRI) && + !queue_empty(&smmu->priq.q.llq)) + tasklet_schedule(&smmu->priq_irq_tasklet); + return 0; err_free_irqs: - arm_smmu_free_irqs(smmu); + if (!resume) + arm_smmu_free_irqs(smmu); return ret; } @@ -2558,10 +2614,21 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev) if (ret) goto out_free; + /* Initialize tasklets for threaded IRQs*/ + tasklet_init(&smmu->evtq_irq_tasklet, arm_smmu_evtq_tasklet, smmu); + tasklet_init(&smmu->priq_irq_tasklet, arm_smmu_priq_tasklet, smmu); + tasklet_init(&smmu->combined_irq_tasklet, arm_smmu_combined_irq_tasklet, + smmu); + /* Reset the device */ - ret = arm_smmu_device_reset(smmu); - if (ret) + ret = arm_smmu_device_reset(smmu, false); + if (ret) { + /* Reset may have enabled queues before failing. */ + if (arm_smmu_device_disable(smmu)) + panic("SMMUv3: %s: Failed to disable during probe cleanup\n", + dev_name(smmu->dev)); goto out_free; + } /* * Keep a list of all probed devices. This will be used to query @@ -2575,7 +2642,6 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev) return 0; - out_free: arm_smmu_free_structures(smmu); if (smmu->page1) @@ -2855,6 +2921,142 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d) xfree(xen_domain); } +#ifdef CONFIG_SYSTEM_SUSPEND + +static void arm_smmu_save_queue_producers(struct arm_smmu_device *smmu) +{ + /* + * IHI0070G.b, sections 6.3.9.4 and 6.3.9.5: EVTQ/PRIQ disable + * acknowledgements make committed entries visible. The caller must + * wait for these acknowledgements before reading the producer indices. + */ + if (queue_sync_prod_in(&smmu->evtq.q) == -EOVERFLOW) + dev_warn(smmu->dev, "EVTQ overflow detected during suspend\n"); + if ((smmu->features & ARM_SMMU_FEAT_PRI) && + queue_sync_prod_in(&smmu->priq.q) == -EOVERFLOW) + dev_warn(smmu->dev, "PRIQ overflow detected during suspend\n"); +} + +static void arm_smmu_reset_for_suspend_rollback(struct arm_smmu_device *smmu) +{ + int ret; + u32 reg; + + /* + * The queues have been requested to stop, but a CR0ACK timeout may + * have skipped saving their producer indices. Wait for the queue + * disable acknowledgements before reset overwrites those indices. + */ + ret = readl_relaxed_poll_timeout(smmu->base + ARM_SMMU_CR0ACK, reg, + !(reg & (CR0_EVTQEN | CR0_PRIQEN)), + 1, ARM_SMMU_POLL_TIMEOUT_US); + if (ret) + panic("SMMUv3: %s: Queue stop timed out during rollback: %d\n", + dev_name(smmu->dev), ret); + + arm_smmu_save_queue_producers(smmu); + ret = arm_smmu_device_reset(smmu, true); + + /* The host suspend error path allows domains to run again. */ + if ( ret ) + panic("SMMUv3: %s: Failed to reset during suspend rollback: %d\n", + dev_name(smmu->dev), ret); +} + +static int arm_smmu_suspend(void) +{ + struct arm_smmu_device *smmu; + int ret = 0; + + list_for_each_entry(smmu, &arm_smmu_devices, devices) + { + /* Abort all transactions before disable to avoid spurious bypass */ + ret = arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0); + if ( ret ) + goto rollback_previous; + + /* Disable the SMMU via CR0.EN and all queues except CMDQ */ + ret = arm_smmu_write_reg_sync(smmu, CR0_CMDQEN, ARM_SMMU_CR0, + ARM_SMMU_CR0ACK); + if ( ret ) + { + dev_err(smmu->dev, "Timed-out while disabling smmu\n"); + goto fail; + } + + arm_smmu_save_queue_producers(smmu); + + /* + * At this point the translation interface is disabled and the + * SMMU won't access translation/config structures, even + * speculatively, as per the IHI0070 spec (section 6.3.9.6). + * CMDQ is still enabled so that a CMD_SYNC can complete any + * previously issued commands. + */ + + /* Ensure all previously issued commands have completed. */ + ret = arm_smmu_cmdq_issue_sync(smmu); + if ( ret ) + { + dev_err(smmu->dev, "Timed-out waiting for pending commands\n"); + goto fail; + } + + /* Stop IRQ generation before gating the handler and disabling CMDQ. */ + ret = arm_smmu_disable_irqs(smmu); + if (ret) { + dev_err(smmu->dev, "Timed-out while disabling SMMU irqs\n"); + goto fail; + } + write_atomic(&smmu->gerror_blocked, true); + + /* Disable everything */ + ret = arm_smmu_device_disable(smmu); + if ( ret ) + goto fail; + + /* Other CPUs are offline and the IRQ handler is gated above. */ + arm_smmu_handle_gerror(smmu); + + dev_dbg(smmu->dev, "Suspended smmu\n"); + } + + return 0; + + fail: + /* Reset the device that failed as well as any already-suspended ones. */ + arm_smmu_reset_for_suspend_rollback(smmu); + + rollback_previous: + /* An initial GBPA failure leaves this SMMU enabled: do not reset it. */ + list_for_each_entry_continue_reverse(smmu, &arm_smmu_devices, devices) + arm_smmu_reset_for_suspend_rollback(smmu); + + return ret; +} + +static void arm_smmu_resume(void) +{ + int ret; + struct arm_smmu_device *smmu; + + list_for_each_entry(smmu, &arm_smmu_devices, devices) + { + dev_dbg(smmu->dev, "Resuming device\n"); + + /* + * The reset will re-initialize all the base addresses, queues, + * prod and cons maintained within struct arm_smmu_device as well as + * re-enable the interrupts. + */ + ret = arm_smmu_device_reset(smmu, true); + if ( ret ) + panic("SMMUv3: %s: Failed to reset during resume: %d\n", + dev_name(smmu->dev), ret); + } +} +#endif + static const struct iommu_ops arm_smmu_iommu_ops = { .page_sizes = PAGE_SIZE_4K, .init = arm_smmu_iommu_xen_domain_init, @@ -2867,6 +3069,10 @@ static const struct iommu_ops arm_smmu_iommu_ops = { .unmap_page = arm_iommu_unmap_page, .dt_xlate = arm_smmu_dt_xlate, .add_device = arm_smmu_add_device, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = arm_smmu_suspend, + .resume = arm_smmu_resume, +#endif }; static __init int arm_smmu_dt_init(struct dt_device_node *dev, diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthrough/arm/smmu-v3.h index ab07366294..93986886f2 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.h +++ b/xen/drivers/passthrough/arm/smmu-v3.h @@ -613,6 +613,7 @@ struct arm_smmu_device { int combined_irq; u32 sync_nr; u8 prev_cmd_opcode; + bool gerror_blocked; unsigned long ias; /* IPA */ unsigned long oas; /* PA */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462582.1673632 (Exim 4.92) (envelope-from ) id 1xLoNP-0007Rn-5R; Tue, 27 Oct 2026 21:06:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462582.1673632; Tue, 27 Oct 2026 21: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 1xLoNO-0007RX-Ri; Tue, 27 Oct 2026 21:06:34 +0000 Received: by outflank-mailman (input) for mailman id 1462582; Tue, 27 Oct 2026 21:06:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNM-0006tv-Ca for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNL-005OFk-PW for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:31 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11224-bab6-0a2a0a5309dd-0a2a45048502-34 for ; Tue, 27 Oct 2026 22:06:31 +0100 Received: from [52.101.65.95] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11257-b57f-0a2a45040019-3465415fb2ef-3 for ; Tue, 27 Oct 2026 22:06:31 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:30 +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.0546.021; Tue, 27 Oct 2026 21:06: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=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=Sa+7pG7i57ugT7NLZ8gTHR8l7iON+r6+KpXDPokl3Wb5qUJv23b/D0PCkcNMnIYGcNkEoeyfRVneF5V1fkykDL4mwcDpTj5mZwfiF1YXENq/TxvOcH5qbzwSxYbUKZN02vkMWme1Oicj9pyYvL6VtDuN2PasyRUpFhIVTzhR/xGiqZHz33CbHenW6HZNOjgmU7Peg0RWDtc7VzfwgzZ9CZhxVE2i0WCbM1Z1pnhSU5djOxUSZvI/RarDTyQgx5yPYhhzJailIyXadd2r+5JFtmlK3FH/RzC2kb05pMjq8edMjsi1NlgryB7LFqtYaoFeC1JqylbqlSy+PpJU0M0UUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qv14y0LA0j3PuvfCtOX8KXFP2/tjoIjxeGt7xfJ4tFQ=; b=HgU0NTXaXQdo9GAI3w3FfTLEnYrGkhX5gPAEOyGdJnCASGzUfsnuNnJ+fGrlXIPtXJleSkbKAbNrhHUCff/PltowhJjy2pAvscgiCTaJ/XAN0T/itqHC9x4dAiCyEb0dC2bSGmPVWamkO5SJGR8yIv9HXfdydpSGPkNYCj6GvQZxdMsCLPONLd/98ZxQxZKOCHFsGm0+8E6rB4Cb084osiIBfk+Y4cP6v9fJr6SXwxE07Wkh8y59osL55fcqH5hL8uwJXtxFEK4aGsUzIIRG6T7CXrrNw+n+9px1T6rlXZjq9WhnchcLAglpD/0WzM6b2poy6s8FXo39hbcU7XyNfQ== 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=qv14y0LA0j3PuvfCtOX8KXFP2/tjoIjxeGt7xfJ4tFQ=; b=W03kVj/ezIn04wub9MwGSUV5rlkFqZxVItR4/CCOQ2HP0hqjXxOjkNZAOqpDiWxr5/7+FoLy9NJelk/TDX8XzFYOOHiwmJm9ynXzXIcSd8iS+ILhaJikYwRcqk8hnBUDP6ww0srVRmI+iNhC17g0GboG88/OvlO3ipYUdaJfv6Q2f48mvwkC11O9yGsHKVtVFZmzYai3u6iaGPUVwvUiZZqnCABMjwlqjVxUxESVtOIy2PFiAk8tNt8UE/wqVbpgZsYlVmk5h7jZls+xnRAWuCEF0TRdVvPWD7xcCMQJ/KtNAwT553gfxjg5xIovci3CXNfnRqOMy9GeKyakmvVVZA== 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: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai , Oleksandr Tyshchenko , Luca Fancellu Subject: [PATCH v13 11/14] xen/arm64: Save/restore CPU context across SYSTEM_SUSPEND Date: Tue, 27 Oct 2026 23:06:00 +0200 Message-ID: <481848fb2d9ada11e6e4661e4a4e6b2d4e80eecc.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: a247a8ab-a93d-43dc-6278-08df346e2bfa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|261026121527099003|260925021311599003|261022075727099003|260925021911599003|11063799006|5023799004|56012099006|261009223027099003|260925022911599003|261021121427099003|261022105027099003|22082099003|18002099003|6133799003|10067099003|261026140227099003; X-Microsoft-Antispam-Message-Info: I0pB+pVVdeyhz/UI9lBCVlNNuZex3Kz/O9ZNHra4/8YjiuX66RSHpHkQ/PV6ViGrkcUjAsPBjm4V9ALMukygB4j4f4UITiAPHGmzND28WOWy46MSAMwmS8YDMAQ9Ejnqj6tVYoSGXKdeUhcP3TKTzxbmnGy86EKASMCsV3eo5CfzDu2vkj8DTp++QhBugJs1i4YcucJ5FLzdtpS31Q8zT32qdhcRFjjiZf6JZX8dMLnjAiUXStBWkj7qL4qAuxJN3MR9M2OkGYwH0B/ZX2hjFuSv8+UKwty2x8mkKT8gFHx8IWZHi+a7uobCQzSW/i1IOEv6SDXVGEn8njP/f3rXTj6dUhMbuBPakUPmX6lQu8iYn5kOqAjDK00dv6SMb/fpz82FFgql867svCTcqBSwCNvhtLPNudRMGFD1wYrSdtErHE6xVbaeJzFdNYhdIYltNbw+DglVAYSozrIibkeJA+nx50wSM+atcXqdvujVOafRwkiEU9u98PEenarV7ZFUc/wLvq8Orrn6m6GyjJ7BZFzqf9nOhwpo3WWQKAqhqj3IbQX8R7Q81jwjSm9ChAPrTp7cT5BaiWFIlTv8DRL71jdqk0eosKDgIU+bvWmMMLuL/1kDm6pwpeLZWzIWX8Mdv2/EZVXjFYhbpIOOKxXVI/iLAg9HPZVVF6mkDMFftL8= 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)(23010399003)(366016)(1800799024)(376014)(261026121527099003)(260925021311599003)(261022075727099003)(260925021911599003)(11063799006)(5023799004)(56012099006)(261009223027099003)(260925022911599003)(261021121427099003)(261022105027099003)(22082099003)(18002099003)(6133799003)(10067099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?B35nRM2GHEvwxGolr+JXF595VcTC0z4nRZmNezyybHSLPU782m6lBlmD7uhJ?= =?us-ascii?Q?DmTtwiRCKvzAcgaHSFwFDuF3s/ilJR5QulUc84BLF3Eb2hBXmcll09VT33iO?= =?us-ascii?Q?X3DUwaWwjUEKBGNtyUPmtALp/0Ujj3TbLYekwHELr8nqSM4Hb42E24C+B/du?= =?us-ascii?Q?nMm1EGZSJhB6aVajtnraqhQ9JU3O+xfay/EWlpOCVZBUCR4s8fZ2EWTzuZns?= =?us-ascii?Q?Axm5YeCW0KRNM7LOhm57ywaUSyXCMj8HIkjUVXfoPVArxEzsbhsaPTpUWR5i?= =?us-ascii?Q?YdGd4mE4CHxw8u6KBNCknVkDzqrEnFMLoDXxwiUs59SF/Cm4B57JmV2yYKz9?= =?us-ascii?Q?ozB0AK4ohh979wfCg15AvDsgNAUiMZg8+MTifWHfLeCruOk27otcMc381cXc?= =?us-ascii?Q?W/WNtXCosinEZha1bCBFvxc36pJXutkzVsPY9D8xBOVTlolGQQv17VlVWnwf?= =?us-ascii?Q?9GSLDXzFqKI4yggEbM8IkF16j6FgYlWgdgweIrkZ4zuVTdYO474H7tMe9k0n?= =?us-ascii?Q?GVGMyA+jsPdyyfUiiWyQVhmyDqgpLJu4/8rNz3IAbytG0LpELN8AE/wzwAbj?= =?us-ascii?Q?IAUzhbMssYvYsTb7in9M1um0LQ57pDbIkrwh+KEhF7csvii7I2lQczMnDgIY?= =?us-ascii?Q?tCD5Ez9FQKI6pJMkcKvnE+wcowHDgbyZXqyBpGII6bHgJqYuGNlE3rmRISkN?= =?us-ascii?Q?g5Vv1PcIcOm4QuP5776cUkJRryw6WAu07iAyP4Z5TaSoqxxWUrwpCcoaYGRx?= =?us-ascii?Q?Moq3R6uYSHzIuRjpaSBGmbwhh7o2wWuviyG8yIXnOlGEM3XZJQE6hz/jl/AS?= =?us-ascii?Q?HV0bDYqrX1XiAI8PXxRKm/+mFcVZUIDiXmVrBQZe2FTHNY9Igx6lL398NkEL?= =?us-ascii?Q?K9zyimozFS5DrniY379COL8FFAOu+LZ11jcxe90aalN2yr2Iq+TWkWboLVbj?= =?us-ascii?Q?OLZs71lFZqRy5gx17RyP6CxKv7y/exa54tXwyqH7rGcWVIS9r5G9ZlZzJLy5?= =?us-ascii?Q?m4kgPRxIB7btxqXOHha36lcmUqtgOS3ZXA9DqDGTxZHKXXYjWQQ/Z0lU57KN?= =?us-ascii?Q?9RZlsed7mZ2f5aYMIMfNgzObKVZP/sI7UNTnobqHoO3yTIUSxfnoOjBFtiqe?= =?us-ascii?Q?iXBMZbor7rGqvK9xz825Du64zS9zxRq31AtFvDvBmxrZTuBoz/u63cjlyuRy?= =?us-ascii?Q?qNaLNjLjTwe7Vs5KJ0VOJMS/2XCcQtowsWGLP2dJQJnw0tkho2QjJWkXiQtH?= =?us-ascii?Q?z6sR/K07XebO98CCHeURlJUROgJga9UMblRIN1MANs5lOPYPzS7XNv1s/Y+7?= =?us-ascii?Q?wyiZnp1l7UvGElmlJ6gVIKeoQlb51dms34YDJMVxNLa283hCVO01Rr+RWuwt?= =?us-ascii?Q?kiQB4VxTacXNF9gSH0cmi1sEj6L4ZVwcpalfu4C9Y+qMnWf8LLUpH6n07cKf?= =?us-ascii?Q?bY/fd5Z9nhCVTk6FY9NufVBuOgqLxp4eRVLrCW3V7Ds2HYayfuJet+JeEodr?= =?us-ascii?Q?RrMWXUn682tE2ZYzVU62XuLAX3uNrYrve5t/c+Upi9xUNK/7NxrdgLNKcfGp?= =?us-ascii?Q?ZiHtce/B6zFLl/ASTDwmqJiKi4q59xh0BWtQw7k+bpBMR4iR5rADs7tp9oEY?= =?us-ascii?Q?Yfqjoe6R0+R2p6qwHIRyRXy9FRmZVDR4o6//aK6IkLI2VwTJIN6wbu02t2SV?= =?us-ascii?Q?JzpkaYY1jZcSmTXQVcCeJWRMTbWNrt0ZcBbTeAkQBXhL3QHSCE7P/TXX/jio?= =?us-ascii?Q?VG3H3ILYTw=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a247a8ab-a93d-43dc-6278-08df346e2bfa X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:30.0028 (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: eJbr+9WOkZ1A733yjmQHj7LayBDYKR1I33seR14G2VFe70000CSqOh0ja8nDEWHMhcHhCnOHEvU9nrxN/40Ciw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-ebf023/1793135191-51ED6B50-6453FE2A/0/0 X-purgate-type: clean X-purgate-size: 11545 From: Mirela Simonovic On wakeup from PSCI SYSTEM_SUSPEND, Xen re-enters EL2 with the MMU and data cache disabled. The resume path must first switch back to Xen's runtime page tables before it can access the saved CPU context using virtual addresses. Add an arm64 hyp_resume trampoline that reuses enable_secondary_cpu_mm() to enable the data cache and MMU, switch to init_ttbr, and resume in the runtime virtual mapping. The trampoline then restores the saved CPU general-purpose and system-control register context. prepare_resume_ctx() must be invoked just before the PSCI system suspend call is issued to the platform firmware. It saves the current CPU context and returns a non-zero value so that the caller enters the physical SYSTEM_SUSPEND call. On resume, hyp_resume restores the saved context, including the saved link register. Control therefore returns to the place where prepare_resume_ctx() was called. To avoid re-entering the suspend path, the restored path sees prepare_resume_ctx() return zero. The assembly save/restore code uses offsets generated by asm-offsets.c from struct resume_cpu_context, keeping the assembly memory accesses in sync with the C structure layout. Support for ARM32 is not implemented. Instead, compilation fails with a build-time error if suspend is enabled for ARM32. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach Reviewed-by: Oleksandr Tyshchenko Reviewed-by: Luca Fancellu Reviewed-by: Bertrand Marquis --- Changes in v10: - Save and restore CNTHCTL_EL2 across SYSTEM_SUSPEND Changes in v9: - Drop the misleading prepare_resume_ctx() pointer argument and make both save/restore paths use the global resume_cpu_context. - Squash the arm64 resume trampoline into the context save/restore patch. - Document in code that hyp_resume relies on PSCI initial-state rules. - Use generic platform firmware wording instead of ATF-specific wording. - Rename the saved context type/storage to resume_cpu_context and rely on implicit zero-initialization for the file-scope object. - Use asm-offsets.c-generated RESUME_CTX_* offsets to keep the assembly save/restore code in sync with struct resume_cpu_context. Changes in v8: - Fix alignments in code. Changes in v7: - No functional changes, just moved commit. --- xen/arch/arm/Makefile | 1 + xen/arch/arm/arm64/asm-offsets.c | 21 +++++ xen/arch/arm/arm64/head.S | 122 +++++++++++++++++++++++++++++ xen/arch/arm/include/asm/suspend.h | 27 +++++++ xen/arch/arm/suspend.c | 14 ++++ 5 files changed, 185 insertions(+) create mode 100644 xen/arch/arm/suspend.c diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index cdcec8cd03..09640090b4 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -52,6 +52,7 @@ obj-y += setup.o obj-y += shutdown.o obj-y += smp.o obj-y += smpboot.o +obj-$(CONFIG_SYSTEM_SUSPEND) += suspend.o obj-$(CONFIG_SYSCTL) += sysctl.o obj-y += time.o obj-y += traps.o diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c index 38a3894a3b..5d60406e9c 100644 --- a/xen/arch/arm/arm64/asm-offsets.c +++ b/xen/arch/arm/arm64/asm-offsets.c @@ -13,6 +13,7 @@ #include #include #include +#include #define DEFINE(_sym, _val) \ asm volatile ( "\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\""\ @@ -57,6 +58,26 @@ void __dummy__(void) OFFSET(INITINFO_stack, struct init_info, stack); BLANK(); +#ifdef CONFIG_SYSTEM_SUSPEND + OFFSET(RESUME_CTX_X19, struct resume_cpu_context, callee_regs[0]); + OFFSET(RESUME_CTX_X21, struct resume_cpu_context, callee_regs[2]); + OFFSET(RESUME_CTX_X23, struct resume_cpu_context, callee_regs[4]); + OFFSET(RESUME_CTX_X25, struct resume_cpu_context, callee_regs[6]); + OFFSET(RESUME_CTX_X27, struct resume_cpu_context, callee_regs[8]); + OFFSET(RESUME_CTX_X29, struct resume_cpu_context, callee_regs[10]); + OFFSET(RESUME_CTX_SP, struct resume_cpu_context, sp); + OFFSET(RESUME_CTX_VBAR_EL2, struct resume_cpu_context, vbar_el2); + OFFSET(RESUME_CTX_VTCR_EL2, struct resume_cpu_context, vtcr_el2); + OFFSET(RESUME_CTX_VTTBR_EL2, struct resume_cpu_context, vttbr_el2); + OFFSET(RESUME_CTX_TPIDR_EL2, struct resume_cpu_context, tpidr_el2); + OFFSET(RESUME_CTX_MDCR_EL2, struct resume_cpu_context, mdcr_el2); + OFFSET(RESUME_CTX_HSTR_EL2, struct resume_cpu_context, hstr_el2); + OFFSET(RESUME_CTX_CPTR_EL2, struct resume_cpu_context, cptr_el2); + OFFSET(RESUME_CTX_HCR_EL2, struct resume_cpu_context, hcr_el2); + OFFSET(RESUME_CTX_CNTHCTL_EL2, struct resume_cpu_context, cnthctl_el2); + BLANK(); +#endif + OFFSET(SMCCC_RES_a0, struct arm_smccc_res, a0); OFFSET(SMCCC_RES_a2, struct arm_smccc_res, a2); OFFSET(ARM_SMCCC_1_2_REGS_X0_OFFS, struct arm_smccc_1_2_regs, a0); diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 7d1e205353..7794eb4c6e 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -563,6 +563,128 @@ END(efi_xen_start) #endif /* CONFIG_ARM_EFI */ +#ifdef CONFIG_SYSTEM_SUSPEND +/* + * int prepare_resume_ctx(void) + * + * CPU context saved here will be restored on resume in hyp_resume function. + * prepare_resume_ctx shall return a non-zero value. Upon restoring context + * hyp_resume shall return value zero instead. From C code that invokes + * prepare_resume_ctx, the return value is interpreted to determine whether + * the context is saved (prepare_resume_ctx) or restored (hyp_resume). + */ +FUNC(prepare_resume_ctx) + ldr x0, =resume_cpu_context + + /* Store callee-saved registers */ + stp x19, x20, [x0, #RESUME_CTX_X19] + stp x21, x22, [x0, #RESUME_CTX_X21] + stp x23, x24, [x0, #RESUME_CTX_X23] + stp x25, x26, [x0, #RESUME_CTX_X25] + stp x27, x28, [x0, #RESUME_CTX_X27] + stp x29, lr, [x0, #RESUME_CTX_X29] + + /* Store stack-pointer */ + mov x2, sp + str x2, [x0, #RESUME_CTX_SP] + + /* Store system control registers */ + mrs x2, VBAR_EL2 + str x2, [x0, #RESUME_CTX_VBAR_EL2] + mrs x2, VTCR_EL2 + str x2, [x0, #RESUME_CTX_VTCR_EL2] + mrs x2, VTTBR_EL2 + str x2, [x0, #RESUME_CTX_VTTBR_EL2] + mrs x2, TPIDR_EL2 + str x2, [x0, #RESUME_CTX_TPIDR_EL2] + mrs x2, MDCR_EL2 + str x2, [x0, #RESUME_CTX_MDCR_EL2] + mrs x2, HSTR_EL2 + str x2, [x0, #RESUME_CTX_HSTR_EL2] + mrs x2, CPTR_EL2 + str x2, [x0, #RESUME_CTX_CPTR_EL2] + mrs x2, HCR_EL2 + str x2, [x0, #RESUME_CTX_HCR_EL2] + mrs x2, CNTHCTL_EL2 + str x2, [x0, #RESUME_CTX_CNTHCTL_EL2] + + /* prepare_resume_ctx must return a non-zero value */ + mov x0, #1 + ret +END(prepare_resume_ctx) + +FUNC(hyp_resume) + /* + * PSCI states that SYSTEM_SUSPEND follows the CPU_SUSPEND initial + * state rules, so PSCI-compliant firmware must enter the return + * exception level with DAIF masked. + */ + + /* Initialize the UART if earlyprintk has been enabled. */ +#ifdef CONFIG_EARLY_PRINTK + bl init_uart +#endif + PRINT_ID("- Xen resuming -\r\n") + + bl check_cpu_mode + bl cpu_init + + ldr x0, =start + adr x20, start /* x20 := paddr (start) */ + sub x20, x20, x0 /* x20 := phys-offset */ + ldr lr, =mmu_resumed + b enable_secondary_cpu_mm + +mmu_resumed: + /* Now we can access the saved context, so restore it here. */ + ldr x0, =resume_cpu_context + + /* Restore callee-saved registers */ + ldp x19, x20, [x0, #RESUME_CTX_X19] + ldp x21, x22, [x0, #RESUME_CTX_X21] + ldp x23, x24, [x0, #RESUME_CTX_X23] + ldp x25, x26, [x0, #RESUME_CTX_X25] + ldp x27, x28, [x0, #RESUME_CTX_X27] + ldp x29, lr, [x0, #RESUME_CTX_X29] + + /* Restore stack pointer */ + ldr x2, [x0, #RESUME_CTX_SP] + mov sp, x2 + + /* Restore system control registers */ + ldr x2, [x0, #RESUME_CTX_VBAR_EL2] + msr VBAR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_VTCR_EL2] + msr VTCR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_VTTBR_EL2] + msr VTTBR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_TPIDR_EL2] + msr TPIDR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_MDCR_EL2] + msr MDCR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_HSTR_EL2] + msr HSTR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_CPTR_EL2] + msr CPTR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_HCR_EL2] + msr HCR_EL2, x2 + ldr x2, [x0, #RESUME_CTX_CNTHCTL_EL2] + msr CNTHCTL_EL2, x2 + isb + + /* + * Since context is restored return from this function will appear + * as return from prepare_resume_ctx. To distinguish a return from + * prepare_resume_ctx which is called upon finalizing the suspend, + * as opposed to return from this function which executes on resume, + * we need to return zero value here. + */ + mov x0, #0 + ret +END(hyp_resume) + +#endif /* CONFIG_SYSTEM_SUSPEND */ + /* * Local variables: * mode: ASM diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h index 31a98a1f1b..c848fc6340 100644 --- a/xen/arch/arm/include/asm/suspend.h +++ b/xen/arch/arm/include/asm/suspend.h @@ -3,6 +3,8 @@ #ifndef ARM_SUSPEND_H #define ARM_SUSPEND_H +#include + struct domain; struct vcpu; struct vcpu_guest_context; @@ -14,6 +16,31 @@ struct resume_info { void arch_domain_resume(struct domain *d); +#ifdef CONFIG_SYSTEM_SUSPEND +#ifdef CONFIG_ARM_64 +struct resume_cpu_context { + register_t callee_regs[12]; + register_t sp; + register_t vbar_el2; + register_t vtcr_el2; + register_t vttbr_el2; + register_t tpidr_el2; + register_t mdcr_el2; + register_t hstr_el2; + register_t cptr_el2; + register_t hcr_el2; + register_t cnthctl_el2; +} __aligned(16); +#else +#error "Define resume_cpu_context structure for arm32" +#endif + +extern struct resume_cpu_context resume_cpu_context; + +int prepare_resume_ctx(void); +void hyp_resume(void); +#endif /* CONFIG_SYSTEM_SUSPEND */ + #endif /* ARM_SUSPEND_H */ /* diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c new file mode 100644 index 0000000000..6ea4a0f9cc --- /dev/null +++ b/xen/arch/arm/suspend.c @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include + +struct resume_cpu_context resume_cpu_context; + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462586.1673638 (Exim 4.92) (envelope-from ) id 1xLoNQ-0007ZK-31; Tue, 27 Oct 2026 21:06:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462586.1673638; Tue, 27 Oct 2026 21: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 1xLoNP-0007Xg-N8; Tue, 27 Oct 2026 21:06:35 +0000 Received: by outflank-mailman (input) for mailman id 1462586; Tue, 27 Oct 2026 21:06:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNO-0007Il-22 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNN-007u3c-Eb for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:33 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11240-2eae-0a2a0a5409dd-0a2a450c8962-22 for ; Tue, 27 Oct 2026 22:06:33 +0100 Received: from [52.101.84.83] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae11258-f479-0a2a450c0019-346554535b99-3 for ; Tue, 27 Oct 2026 22:06:33 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:31 +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.0546.021; Tue, 27 Oct 2026 21:06: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=hPjBn/+9Z/kl9xvQ/r5TWiXVGNNyK6rhFaPy0qJp/z011l2d8ESINacm6yEopIWVWVK+lDrsqSk5D2avCwGTO3C68pTBL5RSK9cpoR8NAAiIHDCRtRty4uundxPY839PSf9fjLr8EHTnZJqk5f2mL1MRTUwn+CWg4WVkfX1NmGlROCjbM1/lRIMRhHIL7f6rIh2UU8b4S9C+JXN2q4zNVsVPp2mTYvH29zbcfJa0piTZG7Fh2M2BRgsBZzv5g1JsZsF2oaDGu0hOZYlb8rxIDnz8q7CWE9u3VLi+xTAv57ZULjLUNVKrghdUGsG2NgNWCODBaDBIgHyaBx/4rxTXFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Lf9TmsDfGuKFKY1Sh8y3OhWOESQWbPLVvxQwVSvceEs=; b=A3XI3HW/xCnrxoiDhg7oqxVu71hSTZkwNN23Dvi3XBJQMqHqDli5fmGotNnISFnKQvd6ZXbJ5eB0FZjMukCLwiYp2hfuOn73MI8tN/qoeEXIsd9N+8goHO5AlfNGci1t79ZJGFcUbQ7/Icv1LMQVAvl3JVLEhzp64OmNGhat+yd6IOFNs/4Gj+IFmTbUCeP50poMiQqmZrmRCqS08gktu/0ddlo2mTgmIHYFvGbtQhf5GebSTSqND0Y2BVGBlvfpIceDYvG72zkgER3bbj8ujm+yYor/7OQD4zl8Q1I1TIFjjnoYDYtrgVnpjn21iF1UT5VJHS4vlBwJe10SSPXItg== 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=Lf9TmsDfGuKFKY1Sh8y3OhWOESQWbPLVvxQwVSvceEs=; b=vZil580iQio2tRRmGBxd+lnuNh1qtVy6O9ZnE5WiT040tef10+KtltqwWr6pHPS1AebtDCtEiibofPM3tDfhkWEcLqTn1aiBUS9+6uL3YUVC4jI2AaBang1Yu1bhqSoKqI0mAqrrprSyBXa4rJYXYUd/OeXeh1nBdMuhv59V1cRmxsLVfB63zgucWgtPbGHGC1AlPSipHubm5t/G03HQ1TIIBVTBcfg17sr4A9UuC52bfB72gEH5P99VCPZafBxh+LB8s6HsnHZdbuRlEgzezq0qqrRE6mK56mYD0DQD1KaWH34P5XTn6mx00qpY+aPqCER6WsV0EBApdlYWUEiPVQ== 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: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai , Luca Fancellu Subject: [PATCH v13 12/14] xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface) Date: Tue, 27 Oct 2026 23:06:01 +0200 Message-ID: <85786d24cb2f835de97ca8c3cd9e8181a26b4bef.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: a202282e-b4e7-4242-6d7e-08df346e2cf7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|11063799006|5023799004|56012099006|261009223027099003|261021123027099003|261021121427099003|261022105027099003|22082099003|18002099003|6133799003|10067099003|261026140227099003; X-Microsoft-Antispam-Message-Info: JEV+YLpW6cfke6s3BiLmURTHXWPegamKnA9g5YwMMIMAEbIYvqEHS9LP8Tc2CfWGmtFNtv34EIXZZ4NMz9UwJ2kR52cI47ce1vHjx71yw8/1kfvYhmOmg+mj2XRPpfjZTEW9hpp7mmwRG759mnWSVLfmNKd+LwAA1mDX2cYjHLRFybwq8Fv6XtM/TNq8793D7SHNokg7AEPs/8wcEGXPjrWcWvdR3Y1H2dhyf0fWwcBgL2Vd9c5V4VwDheRfu9T2vf6uA6+IKVGcO0eRH7EvwPzbkGuwHp04u7GzGYrm4Qpl9YzYRCF0xX0q4KnZtWpjnKhAbaQMb3jQwKYNm8umsZd5grlyiu7YBhbvoKnVduBQHFn5tZzyr8D94Py11dN+pww1dJstFg/3L+sPzzyyJWRAxSRpLrr/1S3mjL7J87vQF13j9bx/HELKzpMlq1tM48gZMA7eZrpMKdXPqeTLMB5HBPck4fIGYALFNozVjgh0k5S8Lvr8zn7AWJ9UzLNP3wai78Hwu8v9F4H/tF2zJKnpWxnAXZ7L3K6NT97Xmtfg+1BROGxkISNAut8uOQYQ4cFoZ0N1ZOBDa+ZQ/HLzAjL8VhiHJFvh/H897Xll3mF6ba52PccKIzXGVKmQO19f6ZlhmKLN0W4SEHyIvY1JhOHTF14arJ2eq1Ilnglf+fo= 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)(23010399003)(366016)(1800799024)(376014)(11063799006)(5023799004)(56012099006)(261009223027099003)(261021123027099003)(261021121427099003)(261022105027099003)(22082099003)(18002099003)(6133799003)(10067099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GNQUp4hUY5wWlURfze1KLaA4QBzuGb56mb5WzrLPbqje0nZjyF15Zzv9AVem?= =?us-ascii?Q?qTyOLAp8SL3pSSGi+YbbQqz0fQNqAtk5sTIYE9VVV0QdJBNZtMzo87Y+2mID?= =?us-ascii?Q?yYVdwXEkVl4SK+4O51XROxaRHfU3BEdVCkPn8kc2JhIqM5Af6c8M4al/Pml/?= =?us-ascii?Q?slPatzvQP3jxc4AIEEQB8FGRypuMoyPuz3PbX3nF6edcXuPuYTO89sEir9/C?= =?us-ascii?Q?AfPanhPKLoojwngyraO6jYKwv2hTNPguL4oKzmlpL+zjPjwiDPyLZVXPWXR8?= =?us-ascii?Q?Km53Y5sB3E0i7WhVvawR13PyEaHB9H9lLDfQFmr4QYBR7jqVy/UQ1QbGPM72?= =?us-ascii?Q?tIYCpn5Rfh/j+gM/YAWu6H2Df/T5GMYd1phQcOCqMhQDNFeyLcxWgz1LapR1?= =?us-ascii?Q?sMX6C9QCkGM3c1aXCzZVi1Dvvj9AmjSMd9VUenkBxySTLBhOCJULXiQ06CQF?= =?us-ascii?Q?269u/rDg0F58Zv97rpm81dVL20WfAW32h9jyFzJl1AEQGJTBs10nJoeDqY8k?= =?us-ascii?Q?lfcLRh90qYq3yivz+p8vFt2nq2PmhQDEzWNzL6wPIW7k6FlYvFKcVkfqmA9D?= =?us-ascii?Q?ar/pGjo+NhcwbVbH6W33k1lJ/+OuAXIItj0L1mGwiRppD1EUFfDcfW1glknl?= =?us-ascii?Q?3kAyMWa1Qtl2V8tfWY/M5bkomXgToYhO4L6rGlm5BloT68DrW3I/0Tr0Cc4o?= =?us-ascii?Q?BCXhs8Ysc/W1ras6fRAY5age8o52Y1fLKeY8VHiAXWcdfU81YBqZZuu/2uEH?= =?us-ascii?Q?iSCzLWPfW3YueqrubUYmBEvy2uJTfEZKmy4Lb0ib3CF7mMED7Mgmmb9U504d?= =?us-ascii?Q?03PFLriTIwSdw1b9PPAiaYfX2VqlLEmRJyY/kxMSzHEM9yCwqnpkPMKQxjBO?= =?us-ascii?Q?V0//60+wF9xF/0nkgE6pMXwCTEsXYI+5ziRlXuPF4vZp+2vAxFduT2X7MIL8?= =?us-ascii?Q?+hRCo3pmrcW0ZVUKZSImMRnCPZrLIqVq2BPysZJSNNt+dvQpzrnSAF3G9SUM?= =?us-ascii?Q?4z+XsalZKWsj0dW+yI6lkVVBuA8bnDGCvViJLwJ1HZdTuI8UQQCfLbMSgc7T?= =?us-ascii?Q?tJHqkntty8suMUpyGiqXzsa4bTcpaLuh22B9oMNFYFAtVhdIyfqICbKQBYO6?= =?us-ascii?Q?I9jmxdDEnGGt/1RSdC0yoGrABgdlDtXTyyySYuXmbl0A4cCMfrwjCGx4c90t?= =?us-ascii?Q?Qq8hjkAZLgkruPAwHp4kRw4Qe9rBR4dxRkMWxg0FV42a9X2v1DQDuR4sr7/Q?= =?us-ascii?Q?1mBoz+pAfQH1z2kEfSgO8ingGpYuxiABqSmrbeGJHhqA1whbsuTNiIHMeVVe?= =?us-ascii?Q?1Hmese5VW59WXCoabg76fxOzJ9kAwTa2A6d895H0KmmR4wYKw9wBwdSthgTU?= =?us-ascii?Q?SXTjZkNdVLFf2mjj/+MciSc/OrGqNxNSUljrPvWDRNVAnGS3gNUV8RpH7ipL?= =?us-ascii?Q?R6QrcA3U1K3OXrLQIscOmqLgoxfliYhYsdQ64ebg9+Ulve1GzcMPYBBdKixJ?= =?us-ascii?Q?OGCmtwxJ+a5cELdwwcC3dQ7DFFcj+vELtql1ILIZZRXyI/ZsO3f4tsV7K79W?= =?us-ascii?Q?kpoiYP7yoG7jcoSDhKOd0dX37YrfrPBy3tTmE5I/wRhpLlXVfPHB+8Ib6Lkg?= =?us-ascii?Q?r97JOn1Ld99BlHYtfZf/Tt6NbrDvDaa3ucAAeBj/6VD8uuW4eY/0iefNVlwY?= =?us-ascii?Q?/SDZYWVT6zrQXSTMTL7zVvUY8LtjsZNWsO9WRsQnkYjNz8BXOIcTKmQ1yCUA?= =?us-ascii?Q?IOiBdodyoA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a202282e-b4e7-4242-6d7e-08df346e2cf7 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:31.6289 (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: MBxWnP3S97V4PVlBLFuxmSJdV9CoGe44IXZqJtCP+o4FOaRnpU+PrIlDi/gM9Ul9eGpmBw6pkrG1Oz0onkDMlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-d25034/1793135193-01AC4A5B-FC5F4259/0/0 X-purgate-type: clean X-purgate-size: 4185 From: Mirela Simonovic Invoke PSCI SYSTEM_SUSPEND to finalize Xen's suspend sequence on ARM64 platforms. Pass the Xen resume entry point (hyp_resume) to EL3 together with a zero context ID, matching Linux. This patch wires up only the host-side PSCI SYSTEM_SUSPEND invocation. The resume trampoline and context restore are provided by earlier patches in the series. Only enable this path when CONFIG_SYSTEM_SUSPEND is set and PSCI advertises SYSTEM_SUSPEND via PSCI_FEATURES. 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 v13: - Use the result returned by arm_smccc_smc() and drop the result pointer. Changes in v9: - cache SYSTEM_SUSPEND support using PSCI_FEATURES and gate the host call on the cached capability - keep the cached SYSTEM_SUSPEND capability read-only after init - log whether firmware reports SYSTEM_SUSPEND support - pass an explicit zero context ID in the SYSTEM_SUSPEND call - drop the stale note claiming hyp_resume is still a stub --- xen/arch/arm/include/asm/psci.h | 1 + xen/arch/arm/psci.c | 32 +++++++++++++++++++++++++++++++- 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h index 48a93e6b79..bb3c73496e 100644 --- a/xen/arch/arm/include/asm/psci.h +++ b/xen/arch/arm/include/asm/psci.h @@ -23,6 +23,7 @@ int call_psci_cpu_on(int cpu); void call_psci_cpu_off(void); void call_psci_system_off(void); void call_psci_system_reset(void); +int call_psci_system_suspend(void); /* Range of allocated PSCI function numbers */ #define PSCI_FNUM_MIN_VALUE _AC(0,U) diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index 967cb4b77d..4d502216ce 100644 --- a/xen/arch/arm/psci.c +++ b/xen/arch/arm/psci.c @@ -17,23 +17,27 @@ #include #include #include +#include /* * While a 64-bit OS can make calls with SMC32 calling conventions, for * some calls it is necessary to use SMC64 to pass or return 64-bit values. - * For such calls PSCI_0_2_FN_NATIVE(x) will choose the appropriate + * For such calls PSCI_*_FN_NATIVE(x) will choose the appropriate * (native-width) function ID. */ #ifdef CONFIG_ARM_64 #define PSCI_0_2_FN_NATIVE(name) PSCI_0_2_FN64_##name +#define PSCI_1_0_FN_NATIVE(name) PSCI_1_0_FN64_##name #else #define PSCI_0_2_FN_NATIVE(name) PSCI_0_2_FN32_##name +#define PSCI_1_0_FN_NATIVE(name) PSCI_1_0_FN32_##name #endif uint32_t psci_ver; uint32_t smccc_ver; static uint32_t psci_cpu_on_nr; +static bool __ro_after_init has_psci_system_suspend; #define PSCI_RET(res) ((int32_t)(res).a0) @@ -60,6 +64,26 @@ void call_psci_cpu_off(void) } } +int call_psci_system_suspend(void) +{ +#ifdef CONFIG_SYSTEM_SUSPEND + struct arm_smccc_res res; + + if ( !has_psci_system_suspend ) + return PSCI_NOT_SUPPORTED; + + /* Context ID is unused for the Xen resume path. */ + res = arm_smccc_smc(PSCI_1_0_FN_NATIVE(SYSTEM_SUSPEND), + __pa(hyp_resume), 0); + + return PSCI_RET(res); +#else + dprintk(XENLOG_WARNING, + "SYSTEM_SUSPEND not supported (CONFIG_SYSTEM_SUSPEND disabled)\n"); + return PSCI_NOT_SUPPORTED; +#endif +} + void call_psci_system_off(void) { if ( psci_ver > PSCI_VERSION(0, 1) ) @@ -223,9 +247,15 @@ int __init psci_init(void) psci_init_smccc(); + has_psci_system_suspend = + psci_features(PSCI_1_0_FN_NATIVE(SYSTEM_SUSPEND)) == 0; + printk(XENLOG_INFO "Using PSCI v%u.%u\n", PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver)); + printk(XENLOG_DEBUG "PSCI SYSTEM_SUSPEND is %ssupported by firmware\n", + has_psci_system_suspend ? "" : "not "); + return 0; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462589.1673650 (Exim 4.92) (envelope-from ) id 1xLoNT-0008AM-I3; Tue, 27 Oct 2026 21:06:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462589.1673650; Tue, 27 Oct 2026 21:06: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 1xLoNT-00089E-8r; Tue, 27 Oct 2026 21:06:39 +0000 Received: by outflank-mailman (input) for mailman id 1462589; Tue, 27 Oct 2026 21:06:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNR-0007oW-2f for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNQ-0005yu-FU for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:36 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11248-e002-0a2a0a5209dd-0a2a450bd092-28 for ; Tue, 27 Oct 2026 22:06:36 +0100 Received: from [40.107.130.126] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1125c-b7e8-0a2a450b0019-286b827eab37-3 for ; Tue, 27 Oct 2026 22:06:36 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:34 +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.0546.021; Tue, 27 Oct 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=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=eHj/4o0jIJHUP83QMO5YQoUb73DuULqnMNi8QgG7o2VQEzkbQe25S7N7gTByztKNCiFBdCTD+t+FYVWaSpBj7qi5fxI9XBXnU7lbO6IxZwm7wxjiBy5HnmasEkkwp5AMvFXnO7iFBQiqhGiX/3Z0FN9jw5ks9TSjlrx54TjQvbqSRH6UYQ2FfNxXeZRNPz/4hGnrxVCs/uzfsxRT4xGF0VUVWJEyJeiLwqOPgj5IsnKncI0YSm3w4d+L/gqruKEtKavFQpOVZwu7iM03ZpAonLtWGYQmqoFATIpOfn8Wa8v0ip1l+iKlx55ZgzWy1SqA7ejVddzSOc1uiiRImQ+/2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xT5GCqDmrl768f5ZphGBuN37AxCJCJjQBQVm+/ort/M=; b=Y2+A/K0iaOtDoNOh2O4n7+J/2brIAhZwAWxNjF3yWX8360rxzZBAjU12O9Io0V6D2gXlTFFpnSTOqb1cAsa8c/pK2KoPsMH6OIAs/Jh+3vT+07JqLPiry8ggTJPeSjTLL75pcTD9PTwPwU55sWxivSVDoFjhHjA8nhemT0D3yLnv6vjKH/eTmVSZIDCaYdQAoemCPcnoElTOlLhEjoHOCqQFYE0CIzseyEj2mHllFhEpJDbEVPW6phFVqNmv8d9nJw1dGV+zZKo2SLCUnzJReswRUoRwnMR9SlOqHvtHiedAljNnwIUgwBmWq8Sdghx9OCIEqwNAHCHMwMQBSqEIDg== 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=xT5GCqDmrl768f5ZphGBuN37AxCJCJjQBQVm+/ort/M=; b=iF9kdxivMThtNANNQuRz8hOzR5J2h1siffzzdprb7YztVrzvBfBpyTlC0Y231JSGoUdVp2ujiMftB9U9Mn8p+7W/7VmWWlp4908nbLK+BU2UJTpqj9CjRuaaGu86bmYzO75Vs5dDH2ae48h0oY/hJemTOwTDeBIX/SBLb4Da3cKFMDzw2u0AQszj+DkwrUBjS5C0DW9du9G+jop5JnWFCI2yXUtr9/Ko1wd8uUIOO/PZUxs7VAjOmDoLtdoIqpsYOV0HqWup+BcsUSMwlCCcM4fBvZ9QjttTBdiJg79cvEYBTUPzX314NhCcAB682MDlZdwVRXvmRh9PkS20VQoUNQ== 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?= , Mykyta Poturai , Rahul Singh Subject: [PATCH v13 13/14] xen/arm: Add vPSCI SYSTEM_SUSPEND policy Date: Tue, 27 Oct 2026 23:06:02 +0200 Message-ID: <815a067a28bdc1db079cc3ad068e3ef74b7afe5c.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: 6e55ede5-0b4d-429d-7a5f-08df346e2eb1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|7416014|376014|261026121527099003|261022075727099003|11063799006|56012099006|261009223027099003|261009220027099003|261009221727099003|261021123027099003|261009221227099003|261021121427099003|261009223327099003|261022105027099003|22082099003|18002099003|6133799003|10067099003|261026140227099003; X-Microsoft-Antispam-Message-Info: ygahDFycbQFybVG1kS25H67pKEM/YjVxg5i8zFz1XvYu1A0e9PDWWyd6NKR9HYWgXXufrZ5vgkK20wWBQJ1rmWz1aDnvUNHS6Yv3w5C6XyX1Hw2EU1kLh9pt6H8eN+VAvFWMKL2B6OXn9JGSp0PdfpWdBq98jKedVM7N5A76DNvsTg19xylbnDqFj1yYRID87WF+l2X1KoWowJdU9+KJO2jCR911vIGHr1rS4wwNBkyePY5rFeJCJC57Ax4psJyOdjKYkK3Uzqj29NThkaGGld7IquJHhyX5AiGwQvFONmk2mZLfLrS6crZn+wmTk0M6QidTeuNiI/Nxts5CTA9PSjIEkYsQ/1zIxuMy/o5V7u3cFR0MDI89gcnsQHO01VueSqR+vgYbfP30REql/GdtwPCRnIChUY49SbrDMAUZx3IspTfor/S5Xx7xCL5VW5hbELpDXpa1lOasf2XzJFuH3jcDwq/E2DUbJvTcJe7v2yt792JOoLiXL0+Sc5JKPjJiQpcMr6ZOc+pwPF9G5vm3/Hi6g2F58IidBLlT8dzyoye34G5hhiRDukstPaPGcrAWEFInB0PX3lUaNq+/G3m5tYUmi7cYh3Xzsv7lwdTANWi73ZYY9MRKAJR/lkS55lm31gSbOyTiU0kRMoOOPwJLJCX9v9SNu+kBlhjSfh8GqfA= 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)(23010399003)(366016)(1800799024)(7416014)(376014)(261026121527099003)(261022075727099003)(11063799006)(56012099006)(261009223027099003)(261009220027099003)(261009221727099003)(261021123027099003)(261009221227099003)(261021121427099003)(261009223327099003)(261022105027099003)(22082099003)(18002099003)(6133799003)(10067099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yD/406x+/2FaDzjzHES+MirkmpirrMpHkBe33T8xIQ2fhMlYV/q7t5LeZbvC?= =?us-ascii?Q?UXZh9CoAzxoRTfRuzY5oDDMop3o7NcDyIz89k8/V8F4dEa0U7sys2nXa/ANa?= =?us-ascii?Q?yUfPaoJOGl8EtR5H3OsyNmEVhJArofOtw9TNPPu+tgnd34ojmVnh0pDhkH2D?= =?us-ascii?Q?VErEMLIxVRvqyw3fJmUMpXvxai7GHPURVNgDue08nJNa3HeoJTPu5umHwRCp?= =?us-ascii?Q?yCxAR7Wtj2SjCXBBqa5DZT+VkycRievxi18TaCRej6c/pwJwsgnhlsmzW6Kl?= =?us-ascii?Q?D6CQ/JzU6K57l3/Iw4V+k2yeXVgjRAwK1dnzHYUBMmRv37iYenEhTng0w8Vh?= =?us-ascii?Q?gdtD1uAKpFqFDk33KC6AEbQT7i4OjS4Il9hIdNG5k9BUQmhq0L8Xc/AczFP/?= =?us-ascii?Q?9pGe5MgMAA3y+Un+8nkYdiYlynIjRzpmsA0JtWYr7akYsD222xz38/vBM15c?= =?us-ascii?Q?V1Eh2+W7Xl1/aJxGIE0yznBjZYdCMTio7UOtwhA6bB4TLDiSA1qV3qoYPEPM?= =?us-ascii?Q?ezORP6vimaZJYYs/sJthMXJ296MGkmROU7Mhq445AxgHVIaShx5nDr7vxQkp?= =?us-ascii?Q?GG/XEQcasJ8Rogoni5Td25X2f3fmjcEw+vtaM2nHnFv4TxYBz0WLRlK4wfnE?= =?us-ascii?Q?WgtlXX36mkaAtllsO8OdH+hY64FZyCPBRU3wlVL+1jsNxVM5CO99VNnz5yXG?= =?us-ascii?Q?zEDkf0CpoQkwmZeJyaHGNyNvOykbVnSXj6eqEwXstX+NYFZNGYiezdMTb79S?= =?us-ascii?Q?8zs+ebb8VgQOznUo4N3qd/9Pym/KNBBADT7N9CPsfey9D2uKPuytBHYmdv+4?= =?us-ascii?Q?LTuOHSy95p3Ms1SbBPg3dmv6v99GeVmWCHr/MVNMioB3C8YVbkyxZZcrgwGp?= =?us-ascii?Q?zkSHE5zvqZEXkDxdPLyMoTdxUecKB7HlKUwqx5PgC1Agyq6Sby+djq5NH4Re?= =?us-ascii?Q?JLjC9FFrLrv+BQQvj6oSP0pWkauj4eOT+o8Nr9KD4k2FSkKDnRVWLQAp1QNY?= =?us-ascii?Q?o9UbrYeL9YLHVyYvxVf/Jvgja6i9IgC6q8BuGcLf71WCulOkHjT3t5CWF1Lq?= =?us-ascii?Q?F+8SgyFXoWYxpd87XAWINfh3EO4j+J7/kLVpYKo8xBGDMtW6jxHY4eHgN8uu?= =?us-ascii?Q?5YGCqebwvX6RtiwfwK2vUmVuyv+OqDTJPla1F0mKz/SZL5m3s76bUT2+/1zh?= =?us-ascii?Q?D8i2w3g2Fv6i5ReNP+I2h5A4Hprt8ldHFw425LlGbzIuub6SEeUK0jJnfENY?= =?us-ascii?Q?2JTU+tG3Por2YBwwYq8ul3ojoS0WXbusfxM8kur4JDWBXFcJRedomBeR7nwY?= =?us-ascii?Q?gOSVgjy2H3H6KR/BRhqHfZ8FxqRfZ2/8FwzsI6jgnjdze7DSYUlB/PvSjl0d?= =?us-ascii?Q?RzisT7ob2zA1958WYlfaMmlq11LYUWwqoX5mfEL6ZKY5GJRQE241e7dRNmct?= =?us-ascii?Q?FqJ38H8DbgeWGccn4c7gXVnV1tC21YFCt5+nNrf9JH21Oxr8bwC65GQbyyTf?= =?us-ascii?Q?8aujvLpCnvAZXeFW3qjZEbfegQxQTlVjoiksKglJCBi6xx6BCZE4eLsdw6+1?= =?us-ascii?Q?gxlGCDu1RaH17rPL9CYVhnlJEC/XT0ghHKzORzpyFYlNCaji/QsQL2vjPjxy?= =?us-ascii?Q?UthNZW5CMYnDmHr8boZnaT28QwBlew9u1TgcY7CDJwdtTuO0QWc/bYRrBSJF?= =?us-ascii?Q?nZZmo1J6mssDpLPc0hnUDOSMLce4ahKdBGhCgb6lNlo0NjicevpbL3/5pRnW?= =?us-ascii?Q?DM6oHsrGwQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6e55ede5-0b4d-429d-7a5f-08df346e2eb1 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:34.5407 (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: ovWMaKePMFejyf9be3rdGAW2uTsFnUOUB18VVcHTjEQRtl22r/KEus+tSvAflW3fw5CnEmwWEyZPmMoMBC/48Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-42698a/1793135196-19EC69EA-9E446406/0/0 X-purgate-type: clean X-purgate-size: 19873 Introduce CONFIG_HAS_HWDOM_SYSTEM_SUSPEND as an architecture-selected capability for platforms where the hardware domain can be parked with SHUTDOWN_suspend without calling hwdom_shutdown(). Expose PSCI SYSTEM_SUSPEND as a vPSCI operation for all domains. For non-control domains, including the hardware domain when it is not acting as a control domain, the call is handled as a guest/domain suspend request and parks the domain in SHUTDOWN_suspend. A non-control domain can suspend only while a control domain exists to resume it using XEN_DOMCTL_resumedomain. Return PSCI_DENIED otherwise, including in a dom0less setup with no control domain. Control domains need additional sequencing because their SYSTEM_SUSPEND request is used to coordinate host-wide suspend. A non-last awake control domain may be parked in SHUTDOWN_suspend without requiring the host suspend path to be available. The last awake control domain is treated as the point where the request becomes a host-suspend request, and it may only proceed when all non-control domains are already in SHUTDOWN_suspend and the host suspend path is available. Keep the control-domain sequencing and domain-readiness checks out of PSCI_FEATURES. They are per-attempt runtime conditions rather than stable PSCI function availability. Advertise SYSTEM_SUSPEND as implemented by vPSCI and report attempt-time policy failures as PSCI_DENIED. Select HAS_HWDOM_SYSTEM_SUSPEND independently from CONFIG_SYSTEM_SUSPEND so that SHUTDOWN_suspend from the hardware domain can be treated as a domain suspend state rather than as a hardware-domain initiated host shutdown. This does not by itself imply that host-wide suspend is available. Add host_system_suspend_allowed() to combine the host PSCI SYSTEM_SUSPEND capability with runtime blockers reported by Xen-owned subsystems. Add runtime blockers for registered serial, IOMMU, GIC and SMMUv3 MSI IRQ paths lacking suspend/resume support. These blockers are runtime based, so they only apply to drivers or paths that Xen actually uses on the platform. For SMMUv3, the blocker applies only when Xen actually uses the MSI IRQ path, since resume does not restore the SMMU *_IRQ_CFGn MSI registers yet. Block host suspend when Xen uses an R-Car Gen4 PCIe controller. The PCIe BDF-to-OSID registers are not saved and restored yet. This does not affect normal IPMMU use or guest-only suspend. Add a struct domain forward declaration to xen/suspend.h so the generic header can expose arch_domain_resume() without requiring a full domain.h include. Signed-off-by: Mykola Kvach --- Changes in V13: - Block host suspend when Xen uses an R-Car Gen4 PCIe controller, since PCIe OSID state is not restored. - Deny guest SYSTEM_SUSPEND when no control domain exists to resume it. - Split the long suspend-state check across two lines. Changes in V12: - handle missing is_shut_down, change checking to call of domain_shutdown_completed Changes in V11: - Mark host_system_suspend_runtime_allowed as __ro_after_init. - Avoid printing the SMMUv3 MSI IRQ host suspend blocker more than once when multiple SMMUv3 instances use MSIs. - Wrap the Arm IOMMU host suspend blocker in CONFIG_SYSTEM_SUSPEND to make its policy-only use explicit. Changes in V10: - Return PSCI_DENIED rather than PSCI_NOT_SUPPORTED when the last awake control domain cannot proceed to host suspend, keeping PSCI_FEATURES stable once SYSTEM_SUSPEND is advertised. - Shorten SYSTEM_SUSPEND blocker messages and use %pd when logging the control domain. - Mark serial_suspend_available as __ro_after_init. - Mention the struct domain forward declaration added to xen/suspend.h. Changes in V9: - Select HAS_HWDOM_SYSTEM_SUSPEND independently from CONFIG_SYSTEM_SUSPEND so that hardware-domain SHUTDOWN_suspend support is not tied to host-wide system suspend availability. - Add runtime host suspend blockers for Xen-owned subsystems lacking suspend/resume support. - Keep vPSCI SYSTEM_SUSPEND advertised through PSCI_FEATURES and enforce control-domain sequencing in the call handler. --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/gic.c | 6 ++ xen/arch/arm/include/asm/psci.h | 3 + xen/arch/arm/include/asm/suspend.h | 10 ++- xen/arch/arm/pci/pci-host-rcar4.c | 4 + xen/arch/arm/psci.c | 7 ++ xen/arch/arm/suspend.c | 40 +++++++++ xen/arch/arm/vpsci.c | 119 +++++++++++++++++++++++--- 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/smmu-v3.c | 9 ++ xen/include/xen/serial.h | 1 + xen/include/xen/suspend.h | 2 + 15 files changed, 217 insertions(+), 13 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index b9c5c40678..fd5f0ddb17 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_HWDOM_SYSTEM_SUSPEND if !MPU select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE select HAS_SHARED_INFO select HAS_STACK_PROTECTOR diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 30087b5938..3fb0a56d94 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -44,6 +45,11 @@ static void __init __maybe_unused build_assertions(void) void register_gic_ops(const struct gic_hw_operations *ops) { gic_hw_ops = ops; + +#ifdef CONFIG_SYSTEM_SUSPEND + if ( !ops->suspend || !ops->resume ) + host_system_suspend_disable("GIC driver lacks suspend support"); +#endif } static void clear_cpu_lr_mask(void) diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h index bb3c73496e..142fa1bfe5 100644 --- a/xen/arch/arm/include/asm/psci.h +++ b/xen/arch/arm/include/asm/psci.h @@ -24,6 +24,9 @@ void call_psci_cpu_off(void); void call_psci_system_off(void); void call_psci_system_reset(void); int call_psci_system_suspend(void); +#ifdef CONFIG_SYSTEM_SUSPEND +bool psci_system_suspend_allowed(void); +#endif /* Range of allocated PSCI function numbers */ #define PSCI_FNUM_MIN_VALUE _AC(0,U) diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h index c848fc6340..50dc6e9fdf 100644 --- a/xen/arch/arm/include/asm/suspend.h +++ b/xen/arch/arm/include/asm/suspend.h @@ -39,7 +39,15 @@ extern struct resume_cpu_context resume_cpu_context; int prepare_resume_ctx(void); void hyp_resume(void); -#endif /* CONFIG_SYSTEM_SUSPEND */ +bool host_system_suspend_allowed(void); +void host_system_suspend_disable(const char *reason); + +#else /* !CONFIG_SYSTEM_SUSPEND */ + +static inline bool host_system_suspend_allowed(void) { return false; } +static inline void host_system_suspend_disable(const char *reason) {} + +#endif #endif /* ARM_SUSPEND_H */ diff --git a/xen/arch/arm/pci/pci-host-rcar4.c b/xen/arch/arm/pci/pci-host-rcar4.c index e1e8eb0ee1..0d85ccf4f5 100644 --- a/xen/arch/arm/pci/pci-host-rcar4.c +++ b/xen/arch/arm/pci/pci-host-rcar4.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "pci-designware.h" #include "pci-host-rcar4.h" @@ -221,6 +222,9 @@ static int __init pci_host_rcar4_probe(struct dt_device_node *dev, dw_pcie_set_priv(bridge, priv); dw_pcie_set_version(bridge, RCAR4_DWC_VERSION); + host_system_suspend_disable( + "R-Car Gen4 PCIe OSID state is not restored"); + return 0; err: xfree(priv); diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index 4d502216ce..187cad44d5 100644 --- a/xen/arch/arm/psci.c +++ b/xen/arch/arm/psci.c @@ -41,6 +41,13 @@ static bool __ro_after_init has_psci_system_suspend; #define PSCI_RET(res) ((int32_t)(res).a0) +#ifdef CONFIG_SYSTEM_SUSPEND +bool psci_system_suspend_allowed(void) +{ + return has_psci_system_suspend; +} +#endif + int call_psci_cpu_on(int cpu) { struct arm_smccc_res res; diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c index 6ea4a0f9cc..c7c26bcf03 100644 --- a/xen/arch/arm/suspend.c +++ b/xen/arch/arm/suspend.c @@ -1,9 +1,49 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include +#include +#include + struct resume_cpu_context resume_cpu_context; +/* + * Non-PSCI infrastructure can make host suspend impossible even when the PSCI + * SYSTEM_SUSPEND conduit is present, e.g. when a Xen-owned driver has no valid + * suspend/resume path. + * + * This gate is checked only when the last awake control domain attempts to + * turn a guest SYSTEM_SUSPEND request into a host-suspend request. + */ +static bool __ro_after_init host_system_suspend_runtime_allowed = true; + +static bool host_serial_suspend_allowed(void) +{ + if ( serial_suspend_supported() ) + return true; + + printk_once(XENLOG_INFO + "Host SYSTEM_SUSPEND blocked: serial unsupported\n"); + + return false; +} + +bool host_system_suspend_allowed(void) +{ + return psci_system_suspend_allowed() && + host_serial_suspend_allowed() && + host_system_suspend_runtime_allowed; +} + +void host_system_suspend_disable(const char *reason) +{ + host_system_suspend_runtime_allowed = false; + + printk(XENLOG_INFO "Host SYSTEM_SUSPEND blocked: %s\n", + reason ? reason : "unsupported suspend/resume path"); +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c index ac6af6118f..0131c297dd 100644 --- a/xen/arch/arm/vpsci.c +++ b/xen/arch/arm/vpsci.c @@ -5,6 +5,7 @@ #include #include +#include #include #include #include @@ -219,6 +220,94 @@ static void do_psci_0_2_system_reset(void) domain_shutdown(d,SHUTDOWN_reboot); } +/* + * Serialise SYSTEM_SUSPEND policy decisions with the domain suspend transition, + * so multiple control domains cannot all observe each other as still awake. + */ +static DEFINE_SPINLOCK(vpsci_system_suspend_lock); + +static bool domain_in_suspend_state(struct domain *d) +{ + bool suspended; + + spin_lock(&d->shutdown_lock); + suspended = domain_shutdown_completed(d) && + (d->shutdown_code == SHUTDOWN_suspend); + spin_unlock(&d->shutdown_lock); + + return suspended; +} + +static int32_t domain_psci_system_suspend_policy(struct domain *d) +{ + struct domain *other; + bool last_awake_control_domain = true; + bool awake_non_control_domain = false; + bool has_control_domain = is_control_domain(d); + + rcu_read_lock(&domlist_read_lock); + + for_each_domain ( other ) + { + bool suspended; + + if ( other == d ) + continue; + + if ( is_control_domain(other) ) + has_control_domain = true; + + suspended = domain_in_suspend_state(other); + if ( suspended ) + continue; + + if ( is_control_domain(other) ) + { + last_awake_control_domain = false; + break; + } + + awake_non_control_domain = true; + } + + rcu_read_unlock(&domlist_read_lock); + + /* Non-control domains need a control domain to resume them. */ + if ( !is_control_domain(d) ) + return has_control_domain ? 0 : PSCI_DENIED; + + /* + * Another control domain is still awake. This request is only the first + * phase of the sequencing: park this control domain and leave the host + * running. Host-wide suspend gates must not block this intermediate state. + */ + if ( !last_awake_control_domain ) + return 0; + + /* + * This is the last awake control domain. It must not be parked unless the + * request can proceed as a host-suspend request; otherwise Xen would lose + * the last domain that can coordinate the system suspend. + */ + if ( awake_non_control_domain ) + { + printk(XENLOG_DEBUG + "SYSTEM_SUSPEND denied for %pd: non-control domains awake\n", + d); + return PSCI_DENIED; + } + + /* + * Host-wide gates are relevant only for the last-control-domain case. They + * must not block parking of a non-last control domain, but they must deny + * the last control domain when host suspend is not currently available. + */ + if ( !host_system_suspend_allowed() ) + return PSCI_DENIED; + + return 0; +} + static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) { int32_t rc; @@ -232,10 +321,6 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) if ( is_64bit_domain(d) && is_thumb ) return PSCI_INVALID_ADDRESS; - /* SYSTEM_SUSPEND is not supported for the hardware domain yet */ - if ( is_hardware_domain(d) ) - return PSCI_NOT_SUPPORTED; - /* Ensure that all CPUs other than the calling one are offline */ domain_lock(d); for_each_vcpu ( d, v ) @@ -252,16 +337,29 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) if ( rc ) return PSCI_DENIED; - rc = domain_shutdown(d, SHUTDOWN_suspend); + spin_lock(&vpsci_system_suspend_lock); + + rc = domain_psci_system_suspend_policy(d); + if ( !rc ) + { + rc = domain_shutdown(d, SHUTDOWN_suspend); + if ( rc ) + rc = PSCI_DENIED; + else + { + rctx->ctxt = ctxt; + rctx->wake_cpu = current; + } + } + + spin_unlock(&vpsci_system_suspend_lock); + if ( rc ) { free_vcpu_guest_context(ctxt); - return PSCI_DENIED; + return rc; } - rctx->ctxt = ctxt; - rctx->wake_cpu = current; - gprintk(XENLOG_DEBUG, "SYSTEM_SUSPEND requested, epoint=%#"PRIregister", cid=%#"PRIregister"\n", epoint, cid); @@ -287,10 +385,9 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id) case PSCI_0_2_FN32_SYSTEM_RESET: case PSCI_1_0_FN32_PSCI_FEATURES: case ARM_SMCCC_VERSION_FID: - return 0; case PSCI_1_0_FN32_SYSTEM_SUSPEND: case PSCI_1_0_FN64_SYSTEM_SUSPEND: - return is_hardware_domain(current->domain) ? PSCI_NOT_SUPPORTED : 0; + return 0; default: return PSCI_NOT_SUPPORTED; } diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 5b289e444f..0a3e5d8a93 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -140,6 +140,9 @@ config HAS_EX_TABLE config HAS_FAST_MULTIPLY bool +config HAS_HWDOM_SYSTEM_SUSPEND + bool + config HAS_IOPORTS bool diff --git a/xen/common/domain.c b/xen/common/domain.c index b41be89cd0..eac94cb888 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -1377,6 +1377,11 @@ void __domain_crash(struct domain *d) domain_shutdown(d, SHUTDOWN_crash); } +static inline bool want_hwdom_shutdown(uint8_t reason) +{ + return !IS_ENABLED(CONFIG_HAS_HWDOM_SYSTEM_SUSPEND) || + reason != SHUTDOWN_suspend; +} int domain_shutdown(struct domain *d, u8 reason) { @@ -1393,7 +1398,7 @@ int domain_shutdown(struct domain *d, u8 reason) d->shutdown_code = reason; reason = d->shutdown_code; - if ( is_hardware_domain(d) ) + if ( is_hardware_domain(d) && want_hwdom_shutdown(reason) ) hwdom_shutdown(reason); if ( domain_shutting_down(d) ) diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c index cf0abf1893..1cdf4968ac 100644 --- a/xen/drivers/char/serial.c +++ b/xen/drivers/char/serial.c @@ -490,6 +490,8 @@ const struct vuart_info *serial_vuart_info(int idx) #ifdef CONFIG_SYSTEM_SUSPEND +static bool __ro_after_init serial_suspend_available = true; + void serial_suspend(void) { int i; @@ -506,6 +508,11 @@ void serial_resume(void) com[i].driver->resume(&com[i]); } +bool serial_suspend_supported(void) +{ + return serial_suspend_available; +} + #endif /* CONFIG_SYSTEM_SUSPEND */ void __init serial_register_uart(int idx, struct uart_driver *driver, @@ -514,6 +521,11 @@ void __init serial_register_uart(int idx, struct uart_driver *driver, /* Store UART-specific info. */ com[idx].driver = driver; com[idx].uart = uart; + +#ifdef CONFIG_SYSTEM_SUSPEND + if ( !driver->suspend || !driver->resume ) + serial_suspend_available = false; +#endif } void __init serial_async_transmit(struct serial_port *port) diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c index 100545e23f..461e01703e 100644 --- a/xen/drivers/passthrough/arm/iommu.c +++ b/xen/drivers/passthrough/arm/iommu.c @@ -19,6 +19,7 @@ #include #include #include +#include #include @@ -46,6 +47,11 @@ void __init iommu_set_ops(const struct iommu_ops *ops) } iommu_ops = ops; + +#ifdef CONFIG_SYSTEM_SUSPEND + if ( !ops->suspend || !ops->resume ) + host_system_suspend_disable("IOMMU driver lacks suspend support"); +#endif } int __init iommu_hardware_setup(void) diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c index 58530ef2d1..247c6156cc 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.c +++ b/xen/drivers/passthrough/arm/smmu-v3.c @@ -91,6 +91,7 @@ #include #include #include +#include #include "smmu-v3.h" @@ -1888,6 +1889,7 @@ static void arm_smmu_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg) static void arm_smmu_setup_msis(struct arm_smmu_device *smmu) { + static bool __ro_after_init host_suspend_blocked_by_msi; struct msi_desc *desc; int ret, nvec = ARM_SMMU_MAX_MSIS; struct device *dev = smmu->dev; @@ -1926,6 +1928,13 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu) } } + if ( !host_suspend_blocked_by_msi ) + { + host_suspend_blocked_by_msi = true; + host_system_suspend_disable( + "SMMUv3 MSI IRQ path is unsupported for host suspend"); + } + /* Add callback to free MSIs on teardown */ devm_add_action(dev, arm_smmu_free_msis, dev); } diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h index 3a71da767d..4c6f891221 100644 --- a/xen/include/xen/serial.h +++ b/xen/include/xen/serial.h @@ -137,6 +137,7 @@ const struct vuart_info* serial_vuart_info(int idx); /* Serial suspend/resume. */ void serial_suspend(void); void serial_resume(void); +bool serial_suspend_supported(void); #endif /* diff --git a/xen/include/xen/suspend.h b/xen/include/xen/suspend.h index 6f94fd53b0..a941331035 100644 --- a/xen/include/xen/suspend.h +++ b/xen/include/xen/suspend.h @@ -6,6 +6,8 @@ #if __has_include() #include #else +struct domain; + static inline void arch_domain_resume(struct domain *d) {} #endif -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 21:06:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 21:06:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462592.1673657 (Exim 4.92) (envelope-from ) id 1xLoNV-0008UT-GH; Tue, 27 Oct 2026 21:06:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462592.1673657; Tue, 27 Oct 2026 21: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 1xLoNV-0008Sb-5v; Tue, 27 Oct 2026 21:06:41 +0000 Received: by outflank-mailman (input) for mailman id 1462592; Tue, 27 Oct 2026 21:06:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLoNS-00085c-LD for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 21:06:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLoNS-007u3c-28 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:06:38 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae11233-2eae-0a2a0a5409dd-0a2a4507c680-42 for ; Tue, 27 Oct 2026 22:06:38 +0100 Received: from [40.107.130.85] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1125d-b4ea-0a2a45070019-286b82552197-3 for ; Tue, 27 Oct 2026 22:06:37 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by PAVPR03MB9573.eurprd03.prod.outlook.com (2603:10a6:102:302::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Tue, 27 Oct 2026 21:06:36 +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.0546.021; Tue, 27 Oct 2026 21:06: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=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=iZRdjOFKhawXkfnZhLJDsafjLBDIu6nf+o8x/PLSgFHj4CZ7dibFD4bFAluCqxuAP/qIg9A9W/4UBXHGd6z48DefumYHHdtuxPyJo+pPERGVfWtxIENl6sX/8tZk0zXRmtovgiFN5Ji5MRm/d8fS0WbQN/OtUID5b4ZM9s5SW1sKcL8DMDxut8SFz2WEgV7ECiVjOIBWWxWMY2c08npzPhz3xyhOx19yC+/zyDM7ePlc+P49gT6Gj28aw8o5mJyB8U13U7DfHcZz7JNvknrP1kAP60LK877o+ZXhR4OvyoQNfkVr1ondUxYUlVXg/Hw9NCpr9pHzvIOi2iSBf8vZkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GQmpjK2V4h/9sztcZmJlhw/is8rEdP0Ax+FFiJZjMgo=; b=t15H9m/S5R8W0q7Sxpx3M/gQajtB8JuvrI7TEIac0JjAaaPlyVZ+wohm7+ASNlsSQMaOhdeh4VGERNK7H1fQt1TPuevQLaX3SHbIDrWKkvghvElayXuw7AggYO4ZvORwGYffiCqE38HQnZsisQihs5L62k06tCpf4OlXlBtC3orbpNr6eZlUjob83J7D5yqrYnr3HT/6uTQdcA4m1IuLZdWZJnf/1rba+w8nCVc6lflpqFYpme47MI7cPpjUghuulmJB9igGwvKEpcF2k+tDUmxBcs+0Rb+6dGszO2MyphxwYmm+LU4HbK2NkqgRKFbKzq+OGqt9IYLDeejRK0pJNQ== 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=GQmpjK2V4h/9sztcZmJlhw/is8rEdP0Ax+FFiJZjMgo=; b=XTu37wpUEuJrUH0Uklxj+FF993BR50y9iD6Wx/yK1F+8AIwUl/9YzRJPgmFzMSer8kSzJexdc2UZGLF6QwvazJGzNYPCWncdrjkMp51bhDiL/ULVu4IkfHMJ9s4bJyzjXZ0BD+k9KrIzE5uHui4OdySKwKvsaYGyKr7lT/Nfz92yCCBG+HgSlM66So2vV9XzRk/2lh41WIMzi9xofuZKXAOYHeiuZUcDaGo9z+Geho0gjj/FhhlSwh5Leef2x0aJSZIqyhjbd8WAQoy0CEw/iouGPxcoAue7fu39oemh3foEs3a5arfekse5WTHZULBZ/llJT330+3Ga0A6P6pVIKg== 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: Mirela Simonovic , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai Subject: [PATCH v13 14/14] xen/arm: Add host system suspend backend Date: Tue, 27 Oct 2026 23:06:03 +0200 Message-ID: <2299a3912c0491680b15d10a39ec5ec7e041a390.1793129971.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: FR4P281CA0223.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::6) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|PAVPR03MB9573:EE_ X-MS-Office365-Filtering-Correlation-Id: 0535fc5f-db4c-4188-55fb-08df346e2fc2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|261026121527099003|261022075727099003|11063799006|5023799004|56012099006|261009223027099003|261021123027099003|261021121427099003|261022105027099003|22082099003|18002099003|6133799003|10067099003|3023799007|261026140227099003; X-Microsoft-Antispam-Message-Info: gLtR59tFu9U/ZV4CfjQNXR1DKnPOoe6RE5jIlfTtqFo0YYjwM4a+bRgc/oSPDWKk0sSIw23i3o4eo9OXdlwbKksUUSve9xHnEQj4Jx+vm5oyaxlpuSPdK4G8MGMYmWBnQGTPmMbn5IT2yEhuVwrZOK7vnKVqMIR9DJ+S+xrBaIhEQhFFOopV3QaRyKE0Zk4hCZpMV4WNf+C+pft7Uwq+tjvDu2xh2loY1l4WMv8NxfmeNvvUz7iN+oWQ0KqfgXn19b7yj6UQ9Unqxtrei1Xl1ToZNiNs8H7K8Hx7qHLlgqdHSQl/Nq2Ya/cupE/EtzSl9RaRgUH+YDxirmiP1BS6bXZZkDGJb3mABmIgyNas85fky/e3JWgq3izFcF+t5LXtVioj100gIOfgWP+yiBVeKsHES2qsXrsEqUUewO/HIMPSnvF33rQsP9YmY53o6/lz+TEZJ+/lkQvh/clD3MFVTmvgu9jd8id/yQfM88UEzSsk0qngK75hoWgH6ZXSlfmumThR6PQN9Q7bqejLZLOa9v6+zNw2KNAM//U/tZeC4sjOWKQ1o4IQ0sdnuAhH6QlAuhuzpPC5YPzV+1aUH4mzO5fLLoa3Ccsr96crH/vO7zamqgVlqm00g32W8opzs+mApDWrosEGIeBWiJulSRoFok8IaAHA8wasxuCW40LFScE= 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)(23010399003)(366016)(1800799024)(376014)(261026121527099003)(261022075727099003)(11063799006)(5023799004)(56012099006)(261009223027099003)(261021123027099003)(261021121427099003)(261022105027099003)(22082099003)(18002099003)(6133799003)(10067099003)(3023799007)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?IJ+RW1tqbAx50Ul/tN1PsMiwb8A5DXGhEnNTBl6ha23IUz38Oj0SR6u7rUF+?= =?us-ascii?Q?GRPrRqorl41jqfosIhniZJCga/d1TWCRkq4/3piD48PQy8OLs/HtFw3DiGpR?= =?us-ascii?Q?jDiCX+Uh0R0ARg8h5PI22KNR32cZrNxAmlGrk6xQ7Oub0ns3iS28Q2iTqgYs?= =?us-ascii?Q?IqFlzJ1pU1KQLIP0gr+SLGafD9Ku8LaRgLYN4soc1xhpVyWQJ7ZIlSPnxTGi?= =?us-ascii?Q?J8hszUJpb5nBPD4z46pMZNIPnArTdJ9UOZ8X6FEbaSq3xi60h91sEzoRCb6A?= =?us-ascii?Q?55/d1BNvrAvpGwuHbYu5rBfyETVInaZ6bei6Y9ss/L8xm4y/+63Gq4p1dtuH?= =?us-ascii?Q?sBdY2SZW5ER5rmeYA0eui8fiekSbgOSswIStVhXtG+mpfeQbVdlB+qZt9L0o?= =?us-ascii?Q?2SA2T6Ato3e4PfhpWVCyBnho3V6Fq640JNOqQOBx6oUpMlmtJ89RjjFyadPj?= =?us-ascii?Q?wtnLImRgfTFDx70f++3eb+HimMN9uSTtZzfvjBmsByd3G/LFuLvm8u/qpnzH?= =?us-ascii?Q?301wUvhkMbBVMS5+AzGWVHhnzm7trCOnoYk1o9XMFcwC49UDgBnWChzH8AAg?= =?us-ascii?Q?A463kvuLECD2CO+DM/6XyrMFQRkU63gQ1hOqkPu4Evzrl1Uy9ckj34Hkh8uS?= =?us-ascii?Q?HtsqvSP3CHWz68wIoc91j5yCrN1U/sC7gsRuTeHBKfGE3dY3YVAgruC6FIsu?= =?us-ascii?Q?pIznzQtIaE4CabfAXRWTO2dDglJaJxi3H6COReHYNgT0fCq1S2gEvKA5HkUU?= =?us-ascii?Q?+5/uWaJxsKc7/Lmpby78WjmdaxejHTJOOqcAHTc/PtTjxma+dZxuJ3iHf5+X?= =?us-ascii?Q?TKmtCgDUmJqdGzo7SFSLGC+KhXxuwgVB6/7gQBFrVYtiX0G5RaOz7bapDdrQ?= =?us-ascii?Q?1+ft/SfE4k5VPTHjVodnwErpgOKQsev52byCoccyeuXhsIYegrEC4rxEV6UX?= =?us-ascii?Q?qePplF4MvSIC0IwJ56PZkR1GRhBDV2TK4SrLnMsUH3mtUzh0q924eSs2UdGg?= =?us-ascii?Q?zBdcDv3xU1ifZjCT0+rUgo5DoNkKUB1iGF/G++e0UArjrjGKldQbijCDIgLt?= =?us-ascii?Q?cZHP/YNlqVSKbgrb4kHrBiShZD6SfSkTrGoxYyA3pv1WNdXFxYgwmnyk6xwa?= =?us-ascii?Q?zT7ERfke4OdqMkD2aaWwkQ61hlHvhCp+E11yGL66vu00KkfhYuYXDRPc+niu?= =?us-ascii?Q?4kr4wgi71uUfG4bPJe03Ir/RudDsuz3R6jR8u+cl7Cju4Rrmy3BtnEvYwrPW?= =?us-ascii?Q?aseLVu1EGH+v8RveVjUSy3RLFbiI5qVgW/AL4yWQ3e3XM9F4hxvxwscz91XQ?= =?us-ascii?Q?r1CwxB4147VfCxTwxDhZdV6iRunE07I3LmP/E+btZBKDcAneoZDQhZLGmPAp?= =?us-ascii?Q?RBWBezOnjgW7Yha9ZYcBuT6yxsnvQ3QUMbtYj4pPD8ZwpPHvSxQwzTz3bzx3?= =?us-ascii?Q?Y40XX2/pDSiTc9O2rgC8z9taDGUH0KvwcIGyCNY3yNRDCHfEf3lGaSmpBy2t?= =?us-ascii?Q?T8gw8Re+QTjclhn52JrNAlttiOPDyIo+D84+5OvHFUtSu0PQo6RBu3LawuGO?= =?us-ascii?Q?tGMeSeBKgq7NbHRPJ3chpVT6ksYfqlv7HFB4yBHNrbN7xj0VjgxYqhX1zQgR?= =?us-ascii?Q?WxK0UK4DZlq78khOTHgbn+s6rpeWz4O3q/iTjZRvbI35osuludWtgNW7d5V4?= =?us-ascii?Q?vLlHESgBt7JjNqEr9DIoQVayyD0nNX8Xmy4UNwoCc6Q5KV581HSL6LlCZv5Z?= =?us-ascii?Q?OeaE077/JA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0535fc5f-db4c-4188-55fb-08df346e2fc2 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 21:06:36.3462 (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: 4b8swPxT+NwSkXSzJfWxb2sXjIBU1JIoKLuTbIpULV/vu1VVRjz07NA7GTNtG6ISQ3llBzPQkMab80EKIARLqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9573 X-purgate-ID: tlsNG-ef75cf/1793135198-348C9AE4-BEC97DEA/0/0 X-purgate-type: clean X-purgate-size: 13960 From: Mirela Simonovic Add the Xen-wide suspend/resume backend used after a control-domain vPSCI SYSTEM_SUSPEND request has been accepted. The vPSCI policy, runtime driver blockers and control-domain sequencing checks are handled by the preceding commit; this change adds the code that actually drives the host suspend attempt. The backend runs from a tasklet scheduled on pCPU0, because non-boot CPUs are disabled during suspend. It freezes domains, disables the scheduler and then disables non-boot CPUs. Host-side suspend participants are handled in phases. IOMMU and console state are suspended first. Local IRQs are then disabled before suspending timer and GIC state. On resume or failure, the completed suspend phases are unwound in reverse: GIC and timer state are restored while IRQs are still disabled, local IRQs are restored, and then console and IOMMU state are restored. On boot, init_ttbr is normally initialized during secondary CPU hotplug. On uniprocessor systems this can leave init_ttbr uninitialized, so set it from the boot CPU before entering suspend. Note: the code is behind CONFIG_HAS_SYSTEM_SUSPEND, which is currently only selected when UNSUPPORTED is set and MPU is not set. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in V13: - Explicitly discard console_resume()'s return value. It always returns zero in the current implementation (MISRA Rule 17.7). No functional change. - Remove the redundant rcu_barrier() and its outdated comment before enable_nonboot_cpus(). Per-CPU areas are kept during suspend, and cpu_up() already waits for pending RCU callbacks before CPU_UP_PREPARE. Changes in V10: - Re-apply boot CPU local errata/workaround handling after SYSTEM_SUSPEND, before resuming the rest of the host suspend path. - Move set_init_ttbr() declaration to asm/mmu/mm.h, since it is MMU-specific. Changes in V9: - Split vPSCI availability policy, runtime host-suspend blockers and the domain-readiness precheck into the preceding commit. - Trigger the host suspend backend from the control-domain SYSTEM_SUSPEND path. - Reorder the host suspend/resume phases so the timer is suspended with local IRQs disabled and local IRQs are restored after the GIC and timer resume paths, before the console and IOMMU resume paths. - Move HAS_HWDOM_SYSTEM_SUSPEND and related logic to policy patch. Changes in V8: - Add a pre-suspend check in system_suspend() after scheduler_disable() to require all domains to be in the shut down state with SHUTDOWN_suspend before proceeding with the global suspend flow. - Drop the common-level depends on !ARM_64 || !SYSTEM_SUSPEND from CONFIG_HAS_HWDOM_SHUTDOWN_ON_SUSPEND and model the ARM64 suspend case with an arch-selected capability instead. - Rename CONFIG_HAS_HWDOM_SHUTDOWN_ON_SUSPEND to CONFIG_HAS_HWDOM_SYSTEM_SUSPEND. - Rename need_hwdom_shutdown() to want_hwdom_shutdown(). Changes in V7: - Control domain is responsible for host suspend. - Add an empty inline host_system_suspend() function when SYSTEM_SUSPEND config is disabled. - Use IS_ENABLED() for config checking instead of #ifdef. - Replace #ifdef checks in domain_shutdown() with IS_ENABLED() to simplify control flow. - Factor hardware domain shutdown condition into a helper (need_hwdom_shutdown()) to avoid preprocessor directives inside the function. - Squash with iommu suspend/resume commit. --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/cpuerrata.c | 7 +- xen/arch/arm/include/asm/cpuerrata.h | 1 + xen/arch/arm/include/asm/mmu/mm.h | 2 + xen/arch/arm/include/asm/suspend.h | 2 + xen/arch/arm/mmu/smpboot.c | 2 +- xen/arch/arm/suspend.c | 149 +++++++++++++++++++++++++++ xen/arch/arm/vpsci.c | 10 +- 8 files changed, 170 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index fd5f0ddb17..c3e32fb683 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -9,6 +9,7 @@ config ARM_64 select 64BIT select HAS_DOMAIN_TYPE select HAS_FAST_MULTIPLY + select HAS_SYSTEM_SUSPEND if !MPU && UNSUPPORTED select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH config ARM diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c index 35ad98d29d..5a7f127495 100644 --- a/xen/arch/arm/cpuerrata.c +++ b/xen/arch/arm/cpuerrata.c @@ -782,6 +782,11 @@ void check_local_cpu_errata(void) update_cpu_capabilities(arm_errata, "enabled workaround for"); } +int enable_local_cpu_errata_workarounds(void) +{ + return enable_nonboot_cpu_caps(arm_errata); +} + void __init enable_errata_workarounds(void) { enable_cpu_capabilities(arm_errata); @@ -818,7 +823,7 @@ static int cpu_errata_callback(struct notifier_block *nfb, * fixed to expect an error at CPU_STARTING phase. */ ASSERT(system_state != SYS_STATE_boot); - rc = enable_nonboot_cpu_caps(arm_errata); + rc = enable_local_cpu_errata_workarounds(); break; default: break; diff --git a/xen/arch/arm/include/asm/cpuerrata.h b/xen/arch/arm/include/asm/cpuerrata.h index 1799a16d7e..b93521326f 100644 --- a/xen/arch/arm/include/asm/cpuerrata.h +++ b/xen/arch/arm/include/asm/cpuerrata.h @@ -5,6 +5,7 @@ #include void check_local_cpu_errata(void); +int enable_local_cpu_errata_workarounds(void); void enable_errata_workarounds(void); #define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \ diff --git a/xen/arch/arm/include/asm/mmu/mm.h b/xen/arch/arm/include/asm/mmu/mm.h index 7f4d59137d..ee73a77777 100644 --- a/xen/arch/arm/include/asm/mmu/mm.h +++ b/xen/arch/arm/include/asm/mmu/mm.h @@ -110,6 +110,8 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr, extern void switch_ttbr(uint64_t ttbr); extern void relocate_and_switch_ttbr(uint64_t ttbr); +void set_init_ttbr(lpae_t *root); + #endif /* __ARM_MMU_MM_H__ */ /* diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h index 50dc6e9fdf..889a6509d9 100644 --- a/xen/arch/arm/include/asm/suspend.h +++ b/xen/arch/arm/include/asm/suspend.h @@ -41,11 +41,13 @@ int prepare_resume_ctx(void); void hyp_resume(void); bool host_system_suspend_allowed(void); void host_system_suspend_disable(const char *reason); +void host_system_suspend(struct domain *d); #else /* !CONFIG_SYSTEM_SUSPEND */ static inline bool host_system_suspend_allowed(void) { return false; } static inline void host_system_suspend_disable(const char *reason) {} +static inline void host_system_suspend(struct domain *d) {} #endif diff --git a/xen/arch/arm/mmu/smpboot.c b/xen/arch/arm/mmu/smpboot.c index 37e91d72b7..ff508ecf40 100644 --- a/xen/arch/arm/mmu/smpboot.c +++ b/xen/arch/arm/mmu/smpboot.c @@ -72,7 +72,7 @@ static void clear_boot_pagetables(void) clear_table(boot_third); } -static void set_init_ttbr(lpae_t *root) +void set_init_ttbr(lpae_t *root) { /* * init_ttbr is part of the identity mapping which is read-only. So diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c index c7c26bcf03..e6b7f6a6cc 100644 --- a/xen/arch/arm/suspend.c +++ b/xen/arch/arm/suspend.c @@ -1,10 +1,18 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include +#include #include #include +#include +#include +#include #include +#include #include +#include struct resume_cpu_context resume_cpu_context; @@ -44,6 +52,147 @@ void host_system_suspend_disable(const char *reason) reason ? reason : "unsupported suspend/resume path"); } +/* Xen suspend. data identifies the domain that initiated suspend. */ +static void system_suspend(void *data) +{ + int status; + unsigned long flags; + struct domain *d = (struct domain *)data; + + BUG_ON(system_state != SYS_STATE_active); + + system_state = SYS_STATE_suspend; + + printk("Xen suspending...\n"); + + freeze_domains(); + scheduler_disable(); + + /* + * Non-boot CPUs have to be disabled on suspend and enabled on resume + * (hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI + * CPU_OFF to be called by each non-boot CPU. Depending on the underlying + * platform capabilities, this may lead to the physical powering down of + * CPUs. + */ + status = disable_nonboot_cpus(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_nonboot_cpus; + } + + console_start_sync(); + status = iommu_suspend(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_end_sync; + } + + status = console_suspend(); + if ( status ) + { + dprintk(XENLOG_ERR, "Failed to suspend the console, err=%d\n", status); + system_state = SYS_STATE_resume; + goto resume_iommu; + } + + local_irq_save(flags); + + time_suspend(); + + status = gic_suspend(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_time; + } + + set_init_ttbr(xen_pgtable); + + /* + * Enable identity mapping before entering suspend to simplify + * the resume path + */ + update_boot_mapping(true); + + if ( prepare_resume_ctx() ) + { + status = call_psci_system_suspend(); + /* + * If suspend is finalized properly by above system suspend PSCI call, + * the code below in this 'if' branch will never execute. Execution + * will continue from hyp_resume which is the hypervisor's resume point. + * In hyp_resume CPU context will be restored and since link-register is + * restored as well, it will appear to return from prepare_resume_ctx. + * The difference in returning from prepare_resume_ctx on system suspend + * versus resume is in function's return value: on suspend, the return + * value is a non-zero value, on resume it is zero. That is why the + * control flow will not re-enter this 'if' branch on resume. + */ + if ( status ) + dprintk(XENLOG_WARNING, "PSCI system suspend failed, err=%d\n", + status); + + system_state = SYS_STATE_resume; + } + else + { + system_state = SYS_STATE_resume; + + /* + * CPU0 resumes directly from hyp_resume(), bypassing the CPU hotplug + * path that re-checks and re-enables errata workarounds for secondary + * CPUs. + */ + check_local_cpu_errata(); + check_local_cpu_features(); + BUG_ON(enable_local_cpu_errata_workarounds()); + } + + update_boot_mapping(false); + + gic_resume(); + + resume_time: + time_resume(); + + local_irq_restore(flags); + + (void)console_resume(); + + resume_iommu: + iommu_resume(); + + resume_end_sync: + console_end_sync(); + + resume_nonboot_cpus: + enable_nonboot_cpus(); + + scheduler_enable(); + thaw_domains(); + + system_state = SYS_STATE_active; + + printk("Resume (status %d)\n", status); + + domain_resume(d); +} + +static DECLARE_TASKLET(system_suspend_tasklet, system_suspend, NULL); + +void host_system_suspend(struct domain *d) +{ + system_suspend_tasklet.data = (void *)d; + /* + * The suspend procedure has to be finalized by the pCPU#0 (non-boot pCPUs + * will be disabled during the suspend). + */ + tasklet_schedule_on_cpu(&system_suspend_tasklet, 0); +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c index 0131c297dd..5d4c31df1e 100644 --- a/xen/arch/arm/vpsci.c +++ b/xen/arch/arm/vpsci.c @@ -238,7 +238,8 @@ static bool domain_in_suspend_state(struct domain *d) return suspended; } -static int32_t domain_psci_system_suspend_policy(struct domain *d) +static int32_t domain_psci_system_suspend_policy(struct domain *d, + bool *host_suspend) { struct domain *other; bool last_awake_control_domain = true; @@ -305,6 +306,7 @@ static int32_t domain_psci_system_suspend_policy(struct domain *d) if ( !host_system_suspend_allowed() ) return PSCI_DENIED; + *host_suspend = true; return 0; } @@ -315,6 +317,7 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) struct vcpu *v; struct domain *d = current->domain; bool is_thumb = epoint & 1; + bool host_suspend = false; struct resume_info *rctx = &d->arch.resume_ctx; /* THUMB set is not allowed with 64-bit domain */ @@ -339,7 +342,7 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) spin_lock(&vpsci_system_suspend_lock); - rc = domain_psci_system_suspend_policy(d); + rc = domain_psci_system_suspend_policy(d, &host_suspend); if ( !rc ) { rc = domain_shutdown(d, SHUTDOWN_suspend); @@ -364,6 +367,9 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) "SYSTEM_SUSPEND requested, epoint=%#"PRIregister", cid=%#"PRIregister"\n", epoint, cid); + if ( host_suspend ) + host_system_suspend(d); + return rc; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462690.1673691 (Exim 4.92) (envelope-from ) id 1xLpp9-0000yw-SP; Tue, 27 Oct 2026 22:39:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462690.1673691; Tue, 27 Oct 2026 22:39: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 1xLpp9-0000yn-Ng; Tue, 27 Oct 2026 22:39:19 +0000 Received: by outflank-mailman (input) for mailman id 1462690; Tue, 27 Oct 2026 22:39:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3EyjhagcKCUYqzwomz0owwotm.kwu5mv-lm3mttq010.5mvxzwrmk1.wzo@flex--irogers.bounces.google.com>) id 1xLpp8-0000xz-Jr for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLpp8-0014Yn-0k for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:18 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3EyjhagcKCUYqzwomz0owwotm.kwu5mv-lm3mttq010.5mvxzwrmk1.wzo@flex--irogers.bounces.google.com>) id 6ae127f8-2eae-0a2a0a5409dd-0a2a4501a848-14 for ; Tue, 27 Oct 2026 23:39:17 +0100 Received: from [74.125.82.69] (helo=mail-dl1-f69.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3EyjhagcKCUYqzwomz0owwotm.kwu5mv-lm3mttq010.5mvxzwrmk1.wzo@flex--irogers.bounces.google.com>) id 6ae12814-5984-0a2a45010019-4a7d5245d558-3 for ; Tue, 27 Oct 2026 23:39:17 +0100 Received: by mail-dl1-f69.google.com with SMTP id a92af1059eb24-15c16792146so167206c88.1 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140756; x=1793745556; 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=kZ/TSWTZAJNbAAfYXfetESQgQ8bp7xksXUAoJHJHiFs=; b=nptYGcBijIO1LE+GHkedrP2Vfh1/0grRyyFkE/tpCF1WLKxMbDONNB58liw03MHaWh 87E/xjDI9N6XmM0jyz/N3jzWPr07GOj/dHxGmgBmRZ0EZeUFOPpYykio3L16gWDxlPIk ymSrTevh1QXPQ1DXEJOGK5BtzGGEKIKM/nuy0lGaX/fDAIE3G2VtnCu86We1dJgL7AEO 6d3+mIaD7ZbNJ6UoPf2/weASTXQYu6FN9+QWsMRFXWoL9AWZQ91dWx3ejtQFh8qC50pT 3sF7ipEOi/DeOUI6ECZPs2xBPURAYoyerayuNf+0lgyuaAVSoda+pJMLuAO6ksKDZx0s q1mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140756; x=1793745556; 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=kZ/TSWTZAJNbAAfYXfetESQgQ8bp7xksXUAoJHJHiFs=; b=nl5cP3iXi7TYSzwh/hN23SJux4GlAQc53wSrq2kkT+VIfibVUpl2DdH6n6xtWN7OKr 3mFf+M/cinxAyR7b2tHOUBbcoRQnWhqTgfjP3dUO/hjsWWv+dRxXv1l9xRugOFOZ541q bf9yM9JtNr66AwErynIymwIJfsQHmf8sgy/EWzKBitiNNB9PdUyPE9xeGxEJz65/eJXd zvX0HQe8C4aAVTj02zK2E/1FaEwQendLIyvkT/IaIn8mGDhyP8AmGdI7BjGRvu5X0+EW 7bHFEmYamCHf+bKnglzASA6g+9U9gtZ+T3KMY0nDA3eshIba225B5OQg7E6qIDhqwXy0 3aBg== X-Forwarded-Encrypted: i=1; AKwUvBxuNXaj0stHzUFZmwRHQGEjFI/LGa5fBwlPVii6f9d7fu7kBzCQuParu1Wjtc8yxHPKMM6pXV/CuVE=@lists.xenproject.org X-Gm-Message-State: AFq9FYLopVSFJwdZa/0HgEuU3w34b8PcJ4d2YcYzguayIok7WH0nDb6D eqIXo5Se+tlSS1jzI/IYfFgX45/mBAeHMAiPP30tV4dJt5zTPnz/rU6vcOwbD7guo8NPFUa7CoG 67gjyTVR6pA== X-Received: from dlbrl28.prod.google.com ([2002:a05:7022:f51c:b0:192:91:5cc4]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:618:b0:19f:527d:96da with SMTP id a92af1059eb24-1a6cdd3e006mr1194989c88.33.1793140755024; Tue, 27 Oct 2026 15:39:15 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:37 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-3-irogers@google.com> Subject: [PATCH v2 2/9] powerpc/secvar: Add missing kobject release callback to secvar_ktype From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , "Ritesh Harjani (IBM)" , Shrikanth Hegde , Nayna Jain , Eric Richter Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d62444/1793140757-BF063757-B9CB074D/0/0 X-purgate-type: clean X-purgate-size: 1283 In add_var(), a struct kobject is dynamically allocated with kzalloc_obj() and initialized with secvar_ktype. If kobject_add() or sysfs_create_file() fails, kobject_put(kobj) is called to clean up. However, secvar_ktype does not define a .release callback, which results in a memory leak of kobj (and a pr_debug warning in kobject_cleanup() when CONFIG_DEBUG_KOBJECT_RELEASE is enabled). Provide a secvar_release() callback that calls kfree(kobj). Fixes: bd5d9c743d38 ("powerpc: expose secure variables to userspace via sysfs") Signed-off-by: Ian Rogers --- arch/powerpc/kernel/secvar-sysfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/kernel/secvar-sysfs.c b/arch/powerpc/kernel/secvar-sysfs.c index 395399bbab2c..f3f6ac25ea78 100644 --- a/arch/powerpc/kernel/secvar-sysfs.c +++ b/arch/powerpc/kernel/secvar-sysfs.c @@ -126,7 +126,13 @@ static const struct attribute_group secvar_attr_group = { }; __ATTRIBUTE_GROUPS(secvar_attr); +static void secvar_release(struct kobject *kobj) +{ + kfree(kobj); +} + static const struct kobj_type secvar_ktype = { + .release = secvar_release, .sysfs_ops = &kobj_sysfs_ops, .default_groups = secvar_attr_groups, }; -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462688.1673672 (Exim 4.92) (envelope-from ) id 1xLpp4-0000Yc-C6; Tue, 27 Oct 2026 22:39:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462688.1673672; Tue, 27 Oct 2026 22: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 1xLpp4-0000YV-9J; Tue, 27 Oct 2026 22:39:14 +0000 Received: by outflank-mailman (input) for mailman id 1462688; Tue, 27 Oct 2026 22:39:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3DCjhagcKCT8jsphfsthpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--irogers.bounces.google.com>) id 1xLpp2-0000Y9-Hp for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLpp1-004ylB-Rr for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:11 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3DCjhagcKCT8jsphfsthpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--irogers.bounces.google.com>) id 6ae127f5-bab6-0a2a0a5309dd-0a2a450ce220-12 for ; Tue, 27 Oct 2026 23:39:11 +0100 Received: from [74.125.82.200] (helo=mail-dy1-f200.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3DCjhagcKCT8jsphfsthpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--irogers.bounces.google.com>) id 6ae1280e-f479-0a2a450c0019-4a7d52c8bcb3-3 for ; Tue, 27 Oct 2026 23:39:11 +0100 Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-30bcb065bfdso523745eec.0 for ; Tue, 27 Oct 2026 15:39: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=20260707 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:Mime-Version:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20260707; t=1793140749; x=1793745549; darn=lists.xenproject.org; h=content-type:cc:to:from:subject:message-id:mime-version:date:from :to:cc:subject:date:message-id:reply-to:content-type; bh=pEmx5PL3tlnBiGr2rjVOl0G+YHkBW7VB5cziBEiH9l0=; b=OvlXwlaA7HuTolK+cU7AHzkTAISfjKBJu3lKQLoT1rmMDSd5GMlBMU5chUiSRqoZsb QaNoUpJCZfXLSBwtgTRFiq57Ts5qSS/CEOtERIQ86UPdHC2nHOtDZsCbp/7SdlQjhJA0 4SI3oIHR5vF7IvlzuLLOmCxv4BOYl488bfZPXxxQ6PoaswLC8SDASUMoltsLxHd8k9aS 3go6xhptCDIjATTxZFT0mNdybRc3N32hSKeb5Yjaa4tWTTkc96mUd10qevcdG/BtAxwy IQrIDk9Hd4Qlcp0V/75DVMYJBhgjDFt7edgHz+8trao/EmoCgQaAoGU0aibCZLkYdqRf 0s8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140749; x=1793745549; h=content-type:cc:to:from:subject:message-id:mime-version:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=pEmx5PL3tlnBiGr2rjVOl0G+YHkBW7VB5cziBEiH9l0=; b=rXilLCScJgSxE7jJgIq+sq1mNlCoeYj8LIpFietqR1eGxDf6Zggpj0C8bXJg+vyUBk dUAQmAlRtM587UXZyTaA+zSXluhG6XbojeWryehZ5I05eYqOWQCSJKHot4ns3Tpd87J/ diXpl8V7FxWM7VXLqiOjYQNLYJbThk5zyRf0E0qvUBI/ORYW8MdqhRfcXGVo7hEx6pfN ePR9kR6PFoAJyv0areN1mJ/v+GuEXh5KR5D+jh9ogxBkRCr+1W/h92qaWDXqJuyu7GSK 5DCiRaLWJ6YrudI7soCc+03mGORPyh8pIbX511mXr5Tv4GvOZTNRLfvyzY+0Stp4Zc7f QGOA== X-Forwarded-Encrypted: i=1; AKwUvBxeSe/MJ0KfF+zoDvVw9ngcxFjgaKT/N++I7LQoZFGyqq4tX1ahCAvQ1vQ+YNYKJ81d3oyinAzQCUI=@lists.xenproject.org X-Gm-Message-State: AFq9FYK89J7u81HzSnUGkDQGyj07f6/ghMyWEDO5T/g8HipMKfXlLgIo SO/cFc2a/87UgKuC8YYOzBLi8hVN/dZN4SuyFgunSAkTqhSyJVy+rz4qlwv3wPaqnlrKMNmET2u ja72w91EQJQ== X-Received: from dli9.prod.google.com ([2002:a05:7022:289:b0:1a1:da78:f9b9]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:6989:b0:165:90af:a25f with SMTP id a92af1059eb24-1a6cfa0c447mr941563c88.41.1793140748444; Tue, 27 Oct 2026 15:39:08 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:35 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-1-irogers@google.com> Subject: [PATCH v2 0/9] Add __must_init and require explicit kobj_type::release From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1793140751-50B3DA5B-2E591983/0/0 X-purgate-type: clean X-purgate-size: 6912 Clang supports the 'require_explicit_initialization' attribute on struct fields to enforce that the field is explicitly initialized when an aggregate object is constructed, emitting -Wuninitialized-explicit-init (enabled by default) if the field is omitted. Following discussion at the Linux Plumbers Conference [1], patch 1 adds the attribute to include/linux/compiler_attributes.h as __must_init. In v1 it was called __require_explicit_initialization. Kees picked up that patch with a first seq_file user [2], and in that thread Greg suggested the shorter __must_init spelling, which Kees and Miguel agreed to. As the attribute did not land in the v7.4 merge window, Kees asked that this series carry the renamed attribute. The Acked-by/Reviewed-by tags on patch 1 were given for the original spelling; the rename is mechanical. As Documentation/core-api/kobject.rst notes: "One important point cannot be overstated: every kobject must have a release() method, and the kobject must persist (in a consistent state) until that method is called. If these constraints are not met, the code is flawed." Annotating struct kobj_type::release caught struct kobj_type definitions across the tree that omitted .release: - Patches 2-8 fix struct kobj_type definitions where dynamically allocated kobjects, ksets, or enclosing structures were either leaked on kobject_put(), freed prematurely before kobject release, or missing proper static initializers. - Patch 9 annotates struct kobj_type::release with __must_init and explicitly sets .release = NULL (with explanatory comments prefixed with "Pre-existing:") on the remaining legacy struct kobj_type definitions whose kobjects are static, per-CPU, permanent firmware structures, or embedded in devm- or parent-managed structures. Note on tool use: An LLM coding assistant was used to help audit the compiler diagnostics across the tree, draft the fixes and changelog descriptions, and verify builds and review feedback. Changes in v2: - Rebased on v7.3-16928-g83f32c773255 (v7.4 merge window). - Patch 1: Rename __require_explicit_initialization to __must_init per Greg Kroah-Hartman; document the Clang >= 20 requirement per Miguel Ojeda; note the Clang gap for file-scope objects without an initializer reported by Kees Cook; add tags from v1 and from Kees's posting. - Move LLM assistance attribution from Assisted-by tags to this cover letter per commit 1e035297ffda ("docs: remove Assisted-by references"). - Patch 4 (cpufreq): Use "cpufreq: governor:" prefix, drop Fixes tag, fix typo, and remove the redundant runtime assignment in cpufreq_dbs_governor_init() per Zhongqiu Han. - Dropped v1 patch 5 (ACPI: CPPC), already fixed upstream by commit 27954e29d7de ("ACPI: CPPC: Release CPC descriptors through kobject"). - Patch 5 (dlm): Call kobject_del() before dlm_recoverd_stop() in release_lockspace() and the new_lockspace() error path, and wait on a new ls_kobj_done completion before freeing the lockspace or dropping the module reference, avoiding races with delayed kobject release. - Dropped v1 patch 8 (s390/sclp_mem) per Sumanth Korikkar: the /sys/firmware/memory/memoryX kobjects are permanent, so sclp_mem.c is folded into patch 9 with .release = NULL. - Patch 7 (ubifs): Add Tested-by and Reviewed-by from Zhihao Cheng. - Patch 8 (drm/amdkfd): Check q->kobj.state_in_sysfs before kobject_del() in kfd_procfs_del_queue(). - Patch 9 (kobject): Cover sclp_mem.c and the new amdgpu_ualink.c ualink_xcp_info_ktype, fix the overlay-sysfs.c comment, and prefix legacy .release = NULL comments with "Pre-existing:". - Patch 9 (kobject): The ioat, kunpeng_hccs and omapfb display comments now say that the existing teardown can use-after-free under CONFIG_DEBUG_KOBJECT_RELEASE (reported by Sashiko). Fixing those drivers is left to follow-up patches. v1: https://lore.kernel.org/all/20261013223946.1836757-1-irogers@google.com/ [1] https://lpc.events/event/20/contributions/2392/ [2] https://lore.kernel.org/lkml/20261014225811.i.852-kees@kernel.org/ Ian Rogers (9): Compiler Attributes: Add __must_init macro powerpc/secvar: Add missing kobject release callback to secvar_ktype sh: sq: Add missing kobject release callback to ktype_percpu_entry cpufreq: governor: Initialize kobj_type release callback statically dlm: Free dlm_ls in kobject release callback xen/sys-hypervisor: Add release callback to hyp_sysfs_kobj_type ubifs: sysfs: Use kset_create_and_add() for ubifs_kset drm/amdkfd: Free queue in procfs_queue_type kobject release callback kobject: Require explicit initialization of struct kobj_type::release Documentation/conf.py | 1 + arch/arm64/kernel/cpuinfo.c | 5 ++++ arch/powerpc/kernel/secvar-sysfs.c | 6 +++++ arch/sh/kernel/cpu/sh4/sq.c | 6 +++++ drivers/acpi/sysfs.c | 2 ++ drivers/cpufreq/cpufreq_conservative.c | 5 +++- drivers/cpufreq/cpufreq_governor.c | 4 +-- drivers/cpufreq/cpufreq_governor.h | 1 + drivers/cpufreq/cpufreq_ondemand.c | 5 +++- drivers/dma/ioat/sysfs.c | 7 +++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c | 5 ++++ drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c | 10 +++++++ drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12 ++++++--- drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 5 +++- drivers/infiniband/hw/hfi1/sysfs.c | 5 ++++ drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 2 ++ drivers/parisc/pdc_stable.c | 5 ++++ drivers/power/supply/ab8500_fg.c | 5 ++++ drivers/s390/char/sclp_mem.c | 2 ++ drivers/soc/hisilicon/kunpeng_hccs.c | 21 +++++++++++++++ .../fbdev/omap2/omapfb/dss/display-sysfs.c | 7 +++++ .../fbdev/omap2/omapfb/dss/manager-sysfs.c | 5 ++++ .../fbdev/omap2/omapfb/dss/overlay-sysfs.c | 5 ++++ drivers/xen/sys-hypervisor.c | 6 +++++ fs/dlm/dlm_internal.h | 1 + fs/dlm/lockspace.c | 26 ++++++++++++++----- fs/erofs/sysfs.c | 10 +++++++ fs/f2fs/sysfs.c | 15 +++++++++++ fs/ocfs2/cluster/masklog.c | 5 ++++ fs/ubifs/sysfs.c | 24 +++++------------ include/linux/compiler_attributes.h | 12 +++++++++ include/linux/kobject.h | 2 +- scripts/checkpatch.pl | 1 + tools/lib/python/kdoc/xforms_lists.py | 1 + 34 files changed, 202 insertions(+), 32 deletions(-) base-commit: 83f32c773255720a661aa45d83e36278135f23f5 -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462691.1673699 (Exim 4.92) (envelope-from ) id 1xLppD-0001Dt-19; Tue, 27 Oct 2026 22:39:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462691.1673699; Tue, 27 Oct 2026 22:39: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 1xLppC-0001Dm-Tj; Tue, 27 Oct 2026 22:39:22 +0000 Received: by outflank-mailman (input) for mailman id 1462691; Tue, 27 Oct 2026 22:39:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3FijhagcKCUkt2zrp23rzzrwp.nzx8py-op6pwwt343.8py02zupn4.z2r@flex--irogers.bounces.google.com>) id 1xLppB-0001CJ-IW for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLppA-00BmpO-OC for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:20 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3FijhagcKCUkt2zrp23rzzrwp.nzx8py-op6pwwt343.8py02zupn4.z2r@flex--irogers.bounces.google.com>) id 6ae127ef-8faa-0a2a0a5109dd-0a2a45059390-40 for ; Tue, 27 Oct 2026 23:39:20 +0100 Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3FijhagcKCUkt2zrp23rzzrwp.nzx8py-op6pwwt343.8py02zupn4.z2r@flex--irogers.bounces.google.com>) id 6ae12817-4cb1-0a2a45050019-d155d2c5c09e-3 for ; Tue, 27 Oct 2026 23:39:20 +0100 Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-8a030e0f9c1so413668b3a.2 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140759; x=1793745559; 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=beIsynJTUoVVYUibNrHvS9xq2J3rMWzpCblr3XGPomY=; b=ouzbSD09iwrlMUVncPRcU9lLmHAbyBRgF5YZnk/0TMk27UW4OZlTOxfdK3fwi6+zqX 1UPsZo/92pg3ptgvRw95ZVLVweKrnYusSWRvlGQe/ClLywRIy39PBF7+6G0kALqyS6i0 4Trh0ksf3HC1TQxCyltMbKwTAsollHd7HrJXLYbHNRxMCqlbXbr0LX7WC7Wr90VogyW1 wUg8SlFZR4E1EoH/7EGSDWfb0XlhjzYmt51JuCL4rpCXwknCY5mItDiTj8Uo4MFrqkyO rZhFMsqrmKat41z7g0QX2zR872u9byyb7c/O4iSLtwQVqRVIz+zgsKMksP61PmShJjYW 0yCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140759; x=1793745559; 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=beIsynJTUoVVYUibNrHvS9xq2J3rMWzpCblr3XGPomY=; b=tQn3Ads0lqBX5b+9x6M5GZyP5eigKIJmQUCbjzlp0FeF7pSGplyrR0ei61umKVPD9t 6YuHOycFqEHNyyRKY4D+kMbia1e1aPslS+bE0etH7YFZqxe/zNVRoh39qPxzDJVrDy6B wzn/lxuBLxhA0twLhBu9rg+xs4n33T0x3Poncuf1rpr7p8hzjWiaahxbv497iMIm82Vc LCO2izjEudcWeFJs7INEkn6SG2I98v/HOmtFLucIisMKP4+b/ZfQpgXTIkAtTtO9Qw9k OZWeOtK2POB1Qyu2YHeufs9CZ4ImqKIFWZrh/2LGXjwFMNfKodcmHsDknHRtTeQVugX0 wH9w== X-Forwarded-Encrypted: i=1; AKwUvByKKmlXam4HC9Q9SHqsxqY+fqn/B1kuY+iHrmW0etsdXLxsefmb1g5yMRDdwWWx+/GXIW5aapOe8kY=@lists.xenproject.org X-Gm-Message-State: AFq9FYKapTSPE3Ye3kirgCyx5dma1rEQw2runHDe8IQcySYtjzzlegBu LBpiT712HP8z4OltlaVl+yTZOd2SxM8EG8ukw+h9zAH7O47JpgHrvwedspSORdi2WwxTmkvIrNy 1Ty0+QcQ4eg== X-Received: from pfbdw21.prod.google.com ([2002:a05:6a00:3695:b0:89f:827e:eb47]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:4293:b0:876:194e:b8fe with SMTP id d2e1a72fcca58-8a6e70e832amr492696b3a.26.1793140758450; Tue, 27 Oct 2026 15:39:18 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:38 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-4-irogers@google.com> Subject: [PATCH v2 3/9] sh: sq: Add missing kobject release callback to ktype_percpu_entry From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Paul Mundt Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c201ff/1793140760-F54AC2A1-CECF191C/0/0 X-purgate-type: clean X-purgate-size: 1055 In sq_dev_add(), sq_kobject[cpu] is dynamically allocated with kzalloc_obj() and initialized with ktype_percpu_entry. When sq_dev_remove() calls kobject_put(kobj), the kobject is never freed because ktype_percpu_entry lacks a .release callback. Provide a sq_kobj_release() callback that calls kfree(kobj). Fixes: d7c30c682a27 ("sh: Store Queue API rework.") Signed-off-by: Ian Rogers --- arch/sh/kernel/cpu/sh4/sq.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/sh/kernel/cpu/sh4/sq.c b/arch/sh/kernel/cpu/sh4/sq.c index 908a8e09113b..f33864958487 100644 --- a/arch/sh/kernel/cpu/sh4/sq.c +++ b/arch/sh/kernel/cpu/sh4/sq.c @@ -331,7 +331,13 @@ static const struct sysfs_ops sq_sysfs_ops = { .store = sq_sysfs_store, }; +static void sq_kobj_release(struct kobject *kobj) +{ + kfree(kobj); +} + static struct kobj_type ktype_percpu_entry = { + .release = sq_kobj_release, .sysfs_ops = &sq_sysfs_ops, .default_groups = sq_sysfs_groups, }; -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462689.1673681 (Exim 4.92) (envelope-from ) id 1xLpp6-0000lE-Ki; Tue, 27 Oct 2026 22:39:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462689.1673681; Tue, 27 Oct 2026 22:39: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 1xLpp6-0000l7-Ho; Tue, 27 Oct 2026 22:39:16 +0000 Received: by outflank-mailman (input) for mailman id 1462689; Tue, 27 Oct 2026 22:39:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3DyjhagcKCUImvskivwksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--irogers.bounces.google.com>) id 1xLpp5-0000ju-CP for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLpp4-004ylB-Pe for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:14 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3DyjhagcKCUImvskivwksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--irogers.bounces.google.com>) id 6ae127f5-bab6-0a2a0a5309dd-0a2a450ce220-14 for ; Tue, 27 Oct 2026 23:39:14 +0100 Received: from [74.125.82.197] (helo=mail-dy1-f197.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3DyjhagcKCUImvskivwksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--irogers.bounces.google.com>) id 6ae12811-f479-0a2a450c0019-4a7d52c5bd5d-3 for ; Tue, 27 Oct 2026 23:39:14 +0100 Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-33c35f5ca6cso579334eec.1 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140753; x=1793745553; 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=dWBu3E1+9O630leKOxiPf33Qem+izCRkowC6gFS9sVM=; b=PLrzcKPdDfBfjAesflYzKm1Aj5jBmB/2fEvBSeKCRAZ4Azmpn9wFMiuAGSPgNHi0tr 8A06Lg0KX8mhgY0AFiFJzbJQmrBU5OvyERsOv14iJUliD8Xbn/Jw6l5+s7cLltEj2lgI WDV/e0l0ncmi4kYi0qbGD1QqgBU4hfiCcit4x/jBxIgtWeEAA34RTUYgymOXNgypkmez MTTIZ3uo3U63LedxvZC5SgX2WcVkGXMas4j1jYR/zZREGRMnQNcGhMOqJ0eCUgO4F52m q+OHuCKSo1tg2gaCER1VKNSUD8dwYgUWdH1IBYicd136xmTaGpg8u2nFHS7vm7lmpy7T NMeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140753; x=1793745553; 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=dWBu3E1+9O630leKOxiPf33Qem+izCRkowC6gFS9sVM=; b=mg1tdZsnQDMiVVy2odZA+MmLQRBCD95E5qxoonsAT3cxvdxv6+WcTJQbee3sEKrDiK PVpvm/PA5CJYtEb+KY70zlzSQ2GAQXCTGpqnf9rV2W8csL3SIFRKQfN1ILQrohMgF0F1 x3U0E421Ct6Wq9eQxsCmq/AgAH+c2rUC8RIRwzf8vDgihUZDhx935I9kopDbrcBjUH6p 9betT1fWLjycAAI5PU5bIEcoS/QKkzImp9vyXD8xjzBB/Z4BAvmNBDPPwDMDIuQBNQ2K dHmQdN+gdqJtIyK/fq5GAHEJ2v1AVlpu0jVWLKC+sNTDLtTOk19evJLJ2Qp1o8fRqNsJ 73iQ== X-Forwarded-Encrypted: i=1; AKwUvByqgr58aSl3cws/ptQPKAVDuql9Ab2PPsxrS6appXYyQMtgR+xB4NPLhJ3CtQ8rUBqW3xCpe7prBpw=@lists.xenproject.org X-Gm-Message-State: AFq9FYIEsEoDd3PAOcIqMpQ47IYBxi01fD5CHMe+f2ajxD+nkUPGzoev 3u3O5zStifzK5OFQICtaMk/pdxh9d1cC9yReoYiQAOkVaYPyN7Mag0pxo0i8HroxCMaxI24oyqi SYwUFOeL1bQ== X-Received: from dybnl11.prod.google.com ([2002:a05:7300:cf8b:b0:36a:117:523b]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:693c:250d:b0:369:f5f6:36a7 with SMTP id 5a478bee46e88-36a2014b887mr1132027eec.16.1793140751881; Tue, 27 Oct 2026 15:39:11 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:36 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-2-irogers@google.com> Subject: [PATCH v2 1/9] Compiler Attributes: Add __must_init macro From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Jonathan Corbet , Shuah Khan , Randy Dunlap , Andy Whitcroft , Joe Perches Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1793140754-770D9A5B-216303FD/0/0 X-purgate-type: clean X-purgate-size: 4176 Clang supports the 'require_explicit_initialization' attribute on struct fields to indicate that a field must be initialized explicitly by the user when the object is constructed. When an aggregate initializer or uninitialized variable omits an annotated field, Clang emits a -Wuninitialized-explicit-init warning (enabled by default). Add the __must_init macro to include/linux/compiler_attributes.h (which is included by include/linux/compiler_types.h and include/linux/compiler.h) so kernel structs with error-prone initialization (such as mandatory callbacks or cleanup handlers) can enforce explicit initialization at compile time, as discussed at the Linux Plumbers Conference. The shorter __must_init spelling, rather than the attribute's full name, keeps annotated struct members readable and was suggested by Greg Kroah-Hartman. Note that Clang does not yet diagnose file-scope objects declared without any initializer (initializers at file scope that omit the field are diagnosed), see https://github.com/llvm/llvm-project/issues/232483. Also teach Sphinx (Documentation/conf.py), kernel-doc (tools/lib/python/kdoc/xforms_lists.py), and checkpatch.pl about the new attribute macro. Link: https://lpc.events/event/20/contributions/2392/ Link: https://lore.kernel.org/lkml/2026101532-fantastic-deafness-e04c@gregkh/ Acked-by: Miguel Ojeda Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Acked-by: Greg Kroah-Hartman Signed-off-by: Ian Rogers --- Documentation/conf.py | 1 + include/linux/compiler_attributes.h | 12 ++++++++++++ scripts/checkpatch.pl | 1 + tools/lib/python/kdoc/xforms_lists.py | 1 + 4 files changed, 15 insertions(+) diff --git a/Documentation/conf.py b/Documentation/conf.py index 5ab26ce89daf..baaa4035258c 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -203,6 +203,7 @@ c_id_attributes = [ "__noreturn", "__packed", "__pure", + "__must_init", "__section", "__always_unused", "__maybe_unused", diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h index 476c4c560d17..b9c0b56dd22e 100644 --- a/include/linux/compiler_attributes.h +++ b/include/linux/compiler_attributes.h @@ -322,6 +322,18 @@ */ #define __pure __attribute__((__pure__)) +/* + * Optional: not supported by gcc + * Optional: only supported since clang >= 20.0 + * + * clang: https://clang.llvm.org/docs/AttributeReference.html#require-explicit-initialization + */ +#if __has_attribute(__require_explicit_initialization__) +# define __must_init __attribute__((__require_explicit_initialization__)) +#else +# define __must_init +#endif + /* * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-section-function-attribute * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-section-variable-attribute diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index c9840f5219c2..5232f66d2b80 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -6860,6 +6860,7 @@ sub process { "noreturn" => "__noreturn", "packed" => "__packed", "pure" => "__pure", + "require_explicit_initialization" => "__must_init", "section" => "__section", "used" => "__used", "weak" => "__weak" diff --git a/tools/lib/python/kdoc/xforms_lists.py b/tools/lib/python/kdoc/xforms_lists.py index 320f977c5bac..3c744cbd2f34 100644 --- a/tools/lib/python/kdoc/xforms_lists.py +++ b/tools/lib/python/kdoc/xforms_lists.py @@ -36,6 +36,7 @@ class CTransforms: (CMatch("CRYPTO_MINALIGN_ATTR"), ""), (CMatch("__private"), ""), (CMatch("__rcu"), ""), + (CMatch("__must_init"), ""), (CMatch("____cacheline_aligned_in_smp"), ""), (CMatch("____cacheline_aligned"), ""), (CMatch("__cacheline_group_(?:begin|end)"), ""), -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462693.1673708 (Exim 4.92) (envelope-from ) id 1xLppF-0001TN-8g; Tue, 27 Oct 2026 22:39:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462693.1673708; Tue, 27 Oct 2026 22:39: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 1xLppF-0001TC-43; Tue, 27 Oct 2026 22:39:25 +0000 Received: by outflank-mailman (input) for mailman id 1462693; Tue, 27 Oct 2026 22:39:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3GSjhagcKCUww52us56u22uzs.q20Bs1-rs9szzw676.Bs1352xsq7.25u@flex--irogers.bounces.google.com>) id 1xLppE-0001Rz-BG for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLppD-00BmpO-OE for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:23 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3GSjhagcKCUww52us56u22uzs.q20Bs1-rs9szzw676.Bs1352xsq7.25u@flex--irogers.bounces.google.com>) id 6ae127a0-8faa-0a2a0a5109dd-0a2a4507810e-48 for ; Tue, 27 Oct 2026 23:39:23 +0100 Received: from [74.125.82.199] (helo=mail-dy1-f199.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3GSjhagcKCUww52us56u22uzs.q20Bs1-rs9szzw676.Bs1352xsq7.25u@flex--irogers.bounces.google.com>) id 6ae1281a-b4ea-0a2a45070019-4a7d52c7b480-3 for ; Tue, 27 Oct 2026 23:39:23 +0100 Received: by mail-dy1-f199.google.com with SMTP id 5a478bee46e88-33713e5e6daso413236eec.0 for ; Tue, 27 Oct 2026 15: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=20260707 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=20260707; t=1793140761; x=1793745561; 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=JWqYb4bGeUKpshpA/YjhKSWXxaEK2QVlfhqplD6YlhY=; b=ZZJcd2rGbosi5uiZZGudoIglK/HZpD8CkquX4MOefmu99Sgm97KjK5+ZZqJ3DCViX6 ZACRhUoUeqMWhcgS74zWb7EadJIOvyLFB+6paPtqi1z+MnXbgwjy4DphM5jQM9bPf8HB vGKhGU4IC6T5sYTfILx0l4UnBwrp2IRdciHvbJe0S7Ap01D4Yyys5o6VW2qND+Irgjpi EBhMG1CghZOTze/AW/9m21rrEcc2/DrtfiGqRXy8ljqUjlUrXnTl6GAquGG+TSbPGlXg NFAxGa0dHEvGCnMgib3+YasR6qsIRVZgxATvu5/bFEvbC7meZx6GGmICYoQt+AH9oDOI IGsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140761; x=1793745561; 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=JWqYb4bGeUKpshpA/YjhKSWXxaEK2QVlfhqplD6YlhY=; b=wK7U3APS/Sw4wVmF4qgeGAlh82KtvQO6VZyPHyVHusqQmORhBmZe0a59MwIbHEiaTv y07zIps3/jj2UAJQgdkpRMbABk30MqZFndiIuZ4jBi0UsF2uTA3cD4aslGP9221m50sg zK/Bfb7gPvbWhqcZxkOhwpltA61HTOeHl/emzSh0XAfSxN809BuiPsUO3ztXMgCodojq ZhiltEprpAkPZlplJwJd72sm3gbLha84+hgvOHuWQdjUS4wtPUxVQsjZDvjIWyN3gQiB jIiWVUESyPoIkpSBlMKdxodudk4TxAIcidIa0dLK/nuCiG2RI0Fu57LRwSQ/wYQdy3Vs AQLg== X-Forwarded-Encrypted: i=1; AKwUvBzH5tvW/m7JQrgSkYMH/l5jqEkUfDymaNME6lzT/fKojrNBTW0+FvJS3M7oTml7XpCaX7VsGedlCwk=@lists.xenproject.org X-Gm-Message-State: AFq9FYLmxyP0MaZtEl23Cco5A/qYbPex2E8ikJJorGssfF5rh9WcFEli NGvRAHL3DLQ2WCj9kxg4W526jOJFpHQCo4pzIF1s8SwvFhmV4VLFXcnS0FKgmH7WcDspnL90xgw DMXwNTlGc4A== X-Received: from dycna3.prod.google.com ([2002:a05:7300:ea83:b0:36a:1b4f:e8f9]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7300:e9c8:10b0:365:d42a:f415 with SMTP id 5a478bee46e88-36a2036d4d1mr1220304eec.12.1793140761297; Tue, 27 Oct 2026 15:39:21 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:39 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-5-irogers@google.com> Subject: [PATCH v2 4/9] cpufreq: governor: Initialize kobj_type release callback statically From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Viresh Kumar Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ef75cf/1793140763-A70DDAE4-8969878F/0/0 X-purgate-type: clean X-purgate-size: 3747 Export cpufreq_dbs_data_release() and set .kobj_type.release statically in the ondemand and conservative governors so their gov_attr_set kobjects have a valid release callback statically initialized, matching cpufreq_governor_dbs. Remove the redundant runtime assignment in cpufreq_dbs_governor_init(). This prepares for annotating struct kobj_type::release with __must_init. Signed-off-by: Ian Rogers --- drivers/cpufreq/cpufreq_conservative.c | 5 ++++- drivers/cpufreq/cpufreq_governor.c | 4 ++-- drivers/cpufreq/cpufreq_governor.h | 1 + drivers/cpufreq/cpufreq_ondemand.c | 5 ++++- 4 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c index 02bfd46543e9..146a2353b1a2 100644 --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -318,7 +318,10 @@ static void cs_limits(struct cpufreq_policy *policy) static struct dbs_governor cs_governor = { .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"), - .kobj_type = { .default_groups = cs_groups }, + .kobj_type = { + .release = cpufreq_dbs_data_release, + .default_groups = cs_groups, + }, .gov_dbs_update = cs_dbs_update, .alloc = cs_alloc, .free = cs_free, diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index f3bd3dbe7c41..f8b5aca09b6b 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -419,7 +419,7 @@ static void free_policy_dbs_info(struct policy_dbs_info *policy_dbs, gov->free(policy_dbs); } -static void cpufreq_dbs_data_release(struct kobject *kobj) +void cpufreq_dbs_data_release(struct kobject *kobj) { struct dbs_data *dbs_data = to_dbs_data(to_gov_attr_set(kobj)); struct dbs_governor *gov = dbs_data->gov; @@ -427,6 +427,7 @@ static void cpufreq_dbs_data_release(struct kobject *kobj) gov->exit(dbs_data); kfree(dbs_data); } +EXPORT_SYMBOL_GPL(cpufreq_dbs_data_release); int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) { @@ -488,7 +489,6 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) policy->governor_data = policy_dbs; gov->kobj_type.sysfs_ops = &governor_sysfs_ops; - gov->kobj_type.release = cpufreq_dbs_data_release; ret = kobject_init_and_add(&dbs_data->attr_set.kobj, &gov->kobj_type, get_governor_parent_kobj(policy), "%s", gov->gov.name); diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h index 806d8fb4dff1..1026712bb79b 100644 --- a/drivers/cpufreq/cpufreq_governor.h +++ b/drivers/cpufreq/cpufreq_governor.h @@ -150,6 +150,7 @@ static inline struct dbs_governor *dbs_governor_of(struct cpufreq_policy *policy } /* Governor callback routines */ +void cpufreq_dbs_data_release(struct kobject *kobj); int cpufreq_dbs_governor_init(struct cpufreq_policy *policy); void cpufreq_dbs_governor_exit(struct cpufreq_policy *policy); int cpufreq_dbs_governor_start(struct cpufreq_policy *policy); diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index 9942dbb38dae..7386d043c665 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -374,7 +374,10 @@ static struct od_ops od_ops = { static struct dbs_governor od_dbs_gov = { .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("ondemand"), - .kobj_type = { .default_groups = od_groups }, + .kobj_type = { + .release = cpufreq_dbs_data_release, + .default_groups = od_groups, + }, .gov_dbs_update = od_dbs_update, .alloc = od_alloc, .free = od_free, -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462694.1673718 (Exim 4.92) (envelope-from ) id 1xLppI-0001lO-Jc; Tue, 27 Oct 2026 22:39:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462694.1673718; Tue, 27 Oct 2026 22:39: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 1xLppI-0001lD-FP; Tue, 27 Oct 2026 22:39:28 +0000 Received: by outflank-mailman (input) for mailman id 1462694; Tue, 27 Oct 2026 22:39:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3GyjhagcKCU4y74wu78w44w1u.s42Du3-tuBu11y898.Du3574zus9.47w@flex--irogers.bounces.google.com>) id 1xLppH-0001io-3k for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLppG-009736-H0 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:26 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3GyjhagcKCU4y74wu78w44w1u.s42Du3-tuBu11y898.Du3574zus9.47w@flex--irogers.bounces.google.com>) id 6ae127f6-e002-0a2a0a5209dd-0a2a450ab2e4-24 for ; Tue, 27 Oct 2026 23:39:26 +0100 Received: from [74.125.82.69] (helo=mail-dl1-f69.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3GyjhagcKCU4y74wu78w44w1u.s42Du3-tuBu11y898.Du3574zus9.47w@flex--irogers.bounces.google.com>) id 6ae1281d-f2d2-0a2a450a0019-4a7d5245cca7-3 for ; Tue, 27 Oct 2026 23:39:26 +0100 Received: by mail-dl1-f69.google.com with SMTP id a92af1059eb24-139b62317d0so1025514c88.0 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140764; x=1793745564; 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=2p5eYZPmxsY9xh985bGLWJJ6j3FfFGXO/U6MsVvS8Z8=; b=bf5c+6XZNvtSx+A9k3q+Q0TdFu6YWRHRIQUl2gN/vIfiLihhTyA92yYX7ci9/M9tSx D9EjfKDDGnN5lVkNpt6XWK2J2EjzQhES+iAjG5BaF82yy7XaGv3MCXEOpsHNQwCyxV3p 3iCL6B/Ta3enhDX/7IuR4pbbkDw/SopJ8Q/rABW8+ejTvwz+uYYuiRsvsDOvMqbCcG47 ceLgV+mlURx6zWvITbKfRmO5SCp0mGiG3fNZME+mcRqUzpoD/Esp+MIHbIu8a5FeSHGd m8qm5Of5vsh8EfTgKnxJB2F/DzeP37fr4ke5HuLgUryMwcr5oPOUGQLD/3ItKCBH+HKx uGaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140764; x=1793745564; 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=2p5eYZPmxsY9xh985bGLWJJ6j3FfFGXO/U6MsVvS8Z8=; b=C1DuY3Vgm0ejcxZEKsZFHrm26nAdExeNf/f1BiPDkqhwR2Mk39DxIEC4ijI5tnGhtj uaK313wo78rripU3T5uCLPGwDO0ppprKoOG88nPMpF2+fktkz9GeF9MJAHKwB5aJ+fTD weq92Aerit942vC3wS1XPbc83p76JgSbBZd0MX/HqxlfgUsC/QgS3vlu9Hd0b2mvR/sN rPtUEFQLCtv1XoNPlyVUuJ4+kRhVpdaP9K427JXv5xT1KywAtJKBYJfSFfm+ciWlPzx7 1wBq6zBx2B3FFpKhGsRzZFAkzcpIYueAY8WWeylBZPZqO4f5Q7HBmjRKu2kcyyhjH403 QHYg== X-Forwarded-Encrypted: i=1; AKwUvByjRF/dYDFj2iCoH860Z9beIzcPsG0AtVu/yOGv+/TAwiK7SnQ3F3OEHGNXoxAR3iv6868vgQNSjhc=@lists.xenproject.org X-Gm-Message-State: AFq9FYLKkY6HHQMA2YY018gCoYjpUWV51upGn+LxWF8XFdKSsczgNwU9 YlgWNxdDhO9uVaMSahpx5bkntL+cljN0Msj/0W4ogzyeD0r8RZwRKb7b4X/xS/C6+pw872ie5y7 B43e+SHJH3A== X-Received: from dlbsv1.prod.google.com ([2002:a05:7022:3a01:b0:1a1:3ce6:560b]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:fd04:b0:1a3:bfb6:44ad with SMTP id a92af1059eb24-1a6ce2ff120mr1130455c88.32.1793140763880; Tue, 27 Oct 2026 15:39:23 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:40 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-6-irogers@google.com> Subject: [PATCH v2 5/9] dlm: Free dlm_ls in kobject release callback From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Alexander Aring , David Teigland , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-4011c0/1793140766-589C9CFC-971947C5/0/0 X-purgate-type: clean X-purgate-size: 4497 struct dlm_ls embeds a struct kobject (ls_kobj), but dlm_ktype lacked a .release callback and dlm freed the lockspace structure directly via kfree(ls). With CONFIG_DEBUG_KOBJECT_RELEASE=y, freeing ls before the delayed kobject release runs causes a use-after-free, and unloading the module while the delayed release is pending results in an instruction page fault. Add a completion ls_kobj_done and dlm_ls_release() to complete it when the last kobject reference is dropped, waiting for it in free_lockspace() before kfree(ls) and in the new_lockspace() error path before module_put(). Also delete the kobject via kobject_del() before stopping dlm_recoverd to close the window where concurrent sysfs writes could wake the stopped recovery task. Fixes: 3514faca19a6 ("kobject: remove struct kobj_type from struct kset") Signed-off-by: Ian Rogers --- fs/dlm/dlm_internal.h | 1 + fs/dlm/lockspace.c | 26 ++++++++++++++++++++------ 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/fs/dlm/dlm_internal.h b/fs/dlm/dlm_internal.h index 74c2e77d1b55..95b3bff0cb57 100644 --- a/fs/dlm/dlm_internal.h +++ b/fs/dlm/dlm_internal.h @@ -576,6 +576,7 @@ struct dlm_ls { int ls_create_count; /* create/release refcount */ unsigned long ls_flags; /* LSFL_ */ struct kobject ls_kobj; + struct completion ls_kobj_done; struct xarray ls_lkbxa; rwlock_t ls_lkbxa_lock; diff --git a/fs/dlm/lockspace.c b/fs/dlm/lockspace.c index a9c98b4f378f..2dccd080a10f 100644 --- a/fs/dlm/lockspace.c +++ b/fs/dlm/lockspace.c @@ -179,7 +179,15 @@ static const struct sysfs_ops dlm_attr_ops = { .store = dlm_attr_store, }; +static void dlm_ls_release(struct kobject *kobj) +{ + struct dlm_ls *ls = container_of(kobj, struct dlm_ls, ls_kobj); + + complete(&ls->ls_kobj_done); +} + static struct kobj_type dlm_ktype = { + .release = dlm_ls_release, .default_groups = dlm_groups, .sysfs_ops = &dlm_attr_ops, }; @@ -355,6 +363,8 @@ static void free_lockspace(struct work_struct *work) */ rhashtable_free_and_destroy(&ls->ls_rsbtbl, rhash_free_rsb, NULL); + kobject_put(&ls->ls_kobj); + wait_for_completion(&ls->ls_kobj_done); kfree(ls); } @@ -435,7 +445,10 @@ static int new_lockspace(const char *name, const char *cluster, ls->ls_lvblen = lvblen; atomic_set(&ls->ls_count, 0); init_waitqueue_head(&ls->ls_count_wait); + init_completion(&ls->ls_kobj_done); ls->ls_flags = 0; + ls->ls_kobj.kset = dlm_kset; + kobject_init(&ls->ls_kobj, &dlm_ktype); if (ops && dlm_config.ci_recover_callbacks) { ls->ls_ops = ops; @@ -567,9 +580,7 @@ static int new_lockspace(const char *name, const char *cluster, wait_event(ls->ls_recover_lock_wait, test_bit(LSFL_RECOVER_LOCK, &ls->ls_flags)); - ls->ls_kobj.kset = dlm_kset; - error = kobject_init_and_add(&ls->ls_kobj, &dlm_ktype, NULL, - "%s", ls->ls_name); + error = kobject_add(&ls->ls_kobj, NULL, "%s", ls->ls_name); if (error) goto out_recoverd; kobject_uevent(&ls->ls_kobj, KOBJ_ADD); @@ -582,7 +593,7 @@ static int new_lockspace(const char *name, const char *cluster, error = do_uevent(ls, 1, 0); if (error < 0) - goto out_recoverd; + goto out_kobj; /* wait until recovery is successful or failed */ wait_for_completion(&ls->ls_recovery_done); @@ -600,6 +611,8 @@ static int new_lockspace(const char *name, const char *cluster, do_uevent(ls, 0, 0); dlm_clear_members(ls); kfree(ls->ls_node_array); + out_kobj: + kobject_del(&ls->ls_kobj); out_recoverd: dlm_recoverd_stop(ls); out_callback: @@ -615,6 +628,7 @@ static int new_lockspace(const char *name, const char *cluster, rhashtable_destroy(&ls->ls_rsbtbl); out_lsfree: kobject_put(&ls->ls_kobj); + wait_for_completion(&ls->ls_kobj_done); kfree(ls); out: module_put(THIS_MODULE); @@ -740,6 +754,8 @@ static int release_lockspace(struct dlm_ls *ls, unsigned int release_option) dlm_user_daemon_available()) do_uevent(ls, 0, (release_option == DLM_RELEASE_RECOVER)); + kobject_del(&ls->ls_kobj); + dlm_recoverd_stop(ls); /* clear the LSFL_RUNNING flag to fast up @@ -759,8 +775,6 @@ static int release_lockspace(struct dlm_ls *ls, unsigned int release_option) dlm_delete_debug_file(ls); - kobject_put(&ls->ls_kobj); - xa_destroy(&ls->ls_recover_xa); kfree(ls->ls_recover_buf); -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462697.1673726 (Exim 4.92) (envelope-from ) id 1xLppK-00022T-R5; Tue, 27 Oct 2026 22:39:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462697.1673726; Tue, 27 Oct 2026 22:39: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 1xLppK-00022M-NV; Tue, 27 Oct 2026 22:39:30 +0000 Received: by outflank-mailman (input) for mailman id 1462697; Tue, 27 Oct 2026 22:39:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3HijhagcKCVE1A7zxABz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--irogers.bounces.google.com>) id 1xLppJ-0001wi-Iq for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLppI-009736-W1 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:29 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3HijhagcKCVE1A7zxABz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--irogers.bounces.google.com>) id 6ae1281b-e002-0a2a0a5209dd-0a2a4507cfa8-8 for ; Tue, 27 Oct 2026 23:39:28 +0100 Received: from [74.125.82.72] (helo=mail-dl1-f72.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3HijhagcKCVE1A7zxABz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--irogers.bounces.google.com>) id 6ae1281f-b4ea-0a2a45070019-4a7d5248cd11-3 for ; Tue, 27 Oct 2026 23:39:28 +0100 Received: by mail-dl1-f72.google.com with SMTP id a92af1059eb24-147be78cd56so953103c88.1 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140767; x=1793745567; 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=4zou/7CSV4h/YwAlF7A1OL9kEnFb2HIoLHCAQS8LrD8=; b=PX/O+NbUYP0xNm7jIc7VkjgbhjklmQO26J/JapSTWjZW/WJVUgHAcfzxu1DMG/PRkh rkYK8Y9tFY2noeH9OjFeIf6FHiYG2nUqEsWMu4B7eJEr/6xrxOdVoz/uD5p4fu/dPd0E m4h1NY44rbEwHzCXxuTEchuc1j4Els9XM6Os6hcY38K8W0ZoJnbS4LcxS+Wu/VBBmKXK uMq0Sz6Q7W3DOzWT1MWCJ2kwMqExQCgSPT2XItnxK+zP+KLBxRUOd+dm5eznCjtp9GLo Vbpf1+br8ii0vYahdrJhAHMdCh7xC+svpKwCXu45UWEd6pJfXsNATMSLwcFSGHrE+H2D MN3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140767; x=1793745567; 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=4zou/7CSV4h/YwAlF7A1OL9kEnFb2HIoLHCAQS8LrD8=; b=gRyry8ztGABLlgWgtGli5jviUy+uJMHGjYC6YLnzmIj4wP/F/B0CwRloc6ZQBNJpEa QLFBTL17UCqDZxew+rzUUab5tJomzA2KiLXCLINiNISf8FBl5E0jPyBlXBX70/CCEluj L75kdgih5kS//Q2mc1t+h/6EAvg3KH9pGl4LNDu8F+5s4BZaz8UVVWYhvimqpldapxLa kl7CrI0geXkaCpvb0TUna/GNBvLh6+k967Zinyw7XjL+a65k78uWn7xHgGMuIBN3rKjX M0jojvfaKgNdLaGqhLYqsLKnOPzJ3QGRy72oADGkTSoq7DZq3mZ3C4CeQFaIbKvZBGtQ Ys2w== X-Forwarded-Encrypted: i=1; AKwUvBwZeuwARHbQgf917Pbwa0VAhAqLd3Uy9RjugnzAEYYwuQn0IO2BPOsnGvlYQ2zEuyAbRRqU5NqWU6E=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ52GWssCSLdZ4dPKqHacczzlVLHVRryYYMF9fJKKlVSe7Ou1eM lXFqBCrA37KMm3hX7kK621cJsHCE/r5ezHK+/XHi3nGPwdMHrB6jpb7KGvtcYWKHKZa+gS/bYI0 yUR6v4Dwn+A== X-Received: from dlbqq10.prod.google.com ([2002:a05:7022:ed0a:b0:1a0:a0b4:204c]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:f115:b0:1a3:6040:bf78 with SMTP id a92af1059eb24-1a6cc34d07bmr917417c88.11.1793140766453; Tue, 27 Oct 2026 15:39:26 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:41 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-7-irogers@google.com> Subject: [PATCH v2 6/9] xen/sys-hypervisor: Add release callback to hyp_sysfs_kobj_type From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jeremy Fitzhardinge Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ef75cf/1793140768-A62C4AE4-CF504562/0/0 X-purgate-type: clean X-purgate-size: 1156 hypervisor_init() in drivers/base/hypervisor.c creates hypervisor_kobj with kobject_create_and_add() (which allocates a dynamic kobject using dynamic_kobj_ktype), and hypervisor_subsys_init() in drivers/xen/sys-hypervisor.c then overwrites hypervisor_kobj->ktype with &hyp_sysfs_kobj_type, which had no .release callback. Add hyp_sysfs_release() calling kfree(kobj) to preserve the dynamic kobject release behavior. Fixes: cff7e81b3dd7 ("xen: add /sys/hypervisor support") Signed-off-by: Ian Rogers --- drivers/xen/sys-hypervisor.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c index 91923242a5ae..0e8a2cd69fd6 100644 --- a/drivers/xen/sys-hypervisor.c +++ b/drivers/xen/sys-hypervisor.c @@ -659,7 +659,13 @@ static const struct sysfs_ops hyp_sysfs_ops = { .store = hyp_sysfs_store, }; +static void hyp_sysfs_release(struct kobject *kobj) +{ + kfree(kobj); +} + static const struct kobj_type hyp_sysfs_kobj_type = { + .release = hyp_sysfs_release, .sysfs_ops = &hyp_sysfs_ops, }; -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462699.1673735 (Exim 4.92) (envelope-from ) id 1xLppO-0002Mp-4l; Tue, 27 Oct 2026 22:39:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462699.1673735; Tue, 27 Oct 2026 22:39: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 1xLppO-0002Mb-0u; Tue, 27 Oct 2026 22:39:34 +0000 Received: by outflank-mailman (input) for mailman id 1462699; Tue, 27 Oct 2026 22:39:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3ISjhagcKCVQ4DA20DE2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--irogers.bounces.google.com>) id 1xLppM-0002Iq-MB for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLppM-004ylB-30 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:32 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3ISjhagcKCVQ4DA20DE2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--irogers.bounces.google.com>) id 6ae127f5-bab6-0a2a0a5309dd-0a2a450ce220-20 for ; Tue, 27 Oct 2026 23:39:32 +0100 Received: from [74.125.82.70] (helo=mail-dl1-f70.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3ISjhagcKCVQ4DA20DE2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--irogers.bounces.google.com>) id 6ae12822-f479-0a2a450c0019-4a7d5246acfa-3 for ; Tue, 27 Oct 2026 23:39:31 +0100 Received: by mail-dl1-f70.google.com with SMTP id a92af1059eb24-1a5005fd0f8so277494c88.0 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140770; x=1793745570; 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=aItLXVgOXAbsJZn2OZIWl+3TQwb1N1Woum6UsPYCRPI=; b=Ioo9vNsOIbzyq6RGky4VaneEVyGRZpLB4XhuZZlhRvY7B1btTIBLA+MIX1yDToaF3v I03oDUrL2kidXj93Y4KVFr7S3i/R8loJ4ELFQRtByayLxUA6GXy0xPzj34qwghFTDKRc 4pWA6qDLnolpDSHmlCO0aWeg6fkox0erCdGsZ81BElayR058PoJDoY0nF07X35asgPOt zop9jauvg34TVlgHeHIiRFeThHaqrNufkbgXYyy0RZgGXmXqnAx3JdXOW7ZLSOL28kOT n5WXakkgxnU4u+L97wptT/4KiRviqAvXMaIhRfh9U+agCHcUd4K84Q8VOLIUS5n3WrzE OJAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140770; x=1793745570; 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=aItLXVgOXAbsJZn2OZIWl+3TQwb1N1Woum6UsPYCRPI=; b=Ckve+TnYreSqE97O/Ur36Q9cQ86xp+l4XhKEqWeAmbyUt44CzGoHEhxkDzjbL/+bUo GiVeMgL2cNyNqqSywXCJ5wfK+jn8BPiof8i5niykmFjDeur7eRFxyupLnqRiAJsZNBQf 350yvzxXYxj8whOEPM2C5bDZsF/ajNFARt7owM+BHcvlc44Ik7sscFEhkiFXzPbJEilb n/puDvTiX6FU0nXYUDk8jTbQYwIZRU0JQAz7D/ma4fJekfYuGQLcBSkamgOXVcMimpOJ fEUB581sNbdFszBaJ1lmqbyKYV1REE8gvVMTZDRhGslLTTTVzuci+fyLFwpK31oQxC43 rBYA== X-Forwarded-Encrypted: i=1; AKwUvBxGxw/fpxC/iiYFlSRAaD/fl/b/9mhvDjm8PpIFgFLfAq+hpoeLDSP9jmgZ2TyJA0fjAdI+fURPQXY=@lists.xenproject.org X-Gm-Message-State: AFq9FYIdJwXWmaqww3nE/niIgbQLxubX7qnVkm8ekMooijd2+pD/5oxw BgoSQGlgShcooOurhWIaoBhky0M81P7+qeUdBvb7LyJMc5utmbA3gFSPboBYWbh2s/Zg5JvVi0h DNC613dPgAA== X-Received: from dld12.prod.google.com ([2002:a05:7022:30c:b0:191:45cb:f8d3]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:607:b0:166:af48:a2ba with SMTP id a92af1059eb24-1a6c2c71125mr1317138c88.0.1793140769446; Tue, 27 Oct 2026 15:39:29 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:42 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-8-irogers@google.com> Subject: [PATCH v2 7/9] ubifs: sysfs: Use kset_create_and_add() for ubifs_kset From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Richard Weinberger , Liu Shixin Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1793140772-00ACCA5B-6150469B/0/0 X-purgate-type: clean X-purgate-size: 2054 ubifs_kset was a static struct kset using a custom ubifs_ktype that had no default_groups and no .release callback. With CONFIG_DEBUG_KOBJECT_RELEASE=y, unloading the ubifs module while delayed kobject release is pending causes a use-after-free on the static kset. Replace the static ubifs_kset and empty ubifs_ktype with a dynamically allocated kset via kset_create_and_add(). Fixes: 203a55f04f66 ("ubifs: Fix memory leak in ubifs_sysfs_init()") Tested-by: Zhihao Cheng Reviewed-by: Zhihao Cheng Signed-off-by: Ian Rogers --- fs/ubifs/sysfs.c | 24 +++++++----------------- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/fs/ubifs/sysfs.c b/fs/ubifs/sysfs.c index dbf967dcf26e..e20931e3a62f 100644 --- a/fs/ubifs/sysfs.c +++ b/fs/ubifs/sysfs.c @@ -80,13 +80,7 @@ static const struct kobj_type ubifs_sb_ktype = { .release = ubifs_sb_release, }; -static const struct kobj_type ubifs_ktype = { - .sysfs_ops = &ubifs_attr_ops, -}; - -static struct kset ubifs_kset = { - .kobj = {.ktype = &ubifs_ktype}, -}; +static struct kset *ubifs_kset; int ubifs_sysfs_register(struct ubifs_info *c) { @@ -107,7 +101,7 @@ int ubifs_sysfs_register(struct ubifs_info *c) goto out_free; } - c->kobj.kset = &ubifs_kset; + c->kobj.kset = ubifs_kset; init_completion(&c->kobj_unregister); ret = kobject_init_and_add(&c->kobj, &ubifs_sb_ktype, NULL, @@ -139,18 +133,14 @@ void ubifs_sysfs_unregister(struct ubifs_info *c) int __init ubifs_sysfs_init(void) { - int ret; + ubifs_kset = kset_create_and_add("ubifs", NULL, fs_kobj); + if (!ubifs_kset) + return -ENOMEM; - kobject_set_name(&ubifs_kset.kobj, "ubifs"); - ubifs_kset.kobj.parent = fs_kobj; - ret = kset_register(&ubifs_kset); - if (ret) - kset_put(&ubifs_kset); - - return ret; + return 0; } void ubifs_sysfs_exit(void) { - kset_unregister(&ubifs_kset); + kset_unregister(ubifs_kset); } -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462702.1673744 (Exim 4.92) (envelope-from ) id 1xLppR-0002il-FM; Tue, 27 Oct 2026 22:39:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462702.1673744; Tue, 27 Oct 2026 22:39: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 1xLppR-0002iS-95; Tue, 27 Oct 2026 22:39:37 +0000 Received: by outflank-mailman (input) for mailman id 1462702; Tue, 27 Oct 2026 22:39:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3JCjhagcKCVc7GD53GH5DD5A3.1DBM3C-23K3AA7HIH.M3CEGD831I.DG5@flex--irogers.bounces.google.com>) id 1xLppP-0002Zb-9i for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLppO-00BmpO-Mq for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:34 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3JCjhagcKCVc7GD53GH5DD5A3.1DBM3C-23K3AA7HIH.M3CEGD831I.DG5@flex--irogers.bounces.google.com>) id 6ae1281f-8faa-0a2a0a5109dd-0a2a4505c02c-8 for ; Tue, 27 Oct 2026 23:39:34 +0100 Received: from [74.125.82.197] (helo=mail-dy1-f197.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3JCjhagcKCVc7GD53GH5DD5A3.1DBM3C-23K3AA7HIH.M3CEGD831I.DG5@flex--irogers.bounces.google.com>) id 6ae12825-4cb1-0a2a45050019-4a7d52c5dc58-3 for ; Tue, 27 Oct 2026 23:39:34 +0100 Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-359b81ad4e8so403043eec.0 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140772; x=1793745572; 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=MTMJFM/nqHoym7HFBiG90k6OXEIlh5WHZZg+1coUz9A=; b=HZ9h/KBBjcX7LR7MrsmMhLcJA52iIOj+wmYstaKgzFJFQx/dQRt0mjyP2WR3/vY7Js svelE5YZ3GDF+jJ5k4I3PLMgEb/QelGKlkJK0uZu9E9XrBXIuSSPKQlqWX7OCtydB8V4 yUAL8TTYZ5tYF7GwVXMq1JcKd+LKWaBzzmU8iGijxekax7Onj5V4FEPRYNhIoulGB78H HDY0yaJoBq2lJe3r82CCO6euoogEHcT6eNTE5yycrGjGTV1oqGsWz9El3pnqZIclnxEq HWRzf1NgA4NOZxIk2WK5C0IqtUzr+NOIVaHcP/qK1IHVrChogy8n1cq5VcnHFONe+zZb xCBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140772; x=1793745572; 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=MTMJFM/nqHoym7HFBiG90k6OXEIlh5WHZZg+1coUz9A=; b=ZWJL8t5zNrHEL1eaFPaO6eb1SrfAIcEIohawBUyVMixr0MNlLm917idhGnTQ5p57X+ Y3NOcB3AKmvoFMTVGFVqIqmTJeuBUnmc8xbfAUO+bCTew5BlMYTfYZ9p2lhMlkj1K51q xfuyFLYPZnV8nvgjdN+ls4PfGn3lUDp1RbLL7So28rPQ046U/6sMIWFeUFlmILlke0Q5 hATQTzopwJMnmeQ6nh5dKVotXpUG+Q3V3KQifhlda1tRSl6j+R7PwkrDy9bEVHoGkwpr QzBR5XsXzlO31HhQHGXs5vPWlfVBL+RrPyeQGwB2Bboh8LPZeZTCh526uZ0pZczyVvJy 6EeA== X-Forwarded-Encrypted: i=1; AKwUvBwgyLLo8eCssHdZCrbXwNn8Xx/SBcpMucllI+GySgZnfBquOkn4CnhGlcVcWqLFAtQTw4gjJd9/liI=@lists.xenproject.org X-Gm-Message-State: AFq9FYK0oCDB6fNig1mi0YrD/tMgfMGWLPnHxfgbXPnU5VP3H1qH04sH Sk++VKQdHGwDEoDNxjlpnOx66y7pTPT+d++/f58YA50YCOYPRKjQMMxzeE9lEQeq+A6bG1BEGdX yRRG3nRJQGg== X-Received: from dlea12-n1.prod.google.com ([2002:a05:701b:420c:10b0:1a4:c892:b166]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:701b:2813:b0:143:6525:f9f6 with SMTP id a92af1059eb24-1a6cd3a1575mr630918c88.13.1793140772067; Tue, 27 Oct 2026 15:39:32 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:43 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-9-irogers@google.com> Subject: [PATCH v2 8/9] drm/amdkfd: Free queue in procfs_queue_type kobject release callback From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Felix Kuehling , Alex Deucher , David Airlie , Simona Vetter , Amber Lin Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-c201ff/1793140774-738BE2A1-DF6C480E/0/0 X-purgate-type: clean X-purgate-size: 2750 struct queue embeds a struct kobject (q->kobj) for procfs entries, but procfs_queue_type had no .release callback and uninit_queue() freed q immediately after kfd_procfs_del_queue() called kobject_put(&q->kobj). With CONFIG_DEBUG_KOBJECT_RELEASE=y, this causes a use-after-free. Add kfd_procfs_queue_release() to free struct queue from the kobject release callback, change kfd_procfs_del_queue() to only remove the kobject from sysfs via kobject_del(), and drop the final reference in uninit_queue() via kobject_put(). Check q->kobj.state_in_sysfs before calling kobject_del() in kfd_procfs_del_queue() to avoid warnings if sysfs creation previously failed. Fixes: 6d220a7e7971 ("drm/amdkfd: Add queue information to sysfs") Signed-off-by: Ian Rogers --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12 +++++++++--- drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 5 ++++- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 226f52626e84..8e6136d52a50 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -512,7 +512,15 @@ static const struct sysfs_ops procfs_queue_ops = { .show = kfd_procfs_queue_show, }; +static void kfd_procfs_queue_release(struct kobject *kobj) +{ + struct queue *q = container_of(kobj, struct queue, kobj); + + kfree(q); +} + static const struct kobj_type procfs_queue_type = { + .release = kfd_procfs_queue_release, .sysfs_ops = &procfs_queue_ops, .default_groups = procfs_queue_groups, }; @@ -552,7 +560,6 @@ int kfd_procfs_add_queue(struct queue *q) if (ret < 0) { pr_warn("Creating proc//queues/%u failed", q->properties.queue_id); - kobject_put(&q->kobj); return ret; } @@ -697,11 +704,10 @@ static void kfd_procfs_add_sysfs_files(struct kfd_process *p) void kfd_procfs_del_queue(struct queue *q) { - if (!q || !q->process->kobj) + if (!q || !q->process || !q->process->kobj || !q->kobj.state_in_sysfs) return; kobject_del(&q->kobj); - kobject_put(&q->kobj); } int kfd_process_create_wq(void) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c index ae3e7c54014a..4666110aebe0 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c @@ -83,7 +83,10 @@ int init_queue(struct queue **q, const struct queue_properties *properties) void uninit_queue(struct queue *q) { - kfree(q); + if (q && q->kobj.state_initialized) + kobject_put(&q->kobj); + else + kfree(q); } #if IS_ENABLED(CONFIG_HSA_AMD_SVM) -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 22:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 22:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462708.1673753 (Exim 4.92) (envelope-from ) id 1xLppU-0003BI-Sp; Tue, 27 Oct 2026 22:39:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462708.1673753; Tue, 27 Oct 2026 22:39: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 1xLppU-0003B1-Ou; Tue, 27 Oct 2026 22:39:40 +0000 Received: by outflank-mailman (input) for mailman id 1462708; Tue, 27 Oct 2026 22:39:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3JyjhagcKCVoAJG86JK8GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--irogers.bounces.google.com>) id 1xLppT-00033U-Bv for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:39:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLppS-004ylB-P9 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:39:38 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3JyjhagcKCVoAJG86JK8GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--irogers.bounces.google.com>) id 6ae127f5-bab6-0a2a0a5309dd-0a2a450ce220-24 for ; Tue, 27 Oct 2026 23:39:38 +0100 Received: from [74.125.82.200] (helo=mail-dy1-f200.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3JyjhagcKCVoAJG86JK8GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--irogers.bounces.google.com>) id 6ae12829-f479-0a2a450c0019-4a7d52c8ddbb-3 for ; Tue, 27 Oct 2026 23:39:38 +0100 Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-35cbea41088so456649eec.1 for ; Tue, 27 Oct 2026 15:39: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=20260707 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=20260707; t=1793140776; x=1793745576; 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=36a0/HoL8yXBAoRB1lx62HZinWx8I5wnTQwOiZ4VBGs=; b=NcTekBwoVD3gDNCK2jFVv7zj4rESUe30z8BffvERuNLFp68r2QISh8Ow7DsjozvQ4I XjvViRK5B2naZ5FBIo/lps1SYDPwHRuQVKAWaeDsd1/04FGKWUMvwr1cx775UWIGHn79 2VAFZi8g44+omOuXN6aiaB0wndteHSkAymDo/39nJ7QzPHyBoHRWz5tQR+vGKsef5+TE 5GpRZbSxQpuK/0GA1X3vEqXNx0hCxQJOJQT7i+ewoOfXp5vRbR2nUuYeq+/+Nmg77/w0 3pl3aSeuv6eRS9Nyk9YhtqS6sFM9FR01QfzqkG1BUUYJy6gWl16HOqiu5WcxLEn368fg KnUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793140776; x=1793745576; 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=36a0/HoL8yXBAoRB1lx62HZinWx8I5wnTQwOiZ4VBGs=; b=uL6KyJrTsE8PUq9UyTjLtaNyl7oQu2cSyOtgOMmF1g9FsVQj/Sjs3PiNeqx0+gVyPC kDr/RWPa0HK8hmJSd80AWk0gZ2vy4oPvowkKj0NL0fiVK649k5nUHeVyhN4qEDW0GFFt BBdsKyNP7ZtI7MHL7CSrbwYdq2PzoWhmDd5w0xNRxZen+B2B/r0welK6xaL1tNfjrfNG AXYp2dd9aHftU45xbd5jd+/OLlZlCnKgzb3voCJtvj23W41zohjGECwmd1ktlHaA0PgB ScpSaQh97XgQNjlVy4D9hcMae1BdwBXcP1vwBDceNOOS9/coH7bhCDMvX/beXePxvtuY KZ3A== X-Forwarded-Encrypted: i=1; AKwUvBz8TIMV9H40LDCKl2SOxsp/Xcx2/VX3BzJ6Ll/afv4IR4AIyE6mczULFZoEQ5Ai8G8NJCeYshHrxV4=@lists.xenproject.org X-Gm-Message-State: AFq9FYKkXDbRPT54KFYueAkkZ2HAy5wo4kO6CiIiTWEAFxgNXpj21QVs th/rkIeB7U1wzXlW9rF+RLYvdKRslxtOQ01FNGKfD9d74xmZuumeEyOIeEfKTa2lRrjeT+ToIY+ A7eMUhcGolg== X-Received: from dycna22.prod.google.com ([2002:a05:7300:ea96:b0:369:de3f:acf9]) (user=irogers job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7300:d101:b0:369:5583:bf4c with SMTP id 5a478bee46e88-36a200c8c63mr1046676eec.28.1793140775931; Tue, 27 Oct 2026 15:39:35 -0700 (PDT) Date: Tue, 27 Oct 2026 15:38:44 -0700 In-Reply-To: <20261027223847.652884-1-irogers@google.com> Mime-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261027223847.652884-10-irogers@google.com> Subject: [PATCH v2 9/9] kobject: Require explicit initialization of struct kobj_type::release From: Ian Rogers To: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , "=?UTF-8?q?Christian=20K=C3=B6nig?=" , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ian Rogers , Catalin Marinas , Will Deacon , Mark Rutland , Len Brown , Vinod Koul , Frank Li , Alex Deucher , David Airlie , Simona Vetter , Dennis Dalessandro , Jason Gunthorpe , Leon Romanovsky , Nelson Escobar , Satish Kharat , "James E.J. Bottomley" , Helge Deller , Linus Walleij , Sebastian Reichel , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Huisong Li , Gao Xiang , Chao Yu , Yue Hu , Jingbo Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , Jaegeuk Kim , Mark Fasheh , Joel Becker , Joseph Qi , Heming Zhao , Johan Hovold , linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org, linux-rdma@vger.kernel.org, linux-parisc@vger.kernel.org, linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-f2fs-devel@lists.sourceforge.net, ocfs2-devel@lists.linux.dev Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-d25034/1793140778-006CEA5B-E55597BF/0/0 X-purgate-type: clean X-purgate-size: 15733 Documentation/core-api/kobject.rst states: "One important point cannot be overstated: every kobject must have a release() method, and the kobject must persist (in a consistent state) until that method is called. If these constraints are not met, the code is flawed. Note that the kernel will warn you if you forget to provide a release() method. Do not try to get rid of this warning by providing an \"empty\" release function." Annotate struct kobj_type::release with __must_init so the compiler diagnoses any struct kobj_type initializer that omits .release. For the remaining legacy struct kobj_type definitions where the kobject is static, per-CPU, permanent firmware structures, or embedded inside a devm- or parent-managed structure rather than freed by kobject_put(), explicitly initialize .release = NULL with a comment documenting why no release callback is provided. Where the existing teardown is not safe with CONFIG_DEBUG_KOBJECT_RELEASE, because the kobject's memory can be freed or cleared while the delayed kobject cleanup is still pending (ioat, kunpeng_hccs and omapfb display), the comment says so. Fixing those is left to follow-up patches; this change does not alter their behavior. Link: https://lpc.events/event/20/contributions/2392/ Signed-off-by: Ian Rogers --- arch/arm64/kernel/cpuinfo.c | 5 +++++ drivers/acpi/sysfs.c | 2 ++ drivers/dma/ioat/sysfs.c | 7 +++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c | 5 +++++ drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c | 10 +++++++++ drivers/infiniband/hw/hfi1/sysfs.c | 5 +++++ drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 2 ++ drivers/parisc/pdc_stable.c | 5 +++++ drivers/power/supply/ab8500_fg.c | 5 +++++ drivers/s390/char/sclp_mem.c | 2 ++ drivers/soc/hisilicon/kunpeng_hccs.c | 21 +++++++++++++++++++ .../fbdev/omap2/omapfb/dss/display-sysfs.c | 7 +++++++ .../fbdev/omap2/omapfb/dss/manager-sysfs.c | 5 +++++ .../fbdev/omap2/omapfb/dss/overlay-sysfs.c | 5 +++++ fs/erofs/sysfs.c | 10 +++++++++ fs/f2fs/sysfs.c | 15 +++++++++++++ fs/ocfs2/cluster/masklog.c | 5 +++++ include/linux/kobject.h | 2 +- 18 files changed, 117 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c index 94e6cd211d70..7a4ac8dd0b86 100644 --- a/arch/arm64/kernel/cpuinfo.c +++ b/arch/arm64/kernel/cpuinfo.c @@ -295,6 +295,11 @@ const struct seq_operations cpuinfo_op = { static const struct kobj_type cpuregs_kobj_type = { + /* + * Pre-existing: info->kobj is embedded in per-CPU cpu_data; + * cpuid_cpu_offline() only calls kobject_del(). + */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops, }; diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index a99373547126..1948b80e8a4a 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -973,6 +973,8 @@ static struct attribute *hotplug_profile_attrs[] = { ATTRIBUTE_GROUPS(hotplug_profile); static const struct kobj_type acpi_hotplug_profile_ktype = { + /* Pre-existing: hotplug->kobj is embedded in static struct acpi_scan_hotplug objects. */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops, .default_groups = hotplug_profile_groups, }; diff --git a/drivers/dma/ioat/sysfs.c b/drivers/dma/ioat/sysfs.c index e796ddb5383f..5ba44876eb96 100644 --- a/drivers/dma/ioat/sysfs.c +++ b/drivers/dma/ioat/sysfs.c @@ -167,6 +167,13 @@ static const struct attribute *const ioat_attrs[] = { ATTRIBUTE_GROUPS(ioat); const struct kobj_type ioat_ktype = { + /* + * Pre-existing: ioatdma_chan is freed by release_ioatdma(), not + * by kobject_put(). With CONFIG_DEBUG_KOBJECT_RELEASE the delayed + * kobject cleanup queued by ioat_kobject_del() may run after + * that kfree(), a use-after-free. + */ + .release = NULL, .sysfs_ops = &ioat_sysfs_ops, .default_groups = ioat_groups, }; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c index 17888cf54447..c2cccd924b03 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c @@ -885,6 +885,11 @@ static const struct attribute_group ualink_xcp_info_group = { }; static const struct kobj_type ualink_xcp_info_ktype = { + /* + * Pre-existing: xcp->ualink.kobj is embedded in struct amdgpu_xcp_mgr + * rather than freed individually by kobject_put(). + */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops }; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c index ab14079d1c42..0847134a1391 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c @@ -797,6 +797,11 @@ static const struct sysfs_ops xcp_cfg_res_sysfs_ops = { }; static const struct kobj_type xcp_cfg_res_sysfs_ktype = { + /* + * Pre-existing: xcp_res is embedded in struct amdgpu_xcp_cfg + * rather than freed individually by kobject_put(). + */ + .release = NULL, .sysfs_ops = &xcp_cfg_res_sysfs_ops, .default_groups = xcp_cfg_res_sysfs_groups, }; @@ -1061,6 +1066,11 @@ static const struct attribute_group amdgpu_xcp_attrs_group = { }; static const struct kobj_type xcp_sysfs_ktype = { + /* + * Pre-existing: xcp is embedded in struct amdgpu_xcp_mgr + * rather than freed individually by kobject_put(). + */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops, }; diff --git a/drivers/infiniband/hw/hfi1/sysfs.c b/drivers/infiniband/hw/hfi1/sysfs.c index 372cfd13dc61..5a1aca06b542 100644 --- a/drivers/infiniband/hw/hfi1/sysfs.c +++ b/drivers/infiniband/hw/hfi1/sysfs.c @@ -608,6 +608,11 @@ static const struct sysfs_ops sde_sysfs_ops = { }; static struct kobj_type sde_ktype = { + /* + * Pre-existing: sdma_engine is embedded in dd->per_sdma array + * rather than freed by kobject_put(). + */ + .release = NULL, .sysfs_ops = &sde_sysfs_ops, }; diff --git a/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c b/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c index fdb63a8fb997..df0e48070c2e 100644 --- a/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c +++ b/drivers/infiniband/hw/usnic/usnic_ib_sysfs.c @@ -245,6 +245,8 @@ static struct attribute *usnic_ib_qpn_default_attrs[] = { ATTRIBUTE_GROUPS(usnic_ib_qpn_default); static struct kobj_type usnic_ib_qpn_type = { + /* Pre-existing: usnic_ib_qp_grp is embedded in RDMA core-managed struct usnic_ib_qp_grp. */ + .release = NULL, .sysfs_ops = &usnic_ib_qpn_sysfs_ops, .default_groups = usnic_ib_qpn_default_groups, }; diff --git a/drivers/parisc/pdc_stable.c b/drivers/parisc/pdc_stable.c index 6b567a74fc2c..2f530e8c6757 100644 --- a/drivers/parisc/pdc_stable.c +++ b/drivers/parisc/pdc_stable.c @@ -484,6 +484,11 @@ ATTRIBUTE_GROUPS(paths_subsys); /* Specific kobject type for our PDC paths */ static const struct kobj_type ktype_pdcspath = { + /* + * Pre-existing: pdcspath_entry instances are static; lifetime + * is not controlled by kobject_put(). + */ + .release = NULL, .sysfs_ops = &pdcspath_attr_ops, .default_groups = paths_subsys_groups, }; diff --git a/drivers/power/supply/ab8500_fg.c b/drivers/power/supply/ab8500_fg.c index e6b5efdf5dc9..d62411e4f535 100644 --- a/drivers/power/supply/ab8500_fg.c +++ b/drivers/power/supply/ab8500_fg.c @@ -2531,6 +2531,11 @@ static struct attribute *ab8500_fg_attrs[] = { ATTRIBUTE_GROUPS(ab8500_fg); static const struct kobj_type ab8500_fg_ktype = { + /* + * Pre-existing: fg_kobject is embedded in devm-allocated struct + * ab8500_fg; ab8500_fg_sysfs_exit() only calls kobject_del(). + */ + .release = NULL, .sysfs_ops = &ab8500_fg_sysfs_ops, .default_groups = ab8500_fg_groups, }; diff --git a/drivers/s390/char/sclp_mem.c b/drivers/s390/char/sclp_mem.c index 6df1926d4c62..2fb7271dce36 100644 --- a/drivers/s390/char/sclp_mem.c +++ b/drivers/s390/char/sclp_mem.c @@ -305,6 +305,8 @@ static ssize_t sclp_memmap_on_memory_store(struct kobject *kobj, struct kobj_att } static const struct kobj_type ktype = { + /* Pre-existing: permanent firmware kobjects, never freed */ + .release = NULL, .sysfs_ops = &kobj_sysfs_ops, }; diff --git a/drivers/soc/hisilicon/kunpeng_hccs.c b/drivers/soc/hisilicon/kunpeng_hccs.c index 0cc2953d59a5..da7a64c95058 100644 --- a/drivers/soc/hisilicon/kunpeng_hccs.c +++ b/drivers/soc/hisilicon/kunpeng_hccs.c @@ -1038,6 +1038,13 @@ static struct attribute *hccs_port_default_attrs[] = { ATTRIBUTE_GROUPS(hccs_port_default); static const struct kobj_type hccs_port_type = { + /* + * Pre-existing: hccs_port_info is allocated via devm_kzalloc() + * rather than freed by kobject_put(). With + * CONFIG_DEBUG_KOBJECT_RELEASE the delayed kobject cleanup may run + * after devm frees it on unbind, a use-after-free. + */ + .release = NULL, .sysfs_ops = &hccs_comm_ops, .default_groups = hccs_port_default_groups, }; @@ -1110,6 +1117,13 @@ static struct attribute *hccs_die_default_attrs[] = { ATTRIBUTE_GROUPS(hccs_die_default); static const struct kobj_type hccs_die_type = { + /* + * Pre-existing: hccs_die_info is allocated via devm_kzalloc() + * rather than freed by kobject_put(). With + * CONFIG_DEBUG_KOBJECT_RELEASE the delayed kobject cleanup may run + * after devm frees it on unbind, a use-after-free. + */ + .release = NULL, .sysfs_ops = &hccs_comm_ops, .default_groups = hccs_die_default_groups, }; @@ -1213,6 +1227,13 @@ static struct attribute *hccs_chip_default_attrs[] = { ATTRIBUTE_GROUPS(hccs_chip_default); static const struct kobj_type hccs_chip_type = { + /* + * Pre-existing: hccs_chip_info is allocated via devm_kzalloc() + * rather than freed by kobject_put(). With + * CONFIG_DEBUG_KOBJECT_RELEASE the delayed kobject cleanup may run + * after devm frees it on unbind, a use-after-free. + */ + .release = NULL, .sysfs_ops = &hccs_comm_ops, .default_groups = hccs_chip_default_groups, }; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c index ae937854403b..452920a4e2a9 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c @@ -304,6 +304,13 @@ static const struct sysfs_ops display_sysfs_ops = { }; static struct kobj_type display_ktype = { + /* + * Pre-existing: dssdev->kobj is embedded in struct omap_dss_device + * and zeroed in display_uninit_sysfs() right after kobject_put(). + * With CONFIG_DEBUG_KOBJECT_RELEASE that memset() clobbers the + * pending delayed kobject cleanup. + */ + .release = NULL, .sysfs_ops = &display_sysfs_ops, .default_groups = display_sysfs_groups, }; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c index 1b644be5fe2e..40ec750f4315 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c @@ -496,6 +496,11 @@ static const struct sysfs_ops manager_sysfs_ops = { }; static struct kobj_type manager_ktype = { + /* + * Pre-existing: mgr->kobj is embedded in static managers[] and + * zeroed in dss_manager_kobj_uninit(). + */ + .release = NULL, .sysfs_ops = &manager_sysfs_ops, .default_groups = manager_sysfs_groups, }; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c index 1da4fb1c77b4..4d333031b18d 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c @@ -429,6 +429,11 @@ static const struct sysfs_ops overlay_sysfs_ops = { }; static struct kobj_type overlay_ktype = { + /* + * Pre-existing: ovl->kobj is embedded in static overlays[]; + * dss_overlay_kobj_uninit() drops the kobject ref. + */ + .release = NULL, .sysfs_ops = &overlay_sysfs_ops, .default_groups = overlay_sysfs_groups, }; diff --git a/fs/erofs/sysfs.c b/fs/erofs/sysfs.c index dfcec9376cd5..2ea6773cd98f 100644 --- a/fs/erofs/sysfs.c +++ b/fs/erofs/sysfs.c @@ -238,6 +238,11 @@ static const struct kobj_type erofs_sb_ktype = { static const struct kobj_type erofs_ktype = { .default_groups = erofs_groups, .sysfs_ops = &erofs_attr_ops, + /* + * Pre-existing: erofs_root is a static struct kset; lifetime + * is not controlled by kobject_put(). + */ + .release = NULL, }; static struct kset erofs_root = { @@ -247,6 +252,11 @@ static struct kset erofs_root = { static const struct kobj_type erofs_feat_ktype = { .default_groups = erofs_feat_groups, .sysfs_ops = &erofs_attr_ops, + /* + * Pre-existing: erofs_feat is a static struct kobject; lifetime + * is not controlled by kobject_put(). + */ + .release = NULL, }; static struct kobject erofs_feat = { diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c index 430356e500af..6e15695cb75f 100644 --- a/fs/f2fs/sysfs.c +++ b/fs/f2fs/sysfs.c @@ -1683,6 +1683,11 @@ static const struct kobj_type f2fs_sb_ktype = { static const struct kobj_type f2fs_ktype = { .sysfs_ops = &f2fs_attr_ops, + /* + * Pre-existing: f2fs_kset is a static struct kset; lifetime + * is not controlled by kobject_put(). + */ + .release = NULL, }; static struct kset f2fs_kset = { @@ -1697,6 +1702,11 @@ static const struct sysfs_ops f2fs_feat_attr_ops = { static const struct kobj_type f2fs_feat_ktype = { .default_groups = f2fs_feat_groups, .sysfs_ops = &f2fs_feat_attr_ops, + /* + * Pre-existing: f2fs_feat is a static struct kobject; lifetime + * is not controlled by kobject_put(). + */ + .release = NULL, }; static struct kobject f2fs_feat = { @@ -1711,6 +1721,11 @@ static const struct sysfs_ops f2fs_tune_attr_ops = { static const struct kobj_type f2fs_tune_ktype = { .default_groups = f2fs_tune_groups, .sysfs_ops = &f2fs_tune_attr_ops, + /* + * Pre-existing: f2fs_tune is a static struct kobject; lifetime + * is not controlled by kobject_put(). + */ + .release = NULL, }; static struct kobject f2fs_tune = { diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c index 563881ddbf00..ff8a1cf51e72 100644 --- a/fs/ocfs2/cluster/masklog.c +++ b/fs/ocfs2/cluster/masklog.c @@ -147,6 +147,11 @@ static const struct sysfs_ops mlog_attr_ops = { static struct kobj_type mlog_ktype = { .default_groups = mlog_default_groups, .sysfs_ops = &mlog_attr_ops, + /* + * Pre-existing: mlog_kset is a static struct kset; lifetime + * is not controlled by kobject_put(). + */ + .release = NULL, }; static struct kset mlog_kset = { diff --git a/include/linux/kobject.h b/include/linux/kobject.h index 55e37a5d405e..8a1332030884 100644 --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -114,7 +114,7 @@ void kobject_get_ownership(const struct kobject *kobj, kuid_t *uid, kgid_t *gid) char *kobject_get_path(const struct kobject *kobj, gfp_t flag); struct kobj_type { - void (*release)(struct kobject *kobj); + void (*release)(struct kobject *kobj) __must_init; const struct sysfs_ops *sysfs_ops; const struct attribute_group **default_groups; const struct kobj_ns_type_operations *(*child_ns_type)(const struct kobject *kobj); -- 2.56.0.313.g2479322e68-goog From xen-devel-bounces@lists.xenproject.org Tue Oct 27 23:16:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 23:16:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462759.1673762 (Exim 4.92) (envelope-from ) id 1xLqOg-0003un-ID; Tue, 27 Oct 2026 23:16:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462759.1673762; Tue, 27 Oct 2026 23:16: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 1xLqOg-0003ug-Ez; Tue, 27 Oct 2026 23:16:02 +0000 Received: by outflank-mailman (input) for mailman id 1462759; Tue, 27 Oct 2026 23:16:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLqOe-0003uR-Rr for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:16:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLqOc-0018HZ-Bg for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 00:15:58 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae13089-8faa-0a2a0a5109dd-0a2a45068be8-14 for ; Wed, 28 Oct 2026 00:15:57 +0100 Received: from [52.101.57.37] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae130ac-195a-0a2a45060019-346539258b33-3 for ; Wed, 28 Oct 2026 00:15:57 +0100 Received: from BN7PPF5F16C5C9C.namprd12.prod.outlook.com (2603:10b6:40f:fc02::607) by DM6PR12MB4186.namprd12.prod.outlook.com (2603:10b6:5:21b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 23:15:52 +0000 Received: from BN7PPF5F16C5C9C.namprd12.prod.outlook.com ([fe80::67a7:9feb:71ef:964a]) by BN7PPF5F16C5C9C.namprd12.prod.outlook.com ([fe80::67a7:9feb:71ef:964a%8]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 23:15: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=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=SQ0rtxs2yHtePTZKSKD03j2Lp/EMu3QXDUf/w94nK9S+l9CYSX+7Cr9paPIDE4/M19m4Ca8X79C0uz89dK22pQ72n+cDOzmWDU3wG0TK0yKs4K0jp/3oIuLOfP+nbdP0y8i3vmhQd6gwRl02mrcu4ByiN+RZ8GhgbCqALGUlndhuhHv5OsXsAxiLkHufzubfHg7vmeVMkxluO80yGDKOOnS0fKbHULE0sAh1LIqaFZh7Oc+5k5hucReBYuB1hA4t0UzQYIJe2FEpnsVIbRa9NCcLN7pveLT71fbGYNPKuH2nmC/bxE/gcjOhOCp6OTi2iVqnf3pdkgdpQpEn7LUOPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7ISyHKlVAcM0/DZJiGCw/9XLIFyiBD/SzVNJUBpkA0g=; b=b0JQW2AEqPk0iP8a9Zub+egPaFvQ3Dhf84zHirwe+SMZ7cbPs0/46tOcyBL2VHwrITCNhqMvFDlSoVfjuzHpvUShZ2rRyprTXr+2xJHEoJtCrTCq/qSxBvu1X+whIr0SBZqudOvFV+Hk0pqnT9+l0aBVaqR9sTE4zuLh7oD9DA/M4D0Ueo2m9Y8cv2Gf98xBykKP/uu4UIBVJHmiEFpJmW4xFNhe6B0hlBOktB/K8r+61T/36+0AhC60Iv3KqqvTCz8hoMyjiY36xf8h5RBGR+GrDYg27t4fE/Kc+iK6EFaxySSCcUo3nJ6cU/d5ZkkJsU5IyxzbTYJgerhci1O+lg== 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=7ISyHKlVAcM0/DZJiGCw/9XLIFyiBD/SzVNJUBpkA0g=; b=Gt/46kowYNiZfGLkAVE6OaDkSSnYpqckrOor/qJPeSdsHwKMTjjCglaYc28asPRHN0TIJ5YbjWWz+FYDCNfl7LBI4K+P4kmPsVpQwcgoeixgHICmsdDLcX6F6xw3v88rW98z6lgDsR4c0TCgFyOXraesRF/6osIb1OZDO9j2J/Y= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <34272fe1-e5cb-490e-9053-a2fa72f29a10@amd.com> Date: Tue, 27 Oct 2026 19:15:49 -0400 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 8/9] drm/amdkfd: Free queue in procfs_queue_type kobject release callback To: Ian Rogers , Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , =?UTF-8?Q?Christian_K=C3=B6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Alex Deucher , David Airlie , Simona Vetter , Amber Lin References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-9-irogers@google.com> Content-Language: en-US From: Felix Kuehling Organization: AMD Inc. In-Reply-To: <20261027223847.652884-9-irogers@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: YT1PR01CA0099.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:2c::8) To BN7PPF5F16C5C9C.namprd12.prod.outlook.com (2603:10b6:40f:fc02::607) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PPF5F16C5C9C:EE_|DM6PR12MB4186:EE_ X-MS-Office365-Filtering-Correlation-Id: c4a9363e-e46d-4dba-1360-08df34803e8c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|7416014|376014|261009223027099003|261022105027099003|261021121427099003|261021123027099003|10067099003|56012099006|22082099003|18002099003|4143699003|11063799006|261026140227099003; X-Microsoft-Antispam-Message-Info: DSmAC/LXxQNwDa5i5URmYnYa+8b0/OwMVhNeh3ZW0NuqAJafHKuOnQaOV0lIwiLh4xwlaBNevUZsjqmNUxBpst2EwayM/QPsvWOCH0nAQ7Ouwlh2Xxrx5NbkBIBXKIT1DqRqeULra7VgJq+BY7jk8uBLBM6q/X4zWFfSe30Dw2M/22y2CzhhaNFeBZwxvLStpgYWP5LPHl1fSHxHXphIwW6FLRkZPM1oiOpWa5Wj5GAr1qWDL/VJ6Yng12EqO5soAG290Xaytsxguy25IQ9zDRdFrF/+qqV9RT8gSDSTnNOwV7ERKIKIi1G8Z/ivMVfMoFHiCrIRR1Y9VYfRwMRW/wCp68FhBilOa8m3tW1zyUagPjSy31NY1yS9ChLCORD1FtVrn3A0xQ85Nr4kZcDm9WQU9kYFKhzppGECZlJ9g7Mx8fmoN/Yqfclcu37pAXmQFyVLWlMAEXHqFTLhtC7gh35ILFxRPgDh2HcGtsCQYl9Jx4qErnS7ttXoPClfclYDED+WsPGOSE7/5NzeoleF2c47cTgMdb/WC+R/4X/WTPFkvm7W18xysyPN656LB5laecoHSmWC61nJF0Rj9CpKopp67Fn+6SIj542SLGThROjCygcddKDvn4sWrWAafoxmVK8LL3yRIU6av/Rat8GCaOFUQAtOq09LPlAM5nOv2Fk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN7PPF5F16C5C9C.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(7416014)(376014)(261009223027099003)(261022105027099003)(261021121427099003)(261021123027099003)(10067099003)(56012099006)(22082099003)(18002099003)(4143699003)(11063799006)(261026140227099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?empiQldXdGliaGFsc1JwOFdmQWViK0VFMlV5Vi80MnI1WW9tc1ZiSmNVN0VZ?= =?utf-8?B?VVlhOHVzVFliZ0NScEx0OUxNVm13eUppMm9OU25NRGNUcWRrWFYwaVl4dDg2?= =?utf-8?B?RUU3S2dPSk1taGxzbU1LV3lRQUhDK0FOcFZrdTBtQ29YeW43cnB2RnQyV0F2?= =?utf-8?B?SlVET3F3d0V6aU42S3dwSXIzaGdLOFo2THJwTEx4YXRDVHdWR1pzcjN5TUtF?= =?utf-8?B?Y1pEKytxd3QyaUJQQmtkRWVNWG91eFcycWlvKzBldjhGZk82em0xQ09sV0VC?= =?utf-8?B?R0VFZW90dUpLeDF4TVI1U2tLN0kycXlpRnplRlR3SzFPRDlqcjdoS3hKbks4?= =?utf-8?B?RXBIK1d1cDIrbjJjUWc0RVdKZGltKzdPNFBlVUx5MTRTSmZER2g3NTlLNUFn?= =?utf-8?B?WU5DOU84OG82cE8zc2ZBUVJYT3dxQ0JtemUxODk2QXpUb2xESG1RUzdid1B5?= =?utf-8?B?ZnZneE03VHk1S1BhRzhtNE1XQmxQOVRPb05IOUhaeUhqblVtVExxR2ovOUdC?= =?utf-8?B?NjNIbE91c2JwcXJtYktKN2ZDaDAzeVZ1YkErT2Q2RVJDc3Q4bDc0aHFhZVNX?= =?utf-8?B?V1hMUWZKU0t2R01HVEhaTEVKamFqMUZXd1luS2NaM0ozKzV1dldwUDlaMkRk?= =?utf-8?B?YTljQlN1SXVJQlM0UjNrSWdieVpMWFdESEI1STNQVHJUK3k5eW1rYWRLbXA0?= =?utf-8?B?V0g0bmYwSlBLcksrNUZ5NlJyUGM3bWw3TDlCR2Izc2U5STNpRGxKUEthN2cv?= =?utf-8?B?TjhyYStvUDhVTjFIYVNDenJJVHFSZ2JpTmVHK0VEYVZKSlByVC9QS0pFcVJ0?= =?utf-8?B?emI2ekJBVFpXNXozYnVLRXdTUURLb2VDeldlOFE3MERLVlZYWnVzSGhkVDlt?= =?utf-8?B?YW94OTFabFhWem5pdEhQWlRDMFZNMldkUmJ3dXdjdnE2R0FudUdXZzdLM2lG?= =?utf-8?B?Q1JkWXh5NVpGRFFOdGtNS2oxUnZ2M1JwbjBtV0s2Y1BIT1NuZ0JWTCs0Q01J?= =?utf-8?B?ZUJINmtIY1ZlRjdUVmNESENuSUNQV25pdTBaaXNHVEs3K1FYSU4xYlcvN09m?= =?utf-8?B?SllmR0NqRkxFcUh4ZEJYekJpOGpHdDAxRGFJNUJUQ3RjODQzZUN2aVlVOWNw?= =?utf-8?B?TEM0SFZrcE0yR1A0bFNoK1lHK2VOZXE2dENJcXZQanBRckJKUTh5elVKOU9O?= =?utf-8?B?RVFmTjhrTkZnTHN0RzFDTEkxR2hMUW9zYTBJNnBTbnRhMWVEUmphanFmT1E4?= =?utf-8?B?YVBKeE9FdUNNZEtZUm5lZGp6NGVRUnRudGhSWGROd2E5OEE3blArVVFvTmI5?= =?utf-8?B?cHpEZm1TUGpYZVNjSzZFeHBTeGNFYm1FUTIwbmVGazh3NmM3MHZtSkREZjBh?= =?utf-8?B?d1pndkJnUEJaR0ZMUUJyb2greDJ3OHJRRE8xTy93SVpuamNaakVtNVhOc0pL?= =?utf-8?B?WG5KZDdhcGRzZG9zTCtpOGJqZFY2dmswVjBmMjR6aDYyc2JjK2s3MDJ5M1R0?= =?utf-8?B?bHNNSk9mN0FPUjhCcWRKUW5mQnBqUStZU1pobllGSGdUa0h6WjBld203OE8w?= =?utf-8?B?TytZc1ZpekF3cTJxakZvQU94dUdLT2hHTVIxKzRaMldRQk9HTTVRcS9hNm45?= =?utf-8?B?WDJIK0h4TUJyUVNqSkk1RTJRTGYwY3dvSWdrNW45MnErY3FlS3BFc280SFE0?= =?utf-8?B?MXNNM203SnA4VGMzMnMycVpSdjdlWENnSEQ4dlNzSHF1ckV0RzBiZ0xLKzcw?= =?utf-8?B?anJZS01PZUpOTVJIa2h3VXFRTzd0YlBySVIwN2NqQ3UyNnM1d09Bc0YrVEVj?= =?utf-8?B?VTk2d0ZINllJWWh0bmtXdmw3dlhyTVEyL1B2a2gwSFY1dEM5c3NYWUFLTmp5?= =?utf-8?B?cVUvM3ZWRkwxTnQyQ3UyeUUwWS96QVgvamo0c21UVTYzOFlaZWRmVWxQTU92?= =?utf-8?B?ZzhEZmtYVkVkTm9ldER3RDMrS3ZqMDBZZEp1Y1ZxVnhDS2lFOTRoR1F3OWVi?= =?utf-8?B?NmFocUZqT2pIakJlT2FnY2ZGdFZNL0Q5aDhGOWNxT3dmbk1tOHpxZGk4TzZO?= =?utf-8?B?c3pucmhJT2ZqZFpvSDRTN0dqYW5ITzFtQVBBQlhKUi8zcEtsdlJKOUFEd2k3?= =?utf-8?B?KzVzS3ZWZ1FDODJnYlQ3YzBGL0ZDaVJNOUJQdGJEVHhCdjZoWGZ5SEs0T1JT?= =?utf-8?B?UXJBeWZBVWRpaEJKU2ViQldVbEN3T3pKb1AxdlNTdkZOTGVUU1d0VmdjYWNj?= =?utf-8?B?T0Y0a3FYcFRwTzdqLzFhNjRGd0Z0VTZaR0dhaWFBNmhqVDdWd3gvdDFJbGpR?= =?utf-8?B?dm0weUVFNDI4VVNXWVZIbVp0L1g4ODlKOWREaE00SjRFSjJ0M0liZz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4a9363e-e46d-4dba-1360-08df34803e8c X-MS-Exchange-CrossTenant-AuthSource: BN7PPF5F16C5C9C.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 23:15:52.0995 (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: Ob+TKLRgRvAPv0Q9NjDGMWPP+1+Q+RZGLPVUAzRJKfxvNbAWmbA/GcQ++WN0aIUSZde9N19st+by1XpDYPKkRg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4186 X-purgate-ID: tlsNG-16d1c6/1793142957-F647377B-426437BA/0/0 X-purgate-type: clean X-purgate-size: 2994 On 2026-10-27 18:38, Ian Rogers wrote: > struct queue embeds a struct kobject (q->kobj) for procfs entries, but > procfs_queue_type had no .release callback and uninit_queue() freed q > immediately after kfd_procfs_del_queue() called kobject_put(&q->kobj). > With CONFIG_DEBUG_KOBJECT_RELEASE=y, this causes a use-after-free. > > Add kfd_procfs_queue_release() to free struct queue from the kobject > release callback, change kfd_procfs_del_queue() to only remove the > kobject from sysfs via kobject_del(), and drop the final reference in > uninit_queue() via kobject_put(). Check q->kobj.state_in_sysfs before > calling kobject_del() in kfd_procfs_del_queue() to avoid warnings if > sysfs creation previously failed. > > Fixes: 6d220a7e7971 ("drm/amdkfd: Add queue information to sysfs") > Signed-off-by: Ian Rogers Reviewed-by: Felix Kuehling > --- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12 +++++++++--- > drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 5 ++++- > 2 files changed, 13 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c > index 226f52626e84..8e6136d52a50 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c > @@ -512,7 +512,15 @@ static const struct sysfs_ops procfs_queue_ops = { > .show = kfd_procfs_queue_show, > }; > > +static void kfd_procfs_queue_release(struct kobject *kobj) > +{ > + struct queue *q = container_of(kobj, struct queue, kobj); > + > + kfree(q); > +} > + > static const struct kobj_type procfs_queue_type = { > + .release = kfd_procfs_queue_release, > .sysfs_ops = &procfs_queue_ops, > .default_groups = procfs_queue_groups, > }; > @@ -552,7 +560,6 @@ int kfd_procfs_add_queue(struct queue *q) > if (ret < 0) { > pr_warn("Creating proc//queues/%u failed", > q->properties.queue_id); > - kobject_put(&q->kobj); > return ret; > } > > @@ -697,11 +704,10 @@ static void kfd_procfs_add_sysfs_files(struct kfd_process *p) > > void kfd_procfs_del_queue(struct queue *q) > { > - if (!q || !q->process->kobj) > + if (!q || !q->process || !q->process->kobj || !q->kobj.state_in_sysfs) > return; > > kobject_del(&q->kobj); > - kobject_put(&q->kobj); > } > > int kfd_process_create_wq(void) > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c > index ae3e7c54014a..4666110aebe0 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c > @@ -83,7 +83,10 @@ int init_queue(struct queue **q, const struct queue_properties *properties) > > void uninit_queue(struct queue *q) > { > - kfree(q); > + if (q && q->kobj.state_initialized) > + kobject_put(&q->kobj); > + else > + kfree(q); > } > > #if IS_ENABLED(CONFIG_HSA_AMD_SVM) From xen-devel-bounces@lists.xenproject.org Tue Oct 27 23:54:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Oct 2026 23:54:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462771.1673771 (Exim 4.92) (envelope-from ) id 1xLqzI-00031k-Ao; Tue, 27 Oct 2026 23:53:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462771.1673771; Tue, 27 Oct 2026 23:53: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 1xLqzI-00031d-7h; Tue, 27 Oct 2026 23:53:52 +0000 Received: by outflank-mailman (input) for mailman id 1462771; Tue, 27 Oct 2026 23:53:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLqzG-00031X-Gz for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:53:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLqzE-009EGn-QQ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 00:53:48 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae13982-2eae-0a2a0a5409dd-0a2a45038b0c-2 for ; Wed, 28 Oct 2026 00:53:48 +0100 Received: from [52.101.72.103] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1398c-fae8-0a2a45030019-346548678a98-3 for ; Wed, 28 Oct 2026 00:53:48 +0100 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by BESPR03MB255357.eurprd03.prod.outlook.com (2603:10a6:b10:12a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 23:53:45 +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.0546.021; Tue, 27 Oct 2026 23:53: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=PKdSEMFnBzO5OoVsZAr7NjGW5OD2qUOpDhtHmLaRFKffETwupQxHCRouuvYHE39Q/aJzRpk3XXjjFhCi6b5pPXTAbXNHoz+GSdWb6InHCyN2FUC368cWwgHZUqJK8mGp4dCM4oKbfOA67nUw/GBXAjHJMQUrYzYPpdMx7Lndu3nAKlT2w/zujy9x2Do4HDSRPKn3L19aot5lX3SHYCrI5UkhM4wj43fEUp6+Tx6haf8ek4HYccbbdQGUvs7sjfG4zqneib11aAAs2ZUQserCLF/NwS9DV6K0fQ36mTlh7BF7vFFWhXoLead5B4g7u9uvedrK40dYqgAE1Ki/sx4gSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=byJ9sFmz24t4mtqdkmgsDp+GwT4BJiF9LkfjFfCoY0U=; b=vIZevLxj1kC9OX2a+z+j4mfrdMRDNF0TJsejHBwypw0wlPeYzwGHhMVIMgBvOWhakL1AAZarlqhIP4Xz1tuw8AwJcYwWPFBG6tflsF2iDIYLq9vPqEVMFxagQfaEhxteXFU0XSQjQDIAaFtaESHi85h1S+2qcYYtDD5JSyMBqqtJXMDXvw1+INDt2NYT7SQxhucsS92X6fXG/VO/mKo/qO2Qpadc5G5e+GsDSKhCEys6TUR9/xUqj7QzHEU8h/QJ/4bw0UJEA0guffXAA1VTksddTshOhhc9uHlpEWsfrP+e5h3bs7J26MpSGGZ+qtj/l5G9RkI7BoI5/lpjhpfEig== 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=byJ9sFmz24t4mtqdkmgsDp+GwT4BJiF9LkfjFfCoY0U=; b=Qh0YDb3HbUjkQndFsA6HcZMbZe4qJJpkSlJGvTQV9J2bdm4tK6K24zZStIABwTtcDQl9gHHqE0IqLic+dQh75qUD6fV5qVXOVIR7jhCeFWRDV3s5k2KJBevFkn/Ie7J1hcFSYh5Uh69WWGoGXv9bXyAl7lc6lF86lDlZlSmzKus3pBKGiCsBxAzEJW6uNyhm62QEfE4epGAwK3mstDJu0X1pRLm3G/cLXw/VHwIOwi0mLgS3DvYMpNt0wKoK/ra6w2QCEKWAALD4Ka0xJZhJhe7fpGjVJSWpO/3pAdtuEu2FzsblawHpgkDkZjmbBFcZqURztf8wNrYLHrFUxsC4Qg== 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: Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk Subject: [PATCH] arm/smmuv3: clean stream tables for non-coherent hardware Date: Wed, 28 Oct 2026 01:53:35 +0200 Message-ID: X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: AM9P250CA0018.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:21c::23) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|BESPR03MB255357:EE_ X-MS-Office365-Filtering-Correlation-Id: bce4e7fa-7d9d-4e55-79e1-08df3485898b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|6133799003|18002099003|56012099006|261022075727099003|11063799006|10067099003|261009223027099003|261021123027099003|261021121427099003|261022105027099003|261026140227099003; X-Microsoft-Antispam-Message-Info: rX7FS6fctSbEZaOIS5Aw/+oTWcQeHlrd7DYmLF3pj3gqJ9a9E3JMZVZDqGJkIZ0TsIRojP78XmFyfcRNKNR5ucQOAi/Y20q/9WWuUcr51CS5aTzP/D2xP+tluj/CEQAA/mA/dKX0ucglP/Reuw+1PVylwcb2IFHbBXSXWJ56kYt463zgZl48i/cpOvKINGU8J2M7fQIJS9UXY18EWCzs+shDZwg9iKz8ZYbc7EJByOEogojwPSzTjJEewjQ9XXgtNql0ABFoYpDiE+Pjxy4kqCtU6r0XZp61bi9kSpiOPZXQN+cCRB73RrWZ4Crnk2kPNjXx76BSI1Lv67flV1PKS9VxME2IfxeYrWwbEuR07Two17U7B8GxhcepjNIXz3ggYaa1/e/KswdM+j7ycghC0Y7k6pVEsALJ0d/2l6H5hg/DkPufXi2xRw3yVFOKh7kqO0FbmyInhmGTSp2QVAip3yfoBt4fq2UuANpD/9CbjS5pkLgNn8I5HZ0CrfGL6uI09GyByTCGp+P85pBvvdg8fHV7cT9DJOw8GgbLv/MXwme/0G5RraipkKb5oqE5ZJ0PueuUXhueJiI19wBwXmTNHk9Q5VKZTlRXd97QFwotHLwuOeU9iKQYG/pgQ5AxESL4I3fpJW/mtqlRJ5tR1YLBGSqdICuoywff2LgqpqjsVi8= 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)(376014)(366016)(23010399003)(1800799024)(6133799003)(18002099003)(56012099006)(261022075727099003)(11063799006)(10067099003)(261009223027099003)(261021123027099003)(261021121427099003)(261022105027099003)(261026140227099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HXy27RQ0VNoF6Vm5thfiXv3J9U8V274oMrgCLHTC+lMhAXY5Xve4VVxYh/w7?= =?us-ascii?Q?go9YbC4Wwh/o/kpd8tc5dy0Z6oS4Uy728hhhgSQQTgXxWjyqt4a/A5JFcRaE?= =?us-ascii?Q?PduSxHfV07ZfM/oqYNpmj0eYNnlp2oVaqM7BaQbTKhJulSpfxUQ1PsKTRPej?= =?us-ascii?Q?7L0N9Xx6D+ZgQlHzfC0a02udvqbMmd1rKT27IicB+RFQ6+hxOjioHoRPXmm7?= =?us-ascii?Q?QgVIjkyEuJN+7aS2SP8rkjpKgVPGK8lbE7efYX2LeSbHTvbj68nKm6j+thS2?= =?us-ascii?Q?68zfrlvpfk1MFDdUvpKBfpW7p1ZV80ynP07fjD7Vds5K7sFzhGGyHkqMuj5j?= =?us-ascii?Q?bRuAiOe4wxviFDX3CAl8Yp3QRZwSwR8DgwzF8vfmrgXf+P7K3beNAMTs29Gx?= =?us-ascii?Q?cmCCLV12i5de4mU36/wBbWRFkw2NpLyLR9eEFCXov+uHIkhVDMto8BtKGf+J?= =?us-ascii?Q?JMc1EkRPIYVxZEnWVo04KDSdAt0aboF+GMs9S1rb+x1wOek5d2DT94YseAsj?= =?us-ascii?Q?o5gzxX5fztqKM//63Htxpl9Qw/8UYuuXqdnubg3YRNCfuEaV0gf1iReAWchw?= =?us-ascii?Q?emNY0faqMePqbilWuRl/fb2F0/zMk8ylMGQQIuHnojV0MaLfRscitmlQ5u1V?= =?us-ascii?Q?4aKZk6XlZxBwZZ47TF+mcLkqFHs9G2WGBEW0Xd7P3vLz/D8opqMPJfr3szt3?= =?us-ascii?Q?h7uC89Nl21TwraGSlA3OLQGo5qwj4XyLe9ecZaNEY8Ju5/4ePKqxDcytPGuT?= =?us-ascii?Q?61YB2ZGd48cCCHucdop88a9CMlA1AX8duzaNvU7GLUC+giQj0qZyAK9+qpZx?= =?us-ascii?Q?wWBBJfyA1B4FgCUFldRFJY+Gdn+kejcUIOt30O8Ht2ivZRLBzhC4lYPs/Brb?= =?us-ascii?Q?gMb2puDmOX0PVvqN7hq5ujv9kg9cEgNtjb49qzM41c7UqJf+FXBZVnyeBhTT?= =?us-ascii?Q?L/O0DY7dKPb0j2hXpJkSbMTDAHQgnVefzGuBuHxCb7BPDa7lSrV5tG3W09nt?= =?us-ascii?Q?PzFE8wQapmTqiQ/qidmLMfRmHZS+HZku7ZKT/UZmg/FFz7Vg3ZkbMlCYKVRV?= =?us-ascii?Q?agiXqif0b/C6MDiBrIfwBZLHsU5FmMyJEs+Zs7hWbR8gDOtJ2sRuO3uk7jil?= =?us-ascii?Q?LG7+997aUiMTkUgY8BOKIQcHckxR+yGrI1Rr97oglaqEwE3hswAxGY9kwnZD?= =?us-ascii?Q?EN5cR+lcebU7F03EXBZ6C8Cxji+z5EUmLXNGaQccnA9rRM8lj38EqwTyYpR2?= =?us-ascii?Q?DR9kRP5jghQR0vu+KDM13vXKY34/eFivv8iH1b7k2kE9Fkurk6VKGkQvzwhX?= =?us-ascii?Q?K8AA6Gwu/4gIcNr8zkQzlVZ5YbcbMmg6Szb0PZELFyiOY3uPhGrIjXD2w0If?= =?us-ascii?Q?Jxxu6zAMcwp4eQc9o/00sVMLhHtSRjgjMZpiu6STz1ba04OQ/WvzWe+ejMY0?= =?us-ascii?Q?Ns1tE1ob56eXQTfxCDWIZaAQ8f2ByPBkNqRQlvee2P2SR35iAhkhcoa+4z7g?= =?us-ascii?Q?6E01Aqmd9N0js36ClXcePxZVbBlyTFQ6273AYQ4SpK+ilHP4H59tDpn4jSC+?= =?us-ascii?Q?GcHAOUTGuH1LmL9Qpw9rFlDceAjkgUCh8D3MQtA0QqWRPlNRFK3zIoDYvhsi?= =?us-ascii?Q?VqJr8EuCeXD4AiAmq/mumKKcgU2DbS1mBOv65kmA/gso4oa0vB4UxrLbbuu7?= =?us-ascii?Q?IxCH7E+HV060AeW98udH1s6gbNNmIksGIy4Jm2ptBB4lDEqRswAvGaUe+oKJ?= =?us-ascii?Q?iJMjqMgNCA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: bce4e7fa-7d9d-4e55-79e1-08df3485898b X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2026 23:53:45.3923 (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: MJl75ssYTh04tHa4m1BxbXj1RwfENaB2OoNOeCWmDLHraHFO0tdjC7x9kU42q0LuBi81makFsk5nqXp1Slopog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BESPR03MB255357 X-purgate-ID: tlsNG-33051d/1793145228-75C804E9-BF27B8CF/0/0 X-purgate-type: clean X-purgate-size: 3445 Xen's dmam_alloc_coherent() returns cacheable memory. A non-coherent SMMU cannot see writes that remain in the CPU cache. On Orange Pi 5 (RK3588S), NVMe initialization failed with C_BAD_STREAMID for SID 0x4100 while the CPU saw a populated L1 descriptor. Clean new stream tables before use and updated STEs before the existing configuration invalidations. Clean the L2 table before writing its L1 pointer, then clean the pointer. Skip these cache operations on coherent SMMUs. See Arm IHI 0070G.b, sections 3.15 and 3.21.3.1. Fixes: 452ddbe3592b ("xen/arm: smmuv3: Add support for SMMUv3 driver") Assisted-by: Codex:GPT-6.1 Signed-off-by: Mykola Kvach --- xen/drivers/passthrough/arm/smmu-v3.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c index bf153227db..a396e2b9e0 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.c +++ b/xen/drivers/passthrough/arm/smmu-v3.c @@ -637,6 +637,14 @@ static int arm_smmu_cmdq_issue_sync(struct arm_smmu_device *smmu) } /* Stream table manipulation functions */ +static void arm_smmu_clean_strtab(struct arm_smmu_device *smmu, + const void *ptr, size_t size) +{ + /* Xen's dmam_alloc_coherent() returns cacheable memory. */ + if (!(smmu->features & ARM_SMMU_FEAT_COHERENCY)) + (void)clean_dcache_va_range(ptr, size); +} + static void arm_smmu_write_strtab_l1_desc(__le64 *dst, struct arm_smmu_strtab_l1_desc *desc) { @@ -735,8 +743,11 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, * The SMMU can perform negative caching, so we must sync * the STE regardless of whether the old value was live. */ - if (smmu) + if (smmu) { + arm_smmu_clean_strtab(smmu, dst, + STRTAB_STE_DWORDS * sizeof(*dst)); arm_smmu_sync_ste_for_sid(smmu, sid); + } return; } @@ -762,8 +773,10 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid, dst[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS, STRTAB_STE_1_EATS_TRANS)); + arm_smmu_clean_strtab(smmu, dst, STRTAB_STE_DWORDS * sizeof(*dst)); arm_smmu_sync_ste_for_sid(smmu, sid); write_atomic(&dst[0], cpu_to_le64(val)); + arm_smmu_clean_strtab(smmu, dst, sizeof(*dst)); arm_smmu_sync_ste_for_sid(smmu, sid); /* It's likely that we'll want to use the new STE soon */ @@ -805,7 +818,11 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid) } arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT); + /* Clean the L2 table before writing the L1 pointer. */ + arm_smmu_clean_strtab(smmu, desc->l2ptr, size); arm_smmu_write_strtab_l1_desc(strtab, desc); + arm_smmu_clean_strtab(smmu, strtab, + STRTAB_L1_DESC_DWORDS * sizeof(__le64)); return 0; } @@ -1700,6 +1717,9 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu) strtab += STRTAB_L1_DESC_DWORDS << 3; } + arm_smmu_clean_strtab(smmu, cfg->strtab, + cfg->num_l1_ents * STRTAB_L1_DESC_DWORDS * sizeof(__le64)); + return 0; } @@ -1766,6 +1786,7 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu) cfg->strtab_base_cfg = reg; arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents); + arm_smmu_clean_strtab(smmu, strtab, size); return 0; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 01:47:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 01:47:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462788.1673779 (Exim 4.92) (envelope-from ) id 1xLslS-0002L4-SK; Wed, 28 Oct 2026 01:47:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462788.1673779; Wed, 28 Oct 2026 01:47: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 1xLslS-0002Kx-PO; Wed, 28 Oct 2026 01:47:42 +0000 Received: by outflank-mailman (input) for mailman id 1462788; Wed, 28 Oct 2026 01:47:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLslR-0002KO-VY for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 01:47:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLslP-005qe3-LN for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 02:47:39 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae15408-e002-0a2a0a5209dd-0a2a45098b68-38 for ; Wed, 28 Oct 2026 02:47:39 +0100 Received: from [40.107.130.97] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1543b-be1a-0a2a45090019-286b8261471d-4 for ; Wed, 28 Oct 2026 02:47:39 +0100 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AM7PR03MB6184.eurprd03.prod.outlook.com (2603:10a6:20b:141::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 01:47:36 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0546.021; Wed, 28 Oct 2026 01:47: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=nuUtx4Tfr7MLivac/HrHZ9vpOJuF48scTT27Vsp/uZNrBbW9hn0hnXDJwhLKecQXwyhMj4vzR7NFBu4aXc0EillaBogJOhQyDTKI5WJ/4wDOCNAUoDIlzsphtAkZbKSWlr9XZpRE8hxMwhyneL6TawTdBe3hnqvQA98XAgTpjH+byczi1EpcRrh+Tx3KZv0ZIK0UbEjxJDAH01rgLZCHdq/xR6nD/WIQif7kzDsAp3LHeYZVPvG40ZdJh0MCQOn7U7Qvs2q/tmwgpTw9ZMirLlUKe6IY4wk57yS7edU9pGfWMEO2688dSdAryikMv+J8zmwdcGs9aimLncMCgnZV9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=85YPMKrBC63s6/qgqB6Dulnbc52kOP52kXYUse+nWW0=; b=Ws40C5nWRVgAIp/BFU7hrYIoP8aqVZBFjMAQ0GHVblGsx1uWiCvEOB9W+bI+WJrp1EQ3RMt2USkHmCT5uQdDm+vvLN55y13rYyRQ4+4XbkUj6i8DbXxrMJt5Wn9avAg+gGn6Nr6ECuCGUTgcj6+xubwEluBr9aoyAodqzNYaAw8XwH6DDCYDEgEhXoFPKT50EEJqQ47osWAE52UxrWBRLszNYXfhlvGj1KzSW+guPNd2Kx2Q/FGZanQKhffU4uTKZxWT9kusdOQTzZBlzn9wnuiL8xJiNYSZlmVsGq0NffJpMV/fNEnfJV6/DFvGMqF4ZZ6NmbRoPQ/o0WusRk5Rqw== 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=85YPMKrBC63s6/qgqB6Dulnbc52kOP52kXYUse+nWW0=; b=FctvqYybPNN/s90nNQBItCL3o9b/IfnVYW+oEdNL5EyDsXJozMIKaGQyor3A8MUCbcQWbMBU0VJpW0Pq3/fzVABTmw7plREWr4AC+4aCuwzglA4lAUlAN/5qhKzuEWEZ718jHKhPnC5QWanPKA6CDzxOHbW6gRF3YqHJw8HPhj2TVvXDkcC5jQkQBw4XCKVfIs7od+GYqnr5KiSGYefz4HqlcY88hiHuyfbhhepQU9QwW0py+8OdzJsp0CJN5oXYpcVL8keqVnmgRBeLP8RU5wzOAgGvOpdaa0UZlQbT07r5jBS8kJrFpXaEwIoQY8Kv0vRBxOJYlSRuJcyqeRC0Fw== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH] arm/smmuv3: clean stream tables for non-coherent hardware Thread-Topic: [PATCH] arm/smmuv3: clean stream tables for non-coherent hardware Thread-Index: AQHdZm5ov4pfl/+ZtUafpoJaRxUN7g== Date: Wed, 28 Oct 2026 01:47:35 +0000 Message-ID: <87fqxqsiix.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Wed, 28 Oct 2026 01:53:35 +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: 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_|AM7PR03MB6184:EE_ x-ms-office365-filtering-correlation-id: 1129e523-87fe-4e9e-a7a1-08df349570d7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|42112799006|366016|1800799024|261026140227099003|38070700021|11063799006|5023799004|56012099006|261021123027099003|261021121427099003|261022075727099003|261009223027099003|261022105027099003|10067099003|22082099003|18002099003|6133799003; x-microsoft-antispam-message-info: R9NX0MgxnjUrrlPbKiODsgqzJuxRGuZrHcqjmVDMXWQivnv9KR1q8PwJroqF+zpcV0EPVRo1PtX2re73OCPNotHB1O/bNCykfQQGu4o/Vy2p5YLO/jSGtAlshT0SIedUgw8MrvOJVQhpa8HinwLYEjEOXBjWTvcU7vAGUY5Yct1XHwu+adhsFpyqgYbUP0ags/omoy8btrwKKVWCx26sjNO/laIFCXCZwBQZL4JnZcJcTvHNySp6e0QYqh2CP89xaJzzZtPtGNJ9kMH3ozVia0PQRHH+V1NpYA3GRC7SgMLeuvz0BwId5yl0RkqkK0WxnWmeLW4Yvayne4nXrXpIV7DK8CGhhuialvlQsqUJGtHMAMZFLbOHOgn64cNMlXk3e+87j8MwF5G8wMoWnhcAx5wfaVZR8AeDrMfCw8ZkqSiqfgUr0T9zcB8sdTqFGAhRNyh9tWwa7J6nLxmf4SkCspFVz8jd4f4IVENZlsTlLYgBa8r57J56bW5wWYBRuQ3O+slzUk2AYFpVvvtTAO47ZYilzYG3e110WzYiPYjGofA2J3mWvXMJDVg2k/RACRfIzMQZyaJoDGossyg5ofj2kd/Ug8FxQbiZyFMJHIQX3tyDpQfBirTiRlBtYQTQIl82rVZDH8CFEKe/XR9gBG9tP/8Yu2QumugD3D4SGU3wBby+XyRbSYqzDwC/q5ByHDuY44SEo9KqtMehkssgB6OESLvSNY2jtiBsVFiXXwWIPz4= 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)(261026140227099003)(38070700021)(11063799006)(5023799004)(56012099006)(261021123027099003)(261021121427099003)(261022075727099003)(261009223027099003)(261022105027099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?yfb8Y2YAyTgHA5wqKEJ8GBy9wSnnXhO+RFK39cZPsr3C/9VHb5OSUV+mJ9?= =?iso-8859-1?Q?qCU6oftL9bcdFFca0R3vw95jYg29DvQrpeDv0LSzIF3KfmM1q82RehbCsx?= =?iso-8859-1?Q?OyTDLEcjZT8cFXtoJLnLR3B7ef57eQxGO4Q2eJ09BytfjsYAK6qxhtVQxe?= =?iso-8859-1?Q?IOfValQpiu9i8WVlTsiMpkjh6ZJkvuidnTWuTy0OlxHFWiNiHjkG8jBcN7?= =?iso-8859-1?Q?GrRqa7HvB8evhkRh9M8MuHI11X7MP5dLe0AqPNdzL33vDoiKc3zbNVr4oX?= =?iso-8859-1?Q?m7zJIkJNAlmFgEtFcPfbQWK0kwifrB1QA0Pc5Jw9gScyEWhhkFLPc/DsPC?= =?iso-8859-1?Q?Am2yQH5MVyB8xYasdiGHgHoBqzXzv3Km6RDkmdhgaiPspHYDxRt0uiOjCh?= =?iso-8859-1?Q?jDD2q7Kiw3R73hzjTocUWerbJ6yKhtfGKlBbld5Yh6tdOBFBAR8uk1HVXp?= =?iso-8859-1?Q?6Z2jFioAZSeDGFtPxddJvnrWndVcmluIkMq4EA87zhDNMzv6+5pXqQ23id?= =?iso-8859-1?Q?efxCKnh4a6uH1rHj2KIYH9pxh9X5UaBq/J+xh8tDRWgTSqGId8/+l+Yvws?= =?iso-8859-1?Q?v9Toi2XEm0GxjuGR3IBVhhJZ5EaC3+sx4tOKqucAAjBsHzWMLf0QCfGCwf?= =?iso-8859-1?Q?2a+FRgrYaWlyhMTY6QBxWN8S8cAt9MK6N5B962EMLlah0tdS2pakamyV8T?= =?iso-8859-1?Q?kVuVoUOxZLoqkRM0G+l717dLnyt5C9luJVDdHcbK7R3yU/kr+PxRlhpDpk?= =?iso-8859-1?Q?A52/ka62Hw9r9r/OeWwlWQV6GuHoHFhB9FgaNZWPlP2FHrDi6npzOMqLGw?= =?iso-8859-1?Q?6YpeC/E5+FPrKXVTYRTUWMIrl5s9HfuAYz9HRXRw8iMAYlnv/FBg180NG+?= =?iso-8859-1?Q?B6Q28V9KpT30316LlrRvZxM3Tp+jSxJNUrj79cMDLXilk2xE163G79mjUx?= =?iso-8859-1?Q?U1noin95DsormjZQsiqAqq8uUvaaOOitKL9aYFM4FsHBsKVt9S++crPe3n?= =?iso-8859-1?Q?C/93ZlGJ81LxdyAt4W24KmWj3cTz7Tkxh8lPRqZbSV4tXeZchs+ZOtZYda?= =?iso-8859-1?Q?H0XICdtX5UbWvqi0R7PEWaozq2TEni2He1BiktlBEk3ZXEpe57mckPGJ9Y?= =?iso-8859-1?Q?CYR/jMsQMyRiAYLCRlALnBKqVFvIDtJWZPpM3iH4CAhbMezpYXAdZiIoWf?= =?iso-8859-1?Q?oE2fKYy3WYiY+L5yfEs73ORSBwZ7j42MQwlKGED2QVo3EXVgudMXY+emWU?= =?iso-8859-1?Q?e//o6mU7HolZrSu6Cg6gADp6sUS6xcy7xjUBxH9FatyjGaTDCGOYwy5/G9?= =?iso-8859-1?Q?PxW85PgGGbpB/DKX+X7wjmNgDBJ77TAeinjgkp9iKXS9nX+zcZeZYfNwmC?= =?iso-8859-1?Q?wtGawjOOkJLspxD3MsBWPNGdQ5MLF7QRswePoSN2Z+cznQFrpo9Qs8YOfB?= =?iso-8859-1?Q?XtT2IoWA0R+fV69woNFKLa2V+KeryT6BwPuSgfbx3eUikJrMzKoJh2GPHJ?= =?iso-8859-1?Q?SqP9O74pntxrhqj6m+SrG3QhCYnOtFDK8nD6F9qSa5+XdSE0ksqDaBqnE9?= =?iso-8859-1?Q?sxjI+89iFm9rmShrhQ38bL7TAc2N97Yd/hPcgjX3XIVIWpAMn0rGzUL8ii?= =?iso-8859-1?Q?GyzW57hMhvmUmWqWztb1QyCr823NXkROPutyxJhilvxrmTVul8klOS9XY6?= =?iso-8859-1?Q?a4WXS5qoKTxrm3C9Rx6YejgJqwYH4y6Q5GF1/Pzw26fUnY1JIelibPGSkw?= =?iso-8859-1?Q?kxf0Wx1uNZNI4WJUBgu6MA/WPrvLV11BwsyqP16OdIsZPsC0bsxKNEfTy8?= =?iso-8859-1?Q?XM4lwFiy0gBlzylNIuiKmX+u3oZ/28Q=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: 1129e523-87fe-4e9e-a7a1-08df349570d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2026 01:47:35.6697 (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: MUrSzIr8+ij4hDbH5d+0mw9oweE9R7PKr5kBPq3yNYSAImyRyqr18dMxVrvMHdj9bOrXRNA1A89Ss+3gNlA7x3R3bx1HOakdi1uYOA8sb5o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6184 X-purgate-ID: tlsNG-bad1c0/1793152059-3AAD8034-B2BE1965/0/0 X-purgate-type: clean X-purgate-size: 4328 Hi, Mykola Kvach writes: > Xen's dmam_alloc_coherent() returns cacheable memory. A non-coherent > SMMU cannot see writes that remain in the CPU cache. > > On Orange Pi 5 (RK3588S), NVMe initialization failed with C_BAD_STREAMID > for SID 0x4100 while the CPU saw a populated L1 descriptor. > > Clean new stream tables before use and updated STEs before the existing > configuration invalidations. Clean the L2 table before writing its L1 > pointer, then clean the pointer. Skip these cache operations on coherent > SMMUs. > > See Arm IHI 0070G.b, sections 3.15 and 3.21.3.1. > > Fixes: 452ddbe3592b ("xen/arm: smmuv3: Add support for SMMUv3 driver") > Assisted-by: Codex:GPT-6.1 > Signed-off-by: Mykola Kvach > --- > xen/drivers/passthrough/arm/smmu-v3.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthro= ugh/arm/smmu-v3.c > index bf153227db..a396e2b9e0 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -637,6 +637,14 @@ static int arm_smmu_cmdq_issue_sync(struct arm_smmu_= device *smmu) > } > =20 > /* Stream table manipulation functions */ > +static void arm_smmu_clean_strtab(struct arm_smmu_device *smmu, I think the name is a bit misleading. You are not cleaning the stream table. You are cleaning cache entries. Also, behaviour of this function is more generic, as it know nothing about stream tables and clears any cache line you are giving it. Maybe call it something like arm_smmu_flush_strtab, or arm_smmu_clean_dcache, or something along these variants? > + const void *ptr, size_t size) > +{ > + /* Xen's dmam_alloc_coherent() returns cacheable memory. */ > + if (!(smmu->features & ARM_SMMU_FEAT_COHERENCY)) > + (void)clean_dcache_va_range(ptr, size); > +} > + > static void > arm_smmu_write_strtab_l1_desc(__le64 *dst, struct arm_smmu_strtab_l1_des= c *desc) > { > @@ -735,8 +743,11 @@ static void arm_smmu_write_strtab_ent(struct arm_smm= u_master *master, u32 sid, > * The SMMU can perform negative caching, so we must sync > * the STE regardless of whether the old value was live. > */ > - if (smmu) > + if (smmu) { > + arm_smmu_clean_strtab(smmu, dst, > + STRTAB_STE_DWORDS * sizeof(*dst)); > arm_smmu_sync_ste_for_sid(smmu, sid); I see that there a lot of places where you are calling arm_smmu_clean_strtab() before arm_smmu_sync_ste_for_sid(). I think it is better to move arm_smmu_clean_strtab() to the beginning of arm_smmu_sync_ste_for_sid(). > + } > return; > } > =20 > @@ -762,8 +773,10 @@ static void arm_smmu_write_strtab_ent(struct arm_smm= u_master *master, u32 sid, > dst[1] |=3D cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS, > STRTAB_STE_1_EATS_TRANS)); > =20 > + arm_smmu_clean_strtab(smmu, dst, STRTAB_STE_DWORDS * sizeof(*dst)); > arm_smmu_sync_ste_for_sid(smmu, sid); > write_atomic(&dst[0], cpu_to_le64(val)); > + arm_smmu_clean_strtab(smmu, dst, sizeof(*dst)); > arm_smmu_sync_ste_for_sid(smmu, sid); > =20 > /* It's likely that we'll want to use the new STE soon */ > @@ -805,7 +818,11 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_d= evice *smmu, u32 sid) > } > =20 > arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT); > + /* Clean the L2 table before writing the L1 pointer. */ > + arm_smmu_clean_strtab(smmu, desc->l2ptr, size); > arm_smmu_write_strtab_l1_desc(strtab, desc); > + arm_smmu_clean_strtab(smmu, strtab, > + STRTAB_L1_DESC_DWORDS * sizeof(__le64)); > return 0; > } > =20 > @@ -1700,6 +1717,9 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_= device *smmu) > strtab +=3D STRTAB_L1_DESC_DWORDS << 3; > } > =20 > + arm_smmu_clean_strtab(smmu, cfg->strtab, > + cfg->num_l1_ents * STRTAB_L1_DESC_DWORDS * sizeof(__le64)); > + > return 0; > } > =20 > @@ -1766,6 +1786,7 @@ static int arm_smmu_init_strtab_linear(struct arm_s= mmu_device *smmu) > cfg->strtab_base_cfg =3D reg; > =20 > arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents); > + arm_smmu_clean_strtab(smmu, strtab, size); > return 0; > } --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Oct 28 01:55:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 01:55:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462795.1673789 (Exim 4.92) (envelope-from ) id 1xLstN-0003tj-Jx; Wed, 28 Oct 2026 01:55:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462795.1673789; Wed, 28 Oct 2026 01:55: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 1xLstN-0003tc-Gm; Wed, 28 Oct 2026 01:55:53 +0000 Received: by outflank-mailman (input) for mailman id 1462795; Wed, 28 Oct 2026 01:55:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLstM-0003tW-Or for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 01:55:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLstL-009Pkh-ER for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 02:55:51 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae155fa-bab6-0a2a0a5309dd-0a2a450a8f9a-34 for ; Wed, 28 Oct 2026 02:55:51 +0100 Received: from [40.107.159.78] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae15627-f2d2-0a2a450a0019-286b9f4e9a1b-3 for ; Wed, 28 Oct 2026 02:55:51 +0100 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS4PR03MB8207.eurprd03.prod.outlook.com (2603:10a6:20b:4fa::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 01:55:48 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0546.021; Wed, 28 Oct 2026 01:55: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=fhZlJNUqVCSP5sPpEhetILpxiUPuD7GG5drBfJ4mJvMBMySNCxfzK6YXqdAqlet8jDFRfwOhaFl+UGtaSRFk/U515F8JGPx/X1hVj3ULTUxjui20PlYK8AT7DvFL8V16+BI0JH9wDMHSOh0OW8cwY0zACcnn0guDvlcg+CNMOjsPQ9rL4UeNjILFfj0cDOR6xrgDaNwzNGMgTDsL8jh3U4uN5lWJQ+lxgr3UUjY5NTPJHw0/NnQdsxYtr7tEvjtyj0DYC+8j6HZ7x7NJLezdtwsLHvI1RAw4kQbw36ZFcnEaYzFYB9UAlmD19vO6XG2ZvsxOQ0m6HF6DypV+A9P13g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8JEB4TcI6rY9PoEiqupKaYUkobSukx5mh2G5+XgiwyQ=; b=TVOygFARYnPs8xmAQT5f1M8Pe2cW4dM0VWRLPnEpeAsDLE1En6TEhu5bsAHCZ4LY0g/aXvwDywIMYECafqVbmIAmraRq1Qiycj4QwO9c/oKOJQiKQmA9iW0zWcCB1uFbKilC55/aVR/cesLxBzm4hs7LGmFJo3t8hsUZbspZYoBf9eEa7VkUAPSjjP4dGUQpaedbe9ZGRNCOamJkOz+J+Wf1RZyQA+qzgNVNkfnT8KDCqsY+dySC4GNY/BT8agJINxNDAGzXDMuHy0vTHKVwRdrAnA1euW4RP2zqjFZ4GeOhim58JVypgKz6o+nP7nGaDdRBm7R//LEVmboc8eW/RQ== 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=8JEB4TcI6rY9PoEiqupKaYUkobSukx5mh2G5+XgiwyQ=; b=hrYxa9o6pdy9qlqmHpGDkjYtGdKb9Zxf036sW7CPCa9/xZGJAbQAU3gpmNQibLwu2pRA4i6UH1onNHMk6MejzMxprFjFt/54JPESjnBhvsBs5o4kcUj1sbbqMVyPOx0RKE55udyoBlLQc/KZIu5Nc6HFdF9Tg/QyAqahcpn0Cu1szTUcYUvWFmmx7JNYNxkvrsp7Iz2A56xSosHVxTmYoRGJiR0Hy0Ni8oR9GxjuKjcHwxXMODO2EEifubsxmUEmbYNi5npwNtkBHZjYv8lDyL3zkLMNuQY8RtVupsQKcWvS4WekbZj9qarTnx0GVbwx/jL8c4IAvYUFG+lVFCUcTQ== From: Volodymyr Babchuk To: Leonid Komarianskyi CC: "xen-devel@lists.xenproject.org" , Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH] xen/arm: smmuv3: invalidate TLB when freeing a VMID Thread-Topic: [PATCH] xen/arm: smmuv3: invalidate TLB when freeing a VMID Thread-Index: AQHdZU2CvV133olROUKhJSegs8l4mg== Date: Wed, 28 Oct 2026 01:55:48 +0000 Message-ID: <87v76mr3ks.fsf@epam.com> References: In-Reply-To: (Leonid Komarianskyi's message of "Mon, 26 Oct 2026 13:25:47 +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_|AS4PR03MB8207:EE_ x-ms-office365-filtering-correlation-id: 15ab847a-1b05-42b0-8575-08df3496966d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|366016|23010399003|1800799024|376014|22082099003|18002099003|11063799006|56012099006|5023799004|261026121527099003|261021121427099003|261026140227099003|10067099003|261009223027099003|261022105027099003|261021123027099003|261022075727099003|38070700021; x-microsoft-antispam-message-info: 3GEFluEBpAlfhy2Lf5yTFkdBQHEOCzZAU7AY85qx2f93tfApPLNLoj83HAaT7/E7fvgdNWN/fW/PyIWqdHVvj+udn3JBySXZc6wn2asmawR6TWpSuFUIZktDN1r3kJkpkbwofDGRHk79k5bZ1z9z/ggWqm93yNSKvL0+gzznJcQLMB3rUR6PqEeXbMgXDykT0buqtzs5PalRJIdMRf1Wmxk0iLtP2uq1kjbhJ0pW+rweyA2E0vqW3Xt5rKztZNOts/NDhb9Vi+kdjIJQ7berUkq3u8aaltswn1m8MaTXaf8OD4FaFDf+MyV5NGMzTOgup2o8qsUWHawc5ASUHZpZJLjJBxoJiCE6VSXbZTfIFd7P8tvXtjO56yedxe73+p1v4ldV4aBnAGWKnXi7dD+4lFpH+24GECbBj68Nz1TfFmu6wAyyP8m0/uFFA+sBcljTSOZeEBX40gso3XxUM0kzNvGT7Zv2OalYOuLw+Q17w+ZLcLQJnrSmMATdMYq3IkPdIe4YRmBJXZMfnrq8900fIfdxpUoCeOnlkJwBz9+iLpNGwYwvtUYKZXwPpJJ6lWa38bZ+sUPlNWxHnSH6kI6gMGFZnO/ZGdh+4Z5F/bre+2PM35arlXrtuKxCFjlsb+61n9EZm4kHahgsOVWwmt0xeGNsPB1YaHxaUz3VfnVMYV9PikkmAVOkP0nPLhiIvPQLvemWxAAETYGDjAjx3APRbUn3slbQQuOmjzQT46a/H/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)(42112799006)(366016)(23010399003)(1800799024)(376014)(22082099003)(18002099003)(11063799006)(56012099006)(5023799004)(261026121527099003)(261021121427099003)(261026140227099003)(10067099003)(261009223027099003)(261022105027099003)(261021123027099003)(261022075727099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?WFN95zwXeYS/dAkUA9PFoZN+l+wo9+zKxDXfNIaCs79ntmrQOo2lODhY5m?= =?iso-8859-1?Q?gFR0PFGja+tFuqM5+mgH3EscGqYwozf0vJLfMWsl/3mpjJ0d/++kd0tKde?= =?iso-8859-1?Q?ND/STo8CXlBbH1nTdTcbTxKbn1Ge4yI7HY2/3t5tctRRvihG+0L+Di/Yzo?= =?iso-8859-1?Q?QS8dKe5CX9lu0GX8b1b1/QR4rGHLrroNW4IbO0zVpVwT5SLzGRxy5j9W45?= =?iso-8859-1?Q?QKy/TeaO7oNpVl0jnTNlzkbcE8dge0KQOlpKi9tdx1yHSpIWudc42uiE9p?= =?iso-8859-1?Q?Qw/kHih6UeYsgVG08OtsEseKSDZkRaDdhVIEbAeechsYSjI2IyI64ZnFNj?= =?iso-8859-1?Q?rY45825CFaz38RO1I64eLvsqce4flwjOXu7Uvyhta3iKzgt/QahPb/rTNR?= =?iso-8859-1?Q?HZ2voMUaCnqEcUOiccHQ/W63CSjVr2mK3T+E6/yQQOihJd0cCfCkbXrumg?= =?iso-8859-1?Q?tDrW2MOTigtShYH4FG64sDQBwaX8TC/nnOAQ2MAWdl2SPrPcwThZtYSxFE?= =?iso-8859-1?Q?fzv0StRQCZjwylrj1L9xrVBgUg83uduszFw0/wqeneNQIB15K8M/1iwonz?= =?iso-8859-1?Q?Lsky2YRvmJ1WskQIBzqNXrR9BBPEdqSyqo80JpI62aF6MbZfIPZMb11txI?= =?iso-8859-1?Q?StbaoJBl65BNZz+TMZfbjEUl54gQCi0O6HJ1IZBtrIwmrS2KqrnR4Ni4Pp?= =?iso-8859-1?Q?Q12jZuiY/QAbzQXSTDJ97f3m6QxvACJl4KgIQxMGGBBsDCvtO+cJ/NbH5T?= =?iso-8859-1?Q?5gWjF7YsVlHqZ+FaJP072VGXGhBTnLd1L0bYk0pJ2w5e4C37gF0X2MN83N?= =?iso-8859-1?Q?MqLM0qrgGbt3BF1zDFOR+uDfEMCVITdQAaPBzzrgqRcsAa8ZgSxiGPNIkr?= =?iso-8859-1?Q?5KbKs94He4LX596gN4zE78M28zTXo3TnEvU9PKyjRbRI6gBi/vXriZqUCp?= =?iso-8859-1?Q?8q2muC8PEcrdgUhB2CxLZ42wBoeMx7wZZ1qk7I5h4ks6gYNxMfDGl1YXNF?= =?iso-8859-1?Q?vBerS7rds0Ago0ryxGQWzotrfVwsOvoBOTazt9w42bHaef6xCus4ii8Bds?= =?iso-8859-1?Q?WgPiMZquARmPfFn7TuOkrQpst83ME9BWPyzaISF3l4C8WLAkH5GJ+u7M54?= =?iso-8859-1?Q?NZ0uu0fdWbZUQF4VBTUwMP6ibPvJadWNZir8tc0EzH56q+/XuRK0BLop8K?= =?iso-8859-1?Q?fSQtDe0TDZGxZzmAejQDI5Trwo8+c3PJWb92XwcdEWg3F0pibvWR9+uush?= =?iso-8859-1?Q?7guHdIcKmGm+Fr6xtnlIxBFyvvtCxPrWNa/J31/R+x4kYYFEghvR2JSNIF?= =?iso-8859-1?Q?KwRfYDOQDdVNPB2q8rhys2YtNySJ1iK4uhhyb5F3MFD5QwCLM6WP/54V3A?= =?iso-8859-1?Q?nvW3t0RkD131NR6LWH01YMVeO+ob6G1N2Z1t+G8oAtXfzWVoo94woGq6H4?= =?iso-8859-1?Q?hqt4OV0zb0/ETy3Fob1CstbqtKElvRNz7zqxfhYg/pTbVkS+cgqRXu5pdV?= =?iso-8859-1?Q?Goq5NB1jQ3VLbIXtxONAc67ACPkNYkcWJ7bfwRpop+/04FTAOZIC7d7HvH?= =?iso-8859-1?Q?PJMHfn+Yr5gUgfIlBYgCMl/9Onf/vKHk24yG33YVY9QJwFga6hFuooq3VE?= =?iso-8859-1?Q?tIpdnllq8r6iJ4IWaFAaqwla3JOY9LiErF6XGKe7vYeKijNF7LV5pM/Lxw?= =?iso-8859-1?Q?Oet9Gvd9xnh1zLL7gIhw6lW8+Bc3bhzoOjPIzZe5pWnqxLh0Hmly6lCrAY?= =?iso-8859-1?Q?wgvZn8I48nCDx6buIogWPDsnz0h/fT4/R6q0yKvfU7L52LCgxR07EeKVVB?= =?iso-8859-1?Q?MNRXkmeS9hQ/LhiopkBSlxoX0L5lP5Q=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: 15ab847a-1b05-42b0-8575-08df3496966d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2026 01:55:48.3046 (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: 3QklfXAKextq9lh+FZ1/6iSfsgoEHqDuIQnI+b7RpGKEnBuFWHFk2geigGwoztmiQ/Ycvyoz9AMpe11Xsyp+JtItCQQzlShodZPq+O+Eo6c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8207 X-purgate-ID: tlsNG-4011c0/1793152551-5A5DBCFC-ECE06759/0/0 X-purgate-type: clean X-purgate-size: 2539 Hi Leonid, Leonid Komarianskyi writes: > arm_smmu_domain_free() releases the VMID without invalidating the SMMU > TLB entries tagged with it. The VMID allocator (arm_smmu_bitmap_alloc) > always returns the first free VMID, so a new domain usually gets the > same VMID as the domain that was just destroyed. As a result, DMA from > a device assigned to the new domain can use stale TLB entries and access > memory of the old domain, which may already be in use by Xen or by > another domain. > > In Linux, this invalidation is done by free_io_pgtable_ops(), which > calls the tlb_flush_all callback (arm_smmu_tlb_inv_context()) before > the VMID is released. The call was dropped when the io-pgtable code > was removed during the port to Xen, and nothing replaced it. > > Linux guests that modify their P2M early in boot (e.g. by mapping > shared_info in the xen_guest_init initcall) hide the problem, because > the resulting IOTLB flush clears the stale entries. However, guests > without Xen support (e.g. Linux with CONFIG_XEN disabled) do not modify > the P2M early in boot, so the device keeps using stale SMMU TLB entries. > This was observed as GPU rendering corruption after "xl destroy" and "xl > create" of the same guest with CONFIG_XEN disabled. > > To fix the problem, issue a TLB invalidation for the VMID before > releasing it. > > Fixes: b3be6ffb009c ("xen/arm: smmuv3: Remove Linux specific code that is= not usable in XEN") > Signed-off-by: Leonid Komarianskyi Reviewed-by: Volodymyr Babchuk > --- > xen/drivers/passthrough/arm/smmu-v3.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthro= ugh/arm/smmu-v3.c > index bf153227dbd..93176e2fb21 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -1153,8 +1153,14 @@ static void arm_smmu_domain_free(struct iommu_doma= in *domain) > struct arm_smmu_device *smmu =3D smmu_domain->smmu; > struct arm_smmu_s2_cfg *cfg =3D &smmu_domain->s2_cfg; > =20 > - if (cfg->vmid) > + if (cfg->vmid) { > + /* > + * Invalidate all entries tagged with this VMID > + * before it can be handed to another domain. > + */ > + arm_smmu_tlb_inv_context(smmu_domain); > arm_smmu_bitmap_free(smmu->vmid_map, cfg->vmid); > + } > =20 > xfree(smmu_domain); > } --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Oct 28 02:13:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 02:13:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462805.1673797 (Exim 4.92) (envelope-from ) id 1xLtAU-0007LW-2v; Wed, 28 Oct 2026 02:13:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462805.1673797; Wed, 28 Oct 2026 02: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 1xLtAU-0007LP-0N; Wed, 28 Oct 2026 02:13:34 +0000 Received: by outflank-mailman (input) for mailman id 1462805; Wed, 28 Oct 2026 02:13:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLtAS-0007KX-BQ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 02:13:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLtAR-009RZ5-Nx for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 03:13:31 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae159d1-8faa-0a2a0a5109dd-0a2a450686be-28 for ; Wed, 28 Oct 2026 03:13:31 +0100 Received: from [52.101.83.102] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae15a4b-195a-0a2a45060019-34655366fe3f-3 for ; Wed, 28 Oct 2026 03:13:31 +0100 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DU2PR03MB7925.eurprd03.prod.outlook.com (2603:10a6:10:2d8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 02:13:25 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0546.021; Wed, 28 Oct 2026 02:13: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=Lx51lV0MEEyKDLPK8qVSOIekN1A/sWMUs5ijCrhMhDkK6KTWVI/lpYOddHk3GXEOP1N9oXh8kot20Sw0ohaT7TSh/xRxhfM1u+cqJQSlMGx8ZZcdS50oDSPK+S4yfstgOfO+0jXx0PYJxeSLc1oZIC+Ho81oYE+WZRFbjRay1L3rDgfoPxasFZhYZdsVqRJy/+imoa6R6bRZmxbHEtbYgq8aYQR/fKI25VoAxwlJ80zf+0dgkJVaWATyZ/p1V0XhfOtgUaKf9lgHMNk2mR+OCaKK4ORGLXSR/5dkNwcK/MeHwT3ouq/F9vrpKurjtEYlxuoe+2PolktBWxsHD+02NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+Az+cdNp2WiBJsttHXvgElp2UNrxJ/fVqIx1E4Ip5fk=; b=zUsFQax1qOrWxwIeNK0iXKvUp0aOu+f3us/R0YVQTVmF6ogr4qgB9eIDFJXUwgq7dTQ1XJ3DFROCYeYevRLhiYTYHxFREpOAVZbmGrzhcmheu7y+FEjP23krldfPZNGnnCxseUDiVVGexZO5r45paP7Seqc83YuS4X8IzofjJHzccjxfZGV8YbJS+TC8Dy8NhzVYeJtE/tmlawLoaFA+EH1lOx4MQpy5B3gvJu6eG9UfRTwakxTx/ZAh1ZL3uvq892PSB4Jv+P37bEsdlCMHTXtbAHwsghTgPZRX06m7zFrBHG9jDLENuPCpcAClh8JNg/3+t/YpHpqpAsHwvzmcuQ== 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=+Az+cdNp2WiBJsttHXvgElp2UNrxJ/fVqIx1E4Ip5fk=; b=kJbuYGmYZmHX5nP1MkWqwzkFXRzK7qYXGZgT1M2Pz/dJujJOnlipC3/hD9swUq2U9ZxNHOBmcgsCoouPGyPbndqLxRdh4pGy64AQk/Yt2pFCr8n2lvTtbQkCyBlkbprhxSK5/NJZNJjkNqS3zIUfPwlpE+4JLS0A0CaoxqrkmkI43LcE7BCGhLkHt/d5eUFj9h5051Mqg7EVzz4bal9ouXeaJeIoaNKtGneWXMWzBlzV370JLcJ2b/Jw8zAmoPRJtrZMVDoU88apL0iBR1KwnprQ2eojRGZ2+IT0vujzwzhjMceRg+H7X3R1TvrcbF0zSIZ407+0sjNYf/hy2wxyGg== From: Volodymyr Babchuk To: Hirokazu Takahashi CC: "xen-devel@lists.xenproject.org" , "michal.orzel@amd.com" , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: Re: [PATCH] xen/arm: Fix sibling mask setup to only include online CPUs Thread-Topic: [PATCH] xen/arm: Fix sibling mask setup to only include online CPUs Thread-Index: AQHdYt8baAARnjXwY0WMOCpcDnsQgA== Date: Wed, 28 Oct 2026 02:13:24 +0000 Message-ID: <87h5i6r2rg.fsf@epam.com> References: <20261023110925.128195-1-taka@valinux.co.jp> In-Reply-To: <20261023110925.128195-1-taka@valinux.co.jp> (Hirokazu Takahashi's message of "Fri, 23 Oct 2026 20:09:25 +0900") 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_|DU2PR03MB7925:EE_ x-ms-office365-filtering-correlation-id: d7b37322-cc37-452d-e2d3-08df34990c0e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|42112799006|23010399003|261026140227099003|38070700021|11063799006|261021123027099003|56012099006|261021135927099003|261021121427099003|261022105027099003|10067099003|261022075727099003|261026121527099003|18002099003|22082099003; x-microsoft-antispam-message-info: 628zd70WbszS7/pXW7mca9T8V+/betGg5QaDFccQ+WmJOdKzztOYcoA+i8XUAbn9+OvUudkVtsjxHvSBCTVNV+nWB5DfdQJBvzHmZA9SyWYdNDwoiC2w9YQlIW3Ttmn9w7di8EDNn8sRYtrdKlmrKW1XC73hgUpXrou5D1yl4tco46NOTm8We355UNbHeckZz7Tlpvy4I7lmzHsDOxIxIWU18XaG7zLEq396M7Ztdf+c0D3VjBmrvXpQhSMAWbMBx/uG5g8bg1jfW6R0XCivV014L/N/N07oF/l1PlaBaQNWVgBfOEUE4U9xeIdbfju1GwaNRG1Y03ZAp+n4tg9qHnbI7P/3VhzbPJZpmDxgxpK3oe96tL5ic4Aac+8o+pgLJLM+S5APATDk1VbHmXTKx/jrECFjA2D/mwIc/pib89zEF3TRpa6p4Nh0MEo3g6T5DoJ0nyFTnXGLo393gLlP/gcKzCl6e9BXNF3HD1e8aDYCRLmsBDvrbOxeAXJV/0en01nQHcfe66f1xH5yK8q4F9hG3xAReU763UxJEh53+dm45FU30/Fhn7/wSDtUo6b5E+oAlR2Oy4W69F1311tfypLz3TkdF2ryZo7rFgvoBM0Qfgz68tRksqYLJFIlwVUi3WSxKXAJSU4iFq2TBSIyn1Y67XNGERZ6574Psjwb4YR79w4PEtrb/g1rw38yCef+pBfJN6tq2BoEmxKNfu2F4X7hgSS7sxAIfmhcnQLuvNw= 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)(366016)(376014)(42112799006)(23010399003)(261026140227099003)(38070700021)(11063799006)(261021123027099003)(56012099006)(261021135927099003)(261021121427099003)(261022105027099003)(10067099003)(261022075727099003)(261026121527099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?dM1jVwK8ZmwKNre0Dl1mV3R7PBEtgHUkyJc9bNiWyn/kDrcOruV0fyF0VX?= =?iso-8859-1?Q?XCrtwowgCiQ9j7vPQ61vJLUg4cYkl2/PBR7DMOUHpH43QSLp6Maxt9jTkF?= =?iso-8859-1?Q?stk05itTQoFpQ9A3otf4wiOu3j+GLKg+70r0OYHZsSNRnNDhhxh3bFDWSs?= =?iso-8859-1?Q?Jfq5kE+v4HiaBw8iDRCfG36sveOUx0a+Wm75dMYStABp1s4EUvnzS9K01w?= =?iso-8859-1?Q?3BjIgldLt7K6ZOQTTcZULvIU8+OgRmiLuy7JZa0LoMmsqwfzBaRDsvqBMD?= =?iso-8859-1?Q?ElSfEZlcLGIr4AkMFTO+gP/KpGulGIoQQxvNseiy0N4yOaJuAQ4JOWbMuR?= =?iso-8859-1?Q?s4A4oKPahqQDscaqmGUPBD1AmijD7bsDMYA6b+9iVsS8Lzo4ZztjqhCcmK?= =?iso-8859-1?Q?pyl3U95eNk87rm2/jvP9VnDLpSEaWl00fmPbd+XADp7Msrz3rzGH/YfCX8?= =?iso-8859-1?Q?q3FRt3pfgh/ftmd3M66t/5JozDpdpk8VM/iUN5AIaevW0o1vvQgNS3YMmx?= =?iso-8859-1?Q?12fK8psa1zyFqSU41nD+HcS9KHEGTOP5NAvvDwAf0juw4bWbsn7uiJ0+sy?= =?iso-8859-1?Q?/L3SLnX3MmoQ+tWthy8QsKmZZxYj44jJ6i5YzQxNA/G5UF+qM3+LLHq0AL?= =?iso-8859-1?Q?K0QJ5rQ6cJLCPkrQ1QjNzWofS5hbIp4C/ouHAKI5PsFuMXjMIs5WYkBtz7?= =?iso-8859-1?Q?rqIZlcTcXuZokFb7DWku9wmUEQxnZF/dRCdxLg52nt8ZJQvqXELvXgzd/d?= =?iso-8859-1?Q?UJAMFIqMcRorYICtaUTKRjQjFfmM2JmCT92IlKiWoZkytEqC9BID4muqoc?= =?iso-8859-1?Q?BL1lyGqTvK6623kioMQRIew7L/1dsqjPhwdR67YhmeFx9Y3UMKGSR4d29Y?= =?iso-8859-1?Q?8yKkjP6p36lTkVAdEZVXWkomAe/qzHLLBQcAg9QoiT8K4+R9L0rXiokOx3?= =?iso-8859-1?Q?4gWNsYgFodEXkNsKFhIL++Zvgxf8JVuL1kNQhZirreqAicKm3clRHXca11?= =?iso-8859-1?Q?LGyAKfjWG4rgB01MwxcbBS0iqF2Zr79Eu6r1BcXDOJIUf8MYaZjoCxWA5e?= =?iso-8859-1?Q?tAn0TC5Fvzeq4VeXS66l1DsPVMPDoem0uCRkHGtnRnySdBPgJCXWCU7IJI?= =?iso-8859-1?Q?NxUP0UMgSzdGeBitd67tiRKSfIHJAMHFbNb1Z78/teiqwBnTzu/CgF2vUn?= =?iso-8859-1?Q?wsWKxpEKNt93+bFq7FcslKeIXjMJvdp2O92IN1qyRApkp6Gn2c5X7AmfkB?= =?iso-8859-1?Q?/bLwHMafymaCehp3T29SFCe/wkajQhWsa8i9F9Puk7jiOtHfkVYjT8TDDD?= =?iso-8859-1?Q?kHkKZjEBU4gKpYz/vGgWhqZQg/ITY0em+AVE2zo9cq0C1gt72syl41Tl4B?= =?iso-8859-1?Q?7GLY+CCkHdImZcpoeuX6vxkECDyXACU4BbHXNg8UKzpLGwWmFoG9dVQbRH?= =?iso-8859-1?Q?8wPod83Nz+FOQwHQFOzZT5akMaKC6rAukEMCBwPFKAe+LMj7k6FPXfHhuC?= =?iso-8859-1?Q?5+zpDRPq7G1SOMc/XHhRki82A4UZCXFVgFA86WDE8J6cUueg92SHoxr6qP?= =?iso-8859-1?Q?6thdpajzwhFKZZro2aKydOZtZA/la5K/6qpFmZThIWfEORkaR5PciMAeDu?= =?iso-8859-1?Q?/1MuQsvofc48OnW3GFUE9lBsXIydbIyK/ZR3bd8NajOQ86zoMI1YarV48y?= =?iso-8859-1?Q?CE7qUls0l0rBwDFTLlcGIvvYnvIUdDgtvZpE/BtE3lUh9z6YzFOibpTv/E?= =?iso-8859-1?Q?aQ/tWwRTHYhrY+jd5Rthz0c60cRusHTOGIM3VVWlz/wl04CnqyGvOKxrez?= =?iso-8859-1?Q?wpywg4gjvbTDjRmOa5mh9Vx+M4Kk57c=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: d7b37322-cc37-452d-e2d3-08df34990c0e X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2026 02:13:24.6475 (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: 4jthMAdr78GO8UYLv++u6FugW8WcJxdsqQvM5xLIU/rpQVVRiMPqwqJ4FazdfPcVPjydLFZCwPVMIJfy0MvpjyzNyZd388As6yKdUfs2tP8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB7925 X-purgate-ID: tlsNG-16d1c6/1793153611-FEA7477B-25A09298/0/0 X-purgate-type: clean X-purgate-size: 2663 Hello Hirokazu-san, Hirokazu Takahashi writes: > Populate the CPU sibling map only with CPUs that are brought > online. Currently, all CPUs in cpu_possible_map are added, > which leaves CPUs that failed to boot in the sibling masks and > may lead the scheduler to make incorrect decisions. I think that this is a scheduler issue then. A CPU has siblings regardless of if they are running or not. Also, your change will affect CPU Hotplug functionality, as with your patch sibling mask will change in runtime. But partially - only in cpu_up, but not on cpu_down. I am not sure that schedulers can handle updates to siblings mask in runtime. Could you please elaborate how it affects scheduler behaviour right now? > > Fixes: 701190abb3d5 ("xen/arm: Set correct per-cpu cpu_core_mask") > Signed-off-by: Hirokazu Takahashi > --- > xen/arch/arm/smpboot.c | 18 +++++++++++++++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > index 8c9072f3c1..2d01896cf0 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -91,15 +91,24 @@ static int setup_cpu_sibling_map(int cpu) > !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) ) > return -ENOMEM; > =20 > + return 0; > +} > + > +static void init_cpu_sibling_map(int cpu) > +{ > + unsigned int sibling; > + > /* > * 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). > + * are supposed to belong to the same socket. > */ > cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu)); > - cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_possible_map); > + cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_online_map); > + cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu)); > =20 > - return 0; > + for_each_online_cpu(sibling) > + cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, sibling)); > } > =20 > static void remove_cpu_sibling_map(int cpu) > @@ -314,6 +323,7 @@ smp_prepare_cpus(void) > if ( rc ) > panic("Unable to allocate CPU sibling/core maps\n"); > =20 > + init_cpu_sibling_map(0); > } > =20 > /* Boot the current CPU */ > @@ -385,6 +395,8 @@ void asmlinkage noreturn start_secondary(void) > =20 > set_current(idle_vcpu[cpuid]); > =20 > + init_cpu_sibling_map(cpuid); > + > /* Run local notifiers */ > notify_cpu_starting(cpuid); > /* --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Oct 28 03:36:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 03:36:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462820.1673806 (Exim 4.92) (envelope-from ) id 1xLuSl-00016W-QH; Wed, 28 Oct 2026 03:36:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462820.1673806; Wed, 28 Oct 2026 03: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 1xLuSl-00016P-Ni; Wed, 28 Oct 2026 03:36:31 +0000 Received: by outflank-mailman (input) for mailman id 1462820; Wed, 28 Oct 2026 03:36:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLuSj-00016J-LR for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 03:36:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLuSi-00Ax8f-O3 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 04:36:28 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae16db4-bab6-0a2a0a5309dd-0a2a4506a6ce-6 for ; Wed, 28 Oct 2026 04:36:28 +0100 Received: from [205.220.168.131] (helo=mx0a-0031df01.pphosted.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae16dba-195a-0a2a45060019-cddca8830cb6-3 for ; Wed, 28 Oct 2026 04:36:28 +0100 Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69S0j9GO2277147 for ; Wed, 28 Oct 2026 03:36:25 GMT Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4hjy712a80-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 28 Oct 2026 03:36:25 +0000 (GMT) Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-89e6ddd4554so403616b3a.3 for ; Tue, 27 Oct 2026 20:36:25 -0700 (PDT) Received: from [10.133.33.27] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3ae5a48ec90sm899533a91.6.2026.10.27.20.36.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2026 20: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=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= /wKdshZSDdNYlVlGGww1CWjddpjIdb7CUnZ1PObkTB4=; b=Jve2qMQHUqrEssgK LflW6/l7KZ234zJVmm5v4avWWbV1TcUiioz11IU7xNAS3yhP+6JpgpsoOMhZWZvJ IPei/BNfJ7ExWg/tShStITm6QZsRQXDRsGswXFZFnq+o9ga6nmbSa33m3OhRLXWT jNycF1Ub6eUUeiAVgYu5ZaX6svI7KSL3EU6+K53Rnc/d554YMUVQJALzktVCxxiV q+Kz86xf3mp9SK5/sBZk8qiecR2lpX8aT+GhaHVmok95F2t7X+5DAAukw34dJtRr PnVGLMYR/XaeQ9zEg45sqiPgK2kxAakvx9jugL9konNgiu/4GNvqT3B3MXccU96s aGnIQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1793158585; x=1793763385; 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=/wKdshZSDdNYlVlGGww1CWjddpjIdb7CUnZ1PObkTB4=; b=bokX1XPpwcYFFqFs83TA5ZIjFB/MRB/4mw8FskWT/MAonIApI5+k8T2Etr4lGTX0Du H+eK3gVuNKpuprcUqNCd/5UjUrw1IYnNkT/nMaXuKNBM3X/CtJOPIM8O4r7kD052XnSp 8KzWCww8tvk1Xh03EpYdfzyKYeuYsuRqI89andk3hwfz1iGqql6gzKy0mZRuuTVDAZvQ xyW/7IZyac4IsNPclLx10ME4kiOocCZEz0BhLyoCzr6QXFkB8sSAjVf+XKgosKTwRGFj UNj3z/GYX/puATtNqM9/QOAcQIVweOXS0baa57RkT2jZjgkDI/kFoM/bgyjNXXCRxN4X FDcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793158585; x=1793763385; 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=/wKdshZSDdNYlVlGGww1CWjddpjIdb7CUnZ1PObkTB4=; b=y4CnKAzotb6ah2bB4uNQph6eDSUW7zgWsSDTax0AdWrYvTQDQJWE5r2E/SJTOlvK58 JfKDMCjUsNXuiV3U7dfZU0m+wgvvRrB7jJmIMMLDDqxd9+kHDNk4ASLaTSGQEQZL7JPl FcjuQndGw0KvUw24ymvvkIV4+UN7Gk2+3xrM2U3e0o1YMpqQ3QUGUC7PK62zvJvnfgTV N86ZyuNjE1927OOa6zMiQYtltVqEklIzQDfM4gOJtrsqZTwxk3kT+rTj371haD1l1CJF BVj7o3H0FN8TYVaXFnPScRedtvvxC0ki4QI2CuiKyFegdYA7F0JARiJsj6o30xgu9oHs ZbCA== X-Forwarded-Encrypted: i=1; AKwUvBzUVk/s/fMLn5lL1why4f+UIuYIBboaqGCeK4x+dzstSJCNq7Rra3cEljc+zGNUc/vCDRbAorbZFb4=@lists.xenproject.org X-Gm-Message-State: AFq9FYLBMmO9H3LfECnEBk9GdXqjdIEEERrgZacEuZalsiIV8zwfjPx/ tKvR2ufPhhpdbjywu4y3azjE8tzcKZl3i6ZBbbg0VhhQLBzUneF+6zvFxewOJWOjteL6VZDnxX2 7ZyzO3yh7kjXpFTafpEwgFqhzyuARiMoQlqvdP5pk9V34BNj84PUh+lmgIvczCO2VMpgSEw== X-Gm-Gg: AYBFou0l030Gcd8br4cS6xLzEOnXFhP5nfBYfvIf29uPYgMId5F5SscwOJxRNE+zonM Nx9Mr73pbXygo7+w5A27/hkMFJrnsWN02/AWmaJ0IH2fHNhxPfvZgaXR/yOn4o0lixeyfFGSoOw uQzatOZ2zlygpD4HIP6Vh3zs5VNDhWu545zlwdIKezl1gtn9lefOinSq5scOCmhZ3waLFhkahaN DzVv9Ysr1Dg7TBNZ0ABbwmqcn+5IDKtVJYd75YUy3Ix4zQI4VTQxcGC7kk3hqO6y7HKlQ82kwQQ vFuioLvrNaFQiT2JnmwnMG99udHrrFuF3Gu7JV0cc0Hsi8SkLw5rnnjZ5RWb1r3A1XfpEOCn2tj nq0gMN7L3h6Xn11w+Zq6Qm3IxOsgk5S9bgiT217RibuwUy+7Otdt8OrF2DWoZ6FdRnT4m7Zp7Vg toivEk8LRsBVeYuUhAL0kfEsJsgmBSHy9nqahwHORoA4s= X-Received: by 2002:a17:90b:5863:b0:3ac:b3ff:b476 with SMTP id 98e67ed59e1d1-3ae581836a6mr818178a91.38.1793158584995; Tue, 27 Oct 2026 20:36:24 -0700 (PDT) X-Received: by 2002:a17:90b:5863:b0:3ac:b3ff:b476 with SMTP id 98e67ed59e1d1-3ae581836a6mr818144a91.38.1793158584441; Tue, 27 Oct 2026 20:36:24 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 11:36:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/9] cpufreq: governor: Initialize kobj_type release callback statically To: Ian Rogers , Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich Cc: Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , =?UTF-8?Q?Christian_K=C3=B6nig?= , Zhihao Cheng , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Viresh Kumar , zhongqiu.han@oss.qualcomm.com References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-5-irogers@google.com> Content-Language: en-US From: Zhongqiu Han In-Reply-To: <20261027223847.652884-5-irogers@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI4MDAxNCBTYWx0ZWRfX1AQFRVz7DjUF c+eUq9EI1ygcSsMW+PGKKK1S6ssgYUIgpdjOJTkAzAlQQsor77tcnLp0k0W+rEyYj7mVIRx4geA LkvuAceBHalIhZlfLqgfcWRO11lT0CsHRHsf7aVc2ThX5OWmYt4IDQSzqpWr06C2Sc0pit6jUwJ BoDw5XNm/OorxP4MFrhx7MXsJ30sFOfuz2ipc6BhNQ5M/nSXctvjK60SLTQaMojx7ocWNeumm1z oWqpe9LGiSpP3BJGPw38yQj/40m6wyzjPS332jfbg002PVCIa/yV2ecHX3oWL/HN6Q+ILpzGrxi xikOEEyGf6RI5PAqolr59WPgaOnKTEN80p9Gk6lJCFEc4YjdDvO5eyCEYCzTIT7RL8kSBCa/WeK CBUN1PPGv//Cy8q6S0vX/xfM701GGxOHsmwyRbXaOhSDOSP2e9DFlGO3DqWc4P/ka16IkzN2czp 5frtVUv89uvfrEBpzyw== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDI4MDAxNCBTYWx0ZWRfXyZhWMKDAmbeY zMJ10E+DQGqijAtoEjpdyf2yt2ttShUbHOyW3em1FFtYM0LDwWgYJWR6CyGhpK6cA8Exw0mHHCA bMcZPQjnsQ7uVydy7a1tU3fomprTCXE= X-Authority-Analysis: v=2.4 cv=JspkP84C c=1 sm=1 tr=0 ts=6ae16db9 cx=c_pps a=rEQLjTOiSrHUhVqRoksmgQ==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=DJpcGTmdVt4CTyJn9g5Z:22 a=EUspDBNiAAAA:8 a=1XWaLZrsAAAA:8 a=MbyaxBA4Lnn_ULkWIDkA:9 a=QEXdDO2ut3YA:10 a=2VI0MkxyNR6bbpdq8BZq:22 X-Proofpoint-GUID: NxWYWPHZQuhhiN-mlMypILlsxQZvRQlS X-Proofpoint-ORIG-GUID: NxWYWPHZQuhhiN-mlMypILlsxQZvRQlS X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-28_01,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610280014 X-purgate-ID: tlsNG-16d1c6/1793158588-F5A0C77B-074958EF/0/0 X-purgate-type: clean X-purgate-size: 4733 Hi Ian, Thanks for the update. On 10/28/2026 6:38 AM, Ian Rogers wrote: > Export cpufreq_dbs_data_release() and set .kobj_type.release statically > in the ondemand and conservative governors so their gov_attr_set > kobjects have a valid release callback statically initialized, matching > cpufreq_governor_dbs. Remove the redundant runtime assignment in "matching cpufreq_governor_dbs" is a bit confusing to me (cpufreq_governor_dbs() was removed back in v4.8 by commit e788892ba3cc ("cpufreq: governor: Get rid of governor events")), as it doesn't seem to refer to anything in the tree. Perhaps we could just drop it, e.g.: Export cpufreq_dbs_data_release() and initialize .kobj_type.release statically in the ondemand and conservative governors instead of assigning it at runtime in cpufreq_dbs_governor_init(). The code change itself looks good to me. With the changelog updated (in a respin if the series needs one for other reasons, or when applying): Reviewed-by: Zhongqiu Han > cpufreq_dbs_governor_init(). > > This prepares for annotating struct kobj_type::release with > __must_init. > > Signed-off-by: Ian Rogers > --- > drivers/cpufreq/cpufreq_conservative.c | 5 ++++- > drivers/cpufreq/cpufreq_governor.c | 4 ++-- > drivers/cpufreq/cpufreq_governor.h | 1 + > drivers/cpufreq/cpufreq_ondemand.c | 5 ++++- > 4 files changed, 11 insertions(+), 4 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c > index 02bfd46543e9..146a2353b1a2 100644 > --- a/drivers/cpufreq/cpufreq_conservative.c > +++ b/drivers/cpufreq/cpufreq_conservative.c > @@ -318,7 +318,10 @@ static void cs_limits(struct cpufreq_policy *policy) > > static struct dbs_governor cs_governor = { > .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"), > - .kobj_type = { .default_groups = cs_groups }, > + .kobj_type = { > + .release = cpufreq_dbs_data_release, > + .default_groups = cs_groups, > + }, > .gov_dbs_update = cs_dbs_update, > .alloc = cs_alloc, > .free = cs_free, > diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c > index f3bd3dbe7c41..f8b5aca09b6b 100644 > --- a/drivers/cpufreq/cpufreq_governor.c > +++ b/drivers/cpufreq/cpufreq_governor.c > @@ -419,7 +419,7 @@ static void free_policy_dbs_info(struct policy_dbs_info *policy_dbs, > gov->free(policy_dbs); > } > > -static void cpufreq_dbs_data_release(struct kobject *kobj) > +void cpufreq_dbs_data_release(struct kobject *kobj) > { > struct dbs_data *dbs_data = to_dbs_data(to_gov_attr_set(kobj)); > struct dbs_governor *gov = dbs_data->gov; > @@ -427,6 +427,7 @@ static void cpufreq_dbs_data_release(struct kobject *kobj) > gov->exit(dbs_data); > kfree(dbs_data); > } > +EXPORT_SYMBOL_GPL(cpufreq_dbs_data_release); > > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) > { > @@ -488,7 +489,6 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) > policy->governor_data = policy_dbs; > > gov->kobj_type.sysfs_ops = &governor_sysfs_ops; > - gov->kobj_type.release = cpufreq_dbs_data_release; > ret = kobject_init_and_add(&dbs_data->attr_set.kobj, &gov->kobj_type, > get_governor_parent_kobj(policy), > "%s", gov->gov.name); > diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h > index 806d8fb4dff1..1026712bb79b 100644 > --- a/drivers/cpufreq/cpufreq_governor.h > +++ b/drivers/cpufreq/cpufreq_governor.h > @@ -150,6 +150,7 @@ static inline struct dbs_governor *dbs_governor_of(struct cpufreq_policy *policy > } > > /* Governor callback routines */ > +void cpufreq_dbs_data_release(struct kobject *kobj); > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy); > void cpufreq_dbs_governor_exit(struct cpufreq_policy *policy); > int cpufreq_dbs_governor_start(struct cpufreq_policy *policy); > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c > index 9942dbb38dae..7386d043c665 100644 > --- a/drivers/cpufreq/cpufreq_ondemand.c > +++ b/drivers/cpufreq/cpufreq_ondemand.c > @@ -374,7 +374,10 @@ static struct od_ops od_ops = { > > static struct dbs_governor od_dbs_gov = { > .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("ondemand"), > - .kobj_type = { .default_groups = od_groups }, > + .kobj_type = { > + .release = cpufreq_dbs_data_release, > + .default_groups = od_groups, > + }, > .gov_dbs_update = od_dbs_update, > .alloc = od_alloc, > .free = od_free, -- Thx and BRs, Zhongqiu Han From xen-devel-bounces@lists.xenproject.org Wed Oct 28 05:04:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 05:04:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462831.1673816 (Exim 4.92) (envelope-from ) id 1xLvpX-0004ur-TJ; Wed, 28 Oct 2026 05:04:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462831.1673816; Wed, 28 Oct 2026 05:04: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 1xLvpX-0004uk-Py; Wed, 28 Oct 2026 05:04:07 +0000 Received: by outflank-mailman (input) for mailman id 1462831; Wed, 28 Oct 2026 05:04:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLvpW-0004ue-84 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 05:04:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLvpT-006B8j-Ol for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 06:04:03 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae18240-2eae-0a2a0a5409dd-0a2a4504c442-8 for ; Wed, 28 Oct 2026 06:04:03 +0100 Received: from [52.101.52.59] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae18242-b57f-0a2a45040019-3465343bae5b-3 for ; Wed, 28 Oct 2026 06:04:02 +0100 Received: from MN2PR20CA0055.namprd20.prod.outlook.com (2603:10b6:208:235::24) by BL4PR12MB9508.namprd12.prod.outlook.com (2603:10b6:208:58e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.19; Wed, 28 Oct 2026 05:03:59 +0000 Received: from IA0PEPF00000039.namprd03.prod.outlook.com (2603:10b6:208:235:cafe::3f) by MN2PR20CA0055.outlook.office365.com (2603:10b6:208:235::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Wed, 28 Oct 2026 05:03:59 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by IA0PEPF00000039.mail.protection.outlook.com (10.167.249.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Wed, 28 Oct 2026 05:03:59 +0000 Received: from jim-System-Product-Name.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.53; Wed, 28 Oct 2026 00:03: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=ouzQv6OIUWe/gp28Dt7whlqb+0QSkp8AWqJyJzKjlOFqf9VuKdfriGjl80dp04g/g4rLa0x0JF9GiYz6eTCnkLB+sHIu2qX7ZUsHlaUinGWA5LrBo8HaTDccDH2ev2H6K7w2G4GGQfAUnqG3fsse9H68tPURCGdaS8BTfaTvrsYGdZMCoEOHVCzUDBFMBxaqlyI22frw+M/wLvTYYJ9DPLfHUFYjKyJkElQlHfT7qS7972QzGY0a9ryhhJoIPYtVVE/ylhgpI6KuFgooFniIOYFCqDW6BiWyDO4O4AvQKxl78bsgAGrK7SlBzF3riiXtFHH190qcxjXr3UpXmXslfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kMYrGPInOhU7jXQfvL98Nfkms3z6Eq3dU6lGpKzArog=; b=pWd+A53aAcQvLH6nT2TnU2EElnoKZ+yrOufzQRK3QoWom50YiOTHBVEBUhdMyE+kXHvdsGOwT9O57megvCbTzab9zDiiwVqI7JylizAv5lxpOd1CXI6GNG2ZKqXPcxheigp0KTyISQ5IZQk8VXTTkwo6j68TTjSyN2tZ+/fGL0EQpxfuuq7QJ7RlymEzD6GWIyd3Z8Dolvbu6uwZ/+8iv4BH6b+HpDYogFomLiuYhk/SxBKXhVfJIWDAIF4SuUvn9qfgYU0u5bJqYVcDOvv1qS675j2SDn5SkFIJGbiF8GWYG+y05JSkWIW5nka7ZWLK8gKMYGIySvfCFWCpIyvBIw== 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=kMYrGPInOhU7jXQfvL98Nfkms3z6Eq3dU6lGpKzArog=; b=uMyOT92LRNk4Jzy/lJ0OraBmwhDdffXd859QimbbOXo3jGZhRI7WOBvys5mGfAejHZtodSQOg0mw2nZxaxDOGZGO3LIGfPpgrmMPzt9dlQ1+joD4kJihbxCIrkWFfZjtXsPTGnvuTr5zvKfM6T1dDWyiCnXB1uAcx6LnCvtmCYI= 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 From: Shuaidong Chen To: CC: Nicola Vetrini , Stefano Stabellini , Michal Orzel , Jan Beulich , Andrew Cooper , "Anthony PERARD" , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , Shuaidong Chen Subject: [XEN PATCH] xen/typesafe: don't brace-initialize a scalar TYPE_SAFE value Date: Wed, 28 Oct 2026 13:03:36 +0800 Message-ID: <20261028050336.2549325-1-shuaidong.chen@amd.com> X-Mailer: git-send-email 2.34.1 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: IA0PEPF00000039:EE_|BL4PR12MB9508:EE_ X-MS-Office365-Filtering-Correlation-Id: 81f58ef4-a4ce-4868-241d-08df34b0e074 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|36860700016|376014|1800799024|7416014|6133799003|18002099003|261026140227099003|10067099003|13003099007|261026121527099003|11063799006|56012099006|261021121427099003|261022105027099003|261009223027099003|261021123027099003|261022075727099003; X-Microsoft-Antispam-Message-Info: PXwhV8H8Sh9xMbhoQbu8RI2qaURxXmA0YQaDjZGOuPEnZO7+aiKSd33wAQf+lNfSDusP4OJR6cBHO86yv8cSFquRVGtNNi1vweE1oKMmHJScZz+MSCXOQUdd5UFA4aKEY0fhAw6OX23ErVbRGR4Ycphk/IZYpkjXAfRBbMzVenGTWbBOYbSfipGkFLgsqmXL3ToOCxhHrFrMjZSKC/JPN65NgKyw5ZzAGxyyYNiFF8N6PBeSyI7vPFnU2hEaYnSx9d0dPE8ws0POjjRwIQ4gN0x8Y59YVlkQFRGGJInVOtN8dUJnvZEyzXVP+J7JB3X29Qinbdgly525VCEbCE9pf1F/doMlqdTlWvw4T6dyVvQLwEG46xaKUNOyeABygcd7CTZ4KtEqQoURR3fhX7ey5EYUdRR7Exnf5TtPFiPcG9GMRfGSPGK+nM478gw5bJE0+zDPfAqzqsKbrrNwwQhl9m13mU9qE4Rl0kJP3woaM9bK1pncU+A8EHTe1yapExLEsyje9lMxw7GwEZ3EkW4nBWD+dkuhdPeCuLeLFIfOL+YVkOmwycUnqgLF0XtvmY7EYFH2nrV8Mqp1+29Su4Uc00mR2zBEJyczcS+VUS2zaRvk0v+zoU6qcKW8jyB81yMQBLwOeefJ6BI8fBRY1B78UTFz2L0VqImCBeVEr8U/de9MMt9EcoJagXfHa+epGvMVBewW3FzUB6JO8fOBorImRA== 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)(23010399003)(36860700016)(376014)(1800799024)(7416014)(6133799003)(18002099003)(261026140227099003)(10067099003)(13003099007)(261026121527099003)(11063799006)(56012099006)(261021121427099003)(261022105027099003)(261009223027099003)(261021123027099003)(261022075727099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: iPo2ooDH3V3ove2IFfOpKe0rM8kD40x0qzt8WdsPARCMR8ukIE9Nw6TpbS7bk1FoLUF96QgNdot43IFtMM3M5ZVdrLY3eGD00vy6l+WochAtDKefXQ6UfYwFkhigScrNmkPZ0rne5NpFYZdSsdwMysyOYy1Feq32Vt3X50ID5OQp0qKuFO3r0Cxd6RE4rsSyLySfTl1v0X8SrXuTntU3q0nOUqsktMZBPxDNs/25JUMpWTK/+Zrl3Mwx/oIPvJLGBMF7vugtkwZWf/lhfwmQtca9C1ju3G4oC/I9mpPHH05ZVuZi2PxRJ2TpOcaqFO1VQ80OCBd3DyUUc5iDnpruiKSKWD09ErfK953GSJ1MMfWn+EsE0yi68o54Fvg8S16A0/JljMuDBMTKOMZmtpaocNyS4U+AK1tMUiZ/DI91J5+yIzvI4eg0T1bG3ZFwJ8nL X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2026 05:03:59.4059 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 81f58ef4-a4ce-4868-241d-08df34b0e074 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: IA0PEPF00000039.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9508 X-purgate-ID: tlsNG-ebf023/1793163843-50AD8B50-AC5B4214/0/0 X-purgate-type: clean X-purgate-size: 3904 TYPE_SAFE() degrades to a plain typedef in non-debug builds (NDEBUG), so mfn_t is then `unsigned long' rather than a one-member struct. INVALID_MFN_INITIALIZER and INVALID_GFN_INITIALIZER, however, always expand to `{ ... }', which leaves mfn_t first_valid_mfn = { ~0UL }; initializing a scalar from a braced list. That is valid C, but MISRA C:2012 Rule 9.2 (required) - "The initializer for an aggregate or union shall be enclosed in braces" - is reported against it, twice in the x86_64 build: common/page_alloc.c and arch/x86/efi/runtime.h. Give TYPE_SAFE() a companion TYPE_SAFE_INIT(), so that the shape of the initializer follows the shape of the type, and use it for both initializers. The debug arm is unchanged; the non-debug one drops the braces. No functional change: with CONFIG_DEBUG_INFO=n, common/page_alloc.o and arch/x86/efi/runtime.o are bit-for-bit identical, both with CONFIG_DEBUG=y and with it unset. With CONFIG_DEBUG_INFO=y they differ only in .debug_info and .debug_line, because typesafe.h gains nine lines and the inline functions defined there move with it; .text and .data are unchanged. Signed-off-by: Shuaidong Chen Reviewed-by: Alejandro Vallejo --- xen/include/xen/mm-frame.h | 4 ++-- xen/include/xen/typesafe.h | 11 ++++++++++- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/xen/include/xen/mm-frame.h b/xen/include/xen/mm-frame.h index d973aec901f..e41d2680af5 100644 --- a/xen/include/xen/mm-frame.h +++ b/xen/include/xen/mm-frame.h @@ -12,7 +12,7 @@ TYPE_SAFE(unsigned long, mfn); * To be used for global variable initialization. This workaround a bug * in GCC < 5.0. */ -#define INVALID_MFN_INITIALIZER { INVALID_MFN_RAW } +#define INVALID_MFN_INITIALIZER TYPE_SAFE_INIT(INVALID_MFN_RAW) #if 0 #define mfn_t /* Grep fodder: mfn_t, _mfn() and mfn_x() are defined above */ @@ -48,7 +48,7 @@ TYPE_SAFE(unsigned long, gfn); * To be used for global variable initialization. This workaround a bug * in GCC < 5.0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64856 */ -#define INVALID_GFN_INITIALIZER { INVALID_GFN_RAW } +#define INVALID_GFN_INITIALIZER TYPE_SAFE_INIT(INVALID_GFN_RAW) #if 0 #define gfn_t /* Grep fodder: gfn_t, _gfn() and gfn_x() are defined above */ diff --git a/xen/include/xen/typesafe.h b/xen/include/xen/typesafe.h index 7ecd3b4a8d5..258404bb915 100644 --- a/xen/include/xen/typesafe.h +++ b/xen/include/xen/typesafe.h @@ -9,12 +9,17 @@ * * _$FOO() which boxes a $TYPE as a $FOO_t * * $FOO_x() which unboxes a $FOO_t to $TYPE * + * TYPE_SAFE_INIT($VAL) spells a constant initializer for a $FOO_t, for use + * where _$FOO() cannot be (an object of static storage duration). + * * This makes a $FOO_t and a $BAR_t incompatible even when the box the same * $TYPE. * * It does have some performance cost because the types now have a different * storage attribute, so type safety is only enforced in a debug build. - * Non-debug builds degrade to a simple typedef and noops for the functions. + * Non-debug builds degrade to a simple typedef and noops for the functions, + * and with it TYPE_SAFE_INIT() loses its braces: a scalar must not be + * brace-initialized. */ #ifndef NDEBUG @@ -24,6 +29,8 @@ static inline _name##_t _##_name(_type n) { return (_name##_t) { n }; } \ static inline _type _name##_x(_name##_t n) { return n._name; } +#define TYPE_SAFE_INIT(val) { val } + #else #define TYPE_SAFE(_type, _name) \ @@ -31,6 +38,8 @@ static inline _name##_t _##_name(_type n) { return n; } \ static inline _type _name##_x(_name##_t n) { return n; } +#define TYPE_SAFE_INIT(val) (val) + #endif #endif /* __XEN_TYPESAFE_H__ */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:05:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:05:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462853.1673824 (Exim 4.92) (envelope-from ) id 1xLxj9-0003Wa-G1; Wed, 28 Oct 2026 07:05:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462853.1673824; Wed, 28 Oct 2026 07:05: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 1xLxj9-0003WT-Cc; Wed, 28 Oct 2026 07:05:39 +0000 Received: by outflank-mailman (input) for mailman id 1462853; Wed, 28 Oct 2026 07:05:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLxj7-0003WK-92 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 07:05:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLxj5-00BMNJ-Qj for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:05:35 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae19eb2-2eae-0a2a0a5409dd-0a2a450b9518-34 for ; Wed, 28 Oct 2026 08:05:35 +0100 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae19ebf-b7e8-0a2a450b0019-d1558036c181-3 for ; Wed, 28 Oct 2026 08:05:35 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a5036bbac7so3426415e9.3 for ; Wed, 28 Oct 2026 00:05: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-4a97c42bb6fsm25163915e9.7.2026.10.28.00.05.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 00:05: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=1793171135; x=1793775935; 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=Tc7spCv2fTJgkdoI13qjZe6u2b0xg4MGuIzXzDYhuTo=; b=S2RXC7ghW7j8Hwe6yEk6z++fbNoUCkudpD1NAy71cnk0jgbQP1QdsPXZXmlPR1SihB WWsJsKwk++5vKVrs1T3Zo7HnIUu9C950M3NEEv6lQjnpwT+Fu/pgMaPFNRsXzVIKKlT1 Chn1+U5WJ1+Wi7ctHolo3U0pGy+tEubbsxc07iSzplIUjkJuG7SqVcyQRLT+4Fq5XJET pU80ReNtpYvtgauGHuwzjTthyoTtYlnuJTt3iDq84Bdqp9D82me48kPe7Zev1Jmx8ShP 3V8p8e6WIzbUQ2Xf2+c754AitryzvS28J0wY4B/MuvO6r0zdJPCu105g3sJFQ5MKuAeg 52GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793171135; x=1793775935; 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=Tc7spCv2fTJgkdoI13qjZe6u2b0xg4MGuIzXzDYhuTo=; b=xKpnK1GCzG01lGOUJQERCDNsM2IfLglueeFs5pKFdkG9HKdr1KRpr+F6nqqctcmE1E /ZLv5M2AVnAjeK/mHAGo3zIfAe0aaEUyDrM/9Tzk0Z9sCevxJHDmx3RfRTgA8zw9IRuL mChFmUW8/GCGkjMs471Bm6RdjWrIUnlb92vFX9DeHpzrlfYeFUHySzndwiKco35DinLY ZuFvpunbCVMsF61WNA2B0nRSQx965A3Yh//Jgup9OFrsgrjQ0RnKDFzcQNoG61aIzkqP Wt5U4eAdwVINRab8jgZ9Hn3tQ+2C9vOnoA+43+iHwnIpoXS1/h/a94/PIAp7vzlEPC/C i5AA== X-Forwarded-Encrypted: i=1; AKwUvBzsEa3Udhb7ZM0k6lC1uw3MB9eTTZOTxu9w8vGrntotH6hNil6R2lLbjkpHjIi0TDhUEYEYMgWNoyU=@lists.xenproject.org X-Gm-Message-State: AFq9FYKTF8ZlggdYcwOexsF9lWmANb2OGDAIKzzbj4GTj9pRPcEqg7WI sgwaXyQSSyMDHCkXM9G5yao9Q+mUTJaOhQ/UE6IoVAX6qOgUU3Fp5neC2AktlmoUfA== X-Gm-Gg: AYBFou3VFT3tNw2cpWm//LmdsbCztY8mIiHkB83J6Vev9HknuVPj1zMHskkkj8r31fZ aPBzWJ4t0sCAJ4Sr9kzHe5vXE+c/APht9GvNnqB6CLPmFKM1KffxLCGhVA/o8UA/asX9XnyAdyQ Gz/N2rgt2EtikTtNnOyaxE5g5fBPTVwORdHgg8Z41pJoTdGEe8z+2PIocltdYy+Jqg5bBt3qtaG ccne0GmZAecIfMd6rQCCENYInuiCHhzFtwVGcbUG0NZ90FgZhVkWQOxR79xyBuJvyPQ6DPahc/Q 3ZdOyL+CCT+rYFrSdWHKUxRPXj74ePaovMlrTU+Zoe5TsdDWLuSGHQ/oJxserRTgN2DkeMpS5/j kgKFv1iWFw+0iUPXUIgMelsO+4BI2QwY5GBeK2U/hSqnQ5j7I6Xj8vtxDMrYLc865lIGIdM2UpS B7Q64Lh0mvEqgVktzd3MYFBdhDqVZtTDJLbpUKw1SfYSVcm+yXu1RURZF3BhSVg4Bxks67kzRFH p3Y+OPNPUTg2ynmHQkxf0yrVfmLK3eUDiPwmJv0aOsAUANDjFutKo2lm3nIMqwyi+HoA0mMyC4+ utUlLeKgvEk6wpyJFSESdn3fmOZkQjkPvVV1Yw04CjelAPBmmrQc658r/KTK0Ff18xm0e8eclbs oBKhsdf1E/rg8e+sCVss= X-Received: by 2002:a05:600c:4f89:b0:4a1:ac66:6059 with SMTP id 5b1f17b1804b1-4a967e8d598mr21789485e9.26.1793171134837; Wed, 28 Oct 2026 00:05:34 -0700 (PDT) Message-ID: <284e1262-2eda-46d7-9307-029faed83d90@suse.com> Date: Wed, 28 Oct 2026 08:05:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/bzimage: Check that the payload lies within the image To: Stefano Stabellini Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261020214825.3655848-1-stefano.stabellini@amd.com> <20261026221008.1143527-1-stefano.stabellini@amd.com> <19979fff-0554-4ec8-969b-6fe50606b1b1@suse.com> <6df73c0e-0d78-d7e4-3837-e4622271f02e@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: <6df73c0e-0d78-d7e4-3837-e4622271f02e@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1793171135-19EC69EA-9BF9B3C8/10/78276251493 X-purgate-type: spam X-purgate-size: 2786 On 27.10.2026 20:43, Stefano Stabellini wrote: > On Tue, 27 Oct 2026, Jan Beulich wrote: >> On 26.10.2026 23:10, Stefano Stabellini wrote: >>> bzimage_check() doesn't validate setup_sects, payload_offset or >>> payload_length against the image size. A truncated or malformed bzImage >>> therefore makes bzimage_headroom() and bzimage_parse() read beyond the >>> end of the boot module, which shows up as a fatal page fault, a bogus >>> headroom, or a decompression failure, rather than as a bad image. >>> >>> Reject such a header up front. bzimage_parse() passes bzimage_check() a >>> length which includes the decompression headroom in front of the image, >>> so subtract it to check against the image alone. >>> >>> Signed-off-by: Stefano Stabellini >>> --- >>> Changes in v2: >>> - drop the UL suffix: setup_sects is 8 bits wide, so the multiplication >>> cannot overflow, and the offset is now computed the same way as where >>> bzimage_headroom() and bzimage_parse() use it >> >> Upon looking again, I think this may have been a mistake: >> >>> @@ -65,6 +67,15 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len) >>> hdr->version >> 8, hdr->version & 0xff); >>> return -EINVAL; >>> } >>> + >>> + payload_start = (hdr->setup_sects + 1) * 512 + hdr->payload_offset; >> >> The multiplication can't overflow, but the addition can. Question is what >> the behavior should be in that case: Adding back the UL suffix would allow >> payload_start to go beyond 4Gb, but that may not be what is intended. The >> alternative would be to check for overflow in the calculation (easiest by >> way of using __builtin_add_overflow(), yet then needing adjustment when >> backporting to 4.20). > > What about this > > > From: Stefano Stabellini > Subject: [PATCH v3] x86/bzimage: Check that the payload lies within the image > > bzimage_check() doesn't validate setup_sects, payload_offset or > payload_length against the image size. A truncated or malformed bzImage > therefore makes bzimage_headroom() and bzimage_parse() read beyond the > end of the boot module, which shows up as a fatal page fault, a bogus > headroom, or a decompression failure, rather than as a bad image. > > Reject such a header up front, including one whose payload offset > overflows the 32-bit calculation bzimage_headroom() and bzimage_parse() > use. bzimage_parse() passes bzimage_check() a length which includes the > decompression headroom in front of the image, so subtract it to check > against the image alone. > > Signed-off-by: Stefano Stabellini Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:14:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:14:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462866.1673833 (Exim 4.92) (envelope-from ) id 1xLxrl-0005EM-9v; Wed, 28 Oct 2026 07:14:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462866.1673833; Wed, 28 Oct 2026 07:14: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 1xLxrl-0005EF-6y; Wed, 28 Oct 2026 07:14:33 +0000 Received: by outflank-mailman (input) for mailman id 1462866; Wed, 28 Oct 2026 07:14:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLxrj-0005E9-RI for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 07:14:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLxrj-005s2i-7t for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:14:31 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1a0c6-e002-0a2a0a5209dd-0a2a4506b61a-44 for ; Wed, 28 Oct 2026 08:14:31 +0100 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1a0d7-195a-0a2a45060019-d155dd32b55c-3 for ; Wed, 28 Oct 2026 08:14:31 +0100 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48c4d99c32bso466385f8f.1 for ; Wed, 28 Oct 2026 00:14: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-4a978d57c36sm23853825e9.11.2026.10.28.00.14.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 00:14: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=1793171670; x=1793776470; 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=yh7+TofLKTCW6Iv94AGACb5h6dTKW3HZAK+d5PKt/NY=; b=cm+4E6yFc70/xbVno0uavQ3kOAsrCxjagKRlIv+kCRHoBbl1cIZrTXurJgiKrUMvrY pmZwMjN3Hq5RXIMomOmB4djjcshR+5n04uVezvagKjrXtWkJRkBI1qbnxBf30GjbP5g9 +h6Atrlk1yZAguIujRJ0tUQm7OKiSDbPba/xsSGbJSr30xg0XYW8fWRv55YBoC4WDmhb sBUaZ8nxLIk3zPm6M9wjw+nTSWT/s+nA+3JqQ/o9BWKbO3JgcIrpaaDLzsLy3HZ+Eb15 pzyVuSOKl2DiWYimFIro0D0vXZykOhdnVzLX5k8A7eoCKBnqFSONYvpxXfqfQ/3njVgi qMfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793171670; x=1793776470; 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=yh7+TofLKTCW6Iv94AGACb5h6dTKW3HZAK+d5PKt/NY=; b=1ia8V7fRwI9iL/D2ri0qg3TvT1w7N53rv+ead+ebbux41jnv8TDmVWXIs7AXKUBUdk fmYQxPeaHZPvONX5VETU0MSGrY/4PnpjvdExDOYll6iUxbT3MZcyJVRwNSu2Xgx7imII C6kYokRR7ooaFncVPtr5RflTjix1P0vKFJsQWc+aYtvYfM38gmH3JzUDH0/fvBAodeP+ wUYyTlR+VBuGE6cLl03JVSCVICcXTZM/reM9ZVx6ZbhaE7MDaBqjbJZr2la4JOlBiiQK /rJBCTpVBmJ79eEo2PYgpLlj6RtCZ55z/bk7kfLC3xa3TNGCyJ2EVT6Ip3HIumMU29y5 F2CA== X-Forwarded-Encrypted: i=1; AKwUvByZA1Y/oCES0Yd0lmF00iwvOiTkbRGbOrjjHAZocHVLOpZq82aKIaj6CYMVLrQyjDozJtH0HynTPCI=@lists.xenproject.org X-Gm-Message-State: AFq9FYLgkRdHEC5yxVLFNaZj3iivu+W/rGLCDDpdF5czdxrBpa8Mq7z6 SVYF+exhJTFbKHj7IrrwTwovz9Jas/aczSTMA25jYeal/1GtNyVBh3hxhXP7nxaFCg== X-Gm-Gg: AYBFou0zW85uVhqwwuQH+b+B2CcHT5It+ss04pSD8al2juIpZ3KibfT4YtBQnMtrDrL r6/y5dgAw3SJff1fgNBzToHDrEQN82lGNu3FlSNMNZwn3U5AeqpcqPuZhuK2n2gnwMsjhrCsanG o4sYCuWZJetmyvB0YcbPp/l24sy2nrQuDfkBqAmckOwj/x3c2oregeBCvK60J18Y2Z3otClX6ro vXvn4IR0g5DmTi+xcMR0Mi7gmzTryp7eNnnkIHTxvgKJIqbnf8zqSmRvHNKhWOTjZmIUp6qeFa9 bfwIJgAvOGE1mo63Q6ksK26M1tPGlC5O8QCIEoESBaAsaUppbWHzhgu/KPMr7J+0aAlCIgvxoIu ghw6+Xx3K3Appb4piG0aGJS7saQigLCLdFFsFNl2kYLzMbYmFqlA9QHM29wfcDa9ZQ3mCixcX5q EokY/4MpUCWWReKouWFURDeeAnUMSDQtq0bBAowv5ejvXjIuAWRDDOhk2Cngj/BhRvmgyNKJfpW XIpfe6PbnnAsTbqbbFjMJChMTaZokaYDimQmnRPy9NQndT2cFtI4esG3hoQu4+0e6qifJrHp9OL cQu3NTaxhEmsPakL0CzTmSRX5HQvJff7RFtNt+n6bX8atlP4skioGg9Tk3ihQrxcnQ3gI5NJ52d 1h+1lDxjoxoTutc6MYSCbwrTyPB1O1BmqsmkuWQ== X-Received: by 2002:a05:600c:a30a:b0:4a4:4d57:8462 with SMTP id 5b1f17b1804b1-4a9672f8143mr17746705e9.24.1793171670585; Wed, 28 Oct 2026 00:14:30 -0700 (PDT) Message-ID: <28ba9787-ffd4-49fc-aafc-ebc552ce812d@suse.com> Date: Wed, 28 Oct 2026 08:14:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v13 13/14] xen/arm: Add vPSCI SYSTEM_SUSPEND policy To: Mykola Kvach Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Mykyta Poturai , Rahul Singh , xen-devel@lists.xenproject.org References: <815a067a28bdc1db079cc3ad068e3ef74b7afe5c.1793129971.git.mykola_kvach@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: <815a067a28bdc1db079cc3ad068e3ef74b7afe5c.1793129971.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1793171671-1ECC577B-C79619D7/10/78276251493 X-purgate-type: spam X-purgate-size: 907 On 27.10.2026 22:06, Mykola Kvach wrote: > --- 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_HWDOM_SYSTEM_SUSPEND if !MPU Why the !MPU dependency? Nothing is being said in this regard in the description, unless I overlooked something. > --- a/xen/drivers/char/serial.c > +++ b/xen/drivers/char/serial.c > @@ -490,6 +490,8 @@ const struct vuart_info *serial_vuart_info(int idx) > > #ifdef CONFIG_SYSTEM_SUSPEND > > +static bool __ro_after_init serial_suspend_available = true; Nit: I'm not going to insist on a change to the name, but prefixing a static variable in a file named serial.c with serial_ looks redundant to me. (I'm also inclined to suggest s/available/possible/, seeing how the variable is set / used.) Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:18:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:18:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462871.1673842 (Exim 4.92) (envelope-from ) id 1xLxv6-0005tG-NE; Wed, 28 Oct 2026 07:18:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462871.1673842; Wed, 28 Oct 2026 07: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 1xLxv6-0005t9-KU; Wed, 28 Oct 2026 07:18:00 +0000 Received: by outflank-mailman (input) for mailman id 1462871; Wed, 28 Oct 2026 07:18:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLxv6-0005rc-0n for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 07:18:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLxv5-00Cfb3-3o for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:17:59 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1a193-e002-0a2a0a5209dd-0a2a4505ee1a-48 for ; Wed, 28 Oct 2026 08:17:59 +0100 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 6ae1a1a6-4cb1-0a2a45050019-d155dd30ece5-3 for ; Wed, 28 Oct 2026 08:17:59 +0100 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48e4831c028so507590f8f.0 for ; Wed, 28 Oct 2026 00:17: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 ffacd0b85a97d-48e3ebcb8d5sm28030129f8f.28.2026.10.28.00.17.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 00: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=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=1793171878; x=1793776678; 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=mk5WFW9eiHu8a4x/pXxrokyNBH9Wuvq6SjmaQiWU1dQ=; b=MzsS3yhwpgDT6kx5ynmHvGz1JqvAjIdQCvT0pDkHbDrykvJFpHGNEJ5qsz3dr8xFbb V6bPby5CUlt0wqE5MFwJogWnuDvVn+WCQhDtEpQy6b6jfOOKubpmuXkAEml1Fufjlwsv pzh17XS0BWvyo47+ca3uFRyg6MoJFIm5muGhwLi3rF3MzTWa6U+UzP5hbxL0EBILptlA W44lZEpuaNw7VMmPldd7sWdGG/VsHTkOb5WiFpVX8l/KiyDemlXxaeU/zxmT/PA3KYUp K02lMM0f5sOsNgTFWp+yEjBIxztugWid98IXwO+/HW2xEO5h+UDWN/dllmWKvBxbpZFD UdOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793171878; x=1793776678; 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=mk5WFW9eiHu8a4x/pXxrokyNBH9Wuvq6SjmaQiWU1dQ=; b=wP8ndkoU3sHNZJkScncfszHej1ycYwR2z3/dDsWg27Xx2hXI/Bk1EJ3WUJyEcKL0DM kQVluY+tgzgnZ1tJBjYlkkWH3fJN8KQ1oCgFR1cA5nfcqm/BjClHKZYytTcZ+4FT3he5 oNlivLJL6CpKxfmfeRY0zfmjBQ9MLoXYh0yLSgFMD2hcK3lwWdlo+H5U0ReZhps/Z1b7 DgjQoejjxt47fvafbLueSNZXdsCP/Zh8ZFjFkZgt/3Ru3apMXJgImcSinQqVU2Djq/iX 7vtxO8n05mgthaBLM4Ob2MOFmsOGUJRhtioULNgLk5aL8dQdMyyQRNz7xV9E2pNXI5Y/ pulw== X-Forwarded-Encrypted: i=1; AKwUvBzfwRem30spVEWr9tXfd+vE/ZfCJdx7pUqN0gnfLKUjuE6k7cDfPsh7s9lZgwGJVdfCJFfelqevvLg=@lists.xenproject.org X-Gm-Message-State: AFq9FYIC1S9Y+HRJxoT1Qu1ByeDWHvtCnlTamnK8F0std0CgfjwyBsG5 76DwqdEVWoOQUqSrk/qWFP//LKSHICQwXiLDS4cDaFvetXtqTX9N/nPowFV1j4jW9w== X-Gm-Gg: AYBFou3bHBz5ocCAilXBH+xt4MpVgjg9mYi9OB5WlVtU9EaXy0Y9Rb/nRbNUyLBBFBq B6dRjXgHVCAPus+ZsRE3SjIb3ixuIOp9cCeHlni2kC7hcXMLt6DTrtaRVivYi7zlnaHcRMYWxks W5atVJanJHqVlfqGF56ptYdwyfRK72inTrpU71sUsFOPOoawMqfx0ukmpX1PDFPbHdRcxonsd6c ++xZtRA4aUnMPXhPExlVceTV+sLqOxu0SvbDrqDyBGgL9kL1VE1nUU9X2A8xDMRPiMSEzu1cWH2 PtUzI6G9HXNjBztfnnJBoc0EZrUzKpJL2W+GxSRge+dRUKohb+ep6KuFuYPew6s87D/rEcmo5Su tuhh83cQ0YiTnq1abH7xbQx0NtQuhNn/9xI90DCFiQ/QVYCtl2cOcKT9n9crBaDxHg7dr9UiDZk 2Z3TazTC5tM0+z83f1+h0ZdE7SdRtWvhGG8KEg9zo9PsXGat5tYYjI8bvkhSoRhD1qINvbd8/ex GNyY7S6LYLhU8qWHcu/CcdxJlnfsfkM4ZbxaYfTrrF5We+PNIXII7tFhT9MkZBcs6TyrmLJZ/Oq if+Prtj93KtuG4dlooiRT0OV49uFdLaA0vx+BTml6qBmUEU+PhYd6oe1/dDE8ifMKvErlmWu7UG tG98xsPqcBiNBUmmg8w== X-Received: by 2002:a05:6000:26c7:b0:48b:108:48cf with SMTP id ffacd0b85a97d-48e5d45a4a0mr4281584f8f.25.1793171878454; Wed, 28 Oct 2026 00:17:58 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 08:17:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/vcpu: Improve code generation for VCPUOP_register_runstate_memory_area To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20261027201754.1307173-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: <20261027201754.1307173-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793171879-F60AA2A1-2BD28BB7/10/78276251493 X-purgate-type: spam X-purgate-size: 748 On 27.10.2026 21:17, Andrew Cooper wrote: > Both XLAT_vcpu_runstate_info() and __copy_to_guest() are common paths in their > respective cases, but the optimiser can't/doesn't merge them. > > Rearrange the code to do so explicitly. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Teddy Astie Just to mention: This is only the x86 list of reviewers, whereas ... > --- > xen/arch/x86/x86_64/domain.c | 13 ++++++------- > xen/common/domain.c | 11 +++++------ ... this is a common file you change. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:32:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:32:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462879.1673852 (Exim 4.92) (envelope-from ) id 1xLy8h-0000F7-Sy; Wed, 28 Oct 2026 07:32:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462879.1673852; Wed, 28 Oct 2026 07: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 1xLy8h-0000F0-Q0; Wed, 28 Oct 2026 07:32:03 +0000 Received: by outflank-mailman (input) for mailman id 1462879; Wed, 28 Oct 2026 07:32:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLy8e-0000Eu-R1 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 07:32:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLy8e-00A4CR-3J for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:32:00 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1a4e0-2eae-0a2a0a5409dd-0a2a4508af18-48 for ; Wed, 28 Oct 2026 08:31:58 +0100 Received: from [52.101.228.81] (helo=OS0P286CU011.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1a4e7-f659-0a2a45080019-3465e4511c92-3 for ; Wed, 28 Oct 2026 08:31:53 +0100 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYWP286MB3349.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2da::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 07:31:48 +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.0546.021; Wed, 28 Oct 2026 07:31: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=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=dR4SjWXKZXOaEKA74iZ5X7HQNzv5c6bnM9hsJFExBMcEoR6EU8/pTiN3GiP10TVZZ+5NO1ODqn6LlFPyuv8I0tZyxPzYR/YEl59vw7CHjIOtGkclo3l2KA4UAMEA2KXObb+lF7A4QQwlb6lUyx6Dwk3hGTdH0aG7xazuceKmurWstDijLBoYouxOu9twevJ9YWqTlmEkUSByaudM/MFOhtbh6QRDUDaWlRJKpZZAsMMWnY7P/ScXgKhuG5u29vBjPQbspvoD5R++WDCvQi1Q29r7sbMOyJKGWWhW/9oaYengO8nBLCEtAZp1l5P80fZnLaDYPnZIs/PySvlJ7z8Zwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bkPJNooUByqU1llh1Tj+YKR75Xu3gUPpvsmUpTdn8zk=; b=C5/+IHVHb3OhD0utBR0samWxxvI5y/J9Uh9EpaHTDa5/mLii6N98m/FWVDwHunuBoxV5fzcUhoI/BIfW4iEubBcIkHasR7ifBB9l6o155vARyhydfbNPZn3vdxvdjtb+U1znA2IugdPOPcQIgZgczRzrBYyRVcdOdWBxaQoXR4D+5+xXgR8asAIQ3P45vLCrzXwqwFvk0r4NuGqTN8dD0t/IMBHqZI0kT7RJC1Zkgqr43zmghNDUysrLTzKHVjaPdjZkSE/7AO2SQRci8SEpYtazlVIIuDQTJndI1BK+UP3qzfKneXUWmAbRTqq3My2ks1nQUcAnrUroKF2qreSKeA== 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=bkPJNooUByqU1llh1Tj+YKR75Xu3gUPpvsmUpTdn8zk=; b=UNtSdqoE2kTmZM8O6Y8lQGm+abcbNz32jY4V06hRzjqFmVU/Uuxi32GWUrY2smpcrwn7kNUIZeLvemS0tj13KQfO5ELBLHbmHzGS1UuZoRp8Rw0d7GY2Xt7MBoNVd/ucFI8BKv3zmjHGN2RWK8d6qHnzUTkjrM3NojvZG4zFm04= From: Hirokazu Takahashi To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , "michal.orzel@amd.com" , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: RE: [PATCH] xen/arm: Fix sibling mask setup to only include online CPUs Thread-Topic: [PATCH] xen/arm: Fix sibling mask setup to only include online CPUs Thread-Index: AQHdYt8WC0CZ/VfzZUWl8UFycAlt/LcSkMeQ Date: Wed, 28 Oct 2026 07:31:47 +0000 Message-ID: References: <20261023110925.128195-1-taka@valinux.co.jp> <87h5i6r2rg.fsf@epam.com> In-Reply-To: <87h5i6r2rg.fsf@epam.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP 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=valinux.co.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OS9P286MB7222:EE_|TYWP286MB3349:EE_ x-ms-office365-filtering-correlation-id: 4ad4eb28-87b3-4d4a-36f4-08df34c5867a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|261026140227099003|38070700021|4143699003|56012099006|261026121527099003|261021121427099003|261021123027099003|261022105027099003|10067099003|261022075727099003|22082099003|18002099003; x-microsoft-antispam-message-info: S+RHAPZSynIXshzfyA4/aInVnoxUhc3r+3A7+U6sYwezDNHd9NWV+KUkj4fFaZthTOJgti/d4PVJIFqeqXSSInfIIgSM03Yx9l1nLAr1E/caykzH9rVus67lI33R8Wqe7SYYhNBIogpyVxV8wMKUZMFwFUO9nwrOQPtfHb3CMJbOobMVMks7iz+wwH0sgBQTkulOZiLR3QxiqfLImp1sXAixCgyaydoAQf8s+RFYIOoK1uYO4qu2Ft7E4ab8xNHoI2FXWKnjAjEWL3JpBltAP9KkXKEay1nvmStpriKYvwBJ2+2Wtua1dv+yD9N0RY6C74ZiRquA5RRHSVsLqZV5mXRSM10Fz1M08t+AgqHJvB8yok3a3wSDkgdgDw1rQN7wt5g6RFK62PbesDHtGDe9dBzV7IolGZQptFNDMN7FGrN/kuikYpypvpWjktQ/CS1T4a8BK4RJh9m3jOjxRrRbiCQE8d7xP4TIgoEiYI2a1l9e6tsujHNJb73toOMX/j085e15zkO71OQHxYc7uBv74pVzL3giuSiGO6MFySpbvXKmum/WfyGkqdKmf0bLYqjM8ZkYtCWr/jrMTyRTlMDgAbxl+wzBkYXnV+NdKOBReqCQ0Jw7rxIiJjijgquVRCH1ilLhGEvtVP/b3QdFtTyd6YP9QrtV2VlUllHKLguy44qXRFpmyZYn735gk7AM37ADTW9LgMN05GKVXE1w/U40F2BdQ35k5b19XnyDcGsY9eY= 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)(376014)(366016)(23010399003)(1800799024)(261026140227099003)(38070700021)(4143699003)(56012099006)(261026121527099003)(261021121427099003)(261021123027099003)(261022105027099003)(10067099003)(261022075727099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QCXhGwhKfL2RUaLsM4Sx68GHfYNSlNZXRxvhmB0ZE6ID0C4VA0a7GlhRUWPN?= =?us-ascii?Q?UdChpT84gXZeToR/tTSbKPf14ks9a/+keu3lTh0MQssyDMtM+m3/2rVVb5tq?= =?us-ascii?Q?Wy0pTkZxxOQhKaiUv+ZikVmlclC2VGMv9zDZpwra+rMdSX0SwVmNJ0XTPG02?= =?us-ascii?Q?HajQPesYPEigaynswnHEmhYQRPMuCb8JrhY1a6N7GTqYzf1ucDYoPnJAIHyU?= =?us-ascii?Q?wmrrRWxA1nOvkVRxzgWLrz3vnYcQWmz0rx8oOQZy6CQw3Omz4f+e3J+6ZqeC?= =?us-ascii?Q?qxPfEwAFCRiDBYmx4uiViSDj401MJ0IgAPQ2X/7sbB5ZVJzC4gqtuuz8/s8R?= =?us-ascii?Q?ciflBopMk3TlUDR6aJkauABuGOpvEV2rx1YWA3PCJg7SDNTIoIv1/kbEVFEa?= =?us-ascii?Q?61ggRORqJ5IE62yw0U5CYkgi224d0CHsELNTbZLlz6qQEIBr1dJE4Rltjl/y?= =?us-ascii?Q?flEuDvKK4554OzT/iw/zy+eIJ97Hh+0BoE19rXMbUeA3X2c5z0Ydl4YQOwGL?= =?us-ascii?Q?c0SRc6Awsay1TobAGI28FVIiaqo/3ruDKgMt7Xj0mfrHFJCPkOel0BHr10Am?= =?us-ascii?Q?m0EZ1wpImVF9ezyN+RQ0sbh+TBry1MvGy/YjDMC3l45cphz8PnDowRJhqa95?= =?us-ascii?Q?GloeDtC+edfkGKgxaUUcnA/V0Bu4qU5mZ6zhRiwgD+IUOG661cYNjWmnOAEa?= =?us-ascii?Q?8VxYXHvk/0VtFyZRKbpYZMKekqH/Pa8m8MlLAJAce8FGI1FnH15bmRUedcVc?= =?us-ascii?Q?5CgrwL6OsFI4ToqHi+0zq5Jek69AyMVvZoVWGYVJx8M1RkaqkFOzKszBbhyO?= =?us-ascii?Q?nrkpWezVU/2L008MDhais2LAmyhRIJPAaTxK6T6qJjAJ6XSbt8ZpkjdE6QV8?= =?us-ascii?Q?YIzWPJU68Sclwxwso4tx6igNVuXRpyL3wrnjPcFhuJ7R1e46o1l27C9QUn7/?= =?us-ascii?Q?aSXy3Gg4am3vd9O+JOyggPVGEDsXyi0N7PIdfptjdR0384IfC0jGvjUoJcM6?= =?us-ascii?Q?FZLkGXqPHRDeJA9FiDs/NHuonyIn08otcOYvCufPLC9L/z3jkjh3k2An5to4?= =?us-ascii?Q?VKyyYWQdqSMEmKhOagAX2RgFi+Vpeurl1CR3yu9pIXVcntdKcBNakq8LVB3q?= =?us-ascii?Q?PofEdqnFAEsNBqxdM0BZmNDgphFCkL/3Y/0dBlbXo6mVpv0dLd4VZSnFyU0e?= =?us-ascii?Q?idxM0kPZMTm9dE7NGJr6u1ikVO9CbXGYhtfrdRq9t54WjSMyuMVRdju5lYIj?= =?us-ascii?Q?e5+QOXvikS3OEX7JW8OtDCWt3OaeF1uPrcFx4U+BN0KyiDUaBrN45M+ZJEWi?= =?us-ascii?Q?qfsCjYrqS8nrxBgAbr7ZAOYo7OJIk3VvbWYBjGYBtJPJI6r6ZU3JL7Ob3uL+?= =?us-ascii?Q?XebfSXrdDfSLAr2pSnLaZZkzIUboaOm5mowSj9JAWFDbjzT6CqvfJmrfKha0?= =?us-ascii?Q?++pSFYqJtYgI7hFpiJ5f/Wp2okFVne84U7Z3xuW/0NbQ1fvo62vXFCOhzmf7?= =?us-ascii?Q?TdYBaWWJSAYVa0Yj9gsHOqdHoL7U+/ce0IcmC1E9+fg6RNTIOgM76/zdXm8Y?= =?us-ascii?Q?sWar4KrJkHlLX3NHGA+Nln5KN6xO4cux3Vi6E4frak54BrESpn0IQojDhHjV?= =?us-ascii?Q?Hs4XTgAqD+Dmdd74IJWbUlvige4E3awq4oUGZN147ZQvlf/40rvJNyQVsXuC?= =?us-ascii?Q?lH0o0hND9IlWl6MUc7LA6Eu5/yF9kVt0YMZnXQXh0rmtFEnS?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 4ad4eb28-87b3-4d4a-36f4-08df34c5867a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2026 07:31:47.9084 (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: ppwwESo7/LPujsb9AWSfQ5JAuCx11ZaXLUO+h93pz3BsNIKVGfw9BTJK5G1Qmp+FLxrYxI7a/nxAyP8sl6zkjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWP286MB3349 X-purgate-ID: tlsNG-c1860d/1793172718-D6F5F87B-732C85A8/0/0 X-purgate-type: clean X-purgate-size: 1938 Hello Volodymyr, > -----Original Message----- > From: Volodymyr Babchuk > Sent: Wednesday, October 28, 2026 11:13 AM > To: Hirokazu Takahashi > Cc: xen-devel@lists.xenproject.org; michal.orzel@amd.com; Stefano Stabell= ini > ; Julien Grall ; Bertrand Marquis > > Subject: Re: [PATCH] xen/arm: Fix sibling mask setup to only include onli= ne > CPUs >=20 > Hello Hirokazu-san, >=20 > Hirokazu Takahashi writes: >=20 > > Populate the CPU sibling map only with CPUs that are brought > > online. Currently, all CPUs in cpu_possible_map are added, > > which leaves CPUs that failed to boot in the sibling masks and > > may lead the scheduler to make incorrect decisions. >=20 > I think that this is a scheduler issue then. A CPU has siblings > regardless of if they are running or not. Also, your change will affect > CPU Hotplug functionality, as with your patch sibling mask will change > in runtime. But partially - only in cpu_up, but not on cpu_down. I am > not sure that schedulers can handle updates to siblings mask in runtime. >=20 > Could you please elaborate how it affects scheduler behaviour right now? In x86 Xen, __cpu_disable() is called in the cpu_down() path, where the tar= get CPU is removed from the CPU sibling map (via remove_siblinginfo()). I think ARM64 Xen should follow suit. > > Fixes: 701190abb3d5 ("xen/arm: Set correct per-cpu cpu_core_mask") > > Signed-off-by: Hirokazu Takahashi > > --- > > xen/arch/arm/smpboot.c | 18 +++++++++++++++--- > > 1 file changed, 15 insertions(+), 3 deletions(-) > > > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > > index 8c9072f3c1..2d01896cf0 100644 > > --- a/xen/arch/arm/smpboot.c > > +++ b/xen/arch/arm/smpboot.c Thank you, Hirokazu Takahashi. From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:32:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:32:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462681.1673861 (Exim 4.92) (envelope-from ) id 1xLy9T-0000jD-8C; Wed, 28 Oct 2026 07:32:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462681.1673861; Wed, 28 Oct 2026 07:32: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 1xLy9T-0000j6-4x; Wed, 28 Oct 2026 07:32:51 +0000 Received: by outflank-mailman (input) for mailman id 1462681; Tue, 27 Oct 2026 22:32:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLpiM-0000Is-O0 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:32:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLpiL-00831V-ME for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:32:17 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1263c-2eae-0a2a0a5409dd-0a2a4507ab4a-46 for ; Tue, 27 Oct 2026 23:32:17 +0100 Received: from [3.74.81.189] (helo=fra-out-004.esa.eu-central-1.outbound.mail-perimeter.amazon.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae12671-b4ea-0a2a45070019-034a51bda0ed-3 for ; Tue, 27 Oct 2026 23:32:17 +0100 Received: from ip-10-6-3-216.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.3.216]) by internal-fra-out-004.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2026 22:32:14 +0000 Received: from EX19MTAEUB002.ant.amazon.com [54.240.197.224:16086] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.14.248:2525] with esmtp (Farcaster) id 34426368-de01-46a2-80a4-9e7ac2f0abda; Tue, 27 Oct 2026 22:32:14 +0000 (UTC) Received: from EX19EXOEUA002.ant.amazon.com (10.252.50.139) by EX19MTAEUB002.ant.amazon.com (10.252.51.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.56; Tue, 27 Oct 2026 22:32:13 +0000 Received: from BEUP281CU002.outbound.protection.outlook.com (10.252.51.94) by EX19EXOEUA002.ant.amazon.com (10.252.50.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.56 via Frontend Transport; Tue, 27 Oct 2026 22:32:13 +0000 Received: from FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:20d::13) by BE3P281MB6226.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:104::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 22:32:08 +0000 Received: from FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM ([fe80::7b1c:7a5d:c405:6c4d]) by FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM ([fe80::7b1c:7a5d:c405:6c4d%5]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 22:32: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=amazoncorp2 header.d=amazon.de header.i="@amazon.de" header.h="From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:Content-Transfer-Encoding:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazoncorp2; t=1793140337; x=1824676337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ncj4joIiKbPl16HQlEIKHQhWwv8Vu9xouoGMLLvA1/0=; b=DEa3qU/hPy5GMG8VzFw3EBhkYXSEQ4N00EJ68DQJ2/5vBU/CY49s/Jxn ZYdMcTdG6Dk1utaSR7QPmpVEZhNHGM9jxqkjVZm1oajLAkjmS7eh8lraA Ufatu2wdQaLjliiyGO+F3wAMGn/W5jpjLXOUgm5UzaTUq9mjf6fl+OfJt XRXbcqP0DearpR0xmIUD+x7VLfFStJpG8tiJzoxCGwdSx6PWIx+thq1f7 GcK024aNQ8N9P3QqqiXKxHiYXpgTzXZjr8moOXs4cdr/xF0cso1oBEsYa ypq+jtioawCo5MGZ67qi+Jptos+T9X19stz6RUTQx4ZH5CVuQYxZcSRtf Q==; X-CSE-ConnectionGUID: AeYYbsXURJyT4H/h4cm74Q== X-CSE-MsgGUID: EIQnOeM8R/C2JfIx6rkh5w== X-IronPort-AV: E=Sophos;i="6.27,181,1787011200"; d="scan'208";a="21851393" X-Farcaster-Flow-ID: 34426368-de01-46a2-80a4-9e7ac2f0abda ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dtZQW0xIXsfjR6x5jax8X9Ag3k15rHtmt7dueOe7wCX7QyNemIKl3fNDj0oN1RiOYPsn79G59DIeUZShDIOSMtpaYfYH0/cIv7xGUTCL1OQy/7hYFFpFOrkkpr1OZqTgQTNR5+mX2FcL+NyQ9rNOKIGOLBUR7Z1cXqNzohPL/p9GyCHhejrAfyavzI0yO1iAofRCmvOfb2ysH3S7dEX+5Kkv0A3kCdWiMv6S2X/9iWQ5iQx3hvl2IaiEN985zEwLayVBjVltJfyUTAbKE9xQJi5y4rnjc3w6LyW6/Sd/wy0hqf4YGpdgAf0crSBkNHI7VBJe0vEoDI6m8dY4CrTmCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ncj4joIiKbPl16HQlEIKHQhWwv8Vu9xouoGMLLvA1/0=; b=ODuYXKFun2vom1228BH2sKny64I15JBPEjrU/QwwNZEOGFUtDQBE5bna/uQM9697IGYd9x8o3hHvr+qrHPcFOZFW5zobrIdN/BFWsS8Z7YS46/L7MNuSljgUpJCaSd5Sw015gsyLFN7S015NLsiD6TYuXJkr5/CoYtR4kxNqAEeFdI5lkN1wLgu4HYuyuxGLYh42KU6M7QJ/o6L04ymf8lO0GOOtrjtEmvGVSYlP4yVVlCWxXsnWwQk1mhOyCIHDMadZbCqfSUXtbxN427vo1tW/bovm/nOpEryg7/GV8JRK3MLy6R8c+EyTKu3bII86H9H6IveUjoO0SCO6pBj+tQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amazon.de; dmarc=pass action=none header.from=amazon.de; dkim=pass header.d=amazon.de; arc=none From: "Graf (AWS), Alexander" To: =?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= , "qemu-devel@nongnu.org" CC: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , "qemu-riscv@nongnu.org" , Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , "xen-devel@lists.xenproject.org" , "Sergio Lopez" , "qemu-arm@nongnu.org" , "qemu-ppc@nongnu.org" , Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , "qemu-s390x@nongnu.org" , "kvm@vger.kernel.org" , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato Subject: Re: [PATCH 11/11] accel/nitro: mark 'nitro' accelerator as secure Thread-Topic: [PATCH 11/11] accel/nitro: mark 'nitro' accelerator as secure Thread-Index: AQHdZmMAlMw9PSV1v0eV1IWyw8llqw== Date: Tue, 27 Oct 2026 22:32:08 +0000 Message-ID: References: <20261027181400.1752951-1-berrange@redhat.com> <20261027181400.1752951-12-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-12-berrange@redhat.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=amazon.de; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: FRVP281MB744463:EE_|BE3P281MB6226:EE_ x-ms-office365-filtering-correlation-id: 41515744-e6f2-4e5a-2257-08df347a229d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|23010399003|1800799024|38070700021|11063799006|4143699003|56012099006|10067099003|18002099003|22082099003; x-microsoft-antispam-message-info: V3naHdaXcDPRPFZcaE/ps35mVFaYglsS1RDsqeXggSjOlm51x/PJmLU4aZ3WW2V0PJenPrkwvW2GSYaV4ZAlQd8RG9rnBrLjiT6Qs2DJXiyh3peDkAZ1Ay1uo1NeKM1f/E256KpBzD2tKs4/mGXD4xC+cHG4zTOOsF2ixW6nYqz2AsnkUcKpGXAJz5W+iuGYno8iRpJTGV/W0oCv+GRKNpxnZ+NvGuoLjx9oQHQmmewZCTqT68SRx/SE83+UuJKM1xk0vrsyYctBKxgGH08kBizjnu9UI6KK7lrQmlM02AxLsCYWFLOI2E0H/wiuDXcGaQLv3INumgsLOOnnddrxDDZr3l12D3fbGM1qUj6U6zCjrNHLOuTs2jdQoX/2iW9Hmy7P12OfawR6ayn70YzbKmlrhyljhapFNyu0Xhub4fXLFd/8ild5CSCQG/PmY2Irz7i1EQW0J1W7xWY+ZM322o1Ghv7wWQdaEdFxo53PorjFLYmvk/9BBAY+KaRP7hJxnEoDgjkfMRLHc3I7OO+oSJZdqRabDAB7S5bxe8sTH8Gb0hocS65AThFn+kma7nApCoKEGEND+bkD9g1/KbefWVovbKVdf3PLyKUfeflrFdHvQ997Y4PHt2gEg9sConppGD4egsUCYSPRO4H7TrdoF2hKifckVlku8sPi0FDmb00GhmRm3yMxb2Y3qoTceE4y0PBX9+2SGeZ+ep8d07eDkqkqwVnkQVVNCPnBn8UH6KQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(23010399003)(1800799024)(38070700021)(11063799006)(4143699003)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QlhSZlFqaXd0aitmb3NhV244Z21QNkdvRHBjWko2Q0sxUlNrQUJkNndHQmhC?= =?utf-8?B?aTFjSFZwSjc1L20zMExZVW9VY0xVMFo3YVgrdkZNSnl1Q3NlRzAyV1YwYzRG?= =?utf-8?B?K3UrcWU5VUQ1SDhPS2k1amsvUmRwSHNwcVR3dXFRYUJwMjNyUG9waW1oL1Vm?= =?utf-8?B?d0VMcEo5c3pNc1N5WHdQWU5DU25EdjhxY1BSUlJsdUk1U2xpVUhsTkpnOVRI?= =?utf-8?B?ZzJNZHRpRFpjbktMM0dIWXUzMG5yQ3FhdEIzZi9rMnc1eGo3U3psZ3gvQ00w?= =?utf-8?B?cUVGaE5lODdHRXdjVkYrTzRJN0ErbFprdkNNTXZQditMb0R1Y3RkdzJ2cFVY?= =?utf-8?B?Y2Q5OUZ1NC85cjBnZGJhUlJNNWw0TVhvaVZSOElFT1NuL24wYmJzeXdGZEhH?= =?utf-8?B?MjJCbVREWW1TSDBWUUlZUEZOMmluK1Ryd3NOM2tNOFdYWVpvZDZCcnFmWVNJ?= =?utf-8?B?VDBRTzB2Q3hZRFRrbmVpdTh5R0YwK1dkcmVEYituc0lQcWtYVElUZFhhUkJ0?= =?utf-8?B?b2svcUtkN3R3U3g5TDV4N25YUEc4TDhEd1dlbzFGYzJVRXBnM1VTMDI4d0JY?= =?utf-8?B?TGhMdWpycFlBRmFrdFQ3ZjFEOE9uQTFGUllaUUtFR3hRZk93NGhYTzJmZDQz?= =?utf-8?B?dmo5dU5OQ3pHeU01a1kvWTJrTW4vL01VWll2REhoNWtNcnVFN2M5ZFBKdjNt?= =?utf-8?B?RWdmdUVmS3BRRjVkb1I0VGtUZDRpcHdFd0hqb2o2OHpqWFVTNElaejhGODN6?= =?utf-8?B?WFJxRklvTzBKcU5GUm9FdC96S1loT3JBZmE2OGsvQ0FxeU4rNkxGOTYxdURE?= =?utf-8?B?NEsvUGV2T0pzTXo1U0pJdkl2Q0hOUWh5ZXZ5YkV4dk92RmEwS0g3ZUZzbmVJ?= =?utf-8?B?L2ZKV3VjOTJIR3JZby9qS0pobklFaUhVWFlmMkVSZXkrOEhIZy9XS1EzSWdN?= =?utf-8?B?U1BBSWFYeVh1QmpJMUcxekVZaHIwby9pSW1LdHNxZlYxNlJpa3QwTytQOU1i?= =?utf-8?B?NTVjNFhObndOVWpTdmgzTmtWTVA0WnFjcjV3eUZHNWQzenpXajZYTGRLS2Nu?= =?utf-8?B?ZlhXTVM0SmRNRzh4RlFpc3hqYVV4Snp4cUd5MExqdVdlWEg0QXFRU3o1NjJX?= =?utf-8?B?ODhERjJ5dGZxckIyM3RkcW1EaWo5eURjRGlMcUpCc2lTTjNmYnlzb2o1YnRl?= =?utf-8?B?N1NrRThpb2dXeTNyUmZTYWh6cjZJYU9nS2FrWWczbklzb1VUTWY0RGRNWEpt?= =?utf-8?B?MkZEd2pQeUc3S3pkYWJmRWZuaU01NXJMTXR3Yks3d0VtY1lTODVqMmw3Mk5v?= =?utf-8?B?UGFCbGlJK21NL0MzSGM2UEtUcUIxeFdveFhpZ1JVWTI1bW5MNjBUa2NzaCtU?= =?utf-8?B?RWg0L0swcUlUeEpOdjRqOHFMWGczc3lyV0t2bzdjbGRkamxnc0lhOGx4OCtX?= =?utf-8?B?KytlZkUwSmdWckZtWnE1eG9xVm02bWpkaXZaTnpaMlJUaVZjeGFsYmtJUGtY?= =?utf-8?B?ZFcvcU5RNmUxdmpWSVZUT2JpdjREWjY0ZEFxdXNLQVl3VUVGWXhsWExUT1Ur?= =?utf-8?B?czY3bHZDc1lBbFA1ckU1bGV4ZEpacnV2aHhVVVFoNmY1cEpMQURzSEVTdmRv?= =?utf-8?B?Vy9EV2pHaUkzMzFNQTljRm9yem5vZFpLYWVoNkR0aDU3OFRHSksyQ1haRzdo?= =?utf-8?B?Uy92SERaRnNSK2djSU9XekNhc2wxaThtTitXNEU3TFNJdFJFMWhUc0RzZ2ZY?= =?utf-8?B?MHdsazA0WXJIMHhuMTBac0pGczNPVzlLWVhqMDVkWlBUdmVGR2t4NUVwMDR2?= =?utf-8?B?QmZ6YnJJVDVaS3BoUHh1RXBRYUR3K01iWURGQ1hoYWk5WVBzdWQyZThYQWpX?= =?utf-8?B?MTVxY1kyY3hLdUczMUI0WE8xYkZ3VVhxMU9RWTRpY2ltdllHK0w2aHZjbDBi?= =?utf-8?B?Q0JPMm9TQjRHa1ltLzZDTmhEWS84YlkrVXgzSTdVdTk3bmJRQ3BSQysrUWJx?= =?utf-8?B?ejNnVVZZZnlpaEVheGdlVlBEQ1cyNG8zVzB2MDBTSi80eHorajhiaDR5WFpa?= =?utf-8?B?dDlZQjVpNFVNcEY0ZHZraGFhMlc5Z2VkQ3Vzcy8vL0lJdlc3TFh1RG11Nmpt?= =?utf-8?B?dnZJK3o1ZWdwQ0hZZGN1bEtVZkpFUGZyVHJIQ0cyQXY2R0ZnR1ZLMHcvU1FR?= =?utf-8?B?cVRVSGZBeFRmak4waHJVTXFLcG1SelZZN3lFc21yZEpPbit4VE9tbzI3WWRG?= =?utf-8?B?eDMrWDdPeHhSYzZOTUFzeDcvNnBvVkNOU01jcHJJSjUyd1dQWTduQkNCbWZI?= =?utf-8?Q?sgbTg/dYUez4UECoGY?= Content-Type: text/plain; charset="utf-8" Content-ID: <71E8D876F7E6D54AADF6F7659FF02972@DEUP281.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: ehEdWFHIf7fR1UukeOg7VdK87LLx24FTy6+QD2n+hBRqZTreXslNguE1G3xzNAHPB4UqeqtFU9mbRxfajtXds60RmzjYeCbGnNOzm7ithNr3UTxOkQfzzzfgPdy1JEa02sziO2lb9VzmrkdCbAi8fETgR5T2UkeDmwJY2gadnoafMyCm+Xmwy+qLnlaTcs7nSjrafbKr/4fDNWJSyi+gddp4KZ5upuymfN/3H+q2bXEeeEh5grLHJSQFyFAOaDDvhee9KuRjjqVjzN7zCl9lpLlswPAtUKu2n7G+vbpZdWFSJrUd/kwAH1eDhytpr2nGLOSylFORFoA30KJU/kyNxA== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 41515744-e6f2-4e5a-2257-08df347a229d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2026 22:32:08.0955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5280104a-472d-4538-9ccf-1e1d0efe8b1b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Y+lk4TlVv8tIGeSR1RaAVShJTDin17A4/uJHD9WAZsUWhnRpaRpbyt71G3AZH9jD X-MS-Exchange-Transport-CrossTenantHeadersStamped: BE3P281MB6226 X-OriginatorOrg: amazon.de X-purgate-ID: tlsNG-ef75cf/1793140337-A7ED6AE4-46713463/9/66687 X-purgate-type: clean X-purgate-size: 378 DQpPbiAyNy4xMC4yNiAxOToxNCwgRGFuaWVsIFAuIEJlcnJhbmfDqSB3cm90ZToNCj4gVGhlICdu aXRybycgYWNjZWxlcmF0b3IgaXMgdXNlZCB3aXRoIGEgcmVhbCBBV1MgZGVwbG95bWVudCBhbmQN Cj4gdGh1cyBpcyBjb25zaWRlcmVkIHRvIGJlIHNlY3VyZS4NCj4NCj4gU2lnbmVkLW9mZi1ieTog RGFuaWVsIFAuIEJlcnJhbmfDqSA8YmVycmFuZ2VAcmVkaGF0LmNvbT4NCg0KDQpSZXZpZXdlZC1i eTogQWxleGFuZGVyIEdyYWYgPGdyYWZAYW1hem9uLmNvbT4NCg0KDQpBbGV4DQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:32:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:32:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462683.1673866 (Exim 4.92) (envelope-from ) id 1xLy9T-0000li-GG; Wed, 28 Oct 2026 07:32:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462683.1673866; Wed, 28 Oct 2026 07:32: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 1xLy9T-0000kr-Az; Wed, 28 Oct 2026 07:32:51 +0000 Received: by outflank-mailman (input) for mailman id 1462683; Tue, 27 Oct 2026 22:33:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLpj6-0000JX-Tg for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 22:33:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLpj6-0096cf-39 for xen-devel@lists.xenproject.org; Tue, 27 Oct 2026 23:33:04 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae12693-8faa-0a2a0a5109dd-0a2a4505e70e-22 for ; Tue, 27 Oct 2026 23:33:04 +0100 Received: from [52.57.120.243] (helo=fra-out-012.esa.eu-central-1.outbound.mail-perimeter.amazon.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1269f-4cb1-0a2a45050019-343978f3bf91-3 for ; Tue, 27 Oct 2026 23:33:04 +0100 Received: from ip-10-6-6-97.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.6.97]) by internal-fra-out-012.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2026 22:32:57 +0000 Received: from EX19MTAEUA001.ant.amazon.com [54.240.197.233:12547] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.44.90:2525] with esmtp (Farcaster) id 09484581-dfa9-4b4c-a117-a67a540b1263; Tue, 27 Oct 2026 22:32:56 +0000 (UTC) Received: from EX19EXOEUC001.ant.amazon.com (10.252.51.133) by EX19MTAEUA001.ant.amazon.com (10.252.50.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.56; Tue, 27 Oct 2026 22:32:56 +0000 Received: from EX19EXOEUC001.ant.amazon.com (10.252.51.133) by EX19EXOEUC001.ant.amazon.com (10.252.51.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.56; Tue, 27 Oct 2026 22:32:56 +0000 Received: from BEUP281CU002.outbound.protection.outlook.com (10.252.51.199) by EX19EXOEUC001.ant.amazon.com (10.252.51.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.56 via Frontend Transport; Tue, 27 Oct 2026 22:32:55 +0000 Received: from FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:20d::13) by BE3P281MB6226.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:104::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Tue, 27 Oct 2026 22:32:46 +0000 Received: from FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM ([fe80::7b1c:7a5d:c405:6c4d]) by FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM ([fe80::7b1c:7a5d:c405:6c4d%5]) with mapi id 15.21.0546.021; Tue, 27 Oct 2026 22:32: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=amazoncorp2 header.d=amazon.de header.i="@amazon.de" header.h="From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:Content-Transfer-Encoding:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazoncorp2; t=1793140384; x=1824676384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GWEbN3/mwk69KDD6DP1aJIFo59Q4n3h4QilYTdK6KJ8=; b=pdA+yjEVu6CSgBC0MEfAKTQBsK3mXbYKLQMBQRsOfTpJv/rLMuwq9jbN nDPfy/EdICXBN8oeoExICotu8iwnuODACTwqw884xMotZoAvww2tYjVKw tZ3klU5JrN4cSMwLhrq+HSZwpeXtHIv7s7Fbnoxvjz1D1WySbWcXAHinA suBcdyBTSYQR/4i/h6weFizQN4KHatZGehJXWCz07iTb+q1npo6ePk+Wz 28i1QEoNQKh7S1OyE6w6EPI+/hkU+GN9tdDYgOw45A4KP/r9eWf3w4HP9 CgsZ32cb+NxLQ+qkw2vmA2vYVSUDKXYVEUxxSKKMNrDqviA5UoumKQ7fQ g==; X-CSE-ConnectionGUID: EB+pMZTETUW8U34DPIYAZQ== X-CSE-MsgGUID: P4uhTOAcSjGDhFl9mhH+Ng== X-IronPort-AV: E=Sophos;i="6.27,181,1787011200"; d="scan'208";a="21795587" X-Farcaster-Flow-ID: 09484581-dfa9-4b4c-a117-a67a540b1263 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FjW0TusRwVgpu/dt/5IeXj1IYuJqqkyM+NuJ8Acc+tpKNHCSXiWFLcabDdPnjHXU9C7oKu+rmji1Dmai3xmKZsvFmsMNcVWEUQe0LK1wTFZqktid1R0sG8S2zL7k+oiBqLbNy+vurkw0cb7ehn/WjlXuEkvb+77YJy7TmslRDdXZOot0zI/mkfXOBLcOJBJcG/vmolw2flzx3y/kQFZFhGYhvgzpXyRc6J+hWyPsm82cz2uvC/wKTpz1Y6NhdJtCK0UUfn1NNk8xIXCabAWlPBcV044MeW0YTFEC12390pGl/FbAazy50YswNWliKVxscevCWLpz7flwULH5XpKfSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GWEbN3/mwk69KDD6DP1aJIFo59Q4n3h4QilYTdK6KJ8=; b=xekt8P6ucGj2j4PfYBIY5ywxLYRvjymEb3eBlKJEreaOjSU+ww7R5ftFoxO0CC1t+wIFH6ZCsvvs7im9J4THPHjGGBs1umuslA9EYGrc+Gjq4YM5eyNiI258/YkHx7tEWW9Tdtk1u5bkX5gjQad4FD21Vk3CBTEtpV9+I1DFEHNVc0xD2BCWLs3n/efzYnt7BualwNeG3ZP2rx65w2iys/iqvoXVWGXrTD7Yp76Aas2QcOhmfJPpurhV1RZJMY5smCU/Zh3i/fjd/mJmUSGjeu8vhfefGnTC9B7wp5lUnY/HN4XvtfaUTBnkR2g7QBMGOPEsMkfwsI94RGAFw6hKZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amazon.de; dmarc=pass action=none header.from=amazon.de; dkim=pass header.d=amazon.de; arc=none From: "Graf (AWS), Alexander" To: =?utf-8?B?RGFuaWVsIFAuIEJlcnJhbmfDqQ==?= , "qemu-devel@nongnu.org" CC: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , "qemu-riscv@nongnu.org" , Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , "xen-devel@lists.xenproject.org" , "Sergio Lopez" , "qemu-arm@nongnu.org" , "qemu-ppc@nongnu.org" , Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , "qemu-s390x@nongnu.org" , "kvm@vger.kernel.org" , Song Gao <17746591750@163.com>, Eric Farman , Cornelia Huck , Matthew Rosato Subject: Re: [PATCH 08/11] hw/nitro: mark 'nitro' machine as secure Thread-Topic: [PATCH 08/11] hw/nitro: mark 'nitro' machine as secure Thread-Index: AQHdZmMX3joabFtXaUWVQ1RiPsBvJw== Date: Tue, 27 Oct 2026 22:32:46 +0000 Message-ID: References: <20261027181400.1752951-1-berrange@redhat.com> <20261027181400.1752951-9-berrange@redhat.com> In-Reply-To: <20261027181400.1752951-9-berrange@redhat.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=amazon.de; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: FRVP281MB744463:EE_|BE3P281MB6226:EE_ x-ms-office365-filtering-correlation-id: 18fac4b7-fdbf-4656-7e07-08df347a39be x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|23010399003|1800799024|38070700021|11063799006|4143699003|56012099006|10067099003|18002099003|22082099003; x-microsoft-antispam-message-info: cyC+3f1YHm6wUu9JacJXPts7iepG6XLMm2+IHmQTOXCcxWFNMrsfdGc7fSLrEFGkhiw2kmpW8Pd7nfSuJljKT1XsbfvEbqfSpWGp45UFfVym6fg9UQyjF0S3v6VGhegdPMuTe1g7Ij4hfS33F7+9jXqptbq5U5T2oaUDrSsvydT4ztFEjNZp9ft2bCNUkh8crKcfiWiPVOn0lTkzvWdsFjv29NLndxrvG0fuEpIGEahTbKFfdulhFOUyvF7I6/aUUuqMvbzLv/nOkhIiScvZPajy+75HmaGE/qJQHrLtA/7GuHKZ8XjC2zRmDjlobE0yiQ82t/MZfPZdSUQsu9sOiJ2qgykfuJITJm/R7QtoFcaiDPdYg4FHcFHNGKviJHPoe6YLdECpZyfBQzcliTmAnQcu4stAPfIs1PPUJd43yTjH4hYt6hugIn3Q8TPghu7CYKA7z4Ke1tf6GnCu5IEbHCAuELO4NunYt6Eou3qLVIuiFiyl5hYwc8eQew15A7rMCq6K+lGhyieDrAQ7lYzDkuhCCjOXL6Fv58PnjYZjcj8IXvFs5iu5fg/VqVnGmFIUV3Y3i9H4D3A4Sfl11isjksscHslU2+fwqrHGcV9uKKTor2bIuzSdnAXCn5BqUG8cbpXF+cOIncTwO0jwlcrEqxL+dpLVuzusX7TuUVkzrHZINkbKGaeYKukYH9MwiNDBqP87oH0jml4IiOFCMrvRWbvIpuS+kqo1ZxsBCDeGNyw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(23010399003)(1800799024)(38070700021)(11063799006)(4143699003)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?emFQd0puMmo1aFJKaCtxdmp4Sjg1QkdJZy8xL1FSMlcxaUw1bHZyb2NQWjB1?= =?utf-8?B?V0lUR2tqdnIxcW1MK3FrOSt3RUNhMUJyTlU2QVl1VTBmay80Rkk3Q2dKaG9t?= =?utf-8?B?ZHd5eFQ3My9kNE00MmRmbWI3MzZ1TFhxcjFEa3JqaE53ZDZLaGdsZVJaMkZN?= =?utf-8?B?QmZNaS9XSktBV3dMT1FQYlpqd1R4MERNMmtmZUJjT2g1Yy9nNFord1VRYnFp?= =?utf-8?B?RGNTb0xtRG9PaEdtRWZReElwdXlNNnhwNnNDRjREVHRnMlJFZCtwSWdJZGFW?= =?utf-8?B?UjVwRWhlZ3UrOUppTjZQRWROeFAyUldQemtheS9zeDhHU1h2US8rS0d2aDN4?= =?utf-8?B?bWJacEVzVjRuMXRFaU13VnFRZFZpT1ZMbUhMbzgvUms3TzVJQjRHVXd3ckY5?= =?utf-8?B?Z0RUSnVOV0dQUmlyN2hVUjg5RG1wYjdWaExKa2tHSGQwWVZnM1hUenljbEhI?= =?utf-8?B?WGZtYUNmd0hQd3JwMjI3NmlpakxxMm15S3U2eFRCUEFqL2M0dDEwWGdsU01a?= =?utf-8?B?UHk4MFJkcGVIalA1UVk4NUdUM2lxTXpIQTQ4TElaUEdtK3k5clVMWjBNQjVv?= =?utf-8?B?QTQ3SFhVaVMzbU9rT001NGVnTSs5RWtNNmdDK25YRldVQ0tKVVZrUDFwdFZ2?= =?utf-8?B?STNiQ1dFZzdGQXg1S0NKNnR5RGZvVG44QjFINyt1UGxjUThhZFppOGxxT29m?= =?utf-8?B?ZENHQWM5UllMK05tUENkVVpUWTJVZVBGdlhYYVRwQURMYmFudzRMS2V0bUVS?= =?utf-8?B?aHh5N2NOOEkvQkZiZjlWbkRLVjhMY0dudlIrSi9wR3UvYXFueHpObXpDa01j?= =?utf-8?B?L3J2dlVtZFQ1UThHSEo4bjc2VWZTUDcyblo4NStaclpwNVR2WlkyTzA3RGo3?= =?utf-8?B?MjkvTmdpSmRsS2pKVHVvNld5OGZBbTUzbnhZcHV3bk1ZelUxY0VLaVlmWVR3?= =?utf-8?B?WTFyTVR1MkJOTkNqZjRzZUhzUTFuNDdNU1hXWUZYR282a0hnV1B4alU1U3JS?= =?utf-8?B?OUVCcFhwSU9jWFhKTitoUXllQ1lDYnA4WnZQV3BaVTRUQW0wZVhGRjMxNmx3?= =?utf-8?B?TzJZQmZzbmtGSzJ4NFZDRXdmKzUzcERtanpodHBubFhZcXhsd2R2U1MxMjYy?= =?utf-8?B?eXRuN0VMc1F2TmdGT3hmc2tzZEJIbkxKNS9GdGJtSXppQVV3WU90cGVQRUNC?= =?utf-8?B?TUhxT2ZNQjA3NzR1TXJwNldCVzJrRTZxRjhxNWlVbThZKzdicTg0alFNeGhY?= =?utf-8?B?QllYcjhWQkdFa2RwT2xIZ1dJMk02VVVlNG5IK0N4QlQ0YUZpQ0ZlOGFsbTBN?= =?utf-8?B?cTJQLzhOemp2TmdFeVpSK1dBZFlLUStKWVA0YnVYdmpCYVo2TjN1T05rUTVk?= =?utf-8?B?czZvUlRMZmFFNm9wK3ZEVTBhU2F5SWVFbGJSL01WUGtTK2JpRy9QbUtDdUpz?= =?utf-8?B?WGttd1dzRjk2WGhEZ3NyZXpVbFhoOVJ2bXBZN3N6MXZwczF5QkIxMHlwZW5N?= =?utf-8?B?SXpUcDJZR054NUVlbE5HQVRwSFVqSGw5TFdzclk2azRkYlZ4VW1teVk3MGRu?= =?utf-8?B?NWo1MFU3SDAzMHA1WEdNeEl5d2VKOWJzZW8wUmRtTE44bVVTYUd6UlRJbU9n?= =?utf-8?B?U01TRXZMUndZVHU4dElTUUhoZG1KQWxBOXI4TC8zYkwrRmdIUFJTMi9VODhZ?= =?utf-8?B?NWN4MkJ5VXNKY1VzSTVCOWU3dEVSRHZiK0o1TDhXVVVrMDRkS2xjM1FZVTQr?= =?utf-8?B?K3p2a3RZSzFKTTdTQUlkd1lUazVqYzAxN1JvbEI0WWJFK3o4UW9wZzR0Z21i?= =?utf-8?B?YUpzeVZIMml6YWh2NjRGOVp1QllYNFFnOFBNUEQ4V0Rtc2kyQ2VSUGZiZjZG?= =?utf-8?B?VERoUjlOM0RLRHdjWUhWU1hmZkpOQkxRK0Mva2dwUzdXOTlIZWRPS29CdDRT?= =?utf-8?B?RHRHOE5mTFl5V3I4T2lpYk9SMGRrNnU2RDdMUU1YL2l1MndrQTdIMFNpR3N0?= =?utf-8?B?OW5KbFFDam9QbllndzJaWVhCVGwrZEtUQ0VjTUd5dUkzNExRNDZIMzgxeWhE?= =?utf-8?B?Tjd2U0RCaFRxUFRxOFBiWnF1WklNaTNPK29WQlJGOHdPUEdRQU1WcElpaUl0?= =?utf-8?B?WjA4MGwvR2xVd25QOFBxRlgwbFpLN21uTnBURGdETGRTQWExa3N2Y3NRWVZ5?= =?utf-8?B?Q21KOVdySGlRaThzeFpUQ0swOUxTWWpxK0ZCcUpiV1hEdlhPZzZMOE1uN2cy?= =?utf-8?B?WS9UdE5UTGFVU0tYRzFMaDByazlaRC9qREtQU0tKMUZCU3ZjRUQrY2EzRTd6?= =?utf-8?Q?/6lkPpd4HClXTVIakb?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: NBDV8OtVjbURIZoZ+dl98PYqYeRz1lRrtKBzL5beaGAPyDsJluvOcBDPVB0kK/YMAN3e1KAxp8RayZuGGNacM+D9mabe8M1EBLsbWCWEBCPLkTRgU+RVjA90iT1I7M3KFxJBB8nRQqrayLrsdYrC6RYtlhrnKjAmaOKKf3qV957Qy+sH4KipLsMLtxTgqpMsnt/67mFbiWVDR6lfHCcTHbQewN/XSN4S1DN1rpGohxWN5S/uXv/Vu1EZ4pde1hJaEDCQiWGERNPF+7e7X4rNucFFYEnE+SR26l7D5J/F5L0ov1O6ybolDTkkH/rkkxR2nuGO26Eqv+L41IxXWdzhHA== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FRVP281MB744463.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 18fac4b7-fdbf-4656-7e07-08df347a39be X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2026 22:32:46.8788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5280104a-472d-4538-9ccf-1e1d0efe8b1b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a6Re2qSIFeVXf8vTz5LrzKCNGp/bvqL5QF4oEG2KmYKwrlJ5jIA2qbjZ43RYxsBM X-MS-Exchange-Transport-CrossTenantHeadersStamped: BE3P281MB6226 X-OriginatorOrg: amazon.de X-purgate-ID: tlsNG-c201ff/1793140384-73CB82A1-2CAFAB79/9/66687 X-purgate-type: clean X-purgate-size: 460 DQpPbiAyNy4xMC4yNiAxOToxMywgRGFuaWVsIFAuIEJlcnJhbmfDqSB3cm90ZToNCj4gVW5saWtl IHRoZSAnbml0cm8tZW5jbGF2ZScgbWFjaGluZSB3aGljaCBwcm92aWRlcyBlbXVsYXRpb24sIHRo ZQ0KPiAnbml0cm8nIG1hY2hpbmUgaXMgdXNlZCB3aXRoIGEgcmVhbCBBV1MgZGVwbG95bWVudCBh bmQgdGh1cyBpcw0KPiBjb25zaWRlcmVkIHRvIGJlIHNlY3VyZS4NCj4NCj4gU2lnbmVkLW9mZi1i eTogRGFuaWVsIFAuIEJlcnJhbmfDqSA8YmVycmFuZ2VAcmVkaGF0LmNvbT4NCg0KDQpSZXZpZXdl ZC1ieTogQWxleGFuZGVyIEdyYWYgPGdyYWZAYW1hem9uLmNvbT4NCg0KDQpBbGV4DQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:32:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:32:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462864.1673873 (Exim 4.92) (envelope-from ) id 1xLy9T-0000rI-So; Wed, 28 Oct 2026 07:32:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462864.1673873; Wed, 28 Oct 2026 07:32: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 1xLy9T-0000py-Jy; Wed, 28 Oct 2026 07:32:51 +0000 Received: by outflank-mailman (input) for mailman id 1462864; Wed, 28 Oct 2026 07:14:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLxrP-0005DK-3U for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 07:14:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLxrO-005ruj-FA for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:14:10 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1a0bc-bab6-0a2a0a5309dd-0a2a450ac4ec-4 for ; Wed, 28 Oct 2026 08:14:06 +0100 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1a0bd-f2d2-0a2a450a0019-aa0a857c8067-3 for ; Wed, 28 Oct 2026 08:14:06 +0100 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-544-aPtTQLUAOnmRkcQac9q43w-1; Wed, 28 Oct 2026 03:14:01 -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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9EEAC1955EA3; Wed, 28 Oct 2026 07:13:51 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.2]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 11B5A1800257; Wed, 28 Oct 2026 07:13:47 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 8C76D21E6A04; Wed, 28 Oct 2026 08:13:44 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-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=1793171645; 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=QxmQ5AxN89rC1HiyefFy0FHMMxtlG6Y/Map2WM9XKmw=; b=R7dNBPEkd2oyQP26Gg7hxNvKw+9UNEGQetKJVP7iMmIaJ3OaqWXqspoeCxdRwREJ64TpHG qHITOlS0YMyTQtv/nlXpDZc/A0NTqvKNU81hQBos6n1P0rqqUZcAammeW+ir9DqNjrRIn8 6/siRGU4XCf2PsP6fTNURV6gTJgCDS0= X-MC-Unique: aPtTQLUAOnmRkcQac9q43w-1 X-Mimecast-MFC-AGG-ID: aPtTQLUAOnmRkcQac9q43w_1793171635 From: Markus Armbruster To: Daniel P. =?utf-8?Q?Berrang=C3=A9?= Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type In-Reply-To: ("Daniel P. =?utf-8?Q?Berrang?= =?utf-8?Q?=C3=A9=22's?= message of "Tue, 27 Oct 2026 15:08:58 +0000") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> <87zevz5h4k.fsf@pond.sub.org> Date: Wed, 28 Oct 2026 08:13:44 +0100 Message-ID: <87o6ce47rr.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: yg0OuaHLVpWCLhBPKH6aP_VmVWCwNbVKeSHwMDYwPrE_1793171635 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1793171646-5A7DACFC-DCB50FCD/0/0 X-purgate-type: clean X-purgate-size: 3650 Daniel P. Berrang=C3=A9 writes: > On Tue, Oct 27, 2026 at 03:54:03PM +0100, Markus Armbruster wrote: >> Marc-Andr=C3=A9 Lureau writes: >>=20 >> > Hi >> > >> > On Fri, Oct 23, 2026 at 2:04=E2=80=AFPM Daniel P. Berrang=C3=A9 wrote: >> >> >> >> On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-Andr=C3=A9 Lureau wrot= e: >> >> > PciDevfn is a bit special, since it accepts integer and string as >> >> > setter, but only output integer as getter. > > snip > >> > But I agree we >> > could do better. >> > >> > There are multiple options. We could keep declaring the property as >> > str instead. In this case, the getter should probably return a string >> > for consistency and correctness. This might surprise some existing >> > users though. >>=20 >> I.e. ditch numeric suppport for numeric addresses, right? >>=20 >> Incompatible change. Do we care? >>=20 >> If we don't, we should be honest about it and mark qom-get unstable. >>=20 >> > We could introduce new properties like `devfn-str` and `devfn-int` >> > that alias the same value. >>=20 >> Compatibility break. If breaking compatibility is okay, I'd rather use >> the opportunity to get rid of cleverness, and go with your first option. >>=20 >> > We could also introduce a new structured QAPI type. >>=20 >> What kind of type do you have in mind? > > IMHO the root cause design flaw here was to overload 'addr' as a > way to set both the slot number and function number, as using > one property for two pieces of data is a well known anti-pattern > we caution against. > > IOW, we should have had 'slot' and 'function' as separate properties > from the start. Fair. Our modeling of PCI is old and weird. What we call "pci-device" isn't a device, it's a function, where function 0 sort of stands in for the device. Its "addr" isn't a PCI address, it's the address of the function on its PCI bus, i.e. the tail of a PCI address. > From a CLI POV, we could easily change 'addr' to mean only the slot > number, since it is always parsed in string format without the > magic (slot << 4) | function encoding. Then add a 'function' prop In CLI, HMP and QMP string (not integer), value "5" is shorthand for "5.0", and means device 5, function 0. We could deprecate the .FN part in favor of a new property "function". Once we drop support for .FN from "addr", its name becomes even more misleading than it always was. > The challenge is the impact on QMP with strict typing, as ideally > int format would soley represent the slot number, but today the > int format is encoded (slot << 4) | function. So anyone relying > on int format in QMP would silently have a semantic change if we > altered what 'addr' means.=20 That's a no-go. > Deprecating 'addr' entirely and adding brand new 'slot' and > 'function' properties would be a significant disruption to > a syntax which has been documented for years (decades). What about this: * No change to PCIDevice member @devfn: encodes slot and function as an integer. * New "pci-device" properties "slot" and "function". "slot" sets just the slot bits of @devfn, and "function" sets just the function bits. Both default to zero, so specifying just "slot" gives you PCI_DEVFN(slot, 0), which makes sense. * Deprecate "pci-device" property "addr" for QMP. We can keep it around for longer than the required grace period if that helps. * Declare it legacy for CLI and HMP, with no intent to remove it. From xen-devel-bounces@lists.xenproject.org Wed Oct 28 07:42:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 07:42:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462905.1673896 (Exim 4.92) (envelope-from ) id 1xLyIl-0003kD-SP; Wed, 28 Oct 2026 07:42:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462905.1673896; Wed, 28 Oct 2026 07:42: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 1xLyIl-0003k6-Pm; Wed, 28 Oct 2026 07:42:27 +0000 Received: by outflank-mailman (input) for mailman id 1462905; Wed, 28 Oct 2026 07:42:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLyIk-0003k0-BG for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 07:42:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLyIj-00BTTw-9H for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:42:25 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1a75a-8faa-0a2a0a5109dd-0a2a450a98d2-20 for ; Wed, 28 Oct 2026 08:42:25 +0100 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1a760-f2d2-0a2a450a0019-d1558031f088-3 for ; Wed, 28 Oct 2026 08:42:25 +0100 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a35d5d4a20so6599965e9.2 for ; Wed, 28 Oct 2026 00:42: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-4a94f05f168sm19545015e9.4.2026.10.28.00.42.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 00: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=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=1793173344; x=1793778144; 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=huVGI+W8+BLSycLdp3E+/uCIzL8hvWrKPFeZuCWM91M=; b=No1NM6h5Dq3azIp1eVrgW/KzEN/p53T8LV4MORg14sgOErnNAJO15Oz2UvyfUx1fLv j10sddJHp5ljurHAm5slEh99m0mM/SqDMXgTg+YvGZQAVSrPsIPhOMLdUlyqsRtokAT3 rQMl8LFcU4AzOGZ9sbG2AW7Qs2Kc4ZyeLGeeawiWg8Dfr9Xp01/H3us05Y5yFuKBpVxk CfW4D/qnUlkZcUz4U6KO6EINxrAUS6Lzjf9Gflh162FsAC3BpORXsjmn7HLAshcJPFv+ ADhEFseH+Z9rWWWgMtxcgKZFwEzNYpnvcO7RnTqfwex1T7plCdwMQzJIH8pBWjupUxeU +6Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793173344; x=1793778144; 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=huVGI+W8+BLSycLdp3E+/uCIzL8hvWrKPFeZuCWM91M=; b=hD1lEOAXjpG85a90P6mWB7DpzaAs76NccoT+RxEZkwDZbFlKGYLZ3gHHLRmw0KFKfe n8BL5M3i5Zo1cNbl+Jx1Mp7eGWjtywOv3JApqrNwlqbKYoM/NF7ynO+bDd9/BmjjrfmA Qmgf5trwdg7C3OiSMxpXoTTxEYh19DadeYtlG6bN/NAqNwj1arBuTYXWv7WbtHs6yUSI B/WLDlAA+JHI7B6aPCEFN2+julo52UCBtsIhEf6EgFmwYQExz5HQEqUGcBYdCB80nTjM p+yfDxU3avJ36cOTIyQlXni1Glo/n5jr0YMoX/+Txop8fmF+uiV6rBazLI09bpK5+NYM zPCQ== X-Forwarded-Encrypted: i=1; AKwUvBwmp/trbAcRYi5k88aT+HbJLc013gWySCRxjJtw42uc2maf/t/YTh/lRqC39aMLX7E33YPBsCjE8YI=@lists.xenproject.org X-Gm-Message-State: AFq9FYLtfQ5JjPPqdWanyqZBJfGXaz7aBPtwHqxYRGbojX4pOLKn0iW9 pX91CT8tROwrnrzj6VzuCyhMp8TXh5QIN4+ske7sKw0PPyY9p6D5ms+Qs+dW2jqI6w== X-Gm-Gg: AYBFou2ntwBVu5ChpYtEHaXbwWLYYvnC8dyhhMqXnkoXiPGjikZNbYV0aWEgcOwxUX2 6YuEArefNmwl6u3SIcB5US4NNXl3VBCEewbPbw/2niInE1yEvffri8OcWn9iqj/9UGbp6ctxx5L q+/uEaijtaxaTOXKWEAQyXGzZjNYCvXB7cVhHa6F5IuRsVL7SQ/2LkOfxUsdcAdNs6DxTC5HRVm i9YQmp6bk5jL5g3qUyiKKQmlUuKblz0zPHt7iaZCYu1VG5Oq5iRSuSAAed+tGV7OBiuNhVwCtfX 6rMQbr6Wk+UIttlDg0M07nm/tIcKQa8ASjp4evdzHq/JOQ1vazbFcULQl3xWuNAR/GhI1Gf+d4z Sd6r2zf13PVA34ar+uc282mMgYXYYFsS7qF2IcvDgZDJgg1oOVTTkgkj77O55HvVX7Qr7DAouv/ MwptBmOgR1n+2yiPIvQQZuTt0YTzsCm9E03zThR4e3RgwWTJII0ql9IH7xqi0Bq+P19IlAybDzM dN/cTn1Q5P549eHgaXH9H3TY5cZ2GK4bla6vAFlIG5WtEx5mdY01vN9tmruC3lzrqzZcvpGdVK7 X+b5TPbAe6GEd/gk84Z5nHtkj3n+i/0IMBg8UYo9klMf81V/9M+iU7STwBug1DATuRLwfa1HVBu +a5oQN5DeGOkzMU3TOg== X-Received: by 2002:a05:600c:6089:b0:49f:e772:6ddf with SMTP id 5b1f17b1804b1-4a967ca24ecmr27060255e9.32.1793173344477; Wed, 28 Oct 2026 00:42:24 -0700 (PDT) Message-ID: <0af0a00b-4f9a-4584-ac5b-554ae00e692e@suse.com> Date: Wed, 28 Oct 2026 08:42:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/typesafe: don't brace-initialize a scalar TYPE_SAFE value To: Shuaidong Chen Cc: Nicola Vetrini , Stefano Stabellini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org References: <20261028050336.2549325-1-shuaidong.chen@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: <20261028050336.2549325-1-shuaidong.chen@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793173345-4B8D5CFC-CD2DBD63/10/78276251493 X-purgate-type: spam X-purgate-size: 2328 On 28.10.2026 06:03, Shuaidong Chen wrote: > TYPE_SAFE() degrades to a plain typedef in non-debug builds (NDEBUG), so > mfn_t is then `unsigned long' rather than a one-member struct. > INVALID_MFN_INITIALIZER and INVALID_GFN_INITIALIZER, however, always > expand to `{ ... }', which leaves > > mfn_t first_valid_mfn = { ~0UL }; > > initializing a scalar from a braced list. That is valid C, but MISRA > C:2012 Rule 9.2 (required) - "The initializer for an aggregate or union > shall be enclosed in braces" - is reported against it, twice in the > x86_64 build: common/page_alloc.c and arch/x86/efi/runtime.h. Wait - the rule says the opposite; it says nothing about initializers of scalars. The rule is clean in all analysis jobs we do. On staging we only ever have debug builds analyzed, but on release branches *-allcode have DEBUG=n. No 9.2 violation shows up there. You also don't point at Eclair output supporting your claim, so I wonder what is going on here. Further, "That is valid C" contradicts ... > --- a/xen/include/xen/typesafe.h > +++ b/xen/include/xen/typesafe.h > @@ -9,12 +9,17 @@ > * * _$FOO() which boxes a $TYPE as a $FOO_t > * * $FOO_x() which unboxes a $FOO_t to $TYPE > * > + * TYPE_SAFE_INIT($VAL) spells a constant initializer for a $FOO_t, for use > + * where _$FOO() cannot be (an object of static storage duration). > + * > * This makes a $FOO_t and a $BAR_t incompatible even when the box the same > * $TYPE. > * > * It does have some performance cost because the types now have a different > * storage attribute, so type safety is only enforced in a debug build. > - * Non-debug builds degrade to a simple typedef and noops for the functions. > + * Non-debug builds degrade to a simple typedef and noops for the functions, > + * and with it TYPE_SAFE_INIT() loses its braces: a scalar must not be > + * brace-initialized. > */ ... the new wording used here. Also, in the earlier insertion above, isn't there "used" missing? Possibly, to avoid the double use of "use", with the earlier "use" replaced by "cases"? Yet maybe this is legal grammar anyway, and it merely feels odd to me as a non- native speaker. A native speaker may want consulting. I also wonder why you CC-ed Roger with his old Citrix address. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 08:09:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 08:09:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462923.1673906 (Exim 4.92) (envelope-from ) id 1xLyiQ-0007wd-84; Wed, 28 Oct 2026 08:08:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462923.1673906; Wed, 28 Oct 2026 08:08: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 1xLyiQ-0007wW-45; Wed, 28 Oct 2026 08:08:58 +0000 Received: by outflank-mailman (input) for mailman id 1462923; Wed, 28 Oct 2026 08:08:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLyiN-0007wQ-V6 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:08:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLyiN-006gCW-4Q for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:08:55 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1ad8b-e002-0a2a0a5209dd-0a2a4505a6da-44 for ; Wed, 28 Oct 2026 09:08:54 +0100 Received: from [40.107.74.89] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1ad93-4cb1-0a2a45050019-286b4a591b72-3 for ; Wed, 28 Oct 2026 09:08:54 +0100 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TYRP286MB4478.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:1af::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 08:08:49 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.021; Wed, 28 Oct 2026 08:08: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=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=rM5KAO9ItCLUv+3aXhisy5vH4yizfFuFbrm+021OU/gQBtvm34jy/Yl73DuGUBHT1UVaJvgj2hYeU9NMOTnOYXHHapVqVCtz0VLrbn/Cojdz8Z3T4aEjEw1eFE6zXZBhqqePy5Jhl83sjQ5qf3WfcvWuoaRzU774FLhHdbpEOUNfkAtA8USznZkhLfKqnMss3v/6k3hfbu3PHcJhaIGACmxE5ndzV3IJtYITEyD9oDYAm01D2j+Z+lquh14U19lXPhBWUoTsHb50us/SNy2z4+5R20HNid+/blF2VYUloT0x1dCfWchHob6cYtgRx8tzl4/OO91w3xBpIXvxRmZr4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2B03yrV6ETCBmypYMvpS66Ut+q9oewu4GOSrgKwVmCE=; b=FvOFXujH9rQovB3gV6jAcbEAVoUEyiw6WVyDR3nxwsFWkee5fM+Jk9kmDDRQVMhYY5KywLKayVumMqWjdkfiZC8thT12Ljd9hiudmWA4We+ye2vaMo9OaHeSh/LB5ryM/30HN9P3JLSU7QV6jcyz+R7HSw7W6qNrNY6G7+LNM3wdGbpyF09n7qcmg8t/tjsYDdsfmQSzpTIjs5tXIUMu03JOWHpfF2jRdA2FfXckyZ5N+dgKylQUrE+yVTTJipGZesU/nG9U83OocyXhaXA6lkMVkRjBhdE4K7cPwGFro6Lp2KTzJY2e0GzDgW7X3XVLRheBLgjIxFSFk3rC+aG0hg== 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=2B03yrV6ETCBmypYMvpS66Ut+q9oewu4GOSrgKwVmCE=; b=R6iWrHByzxRyG72iv++2QqYsRdofSkSkI4r/Vo0DDHcZLRXcdm1GKKKPZ0SltYkOE6HE6AMPyfB9wTb0UcOUf8P+f/8kzB83r5ThK2WV4ne+3Z0o/IM4w0a+wB7B1PCt7srY6/aQVwWMszRfgdkauWxkhQU+k6xAH6Ar92KKZPY= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: andrew.cooper3@citrix.com Cc: xen-devel@lists.xenproject.org Subject: Re: [RFC 0/5] Introduce dynamic tracer using Livepatch Date: Wed, 28 Oct 2026 17:08:41 +0900 Message-Id: <20261028080841.118926-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYWP286CA0031.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:262::19) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TYRP286MB4478:EE_ X-MS-Office365-Filtering-Correlation-Id: d70da82a-bd98-4e84-f1c7-08df34cab28c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|261026140227099003|56012099006|261026121527099003|261021121427099003|261022075727099003|261009223027099003|261022105027099003|10067099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: iGjh8y38TKrQ1v0KnDWwkahJ2K0Onx6v69iT6uDLxqs39YO9Dc74WNSoL6k07GI2D5VK9tY8YJH4zV+NDJCX6Jtq+e40VAPRTax8f1EigQ2l7pOb3I69//qYnL0KIrBEso049thM3zBkSAKqeG02PR33b0iy66c/JY3VB2gcO7JzppAjBznMDZWxA7JJiCaGDeT8srWqDZGcHC4IDgJnPCCv+jvMxsWWUdrADLjSs9AF9UYAxcgv5VEl6PcsgEtK5evalESzKvkFQG1KFSEAykZ8M+A3zWIsdJUl1aFlW8uATvWQ1FZJPL1ENGAEtqLU8FSBjiC9YRGd7qd6eG5IbuZ1QQZaYXTTWGXrkHP3dfuTHTjT2fARJuqx7QHX+OFbjl/TSKGNm5J4ysWPZziK+viyCq0J+0iJ0rn5TPezEJzSScmZHjG8XmJ0rev53M14jjo5v9rofH4XqK6UZ8mIM8kZsvQ/ynTBbTWNbsKeaTRdGBsn8EM5LhVqZfW40d9Ph9cxNuNN4FBhFMpGR9j41KUmiDEW8sm4AserlVssreaKRsVxW2rCvBnCeT+otCPYUNtallqh8DditCqLpsQPpFh57RxOB1PCPDFEhm4vot8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(261026140227099003)(56012099006)(261026121527099003)(261021121427099003)(261022075727099003)(261009223027099003)(261022105027099003)(10067099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?37sz03XI5tyNLptVTjFYYw3la3T8k2ioNn3g6U/5vTxgvM+75XNNQ7ND0yLP?= =?us-ascii?Q?7GopmEESwPdLTwe00Lpi3qPPJFct3bSdOnrKyZpmyNKf9ZNFnVc1CNdutmVo?= =?us-ascii?Q?Ssg8VOBeM80nWbZq2KAIIqtefBHj+lLe/tcUnQh4mCVMroR/f1weORE+mOe8?= =?us-ascii?Q?GuxrxgWtEguAcCOwzwqpuV6qTXS8A/26u96hEyDc41Ax6JCcNF+/M+kmO6HN?= =?us-ascii?Q?Sy72wIJ0P/4iWUeQ9KC4i91M8WSaNVo/aQnN+V/0+0AU1TmVNLRwval6W0SI?= =?us-ascii?Q?2iDTl/WcEEf1MGX5GjOB4KWorK2s8WAv4ujwQZViruf3kcVO3q3NOY4Vx7IY?= =?us-ascii?Q?wscbgl017vIEgJ982C5eLAR7PH4StfyD3c0ax770pyBLPNzMt4DDpVdhjuwt?= =?us-ascii?Q?868h0iKehT0wlLzIwfnLfvtg+W2fgZ8M7Bk97fd8n4p2HnfJfAhO4Vvcl+Eb?= =?us-ascii?Q?WvGIvtpzoLcjQiuk8kY7eAV2Hg8MvZZyJ/EmkoYD+ltXTmY/pOc9mTLCYVBJ?= =?us-ascii?Q?QogFNonU79Zy8Ly1HqLH4e3fFDeYo+CLbPnHXpqUoGp7q5I0OErb8PvcYe+9?= =?us-ascii?Q?42sjTagoXQgE9YMZgs61EK8Fyg0AewJRBTBP77gjNB3hmGSaBnt4SqBVhKFC?= =?us-ascii?Q?BQLoawL+4Pj6tZ56pT+O5wknUecF2C5+oeqPusTzCEgP/yudKp5h9d1kkSp7?= =?us-ascii?Q?qhV0V+Y6sD9d7PSdmPLOzhstkD4NrzYuJGatUASe4pOUKQi/Xk+TVQTPTaVP?= =?us-ascii?Q?eO+moZ0JvsImdlaa204t+38EmBvEpAwfu3V/mlAFiD/lTHMBLqBOa5YFXrsl?= =?us-ascii?Q?zk8691q2ME5wGvIRQTx4dwHEyDUQFgHYAevc0R4VhXtgzxIAPtt6JIDVUrxA?= =?us-ascii?Q?fmyeEIMRgWIxZftmjzMXLIyvLkTaS0SDxzVksti3qZSy9f8uzgjk0U8IEjP+?= =?us-ascii?Q?T4dlH6rzFozM7ApHPmBD1oYQmZJZdKVoHAH2qhtURJGBT/JhaHc1eIwzTKEK?= =?us-ascii?Q?DHkrQcvDvBMNgdG2c7s6u5pHhcK7fuwf+nngnGi/3gJAVs7lZxC6wJs6mfR7?= =?us-ascii?Q?/vEQul0C746xbag1Xm05G5y9Ze/LogdWnzhO/tPPgHpdLkCOERYiGn8UHgHI?= =?us-ascii?Q?cJIztvvUkyA90Wr2dGcz9iXjTtKbyrm1npIE7tG+Ih0yf2dLG+YHsk05VVCC?= =?us-ascii?Q?XkdA/I3ruRb2sI2cSWCKs+LrLNnR+Kie3h/dg0zuvKNJM/tOAjuVvIcBw4GC?= =?us-ascii?Q?fyq5vxOjp8a8QkLH2IYMfbx/awSZCkUPFHvvz3fjeSemA0m02BsoZTNQFs32?= =?us-ascii?Q?ILhjtDyUgVlnP99bxA/6lCyq1hvJU2cR4m5y+X86pOudG1DgwyzPZ/dtDQkI?= =?us-ascii?Q?wnTO9hzfgHbgRO5j3xzCqvf7lUejV2lnNC2rpbtHBqc1A4au0f11+9vQ44Pu?= =?us-ascii?Q?MUIe1Vd07TdPr/aRVkoCWZAcIVY19HAjKlTDa4uvxs/ub3M/sEyv88pu/kAP?= =?us-ascii?Q?U0tI7OZ3DAO92qfSp7iCwcXboYiTYJpu8StLZg9HvFASEHxloqGyYEF8yWnI?= =?us-ascii?Q?53I1Hdi5AaxciXD1NBkK+lwusR7GxJOJInsLgbFSwNk2iI/84uu1DGwCN0xI?= =?us-ascii?Q?YlOIl3chtJi0N80LiX98rvHflbsbVCBDjQ1/CdjR/A1ib489QgNr/gFC7O9Y?= =?us-ascii?Q?quQhCNbSh+nH4Xb3o546SnzEaFuG5bhRXldR/HfVa/OcnjOhjp9/me7mi1/u?= =?us-ascii?Q?rtKvZW3MDw=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d70da82a-bd98-4e84-f1c7-08df34cab28c X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2026 08:08:49.4233 (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: UQlklGzRecROof/xX7UHsFP6gIjYuLwzxMuLgmqmdRbJuBByoI57zv3g7Sgs/IvDVdS2mAomIi8tMagt9zTlww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYRP286MB4478 X-purgate-ID: tlsNG-c201ff/1793174934-247132A1-5A9589CE/0/0 X-purgate-type: clean X-purgate-size: 1857 On Tue, 27 Oct 2026 10:18:44 +0000, Andrew Cooper wrote: >On 27/10/2026 4:37 am, Ryo Takakura wrote: >>> You are also going to need a GCC_PATCHABLE_FUNCTION_ENTRY_BROKEN symbol, >>> because of https://godbolt.org/z/sde4faxaz. See the ASM_GOTO_OUTPUT for >>> another example of this pattern. Just use a plain version check rather >>> than tying it to XEN_IBT; this is a new feature and people wanting to >>> use it can use a new enough compiler, and it avoids variability >>> depending on other options. >> I didn't know about the compiler behaviour. Thank you for the detail. >> I'll make sure to check the acceptable compiler version and add a version >> check as you suggest. > >https://maskray.me/blog/fpatchable-function-entry seems to have a >blow-by-blow of the bugs. Interesting! >The ordering with respect to ENDBR instructions is the only issue which >will affect Xen, I think. We don't use COMDAT, or BTI on ARM yet. > >Clang support seems to have been mostly correct at the point of being >added, which is rather more than can be said for the GCC side. I see. Thank you for the advise. I follow them when preparing the check. >>> Separately, you have a number of MISRA violations which you're >>> introducing in your series. I see you've got cf_check, which suggests >>> you have built in GitlabCI. Have you also run Eclair? >> Thank you for pointing this out. >> My apologies for the violations. I wasn't aware of the tests >> and haven't run either of them. I added the cf_check following >> the existing code that I referred to when preparing this series. >> I'll make sure to run those tests before sending next version. > >Do you have an account on Gitlab to run the CI testing? If not, reach >out on Matrix. I don't have an account yet. Ok, I'll ask on Matrix. Sincerely, Ryo Takakura From xen-devel-bounces@lists.xenproject.org Wed Oct 28 08:20:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 08:20:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462930.1673914 (Exim 4.92) (envelope-from ) id 1xLytl-0002Uw-7D; Wed, 28 Oct 2026 08:20:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462930.1673914; Wed, 28 Oct 2026 08:20: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 1xLytl-0002Up-3Y; Wed, 28 Oct 2026 08:20:41 +0000 Received: by outflank-mailman (input) for mailman id 1462930; Wed, 28 Oct 2026 08:20:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLytj-0002Uj-5G for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:20:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLyti-001MfJ-IK for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:20:38 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1b04b-e002-0a2a0a5209dd-0a2a450b9fb4-28 for ; Wed, 28 Oct 2026 09:20:38 +0100 Received: from [40.107.74.81] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1b053-b7e8-0a2a450b0019-286b4a5179ab-3 for ; Wed, 28 Oct 2026 09:20:37 +0100 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TY4P286MB6752.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:33b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 08:20:32 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0546.021; Wed, 28 Oct 2026 08:20: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=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=LkeWRuXyMUiywJD9+7426Mmed8xBTHhjiKhbwXU/tD5w8yxZOQUza593Mbl/h1QekfOyzyG4TlscrgefNSr+3FyuJsBZd5LpLnTGnco05eBgqQeNyVKDId+CPalueHbgHCQtIH9t3l0wPus04aofTaw0/7ytCgfm/V5QLYxhxCG6KeLrYNA9P00qciwxMLxiWCULWaIJGlhdl7ekd8rnBukEOS8IHTREq2D7+V/uscqxNkHcci1jrVy2f5WcpXmaI7K3CLctg7Xh/mqFpsyN46CMl3WBMc2VHbBZg8wBRWFVF4GVb8TiMqW8yh+C87W4t0ljOSbAOo67B/5VAk199Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LansMxIS3D33QokSM4Gv2GyVi2Xj0o/26ld45KmfJX8=; b=c8kIcj/PNVrLYJFy57mDV3mu+la2Rkk5IaH1Sbx2ZjLJiBUa4cKwZuU/SEDnLVTXZGrrPMviWAdSsdbvP/C+wdUjH/GKxIuQhhCM2A6O6/PggNzFSzLF1iDIvv8bSNld3xE3biL2sBwrNW6ouhLbDoxk/9Vttwbv8vNXZeilwgP77vtUOYqmthDzniJDKEMNetbxsQwCh0RRu8lSrcVZjISSkFKn4sm0zTVlYbmjG6z2aNlSur1/FS3gtY28Ks+6tH80Ew1jVjY65AwOQiwxr0OZD5nMY11mkjl67CykbyK5GVMd5437IaIRIEOzx0zoMjX6dTUspOLwGJrEuyAE5w== 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=LansMxIS3D33QokSM4Gv2GyVi2Xj0o/26ld45KmfJX8=; b=iPu45QH5tZRu9/FzZMPcAmJ5NuhZLm/w41pp6Vg8Pj9QOIwK9z420dbjbaxH4/Ca0rfJ6frSRL8xiSjz0Tm9cgV7mLd4Qkn2J8lA/0B/CaLOrqomDWSaNDpSnuxrd3GVtAmuiwQ8AtST989BRc1mnQ0qSWTwLfkRy9J/5lWA7lA= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: bernhard.kaindl@citrix.com Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, roger@xenproject.org, ross.lagerwall@citrix.com, jgross@suse.com Subject: Re: [RFC 3/5] xen/tracing: prepare a livepatch payload and its controling interface Date: Wed, 28 Oct 2026 17:20:17 +0900 Message-Id: <20261028082017.121826-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <179285123800.1706038.4978498781229199186.b4-review@b4> References: <179285123800.1706038.4978498781229199186.b4-review@b4> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0056.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2b5::17) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TY4P286MB6752:EE_ X-MS-Office365-Filtering-Correlation-Id: 47eb6180-aacc-455d-8309-08df34cc5599 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|366016|23010399003|1800799024|376014|261022105027099003|261021121427099003|261009223027099003|261022075727099003|261022115727099003|10067099003|56012099006|261026140227099003|6133799003|3023799007|18002099003|22082099003|261026121527099003; X-Microsoft-Antispam-Message-Info: td70Lds5b6nHTZgjwmvb6EaRgrVwzeaYWlzXHJa5Cno/yqo6OtTCyamg0BW1luUamYLRax6zHdIlzrM/j+3BDpCtlrxGXyf+WkmCSY4Z6Vya1ZiV6i+tzHgzAhcogVHATOyu+w/EFNN0A71jwJbpLO1Cv8WgU/3sKkrwa5zwT/vSKjWRlvbyIJU3cM1m8691fl575GPboHqNLjqTdDcBAR+iHTIUU8N8Dtjs9L5m5XZY5qEceNjkRHUnDSx5uVRD0vzCBCrZsId5O396MxWUO9n65Ukl7VFTayw/g9d9cYLHlAN6K0jb1Q+0Nm9cMbdk0f4EEh9Myg/eVDJ/vq2Lge64HtRCZFYtw0+oE5S/PJhId9FWCZ+Vi/s+7AwUwryEJyuL/y2CeiXqH65VuIN/iY3ekJiH1Me9glvkCIJNcaPub/7LUeo7YdS6b443TAvMMuV7eAyQ+4MwdTtSaW/W+3twqVAZSj2T1XLj8FV6RrQNwTFM4IFJiXPRgrMUuPs90YAdKca3KIEvJQBjpDkRF36yS6rA2FZ/2nfslAw9opEOjSkY3ZEMnn39CFgNgFDH434qjSYSO05j04SODdvrbU+1lCLN7Qxtu396xKsunGEoAK0ZzzXK/LglzYjRqInJ5roRcghjLP4bR7ChHiLqFuR7mcAUxOl0Bd3lrwPJdrE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(7416014)(366016)(23010399003)(1800799024)(376014)(261022105027099003)(261021121427099003)(261009223027099003)(261022075727099003)(261022115727099003)(10067099003)(56012099006)(261026140227099003)(6133799003)(3023799007)(18002099003)(22082099003)(261026121527099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?B+DL1ONMBkklWmupw03AmxRW7l7ycR1twceH5Dcm9BsTDvf30cA+tGtoe2BD?= =?us-ascii?Q?DjQAU1eKC7KqUEM/0mZLqGBelSr+e2CFnuyQYjrdeIyED7+75o+Wnu/jJSqr?= =?us-ascii?Q?iaBqeNGl0ntYRB+rSh7b8syOR7L2H4vxNPlrKeFwVy5K/ioo2Dkf1f1Z8DkF?= =?us-ascii?Q?GSfFsKdu/35e4jGJzH671fT7X+J3aogOYJAvvchO3tvxjynLdeK/tivJvueN?= =?us-ascii?Q?ftksIMuE0BM/Fh7vTAPXCt+jAq8FpFnsBvDoAn0ucYyBs9QU4AaczmJM6akk?= =?us-ascii?Q?mEnPVs7DTWsDaNlGNfzYqu7u87oNYSni0CsE47UXRSUAj7B4EW4oD9lKY81M?= =?us-ascii?Q?R6Q5uKra9FT6trxBUpwbsCGVjjI+ID/xkMrjfznpDZvxfU9A9ceU12g/qjDB?= =?us-ascii?Q?SO59h637NmrSZ1LKaqF0gZAnHrwaQ76x6qGIeRXrWXCljhn62QK5vayxF70T?= =?us-ascii?Q?H3Yha2jXc6bN1NGFrZK75LDmiY+UPQa+U8uqiT17nHfEmq5PF89kXNi6X8nK?= =?us-ascii?Q?9HQ8qibMFWrl9fjk0lYBQG2Axduo3DRNUzrCEzDqKpzBJazz0xn6EG7//Bhw?= =?us-ascii?Q?LnZluNyiKs9pjywWwfYLjc2+xSbN33ySQd2Pk+hORXmeYhZ098f/5DRF3Wtg?= =?us-ascii?Q?OL0WA5DzKV3wlVp+i/5x6rhk5OWAA6NaYEZ59KgDnJFE4Eh0yf1Jc17r5rHc?= =?us-ascii?Q?6oYusNuW66G59RAM7R1kG94sNMyEgMVIm9Gg83LFTKj2IJcfmCgvm2QZpWeq?= =?us-ascii?Q?g0+hgQsHjXMIKMdRGTz40ZPL6khj4MA1orseShiYsTRPTInEmnZq0khXyERe?= =?us-ascii?Q?6hYCXTlQvdaVgPq1dSHD3L7/OgSyPi9bm+csX/wrSlHsS2dZFoaZ7SNQJYPf?= =?us-ascii?Q?ZZFflpTmcYMwhhniW6/+sMJUA0CBM8urAU8BsorNdM6wN1cn6erz5OmGYQxj?= =?us-ascii?Q?PN25H2y/bADwlgOto/pMTmgv4U32qQd1It5M3DGcLAIwoBCzDy9lK3tAcbgF?= =?us-ascii?Q?jPPAyLycKCDcWYzmI0v43jRBnOWq8WOCFFxLxY3D0wR5n9vgkJqRGYju1I1y?= =?us-ascii?Q?+cRmRqsIMb3KlBajkSUG17GrKv0FP/heZQ/wd/tWlRL6CPMlKlVS+YOiCSJt?= =?us-ascii?Q?OqB0Ksx/3eCj2TF2LOFJwEs3Tf7PuwdumtMxr7Dy+sIgi+pSHp1E2bH80sLc?= =?us-ascii?Q?ry/hUMBsPO7tHk7a4GDCPTcgOF/ZzSJ84hNw/KfCs7vpFO8Orr9SrxgopVn1?= =?us-ascii?Q?wmwrgB1dkJoz79iSiPphPU/ktFZZNK8eqzJwkLt8A0GoavZtUOO247/Oizzx?= =?us-ascii?Q?f0ZFCnrCXtkoaQNzMX0sN4F9tmn5zUbyB8E0BUntXFGKQH0ox291CocGV9vn?= =?us-ascii?Q?V3CaAmH/kDGu16o4C/aTy5RtZ8UsHCwu14FrAFj/8HRyRogL10yXbX5a/FCB?= =?us-ascii?Q?vEDmUgjhIvBdQPgobxLVx/SdkgROOVkmoUdKgMyYEbBCRAtMagIpwLaIuxtU?= =?us-ascii?Q?W3uzy1O/sdtEaWg7hzSTeagRB9Kz/nmC5CFEZ+khufnC9RyThv1PYtNAjQ2S?= =?us-ascii?Q?tHq7ZLtRvMnIa6l4jqjrBstphzkLrIm63umVuxKypmxwlwAijpfY1OVZaeAA?= =?us-ascii?Q?oZ6w6510oNPOolU1nkVsZJ+hxWHzOgPaAQ/d0SoRa/5/ownJObhhW+QnYfrm?= =?us-ascii?Q?FiTIFNweDwotibMXDOXnLVMQPgpnFoYZIG8uNZY2QRICvr2dm098ZYHpod1x?= =?us-ascii?Q?r4EVmVtb1A=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 47eb6180-aacc-455d-8309-08df34cc5599 X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2026 08:20:32.4748 (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: Ou4xjeZtxH5XQZCsp8haj4ZUNYKmlx2EiIkFmpEhwSg2mwa4UeaicXTiUwr4DS8ApgyfM0wB2TEdsGMVW6qpNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY4P286MB6752 X-purgate-ID: tlsNG-42698a/1793175638-AA4DB9EA-ACC66283/0/0 X-purgate-type: clean X-purgate-size: 12526 On Sat, 24 Oct 2026 16:13:58 +0200, Bernhard Kaindl wrote: >> --- /dev/null >> +++ b/xen/common/hypfs_trace.c >> @@ -0,0 +1,741 @@ >> +void trace_dispatch_callbacks(unsigned long ip, unsigned long parent_ip) >> +{ >> + livepatch_trace_func_t callback; >> + >> + if ( !tracing_is_on() ) >> + return; >> + >> + if ( !trace_callback_registered ) >> + return; >> + >> + if ( !global_trace_func.old_addr ) >> + return; >> + >> + if ( (unsigned long)global_trace_func.old_addr != ip ) >> + return; >> + >> + callback = global_trace_func.new_addr; >> + callback((unsigned long)global_trace_func.old_addr, parent_ip); >> +} > >What synchronizes this reader with callback removal on another CPU? Testing !trace_callback_registered was the intended synchronization here... >The corresponding part of trace_unregister_callback() is: > >> --- /dev/null >> +++ b/xen/common/hypfs_trace.c >> @@ -0,0 +1,741 @@ >> +int trace_unregister_callback(void) >> +{ >> + int rc = 0; >> + >> + spin_lock(&trace_callback_lock); >> [...] >> + trace_callback_registered = false; >> + global_trace_func.new_addr = NULL; >> + >> +out_unlock: >> + spin_unlock(&trace_callback_lock); > >Could CPU A pass the enabled and registered tests, then CPU B clear >new_addr, before CPU A loads and calls it? Would that permit a NULL >indirect call despite the writer's lock, since the reader does not >take that lock? ... and yes, I think this can happen. >I wondered whether the existing payload RCU region might cover this, >but the new dispatch appears after its unlock: > >> --- a/xen/common/livepatch.c >> +++ b/xen/common/livepatch.c >> @@ -232,6 +236,11 @@ xen_livepatch_trace_dispatcher(unsigned long ip, >> unsigned long parent_ip) >> out: >> rcu_read_unlock(&rcu_payload_lock); >> + >> +#ifdef CONFIG_LIVEPATCH_TRACER >> + /* Call tracer callbacks. */ >> + trace_dispatch_callbacks(ip, parent_ip); >> +#endif > >Would an ordered publication and reader-lifetime protocol help here, >including draining callbacks before unregister/reset completes? Could >it cover registration as well, where the registered flag is currently >set before the callback pointer? Merely checking the pointer for NULL >would not seem to protect callback state already being used elsewhere. Thank you for your suggestion. I'll extend the existing payload RCU read-side region to cover the callback dispatch and remove the registered flag entirely. Do you think something like the following would work? ---- BEGIN IDEA ---- --- a/xen/common/hypfs_trace.c +++ b/xen/common/hypfs_trace.c @@ -135,17 +135,16 @@ void trace_dispatch_callbacks(unsigned long ip, unsigned long parent_ip) if ( !tracing_is_on() ) return; - if ( !trace_callback_registered ) - return; - if ( !global_trace_func.old_addr ) return; if ( arch_livepatch_trace_entry((unsigned long)global_trace_func.old_addr) != ip ) return; - callback = global_trace_func.new_addr; - callback((unsigned long)global_trace_func.old_addr, parent_ip); + callback = rcu_dereference(global_trace_func.new_addr); + + if ( callback ) + callback((unsigned long)global_trace_func.old_addr, parent_ip); } int trace_register_callback(livepatch_trace_func_t callback) @@ -154,14 +153,13 @@ int trace_register_callback(livepatch_trace_func_t callback) spin_lock(&trace_callback_lock); - if ( trace_callback_registered ) + if ( global_trace_func.new_addr ) { rc = -EEXIST; goto out_unlock; } - trace_callback_registered = true; - global_trace_func.new_addr = callback; + rcu_assign_pointer(global_trace_func.new_addr, callback); out_unlock: spin_unlock(&trace_callback_lock); @@ -175,14 +173,16 @@ int trace_unregister_callback(void) spin_lock(&trace_callback_lock); - if ( !trace_callback_registered ) + if ( !global_trace_func.new_addr ) { rc = -ENOENT; goto out_unlock; } - trace_callback_registered = false; - global_trace_func.new_addr = NULL; + rcu_assign_pointer(global_trace_func.new_addr, NULL); + + /* Drain every callbacks before unregistering this tracer */ + rcu_barrier(); out_unlock: spin_unlock(&trace_callback_lock); ---- END IDEA ---- >Separately, could a pending filter apply survive a successful clear? Yes, it could. Currently, it only checks the immediate result of schedule_work() and the applied state of the payload. >> --- /dev/null >> +++ b/xen/common/hypfs_trace.c >> @@ -0,0 +1,741 @@ >> + /* Schedule removal of the current patch. */ >> + if ( global_trace_fstate.applied == LIVEPATCH_FUNC_APPLIED ) >> [...] >> + /* Clear the filter if no target function was requested. */ >> + if ( !ip ) >> + { >> + /* >> + * Keep global_trace_func.old_addr since livepatching >> + * might be in flight. Only clear global_trace.filter_name >> + * which will effectively update /tracing/set_function_filter. >> + */ >> + global_trace.filter_name[0] = '\0'; >> + return 0; >> + } > >If I select a function and then clear the filter before the trace-on >worker runs, wouldn't applied still be LIVEPATCH_FUNC_NOT_APPLIED? Yes. >Could the clear therefore return success without canceling or removing >anything, followed by the queued worker installing the original target >while set_function_filter reports an empty filter? Yes. >Would it make sense to track pending work explicitly and either return >busy or arrange a safe cancellation/removal before accepting the clear? Yes, I agree tracking the pending work. I'll make sure the pending work gets handled appropriately for the next version. And I believe it should take care the issue you addressed concerning trace_set_filter() as well. >There seems to be a related completion-status question at the end of >trace_set_filter(): Yes. >> --- /dev/null >> +++ b/xen/common/hypfs_trace.c >> @@ -0,0 +1,741 @@ >> + rc = livepatch_schedule_trace_on(payload, global_trace.func, ip); >> + if ( rc ) >> + return rc; >> + >> + strlcpy(global_trace.filter_name, name, >> sizeof(global_trace.filter_name)); > >Am I missing a place where the controls consume payload->rc after the >worker finishes? No, you are right. There is currently no such place. >The existing livepatch worker can fail during CPU >rendezvous or application after submission has succeeded. Could the >displayed name then describe a target that was never installed? The >removal path clears the name before completion, which seems to allow >the converse if removal fails. Yes. The same issue stemming from overlooking the pending work. >Could requested and installed state be kept separate until completion, >with a way for the user to see the eventual result? I agree that those two states should be kept separate. I plan to prepare a new file, something like /set_function_status, which user can track the state of the request, which is payload->rc. And leave /set_function_filter for showing the installed function. >What is the intended contract for changing current_tracer while >tracing_on is still set? I see that its inconsistent right now. I think current_tracer should not be changed while tracing_on is set. >> --- /dev/null >> +++ b/xen/common/hypfs_trace.c >> @@ -0,0 +1,741 @@ >> + if ( prev->reset ) >> + { >> + rc = prev->reset(&global_trace); >> + if ( rc ) >> + return rc; >> + } >> + >> + global_trace.current_trace = &nop_tracer; >> + >> + if ( new->init ) >> + { >> + rc = new->init(&global_trace); >> + if ( rc ) >> + return rc; >> + } >> + >> + global_trace.current_trace = new; > >Could a tracer change either be rejected while recording, or perform >a stop-and-drain transition before reset and initialization? I plan fix it by the former approach of "reject while recording". >For a tracer using the optional start/stop hooks, wouldn't the present path >leave recording reported as enabled without stopping the old tracer >or starting the new one? I missed this inconsistency as well. I believe it should also be fixed by enforcing "reject while recording". >What should tracing_on report if the new >initialization fails and nop remains selected? By enforcing "reject while recording", it should be reporting '0' as tracing should already be disabled at this point. >One more target-validation question: what excludes discarded init >functions from filter selection after boot? Thank you. This was missing as well. >> --- /dev/null >> +++ b/xen/common/hypfs_trace.c >> @@ -0,0 +1,741 @@ >> + if ( len ) >> + { >> + ip = symbols_lookup_by_name(name); >> + if ( !ip || !is_patchable_function_entry(ip) ) >> + return -EINVAL; >> + } > >The new linker table appears to retain the compiler-generated entries >without filtering out init functions: > >> --- a/xen/arch/arm/xen.lds.S >> +++ b/xen/arch/arm/xen.lds.S >> @@ -61,6 +61,11 @@ SECTIONS >> + . = ALIGN(8); >> + __start_patchable_function_entries = .; >> + KEEP(*(__patchable_function_entries)) >> + __stop_patchable_function_entries = .; Yes, they still retain the init functions. >For reference, the existing symbol_valid() in xen/tools/symbols.c >retains symbols in init text too, and symbols_lookup_by_name() in >xen/common/symbols.c returns matching addresses without an active-text >check. Its non-FAST_SYMBOL_LOOKUP branch contains: > >> if ( !strcmp(name, symname) ) >> return addr; > >Meanwhile free_init_memory() in xen/arch/arm/mmu/setup.c removes the >init mapping and returns those pages to the heap when appropriate: > >> rc = destroy_xen_mappings((unsigned long)__init_begin, >> (unsigned long)__init_end); >> [...] >> if ( !using_static_heap ) >> { >> init_domheap_pages(pa, pa + len); > >Could an init function's name and compiler entry therefore still pass >this selection check after its code has been discarded? Since the Arm >patcher writes through an alias of the original image's physical pages, >could that write into memory which has already been reused? Thank you for elaborating. And yes, currently init functions could pass the check and be selected. >Would checking active text before accepting the target address rule out >this case? To illustrate, I think this could be addressed with a small >change like: > >--- a/xen/common/hypfs_trace.c >+++ b/xen/common/hypfs_trace.c >@@ -3,6 +3,7 @@ > #include > #include > #include >+#include > #include > #include > #include >@@ -266,7 +267,8 @@ static int trace_set_filter(const char *name) > if ( len ) > { > ip = symbols_lookup_by_name(name); >- if ( !ip || !is_patchable_function_entry(ip) ) >+ if ( !ip || !is_active_kernel_text(ip) || >+ !is_patchable_function_entry(ip) ) > return -EINVAL; > } > > >Would this reject discarded init text before either scheduling path, >using the same text-region safeguard as address-based symbols_lookup()? Yes, I think this works. I'll make the change for the next version. >This only checks whether the target is currently active text. It does >not validate reserved instruction bytes, reject overlapping livepatches, >or establish the lifetime of a dynamically removable target. Understood. For the other concerns, please take a look at my reply to your feedback on the 1/5 patch. I believe the check I added for the proposed arch_livepatch_verify_entry() should address those concerns. >The pending >operation and callback-lifetime questions above would still need their >own solution. > >Thanks for looking through these questions. Is there a lifecycle, >completion, or target-lifetime guarantee elsewhere that I have missed? Thank you for your feedback. You didn't miss anything. I'll make sure they get fixed for the next version. Sincerely, Ryo Takakura From xen-devel-bounces@lists.xenproject.org Wed Oct 28 08:44:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 08:44:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462941.1673923 (Exim 4.92) (envelope-from ) id 1xLzGQ-0005lQ-0Q; Wed, 28 Oct 2026 08:44:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462941.1673923; Wed, 28 Oct 2026 08:44: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 1xLzGP-0005lJ-Tv; Wed, 28 Oct 2026 08:44:05 +0000 Received: by outflank-mailman (input) for mailman id 1462941; Wed, 28 Oct 2026 08:44:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLzGO-0005lB-LF for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:44:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLzGL-006nrv-U1 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:44:01 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1b5b3-e002-0a2a0a5209dd-0a2a4502b572-48 for ; Wed, 28 Oct 2026 09:44:01 +0100 Received: from [40.107.162.94] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1b5d1-6ca4-0a2a45020019-286ba25e1ed9-3 for ; Wed, 28 Oct 2026 09:44:01 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by VI0PR03MB10447.eurprd03.prod.outlook.com (2603:10a6:800:203::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 08:43:57 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0569.007; Wed, 28 Oct 2026 08:43: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=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=BabKwu7h+DAEK0ebg0FBuqWIlSEp1Kj7k8tm04VjTyBwxchrnhx3MkHEhDcqOoe9Y9SDAq6WyUoJBnUnLOnCcEf/JqAy8hWjjFoKPA0MQ2Eql8FgRqiIvNfCz/ty1ODfUagds3l1A/+m3oJgs5PWKq15VIz+f+QHd8JbOscQYwO3cnu+i1bo9QBe9y8Qmh125gyzuq0d1sYHLo41NX87nLj6of1GbfKlsdS0gGeReZURz9I7wEhvsvjLMnnlxhaVqK+c49GnZpQ/aLeF/aQ9wt0s/YYSytd84F5IHGevL6S5J2Na95qwW8RZ1tGdCOahdDJT05ri5y3hRLdgoMNIfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3k2MgLDCk3FIhsRPvknL2cyyE80gg7qtG6s2Iv9BIsM=; b=XgSi73qQE7AH4Occ/eV8WjRhPt57ZHO/js34GG2PO5ne5XG3O4aauBS4MQJfm/I/G//dgkgVJepJhYn4zJq2zAW06jovPo/NOU9Fgnz4kDobth9wlpaGgDn4m4/yJm5dbI5xI95HhYzpuRzxWXbkHFpH9eCOdvDbN/Y3a9BFMP3t/JYlcdXW/Q4zPMdzHp6e0FB639RJ3q1h7K0AUdDkDvRZm0a+s2D+lQo76GpVuvFr3Y3xy5FElYoCcPrXymEu2v9tNPX7050+7jFh8Tcyy3LRfAg5iiW1zJ+8iMFzb8UN90QqY5PAwHHaXUHFUlksiYcPIfPGGj6kXBMvOuY+rw== 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=3k2MgLDCk3FIhsRPvknL2cyyE80gg7qtG6s2Iv9BIsM=; b=EXEoERHf6fVYJLaTmM0/Vp4RancEYRA0iJY4kWsrEuUIdvFIZXKHLDQLg17A9vAJ5PzLrzmM/sNIRGUuXCYIdgXwdK+Ehm4hB+bszDh/41bv7Sw9y0BPyZhEySmqAQ4yOktmzix6ZFacdVKzwOJCKS3XgYk+hnhJGvHC82Eql8jNt4AzIZO5KIQKsBlj9wtfxZgkVb/Apvn/wmeH3n2bXLGaokvwLlrmh5L+sc+B7xnNDgcw3257t7nlnLaedM7lXV6BmceYFK3BIS+x3/014jhmAjIbPFryn6l4fTZaZ1ZXP05YO085VBrNL5bi/mlpW+Wp944W/o1HiFo7l33fkg== From: Mykyta Poturai To: Jan Beulich CC: Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Topic: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Index: AQHdZUVvbuj2+I/wmEeMfHolzOWTxrcPwg+AgAFhaACAAAvYAIABdxSA Date: Wed, 28 Oct 2026 08:43:57 +0000 Message-ID: References: <8b2fa10a-17ac-4807-b9d2-874f84a85efc@suse.com> <97a123f8-92e8-4ff8-bb3b-a48ad2fe1392@suse.com> In-Reply-To: <97a123f8-92e8-4ff8-bb3b-a48ad2fe1392@suse.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: AS2PR03MB9076:EE_|VI0PR03MB10447:EE_ x-ms-office365-filtering-correlation-id: 4801592c-c748-4d56-75ca-08df34cf9af9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|366016|376014|23010399003|1800799024|261026140227099003|38070700021|4143699003|11063799006|56012099006|261026121527099003|261021121427099003|261022105027099003|10067099003|261022075727099003|22082099003|18002099003|6133799003; x-microsoft-antispam-message-info: 7zm8jXLxWeO75+BQnwffOej8jz9/xXl72laOgaPhaZZPIkTT8+2hJ2zwdtC85G/Q++7cWA/Pd0GP556Gow0lk3pSL9IVzvMc03q/zwgoUk5WFfw0PCV8avGaMTebwKPJSBT9zU4dPSjhhPg9SYY5nj9XgneYYVMgKIgkEVbCz+IIyuqTAT0Xga41rqYuxdx5oVKWKWgnPWyRmwA8DZhpZhu1/qNQ2d0oTfdgu0MKjS0vLF3/bHgSvNBJ7f1ZU8+X2EOrWJwcbIHFuPoMhZaioy+BHpubnizAxLmIiF3LDs6whVp9pJ87kaHovSm7X0Op0DLsZgYrqszRAuaC8Sr2TyNQHtzxvhaY316+m6nXYGSbmvzeQB1EAFTaZNuRGZ/KBGwHVD69Na55yy9Wr/t6bx9HLLGXw/qx608jciOW44DCBmCSvG7DHILyTzGtNYbPWGA1NtqG9OVsGgkHRtdia9GES5isMse9MsuPR09LbU1cLQbRVbXZZU+i2lCc1S70LTFxJAOWOiy+3+eq2zRwbIOJY8RV16rBMV2Osy8cJrZ5TprI9CXF533rW6ijjiUmUbRz4VVKOq41w2LK7HWbNH96T/mMA6YRqIIQEar8NgJ3OesIXV+rnIEFRXdI4XW2kJTsd+GNZFDRHvxhNuPGiO1J9WxEWixv9DxTK4D5LmPBozF9rVVTmKMql1ut3DjvPekjedDMaq/hhI40idIfZZws0cax8ZRsibYVPu6aduc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(366016)(376014)(23010399003)(1800799024)(261026140227099003)(38070700021)(4143699003)(11063799006)(56012099006)(261026121527099003)(261021121427099003)(261022105027099003)(10067099003)(261022075727099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VGJuUTNoaElJcXBtMllOMUZNOElnNTI4U3JWMERQSUtLTmpTdVZrYk9seGxo?= =?utf-8?B?VjZNZEp5ellLdm5Ocjg1WTdFRHRWUGw2VHltQWlyTnFiaVhCZ1JuSXo2N3U5?= =?utf-8?B?NFgvSHBzdjVkamxQbkJBc2ZQQkkyY0UrZ3VxZDZ6ay9RQ1FuVVVnTzlwVzBN?= =?utf-8?B?N2ZBakZCWGwxdWZJUU54WEQvdzhlN0JsWlhreWZyVW11M1QzbExNelZuZjBl?= =?utf-8?B?YVRXbzVZQnVNTFoxc2ZTSC9zdExzRDdnUkgrSHlSSTRDM2lEVmpFdHRTd3lv?= =?utf-8?B?RzVWNFBBU1ZZODNFUHR4Qkd1aWoxc0hiVlliOGhIQmh0bGVzbW8zNjlrdENr?= =?utf-8?B?YUJwK3lsTXhGTSsrNm1ZL0gySGJ3dWRXN2tnYlZxUTVaQXV0MTVRSEIxaE9B?= =?utf-8?B?SUprcFpHZG5zRFdSL0UxVzdrbUJTTFI1b1V6SzNFQk8vTDQvN3kzVlZwTzll?= =?utf-8?B?anNKUDNTRGdrZktFMkowZGxhd3pSaGVWaWhKM1VTUmlWQWdUMEJiSHNmbGJB?= =?utf-8?B?MXQrOUFKdUNwWkhzZkIyNytDZTE1dUdyNWZJKzRLektlbDIrR2NKblNwejZ5?= =?utf-8?B?c2NKU2tWYWZld0VOK2V0MGxaRzNoRWxkdnRHQUVYb1hLNU9hcXdLZCtjSDBX?= =?utf-8?B?WGcvdkszNUF6cHg3cEcvRnByOUhCcDZtZ1lndi9UQ0dPOG83NVlLaDRSRi9Q?= =?utf-8?B?NlcxRFNqQWZON2tyMk1KQ2JXOE1Pak0vbDF2bk16Zi8yMU1YVFlTR1JRcUZQ?= =?utf-8?B?SkczUFEzR2pVaWEzWlcrTnVHUGord3B2NGhSYVFZMEwxUGV1VXhDVVMxby94?= =?utf-8?B?UWJJaExLeUEzNlBpc2dFc0NieWNwSlhZcTRsdXRkQWsyQ1hUSC9xbElnbVRp?= =?utf-8?B?UWVaOHRoZmZ0c2JzMmw2WDR3ZWs2VUk3Zzc0SGRnYjFGenpzMjJGQ0NZWkVo?= =?utf-8?B?ZzRiems5clBRNlVvSVI2QzlOSW1CTWZJS21CSWUxR2NnY2trNUI1MGxUUkVh?= =?utf-8?B?dXhNc2FiazRuQURFVCtOSXVtKy91Z3NyUnR5OUREdkZkcDNmQ0Vxb1U4UStx?= =?utf-8?B?MlJxaWZ0Ni96S2FtV2hXWUhxUXY4MUhTNzBsNjlFSVNaZHVwOWh6K0ROUXBw?= =?utf-8?B?WGt2UEp0S3lyVWtFeDRMeC9NV09VMVQyTTdvSW5vNzUyRGV1ZXlMK2UxRWR6?= =?utf-8?B?ZlRYc1YwUmhTT2lmOXBtZW9odlNmYUFLOExaZmhWWjBBakQrMk9Sb2grY21K?= =?utf-8?B?SUNWdlB4TnUwRmtWWk5oMWxSazJDT0lJeUp2R2lZbkRUZEFTdEZGa0VpTWRK?= =?utf-8?B?TXRkbmdMRENqVmNkVEhSODVSOFpSYk4wb1ROeTB2enZZdWVXbHVYVU5jQ1E3?= =?utf-8?B?SXk0MndiUXlPUmlaU3lhYnFEK0wxUWwxbTg1Z3d5LzAyZ0IxTDdsTXpGeXNV?= =?utf-8?B?RjFXaW9CWFY2UkpSaUxIbHJKT0QwbXk5elgzRmFDOFBqRlBSbzl3aHFoM3lr?= =?utf-8?B?U3F5MzhCQ3dDMlZjY3BMWmRUd2NFRnJ2YXVXWFVUTkpyRlFycTlPM2VSNTJq?= =?utf-8?B?dTl5R0NOUXRhOHdFRjFSeWpJVGpqU1k5dTJ4Z0MvN3k0ODhvZGVveXd3WUVr?= =?utf-8?B?VTg5NHBzS0ErKzNuNDFDYUluY0Z1SVVUTGpGaCtTaTA1SXJ1d3JXTC8yKzNO?= =?utf-8?B?UnFyamliUE05SEs5WmRVa1VLcVQwS3dtMXlJeFJGUzhDbFgvZTdYbW9pMHNn?= =?utf-8?B?Zm5ldy94OTV3cnBrWHBKR0xJdWlkMHpMYjV0RDhla2RaSmtxU1EzZ0ZwTmhZ?= =?utf-8?B?KzZUYjdZR2w5dEo3S29jekdKL1RvMVNMRmlCZnhjL1hFMFdHQ2NhaGR1UXRn?= =?utf-8?B?RUo2UzIrbnV5UXczR25nODlDMDhlYndWNUtLeE53MVVkTTBQYnVwQzQyOXdD?= =?utf-8?B?dG9VU2lyR3pIQkxPVGhXN0ZOTzJFTGxqUVhoY1ZyWkcxQkZMZHBaTWg1NU92?= =?utf-8?B?R3hBenNLdTFFWUVLcjNIRFIweXBmRStta1Z5S0VyU2MrYU5kb0twZnpQU0dy?= =?utf-8?B?WUF2R0xXWVZqNng0aGJ3YlZyd3REYXlmWmF5bCt4UVZNWUZRazZ0OVBjd1hm?= =?utf-8?B?d0cxNVVqZ2wwSGxlQkRZTVhzV0tsRThSdC9tZlFkeDU4YmRzdFgxcVJUUjhk?= =?utf-8?B?cG45enRJNmN1NjRrR2ZPUlBhZGdxdnhvYWFOZUhLSFU5OFBEYUZUSkVra3Nv?= =?utf-8?B?Y0xxM01JRm1KemNNKzBUa3M4L3ladlpBMTBCY2xRL0U2SHAxTjJQWWtwTE9a?= =?utf-8?B?aFcxWE1wcWRDL1lucWhtVWNIaVZQa1dYSFJyRzdDc29TdTZqaGZscTFqRXNK?= =?utf-8?Q?YMEhLkfaB0Up5Q2g=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <5A428DABE310A144A0E4A2916A1C5DA8@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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4801592c-c748-4d56-75ca-08df34cf9af9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2026 08:43:57.2145 (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: n9b8WXePssCdB0jNgDOCt2e4DoDHWHcI1oYSy5VfuFYqCc/Vb2pDxg3mgdgug3joNc3GuSY8T3j19CabRTMUAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10447 X-purgate-ID: tlsNG-720697/1793177041-666B72AC-A031AB95/0/0 X-purgate-type: clean X-purgate-size: 1872 T24gMTAvMjcvMjYgMTI6MjEgUE0sIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNy4xMC4yMDI2 IDEwOjM5LCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+IE9uIDEwLzI2LzI2IDI6MzQgUE0sIEph biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDI2LjEwLjIwMjYgMTM6MjcsIE15a3l0YSBQb3R1cmFp IHdyb3RlOg0KPj4+PiBUaGlzIGlzIHByZXBhcmF0b3J5IHdvcmsgdG8gbWFrZSB2UENJIE1TSS1Y IGZ1bmN0aW9uYWwgb24gQXJtLiBTcGxpdCB0aGUNCj4+Pj4gdlBDSSBNU0ktWCBjb2RlIHNvIHRo YXQgaW50ZXJjZXB0aW5nIHRoZSBNU0ktWCB0YWJsZSBhbmQgUEJBIHN0YXlzIHg4Ng0KPj4+PiBv bmx5LA0KPj4+DQo+Pj4gVGhpcyBsaWtlbHkgaXMgcmVsYXRlZCB0byBwZWN1bGlhcml0aWVzIG9m IEFybSdzIGludGVycnVwdCBoYW5kbGluZywgeWV0DQo+Pj4gb24gdGhlIHN1cmZhY2UgSSBjYW4n dCBzZWUgd2h5IG5vdCBpbnRlcmNlcHRpbmcgTVNJLVggdGFibGUgYWNjZXNzZXMNCj4+PiB3b3Vs ZCBiZSBzYWZlLiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBleHRlbmQgYmFja2dyb3VuZCBoZXJl IGEgbGl0dGxlPw0KPj4NCj4+IE9uIEFybSBtb3N0IG9mIHRoZSB3b3JrIGlzIGRvbmUgYnkgdGhl IElUUywgc28gdGhlIG9ubHkgdGhpbmcgdGhlIGRldmljZQ0KPj4gbmVlZHMgdG8gd3JpdGUgdG8g dGhlIGRvb3JiZWxsIHJlZ2lzdGVyIGlzIHRoZSBFdmVudElELiBJbnRlcnJ1cHQNCj4+IHRyYW5z bGF0aW9uIGlzIGZ1bGx5IGNvbmZpZ3VyZWQgaW4gdGhlIElUUzsgaXQgd2lsbCByZWplY3QgaW52 YWxpZA0KPj4gRXZlbnRJRHMgYW5kIGFsc28gaGFzIGEgc2lkZWJhbmQgRGV2aWNlSUQsIHNvIG1p c2NvbmZpZ3VyZWQgZGV2aWNlcw0KPj4gY2Fubm90IHRyaWdnZXIgZWFjaCBvdGhlcidzIGludGVy cnVwdHMuIE1lbW9yeS13aXNlIGV2ZXJ5dGhpbmcgaXMgZ2F0ZWQNCj4+IGJ5IHRoZSBJT01NVSwg c28gYSB3cm9uZyBkb29yYmVsbCBhZGRyZXNzIHdvdWxkIG5vdCBwb3NlIGFueSByaXNrIGVpdGhl ci4NCj4gDQo+IEFuZCBhIGd1ZXN0IGZpZGRsaW5nIHdpdGggdGhlIG1hc2sgYml0cyBiZWhpbmQg WGVuJ3MgYmFjayBpc24ndCBhIHByb2JsZW0NCj4gZWl0aGVyPw0KPiANCj4gSmFuDQoNCk5vLiBN YXNraW5nL3VubWFza2luZyBhbiBpbnRlcnJ1cHQgdGhlIGd1ZXN0IGhhcyBhbHJlYWR5IG1hcHBl ZCBpcyBqdXN0IA0KdGhlIGd1ZXN0IGRvaW5nIGl0cyBvd24gY29uZmlndXJhdGlvbi4gVW5tYXNr aW5nIGFuIHVubWFwcGVkIGludGVycnVwdCANCndpbGwgcmVzdWx0IGluIGl0IGJlaW5nIGRpc2Nh cmRlZCBieSB0aGUgSVRTLiBTbyBJIGRvbid0IHNlZSBhIHByb2JsZW0gDQpoZXJlIGVpdGhlci4= From xen-devel-bounces@lists.xenproject.org Wed Oct 28 08:59:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 08:59:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462950.1673932 (Exim 4.92) (envelope-from ) id 1xLzUq-0007mw-6t; Wed, 28 Oct 2026 08:59:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462950.1673932; Wed, 28 Oct 2026 08:59: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 1xLzUq-0007mp-3z; Wed, 28 Oct 2026 08:59:00 +0000 Received: by outflank-mailman (input) for mailman id 1462950; Wed, 28 Oct 2026 08:58:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLzUo-0007mj-R5 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 08:58:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLzUo-00CzsF-7v for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:58:58 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1b950-2eae-0a2a0a5409dd-0a2a4504cedc-12 for ; Wed, 28 Oct 2026 09:58:58 +0100 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1b951-b57f-0a2a45040019-d155dd32e996-3 for ; Wed, 28 Oct 2026 09:58:58 +0100 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48bbb06e746so324556f8f.3 for ; Wed, 28 Oct 2026 01:58: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 ffacd0b85a97d-48e3ecd8dcfsm26989822f8f.50.2026.10.28.01.58.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 01:58: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=1793177937; x=1793782737; 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=tsn6W+xGHU1NREbN8EiTgjzU96Ug5ZpjuHZgSoxPCxI=; b=en6VxawGYaoq1x2xsMCyqGRuzHoBj39tqCDhsELoZh2450v5aOjdFLO+cyQx5eqGh6 yRuLlSQWZX7cbWHBFn2luzZioF/6v60jnsTY5B24Iz7Q80dYkW0MZpG8SC62pmx/aAsg yi4gJIFi5NsmyRA76o+YyDAwXvjDcXNM36RP5ISVDUBtx3Jk2Pyl+U6fk1EBCbDUSU7T aAk30263EPUA8L4a29mcJIHXsHYr7/SetbHQZHFlzjPXdrIm6Iknow+MLVeLiuTN5RRG OoBy9BnUZ0BafQQKK6nRFu4gESZsoNlKK9YkMz9dVgp4MjO5Gw/9rwdByCCuyBGpkmKq zIEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793177937; x=1793782737; 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=tsn6W+xGHU1NREbN8EiTgjzU96Ug5ZpjuHZgSoxPCxI=; b=tISAq8A2nGcNOuQNrU51aRd2aStCMgM7Cs2OZpeC6tTJ+dXD5UsWYmEnP13aj//Hqd +ZTU0pXTJq0NcxIKg/FGAh+kKZrQu9OhJdi5Qer70ShWlw34DdIvmXqKdYHHw7ljemWQ QWPTGdNAClxufHf/c0Cq2N7PzOT56fvGTQ5yE/qjLEz08JN6h+STY+m9jqCPlKZsqCbl +gzyvCfHfbAJzcd1NFCR+LHL2q5WHPWKSFg4lRVhwn0IsVCJlWPDgOfWQRmKAurB10zM KSVUHX+6zDV21EM19RhC6JM5HD85OC9fdn1WI9AoC1Hj0avtppDrV+FSOTlVkkz0zBmM CSuw== X-Forwarded-Encrypted: i=1; AKwUvByrXNr6FAMi5KB/Q3hMKcuCFI29QldXQJ+YCRQCNvoxvuA0jkrJwiVHyiVLKlwA2fB5LFxPTJWchEE=@lists.xenproject.org X-Gm-Message-State: AFq9FYK8sXZDK2tvhY/Rlctc4iHJM/QYC63c/flpCp3fJR35fpEm4VHn xomcyRfNUi217fDcbEHx5QhwzXykrHMJ93X7yzgnvCyjTrcUg2jhHX3LgNFMOuaAQA== X-Gm-Gg: AYBFou2kIx1oKHj6zrbM9hisUus8QCqpuKqjqcRaqh/m8zdLdZMxJ9/Aoq7Lqd4O1qf lJe4/GbnFL/JcYMvouQLftYGv1LJsUq8k0lAD2d6h2+73NBIEOv6/fKhahkQaMKQWYYQwCAiEJB vJGeP2pp/w83VIKDwk8Q4jOOBSaFiikIjgN8Cx2raIC22Zl4w1IIetVIILyjhDlt1Olv4cY4Mei bHz1b84sib25OU2ElloBA57Oq6LSTCQCWqGc1vM5FupInlb/opG0Rp6gJKD2bpodEyk6Yx1wy0l TCqwbijx52pZm4kFKUh2UbqBsopeKMWoABYLIkX802mMHU/QOlQuwhVjTpXRs0i88OGCv7Dbp6p U0DQc9QLE0r0QK8290YwlRi3LuTtf9Negiw0XmUxFVp8gs/w0vaSBPOxAKTv0DydbVjuL1fN/OD xyvX1euPZ0XPK8Y5OtZq7mO7YNep8YeHj/yd/9gfHs/QSHkr+IyWgMnXI+IAsUPBPZCaV9ocThP tdv1k5/PFLOVnvIKsH+pFjojnfBjdkzptITAzj9KKElcm67OxQsiBPh37jYr/4Rfe52JtAl9mqm XcrO9qnrPAKQOJBXSKMDwUHHi3xPi2IanFcwY9V+Q/5wf2ScefByhibBtIHMlLxkkgO5G8lJCTu GNxmWNTWkv2kIVW4+ X-Received: by 2002:a05:6000:606:b0:488:5852:6ee3 with SMTP id ffacd0b85a97d-48e5d5c41c9mr3717447f8f.34.1793177937552; Wed, 28 Oct 2026 01:58:57 -0700 (PDT) Message-ID: <96fdb610-65a7-451a-8d3b-600dfcd7ca8a@suse.com> Date: Wed, 28 Oct 2026 09:58:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code To: Mykyta Poturai Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand , "xen-devel@lists.xenproject.org" References: <8b2fa10a-17ac-4807-b9d2-874f84a85efc@suse.com> <97a123f8-92e8-4ff8-bb3b-a48ad2fe1392@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/1793177938-50EDEB50-8519360F/10/78276251493 X-purgate-type: spam X-purgate-size: 1569 On 28.10.2026 09:43, Mykyta Poturai wrote: > On 10/27/26 12:21 PM, Jan Beulich wrote: >> On 27.10.2026 10:39, Mykyta Poturai wrote: >>> On 10/26/26 2:34 PM, Jan Beulich wrote: >>>> On 26.10.2026 13:27, Mykyta Poturai wrote: >>>>> This is preparatory work to make vPCI MSI-X functional on Arm. Split the >>>>> vPCI MSI-X code so that intercepting the MSI-X table and PBA stays x86 >>>>> only, >>>> >>>> This likely is related to peculiarities of Arm's interrupt handling, yet >>>> on the surface I can't see why not intercepting MSI-X table accesses >>>> would be safe. Would it be possible to extend background here a little? >>> >>> On Arm most of the work is done by the ITS, so the only thing the device >>> needs to write to the doorbell register is the EventID. Interrupt >>> translation is fully configured in the ITS; it will reject invalid >>> EventIDs and also has a sideband DeviceID, so misconfigured devices >>> cannot trigger each other's interrupts. Memory-wise everything is gated >>> by the IOMMU, so a wrong doorbell address would not pose any risk either. >> >> And a guest fiddling with the mask bits behind Xen's back isn't a problem >> either? > > No. Masking/unmasking an interrupt the guest has already mapped is just > the guest doing its own configuration. Unmasking an unmapped interrupt > will result in it being discarded by the ITS. So I don't see a problem > here either. IOW unlike on x86, on Arm Xen never has a need to (transiently) mask an interrupt that the guest wants / considers unmasked? Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 09:25:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 09:25:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462966.1673940 (Exim 4.92) (envelope-from ) id 1xLzue-0003aW-2t; Wed, 28 Oct 2026 09:25:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462966.1673940; Wed, 28 Oct 2026 09:25: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 1xLzue-0003aP-05; Wed, 28 Oct 2026 09:25:40 +0000 Received: by outflank-mailman (input) for mailman id 1462966; Wed, 28 Oct 2026 09:25:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xLzuc-0003aJ-8K for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:25:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLzub-006x14-LJ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:25:37 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1bf87-bab6-0a2a0a5309dd-0a2a450a9f28-30 for ; Wed, 28 Oct 2026 10:25:37 +0100 Received: from [52.101.65.108] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1bf91-f2d2-0a2a450a0019-3465416c1710-3 for ; Wed, 28 Oct 2026 10:25:37 +0100 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com (2603:10a6:20b:5fb::5) by GV2PR03MB10950.eurprd03.prod.outlook.com (2603:10a6:150:278::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 09:25:29 +0000 Received: from AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c]) by AS2PR03MB9076.eurprd03.prod.outlook.com ([fe80::bfe6:8f84:2f09:349c%3]) with mapi id 15.21.0569.007; Wed, 28 Oct 2026 09:25: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=FhASpQ24lVmgldzY+WZLTCliob+7FWLqA0nIjq/Ui2FepYUTS+HyhclIbGh1nbjvbc5MMWGWYYBThuOlIWj978ezTnS9kGmdeJcDwCvSYViH+Xtp46rvLVMteI7Ca2MlZrJZ4ZO5MoxmnlprFlDBpGJRGGeED86SniXklHds2aj7xMvQlg357K8PcoBya9ChUA4opArV3jTxz0GQl3owMeJxfWoU3/tOeMFI4++gGtRoBvROY7iwR/dJLbEznq5xfa6L/f6td5N4pkGUGPiIOn6msLZcc259LsgOs7Civtu2605+ODsmswni5mK/6J7CvXawxzr8Cib12quY5F/F3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OYoOgMzGNYQf6XwSwHwBRjorRuWKIs+9cKXNfnqG658=; b=DNpjbOIrNWa61y30lRcGZ6iyv/lC12jMg3P7mF/nrwFma+a4ljFiaAgVblyetqRGY19bt4v/8fX25ODFkLOXGolnSlZ/dHIfg7xCPiO9B+QbhdPD9DZNyZqAx27e7CkBc+pLjWQhowqOD5ambrF9/mhJ6GBNZm621lMydJ2/nXa8XW9EefG4l7TB4I6oRzrYtWYroca8d79ZybxYRQtW9/hxeHl3nH+bYWmTnqY1uEDKnNpIfd0qcVuoshDndH4W7oiJKf86FZQoPbLppoLXRede5rc/REp1ErOREGY0WRIPcsc/iDwFNjnzEcH7a+zIIHzwBegzhxGgDJTJ8hpeRA== 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=OYoOgMzGNYQf6XwSwHwBRjorRuWKIs+9cKXNfnqG658=; b=F45JSyuUyr6WNwOBSWr0Qz2JUaAPk86jp3S969LZdMPxYv3aBNw4RRvyQKUgeVTfTLEs+9pQnO+G4l3SLZrHe7eWuZx26T5t0Q83G2RLTZ27koLJO+8XtHOhJXgdapW5CrzvX8yZjsuOLqi0Lccq5V6uBIaO2tWrbDqnh9xvGFlCxWRJmA92EKBFMX2bWDhCBynnhJw+KF5hDVN8L4u5Vs0s+opvTvtwONlI7vyZKpDBoxWUnicHScYxQp0h1pU/EYuKlxrIi+wujOly5BCpAZcR7puzibM8aTRyJtAC7iWWK5O2DVUFOcPsX9VSCKhAwDEJO64vnuUrS5hZc6VBvA== From: Mykyta Poturai To: Jan Beulich CC: Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Stewart Hildebrand , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Topic: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code Thread-Index: AQHdZUVvbuj2+I/wmEeMfHolzOWTxrcPwg+AgAFhaACAAAvYAIABdxSAgAAEMgCAAAdpgA== Date: Wed, 28 Oct 2026 09:25:29 +0000 Message-ID: <38abd62c-12b7-4441-ae0f-f2504bf8fadd@epam.com> References: <8b2fa10a-17ac-4807-b9d2-874f84a85efc@suse.com> <97a123f8-92e8-4ff8-bb3b-a48ad2fe1392@suse.com> <96fdb610-65a7-451a-8d3b-600dfcd7ca8a@suse.com> In-Reply-To: <96fdb610-65a7-451a-8d3b-600dfcd7ca8a@suse.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: AS2PR03MB9076:EE_|GV2PR03MB10950:EE_ x-ms-office365-filtering-correlation-id: a362b397-665b-48f4-4d82-08df34d56845 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|23010399003|261021121427099003|261022075727099003|10067099003|261022105027099003|56012099006|261026121527099003|6133799003|18002099003|22082099003|11063799006|4143699003|5023799004|261026140227099003|38070700021; x-microsoft-antispam-message-info: G4PEb8cPAH7A9xIgP308ac5gFxTrG2vGfIrr6XF2zdp6HgsTDorrFVi1FLbZOpJLmGPJ9hUNRx2u5Q39gmYEF+owdgIFCTTBDHImL//4bW5xft+JGCrgALQAT93mD8uwyRTP5G5TmwR7DegBv2MESvW2hwAOtpGgCnAaM4T3y5O0sNjJWaAJgWRg2LhPITXQ2rvSqilcj433qF7QpkG7TpYv5InYGyq8kGhMxa6F2i8ZLVEmGN0Xj5FjS8KRw0z7Spg/NXKiOmpZyZ2TEhoI0PnZiUuNzyx4A2Bm8YAL9rp2DjkaEhuClvbn2HAmpEOyjZMv8Tp6lE8KOudC0JfNzbP8RA0i/b03Rq8bC0LSzO6aG8NvLd95avt15obLQulQriFjuRKXrQ+/9xDW2L1hyt58N9m+kDa9qK7qCntRCZOlPjtkZtjKBrpQKO08RpS/etKLc2jOMIuIpgzgeU6bHrJULLUhPKT/ybpsgOLk35tGtoXJ1RReiNOeEwT3TP+mPRR73q754vHIsnqy5lEDcpVduRYba4TPFiblSDYdKXYd+xojFxfkZJaGwa9gPbNZkemMv0hLgZYC5zpWoMVqMoN40NuuQ4cduzuQ1T0DJCIFe6FxfRqET/++EWRwGu/6kU0Hg6M4AArktQCk3icCU6RgwDVrGctfQNglvf2VDym7wA1JGU4ruHas59jAxKoRCddSUDGIeYbJJxwmW/Cy0ieXiGu7FOpV6BMTA/l57g8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9076.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(23010399003)(261021121427099003)(261022075727099003)(10067099003)(261022105027099003)(56012099006)(261026121527099003)(6133799003)(18002099003)(22082099003)(11063799006)(4143699003)(5023799004)(261026140227099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NzVrRHpLdXV4S0Q0ZE1pbmhvUURhUVZnYkMxa2Ewc0JkT0IyRkl1Wkpta1dC?= =?utf-8?B?c0t6ZXQ2Qk41SkY5YUE3bmxORFlVcGFXR1dPOFllZVVXRlVkdFIwRFRYKzJG?= =?utf-8?B?YXJ5S200SHVLQU5wVGM0MUk3UEtrM2R6eUtpZ05aZ0ViT0ZmWFpQSWQvWUxC?= =?utf-8?B?VUdmWVE1MjlZeHJiQ1lOd0tLTzJibFBnSDVPNDV5UWRQRjdnbEFFTDZzd2gx?= =?utf-8?B?dkdkcjZFcDhWNjVKSDJienBLRmVXN01PcWkvTy96UzVNQ25hUUtRNTFKOGd0?= =?utf-8?B?cUh1UlpPWDZXdmFUanpkU1BsdG4wTzRMOGxNcEI3TWVLbjgrdnlRTE94MkVD?= =?utf-8?B?MzFDRXhTM0ZlMDg4VjZCNnc3K29aMTBZZ2pQY00rd3p5VG9OU0dGTE9TbEVw?= =?utf-8?B?SVFGaDI4WlNNbUlVMUpxWW0rOXllWGRXQWJiMC9FNkhIRnVpVDQzRkc4WVF6?= =?utf-8?B?bGNqanZVT0wvN0pIVm9nRkplWkcrY0FLaHFjM1YzZGZqZGN3ZG95QkFnZ3R6?= =?utf-8?B?citFd2xzb2srSjgzaUNtNFk4R1RHSGFXWDgzdjRFcjVsU1lXRWJwcnE5RkhU?= =?utf-8?B?K3paTUsrUFJaZ1dQVVdBSTVFVWVWRlFkdGFwcHZNdTQreldPbXdSRWFLM0E5?= =?utf-8?B?elN5YUJHd09VK0drdzBFdk5ZTERKbnEvN2FzQm5pNktSbkJQRVY5OHlTSDI4?= =?utf-8?B?M1NDdm50QTFKN2tTdWtJekdqMFhJdFJ6bFJaZ0xCak9XY0diRVdhano3TGFa?= =?utf-8?B?bGE3bExMZFphakFKQ0FIUjNzWE9pa1BHV2ZTNXpBb3VNMG03eGpDN2VRYjlZ?= =?utf-8?B?T0FSbDJ6L2JiNUQ0T3hKQWw1V2h2UXFjZ003TzhGSFVEd1QyMU5RY2tRQnhk?= =?utf-8?B?Qy80T0kydHJqRHdXNlBKeWhwcGtHMWlEYjRac3JzcjZXMCtITjFCa3ZhVzBD?= =?utf-8?B?bGM3YzRhY2dkTjNBZTlheU9NZDdmMngwcFRJUGRsMnUwalBLQkVzMmNIVmlw?= =?utf-8?B?V2VpYXVaQlczMkdCY0hVd1hiVElZMGdKMjhJNnlOOVkrU1VmSWhMaGRzc3hV?= =?utf-8?B?QXdtQW5Pc0p0TkV0eGNDdUJxdE9BSEx0RWxicFIyOS9SeEJtMjRKOURxZTFi?= =?utf-8?B?dTdKZnFqN2J0N21acHlIVG1veHAzWm0wTlk5T0lvOWRPSjNiemVBVmlQdVMx?= =?utf-8?B?dVBZOXd6emFMQmtFWnlZWWxJT1QxUzJENnBJS0tkWWVudjY1cVZsOGkxVkxw?= =?utf-8?B?OVVWbEZVUU05SGsveE9CVFlQdW55dmtDN0xPSzZwb2pVRWExK0JIYktob1F3?= =?utf-8?B?dlhJV1A5VFpFZENXTTRmNU1temZ0dDREYUdMNXpDemhVTGNxU3lPdVV3YzZD?= =?utf-8?B?L0lKeXMrMS9Qd1BuOVVueGhNN0RUejBQb1lhL2oxSkpvOW13MENVcHZQZnlh?= =?utf-8?B?SElFcEd3TkxKeTNhS0l3UFhYeGpuRHV2amQxaXAyVG02V0djbjBLdUR6WUJa?= =?utf-8?B?aHdPL2FVdUgzVkhybXdyZFlCQXZZQjEwdUVhY000bk50MkRrZFJrRHJFUDVG?= =?utf-8?B?bUYwSWJVaW8xM1liUkpvQU9CdEFSVzdMT1AzNzVHZHVRSUVqSkNQUDlYeGhN?= =?utf-8?B?Q053bnE1WndKRk9UbXVmRUY1aVBSYkpIZHFuOWtzdXlpZks3cmVmRUxCUW56?= =?utf-8?B?clM1TWIyVTM0OWhRQ2Rva2lQekVDNE92Mng2RnRiTC81QlJCUkxwT2c4U20w?= =?utf-8?B?d3VmaE1WZnBhWHNsVHEwbFd4VC9yYi96R0FRTFJQMzF1MXBYcm9PdXFaU0Ju?= =?utf-8?B?STRWcFl5SUQvczAxc0JsUGtRR2hYd3VqL05OanpXM3RqZUNLbzJBYnEzWHkr?= =?utf-8?B?S1oxUXNNWmw5Q0RMRDJDS2hicGpNN2tNMmQvekl3Y2orWnlFeDljY3N4cFR1?= =?utf-8?B?aXYxQnhkTVE1c3ZEcFllUVc4VGJWUHdKYmhGTm00Q2IrTHJZRk1WYVg2ZG9p?= =?utf-8?B?WTdhREZSWTNKa25lbWUwOUVkSlhWZHJyUzNndnE3VHRCWWp2VFRMRTdmcmd0?= =?utf-8?B?cWNGSEt0Z1JvYmVkZk50UFNYbjhxYStNeFFpam5JS21WZkFjZHlUVC9PYytm?= =?utf-8?B?NVp3cThCUFIxN3NnWHZvNlZmRzZtRjJkTlM3dXR1Z3k0YnFnMERIRjcxam1N?= =?utf-8?B?TGFBY3lKZ0xPTWVqWGdZa0hWOFpxVzBSbUVVU3ArODR2SEhKclF1Q3lCK3Na?= =?utf-8?B?K0poc2RRQytoTUJ6QTIzRHRQNjlVbitub0hrVTU3Zy85ajZFRlRsYTVKSXdY?= =?utf-8?B?RjVBeTF0Vk1tUmNDcVRob1RPc3Y5TjAzeC9sY2pDQ2dIRTVHOUUvTFdzMVY4?= =?utf-8?Q?pHD6V6zHnowTBCDQ=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <10D93A4BF42E0443B09C9447C8A6A5ED@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: AS2PR03MB9076.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a362b397-665b-48f4-4d82-08df34d56845 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2026 09:25:29.1736 (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: HCeOZrLPFYJl0koRV2JWkGbahnGSNqdYehdD1VciwSEErUbubf+M1rRdizj6+8yjEfU2p5B9hLXZJ3bUHrwKTA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10950 X-purgate-ID: tlsNG-4011c0/1793179537-508CDCFC-4EA5CBAE/0/0 X-purgate-type: clean X-purgate-size: 2558 T24gMTAvMjgvMjYgMTA6NTggQU0sIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyOC4xMC4yMDI2 IDA5OjQzLCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+IE9uIDEwLzI3LzI2IDEyOjIxIFBNLCBK YW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAyNy4xMC4yMDI2IDEwOjM5LCBNeWt5dGEgUG90dXJh aSB3cm90ZToNCj4+Pj4gT24gMTAvMjYvMjYgMjozNCBQTSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+ Pj4+PiBPbiAyNi4xMC4yMDI2IDEzOjI3LCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+Pj4+PiBU aGlzIGlzIHByZXBhcmF0b3J5IHdvcmsgdG8gbWFrZSB2UENJIE1TSS1YIGZ1bmN0aW9uYWwgb24g QXJtLiBTcGxpdCB0aGUNCj4+Pj4+PiB2UENJIE1TSS1YIGNvZGUgc28gdGhhdCBpbnRlcmNlcHRp bmcgdGhlIE1TSS1YIHRhYmxlIGFuZCBQQkEgc3RheXMgeDg2DQo+Pj4+Pj4gb25seSwNCj4+Pj4+ DQo+Pj4+PiBUaGlzIGxpa2VseSBpcyByZWxhdGVkIHRvIHBlY3VsaWFyaXRpZXMgb2YgQXJtJ3Mg aW50ZXJydXB0IGhhbmRsaW5nLCB5ZXQNCj4+Pj4+IG9uIHRoZSBzdXJmYWNlIEkgY2FuJ3Qgc2Vl IHdoeSBub3QgaW50ZXJjZXB0aW5nIE1TSS1YIHRhYmxlIGFjY2Vzc2VzDQo+Pj4+PiB3b3VsZCBi ZSBzYWZlLiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBleHRlbmQgYmFja2dyb3VuZCBoZXJlIGEg bGl0dGxlPw0KPj4+Pg0KPj4+PiBPbiBBcm0gbW9zdCBvZiB0aGUgd29yayBpcyBkb25lIGJ5IHRo ZSBJVFMsIHNvIHRoZSBvbmx5IHRoaW5nIHRoZSBkZXZpY2UNCj4+Pj4gbmVlZHMgdG8gd3JpdGUg dG8gdGhlIGRvb3JiZWxsIHJlZ2lzdGVyIGlzIHRoZSBFdmVudElELiBJbnRlcnJ1cHQNCj4+Pj4g dHJhbnNsYXRpb24gaXMgZnVsbHkgY29uZmlndXJlZCBpbiB0aGUgSVRTOyBpdCB3aWxsIHJlamVj dCBpbnZhbGlkDQo+Pj4+IEV2ZW50SURzIGFuZCBhbHNvIGhhcyBhIHNpZGViYW5kIERldmljZUlE LCBzbyBtaXNjb25maWd1cmVkIGRldmljZXMNCj4+Pj4gY2Fubm90IHRyaWdnZXIgZWFjaCBvdGhl cidzIGludGVycnVwdHMuIE1lbW9yeS13aXNlIGV2ZXJ5dGhpbmcgaXMgZ2F0ZWQNCj4+Pj4gYnkg dGhlIElPTU1VLCBzbyBhIHdyb25nIGRvb3JiZWxsIGFkZHJlc3Mgd291bGQgbm90IHBvc2UgYW55 IHJpc2sgZWl0aGVyLg0KPj4+DQo+Pj4gQW5kIGEgZ3Vlc3QgZmlkZGxpbmcgd2l0aCB0aGUgbWFz ayBiaXRzIGJlaGluZCBYZW4ncyBiYWNrIGlzbid0IGEgcHJvYmxlbQ0KPj4+IGVpdGhlcj8NCj4+ DQo+PiBOby4gTWFza2luZy91bm1hc2tpbmcgYW4gaW50ZXJydXB0IHRoZSBndWVzdCBoYXMgYWxy ZWFkeSBtYXBwZWQgaXMganVzdA0KPj4gdGhlIGd1ZXN0IGRvaW5nIGl0cyBvd24gY29uZmlndXJh dGlvbi4gVW5tYXNraW5nIGFuIHVubWFwcGVkIGludGVycnVwdA0KPj4gd2lsbCByZXN1bHQgaW4g aXQgYmVpbmcgZGlzY2FyZGVkIGJ5IHRoZSBJVFMuIFNvIEkgZG9uJ3Qgc2VlIGEgcHJvYmxlbQ0K Pj4gaGVyZSBlaXRoZXIuDQo+IA0KPiBJT1cgdW5saWtlIG9uIHg4Niwgb24gQXJtIFhlbiBuZXZl ciBoYXMgYSBuZWVkIHRvICh0cmFuc2llbnRseSkgbWFzayBhbg0KPiBpbnRlcnJ1cHQgdGhhdCB0 aGUgZ3Vlc3Qgd2FudHMgLyBjb25zaWRlcnMgdW5tYXNrZWQ/DQoNCldoZW4gc3VjaCBhIG5lZWQg YXJpc2VzLCB0aGUgaW50ZXJydXB0IGNhbiBhbmQgc2hvdWxkIGJlIG1hc2tlZCBpbiB0aGUgDQpJ VFMuIE9uIEFybSB0aGUgTVNJLVggZW50cnkgY2FycmllcyBhbG1vc3Qgbm90aGluZyAtIGV2ZXJ5 dGhpbmcgcmVsYXRlZCANCnRvIHJvdXRpbmcsIG1hcHBpbmcgYW5kIG1hc2tpbmcgaXMgZG9uZSBp biB0aGUgSVRTLCB3aGljaCBYZW4gd2lsbCBmdWxseSANCmVtdWxhdGUuDQo= From xen-devel-bounces@lists.xenproject.org Wed Oct 28 09:25:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 09:25:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462968.1673950 (Exim 4.92) (envelope-from ) id 1xLzux-0003s5-Fu; Wed, 28 Oct 2026 09:25:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462968.1673950; Wed, 28 Oct 2026 09:25: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 1xLzux-0003rs-CN; Wed, 28 Oct 2026 09:25:59 +0000 Received: by outflank-mailman (input) for mailman id 1462968; Wed, 28 Oct 2026 09:25:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xLzuv-0003rM-Pf for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:25:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xLzuv-00BrMd-6O for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:25:57 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1bf9c-e002-0a2a0a5209dd-0a2a4509c520-24 for ; Wed, 28 Oct 2026 10:25:57 +0100 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 6ae1bfa5-be1a-0a2a45090019-d155dd35c0e6-3 for ; Wed, 28 Oct 2026 10:25:57 +0100 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48b042c0759so358152f8f.2 for ; Wed, 28 Oct 2026 02:25:57 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ecde7easm27654763f8f.52.2026.10.28.02.25.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 02:25: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=20260707 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=20260707; t=1793179556; x=1793784356; 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=qpjsJfmEnvi5N8ny2PiQ2ixCH2oXxQx9GVyNqdWZSuM=; b=AmRj7Al14urr7d8ndyeOtNQ+8I4Lap9CXEIAO20jg6X/IewqMs7cg5D4LBs3qYkuIO HCYBIA749hmhk4RmZuUz9ybzPSUC1hKjfV0AsTKQR5t27jyCOlUB7gYJs1FrD3TFA3Un XZ4gxOLIhY01v3vLUVMuJOyfYWJpTOeDMN2ALn1WfAbrZCuZo5Ijdcu3L+uIwhrH1Pi/ tXChYz5C7Zk4pOX9lzfSODMZWkxJzPCcONV1iTYz2CnYAQiEM/6uirRf1i6yS37mU2OM wmXp/EKIAxYT+x0w6+79tvO8qvR4zhRhBHZ2SSRkO0cpJ96QakhxSfRYPgP9yGW7XZ73 1HyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793179556; x=1793784356; 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=qpjsJfmEnvi5N8ny2PiQ2ixCH2oXxQx9GVyNqdWZSuM=; b=FLb9US2VHEXglTIMyv2CVgzo1ZwPotRURZNZO/5y5Woff1uw9WGSYMQNLy4aY3l8/t RZvYBC6H8asKJv0msyZ9q9mDYb1xAG1RaiWLvqmnTBj+o3FlFZ4Fq1Jxlec/skieoKCz InjIoVXQUIIAaIh7jlNrdU9VWlEHTrFw6rTf3z5jpid/YPSOoKI5UkkhnP4vo46jwE3N t8gUaq9EqjRd00v1yN16hIJksqlnZzJ8aNiuM2CRWnZu1BlVpIDf+A0+9MnEyff3zKXP HPFwntsnYjUD7SWzJZBL3vrjZwga7/AtxlXz5HC84mroUx2YVzDB8eBwLOdW8dUJEq+w XQng== X-Forwarded-Encrypted: i=1; AKwUvBy54/VbHsKtnvx3I48xg1Go4J0+25txD7RQ+suQD01eCNGNIRkf2qgo7WUMTNVGw5vjvGwEqNKuInE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJBzvrV1dgMClA6JOlt3qlvtczaVFB5gbFgoZQWfGYxzcSCIebA DmDT0czJKX1wMN9iL7xjm4RwXByBZLw3ewR9dB0X61JgsPU6cAWL5zwB X-Gm-Gg: AYBFou1Xz6c+9osVc1X2mwZtqxD+3dLkRLrnvSgLhmufp07m2EdB/1C6QBY8BnCMwfc ugq3wGf6jmds9bLG1yyxwLRhiNJPGkWbx+Bi0kdfz43grNIqlzGUy2hTo3yWngoub/GIpVba9kA QMoOO6NCj8DdM3rfOt5dc+4R+5LdUSykGYzmIuzCS8FX+SRbzp/bgS1mpK6+9wuklISnck//Jgq uWdnH79zjzMogunmr+2vQ6vvceiF/d6rpdH93a1ywRKB1wV6+4/Z4943nNkxZfSp4dS8SxPiHBw kyYlGsvT9b7kcPhszN33dIm1+j7BpxHd7ABzBYLylYbzLN9AiykwDTEN53p8RdZyCBc5ixPqh+v 6ZlanA2bhAUXdpsE8BNTUvjoUG0xLIcWcjhsU/fO9T3wlRSlTQNFH7mUdQcE3pCaQOiNObajJc3 qVxgxTPn36wuqJRfTruLhRZxvu7BJdRzKv3mGYxgH97gDW6pQ4QjCoEawxcuLuRjoRCAXZRe6rm vRQS+0W8Z7NQBGFPL9UXdigjWWVNVEbqICqA4Etl0Bh3eeaiDKTz1GafVbyM3+Rd1GaWFY9p6Ch RyADTTZhiyKZhw0JPx2HZOZ0F1j4d9C3xo4WPugJN9sZfwLRjy712A5IvlhwM4N1hd33mEiqlFx yhQ== X-Received: by 2002:a5d:5f84:0:b0:48b:1a0:5630 with SMTP id ffacd0b85a97d-48e5d3063b6mr4745770f8f.41.1793179556506; Wed, 28 Oct 2026 02:25:56 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 10:25:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f@vates.tech> <1793099133.8631fc262581453bbf619ec5b2062170.1a17d0971ae000f79f@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1793099133.8631fc262581453bbf619ec5b2062170.1a17d0971ae000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1793179557-FC817034-E66562EA/10/73395122804 X-purgate-type: spam X-purgate-size: 4109 On 10/27/26 12:05 PM, Baptiste Le Duc wrote: [...] > +/* > + * Probe whether hardware updates the PTE A/D bits by reading through an alias > + * mapping whose A and D bits are clear. Observing A set, even by a speculative > + * access, implies Svadu, as Svade only allows A to be set by software. > + * > + * Under Svade, the read raises a page fault instead, so use the extable to > + * handle it. > + */ > +static bool __init probe_hw_ad_update(void) > +{ > + vaddr_t va = FIXMAP_ADDR(FIX_MISC); > + pte_t *entry = &xen_fixmap[FIX_MISC]; > + bool a_set = false; > + > + ASSERT(!pte_is_valid(*entry)); > + > + /* > + * Any mapped page will do, as the alias is read-only, so alias the first > + * page of the Xen image, with A and D clear. > + */ > + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(_start)), > + PTE_VALID | PTE_READABLE)); fixmap.h asks for xen_fixmap[] to be accessed directly only when set_fixmap() is unusable. It is unusable here, as pt_update_entry() always sets A and D, but I think the comment should say so. Otherwise someone may "clean this up" by switching to set_fixmap(), after which the probe silently always reports Svadu, and on a Svade platform G-stage PTEs are then created with A/D clear. The current comment also reads as if the page had to be mapped already, while what makes using the Xen image correct is that A and D belong to the PTE, not to the page, so those set in the Xen image mapping don't matter. Something like: /* * set_fixmap() can't be used, as pt_update_entry() always sets A and D. * * A and D belong to the PTE, not to the page, so a new PTE with A and D * clear can point to any RAM page, whatever its other mappings. Use the * first page of the Xen image, and map it read-only so that Xen can't be * corrupted through this alias. */ I am okay to go with how the comment is written now and apply my suggestion only in the case if v10 will be needed (and likely it will look at the comment about fence below) > + flush_tlb_one_local(va); > + > + asm_inline goto ( > + "1: lw zero, 0(%[va])\n" > + ASM_EXTABLE(1b, %l[out]) > + : > + : [va] "r" (va) > + : "memory" > + : out ); > + > + a_set = read_pte(entry).pte & PTE_ACCESSED; I think a fence is needed between the load and reading the PTE back. The spec only orders the A bit update against accesses to the same virtual page: "Furthermore, the PTE update must appear in the global memory order no later than the explicit memory access, or any subsequent explicit memory access to that virtual page by the local hart." read_pte() accesses a different virtual page, and RVWMO doesn't order two loads to different addresses, so on a hart which updates A/D in hardware read_pte() may still observe A clear. That fails safe (Svade gets recorded and A/D are preset), but the message below then asks to add the wrong extension to the DT, and an out-of-order core like the P550 is exactly where this could happen. Ordering the load before the PTE read is enough, as the A bit update is in turn ordered before the load: /* Order the load, hence its A bit update, before reading the PTE. */ RISCV_FENCE(r, r); a_set = read_pte(entry).pte & PTE_ACCESSED; > + > + out: > + write_pte(entry, (pte_t){}); > + flush_tlb_one_local(va); > + > + return a_set; > +} > + [...] I gave it a try on QEMU 9.0 on top of current staging (virt with aia=aplic-imsic, all with svpbmt=on): - default (svadu): the probe doesn't run; - svadu=off (hardware updating, neither in the DT): "probed svadu"; - svadu=off,svade=on with "_svade" dropped from riscv,isa: the load faults, the extable fixup works, "probed svade"; - svadu=off,svade=on: the probe doesn't run. All of them reach "All set up" so: Tested-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 28 09:38:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 09:38:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462984.1673958 (Exim 4.92) (envelope-from ) id 1xM07B-0006B1-GL; Wed, 28 Oct 2026 09:38:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462984.1673958; Wed, 28 Oct 2026 09:38: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 1xM07B-0006As-De; Wed, 28 Oct 2026 09:38:37 +0000 Received: by outflank-mailman (input) for mailman id 1462984; Wed, 28 Oct 2026 09:38:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM078-00069U-WD for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:38:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM078-009Tts-4w for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:38:34 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1c28e-bab6-0a2a0a5309dd-0a2a4502bc08-42 for ; Wed, 28 Oct 2026 10:38:33 +0100 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 6ae1c299-6ca4-0a2a45020019-b9ff1c128959-3 for ; Wed, 28 Oct 2026 10:38:33 +0100 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 1a181e021b2000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 09:38:31 +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 0CB6F81D19; Wed, 28 Oct 2026 10:38:31 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=PPf7A+aEfn7JkqvA4t57I1tJGRIJz2np38/i7rFYbAE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=TWbpOjnrwmr+3HWV3x4/mdvf+44vwYudnwrplhEqHJ7wDiHqks/13pUvsSg52+qd1IZXItfVm 39dyf/1vrTFEu4Xx8xzPW8vcTb2IqCS4XK00YXgvuR0O/vVCi98nF6/x65KYno9msxnqXvmxZlk 27Ja/xWjXBIhgFWsgVlsPOGMLytrzPeUggScmiaDfoyYDmC66ijfF5BnFWuA1FemV/ql+NxV7Uq i1FmHqi7dxSxaP+DujdTPiNYlt0X69PxWCZUeE/rmSLSowLilHmxv3U0Cx13/YDjMKhDej4Cw0Y HQqMHu/A1ZazP0R1Dfe2eBDTT4lrxuJaOpOXkEkd9H5g== X-Zone-Loop: e3d3afb166c0a788c4c5aa3dabd53eed17e7a8e02680 x-campaign-type: default x-transaction-id: 20c83a94-96c5-49cc-9797-b55f11fd46a9 x-swg-uid: 01-bd4ac6f4-ec93-4c31-afb6-0db54a37726e X-Mailer: Sweego Message-ID: <1793180312.8631fc262581453bbf619ec5b2062170.1a181e021b2000f79f@vates.tech> x-swg-bid: 1793180312.8631fc262581453bbf619ec5b2062170.1a181e021b2000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 10:38:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/9] tools/libs/guest: reject non-zero reserved fields in PAGE_DATA To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Jan Beulich References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-2-marcus.granado@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: <20261020200238.1815766-2-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Pc66tAo0acgYaobCTayKz733" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793180311224 X-purgate-ID: tlsNG-720697/1793180313-317CA2AC-22D868B3/0/0 X-purgate-type: clean X-purgate-size: 6952 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Pc66tAo0acgYaobCTayKz733 Content-Type: multipart/mixed; boundary="------------iRnwqgWgIP7gj3fLJW03EYqX"; protected-headers="v1"; hp="clear" Message-ID: <1cf0078f-e343-4bbb-b0f1-f6a317c48983@vates.tech> Date: Wed, 28 Oct 2026 10:38:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/9] tools/libs/guest: reject non-zero reserved fields in PAGE_DATA To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Jan Beulich References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-2-marcus.granado@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: <20261020200238.1815766-2-marcus.granado@citrix.com> --------------iRnwqgWgIP7gj3fLJW03EYqX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowNSwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g QSBQQUdFX0RBVEEgcmVjb3JkIGhhcyB0d28gcmVzZXJ2ZWQgZmllbGRzOiB0aGUgMzItYml0 IGZpZWxkIGFmdGVyDQo+IGNvdW50LCBhbmQgYml0cyA1OS01MiBvZiBlYWNoIHBmbiBlbnRy eS4gIGxpYnhlbmd1ZXN0IGlnbm9yZXMgYm90aCBvbg0KPiByZXN0b3JlLCBhcyB0aGUgc3Bl Y2lmaWNhdGlvbidzIGdlbmVyYWwgcnVsZSBmb3IgcmVzZXJ2ZWQgZmllbGRzDQo+IHJlcXVp cmVzLCB3aGlsZSB0aGUgUHl0aG9uIHN0cmVhbSB2YWxpZGF0b3INCj4gKHRvb2xzL3B5dGhv bi94ZW4vbWlncmF0aW9uL2xpYnhjLnB5KSByZWplY3RzIGJvdGguDQo+IA0KPiBBIHJlY2Vp dmVyIHdoaWNoIGlnbm9yZXMgZWl0aGVyIGZpZWxkIGNhbiBzaWxlbnRseSBtaXNyZWFkIGEg cmVjb3JkDQo+IHdoaWNoIHVzZXMgaXQgdG8gY2hhbmdlIGhvdyB0aGUgcmVjb3JkJ3MgY29u dGVudHMgYXJlIG9yZ2FuaXNlZC4NCj4gDQo+IFJlamVjdCBhIFBBR0VfREFUQSByZWNvcmQg d2l0aCBlaXRoZXIgZmllbGQgbm9uLXplcm8uICBRdWFsaWZ5IHRoZQ0KPiBzcGVjaWZpY2F0 aW9uJ3MgZ2VuZXJhbCBydWxlIHNvIHRoYXQgYSByZWNvcmQgY2FuIG92ZXJyaWRlIGl0LCBy ZXF1aXJlDQo+IHJlamVjdGlvbiBvZiBib3RoIHJlc2VydmVkIGZpZWxkcywgYW5kIGJ1bXAg dGhlIHNwZWNpZmljYXRpb24ncw0KPiByZXZpc2lvbi4NCj4gDQo+IFRoaXMgZGVsaWJlcmF0 ZWx5IHRpZ2h0ZW5zIHJlc3RvcmUuICBFdmVyeSBsaWJ4ZW5ndWVzdCBzaW5jZSBYZW4gNC42 LA0KPiBhbmQgY29udmVydC1sZWdhY3ktc3RyZWFtLCB3cml0ZXMgYm90aCBmaWVsZHMgYXMg emVybywgc28gbm8gc3RyZWFtDQo+IHRoZXkgcHJvZHVjZSBpcyByZWplY3RlZC4NCj4gDQo+ IEJhY2twb3J0OiA0LjE3Kw0KPiBSZXBvcnRlZC1ieTogVGVkZHkgQXN0aWUgPHRlZGR5LmFz dGllQHZhdGVzLnRlY2g+DQo+IEFzc2lzdGVkLWJ5OiBDbGF1ZGU6Y2xhdWRlLW9wdXMtNS01 DQo+IFNpZ25lZC1vZmYtYnk6IE1hcmN1cyBHcmFuYWRvIDxtYXJjdXMuZ3JhbmFkb0BjaXRy aXguY29tPg0KPiAtLS0NCj4gDQo+IE5vdGVzOg0KPiAgICAgIENoYW5nZXMgaW4gdjI6DQo+ ICAgICAgLSBOZXcgcGF0Y2gsIGFmdGVyIFRlZGR5IEFzdGllIHBvaW50ZWQgb3V0IG9uIHYx IHRoYXQgaWdub3JpbmcgcmVzZXJ2ZWQNCj4gICAgICAgIGZpZWxkcyBkb2VzIG5vdCBoZWxw IGEgZnV0dXJlIGZpZWxkIHdoaWNoIGNoYW5nZXMgaG93IHRoZSByZWNvcmQncw0KPiAgICAg ICAgY29udGVudHMgYXJlIG9yZ2FuaXNlZC4NCj4gDQo+ICAgZG9jcy9zcGVjcy9saWJ4Yy1t aWdyYXRpb24tc3RyZWFtLnBhbmRvYyB8IDExICsrKysrKysrLS0tDQo+ICAgdG9vbHMvbGli cy9ndWVzdC94Z19zcl9yZXN0b3JlLmMgICAgICAgICB8IDE1ICsrKysrKysrKysrKysrKw0K PiAgIHRvb2xzL2xpYnMvZ3Vlc3QveGdfc3Jfc3RyZWFtX2Zvcm1hdC5oICAgfCAgNSArKyst LQ0KPiAgIDMgZmlsZXMgY2hhbmdlZCwgMjYgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMo LSkNCj4gDQpSZXZpZXdlZC1ieTogVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRl Y2g+DQo= --------------iRnwqgWgIP7gj3fLJW03EYqX-- --------------Pc66tAo0acgYaobCTayKz733 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+p0QLLz9AFAmrhwpYFAwAAAAAACgkQZg+p0QLLz9C8 tgv+NxU21ESexyupIIDBcalitRb7HJdb/EPUmSf64VLSPHWiX4yVirQ43FDRjMn8FDHRvrbPhW69 sacnHqj/yCJaf2+oTBSvbcu1StxJoHACBurfWhXEk8O2//gHLU+rqZsRmZi7tGwYTGbtFnq1pQaB Nwrs0AKsTBVPOGWNg+nusQKiIp8lwtt2L0xxqSyfrYarmyMLYBbP79s8ocSyh20a4mB6FK8KpZUk 1tUL6PRfcfXCsRN0BtsjXXr0hQnwBH6Bto2GeGuuIJHxmvMdkvsa8bARdTUAoHKKQ2fKhTvoUhtE YRZUx8DeYrHwQ647G5rVyt5isZgasSM2gW/hvZ0HBX7MoaU081MwXUCEGf76wTHEAsqdJs+zTjb5 f7CcyKjE6/9Rhu/Z0sMb688JC25O/6dX2KFDI5Cbq9ydxfRHfvIniGMAQEFtVw8wTLu/hBlfalrR nfbz3/GdD8frRnit8XqGcSYMNHbUDrUXIv0KMfzJSYCjUZdJHQKxAVrFtK9u =N53G -----END PGP SIGNATURE----- --------------Pc66tAo0acgYaobCTayKz733-- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 09:48:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 09:48:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1462992.1673968 (Exim 4.92) (envelope-from ) id 1xM0GL-0007wB-AT; Wed, 28 Oct 2026 09:48:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1462992.1673968; Wed, 28 Oct 2026 09:48: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 1xM0GL-0007w4-7z; Wed, 28 Oct 2026 09:48:05 +0000 Received: by outflank-mailman (input) for mailman id 1462992; Wed, 28 Oct 2026 09:48:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM0GK-0007vl-84 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:48:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM0GJ-006O23-HW for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:48:03 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1c4c9-e002-0a2a0a5209dd-0a2a4505ecc8-26 for ; Wed, 28 Oct 2026 10:48:03 +0100 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 6ae1c4d3-4cb1-0a2a45050019-d155dd31ddfc-3 for ; Wed, 28 Oct 2026 10:48:03 +0100 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48e20edd106so569580f8f.1 for ; Wed, 28 Oct 2026 02:48: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-48e3ebd48e0sm27944912f8f.38.2026.10.28.02.48.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 02:48: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=1793180883; x=1793785683; 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=MIRvX8cIau+XDlHLuogFp15o/j+RYWBpn/8pySM2qvI=; b=VSk1ZZmKtf05X5K6PkkDqNBYc8uMXZvy5+anaOlpRqJ4hg3NJX/FHbK0xnJziGta4H eWeA8/+DpWhogvutGQ7w/Rkc36fZEEH7iyLcfGz5KM9s+V3V6Ebb3he92dSf2b3Q7cKa mxANwEiX1fnft/Q2C4ml/ERbtItLcaeiv0JIRHyEQZKh6MwFulKr5Mw/QlVjFDYfV4G0 +717/zs7N9xtIidhbla4Feb1NYvb7Mm1tzXEuN1QX3JaEP7d84hHTx6/4sKKzzTMu6Ax LR7NJY9xmK65F9eLgMu/t25lpJX/2QUcWOmrBOCUSXLEv/RmYwR+SNPjNk3UJoCu2c66 kB7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793180883; x=1793785683; 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=MIRvX8cIau+XDlHLuogFp15o/j+RYWBpn/8pySM2qvI=; b=nVhcgp2EFyNxSAt9ze9K6eOspwYxelSJExlyC27FitKU9rf/DoA0pmeuE7a3pNr5g3 myDjiURYFcZgH73nd+XmaPPIauRQWNyq7sky5Y0XIYGvzOQs1k7NkkIe5SqzmAjzlvNG wqg5ny2kkr94ZyLwsuWmzH0psJ69I3aOEymJHOEE1N58cgLJ7jSSgYxNoY/qqJ9WbDQ0 XdQo7UmqcjIABmEABOC2LI5SiXhRhLBQ3LXI2c7Bk2Z3jmlD+u3y8uxc4CtdFAGa5P0q 0Jwkn9p6Yo2zfRVBl2hQOma7RN6bxo0tEIer6zd4WEsKf4uqCQ1cTpoUOX6tnDvPozoX 5iQg== X-Forwarded-Encrypted: i=1; AKwUvBwq/wpQobAoy8KyqJ441HH2a1iHEulNkzMV7R5rNCuxdN61n6fScj+LAx+NJ4UnHcUVnylPHzDbFzk=@lists.xenproject.org X-Gm-Message-State: AFq9FYKzX6/VQ51xZO9jEK4hZQcyAQwEJQrmf0CCsbNfTtiYHI3IxOR5 kgDGD7n2NlCkLtOtA8rx65I+nieBz3W7nsxn38JtFlF2dEG9bqEx/wJqVQX8wJhEFQ== X-Gm-Gg: AYBFou2cDJHhkzq7GWufjH0iblDiLLool+Jb8UoEAdYBcUEOiBQJ/NwxzsvlGeRzQBL e1m6bhJHB/r7lR0qrmsWpzCEuM/BoxkXtE3yIfTMfOLyARGOpLFc9P659NwY5TbHa26S2ibafqQ yRR/sZLE4jl9jG1DY6vpKId2M5XqT6/KJR3H12SWh3eVFDzX9Jy9oUqpb4J5WASPyuClne3jdUS 1gySaIDY/EAAV+hPlNIGv+dgCQ0E0WPEV84uGOVyiG51QZOhxTuXc6KPciNCt+I1yfTpQhADKOB jC0dIjVm7mIxLsHR35WmR3C8K2jrdVsG7dSdogx+iRsN0WjT+wva+pp6kmfref7x1iwmFmJSCGf 94eEuyvNhrx/F1iBabSAMs3mNa3qJT8KjRqzjAIfFLHUry4DBiO3D0RhRb/VKWMf0DH06LdJlg8 SAkgdjDBc38OnnYfAMGUAo1mz80v5NycKVJpOyIIvgD4QA4CQ+BKulAXYHogPj00XKt+qUhLDvI UoDB9Ul/lkD9AuzICG3WytFPsV8YuVKdn655EPI7ejAw+29BxF7oPG6V9z29iqakLIt5Y/UdnW1 z3Y3TacSOO9yyOFfB1pPS3XCtuEFj9yzVhKSYRpqJjoUSuNC0JM1HhaRKbmITcIXr3Sh9Dvkvng LFqmzNUfPkQTFuYLVmya/E3Y6wU+IB9fdYDH3xg== X-Received: by 2002:a05:6000:2086:b0:48b:118e:7454 with SMTP id ffacd0b85a97d-48e5d5a45e2mr4074342f8f.31.1793180882489; Wed, 28 Oct 2026 02:48:02 -0700 (PDT) Message-ID: <998b084e-1a3f-4b51-bad3-4b175e6027a0@suse.com> Date: Wed, 28 Oct 2026 10:48:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/5] x86/emul: Introduce x86_decode_lite() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20261015210530.786604-1-andrew.cooper3@citrix.com> <20261015210530.786604-2-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: <20261015210530.786604-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793180883-24D1E2A1-3CD65039/10/78276251493 X-purgate-type: spam X-purgate-size: 9126 On 15.10.2026 23:05, Andrew Cooper wrote: > In order to relocate all IP-relative fields in an alternative replacement > block, we need to decode the instructions enough to obtain their length and > any relative fields. > > Full x86_decode() is far too heavyweight, so introduce a minimal form which > can make several simplifying assumptions. > > This a mostly-complete decoder for integer instruction in the onebyte and > twobyte maps. Some instructions are intentionally unrecognised, as finding > them in an alternative is more likely to be a bug than intentional. Some > instruction groups and prefixes are unimplemented to reduce decode complexity, > as this will be a fasthpath during patching. Just that patching isn't really something where performance matters very much. It's done during boot (or livepatch load), and then not anymore. (I still agree that reduction of complexity is a worthwhile goal, or course.) > --- /dev/null > +++ b/xen/arch/x86/x86_emulate/decode-lite.c > @@ -0,0 +1,331 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifdef __XEN__ > +# include > +#endif > + > +#include "private.h" > + > +#undef ModRM > + > +/* > + * Bare minimum x86 instruction decoder to parse the alternative replacement > + * instructions and locate the IP-relative references that may need updating. > + * > + * These are: > + * - disp8/32 from near direct branches > + * - RIP-relative memory references > + * > + * The following simplifications are used: > + * - All code is 64bit, the instruction stream is well formed and safe to > + * read. > + * - Instruction groups and prefixes not used by Xen's current alternatives > + * are not implemented in order to reduce the decode complexity. > + * - Certain instructions are intentionally not recognised, when it is more > + * likely for their presence to be an error than intentional. > + * > + * Inputs: > + * @ip The position to start decoding from. > + * @end End of the code block. Exceeding this is considered an error. > + * > + * Returns: x86_decode_lite_t > + * - On failure, length of 0. > + * - On success, length > 0. For rel_sz > 0, rel points at the relative > + * field in the instruction stream. > + */ > +x86_decode_lite_t init_or_livepatch x86_decode_lite(void *ip, const void *end) > +{ > +#define Imm8 (1 << 0) > +#define Imm (1 << 1) > +#define Moffs (1 << 2) > +#define Branch (1 << 5) /* Near direct branches, which have a displacement */ > +#define ModRM (1 << 6) > +#define Known (1 << 7) > + > + static const uint8_t init_or_livepatch_const onebyte[256] = { > + > +#define ALU_OPS(x) \ > + [(x) + 0] = (Known|ModRM), \ > + [(x) + 1] = (Known|ModRM), \ > + [(x) + 2] = (Known|ModRM), \ > + [(x) + 3] = (Known|ModRM), \ > + [(x) + 4] = (Known|Imm8), \ > + [(x) + 5] = (Known|Imm) > + > + ALU_OPS(0x00) /* ADD */, ALU_OPS(0x08) /* OR */, > + ALU_OPS(0x10) /* ADC */, ALU_OPS(0x18) /* SBB */, > + ALU_OPS(0x20) /* AND */, ALU_OPS(0x28) /* SUB */, > + ALU_OPS(0x30) /* XOR */, ALU_OPS(0x38) /* CMP */, > + > +#undef ALU_OPS > + > + [0x50 ... 0x5f] = (Known), /* PUSH/POP %reg */ > + > + [0x62] = 0, /* BOUND, but also EVEX prefix, not implemented. */ Given the purpose, BOUND isn't relevant here at all: We don't mean to use this decoder on 32- or 16-bit code. Hence I'd suggest to put emphasis on EVEX, and name BOUND secondarily. See how ... > + [0x63] = (Known|ModRM), /* MOVSxd */ ... here you don't mention ARPL at all. (Also - why xd in lower case?) > + [0x68] = (Known|Imm), /* PUSH $imm */ > + [0x69] = (Known|ModRM|Imm), /* IMUL $imm */ > + [0x6a] = (Known|Imm8), /* PUSH $imm8 */ > + [0x6b] = (Known|ModRM|Imm8), /* PUSH $imm8 */ > + [0x6c ... 0x6f] = (Known), /* INS/OUTS */ > + [0x70 ... 0x7f] = (Known|Branch|Imm8), /* Jcc disp8 */ > + [0x80] = (Known|ModRM|Imm8), /* Grp1 */ > + [0x81] = (Known|ModRM|Imm), /* Grp1 */ > + > + [0x83] = (Known|ModRM|Imm8), /* Grp1 */ > + [0x84 ... 0x8e] = (Known|ModRM), /* TEST/XCHG/MOV/MOV-SREG/LEA */ > + [0x8f] = 0, /* Grp1A - POP but also XOP prefix, not implemented. */ I continue thinking that the asymmetry between PUSH r/m and POP r/m being deliberate wants at least mentioning in the description. > + [0x90 ... 0x99] = (Known), /* NOP/XCHG %rAX/CLTQ/CQTO */ > + > + [0x9b ... 0x9f] = (Known), /* FWAIT/PUSHF/POPF/SAHF/LAHF */ > + [0xa0 ... 0xa3] = (Known|Moffs), /* MOVABS */ > + [0xa4 ... 0xa7] = (Known), /* MOVS/CMPS */ > + [0xa8] = (Known|Imm8), /* TEST %al */ > + [0xa9] = (Known|Imm), /* TEST %rAX */ > + [0xaa ... 0xaf] = (Known), /* STOS/LODS/SCAS */ > + [0xb0 ... 0xb7] = (Known|Imm8), /* MOV $imm8, %reg */ > + [0xb8 ... 0xbf] = (Known|Imm), /* MOV $imm{16,32,64}, %reg */ > + [0xc0 ... 0xc1] = (Known|ModRM|Imm8), /* Grp2 (ROL..SAR $imm8, %reg) */ > + > + [0xc3] = (Known), /* RET */ > + [0xc4 ... 0xc5] = 0, /* LES/LDS but also VEX prefixes, not implemented. */ > + [0xc6] = (Known|ModRM|Imm8), /* Grp11, Further ModRM decode */ > + [0xc7] = (Known|ModRM|Imm), /* Grp11, Further ModRM decode */ > + > + [0xcb ... 0xcc] = (Known), /* LRET/INT3 */ Here and for RET above: I think it's fine to entirely omit entries for opcodes not defined in 64-bit mode (e.g. 9A, EA), and for SIMD ones. At the same time I think we'd be better off having explicit (zero) entries for (integer) opcodes we deliberately mean to not support (RET/LRET with imm16, ENTER, LEAVE; more further down). > + [0xcd] = (Known|Imm8), /* INT $imm8 */ > + > + [0xd0 ... 0xd3] = (Known|ModRM), /* Grp2 (ROL..SAR {$1,%cl}, %reg) */ > + > + [0xd6] = (Known), /* UDB */ > + > + [0xe4 ... 0xe7] = (Known|Imm8), /* IN/OUT $imm8 */ > + [0xe8 ... 0xe9] = (Known|Branch|Imm), /* CALL/JMP disp32 */ > + > + [0xeb] = (Known|Branch|Imm8), /* JMP disp8 */ > + [0xec ... 0xef] = (Known), /* IN/OUT %dx */ > + > + [0xf1] = (Known), /* ICEBP */ > + > + [0xf4] = (Known), /* HLT */ > + [0xf5] = (Known), /* CMC */ > + [0xf6 ... 0xf7] = (Known|ModRM), /* Grp3, Further ModRM decode */ > + [0xf8 ... 0xfd] = (Known), /* CLC ... STD */ > + [0xfe ... 0xff] = (Known|ModRM), /* Grp4 */ > + }; > + static const uint8_t init_or_livepatch_const twobyte[256] = { > + [0x00 ... 0x03] = (Known|ModRM), /* Grp6/Grp7/LAR/LSL */ > + > + [0x0b] = (Known), /* UD2 */ > + > + [0x18 ... 0x1f] = (Known|ModRM), /* Grp16 (Hint Nop) */ > + [0x20 ... 0x23] = (Known|ModRM), /* MOV %cr/%dr */ > + > + [0x30 ... 0x33] = (Known), /* WRMSR/RDTSC/RDMSR/RDPMC */ > + > + [0x40 ... 0x4f] = (Known|ModRM), /* CMOVcc */ > + > + [0x80 ... 0x8f] = (Known|Branch|Imm), /* Jcc disp32 */ > + [0x90 ... 0x9f] = (Known|ModRM), /* SETcc */ > + > + [0xa0 ... 0xa2] = (Known), /* PUSH/POP %fs/CPUID */ > + [0xa3] = (Known|ModRM), /* BT */ > + [0xa4] = (Known|ModRM|Imm8), /* SHLD $imm8 */ > + [0xa5] = (Known|ModRM), /* SHLD %cl */ > + > + [0xa8 ... 0xa9] = (Known), /* PUSH/POP %gs */ > + > + [0xab] = (Known|ModRM), /* BTS */ > + [0xac] = (Known|ModRM|Imm8), /* SHRD $imm8 */ > + [0xad ... 0xaf] = (Known|ModRM), /* SHRD %cl/Grp15/IMUL */ > + > + [0xb0 ... 0xb9] = (Known|ModRM), /* CMPXCHG/LSS/BTR/LFS/LGS/MOVZxx/POPCNT/UD1 */ > + [0xba] = (Known|ModRM|Imm8), /* Grp8 */ > + [0xbb ... 0xbf] = (Known|ModRM), /* BTC/BSF/BSR/MOVSX */ With it being MOVSX here, perhaps MOVZX above? Or the other way around, MOVSxx here? > + [0xc0 ... 0xc1] = (Known|ModRM), /* XADD */ Is there a reason to permit XADD but not CMPXCHG? Preferably with the above addressed (but explicitly also with some / all left as is, yet then with the expectation that I may send an adjustment patch on top, which I'd then expect to not be outright refused/ignored): Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 09:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 09:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463000.1673977 (Exim 4.92) (envelope-from ) id 1xM0IA-0000FP-PS; Wed, 28 Oct 2026 09:49:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463000.1673977; Wed, 28 Oct 2026 09:49: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 1xM0IA-0000FI-Mb; Wed, 28 Oct 2026 09:49:58 +0000 Received: by outflank-mailman (input) for mailman id 1463000; Wed, 28 Oct 2026 09:49:58 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM0I9-0000FA-Qi for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:49:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM0I8-006OhM-SY for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:49:56 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1c538-2eae-0a2a0a5409dd-0a2a450ae2c4-34 for ; Wed, 28 Oct 2026 10:49:56 +0100 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 6ae1c544-f2d2-0a2a450a0019-b9ff1c228857-3 for ; Wed, 28 Oct 2026 10:49:56 +0100 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 1a181ea8c1d000f79f.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 09:49:54 +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 C279482F5C; Wed, 28 Oct 2026 10:49:53 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=+JzbgpxP3FqraFlm+HRAw5QfZsTuxXaXrmR6y7fqCqA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Qvjl4dxRFoFEpuHKWeMn+QgcGsbhP/AJlhy/qYF5oGkGjw2vfe51L3OKLcuf30Xt3OLIr/Op/ lcJla5oP1mbsFtm7tGt4lP+Jqc1vXxiLW70FR4B5pi9Gs4v9VoQ9BV9mIiRBcD3ZVS5k5plISuY Ccq43UMYYHfiOd9h9GY7Ph3kGgzLL/pQDj9/7RTmK8FSLP/7N5T4ptXaSASTD6rs0x+Gj6wxj28 0BtrxrMUg6ZnA82K/KC2Z1pFJ0dK5LuIpRRn8xBF/YrdkzV7a4Z7kHe18CpOHfQIUToklDq5vxO SuP9FQnw8A4HaHnSWr7zOj/Eo5slcFsCsuDzAOf+XrQg== X-Zone-Loop: 0103b367a8918eaf374600eb52f0c4385643a01f715b x-campaign-type: default x-transaction-id: 621b8407-09a7-43d4-b414-9ae985a8f370 x-swg-uid: 01-3075735e-b197-4c29-ac71-39fc9c74119d X-Mailer: Sweego Message-ID: <1793180994.8631fc262581453bbf619ec5b2062170.1a181ea8c1d000f79f@vates.tech> x-swg-bid: 1793180994.8631fc262581453bbf619ec5b2062170.1a181ea8c1d000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 10:49:53 +0100 From: Anthony PERARD To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v2 3/6] automation/qtb: add Python QTB framework with the console-test type References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.27b.80311203c4ee5755.1a181ea8968.a971603a2cf41c40=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793180993901 X-purgate-ID: tlsNG-4011c0/1793180996-58BC8CFC-38F7848B/0/0 X-purgate-type: clean X-purgate-size: 31405 ---=Part.27b.80311203c4ee5755.1a181ea8968.a971603a2cf41c40=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2026 at 11:42:49AM +0200, Baptiste Le Duc wrote: > diff --git a/automation/scripts/qemu_smoke_riscv64=2Epy b/automation/scr= ipts/qemu_smoke_riscv64=2Epy > new file mode 100755 > index 0000000000=2E=2Ef338fafcc2 > --- /dev/null > +++ b/automation/scripts/qemu_smoke_riscv64=2Epy > @@ -0,0 +1,122 @@ > +#!/usr/bin/env python3 > +# SPDX-License-Identifier: GPL-2=2E0-only > +"""CLI launcher for the qtb riscv64 dom0less tests=2E > + > +The test type comes first (e=2Eg=2E `console-test`), then a command=2E = Each type > +reads its own config file, which ships with the type=2E > + > +Commands: > + list Print every test the type defines in the config, then exit=2E > + run Boot one test's machine under QEMU and drive it to a pass/fai= l > + verdict=2E > + > +Usage: > + =2E/qemu_smoke_riscv64=2Epy console-test list > + =2E/qemu_smoke_riscv64=2Epy console-test run dom0less-1smp-0domu-1v= cpu-aplic-imsic-null Can we change the usage a bit? I would put `list` and `run` (the command) as first possitionnal argument=2E `list` would list all types of tests, if alone on the command line=2E And `list console-test` would list all tests associated with this kind=2E As for the comment of this file, it doesn't feel useful as it is=2E It's currently a very verbose way to try to explain how to use the command line, it doesn't explain everything, "usage" is actually just few "examples", and I don't think one would look here to find out how to use it, when running the script with `-h` can print something more standard=2E I guess here you could explain that tests from a config=2Eyaml will be run under qemu, with different parameter for the machine and different tests to run=2E > +""" > + > +from __future__ import annotations > + > +import argparse > +import logging > +import sys > +from collections=2Eabc import Sequence > +from traceback import extract_tb, format_exc > + > +from qtb=2Eriscv import RiscvQtbTest, TEST_TYPES, RiscvTestMachine, cle= anup_temp_dir > + > +logger =3D logging=2EgetLogger(__name__) > + > + > +def _run_test(test: RiscvQtbTest, log_dir: str | None) -> int: > + """Compile the machine's device trees, boot it, and run the test=2E= """ > + vm =3D RiscvTestMachine(test=2Emachine, timeout=3Dtest=2Etimeout, l= og_dir=3Dlog_dir) Naming that `vm` might be a be counter intuitive=2E Especially if you intend to have nested VM later=2E My guess, `host` or `machine` would be a bit better=2E > + try: > + with vm: > + vm=2Elaunch() > + test=2Erun(vm) > + except Exception as exc: > + print( > + f"FAIL: {test=2Ename}: {type(exc)=2E__name__}: {exc}", > + file=3Dsys=2Estderr, > + flush=3DTrue, > + ) > + return 1 > + > + print(f"PASS: {test=2Ename}", flush=3DTrue) > + return 0 > + > + > +def main(argv: Sequence[str] | None =3D None) -> int: > + ns =3D setup_parser()=2Eparse_args(argv) > + logging=2EbasicConfig( > + level=3Dlogging=2EDEBUG if ns=2Everbose else logging=2EWARNING,= format=3D"%(message)s" > + ) > + try: > + return ns=2Efunc(ns) > + except Exception as exc: > + logger=2Edebug(format_exc()) > + frame =3D extract_tb(exc=2E__traceback__)[-1] > + print(f"{frame=2Efilename}:{frame=2Elineno}: {exc}") > + return 2 > + finally: > + cleanup_temp_dir() This cleanup_temp_dir() is out of place, when `main()` doesn't create this temporary dir=2E Instead you could have the main prepare an environment, create temporary directories, and give that to the test classes, and that in turn would justify to do the cleanup here=2E > + > + > +if __name__ =3D=3D "__main__": > + sys=2Eexit(main()) > diff --git a/automation/scripts/qtb/riscv/config=2Epy b/automation/scrip= ts/qtb/riscv/config=2Epy > new file mode 100644 > index 0000000000=2E=2Eb5068d6bfb > --- /dev/null > +++ b/automation/scripts/qtb/riscv/config=2Epy > @@ -0,0 +1,119 @@ > +# SPDX-License-Identifier: GPL-2=2E0-only > +"""YAML config parser for qtb-based Xen riscv64 tests=2E > + > +Parsing steps: > + - validate the YAML > + - build the dataclasses: the host device tree is compiled on first = use > + of MachineConfig=2Edt > +""" > + > +from __future__ import annotations > + > +import functools > +import inspect > +from dataclasses import dataclass > +from functools import cached_property > +from pathlib import Path > + > +import yaml > + > +from =2Epaths import resolve_binary, resolve_path > +from =2Exen_dt import DeviceTree, build_xen_device_tree > + > +XEN_MMU_TYPE_DEFAULT: str =3D "sv48" > +XEN_BOOTARGS_DEFAULT: str =3D "" > + > +MACHINE_MEMORY: int =3D 2048 That feels like a lot, how about just 512MB? Or do you need 2GB for the tests? And why isn't it called *_DEFAULT like other parameters? > +MACHINE_INTERRUPT_CONTROLLER: str =3D "aplic-imsic" This isn't used here, in `config=2Epy`=2E Either MACHINE_INTERRUPT_CONTROLLER doesn't need to exist, or it should be added to MachineConfig=2E > + > + > +@dataclass(frozen=3DTrue) > +class MachineConfig: > + """One named machine: the test-agnostic description of what to boot= =2E > + > + A machine is reusable across test types; a test (see RiscvQtbTest > + subclasses) picks a machine by name and layers its own parameters o= n top=2E > + """ > + > + name: str > + pcpu: int > + binaries: BinariesConfig > + mmu_type: str # Xen (host) MMU type, injected into the host dts cp= us=2E > + xen_bootargs: str > + > + @classmethod > + def from_config(cls, file_name: str, machine: str) -> MachineConfig= : > + """Build only the single named machine from the catalog at `pat= h`=2E > + > + A test run boots one machine, so there is no need to construct = the > + whole catalog: parse the YAML, validate the shared binaries, an= d > + build just the requested entry=2E > + """ > + fpath: Path =3D resolve_path(file_name) > + raw: dict =3D yaml=2Esafe_load(fpath=2Eread_text()) > + > + required =3D ("binaries", "machines") > + missing =3D [k for k in required if k not in raw] > + if missing: > + raise ValueError(f"Global config {file_name} missing keys: = {missing}") > + > + binaries: BinariesConfig =3D _parse_binaries(raw["binaries"]) > + > + machines =3D raw["machines"] > + if machine not in machines: > + known =3D ", "=2Ejoin(sorted(machines)) or "(none)" > + raise ValueError(f"unknown machine {machine!r}; known machi= nes: {known}") > + > + return _parse_machine(machines[machine], binaries, machine) > + > + @cached_property > + def dt(self) -> DeviceTree: > + """Host device tree, compiled on first use=2E""" > + return build_xen_device_tree(self) > diff --git a/automation/scripts/qtb/riscv/config=2Eyaml b/automation/scr= ipts/qtb/riscv/config=2Eyaml > new file mode 100644 > index 0000000000=2E=2E94897827b7 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/config=2Eyaml > @@ -0,0 +1,17 @@ > +# Shared config for the qtb riscv64 tests > +# > +# A machine is the test-agnostic description of what to boot (cpus, Xen= command > +# line)=2E Test YAMLs (e=2Eg=2E console-test=2Eyaml) pick a machine by = name and layer > +# their own parameters on top=2E > +# > +# Path resolution (see paths=2Epy): `binaries:` entries resolve against > +# $QTB_BINARIES_DIR env var if defined else `binaries`=2E Absolute path= s used > +# as-is=2E > + > +binaries: > + xen: xen > + > +machines: > + dom0less-1smp-0domu-1vcpu-aplic-imsic-null: > + xen_bootargs: "sched=3Dnull" There's a document describing the Xen command line in the xen tree=2E It is composed of parameters and options=2E Also `xl info` calls it `xen_commandline`=2E While I understand "bootargs", can we rename that to something more comment in this context? That is "xen_cmdline" or "xen_commandline"=2E > diff --git a/automation/scripts/qtb/riscv/console_test/console-test=2Eya= ml b/automation/scripts/qtb/riscv/console_test/console-test=2Eyaml > new file mode 100644 > index 0000000000=2E=2Ecec0edc510 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/console_test/console-test=2Eyaml > @@ -0,0 +1,18 @@ Would it be possible to merge this config file into the main one? That is "config=2Eyaml"=2E I think having a single config file for the whole te= st suite would be easier to manage going forward=2E It would be easier to look at a single files instead of looking for files in multiple locations=2E Then we can just tell the main script which config file to use, and the different class of tests won't have to guess where their config file is=2E > +# Console string expectation test (run with: qemu_smoke_riscv64=2Epy co= nsole-test run )=2E > +# > +# Each test uses a machine from config=2Eyaml and maps a console index = to the list > +# of string(s) expected on that console: 0 is Xen's own console=2E The = runner boots > +# the machine and asserts each string is printed within the timeout=2E = Nothing is > +# injected=2E > +# > +# Test options: > +# timeout: int # timeout between each string match (in seconds) > +# attempts: int # number of tries for a wait before failing=2E Defaul= t 3 (min =3D 1) > + > +machine_catalog: config=2Eyaml > + > +tests: > + dom0less-1smp-0domu-1vcpu-aplic-imsic-null: > + machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null > + expect: > + 0: ["All set up"] I wonder if configuring the machine here instead of in a separated array wouldn't make more sense=2E The string "dom0less-1smp-0domu-1vcpu-aplic-imsic-null" is duplicated three time=2E If instead we had: =20 tests: dom0less-1smp-0domu-1vcpu-aplic-imsic-null: machine: pcpu: 1 xen_bootargs: "sched=3Dnull" expect: 0: ["All set up"] > diff --git a/automation/scripts/qtb/riscv/console_test/console_test=2Epy= b/automation/scripts/qtb/riscv/console_test/console_test=2Epy > new file mode 100644 > index 0000000000=2E=2E95540fd388 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/console_test/console_test=2Epy > @@ -0,0 +1,145 @@ > +# SPDX-License-Identifier: GPL-2=2E0-only > +"""Console string expectation test (`type: console-test`)=2E > + > +Per console: assert each expected string is printed within the timeout= =2E > +Nothing is injected; this only watches console output=2E > + > +YAML (console-test=2Eyaml): each test names the machine it boots (tests= may > +share one) and maps a console index to the string(s) expected on it: 0 = is > +Xen's own console=2E > + > + machine_catalog: config=2Eyaml > + tests: > + dom0less-1smp-0domu-1vcpu-aplic-imsic-null: # test name (run pos= itional) > + machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null # from con= fig=2Eyaml > + expect: # console index -> s= tring(s) > + 0: [All set up] > +""" > + > +from __future__ import annotations > + > +import logging > +from typing import ClassVar > + > +import pexpect > +import yaml > + > +from =2E=2Epaths import resolve_path > +from =2E=2Econfig import MachineConfig, required_keys > +from =2E=2Eqtb_test import TIMEOUT_DEFAULT, RiscvQtbTest > +from =2E=2Emachine import RiscvTestMachine > + > +logger =3D logging=2EgetLogger(__name__) > + > +TYPE_ID: str =3D "console-test" > + > +CONFIG_FILE_DEFAULT: str =3D "console_test/console-test=2Eyaml" > +DESCRIPTION_DEFAULT: str =3D "Assert expected string(s) are printed on = the Xen console" "DESCRIPTION_DEFAULT", do you mean it can be changed? Just curious, is there a reason to have TYPE_ID and DESCRIPTION_DEFAULT instead of adding the string directly in the class? (That is not using TYPE_ID at all)=2E > +ATTEMPTS_DEFAULT: int =3D 3 > + > +XEN_CONS_IDX: int =3D 0 It could be useful to have a description for XEN_CONS_IDX=2E > + > + > +class ConsoleTest(RiscvQtbTest): > + type_id: ClassVar[str] =3D TYPE_ID > + description: ClassVar[str] =3D DESCRIPTION_DEFAULT > + config_file: ClassVar[str] =3D CONFIG_FILE_DEFAULT > + > + def __init__(self, raw: dict, test_name: str) -> None: > + self=2Ename, self=2Edata, self=2Emachine =3D self=2E_parse_test= _cfg(raw, test_name) > + > + self=2Eexpect =3D self=2Edata["expect"] # expected console str= ing > + > + self=2Etimeout =3D int(self=2Edata=2Eget("timeout", TIMEOUT_DEF= AULT)) > + if self=2Etimeout < 1: > + raise ValueError("timeout < 1, must be at least 1") > + > + self=2Eattempts =3D int(self=2Edata=2Eget("attempts", ATTEMPTS_= DEFAULT)) > + if self=2Eattempts < 1: > + raise ValueError("attempts < 1, must be at least 1") > + > + @staticmethod > + def _load_yaml(path) -> dict: > + return yaml=2Esafe_load(resolve_path(path)=2Eread_text()) This method looks out-of place, it doesn't interact with ConsoleTest at all=2E It could be a generic util/tool=2E Or not exist a all and let the main create a `dict` from a yaml and git that `dict` to ConsoleTest to initialise itself, which is already how ConsoleTest is initialised curently anyway=2E > + > + @classmethod > + def from_config(cls, config_file: str, test_name: str) -> ConsoleTe= st: > + return cls(cls=2E_load_yaml(config_file), test_name) > + > + @staticmethod > + @required_keys("test_data", {"machine", "expect"}) > + def _parse_test_data( > + machine_catalog: str, test_data: dict, test_name: str > + ) -> tuple[str, dict, MachineConfig]: > + """Parse test data dictionary""" > + test_machine =3D MachineConfig=2Efrom_config(machine_catalog, t= est_data["machine"]) > + > + def invalid(why: str) -> ValueError: > + return ValueError( > + f"test {test_name!r}: {why}; expected " > + f"{{{XEN_CONS_IDX}: ['str1', 'str2', =2E=2E=2E]}}" > + ) > + > + expect =3D test_data["expect"] > + if not isinstance(expect, dict) or expect=2Ekeys() !=3D {XEN_CO= NS_IDX}: > + raise invalid( > + f"expect must map console index {XEN_CONS_IDX} (Xen's o= wn " > + f"console, the only one) and nothing else, got {expect!= r}" > + ) > + strings =3D expect[XEN_CONS_IDX] > + if not isinstance(strings, list): > + raise invalid( > + f"{ConsoleTest=2Econfig_file} expects a list of string(= s), " > + f"got {type(strings)=2E__name__}" > + ) > + if not strings: > + raise invalid("Xen has no expected string") > + if not all(isinstance(s, str) and s for s in strings): > + raise invalid(f"Xen expects non-empty strings, got {strings= !r}") > + return (test_name, test_data, test_machine) > + > + @staticmethod > + @required_keys("raw", {"machine_catalog", "tests"}) > + def _parse_test_cfg(raw: dict, test_name: str) -> tuple[str, dict, = MachineConfig]: > + """Read the config: return the named test dict and its machine= =2E""" > + > + tests =3D raw["tests"] > + if test_name not in tests: > + known =3D ", "=2Ejoin(sorted(tests)) or "(none)" > + raise ValueError(f"unknown test {test_name!r}; known tests:= {known}") > + > + test_data =3D tests[test_name] > + return ConsoleTest=2E_parse_test_data( > + raw["machine_catalog"], test_data, test_name > + ) > + > + @staticmethod > + def list_tests(config_file: str) -> list[str]: > + tests =3D ConsoleTest=2E_load_yaml(config_file)=2Eget("tests") > + if not tests: > + logger=2Ewarning("no 'tests' key found in %s", config_file) > + return [] > + return list(tests) > + > + @staticmethod > + def _console(vm: RiscvTestMachine): > + """Xen's own console (con0)=2E""" > + if vm=2Econsole is None: > + raise RuntimeError("Xen console not wired up, machine not l= aunched?") > + return vm=2Econsole > + > + def run(self, vm: RiscvTestMachine) -> None: > + cons =3D self=2E_console(vm) > + for strings in self=2Eexpect=2Evalues(): > + for s in strings: > + self=2E_expect_string(cons, s) > + > + def _expect_string(self, cons, expected: str) -> None: Shouldn't `cons` have a type? > + """Wait for `expected` on the console, retrying on timeout=2E""= " > + for attempt in range(self=2Eattempts): > + try: > + cons=2Eexpect_exact(expected, timeout=3Dself=2Etimeout) > + return > + except pexpect=2ETIMEOUT: > + if attempt =3D=3D self=2Eattempts - 1: > + raise I don't understand the point of this function=2E Why to we retry the `grep` on a timeout? Why is the original asked timeout multiplied by "attempts" ? (which is effectively what is happening here, more or less) Also, raising `pexpect=2ETIMEOUT` might not be the exception to throw=2E A new set of exception dedicated for the Test* classes might be better, and could easily been catch in the main function that run all the tests (without having to import unrelated module like `pexpect`)=2E > diff --git a/automation/scripts/qtb/riscv/dt=2Epy b/automation/scripts/q= tb/riscv/dt=2Epy > new file mode 100644 > index 0000000000=2E=2Ef0376979e5 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/dt=2Epy > @@ -0,0 +1,57 @@ > +# SPDX-License-Identifier: GPL-2=2E0-only > +"""Device tree (DT) handling: compile a =2Edts source into a =2Edtb""" > + > +from __future__ import annotations > + > +import logging > +import subprocess > +from pathlib import Path > + > +logger =3D logging=2EgetLogger(__name__) > + > + > +def _compile_dts(src: Path, out: Path): > + """Run dtc to compile =2Edts `src` into the =2Edtb file at `out`""" > + try: > + p =3D subprocess=2Erun( > + ["dtc", "-I", "dts", "-O", "dtb", "-o", str(out), str(src)]= , > + check=3DTrue, > + capture_output=3DTrue, > + text=3DTrue, > + ) > + logger=2Edebug("dtc %s: stdout: %s stderr: %s", src, p=2Estdout= , p=2Estderr) > + > + except FileNotFoundError as e: > + raise RuntimeError("dtc not found in PATH; install device-tree-= compiler") from e > + except subprocess=2ECalledProcessError as e: > + raise RuntimeError( > + f"dtc failed on {str(src)!r} (exit {e=2Ereturncode}):\n" > + f" stdout: {e=2Estdout}\n stderr: {e=2Estderr}" > + ) from e > + > + > +def compile_to_dtb(src: Path, out: Path) -> Path: > + """ > + Compile a =2Edts source to a =2Edtb under out dir and return the = =2Edtb path=2E > + > + Raises FileNotFoundError if `src` or `out` don't exist=2E > + """ > + if not src=2Eexists(): > + raise FileNotFoundError( > + f"Device tree source {str(src)!r} not found" > + ) > + > + if not out=2Eexists(): > + raise FileNotFoundError(f"Device Tree output dir: {out} doesn't= exist") > + > + dtb =3D out / (src=2Estem + "=2Edtb") > + _compile_dts(src, dtb) > + return dtb > + > + > +def write_dts(text: str, name: str, out_dir: Path) -> Path: > + """Write generated =2Edts text to /=2Edts; return it= s path=2E""" > + src =3D out_dir / f"{name}=2Edts" > + src=2Eparent=2Emkdir(parents=3DTrue, exist_ok=3DTrue) > + src=2Ewrite_text(text) > + return src I don't like this function, it doesn't do anything related to device tree=2E It's just a generic that allow to write any text to a file in any directory, even non existing ones, as long as the filename ends with =2E"d= ts"=2E I think whatever is calling this function should deal with the filename and the directory=2E And that caller should probably write to an existing directory=2E > diff --git a/automation/scripts/qtb/riscv/machine=2Epy b/automation/scri= pts/qtb/riscv/machine=2Epy > new file mode 100644 > index 0000000000=2E=2E74a05dfc82 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/machine=2Epy > @@ -0,0 +1,57 @@ > + > + def _resolve_binary(self) -> str: > + return str(resolve_from_path(self=2Eqemu_bin)) Nothing is using that function=2E (In that patch at least) > diff --git a/automation/scripts/qtb/riscv/paths=2Epy b/automation/script= s/qtb/riscv/paths=2Epy > new file mode 100644 > index 0000000000=2E=2E237f1bf502 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/paths=2Epy I don't like this module=2E Maybe some of those functions here could be move to the qtb package instead, and rename the module "utils" or "tools" or something else generic=2E Because nothing here is riscv specific=2E > @@ -0,0 +1,60 @@ > +# SPDX-License-Identifier: GPL-2=2E0-only > +"""Path helpers: resolve pkg-relative paths=2E""" > + > +from __future__ import annotations > + > +import os > +import shutil > +import tempfile > +from functools import lru_cache > +from pathlib import Path > + > +# Every relative path in this module is resolved against this base=2E > +_BASE =3D Path(__file__)=2Eresolve()=2Eparent > + > +# Build artifacts, overridable for CI=2E > +_BINARIES_BASE =3D Path(os=2Eenviron=2Eget("QTB_BINARIES_DIR") or _BASE= / "binaries") _BINARIES_BASE is misplaced I think, as it's buried deep into the modules=2E I would rather have the location of the "binaries" been set from the start by the main script, then give the path to the classes that needs it=2E Also, having the "binaries" directory location in a envvar is a nice idea, but can it be renamed to be more generic for the CI ? Something like "XEN_CI_BINARIES_DIR"=2E Because this is a variable that contained shared information between the jobs that build xen and other, and jobs that run tests=2E > + > + > +@lru_cache(maxsize=3D1) > +def _temp_dir_handle() -> tempfile=2ETemporaryDirectory: > + return tempfile=2ETemporaryDirectory(prefix=3D"qtb-") > + > + > +def temp_dir() -> Path: > + """Process-wide scratch dir for generated/compiled artifacts (singl= eton)=2E""" > + return Path(_temp_dir_handle()=2Ename) > + > + > +def cleanup_temp_dir() -> None: > + """Remove the scratch dir, if one was created, and clear the cache= =2E""" > + if _temp_dir_handle=2Ecache_info()=2Ecurrsize: > + _temp_dir_handle()=2Ecleanup() > + _temp_dir_handle=2Ecache_clear() > + > + > +def resolve_path(file_name: str) -> Path: > + """Resolve `file_name` against _BASE, absolute paths pass through= =2E""" > + return _resolve_under(file_name, _BASE) > + > + > +def resolve_binary(file_name: str) -> Path: > + """Resolve a build artifact against _BINARIES_BASE, absolute paths = pass through=2E""" > + return _resolve_under(file_name, _BINARIES_BASE) > + > + > +def resolve_from_path(file_name: str) -> Path: > + """Resolve an executable on $PATH, absolute paths pass through=2E""= " > + path =3D shutil=2Ewhich(file_name) > + if not path: > + raise FileNotFoundError(f"cannot resolve {file_name!r}: not an = executable on $PATH") > + return Path(path) > + > + > +def _resolve_under(file_name: str, base: Path) -> Path: > + """Resolve `file_name` against `base`, absolute paths pass through= =2E""" > + p =3D Path(file_name) > + path =3D p if p=2Eis_absolute() else base / p > + if not path=2Eexists(): > + raise FileNotFoundError(f"cannot resolve {str(path)!r}: does no= t exist") > + return path > diff --git a/automation/scripts/qtb/riscv/qtb_test=2Epy b/automation/scr= ipts/qtb/riscv/qtb_test=2Epy > new file mode 100644 > index 0000000000=2E=2E872fbc2fa9 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/qtb_test=2Epy > @@ -0,0 +1,53 @@ > +# SPDX-License-Identifier: GPL-2=2E0-only > +"""Abstract base for the qtb riscv64 test types=2E > + > +A test type is a RiscvQtbTest subclass owning a config file that descri= bes its > +tests, each bound to a machine from the shared catalog=2E > +""" > + > +from __future__ import annotations > + > +from abc import ABC, abstractmethod > +from typing import ClassVar > + > +from =2Econfig import MachineConfig > +from =2Emachine import RiscvTestMachine > + > +# Default per-test timeout (seconds) > +TIMEOUT_DEFAULT: int =3D 120 > + > + > +class RiscvQtbTest(ABC): > + """One runnable test bound to the machine it boots=2E > + > + A subclass sets `type_id`, `description`, and `config_file`, and im= plements > + `from_config` to parse its config file, `list_tests` to enumerate t= he tests > + it declares, and `run` to drive the test logic=2E > + """ > + > + # Set by each concrete subclass=2E > + type_id: ClassVar[str] =3D "" > + # One-line summary of what the type does, shown in the CLI help=2E > + description: ClassVar[str] =3D "" > + # Config file the type reads its tests from, resolved pkg-relative= =2E > + config_file: ClassVar[str] =3D "" > + > + # Set by the subclass parser=2E > + name: str > + data: dict > + machine: MachineConfig > + timeout: int =3D TIMEOUT_DEFAULT > + > + @classmethod > + @abstractmethod > + def from_config(cls, config_file: str, test_name: str) -> RiscvQtbT= est: > + """Build the test named `test_name` from `config_file`=2E""" > + > + @staticmethod > + @abstractmethod > + def list_tests(config_file: str) -> list[str]: > + """Return the names of every test declared in the config file= =2E""" It's nice to have an abstract class, but can't we implement some methods like `list_tests()` here? Otherwise, it's likely that the same exact function is going to be duplicated in every kind of tests=2E > + @abstractmethod > + def run(self, vm: RiscvTestMachine) -> None: > + """Drive the running machine and assert the expected result=2E"= "" > diff --git a/automation/scripts/qtb/riscv/xen_dt=2Epy b/automation/scrip= ts/qtb/riscv/xen_dt=2Epy > new file mode 100644 > index 0000000000=2E=2E8881b01b36 > --- /dev/null > +++ b/automation/scripts/qtb/riscv/xen_dt=2Epy > @@ -0,0 +1,58 @@ > +# SPDX-License-Identifier: GPL-2=2E0-only > +"""Build the Xen host device tree for a MachineConfig=2E It feels like both module `dt=2Epy` and `xen_dt=2Epy` could be in the same module, with something that takes a templates and parameters, and generate a DTB=2E But, seen that xen_dt access directly MachineConfig, maybe all the functions dealing with the device tree could be in the same file as the one declaring MachineConfig, or =2E > + > +The tree is rendered from its Jinja2 template (dts/qemu-host=2Edts=2Ej2= ), which > +takes the hart count, the Xen MMU type and the Xen command line, then c= ompiled > +to a DTB with dtc=2E > +""" > + > +from __future__ import annotations > + > +from dataclasses import dataclass > +from functools import lru_cache > +from pathlib import Path > +from typing import TYPE_CHECKING > +from jinja2 import Environment, FileSystemLoader > + > +from =2Epaths import resolve_path, temp_dir > +from =2Edt import compile_to_dtb, write_dts > + > +if TYPE_CHECKING: # config imports this module, so only import it for = typing=2E > + from =2Econfig import MachineConfig > + > +# Directory holding the Jinja2 platform device tree templates=2E > +_DTS_DIR =3D "dts" Instead of having this hidden variable, how about making it part of the config file? With full path, that is probably relative to the config file location=2E > + > + > +@dataclass(frozen=3DTrue) > +class DeviceTree: > + """Compiled device trees for one machine launch=2E""" > + > + dts: Path > + dtb: Path Is there any reason to keep the path to the dts? It doesn't seems to be ever used=2E > + > + > +@lru_cache(maxsize=3D1) > +def _env() -> Environment: > + return Environment( > + loader=3DFileSystemLoader(resolve_path(_DTS_DIR)), > + keep_trailing_newline=3DTrue, > + ) > + > + > +def _render_xen_dts(machine: MachineConfig) -> str: > + """Render the Xen host device tree source text for `machine`=2E""" > + tmpl =3D _env()=2Eget_template("qemu-host=2Edts=2Ej2") Same remark as for _DTS_DIR, "qemu-host=2Edts=2Ej2" could just be part of the path to the dts on a config file=2E > + return tmpl=2Erender( > + ncpus=3Dmachine=2Epcpu, > + mmu_type=3Dmachine=2Emmu_type, > + xen_bootargs=3Dmachine=2Exen_bootargs, > + ) > + > + > +def build_xen_device_tree(machine: MachineConfig) -> DeviceTree: > + """Compile `machine` device tree into the shared scratch dir=2E""" > + out =3D temp_dir() > + dts: Path =3D write_dts(_render_xen_dts(machine), machine=2Ename, o= ut) > + dtb: Path =3D compile_to_dtb(dts, out) > + return DeviceTree(dts=3Ddts, dtb=3Ddtb) >=20 There's something I haven't really talked about yet, and maybe it's too much changes=2E I've had in mind that the main script "qemu_smoke_riscv64=2Epy" could run all the available tests (or even just all the tests of a single kind/type) and report the result=2E This would change a bit how the different Test classes are instantiated=2E It might actually be better for several reason to run all tests at once=2E - It's a single job in the pipeline=2E - which mean, all the time spent to start a new container, cloning the xen tree, downloading the artefacts, cleanup; would be done a single time, and all those step likely takes a lot more time that the execution of the test=2E - adding a test is easier, there's a single file to edit, and it's automatically picked up=2E No need to also edit the pipeline as well= =2E - well, it could be a single job per kind of test, or a single job overall=2E But one job per kind of test is probably better=2E - It's easier to run the all the tests locally, just a single command=2E Having a single job in the pipeline doesn't prevent from having the result of a single test easily available, for example all the "*-tools-test-*" jobs generate a `tests-junit=2Exml` and you can see the result in the gitlab WebUI, for example: https://gitlab=2Ecom/xen-project/hardware/xen/-/pipelines/2994120991/test_= report I hope all my comments make sense, and would make the framework better=2E Cheers, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.27b.80311203c4ee5755.1a181ea8968.a971603a2cf41c40=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 09:58:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 09:58:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463007.1673987 (Exim 4.92) (envelope-from ) id 1xM0Qg-00022d-NM; Wed, 28 Oct 2026 09:58:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463007.1673987; Wed, 28 Oct 2026 09:58: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 1xM0Qg-00022V-Hv; Wed, 28 Oct 2026 09:58:46 +0000 Received: by outflank-mailman (input) for mailman id 1463007; Wed, 28 Oct 2026 09:58:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM0Qf-000221-0a for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 09:58:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM0Qe-009XrQ-25 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:58:44 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1c74f-e002-0a2a0a5209dd-0a2a450381c4-4 for ; Wed, 28 Oct 2026 10:58:43 +0100 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 6ae1c753-fae8-0a2a45030019-b9ff1c2297fb-3 for ; Wed, 28 Oct 2026 10:58:43 +0100 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 1a181f28bab000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 09:58:38 +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 BCF2981CCE; Wed, 28 Oct 2026 10:58:37 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=ND548mPJ9g3HZbtOrtycuDVO+iQDn4S3XBM0J1lShq8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=CEKcXanS6CSJ7Q10ughJWDkZb8I2QgSbtpbTTyBRjPPoOycXUR/563R1NIlGgkpo/TtVAchLE DnZm71gouzBmn4ZtBcgpMyeUbfB+jyExMLfKTqzW2T8ElOy2FIz2//KxhsukQX6HynM1R119cvD KcCkWbsb4pnk3HaNiACmdSvKactxnae0DJEODlLBVO9m+54L27qlxPIRJtmAIW/pYsfWdNlVT2a TIJ9b4FSKOqXpmqIY705qyBgdtxjAWZC+zRocuRsOittF9ImHy4JuVcF6djFo04rs1lKQxzCL8y Eu4pPRpcYjY/jM8zfq+AKFHXxWVMVXClUuSZkbioa28A== X-Zone-Loop: fa843ac42c69ce1ea22b33d942646de4966de9e90910 x-campaign-type: default x-transaction-id: 1544c94e-6272-47ce-ba5a-e1af5ca37725 x-swg-uid: 01-90d00d58-1d5d-4982-865b-aa8e176e64b6 X-Mailer: Sweego Message-ID: <1793181518.8631fc262581453bbf619ec5b2062170.1a181f28bab000f79f@vates.tech> x-swg-bid: 1793181518.8631fc262581453bbf619ec5b2062170.1a181f28bab000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 10:58:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/9] docs/specs, tools: define the PAGE_DATA flags field To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-3-marcus.granado@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: <20261020200238.1815766-3-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------U5A4dRtFAbCGRgbVYMZcqjeS" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793181517949 X-purgate-ID: tlsNG-33051d/1793181523-77EC24E9-43C7411F/0/0 X-purgate-type: clean X-purgate-size: 15386 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------U5A4dRtFAbCGRgbVYMZcqjeS Content-Type: multipart/mixed; boundary="------------06e2jDhZ4630mHbuo6kZGh6y"; protected-headers="v1"; hp="clear" Message-ID: <5a33cd02-7919-41b4-8f64-728c348b7783@vates.tech> Date: Wed, 28 Oct 2026 10:58:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/9] docs/specs, tools: define the PAGE_DATA flags field To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-3-marcus.granado@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: <20261020200238.1815766-3-marcus.granado@citrix.com> --------------06e2jDhZ4630mHbuo6kZGh6y Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowNSwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g VGhlIDMyLWJpdCBmaWVsZCBhZnRlciBjb3VudCBpbiBhIFBBR0VfREFUQSByZWNvcmQgaXMg cmVzZXJ2ZWQsIGFuZA0KPiBsaWJ4ZW5ndWVzdCBhbmQgdGhlIFB5dGhvbiBzdHJlYW0gdmFs aWRhdG9yIHJlamVjdCBhIHJlY29yZCB3aGljaCBzZXRzDQo+IGl0LiAgVGhlIHJlY29yZCdz IHBhZ2VfZGF0YSBpcyBwYWdlX3NpemUgYnl0ZXMgb2YgdW5jb21wcmVzc2VkDQo+IGNvbnRl bnRzIHBlciBwcmVzZW50IHBhZ2UsIGFuZCBub3RoaW5nIGluIHRoZSByZWNvcmQgY2FuIHNh eSB0aGF0IGl0DQo+IGlzIGVuY29kZWQgb3RoZXJ3aXNlLCBzbyBwYWdlcyBjYW5ub3QgYmUg c2VudCBjb21wcmVzc2VkLg0KPiANCj4gVHVybiB0aGF0IGZpZWxkIGludG8gYSBmbGFncyBm aWVsZC4gIEJpdHMgNy0wIGlkZW50aWZ5IHRoZSBhbGdvcml0aG0NCj4gdXNlZCB0byBlbmNv ZGUgcGFnZV9kYXRhLCAweDAwIG1lYW5pbmcgbm9uZSwgYW5kIGEgcmVzdG9yaW5nIHNpZGUg bXVzdA0KPiBmYWlsIG9uIGEgdmFsdWUgaXQgZG9lcyBub3QgaW1wbGVtZW50LiAgQml0cyAz MS04IHN0YXkgcmVzZXJ2ZWQsIGFuZCBhDQo+IHJlc3RvcmluZyBzaWRlIG11c3Qgc3RpbGwg cmVqZWN0IGEgcmVjb3JkIHdoaWNoIHNldHMgYW55IG9mIHRoZW0sDQo+IG92ZXJyaWRpbmcg dGhlIGdlbmVyYWwgcnVsZSBmb3IgcmVzZXJ2ZWQgZmllbGRzLiAgTWFrZSBsaWJ4ZW5ndWVz dCBhbmQNCj4gdGhlIFB5dGhvbiB2YWxpZGF0b3IgZW5mb3JjZSBib3RoIHJ1bGVzLCBhbmQg Y2hlY2sgdGhlIGxlbmd0aCBvZg0KPiBwYWdlX2RhdGEgYWNjb3JkaW5nIHRvIHRoZSBhbGdv cml0aG0uICBBZGQgdGVzdF9wYWdlX2RhdGFfZmxhZ3MgZm9yIHRoZQ0KPiBQeXRob24gY2hl Y2tzLg0KPiANCj4gVGhlIHNwZWNpZmljYXRpb24ncyBGdXR1cmUgRXh0ZW5zaW9ucyBzZWN0 aW9uIHJlcXVpcmVzIGEgbmV3IHJlY29yZA0KPiB0eXBlIGZvciBhbnkgZXh0ZW5zaW9uIG9m IGFuIGV4aXN0aW5nIG9uZS4gIEFsc28gYWxsb3cgYW4gZXhpc3RpbmcgdHlwZQ0KPiB0byBi ZSBleHRlbmRlZCBpbiBwbGFjZSB3aGVuIGEgcmVjZWl2ZXIgd2hpY2ggcHJlZGF0ZXMgdGhl IGV4dGVuc2lvbiBpcw0KPiBndWFyYW50ZWVkIHRvIHJlamVjdCB0aGUgZXh0ZW5kZWQgcmVj b3JkIHJhdGhlciB0aGFuIG1pc3JlYWQgaXQuICBGb3INCj4gUEFHRV9EQVRBLCB0aGlzIGhv bGRzIGZvciBhbiBlbmNvZGluZyB3aGljaCBsZWF2ZXMgY291bnQgYW5kIHRoZSBwZm4NCj4g YXJyYXkgaW4gcGxhaW50ZXh0IGFuZCBzaG9ydGVucyBwYWdlX2RhdGE6IGFuIG9sZGVyIGxp Ynhlbmd1ZXN0IHdoaWNoDQo+IGlnbm9yZXMgdGhlIGZpZWxkIGZhaWxzIGl0cyBleGFjdCBs ZW5ndGggY2hlY2suDQo+IA0KPiBUaGUgc3RyZWFtIHZlcnNpb24gaXMgbm90IGJ1bXBlZC4g IEEgemVybyBmbGFncyBmaWVsZCBtZWFucyB3aGF0IHRoZQ0KPiByZXNlcnZlZCBmaWVsZCBt ZWFudCwgYW5kIG5vIG90aGVyIHZhbHVlIGlzIGFjY2VwdGVkLg0KPiANCj4gQXNzaXN0ZWQt Ynk6IENsYXVkZTpjbGF1ZGUtb3B1cy01LTUNCj4gU2lnbmVkLW9mZi1ieTogTWFyY3VzIEdy YW5hZG8gPG1hcmN1cy5ncmFuYWRvQGNpdHJpeC5jb20+DQo+IC0tLQ0KPiANCj4gTm90ZXM6 DQo+ICAgICAgQ2hhbmdlcyBpbiB2MjoNCj4gICAgICAtIFJlcGxhY2VzIHYxIDEvNiwgd2hp Y2ggYWRkZWQgYSBQQUdFX0RBVEFfTFo0IHJlY29yZCB0eXBlOiBQQUdFX0RBVEEncw0KPiAg ICAgICAgcmVzZXJ2ZWQgZmllbGQgYmVjb21lcyBhIGZsYWdzIGZpZWxkLCBmb2xsb3dpbmcg cmV2aWV3IGJ5IFRlZGR5DQo+ICAgICAgICBBc3RpZSBhbmQgRnJlZGlhbm8gWmlnbGlvLiAg TFo0IGlzIGFzc2lnbmVkIGluIHBhdGNoIDMuDQo+IA0KPiAgIGRvY3Mvc3BlY3MvbGlieGMt bWlncmF0aW9uLXN0cmVhbS5wYW5kb2MgfCAyOCArKysrKysrKysrKysrKysrKy0tLS0tLQ0K PiAgIHRvb2xzL2xpYnMvZ3Vlc3QveGdfc3JfcmVzdG9yZS5jICAgICAgICAgfCAyOSArKysr KysrKysrKysrKysrLS0tLS0tLS0NCj4gICB0b29scy9saWJzL2d1ZXN0L3hnX3NyX3N0cmVh bV9mb3JtYXQuaCAgIHwgIDggKysrKysrLQ0KPiAgIHRvb2xzL3B5dGhvbi94ZW4vbWlncmF0 aW9uL2xpYnhjLnB5ICAgICAgfCAyOCArKysrKysrKysrKysrKysrKystLS0tLQ0KPiAgIHRv b2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rlc3RzLnB5ICAgICAgfCAyNSArKysrKysrKysr KysrKysrKysrLQ0KPiAgIDUgZmlsZXMgY2hhbmdlZCwgOTQgaW5zZXJ0aW9ucygrKSwgMjQg ZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvZG9jcy9zcGVjcy9saWJ4Yy1taWdy YXRpb24tc3RyZWFtLnBhbmRvYyBiL2RvY3Mvc3BlY3MvbGlieGMtbWlncmF0aW9uLXN0cmVh bS5wYW5kb2MNCj4gaW5kZXggYjFjODFiNWQ2OC4uZmQ0NGRkNmUwYSAxMDA2NDQNCg0KKC4u LikNCg0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zdHJlYW1fZm9y bWF0LmggYi90b29scy9saWJzL2d1ZXN0L3hnX3NyX3N0cmVhbV9mb3JtYXQuaA0KPiBpbmRl eCAxZTZlNTBhNzEwLi5mODM5ZDg3NGM4IDEwMDY0NA0KPiAtLS0gYS90b29scy9saWJzL2d1 ZXN0L3hnX3NyX3N0cmVhbV9mb3JtYXQuaA0KPiArKysgYi90b29scy9saWJzL2d1ZXN0L3hn X3NyX3N0cmVhbV9mb3JtYXQuaA0KPiBAQCAtODMsMTAgKzgzLDE2IEBAIHN0cnVjdCB4Y19z cl9yaGRyDQo+ICAgc3RydWN0IHhjX3NyX3JlY19wYWdlX2RhdGFfaGVhZGVyDQo+ICAgew0K PiAgICAgICB1aW50MzJfdCBjb3VudDsNCj4gLSAgICB1aW50MzJfdCBfcmVzMTsNCj4gKyAg ICB1aW50MzJfdCBmbGFnczsNCj4gICAgICAgdWludDY0X3QgcGZuWzBdOw0KPiAgIH07DQo+ ICAgDQo+ICsvKiBQQUdFX0RBVEEgZmxhZ3M6IGJpdHMgNy0wIGFyZSB0aGUgYWxnb3JpdGht LCBiaXRzIDMxLTggYXJlIHJlc2VydmVkLiAqLw0KPiArI2RlZmluZSBQQUdFX0RBVEFfQUxH T19NQVNLICAgICAgIDB4MDAwMDAwZmZVDQo+ICsjZGVmaW5lIFBBR0VfREFUQV9GTEFHU19S RVNaX01BU0sgMHhmZmZmZmYwMFUNCj4gKw0KPiArI2RlZmluZSBQQUdFX0RBVEFfQUxHT19O T05FICAgICAgIDB4MDAwMDAwMDBVDQo+ICsNCg0Kbml0OiBJIHdvdWxkIHByZWZlciBoYXZp bmcgZWFjaCBhbGdvcml0aG0gYXMgYSBleHBsaWNpdCA4LWJpdCBudW1iZXIsDQppLmUgMHgw MFUgZm9yIEFMR09fTk9ORSwgZ2l2ZW4gdGhhdCB0aGV5IGNhbid0IGJlIGxhcmdlciB0aGFu IGl0Lg0KDQo+ICAgI2RlZmluZSBQQUdFX0RBVEFfUEZOX01BU0sgICAgICAweDAwMGZmZmZm ZmZmZmZmZmZVTEwNCj4gICAjZGVmaW5lIFBBR0VfREFUQV9QRk5fUkVTWl9NQVNLIDB4MGZm MDAwMDAwMDAwMDAwMFVMTA0KPiAgICNkZWZpbmUgUEFHRV9EQVRBX1RZUEVfTUFTSyAgICAg MHhmMDAwMDAwMDAwMDAwMDAwVUxMDQo+IGRpZmYgLS1naXQgYS90b29scy9weXRob24veGVu L21pZ3JhdGlvbi9saWJ4Yy5weSBiL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL2xpYnhj LnB5DQo+IGluZGV4IGU1MmU2MzJjYjEuLjI5MDZiNzhkMzYgMTAwNjQ0DQo+IC0tLSBhL3Rv b2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL2xpYnhjLnB5DQo+ICsrKyBiL3Rvb2xzL3B5dGhv bi94ZW4vbWlncmF0aW9uL2xpYnhjLnB5DQo+IEBAIC04Niw2ICs4NiwxMSBAQCBQQUdFX0RB VEFfRk9STUFUICAgICAgICAgICAgID0gIklJIg0KPiAgIFBBR0VfREFUQV9QRk5fTUFTSyAg ICAgICAgICAgPSAoMSA8PCA1MikgLSAxDQo+ICAgUEFHRV9EQVRBX1BGTl9SRVNaX01BU0sg ICAgICA9ICgoMSA8PCA2MCkgLSAxKSAmIH4oKDEgPDwgNTIpIC0gMSkNCj4gICANCj4gKyMg cGFnZV9kYXRhIGZsYWdzOiBiaXRzIDctMCBhbGdvcml0aG0sIGJpdHMgMzEtOCByZXNlcnZl ZCAobXVzdCByZWplY3QpDQo+ICtQQUdFX0RBVEFfQUxHT19NQVNLICAgICAgICAgID0gMHgw MDAwMDBmZg0KPiArUEFHRV9EQVRBX0ZMQUdTX1JFU1pfTUFTSyAgICA9IDB4ZmZmZmZmMDAN Cj4gK1BBR0VfREFUQV9BTEdPX05PTkUgICAgICAgICAgPSAweDAwDQo+ICsNCj4gICAjIGZs YWdzIGZyb20geGVuL3B1YmxpYy9kb21jdGwuaDogWEVOX0RPTUNUTF9QRklORk9fKiBzaGlm dGVkIGJ5IDMyIGJpdHMNCj4gICBQQUdFX0RBVEFfVFlQRV9TSElGVCAgICAgICAgID0gNjAN Cj4gICBQQUdFX0RBVEFfVFlQRV9MVEFCVFlQRV9NQVNLID0gKDB4NyA8PCBQQUdFX0RBVEFf VFlQRV9TSElGVCkNCj4gQEAgLTI1OSwxMSArMjY0LDE0IEBAIGNsYXNzIFZlcmlmeUxpYnhj KFZlcmlmeUJhc2UpOg0KPiAgICAgICAgICAgICAgIHJhaXNlIFJlY29yZEVycm9yKA0KPiAg ICAgICAgICAgICAgICAgICAiUEFHRV9EQVRBIHJlY29yZCBtdXN0IGJlIGF0IGxlYXN0ICVk IGJ5dGVzIGxvbmciICUgKG1pbnN6LCApKQ0KPiAgIA0KPiAtICAgICAgICBjb3VudCwgcmVz MSA9IHVucGFjayhQQUdFX0RBVEFfRk9STUFULCBjb250ZW50WzptaW5zel0pDQo+ICsgICAg ICAgIGNvdW50LCBmbGFncyA9IHVucGFjayhQQUdFX0RBVEFfRk9STUFULCBjb250ZW50Wzpt aW5zel0pDQo+ICAgDQo+IC0gICAgICAgIGlmIHJlczEgIT0gMDoNCj4gKyAgICAgICAgaWYg ZmxhZ3MgJiBQQUdFX0RBVEFfRkxBR1NfUkVTWl9NQVNLOg0KPiAgICAgICAgICAgICAgIHJh aXNlIFN0cmVhbUVycm9yKA0KPiAtICAgICAgICAgICAgICAgICJSZXNlcnZlZCBiaXRzIHNl dCBpbiBQQUdFX0RBVEEgcmVjb3JkIDB4JTA0eCIgJSAocmVzMSwgKSkNCj4gKyAgICAgICAg ICAgICAgICAiUmVzZXJ2ZWQgYml0cyBzZXQgaW4gUEFHRV9EQVRBIHJlY29yZCAweCUwOHgi DQo+ICsgICAgICAgICAgICAgICAgJSAoZmxhZ3MgJiBQQUdFX0RBVEFfRkxBR1NfUkVTWl9N QVNLLCApKQ0KPiArDQo+ICsgICAgICAgIGFsZ28gPSBmbGFncyAmIFBBR0VfREFUQV9BTEdP X01BU0sNCj4gICANCj4gICAgICAgICAgIHBmbnN6ID0gY291bnQgKiA4DQo+ICAgICAgICAg ICBpZiAobGVuKGNvbnRlbnQpIC0gbWluc3opIDwgcGZuc3o6DQo+IEBAIC0yODksOSArMjk3 LDE3IEBAIGNsYXNzIFZlcmlmeUxpYnhjKFZlcmlmeUJhc2UpOg0KPiAgICAgICAgICAgICAg ICAgICBucl9wYWdlcyArPSAxDQo+ICAgDQo+ICAgICAgICAgICBwYWdlc3ogPSBucl9wYWdl cyAqIDQwOTYNCj4gLSAgICAgICAgaWYgbGVuKGNvbnRlbnQpICE9IG1pbnN6ICsgcGZuc3og KyBwYWdlc3o6DQo+IC0gICAgICAgICAgICByYWlzZSBSZWNvcmRFcnJvcigiRXhwZWN0ZWQg JXUgKyAldSArICV1LCBnb3QgJXUiICUNCj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChtaW5zeiwgcGZuc3osIHBhZ2VzeiwgbGVuKGNvbnRlbnQpKSkNCj4gKyAgICAgICAg ZGF0YXN6ID0gbGVuKGNvbnRlbnQpIC0gbWluc3ogLSBwZm5zeg0KPiArDQo+ICsgICAgICAg IGlmIGFsZ28gPT0gUEFHRV9EQVRBX0FMR09fTk9ORToNCj4gKw0KPiArICAgICAgICAgICAg aWYgZGF0YXN6ICE9IHBhZ2VzejoNCj4gKyAgICAgICAgICAgICAgICByYWlzZSBSZWNvcmRF cnJvcigiRXhwZWN0ZWQgJXUgKyAldSArICV1LCBnb3QgJXUiICUNCj4gKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAobWluc3osIHBmbnN6LCBwYWdlc3osIGxlbihjb250 ZW50KSkpDQo+ICsNCj4gKyAgICAgICAgZWxzZToNCj4gKyAgICAgICAgICAgIHJhaXNlIFN0 cmVhbUVycm9yKA0KPiArICAgICAgICAgICAgICAgICJVbnN1cHBvcnRlZCBhbGdvcml0aG0g JXUgaW4gUEFHRV9EQVRBIHJlY29yZCIgJSAoYWxnbywgKSkNCj4gICANCj4gICANCj4gICAg ICAgZGVmIHZlcmlmeV9yZWNvcmRfeDg2X3B2X2luZm8oc2VsZiwgY29udGVudCk6DQo+IGRp ZmYgLS1naXQgYS90b29scy9weXRob24veGVuL21pZ3JhdGlvbi90ZXN0cy5weSBiL3Rvb2xz L3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rlc3RzLnB5DQo+IGluZGV4IGZjZjk0YjBiYjIuLjE5 NDRhZTA5YjMgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rl c3RzLnB5DQo+ICsrKyBiL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rlc3RzLnB5DQo+ IEBAIC02LDcgKzYsNyBAQCBVbml0IHRlc3RzIGZvciBtaWdyYXRpb24gdjIgc3RyZWFtcw0K PiAgIA0KPiAgIGltcG9ydCB1bml0dGVzdA0KPiAgIA0KPiAtZnJvbSBzdHJ1Y3QgaW1wb3J0 IGNhbGNzaXplDQo+ICtmcm9tIHN0cnVjdCBpbXBvcnQgY2FsY3NpemUsIHBhY2sNCj4gICAN Cj4gICBmcm9tIHhlbi5taWdyYXRpb24gaW1wb3J0IGxpYnhjLCBsaWJ4bA0KPiAgIA0KPiBA QCAtMzAsNiArMzAsMjkgQEAgY2xhc3MgVGVzdExpYnhjKHVuaXR0ZXN0LlRlc3RDYXNlKToN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgKToNCj4gICAgICAgICAgICAgICBzZWxm LmFzc2VydEVxdWFsKGNhbGNzaXplKGZtdCksIHN6KQ0KPiAgIA0KPiArICAgIGRlZiB0ZXN0 X3BhZ2VfZGF0YV9mbGFncyhzZWxmKToNCj4gKyAgICAgICAgIiIiIFBBR0VfREFUQSBmbGFn czogYWxnb3JpdGhtIGRpc3BhdGNoIGFuZCB0aGUgcmVzZXJ2ZWQgYml0cyAiIiINCj4gKw0K PiArICAgICAgICB2ID0gbGlieGMuVmVyaWZ5TGlieGMobGFtYmRhICpfOiBOb25lLCBsYW1i ZGEgKl86IGIiIikNCj4gKyAgICAgICAgUEFHRSA9IGIiXHgwMCIgKiA0MDk2DQo+ICsgICAg ICAgIE5PVEFCID0gbGlieGMuUEFHRV9EQVRBX1RZUEVfTk9UQUIgfCAweDEgICAjIG9uZSBu b3JtYWwgcGFnZSwgcGZuIDENCj4gKw0KPiArICAgICAgICBkZWYgcmVjKGZsYWdzLCBkYXRh KToNCj4gKyAgICAgICAgICAgIHJldHVybiBwYWNrKGxpYnhjLlBBR0VfREFUQV9GT1JNQVQs IDEsIGZsYWdzKSArIFwNCj4gKyAgICAgICAgICAgICAgICAgICBwYWNrKCI9USIsIE5PVEFC KSArIGRhdGENCj4gKw0KPiArICAgICAgICAjIFVuY29tcHJlc3NlZDogZXhhY3RseSBvbmUg cGFnZSBvZiBkYXRhLCBhbmQgbm90aGluZyBlbHNlIGFjY2VwdGVkLg0KPiArICAgICAgICB2 LnZlcmlmeV9yZWNvcmRfcGFnZV9kYXRhKHJlYyhsaWJ4Yy5QQUdFX0RBVEFfQUxHT19OT05F LCBQQUdFKSkNCj4gKyAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMobGlieGMuUmVjb3JkRXJy b3IsIHYudmVyaWZ5X3JlY29yZF9wYWdlX2RhdGEsDQo+ICsgICAgICAgICAgICAgICAgICAg ICAgICAgIHJlYyhsaWJ4Yy5QQUdFX0RBVEFfQUxHT19OT05FLCBQQUdFWzotMV0pKQ0KPiAr DQo+ICsgICAgICAgICMgQW4gdW5pbXBsZW1lbnRlZCBhbGdvcml0aG0sIGFuZCBhbnkgcmVz ZXJ2ZWQgYml0LCBhcmUgcmVmdXNlZC4NCj4gKyAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMo bGlieGMuU3RyZWFtRXJyb3IsIHYudmVyaWZ5X3JlY29yZF9wYWdlX2RhdGEsDQo+ICsgICAg ICAgICAgICAgICAgICAgICAgICAgIHJlYyhsaWJ4Yy5QQUdFX0RBVEFfQUxHT19OT05FICsg MSwgUEFHRSkpDQo+ICsgICAgICAgIGZvciBiaXQgaW4gcmFuZ2UoOCwgMzIpOg0KPiArICAg ICAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMobGlieGMuU3RyZWFtRXJyb3IsIHYudmVyaWZ5 X3JlY29yZF9wYWdlX2RhdGEsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy ZWMoMSA8PCBiaXQsIFBBR0UpKQ0KPiArDQo+ICAgDQo+ICAgY2xhc3MgVGVzdExpYnhsKHVu aXR0ZXN0LlRlc3RDYXNlKToNCj4gICANCg0KVGhlIHJlc3QgbG9va3MgZ29vZCB0byBtZQ0K V2l0aCB0aGUgY2hhbmdlIG9uIG51bWJlciBmb3JtYXR0aW5nDQoNClJldmlld2VkLWJ5OiBU ZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4NCg== --------------06e2jDhZ4630mHbuo6kZGh6y-- --------------U5A4dRtFAbCGRgbVYMZcqjeS 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+p0QLLz9AFAmrhx00FAwAAAAAACgkQZg+p0QLLz9D8 +Qv7B27y/Tue5dXHyDmMNQFlsqMVsaywg9SJoWcQPAVt4xBlPyP9cfqguCZR8o2C2A+ef8jb2xYJ 6ACxXbeorpgtQy81hU17ZeEzZicR5dzY+TQFIMTIOlopuagv07E8T31i+o/xPO5lDsTjd7KI32S9 OGDu+rFKu0Cfg/kjttBA+BoGV3AQDWzsy7zaTpTpTmo9wK7cbZY250OM+m1QjrHb9yJR8k1XFwmr HYaooDUloMw9qQK82wUW+rF/+6+v8kZxYW38YUEz2TId1BfEoYPg6SA0TOmeqqRQy3DcaBuFVk3B qI++xjE41tkBcTHvdgizcgUD2Pd2XmXHAe0qbFheAXLdAHOBEK4iFte6Bd9dE+FaUXfnAH0ciVGZ 0xfEfferaMXlEcD58dOOAbepipfw+Yp32A5ynzthDmGqJNkxGCJ+JqFVxOpZVtgbV6ajrn8+Bm/x v9gbnE8e/pLrTtVQy7j1EbKoeD87ljl0k/a57E8bq2GjCDLra7kYTNTOMC+L =4ZTz -----END PGP SIGNATURE----- --------------U5A4dRtFAbCGRgbVYMZcqjeS-- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 10:07:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 10:07:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463017.1673994 (Exim 4.92) (envelope-from ) id 1xM0ZL-0003mE-AB; Wed, 28 Oct 2026 10:07:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463017.1673994; Wed, 28 Oct 2026 10: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 1xM0ZL-0003m7-7R; Wed, 28 Oct 2026 10:07:43 +0000 Received: by outflank-mailman (input) for mailman id 1463017; Wed, 28 Oct 2026 10:07:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM0ZK-0003lv-3G for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:07:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM0ZJ-00DDzV-CZ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:07:41 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1c969-2eae-0a2a0a5409dd-0a2a4508e85e-22 for ; Wed, 28 Oct 2026 11:07:41 +0100 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 6ae1c96c-f659-0a2a45080019-b9ff1c23b649-3 for ; Wed, 28 Oct 2026 11:07:41 +0100 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 1a181fac390000f79f.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 10:07:37 +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 9FA5880CA5; Wed, 28 Oct 2026 11:07:36 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=aXZ0OgsGv+lyuglQvC4NwIKQ1iGFp8a8FzIYFVBSUcI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=NTT5m8qQsOWngTI4SrDdTBwufXMxjkUuSSeGgx7Cp+GbVh1+/X5AD7vBCHVLCahc3UI+6kRg8 IOZTJAT423nPT/qfge7QygTq76vbtGKIen7wFsSmxO8xEaVn7ImP+IZ8N093sNWBWe6RanOzoWo L88XfVpZSnnfr9YAC8H6LHYUbWzVKsZ5rsbGSvCQe5siYcDY6v2Ct8sxM//6YCnEb9Nc+yNENgM zMpBqfn0FtGq0He6La8zUS/Lg7uAkeV9KGFDCWw7T4cfjnLm3mXBHjxSPqkk327M7vXFUCDBrbB UrIQGn1IIlKeAV6JVF9ywAsV+oxiSvsJa0H/aI/KrvYQ== X-Zone-Loop: d042846dfc815170d969b11751446ae6fe4b25dd575a x-campaign-type: default x-transaction-id: 41327007-6b19-4134-bc02-83aba752dbbe x-swg-uid: 01-4a285e68-9181-459a-977a-3c1cca42c17f X-Mailer: Sweego Message-ID: <1793182057.8631fc262581453bbf619ec5b2062170.1a181fac390000f79f@vates.tech> x-swg-bid: 1793182057.8631fc262581453bbf619ec5b2062170.1a181fac390000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 11:07:36 +0100 From: Anthony PERARD To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v2 6/6] CI: run the riscv64 smoke test via QTB framework console-test References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.27d.dda3b12fb4b579bc.1a181fac121.942cc93773c8d460=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793182056737 X-purgate-ID: tlsNG-c1860d/1793182061-CE34587B-9CCD96F9/0/0 X-purgate-type: clean X-purgate-size: 2542 ---=Part.27d.dda3b12fb4b579bc.1a181fac121.942cc93773c8d460=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2026 at 11:42:52AM +0200, Baptiste Le Duc wrote: > diff --git a/automation/gitlab-ci/test=2Eyaml b/automation/gitlab-ci/tes= t=2Eyaml > index 61adc1baff=2E=2Ee9dd147380 100644 > --- a/automation/gitlab-ci/test=2Eyaml > +++ b/automation/gitlab-ci/test=2Eyaml > @@ -72,14 +72,21 @@ > TEST_TIMEOUT_OVERRIDE: 120 > =20 > =2Eqemu-riscv64: Could you rename that template? The name should contain "qtb" since that the tool used by the test template=2E > + image: ${ARTIFACTS_REGISTRY}/${CONTAINER} > extends: =2Etest-jobs-common > variables: > - CONTAINER: debian:13-riscv64 > - LOGFILE: qemu-smoke-riscv64=2Elog > + CONTAINER: debian:13-qtb-riscv64 > + QTB_LOG_DIR: qtb-logs > + QTB_BINARIES_DIR: ${CI_PROJECT_DIR}/binaries Instead of an envvar, this could be a parameter to the main script, like --log-dir is=2E > + script: > + - =2E/automation/scripts/qemu_smoke_riscv64=2Epy > + ${QTB_TEST_TYPE} > + run > + ${QTB_TEST} > + --log-dir ${QTB_LOG_DIR} > artifacts: > paths: > - - smoke=2Eserial > - - '*=2Elog' > + - ${QTB_LOG_DIR} > when: always > tags: > - x86_64 > @@ -779,8 +786,9 @@ qemu-xtf-argo-x86_64-gcc-debug: > =20 > qemu-smoke-riscv64-gcc: Same here=2E > diff --git a/automation/scripts/qemu-smoke-riscv64=2Esh b/automation/scr= ipts/qemu-smoke-riscv64=2Esh > deleted file mode 100755 > index c0b1082a08=2E=2E0000000000 > --- a/automation/scripts/qemu-smoke-riscv64=2Esh > +++ /dev/null > @@ -1,19 +0,0 @@ > -#!/bin/bash > - > -set -ex -o pipefail > - > -# Run the test > -rm -f smoke=2Eserial > - > -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=2Eserial" > -export PASSED=3D"All set up" > - > -=2E/automation/scripts/console=2Eexp |& sed 's/\r\+$//' I you want to remove the exiting riscv test, can you do so in a separated patch? Then we can decide separatly if the new test is indeed a replacement of the current one=2E Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.27d.dda3b12fb4b579bc.1a181fac121.942cc93773c8d460=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 10:15:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 10:15:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463028.1674005 (Exim 4.92) (envelope-from ) id 1xM0gy-0005d8-0D; Wed, 28 Oct 2026 10:15:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463028.1674005; Wed, 28 Oct 2026 10:15: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 1xM0gx-0005d0-Sr; Wed, 28 Oct 2026 10:15:35 +0000 Received: by outflank-mailman (input) for mailman id 1463028; Wed, 28 Oct 2026 10:15:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM0gw-0005cu-M3 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:15:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM0gw-002UmB-2x for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:15:34 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1cb40-bab6-0a2a0a5309dd-0a2a450691ca-16 for ; Wed, 28 Oct 2026 11:15:34 +0100 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1cb45-195a-0a2a45060019-d155dd29ac37-3 for ; Wed, 28 Oct 2026 11:15:33 +0100 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48e3b22e971so381516f8f.0 for ; Wed, 28 Oct 2026 03:15: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-48e3ebcb8e0sm26833867f8f.29.2026.10.28.03.15.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 03:15: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: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=1793182533; x=1793787333; 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=PARG7RTdpcAvp0WAx9UWs1TwTbbFjToKTRZ6/XeP2w4=; b=VOWBXE3S0xbYg5G7AjgbCo0m8+b60K1BmP16Vl9PT+FF1bNfne1iw23w/6uueWmrxU F+2G9gN8Pdo1Ak7UXmMSmeEby1uwCo4ngXSto0xF7gKrmp2fFXAmqVJ3LTjE3OQmBumm BmGKahQIEyy/ELWio/ToKR1cG/RnffEXzqCVA+I56BGXUMQSONVDeVKuJZFKSwcr8qUc j8pia0+oM/rvLun3uqHkwZLDGferLnxV1v42X11fSyQGNqYjNVbivQVTSkFsWSDcZGEK 3k9WL6bogsBKTNuGaFScAbmtZdGMtcfbFPxGb0OZdewRViB3OvA68/O1Wif/x2bTMVcC bJXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793182533; x=1793787333; 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=PARG7RTdpcAvp0WAx9UWs1TwTbbFjToKTRZ6/XeP2w4=; b=innJN/9FkVlMErAxSusCH/0c56J8/cg/i1j70u150F8e0DXknWypf6m11vaYe11pyd yRED/w2zSQYbmNtzCejdvqRigljhwrjPdjWYRKmSnzbZT24MpN+NYVMbofMPTDXUFJ8+ ci6YHaqnuTu7lyI+P+nI7A6fsVMIugS/bdDSwkSt/bVpSS+pe7RSjykwv6gLiFD8GYh3 WU13rUcoDmaYnMeEIqyVV3s5SOdpZiM3zWJ86jKc06Mj02INSYExSyNYtywLh2/dZHRv 69kMeOd7Qo04tuTQIqK379GyZbQbb7DaeUT8EjI8fncUPSJEmMRaxs7FQLSCIs23k5I3 /XGQ== X-Forwarded-Encrypted: i=1; AKwUvBzjSpgLjN807yYkNd5bpUb4GwpbMQSzRQne/rMBPve5D8SNe39w+HmIUjqH5TS3zoYM8jCIH3D7Jy4=@lists.xenproject.org X-Gm-Message-State: AFq9FYLu4bZLiD7islrkRyjTptHAB7amcqO/CWlmC8mLvrQxgbpaxjUP VNnRTSrSKwVav1OBSiLr7TifF38U3FDI5PpR1FggjtVWX+yTqlLrkYcDuO4B5DJOqg== X-Gm-Gg: AYBFou2mIOjd5XP5QHilkk8P9nMtoQn0I35gWg3zeoHm7MNUHdBxWd21NnGOIC83Oyc OCp5es7oNAmnYxPUrlaAw3RnABL9dLzEO2im+phOE7OFf09NFv33fanevcI/QP/C92MY1LFhqso gAaP/AgTYOglM1PNSL73tfSBK9n51YTmNphid5jZg4XrKPQ0dsiOafdaGG4LJN6+mQf+kqTiIP0 84ElYelWBMX5qm00M3S+e2fbtleziibu3JelaAvuefujARJcTTe56DoPcq6BEgIB+rzJf39i6Nz bpf+DIm+EH3C64s9sRd/z3saDfVLR3wL9gd0RvkCGLYOVNLG8c6qekONaa67iQArvaOjAvHd7RS +Em0R5mVz0lv4QCTqGmaHViwSn0fGkYaljnPmA2COaCNQivkYXRow6vw1QtSgrsaySKUQlcIPo+ 3YkXDIsdaMwzOlBzKCllepJg1s8ZScPaWYmwp4vGZY5Y/M5VqTHZFsPj6NYBoDCcTv2Uj8brJEr mPedGKJL53R0MKSJHrJlv2eopAyR/lesMXCQ7HguAnNR81ckckw0lYlNhmzp6XrK+fZxxIbbQFF ti0g64g6ETmUJ2pwTyDJAockldEehDxzFKTUiW8580zhMCV4OsYIRNwgIO8F9m4SfhuAJmy6pd9 VpVhQipcbOiT8Svlj X-Received: by 2002:a05:6000:240d:b0:48b:a7:6396 with SMTP id ffacd0b85a97d-48e5d5d137cmr4946584f8f.41.1793182533104; Wed, 28 Oct 2026 03:15:33 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 11:15:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/5] x86/emul: Introduce x86_decode_lite() From: Jan Beulich To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20261015210530.786604-1-andrew.cooper3@citrix.com> <20261015210530.786604-2-andrew.cooper3@citrix.com> <998b084e-1a3f-4b51-bad3-4b175e6027a0@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: <998b084e-1a3f-4b51-bad3-4b175e6027a0@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1793182533-F7ACA77B-0A80CA61/10/78276251493 X-purgate-type: spam X-purgate-size: 639 On 28.10.2026 10:48, Jan Beulich wrote: > On 15.10.2026 23:05, Andrew Cooper wrote: >> + [0xb0 ... 0xb9] = (Known|ModRM), /* CMPXCHG/LSS/BTR/LFS/LGS/MOVZxx/POPCNT/UD1 */ >> + [0xba] = (Known|ModRM|Imm8), /* Grp8 */ >> + [0xbb ... 0xbf] = (Known|ModRM), /* BTC/BSF/BSR/MOVSX */ > > With it being MOVSX here, perhaps MOVZX above? Or the other way around, > MOVSxx here? > >> + [0xc0 ... 0xc1] = (Known|ModRM), /* XADD */ > > Is there a reason to permit XADD but not CMPXCHG? Oh, I'm sorry - CMPXCHG is there, just that I overlooked it in the longish comment. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 10:21:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 10:21:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463036.1674013 (Exim 4.92) (envelope-from ) id 1xM0mf-0007VC-LG; Wed, 28 Oct 2026 10:21:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463036.1674013; Wed, 28 Oct 2026 10: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 1xM0mf-0007V5-Ii; Wed, 28 Oct 2026 10:21:29 +0000 Received: by outflank-mailman (input) for mailman id 1463036; Wed, 28 Oct 2026 10:21:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM0md-0007Uz-Sq for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:21:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM0mc-00DH77-U1 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:21:26 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1cc9c-2eae-0a2a0a5409dd-0a2a450ada42-40 for ; Wed, 28 Oct 2026 11:21:26 +0100 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 6ae1cca6-f2d2-0a2a450a0019-d155dd2af1da-3 for ; Wed, 28 Oct 2026 11:21:26 +0100 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48c4649b35bso670957f8f.3 for ; Wed, 28 Oct 2026 03:21: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 ffacd0b85a97d-48e3ebd48fasm27389762f8f.31.2026.10.28.03.21.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 03:21: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=1793182886; x=1793787686; 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=tyc0V9SqxKacP2ySrL85ZyvPr6HLsaDHIgje4Lsqn2U=; b=cEsy794NfOrES9nXILqbPNgInE6Q3J8SgKs3w4J8Smkz2YJmaVCt7XCK+AwtukmUXi yXUbFfkxip3lWj7amB/DGHI1qPXacBkbwU5d43DqKaOZoIi41w2j4g6Kr3nSzPNOgBG+ fTRvQXfxJv3Mx8F3dM4897i0pgzRGikKadGqUu8/dzk0bPQSrumlQGqGVO5KSrztIaOy IzCT7IGIJgikxrM3+WsrIfl2F8+pdh03xS5/JA3OccItjLcJ/XmtSg292cqm4GJAx+/R ZnZEP9EWi3je7tOSZo2fhQYDMnxJjZGhcWpnJ7UR9XgWACo+yRv5kSRENAJpaI0C70De 2Ogw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793182886; x=1793787686; 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=tyc0V9SqxKacP2ySrL85ZyvPr6HLsaDHIgje4Lsqn2U=; b=uYnFjXeLCdS+RWqx+Gq+QETbadTGxd0JEGohFSebYx75UWBsisQND8zXMl7upyh2nT BEREh2x7jgvx/v+iY0t8mhjaRJs1CVkbqAO5zqEkmRbPGA+WjWsmORXf6rfW2ZQOE6mJ jcxLiesMOyYLvIIz7xCJKclhJ6NS9fuZO/RFHhpYglgEhb1LzzBRWY69oBqVHfwuTojD buCojCvhuxZkSomVcKCLmCPBC9rPl5baf5N/ubeRPv9B9AL2zb1kDwh0EvuN3LdZs7h+ hEwHsqvCFtAvL/+j6gdZllm9oPkWNEE+fIqOb8qNGh4sxjn1xIb9GUKEEKFSlt8x0YGe 8sxA== X-Forwarded-Encrypted: i=1; AKwUvBwLoqEj5T49E9w8HNzuThnVGwkr+B8FgXOpUHibns6qTP0LNNXk0nNbyw+xERzfh6Lrb8drc8mF/Ew=@lists.xenproject.org X-Gm-Message-State: AFq9FYLAkjZItapq+7+DE2CZq9wm8Dx14K/pvkdl2xXeHeVowpwP2YFJ J+fmefT1Hov/IjA9YcKhNm7Y/aQoye7Xu/X7GTyIPiFXSKIxvuCg6iJT+COzSgYG5A== X-Gm-Gg: AYBFou1eNvWgrxB+hNTucsUGmIdnyOH8YjK7GGSdsjmVAxp08GQERIvn85wF4ur+CDi 9flYV+WE7MFpqYz2c1tp/S817j8FB20iTZemRm3HgKld+o28+qYpkf3IA99pufz5DHcGT71gOqG f+KHjxYbBnl06ICQ80sYTToqPTSdHx7pBfBbydnQJDTPxsq7HDuaTCaZgONUGSjWX4H3jw97jby h+71Xlc8E8qZCideke85A/X+SwImr56nlLHBC+3u2P+v7VLF0qIEatiYF49iCZGOBVjdi0soS+F eSYb48NxrX8kOP9PWpvq6WgEi5mKFy4lm0SGLlsuNFRmNl5/SBP6RqmVE7UM/TVkzhUpNPYd9ML tXSNYlLo2TXR1q+/sit+2f1NwU8TNd3oCOF5czY0MK+RVv1aS5cG7vpqYphf5o/VbJaVQYH+v36 fP295ngEW+eTYOWxp9Ar9wlErVIFT+qYUW+4jVCSgVaj8+CKIxoZRsXSQKavL9h6RG1weujhzZS OzVsH5RymIjRQjrPYeg5uU7Zoou3xVyJ7fzYbyhqE+z8Q9XUWIpl0Ife8o9bgfYQ6UMc/2oDIp1 WzZGki292nutZM0laZyug+2dNxuYlobhEOfcQNckPP6t6m1XZaFdZ1GuXHWdk/HMwGh8bPiw0wk K+a2UVHPhWa9xAO0CXg== X-Received: by 2002:a05:6000:2892:b0:486:e707:42eb with SMTP id ffacd0b85a97d-48e5d468078mr4877423f8f.33.1793182886145; Wed, 28 Oct 2026 03:21:26 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 11:21:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/5] tests/x86: Introduce a userspace test harness for x86_decode_lite() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20261015210530.786604-1-andrew.cooper3@citrix.com> <20261015210530.786604-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: <20261015210530.786604-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793182886-506CECFC-97AC7EC0/10/78276251493 X-purgate-type: spam X-purgate-size: 8232 On 15.10.2026 23:05, Andrew Cooper wrote: > All the interesting behaviour is in insns.S. > > There are 4 interesting cases; "not an instruction we tolerate", and one we do > tolerate, split by no relation, disp8 or disp32. The DECL()/END() macros DYM "relocation" here? > --- /dev/null > +++ b/tools/tests/x86-decode-lite/Makefile > @@ -0,0 +1,56 @@ > +XEN_ROOT = $(CURDIR)/../../.. > +include $(XEN_ROOT)/tools/Rules.mk > + > +TARGET := > + > +# Clang IAS doesn't like the convenience macros we use > +$(call cc-option-add,CFLAGS,CC,-no-integrated-as) > + > +# Binutils around 2.30 have mutually exclusive expectations of instruction > +# suffix validities compared to later versions. Among the distro we test, > +# this only excludes Ubuntu 18.04. This is liable to go stale; 18.04's lifetime can't be all that much anymore. I'd suggest to keep just the first sentence. > --- /dev/null > +++ b/tools/tests/x86-decode-lite/insns.S > @@ -0,0 +1,711 @@ > [...] > +sib: > + /* Mod=0, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */ > + _ add %al, (%rax, %rax, 8) > + _ add %al, (%rcx, %rax, 8) > + _ add %al, (%rdx, %rax, 8) > + _ add %al, (%rbx, %rax, 8) > + _ add %al, (%rsp, %rax, 8) > + _ add %al, ( , %rax, 8) /* "none", %rbp encoded with mod=1/2 */ > + _ add %al, (%rsi, %rax, 8) > + _ add %al, (%rdi, %rax, 8) > + _ add %al, (%r8, %rax, 8) > + _ add %al, (%r9, %rax, 8) > + _ add %al, (%r10, %rax, 8) > + _ add %al, (%r11, %rax, 8) > + _ add %al, (%r12, %rax, 8) > + _ rex.b add %al,(,%rax, 8) /* "none", %r13 encoded with mod=1/2 */ > + _ add %al, (%r14, %rax, 8) > + _ add %al, (%r15, %rax, 8) > + > + /* Mod=1, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */ > + _ add %al, 0x01(%rax, %rax, 8) > + _ add %al, 0x01(%rcx, %rax, 8) > + _ add %al, 0x01(%rdx, %rax, 8) > + _ add %al, 0x01(%rbx, %rax, 8) > + _ add %al, 0x01(%rsp, %rax, 8) > + _ add %al, 0x01(%rbp, %rax, 8) > + _ add %al, 0x01(%rsi, %rax, 8) > + _ add %al, 0x01(%rdi, %rax, 8) > + _ add %al, 0x01(%r8, %rax, 8) > + _ add %al, 0x01(%r9, %rax, 8) > + _ add %al, 0x01(%r10, %rax, 8) > + _ add %al, 0x01(%r11, %rax, 8) > + _ add %al, 0x01(%r12, %rax, 8) > + _ add %al, 0x01(%r13, %rax, 8) > + _ add %al, 0x01(%r14, %rax, 8) > + _ add %al, 0x01(%r15, %rax, 8) > + > + /* Mod=2, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */ > + _ add %al, 0x7f000001(%rax, %rax, 8) > + _ add %al, 0x7f000001(%rcx, %rax, 8) > + _ add %al, 0x7f000001(%rdx, %rax, 8) > + _ add %al, 0x7f000001(%rbx, %rax, 8) > + _ add %al, 0x7f000001(%rsp, %rax, 8) > + _ add %al, 0x7f000001(%rbp, %rax, 8) > + _ add %al, 0x7f000001(%rsi, %rax, 8) > + _ add %al, 0x7f000001(%rdi, %rax, 8) > + _ add %al, 0x7f000001(%r8, %rax, 8) > + _ add %al, 0x7f000001(%r9, %rax, 8) > + _ add %al, 0x7f000001(%r10, %rax, 8) > + _ add %al, 0x7f000001(%r11, %rax, 8) > + _ add %al, 0x7f000001(%r12, %rax, 8) > + _ add %al, 0x7f000001(%r13, %rax, 8) > + _ add %al, 0x7f000001(%r14, %rax, 8) > + _ add %al, 0x7f000001(%r15, %rax, 8) > + > + /* Mod=0, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */ > + _ add %al, (%rax, %riz, 8) > + _ add %al, (%rcx, %riz, 8) > + _ add %al, (%rdx, %riz, 8) > + _ add %al, (%rbx, %riz, 8) > + _ add %al, (%rsp, %riz, 8) > + _ add %al, ( , %riz, 8) /* %rbp encoded with mod=1/2 */ > + _ add %al, (%rsi, %riz, 8) > + _ add %al, (%rdi, %riz, 8) > + _ add %al, (%r8, %riz, 8) > + _ add %al, (%r9, %riz, 8) > + _ add %al, (%r10, %riz, 8) > + _ add %al, (%r11, %riz, 8) > + _ add %al, (%r12, %riz, 8) > + _ rex.b add %al,(,%riz, 8) /* %r13 encoded with mod=1/2 */ > + _ add %al, (%r14, %riz, 8) > + _ add %al, (%r15, %riz, 8) > + > + /* Mod=1, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */ > + _ add %al, 0x01(%rax, %riz, 8) > + _ add %al, 0x01(%rcx, %riz, 8) > + _ add %al, 0x01(%rdx, %riz, 8) > + _ add %al, 0x01(%rbx, %riz, 8) > + _ add %al, 0x01(%rsp, %riz, 8) > + _ add %al, 0x01(%rbp, %riz, 8) > + _ add %al, 0x01(%rsi, %riz, 8) > + _ add %al, 0x01(%rdi, %riz, 8) > + _ add %al, 0x01(%r8, %riz, 8) > + _ add %al, 0x01(%r9, %riz, 8) > + _ add %al, 0x01(%r10, %riz, 8) > + _ add %al, 0x01(%r11, %riz, 8) > + _ add %al, 0x01(%r12, %riz, 8) > + _ add %al, 0x01(%r13, %riz, 8) > + _ add %al, 0x01(%r14, %riz, 8) > + _ add %al, 0x01(%r15, %riz, 8) > + > + /* Mod=2, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */ > + _ add %al, 0x7f000001(%rax, %riz, 8) > + _ add %al, 0x7f000001(%rcx, %riz, 8) > + _ add %al, 0x7f000001(%rdx, %riz, 8) > + _ add %al, 0x7f000001(%rbx, %riz, 8) > + _ add %al, 0x7f000001(%rsp, %riz, 8) > + _ add %al, 0x7f000001(%rbp, %riz, 8) > + _ add %al, 0x7f000001(%rsi, %riz, 8) > + _ add %al, 0x7f000001(%rdi, %riz, 8) > + _ add %al, 0x7f000001(%r8, %riz, 8) > + _ add %al, 0x7f000001(%r9, %riz, 8) > + _ add %al, 0x7f000001(%r10, %riz, 8) > + _ add %al, 0x7f000001(%r11, %riz, 8) > + _ add %al, 0x7f000001(%r12, %riz, 8) > + _ add %al, 0x7f000001(%r13, %riz, 8) > + _ add %al, 0x7f000001(%r14, %riz, 8) > + _ add %al, 0x7f000001(%r15, %riz, 8) > + > + > +.macro alu_ops op Nit: Can we avoid double blank lines, please? > +onebyte_row_6x: > + /*pusha,popa,bound --> not supported */ > + _ movsxd (%rax), %eax > + _ movslq (%rax), %rax What about the (odd) 16-bit form? Decoding wise it's identical between AMD and Intel. > + _ fs nop > + _ gs nop > + _ data16 nop > + /* addr32 --> not supported */ > + _ pushq $0x7f000001 > + _ pushw $0x7f01 > + _ rex.w pushq $0x7f000001 Maybe also _ data16 rex.w pushq $0x7f000001 ? > + _ imul $0x7f01, %ax, %ax > + _ imul $0x7f000001, %eax, %eax > + _ imul $0x7f000001, %rax, %rax > + _ pushq $0 > + _ pushw $0 > + _ rex.w pushq $0 Same here then. > +onebyte_row_Fx: > + _ lock addb $0, (%rax) > + n "icebp" .byte 0xf1 > + _ repne nop > + _ repe nop > + _ hlt > + _ cmc > + _ test $0, %cl /* Grp3, /0 has extra Imm{8,} */ > + _ not %cl > + _ test $0x7f01, %cx > + _ not %cx > + _ test $0x7f000001, %ecx > + _ not %ecx > + _ test $0x7f000001, %rcx > + _ not %rcx > + _ clc > + _ stc > + _ cli > + _ sti > + _ cld > + _ std > + _ inc %cl /* Grp4 */ > + _ dec %cl > + _ inc %ecx /* Grp5 */ > + _ dec %ecx Any reason you use register operands up to here, but then ... > + _ call *(%rax) ... a memory one here and ... > + _ lcall *(%rax) > + _ jmp *(%rax) ... here? > + _ ljmp *(%rax) > + _ push (%rax) (I realize the assembler can't easily be told to encode this with a ModR/M byte when used with a register operand.) Again preferably with the above addressed (but explicitly also with some / all left as is, except perhaps the double blank line one): Acked-by: Jan Beulich > +twobyte_row_2x: > + _ mov %cr0, %rax > + _ mov %dr0, %rax > + _ mov %rax, %cr0 > + _ mov %rax, %dr0 I guess as we don't mean to use odd encodings of these (ModR/M.mod != 3), there's no value in trying to test (and support) such. > +twobyte_row_4x: > + _ cmovo (%rax), %eax > + _ cmovg (%rax), %eax > + > +/* twobyte_row_8x: --> Jcc disp32 */ Hmm, noticing only here: You do not foresee a need to support VMREAD/VMWRITE? Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 10:30:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 10:30:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463055.1674021 (Exim 4.92) (envelope-from ) id 1xM0uo-0008No-EX; Wed, 28 Oct 2026 10:29:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463055.1674021; Wed, 28 Oct 2026 10: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 1xM0uo-0008Nh-Bd; Wed, 28 Oct 2026 10:29:54 +0000 Received: by outflank-mailman (input) for mailman id 1463055; Wed, 28 Oct 2026 10:29:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM0un-0008Nb-SF for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:29:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM0un-00Af6f-94 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:29:53 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1ce92-2eae-0a2a0a5409dd-0a2a4509dc60-34 for ; Wed, 28 Oct 2026 11:29:53 +0100 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 6ae1cea0-be1a-0a2a45090019-b9ff1c238ddd-3 for ; Wed, 28 Oct 2026 11:29:53 +0100 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 1a1820f0ebb000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 10:29: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 6D92A83509; Wed, 28 Oct 2026 11:29:46 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=oM7KOaX6VYIVdfV4XMb2iaEBJtdIPAO5A7bZbhUGGuU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Ln5RKd+uyBIocE1piY60w3D7zqQgxx2x+cO4+FDdKQV00BruxjrIMnOst+OAxdIghmtYiZcgp 2I6/QNMQARfQPXYNLdyQjKwQD/58H1mnw9wYoN+S1GbB3TgQOxi3e3M1F3RvVV+luOUFlWsrAn6 11n9g0NVDZFFiD+x+UKGUcJc0+/Oz5pD9UNYwlMpLnOSuEQSIosrUZ3NK4Zq9VOxkA3G4Db7moJ nZL1+NT4l8JOmL6u79ZLiTRdHkkcf58osVWLAXC+7SuNLBQi9sMSf8gQZ2x79i0QILMBZqlKXTu seQflLlZKmd5/yNeqsazc/CxHuStEfFERPJRa9CkXDnQ== X-Zone-Loop: ea7eaeee92fe54395ba15fdcf214a3447410c4e34a94 x-campaign-type: default x-transaction-id: 9c87ed07-66c1-49fe-bb9a-983c08c370ff x-swg-uid: 01-abb7c1ab-55d9-447b-85ae-e625e29646f2 X-Mailer: Sweego Message-ID: <1793183387.8631fc262581453bbf619ec5b2062170.1a1820f0ebb000f79f@vates.tech> x-swg-bid: 1793183387.8631fc262581453bbf619ec5b2062170.1a1820f0ebb000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 11:29:46 +0100 From: Anthony PERARD To: Oleksii Kurochko , Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Stefano Stabellini Subject: Re: [PATCH v2 1/6] Add a QTB container to run the Xen riscv64 tests References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823787.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@vates.tech> <846f2ec6-da73-4f12-b46f-5e9f841e35ad@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <846f2ec6-da73-4f12-b46f-5e9f841e35ad@gmail.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.27f.811fb402820a95f1.1a1820f0be8.6028f5c9945de376=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793183386600 X-purgate-ID: tlsNG-bad1c0/1793183393-FC610034-570353F1/10/63158204843 X-purgate-type: spam X-purgate-size: 2933 ---=Part.27f.811fb402820a95f1.1a1820f0be8.6028f5c9945de376=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 22, 2026 at 03:28:26PM +0200, Oleksii Kurochko wrote: > On 8/27/26 11:42 AM, Baptiste Le Duc wrote: > > --- > > containerize | 1 + > > images/debian/13-qtb-riscv64=2Edockerfile | 45 +++++++++++++++++++++= ++++ >=20 > This is more a question for the CI maintainers: should this container > live in test-artifacts at all? >=20 > So far test-artifacts only holds containers for building its own > artifacts (kernels, rootfs, microcode), which xen=2Egit then pulls in vi= a > cross-project needs:=2E The containers the xen=2Egit test jobs run in, > including debian:13-riscv64, which already carries > qemu-system-riscv64 for the test phase, and the hardware runner ones, > are all built from automation/build/ in xen=2Egit and pulled from > XEN_REGISTRY=2E >=20 > Having it as automation/build/debian/13-qtb-riscv64=2Edockerfile in > xen=2Egit would keep the container next to its only user, avoid the new > ARTIFACTS_REGISTRY variable and the image: override in patch 6, and > drop the "must land first" ordering between two repositories=2E Indeed, the new container would fit better in the `xen=2Egit` tree=2E And can you rename the container? I think the format is "$distrib/$release-$arch-$comments" I guess $arch here should be "x86_64", with the comment saying "qtb-riscv64"=2E > > diff --git a/images/debian/13-qtb-riscv64=2Edockerfile b/images/debian= /13-qtb-riscv64=2Edockerfile > > new file mode 100644 > > index 0000000=2E=2E86215d3 > > --- /dev/null > > +++ b/images/debian/13-qtb-riscv64=2Edockerfile > > @@ -0,0 +1,45 @@ > > +# syntax=3Ddocker/dockerfile:1 > > +FROM --platform=3Dlinux/amd64 debian:trixie-slim > > +LABEL maintainer=2Ename=3D"The Xen Project" > > +LABEL maintainer=2Eemail=3D"xen-devel@lists=2Exenproject=2Eorg" > > + > > +ENV DEBIAN_FRONTEND=3Dnoninteractive > > + > > +ARG QEMU_REPO=3Dhttps://gitlab=2Ecom/xen-project/people/amd/qemu=2Egi= t > > +ARG QEMU_COMMIT=3D24cd7e5c0d7e4db8e651f091d0b9da2e7c58dbab > > + >=20 > This commit is currently the tip of the 'safety' branch, and no tag > points to it=2E If that branch gets rebased, the commit may become > unreachable and the container will no longer rebuild=2E Could a tag be > created for it in the fork? I would rather keep the commit hash, but adding a comment that it's the `safety` branch would be useful=2E Having the container fails to build because the commit disappear is better I think than having the test failed because the branch have changed the way qtb is implemented=2E Cheers, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.27f.811fb402820a95f1.1a1820f0be8.6028f5c9945de376=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 10:40:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 10:40:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463064.1674030 (Exim 4.92) (envelope-from ) id 1xM15J-0002lX-C3; Wed, 28 Oct 2026 10:40:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463064.1674030; Wed, 28 Oct 2026 10:40: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 1xM15J-0002lQ-9T; Wed, 28 Oct 2026 10:40:45 +0000 Received: by outflank-mailman (input) for mailman id 1463064; Wed, 28 Oct 2026 10:40:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM15I-0002lK-9V for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:40:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM15H-006a0V-Iy for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:40:43 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1d12b-8faa-0a2a0a5109dd-0a2a450280fe-2 for ; Wed, 28 Oct 2026 11:40:43 +0100 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 6ae1d12b-6ca4-0a2a45020019-a237832f8d62-3 for ; Wed, 28 Oct 2026 11:40:43 +0100 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 229D34EE0216; Wed, 28 Oct 2026 11:40:43 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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=1793184043; b=i865FpOIqCQZCin9GJ5Y54QbbfmQGc7X2hqnvn8cjfX+Rd/6Z88Ac3yfomXkDp4Y4AxH zoQkTCSekD95sZTt7R6k4SGUpkGxlU1TzVlWCdDqVJhpmV8I1eYe+CA0gDJ2lgOROiYub tOVuo3RUwMrzWc9S206XRANw8i9pUl9RC58744oR1MEuZVNyjDUuOT7wSBRJAiu/mpyOh wGuRVrMxWZ6O6Pz4X42/+ioOW+xfHqgiMLlQAiIYJhjmYf5GVKMJcbCrGUNBHVaKlN0w2 aDbKThccz8vQ2jQS4Qut81TgbZBHxH/v1APt5OsflAJxCniPqEzUv3ccbRZXNPk6HqjVt MIxeiZy76IBJDw7tl4chZQD/Loqia2uMOzmqIImKkQE5E5Rlr3Y+D2IOrcXkMP4wXZot3 GCs1nVL+P2nZLKe0y4DY6Bpt3bPh0Qc5ghHVJ/GMKLohysITX6sREjwfKa+xUOM/R5SLa fNUe4mG9gvBMsurl7P9ZXATNOiDhTPWnvKPmysbxRNsT1wkOxxmXKQeGWLmTOv4/r7BlL 8JL5H+Ire889F4znhDIGlCeqe04nIPYQGcBw7A9ZgP2QBg7wzQW8FXMdwCeou9sIESqH0 9dI5kIoRkard3j1osSVm/gEb92biidG96TyGsUZ9LKqXl0xXJRiOlbW9OmyiQ50= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1793184043; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=jl4yoVqNP/AdEYmlEgxjx1N8zYUsTpg7wQt86D6War0=; b=5tv8JlYuVXiQN0sZ4GNCDT2bF+7hz6AqgloLUS0uWRXGH+bapqBU0RO68U5SMmFKKvjO R6oqGkvfV4GOL/UtT/5kHCoa2U6bE4ETuC3lC7KGpBQwC2JelyUIv+CGZWmUTbTqLnRIe szqQRq0BxzoFtPrQ8o1GccJbqGTimATGucq+hsbMsSBuN4CuYu73+jc/M4qzVJsQSYZFc LIgxZcmbcKG/IXIBLZ8Vy1vJWyTsiI7vmcya+J5i+3wRJ6lgS1tl1mSZ+jem8Fu1eEu4G huuh9ktZgvewYMa3IXvl2NilgojwYkkm3WLb3Dlh/X1kv0ytmH904rIYbVcCgupAXcG93 j/Sv7Xl+yhVLGyJfi7M7G5ANONL5TP57G5xtQ1zPREYyFe74Fu9dD8jcg86t4FcmCW80i QGDhs6mKDpli+MnsVv/S04XiDw3QDkH0vfLf4WfsAEslbS2x2QFW7dYkLKoWMzLMe3tPx 65mOXJxfUyEbEKv/vF/HSefOPzCfvLa4GsCyy9c70pHH7Q+9W6dfE+KeHeT5zxgq0cBK/ uTrGKDjON0LvBvICq+Cotxu5+o1iEVwxydnXxNB4mZCKrY2kOKIeVXU8/JqX5VHarMAUo 63M4Yg5+d74lwpUEqpTM8BdIAn/NPEoIXC+5F/8T3yn4/D/s7ItVW9NqVaWZ26c= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Wed, 28 Oct 2026 11:40:43 +0100 From: Nicola Vetrini To: Jan Beulich Cc: Shuaidong Chen , Stefano Stabellini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH] xen/typesafe: don't brace-initialize a scalar TYPE_SAFE value In-Reply-To: <0af0a00b-4f9a-4584-ac5b-554ae00e692e@suse.com> References: <20261028050336.2549325-1-shuaidong.chen@amd.com> <0af0a00b-4f9a-4584-ac5b-554ae00e692e@suse.com> Message-ID: <25c7537efec9c2a12307fd564f564c45@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-720697/1793184043-317CA2AC-A0C4C95D/0/0 X-purgate-type: clean X-purgate-size: 3418 On 2026-10-28 08:42, Jan Beulich wrote: > On 28.10.2026 06:03, Shuaidong Chen wrote: >> TYPE_SAFE() degrades to a plain typedef in non-debug builds (NDEBUG), >> so >> mfn_t is then `unsigned long' rather than a one-member struct. >> INVALID_MFN_INITIALIZER and INVALID_GFN_INITIALIZER, however, always >> expand to `{ ... }', which leaves >> >> mfn_t first_valid_mfn = { ~0UL }; >> >> initializing a scalar from a braced list. That is valid C, but MISRA >> C:2012 Rule 9.2 (required) - "The initializer for an aggregate or >> union >> shall be enclosed in braces" - is reported against it, twice in the >> x86_64 build: common/page_alloc.c and arch/x86/efi/runtime.h. > Wait - the rule says the opposite; it says nothing about initializers > of > scalars. The rule is clean in all analysis jobs we do. On staging we > only > ever have debug builds analyzed, but on release branches *-allcode have > DEBUG=n. No 9.2 violation shows up there. You also don't point at > Eclair > output supporting your claim, so I wonder what is going on here. > > Further, "That is valid C" contradicts ... > This was actually an FP present in ECLAIR 3.14.0 (used by Xen), not an actual violation: 1|$ /opt/bugseng/eclair-3.14.0/bin/eclair_env -enable=MC3A2.R9.2,B.REPORT.TXT -- gcc -c /tmp/fp.c -o /dev/null violation for rule MC3A2.R9.2: (required) The initializer for an aggregate or union shall be enclosed in braces. (untagged) /tmp/fp.c:1.9-1.11: Loc #1 [culprit: to initialize `int' it was expected a scalar but found a compound with 1 element] int x = {2}; <~> nicola@nico:~ 0|$ eclair_env -enable=MC3A2.R9.2,B.REPORT.TXT -- gcc -c /tmp/fp.c -o /dev/null nicola@nico:~ 0|$ cat /tmp/fp.c int x = {2}; It has been fixed since ECLAIR 3.15.0. How to proceed (document as FP or modify the source to avoid it) is up to the project. >> --- a/xen/include/xen/typesafe.h >> +++ b/xen/include/xen/typesafe.h >> @@ -9,12 +9,17 @@ >> * * _$FOO() which boxes a $TYPE as a $FOO_t >> * * $FOO_x() which unboxes a $FOO_t to $TYPE >> * >> + * TYPE_SAFE_INIT($VAL) spells a constant initializer for a $FOO_t, >> for use >> + * where _$FOO() cannot be (an object of static storage duration). >> + * >> * This makes a $FOO_t and a $BAR_t incompatible even when the box >> the same >> * $TYPE. >> * >> * It does have some performance cost because the types now have a >> different >> * storage attribute, so type safety is only enforced in a debug >> build. >> - * Non-debug builds degrade to a simple typedef and noops for the >> functions. >> + * Non-debug builds degrade to a simple typedef and noops for the >> functions, >> + * and with it TYPE_SAFE_INIT() loses its braces: a scalar must not >> be >> + * brace-initialized. >> */ > > ... the new wording used here. > > Also, in the earlier insertion above, isn't there "used" missing? > Possibly, to > avoid the double use of "use", with the earlier "use" replaced by > "cases"? Yet > maybe this is legal grammar anyway, and it merely feels odd to me as a > non- > native speaker. A native speaker may want consulting. > > I also wonder why you CC-ed Roger with his old Citrix address. > > Jan -- 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 Oct 28 10:46:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 10:46:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463074.1674040 (Exim 4.92) (envelope-from ) id 1xM1Ag-0003Mu-0Z; Wed, 28 Oct 2026 10:46:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463074.1674040; Wed, 28 Oct 2026 10:46: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 1xM1Af-0003Mn-U6; Wed, 28 Oct 2026 10:46:17 +0000 Received: by outflank-mailman (input) for mailman id 1463074; Wed, 28 Oct 2026 10:46:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM1Af-0003Mh-39 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:46:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM1Ae-00Aica-7W for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:46:16 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1d271-e002-0a2a0a5209dd-0a2a4505cc2e-42 for ; Wed, 28 Oct 2026 11:46:16 +0100 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1d277-4cb1-0a2a45050019-d155dd2fb060-3 for ; Wed, 28 Oct 2026 11:46:15 +0100 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48af4d4e61fso484550f8f.2 for ; Wed, 28 Oct 2026 03:46: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-48e3ebcb902sm29196460f8f.24.2026.10.28.03.46.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 03:46: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=1793184375; x=1793789175; 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=wYaL/UAyYGY1+l41s79f/K+xV0JStq9HH+IMzKIz5lQ=; b=NMJ1cLj2XsUKmkUS3RyTitaQ0OB1t7bYHPEJsYHqUpStCY2GWV8rOEtx7vsx7j+4PO wB1A/CF/zb3fcoIydVIAZLwfPXNLPHeOQNqpPuV9bprApv/um/NxMnQnENP4SMlD76ru Hrl78f7kvazq64r4L0nZOLiCeuHa7CUrs49XLfd5pW2UTiQvkJt3JcKVUEJbp3CT/CpB kxlrCAVgHzM2Z7G/PWjH7XSUzdtibFjh7ufbc2B+/r6F0f+0gH4nt8ZCa1tAVpApONv6 o48t3+hlrA8jHjdvlYCJFpH/exfXPHKlagnbAEVKpecH3erjEsxcZ12G6ATshq1CJaiF rLAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793184375; x=1793789175; 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=wYaL/UAyYGY1+l41s79f/K+xV0JStq9HH+IMzKIz5lQ=; b=zjJqTXztXwx9sHLb8jGas0rCmvoLckTPPwJEPD34EHaD1LXScejv4Mu5EB19ntQo3b tC0k3cEHmrtcCFQse1fhMPUFPZ9jEezjHNIS4NRGLH322p3cNjGT9ZZfjy1pAt43tr0C jJ6K2ju2VukJktRo8578bYdrGKW4ligE7iTg+sRU4eMA6ZsDgFItWaus+DYh8MbpbCVa AhyLNB8ztw/nD4p3Ze4ncfbquc1Y/cAxdqQofdHEavpAPC8ykra7Z71tE9V6Kf5zqExX V8Y6+9zMmkZq7V3f3Bdn5WiOasb6RBMPF2AggNtNXpchuVF7oqRxK4hprAApR0EWkmVM i3Sg== X-Forwarded-Encrypted: i=1; AKwUvBwVtTmEE7A0eeiY8VA8aNUKQnBHKKpsJupX6mCT85wqs0NRhOsm69Yxk17SpjgrjWkpXLJTPlznOBg=@lists.xenproject.org X-Gm-Message-State: AFq9FYLhzpYnX8ZPpaVPkWlPTK1G/wxofvsPhK/VGikMq9FRAMC89yw2 cEHTlLX4RRwVP/n4dNZQECYbualSjWF9pxc0POlvy5WzD2xfqw4lDO/7YTL7l+JpWQ== X-Gm-Gg: AYBFou0W/jw5bV0MJToK3dy4EzdQGYP4zm91FwVVvAUHa+UbyiC58CLkarchpVC6qxa BeXRl8ueJKxPE6KpK73m5bYfL2rW+DwRmRBId3npdpDnEUPBZw+WDorQtGrhe4v6UJvVHTCKnNf KF0G7+ScOEGdY/E2Lak4u6ftihrZRq7GnhdnTWTmTDMBBokLtqjJOCBpc6+elX9uRN/rSbIcYgz GOKJ9DLIAMawZl8GehPteXRlKb5Bdpse6yVmlJ2L/AIditJghvzwmO+bBgiMe5XjGidmjJ8Abji 3Mrye3mFe0oxKqwgPUoyXOU1aWIzAvISJ+fKg5QvDpzqvN6aeDctLU9tvJthYqkULDaA3nGdvMD GoiXmU6iVpt0DXlC6WPwtzsqK5cvPf/uplKPkUcrn52TmmYT7DKohNgojPRt8QA4sR0UkHMohCj vAOvh8UREF5Keh4oJedvbY+7/4waJLeWSRYL6Imi8BevdPZLiYhm6oRm0rD2/Sqjh/qiVB/GZNb Ai2WXh9PRBt1M+PvKQmR5eRESZ5fTtCTbaNNJ/0/O3LECgGoJOfrI4ItUx4ExZBiAjggyPSYNVX GgQ3Td1uBYKBnmiYFhxD6nT3gheQa4F06FTWEQK+lL2Dbz/OxNKu5W2dqi6h5HXeTYeoc6XLSEY 8sfchdCfVE9K4NUFOqQ== X-Received: by 2002:a05:6000:46dc:b0:48d:ef7d:4b4c with SMTP id ffacd0b85a97d-48e5d5d9113mr2910060f8f.44.1793184375183; Wed, 28 Oct 2026 03:46:15 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 11:46:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/ns16550: identify XScale UARTs from device tree To: Zhang Zheng Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3e8fac86f88d9d3d002b86469b87c20aea53fcef.1792467713.git.zhangzheng@iscas.ac.cn> 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: <3e8fac86f88d9d3d002b86469b87c20aea53fcef.1792467713.git.zhangzheng@iscas.ac.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1793184375-F7EB92A1-28D672DE/10/78276251493 X-purgate-type: spam X-purgate-size: 621 On 20.10.2026 05:45, Zhang Zheng wrote: > Identify XScale UARTs using intel,xscale-uart, since IER bit 6 has other > meanings on some UART variants. Keep UUE set when writing IER so the > UART stays enabled when switching to polling, and enable RTOIE along > with receive interrupts. The RTOIE part needs more than just mentioning; it may even want splitting off into a separate patch. It's not clear to me why setting this bit is entirely benign to existing code, i.e. in particular why the present interrupt handler doesn't need any adjustment to cope with the new reason that it may be invoked for. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 10:55:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 10:55:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463082.1674050 (Exim 4.92) (envelope-from ) id 1xM1Jw-0005E5-Sz; Wed, 28 Oct 2026 10:55:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463082.1674050; Wed, 28 Oct 2026 10: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 1xM1Jw-0005Dy-Ow; Wed, 28 Oct 2026 10:55:52 +0000 Received: by outflank-mailman (input) for mailman id 1463082; Wed, 28 Oct 2026 10:55:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM1Ju-0005Ds-Mn for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 10:55:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM1Jt-009ij7-4G for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:55:49 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1d4aa-2eae-0a2a0a5409dd-0a2a4503c290-34 for ; Wed, 28 Oct 2026 11:55:49 +0100 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 6ae1d4b4-fae8-0a2a45030019-b9ff1c22b25d-3 for ; Wed, 28 Oct 2026 11:55:48 +0100 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 1a18226d2c6000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 10:55:44 +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 E076F82ED0; Wed, 28 Oct 2026 11:55:43 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=Bk6zPrFGbEjKNsx3I59RfkiF7wCSlT76psb7b/fCFAE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=bTHnoy1hDTIFirdBqAHZrm2hjM5wCqeSSlVLiTIvSTJRVJzyStm2GHlgvFJgQ4EtCSXqr0HTn whjLHhGlpiF4Go0Nw98amVlDSZzxsYqlbxUnZYT4CYGYgTERb/MR7egzHge3V4Q3ISSV+GYA6gE GPaqcsEGrEf1x2USBaly2Uw2Kovkk5iovM/vlX4Fv8WPzN5wVj8GmbHXsUFdSnI/GLbnabJOOZq xTGrHca5mB0MO6ldkqRDHF1lIN55M1dJEVRSnjS/qU8FTxgywYLy514p3NhLiSe1DAQOXyufzqA KYKLhcsm07q5C6FzS7UwDCShyqmSNrF3hIMX9xT6hpyw== X-Zone-Loop: e1c6572b5ce5e4cc52c66b6b15ba4b31197dc8ab52bf x-campaign-type: default x-transaction-id: befd11ac-a6a3-44ca-8544-d2943793a724 x-swg-uid: 01-7b99032c-9045-4d50-b7ef-8ec266793a81 X-Mailer: Sweego Message-ID: <1793184944.8631fc262581453bbf619ec5b2062170.1a18226d2c6000f79f@vates.tech> x-swg-bid: 1793184944.8631fc262581453bbf619ec5b2062170.1a18226d2c6000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 11:55:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/9] tools/libs/guest: decompress LZ4 PAGE_DATA records on restore To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-4-marcus.granado@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: <20261020200238.1815766-4-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------L6fIDp1DQsjChtFL0M06GveO" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793184944080 X-purgate-ID: tlsNG-33051d/1793184949-7448C4E9-2FEC25CD/0/0 X-purgate-type: clean X-purgate-size: 32996 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------L6fIDp1DQsjChtFL0M06GveO Content-Type: multipart/mixed; boundary="------------c3WlZovtFMsnSaUphS93vHZl"; protected-headers="v1"; hp="clear" Message-ID: Date: Wed, 28 Oct 2026 11:55:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/9] tools/libs/guest: decompress LZ4 PAGE_DATA records on restore To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-4-marcus.granado@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: <20261020200238.1815766-4-marcus.granado@citrix.com> --------------c3WlZovtFMsnSaUphS93vHZl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjoxMCwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g UEFHRV9EQVRBIHJlY29yZHMgY2FycnkgcGFnZSBjb250ZW50cyB1bmNvbXByZXNzZWQ7IGFs Z29yaXRobSAweDAwIGlzDQo+IHRoZSBvbmx5IG9uZSBhc3NpZ25lZCBpbiB0aGVpciBmbGFn cyBmaWVsZC4gIENvbXByZXNzaW5nIHRoZW0gd291bGQgcHV0DQo+IGxlc3MgZGF0YSBvbiB0 aGUgd2lyZSBkdXJpbmcgbWlncmF0aW9uLCBhdCBhIENQVSBjb3N0IG9uIGJvdGggaG9zdHMs DQo+IHdvcnRoIHBheWluZyB3aGVyZSB0aGUgYm90dGxlbmVjayBpcyB0aGUgbGluaywgb3Ig ZW5jcnlwdGlvbiBvZiB0aGUNCj4gc3RyZWFtIGJ5IHNzaCBvciBUTFMuDQo+IA0KPiBBc3Np Z24gYWxnb3JpdGhtIDB4MDEgKFBBR0VfREFUQV9BTEdPX0xaNCkgdG8gTFo0LCBhbmQgZGVj b2RlIGl0IG9uDQo+IHJlc3RvcmUuICBwYWdlX2RhdGEgaXMgdGhlbiBvbmUgTFo0IGZyYW1l OiBMWjQgZm9yIGl0cyBzcGVlZCwgYW5kIGl0cw0KPiBGcmFtZSBGb3JtYXQgYmVjYXVzZSBp dCBpcyBzcGVjaWZpZWQgb3V0c2lkZSBYZW4sIGRlbGltaXRzIGl0c2VsZiBhbmQNCj4gY2Fu IGNhcnJ5IGJsb2NrIGNoZWNrc3Vtcy4gIFRoaXMgZW5jb2RpbmcgcmVxdWlyZXMgdGhlc2Ug Y2hlY2tzdW1zLCBhcw0KPiB3aXRob3V0IHRoZW0gYSBjb3JydXB0ZWQgZnJhbWUgY2FuIGRl Y29kZSBpbnRvIHdyb25nIHBhZ2UgY29udGVudHM7DQo+IGxpYmx6NCBhY2NlcHRzIGEgZnJh bWUgd2l0aG91dCB0aGVtLCBzbyB0aGUgZGVjb2RlciBjaGVja3MgdGhlDQo+IGJsb2NrLWNo ZWNrc3VtIGZsYWcgaXRzZWxmLg0KPiANCj4gVGhlIG91dHB1dCBzaXplIGNvbWVzIGZyb20g dGhlIHBmbiBhcnJheSwgYW5kIHRoZSBmcmFtZSBtdXN0IGRlY29kZSB0bw0KPiBleGFjdGx5 IHRoYXQgc2l6ZSBhbmQgZW5kIHdoZXJlIHRoZSByZWNvcmQgZW5kcy4gIEJlZm9yZSBkZWNv ZGluZywgdGhlDQo+IHJlY29yZCBtdXN0IGhhdmUgbm8gbW9yZSBwYWdlcyBvZiBkYXRhIHRo YW4gdGhlIGRlY29kZXIncyBidWZmZXIgaG9sZHMNCj4gKHRoZSBtb3N0IHRoZSBzYXZlciBw dXRzIGluIGEgcmVjb3JkKSwgYW5kIGEgcGF5bG9hZCBzdHJpY3RseSBzaG9ydGVyDQo+IHRo YW4gdGhlIHVuY29tcHJlc3NlZCBwYWdlIGRhdGEuICBUaGUgc3RyZWFtIHNwZWNpZmljYXRp b24gcmVxdWlyZXMgdGhlDQo+IGxhdHRlciBmb3IgYSBzYXZlcjogaXQgbWFrZXMgYW4gb2xk ZXIgbGlieGVuZ3Vlc3Qgd2hpY2ggaWdub3JlcyB0aGUNCj4gZmxhZ3MgZmllbGQgZmFpbCBp dHMgZXhhY3QgbGVuZ3RoIGNoZWNrIG9uIHRoZXNlIHJlY29yZHMsIHJhdGhlciB0aGFuDQo+ IHRha2UgdGhlIGZyYW1lIGZvciBwYWdlIGNvbnRlbnRzLg0KPiANCj4gTm90aGluZyBlbWl0 cyBhbGdvcml0aG0gMHgwMSB5ZXQsIHNvIHJlY2VpdmVycyBjYW4gYmUgdXBkYXRlZCBmaXJz dC4NCj4gUmVzdG9yZSBoYXMgbm8gb3B0aW9uIHRvIHR1cm4gaXQgb24gb3Igb2ZmOiBhbnkg c3RyZWFtIG1heSB1c2UgaXQuDQo+IA0KPiBUaGUgZGVjb2RlciBpcyBndWFyZGVkIGJ5IFhH X1NSX0xaNCwgd2hpY2ggeGdfc3JfY29tbW9uLmggZGVmaW5lcyB3aGVuDQo+IEhBVkVfTFo0 IGlzIHNldCBhbmQgbGlibHo0IGlzIDEuOC4xIG9yIGxhdGVyLCBhdm9pZGluZyByZWxlYXNl cyB3aXRoDQo+IGtub3duIGRlY29kZXIgYnVncy4gIEEgYnVpbGQgd2l0aG91dCBYR19TUl9M WjQgcmVqZWN0cw0KPiBhbGdvcml0aG0gMHgwMSB3aXRoIGFuIGVycm9yIG5hbWluZyB0aGUg bWlzc2luZyBMWjQgc3VwcG9ydC4gIGNvbmZpZ3VyZQ0KPiBwdXRzIC1ESEFWRV9MWjQgYW5k IGxpYmx6NCdzIENGTEFHUyBpbiBaTElCX0NGTEFHUywgd2hpY2ggb25seQ0KPiB4Z19kb21f YnppbWFnZWxvYWRlci5vIHVzZWQ6IGFwcGx5IGl0IHRvIGV2ZXJ5IGxpYnhlbmd1ZXN0IG9i amVjdCwgc28NCj4gdGhhdCBIQVZFX0xaNCwgYW5kIHRoZSBsYXlvdXQgb2YgYW55IHN0cnVj dHVyZSB0aGF0IGRlcGVuZHMgb24gaXQsDQo+IGNhbm5vdCBkaWZmZXIgYmV0d2VlbiBvYmpl Y3RzLg0KPiANCj4gVGhlIFB5dGhvbiBzdHJlYW0gdmFsaWRhdG9yIGNoZWNrcyBhbGdvcml0 aG0gMHgwMSdzIHBheWxvYWQgbGVuZ3RoIGFuZA0KPiBibG9jay1jaGVja3N1bSBmbGFnLCBh bmQgdGVzdF9wYWdlX2RhdGFfZmxhZ3MgZ2FpbnMgTFo0IGNhc2VzLg0KPiANCj4gU3VnZ2Vz dGVkLWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4NCj4gQXNzaXN0 ZWQtYnk6IENsYXVkZTpjbGF1ZGUtb3B1cy01LTUNCj4gU2lnbmVkLW9mZi1ieTogTWFyY3Vz IEdyYW5hZG8gPG1hcmN1cy5ncmFuYWRvQGNpdHJpeC5jb20+DQo+IC0tLQ0KPiANCj4gTm90 ZXM6DQo+ICAgICAgQ2hhbmdlcyBpbiB2MjoNCj4gICAgICAtIFdhcyB2MSAyLzYsIHdoaWNo IGRlY29kZWQgcGVyLXBhZ2UgTFo0IGJsb2NrcyBmcm9tIGEgbmV3IFBBR0VfREFUQV9MWjQN Cj4gICAgICAgIHJlY29yZC4gIE5vdyBQQUdFX0RBVEEgYWxnb3JpdGhtIDB4MDE6IG9uZSBM WjQgZnJhbWUgcGVyIHJlY29yZCwgYXMNCj4gICAgICAgIFRlZGR5IEFzdGllIHN1Z2dlc3Rl ZCwgd2l0aCBtYW5kYXRvcnkgYmxvY2sgY2hlY2tzdW1zLg0KPiAgICAgIC0gVGhlIHVuY29t cHJlc3NlZCBzaXplIGFza2VkIGZvciBieSBUZWRkeSBBc3RpZSBhbmQgRnJlZGlhbm8gWmln bGlvDQo+ICAgICAgICBjb21lcyBmcm9tIHRoZSBwZm4gYXJyYXk7IHRoZSBkZWNvZGUgYnVm ZmVyIGhhcyBhIGZpeGVkIHNpemUuDQo+IA0KPiAgIGRvY3Mvc3BlY3MvbGlieGMtbWlncmF0 aW9uLXN0cmVhbS5wYW5kb2MgfCAgMjQgKysrLQ0KPiAgIHRvb2xzL2xpYnMvZ3Vlc3QvTWFr ZWZpbGUgICAgICAgICAgICAgICAgfCAgIDIgKy0NCj4gICB0b29scy9saWJzL2d1ZXN0L3hn X3NyX2NvbW1vbi5oICAgICAgICAgIHwgIDE2ICsrKw0KPiAgIHRvb2xzL2xpYnMvZ3Vlc3Qv eGdfc3JfcmVzdG9yZS5jICAgICAgICAgfCAxNDEgKysrKysrKysrKysrKysrKysrKysrKy0N Cj4gICB0b29scy9saWJzL2d1ZXN0L3hnX3NyX3N0cmVhbV9mb3JtYXQuaCAgIHwgICAxICsN Cj4gICB0b29scy9weXRob24veGVuL21pZ3JhdGlvbi9saWJ4Yy5weSAgICAgIHwgIDIzICsr KysNCj4gICB0b29scy9weXRob24veGVuL21pZ3JhdGlvbi90ZXN0cy5weSAgICAgIHwgIDMx ICsrKystDQo+ICAgNyBmaWxlcyBjaGFuZ2VkLCAyMjkgaW5zZXJ0aW9ucygrKSwgOSBkZWxl dGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kb2NzL3NwZWNzL2xpYnhjLW1pZ3JhdGlv bi1zdHJlYW0ucGFuZG9jIGIvZG9jcy9zcGVjcy9saWJ4Yy1taWdyYXRpb24tc3RyZWFtLnBh bmRvYw0KPiBpbmRleCBmZDQ0ZGQ2ZTBhLi4yZDI1ZTcwZTEzIDEwMDY0NA0KPiAtLS0gYS9k b2NzL3NwZWNzL2xpYnhjLW1pZ3JhdGlvbi1zdHJlYW0ucGFuZG9jDQo+ICsrKyBiL2RvY3Mv c3BlY3MvbGlieGMtbWlncmF0aW9uLXN0cmVhbS5wYW5kb2MNCj4gQEAgLTQwLDggKzQwLDYg QEAgTm90IFlldCBJbmNsdWRlZA0KPiAgIFRoZSBmb2xsb3dpbmcgZmVhdHVyZXMgYXJlIG5v dCB5ZXQgZnVsbHkgc3BlY2lmaWVkIGFuZCB3aWxsIGJlDQo+ICAgaW5jbHVkZWQgaW4gYSBm dXR1cmUgZHJhZnQuDQo+ICAgDQo+IC0qIFBhZ2UgZGF0YSBjb21wcmVzc2lvbi4NCj4gLQ0K PiAgICogQVJNDQo+ICAgDQo+ICAgDQo+IEBAIC0zMDUsNyArMzAzLDI0IEBAIGZsYWdzICAg ICAgIEJpdCA3LTA6ICBBbGdvcml0aG0gdXNlZCB0byBlbmNvZGUgcGFnZV9kYXRhLg0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAweDAwOiBOb25lLiAgcGFnZV9kYXRhIGlzIHBhZ2Vf c2l6ZSBvY3RldHMgb2YNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5jb21w cmVzc2VkIGNvbnRlbnRzIHBlciBwcmVzZW50IHBhZ2UuDQo+ICAgDQo+IC0gICAgICAgICAg ICAgICAgICAgICAgMHgwMSAtIDB4RkY6IFVuYXNzaWduZWQuDQo+ICsgICAgICAgICAgICAg ICAgICAgICAgMHgwMTogTFo0LiAgcGFnZV9kYXRhIGlzIGEgc2luZ2xlIExaNCBmcmFtZSwg YXMNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbmVkIGJ5IHRoZSBMWjQg RnJhbWUgRm9ybWF0IHNwZWNpZmljYXRpb25bXjFdLA0KPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHdob3NlIGRlY29tcHJlc3NlZCBjb250ZW50IGlzIHBhZ2Vfc2l6ZSBvY3Rl dHMNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgZWFjaCBwcmVzZW50IHBh Z2UuICBBIHJlc3RvcmluZyBzaWRlIG11c3QNCj4gKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZWplY3QgYSBmcmFtZSB3aGljaCBkb2VzIG5vdCBkZWNvZGUgdG8gZXhhY3RseQ0K PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgbWFueSBvY3RldHMsIG9yIHdo aWNoIGRvZXMgbm90IGVuZCB3aGVyZQ0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg IHBhZ2VfZGF0YSBlbmRzLg0KPiArDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhlIGZyYW1lIG11c3Qgc2V0IHRoZSBibG9jay1jaGVja3N1bSBmbGFnIGluDQo+ICsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaXRzIGZyYW1lIGRlc2NyaXB0b3IsIGFuZCBhIHJl c3RvcmluZyBzaWRlIG11c3QNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWpl Y3Qgb25lIHdoaWNoIGRvZXMgbm90Lg0KPiArDQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQSBzYXZpbmcgc2lkZSBtYXkgb25seSB1c2UgdGhpcyB2YWx1ZSB3aGVuIHRoZQ0K PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyYW1lIGlzIHN0cmljdGx5IHNob3J0 ZXIgdGhhbiB0aGUgdW5jb21wcmVzc2VkDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgcGFnZV9kYXRhIGl0IHJlcGxhY2VzOyBvdGhlcndpc2UgaXQgbXVzdCBzZW5kIHRoZQ0K PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlY29yZCB3aXRoIGFsZ29yaXRobSAw eDAwLg0KPiArDQo+ICsgICAgICAgICAgICAgICAgICAgICAgMHgwMiAtIDB4RkY6IFVuYXNz aWduZWQuDQo+ICAgDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIEEgcmVzdG9yaW5nIHNp ZGUgbXVzdCBmYWlsIG9uIGFuIGFsZ29yaXRobSB2YWx1ZSBpdA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICBkb2VzIG5vdCBpbXBsZW1lbnQsIHJhdGhlciB0aGFuIGF0dGVtcHRpbmcg dG8NCj4gQEAgLTM3MSw2ICszODYsOSBAQCBndWVzdCdzIFAyTSB0YWJsZSBkdXJpbmcgYSBs aXZlIG1pZ3JhdGlvblteMl0uDQo+ICAgDQo+ICAgUmVzdG9yaW5nIGFuIGltYWdlIHdpdGgg dW5yZWNvZ25pc2VkIHBhZ2UgdHlwZXMgc2hhbGwgZmFpbC4NCj4gICANCj4gK1teMV06IExa NCBGcmFtZSBGb3JtYXQgRGVzY3JpcHRpb24sIHZlcnNpb24gMS42LjQ6DQo+ICs8aHR0cHM6 Ly9naXRodWIuY29tL2x6NC9sejQvYmxvYi92MS4xMC4wL2RvYy9sejRfRnJhbWVfZm9ybWF0 Lm1kPg0KPiArDQo+ICAgW14yXTogSW4gdGhlIGxlZ2FjeSBmb3JtYXQsIHRoaXMgaXMgdGhl IGxpc3Qgb2YgdW5tYXBwZWQgUEZOcyBpbiB0aGUNCj4gICB0YWlsLg0KPiAgIA0KPiBkaWZm IC0tZ2l0IGEvdG9vbHMvbGlicy9ndWVzdC9NYWtlZmlsZSBiL3Rvb2xzL2xpYnMvZ3Vlc3Qv TWFrZWZpbGUNCj4gaW5kZXggOTMzMzhhOTMwMS4uMDM3ZjFmNGRlOSAxMDA2NDQNCj4gLS0t IGEvdG9vbHMvbGlicy9ndWVzdC9NYWtlZmlsZQ0KPiArKysgYi90b29scy9saWJzL2d1ZXN0 L01ha2VmaWxlDQo+IEBAIC0zLDcgKzMsNyBAQCBpbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xz L1J1bGVzLm1rDQo+ICAgDQo+ICAgaW5jbHVkZSBNYWtlZmlsZS5jb21tb24NCj4gICANCj4g LXhnX2RvbV9iemltYWdlbG9hZGVyLm8geGdfZG9tX2J6aW1hZ2Vsb2FkZXIub3BpYzogQ0ZM QUdTICs9ICQoWkxJQl9DRkxBR1MpDQo+ICtDRkxBR1MgKz0gJChaTElCX0NGTEFHUykNCj4g ICANCj4gICAkKExJQkVMRl9PQkpTOi5vPS5vcGljKTogQ0ZMQUdTICs9IC1Xbm8tcG9pbnRl ci1zaWduDQo+ICAgDQo+IGRpZmYgLS1naXQgYS90b29scy9saWJzL2d1ZXN0L3hnX3NyX2Nv bW1vbi5oIGIvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9jb21tb24uaA0KPiBpbmRleCBjMDdj NmRiNTllLi41MzY0N2NhYTMwIDEwMDY0NA0KPiAtLS0gYS90b29scy9saWJzL2d1ZXN0L3hn X3NyX2NvbW1vbi5oDQo+ICsrKyBiL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3JfY29tbW9uLmgN Cj4gQEAgLTMsNiArMywxOCBAQA0KPiAgIA0KPiAgICNpbmNsdWRlIDxzdGRib29sLmg+DQo+ ICAgDQo+ICsjaWYgZGVmaW5lZChIQVZFX0xaNCkNCj4gKyNpbmNsdWRlIDxsejQuaD4NCj4g Ky8qDQo+ICsgKiAxLjguMSBmaXhlZCBhIG1lbWNweSgpIGZyb20gTlVMTCBpbiBMWjRGX2Rl Y29tcHJlc3MoKS4NCj4gKyAqIDEuOS4wJ3MgZGVjb2RlciByZWFkcyBwYXN0IGl0cyBpbnB1 dCAoZml4ZWQgaW4gMS45LjEpLg0KPiArICovDQo+ICsjaWYgTFo0X1ZFUlNJT05fTlVNQkVS ID49IDEwODAxICYmIExaNF9WRVJTSU9OX05VTUJFUiAhPSAxMDkwMA0KPiArI2luY2x1ZGUg PGx6NGZyYW1lLmg+DQo+ICsjZGVmaW5lIFhHX1NSX0xaNA0KPiArI2VuZGlmDQo+ICsjZW5k aWYNCj4gKw0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIHByZWZlcmFibGUgdG8gd2FybiB0aGUg dXNlciB0aGF0IHdlIHJlamVjdGVkIHRoZSBsejQgDQpzdXBwb3J0IGhlcmUgcmF0aGVyIHRo YW4gc2lsZW50bHkgZGlzYWJsaW5nIGl0LiBQZXJoYXBzIHdpdGggc29tZXRoaW5nIGxpa2UN Cg0KI3ByYWdtYSBHQ0Mgd2FybmluZyAiRGlzYWJsZWQgTFo0IHJlc3RvcmUgc3VwcG9ydCBk dWUgdG8gbGlicmFyeSBidWdzIg0KDQpBc3N1bWluZyBpdCdzIHNvbWV0aGluZyB3ZSBzdXBw b3J0Lg0KDQo+ICAgI2luY2x1ZGUgInhnX3ByaXZhdGUuaCINCj4gICAjaW5jbHVkZSAieGdf c2F2ZV9yZXN0b3JlLmgiDQo+ICAgI2luY2x1ZGUgInhnX3NyX3N0cmVhbV9mb3JtYXQuaCIN Cj4gQEAgLTI3Nyw2ICsyODksMTAgQEAgc3RydWN0IHhjX3NyX2NvbnRleHQNCj4gICAgICAg ICAgICAgICAvKiBXaGV0aGVyIGEgU1RBVElDX0RBVEFfRU5EIHJlY29yZCBoYXMgYmVlbiBz ZWVuL2luZmVycmVkLiAqLw0KPiAgICAgICAgICAgICAgIGJvb2wgc2Vlbl9zdGF0aWNfZGF0 YV9lbmQ7DQo+ICAgDQo+ICsgICAgICAgICAgICAvKiBMWjQgZGVjb2RlciBidWZmZXIgYW5k IGNvbnRleHQsIGFsbG9jYXRlZCBvbiBmaXJzdCB1c2UuICovDQo+ICsgICAgICAgICAgICB2 b2lkICpsejRfZGVjb21wX2J1ZjsNCj4gKyAgICAgICAgICAgIHZvaWQgKmx6NF9kY3R4Ow0K PiArDQoNCkkgdGhpbmsgdGhlc2UgbmV3IGZpZWxkcyBhcmUgc3VwcG9zZWQgKGF0IGxlYXN0 LCBsejRfZGN0eCkgdG8gYmUgZ2F0ZWQgDQpiZWhpbmQgWEdfU1JfTFo0LCBvdGhlcndpc2Us IHRoZXkgYXJlIGVmZmVjdGl2ZWx5IHVudXNlZCBpZiBsejQgbGl2ZSANCm1pZ3JhdGlvbiBz dXBwb3J0IGlzIGNvbXBpbGVkIG91dC4NCih0aGF0IHdheSwgd2Ugd291bGQgYmUgYWJsZSB0 byBtYWtlIGx6NF9kY3R4IExaNEZfZGN0eCBpbnN0ZWFkIG9mIHZvaWQpDQoNCmx6NF9kZWNv bXBfYnVmIGlzIGEgTUFYX0JBVENIX1NJWkUgKiBQQUdFX1NJWkUgYnl0ZXMgYnVmZmVyLCBi dXQgaGFzIG5vIA0KbHo0IHNwZWNpZmljIG1lYW5pbmcuIEkgd291bGQganVzdCBjYWxsIGl0 ICJkZWNvbXBfYnVmIiBkaXJlY3RseSwgc28gDQp0aGF0IGl0IGNhbiBiZSByZXVzZWQgZm9y IG90aGVyIGNvbXByZXNzaW9uIGFsZ29yaXRobXMgd2hlbiBuZWVkZWQuDQoNCj4gICAvKg0K PiAgICAqIFdpdGggUmVtdXMvQ09MTywgd2UgYnVmZmVyIHRoZSByZWNvcmRzIHNlbnQgYnkg dGhlIHByaW1hcnkgYXQgY2hlY2twb2ludCwNCj4gICAgKiBpbiBjYXNlIHRoZSBwcmltYXJ5 IHdpbGwgZmFpbCwgd2UgY2FuIHJlY292ZXIgZnJvbSB0aGUgbGFzdA0KPiBkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9yZXN0b3JlLmMgYi90b29scy9saWJzL2d1ZXN0 L3hnX3NyX3Jlc3RvcmUuYw0KPiBpbmRleCA5M2IwMjBiNTVmLi4yOWEzYjEzMjUzIDEwMDY0 NA0KPiAtLS0gYS90b29scy9saWJzL2d1ZXN0L3hnX3NyX3Jlc3RvcmUuYw0KPiArKysgYi90 b29scy9saWJzL2d1ZXN0L3hnX3NyX3Jlc3RvcmUuYw0KPiBAQCAtMzU0LDYgKzM1NCwxMjAg QEAgc3RhdGljIGludCBwcm9jZXNzX3BhZ2VfZGF0YShzdHJ1Y3QgeGNfc3JfY29udGV4dCAq Y3R4LCB1bnNpZ25lZCBpbnQgY291bnQsDQo+ICAgICAgIHJldHVybiByYzsNCj4gICB9DQo+ ICAgDQo+ICsjaWYgZGVmaW5lZChYR19TUl9MWjQpDQo+ICsvKg0KPiArICogRGVjb2RlIHRo ZSBMWjQgZnJhbWUgYXQgc3JjIGludG8gY3R4LT5yZXN0b3JlLmx6NF9kZWNvbXBfYnVmLiAg VGhlDQo+ICsgKiBkZWNvZGVkIHNpemUgY29tZXMgZnJvbSB0aGUgcGZuIGFycmF5Lg0KPiAr ICovDQo+ICtzdGF0aWMgdm9pZCAqZGVjb21wcmVzc19wYWdlX2RhdGEoc3RydWN0IHhjX3Ny X2NvbnRleHQgKmN0eCwgY29uc3Qgdm9pZCAqc3JjLA0KPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHNpemVfdCBzcmNfbGVuLCB1bnNpZ25lZCBpbnQgbnJfcGFnZXMp DQoNCkdpdmVuIHRoaXMgaXMgdGhlIGx6NCBpbXBsZW1lbnRhdGlvbiwgSSB3b3VsZCByYXRo ZXIgbmFtZSBpdCANCmRlY29tcHJlc3NfbHo0X3BhZ2VfZGF0YSgpLg0KDQo+ICt7DQo+ICsg ICAgeGNfaW50ZXJmYWNlICp4Y2ggPSBjdHgtPnhjaDsNCj4gKyAgICBMWjRGX2ZyYW1lSW5m b190IGluZm87DQo+ICsgICAgc2l6ZV90IGV4cGVjdGVkID0gKHNpemVfdClucl9wYWdlcyAq IFBBR0VfU0laRTsNCj4gKyAgICBzaXplX3Qgb3V0X2xlbiA9IGV4cGVjdGVkLCBoZHJfbGVu ID0gc3JjX2xlbiwgcmVzdF9sZW4sIGluX2xlbiwgcmV0Ow0KPiArDQo+ICsgICAgLyogVGhl IGJ1ZmZlciBpcyBhIGZpeGVkIE1BWF9CQVRDSF9TSVpFIHBhZ2VzLiAqLw0KPiArICAgIGlm ICggbnJfcGFnZXMgPiBNQVhfQkFUQ0hfU0laRSApDQo+ICsgICAgew0KPiArICAgICAgICBF UlJPUigiQ29tcHJlc3NlZCBQQUdFX0RBVEEgcmVjb3JkIHdpdGggJXUgcGFnZXMgZXhjZWVk cyBNQVhfQkFUQ0hfU0laRSAldSIsDQo+ICsgICAgICAgICAgICAgIG5yX3BhZ2VzLCBNQVhf QkFUQ0hfU0laRSk7DQo+ICsgICAgICAgIHJldHVybiBOVUxMOw0KPiArICAgIH0NCj4gKw0K PiArICAgIC8qIFRoZSBmb3JtYXQgcmVxdWlyZXMgdGhlIGZyYW1lIHRvIGJlIHN0cmljdGx5 IHNob3J0ZXIgdGhhbiB0aGUgcGFnZXMuICovDQo+ICsgICAgaWYgKCBzcmNfbGVuID49IGV4 cGVjdGVkICkNCj4gKyAgICB7DQo+ICsgICAgICAgIEVSUk9SKCJMWjQgZnJhbWUgaW4gUEFH RV9EQVRBIHJlY29yZCAoJXp1IGJ5dGVzKSBpcyBub3Qgc2hvcnRlciB0aGFuIGl0cyBwYWdl IGRhdGEgKCV6dSBieXRlcykiLA0KPiArICAgICAgICAgICAgICBzcmNfbGVuLCBleHBlY3Rl ZCk7DQo+ICsgICAgICAgIHJldHVybiBOVUxMOw0KPiArICAgIH0NCj4gKw0KPiArICAgIGlm ICggIWN0eC0+cmVzdG9yZS5sejRfZGN0eCApDQo+ICsgICAgew0KPiArICAgICAgICBMWjRG X2RjdHggKmRjdHggPSBOVUxMOw0KPiArDQo+ICsgICAgICAgIHJldCA9IExaNEZfY3JlYXRl RGVjb21wcmVzc2lvbkNvbnRleHQoJmRjdHgsIExaNEZfVkVSU0lPTik7DQo+ICsgICAgICAg IGlmICggTFo0Rl9pc0Vycm9yKHJldCkgKQ0KPiArICAgICAgICB7DQo+ICsgICAgICAgICAg ICBFUlJPUigiVW5hYmxlIHRvIGNyZWF0ZSBMWjQgZGVjb21wcmVzc2lvbiBjb250ZXh0Iik7 DQo+ICsgICAgICAgICAgICByZXR1cm4gTlVMTDsNCj4gKyAgICAgICAgfQ0KPiArICAgICAg ICBjdHgtPnJlc3RvcmUubHo0X2RjdHggPSBkY3R4Ow0KPiArICAgIH0NCj4gKw0KPiArICAg IC8qIFN0YXJ0IGVhY2ggZnJhbWUgYXQgaXRzIGhlYWRlciAocmVzdG9yZSBzdG9wcyBhdCBh bnkgZXJyb3IpLiAqLw0KPiArICAgIExaNEZfcmVzZXREZWNvbXByZXNzaW9uQ29udGV4dChj dHgtPnJlc3RvcmUubHo0X2RjdHgpOw0KDQpUbyBtZSwgaXQncyBub3QgdXNlZnVsIHRvIHJl c2V0IHRoZSBjb250ZXh0IHJpZ2h0IGFmdGVyIGNyZWF0aW5nIGl0Lg0KDQpTbywgd2UgY2Fu IGV2ZW50dWFsbHkgZm9sZCB0aGlzIGxpbmUgaW50byBhIGVsc2UgY2FzZSBpLmUgd2hlbiB0 aGUgDQpjb250ZXh0IGFscmVhZHkgZXhpc3QuDQoNCj4gKw0KPiArICAgIHJldCA9IExaNEZf Z2V0RnJhbWVJbmZvKGN0eC0+cmVzdG9yZS5sejRfZGN0eCwgJmluZm8sIHNyYywgJmhkcl9s ZW4pOw0KPiArICAgIGlmICggTFo0Rl9pc0Vycm9yKHJldCkgKQ0KPiArICAgIHsNCj4gKyAg ICAgICAgRVJST1IoIkxaNCBmcmFtZSBpbiBQQUdFX0RBVEEgcmVjb3JkIGhhcyBhIGJhZCBo ZWFkZXI6ICVzIiwNCj4gKyAgICAgICAgICAgICAgTFo0Rl9nZXRFcnJvck5hbWUocmV0KSk7 DQo+ICsgICAgICAgIHJldHVybiBOVUxMOw0KPiArICAgIH0NCj4gKw0KPiArICAgIC8qIGxp Ymx6NCBhY2NlcHRzIGZyYW1lcyB3aXRob3V0IHRoZSBibG9jayBjaGVja3N1bXMgcmVxdWly ZWQgaGVyZS4gKi8NCj4gKyAgICBpZiAoIGluZm8uYmxvY2tDaGVja3N1bUZsYWcgIT0gTFo0 Rl9ibG9ja0NoZWNrc3VtRW5hYmxlZCApDQo+ICsgICAgew0KPiArICAgICAgICBFUlJPUigi TFo0IGZyYW1lIGluIFBBR0VfREFUQSByZWNvcmQgaGFzIG5vIGJsb2NrIGNoZWNrc3VtcyIp Ow0KPiArICAgICAgICByZXR1cm4gTlVMTDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBpZiAo ICFjdHgtPnJlc3RvcmUubHo0X2RlY29tcF9idWYgKQ0KPiArICAgIHsNCj4gKyAgICAgICAg Y3R4LT5yZXN0b3JlLmx6NF9kZWNvbXBfYnVmID0gbWFsbG9jKE1BWF9CQVRDSF9TSVpFICog UEFHRV9TSVpFKTsNCj4gKyAgICAgICAgaWYgKCAhY3R4LT5yZXN0b3JlLmx6NF9kZWNvbXBf YnVmICkNCj4gKyAgICAgICAgew0KPiArICAgICAgICAgICAgRVJST1IoIlVuYWJsZSB0byBh bGxvY2F0ZSAlbHUgYnl0ZXMgZm9yIGRlY29tcHJlc3Npb24iLA0KPiArICAgICAgICAgICAg ICAgICAgKHVuc2lnbmVkIGxvbmcpTUFYX0JBVENIX1NJWkUgKiBQQUdFX1NJWkUpOw0KPiAr ICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQo+ICsgICAgICAgIH0NCj4gKyAgICB9DQo+ICsN Cj4gKyAgICAvKiBMWjRGX2dldEZyYW1lSW5mbygpIHJlYWQgdGhlIGhlYWRlcjsgZGVjb2Rl IHRoZSByZXN0IG9mIHRoZSBmcmFtZS4gKi8NCj4gKyAgICByZXN0X2xlbiA9IHNyY19sZW4g LSBoZHJfbGVuOw0KPiArICAgIGluX2xlbiA9IHJlc3RfbGVuOw0KPiArDQo+ICsgICAgLyog TlVMTCBvcHRpb25zOiBjaGVja3N1bXMgYXJlIHZlcmlmaWVkOyBsaWJsejQga2VlcHMgaXRz IG93biBidWZmZXJzLiAqLw0KPiArICAgIHJldCA9IExaNEZfZGVjb21wcmVzcyhjdHgtPnJl c3RvcmUubHo0X2RjdHgsIGN0eC0+cmVzdG9yZS5sejRfZGVjb21wX2J1ZiwNCj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgJm91dF9sZW4sIChjb25zdCB1aW50OF90ICopc3JjICsg aGRyX2xlbiwgJmluX2xlbiwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCk7 DQo+ICsNCj4gKyAgICBpZiAoIExaNEZfaXNFcnJvcihyZXQpICkNCj4gKyAgICB7DQo+ICsg ICAgICAgIEVSUk9SKCJGYWlsZWQgdG8gZGVjb21wcmVzcyBQQUdFX0RBVEEgcmVjb3JkOiAl cyIsDQo+ICsgICAgICAgICAgICAgIExaNEZfZ2V0RXJyb3JOYW1lKHJldCkpOw0KPiArICAg ICAgICByZXR1cm4gTlVMTDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICAvKiBOb3QgYW4gZXJy b3IsIGJ1dCB0aGUgZnJhbWUgZGlkIG5vdCBlbmQ6IGlucHV0IG9yIG91dHB1dCByYW4gb3V0 LiAqLw0KDQpuaXQ6ICJOb3QgYSBkZWNvbXByZXNzaW9uIGVycm9yIi4NCg0KPiArICAgIGlm ICggcmV0ICE9IDAgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgRVJST1IoIkxaNCBmcmFtZSBp biBQQUdFX0RBVEEgcmVjb3JkIGlzIHRydW5jYXRlZCBvciBkZWNvZGVzIHRvIG92ZXIgJXp1 IGJ5dGVzIiwNCj4gKyAgICAgICAgICAgICAgZXhwZWN0ZWQpOw0KPiArICAgICAgICByZXR1 cm4gTlVMTDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICAvKiBpbl9sZW4gYW5kIG91dF9sZW4g bm93IGhvbGQgdGhlIGJ5dGVzIGNvbnN1bWVkIGFuZCBwcm9kdWNlZC4gKi8NCj4gKyAgICBp ZiAoIG91dF9sZW4gIT0gZXhwZWN0ZWQgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgRVJST1Io IkxaNCBmcmFtZSBpbiBQQUdFX0RBVEEgcmVjb3JkIHByb2R1Y2VkICV6dSBieXRlcywgZXhw ZWN0ZWQgJXp1IiwNCj4gKyAgICAgICAgICAgICAgb3V0X2xlbiwgZXhwZWN0ZWQpOw0KPiAr ICAgICAgICByZXR1cm4gTlVMTDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBpZiAoIGluX2xl biAhPSByZXN0X2xlbiApDQo+ICsgICAgew0KPiArICAgICAgICBFUlJPUigiTFo0IGZyYW1l IGluIFBBR0VfREFUQSByZWNvcmQgZm9sbG93ZWQgYnkgJXp1IHVuY29uc3VtZWQgYnl0ZXMi LA0KPiArICAgICAgICAgICAgICByZXN0X2xlbiAtIGluX2xlbik7DQo+ICsgICAgICAgIHJl dHVybiBOVUxMOw0KPiArICAgIH0NCj4gKw0KPiArICAgIHJldHVybiBjdHgtPnJlc3RvcmUu bHo0X2RlY29tcF9idWY7DQo+ICt9DQo+ICsjZW5kaWYgLyogWEdfU1JfTFo0ICovDQo+ICsN Cj4gICAvKg0KPiAgICAqIFZhbGlkYXRlIGEgUEFHRV9EQVRBIHJlY29yZCBmcm9tIHRoZSBz dHJlYW0sIGFuZCBwYXNzIHRoZSByZXN1bHRzIHRvDQo+ICAgICogcHJvY2Vzc19wYWdlX2Rh dGEoKSB0byBhY3R1YWxseSBwZXJmb3JtIHRoZSBsZWd3b3JrLg0KPiBAQCAtMzYzLDYgKzQ3 Nyw3IEBAIHN0YXRpYyBpbnQgaGFuZGxlX3BhZ2VfZGF0YShzdHJ1Y3QgeGNfc3JfY29udGV4 dCAqY3R4LCBzdHJ1Y3QgeGNfc3JfcmVjb3JkICpyZWMpDQo+ICAgICAgIHhjX2ludGVyZmFj ZSAqeGNoID0gY3R4LT54Y2g7DQo+ICAgICAgIHN0cnVjdCB4Y19zcl9yZWNfcGFnZV9kYXRh X2hlYWRlciAqcGFnZXMgPSByZWMtPmRhdGE7DQo+ICAgICAgIHVuc2lnbmVkIGludCBpLCBw YWdlc19vZl9kYXRhID0gMDsNCj4gKyAgICB2b2lkICpwYWdlX2RhdGE7DQo+ICAgICAgIGlu dCByYyA9IC0xOw0KPiAgIA0KPiAgICAgICB4ZW5fcGZuX3QgKnBmbnMgPSBOVUxMLCBwZm47 DQo+IEBAIC00NjMsNiArNTc4LDggQEAgc3RhdGljIGludCBoYW5kbGVfcGFnZV9kYXRhKHN0 cnVjdCB4Y19zcl9jb250ZXh0ICpjdHgsIHN0cnVjdCB4Y19zcl9yZWNvcmQgKnJlYykNCj4g ICAgICAgICAgIHR5cGVzW2ldID0gdHlwZTsNCj4gICAgICAgfQ0KPiAgIA0KPiArICAgIHBh Z2VfZGF0YSA9ICZwYWdlcy0+cGZuW3BhZ2VzLT5jb3VudF07DQo+ICsNCj4gICAgICAgc3dp dGNoICggcGFnZXMtPmZsYWdzICYgUEFHRV9EQVRBX0FMR09fTUFTSyApDQo+ICAgICAgIHsN Cj4gICAgICAgY2FzZSBQQUdFX0RBVEFfQUxHT19OT05FOg0KPiBAQCAtNDc4LDE0ICs1OTUs MjkgQEAgc3RhdGljIGludCBoYW5kbGVfcGFnZV9kYXRhKHN0cnVjdCB4Y19zcl9jb250ZXh0 ICpjdHgsIHN0cnVjdCB4Y19zcl9yZWNvcmQgKnJlYykNCj4gICAgICAgICAgIH0NCj4gICAg ICAgICAgIGJyZWFrOw0KPiAgIA0KPiArICAgIGNhc2UgUEFHRV9EQVRBX0FMR09fTFo0Og0K PiArI2lmIGRlZmluZWQoWEdfU1JfTFo0KQ0KPiArICAgIHsNCj4gKyAgICAgICAgc2l6ZV90 IGhkcnN6ID0gc2l6ZW9mKCpwYWdlcykgKyAoc2l6ZW9mKHVpbnQ2NF90KSAqIHBhZ2VzLT5j b3VudCk7DQo+ICsNCj4gKyAgICAgICAgcGFnZV9kYXRhID0gZGVjb21wcmVzc19wYWdlX2Rh dGEoY3R4LCBwYWdlX2RhdGEsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHJlYy0+bGVuZ3RoIC0gaGRyc3osIHBhZ2VzX29mX2RhdGEpOw0KPiArICAg ICAgICBpZiAoICFwYWdlX2RhdGEgKQ0KPiArICAgICAgICAgICAgZ290byBlcnI7DQo+ICsg ICAgICAgIGJyZWFrOw0KPiArICAgIH0NCj4gKyNlbHNlDQo+ICsgICAgICAgIEVSUk9SKCJM WjQgY29tcHJlc3NlZCBQQUdFX0RBVEEgcmVjb3JkIGJ1dCBMWjQgc3VwcG9ydCBub3QgY29t cGlsZWQgaW4iKTsNCj4gKyAgICAgICAgZ290byBlcnI7DQo+ICsjZW5kaWYNCj4gKw0KPiAg ICAgICBkZWZhdWx0Og0KPiAgICAgICAgICAgRVJST1IoIlVuc3VwcG9ydGVkIGFsZ29yaXRo bSAldSBpbiBQQUdFX0RBVEEgcmVjb3JkIiwNCj4gICAgICAgICAgICAgICAgICh1bnNpZ25l ZCBpbnQpKHBhZ2VzLT5mbGFncyAmIFBBR0VfREFUQV9BTEdPX01BU0spKTsNCj4gICAgICAg ICAgIGdvdG8gZXJyOw0KPiAgICAgICB9DQo+ICAgDQo+IC0gICAgcmMgPSBwcm9jZXNzX3Bh Z2VfZGF0YShjdHgsIHBhZ2VzLT5jb3VudCwgcGZucywgdHlwZXMsDQo+IC0gICAgICAgICAg ICAgICAgICAgICAgICAgICAmcGFnZXMtPnBmbltwYWdlcy0+Y291bnRdKTsNCj4gKyAgICBy YyA9IHByb2Nlc3NfcGFnZV9kYXRhKGN0eCwgcGFnZXMtPmNvdW50LCBwZm5zLCB0eXBlcywg cGFnZV9kYXRhKTsNCj4gICAgZXJyOg0KPiAgICAgICBmcmVlKHR5cGVzKTsNCj4gICAgICAg ZnJlZShwZm5zKTsNCj4gQEAgLTgyMiw2ICs5NTQsMTEgQEAgc3RhdGljIHZvaWQgY2xlYW51 cChzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4KQ0KPiAgIA0KPiAgICAgICBmcmVlKGN0eC0+ cmVzdG9yZS5idWZmZXJlZF9yZWNvcmRzKTsNCj4gICAgICAgZnJlZShjdHgtPnJlc3RvcmUu cG9wdWxhdGVkX3BmbnMpOw0KPiArICAgIGZyZWUoY3R4LT5yZXN0b3JlLmx6NF9kZWNvbXBf YnVmKTsNCj4gKyNpZiBkZWZpbmVkKFhHX1NSX0xaNCkNCj4gKyAgICBpZiAoIGN0eC0+cmVz dG9yZS5sejRfZGN0eCApDQo+ICsgICAgICAgIExaNEZfZnJlZURlY29tcHJlc3Npb25Db250 ZXh0KGN0eC0+cmVzdG9yZS5sejRfZGN0eCk7DQo+ICsjZW5kaWYNCj4gICANCj4gICAgICAg aWYgKCBjdHgtPnJlc3RvcmUub3BzLmNsZWFudXAoY3R4KSApDQo+ICAgICAgICAgICBQRVJS T1IoIkZhaWxlZCB0byBjbGVhbiB1cCIpOw0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9n dWVzdC94Z19zcl9zdHJlYW1fZm9ybWF0LmggYi90b29scy9saWJzL2d1ZXN0L3hnX3NyX3N0 cmVhbV9mb3JtYXQuaA0KPiBpbmRleCBmODM5ZDg3NGM4Li5hZjY5NWFlNzcxIDEwMDY0NA0K PiAtLS0gYS90b29scy9saWJzL2d1ZXN0L3hnX3NyX3N0cmVhbV9mb3JtYXQuaA0KPiArKysg Yi90b29scy9saWJzL2d1ZXN0L3hnX3NyX3N0cmVhbV9mb3JtYXQuaA0KPiBAQCAtOTIsNiAr OTIsNyBAQCBzdHJ1Y3QgeGNfc3JfcmVjX3BhZ2VfZGF0YV9oZWFkZXINCj4gICAjZGVmaW5l IFBBR0VfREFUQV9GTEFHU19SRVNaX01BU0sgMHhmZmZmZmYwMFUNCj4gICANCj4gICAjZGVm aW5lIFBBR0VfREFUQV9BTEdPX05PTkUgICAgICAgMHgwMDAwMDAwMFUNCj4gKyNkZWZpbmUg UEFHRV9EQVRBX0FMR09fTFo0ICAgICAgICAweDAwMDAwMDAxVQ0KPiAgIA0KPiAgICNkZWZp bmUgUEFHRV9EQVRBX1BGTl9NQVNLICAgICAgMHgwMDBmZmZmZmZmZmZmZmZmVUxMDQo+ICAg I2RlZmluZSBQQUdFX0RBVEFfUEZOX1JFU1pfTUFTSyAweDBmZjAwMDAwMDAwMDAwMDBVTEwN Cj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL2xpYnhjLnB5IGIv dG9vbHMvcHl0aG9uL3hlbi9taWdyYXRpb24vbGlieGMucHkNCj4gaW5kZXggMjkwNmI3OGQz Ni4uMTBlMTYzZTI3MiAxMDA2NDQNCj4gLS0tIGEvdG9vbHMvcHl0aG9uL3hlbi9taWdyYXRp b24vbGlieGMucHkNCj4gKysrIGIvdG9vbHMvcHl0aG9uL3hlbi9taWdyYXRpb24vbGlieGMu cHkNCj4gQEAgLTkwLDYgKzkwLDExIEBAIFBBR0VfREFUQV9QRk5fUkVTWl9NQVNLICAgICAg PSAoKDEgPDwgNjApIC0gMSkgJiB+KCgxIDw8IDUyKSAtIDEpDQo+ICAgUEFHRV9EQVRBX0FM R09fTUFTSyAgICAgICAgICA9IDB4MDAwMDAwZmYNCj4gICBQQUdFX0RBVEFfRkxBR1NfUkVT Wl9NQVNLICAgID0gMHhmZmZmZmYwMA0KPiAgIFBBR0VfREFUQV9BTEdPX05PTkUgICAgICAg ICAgPSAweDAwDQo+ICtQQUdFX0RBVEFfQUxHT19MWjQgICAgICAgICAgID0gMHgwMQ0KPiAr DQo+ICsjIExaNCBmcmFtZTogYXQgbGVhc3QgbWFnaWMsIEZMRywgQkQgYW5kIEhDOyBGTEcg Yml0IDQgaXMgQi5DaGVja3N1bQ0KPiArUEFHRV9EQVRBX0xaNF9GUkFNRV9NSU4gICAgICA9 IDcNCj4gK1BBR0VfREFUQV9MWjRfRkxHX0JMT0NLU1VNICAgPSAweDEwDQo+ICAgDQo+ICAg IyBmbGFncyBmcm9tIHhlbi9wdWJsaWMvZG9tY3RsLmg6IFhFTl9ET01DVExfUEZJTkZPXyog c2hpZnRlZCBieSAzMiBiaXRzDQo+ICAgUEFHRV9EQVRBX1RZUEVfU0hJRlQgICAgICAgICA9 IDYwDQo+IEBAIC0zMDUsNiArMzEwLDI0IEBAIGNsYXNzIFZlcmlmeUxpYnhjKFZlcmlmeUJh c2UpOg0KPiAgICAgICAgICAgICAgICAgICByYWlzZSBSZWNvcmRFcnJvcigiRXhwZWN0ZWQg JXUgKyAldSArICV1LCBnb3QgJXUiICUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKG1pbnN6LCBwZm5zeiwgcGFnZXN6LCBsZW4oY29udGVudCkpKQ0KPiAgIA0K PiArICAgICAgICBlbGlmIGFsZ28gPT0gUEFHRV9EQVRBX0FMR09fTFo0Og0KPiArDQo+ICsg ICAgICAgICAgICAjIFdpdGhvdXQgZGVjb21wcmVzc2luZywgY2hlY2sgdGhlIHNhdmVyJ3Mg bGVuZ3RoIHJ1bGUuDQo+ICsgICAgICAgICAgICBpZiBkYXRhc3ogPj0gcGFnZXN6Og0KPiAr ICAgICAgICAgICAgICAgIHJhaXNlIFJlY29yZEVycm9yKA0KPiArICAgICAgICAgICAgICAg ICAgICAiTFo0IGZyYW1lIGluIFBBR0VfREFUQSByZWNvcmQgKCV1IGJ5dGVzKSBpcyBub3Qg c2hvcnRlciB0aGFuIGl0cyBwYWdlIGRhdGEgKCV1IGJ5dGVzKSINCj4gKyAgICAgICAgICAg ICAgICAgICAgJSAoZGF0YXN6LCBwYWdlc3opKQ0KPiArDQo+ICsgICAgICAgICAgICBmcmFt ZSA9IGNvbnRlbnRbbWluc3ogKyBwZm5zejpdDQo+ICsgICAgICAgICAgICBpZiBsZW4oZnJh bWUpIDwgUEFHRV9EQVRBX0xaNF9GUkFNRV9NSU46DQo+ICsgICAgICAgICAgICAgICAgcmFp c2UgUmVjb3JkRXJyb3IoDQo+ICsgICAgICAgICAgICAgICAgICAgICJMWjQgZnJhbWUgaW4g UEFHRV9EQVRBIHJlY29yZCB0b28gc2hvcnQ6ICV1IGJ5dGVzIg0KPiArICAgICAgICAgICAg ICAgICAgICAlIChsZW4oZnJhbWUpLCApKQ0KPiArDQo+ICsgICAgICAgICAgICBpZiBub3Qg b3JkKGZyYW1lWzQ6NV0pICYgUEFHRV9EQVRBX0xaNF9GTEdfQkxPQ0tTVU06DQo+ICsgICAg ICAgICAgICAgICAgcmFpc2UgUmVjb3JkRXJyb3IoDQo+ICsgICAgICAgICAgICAgICAgICAg ICJMWjQgZnJhbWUgaW4gUEFHRV9EQVRBIHJlY29yZCBoYXMgbm8gYmxvY2sgY2hlY2tzdW1z IikNCj4gKw0KPiAgICAgICAgICAgZWxzZToNCj4gICAgICAgICAgICAgICByYWlzZSBTdHJl YW1FcnJvcigNCj4gICAgICAgICAgICAgICAgICAgIlVuc3VwcG9ydGVkIGFsZ29yaXRobSAl dSBpbiBQQUdFX0RBVEEgcmVjb3JkIiAlIChhbGdvLCApKQ0KPiBkaWZmIC0tZ2l0IGEvdG9v bHMvcHl0aG9uL3hlbi9taWdyYXRpb24vdGVzdHMucHkgYi90b29scy9weXRob24veGVuL21p Z3JhdGlvbi90ZXN0cy5weQ0KPiBpbmRleCAxOTQ0YWUwOWIzLi45ZTZkOTI1ZTUxIDEwMDY0 NA0KPiAtLS0gYS90b29scy9weXRob24veGVuL21pZ3JhdGlvbi90ZXN0cy5weQ0KPiArKysg Yi90b29scy9weXRob24veGVuL21pZ3JhdGlvbi90ZXN0cy5weQ0KPiBAQCAtMzYsMTkgKzM2 LDQ0IEBAIGNsYXNzIFRlc3RMaWJ4Yyh1bml0dGVzdC5UZXN0Q2FzZSk6DQo+ICAgICAgICAg ICB2ID0gbGlieGMuVmVyaWZ5TGlieGMobGFtYmRhICpfOiBOb25lLCBsYW1iZGEgKl86IGIi IikNCj4gICAgICAgICAgIFBBR0UgPSBiIlx4MDAiICogNDA5Ng0KPiAgICAgICAgICAgTk9U QUIgPSBsaWJ4Yy5QQUdFX0RBVEFfVFlQRV9OT1RBQiB8IDB4MSAgICMgb25lIG5vcm1hbCBw YWdlLCBwZm4gMQ0KPiArICAgICAgICBYVEFCID0gbGlieGMuUEFHRV9EQVRBX1RZUEVfWFRB QiB8IDB4MSAgICAgIyBubyBwYWdlIG9mIGRhdGEsIHBmbiAxDQo+ICAgDQo+IC0gICAgICAg IGRlZiByZWMoZmxhZ3MsIGRhdGEpOg0KPiArICAgICAgICBkZWYgcmVjKGZsYWdzLCBkYXRh LCBwZm49Tk9UQUIpOg0KPiAgICAgICAgICAgICAgIHJldHVybiBwYWNrKGxpYnhjLlBBR0Vf REFUQV9GT1JNQVQsIDEsIGZsYWdzKSArIFwNCj4gLSAgICAgICAgICAgICAgICAgICBwYWNr KCI9USIsIE5PVEFCKSArIGRhdGENCj4gKyAgICAgICAgICAgICAgICAgICBwYWNrKCI9USIs IHBmbikgKyBkYXRhDQo+ICAgDQo+ICAgICAgICAgICAjIFVuY29tcHJlc3NlZDogZXhhY3Rs eSBvbmUgcGFnZSBvZiBkYXRhLCBhbmQgbm90aGluZyBlbHNlIGFjY2VwdGVkLg0KPiAgICAg ICAgICAgdi52ZXJpZnlfcmVjb3JkX3BhZ2VfZGF0YShyZWMobGlieGMuUEFHRV9EQVRBX0FM R09fTk9ORSwgUEFHRSkpDQo+ICAgICAgICAgICBzZWxmLmFzc2VydFJhaXNlcyhsaWJ4Yy5S ZWNvcmRFcnJvciwgdi52ZXJpZnlfcmVjb3JkX3BhZ2VfZGF0YSwNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHJlYyhsaWJ4Yy5QQUdFX0RBVEFfQUxHT19OT05FLCBQQUdFWzot MV0pKQ0KPiAgIA0KPiArICAgICAgICAjIEFuIExaNCBmcmFtZSBoZWFkZXI6IG1hZ2ljLCB0 aGVuIEZMRyB3aXRoIHRoZSBibG9jay1jaGVja3N1bSBiaXQuDQo+ICsgICAgICAgIEZSQU1F ID0gYiJceDA0XHgyMlx4NGRceDE4XHg3MFx4NzBceDcyIiArIGIiXHgwMCIgKiA5Mw0KPiAr DQo+ICsgICAgICAgICMgTFo0OiB0aGUgcGF5bG9hZCBpcyBjaGVja2VkIGFnYWluc3QgdGhl IHNhdmVyJ3MgbGVuZ3RoIHJ1bGUsDQo+ICsgICAgICAgICMgMCA8IGxlbiA8IHRoZSB1bmNv bXByZXNzZWQgc2l6ZSBpdCByZXBsYWNlczogb25lIHBhZ2UgaGVyZSwgYW5kDQo+ICsgICAg ICAgICMgbm9uZSB3aXRoIGFuIFhUQUIgcGZuLiAgRlVMTCBpcyBhIHZhbGlkIGZyYW1lIGhl YWRlciBwYWRkZWQgdG8gb25lDQo+ICsgICAgICAgICMgcGFnZSwgc28gb25seSB0aGUgbGVu Z3RoIHJ1bGUgY2FuIHJlamVjdCBpdC4NCj4gKyAgICAgICAgRlVMTCA9IEZSQU1FICsgYiJc eDAwIiAqICg0MDk2IC0gbGVuKEZSQU1FKSkNCj4gKyAgICAgICAgdi52ZXJpZnlfcmVjb3Jk X3BhZ2VfZGF0YShyZWMobGlieGMuUEFHRV9EQVRBX0FMR09fTFo0LCBGVUxMWzotMV0pKQ0K PiArICAgICAgICB2LnZlcmlmeV9yZWNvcmRfcGFnZV9kYXRhKHJlYyhsaWJ4Yy5QQUdFX0RB VEFfQUxHT19MWjQsIEZSQU1FKSkNCj4gKyAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMobGli eGMuUmVjb3JkRXJyb3IsIHYudmVyaWZ5X3JlY29yZF9wYWdlX2RhdGEsDQo+ICsgICAgICAg ICAgICAgICAgICAgICAgICAgIHJlYyhsaWJ4Yy5QQUdFX0RBVEFfQUxHT19MWjQsIGIiIikp DQo+ICsgICAgICAgIHNlbGYuYXNzZXJ0UmFpc2VzKGxpYnhjLlJlY29yZEVycm9yLCB2LnZl cmlmeV9yZWNvcmRfcGFnZV9kYXRhLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICBy ZWMobGlieGMuUEFHRV9EQVRBX0FMR09fTFo0LCBGVUxMKSkNCj4gKyAgICAgICAgc2VsZi5h c3NlcnRSYWlzZXMobGlieGMuUmVjb3JkRXJyb3IsIHYudmVyaWZ5X3JlY29yZF9wYWdlX2Rh dGEsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYyhsaWJ4Yy5QQUdFX0RBVEFf QUxHT19MWjQsIEZSQU1FLCBYVEFCKSkNCj4gKw0KPiArICAgICAgICAjIC4uLiBhbmQgYWdh aW5zdCB0aGUgZnJhbWUgaGF2aW5nIGEgd2hvbGUgaGVhZGVyIHdpdGggYmxvY2sgY2hlY2tz dW1zLg0KPiArICAgICAgICBzZWxmLmFzc2VydFJhaXNlcyhsaWJ4Yy5SZWNvcmRFcnJvciwg di52ZXJpZnlfcmVjb3JkX3BhZ2VfZGF0YSwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAg ICAgcmVjKGxpYnhjLlBBR0VfREFUQV9BTEdPX0xaNCwNCj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEZSQU1FWzo0XSArIGIiXHg2MCIgKyBGUkFNRVs1Ol0pKQ0KPiArICAg ICAgICBzZWxmLmFzc2VydFJhaXNlcyhsaWJ4Yy5SZWNvcmRFcnJvciwgdi52ZXJpZnlfcmVj b3JkX3BhZ2VfZGF0YSwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjKGxpYnhj LlBBR0VfREFUQV9BTEdPX0xaNCwgRlJBTUVbOjZdKSkNCj4gKw0KPiAgICAgICAgICAgIyBB biB1bmltcGxlbWVudGVkIGFsZ29yaXRobSwgYW5kIGFueSByZXNlcnZlZCBiaXQsIGFyZSBy ZWZ1c2VkLg0KPiAgICAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMobGlieGMuU3RyZWFtRXJy b3IsIHYudmVyaWZ5X3JlY29yZF9wYWdlX2RhdGEsDQo+IC0gICAgICAgICAgICAgICAgICAg ICAgICAgIHJlYyhsaWJ4Yy5QQUdFX0RBVEFfQUxHT19OT05FICsgMSwgUEFHRSkpDQo+ICsg ICAgICAgICAgICAgICAgICAgICAgICAgIHJlYyhsaWJ4Yy5QQUdFX0RBVEFfQUxHT19MWjQg KyAxLCBGUkFNRSkpDQo+ICAgICAgICAgICBmb3IgYml0IGluIHJhbmdlKDgsIDMyKToNCj4g ICAgICAgICAgICAgICBzZWxmLmFzc2VydFJhaXNlcyhsaWJ4Yy5TdHJlYW1FcnJvciwgdi52 ZXJpZnlfcmVjb3JkX3BhZ2VfZGF0YSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZWMoMSA8PCBiaXQsIFBBR0UpKQ0KDQo= --------------c3WlZovtFMsnSaUphS93vHZl-- --------------L6fIDp1DQsjChtFL0M06GveO 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+p0QLLz9AFAmrh1K8FAwAAAAAACgkQZg+p0QLLz9D8 SgwAjwEko3VzbRLyJAiXKejNz1+UPu+ag82dlywxVLOkw8acFYwJbP9gxQV6MwPcvGbbyzQarNF+ dhRMKQBnfAUwk94c3xHnK4Qy/3HlT7cbQXu/PK8hFlmidwHCg6wuAZt30UQ+OPJO7YYFmdQ2BfFT gQymTgC/5QheR0BEzV/p7J+u2T9g4iwkURBQEQUjwKS0BFgEPb82H1/OgZwf3udkWknMpIazdEdp 1hpI7xYq6XpSDv4QzcpLSzuchBPR0iE3heFr48e5atu2+nemoppFlrWfe9Uf87CQtuWCt2ltoqsI t38Dbby8D79cLYiclmFJET1KXaOy1gnQQrbuC2M9MGjqFSJT1T5331EGp1FmQ/CCD2CzUDbXkVRy xjBrnhCyWyfbRMBseOulP9WmeqfajmLBd/bFvu4YAcN/YyQkfaJ64rEqWFYNl/Xld7TI6IzqVEd6 +nkf4heKkAI1Zyu5QBwd23GgGu/flcTk4ekW46NuFYkEi4yybPCp/OGuz79e =mqlT -----END PGP SIGNATURE----- --------------L6fIDp1DQsjChtFL0M06GveO-- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:06:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:06:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463090.1674057 (Exim 4.92) (envelope-from ) id 1xM1UX-0007Bl-VG; Wed, 28 Oct 2026 11:06:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463090.1674057; Wed, 28 Oct 2026 11:06: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 1xM1UX-0007Be-SE; Wed, 28 Oct 2026 11:06:49 +0000 Received: by outflank-mailman (input) for mailman id 1463090; Wed, 28 Oct 2026 11:06:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM1UW-0007BY-WD for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:06:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM1UW-009lDq-29 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:06:48 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1d747-e002-0a2a0a5209dd-0a2a4509b05e-0 for ; Wed, 28 Oct 2026 12:06:47 +0100 Received: from [209.85.218.51] (helo=mail-ej1-f51.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1d747-be1a-0a2a45090019-d155da33e09b-3 for ; Wed, 28 Oct 2026 12:06:47 +0100 Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-c46822eefb6so98641766b.2 for ; Wed, 28 Oct 2026 04:06: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-48e3ebc39a8sm28989042f8f.11.2026.10.28.04.06.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 04:06: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=1793185607; x=1793790407; 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=oeV+agtu0OoQTdFIxx3hW2Px70NutSPsDtlt7O2PwKM=; b=fjrroI+rlpNcjONCefx/yWzbj+XW7hceI2HgIJBlJMoCPRNB+ljWVt4WfJGP3d3g/T 4vt47fKT0K52zI7LI5/1Rgez0kzyzWkQh0igT2SToKr/wOKZSw59MWVJ4DeZg4W6nrED IzHHVinANnMndM1qsNC17CYzGH56F3whqYHw70tYEXGtRZlwPcdBtZ/BLOFJ8ZwEFNsV Vt10oacHhiuBMjT+0Th4MyxR8CMGvhhO2grr56G/B6ByaluMFPVdLxKxwGnMHd9Vovfr hGydqj56Tf4d4/pokor3hbysHEaAZKvEcL+cYDKoAozNSe/686Y82Iwphp6jnZuUXZrN BQwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793185607; x=1793790407; 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=oeV+agtu0OoQTdFIxx3hW2Px70NutSPsDtlt7O2PwKM=; b=SNmaDrnGvjDHLkc2IEv7HsMn3aPn7btM081hGGgFTuvd5oFuHS4CRHjTrzGpc2TGfk itD0xMtNzhAiGloqscAw8KFAYbQtydBBZbSKg53oFDqqHwmH45iV5YOsl7iR0EXcxd1z UGTJKqePm1OLj8WbIDwaR5fFE/vSCysUBMuqCW2luPFhgUDzG+X6u15JToBu5KSVOxNy zgYxEdsCa2FbNtW6zXv3b2c/+6k+rr7FHgnhzdK/UxXcYtf5ttW0Mv1LsgeqEwMaSHHU w7B67nqVn1OOkG1iTSuLDVQldTCwtYWj8doU5d+r4TqIYxA32u0QE2pd6vZVOuvE5UQT tsEg== X-Forwarded-Encrypted: i=1; AKwUvBxVGRNa52WgSvR4wz/vnddDREyGeB28lcE280e9302evZc10jgQVslHWFQcDNqcpsi+o4XkGYoLRZE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ4bkgGbzJkwMM/G1KDhYX1dBs0z3V9U2eV+0t5qgcl/OyeI6Ix YK9bdGRekTjMv5cFfd17gVwqrIAUeyyzmDb+NgCfqV6mNy2E0l38eyMyD9vOicV+CA== X-Gm-Gg: AYBFou2106KC2UHJh9NHR4dfdOMWjxk4B4Hlnts1Vadn/cjhSN6akMnVRzTB34mmk9e K2jj0CWs2uD1lDRx+7Q3S1xfiT5BUR1PTnrp22eoV82Wbkf8pkfGnkz2WZoieXRqvwpBpQGxX6+ TAAxad7INYgFLFogmrSZxoo9YyqY19WEg8dYhimOdbA3qfOalCh+hDOn3iANU2cxL2wPJS+mDWa oOWnw4slmNHWD7zXuwQGNbAqV3NfLfH+AKyEVW0VTMTz/+wLc7zjvH9KUhtTcZBLuWUxTETlvPA VLLW4tNRQsD3M0VKF8TjZ0GnThx7GNl18Wt3BtE3UfUljt2t9Q7Evcx3LJvPByiC6cRS0d5y+Lq XkfPW5sQaWg4/lB+Dg2PYV+EPW+8VhMJJA2gVTqiipILQEf0+jPVKRwDq+CX/to5n6R3zreeAew 5PKy/Na11/p2A2e8E2GohFFUj0XJcb416F8Tf4+dPR7GKyb9PyL0tB/hnyfduJjnOS3usCiHM2d yNipk0uDzygh7rdzMdoFEybttCljCtFNQQmhnp5vqypghSl+ywSqWAy7VBOFCvFXq1IUejbjqNU zz5NMIrsaKDs7kTlKDk3WEwJwIrw+6rDGW1+zM1tBFWSH4W1B4HPGsr7CofPBm/JPL2h3Y6f/bz QWbbRlGVRLxgQIf4Z X-Received: by 2002:a17:906:c143:b0:c40:91fb:b76 with SMTP id a640c23a62f3a-c49bdf898e4mr144992966b.33.1793185607316; Wed, 28 Oct 2026 04:06:47 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 12:06:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/nestedsvm: remove dead code for shadow-paging L1 hosts To: chunjie.zhu@citrix.com Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20261027073711.30963-1-chunjie.zhu@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: <20261027073711.30963-1-chunjie.zhu@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1793185607-FCC15034-0248F30A/10/78276251493 X-purgate-type: spam X-purgate-size: 2112 On 27.10.2026 08:37, chunjie.zhu@citrix.com wrote: > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -237,27 +237,10 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) > hvm_update_guest_cr(v, 2); > > /* CR3 */ > - /* Nested paging mode */ > - if ( nestedhvm_paging_mode_hap(v) ) > - { > - /* host nested paging + guest nested paging. */ > - /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ > - } > - 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. */ > - } > - else > - { > - /* host shadow paging + guest shadow paging. */ > + /* Nested virt requires HAP, so the host is never in shadow mode. */ > + BUG_ON(paging_mode_shadow(v->domain)); See below as to the use of "host" in the comment. > @@ -517,10 +500,13 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > v->arch.hvm.guest_cr[2] = ns_vmcb->_cr2; > hvm_update_guest_cr(v, 2); > > + /* Nested virt requires HAP, so the host is never in shadow mode. */ > + BUG_ON(paging_mode_shadow(v->domain)); > + > /* Nested paging mode */ > if ( nestedhvm_paging_mode_hap(v) ) > { > - /* host nested paging + guest nested paging. */ > + /* Guest uses nested paging. */ > vmcb_set_np(n2vmcb, true); "Guest" alone ends up ambiguous. The "host" / "guest" terminology used before wasn't quite clear either, but at least there was some distinction. Easiest may be to drop "Guest uses" here (and below). Else, to be unambiguous, it may need to be something like "L1 runs L2 under nested paging". If you agree with dropping "Guest uses" and replacing "host" by "L1", I can make these adjustments while committing, implying Acked-by: Jan Beulich in that shape. Otherwise please submit a v3 with adjustments you consider suitable. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:14:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:14:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463099.1674066 (Exim 4.92) (envelope-from ) id 1xM1bx-0000e3-L7; Wed, 28 Oct 2026 11:14:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463099.1674066; Wed, 28 Oct 2026 11: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 1xM1bx-0000dw-IP; Wed, 28 Oct 2026 11:14:29 +0000 Received: by outflank-mailman (input) for mailman id 1463099; Wed, 28 Oct 2026 11:14:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM1bw-0000dm-IE for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:14:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM1bv-00DSkH-K8 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:14:27 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1d90f-bab6-0a2a0a5309dd-0a2a45049a10-24 for ; Wed, 28 Oct 2026 12:14:27 +0100 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1d913-b57f-0a2a45040019-d1558036dcd6-3 for ; Wed, 28 Oct 2026 12:14:27 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a60f9474c4so10182905e9.0 for ; Wed, 28 Oct 2026 04:14: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-4a97c42ca77sm36695365e9.8.2026.10.28.04.14.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 04:14: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=1793186067; x=1793790867; 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=tfR/aykflLpWF1mmF8c66vclT6jnA1r42KisfCY3QFw=; b=DiwFEGhlmz1qmi1+VVUm7WAyDgcpeaU2vi22L53sznRTu8x10Wtmsg8eRe5lpbvzb6 0Q1gILprBFtCyXOhzQ+jomJeEMxcLecnEf1JEkcTTo/uOZTey2gfS0zgKYDk/g+3Z6Y/ WCmy6RGXhP+95uGHtxPQ4VbPFxRM8hiBiWxyb+qLkIUtCAhIcu347irXZ9ttig6WHblQ eCGBePTb+saQETVGh7RhbQH8xZkLnYwVQYf4tHK3AI97jG/L5+htTa02NSWuzygLQnSO 1eVSzp5oGcYAOLz4M5/aXAPgmfepp56eL5JFKlRILQOn5IB1+YRSf2jZoTe5zmIaTMu4 ynVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793186067; x=1793790867; 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=tfR/aykflLpWF1mmF8c66vclT6jnA1r42KisfCY3QFw=; b=X3T6FJNT+giP2FqTWJlLZf+Tg0OlPFdHtf0+7F0/R1pgCsgM72q5vWjDKxS1RtlULO jSqDe9+HWnMelMmM0mTsLYiSrlEYb8PdApgr2deBNMuemThMpjTrrIpd7RlItoacU5sj r13Z6xs53QZAw3l2aso48IJaXScqlKx/dIzfqz8z4DBPo2KpEN69sd8c8Cp7gccOe0ne TyaqDXxrOH/8T7XUPe/qFVeH4vF0i469NO2FonEKNLM6cSv5KHe2WCn6fThnV3n32fB1 M5yMtLHKtZH4ObXJh50MCUCXxrcWs23J8DmZ94EL9sOjpgd2DSDvpULSxwvoriz2vfUm K2DQ== X-Forwarded-Encrypted: i=1; AKwUvBw28w0gCI2hyLPrwfX1TsNZWDITv3TlnamxmtzrgXHXJiLRJDG6ayurL5bKoVgbCv5WM44kw5Jcycg=@lists.xenproject.org X-Gm-Message-State: AFq9FYLYZOtxl9vmxAjClnHymeHPZOfG51O+KG8uiyPvtpNoDMfJVJG5 JTiusXUy04hyfDNEnUKJITWLNZv3Hsw6LyYieMqIIvF72yqcgICsw71y91Ni/N5//Q== X-Gm-Gg: AYBFou0Ly11I2LVfqov4576U10CZMDHxEa1ZTuN7OnprThJ11y2/KHieckBc5WiVheF J4g0tEd9GLSOMRN2Ae5cGRJw00Ln8zP0Cqi3sQ9TTxU6eXW6ln2XJId6HxQPkpmC7RTzE56DOw/ 9Pwowlfgbss/BxOhNXHcb3VRN9FxmhZl6yUavbaB9gO1+077Ed2cG7bOtGQlB2FwGIlmWCBBgTn u9Hsjhck1PadDc5xNCBV/B3Yv3eywB56r/dVbL61WKHE17Lh1XoRhuYeXAzkNscWikoH578qH1h M5TbgwKf0VWkGKxDoqTWnRhxBOgzbuFc8qAYMfHWqhNDJdUeAy97mNXvAyn5c5c+KIz4t+zpM7O DfYIUu7xHxuF5hC+dETpA3SwJGyzwgBv5nEvVvE/SBwCs3EIUkdQZ0/3/utYJ0S0VKrYkQ8bm4d C55JgXVU9eGd+lz8x+CM7oTkF0Wl9CxgHhcZhmWtJHheH2n+BxcegKBuugbcxLRyJJGinT8OIRk /+fjxn0CDce4mlxBK5IKQCij7PhNaOZT0veO4vKbuRA0HuI+KIfkozb23UgEDeF4/x2EyaXA31K dRjo1cBxvtpELj0s8BU16Wn9/AsdeVoj95PCxfcLoIJmMvy1CLT0giF2WG0usZVg9LvK0cUE5U8 KkStdLOjYXddLlq8VUg== X-Received: by 2002:a05:600c:1387:b0:4a1:777b:8a12 with SMTP id 5b1f17b1804b1-4a966586ff2mr41884585e9.14.1793186066783; Wed, 28 Oct 2026 04:14:26 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 12:14:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1793023450.8631fc262581453bbf619ec5b2062170.1a178869cb4000f79f@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: <1793023450.8631fc262581453bbf619ec5b2062170.1a178869cb4000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1793186067-50AD8B50-4EB3B187/10/78276251493 X-purgate-type: spam X-purgate-size: 2673 On 26.10.2026 15:03, Teddy Astie wrote: > The Intel SDM (Vol 3A-13.12.11, June 2026) says > >> The semantics of sending a self-IPI via the SELF IPI register >> are identical to sending a self targeted edge triggered fixed >> interrupt with the specified vector. > > However, this doesn't require altering the ICR register. > On most Intel processors (at least Core/P-Core), it does alter ICR, > but it's not the case on AMD and Atom/E-Core ones, and APICv Self-IPI > appears to follow a similar behavior. > > For consistency, adjust the Xen behavior to send the Self-IPI > directly instead of emulating it by modifying ICR register. > > It also clarify the logic. > > Assisted-by: Claude Fable 5.1 > Signed-off-by: Teddy Astie Reviewed-by: Jan Beulich However, ... > --- a/xen/arch/x86/hvm/vlapic.c > +++ b/xen/arch/x86/hvm/vlapic.c > @@ -970,11 +970,13 @@ int vlapic_apicv_write(struct vcpu *v, unsigned int offset) > > if ( vlapic_x2apic_mode(vlapic) ) > { > - if ( offset != APIC_SELF_IPI ) > - return X86EMUL_UNHANDLEABLE; ... why the extra churn here? The overall hunk here ... > + if ( offset == APIC_SELF_IPI ) > + { > + vlapic_ipi(vlapic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK), 0); > + return X86EMUL_OKAY; > + } > > - offset = APIC_ICR; > - val = APIC_DEST_SELF | (val & APIC_VECTOR_MASK); > + return X86EMUL_UNHANDLEABLE; > } > > vlapic_reg_write(v, offset, val); ... could be @@ -973,8 +973,8 @@ int vlapic_apicv_write(struct vcpu *v, unsigned int offset) if ( offset != APIC_SELF_IPI ) return X86EMUL_UNHANDLEABLE; - offset = APIC_ICR; - val = APIC_DEST_SELF | (val & APIC_VECTOR_MASK); + vlapic_ipi(vlapic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK), 0); + return X86EMUL_OKAY; } vlapic_reg_write(v, offset, val); Much closer to ... > @@ -1050,9 +1052,8 @@ int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr, uint64_t val) > case APIC_SELF_IPI: > if ( val & ~APIC_VECTOR_MASK ) > return X86EMUL_EXCEPTION; > - offset = APIC_ICR; > - val = APIC_DEST_SELF | (val & APIC_VECTOR_MASK); > - break; > + vlapic_ipi(vlapic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK), 0); > + return X86EMUL_OKAY; > > case APIC_EOI: > case APIC_ESR: ... this hunk then. (I may take the liberty of making that adjustment while committing, unless you provide a reason for the bigger change.) Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:20:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:20:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463107.1674075 (Exim 4.92) (envelope-from ) id 1xM1i4-0002Bf-9I; Wed, 28 Oct 2026 11:20:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463107.1674075; Wed, 28 Oct 2026 11:20: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 1xM1i4-0002BY-6Y; Wed, 28 Oct 2026 11:20:48 +0000 Received: by outflank-mailman (input) for mailman id 1463107; Wed, 28 Oct 2026 11:20:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM1i2-0002BQ-Ad for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:20:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM1i1-002iLw-Dn for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:20:45 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1da83-bab6-0a2a0a5309dd-0a2a45059b86-32 for ; Wed, 28 Oct 2026 12:20:45 +0100 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 6ae1da8d-4cb1-0a2a45050019-b9ff1c239a9d-3 for ; Wed, 28 Oct 2026 12:20:45 +0100 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 1a1823daf66000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 11:20:43 +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 23A9282C5C; Wed, 28 Oct 2026 12:20:42 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=fAYXJhjuMCxcTYy3dMUZ/7fHJ30rtd8+lh04Mt5CzLI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=LRSLK5UmYGKtoc7km5ygAIBU6pIbUcjVX4J3wvL75JtWlEsk+2sfVb8gsNW/BtCVMxhCFIQVF lRYG9QySPqAq9TIwFVz5RlZzikbx//GWnNnp/sJ102OEnLEvp8KLfDFXCxZiOz/2dWoK40keYJ+ 1YuMyHhQUxqk9Qcb37DQDFGvZ+NIY+lQrvEI5P4bG3WOV3dSpCWJK6eruj2Wb4Z50Lj/fZkfipx TeMrQxW5YuJQvHIWCbBvSw0+r6ORBSVYMW/1X4IpwLkVHp+/A0Oog4V/oCPfeCx3Uwh9FRi4TN0 BKEwZtGHB5647V6Cg/wMM2fL9T13hwvg59Pzl6nFHgJQ== X-Zone-Loop: 22c26283616368e9ffd6e31f611a8a3e38d7e087697e x-campaign-type: default x-transaction-id: 086eebbf-c833-44f1-88ab-0e4fc5ba7418 x-swg-uid: 01-6552aedc-df1e-484c-917d-cc4e3def0591 X-Mailer: Sweego Message-ID: <1793186443.8631fc262581453bbf619ec5b2062170.1a1823daf66000f79f@vates.tech> x-swg-bid: 1793186443.8631fc262581453bbf619ec5b2062170.1a1823daf66000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 12:20:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/9] tools/libs/guest: compress PAGE_DATA records with LZ4 on save To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-5-marcus.granado@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: <20261020200238.1815766-5-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Mg8pnVzX6fZR9CNWp0lOxo8g" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793186442311 X-purgate-ID: tlsNG-c201ff/1793186445-F54AC2A1-572FBC1A/0/0 X-purgate-type: clean X-purgate-size: 18936 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Mg8pnVzX6fZR9CNWp0lOxo8g Content-Type: multipart/mixed; boundary="------------0XcP9laRqg6EhmwbIUkKb00l"; protected-headers="v1"; hp="clear" Message-ID: <4e762bae-a195-492a-a90b-81daa9bf8c2f@vates.tech> Date: Wed, 28 Oct 2026 12:20:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/9] tools/libs/guest: compress PAGE_DATA records with LZ4 on save To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-5-marcus.granado@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: <20261020200238.1815766-5-marcus.granado@citrix.com> --------------0XcP9laRqg6EhmwbIUkKb00l Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowNSwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g d3JpdGVfYmF0Y2goKSBzZW5kcyB0aGUgcGFnZXMgb2YgZWFjaCBiYXRjaCB1bmNvbXByZXNz ZWQsIHdyaXRpbmcNCj4gaW92ZWNzIHdoaWNoIHBvaW50IGludG8gdGhlIGZvcmVpZ24gbWFw cGluZyBzdHJhaWdodCB0byB0aGUgc3RyZWFtLg0KPiBSZXN0b3JlIGRlY29kZXMgUEFHRV9E QVRBIGFsZ29yaXRobSAweDAxLCBMWjQsIGJ1dCBub3RoaW5nIGVtaXRzIGl0LCBzbw0KPiBt ZW1vcnkgd2hpY2ggY29tcHJlc3NlcyB3ZWxsIHN0aWxsIGNyb3NzZXMgdGhlIGxpbmsgYXQg ZnVsbCBzaXplLg0KPiANCj4gV2hlbiBjdHgtPnNhdmUuY29tcHJlc3Npb24gc2VsZWN0cyBM WjQsIGNvcHkgdGhlIGJhdGNoJ3MgcGFnZSBkYXRhIGludG8NCj4gYSBzdGFnaW5nIGJ1ZmZl ciwgY29tcHJlc3MgaXQgaW50byBvbmUgTFo0IGZyYW1lIHdpdGggYmxvY2sgY2hlY2tzdW1z LA0KPiBhbmQgc2VuZCB0aGUgZnJhbWUsIHplcm8tcGFkZGVkIHRvIFJFQ19BTElHTiwgaW4g cGxhY2Ugb2YgdGhlIHBhZ2VzLg0KPiBTZW5kIHRoZSBiYXRjaCB1bmNvbXByZXNzZWQgdW5s ZXNzIHRoZSBmcmFtZSBpcyBzdHJpY3RseSBzaG9ydGVyIHRoYW4NCj4gdGhlIHBhZ2UgZGF0 YSwgYXMgdGhlIHN0cmVhbSBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIG9mIGEgc2F2ZXIuDQo+ IA0KPiBUaGUgY29weSBpcyByZXF1aXJlZDogTFo0IG1heSBlbmNvZGUgYSBwYWdlIFAgYnkg cmVmZXJlbmNlIHRvIGFuDQo+IGVhcmxpZXIgcGFnZSBRLCBjaGVja2VkIGFnYWluc3QgUSdz IGN1cnJlbnQgYnl0ZXMgYnV0IHJlYnVpbHQgZnJvbSBRIGFzDQo+IGVuY29kZWQgZWFybGll ciBpbiB0aGUgZnJhbWUuICBBIGd1ZXN0IHdyaXRlIHRvIFEgaW4gYmV0d2VlbiBjb3JydXB0 cyBQDQo+IHVuZGV0ZWN0ZWQsIGFzIHRoZSBibG9jayBjaGVja3N1bXMgY292ZXIgdGhlIGNv bXByZXNzZWQgZGF0YSwgYW5kIFAgaXMNCj4gbm90IHJlLXNlbnQgdW5sZXNzIHRoZSBndWVz dCB3cml0ZXMgaXQgYWdhaW4uDQo+IA0KPiBTdGFnZSBmcm9tIHRoZSBpb3YgcmF0aGVyIHRo YW4gdGhlIG1hcHBpbmcsIGFzIG9ubHkgdGhlIGlvdiBkZXNjcmliZXMNCj4gdGhlIHJlY29y ZDogUFYgcGFnZXRhYmxlcyBhcmUgbm9ybWFsaXNlZCBpbnRvIHNlcGFyYXRlbHkgYWxsb2Nh dGVkDQo+IHBhZ2VzLCBhbmQgYSBwYWdlIGRlZmVycmVkIG9uIEVBR0FJTiBzdGF5cyBpbiB0 aGUgbWFwcGluZyBidXQgaGFzIG5vDQo+IGRhdGEgaW4gdGhlIHJlY29yZC4NCj4gDQo+IFRo ZSBiYXRjaCBpcyBzdGFnZWQgd2hvbGUgYW5kIGNvbXByZXNzZWQgYXMgb25lIGJsb2NrIG9m IHVwIHRvIDRNQjsNCj4gY29weWluZyBpbiBzbWFsbGVyIGNodW5rcyBpbnRlcmxlYXZlZCB3 aXRoIGNvbXByZXNzaW9uIHdhcyBzbG93ZXIgaW4NCj4gbW9zdCBjb25maWd1cmF0aW9ucyBt ZWFzdXJlZC4NCj4gDQo+IFRoZSB0d28gYnVmZmVycywgYWJvdXQgOE1CIHRvZ2V0aGVyLCBh cmUgYWxsb2NhdGVkIG9uIGZpcnN0IHVzZS4gIElmDQo+IGFsbG9jYXRpb24gb3IgY29tcHJl c3Npb24gZmFpbHMsIGNvbXByZXNzaW9uIGlzIHN3aXRjaGVkIG9mZiBmb3IgdGhlDQo+IHJl c3Qgb2YgdGhlIHNhdmUgcmF0aGVyIHRoYW4gZmFpbGluZyBpdC4gIFRoZSBlbmNvZGVyIGlz IGd1YXJkZWQgYnkNCj4gWEdfU1JfTFo0LCBhcyB0aGUgZGVjb2RlciBpcy4NCj4gDQo+IE5v dGhpbmcgc2V0cyBjdHgtPnNhdmUuY29tcHJlc3Npb24geWV0LCBzbyBiZWhhdmlvdXIgaXMg dW5jaGFuZ2VkLg0KPiANCj4gU3VnZ2VzdGVkLWJ5OiBGcmVkaWFubyBaaWdsaW8gPGZyZWRk eTc3QGdtYWlsLmNvbT4NCj4gU3VnZ2VzdGVkLWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0 aWVAdmF0ZXMudGVjaD4NCj4gQXNzaXN0ZWQtYnk6IENsYXVkZTpjbGF1ZGUtb3B1cy01LTUN Cj4gU2lnbmVkLW9mZi1ieTogTWFyY3VzIEdyYW5hZG8gPG1hcmN1cy5ncmFuYWRvQGNpdHJp eC5jb20+DQo+IC0tLQ0KPiANCj4gTm90ZXM6DQo+ICAgICAgQ2hhbmdlcyBpbiB2MjoNCj4g ICAgICAtIFdhcyB2MSAzLzYuDQo+ICAgICAgLSBPbmUgTFo0IGZyYW1lIHBlciBiYXRjaCwg Y2FycmllZCBpbiBQQUdFX0RBVEEgYW5kIGNvbXByZXNzZWQgZnJvbSBhDQo+ICAgICAgICBz dGFnZWQgY29weSBvZiB0aGUgcGFnZSBkYXRhLCByZXBsYWNlcyBwZXItcGFnZSBibG9ja3Mg Y29tcHJlc3NlZA0KPiAgICAgICAgZnJvbSB0aGUgbGl2ZSBtYXBwaW5nIGluIGEgc2VwYXJh dGUgcmVjb3JkIHR5cGUuDQo+ICAgICAgLSBTZW5kIGNvbXByZXNzZWQgd2hlbmV2ZXIgdGhl IGZyYW1lIGlzIHNob3J0ZXIgKHYxOiBiZWxvdyA5NyUpLg0KPiAgICAgIC0gSWYgYWxsb2Nh dGlvbiBmYWlscywgY29tcHJlc3Npb24gaXMgc3dpdGNoZWQgb2ZmIHJhdGhlciB0aGFuIGZh aWxpbmcNCj4gICAgICAgIHRoZSBzYXZlICh2MSBmYWlsZWQgaXQpLg0KPiANCj4gICB0b29s cy9saWJzL2d1ZXN0L3hnX3NyX2NvbW1vbi5oIHwgIDE0ICsrKysNCj4gICB0b29scy9saWJz L2d1ZXN0L3hnX3NyX3NhdmUuYyAgIHwgMTMzICsrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrDQo+ICAgMiBmaWxlcyBjaGFuZ2VkLCAxNDcgaW5zZXJ0aW9ucygrKQ0KPiANCj4g ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3JfY29tbW9uLmggYi90b29scy9s aWJzL2d1ZXN0L3hnX3NyX2NvbW1vbi5oDQo+IGluZGV4IDUzNjQ3Y2FhMzAuLmU1NjdhNDc1 ODIgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3JfY29tbW9uLmgNCj4g KysrIGIvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9jb21tb24uaA0KPiBAQCAtMjIxLDYgKzIy MSwxMiBAQCBzdGF0aWMgaW5saW5lIGludCB1cGRhdGVfYmxvYihzdHJ1Y3QgeGNfc3JfYmxv YiAqYmxvYiwNCj4gICAgICAgcmV0dXJuIDA7DQo+ICAgfQ0KPiAgIA0KPiArZW51bSB4Y19z cl9jb21wcmVzc2lvbg0KPiArew0KPiArICAgIFhDX1NSX0NPTVBSRVNTX05PTkUsDQo+ICsg ICAgWENfU1JfQ09NUFJFU1NfTFo0LA0KPiArfTsNCj4gKw0KPiAgIHN0cnVjdCB4Y19zcl9j b250ZXh0DQo+ICAgew0KPiAgICAgICB4Y19pbnRlcmZhY2UgKnhjaDsNCj4gQEAgLTI2NSw2 ICsyNzEsMTQgQEAgc3RydWN0IHhjX3NyX2NvbnRleHQNCj4gICAgICAgICAgICAgICAgICAg dWludDY0X3QgcmVjX3BmbnNbTUFYX0JBVENIX1NJWkVdOw0KPiAgICAgICAgICAgICAgICAg ICBpbnQgZXJyb3JzW01BWF9CQVRDSF9TSVpFXTsNCj4gICAgICAgICAgICAgICB9ICpidWZm ZXJzOw0KPiArDQo+ICsgICAgICAgICAgICAvKiBXaGljaCBhbGdvcml0aG0gdG8gY29tcHJl c3MgcGFnZSBkYXRhIHdpdGguICovDQo+ICsgICAgICAgICAgICBlbnVtIHhjX3NyX2NvbXBy ZXNzaW9uIGNvbXByZXNzaW9uOw0KPiArDQo+ICsgICAgICAgICAgICAvKiBMWjQgc3RhZ2lu ZyBhbmQgb3V0cHV0IGJ1ZmZlcnMsIGFsbG9jYXRlZCBvbiBmaXJzdCB1c2UuICovDQo+ICsg ICAgICAgICAgICB2b2lkICpsejRfc3RhZ2luZ19idWY7DQo+ICsgICAgICAgICAgICB2b2lk ICpsejRfY29tcHJlc3NfYnVmOw0KPiArICAgICAgICAgICAgc2l6ZV90IGx6NF9jb21wcmVz c19idWZfc2l6ZTsNCg0KU2ltaWxhciByZW1hcmsgYXMgZm9yIGRlY29tcHJlc3Npb24gc2lk ZSAoZ2F0ZSBsejQtc3BlY2lmaWMgdmFyaWFibGVzIA0KYmVoaW5kIFhHX1NSX0xaNC4NCg0K PiAgICAgICAgICAgfSBzYXZlOw0KPiAgIA0KPiAgICAgICAgICAgc3RydWN0IC8qIFJlc3Rv cmUgZGF0YS4gKi8NCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3Jfc2F2 ZS5jIGIvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zYXZlLmMNCj4gaW5kZXggNmE3N2UzM2E0 Ny4uMzM5NTRhNzAyMyAxMDA2NDQNCj4gLS0tIGEvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9z YXZlLmMNCj4gKysrIGIvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zYXZlLmMNCj4gQEAgLTcz LDYgKzczLDExOCBAQCBzdGF0aWMgaW50IHdyaXRlX2NoZWNrcG9pbnRfcmVjb3JkKHN0cnVj dCB4Y19zcl9jb250ZXh0ICpjdHgpDQo+ICAgICAgIHJldHVybiB3cml0ZV9yZWNvcmQoY3R4 LCAmY2hlY2twb2ludCk7DQo+ICAgfQ0KPiAgIA0KPiArc3RhdGljIHZvaWQgY2xlYW51cF9j b21wcmVzc2lvbihzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4KQ0KPiArew0KPiArICAgIGZy ZWUoY3R4LT5zYXZlLmx6NF9zdGFnaW5nX2J1Zik7DQo+ICsgICAgZnJlZShjdHgtPnNhdmUu bHo0X2NvbXByZXNzX2J1Zik7DQo+ICsgICAgY3R4LT5zYXZlLmx6NF9zdGFnaW5nX2J1ZiA9 IE5VTEw7DQo+ICsgICAgY3R4LT5zYXZlLmx6NF9jb21wcmVzc19idWYgPSBOVUxMOw0KPiAr ICAgIGN0eC0+c2F2ZS5sejRfY29tcHJlc3NfYnVmX3NpemUgPSAwOw0KPiArfQ0KPiArDQo+ ICsjaWYgZGVmaW5lZChYR19TUl9MWjQpDQo+ICsvKg0KPiArICogT25lIGJsb2NrIHBlciA0 TUIgYmF0Y2g6IHNtYWxsZXIgYmxvY2tzIGNhbiBiZSAyeCBzbG93ZXIgdG8gZGVjb2RlLg0K PiArICogbGlibHo0IGFsbG93cyA2NEtCLCAyNTZLQiwgMU1CIGFuZCA0TUIuDQo+ICsgKi8N Cj4gKyNkZWZpbmUgWENfU1JfQ09NUFJFU1NfQkxPQ0tfU0laRSBMWjRGX21heDRNQg0KDQpJ J20gbm90IGZ1bGx5IGNvbnZpbmNlZCB0aGlzIG1hY3JvIGhlbHBzIGEgbG90IGdpdmVuIHRo YXQgaXQncyBvbmx5IHVzZWQgDQpiZWxvdyBmb3Igc2V0dGluZyBibG9ja1NpemVJRC4gSSB3 b3VsZCBqdXN0IG1vdmUgdGhlIGNvbW1lbnQgYW5kIGZvbGQgDQpMWjRGX21heDRNQiB0byBp dHMgb25seSB1c2VyLg0KDQo+ICsNCj4gKy8qDQo+ICsgKiBDb21wcmVzcyB0aGUgcGFnZSBk YXRhIGluIGlvdlsyLi5pb3ZjbnQpIGludG8gYW4gTFo0IGZyYW1lLCBhbmQgcmVwbGFjZQ0K PiArICogdGhvc2UgZW50cmllcyB3aXRoIG9uZSBkZXNjcmliaW5nIGl0LCBwYWRkZWQgdG8g dGhlIHJlY29yZCBhbGlnbm1lbnQuDQo+ICsgKiBSZXR1cm5zIHRoZSBuZXcgaW92Y250LCB0 aGUgb3JpZ2luYWwgb25lIHdpdGggaW92IHVudG91Y2hlZCBpZiB0aGUgYmF0Y2gNCj4gKyAq IHNob3VsZCBiZSBzZW50IHVuY29tcHJlc3NlZCwgb3IgLTEgaWYgdGhlIGJhdGNoIGl0c2Vs ZiBpcyBtYWxmb3JtZWQuDQo+ICsgKi8NCj4gK3N0YXRpYyBpbnQgbHo0X2NvbXByZXNzX2Jh dGNoKHN0cnVjdCB4Y19zcl9jb250ZXh0ICpjdHgsIHN0cnVjdCBpb3ZlYyAqaW92LA0KPiAr ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IGlvdmNudCwgdW5zaWduZWQgaW50 IG5yX3BhZ2VzLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg KmZsYWdzLCB1aW50MzJfdCAqbGVuZ3RoKQ0KPiArew0KPiArICAgIHN0YXRpYyBjb25zdCBM WjRGX3ByZWZlcmVuY2VzX3QgcHJlZnMgPSB7DQo+ICsgICAgICAgIC5mcmFtZUluZm8gPSB7 DQo+ICsgICAgICAgICAgICAuYmxvY2tTaXplSUQgPSBYQ19TUl9DT01QUkVTU19CTE9DS19T SVpFLA0KPiArICAgICAgICAgICAgLmJsb2NrQ2hlY2tzdW1GbGFnID0gTFo0Rl9ibG9ja0No ZWNrc3VtRW5hYmxlZCwNCj4gKyAgICAgICAgfSwNCj4gKyAgICB9Ow0KPiArICAgIHhjX2lu dGVyZmFjZSAqeGNoID0gY3R4LT54Y2g7DQo+ICsgICAgc2l6ZV90IHJhdyA9IChzaXplX3Qp bnJfcGFnZXMgKiBQQUdFX1NJWkUsIGNsZW4sIHN0YWdlZDsNCj4gKyAgICB1aW50OF90ICpk c3Q7DQo+ICsgICAgaW50IGk7DQo+ICsNCj4gKyAgICBpZiAoIG5yX3BhZ2VzID09IDAgKQ0K PiArICAgICAgICByZXR1cm4gaW92Y250Ow0KPiArDQo+ICsgICAgaWYgKCAhY3R4LT5zYXZl Lmx6NF9zdGFnaW5nX2J1ZiApDQo+ICsgICAgew0KPiArICAgICAgICBzaXplX3QgYm91bmQg PSBMWjRGX2NvbXByZXNzRnJhbWVCb3VuZChNQVhfQkFUQ0hfU0laRSAqIFBBR0VfU0laRSwN Cj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnBy ZWZzKTsNCj4gKw0KPiArICAgICAgICBjdHgtPnNhdmUubHo0X3N0YWdpbmdfYnVmID0gbWFs bG9jKE1BWF9CQVRDSF9TSVpFICogUEFHRV9TSVpFKTsNCj4gKyAgICAgICAgY3R4LT5zYXZl Lmx6NF9jb21wcmVzc19idWYgPSBtYWxsb2MoYm91bmQpOw0KPiArICAgICAgICBjdHgtPnNh dmUubHo0X2NvbXByZXNzX2J1Zl9zaXplID0gYm91bmQ7DQo+ICsNCj4gKyAgICAgICAgaWYg KCAhY3R4LT5zYXZlLmx6NF9zdGFnaW5nX2J1ZiB8fCAhY3R4LT5zYXZlLmx6NF9jb21wcmVz c19idWYgKQ0KPiArICAgICAgICB7DQo+ICsgICAgICAgICAgICBJUFJJTlRGKCJVbmFibGUg dG8gYWxsb2NhdGUgTFo0IGJ1ZmZlcnMsIHNlbmRpbmcgdW5jb21wcmVzc2VkIik7DQo+ICsg ICAgICAgICAgICBjbGVhbnVwX2NvbXByZXNzaW9uKGN0eCk7DQo+ICsgICAgICAgICAgICBj dHgtPnNhdmUuY29tcHJlc3Npb24gPSBYQ19TUl9DT01QUkVTU19OT05FOw0KPiArICAgICAg ICAgICAgcmV0dXJuIGlvdmNudDsNCj4gKyAgICAgICAgfQ0KPiArICAgIH0NCj4gKw0KPiAr ICAgIC8qIFRoZSBpb3YgbXVzdCBtYXRjaCBucl9wYWdlcywgb3Igc3RhbGUgYnl0ZXMgd291 bGQgYmUgY29tcHJlc3NlZC4gKi8NCj4gKyAgICBmb3IgKCBpID0gMiwgc3RhZ2VkID0gMDsg aSA8IGlvdmNudDsgKytpICkNCj4gKyAgICAgICAgc3RhZ2VkICs9IGlvdltpXS5pb3ZfbGVu Ow0KPiArICAgIGlmICggc3RhZ2VkICE9IHJhdyApDQo+ICsgICAgew0KPiArICAgICAgICBF UlJPUigiU3RhZ2VkICV6dSBieXRlcyBmb3IgYSBiYXRjaCBvZiAldSBwYWdlcyIsIHN0YWdl ZCwgbnJfcGFnZXMpOw0KPiArICAgICAgICByZXR1cm4gLTE7DQo+ICsgICAgfQ0KPiArDQo+ ICsgICAgLyogTFo0IG11c3Qgbm90IHJlYWQgbGl2ZSBndWVzdCBtZW1vcnk6IHRoZSBmcmFt ZSBjb3VsZCBkZWNvZGUgd3JvbmcuICovDQo+ICsgICAgZm9yICggaSA9IDIsIGRzdCA9IGN0 eC0+c2F2ZS5sejRfc3RhZ2luZ19idWY7IGkgPCBpb3ZjbnQ7ICsraSApDQo+ICsgICAgew0K PiArICAgICAgICBtZW1jcHkoZHN0LCBpb3ZbaV0uaW92X2Jhc2UsIGlvdltpXS5pb3ZfbGVu KTsNCj4gKyAgICAgICAgZHN0ICs9IGlvdltpXS5pb3ZfbGVuOw0KPiArICAgIH0NCj4gKw0K DQpTaG91bGQgd29yayBpbiBwcmFjdGljZSBhcyBpcywgYnV0IEkgd291bGQgYWRkIHhlbl9i YXJyaWVyKCkgKGNvbXBpbGVyIA0KYmFycmllcikgcmlnaHQgYWZ0ZXIgdGhlIGZvciBsb29w IGFuZCBiZWZvcmUgdGhlIExaNEZfY29tcHJlc3NGcmFtZSgpIA0KZm9yIGNvcnJlY3RuZXNz LCBzbyB0aGF0IHRoZSBjb21waWxlciBpcyBub3QgYWxsb3dlZCB0byBlbGlkZSB0aGUgDQpz dGFnaW5nIGJ1ZmZlciBjb3B5IGluc2lkZSBMWjRGX2NvbXByZXNzRnJhbWUoKS4NCg0KKGlu IHByYWN0aWNlLCB0aGF0IGNhbid0IGhhcHBlbiBhcyB0aGUgY29tcGlsZXIgaGFzbid0IHZp c2liaWxpdHkgb24gDQpMWjRGX2NvbXByZXNzRnJhbWUoKSBpbnRlcm5hbHMgdG8gcGVyZm9y bSBzdWNoIG9wdGltaXphdGlvbiwgYXMgaXQncyBhIA0KZXh0ZXJuYWwgbGlicmFyeSkNCg0K PiArICAgIGNsZW4gPSBMWjRGX2NvbXByZXNzRnJhbWUoY3R4LT5zYXZlLmx6NF9jb21wcmVz c19idWYsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdHgtPnNhdmUubHo0 X2NvbXByZXNzX2J1Zl9zaXplLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y3R4LT5zYXZlLmx6NF9zdGFnaW5nX2J1ZiwgcmF3LCAmcHJlZnMpOw0KPiArDQo+ICsgICAg aWYgKCBMWjRGX2lzRXJyb3IoY2xlbikgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgSVBSSU5U RigiTFo0IGNvbXByZXNzaW9uIGZhaWxlZDogJXMsIHNlbmRpbmcgdW5jb21wcmVzc2VkIiwN Cj4gKyAgICAgICAgICAgICAgICBMWjRGX2dldEVycm9yTmFtZShjbGVuKSk7DQo+ICsgICAg ICAgIGNsZWFudXBfY29tcHJlc3Npb24oY3R4KTsNCj4gKyAgICAgICAgY3R4LT5zYXZlLmNv bXByZXNzaW9uID0gWENfU1JfQ09NUFJFU1NfTk9ORTsNCj4gKyAgICAgICAgcmV0dXJuIGlv dmNudDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICAvKiBUaGUgc3RyZWFtIGZvcm1hdCBhbGxv d3MgTFo0IG9ubHkgd2hlbiBzdHJpY3RseSBzaG9ydGVyLiAqLw0KPiArICAgIGlmICggY2xl biA+PSByYXcgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgREJHUFJJTlRGKCJMWjQ6ICV6dSAt PiAlenUgYnl0ZXMsIHNlbmRpbmcgdW5jb21wcmVzc2VkIiwgcmF3LCBjbGVuKTsNCj4gKyAg ICAgICAgcmV0dXJuIGlvdmNudDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBEQkdQUklOVEYo IkxaNDogJXp1IC0+ICV6dSBieXRlcyAoJXp1LiV6dSUlIHJhdGlvKSIsIHJhdywgY2xlbiwN Cj4gKyAgICAgICAgICAgICAgKGNsZW4gKiAxMDAwIC8gcmF3KSAvIDEwLCAoY2xlbiAqIDEw MDAgLyByYXcpICUgMTApOw0KPiArDQo+ICsgICAgLyogUGFkIGluIHBsYWNlOiByYXcgaXMg YSBtdWx0aXBsZSBvZiBSRUNfQUxJR04gYW5kID4gY2xlbiwgc28gaXQgZml0cy4gKi8NCj4g KyAgICBtZW1zZXQoKHVpbnQ4X3QgKiljdHgtPnNhdmUubHo0X2NvbXByZXNzX2J1ZiArIGNs ZW4sIDAsDQo+ICsgICAgICAgICAgIFJPVU5EVVAoY2xlbiwgUkVDX0FMSUdOKSAtIGNsZW4p Ow0KPiArDQo+ICsgICAgaW92WzJdLmlvdl9iYXNlID0gY3R4LT5zYXZlLmx6NF9jb21wcmVz c19idWY7DQo+ICsgICAgaW92WzJdLmlvdl9sZW4gPSBST1VORFVQKGNsZW4sIFJFQ19BTElH Tik7DQo+ICsNCj4gKyAgICAqZmxhZ3MgfD0gUEFHRV9EQVRBX0FMR09fTFo0Ow0KPiArICAg ICpsZW5ndGggLT0gcmF3IC0gY2xlbjsNCj4gKw0KPiArICAgIC8qIGlvdlswXSBoZWFkZXJz LCBpb3ZbMV0gcGZucywgaW92WzJdIHBhZ2UgZGF0YSBmcmFtZS4gKi8NCj4gKyAgICByZXR1 cm4gMzsNCj4gK30NCj4gKyNlbmRpZiAvKiBYR19TUl9MWjQgKi8NCj4gKw0KPiAgIC8qDQo+ ICAgICogV3JpdGVzIGEgYmF0Y2ggb2YgbWVtb3J5IGFzIGEgUEFHRV9EQVRBIHJlY29yZCBp bnRvIHRoZSBzdHJlYW0uICBUaGUgYmF0Y2gNCj4gICAgKiBpcyBjb25zdHJ1Y3RlZCBpbiBj dHgtPnNhdmUuYnVmZmVycy0+YmF0Y2hfcGZucy4NCj4gQEAgLTIyOCw2ICszNDAsMjYgQEAg c3RhdGljIGludCB3cml0ZV9iYXRjaChzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4KQ0KPiAg ICAgICBmb3IgKCBpID0gMDsgaSA8IG5yX3BmbnM7ICsraSApDQo+ICAgICAgICAgICByZWNf cGZuc1tpXSA9ICgodWludDY0X3QpKHR5cGVzW2ldKSA8PCAzMikgfCBiYXRjaF9wZm5zW2ld Ow0KPiAgIA0KPiArICAgIHN3aXRjaCAoIGN0eC0+c2F2ZS5jb21wcmVzc2lvbiApDQo+ICsg ICAgew0KPiArICAgIGNhc2UgWENfU1JfQ09NUFJFU1NfTk9ORToNCj4gKyAgICAgICAgYnJl YWs7DQo+ICsNCj4gKyAgICBjYXNlIFhDX1NSX0NPTVBSRVNTX0xaNDoNCj4gKyNpZiBkZWZp bmVkKFhHX1NSX0xaNCkNCj4gKyAgICAgICAgaW92Y250ID0gbHo0X2NvbXByZXNzX2JhdGNo KGN0eCwgaW92LCBpb3ZjbnQsIG5yX3BhZ2VzLA0KPiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmhkcnMucGFnZV9kYXRhLmZsYWdzLCAmaGRycy5yZWMubGVuZ3Ro KTsNCj4gKyAgICAgICAgLyoNCj4gKyAgICAgICAgICogLTE6IGlvdlsyLi5dIGlzIG5vdCBu cl9wYWdlcyBwYWdlcy4gIENvbXByZXNzZWQ6IHN0YWxlIGJ5dGVzIGZvcg0KPiArICAgICAg ICAgKiBtaXNzaW5nIHBhZ2VzLCBvciBleHRyYSBwYWdlcyBkcm9wcGVkLCB1bnNlZW4gYnkg dGhlIGNoZWNrc3Vtcy4NCj4gKyAgICAgICAgICogVW5jb21wcmVzc2VkOiByZWMubGVuZ3Ro IHdvdWxkIG5vdCBtYXRjaCB0aGUgYnl0ZXMgd3JpdGV2KCkgd3JpdGVzLg0KPiArICAgICAg ICAgKi8NCj4gKyAgICAgICAgaWYgKCBpb3ZjbnQgPCAwICkNCj4gKyAgICAgICAgICAgIGdv dG8gZXJyOw0KPiArI2VuZGlmDQo+ICsgICAgICAgIGJyZWFrOw0KPiArICAgIH0NCj4gKw0K PiAgICAgICBpZiAoIHdyaXRldl9leGFjdChjdHgtPmZkLCBpb3YsIGlvdmNudCkgKQ0KPiAg ICAgICB7DQo+ICAgICAgICAgICBQRVJST1IoIkZhaWxlZCB0byB3cml0ZSBwYWdlIGRhdGEg dG8gc3RyZWFtIik7DQo+IEBAIC04MDcsNiArOTM5LDcgQEAgc3RhdGljIHZvaWQgY2xlYW51 cChzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4KQ0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTlJQQUdFUyhiaXRtYXBfc2l6ZShjdHgtPnNhdmUucDJtX3NpemUp KSk7DQo+ICAgICAgIGZyZWUoY3R4LT5zYXZlLmRlZmVycmVkX3BhZ2VzKTsNCj4gICAgICAg ZnJlZShjdHgtPnNhdmUuYnVmZmVycyk7DQo+ICsgICAgY2xlYW51cF9jb21wcmVzc2lvbihj dHgpOw0KPiAgIH0NCj4gICANCj4gICAvKg0KDQo= --------------0XcP9laRqg6EhmwbIUkKb00l-- --------------Mg8pnVzX6fZR9CNWp0lOxo8g 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+p0QLLz9AFAmrh2okFAwAAAAAACgkQZg+p0QLLz9BP 8gv/c0cRGvHf5CurOSAGMy9b6UbV5j5c8vBsqYEeE/YYz4Pxijv1+qw4lDGAKASBfVk8maVEuGQT hKq7cPQfMQDNSr29VDPDSgINr7E5h8g7He9S5Iln935ZyZm0vA/QOrFBLRf2xRauZQDjeIDxoitG uIPqskDEJBbPANqSQx4ih1uelMo3CGBCsYZYUZVLlN0xzNNJi3O5GeKSxpsV7fZG5GS/W2mqR+pu 047LdP1n3GNqAOP6n/YDQWkA+sPi9Pf9S3t+16PBCP/ADZenjiyPz3oqGlnAZUOGIy7z6IsI6zN4 X66U1ePSjk/JS9lcfIg5Cev9F3mdFNbyYj0GXS9xGbXugM8X6i4x24WN+vKjQuOlHlLZU2tJywT8 4wlkXGl07pARoW79s+uB8yqt6y8g7HC3EKJACIOt+HNk6uY9thc3ktDUHWnCXrTybuzTnN4UginV XUzS/5KH13PXm6YUOYOfpwyyBjcm1jwQJ1Zjh7oSYZ//3qNI/waG/lWJcRwZ =g4OW -----END PGP SIGNATURE----- --------------Mg8pnVzX6fZR9CNWp0lOxo8g-- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:31:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:31:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463127.1674092 (Exim 4.92) (envelope-from ) id 1xM1sI-0004YY-Dc; Wed, 28 Oct 2026 11:31:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463127.1674092; Wed, 28 Oct 2026 11: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 1xM1sI-0004YR-B4; Wed, 28 Oct 2026 11:31:22 +0000 Received: by outflank-mailman (input) for mailman id 1463127; Wed, 28 Oct 2026 11:31:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM1sH-0004Y5-4R for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:31:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM1sG-00DVe6-A2 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:31:20 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1dd02-e002-0a2a0a5209dd-0a2a450883a0-20 for ; Wed, 28 Oct 2026 12:31:17 +0100 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 6ae1dd05-f659-0a2a45080019-d1558032ecb4-3 for ; Wed, 28 Oct 2026 12:31:17 +0100 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a2d6d01ecbso5580455e9.0 for ; Wed, 28 Oct 2026 04:31: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-4a97c9f150fsm36523685e9.10.2026.10.28.04.31.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 04: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=1793187077; x=1793791877; 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=Nhxjzuv6QyYAU5FPVLgD5/fgE70sNx8tufTqa7+vrLM=; b=ebvj5YMJng0iMTJPs6DuEbQYRCyTrxOge39l/N5AheOwQvqjISVypt8BjDwKzNuTdi 7uwE3MAM9/crwucbMPX4T5HuuAOy93vKiVCZ9qUoCjkRQkSGgmFwwK73kVfcJ88POMHd n/pvV+4HcO62edShE6B7OgLiUk6iEwqv1xsewUscdhszpGlMQC2EPAJdrnPoRvtDGdTw EpZBdA0orPDEHx3CVmqRliQlTSz1BPiF44EO7T2/7LcmjqDF6yrkO3bYvKM8DXg2v9Vv N3m8/5tyMmG92qnuYBVtBMjpZORgJnFIQwoQoDQprABYOEUIWAzkSmztqJpOLcNsX9vW uuLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793187077; x=1793791877; 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=Nhxjzuv6QyYAU5FPVLgD5/fgE70sNx8tufTqa7+vrLM=; b=Ne1abDlfl1nuvqM+g+4brqNMXWxOrM9rsoa/AKmGQ4ucbl2PAM5wzCENqiDkwyWVIo 4OsrSMKmTrR3aCUUE/+PURWXuR4y8iJGYrOngmJik9Bi6AXpOy80TqTik9BqKa9KSzsd /w/aoUO4JJREzf+BwJz2iPqvJBtLF2wG05qU8BWz9MR/ufUhY9Hj75QCTY3laKrRqAer 6u4Go0kVyniMbMR+PJe90ZajzGo7TJO2CiCik8AkCHs6h7TQ7YZvt+CGjrXGF5Vj5X0N PkoAyT4/2ysEr88KEGL3LzXFk7V3Knu1rRss59b1KfHxL/EGhoUdap+gQ7nhV8GdP/lG SAgw== X-Forwarded-Encrypted: i=1; AKwUvBwjuIIYtUSI6FsUT7sgziiOoJsgN/RqNs4hrUBqJKzSjuVkjsXkaAopIAFQhUppIwj5o6LJlb4yusk=@lists.xenproject.org X-Gm-Message-State: AFq9FYL3Yg9TEjH/G+mIEYm14e9Txs7I/kzRaI53+ufQp6ToKhBjWbTc FqYfND81A4xxwmuhPlyLixXmNngijy0yzXFSr06/931N1x5K9TCRE27+EgHg77Kj+Q== X-Gm-Gg: AYBFou2hFVLKfd9TobVRq0XUAVmvWdHj1PPEotaf06cMLCIZeC6BDvDj77Rh1c2YBoE o/EHCkBy49wVcUu+oJU/ArqgABc2POiNRTQVWd/SVkiLiCBXECy/YCI0GENX122QA98foi+XrfN jDSpZ023WmONQmsfVTMhWIj2NMqxYT5O6RfVeHZTpH2kql+dodWdWRpUT2SlyaqHTUPdSPSiky/ KIYddeTT11/fHjs2EmZvvXNzh/DtB4AWRLnnwEYtTc1HmaQVxzhD7QMVH5LVdh8ij0Wgd2Hkayv quz6x2Msssjqmrj/JFj0BxjbcKZYDI0ddDha/3T5KLOJOt+uBEiH0wtYNmc0d00p8bVonN2pGj5 22Ikp65AwXmwwrJx7QA6pxUyLb20oztKhvAEdVmlf7DcDRMiHd2b53gtIRRwk3GLIjdpaSVav9e 96EYaOYb4bWuawvfQ/X4CIIpMoPhNGe8sdMoWmTkcqrOqEAzJQrJiWHuvSoJkHj0go/FQ6fVtM9 yERtfi/F5wv5OuQ48doRgyOiPxAn6kBadV7NjE9ASVM7rBRzCjoX1jQw7X/37Q6hGMWABqdQQtf WkDo+8Je0c6I/33+Rj5Ud7ucsJC2SVwAuMxg/aQ7OoYRn12r4cnnj664WaEqgsmpc53ggme381y Qq8xSbcOCU/O1x096tw== X-Received: by 2002:a05:600c:4f4a:b0:4a3:5c67:55ed with SMTP id 5b1f17b1804b1-4a966c40261mr38463915e9.12.1793187076637; Wed, 28 Oct 2026 04:31:16 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 12:31:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/vpt: Validate timer object with generation number To: Tu Dinh Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <1792717952.8631fc262581453bbf619ec5b2062170.1a166511467000f79f@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: <1792717952.8631fc262581453bbf619ec5b2062170.1a166511467000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793187077-D674387B-96AB6577/10/78276251493 X-purgate-type: spam X-purgate-size: 1920 On 23.10.2026 03:12, Tu Dinh wrote: > The remote completion path of pt_update_irq removes timers from tm_list > by checking that their addresses match the previous iteration. However, > if the guest rearms a timer during the gap between two list iterations, > the resulting timer object is no longer the same, even if their > addresses match. Removing the timer from the list will then lose the > armed timer object. > > Record a generation number in each timer object upon arming, and check > that the generation number matches before removing it from the list. Fixes: 0bcbc971feaa ("x86/vpt: add support for level interrupts") > Signed-off-by: Tu Dinh Reviewed-by: Jan Beulich preferably with ... > --- a/xen/arch/x86/hvm/vpt.c > +++ b/xen/arch/x86/hvm/vpt.c > @@ -318,6 +318,7 @@ int pt_update_irq(struct vcpu *v) > struct list_head *head = &v->arch.hvm.tm_list; > struct periodic_time *pt, *temp, *earliest_pt; > uint64_t max_lag; > + uint64_t generation; ... this folded with the earlier line. > --- a/xen/arch/x86/include/asm/hvm/vpt.h > +++ b/xen/arch/x86/include/asm/hvm/vpt.h > @@ -34,6 +34,7 @@ struct periodic_time { > u8 irq; > struct vcpu *vcpu; /* vcpu timer interrupt delivers to */ > u32 pending_intr_nr; /* pending timer interrupts */ > + u64 generation; /* distinguish two armings of the same timer */ > u64 period; /* frequency in ns */ > s_time_t scheduled; /* scheduled timer interrupt */ > u64 last_plt_gtime; /* platform time when last IRQ is injected */ Also, no matter that adjacent lines use u, it wants to be uint_t for new fields. Otherwise we will never get rid of the remaining u. I can make these adjustments while committing, no need to send a v2 just for that. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:39:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:39:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463137.1674103 (Exim 4.92) (envelope-from ) id 1xM1zw-0005Br-6Y; Wed, 28 Oct 2026 11:39:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463137.1674103; Wed, 28 Oct 2026 11:39: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 1xM1zw-0005Bk-1b; Wed, 28 Oct 2026 11:39:16 +0000 Received: by outflank-mailman (input) for mailman id 1463137; Wed, 28 Oct 2026 11:39:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM1zu-0005Be-Dl for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:39:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM1zt-009qdP-Bn for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:39:13 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1ded0-bab6-0a2a0a5309dd-0a2a450a9846-36 for ; Wed, 28 Oct 2026 12:39:13 +0100 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 6ae1dedf-f2d2-0a2a450a0019-aceafc1fb248-3 for ; Wed, 28 Oct 2026 12:39:12 +0100 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id E8802435E7 for ; Wed, 28 Oct 2026 11:39:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF95E1F031E9 for ; Wed, 28 Oct 2026 11:39:10 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5be4c78e8caso903751e87.1 for ; Wed, 28 Oct 2026 04:39: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="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=1793187550; bh=sOScShlNJOoFQgumDsqaC2sVgmpV4+y6Yzg+EW5P6X4=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=V3aBNqqFFHK8/iCpvfjUC4nqv71d4gzLapwxCef4YXC24PEvK5vHB+xdOeL7szLll P+FI7kOVX15iyVgW6L5BqB5j66cUsU58EFNBVc4ed1gRumoqiCbC4e+4/fMtoPPsBi 389uKh3znOcDxhFOO4xeIVuJHUWRavRXaxLHJn2UManYPCHBMECjV9wAGJYHfg7uRm oE9BZ712DtB2yvqohWmRmnKolH9LeojudIZ3GAkE5g2bjpf6/E/ujmhxw0Acr5Ue7J /SryS8fSPLV7LahdfJR0nny8tZNZQ0l6lyXB4kclXqeLy9UOpL1SeAi4UciWGJrnY9 J8Z5+YeM8O4VQ== X-Forwarded-Encrypted: i=1; AKwUvBxNb7Yn7JLdTOacQATJUQ+3BaZZhJOdPZPljutt4X1e5hMk4NnNWvl9LDJQPl1ppgqcqWyQ/nbLzrU=@lists.xenproject.org X-Gm-Message-State: AFq9FYLqJkhJyOGYtxTiGfzsAGkv113AblbdCRtstfyLg1BiHwn3viwS h5tZ1+B2mKySJ4mFL93e1BlpOtieWIPuhD0Yl3z79jRBSB+try2TuZydu6N1//DWLbHPaqUwhKA OkyYpr/L6aD5wqbhJDEnWHqVc1ESPIRo= X-Received: by 2002:a05:6512:1111:b0:5b9:6603:d451 with SMTP id 2adb3069b0e04-5bfcad31c8emr697328e87.3.1793187548999; Wed, 28 Oct 2026 04:39:08 -0700 (PDT) MIME-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-5-irogers@google.com> In-Reply-To: <20261027223847.652884-5-irogers@google.com> From: "Rafael J. Wysocki (Intel)" Date: Wed, 28 Oct 2026 12:38:56 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-NXF3tWCMDzaNjIN417c7ZMuQGYjVHoQ_x6BSITeW_KdKoI_jbnClXt6k Message-ID: Subject: Re: [PATCH v2 4/9] cpufreq: governor: Initialize kobj_type release callback statically To: Ian Rogers Cc: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich , Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , =?UTF-8?Q?Christian_K=C3=B6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Viresh Kumar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1793187553-50ECACFC-8C95BE01/0/0 X-purgate-type: clean X-purgate-size: 4424 On Tue, Oct 27, 2026 at 11:39=E2=80=AFPM Ian Rogers wr= ote: > > Export cpufreq_dbs_data_release() and set .kobj_type.release statically > in the ondemand and conservative governors so their gov_attr_set > kobjects have a valid release callback statically initialized, matching > cpufreq_governor_dbs. Remove the redundant runtime assignment in > cpufreq_dbs_governor_init(). > > This prepares for annotating struct kobj_type::release with > __must_init. > > Signed-off-by: Ian Rogers Do you want stuff to be picked up by maintainers, or do you want to route it yourself? > --- > drivers/cpufreq/cpufreq_conservative.c | 5 ++++- > drivers/cpufreq/cpufreq_governor.c | 4 ++-- > drivers/cpufreq/cpufreq_governor.h | 1 + > drivers/cpufreq/cpufreq_ondemand.c | 5 ++++- > 4 files changed, 11 insertions(+), 4 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpu= freq_conservative.c > index 02bfd46543e9..146a2353b1a2 100644 > --- a/drivers/cpufreq/cpufreq_conservative.c > +++ b/drivers/cpufreq/cpufreq_conservative.c > @@ -318,7 +318,10 @@ static void cs_limits(struct cpufreq_policy *policy) > > static struct dbs_governor cs_governor =3D { > .gov =3D CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"), > - .kobj_type =3D { .default_groups =3D cs_groups }, > + .kobj_type =3D { > + .release =3D cpufreq_dbs_data_release, > + .default_groups =3D cs_groups, > + }, > .gov_dbs_update =3D cs_dbs_update, > .alloc =3D cs_alloc, > .free =3D cs_free, > diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq= _governor.c > index f3bd3dbe7c41..f8b5aca09b6b 100644 > --- a/drivers/cpufreq/cpufreq_governor.c > +++ b/drivers/cpufreq/cpufreq_governor.c > @@ -419,7 +419,7 @@ static void free_policy_dbs_info(struct policy_dbs_in= fo *policy_dbs, > gov->free(policy_dbs); > } > > -static void cpufreq_dbs_data_release(struct kobject *kobj) > +void cpufreq_dbs_data_release(struct kobject *kobj) > { > struct dbs_data *dbs_data =3D to_dbs_data(to_gov_attr_set(kobj)); > struct dbs_governor *gov =3D dbs_data->gov; > @@ -427,6 +427,7 @@ static void cpufreq_dbs_data_release(struct kobject *= kobj) > gov->exit(dbs_data); > kfree(dbs_data); > } > +EXPORT_SYMBOL_GPL(cpufreq_dbs_data_release); > > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) > { > @@ -488,7 +489,6 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy *= policy) > policy->governor_data =3D policy_dbs; > > gov->kobj_type.sysfs_ops =3D &governor_sysfs_ops; > - gov->kobj_type.release =3D cpufreq_dbs_data_release; > ret =3D kobject_init_and_add(&dbs_data->attr_set.kobj, &gov->kobj= _type, > get_governor_parent_kobj(policy), > "%s", gov->gov.name); > diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq= _governor.h > index 806d8fb4dff1..1026712bb79b 100644 > --- a/drivers/cpufreq/cpufreq_governor.h > +++ b/drivers/cpufreq/cpufreq_governor.h > @@ -150,6 +150,7 @@ static inline struct dbs_governor *dbs_governor_of(st= ruct cpufreq_policy *policy > } > > /* Governor callback routines */ > +void cpufreq_dbs_data_release(struct kobject *kobj); > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy); > void cpufreq_dbs_governor_exit(struct cpufreq_policy *policy); > int cpufreq_dbs_governor_start(struct cpufreq_policy *policy); > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq= _ondemand.c > index 9942dbb38dae..7386d043c665 100644 > --- a/drivers/cpufreq/cpufreq_ondemand.c > +++ b/drivers/cpufreq/cpufreq_ondemand.c > @@ -374,7 +374,10 @@ static struct od_ops od_ops =3D { > > static struct dbs_governor od_dbs_gov =3D { > .gov =3D CPUFREQ_DBS_GOVERNOR_INITIALIZER("ondemand"), > - .kobj_type =3D { .default_groups =3D od_groups }, > + .kobj_type =3D { > + .release =3D cpufreq_dbs_data_release, > + .default_groups =3D od_groups, > + }, > .gov_dbs_update =3D od_dbs_update, > .alloc =3D od_alloc, > .free =3D od_free, > -- > 2.56.0.313.g2479322e68-goog > > From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:43:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:43:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463144.1674110 (Exim 4.92) (envelope-from ) id 1xM24D-0006he-LA; Wed, 28 Oct 2026 11:43:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463144.1674110; Wed, 28 Oct 2026 11: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 1xM24D-0006hX-IU; Wed, 28 Oct 2026 11:43:41 +0000 Received: by outflank-mailman (input) for mailman id 1463144; Wed, 28 Oct 2026 11:43:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM24C-0006hQ-Tv for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:43:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM24B-00CLJ0-UP for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:43:39 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1dfe3-2eae-0a2a0a5409dd-0a2a4503e13c-16 for ; Wed, 28 Oct 2026 12:43:39 +0100 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 6ae1dfe6-fae8-0a2a45030019-d155dd2edc7a-3 for ; Wed, 28 Oct 2026 12:43:34 +0100 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48c5358fc28so707207f8f.0 for ; Wed, 28 Oct 2026 04:43: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-48e3ece14a1sm29167895f8f.57.2026.10.28.04.43.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 04: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=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=1793187814; x=1793792614; 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=c0cBDTacXy9XImVG64ba+CUZaXBj6xD9seAYFIeyLpo=; b=ejB4Dk+vKn1oeCtnBNNgzrq3vuvSxYjrPFYoAiGBNaL7c8hnVBFaMlsBk7rdapgLsG Pde+H6LmpOVUtVoquheYS9jXL5fzik8UZHf5irvrCYzvxU3WUVqIACWF85xRhmZh+X76 FcgnL2PSd2SD/56a/Jn3g8madGPybPydNPB+k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793187814; x=1793792614; 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=c0cBDTacXy9XImVG64ba+CUZaXBj6xD9seAYFIeyLpo=; b=26QaQMT0+GauOR5gFnkGYaVh+8LXJ4a5u/nHAV/S09rBxzWByd4dPar5h1PG/RF5uH WaqT3JjrbsVLqi+IBCO1gVXXI1IRbWpK2qmv78FfG7v+34uTVtgi7PhyoVfZM47AjV+V yx++fW7TRe06dq9f3OZdPG6KzFpcane1gkaWrbMN8USf+3QgL5jvEDP8fZEjd2wk4BY3 rExcZNlRHL6kQRRKIlhQDfzZqi8XmaJrxGloslUNF9L/IHvB+bQhmXbTBFbcj7T8zSq5 a3dEn3oNhSDY/Mq2ID5jLofHP0qBBVRr2mfmjCh6a0IztFuNyaLgVqDHsSRFHSvA+zC0 wcIA== X-Gm-Message-State: AFq9FYJ0DW/4ug2s03sY8Yn10K1j1pvO+zdesYQCc7mjt6mn2ARSir9S axsQsZN66os5D0UhZmqOhTSZwBr9VDF/L8i63StTohoA91qXSW0E3Dh3vd4EwORuTu163x/zspB 1nXSGiz8= X-Gm-Gg: AYBFou3LB05oDe+0oL2ia7iimquilozcNhNJfEW/nx+A/p23qMWoT7IRRlDow1dz9o8 FNFI1+49jqDcfuFhwnO+gQEYEzXjjZkVlGPPSomhKicK5aqQsK1Xh91HPEvZr0e2xPkxCOo5nGR enz4YHhR9+y/CVnxVz4PMoELQSH0P5i/eDRDSEELMucW90c0HWFxl8iTJtrJ0FyqwGfx8y3v/7V /+K+xRhswV0trhkO/aPjVZEpAIFJW1Ne24aWj5SThjh94nM02FLlH9TZ+ZM9MKTFPzNZ2B57lFU /UC/W0v6lWU6xVvKDSlsh8A6FdEKy3Eh0m2zCnMDm5hETP0/ppOsNH8qlJ5LBUIRE/TJb5DMkug eOssJPJ/mylfnXC9jNvRBimnHbGcIYUaNuQFKFnn/7TB8CQcHDtW3wUmxLF00chBj3WdfpTs7VH QDXmafncGDEscVvZJV/h3a/tvHpAz02FRU5gDgRzQVEGLaqh/VhCNTvropYT9Meq4zWe1lxR0HA 5Ni/5BCAoaaH0lPkoiFp9WdpYooJ0X6cdjqbhIXqFvrf+dr6sYQO114ue9XOypgWHN0n6zALjOd HIQiWofhMDzh+gHsZNSYQB23aB9LAYmmlvznLBFu+9FZdDdV3Ue3O00MyzkMY3MrHDXN4VNPcb5 UKNQo X-Received: by 2002:a05:6000:438a:b0:48e:5d63:a4e5 with SMTP id ffacd0b85a97d-48e5d63a673mr4173784f8f.0.1793187814025; Wed, 28 Oct 2026 04:43:34 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] xen/bitops: Remove unused get_bitmask_order() Date: Wed, 28 Oct 2026 11:43:28 +0000 Message-Id: <20261028114328.1514337-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/1793187819-76CF84E9-46B0358C/10/78276251493 X-purgate-type: spam X-purgate-size: 1157 This is a wrapper around fls() with an incorrect comment about the output range of the function. It's also unused, so remove it. Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beulich CC: Julien Grall CC: Roger Pau Monné CC: Stefano Stabellini --- xen/include/xen/bitops.h | 8 -------- 1 file changed, 8 deletions(-) diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h index 24882fb4822d..214613f4b41c 100644 --- a/xen/include/xen/bitops.h +++ b/xen/include/xen/bitops.h @@ -389,14 +389,6 @@ extern unsigned long find_first_zero_bit(const unsigned long *addr, unsigned long size); #endif -static inline int get_bitmask_order(unsigned int count) -{ - int order; - - order = fls(count); - return order; /* We could be slightly more clever with -1 here... */ -} - static inline int get_count_order(unsigned int count) { int order; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:46:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:46:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463151.1674119 (Exim 4.92) (envelope-from ) id 1xM270-0007OL-1o; Wed, 28 Oct 2026 11:46:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463151.1674119; Wed, 28 Oct 2026 11:46: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 1xM26z-0007OE-VL; Wed, 28 Oct 2026 11:46:33 +0000 Received: by outflank-mailman (input) for mailman id 1463151; Wed, 28 Oct 2026 11:46:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM26y-0007O8-Jh for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:46:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM26x-0024iR-TJ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:46:31 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1e095-e002-0a2a0a5209dd-0a2a4503d5c0-8 for ; Wed, 28 Oct 2026 12:46:31 +0100 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1e097-fae8-0a2a45030019-d155dd2fa589-3 for ; Wed, 28 Oct 2026 12:46:31 +0100 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48e0d1da913so690353f8f.1 for ; Wed, 28 Oct 2026 04:46: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-48e3ebd48fasm27816771f8f.31.2026.10.28.04.46.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 04:46: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=1793187991; x=1793792791; 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=K0bOMVZPXAm5IU2Mgv8WQH5ASwOH3yLkWTr+Ua5rv5I=; b=a0XnvcMgjI94MfBeZiYMLsNkfSql8akzETUISQYqBprjEmVTRpSU6+225kqDu3X9Zo v/mRFJOmKqsPTwUxVI3y9kxNevTd3mAKmEgrsXcXYoMqWSIOhjb5aBOwkr7zD410Ru3z NOvjc9rR7OaRVJVMuEGEXIQc6ds+ddT1ZelbBFDervlJNwlPSDEeN4VPl2zpkWiYu7Em 8RcZs+iyjC8VCg8pUZVzpxjFj0s4/At1nqInGjqenJHvuijb/CYxHAe5GYOWWmvSQrxG PPe1mjDUAllvy1uJXtvxkxO8FMKgodG7p000/Q0MCHpUBvnVVIM2wkwB+RLckRKnd7Bc tCoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793187991; x=1793792791; 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=K0bOMVZPXAm5IU2Mgv8WQH5ASwOH3yLkWTr+Ua5rv5I=; b=ZjUng5JyDBt4P9fqo/6wDkNP4blwv1aas2Ww9+NOomNQ7d9Hp0uFmIhBCvEIpnY4zX TVn//4hqiBP05VGdSq8ueBDFzeGF1c9le+sdQrf88h8HaqTLu+lD4FFVHBhC8LtxwsOm qWuJFnsJUxcOsp7HAPlO3XXP2KXv6B8ZWxaKbqIhxGL0LX49srfD8h1FOd95W0lSlBFz vt2LxuzB2bPClbqOGztfGmAGKjK75HsiEmZHeLOFxkcy0fKH1vCsGu/FCn+wt5X3/KVj f+tsIoO74B4wMyKPFo6lV5RjpYSEzx1urKXodjzmAXFrvuhbMO1xyuDA8IJkGeQEVsfq yisg== X-Forwarded-Encrypted: i=1; AKwUvBxiXZHBzib1j7EdAmKiaeEf28AR8gGOYc3evlYMrkH0S0GW2PeGxLrKoXWvFV5OQjvLYZAFkGA3/Mk=@lists.xenproject.org X-Gm-Message-State: AFq9FYKYAeU5/inbsEtUqe4Mtiuu2UEJ2yhmeIVk7Qof1vNwXD1Q9hZD 2oVXh3or3uVob+T+cdeVn4kdfODUrR7J+qbu1eg9RHx2HONFrfXJgeeitNVT10H84Q== X-Gm-Gg: AYBFou2Q4yiI8Gd5mnOzvcAR7M2oQ1mFZpvZbIBrLpb5ixMUJGtrYcY2N5VWvIEFcdd zmQMV9NDwLqdqWYy2mxp6zASKGPhnLODG/ompVxgdxtGQm60NVadFWkT1xfjz/FOpJqOuLkPp90 eTG6Z3GW4KgvnXAbWgADX99G9QmVh4kmv5INTbS4DJEXUkQ/HHdW3JMfiT1njwKGJaLHAMJcSLz nQ4lK8nwnA1vBh9B7gBosaHJ1jkp9ArsLNFOxlq2yQDw5Bs5PC58Tdl5AmLaL85pUNlqDQ45D90 RFTYqRSMg0a8L7HO5w6h62NDtOutGB8oLQgCt2Bj+PQY/aqPVGBIvd6prS/IjQiv5LP20A3+X/u qLj6AH80ObPPKIILKa5m1J6ogJqMt0CXu2FgGDqooe/zbQWhu/fMdu8JyV0uYhCHkOkW3MEdnDS k62YdKESZRUibp8fb7i/ITg9o3umiwSRtjq96iIl0odbRalJjfLckT6Xh3ZY/BnWRURuFy9L7SD dXqmO8CGl2hhQLBiYPgAGPQ/PeWSoy6Zx1iMCJ2yE5VmzReJlwsC1VMKbtR5CcxHzhX7IiNJVEt xGy6ge+JaErO5cJE2fJ1G1uHOxVu3oqDqLHWLSBe/KLP/jcQn/jEl7f11Zb6z/DEFF6thsUfvs7 UHSDZBUf8cM8r5H3jUQ== X-Received: by 2002:a05:6000:490b:b0:48e:850:c0b7 with SMTP id ffacd0b85a97d-48e601eb154mr2919581f8f.1.1793187991186; Wed, 28 Oct 2026 04:46:31 -0700 (PDT) Message-ID: <8ee013ce-e6ff-48be-8d55-9870ad14e26e@suse.com> Date: Wed, 28 Oct 2026 12:46:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/bitops: Remove unused get_bitmask_order() To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel References: <20261028114328.1514337-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: <20261028114328.1514337-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1793187991-6C6DE4E9-C389CC59/10/78276251493 X-purgate-type: spam X-purgate-size: 290 On 28.10.2026 12:43, Andrew Cooper wrote: > This is a wrapper around fls() with an incorrect comment about the output > range of the function. It's also unused, so remove it. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Oct 28 11:46:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 11:46:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463153.1674129 (Exim 4.92) (envelope-from ) id 1xM27J-0007iH-Cm; Wed, 28 Oct 2026 11:46:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463153.1674129; Wed, 28 Oct 2026 11: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 1xM27J-0007iA-9A; Wed, 28 Oct 2026 11:46:53 +0000 Received: by outflank-mailman (input) for mailman id 1463153; Wed, 28 Oct 2026 11:46:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM27I-0007hk-1O for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 11:46:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM27H-00Aufp-A7 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:46:51 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1e0a2-8faa-0a2a0a5109dd-0a2a45039dc8-34 for ; Wed, 28 Oct 2026 12:46:51 +0100 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 6ae1e0aa-fae8-0a2a45030019-b9ff1c1293f7-3 for ; Wed, 28 Oct 2026 12:46:51 +0100 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 1a1825590b6000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 11:46:48 +0000 Received: from [192.168.1.61] (142.220.66.37.rev.sfr.net [37.66.220.142]) (Authenticated sender: ngoc-tu.dinh@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 5E55582C62; Wed, 28 Oct 2026 12:46:47 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=8LhirgX8r53rafbUvtgDISlH8AXpATTq32fwJlc4G2Y=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=rQS0QNsZ6DTcBQ3EQ8JUCjv29sbb9kqKoZRogElPqbWy1fn/6Xs2VEACVTheA92PvGjWGnUv/ EpsR3G7GWOplB7vJI3zQh3qfoeL4yheK75k+GgHipIhUnZvADqn5tzk9kquzFPgaUCjoz+s0mBp lKe10X2w/XHFy3du1sYrc3qjBDJ6Jox2wY45qDz/Z4HE1NIBLVr9Lhga6vAsi3cj1jP6xw5MY28 hVjgpx3K1z5EG8FZR3U1TgDK3a2c8GgH2KArtULE3SUydRx0b4uxXOIu/ONAuDn9n+oBJUWsOVB Nny7N62Y2NwrlJWZNHtlfoz3D7rk29Y0sHJiPj90KNEw== X-Zone-Loop: f7550b081fbb518ca708cfed0b706b83324fc4f54f13 x-campaign-type: default x-transaction-id: 58914819-cdbc-4c1b-8480-2d44f4b35178 x-swg-uid: 01-cddde208-5d85-411e-9ab1-787f1201e6d9 X-Mailer: Sweego Message-ID: <1793188008.8631fc262581453bbf619ec5b2062170.1a1825590b6000f79f@vates.tech> x-swg-bid: 1793188008.8631fc262581453bbf619ec5b2062170.1a1825590b6000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 12:46:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/vpt: Validate timer object with generation number Content-Language: en-US To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <1792717952.8631fc262581453bbf619ec5b2062170.1a166511467000f79f@vates.tech> From: Tu Dinh In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.289.d38e611745819b3.1a182558e2c.8ee8a2f71509cc74=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793188007468 X-purgate-ID: tlsNG-33051d/1793188011-6D8D54E9-CE0E3308/10/78276251493 X-purgate-type: spam X-purgate-size: 2557 ---=Part.289.d38e611745819b3.1a182558e2c.8ee8a2f71509cc74=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/10/2026 12:31, Jan Beulich wrote: > On 23=2E10=2E2026 03:12, Tu Dinh wrote: >> The remote completion path of pt_update_irq removes timers from tm_list >> by checking that their addresses match the previous iteration=2E Howeve= r, >> if the guest rearms a timer during the gap between two list iterations, >> the resulting timer object is no longer the same, even if their >> addresses match=2E Removing the timer from the list will then lose the >> armed timer object=2E >> >> Record a generation number in each timer object upon arming, and check >> that the generation number matches before removing it from the list=2E >=20 > Fixes: 0bcbc971feaa ("x86/vpt: add support for level interrupts") >=20 >> Signed-off-by: Tu Dinh >=20 > Reviewed-by: Jan Beulich Thank you very much for the review=2E > preferably with =2E=2E=2E >=20 >> --- a/xen/arch/x86/hvm/vpt=2Ec >> +++ b/xen/arch/x86/hvm/vpt=2Ec >> @@ -318,6 +318,7 @@ int pt_update_irq(struct vcpu *v) >> struct list_head *head =3D &v->arch=2Ehvm=2Etm_list; >> struct periodic_time *pt, *temp, *earliest_pt; >> uint64_t max_lag; >> + uint64_t generation; >=20 > =2E=2E=2E this folded with the earlier line=2E >=20 >> --- a/xen/arch/x86/include/asm/hvm/vpt=2Eh >> +++ b/xen/arch/x86/include/asm/hvm/vpt=2Eh >> @@ -34,6 +34,7 @@ struct periodic_time { >> u8 irq; >> struct vcpu *vcpu; /* vcpu timer interrupt delivers to *= / >> u32 pending_intr_nr; /* pending timer interrupts */ >> + u64 generation; /* distinguish two armings of the same= timer */ >> u64 period; /* frequency in ns */ >> s_time_t scheduled; /* scheduled timer interrupt */ >> u64 last_plt_gtime; /* platform time when last IRQ is inj= ected */ >=20 > Also, no matter that adjacent lines use u, it wants to be uint_t f= or > new fields=2E Otherwise we will never get rid of the remaining u=2E >=20 > I can make these adjustments while committing, no need to send a v2 just= for > that=2E >=20 Yes, please go ahead and make the adjustments=2E > Jan -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates = solutions web: https://vates=2Etech ---=Part.289.d38e611745819b3.1a182558e2c.8ee8a2f71509cc74=--- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 12:41:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 12:41:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463203.1674139 (Exim 4.92) (envelope-from ) id 1xM2xp-0000qp-Gr; Wed, 28 Oct 2026 12:41:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463203.1674139; Wed, 28 Oct 2026 12:41: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 1xM2xp-0000qi-C1; Wed, 28 Oct 2026 12:41:09 +0000 Received: by outflank-mailman (input) for mailman id 1463203; Wed, 28 Oct 2026 12:41:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM2xn-0000qc-TR for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:41:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM2xn-00DlEN-96 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:41:07 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1ed62-2eae-0a2a0a5409dd-0a2a4508c628-4 for ; Wed, 28 Oct 2026 13:41:07 +0100 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1ed63-f659-0a2a45080019-d1558035ddf1-3 for ; Wed, 28 Oct 2026 13:41:07 +0100 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a2084d62cdso7773725e9.1 for ; Wed, 28 Oct 2026 05:41:07 -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-4a97bf5d5besm52740965e9.5.2026.10.28.05.41.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 05:41: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=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=1793191267; x=1793796067; 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=yPiSZXNK+gUHTd8e6Vwjw643CczPPJQV9RIe3O5yMeM=; b=EP86vzXmtqM5oDDyjYhj/o9AP31WtY5kJWJSFvEg2HNn0kvg0cnb04ccxlVLLyBTwy SCTfsf8D1Ix7vX2srf2sF7sNI07dMxQzJvj2110wjGkxljqwwbngKNpkcCXKOcszj5Pd a1vvbLOqOq45G6YbHL7J5vACTfPPif9CVTw5k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793191267; x=1793796067; 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=yPiSZXNK+gUHTd8e6Vwjw643CczPPJQV9RIe3O5yMeM=; b=SDCjQsYFlVeyd1rGakABxGgm1a677BiB567nQ8YdG53qUgQPNnvWcOFOB/PEGskuuJ cVPxI7VLKKXSQ7POqT9/22ydcR4rXd2RRKnkhIEBs6sYP2YWEW3lALD+Qs1QojByxVUt M1zk7eiJuIq3nqSbgC2JTfZ6gu8GkWOIsF1jOMJGTc/5lf1pSbAYBbIy4j2+8TOy+jIy N9hnb5WUA/VzsOXtx6MhAtSslfb30+Fm/SWHVcnhMPz1W2wqzm+BPCQHlAPId6DvcWL8 act9OT+7NdH5iJ7RYLq6LMFJ6i55oCV6i/8XkDz9qfPj5bNX2irB48KJQaoYSphMpyYS tTIQ== X-Gm-Message-State: AFq9FYLK7igKLyeMWIfDUFZtX9RjPD65JLAtbYn0C9tVNkObWTfHeiJe Ev7Bd4UoTcgSb6W8GhIMPQl7qO2LGvhshe8KZ8yhNJil1W10Mq0TQFN8JogX98g8CfyhTBVpaDK gdIc4lvM= X-Gm-Gg: AYBFou1ApPEBAyMTk3ts0qcXtcTQn1bkL62ystvYQptjuj32f4684cMZGaI1fZvTTVF 6K468xsm8qAAzUWUII79TBv82VkQqC+xZkppAegYvgLmysbMR69UXR3VJzSNZF2pT+Nyx5Opqbd g60JTTAdYdn3fHVKR/0manIGZex5GuZ9w0N2EN5oS2TxSX2cbggE0VtEO09z8fFEpClr1/rK2pM /jwZ7Z4ZFiY1LAlsuM7PQk+E/G5k9KJp/E+AdvglqSFxqbsHGdQayVP/JVLAXlvmm08SaAgiyDR zDchkmeEI/qlD1hTs5/kK56gcCaZiq7lEhjV5RXo05uPw1ykQXABdTI+kCBfa01IYdDXFx8oyxD pwYYY0y0iW9J6BxOVDRCfaknlJYKjAdJwiiZHsUBRv+8CNFu+blO6lBe0L4On9JYh1KYrIJ/t64 HQ5ytwBAV4QqtHUQqHB+ZbzR+f0EjPGMTSuIIUASkAWLcGVV4Nt5CXF3+0woaJuWCq0tORVK+Rb M6gD7TVRc0wAFMUpUFMXnJpwfLv/lmQbqe945ba2s/oAoE9wPjXDyrSdOAZQk23H1ZvbnIfEY6i tycuEud0NO2Top+ay7x8TnFD65gbFhFc0YpK+s/VvLloztbyz3yTKkHzXibNULFHJRoMCLLSKKJ 7i1c= X-Received: by 2002:a05:600c:3541:b0:4a1:f68a:9736 with SMTP id 5b1f17b1804b1-4a9672014d4mr49702965e9.26.1793191266440; Wed, 28 Oct 2026 05:41:06 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] xen/mm: Remove loops in get_order_from_{pages,bytes}() Date: Wed, 28 Oct 2026 12:41:04 +0000 Message-Id: <20261028124104.1564435-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-c1860d/1793191267-CC57487B-96DC296C/10/78276251493 X-purgate-type: spam X-purgate-size: 6489 These two functions are just fls() expressions in disguise. Furthermore, GCC-12 at least won't const-propagate get_order_from_pages() with an input of 3 or above, which covers most of the cases it gets used for. Rewrite them, and provide some self testing. Interesting, unless they are always_inline, GCC has a habit of out-of-lining them even when inlining would have been a win. I expect this is to do with the fls() functions being superficially more complex. No functional change. Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beulich CC: Julien Grall CC: Roger Pau Monné CC: Stefano Stabellini https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2999078934 I think paddr_t is the wrong type to be using in get_order_from_bytes(), and so really is fls64(). I could add fls_g() which would be slightly nicer on builds where paddr_t != uint64_t. Bloat-o-meter reports: x86: add/remove: 1/0 grow/shrink: 1/20 up/down: 39/-624 (-585) Function old new delta deallocate_buffer - 37 +37 iommu_flush_iotlb 518 520 +2 amd_iommu_init 648 647 -1 do_memory_op 11052 11050 -2 dom0_construct_pvh 4025 4021 -4 allocate_ring_buffer.constprop 79 73 -6 conring_flush.constprop 267 259 -8 allocate_buffer 131 123 -8 _free_percpu_area 104 96 -8 vcpu_create 865 849 -16 kexec_init 295 279 -16 enable_qinval 447 427 -20 cpu_percpu_callback 238 216 -22 heap_init_late 1683 1659 -24 amd_iommu_alloc_intremap_table 363 331 -32 dom0_construct 8314 8274 -40 alloc_pgtable_maddr 263 217 -46 free_ivrs_mapping_callback 132 82 -50 amd_iommu_setup_device_table 746 680 -66 _xmalloc.part 585 517 -68 enable_iommu 1668 1583 -85 amd_iommu_init_cleanup 551 449 -102 arm64: add/remove: 2/0 grow/shrink: 3/9 up/down: 248/-400 (-152) Function old new delta guest_map_pages - 176 +176 get_allocation_size - 28 +28 allocate_domheap_memory 268 288 +20 do_memory_op 8584 8600 +16 heap_init_late 1048 1052 +4 find_unallocated_memory 452 456 +4 kernel_decompress 772 768 -4 end_boot_allocator 836 832 -4 cpu_percpu_callback 328 324 -4 arch_livepatch_quiesce 212 208 -4 apply_alternatives_all 360 356 -4 conring_flush.constprop 336 328 -8 _xmalloc.part 584 572 -12 construct_hwdom 1088 1024 -64 allocate_bank_memory 444 148 -296 The three introduced functions are all examples of the inlining decisions going wrong. Still, at least all of these examples are now basic blocks rather than loops. --- xen/common/bitops.c | 27 +++++++++++++++++++++++++++ xen/include/xen/mm.h | 18 ++++-------------- 2 files changed, 31 insertions(+), 14 deletions(-) diff --git a/xen/common/bitops.c b/xen/common/bitops.c index 859a4ca5c131..1291cbbf0967 100644 --- a/xen/common/bitops.c +++ b/xen/common/bitops.c @@ -259,3 +259,30 @@ static void __init __constructor test_muldiv64(void) if ( res != 0xffffffffffffffffULL ) panic("muldiv64(), expecting -1ULL, got %#"PRIx64"\n", res); } + +#include + +/* Not really bitops, but here in lieu of any better location */ +static void __init test_order_from_pages(void) +{ + CHECK(get_order_from_pages, 1, 0); + CHECK(get_order_from_pages, 2, 1); + CHECK(get_order_from_pages, 3, 2); + CHECK(get_order_from_pages, 4, 2); + CHECK(get_order_from_pages, 5, 3); + CHECK(get_order_from_pages, 8, 3); + CHECK(get_order_from_pages, 9, 4); +} + +static void __init test_order_from_bytes(void) +{ + CHECK(get_order_from_bytes, PAGE_SIZE - 1, 0); + CHECK(get_order_from_bytes, PAGE_SIZE, 0); + CHECK(get_order_from_bytes, PAGE_SIZE + 1, 1); +} + +static void __init __constructor test_orders(void) +{ + test_order_from_pages(); + test_order_from_bytes(); +} diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 153c57f5ddc2..8f4bba94919b 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -530,26 +530,16 @@ page_list_splice(struct page_list_head *list, struct page_list_head *head) list_for_each_entry_safe_reverse(pos, tmp, head, list) #endif -static inline unsigned int get_order_from_bytes(paddr_t size) +static always_inline unsigned int get_order_from_bytes(paddr_t size) { - unsigned int order; - size = (size - 1) >> PAGE_SHIFT; - for ( order = 0; size; order++ ) - size >>= 1; - return order; + return fls64(size); } -static inline unsigned int get_order_from_pages(unsigned long nr_pages) +static always_inline unsigned int get_order_from_pages(unsigned long nr_pages) { - unsigned int order; - - nr_pages--; - for ( order = 0; nr_pages; order++ ) - nr_pages >>= 1; - - return order; + return flsl(nr_pages - 1); } #ifndef arch_free_heap_page -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 12:42:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 12:42:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463211.1674148 (Exim 4.92) (envelope-from ) id 1xM2z5-0001Ho-PU; Wed, 28 Oct 2026 12:42:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463211.1674148; Wed, 28 Oct 2026 12:42: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 1xM2z5-0001Hh-Lt; Wed, 28 Oct 2026 12:42:27 +0000 Received: by outflank-mailman (input) for mailman id 1463211; Wed, 28 Oct 2026 12:42:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM2z4-0001HZ-FW for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:42:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM2z3-007aDe-Ov for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:42:25 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1eda3-e002-0a2a0a5209dd-0a2a450a85b2-18 for ; Wed, 28 Oct 2026 13:42:25 +0100 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 6ae1edb1-f2d2-0a2a450a0019-d155802cb567-3 for ; Wed, 28 Oct 2026 13:42:25 +0100 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a215e64962so9906115e9.1 for ; Wed, 28 Oct 2026 05:42: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 5b1f17b1804b1-4a96a32eef4sm26077285e9.3.2026.10.28.05.42.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 05: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=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=1793191345; x=1793796145; 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=WriChvNKiJETe4YDI5a0z5UfBiITFyfI8Vbt79WV9g4=; b=HRmSDSn67OrqVqBKFNKgfsjqMKqb88f4tFdRrM+xIaTOQds/iGic3IEnVMU0rvaxK4 H/XJHqqH2be7jruZevk3IM6/nf2PzdJqCVAmH2F7yNAuccS2ZHNilNUhpYDKjUxhJfgZ PVqQ9B8vCnyn/Fb/9nBlVhi+jg2td237klqIY2nzAmygCFz4WRZvSjmzW/8RXFLq85aO PUX4yFfYbpGuXTjY50OhLoTXzrHVUJf8PaqpH03IYfD5bzdPrzDpOuCLHljFSnYT5ziN RnMsuSNhcG1HpNXOjR2zM64hMsxEudILDWo5hfUlTg1pX1QuexrrGFFQdkeBfO3rcCNo 5vCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793191345; x=1793796145; 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=WriChvNKiJETe4YDI5a0z5UfBiITFyfI8Vbt79WV9g4=; b=e5TWcIxcys8WfWol6kHMeSsAn1BjFWaKqBzhiqT4xFNp1TUFJ/KF6HwZqef2pxAhW6 I2JuxGqC0XRa/ab21v/m0eqRvJYdKi0Qu0N2H5tjI3zdSsD9PSDk7o0NdN592FGjscLZ 5lYV4EzspOWuf+6fXnqQ/vGinh2wYofsnCCx6L/T+/ImgQ5+SyFcMzt55h+2C58y5KH0 gSBG9bpOwk1G70shRMIrb6HIPYZqhnAuRM4Iiz5k6BI4SIObOtpfbDegL+Ls62OkI0MW /UuNVUqw4PY9qHcRGCgR0CQ0V+Dm6Pv/kU6JcaHQRPNsf5PFopc4UAdCwHjY0LrgM39n 2l1A== X-Forwarded-Encrypted: i=1; AKwUvBxcs4mikaADOapLictAow2rJ9BKsxewoKSDpEE0rMfJgbY8XBioI3Gw9u/xLZ7L03NluRzQobrnr8c=@lists.xenproject.org X-Gm-Message-State: AFq9FYKTdaRneqXrymnlVJCFTZB7iIJPVeAcld/XGodncRxLbEi4bll2 H4ObIVLNFhCXRqk6i9RXnwB9GsecCdS83ezLhtU32HBBSaHdHgH/JLtt/kH/5PURnw== X-Gm-Gg: AYBFou3BV/9fWEouVaRJbqRjuqxFj5sA+0T/Qe6tCPeyx/yeWQloYxm/8NHzM+O39oh T5TPl+6V2Jukfe8krnlZQm62TFFNe6e5rPbrP/b4THIeQq7jW258maHBVS2xfWaom9Yq6DLIhGe VJFLpUbkLmIkkiCU+VmMy3HLh9avqO1oEuHfudYMNpwA4GgDbn5SlgUVjmm8YLo5V5VzZvjr0Fz pHpFucThVxLYiZ3Kjg/VX76CyYNzl1RN1ut5rGkvFuiwxOKFHGyeWAsqkTa+bO+pkJh828MPZqF UOFmYP6VND5kxqHw902JzmAAMQcE/1cf0G8e+mMQab3r5wo/jfEncoic5RYAe8P5p2zqOP5EkCj 5NG+rIExyEO0N+QL0541zA5UCUEhgDTaP+QrB5dQ+HEKvXGWAUL3ZTj4vBeawvz48Lk7x9O2AzL Bm/6TEFH21GDcRG1qxoM5kj88fQ4R+mwPbNjsY19VPcW8S9RxF6yoZXmaaSAmpKSDZYwpNvym6e 1u+2AU9cPvKEgUgKSk+7iZDDbaXnI/NSPKmi7XxE87VODlRuTWV+DBchcoq14V4hdM8jHABWHM5 Q8u0JKQHXWH6PzU3hHLJPHyXqR9vBLFMbVRU/wKtXFrisTVZbVxkeAZjFSsMvVjZCa3VTIIISk1 n2lD6LWd2GXcFjAKJ X-Received: by 2002:a05:600c:3e0b:b0:4a6:42cc:bf7b with SMTP id 5b1f17b1804b1-4a963ffcf7bmr49383175e9.3.1793191345092; Wed, 28 Oct 2026 05:42:25 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 13:42:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/5] vpci: allow queueing of mapping operations To: Mykyta Poturai Cc: Stewart Hildebrand , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <14cc4abdcf4c3c3d9a620cf4df3ec87e7b11bd13.1792072426.git.mykyta_poturai@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: <14cc4abdcf4c3c3d9a620cf4df3ec87e7b11bd13.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793191345-516C6CFC-29376209/10/78276251493 X-purgate-type: spam X-purgate-size: 2200 On 15.10.2026 16:08, Mykyta Poturai wrote: > --- a/xen/drivers/vpci/vpci.c > +++ b/xen/drivers/vpci/vpci.c > @@ -24,6 +24,11 @@ > > #ifdef __XEN__ > > +void vpci_vcpu_init(struct vcpu *v) > +{ > + INIT_LIST_HEAD(&v->vpci.task_queue); > +} If there's more that's going to be added to this function, having it out-of- line is fine. If it stays like that, it can be inline (and then there won't be a need for a separate stub). > --- a/xen/include/xen/vpci.h > +++ b/xen/include/xen/vpci.h > @@ -19,6 +19,8 @@ > */ > #define VPCI_MAX_VIRT_DEV (PCI_SLOT(~0) + 1) > > +void vpci_vcpu_init(struct vcpu *v); > + > /* Assign vPCI to device by adding handlers. */ > int __must_check vpci_assign_device(struct pci_dev *pdev); > > @@ -54,7 +56,6 @@ struct vpci { > uint64_t guest_addr; > uint64_t size; > uint64_t resizable_sizes; > - struct rangeset *mem; > enum { > VPCI_BAR_EMPTY, > VPCI_BAR_IO, > @@ -152,14 +153,24 @@ struct vpci { > #endif > }; > > -struct vpci_vcpu { > +#ifdef __XEN__ > +struct vpci_map_task { > /* Per-vcpu structure to store state while {un}mapping of PCI BARs. */ > - const struct pci_dev *pdev; > + struct list_head next; > + struct vpci_bar_map { > + uint64_t addr; > + uint64_t guest_addr; > + struct rangeset *mem; > + } bars[ARRAY_SIZE(((struct vpci_header *)NULL)->bars)]; > uint16_t cmd; > bool rom_only : 1; > + const struct pci_dev *pdev; > +}; As this struct isn't used anywhere in the header itself, it can likely move to vPCI's private.h. Jan > +struct vpci_vcpu { > + struct list_head task_queue; > }; > > -#ifdef __XEN__ > void vpci_dump_msi(void); > > /* Arch-specific vPCI MSI helpers. */ > @@ -204,6 +215,8 @@ bool vpci_ecam_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int len, > #else /* !CONFIG_HAS_VPCI */ > struct vpci_vcpu {}; > > +static inline void vpci_vcpu_init(struct vcpu *v) { } > + > static inline int vpci_reinit_ext_capabilities(struct pci_dev *pdev) > { > return 0; From xen-devel-bounces@lists.xenproject.org Wed Oct 28 12:46:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 12:46:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463222.1674157 (Exim 4.92) (envelope-from ) id 1xM330-0001rW-7C; Wed, 28 Oct 2026 12:46:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463222.1674157; Wed, 28 Oct 2026 12:46: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 1xM330-0001rP-2d; Wed, 28 Oct 2026 12:46:30 +0000 Received: by outflank-mailman (input) for mailman id 1463222; Wed, 28 Oct 2026 12:46:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM32y-0001rC-Qf for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:46:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM32y-002HXl-7Q for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:46:28 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1ee98-2eae-0a2a0a5409dd-0a2a4507bcba-40 for ; Wed, 28 Oct 2026 13:46:28 +0100 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 6ae1eea3-b4ea-0a2a45070019-b9ff1c22942d-3 for ; Wed, 28 Oct 2026 13:46:28 +0100 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 1a1828c1ad0000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 12:46:22 +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 6053A82A1D; Wed, 28 Oct 2026 13:46:21 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=uQYdS+wl92dLu7h0PgVq9ER68frsYKqeVfd++TYZlMQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=evVGXFAUtrKHhl75AchDEfQcyFfh9py45SB5yE5cfUfP1P8jWAZTwFUZdWstBgD5d3q9uGqbV jLvd/CJBTKRWFuFE6tM21w9sKM4vE12NJhORuGGIwXKVjqPf6r4alrlL0/H726A9OHfTvWaujgj kXWsjylLi+ZP/J9AYfk8fo9RsWt2XR5K95JTzuV/e+4TiCEcViyCu8c3WrILN6UNyHiGfTKzQTP GSPpbCPUyEZx8qlmAOwrThnmqMCmEcxptZrNripXmNCPlL3T9KvyvzhUIy3k6s1v7ooxBm0FiCF OmTiWy71B/k2nyVzTO6MIsutsGDQNIOAkA+xnEfa2elw== X-Zone-Loop: f9ba8675f7d91f378eaea4d62cd6a9350876072ac0fe x-campaign-type: default x-transaction-id: af5bbb2f-aa34-4102-a2d8-c63f6e335794 x-swg-uid: 01-028a2fb4-d9dd-48ba-8d49-732d38aef76a X-Mailer: Sweego Message-ID: <1793191582.8631fc262581453bbf619ec5b2062170.1a1828c1ad0000f79f@vates.tech> x-swg-bid: 1793191582.8631fc262581453bbf619ec5b2062170.1a1828c1ad0000f79f 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 v9 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang In-Reply-To: References: <1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f@vates.tech> <1793099133.8631fc262581453bbf619ec5b2062170.1a17d0971ae000f79f@vates.tech> Date: Wed, 28 Oct 2026 13:46:15 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793191576; l=3162; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=dt1OUdXTQV986f0VUbf+dyOok6fM6kLQNWmEbO6EVxM=; b=H8wW01r/TXKit075aXnFAZPLKBKwT7FjoXDd4q2fZW7QRTeTZMrAOsk4A6rysp2kKMOjN8Qci Wi6oTQP2yDBDBoYWOQxmHxZR6Sxb8IZr6d5OPoKvYT99ssIHpp7HBfm 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: 1793191581594 X-purgate-ID: tlsNG-ef75cf/1793191588-A4ECEAE4-07DA89EA/10/73395122804 X-purgate-type: spam X-purgate-size: 3162 On 2026-10-28 10:25:53+01:00, Oleksii Kurochko wrote: > [ ... 27 lines skipped ... ] > fixmap.h asks for xen_fixmap[] to be accessed directly only when > set_fixmap() is unusable. It is unusable here, as pt_update_entry() > always sets A and D, but I think the comment should say so. Otherwise > someone may "clean this up" by switching to set_fixmap(), after which > the probe silently always reports Svadu, and on a Svade platform G-stage > PTEs are then created with A/D clear. > > The current comment also reads as if the page had to be mapped already, > while what makes using the Xen image correct is that A and D belong to > the PTE, not to the page, so those set in the Xen image mapping don't > matter. Something like: > > /* > * set_fixmap() can't be used, as pt_update_entry() always sets A > and D. > * > * A and D belong to the PTE, not to the page, so a new PTE with A > and D > * clear can point to any RAM page, whatever its other mappings. > Use the > * first page of the Xen image, and map it read-only so that Xen > can't be > * corrupted through this alias. > */ > > > I am okay to go with how the comment is written now and apply my > suggestion only in the case if v10 will be needed (and likely it will > look at the comment about fence below) I will use that in v10 thanks. > [ ... 11 lines skipped ... ] > > + a_set = read_pte(entry).pte & PTE_ACCESSED; > > I think a fence is needed between the load and reading the PTE back. The > spec only orders the A bit update against accesses to the same virtual > page: > > "Furthermore, the PTE update must appear in the global memory order no > later than the explicit memory access, or any subsequent explicit > memory access to that virtual page by the local hart." > > read_pte() accesses a different virtual page, and RVWMO doesn't order > two loads to different addresses, so on a hart which updates A/D in > hardware read_pte() may still observe A clear. That fails safe (Svade > gets recorded and A/D are preset), but the message below then asks to > add the wrong extension to the DT, and an out-of-order core like the > P550 is exactly where this could happen. Ordering the load before the > PTE read is enough, as the A bit update is in turn ordered before the load: > > /* Order the load, hence its A bit update, before reading the PTE. */ > RISCV_FENCE(r, r); Good catch thanks, will apply that in v10. > [ ... 12 lines skipped ... ] > [...] > > I gave it a try on QEMU 9.0 on top of current staging (virt with > aia=aplic-imsic, all with svpbmt=on): > - default (svadu): the probe doesn't run; > - svadu=off (hardware updating, neither in the DT): "probed svadu"; > - svadu=off,svade=on with "_svade" dropped from riscv,isa: the load > faults, the extable fixup works, "probed svade"; > - svadu=off,svade=on: the probe doesn't run. > All of them reach "All set up" so: > Tested-by: Oleksii Kurochko Thanks for having tested. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 28 12:49:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 12:49:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463232.1674165 (Exim 4.92) (envelope-from ) id 1xM36L-0002gp-JS; Wed, 28 Oct 2026 12:49:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463232.1674165; Wed, 28 Oct 2026 12: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 1xM36L-0002gi-GU; Wed, 28 Oct 2026 12:49:57 +0000 Received: by outflank-mailman (input) for mailman id 1463232; Wed, 28 Oct 2026 12:49:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM36K-0002gD-8s for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 12:49:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM36J-00B6ik-Lj for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:49:55 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1ef65-e002-0a2a0a5209dd-0a2a450ae90c-42 for ; Wed, 28 Oct 2026 13:49:55 +0100 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1ef73-f2d2-0a2a450a0019-d155802bb1ee-3 for ; Wed, 28 Oct 2026 13:49:55 +0100 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a2153c8525so6842205e9.3 for ; Wed, 28 Oct 2026 05:49: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-4a9783b7e87sm42590565e9.6.2026.10.28.05.49.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 05: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=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=1793191795; x=1793796595; 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=W2LjrcxFV881MsZIlhbIBf+zSxIyMw0XCJCfBIWxan4=; b=Kn3Ym+aa57C69ZSn2GBLuPFQggSK+EjCjlMOnpBWA165Gqjo0QxWVnzo7ovYE3qMwk Hm9W6TEFYCOKnMmodcI8MPoc3sZF+Z6FF5AWlRU/Hl2ro8dex4yPB/mHD1kTwolFB37S ihhD7vtGr6jiC/Tj9PokT0b/4n9Uy8Kg52m3me1ph3HRTALluBn07vmhAmXMVegBIdAI TGs5Q77InRupH9D77mBgd+9TxySHvoPtzRD36J/yZlRhpU0hm1yO6OHaS2VQvxllb/GQ bEDqnwCfXkhT1ZvehN675vrlpLurSFvsxiZrklc6yzzhnTfT9fDMR5Ji3F7RUI9lKsq2 CY1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793191795; x=1793796595; 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=W2LjrcxFV881MsZIlhbIBf+zSxIyMw0XCJCfBIWxan4=; b=OOrGyaaUusPmo9AABW1Uja0ExavQee7FnBw3JozwlOMKgopS8tLdhhGLURXgyHBMFq MsXV6g/n++YlFlfqQ23e6+i51SS3UbS0iPC0v/OZKSy13P01onqlDl/KDuEipNWkWON5 DGPQqQ5sTAXfRQqixIdW/QxBUr824FmROHh8PogIS8Byqnb/6iqrFC09PnF+PHN93nBo 9PoKnbECAoyhG7aStT9mUq5CCf/x7Iwqo9FT8WU3Q45SLXFFy76bj0fU8MH6nbdgkEFG H5XyrPBpCye6Rwq/IjUWhotgrY0dshGFWxAat92KEfemv9+LjrXTXEcryyv8gLnJQ8cl osiA== X-Forwarded-Encrypted: i=1; AKwUvBzTACo2SQwyIJa/O3H/LpJ8K/XJvsOB4tJh51+aui7KXvGRgISFxsqd9hxLq6kY8NiybavqLiqfbOI=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ99MGK03ErPqWfCSvY+pq8e6+6mwo3DmpggyjjOwGVDVBoVLhE 2fVpOS75jRQFcArnb2t1KdFQmfKCvkN9N+sBblIAMwck5W/YH5IKxCR2e0wIMNzvyw== X-Gm-Gg: AYBFou2hHleOPx8TQwSOMbzyAVx0rbB/6NrbmyT859SFaHnDB7qJ9B/Qsu2dc7X13rI dECFUsMtvnLOjYwWt45OTOijAgxJKQy0DBjPLNfdXnpaLOkxSYipQkoETZY9EFWAVnjfBazePNM 29CNwAHRs4s5UQLNRberFX2U+Id+5DYDb1QMYl1nm0B/KphESVs3/Srcoq55vO+skIDkIIBRAk8 lFgvnO6kyZePFSs2ut1OaQRSqDFz3+YZP0RBnBimeC+L2tWxZuqeWlXELrgB/U6ecyUU286kkqk qonZJIE+0xvA2HiS92nCMgvwXDLnbiZ3OiLWTVJVwdq8Iw0IohyqrdVuHddct/yGKZrv7FHbyiG C46SGBwgEriobvSpqnMKTYr085gz2VbXfxnfPiA5LMjkg1Iqvemr7O4ybDpi5pblhlMsNOOiMnJ +USrHOYEn56r5wD73HIp97nQHyWAIBMXaRWfQN1zgQHBGFRmFH9AEndhFLnuJlJfAP5hTt5zSSN po5L+qf+WXWijN+11EGbBN77Ldx6cYVm28nEJkNGjJ9hJCeoVTA/Sf1VHFcenBXZxRhqJ3OksO9 j5GRIq+cHQ/8ArkhNTM2jn4+4lCqleAu7CtYBaYipwL57Olha8Asg6z2trd2PmQu4xDPeQCpIKJ +jOkGzzAwEl+8KHK3dA== X-Received: by 2002:a05:600c:3510:b0:4a9:18f4:925e with SMTP id 5b1f17b1804b1-4a966774dc4mr47605265e9.18.1793191794975; Wed, 28 Oct 2026 05:49:54 -0700 (PDT) Message-ID: <63d6c5ed-ea90-4a54-8930-76767983ceb8@suse.com> Date: Wed, 28 Oct 2026 13:49:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0 To: Jason Andryuk , Mykyta Poturai Cc: Stewart Hildebrand , Oleksii Kurochko , Community Manager , 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: <103b10d012cc291906025045a2da1ce728f0bffd.1792072426.git.mykyta_poturai@epam.com> <25df5d8d-7cd3-4344-86e1-8af883fa9a65@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: <25df5d8d-7cd3-4344-86e1-8af883fa9a65@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793191795-4B2D8CFC-215EDAA6/10/78276251493 X-purgate-type: spam X-purgate-size: 1689 On 19.10.2026 23:47, Jason Andryuk wrote: > On 2026-10-15 10:08, Mykyta Poturai wrote: >> --- a/xen/drivers/vpci/vpci.c >> +++ b/xen/drivers/vpci/vpci.c > >> @@ -486,6 +487,11 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size) >> return data; >> } >> >> + /* Ahead of any lock being taken, as adding a device acquires them. */ >> + if ( unlikely(is_hardware_domain(d) && pci_vf_setup_pending(sbdf)) && > > unlikely() here breaks the tests build. Add > #define unlikely > to tools/tests/vpci/emul.h Or better omit unlikely() here. It's not used properly anyway: Unless it's known that the compiler will translate an && expression to a single branch, each part of && (or || ) wants wrapping, not the entire expression. >> --- a/xen/include/xen/vpci.h >> +++ b/xen/include/xen/vpci.h > >> @@ -145,6 +145,22 @@ struct vpci { >> unsigned int nbars:3; >> } rebar; >> >> + struct vpci_sriov { >> + /* PF only */ >> + struct vpci_bar vf_bars[PCI_SRIOV_NUM_BARS]; >> + /* >> + * When the VFs which are enabled but not added to Xen yet are >> + * guaranteed to respond to config space accesses. Zero if there are >> + * none. >> + */ >> + s_time_t vfs_ready; >> + /* Routing ID offset of the first VF, and stride between VFs. */ >> + uint16_t offset; >> + uint16_t stride; >> + uint16_t num_vfs; >> + unsigned int pos; > > unsigned int before uint16_t packs the structure a little better. As per ./CODING_STYLE, the use of uint16_t may not be justified here anyway. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 13:04:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 13:04:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463247.1674175 (Exim 4.92) (envelope-from ) id 1xM3Kh-00060v-Ss; Wed, 28 Oct 2026 13:04:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463247.1674175; Wed, 28 Oct 2026 13:04: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 1xM3Kh-00060o-Pa; Wed, 28 Oct 2026 13:04:47 +0000 Received: by outflank-mailman (input) for mailman id 1463247; Wed, 28 Oct 2026 13:04:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM3Kf-00060c-TG for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:04:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM3Kf-0063h3-5O for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:04:45 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1f2e2-e002-0a2a0a5209dd-0a2a4509a4e4-34 for ; Wed, 28 Oct 2026 14:04:45 +0100 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 6ae1f2ec-be1a-0a2a45090019-b9ff1c229a25-3 for ; Wed, 28 Oct 2026 14:04:45 +0100 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 1a1829cd6d5000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 13:04:39 +0000 Received: from leducb.home (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 2FF4582DF6; Wed, 28 Oct 2026 14:04:38 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=LHo4TE2lxp+M/2zYe+oNb3uRGp5/UK9/xamLNVPs5EQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=APbImo/LX9PJ7ydZja1Euegb2KeSpDz8ALmqfpXVvofv0CE+ZjPHcAtufgfYseN6PFGT/gHpx ajuK2rW+vNAwjprSRlkFBF8z9cbFV49hFlcZGKUeVqvcIEseHC3vtXnNspzqfRevxhVxSGv87tC h8huaPv9s1SbBH5V/an76K5KpnIW3Tx81K9nq8/uYgWFEkCXmRB+qibZ2lwoa0F4JjuZA+4zUHq xMkDcfgRVCdGrX5Qku2A6nJT5y/oqG2ODGX6n0C5bs2XgXjTiWl88jE5ugxDoBqMbPLAg0rznd1 jK7O3Pb35f0bJfEJExXEGRMhqhXIR5FSksR4Sz6711Fw== X-Zone-Loop: a3cbd028b7a9059f4769c9a31210074228bda5670003 x-campaign-type: default x-transaction-id: d3ebc1e4-4f27-4eed-8896-d4d19c4f00b0 x-swg-uid: 01-023a1d9b-c89b-4b2a-9eea-b83fd9ec7bb2 X-Mailer: Sweego Message-ID: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> x-swg-bid: 1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v10 0/1] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Wed, 28 Oct 2026 14:04:33 +0100 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=1793192635; l=6183; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ueCo5HhT7TFqhAx+p27ZJ7B+Wp6amaxCTTNxIxOFf6w=; b=g2B0ftHtJz9VKScHqkofmrrg3VfWetwWm+EeSiKvekXgVqXwkkwthWZrpec3xP0UmoU1KHV2o YIEnGThqzsOBN5jPfqjlm95VnRplxG7N2tBQGyJ0VG61y0goq579TyE 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: 1793192678394 X-purgate-ID: tlsNG-bad1c0/1793192685-3B6D2034-AA19CA56/0/0 X-purgate-type: clean X-purgate-size: 6185 This series introduces bug 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: Probe the A/D update scheme if the DT advertises neither Svade nor Svadu Test CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2999261409 --- Changes since v9: - Add a fence between the probe load and reading the PTE back, as nothing else orders the A bit update before the read. - Explain why set_fixmap() can't be used and why any RAM page can be aliased. - Link to v9: https://patch.msgid.link/1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f@vates.tech --- Changes since v8: - Drop patches merged upstream: 999c2ca1ab ("xen/riscv: use pte_is_valid() in pte_is_mapping()") 8e34f567ef ("xen/riscv: fix A/D bits in Xen's page-table mappings") 73b802624a ("xen/riscv: look up the exception table for any trap taken in Xen context") 8a9a4bcd7c ("xen/riscv: rework the A/D bits comment in p2m_set_pte_flags()") - Probe through a read-only alias of the Xen image and check the A bit, as A being set by a speculative access still implies Svadu. - Link to v8: https://patch.msgid.link/1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech --- Changes since v7: - Replace the panic when the DTS advertises neither Svade nor Svadu with a probe of the A/D update scheme in that case only, recording the probed extension so that such device trees can be used as-is. The device tree is trusted otherwise, as discussed with Jan (patch 4). - Add patch 3, so that the store page fault raised by the probe on Svade hardware is fixed up. - Move the p2m_set_pte_flags() comment rework last (patch 5). - Collect trailers: A-by on patches 1 and 2, T-by on patch 2 and R-by on patch 5. - Link to v7: https://patch.msgid.link/1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech --- Changes since v6: - Drop the boot time probe of the A/D update scheme and trust the device tree. Xen now panics when the DTS advertises neither Svade nor Svadu (patch 3). - Patch 4 no longer changes when A/D are preset, it only reworks the comment, since patch 3 guarantees the DTS advertises the scheme in effect. - Reorder the series so the already reviewed patches come first. - Patch 2: add a second Fixes tag for arch_pmap_map(). - Patch 1: rebase, as the reorder changed its context. - Link to v6: https://patch.msgid.link/1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech --- Changes since v5: - Replace "xen/riscv: always preset A/D bits in G-stage PTEs" with a boot time probe of the A/D update scheme (patch 1). It checks the result against the Svade/Svadu DT binding and records the probed scheme when the DT advertises neither, instead of trusting the DT alone. - Split the p2m_set_pte_flags() comment rework out into its own patch (patch 2). - Patches 3 and 4 unchanged and are waiting to be merged. - Link to v5: https://patch.msgid.link/1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech --- Changes since v4: - Drop patches merged upstream: ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"") - Collect trailers. - Rebase patches on top of staging. - Link to v4: https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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 --- Baptiste Le Duc (1): xen/riscv: probe the A/D update scheme if the DT advertises neither xen/arch/riscv/cpufeature.c | 71 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 +++--- 2 files changed, 78 insertions(+), 6 deletions(-) --- base-commit: b07838dc463c18f9ca78806d0f05164b02d1cd14 change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 28 13:06:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 13:06:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463254.1674184 (Exim 4.92) (envelope-from ) id 1xM3Lt-0006SB-5x; Wed, 28 Oct 2026 13:06:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463254.1674184; Wed, 28 Oct 2026 13:06: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 1xM3Lt-0006S4-2L; Wed, 28 Oct 2026 13:06:01 +0000 Received: by outflank-mailman (input) for mailman id 1463254; Wed, 28 Oct 2026 13:06:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM3Ls-0006Rt-0z for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:06:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM3Lr-002MDP-DN for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:05:59 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1f32f-e002-0a2a0a5209dd-0a2a450cc3da-44 for ; Wed, 28 Oct 2026 14:05:59 +0100 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 6ae1f336-f479-0a2a450c0019-b9ff1c23aa29-3 for ; Wed, 28 Oct 2026 14:05:59 +0100 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 1a1829e0a63000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 13:05:57 +0000 Received: from leducb.home (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 EF7B882407; Wed, 28 Oct 2026 14:05:56 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=E4YfQ7ziCTZbtcfhIYdbQdYxXRsuw8UiYN0tQwzOUtM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ONNAUmWlZ3MV3gj+RvivFarO6OVzzqvuvq14O54t707eTf3uOZjl/+w+9EfPaj5huR0wn3VSM sMkBSJ41qNmhMc3D0abD3ovROTpsWjo5q7ZEeMHMGE+ppLJM6yuI7gICGvNKNizsQ1cg5yrxWHJ vcyy6gNwZrud9oP/MniHeqW+/9SSs6p8O6q1sEauNZQYFpNRIgBfp/7fr8bCjxJ++yE6TDWiYpf VL7nUHKDaXCFAvpeV/kFARk/gEiJoXRidsEidrQN8OZ1KqmxPBSXsN2EBtnOeFvQ+oIIegIYd7u Vv7jRtaOMWTHpSBIoli7o4qzQ6arHfc+M0v/IrMPb8aQ== X-Zone-Loop: 74c8442cb198d6de71ff17b067e4551ca22eaf6c4ea1 x-campaign-type: default x-transaction-id: ab4d898b-99a6-4ca4-8677-2825e04a5fdd x-swg-uid: 01-cb878f4a-f837-444e-afd7-b619558cec08 X-Mailer: Sweego Message-ID: <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> x-swg-bid: 1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither Date: Wed, 28 Oct 2026 14:05:54 +0100 In-Reply-To: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> References: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793192636; l=8074; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=S9p7lOZi+BIvxBPdus9xQlQ14bcOjaCu8UmqD+n7aZU=; b=CZbH+kMsRwDPHLzon40W9wC1SyqAp8fpvNohwbtYh1s7JXhgtqamtFJmrXviqJgo9Ik+rc2Mk 8Dvn2FZIcXwBUbzloio9qX/efCoBMN6A3LphPlEhWWb04R1C2y2Sztn 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: 1793192757180 X-purgate-ID: tlsNG-d25034/1793192759-52132A5B-B73EDBE9/0/0 X-purgate-type: clean X-purgate-size: 8076 p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. The privileged spec allows exactly two schemes for updating the PTE A and D bits: hardware sets them on access and on write, or accessing a page whose A and/or D bit is clear raises a page fault so that software can set them (ratified as Svade). Every implementation uses one of them, but platforms designed before Svade and Svadu were ratified, such as the HiFive Premier P550, may advertise neither. Trust the device tree when it advertises Svade and/or Svadu, as for any other extension. When it advertises neither, probe the scheme in effect and record the matching extension in riscv_isa, so that such device trees can be used as-is, and warn naming the extension to add to "riscv,isa". Introduce probe_hw_ad_update(): alias the first page of the Xen image read-only through the FIX_MISC fixmap slot with its A and D bits clear, then load from it under an exception table fixup. Hardware updating is in effect if the load completes and the A bit is then set. The probe fails otherwise, whether the load faults or completes leaving the A bit clear. The A bit being set by a speculative access still implies Svadu, as Svade only allows A to be set by software. Add Svadu to the known ISA extensions so it can be told apart from Svade. The comment above the enum asks for new extensions to go at the bottom to avoid shuffling, a leftover from Linux where the IDs were macros with explicit values. Nothing depends on the enum values, so have the comment say that multi-letter extensions follow the order of riscv_isa_ext[]. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc --- Changes since v9: - add a fence between the load and reading the PTE back, as nothing else orders the A bit update before the read. - explain why set_fixmap() can't be used and why any RAM page can be aliased. --- Changes since v8: - probe through a read-only alias of the Xen image and check the A bit, as A being set by a speculative access still implies Svadu. --- Changes since v7: - probe the A/D update scheme when the device tree advertises neither Svade nor Svadu and record the probed extension, instead of panicking. - drop Suggested-by. - update the patch's title/body accordingly. --- Changes since v6: - drop the probe and trust the device tree, only panic when it advertises neither Svade nor Svadu. - update the patch's title/body accordingly. - put svadu between svade and svpbmt in riscv_isa_ext_id. - rewrite the enum riscv_isa_ext_id comment. --- Changes since v5: - new patch, probe the A/D bits update scheme instead of trusting the device tree alone. --- xen/arch/riscv/cpufeature.c | 71 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 +++--- 2 files changed, 78 insertions(+), 6 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 3d5bbd2228..83d3bc5ddc 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -20,6 +20,7 @@ #include #include +#include #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -200,6 +201,7 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { RISCV_ISA_EXT_ENTRY(ssaia, ANY), RISCV_ISA_EXT_ENTRY(sstc, NONE), RISCV_ISA_EXT_ENTRY(svade, NONE), + RISCV_ISA_EXT_ENTRY(svadu, NONE), RISCV_ISA_EXT_ENTRY(svpbmt, NONE), }; @@ -630,6 +632,53 @@ const char *get_guest_isa_str(void) return guest_isa_str; } +/* + * Probe whether hardware updates the PTE A/D bits by reading through an alias + * mapping whose A and D bits are clear. Observing A set, even by a speculative + * access, implies Svadu, as Svade only allows A to be set by software. + * + * Under Svade, the read raises a page fault instead, so use the extable to + * handle it. + */ +static bool __init probe_hw_ad_update(void) +{ + vaddr_t va = FIXMAP_ADDR(FIX_MISC); + pte_t *entry = &xen_fixmap[FIX_MISC]; + bool a_set = false; + + ASSERT(!pte_is_valid(*entry)); + + /* + * set_fixmap() can't be used, as pt_update_entry() always sets A and D. + * + * A and D belong to the PTE, not to the page, so a new PTE with A and D + * clear can point to any RAM page, whatever its other mappings. Use the + * first page of the Xen image, and map it read-only so that Xen can't be + * corrupted through this alias. + */ + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(_start)), + PTE_VALID | PTE_READABLE)); + flush_tlb_one_local(va); + + asm_inline goto ( + "1: lw zero, 0(%[va])\n" + ASM_EXTABLE(1b, %l[out]) + : + : [va] "r" (va) + : "memory" + : out ); + + /* Order the load, and so its A bit update, before reading the PTE */ + RISCV_FENCE(r, r); + a_set = read_pte(entry).pte & PTE_ACCESSED; + + out: + write_pte(entry, (pte_t){}); + flush_tlb_one_local(va); + + return a_set; +} + void __init riscv_fill_hwcap(void) { unsigned int i; @@ -674,6 +723,28 @@ void __init riscv_fill_hwcap(void) "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " "wire up this platform's pause equivalent in cpu_relax()\n"); + /* + * The privileged spec allows exactly two schemes for updating the PTE A + * and D bits: + * 1) hardware sets them on access and on write; + * 2) accessing a page whose A and/or D bit is clear raises a page fault, + * so that software can set them (ratified as Svade). + * + * Every implementation uses one of them, but may predate the extensions + * and advertise neither. In that case, trust the hardware probe. + */ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) + { + bool hw_update = probe_hw_ad_update(); + + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, + riscv_isa); + printk(XENLOG_WARNING + "Device tree advertises neither Svade nor Svadu, probed %s: add it to \"riscv,isa\"\n", + hw_update ? "svadu" : "svade"); + } + 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 2973eb13a5..b0a23be18e 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -8,13 +8,13 @@ #include /* - * These macros represent the logical IDs of each multi-letter RISC-V ISA - * extension and are used in the ISA bitmap. The logical IDs start from - * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single - * letter extensions and are used in enum riscv_isa_ext_id. + * Logical IDs of RISC-V ISA extensions, used as bit positions in the ISA + * bitmap. * - * New extensions should just be added to the bottom, rather than added - * alphabetically, in order to avoid unnecessary shuffling. + * Single-letter extensions use IDs below RISCV_ISA_EXT_BASE and are sorted + * alphabetically. Multi-letter extensions start from RISCV_ISA_EXT_BASE and + * follow the same order as riscv_isa_ext[] (see the ordering rules described + * above it). */ #define RISCV_ISA_EXT_BASE 26 @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_ssaia, RISCV_ISA_EXT_sstc, RISCV_ISA_EXT_svade, + RISCV_ISA_EXT_svadu, RISCV_ISA_EXT_svpbmt, RISCV_ISA_EXT_MAX }; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 13:36:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 13:36:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463284.1674193 (Exim 4.92) (envelope-from ) id 1xM3pd-0003Ak-GG; Wed, 28 Oct 2026 13:36:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463284.1674193; Wed, 28 Oct 2026 13:36: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 1xM3pd-0003Ad-CK; Wed, 28 Oct 2026 13:36:45 +0000 Received: by outflank-mailman (input) for mailman id 1463284; Wed, 28 Oct 2026 13:36:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM3pb-0003AX-Ls for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:36:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM3pa-007nDA-Ri for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:36:42 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1fa68-8faa-0a2a0a5109dd-0a2a4503ac1e-4 for ; Wed, 28 Oct 2026 14:36:42 +0100 Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1fa68-fae8-0a2a45030019-94a39c01269a-3 for ; Wed, 28 Oct 2026 14:36:42 +0100 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 69SBicNF3707362; Wed, 28 Oct 2026 13:36:34 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 4hgmbt4xy0-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 28 Oct 2026 13:36:33 +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 69SBntHS1441982; Wed, 28 Oct 2026 13:36:32 GMT Received: from smtprelay01.wdc07v.mail.ibm.com ([172.16.1.68]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4hjtnnd6kk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2026 13:36:32 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (smtpav06.wdc07v.mail.ibm.com [10.39.53.233]) by smtprelay01.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 69SDaVcv27328908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Oct 2026 13:36:31 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 408995804E; Wed, 28 Oct 2026 13:36:31 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 99FC85803F; Wed, 28 Oct 2026 13:36:27 +0000 (GMT) Received: from [9.61.109.57] (unknown [9.61.109.57]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTP; Wed, 28 Oct 2026 13:36:27 +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=8xiZ5G vKgQdn/F8VRi4kLATkdX1h8i+f6RST97TwmDc=; b=UKFia3q2kGmE+ATZN0mTma td5E2L/0/o7tjjllj/Y2GGwfbgRfOk0X47E1jLTN1fSbRN99oOVSZRDF/aPuXaOq dbt5W3FoOcZ/LNQJQt8eHGu9N8EMnierznnSZsngzL4VuDpdVYItr9NNh13zMO9l 35atG8DhlLDk4NrG+cd15m0XbwY+NCiXUSzQUA0vIP086mTKk/d3SzCguaAcEKum WCR7RpXN3+YUQwMsvjhOhdIKXmZhH4q2Wla2dl5RiWGxBmHVtCNOO8aY+fncam+o ap1+I6GlnKF2BtPdZnMOB1ObMaNdTKcBtpAb5pPApPyADVDxzB2ar/BG5Pz0n1LQ == Message-ID: Date: Wed, 28 Oct 2026 09:36:26 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/11] hw/s390x: mark 's390x-ccw-virtio' as a secure machine To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org Cc: Stefano Stabellini , "Michael S. Tsirkin" , David Hildenbrand , Anthony PERARD , Peter Maydell , qemu-riscv@nongnu.org, Paolo Bonzini , Alistair Francis , Weiwei Li , Richard Henderson , Nicholas Piggin , "Edgar E. Iglesias" , Jiaxun Yang , Chao Liu , Harsh Prateek Bora , Liu Zhiwei , Christian Borntraeger , Daniel Henrique Barboza , Amit Machhiwal , xen-devel@lists.xenproject.org, Sergio Lopez , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Bibo Mao , Ilya Leoshkevich , Halil Pasic , Xianglai Li , Palmer Dabbelt , qemu-s390x@nongnu.org, kvm@vger.kernel.org, Alexander Graf , Song Gao <17746591750@163.com>, Cornelia Huck , Matthew Rosato , =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= References: <20261027181400.1752951-1-berrange@redhat.com> <20261027181400.1752951-7-berrange@redhat.com> Content-Language: en-US From: Eric Farman Autocrypt: addr=farman@linux.ibm.com; keydata= xsFNBF7EiEwBEADGG0EtNKnjp+kQfEVqlqxXoBHjnaQptFpMgxNlz2GtqOujY6nzEWnybIXY 63XUTmMS/tWUf2DTbNCNoWwumGM/I2Gj1uGyMnc4Q477BQlL/e2/9MRaut11rwHsi4zmWylc jO0eFTSLFA8yFBj9osT3uZzk5TwWkD8sf+rD916fFVk0G39uYEd5sjEzjeOf9/dwXyZpjJY6 api1pUHEw7weRvOnllJAfIKFz+KoR6d7ezvMF9zOYHF73FGeSVIYoIEUhA5Cdg60rSlTtHb2 cftex3/cEapvY5bK3CKJ33BVVK10Bht9XfVaA/AOcg/3o5ZbhSIwz4xScGsEVf/Yr368YMdr 3VkCZrmN2ppmVRz/RvAmCyItnmzoVDlSREA6Faw6S0x8Oi7lN0cKh2hy9VPcVupraXJZrdAh GtdU+jrJvSbpdsrX8F7K3RwynbiqGrqC0izGla04hhtei/uwthatglukuxep4PknDGbzijg8 Ef7A8t3qEVklUDrsnNPN5HbR9QQdeF0HuWsDTfILbZv1MICfOK3BCDeT5mJWaJCoQ2rbuljM e1hFSt+mr7GV4h6NcBE+uGIqDSzQORtyTo0uBV4et3cSE84JxOfXBMrj0TlL1855JaIoPWEN uhDRB/dHW8+Fumq2du5hLcaXPka+MO26cNVKVLF0/JjwMTZ9bQARAQABzSJFcmljIEZhcm1h biA8ZmFybWFuQGxpbnV4LmlibS5jb20+wsGuBBMBCABYAhsDBwsJCAcDAgEGFQgCCQoLBBYC AwECHgECF4AdGGh0dHBzOi8va2V5c2VydmVyLnVidW50dS5jb20WIQTSxgUEyej1aM/lh7U4 J7IScb+VYgUCYel8TgAKCRA4J7IScb+VYsHAD/9BSQj7HeJf90PttOmVh35Bb4QyHLZ4g+9x waM59JCKGbiURuNRIGnoRarYXHk6vfy19v8v56Dy1IOlKWaRnizp5Mw9zXBBTCs4fgNbOzY/ SggFY2UzcziXDG29X9zznq5LgY1Jf/cwm1O+rn89GKCZWZhLEB2wKzBj7hum7NBdW+lxfVwp 2qONGDerttWDwAHxJ995k9aDJahq9kIKEMEZbrTQ8JI8KZGoox6+HA04EhoNzxvbV0J+/gLJ 2DkvxN5/xmcD3z+s8B5ev3NarOF17AIA9oCdfu8CPAupcNqJW86m19P5q6AyRB2ZLyAIAAhr HCXrnlh/8HJW1yCOVXxprFdpg1SX1fuArjbFAh53vVVDfkZlwHeTeE7+3y1rtDLfy830pqdD ymv94yey2y1+iZBdbaW0fSC/JkjkOCy8oZawkH3geM4MXV4ze4gbBH6BhxW/0gbEYjnLm3FA 53JcXwhHQFPWIYEYYPvATJi0JUiMY1Znkm3QBWDOCXSrG0tHpAclBa9L40zLRwA1h9YOMFEs qvKijUdvcDf4sTdJ+A6YL66grzul5vNt06NlqsI8HUDHE6vghqyWxupCav2+9b1BuLie++er b8OCo5n3TUHsVMjYJEePU1EkcCa84dCm+CXqPthgRv0sbe4UQEd/qUoVMdWj7Q7FL96mBn0G zM7BTQRexIhMARAAp+k1sC4y7Wtwjqtfu9wIihvY/Vot0v/sKg8CRGRIIRGLiCeA9o+2ZlxC jYztT3Leri5Vo5z09OmRMvoFLJjcHMCG5sYeZwOWNAbeuAxGkIMDSB4pLl3t2c+1PQuMBCd7 +mRZFaMEJfT3nhdUKxy2rp1+YucnA67xGXUJCiD5l9UmhPqa7SAYlpMAqDz7cmBo25c/UNm1 Tpwjrh70jq/4guV5gnprawH8nkRjdKH1JvKWvkuaB7FNZ9IuSHlWclcQX4IQMsaxsU2emAbP VYv7l4YNlKfdlJd8tuEodjuMLOBnr7e9H0hVNUWGFN9bkBNRu3zi/jvhyu15Iu4euR/WdVNu 2K2iYxIfiGMnv0F/a6R1bm10lCJrjyf23J8DYIeH4YmHvOOqYFkq3DWOctlXbb3+aABqjYt3 mkiOLXeplqbo/m3rWcGNd8Q/d1aVA0wm5+Nt3RdSuXG2FHOFdVUQKPLpf1NUH/LInBhS/9Ys ajm6tWXKv7hxwWmyz0u/th6gUra3KpARB1ypebWHULLNzKGwVS81XNs76QhXwX04cyiwLqKb WqLqJKThz+rLa09Ap+eO/UzPfFXvWYWfTeFRIQ/tKF332ZzRR8Xrh/fk//YXyRfpoE/7i5uz ve0HZWp5jXg9Yb+S6g0+XUKznnN9B8WLLCcuRIuSa722070v7KsAEQEAAcLBdgQYAQgAIAIb DBYhBNLGBQTJ6PVoz+WHtTgnshJxv5ViBQJh6XwwAAoJEDgnshJxv5Vib28P/1BYT5gvjuEB A80AXo/IqycicXxDJtrfmyw4COP7bi7AuiDcKyA1wRzC51paKwPFB8Unk2GvG4DV6aDmGTJY +GeCYgthQ+znW461S8B6GqDCAQt2VDNNFVU+gTuh7vYQOgt/OjtiiAvMIJBVRbXoNSRokKOF tpTiXf3ZOsAkot5ZmxE0TV94v18sp/bC84YvFyaxpw5bilT7bmpcq8B8/3yb0kmy6gXLcQAp OnomV3sQBmm050amiO3tvxMNv8J71AvNdTG/rojTDKUl2Nw4f+aw4nVw874m2XpEe9JGRw54 5d2dN8k3GpzcTBe9fCQPOFHOGkQ1CgptDkQuQVD3DIeNzQjXf6xehEymIKnLOkukT2smV0zh fj08z7eiv+dsmnBsbhdM6DKU8qIgkTu77TfHUKjjOY/Mj0YHPuH/J4b1AZFxBhGP0BTKiB2W CR6/49XVKvY1jHxgadSSNCD+f7tEqUNBlVl+P0emMJaYpK1+gy88ma4g3nvyOVe/VzDPjGDC 4HX/6RAR4Dbzry6/epWTTji+7ApzePzmJzPcuzD31ICsgT2dJ6ydxyxxXikBFJqx6BPOF+u+ 1BtKcTz1ek3I2sWvBM1V5CKaFw7iNXxS6HgS2scuAT2awKq+BQlt778/GfBWpXonfqixMvit y8m0x6unNti2MZIUMy0m2gcE In-Reply-To: <20261027181400.1752951-7-berrange@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-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI4MDA1MiBTYWx0ZWRfX6DNF9d3+Fd48 3RC0LyLTIg43PRzAiu72V0xXS2XMnoqAwwdYMAxqjPNdGY28P3SXorufggvURP6vTbjwA+1HZu9 E+0+KDfbCpZlDZp77Y6RuLynAYChara6mil5A/lVMHauSL+7cJHMI+PeWIvf9hnBi1wYh8qwLG4 GCg0zRF5wsU8tv2V9BEhcf0BBow1Ing5Y99rl0bqfC3WL0xXuf/gR7cacFUKwaR6r4DFOmYgX+/ P3r97KmXCn6oIAhUbvB8Je/+N7fCY0ou1iiVVmaRZ9vOaj0RHzguJq4mSoGv2bSofyM6FvKSuDD JWP3lxR4rmje0OfSwagqAM0CqB1ED3RZryzAAmIxFx4PgJa79GFO/ka2lSN3e/vGAFbJUMaSUgk XwNk6ZwHA8hDHH1Ni1XbVU1BeXyuO4XkVtK3DZfsTI9AwShtMEovGz8Pql015I3vQnjdnrYfQ6R wMospIB6u/RoLb69ttA== X-Proofpoint-Spam-Info: AW1haW4tMjYxMDI4MDA1MiBTYWx0ZWRfX/4eKNGhQYuJt zRo2PiEU8avhShhsUAibrj+fauJpmbWdSm3WeZHtAeeC7hz766s08/kdqx7IUto9zh4P2fuyFKR 7FE5QlmatiG44air37gw01qe1sslErU= X-Proofpoint-ORIG-GUID: phX3aVuqOesVV85x3otaufuHTUbZojP3 X-Proofpoint-GUID: mOfyjwvZsnG1t9CIM9KArcMoKqRcB5IB X-Authority-Analysis: v=2.4 cv=CeKdd7rl c=1 sm=1 tr=0 ts=6ae1fa62 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=20KFwNOVAAAA:8 a=VnNF1IyMAAAA:8 a=dfOxh3e3ZTYmKzKDSi0A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=ZXulRonScM0A:10 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-28_04,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610280052 X-purgate-ID: tlsNG-33051d/1793194602-6CCDB4E9-768040B5/0/0 X-purgate-type: clean X-purgate-size: 519 On 10/27/26 2:13 PM, Daniel P. Berrangé wrote: > The 's390x-ccw-virtio' s390x machine is already declared secure in > docs/system/security.rst, due too its intended usage in virtualization > scenarios. > > Reviewed-by: Marc-André Lureau > Acked-by: Cornelia Huck > Signed-off-by: Daniel P. Berrangé > --- > hw/s390x/s390-virtio-ccw.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Eric Farman From xen-devel-bounces@lists.xenproject.org Wed Oct 28 13:49:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 13:49:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463303.1674201 (Exim 4.92) (envelope-from ) id 1xM41o-0005Q1-K3; Wed, 28 Oct 2026 13:49:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463303.1674201; Wed, 28 Oct 2026 13: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 1xM41o-0005Pu-Gl; Wed, 28 Oct 2026 13:49:20 +0000 Received: by outflank-mailman (input) for mailman id 1463303; Wed, 28 Oct 2026 13:49:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM41n-0005Pk-4K for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 13:49:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM41m-007prh-A6 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:49:18 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae1fd4f-2eae-0a2a0a5409dd-0a2a450ae396-42 for ; Wed, 28 Oct 2026 14:49:18 +0100 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae1fd5e-f2d2-0a2a450a0019-d1558036cd2c-3 for ; Wed, 28 Oct 2026 14:49:18 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a20bdaf39cso10530525e9.1 for ; Wed, 28 Oct 2026 06:49: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-4a930a63eb3sm45969645e9.1.2026.10.28.06.49.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 06:49: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=1793195358; x=1793800158; 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=ljkTtUVemMOjlfxR572ftOnuoHHDJnk02lUk1Wt/Idw=; b=OoaU4jvzhHF/GGXhWo7JBpUD60jkdJ4y061MNs8fG+8O02rLgIizsSKaPGGc3zsVSn ts1D73BM9YvRAr+W5SfX06fzGsESMfCBKNe2pkujtF1/wDnF1RME0KmqjtDyxFXFjqac O7gfJ6xdT54MQoV6Bn1kSaVFyrqAN5FhUPOPFZHzBzmLJ6ePkxAA0E3QSu6BAmw47iki v+6OoIOGM9JFUuqY+wVP+Pi0hahkVyxPU2SK3tjVO16NB2qGiSCS2t0pstLFIlmgj0JT Pndlas05r2X8MhzOPubu1rqo+3pEYaLYOrZB8We4DcSloV7dsei0Sv6sbTNtPkPAX/Yl lpJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793195358; x=1793800158; 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=ljkTtUVemMOjlfxR572ftOnuoHHDJnk02lUk1Wt/Idw=; b=N+iut1D0DrBSc3Ifyo3wrcsYH3lVnJDBCp+WRjHWgMw0Fm7GIhmCI1i+sAaDYGuvYD E3zA1DVbGvZO2g9Y4jw40iDzUSO5is2VjEJNAdMH50tbmtHww5WI3sTE9713V8LEE6Q5 6xDt0PPVto1+vvw9JLpDXLnR8LrY09YJe1QZ48zvvgLjmCn2OXQ6vbxTA5U7ymI/hDJP RI9mcXiw/TUs6o4ROT3SqtwMGbf7Ka+sYLROeFEfj978haQWsLDdZcy/Q3+g6AVkB4L2 vIhKQm+Jb6WcFBmiyyaYxY6yLQlPqsjXDYfryvcl569fNh61d662GzfDq92kpBsame4w kf2A== X-Forwarded-Encrypted: i=1; AKwUvBzxrtaHiiE4vWJ5Ve8LPnQ3y7adAuhhmLv4KPcHPd1g9Ps0U4YhTOwWi9nkiDoc2Dp1ufKKQoaduBo=@lists.xenproject.org X-Gm-Message-State: AFq9FYJYVrQVOX6EWo/OdHnQC54jMAC3OFoV5Cl/UA6uhp9Su2DsGjzv 8u43651M77zyq1NvFWQT8DQYKSJ9aNWg5HbcEE6UF1NmeLZe0L0FGLs6tmH567yeKQ== X-Gm-Gg: AYBFou3Um45ZTQN7bAvuo6wVa5BTfBtkAhl8dACNhlwbjREUhWyan5oKTd0lTFnPcjz IeH4BKvQsQcqBCYO5njLjCxrrJiZnu9tW0h3sVxIlHYJYZgNb4VMbg6FxTWh6Z1KLnqe7fwcmFU ybiKo3AU5vtOjgF1UiHe3fVHn8zyxaBeOJNc+npSgHOKeWxtsNJlxn/ZFPLmBOMkwjTN5Ba+cq5 VT4z/imD34482DGdbaglPqEBFPn2AemdqAfiq2Gx3xmMTjWGp9vFYnUbVpRvWg9TS6I6TtP3Cf4 esBmBoe2T0Whsm4kSX8dskJPvvDLZYsPLKAO/mQXZjALkhV7IW+Eo6SmgQhGX/ioEIWYlkngsYA QR29SMZzwhKFtJX7Q/Q6a1OTuv22RQWaDCy8/sgQYo8irLby2EbUkTESOYoa7RVSCQjo6h0i3ZS 71YVO/lJ21B9uQCU2uj/Zy6Ue5iz/JixhvEYs2lrALqFl/NKCYds3CsbsaQtELig/P3SYUfJQLW aujmVpFIG7yZu/nVZPh4uzTwo7OYcetMGf1iynQmUsWAVNauEWpMcGT1imZwB2ixPrTF86mIdwH nacVZEL+l0s17K70+hABsUwKfe1jo4vr15knd6y42HU54ZB0GCfUKEjjTmcPiIClS7b+3SX9s/q 81o0F53RRTfExEId5fw== X-Received: by 2002:a05:600c:354a:b0:4a1:fba8:b13d with SMTP id 5b1f17b1804b1-4a9662a0c02mr50170645e9.9.1793195357433; Wed, 28 Oct 2026 06:49:17 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 14:49:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0 To: Mykyta Poturai Cc: Stewart Hildebrand , Oleksii Kurochko , Community Manager , 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: <103b10d012cc291906025045a2da1ce728f0bffd.1792072426.git.mykyta_poturai@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: <103b10d012cc291906025045a2da1ce728f0bffd.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1793195358-59BC0CFC-1CD4216B/10/78276251493 X-purgate-type: spam X-purgate-size: 12874 On 15.10.2026 16:08, Mykyta Poturai wrote: > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -16,6 +16,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > afterwards. > > ### Added > + - PCI SR-IOV is supported for PVH dom0. Isn't this x86-only right now? > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > #include > #include > #include "ats.h" > @@ -40,6 +41,8 @@ struct pci_seg { > struct list_head alldevs_list; > u16 nr; > unsigned long *ro_map; > + /* BDFs of VFs which have been enabled but which Xen has not added yet. */ > + unsigned long *vf_setup_map; > /* bus2bridge_lock protects bus2bridge array */ > spinlock_t bus2bridge_lock; > #define MAX_BUSES 256 > @@ -139,6 +142,47 @@ const unsigned long *pci_get_ro_map(u16 seg) > return pseg ? pseg->ro_map : NULL; > } > > +/* > + * Marking is serialised by the hardware domain's pci_lock, which the SR-IOV > + * control register write handler holds; unmarking only clears a bit. > + */ What about pci_vf_setup_pending()? How's that (to be) serialized again marking and unmarking? > --- a/xen/drivers/vpci/Makefile > +++ b/xen/drivers/vpci/Makefile > @@ -1,3 +1,4 @@ > obj-y += cap.o > +obj-y += sriov.o > obj-y += vpci.o header.o rebar.o > obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o When I added cap.o on a separate line, the intention was that new files would follow suite, including the respecting of sorting. Imo sriov.o wants to go after msi{,x}.o. Seeing how the latter are conditionally included - wouldn't SR-IOV also want to have a HAS_SRIOV control? > +/* > + * Accesses to a marked BDF are terminated until 100ms after VF Enable; the > + * first one past that adds the VF, which control_write() cannot do itself. > + */ > +static pci_sbdf_t vf_sbdf(const struct pci_dev *pf_pdev, unsigned int idx) > +{ > + const struct vpci_sriov *sriov = pf_pdev->vpci->sriov; > + pci_sbdf_t sbdf = pf_pdev->sbdf; > + > + sbdf.bdf += sriov->offset + sriov->stride * idx; > + > + return sbdf; > +} The comment ahead of the function doesn't appear to be related to it. Does it belong elsewhere? > +static void mark_vfs(const struct pci_dev *pf_pdev) > +{ > + struct vpci_sriov *sriov = pf_pdev->vpci->sriov; > + unsigned int i; > + > + /* VF Offset and VF Stride are only valid while VF Enable is set. */ > + sriov->offset = pci_conf_read16(pf_pdev->sbdf, > + sriov->pos + PCI_SRIOV_VF_OFFSET); > + sriov->stride = pci_conf_read16(pf_pdev->sbdf, > + sriov->pos + PCI_SRIOV_VF_STRIDE); What if we end up reading 0 here, yet ->num_vfs is greater than 1? Or put differently, ... > + sriov->vfs_ready = NOW() + MILLISECS(100); > + > + for ( i = 0; i < sriov->num_vfs; i++ ) > + { > + pci_sbdf_t sbdf = vf_sbdf(pf_pdev, i); > + int rc = pci_vf_setup_begin(sbdf); > + > + if ( rc ) > + gprintk(XENLOG_WARNING, "%pp: cannot set up VF %pp: %d\n", > + &pf_pdev->sbdf, &sbdf, rc); ... wouldn't pci_vf_setup_begin() better indicate to its caller when the BDF was already marked prior to the call? Also, if you didn't end up setting the bit here, shouldn't ... > + } > +} > + > +static void unmark_vfs(const struct pci_dev *pf_pdev) > +{ > + struct vpci_sriov *sriov = pf_pdev->vpci->sriov; > + unsigned int i; > + > + if ( !sriov->vfs_ready ) > + return; > + > + for ( i = 0; i < sriov->num_vfs; i++ ) > + pci_vf_setup_end(vf_sbdf(pf_pdev, i)); ... its clearing better also be avoided? > + sriov->vfs_ready = 0; Might this better be done ahead of the loop? > +} > + > +/* Find the PF which has enabled @sbdf, if that VF is ready to be added. */ > +static const struct pci_dev *ready_pf(const struct domain *d, pci_sbdf_t sbdf) > +{ > + struct pci_dev *pdev; You return pointer-to-const, and nothing in the function alters *pdev. > + ASSERT(rw_is_locked(&d->pci_lock)); > + > + for_each_pdev ( d, pdev ) > + { > + const struct vpci_sriov *sriov = pdev->vpci ? pdev->vpci->sriov : NULL; > + unsigned int i; > + > + if ( !sriov || !sriov->vfs_ready || NOW() < sriov->vfs_ready ) > + continue; > + > + for ( i = 0; i < sriov->num_vfs; i++ ) > + if ( vf_sbdf(pdev, i).sbdf == sbdf.sbdf ) > + return pdev; > + } This loop can easily have hundreds of iterations, when the number of SR-IOV PFs in a system is likely relatively small. I wonder whether there shouldn't be a separate list of "PDEVs with VFs under construction". > +void vpci_sriov_drop_vfs(void) > +{ > + struct vcpu *curr = current; > + pci_sbdf_t pf_sbdf = curr->vpci.drop_vfs_pf; > + struct pci_dev *pf, *vf, *tmp; > + > + if ( likely(pf_sbdf.sbdf == ~0U) ) > + return; > + > + curr->vpci.drop_vfs_pf.sbdf = ~0U; The call site has a comment that the call here happens after all locks were dropped. To prevent two calls here racing, the check-and-update here needs to be atomic imo. > + /* > + * The unmapping queued by control_write() still references the VF pdevs, > + * so it has to complete before they are freed. > + */ > + while ( vpci_process_pending(curr) ) > + process_pending_softirqs(); This isn't very nice, yet I also don't have any better suggestion. > + pcidevs_lock(); > + pf = pci_get_pdev(NULL, pf_sbdf); Why is this a global lookup? > +static void cf_check control_write(const struct pci_dev *pdev, unsigned int reg, > + uint32_t val, void *data) > +{ > + unsigned int sriov_pos = reg - PCI_SRIOV_CTRL; > + struct vpci_sriov *sriov = pdev->vpci->sriov; > + uint16_t control = pci_conf_read16(pdev->sbdf, reg); > + bool enabled = control & PCI_SRIOV_CTRL_VFE; > + bool new_enabled = val & PCI_SRIOV_CTRL_VFE; > + /* VF BARs decode only while both VF Enable and VF MSE are set. */ > + bool decoding = enabled && (control & PCI_SRIOV_CTRL_MSE); > + bool new_decoding = new_enabled && (val & PCI_SRIOV_CTRL_MSE); > + int rc; > + > + ASSERT(!pdev->info.is_virtfn); > + > + if ( new_enabled == enabled && new_decoding == decoding ) > + { > + pci_conf_write16(pdev->sbdf, reg, val); > + return; > + } > + > + /* Unmap while the VF pdevs are still around for vpci_modify_bars(). */ > + if ( decoding && !new_decoding ) > + map_vfs(pdev, 0); > + > + if ( enabled && !new_enabled ) > + { > + unmark_vfs(pdev); > + > + /* The VFs cease to exist below, so Xen has to remove them. */ > + if ( !list_empty(&pdev->vf_list) ) > + current->vpci.drop_vfs_pf = pdev->sbdf; Minimally an assertion may be wanted here, to check that drop_vfs_pf isn't already in use. > +static int cf_check init_sriov(struct pci_dev *pdev) > +{ > + unsigned int pos; > + > + if ( pdev->info.is_virtfn ) > + return -EINVAL; Can this happen? I.e. doesn't this want to be an assertion, much like ... > + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_SRIOV); > + > + ASSERT(pos); ... this one? > + if ( xsm_resource_setup_pci(XSM_PRIV, pdev->sbdf.bdf) ) > + { > + printk(XENLOG_ERR > + "%pp: SR-IOV configuration unsupported for unpriv %pd\n", > + &pdev->sbdf, pdev->domain); > + return -EACCES; > + } In addition to Jason's remark (which may require Daniel's input): Why "unpriv" in the log message? That's fine when dummy or SILO are in use, but that may be entirely off under Flask. > + pdev->vpci->sriov = xvzalloc(struct vpci_sriov); > + if ( !pdev->vpci->sriov ) > + return -ENOMEM; > + > + pdev->vpci->sriov->pos = pos; > + > + /* > + * We need to modify vf_rlen in control_write but we can't do it cleanly > + * from pdev because write callback only accepts const pdev. Moving vf_rlen > + * inside of struct vpci_sriov is also not possible because it is used > + * before vpci init. So pass it here as additional data to not require > + * dropping const in control_write. > + */ > + return vpci_add_register(pdev->vpci, vpci_hw_read16, control_write, > + pos + PCI_SRIOV_CTRL, 2, &pdev->physfn.vf_rlen); > +} This kind of comment is at risk of going stale without anyone noticing. It's anyway written more like something belonging in a commit message. > +static int cf_check cleanup_sriov(const struct pci_dev *pdev, bool hide) > +{ > + unsigned int pos; > + int rc; > + > + if ( !pdev->vpci->sriov ) > + return 0; > + > + ASSERT(!pdev->info.is_virtfn); > + > + unmark_vfs(pdev); > + > + if ( !list_empty(&pdev->vf_list) ) > + { > + struct pci_dev *vf_pdev, *temp; > + > + printk(XENLOG_WARNING > + "Attempting to remove SR-IOV PF %pp with VFs still present, VFs will be forcefully removed first\n", > + &pdev->sbdf); What would be lost if "with VFs still present" was dropped from the log message? > + map_vfs(pdev, 0); > + list_for_each_entry_safe_reverse(vf_pdev, temp, &pdev->vf_list, vf_list) > + { > + pci_remove_device(vf_pdev->sbdf.seg, vf_pdev->sbdf.bus, > + vf_pdev->sbdf.devfn); > + } Nit: No need for figure braces here. > + } > + > + pos = pdev->vpci->sriov->pos; > + if ( !hide ) > + { > + XVFREE(pdev->vpci->sriov); > + return 0; > + } > + > + rc = vpci_remove_registers(pdev->vpci, pos + PCI_SRIOV_CTRL, 2); > + if ( rc ) > + { > + printk(XENLOG_ERR "%pd %pp: fail to remove SRIOV handlers rc=%d\n", > + pdev->domain, &pdev->sbdf, rc); > + ASSERT_UNREACHABLE(); > + return rc; > + } > + XVFREE(pdev->vpci->sriov); > + > + /* > + * Unprivileged domains have a deny by default register access policy, no > + * need to add any further handlers for them. > + */ > + if ( !is_hardware_domain(pdev->domain) ) > + return 0; > + > + rc = vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, > + pos + PCI_SRIOV_CTRL, 2, NULL); > + if ( rc ) > + printk(XENLOG_ERR "%pd %pp: fail to add SRIOV ctrl handler rc=%d\n", > + pdev->domain, &pdev->sbdf, rc); I'm inclined to suggest "re-add", so it's clear from just seeing the message in a log that this isn't about init of the device. > @@ -486,6 +487,11 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size) > return data; > } > > + /* Ahead of any lock being taken, as adding a device acquires them. */ > + if ( unlikely(is_hardware_domain(d) && pci_vf_setup_pending(sbdf)) && > + !vpci_sriov_add_vf(sbdf) ) > + return data & (0xffffffffU >> (32 - 8 * size)); Is there a reason you can't simply "return data" here, like is done in the first conditional of the function? > @@ -145,6 +145,22 @@ struct vpci { > unsigned int nbars:3; > } rebar; > > + struct vpci_sriov { > + /* PF only */ > + struct vpci_bar vf_bars[PCI_SRIOV_NUM_BARS]; > + /* > + * When the VFs which are enabled but not added to Xen yet are > + * guaranteed to respond to config space accesses. Zero if there are > + * none. > + */ > + s_time_t vfs_ready; > + /* Routing ID offset of the first VF, and stride between VFs. */ > + uint16_t offset; > + uint16_t stride; > + uint16_t num_vfs; > + unsigned int pos; > + } *sriov; > + > #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT > /* Guest SBDF of the device. */ > #define INVALID_GUEST_SBDF ((pci_sbdf_t){ .sbdf = ~0U }) While for guests we have control over the range of valid SBDF values, ... > @@ -169,6 +185,12 @@ struct vpci_map_task { > > struct vpci_vcpu { > struct list_head task_queue; > + /* > + * PF whose VFs have been disabled by the config space write in progress, > + * and which Xen has to remove once the PCI locks have been dropped. All > + * ones when there is none. > + */ > + pci_sbdf_t drop_vfs_pf; ... I don't see what would guarantee an all-ones pci_sbdf_t to not represent a real device. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:15:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:15:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463324.1674211 (Exim 4.92) (envelope-from ) id 1xM4R8-0001mn-GG; Wed, 28 Oct 2026 14:15:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463324.1674211; Wed, 28 Oct 2026 14:15: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 1xM4R8-0001mf-CS; Wed, 28 Oct 2026 14:15:30 +0000 Received: by outflank-mailman (input) for mailman id 1463324; Wed, 28 Oct 2026 14:15:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM4R7-0001mZ-2g for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:15:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM4R6-00CqWv-BV for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:15:28 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2037e-bab6-0a2a0a5309dd-0a2a45049af6-18 for ; Wed, 28 Oct 2026 15:15:28 +0100 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae20380-b57f-0a2a45040019-d1558030c058-3 for ; Wed, 28 Oct 2026 15:15:28 +0100 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a5b2be99a8so8915215e9.2 for ; Wed, 28 Oct 2026 07:15: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-4a978795f4dsm42087895e9.9.2026.10.28.07.15.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 07: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=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=1793196928; x=1793801728; 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=mlEJ3PnBF22KBmNuKmc5iG0oPTUVfRLAWE+gciNaRd0=; b=VNZw1mbEkZ5CmO3sLm5AZHQcJo5f8v85qLVOhslCp4CHQIqH0WzHVbIx8Dpw7FMArM 0qjjTk8HI9xQ8aEQLH+ji3fDQbZ867KwE/YzV9rTSjfCoLCxWeLFZ/qJYinprbjwofMJ Xo/MFL6zyUwQapKaScdoetwe/YGN1e+BlOBqYwyH+fAdOx2tVnhEDgHzl3i9rB8BDxtm hoLgI4Wb20AKpCY60vmsDqg9JEHY3POxSI3iXl7zdU6e1pjwkdgAGrgQFIwhDq6mnYo9 7dBPWaLb8ElmRR82Ya04tn+OfUtGXTBOPkMnRBtXOa0qMH0ev3TbSFU6ZtaDJAZGmo78 22Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793196928; x=1793801728; 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=mlEJ3PnBF22KBmNuKmc5iG0oPTUVfRLAWE+gciNaRd0=; b=o2Z0yo6ZntBtroN/Q6xoLfj832gQc7EK1LfKQYtvvEnt/z+tjU7SS4ajEQ76dDyftr +RbqhntblBo2+CHj6/Gj5jiK50bLL3pyCY2HdTh+if609xtROMUX3ieP56A5pxoN1clH B6kMGLSX+KmvLYuFjKnb/bA0O8TiZOeyMnHm4GKp9F6pUzmmUF3f6U9DwLLwmBcLYRGu aS50jX2bela6FXvOnjJTzfoIZ+8QVFXJOixdbSoIcfC05v8ytsmjqGTL2qFa0GG484dD d6s3Y8NpIX2jbCyItGFNCMuHCTfd1WS2jETR0BazCupac4o+yl63sUkEM7lyzQn2qn87 CwKg== X-Forwarded-Encrypted: i=1; AKwUvBwOnReL1haXaGBjvlDvZhBd992ZQ5MKJUf1ZPF/ryPoHieh1QXitxGJJ0L6Inck2inUQZfSkBOp3E4=@lists.xenproject.org X-Gm-Message-State: AFq9FYJX5O0LuFWsRjLcCI5jJLSq//DCEmSt2RPrZ6lQxAbuTDI+vh+b YSweGWfh7NFB9EpyFK/UNEqFdmMm0NpGjIIZK46VJBTKTQQ1aWBHMU7o1pex81bNuQ== X-Gm-Gg: AYBFou0dJIahq/aun4f7U15hE3gZzCA1/vlaA9fX3xC28jvuD74abP4ooIMz1mS7sNX QIpqDwLor9IBDzJvf0qdBaXzhC/Tz6rvFKU3xIlIQwRH4iNGC04iW6SRqzQdVn3aWs7eSoFJuDu 6gdEwixpby0UGcfM4KPWQQUOXO5Oz50slf50i5r7w1nWpXlm8hz/yPvEbbZEMZ/3r2uhDY9HnCk zNfzTpuUJsE1CjZkzhg+2c+/fo/+PaIxaAR6Ys23ehXl/F2c7vnM8/RBLh3h+g17uUE4etUMfHd P52VGXuTRQmirN9ZZfthLxYgp02DijSndxJqvCDxrcQaHKRusDN+pI48pKwFSVzSvivcV/1FY2B kBLWeZuepQdTxQq4Iv6YCV7GLxYwv8o61OGpkW0gxUWsZthhsfkJUBNrpGk0XmvY847ncIc1VSX e4bZDuS7yg+tov2vld8rUIFIJVMr2GEQKuYrkiUrcpvbsk/KBHwZev8wvew4oej6V1Qst6XXlny RT2qbfDfuKH0uY160FVMCLGH9PBvCQ0AXI3re1Swu8IDnp6710bgVuDv+Ksyo9r8311bXvqgKKv uRkU1INqbbdaRBQD0pgu9bfTsZYc6BmHjvkxQ0lBbItmccuzOwlKYLE6BSS42vVJ+3U/WvgRUZ3 uW3LezlaAomPz58nq X-Received: by 2002:a05:600c:154a:b0:4a0:1efa:c74a with SMTP id 5b1f17b1804b1-4a9678c26dfmr51155745e9.20.1793196927665; Wed, 28 Oct 2026 07:15:27 -0700 (PDT) Message-ID: <7128c617-9432-4571-9b7a-22d6f6e8d884@suse.com> Date: Wed, 28 Oct 2026 15:15:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/mm: Remove loops in get_order_from_{pages,bytes}() To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel References: <20261028124104.1564435-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: <20261028124104.1564435-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1793196928-520D5B50-939FBEF8/10/78276251493 X-purgate-type: spam X-purgate-size: 2687 On 28.10.2026 13:41, Andrew Cooper wrote: > These two functions are just fls() expressions in disguise. Furthermore, > GCC-12 at least won't const-propagate get_order_from_pages() with an input of > 3 or above, which covers most of the cases it gets used for. > > Rewrite them, and provide some self testing. > > Interesting, unless they are always_inline, GCC has a habit of out-of-lining > them even when inlining would have been a win. I expect this is to do with > the fls() functions being superficially more complex. > > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Anthony PERARD > CC: Michal Orzel > CC: Jan Beulich > CC: Julien Grall > CC: Roger Pau Monné > CC: Stefano Stabellini > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2999078934 > > I think paddr_t is the wrong type to be using in get_order_from_bytes(), and > so really is fls64(). What other parameter type would you suggest? size_t is suitable only to express virtual address region extents. > I could add fls_g() which would be slightly nicer on > builds where paddr_t != uint64_t. We have ffs_g(), so adding fls_g() would only seem natural. But see also below. Either form: Reviewed-by: Jan Beulich > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -530,26 +530,16 @@ page_list_splice(struct page_list_head *list, struct page_list_head *head) > list_for_each_entry_safe_reverse(pos, tmp, head, list) > #endif > > -static inline unsigned int get_order_from_bytes(paddr_t size) > +static always_inline unsigned int get_order_from_bytes(paddr_t size) > { > - unsigned int order; > - > size = (size - 1) >> PAGE_SHIFT; > - for ( order = 0; size; order++ ) > - size >>= 1; > > - return order; > + return fls64(size); > } Along the lines of what you do below, perhaps simply return fls_g(PFN_DOWN(size - 1)); (and nothing else in the function body)? And then even return flsl(PFN_DOWN(size - 1)); (eliminating the immediate need for fls_g())? Jan > -static inline unsigned int get_order_from_pages(unsigned long nr_pages) > +static always_inline unsigned int get_order_from_pages(unsigned long nr_pages) > { > - unsigned int order; > - > - nr_pages--; > - for ( order = 0; nr_pages; order++ ) > - nr_pages >>= 1; > - > - return order; > + return flsl(nr_pages - 1); > } > > #ifndef arch_free_heap_page From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:21:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:21:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463333.1674219 (Exim 4.92) (envelope-from ) id 1xM4XJ-0003kQ-33; Wed, 28 Oct 2026 14:21:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463333.1674219; Wed, 28 Oct 2026 14:21: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 1xM4XI-0003kJ-W0; Wed, 28 Oct 2026 14:21:52 +0000 Received: by outflank-mailman (input) for mailman id 1463333; Wed, 28 Oct 2026 14:21:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM4XH-0003kD-Co for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:21:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM4XG-00CsgK-PY for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:21:50 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae204f5-e002-0a2a0a5209dd-0a2a4507edfe-32 for ; Wed, 28 Oct 2026 15:21:50 +0100 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae204fe-b4ea-0a2a45070019-d155dd2cb174-3 for ; Wed, 28 Oct 2026 15:21:50 +0100 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48afbd2c386so628289f8f.3 for ; Wed, 28 Oct 2026 07:21:50 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ecd37f4sm34217317f8f.44.2026.10.28.07.21.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 07:21: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=20260707 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=20260707; t=1793197310; x=1793802110; 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=k8WPmaxocSFLoWlGshpx6m4E6Y++C1Fna92wk+6234s=; b=KafN/uUq9BYhu7mAJH+lLxiyX+w/XGQZGIuIDzBl2eLlTCfK0zaEfrS3OVDDY3nN3a RvPxcd2U6AV/Q70k7tZcrLyezGGa4OjW59rjvpiDgc6cZChX8FwB4yGuiexWVbHtVL8w pwcjWMoYfzgTDElc+fVbDPXjfIyeeJncsk4pYxMJcmWIi1b+fIvXm/64IoaR2YU226Uz 4L7yyuWodGngmQIk0/Getop4fo3TJsdeFiXQvcajRYShKLbxiqea5WIxLgZYConcf1ZW XCVyN7SNCDqsLJk1x0zFMriDViHPLW6IMk/ofc6BKsX8scqPrCC3Lw5eGOt7Yn/3hcwY 4VgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793197310; x=1793802110; 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=k8WPmaxocSFLoWlGshpx6m4E6Y++C1Fna92wk+6234s=; b=2muUQqnhtA+pJWkOGIo/UTTQzA7dI6CGKjirRcdZSyxBisdq9lu4ck5mwiefHeADjc AaMWrus5szimDwJ9jgm/BxYN/OI3hIf7jFqN7FFEWls3hOBpBzIl9YpM2er8MghFawhO 1KT5mLhPwcPW7Jk/gvLjQZFptxNzdlFu7ovU9Ag8fEDhqrWIlMiwCG0/rCeEULDu5ViM /JDEq0jf2PEO8kHmJPcGQ9MGfR+2Q1onmcoF68kGzrwjBFC6f15tbdUpjHXYoTJS3Jvm oC2KU9IDcQDrgIjh0v9xn+L9ejJn2Yb7y5Z7wYKB0W7/UQl5/xuodL5JZcuFuuCBQzjf Z3zQ== X-Forwarded-Encrypted: i=1; AKwUvBx+5MJkDcg1n9mtk1edxLUtPSz8XLIRAOZ+5KYnQURj8yGEgKkuLhZHlpKEvpQvroQWc6wzs5ZSr5s=@lists.xenproject.org X-Gm-Message-State: AFq9FYKAls/q9zJ7ZUdczsnLCEr/qL2qKf/ehoq7n3CHSWEFByoAVSR/ QDrm/MJkkXKl27cnrWS49O2hOLtOH1+f+aLmhQJC0VwrYPNcKYmTKnp2 X-Gm-Gg: AYBFou3RR9Xh1KP++at2NagLqIFav5+kwHTAy9DW3ymBVkYoFRTJ0jz6MXV9yWoKBxH CBM0k+Vu0njSksusE+WCLNApnXKwCEUjS22wEwkpXZf9dHcPEEY8eo3esjqQ3gxXOxg20gysH0p ZNOATICuVuyd67ky2UFtt8H6X33b8u4HVJ7cYctsnZDztTnCcybCFiIAddB1mhELISd9IpT97Q9 9ir/xy8JqDOMYDIB/Enh3NvFxiZFiWzV900hdcAWk2aaTRgJtZrzkWhHbvuHwCCJ+D2yRCOmyxk EK7sN2q333DVBBaTsCrZkbGJzFlukds+7q7Ppar0Mco+GeeSgIAogLMlzXfZntqXEoYcPgmKCKx PPjCoPVQlv+KZkid0NiCzRSZbXQ58403SIV+3lu6W2VTt9nlAtgYHSk3Rw5n8OmOcB2/iCpSqCE OPzK97k5/1FazXTs5m3uPymqJ9I3MW3co/JPpLpD4If2RgtRvKKVM/Ioco8iEk06OkqWlSsiM7u g1BTnQQ/wN9/DpZlQAS8Nu/Acb0VM8Wawyjdx4dJm0XfdINOrScleT5SSbM0paXVdEf5M8HtG6Y YbYvYoTBgeemomJoIHykul0kaWI2wr+R/TFDZ58NGQsVUxF0HxkSUvs33PLboM4OUH2P/HTI+iQ hgw== X-Received: by 2002:a05:6000:41c8:b0:48d:faa6:cedf with SMTP id ffacd0b85a97d-48e5d5e01d4mr6431632f8f.56.1793197309868; Wed, 28 Oct 2026 07:21:49 -0700 (PDT) Message-ID: <19bc2130-aa66-495e-8f43-b1ce263142fe@gmail.com> Date: Wed, 28 Oct 2026 15:21:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Baptiste Le Duc , 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 , Alistair Francis , Connor Davis , Zheng Zhang References: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1793197310-A64DBAE4-541D07A6/10/73395122804 X-purgate-type: spam X-purgate-size: 2139 On 10/28/26 2:05 PM, Baptiste Le Duc wrote: > p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when > RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. > > The privileged spec allows exactly two schemes for updating the PTE A and D > bits: hardware sets them on access and on write, or accessing a page whose > A and/or D bit is clear raises a page fault so that software can set them > (ratified as Svade). Every implementation uses one of them, but platforms > designed before Svade and Svadu were ratified, such as the HiFive Premier > P550, may advertise neither. > > Trust the device tree when it advertises Svade and/or Svadu, as for any > other extension. When it advertises neither, probe the scheme in effect > and record the matching extension in riscv_isa, so that such device trees > can be used as-is, and warn naming the extension to add to "riscv,isa". > > Introduce probe_hw_ad_update(): alias the first page of the Xen image > read-only through the FIX_MISC fixmap slot with its A and D bits clear, > then load from it under an exception table fixup. Hardware updating is in > effect if the load completes and the A bit is then set. The probe fails > otherwise, whether the load faults or completes leaving the A bit clear. > The A bit being set by a speculative access still implies Svadu, as Svade > only allows A to be set by software. > > Add Svadu to the known ISA extensions so it can be told apart from Svade. > The comment above the enum asks for new extensions to go at the bottom to > avoid shuffling, a leftover from Linux where the IDs were macros with > explicit values. Nothing depends on the enum values, so have the comment > say that multi-letter extensions follow the order of riscv_isa_ext[]. > > Assisted-by: Claude:claude-opus-5-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v9: Nit: something wrong with version numbering. (in the case of v11 would be nice to fix). Changes itself LGTM: Reviewed-by: Oleksii Kurochko Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:24:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:24:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463343.1674228 (Exim 4.92) (envelope-from ) id 1xM4Zc-0004JG-HL; Wed, 28 Oct 2026 14:24:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463343.1674228; Wed, 28 Oct 2026 14:24: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 1xM4Zc-0004J9-EG; Wed, 28 Oct 2026 14:24:16 +0000 Received: by outflank-mailman (input) for mailman id 1463343; Wed, 28 Oct 2026 14:24:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM4Zb-0004J3-6n for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:24:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM4Za-007vsI-Jc for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:24:14 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2058a-e002-0a2a0a5209dd-0a2a45069842-8 for ; Wed, 28 Oct 2026 15:24:14 +0100 Received: from [40.107.201.36] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2058d-195a-0a2a45060019-286bc924892c-3 for ; Wed, 28 Oct 2026 15:24:14 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN7PR03MB431326.namprd03.prod.outlook.com (2603:10b6:208:5f5::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Wed, 28 Oct 2026 14:24: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%4]) with mapi id 15.21.0569.007; Wed, 28 Oct 2026 14:24: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=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=O/t1GZGRq6+w1j/cW9HhoSedHXv9pyQI4NVH0OI+YmRsm6TtEfCsAiirR+jCMHifl9OvssqSo94JGzumsT/pX260QwGy2QlG0IXLaBUaTSnBWyT4HsQ9FI97rIvkcAerFf/8UYuRzO2KQngUm5wHWwF9hdQCQrdryk29TA4MGNeHwdhk/V2WpnXXJYTILqx7Ne9v3d+s+zKPVyQuOmljZdF6yw4fgLYzZyEsihfcWXbMDAHWebXAPTqeZsXIGQPn7M+6vooiVlgWds5RSQ8474c1QE6c8+cpxDKhk/V1fXN6mdlBHz2RcAJxlSFHVRX2gYhqmHMbY1S3E2acCyRiBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M5sLmmpbpN6bk1iZab31+cz4v3A2w/m5Tk3CYmh3bfI=; b=rukF3liZaPX/Ot03DCHD233zMxGaMiuYmcUzcq0NmjwqSvMblMaKaBV1cD7r//7HwBwxJk394ntnmqgZoM/Qoosx5OnXfNO7jf6/gp9lDQmUOn3uVEM3QvrGGXRkB2D2gquCS4DeeZgG9XykDqE09sh5tN6Nsp5yyIJ+wLkxa53lqOEIqQBhXQKPUasFYIfBPNGG1nBVhPZfqqrnw+l0rKAjLK9jGkJI5PGBMczBbkSGaN46jokSjpytEIMMOiuk42i+BtTEs0+epNXVQi2WJxmIDIirWzosaMvNMFeb3SjTDJsAyaMKH7dV2totUtn8RtTKxPRADJVZ1+kBZ0vlMg== 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=M5sLmmpbpN6bk1iZab31+cz4v3A2w/m5Tk3CYmh3bfI=; b=ELlBS2yNKv5+rwTNLgLgXYLi5wzRGnV/AAudWrGKM9i2/utwSGFDIkKJCCjLRQgALRAUVTE54PaAj09lD+7fhiBFcGdIBUF9evSNT41rg8RfcVfMeP7hfiYV91YsRwOJH3h4FUmSigIlgxY0+qrQQZsW4iOqO1cPAQsRZht2wyM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <35fa29d5-fafc-43da-a5a5-72df8f367e3c@citrix.com> Date: Wed, 28 Oct 2026 14:24:05 +0000 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 , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: Re: [PATCH v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@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: <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0026.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2df::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN7PR03MB431326:EE_ X-MS-Office365-Filtering-Correlation-Id: dd7af81e-032d-45fb-d4e1-08df34ff21a3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|7416014|376014|4143699003|11063799006|56012099006|261009223027099003|261022115727099003|261022075727099003|261022105027099003|261026140227099003|261026121527099003|261021121427099003|261021135927099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: UmUXsw//LE54FslBAj3YnfBBPTzTS3+Bl4zxFkPulbqUj93nuZitJWmy6tV0FYrpafs9IjiqNNXjfNOoEMK3Zd+dkzjhsBn/6f0N4O5XrNxpbG9Bt0D0GWcZmw0aWYOuiPqSW+IKIqm+gTAHMLYO/057Bl+zTfXzZj0ctXE4m+HAkL/ng5fgZXANIxs3GB78ZcMFd61q+yybxx6tTbzVX6bBzGuOVAaFhNIqgCx4tkl6IDCaEUxFPIDFCe75cm8qowiCPT2BMSnlNNLZHvPOPv4T7q4bYoSNc1rQS0FfZ0LzxsVMRGCizz/vxxG2g2Xv24unJD0ZwXfus9EOEYdfuUGVoO3o0r9Pyvhg/jbL2A/qckO3KUQPOTCR9fOd2G20+35L+gY8aCgcHrOift151cEN2DsbFnJJ+45Vc++Z0POmqYpjJ5w901xU5Z1ZC9fKTED9aXmvjdDxxL190oHpawTqiY1PWDzADt9LK/X+itr43NtWR6wnUss5dvtP4w7Xhio0HPF/weS0H2pnpaB2/UmU+3cvk6VoJDqLSRI1jTaRTkUmqgGr1znLlumoCgSAle9op/xAiN0V1wbs2SJzLJiC/DdALzI2Hjctk8sJ4vrXz24Kx/t+4vlTm+NdSd3Rk2DxZy3chGW92bw3m6HdH8jTtVNHVX4iZ28zzbYKI/8= 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)(23010399003)(7416014)(376014)(4143699003)(11063799006)(56012099006)(261009223027099003)(261022115727099003)(261022075727099003)(261022105027099003)(261026140227099003)(261026121527099003)(261021121427099003)(261021135927099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UGxwRkxxbHo3TUNHZlA4VXV5dkZCVFV5ME9xd2pmelBUc1E2VmNERytHNWpB?= =?utf-8?B?SzVSbTRVa2FxRkhoTXQ4bzE4VGZRanVZZFdKS1pEQzQ2QXZRZWhRaStTdDZt?= =?utf-8?B?a1Z3Q3c5UjFwMDFSSHAyQkFiUERBd09LdmNZZlNHRUs3aE1TWTZHZ2x4T2Nj?= =?utf-8?B?ZlliVkJ5TWowQllkMVNmV2hlVktBRDEyM1BYcFpvQmgrbUp3M3pSRHUvbG12?= =?utf-8?B?a3ZrMEFQL0VTYUlhblhjaThoQitva3BJbUNGbFlNbTJQOEpqMkhOV1NsNk9s?= =?utf-8?B?Zmx6UjZ1dTF4aHZSR0RWZXdhc1hQYmtkeDk4WGg1dlc0TFdnMjc0VHJXeDlq?= =?utf-8?B?RHZ5bnFsVFFCbENaNXREb2Zvd3JscDhUTE1jMmRyV3ZvZlJseDh1allKc0Zy?= =?utf-8?B?UnZwWXV4RmluWENpL2J6MXZRN1FKVmJVL292Z2gwUFF4S01xUThWS1R0YWt0?= =?utf-8?B?ZVBVQ2xiOTZHVUhHMXRCakFmeGlUam9ROFhsU2dPRDJQcFc5VnFLQ0k0d01o?= =?utf-8?B?RFh0cE9DNkxOTXU3MkoyYVhTMlZBVWFETGtWaVRXemg1UGcrdHJ4elVEQ3E3?= =?utf-8?B?azRpM2lkanRINVFnZ2ZxbWlaNE50dlB3alM5a2QrYkkwSFB4Ynp3cTA4UmNn?= =?utf-8?B?V1RnVkE0YUJCdXMvazdybzUwakxBT0lFZWdiYmVmMHFsS1A3ZjhOU2V3V0hk?= =?utf-8?B?Zk5nK280NXJkaytidG1GMisxZC9USzBMeVBoMjIvWm10SjlRMmtSNmQvbDZ1?= =?utf-8?B?N2o3a2VFMkhTMHdJeEVjNmJDWHdVNGVHaHJkcUtzSlZWU2x1V3JrUDB0OW5v?= =?utf-8?B?WmxKVDhhcDRJZzZsZTN0ZWN6ZDlOYVBFSzJNUHh4blozcjM5VlNvZkdmVzV2?= =?utf-8?B?OHd5MUpPbWYvL2k1bVFLdzJCdmQ1THd6Q2NNM0JoZG9TcUhsVTNuQ0QwNjhI?= =?utf-8?B?V3NOaW4zaTlZYUxpOUJPNHU0TUM5eHNqRUg5Snkyb0pqajlXek9URExROUVB?= =?utf-8?B?WStBd0NQVU5lT01Ob3NoRFIzcGxLa0NTdVQrK2pVS1pPUVhuUDZiMHZkVlUx?= =?utf-8?B?cU1Cd3B6T0hOdG5XaHVqa3J5Tk81VWQwV0lrcXBKYmc2eThJVW1RZ3RpN1dX?= =?utf-8?B?OFRSYU1pLzd5dmR6dTRQcFU2QjlLeVN6UXlZa09Fd0F6VEx0bHMxWm9RR09y?= =?utf-8?B?T2phM2xMeFhuaDZVSGtFc2VKWDJBcDNQUW5IZVQreGNVZ1JIczkwWG1naTN6?= =?utf-8?B?ZHdjQmExbFdkVnZuUUcrQS8rajh1dmNLdnlCNGx4dmhFTjVuNXQ1NWhrOUV6?= =?utf-8?B?eHAxaXBTdnlnTmNwT1pJcDFoQ0swRWlFdHp4bmpwaCtiK3gzdmdkV2NkbDVn?= =?utf-8?B?QmlnbFdjdDNqaGxtVHM0QktyYjdDUVExbFlCQkplZUVBbG9rbDNMT1l2dEgv?= =?utf-8?B?YUc1dWk5OTdFeFlCR1FReVJHVEVhNU5ManNacFVQRFk0WHkrUHRJMU00SENl?= =?utf-8?B?TnVvdHFQbzFJbWRDZkxUbWxjRG8vSHJpNFJCMWxyY1NiUWF1YXNzcVkycGNM?= =?utf-8?B?NmJCbFYrSzcxQ1RFYXdZUlFZWlFUUThlK3NWWkE3TFBLcjhOS2xOQmR0MFNU?= =?utf-8?B?QmloaUptU1YxSE9XaTdPM08rQkY0TGVkUm4yNS9CRk5zeUZlMHZ1Snl6NDgy?= =?utf-8?B?MmtxQS93MjJiU0E0cEN2NXZZMFJLYTZWektTN1J3QWg4Z3JTeDdNazdmOFMy?= =?utf-8?B?L2hXNVU0aGJsN3F2d1F0ajlCbXpFYjJ1TXBkalBNVG9nclVEOFJFNi9CMjYv?= =?utf-8?B?VVVtRnNqVjZlbFBaOExCZTU0YjVoajZ0RGtWMk1MRnk3MDNBejdIQ1ZYMjdj?= =?utf-8?B?Rkt4N0dKTzdwM21BbXh3c3lXNDF2R2FJbERIMUZrVVgzMzQ0WmlnSlR0aW41?= =?utf-8?B?ZVIvdDhHOFIxbkRkM3hUR2JXZENRRC9qZmpWREpqWm9XOHVjQitCSDd5eC9Z?= =?utf-8?B?c01URFlVSHFZMWtCalRtRFRyMHlOZ1F5dHFweHA2VHpiUmVNQnpoVzJ1QnBC?= =?utf-8?B?SEprQXVxVGZ5cHA2OVFVZ29xOUxWa3pqcW5WLzdwTlR4K0FqUytieHVRQVpL?= =?utf-8?B?UUVrdDJ2WVVMU2I3VUJYc0ZZTWt1U2YrWndTU0dEbmNyS1d3dVo3WElzTEp0?= =?utf-8?B?em91SGJtTWtidTlwL2lFTmFqdkVucjVuamZjVUdJMGZ3ZHladnYxVnUyalVT?= =?utf-8?B?SXBuTzM3N2VwRnJDQmswWWNJRXdlNVdqYzIybmh1bEFzS1kxY3B1bmpqZWxJ?= =?utf-8?B?UjZoUGlOeHRyWnU1M3B5dHpUZDNlTEJHYWZ6cGMrSGsxb013QjdvUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd7af81e-032d-45fb-d4e1-08df34ff21a3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2026 14:24:09.6501 (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: qQaER5WklKIShq7Bjf1OAlPrgdyTh72Xxt9IpelRQw9o5cTaeslQiQGFyWuxgf4RThY+B0aHhUdtJ6OxQ/A/igx4iFIZw3m+m8cqy8QCJL4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN7PR03MB431326 X-purgate-ID: tlsNG-16d1c6/1793197454-FD80D77B-1FDF9323/0/0 X-purgate-type: clean X-purgate-size: 4614 On 28/10/2026 1:05 pm, Baptiste Le Duc wrote: > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > index 3d5bbd2228..83d3bc5ddc 100644 > --- a/xen/arch/riscv/cpufeature.c > +++ b/xen/arch/riscv/cpufeature.c > @@ -630,6 +632,53 @@ const char *get_guest_isa_str(void) > return guest_isa_str; > } > > +/* > + * Probe whether hardware updates the PTE A/D bits by reading through an alias > + * mapping whose A and D bits are clear. Observing A set, even by a speculative > + * access, implies Svadu, as Svade only allows A to be set by software. > + * > + * Under Svade, the read raises a page fault instead, so use the extable to > + * handle it. This is an internal detail, which can be covered by an internal comment. > + */ > +static bool __init probe_hw_ad_update(void) > +{ > + vaddr_t va = FIXMAP_ADDR(FIX_MISC); > + pte_t *entry = &xen_fixmap[FIX_MISC]; > + bool a_set = false; > + > + ASSERT(!pte_is_valid(*entry)); > + > + /* > + * set_fixmap() can't be used, as pt_update_entry() always sets A and D. > + * > + * A and D belong to the PTE, not to the page, so a new PTE with A and D > + * clear can point to any RAM page, whatever its other mappings. Use the > + * first page of the Xen image, and map it read-only so that Xen can't be > + * corrupted through this alias. The function comment is mostly ok, but this one is misleading, not least because it talks about corruption despite this being a read operation.  All you need to say here is: /* Opencode set_fixmap() to intentionally leave A/D clear. */ > + */ > + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(_start)), pte_from_mfn(virt_to_mfn(_start)) > + PTE_VALID | PTE_READABLE)); > + flush_tlb_one_local(va); > + /* Read from the alias, handling pagefault */ > + asm_inline goto ( > + "1: lw zero, 0(%[va])\n" > + ASM_EXTABLE(1b, %l[out]) > + : > + : [va] "r" (va) > + : "memory" > + : out ); > + > + /* Order the load, and so its A bit update, before reading the PTE */ /* Check to see if hardware set A. */ > + RISCV_FENCE(r, r); > + a_set = read_pte(entry).pte & PTE_ACCESSED; > + > + out: It's better to name this label 'fault' because that's what happened to use it. What happens if you neither fault, and A doesn't get set?  Right now you'll report Svade despite there being no fault. You might or might not care to cover this case; that's up to the RISC-V maintainers as to how likely it is to encounter in real life. But, if you do want to handle it, then you want something like     asm goto (...);     if ( 0 )     {     fault:         got_fault = true;     }     ...     if ( !got_fault && !a_set )         panic("Neither Svade nor Svadu !?!\n"); The if (0) is a bit ugly but it's the only way to avoid needing a second label.   > + write_pte(entry, (pte_t){}); > + flush_tlb_one_local(va); > + > + return a_set; > +} > + > void __init riscv_fill_hwcap(void) > { > unsigned int i; > @@ -674,6 +723,28 @@ void __init riscv_fill_hwcap(void) > "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " > "wire up this platform's pause equivalent in cpu_relax()\n"); > > + /* > + * The privileged spec allows exactly two schemes for updating the PTE A > + * and D bits: > + * 1) hardware sets them on access and on write; > + * 2) accessing a page whose A and/or D bit is clear raises a page fault, > + * so that software can set them (ratified as Svade). > + * > + * Every implementation uses one of them, but may predate the extensions > + * and advertise neither. In that case, trust the hardware probe. > + */ > + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && > + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > + { > + bool hw_update = probe_hw_ad_update(); > + > + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, > + riscv_isa); > + printk(XENLOG_WARNING > + "Device tree advertises neither Svade nor Svadu, probed %s: add it to \"riscv,isa\"\n", > + hw_update ? "svadu" : "svade"); This is overly verbose, including details that absolutely shouldn't be the boot log. "Neither Svade nor Svadu in Device Tree - probed as %s\n" ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:25:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:25:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463349.1674237 (Exim 4.92) (envelope-from ) id 1xM4ai-0004lP-Q8; Wed, 28 Oct 2026 14:25:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463349.1674237; Wed, 28 Oct 2026 14:25: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 1xM4ai-0004lI-N1; Wed, 28 Oct 2026 14:25:24 +0000 Received: by outflank-mailman (input) for mailman id 1463349; Wed, 28 Oct 2026 14:25:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM4ah-0004l5-KS for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:25:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM4ah-007wCq-0w for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:25:23 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae205c9-e002-0a2a0a5209dd-0a2a4508d5ba-34 for ; Wed, 28 Oct 2026 15:25:22 +0100 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae205d2-f659-0a2a45080019-d155dd36bd02-3 for ; Wed, 28 Oct 2026 15:25:22 +0100 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48e0d1c095dso566898f8f.1 for ; Wed, 28 Oct 2026 07:25: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-48e3ecd35c2sm28250386f8f.39.2026.10.28.07.25.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 07:25: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=1793197522; x=1793802322; 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=Pt4R12krTVVQKTaxDhZs2VAib5e/yExqZczSnQuv+6U=; b=ObxB3zJXNkiYcxtSJD756+hnGQ0ayz4M3AuTQuORdEKKNsJf7ieE8ddE37/xZbFGwT cshDolkUSAM/nh/93XO40jwyzAsQeEUB2qTaCGjx65U2eFvYs85C+EzBeOtYkIHRwhoW OVI+CWPDQwwqRmPhlaS6fIWJHbGHtd56CxjDP/rj1JVq2FysVElwas1ZNK44WmoRCtp8 y9zknbbXnNjnxSrcpKkC825fcRDFisIHjPfvPSROJ9XdRaLeaX9FwEmHJfWYwX5MsSsD qSTbDJJriOvsnLHId0wmYz4SwP26b/7uc+slqiCOoz+l96jgtt4oGY0bcBG/YP8ZNxQJ FMyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793197522; x=1793802322; 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=Pt4R12krTVVQKTaxDhZs2VAib5e/yExqZczSnQuv+6U=; b=dmb+4r29rmYldR8i5l2UY1wNQ1zx7o7iYwqldzpQ0kHVyRlRsARI3jR1Kx6r/1EO1I 8JTRGQ7MLo3gabiu+WvBblq66C564Fp6NpxbMcx5qHkAcKo9QKw31dd1mRrqGzZXgqtI j/fx0l2C4ZkCp95Z5QvdxuEcl1jLLn1IluJp73MkHaLBS6672t+U33xyTAjqIhyAc9n/ 2vrdPSAFdCXfwxnYIuSkmd4XbzjAj3zYBiGOyqL9du/F34VdDEH/T5nUeoGuzGmVxnLD J4pAdtP1bCqJYuYJvbZFhWfXF2oWD+5atWbuTuIW5HwfiPU+sdsJWhwpZeUjAl3HViZf 7+qQ== X-Forwarded-Encrypted: i=1; AKwUvBxyzxhP6JJgpBoCmCUQZpunF9bjJO4W7unic9N5b2VK1K3ukoseeSgksanrTcUq8qtB8ki4aDiJWOI=@lists.xenproject.org X-Gm-Message-State: AFq9FYIbq66rpH91pMbXk+IjKvbkWkNfNh6ZSMR1Mk+EaXxxckdJHZnm dcUAhikQmPdfCOwujNv8i6WdZiCWBEbziFscZUyEkFN02gJITBiNjq07aqs8z9dn1Cw1U+ZN9Cp O+GbVsA== X-Gm-Gg: AYBFou3TDf07gJ+Ase93YZZlNc2ZgtWdq0QBWH+ndgy7gknGPULcMlQcbAxiUa6C0y3 uvcD1+fekEUhghhFUz/MhRm9dV4uuCYTsTCIqxu0Gi88/mMQYT2tr16kqRsscQHeXezGPqzWvUq aBNjnGXidcS69gwHMbYUvvm51YD2OPdd+7pH2Hj1AMzqG2JAK3YcNRgJZiEoTKlHdsUoag8Wf8z Rjt2dZpCjyz30LqbcpjbUewQ3FHIQoOn9H7iX1p9VdmaO31kwneO1qPKZJDIbWoj42/vfByD4fW 7VwYPTnKudIwbVrv6NDLjZkTjjxrgkezI4KwmbQjzCNm7UZQ/o9O/AYU4NCypXbzv2PDbSaF2BI 1per5Raq69wA5zSU/X6hknvf+BebPUTxw56Pz3CVcPkCOvTUsLpJ8hfzudBiV+fUQOfiD5+/kvq P73y+mLRMOxfw+1EwzCjmexnDYwj58ZFRgu0QCpTr0Y5EfBrql6AeWflHjteyGvT2D/EwSxqzVv ktU77eE+mIFfZWxVtBS85dKDX7Kp/TaG8nSnKWzQc25fk3sLwPhDO54vqAdCFL+XCHYlPHnEWMI c5X54TpantGBTVXO+dlC1jIIetf3u6F+FI9nRhOcVB+fqsRZPdJDTgzllSvD4l7j+q02ys017ok eN9kW0z8eUd+JIAaq X-Received: by 2002:a05:6000:29cf:b0:48d:ea67:79d4 with SMTP id ffacd0b85a97d-48e5d311f62mr4360163f8f.53.1793197522096; Wed, 28 Oct 2026 07:25:22 -0700 (PDT) Message-ID: <65d41464-6c65-40be-8279-acdececf53c5@suse.com> Date: Wed, 28 Oct 2026 15:25:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 5/5] vpci: add SR-IOV support for DomUs To: Mykyta Poturai Cc: Stewart Hildebrand , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <8823cd01334978baea19515c35068c789d4568bb.1792072426.git.mykyta_poturai@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: <8823cd01334978baea19515c35068c789d4568bb.1792072426.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1793197522-CCF4F87B-7BFB3BB2/10/78276251493 X-purgate-type: spam X-purgate-size: 3583 On 15.10.2026 16:08, Mykyta Poturai wrote: > --- a/xen/drivers/vpci/sriov.c > +++ b/xen/drivers/vpci/sriov.c > @@ -79,19 +79,80 @@ int vpci_vf_init_header(struct pci_dev *vf_pdev) > const struct pci_dev *pf_pdev; > int rc = 0; > uint16_t ctrl; > + unsigned int sriov_pos; > > ASSERT(rw_is_write_locked(&vf_pdev->domain->pci_lock)); > ASSERT(vf_pdev->info.is_virtfn); > > pf_pdev = vf_pdev->pf_pdev; > ASSERT(pf_pdev); > + sriov_pos = pf_pdev->vpci->sriov->pos; Can't this move ... > rc = vf_init_bars(vf_pdev); > if ( rc ) > return rc; ... here? > - ctrl = pci_conf_read16(pf_pdev->sbdf, > - pf_pdev->vpci->sriov->pos + PCI_SRIOV_CTRL); > + ctrl = pci_conf_read16(pf_pdev->sbdf, sriov_pos + PCI_SRIOV_CTRL); > + > + if ( IS_ENABLED(CONFIG_HAS_VPCI_GUEST_SUPPORT) && > + pf_pdev->domain != vf_pdev->domain ) > + { > + struct vpci_bar *bars = vf_pdev->vpci->header.bars; > + /* > + * A VF's Vendor and Device ID registers read as 0xffff. The guest has > + * no PF to synthesise them from, so take the vendor from the PF and > + * the device from its SR-IOV capability. > + */ > + uint16_t vid = pci_conf_read16(pf_pdev->sbdf, PCI_VENDOR_ID); > + uint16_t did = pci_conf_read16(pf_pdev->sbdf, > + sriov_pos + PCI_SRIOV_VF_DID); > + > + rc = vpci_add_register(vf_pdev->vpci, vpci_read_val, NULL, > + PCI_VENDOR_ID, 2, (void *)(uintptr_t)vid); This effectively open-codes _p(). > + if ( rc ) > + return rc; > + > + rc = vpci_add_register(vf_pdev->vpci, vpci_read_val, NULL, > + PCI_DEVICE_ID, 2, (void *)(uintptr_t)did); Same here. > + if ( rc ) > + return rc; > + > + /* Hardcode multi-function device bit to 0 */ > + rc = vpci_add_register(vf_pdev->vpci, vpci_read_val, NULL, > + PCI_HEADER_TYPE, 1, > + (void *)PCI_HEADER_TYPE_NORMAL); And this works only because PCI_HEADER_TYPE_NORMAL happens to be 0. Imo _p() wants using here as well. > + if ( rc ) > + return rc; > + > + rc = vpci_add_register(vf_pdev->vpci, vpci_hw_read32, NULL, > + PCI_CLASS_REVISION, 4, NULL); > + if ( rc ) > + return rc; How is this SR-IOV-related? > + for ( unsigned int i = 0; i < PCI_SRIOV_NUM_BARS; i++ ) > + { > + switch ( pf_pdev->vpci->sriov->vf_bars[i].type ) > + { > + case VPCI_BAR_MEM32: > + case VPCI_BAR_MEM64_LO: > + case VPCI_BAR_MEM64_HI: > + rc = vpci_add_register(vf_pdev->vpci, vpci_guest_mem_bar_read, > + vpci_guest_mem_bar_write, > + PCI_BASE_ADDRESS_0 + i * 4, 4, &bars[i]); > + if ( rc ) > + return rc; > + break; > + > + default: > + rc = vpci_add_register(vf_pdev->vpci, vpci_read_val, NULL, > + PCI_BASE_ADDRESS_0 + i * 4, 4, > + (void *)0); Unlike above here I'm less certain - we deliberately use this pattern elsewhere already. Yet maybe those would best be switched to _p() as well. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:26:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:26:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463357.1674246 (Exim 4.92) (envelope-from ) id 1xM4c5-0005Ff-2e; Wed, 28 Oct 2026 14:26:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463357.1674246; Wed, 28 Oct 2026 14: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 1xM4c4-0005FW-Vv; Wed, 28 Oct 2026 14:26:48 +0000 Received: by outflank-mailman (input) for mailman id 1463357; Wed, 28 Oct 2026 14:26:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM4c3-0005FN-OX for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:26:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM4c2-007Ion-Pz for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:26:46 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae20614-2eae-0a2a0a5409dd-0a2a4506a74c-30 for ; Wed, 28 Oct 2026 15:26:46 +0100 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae20626-195a-0a2a45060019-d155dd29dd6d-3 for ; Wed, 28 Oct 2026 15:26:46 +0100 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48e20edd106so808055f8f.1 for ; Wed, 28 Oct 2026 07: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-48e3ebd47basm31456080f8f.32.2026.10.28.07.26.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 07: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=1793197606; x=1793802406; 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=Hs+VEOdUNLzlW8kuG1J2791RhboW1NlX6I/i0/VZM8I=; b=RiwGYkbulNeSUvRbaOYpYda6KM/XhBMPZOhcnnHGuYNCtUrd5K5R86B4k/u1i3ObeQ /C0Glr+xzD5sfB+iunob1RFVw2Xz9UPLDCm9gj3mSrkNH4EZxvN5ZJ842vPE6Sp2RrLI ynkMlRZoQROF87kOkGttcda+chSJfRSYPIhV38wO8cd0w2hyAu0AWMSNDDf+XtO5kx/A 6+ollQ2cEtBY93zlx/RL+TpTQKN+/K8JcbB55tK4R705TsSNw8o+LRjlWYeC1dtH5xAR QAv9G/RVLlAAe5bMrphufxR3vi9cznT/aWeAHj1q0Ryew8DfEfK+8iXSbjOG1odJ4rlb XUnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793197606; x=1793802406; 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=Hs+VEOdUNLzlW8kuG1J2791RhboW1NlX6I/i0/VZM8I=; b=1qYSpGAJEqjUcaDtzyExqiwG1j1uM1V+Cr32LP14xRGOZ5o7dYCvCEB0fTfoQEYYeJ KwhJnafjiTyrNVJpF8WxolJ6qmaCAeHlSCDbQpy2P7nxYSBaYDAtq17Kjm10Oc0q8PqA 4PieJ3S+Bpu5J0I7I5g/3aaZnpCGNDVstw5ode2/6rD+9eOcQ16wWDdLSD3JVmfJliEe vqv+sQLM5sKY4OiXg4EmQ/KPpwwxvQH61jXpULT2Ict/l4TGoo+AFumYXNwLAyOP23jO zPU9Ccb1ptv27UPUtakpJdyBbCMQkpf26nnWhkSVWmghhp5/yFAVsBTuTmNM7NVDaK5z Orug== X-Forwarded-Encrypted: i=1; AKwUvBxtpPupAzWeaC3hb0A5NFJ/HBkR3JqN3s1558wfvFgp+dFWNJISl4ZNNk8gN3hS4IYllBgs/m+QH9M=@lists.xenproject.org X-Gm-Message-State: AFq9FYIX3zdG17OP3Tebwf2LuVuOlu5oRxpd91SAbfKfDfOLj8mYD7HK 4DXhjC+4wrpf49hB8PI3moPkalHMUDZHPnrO0VupVI1G1vRpQUscbFQn9onXUZeiWg== X-Gm-Gg: AYBFou1tayY5TeZJNHFHhgO4VzdaAebML7ltmPX/WPAOINjtacUlux9/no332KZkjHo OIa5o/oqeU9bjsvbV0EpydBre/VEtGvXQK8JrOl69rHCSpbU7Jub+c8rJag2Y66dfvpGohITF9g fwHX5+AYwGxusMepE5/uYGHBGIB5DbwhYyzdKSSb/SYmKQfh+G9xsaD0fhoZG0gYSIMwv84HUjw fzSaC8+Mumr3EnhwDXEYzSc9AoK1PjQz5b7NKDMT1rxkSpLZFQkRoIYDjSb8jv/mjbdOvid33s5 7G+EcCoR88PNFk382+PJCS3RJEl+oHolugtt2GSpHwx463KH3lTp5Y+v/QXdotmVuYbI4oFxWW4 /0qXoircf3jVlyibEf5GHxo+AmA9Avc+itRUq1QunVWihnRWNhwGgNww4U5UKUqgJ3mLP1DDPDK HoMXEWHW+JEhAxWmd3CFvFEGsPVp2bllZyUh1cIJ8p0I4lPQjZI5BZAbO09Vgfoq3Dy7yVzDYK/ ZgwC1sQ8TmJCnLVFYhOxu1SMRyOZtP6X6Qrzv2oozat5nbGG/SyEKXREoWFEIYB3xOB2ozXNqMO YW8MsbD2z6hfjvlJQA2qngIf/WxKsp4Mc37xBU3jJLYAZUGrNdnqUM2V/iPkc5Lql2Bz1SDildC rWU3rZX9xLtSZ/XdO X-Received: by 2002:a05:6000:1449:b0:48c:67d6:a87a with SMTP id ffacd0b85a97d-48e5d5a4385mr5818050f8f.32.1793197605977; Wed, 28 Oct 2026 07:26:45 -0700 (PDT) Message-ID: <56a5e051-b8f5-440e-bde6-604dbe575991@suse.com> Date: Wed, 28 Oct 2026 15:26:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Baptiste Le Duc Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang , xen-devel@lists.xenproject.org, Oleksii Kurochko References: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> <19bc2130-aa66-495e-8f43-b1ce263142fe@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: <19bc2130-aa66-495e-8f43-b1ce263142fe@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1793197606-1FACA77B-16278B3F/10/78276251493 X-purgate-type: spam X-purgate-size: 2256 On 28.10.2026 15:21, Oleksii Kurochko wrote: > > > On 10/28/26 2:05 PM, Baptiste Le Duc wrote: >> p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when >> RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. >> >> The privileged spec allows exactly two schemes for updating the PTE A and D >> bits: hardware sets them on access and on write, or accessing a page whose >> A and/or D bit is clear raises a page fault so that software can set them >> (ratified as Svade). Every implementation uses one of them, but platforms >> designed before Svade and Svadu were ratified, such as the HiFive Premier >> P550, may advertise neither. >> >> Trust the device tree when it advertises Svade and/or Svadu, as for any >> other extension. When it advertises neither, probe the scheme in effect >> and record the matching extension in riscv_isa, so that such device trees >> can be used as-is, and warn naming the extension to add to "riscv,isa". >> >> Introduce probe_hw_ad_update(): alias the first page of the Xen image >> read-only through the FIX_MISC fixmap slot with its A and D bits clear, >> then load from it under an exception table fixup. Hardware updating is in >> effect if the load completes and the A bit is then set. The probe fails >> otherwise, whether the load faults or completes leaving the A bit clear. >> The A bit being set by a speculative access still implies Svadu, as Svade >> only allows A to be set by software. >> >> Add Svadu to the known ISA extensions so it can be told apart from Svade. >> The comment above the enum asks for new extensions to go at the bottom to >> avoid shuffling, a leftover from Linux where the IDs were macros with >> explicit values. Nothing depends on the enum values, so have the comment >> say that multi-letter extensions follow the order of riscv_isa_ext[]. >> >> Assisted-by: Claude:claude-opus-5-5 >> Signed-off-by: Baptiste Le Duc >> --- >> Changes since v9: > > Nit: something wrong with version numbering. (in the case of v11 would > be nice to fix). > > Changes itself LGTM: > > Reviewed-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:33:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:33:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463366.1674254 (Exim 4.92) (envelope-from ) id 1xM4iP-0007Oq-Q2; Wed, 28 Oct 2026 14:33:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463366.1674254; Wed, 28 Oct 2026 14:33: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 1xM4iP-0007Oj-N4; Wed, 28 Oct 2026 14:33:21 +0000 Received: by outflank-mailman (input) for mailman id 1463366; Wed, 28 Oct 2026 14:33:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM4iO-0007Od-DG for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:33:20 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xM4iO-00000000f29-11PA; Wed, 28 Oct 2026 14:33: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.98.2) (envelope-from ) id 1xM4iN-000000079qK-2ols; Wed, 28 Oct 2026 14:33: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=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=M0J2osm8lTrtdywm+8LmBt91vfub2jaGrIxOZbJgrM0=; b=uKz1fMBgG92QNHv5rZTDvjpgWo FgFaJY8M8qIapHEQVEsrb1RiUmHzBf9yBDZmMEgkJ11zlG0621kCjBSaXVj6FeyMvpfFkLs6yP/Ai aeeE7YBy8ACIzMDXGKp0b0wtQG031AXb6qi4+wh7aotwxIlUfGogva3dRrShL+7Vk4ek=; Date: Wed, 28 Oct 2026 15:33:13 +0100 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 v2 1/5] x86/pass-through: alter locking around pt_irq_{create,destroy}_bind() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Wed, Sep 30, 2026 at 01:42:29PM +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(). > > It's merely msixtbl_pt_{,un}register() which require the global or per- > domain PCI lock held. Switch to using the latter, which is also sufficient > to acquire in read mode. While strictly speaking this is needed only for > PT_IRQ_TYPE_MSI, keep it being unconditional. In vioapic_hwdom_map_gsi() > also unlock earlier. > > Signed-off-by: Jan Beulich > --- > v2: Replace locking rather than dropping it altogether. > > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -636,9 +636,9 @@ long arch_do_domctl( > ret = -EPERM; > else if ( is_iommu_enabled(d) ) > { > - pcidevs_lock(); > + read_lock(&d->pci_lock); > ret = pt_irq_create_bind(d, bind); > - pcidevs_unlock(); > + read_unlock(&d->pci_lock); > > if ( ret < 0 ) > printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for %pd\n", > @@ -670,9 +670,9 @@ long arch_do_domctl( > ret = -EPERM; > else if ( is_iommu_enabled(d) ) > { > - pcidevs_lock(); > + read_lock(&d->pci_lock); > ret = pt_irq_destroy_bind(d, bind); > - pcidevs_unlock(); > + read_unlock(&d->pci_lock); > > if ( ret < 0 ) > printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for %pd\n", > --- a/xen/arch/x86/hvm/vioapic.c > +++ b/xen/arch/x86/hvm/vioapic.c > @@ -197,8 +197,9 @@ static int vioapic_hwdom_map_gsi(unsigne > return ret; > } > > - pcidevs_lock(); > + read_lock(&currd->pci_lock); > ret = pt_irq_create_bind(currd, &pt_irq_bind); > + read_unlock(&currd->pci_lock); I think you need to extend the ->pci_lock'ed region so it also covers unmap_domain_pirq(), otherwise the ASSERT_PDEV_LIST_IS_READ_LOCKED() in there will trigger? IE: the read_unlock() needs to be where the pcidevs_unlock() is? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:37:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:37:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463371.1674264 (Exim 4.92) (envelope-from ) id 1xM4m3-0007v5-8K; Wed, 28 Oct 2026 14:37:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463371.1674264; Wed, 28 Oct 2026 14:37: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 1xM4m3-0007ux-5E; Wed, 28 Oct 2026 14:37:07 +0000 Received: by outflank-mailman (input) for mailman id 1463371; Wed, 28 Oct 2026 14:37:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM4m1-0007uq-D2 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:37:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM4m0-002fHS-JG for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:37:04 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae20888-bab6-0a2a0a5309dd-0a2a450bb2f6-10 for ; Wed, 28 Oct 2026 15:37:00 +0100 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2088c-b7e8-0a2a450b0019-d1558034d92b-3 for ; Wed, 28 Oct 2026 15:37:00 +0100 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a35db1f202so8255505e9.3 for ; Wed, 28 Oct 2026 07:37: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 5b1f17b1804b1-4a977539ef8sm50988715e9.0.2026.10.28.07.36.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 07:36: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=1793198220; x=1793803020; 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=9PNJFj8bJ6k//jnvVlqtePr374ELc1J50WDMx1DULyA=; b=OJu7b4Wu5qqFd//aDO4WNWH6RgHmYUNyAgOiLyetnYdbJeoBurr6OZeeSBMGbzMOB2 NsijziYeUZ4eiSy41C5afM8DKtpTs3N1RpzpLsl3D5UeVyen+Eo0fJif+rRwGR7uUanU OJW+GRlE/dFJClk4hkZ6fRMxsZp5OVv8YxSmKPjrDgDCE7cvZ3U1ctGn0+WCi2Pv62dR Wq6lDy62Eqzb6vklJf4i3g97rd1jr6hU0U9cqAl68eimJ/NlAatgnd5/6Jtul/Ml+6PX UEALB3a5AnJHXUUwwschANV9KJz/zsdcMw2gt9+AYUtZ/zIuv2ehZ2a677w0OrkPBQHO AOcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793198220; x=1793803020; 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=9PNJFj8bJ6k//jnvVlqtePr374ELc1J50WDMx1DULyA=; b=zWCyPy9WSjiKrvR/PyjWBh5edZkd5FoN71j8Rn2D4umBnCrgCmH+QN1AfL0AUvp+ru u/OZBrcAJa8ceMGG3OukMs5cDcophoIgddIPLWl8igfksRhcCEKHYvnIJ55gBatrZFWz kWRORplWA/0cucLHnDsN+plEs8HGqVKYo7QOAeddHRSm/w3r0s83j9hQ15NmxxqYuPC8 /EUkUeMQi+FykDh61ohDggHU3FB2MjgsSBnffI8zdrN88ddktKx09jRwaXi/Pt0Nhjxe hAdaWE8gyHMqMYXp+E0JybazBE9Has4PC5IYB4LE7RMZC/BadaGh44p67BkTrICEq2A4 +UWA== X-Forwarded-Encrypted: i=1; AKwUvBzEkGyqQryqkrDH30cdLpn+mh5Ja8wl393zXLqs8SL5l2tpZf1WS8aERVLjtB0hRMiGhNSJY8Mo4U0=@lists.xenproject.org X-Gm-Message-State: AFq9FYIdc5gmd92RpDWgRj2tkWaoXYrlIsAh4A0Vccs25Zou2VuKcVIk Otz4nRSfNEY6l/2ZgHUIuzG89PLOg4HWwMMHGwtHslubadz8Pn7URSdcjhk/5jLIYg== X-Gm-Gg: AYBFou1CBpknNkAx1D5d89lhOy4ibxO7xtelWzRhFchazM59wVcA/ALjC+MzgLlseKc T5hBDco5DbyV7nkzenHLoRMmZZ9vs8c8fTUdEIMRNQ/PKVCDCaoed31rfpShKZksgJGJCu/GSut NcNHo43zm6+e/fJ8x3VyOIsPCecldffj9hHfxmCPLJNrTkxQwHtWdOgoPxOilROIw3KWaqTzWNS lyNYBS8YX9hFFshpaJT0cpWegYWS2VetjNFpK3xXu3dZJ/1Kui/F2cXz/qAar+517CobJJs6hwv /vjBl7eUtIetTxG2IMzuyw7IeDvTjRY24nhO6M2ziQOG5F2fTTdeNwZZWAybgnSOYU8dQPzcub4 0Hlc0NR5Z8Oroj5FUUu490XSMP8QGR+ssLlwBPysSXzqMrMJKyCTyQvgfmvqaqYZ1xWua8mKb4y 2zqv2QF3dnNWTPwkMkqwuJ4t+eYhjwcbe5v6THQXjEdlWv29PqGyRJGLM074EQHX6SMNXkOQIvU ijgnX5Zh7qX6v8hVxLtwtTibHoqFxXyh6atAjbPjMyvfqV6ZOoYor0HtUdCaB4ZfnzUnIw0Cfsr pqejYKcLyiJM0OsBTRFRaDskjDPEX9f9ElwHo13DTIpaPgNJ+ifAMyPMRx5HLWuiiVbHtaFjO7t F5ECcMBsQ9ExLkRM9 X-Received: by 2002:a05:600c:3e0a:b0:4a0:1c0e:b057 with SMTP id 5b1f17b1804b1-4a9640f1fbdmr58548995e9.4.1793198220201; Wed, 28 Oct 2026 07:37:00 -0700 (PDT) Message-ID: Date: Wed, 28 Oct 2026 15:36:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang , Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> <35fa29d5-fafc-43da-a5a5-72df8f367e3c@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: <35fa29d5-fafc-43da-a5a5-72df8f367e3c@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793198220-A84CB9EA-4A529E9B/10/78276251493 X-purgate-type: spam X-purgate-size: 3507 On 28.10.2026 15:24, Andrew Cooper wrote: > On 28/10/2026 1:05 pm, Baptiste Le Duc wrote: >> diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c >> index 3d5bbd2228..83d3bc5ddc 100644 >> --- a/xen/arch/riscv/cpufeature.c >> +++ b/xen/arch/riscv/cpufeature.c >> @@ -630,6 +632,53 @@ const char *get_guest_isa_str(void) >> return guest_isa_str; >> } >> >> +/* >> + * Probe whether hardware updates the PTE A/D bits by reading through an alias >> + * mapping whose A and D bits are clear. Observing A set, even by a speculative >> + * access, implies Svadu, as Svade only allows A to be set by software. >> + * >> + * Under Svade, the read raises a page fault instead, so use the extable to >> + * handle it. > > This is an internal detail, which can be covered by an internal comment. > >> + */ >> +static bool __init probe_hw_ad_update(void) >> +{ >> + vaddr_t va = FIXMAP_ADDR(FIX_MISC); >> + pte_t *entry = &xen_fixmap[FIX_MISC]; >> + bool a_set = false; >> + >> + ASSERT(!pte_is_valid(*entry)); >> + >> + /* >> + * set_fixmap() can't be used, as pt_update_entry() always sets A and D. >> + * >> + * A and D belong to the PTE, not to the page, so a new PTE with A and D >> + * clear can point to any RAM page, whatever its other mappings. Use the >> + * first page of the Xen image, and map it read-only so that Xen can't be >> + * corrupted through this alias. > > The function comment is mostly ok, but this one is misleading, not least > because it talks about corruption despite this being a read operation.  I think though that the intent of the comment isn't limited to the read, but also to possible (bogus) further use of that PTE. > All you need to say here is: > > /* Opencode set_fixmap() to intentionally leave A/D clear. */ Imo the seemingly arbitrary choice of which page to map can do with mentioning. >> @@ -674,6 +723,28 @@ void __init riscv_fill_hwcap(void) >> "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " >> "wire up this platform's pause equivalent in cpu_relax()\n"); >> >> + /* >> + * The privileged spec allows exactly two schemes for updating the PTE A >> + * and D bits: >> + * 1) hardware sets them on access and on write; >> + * 2) accessing a page whose A and/or D bit is clear raises a page fault, >> + * so that software can set them (ratified as Svade). >> + * >> + * Every implementation uses one of them, but may predate the extensions >> + * and advertise neither. In that case, trust the hardware probe. >> + */ >> + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && >> + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) >> + { >> + bool hw_update = probe_hw_ad_update(); >> + >> + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, >> + riscv_isa); >> + printk(XENLOG_WARNING >> + "Device tree advertises neither Svade nor Svadu, probed %s: add it to \"riscv,isa\"\n", >> + hw_update ? "svadu" : "svade"); > > This is overly verbose, including details that absolutely shouldn't be > the boot log. > > "Neither Svade nor Svadu in Device Tree - probed as %s\n" Some shortening is certainly worthwhile here, but omitting the hint what the user can do about the situation is imo unhelpful. Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:38:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:38:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463378.1674272 (Exim 4.92) (envelope-from ) id 1xM4nZ-000089-I0; Wed, 28 Oct 2026 14:38:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463378.1674272; Wed, 28 Oct 2026 14:38: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 1xM4nZ-00007x-F9; Wed, 28 Oct 2026 14:38:41 +0000 Received: by outflank-mailman (input) for mailman id 1463378; Wed, 28 Oct 2026 14:38:40 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM4nY-00007l-IS for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:38:40 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xM4nY-00000000fBr-2T3W; Wed, 28 Oct 2026 14:38: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.98.2) (envelope-from ) id 1xM4nY-00000007NCK-0HNw; Wed, 28 Oct 2026 14:38: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=oS10hp55OsDF8FwJ9DfVx7C2kVo6HY5PR1aboUwnmk4=; b=YDSGspc3d+6yO2ua2au6DdIbwP SKcO8EyAKG0/qmeWk0q+Q+6y/okrMnb02TKfIC7fV4J0WnFPjKZNlT5hSXmJDuHk1dmbCkvaQNZ8L 4yTsFCxrOCPJX0d+rD7IK2qsOdvnA89EEQjmgX6+wbT3KsWgbScacYLuIzh+GMBNfT+w=; Date: Wed, 28 Oct 2026 15:38:38 +0100 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/5] x86/vPCI: make better use of "pdev" in vpci_msix_arch_print() 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 30, 2026 at 01:43:34PM +0200, Jan Beulich wrote: > Move the declaration to function scope, so that not only the (so far) > immediately following spin_unlock() can make use of it, but also the > assertions at the top. Also add const, as the pdev itself isn't supposed > to be altered here. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 28 14:51:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 14:51:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463384.1674281 (Exim 4.92) (envelope-from ) id 1xM4zk-0003Rr-Ia; Wed, 28 Oct 2026 14:51:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463384.1674281; Wed, 28 Oct 2026 14: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 1xM4zk-0003Rj-FY; Wed, 28 Oct 2026 14:51:16 +0000 Received: by outflank-mailman (input) for mailman id 1463384; Wed, 28 Oct 2026 14:51:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM4zj-0003Ra-CW for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 14:51:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xM4zj-00000000fRy-1loB; Wed, 28 Oct 2026 14:51:15 +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.98.2) (envelope-from ) id 1xM4zi-00000007rlb-3m1w; Wed, 28 Oct 2026 14: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" 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=6H19WpD8PUT2zKNPeBfcDZ1hhv3Q7VZOYRatMv7zVwI=; b=i9jmBhRVxeXD7yzpC9TfN4QO6C E2gS9RbY/hmfyDmNjipOigO3JOzTpWIGlnbfbulydTXmL9/iBHawYXIL5QVGzzxyBUzSfaEoiOJux G6I3/WapGy45Vio+tsRBA4pBWPSrzREXsiH/Y789ul20CxqE04S1kjxe/9p97cNzO54s=; Date: Wed, 28 Oct 2026 15:51:12 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v2 5/5] x86/vMSI: avoid "goto" in msixtbl_pt_unregister() Message-ID: References: <3f19c5e9-d8d2-4752-99a1-b5115c3c862b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3f19c5e9-d8d2-4752-99a1-b5115c3c862b@suse.com> On Wed, Sep 30, 2026 at 01:43:59PM +0200, Jan Beulich wrote: > "goto" can be helpful in certain situations, yet where easily possible I > think it's better to avoid its use. With the re-arrangement also restrict > the scop of two of the local variables, and add const to one of them. > > No functional changed intended. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 28 15:21:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 15:21:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463407.1674290 (Exim 4.92) (envelope-from ) id 1xM5Sq-0000NV-Ke; Wed, 28 Oct 2026 15:21:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463407.1674290; Wed, 28 Oct 2026 15:21: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 1xM5Sq-0000NO-Hh; Wed, 28 Oct 2026 15:21:20 +0000 Received: by outflank-mailman (input) for mailman id 1463407; Wed, 28 Oct 2026 15:21:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM5Sp-0000NE-JJ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:21:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM5So-00D4XO-S1 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 16:21:18 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae212e7-2eae-0a2a0a5409dd-0a2a4505e89e-28 for ; Wed, 28 Oct 2026 16:21:18 +0100 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae212ee-4cb1-0a2a45050019-d1558029c4f5-3 for ; Wed, 28 Oct 2026 16:21:18 +0100 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a214af2076so9689775e9.0 for ; Wed, 28 Oct 2026 08:21: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-48e3ebd48eesm29084079f8f.30.2026.10.28.08.21.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2026 08:21: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=1793200878; x=1793805678; 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=uue9UFbI1pGC0zVUdWNlAr/MYFXAE7NAx74nWeMZ+U4=; b=fjd+XVnJQPwJydkAGl4v0IKbRWr+V+kxAchvZdE2Jf73XNyPnS578sbRY0tpr6hThv M73pcgzial70IdKnuyqiYhaTd27TEFKFbI81VU6CY8Usdry9QfQd0OWJo8Rv72a7R4ku d5jWi6wCjtwccNJ6dBmA+/REyLr1F/uMT9x3IHVwpoND36QdivKj/np6p77qG2qGSYGD mpobPqbxZeWBAYxxksO2A4x18IpeavBCj7vLfBnerbIBCLCCYYB2lLASna7OGfWkYAfn RoJmWD8F/ChTmf3EPIvvHgH/eRcaw19X28MQeFi8OG9MtqnYCY8jZ0Yyp8p9qt9lwOAW 1baw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793200878; x=1793805678; 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=uue9UFbI1pGC0zVUdWNlAr/MYFXAE7NAx74nWeMZ+U4=; b=XEfINX6PWDEnnTzIOTqG/+hOQaDDaHwlW1X5Zo9GYmyFgo1qJo049TJn7oj82Oyr3m LtvWNVtl4VAZh/Qw7Yyp/s4P0JCUmeiXkqOx8GC20BneEN6kQAotGGoVTKL+Ry9h/e09 45evynIeenxUbPkG9NGX3HfIYGDWv1NWPb3qavipBokNf+24qsMU+yQtQJwxidLgL0e0 kdlpGt9tZ7Dv22Can+btZFgKZA0ly271qyR8roWxNS8K4dBi4sUnbwOdyvoOZuCsj9ff 8jlutR1C8E6EeBr1lOyo5aeh/FCvNK+dnPjXFSOV86xCn1DNKsFsYqTO/EM1RIVvQbH7 fZ6g== X-Gm-Message-State: AFq9FYJzMX3mK2OoxP2NS1vO6SKlP6m3jo2/nVPCOJzedJUvcN7Zzj5L ToD79KHZqKffl8VkLGgbUspEvcSPUModUrUlA5KKSs5QBIqmFXClren/agy+QnQ8CIV804CDSm5 bfa+/FQ== X-Gm-Gg: AYBFou3UwQWDJ0IsuuQflnIn0WUJcg4kTJioWiL5msx4pMJvIESfVxpKgPStI7KLAib WUB7B4KoWje9pBX9+M+sMQ36PRAKB9C39kOj8TKG0+OGp8rB/S1ysSzwxQQyR/NgwOBNXGcAUhC 4X0EbMZCJie/KLP0Z/A0/AIew+ZJ0DjZxZ44GKopL0sq+ueckT5x7Qy+LAnwjnGeu8NTiwWFD5q sJ9NxXFJtp/hsO2DSfNeyKF/xkaWrbJ5CKHpFENEzscQC4oO9CFoopWlqhPm3Ury4kfWG8g79qb ro8uI556HjpH7Uqq2ZP2pIi8ghk2KoxvSxzpN8M2Z4uoGjiYCzJ1aAQ30EOVvb/IEPXyDBeC709 XcpT9/L4fzqck6GSspD+x5EvtTu5uo0yPe/U3xGUyo0+C57O/h8Sw6QtRKEMRTZENfCC09U1oQ+ 1t3TP+Pxcrc6A5qKcdrG3zMTWBTQQhT2wAWcLNJ4Yshtau/rY9Mv7hy4t/lE2wNxfk1S30bfsT1 oTE/MLc+qcoZzhuk6Ys+7heTgkkWUd43KtDYv+E5kvY8l59pAH6iHtICoytwqtbcixnOwpjQyK3 MO0fFfZnqHWmezk8pApzyMSLB1jw33xEX4BsuyDbeyuNCuiYR4meJE0nGPyloKPWZxwHYka9vUM WgecblVfpbvNObrxr X-Received: by 2002:a05:600c:3b24:b0:4a0:2391:6540 with SMTP id 5b1f17b1804b1-4a966e2b4damr55118725e9.25.1793200877920; Wed, 28 Oct 2026 08:21:17 -0700 (PDT) Message-ID: <3bd58966-9ca8-484f-acb8-cda56df565a6@suse.com> Date: Wed, 28 Oct 2026 16:21:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] x86/pass-through: alter 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: 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/1793200878-71AAF2A1-16AA4F88/10/78276251493 X-purgate-type: spam X-purgate-size: 993 On 28.10.2026 15:33, Roger Pau Monné wrote: > On Wed, Sep 30, 2026 at 01:42:29PM +0200, Jan Beulich wrote: >> --- a/xen/arch/x86/hvm/vioapic.c >> +++ b/xen/arch/x86/hvm/vioapic.c >> @@ -197,8 +197,9 @@ static int vioapic_hwdom_map_gsi(unsigne >> return ret; >> } >> >> - pcidevs_lock(); >> + read_lock(&currd->pci_lock); >> ret = pt_irq_create_bind(currd, &pt_irq_bind); >> + read_unlock(&currd->pci_lock); > > I think you need to extend the ->pci_lock'ed region so it also covers > unmap_domain_pirq(), otherwise the ASSERT_PDEV_LIST_IS_READ_LOCKED() > in there will trigger? IE: the read_unlock() needs to be where the > pcidevs_unlock() is? Oh, indeed. That would only be an issue if an error arose, so it's clear why I didn't hit that assertion. This being the only change (which I've made locally) necessary for the entire series - shall I re-send, or would you mind giving an ack for the patch with said adjustment made? Jan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 15:29:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 15:29:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463417.1674300 (Exim 4.92) (envelope-from ) id 1xM5aj-0001Fs-FL; Wed, 28 Oct 2026 15:29:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463417.1674300; Wed, 28 Oct 2026 15:29: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 1xM5aj-0001Fl-Cb; Wed, 28 Oct 2026 15:29:29 +0000 Received: by outflank-mailman (input) for mailman id 1463417; Wed, 28 Oct 2026 15:29:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM5ai-0001FV-9F for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:29:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM5ah-00D61E-D7 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 16:29:27 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae214c5-8faa-0a2a0a5109dd-0a2a4506a774-36 for ; Wed, 28 Oct 2026 16:29:27 +0100 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 6ae214d6-195a-0a2a45060019-b9ff1c23a401-3 for ; Wed, 28 Oct 2026 16:29:27 +0100 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 1a1832157c8000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 15:29:22 +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 DCFEB81EBC; Wed, 28 Oct 2026 16:29:21 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=AkOazJHQhB9+bxoTCgC7OA+fEuZePPNb0oVoF8C2Vxk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=reH9KrDjEn0Pos2r6M+fd9NrayRtIMkn25SFVChxRBs6IHvhhGEnHNXjdCentNB29bmIuPXYT eDn5WjmyoDmAAGLUUXSiEkvQywkLgbu48jHeA6RbMCwTVc3cvfyko8oJ9BrjR2gNYc2yZSeteg4 IAX2bb71h9Ebe8H460zUN6Rj8eMxGxBfCRxUQIst+I8IRdI5b6HoqGidEDTcDKon5ZFcilYsG4s 0zwuTnuZzFbbtQrZ3S04qONmcn2rfcGVTFumV4VYnt6Jc6S2+KtMlm8xkrEmfGz1ogNbNFh+BzP PWHDel36OaUX/C8BZt7464VZIx1Iqb+fRUNefIrOU+ow== X-Zone-Loop: a870c813c873843fa58cb386ec14fab8d1c12c4825d9 x-campaign-type: default x-transaction-id: 710c6623-2d23-4123-aece-1ea214b9f65a x-swg-uid: 01-97c94065-dd95-427e-b052-a36ea58e307d X-Mailer: Sweego Message-ID: <1793201362.8631fc262581453bbf619ec5b2062170.1a1832157c8000f79f@vates.tech> x-swg-bid: 1793201362.8631fc262581453bbf619ec5b2062170.1a1832157c8000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 16:29:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/9] tools/libs/guest: stop compressing PAGE_DATA when it stops paying off To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-6-marcus.granado@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: <20261020200238.1815766-6-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0swmmymgrhGDFRFyu0Dj8vOG" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793201362089 X-purgate-ID: tlsNG-16d1c6/1793201367-FEC7777B-1B1A667A/0/0 X-purgate-type: clean X-purgate-size: 14406 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0swmmymgrhGDFRFyu0Dj8vOG Content-Type: multipart/mixed; boundary="------------EMH06o0RrD6NGMvLddUB9s0K"; protected-headers="v1"; hp="clear" Message-ID: Date: Wed, 28 Oct 2026 16:29:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/9] tools/libs/guest: stop compressing PAGE_DATA when it stops paying off To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-6-marcus.granado@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: <20261020200238.1815766-6-marcus.granado@citrix.com> --------------EMH06o0RrD6NGMvLddUB9s0K Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowNSwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g V2hlbiBMWjQgY29tcHJlc3Npb24gaXMgaW4gdXNlLCB3cml0ZV9iYXRjaCgpIGNvbXByZXNz ZXMgdGhlIHBhZ2UgZGF0YQ0KPiBvZiBldmVyeSBiYXRjaCB1bnRpbCB0aGUgZW5kIG9mIHRo ZSBzYXZlLCB3aGF0ZXZlciB0aGUgcmVzdWx0LiAgRm9yIGENCj4gZ3Vlc3Qgd2hvc2UgbWVt b3J5IGhhcmRseSBjb21wcmVzc2VzLCB0aGlzIHNwZW5kcyBDUFUgYXQgYm90aCBlbmRzIGZv cg0KPiBsaXR0bGUgb3Igbm8gcmVkdWN0aW9uIG9mIHRoZSBzdHJlYW0uDQo+IA0KPiBUb3Rh bCB0aGUgcGFnZSBkYXRhIGJ5dGVzIGJlZm9yZSBhbmQgYWZ0ZXIgY29tcHJlc3Npb24gb3Zl ciBlYWNoDQo+IHByZWNvcHkgaXRlcmF0aW9uLCBjb3VudGluZyBhIGJhdGNoIHNlbnQgdW5j b21wcmVzc2VkIGFzIG5vIHNhdmluZy4gIElmDQo+IGFuIGl0ZXJhdGlvbidzIHRvdGFsIGFm dGVyIGNvbXByZXNzaW9uIGlzIDkwJSBvciBtb3JlIG9mIGl0cyB0b3RhbA0KPiBiZWZvcmUs IHN0b3AgY29tcHJlc3NpbmcgZm9yIHRoZSByZXN0IG9mIHRoZSBzYXZlLg0KPiANCj4gVGhl IGNoZWNrIHJ1bnMgaW4gc2VuZF9tZW1vcnlfbGl2ZSgpIGF0IHRoZSBlbmQgb2YgZWFjaCBw cmVjb3B5DQo+IGl0ZXJhdGlvbi4gIEEgbm9uLWxpdmUgc2F2ZSAoeGNfZG9tYWluX3NhdmUo KSB3aXRob3V0IFhDRkxBR1NfTElWRSkgaGFzDQo+IG5vIHByZWNvcHkgaXRlcmF0aW9ucywg c28gaXQgbmV2ZXIgc3RvcHMgY29tcHJlc3NpbmcuDQo+IA0KPiBUaGUgOTAlIHRocmVzaG9s ZCBpcyBhIGhldXJpc3RpYzsgYSBwb29yIGNob2ljZSBjb3N0cyBDUFUgb3IgYmFuZHdpZHRo LA0KPiBuZXZlciBjb3JyZWN0bmVzcy4gIExvZywgYXQgaW5mbyBsZXZlbCwgdGhlIHJhdGlv IG9mIGVhY2gganVkZ2VkDQo+IGl0ZXJhdGlvbiwgdGhlIGRlY2lzaW9uIHRvIHN0b3AgYW5k IGEgc3VtbWFyeSBvZiB0aGUgYmF0Y2hlcyBzZW50IHdoaWxlDQo+IGNvbXByZXNzaW9uIHdh cyBvbi4NCj4gDQo+IFN1Z2dlc3RlZC1ieTogRWR3aW4gVMO2csO2ayA8ZWR2aW5AdGFyaWRl cy5jb20+DQo+IEFzc2lzdGVkLWJ5OiBDbGF1ZGU6Y2xhdWRlLW9wdXMtNS01DQo+IFNpZ25l ZC1vZmYtYnk6IE1hcmN1cyBHcmFuYWRvIDxtYXJjdXMuZ3JhbmFkb0BjaXRyaXguY29tPg0K PiAtLS0NCj4gDQo+IE5vdGVzOg0KPiAgICAgIENoYW5nZXMgaW4gdjI6DQo+ICAgICAgLSBX YXMgdjEgNC82LCAiYWRhcHRpdmVseSBkaXNhYmxlIExaNCBvbiBwb29yIGNvbXByZXNzaW9u IHJhdGlvIi4NCj4gICAgICAtIEEgYmF0Y2ggc2VudCB1bmNvbXByZXNzZWQgY291bnRzIGFz IG5vIHNhdmluZzsgdjEgY291bnRlZCBpdHMNCj4gICAgICAgIGNvbXByZXNzZWQgc2l6ZS4N Cj4gDQo+ICAgdG9vbHMvbGlicy9ndWVzdC94Z19zcl9jb21tb24uaCB8ICA5ICsrKysrDQo+ ICAgdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zYXZlLmMgICB8IDY5ICsrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKw0KPiAgIDIgZmlsZXMgY2hhbmdlZCwgNzggaW5zZXJ0aW9u cygrKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3JfY29tbW9u LmggYi90b29scy9saWJzL2d1ZXN0L3hnX3NyX2NvbW1vbi5oDQo+IGluZGV4IGU1NjdhNDc1 ODIuLjM4ZWMxZGEwOTUgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3Jf Y29tbW9uLmgNCj4gKysrIGIvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9jb21tb24uaA0KPiBA QCAtMjc1LDYgKzI3NSwxNSBAQCBzdHJ1Y3QgeGNfc3JfY29udGV4dA0KPiAgICAgICAgICAg ICAgIC8qIFdoaWNoIGFsZ29yaXRobSB0byBjb21wcmVzcyBwYWdlIGRhdGEgd2l0aC4gKi8N Cj4gICAgICAgICAgICAgICBlbnVtIHhjX3NyX2NvbXByZXNzaW9uIGNvbXByZXNzaW9uOw0K PiAgIA0KPiArICAgICAgICAgICAgLyoNCj4gKyAgICAgICAgICAgICAqIFBhZ2UgZGF0YSBi eXRlcyBiZWZvcmUgKHJhdykgYW5kIGFmdGVyIChvdXQpIGNvbXByZXNzaW9uLCBpbg0KPiAr ICAgICAgICAgICAgICogdGhlIGN1cnJlbnQgaXRlcmF0aW9uIGFuZCBpbiBhbGwgaXRlcmF0 aW9ucyBzbyBmYXIuDQo+ICsgICAgICAgICAgICAgKi8NCj4gKyAgICAgICAgICAgIHVpbnQ2 NF90IGNvbXByZXNzX3Jhd190b3RhbDsNCj4gKyAgICAgICAgICAgIHVpbnQ2NF90IGNvbXBy ZXNzX291dF90b3RhbDsNCj4gKyAgICAgICAgICAgIHVpbnQ2NF90IGNvbXByZXNzX3Jhd19h bGxfdG90YWw7DQo+ICsgICAgICAgICAgICB1aW50NjRfdCBjb21wcmVzc19vdXRfYWxsX3Rv dGFsOw0KPiArDQo+ICAgICAgICAgICAgICAgLyogTFo0IHN0YWdpbmcgYW5kIG91dHB1dCBi dWZmZXJzLCBhbGxvY2F0ZWQgb24gZmlyc3QgdXNlLiAqLw0KPiAgICAgICAgICAgICAgIHZv aWQgKmx6NF9zdGFnaW5nX2J1ZjsNCj4gICAgICAgICAgICAgICB2b2lkICpsejRfY29tcHJl c3NfYnVmOw0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zYXZlLmMg Yi90b29scy9saWJzL2d1ZXN0L3hnX3NyX3NhdmUuYw0KPiBpbmRleCAzMzk1NGE3MDIzLi40 ZmExZDIyODU5IDEwMDY0NA0KPiAtLS0gYS90b29scy9saWJzL2d1ZXN0L3hnX3NyX3NhdmUu Yw0KPiArKysgYi90b29scy9saWJzL2d1ZXN0L3hnX3NyX3NhdmUuYw0KPiBAQCAtODMsNiAr ODMsNjcgQEAgc3RhdGljIHZvaWQgY2xlYW51cF9jb21wcmVzc2lvbihzdHJ1Y3QgeGNfc3Jf Y29udGV4dCAqY3R4KQ0KPiAgIH0NCj4gICANCj4gICAjaWYgZGVmaW5lZChYR19TUl9MWjQp DQo+ICtzdGF0aWMgdm9pZCBjb21wcmVzc19zdGF0c19yZXNldChzdHJ1Y3QgeGNfc3JfY29u dGV4dCAqY3R4KQ0KPiArew0KPiArICAgIGN0eC0+c2F2ZS5jb21wcmVzc19yYXdfdG90YWwg PSAwOw0KPiArICAgIGN0eC0+c2F2ZS5jb21wcmVzc19vdXRfdG90YWwgPSAwOw0KPiArfQ0K PiArDQo+ICtzdGF0aWMgdm9pZCBjb21wcmVzc19zdGF0c19hY2N1bXVsYXRlKHN0cnVjdCB4 Y19zcl9jb250ZXh0ICpjdHgsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHNpemVfdCByYXdfbGVuLCBzaXplX3QgY29tcHJlc3NlZF9sZW4pDQo+ICt7DQo+ ICsgICAgY3R4LT5zYXZlLmNvbXByZXNzX3Jhd190b3RhbCArPSByYXdfbGVuOw0KPiArICAg IGN0eC0+c2F2ZS5jb21wcmVzc19vdXRfdG90YWwgKz0gY29tcHJlc3NlZF9sZW47DQo+ICsg ICAgY3R4LT5zYXZlLmNvbXByZXNzX3Jhd19hbGxfdG90YWwgKz0gcmF3X2xlbjsNCj4gKyAg ICBjdHgtPnNhdmUuY29tcHJlc3Nfb3V0X2FsbF90b3RhbCArPSBjb21wcmVzc2VkX2xlbjsN Cj4gK30NCj4gKw0KPiArc3RhdGljIHZvaWQgY29tcHJlc3Nfc3RhdHNfc3VtbWFyeShjb25z dCBzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4KQ0KPiArew0KPiArICAgIHhjX2ludGVyZmFj ZSAqeGNoID0gY3R4LT54Y2g7DQo+ICsgICAgdWludDY0X3QgcmF3ID0gY3R4LT5zYXZlLmNv bXByZXNzX3Jhd19hbGxfdG90YWw7DQo+ICsgICAgdWludDY0X3Qgb3V0ID0gY3R4LT5zYXZl LmNvbXByZXNzX291dF9hbGxfdG90YWw7DQo+ICsgICAgdW5zaWduZWQgaW50IHBlcm1pbDsN Cj4gKw0KPiArICAgIGlmICggIXJhdyApDQo+ICsgICAgICAgIHJldHVybjsNCj4gKw0KPiAr ICAgIHBlcm1pbCA9IG91dCAqIDEwMDAgLyByYXc7DQo+ICsgICAgSVBSSU5URigiQ29tcHJl c3Npb24gc3VtbWFyeTogY29tcHJlc3NlZCAlIlBSSXU2NCIgLT4gJSJQUkl1NjQiIGJ5dGVz ICgldS4ldSUlIGF2ZXJhZ2UgcmF0aW8pIHdoaWxlIGNvbXByZXNzaW9uIHdhcyBvbiIsDQo+ ICsgICAgICAgICAgICByYXcsIG91dCwgcGVybWlsIC8gMTAsIHBlcm1pbCAlIDEwKTsNCj4g K30NCj4gKw0KPiArI2RlZmluZSBYQ19TUl9DT01QUkVTU19JVEVSX1RIUkVTSE9MRCA5MA0K PiArDQo+ICtzdGF0aWMgdm9pZCBjb21wcmVzc19zdGF0c19ldmFsdWF0ZShzdHJ1Y3QgeGNf c3JfY29udGV4dCAqY3R4KQ0KPiArew0KPiArICAgIHhjX2ludGVyZmFjZSAqeGNoID0gY3R4 LT54Y2g7DQo+ICsgICAgdWludDY0X3QgcmF3ID0gY3R4LT5zYXZlLmNvbXByZXNzX3Jhd190 b3RhbDsNCj4gKyAgICB1aW50NjRfdCBvdXQgPSBjdHgtPnNhdmUuY29tcHJlc3Nfb3V0X3Rv dGFsOw0KPiArICAgIHVuc2lnbmVkIGludCBpdGVyID0gY3R4LT5zYXZlLnN0YXRzLml0ZXJh dGlvbjsNCj4gKw0KPiArICAgIGlmICggY3R4LT5zYXZlLmNvbXByZXNzaW9uID09IFhDX1NS X0NPTVBSRVNTX05PTkUgKQ0KPiArICAgICAgICByZXR1cm47DQo+ICsNCj4gKyAgICBpZiAo IHJhdyApDQo+ICsgICAgew0KPiArICAgICAgICB1bnNpZ25lZCBpbnQgcGVybWlsID0gb3V0 ICogMTAwMCAvIHJhdzsNCj4gKw0KPiArICAgICAgICBJUFJJTlRGKCJJdGVyYXRpb24gJXU6 IGNvbXByZXNzZWQgJSJQUkl1NjQiIC0+ICUiUFJJdTY0IiBieXRlcyAoJXUuJXUlJSBhdmVy YWdlIHJhdGlvKSIsDQo+ICsgICAgICAgICAgICAgICAgaXRlciwgcmF3LCBvdXQsIHBlcm1p bCAvIDEwLCBwZXJtaWwgJSAxMCk7DQo+ICsNCj4gKyAgICAgICAgaWYgKCBvdXQgKiAxMDAg Pj0gcmF3ICogWENfU1JfQ09NUFJFU1NfSVRFUl9USFJFU0hPTEQgKQ0KPiArICAgICAgICB7 DQo+ICsgICAgICAgICAgICBJUFJJTlRGKCJJdGVyYXRpb24gJXU6IGF0IG9yIGFib3ZlIHRo ZSAldSUlIHRocmVzaG9sZCAtIGRpc2FibGluZyBjb21wcmVzc2lvbiBmb3IgcmVtYWluaW5n IGl0ZXJhdGlvbnMiLA0KPiArICAgICAgICAgICAgICAgICAgICBpdGVyLCBYQ19TUl9DT01Q UkVTU19JVEVSX1RIUkVTSE9MRCk7DQo+ICsgICAgICAgICAgICBjdHgtPnNhdmUuY29tcHJl c3Npb24gPSBYQ19TUl9DT01QUkVTU19OT05FOw0KPiArICAgICAgICAgICAgY2xlYW51cF9j b21wcmVzc2lvbihjdHgpOw0KPiArICAgICAgICB9DQo+ICsgICAgfQ0KPiArDQo+ICsgICAg Y29tcHJlc3Nfc3RhdHNfcmVzZXQoY3R4KTsNCj4gK30NCj4gKw0KDQpJIHRoaW5rIHdlIGNh biBhZGQgYSBjb25kaXRpb24gd2hlcmUgdGhlIGV2YWx1YXRpb24gb25seSBvY2N1cnMgaWYg DQplbm91Z2ggcGFnZXMgZ290IGV2YWx1YXRlZCwgb3RoZXJ3aXNlLCBhIGl0ZXJhdGlvbiB3 aXRoIG9ubHkgYSBmZXcgDQp1bmNvbXByZXNzaWJsZSBwYWdlcyB3b3VsZCB0dXJuIG9mZiB0 aGUgY29tcHJlc3Npb24gZm9yIHRoZSByZW1haW5kZXIsIA0KZXZlbiBpZiBpdCB3b3VsZCBo YXZlIGNvbXByZXNzZWQgd2VsbC4NCg0KPiAgIC8qDQo+ICAgICogT25lIGJsb2NrIHBlciA0 TUIgYmF0Y2g6IHNtYWxsZXIgYmxvY2tzIGNhbiBiZSAyeCBzbG93ZXIgdG8gZGVjb2RlLg0K PiAgICAqIGxpYmx6NCBhbGxvd3MgNjRLQiwgMjU2S0IsIDFNQiBhbmQgNE1CLg0KPiBAQCAt MTY0LDExICsyMjUsMTMgQEAgc3RhdGljIGludCBsejRfY29tcHJlc3NfYmF0Y2goc3RydWN0 IHhjX3NyX2NvbnRleHQgKmN0eCwgc3RydWN0IGlvdmVjICppb3YsDQo+ICAgICAgIGlmICgg Y2xlbiA+PSByYXcgKQ0KPiAgICAgICB7DQo+ICAgICAgICAgICBEQkdQUklOVEYoIkxaNDog JXp1IC0+ICV6dSBieXRlcywgc2VuZGluZyB1bmNvbXByZXNzZWQiLCByYXcsIGNsZW4pOw0K PiArICAgICAgICBjb21wcmVzc19zdGF0c19hY2N1bXVsYXRlKGN0eCwgcmF3LCByYXcpOw0K PiAgICAgICAgICAgcmV0dXJuIGlvdmNudDsNCj4gICAgICAgfQ0KPiAgIA0KPiAgICAgICBE QkdQUklOVEYoIkxaNDogJXp1IC0+ICV6dSBieXRlcyAoJXp1LiV6dSUlIHJhdGlvKSIsIHJh dywgY2xlbiwNCj4gICAgICAgICAgICAgICAgIChjbGVuICogMTAwMCAvIHJhdykgLyAxMCwg KGNsZW4gKiAxMDAwIC8gcmF3KSAlIDEwKTsNCj4gKyAgICBjb21wcmVzc19zdGF0c19hY2N1 bXVsYXRlKGN0eCwgcmF3LCBjbGVuKTsNCj4gICANCj4gICAgICAgLyogUGFkIGluIHBsYWNl OiByYXcgaXMgYSBtdWx0aXBsZSBvZiBSRUNfQUxJR04gYW5kID4gY2xlbiwgc28gaXQgZml0 cy4gKi8NCj4gICAgICAgbWVtc2V0KCh1aW50OF90ICopY3R4LT5zYXZlLmx6NF9jb21wcmVz c19idWYgKyBjbGVuLCAwLA0KPiBAQCAtNjM4LDYgKzcwMSw5IEBAIHN0YXRpYyBpbnQgc2Vu ZF9tZW1vcnlfbGl2ZShzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4KQ0KPiAgICAgICAgICAg ICAgIHJjID0gc2VuZF9kaXJ0eV9wYWdlcyhjdHgsIHN0YXRzLmRpcnR5X2NvdW50KTsNCj4g ICAgICAgICAgICAgICBpZiAoIHJjICkNCj4gICAgICAgICAgICAgICAgICAgZ290byBvdXQ7 DQo+ICsjaWYgZGVmaW5lZChYR19TUl9MWjQpDQo+ICsgICAgICAgICAgICBjb21wcmVzc19z dGF0c19ldmFsdWF0ZShjdHgpOw0KPiArI2VuZGlmDQo+ICAgICAgICAgICB9DQo+ICAgDQo+ ICAgICAgICAgICBpZiAoIHBvbGljeV9kZWNpc2lvbiAhPSBYR1NfUE9MSUNZX0NPTlRJTlVF X1BSRUNPUFkgKQ0KPiBAQCAtOTM5LDYgKzEwMDUsOSBAQCBzdGF0aWMgdm9pZCBjbGVhbnVw KHN0cnVjdCB4Y19zcl9jb250ZXh0ICpjdHgpDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBOUlBBR0VTKGJpdG1hcF9zaXplKGN0eC0+c2F2ZS5wMm1fc2l6ZSkp KTsNCj4gICAgICAgZnJlZShjdHgtPnNhdmUuZGVmZXJyZWRfcGFnZXMpOw0KPiAgICAgICBm cmVlKGN0eC0+c2F2ZS5idWZmZXJzKTsNCj4gKyNpZiBkZWZpbmVkKFhHX1NSX0xaNCkNCj4g KyAgICBjb21wcmVzc19zdGF0c19zdW1tYXJ5KGN0eCk7DQo+ICsjZW5kaWYNCj4gICAgICAg Y2xlYW51cF9jb21wcmVzc2lvbihjdHgpOw0KPiAgIH0NCj4gICANCg0KT3ZlcmFsbCwgSSB0 aGluayBpdCB3b3VsZCBiZSBwcmVmZXJhYmxlIHRvIGhhdmUgYSBsaWdodHdlaWdodCBoZXVy aXN0aWMgDQp0byBrbm93IGlmIGEgcGFnZSBpcyBsaWtlbHkgdG8gY29tcHJlc3Mgd2VsbCwg cmF0aGVyIHRoYW4gZW1waXJpY2FsbHkgDQp0dXJuaW5nIGl0IG9mZiBiYXNlZCBvbiBzdGF0 cy4gQnV0IHRoYXQncyBwcm9iYWJseSBiZXN0IGFuc3dlcmVkIHdpdGggDQp0ZXN0aW5nIGFu ZCBiZW5jaG1hcmtzLg0KDQpUZWRkeQ0K --------------EMH06o0RrD6NGMvLddUB9s0K-- --------------0swmmymgrhGDFRFyu0Dj8vOG 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+p0QLLz9AFAmriFNEFAwAAAAAACgkQZg+p0QLLz9BS RQv6AvKCbNcrMHvRJIjwJbRPO0ee2/ROfO+gX6EndpRecn8I4D7ubI8MxHsj3K+QKy6ds44BvyiJ vYGORmKqZVzZ4AhHiPb0wqrB0bM3mrd+57/6uBuJlB+T85sV00bCfUPgv9nSbdsIwwe3dXyxmCza ch3lnNXhn/aYfmfNAuAFpcmCXd1GIvJ5Fm5PpJUZS9YYbkYGp+00jxgYgBLCGZG2VuoB1M7phRIW kFIvuFVYsEP487uDmxiA/ZG7vBHpDtw7xQdImz230SA6TdXctWe795NoIUpSjt9ru9fMQEHeUEXL OYz5tKvdGxsBpPxWXrUBw+OUDT5EBIOsSk8ueBlhrDTLVUwRW/XI0KcDE/LSSZv0B3JTGh7vkcFI XbHMrilO9X2ODriVMpXaneiXZl3daSufweIRZcpRQWla3GIdqHVYpdusMlqMLX1G0cH7CHxDmTgf uoaoiV1tAW8M7jjFV3+OyXol2ZAIZw+TRZS5pI/f8K0GjK8BQZ1E85RIDrsl =77tR -----END PGP SIGNATURE----- --------------0swmmymgrhGDFRFyu0Dj8vOG-- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 15:36:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 15:36:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463422.1674309 (Exim 4.92) (envelope-from ) id 1xM5hA-000319-3x; Wed, 28 Oct 2026 15:36:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463422.1674309; Wed, 28 Oct 2026 15:36: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 1xM5hA-000312-0k; Wed, 28 Oct 2026 15:36:08 +0000 Received: by outflank-mailman (input) for mailman id 1463422; Wed, 28 Oct 2026 15:36:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM5h8-00030w-E8 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:36:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM5h7-006YO9-H2 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 16:36:05 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae21664-e002-0a2a0a5209dd-0a2a4509c304-4 for ; Wed, 28 Oct 2026 16:36:05 +0100 Received: from [209.85.160.175] (helo=mail-qt1-f175.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae21664-be1a-0a2a45090019-d155a0af90f2-3 for ; Wed, 28 Oct 2026 16:36:05 +0100 Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-533202fe429so405231cf.0 for ; Wed, 28 Oct 2026 08: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=20260707 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=1793201764; cv=none; d=google.com; s=arc-20260327; b=pHwFfC54MLk0FkwSLIFff7GNwNktvrDXyhH1QbjlN44qqcUEZb93P7CyZ7zPCKnIU6 XI3DtdjkyOYkOTMFWzhbjRxZkjPyVkctX5IeLbWgUf/AL21iSCyF4MbBque42jjg04m8 0swtXvzEEhswYdnJqTME8YA7vFKcFbU1nunqWK6S1iKVOijNuqsdQpkdkaPUHxJl0Su/ 56SJuoFaGM9yUeYtJqwF7y2gw2zTiQ7SZSDnL759MBKO++YwIHO6Tr1zXMS46cK1NLd8 09F2cVgw9JWXNSftb0wB+dLETTm+5UHsoMCDRVt+wzKFsHCuRYQlsi4/keAhbyYaG/YM wPfA== 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=IMDYK1ZjnbIiPQHcJc7SpOjyQ4Wy/ZaG15fuBEkM+6c=; fh=gA55tpGH41ASjpYEidKOLVWzMB3TiUGmX/pFMFevwYM=; b=rVjl8D4coHtvfW/uGqPozkJhaQyjBr92beVgDTRnrikB/yKY4SpgJp0ve9ZFDANyUm QxrRXu5onfrtcAUipAkseuYRb/msVS+SdouSoIQIs9gP2T8PjJbDVEznZKHlahAGvaCz KeLmKs4BykX3a4WtPI/+Hz4kZUQIzYtp5sXsZ8hr98le6GoT3olmB2ifY3a561KtrveQ Y0q1mnl8+HTRdwIYytJd8Em+33u1NUzGAo0mB3ZEVlPz/eDk2X0fAftwI2sEilDVRk/9 OTHURFSOyRDqJkPtS37h9vi0pjC9DoGC8naFvHOinBAYnBa6Kj5chiAcU6H/9QDF+ZKe QEHQ==; 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=20260707; t=1793201764; x=1793806564; 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=IMDYK1ZjnbIiPQHcJc7SpOjyQ4Wy/ZaG15fuBEkM+6c=; b=QTGar9coGFkNhQ8rsE8dZTc+N0eEIzbTB/kHnR+rLP0ar0vHHxsFT18TiuAhBUa526 1J4Ny7iQSXYnW7s+1jBhfHRn1+Hj5xKCO39YQXZQhtV9vwq76W7c2jwsgeBylrExX3h8 7dOHxSgzEs10vcUIAKYVNPpTlmPgk6oq2qu0KooFNzE1NiRq4oajFxybKfTE6PNiZO+/ PgKhrKSHVy2SCeQwLJAOU36gCfcVxHGf1Ly/pIbm3nVl/bUVXO5QKrZFMHfkWCdZEt4e LTVNnXjXiZiWJh1rUzSIEUTpwa2qHe1DhUOJYmZwPXVHjwa617aP3e3dglpyf9hS/Vh6 LPFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793201764; x=1793806564; 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=IMDYK1ZjnbIiPQHcJc7SpOjyQ4Wy/ZaG15fuBEkM+6c=; b=muzMdkfezcCj8aoi7+3Bw642nSOqt4Edt5SxMSXfCPyHBPmPefHdEguBVKnLQES1bn wpI6JasuNHcWzYHsBMQdQrXxX2x/mAqntByLzcauBSB8NzE6o6w2LFhYrKjOZKJcfTO1 TOqpG+Q1efPvlBBkJHRyT2pwT5Pbjd4rjzg5VKTXLDh2b/b/Nj9r9T2UtQmPzAoKivnw VUZZR2LSt7m2V+nj/I0IdTq91J6CM1tjQlu9Daf7e44akJgWUCAY0BfFOJvBMNXeeiM6 GabIKDisJUMZ3NUCSHB/dbwhi+cQwE7kwXyGBn2uHp+xeYEKAtLljIj0oV/dwR4wSend W/Sw== X-Forwarded-Encrypted: i=1; AKwUvBz3itPp2znGB1wl77CJ/D9hbHWjuUgUtZzq7LKDvOVjDLJzB4uPvalyKmHtBNMGjZ6/ZrPnW7yC5YY=@lists.xenproject.org X-Gm-Message-State: AFq9FYIUmBc6TLzakF/I8eEHwiluA7mxiv3jRL7/5JfLYuYMnVMkpWZo xNbrcTW914Zkxomb06FGc2ww4Fm4BFIJdZ7CH4vZoWTyAMGt76PPe7X5L3NJUV4qQTbja8zhae/ wW9K+ZY7FknxJqZJGo9WDkOx1tECbdSt/z7s2al/f X-Gm-Gg: AYBFou08vrDuAzTg6TvCkt71rHgYY1mohJwhdbsh+bb9xz2ttJSPgl+MHb6kHWARYlt ZwDzuK5cJ14il0luHbI6hjCx5MTWfHEuJw3Z0VM690yQrTG6tTUqeEyP9HG/9MWeH2eXdga5RJ5 q4boRxakkmfiwiKI6zWb3y3kudGE6ORXhI1OCfR8f5YwqNl+A7w5SNAv0w1I7Q1zoZw2YHua09B xcPPbINbmlnmWGbm2/O2N+qC/giMeXZKtUbBwBEEMtH5r3SYaRHkNoMteC6tXUjcfAbDRLyDxKh +rjL+D/zfr64hpZhXutmgCZriq+SyPexZtokoPjq7Irst4yK5Lm4PBU43a+Wkv1fUXb9Kj2aGNk zpazMeoTcNtH96ZlQgow3HBlln+KveUF9dvx/9R/vyog4STeMzgYwgFCIjcY= X-Received: by 2002:a05:622a:22a9:b0:536:97c0:dcd0 with SMTP id d75a77b69052e-53fc2aa1fa2mr21345071cf.4.1793201763129; Wed, 28 Oct 2026 08:36:03 -0700 (PDT) MIME-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-5-irogers@google.com> In-Reply-To: From: Ian Rogers Date: Wed, 28 Oct 2026 08:35:50 -0700 X-Gm-Features: AclHuK8Z1SdNi4k8-UQceLsnqDJD6d9aTo0cl8IQ7vlO1Fmucv2n8goL0VFX4iw Message-ID: Subject: Re: [PATCH v2 4/9] cpufreq: governor: Initialize kobj_type release callback statically To: "Rafael J. Wysocki (Intel)" Cc: Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , Danilo Krummrich , Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , =?UTF-8?Q?Christian_K=C3=B6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Viresh Kumar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1793201765-FD06B034-E68C906D/0/0 X-purgate-type: clean X-purgate-size: 5277 On Wed, Oct 28, 2026 at 4:39=E2=80=AFAM Rafael J. Wysocki (Intel) wrote: > > On Tue, Oct 27, 2026 at 11:39=E2=80=AFPM Ian Rogers = wrote: > > > > Export cpufreq_dbs_data_release() and set .kobj_type.release statically > > in the ondemand and conservative governors so their gov_attr_set > > kobjects have a valid release callback statically initialized, matching > > cpufreq_governor_dbs. Remove the redundant runtime assignment in > > cpufreq_dbs_governor_init(). > > > > This prepares for annotating struct kobj_type::release with > > __must_init. > > > > Signed-off-by: Ian Rogers > > Do you want stuff to be picked up by maintainers, or do you want to > route it yourself? Hi Rafael, Just a quick note: I agree with Zhongqiu's feedback and the commit message needs a fix. Regarding merging the patches, the issue with maintainers picking up fixes is that the series will break the clang/llvm build without them. So the maintainers need to either merge the patches (and the series be rebased on top of them) or merge the series as a unit. Perhaps since the patches align, merge conflicts won't happen, so maintainers merging and landing the series is okay. I don't have the experience to know. Thanks, Ian > > --- > > drivers/cpufreq/cpufreq_conservative.c | 5 ++++- > > drivers/cpufreq/cpufreq_governor.c | 4 ++-- > > drivers/cpufreq/cpufreq_governor.h | 1 + > > drivers/cpufreq/cpufreq_ondemand.c | 5 ++++- > > 4 files changed, 11 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/c= pufreq_conservative.c > > index 02bfd46543e9..146a2353b1a2 100644 > > --- a/drivers/cpufreq/cpufreq_conservative.c > > +++ b/drivers/cpufreq/cpufreq_conservative.c > > @@ -318,7 +318,10 @@ static void cs_limits(struct cpufreq_policy *polic= y) > > > > static struct dbs_governor cs_governor =3D { > > .gov =3D CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"), > > - .kobj_type =3D { .default_groups =3D cs_groups }, > > + .kobj_type =3D { > > + .release =3D cpufreq_dbs_data_release, > > + .default_groups =3D cs_groups, > > + }, > > .gov_dbs_update =3D cs_dbs_update, > > .alloc =3D cs_alloc, > > .free =3D cs_free, > > diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufr= eq_governor.c > > index f3bd3dbe7c41..f8b5aca09b6b 100644 > > --- a/drivers/cpufreq/cpufreq_governor.c > > +++ b/drivers/cpufreq/cpufreq_governor.c > > @@ -419,7 +419,7 @@ static void free_policy_dbs_info(struct policy_dbs_= info *policy_dbs, > > gov->free(policy_dbs); > > } > > > > -static void cpufreq_dbs_data_release(struct kobject *kobj) > > +void cpufreq_dbs_data_release(struct kobject *kobj) > > { > > struct dbs_data *dbs_data =3D to_dbs_data(to_gov_attr_set(kobj)= ); > > struct dbs_governor *gov =3D dbs_data->gov; > > @@ -427,6 +427,7 @@ static void cpufreq_dbs_data_release(struct kobject= *kobj) > > gov->exit(dbs_data); > > kfree(dbs_data); > > } > > +EXPORT_SYMBOL_GPL(cpufreq_dbs_data_release); > > > > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) > > { > > @@ -488,7 +489,6 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy= *policy) > > policy->governor_data =3D policy_dbs; > > > > gov->kobj_type.sysfs_ops =3D &governor_sysfs_ops; > > - gov->kobj_type.release =3D cpufreq_dbs_data_release; > > ret =3D kobject_init_and_add(&dbs_data->attr_set.kobj, &gov->ko= bj_type, > > get_governor_parent_kobj(policy), > > "%s", gov->gov.name); > > diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufr= eq_governor.h > > index 806d8fb4dff1..1026712bb79b 100644 > > --- a/drivers/cpufreq/cpufreq_governor.h > > +++ b/drivers/cpufreq/cpufreq_governor.h > > @@ -150,6 +150,7 @@ static inline struct dbs_governor *dbs_governor_of(= struct cpufreq_policy *policy > > } > > > > /* Governor callback routines */ > > +void cpufreq_dbs_data_release(struct kobject *kobj); > > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy); > > void cpufreq_dbs_governor_exit(struct cpufreq_policy *policy); > > int cpufreq_dbs_governor_start(struct cpufreq_policy *policy); > > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufr= eq_ondemand.c > > index 9942dbb38dae..7386d043c665 100644 > > --- a/drivers/cpufreq/cpufreq_ondemand.c > > +++ b/drivers/cpufreq/cpufreq_ondemand.c > > @@ -374,7 +374,10 @@ static struct od_ops od_ops =3D { > > > > static struct dbs_governor od_dbs_gov =3D { > > .gov =3D CPUFREQ_DBS_GOVERNOR_INITIALIZER("ondemand"), > > - .kobj_type =3D { .default_groups =3D od_groups }, > > + .kobj_type =3D { > > + .release =3D cpufreq_dbs_data_release, > > + .default_groups =3D od_groups, > > + }, > > .gov_dbs_update =3D od_dbs_update, > > .alloc =3D od_alloc, > > .free =3D od_free, > > -- > > 2.56.0.313.g2479322e68-goog > > > > From xen-devel-bounces@lists.xenproject.org Wed Oct 28 15:36:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 15:36:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463429.1674317 (Exim 4.92) (envelope-from ) id 1xM5hq-0003Ti-Du; Wed, 28 Oct 2026 15:36:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463429.1674317; Wed, 28 Oct 2026 15: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 1xM5hq-0003Tb-BT; Wed, 28 Oct 2026 15:36:50 +0000 Received: by outflank-mailman (input) for mailman id 1463429; Wed, 28 Oct 2026 15:36:48 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM5ho-0003TN-HG for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:36:48 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xM5ho-00000000gHc-25mD; Wed, 28 Oct 2026 15:36: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.98.2) (envelope-from ) id 1xM5hn-00000009ZFs-3vYd; Wed, 28 Oct 2026 15:36: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=KSYyiEkb3HRvGWRoSzNKtIyaBWL4LjRnypc2Pf5Vodc=; b=40aNsRgwimd2KU4clov4dEsRIX nx+HEsxaGaycGF6Lq8y+mSm7BQPeWEjTF+tMo16rAndjwMnsRHFkqeHryg9N35Pi7Z2oL6DoG1A6R i6ESP7AbDqPaN6FSaAa0HBFkbsDDx6zHakwqn06YSfeIrJ1/yYAGW3Bc382lAf3JEq/c=; Date: Wed, 28 Oct 2026 16:36:45 +0100 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 v2 1/5] x86/pass-through: alter locking around pt_irq_{create,destroy}_bind() Message-ID: References: <3bd58966-9ca8-484f-acb8-cda56df565a6@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3bd58966-9ca8-484f-acb8-cda56df565a6@suse.com> On Wed, Oct 28, 2026 at 04:21:15PM +0100, Jan Beulich wrote: > On 28.10.2026 15:33, Roger Pau Monné wrote: > > On Wed, Sep 30, 2026 at 01:42:29PM +0200, Jan Beulich wrote: > >> --- a/xen/arch/x86/hvm/vioapic.c > >> +++ b/xen/arch/x86/hvm/vioapic.c > >> @@ -197,8 +197,9 @@ static int vioapic_hwdom_map_gsi(unsigne > >> return ret; > >> } > >> > >> - pcidevs_lock(); > >> + read_lock(&currd->pci_lock); > >> ret = pt_irq_create_bind(currd, &pt_irq_bind); > >> + read_unlock(&currd->pci_lock); > > > > I think you need to extend the ->pci_lock'ed region so it also covers > > unmap_domain_pirq(), otherwise the ASSERT_PDEV_LIST_IS_READ_LOCKED() > > in there will trigger? IE: the read_unlock() needs to be where the > > pcidevs_unlock() is? > > Oh, indeed. That would only be an issue if an error arose, so it's > clear why I didn't hit that assertion. > > This being the only change (which I've made locally) necessary for > the entire series - shall I re-send, or would you mind giving an ack > for the patch with said adjustment made? I'm happy for you do do the change locally and commit: Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Oct 28 15:39:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 15:39:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463435.1674326 (Exim 4.92) (envelope-from ) id 1xM5kp-0004Kj-QS; Wed, 28 Oct 2026 15:39:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463435.1674326; Wed, 28 Oct 2026 15:39: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 1xM5kp-0004Ka-NC; Wed, 28 Oct 2026 15:39:55 +0000 Received: by outflank-mailman (input) for mailman id 1463435; Wed, 28 Oct 2026 15:39:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM5ko-0004KJ-5D for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 15:39:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM5kn-00AbKn-9v for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 16:39:53 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2173a-2eae-0a2a0a5409dd-0a2a4506991a-32 for ; Wed, 28 Oct 2026 16:39:53 +0100 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae21747-195a-0a2a45060019-aceafc1fb010-3 for ; Wed, 28 Oct 2026 16:39:52 +0100 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id DB803437D5 for ; Wed, 28 Oct 2026 15:39:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9D2F1F031F5 for ; Wed, 28 Oct 2026 15:39:50 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-3ab3dd9667dso8008441fa.1 for ; Wed, 28 Oct 2026 08:39: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=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=1793201990; bh=v/GrfVBE9REqGlviMjMV9KYA8baC9D3Z4PFL9rDyJNI=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=VHtM/wzid4Vjpi1ahtkrCTunBXdpMk588+yxAl/Zt7jPzQ9CgDIh+PYPt+lW+RHtD XBF1ITpY/oCCREN/r3GxTTiasnxkbYCm2mrSb3zmMn23c5zknBvNx/dV5SfeyYM827 m45G9IzvrUp2GsXITO1BPz91FS4SrBTRct5fIYPvHF7/uja6GCRbMQHJlEDtcLZFBR bBqsTOILPojBkbqP9c5uFYFLXwvDa2XYT2SFUMxRTuB6ZQzLNkssif/6urHzHO00fk Skgn+ptvjMSTS3VMBezq8yREZJPVwbZdc9I441ADP3crdeclpWj7HnR60MZ9kaBb89 e8j26jTotaK2A== X-Forwarded-Encrypted: i=1; AKwUvBwnW5MyDrshO2ihSGnqPqcjSyCRwRfZukH4e4Y/7RlV9lxel4cW7asK8XjxKIEprFy+g90G7h2zQ28=@lists.xenproject.org X-Gm-Message-State: AFq9FYL+CsuXYS6tbzZG7XP4DkGC72PYI4FjhbLz7hvvSwCAW956UD2f CsgdwQfcqgPovfcBwHsXM1/UxeMFXNq5VsKOE2PavxZREyqI8zVT8knzdAwYl5/+9l9EysxcvMa +kJXaK7BlyFdFX2vS7NQ6eke22NzgdX8= X-Received: by 2002:a05:6512:33cb:b0:5bf:ba43:f2f1 with SMTP id 2adb3069b0e04-5bfcad8c081mr1232361e87.34.1793201988873; Wed, 28 Oct 2026 08:39:48 -0700 (PDT) MIME-Version: 1.0 References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-5-irogers@google.com> In-Reply-To: From: "Rafael J. Wysocki (Intel)" Date: Wed, 28 Oct 2026 16:39:37 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-jtq7opXKWd_89haXf76RntnjsmSewB7PcsqPK44QRbhInXeBo-GT0LQw Message-ID: Subject: Re: [PATCH v2 4/9] cpufreq: governor: Initialize kobj_type release callback statically To: Ian Rogers Cc: "Rafael J. Wysocki (Intel)" , Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , Danilo Krummrich , Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , =?UTF-8?Q?Christian_K=C3=B6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Viresh Kumar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1793201993-F6A7477B-84FE82ED/0/0 X-purgate-type: clean X-purgate-size: 5798 On Wed, Oct 28, 2026 at 4:36=E2=80=AFPM Ian Rogers wro= te: > > On Wed, Oct 28, 2026 at 4:39=E2=80=AFAM Rafael J. Wysocki (Intel) > wrote: > > > > On Tue, Oct 27, 2026 at 11:39=E2=80=AFPM Ian Rogers wrote: > > > > > > Export cpufreq_dbs_data_release() and set .kobj_type.release statical= ly > > > in the ondemand and conservative governors so their gov_attr_set > > > kobjects have a valid release callback statically initialized, matchi= ng > > > cpufreq_governor_dbs. Remove the redundant runtime assignment in > > > cpufreq_dbs_governor_init(). > > > > > > This prepares for annotating struct kobj_type::release with > > > __must_init. > > > > > > Signed-off-by: Ian Rogers > > > > Do you want stuff to be picked up by maintainers, or do you want to > > route it yourself? > > Hi Rafael, > > Just a quick note: I agree with Zhongqiu's feedback and the commit > message needs a fix. > > Regarding merging the patches, the issue with maintainers picking up > fixes is that the series will break the clang/llvm build without them. > So the maintainers need to either merge the patches (and the series be > rebased on top of them) or merge the series as a unit. Perhaps since > the patches align, merge conflicts won't happen, so maintainers > merging and landing the series is okay. I don't have the experience to > know. I'd expect the driver core to pick up the series as a whole then, so please feel free to add Acked-by: Rafael J. Wysocki (Intel) # cpufreq to the next version of this patch. Thanks! > > > --- > > > drivers/cpufreq/cpufreq_conservative.c | 5 ++++- > > > drivers/cpufreq/cpufreq_governor.c | 4 ++-- > > > drivers/cpufreq/cpufreq_governor.h | 1 + > > > drivers/cpufreq/cpufreq_ondemand.c | 5 ++++- > > > 4 files changed, 11 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq= /cpufreq_conservative.c > > > index 02bfd46543e9..146a2353b1a2 100644 > > > --- a/drivers/cpufreq/cpufreq_conservative.c > > > +++ b/drivers/cpufreq/cpufreq_conservative.c > > > @@ -318,7 +318,10 @@ static void cs_limits(struct cpufreq_policy *pol= icy) > > > > > > static struct dbs_governor cs_governor =3D { > > > .gov =3D CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"), > > > - .kobj_type =3D { .default_groups =3D cs_groups }, > > > + .kobj_type =3D { > > > + .release =3D cpufreq_dbs_data_release, > > > + .default_groups =3D cs_groups, > > > + }, > > > .gov_dbs_update =3D cs_dbs_update, > > > .alloc =3D cs_alloc, > > > .free =3D cs_free, > > > diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpu= freq_governor.c > > > index f3bd3dbe7c41..f8b5aca09b6b 100644 > > > --- a/drivers/cpufreq/cpufreq_governor.c > > > +++ b/drivers/cpufreq/cpufreq_governor.c > > > @@ -419,7 +419,7 @@ static void free_policy_dbs_info(struct policy_db= s_info *policy_dbs, > > > gov->free(policy_dbs); > > > } > > > > > > -static void cpufreq_dbs_data_release(struct kobject *kobj) > > > +void cpufreq_dbs_data_release(struct kobject *kobj) > > > { > > > struct dbs_data *dbs_data =3D to_dbs_data(to_gov_attr_set(kob= j)); > > > struct dbs_governor *gov =3D dbs_data->gov; > > > @@ -427,6 +427,7 @@ static void cpufreq_dbs_data_release(struct kobje= ct *kobj) > > > gov->exit(dbs_data); > > > kfree(dbs_data); > > > } > > > +EXPORT_SYMBOL_GPL(cpufreq_dbs_data_release); > > > > > > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy) > > > { > > > @@ -488,7 +489,6 @@ int cpufreq_dbs_governor_init(struct cpufreq_poli= cy *policy) > > > policy->governor_data =3D policy_dbs; > > > > > > gov->kobj_type.sysfs_ops =3D &governor_sysfs_ops; > > > - gov->kobj_type.release =3D cpufreq_dbs_data_release; > > > ret =3D kobject_init_and_add(&dbs_data->attr_set.kobj, &gov->= kobj_type, > > > get_governor_parent_kobj(policy), > > > "%s", gov->gov.name); > > > diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpu= freq_governor.h > > > index 806d8fb4dff1..1026712bb79b 100644 > > > --- a/drivers/cpufreq/cpufreq_governor.h > > > +++ b/drivers/cpufreq/cpufreq_governor.h > > > @@ -150,6 +150,7 @@ static inline struct dbs_governor *dbs_governor_o= f(struct cpufreq_policy *policy > > > } > > > > > > /* Governor callback routines */ > > > +void cpufreq_dbs_data_release(struct kobject *kobj); > > > int cpufreq_dbs_governor_init(struct cpufreq_policy *policy); > > > void cpufreq_dbs_governor_exit(struct cpufreq_policy *policy); > > > int cpufreq_dbs_governor_start(struct cpufreq_policy *policy); > > > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpu= freq_ondemand.c > > > index 9942dbb38dae..7386d043c665 100644 > > > --- a/drivers/cpufreq/cpufreq_ondemand.c > > > +++ b/drivers/cpufreq/cpufreq_ondemand.c > > > @@ -374,7 +374,10 @@ static struct od_ops od_ops =3D { > > > > > > static struct dbs_governor od_dbs_gov =3D { > > > .gov =3D CPUFREQ_DBS_GOVERNOR_INITIALIZER("ondemand"), > > > - .kobj_type =3D { .default_groups =3D od_groups }, > > > + .kobj_type =3D { > > > + .release =3D cpufreq_dbs_data_release, > > > + .default_groups =3D od_groups, > > > + }, > > > .gov_dbs_update =3D od_dbs_update, > > > .alloc =3D od_alloc, > > > .free =3D od_free, > > > -- > > > 2.56.0.313.g2479322e68-goog > > > > > > > From xen-devel-bounces@lists.xenproject.org Wed Oct 28 17:09:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 17:09:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463486.1674337 (Exim 4.92) (envelope-from ) id 1xM79a-0002cz-Pi; Wed, 28 Oct 2026 17:09:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463486.1674337; Wed, 28 Oct 2026 17: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 1xM79a-0002cs-M1; Wed, 28 Oct 2026 17:09:34 +0000 Received: by outflank-mailman (input) for mailman id 1463486; Wed, 28 Oct 2026 17:09:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM79Y-0002cJ-7h for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 17:09:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM79X-008NPo-Bg for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 18:09:31 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae22c23-8faa-0a2a0a5109dd-0a2a4502e2f4-30 for ; Wed, 28 Oct 2026 18:09:31 +0100 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 6ae22c4a-6ca4-0a2a45020019-b9ff1c1291c3-3 for ; Wed, 28 Oct 2026 18:09:31 +0100 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 1a1837cf5ff000f79f.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 17:09:27 +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 5194C82C5C; Wed, 28 Oct 2026 18:09:26 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=6L/hueQJbBKX0kvzY/pAWcQ+34OJLdrKc9wGZ5upqcM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=S+a3y6YD8zOv4RLLJc0F3YdBX6MtQxwORmIG3/6jl1qM0YH4qPF3llp+683o8h7dLK8U/E1bW A8aDyyd7yg0YvQS/L6tbwAKLCP0UhWRGm7QZyRohJWG6tXPkzYtUpWPxN/9+5fQh9keVRfS82GT sB8l13xpWmzbsgl6ST/kN4399tkRf2Fq+gW0JrAcTI6nDGFFncgLSfStVNHBcy7GySsQEbgFfpf xWIZ05IPSb3o6ekBMDytEEWQA4GXjLhillvdgoiqEzfHmPWt8g4TLkictNBbZfIDh05hVLAgfU7 V0F9Arv9jXgxvydyC7sNlltvObMf41IarTL/KSQQO21w== X-Zone-Loop: df92b822182eaa357a0475cb90475795a54d4ff4bb1f x-campaign-type: default x-transaction-id: b2c72bdb-23a6-431e-93ab-104bb75e0b08 x-swg-uid: 01-5dc67000-a0e9-4fd6-959a-a8be4829785e X-Mailer: Sweego Message-ID: <1793207367.8631fc262581453bbf619ec5b2062170.1a1837cf5ff000f79f@vates.tech> x-swg-bid: 1793207367.8631fc262581453bbf619ec5b2062170.1a1837cf5ff000f79f 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 3/6] automation/qtb: add Python QTB framework with the console-test type From: Baptiste Le Duc To: Anthony PERARD Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini In-Reply-To: <1793180994.8631fc262581453bbf619ec5b2062170.1a181ea8c1d000f79f@vates.tech> References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@vates.tech> <1793180994.8631fc262581453bbf619ec5b2062170.1a181ea8c1d000f79f@vates.tech> Date: Wed, 28 Oct 2026 18:09:20 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793207361; l=17954; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=0IoXOGAiLq08vJDn/DmoYnwhMNTOY/UXL05QGxKvh4M=; b=hwOFKgj7Gg9bBhJ0IWnv6Carj2mUW+rVr9gHhHHgL16qtbMG/F82YQ7t2ynZzSoziC+Kn5ssR AefL6xul9xBBjHr2FBKgHfMvaVyJyJtdKfYdiI/3zWXaQMKCnQWH01d 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: 1793207366440 X-purgate-ID: tlsNG-720697/1793207371-F12A12AC-FFCEF6AB/0/0 X-purgate-type: clean X-purgate-size: 17954 On 2026-10-28 10:49 +0100, Anthony PERARD wrote: > On Thu, Aug 27, 2026 at 11:42:49AM +0200, Baptiste Le Duc wrote: > > diff --git a/automation/scripts/qemu_smoke_riscv64.py b/automation/scripts/qemu_smoke_riscv64.py > > new file mode 100755 > > index 0000000000..f338fafcc2 > > --- /dev/null > > +++ b/automation/scripts/qemu_smoke_riscv64.py > > @@ -0,0 +1,122 @@ > > +#!/usr/bin/env python3 > > +# SPDX-License-Identifier: GPL-2.0-only > > +"""CLI launcher for the qtb riscv64 dom0less tests. > > + > > +The test type comes first (e.g. `console-test`), then a command. Each type > > +reads its own config file, which ships with the type. > > + > > +Commands: > > + list Print every test the type defines in the config, then exit. > > + run Boot one test's machine under QEMU and drive it to a pass/fail > > + verdict. > > + > > +Usage: > > + ./qemu_smoke_riscv64.py console-test list > > + ./qemu_smoke_riscv64.py console-test run dom0less-1smp-0domu-1vcpu-aplic-imsic-null Thanks for the review! > Can we change the usage a bit? > I would put `list` and `run` (the command) as first possitionnal > argument. > > `list` would list all types of tests, if alone on the command line. > And `list console-test` would list all tests associated with this kind. Done in v3: `list ` and `run [test...]`. Without a test name, `run` runs every test of the type (see your last remark). > > As for the comment of this file, it doesn't feel useful as it is. It's > currently a very verbose way to try to explain how to use the command > line, it doesn't explain everything, "usage" is actually just few > "examples", and I don't think one would look here to find out how to use > it, when running the script with `-h` can print something more standard. > > I guess here you could explain that tests from a config.yaml will be run > under qemu, with different parameter for the machine and different tests > to run. Done in v3. > [ ... 16 lines skipped ... ] > > +def _run_test(test: RiscvQtbTest, log_dir: str | None) -> int: > > + """Compile the machine's device trees, boot it, and run the test.""" > > + vm = RiscvTestMachine(test.machine, timeout=test.timeout, log_dir=log_dir) > > Naming that `vm` might be a be counter intuitive. Especially if you > intend to have nested VM later. My guess, `host` or `machine` would be a > bit better. Renamed `machine` in v3. > [ ... 18 lines skipped ... ] > > +def main(argv: Sequence[str] | None = None) -> int: > > + ns = setup_parser().parse_args(argv) > > + logging.basicConfig( > > + level=logging.DEBUG if ns.verbose else logging.WARNING, format="%(message)s" > > + ) > > + try: > > + return ns.func(ns) > > + except Exception as exc: > > + logger.debug(format_exc()) > > + frame = extract_tb(exc.__traceback__)[-1] > > + print(f"{frame.filename}:{frame.lineno}: {exc}") > > + return 2 > > + finally: > > + cleanup_temp_dir() > > This cleanup_temp_dir() is out of place, when `main()` doesn't create > this temporary dir. Instead you could have the main prepare an > environment, create temporary directories, and give that to the test > classes, and that in turn would justify to do the cleanup here. Done in v3: main() creates the temporary directory and passes it down in a new QtbEnv dataclass (qtb/env.py). The temp_dir helpers are gone. > > > + > > + > > +if __name__ == "__main__": > > + sys.exit(main()) > > diff --git a/automation/scripts/qtb/riscv/config.py b/automation/scripts/qtb/riscv/config.py > > new file mode 100644 > > index 0000000000..b5068d6bfb > > --- /dev/null > > +++ b/automation/scripts/qtb/riscv/config.py > > @@ -0,0 +1,119 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +"""YAML config parser for qtb-based Xen riscv64 tests. > > + > > +Parsing steps: > > + - validate the YAML > > + - build the dataclasses: the host device tree is compiled on first use > > + of MachineConfig.dt > > +""" > > + > > +from __future__ import annotations > > + > > +import functools > > +import inspect > > +from dataclasses import dataclass > > +from functools import cached_property > > +from pathlib import Path > > + > > +import yaml > > + > > +from .paths import resolve_binary, resolve_path > > +from .xen_dt import DeviceTree, build_xen_device_tree > > + > > +XEN_MMU_TYPE_DEFAULT: str = "sv48" > > +XEN_BOOTARGS_DEFAULT: str = "" > > + > > +MACHINE_MEMORY: int = 2048 > > That feels like a lot, how about just 512MB? Or do you need 2GB for the > tests? And why isn't it called *_DEFAULT like other parameters? 512MB is enough, changed in v3. It's not *_DEFAULT because it isn't configurable. > > > +MACHINE_INTERRUPT_CONTROLLER: str = "aplic-imsic" > > This isn't used here, in `config.py`. Either > MACHINE_INTERRUPT_CONTROLLER doesn't need to exist, or it should be > added to MachineConfig. Both moved into MachineConfig in v3 (MEMORY, INTERRUPT_CONTROLLER). > [ ... 50 lines skipped ... ] > > +++ b/automation/scripts/qtb/riscv/config.yaml > > @@ -0,0 +1,17 @@ > > +# Shared config for the qtb riscv64 tests > > +# > > +# A machine is the test-agnostic description of what to boot (cpus, Xen command > > +# line). Test YAMLs (e.g. console-test.yaml) pick a machine by name and layer > > +# their own parameters on top. > > +# > > +# Path resolution (see paths.py): `binaries:` entries resolve against > > +# $QTB_BINARIES_DIR env var if defined else `binaries`. Absolute paths used > > +# as-is. > > + > > +binaries: > > + xen: xen > > + > > +machines: > > + dom0less-1smp-0domu-1vcpu-aplic-imsic-null: > > + xen_bootargs: "sched=null" > > There's a document describing the Xen command line in the xen tree. It > is composed of parameters and options. Also `xl info` calls it > `xen_commandline`. While I understand "bootargs", can we rename that to > something more comment in this context? That is "xen_cmdline" or > "xen_commandline". Renamed xen_commandline in v3. > > > > diff --git a/automation/scripts/qtb/riscv/console_test/console-test.yaml b/automation/scripts/qtb/riscv/console_test/console-test.yaml > > new file mode 100644 > > index 0000000000..cec0edc510 > > --- /dev/null > > +++ b/automation/scripts/qtb/riscv/console_test/console-test.yaml > > @@ -0,0 +1,18 @@ > > Would it be possible to merge this config file into the main one? That > is "config.yaml". I think having a single config file for the whole test > suite would be easier to manage going forward. It would be easier to > look at a single files instead of looking for files in multiple > locations. Then we can just tell the main script which config file to > use, and the different class of tests won't have to guess where their > config file is. Done in v3: single config.yaml, one top-level section per test type (`console-test:`), loaded once by the main script. > [ ... 15 lines skipped ... ] > > +tests: > > + dom0less-1smp-0domu-1vcpu-aplic-imsic-null: > > + machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null > > + expect: > > + 0: ["All set up"] > > I wonder if configuring the machine here instead of in a separated array > wouldn't make more sense. The string > "dom0less-1smp-0domu-1vcpu-aplic-imsic-null" is duplicated three time. > If instead we had: > > tests: > dom0less-1smp-0domu-1vcpu-aplic-imsic-null: > machine: > pcpu: 1 > xen_bootargs: "sched=null" > expect: > 0: ["All set up"] Done in v3. The separate catalog was meant to share machines across test types, but I think with a single config.yaml YAML anchors could cover that. > [ ... 42 lines skipped ... ] > > +CONFIG_FILE_DEFAULT: str = "console_test/console-test.yaml" > > +DESCRIPTION_DEFAULT: str = "Assert expected string(s) are printed on the Xen console" > > "DESCRIPTION_DEFAULT", do you mean it can be changed? > > Just curious, is there a reason to have TYPE_ID and DESCRIPTION_DEFAULT > instead of adding the string directly in the class? (That is not using > TYPE_ID at all). No strong reason, strings are inlined in the class in v3. > [ ... 3 lines skipped ... ] > > +XEN_CONS_IDX: int = 0 > > It could be useful to have a description for XEN_CONS_IDX. Done in v3. > [ ... 21 lines skipped ... ] > > + @staticmethod > > + def _load_yaml(path) -> dict: > > + return yaml.safe_load(resolve_path(path).read_text()) > > This method looks out-of place, it doesn't interact with ConsoleTest at > all. It could be a generic util/tool. Or not exist a all and let the > main create a `dict` from a yaml and git that `dict` to ConsoleTest to > initialise itself, which is already how ConsoleTest is initialised > curently anyway. Agreed, both from_config() and _load_yaml() dropped in v3: main loads the YAML and passes the dict directly to __init__(). > [ ... 74 lines skipped ... ] > > + def _expect_string(self, cons, expected: str) -> None: > > Shouldn't `cons` have a type? Yes, GuestConsoleSession in v3. > > > + """Wait for `expected` on the console, retrying on timeout.""" > > + for attempt in range(self.attempts): > > + try: > > + cons.expect_exact(expected, timeout=self.timeout) > > + return > > + except pexpect.TIMEOUT: > > + if attempt == self.attempts - 1: > > + raise > > I don't understand the point of this function. > Why to we retry the `grep` on a timeout? Why is the original asked > timeout multiplied by "attempts" ? (which is effectively what is > happening here, more or less) > > Also, raising `pexpect.TIMEOUT` might not be the exception to throw. A > new set of exception dedicated for the Test* classes might be better, > and could easily been catch in the main function that run all the tests > (without having to import unrelated module like `pexpect`). No good reason, retry dropped in v3. Agreed for the exception: v3 adds TestFailure; ConsoleTest maps pexpect.TIMEOUT/EOF to it and main only catches TestFailure. > [ ... 58 lines skipped ... ] > > +def write_dts(text: str, name: str, out_dir: Path) -> Path: > > + """Write generated .dts text to /.dts; return its path.""" > > + src = out_dir / f"{name}.dts" > > + src.parent.mkdir(parents=True, exist_ok=True) > > + src.write_text(text) > > + return src > > I don't like this function, it doesn't do anything related to device > tree. It's just a generic that allow to write any text to a file in any > directory, even non existing ones, as long as the filename ends with ."dts". > I think whatever is calling this function should deal with the filename > and the directory. And that caller should probably write to an existing > directory. Dropped in v3: build_dtb() writes .dts into the existing temporary directory from main(), no mkdir. > [ ... 9 lines skipped ... ] > > + def _resolve_binary(self) -> str: > > + return str(resolve_from_path(self.qemu_bin)) > > Nothing is using that function. (In that patch at least) It's a QtbMachine hook, called from QtbMachine.__init__() (same for _machine_args()). v3 adds a comment on both to make it more clear. > > > diff --git a/automation/scripts/qtb/riscv/paths.py b/automation/scripts/qtb/riscv/paths.py > > new file mode 100644 > > index 0000000000..237f1bf502 > > --- /dev/null > > +++ b/automation/scripts/qtb/riscv/paths.py > > I don't like this module. Maybe some of those functions here could be > move to the qtb package instead, and rename the module "utils" or > "tools" or something else generic. Because nothing here is riscv > specific. Done in v3: paths.py is gone, the generic helpers moved to qtb/utils.py. > [ ... 7 lines skipped ... ] > > +import os > > +import shutil > > +import tempfile > > +from functools import lru_cache > > +from pathlib import Path > > + > > +# Every relative path in this module is resolved against this base. > > +_BASE = Path(__file__).resolve().parent > > + > > +# Build artifacts, overridable for CI. > > +_BINARIES_BASE = Path(os.environ.get("QTB_BINARIES_DIR") or _BASE / "binaries") > > _BINARIES_BASE is misplaced I think, as it's buried deep into the > modules. I would rather have the location of the "binaries" been set > from the start by the main script, then give the path to the classes > that needs it. > > Also, having the "binaries" directory location in a envvar is a nice > idea, but can it be renamed to be more generic for the CI ? > Something like "XEN_CI_BINARIES_DIR". Because this is a variable that > contained shared information between the jobs that build xen and other, > and jobs that run tests. Done in v3: main reads $XEN_CI_BINARIES_DIR and passes it in QtbEnv. CI job updated too. > [ ... 96 lines skipped ... ] > > + @staticmethod > > + @abstractmethod > > + def list_tests(config_file: str) -> list[str]: > > + """Return the names of every test declared in the config file.""" > > It's nice to have an abstract class, but can't we implement some > methods like `list_tests()` here? Otherwise, it's likely that the same > exact function is going to be duplicated in every kind of tests. Agreed. In v3 list_tests() is implemented once in RiscvQtbTest. > [ ... 8 lines skipped ... ] > > +++ b/automation/scripts/qtb/riscv/xen_dt.py > > @@ -0,0 +1,58 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +"""Build the Xen host device tree for a MachineConfig. > > It feels like both module `dt.py` and `xen_dt.py` could be in the same > module, with something that takes a templates and parameters, and > generate a DTB. > > But, seen that xen_dt access directly MachineConfig, maybe all the > functions dealing with the device tree could be in the same file as > the one declaring MachineConfig, or . Merged in v3: dt.py has a generic build_dtb(template, params, name, out), and RiscvTestMachine maps its MachineConfig to the params. xen_dt.py is gone. > [ ... 21 lines skipped ... ] > > +# Directory holding the Jinja2 platform device tree templates. > > +_DTS_DIR = "dts" > > Instead of having this hidden variable, how about making it part of the > config file? With full path, that is probably relative to the config > file location. Done in v3, see below... > > + > > + > > +@dataclass(frozen=True) > > +class DeviceTree: > > + """Compiled device trees for one machine launch.""" > > + > > + dts: Path > > + dtb: Path > > Is there any reason to keep the path to the dts? It doesn't seems to be > ever used. Yes, for debugging: Oleksii asked to keep the .dts in the log dir. v3 drops DeviceTree and copies the .dts into --log-dir when it is set. > > > + > > + > > +@lru_cache(maxsize=1) > > +def _env() -> Environment: > > + return Environment( > > + loader=FileSystemLoader(resolve_path(_DTS_DIR)), > > + keep_trailing_newline=True, > > + ) > > + > > + > > +def _render_xen_dts(machine: MachineConfig) -> str: > > + """Render the Xen host device tree source text for `machine`.""" > > + tmpl = _env().get_template("qemu-host.dts.j2") > > Same remark as for _DTS_DIR, "qemu-host.dts.j2" could just be part of > the path to the dts on a config file. ...`host_dts: dts/qemu-host.dts.j2` in config.yaml, resolved relative to it by main and passed in QtbEnv. > > > + return tmpl.render( > > + ncpus=machine.pcpu, > > + mmu_type=machine.mmu_type, > > + xen_bootargs=machine.xen_bootargs, > > + ) > > + > > + > > +def build_xen_device_tree(machine: MachineConfig) -> DeviceTree: > > + """Compile `machine` device tree into the shared scratch dir.""" > > + out = temp_dir() > > + dts: Path = write_dts(_render_xen_dts(machine), machine.name, out) > > + dtb: Path = compile_to_dtb(dts, out) > > + return DeviceTree(dts=dts, dtb=dtb) > > > > > There's something I haven't really talked about yet, and maybe it's too > much changes. I've had in mind that the main script > "qemu_smoke_riscv64.py" could run all the available tests (or even just > all the tests of a single kind/type) and report the result. This would > change a bit how the different Test classes are instantiated. > > It might actually be better for several reason to run all tests at once. > - It's a single job in the pipeline. > - which mean, all the time spent to start a new container, cloning > the xen tree, downloading the artefacts, cleanup; would be done a > single time, and all those step likely takes a lot more time that > the execution of the test. > - adding a test is easier, there's a single file to edit, and it's > automatically picked up. No need to also edit the pipeline as well. > - well, it could be a single job per kind of test, or a single job > overall. But one job per kind of test is probably better. > - It's easier to run the all the tests locally, just a single command. > > Having a single job in the pipeline doesn't prevent from having the > result of a single test easily available, for example all the > "*-tools-test-*" jobs generate a `tests-junit.xml` and you can see the > result in the gitlab WebUI, for example: > https://gitlab.com/xen-project/hardware/xen/-/pipelines/2994120991/test_report Agreed. In v3 `run ` runs all tests of the type, so one job per type. I'll add a junit report for per-test results. > I hope all my comments make sense, and would make the framework better. They do, thanks for your time! -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 28 17:17:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 17:17:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463498.1674350 (Exim 4.92) (envelope-from ) id 1xM7HP-0004Qf-Nh; Wed, 28 Oct 2026 17:17:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463498.1674350; Wed, 28 Oct 2026 17:17: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 1xM7HP-0004QY-Iw; Wed, 28 Oct 2026 17:17:39 +0000 Received: by outflank-mailman (input) for mailman id 1463498; Wed, 28 Oct 2026 17:17:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM7HO-0004QR-78 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 17:17:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM7HN-00As1T-K0 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 18:17:37 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae22e12-2eae-0a2a0a5409dd-0a2a4507c716-46 for ; Wed, 28 Oct 2026 18:17:37 +0100 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 6ae22e31-b4ea-0a2a45070019-b9ff1c2398bb-3 for ; Wed, 28 Oct 2026 18:17:37 +0100 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 1a183846ddc000f79f.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 17:17:36 +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 D0D7382407 for ; Wed, 28 Oct 2026 18:17:35 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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: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=64hFIy1A9jY1l5sWb0csc2BO07MAPXCthO1pwQHNXQs=; h=from:subject:date:message-id:to:mime-version:content-type:feedback-id; b=Gd2XuIcnhxfMrgp/NvyE6jdMXfZDxmYy7KK60IS02lJhbi9t91UWC3wpG6g1OOjOUuC7k0Fke eWmuoj4AmcMgLeZKOfDwFn291tookDJfghNXJrK/a9ZBRs3ElIEqr2l/3i4DIPHxJWmrMTIVBp1 yoBTIe92s86mlfInyyiWheGz4ZPrCusWMHzwxKm9glEOi4YNloz7EQQ2/1fY2hOB0W2/Yfwz5ko CnRAU5S2Z6k6fySxyp+2mwBf/6KpMUy/enFg2DFATMi0qPegTAlsrUfwEHA30i8ySt6vkynDVL2 a1/MVAIsTPlz+LdmPiKQOgMvWkrPlx5cvd3PDts+4gHw== X-Zone-Loop: 764a45984dcfb31de9aba8b3dd3ee891c9eba12c0c0e x-campaign-type: default x-transaction-id: 37271e25-392f-44da-bc21-741495d065ee x-swg-uid: 01-f482ac1b-8cac-4524-bdf6-864d155b63e6 X-Mailer: Sweego Message-ID: <1793207856.8631fc262581453bbf619ec5b2062170.1a183846ddc000f79f@vates.tech> x-swg-bid: 1793207856.8631fc262581453bbf619ec5b2062170.1a183846ddc000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 28 Oct 2026 18:17:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Xen-devel From: Teddy Astie Subject: [RFC] vPMU rework proposal 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Ima0ajx30A7vZprovN80ysg0" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793207855900 X-purgate-ID: tlsNG-ef75cf/1793207857-362C4AE4-7F633ECC/0/0 X-purgate-type: clean X-purgate-size: 9285 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Ima0ajx30A7vZprovN80ysg0 Content-Type: multipart/mixed; boundary="------------EDqgBOM9ETMq8NSGw8NY1l2o"; protected-headers="v1"; hp="clear" Message-ID: Date: Wed, 28 Oct 2026 18:17:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Xen-devel From: Teddy Astie Subject: [RFC] vPMU rework proposal 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 --------------EDqgBOM9ETMq8NSGw8NY1l2o Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkFzIG9mIHRvZGF5LCB2UE1VIGlzIHF1aXRlIGRpZmZpY3VsdCB0byB1c2Ug Zm9yIHByb2ZpbGluZyB0aGUgc3lzdGVtLCANCmFuZCBoYXMgdmFyaW91cyBpc3N1ZXMuIE9u ZSBpbiBwYXJ0aWN1bGFyIGlzIGxhY2sgb2Ygc3RhY2t0cmFjZSBzdXBwb3J0IA0KKFsxXSBl eGlzdHMsIGJ1dCBpcyBjb21wbGljYXRlZCBwYXJ0bHkgZHVlIHRvIEFCSSBzaG9ydGNvbWlu Z3MsIGFuZCBoYXMgDQpsaW1pdGF0aW9ucykuDQoNClRoZSBpZGVhIGhlcmUgaXMgcmF0aGVy IHRoYW4gZXhwYW5kaW5nIHRoZSBjdXJyZW50IGRlc2lnbiB3b3VsZCBiZSB0byANCm1ha2Ug YSBtYWpvciByZXdvcmsgb2YgdGhlIGZlYXR1cmUsIGNvbnNpZGVyaW5nIHNpZ25pZmljYW50 bHkgdGhlIEFCSSANCihpLmUgaW5jcmVhc2luZyBYRU5QTVVfVkVSX01BSikgYW5kIHNpbXBs aWZ5IHRoZSBkZXNpZ24uDQoNCkEgaW1wb3J0YW50IHVzZS1jYXNlIG9mIHZQTVUgaXMgdG8g cHJvZmlsZSB0aGUgZW50aXJlIHN5c3RlbSAoaW5jbHVkaW5nIA0KWGVuIGl0c2VsZiksIHdo aWNoIGlzIG9ubHkgcG9zc2libGUgaWYgdGhlIFBNVSBjb3ZlcnMgdGhlIGVudGlyZSBzeXN0 ZW0gDQooYW5kIG5vdCBqdXN0IERvbTApLCBhbmQgaWYgdGhlIERvbTAgY2FuIHVzZSB0aGUg UE1VIGNvbnNpc3RlbnRseS4gVGhlIA0KaWRlYSBoZXJlIGlzIHRvIGhhdmUgYSBtb2RlIHdo ZXJlIHRoZSBQTVUgcmVnaXN0ZXJzIGFyZSAiZ2xvYmFsIiANCihzeXN0ZW0td2lkZSkgYW5k IHJlcXVpcmVzIHBpbm5lZCBEb20wIHZDUFVzLg0KDQpJbiB0aGUgY3VycmVudCBkZXNpZ24s IHRoZSBQTVUgcmVnaXN0ZXJzIGFyZSBzdGFzaGVkaW4gdGhlIHBtdSBwYWdlLCBhbmQgDQpz eW5jZWQgb24gUE1JLiBUaGUgaXNzdWUgaXMgdGhhdCB0aGUgZm9yIHNldmVyYWwgIG9mIHRo ZXNlIHJlZ2lzdGVycywgDQp0aGVpciBjb3VudCBpcyB1YXJjaC1kZXBlbmRhbnQgKGFuZCBl dmVuIFNLVSBkZXBlbmRlbnQpLCB3aGljaCBtYWtlcyB0aGUgDQpsYXlvdXQgb2YgdGhlIHNo YXJlZCBwYWdlIGNvbXBsZXguDQpBIHByb3Bvc2VkIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRv IG5vdCBoYXZlIFBNVSByZWdpc3RlcnMgaW4gdGhlIHBhZ2UgDQphbmQgcmVseSBvbiBlaXRo ZXIgYSBuZXcgZGVkaWNhdGVkIGh5cGVyY2FsbCAoUFYvUFZIIERvbTApIG9yIGRpcmVjdGx5 IA0KdXNlIFJETVNSL1dSTVNSIChQVkggRG9tMCkgdG8gaW50ZXJhY3Qgd2l0aCB0aGVtIGlu c3RlYWQuDQoNCldpdGggdGhhdCBuZXcgbGF5b3V0LCB0aGUgaHlwZXJ2aXNvciBzdGFja3Ry YWNlIGNhbiBiZSBwbGFjZWQgcmlnaHQgDQpiZWxvdyB0aGUgb3RoZXIgZmllbGRzIG9mIHRo ZSBzaGFyZWQgUE1VIHBhZ2UsIGluc3RlYWQgb2YgYXQgdGhlIGJvdHRvbSANCm9mIHRoZSBw YWdlLCB3aGljaCBtYWtlcyB0aGluZ3MgbXVjaCBzaW1wbGVyLg0KDQpBbm90aGVyIGlkZWEg SSBoYWQgd291bGQgYmUgdG8gZXhwb3NlIHJkcG1jIHRvIFBWIERvbTAgKENSNC5QQ0UpLCBi dXQgDQpJJ20gbm90IHN1cmUgaG93IHVzZWZ1bCBpdCdzIGdvaW5nIHRvIGJlIGluIHByYWN0 aWNlLg0KDQpJbiB0aGlzIG5ldyBkZXNpZ24sIGF0IGxlYXN0IGluIHRoZSBjdXJyZW50IHBy b3Bvc2FsLCBlaXRoZXIgb25seSBQVi9QVkggDQpEb20wIGhhcyBhY2Nlc3MgdG8gdlBNVSwg b3Igc2VsZWN0IFBWSC9IVk0gaGF2ZSBhY2Nlc3MgdG8gdGhlaXIgb3duIA0KdlBNVS4gVGhl cmUgaXMgbm8gbG9uZ2VyIHN1cHBvcnQgZm9yIHZQTVUgZm9yIFBWIERvbVUgYW55bW9yZS4N Cg0KVGVkZHkNCg0KWzFdIA0KaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2Nv dmVyLjE3NTMzNzI5MjguZ2l0LmVkd2luLnRvcm9rQGNsb3VkLmNvbS9ULyNtOTUwN2FkODg0 MDUxNTUwM2Y3MzY4MjNkMGQ2OTlmYjFiOGZmYTdhMQ0KDQotLS0NCg0KIyBQcm9wb3NhbCAo 4oCcdlBNVSB2MuKAnSkNCg0KVGhlcmUgYXJlIHJvdWdobHkgMiAoZXhjbHVzaXZlKSBtb2Rl cyBmb3IgdlBNVSA6DQoNCi0gUHJvZmlsZSB0aGUgc3lzdGVtIGFzIGEgd2hvbGUsIGRyaXZl biBieSBEb20wDQotIFZpcnR1YWxpemUgUE1VIGluIEhWTSBndWVzdHMgKG5vbi1zZWN1cml0 eSBzdXBwb3J0ZWQpDQogICAtIFVzZSBoYXJkd2FyZSBmYWNpbGl0aWVzIChBTUQgUE1DIFZp cnR1YWxpemF0aW9uIC8gSW50ZWwgImxvYWQgDQpgSUEzMl9QRVJGX0dMT0JBTF9DVFJMYCIg Vk1YIGNvbnRyb2wpDQoNClRoZXNlIDIgdXNlLWNhc2VzIGFyZSBleGNsdXNpdmUgYW5kIG5l ZWRzIHRvIGJlIGNob3NlbiBhdCBib290IHRpbWUgaS5lIDoNCg0KLSBgdnBtdT1vZmZgIC8g YG5vLXZwbXVgIDogdlBNVSBkaXNhYmxlZCAoZGVmYXVsdCkNCi0gYHZwbXU9Z2xvYmFsYCA6 IE5hdGl2ZSBQTVUgZHJpdmVuIGJ5IERvbTAsIHJlcXVpcmVzIGBkb20wX3ZjcHVzX3BpbmAN CiAgIC0g4oaSIGxldCBEb20wIHByb2ZpbGUgdGhlIHN5c3RlbQ0KICAgLSBlZmZlY3RpdmVs eSBzaW1pbGFyIHRvIGBYRU5QTVVfTU9ERV9BTExgDQotIGB2cG11PWh2bWAgOiBQb3NzaWJp bGl0eSB0byB2aXJ0dWFsaXplIHZQTVUgcGVyIFBWSC9IVk0gZ3Vlc3QgKHdpdGggDQpgWEVO X0RPTUNUTF9DREZfdnBtdWApDQogICAtIOKGkiBtYWtlIHByb2ZpbGVycyB3b3JrIGluIGd1 ZXN0cw0KDQojIyBHbG9iYWwgUE1VIGZvciBEb20wICh2cG11PWdsb2JhbCkNCg0KR3Vlc3Qg KERvbTApIG9ic2VydmUgdGhpcyBjYXBhYmlsaXR5IHRocm91Z2ggKHRvIGJlIGludHJvZHVj ZWQpIA0KYFhFTkZFQVRfdnBtdWAuDQoNCkFkZGl0aW9uYWwgaW5mb3JtYXRpb24gKHN0YWNr dHJhY2UsIGRvbWlkLCBndWVzdCByZWdpc3RlcnMsIC4uLikgY291bGQgDQpiZSBleHBvc2Vk IHRocm91Z2ggYSBvcHRpb25hbCAoc2ltcGxpZmllZCkgc2hhcmVkIHBhZ2UgcGVyIENQVS4N Cg0KIyMjIFBWDQoNClBWIGRvbWFpbnMgd2lsbCBpbnRlcmFjdCAoZS5nIHdyaXRlKSB0byBQ TVUgcmVnaXN0ZXJzIHRocm91Z2ggYSBuZXcgDQpkZWRpY2F0ZWQgaHlwZXJjYWxsIChgWEVO UE1VX3tyZWFkLHdyaXRlfV9yZWdzYCkuDQpUaGVzZSBQViBkb21haW5zIHdpbGwgZ2V0IGBD UjRbUENFXT0xYCAoYXQgbGVhc3QsIGZvciAia2VybmVsLW1vZGUiIGFuZCANCmFyZSBleHBl Y3RlZCB0byByZWFkIHBlcmZvcm1hbmNlIGNvdW50ZXJzIHRocm91Z2ggYFJEUE1DYCBpbnN0 cnVjdGlvbiANCih3aGljaCBpcyBtb3JlIGVmZmljaWVudCB0aGFuIHRocm91Z2ggaHlwZXJj YWxscykuDQoNClBNSSBhcmUgZm9yd2FyZGVkIHRocm91Z2ggYFZJUlFfWEVOUE1VYC4NCg0K IyMjIFBWSA0KDQpQVkggRG9tMCB3aWxsIG9ic2VydmUgImFsbCIgUE1VIHJlZ2lzdGVycyBu b24taW50ZXJjZXB0ZWQgYW5kIGlzIGFibGUgdG8gDQpjb250cm9sIGl0IHRocm91Z2ggdXN1 YWwgbWVhbnMgKGB3cm1zci9yZG1zci9yZHBtY2ApLCBhbG9uZyB3aXRoIA0KYFhFTlBNVV97 cmVhZCx3cml0ZX1fcmVnc2AuDQoNClhlbiB3aWxsIGVuc3VyZSB0aGF0IHRoZSBQTUkgaXMg Zm9yd2FyZGVkIHRocm91Z2ggdGhlIGFyY2hpdGVjdHVyYWwgd2F5IA0KKGFuZCBhbHNvIHdp dGggYFZJUlFfWEVOUE1VYCA/KS4NCg0KIyMgUE1VIGZvciBIVk0gZ3Vlc3RzICh2cG11PWh2 bSkNCg0KVE9ETw0KDQojIyBOb3Rlcw0KDQpJbnRlbCBQRUJTL0RTX0FSRUEvQlRTIGlzIG91 dCBvZiBzY29wZSBhbmQgd2lsbCBub3QgYmUgZXhwb3NlZCBhdCBsZWFzdCANCmZvciBnbG9i YWwgUE1VIGZvciB0aGUgdGltZSBiZWluZy4NCg== --------------EDqgBOM9ETMq8NSGw8NY1l2o-- --------------Ima0ajx30A7vZprovN80ysg0 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+p0QLLz9AFAmriLi8FAwAAAAAACgkQZg+p0QLLz9Bb Fgv9H9/fpMOwND+alLLvXpnhMuts+scBAlj9ce4nXqHL7InwCgOJ8plR60unTIhjMvHPIOJRknG2 e+CpEP+tNwAiN/F+VYzsyk0V8EoHf0GYCPmWJaGrJRxGNGUPF7XHkdb12T7YDgsyhqQevCa1oQo1 qn6R4WzI2fKSFAmz+Jeb/BKbqJQz4fB0CuMYAsni1u9bzU0U8CKWXHBJEnmL5gKlIb4Y4yvXRdRg Bfe/SpcUy75c5GskekgzvIWZL4gKhPEkk/7kjZXHzfepl+IArw8ETTbT5KTm6GJ1xBPMQP3XaGZM dmqFW7iHV+Csl2bz8ORTbINz3Uc9Gf3AWfJyIo4UnA0fOSpfDQyDUOwfSCgabhQyjikW1KxSH5dp IZsnkJdWQevKIefUWV0T2UW92GV6srrjB2lSJUvs8jWfVDquoq/EJPqjRzhv8UglZdOv/MJJZ9SG StDAtbBp5vy6/pKJkomU+5vwzd/KlX1kUtm8pBIztiCWi/h1I1FlRx9b4VYt =9ODy -----END PGP SIGNATURE----- --------------Ima0ajx30A7vZprovN80ysg0-- From xen-devel-bounces@lists.xenproject.org Wed Oct 28 17:25:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 17:25:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463518.1674402 (Exim 4.92) (envelope-from ) id 1xM7Oy-0006oB-Ce; Wed, 28 Oct 2026 17:25:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463518.1674402; Wed, 28 Oct 2026 17:25: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 1xM7Oy-0006o4-9W; Wed, 28 Oct 2026 17:25:28 +0000 Received: by outflank-mailman (input) for mailman id 1463518; Wed, 28 Oct 2026 17:25:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM7Ow-0006nd-Up for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 17:25:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM7Ow-00379L-Bm for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 18:25:26 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae23006-2eae-0a2a0a5409dd-0a2a4502b82a-2 for ; Wed, 28 Oct 2026 18:25:26 +0100 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 6ae23005-6ca4-0a2a45020019-b9ff1c23b11f-3 for ; Wed, 28 Oct 2026 18:25:26 +0100 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 1a1838b89ef000f79f.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 28 Oct 2026 17:25:22 +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 B3D91805F9; Wed, 28 Oct 2026 18:25:21 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=sB4Of0MUQGjCyjXcJc7KE46pacPRIuyqQ8KXG8IOShE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=YuYUk+skgAuCnam0bsTX76gZgntJNU91Jr+Uf8U40gD7LPLr2zzdKKMtLuY5pi5YZ42b+/58t FISKF19eWZ4FymS5iq/tQtIGQ7Di5J4Q9LyrC+n+KTxP3/0OkdzW1xRylcyEeFa8lt4zw0kbqGH IUU4uO013G29dL/zw1EF4O582+lgjHcpy6097BwzdkqLaSkSPhTiriGunjc6UdAOfycDWeXRJvW wnyh+Zfa17ImBqPweuTJlKS/+rUbbvseBKSHsW04K3aqGj8CdP5uBEqZZuPAaxNa9NVmBTlErxl +e/RZhWffEsXCxsJYdyG3kVTTv2+fkk07+l6v5UKPC0g== X-Zone-Loop: ff594859417a5ed8bb58a98d07930a10bcd16976d26b x-campaign-type: default x-transaction-id: 138f977f-de93-48c8-9f3e-85d4e8df8ed7 x-swg-uid: 01-88285f22-b3db-4527-b758-7f0be3368d89 X-Mailer: Sweego Message-ID: <1793208322.8631fc262581453bbf619ec5b2062170.1a1838b89ef000f79f@vates.tech> x-swg-bid: 1793208322.8631fc262581453bbf619ec5b2062170.1a1838b89ef000f79f 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 v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither 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 , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang In-Reply-To: <35fa29d5-fafc-43da-a5a5-72df8f367e3c@citrix.com> References: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> <35fa29d5-fafc-43da-a5a5-72df8f367e3c@citrix.com> Date: Wed, 28 Oct 2026 18:25:16 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793208316; l=5839; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=1BinobBn/f1f9ULsMCPNN+bhYZDJFVHU6GJQjxxDJYQ=; b=9k9/UbrSt/gVOEBGfGfogF/hIIcvcwGX2duefQ9j8+aDwcQZReRdpdDhDR7EzGX6d9V3MF2M/ GD46gkqSuJmDV46O/SiORSorVFLL2SS8nSN0Fe9xcLoGUXwJ5saNDlI 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: 1793208321930 X-purgate-ID: tlsNG-720697/1793208326-30DC12AC-745F2266/0/0 X-purgate-type: clean X-purgate-size: 5839 On 2026-10-28 14:24 +0000, Andrew Cooper wrote: > On 28/10/2026 1:05 pm, Baptiste Le Duc wrote: > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > > index 3d5bbd2228..83d3bc5ddc 100644 > > --- a/xen/arch/riscv/cpufeature.c > > +++ b/xen/arch/riscv/cpufeature.c > > @@ -630,6 +632,53 @@ const char *get_guest_isa_str(void) > > return guest_isa_str; > > } > > > > +/* > > + * Probe whether hardware updates the PTE A/D bits by reading through an alias > > + * mapping whose A and D bits are clear. Observing A set, even by a speculative > > + * access, implies Svadu, as Svade only allows A to be set by software. > > + * > > + * Under Svade, the read raises a page fault instead, so use the extable to > > + * handle it. > > This is an internal detail, which can be covered by an internal comment. > > > + */ > > +static bool __init probe_hw_ad_update(void) > > +{ > > + vaddr_t va = FIXMAP_ADDR(FIX_MISC); > > + pte_t *entry = &xen_fixmap[FIX_MISC]; > > + bool a_set = false; > > + > > + ASSERT(!pte_is_valid(*entry)); > > + > > + /* > > + * set_fixmap() can't be used, as pt_update_entry() always sets A and D. > > + * > > + * A and D belong to the PTE, not to the page, so a new PTE with A and D > > + * clear can point to any RAM page, whatever its other mappings. Use the > > + * first page of the Xen image, and map it read-only so that Xen can't be > > + * corrupted through this alias. > > The function comment is mostly ok, but this one is misleading, not least > because it talks about corruption despite this being a read operation.  > All you need to say here is: > > /* Opencode set_fixmap() to intentionally leave A/D clear. */ > > > > + */ > > + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(_start)), > > pte_from_mfn(virt_to_mfn(_start)) I didn't use that, as it would require adding ``` /* Override macros from asm/page.h to make them work with mfn_t */ #undef virt_to_mfn #define virt_to_mfn(v) _mfn(__virt_to_mfn(v)) ``` as other archs do. But if you think it's worth it for a single usage, then I could do it. > > > + PTE_VALID | PTE_READABLE)); > > + flush_tlb_one_local(va); > > + > > /* Read from the alias, handling pagefault */ Will apply that in v11. > > > + asm_inline goto ( > > + "1: lw zero, 0(%[va])\n" > > + ASM_EXTABLE(1b, %l[out]) > > + : > > + : [va] "r" (va) > > + : "memory" > > + : out ); > > + > > + /* Order the load, and so its A bit update, before reading the PTE */ > > /* Check to see if hardware set A. */ It doesn't explain the fence, but mine doesn't either. If you think it doesn't matter, then I will use what you propose in v11. > > > + RISCV_FENCE(r, r); > > + a_set = read_pte(entry).pte & PTE_ACCESSED; > > + > > + out: > > It's better to name this label 'fault' because that's what happened to > use it. > > What happens if you neither fault, and A doesn't get set?  Right now > you'll report Svade despite there being no fault. I don't know if such a case is allowed by the spec, but afaiu, and we talked a lot about that with Jan B and Oleksii, if we don't fault then we should report Svade. > > You might or might not care to cover this case; that's up to the RISC-V > maintainers as to how likely it is to encounter in real life. I'm waiting for Jan B's and Oleksii's opinion on that point. > > But, if you do want to handle it, then you want something like > >     asm goto (...); > >     if ( 0 ) >     { >     fault: >         got_fault = true; >     } > >     ... > >     if ( !got_fault && !a_set ) >         panic("Neither Svade nor Svadu !?!\n"); > > > The if (0) is a bit ugly but it's the only way to avoid needing a second > label.   > > > + write_pte(entry, (pte_t){}); > > + flush_tlb_one_local(va); > > + > > + return a_set; > > +} > > + > > void __init riscv_fill_hwcap(void) > > { > > unsigned int i; > > @@ -674,6 +723,28 @@ void __init riscv_fill_hwcap(void) > > "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " > > "wire up this platform's pause equivalent in cpu_relax()\n"); > > > > + /* > > + * The privileged spec allows exactly two schemes for updating the PTE A > > + * and D bits: > > + * 1) hardware sets them on access and on write; > > + * 2) accessing a page whose A and/or D bit is clear raises a page fault, > > + * so that software can set them (ratified as Svade). > > + * > > + * Every implementation uses one of them, but may predate the extensions > > + * and advertise neither. In that case, trust the hardware probe. > > + */ > > + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && > > + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) > > + { > > + bool hw_update = probe_hw_ad_update(); > > + > > + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, > > + riscv_isa); > > + printk(XENLOG_WARNING > > + "Device tree advertises neither Svade nor Svadu, probed %s: add it to \"riscv,isa\"\n", > > + hw_update ? "svadu" : "svade"); > > This is overly verbose, including details that absolutely shouldn't be > the boot log. > > "Neither Svade nor Svadu in Device Tree - probed as %s\n" I agree with Jan on the point that it doesn't give any hint to the user. What do you think of this shorter version: "Svade/Svadu missing from \"riscv,isa\" - probed as %s\n" -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Oct 28 18:07:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 18:07:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463551.1674412 (Exim 4.92) (envelope-from ) id 1xM83Z-0005Ui-Fq; Wed, 28 Oct 2026 18:07:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463551.1674412; Wed, 28 Oct 2026 18:07: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 1xM83Z-0005Ub-BD; Wed, 28 Oct 2026 18:07:25 +0000 Received: by outflank-mailman (input) for mailman id 1463551; Wed, 28 Oct 2026 18:07:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xM83X-0005UV-If for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 18:07:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM83R-003s52-VQ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 19:07:22 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae239bf-bab6-0a2a0a5309dd-0a2a4502a19a-26 for ; Wed, 28 Oct 2026 19:07:17 +0100 Received: from [40.107.200.5] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae239d4-6ca4-0a2a45020019-286bc805b133-3 for ; Wed, 28 Oct 2026 19:07:17 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH5PR03MB7981.namprd03.prod.outlook.com (2603:10b6:610:20f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Wed, 28 Oct 2026 18:07:14 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0569.007; Wed, 28 Oct 2026 18:07: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=l4S/BeO9cjtJiRygEQ9KFnkrBX6FQ8x+U1R4lXdUF3pjBh+oOgSC3qXV4roXntQANUHZ+gVwTNROMu8X0i8Vt1d4JCA8b7rHR7Na6IywqkWrQh1lutXzNNYhe0G5E4HOjFHoR1mjgjy7FXa1XCYvHJImhtmDC4PvItuCNspD1RLzouK4ouTnODgIiewXtYHBiESkhyLUssv9v8LaI7yzg+VQHxGuGNE3f3DgwZgWHZQcXRjGxIPPFPWrtJ5TRSn0yYQWQ+VW6SqsMv1xuJiwDEQGZr2TqVUjXcPM1Mx7HjGKolFrcTB5qR0HvNY/eWMTQp/4rl98lvtsfownt8IlMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SCQjdIPg/E+subNw9B1h4jEB9D2tYCtlMQx/vMOTdSk=; b=udkwfEbsiK+2Lms92nJbfDc2jbu4Qgwg5jE9K5Go7X6tvrE2nJcWgXsAbxOxyrsb+9iJecMCcIc2kwSgM8W7lh6vyAsTOyCm1uB1BLx/fYAxXGmqmgHMqvTYfCwJNL14N5OH/KoX350gA6t/K2g3mkeC0xMqDdUPNWBdaBG712jXBYpCg13k3IXE9rebApj5qXKlDSxo4dJ6twZXoxIKv0u+pEMGYHhAuhy8bXMHJlXTP8GW3JTqSnt9ZHUiffzGTb/V2PrwEbDZEcLe45I6ZUItEA/PvQ2oTk4LmuQA7CSoFIvBN33m/3f/qd4zDU9Me0a3nC2WGihM7PzWjeTJig== 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=SCQjdIPg/E+subNw9B1h4jEB9D2tYCtlMQx/vMOTdSk=; b=nBeHHkng6GjapPPsKLqZDayI0aNuC1id+AxwC//N6+7vM8oaXpia6g94kkl60Jtipb4aWYF1d2d06XawuOM4dVwynICZTpvlrT/RPWtZ7qLNvc5x2kMJnonaUehYUvtKY785O9QCtrX05W2zsQYQ9BU9yjb6CDXKTHl2Gi4apGg= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <78279123-37d2-4acd-85b0-2bfe1fdf61d0@citrix.com> Date: Wed, 28 Oct 2026 18:07:11 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel Subject: Re: [PATCH] xen/mm: Remove loops in get_order_from_{pages,bytes}() To: Jan Beulich References: <20261028124104.1564435-1-andrew.cooper3@citrix.com> <7128c617-9432-4571-9b7a-22d6f6e8d884@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: <7128c617-9432-4571-9b7a-22d6f6e8d884@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0255.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::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_|CH5PR03MB7981:EE_ X-MS-Office365-Filtering-Correlation-Id: 28c3d9ad-3902-4928-5d30-08df351e4b91 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|260925021311599003|260925022911599003|260925021911599003|261021121427099003|56012099006|4143699003|5023799004|11063799006|261009223027099003|261026121527099003|261021135927099003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: uEPxAGudSP6050Co0Kb7pwaBorZ1zuMo6dCwcu7YuVvSkhWBfZQTEzmKRlyu3Z4VL/necB/wZI4OKbrehY6IDIpSfqNfa9yeCNJ/tVbYpIV6UlwMcV6/c9br7CiZuIj4YA9WlONXewrRFEXe7yzbXm7SvlwnWnM3HQh8DP8nuct9Of9DJUKjEwxKYND6HBh3HufTmQH9zia9cj1TnjTbUsFIphuz7ho9aSJKkDE+QwcY/wbgBMM6a+yrDnncNRQpMMa4osq5jkwSHT0KrGyTKc210gN8csWrauQW+j4whBOWtSTwv26P7mCr+m7jN3AU9fCAFNDRumECPwGR0vV3AnxhuJ8JGZzQnPZdjRikyf43HOk4/sxEDqCVXclblCr73bFfOE22UZGKr4nRZK2ZfppDtS70ClajzGE2II5Aa0SDZuSqWsjHCIDc01JWVSeLJmfiz9l+ueYiQo+1IAv8JUSnGqTb3INv607C2R6Z/1ToSZv7aoUkBlKo9nOUP6XyD9vSVMXrMTLIQ2HwkP44POpjDkaPr4AeeEeTr9+a02jBw5PR+9yhVmZntRs87tRvLL1PPhmRrz3gcumjtOn4loRUTeMqLp23O0TcxFjs/FDc5u9N65xotrIVgywNYB1e1+9eK8lgX5x+mNPv43FgKiS9IisG3z/46KP1uYhcizU= 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)(23010399003)(376014)(260925021311599003)(260925022911599003)(260925021911599003)(261021121427099003)(56012099006)(4143699003)(5023799004)(11063799006)(261009223027099003)(261026121527099003)(261021135927099003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bVVhb3FqcVBRYjdyUDY3b0ZLdDNUdXRwUU9jVGRySTZIVVBkZVNDUlJQYmc0?= =?utf-8?B?LzFVM0tDVGFadklHcWdBUlQ4Njk0ZjFCMEhQZTEybUlCNFRSS0pSS01SV1RT?= =?utf-8?B?Yi9UNmVPTHVGcjI5bW04eXluRkJZL0h6aU5aVURnb3JIRndNTmsrSFBLd0FE?= =?utf-8?B?TEYramZCaTBaSTVJUlVQNXpCRkFXcFcvdVllZzNyRVJGTHhhQlVRYXZXbHN4?= =?utf-8?B?amV5N3JqWmFjM3ZFUWFOaDBUN0d2eHRZZEc4Wk5rZTRTMWxkeXZSdVVLQnNi?= =?utf-8?B?QVNTNjZEVXQzWDBldzBjdm1nMWFnNEtOeFZIQW13OWdTdXQwU2lrb3kwTU9E?= =?utf-8?B?ZlVBbUR3bzlqZFBOVHZHR2tMUmdYWTdNbEI4TVlmZUhqNjhYSThVT0pGKzJy?= =?utf-8?B?b3BubTRWV1h4bnU1VFdKeDhBekZjaWFzU2RTMjd2SEpIQXJOeSt4cEtRLzlw?= =?utf-8?B?dDdQUFZwU0prS21HcjZ6UW5qZmFLUkFQMjg0V0daRFM3cnMvNHVrTmkwbjRo?= =?utf-8?B?Wk02Y1VGNEdBWFFsVXhxellnakhxZ1Bua3o3a1ArUENoSXZzd1E3VnMwOTJO?= =?utf-8?B?NklrZ25jcm5EeXFiY1BmT3EyL2wzb0xBZUtOZzRaNm9BUnFKcFZySjRoNTRE?= =?utf-8?B?Y0VJTmx3bklTaXpnV2lBWDFZcUdjWjNOR0k3cWFJaHRUWHZITk9BV0tLZEVC?= =?utf-8?B?RGVBUFpvTHJCcmwzOE1SR1hpUkRzMmdoTmJHVVJyUllVVWZPSTBmTDMrL2Jl?= =?utf-8?B?ZnFjM0lwTTUyRnc5dUU1QmlWTjJNOThaeTNZRnp3WmtyOWd3d1d4QVFZT0hF?= =?utf-8?B?REFldjd0SU1LODk2ZG9XaWpTVzJSM3MyNmZlTmxJbE1yL21rdGFJUlBTYlpq?= =?utf-8?B?T1M4M2N3cFA3Mno4ZDZ0VldhaitLUjBZRE9rOHVhay95TzNUZm5aTkk3V0Zo?= =?utf-8?B?V0J4NTFIMlhNajFaZFdDTGhhVlRxSU9QOUkwdVNvQ09xbHpQTGVWMnMzVk8x?= =?utf-8?B?dXg5MG9Jd0RoNDB5THhQY3VHVitRVmdSSDRoZlRZaTA4emdwRndtQlVhalRq?= =?utf-8?B?YUFPcUVWQnBOTzB1SUkrbVpsdEFyeXJYTExHQVlNcWFoT2w2WjNXTGJsRTZO?= =?utf-8?B?S1h5azhZWTRyMjhxZkJzdG94bU45MG8vUkVNZlFIYmU4N2Y4SHJPUmZ0THlj?= =?utf-8?B?YWJCazdNZTM3Nk9mamh6Z1VjbTRJRGFlM1cvejN0bThJOExWVDFOaU05WXE1?= =?utf-8?B?SEpITTdZOUJxcHpaSURwV2oxMFlUK0hLdUpleG9sa29YMmRBRmt1VnduSVBn?= =?utf-8?B?dFJJVUduTnJUUTJFcUxrMUNwbXFlajdNTzR6Uit3cFhnckFvWnBYMHhzYXhY?= =?utf-8?B?dTN4VWYxcDh4c25RK283U3MrZ292Q0ZsNDJQVjgyck85azc5WVVxOWI0SWdD?= =?utf-8?B?TC9OMXl1WnNaT0FiS3k3TEZ0eXdpNEZHZUFBemVnVUM2QzU4NjRLWTlJWUpT?= =?utf-8?B?MUxzbFE5ekw0NkpUbU5CeXdWNk05TnJ3MU9xRmd6RkN3SjBvdnhmbWNiOTl3?= =?utf-8?B?VnpuMDFEcUdjUFBBd2hFdTN3bzRZemU5bDNpU2N0K1BUNUZYWmRmLzFwY3JT?= =?utf-8?B?ZXdwaEQxMFZhb2lCVVY5blpSSDdzT2hUMjRNSndVY25qb1FBeU1ua0twYTNZ?= =?utf-8?B?L29ZTVhkQlZoNENHMUtoTmNwaC81cmpuTjVMVVlzR0FwZWtsdE81aEh3am9i?= =?utf-8?B?Z0c3SEU5TWZpWHFqcUh1MUxtdVlwanFIWllpcHRWSUZndVNoalNRMnB0M2F4?= =?utf-8?B?RFVWMXNmc2N0YTl0L3Y3eGl4TUZ6OWEvV3d0SUtnZFd3Y0ZWWkRjOWJjeWpD?= =?utf-8?B?QmdQYTIvZktBcDN5b0F3bDF3eStaYWEyM2lTY3R0dnRuRk9Bd1hhQUZFcWRr?= =?utf-8?B?aGdhbTNTT3FMZFlyVG0rdllTREhBUnF1Z2s2TDg5MU9ySy9WRk5kOTIySU04?= =?utf-8?B?VE9TazV1dHJtWU9MYytlME1KVVhKam1IdVVXdXJ2cEs5bnExdDRVK2c4b2sy?= =?utf-8?B?NTVDOVBqYlBlV2N2OHFid1hhZUFTdFd6QzlHZml4TExpOGRhOC81Y1lORjQw?= =?utf-8?B?RDNzMW1rUTVuU3A5Y05FWVBVN3dBSnlkMmVSd0R5aVZJZkRpa0hCSU9zSEY0?= =?utf-8?B?c0taSEdjZmZtQnJJNnV1U1hnL3RoQm1FWUhpcUtteDNrUWc5Zkt0Sk9WSzVB?= =?utf-8?B?QjlacVFIK3p5VVI2clVtSlVDSTRVNStrbkJjVWVXMjloTlAxMjI0SnhJVHNp?= =?utf-8?B?NXFzNjBEVlAvU1RQSHpZRExTRCtQQWhNUWozdDlIMllWSmxSQUNidz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28c3d9ad-3902-4928-5d30-08df351e4b91 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2026 18:07:14.4722 (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: L6DxS8lfzOnYFOHAvHULBdLWcrNgl7Vcy2/dYRwC79AG3pW8OJ6v2T5AEVmBDlgLFMaE+PV7oo8wMaVJzdqCNdAJskUs6rqaBRickMFw6z4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7981 X-purgate-ID: tlsNG-720697/1793210837-662A92AC-37A8BFC6/10/78276251493 X-purgate-type: spam X-purgate-size: 2881 On 28/10/2026 2:15 pm, Jan Beulich wrote: > On 28.10.2026 13:41, Andrew Cooper wrote: >> These two functions are just fls() expressions in disguise. Furthermore, >> GCC-12 at least won't const-propagate get_order_from_pages() with an input of >> 3 or above, which covers most of the cases it gets used for. >> >> Rewrite them, and provide some self testing. >> >> Interesting, unless they are always_inline, GCC has a habit of out-of-lining >> them even when inlining would have been a win. I expect this is to do with >> the fls() functions being superficially more complex. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Anthony PERARD >> CC: Michal Orzel >> CC: Jan Beulich >> CC: Julien Grall >> CC: Roger Pau Monné >> CC: Stefano Stabellini >> >> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2999078934 >> >> I think paddr_t is the wrong type to be using in get_order_from_bytes(), and >> so really is fls64(). > What other parameter type would you suggest? size_t is suitable only to express > virtual address region extents. uint64_t directly. > >> I could add fls_g() which would be slightly nicer on >> builds where paddr_t != uint64_t. > We have ffs_g(), so adding fls_g() would only seem natural. But see also below. > Either form: > Reviewed-by: Jan Beulich Thanks. > >> --- a/xen/include/xen/mm.h >> +++ b/xen/include/xen/mm.h >> @@ -530,26 +530,16 @@ page_list_splice(struct page_list_head *list, struct page_list_head *head) >> list_for_each_entry_safe_reverse(pos, tmp, head, list) >> #endif >> >> -static inline unsigned int get_order_from_bytes(paddr_t size) >> +static always_inline unsigned int get_order_from_bytes(paddr_t size) >> { >> - unsigned int order; >> - >> size = (size - 1) >> PAGE_SHIFT; >> - for ( order = 0; size; order++ ) >> - size >>= 1; >> >> - return order; >> + return fls64(size); >> } > Along the lines of what you do below, perhaps simply > > return fls_g(PFN_DOWN(size - 1)); > > (and nothing else in the function body)? And then even > > return flsl(PFN_DOWN(size - 1)); > > (eliminating the immediate need for fls_g())? Neither of these are quite correct.  fls64() can't be downgraded to flsl(), as it would truncate the input on 32bit builds of Xen. If using fls_g(), you need to modify size absent of type promotion, which is why I left the expression broken out in that way.  (I did actually do fls_g() first, then remove it to shrink the patch.) I think for now I'll go for the patch as-is.  Any change along these lines want to be separate anyway. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Oct 28 18:22:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 18:22:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463572.1674421 (Exim 4.92) (envelope-from ) id 1xM8IE-0000iE-Po; Wed, 28 Oct 2026 18:22:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463572.1674421; Wed, 28 Oct 2026 18: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 1xM8IE-0000i7-L5; Wed, 28 Oct 2026 18:22:34 +0000 Received: by outflank-mailman (input) for mailman id 1463572; Wed, 28 Oct 2026 18:22:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM8IC-0000i1-R5 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 18:22:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM8IC-00ByEP-81 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 19:22:32 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae23d3a-e002-0a2a0a5209dd-0a2a4508dd80-40 for ; Wed, 28 Oct 2026 19:22:32 +0100 Received: from [40.93.194.60] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae23d66-f659-0a2a45080019-285dc23ce739-3 for ; Wed, 28 Oct 2026 19:22:31 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6556.namprd03.prod.outlook.com (2603:10b6:303:127::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 18:22:25 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0569.007; Wed, 28 Oct 2026 18:22: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=IzpwJQIOFFZzUr6i2Ld2np2IuoYjj0pmPGuoWLd2vtvVf1lotv7/BiJcNQxG7r2yft8/PMou1ztUmsD5s1TXWTwLljtPySydw0x9vgyiRiYanrrZcWBZbscByPA15ziONkf71rXgcboU+kziOtpU1DXdy6JSx599OOzpJpr0oYPWvt7WP2A9sYr4RmPGM3D6QpAed1grgUhL8MIyWQuJcX7mBy/+73U8BKkp29v0mwaf0ap01bYVKxyv1kmckj/U9qtGwPIwLKfmKztIsv3eaSLU6zlhkPTNBDeNX1R3JnL5Xo8a6acTHWaXeyr2Ze1oxxDiVi8w3fdmB8HBMYupIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7EKdRDJCHvH+5SiIpb8tn4PDHl1vBoSPzSkLtGMpYu8=; b=YdwJsbxZJgO3HVBwzggInXbgv89RCUOqn/TUK8nsZFu79Q+MJ3iRr9duhOXZRSWWZqAVBZzoLWykdJpZgZOrICTm5iRKt4RPYZR9nctBL070GLQ//A4rMpNlVHGvY8JO2mcy4AuRBPOtOtZV013KWqEyuOqltXydDMcnT+WGiQZFhMDdZm/rT2igkX3pPInEF8549UvpqmFJFo6Ufb7i9WTetX8JNAc/BJA0iECM7dAwOFKUw5ioM8PsR3TdB6Urk0SdSO4nSqhVr4muBWWmypl7ZqkuZ81UidgPzC70fqZosx3Ia8/YrM9sHu8zFqdCsF2f68P0Hc9u4LCy3+qkPg== 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=7EKdRDJCHvH+5SiIpb8tn4PDHl1vBoSPzSkLtGMpYu8=; b=mRCqt12TVlud/rlYB4ND8GKFo6Ka0VS09p9ZjQYLgwf/v1uNCeWyyuhzMcmHr9FncV+EqmCWVQ3LYsazzQJdIFDZsMaGS39hlkYnR1PLG5b4TTyh5u/hQQcxDX4AJUx7zrNWoAOq/AZY+HBgGhuvEr21vOFP9p7f5BHtVxspYO8= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <290dd295-bd1c-442a-874c-de4565932da9@citrix.com> Date: Wed, 28 Oct 2026 18:22:21 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org Subject: Re: [RFC 0/5] Introduce dynamic tracer using Livepatch To: Ryo Takakura References: <20261028080841.118926-1-takakura@valinux.co.jp> 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: <20261028080841.118926-1-takakura@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0132.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c6::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_|MW4PR03MB6556:EE_ X-MS-Office365-Filtering-Correlation-Id: 3448036c-55d8-4e1e-3afb-08df35206a82 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|22082099003|18002099003|261026121527099003|11063799006|4143699003|56012099006|10067099003|261022105027099003|261009223027099003|261022075727099003|261028144727099003|260925021911599003|261026140227099003|260925022911599003|260925021311599003; X-Microsoft-Antispam-Message-Info: DW7fdk5WU5Xw+wih2xarXjYTyQj7ztcZKYqSQL43pzHLU1sv43aIXfYReSu2ErZMFC7HwALbfOguaZurQ7pL1GAxsmyt/knfdMGYcPGWTPhDFabDTLV44WZv1HVRwK9VwqeQZf8Ama/RodYB1fooF2qOl0agb2UhLXqfgtOV8PMJripiJ+Bsk5A/bsiDVNtANKF03VO8W583j5Ofy0amJpRs/R0KN/5HjHnpCgP7OXIeZnjuxkAQICDDyDun9OO9VNEPfcjmpuApXjNNUl9pboJOBcY0/Vu3nSCsMyT9DCRg6xyw2KcVAAU183LlplnQfHm6lvPZ05AtGfupuAPveNTskZdGVqO64SeH8BlbF+LJcGNEPWXnKWU5/eScLjaNo7m7761IWbzgUXnO5Tpm1O7tqXtCC2S445JTZRPoKfvqbu8e7Oold0bzrqNGIl8s8JkoSEBcbDHSr+SipANXhWfL50yvU0e9JYhZNsf5CNAjEapoW76omLMYy7vqAd39z6PdZNFXEOtffuPcMVtaZ5jPmgWrT50I3U553VhT7bfjif2Vc0otuTsaI+JAHQa7AR8iLtW/OdKIKsgO8iCf372rXcLAgAkQjpKpOlYzj+s2MJZGXtmtePdD5YYlWdM1/wOX5Dukv0BhS7fzi/MVzH6Zq+mOGAgnZVTJfepT61Q= 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)(22082099003)(18002099003)(261026121527099003)(11063799006)(4143699003)(56012099006)(10067099003)(261022105027099003)(261009223027099003)(261022075727099003)(261028144727099003)(260925021911599003)(261026140227099003)(260925022911599003)(260925021311599003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eStBUVlERy9RUEZBMDByWjJ4U3dxcVZleDFOcjFFaVFKZkRlTk9VL2JKdGp0?= =?utf-8?B?T1dVMkxKeXN4cWFYc2tqVHFtS0p0YjNEZUpBSlluTTFqYStkQjVXbWxqNDVn?= =?utf-8?B?UktOdVphM2dvYWV6aVVVOHExb1M1WWpHZ0tmYkVhY3BvbDRxMXJ2YUFDVmRL?= =?utf-8?B?d1BRWWdqdk41N09ibjk5NWRqeGl2eDNic285Q2dKb1lCeGxGbWJOR3NIM2Nx?= =?utf-8?B?Y0hIY0NxZU5xczJmaFdKOGxyRzNNV0tEaUdZaGJYMWh1V3RiZUYyeXpzeVQ2?= =?utf-8?B?eWdkQlJOeTFsZEgyaWdqOXEzeXhRK3hrSFhOWUpETE9LZWVoMnNjMHd5TVpX?= =?utf-8?B?VG45NUZtc0dMYlptVXdVVW5GS0FnS3g3VWZhMWNkRWp2amNhUVRzZFplaVo3?= =?utf-8?B?VG1RUmwrN1UyQ1lBSDcvdmhLeW43bWpHMVlJY29lZ2NCcGlWNzZjWkRVZk1C?= =?utf-8?B?TEhCRDM4RGpwU3hldVFMblhiU2EyWjZma2MrZlpGNEptWlV4MTBFcTJtM2dS?= =?utf-8?B?SXNRdU9BUTB1WWtETVA0TG10Smx3STZLUWdTKzhDMno1aTdxbTNLR1pwK20r?= =?utf-8?B?TnY1cmxhc2RVZjJxamI5MHAxTVZJVEpUTDRqajZxeWh6dmVTWUxaUjJFWnFL?= =?utf-8?B?QlRqNFJHeGI2ekQyRlFyVkFUVWRIS2E0R294ZHduWERJaHRFSzNVN3NQUWVP?= =?utf-8?B?SUJHMWYzL3NmcVYxS21mekVlK2pVaEZzZFRaYzdoOVh1eHRSbGd2OHpBRjI0?= =?utf-8?B?aDJmZVBrNldLRUZldEpPdThLSTVxWWVvOURyMU96NGhsZlh2TFRtb1dKUDZC?= =?utf-8?B?T2k2VXhUV2RDai9lVE1rblF0UEV4czEyU2JFWUFNbDI4aW11d0dySm1USlBF?= =?utf-8?B?amxsT1R5RUdMU2FsQ0xsblErUXc5dEx3ODB1aW1MMzVhSURvbkJQK0NEWE5t?= =?utf-8?B?N2tVQWlSTTk2UWxLY25QZURYWTZNdHNHc3FicUxoR2FOTHZPcVdMdUlUeXJ5?= =?utf-8?B?R2xxYlBwK1phZzJ3YTFTSDduUWtSWjJubzZmZlA2TzViQzNzNnJKSWVyd1Va?= =?utf-8?B?YWMvSHhsTkNrRGs2RjdHOHBmVjJHbVFtanlPMmdWUDdQM1IrSHRJRHVFeEE0?= =?utf-8?B?UWFvcjNuNnkyYWQ0YkZhbnZkb2NzRkZGb280VFRRMXJDNFVrdzVjTmZFSkhw?= =?utf-8?B?cktaSUNjeUU5N1pZSG5HQlJhWkVNR0hIaHF6b05MOXNhN01vYU1URHMySnRi?= =?utf-8?B?Qmh1RW02OFBhV3lSMjUxQXZlRmhkY2pYRzZqWUdaSFBGcWlYOFNsWEVTM1lS?= =?utf-8?B?WHg2dHBicGhvd1lyams0dHVyd0t0SXBXbWZTWEtTWjFFbXNaeGVYSmU1cmdq?= =?utf-8?B?TytSV1h1bFFqK2RWK2FKejhtTGFLa0pVNVgxbWhpSE4xK2tvZ0FiL2xaUld2?= =?utf-8?B?bU9wY0V0dzkxc1I5Tm1kemkrSnJsMVR1Z1ZrL2V6MHU1TVJDM2F2SnJnRnBj?= =?utf-8?B?TjQ4Q0dUZE1XZ1FCZ2M4TkFYamE3bE5abGNraGFzYVdzVUE2L3FMdXJMaHEv?= =?utf-8?B?Y3ZXMmltNVd5Vko5VytLVXhFdnhVMUMrTDM3WVFMc05adXR4VVhaSUlheEJY?= =?utf-8?B?c1JXNWNIUnl3NGJrTENjS0krWExaNm9SeFdSenByNlJEQTFTdXpKaWdsWlZt?= =?utf-8?B?N1E0UE5BMzJIVnhmemhGOFVPRHdQU3Y0MCtYVVdmRXVuRVUzZ1dYTUVhNStZ?= =?utf-8?B?dHFMWjBSZG44YXRQRW5rekZERW1ycEY1SnROVHJUN3lDeEQ3bXBVcWJ1aVls?= =?utf-8?B?U1ZyRFgzekMxVkJHQjNUUWFHblYxcytTbzAwN3B1K1U4bWRuTTBqZzlMU3FD?= =?utf-8?B?ZlhNTjE3T0taRUdOaGxROEZFc2thRHdjbWdSSEExSUpVdnFnZURwMUhHL0Y3?= =?utf-8?B?ZWd3ckl5aXJZSzFPUnlET1N4b2dtaHFjeG80Rmxpd1R5OFJYb1BkVC8zYkc4?= =?utf-8?B?bFhweVhLd3dXY05yclcwQ3RYWElxU2NESTg0SU1kUVBnb2JCeEl6ejBjcUh2?= =?utf-8?B?V0liZzFReGN2ck1FeWozcjIzblQ4USt4UElyVHhydjRWMklZUnYyRGJBS1F0?= =?utf-8?B?TW42ZW9SL1h2YkJLclU2Ujl0Lzl5UFlRNGZwRlM0WFgrcHAxYmdyNndvYlZn?= =?utf-8?B?TTJqYlpLV1RWRURjYmxhZUpHdkdrRTFYSGxFN0FQK1ZoaHRkUzlLc0M5TGVv?= =?utf-8?B?T1Fsdk9HQXRVK3VtQUZTOGd3TW9jYk8zU2NzTnE4R3RHNkp2L3lkbkh0c0Jq?= =?utf-8?B?cVcwd0dyRC93cGNKWisyNEsvYXhxa09YNy8rREFlS1p3UkdjUHUwdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3448036c-55d8-4e1e-3afb-08df35206a82 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2026 18:22:25.2881 (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: aHJsZi/6fwOd8B22at/rcLu6/9XwC73wcHAMRP7/Yfni1+swaNbLDXieVqeA+g1WRjsUlze/xgFTKLbRBkEz3MemX23MYYQf1zOsDKHm6fg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6556 X-purgate-ID: tlsNG-c1860d/1793211752-CED4087B-CA7DB755/0/0 X-purgate-type: clean X-purgate-size: 1390 On 28/10/2026 8:08 am, Ryo Takakura wrote: > On Tue, 27 Oct 2026 10:18:44 +0000, Andrew Cooper wrote: >> >>>> Separately, you have a number of MISRA violations which you're >>>> introducing in your series. I see you've got cf_check, which suggests >>>> you have built in GitlabCI. Have you also run Eclair? >>> Thank you for pointing this out. >>> My apologies for the violations. I wasn't aware of the tests >>> and haven't run either of them. I added the cf_check following >>> the existing code that I referred to when preparing this series. >>> I'll make sure to run those tests before sending next version. >> Do you have an account on Gitlab to run the CI testing? If not, reach >> out on Matrix. > I don't have an account yet. > Ok, I'll ask on Matrix. To get you started, I put this series through:   https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/3000384733 There's one Eclair failure on ARM. Interestingly, it's not the failure I was expecting to see.  I was expecting it to complain about +    uint32_t insns[2] = { +        aarch64_insn_gen_nop(), +        aarch64_insn_gen_nop(), +    }; because of the order those function calls being undefined. I was also expecting to see some failures due to arithmetic on pointers of different types, but maybe we've not made those rules enforcing yet. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Oct 28 18:56:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 18:56:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463602.1674429 (Exim 4.92) (envelope-from ) id 1xM8oo-0006Cd-2U; Wed, 28 Oct 2026 18:56:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463602.1674429; Wed, 28 Oct 2026 18:56: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 1xM8on-0006CW-Vx; Wed, 28 Oct 2026 18:56:13 +0000 Received: by outflank-mailman (input) for mailman id 1463602; Wed, 28 Oct 2026 18:56:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM8ol-0006CQ-Ux for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 18:56:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM8ol-008aJs-Bg for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 19:56:11 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae24537-2eae-0a2a0a5409dd-0a2a4508a33e-24 for ; Wed, 28 Oct 2026 19:56:11 +0100 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 6ae24549-f659-0a2a45080019-aceafc1fb780-3 for ; Wed, 28 Oct 2026 19:56:10 +0100 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 94BAC43E30; Wed, 28 Oct 2026 18:56:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70D261F01828; Wed, 28 Oct 2026 18:56: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="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=1793213768; bh=df/xPPyuiQPcm1AE1rSPxuyp5dlFq4Se196rhHrJoBM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=K+edzg6vK4sYIgPI0EHAxslJmPd/aExnxCZkYatx9SKb8ztopQpN/Brte7D1uGHDc +PWfIYIXj2TwEIjrIeT9aSjpQlU/qFISxxHuWsvH08dCGPPiD4L4rx5Tz6bxLuFRvY RhA3+DjTqfNcnhfh/7faDIzX0CmFsTI2XpkHQ8+jhA2LaeatAD4sqfFj21cmIRpM5b W2D2wH60j2ajxxUPUQIplNGc0FcQFY/hgWtTB/gjNx5LU362Hvl/ouMKfNIqzO8whL EQwWzgrE3+OvEllJ5XwE13QwOyNwuhXlhNdKAwm9IJuUZrFACWCEqjTJXX2ww3Zp+t 0+IngOv7LotGw== Date: Wed, 28 Oct 2026 11:56:08 -0700 From: Kees Cook To: Ian Rogers Cc: Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich , Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , Christian =?iso-8859-1?Q?K=F6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Jonathan Corbet , Shuah Khan , Randy Dunlap , Andy Whitcroft , Joe Perches Subject: Re: [PATCH v2 1/9] Compiler Attributes: Add __must_init macro Message-ID: <202610281155.4D2AA663@keescook> References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-2-irogers@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261027223847.652884-2-irogers@google.com> X-purgate-ID: tlsNG-c1860d/1793213771-CC57487B-8BE4B399/0/0 X-purgate-type: clean X-purgate-size: 1920 On Tue, Oct 27, 2026 at 03:38:36PM -0700, Ian Rogers wrote: > Clang supports the 'require_explicit_initialization' attribute on struct > fields to indicate that a field must be initialized explicitly by the > user when the object is constructed. When an aggregate initializer or > uninitialized variable omits an annotated field, Clang emits a > -Wuninitialized-explicit-init warning (enabled by default). > > Add the __must_init macro to include/linux/compiler_attributes.h (which > is included by include/linux/compiler_types.h and > include/linux/compiler.h) so kernel structs with error-prone > initialization (such as mandatory callbacks or cleanup handlers) can > enforce explicit initialization at compile time, as discussed at the > Linux Plumbers Conference. The shorter __must_init spelling, rather than > the attribute's full name, keeps annotated struct members readable and > was suggested by Greg Kroah-Hartman. > > Note that Clang does not yet diagnose file-scope objects declared > without any initializer (initializers at file scope that omit the field > are diagnosed), see https://github.com/llvm/llvm-project/issues/232483. > > Also teach Sphinx (Documentation/conf.py), kernel-doc > (tools/lib/python/kdoc/xforms_lists.py), and checkpatch.pl about the new > attribute macro. > > Link: https://lpc.events/event/20/contributions/2392/ > Link: https://lore.kernel.org/lkml/2026101532-fantastic-deafness-e04c@gregkh/ > Acked-by: Miguel Ojeda > Reviewed-by: Nick Desaulniers > Reviewed-by: Nathan Chancellor > Acked-by: Greg Kroah-Hartman > Signed-off-by: Ian Rogers Reviewed-by: Kees Cook As part of this, can you open a Clang bug for the lack of detecting global initializers? It'd be nice to get that fixed. -- Kees Cook From xen-devel-bounces@lists.xenproject.org Wed Oct 28 19:02:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 19:02:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463611.1674438 (Exim 4.92) (envelope-from ) id 1xM8v8-0008Gj-Mv; Wed, 28 Oct 2026 19:02:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463611.1674438; Wed, 28 Oct 2026 19:02: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 1xM8v8-0008Gb-Jw; Wed, 28 Oct 2026 19:02:46 +0000 Received: by outflank-mailman (input) for mailman id 1463611; Wed, 28 Oct 2026 19:02:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xM8v8-0008GV-0c for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 19:02:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xM8v7-00DbsU-DV for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 20:02:45 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae246c6-bab6-0a2a0a5309dd-0a2a4501eca8-16 for ; Wed, 28 Oct 2026 20:02:45 +0100 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 6ae246d3-5984-0a2a45010019-ac6904fea740-3 for ; Wed, 28 Oct 2026 20:02:45 +0100 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 1845460211; Wed, 28 Oct 2026 19:02:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DF981F01828; Wed, 28 Oct 2026 19:02: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=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=1793214162; bh=YGMMhhJbzgW/QzPBpPTTD30RztuRbfCJwa//1MZPoEw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=T+yeLqAFaIV5ugdB5NjhA61e12w1L+BSrYB7OFrpfAcIR2R3bvk8VTeuph4Z05PLq lcmoQ2GTvN7w8itK8z23Fb7CvX7UrXcLfbyTBM3+olmVREQ8OYm4Vt9S2hUlYCCwvh YoLN/FbwlRtpVeWgrBQUKtpCMq2aSk6BZ96fzAPA1Zh/BUv05xwNUJnUgjyW+0NxCu MFHryYeChyS2NXG+hd5tU1QFjVZnyNZfQFjz6S4tMUSJw3XSKUGdfABAiPkqNVvbJb 9OHQv7qk/nx3jGBDgbUSjb7yK9vqoj5fsPWRjo8ypvHtUbGQp1971XrK08vO1X/XlJ WlJINox/ORLVA== Date: Wed, 28 Oct 2026 12:02:33 -0700 From: Nathan Chancellor To: Kees Cook Cc: Ian Rogers , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich , Nick Desaulniers , Miguel Ojeda , Christian =?iso-8859-1?Q?K=F6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Jonathan Corbet , Shuah Khan , Randy Dunlap , Andy Whitcroft , Joe Perches Subject: Re: [PATCH v2 1/9] Compiler Attributes: Add __must_init macro Message-ID: <20261028190233.GA669046@ax162> References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-2-irogers@google.com> <202610281155.4D2AA663@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202610281155.4D2AA663@keescook> X-purgate-ID: tlsNG-d62444/1793214165-BF262757-3AB2DEA4/0/0 X-purgate-type: clean X-purgate-size: 722 On Wed, Oct 28, 2026 at 11:56:08AM -0700, Kees Cook wrote: > On Tue, Oct 27, 2026 at 03:38:36PM -0700, Ian Rogers wrote: > > Note that Clang does not yet diagnose file-scope objects declared > > without any initializer (initializers at file scope that omit the field > > are diagnosed), see https://github.com/llvm/llvm-project/issues/232483. ... > As part of this, can you open a Clang bug for the lack of detecting > global initializers? It'd be nice to get that fixed. Is that this linked issue or a different one? Looks like you filed that one and it got fixed in clang ToT about a week ago: https://github.com/llvm/llvm-project/commit/58936cb3678b4b5b96177f24cac3940b9a389fe3 -- Cheers, Nathan From xen-devel-bounces@lists.xenproject.org Wed Oct 28 21:18:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 21:18:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463664.1674447 (Exim 4.92) (envelope-from ) id 1xMB1s-0006TU-Tp; Wed, 28 Oct 2026 21:17:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463664.1674447; Wed, 28 Oct 2026 21: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 1xMB1s-0006TL-Qm; Wed, 28 Oct 2026 21:17:52 +0000 Received: by outflank-mailman (input) for mailman id 1463664; Wed, 28 Oct 2026 21:17:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMB1s-0006T6-02 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 21:17:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMB1q-003Yqa-VQ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 22:17:50 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae26640-bab6-0a2a0a5309dd-0a2a4503bab2-22 for ; Wed, 28 Oct 2026 22:17:50 +0100 Received: from [74.125.82.169] (helo=mail-dy1-f169.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2667d-fae8-0a2a45030019-4a7d52a9dc9a-3 for ; Wed, 28 Oct 2026 22:17:50 +0100 Received: by mail-dy1-f169.google.com with SMTP id 5a478bee46e88-3535bf8b3e0so2039146eec.0 for ; Wed, 28 Oct 2026 14:17:50 -0700 (PDT) Received: from visitorckw-work01.c.googlers.com.com (55.11.81.34.bc.googleusercontent.com. [34.81.11.55]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-36a2393cc86sm8584319eec.19.2026.10.28.14.17.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 14:17: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=20260707 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=20260707; t=1793222269; x=1793827069; 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=mSvwUjXL6bxIqoLGpkozD02HG93+EIbGW9TejI0a/vc=; b=u1n6pdO5XqjbfyQPOth64eYKHNF9aBUtid1ez89jPPPfSHCaW3hKx5+qsiKPRUZ+qB VyepVP+MzbxxoSrxtOdz+tMV5F4z2XFxsi7FIuC7ja1Tr2XRKhjJ26lfFGy3UUG1w4W5 BYmRqk8nhNNlvvs/Nff221ImIrKrBVR8h8IWkYh5gX1H4jX4n56D7DeHDtjIQbj3hGSE BVXQwZmBY8x9MtBhxWcR0FUyaNOvXxBENoCs/t0I9pobZUbm0PeKMOMaWsdlYQZgoh6K HIsPX297iFepMDlYa99kL2dtbuNil3NC8ZTKPKfsWzSdrv1UikRlI6M03kyO3LJyTo59 QxBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793222269; x=1793827069; 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=mSvwUjXL6bxIqoLGpkozD02HG93+EIbGW9TejI0a/vc=; b=b0wv68UeKuKqDYsdYHMh5ZnWU8vdyWdiJbIje7jQO8e1qAyo/3T/A6esG24mvUR16y TeGtFN/I9aDhb15HDIQisGp7TK5N2Oxf1L/GbBpwmihiRXoNpHstKenYgNMtVL/kkO/m YWxlojdchYvQFZ9pOq8WOBu7e9TfcbnNc6s/iQSxgaOU3xm0mWQnKT5kTqXpoWpsZPD0 ab0bcku2w6s2MlvqoP7XyXut7MWXjvt5EP64h5vnG0GjOc+Wi1CxWODFfrXRoM+lbTjR 6kUGm1Q8EPI4J2R/551CzQ3Wg19bi3KHJKmUWbKcP0EyMdOh6+EF4jGPI6NoaEu2GTz+ ZYhw== X-Gm-Message-State: AFq9FYKQZPmaCoKqekx9rytGTb/sCbT2CQyRfoTFr10PaqIAri1j3n/b By4KBedTuXKPxa8U6ah39zYnUWRes0/PpsjWLnleLQF1x7mGbTVgckJ6LSycTQ== X-Gm-Gg: AYBFou0MIEVMPFRDju7i+oMscD30IBJT8SeE7TWj8TgpviYWgAVeuxTlXlR1z2Dp7F2 DFC6RgqNl52993ZT2SNp/2zfWQxffn5GeC9kgyrXxIUmK5vx5fWEl00INrvXu/zH7EM+qNkwMIZ ncmo+fG0GBrBSz5PBRKHbA80TCqNwBpopQF1TQvA6LBz3G4lBFIDDfnW4x5CyUL922vP+DAvvPw 0AhlQdzq7bzzzOyDLVZqa7nq89vWGgAu2wOwYjlE/DAHy62jG7gEjqlohSGyknh34T8/oJM/lmN msu11TsWKG/Qc7WK977+HEuPAH8gVrf9syHjfpmnhoXt9dWPrqrbywSdymK/gS7HZpSv/fMMdG8 TkseQ+7JHWZ/INpr228rvBfGjQyNtmb2dV8IPTRiByPqX++ufhYyEeh3H57lmTUE4w/N9UOlIaA vZss57u1FaoVcdYxd9L5KF1m3Qb5GEI0pNfcGZAEWQTTT9yhE4eqBtJW4Rj8WJn+fGRmnkfUsMk K9CSGs+V0g14ESeR4/ESZw8/90Rx4ysvA0ji7e8eXtkqi6n9y8C6A82pW/buQ0oNGQDe4HjXajf pPO/Ya597mqLQD6famJE0ck9zIvKq6d+AkT87nDjx5/BxI0r1D1O7Ufbxy0IEXzycDJpu9FtuVZ xIlNoLFnv+a+RKTBczsJDqWo= X-Received: by 2002:a05:7300:a230:b0:369:a113:7578 with SMTP id 5a478bee46e88-36a1ff4734emr4398816eec.1.1793222268607; Wed, 28 Oct 2026 14:17:48 -0700 (PDT) From: Kuan-Wei Chiu To: xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, marscheng@google.com, jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com, Kuan-Wei Chiu Subject: [PATCH] xen/dt: Skip non-RAM reserved-memory regions in make_memory_node() Date: Wed, 28 Oct 2026 21:17:37 +0000 Message-ID: <20261028211737.17629-1-visitorckw@gmail.com> X-Mailer: git-send-email 2.56.0.385.gac671c819a-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1793222270-6FAC44E9-1E5AC3BC/0/0 X-purgate-type: clean X-purgate-size: 3244 Xen creates a second /memory node for Dom0 from bootinfo_get_reserved_mem() without checking whether those regions belong to host RAM. However, /reserved-memory can also describe on-chip SRAM or firmware regions outside system RAM. Listing them in a /memory node causes Dom0 to register non-RAM addresses as system RAM, conflicting with device MMIO mappings. Skip reserved-memory banks outside the host RAM banks reported by bootinfo_get_mem() in make_memory_node(). Fixes: 248faa637d2f ("xen/arm: add reserved-memory regions to the dom0 memory node") Signed-off-by: Kuan-Wei Chiu --- Found while trying to bring up Xen on new hardware. Tested on real silicon. xen/common/device-tree/domain-build.c | 42 +++++++++++++++++++++++++-- 1 file changed, 39 insertions(+), 3 deletions(-) diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c index 30a59abfa7..33baf150a6 100644 --- a/xen/common/device-tree/domain-build.c +++ b/xen/common/device-tree/domain-build.c @@ -504,6 +504,34 @@ int __init make_chosen_node(const struct kernel_info *kinfo) return res; } +static bool __init is_in_host_ram(const struct membank *bank) +{ + const struct membanks *ram = bootinfo_get_mem(); + paddr_t start = bank->start; + paddr_t end = start + bank->size; + unsigned int i; + + if ( !bank->size || end < start ) + return false; + + for ( i = 0; i < ram->nr_banks; i++ ) + { + paddr_t ram_start = ram->bank[i].start; + paddr_t ram_end = ram_start + ram->bank[i].size; + + if ( start < ram_start ) + return false; + + if ( end <= ram_end ) + return true; + + if ( start < ram_end ) + start = ram_end; + } + + return false; +} + int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, int sizecells, const struct membanks *mem) { @@ -513,14 +541,20 @@ int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, int nr_cells = 0; __be32 reg[DT_MEM_NODE_REG_RANGE_SIZE]; __be32 *cells; + bool is_resv = (mem == bootinfo_get_reserved_mem()); if ( mem->nr_banks == 0 ) return -ENOENT; /* find the first memory range that is reserved for device (or firmware) */ - for ( i = 0; i < mem->nr_banks && - (mem->bank[i].type != MEMBANK_DEFAULT); i++ ) - ; + for ( i = 0; i < mem->nr_banks; i++ ) + { + if ( mem->bank[i].type != MEMBANK_DEFAULT ) + continue; + if ( is_resv && !is_in_host_ram(&mem->bank[i]) ) + continue; + break; + } if ( i == mem->nr_banks ) return 0; @@ -544,6 +578,8 @@ int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, if ( (mem->bank[i].type == MEMBANK_STATIC_DOMAIN) || (mem->bank[i].type == MEMBANK_FDT_RESVMEM) ) continue; + if ( is_resv && !is_in_host_ram(&mem->bank[i]) ) + continue; nr_cells += reg_size; BUG_ON(nr_cells > ARRAY_SIZE(reg)); -- 2.56.0.385.gac671c819a-goog From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463718.1674525 (Exim 4.92) (envelope-from ) id 1xMCjG-0003xl-L0; Wed, 28 Oct 2026 23:06:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463718.1674525; Wed, 28 Oct 2026 23:06: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 1xMCjG-0003wk-E6; Wed, 28 Oct 2026 23:06:46 +0000 Received: by outflank-mailman (input) for mailman id 1463718; Wed, 28 Oct 2026 23:06:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCjF-0003m1-Da for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCjF-00000000ozi-0Tjz; Wed, 28 Oct 2026 23:06:44 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjE-00000001KpM-2exR; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=MLibhM8wWl0/HCQDzONzRs5XUt2IjOuQT9Me0vQau9k=; b=TUTKAFoLmXdsPbV6b3gwgBpyOn m0MBzZGkNb7CzpuRxQvqpCiskjG+OLk0YwoQ5QPZztr6iHRWSTO9F4sSQUoY8cl3VGzRQ40Rq77Ia j7DYIDd8CHFxitpdnBU3dUTxn+kINQrwtVm+vymDDzGMgNgtkoxtZqg3YkmJbcWtXFx8=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Tim Deegan Subject: [PATCH v5 08/45] x86/mm: have init_xen_l4_slots() take a vCPU in place of the domain Date: Wed, 28 Oct 2026 23:05:22 +0000 Message-ID: <20261028-asi-hvm-v5-8-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A later change gives the vCPUs of some domains per-domain areas of their own, and slot 260 of a table private to one vCPU must then hold that vCPU's L3. init_xen_l4_slots(), which fills slot 260, needs the vCPU for that. Have it take a vCPU in place of the domain. A table private to one vCPU passes that vCPU; tables that the domain's vCPUs share -- promoted PV guest L4s, PV shadow L4s, and the PV dom0 L4 under construction -- pass any of them. promote_l4_table() passes vCPU 0, so it now also refuses an L4 while the domain has no vCPU 0, as it already does while the domain has no per-domain L3; its call is reflowed. Otherwise no functional change: slot 260 still gets the domain's per-domain L3. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - promote_l4_table() checks for vCPU 0 itself, now that "x86/mm: refuse to promote an L4 while the domain has no per-domain L3" tests for the L3 instead. Changes in v4: - New in this version, split out of "x86/hvm: introduce per-vCPU L3 page-table": init_xen_l4_slots() takes a vCPU in place of the domain (Roger, Jan). - Reflow promote_l4_table()'s call to init_xen_l4_slots() (Jan). --- xen/arch/x86/include/asm/mm.h | 2 +- xen/arch/x86/mm.c | 21 ++++++++++++++------- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/pv/dom0_build.c | 2 +- xen/arch/x86/pv/domain.c | 2 +- 7 files changed, 20 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index c9085214fd..de45a111f3 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); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 8153683a0c..f2122a68ce 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1687,14 +1687,18 @@ static int promote_l3_table(struct page_info *page) * 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. + * + * v is the vCPU the table is private to or, for a table the domain's vCPUs + * share, any of them. */ 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. @@ -1798,6 +1802,8 @@ void zap_ro_mpt(mfn_t mfn) static int promote_l4_table(struct page_info *page) { struct domain *d = page_get_owner(page); + /* Any vCPU will do: a PV domain's vCPUs all use the domain-wide L3. */ + const struct vcpu *v = domain_vcpu(d, 0); mfn_t l4mfn = page_to_mfn(page); l4_pgentry_t *pl4e; unsigned int i; @@ -1805,10 +1811,11 @@ static int promote_l4_table(struct page_info *page) unsigned int partial_flags = page->partial_flags; /* - * init_xen_l4_slots() puts the domain's per-domain L3 in slot 260, and a - * PV domain may get that only with its first vCPU. + * init_xen_l4_slots() needs a vCPU, and puts the domain's per-domain L3 + * in slot 260. A PV domain has no vCPUs before XEN_DOMCTL_max_vcpus, + * and may get the L3 only with its first vCPU. */ - if ( !d->arch.perdomain_l3_pg ) + if ( !v || !d->arch.perdomain_l3_pg ) return -EINVAL; pl4e = map_domain_page(l4mfn); @@ -1887,8 +1894,8 @@ static int promote_l4_table(struct page_info *page) if ( !rc ) { - init_xen_l4_slots(pl4e, l4mfn, - d, INVALID_MFN, VM_ASSIST(d, m2p_strict)); + init_xen_l4_slots(pl4e, l4mfn, v, INVALID_MFN, + VM_ASSIST(d, m2p_strict)); atomic_inc(&d->arch.pv.nr_l4_pages); } unmap_domain_page(pl4e); 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/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 7f72b4b7b2..ebbf4a12ce 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 24f2fa0b7f..dcb1d407ec 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -725,7 +725,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); + v, INVALID_MFN, true); v->arch.guest_table = pagetable_from_paddr(__pa(l4start)); } else diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index f3c711b85b..f139d8f83c 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.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463713.1674482 (Exim 4.92) (envelope-from ) id 1xMCjB-0002y9-1k; Wed, 28 Oct 2026 23:06:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463713.1674482; Wed, 28 Oct 2026 23: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 1xMCjA-0002y2-V2; Wed, 28 Oct 2026 23:06:40 +0000 Received: by outflank-mailman (input) for mailman id 1463713; Wed, 28 Oct 2026 23:06:40 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCj9-0002cZ-SX for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:39 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCj9-00000000oz4-24kV; Wed, 28 Oct 2026 23:06:39 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCj9-00000001KpM-0CAZ; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=o3zz2HkxCeoJz+EVitDmyu1O+pr0HXQj+R59SjSZJuI=; b=1CrRkHxtlC5db9Y6Jp/CQLQF6p Pb/EgFEv33QLhw4VjN/tUrbo9aoHtGOlU4zZa9zf5iui5bXdXXxLowdFabshcU6gUY/cLE2VYJdDj j1gRli7cGJUCRRhIGeCCE54ivb4G+2nPPwZi2JnvcPL3cFcX0ToBQq5NQ4xndIcGldVM=; 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?= , Teddy Astie Subject: [PATCH v5 03/45] x86/mm: purge unneeded destroy_perdomain_mapping() Date: Wed, 28 Oct 2026 23:05:17 +0000 Message-ID: <20261028-asi-hvm-v5-3-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 at both of its call sites. arch_domain_destroy() unconditionally calls free_perdomain_mappings(), which tears down the same entries and additionally frees the page-table structures; and the other caller, the error path of pv_domain_initialise(), returns into arch_domain_create()'s failure path, which invokes free_perdomain_mappings() as well. One vCPU-scoped caller, pv_destroy_gdt_ldt_l1tab(), is covered the same way: a vCPU is only ever destroyed together with its domain, or on the failure path of creating it, and both routes end in free_perdomain_mappings(); the GDT/LDT slots hold no area-owned pages, so there is nothing else for the call to do. While we're getting rid of unnecessary callers, drop this one too. Note that free_compat_arg_xlat() keeps its explicit teardown: switch_compat() calls it on the failure path. While in practice most toolstacks will immediately destroy the domain, in theory a toolstack could let it live on as a 64-bit guest. Release the resources immediately rather than waiting for domain destruction. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap Reviewed-by: Jan Beulich --- Changes in v4: - Remove an unnecessary comment (Jan). Changes in v3: - Note that pv_domain_destroy()'s other call site, the error path of pv_domain_initialise(), is covered the same way (Jan). - Also drop pv_destroy_gdt_ldt_l1tab(), the per-vCPU teardown call (Jan), and comment on why free_compat_arg_xlat() keeps its own. The Reviewed-by tags given for the previous form are dropped. 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 | 10 ---------- 2 files changed, 11 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index ef9c7cd057..6aefe91e02 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 0c42ae58aa..28ea0742ab 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -319,12 +319,6 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) NULL); } -static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) -{ - destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v), - 1U << GDT_LDT_VCPU_SHIFT); -} - void pv_vcpu_destroy(struct vcpu *v) { if ( is_pv_32bit_vcpu(v) ) @@ -333,7 +327,6 @@ void pv_vcpu_destroy(struct vcpu *v) release_compat_l4(v); } - pv_destroy_gdt_ldt_l1tab(v); XFREE(v->arch.pv.trap_ctxt); } @@ -381,9 +374,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); FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463716.1674511 (Exim 4.92) (envelope-from ) id 1xMCjE-0003ci-Q3; Wed, 28 Oct 2026 23:06:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463716.1674511; Wed, 28 Oct 2026 23:06: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 1xMCjE-0003cZ-M2; Wed, 28 Oct 2026 23:06:44 +0000 Received: by outflank-mailman (input) for mailman id 1463716; Wed, 28 Oct 2026 23:06:43 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCjD-0003Kj-1Y for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:43 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCjC-00000000ozS-2c3F; Wed, 28 Oct 2026 23:06:42 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjC-00000001KpM-0mqd; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=esXrd0Jka8WbHwkPGFhLd2S1JxqJTf5kbPSe2y2FeJo=; b=2I66xFRaZkkUlK/FZSf+w5CKg/ SHYX6FNyz38Sx03bhnqUVOUy+3NwrrhXEesq3ia4Ht/Nij2eULdBsQn2shgCSnOP6biskYb1X7U0f 5kD9tdNXfquydm6pkRp33fouSzvJQU1uY5UmtVsdq7qvAJ2cqbANs1axMN4q+ZjJPf88=; 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?= , Teddy Astie Subject: [PATCH v5 06/45] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas Date: Wed, 28 Oct 2026 23:05:20 +0000 Message-ID: <20261028-asi-hvm-v5-6-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: much of the perdomain area has always been laid out in per-vCPU slices -- each vCPU has its own GDT/LDT window and its own COMPAT_ARG_XLAT pages -- 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 before any page tables referencing it are built. 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. Once a domain's area is per-vCPU, a later change gives its vCPUs a teardown of their own; the domain-wide teardown stays for domains with a shared area, PV ones included. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Jan Beulich --- Changes in v5: - Message: the domain-wide mapcache is one pool, not per-vCPU windows: drop it from the per-vCPU slices, and say "much of" the area. Changes in v4: - Message: drop a sentence repeating its paragraph, and say that the domain-wide teardown stays for domains with a shared area (Roger). - End the comment in arch_vcpu_create() at the colon (Roger). Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series): the capture parameters stay, as the PV GDT/LDT stash still uses them. 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 | 8 ++++++++ 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 | 3 ++- xen/arch/x86/pv/domain.c | 2 +- xen/arch/x86/x86_64/mm.c | 2 +- 7 files changed, 16 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 8e17fbe6d9..94a1ea904a 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -517,6 +517,14 @@ 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). + */ + rc = create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, NULL, NULL); + 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 f02be1675b..f3e65e2d44 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -260,15 +260,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, + int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, NIL(l1_pgentry_t *), NULL); /* Populate bit maps. */ if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse, + rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse, nr, NULL, NIL(struct page_info *)); if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage, + rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage, nr, NULL, NIL(struct page_info *)); if ( rc ) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 6aefe91e02..71da15c0a4 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, NULL, NULL); - 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 20a1d27cd0..c9085214fd 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -606,7 +606,7 @@ 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, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, l1_pgentry_t **pl1tab, struct page_info **ppg); void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 72c1865e7e..8153683a0c 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6238,10 +6238,11 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e) (_PAGE_PRESENT | _PAGE_AVAIL0); } -int create_perdomain_mapping(struct domain *d, unsigned long va, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, l1_pgentry_t **pl1tab, struct page_info **ppg) { + 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 28ea0742ab..f3c711b85b 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, v->domain->arch.pv.gdt_ldt_l1tab, NULL); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index f467ed426b..7b04537066 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), NULL, NIL(struct page_info *)); } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463714.1674492 (Exim 4.92) (envelope-from ) id 1xMCjC-0003BI-B5; Wed, 28 Oct 2026 23:06:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463714.1674492; Wed, 28 Oct 2026 23:06:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCjC-0003B5-7W; Wed, 28 Oct 2026 23:06:42 +0000 Received: by outflank-mailman (input) for mailman id 1463714; Wed, 28 Oct 2026 23:06:40 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCjA-0002wF-Nh for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:40 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCjA-00000000ozC-2IXQ; Wed, 28 Oct 2026 23:06:40 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjA-00000001KpM-0Z4w; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=w50GWZ48VtZLTYVd8SCuQUF/rxoF1HYBp06a7RaN7SI=; b=XECs9kUdwfm+idqZTNzkmlBkT/ bxSVdPiglppi2owsP220vs09Fc8F1dg5kAQd1A0cpHW/HWhC2pwEoOZ+JcYC1UGPTppP2f0TOqUWc adhURgql79xNbPRnmEOZE49eH4oTplXSEZSz+qXY7GW55Y9pff6h/mbaDObitd92GJ7U=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v5 04/45] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas Date: Wed, 28 Oct 2026 23:05:18 +0000 Message-ID: <20261028-asi-hvm-v5-4-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 one remaining caller, free_compat_arg_xlat(), is already in a vCPU context, so we just need to change the parameter from a domain pointer to a vCPU pointer. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v4: - Say "No functional change." (Roger). Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series): free_compat_arg_xlat() is the only caller left. - Drop the linear-page-table fast path altogether (Jan): its only user would have been guest-driven LDT teardown, and without it the function does not depend on the linear mapping being available. Changes in v2: - Added to the series Changes since the previously posted version: - The fast path is gone (v3), and with it the previously posted version's sync_local_execstate() call. - 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 | 3 ++- xen/arch/x86/x86_64/mm.c | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index aa515efbee..20a1d27cd0 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -609,7 +609,7 @@ 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 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 f00f0b831d..72c1865e7e 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6361,10 +6361,11 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, return rc; } -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)); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 8eadab7933..f467ed426b 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -739,7 +739,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.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463712.1674470 (Exim 4.92) (envelope-from ) id 1xMCj9-0002bX-TL; Wed, 28 Oct 2026 23:06:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463712.1674470; Wed, 28 Oct 2026 23:06: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 1xMCj9-0002aq-PK; Wed, 28 Oct 2026 23:06:39 +0000 Received: by outflank-mailman (input) for mailman id 1463712; Wed, 28 Oct 2026 23:06:39 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCj8-0002Vj-W3 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:38 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCj8-00000000oyw-24N5; Wed, 28 Oct 2026 23:06:38 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCj8-00000001KpM-07RY; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=V0LyJBxVk4KD9HGsd+/rOvk7kIUU4yEoOtzPVbAsy4M=; b=CZ7OMUrt0B+0YK9aGFFnyswUnJ 5J+fJCVrQov+Pv64T22thEqJaVzrdrcv3UtnKsyKZ+f9coqUVibPlJ06pmbKgh5xav0FZWzuOpJpI Ltr9bIw8b68c2g9iMx9gI3IzcJVrUbOoYXRqPcvl/Gc3r2cVWUNJ1Y3dyVHTYtZvfg0c=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 02/45] x86/mm: refuse to promote an L4 while the domain has no per-domain L3 Date: Wed, 28 Oct 2026 23:05:16 +0000 Message-ID: <20261028-asi-hvm-v5-2-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit init_xen_l4_slots() puts the domain's per-domain L3 in slot 260 of the L4s it fills. Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT L3 slot at domain creation") a PV domain gets that L3 with its first vCPU (pv_create_gdt_ldt_l1tab()). Only mapcache_domain_init() makes it earlier, with the domain, and release builds skip that unless memory hotplug is enabled or the host's memory reaches past the part of the directmap PV guests can see. So in release builds on most hosts, an L4 that is promoted before XEN_DOMCTL_max_vcpus has created the domain's vCPUs gets a slot 260 entry made from a NULL page (0x803e900000000063), pointing far beyond the host's memory. Have promote_l4_table() return -EINVAL while the domain has no per-domain L3, before taking any reference. The other callers of init_xen_l4_slots() all run once the L3 exists; have init_xen_l4_slots() check that with a BUG_ON(). An ASSERT() would not do: the case above arises only in release builds. libxl is unaffected: it creates the vCPUs before it builds or restores a domain. There's no way to trigger the issue from the current toolstack; this is just belt-and-braces. Fixes: fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT L3 slot at domain creation") Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Test for the per-domain L3 itself, not for vCPU 0 (Roger). - BUG_ON() in init_xen_l4_slots() if the domain has no per-domain L3. - Retitle (was: "x86/mm: refuse to promote an L4 while the domain has no vCPU"). Changes in v4: - New in this version, split out of "x86/hvm: introduce per-vCPU L3 page-table": promote_l4_table() fails while the domain has no vCPU --- xen/arch/x86/mm.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e42cd33c0d..f00f0b831d 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1721,6 +1721,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW); /* Slot 260: Per-domain mappings. */ + BUG_ON(!d->arch.perdomain_l3_pg); l4t[l4_table_offset(PERDOMAIN_VIRT_START)] = l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); @@ -1798,11 +1799,20 @@ 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() puts the domain's per-domain L3 in slot 260, and a + * PV domain may get that only with its first vCPU. + */ + if ( !d->arch.perdomain_l3_pg ) + return -EINVAL; + + pl4e = map_domain_page(l4mfn); + for ( i = page->nr_validated_ptes; i < L4_PAGETABLE_ENTRIES; i++, partial_flags = 0 ) { -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463715.1674501 (Exim 4.92) (envelope-from ) id 1xMCjD-0003Om-IR; Wed, 28 Oct 2026 23:06:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463715.1674501; Wed, 28 Oct 2026 23: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 1xMCjD-0003Of-EA; Wed, 28 Oct 2026 23:06:43 +0000 Received: by outflank-mailman (input) for mailman id 1463715; Wed, 28 Oct 2026 23:06:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCjC-0003Ai-0h for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:42 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCjB-00000000ozK-2RLG; Wed, 28 Oct 2026 23:06:41 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjB-00000001KpM-0fV3; Wed, 28 Oct 2026 23:06: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" 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=bA3v+JEkOAdTcWN15wgbRh+Ssvgb9EI2cGiWnRhLeLY=; b=QNWIWVDQhioI3UWE8ewCzk6rZv BASlVPF1ICD4mzef+63Qcvrz4GRU+FPmHM0jE9iGQ52vuXYdDZVxlMkmOcZQ0fS5dvliqXHQhVGaC aeQlBDfzrwwfEcUPv4DqHon1cPIlByNdCm1dEAvxOLY1j3Cvoi8g+SPKB7D5jpomqOYk=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v5 05/45] x86/domain_page: drop redundant create_perdomain_mapping() call Date: Wed, 28 Oct 2026 23:05:19 +0000 Message-ID: <20261028-asi-hvm-v5-5-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 populating 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. In debug builds, and on hosts with memory hotplug or with more memory than the PV directmap covers, the call was also what first allocated a PV domain's per-domain L3. Release builds on other hosts already allocated it only with the first vCPU. Drop the call; now we always allocate only with the first vCPU. With the only fallible operation gone, mapcache_domain_init() becomes void, and arch_domain_create()'s error handling for it goes away. The per-domain-mapping work in mapcache_vcpu_init() stays where it is rather than moving into mapcache_domain_init() along with this change, ready for a later patch which introduces per-vCPU mapcaches. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v3: - Rebased onto staging without the GDT/LDT conversions (for the HVM-only series); no functional difference. - Say why the per-vCPU part stays in mapcache_vcpu_init() (Jan). - Say that the call also first allocated a PV domain's per-domain L3 in some builds, which all builds now do with the first vCPU. 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 | 8 ++------ xen/arch/x86/include/asm/domain.h | 2 +- 3 files changed, 4 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 368e4deff3..8e17fbe6d9 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 5744754f11..f02be1675b 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -223,7 +223,7 @@ void unmap_domain_page(const void *ptr) local_irq_restore(flags); } -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; @@ -232,7 +232,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 + @@ -244,10 +244,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, - NIL(l1_pgentry_t *), NULL); } 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 2d0a915410..212daae1f5 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.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463717.1674519 (Exim 4.92) (envelope-from ) id 1xMCjG-0003rA-0z; Wed, 28 Oct 2026 23:06:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463717.1674519; Wed, 28 Oct 2026 23:06: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 1xMCjF-0003qy-TW; Wed, 28 Oct 2026 23:06:45 +0000 Received: by outflank-mailman (input) for mailman id 1463717; Wed, 28 Oct 2026 23:06:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCjE-0003YN-7j for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:44 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCjE-00000000oza-07SU; Wed, 28 Oct 2026 23:06:43 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjD-00000001KpM-2WG6; Wed, 28 Oct 2026 23:06: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" 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=GsQusdW8CwK9lWg0WTbN8UcrqKWkfEhBlrYNLpqfu3M=; b=IICBVG0ELKSsBb4MGMM8L7pwAH QDGax6zM1fGBZf/ZrnaZLuWLNYwRromMQr3L4BLXFe6KgSAStx5ea25KYB/7pP6l6s1oHJpbQdRSZ Zm25VH/VOjOqzpW8On5GkP6SRc5x6RGEypw+97Gl/PCWfpHWtjlGPlxwxi/eZxMoSXrs=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Teddy Astie Subject: [PATCH v5 07/45] x86/spec-ctrl: introduce Address Space Isolation command line option Date: Wed, 28 Oct 2026 23:05:21 +0000 Message-ID: <20261028-asi-hvm-v5-7-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Introduce the `asi=` command line option, and the opt_vcpu_pt_hvm and opt_vcpu_pt_hwdom knobs plus the per-domain d->arch.asi.vcpu_pt setting they control. 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 any use of the option, `asi=0` included, adds a boot-time warning that the feature is not functional and is meant for development only. The mechanisms this option controls apply to HVM domains: an HVM vCPU already runs on its own monitor table, so giving each vCPU its own per-domain area needs no work at context switch. d->arch.asi.vcpu_pt is therefore only ever set for HVM domains, a PVH hardware domain included; PV domains, a PV hardware domain included, are unaffected. Besides the plain boolean, `pv=`, `hvm=` and `dom0=` select the features for PV domains or HVM domains other than the hardware domain, or for the hardware domain, PV or PVH. None of the features applies to PV domains, so `pv=` has no effect beyond a boot-log line saying it is ignored, and `dom0=` acts on a PVH hardware domain only. The boot log gains "ASI features for ..." lines for Dom0 and HVM domains, so hardware-domain-only configurations remain visible. 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, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Rename opt_pvh_vcpu_pt_hwdom back to opt_vcpu_pt_hwdom: that it acts on a PVH hardware domain only is a limitation of the implementation, not of the design (Roger). - pv= logs that it is ignored (Roger). - parse_asi() adds the development warning, so any use of asi= gives it and later sub-options need not extend a condition (Roger). - print_details(): IS_ENABLED(CONFIG_HVM) rather than #ifdef (Roger). Changes in v4: - Docs: "domains" throughout, not "guests" (Roger). - Group the per-domain settings as one-bit fields of d->arch.asi (Roger). - Rename opt_vcpu_pt_hwdom to opt_pvh_vcpu_pt_hwdom: it acts on a PVH hardware domain only (Jan). - parse_asi(): break in the success branch and fall through to default:, rather than a default: label after an else (MISRA C:2012 Rule 16.2; Jan). - Message: enabling a knob adds a boot-time warning; it does not taint (Roger). - Add the pv= and dom0= sub-options here, beside hvm= (Roger). Changes in v3: - HVM only: drop the PV knob and its interaction with XPTI. vCPU-PT applies to HVM domains and to a PVH hardware domain; the Dom0 boot log line says None for a PV one. Changes in v2: - Added to the series Changes since the previously posted version: - Include the hardware domain in the development warning and the boot log summary. - Make the opt_vcpu_pt_* knobs plain booleans preinitialised to false, dropping the late -1 resolution. - Documentation: mention possible protection against unmitigated attacks, and state that hvm= does not affect the hardware domain. - Rewrite the commit message. --- docs/misc/xen-command-line.pandoc | 29 ++++++++++ xen/arch/x86/include/asm/domain.h | 6 ++ xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/spec_ctrl.c | 87 ++++++++++++++++++++++++++++ 4 files changed, 124 insertions(+) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index a6f08463d1..839d06da26 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -202,6 +202,35 @@ 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,dom0}=, +> vcpu-pt= | vcpu-pt=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. + +The mechanisms currently implemented apply to HVM domains, including a PVH +hardware domain. PV domains, including a PV hardware domain, are unaffected. + +* `pv=`, `hvm=` and `dom0=` enable the features for PV domains or HVM domains + other than the hardware domain, or for the hardware domain, PV or PVH. The + plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain + out. The forms naming no domain type (an un-suffixed `vcpu-pt=`) + cover the hardware domain too. + +**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` gives each vCPU its own per-domain area: the per-domain slot of + each vCPU's monitor table maps a region private to that vCPU. + ### asid (x86) > `= ` diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 212daae1f5..12f79feb42 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -474,6 +474,12 @@ struct arch_domain /* Don't unconditionally inject #GP for unhandled MSRs. */ bool msr_relaxed; + /* Fine grained ASI related options. */ + struct { + /* Give each vCPU its own per-domain area (HVM only). */ + bool vcpu_pt:1; + } asi; + /* 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..b62229ab5d 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_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..8797523a62 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -86,6 +86,10 @@ bool __ro_after_init opt_bp_spec_reduce = true; static bool __initdata opt_ibpb_alt; +/* Give each vCPU of an HVM domain its own per-domain area (vCPU-PT). */ +bool __ro_after_init opt_vcpu_pt_hvm; +bool __ro_after_init opt_vcpu_pt_hwdom; + static int __init cf_check parse_spec_ctrl(const char *s) { const char *ss; @@ -487,6 +491,80 @@ 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) +{ + static bool __initdata warned; + const char *ss; + int val, rc = 0; + + if ( !warned ) + { + warned = true; + warning_add( + "Address Space Isolation is not functional, this option is\n" + "intended to be used only for development purposes.\n"); + } + + /* Interpret 'asi' alone in its positive boolean form. */ + if ( *s == '\0' ) + 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_hwdom = opt_vcpu_pt_hvm = val; + break; + + default: + if ( (val = parse_boolean("pv", s, ss)) >= 0 ) + printk(XENLOG_WARNING + "No ASI feature applies to PV domains - ignoring 'asi=%.*s' setting\n", + (int)(ss - s), s); + else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + opt_vcpu_pt_hvm = val; + else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) + opt_vcpu_pt_hwdom = val; + else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) + { + switch ( val ) + { + case 1: + case 0: + opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; + break; + + case -2: + s += strlen("vcpu-pt="); + if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + { + opt_vcpu_pt_hvm = val; + break; + } + fallthrough; + 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 +758,12 @@ 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\n", + opt_dom0_pvh && opt_vcpu_pt_hwdom ? " vCPU-PT" : " None"); + if ( IS_ENABLED(CONFIG_HVM) ) + printk(" ASI features for HVM VMs:%s\n", + opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); } static bool __init check_smt_enabled(void) @@ -1866,6 +1950,9 @@ 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.asi.vcpu_pt = !pv && (is_hardware_domain(d) ? opt_vcpu_pt_hwdom + : opt_vcpu_pt_hvm); } void __init init_speculation_mitigations(void) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463711.1674464 (Exim 4.92) (envelope-from ) id 1xMCj9-0002ZF-Lo; Wed, 28 Oct 2026 23:06:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463711.1674464; Wed, 28 Oct 2026 23:06: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 1xMCj9-0002Z8-Iz; Wed, 28 Oct 2026 23:06:39 +0000 Received: by outflank-mailman (input) for mailman id 1463711; Wed, 28 Oct 2026 23:06:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCj7-0002Mh-RT for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCj7-00000000oyo-2U6I; Wed, 28 Oct 2026 23:06:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCj7-00000001KpM-0VHz; Wed, 28 Oct 2026 23: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" 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=B2+5XOSM+cuv0+hYCmliA8wrwB1HxetxuWUGkc2sz6A=; b=KOmSyLxSbUt7uJQzQ8K8WPC3uI 9a+eV3JAettdVNSipin03TCoi9GC2IQk84oZYKwiq2x5iA7XSULBSQO+/aJJ4Ik0d9n7hSLI7dfVX aZ9KiIYewwPXivAIqbXDOoHQj8neYvcH+HYQSgM0GWGjYj59ipSKmPlfg9YsbS6e/KlY=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v5 01/45] x86/PoD: map one page at a time in p2m_pod_zero_check() Date: Wed, 28 Oct 2026 23:05:15 +0000 Message-ID: <20261028-asi-hvm-v5-1-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit p2m_pod_zero_check() maps every page of its batch that passes its checks, up to POD_SWEEP_STRIDE (16) of them, and keeps them mapped across the p2m lookups and updates which follow, each of which maps page-table pages of its own. Its callers hold mappings too: the p2m lookup which found the entry to populate still has its page-table page mapped, and a PV mmu_update() the L1 page it is writing. map_domain_page() cannot always provide that many at once. It uses the mapcache on behalf of PV vCPUs only. The mapcache has MAPCACHE_VCPU_ENTRIES (16) slots per vCPU of the domain, shared by its vCPUs, and a mapping which finds no slot free or reclaimable hits the BUG_ON() in map_domain_page(): the host crashes. The sweep runs in the context of whichever vCPU populates a PoD entry while the domain's PoD cache is empty. The guest's own vCPUs, being HVM, map through the directmap; a PV vCPU gets there when its domain maps or copies the guest's memory: a device model in dom0 or in a stub domain, a backend doing grant copies. A single-vCPU PV domain, such as a device-model stub domain or a dom0 booted with dom0_max_vcpus=1, has 16 slots, and a sweep over 16 candidate pages needs more. The sweep has mapped its whole batch at once since 9ad9a1609fbe ("PoD memory 5/9: emergency scan"), when x86-64 reached all memory through the directmap. The per-vCPU budget came with the mapcache's return to x86-64 in 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al"). Map one page at a time instead, as p2m_pod_zero_check_superpage() already does: map a page for the quick check and unmap it again, and map it anew for the full check after the p2m update and the TLB flush. The checks and their order are unchanged. Each page is mapped twice, which costs little next to scanning it, and the error paths no longer have mappings to undo. Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al") Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Acked-by: Roger Pau Monné --- Changes in v5: - Use __set_bit() and __clear_bit() on the bitmask (Roger). - Description: drop the memory limit at which the mapcache starts to be used, and the list of what makes map_domain_page() use it (Roger). Changes in v4: - Track the pages to check in a bitmask walked with for_each_set_bit(), not an array of bools (Andrew). - Drop the new comment above the first loop; edit the old one's "and map the pages" instead (Andrew). NB this issue was raised in review and verified only by code inspection; it hasn't been demonstrated. --- xen/arch/x86/mm/p2m-pod.c | 72 +++++++++++++++++---------------------- 1 file changed, 31 insertions(+), 41 deletions(-) diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c index 4602c32cff..ae1210e279 100644 --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -901,9 +901,10 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { mfn_t mfns[POD_SWEEP_STRIDE]; p2m_type_t types[POD_SWEEP_STRIDE]; - unsigned long *map[POD_SWEEP_STRIDE]; + unsigned int check = 0; + const unsigned long *map; struct domain *d = p2m->domain; - unsigned int i, j, max_ref = 1; + unsigned int j, max_ref = 1; BUG_ON(count > POD_SWEEP_STRIDE); @@ -911,8 +912,11 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count if ( paging_mode_shadow(d) ) max_ref++; - /* First, get the gfn list, translate to mfns, and map the pages. */ - for ( i = 0; i < count; i++ ) + /* + * First, get the gfn list, translate to mfns, and check for being a + * plausible candidate. + */ + for ( unsigned int i = 0; i < count; i++ ) { p2m_access_t a; @@ -921,9 +925,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count /* * If this is ram, and not a pagetable or a special page, and - * probably not mapped elsewhere, map it; otherwise, skip. + * probably not mapped elsewhere, check it; otherwise, skip. */ - map[i] = NULL; if ( p2m_is_ram(types[i]) ) { const struct page_info *pg = mfn_to_page(mfns[i]); @@ -932,7 +935,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count (pg->count_info & PGC_allocated) && !(pg->count_info & PGC_shadowed_pt) && ((pg->count_info & PGC_count_mask) <= max_ref) ) - map[i] = map_domain_page(mfns[i]); + __set_bit(i, &check); } } @@ -940,20 +943,23 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count * Then, go through and check for zeroed pages, removing write permission * for those with zeroes. */ - for ( i = 0; i < count; i++ ) + for_each_set_bit ( i, check ) { - if ( !map[i] ) - continue; - /* Quick zero-check */ + map = map_domain_page(mfns[i]); for ( j = 0; j < 16; j++ ) - if ( *(map[i] + j) != 0 ) - goto skip; + if ( map[j] != 0 ) + break; + unmap_domain_page(map); /* Try to remove the page, restoring old mapping if it fails. */ - if ( p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, + if ( j < 16 || + p2m_set_entry(p2m, gfns[i], INVALID_MFN, PAGE_ORDER_4K, p2m_populate_on_demand, p2m->default_access) ) - goto skip; + { + __clear_bit(i, &check); + continue; + } /* * See if the page was successfully unmapped. (Allow one refcount @@ -961,6 +967,8 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count */ if ( (mfn_to_page(mfns[i])->count_info & PGC_count_mask) > 1 ) { + __clear_bit(i, &check); + /* * If the previous p2m_set_entry call succeeded, this one shouldn't * be able to fail. If it does, crashing the domain should be safe. @@ -970,38 +978,27 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { ASSERT_UNREACHABLE(); domain_crash(d); - goto out_unmap; + return; } - - skip: - unmap_domain_page(map[i]); - map[i] = NULL; - - continue; } } p2m_tlb_flush_sync(p2m); /* Now check each page for real */ - for ( i = 0; i < count; i++ ) + for_each_set_bit ( i, check ) { - if ( !map[i] ) - continue; - - for ( j = 0; j < (PAGE_SIZE / sizeof(*map[i])); j++ ) - if ( *(map[i] + j) != 0 ) + map = map_domain_page(mfns[i]); + for ( j = 0; j < (PAGE_SIZE / sizeof(*map)); j++ ) + if ( map[j] != 0 ) break; - - unmap_domain_page(map[i]); - - map[i] = NULL; + unmap_domain_page(map); /* * See comment in p2m_pod_zero_check_superpage() re gnttab * check timing. */ - if ( j < (PAGE_SIZE / sizeof(*map[i])) ) + if ( j < (PAGE_SIZE / sizeof(*map)) ) { /* * If the previous p2m_set_entry call succeeded, this one shouldn't @@ -1012,14 +1009,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { ASSERT_UNREACHABLE(); domain_crash(d); - out_unmap: - /* - * Something went wrong, probably crashing the domain. Unmap - * everything and return. - */ - for ( i = 0; i < count; i++ ) - if ( map[i] ) - unmap_domain_page(map[i]); + return; } } else -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463719.1674537 (Exim 4.92) (envelope-from ) id 1xMCjH-0004Ip-Sh; Wed, 28 Oct 2026 23:06:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463719.1674537; Wed, 28 Oct 2026 23:06: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 1xMCjH-0004I1-OV; Wed, 28 Oct 2026 23:06:47 +0000 Received: by outflank-mailman (input) for mailman id 1463719; Wed, 28 Oct 2026 23:06:46 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCjG-0003so-3q for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:46 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCjG-00000000ozt-0Kas; Wed, 28 Oct 2026 23:06:45 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjF-00000001KpM-2k5o; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=8H0V8RA4Wa1e0SSpnxuGjwXcA2NpA35aSMRyM//0g9w=; b=LEkmzKEb8grjFBVa8Av8slbbtX 90D0ME/bQPlsBSEcif7UmL2vdCiA34p9wuRRXt0Dphen5sg1ULFa0pgkvJmiM0ZWSGvmAWevS4ri9 F7xVwdYqowjmsyqBF9wEaRJ76+ZizQTqEmVrGtnNw8/h0BZnbQnOTSdFWASbNHrf3a08=; 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?= , Teddy Astie Subject: [PATCH v5 09/45] x86/hvm: introduce per-vCPU L3 page-table Date: Wed, 28 Oct 2026 23:05:23 +0000 Message-ID: <20261028-asi-hvm-v5-9-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Currently all of a domain's vCPUs share its per-domain area: 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. Much of the area is already laid out in per-vCPU slices (each vCPU's COMPAT_ARG_XLAT pages, and for PV each vCPU's GDT/LDT window), 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. For HVM domains, allow each vCPU a per-domain area of its own instead ("vCPU-PT"). HVM monitor tables are already per-vCPU, so this needs nothing at context switch: every monitor table carries its vCPU's own L3 from creation, and the per-vCPU mappings are isolated from other running vCPUs at once. We will later build on this, adding a per-vCPU mapcache and a per-vCPU state window, into which we can move the vCPU state mentioned above. 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 vCPU-PT can be chosen domain by domain; PV domains always use the domain-wide L3.) In {create,destroy}_perdomain_mapping(), if d->arch.asi.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() keeps covering non-vCPU-PT domains. init_xen_l4_slots() is given the vCPU that a table is private to or, for a table that the domain's vCPUs share, any of them. Have it install that vCPU's perdomain_l3() in slot 260: the tables that a domain's vCPUs share are PV ones, and a PV domain's vCPUs all use the domain-wide L3. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-fable-5-1, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - init_xen_l4_slots()'s BUG_ON() follows slot 260 to perdomain_l3(). - Message: all of a domain's vCPUs share its per-domain area; the mapcache is not among the per-vCPU slices; the mode is "vCPU-PT". The comment above init_xen_l4_slots() names perdomain_l3(v) and the domain-wide L3. Changes in v4: - Rebase over earlier changes - d->arch.vcpu_pt is now d->arch.asi.vcpu_pt. - init_xen_l4_slots() taking a vCPU in place of the domain, and promote_l4_table() failing while the domain has none, are now patches of their own (Roger, Jan). - Drop the fail_early label: every cleanup step after fail: is safe before its setup has run (Roger). - free_pervcpu_mappings(): clear the pointer, then free, as XFREE() does (Roger). - Likewise in free_perdomain_mappings(). Changes in v3: - HVM only: PV domains keep the domain-wide area, so the PV parts go (the single-vCPU limit, the shadow refusals, the XPTI slot install). init_xen_l4_slots() takes the vCPU as an extra, optional argument rather than in place of the domain, so PV guest L4s, which no vCPU owns, are promoted exactly as before. - Retitle (was: "x86/mm: introduce per-vCPU L3 page-table"). - free_compat_arg_xlat()'s comment names free_pervcpu_mappings() as the teardown for a vCPU-PT domain. Changes in v2: - Added to the series Changes since the previously posted version: - Expand the commit message with the motivation and the design rationale. - 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. - 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. --- xen/arch/x86/domain.c | 9 ++-- xen/arch/x86/include/asm/domain.h | 4 ++ xen/arch/x86/include/asm/mm.h | 2 + xen/arch/x86/mm.c | 68 +++++++++++++++++++++++-------- 4 files changed, 62 insertions(+), 21 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 94a1ea904a..7a4da203d4 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; if ( !is_idle_domain(d) ) { @@ -523,12 +523,12 @@ int arch_vcpu_create(struct vcpu *v) */ rc = create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, NULL, NULL); if ( rc ) - return rc; + goto fail; paging_vcpu_init(v); if ( (rc = vcpu_init_fpu(v)) != 0 ) - return rc; + goto fail; vmce_init_vcpu(v); @@ -576,6 +576,7 @@ int arch_vcpu_create(struct vcpu *v) vcpu_destroy_fpu(v); xfree(v->arch.msrs); v->arch.msrs = NULL; + free_pervcpu_mappings(v); return rc; } @@ -596,6 +597,8 @@ void arch_vcpu_destroy(struct vcpu *v) pv_vcpu_destroy(v); else ASSERT_UNREACHABLE(); + + free_pervcpu_mappings(v); } int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 12f79feb42..4140a92f15 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -332,6 +332,7 @@ struct monitor_write_data { struct arch_domain { + /* Domain-wide L3 for the per-domain slot; NULL in a vCPU-PT domain. */ struct page_info *perdomain_l3_pg; /* I/O-port admin-specified access capabilities. */ @@ -688,6 +689,9 @@ struct arch_vcpu struct vcpu_msrs *msrs; + /* Per-vCPU L3 for the per-domain slot; NULL in a non-vCPU-PT domain. */ + 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 de45a111f3..12d1c06c12 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -369,6 +369,7 @@ int devalidate_page(struct page_info *page, unsigned long type, int preemptible); void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d); +struct page_info *perdomain_l3(const struct vcpu *v); void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt); bool fill_ro_mpt(mfn_t mfn); @@ -612,6 +613,7 @@ int create_perdomain_mapping(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 f2122a68ce..6e3b1c4c7d 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1681,6 +1681,18 @@ 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. + */ +struct page_info *perdomain_l3(const struct vcpu *v) +{ + const struct domain *d = v->domain; + + return d->arch.asi.vcpu_pt ? v->arch.pervcpu_l3_pg + : d->arch.perdomain_l3_pg; +} + /* * Fill an L4 with Xen entries. * @@ -1693,7 +1705,8 @@ static int promote_l3_table(struct page_info *page) * extended directmap. * * v is the vCPU the table is private to or, for a table the domain's vCPUs - * share, any of them. + * share, any of them: slot 260 gets perdomain_l3(v), which in a domain + * whose vCPUs share tables (PV) is the domain-wide L3. */ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt) @@ -1725,9 +1738,9 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW); /* Slot 260: Per-domain mappings. */ - BUG_ON(!d->arch.perdomain_l3_pg); + BUG_ON(!perdomain_l3(v)); 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) && @@ -6250,7 +6263,7 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va, struct page_info **ppg) { 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; @@ -6259,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.asi.vcpu_pt ) + v->arch.pervcpu_l3_pg = pg; + else + d->arch.perdomain_l3_pg = pg; if ( !nr ) { unmap_domain_page(l3tab); @@ -6276,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))); @@ -6373,16 +6389,16 @@ 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; - 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 ) @@ -6421,16 +6437,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 ) { @@ -6466,8 +6477,29 @@ 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) +{ + struct page_info *l3pg = d->arch.perdomain_l3_pg; + + if ( !l3pg ) + return; + d->arch.perdomain_l3_pg = NULL; + free_perdomain_l3(l3pg); +} + +void free_pervcpu_mappings(struct vcpu *v) +{ + struct page_info *l3pg = v->arch.pervcpu_l3_pg; + + if ( !l3pg ) + return; + + v->arch.pervcpu_l3_pg = NULL; + free_perdomain_l3(l3pg); } static void write_sss_token(unsigned long *ptr) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463710.1674455 (Exim 4.92) (envelope-from ) id 1xMCj8-0002Mu-G5; Wed, 28 Oct 2026 23:06:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463710.1674455; Wed, 28 Oct 2026 23: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 1xMCj8-0002Mn-DA; Wed, 28 Oct 2026 23:06:38 +0000 Received: by outflank-mailman (input) for mailman id 1463710; Wed, 28 Oct 2026 23:06:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMCj6-0002Mb-IQ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMCj6-00000000oyk-2jIV for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCj6-00000001KpM-0thJ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:06: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" 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:To:From; bh=b5/KRvNpW7doNNwVa6XyxzTuMKkPxnUY8BHBVIU7vEI=; b=nDF1d/Hu3qdLMExlgZMe9TguRc cYzBW9IeiigmBRM+nrq69yVdxidlU4SxLQPpoF2Qo+DF2ynNzitjCAZ6o6eCcr7+zxLHmaTHXfZ/v CHsNXGWLKXKgwUjbQdKc8EwZrgkVEkGhREPKif9aPYusgCTdw7OM1wchzIDuwtTl+TPI=; From: George Dunlap To: xen-devel@lists.xenproject.org Subject: [PATCH v5 00/45] ASI: HVM through X4 Date: Wed, 28 Oct 2026 23:05:14 +0000 Message-ID: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is the first part of a series to implement address space isolation. The approach is the same as v3 and v4: Start by focusing on just getting ASI and intra-domain isolation for HVM guests. PV support is added where it's simple to do. The full series can be roughly divided as below: Included in this version, posted before: - VH (02-14): Give each vCPU of an HVM guest its own per-domain area and its own mapcache. - DV (15-24): Maintain two "views" of the directmap: A full directmap, and a sparse directmap. The full directmap is what we have now; the sparse directmap removes non-xenheap heap memory. - X1 (25-31): Add a vCPU state window to the per-domain area (both for PV and HVM). Move SVM VMCB structures and VMX guest MSR areas into it. Included this version, new: - X2 (32-35): Move every vCPU's saved register frame (PV and HVM), and the HVM emulator's operand caches, into the vCPU state window. 35 also clears the vCPU's copy of an emulated I/O request once it has been consumed. - X3 (36-38): Introduce map_domain_pages(), which maps several pages in the calling vCPU's per-domain area, and use it in place of vmap() for the shadow code's cross-page emulated writes and the HVM emulator's multi-frame accesses. - X4 (39-45): Move the guest XSAVE areas into the vCPU state window. Implemented but not yet posted: - PH1: Preparation for per-pCPU stacks, modifying rendezvous and call-function IPIs to not use the stack - PH2: Moving pCPU stacks into the perdomain area, allocating them from the domheap - O: A number of optimizations to improve performance The functionality of v5 (through X4) is the bare minimum that XenServer needs to make it into 4.23. v4 can be found here: https://lore.kernel.org/xen-devel/20261019-asi-hvm-v4-0-b68b66652266@xenproject.org/ v5 is based on staging 8b0a70ddd29d, which now includes Ross's "x86/svm: Don't clear clean bits on every context switch" (69633efbca3c). Ross's patch replaces v4's 26/30, "x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from()", which is dropped. The first 31 patches are v4's other 29, some changed in review, and one new patch (16); the last 14 are new: they add map_domain_pages(), and move the register frames, the emulator's caches and the XSAVE areas into the vCPU state window. v4's 16/30 is now two, 17 and 18. Some more details: 01: A fix that should be considered for backport 16: New patch, a work-around for a slow-down which causes a watchdog to fire. (Proper performance fixes have been implemented but won't be posted until the end of the entire series.) 15,17-18: The previous patch 16 has been refactored; some of it has moved to patch 15, the rest has been broken down into two patches. Code is substantially the same, with minor edits; the patch breakdown has changed to improve reviewability. 35 also limits exposure of ioreq state: Completely isolating each vCPU’s I/O requests from being read by other vCPUs of the same domain is complicated; as a mitigation, this patch clears the emulated I/O request once it has been consumed, reducing the window available to read the payload. 39-42 are Alejandro's patches from "x86: Address Space Isolation FPU preparations" (v3, January 2025), revived. State is moved from the xenheap into the per-domain area for both ASI and non-ASI domains: VMCB, MSR List, vCPU register frame, and XSAVE/FPU areas. Same is true for users of map_domain_pages. This protects non-ASI domains from ASI domains. One key thing to get feedback on is the question below 45's "---": xstate_init() now panics on hardware whose XSAVE area needs more than the three pages reserved for it in the vCPU state window. No current hardware does. Should it do more, for instance size the reservation from the size found at boot, or fall back to xenheap areas on such hardware? Note that at the end of this series, PV guests can be given the sparse directmap; this isolates them from other domains, but doesn't isolate vCPUs within a domain. With v5, a PV domain's register frames and XSAVE areas are also out of reach of domains on the sparse directmap, whether or not the PV domain itself is on it. Testing of v5: - Builds of xen/ at each of the 45 patches, in nine configurations: debug and release, each with and without CONFIG_SPARSE_DIRECTMAP from 18 on (where the option appears), !HVM, !PV, the PV shim, and shadow paging, debug and release. No warnings or errors beyond those staging itself gives. - QEMU (TCG) smoke boots at 31, 33, 36 and 45: a PV dom0 with no asi=, asi=1, asi=1,dom0=0 and xpti=1; a PVH dom0 with no asi=, asi=1 and asi=1,dom0=0. Each boot reaches dom0's userspace with no crash, assertion or warning in Xen's log. - On an Intel NUC: whole-tree builds (xen, tools, stubdom, docs) of 45, with tools/tests/vpci run. Boots of 45 (cet=no-shstk,no-ibt pv=32 throughout) with XPTI forced on (xpti=1), with XPTI off, and with asi=1: in each, a 64-bit PV guest and an HVM guest (QEMU, PV drivers) run a short stress and network test side by side and shut down cleanly. With asi=1, XTF's full suite, 32-bit PV included, passes twice (the usual four skips). - The same basic code has been run through XenRT, with the issue addressed by 16 (slow dom0 kernel decompression triggering a watchdog on large machines) the only issue found. A dependency graph of the above functionality can be found here: https://xenbits.xenproject.org/people/gdunlap/asi-series-deps.html Extending the intra-domain isolation to PV guests would involve implementing per-vCPU root pagetables for PV guests. There are draft implementations of this, but they are quite complicated. Alejandro Vallejo (4): x86/emulator: Refactor FXSAVE_AREA to use wrappers x86/mpx: Map/unmap xsave area in read_bndcfgu() x86/fpu: Pass explicit xsave areas to fpu_(f)xsave() x86/fpu: Pass explicit xsave areas to fpu_(f)xrstor() George Dunlap (31): x86/PoD: map one page at a time in p2m_pod_zero_check() x86/mm: refuse to promote an L4 while the domain has no per-domain L3 x86/mm: have init_xen_l4_slots() take a vCPU in place of the domain x86/domain_page: drop redundant is_pv_vcpu() checks x86/domain_page: don't unmap a mapcache entry that is not present x86/mm: let Xen's page-table walker operate on a given root xen/gunzip: process pending softirqs once per deflate block x86/mm: add hooks for a sparse view of the directmap x86/mm: build and maintain a sparse view of the directmap x86/domain_page: key the directmap fast paths on the loaded view x86/domain_page: clear a mapcache slot at its last unmap x86/mm: run guest contexts on the sparse directmap view x86/spec-ctrl: wire the sparse directmap view into the asi= option xen/xmalloc: return an emptied region after dropping the pool lock x86/mm: split a sparse directmap superpage with a page being freed x86/mm: introduce a per-vCPU state window in the perdomain area x86/svm: introduce SVM_MAP_VMCB() and SVM_UNMAP_VMCB() x86/svm: restore guest debug registers in svm_do_resume() x86/svm: drop svm_vmcb_dump()'s paddr x86/svm: allocate VMCBs from the domain heap behind the vCPU state window x86/vmx: move the guest MSR load/save list off always-mapped memory x86: access a vCPU's saved register frame through map/unmap helpers x86: move the saved register frame behind the vCPU state window x86/hvm: move the emulator's operand caches behind the vCPU state window x86/hvm: clear the vCPU's copy of an emulated I/O request once consumed x86/domain_page: introduce map_domain_pages() x86/shadow: use map_domain_pages() for cross-page emulated writes x86/hvm: use map_domain_pages() for multi-frame emulated accesses x86/xstate: classify xsave-area seam accesses by failure mode x86/domain: restore FPU state after switching to the new page tables x86/xstate: move guest XSAVE areas behind the vCPU state window Roger Pau Monné (10): 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/hvm: introduce per-vCPU L3 page-table x86/domain_page: prepare the mapcache for per-vCPU accounting x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains x86/mm: introduce populate_perdomain_mapping() docs/misc/xen-command-line.pandoc | 57 +++ xen/arch/x86/Kconfig | 1 + xen/arch/x86/Makefile | 1 + xen/arch/x86/domain.c | 233 ++++++++-- xen/arch/x86/domain_page.c | 461 ++++++++++++++++---- xen/arch/x86/domctl.c | 98 +++-- xen/arch/x86/hvm/domain.c | 6 +- xen/arch/x86/hvm/emulate.c | 243 ++++++++--- xen/arch/x86/hvm/hvm.c | 122 +++--- xen/arch/x86/hvm/svm/nestedsvm.c | 12 +- xen/arch/x86/hvm/svm/svm.c | 147 +++++-- xen/arch/x86/hvm/svm/vmcb.c | 74 +++- xen/arch/x86/hvm/svm/vmcb.h | 29 +- xen/arch/x86/hvm/vmx/vmcs.c | 151 ++++++- xen/arch/x86/hvm/vmx/vmx.c | 7 +- xen/arch/x86/hypercall.c | 4 +- xen/arch/x86/i387.c | 60 ++- xen/arch/x86/include/asm/config.h | 42 +- xen/arch/x86/include/asm/domain.h | 109 ++++- xen/arch/x86/include/asm/hvm/emulate.h | 9 +- xen/arch/x86/include/asm/hvm/vcpu.h | 7 + xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 63 +-- xen/arch/x86/include/asm/i387.h | 1 + xen/arch/x86/include/asm/mm.h | 29 +- xen/arch/x86/include/asm/sparse-directmap.h | 83 ++++ xen/arch/x86/include/asm/spec_ctrl.h | 3 + xen/arch/x86/include/asm/xstate.h | 73 ++-- xen/arch/x86/mm.c | 428 +++++++++++++++--- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/p2m-pod.c | 72 ++- xen/arch/x86/mm/shadow/hvm.c | 6 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/pv/dom0_build.c | 9 +- xen/arch/x86/pv/domain.c | 30 +- xen/arch/x86/pv/shim.c | 4 +- xen/arch/x86/setup.c | 4 + xen/arch/x86/sparse-directmap.c | 455 +++++++++++++++++++ xen/arch/x86/spec_ctrl.c | 183 +++++++- xen/arch/x86/traps.c | 20 +- xen/arch/x86/x86_64/mm.c | 14 +- xen/arch/x86/x86_emulate/blk.c | 36 +- xen/arch/x86/xstate.c | 212 ++++++++- xen/common/Kconfig | 18 + xen/common/gzip/gunzip.c | 1 + xen/common/gzip/inflate.c | 1 + xen/common/page_alloc.c | 51 ++- xen/common/xmalloc_tlsf.c | 12 +- xen/include/xen/domain_page.h | 21 + xen/include/xen/mm.h | 40 ++ 49 files changed, 3102 insertions(+), 644 deletions(-) create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h create mode 100644 xen/arch/x86/sparse-directmap.c base-commit: 8b0a70ddd29dec2f86a49c21e3664a21e281e859 -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463791.1674591 (Exim 4.92) (envelope-from ) id 1xMD6P-0004vS-9K; Wed, 28 Oct 2026 23:30:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463791.1674591; Wed, 28 Oct 2026 23:30: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 1xMD6O-0004r3-Vm; Wed, 28 Oct 2026 23:30:40 +0000 Received: by outflank-mailman (input) for mailman id 1463791; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048N-Rx for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pO3-2KnS; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjW-00000001KpM-3fYZ; Wed, 28 Oct 2026 23:07: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" 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=6StxVuF+DxVESv0W4X+e1gdp43IG04FSqlKMUwh8lP8=; b=iBu5WntoYtpv4VxcBVX1Lykv7U Bh72UDB2nSzLYZZ8rad5cOxQ6WWGZmsyHCIgs+je9ddjAibFiK6/NAV0JVJHHrqQgbBZgtbbMy+jU LCFiihS5hY2uyCHCWYC/iwPQ78YN+CrPWnxyOqetuL4Gcc3/9BWtXbEE0nJKMVmLWmxk=; 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?= , Teddy Astie Subject: [PATCH v5 25/45] x86/mm: introduce populate_perdomain_mapping() Date: Wed, 28 Oct 2026 23:05:39 +0000 Message-ID: <20261028-asi-hvm-v5-25-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné The per-domain area 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 and the compat argument-translation area. What the interface lacks is a way to install a caller's own pages at a chosen address, which a per-vCPU state window, introduced by a later patch, needs: its users allocate their pages themselves and map them there. Introduce populate_perdomain_mapping(v, va, mfn, nr, flags) for this. It writes the given MFNs, with the given page-table flags, into v's view of the per-domain area, walking the per-domain page-table structures with transient mappings, so v need not be current. Callers don't need to know where the page-tables live, how the area is structured, or whether v has a per-domain area of its own or shares its domain's. 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 never expected: such a page is referenced only by the mapping, and no caller replaces area-owned backing. Should one ever do so, the page is leaked with a message rather than freed. The function is not for contexts with interrupts off: its users map their pages when allocating them. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Comment above populate_perdomain_mapping(): the range lies within one sub-area (one PERDOMAIN_VIRT_SLOT()), not one "per-domain slot". - Message: "whether v has a per-domain area of its own or shares its domain's". Changes in v4: - Re-introduced into the series. - HVM only: the users are the state window's, all of which map their pages at allocation time, so drop the linear-mapping fast path and the IRQs-off walk that context-switch callers needed, along with the map_domain_page_irqoff() variants. --- xen/arch/x86/include/asm/mm.h | 3 ++ xen/arch/x86/mm.c | 62 +++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index af43ae01b0..6d50e17259 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -620,6 +620,9 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); int create_perdomain_mapping(struct vcpu *v, 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(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 8d09a8e2c8..b10cc03840 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6555,6 +6555,68 @@ int create_perdomain_mapping(struct vcpu *v, 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 sub-area (one PERDOMAIN_VIRT_SLOT()), and must already have been + * plumbed down to the L1 tables by create_perdomain_mapping(). Present + * entries are replaced, and no TLB flushing is done. + * + * The walk maps the per-domain page-table pages transiently, so v need not + * be current. It is not for contexts with interrupts disabled. + */ +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, + const mfn_t *mfn, unsigned int nr, + unsigned int flags) +{ + struct page_info *l3_pg = perdomain_l3(v); + const l3_pgentry_t *l3tab; + const l2_pgentry_t *l2tab; + l1_pgentry_t *l1tab = NULL; + unsigned int i; + + ASSERT(va >= PERDOMAIN_VIRT_START && + va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); + ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1))); + ASSERT(local_irq_is_enabled()); + + if ( !nr ) + return; + + BUG_ON(!l3_pg); + l3tab = __map_domain_page(l3_pg); + BUG_ON(!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT)); + l2tab = map_l2t_from_l3e(l3tab[l3_table_offset(va)]); + unmap_domain_page(l3tab); + + for ( i = 0; i < nr; i++, va += PAGE_SIZE ) + { + l1_pgentry_t *pl1e; + + if ( !l1tab || !l1_table_offset(va) ) + { + const l2_pgentry_t *pl2e = &l2tab[l2_table_offset(va)]; + + unmap_domain_page(l1tab); + BUG_ON(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT)); + l1tab = map_l1t_from_l2e(*pl2e); + } + + pl1e = &l1tab[l1_table_offset(va)]; + if ( perdomain_l1e_needs_freeing(*pl1e) ) + { + printk(XENLOG_ERR + "%pv: leaking area-owned page %"PRI_mfn" at %#lx\n", + v, mfn_x(l1e_get_mfn(*pl1e)), va); + ASSERT_UNREACHABLE(); + } + l1e_write(pl1e, l1e_from_mfn(mfn[i], flags)); + } + + unmap_domain_page(l1tab); + unmap_domain_page(l2tab); +} + void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr) { -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463784.1674555 (Exim 4.92) (envelope-from ) id 1xMD6N-0004GB-9m; Wed, 28 Oct 2026 23:30:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463784.1674555; Wed, 28 Oct 2026 23:30: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 1xMD6N-0004E5-28; Wed, 28 Oct 2026 23:30:39 +0000 Received: by outflank-mailman (input) for mailman id 1463784; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00046f-Ko for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pNz-1xa6; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjP-00000001KpM-18We; Wed, 28 Oct 2026 23: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" 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=Nbm5LGUXAXFDIjgJzJsxMDDBiZ2tUg52cJwtNk9aHjw=; b=a37K4So41+zclNqzxUPbyjdYd5 aVz96JGG+Wkezx0o3AhZGFiXh/+YVelLQUkv4O/7+fZ4kg/x96ZVLnFG59KBm6HREvkHS+S7Gp65G J5Gq9ZVs3ZRzkOjm4jT/MTf2Bubuj1FmGGmCk4oKeL9saVVPF6SyUXqOaVQgZ44e04w0=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v5 18/45] x86/mm: build and maintain a sparse view of the directmap Date: Wed, 28 Oct 2026 23:05:32 +0000 Message-ID: <20261028-asi-hvm-v5-18-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The directmap maps all of RAM, and every root page-table carries it, so while any guest context runs, all guest memory is reachable from Xen's address space. For ASI, guest contexts are to run on a view of the directmap which maps only what Xen must reach through it at all times, leaving guest memory to transient mappings (map_domain_page()). Rather than remove the directmap for everyone, keep the full directmap as it is, for the idle domain and for guest contexts not using ASI, and build a second, sparse view: page-tables for the same virtual addresses (the part of the directmap PV guests can see, where everything Xen reaches through the directmap lives), mapping a subset of what the full directmap maps, each entry a copy of the full directmap's. Boot and the idle domain keep the full directmap, so nothing in them needs converting. The sparse view maps the xenheap, and memory never handed to the heap allocator (Xen's image, boot-time allocations, firmware tables). It is built once the boot allocator has handed its memory to the heap, from the full directmap minus the ranges the heap was given, plus the xenheap allocations made meanwhile. The page-tables then come from the heap, and no other CPU is up. The sparse view has an L3 for each of its L4 slots from the start, so its L4 entries never change and root page-tables can take copies of them. It is then kept in step through the hooks added by "x86/mm: add hooks for a sparse view of the directmap", which this patch implements for CONFIG_SPARSE_DIRECTMAP. modify_xen_mappings_lite() needs no change: it only changes the mappings of Xen's image, in L4 slot 261, which every root page-table shares with idle_pg_table, outside the range the sparse view replaces. xen_mapping_lookup(), built only with CONFIG_SPARSE_DIRECTMAP, reads an entry of either hierarchy under the L3 table lock. The allocator may still have to scrub a page before returning it; this will be mapped with map_domain_page(). This is fine for HVM domains on the sparse view, as the mapcache is per-vCPU, so no other vCPU can read unscrubbed data. PV domains' mapcache is still domain-wide, so for PV domains on the sparse view, this opens up a window where other vCPUs could potentially speculatively access the unscrubbed data. This would be fixed by having per-vCPU mapcaches for PV domains, or synchronously scrubbing pages on free. Neither are in the scope of the current work. The sparse view is built only when some domain type is to use it, which nothing can request yet: this patch changes nothing on its own. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Split: free_pagetable_in() moves to "x86/mm: let Xen's page-table walker operate on a given root", and the hooks with their stubs and callers to the new "x86/mm: add hooks for a sparse view of the directmap". Changes in v4: - Message: "domain type", not "guest type". - Wrap a line that reached 80 columns. - Memory hot-add maps the new range into the full directmap only. - Define opt_sparse_dmap_hwdom here, beside the PV and HVM knobs (Roger). - add_to_sparse_view(): assert that the lookup finds the MFN expected (Roger). - cmp_mfn_range(): explicit return values, as in cmp_node() (Roger). - Comments and variable name changes in sparse_dmap_init()'s loop over the heap's ranges (Roger). - Message: drop "(NUMA node heap metadata)" (Roger). - Message: drop the reference to the directmap removal series (Roger). - Message: modify_xen_mappings_lite() needs no change (Roger). - Message: note the limit of scrubbing at allocation for PV domains (Roger). - Message: only boot and the idle domain keep the full directmap. - Set the NX bit in this patch, rather than adding it in a later patch. Changes in v3: - New in this version. --- xen/arch/x86/Kconfig | 1 + xen/arch/x86/Makefile | 1 + xen/arch/x86/include/asm/mm.h | 4 + xen/arch/x86/include/asm/sparse-directmap.h | 37 ++ xen/arch/x86/mm.c | 74 ++++ xen/arch/x86/sparse-directmap.c | 431 ++++++++++++++++++++ xen/common/Kconfig | 18 + xen/include/xen/mm.h | 14 + 8 files changed, 580 insertions(+) create mode 100644 xen/arch/x86/sparse-directmap.c diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index e5535ac484..cd72102ccc 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -31,6 +31,7 @@ config X86 select HAS_SCHED_GRANULARITY select HAS_SHARED_INFO imply HAS_SOFT_RESET + select HAS_SPARSE_DIRECTMAP select HAS_UBSAN select HAS_VMAP select HAS_VPCI if HVM diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 2be90ea098..86adf042e9 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -63,6 +63,7 @@ obj-y += shutdown.o obj-y += smp.o obj-y += smpboot.o obj-y += spec_ctrl.o +obj-$(CONFIG_SPARSE_DIRECTMAP) += sparse-directmap.o obj-y += srat.o obj-y += string.o obj-$(CONFIG_SYSCTL) += sysctl.o diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 6264f67af4..7612cf66ef 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -602,6 +602,10 @@ int map_pages_in(l4_pgentry_t *root, unsigned long virt, mfn_t mfn, unsigned long nr_mfns, pte_attr_t flags); int modify_mappings_in(l4_pgentry_t *root, unsigned long s, unsigned long e, pte_attr_t nf); +#ifdef CONFIG_SPARSE_DIRECTMAP +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, + pte_attr_t *flags, unsigned long *nr); +#endif int __sync_local_execstate(void); diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index 53747a98ad..ea14d44334 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -6,6 +6,41 @@ #include #include +#ifdef CONFIG_SPARSE_DIRECTMAP + +/* + * The part of the directmap the sparse view covers: the part PV guests can + * see, which is where everything Xen reaches through the directmap lives. + * SPARSE_DMAP_END_MFN is the first MFN past it. + */ +#define SPARSE_DMAP_START DIRECTMAP_VIRT_START +#define SPARSE_DMAP_END HYPERVISOR_VIRT_END +#define SPARSE_DMAP_END_MFN (virt_to_mfn(SPARSE_DMAP_END - 1) + 1) + +/* + * Which domains use the sparse view: PV domains and HVM domains other than + * the hardware domain, and the hardware domain, PV or PVH. + */ +extern bool opt_sparse_dmap_pv, opt_sparse_dmap_hvm, opt_sparse_dmap_hwdom; + +/* Root of the sparse view, once built (NULL before, or if not configured). */ +extern l4_pgentry_t *sparse_dmap_root; + +static inline bool sparse_dmap_configured(void) +{ + return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; +} + +void sparse_dmap_init(void); +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, + pte_attr_t flags); +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf); +int sparse_dmap_remove(mfn_t mfn, unsigned long nr); +int sparse_dmap_drop_pagetable(mfn_t mfn); + +#else /* !CONFIG_SPARSE_DIRECTMAP */ + static inline bool sparse_dmap_configured(void) { return false; } static inline void sparse_dmap_init(void) {} static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, @@ -27,4 +62,6 @@ static inline int sparse_dmap_drop_pagetable(mfn_t mfn) return 0; } +#endif /* CONFIG_SPARSE_DIRECTMAP */ + #endif /* X86_SPARSE_DIRECTMAP_H */ diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 6028408b82..964f9e6a41 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5424,6 +5424,80 @@ mfn_t xen_map_to_mfn(unsigned long va) return ret; } +#ifdef CONFIG_SPARSE_DIRECTMAP +/* + * Look @va up in the hierarchy rooted at @root, without allocating anything. + * Returns the MFN mapped at @va, or INVALID_MFN, with the mapping's flags in + * L1 form in *flags, and in *nr the number of pages from @va to the end of + * the entry that maps @va (or that finds it unmapped). + */ +mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, + pte_attr_t *flags, unsigned long *nr) +{ + bool locking = system_state > SYS_STATE_boot; + l4_pgentry_t l4e = root[l4_table_offset(va)]; + const l3_pgentry_t *pl3e = NULL; + const l2_pgentry_t *pl2e = NULL; + const l1_pgentry_t *pl1e = NULL; + struct page_info *l3page; + unsigned int shift = L4_PAGETABLE_SHIFT; + mfn_t ret = INVALID_MFN; + + L3T_INIT(l3page); + *flags = 0; + + if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) ) + goto out; + + pl3e = map_l3t_from_l4e(l4e) + l3_table_offset(va); + l3page = l4e_get_page(l4e); + L3T_LOCK(l3page); + + shift = L3_PAGETABLE_SHIFT; + if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) ) + goto out; + if ( l3e_get_flags(*pl3e) & _PAGE_PSE ) + { + /* The superpage PAT bit sits among the address bits. */ + *flags = lNf_to_l1f(l3e_get_flags(*pl3e)) | + (l3e_get_intpte(*pl3e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); + ret = _mfn((l3e_get_pfn(*pl3e) & + ~((1UL << (2 * PAGETABLE_ORDER)) - 1)) + + (PFN_DOWN(va) & ((1UL << (2 * PAGETABLE_ORDER)) - 1))); + goto out; + } + + pl2e = map_l2t_from_l3e(*pl3e) + l2_table_offset(va); + shift = L2_PAGETABLE_SHIFT; + if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) + goto out; + if ( l2e_get_flags(*pl2e) & _PAGE_PSE ) + { + *flags = lNf_to_l1f(l2e_get_flags(*pl2e)) | + (l2e_get_intpte(*pl2e) & _PAGE_PSE_PAT ? _PAGE_PAT : 0); + ret = _mfn((l2e_get_pfn(*pl2e) & ~((1UL << PAGETABLE_ORDER) - 1)) + + l1_table_offset(va)); + goto out; + } + + pl1e = map_l1t_from_l2e(*pl2e) + l1_table_offset(va); + shift = PAGE_SHIFT; + if ( l1e_get_flags(*pl1e) & _PAGE_PRESENT ) + { + *flags = l1e_get_flags(*pl1e); + ret = l1e_get_mfn(*pl1e); + } + + out: + L3T_UNLOCK(l3page); + unmap_domain_page(pl1e); + unmap_domain_page(pl2e); + unmap_domain_page(pl3e); + *nr = ((((va >> shift) + 1) << shift) - va) >> PAGE_SHIFT; + return ret; +} +#endif /* CONFIG_SPARSE_DIRECTMAP */ + /* * Free a page-table page that the hierarchy rooted at @root has stopped * using. One of idle_pg_table's may be in the sparse directmap view: it is diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c new file mode 100644 index 0000000000..d35a8d6979 --- /dev/null +++ b/xen/arch/x86/sparse-directmap.c @@ -0,0 +1,431 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * A sparse view of the directmap. + * + * Xen maps all of RAM at DIRECTMAP_VIRT_START, and every root page-table + * carries those mappings. The sparse view is a second set of page-tables + * for the same virtual addresses (the part of the directmap PV guests can + * see), mapping only what Xen needs to reach through the directmap at all + * times: + * + * - Memory never handed to the heap: Xen's image, boot-time allocations, + * firmware tables. Not a PV dom0's initrd, used in place, nor the frame + * table and M2P pages carved from hot-added memory. + * - Memory handed to the heap, then allocated to the xenheap. + * + * The rest of the heap's memory, where guest memory comes from, is not + * mapped. Every mapping in the sparse view is either identical to the + * full directmap's at the same address, or empty. + * + * Guest contexts selected on the command line run on root page-tables + * carrying the sparse view's L3s in the directmap slots. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +bool __ro_after_init opt_sparse_dmap_pv; +bool __ro_after_init opt_sparse_dmap_hvm; +bool __ro_after_init opt_sparse_dmap_hwdom; + +/* Root of the sparse view: only ever walked and copied from, never loaded. */ +static l4_pgentry_t __aligned(PAGE_SIZE) sparse_l4[L4_PAGETABLE_ENTRIES]; +l4_pgentry_t *__ro_after_init sparse_dmap_root; + +/* + * Before the sparse view is built: the MFN ranges handed to the heap, which + * it leaves out, and the xenheap allocations made since, which it puts back. + */ +struct mfn_range { + unsigned long s, e; +}; +static struct mfn_range early_heap[256]; +static unsigned int nr_early_heap; +static struct mfn_range early_xenheap[2 * MAX_NUMNODES]; +static unsigned int nr_early_xenheap; +static bool early_overflow; + +/* + * Clip [*mfn, *mfn + *nr) to what the sparse view covers; false if nothing is + * left. + */ +static bool clip_to_sparse_view(unsigned long *mfn, unsigned long *nr) +{ + unsigned long end = SPARSE_DMAP_END_MFN; + + if ( *mfn >= end ) + return false; + if ( *nr > end - *mfn ) + *nr = end - *mfn; + + return *nr; +} + +static void early_range_add(struct mfn_range *r, unsigned int *nr, + unsigned int max, unsigned long s, unsigned long e) +{ + if ( *nr && r[*nr - 1].e == s ) + r[*nr - 1].e = e; + else if ( *nr < max ) + r[(*nr)++] = (struct mfn_range){ s, e }; + else + early_overflow = true; +} + +static void early_range_del(struct mfn_range *r, unsigned int *nr, + unsigned long s, unsigned long e) +{ + unsigned int i; + + for ( i = 0; i < *nr; i++ ) + if ( r[i].s == s && r[i].e == e ) + { + r[i] = r[--*nr]; + return; + } +} + +/* + * Copy the full directmap's mappings of MFNs [mfn, mfn + nr) into the sparse + * view. + */ +static int add_to_sparse_view(l4_pgentry_t *root, unsigned long mfn, + unsigned long nr) +{ + unsigned long start = (unsigned long)mfn_to_virt(mfn); + unsigned long va = start, end = start + (nr << PAGE_SHIFT); + + while ( va < end ) + { + pte_attr_t flags; + unsigned long n; + mfn_t va_mfn = xen_mapping_lookup(idle_pg_table, va, &flags, &n); + int rc; + + ASSERT(mfn_eq(va_mfn, INVALID_MFN) || + mfn_x(va_mfn) == mfn + ((va - start) >> PAGE_SHIFT)); + n = min(n, (end - va) >> PAGE_SHIFT); + if ( !mfn_eq(va_mfn, INVALID_MFN) && + (rc = map_pages_in(root, va, va_mfn, n, flags)) ) + return rc; + va += n << PAGE_SHIFT; + } + + return 0; +} + +static int remove_from_sparse_view(unsigned long mfn, unsigned long nr) +{ + unsigned long va = (unsigned long)mfn_to_virt(mfn); + + return modify_mappings_in(sparse_dmap_root, va, va + (nr << PAGE_SHIFT), + _PAGE_NONE); +} + +/* Memory is about to be handed to the heap allocator. */ +bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) +{ + unsigned long s = mfn_x(mfn); + + if ( !sparse_dmap_configured() || !clip_to_sparse_view(&s, &nr) ) + return true; + + if ( !sparse_dmap_root ) + { + early_range_add(early_heap, &nr_early_heap, ARRAY_SIZE(early_heap), + s, s + nr); + return true; + } + + if ( remove_from_sparse_view(s, nr) ) + { + printk(XENLOG_ERR + "sparse directmap: cannot unmap MFNs %#lx-%#lx, not freeing\n", + s, s + nr - 1); + return false; + } + + return true; +} + +/* + * Xenheap pages enter the sparse view, which guest contexts run on: those + * still holding a previous owner's data must be scrubbed first. + */ +bool arch_xenheap_needs_scrub(void) +{ + return sparse_dmap_configured(); +} + +/* Pages have been allocated from the heap as xenheap pages. */ +int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) +{ + unsigned long s = mfn_x(mfn), nr = 1UL << order; + + if ( !sparse_dmap_configured() ) + return 0; + + /* Xenheap pages must be reachable through the sparse view. */ + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); + + if ( !sparse_dmap_root ) + { + early_range_add(early_xenheap, &nr_early_xenheap, + ARRAY_SIZE(early_xenheap), s, s + nr); + return 0; + } + + return add_to_sparse_view(sparse_dmap_root, s, nr); +} + +/* + * Xenheap pages are about to be freed. A failure means the pages may still + * be reachable through the sparse view, and must not be reused. + */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +{ + unsigned long s = mfn_x(mfn), nr = 1UL << order; + + if ( !sparse_dmap_configured() ) + return 0; + + BUG_ON(s + nr > SPARSE_DMAP_END_MFN); + + if ( !sparse_dmap_root ) + { + early_range_del(early_xenheap, &nr_early_xenheap, s, s + nr); + return 0; + } + + return remove_from_sparse_view(s, nr); +} + +/* Memory leaves Xen's hands without passing through the heap. */ +int sparse_dmap_remove(mfn_t mfn, unsigned long nr) +{ + return arch_heap_pages_init(mfn, nr) ? 0 : -ENOMEM; +} + +/* + * A page-table page of idle_pg_table's hierarchy is about to be freed. One + * the boot allocator provided is in the sparse view, as every boot-time + * allocation is: take it out before the heap may hand it on. One allocated + * since came from the heap and is not in the sparse view, which a lookup + * finds without changing, or flushing, anything. Non-zero: the page may + * still be mapped, and must not be freed. + */ +int sparse_dmap_drop_pagetable(mfn_t mfn) +{ + unsigned long s = mfn_x(mfn), nr = 1, n; + pte_attr_t flags; + int rc; + + if ( !sparse_dmap_root || !clip_to_sparse_view(&s, &nr) || + mfn_eq(xen_mapping_lookup(sparse_dmap_root, + (unsigned long)mfn_to_virt(s), &flags, &n), + INVALID_MFN) ) + return 0; + + rc = remove_from_sparse_view(s, 1); + if ( rc ) + printk(XENLOG_WARNING + "Leaking page-table page %"PRI_mfn": still in the sparse directmap\n", + mfn_x(mfn)); + + return rc; +} + +int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, + pte_attr_t flags) +{ + if ( !sparse_dmap_root || virt < SPARSE_DMAP_START || + virt >= SPARSE_DMAP_END ) + return 0; + + nr = min(nr, (SPARSE_DMAP_END - virt) >> PAGE_SHIFT); + + return map_pages_in(sparse_dmap_root, virt, mfn, nr, flags); +} + +int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf) +{ + unsigned long va; + + if ( !sparse_dmap_root || e <= SPARSE_DMAP_START || + s >= SPARSE_DMAP_END ) + return 0; + + s = max(s, SPARSE_DMAP_START); + e = min(e, SPARSE_DMAP_END); + + if ( !(nf & _PAGE_PRESENT) ) + return modify_mappings_in(sparse_dmap_root, s, e, nf); + + /* + * A permission change applies where the sparse view maps anything: it + * never creates mappings, and the sparse view need not map all of [s, e). + */ + for ( va = s; va < e; ) + { + pte_attr_t flags; + unsigned long n; + mfn_t mfn = xen_mapping_lookup(sparse_dmap_root, va, &flags, &n); + int rc; + + n = min(n, (e - va) >> PAGE_SHIFT); + if ( !mfn_eq(mfn, INVALID_MFN) && + (rc = modify_mappings_in(sparse_dmap_root, va, + va + (n << PAGE_SHIFT), nf)) ) + return rc; + va += n << PAGE_SHIFT; + } + + return 0; +} + +static int __init cf_check cmp_mfn_range(const void *a, const void *b) +{ + const struct mfn_range *l = a, *r = b; + + if ( l->s > r->s ) + return 1; + if ( l->s < r->s ) + return -1; + + return 0; +} + +static void __init cf_check swap_mfn_range(void *a, void *b) +{ + SWAP(*(struct mfn_range *)a, *(struct mfn_range *)b); +} + +/* + * Build the sparse view: the full directmap, minus the ranges handed to the + * heap so far, plus the xenheap allocations made from them. Called once the + * heap has taken over from the boot allocator, so that the page-tables come + * from the heap, and before any other CPU is up. + */ +void __init sparse_dmap_init(void) +{ + unsigned long va, mapped = 0; + unsigned int i, heap_idx; + + if ( !sparse_dmap_configured() ) + return; + + if ( early_overflow ) + { + printk(XENLOG_WARNING + "Sparse directmap: too many early heap ranges, disabled\n"); + opt_sparse_dmap_pv = opt_sparse_dmap_hvm = opt_sparse_dmap_hwdom = + false; + return; + } + + /* An L3 for every slot, so that the L4 entries never change. */ + for ( va = SPARSE_DMAP_START; va < SPARSE_DMAP_END; + va += 1UL << L4_PAGETABLE_SHIFT ) + { + mfn_t l3mfn; + void *l3t = alloc_mapped_pagetable(&l3mfn); + + if ( !l3t ) + panic("Sparse directmap: out of memory\n"); + unmap_domain_page(l3t); + sparse_l4[l4_table_offset(va)] = + l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR); + } + + sort(early_heap, nr_early_heap, sizeof(*early_heap), cmp_mfn_range, + swap_mfn_range); + + /* + * The full directmap, leaf by leaf, minus the ranges added to the + * heap. Leaves come in address order, which is MFN order in the + * directmap, and the heap ranges are sorted and disjoint, so + * heap_idx only moves forward. + */ + for ( va = SPARSE_DMAP_START, heap_idx = 0; va < SPARSE_DMAP_END; ) + { + pte_attr_t flags; + unsigned long n, s, e; + + /* Get information about the leaf PTE at va. */ + mfn_t mfn = xen_mapping_lookup(idle_pg_table, va, &flags, &n); + + /* Clip the va range we're considering to SPARSE_DMAP_END. */ + n = min(n, (SPARSE_DMAP_END - va) >> PAGE_SHIFT); + if ( mfn_eq(mfn, INVALID_MFN) ) + { + va += n << PAGE_SHIFT; + continue; + } + + /* + * Walk through the range [mfn, mfn + n) looking for ranges not + * handed to the heap. + */ + for ( s = mfn_x(mfn), e = s + n; s < e; ) + { + unsigned long upto = e; + + /* Step past heap ranges that end at or before s. */ + while ( heap_idx < nr_early_heap && early_heap[heap_idx].e <= s ) + heap_idx++; + + /* s lies in a heap range: skip to its end. */ + if ( heap_idx < nr_early_heap && early_heap[heap_idx].s <= s ) + { + s = min(e, early_heap[heap_idx].e); + continue; + } + + /* Map up to the next heap range, or to the end of the leaf. */ + if ( heap_idx < nr_early_heap ) + upto = min(e, early_heap[heap_idx].s); + + if ( map_pages_in(sparse_l4, va + ((s - mfn_x(mfn)) << PAGE_SHIFT), + _mfn(s), upto - s, flags) ) + panic("Sparse directmap: out of memory\n"); + mapped += upto - s; + s = upto; + } + + va += n << PAGE_SHIFT; + } + + /* + * Now add back in ranges from the heap which were allocated to + * the xenheap. + */ + for ( i = 0; i < nr_early_xenheap; i++ ) + { + unsigned long nr = early_xenheap[i].e - early_xenheap[i].s; + + if ( add_to_sparse_view(sparse_l4, early_xenheap[i].s, nr) ) + panic("Sparse directmap: out of memory\n"); + mapped += nr; + } + + /* + * Nothing in the directmap is executed: its slots are NX, as the full + * directmap's are. + */ + if ( cpu_has_nx ) + for ( i = l4_table_offset(SPARSE_DMAP_START); + i < l4_table_offset(SPARSE_DMAP_END); i++ ) + l4e_add_flags(sparse_l4[i], _PAGE_NX_BIT); + + sparse_dmap_root = sparse_l4; + + printk(XENLOG_INFO "Sparse directmap: %lu pages mapped\n", mapped); +} diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 5b289e444f..8f2f605e45 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -167,6 +167,9 @@ config HAS_STATIC_MEMORY config HAS_SOFT_RESET bool +config HAS_SPARSE_DIRECTMAP + bool + config HAS_STACK_PROTECTOR bool @@ -299,6 +302,21 @@ config SPECULATIVE_HARDEN_LOCK This option is disabled by default at run time, and needs to be enabled on the command line. + +config SPARSE_DIRECTMAP + bool "Sparse directmap view" + depends on HAS_SPARSE_DIRECTMAP + help + Build support for a sparse view of the directmap, alongside the + full one: it maps only the memory Xen needs to reach at all times + (the Xen heap, Xen's own image, firmware tables), while guest + memory is reached through transient mappings. Guest contexts + selected with the `asi=` command line option run on the sparse + directmap view, narrowing the memory reachable from Xen's address + space while they run, and hence the memory disclosure surface of + speculative side channels. + + If unsure, say N. endmenu menu "Other hardening" diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index e8f9993286..2bcc45cf58 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -98,6 +98,19 @@ bool scrub_free_pages(void); * Hooks for an architecture keeping a second, sparse view of its directmap, * which maps the xenheap but not the rest of the heap's memory. */ +#ifdef CONFIG_SPARSE_DIRECTMAP +/* Memory is about to be handed to the heap. False: don't, keep it out. */ +bool arch_heap_pages_init(mfn_t mfn, unsigned long nr); +/* Xenheap pages are to be allocated. True: scrub those needing it first. */ +bool arch_xenheap_needs_scrub(void); +/* + * Xenheap pages were allocated. Non-zero: failed, possibly part-way; the + * pages go through arch_xenheap_pages_free() before being freed again. + */ +int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order); +/* Xenheap pages are to be freed. Non-zero: failed, don't reuse them. */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order); +#else static inline bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) { return true; @@ -114,6 +127,7 @@ static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) { return 0; } +#endif /* Free an allocation, and zero the pointer to it. */ #define FREE_XENHEAP_PAGES(p, o) do { \ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463790.1674603 (Exim 4.92) (envelope-from ) id 1xMD6Q-0005E5-Eu; Wed, 28 Oct 2026 23:30:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463790.1674603; Wed, 28 Oct 2026 23:30: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 1xMD6Q-0005A3-35; Wed, 28 Oct 2026 23:30:42 +0000 Received: by outflank-mailman (input) for mailman id 1463790; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048K-RW for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pO1-29SG; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjn-00000001KpM-0NMM; Wed, 28 Oct 2026 23: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" 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=+ze/mUts7B6alTNouyX2ejvqaet9bE/wAgVhHkz5gYM=; b=L1QZV77DZv2kqUzdaEjiKeNt2P vYEhqvGJ/DEwb18S77KFu43mU2Y8cvsmU900pAPO4E2wmuCMz7TCs4TuHNAxSFQ06JNDILXVnOS5x r8D7RNFw4I13wKhotdO9kQlT5UST0DLuhLqcGT5YH39FquPlcjeZ09arqopN8Lh1H/Lk=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 41/45] x86/fpu: Pass explicit xsave areas to fpu_(f)xsave() Date: Wed, 28 Oct 2026 23:05:55 +0000 Message-ID: <20261028-asi-hvm-v5-41-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Alejandro Vallejo Have the save entry point fetch the vCPU's XSAVE area once, through the VCPU_MAP_XSAVE_AREA() seam, and pass the resulting pointer down explicitly: xsave() gains an area parameter in place of its internal dereference, and fpu_fxsave() takes the legacy region directly. The lower-level helpers no longer know where a vCPU's save area lives, which is the property the coming relocation of guest save areas relies on; the vcpu pointers become const on the way. No functional change. Signed-off-by: Alejandro Vallejo Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Revived from "x86: Address Space Isolation FPU preparations" v3 patch 10/12 (<20250110132823.24348-11-alejandro.vallejo@cloud.com>, Acked-by Jan Beulich; no v4 was ever posted). Changes in v5: - New in this version. Changes since the previously posted version: - Regenerated against the eager-FPU-only tree: the entry point is now vcpu_save_fpu() (vcpu_xsave_mask()/_vcpu_save_fpu() no longer exist), and the mask is always XSTATE_ALL. - Expanded the commit message. --- xen/arch/x86/i387.c | 18 ++++++++++++------ xen/arch/x86/include/asm/xstate.h | 2 +- xen/arch/x86/xstate.c | 3 +-- 3 files changed, 14 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c index c6796bc97b..65491b5697 100644 --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -109,7 +109,8 @@ static inline void fpu_fxrstor(struct vcpu *v) /*******************************/ /* Save x87 extended state */ -static inline void fpu_xsave(struct vcpu *v) +static inline void fpu_xsave(const struct vcpu *v, + struct xsave_struct *xsave_area) { bool ok; @@ -119,15 +120,14 @@ static inline void fpu_xsave(struct vcpu *v) */ ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE); ASSERT(ok); - xsave(v, XSTATE_ALL); + xsave(v, xsave_area, XSTATE_ALL); ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE); ASSERT(ok); } /* Save x87 FPU, MMX, SSE and SSE2 state */ -static inline void fpu_fxsave(struct vcpu *v) +static inline void fpu_fxsave(const struct vcpu *v, fpusse_t *fpu_ctxt) { - fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; unsigned int fip_width = v->domain->arch.x87_fip_width; if ( fip_width != 4 ) @@ -192,15 +192,21 @@ void vcpu_restore_fpu(struct vcpu *v) */ void vcpu_save_fpu(struct vcpu *v) { + struct xsave_struct *xsave_area; + ASSERT(!is_idle_vcpu(v)); /* This can happen, if a paravirtualised guest OS has set its CR0.TS. */ clts(); + xsave_area = VCPU_MAP_XSAVE_AREA(v); + if ( cpu_has_xsave ) - fpu_xsave(v); + fpu_xsave(v, xsave_area); else - fpu_fxsave(v); + fpu_fxsave(v, &xsave_area->fpu_sse); + + VCPU_UNMAP_XSAVE_AREA(v, xsave_area); } /* Initialize FPU's context save area */ diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h index 0519379edb..40bb6f152e 100644 --- a/xen/arch/x86/include/asm/xstate.h +++ b/xen/arch/x86/include/asm/xstate.h @@ -95,7 +95,7 @@ uint64_t get_xcr0(void); void set_msr_xss(u64 xss); uint64_t get_msr_xss(void); uint64_t read_bndcfgu(void); -void xsave(struct vcpu *v, uint64_t mask); +void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask); void xrstor(struct vcpu *v, uint64_t mask); void xstate_set_init(uint64_t mask); bool xsave_enabled(const struct vcpu *v); diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 2eae3f098d..058bc4c0bc 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -304,9 +304,8 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size) VCPU_UNMAP_XSAVE_AREA(v, xstate); } -void xsave(struct vcpu *v, uint64_t mask) +void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask) { - struct xsave_struct *ptr = v->arch.xsave_area; uint32_t hmask = mask >> 32; uint32_t lmask = mask; unsigned int fip_width = v->domain->arch.x87_fip_width; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463787.1674573 (Exim 4.92) (envelope-from ) id 1xMD6O-0004Za-3d; Wed, 28 Oct 2026 23:30:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463787.1674573; Wed, 28 Oct 2026 23:30: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 1xMD6N-0004V2-Tz; Wed, 28 Oct 2026 23:30:39 +0000 Received: by outflank-mailman (input) for mailman id 1463787; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00047z-MY for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pNx-1lM3; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjb-00000001KpM-0c14; Wed, 28 Oct 2026 23:07: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=x3Vx8q2pS91S3VIbmLZaIAr7uWnHJgNTJ/Nzz6y5x7k=; b=GJGBBUhazwLI1pIZEQMb4WxmYe 5ltdacPokxGJtkWZJ596SQy6OJoH8NxWMlkXkksXGLoekxC7QgOOX6SALu+R82bN+AAz2AcTtnz0c ryTUVky/v2ZHpd5CgbcMIdiYuQ/UEIZJHpAhOtFY6fQsO7lKz24lp2c3DjzblyOvulK4=; From: George Dunlap 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 v5 29/45] x86/svm: drop svm_vmcb_dump()'s paddr Date: Wed, 28 Oct 2026 23:05:43 +0000 Message-ID: <20261028-asi-hvm-v5-29-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit svm_vmcb_dump() prints virt_to_maddr() of the VMCB, which is right only while VMCBs are reached through the directmap. Print the virtual address alone. This prepares for moving VMCBs off always-mapped memory. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- CC: Ross Lagerwall Changes in v5: - Keep VCPU_svm_vmcb: svm_asm_do_resume() now uses it, since df8d101a3854 ("x86/svm: Work around VMRUN's corruption of VMCB.INTR_SHADOW") in staging. - Retitle (was: "x86/svm: drop svm_vmcb_dump()'s paddr and the unused VCPU_svm_vmcb"). Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/vmcb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 5e193be9cd..21005dc57f 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -280,8 +280,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) svm_sync_vmcb(curr, vmcb_in_sync); printk("Dumping guest's current state at %s...\n", from); - printk("Size of VMCB = %zu, paddr = %"PRIpaddr", vaddr = %p\n", - sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb); + printk("Size of VMCB = %zu, vaddr = %p\n", + sizeof(struct vmcb_struct), vmcb); printk("cr_intercepts = %#x dr_intercepts = %#x " "exception_intercepts = %#x\n", -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463783.1674549 (Exim 4.92) (envelope-from ) id 1xMD6M-0004DK-VU; Wed, 28 Oct 2026 23:30:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463783.1674549; Wed, 28 Oct 2026 23:30: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 1xMD6M-0004CX-Qo; Wed, 28 Oct 2026 23:30:38 +0000 Received: by outflank-mailman (input) for mailman id 1463783; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00046e-Kn for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pO5-2Uho; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjV-00000001KpM-3XUl; Wed, 28 Oct 2026 23:07: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: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=i1wbpW4BY2W0hqgemwJfZ+sCkZmvITqg+06/Ze/8QsE=; b=V4M2EqfmHdnhs5DUlIO2eCXj+m XyoiPH2n7VVUGbv64Sstz0kW19J9dxIxgoRmsttFOcReJ9FoYdP7tsH1in50RXsIRYh3iS+IURnsD jNK3k5MVkpPcUI+4Y08oOGV7uz2fd7U1v18GPzlQlmNSYQ1RFlv698ttbhuTpLnZtdVE=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v5 24/45] x86/mm: split a sparse directmap superpage with a page being freed Date: Wed, 28 Oct 2026 23:05:38 +0000 Message-ID: <20261028-asi-hvm-v5-24-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A xenheap free takes its pages out of the sparse directmap view. Where a superpage covers them, the superpage has to be split, and modify_mappings_in() allocates the page-table page for that. The sparse view has such superpages wherever a xenheap block of 2MiB or more was mapped whole, and wherever map_pages_in() merged the entries of a 2MiB region into one, as it does in the full directmap, once all 512 pages were mapped. The allocation can fail once the hardware domain exists, and the free then keeps its pages out of the heap for good, with a warning. Use one of the pages being freed instead. The sparse view's free hook makes the first of them what alloc_xen_pagetable() would return, and passes it to modify_mappings_in(), which uses it, should a split need a page, before allocating one. The new L1 maps the rest of the superpage, and the page's own entry is cleared along with the others being freed. The hook tells free_xenheap_pages() whether it kept the page, and free_xenheap_pages() then frees the rest of the block as blocks of orders 0 to order - 1. The page goes back to the heap once the L1 has emptied, as any page-table page of the sparse view does. One page is enough if the sparse view has no 1GiB pages: a block smaller than 2MiB lies within one 2MiB page and needs one L1, and a larger block covers whole 2MiB pages and needs none, where a block within a 1GiB page could need an L2 as well. So map_pages_in() makes 1GiB pages, by mapping or by merging, only in idle_pg_table's hierarchy; the sparse view keeps its 2MiB pages, mapped and merged. A xenheap free then allocates nothing in the sparse view. The costs: a 2MiB region split this way can merge again only once it has emptied, as its L1 is one of its own pages; where the sparse view maps a whole 1GiB region, which takes memory never handed to the heap and xenheap memory filling it, contexts on it use 2MiB pages instead of one 1GiB page; and arch_xenheap_pages_free() gains a parameter. The other removals from the sparse view (memory handed to the heap, idle_pg_table's boot-time page-tables, and the undo of a failed xenheap allocation) still allocate when they split a superpage. The sparse view is correct without this, as a free that cannot split its superpage fails safe. It is kept apart from "x86/mm: build and maintain a sparse view of the directmap" so that it can be weighed on its own. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New patch This is a fairly complicated patch to handle a very niche corner case: - All the 4k pages in a superpage happen to have been allocated into the xenheap (and the page table automatically merged into a superpage) - The system is completely out of singleton pages to allocate as pagetables - A free_xenheap_page() is called on a subset of those pages Without this patch, the freed page is leaked; with this patch, one of the freed pages is used as a pagetable page instead. Happy to drop this patch, or move it further to the end of the series, if it helps the main bit of functionality get in. --- xen/arch/x86/include/asm/mm.h | 2 +- xen/arch/x86/mm.c | 34 ++++++++++++++++++++++------ xen/arch/x86/sparse-directmap.c | 40 ++++++++++++++++++++++++++------- xen/common/page_alloc.c | 14 ++++++++---- xen/include/xen/mm.h | 11 ++++++--- 5 files changed, 78 insertions(+), 23 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 7612cf66ef..af43ae01b0 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -601,7 +601,7 @@ void *alloc_mapped_pagetable(mfn_t *pmfn); int map_pages_in(l4_pgentry_t *root, unsigned long virt, mfn_t mfn, unsigned long nr_mfns, pte_attr_t flags); int modify_mappings_in(l4_pgentry_t *root, unsigned long s, unsigned long e, - pte_attr_t nf); + pte_attr_t nf, mfn_t *spare); #ifdef CONFIG_SPARSE_DIRECTMAP mfn_t xen_mapping_lookup(l4_pgentry_t *root, unsigned long va, pte_attr_t *flags, unsigned long *nr); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e25af043bc..8d09a8e2c8 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5541,6 +5541,10 @@ static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) /* * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or * another hierarchy sharing its virtual addresses. + * + * Only idle_pg_table's hierarchy gets 1GiB pages: a xenheap free splits a + * superpage of the sparse directmap view with one of the pages it frees, + * which is enough for a 2MiB page only. */ int map_pages_in( l4_pgentry_t *root, @@ -5550,6 +5554,7 @@ int map_pages_in( pte_attr_t flags) { bool locking = system_state > SYS_STATE_boot; + bool page1gb = cpu_has_page1gb && root == idle_pg_table; l3_pgentry_t *pl3e = NULL, ol3e; l2_pgentry_t *pl2e = NULL, ol2e; l1_pgentry_t *pl1e, ol1e; @@ -5602,7 +5607,7 @@ int map_pages_in( L3T_LOCK(current_l3page); ol3e = *pl3e; - if ( cpu_has_page1gb && + if ( page1gb && IS_L3E_ALIGNED(virt, flags & _PAGE_PRESENT ? mfn : _mfn(0)) && nr_mfns >= (1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT)) && !(flags & (_PAGE_PAT | MAP_SMALL_PAGES)) ) @@ -5888,7 +5893,7 @@ int map_pages_in( } check_l3: - if ( cpu_has_page1gb && + if ( page1gb && (flags == PAGE_HYPERVISOR) && ((nr_mfns == 0) || IS_L3E_ALIGNED(virt, mfn)) ) { @@ -5967,6 +5972,18 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) return map_pages_to_xen(virt, INVALID_MFN, nr_mfns, MAP_SMALL_PAGES); } +static mfn_t take_or_alloc_pagetable(mfn_t *spare) +{ + mfn_t mfn = spare ? *spare : INVALID_MFN; + + if ( mfn_eq(mfn, INVALID_MFN) ) + return alloc_xen_pagetable(); + + *spare = INVALID_MFN; + + return mfn; +} + /* * Alter the permissions of a range of Xen virtual address space. * @@ -5980,10 +5997,13 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * It is an error to call with present flags over an unpopulated range. * * modify_mappings_in() does so in the hierarchy rooted at @root, as - * map_pages_in() does. + * map_pages_in() does. @spare, if not NULL, may hold a page the caller + * gives up for a page-table page, which shattering a superpage then uses + * before allocating one. *@spare reads INVALID_MFN once it has been used, + * and the page is then no longer the caller's. */ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, - unsigned long e, pte_attr_t nf) + unsigned long e, pte_attr_t nf, mfn_t *spare) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -6047,7 +6067,7 @@ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, } /* PAGE1GB: shatter the superpage and fall through. */ - l2mfn = alloc_xen_pagetable(); + l2mfn = take_or_alloc_pagetable(spare); if ( mfn_eq(l2mfn, INVALID_MFN) ) goto out; @@ -6105,7 +6125,7 @@ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, { l1_pgentry_t *l1t; /* PSE: shatter the superpage and try again. */ - mfn_t l1mfn = alloc_xen_pagetable(); + mfn_t l1mfn = take_or_alloc_pagetable(spare); if ( mfn_eq(l1mfn, INVALID_MFN) ) goto out; @@ -6263,7 +6283,7 @@ int modify_mappings_in(l4_pgentry_t *root, unsigned long s, int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) { - int rc = modify_mappings_in(idle_pg_table, s, e, nf); + int rc = modify_mappings_in(idle_pg_table, s, e, nf, NULL); if ( !rc ) rc = sparse_dmap_mirror_modify(s, e, nf); diff --git a/xen/arch/x86/sparse-directmap.c b/xen/arch/x86/sparse-directmap.c index d35a8d6979..adec474f72 100644 --- a/xen/arch/x86/sparse-directmap.c +++ b/xen/arch/x86/sparse-directmap.c @@ -121,12 +121,13 @@ static int add_to_sparse_view(l4_pgentry_t *root, unsigned long mfn, return 0; } -static int remove_from_sparse_view(unsigned long mfn, unsigned long nr) +static int remove_from_sparse_view(unsigned long mfn, unsigned long nr, + mfn_t *spare) { unsigned long va = (unsigned long)mfn_to_virt(mfn); return modify_mappings_in(sparse_dmap_root, va, va + (nr << PAGE_SHIFT), - _PAGE_NONE); + _PAGE_NONE, spare); } /* Memory is about to be handed to the heap allocator. */ @@ -144,7 +145,7 @@ bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) return true; } - if ( remove_from_sparse_view(s, nr) ) + if ( remove_from_sparse_view(s, nr, NULL) ) { printk(XENLOG_ERR "sparse directmap: cannot unmap MFNs %#lx-%#lx, not freeing\n", @@ -188,10 +189,18 @@ int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) /* * Xenheap pages are about to be freed. A failure means the pages may still * be reachable through the sparse view, and must not be reused. + * + * If the caller allows, the first page serves as the page-table page that + * splitting a superpage of the sparse view needs: the new L1 maps the rest + * of the superpage, and the page leaves the sparse view with the others. + * One page is enough: the sparse view has no 1GiB pages, a block below 2MiB + * lies within one 2MiB page, and a larger one covers whole ones. */ -int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order, bool *first_kept) { unsigned long s = mfn_x(mfn), nr = 1UL << order; + mfn_t spare = INVALID_MFN; + int rc; if ( !sparse_dmap_configured() ) return 0; @@ -204,7 +213,22 @@ int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) return 0; } - return remove_from_sparse_view(s, nr); + if ( first_kept ) + { + struct page_info *pg = mfn_to_page(mfn); + + /* Made what alloc_xen_pagetable() would return, in case it is used. */ + pg->count_info &= ~PGC_xen_heap; + page_set_owner(pg, NULL); + spare = mfn; + } + + rc = remove_from_sparse_view(s, nr, &spare); + + if ( first_kept && mfn_eq(spare, INVALID_MFN) ) + *first_kept = true; + + return rc; } /* Memory leaves Xen's hands without passing through the heap. */ @@ -233,7 +257,7 @@ int sparse_dmap_drop_pagetable(mfn_t mfn) INVALID_MFN) ) return 0; - rc = remove_from_sparse_view(s, 1); + rc = remove_from_sparse_view(s, 1, NULL); if ( rc ) printk(XENLOG_WARNING "Leaking page-table page %"PRI_mfn": still in the sparse directmap\n", @@ -267,7 +291,7 @@ int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, e = min(e, SPARSE_DMAP_END); if ( !(nf & _PAGE_PRESENT) ) - return modify_mappings_in(sparse_dmap_root, s, e, nf); + return modify_mappings_in(sparse_dmap_root, s, e, nf, NULL); /* * A permission change applies where the sparse view maps anything: it @@ -283,7 +307,7 @@ int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, n = min(n, (e - va) >> PAGE_SHIFT); if ( !mfn_eq(mfn, INVALID_MFN) && (rc = modify_mappings_in(sparse_dmap_root, va, - va + (n << PAGE_SHIFT), nf)) ) + va + (n << PAGE_SHIFT), nf, NULL)) ) return rc; va += n << PAGE_SHIFT; } diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2150dcbd5e..349de3ddf3 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -2561,7 +2561,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags) * The hook may have mapped part of the pages before failing: take * them out again as a free would, and leak them if that fails too. */ - if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + if ( arch_xenheap_pages_free(page_to_mfn(pg), order, NULL) ) printk(XENLOG_WARNING "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", mfn_x(page_to_mfn(pg)), 1U << order); @@ -2580,6 +2580,7 @@ void free_xenheap_pages(void *v, unsigned int order) { struct page_info *pg; unsigned int i; + bool first_kept = false; ASSERT_ALLOC_CONTEXT(); @@ -2593,7 +2594,7 @@ void free_xenheap_pages(void *v, unsigned int order) * they may remain reachable through it: leak them rather than hand them * out. */ - if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + if ( arch_xenheap_pages_free(page_to_mfn(pg), order, &first_kept) ) { printk(XENLOG_WARNING "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", @@ -2601,10 +2602,15 @@ void free_xenheap_pages(void *v, unsigned int order) return; } - for ( i = 0; i < (1u << order); i++ ) + for ( i = first_kept ? 1 : 0; i < (1u << order); i++ ) pg[i].count_info &= ~PGC_xen_heap; - free_heap_pages(pg, order, true); + if ( !first_kept ) + free_heap_pages(pg, order, true); + else + /* The rest of the block, as the blocks of orders 0 to order - 1. */ + for ( i = 0; i < order; i++ ) + free_heap_pages(pg + (1u << i), i, true); } #endif /* CONFIG_SEPARATE_XENHEAP */ diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 2bcc45cf58..debd511caf 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -108,8 +108,12 @@ bool arch_xenheap_needs_scrub(void); * pages go through arch_xenheap_pages_free() before being freed again. */ int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order); -/* Xenheap pages are to be freed. Non-zero: failed, don't reuse them. */ -int arch_xenheap_pages_free(mfn_t mfn, unsigned int order); +/* + * Xenheap pages are to be freed. Non-zero: failed, don't reuse them. With + * @first_kept not NULL, the arch may keep the first page for itself, and + * then sets *@first_kept to true: that page is not the caller's to free. + */ +int arch_xenheap_pages_free(mfn_t mfn, unsigned int order, bool *first_kept); #else static inline bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) { @@ -123,7 +127,8 @@ static inline int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) { return 0; } -static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order, + bool *first_kept) { return 0; } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463785.1674567 (Exim 4.92) (envelope-from ) id 1xMD6N-0004Qr-QI; Wed, 28 Oct 2026 23:30:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463785.1674567; Wed, 28 Oct 2026 23:30: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 1xMD6N-0004NY-JM; Wed, 28 Oct 2026 23:30:39 +0000 Received: by outflank-mailman (input) for mailman id 1463785; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00046i-LC for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pNt-1PrC; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjf-00000001KpM-3qDu; Wed, 28 Oct 2026 23:07: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=WQj1cjQl+p8b5oV0v8OW8b1WUFrZKB7aQKqa9oZA47g=; b=ZaOjqNH8SGtARaDusK8p8KCXs2 Z/OPcTI9LtSANYJlOFFrXM2+k4KihWLLy4hQ1fpUIZ+0b5UKreeyo7nuPPFUZ+beHDuuNNBWV/cZs T9GWL89w2xz4T2u+PKXasjYGInV2I+8R/6hyfqV03llvwqQEa6SsuOOhhBPLPYQ4m5FQ=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 34/45] x86/hvm: move the emulator's operand caches behind the vCPU state window Date: Wed, 28 Oct 2026 23:05:48 +0000 Message-ID: <20261028-asi-hvm-v5-34-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The HVM emulator keeps two per-vCPU caches of guest data: the read cache (struct hvmemul_cache), which records every guest-memory read made while an instruction is emulated -- guest page-table entries, instruction bytes and memory operands -- so that a re-execution observes the same values, and the three MMIO caches, which hold the operand bytes of an instruction's MMIO accesses. Both are xvmalloc() allocations, from the xmalloc pool on the xenheap, and so mapped in every context, the sparse directmap view included. Disabling the read cache when emulation completes leaves its entries in place. Put both in a domain-heap page of the vCPU's own, mapped for the life of the vCPU at a new slot (index 7) of its state window: the read cache, counts included, then the MMIO caches, 4032 bytes of the page. As "x86: move the saved register frame behind the vCPU state window" does for the register frame, this applies to every HVM vCPU, whatever asi= says; for a vCPU without per-vCPU page tables the window is in the per-domain area that all its domain's vCPUs share, which only that domain's page tables map. The pointers in struct hvm_vcpu_io hold window addresses. hvmemul_cache_init() sets the page up through a transient mapping, as the vCPU is still being built, and hvmemul_cache_destroy(), now out of line, unmaps it before freeing it. The emulator only ever works on the vCPU running, on its own page tables, and reaches the caches through the window address; hvmemul_find_mmio_cache() now asserts as much. The read cache also has users in other contexts: a debugger's guest page walk on a paused vCPU (gdbsx, and the guest stack dump of the debug keys), which reads and extends it if the vCPU was paused mid-emulation, and hvmemul_cancel(), which disables it, on toolstack, VCPUOP_initialise and INIT/SIPI paths. Its accessors therefore map the page transiently unless the vCPU is running on its own page tables, as VCPU_MAP_REGS() does: a single page, so no new failure paths. They drop the mapping with unmap_vcpu_state_page(), which also flushes this CPU's translation. The read and write paths are split into an outer function, which checks and maps the cache once, and a recursive inner one. Cost: a page per HVM vCPU, where the caches took about 4KiB of the xmalloc pool, and the emulator reaches them through a 4KiB mapping in the per-domain area instead of the directmap. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. Notes for reviewers: the sizes before and after, on x86-64 (CONFIG_PAGING_LEVELS 4, MAX_INST_LEN 15). before after read cache ents 16*2*(4+1) + 15*(4+1) (16*2 + 15) * (4+1) = 235 (nents) = 235 (HVMEMUL_CACHE_ENTS) read cache bytes 8 + 235*16 = 3768 the same offsetof(), at 0 MMIO buffer bytes 64 (max_bytes) 64 (MMIO_CACHE_BYTES) MMIO cache bytes 24 + 64 = 88, three 88 (MMIO_CACHE_SIZE), three The page: offset bytes contents 0 8 num_ents, max_ents 8 3760 ents[235], 16 bytes each 3768 88 mmio_cache[0]: 24-byte header, buffer[64] 3856 88 mmio_cache[1] 3944 88 mmio_cache[2] 4032 64 unused The four old allocations together asked for 4032 bytes, the span the page now uses. The limits the code checks, max_ents (235) and space (64), are unchanged. The BUILD_BUG_ON() in hvmemul_cache_init() keeps the end within the page. --- xen/arch/x86/domain.c | 2 + xen/arch/x86/hvm/emulate.c | 196 +++++++++++++++++++------ xen/arch/x86/include/asm/config.h | 1 + xen/arch/x86/include/asm/hvm/emulate.h | 9 +- xen/arch/x86/include/asm/hvm/vcpu.h | 7 + 5 files changed, 165 insertions(+), 50 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 2c27be4437..397508a313 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -596,6 +596,8 @@ int arch_vcpu_create(struct vcpu *v) BUILD_BUG_ON(VCPU_STATE_IDX_N2VMCB >= VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_VMX_MSR >= VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_REGS >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_EMUL >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_EMUL == VCPU_STATE_IDX_REGS); /* Page tables only; torn down with the rest of the per-domain area. */ rc = create_perdomain_mapping(v, VCPU_STATE_START(v), VCPU_STATE_NR_PAGES, diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index cd2831d34b..e2cf982c25 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -9,6 +9,7 @@ * Keir Fraser */ +#include #include #include #include @@ -56,6 +57,26 @@ struct hvmemul_cache } ents[]; }; +/* + * AVX512F scatter/gather insns can access up to 16 independent linear + * addresses, up to 8 bytes size. Each such linear range can span a page + * boundary, i.e. may require two page walks. Account for each insn byte + * individually, both for simplicity and to leave some slack space. + */ +#define HVMEMUL_CACHE_ENTS \ + ((16 * 2 + MAX_INST_LEN) * (CONFIG_PAGING_LEVELS + 1)) + +/* Operand bytes per MMIO cache: up to m512 or a tile row. */ +#define MMIO_CACHE_BYTES 64 + +/* Layout of the caches' page: the read cache, then the MMIO caches. */ +#define MMIO_CACHE_SIZE \ + ROUNDUP(offsetof(struct hvm_mmio_cache, buffer[MMIO_CACHE_BYTES]), \ + __alignof__(struct hvm_mmio_cache)) +#define EMUL_PAGE_MMIO_CACHE(i) \ + (ROUNDUP(offsetof(struct hvmemul_cache, ents[HVMEMUL_CACHE_ENTS]), \ + __alignof__(struct hvm_mmio_cache)) + (i) * MMIO_CACHE_SIZE) + static void hvmtrace_io_assist(const ioreq_t *p) { unsigned int size, event; @@ -1130,6 +1151,9 @@ static struct hvm_mmio_cache *hvmemul_find_mmio_cache( unsigned int i; struct hvm_mmio_cache *cache; + ASSERT(hvio == ¤t->arch.hvm.hvm_io); + ASSERT(this_cpu(pgtable_vcpu) == current); + for ( i = 0; i < hvio->mmio_cache_count; i ++ ) { cache = hvio->mmio_cache[i]; @@ -3057,77 +3081,133 @@ void hvm_dump_emulation_state(const char *loglvl, const char *prefix, int hvmemul_cache_init(struct vcpu *v) { - /* - * AVX512F scatter/gather insns can access up to 16 independent linear - * addresses, up to 8 bytes size. Each such linear range can span a page - * boundary, i.e. may require two page walks. - */ - unsigned int nents = 16 * 2 * (CONFIG_PAGING_LEVELS + 1); - unsigned int i, max_bytes = 64; + struct hvm_vcpu_io *hvio = &v->arch.hvm.hvm_io; + struct page_info *pg = alloc_domheap_page(v->domain, MEMF_no_owner); + void *va = (void *)VCPU_STATE_ADDR(v, VCPU_STATE_IDX_EMUL), *p; struct hvmemul_cache *cache; + unsigned int i; + mfn_t mfn; - /* - * Account for each insn byte individually, both for simplicity and to - * leave some slack space. - */ - nents += MAX_INST_LEN * (CONFIG_PAGING_LEVELS + 1); + BUILD_BUG_ON(EMUL_PAGE_MMIO_CACHE(ARRAY_SIZE(hvio->mmio_cache)) > + PAGE_SIZE); - cache = xvmalloc_flex_struct(struct hvmemul_cache, ents, nents); - if ( !cache ) + if ( !pg ) return -ENOMEM; - /* Cache is disabled initially. */ - cache->num_ents = nents + 1; - cache->max_ents = nents; + mfn = page_to_mfn(pg); + clear_domain_page(mfn); - v->arch.hvm.hvm_io.cache = cache; + /* v != current, so we can't use the vCPU state window. */ + p = map_domain_page(mfn); - for ( i = 0; i < ARRAY_SIZE(v->arch.hvm.hvm_io.mmio_cache); ++i ) + /* Cache is disabled initially. */ + cache = p; + cache->num_ents = HVMEMUL_CACHE_ENTS + 1; + cache->max_ents = HVMEMUL_CACHE_ENTS; + + for ( i = 0; i < ARRAY_SIZE(hvio->mmio_cache); ++i ) { - v->arch.hvm.hvm_io.mmio_cache[i] = - xvmalloc_flex_struct(struct hvm_mmio_cache, buffer, max_bytes); - if ( !v->arch.hvm.hvm_io.mmio_cache[i] ) - return -ENOMEM; - v->arch.hvm.hvm_io.mmio_cache[i]->space = max_bytes; + struct hvm_mmio_cache *mmio = p + EMUL_PAGE_MMIO_CACHE(i); + + mmio->space = MMIO_CACHE_BYTES; } + unmap_domain_page(p); + + populate_perdomain_mapping(v, (unsigned long)va, &mfn, 1, + __PAGE_HYPERVISOR_RW); + + hvio->emul_pg = pg; + hvio->cache = va; + for ( i = 0; i < ARRAY_SIZE(hvio->mmio_cache); ++i ) + hvio->mmio_cache[i] = va + EMUL_PAGE_MMIO_CACHE(i); + return 0; } +void hvmemul_cache_destroy(struct vcpu *v) +{ + struct hvm_vcpu_io *hvio = &v->arch.hvm.hvm_io; + unsigned int i; + + if ( !hvio->emul_pg ) + return; + + unmap_vcpu_state(v, VCPU_STATE_IDX_EMUL, 1); + free_domheap_page(hvio->emul_pg); + hvio->emul_pg = NULL; + hvio->cache = NULL; + for ( i = 0; i < ARRAY_SIZE(hvio->mmio_cache); ++i ) + hvio->mmio_cache[i] = NULL; +} + +/* + * The read cache of @v, for access from any context: the window address in + * struct hvm_vcpu_io where v runs here on its own page tables, a transient + * mapping of the page otherwise, and the NULL left there once the cache is + * destroyed. v's page tables being loaded is not enough: while this CPU + * holds v's state lazily, an IPI syncing that state for another CPU can + * switch them away at any time. + */ +static struct hvmemul_cache *map_cache(const struct vcpu *v) +{ + const struct hvm_vcpu_io *hvio = &v->arch.hvm.hvm_io; + + if ( !hvio->emul_pg || (v == current && this_cpu(pgtable_vcpu) == v) ) + return hvio->cache; + + /* The read cache is at the start of the page. */ + return __map_domain_page(hvio->emul_pg); +} + +static void unmap_cache(const struct vcpu *v, + const struct hvmemul_cache *cache) +{ + if ( cache != v->arch.hvm.hvm_io.cache ) + unmap_vcpu_state_page(cache); +} + +#define HVMEMUL_MAP_CACHE(v) map_cache(v) + +/* Drops the mapping of a vCPU's read cache and nullifies its pointer. */ +#define HVMEMUL_UNMAP_CACHE(v, cache) do { \ + unmap_cache(v, cache); \ + (cache) = NULL; \ +} while ( false ) + unsigned int hvmemul_cache_disable(struct vcpu *v) { - struct hvmemul_cache *cache = v->arch.hvm.hvm_io.cache; + struct hvmemul_cache *cache = HVMEMUL_MAP_CACHE(v); unsigned int token = cache->num_ents; cache->num_ents = cache->max_ents + 1; + HVMEMUL_UNMAP_CACHE(v, cache); + return token; } void hvmemul_cache_restore(struct vcpu *v, unsigned int token) { - struct hvmemul_cache *cache = v->arch.hvm.hvm_io.cache; + struct hvmemul_cache *cache = HVMEMUL_MAP_CACHE(v); ASSERT(cache->num_ents > cache->max_ents); cache->num_ents = token; + + HVMEMUL_UNMAP_CACHE(v, cache); } -bool hvmemul_read_cache(const struct vcpu *v, paddr_t gpa, - void *buffer, unsigned int size) +static bool read_cache(const struct hvmemul_cache *cache, paddr_t gpa, + void *buffer, unsigned int size) { - const struct hvmemul_cache *cache = v->arch.hvm.hvm_io.cache; unsigned int i; - /* Cache unavailable? */ - if ( !is_hvm_vcpu(v) || cache->num_ents > cache->max_ents ) - return false; - while ( size > sizeof(cache->ents->data) ) { i = gpa & (sizeof(cache->ents->data) - 1) ? -gpa & (sizeof(cache->ents->data) - 1) : sizeof(cache->ents->data); - if ( !hvmemul_read_cache(v, gpa, buffer, i) ) + if ( !read_cache(cache, gpa, buffer, i) ) return false; gpa += i; buffer += i; @@ -3144,22 +3224,37 @@ bool hvmemul_read_cache(const struct vcpu *v, paddr_t gpa, return false; } -void hvmemul_write_cache(const struct vcpu *v, paddr_t gpa, - const void *buffer, unsigned int size) +bool hvmemul_read_cache(const struct vcpu *v, paddr_t gpa, + void *buffer, unsigned int size) { - struct hvmemul_cache *cache = v->arch.hvm.hvm_io.cache; - unsigned int i; + const struct hvmemul_cache *cache; + bool hit = false; - /* Cache unavailable? */ - if ( !is_hvm_vcpu(v) || cache->num_ents > cache->max_ents ) - return; + if ( !is_hvm_vcpu(v) ) + return false; + + cache = HVMEMUL_MAP_CACHE(v); + + /* Cache available? */ + if ( cache->num_ents <= cache->max_ents ) + hit = read_cache(cache, gpa, buffer, size); + + HVMEMUL_UNMAP_CACHE(v, cache); + + return hit; +} + +static void write_cache(const struct vcpu *v, struct hvmemul_cache *cache, + paddr_t gpa, const void *buffer, unsigned int size) +{ + unsigned int i; while ( size > sizeof(cache->ents->data) ) { i = gpa & (sizeof(cache->ents->data) - 1) ? -gpa & (sizeof(cache->ents->data) - 1) : sizeof(cache->ents->data); - hvmemul_write_cache(v, gpa, buffer, i); + write_cache(v, cache, gpa, buffer, i); gpa += i; buffer += i; size -= i; @@ -3186,6 +3281,23 @@ void hvmemul_write_cache(const struct vcpu *v, paddr_t gpa, cache->num_ents = i + 1; } +void hvmemul_write_cache(const struct vcpu *v, paddr_t gpa, + const void *buffer, unsigned int size) +{ + struct hvmemul_cache *cache; + + if ( !is_hvm_vcpu(v) ) + return; + + cache = HVMEMUL_MAP_CACHE(v); + + /* Cache available? */ + if ( cache->num_ents <= cache->max_ents ) + write_cache(v, cache, gpa, buffer, size); + + HVMEMUL_UNMAP_CACHE(v, cache); +} + /* * Local variables: * mode: C diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index c8d4a8ddc7..5bd9970fce 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -312,6 +312,7 @@ extern unsigned long xen_phys_start; #define VCPU_STATE_IDX_N2VMCB 1 #define VCPU_STATE_IDX_VMX_MSR 2 #define VCPU_STATE_IDX_REGS 6 +#define VCPU_STATE_IDX_EMUL 7 #define ELFSIZE 64 diff --git a/xen/arch/x86/include/asm/hvm/emulate.h b/xen/arch/x86/include/asm/hvm/emulate.h index 178ac32e15..16491a92b1 100644 --- a/xen/arch/x86/include/asm/hvm/emulate.h +++ b/xen/arch/x86/include/asm/hvm/emulate.h @@ -117,14 +117,7 @@ int hvmemul_do_pio_buffer(uint16_t port, * further re-execution. */ int __must_check hvmemul_cache_init(struct vcpu *v); -static inline void hvmemul_cache_destroy(struct vcpu *v) -{ - unsigned int i; - - for ( i = 0; i < ARRAY_SIZE(v->arch.hvm.hvm_io.mmio_cache); ++i ) - XVFREE(v->arch.hvm.hvm_io.mmio_cache[i]); - XVFREE(v->arch.hvm.hvm_io.cache); -} +void hvmemul_cache_destroy(struct vcpu *v); bool hvmemul_read_cache(const struct vcpu *v, paddr_t gpa, void *buffer, unsigned int size); void hvmemul_write_cache(const struct vcpu *v, paddr_t gpa, diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm/hvm/vcpu.h index 876c230784..ee7bc8be00 100644 --- a/xen/arch/x86/include/asm/hvm/vcpu.h +++ b/xen/arch/x86/include/asm/hvm/vcpu.h @@ -46,6 +46,13 @@ struct hvm_vcpu_io { unsigned char mmio_insn[16]; struct hvmemul_cache *cache; + /* + * The page holding the caches above, mapped in the vCPU's state window: + * mmio_cache[] and cache hold addresses in the window, for use while the + * vCPU's own page tables are loaded. + */ + struct page_info *emul_pg; + /* * For string instruction emulation we need to be able to signal a * necessary retry through other than function return codes. -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463782.1674545 (Exim 4.92) (envelope-from ) id 1xMD6M-0004B0-Nn; Wed, 28 Oct 2026 23:30:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463782.1674545; Wed, 28 Oct 2026 23:30: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 1xMD6M-0004At-Jf; Wed, 28 Oct 2026 23:30:38 +0000 Received: by outflank-mailman (input) for mailman id 1463782; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00046Y-Eg for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pNv-1aho; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjR-00000001KpM-4Bnp; Wed, 28 Oct 2026 23:06: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:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=uF5AU0TsOGRUZl40feFge0+rlPH5GGpTVMZm9buYkhM=; b=e3zXAQjVC1raYjeb6Wvj8+/uUV TdOdzzQj1zYT0S4dIjx8FI2HSgBZ4r+Ijqe+TD/BpVGb/uKHYRSdSotdEZH5ZcysW1l0MaLwCVEsF 6kXBabGgSwrG1DkkrQ+yQAAd8FBm4p9pkK8ghA3r9oIXrLOdBlcaRGGDWON+RF5k+YIY=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 21/45] x86/mm: run guest contexts on the sparse directmap view Date: Wed, 28 Oct 2026 23:05:35 +0000 Message-ID: <20261028-asi-hvm-v5-21-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In init_xen_l4_slots(), if d->arch.asi.sparse_dmap is set, point the directmap slots at the sparse view, copying from idle_pg_table only the Xen slots below them. A root page-table not shared with a PV guest gets no extended directmap, which the sparse view does not cover. d->arch.asi.sparse_dmap is decided at domain creation: PV domains all have a mapcache, HVM domains need per-vCPU page-tables for one. No option asks for the sparse view yet. The sparse view is built before any domain is created, so the root page-tables of every domain using it carry it from their creation, dom0's included. Dom0's builders reach dom0's memory only through guest virtual addresses and map_domain_page(). In PV shim mode, replace_va_mapping() reads the guest's L4 through the directmap; map it with map_domain_page() instead, as the lower levels already are. Shadow L4s, dom0=shadow's included, get the sparse view from init_xen_l4_slots(). The two directmaps differ where the sparse view leaves memory out, so no translation of the full directmap may remain usable on page-tables carrying the sparse view. Directmap mappings stay global nevertheless: every CR3 write which can move a CPU onto the sparse view goes through switch_cr3_cr4(), which flushes the old page-tables' translations, global entries included, before it returns. The CR3 writes which keep entries -- a PV vCPU's switch between its kernel and user page-tables, XPTI's entry and exit -- stay within one vCPU's page-tables, which carry the same directmap, or go to XPTI's per-CPU root, which maps only Xen's own per-CPU pages there. Removals from the sparse view are flushed on every CPU, global entries included. PV guests that run with global pages, among them a PV dom0 not using the sparse view, therefore keep their directmap TLB entries across switches between guest kernel and user mode. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - d->arch.vcpu_pt and d->arch.sparse_dmap are now d->arch.asi.vcpu_pt and d->arch.asi.sparse_dmap. - Drop sparse_dmap_active and sparse_dmap_activate(): root page-tables carry the sparse view from their creation, dom0's included (Roger). - The sparse view's slots are now marked NX in "x86/mm: build and maintain a sparse view of the directmap". - PV shim: replace_va_mapping() maps the guest's L4 with map_domain_page(). - Give sparse_dmap_wanted() its hardware-domain case (Roger). - init_xen_l4_slots() takes the directmap slots from the sparse view, rather than copying the full directmap's and overwriting them; sparse_dmap_install() goes (Roger). - Message: drop the sentence on NX (Roger). Changes in v3: - New in this version. --- xen/arch/x86/include/asm/sparse-directmap.h | 9 +++++++ xen/arch/x86/mm.c | 28 +++++++++++++++++++-- xen/arch/x86/pv/shim.c | 4 ++- xen/arch/x86/spec_ctrl.c | 7 ++++++ 4 files changed, 45 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index ea14d44334..2f8b94f4c1 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -31,6 +31,14 @@ static inline bool sparse_dmap_configured(void) return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; } +/* Whether a new domain of the given type is to use the sparse view. */ +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) +{ + return sparse_dmap_root && + (hwdom ? opt_sparse_dmap_hwdom + : pv ? opt_sparse_dmap_pv : opt_sparse_dmap_hvm); +} + void sparse_dmap_init(void); int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags); @@ -42,6 +50,7 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); #else /* !CONFIG_SPARSE_DIRECTMAP */ static inline bool sparse_dmap_configured(void) { return false; } +static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { return false; } static inline void sparse_dmap_init(void) {} static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 964f9e6a41..e25af043bc 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1703,7 +1703,8 @@ struct page_info *perdomain_l3(const struct vcpu *v) * 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. + * extended directmap, unless the domain runs on the sparse view of the + * directmap, which replaces the directmap slots. * * v is the vCPU the table is private to or, for a table the domain's vCPUs * share, any of them: slot 260 gets perdomain_l3(v), which in a domain @@ -1715,7 +1716,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, const struct domain *d = v->domain; /* * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full - * directmap. + * directmap, unless the domain runs on the sparse view (below). */ bool short_directmap = !paging_mode_external(d); @@ -1751,6 +1752,29 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, l4t[l4_table_offset(PERDOMAIN_VIRT_START)]; /* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */ +#ifdef CONFIG_SPARSE_DIRECTMAP + if ( d->arch.asi.sparse_dmap ) + { + unsigned int i = l4_table_offset(SPARSE_DMAP_START); + + memcpy(&l4t[l4_table_offset(XEN_VIRT_START)], + &idle_pg_table[l4_table_offset(XEN_VIRT_START)], + (i - l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); + + /* + * Every slot the sparse view covers gets its L3, whatever the full + * directmap has there, so that memory added later is covered too. A + * PV root has guest slots above; any other root loses the rest of the + * directmap, which the sparse view does not cover. + */ + for ( ; i < l4_table_offset(SPARSE_DMAP_END); i++ ) + l4t[i] = sparse_dmap_root[i]; + if ( !short_directmap ) + for ( ; i < l4_table_offset(DIRECTMAP_VIRT_END); i++ ) + l4t[i] = l4e_empty(); + } + else +#endif #ifndef NDEBUG if ( short_directmap && unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) ) diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c index 41000b0523..2a47dbc56c 100644 --- a/xen/arch/x86/pv/shim.c +++ b/xen/arch/x86/pv/shim.c @@ -148,12 +148,14 @@ const struct platform_bad_page *__init pv_shim_reserved_pages(unsigned int *size static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start, unsigned long va, mfn_t mfn) { - l4_pgentry_t l4e = l4start[l4_table_offset(va)]; + const l4_pgentry_t *l4t = map_domain_page(virt_to_mfn(l4start)); + l4_pgentry_t l4e = l4t[l4_table_offset(va)]; l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va)); l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va)); l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) + l1_table_offset(va); struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e)); + unmap_domain_page(l4t); put_page_and_type(page); *pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 8797523a62..bcdcdf0476 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -1953,6 +1953,13 @@ void spec_ctrl_init_domain(struct domain *d) d->arch.asi.vcpu_pt = !pv && (is_hardware_domain(d) ? opt_vcpu_pt_hwdom : opt_vcpu_pt_hvm); + + /* + * The sparse directmap view needs a mapcache: PV domains all have one, + * HVM domains through per-vCPU page-tables. + */ + d->arch.asi.sparse_dmap = (pv || d->arch.asi.vcpu_pt) && + sparse_dmap_wanted(pv, is_hardware_domain(d)); } void __init init_speculation_mitigations(void) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463788.1674582 (Exim 4.92) (envelope-from ) id 1xMD6O-0004kp-Nq; Wed, 28 Oct 2026 23:30:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463788.1674582; Wed, 28 Oct 2026 23:30: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 1xMD6O-0004i3-Cy; Wed, 28 Oct 2026 23:30:40 +0000 Received: by outflank-mailman (input) for mailman id 1463788; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-000488-OV for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOf-3YQ3; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjM-00000001KpM-2iMG; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=Lb7F1xsyX+9AldokNzH9xX+s7w05jag/1Hr7PjUMcMQ=; b=l3z8l0yGmyqfmyFdtycjVXedq4 iCQ//Nnas7iBBxKw4PiF6OSB7UIGbld8sxVMjF1UF6qmZGRDO9M6BuRxpLY4sH6lX+wLvQRksId+y CL4GqqpqszWlR/GXnqRXXK2zUXVoBKY4NWivOmnDjYH7blTzFjhJefdGxJ73fk+VaZWQ=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v5 16/45] xen/gunzip: process pending softirqs once per deflate block Date: Wed, 28 Oct 2026 23:05:30 +0000 Message-ID: <20261028-asi-hvm-v5-16-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Nothing in the gzip decompressor lets the CPU run softirqs. The NMI watchdog treats a CPU as stuck once its timer softirq has not run for the watchdog's timeout, 5s by default, so a decompression that runs that long panics the host. Decompression is normally quick, but it need not be. Every compressed deflate block builds its Huffman tables with xmalloc() and frees them with xfree(), and those calls reach the xenheap whenever a request is a page or more, or a free empties an xmalloc pool page. A subsequent change can make every xenheap free end in a TLB flush on all online CPUs. With it in effect, decompressing the PV dom0 kernel and reading its ELF headers on a 480-CPU host took 5.2s instead of 0.5s; with cpufreq=xen:performance max_cstate=1,0 dom0_nodes=0,relaxed added to the command line as well, the watchdog fired before decompression had finished, on each of eight boots. Process pending softirqs after each deflate block, as libelf does for each ELF note since c5089fae0f6f ("x86: avoid tripping watchdog when constructing dom0"), and as the PV and PVH dom0 builders do in their long loops. Every caller of perform_gunzip() runs during domain construction at boot, on the boot CPU with interrupts enabled and no lock held: x86's PV and PVH dom0 builders, which call process_pending_softirqs() themselves, and kernel_decompress(), which Arm uses for dom0 and for dom0less domains. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/common/gzip/gunzip.c | 1 + xen/common/gzip/inflate.c | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c index 89f45d4050..9551d470aa 100644 --- a/xen/common/gzip/gunzip.c +++ b/xen/common/gzip/gunzip.c @@ -3,6 +3,7 @@ #include #include #include +#include #define WSIZE 0x80000000U diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c index cb146555c8..737aff505e 100644 --- a/xen/common/gzip/inflate.c +++ b/xen/common/gzip/inflate.c @@ -1018,6 +1018,7 @@ static int __init inflate(struct gunzip_state *s) r = inflate_block(s, &e); if (r) return r; + process_pending_softirqs(); } while (!e); /* Undo too much lookahead. The next read will be byte aligned so we -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463789.1674599 (Exim 4.92) (envelope-from ) id 1xMD6P-00055G-U9; Wed, 28 Oct 2026 23:30:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463789.1674599; Wed, 28 Oct 2026 23:30: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 1xMD6P-00053u-GR; Wed, 28 Oct 2026 23:30:41 +0000 Received: by outflank-mailman (input) for mailman id 1463789; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048A-PU for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOB-2eJT; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjU-00000001KpM-2Fc5; Wed, 28 Oct 2026 23:07: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" 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=lmWRg/5OLo0R/NPywMyA45Uq6cr7VvMb3O4KA5pNTBc=; b=xJLqG+NQsVQlg75Q/gRxv+Cgef G32BlLOkITvDfZt5cXWYoXatY0hNWu+oMoYPoALLeifhi6J2Cx+iNDPdtM48nP1FgGWNaDHT2HQMf nhOK9Q8uXTPb1zSt7bvDlqUi+zWxah1BBsvj8yOScuoU1EAfWVbEtt2BE00w6l9F8Rh4=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v5 23/45] xen/xmalloc: return an emptied region after dropping the pool lock Date: Wed, 28 Oct 2026 23:05:37 +0000 Message-ID: <20261028-asi-hvm-v5-23-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When a free leaves a whole region of an xmalloc pool empty, xmem_pool_free() hands the region back through pool->put_mem() with pool->lock still held. For the xenheap pool that is free_xenheap_pages(), which takes the heap lock inside the pool lock and runs arch_xenheap_pages_free(). On x86 with a sparse directmap view configured, the latter takes the page out of the sparse view, at the cost of one to three rounds of TLB-flush IPIs to every CPU, while every other CPU's sub-page xmalloc() and xfree() waits on the pool lock. By then the region is on no free list and no longer counted in the pool, so nothing else can reach it. Drop the lock first and return the region afterwards, as xmem_pool_alloc() already does when it calls pool->get_mem(), and say at both callbacks that they are called without the pool lock, so that they keep not relying on it. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- xen/common/xmalloc_tlsf.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c index b43219b4af..caf33f1a04 100644 --- a/xen/common/xmalloc_tlsf.c +++ b/xen/common/xmalloc_tlsf.c @@ -106,7 +106,10 @@ struct xmem_pool { unsigned long used_size; unsigned long num_regions; - /* User provided functions for expanding/shrinking pool */ + /* + * User provided functions for expanding/shrinking pool. They are + * called without the pool lock held, and must not rely on it. + */ xmem_pool_get_memory *get_mem; xmem_pool_put_memory *put_mem; @@ -488,17 +491,18 @@ void xmem_pool_free(void *ptr, struct xmem_pool *pool) if ( (b->prev_hdr == NULL) && ((tmp_b->size & BLOCK_SIZE_MASK) == 0) ) { - pool->put_mem(b); pool->num_regions--; pool->used_size -= BHDR_OVERHEAD; /* sentinel block header */ - goto out; + spin_unlock(&pool->lock); + pool->put_mem(b); + return; } INSERT_BLOCK(b, pool, fl, sl); tmp_b->size |= PREV_FREE; tmp_b->prev_hdr = b; - out: + spin_unlock(&pool->lock); } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463786.1674560 (Exim 4.92) (envelope-from ) id 1xMD6N-0004KA-H8; Wed, 28 Oct 2026 23:30:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463786.1674560; Wed, 28 Oct 2026 23:30: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 1xMD6N-0004IU-AX; Wed, 28 Oct 2026 23:30:39 +0000 Received: by outflank-mailman (input) for mailman id 1463786; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00047y-MU for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pNr-1DM6; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjc-00000001KpM-16ji; Wed, 28 Oct 2026 23:07: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=dopVYxwE5WZJQ7rniOXqTSn3Q1J1g9fMCABmI8qjVpI=; b=BC1kz2aHvWcRD+zubCZXCKjCec mgfIE//9F9RlUVuUOitVBzY8iPx/h0f8GS67en7hLD+4dx4+Ig/94B2qM83fEBAAaijYre6Xcwx3f lvFE6fv3fejBVvriL4b/YKijXobchYUalYeCcW55FOCoPRTZZY48De1BRySgJVVFFcw0=; From: George Dunlap 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 v5 30/45] x86/svm: allocate VMCBs from the domain heap behind the vCPU state window Date: Wed, 28 Oct 2026 23:05:44 +0000 Message-ID: <20261028-asi-hvm-v5-30-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The VMCB holds the full guest register save area, but lives on the xenheap, where it stays reachable from every context. Move it to the domain heap and map it at a fixed slot in the owning vCPU's state window, so that under Address Space Isolation it is only mapped while that vCPU's page tables are loaded. Hardware is unaffected: VMRUN, VMLOAD and VMSAVE address the VMCB physically, and vmcb_pa now derives from the page rather than from virt_to_maddr() on a directmap VA. A vCPU can have two VMCBs: the primary (nv_n1vmcx) and the nested L2 one (nv_n2vmcx). Both move, taking the first two slots in the window stride. The nested code's swapping of svm->vmcb / svm->vmcb_pa between the two works unchanged, now swapping between two window VAs. free_vmcb() takes a VMCB out of the window with unmap_vcpu_state() before freeing the page: without per-vCPU page tables the window is in the per-domain area that all its domain's vCPUs share, which outlives a vCPU whose creation fails. The window VA is only valid in the owning vCPU's context. SVM_MAP_VMCB() and SVM_MAP_VMCB_ONE() return it for v == current, and a transient map_domain_page() mapping otherwise, which SVM_UNMAP_VMCB() drops with unmap_vcpu_state_page(), along with this CPU's translations of it. svm_ctxt_switch_to() no longer touches the VMCB, as it runs before write_ptbase(); svm_ctxt_switch_from() keeps dereferencing the window VA, as the outgoing page tables are still loaded at that point. svm_asm_do_resume() reads the VMCB's interrupt shadow through the window VA just before VMRUN, with the vCPU's own page tables loaded. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- CC: Ross Lagerwall Changes in v5: - Describe the mapping in terms of SVM_MAP_VMCB(), SVM_MAP_VMCB_ONE() and SVM_UNMAP_VMCB(), which clears the pointer (George). - v4's 26/30, "x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from()", is dropped. Ross's "x86/svm: Don't clear clean bits on every context switch", now in staging as 69633efbca3c, removes the clearing from svm_ctxt_switch_to() instead. - svm_asm_do_resume() now reads the VMCB through svm.vmcb (staging's "x86/svm: Work around VMRUN's corruption of VMCB.INTR_SHADOW"); it runs in the vCPU's own context, where the window VA is valid. Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/nestedsvm.c | 8 +++--- xen/arch/x86/hvm/svm/svm.c | 10 ++++++++ xen/arch/x86/hvm/svm/vmcb.c | 43 ++++++++++++++++++++++---------- xen/arch/x86/hvm/svm/vmcb.h | 15 ++++++++--- 4 files changed, 56 insertions(+), 20 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index ff5d7df301..6eea641ab5 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -71,10 +71,9 @@ int cf_check nsvm_vcpu_initialise(struct vcpu *v) goto err; memset(msrpm, 0x0, MSRPM_SIZE); - nv->nv_n2vmcx = alloc_vmcb(); + nv->nv_n2vmcx = alloc_vmcb(v, VCPU_STATE_IDX_N2VMCB, &nv->nv_n2vmcx_pa); if ( nv->nv_n2vmcx == NULL ) goto err; - nv->nv_n2vmcx_pa = virt_to_maddr(nv->nv_n2vmcx); return 0; @@ -95,7 +94,10 @@ void cf_check nsvm_vcpu_destroy(struct vcpu *v) * of l1 vmcb page. */ if ( nv->nv_n1vmcx ) + { v->arch.hvm.svm.vmcb = nv->nv_n1vmcx; + v->arch.hvm.svm.vmcb_pa = nv->nv_n1vmcx_pa; + } if ( svm->ns_cached_msrpm ) { @@ -113,7 +115,7 @@ void cf_check nsvm_vcpu_destroy(struct vcpu *v) if ( nv->nv_n2vmcx ) { - free_vmcb(nv->nv_n2vmcx); + free_vmcb(v, VCPU_STATE_IDX_N2VMCB, nv->nv_n2vmcx_pa); nv->nv_n2vmcx = NULL; nv->nv_n2vmcx_pa = INVALID_PADDR; } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index df56245311..8b593b1b39 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -265,6 +265,10 @@ static void cf_check svm_enable_msr_interception(struct domain *d, uint32_t msr) static void svm_save_dr(struct vcpu *v) { + /* + * @v is the outgoing vCPU, whose page tables are still loaded: the + * VMCB's window VA serves, although current has moved on. + */ struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; unsigned int flag_dr_dirty = v->arch.hvm.flag_dr_dirty; @@ -940,6 +944,12 @@ static void cf_check svm_ctxt_switch_to(struct vcpu *v) { int cpu = smp_processor_id(); + /* + * NB we cannot access the VMCB here: this runs before + * write_ptbase(), so the incoming vCPU's state window is not + * reachable yet. + */ + /* * This is required, because VMRUN does consistency check and some of the * DOM0 selectors are pointing to invalid GDT locations, and cause AMD diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 21005dc57f..6588ec87e6 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -6,6 +6,7 @@ * */ +#include #include #include #include @@ -23,30 +24,40 @@ #include "svm.h" #include "vmcb.h" -struct vmcb_struct *alloc_vmcb(void) +struct vmcb_struct *alloc_vmcb(struct vcpu *v, unsigned int idx, paddr_t *pa) { - struct vmcb_struct *vmcb; + struct page_info *pg = alloc_domheap_page(v->domain, MEMF_no_owner); + mfn_t mfn; + + ASSERT(idx < VCPU_STATE_NR_PAGES); - vmcb = alloc_xenheap_page(); - if ( vmcb == NULL ) + if ( pg == NULL ) { printk(XENLOG_WARNING "Warning: failed to allocate vmcb.\n"); return NULL; } - clear_page(vmcb); - return vmcb; + mfn = page_to_mfn(pg); + clear_domain_page(mfn); + populate_perdomain_mapping(v, VCPU_STATE_ADDR(v, idx), &mfn, 1, + __PAGE_HYPERVISOR_RW); + *pa = mfn_to_maddr(mfn); + + return (struct vmcb_struct *)VCPU_STATE_ADDR(v, idx); } -void free_vmcb(struct vmcb_struct *vmcb) +void free_vmcb(struct vcpu *v, unsigned int idx, paddr_t pa) { - free_xenheap_page(vmcb); + ASSERT(idx < VCPU_STATE_NR_PAGES); + + unmap_vcpu_state(v, idx, 1); + free_domheap_page(maddr_to_page(pa)); } struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, struct vmcb_struct *va, paddr_t pa) { - return va; + return v == current ? va : map_domain_page(maddr_to_mfn(pa)); } struct vmcb_struct *svm_vmcb_map(const struct vcpu *v) @@ -56,6 +67,8 @@ struct vmcb_struct *svm_vmcb_map(const struct vcpu *v) void svm_vmcb_unmap(const struct vcpu *v, const struct vmcb_struct *vmcb) { + if ( v != current ) + unmap_vcpu_state_page(vmcb); } /* This function can directly access fields which are covered by clean bits. */ @@ -219,26 +232,29 @@ int svm_create_vmcb(struct vcpu *v) int rc; if ( (nv->nv_n1vmcx == NULL) && - (nv->nv_n1vmcx = alloc_vmcb()) == NULL ) + (nv->nv_n1vmcx = alloc_vmcb(v, VCPU_STATE_IDX_VMCB, + &nv->nv_n1vmcx_pa)) == NULL ) { printk("Failed to create a new VMCB\n"); return -ENOMEM; } svm->vmcb = nv->nv_n1vmcx; + svm->vmcb_pa = nv->nv_n1vmcx_pa; vmcb = SVM_MAP_VMCB(v); rc = construct_vmcb(v, vmcb); SVM_UNMAP_VMCB(v, vmcb); if ( rc != 0 ) { - free_vmcb(nv->nv_n1vmcx); + free_vmcb(v, VCPU_STATE_IDX_VMCB, nv->nv_n1vmcx_pa); nv->nv_n1vmcx = NULL; + nv->nv_n1vmcx_pa = INVALID_PADDR; svm->vmcb = NULL; + svm->vmcb_pa = INVALID_PADDR; return rc; } - svm->vmcb_pa = nv->nv_n1vmcx_pa = virt_to_maddr(svm->vmcb); return 0; } @@ -248,7 +264,7 @@ void svm_destroy_vmcb(struct vcpu *v) struct svm_vcpu *svm = &v->arch.hvm.svm; if ( nv->nv_n1vmcx != NULL ) - free_vmcb(nv->nv_n1vmcx); + free_vmcb(v, VCPU_STATE_IDX_VMCB, nv->nv_n1vmcx_pa); if ( svm->msrpm != NULL ) { @@ -260,6 +276,7 @@ void svm_destroy_vmcb(struct vcpu *v) nv->nv_n1vmcx = NULL; nv->nv_n1vmcx_pa = INVALID_PADDR; svm->vmcb = NULL; + svm->vmcb_pa = INVALID_PADDR; } static void svm_dump_sel(const char *name, const struct segment_register *s) diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index d49c910d46..9e1e9ec1cd 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -556,12 +556,19 @@ struct vmcb_struct { uint64_t res18[291]; }; -struct vmcb_struct *alloc_vmcb(void); -void free_vmcb(struct vmcb_struct *vmcb); +/* + * VMCBs are domain-heap pages: hardware addresses them physically, and + * Xen maps each one at a fixed slot in the owning vCPU's state window, + * so the returned virtual address is valid only in that vCPU's context. + * @idx is the VCPU_STATE_IDX_* slot to place the mapping in. + */ +struct vmcb_struct *alloc_vmcb(struct vcpu *v, unsigned int idx, paddr_t *pa); +void free_vmcb(struct vcpu *v, unsigned int idx, paddr_t pa); /* - * Access a VMCB of a vCPU that may not be current. SVM_MAP_VMCB() takes - * the active VMCB, SVM_MAP_VMCB_ONE() a specific one. + * Access a VMCB of a vCPU that may not be current: the window VA for + * current, a transient mapping otherwise. SVM_MAP_VMCB() takes the active + * VMCB, SVM_MAP_VMCB_ONE() a specific one. */ struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, struct vmcb_struct *va, paddr_t pa); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463792.1674613 (Exim 4.92) (envelope-from ) id 1xMD6R-0005Pu-G1; Wed, 28 Oct 2026 23:30:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463792.1674613; Wed, 28 Oct 2026 23:30: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 1xMD6Q-0005NJ-Qs; Wed, 28 Oct 2026 23:30:42 +0000 Received: by outflank-mailman (input) for mailman id 1463792; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048M-Rj for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pP8-41Eh; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjL-00000001KpM-1nmm; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=nAVXITYKBWjP/mczkyb/Slf4KhG5mPyW4p/IRHHh7AM=; b=R1Kya5KSrFacKoY00DDWtzx7bW tAmkAY/EoompgfcR81/oNuur1sy93tUAFg1v9rtTX2ICqqCAZ/obLR+ZAcAb3L/YGwVUf8hzKUG2J rgHAJZq9Csw7I7IxpT4smNVAuHkk9kmTWW2i3ZJshS84nXrLoloW4t6W7bra2spvmbaI=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 15/45] x86/mm: let Xen's page-table walker operate on a given root Date: Wed, 28 Oct 2026 23:05:29 +0000 Message-ID: <20261028-asi-hvm-v5-15-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit map_pages_to_xen() and modify_xen_mappings() maintain Xen's own mappings, walking from idle_pg_table, whose Xen slots every other root page-table copies. A later patch introduces a second, sparse directmap hierarchy: page tables for the directmap virtual address range that some guest contexts use in place of idle_pg_table's. It needs the same maintenance at the same virtual addresses. Give virt_to_xen_l{3,2,1}e() the L4 to walk from, and move the bodies of map_pages_to_xen() and modify_xen_mappings() into map_pages_in() and modify_mappings_in(), which take the root as well. The public functions pass idle_pg_table. The EFI runtime-services page-tables mirror idle_pg_table's L4 entries only, so a newly allocated L3 is propagated to them only when the root is idle_pg_table. map_pages_in() and modify_mappings_in() free page-table pages through free_pagetable_in(), which takes the root too and for now only calls free_xen_pagetable(). TLB flushing is unaffected: flushes are by virtual address and go to every online CPU, which covers both hierarchies. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Free page-table pages through free_pagetable_in(), for now a plain wrapper, split out of "x86/mm: build and maintain a sparse view of the directmap". Changes in v4: - Message: name the second hierarchy as sparse; flushes reach every CPU (Roger). Changes in v3: - New in this version. --- xen/arch/x86/mm.c | 78 ++++++++++++++++++++++++++++++++++------------- 1 file changed, 56 insertions(+), 22 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 6e3b1c4c7d..4bfb690017 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5230,13 +5230,14 @@ static DEFINE_SPINLOCK(map_pgdir_lock); /* * For virt_to_xen_lXe() functions, they take a linear address and return a - * pointer to Xen's LX entry. Caller needs to unmap the pointer. + * pointer to Xen's LX entry in the page-table hierarchy rooted at @root + * (idle_pg_table for Xen's own mappings). Caller needs to unmap the pointer. */ -static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) +static l3_pgentry_t *virt_to_xen_l3e(l4_pgentry_t *root, unsigned long v) { l4_pgentry_t *pl4e; - pl4e = &idle_pg_table[l4_table_offset(v)]; + pl4e = &root[l4_table_offset(v)]; if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) ) { bool locking = system_state > SYS_STATE_boot; @@ -5252,7 +5253,8 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) l4_pgentry_t l4e = l4e_from_mfn(l3mfn, __PAGE_HYPERVISOR); l4e_write(pl4e, l4e); - efi_update_l4_pgtable(l4_table_offset(v), l4e); + if ( root == idle_pg_table ) + efi_update_l4_pgtable(l4_table_offset(v), l4e); l3mfn = INVALID_MFN; } if ( locking ) @@ -5263,11 +5265,11 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v) return map_l3t_from_l4e(*pl4e) + l3_table_offset(v); } -static l2_pgentry_t *virt_to_xen_l2e(unsigned long v) +static l2_pgentry_t *virt_to_xen_l2e(l4_pgentry_t *root, unsigned long v) { l3_pgentry_t *pl3e, l3e; - pl3e = virt_to_xen_l3e(v); + pl3e = virt_to_xen_l3e(root, v); if ( !pl3e ) return NULL; @@ -5301,11 +5303,11 @@ static l2_pgentry_t *virt_to_xen_l2e(unsigned long v) return map_l2t_from_l3e(l3e) + l2_table_offset(v); } -static l1_pgentry_t *virt_to_xen_l1e(unsigned long v) +static l1_pgentry_t *virt_to_xen_l1e(l4_pgentry_t *root, unsigned long v) { l2_pgentry_t *pl2e, l2e; - pl2e = virt_to_xen_l2e(v); + pl2e = virt_to_xen_l2e(root, v); if ( !pl2e ) return NULL; @@ -5381,7 +5383,7 @@ mfn_t xen_map_to_mfn(unsigned long va) bool locking = system_state > SYS_STATE_boot; unsigned int l2_offset = l2_table_offset(va); unsigned int l1_offset = l1_table_offset(va); - const l3_pgentry_t *pl3e = virt_to_xen_l3e(va); + const l3_pgentry_t *pl3e = virt_to_xen_l3e(idle_pg_table, va); const l2_pgentry_t *pl2e = NULL; const l1_pgentry_t *pl1e = NULL; struct page_info *l3page; @@ -5421,7 +5423,21 @@ mfn_t xen_map_to_mfn(unsigned long va) return ret; } -int map_pages_to_xen( +/* + * Free a page-table page that the hierarchy rooted at @root has stopped + * using. + */ +static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) +{ + free_xen_pagetable(mfn); +} + +/* + * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or + * another hierarchy sharing its virtual addresses. + */ +static int map_pages_in( + l4_pgentry_t *root, unsigned long virt, mfn_t mfn, unsigned long nr_mfns, @@ -5472,7 +5488,7 @@ int map_pages_to_xen( UNMAP_DOMAIN_PAGE(pl3e); UNMAP_DOMAIN_PAGE(pl2e); - pl3e = virt_to_xen_l3e(virt); + pl3e = virt_to_xen_l3e(root, virt); if ( !pl3e ) goto out; @@ -5525,10 +5541,10 @@ int map_pages_to_xen( ol2e = l2t[i]; if ( (l2e_get_flags(ol2e) & _PAGE_PRESENT) && !(l2e_get_flags(ol2e) & _PAGE_PSE) ) - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } unmap_domain_page(l2t); - free_xen_pagetable(l3e_get_mfn(ol3e)); + free_pagetable_in(root, l3e_get_mfn(ol3e)); } } @@ -5596,7 +5612,7 @@ int map_pages_to_xen( free_xen_pagetable(l2mfn); } - pl2e = virt_to_xen_l2e(virt); + pl2e = virt_to_xen_l2e(root, virt); if ( !pl2e ) goto out; @@ -5626,7 +5642,7 @@ int map_pages_to_xen( flush_flags(l1e_get_flags(l1t[i])); flush_area(virt, flush_flags); unmap_domain_page(l1t); - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } } @@ -5641,7 +5657,7 @@ int map_pages_to_xen( /* Normal page mapping. */ if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) { - pl1e = virt_to_xen_l1e(virt); + pl1e = virt_to_xen_l1e(root, virt); if ( pl1e == NULL ) goto out; } @@ -5758,7 +5774,7 @@ int map_pages_to_xen( flush_area(virt - PAGE_SIZE, FLUSH_TLB_GLOBAL | FLUSH_ORDER(PAGETABLE_ORDER)); - free_xen_pagetable(l2e_get_mfn(ol2e)); + free_pagetable_in(root, l2e_get_mfn(ol2e)); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -5805,7 +5821,7 @@ int map_pages_to_xen( flush_area(virt - PAGE_SIZE, FLUSH_TLB_GLOBAL | FLUSH_ORDER(2*PAGETABLE_ORDER)); - free_xen_pagetable(l3e_get_mfn(ol3e)); + free_pagetable_in(root, l3e_get_mfn(ol3e)); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -5826,6 +5842,15 @@ int map_pages_to_xen( return rc; } +int map_pages_to_xen( + unsigned long virt, + mfn_t mfn, + unsigned long nr_mfns, + pte_attr_t flags) +{ + return map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); +} + int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) { return map_pages_to_xen(virt, INVALID_MFN, nr_mfns, MAP_SMALL_PAGES); @@ -5842,8 +5867,12 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * flags are ignored. * * It is an error to call with present flags over an unpopulated range. + * + * modify_mappings_in() does so in the hierarchy rooted at @root, as + * map_pages_in() does. */ -int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) +static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, + unsigned long e, pte_attr_t nf) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -5870,7 +5899,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) UNMAP_DOMAIN_PAGE(pl2e); UNMAP_DOMAIN_PAGE(pl3e); - pl3e = virt_to_xen_l3e(v); + pl3e = virt_to_xen_l3e(root, v); if ( !pl3e ) goto out; @@ -6053,7 +6082,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) if ( locking ) spin_unlock(&map_pgdir_lock); flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ - free_xen_pagetable(l1mfn); + free_pagetable_in(root, l1mfn); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -6097,7 +6126,7 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) if ( locking ) spin_unlock(&map_pgdir_lock); flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */ - free_xen_pagetable(l2mfn); + free_pagetable_in(root, l2mfn); } else if ( locking ) spin_unlock(&map_pgdir_lock); @@ -6121,6 +6150,11 @@ int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) #undef flush_area +int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) +{ + return modify_mappings_in(idle_pg_table, s, e, nf); +} + int destroy_xen_mappings(unsigned long s, unsigned long e) { return modify_xen_mappings(s, e, _PAGE_NONE); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463793.1674623 (Exim 4.92) (envelope-from ) id 1xMD6S-0005aK-89; Wed, 28 Oct 2026 23:30:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463793.1674623; Wed, 28 Oct 2026 23:30: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 1xMD6R-0005XN-Mc; Wed, 28 Oct 2026 23:30:43 +0000 Received: by outflank-mailman (input) for mailman id 1463793; Wed, 28 Oct 2026 23:30:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048L-Rf for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOH-2wJV; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjY-00000001KpM-3nTo; Wed, 28 Oct 2026 23:07: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=t+EdWO6iPxPuCBCh+16xGZznZe+HtW0IST442JNVREo=; b=c0fLvReR1AH5nFP2zK2FrgR0Ts V3jgY+aheCvosumVcHs0RiwlOk+4H0bXluC6bKxWvFhHfsKWhgjn3pHP+XLtjvfkaiRIOMeKbk2B6 rVlUEJWZVLB0PfkxtnQEwBV30yGGX3VT/l0YR4TvN0xXt9RKX7O2z8bK3WXOQAbFuGk0=; From: George Dunlap 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 v5 27/45] x86/svm: introduce SVM_MAP_VMCB() and SVM_UNMAP_VMCB() Date: Wed, 28 Oct 2026 23:05:41 +0000 Message-ID: <20261028-asi-hvm-v5-27-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some accessors of a vCPU's VMCB can run with that vCPU paused, from another vCPU's context: context save/load, the segment and CPL getters, PAT/TSC/intercept updates reachable from toolstack operations, vm_event, the 'v' debug key, and construct_vmcb() itself, which runs before the vCPU ever entered guest context. svm_nested_features_on_efer_update() is among them: it is reachable remotely via hvm_load_cpu_ctxt() -> svm_update_guest_efer(). Route them through the new SVM_MAP_VMCB() and SVM_UNMAP_VMCB(); construct_vmcb() takes the VMCB from its caller. svm_set_tsc_offset() needs both VMCBs rather than just the active one, so it maps them individually via SVM_MAP_VMCB_ONE(). A vCPU stays in nested guest mode across a deschedule or a pause, so this path can run remotely with the L2 VMCB active; guest mode does not imply v == current. Hot vmexit-path accesses all have v == current and keep dereferencing svm->vmcb directly. SVM_MAP_VMCB(), SVM_MAP_VMCB_ONE() and SVM_UNMAP_VMCB() are macros over svm_vmcb_map(), svm_vmcb_map_one() and svm_vmcb_unmap(), so that SVM_UNMAP_VMCB() can clear the caller's pointer, as VCPU_UNMAP_XSAVE_AREA() does. No functional change: the helpers return the VMCB's existing address. They prepare for moving VMCBs off always-mapped memory, where a VMCB's mapping is valid only in its own vCPU's context. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- CC: Ross Lagerwall Changes in v5: - Map and unmap through SVM_MAP_VMCB(), SVM_MAP_VMCB_ONE() and SVM_UNMAP_VMCB(), which clears the pointer (George). - Retitle (was: "x86/svm: introduce svm_vmcb_map() and svm_vmcb_unmap()"). Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/nestedsvm.c | 4 +- xen/arch/x86/hvm/svm/svm.c | 133 +++++++++++++++++++++++-------- xen/arch/x86/hvm/svm/vmcb.c | 29 ++++++- xen/arch/x86/hvm/svm/vmcb.h | 18 +++++ 4 files changed, 145 insertions(+), 39 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 56d0f0fa4d..ff5d7df301 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1556,7 +1556,7 @@ 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 vmcb_struct *vmcb = SVM_MAP_VMCB(v); struct nestedsvm *svm = &vcpu_nestedsvm(v); u32 general2_intercepts; vintr_t vintr; @@ -1614,6 +1614,8 @@ void svm_nested_features_on_efer_update(struct vcpu *v) vmcb_set_general2_intercepts(vmcb, general2_intercepts); } } + + SVM_UNMAP_VMCB(v, vmcb); } void __init start_nested_svm(struct hvm_function_table *hvm_function_table) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 1628c5e0ae..b539406f0c 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -107,7 +107,7 @@ static void cf_check svm_cpu_down(void) static void cf_check svm_update_guest_cr( struct vcpu *v, unsigned int cr, unsigned int flags) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); uint64_t value; switch ( cr ) @@ -173,11 +173,13 @@ static void cf_check svm_update_guest_cr( default: BUG(); } + + SVM_UNMAP_VMCB(v, vmcb); } static void cf_check svm_update_guest_efer(struct vcpu *v) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); unsigned long guest_efer = v->arch.hvm.guest_efer, xen_efer = read_efer(); @@ -204,6 +206,7 @@ static void cf_check svm_update_guest_efer(struct vcpu *v) guest_efer |= EFER_SVME; vmcb_set_efer(vmcb, guest_efer); + SVM_UNMAP_VMCB(v, vmcb); ASSERT(nestedhvm_enabled(v->domain) || !nsvm_efer_svm_enabled(v)); @@ -352,7 +355,7 @@ static void svm_restore_dr(struct vcpu *v) static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); if ( vmcb->event_inj.v && hvm_event_needs_reinjection(vmcb->event_inj.type, @@ -362,13 +365,15 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c) c->error_code = vmcb->event_inj.ec; } + SVM_UNMAP_VMCB(v, vmcb); + return 1; } static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) { struct page_info *page = NULL; - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb; struct p2m_domain *p2m = p2m_get_hostp2m(v->domain); if ( c->pending_valid ) @@ -417,6 +422,8 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) svm_update_guest_cr(v, 0, 0); svm_update_guest_cr(v, 4, 0); + vmcb = SVM_MAP_VMCB(v); + if ( !paging_mode_shadow(v->domain) ) { vmcb_set_np(vmcb, true); @@ -436,6 +443,8 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) vmcb->event_inj.raw = 0; vmcb->cleanbits.raw = 0; + SVM_UNMAP_VMCB(v, vmcb); + paging_update_paging_modes(v); return 0; @@ -443,7 +452,7 @@ 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; + const struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); data->sysenter_cs = vmcb->sysenter_cs; data->sysenter_esp = vmcb->sysenter_esp; @@ -453,11 +462,13 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) data->msr_star = vmcb->star; data->msr_cstar = vmcb->cstar; data->msr_syscall_mask = vmcb->sfmask; + + SVM_UNMAP_VMCB(v, vmcb); } 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 *vmcb = SVM_MAP_VMCB(v); vmcb->lstar = data->msr_lstar; vmcb->star = data->msr_star; @@ -467,6 +478,9 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) vmcb->sysenter_cs = data->sysenter_cs; vmcb->sysenter_esp = data->sysenter_esp; vmcb->sysenter_eip = data->sysenter_eip; + + SVM_UNMAP_VMCB(v, vmcb); + v->arch.hvm.guest_efer = data->msr_efer; svm_update_guest_efer(v); } @@ -492,7 +506,7 @@ static int cf_check svm_load_vmcb_ctxt(struct vcpu *v, struct hvm_hw_cpu *ctxt) static unsigned cf_check int svm_get_interrupt_shadow(struct vcpu *v) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); unsigned int intr_shadow = 0; if ( vmcb->int_stat.intr_shadow ) @@ -503,13 +517,15 @@ static unsigned cf_check int svm_get_interrupt_shadow(struct vcpu *v) : (vmcb_get_general1_intercepts(vmcb) & GENERAL1_INTERCEPT_IRET) ) intr_shadow |= HVM_INTR_SHADOW_NMI; + SVM_UNMAP_VMCB(v, vmcb); + return intr_shadow; } static void cf_check svm_set_interrupt_shadow( struct vcpu *v, unsigned int intr_shadow) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); bool block_nmi = intr_shadow & HVM_INTR_SHADOW_NMI; vmcb->int_stat.intr_shadow = @@ -527,10 +543,13 @@ static void cf_check svm_set_interrupt_shadow( vmcb_set_general1_intercepts(vmcb, gen1); } + + SVM_UNMAP_VMCB(v, vmcb); } static int cf_check svm_guest_x86_mode(struct vcpu *v) { + /* Current only (see guest_cpu_user_regs() below): no mapping needed. */ struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; if ( unlikely(!(v->arch.hvm.guest_cr[0] & X86_CR0_PE)) ) @@ -544,8 +563,7 @@ static int cf_check svm_guest_x86_mode(struct vcpu *v) static void cf_check svm_cpuid_policy_changed(struct vcpu *v) { - struct svm_vcpu *svm = &v->arch.hvm.svm; - struct vmcb_struct *vmcb = svm->vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); const struct cpu_policy *cp = v->domain->arch.cpu_policy; u32 bitmap = vmcb_get_exception_intercepts(vmcb); @@ -555,6 +573,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v) bitmap &= ~(1U << X86_EXC_UD); vmcb_set_exception_intercepts(vmcb, bitmap); + SVM_UNMAP_VMCB(v, vmcb); /* Give access to MSR_SPEC_CTRL if the guest has been told about it. */ svm_intercept_msr(v, MSR_SPEC_CTRL, @@ -598,13 +617,18 @@ void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) static unsigned int cf_check svm_get_cpl(struct vcpu *v) { - return vmcb_get_cpl(v->arch.hvm.svm.vmcb); + const struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); + unsigned int cpl = vmcb_get_cpl(vmcb); + + SVM_UNMAP_VMCB(v, vmcb); + + return cpl; } 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 *vmcb = SVM_MAP_VMCB(v); ASSERT((v == current) || !vcpu_runnable(v)); @@ -645,12 +669,14 @@ static void cf_check svm_get_segment_register( *reg = (struct segment_register){}; break; } + + SVM_UNMAP_VMCB(v, vmcb); } 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 *vmcb = SVM_MAP_VMCB(v); ASSERT((v == current) || !vcpu_runnable(v)); @@ -679,6 +705,7 @@ static void cf_check svm_set_segment_register( default: ASSERT_UNREACHABLE(); domain_crash(v->domain); + SVM_UNMAP_VMCB(v, vmcb); return; } @@ -716,33 +743,41 @@ static void cf_check svm_set_segment_register( ASSERT_UNREACHABLE(); break; } + + SVM_UNMAP_VMCB(v, vmcb); } static int cf_check svm_set_guest_pat(struct vcpu *v, u64 gpat) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb; if ( paging_mode_shadow(v->domain) ) return 0; + vmcb = SVM_MAP_VMCB(v); vmcb_set_g_pat(vmcb, gpat); + SVM_UNMAP_VMCB(v, vmcb); + return 1; } static int cf_check svm_get_guest_pat(struct vcpu *v, u64 *gpat) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + const struct vmcb_struct *vmcb; if ( paging_mode_shadow(v->domain) ) return 0; + vmcb = SVM_MAP_VMCB(v); *gpat = vmcb_get_g_pat(vmcb); + SVM_UNMAP_VMCB(v, vmcb); + return 1; } static void cf_check svm_set_tsc_offset(struct vcpu *v, uint64_t offset) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); struct vmcb_struct *n1vmcb, *n2vmcb; uint64_t n2_tsc_offset = 0; struct domain *d = v->domain; @@ -750,25 +785,36 @@ static void cf_check svm_set_tsc_offset(struct vcpu *v, uint64_t offset) if ( !nestedhvm_enabled(d) ) { vmcb_set_tsc_offset(vmcb, offset); + SVM_UNMAP_VMCB(v, vmcb); return; } - n1vmcb = vcpu_nestedhvm(v).nv_n1vmcx; - n2vmcb = vcpu_nestedhvm(v).nv_n2vmcx; - + /* + * A vCPU stays in nested guest mode across a deschedule or a pause, so + * this can run remotely with the L2 VMCB active: map both explicitly. + */ if ( nestedhvm_vcpu_in_guestmode(v) ) { + const struct nestedvcpu *nv = &vcpu_nestedhvm(v); + + n1vmcb = SVM_MAP_VMCB_ONE(v, nv->nv_n1vmcx, nv->nv_n1vmcx_pa); + n2vmcb = SVM_MAP_VMCB_ONE(v, nv->nv_n2vmcx, nv->nv_n2vmcx_pa); + n2_tsc_offset = vmcb_get_tsc_offset(n2vmcb) - vmcb_get_tsc_offset(n1vmcb); vmcb_set_tsc_offset(n1vmcb, offset); + + SVM_UNMAP_VMCB(v, n2vmcb); + SVM_UNMAP_VMCB(v, n1vmcb); } vmcb_set_tsc_offset(vmcb, offset + n2_tsc_offset); + SVM_UNMAP_VMCB(v, vmcb); } static void cf_check svm_set_rdtsc_exiting(struct vcpu *v, bool enable) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb); u32 general2_intercepts = vmcb_get_general2_intercepts(vmcb); @@ -783,13 +829,14 @@ static void cf_check svm_set_rdtsc_exiting(struct vcpu *v, bool enable) vmcb_set_general1_intercepts(vmcb, general1_intercepts); vmcb_set_general2_intercepts(vmcb, general2_intercepts); + SVM_UNMAP_VMCB(v, vmcb); } #ifdef CONFIG_VM_EVENT static void cf_check svm_set_descriptor_access_exiting( struct vcpu *v, bool enable) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb); u32 mask = GENERAL1_INTERCEPT_IDTR_READ | GENERAL1_INTERCEPT_GDTR_READ | GENERAL1_INTERCEPT_LDTR_READ | GENERAL1_INTERCEPT_TR_READ @@ -802,6 +849,7 @@ static void cf_check svm_set_descriptor_access_exiting( general1_intercepts &= ~mask; vmcb_set_general1_intercepts(vmcb, general1_intercepts); + SVM_UNMAP_VMCB(v, vmcb); } #endif /* CONFIG_VM_EVENT */ @@ -1360,7 +1408,12 @@ static void cf_check svm_inject_event(const struct x86_event *event) static bool cf_check svm_event_pending(const struct vcpu *v) { - return v->arch.hvm.svm.vmcb->event_inj.v; + const struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); + bool pending = vmcb->event_inj.v; + + SVM_UNMAP_VMCB(v, vmcb); + + return pending; } static void cf_check svm_cpu_dead(unsigned int cpu) @@ -2318,45 +2371,55 @@ static void cf_check svm_invlpg(struct vcpu *v, unsigned long linear) static bool cf_check svm_get_pending_event( struct vcpu *v, struct x86_event *info) { - const struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + const struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); + bool pending = vmcb->event_inj.v; - if ( !vmcb->event_inj.v ) - return false; + if ( pending ) + { + info->vector = vmcb->event_inj.vector; + info->type = vmcb->event_inj.type; + info->error_code = vmcb->event_inj.ec; + } - info->vector = vmcb->event_inj.vector; - info->type = vmcb->event_inj.type; - info->error_code = vmcb->event_inj.ec; + SVM_UNMAP_VMCB(v, vmcb); - return true; + return pending; } static uint64_t cf_check svm_get_reg(struct vcpu *v, unsigned int reg) { struct vcpu *curr = current; - const struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + const struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); struct domain *d = v->domain; + uint64_t val = 0; switch ( reg ) { case MSR_SPEC_CTRL: - return vmcb->spec_ctrl; + val = vmcb->spec_ctrl; + break; case MSR_SHADOW_GS_BASE: if ( v == curr ) svm_sync_vmcb(v, vmcb_in_sync); - return vmcb->kerngsbase; + val = vmcb->kerngsbase; + break; default: printk(XENLOG_G_ERR "%s(%pv, 0x%08x) Bad register\n", __func__, v, reg); domain_crash(d); - return 0; + break; } + + SVM_UNMAP_VMCB(v, vmcb); + + return val; } static void cf_check svm_set_reg(struct vcpu *v, unsigned int reg, uint64_t val) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *vmcb = SVM_MAP_VMCB(v); struct domain *d = v->domain; switch ( reg ) @@ -2371,6 +2434,8 @@ static void cf_check svm_set_reg(struct vcpu *v, unsigned int reg, uint64_t val) domain_crash(d); break; } + + SVM_UNMAP_VMCB(v, vmcb); } static struct hvm_function_table __initdata_cf_clobber svm_function_table = { diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index a6f09672a7..5e193be9cd 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -43,11 +43,25 @@ void free_vmcb(struct vmcb_struct *vmcb) free_xenheap_page(vmcb); } +struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, + struct vmcb_struct *va, paddr_t pa) +{ + return va; +} + +struct vmcb_struct *svm_vmcb_map(const struct vcpu *v) +{ + return svm_vmcb_map_one(v, v->arch.hvm.svm.vmcb, v->arch.hvm.svm.vmcb_pa); +} + +void svm_vmcb_unmap(const struct vcpu *v, const struct vmcb_struct *vmcb) +{ +} + /* This function can directly access fields which are covered by clean bits. */ -static int construct_vmcb(struct vcpu *v) +static int construct_vmcb(struct vcpu *v, struct vmcb_struct *vmcb) { struct svm_vcpu *svm = &v->arch.hvm.svm; - struct vmcb_struct *vmcb = svm->vmcb; vmcb->_general1_intercepts = GENERAL1_INTERCEPT_INTR | GENERAL1_INTERCEPT_NMI | @@ -201,6 +215,7 @@ int svm_create_vmcb(struct vcpu *v) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct svm_vcpu *svm = &v->arch.hvm.svm; + struct vmcb_struct *vmcb; int rc; if ( (nv->nv_n1vmcx == NULL) && @@ -211,7 +226,10 @@ int svm_create_vmcb(struct vcpu *v) } svm->vmcb = nv->nv_n1vmcx; - rc = construct_vmcb(v); + + vmcb = SVM_MAP_VMCB(v); + rc = construct_vmcb(v, vmcb); + SVM_UNMAP_VMCB(v, vmcb); if ( rc != 0 ) { free_vmcb(nv->nv_n1vmcx); @@ -407,6 +425,7 @@ static void cf_check vmcb_dump(unsigned char ch) { struct domain *d; struct vcpu *v; + struct vmcb_struct *vmcb; printk("*********** VMCB Areas **************\n"); @@ -425,7 +444,9 @@ 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); + vmcb = SVM_MAP_VMCB(v); + svm_vmcb_dump("key_handler", vmcb); + SVM_UNMAP_VMCB(v, vmcb); process_pending_softirqs(); } diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 28dae325ce..d49c910d46 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -559,6 +559,24 @@ struct vmcb_struct { struct vmcb_struct *alloc_vmcb(void); void free_vmcb(struct vmcb_struct *vmcb); +/* + * Access a VMCB of a vCPU that may not be current. SVM_MAP_VMCB() takes + * the active VMCB, SVM_MAP_VMCB_ONE() a specific one. + */ +struct vmcb_struct *svm_vmcb_map_one(const struct vcpu *v, + struct vmcb_struct *va, paddr_t pa); +struct vmcb_struct *svm_vmcb_map(const struct vcpu *v); +void svm_vmcb_unmap(const struct vcpu *v, const struct vmcb_struct *vmcb); + +#define SVM_MAP_VMCB(v) svm_vmcb_map(v) +#define SVM_MAP_VMCB_ONE(v, va, pa) svm_vmcb_map_one(v, va, pa) + +/* Drops the mapping of a VMCB and nullifies its pointer. */ +#define SVM_UNMAP_VMCB(v, vmcb) do { \ + svm_vmcb_unmap(v, vmcb); \ + (vmcb) = NULL; \ +} while ( false ) + int svm_create_vmcb(struct vcpu *v); void svm_destroy_vmcb(struct vcpu *v); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463795.1674632 (Exim 4.92) (envelope-from ) id 1xMD6T-0005u9-1Y; Wed, 28 Oct 2026 23:30:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463795.1674632; Wed, 28 Oct 2026 23:30: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 1xMD6S-0005rq-Jp; Wed, 28 Oct 2026 23:30:44 +0000 Received: by outflank-mailman (input) for mailman id 1463795; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048q-VT for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pPi-0K1I; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjk-00000001KpM-0LHD; Wed, 28 Oct 2026 23:07: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=tI8rWUCKpztUW6i1B6fFTfydag4KVKVQaRj7AWM+f08=; b=nb0aCLFuk9b0R9BU+VzVuq1vZz vQxTWvEvEzAlTsV8rxb+tZZLxd+cF4WaZvTxChtyx47Uwf6ySmRqC8Ntu6AlwYb6ceYnlp3bRVkk9 OMSiS51GzPoL0WsdmVhsnEHIQljPu0AnBxZ66vmQwe7zax8QL5Ljx1iGJ0z1ccparer8=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 38/45] x86/hvm: use map_domain_pages() for multi-frame emulated accesses Date: Wed, 28 Oct 2026 23:05:52 +0000 Message-ID: <20261028-asi-hvm-v5-38-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit hvmemul_map_linear_addr() picks its mapping method purely on the frame count: one frame goes through map_domain_page(), more through vmap() -- mapping the guest data in every context for the duration, those of domains on the sparse directmap view included, whatever the guest's own configuration. map_domain_pages() maps them only in the page tables of the guest's own domain; use it for the multi-frame case. The NULL return handling is unchanged: the primitive can fail only for want of a free slot, and the access then bails out as unhandleable exactly as before. This is one of the two in-tree consumers of the primitive. Other long-lived global mappings of guest pages (the ioreq server pages among them) remain in the vmap area. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/arch/x86/hvm/emulate.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index da7c08b5d9..7e7beccb93 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -735,7 +735,8 @@ static void *hvmemul_map_linear_addr( /* * The maximum access size depends on the number of adjacent mfns[] which - * can be vmap()'d, accouting for possible misalignment within the region. + * can be mapped together, accounting for possible misalignment within + * the region. * The higher level emulation callers are responsible for ensuring that * mfns[] is large enough for the requested access size. */ @@ -824,9 +825,9 @@ static void *hvmemul_map_linear_addr( /* Entire access within a single frame? */ if ( nr_frames == 1 ) mapping = map_domain_page(hvmemul_ctxt->mfn[0]); - /* Multiple frames? Need to vmap(). */ - else if ( (mapping = vmap(hvmemul_ctxt->mfn, - nr_frames)) == NULL ) + /* Multiple frames? Need a multi-page mapping. */ + else if ( (mapping = map_domain_pages(hvmemul_ctxt->mfn, + nr_frames)) == NULL ) goto unhandleable; #ifndef NDEBUG /* Poision unused mfn[]s with INVALID_MFN. */ @@ -867,7 +868,7 @@ static void hvmemul_unmap_linear_addr( if ( nr_frames == 1 ) unmap_domain_page(mapping); else - vunmap(mapping); + unmap_domain_pages(mapping, nr_frames); for ( i = 0; i < nr_frames; i++ ) { -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463794.1674641 (Exim 4.92) (envelope-from ) id 1xMD6T-00067X-S9; Wed, 28 Oct 2026 23:30:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463794.1674641; Wed, 28 Oct 2026 23: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 1xMD6T-00062B-8w; Wed, 28 Oct 2026 23:30:45 +0000 Received: by outflank-mailman (input) for mailman id 1463794; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048e-TQ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOL-3Fm0; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjj-00000001KpM-0l8o; Wed, 28 Oct 2026 23:07: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=nCu/9nxrMBPoeFP8cJd8ihmMLFkJzdeaGH0E1Itmh5E=; b=O2Q3282EztO4L2CnaV6spNMaBP WK9w3R5TXea6P47EnChPL0SWcCvAWIgHbE411pIA+2T8/9PiLTQNehBh/RGa7AtHDe6CfhcLApza/ LLUpMHWtm7lPCWuA4722lzHL9z37tqmDPNhDLrPxGLh9XGFZhxHbvM87oP+TPjZmbR3Y=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , Tim Deegan , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 37/45] x86/shadow: use map_domain_pages() for cross-page emulated writes Date: Wed, 28 Oct 2026 23:05:51 +0000 Message-ID: <20261028-asi-hvm-v5-37-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit sh_emulate_map_dest() picks its mapping method purely on whether the write straddles a page boundary: a single page goes through map_domain_page(), two pages through vmap() -- mapping the destination in every context for the duration, those of domains on the sparse directmap view included, whatever the guest's own configuration. map_domain_pages() maps it only in the page tables of the guest's own domain; use it for the two-page case. The NULL return handling is unchanged: the primitive can fail only for want of a free slot, and the emulation then bails out as unhandleable exactly as before. This is one of the two in-tree consumers of the primitive. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/arch/x86/mm/shadow/hvm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c index 0b23326214..b1c3d5e637 100644 --- a/xen/arch/x86/mm/shadow/hvm.c +++ b/xen/arch/x86/mm/shadow/hvm.c @@ -506,7 +506,7 @@ static void *sh_emulate_map_dest(struct vcpu *v, unsigned long vaddr, /* Cross-page writes mean probably not a pagetable. */ sh_remove_shadows(d, sh_ctxt->mfn[1], 0, 0 /* Slow, can fail. */ ); - map = vmap(sh_ctxt->mfn, 2); + map = map_domain_pages(sh_ctxt->mfn, 2); if ( !map ) { put_page(mfn_to_page(sh_ctxt->mfn[0])); @@ -670,7 +670,7 @@ static void sh_emulate_unmap_dest(struct vcpu *v, void *addr, if ( unlikely(mfn_valid(sh_ctxt->mfn[1])) ) { put_page(mfn_to_page(sh_ctxt->mfn[1])); - vunmap((void *)((unsigned long)addr & PAGE_MASK)); + unmap_domain_pages(addr, 2); } else unmap_domain_page(addr); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463800.1674646 (Exim 4.92) (envelope-from ) id 1xMD6U-0006HG-Kd; Wed, 28 Oct 2026 23:30:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463800.1674646; Wed, 28 Oct 2026 23:30: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 1xMD6T-0006En-Vk; Wed, 28 Oct 2026 23:30:45 +0000 Received: by outflank-mailman (input) for mailman id 1463800; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049I-4t for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pQN-15gm; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjl-00000001KpM-0PPR; Wed, 28 Oct 2026 23:07: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=FlX8i68BurZZbddP5JFg/suxuQm3LKHJ87QfUKq0fho=; b=yM+K2gDhBTn33JbARZDS88dTNx /5uNKqrJ5BPkZtu6t+I8TYTpKDkJaCPVrU9PC7xKEb9T7e3rJ+n/GozNMw7juvP6RtjJU8LCWlK3e teSax+YVOY2/wI3pK7he0+Ea2otncKOX0Rhdrt48l8HF/1QqU3iijr1Wdotkq1BrmI3Y=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 39/45] x86/emulator: Refactor FXSAVE_AREA to use wrappers Date: Wed, 28 Oct 2026 23:05:53 +0000 Message-ID: <20261028-asi-hvm-v5-39-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Alejandro Vallejo The FXSAVE/FXRSTOR emulation scratch buffer is the calling vCPU's own XSAVE area, reached today through a raw pointer dereference. Route it through the VCPU_MAP_XSAVE_AREA()/VCPU_UNMAP_XSAVE_AREA() seam instead, so the buffer keeps working when guest XSAVE areas move behind per-vCPU mappings. This path always operates on `current`, for which the map has a fastpath; the unmap is a no-op outside Xen builds. The macro pair is named MAP_FXSAVE_AREA()/UNMAP_FXSAVE_AREA() rather than keeping the bare FXSAVE_AREA name, so that the mapping operation is visible at the use sites. blk_fxsave() saves directly into the caller's buffer when it is large enough, so it needs a second variable: the save destination and the mapped area are not the same pointer, and only the latter may be handed to the unmap. Signed-off-by: Alejandro Vallejo Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Revived from "x86: Address Space Isolation FPU preparations" v3 patch 08/12 (<20250110132823.24348-9-alejandro.vallejo@cloud.com>, Acked-by Jan Beulich modulo the rename below; no v4 was ever posted). Changes in v5: - New in this version. Changes since the previously posted version: - Renamed FXSAVE_AREA to MAP_FXSAVE_AREA(), as requested by Jan Beulich on the original thread ("the existing macro better would be adjusted to become MAP_FXSAVE_AREA()"), making the map operation visible at the use sites. - Introduced the separate save-destination variable in blk_fxsave(). The original unmapped `fxsr` after that variable had been repointed at the caller's buffer, so the unmap received a pointer that was never mapped. Harmless while the unmap was a stub, but a latent bug, and exactly the class of mistake Jan predicted in the message quoted above when he objected to the mapping being invisible at the use sites. - Reworded the commit message. - Unmap before raising #GP for a reserved MXCSR bit in blk_fxrstor: generate_exception_if() leaves through the done: label, past the unmap. --- xen/arch/x86/x86_emulate/blk.c | 36 +++++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/x86_emulate/blk.c b/xen/arch/x86/x86_emulate/blk.c index 9fddf649ee..b3055c8084 100644 --- a/xen/arch/x86/x86_emulate/blk.c +++ b/xen/arch/x86/x86_emulate/blk.c @@ -11,9 +11,12 @@ !defined(X86EMUL_NO_SIMD) # ifdef __XEN__ # include -# define FXSAVE_AREA ((void *)¤t->arch.xsave_area->fpu_sse) +/* Has a fastpath for `current`, so there's no actual map */ +# define MAP_FXSAVE_AREA() ((void *)VCPU_MAP_XSAVE_AREA(current)) +# define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(current, x) # else -# define FXSAVE_AREA get_fpu_save_area() +# define MAP_FXSAVE_AREA() get_fpu_save_area() +# define UNMAP_FXSAVE_AREA(x) ((void)(x)) # endif #endif @@ -254,7 +257,7 @@ int x86_emul_blk( case blk_fxrstor: { - struct x86_fxsr *fxsr = FXSAVE_AREA; + struct x86_fxsr *fxsr = MAP_FXSAVE_AREA(); ASSERT(!data); ASSERT(bytes == sizeof(*fxsr)); @@ -277,18 +280,26 @@ int x86_emul_blk( (unsigned int)offsetof(struct x86_fxsr, rsvd))); memset(fxsr->rsvd, 0, sizeof(*fxsr) - offsetof(struct x86_fxsr, rsvd)); - generate_exception_if(fxsr->mxcsr & ~mxcsr_mask, X86_EXC_GP, 0); + if ( fxsr->mxcsr & ~mxcsr_mask ) + { + UNMAP_FXSAVE_AREA(fxsr); + generate_exception(X86_EXC_GP, 0); + } if ( s->rex_prefix & REX_W ) asm volatile ( "fxrstorq %0" :: "m" (*fxsr) ); else asm volatile ( "fxrstor %0" :: "m" (*fxsr) ); + + UNMAP_FXSAVE_AREA(fxsr); + break; } case blk_fxsave: { - struct x86_fxsr *fxsr = FXSAVE_AREA; + struct x86_fxsr *fxsr = MAP_FXSAVE_AREA(); + struct x86_fxsr *dst = fxsr; ASSERT(!data); ASSERT(bytes == sizeof(*fxsr)); @@ -296,17 +307,20 @@ int x86_emul_blk( if ( s->op_bytes < sizeof(*fxsr) ) /* Don't chance consuming uninitialized data. */ - memset(fxsr, 0, s->op_bytes); + memset(dst, 0, s->op_bytes); else - fxsr = ptr; + dst = ptr; if ( s->rex_prefix & REX_W ) - asm volatile ( "fxsaveq %0" : "=m" (*fxsr) ); + asm volatile ( "fxsaveq %0" : "=m" (*dst) ); else - asm volatile ( "fxsave %0" : "=m" (*fxsr) ); + asm volatile ( "fxsave %0" : "=m" (*dst) ); + + if ( dst != ptr ) /* i.e. s->op_bytes < sizeof(*fxsr) */ + memcpy(ptr, dst, s->op_bytes); + + UNMAP_FXSAVE_AREA(fxsr); - if ( fxsr != ptr ) /* i.e. s->op_bytes < sizeof(*fxsr) */ - memcpy(ptr, fxsr, s->op_bytes); break; } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463796.1674655 (Exim 4.92) (envelope-from ) id 1xMD6V-0006Ou-Ag; Wed, 28 Oct 2026 23:30:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463796.1674655; Wed, 28 Oct 2026 23:30: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 1xMD6U-0006KG-Dd; Wed, 28 Oct 2026 23:30:46 +0000 Received: by outflank-mailman (input) for mailman id 1463796; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048l-Uu for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pON-3OG0; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCje-00000001KpM-0JnX; Wed, 28 Oct 2026 23:07: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=QAz/r9LvmMiTrUWKKl2WQZxhTMBDbu1jYHL9VdcYAAk=; b=I/Z6kOyo01mwG28LYiJbtqWD1w 4/iRPmJw4OZ1+AAZvkwF7jFqoBfveT+Cy5Vh4N0yh6e4o+Nr+/5P8hb4ijMIZ5TXF+xN71j4g8szp UxUF0vBP93ofvFCYsU8vtxE2awA2YM5N5sfMuw90djDyOF6Xk2SLbGHj0YQ1nhzwTdOM=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 32/45] x86: access a vCPU's saved register frame through map/unmap helpers Date: Wed, 28 Oct 2026 23:05:46 +0000 Message-ID: <20261028-asi-hvm-v5-32-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When a vCPU is switched out, __context_switch() copies its register frame from the stack into struct vcpu, and back when the vCPU is switched in. Code working on a vCPU other than the one running uses that copy: vCPU creation, XEN_DOMCTL_{get,set}vcpucontext, saving and loading the HVM CPU record, VCPUOP_initialise, INIT/SIPI and S3 resets, the result of a hypercall continued on another CPU, PV dom0 construction, and the debug-key dumps. Under Address Space Isolation the frame is to move out of struct vcpu, which is mapped in every context, into memory which other domains' contexts do not map. Its users then need a transient mapping whenever they run in another context. Prepare for that: introduce VCPU_MAP_REGS() and VCPU_UNMAP_REGS(), after VCPU_MAP_XSAVE_AREA(), and convert every user but the context switch, which moves the frame between the stack and its storage. The field becomes _user_regs, so that an access bypassing the helpers fails to build: once the frame can live elsewhere, such an access would silently use a stale copy. vcpu_show_registers() now prints from a copy of the frame for PV vCPUs as well as HVM ones, so that it holds no mapping while printing, and vmx_set_info_guest() reads EFLAGS.TF before engaging the VMCS. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/arch/x86/domain.c | 94 ++++++++++++++++++------------- xen/arch/x86/domctl.c | 72 ++++++++++++----------- xen/arch/x86/hvm/domain.c | 6 +- xen/arch/x86/hvm/hvm.c | 89 ++++++++++++++++------------- xen/arch/x86/hvm/vmx/vmcs.c | 9 +-- xen/arch/x86/hvm/vmx/vmx.c | 7 ++- xen/arch/x86/hypercall.c | 4 +- xen/arch/x86/include/asm/domain.h | 28 ++++++++- xen/arch/x86/pv/dom0_build.c | 3 +- xen/arch/x86/traps.c | 20 ++++--- 10 files changed, 204 insertions(+), 128 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 3465124ea0..6911f8484c 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -496,8 +496,12 @@ unsigned int arch_domain_struct_memflags(void) /* Initialise various registers to their architectural INIT/RESET state. */ void arch_vcpu_regs_init(struct vcpu *v) { - memset(&v->arch.user_regs, 0, sizeof(v->arch.user_regs)); - v->arch.user_regs.eflags = X86_EFLAGS_MBS; + struct cpu_user_regs *regs = VCPU_MAP_REGS(v); + + memset(regs, 0, sizeof(*regs)); + regs->eflags = X86_EFLAGS_MBS; + + VCPU_UNMAP_REGS(v, regs); memset(v->arch.dr, 0, sizeof(v->arch.dr)); v->arch.dr6 = X86_DR6_DEFAULT; @@ -1146,6 +1150,7 @@ int arch_set_info_guest( { struct domain *d = v->domain; const struct cpu_policy *p = d->arch.cpu_policy; + struct cpu_user_regs *regs; unsigned int i; unsigned long flags; bool compat; @@ -1273,30 +1278,32 @@ int arch_set_info_guest( else vcpu_reset_fpu(v); - memset(&v->arch.user_regs, 0, sizeof(v->arch.user_regs)); + regs = VCPU_MAP_REGS(v); + memset(regs, 0, sizeof(*regs)); if ( !compat ) { - v->arch.user_regs.r15 = c.nat->user_regs.r15; - v->arch.user_regs.r14 = c.nat->user_regs.r14; - v->arch.user_regs.r13 = c.nat->user_regs.r13; - v->arch.user_regs.r12 = c.nat->user_regs.r12; - v->arch.user_regs.rbp = c.nat->user_regs.rbp; - v->arch.user_regs.rbx = c.nat->user_regs.rbx; - v->arch.user_regs.r11 = c.nat->user_regs.r11; - v->arch.user_regs.r10 = c.nat->user_regs.r10; - v->arch.user_regs.r9 = c.nat->user_regs.r9; - v->arch.user_regs.r8 = c.nat->user_regs.r8; - v->arch.user_regs.rax = c.nat->user_regs.rax; - v->arch.user_regs.rcx = c.nat->user_regs.rcx; - v->arch.user_regs.rdx = c.nat->user_regs.rdx; - v->arch.user_regs.rsi = c.nat->user_regs.rsi; - v->arch.user_regs.rdi = c.nat->user_regs.rdi; - v->arch.user_regs.rip = c.nat->user_regs.rip; - v->arch.user_regs.cs = c.nat->user_regs.cs; - v->arch.user_regs.rflags = (c.nat->user_regs.rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; - v->arch.user_regs.rsp = c.nat->user_regs.rsp; - v->arch.user_regs.ss = c.nat->user_regs.ss; + regs->r15 = c.nat->user_regs.r15; + regs->r14 = c.nat->user_regs.r14; + regs->r13 = c.nat->user_regs.r13; + regs->r12 = c.nat->user_regs.r12; + regs->rbp = c.nat->user_regs.rbp; + regs->rbx = c.nat->user_regs.rbx; + regs->r11 = c.nat->user_regs.r11; + regs->r10 = c.nat->user_regs.r10; + regs->r9 = c.nat->user_regs.r9; + regs->r8 = c.nat->user_regs.r8; + regs->rax = c.nat->user_regs.rax; + regs->rcx = c.nat->user_regs.rcx; + regs->rdx = c.nat->user_regs.rdx; + regs->rsi = c.nat->user_regs.rsi; + regs->rdi = c.nat->user_regs.rdi; + regs->rip = c.nat->user_regs.rip; + regs->cs = c.nat->user_regs.cs; + regs->rflags = + (c.nat->user_regs.rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; + regs->rsp = c.nat->user_regs.rsp; + regs->ss = c.nat->user_regs.ss; v->arch.pv.es = c.nat->user_regs.es; v->arch.pv.ds = c.nat->user_regs.ds; v->arch.pv.fs = c.nat->user_regs.fs; @@ -1309,18 +1316,19 @@ int arch_set_info_guest( #ifdef CONFIG_COMPAT else { - v->arch.user_regs.ebx = c.cmp->user_regs.ebx; - v->arch.user_regs.ecx = c.cmp->user_regs.ecx; - v->arch.user_regs.edx = c.cmp->user_regs.edx; - v->arch.user_regs.esi = c.cmp->user_regs.esi; - v->arch.user_regs.edi = c.cmp->user_regs.edi; - v->arch.user_regs.ebp = c.cmp->user_regs.ebp; - v->arch.user_regs.eax = c.cmp->user_regs.eax; - v->arch.user_regs.eip = c.cmp->user_regs.eip; - v->arch.user_regs.cs = c.cmp->user_regs.cs; - v->arch.user_regs.eflags = (c.cmp->user_regs.eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; - v->arch.user_regs.esp = c.cmp->user_regs.esp; - v->arch.user_regs.ss = c.cmp->user_regs.ss; + regs->ebx = c.cmp->user_regs.ebx; + regs->ecx = c.cmp->user_regs.ecx; + regs->edx = c.cmp->user_regs.edx; + regs->esi = c.cmp->user_regs.esi; + regs->edi = c.cmp->user_regs.edi; + regs->ebp = c.cmp->user_regs.ebp; + regs->eax = c.cmp->user_regs.eax; + regs->eip = c.cmp->user_regs.eip; + regs->cs = c.cmp->user_regs.cs; + regs->eflags = + (c.cmp->user_regs.eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; + regs->esp = c.cmp->user_regs.esp; + regs->ss = c.cmp->user_regs.ss; v->arch.pv.es = c.cmp->user_regs.es; v->arch.pv.ds = c.cmp->user_regs.ds; v->arch.pv.fs = c.cmp->user_regs.fs; @@ -1335,6 +1343,8 @@ int arch_set_info_guest( } #endif + VCPU_UNMAP_REGS(v, regs); + if ( v->vcpu_id == 0 && (c(vm_assist) & ~arch_vm_assist_valid_mask(d)) ) return -EINVAL; @@ -1353,12 +1363,16 @@ int arch_set_info_guest( } #ifdef CONFIG_PV + regs = VCPU_MAP_REGS(v); + /* IOPL privileges are virtualised. */ - v->arch.pv.iopl = v->arch.user_regs.eflags & X86_EFLAGS_IOPL; - v->arch.user_regs.eflags &= ~X86_EFLAGS_IOPL; + v->arch.pv.iopl = regs->eflags & X86_EFLAGS_IOPL; + regs->eflags &= ~X86_EFLAGS_IOPL; /* Ensure real hardware interrupts are enabled. */ - v->arch.user_regs.eflags |= X86_EFLAGS_IF; + regs->eflags |= X86_EFLAGS_IF; + + VCPU_UNMAP_REGS(v, regs); nr_gdt_frames = DIV_ROUND_UP(c(gdt_ents), 512); if ( nr_gdt_frames > ARRAY_SIZE(v->arch.pv.gdt_frames) ) @@ -2129,7 +2143,7 @@ static void __context_switch(void) if ( !is_idle_domain(pd) ) { ASSERT(read_atomic(&p->dirty_cpu) == cpu); - memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES); + memcpy(&p->arch._user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES); vcpu_save_fpu(p); pd->arch.ctxt_switch->from(p); } @@ -2145,7 +2159,7 @@ static void __context_switch(void) if ( !is_idle_domain(nd) ) { - memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES); + memcpy(stack_regs, &n->arch._user_regs, CTXT_SWITCH_STACK_BYTES); if ( cpu_has_xsave ) { if ( !set_xcr0(n->arch.xcr0 ?: XSTATE_FP_SSE) ) diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 51d62617bb..b7ea1e1801 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -1461,6 +1461,7 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c) const struct domain *d = v->domain; bool compat = is_pv_32bit_domain(d); const struct xsave_struct *xsave_area; + const struct cpu_user_regs *regs; #ifdef CONFIG_COMPAT #define c(fld) (!compat ? (c.nat->fld) : (c.cmp->fld)) #else @@ -1479,29 +1480,32 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c) c(flags |= VGCF_i387_valid); if ( !(v->pause_flags & VPF_down) ) c(flags |= VGCF_online); + + regs = VCPU_MAP_REGS(v); + if ( !compat ) { /* Backing memory is pre-zeroed. */ - c.nat->user_regs.r15 = v->arch.user_regs.r15; - c.nat->user_regs.r14 = v->arch.user_regs.r14; - c.nat->user_regs.r13 = v->arch.user_regs.r13; - c.nat->user_regs.r12 = v->arch.user_regs.r12; - c.nat->user_regs.rbp = v->arch.user_regs.rbp; - c.nat->user_regs.rbx = v->arch.user_regs.rbx; - c.nat->user_regs.r11 = v->arch.user_regs.r11; - c.nat->user_regs.r10 = v->arch.user_regs.r10; - c.nat->user_regs.r9 = v->arch.user_regs.r9; - c.nat->user_regs.r8 = v->arch.user_regs.r8; - c.nat->user_regs.rax = v->arch.user_regs.rax; - c.nat->user_regs.rcx = v->arch.user_regs.rcx; - c.nat->user_regs.rdx = v->arch.user_regs.rdx; - c.nat->user_regs.rsi = v->arch.user_regs.rsi; - c.nat->user_regs.rdi = v->arch.user_regs.rdi; - c.nat->user_regs.rip = v->arch.user_regs.rip; - c.nat->user_regs.cs = v->arch.user_regs.cs; - c.nat->user_regs.rflags = v->arch.user_regs.rflags; - c.nat->user_regs.rsp = v->arch.user_regs.rsp; - c.nat->user_regs.ss = v->arch.user_regs.ss; + c.nat->user_regs.r15 = regs->r15; + c.nat->user_regs.r14 = regs->r14; + c.nat->user_regs.r13 = regs->r13; + c.nat->user_regs.r12 = regs->r12; + c.nat->user_regs.rbp = regs->rbp; + c.nat->user_regs.rbx = regs->rbx; + c.nat->user_regs.r11 = regs->r11; + c.nat->user_regs.r10 = regs->r10; + c.nat->user_regs.r9 = regs->r9; + c.nat->user_regs.r8 = regs->r8; + c.nat->user_regs.rax = regs->rax; + c.nat->user_regs.rcx = regs->rcx; + c.nat->user_regs.rdx = regs->rdx; + c.nat->user_regs.rsi = regs->rsi; + c.nat->user_regs.rdi = regs->rdi; + c.nat->user_regs.rip = regs->rip; + c.nat->user_regs.cs = regs->cs; + c.nat->user_regs.rflags = regs->rflags; + c.nat->user_regs.rsp = regs->rsp; + c.nat->user_regs.ss = regs->ss; c.nat->user_regs.es = v->arch.pv.es; c.nat->user_regs.ds = v->arch.pv.ds; c.nat->user_regs.fs = v->arch.pv.fs; @@ -1515,18 +1519,18 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c) else { /* Backing memory is pre-zeroed. */ - c.cmp->user_regs.ebp = v->arch.user_regs.ebp; - c.cmp->user_regs.ebx = v->arch.user_regs.ebx; - c.cmp->user_regs.eax = v->arch.user_regs.eax; - c.cmp->user_regs.ecx = v->arch.user_regs.ecx; - c.cmp->user_regs.edx = v->arch.user_regs.edx; - c.cmp->user_regs.esi = v->arch.user_regs.esi; - c.cmp->user_regs.edi = v->arch.user_regs.edi; - c.cmp->user_regs.eip = v->arch.user_regs.eip; - c.cmp->user_regs.cs = v->arch.user_regs.cs; - c.cmp->user_regs.eflags = v->arch.user_regs.eflags; - c.cmp->user_regs.esp = v->arch.user_regs.esp; - c.cmp->user_regs.ss = v->arch.user_regs.ss; + c.cmp->user_regs.ebp = regs->ebp; + c.cmp->user_regs.ebx = regs->ebx; + c.cmp->user_regs.eax = regs->eax; + c.cmp->user_regs.ecx = regs->ecx; + c.cmp->user_regs.edx = regs->edx; + c.cmp->user_regs.esi = regs->esi; + c.cmp->user_regs.edi = regs->edi; + c.cmp->user_regs.eip = regs->eip; + c.cmp->user_regs.cs = regs->cs; + c.cmp->user_regs.eflags = regs->eflags; + c.cmp->user_regs.esp = regs->esp; + c.cmp->user_regs.ss = regs->ss; c.cmp->user_regs.es = v->arch.pv.es; c.cmp->user_regs.ds = v->arch.pv.ds; c.cmp->user_regs.fs = v->arch.pv.fs; @@ -1638,10 +1642,12 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c) } #endif - if ( guest_kernel_mode(v, &v->arch.user_regs) ) + if ( guest_kernel_mode(v, regs) ) c(flags |= VGCF_in_kernel); } + VCPU_UNMAP_REGS(v, regs); + c(vm_assist = d->vm_assist); #undef c } diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c index 978d8b2222..71e16e25ba 100644 --- a/xen/arch/x86/hvm/domain.c +++ b/xen/arch/x86/hvm/domain.c @@ -103,7 +103,7 @@ static int check_segment(struct segment_register *reg, enum x86_segment seg) int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) { const struct domain *d = v->domain; - struct cpu_user_regs *uregs = &v->arch.user_regs; + struct cpu_user_regs *uregs; struct segment_register cs, ds, ss, es, tr; const char *errstr; int rc; @@ -188,6 +188,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) return -EINVAL; } + uregs = VCPU_MAP_REGS(v); uregs->rax = regs->eax; uregs->rcx = regs->ecx; uregs->rdx = regs->edx; @@ -198,6 +199,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) uregs->rdi = regs->edi; uregs->rip = regs->eip; uregs->rflags = (regs->eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; + VCPU_UNMAP_REGS(v, uregs); v->arch.hvm.guest_cr[0] = regs->cr0; v->arch.hvm.guest_cr[3] = regs->cr3; @@ -239,6 +241,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) return -EINVAL; } + uregs = VCPU_MAP_REGS(v); uregs->rax = regs->rax; uregs->rcx = regs->rcx; uregs->rdx = regs->rdx; @@ -249,6 +252,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) uregs->rdi = regs->rdi; uregs->rip = regs->rip; uregs->rflags = (regs->rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; + VCPU_UNMAP_REGS(v, uregs); v->arch.hvm.guest_cr[0] = regs->cr0; v->arch.hvm.guest_cr[3] = regs->cr3; diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 71da15c0a4..eadccf3d79 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -827,28 +827,29 @@ HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust, NULL, static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h) { + const struct cpu_user_regs *regs = VCPU_MAP_REGS(v); struct segment_register seg; struct hvm_hw_cpu ctxt = { .tsc = hvm_get_guest_tsc_fixed(v, v->domain->arch.hvm.sync_tsc), .msr_tsc_aux = v->arch.msrs->tsc_aux, - .rax = v->arch.user_regs.rax, - .rbx = v->arch.user_regs.rbx, - .rcx = v->arch.user_regs.rcx, - .rdx = v->arch.user_regs.rdx, - .rbp = v->arch.user_regs.rbp, - .rsi = v->arch.user_regs.rsi, - .rdi = v->arch.user_regs.rdi, - .rsp = v->arch.user_regs.rsp, - .rip = v->arch.user_regs.rip, - .rflags = v->arch.user_regs.rflags, - .r8 = v->arch.user_regs.r8, - .r9 = v->arch.user_regs.r9, - .r10 = v->arch.user_regs.r10, - .r11 = v->arch.user_regs.r11, - .r12 = v->arch.user_regs.r12, - .r13 = v->arch.user_regs.r13, - .r14 = v->arch.user_regs.r14, - .r15 = v->arch.user_regs.r15, + .rax = regs->rax, + .rbx = regs->rbx, + .rcx = regs->rcx, + .rdx = regs->rdx, + .rbp = regs->rbp, + .rsi = regs->rsi, + .rdi = regs->rdi, + .rsp = regs->rsp, + .rip = regs->rip, + .rflags = regs->rflags, + .r8 = regs->r8, + .r9 = regs->r9, + .r10 = regs->r10, + .r11 = regs->r11, + .r12 = regs->r12, + .r13 = regs->r13, + .r14 = regs->r14, + .r15 = regs->r15, .cr0 = v->arch.hvm.guest_cr[0], .cr2 = v->arch.hvm.guest_cr[2], .cr3 = v->arch.hvm.guest_cr[3], @@ -863,6 +864,8 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h) }; const struct xsave_struct *xsave_area; + VCPU_UNMAP_REGS(v, regs); + /* * We don't need to save state for a vcpu that is down; the restore * code will leave it down if there is nothing saved. @@ -1020,6 +1023,7 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h) const struct cpu_policy *p = d->arch.cpu_policy; unsigned int vcpuid = hvm_load_instance(h); struct vcpu *v; + struct cpu_user_regs *regs; struct hvm_hw_cpu ctxt; struct segment_register seg; const char *errstr; @@ -1182,24 +1186,26 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h) else vcpu_reset_fpu(v); - v->arch.user_regs.rax = ctxt.rax; - v->arch.user_regs.rbx = ctxt.rbx; - v->arch.user_regs.rcx = ctxt.rcx; - v->arch.user_regs.rdx = ctxt.rdx; - v->arch.user_regs.rbp = ctxt.rbp; - v->arch.user_regs.rsi = ctxt.rsi; - v->arch.user_regs.rdi = ctxt.rdi; - v->arch.user_regs.rsp = ctxt.rsp; - v->arch.user_regs.rip = ctxt.rip; - v->arch.user_regs.rflags = ctxt.rflags | X86_EFLAGS_MBS; - v->arch.user_regs.r8 = ctxt.r8; - v->arch.user_regs.r9 = ctxt.r9; - v->arch.user_regs.r10 = ctxt.r10; - v->arch.user_regs.r11 = ctxt.r11; - v->arch.user_regs.r12 = ctxt.r12; - v->arch.user_regs.r13 = ctxt.r13; - v->arch.user_regs.r14 = ctxt.r14; - v->arch.user_regs.r15 = ctxt.r15; + regs = VCPU_MAP_REGS(v); + regs->rax = ctxt.rax; + regs->rbx = ctxt.rbx; + regs->rcx = ctxt.rcx; + regs->rdx = ctxt.rdx; + regs->rbp = ctxt.rbp; + regs->rsi = ctxt.rsi; + regs->rdi = ctxt.rdi; + regs->rsp = ctxt.rsp; + regs->rip = ctxt.rip; + regs->rflags = ctxt.rflags | X86_EFLAGS_MBS; + regs->r8 = ctxt.r8; + regs->r9 = ctxt.r9; + regs->r10 = ctxt.r10; + regs->r11 = ctxt.r11; + regs->r12 = ctxt.r12; + regs->r13 = ctxt.r13; + regs->r14 = ctxt.r14; + regs->r15 = ctxt.r15; + VCPU_UNMAP_REGS(v, regs); v->arch.dr[0] = ctxt.dr0; v->arch.dr[1] = ctxt.dr1; v->arch.dr[2] = ctxt.dr2; @@ -2563,7 +2569,7 @@ bool hvm_vcpu_virtual_to_linear( { unsigned long addr = offset, last_byte; const struct cpu_user_regs *regs = v == current ? guest_cpu_user_regs() - : &v->arch.user_regs; + : VCPU_MAP_REGS(v); bool okay = false; ASSERT(v == current || !vcpu_runnable(v)); @@ -2688,6 +2694,10 @@ bool hvm_vcpu_virtual_to_linear( * failed. The permissions failure is not relevant to some callers. */ *linear_addr = addr; + + if ( v != current ) + VCPU_UNMAP_REGS(v, regs); + return okay; } @@ -3956,6 +3966,7 @@ void hvm_init_hypercall_page(struct domain *d, void *ptr) void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, uint16_t ip) { struct domain *d = v->domain; + struct cpu_user_regs *regs; struct segment_register reg; domain_lock(d); @@ -3973,7 +3984,9 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, uint16_t ip) vcpu_reset_fpu(v); arch_vcpu_regs_init(v); - v->arch.user_regs.rip = ip; + regs = VCPU_MAP_REGS(v); + regs->rip = ip; + VCPU_UNMAP_REGS(v, regs); v->arch.hvm.guest_cr[0] = X86_CR0_ET; hvm_update_guest_cr(v, 0); diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 592722f1ca..78b0af29f2 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -2083,15 +2083,13 @@ static void vmx_dump_sel2(const char *name, uint32_t lim) void vmcs_dump_vcpu(struct vcpu *v) { - struct cpu_user_regs *regs = &v->arch.user_regs; + const struct cpu_user_regs *regs = v == current ? guest_cpu_user_regs() + : VCPU_MAP_REGS(v); uint32_t vmentry_ctl, vmexit_ctl; unsigned long cr4; uint64_t efer; unsigned int i, n; - if ( v == current ) - regs = guest_cpu_user_regs(); - vmx_vmcs_enter(v); vmentry_ctl = vmr32(VM_ENTRY_CONTROLS), @@ -2236,6 +2234,9 @@ void vmcs_dump_vcpu(struct vcpu *v) vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL)); vmx_vmcs_exit(v); + + if ( v != current ) + VCPU_UNMAP_REGS(v, regs); } static void cf_check vmcs_dump(unsigned char ch) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 3c7374a9ff..bdbcd0ad4d 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2159,8 +2159,12 @@ static bool cf_check vmx_event_pending(const struct vcpu *v) static void cf_check vmx_set_info_guest(struct vcpu *v) { + const struct cpu_user_regs *regs = VCPU_MAP_REGS(v); + bool single_step = regs->eflags & X86_EFLAGS_TF; unsigned long intr_shadow; + VCPU_UNMAP_REGS(v, regs); + vmx_vmcs_enter(v); __vmwrite(GUEST_DR7, v->arch.dr7); @@ -2174,8 +2178,7 @@ static void cf_check vmx_set_info_guest(struct vcpu *v) * immediately vmexit and hence make no progress. */ __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow); - if ( v->domain->debugger_attached && - (v->arch.user_regs.eflags & X86_EFLAGS_TF) && + if ( v->domain->debugger_attached && single_step && (intr_shadow & VMX_INTR_SHADOW_STI) ) { intr_shadow &= ~VMX_INTR_SHADOW_STI; diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c index dc0a90ca09..bfdc462874 100644 --- a/xen/arch/x86/hypercall.c +++ b/xen/arch/x86/hypercall.c @@ -107,9 +107,11 @@ unsigned long hypercall_create_continuation( void arch_hypercall_tasklet_result(struct vcpu *v, long res) { - struct cpu_user_regs *regs = &v->arch.user_regs; + struct cpu_user_regs *regs = VCPU_MAP_REGS(v); regs->rax = res; + + VCPU_UNMAP_REGS(v, regs); } int hypercall_xlat_continuation(unsigned int *id, unsigned int nr, diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 0e405157b4..457eb69ace 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -632,7 +632,12 @@ struct pv_vcpu struct arch_vcpu { - struct cpu_user_regs user_regs; + /* + * The vCPU's register frame while it is not running: __context_switch() + * copies it here from the stack when the vCPU is switched out, and back + * when it is switched in. Everything else goes through VCPU_MAP_REGS(). + */ + struct cpu_user_regs _user_regs; /* Debug registers. */ unsigned long dr[4]; @@ -741,6 +746,27 @@ static inline void free_vcpu_guest_context(struct vcpu_guest_context *vgc) vfree(vgc); } +/* + * Fetch a pointer to the register frame a vCPU was last switched out with, + * or which a toolstack, debugger or reset has put there since: the vCPU's + * registers for code working on a vCPU other than the one running (whose + * registers are on the stack, see guest_cpu_user_regs()). + * + * The pointer is valid until VCPU_UNMAP_REGS(), which clears it. A mapping + * must not be held across a scheduling point. + * + * @param v Owner of the register frame + */ +#define VCPU_MAP_REGS(v) (&(v)->arch._user_regs) + +/* + * Drops the mapping of a vCPU's register frame and nullifies its pointer. + * + * @param v Owner of the register frame + * @param r Register frame of v, from VCPU_MAP_REGS() + */ +#define VCPU_UNMAP_REGS(v, r) do { (void)(v); (r) = NULL; } while ( false ) + void arch_vcpu_regs_init(struct vcpu *v); struct vcpu_hvm_context; diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index f18959f3b4..b38beca2ea 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -1007,7 +1007,7 @@ static int __init dom0_construct(const struct boot_domain *bd) * rSI = start_info * [rAX,rBX,rCX,rDX,rDI,rBP,R8-R15 are zero] */ - regs = &v->arch.user_regs; + regs = VCPU_MAP_REGS(v); v->arch.pv.ds = (compat ? FLAT_COMPAT_KERNEL_DS : FLAT_KERNEL_DS); v->arch.pv.es = (compat ? FLAT_COMPAT_KERNEL_DS : FLAT_KERNEL_DS); v->arch.pv.fs = (compat ? FLAT_COMPAT_KERNEL_DS : FLAT_KERNEL_DS); @@ -1018,6 +1018,7 @@ static int __init dom0_construct(const struct boot_domain *bd) regs->rsp = vstack_end; regs->rsi = vstartinfo_start; regs->eflags = X86_EFLAGS_IF | X86_EFLAGS_MBS; + VCPU_UNMAP_REGS(v, regs); /* * We don't call arch_set_info_guest(), so some initialisation needs doing diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index ac01ba0872..3b4a01ba52 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -273,16 +273,17 @@ void show_registers(const struct cpu_user_regs *regs) void vcpu_show_registers(struct vcpu *v) { - const struct cpu_user_regs *regs = &v->arch.user_regs; - struct cpu_user_regs aux_regs; + const struct cpu_user_regs *regs = VCPU_MAP_REGS(v); + struct cpu_user_regs aux_regs = *regs; struct extra_state state; enum context context; + VCPU_UNMAP_REGS(v, regs); + regs = &aux_regs; + if ( is_hvm_vcpu(v) ) { - aux_regs = *regs; get_hvm_registers(v, &aux_regs, &state); - regs = &aux_regs; context = CTXT_hvm_guest; } else @@ -916,6 +917,7 @@ void cf_check show_execution_state(const struct cpu_user_regs *regs) void vcpu_show_execution_state(struct vcpu *v) { + const struct cpu_user_regs *regs; unsigned long flags = 0; if ( test_bit(_VPF_down, &v->pause_flags) ) @@ -961,12 +963,16 @@ void vcpu_show_execution_state(struct vcpu *v) */ console_unlock_recursive_irqrestore(flags); - show_hvm_stack(v, &v->arch.user_regs); + regs = VCPU_MAP_REGS(v); + show_hvm_stack(v, regs); + VCPU_UNMAP_REGS(v, regs); } else { - if ( guest_kernel_mode(v, &v->arch.user_regs) ) - show_guest_stack(v, &v->arch.user_regs); + regs = VCPU_MAP_REGS(v); + if ( guest_kernel_mode(v, regs) ) + show_guest_stack(v, regs); + VCPU_UNMAP_REGS(v, regs); console_unlock_recursive_irqrestore(flags); } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463797.1674662 (Exim 4.92) (envelope-from ) id 1xMD6W-0006as-ED; Wed, 28 Oct 2026 23:30:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463797.1674662; Wed, 28 Oct 2026 23: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 1xMD6V-0006WY-DI; Wed, 28 Oct 2026 23:30:47 +0000 Received: by outflank-mailman (input) for mailman id 1463797; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048j-UK for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pPV-0BTK; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCje-00000001KpM-4BIA; Wed, 28 Oct 2026 23:07: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" 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=jMfdoAPkdAJPjogk0SgB6TI+M2sU6aQzGFQz4Pr0JLg=; b=o5nm8nJBEuIXNmjlt2hZK3iJ5c rMi+TSpqrt/SJUXfLcr2at3zU/rNo4QBWDav9fJnyPChHIScyEnPkVecanYX1tEY/2BHlj7EIXNAp frrR6bfTo95p77VQElE3EjQHV8/vyjbU0R3UjoKfnfnCJpB6+jl0NowN/amaU3i2Jb7c=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 33/45] x86: move the saved register frame behind the vCPU state window Date: Wed, 28 Oct 2026 23:05:47 +0000 Message-ID: <20261028-asi-hvm-v5-33-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit While a vCPU is not running, its register frame is saved in struct vcpu: a xenheap page, mapped in every context, the sparse directmap view included. Under Address Space Isolation that leaves the general-purpose registers of every descheduled vCPU reachable from other domains' contexts, whether or not the vCPU's own domain is on the sparse view. Keep the frame instead in a domain-heap page of the vCPU's own, mapped for the life of the vCPU at a new slot (index 6) of its state window, like the SVM VMCB and the VMX MSR list; indexes 3-5 are left for the guest XSAVE area, which takes up to three pages. Like the VMCB and MSR list moves, this does not depend on asi=, and it applies to every guest vCPU, PV and HVM: struct vcpu no longer holds a copy. The page is allocated in arch_vcpu_create() ahead of arch_vcpu_regs_init(), which initialises the frame, and unmapped before it is freed, on the failure path as at teardown. An HVM vCPU using per-vCPU page tables has its window in its own page tables. For any other vCPU, PV ones included, the window is in the per-domain area that all its domain's vCPUs share, which only that domain's page tables map: a context on the sparse view reaches no other domain's frames. That includes a domain left off the sparse view, such as dom0 under asi=1,dom0=0, whose vCPUs' frames are no longer mapped in the contexts of the domUs on the sparse view. __context_switch() saves the outgoing vCPU's frame while its page tables are still loaded, and now restores the incoming vCPU's only after write_ptbase(), once its window is mapped. Nothing in between reads the frame: set_xcr0(), the FPU restore, the ctxt_switch->to() hooks, and the PSR and GDT updates. Both copies go through the window address, with interrupts off; a transient mapping would complete the lazy context switch and re-enter __context_switch(). The save is skipped if the outgoing vCPU's page tables are no longer loaded. Only the shadow-mode paths which abandon a PV vCPU's page tables early (update_cr3() failure in new_guest_cr3() and _toggle_guest_pt()) leave them so, loading the idle page tables once they have crashed the domain; anything else reaching that point is a page-table tracking bug, fatal in every build. After such a crash the vCPU's saved frame is the one it was last switched in with, not its registers at the crash, and that is what XEN_DOMCTL_getvcpucontext and the debug keys report for it. VCPU_MAP_REGS() returns the window address when the vCPU is running here on its own page tables (v == current and this_cpu(pgtable_vcpu) == v), and otherwise a transient mapping of the page, which, for a single page, cannot fail. Its users all work on a vCPU other than the one running here, normally paused or not yet run: vCPU creation, the toolstack's vCPU context, the HVM CPU record, VCPUOP_initialise, INIT/SIPI and S3 resets, a hypercall continued on another CPU, PV dom0 construction, and the debug-key dumps. The vCPU's own page tables being loaded is not enough: while a CPU holds a vCPU's state lazily they are loaded there, but an IPI syncing that state for another CPU can switch them away at any time. VCPU_UNMAP_REGS() drops a transient mapping with unmap_vcpu_state_page(), which also flushes this CPU's translation. The live frame on the pCPU's stack, which holds a running vCPU's registers, is not affected. Cost: a page per guest vCPU, and a transient mapping on each of the cold paths above. On every switch into a guest vCPU, the restore reaches the frame through a 4KiB, non-global PTE in the per-domain area, just after switch_cr3_cr4() has flushed the TLB, so it takes a page walk, where struct vcpu was reached through a superpage of the full directmap. struct vcpu shrinks from 3072 to 2880 bytes (x86_64 defconfig). Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/arch/x86/domain.c | 98 ++++++++++++++++++++++++++++++- xen/arch/x86/include/asm/config.h | 1 + xen/arch/x86/include/asm/domain.h | 26 +++++--- 3 files changed, 116 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 6911f8484c..2c27be4437 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include @@ -493,6 +494,66 @@ unsigned int arch_domain_struct_memflags(void) return MEMF_bits(bits); } +/* + * A vCPU keeps its register frame, while it is not running, in a domain-heap + * page of its own, mapped for the life of the vCPU at a fixed slot of its + * state window. + */ +static struct cpu_user_regs *regs_window(const struct vcpu *v) +{ + return (void *)VCPU_STATE_ADDR(v, VCPU_STATE_IDX_REGS); +} + +static int vcpu_regs_alloc(struct vcpu *v) +{ + struct page_info *pg = alloc_domheap_page(v->domain, MEMF_no_owner); + mfn_t mfn; + + if ( !pg ) + return -ENOMEM; + + mfn = page_to_mfn(pg); + clear_domain_page(mfn); + populate_perdomain_mapping(v, VCPU_STATE_ADDR(v, VCPU_STATE_IDX_REGS), + &mfn, 1, __PAGE_HYPERVISOR_RW); + v->arch.regs_pg = pg; + + return 0; +} + +static void vcpu_regs_free(struct vcpu *v) +{ + struct page_info *pg = v->arch.regs_pg; + + if ( !pg ) + return; + + unmap_vcpu_state(v, VCPU_STATE_IDX_REGS, 1); + v->arch.regs_pg = NULL; + free_domheap_page(pg); +} + +struct cpu_user_regs *vcpu_map_regs(const struct vcpu *v) +{ + /* + * v's page tables being loaded is not enough: while this CPU holds v's + * state lazily, an IPI syncing that state for another CPU can switch + * them away at any time. + */ + if ( v == current && this_cpu(pgtable_vcpu) == v ) + return regs_window(v); + + return __map_domain_page(v->arch.regs_pg); +} + +void vcpu_unmap_regs(const struct vcpu *v, const struct cpu_user_regs *regs) +{ + if ( !regs || regs == regs_window(v) ) + return; + + unmap_vcpu_state_page(regs); +} + /* Initialise various registers to their architectural INIT/RESET state. */ void arch_vcpu_regs_init(struct vcpu *v) { @@ -534,6 +595,7 @@ int arch_vcpu_create(struct vcpu *v) BUILD_BUG_ON(VCPU_STATE_IDX_VMCB >= VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_N2VMCB >= VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_VMX_MSR >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_REGS >= VCPU_STATE_NR_PAGES); /* Page tables only; torn down with the rest of the per-domain area. */ rc = create_perdomain_mapping(v, VCPU_STATE_START(v), VCPU_STATE_NR_PAGES, @@ -548,6 +610,10 @@ int arch_vcpu_create(struct vcpu *v) vmce_init_vcpu(v); + /* The frame's storage, ahead of its initialisation. */ + if ( (rc = vcpu_regs_alloc(v)) != 0 ) + goto fail; + arch_vcpu_regs_init(v); if ( (rc = init_vcpu_msr_policy(v)) ) @@ -590,6 +656,7 @@ int arch_vcpu_create(struct vcpu *v) fail: paging_vcpu_teardown(v); vcpu_destroy_fpu(v); + vcpu_regs_free(v); xfree(v->arch.msrs); v->arch.msrs = NULL; free_pervcpu_mappings(v); @@ -614,6 +681,8 @@ void arch_vcpu_destroy(struct vcpu *v) else ASSERT_UNREACHABLE(); + vcpu_regs_free(v); + free_pervcpu_mappings(v); } @@ -2129,6 +2198,19 @@ static void load_default_gdt(unsigned int cpu) per_cpu(full_gdt_loaded, cpu) = false; } +/* + * The register frame of p or n, for __context_switch(), which runs with + * interrupts off and with the vCPU's own page tables loaded: the window + * address serves. A transient mapping is not an option from here: it would + * complete the lazy context switch and re-enter __context_switch(). + */ +static struct cpu_user_regs *vcpu_user_regs(const struct vcpu *v) +{ + BUG_ON(this_cpu(pgtable_vcpu) != v); + + return regs_window(v); +} + static void __context_switch(void) { struct cpu_user_regs *stack_regs = guest_cpu_user_regs(); @@ -2143,7 +2225,17 @@ static void __context_switch(void) if ( !is_idle_domain(pd) ) { ASSERT(read_atomic(&p->dirty_cpu) == cpu); - memcpy(&p->arch._user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES); + /* + * p's frame is reached through its state window, mapped while p's + * own page tables are loaded, as they normally still are here. Not + * so after the shadow-mode paths which abandon a vCPU's tables early + * (update_cr3() failure), which have crashed the domain: the frame + * is left unsaved. A transient mapping would re-enter this function. + */ + if ( likely(this_cpu(pgtable_vcpu) == p) ) + memcpy(vcpu_user_regs(p), stack_regs, CTXT_SWITCH_STACK_BYTES); + else + BUG_ON(!domain_shutting_down(pd)); vcpu_save_fpu(p); pd->arch.ctxt_switch->from(p); } @@ -2159,7 +2251,6 @@ static void __context_switch(void) if ( !is_idle_domain(nd) ) { - memcpy(stack_regs, &n->arch._user_regs, CTXT_SWITCH_STACK_BYTES); if ( cpu_has_xsave ) { if ( !set_xcr0(n->arch.xcr0 ?: XSTATE_FP_SSE) ) @@ -2183,6 +2274,9 @@ static void __context_switch(void) write_ptbase(n); + if ( !is_idle_domain(nd) ) + memcpy(stack_regs, vcpu_user_regs(n), CTXT_SWITCH_STACK_BYTES); + #ifdef CONFIG_PV /* Prefetch the VMCB if we expect to use it later in the context switch */ if ( using_svm() && is_pv_64bit_domain(nd) && !is_idle_domain(nd) ) diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index 8a265e25c8..c8d4a8ddc7 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -311,6 +311,7 @@ extern unsigned long xen_phys_start; #define VCPU_STATE_IDX_VMCB 0 #define VCPU_STATE_IDX_N2VMCB 1 #define VCPU_STATE_IDX_VMX_MSR 2 +#define VCPU_STATE_IDX_REGS 6 #define ELFSIZE 64 diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 457eb69ace..6b27af9eb5 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -633,11 +633,12 @@ struct pv_vcpu struct arch_vcpu { /* - * The vCPU's register frame while it is not running: __context_switch() - * copies it here from the stack when the vCPU is switched out, and back - * when it is switched in. Everything else goes through VCPU_MAP_REGS(). + * The page holding the vCPU's register frame while it is not running, + * mapped in its state window: __context_switch() copies the frame there + * from the stack when the vCPU is switched out, and back when it is + * switched in. Everything else goes through VCPU_MAP_REGS(). */ - struct cpu_user_regs _user_regs; + struct page_info *regs_pg; /* Debug registers. */ unsigned long dr[4]; @@ -752,12 +753,20 @@ static inline void free_vcpu_guest_context(struct vcpu_guest_context *vgc) * registers for code working on a vCPU other than the one running (whose * registers are on the stack, see guest_cpu_user_regs()). * + * The frame is in the vCPU's state window: the window address serves while + * the vCPU runs here on its own page tables, and the page is mapped + * transiently otherwise, which cannot fail. + * * The pointer is valid until VCPU_UNMAP_REGS(), which clears it. A mapping - * must not be held across a scheduling point. + * must not be held across a scheduling point: a transient one is only valid + * on the pCPU which made it. * * @param v Owner of the register frame */ -#define VCPU_MAP_REGS(v) (&(v)->arch._user_regs) +struct cpu_user_regs *vcpu_map_regs(const struct vcpu *v); +void vcpu_unmap_regs(const struct vcpu *v, const struct cpu_user_regs *regs); + +#define VCPU_MAP_REGS(v) vcpu_map_regs(v) /* * Drops the mapping of a vCPU's register frame and nullifies its pointer. @@ -765,7 +774,10 @@ static inline void free_vcpu_guest_context(struct vcpu_guest_context *vgc) * @param v Owner of the register frame * @param r Register frame of v, from VCPU_MAP_REGS() */ -#define VCPU_UNMAP_REGS(v, r) do { (void)(v); (r) = NULL; } while ( false ) +#define VCPU_UNMAP_REGS(v, r) do { \ + vcpu_unmap_regs(v, r); \ + (r) = NULL; \ +} while ( false ) void arch_vcpu_regs_init(struct vcpu *v); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463799.1674669 (Exim 4.92) (envelope-from ) id 1xMD6X-0006me-6a; Wed, 28 Oct 2026 23:30:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463799.1674669; Wed, 28 Oct 2026 23: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 1xMD6W-0006gy-9q; Wed, 28 Oct 2026 23:30:48 +0000 Received: by outflank-mailman (input) for mailman id 1463799; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-000495-1V for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pPD-4BuO; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjg-00000001KpM-3TaO; Wed, 28 Oct 2026 23:07: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=xMTLrvxxwpwmKfoWs2RiIcYg6g+Liai9ytC5nmpdgLQ=; b=XH5Tx6p9ugn8sbuh8vww2TnW6E oCo46K90NkNypjKIpjZlVOPErWCJ5JESLk1ouKZN8DdDl4ZpxZ9cUpNwriqfODh3i3HI4EqhPEEwq 8Gl3HRtVnWyHkcpe/LEmNOfH0mOdVWVGRsGJp40jWc6ExUVlaav2DCOXZhrZJHpB10rQ=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 35/45] x86/hvm: clear the vCPU's copy of an emulated I/O request once consumed Date: Wed, 28 Oct 2026 23:05:49 +0000 Message-ID: <20261028-asi-hvm-v5-35-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit hvmemul_do_io() keeps the request it is emulating in the vCPU's struct vcpu_io: the data written, or the response once a device model has supplied it, with the address and repeat count. Once the access is done only the state is set back to STATE_IOREQ_NONE, so the operand stays in struct vcpu, a xenheap page mapped in every context, until the next emulated I/O overwrites it. Drop the copy wherever it is done with: when the response has been taken into hvmemul_do_io()'s local copy on the instruction's re-execution, when Xen's own handlers have completed the access, when the request is retried, suspended or not sent, and in hvmemul_cancel(). A request sent to a device model stays while it is in flight: the re-execution checks it, and the port-I/O completion reads its address and size before re-issuing it. One which needs no completion -- a port write, or a request whose data is a guest buffer's address -- loses its address, data and count as soon as it is sent: the device model has its own copy, and the completion path reads only the state, type, direction and data_is_ptr. Nothing reads the copy after STATE_IOREQ_NONE. Only the x86 emulator changes. struct vcpu_io is common code, and Arm's MMIO completion reads the response from it. Moving the in-flight copy out of struct vcpu belongs with narrowing the ioreq server pages, which carry the same operand while a device model handles it. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/arch/x86/hvm/emulate.c | 36 ++++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index e2cf982c25..da7c08b5d9 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -167,6 +167,16 @@ static const struct hvm_io_handler ioreq_server_handler = { .ops = &ioreq_server_ops }; +/* + * The vCPU's copy of an emulated I/O request is done with: nothing reads it + * before the next request overwrites it. Clear it all, so that the operand + * and the address do not stay in struct vcpu. + */ +static void ioreq_done(struct vcpu_io *vio) +{ + vio->req = (ioreq_t){ .state = STATE_IOREQ_NONE }; +} + /* * Drop all records of in-flight emulation. This is needed whenever a vCPU's * register state may have changed behind the emulator's back. @@ -175,7 +185,7 @@ void hvmemul_cancel(struct vcpu *v) { struct hvm_vcpu_io *hvio = &v->arch.hvm.hvm_io; - v->io.req.state = STATE_IOREQ_NONE; + ioreq_done(&v->io); v->io.completion = VIO_no_completion; hvio->mmio_cache_count = 0; hvio->mmio_insn_bytes = 0; @@ -265,8 +275,9 @@ static int hvmemul_do_io( case STATE_IOREQ_NONE: break; case STATE_IORESP_READY: - vio->req.state = STATE_IOREQ_NONE; + /* The local copy carries the response from here. */ p = vio->req; + ioreq_done(vio); /* Verify the emulation request has been correctly re-issued */ if ( (p.type != (is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO)) || @@ -330,7 +341,7 @@ static int hvmemul_do_io( { case X86EMUL_OKAY: case X86EMUL_RETRY: - vio->req.state = STATE_IOREQ_NONE; + ioreq_done(vio); break; case X86EMUL_UNHANDLEABLE: { @@ -383,7 +394,7 @@ static int hvmemul_do_io( if ( s == NULL ) { rc = X86EMUL_RETRY; - vio->req.state = STATE_IOREQ_NONE; + ioreq_done(vio); break; } @@ -394,7 +405,7 @@ static int hvmemul_do_io( if ( dir == IOREQ_READ ) { rc = hvm_process_io_intercept(&ioreq_server_handler, &p); - vio->req.state = STATE_IOREQ_NONE; + ioreq_done(vio); break; } } @@ -440,7 +451,7 @@ static int hvmemul_do_io( paddr_to_pfn(addr)); rc = X86EMUL_RETRY; - vio->req.state = STATE_IOREQ_NONE; + ioreq_done(vio); break; } @@ -455,15 +466,24 @@ static int hvmemul_do_io( dir ? "read from" : "write to", addr, size); } rc = hvm_process_io_intercept(&null_handler, &p); - vio->req.state = STATE_IOREQ_NONE; + ioreq_done(vio); } else { rc = ioreq_send(s, &p, 0); if ( rc != X86EMUL_RETRY || vio->suspended ) - vio->req.state = STATE_IOREQ_NONE; + ioreq_done(vio); else if ( !ioreq_needs_completion(&vio->req) ) + { + /* + * Nothing comes back, and the device model has its own copy + * of the request: keep only what completion checks. + */ + vio->req.addr = 0; + vio->req.data = 0; + vio->req.count = 0; rc = X86EMUL_OKAY; + } } break; } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463798.1674678 (Exim 4.92) (envelope-from ) id 1xMD6Y-00074F-T8; Wed, 28 Oct 2026 23:30:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463798.1674678; Wed, 28 Oct 2026 23: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 1xMD6X-0006xK-Hp; Wed, 28 Oct 2026 23:30:49 +0000 Received: by outflank-mailman (input) for mailman id 1463798; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6K-00048k-Uw for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOD-2mbO; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjo-00000001KpM-4B30; Wed, 28 Oct 2026 23: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=DbVOB2YlxYBgBhkCO9XsfTSfRNU6koHfebs+alJDQWM=; b=ZpgGwQ0a/ssphHOnxGzVp44Et5 vA90tHujpLrJLgwBsxXLgbklo9gIi0KprcaH2Vtz6fMo5XWX9TYEXPMcjeOs+QA3QGe0kzPim2VDO Ng+mNe6fYHJ21t12LugQs4nP0GbU7op7E2b1boBk13MEeJejlx8Bc0Rv8QTnbWX3mP2Y=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 43/45] x86/xstate: classify xsave-area seam accesses by failure mode Date: Wed, 28 Oct 2026 23:05:57 +0000 Message-ID: <20261028-asi-hvm-v5-43-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The VCPU_MAP_XSAVE_AREA() seam currently cannot fail: the map is a pointer fetch. Once guest XSAVE areas move behind per-vCPU mappings, mapping another vCPU's multi-page area becomes an operation that can run out of resources. Split the seam's users along that line ahead of the change: - expand_xsave_states() and compress_xsave_states() address the full area; they gain an error return, which their four callers (the vcpuextstate domctls and the HVM context save/load handlers) propagate. The two deserialising callers (the setvcpuextstate domctl and the HVM xsave-state load handler) restore the previously-set XCR0 fields if the deserialisation fails, so a failed restore leaves the vCPU's state as it was. - Accessors touching only the legacy region and the XSAVE header -- vcpu_reset_fpu(), vcpu_setup_fpu(), hvm_save_cpu_ctxt() and arch_get_info_guest() -- switch to a new VCPU_MAP_XSAVE_AREA_PREFIX() variant. The prefix always fits the area's first page, so that variant can remain infallible, and no error plumbing is needed on the paths (INIT/SIPI, S3 resume) that have no way to fail. No functional change: both variants are still pointer fetches. Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/arch/x86/domctl.c | 26 ++++++++++++++++++-------- xen/arch/x86/hvm/hvm.c | 27 ++++++++++++++++++--------- xen/arch/x86/i387.c | 8 ++++---- xen/arch/x86/include/asm/xstate.h | 13 +++++++++++-- xen/arch/x86/xstate.c | 18 +++++++++++++++--- 5 files changed, 66 insertions(+), 26 deletions(-) diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index b7ea1e1801..b967352fc5 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -1010,10 +1010,10 @@ long arch_do_domctl( goto vcpuextstate_out; } - expand_xsave_states(v, xsave_area, xsave_size); + ret = expand_xsave_states(v, xsave_area, xsave_size); - if ( copy_to_guest_offset(evc->buffer, offset, xsave_area, - xsave_size) ) + if ( !ret && copy_to_guest_offset(evc->buffer, offset, + xsave_area, xsave_size) ) ret = -EFAULT; xfree(xsave_area); } @@ -1077,14 +1077,24 @@ long arch_do_domctl( ret = -EINVAL; /* Not legitimate data. */ else { + uint64_t old_xcr0, old_xcr0_accum; + vcpu_pause(v); + old_xcr0 = v->arch.xcr0; + old_xcr0_accum = v->arch.xcr0_accum; v->arch.xcr0 = _xcr0; v->arch.xcr0_accum = _xcr0_accum; - compress_xsave_states(v, _xsave_area, - evc->size - PV_XSAVE_HDR_SIZE); + ret = compress_xsave_states(v, _xsave_area, + evc->size - PV_XSAVE_HDR_SIZE); - if ( is_hvm_domain(d) ) + if ( ret ) + { + /* Leave the vCPU's state as it was. */ + v->arch.xcr0 = old_xcr0; + v->arch.xcr0_accum = old_xcr0_accum; + } + else if ( is_hvm_domain(d) ) hvmemul_cancel(v); vcpu_unpause(v); @@ -1468,10 +1478,10 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c) #define c(fld) (c.nat->fld) #endif - xsave_area = VCPU_MAP_XSAVE_AREA(v); + xsave_area = VCPU_MAP_XSAVE_AREA_PREFIX(v); BUILD_BUG_ON(sizeof(c.nat->fpu_ctxt) != sizeof(xsave_area->fpu_sse)); memcpy(&c.nat->fpu_ctxt, &xsave_area->fpu_sse, sizeof(c.nat->fpu_ctxt)); - VCPU_UNMAP_XSAVE_AREA(v, xsave_area); + VCPU_UNMAP_XSAVE_AREA_PREFIX(v, xsave_area); if ( is_pv_domain(d) ) c(flags = v->arch.pv.vgc_flags & ~VGCF_in_kernel); diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index eadccf3d79..42a7d03b3a 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -932,10 +932,10 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h) ctxt.ldtr_base = seg.base; ctxt.ldtr_arbytes = seg.attr; - xsave_area = VCPU_MAP_XSAVE_AREA(v); + xsave_area = VCPU_MAP_XSAVE_AREA_PREFIX(v); BUILD_BUG_ON(sizeof(ctxt.fpu_regs) != sizeof(xsave_area->fpu_sse)); memcpy(ctxt.fpu_regs, &xsave_area->fpu_sse, sizeof(ctxt.fpu_regs)); - VCPU_UNMAP_XSAVE_AREA(v, xsave_area); + VCPU_UNMAP_XSAVE_AREA_PREFIX(v, xsave_area); ctxt.flags = XEN_X86_FPU_INITIALISED; return hvm_save_entry(CPU, v->vcpu_id, h, &ctxt); @@ -1251,10 +1251,8 @@ static int cf_check hvm_save_cpu_xsave_states( ctxt->xcr0 = v->arch.xcr0; ctxt->xcr0_accum = v->arch.xcr0_accum; - expand_xsave_states(v, &ctxt->save_area, - size - offsetof(typeof(*ctxt), save_area)); - - return 0; + return expand_xsave_states(v, &ctxt->save_area, + size - offsetof(typeof(*ctxt), save_area)); } /* @@ -1279,6 +1277,7 @@ static int cf_check hvm_load_cpu_xsave_states( struct hvm_hw_cpu_xsave *ctxt; const struct hvm_save_descriptor *desc; unsigned int i, desc_start, desc_length; + uint64_t old_xcr0, old_xcr0_accum; /* Which vcpu is this? */ vcpuid = hvm_load_instance(h); @@ -1383,12 +1382,22 @@ static int cf_check hvm_load_cpu_xsave_states( } /* Checking finished */ + old_xcr0 = v->arch.xcr0; + old_xcr0_accum = v->arch.xcr0_accum; v->arch.xcr0 = ctxt->xcr0; v->arch.xcr0_accum = ctxt->xcr0_accum; - compress_xsave_states(v, &ctxt->save_area, - size - offsetof(struct hvm_hw_cpu_xsave, save_area)); - return 0; + err = compress_xsave_states(v, &ctxt->save_area, + size - offsetof(struct hvm_hw_cpu_xsave, + save_area)); + if ( err ) + { + /* Leave the vCPU's state as it was. */ + v->arch.xcr0 = old_xcr0; + v->arch.xcr0_accum = old_xcr0_accum; + } + + return err; } #define HVM_CPU_MSR_SIZE(cnt) offsetof(struct hvm_msr, msr[cnt]) diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c index b796687eeb..d49e391e99 100644 --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -222,7 +222,7 @@ int vcpu_init_fpu(struct vcpu *v) void vcpu_reset_fpu(struct vcpu *v) { - struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(v); + struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA_PREFIX(v); *xsave_area = (struct xsave_struct) { .xsave_hdr.xstate_bv = X86_XCR0_X87, @@ -233,19 +233,19 @@ void vcpu_reset_fpu(struct vcpu *v) xsave_area->fpu_sse.fcw = FCW_RESET; xsave_area->fpu_sse.ftw = FXSAVE_FTW_RESET; - VCPU_UNMAP_XSAVE_AREA(v, xsave_area); + VCPU_UNMAP_XSAVE_AREA_PREFIX(v, xsave_area); } void vcpu_setup_fpu(struct vcpu *v, const void *data) { - struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(v); + struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA_PREFIX(v); *xsave_area = (struct xsave_struct) { .fpu_sse = *(const fpusse_t*)data, .xsave_hdr.xstate_bv = XSTATE_FP_SSE, }; - VCPU_UNMAP_XSAVE_AREA(v, xsave_area); + VCPU_UNMAP_XSAVE_AREA_PREFIX(v, xsave_area); } /* Free FPU's context save area */ diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h index 3d57aaadd8..c23308cbe2 100644 --- a/xen/arch/x86/include/asm/xstate.h +++ b/xen/arch/x86/include/asm/xstate.h @@ -103,8 +103,8 @@ int __must_check validate_xstate(const struct domain *d, uint64_t xcr0, uint64_t xcr0_accum, const struct xsave_hdr *hdr); int __must_check handle_xsetbv(u32 index, u64 new_bv); -void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size); -void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size); +int expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size); +int compress_xsave_states(struct vcpu *v, const void *src, unsigned int size); /* extended state init and cleanup functions */ void xstate_free_save_area(struct vcpu *v); @@ -171,4 +171,13 @@ xsave_area_compressed(const struct xsave_struct *xsave_area) */ #define VCPU_UNMAP_XSAVE_AREA(v, x) do { (void)(v); (x) = NULL; } while (0) +/* + * Variant of VCPU_MAP_XSAVE_AREA() for accessors which touch nothing + * beyond the legacy region and the XSAVE header (the first + * XSTATE_AREA_MIN_SIZE bytes). That prefix always fits within the + * area's first page, so this variant cannot fail. + */ +#define VCPU_MAP_XSAVE_AREA_PREFIX(v) VCPU_MAP_XSAVE_AREA(v) +#define VCPU_UNMAP_XSAVE_AREA_PREFIX(v, x) VCPU_UNMAP_XSAVE_AREA(v, x) + #endif /* __ASM_XSTATE_H */ diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 3c9be271a3..2dd1699aba 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -177,14 +177,19 @@ static void setup_xstate_comp(uint16_t *comp_offsets, * It is the callers responsibility to ensure that there is xsave state to * serialise, and that the provided buffer is exactly the right size. */ -void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size) +int expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size) { const struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v); const void *src; uint16_t comp_offsets[sizeof(xfeature_mask)*8]; - u64 xstate_bv = xstate->xsave_hdr.xstate_bv; + u64 xstate_bv; u64 valid; + if ( !xstate ) + return -ENOMEM; + + xstate_bv = xstate->xsave_hdr.xstate_bv; + /* Check there is state to serialise (i.e. at least an XSAVE_HDR) */ BUG_ON(!v->arch.xcr0_accum); /* Check there is the correct room to decompress into. */ @@ -233,6 +238,8 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size) out: VCPU_UNMAP_XSAVE_AREA(v, xstate); + + return 0; } /* @@ -245,13 +252,16 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size) * It is the callers responsibility to ensure that the source buffer contains * xsave state, is uncompressed, and is exactly the right size. */ -void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size) +int compress_xsave_states(struct vcpu *v, const void *src, unsigned int size) { struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v); void *dest; uint16_t comp_offsets[sizeof(xfeature_mask)*8]; u64 xstate_bv, valid; + if ( !xstate ) + return -ENOMEM; + BUG_ON(!v->arch.xcr0_accum); BUG_ON(size != xstate_uncompressed_size(v->arch.xcr0_accum)); ASSERT(!xsave_area_compressed(src)); @@ -302,6 +312,8 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size) out: VCPU_UNMAP_XSAVE_AREA(v, xstate); + + return 0; } void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463802.1674686 (Exim 4.92) (envelope-from ) id 1xMD6a-0007LW-NR; Wed, 28 Oct 2026 23:30:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463802.1674686; Wed, 28 Oct 2026 23:30: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 1xMD6Z-0007Gh-4Y; Wed, 28 Oct 2026 23:30:51 +0000 Received: by outflank-mailman (input) for mailman id 1463802; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049K-52 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pPp-0X7P; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjo-00000001KpM-0M9q; Wed, 28 Oct 2026 23:07: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=O3n3UQQODatRF1IOFe5HjC1fiBbAzhiwh2RBel9BdYM=; b=u1aXUZIvXLl0E1ixBbS8VlGeig pmOlOvqtr1AGH3fkYgcfXbXKDiYjVmmgXz3XOju2bhTcVMyiHXY6J7dAMFbwzErd7l5lhN4hcxj/Y ucTNrQghNfMqKorOw3JoB/E35PKKZjhfEbhLWbn/47oI3By8faFoSMD73zgmWzwZy2MM=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 42/45] x86/fpu: Pass explicit xsave areas to fpu_(f)xrstor() Date: Wed, 28 Oct 2026 23:05:56 +0000 Message-ID: <20261028-asi-hvm-v5-42-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Alejandro Vallejo Mirror of the save-side change: the restore entry point fetches the vCPU's XSAVE area once, through the VCPU_MAP_XSAVE_AREA() seam, and passes the pointer down explicitly. xrstor() gains an area parameter in place of its internal dereference (its fault-recovery writes go through the same mapped pointer), fpu_fxrstor() reduces to taking just the legacy region, and the two direct xrstor() callers -- XSETBV emulation and xstate_set_init() -- pass the pointers they already hold mapped. In handle_xsetbv() this moves the xrstor inside the mapped section, where it belongs. No functional change. Signed-off-by: Alejandro Vallejo Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Revived from "x86: Address Space Isolation FPU preparations" v3 patch 11/12 (<20250110132823.24348-12-alejandro.vallejo@cloud.com>, Acked-by Jan Beulich; no v4 was ever posted). Changes in v5: - New in this version. Changes since the previously posted version: - Regenerated against the eager-FPU-only tree: the entry point is now vcpu_restore_fpu() (the lazy/nonlazy split no longer exists), and the mask is always XSTATE_ALL. - Moved handle_xsetbv()'s xrstor() call inside its map/unmap bracket, which the explicit-area form makes possible. - Expanded the commit message. --- xen/arch/x86/i387.c | 19 ++++++++++++------- xen/arch/x86/include/asm/xstate.h | 2 +- xen/arch/x86/xstate.c | 7 +++---- 3 files changed, 16 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c index 65491b5697..b796687eeb 100644 --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -20,7 +20,8 @@ /* FPU Restore Functions */ /*******************************/ /* Restore x87 extended state */ -static inline void fpu_xrstor(struct vcpu *v, uint64_t mask) +static inline void fpu_xrstor(const struct vcpu *v, + struct xsave_struct *xsave_area, uint64_t mask) { bool ok; @@ -30,16 +31,14 @@ static inline void fpu_xrstor(struct vcpu *v, uint64_t mask) */ ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE); ASSERT(ok); - xrstor(v, mask); + xrstor(v, xsave_area, mask); ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE); ASSERT(ok); } /* Restore x87 FPU, MMX, SSE and SSE2 state */ -static inline void fpu_fxrstor(struct vcpu *v) +static inline void fpu_fxrstor(const fpusse_t *fpu_ctxt) { - const fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; - /* * Some CPUs don't save/restore FDP/FIP/FOP unless an exception * is pending. Clear the x87 state here by setting it to fixed @@ -174,12 +173,18 @@ static inline void fpu_fxsave(const struct vcpu *v, fpusse_t *fpu_ctxt) /* Restore FPU state whenever VCPU is schduled in. */ void vcpu_restore_fpu(struct vcpu *v) { + struct xsave_struct *xsave_area; + ASSERT(!is_idle_vcpu(v)); + xsave_area = VCPU_MAP_XSAVE_AREA(v); + if ( cpu_has_xsave ) - fpu_xrstor(v, XSTATE_ALL); + fpu_xrstor(v, xsave_area, XSTATE_ALL); else - fpu_fxrstor(v); + fpu_fxrstor(&xsave_area->fpu_sse); + + VCPU_UNMAP_XSAVE_AREA(v, xsave_area); /* Xen doesn't need TS set, but the guest might. */ if ( is_pv_vcpu(v) && (v->arch.pv.ctrlreg[0] & X86_CR0_TS) ) diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h index 40bb6f152e..3d57aaadd8 100644 --- a/xen/arch/x86/include/asm/xstate.h +++ b/xen/arch/x86/include/asm/xstate.h @@ -96,7 +96,7 @@ void set_msr_xss(u64 xss); uint64_t get_msr_xss(void); uint64_t read_bndcfgu(void); void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask); -void xrstor(struct vcpu *v, uint64_t mask); +void xrstor(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask); void xstate_set_init(uint64_t mask); bool xsave_enabled(const struct vcpu *v); int __must_check validate_xstate(const struct domain *d, diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 058bc4c0bc..3c9be271a3 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -378,11 +378,10 @@ void xsave(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask) ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = fip_width; } -void xrstor(struct vcpu *v, uint64_t mask) +void xrstor(const struct vcpu *v, struct xsave_struct *ptr, uint64_t mask) { uint32_t hmask = mask >> 32; uint32_t lmask = mask; - struct xsave_struct *ptr = v->arch.xsave_area; unsigned int faults, prev_faults; /* @@ -1011,8 +1010,8 @@ int handle_xsetbv(u32 index, u64 new_bv) clts(); asm ( "stmxcsr %0" : "=m" (xsave_area->fpu_sse.mxcsr) ); + xrstor(curr, xsave_area, mask); VCPU_UNMAP_XSAVE_AREA(curr, xsave_area); - xrstor(curr, mask); if ( cr0 & X86_CR0_TS ) write_cr0(cr0); } @@ -1079,7 +1078,7 @@ void xstate_set_init(uint64_t mask) xstate = VCPU_MAP_XSAVE_AREA(v); memset(&xstate->xsave_hdr, 0, sizeof(xstate->xsave_hdr)); - xrstor(v, mask); + xrstor(v, xstate, mask); VCPU_UNMAP_XSAVE_AREA(v, xstate); if ( cr0 & X86_CR0_TS ) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463803.1674696 (Exim 4.92) (envelope-from ) id 1xMD6c-0007eR-Je; Wed, 28 Oct 2026 23:30:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463803.1674696; Wed, 28 Oct 2026 23: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 1xMD6a-0007ZM-Sk; Wed, 28 Oct 2026 23:30:52 +0000 Received: by outflank-mailman (input) for mailman id 1463803; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049S-6H for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pQT-1FKD; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjp-00000001KpM-3mRa; Wed, 28 Oct 2026 23:07: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:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=IteVxGd7849ZKEuwZ+hgHhRePArJlWdr2co4VC0Lmas=; b=LNhda0lc5wqv4nnzd4y0DOMRGq vKOvo3jJYjZL2/Zqcjs6lB9v4QY3Dx6zi/JVJ1SvBoLT8ncHu2hCe35COlprlZ2RfkbuysdGmQ6E0 QY5q2az3WmPS6c3d0h3nLj3IWatihHCSuTLv5MN4o8w34iYHhlb537WiOzEw1THBN2MI=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 44/45] x86/domain: restore FPU state after switching to the new page tables Date: Wed, 28 Oct 2026 23:05:58 +0000 Message-ID: <20261028-asi-hvm-v5-44-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit __context_switch() restores the incoming vCPU's FPU state (vcpu_restore_fpu(n)) while still running on the outgoing vCPU's page tables, before write_ptbase(n). That dereferences n's XSAVE area through whatever address it happens to have in p's address space -- fine today, when the area is globally mapped, but not once guest XSAVE state moves to a per-vCPU mapping that need not exist in another vCPU's address space (upcoming Address Space Isolation work). Move the eager restore to just after write_ptbase(n), so it runs with n's page tables loaded. The XCR0/XSS setup stays where it is (it programs control registers / an MSR, independent of the page tables, and XSS must be set before the supervisor-state xrstor). Nothing between the save and the new restore point touches guest FPU state: the ctxt_switch->to() hooks, psr and GDT handling are all FPU-free, and Xen is built without SSE. No functional change with the current global XSAVE-area mapping. Assisted-by: Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- xen/arch/x86/domain.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 397508a313..e57a99504b 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2261,7 +2261,6 @@ static void __context_switch(void) if ( cpu_has_xsaves && is_hvm_vcpu(n) ) set_msr_xss(n->arch.msrs->xss.raw); } - vcpu_restore_fpu(n); nd->arch.ctxt_switch->to(n); } @@ -2277,7 +2276,10 @@ static void __context_switch(void) write_ptbase(n); if ( !is_idle_domain(nd) ) + { memcpy(stack_regs, vcpu_user_regs(n), CTXT_SWITCH_STACK_BYTES); + vcpu_restore_fpu(n); + } #ifdef CONFIG_PV /* Prefetch the VMCB if we expect to use it later in the context switch */ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463801.1674702 (Exim 4.92) (envelope-from ) id 1xMD6e-000823-8j; Wed, 28 Oct 2026 23:30:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463801.1674702; Wed, 28 Oct 2026 23:30: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 1xMD6c-0007tU-Ow; Wed, 28 Oct 2026 23:30:54 +0000 Received: by outflank-mailman (input) for mailman id 1463801; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049B-3Q for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pQF-0wHy; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjK-00000001KpM-2C4W; Wed, 28 Oct 2026 23:06: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" 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=OyV4YAPF4e+PZiLpSD0A+0i1GRo90xWbIXsdeH11W3w=; b=gQRWe4tYspPm+HvX4TgDpN28XP ca4RJADHHXUhU95j7CeZS5UO9XT30wVrX18XNtPymEQQsJfQn1LspmGz/r1A8VBT7gEjPlZyyQuBb bkkaldyKuWY8j4IcxZnvqWjCTxGEvlRF1YmgIbgVbqQQiw4KU5zFLOvgSkiQQJ/FKAEQ=; 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?= , Teddy Astie Subject: [PATCH v5 14/45] x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains Date: Wed, 28 Oct 2026 23:05:28 +0000 Message-ID: <20261028-asi-hvm-v5-14-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Add a struct mapcache to struct mapcache_vcpu for the per-vCPU accounting, with MAPCACHE_PERVCPU_ENTRIES (64) slots. Its inuse and garbage bitmaps are then an unsigned long each: declare them inline in struct mapcache_vcpu, rather than mapping them in the per-domain area as the domain-wide bitmaps are. A per-vCPU mapcache is only ever used by its own vCPU, and so by one pCPU at a time. We can therefore skip both the lock and the TLB-epoch tracking the domain-wide mapcache needs; a wrap still flushes the local TLB. struct mapcache_vcpu grows from 136 to 176 bytes, and struct vcpu from 3008 to 3072 bytes (x86_64, debug build), within its page. Unlike a domain-wide mapcache, whose one pool all the domain's vCPUs draw on, a per-vCPU one cannot, by design, use more than its own slots: MAPCACHE_PERVCPU_ENTRIES (64) is the most single-page mappings such a vCPU can hold at once, interrupt handlers' included, and one more hits the BUG_ON() in map_domain_page(). The PoD zero-page sweep held up to 16 on top of its callers' until "x86/PoD: map one page at a time in p2m_pod_zero_check()". A domain-wide mapcache is sized at MAPCACHE_VCPU_ENTRIES (16) slots per vCPU, in one shared pool; a per-vCPU one gets 64, for a wider margin. The extra slots take no memory: the area is a whole L1 page whatever the number of slots, and each bitmap is still one unsigned long. Wraps, each of which flushes the local TLB, also come less often. mapcache_current_vcpu()'s lazy-context-switch handling (sync_local_execstate() plus a pgtable_vcpu re-read) now applies to any vCPU with a mapcache: when the idle vCPU runs lazily on an HVM vCPU's monitor table, the full switch happens before the idle context uses a mapcache. In release builds map_domain_page() still tries the directmap first, for any vCPU; debug builds exercise the new mapcache. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Message: a domain-wide mapcache is one pool that all the domain's vCPUs draw on, not per-vCPU slots another vCPU could borrow. Changes in v4: - d->arch.vcpu_pt is now d->arch.asi.vcpu_pt. - mapcache_lock() / mapcache_unlock() are now mapcache_enter() / mapcache_exit(). has_mapcache()'s comment no longer changes, and the early return in mapcache_enter() has a one-line comment instead of a sentence added to the block (Roger). - mapcache_vcpu_init(): ents and nr become assignments here, ents now depending on the kind of mapcache (Jan). - A per-vCPU mapcache gets 64 slots (MAPCACHE_PERVCPU_ENTRIES) in place of MAPCACHE_VCPU_ENTRIES (16), which still sizes the domain-wide mapcache; its bitmaps, now full, are described as an unsigned long each (Roger). - Move the comment on why a per-vCPU mapcache needs only a local flush from map_domain_page()'s TLB flush to mapcache_new_epoch()'s early return, as one line (Roger). Changes in v3: - HVM only, and per-vCPU from the start: the HVM enablement of "x86: Initialize the mapcache for PV, HVM, and idle domains" (from the directmap removal series) is folded in, without the idle domain and without a domain-wide HVM mapcache. - Retitle (was: "x86/mm: introduce a per-vCPU mapcache when using ASI"). - Say which second unmaps the not-present check in unmap_domain_page() catches: those of an entry the first unmap zapped. - State the budget of single-page mappings a vCPU can hold at once. - The mapcache accounting refactor, the move of struct mapcache_vcpu to struct arch_vcpu and the not-present check in unmap_domain_page() are split out, for review, into the three patches before this one. --- xen/arch/x86/domain_page.c | 61 +++++++++++++++++++++++-------- xen/arch/x86/include/asm/config.h | 2 + xen/arch/x86/include/asm/domain.h | 6 +++ 3 files changed, 53 insertions(+), 16 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 47ccefa4e9..770fee80a4 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -21,7 +21,7 @@ /* Whether the vCPU supports mapcache usage, might not be in use. */ static bool has_mapcache(const struct vcpu *v) { - return is_pv_vcpu(v); + return is_pv_vcpu(v) || v->domain->arch.asi.vcpu_pt; } static inline struct vcpu *mapcache_current_vcpu(void) @@ -34,10 +34,10 @@ static inline struct vcpu *mapcache_current_vcpu(void) return NULL; /* - * If we are in a lazy context-switch state from a PV vCPU do a full switch - * 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. + * If we are in a lazy context-switch state from a vCPU with a mapcache do + * a full switch to the idle vCPU now, otherwise an incoming + * FLUSH_VCPU_STATE IPI would change the page tables under our feet and + * invalidate any in-use mapcache entries. */ if ( unlikely(this_cpu(curr_vcpu) != curr) ) { @@ -57,14 +57,21 @@ static inline struct vcpu *mapcache_current_vcpu(void) } /* - * The accounting for v's mapcache: the domain's, with *dcache set so the - * caller takes the domain-wide lock and TLB-epoch machinery into account. + * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's + * otherwise, in which case *dcache is set so the caller takes the domain-wide + * lock and TLB-epoch machinery into account. */ static struct mapcache *vcpu_mapcache(struct vcpu *v, struct mapcache_domain **dcache) { struct domain *d = v->domain; + if ( d->arch.asi.vcpu_pt ) + { + *dcache = NULL; + return &v->arch.mapcache.cache; + } + *dcache = &d->arch.pv.mapcache; return &(*dcache)->cache; } @@ -72,6 +79,10 @@ static struct mapcache *vcpu_mapcache(struct vcpu *v, static void mapcache_enter(struct mapcache_domain *dcache, struct mapcache_vcpu *vcache) { + /* Only its own vCPU uses a per-vCPU mapcache: no lock or epoch needed. */ + if ( !dcache ) + return; + /* The domain's vCPUs share the mapcache's slots. */ spin_lock(&dcache->lock); @@ -91,6 +102,10 @@ static void mapcache_enter(struct mapcache_domain *dcache, static void mapcache_new_epoch(struct mapcache_domain *dcache, struct mapcache_vcpu *vcache) { + /* Per-vCPU: no epoch, as page-table loads flush its non-global entries. */ + if ( !dcache ) + return; + ASSERT(spin_is_locked(&dcache->lock)); vcache->shadow_epoch = ++dcache->epoch; @@ -99,7 +114,8 @@ static void mapcache_new_epoch(struct mapcache_domain *dcache, static void mapcache_exit(struct mapcache_domain *dcache) { - spin_unlock(&dcache->lock); + if ( dcache ) + spin_unlock(&dcache->lock); } #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) @@ -299,15 +315,25 @@ int mapcache_vcpu_init(struct vcpu *v) struct mapcache_domain *dcache; struct mapcache *cache; unsigned long i; - unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; - unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); + unsigned int ents, nr; if ( !has_mapcache(v) ) return 0; cache = vcpu_mapcache(v, &dcache); - if ( !cache->inuse ) + if ( !dcache ) + { + /* Per-vCPU bitmaps are an unsigned long each, in the vCPU itself. */ + cache->inuse = v->arch.mapcache.inuse; + cache->garbage = v->arch.mapcache.garbage; + ents = MAPCACHE_PERVCPU_ENTRIES; + } + else if ( !cache->inuse ) return 0; + else + ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; + + nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); if ( ents > cache->entries ) { @@ -315,13 +341,16 @@ int mapcache_vcpu_init(struct vcpu *v) int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, NIL(l1_pgentry_t *), NULL); - /* Populate bit maps. */ - if ( !rc ) + /* Populate the domain-wide bit maps (kept in the per-domain area). */ + if ( !rc && dcache ) + { rc = create_perdomain_mapping(v, (unsigned long)cache->inuse, nr, NULL, NIL(struct page_info *)); - if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, - nr, NULL, NIL(struct page_info *)); + if ( !rc ) + rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, + nr, NULL, + NIL(struct page_info *)); + } if ( rc ) return rc; diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index aebd3e8f45..ee84c57432 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -279,6 +279,8 @@ extern unsigned long xen_phys_start; /* map_domain_page() map cache. The second per-domain-mapping sub-area. */ #define MAPCACHE_VCPU_ENTRIES (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEVELS) +/* Single-page slots of a per-vCPU mapcache (vCPU-PT domains). */ +#define MAPCACHE_PERVCPU_ENTRIES 64 #define MAPCACHE_ENTRIES (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES) #define MAPCACHE_VIRT_START PERDOMAIN_VIRT_SLOT(1) #define MAPCACHE_VIRT_END (MAPCACHE_VIRT_START + \ diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 45d308407e..7076e38848 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -80,6 +80,12 @@ struct mapcache_vcpu { uint32_t idx; uint32_t refcnt; } hash[MAPHASH_ENTRIES]; + + /* Accounting of a per-vCPU mapcache (vCPU-PT domains). */ + struct mapcache cache; + /* Backing for cache.{inuse,garbage}. */ + DECLARE_BITMAP(inuse, MAPCACHE_PERVCPU_ENTRIES); + DECLARE_BITMAP(garbage, MAPCACHE_PERVCPU_ENTRIES); }; struct mapcache_domain { -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:30:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:30:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463804.1674711 (Exim 4.92) (envelope-from ) id 1xMD6g-0008SE-9A; Wed, 28 Oct 2026 23:30:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463804.1674711; Wed, 28 Oct 2026 23:30: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 1xMD6e-0008JZ-Ls; Wed, 28 Oct 2026 23:30:56 +0000 Received: by outflank-mailman (input) for mailman id 1463804; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049L-5k for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pQ7-0i5g; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjX-00000001KpM-3IGH; Wed, 28 Oct 2026 23:07: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" 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=bQTQV7c4xH1DcaQ6QmlFP76js9ObXYQ0pwdJXBivQ8g=; b=jxZK3cwaPxX8czQVDdQyVJ6zCO pe4h0ZaDpQfnXDi0QaZw8x/YKGjNvTK74GrKfchHP5wA20M5dDJz8Js92V+c3snhL+/scfuMh7cs3 GUyneg5CEzgWpKjwxuWbKVGnIDn64S4VA1MV//n1zuC9kaRNrzi2RgwXYHI6xgRSbI0c=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 26/45] x86/mm: introduce a per-vCPU state window in the perdomain area Date: Wed, 28 Oct 2026 23:05:40 +0000 Message-ID: <20261028-asi-hvm-v5-26-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Under Address Space Isolation, guest-owned register state that Xen keeps in always-mapped memory moves to the domain heap, mapped only in the contexts that use it. The long-lived per-vCPU structures involved (the SVM VMCB, the VMX guest MSR load/save list, the guest XSAVE area, and later the aggregated small per-vCPU allocations) all want the same shape: one or more domain-heap pages, mapped once at fixed per-vCPU virtual addresses for the life of the vCPU. Add a fourth per-domain-mapping sub-area providing that destination: a small per-vCPU stride of page slots, with a fixed index assigned to each relocated structure and the page tables created at vCPU creation time. Consumers allocate their own pages and install them with populate_perdomain_mapping(); the backing pages remain caller-owned, so their lifetime stays with the consumer, while the page tables are torn down with the rest of the per-domain area. Before freeing their pages, consumers take them out of the window with unmap_vcpu_state(), on failure paths as at teardown: vCPU creation can fail once a consumer has mapped its pages, and the domain lives on. It flushes the domain's dirty CPUs, which include every CPU whose page-tables carry the window, in the vCPU's own per-domain area or in the one its domain's vCPUs share; so far that mask is empty on every call, as the vCPU has not run or the domain is paused. A consumer reaching a page from another context, through a transient map_domain_page() mapping, drops the mapping with unmap_vcpu_state_page(), which also flushes this CPU's translations of it, there and at its alias in the per-domain mirror: a domain-wide mapcache defers that flush, and the translations would otherwise outlive the mapping. For a domain running without per-vCPU page tables the window has the same domain-wide visibility as the other per-domain sub-areas: the virtual addresses are keyed on vcpu_id, so the same VA arithmetic serves both modes. With vcpu-pt enabled, a vCPU's window is simply absent from its siblings' address spaces. This is infrastructure for moving the SVM VMCB, the VMX MSR load/save lists, the saved register frames, the HVM emulator's caches and the guest XSAVE areas off always-mapped memory. Nothing occupies the area yet; the only behavioural change is the page-table allocation itself and the failure path that comes with it: vCPU creation can now fail with -ENOMEM. Both apply to every guest vCPU, with or without asi=, PV ones included. A domain with per-vCPU page tables gets an L2 and an L1 per vCPU; any other domain, every PV domain among them, one L2 plus an L1 per 64 vCPUs: 2 pages for up to 64 vCPUs. A PV domain's window stays empty until the register frames and XSAVE areas move there. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Say that the PV register frames move into the window too, not only the XSAVE areas. - Message and comments: "per-domain area", and which vCPUs share it. Changes in v4: - New in this version. --- xen/arch/x86/domain.c | 12 ++++++++ xen/arch/x86/include/asm/config.h | 21 +++++++++++++- xen/arch/x86/include/asm/mm.h | 2 ++ xen/arch/x86/mm.c | 47 +++++++++++++++++++++++++++++++ 4 files changed, 81 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 7a4da203d4..3465124ea0 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -525,6 +525,18 @@ int arch_vcpu_create(struct vcpu *v) if ( rc ) goto fail; + BUILD_BUG_ON((MAX_VIRT_CPUS << VCPU_STATE_VA_SHIFT) > + (PERDOMAIN_SLOT_MBYTES << 20)); + BUILD_BUG_ON(VCPU_STATE_IDX_VMCB >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_N2VMCB >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_VMX_MSR >= VCPU_STATE_NR_PAGES); + /* Page tables only; torn down with the rest of the per-domain area. */ + rc = create_perdomain_mapping(v, VCPU_STATE_START(v), + VCPU_STATE_NR_PAGES, + NIL(l1_pgentry_t *), NULL); + if ( rc != 0 ) + goto fail; + paging_vcpu_init(v); if ( (rc = vcpu_init_fpu(v)) != 0 ) diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index ee84c57432..8a265e25c8 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -158,7 +158,7 @@ /* Slot 260: per-domain mappings (including map cache). */ #define PERDOMAIN_VIRT_START (PML4_ADDR(260)) #define PERDOMAIN_SLOT_MBYTES (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER)) -#define PERDOMAIN_SLOTS 3 +#define PERDOMAIN_SLOTS 4 #define PERDOMAIN_VIRT_SLOT(s) (PERDOMAIN_VIRT_START + (s) * \ (PERDOMAIN_SLOT_MBYTES << 20)) /* Slot 4: mirror of per-domain mappings (for compat xlat area accesses). */ @@ -293,6 +293,25 @@ extern unsigned long xen_phys_start; #define ARG_XLAT_START(v) \ (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT)) +/* + * Per-vCPU state window. The fourth per-domain-mapping sub-area: a small + * per-vCPU stride of page slots holding long-lived per-vCPU structures kept + * out of always-mapped memory, each mapped once for the life of the vCPU at + * a fixed index within the stride. + */ +#define VCPU_STATE_SLOT 3 +#define VCPU_STATE_VIRT_START PERDOMAIN_VIRT_SLOT(VCPU_STATE_SLOT) +#define VCPU_STATE_ORDER 3 +#define VCPU_STATE_NR_PAGES (1U << VCPU_STATE_ORDER) +#define VCPU_STATE_VA_SHIFT (VCPU_STATE_ORDER + PAGE_SHIFT) +#define VCPU_STATE_START(v) \ + (VCPU_STATE_VIRT_START + ((v)->vcpu_id << VCPU_STATE_VA_SHIFT)) +#define VCPU_STATE_ADDR(v, idx) \ + (VCPU_STATE_START(v) + (idx) * PAGE_SIZE) +#define VCPU_STATE_IDX_VMCB 0 +#define VCPU_STATE_IDX_N2VMCB 1 +#define VCPU_STATE_IDX_VMX_MSR 2 + #define ELFSIZE 64 #define ARCH_CRASH_SAVE_VMCOREINFO diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 6d50e17259..6eaea3ba01 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -625,6 +625,8 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int flags); void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr); +void unmap_vcpu_state(const struct vcpu *v, unsigned int idx, unsigned int nr); +void unmap_vcpu_state_page(const void *va); void free_perdomain_mappings(struct domain *d); void free_pervcpu_mappings(struct vcpu *v); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index b10cc03840..e6dd5aec67 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6669,6 +6669,53 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unmap_domain_page(l3tab); } +/* + * Take @nr slots of @v's state window, from @idx, out of the per-domain + * area, before the caller frees the pages behind them: the pages are the + * caller's own, and must not stay mapped once freed. The window's + * translations are usable only on CPUs whose page-tables carry it, all in + * the domain's dirty mask: with per-vCPU page-tables, the CPU running v or + * holding it lazily; otherwise, those of any of the domain's vCPUs. + */ +void unmap_vcpu_state(const struct vcpu *v, unsigned int idx, unsigned int nr) +{ + const struct domain *d = v->domain; + + /* + * Beyond the stride is the next vCPU's window, where the domain's vCPUs + * share a per-domain area. + */ + BUG_ON(idx >= VCPU_STATE_NR_PAGES || nr > VCPU_STATE_NR_PAGES - idx); + + destroy_perdomain_mapping(v, VCPU_STATE_ADDR(v, idx), nr); + + flush_tlb_mask(d->dirty_cpumask); +} + +/* + * Drop a transient mapping of a page behind a vCPU's state window, and this + * CPU's translations of it: at its address, and at its alias in the + * per-domain mirror, which every domain but a 64-bit PV one has (flushing + * that address there is harmless). A per-vCPU mapcache flushes both + * already, with the slot's last mapping; a domain-wide one defers the + * flush, and CPUs running other vCPUs of its domain may have cached the + * slot too. A directmap address, where the caller has no mapcache, needs + * nothing. + */ +void unmap_vcpu_state_page(const void *va) +{ + unsigned long addr = (unsigned long)va; + + unmap_domain_page(va); + + if ( addr < DIRECTMAP_VIRT_START ) + { + flush_tlb_one_local(addr); + flush_tlb_one_local(addr - PERDOMAIN_VIRT_START + + PERDOMAIN_ALT_VIRT_START); + } +} + static void free_perdomain_l3(struct page_info *l3pg) { l3_pgentry_t *l3tab = __map_domain_page(l3pg); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463805.1674722 (Exim 4.92) (envelope-from ) id 1xMD6j-0000b6-V4; Wed, 28 Oct 2026 23:31:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463805.1674722; Wed, 28 Oct 2026 23:31: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 1xMD6h-0000QG-CZ; Wed, 28 Oct 2026 23:30:59 +0000 Received: by outflank-mailman (input) for mailman id 1463805; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049Z-7f for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pQj-1RDH; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjQ-00000001KpM-0mv0; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=RVROnRhnJ2CS9YJZ5lc9Ti4SNS+seTPBJxsek/UlS70=; b=E2C824RUvzOBqrkoMBWaYPnIuv Z8bIlRD1Hs75E+rVQ0QoWelMblBRMVOnJ30G4DhrlqJsNqN2U0GMUmf5RGFN8djfzfuhSbOjiTibs l2ALy13d3Ar7XutefkhiHGNeYAY8BQX5N1GKyUtel/zp39KkYAgMJ2N4Nexcp2fxtQQQ=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 19/45] x86/domain_page: key the directmap fast paths on the loaded view Date: Wed, 28 Oct 2026 23:05:33 +0000 Message-ID: <20261028-asi-hvm-v5-19-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit map_domain_page() returns directmap addresses whenever it can: for any MFN the directmap covers in release builds, and for vCPUs without a mapcache. Once guest contexts may run on the sparse view of the directmap, modify this to take the fast path returning the directmap address only when the full directmap is loaded. The release-build shortcut ahead of the vCPU lookup looks at the vCPU whose page-tables are loaded, without completing a lazy context switch: if that vCPU is not on the sparse view, its page-tables map the page through the directmap, and completing the switch would only move the CPU to the idle vCPU's page-tables, which map it too. A vCPU on the sparse view always has a mapcache: HVM ones through per-vCPU page-tables, PV ones through the domain-wide mapcache, which mapcache_domain_init() now sets up for a domain using the sparse view in release builds too, rather than only when the directmap does not cover all memory. map_domain_page_global() mappings must be valid in every context: use vmap() for all of them once a sparse view is configured, as arch_mfns_in_directmap() then says. Add d->arch.asi.sparse_dmap for this; nothing sets it yet. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - d->arch.sparse_dmap is now a one-bit field of d->arch.asi, beside vcpu_pt. - Wrap a line that reached 80 columns. - Drop sparse_dmap_active: d->arch.asi.sparse_dmap alone says whether a domain's root page-tables carry the sparse view (Roger). Builds without CONFIG_SPARSE_DIRECTMAP compile the test out, as before. - Drop the second directmap check after the vCPU lookup: the !cache->inuse case covers it. Changes in v3: - New in this version. --- xen/arch/x86/domain_page.c | 34 ++++++++++++++++++++++++++++--- xen/arch/x86/include/asm/domain.h | 3 +++ 2 files changed, 34 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 770fee80a4..6b662706fb 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -56,6 +56,13 @@ static inline struct vcpu *mapcache_current_vcpu(void) return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } +/* Whether @v's page-tables carry the sparse view of the directmap. */ +static bool on_sparse_dmap(const struct vcpu *v) +{ + return IS_ENABLED(CONFIG_SPARSE_DIRECTMAP) && + v->domain->arch.asi.sparse_dmap; +} + /* * The accounting for v's mapcache: its own for a vCPU-PT domain, the domain's * otherwise, in which case *dcache is set so the caller takes the domain-wide @@ -135,9 +142,19 @@ void *map_domain_page(mfn_t mfn) #ifdef NDEBUG if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) - return mfn_to_virt(mfn_x(mfn)); + { + const struct vcpu *pt_vcpu = this_cpu(pgtable_vcpu); + + /* + * The page-tables loaded map @mfn through the directmap, unless they + * carry the sparse view. + */ + if ( !pt_vcpu || !on_sparse_dmap(pt_vcpu) ) + return mfn_to_virt(mfn_x(mfn)); + } #endif + /* No vCPU (early boot), or no mapcache: the full directmap is loaded. */ v = mapcache_current_vcpu(); if ( !v ) return mfn_to_virt(mfn_x(mfn)); @@ -145,7 +162,10 @@ void *map_domain_page(mfn_t mfn) cache = vcpu_mapcache(v, &dcache); vcache = &v->arch.mapcache; if ( !cache->inuse ) + { + ASSERT(!on_sparse_dmap(v)); return mfn_to_virt(mfn_x(mfn)); + } perfc_incr(map_domain_page_count); @@ -294,7 +314,11 @@ void mapcache_domain_init(struct domain *d) ASSERT(is_pv_domain(d)); #ifdef NDEBUG - if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) + /* + * Not needed when the directmap loaded for the domain covers everything. + */ + if ( !d->arch.asi.sparse_dmap && !mem_hotplug && + max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) return; #endif @@ -378,8 +402,12 @@ void *map_domain_page_global(mfn_t mfn) system_state < SYS_STATE_active) || local_irq_is_enabled())); + /* + * Global mappings must hold in every context: a sparse view of the + * directmap rules the directmap out. + */ #ifdef NDEBUG - if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) + if ( arch_mfns_in_directmap(mfn_x(mfn), 1) ) return mfn_to_virt(mfn_x(mfn)); #endif diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 7076e38848..f84ac15759 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -490,6 +490,9 @@ struct arch_domain struct { /* Give each vCPU its own per-domain area (HVM only). */ bool vcpu_pt:1; + + /* The domain's root page-tables carry the sparse directmap view. */ + bool sparse_dmap:1; } asi; /* Emulated devices enabled bitmap. */ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463808.1674729 (Exim 4.92) (envelope-from ) id 1xMD6m-00018q-Oi; Wed, 28 Oct 2026 23:31:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463808.1674729; Wed, 28 Oct 2026 23:31: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 1xMD6l-00011r-4E; Wed, 28 Oct 2026 23:31:03 +0000 Received: by outflank-mailman (input) for mailman id 1463808; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049n-AV for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pR4-1ilo; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjR-00000001KpM-0N6T; Wed, 28 Oct 2026 23:06: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" 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=r1VmGidvH1AZLdhk+0ig3hYGT6yhxdDnEfjoDf/SEiU=; b=Q5L/hQLSCpwqonLvRv01T1zLtb zzi/cw0xEH70Rj4XDP0jwHnltt4uz9W6TqUxzAzv4suzEtfFsgwkom40v/MvFkbNVDmLtb6wsJ/Q8 Aoki/X2pFu2PQ1V3KJS1sR9vOzgMSL9G0ilYD1iA0+n/vh7b34y9PJAb1QSQP24ATafs=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 20/45] x86/domain_page: clear a mapcache slot at its last unmap Date: Wed, 28 Oct 2026 23:05:34 +0000 Message-ID: <20261028-asi-hvm-v5-20-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit unmap_domain_page() keeps a recently unmapped slot in the vCPU's maphash (MAPHASH_ENTRIES, 8 per vCPU) for a quick remap of the same MFN, and leaves its PTE in place until the entry is displaced by a later unmap or reclaimed by a full cache. Until then the page stays mapped, although nothing refers to the mapping and the mapcache holds no reference to the page. Where the mapcache clears a slot's PTE, it defers the flush: the slot's translation can stay in the TLB of the CPU which used it until that CPU next flushes. While the full directmap is loaded, that reaches nothing it does not map anyway. On the sparse view of the directmap, Xen reaches domain-heap memory only through mappings made for the purpose. A mapping or a translation left behind keeps the page reachable after its last unmap: while Xen serves another of the guest's contexts on the same vCPU, and, once the page is freed and handed to another domain, from a context which has nothing to do with it. So clear a slot's PTE when its last reference goes, maphash slots included: the hash entry keeps the slot, not the mapping, and a later hit maps the page again in the same slot. The slot has mapped nothing else in between, so that needs no flush. Reusing the slot for another page still goes through the garbage map, or through the replacement of a hash entry when the cache is full, both of which flush first. In a per-vCPU mapcache, as vCPU-PT domains have, also invalidate the slot's translation on the local CPU, right after clearing the PTE. The slot has a second address, in the mirror of the per-domain area that every domain but a 64-bit PV one gets for the compat argument translation area, and its translation is invalidated too: two INVLPGs. That leaves no translation on any CPU, as the vCPU's page-tables are loaded on one CPU at a time, and a CPU loading other page-tables (switch_cr3_cr4()) flushes non-global translations, the mapcache's included. A PV domain's domain-wide mapcache has its PTEs cleared but no INVLPG, as CPUs running the domain's other vCPUs may hold the slot's translation too, which a local INVLPG would not reach. For it, as before, builds with PV support flush a page freed by its owner from TLBs before the page is handed out again. The cost is one PTE write per unmap into the maphash and per remap from it, and in a per-vCPU mapcache two INVLPGs per slot's last unmap. A second unmap of an entry in the maphash now finds its PTE not present and is caught by the check unmap_domain_page() has for entries the first unmap zapped, rather than by the reference count's ASSERT() in debug builds only. The change does not depend on asi= or on a sparse view of the directmap being configured: PV vCPUs use the domain-wide mapcache on the default command line too. For them it adds the PTE writes above, and leaves up to MAPHASH_ENTRIES fewer pages per vCPU mapped in the domain-wide mapcache. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Merge v3's 15/18 ("x86/mm: flush owned pages before reuse with the sparse directmap view") and 16/18 ("x86/domain_page: keep the maphash's slots, not their mappings"). Rather than flush pages freed by their owner before reuse wherever a sparse view is configured, invalidate a per-vCPU mapcache slot's translations on the local CPU right after its PTE is cleared (Roger). - Message: don't restate when PV vCPUs use the mapcache (Roger). Changes in v3: - New in this version. For reviewers: with a slot cleared and invalidated at its last unmap, a per-vCPU mapcache's maphash saves only the search for a free slot, and a second slot for a page mapped twice at once. One page in two slots is fine, and already happens when it is not in the maphash. So per-vCPU mapcaches could drop the maphash, and with it their garbage map and wrap-time flush; that is left for a follow-up. --- xen/arch/x86/domain_page.c | 53 +++++++++++++++++++++++++------ xen/arch/x86/include/asm/domain.h | 5 ++- 2 files changed, 48 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 6b662706fb..4198ee7c18 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -130,6 +130,26 @@ static void mapcache_exit(struct mapcache_domain *dcache) #define MAPCACHE_L1ENT(idx) \ __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + pfn_to_paddr(idx))] +/* + * Clear a slot's PTE. For a per-vCPU mapcache (HVM domains only), then also + * drop the slot's translations from this CPU's TLB, at its address and at its + * alias in the per-domain mirror, which every HVM domain has. No other CPU + * can hold them: the vCPU's page-tables are loaded on one CPU at a time, and + * loading other page-tables flushes non-global translations. + */ +static void mapcache_zap(const struct mapcache_domain *dcache, + unsigned int idx) +{ + unsigned long va = MAPCACHE_VIRT_START + pfn_to_paddr(idx); + + l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); + if ( dcache ) + return; + + flush_tlb_one_local(va); + flush_tlb_one_local(va - PERDOMAIN_VIRT_START + PERDOMAIN_ALT_VIRT_START); +} + void *map_domain_page(mfn_t mfn) { unsigned long flags; @@ -176,6 +196,14 @@ void *map_domain_page(mfn_t mfn) { idx = hashent->idx; ASSERT(idx < cache->entries); + /* + * An entry the maphash kept holds on to its slot, not to its mapping + * (see unmap_domain_page()): map the page again. No flush is needed, + * as the slot has mapped nothing else since. + */ + if ( !hashent->refcnt ) + l1e_write(&MAPCACHE_L1ENT(idx), + l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW)); hashent->refcnt++; ASSERT(hashent->refcnt); ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn)); @@ -208,8 +236,8 @@ void *map_domain_page(mfn_t mfn) if ( hashent->idx != MAPHASHENT_NOTINUSE && !hashent->refcnt ) { idx = hashent->idx; - ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) == hashent->mfn); - l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); + ASSERT(!(l1e_get_flags(MAPCACHE_L1ENT(idx)) & + _PAGE_PRESENT)); hashent->idx = MAPHASHENT_NOTINUSE; hashent->mfn = ~0UL; break; @@ -273,32 +301,39 @@ void unmap_domain_page(const void *ptr) local_irq_save(flags); + /* + * The maphash keeps a freed slot, not its mapping: the page may change + * hands meanwhile. A domain-wide mapcache's translation left in a TLB + * is covered by the flush the allocator makes before reusing an owned + * page. + */ if ( hashent->idx == idx ) { ASSERT(hashent->mfn == mfn); ASSERT(hashent->refcnt); hashent->refcnt--; + if ( !hashent->refcnt ) + mapcache_zap(dcache, idx); } else if ( !hashent->refcnt ) { + /* The entry replaced has no mapping left: mark its slot as garbage. */ if ( hashent->idx != MAPHASHENT_NOTINUSE ) { - /* /First/, zap the PTE. */ - ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(hashent->idx)) == - hashent->mfn); - l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty()); - /* /Second/, mark as garbage. */ + ASSERT(!(l1e_get_flags(MAPCACHE_L1ENT(hashent->idx)) & + _PAGE_PRESENT)); set_bit(hashent->idx, cache->garbage); } - /* Add newly-freed mapping to the maphash. */ + /* Add the newly-freed slot to the maphash, without its mapping. */ + mapcache_zap(dcache, idx); hashent->mfn = mfn; hashent->idx = idx; } else { /* /First/, zap the PTE. */ - l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); + mapcache_zap(dcache, idx); /* /Second/, mark as garbage. */ set_bit(idx, cache->garbage); } diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index f84ac15759..0e405157b4 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -74,7 +74,10 @@ struct mapcache_vcpu { /* Shadow of mapcache_domain.epoch. */ unsigned int shadow_epoch; - /* Lock-free per-VCPU hash of recently-used mappings. */ + /* + * Lock-free per-VCPU hash of recently-used mappings. An entry without + * references keeps its slot but not its mapping (see unmap_domain_page()). + */ struct vcpu_maphash_entry { unsigned long mfn; uint32_t idx; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463807.1674738 (Exim 4.92) (envelope-from ) id 1xMD6o-0001ZD-LE; Wed, 28 Oct 2026 23:31:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463807.1674738; Wed, 28 Oct 2026 23: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 1xMD6n-0001Tf-27; Wed, 28 Oct 2026 23:31:05 +0000 Received: by outflank-mailman (input) for mailman id 1463807; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049u-CH for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pRA-1sep; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjd-00000001KpM-0j5A; Wed, 28 Oct 2026 23:07: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=0lX6CHwDNVccQVi6T81X3E5uhExKP3Yedzo3WsWaf6A=; b=bQqAc85oOR3S5KGZydKsY0Ybrv 7KVwE8AEPEs9azELoBWt/EhoUMefEjbxQj9d9zqBMXRBMRjmlzjoHcdGkrB8SXuDghAYgsbIrDSZU yBU4JM3cE0KsjZ9KA/QrXTaIAIqfjKYELc42JlZR/mJYAXC8zvrhYqjHkkDejeQgzDcQ=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 31/45] x86/vmx: move the guest MSR load/save list off always-mapped memory Date: Wed, 28 Oct 2026 23:05:45 +0000 Message-ID: <20261028-asi-hvm-v5-31-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The guest MSR load/save list holds guest MSR values (SPEC_CTRL, LBR, PT, vPMU global control, and EFER on hardware without dedicated controls), but lives on the xenheap, where it stays reachable from every context. Move the page to the domain heap and map it at its fixed slot in the owning vCPU's state window, so that under Address Space Isolation it is only mapped while that vCPU's page tables are loaded. Hardware is unaffected: the VMCS MSR-area pointers hold the physical address, now derived from the page rather than from virt_to_maddr() on a directmap VA. The host MSR load list is left on the xenheap: it holds Xen's own exit-time values, not guest data, so relocating it would serve no isolation purpose. The window VA is only valid in the owning vCPU's context. Almost all accesses have v == current and keep going through vmx->msr_area unchanged (the vmentry-path LBR fixups, the failed-vmentry dump, vPMU, and the MSR intercepts). The remote accessors -- vmx_add_msr() / vmx_del_msr() from vCPU construction, policy updates and context load, and single-entry reads/writes from the HVM context save/load and get/set-reg paths, all of which already require the target vCPU to be paused -- dispatch through a transient mapping of the page, dropped with unmap_vcpu_state_page(), which also drops this CPU's translations of it: * vmx_add_msr() and vmx_del_msr() map internally around their search/insert/remove. * vmx_read_guest_msr(), vmx_read_guest_loadonly_msr() and vmx_write_guest_msr() move out of line and do the same, via vmx_find_msr_in(), the existing lookup parameterised on the mapped area. vmx_find_msr() itself is unchanged for its remaining callers, which all run in current context and dereference the returned pointer through the window. vmx_destroy_vmcs() takes the page out of the window before freeing it, with unmap_vcpu_state(): without per-vCPU page tables the window is in the per-domain area that all its domain's vCPUs share, which outlives a vCPU whose creation fails. The new page pointer goes with the existing page_info pointers after pi_desc rather than next to msr_area: struct pi_desc is 64-byte aligned, so inserting eight bytes ahead of it would have added 56 bytes of padding, growing struct vmx_vcpu from 448 to 512 bytes and, via the union in struct arch_vcpu, every struct vcpu by 64 bytes (x86_64 defconfig). Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Map and unmap through VMX_MAP_MSR_AREA() and VMX_UNMAP_MSR_AREA(), which clears the pointer (George). Changes in v4: - New in this version. --- xen/arch/x86/hvm/vmx/vmcs.c | 142 ++++++++++++++++++++++-- xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 63 +++-------- 2 files changed, 147 insertions(+), 58 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 8ec7ae7403..592722f1ca 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -1416,8 +1416,11 @@ static struct vmx_msr_entry *locate_msr_entry( return start; } -struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, - enum vmx_msr_list_type type) +/* As vmx_find_msr(), but reaching the guest MSR area through @area. */ +static struct vmx_msr_entry *vmx_find_msr_in(const struct vcpu *v, + struct vmx_msr_entry *area, + uint32_t msr, + enum vmx_msr_list_type type) { const struct vmx_vcpu *vmx = &v->arch.hvm.vmx; struct vmx_msr_entry *start = NULL, *ent, *end; @@ -1435,11 +1438,11 @@ struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, break; case VMX_MSR_GUEST: - start = vmx->msr_area; + start = area; break; case VMX_MSR_GUEST_LOADONLY: - start = vmx->msr_area; + start = area; substart = subend; subend = total; break; @@ -1458,6 +1461,77 @@ struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, return ((ent < end) && (ent->index == msr)) ? ent : NULL; } +struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, + enum vmx_msr_list_type type) +{ + ASSERT(v == current || type == VMX_MSR_HOST); + + return vmx_find_msr_in(v, v->arch.hvm.vmx.msr_area, msr, type); +} + +static struct vmx_msr_entry *vmx_msr_area_map(const struct vcpu *v) +{ + const struct vmx_vcpu *vmx = &v->arch.hvm.vmx; + + if ( v == current || !vmx->msr_area ) + return vmx->msr_area; + + return map_domain_page(page_to_mfn(vmx->msr_area_pg)); +} + +static void vmx_msr_area_unmap(const struct vcpu *v, + const struct vmx_msr_entry *area) +{ + if ( v != current && area ) + unmap_vcpu_state_page(area); +} + +#define VMX_MAP_MSR_AREA(v) vmx_msr_area_map(v) + +/* Drops the mapping of a guest MSR area and nullifies its pointer. */ +#define VMX_UNMAP_MSR_AREA(v, area) do { \ + vmx_msr_area_unmap(v, area); \ + (area) = NULL; \ +} while ( false ) + +int vmx_read_guest_msr(const struct vcpu *v, uint32_t msr, uint64_t *val) +{ + struct vmx_msr_entry *area = VMX_MAP_MSR_AREA(v); + const struct vmx_msr_entry *ent = + area ? vmx_find_msr_in(v, area, msr, VMX_MSR_GUEST) : NULL; + + *val = ent ? ent->data : 0; + VMX_UNMAP_MSR_AREA(v, area); + + return ent ? 0 : -ESRCH; +} + +int vmx_read_guest_loadonly_msr(const struct vcpu *v, uint32_t msr, + uint64_t *val) +{ + struct vmx_msr_entry *area = VMX_MAP_MSR_AREA(v); + const struct vmx_msr_entry *ent = + area ? vmx_find_msr_in(v, area, msr, VMX_MSR_GUEST_LOADONLY) : NULL; + + *val = ent ? ent->data : 0; + VMX_UNMAP_MSR_AREA(v, area); + + return ent ? 0 : -ESRCH; +} + +int vmx_write_guest_msr(struct vcpu *v, uint32_t msr, uint64_t val) +{ + struct vmx_msr_entry *area = VMX_MAP_MSR_AREA(v); + struct vmx_msr_entry *ent = + area ? vmx_find_msr_in(v, area, msr, VMX_MSR_GUEST) : NULL; + + if ( ent ) + ent->data = val; + VMX_UNMAP_MSR_AREA(v, area); + + return ent ? 0 : -ESRCH; +} + int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, enum vmx_msr_list_type type) { @@ -1503,13 +1577,38 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, { paddr_t addr; - if ( (*ptr = alloc_xenheap_page()) == NULL ) + if ( type == VMX_MSR_HOST ) { - rc = -ENOMEM; - goto out; + if ( (*ptr = alloc_xenheap_page()) == NULL ) + { + rc = -ENOMEM; + goto out; + } + + addr = virt_to_maddr(*ptr); } + else + { + struct page_info *pg = alloc_domheap_page(v->domain, + MEMF_no_owner); + mfn_t mfn; - addr = virt_to_maddr(*ptr); + if ( pg == NULL ) + { + rc = -ENOMEM; + goto out; + } + + mfn = page_to_mfn(pg); + clear_domain_page(mfn); + populate_perdomain_mapping(v, + VCPU_STATE_ADDR(v, + VCPU_STATE_IDX_VMX_MSR), + &mfn, 1, __PAGE_HYPERVISOR_RW); + vmx->msr_area_pg = pg; + *ptr = (void *)VCPU_STATE_ADDR(v, VCPU_STATE_IDX_VMX_MSR); + addr = mfn_to_maddr(mfn); + } switch ( type ) { @@ -1525,7 +1624,7 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, } } - start = *ptr; + start = type == VMX_MSR_HOST ? *ptr : VMX_MAP_MSR_AREA(v); end = start + total; ent = locate_msr_entry(start + substart, start + subend, msr); @@ -1565,6 +1664,8 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t val, rc = 0; out: + if ( type != VMX_MSR_HOST ) + VMX_UNMAP_MSR_AREA(v, start); vmx_vmcs_exit(v); return rc; @@ -1576,6 +1677,7 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) struct vmx_msr_entry *start = NULL, *ent, *end; unsigned int substart = 0, subend = vmx->msr_save_count; unsigned int total = vmx->msr_load_count; + int rc = 0; ASSERT(v == current || !vcpu_runnable(v)); @@ -1605,11 +1707,17 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) if ( !start ) return -ESRCH; + if ( type != VMX_MSR_HOST ) + start = VMX_MAP_MSR_AREA(v); + end = start + total; ent = locate_msr_entry(start + substart, start + subend, msr); if ( (ent == end) || (ent->index != msr) ) - return -ESRCH; + { + rc = -ESRCH; + goto out; + } memmove(ent, ent + 1, sizeof(*ent) * (end - ent - 1)); @@ -1632,7 +1740,11 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) vmx_vmcs_exit(v); - return 0; + out: + if ( type != VMX_MSR_HOST ) + VMX_UNMAP_MSR_AREA(v, start); + + return rc; } void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector) @@ -1829,7 +1941,13 @@ void vmx_destroy_vmcs(struct vcpu *v) vmx_free_vmcs(vmx->vmcs_pa); free_xenheap_page(v->arch.hvm.vmx.host_msr_area); - free_xenheap_page(v->arch.hvm.vmx.msr_area); + if ( v->arch.hvm.vmx.msr_area_pg ) + { + unmap_vcpu_state(v, VCPU_STATE_IDX_VMX_MSR, 1); + free_domheap_page(v->arch.hvm.vmx.msr_area_pg); + v->arch.hvm.vmx.msr_area_pg = NULL; + v->arch.hvm.vmx.msr_area = NULL; + } free_xenheap_page(v->arch.hvm.vmx.msr_bitmap); } diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h index d0716e97d2..e5730780e2 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h @@ -140,6 +140,10 @@ struct vmx_vcpu { * context. However, the data can be modified by toolstack/migration * actions. Remote access is only permitted for paused vcpus, and is * protected under the domctl lock. + * + * The guest list is a domain-heap page (msr_area_pg, below) mapped at a + * fixed slot in the owning vCPU's state window: msr_area holds that + * window VA, which is only valid in the owning vCPU's context. */ struct vmx_msr_entry *msr_area; struct vmx_msr_entry *host_msr_area; @@ -185,6 +189,9 @@ struct vmx_vcpu { struct page_info *pml_pg; + /* Backing page of msr_area; see the comment there. */ + struct page_info *msr_area_pg; + /* Bitmask of trapped CR4 bits. */ unsigned long cr4_host_mask; @@ -669,55 +676,19 @@ static inline int vmx_add_host_load_msr(struct vcpu *v, uint32_t msr, return vmx_add_msr(v, msr, val, VMX_MSR_HOST); } +/* + * Look an MSR up in the guest or host list of @v. The returned pointer + * reaches the guest lists through the vCPU state window, so for those it + * is only valid (and the call only permitted) in current context; the + * single-entry accessors below handle paused remote vCPUs. + */ struct vmx_msr_entry *vmx_find_msr(const struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type); -static inline int vmx_read_guest_msr(const struct vcpu *v, uint32_t msr, - uint64_t *val) -{ - const struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST); - - if ( !ent ) - { - *val = 0; - return -ESRCH; - } - - *val = ent->data; - - return 0; -} - -static inline int vmx_read_guest_loadonly_msr( - const struct vcpu *v, uint32_t msr, uint64_t *val) -{ - const struct vmx_msr_entry *ent = - vmx_find_msr(v, msr, VMX_MSR_GUEST_LOADONLY); - - if ( !ent ) - { - *val = 0; - return -ESRCH; - } - - *val = ent->data; - - return 0; -} - -static inline int vmx_write_guest_msr(struct vcpu *v, uint32_t msr, - uint64_t val) -{ - struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST); - - if ( !ent ) - return -ESRCH; - - ent->data = val; - - return 0; -} - +int vmx_read_guest_msr(const struct vcpu *v, uint32_t msr, uint64_t *val); +int vmx_read_guest_loadonly_msr(const struct vcpu *v, uint32_t msr, + uint64_t *val); +int vmx_write_guest_msr(struct vcpu *v, uint32_t msr, uint64_t val); /* MSR intercept bitmap infrastructure. */ enum vmx_msr_intercept_type { -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463806.1674749 (Exim 4.92) (envelope-from ) id 1xMD6r-000277-5F; Wed, 28 Oct 2026 23:31:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463806.1674749; Wed, 28 Oct 2026 23: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 1xMD6p-000209-JY; Wed, 28 Oct 2026 23:31:07 +0000 Received: by outflank-mailman (input) for mailman id 1463806; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-00049m-9r for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pQs-1aHH; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCji-00000001KpM-0cW6; Wed, 28 Oct 2026 23:07: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=7+SfUGkgBYMN0fY336uRRwse3Bcl2E3YDqRetUP0NXs=; b=oNClwR3QfY5jjFZbB/6OJx/3AR wF/nDfGiph18juJTprE26VvtnNekzmVLqd+4Vn7yzcW1HBcJ6OpAiDhaKK8khriIqdmzjiH+W9tqg wEGtamMT2/I0SqVf5U2srqeV9M8+LFXrp0jm71w9ixyKpVY67VzY5QjGdwIKpOK3JygM=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Teddy Astie Subject: [PATCH v5 36/45] x86/domain_page: introduce map_domain_pages() Date: Wed, 28 Oct 2026 23:05:50 +0000 Message-ID: <20261028-asi-hvm-v5-36-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit map_domain_page() maps a single page, so callers needing a virtually contiguous mapping of several (not necessarily physically contiguous) frames have had to fall back to vmap(), which maps whatever the frames hold in every context, those of domains on the sparse directmap view included, for the lifetime of the mapping. Provide a multipage counterpart which maps them in the calling vCPU's per-domain area instead, which only its domain's page tables carry: map_domain_pages(mfn, nr) / unmap_domain_pages(ptr, nr) Each vCPU has MAPCACHE_MULTIPAGE_ENTRIES slots of its own for such mappings. With per-vCPU page tables, they are just above the vCPU's single-page mapcache. Where a domain's vCPUs share one per-domain area, they are at the end of the mapcache sub-area, where each vCPU has a fixed block of its own. No single-page mapcache is needed: the multipage slots are in the same VA range whether or not the domain has one. The mappings are order-aligned and tracked in a per-vCPU bitmap, and bypass the maphash and the deferred garbage/epoch machinery. At unmap a mapping's PTEs are cleared, and a local flush done. Since each vCPU has its own slots, even with a domain-wide L3, the local flush suffices for correctness: even if a stray TLB entry is speculatively loaded on another processor, no other vCPU will use that mapping, and it will be flushed before the vCPU which owns the slots runs on that CPU. With regard to exposure: in a domain whose vCPUs share one per-domain area, other vCPUs may be able to reach the mapping speculatively while it exists, and afterwards through a stale TLB entry until their CPU next flushes. For guests on the full directmap, this doesn't expose anything new, as the page is already mapped in the directmap anyway (unless it's a PV domain and the page is past the short directmap). For PV guests on the sparse directmap view, it's still an improvement over the status quo, as exposure is limited to the domain, rather than the whole system (as in the case of vmap). An unmap will BUG() when given a pointer or a @nr which indexes outside the vCPU's slots, unless that pointer is in the vmap area (see below). These slots are not available before the first page-table switch in boot, nor with the idle vCPU's page tables loaded. Currently no calls are made during boot, and the only known way to reach map_domain_pages() with the idle page tables loaded is on an error path that will already ultimately crash the host. Nonetheless, for robustness, if called from a context where no mapping is available, it will fall back to using vmap(); and unmap recognizes such an address and vunmap()'s it. This briefly exposes contents to every context, and requires a system-wide TLB shootdown on unmap, but allows execution to continue. The alternative would be to BUG() in such a context. For those who want stricter isolation guarantees, at the risk that more situations might come up in the future, a new sub-option, asi=vmap-strict, off by default, makes the fallback a BUG() instead. The first fallback is logged. The handling of a lazy context switch in mapcache_current_vcpu() moves into pgtable_current_vcpu(), which map_domain_pages() uses whatever the domain: an IPI can switch away page tables held lazily at any time. Eight slots hold the largest mapping a known caller needs, a three-page XSAVE area (four slots, order 2), with room for a two-page mapping beside it. Where a domain's vCPUs share one per-domain area, the multipage area takes 256MiB of address space for MAX_VIRT_CPUS, and one L1 table per 64 vCPUs. Later patches convert the two known in-tree consumers. Moving the XSAVE areas off always-mapped memory needs the primitive too: the XSAVE area exceeds one page on AMX-class hardware, and XSAVE/XRSTOR require it to be virtually contiguous. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. --- docs/misc/xen-command-line.pandoc | 10 +- xen/arch/x86/domain_page.c | 171 +++++++++++++++++++++++++-- xen/arch/x86/include/asm/config.h | 14 +++ xen/arch/x86/include/asm/domain.h | 3 + xen/arch/x86/include/asm/spec_ctrl.h | 1 + xen/arch/x86/spec_ctrl.c | 7 ++ xen/include/xen/domain_page.h | 21 ++++ 7 files changed, 216 insertions(+), 11 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 092c858f34..52e10eb393 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -203,7 +203,7 @@ to appropriate auditing by Xen. Argo is disabled by default. buggy or malicious other domain spamming the ring. ### asi (x86) -> `= List of [ , {pv,hvm,dom0}=, directmap=, +> `= List of [ , {pv,hvm,dom0}=, {directmap,vmap-strict}=, > vcpu-pt= | vcpu-pt=hvm= ]` > Default: `false` @@ -245,6 +245,14 @@ are meant to be used for debugging purposes only.** and `dom0=`) set this too, on builds that support it; on other builds they leave it off. +* `vmap-strict` crashes the host when a multipage transient mapping + (`map_domain_pages()`) is requested where the loaded page-tables + have no slots for one: in early boot, or on the idle vCPU's + page-tables. By default such a mapping falls back to `vmap()`, + which maps the pages in every context. The first such mapping is + logged. The option is for hosts where a crash is preferable to such + a mapping; none is known to be made in normal operation. + ### asid (x86) > `= ` diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 4198ee7c18..8e5ef4a34a 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -6,6 +6,7 @@ * Copyright (c) 2003-2006, Keir Fraser */ +#include #include #include #include @@ -17,6 +18,7 @@ #include #include #include +#include /* Whether the vCPU supports mapcache usage, might not be in use. */ static bool has_mapcache(const struct vcpu *v) @@ -24,20 +26,22 @@ static bool has_mapcache(const struct vcpu *v) return is_pv_vcpu(v) || v->domain->arch.asi.vcpu_pt; } -static inline struct vcpu *mapcache_current_vcpu(void) +/* + * The vCPU whose page tables are loaded here, and stay loaded until the + * caller is done with what it maps in them. + */ +static struct vcpu *pgtable_current_vcpu(void) { - const struct vcpu *v = this_cpu(pgtable_vcpu); const struct vcpu *curr = current; /* During early boot pgtable_vcpu is not set, callers must handle NULL. */ - if ( !v || !has_mapcache(v) ) + if ( !this_cpu(pgtable_vcpu) ) return NULL; /* - * If we are in a lazy context-switch state from a vCPU with a mapcache do - * a full switch to the idle vCPU now, otherwise an incoming - * FLUSH_VCPU_STATE IPI would change the page tables under our feet and - * invalidate any in-use mapcache entries. + * If we are in a lazy context-switch state do a full switch to the idle + * vCPU now, otherwise an incoming FLUSH_VCPU_STATE IPI would change the + * page tables under our feet and invalidate any in-use mappings in them. */ if ( unlikely(this_cpu(curr_vcpu) != curr) ) { @@ -56,6 +60,17 @@ static inline struct vcpu *mapcache_current_vcpu(void) return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } +static inline struct vcpu *mapcache_current_vcpu(void) +{ + const struct vcpu *v = this_cpu(pgtable_vcpu); + + /* During early boot pgtable_vcpu is not set, callers must handle NULL. */ + if ( !v || !has_mapcache(v) ) + return NULL; + + return pgtable_current_vcpu(); +} + /* Whether @v's page-tables carry the sparse view of the directmap. */ static bool on_sparse_dmap(const struct vcpu *v) { @@ -341,6 +356,124 @@ void unmap_domain_page(const void *ptr) local_irq_restore(flags); } +/* + * The mapcache index of @v's first map_domain_pages() slot: above the + * single-page slots of its own mapcache with per-vCPU page tables, otherwise + * at its stride of the domain-wide multipage area. + */ +static unsigned int multipage_first_slot(const struct vcpu *v) +{ + if ( v->domain->arch.asi.vcpu_pt ) + return MAPCACHE_PERVCPU_ENTRIES; + + return PFN_DOWN(MAPCACHE_MULTIPAGE_START(v) - MAPCACHE_VIRT_START); +} + +/* + * Multipage mappings come from slots of the vCPU whose page tables are + * loaded, which no other vCPU uses, and bypass the maphash and the + * garbage/epoch machinery: at unmap a mapping's PTEs are zapped, and their + * translations dropped from this CPU's TLB, at their addresses and at their + * aliases in the per-domain mirror. + */ +void *map_domain_pages(const mfn_t *mfn, unsigned int nr) +{ + unsigned long flags; + unsigned int i, first; + struct vcpu *v; + int idx; + + if ( !nr || nr > MAPCACHE_MULTIPAGE_ENTRIES ) + { + ASSERT_UNREACHABLE(); + return NULL; + } + + if ( nr == 1 ) + return map_domain_page(mfn[0]); + + /* Early boot, or the idle vCPU's page tables: no multipage slots. */ + v = pgtable_current_vcpu(); + if ( !v || is_idle_vcpu(v) ) + { + BUG_ON(opt_vmap_strict); + printk_once(XENLOG_WARNING + "%pS: map_domain_pages() falling back to vmap()\n", + __builtin_return_address(0)); + return vmap(mfn, nr); + } + + first = multipage_first_slot(v); + + local_irq_save(flags); + + idx = bitmap_find_free_region(&v->arch.mapcache.multipage_inuse, + MAPCACHE_MULTIPAGE_ENTRIES, + get_order_from_pages(nr)); + if ( idx >= 0 ) + for ( i = 0; i < nr; i++ ) + l1e_write(&MAPCACHE_L1ENT(first + idx + i), + l1e_from_mfn(mfn[i], __PAGE_HYPERVISOR_RW)); + + local_irq_restore(flags); + + if ( idx < 0 ) + return NULL; + + return (void *)MAPCACHE_VIRT_START + pfn_to_paddr(first + idx); +} + +void unmap_domain_pages(const void *ptr, unsigned int nr) +{ + unsigned long va = (unsigned long)ptr & PAGE_MASK; + unsigned long flags, slot; + unsigned int idx, first, i; + struct vcpu *v; + + BUG_ON(!nr); + + if ( nr == 1 ) + { + unmap_domain_page(ptr); + return; + } + + if ( va >= VMAP_VIRT_START && va < VMAP_VIRT_END ) + { + vunmap((void *)va); + return; + } + + v = pgtable_current_vcpu(); + BUG_ON(!v || is_idle_vcpu(v) || va < MAPCACHE_VIRT_START); + + first = multipage_first_slot(v); + slot = PFN_DOWN(va - MAPCACHE_VIRT_START); + BUG_ON(slot < first || slot - first >= MAPCACHE_MULTIPAGE_ENTRIES); + + idx = slot - first; + BUG_ON(nr > MAPCACHE_MULTIPAGE_ENTRIES - idx); + + local_irq_save(flags); + + for ( i = 0; i < nr; i++ ) + { + unsigned long addr = va + i * PAGE_SIZE; + + ASSERT(l1e_get_flags(MAPCACHE_L1ENT(slot + i)) & _PAGE_PRESENT); + l1e_write(&MAPCACHE_L1ENT(slot + i), l1e_empty()); + flush_tlb_one_local(addr); + if ( !is_pv_64bit_vcpu(v) ) + flush_tlb_one_local(addr - PERDOMAIN_VIRT_START + + PERDOMAIN_ALT_VIRT_START); + } + + bitmap_release_region(&v->arch.mapcache.multipage_inuse, idx, + get_order_from_pages(nr)); + + local_irq_restore(flags); +} + void mapcache_domain_init(struct domain *d) { struct mapcache_domain *dcache = &d->arch.pv.mapcache; @@ -359,7 +492,7 @@ void mapcache_domain_init(struct domain *d) BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 + 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long))) > - MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20)); + MAPCACHE_MULTIPAGE_VIRT_START); bitmap_pages = PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)); dcache->cache.inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE; dcache->cache.garbage = dcache->cache.inuse + @@ -376,12 +509,28 @@ int mapcache_vcpu_init(struct vcpu *v) unsigned long i; unsigned int ents, nr; + BUILD_BUG_ON(MAPCACHE_MULTIPAGE_ENTRIES > BITS_PER_LONG); + + /* Without per-vCPU page tables, the vCPU's stride of the multipage area. */ + if ( !is_idle_domain(d) && !d->arch.asi.vcpu_pt ) + { + int rc = create_perdomain_mapping(v, MAPCACHE_MULTIPAGE_START(v), + MAPCACHE_MULTIPAGE_ENTRIES, + NIL(l1_pgentry_t *), NULL); + + if ( rc ) + return rc; + } + if ( !has_mapcache(v) ) return 0; cache = vcpu_mapcache(v, &dcache); if ( !dcache ) { + BUILD_BUG_ON(MAPCACHE_PERVCPU_ENTRIES + MAPCACHE_MULTIPAGE_ENTRIES > + MAPCACHE_ENTRIES); + /* Per-vCPU bitmaps are an unsigned long each, in the vCPU itself. */ cache->inuse = v->arch.mapcache.inuse; cache->garbage = v->arch.mapcache.garbage; @@ -396,8 +545,10 @@ int mapcache_vcpu_init(struct vcpu *v) if ( ents > cache->entries ) { - /* Populate page tables. */ - int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, + /* Populate page tables, a per-vCPU cache's multipage slots included. */ + int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, + ents + (dcache ? 0 + : MAPCACHE_MULTIPAGE_ENTRIES), NIL(l1_pgentry_t *), NULL); /* Populate the domain-wide bit maps (kept in the per-domain area). */ diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index 5bd9970fce..52d1ebc0e7 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -281,10 +281,24 @@ extern unsigned long xen_phys_start; #define MAPCACHE_VCPU_ENTRIES (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEVELS) /* Single-page slots of a per-vCPU mapcache (vCPU-PT domains). */ #define MAPCACHE_PERVCPU_ENTRIES 64 +/* + * Multipage slots of each vCPU: above the single-page ones of a per-vCPU + * mapcache, otherwise at the vCPU's stride of the multipage area. + */ +#define MAPCACHE_MULTIPAGE_ORDER 3 +#define MAPCACHE_MULTIPAGE_ENTRIES (1U << MAPCACHE_MULTIPAGE_ORDER) #define MAPCACHE_ENTRIES (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES) #define MAPCACHE_VIRT_START PERDOMAIN_VIRT_SLOT(1) #define MAPCACHE_VIRT_END (MAPCACHE_VIRT_START + \ MAPCACHE_ENTRIES * PAGE_SIZE) +/* The multipage area, at the end of the sub-area. */ +#define MAPCACHE_MULTIPAGE_VA_SHIFT (MAPCACHE_MULTIPAGE_ORDER + PAGE_SHIFT) +#define MAPCACHE_MULTIPAGE_VIRT_START \ + (MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20) - \ + (MAX_VIRT_CPUS << MAPCACHE_MULTIPAGE_VA_SHIFT)) +#define MAPCACHE_MULTIPAGE_START(v) \ + (MAPCACHE_MULTIPAGE_VIRT_START + \ + ((v)->vcpu_id << MAPCACHE_MULTIPAGE_VA_SHIFT)) /* Argument translation area. The third per-domain-mapping sub-area. */ #define ARG_XLAT_VIRT_START PERDOMAIN_VIRT_SLOT(2) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 6b27af9eb5..3748e417ce 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -84,6 +84,9 @@ struct mapcache_vcpu { uint32_t refcnt; } hash[MAPHASH_ENTRIES]; + /* Which of the vCPU's map_domain_pages() slots are in use. */ + unsigned long multipage_inuse; + /* Accounting of a per-vCPU mapcache (vCPU-PT domains). */ struct mapcache cache; /* Backing for cache.{inuse,garbage}. */ diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h index b62229ab5d..d9ad94ddb0 100644 --- a/xen/arch/x86/include/asm/spec_ctrl.h +++ b/xen/arch/x86/include/asm/spec_ctrl.h @@ -88,6 +88,7 @@ extern uint8_t default_scf; extern int8_t opt_xpti_hwdom, opt_xpti_domu; extern bool opt_vcpu_pt_hwdom, opt_vcpu_pt_hvm; +extern bool opt_vmap_strict; extern bool cpu_has_bug_l1tf; extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu; diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index c86f5ff886..3c52916eda 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -86,6 +86,9 @@ bool __ro_after_init opt_bp_spec_reduce = true; static bool __initdata opt_ibpb_alt; +/* BUG() where map_domain_pages() would fall back to vmap() (vmap-strict). */ +bool __ro_after_init opt_vmap_strict; + /* Give each vCPU of an HVM domain its own per-domain area (vCPU-PT). */ bool __ro_after_init opt_vcpu_pt_hvm; bool __ro_after_init opt_vcpu_pt_hwdom; @@ -591,6 +594,8 @@ static int __init cf_check parse_asi(const char *s) rc = -EINVAL; } } + else if ( (val = parse_boolean("vmap-strict", s, ss)) >= 0 ) + opt_vmap_strict = val; else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) { switch ( val ) @@ -840,6 +845,8 @@ static void __init print_details(enum ind_thunk thunk) printk(" ASI features for PV VMs:%s\n", sparse_dmap_pv() && !opt_xpti_domu ? " sparse-directmap" : " None"); + printk(" ASI vmap-strict: %s\n", + opt_vmap_strict ? "enabled" : "disabled"); } } diff --git a/xen/include/xen/domain_page.h b/xen/include/xen/domain_page.h index c89b149e54..bf45a4cf55 100644 --- a/xen/include/xen/domain_page.h +++ b/xen/include/xen/domain_page.h @@ -31,6 +31,27 @@ void *map_domain_page(mfn_t mfn); */ void unmap_domain_page(const void *ptr); +/* + * Map @nr page frames, not necessarily physically contiguous, at + * consecutive virtual addresses. Returns the virtual address of the + * first frame, or NULL when no space is available. As with + * map_domain_page(), the mapping is only valid within the current VCPU, + * and must be unmapped by it; unmap_domain_pages() takes the same @nr, + * and accepts a pointer carrying an in-page offset. Implemented on x86 + * only at present. + * + * @nr has an implementation-defined upper bound (x86: + * MAPCACHE_MULTIPAGE_ENTRIES). Exceeding it is a caller bug rather than a + * transient failure, and fails the mapping; callers needing more pages + * than a per-VCPU window holds want vmap() directly. + * + * unmap_domain_pages() is fatal given a pointer or an @nr which indexes + * outside the current VCPU's multipage slots. A wrong @nr within them + * is not detected: callers must pass the @nr they mapped with. + */ +void *map_domain_pages(const mfn_t *mfn, unsigned int nr); +void unmap_domain_pages(const void *ptr, unsigned int nr); + /* * Given a VA from map_domain_page(), return its underlying MFN. */ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463810.1674756 (Exim 4.92) (envelope-from ) id 1xMD6s-0002TV-Hc; Wed, 28 Oct 2026 23:31:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463810.1674756; Wed, 28 Oct 2026 23:31: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 1xMD6q-0002Lq-VR; Wed, 28 Oct 2026 23:31:08 +0000 Received: by outflank-mailman (input) for mailman id 1463810; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-0004AB-GD for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pRb-2bIu; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjJ-00000001KpM-2662; Wed, 28 Oct 2026 23:06: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" 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=KFvkL5WqfDQDRrp7P3qFC/Nmk3HS+ngDzI09Wi+qTuQ=; b=Pp3g2nIjhchz5yZ6+p6NcIoPzZ uuKeeRsdWNdCWPZJe+ocgON9GY/BEdNWrZGAeIfbOy7rYeGKD+BJKlQr2WJOAtCZC+9Wukag3Qr+J s5JDYyBe1ITVCY4YZXPCJS62/RkdLn6KvqJgL5wj7fEqjFWtEXHV+gKH6A+XvabAD3IA=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v5 13/45] x86/domain_page: don't unmap a mapcache entry that is not present Date: Wed, 28 Oct 2026 23:05:27 +0000 Message-ID: <20261028-asi-hvm-v5-13-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mappings must be torn down by the vCPU that created them, and only once. Have unmap_domain_page() check that the entry it is handed is present and bail out otherwise (ASSERT_UNREACHABLE()), rather than read an MFN out of an empty PTE and act on it, as a second unmap of an entry the first one zapped would. (A second unmap of an entry the maphash kept is caught, as before, only by the refcount ASSERT() in debug builds.) Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v4: - Reword the comment on the new check (Roger). Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 205d7b832a..47ccefa4e9 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -223,6 +223,15 @@ void unmap_domain_page(const void *ptr) ASSERT(cache->inuse); idx = PFN_DOWN(va - MAPCACHE_VIRT_START); + /* + * Sanity check: an entry that isn't present means a double or stray + * unmap. Play it safe: don't act on the MFN in an empty PTE. + */ + if ( !(l1e_get_flags(MAPCACHE_L1ENT(idx)) & _PAGE_PRESENT) ) + { + ASSERT_UNREACHABLE(); + return; + } mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)]; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463811.1674764 (Exim 4.92) (envelope-from ) id 1xMD6u-0002uG-8c; Wed, 28 Oct 2026 23:31:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463811.1674764; Wed, 28 Oct 2026 23:31: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 1xMD6s-0002ho-JZ; Wed, 28 Oct 2026 23:31:10 +0000 Received: by outflank-mailman (input) for mailman id 1463811; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-0004AP-I1 for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pRo-2rGR; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjH-00000001KpM-2QPJ; Wed, 28 Oct 2026 23:06: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" 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=Qz96shbhY184atVnv3ju4Bmbb5aXR1JV+WrIp8a3N3k=; b=ONxr/Z2LxWQVLz8G31YUNYBH64 7Vyq6VsECtnAVanQgP+zRJJWBKMqgudNNeEVeIs9razNvli7LNHAhLSTV9jwOiKlaHVEXiDt7FGX2 G0OgmAZI/nWcs1tQjJTSv3CyY11q7LJBVdfPpIBc2m345M6u8MbYs7kTw3j/4hR+RYU0=; 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?= , Teddy Astie Subject: [PATCH v5 11/45] x86/domain_page: prepare the mapcache for per-vCPU accounting Date: Wed, 28 Oct 2026 23:05:25 +0000 Message-ID: <20261028-asi-hvm-v5-11-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné Currently, only PV domains have a mapcache, which is a domain-wide one. In preparation for enabling per-vCPU mapcaches for HVM domains, split the accounting out into a struct mapcache, embedded in struct mapcache_domain. Introduce has_mapcache(), for whether a vCPU has a mapcache, and vcpu_mapcache(), which returns the accounting for a vCPU's mapcache and, in *dcache, the domain-wide mapcache whose lock and TLB epoch the caller has to take into account. For now has_mapcache() is is_pv_vcpu(), and vcpu_mapcache() always returns the domain's accounting. Move map_domain_page()'s handling of the domain-wide lock and TLB epoch into three helpers: mapcache_enter() takes the lock and catches up with a wrap another vCPU caused, mapcache_new_epoch() starts a new epoch after a wrap, and mapcache_exit() drops the lock. A per-vCPU mapcache can then skip them without map_domain_page() being re-indented. struct mapcache_domain keeps its size (40 bytes, x86_64 debug build), and so do the structures containing it. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - Reword has_mapcache()'s comment (Roger). - Move the comment on the domain-wide lock and TLB epoch into the function body (Roger). - Rename mapcache_lock() / mapcache_unlock() to mapcache_enter() / mapcache_exit() (Roger). - mapcache_new_epoch(): assert that the domain-wide lock is held (Roger). - mapcache_vcpu_init(): drop the comment on the early return for a disabled domain-wide mapcache (Jan). - mapcache_vcpu_init(): initialise ents and nr at their declarations, as before (Jan). - Dropping the redundant is_pv_vcpu() checks in map_domain_page() and unmap_domain_page() is now a patch of its own (Jan). Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 137 ++++++++++++++++++++---------- xen/arch/x86/include/asm/domain.h | 19 +++-- 2 files changed, 102 insertions(+), 54 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index ed68483695..e4ea7a254f 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -18,17 +18,19 @@ #include #include +/* Whether the vCPU supports mapcache usage, might not be in use. */ +static bool has_mapcache(const struct vcpu *v) +{ + return is_pv_vcpu(v); +} + static inline struct vcpu *mapcache_current_vcpu(void) { const struct vcpu *v = this_cpu(pgtable_vcpu); const struct vcpu *curr = current; - /* - * During early boot pgtable_vcpu is not set, callers must handle NULL. - * Non-PV domains don't have a mapcache, the directmap covers all physical - * address space. - */ - if ( !v || !is_pv_vcpu(v) ) + /* During early boot pgtable_vcpu is not set, callers must handle NULL. */ + if ( !v || !has_mapcache(v) ) return NULL; /* @@ -54,6 +56,52 @@ static inline struct vcpu *mapcache_current_vcpu(void) return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } +/* + * The accounting for v's mapcache: the domain's, with *dcache set so the + * caller takes the domain-wide lock and TLB-epoch machinery into account. + */ +static struct mapcache *vcpu_mapcache(struct vcpu *v, + struct mapcache_domain **dcache) +{ + struct domain *d = v->domain; + + *dcache = &d->arch.pv.mapcache; + return &(*dcache)->cache; +} + +static void mapcache_enter(struct mapcache_domain *dcache, + struct mapcache_vcpu *vcache) +{ + /* The domain's vCPUs share the mapcache's slots. */ + spin_lock(&dcache->lock); + + /* Has some other CPU caused a wrap? We must flush if so. */ + if ( unlikely(dcache->epoch != vcache->shadow_epoch) ) + { + vcache->shadow_epoch = dcache->epoch; + if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) ) + { + perfc_incr(domain_page_tlb_flush); + flush_tlb_local(); + } + } +} + +/* A wrap has just flushed this CPU's TLB: start a new epoch. */ +static void mapcache_new_epoch(struct mapcache_domain *dcache, + struct mapcache_vcpu *vcache) +{ + ASSERT(spin_is_locked(&dcache->lock)); + + vcache->shadow_epoch = ++dcache->epoch; + dcache->tlbflush_timestamp = tlbflush_current_time(); +} + +static void mapcache_exit(struct mapcache_domain *dcache) +{ + spin_unlock(&dcache->lock); +} + #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER) #define MAPCACHE_L2_ENTRIES (mapcache_l2_entry(MAPCACHE_ENTRIES - 1) + 1) #define MAPCACHE_L1ENT(idx) \ @@ -66,6 +114,7 @@ void *map_domain_page(mfn_t mfn) struct vcpu *v; struct mapcache_domain *dcache; struct mapcache_vcpu *vcache; + struct mapcache *cache; struct vcpu_maphash_entry *hashent; #ifdef NDEBUG @@ -77,9 +126,9 @@ void *map_domain_page(mfn_t mfn) if ( !v ) return mfn_to_virt(mfn_x(mfn)); - dcache = &v->domain->arch.pv.mapcache; + cache = vcpu_mapcache(v, &dcache); vcache = &v->arch.pv.mapcache; - if ( !dcache->inuse ) + if ( !cache->inuse ) return mfn_to_virt(mfn_x(mfn)); perfc_incr(map_domain_page_count); @@ -90,41 +139,30 @@ void *map_domain_page(mfn_t mfn) if ( hashent->mfn == mfn_x(mfn) ) { idx = hashent->idx; - ASSERT(idx < dcache->entries); + ASSERT(idx < cache->entries); hashent->refcnt++; ASSERT(hashent->refcnt); ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn)); goto out; } - spin_lock(&dcache->lock); + mapcache_enter(dcache, vcache); - /* Has some other CPU caused a wrap? We must flush if so. */ - if ( unlikely(dcache->epoch != vcache->shadow_epoch) ) - { - vcache->shadow_epoch = dcache->epoch; - if ( NEED_FLUSH(this_cpu(tlbflush_time), dcache->tlbflush_timestamp) ) - { - perfc_incr(domain_page_tlb_flush); - flush_tlb_local(); - } - } - - idx = find_next_zero_bit(dcache->inuse, dcache->entries, dcache->cursor); - if ( unlikely(idx >= dcache->entries) ) + idx = find_next_zero_bit(cache->inuse, cache->entries, cache->cursor); + if ( unlikely(idx >= cache->entries) ) { unsigned long accum = 0, prev = 0; /* /First/, clean the garbage map and update the inuse list. */ - for ( i = 0; i < BITS_TO_LONGS(dcache->entries); i++ ) + for ( i = 0; i < BITS_TO_LONGS(cache->entries); i++ ) { accum |= prev; - dcache->inuse[i] &= ~xchg(&dcache->garbage[i], 0); - prev = ~dcache->inuse[i]; + cache->inuse[i] &= ~xchg(&cache->garbage[i], 0); + prev = ~cache->inuse[i]; } - if ( accum | (prev & BITMAP_LAST_WORD_MASK(dcache->entries)) ) - idx = find_first_zero_bit(dcache->inuse, dcache->entries); + if ( accum | (prev & BITMAP_LAST_WORD_MASK(cache->entries)) ) + idx = find_first_zero_bit(cache->inuse, cache->entries); else { /* Replace a hash entry instead. */ @@ -144,19 +182,18 @@ void *map_domain_page(mfn_t mfn) i = 0; } while ( i != MAPHASH_HASHFN(mfn_x(mfn)) ); } - BUG_ON(idx >= dcache->entries); + BUG_ON(idx >= cache->entries); /* /Second/, flush TLBs. */ perfc_incr(domain_page_tlb_flush); flush_tlb_local(); - vcache->shadow_epoch = ++dcache->epoch; - dcache->tlbflush_timestamp = tlbflush_current_time(); + mapcache_new_epoch(dcache, vcache); } - set_bit(idx, dcache->inuse); - dcache->cursor = idx + 1; + set_bit(idx, cache->inuse); + cache->cursor = idx + 1; - spin_unlock(&dcache->lock); + mapcache_exit(dcache); l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_mfn(mfn, __PAGE_HYPERVISOR_RW)); @@ -170,6 +207,7 @@ void unmap_domain_page(const void *ptr) unsigned int idx; struct vcpu *v; struct mapcache_domain *dcache; + struct mapcache *cache; unsigned long va = (unsigned long)ptr, mfn, flags; struct vcpu_maphash_entry *hashent; @@ -181,8 +219,8 @@ void unmap_domain_page(const void *ptr) v = mapcache_current_vcpu(); ASSERT(v); - dcache = &v->domain->arch.pv.mapcache; - ASSERT(dcache->inuse); + cache = vcpu_mapcache(v, &dcache); + ASSERT(cache->inuse); idx = PFN_DOWN(va - MAPCACHE_VIRT_START); mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); @@ -205,7 +243,7 @@ void unmap_domain_page(const void *ptr) hashent->mfn); l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty()); /* /Second/, mark as garbage. */ - set_bit(hashent->idx, dcache->garbage); + set_bit(hashent->idx, cache->garbage); } /* Add newly-freed mapping to the maphash. */ @@ -217,7 +255,7 @@ void unmap_domain_page(const void *ptr) /* /First/, zap the PTE. */ l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty()); /* /Second/, mark as garbage. */ - set_bit(idx, dcache->garbage); + set_bit(idx, cache->garbage); } local_irq_restore(flags); @@ -239,9 +277,9 @@ void mapcache_domain_init(struct domain *d) 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long))) > MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20)); bitmap_pages = PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)); - dcache->inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE; - dcache->garbage = dcache->inuse + - (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); + dcache->cache.inuse = (void *)MAPCACHE_VIRT_END + PAGE_SIZE; + dcache->cache.garbage = dcache->cache.inuse + + (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); spin_lock_init(&dcache->lock); } @@ -249,15 +287,20 @@ void mapcache_domain_init(struct domain *d) int mapcache_vcpu_init(struct vcpu *v) { struct domain *d = v->domain; - struct mapcache_domain *dcache = &d->arch.pv.mapcache; + struct mapcache_domain *dcache; + struct mapcache *cache; unsigned long i; unsigned int ents = d->max_vcpus * MAPCACHE_VCPU_ENTRIES; unsigned int nr = PFN_UP(BITS_TO_LONGS(ents) * sizeof(long)); - if ( !is_pv_vcpu(v) || !dcache->inuse ) + if ( !has_mapcache(v) ) + return 0; + + cache = vcpu_mapcache(v, &dcache); + if ( !cache->inuse ) return 0; - if ( ents > dcache->entries ) + if ( ents > cache->entries ) { /* Populate page tables. */ int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, @@ -265,16 +308,16 @@ int mapcache_vcpu_init(struct vcpu *v) /* Populate bit maps. */ if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse, + rc = create_perdomain_mapping(v, (unsigned long)cache->inuse, nr, NULL, NIL(struct page_info *)); if ( !rc ) - rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage, + rc = create_perdomain_mapping(v, (unsigned long)cache->garbage, nr, NULL, NIL(struct page_info *)); if ( rc ) return rc; - dcache->entries = ents; + cache->entries = ents; } /* Mark all maphash entries as not in use. */ diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 4140a92f15..542c6b5eca 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -57,6 +57,16 @@ struct trap_bounce { unsigned long eip; }; +struct mapcache { + /* The number of array entries, and a cursor into the array. */ + unsigned int entries; + unsigned int cursor; + + /* Which mappings are in use, and which are garbage to reap next epoch? */ + unsigned long *inuse; + unsigned long *garbage; +}; + #define MAPHASH_ENTRIES 8 #define MAPHASH_HASHFN(pfn) ((pfn) & (MAPHASH_ENTRIES-1)) #define MAPHASHENT_NOTINUSE ((u32)~0U) @@ -73,10 +83,6 @@ struct mapcache_vcpu { }; struct mapcache_domain { - /* The number of array entries, and a cursor into the array. */ - unsigned int entries; - unsigned int cursor; - /* Protects map_domain_page(). */ spinlock_t lock; @@ -84,9 +90,8 @@ struct mapcache_domain { unsigned int epoch; u32 tlbflush_timestamp; - /* Which mappings are in use, and which are garbage to reap next epoch? */ - unsigned long *inuse; - unsigned long *garbage; + /* Accounting of the domain-wide mapcache. */ + struct mapcache cache; }; void mapcache_domain_init(struct domain *d); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463809.1674777 (Exim 4.92) (envelope-from ) id 1xMD6w-0003RZ-QR; Wed, 28 Oct 2026 23:31:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463809.1674777; Wed, 28 Oct 2026 23: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 1xMD6u-0003FX-Sv; Wed, 28 Oct 2026 23:31:12 +0000 Received: by outflank-mailman (input) for mailman id 1463809; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-0004AF-HD for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pRe-2iRK; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjq-00000001KpM-3Rir; Wed, 28 Oct 2026 23:07: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" 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=ld4BxAzvJvhftiGylQHLlBGsLps0YgvS9JWe5NAWOXA=; b=AtgzRgNpkoHR6CcHNEJH7rLXV6 /VxlzUYpWvt365O+Kdihs66lM1YTYV9HyC8oS90IzbZo0stziG4mdN2vpiWx7XyxLUju+ukRBVCv/ NVkwBFUSf5siK3bA3DKWIvbiJwVUj5wraTFZlJWcEfFSqh+IKXp7WhsbqvlGy7gBHlZw=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 45/45] x86/xstate: move guest XSAVE areas behind the vCPU state window Date: Wed, 28 Oct 2026 23:05:59 +0000 Message-ID: <20261028-asi-hvm-v5-45-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Guest vCPUs' XSAVE areas hold guest-owned register state, yet live in always-mapped memory: xenheap objects when they fit a page, vmap-backed allocations on hardware (AMX-class) where they do not. Under Address Space Isolation both placements leave the state reachable from every context. Move them to individual domain-heap pages, installed once at vCPU creation at a fixed reservation (indexes 3-5) in the per-vCPU state window, following the pattern set by the SVM VMCB and VMX MSR list relocations. With this, all eight slots of the state window are in use. The seam introduced by the VCPU_MAP_XSAVE_AREA() wrappers now gains its real implementation. The window address serves when v runs here on its own page tables: v == current, and this_cpu(pgtable_vcpu) == v. Neither test suffices alone. Inside the EFI runtime bracket, and after a shadow-mode update_cr3() failure, `current`'s own page tables are not loaded. While a CPU holds v's state lazily, v's page tables are loaded, but an IPI syncing that state for another CPU can switch them away at any time. The page-table test also structurally rules out one vCPU reaching through a same-vcpu_id window address into another domain's state, which a dispatch on `current` alone would have made possible to get wrong silently. With the owning vCPU running on its tables, or for an idle vCPU, the map is a pointer fetch, so the hot paths map nothing. Otherwise (a paused, never-started or lazily held vCPU) the full-area map uses map_domain_pages() and can fail; those callers gained error handling in "x86/xstate: classify xsave-area seam accesses by failure mode". The prefix variant maps only the area's first page, which the legacy region and header always fit, and hence cannot fail. A mapping of a single page is dropped with unmap_vcpu_state_page(), which also flushes this CPU's translation of it; unmap_domain_pages() flushes a multipage mapping itself. __context_switch() saves the outgoing vCPU's FPU state after `current` has moved to the incoming vCPU, with interrupts off, while the outgoing vCPU's page tables -- and therefore its window -- are normally still loaded. It takes the window address through a path of its own, vcpu_save_fpu_ctxt_switch(): the transient-mapping fallback must not run from there, as it would sync the local execution state and re-enter __context_switch(). The shadow-mode paths which abandon a vCPU's page tables early (update_cr3() failure in new_guest_cr3() and _toggle_guest_pt()) leave the idle tables loaded with the outgoing vCPU's state still in registers. Those paths have already crashed the domain, so there is nothing worth saving, and the save is skipped there, as the register frame's already is: both sit under one test of the loaded page tables. Anything else failing it is a page-table tracking bug rather than a recoverable state, so it is fatal in every build. The window reservation is fixed at three pages, sized for the largest save area current hardware produces (AMX TILEDATA); xstate_init() refuses, with an explanatory panic, hardware whose enabled feature set exceeds it. It does so on every boot, with or without asi=: every guest vCPU's area moves. Idle vCPUs keep a globally-reachable area (xenheap, or vmap space where it exceeds a page, as with AMX) deliberately: it is scratch for accesses which execute with a guest's page tables loaded (read_bndcfgu(), xstate_set_init()) and holds no guest register state. On such paths the area a guest's MPX state is transiently saved into remains reachable from other contexts, as today. The backing pages are caller-owned (no _PAGE_AVAIL0): the per-domain teardown reclaims only the page tables, so xstate_free_save_area() unmaps the pages from the window and frees them itself. Without per-vCPU page tables (every PV domain) the window is in the per-domain area that all its domain's vCPUs share, which outlives a vCPU whose creation fails. A failed partial allocation unwinds in place, and xstate_free_save_area() tolerates the resulting half-built state, which arch_vcpu_create()'s failure path relies on. Memory cost: sub-page areas (all non-AMX hardware) round up from a 2.7KiB xenheap object to a full page per vCPU. The move does not depend on asi=, and applies to PV vCPUs as to HVM ones. A context switch now calls vcpu_xsave_area_ctxt_switch() for the save, and vcpu_map_xsave_area() and vcpu_unmap_xsave_area() around the restore, out of line, instead of reading v->arch.xsave_area. The XRSTOR following write_ptbase() reaches the area through a 4KiB, non-global PTE in the per-domain area. As switch_cr3_cr4() has just flushed every non-global translation, that takes a page walk on every switch to a guest vCPU, where a sub-page area, a xenheap object, was reached through a superpage of the full directmap; the walk goes through the L1 table which the register frame's restore has just walked. On an Intel NUC, a 64-bit PV guest's vCPU context switch takes 15-30ns longer, with XPTI off or on and against either the tree before the XSAVE work or the one just before this change; code placement alone moves that measurement by up to about 20ns between builds. That was measured while the PV guest's register frames were still in struct vcpu. On AMX-class hardware, where the area takes three pages, a full-area map for a vCPU other than the one running here goes through map_domain_pages(): XEN_DOMCTL_getvcpuextstate and XEN_DOMCTL_setvcpuextstate make one for PV save, restore and migration, as the HVM XSAVE save record does for HVM guests. The area is then mapped in the calling vCPU's multipage slots, which only the calling domain's page tables carry, and dropping the mapping flushes the calling CPU's translations alone. Each of those operations can now fail with -ENOMEM. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version. xstate_init() now panics, with or without asi=, if the enabled XSAVE features need more than the three pages the window reserves. No current hardware does. Would you rather this did more, for instance size the window's XSAVE range from the size found at boot, or fall back to xenheap areas on such hardware? --- xen/arch/x86/domain.c | 19 ++-- xen/arch/x86/i387.c | 23 +++- xen/arch/x86/include/asm/config.h | 3 + xen/arch/x86/include/asm/domain.h | 15 ++- xen/arch/x86/include/asm/i387.h | 1 + xen/arch/x86/include/asm/xstate.h | 60 +++++------ xen/arch/x86/xstate.c | 172 +++++++++++++++++++++++++++++- 7 files changed, 243 insertions(+), 50 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index e57a99504b..b3f346020c 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -595,7 +595,11 @@ int arch_vcpu_create(struct vcpu *v) BUILD_BUG_ON(VCPU_STATE_IDX_VMCB >= VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_N2VMCB >= VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_VMX_MSR >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_XSAVE + VCPU_STATE_XSAVE_PAGES > + VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_REGS >= VCPU_STATE_NR_PAGES); + BUILD_BUG_ON(VCPU_STATE_IDX_REGS < VCPU_STATE_IDX_XSAVE + + VCPU_STATE_XSAVE_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_EMUL >= VCPU_STATE_NR_PAGES); BUILD_BUG_ON(VCPU_STATE_IDX_EMUL == VCPU_STATE_IDX_REGS); /* Page tables only; torn down with the rest of the per-domain area. */ @@ -2228,17 +2232,20 @@ static void __context_switch(void) { ASSERT(read_atomic(&p->dirty_cpu) == cpu); /* - * p's frame is reached through its state window, mapped while p's - * own page tables are loaded, as they normally still are here. Not - * so after the shadow-mode paths which abandon a vCPU's tables early - * (update_cr3() failure), which have crashed the domain: the frame - * is left unsaved. A transient mapping would re-enter this function. + * p's frame and XSAVE area are reached through its state window, + * mapped while p's own page tables are loaded, as they normally + * still are here. Not so after the shadow-mode paths which abandon + * a vCPU's tables early (update_cr3() failure), which have crashed + * the domain: both are left unsaved. A transient mapping would + * re-enter this function. */ if ( likely(this_cpu(pgtable_vcpu) == p) ) + { memcpy(vcpu_user_regs(p), stack_regs, CTXT_SWITCH_STACK_BYTES); + vcpu_save_fpu_ctxt_switch(p); + } else BUG_ON(!domain_shutting_down(pd)); - vcpu_save_fpu(p); pd->arch.ctxt_switch->from(p); } diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c index d49e391e99..239404b37b 100644 --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -177,7 +177,9 @@ void vcpu_restore_fpu(struct vcpu *v) ASSERT(!is_idle_vcpu(v)); + /* v runs here on its own page tables: the map cannot fail. */ xsave_area = VCPU_MAP_XSAVE_AREA(v); + BUG_ON(!xsave_area); if ( cpu_has_xsave ) fpu_xrstor(v, xsave_area, XSTATE_ALL); @@ -195,25 +197,36 @@ void vcpu_restore_fpu(struct vcpu *v) * On each context switch, save the necessary FPU info of VCPU being switch * out. It dispatches saving operation based on CPU's capability. */ -void vcpu_save_fpu(struct vcpu *v) +static void save_fpu(struct vcpu *v, struct xsave_struct *xsave_area) { - struct xsave_struct *xsave_area; - ASSERT(!is_idle_vcpu(v)); /* This can happen, if a paravirtualised guest OS has set its CR0.TS. */ clts(); - xsave_area = VCPU_MAP_XSAVE_AREA(v); - if ( cpu_has_xsave ) fpu_xsave(v, xsave_area); else fpu_fxsave(v, &xsave_area->fpu_sse); +} +/* Save the FPU state of v, the vCPU running here. */ +void vcpu_save_fpu(struct vcpu *v) +{ + /* As in vcpu_restore_fpu(): the fastpath, which cannot fail. */ + struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(v); + + BUG_ON(!xsave_area); + save_fpu(v, xsave_area); VCPU_UNMAP_XSAVE_AREA(v, xsave_area); } +/* As vcpu_save_fpu(), for __context_switch() switching v out. */ +void vcpu_save_fpu_ctxt_switch(struct vcpu *v) +{ + save_fpu(v, vcpu_xsave_area_ctxt_switch(v)); +} + /* Initialize FPU's context save area */ int vcpu_init_fpu(struct vcpu *v) { diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index 52d1ebc0e7..498e3c91fa 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -325,6 +325,9 @@ extern unsigned long xen_phys_start; #define VCPU_STATE_IDX_VMCB 0 #define VCPU_STATE_IDX_N2VMCB 1 #define VCPU_STATE_IDX_VMX_MSR 2 +#define VCPU_STATE_IDX_XSAVE 3 +/* Pages reserved for the XSAVE area; bounded at boot in xstate_init(). */ +#define VCPU_STATE_XSAVE_PAGES 3 #define VCPU_STATE_IDX_REGS 6 #define VCPU_STATE_IDX_EMUL 7 diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 3748e417ce..69ab854177 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -685,12 +685,19 @@ struct arch_vcpu unsigned long cr3; /* (MA) value to install in HW CR3 */ /* - * The save area for Processor Extended States and the bitmask of the - * XSAVE/XRSTOR features. They are used by: 1) when a vcpu (which has - * dirtied FPU/SSE) is scheduled out we XSAVE the states here; 2) in - * #NM handler, we XRSTOR the states we XSAVE-ed; + * The save area for Processor Extended States, XSAVEd on context + * switch out and XRSTORed on context switch in. For guest vCPUs + * the backing pages (xsave_pg[], xsave_pgcnt of them) come from the + * domain heap and are mapped once, for the life of the vCPU, at a + * fixed spot in the per-vCPU state window; xsave_area holds that + * window address, valid whenever the owning vCPU's page tables are + * loaded. Idle vCPUs' areas are ordinary Xen allocations (xenheap, + * or vmap space when larger than a page), reachable from every + * context. Any other access goes through VCPU_MAP_XSAVE_AREA(). */ struct xsave_struct *xsave_area; + struct page_info *xsave_pg[VCPU_STATE_XSAVE_PAGES]; + unsigned int xsave_pgcnt; uint64_t xcr0; /* Accumulated eXtended features mask for using XSAVE/XRESTORE by Xen * itself, as we can never know whether guest OS depends on content diff --git a/xen/arch/x86/include/asm/i387.h b/xen/arch/x86/include/asm/i387.h index 0717005d31..8d28de3ba8 100644 --- a/xen/arch/x86/include/asm/i387.h +++ b/xen/arch/x86/include/asm/i387.h @@ -29,6 +29,7 @@ struct ix87_env { void vcpu_restore_fpu(struct vcpu *v); void vcpu_save_fpu(struct vcpu *v); +void vcpu_save_fpu_ctxt_switch(struct vcpu *v); int vcpu_init_fpu(struct vcpu *v); void vcpu_destroy_fpu(struct vcpu *v); diff --git a/xen/arch/x86/include/asm/xstate.h b/xen/arch/x86/include/asm/xstate.h index c23308cbe2..a906df11ad 100644 --- a/xen/arch/x86/include/asm/xstate.h +++ b/xen/arch/x86/include/asm/xstate.h @@ -130,46 +130,43 @@ xsave_area_compressed(const struct xsave_struct *xsave_area) } /* - * Fetch a pointer to a vCPU's XSAVE area + * Fetch a pointer to a vCPU's XSAVE area. * - * TL;DR: If v == current, the mapping is guaranteed to already exist. + * Guest vCPUs' areas live on the domain heap, mapped once for the life + * of the vCPU at a fixed spot in the owning vCPU's state window. For a + * vCPU running here on its own page tables, and for an idle vCPU, the + * "map" is a pointer fetch. * - * Despite the name, this macro might not actually map anything. The only case - * in which a mutation of page tables is strictly required is when ASI==on && - * v!=current. For everything else the mapping already exists and needs not - * be created nor destroyed. + * Otherwise -- a paused, never-started or lazily held vCPU -- the area + * is genuinely mapped, and mapping the full, possibly multi-page area + * can fail: VCPU_MAP_XSAVE_AREA() may return NULL, and callers must + * handle that. The _PREFIX variant below cannot fail. * - * +-----------------+--------------+ - * | v == current | v != current | - * +--------------+-----------------+--------------+ - * | ASI enabled | per-vCPU fixmap | actual map | - * +--------------+-----------------+--------------+ - * | ASI disabled | directmap | - * +--------------+--------------------------------+ - * - * There MUST NOT be outstanding maps of XSAVE areas of the non-current vCPU - * at the point of context switch. Otherwise, the unmap operation will - * misbehave. - * - * TODO: Expand the macro to the ASI cases after infra to do so is in place. + * There MUST NOT be outstanding maps of another vCPU's XSAVE area at + * the point of context switch: such a mapping is only valid on the + * pCPU that created it, and only until the next reschedule. * * @param v Owner of the XSAVE area */ -#define VCPU_MAP_XSAVE_AREA(v) ((v)->arch.xsave_area) +struct xsave_struct *vcpu_map_xsave_area(const struct vcpu *v); +void vcpu_unmap_xsave_area(const struct vcpu *v, const void *area); +struct xsave_struct *vcpu_map_xsave_area_prefix(const struct vcpu *v); +void vcpu_unmap_xsave_area_prefix(const struct vcpu *v, const void *area); +struct xsave_struct *vcpu_xsave_area_ctxt_switch(const struct vcpu *v); + +#define VCPU_MAP_XSAVE_AREA(v) vcpu_map_xsave_area(v) /* - * Drops the mapping of a vCPU's XSAVE area and nullifies its pointer on exit - * - * See VCPU_MAP_XSAVE_AREA() for additional information on the persistence of - * these mappings. This macro only tears down the mappings in the ASI=on && - * v!=current case. - * - * TODO: Expand the macro to the ASI cases after infra to do so is in place. + * Drops the mapping of a vCPU's XSAVE area and nullifies the local + * pointer on exit. * * @param v Owner of the XSAVE area * @param x XSAVE blob of v */ -#define VCPU_UNMAP_XSAVE_AREA(v, x) do { (void)(v); (x) = NULL; } while (0) +#define VCPU_UNMAP_XSAVE_AREA(v, x) do { \ + vcpu_unmap_xsave_area(v, x); \ + (x) = NULL; \ +} while ( false ) /* * Variant of VCPU_MAP_XSAVE_AREA() for accessors which touch nothing @@ -177,7 +174,10 @@ xsave_area_compressed(const struct xsave_struct *xsave_area) * XSTATE_AREA_MIN_SIZE bytes). That prefix always fits within the * area's first page, so this variant cannot fail. */ -#define VCPU_MAP_XSAVE_AREA_PREFIX(v) VCPU_MAP_XSAVE_AREA(v) -#define VCPU_UNMAP_XSAVE_AREA_PREFIX(v, x) VCPU_UNMAP_XSAVE_AREA(v, x) +#define VCPU_MAP_XSAVE_AREA_PREFIX(v) vcpu_map_xsave_area_prefix(v) +#define VCPU_UNMAP_XSAVE_AREA_PREFIX(v, x) do { \ + vcpu_unmap_xsave_area_prefix(v, x); \ + (x) = NULL; \ +} while ( false ) #endif /* __ASM_XSTATE_H */ diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 2dd1699aba..7543edc160 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -5,6 +5,7 @@ * */ +#include #include #include #include @@ -14,6 +15,7 @@ #include #include #include +#include #include #include #include @@ -555,9 +557,61 @@ int xstate_alloc_save_area(struct vcpu *v) /* XSAVE/XRSTOR requires the save area be 64-byte-boundary aligned. */ BUILD_BUG_ON(__alignof(*save_area) < 64); - save_area = _xvzalloc(size, __alignof(*save_area)); - if ( save_area == NULL ) - return -ENOMEM; + + if ( !is_idle_vcpu(v) ) + { + /* + * The pages are the vCPU's own (no _PAGE_AVAIL0): the area teardown + * leaves them alone, and xstate_free_save_area() frees them. + */ + unsigned int nr = PFN_UP(size), i; + mfn_t mfns[VCPU_STATE_XSAVE_PAGES]; + + /* xstate_init() bounds the host size against the reservation. */ + BUG_ON(nr > VCPU_STATE_XSAVE_PAGES); + + for ( i = 0; i < nr; i++ ) + { + struct page_info *pg = alloc_domheap_page(v->domain, + MEMF_no_owner); + + if ( !pg ) + { + while ( i-- ) + { + free_domheap_page(v->arch.xsave_pg[i]); + v->arch.xsave_pg[i] = NULL; + } + return -ENOMEM; + } + + v->arch.xsave_pg[i] = pg; + mfns[i] = page_to_mfn(pg); + clear_domain_page(mfns[i]); + } + v->arch.xsave_pgcnt = nr; + + populate_perdomain_mapping(v, VCPU_STATE_ADDR(v, VCPU_STATE_IDX_XSAVE), + mfns, nr, __PAGE_HYPERVISOR_RW); + + /* + * The window VA is not reachable from the creating context (v is + * still being built); seed the initial register values through a + * transient mapping of the first page instead. + */ + save_area = map_domain_page(mfns[0]); + } + else + { + /* + * Idle vCPUs' areas must be reachable from every context: they are + * scratch for accesses made with a guest's page tables loaded + * (read_bndcfgu(), xstate_set_init()). + */ + save_area = _xvzalloc(size, __alignof(*save_area)); + if ( save_area == NULL ) + return -ENOMEM; + } /* * We're creating a vCPU, so conceptually we should be choosing the @@ -578,7 +632,15 @@ int xstate_alloc_save_area(struct vcpu *v) save_area->fpu_sse.ftw = FXSAVE_FTW_RESET; save_area->fpu_sse.mxcsr = MXCSR_DEFAULT; - v->arch.xsave_area = save_area; + if ( !is_idle_vcpu(v) ) + { + unmap_domain_page(save_area); + v->arch.xsave_area = + (void *)VCPU_STATE_ADDR(v, VCPU_STATE_IDX_XSAVE); + } + else + v->arch.xsave_area = save_area; + v->arch.xcr0 = 0; v->arch.xcr0_accum = 0; @@ -587,7 +649,103 @@ int xstate_alloc_save_area(struct vcpu *v) void xstate_free_save_area(struct vcpu *v) { - XVFREE(v->arch.xsave_area); + if ( !is_idle_vcpu(v) ) + { + unsigned int i, nr = v->arch.xsave_pgcnt; + + if ( nr ) + { + unmap_vcpu_state(v, VCPU_STATE_IDX_XSAVE, nr); + for ( i = 0; i < nr; i++ ) + { + free_domheap_page(v->arch.xsave_pg[i]); + v->arch.xsave_pg[i] = NULL; + } + v->arch.xsave_pgcnt = 0; + } + + v->arch.xsave_area = NULL; + } + else + XVFREE(v->arch.xsave_area); +} + +struct xsave_struct *vcpu_map_xsave_area(const struct vcpu *v) +{ + mfn_t mfns[VCPU_STATE_XSAVE_PAGES]; + unsigned int i; + + if ( is_idle_vcpu(v) ) + return v->arch.xsave_area; + + /* + * The window VA is valid while v's own page tables are loaded, but that + * alone is not enough: while this CPU holds v's state lazily, an IPI + * syncing that state for another CPU can switch v's page tables away + * at any time. Hence the window only for v running here on its own + * page tables, which current's are not inside the EFI runtime bracket + * or after a shadow-mode update_cr3() failure. + */ + if ( v == current && this_cpu(pgtable_vcpu) == v ) + return v->arch.xsave_area; + + for ( i = 0; i < v->arch.xsave_pgcnt; i++ ) + mfns[i] = page_to_mfn(v->arch.xsave_pg[i]); + + return map_domain_pages(mfns, v->arch.xsave_pgcnt); +} + +void vcpu_unmap_xsave_area(const struct vcpu *v, const void *area) +{ + if ( !area || is_idle_vcpu(v) || + area == (const void *)v->arch.xsave_area ) + return; + + /* + * A single page comes from the single-page mapcache, whose + * domain-wide form defers its flushes; unmap_domain_pages() flushes a + * multipage mapping itself. + */ + if ( v->arch.xsave_pgcnt == 1 ) + unmap_vcpu_state_page(area); + else + unmap_domain_pages(area, v->arch.xsave_pgcnt); +} + +struct xsave_struct *vcpu_map_xsave_area_prefix(const struct vcpu *v) +{ + /* The legacy region and header always fit the area's first page. */ + BUILD_BUG_ON(sizeof(struct xsave_struct) > PAGE_SIZE); + + /* The window VA under vcpu_map_xsave_area()'s conditions. */ + if ( is_idle_vcpu(v) || + (v == current && this_cpu(pgtable_vcpu) == v) ) + return v->arch.xsave_area; + + return map_domain_page(page_to_mfn(v->arch.xsave_pg[0])); +} + +void vcpu_unmap_xsave_area_prefix(const struct vcpu *v, const void *area) +{ + if ( !area || is_idle_vcpu(v) || + area == (const void *)v->arch.xsave_area ) + return; + + unmap_vcpu_state_page(area); +} + +/* + * The XSAVE area of @v for __context_switch() saving it: `current` has + * moved on to the incoming vCPU, but @v's page tables are still loaded, and + * interrupts are off, so the window VA serves. A transient mapping is not + * an option from there: it would sync the lazy state and re-enter + * __context_switch(). + */ +struct xsave_struct *vcpu_xsave_area_ctxt_switch(const struct vcpu *v) +{ + BUG_ON(is_idle_vcpu(v) || this_cpu(pgtable_vcpu) != v); + + return v->arch.xsave_area; } static bool valid_xcr0(uint64_t xcr0) @@ -934,6 +1092,10 @@ void xstate_init(struct cpuinfo_x86 *c) xsave_cntxt_size = cpuid_count_ebx(0xd, 0); printk("xstate: size: %#x and states: %#"PRIx64"\n", xsave_cntxt_size, xfeature_mask); + + if ( PFN_UP(xsave_cntxt_size) > VCPU_STATE_XSAVE_PAGES ) + panic("XSAVE area needs %lu pages, vCPU state window reserves %u\n", + PFN_UP(xsave_cntxt_size), VCPU_STATE_XSAVE_PAGES); } else { -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463812.1674784 (Exim 4.92) (envelope-from ) id 1xMD6y-0003y0-SN; Wed, 28 Oct 2026 23:31:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463812.1674784; Wed, 28 Oct 2026 23:31: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 1xMD6x-0003nU-85; Wed, 28 Oct 2026 23:31:15 +0000 Received: by outflank-mailman (input) for mailman id 1463812; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-0004A9-FZ for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pRX-2TfM; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjm-00000001KpM-0PHd; Wed, 28 Oct 2026 23:07: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" 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=78UJyNn4VY/h+N1P7RYObuj4ivXfajt4ZYGSI254v8U=; b=psZXujfReIZ3ehIb5LClc4d9JS FmiH8crUB/DVU6qThT8cPtrvSs0b11qR+IP1ik0r5R/fz9O0TJqlgqv/v6THkhh3WxDoEIuatdKa4 6WMESDMEXkgZ7TaqEHo06Q8wP82pqcBEGalQR93IopuT2LdamLzwQjrbKYfyEgo5AUqg=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 40/45] x86/mpx: Map/unmap xsave area in read_bndcfgu() Date: Wed, 28 Oct 2026 23:05:54 +0000 Message-ID: <20261028-asi-hvm-v5-40-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Alejandro Vallejo The BNDCSR read executes XSAVE into the local idle vCPU's save area as scratch space and pulls BNDCFGU out of the result. Fetch that buffer through the VCPU_MAP_XSAVE_AREA() seam rather than a raw dereference, so the function is indifferent to where vCPU save areas live. This was the last raw access to another vCPU's save-area pointer outside the seam. No functional change. Signed-off-by: Alejandro Vallejo Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Revived from "x86: Address Space Isolation FPU preparations" v3 patch 09/12 (<20250110132823.24348-10-alejandro.vallejo@cloud.com>; no v4 was ever posted). Changes in v5: - New in this version. Changes since the previously posted version: - Constified the vcpu pointer, as requested by Jan Beulich on the original thread (the xstate pointer itself stays mutable: the asm()s write through it, as Jan noted in withdrawing that half of the request). - Expanded the commit message. --- xen/arch/x86/xstate.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 8336414c52..2eae3f098d 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -1023,9 +1023,10 @@ int handle_xsetbv(u32 index, u64 new_bv) uint64_t read_bndcfgu(void) { + uint64_t bndcfgu = 0; unsigned long cr0 = read_cr0(); - struct xsave_struct *xstate - = idle_vcpu[smp_processor_id()]->arch.xsave_area; + const struct vcpu *v = idle_vcpu[smp_processor_id()]; + struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v); const struct xstate_bndcsr *bndcsr; ASSERT(cpu_has_mpx); @@ -1051,7 +1052,12 @@ uint64_t read_bndcfgu(void) if ( cr0 & X86_CR0_TS ) write_cr0(cr0); - return xstate->xsave_hdr.xstate_bv & X86_XCR0_BNDCSR ? bndcsr->bndcfgu : 0; + if ( xstate->xsave_hdr.xstate_bv & X86_XCR0_BNDCSR ) + bndcfgu = bndcsr->bndcfgu; + + VCPU_UNMAP_XSAVE_AREA(v, xstate); + + return bndcfgu; } void xstate_set_init(uint64_t mask) -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463813.1674799 (Exim 4.92) (envelope-from ) id 1xMD72-0004sN-Rh; Wed, 28 Oct 2026 23:31:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463813.1674799; Wed, 28 Oct 2026 23: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 1xMD70-0004kW-JQ; Wed, 28 Oct 2026 23:31:18 +0000 Received: by outflank-mailman (input) for mailman id 1463813; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-0004AI-Hn for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pRI-2701; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjI-00000001KpM-2Xv1; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=6RX48R0QNYubdYR5xyvgMIQXSDrHO/YymvMThV7Bj0U=; b=ZIIcrB+bvis1Qh62QjjdgYNh+8 mi0QWboAN1HhuTz/9rs2SHbtltttn2NmsoRJFzhkXyM4u4R1pbUXm4hPonb+/7X/7WMp8KefTgnIo GWbnPZfQOMY3u/nvM7zmnVM4JPhBIMXjkdt6cqo+j9n9u4UTjrTNavfFtGvghzLfe4xs=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH v5 12/45] x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu Date: Wed, 28 Oct 2026 23:05:26 +0000 Message-ID: <20261028-asi-hvm-v5-12-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Roger Pau Monné struct mapcache_vcpu, the per-vCPU part of the mapcache (the maphash and the vCPU's shadow of the domain's TLB epoch), lives in struct pv_vcpu, as only PV vCPUs have a mapcache. In preparation for implementing mapcaches for HVM domains, move it to struct arch_vcpu: v->arch.pv.mapcache becomes v->arch.mapcache. struct pv_vcpu shrinks from 512 to 376 bytes, and struct vcpu grows from 2880 to 3008 bytes (x86_64, debug build), within its page: from here on HVM vCPUs carry the 136-byte struct mapcache_vcpu too, ahead of its use by those of vCPU-PT domains. No functional change. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap Reviewed-by: Roger Pau Monné --- Changes in v3: - New in this version, split out of "x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains" for review. --- xen/arch/x86/domain_page.c | 6 +++--- xen/arch/x86/include/asm/domain.h | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index e4ea7a254f..205d7b832a 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -127,7 +127,7 @@ void *map_domain_page(mfn_t mfn) return mfn_to_virt(mfn_x(mfn)); cache = vcpu_mapcache(v, &dcache); - vcache = &v->arch.pv.mapcache; + vcache = &v->arch.mapcache; if ( !cache->inuse ) return mfn_to_virt(mfn_x(mfn)); @@ -224,7 +224,7 @@ void unmap_domain_page(const void *ptr) idx = PFN_DOWN(va - MAPCACHE_VIRT_START); mfn = l1e_get_pfn(MAPCACHE_L1ENT(idx)); - hashent = &v->arch.pv.mapcache.hash[MAPHASH_HASHFN(mfn)]; + hashent = &v->arch.mapcache.hash[MAPHASH_HASHFN(mfn)]; local_irq_save(flags); @@ -324,7 +324,7 @@ int mapcache_vcpu_init(struct vcpu *v) BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES); for ( i = 0; i < MAPHASH_ENTRIES; i++ ) { - struct vcpu_maphash_entry *hashent = &v->arch.pv.mapcache.hash[i]; + struct vcpu_maphash_entry *hashent = &v->arch.mapcache.hash[i]; hashent->mfn = ~0UL; /* never valid to map */ hashent->idx = MAPHASHENT_NOTINUSE; diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 542c6b5eca..45d308407e 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -545,9 +545,6 @@ struct arch_domain struct pv_vcpu { - /* map_domain_page() mapping cache. */ - struct mapcache_vcpu mapcache; - unsigned int vgc_flags; struct trap_info *trap_ctxt; @@ -643,6 +640,9 @@ struct arch_vcpu #define async_exception_state(t) async_exception_state[(t)-1] uint8_t async_exception_mask; + /* map_domain_page() mapping cache. */ + struct mapcache_vcpu mapcache; + /* Virtual Machine Extensions */ union { struct pv_vcpu pv; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463814.1674807 (Exim 4.92) (envelope-from ) id 1xMD74-0005Gr-6N; Wed, 28 Oct 2026 23:31:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463814.1674807; Wed, 28 Oct 2026 23:31: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 1xMD72-0005As-9t; Wed, 28 Oct 2026 23:31:20 +0000 Received: by outflank-mailman (input) for mailman id 1463814; Wed, 28 Oct 2026 23:30:37 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6L-0004Ah-Oq for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:37 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6L-00000000pRT-2Io0; Wed, 28 Oct 2026 23:30:37 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjT-00000001KpM-1LPV; Wed, 28 Oct 2026 23:06: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" 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=Wl4nV3ZTDHnsWL9MvyITa+VNEqVOjsoYMCNqs+DR/ME=; b=c7xLgDl+sXuJFaYr/hVcrRc9ia 423oZM0vKVoqJgyGIbCV1Lw+P1wSXkgTRgl59PlM/DlmTQCT3fqBUWdQ/ZwClz9tmYk+Cz2raKDMG qXDzb3QlXtIc1PHVGW9kE+wrWMWNFyyHUo5E90Fo1IHIQ7M41PmsdG9zWt/InvMD88Ds=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Teddy Astie Subject: [PATCH v5 22/45] x86/spec-ctrl: wire the sparse directmap view into the asi= option Date: Wed, 28 Oct 2026 23:05:36 +0000 Message-ID: <20261028-asi-hvm-v5-22-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Let asi= choose which domains run on the sparse view of the directmap, when the hypervisor is built with CONFIG_SPARSE_DIRECTMAP: * `asi` and `asi=` enable or disable the sparse view, along with vCPU-PT, for every domain including the hardware domain, PV or PVH. HVM domains, a PVH hardware domain included, use the sparse view together with vCPU-PT, which gives them the mapcache it needs; PV domains all have one. A PV domain on the sparse view keeps its domain-wide mapcache and per-domain mappings: the sparse view separates it from other domains, not its vCPUs from each other. * `asi=hvm=`, `asi=pv=` and `asi=dom0=` do the same for HVM or PV domains other than the hardware domain, or for the hardware domain, whatever its type: `asi=1,dom0=0` leaves the hardware domain out of ASI altogether. * A new `asi=directmap=` selects the sparse view for all domains, as `asi=vcpu-pt=` selects vCPU-PT; `vcpu-pt=` alone leaves the sparse view off. On a hypervisor built without CONFIG_SPARSE_DIRECTMAP the forms enabling all features leave the sparse view off, and `directmap=` is rejected as invalid, as compiled-out `spec-ctrl=` sub-options are. A domain type the build lacks is ignored, so that the sparse view is not built for nothing. * For now, a PV domain uses one of XPTI and the sparse view, not both. Enabled explicitly, for dom0, domUs or both, XPTI takes precedence: the PV domains it covers keep the full directmap, and the boot log says so. Left to its default, XPTI yields: it is disabled for the PV domains using the sparse view, with a boot-log warning where it would otherwise be enabled, as the sparse view does not replace it yet (it still maps the xenheap and Xen's stacks). Each domain's case is settled at its creation, and again if it becomes 32-bit, which XPTI does not cover: switch_compat() then puts a domain that XPTI kept off the sparse view on it, with the domain-wide mapcache, which release builds may not have set up for it. The boot log gains a line with the directmap mode, "sparse" once a sparse view is configured and "full" otherwise, and the "ASI features for ..." lines, one for PV domUs now among them, say which domains use the sparse view. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - Follow "x86/spec-ctrl: introduce Address Space Isolation command line option": opt_vcpu_pt_hwdom's name, the development warning in parse_asi(), IS_ENABLED() in the boot log; pv= now replaces the line saying it is ignored. Changes in v4: - Docs, comments and message: "domains" throughout, not "guests" (Roger). - Follow the rename of opt_vcpu_pt_hwdom to opt_pvh_vcpu_pt_hwdom and the move of the per-domain settings into d->arch.asi. - pv= and dom0= move to the patch introducing asi=, beside hvm=; opt_sparse_dmap_hwdom and sparse_dmap_wanted()'s hardware-domain case to the patches that add the other knobs and sparse_dmap_wanted() (Roger). - directmap= on a build without CONFIG_SPARSE_DIRECTMAP is rejected as invalid, as compiled-out spec-ctrl= sub-options are, rather than ignored with a warning (Roger). - A PV domain that XPTI kept off the sparse view goes on it when it becomes 32-bit, which ends XPTI; it used to end up with neither. Changes in v3: - New in this version. --- docs/misc/xen-command-line.pandoc | 30 +++++- xen/arch/x86/include/asm/sparse-directmap.h | 7 ++ xen/arch/x86/pv/domain.c | 16 +++ xen/arch/x86/spec_ctrl.c | 102 +++++++++++++++++--- 4 files changed, 138 insertions(+), 17 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 839d06da26..092c858f34 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -203,7 +203,7 @@ to appropriate auditing by Xen. Argo is disabled by default. buggy or malicious other domain spamming the ring. ### asi (x86) -> `= List of [ , {pv,hvm,dom0}=, +> `= List of [ , {pv,hvm,dom0}=, directmap=, > vcpu-pt= | vcpu-pt=hvm= ]` > Default: `false` @@ -215,14 +215,16 @@ 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. -The mechanisms currently implemented apply to HVM domains, including a PVH -hardware domain. PV domains, including a PV hardware domain, are unaffected. +The mechanisms currently implemented are `vcpu-pt`, for HVM domains including +a PVH hardware domain, and `directmap`, for all domains including the hardware +domain, PV or PVH. The plain boolean enables or disables both, wherever they +apply. * `pv=`, `hvm=` and `dom0=` enable the features for PV domains or HVM domains other than the hardware domain, or for the hardware domain, PV or PVH. The plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain - out. The forms naming no domain type (an un-suffixed `vcpu-pt=`) - cover the hardware domain too. + out. The forms naming no domain type (an un-suffixed `vcpu-pt=`, and + `directmap=`) cover the hardware domain too. **WARNING: manual de-selection of enabled options will invalidate any protection offered by the feature. The fine grained options provided below @@ -231,6 +233,18 @@ are meant to be used for debugging purposes only.** * `vcpu-pt` gives each vCPU its own per-domain area: the per-domain slot of each vCPU's monitor table maps a region private to that vCPU. +* `directmap` (only available when Xen is built with + `CONFIG_SPARSE_DIRECTMAP`) runs guest contexts on a sparse view of the + directmap, which maps the memory Xen needs to reach at all times (the Xen + heap, Xen's own image, firmware tables), while guest memory is mapped + transiently. This selection is system-wide; `pv=`, `hvm=` and `dom0=` + make it for one domain type, along with the other features. HVM domains use + the sparse view only together with `vcpu-pt`, and PV domains only without + XPTI, which yields to the sparse view unless enabled explicitly (see + `xpti`). The whole-feature forms (`asi`, `asi=`, and `pv=`, `hvm=` + and `dom0=`) set this too, on builds that support it; on other builds they + leave it off. + ### asid (x86) > `= ` @@ -3132,6 +3146,12 @@ Meltdown for all domains. With `dom0` and `domu` it is possible to control page table isolation for dom0 or guest domains only. +With `asi`, XPTI and the sparse directmap view (`asi=directmap`) exclude each +other for a PV domain. Enabled explicitly, as a whole or with `dom0` or +`domu`, XPTI keeps the PV domains it covers off the sparse view, and the boot +log says so. Left to its default, XPTI is disabled for the PV domains using +the sparse view, with a boot-log warning where it would otherwise be enabled. + ### xsave (x86) > `= ` diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h index 2f8b94f4c1..db4df82215 100644 --- a/xen/arch/x86/include/asm/sparse-directmap.h +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -31,6 +31,10 @@ static inline bool sparse_dmap_configured(void) return opt_sparse_dmap_pv || opt_sparse_dmap_hvm || opt_sparse_dmap_hwdom; } +static inline bool sparse_dmap_pv(void) { return opt_sparse_dmap_pv; } +static inline bool sparse_dmap_hvm(void) { return opt_sparse_dmap_hvm; } +static inline bool sparse_dmap_hwdom(void) { return opt_sparse_dmap_hwdom; } + /* Whether a new domain of the given type is to use the sparse view. */ static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { @@ -51,6 +55,9 @@ int sparse_dmap_drop_pagetable(mfn_t mfn); static inline bool sparse_dmap_configured(void) { return false; } static inline bool sparse_dmap_wanted(bool pv, bool hwdom) { return false; } +static inline bool sparse_dmap_pv(void) { return false; } +static inline bool sparse_dmap_hvm(void) { return false; } +static inline bool sparse_dmap_hwdom(void) { return false; } static inline void sparse_dmap_init(void) {} static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, unsigned long nr, pte_attr_t flags) diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index f139d8f83c..579d6133f5 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -248,6 +248,20 @@ int switch_compat(struct domain *d) d->arch.has_32bit_shinfo = 1; d->arch.pv.is_32bit = true; + /* + * XPTI, cleared below, is for 64-bit domains. A domain it kept off the + * sparse directmap view goes on it now if wanted, and the domain-wide + * mapcache the view needs is set up for the domain and its vCPUs. + */ + if ( d->arch.pv.xpti && sparse_dmap_wanted(true, is_hardware_domain(d)) ) + { + d->arch.asi.sparse_dmap = true; + mapcache_domain_init(d); + for_each_vcpu ( d, v ) + if ( (rc = mapcache_vcpu_init(v)) ) + goto undo_and_fail; + } + /* * For 32bit PV guests the shared_info machine address must fit in a 32-bit * field within the guest's start_info structure. We might need to free @@ -301,6 +315,8 @@ int switch_compat(struct domain *d) undo_and_fail: d->arch.pv.is_32bit = d->arch.has_32bit_shinfo = false; + if ( d->arch.pv.xpti ) + d->arch.asi.sparse_dmap = false; for_each_vcpu( d, v ) { free_compat_arg_xlat(v); diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index bcdcdf0476..c86f5ff886 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -387,6 +387,19 @@ int8_t __ro_after_init opt_xpti_domu = -1; static __init void xpti_init_default(void) { + /* + * XPTI and the sparse directmap view exclude each other for a PV domain + * (see spec_ctrl_init_domain()). Enabled explicitly, XPTI takes + * precedence: the PV domains it covers stay off the sparse view. Left to + * its default, it yields: it is off where the sparse view is asked for. + */ + if ( !opt_dom0_pvh && opt_xpti_hwdom == 1 && sparse_dmap_hwdom() ) + printk(XENLOG_ERR + "XPTI enabled, disabling Dom0 sparse-directmap\n"); + if ( opt_xpti_domu == 1 && sparse_dmap_pv() ) + printk(XENLOG_ERR + "XPTI enabled, disabling PV DomU sparse-directmap\n"); + if ( (boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) || cpu_has_rdcl_no ) { @@ -397,10 +410,21 @@ static __init void xpti_init_default(void) } else { + bool yield_hwdom = opt_xpti_hwdom < 0 && !opt_dom0_pvh && + sparse_dmap_hwdom(); + bool yield_domu = opt_xpti_domu < 0 && sparse_dmap_pv(); + + /* The default would be on here: say where it yields. */ + if ( yield_hwdom || yield_domu ) + printk(XENLOG_WARNING + "XPTI defaults off for PV %s on the sparse directmap\n", + yield_hwdom ? (yield_domu ? "Dom0 and DomU" : "Dom0") + : "DomU"); + if ( opt_xpti_hwdom < 0 ) - opt_xpti_hwdom = 1; + opt_xpti_hwdom = !sparse_dmap_hwdom(); if ( opt_xpti_domu < 0 ) - opt_xpti_domu = 1; + opt_xpti_domu = !sparse_dmap_pv(); } } @@ -491,6 +515,23 @@ static int __init cf_check parse_pv_l1tf(const char *s) } custom_param("pv-l1tf", parse_pv_l1tf); +/* + * Set the sparse directmap view's knob for each domain type given. A type + * the build lacks stays off, so that no view is built for it, and without + * CONFIG_SPARSE_DIRECTMAP all stay off. + */ +static void __init set_sparse_dmap(bool pv, bool hvm, bool hwdom, bool val) +{ +#ifdef CONFIG_SPARSE_DIRECTMAP + if ( pv && IS_ENABLED(CONFIG_PV) ) + opt_sparse_dmap_pv = val; + if ( hvm && IS_ENABLED(CONFIG_HVM) ) + opt_sparse_dmap_hvm = val; + if ( hwdom ) + opt_sparse_dmap_hwdom = val; +#endif +} + static int __init cf_check parse_asi(const char *s) { static bool __initdata warned; @@ -507,7 +548,10 @@ static int __init cf_check parse_asi(const char *s) /* Interpret 'asi' alone in its positive boolean form. */ if ( *s == '\0' ) + { opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = true; + set_sparse_dmap(true, true, true, true); + } do { ss = strchr(s, ','); @@ -520,17 +564,33 @@ static int __init cf_check parse_asi(const char *s) case 0: case 1: opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; + set_sparse_dmap(true, true, true, val); break; default: if ( (val = parse_boolean("pv", s, ss)) >= 0 ) - printk(XENLOG_WARNING - "No ASI feature applies to PV domains - ignoring 'asi=%.*s' setting\n", - (int)(ss - s), s); + set_sparse_dmap(true, false, false, val); else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + { opt_vcpu_pt_hvm = val; + set_sparse_dmap(false, true, false, val); + } else if ( (val = parse_boolean("dom0", s, ss)) >= 0 ) + { opt_vcpu_pt_hwdom = val; + set_sparse_dmap(false, false, true, val); + } + else if ( (val = parse_boolean("directmap", s, ss)) >= 0 ) + { + /* System-wide: every domain type, the hardware domain too. */ + if ( IS_ENABLED(CONFIG_SPARSE_DIRECTMAP) ) + set_sparse_dmap(true, true, true, val); + else + { + no_config_param("SPARSE_DIRECTMAP", "asi", s, ss); + rc = -EINVAL; + } + } else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) { switch ( val ) @@ -759,11 +819,28 @@ static void __init print_details(enum ind_thunk thunk) opt_pv_l1tf_domu ? "enabled" : "disabled"); #endif - printk(" ASI features for Dom0:%s\n", - opt_dom0_pvh && opt_vcpu_pt_hwdom ? " vCPU-PT" : " None"); - if ( IS_ENABLED(CONFIG_HVM) ) - printk(" ASI features for HVM VMs:%s\n", - opt_vcpu_pt_hvm ? " vCPU-PT" : " None"); + { + bool hwdom_pt = opt_dom0_pvh && opt_vcpu_pt_hwdom; + bool hwdom_sd = sparse_dmap_hwdom() && + (opt_dom0_pvh ? hwdom_pt : !opt_xpti_hwdom); + + printk(" ASI directmap mode: %s\n", + sparse_dmap_configured() ? "sparse" : "full"); + printk(" ASI features for Dom0:%s%s%s\n", + hwdom_pt || hwdom_sd ? "" : " None", + hwdom_pt ? " vCPU-PT" : "", + hwdom_sd ? " sparse-directmap" : ""); + if ( IS_ENABLED(CONFIG_HVM) ) + printk(" ASI features for HVM VMs:%s%s%s\n", + opt_vcpu_pt_hvm ? "" : " None", + opt_vcpu_pt_hvm ? " vCPU-PT" : "", + opt_vcpu_pt_hvm && sparse_dmap_hvm() + ? " sparse-directmap" : ""); + if ( IS_ENABLED(CONFIG_PV) ) + printk(" ASI features for PV VMs:%s\n", + sparse_dmap_pv() && !opt_xpti_domu + ? " sparse-directmap" : " None"); + } } static bool __init check_smt_enabled(void) @@ -1956,9 +2033,10 @@ void spec_ctrl_init_domain(struct domain *d) /* * The sparse directmap view needs a mapcache: PV domains all have one, - * HVM domains through per-vCPU page-tables. + * HVM domains through per-vCPU page-tables. A PV domain using XPTI + * stays on the full directmap. */ - d->arch.asi.sparse_dmap = (pv || d->arch.asi.vcpu_pt) && + d->arch.asi.sparse_dmap = (pv ? !d->arch.pv.xpti : d->arch.asi.vcpu_pt) && sparse_dmap_wanted(pv, is_hardware_domain(d)); } -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463815.1674836 (Exim 4.92) (envelope-from ) id 1xMD7G-0007nL-2i; Wed, 28 Oct 2026 23:31:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463815.1674836; Wed, 28 Oct 2026 23:31: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 1xMD7E-0007gm-Qp; Wed, 28 Oct 2026 23:31:32 +0000 Received: by outflank-mailman (input) for mailman id 1463815; Wed, 28 Oct 2026 23:30:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6P-00055U-NC for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOJ-36qj; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjN-00000001KpM-3zh4; Wed, 28 Oct 2026 23:06: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" 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=5bWt48oVbFgfls5ydUXDK8NsiQisFqKXCpJUHopfOnc=; b=SDTvLHjW/YSxnSJ3a96OEGrNH8 56YaEkp6Ix9pie1XPnaoAu/WYXDehwNiRzrU5VfXWm7Pxan/VdCBgJ1hmMAFdHQbpPCV+zUNN8Q6R PCqqQhldGWeP9z3XhJwYSG4XMKWXIufzsZX3kPOLTGgq5Y6b8t6jAp0+z6U38ZDgInaQ=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v5 17/45] x86/mm: add hooks for a sparse view of the directmap Date: Wed, 28 Oct 2026 23:05:31 +0000 Message-ID: <20261028-asi-hvm-v5-17-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The directmap maps all of RAM, and every root page-table carries it, so while any guest context runs, all guest memory is reachable from Xen's address space. For ASI, guest contexts are to run on a sparse view of the directmap which maps only what Xen must reach through it at all times, leaving guest memory to transient mappings (map_domain_page()). A later patch builds such a sparse view alongside the full directmap, once the boot allocator has handed its memory to the heap. It is then kept in step: - xenheap allocations are added, and taken out again before the pages are freed. If that fails the pages stay mapped, and are leaked with a warning rather than reused; - memory handed to the heap later (boot modules, .init) is taken out, and is not handed over if that fails; - a PV dom0's initrd, assigned to dom0 in place, is taken out; - page-tables from the boot allocator, which the sparse view maps with every other boot-time allocation, are taken out when idle_pg_table's hierarchy frees them, and are not freed if that fails, so that the sparse view never keeps a page the heap may hand out; - changes to the full directmap through map_pages_to_xen() and modify_xen_mappings() are mirrored. After boot, map_pages_to_xen() maps into the directmap only memory Xen keeps (stack guard and shadow stack pages, firmware tables); memory hot-add maps the new range into the full directmap only, so that the sparse view never needs page-table pages for it. Add a hook at each of these points, and one where the view is to be built; x86's are stubs in a new asm/sparse-directmap.h. map_pages_in() and modify_mappings_in() are no longer static: memory hot-add calls map_pages_in() on idle_pg_table, and the sparse view will use both. Common code gains four hooks for this, arch_heap_pages_init(), arch_xenheap_needs_scrub() and arch_xenheap_pages_{alloc,free}(), no-ops until an architecture implements them. A failed arch_xenheap_pages_alloc() may have mapped part of the pages: alloc_xenheap_pages() then takes them out through arch_xenheap_pages_free(), as a free would, before freeing them, and leaks them if that fails too. alloc_xenheap_pages() accepts pages still awaiting scrubbing (MEMF_no_scrub). That is harmless while the directmap maps all memory anyway, but the sparse view would make such a page's contents, a dying domain's data for instance, reachable from every context on it until overwritten. With a sparse view configured, arch_xenheap_needs_scrub() makes xenheap allocations scrub those pages first, as domain heap allocations do; clean pages need nothing extra. arch_mfns_in_directmap() says whether an MFN range is reachable through the directmap; it now answers for every context, so false once a sparse view is configured. Its one caller, init_node_heap(), then keeps a NUMA node's heap metadata in the xenheap instead of carving it out of the node's memory through the directmap: carved out of a range handed to the heap, it would be left out of the sparse view, which every heap allocation needs it in. The hooks for now are just stubs. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v5: - New in this version, split out of "x86/mm: build and maintain a sparse view of the directmap". --- xen/arch/x86/include/asm/mm.h | 12 +++++- xen/arch/x86/include/asm/sparse-directmap.h | 30 +++++++++++++++ xen/arch/x86/mm.c | 30 ++++++++++++--- xen/arch/x86/pv/dom0_build.c | 4 ++ xen/arch/x86/setup.c | 4 ++ xen/arch/x86/x86_64/mm.c | 10 ++++- xen/common/page_alloc.c | 41 ++++++++++++++++++++- xen/include/xen/mm.h | 21 +++++++++++ 8 files changed, 142 insertions(+), 10 deletions(-) create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 12d1c06c12..6264f67af4 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -7,6 +7,7 @@ #include #include #include +#include #include /* @@ -597,6 +598,11 @@ mfn_t alloc_xen_pagetable(void); void free_xen_pagetable(mfn_t mfn); void *alloc_mapped_pagetable(mfn_t *pmfn); +int map_pages_in(l4_pgentry_t *root, unsigned long virt, mfn_t mfn, + unsigned long nr_mfns, pte_attr_t flags); +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, unsigned long e, + pte_attr_t nf); + int __sync_local_execstate(void); /* Arch-specific portion of memory_op hypercall. */ @@ -657,12 +663,16 @@ void write_32bit_pse_identmap(uint32_t *l2); /* * x86 maps part of physical memory via the directmap region. - * Return whether the range of MFN falls in the directmap region. + * Return whether the range of MFN falls in the directmap region in every + * context: never, with a sparse directmap view configured. */ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) { unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END); + if ( sparse_dmap_configured() ) + return false; + return (mfn + nr) <= (virt_to_mfn(eva - 1) + 1); } diff --git a/xen/arch/x86/include/asm/sparse-directmap.h b/xen/arch/x86/include/asm/sparse-directmap.h new file mode 100644 index 0000000000..53747a98ad --- /dev/null +++ b/xen/arch/x86/include/asm/sparse-directmap.h @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef X86_SPARSE_DIRECTMAP_H +#define X86_SPARSE_DIRECTMAP_H + +#include +#include +#include + +static inline bool sparse_dmap_configured(void) { return false; } +static inline void sparse_dmap_init(void) {} +static inline int sparse_dmap_mirror_map(unsigned long virt, mfn_t mfn, + unsigned long nr, pte_attr_t flags) +{ + return 0; +} +static inline int sparse_dmap_mirror_modify(unsigned long s, unsigned long e, + pte_attr_t nf) +{ + return 0; +} +static inline int sparse_dmap_remove(mfn_t mfn, unsigned long nr) +{ + return 0; +} +static inline int sparse_dmap_drop_pagetable(mfn_t mfn) +{ + return 0; +} + +#endif /* X86_SPARSE_DIRECTMAP_H */ diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 4bfb690017..6028408b82 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -127,6 +127,7 @@ #include #include #include +#include #include #include #include @@ -5425,10 +5426,17 @@ mfn_t xen_map_to_mfn(unsigned long va) /* * Free a page-table page that the hierarchy rooted at @root has stopped - * using. + * using. One of idle_pg_table's may be in the sparse directmap view: it is + * taken out first, under the sparse view's L3 lock inside an L3 lock of + * idle_pg_table's hierarchy (the only order in which the two nest), and + * kept if that fails. The sparse view's own page-tables are not in it, and + * are freed directly: the caller may hold the sparse view's L3 lock. */ static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) { + if ( root == idle_pg_table && sparse_dmap_drop_pagetable(mfn) ) + return; + free_xen_pagetable(mfn); } @@ -5436,7 +5444,7 @@ static void free_pagetable_in(const l4_pgentry_t *root, mfn_t mfn) * map_pages_to_xen() in the hierarchy rooted at @root: idle_pg_table's, or * another hierarchy sharing its virtual addresses. */ -static int map_pages_in( +int map_pages_in( l4_pgentry_t *root, unsigned long virt, mfn_t mfn, @@ -5848,7 +5856,12 @@ int map_pages_to_xen( unsigned long nr_mfns, pte_attr_t flags) { - return map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); + int rc = map_pages_in(idle_pg_table, virt, mfn, nr_mfns, flags); + + if ( !rc ) + rc = sparse_dmap_mirror_map(virt, mfn, nr_mfns, flags); + + return rc; } int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) @@ -5871,8 +5884,8 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) * modify_mappings_in() does so in the hierarchy rooted at @root, as * map_pages_in() does. */ -static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, - unsigned long e, pte_attr_t nf) +int modify_mappings_in(l4_pgentry_t *root, unsigned long s, + unsigned long e, pte_attr_t nf) { bool locking = system_state > SYS_STATE_boot; l3_pgentry_t *pl3e = NULL; @@ -6152,7 +6165,12 @@ static int modify_mappings_in(l4_pgentry_t *root, unsigned long s, int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) { - return modify_mappings_in(idle_pg_table, s, e, nf); + int rc = modify_mappings_in(idle_pg_table, s, e, nf); + + if ( !rc ) + rc = sparse_dmap_mirror_modify(s, e, nf); + + return rc; } int destroy_xen_mappings(unsigned long s, unsigned long e) diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index dcb1d407ec..f18959f3b4 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -22,6 +22,7 @@ #include #include #include +#include /* Allow ring-3 access in long mode as guest cannot use ring 1 ... */ #define BASE_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_USER) @@ -650,6 +651,9 @@ static int __init dom0_construct(const struct boot_domain *bd) { if ( assign_pages(mfn_to_page(_mfn(initrd_mfn)), count, d, 0) ) BUG(); + /* The initrd is dom0's now: out of the sparse directmap. */ + if ( sparse_dmap_remove(_mfn(initrd_mfn), PFN_UP(initrd_len)) ) + panic("Cannot unmap dom0's initrd\n"); /* * We have mapped the initrd directly into dom0, and assigned the * pages. Tell the boot_module handling that we've freed it, so the diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 446cd81276..bdc43dfe58 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -54,6 +54,7 @@ #include #include #include +#include #include #include @@ -1949,6 +1950,9 @@ void asmlinkage __init noreturn __start_xen(void) system_state = SYS_STATE_boot; + /* The heap now has all memory: page-tables come from it from here on. */ + sparse_dmap_init(); + bsp_stack = cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ if ( !bsp_stack ) panic("No memory for BSP stack\n"); diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 7b04537066..c5d9dd64a3 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -1231,8 +1231,14 @@ int memory_add(unsigned long spfn, unsigned long epfn, unsigned int pxm) i = virt_to_mfn(HYPERVISOR_VIRT_END - 1) + 1; if ( spfn < i ) { - ret = map_pages_to_xen((unsigned long)mfn_to_virt(spfn), _mfn(spfn), - min(epfn, i) - spfn, PAGE_HYPERVISOR); + /* + * Into the full directmap only, not a sparse directmap view: the + * frame table and M2P carved from the start of the range are + * reached through their own mappings, and the rest goes to the + * heap, which the sparse view leaves out. + */ + ret = map_pages_in(idle_pg_table, (unsigned long)mfn_to_virt(spfn), + _mfn(spfn), min(epfn, i) - spfn, PAGE_HYPERVISOR); if ( ret ) goto destroy_directmap; } diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 5243dba29f..2150dcbd5e 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1971,6 +1971,9 @@ static void init_heap_pages( unsigned long i; bool need_scrub = scrub_debug; + if ( !arch_heap_pages_init(page_to_mfn(pg), nr_pages) ) + return; + /* * Keep MFN 0 away from the buddy allocator to avoid crossing zone * boundary when merging two buddies. @@ -2540,10 +2543,33 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags) if ( !(memflags >> _MEMF_bits) ) memflags |= MEMF_bits(xenheap_bits); - pg = alloc_domheap_pages(NULL, order, memflags | MEMF_no_scrub); + /* + * Pages still awaiting scrubbing may do as xenheap pages: the directmap + * maps them anyway. Not so if an arch's sparse directmap view makes them + * reachable where the rest of the heap's memory is not. + */ + if ( !arch_xenheap_needs_scrub() ) + memflags |= MEMF_no_scrub; + + pg = alloc_domheap_pages(NULL, order, memflags); if ( unlikely(pg == NULL) ) return NULL; + if ( arch_xenheap_pages_alloc(page_to_mfn(pg), order) ) + { + /* + * The hook may have mapped part of the pages before failing: take + * them out again as a free would, and leak them if that fails too. + */ + if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + printk(XENLOG_WARNING + "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", + mfn_x(page_to_mfn(pg)), 1U << order); + else + free_domheap_pages(pg, order); + return NULL; + } + for ( i = 0; i < (1u << order); i++ ) pg[i].count_info |= PGC_xen_heap; @@ -2562,6 +2588,19 @@ void free_xenheap_pages(void *v, unsigned int order) pg = virt_to_page(v); + /* + * If the pages cannot be taken out of an arch's sparse directmap view, + * they may remain reachable through it: leak them rather than hand them + * out. + */ + if ( arch_xenheap_pages_free(page_to_mfn(pg), order) ) + { + printk(XENLOG_WARNING + "Leaking xenheap pages %"PRI_mfn"+%u: still mapped\n", + mfn_x(page_to_mfn(pg)), 1U << order); + return; + } + for ( i = 0; i < (1u << order); i++ ) pg[i].count_info &= ~PGC_xen_heap; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 153c57f5dd..e8f9993286 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -94,6 +94,27 @@ bool scrub_free_pages(void); #define alloc_xenheap_page() (alloc_xenheap_pages(0,0)) #define free_xenheap_page(v) (free_xenheap_pages(v,0)) +/* + * Hooks for an architecture keeping a second, sparse view of its directmap, + * which maps the xenheap but not the rest of the heap's memory. + */ +static inline bool arch_heap_pages_init(mfn_t mfn, unsigned long nr) +{ + return true; +} +static inline bool arch_xenheap_needs_scrub(void) +{ + return false; +} +static inline int arch_xenheap_pages_alloc(mfn_t mfn, unsigned int order) +{ + return 0; +} +static inline int arch_xenheap_pages_free(mfn_t mfn, unsigned int order) +{ + return 0; +} + /* Free an allocation, and zero the pointer to it. */ #define FREE_XENHEAP_PAGES(p, o) do { \ void *_ptr_ = (p); \ -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463816.1674841 (Exim 4.92) (envelope-from ) id 1xMD7H-000820-Hu; Wed, 28 Oct 2026 23:31:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463816.1674841; Wed, 28 Oct 2026 23: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 1xMD7G-0007xU-4k; Wed, 28 Oct 2026 23:31:34 +0000 Received: by outflank-mailman (input) for mailman id 1463816; Wed, 28 Oct 2026 23:30:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6P-00057D-Ri for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOx-3sUs; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCjG-00000001KpM-2LLI; Wed, 28 Oct 2026 23:06: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=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=S/tsd9lGldh/FCRRWK8hPBso1PhupuXumoKhOFQc+oM=; b=HAoM4VTIuk0P/qFlRzRVuu3Lxj kZBmbtn9lr/JysfKrqtOYHXU56RnOvi+s4Ws8MFtChLDJJ7BrOPuCBbtwXOVU5iQaqaiWKIMa7Ylf JTruZEz9dfnCppcB2yZssb/irHA1P1eGNKpo8AzQ88OCQLMF06W+wYu+13j+W6Ysbf0k=; From: George Dunlap To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 10/45] x86/domain_page: drop redundant is_pv_vcpu() checks Date: Wed, 28 Oct 2026 23:05:24 +0000 Message-ID: <20261028-asi-hvm-v5-10-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The is_pv_vcpu() checks after mapcache_current_vcpu() never fail: they have been redundant since 622c9a5ba95d ("x86/mm: accurately track which vCPU page-tables are loaded") made mapcache_current_vcpu() do the check itself. mapcache_current_vcpu() is now guaranteed to return a PV vCPU with a caching structure (which is what is needed for the subsequent dcache->inuse check): either a scheduled PV vCPU, or this CPU's idle vCPU (possibly after finishing a lazy context switch). Drop the checks; their speculation barriers (evaluate_nospec()) go too. mapcache_current_vcpu() returns NULL if this CPU's pgtable_vcpu is not yet set (early boot) or is not a PV vCPU. Otherwise it reads pgtable_vcpu again and returns that. In between, pgtable_vcpu changes only when a lazy context switch from a PV vCPU is completed, by mapcache_current_vcpu() itself (sync_local_execstate()) or first by an interrupt such as a FLUSH_VCPU_STATE IPI; completing it loads the idle vCPU's page-tables and sets pgtable_vcpu to the idle vCPU. No other writer of pgtable_vcpu runs in an interrupt that returns to the code it interrupted. During an EFI runtime call pgtable_vcpu is the idle vCPU: efi_rs_enter() completes any lazy switch, then loads EFI's page-tables, which carry the directmap. So the vCPU returned is either the PV vCPU checked or this CPU's idle vCPU. The idle vCPU passes is_pv_vcpu(), as the idle domain is created without XEN_DOMCTL_CDF_hvm, but its mapcache is never set up: domain_create() returns for the idle domain before calling arch_domain_create(), which is what calls mapcache_domain_init(). With its dcache->inuse NULL, map_domain_page() uses the directmap, and unmap_domain_page()'s ASSERT() on dcache->inuse still catches a mapcache address unmapped with no mapcache in use. In builds without CONFIG_PV, is_pv_vcpu() is always false and mapcache_current_vcpu() always returns NULL. No functional change. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- Changes in v4: - New in this version, split out of "x86/domain_page: prepare the mapcache for per-vCPU accounting", with a justification of its own. NB I've included Claude's complete analysis in the commit message. I've reworded the commit message so that the middle two paragraphs can be dropped, or reworded more briefly on commit. --- xen/arch/x86/domain_page.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index f3e65e2d44..ed68483695 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -74,7 +74,7 @@ void *map_domain_page(mfn_t mfn) #endif v = mapcache_current_vcpu(); - if ( !v || !is_pv_vcpu(v) ) + if ( !v ) return mfn_to_virt(mfn_x(mfn)); dcache = &v->domain->arch.pv.mapcache; @@ -179,7 +179,7 @@ void unmap_domain_page(const void *ptr) ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END); v = mapcache_current_vcpu(); - ASSERT(v && is_pv_vcpu(v)); + ASSERT(v); dcache = &v->domain->arch.pv.mapcache; ASSERT(dcache->inuse); -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Wed Oct 28 23:31:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Oct 2026 23:31:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1463817.1674850 (Exim 4.92) (envelope-from ) id 1xMD7J-0008TZ-Ps; Wed, 28 Oct 2026 23:31:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1463817.1674850; Wed, 28 Oct 2026 23:31: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 1xMD7I-0008Nh-Do; Wed, 28 Oct 2026 23:31:36 +0000 Received: by outflank-mailman (input) for mailman id 1463817; Wed, 28 Oct 2026 23:30:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMD6P-00058X-UV for xen-devel@lists.xenproject.org; Wed, 28 Oct 2026 23:30:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMD6K-00000000pOr-3k4q; Wed, 28 Oct 2026 23:30:36 +0000 Received: from [217.155.165.12] (helo=Mac.fritz.box.net) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMCja-00000001KpM-08NZ; Wed, 28 Oct 2026 23:07: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=xyRRTvzAZ1uxBpB7gEOaI29dfhB9uSJD02k1XOtgRUc=; b=08tEDeZZW4jtuHB4xtir14VyHK 0eFQya78XTo9pKuaUFhRQkScUouJ/GSmcIae+vHBwODJZDIcvWpj2KeiwVCgAR/xEgq19kUsSD5CA FvyPcaBbz3/Gt0Cctx2rcfbjmpD1gnqTsakD8iCFDhWMt7gwre67j4HAT5Z7W8RdDNNs=; From: George Dunlap 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 v5 28/45] x86/svm: restore guest debug registers in svm_do_resume() Date: Wed, 28 Oct 2026 23:05:42 +0000 Message-ID: <20261028-asi-hvm-v5-28-13b908e0df0b@xenproject.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit svm_ctxt_switch_to() restores the guest's debug registers when its DR7 enables any of them, which also updates the VMCB. Do it in svm_do_resume() instead, which follows it whenever the vCPU is scheduled in. svm_do_resume() also runs when a vCPU keeps running on its pCPU (continue_running()), without svm_ctxt_switch_to(). Where the guest's debug registers are already loaded, the restore does nothing: flag_dr_dirty records that they are, and only svm_save_dr() clears it, from svm_ctxt_switch_from(). This prepares for moving VMCBs off always-mapped memory: svm_ctxt_switch_to() runs before write_ptbase(), where the incoming vCPU's VMCB will not be mapped. Not yet run with a guest using debug registers. Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-5-5 Signed-off-by: George Dunlap --- CC: Ross Lagerwall Changes in v4: - New in this version. --- xen/arch/x86/hvm/svm/svm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index b539406f0c..df56245311 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -953,8 +953,6 @@ static void cf_check svm_ctxt_switch_to(struct vcpu *v) */ disable_each_ist(per_cpu(idt, cpu)); - svm_restore_dr(v); - svm_tsc_ratio_load(v); if ( cpu_has_msr_tsc_aux ) @@ -978,6 +976,8 @@ static void noreturn cf_check svm_do_resume(void) bool vcpu_guestmode = false; struct vlapic *vlapic = vcpu_vlapic(v); + svm_restore_dr(v); + if ( nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v) ) vcpu_guestmode = 1; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 04:45:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 04:45:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464132.1674869 (Exim 4.92) (envelope-from ) id 1xMI1H-00085F-Qy; Thu, 29 Oct 2026 04:45:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464132.1674869; Thu, 29 Oct 2026 04: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 1xMI1H-000858-O4; Thu, 29 Oct 2026 04:45:43 +0000 Received: by outflank-mailman (input) for mailman id 1464132; Thu, 29 Oct 2026 04:45:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMI1F-000852-G0 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 04:45:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMI1E-009aqD-A1 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 05:45:40 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2cf69-e002-0a2a0a5209dd-0a2a450ad126-8 for ; Thu, 29 Oct 2026 05:45:39 +0100 Received: from [40.107.74.79] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2cf71-f2d2-0a2a450a0019-286b4a4f67f7-3 for ; Thu, 29 Oct 2026 05:45:39 +0100 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TY4P286MB7152.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:344::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 04:45:34 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 04: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=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=jrioarnpFLre8SxxRdpTAaL27V+rqN6EckKwTkskrSkscN1La1Dnv9sfzAElZBwnzvxbszeYmc9ZSPZkfQANDXetRw5h9dqGxGtPB08g7DBZmrjLsx3tws4llLJtTP7ook/QVdqnWw94eP0M0tWVidRsh5fOYaANwUFd+4qO/dfGJwrCWwkxr6zc4fLpNiZe55258oliSnhvYFOzsGOQrBffwyj6UGYO4myRl0PwZaTqe0Z/Tu8HwJsuGTzNsIMAlFIFiFYWSY6sEzJhaI8h44DhkUwXMrme7WaxlPX/OF1kEgctdYsKPFYJIPnxr6iJi9eu9sgCJNRUkz5yRHcpUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6EssaoHrsC91iDaQNMtVRO+SV6Rtzd2FHY/4yt5E0LM=; b=Bd1u7UE0P06myobq+g90rmtqkzHopSZi2QdMl6v/Er2zEj5N72zV75xefm7FjUu554gHlAbSxjMnnZP7LzH/jkQ06+9KjUAWE5PmZYgm2n6KMt8tM/lw66oRqJrc8a89dt3YQekoKzNOxeHEFUP98IR57bBM5hLlv3ajuTuNmy0r8r0c/XfLPz45LEq+nNBazQ3NnGrUdymebdGpOoTA/lc2/EBm+q3dnv7uiGS0Q083q5XktHoxrD0ZDZSVU/GuxI3cbdkva+JCbyBjtUC1zJUYKgEDuPyJQN5vxoNoW443oZS+aZyG/jzOSQCWRSGSo0pYv4vaXHIzqw+MHmcabw== 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=6EssaoHrsC91iDaQNMtVRO+SV6Rtzd2FHY/4yt5E0LM=; b=sk5ex2kBECXmuZ82/lmn0hKlCdZF7mc8uwPWmIgfh7XAEGz00J+mjDGIUKUgusg+yLTkv9/iazvtQ1Kcn/qF1Ct43PAUoFw+0qtb5Qpd00uBECJlJoMV5l2Th7P5BpOcyLmssRRc2SGgnWyV+BMyURwZ7xbBbousr+/p/NdUW5g= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: andrew.cooper3@citrix.com Cc: xen-devel@lists.xenproject.org Subject: Re: [RFC 0/5] Introduce dynamic tracer using Livepatch Date: Thu, 29 Oct 2026 13:45:11 +0900 Message-Id: <20261029044511.28285-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <290dd295-bd1c-442a-874c-de4565932da9@citrix.com> References: <290dd295-bd1c-442a-874c-de4565932da9@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0177.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:3c6::20) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TY4P286MB7152:EE_ X-MS-Office365-Filtering-Correlation-Id: 1182fab0-09cc-4347-fe9b-08df3577786c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|261028144727099003|260925022911599003|260925021911599003|260925021311599003|56012099006|261009223027099003|261026121527099003|261026140227099003|261022105027099003|10067099003|261022075727099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: cfgcoXGCkU6mbv8E98tbNhT9dC15a7wcmg4yv+TXKszaWfdxhYuGKBfUxR2Htq/7wS+Hy+mrSdoacgW6HgBtvtBSf20Dl/a9aImG+VpMOhhXJG0JUUpjZ1BmraHdebAyKxpnOZ7uOICzdc2fqpMkgTRBaZBrg2vD2h7UH8Yyhhn6cHrNJ1/Bqg2CePEKmq31LRRe1Qd89o9dru2LQCAhECjF3xYcv0jGgaeSdzoH4i80LevJI4e9h6UPtZozyRCGXolnIUZiTXaLd+gh482t/kfIZzX54r46BHq81MMHMZLn60q9yoPcpKZXuyVYIHxDE5ggSX65p1dKfAUEUMMQ2Ye8uZLb5Ur0paraKUvqCbDp3O9GoWvgWZwpppzye7OhmSgPrBPJKebE37ybmoeRpDgQ3RGMGfDe0+tw3yyCDw5T9GtxK9blvXPDys7QsH6KGQTgF7vQ5XKF/nyTI/icxNFGOxBixvIvS8AD29erBixZqi6kv3x0ghWEhb+ut5EQxHplEh2W8KhVmYFM2H9KiiDxi92AucLJ604WYRbRLnfv99gnKUiIfJYc5FHMDggrTBk2+Inq5iKTr3uyiL5zGjfj6IEJ9AOkHGEIwsCWefgEZxapMO5i0lw4qbVkHwo+Vi7MnbvTUEXg7HJrE9EY/tsUaPUBEPqk2rjFg2EO+9c= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(261028144727099003)(260925022911599003)(260925021911599003)(260925021311599003)(56012099006)(261009223027099003)(261026121527099003)(261026140227099003)(261022105027099003)(10067099003)(261022075727099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bWDF1Qn8Ulziw83J7CAgVWhV+e+y3JAmb9fvy0AbUBxdKme63mt9CZ0KkZtc?= =?us-ascii?Q?wWEz93jJquDqc9wCmx2Z3GGOeY8zW6Je3XkczqVFVTTdKpb0mAuz63W98WLk?= =?us-ascii?Q?ifd+7OUy02CQg7Mnw7K4kKPQ3oBpm0WhKyWtYqYPRsQGcV+lFtDtlsxGsVcX?= =?us-ascii?Q?l1FKP6PRLlW8JJN6vQmuKSMGrpX04JMKmuQxOOpUsJZ0oyKTJnRLAXz3pkU3?= =?us-ascii?Q?p6H6WrU4u7QqhR3XfDVjWOUETy52M4IoURCzX8VkHaDktEvcCn09o3JhSg7h?= =?us-ascii?Q?ifH5/TVi9EyQLy2AitA9KH5oN/1tZBsnzWssfqICH8vtrFd3arkIbOybPw8h?= =?us-ascii?Q?KxCgXVd+gTUtPq6XbR7VYCFrYYl9PuSNsWSW/dNl7aC4W9YOTO04xLHeDyb9?= =?us-ascii?Q?D12nPCAIOcCxnaHKh8TZqyicFbcuxNRpTDNJfSzUwkGgCanq4wkbs/nPy97Y?= =?us-ascii?Q?6q1RIItw+qT/m6mhswJo8MeRZ4wNuDEDwwuN+16gH8jGGZW2vEm5f4SWRixJ?= =?us-ascii?Q?n/WfX/mvd+Q4crgMzdGOFACXh4AHe6IZIOp67n94k7wx45/m3RExb9WD7bva?= =?us-ascii?Q?GwrRYL+2WcorqMMOIFp56BxfbwGXnfu1aWZix5gH+tK7Dhc4wnDyvAL/NxVr?= =?us-ascii?Q?upNoCOpPKHSNvDP8yKLvTuRCpLbTF1Ovf5xJS/w08CptJi+cbRUpd7lvgKsP?= =?us-ascii?Q?QPOq6IMh3wPZ7Ldk77Nl1eAEHov5Ia0GqnKU74bVRCewRavBO3fiRw9s0DFy?= =?us-ascii?Q?mQ4pAZyNepDLB7aO2weMY0JWayhX6M3WEPuWoeGblywe9e1fytOVrEiZlS0z?= =?us-ascii?Q?41V7ZVT7m9n2rxQv/KGgKKQ/7oDq7dZsz3/MCIY4xuuwdMvzG58gP3xq+/nQ?= =?us-ascii?Q?Wsz4FgraR3OXOFtRGEUGgU0oz94dtrNVWZfNSHkR5P4fxvl+AV6zwMulSGvx?= =?us-ascii?Q?qRj4sK9fL0+xVp5v34wjEGxcdDuL3PjKRYJ9EUM5t+bvAtuxefNdi0WMdpSq?= =?us-ascii?Q?qcgnI1UUVcxzz7zy4goPyaodrQ4KBj8FuXwu6dHoNgzJDM15e3PwmeOVOmQd?= =?us-ascii?Q?+30692cd4N97IJPekk7OT2MICNsQI/KIRFwoD2gSN5sX8jzhsPpdmSQMNyAD?= =?us-ascii?Q?OcBfCFWegclBl5j4OA8W/k0Di0ArzNpQTvcKcUHBCmA1xWW/xNm0tP9LefIM?= =?us-ascii?Q?42+8AiL4wUoNgd/QJJLUZhS3IoSNpIoQte58C0KtJjaBBVNVronzC6w/Ww+w?= =?us-ascii?Q?dxpJ67wKQQ2GeMPc1jCtudyC6sd2jUY51aAnyXB/SRDflixvFPOB56N5L9i3?= =?us-ascii?Q?EMhXJA8432bo12FpB+7MHFfnp/j0A2F6LAzADYY3Kt2xcuYoIuUNesViuwj4?= =?us-ascii?Q?2izJdg7X1bHUInx9BMjik7PNRrgiLXWWdJ01aP+/OyzCdhW3n7SrUHcdo6EB?= =?us-ascii?Q?jHKIy9m6AG0rQPgDY9iMFXXFQNYDlWKKQXcb3r6jOWWarxVx80zzkyvz7xSE?= =?us-ascii?Q?07pIWG5IAW72cQbt35zIfmKs87Lo1WavVNkX0Pgy07YSCF5xykE3HYEGfrEm?= =?us-ascii?Q?wC0bTXdMoNqW04VXW29yT7Cqm56wdjCZGaGKqX4qH4UBPVGjGoqzkhByr7cp?= =?us-ascii?Q?ooXddJhlB3nR1TPGzc8yiLGOt7r73mOQbxSPYMXlV9BOqn7LqfxhxzaWEfW5?= =?us-ascii?Q?jlSDGlyHZOWRbU7l4ZyzzZHtx/fU6vqIrwRO5nGXXHNSKLIjZ3X18AVXlXRn?= =?us-ascii?Q?P90PoNtSgg=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 1182fab0-09cc-4347-fe9b-08df3577786c X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 04:45:34.8456 (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: /T4r8YVuzCbKhQi8yEe1AIoQolVuO4+ZhZeJK8NWnf8j5BMNhf3XpbSkwz/oGTov9fY4Lx0IL8ucpt/Rhvg2aA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY4P286MB7152 X-purgate-ID: tlsNG-4011c0/1793249139-4B8D5CFC-14BA37C0/0/0 X-purgate-type: clean X-purgate-size: 1695 On Wed, 28 Oct 2026 18:22:21 +0000, Andrew Cooper wrote: >On 28/10/2026 8:08 am, Ryo Takakura wrote: >> On Tue, 27 Oct 2026 10:18:44 +0000, Andrew Cooper wrote: >>> >>>>> Separately, you have a number of MISRA violations which you're >>>>> introducing in your series. I see you've got cf_check, which suggests >>>>> you have built in GitlabCI. Have you also run Eclair? >>>> Thank you for pointing this out. >>>> My apologies for the violations. I wasn't aware of the tests >>>> and haven't run either of them. I added the cf_check following >>>> the existing code that I referred to when preparing this series. >>>> I'll make sure to run those tests before sending next version. >>> Do you have an account on Gitlab to run the CI testing? If not, reach >>> out on Matrix. >> I don't have an account yet. >> Ok, I'll ask on Matrix. > >To get you started, I put this series through: > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/3000384733 > >There's one Eclair failure on ARM. Thank you for running the test. I see the report saying its violating MC3A2.R1.1. I'll fix the issue and make sure it passes the test. >Interestingly, it's not the failure I was expecting to see. I was >expecting it to complain about > >+ uint32_t insns[2] = { >+ aarch64_insn_gen_nop(), >+ aarch64_insn_gen_nop(), >+ }; > >because of the order those function calls being undefined. > >I was also expecting to see some failures due to arithmetic on pointers >of different types, but maybe we've not made those rules enforcing yet. I see. I'll make sure to address them as well in the next version. Sincerely, Ryo Takakura From xen-devel-bounces@lists.xenproject.org Thu Oct 29 04:59:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 04:59:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464143.1674879 (Exim 4.92) (envelope-from ) id 1xMIEA-0002OH-Tx; Thu, 29 Oct 2026 04:59:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464143.1674879; Thu, 29 Oct 2026 04:59: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 1xMIEA-0002OA-RE; Thu, 29 Oct 2026 04:59:02 +0000 Received: by outflank-mailman (input) for mailman id 1464143; Thu, 29 Oct 2026 04:59:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMIE9-0002O4-4s for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 04:59:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMIE8-00D1rS-1f for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 05:59:00 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2d22e-bab6-0a2a0a5309dd-0a2a4501962e-48 for ; Thu, 29 Oct 2026 05:58:59 +0100 Received: from [40.107.200.12] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2d292-5984-0a2a45010019-286bc80c7086-3 for ; Thu, 29 Oct 2026 05:58:59 +0100 Received: from BL0PR12MB4754.namprd12.prod.outlook.com (2603:10b6:208:8e::26) by SN7PR12MB8026.namprd12.prod.outlook.com (2603:10b6:806:34b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Thu, 29 Oct 2026 04:55:54 +0000 Received: from BL0PR12MB4754.namprd12.prod.outlook.com ([fe80::ebe5:87e:6d95:580c]) by BL0PR12MB4754.namprd12.prod.outlook.com ([fe80::ebe5:87e:6d95:580c%4]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 04: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=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=MrrEddOAundabNM5EEMCGG8x26bfMiAgdSAcVKK2hJIsjsn3sultXySypC9+Y3XyLFlHWp1Cz4mPK0L7f67j3MONZPr5D/NPM+8MVIGYafQOwBJ9Plldc5rwkxjWEvKIBTXYi5GxUGsyxhLhbL54wal7BvIUmrKNtv1znp63LzAUQKyLQvb/QpB3RxzIakXxji5qkjfhy3qYvyJRIEEqJduHoGI165slu9Q4Z3TO0RC/y0gdMJY6yYChwfQebBPAebSfjuoabIW1CRGshj/vfSntRHH9hnF3Gauf+SU8S8XXFTgV99hCudpdOPWceKmJJaxKsPhi+GUQWmpxRmda1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iTMKhlUDo+SOon0xuAedhYFCaX26pCDUixJNJEEiruw=; b=RUeQJvAZGhVc0NsW/yN7bLSa7kxbHZt29fwecbVr7I6NwwVLPAH2froYv10+wb8uru266BQ27dk4iETdg6XIMORva0QpIco0l7mxgXCZYjsvC0ywfh5vDi/zc7OcG7dW5ss25VfT0ieMM7JWKxZfW1U4oPv66tSIuPuJBg+hNbdGaEG87FhYCkZNBt147JJD/yuEX/9cEiu8lugEWcTt6yTVWmSI3A4GL1tTBxbiDLjMOIlNMYfFI7aleI1I1D8+GePRYl374XiOqlzfUAkHUHmGXUYbO9LLLBYRHRvfFZdIxQtT5g+1XsWcgXhSSqhdT3W1dHFTxo7JJhJ3tn+nzw== 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=iTMKhlUDo+SOon0xuAedhYFCaX26pCDUixJNJEEiruw=; b=rrZiu1S/T5yuWgSTn42c8wRRpJ/QIb+CKqe0tPPnKFUlo3859gv/6bKNmGfVbfLOqW3/FWlf+nDsyra6lSK9N9fq/YVwu+F1QOyMA2Q8wLZFjfR7dPF/dHNdikw/W8ATg9o1R6a59NO8ZZgvdzzxxjVrXJ+gsiuP+nItI3ZUuKk= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <8fe9ceb1-7418-44e1-ae9f-cc03b872b3a2@amd.com> Date: Thu, 29 Oct 2026 12:55:43 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen/typesafe: don't brace-initialize a scalar TYPE_SAFE value To: Jan Beulich Cc: Nicola Vetrini , Stefano Stabellini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Alejandro Vallejo , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org References: <20261028050336.2549325-1-shuaidong.chen@amd.com> <0af0a00b-4f9a-4584-ac5b-554ae00e692e@suse.com> Content-Language: en-US From: "Chen, Shuaidong" In-Reply-To: <0af0a00b-4f9a-4584-ac5b-554ae00e692e@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI3PR02CA0009.apcprd02.prod.outlook.com (2603:1096:4:295::14) To BL0PR12MB4754.namprd12.prod.outlook.com (2603:10b6:208:8e::26) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL0PR12MB4754:EE_|SN7PR12MB8026:EE_ X-MS-Office365-Filtering-Correlation-Id: 6dccb8b0-26d5-4bd9-0054-08df3578e8ba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|7416014|261026140227099003|5023799004|261028144727099003|11063799006|4143699003|56012099006|261026121527099003|261021121427099003|261009223027099003|10067099003|261022075727099003|261022105027099003|3023799007|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: flgdc227IGD/wJ+c3WNAI7W7nppGCttpqapNde48VsvcGo7Ldq7B6M3HL8ZHP8NgCKVxdyDqMtjUnag4BR+o65wcCcRpE5V3z9R6qy9XrXZDXvmyd/TA/kUcVGn77P8/F49wVChMlCFhcFqD/URh1PKYsMTJfSd+sDGjdyVWLRWkBt+l1k5PKU9/z7nPTZuH2q2vu8XwyKskY3cZvw7lPORNmLlJvBRNoK+BHs5DfpSJP207vmAL5DntwcrZO284hshym6PZNfF1ceI2HKqnr8G796OU30pKJaGulmpnra1h/FsVHhakE5hiUCR8htxaQb/ZkuWnNuvJWJeOxmees/BI6VNbq4PyXTn6CJF6TVz3IFiYNATVZdWjydH9NFVwYR3vo3fiEubw4oq8xBnKZiEOwOQcarEHEA8brgurZ2y6iBpLJCzPJti7msB0GwZUNA31xeMJ5ESOh+HYFGxoJx8ywEhk2oumbax9k2xhOnEOOFXMnoM2D71y/KosX8zkEWod5sGIdpRyNdpptA22w/mRgo8zNiJVSYqTToJyhlclTlaRc/YoZWVVfXVGyx+TZUCIZM1/Z9IJXGV6CDTZEVHh8/9A5UZKL1N8wiJ+W536R6QeqB/CzJk6RuNebsGX5gEoAMXEIMLmkYPPX4cECaqQIAzVnNBOBpDnx6IkpzE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL0PR12MB4754.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(7416014)(261026140227099003)(5023799004)(261028144727099003)(11063799006)(4143699003)(56012099006)(261026121527099003)(261021121427099003)(261009223027099003)(10067099003)(261022075727099003)(261022105027099003)(3023799007)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QVF2cWZJMldMRTdhWWduc01GYWxoa0FWeHB1NEFpZDVhRU41b21DclRCTFIr?= =?utf-8?B?OTg3Y20xaUkwME92NENXSXp6cGZhZGcwMitkTThqaEVZQ2RRNnlBZmdJRGxJ?= =?utf-8?B?UlNSV3ZrWDB4Y1g2OGZhZTYrVjVkeGJHQytSVm9YTnNneFlTOW84QWk1RHhL?= =?utf-8?B?MWxyeWdSbXdaRndJcnpvdDVtL0VEaThPUVhiWGljUWM5a0ZINU9Kb3EvTFo4?= =?utf-8?B?bzNhaE1GbUZZdUswNG9HZGZlSjdiYklCWlVyOVVJTHZreDZkT0ZmclhkZGxZ?= =?utf-8?B?OGp3VGRMWm9hYVlYUlprZ2gwQ2F5Q0tQSm5GbVYxSXA4ejZFV0lvTW1LYmps?= =?utf-8?B?WDhXRDRHbGdoT0FVd241RWUvSlNlbXZBRUVHRktHMStZQmVxQ0dDaW9YQ1JK?= =?utf-8?B?dk5QblBOcFcxZlFSamJKZ3NpZDRKakhIc1hDVGVZV2Z6M0c5Nml2Y0tGQ2I2?= =?utf-8?B?SVN2SlowNmdkSmN5ZnlmVlB5VlFYdlhqOC9LR25MNURUVnF4Wm56SjNoeDZS?= =?utf-8?B?SGJKT2g1dks5bkdEQzZGYkFvd29TRVhNdjFSRnkzVWRpeXdCT1h1SlhPWTVu?= =?utf-8?B?T2M1ZGVaTlRmTHpLV2Q5ZVdhOHZPRlNxdHZRcE0rWVJud05lc0l3UGorS1Nk?= =?utf-8?B?Zm9aSXZYSy91VGozL2pEQnRUd0I3TnFEV3Yxem5Fd2Y3NnhHVjdwbnljdmdC?= =?utf-8?B?TWhCbUR0MUhmTVpQTFFxb2NidEJEL0pNaDJOaVZKcVd3VWhwdnBKQWhLQlMz?= =?utf-8?B?SUExZ0RtajJWb1dnZCtKMndpOFFBMTE4S1Ywb3VlbEMyUHlXVExIS0tOUVd4?= =?utf-8?B?NFppdUM0bjhGcnlCK0c2dEp1YW5uTzJCb2NBbnZRUW1OaTNIU09McmxpSnpV?= =?utf-8?B?b2hpVXpZWUFxMFN6R1FxcFpUZGcyclM2bWpLVGVucFI2S1hqT09vMTVIeDZU?= =?utf-8?B?Z0dBQm5oc2VzSWgvRGpGRWRkYjVwdUJnM1g3Tmc2aXRoR2xQMXF0a2Z5a3RG?= =?utf-8?B?ZXB3UG1LREMxQ0xSUHYxOUFDMXVLc1lzMWZNcFcrL3ZyV0FFQXNBa0QxZXlJ?= =?utf-8?B?ZHNOU2tVRnBNSWpEaWt3MWxBTWdPMGplNmFBMmhMMG9USmgvNUxQUXdmcnZM?= =?utf-8?B?c05ZNGE4WVZOaFhTZGxvbUJvRlhaZVpMdndrMjlnZHE0cmZYUkNJWG12dlNP?= =?utf-8?B?ZTZTL1BEQ3g3V2cvajZYOWJzdzh4WjhIWU4xWHgwRThlUURGRTgraElTWGpM?= =?utf-8?B?Rit5bEtoQXFBbGZLRG16ZDVueko5b0Mrak9HM01oSTVQRGdiRXQzQitHZW1w?= =?utf-8?B?ODFiUSttY1RFcFQ2OGliaytJZXVsbXpiMXZqak5OaUFyUnNpak5tdFdOOU43?= =?utf-8?B?NU1LOWNaWENGcEJ1Z1RuT1VCMnl3UWs2UnhXM20ySUp0a3ZtNUZaRU9GZUVx?= =?utf-8?B?VDZuMTA5Q1RwRFJ1SnRKSjkyWHBaNVpRY1ZTa21xQ1EzNnM0UFZIdzJaMlQx?= =?utf-8?B?Rm5xd0pCdVdZZGxDMGhVdFNMMnMrVGNmRVk2cG1qZ3VUdjNIVm5lN1BVQVc5?= =?utf-8?B?a0REQmNiaTlZKzY2WTgydHRhUmtYcUhkNTVPVDFqOTB3V09vbGtiY0VEVHlp?= =?utf-8?B?SVdEYVozN2wySzM0UGVVMEtKSncyZ05UVGpKYW00Y2Z4NGRIRUFsQ2dWamY3?= =?utf-8?B?RVNpWGFvS2JRT1NOTjRWcGVHTmRiZldkOXQ4V0wwUzhFVU9WN3Uvb0F2ZmdS?= =?utf-8?B?SjdHT2ltRkltRkdRWGlNbmNEQXBTcjF5RElmRkdYbkpBb1ROelJuZ2w0R2FU?= =?utf-8?B?cDIxY1M3M2xXUGp3aXV3Y0JzVVpZbnltenVRZEpCUmdBRTNUOWQ1Q3dvNW82?= =?utf-8?B?NndPNFQ4VzRjTE95cEFoS25KQjRHMXRUU1hQNENOVE9LTVFDcXZVaExObElB?= =?utf-8?B?d0FMTmU4ZHZxUG9YcnVRREY0ZTFrV3E4UHI2SFgxT3ZjQnJPeXVocnR3bXVV?= =?utf-8?B?dk9wVFdNZGNzWGdNOU1ZL1cySWhuVGRRVUM5eXptV2NxV3dlQndtWkRXR0FI?= =?utf-8?B?Q1ZJN29Mc1V1dVJqQ1B0UGtqMmc1eGROTUFISnlxWDR5Wm5UekkwbW9aNmM3?= =?utf-8?B?RlB0WnFEdDgvQmZmNG5VVEFnVmZrWTREaEo3SGZvTGYzRVdJenAwVjlpcFBw?= =?utf-8?B?ZHNuaG83WGtvN01WRU9RUHpWWVdFczhyS0xNTUQ0NkRaelY0ZTdjOVlDbGxk?= =?utf-8?B?SzBmVC9yUnlaeGw2TW1PRmJsR3NTTjN3bFJLczBpL3R1NkFrdmt0cmZmdkhE?= =?utf-8?Q?u+Hyt3n0hMyAwkX0Uk?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6dccb8b0-26d5-4bd9-0054-08df3578e8ba X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB4754.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 04:55:53.2703 (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: ow/TVsDXArGUZnMgG1jGpzwXVNKNbujZ0zAVEj0QeXGG+X67CC2bO84P6hD+qiKK1F/LoGwBfwK68nBYEXMrHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8026 X-purgate-ID: tlsNG-d62444/1793249939-1D272757-CB7E13DE/0/0 X-purgate-type: clean X-purgate-size: 3438 On 10/28/2026 3:42 PM, Jan Beulich wrote: > On 28.10.2026 06:03, Shuaidong Chen wrote: >> TYPE_SAFE() degrades to a plain typedef in non-debug builds (NDEBUG), so >> mfn_t is then `unsigned long' rather than a one-member struct. >> INVALID_MFN_INITIALIZER and INVALID_GFN_INITIALIZER, however, always >> expand to `{ ... }', which leaves >> >> mfn_t first_valid_mfn = { ~0UL }; >> >> initializing a scalar from a braced list. That is valid C, but MISRA >> C:2012 Rule 9.2 (required) - "The initializer for an aggregate or union >> shall be enclosed in braces" - is reported against it, twice in the >> x86_64 build: common/page_alloc.c and arch/x86/efi/runtime.h. > Wait - the rule says the opposite; it says nothing about initializers of > scalars. The rule is clean in all analysis jobs we do. On staging we only > ever have debug builds analyzed, but on release branches *-allcode have > DEBUG=n. No 9.2 violation shows up there. You also don't point at Eclair > output supporting your claim, so I wonder what is going on here. I came across this while working through MISRA violations on our safety tree.  As the code is not something the safety work introduced, I sent the fix here rather than keeping it downstream. I have now found that upstream already dealt with these two macros, in e6b68789d42c ("xen/mm: Remove INVALID_{MFN,GFN}_INITIALIZER").  So you are right that there is no violation upstream - our tree simply predates that commit and still has INVALID_{MFN,GFN}_INITIALIZER.  What we need is to backport it, not this patch. Please drop this one.  Sorry for the noise. > > Further, "That is valid C" contradicts ... > >> --- a/xen/include/xen/typesafe.h >> +++ b/xen/include/xen/typesafe.h >> @@ -9,12 +9,17 @@ >> * * _$FOO() which boxes a $TYPE as a $FOO_t >> * * $FOO_x() which unboxes a $FOO_t to $TYPE >> * >> + * TYPE_SAFE_INIT($VAL) spells a constant initializer for a $FOO_t, for use >> + * where _$FOO() cannot be (an object of static storage duration). >> + * >> * This makes a $FOO_t and a $BAR_t incompatible even when the box the same >> * $TYPE. >> * >> * It does have some performance cost because the types now have a different >> * storage attribute, so type safety is only enforced in a debug build. >> - * Non-debug builds degrade to a simple typedef and noops for the functions. >> + * Non-debug builds degrade to a simple typedef and noops for the functions, >> + * and with it TYPE_SAFE_INIT() loses its braces: a scalar must not be >> + * brace-initialized. >> */ > ... the new wording used here. > > Also, in the earlier insertion above, isn't there "used" missing? Possibly, to > avoid the double use of "use", with the earlier "use" replaced by "cases"? Yet > maybe this is legal grammar anyway, and it merely feels odd to me as a non- > native speaker. A native speaker may want consulting. > > I also wonder why you CC-ed Roger with his old Citrix address. > > Jan On your other points, briefly: you are right that "That is valid C" contradicted the comment I added - C11 6.7.9p11 permits the braces, so "must not" was wrong; and "for cases where _$FOO() cannot be used" does read better.  The stale Citrix address for Roger was a hand-maintained CC list on my side; I will use scripts/get_maintainer.pl in future. Thanks for the review. -- Thx and BRs, Shuaidong Chen From xen-devel-bounces@lists.xenproject.org Thu Oct 29 05:30:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 05:30:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464157.1674888 (Exim 4.92) (envelope-from ) id 1xMIiv-0001lW-Bg; Thu, 29 Oct 2026 05:30:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464157.1674888; Thu, 29 Oct 2026 05: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 1xMIiv-0001lP-7l; Thu, 29 Oct 2026 05:30:49 +0000 Received: by outflank-mailman (input) for mailman id 1464157; Thu, 29 Oct 2026 05:30:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMIit-0001lJ-FJ for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 05:30:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMIis-009fd1-HH for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:30:46 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2d9ee-8faa-0a2a0a5109dd-0a2a4506832a-38 for ; Thu, 29 Oct 2026 06:30:46 +0100 Received: from [40.93.196.21] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2da04-195a-0a2a45060019-285dc41532ba-3 for ; Thu, 29 Oct 2026 06:30:45 +0100 Received: from BL0PR12MB4754.namprd12.prod.outlook.com (2603:10b6:208:8e::26) by CY8PR12MB7145.namprd12.prod.outlook.com (2603:10b6:930:5f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Thu, 29 Oct 2026 05:30:41 +0000 Received: from BL0PR12MB4754.namprd12.prod.outlook.com ([fe80::ebe5:87e:6d95:580c]) by BL0PR12MB4754.namprd12.prod.outlook.com ([fe80::ebe5:87e:6d95:580c%4]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 05: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=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=tdGJ0oEnEvLq5kTdjdnCAO9IQS/DpY2dCKk0lUWezBjr2ilmRD2TfHiph0uhJeOhVH7Rv/Xld/Q7ufZkJ7znSwcFTYOIXVPkzkdJ1tn2CwJHmG5jDuOcPBqk8Zl2MmI11ZQRSuIlRnFMbke3HP5l2dML+1GSFmDERdueCdyxNV3x0HCFQLCtKQhuXmEL2as990pOUMajHQK8piShDs7fVRpXPdAIvCosf9Gmh7ZSsCM5pD5TSOzw0k7d3RDapyKn22hXeYGYjpA2lERCpCz+2OuMtRKT/Vul/KzJEgCLcrRusDX+KIzrANPaNpPmA3yxaylZf2MwqdGCxmCpSblqYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O+7Ss2GG/Hma27POK23U05kkj0KyiUOhq/b8t6sTeYo=; b=ewfJfl9HtfYGvp9AI3yhHKTRbXnuX9ugLN9/f0Ho6bgNA2UiiFJVB7q5DeM1qnJodSFMZX/kH3D2lpOau5xcf6gBRo0UmZM5OPXtBjz/CAiIIpbBAxHyjjokr64F5h/qgpItxBKtAFxAl+XkHHvBcAg5bKGtSeLficf2dNsOvvkvwYJAwtbPnA2wRHC7gfOUl56hFPNrIcIvNU9LadoZtWu8Jpk25RV4U2LQTJedrgY+g3e2nZ+cBZHN4b84PMmvZ/Xoy74mvT3rpkS1bNa/QfS91KApz1zrryzR1+KQ/O6tv3ww827ohF8AgLYXRwsPW7OmtEQmdJCHB0OOkKwbUA== 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=O+7Ss2GG/Hma27POK23U05kkj0KyiUOhq/b8t6sTeYo=; b=41Bv8ap648Q1H+c4xcX7qxvu5tf3NcesTDeCRYr5U9jzxB4mFidCJHe9NQkgzU0dHizXbaYU1aD9KGjC1cKXah2xC1+dJ2yhJd2LGzeZdpruYBtfS/jIDwkSlyjQAi3Tkrm8ci0/65rHWMXo19l+ZGk4kSJH014uohW9I3ftLnM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <67f91d71-5692-4c07-a834-f282daaebd5a@amd.com> Date: Thu, 29 Oct 2026 13:30:32 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations To: Alejandro Vallejo , Jan Beulich , Stefano Stabellini Cc: Nicola Vetrini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org References: <20261026030309.2507461-1-shuaidong.chen@amd.com> <67e298cd-3b84-4476-9dd3-607e505effe6@suse.com> <321e7082-5cd2-4a41-9c49-ff091d9ceade@amd.com> Content-Language: en-US From: "Chen, Shuaidong" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TPYP295CA0053.TWNP295.PROD.OUTLOOK.COM (2603:1096:7d0:8::10) To BL0PR12MB4754.namprd12.prod.outlook.com (2603:10b6:208:8e::26) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL0PR12MB4754:EE_|CY8PR12MB7145:EE_ X-MS-Office365-Filtering-Correlation-Id: 5336d154-9678-48e1-5eb5-08df357dc5b2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016|23010399003|261026140227099003|4143699003|5023799004|11063799006|56012099006|261021135927099003|261022075727099003|261022105027099003|261021123027099003|261021121427099003|10067099003|261009223027099003|261028144727099003|22082099003|261026121527099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: taYteq7yZ8hXz7Tde8bI1ZInPaeInp/FC0JVAAUzk62zKGhmBxeDdAVsjqucQXAs0bBRLuuETIFqlPnpm4hGPscK0p0y1/sJSS7QtyJNlhJTh2c8RJ0V9YiJgaqp6Q6A1gcGWml5Jhuj/nbYY9ZrgNOryVpmSjcfFi8fKLCKYfShtBkxdh93SJxd3sDRwDnFfgXN6Xa0jWbykujc8jc+XIj/aNVUvR+hu+BbqibvQwlubsw8X0TPgOOASX/G2RXUmOOP98m0hlMgykhv/p9N/ueGS9V/kcCzdEPeeK6IcZq/AlO9dJFM7tS3doNUV5il/rK41BgCqgyn6TFw/YdFjgs4GKFTJcy+l9lLcPtpYCQ3xt0s4GEvdyZh22gmkOiTvPFQeLpbCk5a4FFmozNZQ4e481P+V50oVLiJb3bGClbgplrKnuu+Zak4e2Aek4IWMIogeV+T7tmNmDvB/0aU+QagdIMobd6SEOa3o+BZd2UtkmZn8BoGO+iIPJ5M8pNBOtMwZDKVAM1iXCr4cEKuWWu8h7Vbka1RXYap7pcLjAyE+lZ+I5DMtLXnUIs6mjQQLA3t28abVHrqCQzYkIR2VzjW32vXvdFhnGT/YdTaXJgjXXgv1NwMbf5mswGZhmI6zyaFvG0LxAuefjsRf93exr/9FtYDjp5oH1MOjDeIJ+Q= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL0PR12MB4754.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016)(23010399003)(261026140227099003)(4143699003)(5023799004)(11063799006)(56012099006)(261021135927099003)(261022075727099003)(261022105027099003)(261021123027099003)(261021121427099003)(10067099003)(261009223027099003)(261028144727099003)(22082099003)(261026121527099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VXZKK0taY1QrbEtMUU9PdmZkelhUUkozMHZOWlBMYkFGSDF3cm9RK2czS3dj?= =?utf-8?B?SDg4a2l6YzArdmJNT1FHQVBPdHNDQjdCQ05wNnVKdFB3M0drUG9ibUZaT3lW?= =?utf-8?B?L2FaUTV5U3lWbEtGUUNvNE92eG9CN2xGQkc1L2ZXMW8yVE1nZjU1bVRrNjZ1?= =?utf-8?B?cjRMZkVzaHF0UWppWnhQdEVmbERsQzZZSVlDRnJJWkk2bHV3YURkQjJHc2JZ?= =?utf-8?B?SVh3R2FqOXZNYS8wYnUxbkpvOU45K3BSQXpRODY3eGtOWUxsdFM3bCtFK2d5?= =?utf-8?B?aDUxK2t2OTRXRVUyTXVrc1RPNnVYcVBHZHdUYVNXd0U1bkNrRWlPa0E4YWVQ?= =?utf-8?B?d0R2cTM5NnlqcGp5alZrdlMrdS94QVlsTDk2OTBEQVZxTXRGR0psM3lSckUz?= =?utf-8?B?MkxzM0FUb1BMb04yQytOa0d3S084Sk80NllUZTRNN1h5YmpUY0ZOblJjN0gw?= =?utf-8?B?bTk3R0hWK2t4SDZMMVlPYmFoU2JCL2YwZ0hGdEpOemVteFpidGN0NDA2ajVj?= =?utf-8?B?M3FhZUJkRjBkOWtad0I0djA1bFMwcmYwdWExVm9INitrZ1k2eUszU1pTMXcw?= =?utf-8?B?SWxJZXdkTk9RdWFhanBXOHJnbzRpd1BsSlFFOUYxSmNlSFBLcHR3clBJTitI?= =?utf-8?B?Znh6Z21HK3lFSUU4NkcrQXFmQU5ENWRFQnRMMklHcnZqMG5yVy94ZUVPMloy?= =?utf-8?B?cjBYRDdaV3R0RU11ZjJyTlBFK2wxZ1lBM0NLK0h2SXc4eHVTaTlYMmR2S1F0?= =?utf-8?B?VGdFOU5ScGRFTytYMGhsR2VDY0xtSUhCVU9TMjVOcDdqazU1OFBLUW83R2c4?= =?utf-8?B?aVBvSEdKZ0pNSTU4Ukg1MTU2NDU3RFlGaHJOZEViNEg5V0V6cFB1cWh3aE9y?= =?utf-8?B?bG0xY2tqaEMyNGoxQ0Y5clZvd3FHV3ZESXBINGtHaUppOTM2VWpUdlc2OFYx?= =?utf-8?B?Nm5MRitWanl3elRreHJTajI4RlY0WWFLbDJKSGpQaFVPWlhmbmJ4SjJwRFRS?= =?utf-8?B?YW1FZC90L0dUK092N0NuSWlIK2NYVTg4QkdCaDdFaGEzUlhmL3VBeXpSeXlQ?= =?utf-8?B?bFZoM0F4VFlOZDRKNDdNZG8wWTMrYkQ5TkRCc2NSMXA0TkFOSkROVXlzc2lt?= =?utf-8?B?ODVQUGVLT2o2OG9LQm0wWFVNUWhUNlczR2dlL3lHTk0wdHlVcm43V2RDSG05?= =?utf-8?B?NzRVVE5xcHl3ZVRXZzJFYkk4Z2VJQUxlakVPOTJrbmhSU1hTK2ZmcHIraVlo?= =?utf-8?B?YTc3SXpIeVFwVHk5ejdoalEwRWRWMi8yNmNiekV3eHR1K25lVVREbjZROVlo?= =?utf-8?B?VTh3eGhIVy8ycGw4NHAwWjFxa2JVU24rYjJvZFZCM256WTVoV3dOa0pTNW10?= =?utf-8?B?NlUyTkNpdG5xM01Zck8rS01obkJtbVdQLzdzc05QdXF3ZjhSUXhQZmJ3czZY?= =?utf-8?B?cEY1VHpqVEdDazdYNTRxR2NObmRoUE5pQlpYaHlsMXNRZWkxcDdyMnpOOGM1?= =?utf-8?B?OVRoU3BPRWY3TUs0Tnh3T05Ba1REQjZkOVdkZDJvazdWVHFqK1VRQy9QQ3N5?= =?utf-8?B?Yk5tUVJQSVhwVWMvVTYwRmY5Z1dMckM3NEg1d0hVUVlxUWtONGx4VVJtdWNJ?= =?utf-8?B?TVV3ZnJoYnI5TWd6d2ZoUnFZR1NHWllHRWg2Nk1GRDlNV2lDaWxKeFVhNlVy?= =?utf-8?B?OS81eVBxNmxwQmVncGhBZjZ5TjN0UG9WOGFnWUpKcHJvYjI0dU83VU5OS0Ft?= =?utf-8?B?bHRDM3lBc1pGcHk3S0I0NjV4UDJMZzN6M0xSWUNNdUNPdWlGK0MyaEYrNTNi?= =?utf-8?B?MWcvMlAveFY1aU1mOG00VDhSZW5zeEtRRVRlbmdWeUZBQnpVQmtOSkdib0x6?= =?utf-8?B?VVZFbXNpQ1F6YUZ3S2JOYnBId1JseW11YWh4QStNcm10UGptQkgrTG9Nc01J?= =?utf-8?B?OFB1OWJPN3pTZXpqdy9oeldKTHppMkpOeW5lQlA1Zk9FZVduRnhzNDhBZXBC?= =?utf-8?B?bitGd3c4VU5kSVBmc1lIbi9BR08yWXBIbXJZZkRuWFM0N3hlRkQ1eUp2U3hY?= =?utf-8?B?YlFNUG1SNENBVlNTb1ljZUhRZGNZQjgrODFWd1hLVmxpdm5ySEswUVRFQmtm?= =?utf-8?B?cW15VGpmSmlTWE1lcnZMNDVCTFVUOHlyNnF1Mld1SHBEUExrbUpVendGRGVQ?= =?utf-8?B?SVM2OEpTVGJTQ1FUc21XTWxIWmg5bFloWEpha005Z0pIQ2RGQnZsdzVjZWg4?= =?utf-8?B?Y1IreWw0S0kvTXpyVi95Q2ExV2V2Rkd5b3N6SnRQam9PSHAwR2FDOTlzYlZp?= =?utf-8?Q?I/Pp9eogzBIX+cl9yw?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5336d154-9678-48e1-5eb5-08df357dc5b2 X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB4754.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 05:30:41.7381 (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: ZyUFBZDKb8ziKm+4eQt2M1qanOERC6m1rzxYOKSNTbnztJ6hgZmTCZDezHUba+xVc/BSyIBpgOA3jscBWicfbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7145 X-purgate-ID: tlsNG-16d1c6/1793251846-F4C0777B-9F5FB199/0/0 X-purgate-type: clean X-purgate-size: 6520 On 10/27/2026 5:14 PM, Alejandro Vallejo wrote: > On Tue Oct 27, 2026 at 9:18 AM CET, Chen, Shuaidong wrote: >> On 10/26/2026 9:14 PM, Jan Beulich wrote: >>> On 26.10.2026 04:03, Shuaidong Chen wrote: >>>> MC3A2.R14.3 ("Controlling expressions shall not be invariant") is >>>> deviated by two separate entries. One covers 'if' statements and >>>> conditional operators and places no restriction on where the invariant >>>> condition comes from. The other covers 'switch' statements, but only >>>> when the controlling expression is a 'sizeof' operator. >>>> >>>> The rationale recorded for the two is the same: the condition is >>>> deliberate. Nothing about a 'switch' makes an invariant condition less >>>> deliberate than the same condition in an 'if', so the 'sizeof' >>>> restriction reads as an artefact of that entry having been added for >>>> read_atomic() and friends in arch/x86/include/asm/atomic.h rather than >>>> as a considered limit. >>> Well, >>> >>> if ( 1 ) >>> >>> can make sense, especially when 1 is the expansion of e.g. IS_ENABLED(). >>> Otoh >>> >>> switch ( 1 ) >>> >>> doesn't make a lot of sense, even when it's as a result of the expanding >>> IS_ENABLED(). I agree that limiting to just sizeof() is unnecessarily >>> strict; alignof(), for example, should about always be usable where >>> sizeof() is. Yet making if() and switch() equal is imo going too far. I >>> realize though that it may be difficult to find a suitable boundary. >>> Stefano - do you possibly still have notes from the discussions long ago? >>> >>>> Fold switch_stmt into the general entry and drop the 'sizeof'-restricted >>>> one, which the general predicate now subsumes. Invariant 'switch' >>>> conditions that are not a 'sizeof' become deliberate as a result; that >>>> is the intent. >>>> >>>> Signed-off-by: Shuaidong Chen >>> What you don't say at all: Does this help with any remaining violations? >>> >>> Jan >> Yes, and let me give the full context, since the motivation comes from >> downstream safety work rather than from the upstream analysis. >> >> On safety branch one of the techniques we rely on there is to pin build-time >> configuration to compile-time constants, so that the code which the >> intended configuration can never reach is removed by the compiler >> rather than merely left untested.  That matters for us in two ways: >> code eliminated at compile time does not enter the coverage >> denominator, and - more importantly - it is not in the binary at all, >> so it does not have to be carried through the whole qualification >> chain. >> >> Two examples: >> >> https://gitlab.com/amd-xen-safety/xen/-/commit/160dac43f554733a68d83c38cc1d0e73b3b7bff0 >> https://gitlab.com/amd-xen-safety/xen/-/commit/e0eccfa7184b7acee23916cd5cb2a3b5afa101f2 >> >> A side effect of this is that some of those constants end up as the >> controlling expression of an switch statement, which then >> trips R14.3. >> >> > Otoh switch ( 1 ) doesn't make a lot of sense >> >> Agreed in the abstract, and I would push back on anyone writing that >> by hand.  But that is not what happens here.  The sources still read >> >>   switch ( gt->gt_version ) >>   switch ( opt_bootscrub ) >> >> exactly as upstream wrote them, against what upstream intends as a >> runtime-variable value.  The constant only appears after a build >> configuration specialises that value.  So the construct is not a >> pointless switch on a literal; it is ordinary upstream code that a >> particular configuration has made invariant - which is precisely the >> situation the existing 'deliberate' deviation for if statements and >> >> conditional operators already covers. >> >> Of course the other alternative: rewrite those switches as >> if/else chains, which the existing deviation would already cover it, and >> the violations gone. Technically that works. >> >> The reason I would rather not is that it is churn in common code for no >> functional >> reason, carried indefinitely as a delta against upstream, and it makes >> every subsequent rebase of the safety branch more expensive. >> >> Having seen that a deviation for switch already exists - restricted to >> sizeof - extending it to switch in general seemed the smaller and more >> honest change: it states that an invariant switch condition is >> deliberate, just as the project already states for if and for the >> conditional operators. >> >> -Shuaidong > To build further on this. add_sized() is one such case (already covered > by the disappearing exception. There are existing cases in the upstream > tree where this is or will be the case, but due to their being inside > macros become invisible to Eclair. > > Or my (still not resent) cpu_vendor() series, I rely on placing > X86_VENDOR_X constants as invariant expressions in switch statements. > Even if nothing does it today, MISRA would be prohibiting constification > of any global that happens to go in a switch for no particular benefit. > > IOW: This isn't about hardcoded values, it's about IS_ENABLED() gating > and DCE. > > On the specifics of the patch, it's not exclusive to switches. I'd much > rather see it extended to for loops as well. > > for ( unsigned int i = 0; i < NR_MAX_FOOS; i++ ) > ... > > Where having NR_MAX_FOOS be zero is effectively a guard on the whole > loop. Today we need explicit early IS_ENABLED()-gated exits to keep > Eclair happy on some such statements, and that's just strictly worse. > > Shuaidong had to recently fix these violations in our tree because the > spirit of the existing exception is needlessly exclusive to "if" > statements. > > Cheers, > Alejandro Yes, as Alejandro described, some DCE techniques have been adopted in safety to meet the coverage requirements for safety certification. However, this inevitably introduces code or macro patterns that can trigger violations of this rule in some cases. The current deviation for this rule is unnecessarily narrow. If extending it too broadly would have an excessive impact, we could also expand it incrementally to cover specific cases as they arise. For example, this patch could initially extend the deviation to switch statements only. That would already be a reasonable improvement over the current situation, where only if statements are covered. -- Thx and BRs, Shuaidong Chen From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:27:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:27:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464176.1674897 (Exim 4.92) (envelope-from ) id 1xMJbx-0003kG-7R; Thu, 29 Oct 2026 06:27:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464176.1674897; Thu, 29 Oct 2026 06:27: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 1xMJbx-0003k9-4J; Thu, 29 Oct 2026 06:27:41 +0000 Received: by outflank-mailman (input) for mailman id 1464176; Thu, 29 Oct 2026 06:27:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJbv-0003jx-CS for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:27:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJbu-00FxUc-IL for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:27:38 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e74f-e002-0a2a0a5209dd-0a2a4509d038-18 for ; Thu, 29 Oct 2026 07:27:38 +0100 Received: from [52.101.61.43] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e759-be1a-0a2a45090019-34653d2b5e9b-3 for ; Thu, 29 Oct 2026 07:27:38 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by MW4PR03MB6649.namprd03.prod.outlook.com (2603:10b6:303:12c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:27:21 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06: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" 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=LY93Dc2he36qzBE6ehMri22kyi1HoC6E9MDwSfw4+rV7D4OV/eZx4X2cHomBqZQLCXBEv1rzLArWVdZhAoNmm2UINPXtrb+WjkNu58BSm8W3t7OkTrD7hOEbtNmDMiGYxtczcpLdlZs7o8PP4nVHT4VnfbPr9aRQkH0ABtKNXE4ZnDlIBsvr6IgPMIleyE+YAz+OR89Q7R994Sr+8OnJ1x8tCxbgLIRxzJXyj+w2k3qVauHjNBH/SSl/avmiD1tY/tP+6NDv1jiQ+KRcwnvir6z9tesue70PfDc1KyQQjYKJHYqdXrP/fPdYYf6iih4opu/FqLM4Oorka2nWsmx9Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+CSoyYs+mwsdjQFZS5TYqlnxP6kA83rRcuAJN8c2R+0=; b=TFoue+//Ij56+valcIS10vujRWCrtxy9jpF5Yv4Q/dIsHK3JE0LXvkrCgZHsq+69uGSn7dhRfNox1TnKDcQTFGSKJuRF98hB1fm3UthtqG+TnbKXsvGp1NYv9A31YPGeKSj32y7vSjMU1QXUk3VuQgIlGMdsj4Hmz7GAZco3h/FuWA++bBS9wvRdiMUYV6ZoeATEvOQ/8Pe7LR4G+W5UH+FYZuk4wW8LiiJ+npG8cMjI3F14ziQToFfLOIw0esfrKtYlUJ3IquVE/EwfqThLBXbmHPKnYJrEFWGr2yFEfcWRsEwlIvUpF/IpnjApu9a6eqkbJpozLGuzhwkiHfkcLA== 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=+CSoyYs+mwsdjQFZS5TYqlnxP6kA83rRcuAJN8c2R+0=; b=fOwv/0Nvrlhb4mKXQJ9wtKskrJaF6Gn09VmWkdfvv5vA8okcRjfD4aWV1Ujup1+q/SXwnmK+mLwmVn6I1nYt+6uKwFbO2+e4Mf6oW6ElLOK0obq+4xYgOKAeWAoIArLCaoRiYN3TLEVaR2PnHhzB6yD5pc38MfKcOcH9IHpGCzE= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 0/7] x86/nestedvmx: Fix nested VMX bugs Date: Thu, 29 Oct 2026 14:26:52 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR04CA0003.apcprd04.prod.outlook.com (2603:1096:4:197::23) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|MW4PR03MB6649:EE_ X-MS-Office365-Filtering-Correlation-Id: d62be114-7821-4eab-07f8-08df3585afcf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|261028144727099003|11063799006|56012099006|261022105027099003|261009223027099003|261026140227099003|261022075727099003|261021123027099003|261021121427099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: 3mwOhzxXZhBgzVrTIsWywaH5J/VGEB3FV+b/8FU+GOEa38R8QK4h+jfhA1Hp5WcookNfbBBOM0tfe5tixtTz3+JPQWD1CI6hHISx5rHN4YEIW0SXDriQVpNT4KQgHhjIEtFjWyFQSPKJztbLuJHhkpq76Cq6JvCWZpaa4Ecvpp6rQqAhcGF66bwSrG2j9rScoVAfhyoZ9wPVAGvKAgyfrETwn0Izv+wGfoD5+blD8HW7Xu9/7J5sS1cZzpwOKj/O+HfpuFU18QchYplKWKuxwg72m4hjAXdNbi1p9OBpyrXv0kb+XXbvDTBiDCVZDbxq2pib87vFL23V11N03OyN7d9TOHHC7eSPAWG/MU0Wz2u6sRQPaEdGXDnRPmovYd73vNNvoOG/9SFsdm2/50Tp4vvE/S9VEshGCU6IOE20S4XRyFkrwUqD77vqk7pmmFsZgrBvC1Hb6vnqV4EbpBANXFxxn33iGafukttpCFGC1yAhCsyX2I92rZreg/5J2wgLY/PMRYAiBVGdNXVBIxFZQloxUdL9izoucTwT9RTX8BagZt+jC5WxnVcNE3HyqWyoWMGZGDTg9sekh7QcHo9pY+erpwS6wf6P61fOjRKhDom9wd4l9sRQ8rHv+d63yL4MSc+xl0K+lhpJRlmMDPaw8ebtlvkEBDH7Lie9UffXiE4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(261028144727099003)(11063799006)(56012099006)(261022105027099003)(261009223027099003)(261026140227099003)(261022075727099003)(261021123027099003)(261021121427099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7CVIC64WyD8YEGLiyKA06ahCiQ4rZDsfQYdfi+y2ZEwYgF45Eg+iPVBhNzT4?= =?us-ascii?Q?i5IROt2PJ3lday+PqzJH4ue5JT0Y6IH1iB0l2mpT1THXnx5sgTRObpCQOto8?= =?us-ascii?Q?4CcSZTSMNXqVnAckrjpzJlKBF4OggZn9LgIgoAe8YuiNvchWSYNn2DrHVdCD?= =?us-ascii?Q?70HfZk6wvJlkBOglisvkWwIyNYHRn6HTnLMjyNFRCqTNUdFvd8ADNKgCdteL?= =?us-ascii?Q?UK0cQQ71GV4KNv2TzC91efTuxkkti0zkJ0ena/rCKGXyOU7F3zBAlDppqMZB?= =?us-ascii?Q?cklyM+LCOdPGx+uri0XD26QgH24wibvoGx5AEisqCBTqWIoMD+9ye2VAXllE?= =?us-ascii?Q?/a3f59Y0zmxxYbOWpiI5oybWk36LoSyoqrX/AHsp2LDdW9unKvQbMsC/Xnsu?= =?us-ascii?Q?iOQXGFpb5pSP+z6Y0JFirb0TUvEDc7yxiwMLkh6i2DDOYq9rsWouAcuA3Nfv?= =?us-ascii?Q?HHxNV/QrZognA/B7n49KG4+wgbEimGP9pgtVBo3uFmjoQMffiXAkV+UISc5X?= =?us-ascii?Q?WiGhFJA4SMoaaAqlOSN0//fP62B2X9RTkAcDyNvnkB5A5QVRfrftddn234wv?= =?us-ascii?Q?sUBSOWcAWL1qVAgQTmR/opFfdS5tDOv6Jj9w/WuK9wTT7EknOQ0VVzgQWsin?= =?us-ascii?Q?nFO/0pN1LaVtmnnxHiWb6fRMM8J1/rphHFOdZ9BAA1+Wu21I13SQAqT65zmK?= =?us-ascii?Q?4n5lZq88brZSru4V1p9+EdRqf4THUFA8SMlj0QIUheR0NqV6y0ucsNWks8/b?= =?us-ascii?Q?sPe4PAqjB4Akpx8DTRl+/01SFHx3b9FcVNvfydJdapgEbpn1uiFrDBR0pTkZ?= =?us-ascii?Q?gkEIb5Pg2gDjj26N0YOVdWEMrM+6DrOyg83YUWFGxBpcuEM3icrWDL7jFPB6?= =?us-ascii?Q?3+mPTgwJVNxb8eb3zb3x9dX2d75FCc7wKIsa1qzn/uX00a/IJoEsBO1ZP+KP?= =?us-ascii?Q?IKwcP5pNFOuo2PTjyX2jXGlxDtN8aEag3GxiRKPKrj3D0yGtH1uL81QKtd01?= =?us-ascii?Q?6JD3IY/CcZQcObVODXRXL6IKq819LHZkjR0niS2pHxC75bOLlrUuvVX43wpY?= =?us-ascii?Q?roDDqVUzMGxF+MHLGqxeCdPS/PD6N4BABZE3+b4qyPvrkjtivkH2T2dOq0OX?= =?us-ascii?Q?NFI+Rq+GdD41OhlpfZ+0EpbadSRROFmudYllpRL98c4WOYtp9h76RgWcgQp5?= =?us-ascii?Q?UQL4lkJHr52DZt6MbpRnsNRTXbEbb60l3gzBR4D6Z8K3xGR2BKG29WeMLgkt?= =?us-ascii?Q?bVtBP/NC3rTlueljC++d8Relu8ULlDqba3EadiNsrNB2dW9v3cgsIyW8Rf30?= =?us-ascii?Q?cTYW0RQOQlJumfXfG7zj6iSouYmqtmCMUns8L05qlmJTWR1LGy/9nmZILtI9?= =?us-ascii?Q?xb/Ca7zZkr42sW6xFYYLfGaAx6TSKG5gT+jZmTqwVPM1IOENrm3tZbdoJv0N?= =?us-ascii?Q?FVJ0a0oLsktLxvjNBYbzA2fuEdgAeT9IojG6aP+ofBB7BYoLmSmJ1EOC4yTY?= =?us-ascii?Q?CVM8PU4Tyz3QfndcfiPMhsHt0EdxwE1zTh99zf1+UA4dxTWCLsayaA1ca+M/?= =?us-ascii?Q?FuqLWQ5Fu5GBYbtpoyyCSbmTsOlWvkLV2THKM70Yd53kHG3mLVvjcAtL0D/I?= =?us-ascii?Q?lQOOVQWUW6wnRqcNeHKkZ2Jrzkap4ZKVxnOdzQEdHL7O462YH7NpOanyqAbP?= =?us-ascii?Q?vd8ABExdp3ET3uHPywiUNB1pO+H4k0CV9qN+I+YDELnhcbrL+VpOHQAL3KGX?= =?us-ascii?Q?gSq6rFVMqQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d62be114-7821-4eab-07f8-08df3585afcf X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:27:20.9326 (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: Lyho2Z0mOK1Z9OuNufHtQlX2ae+Ms5ZtVP9M8EGSHfeD4V7bxMEcqCezhs5c2lO957chj6NfSzl0HT+hMHqrdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6649 X-purgate-ID: tlsNG-bad1c0/1793255258-3ACDF034-0FFDAB5A/0/0 X-purgate-type: clean X-purgate-size: 2047 From: Chunjie Zhu This series fixes several bugs found while running nested VMX guests (L1 Xen running an L2 guest) on top of Xen: - Patch 1: stop leaking L0's widened access bits into the EPT violation exit qualification reflected to L1. - Patch 2: emulate L2 accesses that hit the APIC-access dummy page against L1's vLAPIC instead of mapping the page directly. - Patch 3: reflect EPT holes hit during L2 emulation to L1 as EPT violations rather than injecting a bogus #PF into L2. - Patch 4: load L2's EFER on VM entry and restore L1's on VM exit, so L2 neither sees L0's LME nor fails VM entry with invalid guest state. - Patch 5: invalidate EPT caches after flushing a nested p2m, to avoid L2 walking stale paging-structure caches into freed pages. - Patch 6: retry a nested page fault if the np2m changes while L1/L0 p2m are being walked without the np2m lock held. - Patch 7: fix several nested VPID problems. Changes in v2: - Drop V1 patch 2 (Implement nhvm_hap_walk_L1_p2m2), a temporary change. - Rebased onto current master. Chunjie Zhu (7): x86/nestedvmx: Preserve hardware access bits in reflected EPT violations x86/nestedvmx: Emulate L2 accesses to L1's LAPIC page x86/nestedvmx: Reflect EPT holes hit during L2 emulation x86/nestedvmx: Load L2's EFER on VM entry and restore L1's on VM exit x86/p2m: invalidate EPT caches after flushing a nested p2m x86/nestedhap: Retry nested page fault if the np2m changes during walk x86/vmx: Fix nested VPID handling xen/arch/x86/hvm/hvm.c | 6 +++ xen/arch/x86/hvm/vmx/vmx.c | 4 +- xen/arch/x86/hvm/vmx/vvmx.c | 71 ++++++++++++++++++++++--- xen/arch/x86/include/asm/hvm/vmx/vvmx.h | 4 ++ xen/arch/x86/mm/hap/nested_ept.c | 9 +++- xen/arch/x86/mm/hap/nested_hap.c | 52 +++++++++++++++++- xen/arch/x86/mm/p2m.c | 19 ++++++- 7 files changed, 152 insertions(+), 13 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:27:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:27:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464178.1674914 (Exim 4.92) (envelope-from ) id 1xMJc2-0004AY-R1; Thu, 29 Oct 2026 06:27:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464178.1674914; Thu, 29 Oct 2026 06:27: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 1xMJc2-0004AR-OK; Thu, 29 Oct 2026 06:27:46 +0000 Received: by outflank-mailman (input) for mailman id 1464178; Thu, 29 Oct 2026 06:27:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJc1-00049v-Mb for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:27:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJc1-00CK4H-3E for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:27:45 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e756-bab6-0a2a0a5309dd-0a2a4505be68-4 for ; Thu, 29 Oct 2026 07:27:45 +0100 Received: from [40.93.198.59] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e75f-4cb1-0a2a45050019-285dc63baafa-3 for ; Thu, 29 Oct 2026 07:27:44 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by MW4PR03MB6649.namprd03.prod.outlook.com (2603:10b6:303:12c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:27:42 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06:27: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=DjrkIWFPJln5XVPiCYuu2AMfsU3+ZGOIU65pLH2gGcHMWd98b1GNLZLnUbneT4X8MZB9FcCsTq7Pl8J5u2nMMojATU5DAiPNaAXdorLGZEhEAOhIWOjZd54oax8j2y3dvB2BLRQSUC94R3JsuZtVXcioCmgdZ60wRqz71v5imNZg9wt/HUXxFTq4oUtfJLUIWiJf5drF/OgrCLCratYpHPYUPudDgRK0ATtgyJyJxYhm0SUVryhhBx9DBVvxan6Ehu5/1vqmDibiqaTrzme44oOfbGcR4o9dARpDP86P8D7+fkZMmWKL7TJbWEilE8+nrZMit/TNgzLY/6me2eI3gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vSeSBRBijBRwv/dIGJiPCgHb/dZpfbcL2+Rqa+yYO28=; b=cNFlFe2hJ3Nrm/C4O4hqSAHP+vra1/lEn8pgmwS1QdzhhulPr3fROwtwFzZiKJIlYiSXDf/b45RJTfv9YMI90xFxKqr4qLcr0qQN1igGIvyoqNJRPyUU+nD6Ipaxxi7+qgeU+1/yYRFaz7+Yj2dryRCPVZVmRqeecYldIkzEv+wBpxT8VHtsBCIcuqPkPFs+Kp4QcLp4pG2yo0APGaWuPzM3nP+stblFPjh61b3uSBogBYrgJoDaymdDqALHMClMpFVLqdFD0bWVzTFvSNETa1LpDjjIdsl03IiDG5mgIEoaMUKP2jJcXerMbK3ZMpCQoxakR9ABnl4sdvk8CMERkA== 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=vSeSBRBijBRwv/dIGJiPCgHb/dZpfbcL2+Rqa+yYO28=; b=stGnrw1Yw4UeQYBQEdhEUQwj9iQ0pJtR1tVru+CVrPMPBf/MoXCUs9wNpLEj6abBddzS6u38FBhgKTnEd43tBOu+GoSIumSb66VCKktVZIeWE2TBFt7TRBtcP9vnWNcc1o88pDqUnb7mCgDvdzK5LR8g1iu7d9oMYIXmzenNUC0= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 2/7] x86/nestedvmx: Emulate L2 accesses to L1's LAPIC page Date: Thu, 29 Oct 2026 14:26:54 +0800 Message-Id: <4daa9052fc7d5ebd8d050965c99eda78f8f5b1dc.1793254779.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0075.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:c9::15) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|MW4PR03MB6649:EE_ X-MS-Office365-Filtering-Correlation-Id: 3039b11d-2aa2-4213-286d-08df3585bc44 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|261028144727099003|11063799006|56012099006|261022105027099003|261009223027099003|261026121527099003|261026140227099003|261022075727099003|261021121427099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: YePXTuz6sbutqQf2R9T6uWC8Y78vwdtoYZ1fw0frAwcWW2KU0sDrB1Q8nKa2i7f+U3zkLyxQkFuDUvsQj74yQbHbk4RSyp3skeRnOAZki6opj0F80AI7WPI50MWXRpNsryrRqY/j4pah2z7cxjO5Hc/xx6AF0IxhDroV7xEZpBu1bfsC8hMGfrFNi/TK6QGpq9jyznh9/lfALc2csBwCoxaent1bMf4vKeG7CBDSg2xSwzs+hkhcuKRUsPmvbbJ4/p6WV6L3sX0669cXxF2DVutHs0aTRJhtmdiUufk2H9KdfNi4xtpsNqwHso8ARQizZZdVBsqdJON/MiAkP3jIU+iG3nAO5ncybcWjG5RqyM1zhmlIpwWXPOj/4k3hfGlmKKNyg41VPy1ASR924wNmc5QLMRV328aCw5aEoZ9pfdLj9ez4qlBUCUgnTIY4Gx1/ZJYRrlWBGQPT4OpX8J5UhtkPPgyvhs8PHCNTZM598zEjMgCxitZXpQTV+K4qwPrqUfh0PSzi4V/NHQgMvVALaSoXKD+5Ou/4xGzi4oL+vIF1hnvSgYCJq27bK+C4KL0sZuinZPKN7bWvTy5jsRXusQETgC49zNMB8sgY6e4Zs+tdyRGijt+9U5RG1a7n4A4iiAdSI3/zyiixCZbPZr9tiapEIZv7aIf4Svv6IVNpUXc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(261028144727099003)(11063799006)(56012099006)(261022105027099003)(261009223027099003)(261026121527099003)(261026140227099003)(261022075727099003)(261021121427099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?C/FfgnQDicZFw002MjejKBXOv4rQECbPd/QPAYK/xQlq6bFv4dr1rmrEqBLs?= =?us-ascii?Q?+EfXHmwW28wqtyDmntJiAdC+11iiCsoNFi1z05qdsi0iYk6TBN9NxfFXmD8x?= =?us-ascii?Q?Plj0rTh30M34vq8HxjLGhmp1qol/jeod+DVpjnJwmCQo+fXHc5zhg8eAZSWg?= =?us-ascii?Q?2nh4SIngryzFJTz4eMDhN6xlth7w+/S26Xf5P2v0OtaVqc6Hp9bzygMMZhKl?= =?us-ascii?Q?n3x2Ta9sQyATk69bu4/On/0qPiYw6U5fT875700TopxQPb/I23y97DW2ATma?= =?us-ascii?Q?JQitMFr2LfvEgz+ENcRpcY4atoQCBJUAJDEA4ifvvpoim/bFstXyx8BMXAQH?= =?us-ascii?Q?RxDNWUd1VnZUVZBB9eh1w/y7p0kOBZKFIKdmiTBJPmTJGjHMGYZQwHMOpPu5?= =?us-ascii?Q?OCZOQMzs3luagWW3E6T0oTTLhVNMzQDCPW5Avd9iTmqsOay9KP5qkoAwA3kD?= =?us-ascii?Q?ELJb2rZljMcbsY9WSBXPjfNs41vY7e2biZFF4td7luRj//E/Oa5gi6VHzdtO?= =?us-ascii?Q?gv69AIY9D+frp0SENYloTgvwIQvgkTMwZZIIvrp6xt9gGxKwAEIqhSYamEAB?= =?us-ascii?Q?XZSa/Wk4sklazupqYjXUjn3nzR9nMhvSqtBWQcrIWPV1hwzDSZi6+zAoNZ4l?= =?us-ascii?Q?mB79DvGrzswPR+l2ncrHlXJAMcXHsd9pRdjBi83S3iOxYqJJxuUiIZ8Ns2sC?= =?us-ascii?Q?jbqtIWfe2WpjdocL7l7KCpQb+vcb1fh2vzByYLSIly130VQKjhSaxpdPM0dr?= =?us-ascii?Q?Z3GjSqk0GY0BT7Xty8tO09GwfelED1c+gNxvzN0asUTgVx16MHXO4OekcUH/?= =?us-ascii?Q?DcUC6UnSEVwWho4HAa0JQYsNv9ubhqN3E2y7U3ZSTk5p6w8WFdsZoctchVDA?= =?us-ascii?Q?uSgCEi/fAhR578cjcsdMwww/qEfSc6dUeKHcfRKHxZGaEkSIfMrO54T041ov?= =?us-ascii?Q?jPAvMR6HSlSLkCmnf38eO730L6IVAzzTD0D0ptn8t2w+HQVohD6SS4Lv8YxO?= =?us-ascii?Q?bcpGWmBOiCCdfi/vKvkVvS70R6R2NZUFGh7DJDFr/lLjyT2QwA0agolA3IHO?= =?us-ascii?Q?BmgvmHyDIqhDcK+lab/gm+11sHEjTuw04pcrgYb/tkeXfLtm77RLKZk1KXGj?= =?us-ascii?Q?meTsCKyk2hBzsMnhBL9vpkAAK2IdzgIgD1YloGSvQjUqpzJNg7AToexBy5n9?= =?us-ascii?Q?w0VNIyeGEaJdoIprLSl8JHunyeEzQP9O2Azbmj7YPsbTcb+WpK2wHN53B3w5?= =?us-ascii?Q?mDfU6Kahj7iQ8JxE6i85qg27OnhyVSx6BXQkuiKp2ZU73KIXKPH1U5PNwjoI?= =?us-ascii?Q?qtXpePOmDM+grVgxeOukYm0NAKM+lVrp1cDGWJZPa2MyCi71hHP6fEER7RvK?= =?us-ascii?Q?4i/HpxiNQySxv7U5ttpweFRG1nhCB08CEfSuSgtxvQmrwmXGSNak/UcXjnGd?= =?us-ascii?Q?QzYoRLcuhcq+JHdtV+sOojLyH/5Co4aGhgPVZ3EvWAzYwCZNnSSrPdiZSZyz?= =?us-ascii?Q?YNd1io659AAgHUhIjK6jRoo/o33s9tYjIO0gDCzTVanThGyb9dqcpOs/JYLC?= =?us-ascii?Q?FWgYlN+pIxcxS3PLzu9vMjvfOETfcSuatUO3/Q8JE/MNmz4GydTAgzwHDkux?= =?us-ascii?Q?h28RzfeO2Dn58dRpiD2gqD7i3AkWzlpPXlFanlZ5F+nZc7OULsUnGmXpao3U?= =?us-ascii?Q?j8fn7+zHcLjKU4WQ27SdQc+1qRVRobTaUB3kJ51IvvikGFS+sTqneKWm0/nz?= =?us-ascii?Q?Oct+p14v+A=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3039b11d-2aa2-4213-286d-08df3585bc44 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:27:41.8945 (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: 5A6402Xp9k5kWwiQ19yAcjiC1hQ5ygqjcFCBRcWmsrO4eBR9qibeWcEQb/8ME05Vkg4+h34CJ3QXlv+RjHdbAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6649 X-purgate-ID: tlsNG-c201ff/1793255265-F5EA92A1-0D15A45F/0/0 X-purgate-type: clean X-purgate-size: 1474 From: Chunjie Zhu Return NESTEDHVM_PAGEFAULT_MMIO when the L0 p2m entry is the APIC-access page, so that the access faults and is emulated against L1's vLAPIC. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/hap/nested_hap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c index 255fba7e1cac..ceabf31ec0ab 100644 --- a/xen/arch/x86/mm/hap/nested_hap.c +++ b/xen/arch/x86/mm/hap/nested_hap.c @@ -17,6 +17,7 @@ #include #include +#include #include "private.h" @@ -115,6 +116,17 @@ static int nestedhap_walk_L0_p2m( mfn = get_gfn_type_access(p2m, L1_gpa >> PAGE_SHIFT, p2mt, p2ma, 0, page_order); + /* + * With APIC-access virtualisation, Xen backs the LAPIC page of L1 with a + * dummy page. L2 must not touch it directly: the access is to L1's + * emulated LAPIC, so let the caller emulate it. + */ + rc = NESTEDHVM_PAGEFAULT_MMIO; + if ( *p2mt == p2m_mmio_direct && cpu_has_vmx && + !mfn_eq(p2m->domain->arch.hvm.vmx.apic_access_mfn, _mfn(0)) && + mfn_eq(mfn, p2m->domain->arch.hvm.vmx.apic_access_mfn) ) + goto out; + rc = NESTEDHVM_PAGEFAULT_DIRECT_MMIO; if ( *p2mt == p2m_mmio_direct ) goto direct_mmio_out; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:27:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:27:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464177.1674903 (Exim 4.92) (envelope-from ) id 1xMJbx-0003mc-H8; Thu, 29 Oct 2026 06:27:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464177.1674903; Thu, 29 Oct 2026 06:27: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 1xMJbx-0003mV-BL; Thu, 29 Oct 2026 06:27:41 +0000 Received: by outflank-mailman (input) for mailman id 1464177; Thu, 29 Oct 2026 06:27:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJbv-0003k3-Td for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:27:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJbv-00FxUc-AO for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:27:39 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e74f-e002-0a2a0a5209dd-0a2a4509d038-20 for ; Thu, 29 Oct 2026 07:27:39 +0100 Received: from [52.101.61.43] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e759-be1a-0a2a45090019-34653d2b5e9b-4 for ; Thu, 29 Oct 2026 07:27:39 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by MW4PR03MB6649.namprd03.prod.outlook.com (2603:10b6:303:12c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:27:29 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06:27: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=XWPmbfvrbp5HJ6UKx2/NMHTrQhC2eIp3Tm3zHSEBcsu25gZEiACKEEjyc5XWU/yKsvRtwxD5gKVYpkTWQfD6oUMVEfEt0yeI4xqVFhSIbrHXvt2sq1/hGhUzAgQRcmmES105BV55ayg92Bqu2tTQU8fEwgKXRZ9Q/P1cZpyaIDjA3hAkzbUSCTgvTX8DWfH53gPzJTz7O6CCBauQfZxSyPt5691zw+/Su/DRHuABBLqmgog1h567I1q1IKlnCrM3Yb2/492axZ5MTie+cjfu3+alwTts1zTAGvTBiY2lIUn91OshYWraLrLJdCdTOogWZquMJEJ5RWSnsUKlbbm6jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uOROdr3Lsj2WWcWL/9pNfOId1Ctpk0JV6ASZ1lvZtqo=; b=qX1noF26Jse3mc/P0gHKci+c4bglt8wghckM0hfyHkYpHY2Wjce+zQBRLsVGvQAfTaiqPqtP/Upawp7teaRjPHFOIilNKpPmE2Qn4X6qhp+gFZpJaUzMKa3RaougTw1SMWxVUkdbONWYWAnIurpQJXvIDvDoKo9I4hUBnneDpQ2tWuo8gShrK8SSwN7jlPaOiMKFjlfXbpiFXjWWFiB0mEvXbt4s4Pjc+oFudwwlisSQ+JYu8FvOl0fM9nakB9HW9WYzQKdi867SxAH/xbxYEWxAw143yFwdcrvD6NlgNzCR/1KD7jtPCwc7GAuFWppvi02smPCaV9+WfB6BFnycYw== 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=uOROdr3Lsj2WWcWL/9pNfOId1Ctpk0JV6ASZ1lvZtqo=; b=W1KRBrXltXN63jXhh9NC19Vge3T1+5jKYuJqz8vEpgY01x96yxEbFMDZ3TCoV9lxZC291VbZW0t6BwRzjWjWTPCWpgxb7rfaQAMIj9Q01BVxuVeMYIAstqx11kAIuloFFamWCaWSFJ5d+7yus4G+6BDtGFu42KsCA+wfusgJ6+M= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 1/7] x86/nestedvmx: Preserve hardware access bits in reflected EPT violations Date: Thu, 29 Oct 2026 14:26:53 +0800 Message-Id: <6673ab0eec0f71d6b90e93e70d1c1ed265982de5.1793254779.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: FR4P281CA0238.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e9::17) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|MW4PR03MB6649:EE_ X-MS-Office365-Filtering-Correlation-Id: 2eef35d0-2f9a-4e9b-7519-08df3585b498 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|261028144727099003|11063799006|56012099006|261022105027099003|261009223027099003|261026140227099003|261021123027099003|261021121427099003|10067099003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: sCE9860uG3yRP0epw38zuuFGq15h/6ybEMeumK12J9VYsXGawoSGaSRFEjsu7c0kc38V3zQJMh/re2nwuQsz2NTOS6kKpnCGlyQFmIRV1uISV3hjGkM/nb9BSxN0hRM1YVZAIE3o/MrAVVz5xmf1W5OzEFXI4qlfnSh5NJ9oxcfzRVVLQhY/tSfPVkgzqG8NUTeRguGqOLfNzWn0VdgHleZOUmQYnx9qU/HNTHfL4qYE5k4XlrDLDPug6/arLG7kT+Dmemh9gzrx0PqqX9TzQBF4cnDvC/uPZ9eDBNkShmx/b1S5m8Yol6jvTLNodVTuTEtPyQ3ySe3nWnXDczaPC+yCBAHcM/gBWqSPT0W+rejBDxwfx68AheiaZm8OP4XDI8X8jcW5QRyajFGketImFE5DnrO0ppeGTzFeFdw9K+rFEgRwqeTWD1Bq4j/bHtiXoxGYTyuzWk0axy0m872E8qn3OdXASevQxQEnM/XKk+n62VIOPkoDWdkyjlrPYTk069qFKSNL1Jt4u5cy73oWXd0TnT0mLHi5sDPyq+roIpa1fXLz16FR4zmXaSFkP1X2IqTRpn4P9ivewQtQ7mqNAbIaAEPb3eJR06UKZXWF5Zn0qhEoHIG9x53zmvCXQsl/ZBwlGUrledBRJJAZIUYmgymkMkvDkwmC3z4QldOBMFc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(261028144727099003)(11063799006)(56012099006)(261022105027099003)(261009223027099003)(261026140227099003)(261021123027099003)(261021121427099003)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bE1pSlfMa9eXNcIWInXBqcJD8wr804O4OSDTXN29roFyro1Uj9pC7ZZg5xCV?= =?us-ascii?Q?z1DWgxL9eBe0rSD0EQhXTZDzv6yumbBl8Y6gFoZZYBFRvn79QwyLW9y23kjp?= =?us-ascii?Q?pdr3jCeNujJ1BOLWSBKODtnGASQb8HKY2LhFGRh8fAY+h20OTyK/5lY/wPWZ?= =?us-ascii?Q?dLR2RaJPaD0BJutccvLiCRR1Gj6PkFFhDk4kxv3SA4SDKZRggxdEPWPBS90j?= =?us-ascii?Q?ChecG+ZR7FnZHhA/T5Rl8bYmqZtOQt3gugU7QcyVhFz8GHVbjN7VxEGCo9+f?= =?us-ascii?Q?TXZhsYIklRbj1RSStSMTvIeVyMvZn/++kYAa5emczkh0eGWKmHokbX4zJUTr?= =?us-ascii?Q?n+uguwhaS4I2H1yHnDJ5c55UjVMT/B2ANSJDyva3AIW/yfdK1bac5/0rxJsM?= =?us-ascii?Q?2piSD7+cMEMvWYgrMsPLhk0+7XVJugPJEcjqODvrryfzCLvfv3PU8FRmAcJq?= =?us-ascii?Q?guo5Vk15MtXTf8K2fHsm8NKs33v/GzZRYHQSzuFnDqxRg9igHTZWHsFDB7p+?= =?us-ascii?Q?zEJQLQl6Tdh4TmEKVMbUbUvvh+0+DpPBgNZtUgwLaIWZhLUmJvmMaYIVWasQ?= =?us-ascii?Q?d7oztdNGsaTWQV6dzAaXH2DdyPz71dIGka81yiU7GJwrlqI0W6o7F77sn5Sk?= =?us-ascii?Q?o830wOHQ6qSfr55BMgEwRV4gh1sH1j16nUFES4C4j8rs9QgN53+sS7j/W+OQ?= =?us-ascii?Q?t/gp7dGnaoYg1NxhVCKQebaCeCwngQxlLHa8l3xe+ls7x+DERzQ7ZddfRWkC?= =?us-ascii?Q?LoxdpEjAoBmtY32rW5kVCWLCmqpPRvcVQXcSQyxk0rktBJEnTpg3PYA0YrHu?= =?us-ascii?Q?fqpGElRuzJSDh/tXAHLyXez32jw33YN6qWmYgrS0JHgsZF5nOAqM/JFK5e5Q?= =?us-ascii?Q?Ee01Zt8Z3ZIMdnfWYGafdeJqSyug1VKmMxhUERWtXgNF84REkLtY4qiZ/TgH?= =?us-ascii?Q?EhgjszHldNQC0gTKxyvdGGeGpA9Ww11IolFBxn/l4C6YfC+cVzQmGBgzKjzq?= =?us-ascii?Q?+rfO0S8eoXkXgOCCUwouonWxGlmRgjSoLheUanyIcM1QFrYLG83CgHC/4h8A?= =?us-ascii?Q?e7DDeKL9KYGRGFJC2S4nQZ8actUcwyrpL6P1Yjh+Nu3AgKBEiwwxrLVUx0VX?= =?us-ascii?Q?m2V6UfN4/WcfCthjrSMj71XdANc2NjJFZkNm27uVoss3LIoWauNUvCAvdTad?= =?us-ascii?Q?CGsf7QIgH/w2zUM0meHQtEVYYOtARatQUHnuxer/EkuXGXV7ZT5ScZO2ZHX0?= =?us-ascii?Q?xwjwgIpJ3sYiCNLUFLAiBOwn+ABzcamF85dMsfMyDqVq3ybosVGzdQ/zNX+k?= =?us-ascii?Q?+H8YACrzdax0N1s3ffwXxhzkJnjUr0iYb4ugVk/wL1ArisQ/ptxwyDE/A3q3?= =?us-ascii?Q?epL7KsqcxdOJCHLsrOtuRIZHeV6Jb8KoS7n3lJ7xM1Ux+WlUWj9QHJHbxM7I?= =?us-ascii?Q?R8Qrva8weBvjFRMLxGtOGFFoNHQZAn2o02yEcpW/Wn9a4OhFE3F+7eSRUgZA?= =?us-ascii?Q?CqiXcVbI3eDOtZfoZUDLr8FZTuixGH10t3OfMM7Z2BppaHBZXfEeUBB9NKH/?= =?us-ascii?Q?3ywFUJz1AUE7mplZHf4LpsJhfv7pJ6qgdvk3hebBtCDgHWPAlZYK70wH8HSd?= =?us-ascii?Q?N3g5UOSv2qOVPbNWgySurJ5I7E8NbhPqOQzfeYCtp2hC3EHeTt9xPmzDjkrp?= =?us-ascii?Q?62iGAydv3oX/7CkyPjODC3NKjfr4DEFo+e7dgLImtG1g0b+A/3VjZxBzcitK?= =?us-ascii?Q?jDwG/KKXpQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2eef35d0-2f9a-4e9b-7519-08df3585b498 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:27:28.9674 (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: CrjH7+trNqDh8CEQTfWBuDDhtpa8vRg+0qUq2N5rWdrMkMAQGQF3ZxOugO+lkd4I4Vp609WiwGM+FH3DrpAR5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6649 X-purgate-ID: tlsNG-bad1c0/1793255259-BC2F4034-634B8D2A/0/0 X-purgate-type: clean X-purgate-size: 1909 From: Chunjie Zhu nept_translate_l2ga() rebuilds the exit qualification handed to L1 from rwx_acc, which is derived from the npfec set up by ept_handle_violation(). That function deliberately treats every write violation as a read as well (read_access = q.read || q.write), because the SDM leaves bit 0 undefined for read-modify-write accesses. As a result, a plain write by L2 that violates L1's EPT is reflected to L1 with bits 0 and 1 both set, whereas bare metal reports only bit 1 (data write). The widened access bits are an L0 implementation detail for its own permission checks and should not leak into L1's view. Keep bits 0-2 of the qualification as reported by hardware, and only replace the GPA permission bits (3-5) with those from L1's EPT entries. rwx_acc is still used for the permission check itself. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/hap/nested_ept.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/hap/nested_ept.c b/xen/arch/x86/mm/hap/nested_ept.c index d88d677825f1..e116d8254824 100644 --- a/xen/arch/x86/mm/hap/nested_ept.c +++ b/xen/arch/x86/mm/hap/nested_ept.c @@ -255,7 +255,12 @@ int nept_translate_l2ga(struct vcpu *v, paddr_t l2ga, rc = EPT_TRANSLATE_VIOLATION; /* Fall through to EPT violation if permission check fails. */ case EPT_TRANSLATE_VIOLATION: - *exit_qual = (*exit_qual & 0xffffffc0) | (rwx_bits << 3) | rwx_acc; + /* + * Keep the access bits (0-2) as the hardware reported them. rwx_acc + * treats every write as a read too, which is not what L1 would see + * on bare metal for a plain write. + */ + *exit_qual = (*exit_qual & 0xffffffc7) | (rwx_bits << 3); *exit_reason = EXIT_REASON_EPT_VIOLATION; break; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464182.1674924 (Exim 4.92) (envelope-from ) id 1xMJcE-0004Yb-53; Thu, 29 Oct 2026 06:27:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464182.1674924; Thu, 29 Oct 2026 06:27: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 1xMJcE-0004YS-0u; Thu, 29 Oct 2026 06:27:58 +0000 Received: by outflank-mailman (input) for mailman id 1464182; Thu, 29 Oct 2026 06:27:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJcC-0004Wz-HW for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:27:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJcB-009nLu-Uc for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:27:55 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e751-8faa-0a2a0a5109dd-0a2a4503cc7a-32 for ; Thu, 29 Oct 2026 07:27:55 +0100 Received: from [40.93.194.50] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e76a-fae8-0a2a45030019-285dc23245fa-3 for ; Thu, 29 Oct 2026 07:27:55 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by MW4PR03MB6649.namprd03.prod.outlook.com (2603:10b6:303:12c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:27:52 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06:27: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=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=dDS9yzGxnBbN9BW3+6SHO6jQ0cNRO8GTujX0WQ5CJDVwaMOhht9WXBUdi+YnGJo7whcn/X/Zcm7I986gZwIGLaYPVagiQfYciiQ2sNNdC90nrvFI1RGZkWuv3LyKy4/ml/E9S43JgWTxR+SdZm9AE0ijHU2m1yK5NdiNCC4BjPAdkJ7G+889uCQHLfSkn5YAAfAn35af0uHGvEhbyqVTBuizQriSBwz6orcYCCj8JY6byZhNPd7ZK550vvdMmJ23fiCoRsr76ANibLSR8lG+aKF/B3t6/4i9ArqhoZvPwWSaYnJMmqIEqwKywTrLQ8/MVTwGPw2bCxcGDPJvuA9RTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vohssKWS8nBCWyXP0FGzesDtuD315htMSMAVliHIuRc=; b=GHgqOjXJ9aelKl1Qze6CERP5GPb9HUhS7WZttviEpSKUao4s/cHXNXr6yaSXs+xG6bSTxDc9Oh8judNNeXpc2ENsinShrvPTb5thMWS4YkqyNXjVigxs2ZLysjFPzAWIYkSeoj5KfkraYMJdiZ7RnVD6x/EHWRUax1z/Vl8k7dlhJ5ZrGl8UEwO72mnV2ZPfLH1mGWWvK2fPr9m6sWlN83o8WkcgdqURrMxI5nNb0aLZ9p/6lvsAjaC+TWqS8m1OmEyscMSRI/WyV/31fQFvtL1zUFgxYsIkG0p2+SOLs1UpYDNpvXikTFpRH6qxw/wjp774IdJXNZD8Y1fuGiu/ww== 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=vohssKWS8nBCWyXP0FGzesDtuD315htMSMAVliHIuRc=; b=gOS6Blij+Sb3PVZ/yKn7OZXmyCcd1AA6qq1EHpfFMhHpAjJcn7MYmzHeC3dnJWb4VwQ+2l1By1d3QFCBp4royxXDlTCzY08l80UHLfRTVej9BjMNrkZf82JZ32CGnRgxGtdx7YQkjUBhGLK4hhA79S4TNLDTi1llG6B4RVhSSyo= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 3/7] x86/nestedvmx: Reflect EPT holes hit during L2 emulation Date: Thu, 29 Oct 2026 14:26:55 +0800 Message-Id: <0176e3f6811762093c0d6e680bc1057c77d681b9.1793254779.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR04CA0006.apcprd04.prod.outlook.com (2603:1096:4:197::13) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|MW4PR03MB6649:EE_ X-MS-Office365-Filtering-Correlation-Id: 067dae9e-3cc5-447f-b886-08df3585c2bb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|261028144727099003|11063799006|56012099006|261022105027099003|261009223027099003|261026121527099003|261026140227099003|261022075727099003|261021123027099003|261021121427099003|10067099003|18002099003|22082099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: k/4/5l0rlN54911zRkoqzL8jPEZZBDoHXK2DRt8xNQUtYwxGGrTyyMa+sN8LCB43fa1cRTJ2azF5nTmMjxMlFOJP/pefWhEQzF0vGNMv/uNKb9fsm7mnpel9tv+om8h3586NIzpdSnC8qXqIdMZHTsnY8dMWuIsMpKXBGcImVyFkj3C9NYafrNw6YQiB9M2vXj2V7+ZOakRE+3rkqI7wzYx3QoZg011bbM8ILbrMU+32J9y2vlIr0FuIa5PiGWV99eHzvw5YiVU7mE5zVcbMCgclABFyfiXi80+LIG7HiG1wIkqn3cdY0oO8SeBgrcw/gynKLMeyRTjCaK6XVRgXAdT751c+9iWaRaDtwxCX/KifY6eVbalK/Q+gk6Ni63VjL8pwIx0uuZG9QStUKpUvp498++O8n4rNuHncMPhm0zZBWdJk9MyyB3REh7ZTJdUDATTEoYIjy0KDV3eLqfptGKTBG4hmltp3dtAEp/KR31Pj8UT0fEp5xvg0TqI2unQKgDcqIDlWFNp4PVKHI9G24fBG49h/wvdQJO5dGuNF2Ng4Qymgv7q0i8A1MxK3RWLgVe/hGjdJdcJsyXYZQkdGn4ec82lcMmY3tMx92SeQNyaLzADA4PFyivTFYabEae8m882ee3MvwTPg/JmXyU2bRBzeUM4bEKgnbYJjAg/opG0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(261028144727099003)(11063799006)(56012099006)(261022105027099003)(261009223027099003)(261026121527099003)(261026140227099003)(261022075727099003)(261021123027099003)(261021121427099003)(10067099003)(18002099003)(22082099003)(6133799003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?DvcyVatANR5lTs57Q+Ls0PyXKxku6WEegWEZn/+YGA3JbySN9wklXJUnPUdZ?= =?us-ascii?Q?f8doqreGjriQTSFbvQj/GknTJkux44QAZdfTz/iu8/eRJK7lmolWG94rTd7f?= =?us-ascii?Q?zAX1EEJ0DIG/oZcFjqWLgBO0UIc6YHXw2MP4/dB/V6fbHX1xjm2PS2Ml6jo9?= =?us-ascii?Q?I7FzRlMEuKW/skmhDFBKBxw+feG7JomtQ59sqFDzkcWZZuxdNkz5Ruqev//6?= =?us-ascii?Q?GcHmdoCytlPrTCODqyrORM7a75VoNVy+ltfeLywYY3IhP4WtY0yehhly3h/Z?= =?us-ascii?Q?pfI4itCKwG61/YgGrcpYBR4IPsgpiri8ARheq+Cc2dYrqovhWpjaFzXZ3V1d?= =?us-ascii?Q?r49oMrv6qtjwRKq0o04lQcGxz6aL9hdpEF2Ss5cq+55eNzi7a3lQzUMgahqq?= =?us-ascii?Q?A1Zd/XRyxecj3mkPdIOnz6mBzqixf5qL+fE4BzvKy1Mg0dljPRnFM/l2tepU?= =?us-ascii?Q?x96jsotyUmb41P+DZuISaTuuhl2OaQuBANJi7ysEJTItkbZ1dPF6OfsKpwIU?= =?us-ascii?Q?QZba44R8IwbATgKKsHoR4xC6l9zfFRz0OKOAMaAYMxY5btfczTqQUFJ7FB7p?= =?us-ascii?Q?C/lGXZ0BXBJ2T38mis+4R0+WMgNWKH1WeSdly1ljqVp7fu5EfTzMEjapdpEv?= =?us-ascii?Q?2Oq3ShkAtekSypG1RkUF0a5wKWGcojcxQxzC4IsfA/zkE3e7nFuPU7stHwAO?= =?us-ascii?Q?lNITsOwaayumlux9DGUkOih1gzVsl1YrO3nK8cOudVIBbpKjeqVrIF6DnLdD?= =?us-ascii?Q?NQ1mImOwcRBWMvtBN5+zre+ZQqcyfyX0CiFWxa4lrJcx3d/A+3KWMpXw4Jb9?= =?us-ascii?Q?anEpplGCSSuMGWWPRNKK0vFYyFy4tRNhHt9iVEgNsCXGacBbVJYw4K38mjVA?= =?us-ascii?Q?rUe07yW1hNQ25+Ry6Glcu9YVbp+yTHQNKx67f4oZimNWA7e8hSBC+DB/jVvF?= =?us-ascii?Q?w/6ele4urK5uU1afkbP3qukvDcjjmVLelaeq4FOPGEJG1U4aimQOfOZIq+dv?= =?us-ascii?Q?g3x4PP1+VNmBhJuoIemx75uLx6Y6X8ydNX2/7gM9VGpIumLpqbobc90PXSCD?= =?us-ascii?Q?w1qSD8D7Py/gaq37esf9K+lMcbQ1IklVlZ1YbXJWzmOTQY+NYFjTVjo28d90?= =?us-ascii?Q?UKb5S3s/+O+vjVdWBF26WWEha72nzjR2KkQAge+f3URu5KwuZpzHj8pAbvM+?= =?us-ascii?Q?JxiGeY7Gl7gJgZ+9y1S4OQXqxDKVFAOq+BGVDhsogfBEZRKsDHk7wCEjiQNV?= =?us-ascii?Q?IhG/fijQ5HmYfm0u2j6NckznmzEtTm4hGK+u25smAyv8Dz5vTIPzhJfJR6rr?= =?us-ascii?Q?p1kXRNWiESBBp755pCPqjD9plWrWUlbSsazyb1asxTzIkjL1kgcALTgA1wWJ?= =?us-ascii?Q?X9P/KxheWOYFWlWGexH1rsmVBKbhMo44ktjKoH/8BqwkBi8MpuC4EPgoQVHa?= =?us-ascii?Q?c2YVPlQK33cCSApcHQPR2ani0mEMm1mLqGsQm1eNH09KmpKYlVMKc6Zpt/g1?= =?us-ascii?Q?21woegj9FEN91MgZqE+QsxyvOQKVZfoVcUktmdBaFg48RLPmn0pbUjFFOjnV?= =?us-ascii?Q?8ygIgzuo09ZlI+MXMyh6MmaSDb0G6owli39+vpC1MvpJT3Tpbxf+75SFA+oO?= =?us-ascii?Q?YEODPAbzcunJ5xY9q3My6DB8NqTqfhlTFHSVXeBuoV9nHFzQm461eGQSzPN9?= =?us-ascii?Q?rI41r4mSkpeefYSp2ZIgUkSOPHz69T860xCaEIxwvkw7eB6i0wHjQUeUzQ09?= =?us-ascii?Q?ISP6qb707A=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 067dae9e-3cc5-447f-b886-08df3585c2bb X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:27:52.4390 (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: vRhaBCDByGweEyWhYO62BGVoxebqgNlr98K6De6NTfBlRHrFCH/Lcckqr6tmS+K2z/4R+uL8Nc3ixl5q4XWXnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6649 X-purgate-ID: tlsNG-33051d/1793255275-77AF14E9-72DDD78A/0/0 X-purgate-type: clean X-purgate-size: 5819 From: Chunjie Zhu When L0 emulates an L2 instruction, e.g. a `movs` from MMIO, it translates the other operand with paging_gva_to_gfn(). For an n2 vCPU this walks L2's pagetables and then L1's EPT. If L1's EPT has no mapping for the resulting L2 GPA, the walk returns NESTEDHVM_PAGEFAULT_INJECT and paging_gva_to_gfn() returns INVALID_GFN. The emulator then injects #PF into L2, although L2's own pagetables map the address. L2 is blamed for a fault that is L1's to handle. Reflect the hole to L1 as an EPT violation instead: * paging_gva_to_gfn() calls nvmx_reflect_emul_ept_violation() on INJECT. If the current L2 exit is an EPT violation, it records the missing GPA and sets nv_vmexit_pending. * sync_vvmcs_ro() reports that GPA to L1 as the guest-physical address of the violation, together with the exit qualification computed by the L1 EPT walk. * hvm_inject_event() drops events for L2 while a virtual vmexit to L1 is pending, so the emulator's #PF does not stay in vmcs02. L1 can then fix its EPT and resume L2, which re-executes the instruction. Signed-off-by: Chunjie Zhu Assisted-by: Claude:claude-sonnet-5 --- xen/arch/x86/hvm/hvm.c | 6 +++++ xen/arch/x86/hvm/vmx/vvmx.c | 30 +++++++++++++++++++++++++ xen/arch/x86/include/asm/hvm/vmx/vvmx.h | 4 ++++ xen/arch/x86/mm/p2m.c | 8 ++++++- 4 files changed, 47 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index ef9c7cd05777..b38f8dd68733 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1801,6 +1801,12 @@ void hvm_inject_event(const struct x86_event *event) } } + /* L2 is about to exit to L1; an event for L2 would only be lost. */ + if ( nestedhvm_enabled(curr->domain) && + nestedhvm_vcpu_in_guestmode(curr) && + vcpu_nestedhvm(curr).nv_vmexit_pending ) + return; + alternative_vcall(hvm_funcs.inject_event, event); } diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 29e48387a110..0ec9eb6be450 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1290,7 +1290,12 @@ static void sync_vvmcs_ro(struct vcpu *v) { set_vvmcs(v, EXIT_QUALIFICATION, nvmx->ept.exit_qual); set_vvmcs(v, VM_EXIT_REASON, nvmx->ept.exit_reason); + + if ( nvmx->ept.gpa_valid ) + set_vvmcs(v, GUEST_PHYSICAL_ADDRESS, nvmx->ept.gpa); } + + nvmx->ept.gpa_valid = false; } static void load_vvmcs_host_state(struct vcpu *v) @@ -2422,6 +2427,31 @@ void nvmx_idtv_handling(void) } } +/* + * L0 is emulating an L2 instruction triggered by an EPT violation, and L1's + * EPT has a hole for another address the instruction accesses. Report that + * hole to L1 as the EPT violation, instead of blaming L2 with a #PF. Called + * after nvmx_hap_walk_L1_p2m() returned NESTEDHVM_PAGEFAULT_INJECT. + */ +bool nvmx_reflect_emul_ept_violation(struct vcpu *v, paddr_t L2_gpa) +{ + struct nestedvmx *nvmx = &vcpu_2_nvmx(v); + unsigned long reason; + + if ( v != current || !nestedhvm_vcpu_in_guestmode(v) ) + return false; + + __vmread(VM_EXIT_REASON, &reason); + if ( (uint16_t)reason != EXIT_REASON_EPT_VIOLATION ) + return false; + + nvmx->ept.gpa = L2_gpa; + nvmx->ept.gpa_valid = true; + vcpu_nestedhvm(v).nv_vmexit_pending = 1; + + return true; +} + /* * L2 VMExit handling * return 1: Done or skip the normal layer 0 hypervisor process. diff --git a/xen/arch/x86/include/asm/hvm/vmx/vvmx.h b/xen/arch/x86/include/asm/hvm/vmx/vvmx.h index da10d3fa9617..d5bc0ab40198 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vvmx.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vvmx.h @@ -38,6 +38,9 @@ struct nestedvmx { bool enabled; uint32_t exit_reason; uint32_t exit_qual; + /* Violation raised by L0's emulation, not by the L2 access itself */ + bool gpa_valid; + paddr_t gpa; } ept; uint32_t guest_vpid; struct list_head launched_list; @@ -92,6 +95,7 @@ bool cf_check nvmx_ept_enabled(struct vcpu *v); int cf_check nvmx_hap_walk_L1_p2m( struct vcpu *v, paddr_t L2_gpa, paddr_t *L1_gpa, unsigned int *page_order, uint8_t *p2m_acc, struct npfec npfec); +bool nvmx_reflect_emul_ept_violation(struct vcpu *v, paddr_t L2_gpa); /* * Virtual VMCS layout diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 52cadd9b25c6..7660ea48fc64 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -25,6 +25,8 @@ #include #include #include +#include +#include #include #include #include @@ -1653,7 +1655,7 @@ unsigned long paging_gva_to_gfn(struct vcpu *v, .write_access = *pfec & PFEC_write_access, .insn_fetch = *pfec & PFEC_insn_fetch, }; - int rv; + int rv = NESTEDHVM_PAGEFAULT_DONE; /* translate l2 guest va into l2 guest gfn */ p2m = p2m_get_nestedp2m(v); @@ -1667,7 +1669,11 @@ unsigned long paging_gva_to_gfn(struct vcpu *v, v, pfn_to_paddr(l2_gfn), &l1_gpa, &l1_page_order, &l1_p2ma, npfec); if ( rv != NESTEDHVM_PAGEFAULT_DONE ) + { + if ( rv == NESTEDHVM_PAGEFAULT_INJECT && cpu_has_vmx ) + nvmx_reflect_emul_ept_violation(v, pfn_to_paddr(l2_gfn)); return gfn_x(INVALID_GFN); + } l1_gfn = paddr_to_pfn(l1_gpa); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:28:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:28:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464193.1674932 (Exim 4.92) (envelope-from ) id 1xMJcQ-0005B9-Bi; Thu, 29 Oct 2026 06:28:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464193.1674932; Thu, 29 Oct 2026 06:28: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 1xMJcQ-0005B2-91; Thu, 29 Oct 2026 06:28:10 +0000 Received: by outflank-mailman (input) for mailman id 1464193; Thu, 29 Oct 2026 06:28:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJcP-00058r-61 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:28:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJcO-009nQA-JA for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:28:08 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e772-e002-0a2a0a5209dd-0a2a45098852-6 for ; Thu, 29 Oct 2026 07:28:08 +0100 Received: from [52.101.57.9] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e777-be1a-0a2a45090019-346539099b10-3 for ; Thu, 29 Oct 2026 07:28:08 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by CH5PR03MB7814.namprd03.prod.outlook.com (2603:10b6:610:213::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:28:05 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06:28: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=E0dQoTcor2TTOmUNpIca37xUvUXBkAG6kzMcIGJjX5fpoAG++TvtwFOIzIAfHWU5HE1FmftpwfMaaB70JcVZADdeiiERdgZpyvk2oeGBterGB6YfDrsyGIdQDlrTvcLB2yK6FgnU/Y/1kdPjuvIMTP+HhiBN6uWnCCFTwmdHzBbkeEiymuPcVMTQh1KHrve+wzIXOKWtQ75HX5NKieTxBXtoo/ICXlYZzawomh9vyeVbEMT5NSoluh0EDINWan/7BlOFWjNhjE9WwCkgddb1Ao7sCMJ7LufLbwrYoyTxlsvfHMq5vHLBj42ifcqRiqLPrP8xnf6OkZAz/62aDgQDKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kRYuKRMvwLZ55Mb3+BJf5qlLfaVtGKo4c1WB061e+e4=; b=h9Z7MSPaCGFJCgAeWRszLSLcJe2iAVP2kaXYe4o8967sxcgUuXqaU/jhpB5ccWNNcEpdTX3yjfVdF2QCc2wCbtS4wkO+oaKXqh266kvUpVeKbDEUKXNgaZnRtvbSuLHp3GkYHlEX/elUGy8jGE+ZFrTESavBw7UjtbVB1oz704y/eT+KXHw6nfMa3rL8EgC1Brj/jWc3HnovQBI99tihu8lxvsG/hZUaOUQ+m9J5gigZJO3Eh0n1TCVIHe76KCjRpkuAkPdtk7JXVBSb7F9Q8L8ewwUoF6maQUtc+Q7/LChXkBjGpLhBq1pgDKPpQNVy01QTdcpNhu0NSgIC0hzkQQ== 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=kRYuKRMvwLZ55Mb3+BJf5qlLfaVtGKo4c1WB061e+e4=; b=xBeTXUzsJrpSjjvSb1CDFzrQfqAmmOIUI2RpNZo9J44cMDI2mzmBNoc0M8pouWMYtvpJmiCV5gGvUsX1jNgiy0yD/GguCyghEjAqUlF0n+GtyXEenv+q9Te8jLH6dCK+xIaiZYq7qMrM1AGEplzZGvWwF+NTXl83cwlebf3zQDk= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 4/7] x86/nestedvmx: Load L2's EFER on VM entry and restore L1's on VM exit Date: Thu, 29 Oct 2026 14:26:56 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0086.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:c9::16) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|CH5PR03MB7814:EE_ X-MS-Office365-Filtering-Correlation-Id: 410c71ba-77bb-45cd-c273-08df3585ca13 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|260925021911599003|260925022911599003|260925021311599003|11063799006|56012099006|261009223027099003|261026121527099003|261028144727099003|261026140227099003|261021121427099003|261022105027099003|261021123027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Y7I2CdZI0bvQnf8Xb2SMhyM+Jm7/E2UctzVRKiZhcYZftnEkoeX1IZU3/oC0L1nF0nl60euBoAC0ULSIDx6hSJL9RNkTEM0TVNlrqZWrISpHdcNdfEDj/sXUUCytILL6beSwYV6LkpNUlpcB3+95Njg5ehXDx/YBsoIpNkH8BbhxafNulb+qMkfBKgTL3Kvx9/1NCizfTYTUzx5UfsjC+S0OR4vPXtR70W8y1tWXyIcDmcBxZCbFWKkPdXgLIi9525xj7D+ls0Bi7ba8J1GFA59UBTFdrQ1H3jMkclZiKy7mrEB+V9TdeW6N8u1dw709WAG5Hwd0UaZ8oLPOFw2KVKfEqioQXw9toVJNi1frayAOZTyyZl42GasLnDBuhZlp5UCtNuOBSAtjOcwofcoaSywgP1Cf7kFFJU7QSWKhkIZ8BVIAJ4iRzp7PyxljM21UWPPSBGpBr54kPl7pRqLl5J0k10hkwYyBGlc+ObUdGVJkpK33W4oiVzpCIbwXgN9HFm0dPXjI39PWv3aTHBG+eoUzt3TRn3c119BQJqhaKZZjtgpoVT/N3aemL5ia7fxEMvWwefzSnvh6l4Wvc9cJ3O6+jFafU4ZS3CSP0snry20= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(260925021911599003)(260925022911599003)(260925021311599003)(11063799006)(56012099006)(261009223027099003)(261026121527099003)(261028144727099003)(261026140227099003)(261021121427099003)(261022105027099003)(261021123027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zyZTXeMELMeTOu3GiSyhYp23cuvTEUgOgJmMIqkS6mO/hHIDpYdF57oLOiwK?= =?us-ascii?Q?ibphafd3wuhGCCYFNLY1kbYslVfTUvU5d82MXLczx7p7sZTQ6FYEgP1YCrIX?= =?us-ascii?Q?7yNfLiQzAxRcwvQO9hJ9oPvb0s5BbxH6t+eFDA5svmighPu6ZK5iXwQkKpm6?= =?us-ascii?Q?X+j45sMgLeTcyKi2TrvCwIkgmZ5kW4EEhSehm1ogFg7uN1274f0Z0GkBv1vL?= =?us-ascii?Q?WY0b3S7bC4dt8FQfJQxIZri2NLQF0TgxMLwJUpxYLb1fz5OTsEupqfo9Fmrs?= =?us-ascii?Q?LN8sFXOoj72hC4lwFKi4+ra+Mc4w4KM7jCW9Fcj/b44qAVShnlIDWRuRtuCj?= =?us-ascii?Q?6jcTYiJwbfojt/CC7VmqhFX9Sw1QHSUKIOfgaCWQ0UJZW9+aWz5ATWprlmWE?= =?us-ascii?Q?cSCcr7eM6XfnKhw9W9Bx9nCwWjw3MIYrL2oJKpBt4xJVw5aBgWYkUUwjucLD?= =?us-ascii?Q?GV/gm63uvAHSPyJ5Nh0Oua0j6vBm4GmXQO7i+3bo86o/nievpp4JXLyiXAFl?= =?us-ascii?Q?FYzUmMBwujAoCYLH9nsC6+tl6OV7qwajOd+6WKop10EKiKfLbhU3d4YuvT44?= =?us-ascii?Q?92GuaZ8LbRLWDbjeD0xInYKGEaWXI+Z6fwdRUeeuDpFb0aA5LtNtaY/4kDbQ?= =?us-ascii?Q?NylEkEsndorITZqQC3pB6FFmTXHE/lhfAcm8wQ4lpk8L6wnf7NAqfgg3oKBx?= =?us-ascii?Q?2dA1Bjq3NOVpAT/wP0oSnfhx/k0SukE0aRJctM1n7ifjl8wA9dNp+1OpTEV3?= =?us-ascii?Q?wqGNsQjVKCOm2REeMorBIl+W+5B1TsdTO54B6BdfP8RluJbzoJfP7+tLmUr3?= =?us-ascii?Q?pIroz5VLsOv9fNhyPWUO7FZeJqrh/u4DqNgxTYtJ0ZmD0NgLjGw34J84A70E?= =?us-ascii?Q?H1Wg+8eUcqIPTreGqdrbB8L5gye/swORazbGCqHVU7e/CBbZM2RZ1y6/H+kJ?= =?us-ascii?Q?H3RCtmzRI/yVJxe2yAqUQeUY0VsfhlNguDWBzL1wi0KI06nbvX/LdiuN1rpR?= =?us-ascii?Q?tmAIkAFhMgOBXKjtvmGHWwbCpUSySgSgap+1d89z3b5EQNoCXYo5wSqqRk8R?= =?us-ascii?Q?jrLJFLZnTCmmXEVggcVFbpTwUXqNmNelbK1sz1KJe1MLf5jBMcprHAJn5Whq?= =?us-ascii?Q?vYb2gLiRKFaa/cz1RcYy0nm+eJKHsWSX3RADwyc7ygyh/1DtyWV1jWOZIcln?= =?us-ascii?Q?iYDNwAd/pf8nHjJVjyWs265WhxOqD1dvFvuOR0Et/NZ5+uKVTHxFNRGUWPgp?= =?us-ascii?Q?y7+Hfw19smJB2dZcsRUhYahS+JfMZFFIFS2Q9EWNjq67nw3uuPBycy5ezINo?= =?us-ascii?Q?0rDkgV9muoeDFcaGuM78MGXnf0Z6DknkGkUKe/adWcSO77a+PrPt9Ou0ShVT?= =?us-ascii?Q?glrlFI/S3pGPHulEV+Tv0b3nDxt7TTt8EApsma11kjydI0NoMT6BKOfIRJvh?= =?us-ascii?Q?qCc4Cuk5CUtL5b2G84hBfdoBY9xNeL1drx1r+c9eldT0/iVRqA7GZl83wxAv?= =?us-ascii?Q?/72Bs2+JxZp3tz3PpXvNznUMGDGiLJQqPVZ927h4XM6pak2pUsPBdnY7jcRx?= =?us-ascii?Q?xa0uCXjjsjPiuyJ9cu7jZpNwKo5u/R9EdT+skfvnv+w9IahGrZWiAbzqq5yv?= =?us-ascii?Q?wWcXh1+1VqQ7g5dG0v5C+ZjDAFg4+jBzRpDgjwNMCvW6pz2lP8e0Pw8QmQBv?= =?us-ascii?Q?3QsnVzC9Wcwi66CdNY9WON7SpqXrBhW2IFqaeSrXTy1Xj0MnnFZxe6Fln3fo?= =?us-ascii?Q?mXRIg5GDKw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 410c71ba-77bb-45cd-c273-08df3585ca13 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:28:05.0662 (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: pSP5d+fj6yvKJLQfAB57BioP+SV8Mi8W/jX4mGuj+7U0uHSiIiGWluIx/NZd5qdccKUUh/pTiRpoILg3lfaLIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7814 X-purgate-ID: tlsNG-bad1c0/1793255288-FD26A034-EDBCD327/0/0 X-purgate-type: clean X-purgate-size: 4060 From: Chunjie Zhu nvmx_update_entry_control() strips VM_ENTRY_LOAD_GUEST_EFER from the vmcs02 entry controls, and virtual_vmentry() only derives EFER.LMA/LME from VM_ENTRY_IA32E_MODE. As a result: * While L2 runs, hardware EFER is L0's own value (LME set), and since vmx_update_guest_efer() clears the RDMSR intercept when guest_efer matches the value it believes is loaded, L2's RDMSR of EFER is passed through and returns LME=1 even though L2 never set it. * L0's v->arch.hvm.guest_efer has LME cleared for a non-64bit L2, so L2 never sets LME in L0's view L2 Linux AP trampolines read EFER and skip the WRMSR if LME is already set. L0 therefore never sees LME, and when L2 enables CR0.PG it is treated as legacy PAE paging. PDPTEs are loaded from what is really a PML4, and VM entry fails: vmentry failure (reason 0x80000021): Invalid guest state (2) PDPTE0 = 0x0000000023604063 EFER(VMCS) = 0 which crashes the L1 domain ("Unhandled nested vmexit: reason 2147483681"). Fix this by: * Forcing VM_ENTRY_LOAD_GUEST_EFER in vmcs02 (when the CPU supports it), so hardware EFER, and hence passthrough RDMSR, matches guest_efer. * In virtual_vmentry(), taking guest_efer from vmcs12 GUEST_EFER when L1 set VM_ENTRY_LOAD_GUEST_EFER, preserving LME for an unpaged L2, with LMA still following IA32E_MODE. Then push it to hardware with hvm_update_guest_efer(). * In virtual_vmexit(), restoring guest_efer from vmcs01 GUEST_EFER so that L2's SCE/NXE/LME bits don't leak into L1. Signed-off-by: Chunjie Zhu Assisted-by: Claude:claude-sonnet-5 --- xen/arch/x86/hvm/vmx/vvmx.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 0ec9eb6be450..e37f59bea7ce 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -695,6 +695,12 @@ static void nvmx_update_entry_control(struct vcpu *v) shadow_cntrl &= ~(VM_ENTRY_LOAD_GUEST_PAT | VM_ENTRY_LOAD_GUEST_EFER | VM_ENTRY_LOAD_PERF_GLOBAL_CTRL); + /* + * Always load L2's EFER from v->arch.hvm.guest_efer, so hardware (and + * passthrough RDMSR) agrees with it rather than showing L0's own EFER. + */ + if ( cpu_has_vmx_efer ) + shadow_cntrl |= VM_ENTRY_LOAD_GUEST_EFER; __vmwrite(VM_ENTRY_CONTROLS, shadow_cntrl); } @@ -1220,13 +1226,24 @@ static void virtual_vmentry(struct cpu_user_regs *regs) lm_l1 = hvm_long_mode_active(v); lm_l2 = !!(get_vvmcs(v, VM_ENTRY_CONTROLS) & VM_ENTRY_IA32E_MODE); - if ( lm_l2 ) - v->arch.hvm.guest_efer |= EFER_LMA | EFER_LME; + if ( get_vvmcs(v, VM_ENTRY_CONTROLS) & VM_ENTRY_LOAD_GUEST_EFER ) + { + /* + * L2 may have EFER.LME set while still unpaged (LMA clear), e.g. an + * AP trampoline which skips the WRMSR because it reads LME already + * set. Keep it, or enabling paging later is treated as legacy PAE. + */ + v->arch.hvm.guest_efer = get_vvmcs(v, GUEST_EFER) & ~EFER_LMA; + } else v->arch.hvm.guest_efer &= ~(EFER_LMA | EFER_LME); + if ( lm_l2 ) + v->arch.hvm.guest_efer |= EFER_LMA | EFER_LME; + load_shadow_control(v); load_shadow_guest_state(v); + hvm_update_guest_efer(v); if ( lm_l1 != lm_l2 ) paging_update_paging_modes(v); @@ -1452,6 +1469,15 @@ static void virtual_vmexit(struct cpu_user_regs *regs) lm_l2 = hvm_long_mode_active(v); lm_l1 = !!(get_vvmcs(v, VM_EXIT_CONTROLS) & VM_EXIT_IA32E_MODE); + /* Don't leak L2's EFER (SCE, NXE, LME) into L1. */ + if ( cpu_has_vmx_efer ) + { + unsigned long efer; + + __vmread(GUEST_EFER, &efer); + v->arch.hvm.guest_efer = efer; + } + if ( lm_l1 ) v->arch.hvm.guest_efer |= EFER_LMA | EFER_LME; else -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:28:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:28:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464202.1674941 (Exim 4.92) (envelope-from ) id 1xMJcf-0005jy-Mo; Thu, 29 Oct 2026 06:28:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464202.1674941; Thu, 29 Oct 2026 06:28: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 1xMJcf-0005jr-Jm; Thu, 29 Oct 2026 06:28:25 +0000 Received: by outflank-mailman (input) for mailman id 1464202; Thu, 29 Oct 2026 06:28:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJcd-0005iC-QQ for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:28:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJcd-008G5z-7B for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:28:23 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e775-bab6-0a2a0a5309dd-0a2a4508eb08-40 for ; Thu, 29 Oct 2026 07:28:23 +0100 Received: from [52.101.53.57] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e786-f659-0a2a45080019-346535393019-3 for ; Thu, 29 Oct 2026 07:28:23 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by CH5PR03MB7814.namprd03.prod.outlook.com (2603:10b6:610:213::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:28:20 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06: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=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=YJbVM5U7s6yKgYfKwsuUBKxLCwo3kOuXfOE0yyIyt2NwR5SWEHntrCfhhaukbMsleyw70XbR87dSEzEvCyksOrDvCzDwuyIveOmsse5EdTEtEU3Nva5ha6Kwysl7OhE0kZqAns1dpgAIfUbSAc014AGau5prt7geoKL68xvIa+v10OHfgibVlnftNZjFiaaA5yvdEiB4ad7u4y5Fj2d5gHZtQrrKm159zxUsl/vW4v61bJNrsnrkwRLHVBLIXEYqj7xbf4lN74cPjVQkJTM7lxNuJ7g4x1/iK/Gxd6ueTJmwwa3gU9x7pWpnHyRbvkM98ArmHH6RJbF5PQ77T/uNtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+fayPtOf3yWaQhO5MvhVZiM7bufGtKK/IQBTh7y6MYE=; b=Jfrjitl2HAWmmXAfXn7dw9916CW1+I4T41QdpI7YlNBMuadTYxcr8YQzcIHp5xBSzlo65grPepKMunCWczSlI7ovc1YoXkcCMKfh9TnpxYRnzee8xwzVYjRE5t8B5R8tvw8Bz2BNSxoIewY8w8VSVA5MkXDVIyy1pIXJ/3vCJOpB3sInbhNzCgXesmU73grJvkHucS0sDTn36DwQoL08IBe3YItZ3E8Kv15XE5mvlwwApdT6r8e8Z6JQLFrr5o5WM1yxhhVJEI9tqPcNbeQHryPgWIU/mrWQKRPVw4DESCihForwrT+ArAIKwspGWh/ViB6Xmvb5nPzq++nsZRHieg== 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=+fayPtOf3yWaQhO5MvhVZiM7bufGtKK/IQBTh7y6MYE=; b=RH7ubsD1ND8MkQ/+s1sOc2AD9I7Rl2TZCGhdLx/i3W0hPDLova8HTK5dx5DrlBvnJ7D4dT0ES/OjLq1figT01k3lLM0LDCw+K94+ilkCYw9fUDzpe36QmUl3F/Nqks99Af9RFFVBGuT7tBaFKoPQ5NVaQW0ztuVd7TgI1IZWI1s= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 5/7] x86/p2m: invalidate EPT caches after flushing a nested p2m Date: Thu, 29 Oct 2026 14:26:57 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0106.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:cf::17) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|CH5PR03MB7814:EE_ X-MS-Office365-Filtering-Correlation-Id: a315f208-aaf0-46a5-b1fd-08df3585d34f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|11063799006|56012099006|261026121527099003|261028144727099003|261026140227099003|261021121427099003|261022105027099003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: 653/ZMybAoxF/biXcnrLRvPyzKP1gfp3n8oE9GWWazsMze+gzPHYW7kH9vp0yfgZ6gf4nzWjE4x6Wh4n5nsDQgtvNxHCceTDm++hBfIJO7I/eQlsq5FWQqgGigQcx9OP0OtK9L5Jrs5XTCZlP08cHgx5sdXjp+0KPojdH0TT2Rv85PLsMqmFD4P7TZyZyZltKpnEqjxP1vKyuIPnFvNgu2gQ15CZcRl3mCncZFVr0SQ5UXDTZOcDLtBdyLlUv0XSMOfQWfTg4Y+rejzC/fXeL7JbiawCEFdI3Lu5KANUD0QVZTDJJx7AroP8nj3b+tCGqa5LAvtI8kncQvXNWRy6C4pfWE+GKNTUetWIGTxUXvjeOdm1bVkAu4+P8XblNcEE7NM7NaCu8+djq0uD5effvXkgw/ENyI5WJ69mnaEwZUAU4wDQ2m7Ie4N7vJ0D3XH878qpIDbUueAXxJAfpJIRU6eeNGXPjZIzaj4sFxw+tHoWu98PPILvz/KFziajOIDoH5toRcoHi0nslRyHFgT8PDtPOaY70MImXYr+N9dlTthumP3qn6MzzoGMi3DqfTu+WexZ1exP4RCCwTH6h7F75CtJP4rqY2YVmY5gxlM+4mZkA+MuYSkwlqilXOzcINA0rMahXWACw/B9BGKp7J0MVNthxHLBmDyU2Z9nXS5F00w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(11063799006)(56012099006)(261026121527099003)(261028144727099003)(261026140227099003)(261021121427099003)(261022105027099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?98yrsUVmAwUJACJ2ipezvrl5s1PxmJHB60u14uGyWwxcy5GKt9QDFtOuAtsm?= =?us-ascii?Q?ICDIo2fM540KnGqnvtSiwKL0nv6jcpkEcjPwhzo+uVohCC013bJ+B2PyRwHZ?= =?us-ascii?Q?Y8hXUAQU9sC5+Y+pO2eo+XT5ChGxW/RanpIClm+OxRVs4UMdiLymyNrxoUpH?= =?us-ascii?Q?ay7q6ibBH6Dcgb+7cQETyUqMOgEJAS8hmm6beJgsWMN8g6SLE1gTC+67Sr7U?= =?us-ascii?Q?tEOKs9TC0zSFh5O1H4P3Ugw5Alt4QNmMm9cpshGx8QXELDFamKC7OK6nF3Gd?= =?us-ascii?Q?uVGCIKzi/Fof/0rAMVJSB8SeYgZ1Qt4GrdkZSzRYL4Bv0L1q9e+JcfGtiNcN?= =?us-ascii?Q?oUFE9WYhCK05rCJnjH44gDrTWBXMLk15aFCasNsp3XSgEuSYTjbkDm/kYT4z?= =?us-ascii?Q?+jfI5DpBHLCqvgMH+ecO2/OE/njOLOa8u9kbF+8X0qwrMqcxS2AHBYGZGaNS?= =?us-ascii?Q?TJcMolWb9cw7NXT/bunhtLxaV1rnyS5Mvewqdzn0+E9iNRygPv+vTydzncSc?= =?us-ascii?Q?sm9hrDRug0bYzbSU7TVASqabq9PL58pI8wTQHMoRStKYm2bathupVhYnGtTD?= =?us-ascii?Q?/sJDEFh6ngp3uHCMJxk7JnIXwae2cFOha4qULTo/dbYj9m5yJyk66Q3XkCDO?= =?us-ascii?Q?vVh0GUutLQCihQHF37UwTzBeeVAVFfLXbMr0r2Y1nrUyfEEAi0M71txyR0rY?= =?us-ascii?Q?12Wp2QGjje1oiI5Ih0ffiIGdgqy9lc+Q70uwi37tbkp5OI/rU41AVZPNaYCF?= =?us-ascii?Q?QGDAlbizrjgEeX/2qdlhm9VTETrx2TYhoTjMKtk1Xy8MgZM7zuSz3MLn+xj7?= =?us-ascii?Q?8rH8j6XJYNk6k6vhJp/bfMqDXGRP/lNGkPOgvvRdVCM1TcVIMF2Uz5CwuRES?= =?us-ascii?Q?5U5mQrulids1BFhEJxqugHmLNN9Sq24x6WZb6Gn64DcbJAY7ziOUQdZqBV1G?= =?us-ascii?Q?q1FIAsv7u8oYnPqEGaos92L0FDC/Rm2L7ipX17p+ikCwV2n0MAIxuLFBYl9c?= =?us-ascii?Q?uhXic/KSvaZ8celdMmc7n1DX6gqapaVvbg64ReM5mNTPLo3roljrC6c3N4RP?= =?us-ascii?Q?pluLI1H3b1K3UkeVBJKxIXDH+Djr1ErhXbBIsyHaVW8Rsthqi/+dgSnF5PWD?= =?us-ascii?Q?/rlR9lJE3ohZhr753Yw9ya0iKojORIqiu+IvpPmrwR7fTWZYVA85nfipB9zF?= =?us-ascii?Q?Xe6mwfWjM3kpmr3liQZrwAPTSCaUVp3LE2lSk/HYxweASMTkZn9SKsHNOQv+?= =?us-ascii?Q?JxhdNW9Qls8aKFXDJC4LYWBHpNbJLK992gxk4nKW1DMcBQfSXlVFpXV2OJHR?= =?us-ascii?Q?OuKczS20S0oHHM0kQxJasxGOFvYAuUIIlydqSL/R0HDosZe1qczG/Z0RnWpn?= =?us-ascii?Q?7uDuTB+pbYQp+6OMiYr7bxcMUYgUbzNJuIivAwG4i6cQl3nF4R4I8ma8zMgK?= =?us-ascii?Q?zugfnH0Q4se/03h/1r7zZkmopC/IdKMyOJzZywnqO3tCfSM8XPDfGZGt9BtQ?= =?us-ascii?Q?UMoOtU8PGK+2VtCyc+SUez0Ib8hLD1E8x6g1EvKq2GApXin4BgX+iIsdOmoD?= =?us-ascii?Q?Ub/RvnuSeWS7dd73aa4FgHnQKx6r/BYJ04jTWpmqgutzhofgmyBzd2a1Xya4?= =?us-ascii?Q?Hix2rrPkSrFN6FZweB7H8XPbFKEiJs+ppk+44aFhhuVwMFLb8ilO1+A7qb/Q?= =?us-ascii?Q?k9S+oqZKxkdmyRO0qMfqFMAjyqnhkV1uoL/4LsAaarKnOWNtFAlEoSyX1EdT?= =?us-ascii?Q?KqJPF4fKew=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a315f208-aaf0-46a5-b1fd-08df3585d34f X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:28:20.4619 (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: 9hKH4anRK/y9duVHAIW0q+h6sHi4ShBUCrTE9rQWTqzLtwhRsmIQa1wwmOsapdaYCQ92iEAnYYS2IdUTPZis0w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7814 X-purgate-ID: tlsNG-c1860d/1793255303-CD94A87B-C789FDB7/0/0 X-purgate-type: clean X-purgate-size: 2390 From: Chunjie Zhu p2m_flush_table_locked() keeps the np2m root page, so the EP4TA is unchanged, clears it, and returns the remaining page-table pages to the paging pool. The only invalidation it triggers is nestedhvm_vmcx_flushtlb(), whose IPI handler does hvm_asid_flush_core() and drops the cached nv_p2m. That only flushes VPID/ASID-tagged translations. EPT paging-structure caches and guest-physical mappings are tagged by EP4TA and survive. After the flush they can still point at the freed np2m pages. vmx_vmenter_helper() issues INVEPT only if the CPU is set in hostp2m->ept.invalidate. ept_sync_domain_prepare() sets that mask only when an already-present host p2m entry changes. Nested flushes (L1 INVEPT, np2m LRU recycle, p2m_flush()) never set it. Filling non-present np2m entries afterwards doesn't set it either. Once those freed pages are reused, or scrubbed (0xc2 pattern on debug builds), L2 walks through stale cached pointers and can fetch or read garbage. In practice this showed up as L2 guests executing 0xc2c2c2c2. Mark every CPU in the host p2m's ept.invalidate mask at the end of p2m_flush_table_locked(), so each CPU does an INVEPT on its next VM entry. The cost is paid only when a flush actually happens. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/p2m.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 7660ea48fc64..77e3d9b57574 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1425,6 +1425,17 @@ p2m_flush_table_locked(struct p2m_domain *p2m) d->arch.paging.free_page(d, pg); } page_list_add(top, &p2m->pages); + + /* + * The root page is kept (so the EP4TA is unchanged) and the other tables + * are freed for reuse, but INVVPID/ASID flushes don't cover the EPT + * paging-structure caches or guest-physical mappings, which are tagged by + * EP4TA. Without an INVEPT, a walk can follow a cached pointer into a + * freed (possibly reused or scrubbed) table. vmx_vmenter_helper() does + * the INVEPT on every pCPU's next VM entry. + */ + if ( cpu_has_vmx && nestedhvm_enabled(d) ) + cpumask_setall(p2m_get_hostp2m(d)->ept.invalidate); } /* Reset this p2m table to be empty */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:28:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:28:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464209.1674951 (Exim 4.92) (envelope-from ) id 1xMJcr-0006I1-Uy; Thu, 29 Oct 2026 06:28:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464209.1674951; Thu, 29 Oct 2026 06: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 1xMJcr-0006Ht-Rb; Thu, 29 Oct 2026 06:28:37 +0000 Received: by outflank-mailman (input) for mailman id 1464209; Thu, 29 Oct 2026 06:28:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJcq-0006Ei-OK for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:28:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJcq-005898-5N for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:28:36 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e77f-2eae-0a2a0a5409dd-0a2a45058b36-18 for ; Thu, 29 Oct 2026 07:28:36 +0100 Received: from [40.107.208.37] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e792-4cb1-0a2a45050019-286bd025bd8b-3 for ; Thu, 29 Oct 2026 07:28:35 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by CH5PR03MB7814.namprd03.prod.outlook.com (2603:10b6:610:213::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:28:33 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06:28: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=b+BdljvVprzlpfiTe0CLc6hcWq8lLQyYibGbQAVdKWexQF05GBwIPyEKt6wiGMVKm0hCQHrKVtEQLLRffL6iHK9uMo5pvZxmgAIJU4p/wh6NcrCitm3BxOhSO8KjgazJFXViHiXrDid9xtVTucSkMMc0DNMIkFVaoci9vf97WQvQYcYRBXY8QYwx47aaiJeEdqOQO2LaHgAArSbZ4NCl1CzkGGmjdUMZGPCMGWNz/qyl2HaPRL8WHa5lL4bcThJx48IquLRRKF9SNCxN1hj7yZUI57aCSNODoCSqTHlsgMJtbKc+qFHNivehZOgWjWVeeuW5NGx4sMgPXTJg+xg/eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Cy/UyqDtdWpV9UIv+XFXeIi53yw8IbZ1xohIkknhFmU=; b=jtPYIGoNfxJ3i902nOLK9prJ7vS9pghuU/jSmkIjB0frXh9jZAKS98YRw1pmZvFjUpzltTCwZvbuo1zHAZ1iNr1vIyO/wHsWvl77k2IMCYtOPsQyz/ULR1KnnJYLIISefTKaRUM+ID9ekSQuUWARoeTmeg7wASREw1wesEXrfNlKrKfDFFPhtmeoJTmW0AlPaveMzRVPesJnxlV0qbl/LXVjWv24JEHV6tFn+r6h6P2ZrXZbP0ale6X8cyPvoLXK3JpuxCWpUuxblmqC5y6McNuQq3Caqv0rK+QICSGbQUNsWTpi+hjj+iOrLe+sxhdxnXCPl8Hb0cIRsmMl+Jc+Hw== 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=Cy/UyqDtdWpV9UIv+XFXeIi53yw8IbZ1xohIkknhFmU=; b=cI4RnVfAqvu3XLAcfHVBq1jufZPpc3ZdX8f0Oxi+b97I3FesrZDwf2XvDVO/o4QNssWZdD10799b9gAgaVulEAetf8bFTIcsFIoAC9M+O/ECl6DOo7FA3rjC2+jFLm5DZ3WiCrB8pM+/KNvtXxIYEqZaoN5utMWCMNfs134fg6Y= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 6/7] x86/nestedhap: Retry nested page fault if the np2m changes during walk Date: Thu, 29 Oct 2026 14:26:58 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JN3P275CA0077.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:c9::19) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|CH5PR03MB7814:EE_ X-MS-Office365-Filtering-Correlation-Id: acec0372-01fb-4224-3df4-08df3585dae3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|11063799006|56012099006|261009223027099003|261022075727099003|261026121527099003|261028144727099003|261026140227099003|261021121427099003|261022105027099003|261021123027099003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: lOzQ72l8y5FupyukloAXjKwIHLXYRO3+3x+tbz7YPlDg/bKRpxuw8NmhVMghPa95ip7nJHkQ4mKXE+wFCrAgcK6Bw5iwf02cujDR7Gx6sPQEB2uTTI4fvRy8Zp2fSHqaVK5xDy1n4Rn0Yvkd1wKjrF4IH5sSkwAsK1K3YeItHqZKUGivn1UMRkJqmI7VCnxp22Cvez73g9ckRiyQpPij7IMj4Toow7Qw66c+rT81oIdHDsYvyt4DDSV/URIUmIIDWltPr8cp0SQ/oqBw1FtpCfaeYlfyIGUheKILZw8hy39NwHswsTTND8nR9SSXfSxLBCooXpi/TlKx89SNjAkI065zJ2W7Y5qy6k0EbwvnFVUicYQsbNOgX1Ly2khoKeEQ4xiqbnAAot7LPCWiGILDW+CmzJC5FJyW4qgWZKZq0uaQbZf7cd1C5Jda14bU2p6sGGY2UUCqWZ5+LOCvlKEjoSAK4BaRJZW6teEbjzIs46m+9j6IF69gZYZyM2C3DPE0yUeskIa/4MvOitQQbtcvYTPA1MJIURlRmk3Y+Ow9racZzdu4uQrh1LajJnTvuQsbdkMASKXUnY4cWRzrqV7hBa2rMX9n59e6QPhCuk94oRKqqprCiyF4SxqQLM8TLGDLmevgjdCnxW6ZaKuWBurjnv4GzJAkdu13VpyCCbqdii8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(11063799006)(56012099006)(261009223027099003)(261022075727099003)(261026121527099003)(261028144727099003)(261026140227099003)(261021121427099003)(261022105027099003)(261021123027099003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AAtBAlQ/wiW5UiG83arWR9h2VP/m50ewR7tUt0khL9MoE1M+c38pwxaMKm4u?= =?us-ascii?Q?rkc9hZ0kIotbLX7S1AuSUYjTFeMUPm0xWpAXwUtXxxsXaVxeiAtwJHDPh3PN?= =?us-ascii?Q?JKbhAaLX6U7FZUonLnRPEFsjsOR21wgHkcFsIDlrZUiiqW3q5Vispb9ZMedg?= =?us-ascii?Q?fWcJaLeOlsxEOtYYTk4ax/AfeQz7pwKu7u/zxPcO6+vyTWUL4suuIDuXJFSM?= =?us-ascii?Q?lANUupe4bb+VRt6vaDUpCJJgIKm6MPeRRtPqiqABaZBU3u/04yrF5mCvXc3L?= =?us-ascii?Q?OxG3LHgntv9AZsm86ali4A+HehoxUuCeyFbgOkThTDXkjNt1u2yj7WB70BRv?= =?us-ascii?Q?0yKIQRvf0m6PN9gjjKOz48Z0JCatVteMENWSWPfk/lsg7Tqr5Onh++/CdC8O?= =?us-ascii?Q?mYcUSNCU1a9Ue7aU14l3pZlLHhnv+2LXzoksuw7CvFR4xY8UVkaIvIJpzMaj?= =?us-ascii?Q?ZBPc4wdbj8Gy395MUIfPx76Me1CrZhdIgBye6GZHuZg1mVy5rKvs6DsY67u3?= =?us-ascii?Q?gWsTp/GbIAUncmmPGLHY68bLJ3OlpzCPio5ke8t5ls4mb6GwdbYGnJBOrcWq?= =?us-ascii?Q?Pn0NGbrpJ5xEhGQ7QcHGIhr/Bhj5tk3WxWeh2eic7hrZZ/vEynuOh4XbqTPa?= =?us-ascii?Q?sRROavei7rDfWHwUC1sYrYOOumwDuIsz5I6oShAM8cWxOpIU/Q2CR/QMyku6?= =?us-ascii?Q?6MNREen3pu6em3dlGDjQ8BxZUffzghawS/ZoOgDozi0Au5vS17Dk7spHdmiR?= =?us-ascii?Q?yZTbgFcsvmsngs9uiJrAe2TwtmGcJsVilY1FxWb2A/UtFaYphHUgpWGENfaY?= =?us-ascii?Q?pe3kJNSTcxNWQbKIjXe3x5l3xvhr2kdKi8zw8TUGEL/UGVPUyn73TvHRaYml?= =?us-ascii?Q?uOMq8koxFIt97ytpyqoAwiU+wmKFvKugOE33eMGL33941nVk6djitumyaXFw?= =?us-ascii?Q?nWYxwIEEMYWfTHrteL+UjVkZbxUmOSSpTzlj5/HWC1aKEIPfbDkvI0f6dnnx?= =?us-ascii?Q?yoM8T0eYZlbn2vnE7yg0NIZQ45fAU2DTO8AaqswcA6m6n2+mGKub2v+n4Q/4?= =?us-ascii?Q?ze9m+QY6NibgBx+9SG+Dx7qM1qy60vNHcPMmLFh1H1mqUl9QQoKcKKgRCP84?= =?us-ascii?Q?x6lAzfVAzb+PgEt+9Z3s6ILKh5hhha67aoHmRwGU7fx3NBbBUr319m64NkSg?= =?us-ascii?Q?LVBAqFAznssXszncJJ9fHV+XeXMhmWV6m1moC7kBRhOT+wSMYHYiDOFhv074?= =?us-ascii?Q?07ABSj/PnuongOiWGldjZXHpIjRldGIam8mCuYvFV4+qSLMm0Uf9LLNSLG00?= =?us-ascii?Q?8MlVNXT/T4P2cX9Vlt4scl87oXlnZNq4SOaj0ksAA4ioNXruzugFNJp7m/ER?= =?us-ascii?Q?cLEcJf2kYk3b9HhA4DewZxVo9mILqf0dlUyf0fuEloJBQZU8M0PB+k1qrAzn?= =?us-ascii?Q?G+puC/lorqBtktlEoSQrrh8MpHgp/+0ybZr4DqHNuwPdIDqDtrOtGwtTVXgA?= =?us-ascii?Q?tt7kJka5U8Py046hS0PtKmCPaTTke7Tn7RY1opUjIiR9hibYmggaA5y8kkcM?= =?us-ascii?Q?NiBxhCPi7B5Mju12BNo6aMI/xQGWlx/ibchDk2r3cLLgzaDfRq09yh1fiUbw?= =?us-ascii?Q?wQaqgPRkufWxnlJEcbm+65szGU00gYjHSJj158b72hO2TBq/LzL7cV4T3hSZ?= =?us-ascii?Q?2ve8axmJwQGAz8glAYTcZXFbUwPQYr0bbDYrN0GelnSMFIFwduS5ZWlzwddF?= =?us-ascii?Q?B4nf0X/fTA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: acec0372-01fb-4224-3df4-08df3585dae3 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:28:33.2863 (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: +zeNss385swAhxGWONBQuGESEpTyKiA7FoCVnFlVo2J/WQR5ZT3GkSBWBoVBYqmmEb/ZTIKliX8swc7NAXRFBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7814 X-purgate-ID: tlsNG-c201ff/1793255316-726B52A1-5C2F51D4/0/0 X-purgate-type: clean X-purgate-size: 3840 From: Chunjie Zhu nestedhvm_hap_nested_page_fault() walks the L1 and L0 p2m tables without holding the nested p2m lock, and only afterwards looks up the np2m with p2m_get_nestedp2m_locked() to install the result. If L1 changes its EPT/NPT base or the np2m is flushed or reassigned during the walk (np2m_base / np2m_generation change), the translation computed from the old tables may be installed into a np2m that now represents a different L2 address space, leaving a stale or wrong mapping. Snapshot np2m_base and np2m_generation before the walk, and re-check them after each walk step (L1 and L0) via the new nestedhap_np2m_changed() helper. Re-check them again, together with the np2m identity, once the np2m lock is retaken for nestedhap_fix_p2m(). On any mismatch, drop the lock and retry the whole fault from the start. Signed-off-by: Chunjie Zhu --- xen/arch/x86/mm/hap/nested_hap.c | 40 +++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c index ceabf31ec0ab..3db3eb259d3e 100644 --- a/xen/arch/x86/mm/hap/nested_hap.c +++ b/xen/arch/x86/mm/hap/nested_hap.c @@ -101,6 +101,19 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m, } } +static bool nestedhap_np2m_changed(struct p2m_domain *p2m, + uint64_t base, uint64_t generation) +{ + bool changed; + + p2m_lock(p2m); + changed = p2m->np2m_base != base || + p2m->np2m_generation != generation; + p2m_unlock(p2m); + + return changed; +} + /* This function uses L1_gpa to walk the P2M table in L0 hypervisor. If the * walk is successful, the translated value is returned in L0_gpa. The return * value tells the upper level what to do. @@ -168,13 +181,23 @@ int nestedhvm_hap_nested_page_fault( p2m_type_t p2mt_10; p2m_access_t p2ma_10 = p2m_access_rwx; uint8_t p2ma_21 = p2m_access_rwx; + uint64_t np2m_base, np2m_generation; p2m = p2m_get_hostp2m(d); /* L0 p2m */ +retry: + nested_p2m = p2m_get_nestedp2m_locked(v); + np2m_base = nested_p2m->np2m_base; + np2m_generation = nested_p2m->np2m_generation; + p2m_unlock(nested_p2m); + /* walk the L1 P2M table */ rv = nhvm_hap_walk_L1_p2m(v, *L2_gpa, &L1_gpa, &page_order_21, &p2ma_21, npfec); + if ( nestedhap_np2m_changed(nested_p2m, np2m_base, np2m_generation) ) + goto retry; + /* let caller to handle these two cases */ switch (rv) { case NESTEDHVM_PAGEFAULT_INJECT: @@ -192,6 +215,9 @@ int nestedhvm_hap_nested_page_fault( rv = nestedhap_walk_L0_p2m(p2m, L1_gpa, &L0_gpa, &p2mt_10, &p2ma_10, &page_order_10, npfec); + if ( nestedhap_np2m_changed(nested_p2m, np2m_base, np2m_generation) ) + goto retry; + /* let upper level caller to handle these two cases */ switch (rv) { case NESTEDHVM_PAGEFAULT_INJECT: @@ -238,7 +264,19 @@ int nestedhvm_hap_nested_page_fault( p2ma_10 &= (p2m_access_t)p2ma_21; /* fix p2m_get_pagetable(nested_p2m) */ - nested_p2m = p2m_get_nestedp2m_locked(v); + { + struct p2m_domain *current_p2m = p2m_get_nestedp2m_locked(v); + + if ( current_p2m != nested_p2m || + current_p2m->np2m_base != np2m_base || + current_p2m->np2m_generation != np2m_generation ) + { + p2m_unlock(current_p2m); + goto retry; + } + + nested_p2m = current_p2m; + } nestedhap_fix_p2m(v, nested_p2m, *L2_gpa, L0_gpa, page_order_20, p2mt_10, p2ma_10); p2m_unlock(nested_p2m); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 06:28:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 06:28:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464217.1674960 (Exim 4.92) (envelope-from ) id 1xMJd6-0006sx-6a; Thu, 29 Oct 2026 06:28:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464217.1674960; Thu, 29 Oct 2026 06:28: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 1xMJd6-0006sN-2k; Thu, 29 Oct 2026 06:28:52 +0000 Received: by outflank-mailman (input) for mailman id 1464217; Thu, 29 Oct 2026 06:28:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMJd4-0006qN-Sq for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 06:28:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMJd4-008GBj-9k for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:28:50 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2e793-8faa-0a2a0a5109dd-0a2a4507e7d8-18 for ; Thu, 29 Oct 2026 07:28:50 +0100 Received: from [40.107.208.33] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2e7a0-b4ea-0a2a45070019-286bd021ba94-3 for ; Thu, 29 Oct 2026 07:28:50 +0100 Received: from LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) by CH5PR03MB7814.namprd03.prod.outlook.com (2603:10b6:610:213::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 06:28:47 +0000 Received: from LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902]) by LVXPR03MB989161.namprd03.prod.outlook.com ([fe80::f728:f8a9:4e0c:d902%5]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 06:28: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=GftH9fY4Av1SSvC8NJr2nvdtWv8Y4yVwo9C+S8Eou+aR5aPDeIxQUAXQ3hXhoui8W+AbM7sg55sMr2u/UYDEI7X8VM5nqcidarD5t3IOOT/ECtiafUhqspmiB8N4MsgTCWXLvCvwgVbjkpeIW8Rh8GHAn5yXK78iJsUsvp0j7zfmJllqQDfPQmrtTgY9RY6njqM9fecOEZlVlgF14qOG4GaQd5GhR4ZNMX4WEFKUZTvDpOEociBkTp6reTXTenkby75smRJtks5aLzvL1QmbLeoEffc/dDN7IGVzSlNQuCZnsNfNnq3YfD7vHUmMd5yfUcuZMiMMx+NfHRpTRj8uAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IZmCapoCbbC98HQoeR/WondHb4MXNQh7OP39+AjyYYE=; b=gEGAmQ9MCvGJCtlL8POtXL/J7bXw272zmKoZx4RZ/BXGp9WebYgzFP4tfhMJQE/Au5T9yI2LA2mzsrRNqqhfJLfqj7xyZo32waHTaqAI/hFWJsLGVGEz6bfCFhd2+HA5N4GBpU+DxIvs5QBSdK3kpA0sd6IhF3hSBM2AprmgvE5vfZfVhEbENPP0kuuvbidgP+fkMEd1/doBESHdAmLVc3luRs4WD6/yD7CWWF5uHjd5LnwLil1z96LmRzR/TlcU1uiYhP0aZFNDenyA4i/LOAt9D6QM9MGl6FTIO3LtSL/pWdww7dBzo+HohxrMkOvfh1F9OxBTxSioo1NG+dCtcw== 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=IZmCapoCbbC98HQoeR/WondHb4MXNQh7OP39+AjyYYE=; b=pNFhG0Wrqh38MawNfIQTlLlx0cmAv/f+r1trUeCPjzcgQvRDr1Us9rYScmj2QzR9oS0GATJBt4JxySl0bCMso0J48JFqySV26x2xHyQzgtcpBgeOaisZmto8iXRpHA6HBHz1QLTtCs5o1ildrDr4ZbQP5fSgzIhvx1r3z2aOp4s= Authentication-Results: mx.microsoft.com 1; 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: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, dpsmith@apertussolutions.com, Stephen.Cheng@citrix.com, Chunjie Zhu Subject: [PATCH v2 7/7] x86/vmx: Fix nested VPID handling Date: Thu, 29 Oct 2026 14:26:59 +0800 Message-Id: <1e256a5695a7c4c5fcba052ec820cf3dd7bfc8f7.1793254779.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: JNAP275CA0020.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:4d::20) To LVXPR03MB989161.namprd03.prod.outlook.com (2603:10b6:408:37e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LVXPR03MB989161:EE_|CH5PR03MB7814:EE_ X-MS-Office365-Filtering-Correlation-Id: aaaeb7d7-48bf-4fc5-fcf9-08df3585e2b9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|5023799004|11063799006|56012099006|261009223027099003|261022075727099003|261026121527099003|261028144727099003|261026140227099003|261021121427099003|261022105027099003|261021123027099003|10067099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: f5IUm9M4pD+Oerf1YjL2hvpKINLmP9YWJPjxNCUqMm3uGaS5VHMgy7mQgyEuGsfF1y6dSaphZqfbIjF9BNiUjP9BBt9lSeU0X3VZqmtCcrMg0l/EQNKq+AI4Qs3Zq90YktX6HDWoQFhiQ+gbdWkJaw6wVJ3twGqFgIOVT/WG5sHyXOTPu+D7gtcd9E4b74RRj6FL6P6B0bxkTwVgRtCAvFKPzpYJiIqy7D8IfVoxj+/kcar97YUxmlHuwTdABQvm3usoZQWmVLiZX6q0izHl+4CpOyXeyub5v8F1/7QaIScs+x48qX25oBI9zGOsXllYH7bKzie+SKv5La41sLaB1kxhKOE2TupmhJJhYxdnS8ksOV7J0mFwRjQxmXt4lDyG2pjCC5WP2wOQhtS/xnUsUkDTB21hQKzTEr9d1TRfq26a2seJejh9GXTbKrENXHlFrllEAKO5cxcxhu0UuFkkPkDnhH2eLBnxNBItl0cz0m7fHmunWLdRyKJv1UpZ9m3EafHoi2Dv6wyAZwNQNZWOYiR0gDIQMLGCb923PymvBUGfdo1qBVhCCHE99rOjaxuvdWNVQL0vObrzf6vdKWLBti4+rm91yyfJv01v2ultScCXgbG0cb3O91I3cxEmUoossyzgTSrzZ/9PuQEscGNiTW+OylCuexyxR72jmm6Dn/o= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LVXPR03MB989161.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(5023799004)(11063799006)(56012099006)(261009223027099003)(261022075727099003)(261026121527099003)(261028144727099003)(261026140227099003)(261021121427099003)(261022105027099003)(261021123027099003)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bFMbDpXW4lYnAoFBfyWWFNA4T4muUre2/7kO+C8kDIqTte+o5y//qTSrYiVj?= =?us-ascii?Q?ai5utvKe/Mz1C+oJsuQeJsO5E5LTdaTs1P7lCL3RQp5eXItDqF67rGJPloAp?= =?us-ascii?Q?wpr9QwypTyrOkm2luxnWoLYF2PQ543qbSf+hliSVHc7alSyOSL4+JhSfdeZl?= =?us-ascii?Q?+fOYnmiBZPZH6/0GsVhc9riApUjVoCxyBjISjD/+joALNE1xvhdwlhqwguzw?= =?us-ascii?Q?XHpQpSKPUdOfbxNWQrW8Y+gVO5xMVLQs9G5WNIDDJZF6CL7kKLVVkgUzy5qU?= =?us-ascii?Q?1JVFdAt2WL0NTgy++8/EiQVmtAtOjzD5GRUDmsjJouzvtUxv7UXCE26IItqK?= =?us-ascii?Q?8LbjMcJVDlaSaFYYb9TAayepo3mr2ShCpjboaLdwMGyBxjEGsMe3TVXdIL2o?= =?us-ascii?Q?bcn+PWai2KTrHdgO454b39qI0ePixdIlH7S8Rq3isxdoBhdIxVFLhum30KAD?= =?us-ascii?Q?vIK+UEjdBv6JHsYi+3bbptFE9uQu3pJlT/hommAyfky7DACjsovvh6EFnbW/?= =?us-ascii?Q?RSUiDDTxEc/M8MEyR21m69v014KsgR/SDcoe/25bAnEkckevne2pRmBP4U64?= =?us-ascii?Q?CD1Q+SnkTd+7CtrvGy9HqATNxzWKU5XV7QqV/XxscH2c96p8wATCeIpaj4kx?= =?us-ascii?Q?YBOBeI/q2OQsJfbBy1kJyko4GmYGw+3h/qLZk9rDR69/OccKDhQWCP1xf/3h?= =?us-ascii?Q?eW+OPHCeyToGz3wXXm610DzHjPi0fVNwsijkWh39LcVVb+uqoX2WXicvQtHm?= =?us-ascii?Q?TQ1FpxPaYJsftWONJG9DZaYWYRl4Wh/08SSlcopK6LN/BpD9tOr0nZGF5FEF?= =?us-ascii?Q?yAPjjw5E6d5+UGHTXUERmKFqKLmtkCuyYUPFTBDxaE2UKJLKmt4+gAnfnu3e?= =?us-ascii?Q?4SAZwGaXkL1xpBcMtvwMt1jr3wzZsEPID/lY2N4vxN3hgz2UcRpd8wWU1GjN?= =?us-ascii?Q?TiAvhY4WAxa8mOTCWEpVgXFieTNLbdjKuS5h6HL7E0wd1tpV3fVkOsJZhvmR?= =?us-ascii?Q?/sN5+wKVn63ZRFOapsaaoxbu7QMFo95xTyahjVQIBlJR+gQ+t9P4KSR3VHY+?= =?us-ascii?Q?jSTuZKOD2pq0Xxue8Kl34pOLWxG5quggSdo2pJL4a7NJE3mEzKRBpG1kCOkm?= =?us-ascii?Q?JUPY/+R/hZIU3kxFsUwsoLD0gGxQFb8u4gk77j7Z3RD7/r4FFySptkgMIWu2?= =?us-ascii?Q?MtE7yV/1XFdmyjxX4IQBKIMhW29rdNU0/m6/OEcU5zAbfj6AYJFG9aLApnwo?= =?us-ascii?Q?bdkoAN3BeBQSmZRYhEBAHikgvfPUZxNMYAhRIls8EZVGujc5rqRZtFB9hgkS?= =?us-ascii?Q?Mw0sHPARUOOyor8gi8ZwyD3pKypTzCkr9nmfH69BaFqar/yhUuA1qmF7z0vB?= =?us-ascii?Q?0KdqUnPcZyuCqw95Mj+qzX8glbRvd4t+e4Tmv2isp7Xs0HJgenYRA+EgFOMx?= =?us-ascii?Q?+rPTLbcRFuHed0q7342NmwIEiw4Jv26XScuuuiLaisHIuC7Sxkv8fXHlLlmZ?= =?us-ascii?Q?V2mgTTjqpZt4NXGGVCdaecpNG3gdKZUzBc/svJxFyFgSHu2cYP4eIjrpMHsA?= =?us-ascii?Q?bCDMptlYG8ZiAZi4IEuO17c+bX7EOshVW/C5xxeQ3CUfT0+JWhmPGdeeweGr?= =?us-ascii?Q?bHbFZ1LJD/gp0QGeRby4o0nIWM/aK/yPvbp6SdM9wb6RRcnsb8JtcfnMIzUS?= =?us-ascii?Q?Inrsfqeyqnv0fge4WWb8pGn5Wa1rnjaG4tLiic1trCUe3s0DaZFRPsUwFYvk?= =?us-ascii?Q?dD7UJpJrlA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: aaaeb7d7-48bf-4fc5-fcf9-08df3585e2b9 X-MS-Exchange-CrossTenant-AuthSource: LVXPR03MB989161.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 06:28:46.5868 (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: xCaIkismC4uo/KeKmUHadq7MVPxR7xzcCWoIuO5drW1YGxaFRGbUMi2zedeGbNHahqZQqQkbeZKRzu35QJfxFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7814 X-purgate-ID: tlsNG-ef75cf/1793255330-A68D9AE4-A747E11B/0/0 X-purgate-type: clean X-purgate-size: 4125 From: Chunjie Zhu Some nested VPID problems: * nept_get_ept_vpid_cap() ORed NVPID_CAP_BITS into the low half of IA32_VMX_EPT_VPID_CAP. The VPID capability bits (INVVPID support and types) live in bits 32 and up, so the low-half write advertised unrelated EPT capabilities to L1 and never the intended INVVPID ones. Shift them into place. * virtual_vmentry() only tracked the L2 VPID when L1 enabled VPID. When L1 does not use VPID, all of L2's linear mappings are tagged with VPID 0 and must be invalidated on every virtual VM entry, so flush the n2asid in that case as well. * vmx_vmenter_helper() jumped over the whole ASID/EPT invalidation block when the CPU lacks VPID, which also skipped the EPT invalidation that has nothing to do with VPID. Skip only the VPID part. * Nested virt only can be enabled on any HAP-capable hardware. Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- xen/arch/x86/hvm/vmx/vvmx.c | 11 ++++++----- xen/arch/x86/mm/hap/nested_ept.c | 2 +- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 3c7374a9ff42..00fe2ada4f86 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -4942,7 +4942,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) vmx_pi_do_resume(curr); if ( !cpu_has_vmx_vpid ) - goto out; + goto skip_vpid; if ( nestedhvm_vcpu_in_guestmode(curr) ) p_asid = &vcpu_nestedhvm(curr).nv_n2asid; else @@ -4974,6 +4974,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) if ( unlikely(need_flush) ) vpid_sync_all(); + skip_vpid: if ( !paging_mode_shadow(curr->domain) ) { struct ept_data *ept = &p2m_get_hostp2m(currd)->ept; @@ -5016,7 +5017,6 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) inv == 1 ? single->eptp : 0); } - out: if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) ) lbr_fixup(); diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index e37f59bea7ce..8b1efed8efa9 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1264,12 +1264,14 @@ static void virtual_vmentry(struct cpu_user_regs *regs) __vmwrite(EPT_POINTER, get_host_eptp(v)); /* nested VPID support! */ - if ( cpu_has_vmx_vpid && nvmx_vpid_enabled(v) ) + if ( cpu_has_vmx_vpid ) { struct nestedvmx *nvmx = &vcpu_2_nvmx(v); - uint32_t new_vpid = get_vvmcs(v, VIRTUAL_PROCESSOR_ID); + uint32_t new_vpid = nvmx_vpid_enabled(v) ? + get_vvmcs(v, VIRTUAL_PROCESSOR_ID) : 0; - if ( nvmx->guest_vpid != new_vpid ) + /* Without VPID, every virtual VM entry invalidates linear mappings. */ + if ( !new_vpid || nvmx->guest_vpid != new_vpid ) { hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); nvmx->guest_vpid = new_vpid; @@ -2872,9 +2874,8 @@ void nvmx_set_cr_read_shadow(struct vcpu *v, unsigned int cr) void __init start_nested_vmx(struct hvm_function_table *hvm_function_table) { - /* TODO: Require hardware support before enabling nested virt */ hvm_function_table->caps.nested_virt = - hvm_function_table->caps.hap; + hvm_function_table->caps.hap && cpu_has_vmx_vpid; } /* diff --git a/xen/arch/x86/mm/hap/nested_ept.c b/xen/arch/x86/mm/hap/nested_ept.c index e116d8254824..abae483713d3 100644 --- a/xen/arch/x86/mm/hap/nested_ept.c +++ b/xen/arch/x86/mm/hap/nested_ept.c @@ -101,7 +101,7 @@ uint64_t nept_get_ept_vpid_cap(void) if ( !cpu_has_vmx_ept_exec_only_supported ) caps &= ~VMX_EPT_EXEC_ONLY_SUPPORTED; if ( cpu_has_vmx_vpid ) - caps |= NVPID_CAP_BITS; + caps |= (uint64_t)NVPID_CAP_BITS << 32; return caps; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 07:13:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 07:13:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464235.1674969 (Exim 4.92) (envelope-from ) id 1xMKKC-0008Ta-Gc; Thu, 29 Oct 2026 07:13:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464235.1674969; Thu, 29 Oct 2026 07:13: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 1xMKKC-0008TT-C2; Thu, 29 Oct 2026 07:13:24 +0000 Received: by outflank-mailman (input) for mailman id 1464235; Thu, 29 Oct 2026 07:13:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMKKB-0008TN-4i for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:13:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMKK9-00G5lM-NJ for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 08:13:21 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2f201-8faa-0a2a0a5109dd-0a2a45029b40-40 for ; Thu, 29 Oct 2026 08:13:21 +0100 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 6ae2f211-6ca4-0a2a45020019-d155802ccd6c-3 for ; Thu, 29 Oct 2026 08:13:21 +0100 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a20bdaf39cso19025145e9.1 for ; Thu, 29 Oct 2026 00:13: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-48e3ebc3932sm33957511f8f.18.2026.10.29.00.13.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 00:13: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=1793258001; x=1793862801; 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=kBA2wbAezOQ0h0cwG79l8WxR5+Zyx74ppDFGMr4jtsg=; b=O6mau2xZqF2wJaWFQsa5jVG4M5aTZSPF4My3LR7Je/tvQBBEr1Jn52zGnlENL/QD+v SHBan30HeIyj6fgFhrpkNWOVVCN1+5cLkC34Pza8szvG4VY4fnDKFxg6VJszEomQ4St0 +0vMPLltDnDiWV6lJc7PWcZDfQi38xUwur4MzcYiVbTdSOEYGpgJBSRW49puLhqj/h1j k/moN1vLC4jBDqFTaYS33Lx41VNcbx9Rrq1y3EZ1pIfhu1zkOAdLMYApRS7FZ49m3DcM visfcCwfJxUhUqqxCWqOVYtDMNEozKRcJrIarUNArDtHP7veL8n7z4wU4hE7Ti4gIv0p guug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793258001; x=1793862801; 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=kBA2wbAezOQ0h0cwG79l8WxR5+Zyx74ppDFGMr4jtsg=; b=FDoFTqxkc5DopkUCUbp05j9yIsKVwdkrPbnVErooHqyx+0WGCKA8IZ8IU/ADVArNYR mEEMXexGdBAP+e0BvIzNchpExdS/u6BIL8yOnELjx5zZgG0yOxHWh8CxhX3lVtZWld0h krTttHAd+PQ4omoyWJ50oX2ge7WKjTGmYcTx1KzNNffgMTN+uI4ROkZkRlGbrGSXKCwQ dWUQb0LBZtK9hFd9rmoUcypLWOs/gHxu0n6aBQscPi7wlQzd8UElUMOVzZot1mzWCovD a1vpfMBT95lJIK5+w3a2l6nxMYVU5VHKA/GRi5bmXUcnyvbfhHn2JPiXeXsTN94ze6t7 W8Gg== X-Forwarded-Encrypted: i=1; AKwUvByiOpiQiKdUa8YdEj4/dM7IQvcBY6bkGHi8JWwU3zJuiVyiilKLJxjEukoB2nh9l4mVV0a3Q/1YjQQ=@lists.xenproject.org X-Gm-Message-State: AFq9FYLNUp67zJNCopav3JniSQXBix3maHlzjvC5/wywtq+lHtBwS7Cr wRR2eq70fbq+IUX00nSGXDBf2Hz34lwlLVShLVxHPJ5L/U9drZu7Von9VTpDjzfj1g== X-Gm-Gg: AYBFou1HRqMp6VBX1XrVnFZpJ1PF77GJX0OIe1/6bO6VMizf219WC5jodtA4tIVEEAF 0aChQrCrDAKA3slNA3ZegQmmBo6jjOXdcfnAc1UPVrKB/5hwDoT/XDMroJKrSNgXapruzSQReEV bLzAo7mxwlTcrhvEWbF/XtkWGguGDJzY2XQTRtezb3I6nY0wAoruAUI3XzOwTVOJSYdZbfIVufn 8B2yfdZraAif4mdc5EogNisIa38uiCTvJRpC1M7Ci+Wb+VRw7K+85nGc/uUXJECg6P2WpA/tR/i NHx0otw2Xr0cHKrkLtLyRPD/f47lrL1bLhR8VQEn0eNsY7WCS3b18TrPXObXpkkHUrcY16vZamI ugq6ah017zqGAHwN464nDUnwX2KWB+bnIL/t5KIQMslnf5Sqq8ie+xGyIARa8+tSpF0IRORDUfG MYSfHYAzO7211wYy/SsEy4QNJlZBAH/uwevZqcjffs0yeNndxt+vzH7iJZXTT0hnrw8U0xofz6D LGC73oGVeAnoppRtARSIWAkAW0wyJurK0LANLUDAZNn8QwN0fcbWUXgK/M9nku34yrXPHqovpar ZpKvm7KvvoFF3xMOsA9KHX9EYAfFKcTOl8FGx5zjlL+n0DARJ57iP1k1YDM4ghITWppQaWDvJnD cczpQZGY7epxUgVjIzg== X-Received: by 2002:a05:600c:4e01:b0:4a2:190f:cf6a with SMTP id 5b1f17b1804b1-4a967ca03demr105721145e9.35.1793258000809; Thu, 29 Oct 2026 00:13:20 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 08:13:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/mm: Remove loops in get_order_from_{pages,bytes}() To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel References: <20261028124104.1564435-1-andrew.cooper3@citrix.com> <7128c617-9432-4571-9b7a-22d6f6e8d884@suse.com> <78279123-37d2-4acd-85b0-2bfe1fdf61d0@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: <78279123-37d2-4acd-85b0-2bfe1fdf61d0@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1793258001-F0EA32AC-5FA78554/10/78276251493 X-purgate-type: spam X-purgate-size: 1402 On 28.10.2026 19:07, Andrew Cooper wrote: > On 28/10/2026 2:15 pm, Jan Beulich wrote: >> On 28.10.2026 13:41, Andrew Cooper wrote: >>> --- a/xen/include/xen/mm.h >>> +++ b/xen/include/xen/mm.h >>> @@ -530,26 +530,16 @@ page_list_splice(struct page_list_head *list, struct page_list_head *head) >>> list_for_each_entry_safe_reverse(pos, tmp, head, list) >>> #endif >>> >>> -static inline unsigned int get_order_from_bytes(paddr_t size) >>> +static always_inline unsigned int get_order_from_bytes(paddr_t size) >>> { >>> - unsigned int order; >>> - >>> size = (size - 1) >> PAGE_SHIFT; >>> - for ( order = 0; size; order++ ) >>> - size >>= 1; >>> >>> - return order; >>> + return fls64(size); >>> } >> Along the lines of what you do below, perhaps simply >> >> return fls_g(PFN_DOWN(size - 1)); >> >> (and nothing else in the function body)? And then even >> >> return flsl(PFN_DOWN(size - 1)); >> >> (eliminating the immediate need for fls_g())? > > Neither of these are quite correct.  fls64() can't be downgraded to > flsl(), as it would truncate the input on 32bit builds of Xen. Only hypothetically: get_order_from_pages() taking an unsigned long is okay on 32-bit builds. In fact in principle get_order_from_bytes() could be implemented by calling get_order_from_pages() with a suitably adjusted argument. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 07:47:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 07:47:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464249.1674978 (Exim 4.92) (envelope-from ) id 1xMKrL-00062l-02; Thu, 29 Oct 2026 07:47:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464249.1674978; Thu, 29 Oct 2026 07:47: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 1xMKrK-00062T-T1; Thu, 29 Oct 2026 07:47:38 +0000 Received: by outflank-mailman (input) for mailman id 1464249; Thu, 29 Oct 2026 07:47:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMKrI-0005qd-Vz for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 07:47:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMKrI-004iMd-7D for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 08:47:36 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae2fa07-bab6-0a2a0a5309dd-0a2a450bba56-40 for ; Thu, 29 Oct 2026 08:47:35 +0100 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae2fa17-b7e8-0a2a450b0019-d1558033f1ff-3 for ; Thu, 29 Oct 2026 08:47:35 +0100 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4a140e7405dso18718455e9.3 for ; Thu, 29 Oct 2026 00:47: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-4aa7f7f4cdbsm52610815e9.7.2026.10.29.00.47.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 00:47: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=1793260055; x=1793864855; 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=8TbAAvEu/zKVmCKhVcl1XqJ60T2QI4v+kGuAA3utzWw=; b=B8q6iUKCcyT0HK8zMpQCkUkXEkX9MX8YxZ4hInhJ7yoeJoezBuTP7lSSZC/Oyvqnbf jGTs+oq6HEjqXFpb68vPBRQFLWajwqAroK7I35/5+qY24UD3TOsZXSGeP4nqU3aC6Fq/ z/dYYvrmDzgUJCovSPp82QEYaEekrHA7PbCz6sfdI0YRpnMb3K2AwAAtqQj0F2Q2yXkS JiVDAcPSrFy6/4LjZm69bMuFU2quOPMbJdgVWzT6ccOfKqC5hl8BST1djmcX2jHj/PQR 9azhmvlie04QP1Lkkjmc1qe6JQ7JozdBqUwuCUyGAOgvyCNT6+fq6v1nJbDA3hBulavj llyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793260055; x=1793864855; 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=8TbAAvEu/zKVmCKhVcl1XqJ60T2QI4v+kGuAA3utzWw=; b=ZBo9ZpMrt/a1+ud8wqfRFp97WwmUMRrEUWs4qHemjXBIAYARhF5ZreyAx+JS5sucIN oURUJqtDrmorbYNKx3T/Rr5PIEsoatQnjxpiU5POaBU1ytXiAcihTIb4VWNr9eZlaeB/ G3RX87RDTbqFubCSyr6X+cT+DewXXS3MqLuw+h8Uut83OuIaBg8lZxefKvXZDfNZ41ho +htMXp6qx+JdVN+Sn92MG/P6Jcvm27q3Ied2+1dGk2+x56wkv0s+Tg9gJ4gABMqgokLi YLE0IAlWdSBdVBQMJ3C3viNIq8pkldp1QN0P5nmJbrRxBsnhWhQz03F/oaYm/mhDIvko aKbw== X-Forwarded-Encrypted: i=1; AKwUvBxwHMQNTUQ2iTlmOBMF9EgcW5VkceM2D0trHJXWMZ5t9iro1vsHm7wQrV5haY2aVunkPT/qVkiRw8M=@lists.xenproject.org X-Gm-Message-State: AFq9FYL9pxQi93qhVObqCDt3OkDiQpX8Gnh7Et2d0oQyB4XtJKr0PI9a pWLGbgwhufOLbY/1wsww1gQ3REMbSCbeiHgrljw+3BoKd8NQ7tXFA1pUF0DnhkT2Zg== X-Gm-Gg: AYBFou0OVBFR9CWgiUTmxhZMrar3VNmMKTy4JQQEbzGUkl++dgtZ/lW8lmYrAdMGP9S AjLYORRy9SYueaVVRG1NXvir2lM49rwCHZXNNrjVAidmBND+w6S9wFt2+99YRRkeM0zSqrcv3QO c8SxfIVw4Ftir2OH6I85Lpv2mLJhCW45/Mf8WiMtNkw66dPGOjuGp2WPwxhpTt+sMWpebv0EF2B 0FCnINRw+eccGaXr8CltrOddKK/6dc3qfzC0KIv5aJ4F4u7ZwvZBwjYk8KVRE129NSt13xDQWfP OaIhLaW1WBJmx2GXjx+pYJNTGM1JEu/eagGdunwDjHl3MjW7n+lESicbUQ3rl4/yN5VfeOKTyuv 6JnOVLGGzlFSdLUEMEtx+SZiiOJDpgY1cLEnDhWF1OqyC5VOGc/MJY4BS7m484H7yifQubUwroB 0mh3eN630Ar4qOeYss5ki948dDbgQvIFIvxAglb0pRrVbsfJVQGlSzD6eBSlmmPg5WNC0BawGO0 FSIS8iSxCQfENIlSqTjoqskj/McQ1wd2PqcIX0rbT/vyte+h7ZwfupXaO5a5IUcVhPBUlACvcxj 1BLZX/LyW5ph9R/EbM9SHrk5ov0IYQuEK0dzjVj6zu1leEIaeR/m/Gq+DFYTOzAUo/K4VbYwAex uNXzecbgatpHXdxLY X-Received: by 2002:a05:600c:4f89:b0:4a2:1612:637a with SMTP id 5b1f17b1804b1-4a966c4110fmr105857615e9.16.1793260055020; Thu, 29 Oct 2026 00:47:35 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 08:47:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 02/45] x86/mm: refuse to promote an L4 while the domain has no per-domain L3 To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> <20261028-asi-hvm-v5-2-13b908e0df0b@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: <20261028-asi-hvm-v5-2-13b908e0df0b@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1793260055-AA6DA9EA-62F91209/10/78276251493 X-purgate-type: spam X-purgate-size: 1469 On 29.10.2026 00:05, George Dunlap wrote: > init_xen_l4_slots() puts the domain's per-domain L3 in slot 260 of the > L4s it fills. Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT > L3 slot at domain creation") a PV domain gets that L3 with its first > vCPU (pv_create_gdt_ldt_l1tab()). Only mapcache_domain_init() makes it > earlier, with the domain, and release builds skip that unless memory > hotplug is enabled or the host's memory reaches past the part of the > directmap PV guests can see. So in release builds on most hosts, an L4 > that is promoted before XEN_DOMCTL_max_vcpus has created the domain's > vCPUs gets a slot 260 entry made from a NULL page (0x803e900000000063), > pointing far beyond the host's memory. > > Have promote_l4_table() return -EINVAL while the domain has no > per-domain L3, before taking any reference. The other callers of > init_xen_l4_slots() all run once the L3 exists; have init_xen_l4_slots() > check that with a BUG_ON(). An ASSERT() would not do: the case above > arises only in release builds. libxl is unaffected: it creates the > vCPUs before it builds or restores a domain. Isn't setup_compat_l4() similarly affected? XEN_DOMCTL_set_address_size may (in principle) be issued ahead of the domain having any vCPU-s. Independent of that, how about pulling hvm_domain_initialise()'s create_perdomain_mapping() up into arch_domain_create() instead of the code additions you do? Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 08:59:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 08:59:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464289.1674987 (Exim 4.92) (envelope-from ) id 1xMLyZ-0001zz-BY; Thu, 29 Oct 2026 08:59:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464289.1674987; Thu, 29 Oct 2026 08: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 1xMLyZ-0001zr-7K; Thu, 29 Oct 2026 08:59:11 +0000 Received: by outflank-mailman (input) for mailman id 1464289; Thu, 29 Oct 2026 08:59:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMLyX-0001zl-Vt for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 08:59:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMLyX-009bTZ-5W for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 09:59:09 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae30ace-8faa-0a2a0a5109dd-0a2a450aeb24-44 for ; Thu, 29 Oct 2026 09:59:08 +0100 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae30adc-f2d2-0a2a450a0019-d1558031f0b3-3 for ; Thu, 29 Oct 2026 09:59:08 +0100 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4a35d5d4a20so20387815e9.2 for ; Thu, 29 Oct 2026 01:59: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-48e3ebc3a1csm33608215f8f.16.2026.10.29.01.59.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 01:59: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=1793264348; x=1793869148; 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=UZQtcNrTJaB+om9tfnseHVGXrK//mv/mnohM85AGg0c=; b=D1qNKqTA9ghUmjhoO3asXRKUpM3FIqT67fdhyA9z7BHQqvw+zHiH611lHHbSrszed8 5c/rTMsdLVtpkJMjeR3xn/d2AbrNYOhc+HH8DEmvh8oZNTKZUvccjnaijTq/0YiWJuhR kBpWh+Soyx7wyU3w2a6SVsKDIlUdzSjnmyY3T7V+ZkFWb7EsTM4FC+fjcy2o9/B1rKsP DVLt2xVSvZy6KZASLxVRMnXaIFZrUYn4kwCIBrIMH2UIg/TqrUhsp3WHKcm9a/IXv5s0 tXPUX0I0JUetSrLA2mKRyVNXurvAHLtdk0adEriNxjQb9fzX67GpyMRUtQaGxmD9ORGc IfiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793264348; x=1793869148; 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=UZQtcNrTJaB+om9tfnseHVGXrK//mv/mnohM85AGg0c=; b=OZD7xczcts+Wd0dI4AFvv6VuacHalScr0X6w2sHPbBU/WxVRc/VOrypXb0EL6LJGKT gtDhtthaD7JAPzZUKSabonsipWVSz+br5Q56RNHLi+LtU8xbdcvysW3EvFKcP5JThzNb SepmpLXshP1qu+hnXSb9mN/xb0F6BYnbpjGy0Wb4dm0NQlx1ky18gByBry3hwmwCXTnf s1o03OKYn56qooYi8yN6K9f25kQkv7YqJOKuEOOvGlFTxIU6/NqNlZtcKYjtTEBI5W4D HuHeDfywEhHZjS8eQRT0/FDR60RX9Zwvi5o0H1BuiQoKhNMgKx0kXjEtwDqyNl4+36XT zv9Q== X-Forwarded-Encrypted: i=1; AKwUvBxLSsnJc1tvKUyYBSAPMA8zvThj2LuS4dhmsZQq510Tm2nPyEilp2sPtq0yrc3YwOJSNlk1zziT/WM=@lists.xenproject.org X-Gm-Message-State: AFq9FYIHPM/JL7NKDsqF8uZ4B8IaakeVi6GukHZlFPHsf4SuK5RUkHrT v1vHk10tGoRUJpgXzUsizJhd9tsye3QbiekPBmFkhGvTo+IBRpzwe4dH0xjQBd5GEw== X-Gm-Gg: AYBFou3Sg73vJ9OTBIvWUDBnA/u0y5UCb+AGSHvoUb7VRpkpezXvyVOH+o7Xb+GTzx1 hpoYJiswgGhEFaAsEpBHV9Ot7j7yd4tsch7NyvWYcUIDmSPxMeu9F/DNUGW+K7Ea7eGW0pqaXN3 cPRs5oqKGOxdfGn3MocZ8AlygcAukGToEYdYN3EtpCMMj7o68ftYqlBqWqo08Jp9I/1KDKlVyMa azLdeo0zTPpkN4f2Wk3WpzTj8hhP3W2Y4mrXBrK/w62PHaPELCX87xkiy1/QL8ZQNPevfT7pHIc 8lHRhNgVlkAXjTJxJTFFPEcQvU3bAhk5IyB3qubY1UqbP67fi4/Kfz2rBzHPKSb9jTVoBxIO/90 Y+Pw3PbJ93sgLCD2FSF6MNX1y+AKEdSQvyjmvvwmRgCxEUhZV0WGRN/uMVjdGs1xUbvaHiTP2nM 1NAblbwcpDEds40JGL0LIipRE3Ch04BD7VnhGdrfZEZunZKyp+PVdFfUYATzOpuyATVBO1twpNR iVNsBJqOWhQDntuSK84jz1Q4kO2C+F8OkpGUY4d0rXhKm2AOsLhABJdLT+eJchUTBMFsW/mVXKc GZrLYjlvlDzkjQogXxWK9ywKGCbC6v9/Tb7LRGm525J14Qv/t779aCd2B3mj/yAO1NtuHm4cwSg fAg3oJ+C46hbEg3KNYQ== X-Received: by 2002:a05:600c:83c5:b0:4a8:c6a0:c08f with SMTP id 5b1f17b1804b1-4a967e8c05emr121912425e9.35.1793264348353; Thu, 29 Oct 2026 01:59:08 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 09:59:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] misra: merge the two R14.3 invariant-condition deviations To: "Chen, Shuaidong" Cc: Nicola Vetrini , Michal Orzel , Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Doug Goldstein , Grygorii Strashko , Penny Zheng , Ray Huang , xen-devel@lists.xenproject.org, Alejandro Vallejo , Stefano Stabellini References: <20261026030309.2507461-1-shuaidong.chen@amd.com> <67e298cd-3b84-4476-9dd3-607e505effe6@suse.com> <321e7082-5cd2-4a41-9c49-ff091d9ceade@amd.com> <67f91d71-5692-4c07-a834-f282daaebd5a@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: <67f91d71-5692-4c07-a834-f282daaebd5a@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1793264348-595C3CFC-1EAFE6A8/10/78276251493 X-purgate-type: spam X-purgate-size: 6950 On 29.10.2026 06:30, Chen, Shuaidong wrote: > > On 10/27/2026 5:14 PM, Alejandro Vallejo wrote: >> On Tue Oct 27, 2026 at 9:18 AM CET, Chen, Shuaidong wrote: >>> On 10/26/2026 9:14 PM, Jan Beulich wrote: >>>> On 26.10.2026 04:03, Shuaidong Chen wrote: >>>>> MC3A2.R14.3 ("Controlling expressions shall not be invariant") is >>>>> deviated by two separate entries. One covers 'if' statements and >>>>> conditional operators and places no restriction on where the invariant >>>>> condition comes from. The other covers 'switch' statements, but only >>>>> when the controlling expression is a 'sizeof' operator. >>>>> >>>>> The rationale recorded for the two is the same: the condition is >>>>> deliberate. Nothing about a 'switch' makes an invariant condition less >>>>> deliberate than the same condition in an 'if', so the 'sizeof' >>>>> restriction reads as an artefact of that entry having been added for >>>>> read_atomic() and friends in arch/x86/include/asm/atomic.h rather than >>>>> as a considered limit. >>>> Well, >>>> >>>> if ( 1 ) >>>> >>>> can make sense, especially when 1 is the expansion of e.g. IS_ENABLED(). >>>> Otoh >>>> >>>> switch ( 1 ) >>>> >>>> doesn't make a lot of sense, even when it's as a result of the expanding >>>> IS_ENABLED(). I agree that limiting to just sizeof() is unnecessarily >>>> strict; alignof(), for example, should about always be usable where >>>> sizeof() is. Yet making if() and switch() equal is imo going too far. I >>>> realize though that it may be difficult to find a suitable boundary. >>>> Stefano - do you possibly still have notes from the discussions long ago? >>>> >>>>> Fold switch_stmt into the general entry and drop the 'sizeof'-restricted >>>>> one, which the general predicate now subsumes. Invariant 'switch' >>>>> conditions that are not a 'sizeof' become deliberate as a result; that >>>>> is the intent. >>>>> >>>>> Signed-off-by: Shuaidong Chen >>>> What you don't say at all: Does this help with any remaining violations? >>>> >>>> Jan >>> Yes, and let me give the full context, since the motivation comes from >>> downstream safety work rather than from the upstream analysis. >>> >>> On safety branch one of the techniques we rely on there is to pin build-time >>> configuration to compile-time constants, so that the code which the >>> intended configuration can never reach is removed by the compiler >>> rather than merely left untested.  That matters for us in two ways: >>> code eliminated at compile time does not enter the coverage >>> denominator, and - more importantly - it is not in the binary at all, >>> so it does not have to be carried through the whole qualification >>> chain. >>> >>> Two examples: >>> >>> https://gitlab.com/amd-xen-safety/xen/-/commit/160dac43f554733a68d83c38cc1d0e73b3b7bff0 >>> https://gitlab.com/amd-xen-safety/xen/-/commit/e0eccfa7184b7acee23916cd5cb2a3b5afa101f2 >>> >>> A side effect of this is that some of those constants end up as the >>> controlling expression of an switch statement, which then >>> trips R14.3. >>> >>> > Otoh switch ( 1 ) doesn't make a lot of sense >>> >>> Agreed in the abstract, and I would push back on anyone writing that >>> by hand.  But that is not what happens here.  The sources still read >>> >>>   switch ( gt->gt_version ) >>>   switch ( opt_bootscrub ) >>> >>> exactly as upstream wrote them, against what upstream intends as a >>> runtime-variable value.  The constant only appears after a build >>> configuration specialises that value.  So the construct is not a >>> pointless switch on a literal; it is ordinary upstream code that a >>> particular configuration has made invariant - which is precisely the >>> situation the existing 'deliberate' deviation for if statements and >>> >>> conditional operators already covers. >>> >>> Of course the other alternative: rewrite those switches as >>> if/else chains, which the existing deviation would already cover it, and >>> the violations gone. Technically that works. >>> >>> The reason I would rather not is that it is churn in common code for no >>> functional >>> reason, carried indefinitely as a delta against upstream, and it makes >>> every subsequent rebase of the safety branch more expensive. >>> >>> Having seen that a deviation for switch already exists - restricted to >>> sizeof - extending it to switch in general seemed the smaller and more >>> honest change: it states that an invariant switch condition is >>> deliberate, just as the project already states for if and for the >>> conditional operators. >>> >>> -Shuaidong >> To build further on this. add_sized() is one such case (already covered >> by the disappearing exception. There are existing cases in the upstream >> tree where this is or will be the case, but due to their being inside >> macros become invisible to Eclair. >> >> Or my (still not resent) cpu_vendor() series, I rely on placing >> X86_VENDOR_X constants as invariant expressions in switch statements. >> Even if nothing does it today, MISRA would be prohibiting constification >> of any global that happens to go in a switch for no particular benefit. >> >> IOW: This isn't about hardcoded values, it's about IS_ENABLED() gating >> and DCE. >> >> On the specifics of the patch, it's not exclusive to switches. I'd much >> rather see it extended to for loops as well. >> >> for ( unsigned int i = 0; i < NR_MAX_FOOS; i++ ) >> ... >> >> Where having NR_MAX_FOOS be zero is effectively a guard on the whole >> loop. Today we need explicit early IS_ENABLED()-gated exits to keep >> Eclair happy on some such statements, and that's just strictly worse. >> >> Shuaidong had to recently fix these violations in our tree because the >> spirit of the existing exception is needlessly exclusive to "if" >> statements. >> >> Cheers, >> Alejandro > > Yes, as Alejandro described, some DCE techniques have been adopted in > safety to meet the coverage requirements for safety certification. > However, this inevitably introduces code or macro patterns that can > trigger violations of this rule in some cases. > > The current deviation for this rule is unnecessarily narrow. If > extending it too broadly would have an excessive impact, we could also > expand it incrementally to cover specific cases as they arise. > > For example, this patch could initially extend the deviation to switch > statements only. That would already be a reasonable improvement over the > current situation, where only if statements are covered. That is what the proposed patch does, isn't it? Personally I keep thinking that this is what is going too far. Extending to while() and maybe for(), otoh, would be okay with me, I think. Albeit infinite loops and do/while already have "built-in" exceptions. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 09:56:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 09:56:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464335.1675032 (Exim 4.92) (envelope-from ) id 1xMMrV-00045k-LF; Thu, 29 Oct 2026 09:55:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464335.1675032; Thu, 29 Oct 2026 09: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 1xMMrV-00045c-Gv; Thu, 29 Oct 2026 09:55:57 +0000 Received: by outflank-mailman (input) for mailman id 1464335; Thu, 29 Oct 2026 09:55:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMMrT-00045O-Js for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 09:55:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMMrT-00DqTC-06 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:55:55 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3180e-8faa-0a2a0a5109dd-0a2a4508b5c0-36 for ; Thu, 29 Oct 2026 10:55:54 +0100 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae3182a-f659-0a2a45080019-d1558036a54d-3 for ; Thu, 29 Oct 2026 10:55:54 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a9a8d6cea8so6953085e9.1 for ; Thu, 29 Oct 2026 02:55: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-4a94f05e4e4sm74207055e9.3.2026.10.29.02.55.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 02: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=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=1793267754; x=1793872554; 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=Y62QYoQ69kHGf0I6xAb8FiX+7PjW3kdG4Y6EN9Ch4iE=; b=DTx7ptZp+prfERvDqiFz2H9GiGjPCd1kehjHxRUedfuDRYR4dWHpNZkP5WBDMyjYp1 eedGivEblZnztyQySxsNBo+/aKTYe3Q273n+BgQD6EYGhrrvA06xSoeqwQ0FL6Nb3N5Q P6rZ9W/X8haPFW6I3czuew/tDAPjJVeOQ/kvxbrRHce8BX7J7y682aEbQuD+bN4G18FB McuicBCoDCu6WjeRldtE1MkLJcKD8Ugh7dSog3nqWq7vrBO7KfTRezQeGMej5QOiCPdf SDx+1oQtnl+NZcoTwHc5MYCc02JN32RSLzlzu/0fxFDj2gaHPmM+FYqRQZMddnzm+9N7 HAoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793267754; x=1793872554; 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=Y62QYoQ69kHGf0I6xAb8FiX+7PjW3kdG4Y6EN9Ch4iE=; b=wq1ovWCqeVoK6E7e90AQJj6pOWJL7fwdFsuZwugzgZl9CLtHPmLxq/Y7QkFr+SWG3q YfGE7+Jh3tIhF0w+xucl9zTuG/PI8FD4JIW+Z1pU+o+woI8XisXCcypkg9JAhvovKgye ZX6PkFKIOiHkPfrkuGyq7mULumA2RS93L/oZ/7OyUyc24schAHxpNY+HMNKW+GvS9r/s JwOS4g9xFlylknxxy0+EiCrnL3k9hLpuoEdX1VilL9wZtIA3ZZQzQMO/xG3ysjyS6zaU OmzQDNUiDt9JoGUPZin7//VtyPUQDoNX3l61nxdoHfVdndtVmjnFtViRbYLwRgiBcPe8 j2qQ== X-Forwarded-Encrypted: i=1; AKwUvByNQKYqMZ0b4OReTWFX3q3KLvilM/Nv29fmHEfOOBxB6W1E5RVEVQwz0c4e8kiJ60/wP4/JlUau1f8=@lists.xenproject.org X-Gm-Message-State: AFq9FYJXh2VcAdkWz8TtqBidhDHjFJlE9/PBJW7tF3rV9/Rx2t5HISMX yfUmUI1nuFS0WznHZcvVwiUMlb2YbeQDrcGdmX0vRmRphWYZW+H/0YP3nMFmEODf6A== X-Gm-Gg: AYBFou3Kbk8LhfqwVfGKPo0v4GMh96sYmKEjF4pXhVmspWxYUn7ShSaJ8etiDjDOFqT //OIFJwgI7ELDfpzgvQzP52aO3sD35M4hGwZU16OC0ZjhJYPBFlLMiYA5I1CtcUIT/d9IfVEpGf aK62htxVH7t8DHMqhVl8GdSLz2luQ/EEaVYFGzm6yr0yD7udSWhw6nvwu82l22DIU2cFqKh+e2U Uu+3ZLl6s3YioLKUZILvnN932/+5Ju7zp8+UO0e+Yld/XfU1+PFeEVmVPgkiH5XPETDrPgCkdYf SEBKTHga47S98Y678f44H6n9EI38wo92GhuR0Q5yFbGA9cKHXQTo6m9lcPPrYeaqT/ntxIRmd0T nbOmCdUqgg/760g5CHciFLS84tbPTiaiRIpSuwbXFGCuzIWe80wRLrrRQkrjoBWyq+09kQwYPAE yX42iWTk3lMOoXdBmtHD5IeoErxhnOpvyzggBvAkYRpsKLZ2XV3IlQREwT3VKyZ+73Kz/nAJAR0 72BmOPO5NLgzwm2w16VS1fbos3enFzhxQkVqty4OZiQ3yYijk/YPdYd53Refo41jhZh/ZbiRBkL W2tHvNm8zFFWt3+BEvDJ0gXkCNRTKw/KbkTRrppSG+sXNBdXDGcPmS4PFrsHdjf2OjYMo9ZM9Wf zRt69/ThYERz4NjUHTJl2CPHEZXMYc107nW6YNiU= X-Received: by 2002:a05:600c:621a:b0:4a2:10f9:37db with SMTP id 5b1f17b1804b1-4aa871e8be0mr50764985e9.7.1793267753583; Thu, 29 Oct 2026 02:55:53 -0700 (PDT) Message-ID: <1f83eca2-09c5-470e-8326-5ec6604c6e6f@suse.com> Date: Thu, 29 Oct 2026 10:55:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gnttab: drop bogus check from _cache_flush() From: Jan Beulich To: Andrew Cooper Cc: Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <6d0acc68-9d07-4e0a-b27b-0095a51ebe42@suse.com> <8d4f9d39-f80b-43cf-91a1-033a8bca777f@citrix.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: 8bit X-purgate-ID: tlsNG-c1860d/1793267754-D614687B-9818EB44/10/78276251493 X-purgate-type: spam X-purgate-size: 1656 On 15.10.2026 09:11, Jan Beulich wrote: > On 14.10.2026 18:24, Andrew Cooper wrote: >> On 14/10/2026 1:52 pm, Jan Beulich wrote: >>> There's no such thing as an alive domain without ->grant_table, and system >>> domains (on Arm) don't own any pages. The check should also not be left >>> there "just in case", because if that check could legitimately yield >>> "false", the page reference obtained would then need dropping on the >>> subsequent error path (see XSA-520). >>> >>> Reported-by: Andrew Cooper >>> Reported-by: Yehyeong Lee >>> Signed-off-by: Jan Beulich >>> >>> --- a/xen/common/grant_table.c >>> +++ b/xen/common/grant_table.c >>> @@ -3637,7 +3637,7 @@ static int _cache_flush(gnttab_cache_flu >>> >>> page = mfn_to_page(mfn); >>> owner = page_get_owner_and_reference(page); >>> - if ( !owner || !owner->grant_table ) >>> + if ( !owner ) >>> { >>> rcu_unlock_domain(d); >>> return -EPERM; >> >> Do you remember that I already posted this patch (to the security team), >> and you already reviewed it? > > I do. That was after I had made this patch, though. > >> I'm afraid that your commit message is hard to follow, despite knowing >> the details.  I already have one prepared from 3 weeks ago which I think >> is rather clearer to follow. > > I'm happy for you to post (and commit) yours. I just didn't want this to > fall between the cracks. Are you going to post your patch then, for me to ack? Or are you willing to ack mine? We should make progress here, whichever way. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 09:57:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 09:57:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464340.1675040 (Exim 4.92) (envelope-from ) id 1xMMsx-0004bB-Sx; Thu, 29 Oct 2026 09:57:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464340.1675040; Thu, 29 Oct 2026 09:57: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 1xMMsx-0004b4-QK; Thu, 29 Oct 2026 09:57:27 +0000 Received: by outflank-mailman (input) for mailman id 1464340; Thu, 29 Oct 2026 09:57:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMMsx-0004aw-3P for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 09:57:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMMsw-005rnd-5H for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:57:26 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae31881-2eae-0a2a0a5409dd-0a2a4507d8d4-14 for ; Thu, 29 Oct 2026 10:57:26 +0100 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 6ae31885-b4ea-0a2a45070019-d1558035ccc6-3 for ; Thu, 29 Oct 2026 10:57:25 +0100 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4a1fbd52ab6so15079235e9.0 for ; Thu, 29 Oct 2026 02:57: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 5b1f17b1804b1-4aa7ee575e2sm54854155e9.1.2026.10.29.02.57.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 02: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=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=1793267845; x=1793872645; 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=XClxOWhUsvUCRR49fE1bGi/6cJOaK8D4/W3rnCLSA7E=; b=J7dGPYk50Rk4CpDPtU5y9skIXMD5aewD6G0E9fE0XF5/mGeqEq96BXNGyCL6y7WuM2 A/qEx4X5im7s+k6DUUt+213lFjPeSANiYY3+nJlidjEds9C3d0oav+wa7wAFyHUCWHdt rRr+PSIpXQYjwSQP+i2XvE3psPlU8Ssk4EPSUtliSiNUHPilYHVxmhL0eEEQb5ZNoKsY bUtNXNTQFqUuCmdcfOvo08nSqU+egy6HHvvBrOIZRZx8RFIWmfGhrsyS/7MuMTBAiqfD BlFkftH0xp64K4gxqSTatRE/KJZfw11lXZ6+GzdgnGzuMuSvT9xNmSMJ9NXSYb8kpaI0 DCOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793267845; x=1793872645; 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=XClxOWhUsvUCRR49fE1bGi/6cJOaK8D4/W3rnCLSA7E=; b=R+tqF/YxdUJwjNVZ6/TybWV7e66OWkgUtb7uzKqxKksJKaKGGF3M6mgpHi0JPqx68b 1h/9TQ5s9DLFamwiI2yTr1e9NoFuBvVqbv1idFMDiwkmAn15F9+lsW82rpF7ttjPJbWW uErpWpPRjbLGKsSsQ7ZbH52BqPGokyrAKROSifi6TxSpt4nrv6mzmRu9hB0TRhiAHxM3 WBAAp2DDcpR1yFqT3K2rowY64/mHs6S1ItxUoSlvV+V7BtaKaf6zobp0bm2aEWcI91IF ZFqbfHD8VI9W+cZarmKXVf0GV/9j7Mxx7PNQTmN/2r0D27IkH1gv+cZAFBHgwVb5EA2X daqw== X-Forwarded-Encrypted: i=1; AKwUvBz47J/XGjeVjw8QtnnEUc/St2UdezrdD3w/AtLGYj7lqNHoXD3BWmyVeBW5/p3VBdr2NdS4SvRC4lY=@lists.xenproject.org X-Gm-Message-State: AFq9FYIyDrKmzNaEMUolHqU3amn+QwvsGDSral8L9uObSGaKjU+gvlDG GRT4G/X0OWIlRgmNcQAT7d2PeSHQPmpsIuC91Sow8k+ktkRbV4c8FbP4OckEdHKE0g== X-Gm-Gg: AYBFou1LZwn59kzXTnAAoPVlZRqLy2pdHAEYZJQtbS88U1CX8Q9DTccZmpLtbXuaUpk N12+QtKkNVSb/Q3gkhzVGA88EEZA+zYZEZXuCPw9c8H88RL8c04cj86TtaKh4F+7XNMph73oXpz pSTJSN1r6y0H7hJKquoniMr7JoqXCxMiaWvbv7hzcadLxcnmBghz99S00JRRm4GYOjM2dQfBSFC j5osr5hFnszqpGWLRZZ2ieji+Ry1GLALHGYuZXcbT4s13L7I1v3XfPI9wmqQCpvGGVgpEUKV8Qf +B6PcO0k5n22e0ZZ1EefamfdEM0TrENGV1Vp/CGUjzJGnaEQlIgO7YU7ssUI88DtxT8757F4gRe ISU3YoevMetJVZf05dDAv8dlaRmvVp01htJz5WHigdJN1VmzLzo7kX72uwTg46urCc5uCGbEyhd Q/+iUqketd6cPKxYESdMrHNatFE3RaTUGxWOHPIULngPY77fFnZ5SGSZb2bBfC9wrxD6mjpVwCl ASPw1qdxZSHewUAJKzrSXs4GAFLoOE0mWNvuuIXtBvMSaZgZJfHkAsYmHuAzr566aWiu1yFuuog sUEM4G5JEtQSdBGR+hpXSj8HQpZVtDWgcLbdbLVcc8yitX1H9Z9OtkBK0Hgzh3/ozXEMpOEOl4G QtceGhfxvZf5PdU30 X-Received: by 2002:a05:600c:1143:b0:4a1:da58:1ee with SMTP id 5b1f17b1804b1-4a967ab1949mr76494215e9.31.1793267845313; Thu, 29 Oct 2026 02:57:25 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 10:57:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Ping: [PATCH] x86: invoke xenheap_max_mfn() unconditionally From: Jan Beulich To: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Teddy Astie , George Dunlap , "xen-devel@lists.xenproject.org" 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-ef75cf/1793267845-A7CD7AE4-C020393E/10/78276251493 X-purgate-type: spam X-purgate-size: 2065 On 12.10.2026 13:11, Jan Beulich wrote: > Calling the function only conditionally can, when highmem_start isn't set > and when hotplugged memory appears above the boundary where the "short" > directmap ends, result in Xenheap allocations to yield memory which isn't > accessible through the "short" directmap. Accesses from PV guest context > would then either fault or access guest controlled memory. > > With this the bifurcation done by 88e3ed61642b ("x86/NUMA: make > init_node_heap() respect Xen heap limit") can also be undone: > end_boot_allocator() can be called from a single place, and system_state > is bumped right afterwards. > > Fixes: adc5afbf1c70 ("x86: support up to 16Tb") > Assisted-by: Claude Opus 5.5 > Reported-by: George Dunlap > Signed-off-by: Jan Beulich This being a bugfix, can we please work towards getting it in? Thanks, Jan > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1908,16 +1908,17 @@ if(j == 1/*bm->kind == BOOTMOD_RAMDISK*/ > > numa_initmem_init(0, raw_max_page); > > + if ( !highmem_start ) > + xenheap_max_mfn(virt_to_mfn(HYPERVISOR_VIRT_END - 1)); > + > + end_boot_allocator(); > + system_state = SYS_STATE_boot; > + > if ( max_page - 1 > virt_to_mfn(HYPERVISOR_VIRT_END - 1) ) > { > unsigned long lo = virt_to_mfn(HYPERVISOR_VIRT_END - 1); > uint64_t mask = PAGE_SIZE - 1; > > - if ( !highmem_start ) > - xenheap_max_mfn(lo); > - > - end_boot_allocator(); > - > /* Pass the remaining memory in (lo, max_page) to the allocator. */ > for ( i = 0; i < boot_e820.nr_map; i++ ) > { > @@ -1936,10 +1937,6 @@ if(j == 1/*bm->kind == BOOTMOD_RAMDISK*/ > init_domheap_pages(s, e); > } > } > - else > - end_boot_allocator(); > - > - system_state = SYS_STATE_boot; > > bsp_stack = cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ > if ( !bsp_stack ) From xen-devel-bounces@lists.xenproject.org Thu Oct 29 10:08:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 10:08:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464358.1675050 (Exim 4.92) (envelope-from ) id 1xMN3E-0006sW-Pk; Thu, 29 Oct 2026 10:08:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464358.1675050; Thu, 29 Oct 2026 10:08: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 1xMN3E-0006sP-N0; Thu, 29 Oct 2026 10:08:04 +0000 Received: by outflank-mailman (input) for mailman id 1464358; Thu, 29 Oct 2026 10:08:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMN3D-0006sJ-ON for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:08:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMN3D-00000002PB4-2FGS; Thu, 29 Oct 2026 10:08:03 +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.98.2) (envelope-from ) id 1xMN3C-000000012kX-46yx; Thu, 29 Oct 2026 10:08: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" 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=JWt7RjLtDFAj1Twt2mVWYcZJUcmbBZY2oIoGpwJlSWc=; b=z06qXT2uuI8qN98a0dJqjk9a37 fHnz6Vv5OF34HmZlS2JhkXrG+VumPJetdYbm2W5pN7IvJOc0+9ed3NMHbnlaQIJq04EkBcV9FKjUL a/6lyovM6vq6qlmR24S1AjvYLxJgiNBMPJSN8HEn2eEBi0lyeSrHtHKoxMFfm/VinLqg=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH] x86/irq: further gate PIRQ usage for HVM domains Date: Thu, 29 Oct 2026 11:07:41 +0100 Message-ID: <20261029100741.42711-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 Further restrict PIRQ usage for HVM domains not having the ability to route device interrupts over event channels. It's still possible for HVM domains without PIRQ support to exercise the vector == 0 path in hvm_inject_msi(), which is intended to be used only when the guest has PIRQ support. Taking the PIRQ path in hvm_inject_msi() inhibits the local APIC from raising an ESR error when the MSI vector is 0, since an MSI with vector == 0 is always processed as a PIRQ. Introduce a has_pirq() check in hvm_inject_msi(). EVTCHNOP_bind_pirq is also not outright blocked for HVM domains without PIRQ support, so guests could attempt to bind device interrupts to event channels. Short-circuit evtchn_bind_pirq() early if the domain has no PIRQ support. Additionally introduce an assert in map_domain_emuirq_pirq() to ensure it's never called from HVM domains without PIRQ support. Finally add an extra check in hvm_domain_use_pirq() so it returns false unconditionally if the domain has no PIRQ support. Also convert the is_hvm_domain() check into an ASSERT(); this helper is never called against a PV domain. Fixes: b96b50004804 ("x86: remove XENFEAT_hvm_pirqs for PVHv2 guests") Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/irq.c | 5 +++-- xen/arch/x86/irq.c | 2 ++ xen/common/event_channel.c | 3 +++ 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index 5f643611130f..50a43143149b 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -19,7 +19,8 @@ bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq) { - return is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND; + ASSERT(is_hvm_domain(d)); + return has_pirq(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND; } /* Must be called with hvm_domain->irq_lock hold */ @@ -382,7 +383,7 @@ int hvm_inject_msi(struct domain *d, uint64_t addr, uint32_t data) >> MSI_DATA_TRIGGER_SHIFT; uint8_t vector = data & MSI_DATA_VECTOR_MASK; - if ( !vector ) + if ( has_pirq(d) && !vector ) { unsigned int pirq = ((addr >> 32) & 0xffffff00U) | dest; diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c index c58d2eb9227c..32a75f77a46d 100644 --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2814,6 +2814,8 @@ int map_domain_emuirq_pirq(struct domain *d, int pirq, int emuirq) if ( !is_hvm_domain(d) ) return -EINVAL; + ASSERT(has_pirq(d)); + if ( pirq < 0 || pirq >= d->nr_pirqs || emuirq == IRQ_UNBOUND || emuirq >= (int) nr_irqs ) { diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index bd03e094d096..97104bea15fc 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -681,6 +681,9 @@ static int evtchn_bind_pirq(evtchn_bind_pirq_t *bind) int port = 0, rc; unsigned int pirq = bind->pirq; + if ( is_hvm_domain(d) && !has_pirq(d) ) + return -EOPNOTSUPP; + if ( pirq >= d->nr_pirqs ) return -EINVAL; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 10:42:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 10:42:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464388.1675058 (Exim 4.92) (envelope-from ) id 1xMNaN-0005Qg-9D; Thu, 29 Oct 2026 10:42:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464388.1675058; Thu, 29 Oct 2026 10:42: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 1xMNaN-0005QZ-6V; Thu, 29 Oct 2026 10:42:19 +0000 Received: by outflank-mailman (input) for mailman id 1464388; Thu, 29 Oct 2026 10:42:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMNaM-0005QT-Df for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:42:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMNaL-0095oZ-Qm for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:42:17 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae32309-e002-0a2a0a5209dd-0a2a450cb26c-0 for ; Thu, 29 Oct 2026 11:42:17 +0100 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae32309-f479-0a2a450c0019-d1558032ec58-3 for ; Thu, 29 Oct 2026 11:42:17 +0100 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a2d6d01ecbso13620345e9.0 for ; Thu, 29 Oct 2026 03:42:17 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a966a56abesm76404935e9.0.2026.10.29.03.42.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 03:42: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=20260707 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=20260707; t=1793270537; x=1793875337; 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=qysdC2k7d0sG9F2jerQoG3RmIk40HztTJ82JvP3wOZA=; b=HgepfgtufAJ1qXt+b+WESiS1sT8vBGXOygD1ix5NpsQ3kYqYt9mRokierQfP+JTErW WYCA7PrltB7fwqDczW5yUPFR9jtXm5DOznOVqL+zqRh6LRsTO7QbPmRN5uBsvqTVdPMb LOi5xrHeEkT4lY9IWBf+JvwzAPB18LoopEC83/dBzSmwdnqWupRA8U20UWpEFmBI/WNv mildOTarqnkWFVL4JK7X1lw5kgj8z5dnpbbQRINPZQ6vU+yDSGWVXjLArC3UuGglvy67 Qiw/rvwPwPSBuJe8pnJsMj1YeiQX7AoB89+ZPMsNmD7iCS/YQf+Zu4rbDddH1zo3Lw5a Ykuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793270537; x=1793875337; 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=qysdC2k7d0sG9F2jerQoG3RmIk40HztTJ82JvP3wOZA=; b=spPu/gcEMUvE5UdPSIAu56MkVzNnAbM+iWCubXHUmqtdCdiJX1Uwfd8P1X1Qa+Q6jA tCl6cQNOg0+80p/If3/WPIpAQSz6oNGPDWZ1ynEzOfUcdFKuWa6XIQFlNnLmzuYtAZ1X vyr6y2kpgu9WoWWBCOGkiy+S6S501pT7jATjO3WPaPmPQMd+uw6XO0l/C78cOR5NlUzG 9++JX+UEeh0ZuY0avcxbiat8ddymLXMd/spmvmHVqbtyq4n7KTV1b2Ujq4DRBfpeJJPF AAWbm3B0YMumci2ygnMBYmayS5u8aa4o2JBX4b9qOwFiv1KKirEsvDoMFV7IqGezHqnf BYmg== X-Gm-Message-State: AFq9FYLQ4ncpvy0iAGeBkDBP1jF5l+N/tLycPrxUp7AaJVV+ItL5UUCA cMtRVGFM+rfcsmb5eLRJjU3l+vIn3K+pXSc0gK/wE65q5agC1wJpDsUu X-Gm-Gg: AYBFou1xbznpzWoEdl9ikiHZu/5cEsq6b5sG7a0N6k8YjaKKdhmSVm4NBGLdOKzVh6g WJoHDRC1+f5QJU5t1jh9aE7DP2xip5lxqiK9Qz1l9+j/qqOVpi48rNERwCPy5GlC7/BkpafG1pL r/M9HTfDSNaCB1pnavrKw7NNbBy5VOsqCnFK2V2w9ObMhBdMxI8QtkIiYeI9xgt/INGZ3C+fU9g fs03Qse5X3g7m1HrKczviPH5yMYyoymph8sAJpiiVTH3zs7UoAP/2j9qeIL8oczkDKuHwLxygrA I475yPw91EkbBPV+tmsb+U5hnmpOTIjJCpUTe7U0joLag2Fd4ZcfUZ1Jp/NE15l/vKSQccntCo/ GG+C0pVYJDwnAKBr8k35ZcjW5WyxrhHatNYouGOTrrvAv2lHHHyDP6GlAIFbz4NVHpKDa3yQidD hUk6krDl0kx+LazRDb6NWdI6vKt0wSR4ndnp22OJxfHg70DeIkuCxxAu3T7gpJB9oJcQk9S9/T0 Z03hrZUxIkWxAGzl4R2qHoN0lAlW8qXPU1xXlmWvGDu1d7WJj+dmxBRtBSXSfzFNQXaAyLL/tLx uhtzb9vPeAHKOb/BZUc+YXFQtRRBkF24Mr6gOr0GbhbbxD1rLzUAf+gMRehKuhncW4EXpPxOrIJ kP9s= X-Received: by 2002:a05:600c:8b28:b0:4a5:75d2:c104 with SMTP id 5b1f17b1804b1-4a96720304cmr116968855e9.22.1793270536964; Thu, 29 Oct 2026 03:42:16 -0700 (PDT) Message-ID: <83fd251c-4a1e-4057-8990-0f8a2f3d38b5@gmail.com> Date: Thu, 29 Oct 2026 11:42:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither To: Baptiste Le Duc , Andrew Cooper Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Zheng Zhang References: <1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech> <1793192757.8631fc262581453bbf619ec5b2062170.1a1829e0a63000f79f@vates.tech> <35fa29d5-fafc-43da-a5a5-72df8f367e3c@citrix.com> <1793208322.8631fc262581453bbf619ec5b2062170.1a1838b89ef000f79f@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1793208322.8631fc262581453bbf619ec5b2062170.1a1838b89ef000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1793270537-50D3CA5B-FD9A1B00/10/73395122804 X-purgate-type: spam X-purgate-size: 2920 On 10/28/26 6:25 PM, Baptiste Le Duc wrote: >>> + asm_inline goto ( >>> + "1: lw zero, 0(%[va])\n" >>> + ASM_EXTABLE(1b, %l[out]) >>> + : >>> + : [va] "r" (va) >>> + : "memory" >>> + : out ); >>> + >>> + /* Order the load, and so its A bit update, before reading the PTE */ >> /* Check to see if hardware set A. */ > It doesn't explain the fence, but mine doesn't either. If you think it > doesn't matter, then I will use what you propose in v11. >>> + RISCV_FENCE(r, r); >>> + a_set = read_pte(entry).pte & PTE_ACCESSED; >>> + >>> + out: >> It's better to name this label 'fault' because that's what happened to >> use it. >> >> What happens if you neither fault, and A doesn't get set?  Right now >> you'll report Svade despite there being no fault. > I don't know if such a case is allowed by the spec, but afaiu, and we > talked a lot about that with Jan B and Oleksii, if we don't fault then > we should report Svade. >> You might or might not care to cover this case; that's up to the RISC-V >> maintainers as to how likely it is to encounter in real life. > I'm waiting for Jan B's and Oleksii's opinion on that point. I think that architecturally, per the RISC-V Privileged ISA specification, this outcome is not possible. During the execution of lw zero, 0(%[va]), there are only two valid spec-defined behaviors: - Hardware A/D update (Svadu): The load instruction succeeds, and the hardware atomically sets the A bit (PTE_ACCESSED) in the PTE. - Software A/D update (Svade): The load instruction triggers a Load Page Fault because the A bit is clear. The specification does not allow (or at least, I don't see it.) a third case where the load succeeds without setting the A bit. However, I agree that if we encounter non-compliant hardware or a buggy emulator where the load succeeds without setting the A bit, concluding that it is Svade (which strictly implies a page fault occurred) would be logically incorrect. Considering this is incorrect behavior per the spec, and given that having Svade support by default is safe, nothing bad will happen if we report Svade in such a case. So I would be okay with the current behavour in v10 and it seems to me enough for now. At the same time, I won't NACK the suggested approach below as it is harmless; I just think this scenario will never happen in practice, so it would essentially be dead code. >> But, if you do want to handle it, then you want something like >> >>     asm goto (...); >> >>     if ( 0 ) >>     { >>     fault: >>         got_fault = true; >>     } >> >>     ... >> >>     if ( !got_fault && !a_set ) >>         panic("Neither Svade nor Svadu !?!\n"); >> >> >> The if (0) is a bit ugly but it's the only way to avoid needing a second >> label. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 29 10:43:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 10:43:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464395.1675068 (Exim 4.92) (envelope-from ) id 1xMNbI-00060M-K1; Thu, 29 Oct 2026 10:43:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464395.1675068; Thu, 29 Oct 2026 10: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 1xMNbI-00060F-HM; Thu, 29 Oct 2026 10:43:16 +0000 Received: by outflank-mailman (input) for mailman id 1464395; Thu, 29 Oct 2026 10:43:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMNbH-000603-Eo for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:43:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMNbG-005JKR-Ry for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:43:14 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae32339-8faa-0a2a0a5109dd-0a2a4506c4c8-32 for ; Thu, 29 Oct 2026 11:43:14 +0100 Received: from [40.107.201.67] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae32340-195a-0a2a45060019-286bc9436f1a-3 for ; Thu, 29 Oct 2026 11:43:14 +0100 Received: from CYXPR03CA0059.namprd03.prod.outlook.com (2603:10b6:930:d1::11) by CY5PR12MB6623.namprd12.prod.outlook.com (2603:10b6:930:41::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Thu, 29 Oct 2026 10:43:10 +0000 Received: from CO1PEPF00012E65.namprd05.prod.outlook.com (2603:10b6:930:d1:cafe::73) by CYXPR03CA0059.outlook.office365.com (2603:10b6:930:d1::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.9 via Frontend Transport; Thu, 29 Oct 2026 10:43:10 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CO1PEPF00012E65.mail.protection.outlook.com (10.167.249.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Thu, 29 Oct 2026 10:43:08 +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.53; Thu, 29 Oct 2026 05:43: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.53; Thu, 29 Oct 2026 05:43:08 -0500 Received: from APPOL-18KY0J4.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Thu, 29 Oct 2026 05:43: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=T7egk3bZJ24CkH/Jy0jyvk6FpZPMk0T/ekulm14gs9NbK4GautO6ocPr+Thj1AJ4s1Rjj1pIfQF6vvLFn7zGnBeV3WrmQaMy/wRHYfM9MHYV32+kzpSU7M05pOitJIrHh/Gk89yPhEJ0fc2r+LfPBo0AWQ3tISNCPNiwqyVkQCD/W1qbX5bUiS+XeFA1a7pqV/OmoutFWumhkWkQG0fKPkNAxGjltgAUS17SBwbQZgTyeIjofxw/htdUCrf4aMBjRg8ERUu535ErOwKAKXPYuInFTOYqz1KCL7AsvvB6+SCssA2AGYNLqg4bl89opxg/TVr/fJMhI9p68nuljTTj7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p/Gsr14SbE4BHUwi0UD3spkz8U+EQr4T/9fDf5mXp34=; b=NFur581ba0D8h2QKaDRMK5SQ8Od9iYWFyrXlXuKeroSfJRqGDh/j08R49jcz30x+hresMkP5dA6S4qCYNSbxFBFo5EoaSpKK9fg3fsTG4lzFeZrswGbT/YdOplUMncF+IZcaAFDz1OP6hZrNmN5cZ9rwsLGGWh/MeI537AgeMkSEZpsadQlqxy6Mf0Gsl49yVzQeztXVv/ppHH4WE95AnzZJ1vcFQarh0j+ijPf97qb9y8A/tef93u0TY0L434gw9m7893xZ1vbcCKy6u63X7u9hCQvDMdMMvToqhHsvjoGLmnAaaOY5N2c2f5cp/gAJipzQS5CTv6fWgLFJQDRGeA== 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=p/Gsr14SbE4BHUwi0UD3spkz8U+EQr4T/9fDf5mXp34=; b=MlLXe3HMrze6lv6PWQ3WieTIO8AiVbIurCiHQlh/zyHoby7IGxyTn1+f9+HNavjfexfmQSa2V5XY73kSo7ZoGsZviKOtE/hebMx3XtiRi7gW/cJa9/lUd5JhU4lqdIZHrRueXncBWrsVZ9WCTh5K3GN+p2W34jF70i+iSPiEZuA= 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 From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: [PATCH] xen/dt: Don't advertise Xen static-heap region to hwdom Date: Thu, 29 Oct 2026 11:43:05 +0100 Message-ID: <20261029104305.169036-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: CO1PEPF00012E65:EE_|CY5PR12MB6623:EE_ X-MS-Office365-Filtering-Correlation-Id: ae638d42-8b2b-42b3-3b50-08df35a96c2b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|36860700016|1800799024|82310400026|261021121427099003|261026121527099003|260925021311599003|260925021911599003|260925022911599003|11063799006|5023799004|56012099006|261022105027099003|261022075727099003|261009223027099003|261021123027099003|10067099003|18002099003|6133799003|261026140227099003|261028144727099003; X-Microsoft-Antispam-Message-Info: kpFwalQGph8bT8tuSeatZYZjSCLOrAhUmHndLjBQn7c1nXOJvYWtY3Gc4M01SSf6DIOE6BGXfe2hozglo9j+PLnGe5HQhWT5T5sap0NChdpcJ2Smi+BN0hJk1/N3sDAN3Sb3fzBn337ZzH7tAQCizOZ4P3AfAMXaZDE02yl3GbSriiYyHQ8aW+Pbk6BPGhH6OPO43MTLIrHkBao0/gPIWqM6hw/EZWggc1YBmfDyBQkjOBZ6eJWmr353HnDTWUiHdk8yT6b98MeRObx6URnvYqWIspY0opKt0UkfuqQ9MkHJwpZ5d/RPgKEp2N9R2atVe4rmsPe4TNP/PqwgOtikHedCw0LM4yVQlD0NvYjaD3RJKKAP5SWDkjlf3uPRAaSzQB+jL4AJyvFzBRfRtWwwQfX+fxu6UXQRN5NP5UkCaLhnB/eZa8OIfkptCKFTd1FPVpVfiOAc0POHIuCbJ5zjXVSOZsChdHS6htlWIvcdjeILYjCRLOE67TCzOeoeqZ03umvsk9xMMZWAwvi7D2TY/+oFihfrbOG/AafA5i3t6kDQwg078yCTQWAS2SvcT+jzAd0OmVsE4PqM4BSIl/M78TpqmTFVcn55zg7HoqNlj7VQwTfqGJfqnn9I4irCcW0uF+aRnDGK3HQ6d+ABYXlC8xxS+sPxyIfyknPu1bhGiktoxzpXJfCalxmtVID/3cSGZvzMoqcDQf6C2fRu/7+Dog== 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)(23010399003)(36860700016)(1800799024)(82310400026)(261021121427099003)(261026121527099003)(260925021311599003)(260925021911599003)(260925022911599003)(11063799006)(5023799004)(56012099006)(261022105027099003)(261022075727099003)(261009223027099003)(261021123027099003)(10067099003)(18002099003)(6133799003)(261026140227099003)(261028144727099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: leOAkV8JunCZxZavG7744pcmp7cQnpgajekVbx5N2LtA7ki6nvHORXPo+blnfgURKOspx5DQfWiVzEECoKloJjSGkF8f64S/teVWQWIxvYqOh3gNg080+RqRAnb+tFAtkUsl1ooa2AlkfrLhKlqEzBervRY7DOS4ibXi4zkb4Ar/ihZXKxPfvNnLl1PmQeekNk6jZWyM+T1l/pUSIIG2+WjnOmX/BsCITVGfUlRvPPK3Dsb74qs8BKhscZX3Bx4T0DLXn9pD3iLDCZQdbSdIboHoScEHxcRMqiEi9Mb2WpTTb+TL+2QTe5rvZnNpOOoDG6Cv2PcZnt1tEA83y+DqUXsi1iH8gpsuzzMK8GrVq1TDpoeVLe2CwXvBPsMb0QlyKE1qCBNJpWe7sClTISG5IwlYyx2yfEt6aFIiG3tRWNwSrEYxByDl+8/B5vhSCwfD X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 10:43:08.9587 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ae638d42-8b2b-42b3-3b50-08df35a96c2b 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: CO1PEPF00012E65.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6623 X-purgate-ID: tlsNG-16d1c6/1793270594-F580D77B-C87B7E30/0/0 X-purgate-type: clean X-purgate-size: 1560 bootinfo.reserved_mem is used to store different types of memory that Xen considers as reserved: domU static mem, normal /reserved-memory, FDT memreserve and Xen static heap. make_memory_node(), invoked during FDT generation for a hwdom for reserved memory, only skips the domU static memory and FDT memreserve. This results in advertising Xen static heap (if used) to a hwdom as /memory. This memory is not mapped in P2M and guest attempt to access it fails. Interestingly, if the /reserved-memory node is placed after /chosen, there is no problem because of the check at the beginning of make_memory_node() that finds the first memory range using the correct type. Fixes: 4596329291f5 ("docs, xen/arm: Introduce static heap memory") Signed-off-by: Michal Orzel --- xen/common/device-tree/domain-build.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c index 30a59abfa722..634a26946c24 100644 --- a/xen/common/device-tree/domain-build.c +++ b/xen/common/device-tree/domain-build.c @@ -541,8 +541,7 @@ int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, u64 start = mem->bank[i].start; u64 size = mem->bank[i].size; - if ( (mem->bank[i].type == MEMBANK_STATIC_DOMAIN) || - (mem->bank[i].type == MEMBANK_FDT_RESVMEM) ) + if ( mem->bank[i].type != MEMBANK_DEFAULT ) continue; nr_cells += reg_size; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Oct 29 10:56:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 10:56:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464381.1675085 (Exim 4.92) (envelope-from ) id 1xMNnv-0008NA-QC; Thu, 29 Oct 2026 10:56:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464381.1675085; Thu, 29 Oct 2026 10: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 1xMNnv-0008N3-Lw; Thu, 29 Oct 2026 10:56:19 +0000 Received: by outflank-mailman (input) for mailman id 1464381; Thu, 29 Oct 2026 10:30:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMNOt-0003U2-Ly for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:30:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMNOs-005zYR-TH for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:30:26 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae32041-8faa-0a2a0a5109dd-0a2a450aa604-2 for ; Thu, 29 Oct 2026 11:30:26 +0100 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 6ae32041-f2d2-0a2a450a0019-aa0a817ca7c1-3 for ; Thu, 29 Oct 2026 11:30:26 +0100 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-651-31dn0k00OXi4Pkf-NALwaA-1; Thu, 29 Oct 2026 06:30:22 -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 9F9651801358; Thu, 29 Oct 2026 10:30:15 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.2]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7AAD23000735; Thu, 29 Oct 2026 10:30:11 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 1B5FA21E6A04; Thu, 29 Oct 2026 11:30:09 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-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=1793269825; 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=cAtddHWUPZrCBDhs0Y+44QLZfPLGxO3YxnP4tMoElZY=; b=Lq/1fex3Y4GT8j3QIrSQ81ux7YKZMeMUldvBHwLc9wQUpQortmX03lASbZOLcFg1bDk9Th JDgXzjageCnz7f2j7xq0jSmYqLkwiwAMGzIDBtk5YFq5ylj9UhuP3FU5yFDPnL7+34uuyT rA7MKOrLbH4aAUo7LxxvKa3vfHBYtDE= X-MC-Unique: 31dn0k00OXi4Pkf-NALwaA-1 X-Mimecast-MFC-AGG-ID: 31dn0k00OXi4Pkf-NALwaA_1793269818 From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 61/65] qdev: remove deprecated PropertyInfo.type and .enum_table fields In-Reply-To: <20261020-qom-qapi-v7-61-431a86b02b58@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 20 Oct 2026 14:46:18 +0400") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-61-431a86b02b58@redhat.com> Date: Thu, 29 Oct 2026 11:30:09 +0100 Message-ID: <87ecd8dcjy.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: KcRy_kpfijyhVU3nyHi7SGiyuZPieqr2vZaIUJxFZXo_1793269818 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1793269826-4BCD3CFC-4EDEA0FB/0/0 X-purgate-type: clean X-purgate-size: 882 Re title: I think "deprecated" isn't the right word. Let's go with "unused", or maybe qdev: PropertyInfo.type and .enum_table are no longer used, drop Marc-Andr=C3=A9 Lureau writes: > Now that all PropertyInfo definitions use .qapi_type, remove the > legacy .type (string) and .enum_table fields from PropertyInfo, and > the .arrayinfo/.arrayfieldsize fields from Property. > > Remove fallback branches in qdev_property_add_static() and > qdev_class_add_property() that used object_property_add() with > prop->info->type: these always use the QAPI-aware registration > path now. Simplify qdev_propinfo_enum_lookup(), prop_array_info() > and prop_array_elem_size() to use the new fields directly. > > Signed-off-by: Markus Armbruster > Signed-off-by: Marc-Andr=C3=A9 Lureau From xen-devel-bounces@lists.xenproject.org Thu Oct 29 10:57:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 10:57:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464417.1675094 (Exim 4.92) (envelope-from ) id 1xMNoa-0000N0-1S; Thu, 29 Oct 2026 10:57:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464417.1675094; Thu, 29 Oct 2026 10:57: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 1xMNoZ-0000Mt-UP; Thu, 29 Oct 2026 10:56:59 +0000 Received: by outflank-mailman (input) for mailman id 1464417; Thu, 29 Oct 2026 10:56:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMNoZ-0000Mn-DB for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:56:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMNoZ-00000002Q0I-2D2B for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:56:59 +0000 Received: from mail-lj1-f169.google.com ([209.85.208.169]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMNoZ-00000003Qzk-14mp for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 10:56:59 +0000 Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-3ab4891fc73so18681751fa.0 for ; Thu, 29 Oct 2026 03:56: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" 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=Efja6pmbvVwOMLQt56xqENbzqtO47sBOANrpLbfmbUQ=; b=GCDs2hz5QgVExTtRHHC30r6JSU 5oGdJfQ3KpCBXcnh4jZEYuAEFg0ELx/qbi2s56p2RXErutO7fk/Sk3cOrtu+w/rqXDHYmSBmUsyXO 8UzMmZECXxwsxdyFyTuLxzYcQTXhHOzNC30f3BZhTflIqFHwB6Z5muRgCgldK0jYQ3r0=; X-Gm-Message-State: AFq9FYITtcDd9AiI0TumNRF9TrQ4L3Zj5vHfJmBXOtc3kBtBxeItHDvj 4zi5u4O7h72BpkS4GmoL6wjfXjIuQEuvFTYIINExv4VqbSfw1OPzHpZSiYPBwElt6OKYX19xlRs K7GUoYoFGep63k7SSoyHxJUT4pjFal28= X-Received: by 2002:a05:651c:b26:b0:3a3:3170:5420 with SMTP id 38308e7fff4ca-3ac9ce84920mr11099491fa.3.1793271418027; Thu, 29 Oct 2026 03:56:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Dunlap Date: Thu, 29 Oct 2026 10:56:45 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_j0FzS-_OKVmwAH362qHz2dG4lkK6mBc8mz0dKuDerD84Yve73jY3SE2E Message-ID: Subject: Re: [PATCH] x86: invoke xenheap_max_mfn() unconditionally To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2026 at 12:12=E2=80=AFPM Jan Beulich wr= ote: > > Calling the function only conditionally can, when highmem_start isn't set > and when hotplugged memory appears above the boundary where the "short" > directmap ends, result in Xenheap allocations to yield memory which isn't > accessible through the "short" directmap. Accesses from PV guest context > would then either fault or access guest controlled memory. > > With this the bifurcation done by 88e3ed61642b ("x86/NUMA: make > init_node_heap() respect Xen heap limit") can also be undone: > end_boot_allocator() can be called from a single place, and system_state > is bumped right afterwards. > > Fixes: adc5afbf1c70 ("x86: support up to 16Tb") > Assisted-by: Claude Opus 5.5 > Reported-by: George Dunlap > Signed-off-by: Jan Beulich Reviewed-by: George Dunlap I might note more strongly that the bifurcation is a robustness issue: people checking for SYS_STATE_boot are specifically checking whether the boot allocation regime is still in place. I take it we're not moving "system_state =3D SYS_STATE_boot" into end_boot_allocator() to make it easier to see the major milestones in setup.c:__start_xen(). As an aside, Claude notes that highmem_start isn't clamped to 5TiB; in theory if somebody put `highmem-start=3D6T` on the command-line, it would cause problems. From xen-devel-bounces@lists.xenproject.org Thu Oct 29 11:07:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 11:07:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464436.1675135 (Exim 4.92) (envelope-from ) id 1xMNyr-00033s-6h; Thu, 29 Oct 2026 11:07:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464436.1675135; Thu, 29 Oct 2026 11:07: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 1xMNyr-00033l-3G; Thu, 29 Oct 2026 11:07:37 +0000 Received: by outflank-mailman (input) for mailman id 1464436; Thu, 29 Oct 2026 11:07:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMNyp-00033C-8d for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:07:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMNyo-005OxU-5d for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:07:34 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae328ef-e002-0a2a0a5209dd-0a2a4504e5e2-18 for ; Thu, 29 Oct 2026 12:07:33 +0100 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 6ae328f5-b57f-0a2a45040019-b9ff1c228277-3 for ; Thu, 29 Oct 2026 12:07:33 +0100 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 1a18757e9d0000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 11:07: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 2126282159; Thu, 29 Oct 2026 12:07:27 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=cjMzGO01G3hOFMmT9X5LdO+DnHW9oHX6RTdHSYMWhNA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ew9TRJYzkqRGKgUyy95kNQHJqjttx5Ya8i+QORweJUowjnDTd/sFZDk8SSU3oMpm7ei9GOQk2 zoHHBBP1LX0zayuo+pWCgQk0weDoxze6OYIVkZtK9Uj0ykkERQ47Y1dL0sMnQoXypm4tp0ABrP0 SX1L+PyrVjRxqwZw/+jRKJWrYpjwV9L5OKTtnigkeBXwYdXi/nc4O2AC3sLAQR+0HESL0+FSGn/ /OziFNMUpDIc2YoU1DBv5UndDKmHLQ5K8c1OMJYiErZcwtM4L2CzIriFqp1kMPjISbrhITvfFVH K5nPWmloxshBj4UE9gJlTrOC5IajudqZCyVKgOQaZeyg== X-Zone-Loop: 57114da202241c6487c154364158802d17c5920653a6 x-campaign-type: default x-transaction-id: f9b1dac3-b34c-4e62-ac82-5eefdee38539 x-swg-uid: 01-bbdf37e0-82bd-4cef-af07-e4b6f28eb90e X-Mailer: Sweego Message-ID: <1793272048.8631fc262581453bbf619ec5b2062170.1a18757e9d0000f79f@vates.tech> x-swg-bid: 1793272048.8631fc262581453bbf619ec5b2062170.1a18757e9d0000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 29 Oct 2026 12:07:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 6/9] tools/libs/guest: add XCFLAGS_COMPRESS_LZ4 to request LZ4 compression To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-7-marcus.granado@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: <20261020200238.1815766-7-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------k9qiSCKGyvxPnYWYuW09oQ57" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793272047286 X-purgate-ID: tlsNG-ebf023/1793272053-512DCB50-B5098AA7/0/0 X-purgate-type: clean X-purgate-size: 8276 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------k9qiSCKGyvxPnYWYuW09oQ57 Content-Type: multipart/mixed; boundary="------------wTsRs3hVkkBSpEXKKVHtwKIf"; protected-headers="v1"; hp="clear" Message-ID: <9eaf727c-50b2-4b0e-b9b4-290272287d85@vates.tech> Date: Thu, 29 Oct 2026 12:07:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 6/9] tools/libs/guest: add XCFLAGS_COMPRESS_LZ4 to request LZ4 compression To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-7-marcus.granado@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: <20261020200238.1815766-7-marcus.granado@citrix.com> --------------wTsRs3hVkkBSpEXKKVHtwKIf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowNSwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g Tm90aGluZyBzZXRzIGN0eC0+c2F2ZS5jb21wcmVzc2lvbiB0byBYQ19TUl9DT01QUkVTU19M WjQsIHNvIHRoZSBMWjQNCj4gcGF0aCBpbiB3cml0ZV9iYXRjaCgpIGlzIHVucmVhY2hhYmxl IGFuZCBhIGNhbGxlciBvZiB4Y19kb21haW5fc2F2ZSgpDQo+IGhhcyBubyB3YXkgdG8gYXNr IGZvciBjb21wcmVzc2VkIFBBR0VfREFUQSByZWNvcmRzLg0KPiANCj4gQWRkIFhDRkxBR1Nf Q09NUFJFU1NfTFo0IGFuZCBzZWxlY3QgTFo0IHdoZW4gaXQgaXMgc2V0LiAgQSBjYWxsZXIg d2hpY2gNCj4gZG9lcyBub3Qgc2V0IGl0IHNlZXMgbm8gY2hhbmdlOyBvbmUgd2hpY2ggZG9l cyBuZWVkcyBhIHJlY2VpdmVyIGFibGUgdG8NCj4gZGVjb21wcmVzcyBMWjQuDQo+IA0KPiBB IGxpYnhlbmd1ZXN0IGJ1aWx0IHdpdGhvdXQgYSBzdXBwb3J0ZWQgbGlibHo0IGNhbm5vdCBo b25vdXIgdGhlIGZsYWcsDQo+IHNvIGZhaWwgdXAgZnJvbnQgd2l0aCBFT1BOT1RTVVBQIHJh dGhlciB0aGFuIHNpbGVudGx5IHNlbmQgdW5jb21wcmVzc2VkDQo+IHJlY29yZHMuDQo+IA0K PiBBc3Npc3RlZC1ieTogQ2xhdWRlOmNsYXVkZS1vcHVzLTUtNQ0KPiBTaWduZWQtb2ZmLWJ5 OiBNYXJjdXMgR3JhbmFkbyA8bWFyY3VzLmdyYW5hZG9AY2l0cml4LmNvbT4NCj4gLS0tDQo+ IA0KPiBOb3RlczoNCj4gICAgICBDaGFuZ2VzIGluIHYyOg0KPiAgICAgIC0gV2FzIHYxIDUv Ni4NCj4gICAgICAtIFNldCBjdHgtPnNhdmUuY29tcHJlc3Npb247IHRoZSBmaWVsZCBtb3Zl ZCBpbnRvIHRoZSBzYXZlIGNvbnRleHQuDQo+ICAgICAgDQo+ICAgICAgQml0IDIgd2FzIFhD RkxBR1NfSFZNIHVudGlsIGNvbW1pdCAyMDA0ZGIzY2VkMTggKCJ0b29scy9zYXZlOiBEcm9w DQo+ICAgICAgdW51c2VkIHBhcmFtZXRlcnMgZnJvbSB4Y19kb21haW5fc2F2ZSgpIikgcmVt b3ZlZCBpdCBpbiA0LjE0Lg0KPiANCj4gICB0b29scy9pbmNsdWRlL3hlbmd1ZXN0LmggICAg ICB8ICA1ICsrKy0tDQo+ICAgdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zYXZlLmMgfCAxMSAr KysrKysrKysrKw0KPiAgIDIgZmlsZXMgY2hhbmdlZCwgMTQgaW5zZXJ0aW9ucygrKSwgMiBk ZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS90b29scy9pbmNsdWRlL3hlbmd1ZXN0 LmggYi90b29scy9pbmNsdWRlL3hlbmd1ZXN0LmgNCj4gaW5kZXggMmEyNzdjYjdjZC4uNzAz MDFjMmY0OCAxMDA2NDQNCj4gLS0tIGEvdG9vbHMvaW5jbHVkZS94ZW5ndWVzdC5oDQo+ICsr KyBiL3Rvb2xzL2luY2x1ZGUveGVuZ3Vlc3QuaA0KPiBAQCAtMjQsOCArMjQsOSBAQA0KPiAg IA0KPiAgICNkZWZpbmUgWENfTlVNQV9OT19OT0RFICAgKH4wVSkNCj4gICANCj4gLSNkZWZp bmUgWENGTEFHU19MSVZFICAgICAgKDEgPDwgMCkNCj4gLSNkZWZpbmUgWENGTEFHU19ERUJV RyAgICAgKDEgPDwgMSkNCj4gKyNkZWZpbmUgWENGTEFHU19MSVZFICAgICAgICAgKDEgPDwg MCkNCj4gKyNkZWZpbmUgWENGTEFHU19ERUJVRyAgICAgICAgKDEgPDwgMSkNCj4gKyNkZWZp bmUgWENGTEFHU19DT01QUkVTU19MWjQgKDEgPDwgMikgLyogTFo0IG9uIHNhdmU7IHJlc3Rv cmVyIG5lZWRzIExaNCAqLw0KPiAgIA0KPiAgICNkZWZpbmUgWDg2XzY0X0JfU0laRSAgIDY0 DQo+ICAgI2RlZmluZSBYODZfMzJfQl9TSVpFICAgMzINCj4gZGlmZiAtLWdpdCBhL3Rvb2xz L2xpYnMvZ3Vlc3QveGdfc3Jfc2F2ZS5jIGIvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zYXZl LmMNCj4gaW5kZXggNGZhMWQyMjg1OS4uZmUzZDc4YmRkNiAxMDA2NDQNCj4gLS0tIGEvdG9v bHMvbGlicy9ndWVzdC94Z19zcl9zYXZlLmMNCj4gKysrIGIvdG9vbHMvbGlicy9ndWVzdC94 Z19zcl9zYXZlLmMNCj4gQEAgLTExNjYsNiArMTE2NiwxNyBAQCBpbnQgeGNfZG9tYWluX3Nh dmUoeGNfaW50ZXJmYWNlICp4Y2gsIGludCBpb19mZCwgdWludDMyX3QgZG9tLA0KPiAgICAg ICBjdHguc2F2ZS5kZWJ1ZyA9ICEhKGZsYWdzICYgWENGTEFHU19ERUJVRyk7DQo+ICAgICAg IGN0eC5zYXZlLnJlY3ZfZmQgPSByZWN2X2ZkOw0KPiAgIA0KPiArICAgIGlmICggZmxhZ3Mg JiBYQ0ZMQUdTX0NPTVBSRVNTX0xaNCApDQo+ICsgICAgew0KPiArI2lmIGRlZmluZWQoWEdf U1JfTFo0KQ0KPiArICAgICAgICBjdHguc2F2ZS5jb21wcmVzc2lvbiA9IFhDX1NSX0NPTVBS RVNTX0xaNDsNCj4gKyNlbHNlDQo+ICsgICAgICAgIEVSUk9SKCJYQ0ZMQUdTX0NPTVBSRVNT X0xaNCByZXF1ZXN0ZWQgYnV0IGxpYnhlbmd1ZXN0IHdhcyBidWlsdCB3aXRob3V0IGEgc3Vw cG9ydGVkIGxpYmx6NCIpOw0KPiArICAgICAgICBlcnJubyA9IEVPUE5PVFNVUFA7DQo+ICsg ICAgICAgIHJldHVybiAtMTsNCj4gKyNlbmRpZg0KPiArICAgIH0NCj4gKw0KPiAgICAgICBp ZiAoIHhjX2RvbWFpbl9nZXRpbmZvX3NpbmdsZSh4Y2gsIGRvbSwgJmN0eC5kb21pbmZvKSA8 IDAgKQ0KPiAgICAgICB7DQo+ICAgICAgICAgICBQRVJST1IoIkZhaWxlZCB0byBnZXQgZG9t YWluIGluZm8iKTsNCg0KUmV2aWV3ZWQtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2 YXRlcy50ZWNoPg0KDQpUZWRkeQ0K --------------wTsRs3hVkkBSpEXKKVHtwKIf-- --------------k9qiSCKGyvxPnYWYuW09oQ57 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+p0QLLz9AFAmrjKO4FAwAAAAAACgkQZg+p0QLLz9BK 0QwAoAxjgLJqXkEVW3PqhZaXQuXvKUB+0brXJviAYHZRmxyULAh4ohiQ9cF3a5jIaRhWZmoYMrAR +qRmdoPCKNOJ221HxgAutnNh6IFd13+G4Mw4JfH5P2s+GuXx3WxXW2lxEe2I/Csy8WiTHFqyZcEa //FXQZJ0oisv9VWULZLx0I6QcY6ZHe4Vy4IB0hX6I/cZ1a9pxyb5BI7Ard+p0cJwGwnKwxhCReq0 +oUc8mLfvqKO5vEfvw1hFBT1S78UBgSOBvU2EY3e6Q65mePlrLfoGAfI5lP8luTTQEvNb5gLVvMs 8Gk4HY4F3GbpQXqejIhkHsnIo5eKY+5pkhf8Ff9VoiXqFHAd1Q3F5MIIvaoEU9THc1P2QDDdZMCJ SH5F/cehlPTAJZSIkRlyPk89dGX6hu8yjI6GMB8oGLhSe4Kexvqsl93lP+nrD7iQDZigEez86oRd qZeI+IcJkhE+8EZ1cx4SgGvxKor6hBXvgTRE/hzGiDr22aeDqWut1zpK0tA4 =1HQ6 -----END PGP SIGNATURE----- --------------k9qiSCKGyvxPnYWYuW09oQ57-- From xen-devel-bounces@lists.xenproject.org Thu Oct 29 11:17:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 11:17:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464446.1675143 (Exim 4.92) (envelope-from ) id 1xMO80-0005X6-3C; Thu, 29 Oct 2026 11:17:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464446.1675143; Thu, 29 Oct 2026 11:17: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 1xMO80-0005Wz-0H; Thu, 29 Oct 2026 11:17:04 +0000 Received: by outflank-mailman (input) for mailman id 1464446; Thu, 29 Oct 2026 11:17:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMO7y-0005Wt-SI for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:17:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMO7y-006A7U-8w for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:17:02 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae32b2b-2eae-0a2a0a5409dd-0a2a4501a83c-6 for ; Thu, 29 Oct 2026 12:17:02 +0100 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 6ae32b2d-5984-0a2a45010019-d1558036e070-3 for ; Thu, 29 Oct 2026 12:17:02 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a3517554f7so17808645e9.2 for ; Thu, 29 Oct 2026 04:17: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-4a94eb8a60fsm93109935e9.3.2026.10.29.04.17.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 04:17: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=1793272621; x=1793877421; 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=OSkLkZDEkmBMrgmXTeq2XFXp5vmN6xBD+I1u0VWPlow=; b=gJGpZBbAxOXsD5vvvSJUWp8Y2Yv0KvHQcm+AoOLXoNpnww9Alt0aXr5NH7pBdOA+ss PuOQkFiBx1D4AMTGGTjnstNzu1KdaY2q3vojt9LsfB9h6EuMPAP8wq+lvMFaXI/CxvgW 7OU1bbVpW3g3CM8FvBzJH9aC63DCjhXLgMih8rsYLUI9DI845x9ZUowRIOZtr6t8XP6K GZ/CwCouy0AP/Jr9dhoppeUczF8Ubk8Z6nBYAC8WvP/dVZTTxNKHFGGsY3FuIX9u+38N y0FpsHxmB87PRGEg5fHbzj0EeRVnrt4tqzUJN81Nu3D9GYKBzHGatay1PDj71SirPDTC QReQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793272621; x=1793877421; 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=OSkLkZDEkmBMrgmXTeq2XFXp5vmN6xBD+I1u0VWPlow=; b=GQoxaDEpKu1XNUdGYon4qx/T+eykadwmEQgq7bVcSDlUBvuursJEObqpBu/WMvZ+06 BhaiwOPGlI+/rgLa1R31e04HyXAmYutpWR40jPRp0xhR4MZTos8hRQyLMn4CTP2ZF5HO VFG8tTEeh0czcrDrxykHoPXEXvf9clmg/SPYzfc+VMWCRN3/wXNH0OBUBNtvqHhe3mXa jqyQoTW2cVlEUjOa+7hbEHYHRr4Uts622U8uLOvsaJtcXq6yacte2GQ1UUCX2DLUNRq2 wwVI/Jvt4LwHDXPRbPQsqFlJG5sSZC686mjxDp1d7SWAV//1aphRK0sEwPY91+e27PA4 81Pg== X-Gm-Message-State: AFq9FYKsQsVPRAQl4P1VVthHkFinX4vrZCO53nj4jKkzespSJ/47B1oq BIt2xL4Le1Ixrupk/f5RJUhzD8/4ic04Z6He8s3VtEzkiKD/OeagXMll2P30Wkirxg== X-Gm-Gg: AYBFou3X57yEtrcc3+H2meL6VfOLGcWtKphjJN2fCXGWx2SvBFpBbb/DK78ICg5Cdjh YyydrraU38TyvP/9QXd57VaAOGBTbX+TDWN5QGO+dBhbvK9O5/noF5FreOD3YyNMsdjAw8O/E9e eUemIAoZIdurtlVC3kZWv/awgW85ScBRa8wBliIJwpCwYd4oURR1GWQjbG6XhQUsyOS+IsuwiBf tRP5qubzaPL9GXvvyKHC2rqulx3XMKSmpDNK0b+ujNBTcDblJprykltBC57DHkOIGnQOumcJYAz C0nmg6iG7ssXkD/u4EBbsKJiHQargGtwQFw3QFWQz+nIU3sHqZN5/AOiMBpDRZKk9YwYZr0LEvT JXqlsD2cDA1gtOFafaH46CU0FzR5z18sfMHBeGCo1RKuj3o2PkP1GHGQ+8aEUQCjykzatXnUaPi wkElCpEJjO6L/0aEjWJ3DnwAQV1JuafOgAj1OazphlGb0Q+cw9mbuuZy8MCPBRvAC9ewdjt8rIc AviSgKfsI29mIf6kdHQnxtzufNbgyFe0n2TuZ91ePA9uJVB57NT8M3zUewuOOpPfaZwgnEI6cu7 ug1HB7p2u1bSGW+DQsfsEbM+XW/c3PX1mzVAJDrQDApZ943fRRUOPshghKnHmtUt132RT+T92KW g4kuj7FmF1i/ETmyB X-Received: by 2002:a05:600c:190a:b0:4a2:150f:1601 with SMTP id 5b1f17b1804b1-4a966586d1bmr111159595e9.12.1793272621559; Thu, 29 Oct 2026 04:17:01 -0700 (PDT) Message-ID: <4ab81f7c-ec26-48b7-971f-1d548362ad57@suse.com> Date: Thu, 29 Oct 2026 12:17:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: invoke xenheap_max_mfn() unconditionally To: George Dunlap Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 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-d62444/1793272622-BCF47757-F5F9AEAB/10/78276251493 X-purgate-type: spam X-purgate-size: 1328 On 29.10.2026 11:56, George Dunlap wrote: > On Mon, Oct 12, 2026 at 12:12 PM Jan Beulich wrote: >> >> Calling the function only conditionally can, when highmem_start isn't set >> and when hotplugged memory appears above the boundary where the "short" >> directmap ends, result in Xenheap allocations to yield memory which isn't >> accessible through the "short" directmap. Accesses from PV guest context >> would then either fault or access guest controlled memory. >> >> With this the bifurcation done by 88e3ed61642b ("x86/NUMA: make >> init_node_heap() respect Xen heap limit") can also be undone: >> end_boot_allocator() can be called from a single place, and system_state >> is bumped right afterwards. >> >> Fixes: adc5afbf1c70 ("x86: support up to 16Tb") >> Assisted-by: Claude Opus 5.5 >> Reported-by: George Dunlap >> Signed-off-by: Jan Beulich > > Reviewed-by: George Dunlap Thanks. > As an aside, Claude notes that highmem_start isn't clamped to 5TiB; in > theory if somebody put `highmem-start=6T` on the command-line, it > would cause problems. True, and we may want to do better there. Still various other cmdline options, when used with inappropriate values, will cause mischief as well. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 11:22:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 11:22:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464454.1675152 (Exim 4.92) (envelope-from ) id 1xMODM-0007Yv-M7; Thu, 29 Oct 2026 11:22:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464454.1675152; Thu, 29 Oct 2026 11:22: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 1xMODM-0007Yn-IV; Thu, 29 Oct 2026 11:22:36 +0000 Received: by outflank-mailman (input) for mailman id 1464454; Thu, 29 Oct 2026 11:22:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMODK-0007Yh-Q5 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:22:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMODK-00AmZx-6m for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:22:34 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae32c75-bab6-0a2a0a5309dd-0a2a450cda6a-16 for ; Thu, 29 Oct 2026 12:22:33 +0100 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 6ae32c79-f479-0a2a450c0019-b9ff1c23915d-3 for ; Thu, 29 Oct 2026 12:22:33 +0100 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 1a18765b5cd000f79f.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 11:22:32 +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 061A1823B2; Thu, 29 Oct 2026 12:22:31 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=txRw/BY8SLvJTx4NIKx4eVMB5gMLZd9dpwDiZFVMXDo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=tKMLg81ncO5vcZJqVM8g9El91QCNcfGJqx67uBf+iSGKbDpmqFyrRRVNue+BdPZEp4zu3ZlfP Paehr/0s6Gy2NbJsOAarOi/7n8Evrw/1FCb9lRkiD6+4pfsFHt3S2YpY+zNPhNx1R1XPSweR6yk xgmml6T+ekXOAqIgf67eugnlOrv/tVxj+ZM9yDb4qgTlECp8R07Tsbxhy+1JiQ3bhRz5pLEfUvH Peaky5okrwDSd2sR4Kbqnjl2TOQKm+nMug83RejQbCUCvYTzmCUsOpuHo0WqphZUvDEt5464cYS +DakQODa1BQPUiYOOks8wghh0utj7vDPxJRnOoi2IfLA== X-Zone-Loop: 29c0343b7d9a23f9d8d0890fe74862ba2900a0f63d2f x-campaign-type: default x-transaction-id: e3a01285-29e5-4f5d-8518-6b27b9fdbceb x-swg-uid: 01-1d31058c-a35c-49c6-9e2b-64c743028466 X-Mailer: Sweego Message-ID: <1793272952.8631fc262581453bbf619ec5b2062170.1a18765b5cd000f79f@vates.tech> x-swg-bid: 1793272952.8631fc262581453bbf619ec5b2062170.1a18765b5cd000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 29 Oct 2026 12:22:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 7/9] tools/libxl,xl: add a --compress option to xl migrate To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Oleksii Kurochko , Community Manager References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-8-marcus.granado@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: <20261020200238.1815766-8-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------U4bQ90ZdlRpTAVQCjeBnXCVc" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793272951234 X-purgate-ID: tlsNG-d25034/1793272953-770D9A5B-2371939A/0/0 X-purgate-type: clean X-purgate-size: 17293 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------U4bQ90ZdlRpTAVQCjeBnXCVc Content-Type: multipart/mixed; boundary="------------JIIv7xp30jc1abRiF1bZWtsB"; protected-headers="v1"; hp="clear" Message-ID: <2af4c626-1209-43c2-8339-34f04b9c5aaa@vates.tech> Date: Thu, 29 Oct 2026 12:22:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 7/9] tools/libxl,xl: add a --compress option to xl migrate To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Oleksii Kurochko , Community Manager References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-8-marcus.granado@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: <20261020200238.1815766-8-marcus.granado@citrix.com> --------------JIIv7xp30jc1abRiF1bZWtsB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowNSwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g bGlieGVuZ3Vlc3QgY2FuIGNvbXByZXNzIFBBR0VfREFUQSByZWNvcmRzIHdpdGggTFo0IHdo ZW4gaXRzIGNhbGxlcg0KPiBzZXRzIFhDRkxBR1NfQ09NUFJFU1NfTFo0LCBidXQgbGlieGwg bmV2ZXIgc2V0cyBpdCwgc28geGwgaGFzIG5vIHdheSB0bw0KPiBhc2sgZm9yIGNvbXByZXNz aW9uLg0KPiANCj4gQWRkIGEgTElCWExfU1VTUEVORF9DT01QUkVTU19MWjQgZmxhZyBmb3Ig bGlieGxfZG9tYWluX3N1c3BlbmQoKSwgcGFzcw0KPiBpdCB0byBsaWJ4ZW5ndWVzdCBhcyBY Q0ZMQUdTX0NPTVBSRVNTX0xaNCwgYW5kIGV4cG9zZSBpdCBhcw0KPiAieGwgbWlncmF0ZSAt LWNvbXByZXNzIi4NCj4gDQo+IE9mZiBieSBkZWZhdWx0OiB3aGV0aGVyIGNvbXByZXNzaW5n IHBheXMgb2ZmIGRlcGVuZHMgb24gaG93IGNvbXByZXNzaWJsZQ0KPiB0aGUgZ3Vlc3QncyBt ZW1vcnkgaXMgYW5kIG9uIHRoZSBDUFUgaGVhZHJvb20gb2YgYm90aCBob3N0cywgc28gdGhl DQo+IGNhbGxlciBkZWNpZGVzLiAgT25seSB4bCBtaWdyYXRlIGdldHMgdGhlIG9wdGlvbjsg eGwgc2F2ZSBhbmQgeGwgcmVtdXMNCj4gbmV2ZXIgdXNlIExaNC4NCj4gDQo+IFRoZSByZWNl aXZpbmcgc2lkZSBuZWVkcyBubyBvcHRpb24sIGFzIGVhY2ggUEFHRV9EQVRBIHJlY29yZCBz YXlzDQo+IHdoZXRoZXIgaXQgaXMgY29tcHJlc3NlZC4gIEEgcmVjZWl2ZXIgd2hpY2ggY2Fu bm90IGRlY29tcHJlc3MgcmVqZWN0cw0KPiB0aGUgZmlyc3QgY29tcHJlc3NlZCByZWNvcmQs IGFmdGVyIGl0IGhhcyBjcmVhdGVkIHRoZSBkb21haW4sIGFuZCB0aGUNCj4gbWlncmF0aW9u IGZhaWxzIHdpdGggdGhlIGd1ZXN0IHN0aWxsIG9uIHRoZSBzb3VyY2UuICBBIHNlbmRlciB3 aG9zZQ0KPiBsaWJ4ZW5ndWVzdCB3YXMgYnVpbHQgd2l0aG91dCBhIHN1cHBvcnRlZCBsaWJs ejQgZmFpbHMgdGhlIG1pZ3JhdGlvbg0KPiBiZWZvcmUgc2VuZGluZyBhbnkgZ3Vlc3QgbWVt b3J5OyBsaWJ4bCByZXBvcnRzIGl0IGFzIGEgc3VzcGVuZCB0aW1lb3V0Lg0KPiANCj4gQXNz aXN0ZWQtYnk6IENsYXVkZTpjbGF1ZGUtb3B1cy01LTUNCj4gU2lnbmVkLW9mZi1ieTogTWFy Y3VzIEdyYW5hZG8gPG1hcmN1cy5ncmFuYWRvQGNpdHJpeC5jb20+DQo+IC0tLQ0KDQpJIHdv bmRlciBpZiB3ZSBzaG91bGQgbmFtZSB0aGUgb3B0aW9uICItLWNvbXByZXNzLWx6NCIsIGxp a2UgaXQgaXMgdXNlZCANCmluIHRoZSBjb2RlIChjb21wcmVzc19sejQsIFhDRkxBR1NfQ09N UFJFU1NfTFo0LCANCkxJQlhMX1NVU1BFTkRfQ09NUFJFU1NfTFo0LCAuLi4pLg0KDQo+IA0K PiBOb3RlczoNCj4gICAgICBDaGFuZ2VzIGluIHYyOg0KPiAgICAgIC0gV2FzIHYxIDYvNi4g IFRoZSBsaWJ4bCBhbmQgeGwgY29kZSBpcyB1bmNoYW5nZWQ7IHRoZSBoZWxwIHRleHQgYW5k DQo+ICAgICAgICBtYW4gcGFnZSBub3cgc2F5IGJvdGggaG9zdHMgbmVlZCBsaWJsejQgc3Vw cG9ydCBpbiBsaWJ4ZW5ndWVzdCwgYW5kDQo+ICAgICAgICBDSEFOR0VMT0cubWQgaGFzIGFu IGVudHJ5Lg0KPiAgICAgIA0KPiAgICAgIE5vIExJQlhMX0hBVkVfKiBtYWNybzogTElCWExf U1VTUEVORF9DT01QUkVTU19MWjQgaXMgaXRzZWxmIGEgI2RlZmluZSwNCj4gICAgICBzbyBh IGNhbGxlciBjYW4gdGVzdCBmb3IgaXQgd2l0aCAjaWZkZWYgTElCWExfU1VTUEVORF9DT01Q UkVTU19MWjQuDQo+IA0KPiAgIENIQU5HRUxPRy5tZCAgICAgICAgICAgICAgICAgICAgICB8 ICAzICsrKw0KPiAgIGRvY3MvbWFuL3hsLjEucG9kLmluICAgICAgICAgICAgICB8ICA4ICsr KysrKysrDQo+ICAgdG9vbHMvaW5jbHVkZS9saWJ4bC5oICAgICAgICAgICAgIHwgIDEgKw0K PiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfZG9tX3NhdmUuYyB8ICA0ICsrKy0NCj4gICB0 b29scy9saWJzL2xpZ2h0L2xpYnhsX2RvbWFpbi5jICAgfCAgMSArDQo+ICAgdG9vbHMvbGli cy9saWdodC9saWJ4bF9pbnRlcm5hbC5oIHwgIDEgKw0KPiAgIHRvb2xzL3hsL3hsX2NtZHRh YmxlLmMgICAgICAgICAgICB8ICAyICsrDQo+ICAgdG9vbHMveGwveGxfbWlncmF0ZS5jICAg ICAgICAgICAgIHwgMTMgKysrKysrKysrKy0tLQ0KPiAgIDggZmlsZXMgY2hhbmdlZCwgMjkg aW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9DSEFO R0VMT0cubWQgYi9DSEFOR0VMT0cubWQNCj4gaW5kZXggMjI1Mzk3ZjEyOC4uNGYxZGE1ZDll NSAxMDA2NDQNCj4gLS0tIGEvQ0hBTkdFTE9HLm1kDQo+ICsrKyBiL0NIQU5HRUxPRy5tZA0K PiBAQCAtMTYsNiArMTYsOSBAQCBUaGUgZm9ybWF0IGlzIGJhc2VkIG9uIFtLZWVwIGEgQ2hh bmdlbG9nXShodHRwczovL2tlZXBhY2hhbmdlbG9nLmNvbS9lbi8xLjAuMC8pDQo+ICAgICAg ICBhZnRlcndhcmRzLg0KPiAgIA0KPiAgICMjIyBBZGRlZA0KPiArIC0gT24geDg2Og0KPiAr ICAgLSBPcHRpb25hbCBMWjQgY29tcHJlc3Npb24gb2YgdGhlIG1lbW9yeSBzdHJlYW0gZHVy aW5nIG1pZ3JhdGlvbg0KPiArICAgICAoeGwgbWlncmF0ZSAtLWNvbXByZXNzKS4NCj4gICAN Cj4gICAjIyMgUmVtb3ZlZA0KPiAgICAtIE9uIEFybToNCj4gZGlmZiAtLWdpdCBhL2RvY3Mv bWFuL3hsLjEucG9kLmluIGIvZG9jcy9tYW4veGwuMS5wb2QuaW4NCj4gaW5kZXggNTE0MDVm NGUzMy4uYjA0MzkyMzFlMiAxMDA2NDQNCj4gLS0tIGEvZG9jcy9tYW4veGwuMS5wb2QuaW4N Cj4gKysrIGIvZG9jcy9tYW4veGwuMS5wb2QuaW4NCj4gQEAgLTQ4OCw2ICs0ODgsMTQgQEAg ZG9tYWluLg0KPiAgIA0KPiAgIERpc3BsYXkgaHVnZSAoISkgYW1vdW50IG9mIGRlYnVnIGlu Zm9ybWF0aW9uIGR1cmluZyB0aGUgbWlncmF0aW9uIHByb2Nlc3MuDQo+ICAgDQo+ICs9aXRl bSBCPC0tY29tcHJlc3M+DQo+ICsNCj4gK0NvbXByZXNzIHRoZSBtZW1vcnkgc3RyZWFtIHVz aW5nIExaNCBpbnNpZGUgbGlieGVuZ3Vlc3QgYmVmb3JlIHNlbmRpbmcgaXQNCj4gK3RvIHRo ZSBkZXN0aW5hdGlvbiBob3N0LiBUaGlzIGNhbiBzaWduaWZpY2FudGx5IHJlZHVjZSBtaWdy YXRpb24gdGltZSBvbg0KPiArc2xvdyB0cmFuc3BvcnRzLCBhbmQgcmVkdWNlIGRvbTAgQ1BV IHByZXNzdXJlIGR1cmluZyBob3N0IGV2YWN1YXRpb25zIHdoZW4NCj4gK3RoZSBtaWdyYXRp b24gZGF0YSBpcyBzdWJzZXF1ZW50bHkgZW5jcnlwdGVkIG9yIGNvcGllZCB0aHJvdWdoIHBp cGVzLg0KPiArUmVxdWlyZXMgbGlibHo0IHN1cHBvcnQgaW4gbGlieGVuZ3Vlc3Qgb24gYm90 aCBob3N0cy4NCj4gKw0KPiAgID1pdGVtIEI8LXA+DQo+ICAgDQo+ICAgTGVhdmUgdGhlIGRv bWFpbiBvbiB0aGUgcmVjZWl2ZSBzaWRlIHBhdXNlZCBhZnRlciBtaWdyYXRpb24uDQo+IGRp ZmYgLS1naXQgYS90b29scy9pbmNsdWRlL2xpYnhsLmggYi90b29scy9pbmNsdWRlL2xpYnhs LmgNCj4gaW5kZXggZDI5NGZiMzZiZC4uMTExNGM4ZjhkMSAxMDA2NDQNCj4gLS0tIGEvdG9v bHMvaW5jbHVkZS9saWJ4bC5oDQo+ICsrKyBiL3Rvb2xzL2luY2x1ZGUvbGlieGwuaA0KPiBA QCAtMTkyMiw2ICsxOTIyLDcgQEAgaW50IGxpYnhsX2RvbWFpbl9zdXNwZW5kKGxpYnhsX2N0 eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgaW50IGZkLA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBMSUJYTF9FWFRFUk5BTF9DQUxMRVJTX09OTFk7DQo+ICAgI2RlZmluZSBMSUJY TF9TVVNQRU5EX0RFQlVHIDENCj4gICAjZGVmaW5lIExJQlhMX1NVU1BFTkRfTElWRSAyDQo+ ICsjZGVmaW5lIExJQlhMX1NVU1BFTkRfQ09NUFJFU1NfTFo0IDQNCj4gICANCg0KSSB0aGlu ayB0aGVzZSB3YW50cyB0byBiZSBjb252ZXJ0ZWQgdG8gKDE8PE4pIGZvcm0uDQoNCj4gICAv Kg0KPiAgICAqIE9ubHkgc3VzcGVuZCBkb21haW4sIGRvIG5vdCBzYXZlIGl0cyBzdGF0ZSB0 byBmaWxlLCBkbyBub3QgZGVzdHJveSBpdC4NCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMv bGlnaHQvbGlieGxfZG9tX3NhdmUuYyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfZG9tX3Nh dmUuYw0KPiBpbmRleCBkNjRmZDY0ZjJlLi4xNmI4ODJlY2YwIDEwMDY0NA0KPiAtLS0gYS90 b29scy9saWJzL2xpZ2h0L2xpYnhsX2RvbV9zYXZlLmMNCj4gKysrIGIvdG9vbHMvbGlicy9s aWdodC9saWJ4bF9kb21fc2F2ZS5jDQo+IEBAIC0yNDUsNiArMjQ1LDcgQEAgdm9pZCBsaWJ4 bF9fZG9tYWluX3NhdmUobGlieGxfX2VnYyAqZWdjLCBsaWJ4bF9fZG9tYWluX3NhdmVfc3Rh dGUgKmRzcykNCj4gICAgICAgY29uc3QgbGlieGxfZG9tYWluX3R5cGUgdHlwZSA9IGRzcy0+ dHlwZTsNCj4gICAgICAgY29uc3QgaW50IGxpdmUgPSBkc3MtPmxpdmU7DQo+ICAgICAgIGNv bnN0IGludCBkZWJ1ZyA9IGRzcy0+ZGVidWc7DQo+ICsgICAgY29uc3QgaW50IGNvbXByZXNz X2x6NCA9IGRzcy0+Y29tcHJlc3NfbHo0Ow0KPiAgICAgICBjb25zdCBsaWJ4bF9kb21haW5f cmVtdXNfaW5mbyAqY29uc3Qgcl9pbmZvID0gZHNzLT5yZW11czsNCj4gICAgICAgbGlieGxf X3NybV9zYXZlX2F1dG9nZW5fY2FsbGJhY2tzICpjb25zdCBjYWxsYmFja3MgPQ0KPiAgICAg ICAgICAgJmRzcy0+c3dzLnNocy5jYWxsYmFja3Muc2F2ZS5hOw0KPiBAQCAtMjY5LDcgKzI3 MCw4IEBAIHZvaWQgbGlieGxfX2RvbWFpbl9zYXZlKGxpYnhsX19lZ2MgKmVnYywgbGlieGxf X2RvbWFpbl9zYXZlX3N0YXRlICpkc3MpDQo+ICAgICAgIGlmIChyYykgZ290byBvdXQ7DQo+ ICAgDQo+ICAgICAgIGRzcy0+eGNmbGFncyA9IChsaXZlID8gWENGTEFHU19MSVZFIDogMCkN Cj4gLSAgICAgICAgICB8IChkZWJ1ZyA/IFhDRkxBR1NfREVCVUcgOiAwKTsNCj4gKyAgICAg ICAgICB8IChkZWJ1ZyA/IFhDRkxBR1NfREVCVUcgOiAwKQ0KPiArICAgICAgICAgIHwgKGNv bXByZXNzX2x6NCA/IFhDRkxBR1NfQ09NUFJFU1NfTFo0IDogMCk7DQo+ICAgDQo+ICAgICAg IC8qIERpc2FsbG93IHNhdmluZyBhIGd1ZXN0IHdpdGggdk5VTUEgY29uZmlndXJlZCBiZWNh dXNlIG1pZ3JhdGlvbg0KPiAgICAgICAgKiBzdHJlYW0gZG9lcyBub3QgcHJlc2VydmUgbm9k ZSBpbmZvcm1hdGlvbi4NCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxf ZG9tYWluLmMgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2RvbWFpbi5jDQo+IGluZGV4IDM3 ZmNkOTI4NzEuLjg2NDU4YTY5YzAgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnMvbGlnaHQv bGlieGxfZG9tYWluLmMNCj4gKysrIGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF9kb21haW4u Yw0KPiBAQCAtNTI3LDYgKzUyNyw3IEBAIGludCBsaWJ4bF9kb21haW5fc3VzcGVuZChsaWJ4 bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsIGludCBmZCwgaW50IGZsYWdzLA0KPiAgICAg ICBkc3MtPnR5cGUgPSB0eXBlOw0KPiAgICAgICBkc3MtPmxpdmUgPSBmbGFncyAmIExJQlhM X1NVU1BFTkRfTElWRTsNCj4gICAgICAgZHNzLT5kZWJ1ZyA9IGZsYWdzICYgTElCWExfU1VT UEVORF9ERUJVRzsNCj4gKyAgICBkc3MtPmNvbXByZXNzX2x6NCA9IGZsYWdzICYgTElCWExf U1VTUEVORF9DT01QUkVTU19MWjQ7DQo+ICAgICAgIGRzcy0+Y2hlY2twb2ludGVkX3N0cmVh bSA9IExJQlhMX0NIRUNLUE9JTlRFRF9TVFJFQU1fTk9ORTsNCj4gICANCj4gICAgICAgcmMg PSBsaWJ4bF9fZmRfZmxhZ3NfbW9kaWZ5X3NhdmUoZ2MsIGRzcy0+ZmQsDQo+IGRpZmYgLS1n aXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2ludGVybmFsLmggYi90b29scy9saWJzL2xp Z2h0L2xpYnhsX2ludGVybmFsLmgNCj4gaW5kZXggYjY1ZTAwNjRiOS4uZmY3YTMzNDUwMSAx MDA2NDQNCj4gLS0tIGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF9pbnRlcm5hbC5oDQo+ICsr KyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfaW50ZXJuYWwuaA0KPiBAQCAtMzU5OCw2ICsz NTk4LDcgQEAgc3RydWN0IGxpYnhsX19kb21haW5fc2F2ZV9zdGF0ZSB7DQo+ICAgICAgIGxp YnhsX2RvbWFpbl90eXBlIHR5cGU7DQo+ICAgICAgIGludCBsaXZlOw0KPiAgICAgICBpbnQg ZGVidWc7DQo+ICsgICAgaW50IGNvbXByZXNzX2x6NDsNCj4gICAgICAgaW50IGNoZWNrcG9p bnRlZF9zdHJlYW07DQo+ICAgICAgIGNvbnN0IGxpYnhsX2RvbWFpbl9yZW11c19pbmZvICpy ZW11czsNCj4gICAgICAgLyogcHJpdmF0ZSAqLw0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMveGwv eGxfY21kdGFibGUuYyBiL3Rvb2xzL3hsL3hsX2NtZHRhYmxlLmMNCj4gaW5kZXggZTQ4ZDVj NWVkYy4uYWFkY2EyM2E3NyAxMDA2NDQNCj4gLS0tIGEvdG9vbHMveGwveGxfY21kdGFibGUu Yw0KPiArKysgYi90b29scy94bC94bF9jbWR0YWJsZS5jDQo+IEBAIC0xNzQsNiArMTc0LDgg QEAgY29uc3Qgc3RydWN0IGNtZF9zcGVjIGNtZF90YWJsZVtdID0gew0KPiAgICAgICAgICIt ZSAgICAgICAgICAgICAgRG8gbm90IHdhaXQgaW4gdGhlIGJhY2tncm91bmQgKG9uIDxob3N0 PikgZm9yIHRoZSBkZWF0aFxuIg0KPiAgICAgICAgICIgICAgICAgICAgICAgICAgb2YgdGhl IGRvbWFpbi5cbiINCj4gICAgICAgICAiLS1kZWJ1ZyAgICAgICAgIFByaW50IGh1Z2UgKCEp IGFtb3VudCBvZiBkZWJ1ZyBkdXJpbmcgdGhlIG1pZ3JhdGlvbiBwcm9jZXNzLlxuIg0KPiAr ICAgICAgIi0tY29tcHJlc3MgICAgICBDb21wcmVzcyB0aGUgbWVtb3J5IHN0cmVhbSB1c2lu ZyBMWjQgaW4gbGlieGVuZ3Vlc3QuXG4iDQo+ICsgICAgICAiICAgICAgICAgICAgICAgIFJl cXVpcmVzIGxpYmx6NCBzdXBwb3J0IGluIGxpYnhlbmd1ZXN0IG9uIGJvdGggaG9zdHMuXG4i DQo+ICAgICAgICAgIi1wICAgICAgICAgICAgICBEbyBub3QgdW5wYXVzZSBkb21haW4gYWZ0 ZXIgbWlncmF0aW5nIGl0LlxuIg0KPiAgICAgICAgICItRCAgICAgICAgICAgICAgUHJlc2Vy dmUgdGhlIGRvbWFpbiBpZCINCj4gICAgICAgfSwNCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hs L3hsX21pZ3JhdGUuYyBiL3Rvb2xzL3hsL3hsX21pZ3JhdGUuYw0KPiBpbmRleCA0YjRhMzc5 YWExLi4zMWE4Y2I0ZjMyIDEwMDY0NA0KPiAtLS0gYS90b29scy94bC94bF9taWdyYXRlLmMN Cj4gKysrIGIvdG9vbHMveGwveGxfbWlncmF0ZS5jDQo+IEBAIC0xNzcsNyArMTc3LDcgQEAg c3RhdGljIHZvaWQgbWlncmF0ZV9kb19wcmVhbWJsZShpbnQgc2VuZF9mZCwgaW50IHJlY3Zf ZmQsIHBpZF90IGNoaWxkLA0KPiAgIH0NCj4gICANCj4gICBzdGF0aWMgdm9pZCBtaWdyYXRl X2RvbWFpbih1aW50MzJfdCBkb21pZCwgaW50IHByZXNlcnZlX2RvbWlkLA0KPiAtICAgICAg ICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqcnVuZSwgaW50IGRlYnVnLA0KPiAr ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqcnVuZSwgaW50IGRlYnVn LCBpbnQgY29tcHJlc3NfbHo0LA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bnN0IGNoYXIgKm92ZXJyaWRlX2NvbmZpZ19maWxlKQ0KPiAgIHsNCj4gICAgICAgcGlkX3Qg Y2hpbGQgPSAtMTsNCj4gQEAgLTIwNiw2ICsyMDYsOCBAQCBzdGF0aWMgdm9pZCBtaWdyYXRl X2RvbWFpbih1aW50MzJfdCBkb21pZCwgaW50IHByZXNlcnZlX2RvbWlkLA0KPiAgIA0KPiAg ICAgICBpZiAoZGVidWcpDQo+ICAgICAgICAgICBmbGFncyB8PSBMSUJYTF9TVVNQRU5EX0RF QlVHOw0KPiArICAgIGlmIChjb21wcmVzc19sejQpDQo+ICsgICAgICAgIGZsYWdzIHw9IExJ QlhMX1NVU1BFTkRfQ09NUFJFU1NfTFo0Ow0KPiAgICAgICByYyA9IGxpYnhsX2RvbWFpbl9z dXNwZW5kKGN0eCwgZG9taWQsIHNlbmRfZmQsIGZsYWdzLCBOVUxMKTsNCj4gICAgICAgaWYg KHJjKSB7DQo+ICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIm1pZ3JhdGlvbiBzZW5kZXI6 IGxpYnhsX2RvbWFpbl9zdXNwZW5kIGZhaWxlZCINCj4gQEAgLTUzOCwxMCArNTQwLDExIEBA IGludCBtYWluX21pZ3JhdGUoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQ0KPiAgICAgICBjaGFy ICpydW5lID0gTlVMTDsNCj4gICAgICAgY2hhciAqaG9zdDsNCj4gICAgICAgaW50IG9wdCwg ZGFlbW9uaXplID0gMSwgbW9uaXRvciA9IDEsIGRlYnVnID0gMCwgcGF1c2VfYWZ0ZXJfbWln cmF0aW9uID0gMDsNCj4gLSAgICBpbnQgcHJlc2VydmVfZG9taWQgPSAwOw0KPiArICAgIGlu dCBwcmVzZXJ2ZV9kb21pZCA9IDAsIGNvbXByZXNzX2x6NCA9IDA7DQo+ICAgICAgIHN0YXRp YyBzdHJ1Y3Qgb3B0aW9uIG9wdHNbXSA9IHsNCj4gICAgICAgICAgIHsiZGVidWciLCAwLCAw LCAweDEwMH0sDQo+ICAgICAgICAgICB7ImxpdmUiLCAwLCAwLCAweDIwMH0sDQo+ICsgICAg ICAgIHsiY29tcHJlc3MiLCAwLCAwLCAweDMwMH0sDQo+ICAgICAgICAgICBDT01NT05fTE9O R19PUFRTDQo+ICAgICAgIH07DQo+ICAgDQo+IEBAIC01NzEsNiArNTc0LDkgQEAgaW50IG1h aW5fbWlncmF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQo+ICAgICAgIGNhc2UgMHgyMDA6 IC8qIC0tbGl2ZSAqLw0KPiAgICAgICAgICAgLyogaWdub3JlZCBmb3IgY29tcGF0aWJpbGl0 eSB3aXRoIHhtICovDQo+ICAgICAgICAgICBicmVhazsNCj4gKyAgICBjYXNlIDB4MzAwOiAv KiAtLWNvbXByZXNzICovDQo+ICsgICAgICAgIGNvbXByZXNzX2x6NCA9IDE7DQo+ICsgICAg ICAgIGJyZWFrOw0KPiAgICAgICB9DQo+ICAgDQo+ICAgICAgIGRvbWlkID0gZmluZF9kb21h aW4oYXJndltvcHRpbmRdKTsNCj4gQEAgLTYwMiw3ICs2MDgsOCBAQCBpbnQgbWFpbl9taWdy YXRlKGludCBhcmdjLCBjaGFyICoqYXJndikNCj4gICAgICAgICAgICAgICAgICAgICBwYXVz ZV9hZnRlcl9taWdyYXRpb24gPyAiIC1wIiA6ICIiKTsNCj4gICAgICAgfQ0KPiAgIA0KPiAt ICAgIG1pZ3JhdGVfZG9tYWluKGRvbWlkLCBwcmVzZXJ2ZV9kb21pZCwgcnVuZSwgZGVidWcs IGNvbmZpZ19maWxlbmFtZSk7DQo+ICsgICAgbWlncmF0ZV9kb21haW4oZG9taWQsIHByZXNl cnZlX2RvbWlkLCBydW5lLCBkZWJ1ZywgY29tcHJlc3NfbHo0LA0KPiArICAgICAgICAgICAg ICAgICAgIGNvbmZpZ19maWxlbmFtZSk7DQo+ICAgICAgIHJldHVybiBFWElUX1NVQ0NFU1M7 DQo+ICAgfQ0KPiAgIA0KDQpUaGUgcmVzdCBsb29rcyBnb29kIHRvIG1lLg0KDQpUZWRkeQ0K --------------JIIv7xp30jc1abRiF1bZWtsB-- --------------U4bQ90ZdlRpTAVQCjeBnXCVc 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+p0QLLz9AFAmrjLHYFAwAAAAAACgkQZg+p0QLLz9Ba eAv/cDGMbIfDDRAeUYZ5je+M+sP8rmLvzDuNrFpUfMu1emX1r9nTyQMTauXuo3LaRR5b10GSVtq3 6ASHJdKx93XEQ/SDAo992mUuM+r5Ok5KytuaXrm1wfNgUHorMbXlbnQutRKVqekFTyCezHIFf4qe at/ZokAA7p0viqtqTqkOFlwdyIlzDv9KGhrK2dShHZCXMUA0ekGnO1FqAZh9YpZMO9pkQ6wcjqQb c60Evuw1NdrdHLTMmZrLVuV12lcokZVstnijiil93/zkxWEsVMT2bwD0oq3g7Ey71n/WQAcwiKHa +Q5yL7vGmxayjf+OKB+w2kiKUYu9BlNDyNDWb+WO+iTJoDoSvbjT1y5wv5q9D1JtXHA9cxTNNWvk CxsmrBtg//TF4bih0AaEw40ZShyt0R2ju7JzyFcmXzDNwkqKe5wosQhQe8GD35F41G0JvM9p3URD ORMp2eG0hXYRY6JD1fGqcf99igCP9zQ+YCoNFgeI0yTGI8d+y73t6ocS4yTp =ClwK -----END PGP SIGNATURE----- --------------U4bQ90ZdlRpTAVQCjeBnXCVc-- From xen-devel-bounces@lists.xenproject.org Thu Oct 29 11:39:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 11:39:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464476.1675162 (Exim 4.92) (envelope-from ) id 1xMOTq-0002Am-2c; Thu, 29 Oct 2026 11:39:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464476.1675162; Thu, 29 Oct 2026 11: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 1xMOTp-0002Af-VU; Thu, 29 Oct 2026 11:39:37 +0000 Received: by outflank-mailman (input) for mailman id 1464476; Thu, 29 Oct 2026 11:39:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMOTo-0002AJ-TI for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:39:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMOTo-00DJdt-2D for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:39:36 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3306c-8faa-0a2a0a5109dd-0a2a450885c2-28 for ; Thu, 29 Oct 2026 12:39:36 +0100 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 6ae33077-f659-0a2a45080019-b9ff1c239941-3 for ; Thu, 29 Oct 2026 12:39:35 +0100 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 1a1877542ec000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 11:39:31 +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 A28D3823B2; Thu, 29 Oct 2026 12:39:30 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=sFw43ygO0Ba0+1MA4xkq0wjWAeTwwsYe3hp903H8lVk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ZFSL/sOhXjFukGSGdlflHdbOziaYBKs375N8N8CuAkH3R989EBcn+Y+srAstmPVBDiNwBEk16 UZuNQzFbOtNcG+jHuAFM1GdBrB/XNuEkvb0qjgJKD3X9srNnLr2H97la8Uan17pXkwxfuSK2VaR KTx0AFNUH0q46/4jWfpkgJ+sASn8qiELUvQWmA3WsV6zKglnqHoCF4BufR/Adx146ujpkLa603n YD1jeteZzpEe0fHdv6KT3/5tBO/1NQ7hEbjOBB7fJBYEwIepiOlCtWYy/OvQ1W52bMNOeo3VM0U PWNJgav1+rAahEmcO7C35279t0HrcDTt3Uch431TZ4Pw== X-Zone-Loop: 8c6ce0db419659f0baa813c5a374eddf123831a6c31a x-campaign-type: default x-transaction-id: a80955d7-3523-4a96-94f4-fe04a13f2246 x-swg-uid: 01-3dfa6b38-1436-4c19-86c2-66657e6b8d67 X-Mailer: Sweego Message-ID: <1793273971.8631fc262581453bbf619ec5b2062170.1a1877542ec000f79f@vates.tech> x-swg-bid: 1793273971.8631fc262581453bbf619ec5b2062170.1a1877542ec000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 29 Oct 2026 12:39:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 8/9] tools/xl: mark LZ4 migration streams with a mandatory header flag To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-9-marcus.granado@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: <20261020200238.1815766-9-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------hMJPEppig20wr6FkEqHOsPMn" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793273970827 X-purgate-ID: tlsNG-c1860d/1793273976-DF6D687B-9E75454A/0/0 X-purgate-type: clean X-purgate-size: 13196 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hMJPEppig20wr6FkEqHOsPMn Content-Type: multipart/mixed; boundary="------------fSTSSJ0ULNwrrfeKCmlF9j4m"; protected-headers="v1"; hp="clear" Message-ID: Date: Thu, 29 Oct 2026 12:39:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 8/9] tools/xl: mark LZ4 migration streams with a mandatory header flag To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-9-marcus.granado@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: <20261020200238.1815766-9-marcus.granado@citrix.com> --------------fSTSSJ0ULNwrrfeKCmlF9j4m Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowNiwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g QSByZWNlaXZlciB3aGljaCBjYW5ub3QgZGVjb21wcmVzcyBMWjQgcmVqZWN0cyB0aGUgZmly c3QgY29tcHJlc3NlZA0KPiBQQUdFX0RBVEEgcmVjb3JkLiAgVGhhdCBpcyBsYXRlOiB0aGUg cmVjZWl2ZXIgaGFzIGFscmVhZHkgY3JlYXRlZCB0aGUNCj4gZG9tYWluLCBwcmVjb3B5IGhh cyBzdGFydGVkLCBhbmQgYW4gb2xkZXIgbGlieGVuZ3Vlc3QncyBlcnJvciBzYXlzDQo+IG5v dGhpbmcgYWJvdXQgY29tcHJlc3Npb24uDQo+IA0KPiB4bCBjYW4gZmFpbCBlYXJsaWVyLiAg SXRzIHNhdmUgZmlsZSBoZWFkZXIgY2FycmllcyBtYW5kYXRvcnlfZmxhZ3MsIGFuZA0KPiBj cmVhdGVfZG9tYWluKCkgcmVqZWN0cyB1bmtub3duIGJpdHMgYmVmb3JlIGl0IGNhbGxzDQo+ IGxpYnhsX2RvbWFpbl9jcmVhdGVfcmVzdG9yZSgpLiAgU2ltaWxhciB0byBjb21taXQgZTcy Y2UyNDRkYzkxDQo+ICgidG9vbHMveGw6IE1hbmRhdG9yeSBmbGFnIGluZGljYXRpbmcgdGhl IGZvcm1hdCBvZiB0aGUgbWlncmF0aW9uDQo+IHN0cmVhbSIpLCBjbGFpbSBiaXQgMiBmb3Ig TFo0IGFuZCBzZXQgaXQgZm9yICJ4bCBtaWdyYXRlIC0tY29tcHJlc3MiLg0KPiBBbiBvbGRl ciB4bCB0aGVuIHJlcG9ydHMgbWFuZGF0b3J5IGZsYWcgMHg0IGFzIHVuc3VwcG9ydGVkIGFu ZCBjcmVhdGVzDQo+IG5vIGRvbWFpbi4NCj4gDQo+IFRoaXMgaXMgZGVmZW5jZSBpbiBkZXB0 aCwgZm9yIHhsLXRvLXhsIG1pZ3JhdGlvbiBvbmx5LiAgQW4geGwgd2hpY2gNCj4ga25vd3Mg dGhlIGZsYWcgYnV0IHdob3NlIGxpYnhlbmd1ZXN0IGxhY2tzIGxpYmx6NCBzdGlsbCBhY2Nl cHRzIHRoZQ0KPiBoZWFkZXIgYW5kIGZhaWxzIGxhdGUsIGF0IHRoZSBmaXJzdCBjb21wcmVz c2VkIFBBR0VfREFUQSByZWNvcmQsIHRob3VnaA0KPiB3aXRoIGFuIGVycm9yIHRoYXQgbmFt ZXMgTFo0LiAgVGhlIGhlYWRlciBpcyB3cml0dGVuIGJlZm9yZSBhbnkgcmVjb3JkLA0KPiBz byBhIHN0cmVhbSBpbiB3aGljaCBubyByZWNvcmQgZW5kcyB1cCBjb21wcmVzc2VkIHN0aWxs IGNhcnJpZXMgdGhlDQo+IGZsYWcgYW5kIG5lZWRzIGFuIExaNC1hd2FyZSB4bC4NCj4gDQo+ IEFzc2lzdGVkLWJ5OiBDbGF1ZGU6Y2xhdWRlLW9wdXMtNS01DQo+IFNpZ25lZC1vZmYtYnk6 IE1hcmN1cyBHcmFuYWRvIDxtYXJjdXMuZ3JhbmFkb0BjaXRyaXguY29tPg0KPiAtLS0NCg0K SSB0aGluayBpdCB3b3VsZCBiZSBwcmVmZXJhYmxlIHRvIGNoZWNrIGZvciBsaWJ4ZW5ndWVz dCBsejQgc3VwcG9ydCBhcyANCndlbGwsIHNvIHRoYXQgbGlieGVuZ3Vlc3Qgd2l0aG91dCBs ejQgd291bGQgZmFpbCB0aGUgc2FtZSB3YXkgYXMgDQpsaWJ4ZW5ndWVzdCBwcmlvciB0byB0 aGlzIHBhdGNoLg0KDQo+IA0KPiBOb3RlczoNCj4gICAgICBDaGFuZ2VzIGluIHYyOg0KPiAg ICAgIC0gTmV3LCBhZnRlciBhbiBvZmYtbGlzdCBxdWVzdGlvbiBmcm9tIFJvc3MgTGFnZXJ3 YWxsOiBhbiBvbGRlciB4bA0KPiAgICAgICAgbm93IHJlZnVzZXMgYSBjb21wcmVzc2VkIHN0 cmVhbSBiZWZvcmUgaXQgY3JlYXRlcyB0aGUgZG9tYWluLg0KPiANCj4gICB0b29scy94bC94 bC5oICAgICAgICAgICAgIHwgNyArKysrKy0tDQo+ICAgdG9vbHMveGwveGxfbWlncmF0ZS5j ICAgICB8IDggKysrKy0tLS0NCj4gICB0b29scy94bC94bF9zYXZlcmVzdG9yZS5jIHwgNyAr KysrKy0tDQo+ICAgMyBmaWxlcyBjaGFuZ2VkLCAxNCBpbnNlcnRpb25zKCspLCA4IGRlbGV0 aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hsL3hsLmggYi90b29scy94bC94 bC5oDQo+IGluZGV4IDdiNzVmOWE0OTMuLjAwOWNiZDFjM2MgMTAwNjQ0DQo+IC0tLSBhL3Rv b2xzL3hsL3hsLmgNCj4gKysrIGIvdG9vbHMveGwveGwuaA0KPiBAQCAtNzcsOCArNzcsMTAg QEAgc3RhdGljIGNvbnN0IGNoYXIgbWlncmF0ZV9yZXBvcnRbXT0NCj4gICANCj4gICAjZGVm aW5lIFhMX01BTkRBVE9SWV9GTEFHX0pTT04gKDFVIDw8IDApIC8qIGNvbmZpZyBkYXRhIGlz IGluIEpTT04gZm9ybWF0ICovDQo+ICAgI2RlZmluZSBYTF9NQU5EQVRPUllfRkxBR19TVFJF QU12MiAoMVUgPDwgMSkgLyogc3RyZWFtIGlzIHYyICovDQo+ICsjZGVmaW5lIFhMX01BTkRB VE9SWV9GTEFHX0NPTVBSRVNTX0xaNCAoMVUgPDwgMikgLyogUEFHRV9EQVRBIG1heSB1c2Ug TFo0ICovDQo+ICAgI2RlZmluZSBYTF9NQU5EQVRPUllfRkxBR19BTEwgIChYTF9NQU5EQVRP UllfRkxBR19KU09OIHwgICAgICAgIFwNCj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgWExfTUFOREFUT1JZX0ZMQUdfU1RSRUFNdjIpDQo+ICsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFhMX01BTkRBVE9SWV9GTEFHX1NUUkVBTXYyIHwgICAgXA0KPiAr ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYTF9NQU5EQVRPUllfRkxBR19DT01Q UkVTU19MWjQpDQo+ICAgDQo+ICAgc3RydWN0IHNhdmVfZmlsZV9oZWFkZXIgew0KPiAgICAg ICBjaGFyIG1hZ2ljWzMyXTsgLyogc2F2ZWZpbGVoZWFkZXJfbWFnaWMgKi8NCj4gQEAgLTEw Miw3ICsxMDQsOCBAQCB2b2lkIHNhdmVfZG9tYWluX2NvcmVfYmVnaW4odWludDMyX3QgZG9t aWQsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4X3QgKipjb25maWdf ZGF0YV9yLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgKmNvbmZpZ19s ZW5fcik7DQo+ICAgdm9pZCBzYXZlX2RvbWFpbl9jb3JlX3dyaXRlY29uZmlnKGludCBmZCwg Y29uc3QgY2hhciAqc291cmNlLA0KPiAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbnN0IHVpbnQ4X3QgKmNvbmZpZ19kYXRhLCBpbnQgY29uZmlnX2xlbik7DQo+ICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgdWludDhfdCAqY29uZmln X2RhdGEsIGludCBjb25maWdfbGVuLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGludCBjb21wcmVzc19sejQpOw0KPiAgIA0KPiAgIC8qDQo+ICAgICogVGhlIHhs IHByb2Nlc3Mgc2hvdWxkIGFsd2F5cyByZXR1cm4gZWl0aGVyIEVYSVRfU1VDQ0VTUyBvcg0K PiBkaWZmIC0tZ2l0IGEvdG9vbHMveGwveGxfbWlncmF0ZS5jIGIvdG9vbHMveGwveGxfbWln cmF0ZS5jDQo+IGluZGV4IDMxYThjYjRmMzIuLjIzMGFhYzFiNzEgMTAwNjQ0DQo+IC0tLSBh L3Rvb2xzL3hsL3hsX21pZ3JhdGUuYw0KPiArKysgYi90b29scy94bC94bF9taWdyYXRlLmMN Cj4gQEAgLTE1Myw3ICsxNTMsNyBAQCBzdGF0aWMgdm9pZCBtaWdyYXRpb25fY2hpbGRfcmVw b3J0KGludCByZWN2X2ZkKSB7DQo+ICAgDQo+ICAgc3RhdGljIHZvaWQgbWlncmF0ZV9kb19w cmVhbWJsZShpbnQgc2VuZF9mZCwgaW50IHJlY3ZfZmQsIHBpZF90IGNoaWxkLA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDhfdCAqY29uZmlnX2RhdGEsIGlu dCBjb25maWdfbGVuLA0KPiAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z dCBjaGFyICpydW5lKQ0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z dCBjaGFyICpydW5lLCBpbnQgY29tcHJlc3NfbHo0KQ0KPiAgIHsNCj4gICAgICAgaW50IHJj ID0gMDsNCj4gICANCj4gQEAgLTE3Miw3ICsxNzIsNyBAQCBzdGF0aWMgdm9pZCBtaWdyYXRl X2RvX3ByZWFtYmxlKGludCBzZW5kX2ZkLCBpbnQgcmVjdl9mZCwgcGlkX3QgY2hpbGQsDQo+ ICAgICAgIH0NCj4gICANCj4gICAgICAgc2F2ZV9kb21haW5fY29yZV93cml0ZWNvbmZpZyhz ZW5kX2ZkLCAibWlncmF0aW9uIHN0cmVhbSIsDQo+IC0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjb25maWdfZGF0YSwgY29uZmlnX2xlbik7DQo+ICsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25maWdfZGF0YSwgY29uZmlnX2xlbiwgY29tcHJlc3Nf bHo0KTsNCj4gICANCj4gICB9DQo+ICAgDQo+IEBAIC0yMDAsNyArMjAwLDcgQEAgc3RhdGlj IHZvaWQgbWlncmF0ZV9kb21haW4odWludDMyX3QgZG9taWQsIGludCBwcmVzZXJ2ZV9kb21p ZCwNCj4gICAgICAgY2hpbGQgPSBjcmVhdGVfbWlncmF0aW9uX2NoaWxkKHJ1bmUsICZzZW5k X2ZkLCAmcmVjdl9mZCk7DQo+ICAgDQo+ICAgICAgIG1pZ3JhdGVfZG9fcHJlYW1ibGUoc2Vu ZF9mZCwgcmVjdl9mZCwgY2hpbGQsIGNvbmZpZ19kYXRhLCBjb25maWdfbGVuLA0KPiAtICAg ICAgICAgICAgICAgICAgICAgICAgcnVuZSk7DQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICBydW5lLCBjb21wcmVzc19sejQpOw0KPiAgIA0KPiAgICAgICB4dGxfc3RkaW9zdHJlYW1f YWRqdXN0X2ZsYWdzKGxvZ2dlciwgWFRMX1NURElPU1RSRUFNX0hJREVfUFJPR1JFU1MsIDAp Ow0KPiAgIA0KPiBAQCAtNzQwLDcgKzc0MCw3IEBAIGludCBtYWluX3JlbXVzKGludCBhcmdj LCBjaGFyICoqYXJndikNCj4gICAgICAgICAgIGNoaWxkID0gY3JlYXRlX21pZ3JhdGlvbl9j aGlsZChydW5lLCAmc2VuZF9mZCwgJnJlY3ZfZmQpOw0KPiAgIA0KPiAgICAgICAgICAgbWln cmF0ZV9kb19wcmVhbWJsZShzZW5kX2ZkLCByZWN2X2ZkLCBjaGlsZCwgY29uZmlnX2RhdGEs IGNvbmZpZ19sZW4sDQo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVuZSk7DQo+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVuZSwgMCk7DQo+ICAgDQo+ICAgICAg ICAgICBpZiAoc3NoX2NvbW1hbmRbMF0pDQo+ICAgICAgICAgICAgICAgZnJlZShydW5lKTsN Cj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hsL3hsX3NhdmVyZXN0b3JlLmMgYi90b29scy94bC94 bF9zYXZlcmVzdG9yZS5jDQo+IGluZGV4IDc0NzA5NGVjN2IuLjUxNTFjOGExMzAgMTAwNjQ0 DQo+IC0tLSBhL3Rvb2xzL3hsL3hsX3NhdmVyZXN0b3JlLmMNCj4gKysrIGIvdG9vbHMveGwv eGxfc2F2ZXJlc3RvcmUuYw0KPiBAQCAtNzksNyArNzksOCBAQCB2b2lkIHNhdmVfZG9tYWlu X2NvcmVfYmVnaW4odWludDMyX3QgZG9taWQsDQo+ICAgfQ0KPiAgIA0KPiAgIHZvaWQgc2F2 ZV9kb21haW5fY29yZV93cml0ZWNvbmZpZyhpbnQgZmQsIGNvbnN0IGNoYXIgKnNvdXJjZSwN Cj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1aW50OF90ICpj b25maWdfZGF0YSwgaW50IGNvbmZpZ19sZW4pDQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3QgdWludDhfdCAqY29uZmlnX2RhdGEsIGludCBjb25maWdfbGVu LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBjb21wcmVzc19s ejQpDQo+ICAgew0KPiAgICAgICBzdHJ1Y3Qgc2F2ZV9maWxlX2hlYWRlciBoZHI7DQo+ICAg ICAgIHVpbnQ4X3QgKm9wdGRhdGFfYmVnaW47DQo+IEBAIC04OSw2ICs5MCw4IEBAIHZvaWQg c2F2ZV9kb21haW5fY29yZV93cml0ZWNvbmZpZyhpbnQgZmQsIGNvbnN0IGNoYXIgKnNvdXJj ZSwNCj4gICAgICAgbWVtY3B5KGhkci5tYWdpYywgc2F2ZWZpbGVoZWFkZXJfbWFnaWMsIHNp emVvZihoZHIubWFnaWMpKTsNCj4gICAgICAgaGRyLmJ5dGVvcmRlciA9IFNBVkVGSUxFX0JZ VEVPUkRFUl9WQUxVRTsNCj4gICAgICAgaGRyLm1hbmRhdG9yeV9mbGFncyA9IFhMX01BTkRB VE9SWV9GTEFHX1NUUkVBTXYyOw0KPiArICAgIGlmIChjb21wcmVzc19sejQpDQo+ICsgICAg ICAgIGhkci5tYW5kYXRvcnlfZmxhZ3MgfD0gWExfTUFOREFUT1JZX0ZMQUdfQ09NUFJFU1Nf TFo0Ow0KPiAgIA0KPiAgICAgICBvcHRkYXRhX2JlZ2luPSAwOw0KPiAgIA0KPiBAQCAtMTQ0 LDcgKzE0Nyw3IEBAIHN0YXRpYyBpbnQgc2F2ZV9kb21haW4odWludDMyX3QgZG9taWQsIGlu dCBwcmVzZXJ2ZV9kb21pZCwNCj4gICAgICAgICAgIGV4aXQoRVhJVF9GQUlMVVJFKTsNCj4g ICAgICAgfQ0KPiAgIA0KPiAtICAgIHNhdmVfZG9tYWluX2NvcmVfd3JpdGVjb25maWcoZmQs IGZpbGVuYW1lLCBjb25maWdfZGF0YSwgY29uZmlnX2xlbik7DQo+ICsgICAgc2F2ZV9kb21h aW5fY29yZV93cml0ZWNvbmZpZyhmZCwgZmlsZW5hbWUsIGNvbmZpZ19kYXRhLCBjb25maWdf bGVuLCAwKTsNCj4gICANCj4gICAgICAgaW50IHJjID0gbGlieGxfZG9tYWluX3N1c3BlbmQo Y3R4LCBkb21pZCwgZmQsIDAsIE5VTEwpOw0KPiAgICAgICBjbG9zZShmZCk7DQoNCg== --------------fSTSSJ0ULNwrrfeKCmlF9j4m-- --------------hMJPEppig20wr6FkEqHOsPMn 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+p0QLLz9AFAmrjMHIFAwAAAAAACgkQZg+p0QLLz9BR vQv7BS7SW2ho9UNBCu3vSzC8f83XPVcR0X9gbf2eVM6V6gLwoXRHDcc46wbgsetgn6LOzv7YUVpj IEfsgFzxc+GOPOL0NQH85+1Mf5CJLYBE6zlVq/cVf99qI85Zl0IjKfHt6qf++m6fWRQUuTMt9KXC X/mJVrHDD3GTyaqslDEw1DW807Lk3rk1OOuV1GqZzSUrgIRsYjXCtHOP5z4r1LQb/svyAxyhAj47 QFc/nmUXhHLiYOp7Mug9Daa0QPodasmsOVb/jTfZyhklVureYt8q4iIFxb243uHIVrrvjI2bczVa DCr7B41W08KtZO7YkuHvtE79dzLqhJ2sjw67RI44lf/EFFBoFMI+ueenNqoHnHYlaY+DbMkbdm6q djiRyqWM56yAFNHn9e4VhnR2ZNiLQq+Bhiu7wOaoXV2U7FSU19y/F2BUwaB2SwYK0Yn0ZcN18NOS VwZLFHBmJwXJpfajJZ+2I/++PqCXTLZgoTwgvaZX0nAAhaEOaBGOU51D3qIU =DODK -----END PGP SIGNATURE----- --------------hMJPEppig20wr6FkEqHOsPMn-- From xen-devel-bounces@lists.xenproject.org Thu Oct 29 11:49:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 11:49:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464491.1675170 (Exim 4.92) (envelope-from ) id 1xMOd0-0004Dv-Sn; Thu, 29 Oct 2026 11:49:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464491.1675170; Thu, 29 Oct 2026 11:49: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 1xMOd0-0004Do-Q7; Thu, 29 Oct 2026 11:49:06 +0000 Received: by outflank-mailman (input) for mailman id 1464491; Thu, 29 Oct 2026 11:49:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMOcz-0004Di-Nk for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 11:49:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMOcz-005WxU-4U for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:49:05 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae332a9-8faa-0a2a0a5109dd-0a2a4507a7ca-20 for ; Thu, 29 Oct 2026 12:49:05 +0100 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae332b0-b4ea-0a2a45070019-d155802ce973-3 for ; Thu, 29 Oct 2026 12:49:05 +0100 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a2167bd087so20752905e9.3 for ; Thu, 29 Oct 2026 04:49:05 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-71.play-internet.pl. [109.243.67.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4aa7c1302f6sm67567015e9.0.2026.10.29.04.49.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 04:49: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=20260707 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=20260707; t=1793274544; x=1793879344; 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=639132pkPLJu3/vww6AhkK7GPJGA7ALyC+zuXl1Ajyg=; b=xCxhy1SrgztfQKTaowTze5thZKYHzjuHJdM1ZSz3sJ2faqmrPSnKTLby5B5MpsQCVx B2V6Ot+O6vXITMgPQj9wKsnzjE/EmaiJoEc+tydyipHf+czSNDzJf9FCnO/eh6GKCM0F VQ4GynQjc34cUDyNOLcv6d3EC/cXX9r96VkXdI2sITXmfbyZMes0slssT79H8Ph1xjDg rNT+grqUqpEoHgjuXTSvE2YhfiaknCGBW183ebHraZSDgjeAkvvyWLXZxPfA4h7nf471 c+zZJNM9cy5/2CFmZeW9usfE9o9F0NSeprW/jCNvhSjdhrTFXxXONTpBu5pfeI6k02h0 VSnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793274544; x=1793879344; 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=639132pkPLJu3/vww6AhkK7GPJGA7ALyC+zuXl1Ajyg=; b=ihXInxlf54BMGG5xpyjkknyFhcq77AyD74DPDAn5zFySsxEPS5xDzyBDJjd8EEFYR8 Kx0lzc1J2CGSBtCb5tZ4tK2UjXWAUzD0SpKUndwT1DO3mfj/3m+9TYZGx4ZxB8iCTYnR ++2b9bEIvdTSvBlVTEq34tJ9yG96YAb1WLhbg5i9Qu49kCmcU12X9Elb/hO+Yqkxur50 wqrjuA/mAuQeTWUxTZdByMxDlzQWfIBRcK80clRigFRkNNjdt43df8cxqmIwBJCWMQ/U nLC7PvybrC2L3ZwowxoJJtfPCQgrtipuEP34EGBJZqclWasFoSYvRGn60vZPijJJccMC iDCg== X-Forwarded-Encrypted: i=1; AKwUvByswuxUEeZd/EKjx0mLSxkXmLjKVzi5/r/wxfF1Cq+oPpLmB6BGM7kOf0HSxZXnRuHocrBcn36sbUU=@lists.xenproject.org X-Gm-Message-State: AFq9FYJTehQpWcbwALopArmY3Z+BeYiA7pwBBhIcZzj7z23Tgey/Csnt hhs4iHCN6j3JQwV5ttyvM/l5T4STAH8IcD9PTZTrdmDUN+jFQioU0AOV X-Gm-Gg: AYBFou0t7/TqGf57wy1fCHThQqCsFH9C5YTCfxJ23XZIkweBiI+4P4AebSMmQMUxTRn tZ2G0g4eRp0auiORtdNOJCsZnvYXtTt49ZKijdO/zjPZT/xUcrTHsvc1KF05YVd8y5tjZT2P8CF vicwEoevhdyQ4sp48dB1vg+LfFiLrwpvsBDganP93jT6hMZZqDlPnYlDS1rs6yJce8JGjRIpqbU MzjA8nY2PBZoJQ2CGI6f1VUmFnmhreNZrI0rdpqsbNLiXvQYFIBlneDuolInN18hgacKF66SlVy oQqcXMOaFd7DZyBq6D2buyUo7qQ5MevHzRD5iA3ud/DaBDsKruTT7x7Mn9/iG2FYD6u8IDUaOJX JBPG7ADlV/iVsZMx9NnEVfk3fk6LsVK5a4fiuguzRGvZ4c4SpCa1wNPkzBqcLmsGi1MxkvK+ZSP amc/maYibnfw1YU0QZGsgApQ5ix2Wx9xUsG+2ro0naqxrXSs/VR/Vh/X1wWyUHN5+dTzK4VMY+o 2fKE7PCBY5meG9GGgGqubd1gRg9+OOsZa6cH3/Q8NBiZ17oKGgx18MCqM+he31zkvxo/qZqOUXf eC3KOtwM1ZNAz0D538QGt9FC12mPrBH+qQzDPVcRboBDTMhs3XJmucRHzAX83DPSa3Rpv5OHUPJ M2Q== X-Received: by 2002:a05:600c:1f93:b0:4a1:6517:ccf1 with SMTP id 5b1f17b1804b1-4a9663997dfmr113046155e9.9.1793274544417; Thu, 29 Oct 2026 04:49:04 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 12:49:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/dt: Don't advertise Xen static-heap region to hwdom To: Michal Orzel , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis References: <20261029104305.169036-1-michal.orzel@amd.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20261029104305.169036-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1793274545-346CAAE4-C92B583A/10/73395122804 X-purgate-type: spam X-purgate-size: 956 On 10/29/26 11:43 AM, Michal Orzel wrote: > bootinfo.reserved_mem is used to store different types of memory that > Xen considers as reserved: domU static mem, normal /reserved-memory, > FDT memreserve and Xen static heap. make_memory_node(), invoked during > FDT generation for a hwdom for reserved memory, only skips the domU > static memory and FDT memreserve. This results in advertising Xen static > heap (if used) to a hwdom as /memory. This memory is not mapped in P2M > and guest attempt to access it fails. Interestingly, if the > /reserved-memory node is placed after /chosen, there is no problem because > of the check at the beginning of make_memory_node() that finds the first > memory range using the correct type.> > Fixes: 4596329291f5 ("docs, xen/arm: Introduce static heap memory") > Signed-off-by: Michal Orzel LGTM: Reviewed-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Oct 29 12:20:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 12:20:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464517.1675180 (Exim 4.92) (envelope-from ) id 1xMP6t-00026e-81; Thu, 29 Oct 2026 12:19:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464517.1675180; Thu, 29 Oct 2026 12: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 1xMP6t-00026X-5K; Thu, 29 Oct 2026 12:19:59 +0000 Received: by outflank-mailman (input) for mailman id 1464517; Thu, 29 Oct 2026 12:19:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMP6r-00026R-EX for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:19:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMP6q-00H7wz-Jt for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 13:19:56 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae339da-2eae-0a2a0a5409dd-0a2a4509d346-38 for ; Thu, 29 Oct 2026 13:19:56 +0100 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 6ae339eb-be1a-0a2a45090019-b9ff1c238c99-3 for ; Thu, 29 Oct 2026 13:19:56 +0100 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 1a1879a379e000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 12:19:53 +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 58FEE8032A; Thu, 29 Oct 2026 13:19:52 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=WA57kPg/+t7JRzP9I9VdXVDX7/7pZmSjneJPoBTMMVY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=YNQsOHXRsV7G165W+btyvqSx93Ymn0IO6YaKTb09qrDEmlfN8KAGqlpzAkwmEq4sWRlOhCiOH I3miOcqiDDJhOyGHJBph8HX18V8ptf9E11McVZYJC7+IBw6k+YG09oJiXKQ81Jv9jA8LfOfnXY+ U2iGFDUtd2aeejd65RO3xfx6FJi6vausuGeVgIb8vkOBo7V673YwG6lnnxIeSEax2JsRWaPqi4V xiEGesynjn+EkiSKfKBLk0LWTyx5z+mOnYXAG7c9/V4MRGs8GReftv0rwerdhRIzUtjNxweH2W3 6IxYlOUtMpd9nK0isYjymHfrm4eYReTK6qMYWapmb2yQ== X-Zone-Loop: d7901c3c48bfe8debe673b13dfa2cc81dacbbf30e510 x-campaign-type: default x-transaction-id: 27177433-5963-47aa-9cec-8dbcbe0eeb33 x-swg-uid: 01-4e502ae1-9bc3-4055-80b9-8d21fee9a397 X-Mailer: Sweego Message-ID: <1793276393.8631fc262581453bbf619ec5b2062170.1a1879a379e000f79f@vates.tech> x-swg-bid: 1793276393.8631fc262581453bbf619ec5b2062170.1a1879a379e000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 29 Oct 2026 13:19:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 9/9] tools/libs/guest: compress the PAGE_DATA pfn array too To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-10-marcus.granado@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: <20261020200238.1815766-10-marcus.granado@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------dcO9JO7r0YNu0VoWenQeFcHl" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793276392546 X-purgate-ID: tlsNG-bad1c0/1793276396-BDEC6034-9DB2258A/0/0 X-purgate-type: clean X-purgate-size: 46927 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------dcO9JO7r0YNu0VoWenQeFcHl Content-Type: multipart/mixed; boundary="------------W15pEi6wuN509Z44wy00nuHv"; protected-headers="v1"; hp="clear" Message-ID: <2ac4b0af-d907-421c-b5ea-f65e9d44b186@vates.tech> Date: Thu, 29 Oct 2026 13:19:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 9/9] tools/libs/guest: compress the PAGE_DATA pfn array too To: Marcus Granado , xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Frediano Ziglio , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20261020200238.1815766-1-marcus.granado@citrix.com> <20261020200238.1815766-10-marcus.granado@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: <20261020200238.1815766-10-marcus.granado@citrix.com> --------------W15pEi6wuN509Z44wy00nuHv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMTAvMjAyNiDDoCAyMjowOSwgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g QW4gTFo0IFBBR0VfREFUQSByZWNvcmQgY29tcHJlc3NlcyBvbmx5IGl0cyBwYWdlIGRhdGEu ICBJdHMgcGZuIGFycmF5LA0KPiA4IGJ5dGVzIHBlciBwYWdlLCBzdGlsbCB0cmF2ZWxzIGlu IHBsYWludGV4dCBhaGVhZCBvZiB0aGUgZnJhbWUuDQo+IA0KPiBEZWZpbmUgYml0IDggb2Yg dGhlIGZsYWdzIGZpZWxkOiB0aGUgcGZuIGFycmF5IGlzIGNvbXByZXNzZWQgdG9vLCB3aXRo DQo+IHRoZSByZWNvcmQncyBhbGdvcml0aG0sIGFzIGEgZnJhbWUgb2YgaXRzIG93biBpbW1l ZGlhdGVseSBiZWZvcmUgdGhlDQo+IHBhZ2UgZGF0YSBmcmFtZS4gIFRoYXQgbWFrZXMgaXQg ZWFzaWVyIHRvIGhhbmRsZSB0aGUgcGZucyBhbmQgdGhlIHBhZ2UNCj4gZGF0YSBzZXBhcmF0 ZWx5LCBpbiBib3RoIHRoZSBzYXZlciBhbmQgcmVzdG9yZS4gIEJpdCA4IG5lZWRzIGFuDQo+ IGFsZ29yaXRobSBvdGhlciB0aGFuIFBBR0VfREFUQV9BTEdPX05PTkUuICBGb3IgUEFHRV9E QVRBX0FMR09fTFo0IGJvdGgNCj4gZnJhbWVzIGNhcnJ5IGJsb2NrIGNoZWNrc3Vtcy4gIFRo ZSBjb3VudCBzdGF5cyBpbiBwbGFpbnRleHQsIHNvIHJlc3RvcmUNCj4gY2FuIGJvdW5kIGl0 IGJlZm9yZSBkZWNvZGluZyBhbnl0aGluZywgYW5kIGZpbmRzIHRoZSBwYWdlIGRhdGEgZnJh bWUNCj4gd2hlcmUgZGVjb2RpbmcgdGhlIHBmbiBmcmFtZSBlbmRzLiAgVGhlIHNhdmVyIHNl dHMgYml0IDggb24gZXZlcnkgYmF0Y2gNCj4gaXQgY29tcHJlc3NlcywgZXhjZXB0IHdoZW4g YSkgdGhlIHBmbiBmcmFtZSBpcyBubyBzbWFsbGVyIHRoYW4gdGhlDQo+IGFycmF5LCBzbyB3 b3VsZCBzYXZlIG5vdGhpbmcsIG9yIGIpIHRoZSBzaXplIHJ1bGUgYmVsb3cgYXBwbGllcywg Zm9yDQo+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiAgUmVzdG9yZSBkZWNvZGVzIGJvdGgg ZnJhbWVzIHdpdGggYSBuZXcgaGVscGVyLA0KPiB3aGljaCByZXNldHMgdGhlIExaNCBjb250 ZXh0IGJlZm9yZSBlYWNoIGZyYW1lLg0KPiANCj4gVGhpcyBjb21wcmVzc2VzIHRoZSB3aG9s ZSByZWNvcmQgYm9keSBhcGFydCBmcm9tIGNvdW50IGFuZCBmbGFncywgYXMNCj4gZGlzY3Vz c2VkIGluIHYxLiAgQ29tcHJlc3NpbmcgdGhlIHBmbiBhcnJheSBzYXZlcyBhIGxpdHRsZSBv biByZWFsDQo+IHRyYWZmaWM6IDAuMzMlIG9mIHRoZSBwYWdlIGRhdGEgYnl0ZXMgZm9yIGEg Y29tcHJlc3NpYmxlIDY0IEdpQiBndWVzdCwNCj4gMC4wMTYlIGZvciBhbiBpbmNvbXByZXNz aWJsZSBvbmUuDQo+IA0KDQpJJ20gbm90IHN1cmUgdG8gdW5kZXJzdGFuZC4gSXMgdGhlIHBm biBsaXN0IGNvbXByZXNzZWQgYXMgMC4zMyUgb2YgaXRzIA0KZnVsbCBzaXplLCBvciBkbyB3 ZSB3aW4gMC4zMyUgYmFuZHdpZHRoIGJ5IHBmbiBjb21wcmVzc2lvbiA/DQoNCj4gVGhlIHNp emUgcnVsZSAoYikgbWFrZXMgdGhlIHNhdmVyIHNlbmQgdGhlIHBmbiBhcnJheSBpbiBwbGFp bnRleHQgd2hlbg0KPiB0aGUgdHdvIGZyYW1lcyB0b3RhbCA4ICogY291bnQgYnl0ZXMgcGx1 cyBhIHdob2xlIG51bWJlciBvZiBwYWdlcy4gIEENCj4gcmVjZWl2ZXIgd2l0aG91dCAidG9v bHMvbGlicy9ndWVzdDogcmVqZWN0IG5vbi16ZXJvIHJlc2VydmVkIGZpZWxkcyBpbg0KPiBQ QUdFX0RBVEEiIGlnbm9yZXMgdGhlIGZsYWdzIGZpZWxkLCBzbyBpdCByZWFkcyB0aGUgZnJh bWVzIGFzIGNvdW50DQo+IHBmbnMgZm9sbG93ZWQgYnkgcGFnZSBkYXRhLiAgSXRzIGNoZWNr cyBvZiB0aG9zZSBwZm5zIG1heSBsZXQgdGhlbQ0KPiBwYXNzLCB3aGljaCBsZWF2ZXMgaXRz IGV4YWN0IGxlbmd0aCBjaGVjayBhcyB0aGUgb25seSBjZXJ0YWluDQo+IHJlamVjdGlvbiwg YW5kIHRoYXQgY2hlY2sgY291bGQgcGFzcyBhdCBleGFjdGx5IHRob3NlIHNpemVzLiAgVGhp cyBydWxlDQo+IGNhbiBiZSByZW1vdmVkIG9uY2UgZXZlcnkgcmVjZWl2ZXIgaGFzIHRoYXQg Y29tbWl0LCB3aGljaCBpcyBtYXJrZWQgZm9yDQo+IGJhY2twb3J0IHRvIDQuMTcgYW5kIGxh dGVyLiAgbGlieGVuZ3Vlc3QgZG9lcyBub3QgY2hlY2sgdGhlIHJ1bGUgb24NCj4gcmVzdG9y ZSwgYXMgdGhhdCB3b3VsZCBwcmV2ZW50IGl0IGV2ZXIgYmVpbmcgcmVtb3ZlZDsgb25seSB0 aGUgUHl0aG9uDQo+IHN0cmVhbSBjaGVja2VyIGRvZXMsIGFzIGEgdGVzdCBvZiB0aGUgc2F2 ZXIuDQo+IA0KPiBTdWdnZXN0ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz QGNpdHJpeC5jb20+DQo+IEFzc2lzdGVkLWJ5OiBDbGF1ZGU6Y2xhdWRlLW9wdXMtNS01DQo+ IFNpZ25lZC1vZmYtYnk6IE1hcmN1cyBHcmFuYWRvIDxtYXJjdXMuZ3JhbmFkb0BjaXRyaXgu Y29tPg0KPiAtLS0NCj4gDQo+IE5vdGVzOg0KPiAgICAgIENoYW5nZXMgaW4gdjI6DQo+ICAg ICAgLSBOZXcgaW4gdjIuICBBbmRyZXcgQ29vcGVyIHN1Z2dlc3RlZCB0aGUgcGZuIGFycmF5 IHRvIGJlIGNvbXByZXNzZWQNCj4gICAgICAgIHRvbzsgaW4gdjEgcmV2aWV3IEZyZWRpYW5v IFppZ2xpbyBhc2tlZCBhYm91dCBjb21wcmVzc2luZyB3aG9sZQ0KPiAgICAgICAgcmVjb3Jk cy4NCg0KQ29tcHJlc3NpbmcgdGhlIGVudGlyZSByZWNvcmQgY291bGQgYmUgc2ltcGxlciB0 aGFuIHRoZSBjdXJyZW50IGRlc2lnbi4NCldlIGFscmVhZHkgaGF2ZSB0aGUgZW50aXJlIHJl Y29yZDsgdGhhdCBjb3VsZCBoYXZlIGEgY29tcHJlc3MgY29tYmluZWQgDQpwZm4gYXJyYXkg YW5kIHBhZ2UgZGF0YSBmcmFtZShzKS4NCih0aGF0IHdvdWxkIGltcGx5IGx6NF9kZWNvbXBf YnVmIHRvIGJlIE1BWF9CQVRDSF9TSVpFICogDQooc2l6ZW9mKHVpbnQ2NF90KSArIFBBR0Vf U0laRSkgbGFyZ2UsIGluc3RlYWQgb2YgTUFYX0JBVENIX1NJWkUgKiBQQUdFX1NJWkUpDQoN ClRoZW4gdGhlIHBpcGVsaW5lIGNhbiBiZSBtYWRlIGFzIDoNCg0KSWYgY29tcHJlc3NlZCA6 DQotIGRlY29tcHJlc3MgdGhlIGVudGlyZSBwYXlsb2FkIChwZm4gbGlzdCBhbmQgcGFnZSBk YXRhIGV2ZW50dWFsbHkgYXMgYSANCnNpbmdsZSBmcmFtZSkNCg0KVGhlbiBwcm9jZXNzIGl0 IGFzIHVzdWFsICh1c2luZyB0aGUgZGVjb21wcmVzc2VkIHN0YWdpbmcgYnVmZmVyIGluc3Rl YWQpLg0KDQpUaGUgc2l6ZSBvZiB0aGUgY29tcHJlc3NlZCBwYXlsb2FkIGNhbiBhbHJlYWR5 IGJlIGRlcml2YXRlZCBmcm9tIA0KYm9keV9sZW5ndGggLSBoZWFkZXIgc2l6ZS4NCg0KVG8g bWUsIHRoYXQgbG9va3Mgc2ltcGxlciB0aGFuIHRyeWluZyB0byBzcGxpdCB0aGUgcGZuIGFy cmF5IHRvIHRoZSBwYWdlIA0KZGF0YXMuDQoNCj4gICAgICANCj4gICAgICBUZXN0ZWQ6IGJ1 aWxkcyB3aXRoIGFuZCB3aXRob3V0IGxpYmx6NDsgdGhlIFB5dGhvbiB1bml0IHRlc3RzOyBh IHJvdW5kDQo+ICAgICAgdHJpcCBvZiB0aGUgY2hhbmdlZCBzYXZlIGFuZCByZXN0b3JlIGZ1 bmN0aW9ucyB3aXRoIFhlbiBzdHViYmVkIG91dCwNCj4gICAgICB1bmRlciBBU2FuIGFuZCBV QlNhbiwgdGhyb3VnaCB1bmNvbXByZXNzZWQgcmVjb3JkcywgTFo0IHJlY29yZHMgd2l0aA0K PiAgICAgIHBsYWludGV4dCBhbmQgd2l0aCBjb21wcmVzc2VkIHBmbnMsIHRoZSBzaXplLXJ1 bGUgZmFsbGJhY2sgYW5kIG1hbGZvcm1lZA0KPiAgICAgIGJpdC04IHJlY29yZHM7IGFuZCBs aXZlIG1pZ3JhdGlvbnMgd2l0aCB4bCBtaWdyYXRlIC0tY29tcHJlc3MgLS1kZWJ1Zy4NCj4g DQo+ICAgZG9jcy9zcGVjcy9saWJ4Yy1taWdyYXRpb24tc3RyZWFtLnBhbmRvYyB8ICA1NSAr KysrKysrKy0NCj4gICB0b29scy9saWJzL2d1ZXN0L3hnX3NyX3Jlc3RvcmUuYyAgICAgICAg IHwgMTQwICsrKysrKysrKysrKysrKystLS0tLS0tDQo+ICAgdG9vbHMvbGlicy9ndWVzdC94 Z19zcl9zYXZlLmMgICAgICAgICAgICB8ICA1OSArKysrKysrKy0tDQo+ICAgdG9vbHMvbGli cy9ndWVzdC94Z19zcl9zdHJlYW1fZm9ybWF0LmggICB8ICAgOCArLQ0KPiAgIHRvb2xzL3B5 dGhvbi94ZW4vbWlncmF0aW9uL2xpYnhjLnB5ICAgICAgfCAgNDMgKysrKysrLQ0KPiAgIHRv b2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rlc3RzLnB5ICAgICAgfCAgMzkgKysrKysrLQ0K PiAgIDYgZmlsZXMgY2hhbmdlZCwgMjg0IGluc2VydGlvbnMoKyksIDYwIGRlbGV0aW9ucygt KQ0KPiANCj4gZGlmZiAtLWdpdCBhL2RvY3Mvc3BlY3MvbGlieGMtbWlncmF0aW9uLXN0cmVh bS5wYW5kb2MgYi9kb2NzL3NwZWNzL2xpYnhjLW1pZ3JhdGlvbi1zdHJlYW0ucGFuZG9jDQo+ IGluZGV4IDJkMjVlNzBlMTMuLjg2MDI4YzdkMjAgMTAwNjQ0DQo+IC0tLSBhL2RvY3Mvc3Bl Y3MvbGlieGMtbWlncmF0aW9uLXN0cmVhbS5wYW5kb2MNCj4gKysrIGIvZG9jcy9zcGVjcy9s aWJ4Yy1taWdyYXRpb24tc3RyZWFtLnBhbmRvYw0KPiBAQCAtMzI2LDcgKzMyNiw0NyBAQCBm bGFncyAgICAgICBCaXQgNy0wOiAgQWxnb3JpdGhtIHVzZWQgdG8gZW5jb2RlIHBhZ2VfZGF0 YS4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgZG9lcyBub3QgaW1wbGVtZW50LCByYXRo ZXIgdGhhbiBhdHRlbXB0aW5nIHRvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGludGVy cHJldCB0aGUgcGFnZV9kYXRhLg0KPiAgIA0KPiAtICAgICAgICAgICAgQml0IDMxLTg6IFJl c2VydmVkLiAgU2V0IHRvIHplcm8gb24gc2F2ZS4gIEEgcmVzdG9yaW5nIHNpZGUNCj4gKyAg ICAgICAgICAgIEJpdCA4OiAgICBDb21wcmVzc2VkIHBmbiBhcnJheS4gIFRoZSBwZm4gYXJy YXkgaXMNCj4gKyAgICAgICAgICAgICAgICAgICAgICBjb21wcmVzc2VkIHRvbywgd2l0aCB0 aGUgYWxnb3JpdGhtIGluIGJpdHMgNy0wLg0KPiArICAgICAgICAgICAgICAgICAgICAgIE1h eSBvbmx5IGJlIHNldCB3aGVuIGJpdHMgNy0wIGFyZSBub3QgMHgwMDsgYQ0KPiArICAgICAg ICAgICAgICAgICAgICAgIHJlc3RvcmluZyBzaWRlIG11c3QgcmVqZWN0IHRoZSByZWNvcmQg b3RoZXJ3aXNlLg0KPiArDQo+ICsgICAgICAgICAgICAgICAgICAgICAgV2hlbiBzZXQsIHRo ZSBwZm4gYXJyYXkgaXMgbm90IHByZXNlbnQgaW4NCj4gKyAgICAgICAgICAgICAgICAgICAg ICBwbGFpbnRleHQuICBUaGUgZmxhZ3MgZmllbGQgaXMgaW5zdGVhZCBmb2xsb3dlZA0KPiAr ICAgICAgICAgICAgICAgICAgICAgIGJ5IHBmbl9mcmFtZSwgd2hvc2UgZGVjb21wcmVzc2Vk IGNvbnRlbnQgaXMgdGhlDQo+ICsgICAgICAgICAgICAgICAgICAgICAgY291bnQgcGZuIGVu dHJpZXMgKGNvdW50ICogOCBvY3RldHMsIGVuY29kZWQgYXMNCj4gKyAgICAgICAgICAgICAg ICAgICAgICBmb3IgcGZuIGJlbG93KSwgdGhlbiBwYWdlX2RhdGFfZnJhbWUsIHdob3NlDQo+ ICsgICAgICAgICAgICAgICAgICAgICAgZGVjb21wcmVzc2VkIGNvbnRlbnQgaXMgcGFnZV9z aXplIG9jdGV0cyBmb3IgZWFjaA0KPiArICAgICAgICAgICAgICAgICAgICAgIHBhZ2Ugc2V0 IGFzIHByZXNlbnQgaW4gdGhhdCBwZm4gYXJyYXkuICBUaGV5IGFyZQ0KPiArICAgICAgICAg ICAgICAgICAgICAgIGJhY2sgdG8gYmFjaywgd2l0aCBubyBzZXBhcmF0b3IsIGxlbmd0aCBm aWVsZCBvcg0KPiArICAgICAgICAgICAgICAgICAgICAgIHBhZGRpbmcgYmV0d2VlbiB0aGVt Lg0KPiArDQo+ICsgICAgICAgICAgICAgICAgICAgICAgVGhlIGxlbmd0aCBvZiBwZm5fZnJh bWUgaXMgbm90IHJlY29yZGVkOyBhDQo+ICsgICAgICAgICAgICAgICAgICAgICAgcmVzdG9y aW5nIHNpZGUgZmluZHMgaXRzIGVuZCBieSBkZWNvZGluZyBpdCwgc28NCj4gKyAgICAgICAg ICAgICAgICAgICAgICBhbiBhbGdvcml0aG0gY2FuIG9ubHkgYmUgdXNlZCB3aXRoIGJpdCA4 IGlmIGl0cw0KPiArICAgICAgICAgICAgICAgICAgICAgIGVuY29kaW5nIG1hcmtzIGl0cyBv d24gZW5kLiAgY291bnQgaXMgbmV2ZXINCj4gKyAgICAgICAgICAgICAgICAgICAgICBjb21w cmVzc2VkLCBzbyB0aGF0IGEgcmVzdG9yaW5nIHNpZGUgY2FuIGJvdW5kDQo+ICsgICAgICAg ICAgICAgICAgICAgICAgaXRzIGJ1ZmZlcnMgYmVmb3JlIGRlY29tcHJlc3NpbmcgYW55dGhp bmcuDQo+ICsNCj4gKyAgICAgICAgICAgICAgICAgICAgICBGb3IgYWxnb3JpdGhtIDB4MDEs IGJvdGggYXJlIGNvbXBsZXRlIExaNCBmcmFtZXMuDQo+ICsgICAgICAgICAgICAgICAgICAg ICAgQm90aCBtdXN0IHNldCB0aGUgYmxvY2stY2hlY2tzdW0gZmxhZywgYW5kIGENCj4gKyAg ICAgICAgICAgICAgICAgICAgICByZXN0b3Jpbmcgc2lkZSBtdXN0IHJlamVjdCBvbmUgd2hp Y2ggZG9lcyBub3QuDQo+ICsgICAgICAgICAgICAgICAgICAgICAgcGFnZV9kYXRhX2ZyYW1l IGlzIHN1YmplY3QgdG8gdGhlIHJ1bGVzIGZvcg0KPiArICAgICAgICAgICAgICAgICAgICAg IGFsZ29yaXRobSAweDAxLCBhbmQgYSByZXN0b3Jpbmcgc2lkZSBtdXN0IHJlamVjdA0KPiAr ICAgICAgICAgICAgICAgICAgICAgIGEgcGZuX2ZyYW1lIHdoaWNoIGRvZXMgbm90IGRlY29k ZSB0byBleGFjdGx5DQo+ICsgICAgICAgICAgICAgICAgICAgICAgY291bnQgKiA4IG9jdGV0 cy4NCj4gKw0KPiArICAgICAgICAgICAgICAgICAgICAgIEEgc2F2aW5nIHNpZGUgbXVzdCBz ZW5kIHRoZSByZWNvcmQgd2l0aCBiaXQgOA0KPiArICAgICAgICAgICAgICAgICAgICAgIGNs ZWFyIGluc3RlYWQsIHRoZSBwZm4gYXJyYXkgaW4gcGxhaW50ZXh0IGFuZA0KPiArICAgICAg ICAgICAgICAgICAgICAgIHBhZ2VfZGF0YV9mcmFtZSBhcyBwYWdlX2RhdGEsIHdoZW4gdGhl IHR3byBmcmFtZXMNCj4gKyAgICAgICAgICAgICAgICAgICAgICB0b2dldGhlciwgTCBvY3Rl dHMsIHNhdGlzZnkgTCA+PSBjb3VudCAqIDggYW5kDQo+ICsgICAgICAgICAgICAgICAgICAg ICAgKEwgLSBjb3VudCAqIDgpIGlzIGEgbXVsdGlwbGUgb2YgcGFnZV9zaXplLiAgVGhpcw0K PiArICAgICAgICAgICAgICAgICAgICAgIGVuc3VyZXMgdGhhdCBhIHJlc3RvcmluZyBzaWRl IHdoaWNoIGlnbm9yZXMgdGhpcw0KPiArICAgICAgICAgICAgICAgICAgICAgIGZpZWxkLCBh cyByZXZpc2lvbnMgMSB0byAzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbg0KPiArICAgICAgICAg ICAgICAgICAgICAgIHJlcXVpcmVkLCBhbmQgc28ganVkZ2VzIHRoZSByZWNvcmQgYnkgaXRz IGxlbmd0aA0KPiArICAgICAgICAgICAgICAgICAgICAgIGFsb25lLCByZWplY3RzIGl0IHJh dGhlciB0aGFuIG1pc3JlYWRpbmcgaXQuDQoNCkdpdmVuIHRoYXQgYWxnb3JpdGhtIDB4MDEg aXMgTFo0LCBpdCdzIGJldHRlciByZWZlcmVkIGFzIGlzLiBCdXQgSSB3b3VsZCANCnByZWZl ciBtb3ZpbmcgdGhlIExaNCBzcGVjaWZpYyBzZW1hbnRpY3MgdG8gdGhlIGJpdHMgMC4uNz0w eDAxIHNlY3Rpb24gDQooTFo0KSBpbnN0ZWFkLCBzbyBhZGRpbmcgbmV3IGFsZ29yaXRobXMg ZG9lc24ndCBpbXBseSBleHBhbmRpbmcgdGhlIGJpdCANCjggZGVmaW5pdGlvbi4NCg0KSW4g YSB3YXksIHNheWluZyBzb21ldGhpbmcgbGlrZQ0KDQoiVGhlIGZvcm1hdCBvZiBjb21wcmVz c2VkIHBmbiBhcnJheSBpcyBhbGdvcml0aG0gc3BlY2lmaWMuIg0KDQo+ICsNCj4gKyAgICAg ICAgICAgIEJpdCAzMS05OiBSZXNlcnZlZC4gIFNldCB0byB6ZXJvIG9uIHNhdmUuICBBIHJl c3RvcmluZyBzaWRlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIG11c3QgcmVqZWN0IGEg cmVjb3JkIHdpdGggYW55IG9mIHRoZXNlIGJpdHMgc2V0Lg0KPiAgIA0KPiAgIHBmbiAgICAg ICAgIEFuIGFycmF5IG9mIGNvdW50IFBGTnMgYW5kIHRoZWlyIHR5cGVzLg0KPiBAQCAtMzQ2 LDYgKzM4NiwxOSBAQCBwYWdlX2RhdGEgICBDb250ZW50cyBvZiBlYWNoIHBhZ2Ugc2V0IGFz IHByZXNlbnQgaW4gdGhlIHBmbiBhcnJheSwNCj4gICBOb3RlOiBDb3VudCBpcyBzdHJpY3Rs eSA+IDAuICBOIGlzIHN0cmljdGx5IDw9IEMgYW5kIGl0IGlzIHBvc3NpYmxlIGZvciB0aGVy ZQ0KPiAgIHRvIGJlIG5vIHBhZ2VfZGF0YSBpbiB0aGUgcmVjb3JkIGlmIGFsbCBwZm5zIGFy ZSBvZiBpbnZhbGlkIHR5cGVzLg0KPiAgIA0KPiArV2hlbiBmbGFncyBiaXQgOCBpcyBzZXQs IHRoZSByZWNvcmQgaXMgaW5zdGVhZCBsYWlkIG91dCBhcyBmb2xsb3dzOg0KPiArDQo+ICsg ICAgIDAgICAgIDEgICAgIDIgICAgIDMgICAgIDQgICAgIDUgICAgIDYgICAgIDcgb2N0ZXQN Cj4gKyAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCj4gKyAgICB8IGNvdW50IChDKSAgICAgICAgICAgICB8IGZsYWdzICAgICAgICAg ICAgICAgICAgIHwNCj4gKyAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCj4gKyAgICB8IHBmbl9mcmFtZS4uLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCj4gKyAgICAuLi4NCj4gKyAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gKyAgICB8IHBh Z2VfZGF0YV9mcmFtZS4uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gKyAg ICAuLi4NCj4gKyAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCj4gKw0KPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgUEZJTkZPIHR5cGUg ICAgVmFsdWUgICAgICBEZXNjcmlwdGlvbg0KPiAgIC0tLS0tLS0tLS0tLS0gIC0tLS0tLS0t LSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IGRpZmYg LS1naXQgYS90b29scy9saWJzL2d1ZXN0L3hnX3NyX3Jlc3RvcmUuYyBiL3Rvb2xzL2xpYnMv Z3Vlc3QveGdfc3JfcmVzdG9yZS5jDQo+IGluZGV4IDI5YTNiMTMyNTMuLjc5ZGJmY2NkMmYg MTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3JfcmVzdG9yZS5jDQo+ICsr KyBiL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3JfcmVzdG9yZS5jDQo+IEBAIC0zNTYsMzIgKzM1 NiwxOSBAQCBzdGF0aWMgaW50IHByb2Nlc3NfcGFnZV9kYXRhKHN0cnVjdCB4Y19zcl9jb250 ZXh0ICpjdHgsIHVuc2lnbmVkIGludCBjb3VudCwNCj4gICANCj4gICAjaWYgZGVmaW5lZChY R19TUl9MWjQpDQo+ICAgLyoNCj4gLSAqIERlY29kZSB0aGUgTFo0IGZyYW1lIGF0IHNyYyBp bnRvIGN0eC0+cmVzdG9yZS5sejRfZGVjb21wX2J1Zi4gIFRoZQ0KPiAtICogZGVjb2RlZCBz aXplIGNvbWVzIGZyb20gdGhlIHBmbiBhcnJheS4NCj4gKyAqIERlY29kZSB0aGUgTFo0IGZy YW1lIGF0IHRoZSBzdGFydCBvZiBzcmMgaW50byBleGFjdGx5IGRzdF9sZW4gYnl0ZXMgb2YN Cj4gKyAqIGN0eC0+cmVzdG9yZS5sejRfZGVjb21wX2J1Zi4gIFdpdGggY29uc3VtZWQgTlVM TCB0aGUgZnJhbWUgbXVzdCB1c2UgYWxsIG9mDQo+ICsgKiBzcmMsIHdoaWNoIHJlamVjdHMg dHJhaWxpbmcgZGF0YTsgb3RoZXJ3aXNlIGl0cyBsZW5ndGggaXMgcmV0dXJuZWQgdGhlcmUu DQo+ICAgICovDQo+IC1zdGF0aWMgdm9pZCAqZGVjb21wcmVzc19wYWdlX2RhdGEoc3RydWN0 IHhjX3NyX2NvbnRleHQgKmN0eCwgY29uc3Qgdm9pZCAqc3JjLA0KPiAtICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHNpemVfdCBzcmNfbGVuLCB1bnNpZ25lZCBpbnQgbnJf cGFnZXMpDQo+ICtzdGF0aWMgdm9pZCAqbHo0X2RlY29kZV9mcmFtZShzdHJ1Y3QgeGNfc3Jf Y29udGV4dCAqY3R4LCBjb25zdCBjaGFyICp3aGF0LA0KPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc3Qgdm9pZCAqc3JjLCBzaXplX3Qgc3JjX2xlbiwgc2l6ZV90IGRz dF9sZW4sDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplX3QgKmNvbnN1 bWVkKQ0KPiAgIHsNCj4gICAgICAgeGNfaW50ZXJmYWNlICp4Y2ggPSBjdHgtPnhjaDsNCj4g ICAgICAgTFo0Rl9mcmFtZUluZm9fdCBpbmZvOw0KPiAtICAgIHNpemVfdCBleHBlY3RlZCA9 IChzaXplX3QpbnJfcGFnZXMgKiBQQUdFX1NJWkU7DQo+IC0gICAgc2l6ZV90IG91dF9sZW4g PSBleHBlY3RlZCwgaGRyX2xlbiA9IHNyY19sZW4sIHJlc3RfbGVuLCBpbl9sZW4sIHJldDsN Cj4gLQ0KPiAtICAgIC8qIFRoZSBidWZmZXIgaXMgYSBmaXhlZCBNQVhfQkFUQ0hfU0laRSBw YWdlcy4gKi8NCj4gLSAgICBpZiAoIG5yX3BhZ2VzID4gTUFYX0JBVENIX1NJWkUgKQ0KPiAt ICAgIHsNCj4gLSAgICAgICAgRVJST1IoIkNvbXByZXNzZWQgUEFHRV9EQVRBIHJlY29yZCB3 aXRoICV1IHBhZ2VzIGV4Y2VlZHMgTUFYX0JBVENIX1NJWkUgJXUiLA0KPiAtICAgICAgICAg ICAgICBucl9wYWdlcywgTUFYX0JBVENIX1NJWkUpOw0KPiAtICAgICAgICByZXR1cm4gTlVM TDsNCj4gLSAgICB9DQo+ICsgICAgc2l6ZV90IG91dF9sZW4gPSBkc3RfbGVuLCBoZHJfbGVu ID0gc3JjX2xlbiwgcmVzdF9sZW4sIGluX2xlbiwgcmV0Ow0KPiAgIA0KPiAtICAgIC8qIFRo ZSBmb3JtYXQgcmVxdWlyZXMgdGhlIGZyYW1lIHRvIGJlIHN0cmljdGx5IHNob3J0ZXIgdGhh biB0aGUgcGFnZXMuICovDQo+IC0gICAgaWYgKCBzcmNfbGVuID49IGV4cGVjdGVkICkNCj4g LSAgICB7DQo+IC0gICAgICAgIEVSUk9SKCJMWjQgZnJhbWUgaW4gUEFHRV9EQVRBIHJlY29y ZCAoJXp1IGJ5dGVzKSBpcyBub3Qgc2hvcnRlciB0aGFuIGl0cyBwYWdlIGRhdGEgKCV6dSBi eXRlcykiLA0KPiAtICAgICAgICAgICAgICBzcmNfbGVuLCBleHBlY3RlZCk7DQo+IC0gICAg ICAgIHJldHVybiBOVUxMOw0KPiAtICAgIH0NCj4gKyAgICBhc3NlcnQoZHN0X2xlbiA8PSBN QVhfQkFUQ0hfU0laRSAqIFBBR0VfU0laRSk7DQo+ICAgDQo+ICAgICAgIGlmICggIWN0eC0+ cmVzdG9yZS5sejRfZGN0eCApDQo+ICAgICAgIHsNCj4gQEAgLTQwMiwxNSArMzg5LDE1IEBA IHN0YXRpYyB2b2lkICpkZWNvbXByZXNzX3BhZ2VfZGF0YShzdHJ1Y3QgeGNfc3JfY29udGV4 dCAqY3R4LCBjb25zdCB2b2lkICpzcmMsDQo+ICAgICAgIHJldCA9IExaNEZfZ2V0RnJhbWVJ bmZvKGN0eC0+cmVzdG9yZS5sejRfZGN0eCwgJmluZm8sIHNyYywgJmhkcl9sZW4pOw0KPiAg ICAgICBpZiAoIExaNEZfaXNFcnJvcihyZXQpICkNCj4gICAgICAgew0KPiAtICAgICAgICBF UlJPUigiTFo0IGZyYW1lIGluIFBBR0VfREFUQSByZWNvcmQgaGFzIGEgYmFkIGhlYWRlcjog JXMiLA0KPiAtICAgICAgICAgICAgICBMWjRGX2dldEVycm9yTmFtZShyZXQpKTsNCj4gKyAg ICAgICAgRVJST1IoIkxaNCAlcyBmcmFtZSBpbiBQQUdFX0RBVEEgcmVjb3JkIGhhcyBhIGJh ZCBoZWFkZXI6ICVzIiwNCj4gKyAgICAgICAgICAgICAgd2hhdCwgTFo0Rl9nZXRFcnJvck5h bWUocmV0KSk7DQo+ICAgICAgICAgICByZXR1cm4gTlVMTDsNCj4gICAgICAgfQ0KPiAgIA0K PiAgICAgICAvKiBsaWJsejQgYWNjZXB0cyBmcmFtZXMgd2l0aG91dCB0aGUgYmxvY2sgY2hl Y2tzdW1zIHJlcXVpcmVkIGhlcmUuICovDQo+ICAgICAgIGlmICggaW5mby5ibG9ja0NoZWNr c3VtRmxhZyAhPSBMWjRGX2Jsb2NrQ2hlY2tzdW1FbmFibGVkICkNCj4gICAgICAgew0KPiAt ICAgICAgICBFUlJPUigiTFo0IGZyYW1lIGluIFBBR0VfREFUQSByZWNvcmQgaGFzIG5vIGJs b2NrIGNoZWNrc3VtcyIpOw0KPiArICAgICAgICBFUlJPUigiTFo0ICVzIGZyYW1lIGluIFBB R0VfREFUQSByZWNvcmQgaGFzIG5vIGJsb2NrIGNoZWNrc3VtcyIsIHdoYXQpOw0KPiAgICAg ICAgICAgcmV0dXJuIE5VTEw7DQo+ICAgICAgIH0NCj4gICANCj4gQEAgLTQzNiwzNiArNDIz LDY0IEBAIHN0YXRpYyB2b2lkICpkZWNvbXByZXNzX3BhZ2VfZGF0YShzdHJ1Y3QgeGNfc3Jf Y29udGV4dCAqY3R4LCBjb25zdCB2b2lkICpzcmMsDQo+ICAgDQo+ICAgICAgIGlmICggTFo0 Rl9pc0Vycm9yKHJldCkgKQ0KPiAgICAgICB7DQo+IC0gICAgICAgIEVSUk9SKCJGYWlsZWQg dG8gZGVjb21wcmVzcyBQQUdFX0RBVEEgcmVjb3JkOiAlcyIsDQo+IC0gICAgICAgICAgICAg IExaNEZfZ2V0RXJyb3JOYW1lKHJldCkpOw0KPiArICAgICAgICBFUlJPUigiRmFpbGVkIHRv IGRlY29tcHJlc3MgTFo0ICVzIGZyYW1lIGluIFBBR0VfREFUQSByZWNvcmQ6ICVzIiwNCj4g KyAgICAgICAgICAgICAgd2hhdCwgTFo0Rl9nZXRFcnJvck5hbWUocmV0KSk7DQo+ICAgICAg ICAgICByZXR1cm4gTlVMTDsNCj4gICAgICAgfQ0KPiAgIA0KPiAgICAgICAvKiBOb3QgYW4g ZXJyb3IsIGJ1dCB0aGUgZnJhbWUgZGlkIG5vdCBlbmQ6IGlucHV0IG9yIG91dHB1dCByYW4g b3V0LiAqLw0KPiAgICAgICBpZiAoIHJldCAhPSAwICkNCj4gICAgICAgew0KPiAtICAgICAg ICBFUlJPUigiTFo0IGZyYW1lIGluIFBBR0VfREFUQSByZWNvcmQgaXMgdHJ1bmNhdGVkIG9y IGRlY29kZXMgdG8gb3ZlciAlenUgYnl0ZXMiLA0KPiAtICAgICAgICAgICAgICBleHBlY3Rl ZCk7DQo+ICsgICAgICAgIEVSUk9SKCJMWjQgJXMgZnJhbWUgaW4gUEFHRV9EQVRBIHJlY29y ZCBpcyB0cnVuY2F0ZWQgb3IgZGVjb2RlcyB0byBvdmVyICV6dSBieXRlcyIsDQo+ICsgICAg ICAgICAgICAgIHdoYXQsIGRzdF9sZW4pOw0KPiAgICAgICAgICAgcmV0dXJuIE5VTEw7DQo+ ICAgICAgIH0NCj4gICANCj4gICAgICAgLyogaW5fbGVuIGFuZCBvdXRfbGVuIG5vdyBob2xk IHRoZSBieXRlcyBjb25zdW1lZCBhbmQgcHJvZHVjZWQuICovDQo+IC0gICAgaWYgKCBvdXRf bGVuICE9IGV4cGVjdGVkICkNCj4gKyAgICBpZiAoIG91dF9sZW4gIT0gZHN0X2xlbiApDQo+ ICAgICAgIHsNCj4gLSAgICAgICAgRVJST1IoIkxaNCBmcmFtZSBpbiBQQUdFX0RBVEEgcmVj b3JkIHByb2R1Y2VkICV6dSBieXRlcywgZXhwZWN0ZWQgJXp1IiwNCj4gLSAgICAgICAgICAg ICAgb3V0X2xlbiwgZXhwZWN0ZWQpOw0KPiArICAgICAgICBFUlJPUigiTFo0ICVzIGZyYW1l IGluIFBBR0VfREFUQSByZWNvcmQgcHJvZHVjZWQgJXp1IGJ5dGVzLCBleHBlY3RlZCAlenUi LA0KPiArICAgICAgICAgICAgICB3aGF0LCBvdXRfbGVuLCBkc3RfbGVuKTsNCj4gICAgICAg ICAgIHJldHVybiBOVUxMOw0KPiAgICAgICB9DQo+ICAgDQo+IC0gICAgaWYgKCBpbl9sZW4g IT0gcmVzdF9sZW4gKQ0KPiArICAgIGlmICggY29uc3VtZWQgKQ0KPiArICAgICAgICAqY29u c3VtZWQgPSBoZHJfbGVuICsgaW5fbGVuOw0KPiArICAgIGVsc2UgaWYgKCBpbl9sZW4gIT0g cmVzdF9sZW4gKQ0KPiAgICAgICB7DQo+IC0gICAgICAgIEVSUk9SKCJMWjQgZnJhbWUgaW4g UEFHRV9EQVRBIHJlY29yZCBmb2xsb3dlZCBieSAlenUgdW5jb25zdW1lZCBieXRlcyIsDQo+ IC0gICAgICAgICAgICAgIHJlc3RfbGVuIC0gaW5fbGVuKTsNCj4gKyAgICAgICAgRVJST1Io IkxaNCAlcyBmcmFtZSBpbiBQQUdFX0RBVEEgcmVjb3JkIGZvbGxvd2VkIGJ5ICV6dSB1bmNv bnN1bWVkIGJ5dGVzIiwNCj4gKyAgICAgICAgICAgICAgd2hhdCwgcmVzdF9sZW4gLSBpbl9s ZW4pOw0KPiAgICAgICAgICAgcmV0dXJuIE5VTEw7DQo+ICAgICAgIH0NCj4gICANCj4gICAg ICAgcmV0dXJuIGN0eC0+cmVzdG9yZS5sejRfZGVjb21wX2J1ZjsNCj4gICB9DQo+ICsNCj4g Ky8qIERlY29tcHJlc3MgdGhlIHBhZ2UgZGF0YSBmcmFtZSBhdCBzcmMsIG9mIG5yX3BhZ2Vz IHBhZ2VzLiAqLw0KPiArc3RhdGljIHZvaWQgKmRlY29tcHJlc3NfcGFnZV9kYXRhKHN0cnVj dCB4Y19zcl9jb250ZXh0ICpjdHgsIGNvbnN0IHZvaWQgKnNyYywNCj4gKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzaXplX3Qgc3JjX2xlbiwgdW5zaWduZWQgaW50IG5y X3BhZ2VzKQ0KPiArew0KPiArICAgIHhjX2ludGVyZmFjZSAqeGNoID0gY3R4LT54Y2g7DQo+ ICsgICAgc2l6ZV90IGV4cGVjdGVkID0gKHNpemVfdClucl9wYWdlcyAqIFBBR0VfU0laRTsN Cj4gKw0KPiArICAgIC8qIFRoZSBidWZmZXIgaXMgYSBmaXhlZCBNQVhfQkFUQ0hfU0laRSBw YWdlcy4gKi8NCj4gKyAgICBpZiAoIG5yX3BhZ2VzID4gTUFYX0JBVENIX1NJWkUgKQ0KPiAr ICAgIHsNCj4gKyAgICAgICAgRVJST1IoIkNvbXByZXNzZWQgUEFHRV9EQVRBIHJlY29yZCB3 aXRoICV1IHBhZ2VzIGV4Y2VlZHMgTUFYX0JBVENIX1NJWkUgJXUiLA0KPiArICAgICAgICAg ICAgICBucl9wYWdlcywgTUFYX0JBVENIX1NJWkUpOw0KPiArICAgICAgICByZXR1cm4gTlVM TDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICAvKiBUaGUgZm9ybWF0IHJlcXVpcmVzIHRoZSBm cmFtZSB0byBiZSBzdHJpY3RseSBzaG9ydGVyIHRoYW4gdGhlIHBhZ2VzLiAqLw0KPiArICAg IGlmICggc3JjX2xlbiA+PSBleHBlY3RlZCApDQo+ICsgICAgew0KPiArICAgICAgICBFUlJP UigiTFo0IGZyYW1lIGluIFBBR0VfREFUQSByZWNvcmQgKCV6dSBieXRlcykgaXMgbm90IHNo b3J0ZXIgdGhhbiBpdHMgcGFnZSBkYXRhICglenUgYnl0ZXMpIiwNCj4gKyAgICAgICAgICAg ICAgc3JjX2xlbiwgZXhwZWN0ZWQpOw0KPiArICAgICAgICByZXR1cm4gTlVMTDsNCj4gKyAg ICB9DQo+ICsNCj4gKyAgICByZXR1cm4gbHo0X2RlY29kZV9mcmFtZShjdHgsICJwYWdlIGRh dGEiLCBzcmMsIHNyY19sZW4sIGV4cGVjdGVkLCBOVUxMKTsNCj4gK30NCj4gICAjZW5kaWYg LyogWEdfU1JfTFo0ICovDQo+ICAgDQo+ICAgLyoNCj4gQEAgLTQ3Niw3ICs0OTEsOSBAQCBz dGF0aWMgaW50IGhhbmRsZV9wYWdlX2RhdGEoc3RydWN0IHhjX3NyX2NvbnRleHQgKmN0eCwg c3RydWN0IHhjX3NyX3JlY29yZCAqcmVjKQ0KPiAgIHsNCj4gICAgICAgeGNfaW50ZXJmYWNl ICp4Y2ggPSBjdHgtPnhjaDsNCj4gICAgICAgc3RydWN0IHhjX3NyX3JlY19wYWdlX2RhdGFf aGVhZGVyICpwYWdlcyA9IHJlYy0+ZGF0YTsNCj4gKyAgICBjb25zdCB1aW50NjRfdCAqcmVj X3BmbnM7DQo+ICAgICAgIHVuc2lnbmVkIGludCBpLCBwYWdlc19vZl9kYXRhID0gMDsNCj4g KyAgICBzaXplX3QgcGZuX2xlbjsNCj4gICAgICAgdm9pZCAqcGFnZV9kYXRhOw0KPiAgICAg ICBpbnQgcmMgPSAtMTsNCj4gICANCj4gQEAgLTUyMywxNyArNTQwLDU0IEBAIHN0YXRpYyBp bnQgaGFuZGxlX3BhZ2VfZGF0YShzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4LCBzdHJ1Y3Qg eGNfc3JfcmVjb3JkICpyZWMpDQo+ICAgICAgICAgICBnb3RvIGVycjsNCj4gICAgICAgfQ0K PiAgIA0KPiArICAgIC8qIENvbXByZXNzZWQgcGZucyBuZWVkIGFuIGFsZ29yaXRobTsgb25s eSBMWjQgaXMgaW1wbGVtZW50ZWQuICovDQo+ICsgICAgaWYgKCAocGFnZXMtPmZsYWdzICYg UEFHRV9EQVRBX0ZMQUdfQ09NUFJFU1NFRF9QRk5TKSAmJg0KPiArICAgICAgICAgKHBhZ2Vz LT5mbGFncyAmIFBBR0VfREFUQV9BTEdPX01BU0spICE9IFBBR0VfREFUQV9BTEdPX0xaNCAp DQo+ICsgICAgew0KPiArICAgICAgICBFUlJPUigiQ29tcHJlc3NlZCBwZm4gYXJyYXkgd2l0 aCB1bnN1cHBvcnRlZCBhbGdvcml0aG0gJXUgaW4gUEFHRV9EQVRBIHJlY29yZCIsDQo+ICsg ICAgICAgICAgICAgICh1bnNpZ25lZCBpbnQpKHBhZ2VzLT5mbGFncyAmIFBBR0VfREFUQV9B TEdPX01BU0spKTsNCj4gKyAgICAgICAgZ290byBlcnI7DQo+ICsgICAgfQ0KPiArDQo+ICAg ICAgIGlmICggcGFnZXMtPmNvdW50IDwgMSApDQo+ICAgICAgIHsNCj4gICAgICAgICAgIEVS Uk9SKCJFeHBlY3RlZCBhdCBsZWFzdCAxIHBmbiBpbiBQQUdFX0RBVEEgcmVjb3JkIik7DQo+ ICAgICAgICAgICBnb3RvIGVycjsNCj4gICAgICAgfQ0KPiAgIA0KPiAtICAgIGlmICggcmVj LT5sZW5ndGggPCBzaXplb2YoKnBhZ2VzKSArIChwYWdlcy0+Y291bnQgKiBzaXplb2YodWlu dDY0X3QpKSApDQo+ICsgICAgaWYgKCBwYWdlcy0+ZmxhZ3MgJiBQQUdFX0RBVEFfRkxBR19D T01QUkVTU0VEX1BGTlMgKQ0KPiAgICAgICB7DQo+IC0gICAgICAgIEVSUk9SKCJQQUdFX0RB VEEgcmVjb3JkIChsZW5ndGggJXUpIHRvbyBzaG9ydCB0byBjb250YWluICV1Ig0KPiAtICAg ICAgICAgICAgICAiIHBmbnMgd29ydGggb2YgaW5mb3JtYXRpb24iLCByZWMtPmxlbmd0aCwg cGFnZXMtPmNvdW50KTsNCj4gKyNpZiBkZWZpbmVkKFhHX1NSX0xaNCkNCj4gKyAgICAgICAg aWYgKCBwYWdlcy0+Y291bnQgPiBNQVhfQkFUQ0hfU0laRSApDQo+ICsgICAgICAgIHsNCj4g KyAgICAgICAgICAgIEVSUk9SKCJDb21wcmVzc2VkIHBmbnMgaW4gUEFHRV9EQVRBIHJlY29y ZDogY291bnQgJXUgZXhjZWVkcyBNQVhfQkFUQ0hfU0laRSAldSIsDQo+ICsgICAgICAgICAg ICAgICAgICBwYWdlcy0+Y291bnQsIE1BWF9CQVRDSF9TSVpFKTsNCj4gKyAgICAgICAgICAg IGdvdG8gZXJyOw0KPiArICAgICAgICB9DQo+ICsNCj4gKyAgICAgICAgLyogVGhlIHBhZ2Ug ZGF0YSBmcmFtZSBvdmVyd3JpdGVzIHRoZXNlLCBhZnRlciB0aGUgY29weSBiZWxvdy4gKi8N Cj4gKyAgICAgICAgcmVjX3BmbnMgPSBsejRfZGVjb2RlX2ZyYW1lKGN0eCwgInBmbiIsIHBh Z2VzLT5wZm4sDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWMt Pmxlbmd0aCAtIHNpemVvZigqcGFnZXMpLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcGFnZXMtPmNvdW50ICogc2l6ZW9mKHVpbnQ2NF90KSwNCj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZwZm5fbGVuKTsNCj4gKyAgICAgICAg aWYgKCAhcmVjX3BmbnMgKQ0KPiArICAgICAgICAgICAgZ290byBlcnI7DQo+ICsjZWxzZQ0K PiArICAgICAgICBFUlJPUigiTFo0IGNvbXByZXNzZWQgUEFHRV9EQVRBIHJlY29yZCBidXQg TFo0IHN1cHBvcnQgbm90IGNvbXBpbGVkIGluIik7DQo+ICAgICAgICAgICBnb3RvIGVycjsN Cj4gKyNlbmRpZg0KPiArICAgIH0NCj4gKyAgICBlbHNlDQo+ICsgICAgew0KPiArICAgICAg ICBpZiAoIHJlYy0+bGVuZ3RoIDwgc2l6ZW9mKCpwYWdlcykgKyAocGFnZXMtPmNvdW50ICog c2l6ZW9mKHVpbnQ2NF90KSkgKQ0KPiArICAgICAgICB7DQo+ICsgICAgICAgICAgICBFUlJP UigiUEFHRV9EQVRBIHJlY29yZCAobGVuZ3RoICV1KSB0b28gc2hvcnQgdG8gY29udGFpbiAl dSINCj4gKyAgICAgICAgICAgICAgICAgICIgcGZucyB3b3J0aCBvZiBpbmZvcm1hdGlvbiIs IHJlYy0+bGVuZ3RoLCBwYWdlcy0+Y291bnQpOw0KPiArICAgICAgICAgICAgZ290byBlcnI7 DQo+ICsgICAgICAgIH0NCj4gKw0KPiArICAgICAgICByZWNfcGZucyA9IHBhZ2VzLT5wZm47 DQo+ICsgICAgICAgIHBmbl9sZW4gPSBwYWdlcy0+Y291bnQgKiBzaXplb2YodWludDY0X3Qp Ow0KPiAgICAgICB9DQo+ICAgDQo+ICAgICAgIHBmbnMgPSBtYWxsb2MocGFnZXMtPmNvdW50 ICogc2l6ZW9mKCpwZm5zKSk7DQo+IEBAIC01NDcsMjEgKzYwMSwyMSBAQCBzdGF0aWMgaW50 IGhhbmRsZV9wYWdlX2RhdGEoc3RydWN0IHhjX3NyX2NvbnRleHQgKmN0eCwgc3RydWN0IHhj X3NyX3JlY29yZCAqcmVjKQ0KPiAgIA0KPiAgICAgICBmb3IgKCBpID0gMDsgaSA8IHBhZ2Vz LT5jb3VudDsgKytpICkNCj4gICAgICAgew0KPiAtICAgICAgICBpZiAoIHBhZ2VzLT5wZm5b aV0gJiBQQUdFX0RBVEFfUEZOX1JFU1pfTUFTSyApDQo+ICsgICAgICAgIGlmICggcmVjX3Bm bnNbaV0gJiBQQUdFX0RBVEFfUEZOX1JFU1pfTUFTSyApDQo+ICAgICAgICAgICB7DQo+ICAg ICAgICAgICAgICAgRVJST1IoIlJlc2VydmVkIGJpdHMgc2V0IGluIHBmblsldV06ICUjIlBS SXg2NCwgaSwNCj4gLSAgICAgICAgICAgICAgICAgIHBhZ2VzLT5wZm5baV0pOw0KPiArICAg ICAgICAgICAgICAgICAgcmVjX3BmbnNbaV0pOw0KPiAgICAgICAgICAgICAgIGdvdG8gZXJy Ow0KPiAgICAgICAgICAgfQ0KPiAgIA0KPiAtICAgICAgICBwZm4gPSBwYWdlcy0+cGZuW2ld ICYgUEFHRV9EQVRBX1BGTl9NQVNLOw0KPiArICAgICAgICBwZm4gPSByZWNfcGZuc1tpXSAm IFBBR0VfREFUQV9QRk5fTUFTSzsNCj4gICAgICAgICAgIGlmICggIWN0eC0+cmVzdG9yZS5v cHMucGZuX2lzX3ZhbGlkKGN0eCwgcGZuKSApDQo+ICAgICAgICAgICB7DQo+ICAgICAgICAg ICAgICAgRVJST1IoInBmbiAlIyJQUklwZm4iIChpbmRleCAldSkgb3V0c2lkZSBkb21haW4g bWF4aW11bSIsIHBmbiwgaSk7DQo+ICAgICAgICAgICAgICAgZ290byBlcnI7DQo+ICAgICAg ICAgICB9DQo+ICAgDQo+IC0gICAgICAgIHR5cGUgPSAocGFnZXMtPnBmbltpXSAmIFBBR0Vf REFUQV9UWVBFX01BU0spID4+IDMyOw0KPiArICAgICAgICB0eXBlID0gKHJlY19wZm5zW2ld ICYgUEFHRV9EQVRBX1RZUEVfTUFTSykgPj4gMzI7DQo+ICAgICAgICAgICBpZiAoICFpc19r bm93bl9wYWdlX3R5cGUodHlwZSkgKQ0KPiAgICAgICAgICAgew0KPiAgICAgICAgICAgICAg IEVSUk9SKCJVbmtub3duIHR5cGUgJSMiUFJJeDMyIiBmb3IgcGZuICUjIlBSSXBmbiIgKGlu ZGV4ICV1KSIsDQo+IEBAIC01NzgsNyArNjMyLDcgQEAgc3RhdGljIGludCBoYW5kbGVfcGFn ZV9kYXRhKHN0cnVjdCB4Y19zcl9jb250ZXh0ICpjdHgsIHN0cnVjdCB4Y19zcl9yZWNvcmQg KnJlYykNCj4gICAgICAgICAgIHR5cGVzW2ldID0gdHlwZTsNCj4gICAgICAgfQ0KPiAgIA0K PiAtICAgIHBhZ2VfZGF0YSA9ICZwYWdlcy0+cGZuW3BhZ2VzLT5jb3VudF07DQo+ICsgICAg cGFnZV9kYXRhID0gKHVpbnQ4X3QgKilwYWdlcy0+cGZuICsgcGZuX2xlbjsNCj4gICANCj4g ICAgICAgc3dpdGNoICggcGFnZXMtPmZsYWdzICYgUEFHRV9EQVRBX0FMR09fTUFTSyApDQo+ ICAgICAgIHsNCj4gQEAgLTU5OCw3ICs2NTIsNyBAQCBzdGF0aWMgaW50IGhhbmRsZV9wYWdl X2RhdGEoc3RydWN0IHhjX3NyX2NvbnRleHQgKmN0eCwgc3RydWN0IHhjX3NyX3JlY29yZCAq cmVjKQ0KPiAgICAgICBjYXNlIFBBR0VfREFUQV9BTEdPX0xaNDoNCj4gICAjaWYgZGVmaW5l ZChYR19TUl9MWjQpDQo+ICAgICAgIHsNCj4gLSAgICAgICAgc2l6ZV90IGhkcnN6ID0gc2l6 ZW9mKCpwYWdlcykgKyAoc2l6ZW9mKHVpbnQ2NF90KSAqIHBhZ2VzLT5jb3VudCk7DQo+ICsg ICAgICAgIHNpemVfdCBoZHJzeiA9IHNpemVvZigqcGFnZXMpICsgcGZuX2xlbjsNCj4gICAN Cj4gICAgICAgICAgIHBhZ2VfZGF0YSA9IGRlY29tcHJlc3NfcGFnZV9kYXRhKGN0eCwgcGFn ZV9kYXRhLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cmVjLT5sZW5ndGggLSBoZHJzeiwgcGFnZXNfb2ZfZGF0YSk7DQo+IGRpZmYgLS1naXQgYS90 b29scy9saWJzL2d1ZXN0L3hnX3NyX3NhdmUuYyBiL3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3Jf c2F2ZS5jDQo+IGluZGV4IGZlM2Q3OGJkZDYuLjE5MmFiYzgyYzUgMTAwNjQ0DQo+IC0tLSBh L3Rvb2xzL2xpYnMvZ3Vlc3QveGdfc3Jfc2F2ZS5jDQo+ICsrKyBiL3Rvb2xzL2xpYnMvZ3Vl c3QveGdfc3Jfc2F2ZS5jDQo+IEBAIC0xNTAsMTEgKzE1MCwxOSBAQCBzdGF0aWMgdm9pZCBj b21wcmVzc19zdGF0c19ldmFsdWF0ZShzdHJ1Y3QgeGNfc3JfY29udGV4dCAqY3R4KQ0KPiAg ICAqLw0KPiAgICNkZWZpbmUgWENfU1JfQ09NUFJFU1NfQkxPQ0tfU0laRSBMWjRGX21heDRN Qg0KPiAgIA0KPiArLyogU2l6ZSBydWxlOiBjb3VsZCBsZW4gYnl0ZXMgcGFzcyBhcyBwZm5z X2xlbiBvZiBwZm5zIHBsdXMgd2hvbGUgcGFnZXM/ICovDQo+ICtzdGF0aWMgYm9vbCBwYWdl X2RhdGFfc2l6ZV9jbGFzaChzaXplX3QgbGVuLCBzaXplX3QgcGZuc19sZW4pDQo+ICt7DQo+ ICsgICAgcmV0dXJuIGxlbiA+PSBwZm5zX2xlbiAmJiAobGVuIC0gcGZuc19sZW4pICUgUEFH RV9TSVpFID09IDA7DQo+ICt9DQo+ICsNCj4gICAvKg0KPiAgICAqIENvbXByZXNzIHRoZSBw YWdlIGRhdGEgaW4gaW92WzIuLmlvdmNudCkgaW50byBhbiBMWjQgZnJhbWUsIGFuZCByZXBs YWNlDQo+IC0gKiB0aG9zZSBlbnRyaWVzIHdpdGggb25lIGRlc2NyaWJpbmcgaXQsIHBhZGRl ZCB0byB0aGUgcmVjb3JkIGFsaWdubWVudC4NCj4gLSAqIFJldHVybnMgdGhlIG5ldyBpb3Zj bnQsIHRoZSBvcmlnaW5hbCBvbmUgd2l0aCBpb3YgdW50b3VjaGVkIGlmIHRoZSBiYXRjaA0K PiAtICogc2hvdWxkIGJlIHNlbnQgdW5jb21wcmVzc2VkLCBvciAtMSBpZiB0aGUgYmF0Y2gg aXRzZWxmIGlzIG1hbGZvcm1lZC4NCj4gKyAqIHRob3NlIGVudHJpZXMgd2l0aCBvbmUgZGVz Y3JpYmluZyBpdCwgcGFkZGVkIHRvIHRoZSByZWNvcmQgYWxpZ25tZW50LiAgVGhlDQo+ICsg KiBwZm4gYXJyYXkgaW4gaW92WzFdIGJlY29tZXMgYSBzZWNvbmQgZnJhbWUgdG9vLCB1bmxl c3MgdGhhdCBpcyBubyBzbWFsbGVyIG9yDQo+ICsgKiB0aGUgc2l6ZSBydWxlIGFwcGxpZXMu ICBSZXR1cm5zIHRoZSBuZXcgaW92Y250LCB0aGUgb3JpZ2luYWwgb25lIHdpdGggaW92DQo+ ICsgKiB1bnRvdWNoZWQgaWYgdGhlIGJhdGNoIHNob3VsZCBiZSBzZW50IHVuY29tcHJlc3Nl ZCwgb3IgLTEgaWYgdGhlIGJhdGNoDQo+ICsgKiBpdHNlbGYgaXMgbWFsZm9ybWVkLg0KPiAg ICAqLw0KPiAgIHN0YXRpYyBpbnQgbHo0X2NvbXByZXNzX2JhdGNoKHN0cnVjdCB4Y19zcl9j b250ZXh0ICpjdHgsIHN0cnVjdCBpb3ZlYyAqaW92LA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGludCBpb3ZjbnQsIHVuc2lnbmVkIGludCBucl9wYWdlcywNCj4gQEAg LTE2Nyw3ICsxNzUsNyBAQCBzdGF0aWMgaW50IGx6NF9jb21wcmVzc19iYXRjaChzdHJ1Y3Qg eGNfc3JfY29udGV4dCAqY3R4LCBzdHJ1Y3QgaW92ZWMgKmlvdiwNCj4gICAgICAgICAgIH0s DQo+ICAgICAgIH07DQo+ICAgICAgIHhjX2ludGVyZmFjZSAqeGNoID0gY3R4LT54Y2g7DQo+ IC0gICAgc2l6ZV90IHJhdyA9IChzaXplX3QpbnJfcGFnZXMgKiBQQUdFX1NJWkUsIGNsZW4s IHN0YWdlZDsNCj4gKyAgICBzaXplX3QgcmF3ID0gKHNpemVfdClucl9wYWdlcyAqIFBBR0Vf U0laRSwgY2xlbiwgcGZuX2NsZW4sIHN0YWdlZCwgcGFkOw0KPiAgICAgICB1aW50OF90ICpk c3Q7DQo+ICAgICAgIGludCBpOw0KPiAgIA0KPiBAQCAtMTc2LDggKzE4NCw5IEBAIHN0YXRp YyBpbnQgbHo0X2NvbXByZXNzX2JhdGNoKHN0cnVjdCB4Y19zcl9jb250ZXh0ICpjdHgsIHN0 cnVjdCBpb3ZlYyAqaW92LA0KPiAgIA0KPiAgICAgICBpZiAoICFjdHgtPnNhdmUubHo0X3N0 YWdpbmdfYnVmICkNCj4gICAgICAgew0KPiArICAgICAgICAvKiBUaGUgcGFnZSBkYXRhIGZy YW1lIHBsdXMgdXAgdG8gUkVDX0FMSUdOIC0gMSBieXRlcyBvZiBwYWRkaW5nLiAqLw0KPiAg ICAgICAgICAgc2l6ZV90IGJvdW5kID0gTFo0Rl9jb21wcmVzc0ZyYW1lQm91bmQoTUFYX0JB VENIX1NJWkUgKiBQQUdFX1NJWkUsDQo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZwcmVmcyk7DQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICZwcmVmcykgKyBSRUNfQUxJR047DQo+ICAgDQo+ ICAgICAgICAgICBjdHgtPnNhdmUubHo0X3N0YWdpbmdfYnVmID0gbWFsbG9jKE1BWF9CQVRD SF9TSVpFICogUEFHRV9TSVpFKTsNCj4gICAgICAgICAgIGN0eC0+c2F2ZS5sejRfY29tcHJl c3NfYnVmID0gbWFsbG9jKGJvdW5kKTsNCj4gQEAgLTIzMywxNiArMjQyLDQ0IEBAIHN0YXRp YyBpbnQgbHo0X2NvbXByZXNzX2JhdGNoKHN0cnVjdCB4Y19zcl9jb250ZXh0ICpjdHgsIHN0 cnVjdCBpb3ZlYyAqaW92LA0KPiAgICAgICAgICAgICAgICAgKGNsZW4gKiAxMDAwIC8gcmF3 KSAvIDEwLCAoY2xlbiAqIDEwMDAgLyByYXcpICUgMTApOw0KPiAgICAgICBjb21wcmVzc19z dGF0c19hY2N1bXVsYXRlKGN0eCwgcmF3LCBjbGVuKTsNCj4gICANCj4gLSAgICAvKiBQYWQg aW4gcGxhY2U6IHJhdyBpcyBhIG11bHRpcGxlIG9mIFJFQ19BTElHTiBhbmQgPiBjbGVuLCBz byBpdCBmaXRzLiAqLw0KPiAtICAgIG1lbXNldCgodWludDhfdCAqKWN0eC0+c2F2ZS5sejRf Y29tcHJlc3NfYnVmICsgY2xlbiwgMCwNCj4gLSAgICAgICAgICAgUk9VTkRVUChjbGVuLCBS RUNfQUxJR04pIC0gY2xlbik7DQo+IC0NCj4gLSAgICBpb3ZbMl0uaW92X2Jhc2UgPSBjdHgt PnNhdmUubHo0X2NvbXByZXNzX2J1ZjsNCj4gLSAgICBpb3ZbMl0uaW92X2xlbiA9IFJPVU5E VVAoY2xlbiwgUkVDX0FMSUdOKTsNCj4gKyAgICAvKiBUaGUgcGFnZXMgYXJlIGNvbXByZXNz ZWQ6IHJldXNlIHRoZSBzdGFnaW5nIGJ1ZmZlciBmb3IgdGhlIHBmbiBmcmFtZS4gKi8NCj4g KyAgICBhc3NlcnQoTFo0Rl9jb21wcmVzc0ZyYW1lQm91bmQoaW92WzFdLmlvdl9sZW4sICZw cmVmcykgPD0NCj4gKyAgICAgICAgICAgTUFYX0JBVENIX1NJWkUgKiBQQUdFX1NJWkUpOw0K DQpJcyB0aGlzIGFzc2VydCBleHBlY3RlZCA/DQoNCj4gKyAgICBwZm5fY2xlbiA9IExaNEZf Y29tcHJlc3NGcmFtZShjdHgtPnNhdmUubHo0X3N0YWdpbmdfYnVmLA0KPiArICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE1BWF9CQVRDSF9TSVpFICogUEFHRV9TSVpFLA0K PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlvdlsxXS5pb3ZfYmFzZSwg aW92WzFdLmlvdl9sZW4sICZwcmVmcyk7DQo+ICsNCj4gKyAgICAvKg0KPiArICAgICAqIFRo ZSBzaXplIHJ1bGUgb25seSBwcm90ZWN0cyByZWNlaXZlcnMgd2l0aG91dCAidG9vbHMvbGli cy9ndWVzdDoNCj4gKyAgICAgKiByZWplY3Qgbm9uLXplcm8gcmVzZXJ2ZWQgZmllbGRzIGlu IFBBR0VfREFUQSI7IGRyb3AgaXQgb25jZSBub25lIHJlbWFpbi4NCj4gKyAgICAgKiBTdWNo IGEgcmVjZWl2ZXIgcmVhZHMgdGhlIGZyYW1lcyBhcyBpb3ZbMV0uaW92X2xlbiBieXRlcyBv ZiBwZm5zIGFuZA0KPiArICAgICAqIHBhZ2VzLCBzbyBwYWdlX2RhdGFfc2l6ZV9jbGFzaCgp IGNoZWNrcyB0aGUgbGVuZ3RocyBhcyBpdCBzZWVzIHRoZW0uDQo+ICsgICAgICovDQoNClRo YXQgY29tbWVudCBmZWVscyBhIGJpdCBvZGQuDQpXZSBuZXZlciByZWFsbHkga25vdyB3aGVu IHJlY2VpdmVyIHdpdGhvdXQgdGhlIHBhdGNoIHJlbWFpbnMuDQoNCj4gKyAgICBpZiAoIExa NEZfaXNFcnJvcihwZm5fY2xlbikgfHwgcGZuX2NsZW4gPj0gaW92WzFdLmlvdl9sZW4gfHwN Cj4gKyAgICAgICAgIHBhZ2VfZGF0YV9zaXplX2NsYXNoKHBmbl9jbGVuICsgY2xlbiwgaW92 WzFdLmlvdl9sZW4pICkNCj4gKyAgICAgICAgREJHUFJJTlRGKCJMWjQ6IHNlbmRpbmcgJXp1 IGJ5dGVzIG9mIHBmbnMgdW5jb21wcmVzc2VkIiwNCj4gKyAgICAgICAgICAgICAgICAgIGlv dlsxXS5pb3ZfbGVuKTsNCj4gKyAgICBlbHNlDQo+ICsgICAgew0KPiArICAgICAgICAqZmxh Z3MgfD0gUEFHRV9EQVRBX0ZMQUdfQ09NUFJFU1NFRF9QRk5TOw0KPiArICAgICAgICAqbGVu Z3RoIC09IGlvdlsxXS5pb3ZfbGVuIC0gcGZuX2NsZW47DQo+ICsgICAgICAgIGlvdlsxXS5p b3ZfYmFzZSA9IGN0eC0+c2F2ZS5sejRfc3RhZ2luZ19idWY7DQo+ICsgICAgICAgIGlvdlsx XS5pb3ZfbGVuID0gcGZuX2NsZW47DQo+ICsgICAgfQ0KPiAgIA0KPiAgICAgICAqZmxhZ3Mg fD0gUEFHRV9EQVRBX0FMR09fTFo0Ow0KPiAgICAgICAqbGVuZ3RoIC09IHJhdyAtIGNsZW47 DQo+ICAgDQo+ICsgICAgLyogUGFkIGluIHBsYWNlOiB0aGUgYnVmZmVyIHdhcyBhbGxvY2F0 ZWQgd2l0aCBSRUNfQUxJR04gdG8gc3BhcmUuICovDQo+ICsgICAgcGFkID0gUk9VTkRVUCgq bGVuZ3RoLCBSRUNfQUxJR04pIC0gKmxlbmd0aDsNCj4gKyAgICBtZW1zZXQoKHVpbnQ4X3Qg KiljdHgtPnNhdmUubHo0X2NvbXByZXNzX2J1ZiArIGNsZW4sIDAsIHBhZCk7DQo+ICsNCj4g KyAgICBpb3ZbMl0uaW92X2Jhc2UgPSBjdHgtPnNhdmUubHo0X2NvbXByZXNzX2J1ZjsNCj4g KyAgICBpb3ZbMl0uaW92X2xlbiA9IGNsZW4gKyBwYWQ7DQo+ICsNCj4gKyAgICBhc3NlcnQo aW92WzBdLmlvdl9sZW4gKyBpb3ZbMV0uaW92X2xlbiArIGlvdlsyXS5pb3ZfbGVuID09DQo+ ICsgICAgICAgICAgIHNpemVvZihzdHJ1Y3QgeGNfc3JfcmhkcikgKyBST1VORFVQKCpsZW5n dGgsIFJFQ19BTElHTikpOw0KPiArDQo+ICAgICAgIC8qIGlvdlswXSBoZWFkZXJzLCBpb3Zb MV0gcGZucywgaW92WzJdIHBhZ2UgZGF0YSBmcmFtZS4gKi8NCj4gICAgICAgcmV0dXJuIDM7 DQo+ICAgfQ0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9ndWVzdC94Z19zcl9zdHJlYW1f Zm9ybWF0LmggYi90b29scy9saWJzL2d1ZXN0L3hnX3NyX3N0cmVhbV9mb3JtYXQuaA0KPiBp bmRleCBhZjY5NWFlNzcxLi45YmM1Yjc1MTA0IDEwMDY0NA0KPiAtLS0gYS90b29scy9saWJz L2d1ZXN0L3hnX3NyX3N0cmVhbV9mb3JtYXQuaA0KPiArKysgYi90b29scy9saWJzL2d1ZXN0 L3hnX3NyX3N0cmVhbV9mb3JtYXQuaA0KPiBAQCAtODcsOSArODcsMTMgQEAgc3RydWN0IHhj X3NyX3JlY19wYWdlX2RhdGFfaGVhZGVyDQo+ICAgICAgIHVpbnQ2NF90IHBmblswXTsNCj4g ICB9Ow0KPiAgIA0KPiAtLyogUEFHRV9EQVRBIGZsYWdzOiBiaXRzIDctMCBhcmUgdGhlIGFs Z29yaXRobSwgYml0cyAzMS04IGFyZSByZXNlcnZlZC4gKi8NCj4gKy8qDQo+ICsgKiBQQUdF X0RBVEEgZmxhZ3M6IGJpdHMgNy0wIGFyZSB0aGUgYWxnb3JpdGhtLCBiaXQgOCBtYXJrcyBh IGNvbXByZXNzZWQgcGZuDQo+ICsgKiBhcnJheSwgYml0cyAzMS05IGFyZSByZXNlcnZlZC4N Cj4gKyAqLw0KPiAgICNkZWZpbmUgUEFHRV9EQVRBX0FMR09fTUFTSyAgICAgICAweDAwMDAw MGZmVQ0KPiAtI2RlZmluZSBQQUdFX0RBVEFfRkxBR1NfUkVTWl9NQVNLIDB4ZmZmZmZmMDBV DQo+ICsjZGVmaW5lIFBBR0VfREFUQV9GTEFHX0NPTVBSRVNTRURfUEZOUyAweDAwMDAwMTAw VQ0KPiArI2RlZmluZSBQQUdFX0RBVEFfRkxBR1NfUkVTWl9NQVNLIDB4ZmZmZmZlMDBVDQo+ ICAgDQo+ICAgI2RlZmluZSBQQUdFX0RBVEFfQUxHT19OT05FICAgICAgIDB4MDAwMDAwMDBV DQo+ICAgI2RlZmluZSBQQUdFX0RBVEFfQUxHT19MWjQgICAgICAgIDB4MDAwMDAwMDFVDQo+ IGRpZmYgLS1naXQgYS90b29scy9weXRob24veGVuL21pZ3JhdGlvbi9saWJ4Yy5weSBiL3Rv b2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL2xpYnhjLnB5DQo+IGluZGV4IDEwZTE2M2UyNzIu LjVlNjA2YTcwZWUgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9u L2xpYnhjLnB5DQo+ICsrKyBiL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL2xpYnhjLnB5 DQo+IEBAIC04Niw5ICs4NiwxMSBAQCBQQUdFX0RBVEFfRk9STUFUICAgICAgICAgICAgID0g IklJIg0KPiAgIFBBR0VfREFUQV9QRk5fTUFTSyAgICAgICAgICAgPSAoMSA8PCA1MikgLSAx DQo+ICAgUEFHRV9EQVRBX1BGTl9SRVNaX01BU0sgICAgICA9ICgoMSA8PCA2MCkgLSAxKSAm IH4oKDEgPDwgNTIpIC0gMSkNCj4gICANCj4gLSMgcGFnZV9kYXRhIGZsYWdzOiBiaXRzIDct MCBhbGdvcml0aG0sIGJpdHMgMzEtOCByZXNlcnZlZCAobXVzdCByZWplY3QpDQo+ICsjIHBh Z2VfZGF0YSBmbGFnczogYml0cyA3LTAgYWxnb3JpdGhtLCBiaXQgOCBwZm4gYXJyYXkgY29t cHJlc3NlZCB0b28gKG5vdCB3aXRoDQo+ICsjIGFsZ29yaXRobSAwKSwgYml0cyAzMS05IHJl c2VydmVkIChtdXN0IHJlamVjdCkNCj4gICBQQUdFX0RBVEFfQUxHT19NQVNLICAgICAgICAg ID0gMHgwMDAwMDBmZg0KPiAtUEFHRV9EQVRBX0ZMQUdTX1JFU1pfTUFTSyAgICA9IDB4ZmZm ZmZmMDANCj4gK1BBR0VfREFUQV9GTEFHX0NPTVBSRVNTRURfUEZOUyA9IDB4MDAwMDAxMDAN Cj4gK1BBR0VfREFUQV9GTEFHU19SRVNaX01BU0sgICAgPSAweGZmZmZmZTAwDQo+ICAgUEFH RV9EQVRBX0FMR09fTk9ORSAgICAgICAgICA9IDB4MDANCj4gICBQQUdFX0RBVEFfQUxHT19M WjQgICAgICAgICAgID0gMHgwMQ0KPiAgIA0KPiBAQCAtMjc4LDYgKzI4MCwxMCBAQCBjbGFz cyBWZXJpZnlMaWJ4YyhWZXJpZnlCYXNlKToNCj4gICANCj4gICAgICAgICAgIGFsZ28gPSBm bGFncyAmIFBBR0VfREFUQV9BTEdPX01BU0sNCj4gICANCj4gKyAgICAgICAgaWYgZmxhZ3Mg JiBQQUdFX0RBVEFfRkxBR19DT01QUkVTU0VEX1BGTlM6DQo+ICsgICAgICAgICAgICBzZWxm LnZlcmlmeV9wYWdlX2RhdGFfY29tcHJlc3NlZF9wZm5zKGNvbnRlbnRbbWluc3o6XSwgY291 bnQsIGFsZ28pDQo+ICsgICAgICAgICAgICByZXR1cm4NCj4gKw0KPiAgICAgICAgICAgcGZu c3ogPSBjb3VudCAqIDgNCj4gICAgICAgICAgIGlmIChsZW4oY29udGVudCkgLSBtaW5zeikg PCBwZm5zejoNCj4gICAgICAgICAgICAgICByYWlzZSBSZWNvcmRFcnJvcigNCj4gQEAgLTMz Myw2ICszMzksMzkgQEAgY2xhc3MgVmVyaWZ5TGlieGMoVmVyaWZ5QmFzZSk6DQo+ICAgICAg ICAgICAgICAgICAgICJVbnN1cHBvcnRlZCBhbGdvcml0aG0gJXUgaW4gUEFHRV9EQVRBIHJl Y29yZCIgJSAoYWxnbywgKSkNCj4gICANCj4gICANCj4gKyAgICBkZWYgdmVyaWZ5X3BhZ2Vf ZGF0YV9jb21wcmVzc2VkX3BmbnMoc2VsZiwgcGF5bG9hZCwgY291bnQsIGFsZ28pOg0KPiAr ICAgICAgICAiIiIgUGFnZSBEYXRhIHJlY29yZCB3aG9zZSBwZm4gYXJyYXkgaXMgY29tcHJl c3NlZCB0b28gIiIiDQo+ICsNCj4gKyAgICAgICAgaWYgYWxnbyA9PSBQQUdFX0RBVEFfQUxH T19OT05FOg0KPiArICAgICAgICAgICAgcmFpc2UgUmVjb3JkRXJyb3IoDQo+ICsgICAgICAg ICAgICAgICAgIkNvbXByZXNzZWQgcGZuIGFycmF5IHdpdGhvdXQgYW4gYWxnb3JpdGhtIGlu IFBBR0VfREFUQSByZWNvcmQiKQ0KPiArICAgICAgICBpZiBhbGdvICE9IFBBR0VfREFUQV9B TEdPX0xaNDoNCj4gKyAgICAgICAgICAgIHJhaXNlIFN0cmVhbUVycm9yKA0KPiArICAgICAg ICAgICAgICAgICJVbnN1cHBvcnRlZCBhbGdvcml0aG0gJXUgaW4gUEFHRV9EQVRBIHJlY29y ZCIgJSAoYWxnbywgKSkNCj4gKw0KPiArICAgICAgICBpZiBjb3VudCA9PSAwOg0KPiArICAg ICAgICAgICAgcmFpc2UgUmVjb3JkRXJyb3IoIlBBR0VfREFUQSByZWNvcmQgd2l0aCBubyBw Zm5zIikNCj4gKw0KPiArICAgICAgICAjIFdpdGhvdXQgZGVjb21wcmVzc2luZywgY2hlY2sg dGhlIHNhdmVyJ3Mgc2l6ZSBydWxlOiBub3QgY291bnQgcGZucw0KPiArICAgICAgICAjIHBs dXMgd2hvbGUgcGFnZXMsIHdoaWNoIGEgcmVjZWl2ZXIgaWdub3JpbmcgZmxhZ3MgY291bGQg bWlzcmVhZC4NCj4gKyAgICAgICAgcGZuc3ogPSBjb3VudCAqIDgNCj4gKyAgICAgICAgaWYg bGVuKHBheWxvYWQpID49IHBmbnN6IGFuZCAobGVuKHBheWxvYWQpIC0gcGZuc3opICUgNDA5 NiA9PSAwOg0KPiArICAgICAgICAgICAgcmFpc2UgUmVjb3JkRXJyb3IoDQo+ICsgICAgICAg ICAgICAgICAgIkNvbXByZXNzZWQgUEFHRV9EQVRBIHBheWxvYWQgb2YgJXUgaXMgJXUgcGZu cyBhbmQgd2hvbGUgcGFnZXMiDQo+ICsgICAgICAgICAgICAgICAgJSAobGVuKHBheWxvYWQp LCBjb3VudCkpDQo+ICsNCj4gKyAgICAgICAgIyBPbmx5IHRoZSBwZm4gZnJhbWUncyBoZWFk ZXIgaXMgY2hlY2thYmxlOiB0aGUgcGFnZSBkYXRhIGZyYW1lIHN0YXJ0cw0KPiArICAgICAg ICAjIHdoZXJlIGRlY29kaW5nIHRoZSBwZm4gZnJhbWUgZW5kcy4NCj4gKyAgICAgICAgaWYg bGVuKHBheWxvYWQpIDwgUEFHRV9EQVRBX0xaNF9GUkFNRV9NSU46DQo+ICsgICAgICAgICAg ICByYWlzZSBSZWNvcmRFcnJvcigNCj4gKyAgICAgICAgICAgICAgICAiTFo0IGZyYW1lIGlu IFBBR0VfREFUQSByZWNvcmQgdG9vIHNob3J0OiAldSBieXRlcyINCj4gKyAgICAgICAgICAg ICAgICAlIChsZW4ocGF5bG9hZCksICkpDQo+ICsNCj4gKyAgICAgICAgaWYgbm90IG9yZChw YXlsb2FkWzQ6NV0pICYgUEFHRV9EQVRBX0xaNF9GTEdfQkxPQ0tTVU06DQo+ICsgICAgICAg ICAgICByYWlzZSBSZWNvcmRFcnJvcigNCj4gKyAgICAgICAgICAgICAgICAiTFo0IGZyYW1l IGluIFBBR0VfREFUQSByZWNvcmQgaGFzIG5vIGJsb2NrIGNoZWNrc3VtcyIpDQo+ICsNCj4g Kw0KPiAgICAgICBkZWYgdmVyaWZ5X3JlY29yZF94ODZfcHZfaW5mbyhzZWxmLCBjb250ZW50 KToNCj4gICAgICAgICAgICIiIiB4ODYgUFYgSW5mbyByZWNvcmQgIiIiDQo+ICAgDQo+IGRp ZmYgLS1naXQgYS90b29scy9weXRob24veGVuL21pZ3JhdGlvbi90ZXN0cy5weSBiL3Rvb2xz L3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rlc3RzLnB5DQo+IGluZGV4IDllNmQ5MjVlNTEuLmRk N2U4ZWI1Y2QgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rl c3RzLnB5DQo+ICsrKyBiL3Rvb2xzL3B5dGhvbi94ZW4vbWlncmF0aW9uL3Rlc3RzLnB5DQo+ IEBAIC03NCwxMCArNzQsNDcgQEAgY2xhc3MgVGVzdExpYnhjKHVuaXR0ZXN0LlRlc3RDYXNl KToNCj4gICAgICAgICAgICMgQW4gdW5pbXBsZW1lbnRlZCBhbGdvcml0aG0sIGFuZCBhbnkg cmVzZXJ2ZWQgYml0LCBhcmUgcmVmdXNlZC4NCj4gICAgICAgICAgIHNlbGYuYXNzZXJ0UmFp c2VzKGxpYnhjLlN0cmVhbUVycm9yLCB2LnZlcmlmeV9yZWNvcmRfcGFnZV9kYXRhLA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjKGxpYnhjLlBBR0VfREFUQV9BTEdPX0xa NCArIDEsIEZSQU1FKSkNCj4gLSAgICAgICAgZm9yIGJpdCBpbiByYW5nZSg4LCAzMik6DQo+ ICsgICAgICAgIGZvciBiaXQgaW4gcmFuZ2UoOSwgMzIpOg0KPiAgICAgICAgICAgICAgIHNl bGYuYXNzZXJ0UmFpc2VzKGxpYnhjLlN0cmVhbUVycm9yLCB2LnZlcmlmeV9yZWNvcmRfcGFn ZV9kYXRhLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYygxIDw8IGJp dCwgUEFHRSkpDQo+ICAgDQo+ICsgICAgZGVmIHRlc3RfcGFnZV9kYXRhX2NvbXByZXNzZWRf cGZucyhzZWxmKToNCj4gKyAgICAgICAgIiIiIFBBR0VfREFUQSB3aXRoIHRoZSBwZm4gYXJy YXkgY29tcHJlc3NlZCB0b28gKGZsYWdzIGJpdCA4KSAiIiINCj4gKw0KPiArICAgICAgICB2 ID0gbGlieGMuVmVyaWZ5TGlieGMobGFtYmRhICpfOiBOb25lLCBsYW1iZGEgKl86IGIiIikN Cj4gKyAgICAgICAgRlJBTUUgPSBiIlx4MDRceDIyXHg0ZFx4MThceDcwXHg3MFx4NzIiICsg YiJceDAwIiAqIDkzDQo+ICsgICAgICAgIFBGTlMgPSBsaWJ4Yy5QQUdFX0RBVEFfRkxBR19D T01QUkVTU0VEX1BGTlMNCj4gKyAgICAgICAgTFo0ID0gbGlieGMuUEFHRV9EQVRBX0FMR09f TFo0DQo+ICsNCj4gKyAgICAgICAgZGVmIHJlYyhjb3VudCwgZmxhZ3MsIHBheWxvYWQpOg0K PiArICAgICAgICAgICAgcmV0dXJuIHBhY2sobGlieGMuUEFHRV9EQVRBX0ZPUk1BVCwgY291 bnQsIGZsYWdzKSArIHBheWxvYWQNCj4gKw0KPiArICAgICAgICAjIFR3byBmcmFtZXMgYXJl IGZpbmUgdW5sZXNzIHRoZXkgdG90YWwgOCAqIGNvdW50IHBsdXMgd2hvbGUgcGFnZXMsDQo+ ICsgICAgICAgICMgd2hpY2ggYSByZWNlaXZlciBpZ25vcmluZyB0aGUgZmxhZ3MgY291bGQg bWlzcmVhZC4NCj4gKyAgICAgICAgdi52ZXJpZnlfcmVjb3JkX3BhZ2VfZGF0YShyZWMoMTAy NCwgUEZOUyB8IExaNCwgRlJBTUUgKyBGUkFNRSkpDQo+ICsgICAgICAgIHYudmVyaWZ5X3Jl Y29yZF9wYWdlX2RhdGEocmVjKDE2LCBQRk5TIHwgTFo0LCBGUkFNRSArIEZSQU1FKSkNCj4g KyAgICAgICAgZm9yIGV4dHJhIGluICgwLCA0MDk2LCAyICogNDA5Nik6DQo+ICsgICAgICAg ICAgICBzZWxmLmFzc2VydFJhaXNlcyhsaWJ4Yy5SZWNvcmRFcnJvciwgdi52ZXJpZnlfcmVj b3JkX3BhZ2VfZGF0YSwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYygx NiwgUEZOUyB8IExaNCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG UkFNRSArIGIiXHgwMCIgKiAoMTI4ICsgZXh0cmEgLSAxMDApKSkNCj4gKw0KPiArICAgICAg ICAjIFRoZSBwZm4gZnJhbWUgaGFzIGEgd2hvbGUgaGVhZGVyLCB3aXRoIGJsb2NrIGNoZWNr c3VtcywgYW5kIHRoZXJlDQo+ICsgICAgICAgICMgYXJlIHBmbnMgYXQgYWxsLg0KPiArICAg ICAgICBzZWxmLmFzc2VydFJhaXNlcyhsaWJ4Yy5SZWNvcmRFcnJvciwgdi52ZXJpZnlfcmVj b3JkX3BhZ2VfZGF0YSwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjKDE2LCBQ Rk5TIHwgTFo0LCBGUkFNRVs6Nl0pKQ0KPiArICAgICAgICBzZWxmLmFzc2VydFJhaXNlcyhs aWJ4Yy5SZWNvcmRFcnJvciwgdi52ZXJpZnlfcmVjb3JkX3BhZ2VfZGF0YSwNCj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgcmVjKDE2LCBQRk5TIHwgTFo0LA0KPiArICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRlJBTUVbOjRdICsgYiJceDYwIiArIEZSQU1FWzU6XSAr IEZSQU1FKSkNCj4gKyAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMobGlieGMuUmVjb3JkRXJy b3IsIHYudmVyaWZ5X3JlY29yZF9wYWdlX2RhdGEsDQo+ICsgICAgICAgICAgICAgICAgICAg ICAgICAgIHJlYygwLCBQRk5TIHwgTFo0LCBGUkFNRSArIEZSQU1FKSkNCj4gKw0KPiArICAg ICAgICAjIEJpdCA4IG5lZWRzIGEgY29tcHJlc3Npb24gYWxnb3JpdGhtLCBhbmQgb25lIHRo aXMgY2hlY2tlciBrbm93cy4NCj4gKyAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMobGlieGMu UmVjb3JkRXJyb3IsIHYudmVyaWZ5X3JlY29yZF9wYWdlX2RhdGEsDQo+ICsgICAgICAgICAg ICAgICAgICAgICAgICAgIHJlYygxNiwgUEZOUyB8IGxpYnhjLlBBR0VfREFUQV9BTEdPX05P TkUsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGUkFNRSArIEZSQU1FKSkN Cj4gKyAgICAgICAgc2VsZi5hc3NlcnRSYWlzZXMobGlieGMuU3RyZWFtRXJyb3IsIHYudmVy aWZ5X3JlY29yZF9wYWdlX2RhdGEsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgIHJl YygxNiwgUEZOUyB8IChMWjQgKyAxKSwgRlJBTUUgKyBGUkFNRSkpDQo+ICsNCj4gICANCj4g ICBjbGFzcyBUZXN0TGlieGwodW5pdHRlc3QuVGVzdENhc2UpOg0KPiAgIA0KDQo= --------------W15pEi6wuN509Z44wy00nuHv-- --------------dcO9JO7r0YNu0VoWenQeFcHl 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+p0QLLz9AFAmrjOegFAwAAAAAACgkQZg+p0QLLz9Af wwv+OC0gQ28baGkYZSXgPdiekqIA7x70wnSGxBMgqwdbUmoll4qy+MeBZpx26S98O66gxGD1arTy 0Ow2v+UxXvPuOwoEpWvfhCokMxGPu6TAX2/9F+Dk0nsBQO33/rRLAux9SWNwF6CGuaxWCQcY8Jr4 47vhIj/YcA6W4uFVoqe7ZzxY+jX57QOZEHPXsYe2yUHaLqrEG/TfEt4qN11GSKUB/iemM18F2DRd df9Tvp93+DWsfjnHngnZN4LF872UG8OcNr/edB2gx1nlTST+7pYTgMttqcSfCEA3yicbiwSPteY7 OXInsYcALZD9fKBIrUFcw37OYNGXuT2Q8oRzyP8gE1KJU+SgOCvnJ9A0h3hO+2NHgFduk2PVkKI9 l1DDYI+7JWCzgkhGbDL3U3rcY28puq4jdyKxYfN3bXjtwgmMAmMnxNtJmXNYzzlUDDZNt/32njy4 n7am7gWHkj5Sb8htdc0dgZrs7zYW8S+E4ujzcXM2gaglmYIKbe2IvjAgizXv =gfu7 -----END PGP SIGNATURE----- --------------dcO9JO7r0YNu0VoWenQeFcHl-- From xen-devel-bounces@lists.xenproject.org Thu Oct 29 12:48:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 12:48:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464616.1675452 (Exim 4.92) (envelope-from ) id 1xMPY6-00025S-RD; Thu, 29 Oct 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 1464616.1675452; Thu, 29 Oct 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 1xMPY6-00025L-OH; Thu, 29 Oct 2026 12:48:06 +0000 Received: by outflank-mailman (input) for mailman id 1464616; Thu, 29 Oct 2026 12:48:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMPY5-00022H-CF for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:48:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMPY4-006Sth-P3 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 13:48:04 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3407d-2eae-0a2a0a5409dd-0a2a4508ce5e-22 for ; Thu, 29 Oct 2026 13:48:04 +0100 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 6ae34084-f659-0a2a45080019-d1558034b8c5-3 for ; Thu, 29 Oct 2026 13:48:04 +0100 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4a5177d78c7so20707315e9.2 for ; Thu, 29 Oct 2026 05:48: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-4aa7f418afbsm75021295e9.6.2026.10.29.05.48.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 05:48: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=1793278084; x=1793882884; 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=B4flZ5y66HJMbxZCV71RggMQe1+QymcPJJkwz7Ikx+8=; b=A6uDX1pK5CxG1EyeBBfWKljYkqQJataB3R3eGgdCV+HVj5lq3K8TGBsaKGdOY+4Rwd dvEWFA5ijPDhrxMZVLKJdyGWvT87cjMnFmRp2Zh6AYj07ob2AuGMCR69Lnx4CcZylAT6 GZfBJeoBlBZUYf2+rXvpM3W0cu1VfvGGfXhnN28wJD37epy/q36rfZFNAH4NKDlwHcRN RMVrctq+wEoZNfO03l+Y4HvYZrvy3hwawEQ6iUsYdFgSRCgg0UNoiSnJ5fwusSFJwtz6 psb2+orMV6SA1aA7dwIoesXoLkICNE2GyOSMqzqyDgr++tWe8Ej/9YHFyPVtpE0DesBo /b8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793278084; x=1793882884; 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=B4flZ5y66HJMbxZCV71RggMQe1+QymcPJJkwz7Ikx+8=; b=lHUZQ6B1R9Sa60x09jGbJgdqWavR0tU3QlxW7gR+WDKPVbP3ep5nIo9r4+n3Ha8luw IwAMAVjl+ENS1W8RbOjME9he9oXrn2ZSUNYHVLYVy/7rURGVDYQCu/f9/bdxDior13EI Nle7Su+PbvZ5IGZ464TKbMP5dtyTI3IpN+ABeoy/5MH6nx1qE4kg46nxwb/VwraMqUDG lN1bfCU1DHeWhuZWabwHqxh1uW95VZCGl9w8xMoGjiEmyFtGOeRwe9MyRItYdwVnnoH4 OUenTzqkjVX1eSoGTgYqPfYo4uMVd7/KuBlzxWATH68sMJade3Y7JByvwYdzkYTg3CC/ l6Ug== X-Forwarded-Encrypted: i=1; AKwUvBwUoULlfVNJtguXDVy7FhI6Wkdj7voiA0E6cqFOwKm3YJLjV1VIMhey75IvcRTrWoojIRPPzd9WC4k=@lists.xenproject.org X-Gm-Message-State: AFq9FYL3pMIKW539oN/MI5Z30AJv8MkGRI4OudgWoscSnwJvxngYlx8k ZN6W2EFjFZ4AddDI4lhEXa42nYBoUjwptZDC0DW65Myam7AXp8IoYwlPuiC4bHD0Yw== X-Gm-Gg: AYBFou08H9XzwsT39318nEtcOx0qYu0imS39+YCQzP0Jq8twvYUdevutJ7gI91ehR4T H2rIG0diyMVjLg/d7WGxC5pHisTjeb8bA3jRhSxhZkopEcapA0EMlid/1LmuG+OsY/bfDYHrEjR 391sJbTCblaAIt1upl+D3Lpru7gX+jlWD7HmnJu89p5dKl9ad7SnWXT7v4Uk7g4fTPATGLKBBj+ Hwf61ie1pvtrv5hX8ni8rWb7MNEmiXyIHTEL2I81dSL/fwg788TH3gQpx/rgA3uH/N6AOHprZGQ +E9FwoXOzxF9K+96llrxNvEkcMZuWTb0ImnSqsuW+6gSU6KH3SKlwBWWxkdaTqDvoByD2K1hUv2 9+OjO5/YiiPWzzXyd4FUsjX5Q2qLHk3xDqVR4GHbm1JIgRr4bOUVoXMnGuxvKaxsJE117yoc7tG aCMvgyaSsDU92UDn0Dh0EuJJjIelMIrS2UTTDsj4bkENbZ76Bj+Q4LeYR8MY6QcYDPvyOczk5US q4xZnzb9XI1WfIHwXm8yZ5GiMcmn0yMNj1zsZLlGL45GVDU3McJ6iBoCY/boiblxtAYdR0U9blr J+MeW0/UIdXWA1MDJui1VfQQiKh4M0pih9pRqf3nQJ78NdGtPRWOMHBLHx+71jfzIWcdMARMZgj b7j/Ikplc36QQ3Xba5w== X-Received: by 2002:a05:600c:154e:b0:4a1:7bd4:d07d with SMTP id 5b1f17b1804b1-4a967e8d5a3mr118099775e9.34.1793278083814; Thu, 29 Oct 2026 05:48:03 -0700 (PDT) Message-ID: <071c17d3-1cb9-4a37-bbf3-eb3b87910aaa@suse.com> Date: Thu, 29 Oct 2026 13:48:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/irq: further gate PIRQ usage for HVM domains To: Roger Pau Monne Cc: Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20261029100741.42711-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: <20261029100741.42711-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1793278084-CEF5F87B-EC7EDF96/10/78276251493 X-purgate-type: spam X-purgate-size: 1412 On 29.10.2026 11:07, Roger Pau Monne wrote: > Further restrict PIRQ usage for HVM domains not having the ability to route > device interrupts over event channels. > > It's still possible for HVM domains without PIRQ support to exercise the > vector == 0 path in hvm_inject_msi(), which is intended to be used only > when the guest has PIRQ support. Taking the PIRQ path in hvm_inject_msi() > inhibits the local APIC from raising an ESR error when the MSI vector is > 0, since an MSI with vector == 0 is always processed as a PIRQ. Introduce > a has_pirq() check in hvm_inject_msi(). > > EVTCHNOP_bind_pirq is also not outright blocked for HVM domains without > PIRQ support, so guests could attempt to bind device interrupts to event > channels. Short-circuit evtchn_bind_pirq() early if the domain has no PIRQ > support. > > Additionally introduce an assert in map_domain_emuirq_pirq() to ensure it's > never called from HVM domains without PIRQ support. > > Finally add an extra check in hvm_domain_use_pirq() so it returns false > unconditionally if the domain has no PIRQ support. Also convert the > is_hvm_domain() check into an ASSERT(); this helper is never called against > a PV domain. > > Fixes: b96b50004804 ("x86: remove XENFEAT_hvm_pirqs for PVHv2 guests") > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Oct 29 12:57:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 12:57:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464626.1675461 (Exim 4.92) (envelope-from ) id 1xMPhH-0004AU-Kw; Thu, 29 Oct 2026 12:57:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464626.1675461; Thu, 29 Oct 2026 12:57: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 1xMPhH-0004AN-Hp; Thu, 29 Oct 2026 12:57:35 +0000 Received: by outflank-mailman (input) for mailman id 1464626; Thu, 29 Oct 2026 12:57:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMPhG-0004AH-I6 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 12:57:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMPhF-00DZEH-Mk for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 13:57:33 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae342b5-e002-0a2a0a5209dd-0a2a4506e00e-22 for ; Thu, 29 Oct 2026 13:57:33 +0100 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 6ae342bd-195a-0a2a45060019-b9ff1c23a6ff-3 for ; Thu, 29 Oct 2026 13:57:33 +0100 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 1a187bca9f9000f79f.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 12:57:30 +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 CDB848320C; Thu, 29 Oct 2026 13:57:29 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=+70eyE3X6IsSBex8TdzPcAkuLluLxz5+DRwG0WXzX+I=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=KZ+bAEqD75pOYtlJjAy3GTwGDd1j0rv+Yxn17fow9O1y2MmeE7Wse+GLIy/FeQI4hroEG9lsj E5DfnRUCbTgTlPG0/PRRJAL74dQN8MyFDdFMLtBz1SfZYtcqw6/PiVsLesxwj1LD8bhncR06tK4 hAQISt9doc3G7TrMh/xIlrr7vijtiBqohQUBLD4Veab1hHiHMNMOkOu9XhrXNc+WAfvDP5hZb1H f5zzX+2Au7DlukNpB7dsuUyxYNuJiyJiodKmQ9DfAd8j75X2M157PvSgukTXRtvNxN5rqFt92a1 kTOOLoM7AfRligerTDUQp19DBhxSoysFVaVeBXTqetIA== X-Zone-Loop: 54ae748d6f19ceba5a5ee13a9de816fb145ea567b517 x-campaign-type: default x-transaction-id: ff76729d-898d-4710-9284-4c9e0718f428 x-swg-uid: 01-84da4322-ba3c-41f3-9e97-869232345588 X-Mailer: Sweego Message-ID: <1793278650.8631fc262581453bbf619ec5b2062170.1a187bca9f9000f79f@vates.tech> x-swg-bid: 1793278650.8631fc262581453bbf619ec5b2062170.1a187bca9f9000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 29 Oct 2026 13:57:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1793023450.8631fc262581453bbf619ec5b2062170.1a178869cb4000f79f@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="------------cRIqAiRTBpkpGa5LXnR00jHG" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793278649937 X-purgate-ID: tlsNG-16d1c6/1793278653-1EAC277B-D936BDBD/10/78276251493 X-purgate-type: spam X-purgate-size: 8745 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cRIqAiRTBpkpGa5LXnR00jHG Content-Type: multipart/mixed; boundary="------------8nVVyAKIErrmnQ00ViOV5uCb"; protected-headers="v1"; hp="clear" Message-ID: Date: Thu, 29 Oct 2026 13:57:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1793023450.8631fc262581453bbf619ec5b2062170.1a178869cb4000f79f@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: --------------8nVVyAKIErrmnQ00ViOV5uCb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjgvMTAvMjAyNiDDoCAxMjoxNiwgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g MjYuMTAuMjAyNiAxNTowMywgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiBUaGUgSW50ZWwgU0RN IChWb2wgM0EtMTMuMTIuMTEsIEp1bmUgMjAyNikgc2F5cw0KPj4NCj4+PiBUaGUgc2VtYW50 aWNzIG9mIHNlbmRpbmcgYSBzZWxmLUlQSSB2aWEgdGhlIFNFTEYgSVBJIHJlZ2lzdGVyDQo+ Pj4gYXJlIGlkZW50aWNhbCB0byBzZW5kaW5nIGEgc2VsZiB0YXJnZXRlZCBlZGdlIHRyaWdn ZXJlZCBmaXhlZA0KPj4+IGludGVycnVwdCB3aXRoIHRoZSBzcGVjaWZpZWQgdmVjdG9yLg0K Pj4NCj4+IEhvd2V2ZXIsIHRoaXMgZG9lc24ndCByZXF1aXJlIGFsdGVyaW5nIHRoZSBJQ1Ig cmVnaXN0ZXIuDQo+PiBPbiBtb3N0IEludGVsIHByb2Nlc3NvcnMgKGF0IGxlYXN0IENvcmUv UC1Db3JlKSwgaXQgZG9lcyBhbHRlciBJQ1IsDQo+PiBidXQgaXQncyBub3QgdGhlIGNhc2Ug b24gQU1EIGFuZCBBdG9tL0UtQ29yZSBvbmVzLCBhbmQgQVBJQ3YgU2VsZi1JUEkNCj4+IGFw cGVhcnMgdG8gZm9sbG93IGEgc2ltaWxhciBiZWhhdmlvci4NCj4+DQo+PiBGb3IgY29uc2lz dGVuY3ksIGFkanVzdCB0aGUgWGVuIGJlaGF2aW9yIHRvIHNlbmQgdGhlIFNlbGYtSVBJDQo+ PiBkaXJlY3RseSBpbnN0ZWFkIG9mIGVtdWxhdGluZyBpdCBieSBtb2RpZnlpbmcgSUNSIHJl Z2lzdGVyLg0KPj4NCj4+IEl0IGFsc28gY2xhcmlmeSB0aGUgbG9naWMuDQo+Pg0KPj4gQXNz aXN0ZWQtYnk6IENsYXVkZSBGYWJsZSA1LjENCj4+IFNpZ25lZC1vZmYtYnk6IFRlZGR5IEFz dGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0KPiANCj4gUmV2aWV3ZWQtYnk6IEphbiBC ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gDQo+IEhvd2V2ZXIsIC4uLg0KPiANCj4+ IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdmxhcGljLmMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4 Ni9odm0vdmxhcGljLmMNCj4+IEBAIC05NzAsMTEgKzk3MCwxMyBAQCBpbnQgdmxhcGljX2Fw aWN2X3dyaXRlKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQgb2Zmc2V0KQ0KPj4gICAN Cj4+ICAgICAgIGlmICggdmxhcGljX3gyYXBpY19tb2RlKHZsYXBpYykgKQ0KPj4gICAgICAg ew0KPj4gLSAgICAgICAgaWYgKCBvZmZzZXQgIT0gQVBJQ19TRUxGX0lQSSApDQo+PiAtICAg ICAgICAgICAgcmV0dXJuIFg4NkVNVUxfVU5IQU5ETEVBQkxFOw0KPiANCj4gLi4uIHdoeSB0 aGUgZXh0cmEgY2h1cm4gaGVyZT8gVGhlIG92ZXJhbGwgaHVuayBoZXJlIC4uLg0KPiANCj4+ ICsgICAgICAgIGlmICggb2Zmc2V0ID09IEFQSUNfU0VMRl9JUEkgKQ0KPj4gKyAgICAgICAg ew0KPj4gKyAgICAgICAgICAgIHZsYXBpY19pcGkodmxhcGljLCBBUElDX0RFU1RfU0VMRiB8 ICh2YWwgJiBBUElDX1ZFQ1RPUl9NQVNLKSwgMCk7DQo+PiArICAgICAgICAgICAgcmV0dXJu IFg4NkVNVUxfT0tBWTsNCj4+ICsgICAgICAgIH0NCj4+ICAgDQo+PiAtICAgICAgICBvZmZz ZXQgPSBBUElDX0lDUjsNCj4+IC0gICAgICAgIHZhbCA9IEFQSUNfREVTVF9TRUxGIHwgKHZh bCAmIEFQSUNfVkVDVE9SX01BU0spOw0KPj4gKyAgICAgICAgcmV0dXJuIFg4NkVNVUxfVU5I QU5ETEVBQkxFOw0KPj4gICAgICAgfQ0KPj4gICANCj4+ICAgICAgIHZsYXBpY19yZWdfd3Jp dGUodiwgb2Zmc2V0LCB2YWwpOw0KPiANCj4gLi4uIGNvdWxkIGJlDQo+IA0KPiBAQCAtOTcz LDggKzk3Myw4IEBAIGludCB2bGFwaWNfYXBpY3Zfd3JpdGUoc3RydWN0IHZjcHUgKnYsIHVu c2lnbmVkIGludCBvZmZzZXQpDQo+ICAgICAgICAgICBpZiAoIG9mZnNldCAhPSBBUElDX1NF TEZfSVBJICkNCj4gICAgICAgICAgICAgICByZXR1cm4gWDg2RU1VTF9VTkhBTkRMRUFCTEU7 DQo+ICAgDQo+IC0gICAgICAgIG9mZnNldCA9IEFQSUNfSUNSOw0KPiAtICAgICAgICB2YWwg PSBBUElDX0RFU1RfU0VMRiB8ICh2YWwgJiBBUElDX1ZFQ1RPUl9NQVNLKTsNCj4gKyAgICAg ICAgdmxhcGljX2lwaSh2bGFwaWMsIEFQSUNfREVTVF9TRUxGIHwgKHZhbCAmIEFQSUNfVkVD VE9SX01BU0spLCAwKTsNCj4gKyAgICAgICAgcmV0dXJuIFg4NkVNVUxfT0tBWTsNCj4gICAg ICAgfQ0KPiAgIA0KPiAgICAgICB2bGFwaWNfcmVnX3dyaXRlKHYsIG9mZnNldCwgdmFsKTsN Cj4gDQo+IE11Y2ggY2xvc2VyIHRvIC4uLg0KPiANCj4+IEBAIC0xMDUwLDkgKzEwNTIsOCBA QCBpbnQgZ3Vlc3Rfd3Jtc3JfeDJhcGljKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3Is IHVpbnQ2NF90IHZhbCkNCj4+ICAgICAgIGNhc2UgQVBJQ19TRUxGX0lQSToNCj4+ICAgICAg ICAgICBpZiAoIHZhbCAmIH5BUElDX1ZFQ1RPUl9NQVNLICkNCj4+ICAgICAgICAgICAgICAg cmV0dXJuIFg4NkVNVUxfRVhDRVBUSU9OOw0KPj4gLSAgICAgICAgb2Zmc2V0ID0gQVBJQ19J Q1I7DQo+PiAtICAgICAgICB2YWwgPSBBUElDX0RFU1RfU0VMRiB8ICh2YWwgJiBBUElDX1ZF Q1RPUl9NQVNLKTsNCj4+IC0gICAgICAgIGJyZWFrOw0KPj4gKyAgICAgICAgdmxhcGljX2lw aSh2bGFwaWMsIEFQSUNfREVTVF9TRUxGIHwgKHZhbCAmIEFQSUNfVkVDVE9SX01BU0spLCAw KTsNCj4+ICsgICAgICAgIHJldHVybiBYODZFTVVMX09LQVk7DQo+PiAgIA0KPj4gICAgICAg Y2FzZSBBUElDX0VPSToNCj4+ICAgICAgIGNhc2UgQVBJQ19FU1I6DQo+IA0KPiAuLi4gdGhp cyBodW5rIHRoZW4uIChJIG1heSB0YWtlIHRoZSBsaWJlcnR5IG9mIG1ha2luZyB0aGF0IGFk anVzdG1lbnQgd2hpbGUNCj4gY29tbWl0dGluZywgdW5sZXNzIHlvdSBwcm92aWRlIGEgcmVh c29uIGZvciB0aGUgYmlnZ2VyIGNoYW5nZS4pDQo+IA0KDQpObyBzdHJvbmcgb3BpbmlvbiBv biBpdCBub3Igc3BlY2lmaWMgcmVhc29uLg0KDQpUbyBtZSwgZ2l2ZW4gdGhhdCB3ZSBkb24n dCB1cGRhdGUgSUNSIGFueW1vcmUgYW5kIG5vIGxvbmdlciBuZWVkIHRvIA0KZmFsbHRocm91 Z2ggdGhlIHJlc3Qgb2YgdGhlIHJlZ2lzdGVyIHdyaXRlIGxvZ2ljLCB3ZSBjYW4gaW52ZXJ0 IHRoZSANCmNoZWNrIHRvIGhpZ2hsaWdodCB0aGUgU0VMRl9JUEkgY2FzZS4NCg0KPiBKYW4N Cg0KVGVkZHkNCg== --------------8nVVyAKIErrmnQ00ViOV5uCb-- --------------cRIqAiRTBpkpGa5LXnR00jHG 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+p0QLLz9AFAmrjQrkFAwAAAAAACgkQZg+p0QLLz9AT gQv/emNE3RRH3EsGP3DrrR5JxeBWggY5l030K/AorXS4BiMU8S5r3W0ELhK+9LtAMa/3htI8y4PO EPEFCgV0F/XCzWWegzDVuGiAjF+dp/42l529N7Gkp+6hfx50WKY95iitlEa8X64jXqoKAIDhTPob /j67F/+vFQ+xzKn/mFIKinMmbO9rIGtg2nACd2+4ufyTMngh4E8Vpzw6VVjgDMO8GR2/fix0uCMp WwH0goDETEvKhm/mGXFCUACKgW7xkl4YaBQRpiHE59OjR35XebFba2NLknhDjFJvxHE0c+aEF/7q XGA99LuUJOOnR3sW6UUM3rqZI2vN6k6owuz8VOMOfHD1z/VruYTE+rtbOzsssg/So3GqNYg9U1Gj fHMhd3HC+0ng/ISKUjm/vo0ZNItfazU4VJl/TM2WYClHbGYd3JtvkEnrurnesGErCbBWRtsvsOMI T+dy0ljysDB66N3OSsaMdgrGVvH3DjJSkzzhl7UJyenU8FMRryvfdDq6nYSD =UiBj -----END PGP SIGNATURE----- --------------cRIqAiRTBpkpGa5LXnR00jHG-- From xen-devel-bounces@lists.xenproject.org Thu Oct 29 13:56:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 13:56:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464687.1675558 (Exim 4.92) (envelope-from ) id 1xMQc1-0007dz-Gr; Thu, 29 Oct 2026 13:56:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464687.1675558; Thu, 29 Oct 2026 13:56: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 1xMQc1-0007ds-E0; Thu, 29 Oct 2026 13:56:13 +0000 Received: by outflank-mailman (input) for mailman id 1464687; Thu, 29 Oct 2026 13:56:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMQbz-0007dm-Tb for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 13:56:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMQbz-00AYpF-6G for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:56:11 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae35060-2eae-0a2a0a5409dd-0a2a450296b8-48 for ; Thu, 29 Oct 2026 14:56:10 +0100 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae3507a-6ca4-0a2a45020019-d155dd35b898-3 for ; Thu, 29 Oct 2026 14:56:10 +0100 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48c4be28b82so1918424f8f.2 for ; Thu, 29 Oct 2026 06:56: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-48e3ece14a1sm35919655f8f.57.2026.10.29.06.56.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 06:56: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: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=1793282170; x=1793886970; 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=WB3lF7EPEE1aYa6kOgODxIiQOSUkR4cyg+8/BqTd+pY=; b=RziWUWgViTN+aBE0KgJCn9XnB34QXwT6NSmF/GUi4au248C88alkc8M3EYuQi3WHCn /wda7Fjt3W+04TEoyl1BTdAfmmjuS76zESxgIyrhTLh8fBciVM8bM2Q+TkuKkoNNL79I t2XJjnz39EZEzTRA5qyIOAoUD3VhMqxbrUFKOxcS9ugQiNjOuyq+NNmwEsFjtNHHp1i3 2Cwf5gTjhblPBwvtPjdAaVbP6H017lwRkk3gEVvLP/zx5zwYhuwnpTWmw7CrQItWiKmm NhTwOw7FsMZ86iJSlrmyNCeSyrNzL7QuaZHtIl9xCHu+5iQnOhIey2NhiPPL7s1iqe8I MzJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793282170; x=1793886970; 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=WB3lF7EPEE1aYa6kOgODxIiQOSUkR4cyg+8/BqTd+pY=; b=Dh7D09WT4a7lZgJigKpbj6W4NDKgX06qp9gzNaJAQaXI0/8+ppTIa4gqXNDrEzv9uq fwZilYineORfOBcLIkdGYSCh4Dmv0zs3HjSUfLTgWVkGcjj6iwXoQ10TntQhntGc6dMu RYVWQR2vCmt0FovojuT8w5fLJkigWuZ3um1SHquiJhufdYTnEy1nwVKtwMsgKx35k0Pf 4ZdfO92tYR/iY9/5FQyXb3xSF3D6wn8GfHymh+ri0OzuYnGSeVogpZXQUZiufsAmvfTZ kGA7BPJ8HkPyoM6xnim0mWhdSyVHv3WurpDLEb9WrIlANNuVRZ3ejlo4YI5wzG/KD7sp 9SXQ== X-Gm-Message-State: AFq9FYIfQbmKUjN8hGXECQ+EOtSZeb4S6LXxzcQukLbUDGItSoTcuEda gYghjOkoAvA20nGxpZTswuXo+IiB0cEIMNb/FAjtsrfgLvnbUAOw486iq+eIPhSLGWNKQCrcIT5 53R5p5w== X-Gm-Gg: AYBFou1hk4QUFXa6aFenct0tsuMsqblcvVP2M6FcV0OS9/f4j67i8c0/74LIoTJ3Wuj xo604BtT+5AfRmpY/ErsLP9wmJLvKnD7QRVBjkhrP0B3ngJa8L25FFShJLUdqEgO/3s3aZX+Qfh 5Y8bLRqxjNlW6d+WQq0+h9XdVHN7QPgEwFT0DrkjYRIt6gwpli+TWOe6vjH+wYRspr358zy7hXt 9p//7AXcIcCch4rui5Ii6wNHuBJgUmWTYIYw5e5Lp/cqt6NNx7F9R438GSa4DTlnBKlGyXVufXH Xp1rPWuw1ZcYcPoiKH1nQdbM4+4Gzfne4np1vWrJMvDbKuprPjXBILK1nwh9kObueVev98zzb5e yT/fnU66CKLaA+RAZB4xsf1kGe46NxAjV4VEk/NbilLvJJtPuoXpFsW0/RZFGvrChWNV5XD2Vps Jj0VrNYfZC+KoUnkHqIX3f8iRGeQ0o5YoAEzrUY/sDYY5hUJGtrmEJ6jTi2gphI9SKX3VO6Cf7t GtkT3s9Wsh/yxZSF2c1RE8HA/LS8m9YFNOZi2L14zbj0OMl++oVLgt12Mr4g065t/wJd0qCe8mm BjvLmTlbgobTKiwHIToDsPSqVolj18JVtgRuZxuyNkD0hV+tj2bTTcs7SllD7orKs7P9II3nH5l 8Ei+8vNRawh8Ri720ZQ== X-Received: by 2002:a05:6000:2006:b0:48d:faa4:5b66 with SMTP id ffacd0b85a97d-48e5d2f95cbmr13557122f8f.36.1793282170394; Thu, 29 Oct 2026 06:56:10 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 14:56:09 +0100 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: shrink (pack) struct periodic_time Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1793282170-30FCE2AC-9EFFA85F/10/78276251493 X-purgate-type: spam X-purgate-size: 1359 Except for warned_timeout_too_short, which is used with test_and_set_bool(), the booleans there don't need to occupy entire bytes. With them converted to bitfields, pending_intr_nr can move up into the vacated 4-byte slot. Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/hvm/vpt.h +++ b/xen/arch/x86/include/asm/hvm/vpt.h @@ -21,19 +21,19 @@ typedef void time_cb(struct vcpu *v, voi struct periodic_time { struct list_head list; - bool on_list; - bool one_shot; - bool do_not_freeze; - bool irq_issued; + bool on_list:1; + bool one_shot:1; + bool do_not_freeze:1; + bool irq_issued:1; + bool level:1; bool warned_timeout_too_short; - bool level; #define PTSRC_isa 1 /* ISA time source */ #define PTSRC_lapic 2 /* LAPIC time source */ #define PTSRC_ioapic 3 /* IOAPIC time source */ u8 source; /* PTSRC_ */ u8 irq; + uint32_t pending_intr_nr; /* pending timer interrupts */ struct vcpu *vcpu; /* vcpu timer interrupt delivers to */ - u32 pending_intr_nr; /* pending timer interrupts */ uint64_t generation; /* distinguish two armings of the same timer */ u64 period; /* frequency in ns */ s_time_t scheduled; /* scheduled timer interrupt */ From xen-devel-bounces@lists.xenproject.org Thu Oct 29 13:57:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 13:57:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464698.1675568 (Exim 4.92) (envelope-from ) id 1xMQcw-00089B-U4; Thu, 29 Oct 2026 13:57:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464698.1675568; Thu, 29 Oct 2026 13: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 1xMQcw-000894-R5; Thu, 29 Oct 2026 13:57:10 +0000 Received: by outflank-mailman (input) for mailman id 1464698; Thu, 29 Oct 2026 13:57:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMQcv-00088s-0m for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 13:57:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMQct-006hLb-DP for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:57:08 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae350b1-2eae-0a2a0a5409dd-0a2a45059e4c-2 for ; Thu, 29 Oct 2026 14:57:05 +0100 Received: from [18.219.209.13] (helo=gorgon.relay-egress.a.mail.umich.edu) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae350af-4cb1-0a2a45050019-12dbd10dde22-3 for ; Thu, 29 Oct 2026 14:57:04 +0100 Received: from truthful-redcap.authn-relay.a.mail.umich.edu (ip-10-0-73-72.us-east-2.compute.internal [10.0.73.72]) by gorgon.relay-egress.a.mail.umich.edu with ESMTPS id 6AE350AF.782D12D.52E9F640.1881737; Thu, 29 Oct 2026 09:57:03 -0400 Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by truthful-redcap.authn-relay.a.mail.umich.edu with ESMTPSA id 6AE350AE.16D3188D.71A5AF08.3104888; Thu, 29 Oct 2026 09:57:02 -0400 Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-3ab27e45e7cso17532241fa.3 for ; Thu, 29 Oct 2026 06:57: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=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=1793282222; bh=t2D2sDXKQ7pTvv07EdWL5pfAbbyJ8r7Apbn+VFhH/8s=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=VR9MHA3vsSRWMzPxx2B8UTIvRCUHyqwLaTdoTlk+rDlBtV4oPpLp9wPhQd8s9jKSl 1nzF0Q5pgOM3Cvf94A+HmFg4E+9B+GC5A9KE/OyNGcekIlkTbMdXRDHazsorfCHPin OL/ThspPHDgmTmK0ualzqXt9CLfO5kO8Gp8zROyFhq40TKQ879FO3g82hpEUmjhFzz ENkQe0YrKvZKQlEv9NWey1VXCX5+O+yZrby2LHZ7RkmtCJUgItMSoSQ871TWwjMXuG i5Ca5sLr1UwAnv07vjmtLxyTUnF8RASHgLl1PjquYn/rljmeZCL+bvoo+2pGe0T7Sj yoHtKEIh0BeNQ== Authentication-Results: truthful-redcap.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; AKwUvByg+DyvYcUw+/dNxPwW38GmbQ0jvGWJTXENMZSMAvMdraPZNqPGCN+d4XocDzeMM/SQaEErZXgboW0=@lists.xenproject.org X-Gm-Message-State: AFq9FYI2u/nGR9SECthm3Hkyxn1hs4lEe/GL3svFdzAHDU9VWjjFlV7k GG9GL37dI+yUMboImAEsA8qCCxzvgRkOlz++gCliVytrm9mBgnIN71nl/jUIvmUu6Os0GP57Bvf LGGkqdOdymDB6cIQSn+f04m9igH443Ko= X-Received: by 2002:a2e:9a0f:0:b0:3a9:740d:51cb with SMTP id 38308e7fff4ca-3ac9cf41afamr13635901fa.14.1793282220534; Thu, 29 Oct 2026 06:57:00 -0700 (PDT) MIME-Version: 1.0 References: <942facb0-c42b-4f09-9081-6cfb006c7bfc@suse.com> <9e587bff-7fb9-416e-a4b6-6cb13ec39a6a@suse.com> In-Reply-To: <9e587bff-7fb9-416e-a4b6-6cb13ec39a6a@suse.com> From: George Dunlap Date: Thu, 29 Oct 2026 13:56:48 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK-x4L2Ja3WMp7g9hGbNhdv3Ydefs7MYYmMen48nofFc2DGFRV60MZ5KVPU Message-ID: Subject: Re: [PATCH 2/2] x86: replace this_cpu() uses in mapcache_current_vcpu() To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1793282225-728B62A1-55CCC43A/10/78276251493 X-purgate-type: spam X-purgate-size: 3529 On Tue, Oct 13, 2026 at 12:52=E2=80=AFPM Jan Beulich wr= ote: > >> Like indicated in the earlier patch, this similarly leads to the funct= ion > >> actually being inlined (and hence generated code size actually growing= ) in > >> gcc16 debug builds. In release builds (with older gcc) the function is > >> being inlined no matter what. Overall, having looked at generated code > >> differences, I'm not quite sure anymore whether the earlier observed > >> inefficiency with repeated this_cpu() really is much of an issue (here= or > >> maybe even more generally). > > > > I think we sometimes focus too much on this kind of > > micro-optimizations when the cost of the operation itself is orders of > > magnitude bigger than any performance difference the optimization > > might cause. > > Well, any improvement we can reasonably (and safely) make counts. Even > if not measurable performance-wise, it may still make a difference > (also in power consumption) when accumulated over long enough a period. If we had an infinite amount of developer and reviewer attention, this would be true; if for instance we could have LLMs just review and check in patches they were confident of. But reviewer bandwidth is in fact a major bottleneck; the fact that Roger and I are looking at this patch now means we're not looking at some other patch. > > In this case I don't think the resulting code is bad or harder to > > read, so I don't mind adjusting the logic. But that's a question of > > taste, if someone else has a preference for the original form I > > wouldn't change it. > > I'll give it some time for comments to that (or any other) effect. FWIW, having already looked at the patch, I don't mind either way. "this_cpu()" is slightly more readable; one could argue that per_cpu(foo, cpu) sort of implies that it could be a *different* cpu -- at very least someone reading the code has to go check at least once. And again, human cognitive effort is the main bottleneck for a correct, feature-ful, and performant hypervisor. But both the potential efficiency win, and the potential cognitive load, are so small that I don't feel like it's a clear win either way. So I would leave it off, but if you'd rather: Reviewed-by: George Dunlap > >> --- a/xen/arch/x86/domain_page.c > >> +++ b/xen/arch/x86/domain_page.c > >> @@ -20,7 +20,8 @@ > >> > >> static inline struct vcpu *mapcache_current_vcpu(void) > >> { > >> - const struct vcpu *v =3D this_cpu(pgtable_vcpu); > >> + unsigned int cpu =3D smp_processor_id(); > >> + const struct vcpu *v =3D per_cpu(pgtable_vcpu, cpu); > >> const struct vcpu *curr =3D current; > > > > Maybe you can reorder the variables here: > > > > const struct vcpu *curr =3D current; > > unsigned int cpu =3D curr->processor; > > const struct vcpu *v =3D per_cpu(pgtable_vcpu, cpu); > > The use of curr->processor in the remark in patch 1 was safe afaict. > I'm not fully sure the one here would be safe: It would require > thorough auditing of scheduler code to be sure, I think. (I don't > _think_ ->processor would be altered from a remote CPU, but I'm not > entirely certain.) Claude points out that curr is never dereferenced, only compared; so the code as it is works before `current` is set. The first map_domain_page() comes long before `current` is set in init_idle_domain(), so Roger's version crashes during boot (Claude verified this). -George From xen-devel-bounces@lists.xenproject.org Thu Oct 29 13:59:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 13:59:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464704.1675576 (Exim 4.92) (envelope-from ) id 1xMQfF-0000PP-87; Thu, 29 Oct 2026 13:59:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464704.1675576; Thu, 29 Oct 2026 13: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 1xMQfF-0000PI-5Q; Thu, 29 Oct 2026 13:59:33 +0000 Received: by outflank-mailman (input) for mailman id 1464704; Thu, 29 Oct 2026 13:59:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMQfD-0000PC-Jd for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 13:59:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMQfD-006hw8-0G for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:59:31 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3513a-bab6-0a2a0a5309dd-0a2a4506e970-24 for ; Thu, 29 Oct 2026 14:59:30 +0100 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 6ae35142-195a-0a2a45060019-b9ff1c2296f9-3 for ; Thu, 29 Oct 2026 14:59:30 +0100 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 1a187f55469000f79f.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 13:59:24 +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 8DEA881F81; Thu, 29 Oct 2026 14:59:23 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=ngP0V0CyZiKEvVbwG2RaqA/mms4DwbxyAVzE2p6XZ8w=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=axBkBCVtoIkuwe/uTmbCOgyp4IYk6Nf+ySZAbDXJU60o4D2PQhANh1VTlqCEIA3ST8Z6lHjDX JClMnNem4Ei+MCw0k/UI/54b0cV9tcS9HAdB/Zs4+J9bpMC4j52lWW991Zbjb9u9aGmfxOB4FUp aJjE84+vo0GJ9ofC/xNyNQnQGbAc/4UbZN0KEJqxu0hzQal18lcE/usVBSmFo4mbBYi2BV/CdDf 76dRxeHbShwmKbjiqYWMmKElggoUPc1AzakQIeHg4/oYCItiO6D8oO4DsOwclm6YsvCz7NB1LMX X4is/ci8ycncJ6iFueBeEcAMAXpZ+KLYd4rKSiev2iJw== X-Zone-Loop: ecf0d029a7fa486bf737e2443a8f28174620dbf1e55c x-campaign-type: default x-transaction-id: affd84d6-5218-4cdd-81dc-fa2c1a18e225 x-swg-uid: 01-ad61ac13-1048-4442-a97d-a2ea33ac3558 X-Mailer: Sweego Message-ID: <1793282364.8631fc262581453bbf619ec5b2062170.1a187f55469000f79f@vates.tech> x-swg-bid: 1793282364.8631fc262581453bbf619ec5b2062170.1a187f55469000f79f 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 , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] common: Convert !test_bit(_VPF_down) into is_vcpu_online() Date: Thu, 29 Oct 2026 14:58:47 +0100 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2e1.2451c527bc220225.1a187f551a5.6ccfb3988fd86c8c=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793282363817 X-purgate-ID: tlsNG-16d1c6/1793282370-FCC0777B-72A9A542/0/0 X-purgate-type: clean X-purgate-size: 4611 ---=Part.2e1.2451c527bc220225.1a187f551a5.6ccfb3988fd86c8c=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Do the same for test_bit(_VPF_down) into !is_vcpu_online()=2E No functional change=2E Signed-off-by: Teddy Astie --- xen/arch/arm/domctl=2Ec | 2 +- xen/arch/arm/traps=2Ec | 2 +- xen/arch/arm/vgic=2Ec | 2 +- xen/arch/arm/vpsci=2Ec | 4 ++-- xen/arch/x86/pv/shim=2Ec | 2 +- xen/arch/x86/traps=2Ec | 2 +- xen/common/domain=2Ec | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/domctl=2Ec b/xen/arch/arm/domctl=2Ec index b76af56fad=2E=2E292cc92159 100644 --- a/xen/arch/arm/domctl=2Ec +++ b/xen/arch/arm/domctl=2Ec @@ -203,7 +203,7 @@ void arch_get_info_guest(struct vcpu *v, vcpu_guest_co= ntext_u c) ctxt->ttbr1 =3D v->arch=2Ettbr1; ctxt->ttbcr =3D v->arch=2Ettbcr; =20 - if ( !test_bit(_VPF_down, &v->pause_flags) ) + if ( is_vcpu_online(v) ) ctxt->flags |=3D VGCF_online; } =20 diff --git a/xen/arch/arm/traps=2Ec b/xen/arch/arm/traps=2Ec index 6a5dcef2aa=2E=2E47a5c6bdd4 100644 --- a/xen/arch/arm/traps=2Ec +++ b/xen/arch/arm/traps=2Ec @@ -1004,7 +1004,7 @@ static void show_guest_stack(struct vcpu *v, const s= truct cpu_user_regs *regs) void *mapped; unsigned long *stack, addr; =20 - if ( test_bit(_VPF_down, &v->pause_flags) ) + if ( !is_vcpu_online(v) ) { printk("No stack trace, VCPU offline\n"); return; diff --git a/xen/arch/arm/vgic=2Ec b/xen/arch/arm/vgic=2Ec index acded6a40f=2E=2E062238a899 100644 --- a/xen/arch/arm/vgic=2Ec +++ b/xen/arch/arm/vgic=2Ec @@ -818,7 +818,7 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v,= unsigned int virq, } =20 /* vcpu offline */ - if ( test_bit(_VPF_down, &v->pause_flags) ) + if ( !is_vcpu_online(v) ) { spin_unlock_irqrestore(&v->arch=2Evgic=2Elock, flags); return; diff --git a/xen/arch/arm/vpsci=2Ec b/xen/arch/arm/vpsci=2Ec index ac6af6118f=2E=2Eb2b6b4c98d 100644 --- a/xen/arch/arm/vpsci=2Ec +++ b/xen/arch/arm/vpsci=2Ec @@ -85,7 +85,7 @@ static int do_common_cpu_on(register_t target_cpu, regis= ter_t entry_point, if ( is_64bit_domain(d) && is_thumb ) return PSCI_INVALID_ADDRESS; =20 - if ( !test_bit(_VPF_down, &v->pause_flags) ) + if ( is_vcpu_online(v) ) return PSCI_ALREADY_ON; =20 rc =3D vpsci_build_guest_context(v, entry_point, context_id, &ctxt); @@ -195,7 +195,7 @@ static int32_t do_psci_0_2_affinity_info(register_t ta= rget_affinity, v =3D d->vcpu[vcpuid]; =20 if ( ( ( v->arch=2Evmpidr & tmask ) =3D=3D target_affinity ) - && ( !test_bit(_VPF_down, &v->pause_flags) ) ) + && ( is_vcpu_online(v) ) ) return PSCI_0_2_AFFINITY_LEVEL_ON; } =20 diff --git a/xen/arch/x86/pv/shim=2Ec b/xen/arch/x86/pv/shim=2Ec index 41000b0523=2E=2E8ec03d7295 100644 --- a/xen/arch/x86/pv/shim=2Ec +++ b/xen/arch/x86/pv/shim=2Ec @@ -404,7 +404,7 @@ int pv_shim_shutdown(uint8_t reason) /* Stop the singleshot timer=2E */ stop_timer(&v->singleshot_timer); =20 - if ( test_bit(_VPF_down, &v->pause_flags) ) + if ( !is_vcpu_online(v) ) BUG_ON(vcpu_reset(v)); =20 if ( v !=3D current ) diff --git a/xen/arch/x86/traps=2Ec b/xen/arch/x86/traps=2Ec index ac01ba0872=2E=2E5a702fe22c 100644 --- a/xen/arch/x86/traps=2Ec +++ b/xen/arch/x86/traps=2Ec @@ -918,7 +918,7 @@ void vcpu_show_execution_state(struct vcpu *v) { unsigned long flags =3D 0; =20 - if ( test_bit(_VPF_down, &v->pause_flags) ) + if ( !is_vcpu_online(v) ) { printk("*** %pv is offline ***\n", v); return; diff --git a/xen/common/domain=2Ec b/xen/common/domain=2Ec index 6b52713518=2E=2E167338f360 100644 --- a/xen/common/domain=2Ec +++ b/xen/common/domain=2Ec @@ -2190,7 +2190,7 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUE= ST_HANDLE_PARAM(void) arg) =20 case VCPUOP_down: for_each_vcpu ( d, v ) - if ( v->vcpu_id !=3D vcpuid && !test_bit(_VPF_down, &v->pause= _flags) ) + if ( v->vcpu_id !=3D vcpuid && is_vcpu_online(v) ) { rc =3D 1; break; --=20 2=2E56=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.2e1.2451c527bc220225.1a187f551a5.6ccfb3988fd86c8c=--- From xen-devel-bounces@lists.xenproject.org Thu Oct 29 14:01:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 14:01:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464712.1675586 (Exim 4.92) (envelope-from ) id 1xMQh9-00028S-KB; Thu, 29 Oct 2026 14:01:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464712.1675586; Thu, 29 Oct 2026 14: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 1xMQh9-00028L-Gd; Thu, 29 Oct 2026 14:01:31 +0000 Received: by outflank-mailman (input) for mailman id 1464712; Thu, 29 Oct 2026 14:01:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMQh7-00028F-Jd for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:01:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMQh6-00EaIW-IQ for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:01:28 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae351b0-8faa-0a2a0a5109dd-0a2a450be634-28 for ; Thu, 29 Oct 2026 15:01:28 +0100 Received: from [18.217.159.240] (helo=ghoul.relay-egress.a.mail.umich.edu) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae351b7-b7e8-0a2a450b0019-12d99ff0bb74-3 for ; Thu, 29 Oct 2026 15:01:28 +0100 Received: from decisive-ogre.authn-relay.a.mail.umich.edu (ip-10-0-74-246.us-east-2.compute.internal [10.0.74.246]) by ghoul.relay-egress.a.mail.umich.edu with ESMTPS id 6AE351B7.1DE87A9.24AD4C46.470894; Thu, 29 Oct 2026 10:01:27 -0400 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by decisive-ogre.authn-relay.a.mail.umich.edu with ESMTPSA id 6AE351B6.13F504AD.6F1516D9.381346; Thu, 29 Oct 2026 10:01:26 -0400 Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-3ab27e45e7cso17601451fa.3 for ; Thu, 29 Oct 2026 07:01: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=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=1793282486; bh=Sd1w4bHSdg3R4jiuILygJQGmcBR09WjXKUsgSFB9ebw=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=D58r4Zi4gm+/Vb039WFtkeLQ7p4W1EASdJ7O7gyF/5qko9aGm+/F53dCpzOn9NGhp wJiZ6otSEoQAPYGQ9FWzpU3Rp0OVbE7bVOj2FY1ru3/9MU5sEn6BhOTfGMQ/Gz3FtO u8jXnt8I9m5FSgHGxfFGTYmEm24CH6DP0zqWEivURG0JQE+Nooeu1794sJC4Bq1Pb5 Yz4O/XMo2MnXmbleJ+n7IxwnSS5+kuRLAAXXO8GAAXRtESBsALQe1HjVL63VakXCSm 6vydwtvboWprii69kikcW5/rFq9lHO6+vDi6PvbwupebHLJ49aLaLlRuXbgFbUmaOL E4vQKWF04fzwg== Authentication-Results: decisive-ogre.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.208.173 (mail-lj1-f173.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvByy6xnkeaIRwVKFBD0comXal5wicX28T81se7RSv7l8zSe1soYSt3IzafSgiZ+0TW472ag6qis+V+o=@lists.xenproject.org X-Gm-Message-State: AFq9FYJNlg9tnd9kTRVPVC3OPgFVfcJOlbnY9LFssK7d0kqDgiy0BiMv KuVM7ebflziJlamE3P0o5VOkn7ilTHodXAqR5umswSI4Ud4cWjLyOTnElE12EV3LGuNmgElBlJN G+kZXAp08785/haxBxqCyc+V0JQV8HzU= X-Received: by 2002:a05:651c:2101:b0:3ac:433c:6ab7 with SMTP id 38308e7fff4ca-3ac9cf5d61bmr12688761fa.16.1793282484708; Thu, 29 Oct 2026 07:01:24 -0700 (PDT) MIME-Version: 1.0 References: <942facb0-c42b-4f09-9081-6cfb006c7bfc@suse.com> <9e587bff-7fb9-416e-a4b6-6cb13ec39a6a@suse.com> In-Reply-To: From: George Dunlap Date: Thu, 29 Oct 2026 14:01:12 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK8DREOvbKJAs3FrxJ5Hb-yhXQ1KKnhm8erfiUaBoft96R_JT-SBUvWhnrw Message-ID: Subject: Re: [PATCH 2/2] x86: replace this_cpu() uses in mapcache_current_vcpu() To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1793282488-19CC79EA-11F1AF98/10/78276251493 X-purgate-type: spam X-purgate-size: 3485 On Thu, Oct 29, 2026 at 1:56=E2=80=AFPM George Dunlap w= rote: > > On Tue, Oct 13, 2026 at 12:52=E2=80=AFPM Jan Beulich = wrote: > > >> Like indicated in the earlier patch, this similarly leads to the fun= ction > > >> actually being inlined (and hence generated code size actually growi= ng) in > > >> gcc16 debug builds. In release builds (with older gcc) the function = is > > >> being inlined no matter what. Overall, having looked at generated co= de > > >> differences, I'm not quite sure anymore whether the earlier observed > > >> inefficiency with repeated this_cpu() really is much of an issue (he= re or > > >> maybe even more generally). > > > > > > I think we sometimes focus too much on this kind of > > > micro-optimizations when the cost of the operation itself is orders o= f > > > magnitude bigger than any performance difference the optimization > > > might cause. > > > > Well, any improvement we can reasonably (and safely) make counts. Even > > if not measurable performance-wise, it may still make a difference > > (also in power consumption) when accumulated over long enough a period. > > If we had an infinite amount of developer and reviewer attention, this > would be true; if for instance we could have LLMs just review and > check in patches they were confident of. But reviewer bandwidth is in > fact a major bottleneck; the fact that Roger and I are looking at this > patch now means we're not looking at some other patch. > > > > In this case I don't think the resulting code is bad or harder to > > > read, so I don't mind adjusting the logic. But that's a question of > > > taste, if someone else has a preference for the original form I > > > wouldn't change it. > > > > I'll give it some time for comments to that (or any other) effect. > > FWIW, having already looked at the patch, I don't mind either way. > "this_cpu()" is slightly more readable; one could argue that > per_cpu(foo, cpu) sort of implies that it could be a *different* cpu > -- at very least someone reading the code has to go check at least > once. And again, human cognitive effort is the main bottleneck for a > correct, feature-ful, and performant hypervisor. But both the > potential efficiency win, and the potential cognitive load, are so > small that I don't feel like it's a clear win either way. > > So I would leave it off, but if you'd rather: > > Reviewed-by: George Dunlap That said, Claude's analysis of the generated code doesn't give any benefits. Its take below. -George It saves no work in the generated code (gcc 16.2.0, staging 41ddcfe808): - Why: is_pv_vcpu() =E2=86=92 evaluate_nospec() is an asm volatile with a "memory" clobber. So the per-CPU offset is reloaded after it either way, whether it comes from cpu_info or from __per_cpu_offset[cpu]. Latching cpu only saves the %rsp arithmetic, and costs the processor_id load. - Release builds: the same number of loads on the common path, one instruction fewer, and map_domain_page/unmap_domain_page grow by 16 and 21 bytes. In release builds this code runs only for frames above 5 TiB anyway, because of the NDEBUG shortcut. - Debug builds: gcc inlines the function into both callers (.text +384 bytes, as Jan said), and the common path gains one load. So, as Roger said, it=E2=80=99s a matter of taste; the generated code gives= no reason to take it. From xen-devel-bounces@lists.xenproject.org Thu Oct 29 14:10:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 14:10:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464724.1675594 (Exim 4.92) (envelope-from ) id 1xMQpQ-00040H-CA; Thu, 29 Oct 2026 14:10:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464724.1675594; Thu, 29 Oct 2026 14:10: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 1xMQpQ-000402-9B; Thu, 29 Oct 2026 14:10:04 +0000 Received: by outflank-mailman (input) for mailman id 1464724; Thu, 29 Oct 2026 14:10:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMQpP-0003nS-99 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:10:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMQpO-00EcHm-LN for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:10:02 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae353b5-8faa-0a2a0a5109dd-0a2a4502a0cc-18 for ; Thu, 29 Oct 2026 15:10:02 +0100 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 6ae353ba-6ca4-0a2a45020019-d155dd36dc5d-3 for ; Thu, 29 Oct 2026 15:10:02 +0100 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48c5358fc28so1786410f8f.0 for ; Thu, 29 Oct 2026 07: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-48e3ecde7easm34896289f8f.52.2026.10.29.07.10.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 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=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=1793283002; x=1793887802; 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=73SYlDAtiP8uRUIaM56Lx7B0+YvsukeKtcFXE61sCsg=; b=VakVK9rGO1t5iXb7OioofJZq09Q0ftZrWHY41DcJvGx9lyOoQOAnGx6TQ7bRgPlb3k gbQwSTVUOvnLr+KAEHybmXLzHq+CYHlNM7hBtjgRiwhFayEYpyalY6lrURyJsU88k1NL h/KciUbYN14LKjriRmLEzzxuBzB8Nh43liDERf94qJzeZpfPygL77syCpbJQUWJCnTPC kUrsMWMbXrSvrk5wOAZs3KuWXGenPHpI5jKmMkDyhOjSVuDrYlYgRL16S9HGbJTogK/0 NYvDVMAP6OG992velSYZC3srvp9yxCvCdGyZWk2xDnpyOwRJbdCRGDLmnmpJhvH6DC14 +T8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793283002; x=1793887802; 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=73SYlDAtiP8uRUIaM56Lx7B0+YvsukeKtcFXE61sCsg=; b=Qo6QoHlHW2IdWF8bT7iVPiCwlurTmk8O+n/fQpXHgMXhZ1QmgTxa9rpDUnt6bcQhev oYk9M+zjUJWJtSTRHogfYKxKP09RKpZF6D1jPdiCPr/BdOHxKfsFlZUU9oWt9zHkToBA JF00JZpWmuyHtgEOthVIktozw3XJFUgfChj+A8dEVQKH39bzwUUm2MpmSOsdvTX8RndK uLDkGXN9VUr6e97ccU/j1czE9mgJ3nL87mkOC3kryQymONY2zQMPRE7esVbEcanFotjy iRjEm5g+Q9DDgeXeF9BKSdebu3udKLcx/VQCkbRDu/FT75K7Cr9/6sCplr+xaArAd1SS rl7g== X-Forwarded-Encrypted: i=1; AKwUvBy7u4uPNZ8PdERDmPTaViAVkS9yWWbpzSyToDNGAYqk4p03RlTwCTKjwSCnyxfiMKoswRw7DeOr2Jw=@lists.xenproject.org X-Gm-Message-State: AFq9FYLsi4msaSvozIanBLwYZmr8K/QMv6bks2p2htbWirXRscJzK1/u ZHEkTgJU4MubbgdfWVk7MtcfKGUI0hUyznENrcnmoYfAzfqBV7LqOsu54osemNI23w== X-Gm-Gg: AYBFou1nORKuVJX0p07PBPT/KsEPWzSS0d6MikREsEwiebWgBPdu7NXRpotAMQuDKFk 8r+a9MUoZE0obwKVajONe5qMpSnjV4N/tJt4GoMn16W9ZDo2x8eWDjI5YL614vCAwhCLWM+3/Ij 56Ko9nqq8hUCSlUWHxj9qbyfKecUy01AUwz6btPUX/9815BuHVO4gl3pgPkIBL1G1hNuBTj70Nl g8OUsnnkDXrNZLEIDMM1CE8ow59kQn57hvAPkf2RRct4kXWWePcJ6rOxDbikyPiksyBKtZQu+4w RV55CeNrxqBrFLfd5vVRCHIMUZY80wTmA7CnXTb6VXNalwZkoLYI+Q0VwyfpNk1VXeWXfm31Id2 9TCArSSRkTSrw9zL0IgAQX8GMrh2qdze7xi250rFsT0B9wpUGuxD66h3QqPMj2rIkRpfCcKBj1c rLcUYaNi06KWtRcuXYKY4Dlypt084S5pu5IptiTdF1wGCjEAJMLXwg/UCJE1EntoBPYF2HksPk8 x9TGL5ZyNYkQ6s5CSqbvr4QW4Wz9PVgD/ACYevozVeUjympgNs7BtJcFxUIQnbYDVEs+b+0ETvP bAedF8DpqlD9loFrmckWVP1Kn+BnSQRa8ZbJhZf4weKojWEa7WrJ76951Kq4d2Z2CQbICfdYgen yD7I1qvq01xS7ewYrtCQ= X-Received: by 2002:a5d:5f07:0:b0:48b:9d2:1a6a with SMTP id ffacd0b85a97d-48e5d45a3c2mr12403084f8f.1.1793283001749; Thu, 29 Oct 2026 07:10:01 -0700 (PDT) Message-ID: <482334fd-1b21-4541-a903-a9e7434daffe@suse.com> Date: Thu, 29 Oct 2026 15:10:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] common: Convert !test_bit(_VPF_down) into is_vcpu_online() To: Teddy Astie Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1793282364.8631fc262581453bbf619ec5b2062170.1a187f55469000f79f@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: <1793282364.8631fc262581453bbf619ec5b2062170.1a187f55469000f79f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1793283002-F0CA22AC-94E2C773/10/78276251493 X-purgate-type: spam X-purgate-size: 773 On 29.10.2026 14:58, Teddy Astie wrote: > Do the same for test_bit(_VPF_down) into !is_vcpu_online(). > > No functional change. > > Signed-off-by: Teddy Astie Reviewed-by: Jan Beulich with one nit addressed (can likely be done while committing): > @@ -195,7 +195,7 @@ static int32_t do_psci_0_2_affinity_info(register_t target_affinity, > v = d->vcpu[vcpuid]; > > if ( ( ( v->arch.vmpidr & tmask ) == target_affinity ) > - && ( !test_bit(_VPF_down, &v->pause_flags) ) ) > + && ( is_vcpu_online(v) ) ) With this the parentheses also want to go away. With them the stray extra blanks then will also disappear (at least from the line being touched). Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 14:23:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 14:23:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464744.1675603 (Exim 4.92) (envelope-from ) id 1xMR1y-0007H1-IP; Thu, 29 Oct 2026 14:23:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464744.1675603; Thu, 29 Oct 2026 14:23: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 1xMR1y-0007Gu-Ff; Thu, 29 Oct 2026 14:23:02 +0000 Received: by outflank-mailman (input) for mailman id 1464744; Thu, 29 Oct 2026 14:23:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMR1w-0007Go-US for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:23:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMR1w-00EetO-26 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:23:00 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae356bc-2eae-0a2a0a5409dd-0a2a4504c2ae-18 for ; Thu, 29 Oct 2026 15:22:59 +0100 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 6ae356c3-b57f-0a2a45040019-d155dd35d1cd-3 for ; Thu, 29 Oct 2026 15:22:59 +0100 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48e46e449e8so1321549f8f.3 for ; Thu, 29 Oct 2026 07:22: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-48e3ece14a1sm36030386f8f.57.2026.10.29.07.22.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 07:22: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: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=1793283779; x=1793888579; 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=p+iGOYeOpST/ZKq5PGKI70mfKnTWZbE50E0zGZEpHLY=; b=E+/aRNEgXG7Y7BhAsGt/yRI2A+WJZaIdqEF21rQDRaMV+LXb/flbwGM0zXec/j4Dts x79zuJ4pz7dkcb6Xnd+td1ufgNz/2MDkAFZWcv0vKWPupJTUkiGqQo2+T4juo+zEmx0V ycgv4uIPar0BcFRGPz0pdL7Cw2Azdgfb8LIErgR01wvEDVPANPaom6MEJz/3QH1BhXc1 x7oYF2WFfqP4gnbVjKTjqVh/ZgmdslvlQHe7K5x2qmkiU9o0YABoqHMq9USdr3rsZoro cxd/Hqp4VdcCemiW4uty1YI9DkB75JWXjGK87C6SBmaEWtxTE+xW8Cml+kYAbG4xT3oX Xt8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793283779; x=1793888579; 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=p+iGOYeOpST/ZKq5PGKI70mfKnTWZbE50E0zGZEpHLY=; b=iajTv/FKjIbEdDOIh7kXzOZoDwRpGpJws6ldPDk7P+si8bN9CjK64lZac8DUGmF/wg RdX4H1AbgKmkEWgs+wFPH27IVuIiHtSmBjxjQ1wp4CQDU1R3+RSPGlck5BxQDP3PJDUr rVVITT8VvWVLlo6QcPDvpRtdSB+RF3IB0UE1BunHGghZoYmYuxNvGn/py7qGZHwyAb5/ nY47w6hnXbph8e0Cibs3bFy3Vlg2rY8uyVOA8IjbUpODRsvp/KYwjLZRdEZCtrrnS3Fq R9HKBMHCTU6Jl6SpF4cEA5QKJBS9ifo8CmtaerHxrGei7xyE3gzX4AU0rZHe3NuVx8jt 2Plw== X-Gm-Message-State: AFq9FYLXtiKRtvW1JdHI9kvp4nAYkIWtFuXPfwPs25AAmt4b/DAOIMnD IDyxlLfSU49x2NBrm4tGWe0zkb6nEXPp67p3VrEII989pLd1XQMzU1sGJircWC6tKPKnvnlkmfo IPq1neQ== X-Gm-Gg: AYBFou3KTRDyWjIVrXzRPUX4Dq7vIOeNqGjl+Jghpogukkto64OLk2PlYpC7eCqUL7P LBoWQ86ef/fsNk7eP3pnFVxexDCSxWV8V/tdBBWWeTPtfZr46r1PzjcgwUihCxPpBS6Xy5grTzS buNgR7YHQ14OSXkL3VSZsq5ghSzyavky4pkcLitnj8Z5qrxYLjoYgU7rAJggDgKsiQ7A23TZgho 9Q+gsBg9rk9Ue3vGPa4OPY13mJ/D1vuQox8C9HTGHWwe5be2ESUslS0ZizCRo8pQo5SnIe4KnwE x2o+z/OLwbnAHjlIPTNJAW1lm1cPbV2c+uGhhIQZw4d9KeUbzu7Z3r8aTxXEmeLkagww1RyNmD7 k/2LNfFfZEu1/LxvqBTAHjmLdSeyKa7ozMAsj2DhsL0bMtE6HtjItt3FynjVYj1rnGD00bY6DCi ElTf+/4sttf/mRyl0BYxwPwKlJ8KuCywDUcHLMsJRazxSihs3TafewXaY6oL2UR++tf6NK3mkAz gQwRnggZqXG9S09SvL/0PsJIUMBw7QwZUnTb0L/jzMvvPosM1oxcRqci0FL3gZDO7rGKyT5861t KrFMFQ/kxKv6jzEYmUljqIPutJsRHpKG58hI9WU62qV6XmSmq9yI+RKoZUvOiDrg1hKDwzcW+fO z7p/jbWFpc3JqOSUN1dg= X-Received: by 2002:a05:6000:989:b0:48b:123e:2f5c with SMTP id ffacd0b85a97d-48e5d2f2222mr13334782f8f.29.1793283778402; Thu, 29 Oct 2026 07:22:58 -0700 (PDT) Message-ID: <37c9675b-dc2b-4c57-b5a8-79075836311b@suse.com> Date: Thu, 29 Oct 2026 15:22:57 +0100 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/4] x86: yet more PCI locking adjustments Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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/1793283779-C26CAB50-5D25D625/10/78276251493 X-purgate-type: spam X-purgate-size: 272 Continuing from 13efde94f4af ("x86/vPCI: tighten locking assertions"). 1: physdev: use less heavy locking in physdev_unmap_pirq() 2: IRQ: use less heavy locking in free_domain_pirqs() 3: MSI: drop redundant checking 4: tighten PCI-related locking assertions Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 14:23:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 14:23:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464749.1675613 (Exim 4.92) (envelope-from ) id 1xMR2t-0007m7-Qj; Thu, 29 Oct 2026 14:23:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464749.1675613; Thu, 29 Oct 2026 14:23: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 1xMR2t-0007m0-O2; Thu, 29 Oct 2026 14:23:59 +0000 Received: by outflank-mailman (input) for mailman id 1464749; Thu, 29 Oct 2026 14:23:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMR2s-0007lr-QE for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:23:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMR2r-00Ds5q-SS for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:23:57 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae356fc-e002-0a2a0a5209dd-0a2a450b9308-8 for ; Thu, 29 Oct 2026 15:23:57 +0100 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae356fd-b7e8-0a2a450b0019-d1558036c13c-3 for ; Thu, 29 Oct 2026 15:23:57 +0100 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4a5036bbac7so14118835e9.3 for ; Thu, 29 Oct 2026 07:23: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-4a96989ab11sm82364085e9.1.2026.10.29.07.23.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 07:23: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: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=1793283837; x=1793888637; 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=bZ36Ue2o7QdpI26tm3fbDKjPhI0zCZm7YgWfiKnDmR0=; b=Bx8LgsQ/fspTtyjJ9/ksT+G//jZzTn2JPLUfQGR1izQWrAtwmXzgnGXO2iwGAHcz6d 3B+RydIaQ9rMjFrXGN3Cxwhb9vO2m/vnKTxeOQQCHrAvsjQ79DbMzSm7A22aHgXDgRnX 5l8rplZfsVzha35OlSdco5KNitCvJm1gaSEXDcqfbKQtuP0/b234MOVi8GZifqT/qSo5 Fr5EB4K8arNxedmmYZzMLj6dqR1f4l8jBp6BKf/ktLfjsPuWC35hAo8t2bqix7qFOnvq mYYDFDapmJT71GaMIGxT00eRNn39SKbf5O8a4Bv89Ezr6OgVor1g8Fj6tDw/U8uyKwmH VwmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793283837; x=1793888637; 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=bZ36Ue2o7QdpI26tm3fbDKjPhI0zCZm7YgWfiKnDmR0=; b=n9gTMtBYqnCDfBOGsy1xbhql3CWEEEuvcWmDJJhLSABaOgjA7DFNYtkUIS1QtQr0rC YYputRmN7Wr4vnRJuEWtCG5Vbn4era6XWpm83qwIAsdzI8qP7GXTjFpgFr57mp9iSiTi TZU4nBpdsBJ05XTgBmlkLTvmDy0ZcQ9bTb4JGP2wtkX/acipvqmi19DWtwWWmb6opifJ CO07htmY4FCHucuh4VwlQz9PWKPt54a7roliHOdUKirnYY+oAqZqgeAxInqtr1H25inr N8bslfGTV7O7KkBXmquKIddSDlfpOOv+5Hv9ZSxnBVZvBF608Kt2bRvhyfPqa6m5xwwC Y1QA== X-Gm-Message-State: AFq9FYL/TvNWXviItNG0EXvCAKJAo252DKVS4Up+0Yl7RtKB7q9XYrGW 9/cvkp85sn36zmHwe8InpeyGGQnBVAEnjAVU6m+Eh5bKOLWqBRy65FefQh9p0aCYcZsG4BxreE6 9w4DOlg== X-Gm-Gg: AYBFou0xMkyeUpwzK2w94kbwAzfThSPG33KU2QGxIqOB1vKGVg+I6KYfbg/soO7PlbU hZzMGWwjAjZXIG0tpG6F9rqOw6AvSKt6aZe81nK9SMy9a+AcCw35Y5Jb4GW1xUKSRO7l17o4Ych MY2hTHAN3GHvUfuGNa9FvWUfDccywZnHeVNPYruMRveaZlO3VLq+0guzbUynBSVLKvF8ftGootP eZrKMo9cEoxKSTMj0v0NEqTEyzVcBwNP/Q9UiLEIwwcYH0rrYk7034P+bu52LXRAMNZ2Y0mlQIq AGViUkvGngZVtNMmDVQeyrb7AA1Gv5LApD85XECeLJnl3blN0veHvCsgutVjj/5BphVTWfFQDi9 JGs1H2ExEO0HcrIGwPYOa4A5UqtK+Jm6B3zQHphLYypACqOd6lh6l0JaQi3vAvxWj2A5o/7+bJb Flfa4yzrVz3u8wDf7iRbLuZnqtXNsPrL17igJUKc6JAEyN/pJEGV8geauD3k/F0ANTXeXHLVa84 99Cnu4G0vCJBkcTN7IoITY8IZkuJeCOEkVf9GvXRahOSeBoLaBAMqNDvPQaRrf0aR8hMFd8hrM/ FmbiBzNSgw31wuTS4Y7rLCIKy4lYv4KK3tkJCNu6L3U4F5Tss43jm4QrE2HAs1NlGush6MbhC7V CjV+SQjmQu46PVbcU32tNEjqOfdM2DD0DC4NhSg== X-Received: by 2002:a05:600c:37c9:b0:4a5:26b8:4507 with SMTP id 5b1f17b1804b1-4a9678c281fmr125754845e9.21.1793283837136; Thu, 29 Oct 2026 07:23:57 -0700 (PDT) Message-ID: <7dc9e911-73f7-4efb-8132-b9f6a5fafc0a@suse.com> Date: Thu, 29 Oct 2026 15:23:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/4] x86/physdev: use less heavy locking in physdev_unmap_pirq() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <37c9675b-dc2b-4c57-b5a8-79075836311b@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: <37c9675b-dc2b-4c57-b5a8-79075836311b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1793283837-1A2C49EA-6D9CAA72/10/78276251493 X-purgate-type: spam X-purgate-size: 623 Like its mapping counterpart, in the GSI case no (PCI-related) lock would be needed at all, while in the MSI cases the domain's PCI lock is sufficient to hold. Signed-off-by: Jan Beulich --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -156,11 +156,11 @@ int physdev_unmap_pirq(struct domain *d, return ret; } - pcidevs_lock(); + read_lock(&d->pci_lock); write_lock(&d->event_lock); ret = unmap_domain_pirq(d, pirq); write_unlock(&d->event_lock); - pcidevs_unlock(); + read_unlock(&d->pci_lock); return ret; } From xen-devel-bounces@lists.xenproject.org Thu Oct 29 14:24:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 14:24:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464752.1675622 (Exim 4.92) (envelope-from ) id 1xMR3C-00086t-1b; Thu, 29 Oct 2026 14:24:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464752.1675622; Thu, 29 Oct 2026 14: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 1xMR3B-00086m-UR; Thu, 29 Oct 2026 14:24:17 +0000 Received: by outflank-mailman (input) for mailman id 1464752; Thu, 29 Oct 2026 14:24:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMR3A-00086D-Os for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:24:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMR3A-00DsED-5N for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:24:16 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3570e-bab6-0a2a0a5309dd-0a2a450bd84a-4 for ; Thu, 29 Oct 2026 15:24:16 +0100 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 6ae3570f-b7e8-0a2a450b0019-d1558029a8ef-3 for ; Thu, 29 Oct 2026 15:24:16 +0100 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4a5720b0a57so4528035e9.0 for ; Thu, 29 Oct 2026 07:24: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-4aa7f3229dbsm68552185e9.1.2026.10.29.07.24.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 07:24: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: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=1793283855; x=1793888655; 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=/YI/rf/n23fQGH/Iy0R9KMpw9J7mM7Lajb7NLc/3zO0=; b=GWYiXUlEcFWCl3szdHf3QD5LopAKDbK/WKITUMx8JJ+U3hC4xiovd8KZLqxvExL0Vx QZsUDdt4w2wZqBdxlIysyZLdHd4tSSO9DoMks/8+TAkpxjEvJ786j8M2dUJF9qBXU9v9 KU97VO916kZ5PFDu/ssTZynCdmVnMsJ5PF9QbAEd7gjChUXEiZRMEoxqAtTQyZfRnHol tXnpu4sTJIrFszETbpDD0/CRrFU5JZk4NSWqMmOYYLYxPVky+EQlO3Rr1xZHBUtrpWkS D91tmzz88oqtA/OoBBhAFbfLM72eFbNjz+4SqsDOm9mS6EG0JKUZQ8+O/EZJ2qxR87U7 PVnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793283855; x=1793888655; 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=/YI/rf/n23fQGH/Iy0R9KMpw9J7mM7Lajb7NLc/3zO0=; b=OoUo5XqOoE1j6+Iwrl7/ELhHvIebLCUm1i3ohls1TIDdygMLMyw5SC2Eke3ZRB6fRQ iNthDubq5GyhbL3jw9qXMUHdWNRFeQtS5rS7lXY8XyyPIseJcskDlbwzB898nacAzSk5 Wm5BcYiDupCFbn1vEA3weDhiEZLaYGPlLmpXQZr9BQR0VZqL/X48w0rDKuzkMWpdttes GgpnmF2H5Vftqi9RhRiG/m0zWbcDFuEQuKiLNTypgqMqt33usb3moz61HR+d2w8ArL0l UfXMbX3edvvwySQt3YKkH463fAkrVcMLNSc2cVT0lCFH4BfSU0ImCBanil+0dxlYpuGg k1lg== X-Gm-Message-State: AFq9FYJZQnQWwItHUtjcL8rXVGdMrz/xi+K7SSnaamXnc8YofX0t9n43 7Qe4vGzZD+QHWaQCRIYTEOZr8wRDri79ATuOvGN62lhFJ4w5MtupXewmuNtRmWB/ROV+NJzy5PD NNUvtOw== X-Gm-Gg: AYBFou2UrfRdw9c1GkAfWUOwZeYwKVanlxk6mI2wlYfXJT3ABI47O0hlPIab5poldwV SJOa0ekoP/kRRrtnVoQF2aI/4Gxi+BR9JURy1PezbeWqWR435vlyxtSOCsg9N6//SaBOEJlgZr0 izl/ntCk299jVad0QKx7yG0DyN3izv0FPPdIGnkQO1GHB2RlRamFnQ/n1xnyN/eoPE+MjYXKSSo l/LstJAWUmH1kU+rPZnp0WtpO+dRTIuP6t9+ur1hJlcwOtv50kBURDhLp/gfAd9uWx4yTjW4jSH CQy1HNVRWxNCILZLQbNr8yDTOIbrXWbKHyMqD2LZxNlyrHKFuZ7o78ppFH9Aa28et0N71CpmLbH P7t4f7nstrG4wKRoYgYkXFoYhLVmeu+Xu3FxyWpOtNc2LbfjB3JCuXJZTJOSaCxh7okL7D6sDZD Qs7kmQatPg1hzPkI5hLv/57BkE9PnkF2WZXTbuTs3/bozAGWry7WrWCuruPy4m3xfcMu94kzeD9 hPLL6+Ry+CvggnbdL6476NRvlJmAB+eoxYakf3PZzeM8atgTznZOviZkSc7WLAcEVh5da+oqkmY 3iy7D1lBqOIp3G/m9UBh1QO1dhhx/mnp4Cu2p0/cx5E7JB9CxOFK0zSZEdlcfWTZ7f5RGwjCIhQ DwUJIWSU+UG5gNqLZYZU= X-Received: by 2002:a05:600c:8485:b0:4a1:88df:8a2a with SMTP id 5b1f17b1804b1-4aa87d6fcdamr68907565e9.13.1793283855467; Thu, 29 Oct 2026 07:24:15 -0700 (PDT) Message-ID: <12b095ad-2fbf-4964-bad0-ae930009a22f@suse.com> Date: Thu, 29 Oct 2026 15:24:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/4] x86/IRQ: use less heavy locking in free_domain_pirqs() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <37c9675b-dc2b-4c57-b5a8-79075836311b@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: <37c9675b-dc2b-4c57-b5a8-79075836311b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1793283856-A84CB9EA-8F7B13F9/10/78276251493 X-purgate-type: spam X-purgate-size: 681 Holding the domain's PCI lock (alongside its event lock) is sufficient around unmap_domain_pirq(). Signed-off-by: Jan Beulich --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2516,7 +2516,7 @@ void free_domain_pirqs(struct domain *d) { int i; - pcidevs_lock(); + read_lock(&d->pci_lock); write_lock(&d->event_lock); for ( i = 0; i < d->nr_pirqs; i++ ) @@ -2524,7 +2524,7 @@ void free_domain_pirqs(struct domain *d) unmap_domain_pirq(d, i); write_unlock(&d->event_lock); - pcidevs_unlock(); + read_unlock(&d->pci_lock); } static void cf_check dump_irqs(unsigned char key) From xen-devel-bounces@lists.xenproject.org Thu Oct 29 14:24:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 14:24:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464762.1675631 (Exim 4.92) (envelope-from ) id 1xMR3V-00009O-80; Thu, 29 Oct 2026 14:24:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464762.1675631; Thu, 29 Oct 2026 14: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 1xMR3V-00009G-52; Thu, 29 Oct 2026 14:24:37 +0000 Received: by outflank-mailman (input) for mailman id 1464762; Thu, 29 Oct 2026 14:24:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMR3T-00005w-EW for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:24:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMR3S-00HYM3-K0 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:24:34 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3571d-e002-0a2a0a5209dd-0a2a4503ba1a-4 for ; Thu, 29 Oct 2026 15:24:34 +0100 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae35721-fae8-0a2a45030019-d1558030a522-3 for ; Thu, 29 Oct 2026 15:24:33 +0100 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a9a8d6cea8so11347015e9.1 for ; Thu, 29 Oct 2026 07:24: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-4a94fce50a8sm98622605e9.4.2026.10.29.07.24.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 07:24: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: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=1793283873; x=1793888673; 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=YebI1vN0ZK8O/Ps+ugmtufrEhxG7UGyapyJh1x3BBgs=; b=OW+eCXWxAmwwAysEHVMvPfNxGglxjP/N91zxx+GTIWFQ8WTtH6Fei3hHhwApxSRHRS QL2C0ixrr5oWLxtzvkMBptHQn2xZeTcHNTDo1qnoe//e1xhKith5xoCEQPzy9RYidIWd aLB8RB1OTDbGDeZLWKtNjNVbQHvgPYCBcH0zGhmrHeXceKGx+SV79BrQjLNhcIcusvoa viEXiArg+aVS0L2rVf6wI1HlVZJO8Zo6xctdGQKemKHmom/+qLaBZyLBxieThCiJpDAq C6KDVg41X1gUxeQ9Tjll5AuMJQEDTuvQLJEWWh+ppJ1LpIssHrDFPiM0rsNhtsyFcA0t NWUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793283873; x=1793888673; 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=YebI1vN0ZK8O/Ps+ugmtufrEhxG7UGyapyJh1x3BBgs=; b=XvHzNAg0dTpsKGC9Myk2nujIGtNZ0GNFd0j+8GL8bjOMi0mIWqlstpsklSni2jCAsu KnneOqpkNCvKEO97fi9socQC21MpBhInYXONhAZ8NbfQCvUGibMU9/p9cHHQkMvBK08N uFjfpjhFv8qecL+8EQbYPt8GyP14ytwBILT4tJDY2Ki74dZhV3yX1qJzbXdoH3+7WywF ZKGY5+IZRuot2vvVaAkvN0x35nQGBdGjMLTx2Gl6TAXZ9piZ+n/Orq4SWngZKs9eXyRq HZtkEPcnOxYaFOjeS5lVnOQ+tmn1kd0YA+t5XMu5NFdpnCUbGwC4O2KY9jt7EMWiYXcW 5Txw== X-Gm-Message-State: AFq9FYLrkVrrSLGMQ+in2P3+QwLeGHJc1+Ojds3Dour/JKUZc4LxDwuR 3jh2DxKNWugmI+8rSwvhLPFdVwjPAB55lAna+jQLkuM/CH+2gWgB9H9GsTjyknqYVzPQcyhMf68 9FPL9Ng== X-Gm-Gg: AYBFou0eOiWzM1DG14yJuT25iUNtG5yEQ/LQQBahuRtbbZ2pHW8MKgXs20o7DmOx3XH MCpSqfGbIXtiq39THk88Zgs1o80YZU23TvRS7km1L7H4nviipKhCUs5UY6GhVu5BAIiqTBmW2v+ IF2GUeBO/FcqCtyGbT9ixSDSt7+2nysrOhrn800GLhywbNdiW4B0Y0wIGbFUIT82mHdjIOqnf39 NMy7yGwm7ocJAhrC16yxyxwwh46em//Oz9BPLaAtuoHKcSO3HYzHIq4FTrHeBfqJVKOjx2Vpscs dN3hZqRTahhK7q3XEyjaopTgRHqGscgBQ8++FMdNVAikA0n1o31aLWjDIvijAI++aRDIj288Gw+ C+QZwIN6awKJExWXKEGJIbCh9k8A21azIrdOLsGWe+aLWubz0LKlrnzFLhiPs5qwCnkamvRPhrX aGn2rCazSpQJOg9PHppbmJmkNtAO35z7+K6zrKsjycYudnEe9cGgd78TENDMPsJx8PUbRSJUdlF YCVg2GIWGWXbjhvP3u+DSVbwCcDWAScTINiy0SCyVzNVHfoDrSSenre9Du/OgbXfWiyl8QRziht pkp4BTxNp8XEok8M9YSVa0QthvR4gRhjR2PwZK6on9j2Jwk0jh1j+XlhyqD90K9gKT/M4DNOHJT ob/kBVmj7uwn0cfME4A== X-Received: by 2002:a05:600c:4694:b0:4a8:a341:2377 with SMTP id 5b1f17b1804b1-4aa86a4250dmr69301455e9.3.1793283873069; Thu, 29 Oct 2026 07:24:33 -0700 (PDT) Message-ID: <297da05f-756d-4af2-8784-5af3355ee121@suse.com> Date: Thu, 29 Oct 2026 15:24:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/4] x86/MSI: drop redundant checking From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <37c9675b-dc2b-4c57-b5a8-79075836311b@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: <37c9675b-dc2b-4c57-b5a8-79075836311b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1793283873-6F8C54E9-6CBF1CD3/10/78276251493 X-purgate-type: spam X-purgate-size: 1147 __pci_enable_msi{,x}() are local helpers of pci_enable_msi(). That one already checks for pdev to be non-NULL, and it also asserts the necessary locking state. msi_capability_init() in turn is a local helper of __pci_enable_msi(). Signed-off-by: Jan Beulich --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -600,7 +600,6 @@ static int msi_capability_init(struct pc unsigned int i, mpos; uint16_t control; - ASSERT_PDEV_LIST_IS_READ_LOCKED(dev->domain); pos = dev->msi_pos; if ( !pos ) return -ENODEV; @@ -1004,11 +1003,6 @@ static int __pci_enable_msi(struct pci_d { struct msi_desc *old_desc; - if ( !pdev ) - return -ENODEV; - - ASSERT_PDEV_LIST_IS_READ_LOCKED(pdev->domain); - old_desc = find_msi_entry(pdev, msi->irq, PCI_CAP_ID_MSI); if ( old_desc ) { @@ -1059,11 +1053,6 @@ static int __pci_enable_msix(struct pci_ { struct msi_desc *old_desc; - if ( !pdev ) - return -ENODEV; - - ASSERT_PDEV_LIST_IS_READ_LOCKED(pdev->domain); - if ( !pdev->msix ) return -ENODEV; From xen-devel-bounces@lists.xenproject.org Thu Oct 29 14:25:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 14:25:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464774.1675640 (Exim 4.92) (envelope-from ) id 1xMR45-0000nk-Jl; Thu, 29 Oct 2026 14:25:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464774.1675640; Thu, 29 Oct 2026 14: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 1xMR45-0000nd-H6; Thu, 29 Oct 2026 14:25:13 +0000 Received: by outflank-mailman (input) for mailman id 1464774; Thu, 29 Oct 2026 14:25:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMR44-0000nR-QB for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 14:25:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMR44-006n51-6v for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:25:12 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae35738-2eae-0a2a0a5409dd-0a2a4507c014-34 for ; Thu, 29 Oct 2026 15:25:12 +0100 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 6ae35743-b4ea-0a2a45070019-d155dd32add4-3 for ; Thu, 29 Oct 2026 15:25:07 +0100 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48e10a70540so1440443f8f.1 for ; Thu, 29 Oct 2026 07:25: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-48e3ece14a1sm36040424f8f.57.2026.10.29.07.25.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 07:25: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=1793283906; x=1793888706; 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=68xddbKpJuK9lRBNK1xmW0G0FAfxhT0/ZIkUKuJLHRk=; b=NBzA0J/U0jcd+felBqXsvsH5hcYYGcsKo4sJ6YLQFreHGBIvWsFZm8ROTvWUNd4XKZ N7fYBr0FA+XnfWSTRVFO2e9msqfjOCZ17fN/fEfz+CQ0gcogo1emCXVkXfV8rgxp3klQ lV1Siv+QLxV6TaZ6gvUDAnYFAUXF+0o3w4lMDVs8JXmW7Kg6ojQd8xTnlVrT2z3KyWZQ acJbKJUU/inmZu9wPUWyl0dWMYS1cVKeyre+b4Sb2tk8qBPRsxftPhXSCDIrA1tirLk3 xZ1eiSpG4QxrxNme6BZQysO9gMXtfxbXcs3rEQk9LxxdMLZpkgUywXaDU9TuO3uHUSCw TIpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793283906; x=1793888706; 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=68xddbKpJuK9lRBNK1xmW0G0FAfxhT0/ZIkUKuJLHRk=; b=mJSmooATdTvt5fxj0nIhycj4UpV/6OO+AMIr2EoBo249Ovi1UvchmY4IWUX/lumzdR 55LkJVPYsxi9IIJg7D+/7XBLJPMddUO3rPORMN62ss9EcjwZ04Jwki+cme3j8WyMzb+1 p4sfMf1WnQvE+fn0Qfm/lAvnGKnw942itYoMk0GZ7Eguk0QjL9o8SifJlS5dK0HIviek GU98MUd6TdwJCwRGSd3LoNG/MvREiBgSQUYEHQ+OtfqRqmUkyd1jTbVGYWUXMINxe649 a6GWOOZSs8+CerR3IxwrtLIO9R8Y6L/JvN+t1lAQThqnoOVZ/b3MIxCr/gv6LK8EyVef IXuA== X-Gm-Message-State: AFq9FYJ6v+FL3pPxeZC23LOZM6Gak7g1j+QZVUWizrWJB1xc2c7Vnt+3 x851dQxieEAGCUCLHQNWvorCI6phzSsP/LbWq2zuT49jaU2AXg0nTbRiy3rHcHaEMGhHvgRXrT+ BESJmdA== X-Gm-Gg: AYBFou0D7lSpANOsfdnVATmlcWDEeJGiaHoFmnJraDF7sO7fCCh02IiwXt9q3UVk1HN 0MZDOs8FH1SwT+/cRWR3dIux9ilvvK5kW2NnIBPCy8o9m1Bu2+gtY7lIj4Z/RLaMuTHBfHs42U9 QcsZLqYUDhHVBlFyt0ycUBDi19LXf5BVjjuReGK74+9e0gnvuupGuKWWwEfvs2X9sinlBYg7Qum VECWX+0hT5TPccPm2eZnBZ/d16gc9sDPMngtsAm7/JHqrf29GQ6WJJL3KgxgL/6E/WCEoELA00G 7U0pa6SJOyOd8WwOSkyRbwaMUUIv1w39+CEFcd7Q8uj0MEfQwUn3kv1KJ6YhBhfOVipTSTQsgiW mGTo4oNrWNBlUacXh1yObJ1ab2ZrmDCzeAvtMN1hF6Yv/5D7e5G0MkIjev59YSexzo9GE4suavW wOC+ECKiCLFomHr05oryrkdNm8sXjsAsuD3N+NSsb2bvVxRMrilGDLokHeBEwidQWkUCaQeDOAM lZvSJjM2T+PuXi+VxzQeoknNdddgUJQ5Ndzyn993u3+Q+KZvAmoEZDb9mMdva3MNYD5U6+skWi0 oMAot4GXpVtMy2+PgswdJ2AtHuTyfjowgtX1s0AwsYiMlJLIPVszYj3rYJ1nFj22M5phyWeLDrs ucfOybx9mLdGpCcri X-Received: by 2002:a05:6000:178a:b0:48d:e5c9:39a4 with SMTP id ffacd0b85a97d-48e5d5d0a3emr13312934f8f.33.1793283906515; Thu, 29 Oct 2026 07:25:06 -0700 (PDT) Message-ID: <5d5bc3c9-79ef-4a80-866b-8c374c4021e5@suse.com> Date: Thu, 29 Oct 2026 15:25:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/4] x86: tighten PCI-related locking assertions 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: <37c9675b-dc2b-4c57-b5a8-79075836311b@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: <37c9675b-dc2b-4c57-b5a8-79075836311b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1793283907-A48C9AE4-5FCFF87C/10/78276251493 X-purgate-type: spam X-purgate-size: 3615 With recent changes the .pi_update_irte() hook as well as {,un}map_domain_pirq() and allocate_and_map_msi_pirq() won't be called anymore with the global PCI lock held. Convert the assertions to check for just the domain's PCI lock. With that the somewhat ugly ASSERT_PDEV_LIST_IS_READ_LOCKED() isn't used outside of msi.c anymore, so move the #define there. Signed-off-by: Jan Beulich --- It being just two use sites which remain, we may want to do away with ASSERT_PDEV_LIST_IS_READ_LOCKED() altogether. Thoughts? (It also isn't qite clear to me why its #define(s) sit inside an #ifdef: The expression used ought to be fine to use also in release builds, as it looks.) --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -419,7 +419,7 @@ static int cf_check vmx_pi_update_irte(c spin_unlock_irq(&desc->lock); - ASSERT_PDEV_LIST_IS_READ_LOCKED(msi_desc->dev->domain); + ASSERT(rw_is_locked(&msi_desc->dev->domain->pci_lock)); rc = iommu_update_ire_from_msi(msi_desc, &msg); if ( rc > 0 ) --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2250,7 +2250,7 @@ int map_domain_pirq( struct pci_dev *pdev; unsigned int nr = 0; - ASSERT_PDEV_LIST_IS_READ_LOCKED(d); + ASSERT(rw_is_locked(&d->pci_lock)); ret = -ENODEV; if ( !cpu_has_apic ) @@ -2410,7 +2410,7 @@ int unmap_domain_pirq(struct domain *d, if ( (pirq < 0) || (pirq >= d->nr_pirqs) ) return -EINVAL; - ASSERT_PDEV_LIST_IS_READ_LOCKED(d); + ASSERT(rw_is_locked(&d->pci_lock)); ASSERT(rw_is_write_locked(&d->event_lock)); info = pirq_info(d, pirq); @@ -3021,7 +3021,7 @@ int allocate_and_map_msi_pirq(struct dom { int irq = -1, pirq, ret; - ASSERT_PDEV_LIST_IS_READ_LOCKED(d); + ASSERT(rw_is_locked(&d->pci_lock)); switch ( type ) { --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -737,6 +737,19 @@ static uint64_t read_pci_mem_bar(const s return (addr & PCI_BASE_ADDRESS_MEM_MASK) + disp; } +#ifndef NDEBUG +/* + * Check to ensure there will be no changes to the entries in d->pdev_list (but + * not the contents of each entry). + * This check is not suitable for protecting other state or critical regions. + */ +#define ASSERT_PDEV_LIST_IS_READ_LOCKED(d) \ + /* NB: d may be evaluated multiple times, or not at all */ \ + ASSERT(pcidevs_locked() || ((d) && rw_is_locked(&(d)->pci_lock))) +#else +#define ASSERT_PDEV_LIST_IS_READ_LOCKED(d) ((void)(d)) +#endif + /** * msix_capability_init - configure device's MSI-X capability * @dev: pointer to the pci_dev data structure of MSI-X device function --- a/xen/include/xen/pci.h +++ b/xen/include/xen/pci.h @@ -204,19 +204,6 @@ static always_inline bool pcidevs_tryloc return lock_evaluate_nospec(pcidevs_trylock_unsafe()); } -#ifndef NDEBUG -/* - * Check to ensure there will be no changes to the entries in d->pdev_list (but - * not the contents of each entry). - * This check is not suitable for protecting other state or critical regions. - */ -#define ASSERT_PDEV_LIST_IS_READ_LOCKED(d) \ - /* NB: d may be evaluated multiple times, or not at all */ \ - ASSERT(pcidevs_locked() || ((d) && rw_is_locked(&(d)->pci_lock))) -#else -#define ASSERT_PDEV_LIST_IS_READ_LOCKED(d) ((void)(d)) -#endif - bool pci_known_segment(u16 seg); bool pci_device_detect(pci_sbdf_t sbdf); int scan_pci_devices(void); From xen-devel-bounces@lists.xenproject.org Thu Oct 29 15:21:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 15:21:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464829.1675649 (Exim 4.92) (envelope-from ) id 1xMRvw-0003nd-Ld; Thu, 29 Oct 2026 15:20:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464829.1675649; Thu, 29 Oct 2026 15: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 1xMRvw-0003nW-II; Thu, 29 Oct 2026 15:20:52 +0000 Received: by outflank-mailman (input) for mailman id 1464829; Thu, 29 Oct 2026 15:20:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMRvu-0003nQ-H1 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:20:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMRvt-00GV1X-Tl for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:20:49 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3643f-e002-0a2a0a5209dd-0a2a450bdc42-36 for ; Thu, 29 Oct 2026 16:20:49 +0100 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 6ae36451-b7e8-0a2a450b0019-b9ff1c22aa2b-3 for ; Thu, 29 Oct 2026 16:20:49 +0100 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 1a1883fc6a5000f79f.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 15:20:43 +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 9ADE281B60; Thu, 29 Oct 2026 16:20:42 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=XT/9kz4AnqLJK7s6axTpeDwmHhfQUrR3yatWmy939T4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=I+gzWmRomU0BSmj81ak1u9gGw97739i4Wb3w8D5Wn84ra412ZrkV54m+scivWMrp/pUfO8Gl1 54N79vIzbQxuXMEdHag1VZ/e4Jei/UaVYoNydVEwMVmdx0W8bCA04IpvtPvx/WwUBguf1o71W0Y mmWgb+6GiZYdHc0M4fuZJM0mfX0Lhgs+HymemosRdjNhCNDmW7ei26cwOiVTQT67sALplT/5mYz UGYPg/Nr6oAE3NjfGzeBFcFmm3nx5fDltBMFgzt0Wtbf1Xr+Vvb3dbe7dKY1zpIdiTr6NV8yPPl qhvLx/USEK7SeFQbnlVjgzxxs8OSolb17MZYLBHD8zEg== X-Zone-Loop: 2e0166678e26cc68daac6ca06cfeaaf9c049911eab1c x-campaign-type: default x-transaction-id: 36b410de-f828-4df1-9309-8ed3d7bf8453 x-swg-uid: 01-76ef4c33-ea2d-4eb3-ba5c-4232ad9d9c6d X-Mailer: Sweego Message-ID: <1793287243.8631fc262581453bbf619ec5b2062170.1a1883fc6a5000f79f@vates.tech> x-swg-bid: 1793287243.8631fc262581453bbf619ec5b2062170.1a1883fc6a5000f79f Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 29 Oct 2026 16:20:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] common: Convert !test_bit(_VPF_down) into is_vcpu_online() To: Jan Beulich Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1793282364.8631fc262581453bbf619ec5b2062170.1a187f55469000f79f@vates.tech> <482334fd-1b21-4541-a903-a9e7434daffe@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: <482334fd-1b21-4541-a903-a9e7434daffe@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------AszZnxG0BWLO03M0oL5Zt4vr" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793287242830 X-purgate-ID: tlsNG-42698a/1793287249-AACDF9EA-1C39FC96/10/78276251493 X-purgate-type: spam X-purgate-size: 5991 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------AszZnxG0BWLO03M0oL5Zt4vr Content-Type: multipart/mixed; boundary="------------wW0y1k0AiAb6vPSUuH8q4PEf"; protected-headers="v1"; hp="clear" Message-ID: Date: Thu, 29 Oct 2026 16:20:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] common: Convert !test_bit(_VPF_down) into is_vcpu_online() To: Jan Beulich Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1793282364.8631fc262581453bbf619ec5b2062170.1a187f55469000f79f@vates.tech> <482334fd-1b21-4541-a903-a9e7434daffe@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: <482334fd-1b21-4541-a903-a9e7434daffe@suse.com> --------------wW0y1k0AiAb6vPSUuH8q4PEf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjkvMTAvMjAyNiDDoCAxNToxMSwgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g MjkuMTAuMjAyNiAxNDo1OCwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiBEbyB0aGUgc2FtZSBm b3IgdGVzdF9iaXQoX1ZQRl9kb3duKSBpbnRvICFpc192Y3B1X29ubGluZSgpLg0KPj4NCj4+ IE5vIGZ1bmN0aW9uYWwgY2hhbmdlLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IFRlZGR5IEFz dGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0KPiANCj4gUmV2aWV3ZWQtYnk6IEphbiBC ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gd2l0aCBvbmUgbml0IGFkZHJlc3NlZCAo Y2FuIGxpa2VseSBiZSBkb25lIHdoaWxlIGNvbW1pdHRpbmcpOg0KPiANCj4+IEBAIC0xOTUs NyArMTk1LDcgQEAgc3RhdGljIGludDMyX3QgZG9fcHNjaV8wXzJfYWZmaW5pdHlfaW5mbyhy ZWdpc3Rlcl90IHRhcmdldF9hZmZpbml0eSwNCj4+ICAgICAgICAgICB2ID0gZC0+dmNwdVt2 Y3B1aWRdOw0KPj4gICANCj4+ICAgICAgICAgICBpZiAoICggKCB2LT5hcmNoLnZtcGlkciAm IHRtYXNrICkgPT0gdGFyZ2V0X2FmZmluaXR5ICkNCj4+IC0gICAgICAgICAgICAgICAgJiYg KCAhdGVzdF9iaXQoX1ZQRl9kb3duLCAmdi0+cGF1c2VfZmxhZ3MpICkgKQ0KPj4gKyAgICAg ICAgICAgICAgICAmJiAoIGlzX3ZjcHVfb25saW5lKHYpICkgKQ0KPiANCj4gV2l0aCB0aGlz IHRoZSBwYXJlbnRoZXNlcyBhbHNvIHdhbnQgdG8gZ28gYXdheS4gV2l0aCB0aGVtIHRoZSBz dHJheSBleHRyYQ0KPiBibGFua3MgdGhlbiB3aWxsIGFsc28gZGlzYXBwZWFyIChhdCBsZWFz dCBmcm9tIHRoZSBsaW5lIGJlaW5nIHRvdWNoZWQpLg0KPiANCg0KTG9va3MgZ29vZCB0byBt ZS4NCg0KPiBKYW4NCg0KVGVkZHkNCg== --------------wW0y1k0AiAb6vPSUuH8q4PEf-- --------------AszZnxG0BWLO03M0oL5Zt4vr 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+p0QLLz9AFAmrjZEoFAwAAAAAACgkQZg+p0QLLz9BF 8gv7B8iooNoTOgZta9QN2sqzt2vN4In2e2btnEK37GOUyW3QCpk9WtBGDsi63c2L4grImSIQ4Z07 /Z1i7sJ6AdND/uQzlXgjvbWPQ7Z2VTLF8M3Cp2TfiHrOuZY18pkoDQxiLXEK53EhVXuGCljAQ5AB UDlBSfFi3NbqtRguHfzWV5kq76NCYw0v96gHQ4WDN3dTpCYv4x7bkhiIjIkhFbC8/F6csvM3pUMq T4mjv9RJ+m5J5PdcwEzV9UXjyiCADh/SQetSAhuIEQXTbHeG+9Plq/Vdf+2CyQ0sbVsZyQUFrB9T UjDcSSvXrbpHw6vTODR7vhQP2NK46+Xg313vKCVlkbhEaqBbXVB5WCtM7im+JZnXI/VYybJiv3Hj +wSAh/jXtMZb9QJo6CfoZK4qetOj4H53mBr7ELvcQxK6OmfG0wjSYuzkCJNtAwUSNjFTXMfJs6C/ wTVX0lef3ArX9k97mfSe7uIuN56cwLQhDLBUZWShAZPgAIjhdygEBDmu62Hk =iKc3 -----END PGP SIGNATURE----- --------------AszZnxG0BWLO03M0oL5Zt4vr-- From xen-devel-bounces@lists.xenproject.org Thu Oct 29 15:22:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 15:22:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464821.1675669 (Exim 4.92) (envelope-from ) id 1xMRxU-0004XP-2O; Thu, 29 Oct 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 1464821.1675669; Thu, 29 Oct 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 1xMRxT-0004XH-VV; Thu, 29 Oct 2026 15:22:27 +0000 Received: by outflank-mailman (input) for mailman id 1464821; Thu, 29 Oct 2026 15:12:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMRni-0002F2-6c for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:12:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMRnh-00An3n-Ct for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:12:21 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae36249-bab6-0a2a0a5309dd-0a2a45099a8e-8 for ; Thu, 29 Oct 2026 16:12:21 +0100 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 6ae36253-be1a-0a2a45090019-aa0a817c852f-3 for ; Thu, 29 Oct 2026 16:12:21 +0100 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-647-lR4E_uxDPxGRis0Bj7u-cg-1; Thu, 29 Oct 2026 11:12:15 -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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5CA951956043; Thu, 29 Oct 2026 15:12:09 +0000 (UTC) Received: from redhat.com (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 11F131955F08; Thu, 29 Oct 2026 15:11: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=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=1793286739; 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=sy6RcJq7kWnzNPatcCz5vMju7T26X8KtMwEXCbitl90=; b=Xm56vkH9ATMJMygfPZSg+6GK3F6dQs7YPsYUO98Xep2m+NG+NICizkX3sSRQ6aFxum1tFS 2r5qzweZVvntR9s1vJ+llUI80AT507RpAf8Wam+f6LXJQP6VwleF7JeNpCHZ3Pdfknrstd mi7fwEqZHv79SYuWjlc8dXp0RGQs8wo= X-MC-Unique: lR4E_uxDPxGRis0Bj7u-cg-1 X-Mimecast-MFC-AGG-ID: lR4E_uxDPxGRis0Bj7u-cg_1793286731 Date: Thu, 29 Oct 2026 15:11:41 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Markus Armbruster Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> <87zevz5h4k.fsf@pond.sub.org> <87o6ce47rr.fsf@pond.sub.org> MIME-Version: 1.0 In-Reply-To: <87o6ce47rr.fsf@pond.sub.org> User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-MFC-PROC-ID: 2G7TYa8PEEO9nj3_XFOKi1YSin1WxFaXis19DMpLORk_1793286731 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1793286741-3B4D3034-C52894B3/0/0 X-purgate-type: clean X-purgate-size: 4930 On Wed, Oct 28, 2026 at 08:13:44AM +0100, Markus Armbruster wrote: > Daniel P. Berrangé writes: > > > On Tue, Oct 27, 2026 at 03:54:03PM +0100, Markus Armbruster wrote: > >> Marc-André Lureau writes: > >> > >> > Hi > >> > > >> > On Fri, Oct 23, 2026 at 2:04 PM Daniel P. Berrangé wrote: > >> >> > >> >> On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-André Lureau wrote: > >> >> > PciDevfn is a bit special, since it accepts integer and string as > >> >> > setter, but only output integer as getter. > > > > snip > > > >> > But I agree we > >> > could do better. > >> > > >> > There are multiple options. We could keep declaring the property as > >> > str instead. In this case, the getter should probably return a string > >> > for consistency and correctness. This might surprise some existing > >> > users though. > >> > >> I.e. ditch numeric suppport for numeric addresses, right? > >> > >> Incompatible change. Do we care? > >> > >> If we don't, we should be honest about it and mark qom-get unstable. > >> > >> > We could introduce new properties like `devfn-str` and `devfn-int` > >> > that alias the same value. > >> > >> Compatibility break. If breaking compatibility is okay, I'd rather use > >> the opportunity to get rid of cleverness, and go with your first option. > >> > >> > We could also introduce a new structured QAPI type. > >> > >> What kind of type do you have in mind? > > > > IMHO the root cause design flaw here was to overload 'addr' as a > > way to set both the slot number and function number, as using > > one property for two pieces of data is a well known anti-pattern > > we caution against. > > > > IOW, we should have had 'slot' and 'function' as separate properties > > from the start. > > Fair. > > Our modeling of PCI is old and weird. > > What we call "pci-device" isn't a device, it's a function, where > function 0 sort of stands in for the device. Mmm, yes, interesting way of looking at it. > Its "addr" isn't a PCI address, it's the address of the function on its > PCI bus, i.e. the tail of a PCI address. > > > From a CLI POV, we could easily change 'addr' to mean only the slot > > number, since it is always parsed in string format without the > > magic (slot << 4) | function encoding. Then add a 'function' prop > > In CLI, HMP and QMP string (not integer), value "5" is shorthand for > "5.0", and means device 5, function 0. > > We could deprecate the .FN part in favor of a new property "function". > > Once we drop support for .FN from "addr", its name becomes even more > misleading than it always was. Yes. > > The challenge is the impact on QMP with strict typing, as ideally > > int format would soley represent the slot number, but today the > > int format is encoded (slot << 4) | function. So anyone relying > > on int format in QMP would silently have a semantic change if we > > altered what 'addr' means. > > That's a no-go. > > > Deprecating 'addr' entirely and adding brand new 'slot' and > > 'function' properties would be a significant disruption to > > a syntax which has been documented for years (decades). > > What about this: > > * No change to PCIDevice member @devfn: encodes slot and function as an > integer. > > * New "pci-device" properties "slot" and "function". "slot" sets just > the slot bits of @devfn, and "function" sets just the function bits. > Both default to zero, so specifying just "slot" gives you > PCI_DEVFN(slot, 0), which makes sense. > > * Deprecate "pci-device" property "addr" for QMP. We can keep it around > for longer than the required grace period if that helps. > > * Declare it legacy for CLI and HMP, with no intent to remove it. We can't easily keep it in CLI/HMP, while removing from QMP can we ? As long as the property exists on the PCIDevice object, it will be accessible everywhere. Perhaps keep it relatively simple and merely deprecate the string syntax of 'addr' in QMP. That's the place where it is really ugy. Force QMP over to only the integer syntax for 'addr', and leave CLI/HMP accepting the (optionally dotted) string syntax. Mgmt apps like libvirt will have to adapt. Tedious, but actually quite simple compared to most deprecations, as the integer syntax can already be used with all historical QEMU versions in QMP that mgmt apps ever need to deal with. They can unconditionally change their code to int syntax and not worry about old/new QEMUs at all. 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 Thu Oct 29 15:47:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 15:47:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464907.1675843 (Exim 4.92) (envelope-from ) id 1xMSLh-0002LX-Ho; Thu, 29 Oct 2026 15:47:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464907.1675843; Thu, 29 Oct 2026 15:47: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 1xMSLh-0002LQ-Ei; Thu, 29 Oct 2026 15:47:29 +0000 Received: by outflank-mailman (input) for mailman id 1464907; Thu, 29 Oct 2026 15:47:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMSLg-0002LI-9j for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:47:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMSLe-00Asxu-5J for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:47:26 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae36a87-bab6-0a2a0a5309dd-0a2a4507a168-14 for ; Thu, 29 Oct 2026 16:47:26 +0100 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 6ae36a8d-b4ea-0a2a45070019-b9ff1c1292ad-3 for ; Thu, 29 Oct 2026 16:47:26 +0100 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 1a1885828c6000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 15:47:21 +0000 Received: from [192.168.1.52] (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 B399F83212; Thu, 29 Oct 2026 16:47:20 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=Es67gfhK4eAll13Wo9ntqA5rO5ZYA+VKYNSC9qFkaFk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=lvpK13hMU3Tv77d1gNbtzuFOX2hplzsdY+a1TYp0DGuG8JuX6aqUkLWW6Lk5zBtUVHVG2lQql kTU6bFFBrgHvEyRc54qeDZ2LII/lv7hzamJdm8QbzHh8k6ACIOkzKaSYlRxMYK1oJb/NQdNUQ3i X1IHMy6EJunOohkMMfXqwHfr9wgts3k/j87Kbdc4RHNnb3mpMb1tJ7MMiB0yotS9uZGjxIpY9S9 nmAOqKslXEyUVOUt7zXa6I//xqx8JYXe2aC7DxpHOUQyxT1zJEMVAvOo9yKHZJy6nnYqKCUL0uV J2dx7rsHJnTw+DPPovB7NiFn20k1LyJo3clfsTejJiTQ== X-Zone-Loop: b964b3962bd4c7d20c73f90cd48bbce0066c59ac40b4 x-campaign-type: default x-transaction-id: 3fa1f438-650e-45fe-be6e-fba16916b2c1 x-swg-uid: 01-21db4bc5-06ca-47d5-8b19-1b2c2c46b1fb X-Mailer: Sweego Message-ID: <1793288841.8631fc262581453bbf619ec5b2062170.1a1885828c6000f79f@vates.tech> x-swg-bid: 1793288841.8631fc262581453bbf619ec5b2062170.1a1885828c6000f79f 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] Add a QTB container to run the Xen riscv64 tests From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <846f2ec6-da73-4f12-b46f-5e9f841e35ad@gmail.com> References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823787.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@vates.tech> <846f2ec6-da73-4f12-b46f-5e9f841e35ad@gmail.com> Date: Thu, 29 Oct 2026 16:47:14 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793288834; l=1256; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=EAGB0uj303WpSeV8adE4Z3HR91CddmGg9iId3k6IQpo=; b=R6ovMOPNjPmOLzbFvqVznLBxXpIvmwV+TgeuzZw/4PTWg19TSmGAUvwqS/Y9P2XapwZ36hZO5 HPzWacZOTP5BR9Smk/GUlHNrUxtvqKcssDaLwWuVsukOFEV+lcEITMA 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: 1793288840887 X-purgate-ID: tlsNG-ef75cf/1793288846-A58C1AE4-029B956B/0/0 X-purgate-type: clean X-purgate-size: 1256 On 2026-10-22 15:28 +0200, Oleksii Kurochko wrote: > [ ... 120 lines skipped ... ] > Also, this fetches qemu.qmp, pexpect, pygdbmi and ptyprocess from PyPI > with only lower bounds, so the result depends on when the container is > built: building it now installs qemu.qmp 0.0.6, while the fork ships > 0.0.5. The fork already bundles wheels for all of the [qtb] > dependencies in python/wheels/, so they can be installed offline. I've > checked that the following works, with python3-setuptools added to > DEPS: > > pip install --break-system-packages --no-index --no-build-isolation \ > --find-links /tmp/qemu/python/wheels "/tmp/qemu/python[qtb]" > > Minor: python3-pytest isn't installed, so the unit tests from patch 4 > can't be run in this container, although the README asks only for > "the prerequisites above plus pytest". It would be convenient to have > it here. Applied in v3, thanks! > > FWIW, I've built the container and run the smoke test from this series > in it against a locally built riscv64 Xen (console-test run > dom0less-1smp-0domu-1vcpu-aplic-imsic-null): it passes. > Great to know, thanks! Could you please add a Tested-by next time? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 29 15:54:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 15:54:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464918.1675853 (Exim 4.92) (envelope-from ) id 1xMSS6-0004N7-6j; Thu, 29 Oct 2026 15:54:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464918.1675853; Thu, 29 Oct 2026 15:54: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 1xMSS6-0004N0-2O; Thu, 29 Oct 2026 15:54:06 +0000 Received: by outflank-mailman (input) for mailman id 1464918; Thu, 29 Oct 2026 15:54:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMSS5-0004Mu-Kt for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:54:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMSS4-00Euja-UU for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:54:04 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae36bfd-8faa-0a2a0a5109dd-0a2a4502e680-48 for ; Thu, 29 Oct 2026 16:54:04 +0100 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 6ae36c1c-6ca4-0a2a45020019-b9ff1c2385af-3 for ; Thu, 29 Oct 2026 16:54:04 +0100 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 1a1885e42e1000f79f.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 15:54:01 +0000 Received: from [192.168.1.52] (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 9D52183212; Thu, 29 Oct 2026 16:54:00 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=5EN3g4eSq9t2R26JbFIwREzN/mlROd8whpSwM9ewidQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=JmD1+RW/mQqxArLVZ/igF2aoVjxbFWpPtZBjrD7uGEr5Ap9XihCibJnDagb8NQW8oOKsIR2g+ WJXI4cM7CQDnfJJMzINj6Nt/6PZXdN9af1yCXsuBz80Rc6OQIIpNq46l1PEm5XHXxCci/TGvFV7 ynGyYWvcx9BWzjTHPo2yxfClN+HtfL6p92yrLjJLGdmquPdlxbQpN2IZZe+af9QjAKInJnittL0 92Dp+hKJGxHnDM87+mgy/72dFeb/fqzagxzLiQFSGtzFeCx7cQ30+9A0qS/JSF1020LxTOTzX9d +h3BSsWul7Ttf/+a+mSli5lMvYbQDalrKL44+SzkUiqg== X-Zone-Loop: 83320cd67f0472e6071d55278b3be32d0324810c584a x-campaign-type: default x-transaction-id: 233a624e-97cb-4be8-85ed-50a4e803b0dc x-swg-uid: 01-5e64bc01-88e5-4178-a10d-09283474c89b X-Mailer: Sweego Message-ID: <1793289241.8631fc262581453bbf619ec5b2062170.1a1885e42e1000f79f@vates.tech> x-swg-bid: 1793289241.8631fc262581453bbf619ec5b2062170.1a1885e42e1000f79f 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] Add a QTB container to run the Xen riscv64 tests From: Baptiste Le Duc To: Anthony PERARD Cc: Oleksii Kurochko , Baptiste Le Duc , xen-devel@lists.xenproject.org, Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <1793183387.8631fc262581453bbf619ec5b2062170.1a1820f0ebb000f79f@vates.tech> References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823787.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@vates.tech> <846f2ec6-da73-4f12-b46f-5e9f841e35ad@gmail.com> <1793183387.8631fc262581453bbf619ec5b2062170.1a1820f0ebb000f79f@vates.tech> Date: Thu, 29 Oct 2026 16:53:54 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793289234; l=1020; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=TpS0kwmVGyAMREpXKkM9XXoS2RsXmZGzw1xGuxkXm80=; b=VsGARp1pXgB23sRA2CN1srJQ61nbcr9GFfmpZRViu9U/Pk0Gu8NGz29VLm4c+BMZG17UFyH2u rPxRGZW10XlDbYr9RKCDo49uBYEOTAuufcaxavvXcF+84zoQUD8KE2x 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: 1793289240797 X-purgate-ID: tlsNG-720697/1793289244-31FD62AC-80FF3A96/0/0 X-purgate-type: clean X-purgate-size: 1020 On 2026-10-28 11:29 +0100, Anthony PERARD wrote: > [ ... 17 lines skipped ... ] > > Having it as automation/build/debian/13-qtb-riscv64.dockerfile in > > xen.git would keep the container next to its only user, avoid the new > > ARTIFACTS_REGISTRY variable and the image: override in patch 6, and > > drop the "must land first" ordering between two repositories. > > Indeed, the new container would fit better in the `xen.git` tree. > > And can you rename the container? I think the format is > "$distrib/$release-$arch-$comments" I'd rather keep riscv64 as the $arch part. The existing debian/12-riscv64.dockerfile and debian/13-riscv64.dockerfile are also built with --platform=linux/amd64, yet they are named after the arch they target, not the one they run on. Naming this one x86_64 would break that convention. Following "$distrib/$release-$arch-$comments", how about debian/13-riscv64-qtb.dockerfile (and the debian:13-riscv64-qtb image)? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 29 15:57:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 15:57:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464926.1675862 (Exim 4.92) (envelope-from ) id 1xMSV8-000543-Jm; Thu, 29 Oct 2026 15:57:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464926.1675862; Thu, 29 Oct 2026 15:57: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 1xMSV8-00053w-GG; Thu, 29 Oct 2026 15:57:14 +0000 Received: by outflank-mailman (input) for mailman id 1464926; Thu, 29 Oct 2026 15:57:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMSV7-00053q-BQ for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 15:57:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMSV6-00E8Vc-OR for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:57:12 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae36ccc-e002-0a2a0a5209dd-0a2a45018772-34 for ; Thu, 29 Oct 2026 16:57:12 +0100 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 6ae36cd8-5984-0a2a45010019-b9ff1c23b143-3 for ; Thu, 29 Oct 2026 16:57:12 +0100 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 1a18861278b000f79f.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 15:57:10 +0000 Received: from [192.168.1.52] (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 1600E832C2; Thu, 29 Oct 2026 16:57:10 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=4fxjre9W4OxxhMX8NL+oN0+7uYN+3E/sDoH0Rc5vRFc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=iisYCXZud8njodGagKZWDfZuaZdsy3obNRRU1dUsPqXk8E5l3tlmTVQq8ATHUcV1Eu/AfjjPq SyRaSj9TwvzZN/MjajlP5aI08QbQdPBlVywquKPZkJllmgJbbGi6wamucwU/woIz7mtgIu3UkEk V1XOxCwe383oP9DOrA9y6CezZNE6y3wETNhobDaQBWdK5lIjD154jc38LNw4POt04j56jE+ivsc 5zLLEyA3HTjdSzVv9xQPapmDXqM+V9FL5zQZVVHnItBKWT4MTzps8XGCVOwtHQKlK59O+WTW9Yz ibhBbt7kDomAXP1hh84KehPQ1wCDIi7vDGqIKNOS4s5w== X-Zone-Loop: 089cadbf958261dae9bb42de490bdfe6bb3fd2bbe75c x-campaign-type: default x-transaction-id: c1532ab9-1572-43a2-a24a-c69d81f5c672 x-swg-uid: 01-13d1de4f-4512-4982-8df7-c580ec02b9bd X-Mailer: Sweego Message-ID: <1793289430.8631fc262581453bbf619ec5b2062170.1a18861278b000f79f@vates.tech> x-swg-bid: 1793289430.8631fc262581453bbf619ec5b2062170.1a18861278b000f79f 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 4/6] automation/qtb: add unit tests for the QTB framework From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini In-Reply-To: <5ada3d12-5569-4e14-8178-815da3665a52@gmail.com> References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3@vates.tech> <5ada3d12-5569-4e14-8178-815da3665a52@gmail.com> Date: Thu, 29 Oct 2026 16:57:04 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793289424; l=996; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=TYRoyYTmSmpfttf3L21CE0J6kFhMJ4ZiyyLtahy1nEY=; b=3uImFNd147594FstrDt/TEW+ZzmZUGMwoWd7D4IzGWZqQ+cZEE6p+MG8noYDzAT4sW5RjaAEc V9fXl0vANuMAFDCkYADsSliUfuhbSYGuYTMajcWpMHmPnIQ98nWDXW9 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: 1793289430180 X-purgate-ID: tlsNG-d62444/1793289432-BF66C757-6F2A364B/0/0 X-purgate-type: clean X-purgate-size: 996 On 2026-10-27 17:51 +0100, Oleksii Kurochko wrote: > > > On 8/27/26 11:42 AM, Baptiste Le Duc wrote: > > The QTB framework is meant to be extended: new test types, new machines and > > new device trees aim to be added by other people. > > > > Add pytest coverage of the framework's functions, and of the console-test > > type's config validation and expect/retry loop, so that such changes get > > immediate feedback and existing behaviour does not silently regress. > > Nothing runs these tests, though: there is no CI job for them, and the > container from patch 1 doesn't even have pytest. So the feedback only > comes if whoever changes the framework has pytest and the QTB fork > installed locally and remembers to run them. Finally, I'll drop the unit tests patch in v3. They mostly help local development of the framework itself, and CI never runs them, so carrying that much test code in the tree isn't worth it. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 29 16:07:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 16:07:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464937.1675871 (Exim 4.92) (envelope-from ) id 1xMSfL-0007zg-Fl; Thu, 29 Oct 2026 16:07:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464937.1675871; Thu, 29 Oct 2026 16:07: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 1xMSfL-0007zZ-CT; Thu, 29 Oct 2026 16:07:47 +0000 Received: by outflank-mailman (input) for mailman id 1464937; Thu, 29 Oct 2026 16:07:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMSfK-0007zT-Gb for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:07:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMSfJ-0076jM-If for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 17:07:45 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae36f4d-bab6-0a2a0a5309dd-0a2a450ac2a2-8 for ; Thu, 29 Oct 2026 17:07:45 +0100 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 6ae36f51-f2d2-0a2a450a0019-b9ff1c229aaf-3 for ; Thu, 29 Oct 2026 17:07:45 +0100 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 1a1886abd5a000f79f.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 16:07:39 +0000 Received: from [192.168.1.52] (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 76C79829AA; Thu, 29 Oct 2026 17:07:38 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=jo9yEpFO5ky6kKPW38eVYVqfizMOrnDFcU5fX9kwinY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=hYrsICLqTHcQBV9Baiu4PYfab/hZ152AbdgxSuhuOu3jver4TKuA6E7Wkr3aa0wTTIaDF0kDG BRs5AcjCA2rUQSG1gjOH5nsPG6xPRyTrA9cIV7hcb1WXNYWzCiGIZcHM62UP6UrOukUSNpk/G2I LmdQs/26zwoakPgO55TMn4cqgFNaGiTcZU921aKauKE0d1RifykposMXZ1raQW5BMBwxBY9MaxY 5clj92DgBje0dLQ3I9JUKGZNZzUZ83hR3f57qTvRWJdxP5iVRQi8EyuiKEaUXB3TiiTVKldMtXn 7OygW5VIDlHZafsdLgREbMeRHWDuBUcm4o+A+maUWO/w== X-Zone-Loop: 4d17cd1e80436a00959933217d86e87d335cb668c9fe x-campaign-type: default x-transaction-id: f49396c6-6cbb-4f8d-9318-4fe48504373f x-swg-uid: 01-90a8bba6-c9f7-47b1-bf04-727169f86843 X-Mailer: Sweego Message-ID: <1793290059.8631fc262581453bbf619ec5b2062170.1a1886abd5a000f79f@vates.tech> x-swg-bid: 1793290059.8631fc262581453bbf619ec5b2062170.1a1886abd5a000f79f 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 5/6] automation/qtb: add QTB framework README From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini In-Reply-To: <1fcacfcb-2775-4a4f-ac38-d7ed9a143e99@gmail.com> References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@vates.tech> <1fcacfcb-2775-4a4f-ac38-d7ed9a143e99@gmail.com> Date: Thu, 29 Oct 2026 17:07:32 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793290052; l=3698; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=NiFKFYGFyVJwlRFNrCbl48tJrpDfI3ZIzTM0brlawqQ=; b=Yo07ydvF8D4qYU/1EmVlws9FCSLFGs8v9TWLQCzLUextKhVosBSGzkX3VTix/DJ5bhuU7Mla2 eka6z095VwdCBDERVc9CsPibczVhDN8V7q4ON45uQfADdNQGvabKP0t 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: 1793290058572 X-purgate-ID: tlsNG-4011c0/1793290065-50ECACFC-14EC7620/0/0 X-purgate-type: clean X-purgate-size: 3698 On 2026-10-27 18:32 +0100, Oleksii Kurochko wrote: > > > On 8/27/26 11:42 AM, Baptiste Le Duc wrote: > > Document the qtb riscv64 test framework in a README. > > I understand that you are trying to introduce things so they could be > traceble. But probaly it makes mentioned in cover letter or somewhere > else that thre is README which probably should be read first for easier > understanding of the patch series. Agreed, v3's cover letter will point to the README as the place to start. Note that in v3 the framework will run with pytest: the CLI, config.yaml, the .yaml files and the timeout/attempts logic are gone, and the README is rewritten accordingly. Answers on the points that still apply below. > > + config.yaml The machine catalog (shared across test types) > > + dts/ Jinja2 device-tree templates (host, common) > > There is only one template, qemu-host.dts.j2, nothing "common". Right, the README now only describes qemu-host.dts.j2. > > +- `qemu.qtb`, QEMU's Python package (`python/` in the QEMU tree) > > qemu.qtb isn't in QEMU's python/ (it isn't upstream yet, as the cover > letter says), so this sends people to the wrong place. Please point to > the fork and the commit used by the container in patch 1, or better, > say that the simplest way to get all prerequisites is that container, > and show how to run a test in it with containerize. Done: the README says it is not upstream, points to the fork and the commit pinned in the container's dockerfile, and recommends the container, with a new "Running in the container" section showing how to build it and run the tests through containerize. > > +Run from `automation/scripts/`, or give the full path from the Xen tree root > > +(`./automation/scripts/qemu_smoke_riscv64.py ...`), which is what CI does. > > Neither works without QTB_BINARIES_DIR unless xen is copied to > automation/scripts/qtb/riscv/binaries/ (see my reply to patch 3), and > the README doesn't say where to put it. There is no default location any more: the directory holding the xen binary is given with a required --binaries-dir option, which the README documents and the container example uses. A test run without it fails at setup with an explicit message. > > +`--log-dir` (run only) collects the QEMU process log, the qtest log, and each > > +console as `con.log`: `con0.log` is Xen's own console, the only one wired > > There is no qtest log: QtbMachine passes "-qtest-log none". The > riscv64-qtest-.log file is QEMU's stdout/stderr; "qtest" comes > from the machine name. Right, the README now describes riscv64-qtest-.log as QEMU's stdout/stderr, named after the machine. > > +`config.yaml` is the machine catalog. `binaries:` are build artifacts resolved > > +under `binaries/` (overridable with `$QTB_BINARIES_DIR`); absolute paths pass > > +through. > > This reads as binaries/ at the top of the tree, while it is actually > automation/scripts/qtb/riscv/binaries/. Gone with --binaries-dir, see above. > > +- `mmu_type` (default `sv48`): Xen host MMU type. > > See my reply to patch 2: Xen doesn't use this. Right, Xen only reads mmu-type from dom0less guest nodes. I dropped it for host in MachineConfig and in dts in v3. > > +3. bound each wait by `timeout` seconds, retrying a timed-out wait up to > > + `attempts` times > > See my reply to patch 3: nothing is retried, attempts only multiplies > the timeout. attempts is gone in v3: console-test waits for each expected string with a single timeout. Thanks, Baptiste -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 29 16:24:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 16:24:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464949.1675880 (Exim 4.92) (envelope-from ) id 1xMSup-0003up-Qo; Thu, 29 Oct 2026 16:23:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464949.1675880; Thu, 29 Oct 2026 16:23: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 1xMSup-0003ui-Le; Thu, 29 Oct 2026 16:23:47 +0000 Received: by outflank-mailman (input) for mailman id 1464949; Thu, 29 Oct 2026 16:23:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMSuo-0003uc-I8 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:23:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMSun-00GfuI-Bd for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 17:23:45 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae37308-bab6-0a2a0a5309dd-0a2a45068222-32 for ; Thu, 29 Oct 2026 17:23:45 +0100 Received: from [52.101.62.47] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae3730f-195a-0a2a45060019-34653e2f5872-4 for ; Thu, 29 Oct 2026 17:23:44 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB8328.namprd03.prod.outlook.com (2603:10b6:806:460::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Thu, 29 Oct 2026 16:23:29 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0569.008; Thu, 29 Oct 2026 16:23: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=HoNDTcaigJKUmwVGQzPYHnAYx3FWgt+Mrx2OrXHSZMBmD4r2ddfX74mRvBh3nqW9Kqt5CyQwuYQOPVQKWxGsIDTPP9T0tsXJlh79xem6j+7h8ey+bP2SFrzBaLPu5qmYo/B6CValskdaR+Q1b+zUKWeEHYg2Ri4QnxlLeKUaVv2YbyznEn+c/vBLSe7sjB+YeE8xq4AkXw6SjZ0eTsItpgwSOhcKFxS8lwCApx+9uGUraqgdl0gvSsxYfEy9ESDbQ1ZyDiI9ECuaqPYwRHlK4ELjw3awXKUAC/EZhT/yOxntnMedFsvxRD5Tw9dILUkv73NM6ElLH+lIZ2xuJOd/ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gZtXkUJqagZuRI3N4ziQiVOHnYUCntW69wcovVMbjws=; b=cLQA8abNQG06Q+Kh8JILJmbQ5QulEXGcHLujRJ7ElytZl/w5pdZR7byHAlI7hnLzSWsnbmaB2cMV5ZXSHhPeOnLvEwTr5bdkpcuwzOP5Ut7TzODLx+gfaaaTbxO9mClxU82Ag5WM/EQK36yvj6Dr2FxdRV6mtDBwHt+TtR0yESR9bJmNfHNGu+nANx7SaTTLmFYIeu0Pg+a1N49RR/0IRhSrvbOAQb1GFedh6CuGfXz+X6EEPuzS7DXsj1Gj7oF28jfZFVAAqcxvFiN25ZtfUO62jOxAM06W7zsecXIXMsKkj9/K4LaG60VNc0ZpIL6u5yX7LmLi/XGi2fEEZ04vjg== 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=gZtXkUJqagZuRI3N4ziQiVOHnYUCntW69wcovVMbjws=; b=H10zMVqXpwsGr2a/RAX5Qu5V39uWtFugvhWF/s5L0WMDg+qWcG/xt/WVJzEydsz5X0RdfD6rfetH2RkUVwlojosQWWKC0GSluX4kkp54ahUK+Z0lTj3UnXfey2RYEsBIvshrlUIJj8OEjRd2zVLD95XW3W+Ey4xJ8kkGKYOziyM= 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, 29 Oct 2026 16:23:25 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/HVM: shrink (pack) struct periodic_time 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: LO4P123CA0615.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:314::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_|SA3PR03MB8328:EE_ X-MS-Office365-Filtering-Correlation-Id: fc10b952-29ec-415a-9dfa-08df35d8f774 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|11063799006|56012099006|261009223027099003|261026140227099003|261026121527099003|261028144727099003|10067099003|261022105027099003|261021121427099003|261022075727099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: lwQoyM18L/uELpZy3PZV2xWeCqU87SN5ZFQGTdCJ46CwlIDWS9J95Kl6WSqb1uTpvguv1L3lLl29jjDKUmCZvDcSMLK3Oo+8XAnAM4PXwvp4ryoQcdpRyYnaXZIO5p0OB7A0TjYYCLMsWIMwGXY/28d/iJxaLl25L5JXL4p9ko8t5skx5mk8OyIohZnjeVf1jlEx4gQJJUpnloC0HOnn0gQxggdeXalsKjFwIuhdKIpu0qBlvespVdTKt563a18I09SrG8SVuJO6GoRLZDTewFgQAjggaiCH1J7Rdv8ySsSGtNUvgp+K88+e/o25Mh6hngsBt4hYtyWrOQxVPE2GVCi0EBirxrbjOhv1dUBbGckJeL8MUvUWeysVuLR5aDO/HDO1O3R8m2aYXZx0+RBeRafNnH/u1/QYTA7rmkAPj0spjLQLdHWtOAH2A84Jt/WlD9OlvpGyRlI5QunGoDz7jK21rzwhwlfCPolijWyB1RgKc9JrmtcREea8qZvhMJvcP3kjvE08t6Qp09lXkI2e6h4isWFWqRCSPCNVU2MZC+9QALuopzZ0qr3qwyoQ4CAtt51NojkMjPeDXrYOTEP1InnlPwdaRpX6ll6D7FUAFxePiR7W32kjXSfBEt+BKtuWJvSUW5z76sbIZsGTxDCqT/3C+JDKIrTp02NoLVcefOk= 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)(11063799006)(56012099006)(261009223027099003)(261026140227099003)(261026121527099003)(261028144727099003)(10067099003)(261022105027099003)(261021121427099003)(261022075727099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a3R3bEhXTmY5Q1lsRlhRd25UbjRuUEgwU2tZbDVwdWpGdVBoSnU1Rlg1REll?= =?utf-8?B?cHhPT0NEODNadDg3VDEvWkJPUVFaYzVLSkhhVmZjUm1MQmN6Zlc1SnBxZVdC?= =?utf-8?B?YjFETUFTMis0VmpxbUh6eHN4b2hvNGVZTytRamJ1YjdqQ3JGWGo2bG1yWkI3?= =?utf-8?B?TUtpYUs1MEVQaThjM0VZL1VraFBad3RrcUYxeG1rVGxGMjlxNlU2VjA0dzZn?= =?utf-8?B?K1lNMER6MUdvMTRIRzUzRUY2Y1F2VS9RWG5FWSt1Q252V0F4czJ6Z2RVeFFr?= =?utf-8?B?SUdNdXRJdm51L2h0RVZaM1FrQkwyUzBFOXQyTHh1Um1CT3ZRdmJGZkpRT2VR?= =?utf-8?B?KytpUm00ckgzTW45YTBWZytHajVDNUMvY0t5d3ExYlRqYXVWb0FDZkZOaFhu?= =?utf-8?B?b3JNQzRaRDREcjUwbEZJR3diSEFOd0tPYXRrUE9CczBSd0ZreGU1N2lQVFhW?= =?utf-8?B?MDBaNlB1TXduemJ0bFl0WFNjNmRRcU8vUlppU2t6YkZRR2pVQW1NVittNkxF?= =?utf-8?B?MUVJazdubWVZZm5id1FEa2dFN0ZVb3pXRDczdGxMbENxYk5xTVhmUXQ0VWJs?= =?utf-8?B?SWEzdVZOMjAwa0tHaFlGdi9ocEFjaWxxc2ZOUk9pMzdSRVJ2Q1RRVGxPUEx2?= =?utf-8?B?Q3J4b01vYzNzMDFYMGRvYVVhcTJyZkV2L283bWEzMGZsRDJlaVJuS3N1R1RL?= =?utf-8?B?MlNiSnFucjRuVitXQWd5bjhLVktQVDFRRkRzU21Db0dHRzVOZTV3dXhEb2V5?= =?utf-8?B?RVhaeXhHaVBmK1o5VG4zT21MY3YyQU9SZEUvNDJ2U0tndXBMdSsvQjVldjI1?= =?utf-8?B?R3dDUXJmVkQzeXFFZUVFZDl0bzlOZXhjOWVxdnVWQkZ0OXZxb1BXZWlNRU9Y?= =?utf-8?B?QzZQTXFOQjhvK0crcHVyZkptTENwd3VQMXhqM205dFBBekxUc2NNaitxMkQ4?= =?utf-8?B?MHp6YWRYMmtyR3ZFSE1xNElCbUh0Rmd3M3NpRXhrdE9US1NSbXJjSHhDeVVX?= =?utf-8?B?VTdDNEhxcmVHSm03dXVLeDhvdVRVTkRoemNsdlNZTEdyNTczOWQwaVN1ek5i?= =?utf-8?B?c3FWL2JXdG9zU0xZTFUwZUNzdzByeUpIUXplSExyd0pkUGViVXRqeEpjbHVa?= =?utf-8?B?dCtmSjJYT25yNG00cDJKQTFrVFNyd2pCeUUxdDkyTFZVejdXVVJkQngrUVJj?= =?utf-8?B?MWF4RURVZHY5c3ZOU0VYdHdTSTZOamk4V3FwVU5CQXFFTGwwZW8vRnF2R3NU?= =?utf-8?B?YXJHandld21ucU8xZkpncjJ3c0V5TjNVN1Q1VmFCR05BOGloV2dSdHdSd3lj?= =?utf-8?B?WlRVMWdZTGMzQ3RTanRCZE5DUlQwK1RmUjg3VjRMcTFtS05uYU8zOFFlZ2lv?= =?utf-8?B?M01nN2pka1lBNk9Oem1saVl5MUd5NUFMNU9TQ3hVR2lEdDdZbzJmaDVTWHJ1?= =?utf-8?B?NjZhMDlsYmxjcytzcjBNV3ZWd3hoeURKRW9oM2tiemRFMk1zNXhpQ2hnUVNt?= =?utf-8?B?eGdKbTdYRkZQdzA5MjdIaHA4alpSd3NvbTcrc2EweHVyY1FqNFJSdlZTZ2Zh?= =?utf-8?B?dyszZmRhWmUyZEFKVnFLeENyMmJ0ZmR2ZmVwWFNEQ1BlQmZTdlJIYVRqeDZE?= =?utf-8?B?MnU3RDZOV3FLaytyL3VuUjdNbmtpcEtmbUt3VDZQUHViUUhSdEVNZG82bGwr?= =?utf-8?B?alNtQWFlRkhCcElDeVQ0b2xhYytuaTZBK1NoNURmNjAwMHMwMXFRR0tuS3Ft?= =?utf-8?B?cXJBR3NQSjQxbU1OM3NTRDhZMXJpOElKREY5QmVRMEFGUjJRQVNGd1JiU0Zp?= =?utf-8?B?cGlNWjhsWGFJelpiM0hkdzNYdDRvRDExNGxZazNCZWs3Rk1pUGxaY0NvNnJz?= =?utf-8?B?YTlidi90V3l2UEQ0cWU0aTVWd1JhT1QyRnRvZkxqTmRtYkRDS29UZFVIRnEy?= =?utf-8?B?ZXJGOGlDMFQrSEs1MjFzdmt3UjFnZXhtRUFaclF3OU5RVWt3N0FiNGdjMUxu?= =?utf-8?B?aXNWSWMwemFtVnZtck14dVMrQWNWSElESldUM0hDVm1pT3c2SUxwRTE1RHVE?= =?utf-8?B?OFd1MG1WcUJMQXlRdno4THUvQnVocDgyN3FzUStMdmwwbG9oOVI1SkhjNm5F?= =?utf-8?B?UGpWUjJJU0VKanc0dS9sTWhuWW1oc0Ywa0hDYTIwdzB4SUN5UTVoSDdSQ251?= =?utf-8?B?czMwU3pNSVV2Uys1bnI4cW41dG1FVS8zVHVjRHFpK21PQ2ZpdkxvdVlwbU55?= =?utf-8?B?a0lGb1JHNmsvNFc4N2RGZk56aEJQcm5qSEtPNzYxcGV4QmhVeUpYbEJMM01E?= =?utf-8?B?ektFUnd3dXlRdy9zcllhY2I0OWg5UzI3c1ZPVENhSG9tT3YzSkl4dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc10b952-29ec-415a-9dfa-08df35d8f774 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 16:23:29.2634 (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: richTbi0LeCrhhnmOkYFjjzvYNZHiUMEq2d6kTla9UTZQ5t9P9kgLxU4Kkgs/hbkYAp2xV+D9sFJg6cM4WgvcWj3nsb2vEtdyM4mDSIrfOE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB8328 X-purgate-ID: tlsNG-16d1c6/1793291025-F72C677B-7313C6E6/10/78276251493 X-purgate-type: spam X-purgate-size: 1280 On 29/10/2026 1:56 pm, Jan Beulich wrote: > Except for warned_timeout_too_short, which is used with > test_and_set_bool(), the booleans there don't need to occupy entire bytes. > With them converted to bitfields, pending_intr_nr can move up into the > vacated 4-byte slot. > > Signed-off-by: Jan Beulich test_and_?_bool() are a source of multiple problems, not least because they have no business living in xen/types.h Next, most users of them really ought to be using the bit forms, not the whole boolean form. Next next, this particular warned_timeout_too_short has no business being an atomic at all.  It's a printk_once() in disguise.  Worse, it's a gdprink() so we're doing this atomic work for a no-op in release builds.  Also the debug message is tantamount to useless as it fails to identify the domain/vcpu which produced the overly short period. At a minimum, I think you ought to convert warned_timeout_too_short to be like the rest, rather than leaving it like this.  Or remove it; I really do question its utility. But, if you were to expand the test_and_?_bool() macros to finally remove them from the code base, leaving behind just the xchg expressions, that would also be very much appreciated. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 29 16:34:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 16:34:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1464967.1675888 (Exim 4.92) (envelope-from ) id 1xMT4v-000685-OQ; Thu, 29 Oct 2026 16:34:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1464967.1675888; Thu, 29 Oct 2026 16: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 1xMT4v-00067y-Ll; Thu, 29 Oct 2026 16:34:13 +0000 Received: by outflank-mailman (input) for mailman id 1464967; Thu, 29 Oct 2026 16:34:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMT4u-00067n-3r for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 16:34:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMT4t-00Gi3Z-D2 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 17:34:11 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3757d-2eae-0a2a0a5409dd-0a2a450abbe4-18 for ; Thu, 29 Oct 2026 17:34:11 +0100 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 6ae37582-f2d2-0a2a450a0019-d155802dd43c-3 for ; Thu, 29 Oct 2026 17:34:10 +0100 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a218c463d1so15883765e9.0 for ; Thu, 29 Oct 2026 09: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-48e6df1e543sm237344f8f.4.2026.10.29.09.33.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 09: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-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=1793291650; x=1793896450; 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=0N+6yqUkoBetmn/N10FAiKXysuT5QJyGT63Uo4upcZo=; b=bUNUcCuq9ugQ0fFd4pfpiHnMNaNJbzRbB1tkTNd/VU1Qbd3sVu8yOmNgLX1KNJiGhY C8jLGPjgbWlN0AHPpmAoz4t68wQEdybQKzXvpEWvTG3KBheprNOdvyMSiiXCz8NaXS7T 2jtSyqGStUHl0itFIsntfrjCFHigpyFXHy5HLZjvPPoKZlsmDZ+DDR8rPL9h9CFlMGUq GSs2ZDXEru0jRSv8RfLJobjdF+XJ9L3mQjCYwIpUSgHQshGJc2B0jQFxxdn+yy2DfId6 nBNqVlBON+SXay9ZV6sOJN/TnBJR+i06RjVQYLDFzuGmSjkwTThqbCwgw8XuVyKsRqgs TaEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793291650; x=1793896450; 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=0N+6yqUkoBetmn/N10FAiKXysuT5QJyGT63Uo4upcZo=; b=CzvuFwDYuOzei/vCCoFWYw5XdUjdt/IgfCZh/UCX40+E+cDYgp6H3hioIbQioH2L7Q b0Kf+IPv+MHFKiLfOCNlB0DjwOHcLT4+o5KMpcu3jzs7ASwnBnUdL4xv3WbKoEshlCH3 9OBg/fAhpozri2rPkYXcIw2/84tiD7mf5arXtQaMLS4kNtkXDL5NqHoJV766862vJIfQ VFIMtEeW2NO2V2+F6xiiey+fZCiJ5vu8fE/E39kA0i8WhJ+2J28uXH6tfaNUcokVYZIj WSEAmAXqSBfgYT9kk+F4q5mrAIxD6bpI05LIACd/XRjpP/X/PrOnw6pfC9buAwc+rYN4 OD6Q== X-Forwarded-Encrypted: i=1; AKwUvBx47CJGBGlUy3AvgbapzQ96P7PfN1LVFosH3RVGgNlfFleLUhpxZntLwp/r98xTkwFy12lpniK0YpE=@lists.xenproject.org X-Gm-Message-State: AFq9FYJrIMT/pCxLH3GjwdEBCq+d68FdYsJVAoUviTV9rsBUMIKOl4HM 8yk+Vd0zlA+4FZS3Pjr4Pmuu2gljtVQnbLpn+4IMbrKJv+uSQvLYv51kZKa6u7PS9A== X-Gm-Gg: AYBFou1xrMnA9sd4q6u7oLNFz8gXxIwitMHOPxfsi4HuZ4WTE7wHIsJkDymkRYw2oXy IeDn3Sh63+IW68tpp1PXS2VcP3F5oTlY2In5o4gXrF2Ei4zlp1zS0ujy9Buv+Uk7YKj0OKmWbZ0 ozCCbb1y+sV1+Uy7hPEyo/Nc097yCbqtztJSanKT0/xJjdcoImlrzxZxvBPd7xuLQQ3/WqQ7wOA xQlr1xsVBAiItoOcaUZif3SEvWyVQx9M0mecaPDfFAqUSt++gzWuhTkhfQwPbe+9G+h6DcGvN7N /E8PtvfBwCOgwy/w1s3JPGrWRpB0Bh2ThaRlhQrcrXDUcA2TQUVUiNKgAMAqqp2oqDWHwC7uK6+ hvNxffCYo3kUlKDsmqE3sTTWCmyNBDOyUL8jBPJSW2F7shoeujB/kO6zCdqAIPP68jKieOsedzV OPj/RWgHypxXv0d1swGZhfQ79PcoP9Owp9x+zw6lPUeSkYyQfvT7QA+414ZduWOGLKqzBdDi1ZY JCtXnrnHMMCE6UDiKp2wHie9FLNNkmaBXN3Pe3zdepLLXFMfCf2uJoq5NOiMWLo7drbbqHDzJ1K 1CRZ3gNL+Zf2fnN8DWfshyexR5vMeA/JK2x3qCRdlxjqYUQILzgDja6OoROdN0FQqnBu/iiZC7L ylu/HmjwMWFR4+HoZ X-Received: by 2002:a05:600c:b8a:b0:4a2:167a:c93b with SMTP id 5b1f17b1804b1-4a9672f91d2mr137255995e9.30.1793291650355; Thu, 29 Oct 2026 09:34:10 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 17:33:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/HVM: shrink (pack) struct periodic_time To: Andrew Cooper Cc: Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "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: 8bit X-purgate-ID: tlsNG-4011c0/1793291650-510C9CFC-223172DF/10/78276251493 X-purgate-type: spam X-purgate-size: 1580 On 29.10.2026 17:23, Andrew Cooper wrote: > On 29/10/2026 1:56 pm, Jan Beulich wrote: >> Except for warned_timeout_too_short, which is used with >> test_and_set_bool(), the booleans there don't need to occupy entire bytes. >> With them converted to bitfields, pending_intr_nr can move up into the >> vacated 4-byte slot. >> >> Signed-off-by: Jan Beulich > > test_and_?_bool() are a source of multiple problems, not least because > they have no business living in xen/types.h > > Next, most users of them really ought to be using the bit forms, not the > whole boolean form. > > Next next, this particular warned_timeout_too_short has no business > being an atomic at all.  It's a printk_once() in disguise.  Worse, it's > a gdprink() so we're doing this atomic work for a no-op in release > builds.  Also the debug message is tantamount to useless as it fails to > identify the domain/vcpu which produced the overly short period. > > > At a minimum, I think you ought to convert warned_timeout_too_short to > be like the rest, rather than leaving it like this.  Or remove it; I > really do question its utility. > > But, if you were to expand the test_and_?_bool() macros to finally > remove them from the code base, leaving behind just the xchg > expressions, that would also be very much appreciated. A lot of largely orthogonal (to this patch) work, which may indeed want doing, yet surely not right here. There's no problem at all for someone to do that work on top of this change, assuming it may go in. Jan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 17:12:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 17:12:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465005.1675896 (Exim 4.92) (envelope-from ) id 1xMTfk-0005i4-Fn; Thu, 29 Oct 2026 17:12:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465005.1675896; Thu, 29 Oct 2026 17:12: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 1xMTfk-0005hx-DD; Thu, 29 Oct 2026 17:12:16 +0000 Received: by outflank-mailman (input) for mailman id 1465005; Thu, 29 Oct 2026 17:12:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMTfj-0005hr-Tt for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 17:12:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMTfj-006SKz-9X for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 18:12:15 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae37e69-8faa-0a2a0a5109dd-0a2a4505d20c-16 for ; Thu, 29 Oct 2026 18:12:15 +0100 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 6ae37e6e-4cb1-0a2a45050019-b9ff1c23a37f-3 for ; Thu, 29 Oct 2026 18:12:15 +0100 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 1a188a5ce83000f79f.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 29 Oct 2026 17:12:10 +0000 Received: from [192.168.1.52] (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 2C3D8815DF; Thu, 29 Oct 2026 18:12:09 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=Sljo7EO7U4Td57JTslIaWxULNl2tb4d3Q6wtetYpRNc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=pvBPsT/lpVeSOL21znjDSCOeQbWzYBmAS3JXgMlaLU8yLFjqNihUq+5hkGpN+HxFpeKjnbrtL +T60/RLNSXjd6D/XPKxP7Sd3OY7LAX1ZNBG3JXSlwzxyeDGy6+Lfte7TYvjLcTCdft1VmonehIs 0YUXWvpKbkt+zPR7xwmFkyF42lQEp4RM2wOWh8iWMqv+69fs+FRhBilPV3EkuJCy3de7e3USvLc jrJBPYUYhGkUc5OKXK9oFL/kWEd3/j4VCgvMAhaTcc0b8DKMxSuPVxDpzxJf50thBB9yttxt2b0 CJpsxuluGomy3b3NOfNhnptrfOXoCTckrdvBvkmSFsgw== X-Zone-Loop: 224b4a59e52f239eb2d9ac0dc957d8296dc1b055ce2c x-campaign-type: default x-transaction-id: 5b780938-fb98-4d01-9d73-dfa87e2066ba x-swg-uid: 01-7c56cb72-7d9b-4d72-8950-8aa733fb2aaa X-Mailer: Sweego Message-ID: <1793293930.8631fc262581453bbf619ec5b2062170.1a188a5ce83000f79f@vates.tech> x-swg-bid: 1793293930.8631fc262581453bbf619ec5b2062170.1a188a5ce83000f79f 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 5/6] automation/qtb: add QTB framework README From: Baptiste Le Duc To: Baptiste Le Duc Cc: Oleksii Kurochko , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini In-Reply-To: <1793290059.8631fc262581453bbf619ec5b2062170.1a1886abd5a000f79f@vates.tech> References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@vates.tech> <1fcacfcb-2775-4a4f-ac38-d7ed9a143e99@gmail.com> <1793290059.8631fc262581453bbf619ec5b2062170.1a1886abd5a000f79f@vates.tech> Date: Thu, 29 Oct 2026 18:12:03 +0100 X-Developer-Signature: v=1; a=ed25519-sha256; t=1793293923; l=639; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=vmESxvABw5DuWxRu2hAqWvXiUbAyjkmIDf8bgA9uF2M=; b=CahX+Im0hszWnUZSJFeBr93lQsh3oywftPDxhugFjg6oJjs7vsxoELQyGSh9kHGgif6t7lgDk JA05usH8cVLBmncENFw4kVIkttqFzAgjJQ2zHlBBRM9DlmQzbzRoHey 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: 1793293929272 X-purgate-ID: tlsNG-c201ff/1793293935-726B52A1-BAAE5232/0/0 X-purgate-type: clean X-purgate-size: 639 On 2026-10-29 17:07 +0100, Baptiste Le Duc wrote: > [ ... 72 lines skipped ... ] > > See my reply to patch 2: Xen doesn't use this. > > Right, Xen only reads mmu-type from dom0less guest nodes. I dropped it > for host in MachineConfig and in dts in v3. > Finally, I've just seen that dropping mmu-type from dts breaks boot: OpenSBI's fdt_cpu_fixup() marks any hart node without it as status = "disabled", so Xen then finds no usable CPU ("CPU with hartid=0 is not available"). I'd keep it hard-coded to "riscv,sv57" in the dts to match what QEMU's virt machine reports. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Oct 29 17:21:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 17:21:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465020.1675906 (Exim 4.92) (envelope-from ) id 1xMTo9-0007sG-76; Thu, 29 Oct 2026 17:20:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465020.1675906; Thu, 29 Oct 2026 17:20: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 1xMTo9-0007s9-4B; Thu, 29 Oct 2026 17:20:57 +0000 Received: by outflank-mailman (input) for mailman id 1465020; Thu, 29 Oct 2026 17:20:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMTo7-0007rv-M1 for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 17:20:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMTo7-00AHJl-2x for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 18:20:55 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae38058-e002-0a2a0a5209dd-0a2a450b96ba-48 for ; Thu, 29 Oct 2026 18:20:55 +0100 Received: from [40.93.201.49] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae38073-b7e8-0a2a450b0019-285dc9318828-4 for ; Thu, 29 Oct 2026 18:20:54 +0100 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DM8PR03MB6216.namprd03.prod.outlook.com (2603:10b6:8:27::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Thu, 29 Oct 2026 17:20:50 +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.0569.008; Thu, 29 Oct 2026 17:20: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=KQH+prNia2ZfWTcfEvdW8abTbWH4S10KHVNDOlqdckZhXE9vw0r894zqsdyKybW/6elaIK66yDm3cDCJY4H/rxz/cyi0Kn0IeCojBxroqnfjdN1fmV7cmJWqU9hcrWhfSfRd+3t8bFkNChZAKr0GJJasN9jCG+hiSAIy3z17MMfrsl6UlhGP7OZbA5QUQZgOXTpPYXuuv/p33xfZTb2+DX/GvYWllOT8I52xYI3hxjuFPbP+qzjjqmCF8bZJFNkx+yXVtEE73/MHFzBP6Tprk/fQucz8fpvkCa7HOxIBxE8iodT5SXuAlpIRe4Rpvg78LZuIA0U9Nb1AprCgTPXsnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GbT830pLYAscc7TFwa+jWCqOWo8Y9+8zwFKojsnqdxw=; b=pFZAznbmwBjQonEm7MyhWNiWPs0yVgiyvPJwXG5QoAKJdSOeF8EPkZSAqcTjM/mFUpXgQkYupIOE7kruguD8bqsNvXV6K9xS4TuMzCGS3kHzw+/U8R9ScwhVlGNMxEsCzFU75ITEGuROjjTLjGrWzftQRPZdAika/LTIeYBB8XXuhadw6EMowPTsgpHUc8xuGQGRGgLhS1jM1MNPAEGU6w2DUR+J8zD+AT7Z++X88guyGI1hTZANTQgWKl1z8FeMTHBumG6dyEmd5HRpIjIyKOFbm6FvoXtprGml3C6O7YN5PAAccdq8amcNDolwqw3UcQ6UWcRmWsXZEE7OHrgAFw== 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=GbT830pLYAscc7TFwa+jWCqOWo8Y9+8zwFKojsnqdxw=; b=iDwRUq7ZfUmACvuoX/LXVJ4d7ieVRVD1vXMKUfQYE4nIwvLnrf43PiLHRCJcFFUMUp/Ag4Bh/9ryV4GJZjg3ij+VlQBjyr0SFOZs90O9FY98XwADTrRTdweA95Jj+YUGpxaJDyP5bNRKrSfQlp72AKVir16uBihI0XhD9z+F3Ik= From: Ross Lagerwall To: =?utf-8?B?Q2h1bmppZSBaaHUg77yI5pyx5pil5p2w77yJ?= , "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" , Andrew Cooper , "roger@xenproject.org" , "jason.andryuk@amd.com" , "teddy.astie@vates.tech" Subject: Re: [PATCH v1] x86/nestedsvm: honour L2's EFLAGS.IF when L1 clears V_INTR_MASKING Thread-Topic: [PATCH v1] x86/nestedsvm: honour L2's EFLAGS.IF when L1 clears V_INTR_MASKING Thread-Index: AQHdXVVTRd+tP+KIck2rlzcwmbytZrcU2N01 Date: Thu, 29 Oct 2026 17:20:50 +0000 Message-ID: References: <20261016100058.268266-1-chunjie.zhu@citrix.com> In-Reply-To: <20261016100058.268266-1-chunjie.zhu@citrix.com> Accept-Language: en-US Content-Language: en-US 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: CH8PR03MB8274:EE_|DM8PR03MB6216:EE_ x-ms-office365-filtering-correlation-id: a045a87b-031c-40d2-a124-08df35e0fa85 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|22082099003|18002099003|56012099006|11063799006|10067099003|261028144727099003|261021121427099003|261009223027099003|261026140227099003|261022105027099003|38070700021; x-microsoft-antispam-message-info: +FhspT2XKOPK9BqnHHprCOgFLAP0oU6XTDkgoJbo2eBggy7pacQLz81OIp0dLnGRojT43HcA4HJGIlYbsnYHZW+rEnj0CJ/OiaAYSCg6vjam+dpA0VVTAwNxZRGR/MDB6vuEhkNLTb+sOPG6tZ9Kl3OlB+96aMzH5U7LC4oy/2tL3eiFsFSiGTYHbALZJdT0roRNLjlaLyTgBBWhrWsOIoEcybzR/drHmrhQwcSdIBTC3hXEP1x6oq/yZIZpiB4fbxLrm/xApQ/HprR5mpShuXD+UpVnqsgTF6CtuvZBC1mHqEUIY9/8Ok1linzbiV/6sFfyihKsbvr0OR1iY63eOPVOjDxhNECvj1D3FzGXh1h+R+q+iNyd7blvYJZGcplRW+8dwR2UnOjVNaAs+kDAP8DNcPj8h8ogd4SRd0v6bQNYFs/3thaYRsO/KFB4h3FIzEdOvqa3MLNxLN9aIt/BRI+2jhvxpV512fGpbwG84DiVzFcYBJsKZAX6yyvgNYthPHQf7LQYsxhbyaBBOHiBmcnGK898sgA/weHsPSBcMES0opgEsbWAbHB9rNg2PWzY54pr5oBzsDev/HMTxW/Px0f74FDZHYfiEC/KHpEDfiW+3xwLbpJB4aXLr890d22t/yKqGjTHWqsRFeO4zZrXLna/cnFB9cBEn/zQLHUQdj1y64VaAdT0W6LgY7bXtkBclKa/324oCjJi4YUg9aL1eQ== 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)(22082099003)(18002099003)(56012099006)(11063799006)(10067099003)(261028144727099003)(261021121427099003)(261009223027099003)(261026140227099003)(261022105027099003)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VVJEdVMvTXE3cWJsekxsaDk5MjdyVkJ5ZFhzU2VYTUp6RUwzbmJkOXBGMEZx?= =?utf-8?B?K3ZneER1MkF5SXpBYWdTY25VY05ia2ZnSlV0UHNBTGQ2ODlOYm8rMnVTaUdz?= =?utf-8?B?QkJjSThRSlZ0cHFlSzdmTUx2KzJGOUkzV2hNZ2dVVCs2Sy8rY2FCUVp0dy9D?= =?utf-8?B?Nk1ORFlsT0EyOHpySzRZdStJMGxJRC8vdDROYy9ZeUdoU0E4d3dTMURxS2t4?= =?utf-8?B?WkozeUdZVEZtbUxHNEVGK2dDcVJ2WWdQS0w3TmdXRW9JLy9rRDFGQjI1RWNY?= =?utf-8?B?VHhZVFdkblJBbjZLUjdBWUsvWVE2bXNWWmRRdU9yK0gvVit3WWh6UW51c0VW?= =?utf-8?B?TkxmamFCbm5CNVQvdjdVZEEvTWxyaTZId21mdFJ0OG0wUk05b0lISklCQjE2?= =?utf-8?B?Q0kzMFJmQVR1WHY1b1BWalVMd09tUUZCVjlRckZjOFd4RkdVTGRVYURZMm5z?= =?utf-8?B?UlVIOW5naGZ0d0Eyb1ZiaVpWRGw1RUgxdk5DZGU0eisrVjFST1BRQld0VGJz?= =?utf-8?B?QU9oY2FWYnlxRENUUlo3dkM0dWZYellkUEdRZE03MzhjdTdybkRuZ09KOVdB?= =?utf-8?B?VnZmR2p1c1JLMHFma1ZUL3pRNVZvYWdxYnVrQXBkY0R6TlFFelVvVUwwYmV4?= =?utf-8?B?eENienJhUC9vT1YrTjBrbUxpUGg0Q1Z0UFlZOUYvdUF4eU82cTlDa3R3emZn?= =?utf-8?B?YUpRVTYwSlY5b1pheVlCYmxKMzEyQU42Y3daRUYwTnZMWmtPZ1lUVE8wVUx5?= =?utf-8?B?MmpyUU80c3ZhUDVoY3p4UytYYWRqN0YvUXlCN2NBbERVMWRmSFoybzBNc3lK?= =?utf-8?B?VUExMGdBQmdDcjRjaUxWV3h3cFRZQmxZdzJhaTJlc1J1ZmFaaWU0UmdvQkhW?= =?utf-8?B?elJJR1hCd2FJOU5aNTIveXFNdUxVWU5kVzFDNDExejRVdW80OEd5bFBiY1c3?= =?utf-8?B?Nlh1RW5QZUYyd01oK1ltTElGdC9MZ2o4cHVSbkt1Q1FlY3JxZzdjUFpmVDJ1?= =?utf-8?B?Sko0L04vNUU4ZXk2Mkx0UjRCYkgvWm9EWnhrWjFVMUkxbUJuNkFXUTNKUWJt?= =?utf-8?B?RElhaHgreDBxMkVObWRDQ3U0SlVHRWc0VmxWRVpmcFkrR0NiZ1NCdUN1OFNR?= =?utf-8?B?RGVtZ0pjTU5CY0tUU3dKWlJRc2JJQ3hGSHlZLzdiRWEzM3VWQ21NdXJ5aWh6?= =?utf-8?B?M2RiZnovSU8rK3o0OFB4VDdqdjVJS0xZM0tuaVM3MUM5ckh4MkF6b20vWnQy?= =?utf-8?B?eS9VVjl3UmpVWE5BVkFvL1N3Y0ZGNzJrTHE3VzdjSzNxT3lBMUVGd254UVFI?= =?utf-8?B?UksyV0lFemNGWG9uK3ZHZGIrMC9VTEZ2ZEV3K2VoamRrV3ZpUkw0R0pOaWRx?= =?utf-8?B?WmJsNTVtQ0dLVFJ3aUQrVVBtRFA5SEJUTytXQkNUcG1rb0w5Q0xVZHBBVnEz?= =?utf-8?B?amtZSWNlVUVKNmMvTndBWFpmTzdjVWhjTXBISHF3TW15TXVpMGtjNGhIZThj?= =?utf-8?B?L2dnUlhlQ1NNbURLdDVwdFpvd3FqRENGUTVpZ01IV21IZzExUU9sbFYreWoy?= =?utf-8?B?ZnBBNjBpR1cxVlBqYjQyTUcrMmN3WkR4SVdJTjQ3QzhONjZ5UXJsMjVvQS9j?= =?utf-8?B?YmdMTS9TNGgxMHI2WGRNbGRsZkhFU3FOSkRaRkZJeHQ1djVTV01kcmJRa0w0?= =?utf-8?B?T2dacnZHVlo4elhJWGNzc3A2cEdnN3poSjIyWlY5YzlvUGw1L2hvdmtZaWVS?= =?utf-8?B?Y2hJMmVFQmNTaU9OK292cnFrMEIzNHRDTXgyb0tCYkhhT2g4cWxCN0lpSTBZ?= =?utf-8?B?RW9jNXJLQ3VuVHJRWXlWeExLL1Rmak90WnBCRjc1ZEN6MjluTUk2UExVaTRa?= =?utf-8?B?a293bGNIQ1RxMXFzaW0yNG9WamVhb0hsSC81QlpHeEpLN1RFNTl0Y05xK1dr?= =?utf-8?B?a2RMRXc4cHMxV3ZERk9ERFVabkVnTEFyakQ2R1BuN0dtYWZxYjZZcHhIUENM?= =?utf-8?B?TVlUMENlMCtxSmhBR2F5Y0REQmNLbTZHR1hhNmUvaWdCaUxlRllranFCT2ky?= =?utf-8?B?ZUVOVEQzbUtNUVlDcnBFQ2VEY2t1K3RQMnJMYVdSS1JCRU1RUkltWGovaTNU?= =?utf-8?B?d0dGc3I2eVdiOUxReE84MG1obW0yWTFzUzNxanQzcjRCWnRMdmVMa0EwcU5S?= =?utf-8?B?blREcnNGTldoeWZsMSsrWXhtWk5UU3lPQU5qeHNTOEJ2WURIRHJzMTJPUHhN?= =?utf-8?B?VlJKT1JqVVlxMmJ5OElOeUptOCt1L2svdkhLK1hqN0JPa2JMdkRZamJCTHVt?= =?utf-8?B?M3RqMkk3a3RQSnlnd2pXRmdVYjRzY3FuZVd5MUpvMHpVT05EcUZsdz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a045a87b-031c-40d2-a124-08df35e0fa85 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2026 17:20:50.1755 (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: 9aSEXPfub1FvgDK2veLmrLaMFRO5TCb7CbCGYqo7nlnYxuLlVib+hQQe6zbjQgIIY5TAoiSeIlx6GumFV6PW9qG4Y/uhX8fOsgU0yM5hxDE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR03MB6216 X-purgate-ID: tlsNG-42698a/1793294454-1B4D39EA-5D3638EC/10/78276251493 X-purgate-type: spam X-purgate-size: 4780 PiBGcm9tOiBYZW4tZGV2ZWwgPHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbnByb2plY3Qub3Jn PiBvbiBiZWhhbGYgb2YgY2h1bmppZS56aHVAY2l0cml4LmNvbSA8Y2h1bmppZS56aHVAY2l0cml4 LmNvbT4KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjYgMTE6MDAKPiBUbzogeGVuLWRl dmVsQGxpc3RzLnhlbnByb2plY3Qub3JnIDx4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc+ Cj4gQ2M6IGpiZXVsaWNoQHN1c2UuY29tIDxqYmV1bGljaEBzdXNlLmNvbT47IEFuZHJldyBDb29w ZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyByb2dlckB4ZW5wcm9qZWN0Lm9yZyA8cm9n ZXJAeGVucHJvamVjdC5vcmc+OyBqYXNvbi5hbmRyeXVrQGFtZC5jb20gPGphc29uLmFuZHJ5dWtA YW1kLmNvbT47IHRlZGR5LmFzdGllQHZhdGVzLnRlY2ggPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+ OyBDaHVuamllIFpodSDvvIjmnLHmmKXmnbDvvIkgPGNodW5qaWUuemh1QGNpdHJpeC5jb20+Cj4g U3ViamVjdDogW1BBVENIIHYxXSB4ODYvbmVzdGVkc3ZtOiBob25vdXIgTDIncyBFRkxBR1MuSUYg d2hlbiBMMSBjbGVhcnMgVl9JTlRSX01BU0tJTkcKPgo+Cj4gRnJvbTogQ2h1bmppZSBaaHUgPGNo dW5qaWUuemh1QGNpdHJpeC5jb20+Cj4KPiBMMCBhbHdheXMgcnVucyBMMiB3aXRoIFZfSU5UUl9N QVNLSU5HIHNldCwgc28gYSBwaHlzaWNhbCBpbnRlcnJ1cHQgZXhpdHMgdG8KPiBMMCByZWdhcmRs ZXNzIG9mIEwyJ3MgRUZMQUdTLklGLsKgIG5zdm1faW50cl9ibG9ja2VkKCkgb25seSBibG9ja3Mg d2hlbiBMMQo+IHJlcXVlc3RlZCBWX0lOVFJfTUFTS0lORz0xIGFuZCBMMSdzIElGIHdhcyBjbGVh ci7CoCBXaXRoIFZfSU5UUl9NQVNLSU5HPTAKPiBhbmQgTDIncyBJRiBjbGVhciwgbmVzdGVkc3Zt X3ZjcHVfaW50ZXJydXB0KCkgd291bGQgc3RpbGwgaW5qZWN0Cj4gVk1FWElUKElOVFIpIGludG8g TDEuCj4KPiBQZXIgdGhlIEFQTSAodm9sLjIgcmV2IDMuNDQgIlBoeXNpY2FsIEludGVycnVwdCBN YXNraW5nIGluIEVGTEFHUyIpLCB3aXRoCj4gVl9JTlRSX01BU0tJTkc9MCBMMidzIElGIG1hc2tz IHBoeXNpY2FsIGludGVycnVwdHMsIGFuZCBhIG1hc2tlZCBpbnRlcnJ1cHQKPiBtdXN0IHN0YXkg cGVuZGluZy7CoCBSZXR1cm4gTlNWTV9JTlRSX01BU0tFRCBmb3IgZXh0ZXJuYWwgaW50ZXJydXB0 cyBpbgo+IHRoYXQgY2FzZS4KPgo+IFNpZ25lZC1vZmYtYnk6IENodW5qaWUgWmh1IDxjaHVuamll LnpodUBjaXRyaXguY29tPgo+IC0tLQo+IMKgeGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3Zt LmMgfCAxMSArKysrKysrKysrKwo+IMKgMSBmaWxlIGNoYW5nZWQsIDExIGluc2VydGlvbnMoKykK Pgo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaHZtL3N2bS9uZXN0ZWRzdm0uYyBiL3hlbi9h cmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2bS5jCj4gaW5kZXggZmFhY2ZlMDA3ODMyLi5hNDE5YjQ3 ZWI1ZjYgMTAwNjQ0Cj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMKPiAr KysgYi94ZW4vYXJjaC94ODYvaHZtL3N2bS9uZXN0ZWRzdm0uYwo+IEBAIC0xNTE0LDYgKzE1MTQs MTcgQEAgbmVzdGVkc3ZtX3ZjcHVfaW50ZXJydXB0KHN0cnVjdCB2Y3B1ICp2LCBjb25zdCBzdHJ1 Y3QgaHZtX2ludGFjayBpbnRhY2spCj4gwqDCoMKgwqAgY2FzZSBodm1faW50c3JjX3BpYzoKPiDC oMKgwqDCoCBjYXNlIGh2bV9pbnRzcmNfbGFwaWM6Cj4gwqDCoMKgwqAgY2FzZSBodm1faW50c3Jj X3ZlY3RvcjoKPiArwqDCoMKgwqDCoMKgwqAgLyoKPiArwqDCoMKgwqDCoMKgwqDCoCAqIFdpdGhv dXQgVl9JTlRSX01BU0tJTkcsIEwyJ3MgRUZMQUdTLklGIG1hc2tzIHBoeXNpY2FsIGludGVycnVw dHMKPiArwqDCoMKgwqDCoMKgwqDCoCAqIChBUE0gdm9sLjIgcmV2IDMuNDQgIlBoeXNpY2FsIElu dGVycnVwdCBNYXNraW5nIGluIEVGTEFHUyIpLsKgIEwwCj4gK8KgwqDCoMKgwqDCoMKgwqAgKiBh bHdheXMgcnVucyBMMiB3aXRoIFZfSU5UUl9NQVNLSU5HIHNldCwgc28gdGhlIGludGVycnVwdCB3 b3VsZAo+ICvCoMKgwqDCoMKgwqDCoMKgICogb3RoZXJ3aXNlIGV4aXQgdG8gTDAgYW5kIGJlIGZv cndhcmRlZCB0byBMMSBldmVuIHdpdGggTDIncyBJRgo+ICvCoMKgwqDCoMKgwqDCoMKgICogY2xl YXIuwqAgTGVhdmUgaXQgcGVuZGluZyBpbnN0ZWFkLgo+ICvCoMKgwqDCoMKgwqDCoMKgICovCj4g K8KgwqDCoMKgwqDCoMKgIGlmICggIXZjcHVfbmVzdGVkc3ZtKHYpLm5zX2hvc3RmbGFncy5maWVs ZHMudmludHJtYXNrICYmCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAhKGd1ZXN0X2NwdV91 c2VyX3JlZ3MoKS0+ZWZsYWdzICYgWDg2X0VGTEFHU19JRikgKQo+ICvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIHJldHVybiBOU1ZNX0lOVFJfTUFTS0VEOwo+ICsKPiDCoMKgwqDCoMKgwqDCoMKgIGV4 aXRjb2RlID0gVk1FWElUX0lOVFI7Cj4gwqDCoMKgwqDCoMKgwqDCoCBleGl0aW5mbzIgPSBpbnRh Y2sudmVjdG9yOwo+IMKgwqDCoMKgwqDCoMKgwqAgYnJlYWs7Cj4gLS0KPiAyLjM0LjEKPgoKV291 bGQgaXQgbm90IG1ha2Ugc2Vuc2UgdG8gY2hlY2sgdGhpcyBpbiBuc3ZtX2ludHJfYmxvY2tlZCgp IGluc3RlYWQ/ClRoZXJlIGlzIGFscmVhZHkgYSBzaW1pbGFyIChpbnZlcnNlKSBjaGVjayB0aGVy ZSBzbyBleHRlbmRpbmcgdGhhdCBzZWVtcwptb3JlIGxvZ2ljYWwgdG8gbWUuCgpFLmcuIHNvbWV0 aGluZyBsaWtlIHRoaXMgKHVudGVzdGVkKToKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaHZt L3N2bS9uZXN0ZWRzdm0uYyBiL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2bS5jCmluZGV4 IGIxOTJiZTBkNTZiMS4uOGJkZWQ4YjlhOWMyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaHZt L3N2bS9uZXN0ZWRzdm0uYworKysgYi94ZW4vYXJjaC94ODYvaHZtL3N2bS9uZXN0ZWRzdm0uYwpA QCAtMTIxMyw4ICsxMjEzLDkgQEAgZW51bSBodm1faW50YmxrIGNmX2NoZWNrIG5zdm1faW50cl9i bG9ja2VkKHN0cnVjdCB2Y3B1ICp2KQogICAgIHsKICAgICAgICAgc3RydWN0IHZtY2Jfc3RydWN0 ICpuMnZtY2IgPSBudi0+bnZfbjJ2bWN4OwoKLSAgICAgICAgaWYgKCBzdm0tPm5zX2hvc3RmbGFn cy5maWVsZHMudmludHJtYXNrICYmCi0gICAgICAgICAgICAgIXN2bS0+bnNfaG9zdGZsYWdzLmZp ZWxkcy5yZmxhZ3NpZiApCisgICAgICAgIGlmICggc3ZtLT5uc19ob3N0ZmxhZ3MuZmllbGRzLnZp bnRybWFzayA/CisgICAgICAgICAgICAgIXN2bS0+bnNfaG9zdGZsYWdzLmZpZWxkcy5yZmxhZ3Np ZiA6CisgICAgICAgICAgICAgIShndWVzdF9jcHVfdXNlcl9yZWdzKCktPmVmbGFncyAmIFg4Nl9F RkxBR1NfSUYpICkKICAgICAgICAgICAgIHJldHVybiBodm1faW50YmxrX3JmbGFnc19pZTsKCiAg ICAgICAgIC8qIHdoZW4gbDEgZ3Vlc3QgcGFzc2VzIGl0cyBkZXZpY2VzIHRocm91Z2ggdG8gdGhl IGwyIGd1ZXN0CgpSb3Nz From xen-devel-bounces@lists.xenproject.org Thu Oct 29 17:55:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 17:55:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465050.1675915 (Exim 4.92) (envelope-from ) id 1xMULC-0004wK-Nw; Thu, 29 Oct 2026 17:55:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465050.1675915; Thu, 29 Oct 2026 17: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 1xMULC-0004wD-Kg; Thu, 29 Oct 2026 17:55:06 +0000 Received: by outflank-mailman (input) for mailman id 1465050; Thu, 29 Oct 2026 17:55:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMULA-0004w6-Ma for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 17:55:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMULA-006XHH-2v for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 18:55:04 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3885e-2eae-0a2a0a5409dd-0a2a4508ca5c-8 for ; Thu, 29 Oct 2026 18:55:04 +0100 Received: from [40.93.201.68] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae38876-f659-0a2a45080019-285dc9445fbf-3 for ; Thu, 29 Oct 2026 18:55:03 +0100 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DS0PPFF7CE02BD0.namprd03.prod.outlook.com (2603:10b6:f:fc02::39a) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Thu, 29 Oct 2026 17:55: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.0569.008; Thu, 29 Oct 2026 17:55: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=h72JyTfQ8zNcjC6lGVFh2V3wBjdNO7flrH4z2lgTG0CxeCeTVeqTeG2QwQgvBy9N2HMpU+0Eg/1e6B/6/m2NPpJtmzOm7nz72AbuZ8njcYV4pZiLbARAQfARyb7gfm4QXvZ3Pp9typiMXllpgrLYUxkay6OQ2qQVK4BYbkHP/61313kj0m9y33c6B+Z+c2RLo1KdvEh9Zvbk1sKmrHWWa4NXWkgKJxzHOeVNm3Q4w4W57Wf094obcpAjetJH/O8LAXp+c9Mh/3T1BfpTF+DLDEIj/j472z6dgkzTZ3Ofq6xW6Anm9mH3EI67fd+xA0vFiA+/513TsFB7WmGc+8j/fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vGab5AIaR1STeapt5WDS0Xtnl2GjCzzUijhZvewu1AI=; b=DJ3sBDT9lTZexORZjef+f1ZECj5ZmX5d1YCEwdTO2TixMdgY89pMCI9niIV23MJDPE5hG07Y8tjqEnuUtMdqBG/7uXB9gkp200JA+IBBBXgHV2OgTVUZ14OnPMjk05F0vB9tt8UljlqSYiyGs1L/hgouisxP2ulZqBS4vRBjNfqQGgMH7ixwlUjtMhMrc33xT3gkOkfhCRLFOVaMepoEldLAiMijn9GYX/1WAUeZY4Lm7G0WZNpBtfszFHJMsu7vEG0Ida3XvnUouLqRRTXGgexBzorA3JDyVqy2+1SwUCeg+erOrO+NJYZPqUx16IWBaoLmQXh2CuiIJbFiAyDeSA== 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=vGab5AIaR1STeapt5WDS0Xtnl2GjCzzUijhZvewu1AI=; b=OQM3mqTUw1yTnYZqwknKwJllgH/25GmSlaKe5pxfegTjxzyrSUK6ZPGI219ZvybUcNor5NjVBFKH1lB9juEwLcyhpfEhv9nTsN2ZANTCQiEiskiiH3X6fVmdJRvFSuXI7RtcymTXy4EPwuYUNMjuXBmvbbWFefFX1CAM58DTuIU= From: Ross Lagerwall To: =?utf-8?B?Q2h1bmppZSBaaHUg77yI5pyx5pil5p2w77yJ?= , Andrew Cooper , "xen-devel@lists.xenproject.org" CC: "jason.andryuk@amd.com" , "jbeulich@suse.com" , "roger@xenproject.org" , "teddy.astie@vates.tech" Subject: Re: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT Thread-Topic: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT Thread-Index: AQHdXTzn+Hkg06vIsUeaRhcdK6IUircU3j9P Date: Thu, 29 Oct 2026 17:54:59 +0000 Message-ID: References: <20261016070611.255322-1-chunjie.zhu@citrix.com> In-Reply-To: <20261016070611.255322-1-chunjie.zhu@citrix.com> Accept-Language: en-US Content-Language: en-US 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: CH8PR03MB8274:EE_|DS0PPFF7CE02BD0:EE_ x-ms-office365-filtering-correlation-id: 8cfbd4d9-3a9b-4785-ca7e-08df35e5c04a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|261026140227099003|38070700021|4143699003|56012099006|11063799006|5023799004|261022105027099003|261021121427099003|10067099003|261022075727099003|261009223027099003|261028144727099003|261021123027099003|22082099003|18002099003|261026121527099003|6133799003; x-microsoft-antispam-message-info: 11EYPlGx872ph9T9CI4t9dxW7PDztqb1H6PGID5RV//m7mHN+twT08Ajq+BGAL9X+zgphHj0boCEVdoafPCZitKqRsYvMUoBX/PQxkuz7dmHnohurkSHHYaJZ8A0Q/5vQ6Rc6z41ZTiaSR+K0WRfdjhnuUJULNmKQ7/K0tr3+D9685E9IVuAdG39Y1N8rIHYstQHbSBdZWt2OKmn1iRKv6zEQB2Csw0tG7oesTwsOj+6DAwVu+S/nR4SrKmQneOFwCDEMDwwPJ7WTP0fKbB7X845xFY7FspKh6vXI0LjmDl4hEOVRsSWD/f3z4p2jd+K1+V7I8SkmkuhQy32gsYo2iUpBydTCYlo41u7ckEcNLNmBmRye4fwV6dmJ9I+SYMXWToeuGAC4qky9yIsnI1EFyE31wK9yVaPcJNIpRWY01wn5vV4n6TGNFwJFfOFIlgQH45FyEh7dEaGE22KbNHJuvG32wFdxfp+Yi1ymKDjn/KjiLFV8Tuqrg+0z/XqrM2q/4w12qPPZ8FI5393lQrHAjNBhUrEsD1ydUd9fRi3fWIpcfRIuocPf5CE+lCv1OtxjQkkFFit5xY/18Py+4E1cI3JRaFFh2lCkmf+TwvpMlYD+bSglf73ZdSMlwh+AILiX8PamRnRhU9NLLXkOlJd7eb595f/OaxW3fNmOQgP8iw= 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)(261026140227099003)(38070700021)(4143699003)(56012099006)(11063799006)(5023799004)(261022105027099003)(261021121427099003)(10067099003)(261022075727099003)(261009223027099003)(261028144727099003)(261021123027099003)(22082099003)(18002099003)(261026121527099003)(6133799003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UE1md0NtZVlYbzFxT2pUcDdvMjM4SzJTRkFQaWwvTGFVdWtRdDVsK29yWFY4?= =?utf-8?B?bEx5K01WdjVuR1JTZkZxSFhzSGdVMm11MmRFMERLQ3g1eG1tWTU3MXQ0N0g4?= =?utf-8?B?YmtTSkRCZlVJYVRLOVdvU29UVkV0c2MzN0xqY0xKa3ZJUmxWV3VRVEJjWTI0?= =?utf-8?B?Wmk0TGtrNEgzNzJFdGxCTm1pRWZQTzd0Y0lUM3J2SDNBS0gzVEV4ajFyN1dh?= =?utf-8?B?a2dLVWVPL09ZYzRqbnJrTnV3TnFlTjBPT1owOWFpQ0hJWTJEcXdKOFcyaDly?= =?utf-8?B?NndNRzRlcW5MQ1dhOW5TSml2YTlWREZ4L2RSNkNMdnpzOVBTTHc1c2RhWFIy?= =?utf-8?B?MFhxRzAzV1gzcGlwdTVBWjdCMkF5NTk0dVNWNThiNGVuUkJ1YWVHVFlEclRH?= =?utf-8?B?MFpUNHJ6OHFnei9VMXE3MXVjV2lqYVBUNmhiZ0J2cFBRSGo5RzRBUWE5V1Nm?= =?utf-8?B?c2drc3BVSDZhWStaUEQrLzl6UGtPbVRGQmhoOHBGVG1MQllBYzdseFRoVXZw?= =?utf-8?B?VHRMQVBPVWJQMm15aGFlK0JyUFNJT2lKK3VXWVQ3T0xiZ0JxN1ZxSTdUYVc4?= =?utf-8?B?RUdqMnV1bVdOdUN4WVk3M0ZmelYzbm5XTG9yUVdkTFJ3cThZd2lqS2RNU0Jw?= =?utf-8?B?bmVSdXdUYzlLZWJ1azM2UVR2Wkt0VWZJUlFsZ2d4V1VZMHBHdVR3M1paWUxO?= =?utf-8?B?ZkVHMFBpcjhGRlJtWDJvU2xYM204bE5BTXRvY3N2N0tkYVkxb2tLaGFRQXFR?= =?utf-8?B?NVVaanhQb3UxdHhHOGxBdlpnT3hWTVpJUmRXdUZidlc0RUJzb2c2MzNWRmha?= =?utf-8?B?VGozMWpvM3ZRTG1GWGtIa0Fkc0dvemhraWpYWjN5Rk54UjZmbEVla1F5N0N1?= =?utf-8?B?VWVXengweFo4UE9SQ01teVNmbnByejVjNW5pVHhOd3BKZ3hFQi9FcmxwNkdH?= =?utf-8?B?cUxaT09PN0dTMnBxRnN3N2JLL3VJRjRtaG9MOE4vV3ZJL21tWm9ZV3JsSmFL?= =?utf-8?B?L3hIUHh4ZmRZSTRPL2R4cUhMVDFTL3J5aDZ4VkdCOFhubFBhYUlBQi9SYmtU?= =?utf-8?B?WXhCUWNJN1JRMzgwbzBQN09lLzRPeU5pN0Q0NXNrVFkxMGpmcmxuaUZDRlZU?= =?utf-8?B?ZnBQRWFhSmkxdXhZVGZkaEcybVVISVhhQ0J0L0wwa2V1UStCUURRdytSVGo4?= =?utf-8?B?TUVMdEVOb1RuYlBhem1rTVZqa2drVmVmNUhWM3UxdW5mRlVoNkNYV09OdU9F?= =?utf-8?B?b21pMG0rWlNhSjQ1Yy9mbGxSM2p0QzJhbTd1SkxNMVJ6T3dTYXJXY1R1ckxJ?= =?utf-8?B?RU1yejZsa0tzT0RNaTRET2hqYlVRWUowTHVILzJYQ3VacUlOK2pZcTlQM0tJ?= =?utf-8?B?YktTQlNLYXBtMFpwMFRMcWFuVWRaOEhubCt3V2plQzN5VEZ6OVl2UXBmNUhN?= =?utf-8?B?MTQ4R0FhZnhFOWRzT0lBd0FiYndHQ21HMVpMblZlbkp6L2o4TTVxUjRaRmE1?= =?utf-8?B?K3dmL2c4dnk1STRIM3diUG5uRGpQNXAwY2w4QlMvNGRvMzRNblJUR2pqMTFl?= =?utf-8?B?cHdmeXRBVXVxUGl0OXRQOTVaMWY5aGtJQUt4NEZMdjNreGpCYTFyQ0ZrTStj?= =?utf-8?B?UVNEOGU5M29iUEp3Q21kdERzd0liSmtadmN6eUp0NW9PcHg0ai9lZGVkbVdk?= =?utf-8?B?NkNrRTV5R0YwRjRZckwzNFJoOWRES1FJb2s0d2I0citqVnliUm82bEk0Ujh6?= =?utf-8?B?ZDkwT3ZNemFGWm9NY0RBRUdZWnBtUVRJeC9tc2RPMjJaODVpY05yTVZQN0RS?= =?utf-8?B?RUlaS242MEJmc3F0TFpJQk9KYzREbEF6MVN6TU5nSnFzN21VZ0dFcjBxOGts?= =?utf-8?B?bmVGdGVybHRrR0t0QTRDNzNFOERBb0JsdmFDWHN2RldoTktRTVNRVXBCV3Fl?= =?utf-8?B?dVV2M1lxaUt5YlhLbVE3QWNYNnUzSmF3OW14eEZvV2VEVmVlSHRGTndNbVpN?= =?utf-8?B?Qk9jaE9EVHcxY2tOYUxpZW1mMHIyemZyR0kzUDZ6TGxYbkljOGtRTkx1ZU9B?= =?utf-8?B?SlplSUdWY3dTT2hjNDgxVXRHcFZ2SWRvc0I1UDRuRU9XYk1wYkl2bWYvSFBZ?= =?utf-8?B?VUYwSDJ5dm8vYWdmeUNlcUJyUEUvVEdiM1kraCtPenlQYkRXbUYwMDBRUmlx?= =?utf-8?B?REZDQ2piRmk4cThFVm1YeWZlQmp0d0Z1VmVrZmJXeTRxNHd1U1g1bWF0NzdF?= =?utf-8?B?TUZYNXZpbE5xRnhHU25SMmRJZFMyYUFkMEJ6U2pYcmJpTnRMT3JPUmpFbFlL?= =?utf-8?B?dUdYYlQyNC9oTE94T1dMSlQ1K1NpWDBXU3BSZ3R1cGJtTW5tYzFBZz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8cfbd4d9-3a9b-4785-ca7e-08df35e5c04a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2026 17:54:59.9217 (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: hiFhA8ZJanD4GekcemF0rLY4BC+KXe6iV6m5y9RzkY9FKg3x/uHoDstAEB0mAXBNBnCWYqXYWFj0Yg7DNoACigMtObvgWEl8ToGZIfzw5Ws= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PPFF7CE02BD0 X-purgate-ID: tlsNG-c1860d/1793296504-D775B87B-190D8FAE/10/78276251493 X-purgate-type: spam X-purgate-size: 4894 PiBGcm9tOiBYZW4tZGV2ZWwgPHhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbnByb2plY3Qub3Jn PiBvbiBiZWhhbGYgb2YgY2h1bmppZS56aHVAY2l0cml4LmNvbSA8Y2h1bmppZS56aHVAY2l0cml4 LmNvbT4KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjYgMDg6MDYKPiBUbzogQW5kcmV3 IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IHhlbi1kZXZlbEBsaXN0cy54ZW5w cm9qZWN0Lm9yZyA8eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnPgo+IENjOiBDaHVuamll IFpodSDvvIjmnLHmmKXmnbDvvIkgPGNodW5qaWUuemh1QGNpdHJpeC5jb20+OyBqYXNvbi5hbmRy eXVrQGFtZC5jb20gPGphc29uLmFuZHJ5dWtAYW1kLmNvbT47IGpiZXVsaWNoQHN1c2UuY29tIDxq YmV1bGljaEBzdXNlLmNvbT47IHJvZ2VyQHhlbnByb2plY3Qub3JnIDxyb2dlckB4ZW5wcm9qZWN0 Lm9yZz47IHRlZGR5LmFzdGllQHZhdGVzLnRlY2ggPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+Cj4g U3ViamVjdDogW1BBVENIIHYyXSB4ODYvbmVzdGVkc3ZtOiB3cml0ZSBiYWNrIFZfTk1JIGFuZCBW X05NSV9NQVNLIG9uIG5lc3RlZCAjVk1FWElUCj4KPgo+IEZyb206IENodW5qaWUgWmh1IDxjaHVu amllLnpodUBjaXRyaXguY29tPgo+Cj4gV2hlbiBWX05NSV9FTkFCTEUgaXMgc2V0LCB0aGUgcHJv Y2Vzc29yIG1hbmFnZXMgVl9OTUkgYW5kIFZfTk1JX01BU0sKPiBhdXRvbWF0aWNhbGx5IChpbmNs dWRpbmcgb24gSVJFVCksIGFuZCB3cml0ZXMgYm90aCBiYWNrIHRvIHRoZSBWTUNCIG9uCj4gVk1F WElUIChBUE0gdm9sLjIgcmV2IDMuNDQsICJOTUkgVmlydHVhbGl6YXRpb24iKS4KPgo+IG5zdm1f dm1jYl9wcmVwYXJlNHZtZXhpdCgpIG9ubHkgcHJvcGFnYXRlZCBWX1RQUiwgVl9JUlEgYW5kIChj b25kaXRpb25hbGx5KQo+IFZfR0lGIGZyb20gdGhlIEwyIHNoYWRvdyBWTUNCIGludG8gdm1jYjEy LiBWX05NSSBhbmQgVl9OTUlfTUFTSyB3ZXJlIG5ldmVyCj4gY29waWVkIGJhY2ssIHNvIEwxIGtl cHQgc2VlaW5nIHdoYXRldmVyIGl0IGhhZCBsYXN0IHdyaXR0ZW4sIHJlZ2FyZGxlc3Mgb2YKPiB3 aGF0IGhhcHBlbmVkIGluIEwyLgo+Cj4gQ29weSBib3RoIGJhY2sgd2hlbiBMMSBoYXMgZW5hYmxl ZCB2Tk1JIGZvciBpdHMgZ3Vlc3QuCj4KPiBGaXhlczogODZhMjAzYWI4ZDM4ICgieDg2L3N2bTog U3VwcG9ydCB2Tk1JIG9uIGNhcGFibGUgaGFyZHdhcmUiKQo+IFNpZ25lZC1vZmYtYnk6IENodW5q aWUgWmh1IDxjaHVuamllLnpodUBjaXRyaXguY29tPgo+IC0tLQo+IHYyOgo+IMKgKiBSZXdvcmQg Y29tbWl0IG1lc3NhZ2U6IHRoZSBwcm9jZXNzb3IgbWFuYWdlcyBWX05NSS9WX05NSV9NQVNLIGl0 c2VsZi4KPiDCoCogQWRkIEZpeGVzOiB0YWcuCj4gwqAqIENpdGUgQVBNIGJ5IHJldmlzaW9uIGFu ZCBzZWN0aW9uIHRpdGxlLgo+IC0tLQo+IMKgeGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3Zt LmMgfCA5ICsrKysrKysrLQo+IMKgMSBmaWxlIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgMSBk ZWxldGlvbigtKQo+Cj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2 bS5jIGIveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMKPiBpbmRleCBmYWFjZmUwMDc4 MzIuLjNhMGFmYTk4MTI5ZSAxMDA2NDQKPiAtLS0gYS94ZW4vYXJjaC94ODYvaHZtL3N2bS9uZXN0 ZWRzdm0uYwo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2bS5jCj4gQEAgLTEw MjcsMTIgKzEwMjcsMTkgQEAgbnN2bV92bWNiX3ByZXBhcmU0dm1leGl0KHN0cnVjdCB2Y3B1ICp2 LCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykKPiDCoMKgwqDCoCAvKgo+IMKgwqDCoMKgwqAg KiBWaXJ0dWFsIEludGVycnVwdHMuwqAgI1ZNRVhJVCB3cml0ZXMgYmFjayBWX1RQUiBhbmQgVl9J UlEgKEFQTSB2b2wuMgo+IMKgwqDCoMKgwqAgKiAxNS42KTsgdGhlIHJlbWFpbmluZyBmaWVsZHMg ZG8gbm90IGNoYW5nZS7CoCBDb3B5IHZHSUYgYmFjayBvbmx5IGlmCj4gLcKgwqDCoMKgICogZW5h YmxlZCBpbiBMMS4KPiArwqDCoMKgwqAgKiBlbmFibGVkIGluIEwxLsKgIFdpdGggdk5NSSBlbmFi bGVkLCB0aGUgcHJvY2Vzc29yIG1hbmFnZXMgVl9OTUkgYW5kCj4gK8KgwqDCoMKgICogVl9OTUlf TUFTSyBpdHNlbGYgYW5kIHdyaXRlcyBib3RoIGJhY2sgb24gI1ZNRVhJVCAoQVBNIHZvbC4yIHJl diAzLjQ0LAo+ICvCoMKgwqDCoCAqICJOTUkgVmlydHVhbGl6YXRpb24iKS4KPiDCoMKgwqDCoMKg ICovCj4gwqDCoMKgwqAgbnNfdm1jYi0+X3ZpbnRyLmZpZWxkcy50cHIgPSBuMnZtY2ItPl92aW50 ci5maWVsZHMudHByOwo+IMKgwqDCoMKgIG5zX3ZtY2ItPl92aW50ci5maWVsZHMuaXJxID0gbjJ2 bWNiLT5fdmludHIuZmllbGRzLmlycTsKPiDCoMKgwqDCoCBpZiAoIG5zX3ZtY2ItPl92aW50ci5m aWVsZHMudmdpZl9lbmFibGUgKQo+IMKgwqDCoMKgwqDCoMKgwqAgbnNfdm1jYi0+X3ZpbnRyLmZp ZWxkcy52Z2lmID0gbjJ2bWNiLT5fdmludHIuZmllbGRzLnZnaWY7Cj4gK8KgwqDCoCBpZiAoIG5z X3ZtY2ItPl92aW50ci5maWVsZHMudm5taV9lbmFibGUgKQo+ICvCoMKgwqAgewo+ICvCoMKgwqDC oMKgwqDCoCBuc192bWNiLT5fdmludHIuZmllbGRzLnZubWlfcGVuZGluZyA9IG4ydm1jYi0+X3Zp bnRyLmZpZWxkcy52bm1pX3BlbmRpbmc7Cj4gK8KgwqDCoMKgwqDCoMKgIG5zX3ZtY2ItPl92aW50 ci5maWVsZHMudm5taV9ibG9ja2luZyA9IG4ydm1jYi0+X3ZpbnRyLmZpZWxkcy52bm1pX2Jsb2Nr aW5nOwo+ICvCoMKgwqAgfQo+IMKgCj4gwqDCoMKgwqAgLyogSW50ZXJydXB0IHN0YXRlICovCj4g wqDCoMKgwqAgbnNfdm1jYi0+aW50X3N0YXQgPSBuMnZtY2ItPmludF9zdGF0Owo+IC0tCj4gMi4z NC4xCgpUaGUgaXNzdWUgaGVyZSBpcyB0aGF0IFhlbiBhbGxvd3MgTDEgdG8gZW5hYmxlIFZOTUkg aW4gdGhlIGZpcnN0IHBsYWNlCndoaWxlIGl0IGhhc24ndCBleHBvc2VkIHRoZSBmZWF0dXJlIHRv IEwxLiAgVGhpcyBpcyBiZWNhdXNlIFhlbiBibGluZGx5CmNvcGllcyB0aGUgZW50aXJlIHZpbnRy IGZpZWxkIChleGNlcHQgVl9JTlRSX01BU0tJTkcpIGZyb20gVk1DQigxLTIpLAp3aGljaCBpbmNp ZGVudGFsbHkgYWxzbyBhbGxvd3MgdGhlIGd1ZXN0IHRvIGVuYWJsZSBBVklDIGFuZCB1bmV4cGVj dGVkbHkKZ2V0IEFWSUMtcmVsYXRlZCBWTUVYSVRzIGFzIHJlcG9ydGVkIGhlcmU6Cmh0dHBzOi8v bG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9DQSthQ1MtSGE0alNZRmZ4aE93TUdpR0pQZENPdGdC Skx0PTNRPXY5ZGZwNlNRSnlzNHdAbWFpbC5nbWFpbC5jb20vVC8jdQoKRmlyc3QsIHdlIG5lZWQg dG8gZml4IHRoYXQgYnVnIGJ5IGNvcHlpbmcgb25seSB0aGUgcmVsZXZhbnQgc3VwcG9ydGVkCnBh cnRzIG9mIHZpbnRyIGZyb20gVk1DQigxLTIpLgoKVGhlbiwgYXMgYSBzZXBhcmF0ZSBzZXJpZXMs IGV4cG9zZSB0aGUgVk5NSSBmZWF0dXJlIGJpdCB0byB0aGUgVk0gKGlmCnN1cHBvcnRlZCBieSBo YXJkd2FyZSkgYW5kIG1ha2UgaXQgd29yayBjb3JyZWN0bHkuCgpSb3Nz From xen-devel-bounces@lists.xenproject.org Thu Oct 29 18:16:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 18:16:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465064.1675924 (Exim 4.92) (envelope-from ) id 1xMUfm-00010w-Fz; Thu, 29 Oct 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 1465064.1675924; Thu, 29 Oct 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 1xMUfm-00010p-Cr; Thu, 29 Oct 2026 18:16:22 +0000 Received: by outflank-mailman (input) for mailman id 1465064; Thu, 29 Oct 2026 18:16:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMUfl-00010j-7L for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 18:16:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMUfk-00FEGc-Kb for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 19:16:20 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae38d57-8faa-0a2a0a5109dd-0a2a4503e5d6-38 for ; Thu, 29 Oct 2026 19:16:20 +0100 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 6ae38d72-fae8-0a2a45030019-aceafc1f9c80-3 for ; Thu, 29 Oct 2026 19:16:20 +0100 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 35D53429FB; Thu, 29 Oct 2026 18:16:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E2D61F01824; Thu, 29 Oct 2026 18:16: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=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:To:Cc:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793297778; bh=/4gAgQ/v/3Bqijm1D2LCxgkMVVLMB4tDzBQLcSYjwMI=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=Ikpslf4YPUkOg5LrHDzFgpYpKlX9FjGI+vmKTVrkbTykNdR7VwZu7cuqgx8Yyyf5u VxZ2apLVqTOJZmkvDA6luWYsH7hWhs45Ws60v8fHW8UN+rdMJn/VBdRw0kDXaw3Jc2 qd1jSc34CrKjp7nDXowZxk3Vp5ciTuDwiLLOQYUPlbiChTCMtKCqVtOkxwHT6ZuaqQ IGOfQ2Tl1TYNJfzIm56KyHVSrp4E5A/OL9DqlVLuHSQe9r8Al3F4EioOnW4avwZm61 CtL3L3vpbIMk0jI66u/nTOSXxcL/J+3W9yuuoa5JIKprYgm+2NMd4uw61yfTnI8rNf z683LYB2t5TLA== Subject: Re: [PATCH] xen-netback: wait for RCU readers before freeing queues on error From: netdev-bot+sashiko@kernel.org To: yhlee@isslab.korea.ac.kr Cc: wei.liu@kernel.org, paul@xen.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, xen-devel@lists.xenproject.org, netdev@vger.kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 29 Oct 2026 18:16:16 +0000 Message-ID: <179329777698.3134.1942941250754899235@kernel.org> In-Reply-To: <20261027121438.1266207-1-yhlee@isslab.korea.ac.kr> References: <20261027121438.1266207-1-yhlee@isslab.korea.ac.kr> X-sashiko-severity: High Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-purgate-ID: tlsNG-33051d/1793297780-772F54E9-12FC1EAD/0/0 X-purgate-type: clean X-purgate-size: 4611 Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider. Critical: 0 · High: 1 · Medium: 0 · Low: 1 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [High] The fix leaves the use-after-free open when the very first queue fails, which is every failure for a single-queue frontend. - [Low] The commit message names xenvif_get_stats64() as one of the RCU readers, but xen-netback has no such function. -- xen-netback: wait for RCU readers before freeing queues on error This patch changes the connect() error path in xen-netback. It now publishes num_queues = 0 and calls synchronize_net() before it deinits and frees vif->queues, which is what backend_disconnect() already does. The goal is to stop RCU stats readers from dereferencing the freed vmalloc array. > The net device is registered in xenvif_alloc() during probe, so it is > already live when connect() runs. xenvif_get_stats64() and > xenvif_get_ethtool_stats() read it through the usual stats paths, taking [Severity: Low] This isn't a bug, but xen-netback has no xenvif_get_stats64(). The driver only implements the legacy callback: drivers/net/xen-netback/interface.c: .ndo_get_stats = xenvif_get_stats, The KASAN trace also shows that function (xenvif_get_stats+0x28f). Should the commit message say xenvif_get_stats() instead? > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c > index e020f44ac2c71..d1c9e38cfb8ef 100644 > --- a/drivers/net/xen-netback/xenbus.c > +++ b/drivers/net/xen-netback/xenbus.c > @@ -835,10 +835,21 @@ static void connect(struct backend_info *be) > return; > > err: > - if (be->vif->num_queues > 0) > + if (be->vif->num_queues > 0) { > + unsigned int num_queues = be->vif->num_queues; > + > xenvif_disconnect_data(be->vif); /* Clean up existing queues */ > - for (queue_index = 0; queue_index < be->vif->num_queues; ++queue_index) > - xenvif_deinit_queue(&be->vif->queues[queue_index]); > + > + /* > + * Mirror backend_disconnect(): publish num_queues == 0 and > + * synchronize_net() so RCU stats readers finish before the free. > + */ > + be->vif->num_queues = 0; > + synchronize_net(); > + > + for (queue_index = 0; queue_index < num_queues; ++queue_index) > + xenvif_deinit_queue(&be->vif->queues[queue_index]); > + } > vfree(be->vif->queues); [Severity: High] Is the use-after-free still open when the very first queue fails? Earlier in connect(), num_queues is published before any queue is set up: be->vif->num_queues = requested_num_queues; be->vif->stalled_queues = requested_num_queues; If xenvif_init_queue() or connect_data_rings() then fails for queue_index 0, the failure branch resets the count. For example, when connect_data_rings() fails: xenvif_deinit_queue(queue); be->vif->num_queues = queue_index; goto err; This sets num_queues to 0, so the new if (be->vif->num_queues > 0) block is skipped. synchronize_net() never runs, and vfree(be->vif->queues) happens with no grace period. A reader that sampled a non-zero num_queues during the connect_data_rings() window could still be inside rcu_read_lock(): xenvif_get_stats() { rcu_read_lock(); num_queues = READ_ONCE(vif->num_queues); for (index = 0; index < num_queues; ++index) { queue = &vif->queues[index]; ... } xenvif_get_ethtool_stats() follows the same pattern. multi-queue-num-queues defaults to 1, and with one queue every failure happens at queue_index 0. So for a default single-queue frontend, a guest that supplies a bad ring reference or event channel would still reach this vfree() without a grace period. The new comment says this mirrors backend_disconnect(). However, backend_disconnect() calls synchronize_net() before vfree(vif->queues) whatever the queue count is. The commit message says connect() jumps to err: "with num_queues still counting the queues already set up". That doesn't hold in the queue 0 case. Should the grace period run whenever vif->queues was allocated and num_queues was published, and not only when num_queues > 0 at the err label? [ ... ] -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261027121438.1266207-1-yhlee%40isslab.korea.ac.kr From xen-devel-bounces@lists.xenproject.org Thu Oct 29 18:30:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 18:30:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465082.1675934 (Exim 4.92) (envelope-from ) id 1xMUsw-0003UD-JV; Thu, 29 Oct 2026 18:29:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465082.1675934; Thu, 29 Oct 2026 18:29: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 1xMUsw-0003U6-G5; Thu, 29 Oct 2026 18:29:58 +0000 Received: by outflank-mailman (input) for mailman id 1465082; Thu, 29 Oct 2026 18:29:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMUsu-0003U0-Ps for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 18:29:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMUsu-006bOP-6f for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 19:29:56 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3908c-2eae-0a2a0a5409dd-0a2a4505ed24-14 for ; Thu, 29 Oct 2026 19:29:56 +0100 Received: from [52.101.43.5] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae390a2-4cb1-0a2a45050019-34652b05f592-4 for ; Thu, 29 Oct 2026 19:29:55 +0100 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS6PR03MB837260.namprd03.prod.outlook.com (2603:10b6:8:49a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 18:29:52 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.21.0569.008; Thu, 29 Oct 2026 18:29: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=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=prnPv8hRVLF9JPeBC85IdX0YS7HkaXIm2SE+OtoCee9hFlWu7vGNS82crGxlqnf9fg+8WEqF1Oi/YaoZvr+HZdHvNIXiJ3MfhwKPFkhDDNvIk8y8C2T6p0QhgNRoexq/H07DnESP1QhwnHt3rFNxWGIO0w01dAUP05zf6XeedUueILx6MU2t2VQaXFkFZhJm/+np3nn2ov4xMyjKSAf8fpqL87ZczmNLbf5TIS0DJXeVMiXm+fKEkeemPlzSMG45c3q3GAFU8O4AOGirgJoET8YIjDCpkyyuJAfuWd1avLpIikjJmQ2Nh8qQlmkSzaVVc2gYxd6eCauUsXy6Cppacg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7vfOx4QhKfc8Cb9UMh0pyP2ntXG/QTnm00P5DSImr/U=; b=WZegI+vzmRqY/HYr5X+lWFSdnz14ESzrFR8MB+gmBCLn7PLuYddpkPiIwZu7LTwSn5dYWeK92GpZkVe7+KbqzNb5GU85CrESuakMuxx6FviyGAcGP68GMrl2ahSwuX9lFl3vGbQoaGgZd+iFf9fJ2v3ltj0yLDvmhwV0mc75A3FGsN9torci4OQX736HqZRreywNO4VstB4+5rQZmB0lLLm47eZkcmP5f2Upx2M9rMyug+2XaBN55iOsV0uATcut1yoUcXZ/Z7D5zBsk8PSaEJWKSklR1g1INwWkVqaQ0yWeYX91dukUBMRJQzQxZwZI1pNHc+pc91wcpnuQ/u2QPA== 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=7vfOx4QhKfc8Cb9UMh0pyP2ntXG/QTnm00P5DSImr/U=; b=InvKD340XOAitM62omXlHXnWkVGZIcVC5L9d4ew8vEl/sM4nOpna42+KMkdOj/fRYTVvQ5JuFMfTE2/0yIdW72nBdivZ0yOpN6NImDIx1dTLpfvDVfg5kKfpbWC15BVrj7pC9X+DjQAkp/Cu5tk4/HfCyiXAV54z4n0Z/1qc62Y= 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, 29 Oct 2026 18:29:48 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , "jason.andryuk@amd.com" , "jbeulich@suse.com" , "roger@xenproject.org" , "teddy.astie@vates.tech" Subject: Re: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT To: Ross Lagerwall , =?UTF-8?B?Q2h1bmppZSBaaHUg77yI5pyx5pil5p2w77yJ?= , "xen-devel@lists.xenproject.org" References: <20261016070611.255322-1-chunjie.zhu@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: LO4P265CA0226.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:315::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_|DS6PR03MB837260:EE_ X-MS-Office365-Filtering-Correlation-Id: 90472245-16b1-441c-a882-08df35ea9f3c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|6133799003|22082099003|18002099003|56012099006|4143699003|11063799006|5023799004|261022075727099003|261026121527099003|261021123027099003|261022105027099003|10067099003|261026140227099003|261009223027099003|261028144727099003|261021121427099003; X-Microsoft-Antispam-Message-Info: pnVI8sEOsOhuOszWqUC+/r3IzXXQ8vRSCrl1hG21h12mCWR/ELttxDMaW0XRcUJQtory8asfhXKhINFHTNSCQIyZOk9TOQCbTAzeDnl9b3OIjBsImUK23SFYv8URxzYX6TwlbJuiGJq9amfdrhNGIQ/xxJMpuBg6Ml4Pdk+vPKveAtgZBs9GSe7QyOkoOQIZMoBvlX7n/fyfwZQARN01lhbz7dbFUQLEEKsBlcTu0RpQsBB1gI+7YVZkBXrd+IOWuiLQPiP937xbwP7pLsKNg2SYcXKijm8YX069uLFrprAgi8tZKiFuk5rZRK5kKb9VIWxpKKIVP2invAy21DSrP0zdn4w07UbvYYqnxos4lOHlwjwPXq1WWkUbto/9AOg1kpK/xWoa103iRszzUyY9gkh1Vt9hCGCronzpwCsJRAWnoZd5ipQPAr3Y+710fzC1unJ/Lu5ajLZvaZenXuAgqai+0wHNBsmzYzrMd5UD4GET/rWXtaEfRu/NdAiG1C4CATiigGXue2LHOw3zuuyD5Pj21CYpoXbDXUKKuVAJnsBC2D3Pzu+Won+y/0q0uBYkK68pNQku4lDDJir5U1gpMwtAjb2lfwRwv04IB60uMAmncsexCzISzxm4zcY+sZBA 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)(23010399003)(376014)(6133799003)(22082099003)(18002099003)(56012099006)(4143699003)(11063799006)(5023799004)(261022075727099003)(261026121527099003)(261021123027099003)(261022105027099003)(10067099003)(261026140227099003)(261009223027099003)(261028144727099003)(261021121427099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NmZiYURDeU9pSmMzQWs3a3dlU1J2VGQ1dWxha0ptNVMyZlluZTNWanFHdDZ2?= =?utf-8?B?cmsrSmFGcit0N1FFWjhxb1hBY21uajdUVnl1VVNobEhCMXNxNElYNEo1dTdq?= =?utf-8?B?Yy9rZ3l1ekNyZjhRTG5rbFBLanFSTUk2ZmxwRHZNeXRtTk5pQkRiRzZZQnUw?= =?utf-8?B?VXhjdjA2bzdsaE8vWnBSOWVRYUwxbEdoSGN5bjYrWTdZTDB3c2hyUVpLaG44?= =?utf-8?B?bENBZmpZNnlxb3B0ci9Eb01vbXpFcmo0c3hjam4zVG5FZ2hqNmNXci9BWWd6?= =?utf-8?B?cjA3NjlReVpwQ2c0U2ZtVzU4RW9XSG5oQVFVSXdOeDZxdUNvZVJ1aGZLTSs2?= =?utf-8?B?ZW9FT1ptaGdyM21BOENsYUp1dldDVXNsbFlVcFVDSlpENGRPNTRmZlR0NUs3?= =?utf-8?B?dyt6OVdWajM0WmxsdVV4dnRVVGJLU1Y2ZER4R2d0Mkk5UjlrTFdYTmRNVlpp?= =?utf-8?B?ZTE2aS9xd3BGN3VQQ0VCZ2I4Z3FQcitCbmt1SitqQzF6cW1ZR2I4NlUzMkVR?= =?utf-8?B?MHphbUtjREdFblcwckJaNUVFeUlMdmE1VElaR08vakRwa2Rka3FQMndtdnJl?= =?utf-8?B?cDdoZ012SWhZdVBUUFVXd0V5SHV5V1ZWRittcHlyYU1CODNoRDd5L1lqcitP?= =?utf-8?B?d09zL3hxUlBaZ2RmbkVnWkNoblZ6Nk1ETERvZDAyTVNYbTRBeXFtN3FONENZ?= =?utf-8?B?RVpJZTJSR01pU3RUVlJWZ2hjLzM0YSt1bzZYdnBWcVBvYiswRkxtRWVmZGtj?= =?utf-8?B?TXMxOWVrc0ZYa3NUMHAyWjR3RENxeWJudEM2b1k0ejI0TTd3WnZoUGRqTGIz?= =?utf-8?B?RUs1Y0p6RHk3N2VTeHBQZTBoRjFpTVlwQTV5dVpFb1BnWmtTYTZlbmx0a0xJ?= =?utf-8?B?T2tTMGx6bEtjQzRlR0UxbkZtbld3TSsvOTQwZjFyNHhIRkNuVlJjczQxVjJO?= =?utf-8?B?SXNEVi9xejQ1QkZKZjJ2WmFXQ0lLcjRnOS9jYWlJeDl0ZTRLZ3pwK3lqeDFI?= =?utf-8?B?YUlYa2NEbUlNOFNJQ2xsUnp6SVZnclliQWkyb0pNbjBDdHYwai9TYTA0STNZ?= =?utf-8?B?MVg1M25ma1FmV3RXc0doTnJJenJzOWNJaVloOXpxZG93S0pxQmREN3RaQjE3?= =?utf-8?B?SWxYclRQTThvemp2N1BBRVo5R010TUp2V3F6ZHNlckxyQ0JTZHE2QkVocnpj?= =?utf-8?B?cktocitmN2xhMUF1djl1cHIrM1UwdG05UUpCRHhxcHJOU2xVZXY3dzBaYmYx?= =?utf-8?B?dTRGODJYb05mNWZqaWFGYnEwa0JieFBiU0lIRUU5aHNzMzdObjlzV09lTWpx?= =?utf-8?B?MTlDNXVsakFHS1BTbHNjRlVzNlY4VFZiRm1KZHdaR1dhS3Q2dHhrUVd0NGNW?= =?utf-8?B?VmkxRTIxZDQyRmpJNGdMWExJaE1UZUJGa3R4VlUrQTNGMEsrWlBBNGltZjY5?= =?utf-8?B?aVlsNGQ4cFNVVlEwOUxVSUQzM1g4K1lpbXZLaEJjZWVDU0dBUkF4Skt4MWpS?= =?utf-8?B?ODNGVHR0RGhyVXNWcHVRWTBEOXhJd1BNd241UG9BYVNNNmZFMnBnOUpRSll4?= =?utf-8?B?Nld5QUo5T29heS9xeDlWTWRIL2IxeExxUXhxcTNOdk92Vit2eW5taWllczNH?= =?utf-8?B?dVF3US9iMEMwMk1YYnlvYk1zdTV5dXNsREw5Q01QWlVTQkxPN0NlaWRzL2wr?= =?utf-8?B?QUtBa3BQZ0RsbTZTTm4xNzR4UDNNMXRnbTBUZlo3eEJWRlRpeTVhUytQeWdp?= =?utf-8?B?b2ZrTzNSTElxMndkUlpYUUlNNElNY0E4K0YzanAxRzVBcmVsazVMT3p3RmZL?= =?utf-8?B?ZGxZTFFvYnBWd21LMWV0RjJ1RW1RR0RkdURoM05idUR3MG5uL3gxbURQR2VE?= =?utf-8?B?OW14SXdwMlBMYmJ5MEVCRzlMTzlxSWtKbFVqMklFbVdhNXJraVVqZURBdURF?= =?utf-8?B?Ym5WUVBZWlBibjA2Tno5eTc4L0x0WTlBVGRLTGs0ZG14WkJEcjRjY2IxSEJU?= =?utf-8?B?TjV5cFhwL08wZXgreDArSm9JR0NzSURDOFkzbmNkOFJMTElSalc2SDJ3TzQ3?= =?utf-8?B?UTRmNFh2VFFDbGlpSnkxTURwN3hZS1NveHdncHlZYk15WTRtL2p4czluMENw?= =?utf-8?B?azZINUtsZmE2YzduSTkzZXZGZGJacnFSeXpkYUg4TTFWT2NEQ2N0RjFZbm1h?= =?utf-8?B?VU9UTDVQSllXUzBaNklCOUxJYyt0QWV5QTZLWFdLc1BPNjNWWklZSmNqeHlH?= =?utf-8?B?RUk2VTBmaDArTmtTOVltU0ZIT252MGF5SXFQcTcrZUthYWkrNEd6RURKTE1K?= =?utf-8?B?RGhWOEozVEpidVU3Tjl3VTJmMlFHRG5vb3pxR2VkNk44RS9NS0padz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90472245-16b1-441c-a882-08df35ea9f3c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 18:29:52.1022 (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: MYVTZ7GFjcCb9TPbWBLDaa3F+f6S7OPcHoceRPC6vBIEoPyxTPkGcy1jBuGjhH6CZ6W3fsBuSdXiurpfjUkr0aPOm5B92F28vR+ESjKQ82I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS6PR03MB837260 X-purgate-ID: tlsNG-c201ff/1793298596-724B42A1-C4F1483F/10/78276251493 X-purgate-type: spam X-purgate-size: 3960 On 29/10/2026 5:54 pm, Ross Lagerwall wrote: >> From: Xen-devel on behalf of chunjie.zhu@citrix.com >> Sent: Friday, October 16, 2026 08:06 >> To: Andrew Cooper ; xen-devel@lists.xenproject.org >> Cc: Chunjie Zhu （朱春杰） ; jason.andryuk@amd.com ; jbeulich@suse.com ; roger@xenproject.org ; teddy.astie@vates.tech >> Subject: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT >> >> >> From: Chunjie Zhu >> >> When V_NMI_ENABLE is set, the processor manages V_NMI and V_NMI_MASK >> automatically (including on IRET), and writes both back to the VMCB on >> VMEXIT (APM vol.2 rev 3.44, "NMI Virtualization"). >> >> nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally) >> V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never >> copied back, so L1 kept seeing whatever it had last written, regardless of >> what happened in L2. >> >> Copy both back when L1 has enabled vNMI for its guest. >> >> Fixes: 86a203ab8d38 ("x86/svm: Support vNMI on capable hardware") >> Signed-off-by: Chunjie Zhu >> --- >> v2: >>  * Reword commit message: the processor manages V_NMI/V_NMI_MASK itself. >>  * Add Fixes: tag. >>  * Cite APM by revision and section title. >> --- >>  xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++++++- >>  1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >> index faacfe007832..3a0afa98129e 100644 >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >> @@ -1027,12 +1027,19 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>      /* >>       * 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. >> +     * enabled in L1.  With vNMI enabled, the processor manages V_NMI and >> +     * V_NMI_MASK itself and writes both back on #VMEXIT (APM vol.2 rev 3.44, >> +     * "NMI Virtualization"). >>       */ >>      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; >> +    if ( ns_vmcb->_vintr.fields.vnmi_enable ) >> +    { >> +        ns_vmcb->_vintr.fields.vnmi_pending = n2vmcb->_vintr.fields.vnmi_pending; >> +        ns_vmcb->_vintr.fields.vnmi_blocking = n2vmcb->_vintr.fields.vnmi_blocking; >> +    } >>   >>      /* Interrupt state */ >>      ns_vmcb->int_stat = n2vmcb->int_stat; >> -- >> 2.34.1 > The issue here is that Xen allows L1 to enable VNMI in the first place > while it hasn't exposed the feature to L1. This is because Xen blindly > copies the entire vintr field (except V_INTR_MASKING) from VMCB(1-2), > which incidentally also allows the guest to enable AVIC and unexpectedly > get AVIC-related VMEXITs as reported here: > https://lore.kernel.org/xen-devel/CA+aCS-Ha4jSYFfxhOwMGiGJPdCOtgBJLt=3Q=v9dfp6SQJys4w@mail.gmail.com/T/#u > > First, we need to fix that bug by copying only the relevant supported > parts of vintr from VMCB(1-2). > > Then, as a separate series, expose the VNMI feature bit to the VM (if > supported by hardware) and make it work correctly. This comes back to policy work. Luckily for AMD it's easy, because the information is in CPUID.  There's a series of mine from a while back doing this which needs committing. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Oct 29 18:56:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 18:56:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465098.1675941 (Exim 4.92) (envelope-from ) id 1xMVHz-0008Uu-GR; Thu, 29 Oct 2026 18:55:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465098.1675941; Thu, 29 Oct 2026 18:55: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 1xMVHz-0008Un-DR; Thu, 29 Oct 2026 18:55:51 +0000 Received: by outflank-mailman (input) for mailman id 1465098; Thu, 29 Oct 2026 18:55:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMVHx-0008Uh-Tz for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 18:55:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMVHx-000cnP-1z for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 19:55:49 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae396a7-2eae-0a2a0a5409dd-0a2a4501e4f4-12 for ; Thu, 29 Oct 2026 19:55:49 +0100 Received: from [52.101.69.89] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae396b4-5984-0a2a45010019-34654559e2ef-3 for ; Thu, 29 Oct 2026 19:55:48 +0100 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by PAWPR03MB8963.eurprd03.prod.outlook.com (2603:10a6:102:334::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Thu, 29 Oct 2026 18:55:39 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%4]) with mapi id 15.21.0569.008; Thu, 29 Oct 2026 18:55: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=oYLHpZDM9JrAFQN1/0SVnTkPZusBx4MMj38KmPOnAGM/xRnXtKCjEpIjHnEMbMKcFthXkl8u7Gl9kamckCZhrXfJ6tg3R7cP34w4iSq/AarFAd3BBLiphEmNULkUlJWwV/X6haPqxWH27ZvxrNWc8tEzNvVV6yo3S2qOccHGzyzEUrnvnbYbzajtsIwJgGLr3ApMvBiM9GarIlmHR/umL99tS63v1HHWeSr/I37pmbmhfTcl8ZjfJHSR9+1bZIKwZXtJJwcy9AIjaUyflmUdIB5xk32xVZIzk0pr4csc0V1PvaowK30LJTo7ZvLXj05EGDzcLXlw9C8YJv6NF6pYEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/N/Ql1dR4yBiWc5SYZTcLgM69r2WmvDp5LFQm1e9P1Q=; b=YJIv9p15cgQLvxSxVzwFzDUeolQVHCCiaitNGSL0DkdgYmY3ATtWnaYfjHYG4m93PfWiaO7igETHERL7yzziSvAtnhvkFBwzQfEKJcTIEku4a6sHUfQSLyB7hzmAw1+JiqXKiH/f3FjEfwLPoCqOFGXRpV04jIS969vgWOoSGD4+LnlG0wLJe083JwvGaH60YGTYYiRbncB256vDec5vlj3K7drDBQwLuyrDZ9Hxb6bejTUe9MbmnD4W8YB22teaoW7BZxwS6Yr/jFfGymzpghSxnIhgP/AhwluAHd/DIAfjiMTv7SMX8sS+uxOsGb5nFW8ftgc6uYCRWdb4h+I8aw== 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=/N/Ql1dR4yBiWc5SYZTcLgM69r2WmvDp5LFQm1e9P1Q=; b=K8v/DYKIiuRX4S3YGBv5J89lMpJojT2cPnFu58x257GPOJevy3gIXfb3wI7NNyYqlUkR3x90Li6o22pb/iTQzd/EvS3rzQPz2YZgsgZ/ww1PvplBD51RHISBxWz1gV0gnuI1sEsWHJgczjWF6dao/bCU7k/aWJqW2oBC6BsIOWpARIHAe6Iyn7O0OadFTcig87uyCUskDpTg89FLGeh9xuLVPV+oioyEK9LihcJVm0PEM8ZNzXRk/jVfdP96Z7U4t5d2kKocc/st0kXcXe2ZFbnatfucDkPlpw1Ff5aKRAN6a6WYBpzy7YJVXqjeFAv8pczTJRRwaIrLrEl+4tObAg== 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 v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v14 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdYG8UqIf/0AA9cU2/foNeomddPw== Date: Thu, 29 Oct 2026 18:55:38 +0000 Message-ID: <87v76knxp3.fsf@epam.com> References: <87mrs5tc1g.fsf@epam.com> <8d8985e3-fd09-4664-abaa-c3c0f4ca33d6@epam.com> In-Reply-To: <8d8985e3-fd09-4664-abaa-c3c0f4ca33d6@epam.com> (Oleksii Moisieiev's message of "Mon, 26 Oct 2026 15:39:40 +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_|PAWPR03MB8963:EE_ x-ms-office365-filtering-correlation-id: fe2d3735-7801-4a34-db17-08df35ee38f5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|23010399003|1800799024|366016|42112799006|38070700021|260925022911599003|260925021911599003|260925021311599003|4143699003|11063799006|56012099006|261009223027099003|261026135527099003|261026121527099003|261026140227099003|261026130827099003|261028144727099003|261022115727099003|261022113327099003|261022105027099003|261022075727099003|261021135927099003|261021133027099003|261021130227099003|261021123027099003|261021121427099003|10067099003|18002099003|22082099003|6133799003|4133799003|3023799007; x-microsoft-antispam-message-info: jpF6tE6KPwFAsbdmujetn432HN3rrW+/f3mP7P1A49TD01RnJ0OK5sMReAZBpMU58UB/QoL5DWE3t9OXHHbXQSscAGPyhxzuQZNChHVNli6/JhD/sm8gCJ1J535pkVD6elj4v0pkuGv/VmKibyiqg/hhlzc1+GpBzXobKQ+7XrCIz52MeFN8/uAIZ1S9rGMDqg4TlHRaq64enCuKsSZ/WVQYqQItHFJHBQ9bwlhMEJ1rb2a0KDIDOKLlovgCTvPWzrxV4cDXW/N8PnBiEpJncLl1qwTIM3hzA2JCqnSEUHcKviQJjTbb4eLW604ALEthSnJ4Fl3EvxiV0xMlLR/eAPXZrC+/m6W2r/eZC7eqlR9b0/N/lfmIvj/vITv2fj4MIr83Lh5qRgDEocr/zbotmQJvv/qQLY8NkUDdM6sBuHPw4m8uSiAKpGpapW2P+7rytVujA4L/DL+CeyNBcotnbCe+tPeRvTXznj7anyd34/c5fLLiwFJipVc0porrIO4kN7etsMSB2yPewxEdYdlXRRGcfJEXt5+NX+x/86yihQJXy42Ngxbbxwnliawcr6o4lxFfiLSf1W+658m9KKQHYdRB7X44j3MaUEuMixjmcOLhuJ5Zw5v3n7HOXc90cFc7YVRgwYF/BJduUD65t0m25o1SXB0zW91bOShmxEQ77KPWOCP7ECaMAFVqciIGjEhs6E3g7mrFKxLGt7on17gyq08LLDVB3+wLHvpHJ+BloYw= 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)(1800799024)(366016)(42112799006)(38070700021)(260925022911599003)(260925021911599003)(260925021311599003)(4143699003)(11063799006)(56012099006)(261009223027099003)(261026135527099003)(261026121527099003)(261026140227099003)(261026130827099003)(261028144727099003)(261022115727099003)(261022113327099003)(261022105027099003)(261022075727099003)(261021135927099003)(261021133027099003)(261021130227099003)(261021123027099003)(261021121427099003)(10067099003)(18002099003)(22082099003)(6133799003)(4133799003)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VEg3NU9wZ2pvM1dXaHdFK3lkTXY5cUpKRWVBM0NGbkFycVpYc25HTDUzWU5Z?= =?utf-8?B?MG00RmQ4U0pubk1WZmMxSDZkT1U0Z3ZzK3dFaHdWcWgxem1ORkcxUTUrUnd1?= =?utf-8?B?MmMrWHBaTkZYQTB0bXNhV0F3amViYWdHMmdSNlN5WjJWU0k3dEhEcFlCL09x?= =?utf-8?B?SktsZzkyUzROQ2NQN0c5UVpDQW8zR01zVmVxNEtSTTZSUUwydHRYeG5KekJX?= =?utf-8?B?eDR3TFRBYjI0OGVwa0ZIQm55WDJjVlo5SlEvdHFXQWN2dktGWUFyblNhOWJL?= =?utf-8?B?NWlrSTNDNk1UNHBkemJMM1Z4eUFVVVBJMWV4alNsWTFjeEFhaGVTQ2tJNTdq?= =?utf-8?B?VUs5Y0VFRldscUR0NmVxNVFGOHlnQTd2RVBSeXpzYkhacEZESkFhcDUxSEx5?= =?utf-8?B?N0ZZODlNSGVoYlFJVk9BSkhTdUZpTm95U09HSUR6M2l2WlEvbTQydTFmOVJT?= =?utf-8?B?dUtxOTBadnVrRmZyMDhXUXlpVG5NUlhQNHFIT2JxamRFWGhyMW5tNktyZXRt?= =?utf-8?B?dS9MbklPZHNOeFcxLzl2aFZ3V1I4NjJUVzdxOHhDanpUUVBRTm5GVSt5YTJv?= =?utf-8?B?Mm8xa20vbTFVY2h5T2dMNW5WSWQ3bHBmWExKZ3RWTHdzMmF1MW4wOVA0YzNB?= =?utf-8?B?ckhVcFF6aGtYdGFXK09QSTA0MnJibnl2eHNaNXo5dnNHQmJhWVdnZkU2dmlT?= =?utf-8?B?RE5ZK3BLdFFHa3JXM1RGUG5icG90YkdFcWlMeFU2Ri8vMXJGVk45S2c5bEtJ?= =?utf-8?B?SG1hK1gwY3AwM3ZiSGE0U3BPZW94dTUwYURvS1U3RFdEUmFFY1RPSnRPTDY5?= =?utf-8?B?dHRvMG1FTFpVbTlPbldWY3RjZVl5WjlzdFhSc2xsRlU2Z3dUOG9uYUtGMFFa?= =?utf-8?B?amtURVdKdWdIR0hKcWd2M3BmdWpzQ2xld3hFRzZXZXpqTlh4ckdxaHl1ZEkr?= =?utf-8?B?aEVRb2dKMHk3dVlZUHN4dXpFVGhhSEVTcWFPRWRvMzBEQzNIODdmbXk5VVJs?= =?utf-8?B?dDk3NDBiNGtLSWQ3bk5FVEp4K1RncjlncDB1UXBySmhPRkZFanJzTlM2M29X?= =?utf-8?B?SGx4VUYzM0drNXVtZWowNHpoU2U3bFpFR0VPWi8vUFgxTnBpczNVRTV0NWh1?= =?utf-8?B?MGpHVGNjUXB4WFZGaVhPNys4TnJXUm44S1ZkWVBHWFVUR0VMUnY5V1g1dnlL?= =?utf-8?B?cTMzV3QvSFBMOXpWRXdEVzRuSHo0eENhUk1DR3NGWG1DaWh4bzhEdzIzdUdG?= =?utf-8?B?eUJQTVNMb0FBVUwwZUJHRGllcVlKa1VDa09lUE5CZFVhbzV0VUdQWUlFUzFt?= =?utf-8?B?YlJoM09raHQ1STlWMklaL1d5Q05lczNEQ1NOdEpvM2RoaHZla3hrVnFGc2xI?= =?utf-8?B?SW5UT2k3VXhwM0VmMkg4alR6RXdFa3JWSmJjM05pVkdJUDBZbzNKN0QxMkw3?= =?utf-8?B?Lzk0N0JVSlRzalVHRWcxbGptdm1EMnRNM1VsQitmQkJ3akFQcFhIUG1TTnhl?= =?utf-8?B?bm5iL05Sa0JsRndxTnlremF2QTM1czE4dG5xankzT2hWNldaUmtwQitGWGZn?= =?utf-8?B?OHJyb1hETklsQktZNW5Da2pubUVtbkpOQlBpMXRMTHp1QWdoY3dnQmhnblBD?= =?utf-8?B?YzZ4dzU1RGVTbFl0OGgyZFcyaCtIdEpjS3ZSKzVNWHUrK3JOMGVtaE53Wmli?= =?utf-8?B?ZkFDMTdUZC9JMmpoMjVBZnh6ejkyNG9lUmVTNXlOMG43NG1tekpwMGR5WHBQ?= =?utf-8?B?dUFYcE1FdmZscDlsM0gwM05lRll4YnBobm42Q05yOUZwUStudHZZbVEzd0FS?= =?utf-8?B?aEZLeE1JS0JSbjdIRzZqOTZTQThHQjNWeHMyTDVQTDlDcG01QjhKSnBjV2d3?= =?utf-8?B?eU8rOUJwdkNVeHJsdksyVGZ5NitVY3ErZ3NDVW0xM0wzZGFrOWVINW1GOVNu?= =?utf-8?B?TDJ1UU5XQkRxcE53YzZwRWdhZEhodVQzQ2lOaFlpV2lQWFh1c3RzaTlDTjNP?= =?utf-8?B?K0xYWFZiSUhzUjh5TysxS0xxQ3RqaXBndTBVZlM3SzZrVjJlNzd5cXZiaUMr?= =?utf-8?B?bnd1cmorcTcranhoQWk3czVZSXRPcnpSbU42Z09UKzhybkRXcDcwUUtzWVNj?= =?utf-8?B?ZjA1dnlFL0U1MzFrYVRzSjZIbW55SWZlMk1ncTJVS0RsWkNGQTV3QUxsR3FE?= =?utf-8?B?UStwZ1lranNwRFJzaVRXaEY2TlhPYjhFVngyZnVLS0xBOXVlMFVrK25LQXJK?= =?utf-8?B?L1lLU3lhRFYxSmtvaGZtU2NVY1d4K1ZUNXZxSlB1UnB6c1UrekUrOTZoQ01q?= =?utf-8?B?Rm5FL1NRU0F0ODY5bVVxNk1jZjI1MUY1M0VPMXZpeEpEZzYxQzU0ckhlNjdP?= =?utf-8?Q?93/mT6CuDiXBrpHo=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <82076FEDB59D7949A53466ABB8416555@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: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe2d3735-7801-4a34-db17-08df35ee38f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2026 18:55:38.3524 (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: vuoBUnWPzobvAEKXT924zjeM20rF3hUhoyLhgzoSO+BEOBDnTEFpIkdQlypdZuX/ii2FEjikd7ne13kuDpEhIu6dohzubaQLurkQX62Dduo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB8963 X-purgate-ID: tlsNG-d62444/1793300148-BCF47757-6D648E1D/0/0 X-purgate-type: clean X-purgate-size: 13958 SGkgT2xla3NpaSwNCg0KT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0u Y29tPiB3cml0ZXM6DQoNCj4gSGkgVm9sb2R5bXlyLA0KPg0KPiBUaGFuayB5b3UgZm9yIHRoZSBy ZXZpZXcuIEkgYWdyZWUgd2l0aCB0aGUgbW9zdCBvZiB5b3VyIGNvbW1lbnRzLCBqdXN0DQo+IGZl dyBtb3JlIHF1ZXN0aW9ucyBsZWZ0Og0KPg0KPiBPbiAyMy8xMC8yMDI2IDA0OjU2LCBWb2xvZHlt eXIgQmFiY2h1ayB3cm90ZToNCj4+IEhpIE9sZWtzaWksDQo+Pg0KPj4gT2xla3NpaSBNb2lzaWVp ZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0uY29tPiB3cml0ZXM6DQo+Pg0KPj4+IFRoaXMgcGF0 Y2ggaW50cm9kdWNlcyBTQ0kgZHJpdmVyIHRvIHN1cHBvcnQgZm9yIEFSTSBFTDMgVHJ1c3RlZCBG aXJtd2FyZS1BDQo+Pj4gKFRGLUEpIHdoaWNoIHByb3ZpZGVzIFNDTUkgaW50ZXJmYWNlIHdpdGgg bXVsdGktYWdlbnQgc3VwcG9ydCwgYXMgc2hvd24NCj4gW3NuaXBdDQo+Pj4gZGlmZiAtLWdpdCBh L3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgYi94ZW4vYXJjaC9hcm0vZmlybXdh cmUvc2NtaS1zaG1lbS5jDQo+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+PiBpbmRleCAwMDAw MDAwMDAwLi5lMzY3NDVhODVlDQo+Pj4gLS0tIC9kZXYvbnVsbA0KPj4+ICsrKyBiL3hlbi9hcmNo L2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+PiBAQCAtMCwwICsxLDExOCBAQA0KPj4+ICsv KiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+Pj4gKy8qDQo+Pj4g KyAqIFNNQy9IVkMgc2htZW0gdHJhbnNwb3J0IGltcGxlbWVudGF0aW9uIHVzZWQgYnkNCj4+PiAr ICogU0NJIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVyLg0KPj4+ICsgKg0KPj4+ICsgKiBPbGVrc2lp IE1vaXNpZWlldiA8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+Pj4gKyAqIENvcHlyaWdo dCAoYykgMjAyNSBFUEFNIFN5c3RlbXMNCj4+PiArICovDQo+Pj4gKw0KPj4+ICsjaW5jbHVkZSA8 eGVuL2Vyci5oPg0KPj4+ICsjaW5jbHVkZSA8eGVuL2lvLmg+DQo+Pj4gKyNpbmNsdWRlIDxhc20v aW8uaD4NCj4+PiArDQo+Pj4gKyNpbmNsdWRlICJzY21pLXByb3RvLmgiDQo+Pj4gKyNpbmNsdWRl ICJzY21pLXNobWVtLmgiDQo+Pj4gKw0KPj4+ICtzdGF0aWMgaW5saW5lIGludA0KPj4+ICtzaG1l bV9jaGFubmVsX3N0YXR1cyhjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9f aW9tZW0gKnNobWVtKQ0KPj4+ICt7DQo+Pj4gKyAgICByZXR1cm4gKHJlYWRsKCZzaG1lbS0+Y2hh bm5lbF9zdGF0dXMpICYNCj4+PiArICAgICAgICAgICAgU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hB Tk5FTF9GUkVFKSA/IDAgOiAtRUJVU1k7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK2ludCBzaG1lbV9w dXRfbWVzc2FnZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVt LA0KPj4+ICsgICAgICAgICAgICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9p ZCAqZGF0YSwgdW5zaWduZWQgaW50IGxlbikNCj4+PiArew0KPj4+ICsgICAgaW50IHJldDsNCj4+ PiArDQo+Pj4gKyAgICBpZiAoIChsZW4gKyBvZmZzZXRvZihzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVt LCBtc2dfcGF5bG9hZCkpID4NCj4+PiArICAgICAgICAgU0NNSV9TSE1FTV9NQVBQRURfU0laRSAp DQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IFdyb25n IHNpemUgb2Ygc21jIG1lc3NhZ2UuIERhdGEgaXMgaW52YWxpZFxuIik7DQo+PiAib2YgdGhlIFNN QyBtZXNzYWdlIi4gQWxzbywgbG9va3MgbGlrZSBpdCBpcyBvdmVyIDgwIGNoYXJhY3RlcnMuDQo+ IGFncmVlZCB3aXRoIGJvdGguIHRoYW5rIHlvdS4NCj4+PiArICAgICAgICByZXR1cm4gLUVJTlZB TDsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICByZXQgPSBzaG1lbV9jaGFubmVsX3N0YXR1 cyhzaG1lbSk7DQo+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4gKyAgICAgICAgcmV0dXJuIHJldDsN Cj4+PiArDQo+Pj4gKyAgICB3cml0ZWxfcmVsYXhlZCgweDAsICZzaG1lbS0+Y2hhbm5lbF9zdGF0 dXMpOw0KPj4+ICsgICAgLyogV3JpdGluZyAweDAgcmlnaHQgbm93LCBidXQgInNobWVtIl9GTEFH X0lOVFJfRU5BQkxFRCBjYW4gYmUgc2V0ICovDQo+Pj4gKyAgICB3cml0ZWxfcmVsYXhlZCgweDAs ICZzaG1lbS0+ZmxhZ3MpOw0KPj4+ICsgICAgd3JpdGVsX3JlbGF4ZWQoc2l6ZW9mKHNobWVtLT5t c2dfaGVhZGVyKSArIGxlbiwgJnNobWVtLT5sZW5ndGgpOw0KPj4+ICsgICAgd3JpdGVsKHBhY2tf c2NtaV9oZWFkZXIoaGRyKSwgJnNobWVtLT5tc2dfaGVhZGVyKTsNCj4+IFdoeSBkbyB5b3UgbWl4 IHdyaXRlbCgpIGFuZCB3cml0ZWxfcmVsYXhlZCgpIGhlcmU/DQo+DQo+IFRoZSBtYWluIGlkZWEg dGhhdCBJJ20gZmlsbGluZyB1cCBTQ01JIGhlYWRlciBpbmZvcm1hdGlvbiBmb2xsb3dpbmcNCj4g RGV2aWNlIG1lbW9yeSBvcmRlcmluZyBhbmQgZXhlY3V0ZSBfX2lvd21iIGJlZm9yZSBzdG9yZSBp biB0aGUgbGFzdA0KPiB3cml0ZWwgY2FsbC4NCg0KWWVzLCBidXQgZGlmZmVyZW5jZSBiZXR3ZWVu IHdyaXRlbF9yZWxheGVkKCkgYW5kIHdyaXRlbCgpIGlzIHRoYXQNCndyaXRlbCgpIGhhcyBtZW1v cnkgYmFycmllciBmb3IgTm9ybWFsIE1lbW9yeSBhY2Nlc3Nlcy4gV3JpdGVzIHRvIERldmljZQ0K TWVtb3J5IGFyZSBndWFyYW50ZWVkIHRvIGFycml2ZSBpbiB0aGUgcHJvcGVyIG9yZGVyLg0KDQo+ DQo+DQo+Pj4gKw0KPj4+ICsgICAgaWYgKCBsZW4gPiAwICYmIGRhdGEgKQ0KPj4+ICsgICAgICAg IG1lbWNweV90b2lvKHNobWVtLT5tc2dfcGF5bG9hZCwgZGF0YSwgbGVuKTsNCj4+PiArDQo+Pj4g KyAgICByZXR1cm4gMDsNCj4+PiArfQ0KPj4+ICsNCj4+PiAraW50IHNobWVtX2dldF9yZXNwb25z ZShjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtLA0K Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQg KmRhdGEsIHVuc2lnbmVkIGludCBsZW4pDQo+Pj4gK3sNCj4+PiArICAgIGludCByZWN2X2xlbjsN Cj4+PiArICAgIGludCByZXQ7DQo+Pj4gKyAgICAvKg0KPj4+ICsgICAgICogRmlyc3Qgd29yZCBv ZiBtc2dfcGF5bG9hZCBjYXJyaWVzIHRoZSByZXR1cm5lZCBzdGF0dXM7IGV4Y2x1ZGUgaXQgZnJv bQ0KPj4+ICsgICAgICogcmVjdl9sZW4gc28gb25seSB0aGUgcHJvdG9jb2wgcGF5bG9hZCBpcyBj b3BpZWQgYmFjayB0byB0aGUgY2FsbGVyLg0KPj4+ICsgICAgICovDQo+Pj4gKyAgICBpbnQgcGFk ID0gc2l6ZW9mKGhkci0+c3RhdHVzKTsNCj4+PiArDQo+Pj4gKyAgICBpZiAoIGxlbiA+PSBTQ01J X1NITUVNX01BUFBFRF9TSVpFIC0NCj4+PiArICAgICAgICAgb2Zmc2V0b2Yoc3RydWN0IHNjbWlf c2hhcmVkX21lbSwgbXNnX3BheWxvYWQpICkNCj4+PiArICAgIHsNCj4+PiArICAgICAgICBwcmlu dGsoWEVOTE9HX0VSUg0KPj4+ICsgICAgICAgICAgICAgICAic2NtaTogV3Jvbmcgc2l6ZSBvZiBp bnB1dCBzbWMgbWVzc2FnZS4gRGF0YSBtYXkgYmUgaW52YWxpZFxuIik7DQo+PiAib2YgdGhlIGlu cHV0IFNNQyBtZXNzYWdlIg0KPiArMQ0KPj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+ ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIHJldCA9IHNobWVtX2NoYW5uZWxfc3RhdHVzKHNobWVt KTsNCj4+PiArICAgIGlmICggcmV0ICkNCj4+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4+ICsN Cj4+PiArICAgIHJlY3ZfbGVuID0gcmVhZGwoJnNobWVtLT5sZW5ndGgpIC0gc2l6ZW9mKHNobWVt LT5tc2dfaGVhZGVyKTsNCj4+PiArDQo+Pj4gKyAgICBpZiAoIHJlY3ZfbGVuIDwgMCApDQo+Pj4g KyAgICB7DQo+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+PiArICAgICAgICAgICAg ICAgInNjbWk6IFdyb25nIHNpemUgb2Ygc21jIG1lc3NhZ2UuIERhdGEgbWF5IGJlIGludmFsaWRc biIpOw0KPj4gIm9mIHRoZSBTTUMgbWVzc2FnZSINCj4+DQo+PiBBbHNvLCBJIGFtIHdvbmRlcmlu ZyBpZiB5b3UgcmVhbGx5IG5lZWQgdG8gcHJpbnQgdGhpcyBlcnJvciBtZXNzYWdlcyBpbg0KPj4g dGhlIGZpcnN0IHBsYWNlLg0KPj4NCj4gVGhlc2UgZ2VuZXJpYyBtZXNzYWdlcyB3ZXJlIHZlcnkg aGVscGZ1bCBpbiBkZXRlcm1pbmluZyB0aGUgZXhhY3QgZXJyb3IuDQo+IEZvciBleGFtcGxlLCB0 aGlzIGZ1bmN0aW9uIHJldHVybnMgLUVJTlZBTCBib3RoIGlmDQo+DQo+ICAgbGVuID49IFNDTUlf U0hNRU1fTUFQUEVEX1NJWkUgLSAgb2Zmc2V0b2Yoc3RydWN0IHNjbWlfc2hhcmVkX21lbSwgbXNn X3BheWxvYWQpICBhbmQgaWYgcmVjdl9sZW4gPCAwDQo+DQo+IEhvd2V2ZXIsIGlmIHlvdSB0aGlu ayB0aGV5IGFyZSBleGNlc3NpdmUsIEkgY2FuIHJlbW92ZSB0aGUgcHJpbnRzIGFuZCByZXR1cm4g ZGlmZmVyZW50IGVycm9yIGNvZGVzIGluc3RlYWQuDQoNCldlbGwsIEkgaGF2ZSBubyBzdHJvbmcg b3BpbmlvbiBoZXJlLiBTbyB5b3UgY2FuIGxlYXZlIHRoZW0gaWYgeW91DQp3aXNoLiBKdXN0IG1h a2Ugc3VyZSB0aGF0IHRoZXkgaGF2ZSBwcm9wZXIgc3BlbGxpbmcuDQoNCj4NCj4+PiArICAgICAg ICByZXR1cm4gLUVJTlZBTDsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICB1bnBhY2tfc2Nt aV9oZWFkZXIocmVhZGwoJnNobWVtLT5tc2dfaGVhZGVyKSwgaGRyKTsNCj4+PiArDQo+Pj4gKyAg ICBoZHItPnN0YXR1cyA9IHJlYWRsKCZzaG1lbS0+bXNnX3BheWxvYWQpOw0KPj4+ICsgICAgcmVj dl9sZW4gPSByZWN2X2xlbiA+IHBhZCA/IHJlY3ZfbGVuIC0gcGFkIDogMDsNCj4+PiArDQo+Pj4g KyAgICByZXQgPSBzY21pX3RvX3hlbl9lcnJubyhoZHItPnN0YXR1cyk7DQo+Pj4gKyAgICBpZiAo IHJldCApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2Nt aTogRXJyb3IgcmVjZWl2ZWQ6ICVkXG4iLCByZXQpOw0KPj4+ICsgICAgICAgIHJldHVybiByZXQ7 DQo+Pj4gKyAgICB9DQo+Pj4gKw0KPj4+ICsgICAgaWYgKCByZWN2X2xlbiA+IGxlbiApDQo+Pj4g KyAgICB7DQo+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+PiArICAgICAgICAgICAg ICAgInNjbWk6IE5vdCBlbm91Z2ggYnVmZmVyIGZvciBtZXNzYWdlICVkLCBleHBlY3RpbmcgJWRc biIsDQo+Pj4gKyAgICAgICAgICAgICAgIHJlY3ZfbGVuLCBsZW4pOw0KPj4+ICsgICAgICAgIHJl dHVybiAtRUlOVkFMOw0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIGlmICggcmVjdl9sZW4g PiAwICkNCj4+PiArICAgICAgICBtZW1jcHlfZnJvbWlvKGRhdGEsIHNobWVtLT5tc2dfcGF5bG9h ZCArIHBhZCwgcmVjdl9sZW4pOw0KPj4+ICsNCj4+PiArICAgIHJldHVybiAwOw0KPj4+ICt9DQo+ Pj4gKw0KPj4+ICsvKg0KPj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+Pj4gKyAqIG1vZGU6IEMN Cj4+PiArICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4+ICsgKiBjLWJhc2ljLW9mZnNldDogNA0K Pj4+ICsgKiB0YWItd2lkdGg6IDQNCj4+PiArICogaW5kZW50LXRhYnMtbW9kZTogbmlsDQo+Pj4g KyAqIEVuZDoNCj4+PiArICovDQo+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2Fy ZS9zY21pLXNobWVtLmggYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5oDQo+Pj4g bmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+PiBpbmRleCAwMDAwMDAwMDAwLi43MjIyNjNhYTc3DQo+ Pj4gLS0tIC9kZXYvbnVsbA0KPj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNo bWVtLmgNCj4+PiBAQCAtMCwwICsxLDQ1IEBADQo+Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlm aWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+PiArLyoNCj4+PiArICogQXJtIFN5c3RlbSBDb250cm9s IGFuZCBNYW5hZ2VtZW50IEludGVyZmFjZSBkZWZpbml0aW9ucw0KPj4+ICsgKiBWZXJzaW9uIDMu MCAoREVOMDA1NkMpDQo+Pj4gKyAqIFNoYXJlZCBNZW1vcnkgYmFzZWQgVHJhbnNwb3J0DQo+Pj4g KyAqDQo+Pj4gKyAqIENvcHlyaWdodCAoYykgMjAyNCBFUEFNIFN5c3RlbXMNCj4+PiArICovDQo+ Pj4gKw0KPj4+ICsjaWZuZGVmIEFSTV9GSVJNV0FSRV9TQ01JX1NITUVNX0hfDQo+Pj4gKyNkZWZp bmUgQVJNX0ZJUk1XQVJFX1NDTUlfU0hNRU1fSF8NCj4+PiArDQo+Pj4gKyNpbmNsdWRlIDx4ZW4v c3RkaW50Lmg+DQo+Pj4gKw0KPj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NIQU5O RUxfRlJFRSAgQklUKDAsIFVMKQ0KPj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NI QU5ORUxfRVJST1IgQklUKDEsIFVMKQ0KPj4+ICsNCj4+PiArc3RydWN0IHNjbWlfc2hhcmVkX21l bSB7DQo+Pj4gKyAgICB1aW50MzJfdCByZXNlcnZlZDsNCj4+PiArICAgIHVpbnQzMl90IGNoYW5u ZWxfc3RhdHVzOw0KPj4+ICsgICAgdWludDMyX3QgcmVzZXJ2ZWQxWzJdOw0KPj4+ICsgICAgdWlu dDMyX3QgZmxhZ3M7DQo+Pj4gKyAgICB1aW50MzJfdCBsZW5ndGg7DQo+Pj4gKyAgICB1aW50MzJf dCBtc2dfaGVhZGVyOw0KPj4+ICsgICAgdWludDhfdCBtc2dfcGF5bG9hZFtdOw0KPj4+ICt9Ow0K Pj4gU2hvdWxkIGl0IGJlIF9fcGFja2VkPw0KPiBUaGUgbGF5b3V0IGFscmVhZHkgbWF0Y2hlcyB0 aGUgc2hhcmVkLW1lbW9yeSBmb3JtYXQgd2l0aG91dCBwYWRkaW5nOg0KPiBFdmVyeSBmaXhlZCBt ZW1iZXIgaXMgYSB1aW50MzJfdCBvciBhbiBhcnJheSBvZiB1aW50OF90LCBhbmQgdGhlDQo+IG1h cHBpbmcgaXMgcGFnZSBhbGlnbmVkLg0KPg0KPiBUaGVyZWZvcmUgX19wYWNrZWQgd291bGQgbm90 IGNoYW5nZSB0aGVzZSBvZmZzZXRzLCBidXQgd291bGQgcmVkdWNlIHRoZQ0KPiBzdHJ1Y3R1cmUn cyBhbGlnbm1lbnQgZ3VhcmFudGVlLiBJIHdvdWxkIHByZWZlciB0byBrZWVwIHRoZSBuYXR1cmFs DQo+IGFsaWdubWVudCBhbmQgYWRkIGNvbXBpbGUtdGltZSBvZmZzZXQgY2hlY2tzIHRvIGRvY3Vt ZW50IHRoZSB0cmFuc3BvcnQNCj4gbGF5b3V0LiBEb2VzIHRoYXQgYWRkcmVzcyB5b3VyIGNvbmNl cm4/DQoNClllcy4NCg0KWy4uLl0NCg0KDQo+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9m aXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2Nt aS1zbWMtbXVsdGlhZ2VudC5jDQo+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+PiBpbmRleCAw MDAwMDAwMDAwLi42YzQ2ZjZjZDM2DQo+Pj4gLS0tIC9kZXYvbnVsbA0KPj4+ICsrKyBiL3hlbi9h cmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMNCj4+PiBAQCAtMCwwICsxLDc5 MiBAQA0KPj4+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+ Pj4gKy8qDQo+Pj4gKyAqIFNDSSBTQ01JIG11bHRpLWFnZW50IGRyaXZlciwgdXNpbmcgU01DL0hW QyBzaG1lbSBhcyB0cmFuc3BvcnQuDQo+Pj4gKyAqDQo+Pj4gKyAqIE9sZWtzaWkgTW9pc2llaWV2 IDxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+PiArICogQ29weXJpZ2h0IChjKSAyMDI1 IEVQQU0gU3lzdGVtcw0KPj4+ICsgKi8NCj4+PiArDQo+Pj4gKyNpbmNsdWRlIDx4ZW4vYWNwaS5o Pg0KPj4+ICsNCj4+PiArI2luY2x1ZGUgPHhlbi9kZXZpY2VfdHJlZS5oPg0KPj4+ICsjaW5jbHVk ZSA8eGVuL2luaXQuaD4NCj4+PiArI2luY2x1ZGUgPHhlbi9pb2NhcC5oPg0KPj4+ICsjaW5jbHVk ZSA8eGVuL2Vyci5oPg0KPj4+ICsjaW5jbHVkZSA8eGVuL2xpYmZkdC9saWJmZHQuaD4NCj4+PiAr I2luY2x1ZGUgPHhlbi9zdHJpbmcuaD4NCj4+PiArI2luY2x1ZGUgPHhlbi9wYXJhbS5oPg0KPj4+ ICsjaW5jbHVkZSA8eGVuL3NjaGVkLmg+DQo+Pj4gKyNpbmNsdWRlIDx4ZW4vdm1hcC5oPg0KPj4+ ICsNCj4+PiArI2luY2x1ZGUgPGFzbS9maXJtd2FyZS9zY2kuaD4NCj4+PiArI2luY2x1ZGUgPGFz bS9zbWNjYy5oPg0KPj4+ICsNCj4+PiArI2luY2x1ZGUgInNjbWktcHJvdG8uaCINCj4+PiArI2lu Y2x1ZGUgInNjbWktc2htZW0uaCINCj4+PiArDQo+Pj4gK3N0cnVjdCBzY21pX2NoYW5uZWwgew0K Pj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+PiBJZiBhbGwgYWdlbnRfaWRzIGxhcmdlIHRo YW4gVUlOVDhfTUFYIGFyZSBpbnZhbGlkLCB3aHkgZG8geW91IG5lZWQNCj4+IHVpbnQzMl90IGhl cmU/DQo+DQo+IEFjY29yZGluZyB0byB0aGUgREVOMDA1NkYgZG9jdW1lbnQ6DQo+DQo+IGh0dHBz Oi8vc3VwcG9ydC5hcm0uY29tL2RvY3VtZW50YXRpb24vZGVuMDA1Ni9mLz9sYW5nPWVuDQo+DQo+ IGFnZW50X2lkIGlzIHVpbnQzMl90ICBpbiBTQ01JIG1lc3NhZ2VzLg0KPg0KDQpPa2F5LCBzbyBh Z2VudF9pZCBpcyAzMi1iaXQgdmFsdWUuIEkgY2FuIGltYWdpbmUgYSBwbGF0Zm9ybSB0aGF0IGhh dmUNCmFnZW50IElEcyAweDEwMCwgMHgyMDAsIDB4MzAwIGFuZCBzbyBvbi4gSSBiZWxpZXZlLCBp biB0aGlzIGNhc2UgeW91cg0KY29kZSB3aWxsIG5vdCB3b3JrIGFzIGludGVuZGVkLCBiZWNhdXNl IHlvdSBsaW1pdCBhZ2VudCBpZCB0byA4IGJpdHMgaW4NCmRvbWFpbiBzdHJ1Y3R1cmUuDQoNCg0K Wy4uLl0NCg0KPj4+ICtzdGF0aWMgaW50IGNvbGxlY3RfYWdlbnRfaWQoc3RydWN0IHNjbWlfY2hh bm5lbCAqYWdlbnRfY2hhbm5lbCkNCj4+PiArew0KPj4+ICsgICAgaW50IHJldDsNCj4+PiArICAg IHNjbWlfbXNnX2hlYWRlcl90IGhkcjsNCj4+PiArICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX2Rp c2NvdmVyX2FnZW50X3AyYSBkYV9yeDsNCj4+PiArICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX2Rp c2NvdmVyX2FnZW50X2EycCBkYV90eDsNCj4+PiArDQo+Pj4gKyAgICByZXQgPSBtYXBfY2hhbm5l bF9tZW1vcnkoYWdlbnRfY2hhbm5lbCk7DQo+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4gKyAgICAg ICAgcmV0dXJuIHJldDsNCj4+PiArDQo+Pj4gKyAgICBoZHIuaWQgPSBTQ01JX0JBU0VfRElTQ09W RVJfQUdFTlQ7DQo+Pj4gKyAgICBoZHIudHlwZSA9IDA7DQo+Pj4gKyAgICBoZHIucHJvdG9jb2wg PSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+Pj4gKw0KPj4+ICsgICAgZGFfdHguYWdlbnRfaWQgPSBh Z2VudF9jaGFubmVsLT5hZ2VudF9pZDsNCj4+PiArDQo+Pj4gKyAgICByZXQgPSBkb19zbWNfeGZl cihhZ2VudF9jaGFubmVsLCAmaGRyLCAmZGFfdHgsIHNpemVvZihkYV90eCksICZkYV9yeCwNCj4+ PiArICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGRhX3J4KSk7DQo+Pj4gKyAgICBpZiAo IGFnZW50X2NoYW5uZWwtPmRvbWFpbl9pZCAhPSBET01JRF9YRU4gKQ0KPj4+ICsgICAgICAgIHVu bWFwX2NoYW5uZWxfbWVtb3J5KGFnZW50X2NoYW5uZWwpOw0KPj4+ICsgICAgaWYgKCByZXQgKQ0K Pj4gT24gZXJyb3IsIFhlbidzIGNoYW5uZWwgd2lsbCBiZSBtYXBwZWQgc3RpbGwuIElzIHRoaXMg aW50ZW5kZWQgYmVoYXZpb3VyPw0KPiBJdCByZW1haW5zIG1hcHBlZCB3aGVuIGNvbGxlY3RfYWdl bnRfaWQoKSByZXR1cm5zLCBidXQgdGhlIGV4aXN0aW5nDQo+IGNhbGxlciBjbGVhbnMgaXQgdXAu IHNjbWlfcHJvYmUoKSBtYXJrcyB0aGUgbWFuYWdlbWVudCBjaGFubmVsIERPTUlEX1hFTg0KPiBi ZWZvcmUgZGlzY292ZXJ5LiBJZiBkaXNjb3ZlcnkgZmFpbHMsIGl0IGp1bXBzIHRvIGVycm9yLCBj YWxscw0KPiB1bm1hcF9jaGFubmVsX21lbW9yeShjaGFubmVsKSwgdGhlbiBmcmVlX2NoYW5uZWxf bGlzdCgpLiBUaHVzIHRoZSBjdXJyZW50DQo+IHByb2JlIGZhaWx1cmUgcGF0aCBkb2VzIG5vdCBs ZWFrIHRoZSBtYXBwaW5nLg0KPg0KPg0KPiBPbiBzdWNjZXNzZnVsIGRpc2NvdmVyeSB0aGUgbWFu YWdlbWVudCBtYXBwaW5nIGlzIGRlbGliZXJhdGVseSByZXRhaW5lZA0KPiBmb3Igc3Vic2VxdWVu dCBwZXJtaXNzaW9uIGFuZCByZXNldCByZXF1ZXN0cy4gU2Vjb25kYXJ5IGRpc2NvdmVyeQ0KPiBt YXBwaW5ncyBhcmUgYWx3YXlzIHJlbW92ZWQgYnkgY29sbGVjdF9hZ2VudF9pZCgpLCB3aGV0aGVy IHRoZSB0cmFuc2Zlcg0KPiBzdWNjZWVkcyBvciBmYWlscy4NCg0KQWgsIG9rYXkuIFRoYW5rIHlv dSBmb3IgY2xhcmlmaWNhdGlvbi4NCg0KWy4uLl0NCg0KLS0NCldCUiwgVm9sb2R5bXlyDQo= From xen-devel-bounces@lists.xenproject.org Thu Oct 29 19:27:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 19:27:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465131.1675951 (Exim 4.92) (envelope-from ) id 1xMVmm-0006Kr-U8; Thu, 29 Oct 2026 19:27:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465131.1675951; Thu, 29 Oct 2026 19: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 1xMVmm-0006Kk-RE; Thu, 29 Oct 2026 19:27:40 +0000 Received: by outflank-mailman (input) for mailman id 1465131; Thu, 29 Oct 2026 19:27:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMVml-0006Ke-6f for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 19:27:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMVmk-00C5Qq-JZ for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 20:27:38 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae39e1e-2eae-0a2a0a5409dd-0a2a450bd60c-10 for ; Thu, 29 Oct 2026 20:27:38 +0100 Received: from [40.107.130.120] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae39e2a-b7e8-0a2a450b0019-286b8278d7eb-4 for ; Thu, 29 Oct 2026 20:27:38 +0100 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) by DUYPR03MB11922.eurprd03.prod.outlook.com (2603:10a6:10:65e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 19:27:36 +0000 Received: from AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5]) by AS2PR03MB9587.eurprd03.prod.outlook.com ([fe80::daa7:3b97:acb3:67d5%5]) with mapi id 15.21.0546.021; Thu, 29 Oct 2026 19:27: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=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=xkT3RwH3R0hHn0HEbPK4b9nURvBMkUbGaScMBJnaYuP7IgxelSTeJYp8eqic0bYJxcAQLzByJQm2Rfhs2gHI9MqyRpX3DRTpG0vFjn79oLdkQZoSVlczEG8ClYBODXkKiUX4ZwsXC9ggltFJhkYReFWVoGrAM5p74NvFY/ZrslY4ErNQve0iAHJ58yzjhl6jha1ltp1WKdNpMNO68vbuj6kGIwNFI68/+l9y2ycKhWhVJAzLh+GqVk5rTzOCDF5nh4B4YHVSymntLHuCF0khlEVwE22nNwZrZgzzbeZel2xLTIltwrOdxetLryeYXrdDwj3faSwtVikFbiZFuavHpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DMOOoi/2V/gj3TsEc/zqK5Uepp76ImBE5Ty5GnJqJBo=; b=B+rMQS7vy3VT8jaKERoOyf93Zfx7blXoefON1wEXH4hlHNOnkydPujVUKMAJz77xsWU9lPlzeTlgL/qgB8x11ecObJravBSIGgrEGf3UvH4NRQVdbW+eK94nDVx7YiGVuKy/KDvYopSbNXrmmJi5HQQsFofDLCZQXNBIi33f2ekh79ezPeVeieD2Gsdf7hQKZpq7W5ZzQ0RWqpNvphldRQz92UirplNc4dLk/e2QSnrlQBFdRJFTqTa3Eg0oAuoR6Fgln5Wy6JGyd6MeffisiH70fOahdfsYAqnxM0DHowEKtL9mx8sX90YL48zji5fEKpozM3ZduvFeKf4oiN647A== 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=DMOOoi/2V/gj3TsEc/zqK5Uepp76ImBE5Ty5GnJqJBo=; b=dfWFNBi46VS6d+UXBBiWw7HSf787xk8mrl36l33Z2DeGYyTFDih066Nf+kdBcpGd/oaFZb6FVlG6IPGy9uaQRohSnL4t9Qi2LoDmVfMJuVPu2FwgYd4XVhSvBPxZtfCVBlDKifK/6NVFfCmgB2fAObcGmINKYfsU1UJZyJr/L/p3xalvxdFolaIH5O7mmMZqrJ4NMy3FavdfUQwoY7+8BXi2bL3/46eKKRa3qH0F13GT89xEmSq6CDXV227Bxq6QFAEYwwtk54GuHflAj4cCpuR7k9xmX7ihincmvX2sS/Bkr1nH2yfvnzaymhy9VNgWsFynTimilvWGOGp7q0TsVA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Message-ID: <48e32e1b-67ad-47ed-8ca6-42854a572d52@epam.com> Date: Thu, 29 Oct 2026 20:27:34 +0100 User-Agent: Mozilla Thunderbird From: Milan Djokic Subject: Re: [PATCH v4 11/22] xen/arm: vsmmuv3: Attach Stage-1 configuration to SMMUv3 hardware To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" Cc: Rahul Singh , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4f83a0ee7f46e19c6afec3460a2a7e1bbe8e3c1a.1791328190.git.milan_djokic@epam.com> <84d8b1c8-f716-41bf-82f7-fdfdb6207c04@gmail.com> Content-Language: en-US In-Reply-To: <84d8b1c8-f716-41bf-82f7-fdfdb6207c04@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VIXP296CA0027.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:36e::7) To AS2PR03MB9587.eurprd03.prod.outlook.com (2603:10a6:20b:595::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS2PR03MB9587:EE_|DUYPR03MB11922:EE_ X-MS-Office365-Filtering-Correlation-Id: db983050-4dd7-430e-4c73-08df35f2b024 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|261028144727099003|4143699003|11063799006|261022105027099003|56012099006|261009223027099003|261021121427099003|261026140227099003|261026121527099003|10067099003|261022075727099003|22082099003|18002099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: nCaAWgw/aYkSwm8CS594SYcHcLF+uR89FDZQ7V/BLPR0L+VsI6LhMihM/2qYJJRrxaTveSJaQUhfUjJLljJvYghBFpgbpLNHLHk+UmrcTZwBjCBvfPoV7C7DahmRFiy01SKUE7RZz6LeYkAeIUzRITay989EW3PhdT4LbmurK5rJob3kzftsN7k+BZeEflufzjMN8+mJlyJy8067DSiVmpxL5eJX5oP9c9VAO54sax+DnLOeyfR4WxGnIBYioWbiQI2nTECi5ELX884qAMABVbU8Dk6yUF6O5hHg6UH87uCC+tqs3jpqFWkP8mozBZr8zx2nMWJZc0r7NdsJcLxeoh3M9oP0eDfFweu826d/HpDu2ezXwwxFcQevumR3YO0n4sy3NyL8hBaN9OuI/qC0NrdgBPQaU5NLKw8UFxVvaEA55KbHZ4bToaGBBdhuemr7NjJZnKz71Jdtke1rhhTPC/vdw7X8Ff5A5TgPJ51iFqwNGqXD9HDrkAeuDYdxc27FVcp7luYsFOHNnbGV44kFQmOP9q4rDzEFKXU+uEkw0T7cBsoYBzUCJaySFKKLgeLgXyMfLpUp2DXWOynZ7jFYlcrPlaOiBes+l/GLvQZnZkw9powfdC2gJhLUDDV0uylPWFZs7yZNd1CIICLMUcgQK8viJ7n7SCtoPZrYxyqntj4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB9587.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(261028144727099003)(4143699003)(11063799006)(261022105027099003)(56012099006)(261009223027099003)(261021121427099003)(261026140227099003)(261026121527099003)(10067099003)(261022075727099003)(22082099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UzBUeHdCYVo4WEdST1R3TkQrM2hHNlA3d201cVRNU09nMTZNanpleHlhNlNm?= =?utf-8?B?UjQ0Y1FaSkpiY3c4VG5NM1lKRWVaTGdvN0M1MUxpNk55SUQ0QUxUM2h6blZo?= =?utf-8?B?eUNGN3J1Mk9Zckp5Rk9IbWo2aGxOODY3ZHRZMDErUC9HUjRBZFl0WkVFVFRq?= =?utf-8?B?bVhubCsrZTVJd2FUOFJVQmQrNTc3Ym42Y0pHU2RBZzVNR25va3hCWGV1bXZs?= =?utf-8?B?MWVXQjkzR2FiTm1TcE0vS0FWS0lRSW9KazlWd2RtWVlPVFE3ZEJoZHg5TUxs?= =?utf-8?B?UWZ4TXJmc1h5SCt0TFlxVXpPRUFzTnBFUUlmOWthN3NJUGM5TlFXOGJDVHli?= =?utf-8?B?dTN0L0VETVhaaWFLT01weW1aWk9SM1JXQnpyTnBqQmxGSDh0TVo0RHRqdndu?= =?utf-8?B?TW9McTkzZEhxRVlMNWlwQnAraGtTTGIzaVZUNkpLK3hEV1RNNUJtUXpWUURZ?= =?utf-8?B?T2xadFVWYTl2ZFlUckFPTDJHcktOOFovZWE4M0hKeUdGK21MSDNybEcvbks4?= =?utf-8?B?dVVCeXJrWmg4cTJUNzRveS9QSHZFVko5ZFVieDR2OGhoR3ZRUGVVSTllZlVG?= =?utf-8?B?OGdYWkQwdDgxQ0sxZjdzdGdubVhkK0wwRWFRWmhUUHFreHYyTURna2ZjMlhp?= =?utf-8?B?azJEUW5PeU1XRGJGd3ZaaFBzUTJuRUNiUDBLMXNXNFRLWE1FTXpQTTlGVVJM?= =?utf-8?B?aWkxaC92TVhxOHNQeGZGUjBBYjFDdlNKRTVUdUdxVzE4MXJoRENyeStKSzUw?= =?utf-8?B?d0l5V25RSnd2MExNbjdGQkk5U2ovc29rZ0hULzc4dGptZ0JsRFhxRWxITHVh?= =?utf-8?B?RjRsTFFEaTluLzgwaWhvU29LYWtxZTg3emJxZjNHeElWcSt3UWkydm0rYTNS?= =?utf-8?B?WEdDUG16djJUUnB5Y2RFN2F1YjdFWnBYeFlKc24xajB5N2lxS213dEFMTDBU?= =?utf-8?B?SEFiQ000eEY4ckx0SllxMkVFclY0WktQcTM3S2RsN1FaS0EybjFIWWhJL04x?= =?utf-8?B?NDIwYndtWmtKSkhoMzNwazZlajA3bVNHSUNuWHVXRGlzWFlWVGRpeG8rN0h3?= =?utf-8?B?d0NzdWhSUU9Ua21wVlZDUHhLaGdPcnZKNzcvSUxqVkF4NVFacUFCcGFoRE5R?= =?utf-8?B?Q1Q2QWRjbk9NYUw5eS9Obm5nS0loMVhHNTBYa2p5YjRiZVhuQzVtZk9jbjhj?= =?utf-8?B?TTNtUmtvQVFla2k2ZXlkOFRGTld3MDFnZHlJdmpzdnppM3g0bFpSd1BsRkVG?= =?utf-8?B?YTB4TGk0SFF5djFTS0wvZUxCK3N6YmdJT3NBaGlxU29NWEFIM2ovcFFsaitq?= =?utf-8?B?VEROVnJScmJ3dWNEZE5IZjhmd1YwRmxNeUZna0pyVVJtZmM1N0MzM3M4OVRX?= =?utf-8?B?c3libWVsR3pPZnJSRmxMaVB6SGJ2bUl6NnB6eUVXcUttT0lWdVBubitMcm5k?= =?utf-8?B?VU1WY2FxaEIrL05SMndVNXY0SXJYTThUWjBER3E2QjdoZHEvbVp1VG1RN0k1?= =?utf-8?B?ZGVISFpHV0tsWnZzeUhHWjIxaWp1VW5tT2I1bU1FL1llT2dBRmZIeCsyUTZE?= =?utf-8?B?b1RLL3czdDZaVHl5SlZZazFLUnY0cWkxMkdyZXBvU2tVYk1CUE1kQWFDRHY5?= =?utf-8?B?bG9BZGRVWkIyMy9KcnFkRlJkeHkrY3d4bWNOR1lGdHFoVTNaREF3aWVvWDJy?= =?utf-8?B?d2piRUdtOXAyeWcyck83ekpZVzJZQVl0T0h4b21IRzBtTGhaYUYwUnVXOTk1?= =?utf-8?B?dEhkQS83UEZwOWlpSnFGWVozRzQwVzRxL3N2VVlSK1g1UU1tSWp4MXdsc0lj?= =?utf-8?B?RlRlT0FTY09yWVdqUHVsSkp1QkVPQ3o4Rkl0aGI5OHg5SjdiWVFTU0N3OHF1?= =?utf-8?B?VktudnFqYy94bXNTOThXMW5FVFgzbUxTMERKSXlMbHFETXhXNnVmZjdYK0FZ?= =?utf-8?B?MVhGcUppM2dwdFlaSzJUSVhyeStMVklKZmNWR2ZXRlNPK29CNUlhSStvUXNZ?= =?utf-8?B?QzdMY3NlTnlwYXJENXU5OTgxVWpnVWNXdXRWYkJDSEVTcTRiTFFIaVZyWG01?= =?utf-8?B?a3ZWaUU2STAyTnE2bnMrWnBmZUpkMkU5VktCNUJ4Sm8rOUdEdzkxS2JtamM2?= =?utf-8?B?bjNPOE9QZThucDg3clNNcW8xMWI5NzFBdG8xOUJhQVhIYnkxVnB0WTdCUVdh?= =?utf-8?B?U3NDRUtyNVEwV3NleVBsU2hmRkV1TTl4MTNMOFBSYWtISjVCZGpGM2daYkgx?= =?utf-8?B?VXhmQWtpSlZ5Uk1IWUExVEV6NzJHdHRGZ2k2R3lCVXdMTEhSMy8zd0lmY2xt?= =?utf-8?B?WStac29xelBRMmdMVVRnVFZ5K1lMR1cyRWp3VE5CUkx1VmJ1Q2tRUT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: db983050-4dd7-430e-4c73-08df35f2b024 X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB9587.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 19:27:36.6143 (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: ZFWUWFp5gjXiVwTcHRBYy98apsQ5OPXtC8qlW829YKdXqqreWdvihEVgcWj1NqM1ms3b4WEj5rw0e4Zk+UYzNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DUYPR03MB11922 X-purgate-ID: tlsNG-42698a/1793302058-A8ECE9EA-5A068D2D/0/0 X-purgate-type: clean X-purgate-size: 12805 Hi Oleksandr, On 10/10/26 16:47, Oleksandr Tyshchenko wrote: > > > On 10/7/26 03:07, Milan Djokic wrote: > > > Hello Milan > >> From: Rahul Singh >> >> Attach the Stage-1 configuration to device STE to support nested >> translation for the guests. > > My review of this is based on the full series being applied and includes > the surrounding code context. > >> >> Signed-off-by: Rahul Singh >> Signed-off-by: Milan Djokic >> --- >> xen/arch/arm/include/asm/iommu.h | 7 ++ >> xen/drivers/passthrough/arm/smmu-v3.c | 105 +++++++++++++++++++++++++ >> xen/drivers/passthrough/arm/smmu-v3.h | 1 + >> xen/drivers/passthrough/arm/vsmmu-v3.c | 18 +++++ >> xen/include/xen/iommu.h | 6 ++ >> 5 files changed, 137 insertions(+) >> >> diff --git a/xen/arch/arm/include/asm/iommu.h b/xen/arch/arm/include/asm/iommu.h >> index ad15477e24..56bc9314a7 100644 >> --- a/xen/arch/arm/include/asm/iommu.h >> +++ b/xen/arch/arm/include/asm/iommu.h >> @@ -20,6 +20,13 @@ struct arch_iommu >> void *priv; >> }; >> >> +struct iommu_guest_config { >> + paddr_t s1ctxptr; >> + uint8_t config; >> + uint8_t s1fmt; >> + uint8_t s1cdmax; >> +}; >> + >> const struct iommu_ops *iommu_get_ops(void); >> void iommu_set_ops(const struct iommu_ops *ops); >> >> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c >> index 9d2b8a708b..196ac660ef 100644 >> --- a/xen/drivers/passthrough/arm/smmu-v3.c >> +++ b/xen/drivers/passthrough/arm/smmu-v3.c >> @@ -3003,6 +3003,37 @@ static struct arm_smmu_device *arm_smmu_get_by_dev(const struct device *dev) >> return NULL; >> } >> >> +static struct iommu_domain *arm_smmu_get_domain_by_sid(struct domain *d, >> + u32 sid) >> +{ >> + int i; >> + unsigned long flags; >> + struct iommu_domain *io_domain; >> + struct arm_smmu_domain *smmu_domain; >> + struct arm_smmu_master *master; >> + struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv; >> + >> + /* >> + * Loop through the &xen_domain->contexts to locate a context >> + * associated with the target SMMU and device SID >> + */ >> + list_for_each_entry(io_domain, &xen_domain->contexts, list) { >> + smmu_domain = to_smmu_domain(io_domain); >> + >> + spin_lock_irqsave(&smmu_domain->devices_lock, flags); >> + list_for_each_entry(master, &smmu_domain->devices, domain_head) { >> + for (i = 0; i < master->num_streams; i++) { >> + if (sid != master->streams[i].id) >> + continue; >> + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); >> + return io_domain; >> + } >> + } >> + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); >> + } >> + return NULL; >> +} >> + >> static struct iommu_domain *arm_smmu_get_domain(struct domain *d, >> struct device *dev) >> { >> @@ -3216,6 +3247,79 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d) >> xfree(xen_domain); >> } >> >> +static int arm_smmu_attach_guest_config(struct domain *d, uint32_t sid, >> + const struct iommu_guest_config *cfg) >> +{ >> + int ret = -EINVAL; >> + unsigned long flags; >> + struct arm_smmu_master *master; >> + struct arm_smmu_domain *smmu_domain; >> + struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv; >> + struct iommu_domain *io_domain = arm_smmu_get_domain_by_sid(d, sid); >> + >> + if (!io_domain) >> + return -ENODEV; >> + >> + smmu_domain = to_smmu_domain(io_domain); > > > I might be wrong, but it feels to me that io_domain should be fetched > after acquiring the lock below since concurrent deassign can free the > io_domain. arm_smmu_deassign_dev() takes xen_domain->lock, decrements > io_domain->ref, and if it hits 0, calls arm_smmu_destroy_iommu_domain() > which frees the memory. > Yes, you're right. I'll update this. >> + >> + spin_lock(&xen_domain->lock); >> + >> + switch (cfg->config) { >> + case ARM_SMMU_DOMAIN_ABORT: >> + smmu_domain->abort = true; >> + smmu_domain->stage = cfg->config; >> + break; >> + case ARM_SMMU_DOMAIN_BYPASS: >> + smmu_domain->abort = false; >> + smmu_domain->stage = cfg->config; > > I am not quite sure where the best place is to leave this comment, but > unless I am missing something, it looks like a guest can trivially > disable stage-2 translation. > > If the guest requests CFG_BYPASS, arm_vsmmu_decode_ste() sets bypassed > and guest_cfg.config becomes ARM_SMMU_DOMAIN_BYPASS. > arm_smmu_attach_guest_config() then sets that stage. Consequently, > arm_smmu_write_strtab_ent() finds neither s1_cfg nor s2_cfg and writes > the physical STE as CFG_BYPASS, which bypasses both stages. > > So any device the guest puts in bypass (which Linux might legitimately > do for identity domains) can read and write any physical memory, > including Xen’s memory. Even for well-behaved guests, this is > problematic: the device would use IOVA (which equals IPA) directly as a > host physical address instead of going through the domain’s P2M. > > I think that guest bypass request should map to S2-only physical STE. > Thanks for catching this. You're right, a guest BYPASS request should bypass Stage-1 while retaining Stage-2 translation. I'll update the handling to reuse the existing Stage-2 configuration and install the physical STE as CFG_S2_TRANS. > >> + break; >> + case ARM_SMMU_DOMAIN_S1: >> + /* Check stage-1 support */ >> + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_TRANS_S1)) { >> + dev_info(smmu_domain->smmu->dev, >> + "stage-1 not implemented\n"); >> + goto out; >> + } >> + >> + /* If stage-2 is not supported, configure stage-1 only */ >> + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_TRANS_S2)) { >> + dev_warn(smmu_domain->smmu->dev, >> + "SMMU does not implement stage-2 translation support. " >> + "Fallback to stage-1-only translation configuration\n"); >> + /* Enable Stage-1 translation. */ >> + smmu_domain->stage = ARM_SMMU_DOMAIN_S1; > > As I already mentioned for commit #02/22, Without stage-2 there is no > layer to turn the stage-1 output's IPA into PA. Should we allow this > fallback only for privileged, direct-mapped domains? > > And apologies if this has already been discussed. > Yes, I'll update this to be handled during vIOMMU initialization for the domain. If vIOMMU is enabled for a non-direct-mapped domain when the physical IOMMU supports only stage-1, the configuration shall be rejected. > >> + } >> + else { >> + /* Check nested support */ >> + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_NESTING)) { >> + dev_info(smmu_domain->smmu->dev, >> + "Nested translation not supported\n"); >> + goto out; > > According to commit #07/22 "MMU-600 variant < 2 and all MMU-700" are > affected. But it seems that Xen still offers SMMU, a guest still sees > SMMU and might believe it is working. The attach fails with only a log > line (gdprintk in arm_vsmmu_handle_cmds()) and the guest is never told. > Device DMA then might land in the wrong guest memory. > > Please consider gating this at viommu_get_type() or at domain creation. > Agreed. I'll update the vIOMMU initialization to reject the configuration if the hardware supports both Stage-1 and Stage-2 translation but does not support nesting. The same approach should apply when Stage-1 translation is not supported by the hardware. > >> + } >> + smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED; >> + } >> + >> + /* Enable Stage-1 translation. */ >> + smmu_domain->s1_cfg.s1ctxptr = cfg->s1ctxptr; >> + smmu_domain->s1_cfg.s1fmt = cfg->s1fmt; >> + smmu_domain->s1_cfg.s1cdmax = cfg->s1cdmax; >> + smmu_domain->abort = false; > > Since all this stored per smmu_domain, one domain-wide S1 config > (bypass, abort, context pointer) is applied to all of device’s SIDs > (from the design doc I got this as intentional for current driver > implementation) ... > > >> + break; >> + default: >> + goto out; >> + } >> + >> + spin_lock_irqsave(&smmu_domain->devices_lock, flags); >> + list_for_each_entry(master, &smmu_domain->devices, domain_head) >> + arm_smmu_install_ste_for_dev(master); > > ... ^^^ loops over all masters and applies the identical config to all > of them. If, lets say, a device (PCI?) exposes several SIDs, and the > guest tries to program SID 0 with one mappings and SID 1 with a > different mappings, the second command will silently overwrite SID 0's > mappings. > > I do not want to ask for extra work, but should Xen at least report an > error when a guest programs different configs, rather than silently > overwriting the previous one? Or at least leave a TODO? > Yes, this is a limitation of the current implementation. The Stage-1 configuration is stored per smmu_domain and shared by all SIDs belonging to its masters. I'll add a TODO to make this limitation explicit. PCI Stage-1 support will be addressed in a follow-up to this series, which should be a suitable place to handle this limitation. > >> + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); >> + >> + ret = 0; >> +out: >> + spin_unlock(&xen_domain->lock); >> + return ret; >> +} >> + >> static const struct iommu_ops arm_smmu_iommu_ops = { >> .page_sizes = PAGE_SIZE_4K, >> .init = arm_smmu_iommu_xen_domain_init, >> @@ -3228,6 +3332,7 @@ static const struct iommu_ops arm_smmu_iommu_ops = { >> .unmap_page = arm_iommu_unmap_page, >> .dt_xlate = arm_smmu_dt_xlate, >> .add_device = arm_smmu_add_device, >> + .attach_guest_config = arm_smmu_attach_guest_config, >> }; >> >> static __init int arm_smmu_dt_init(struct dt_device_node *dev, >> diff --git a/xen/drivers/passthrough/arm/smmu-v3.h b/xen/drivers/passthrough/arm/smmu-v3.h >> index ef492098ae..4a912be740 100644 >> --- a/xen/drivers/passthrough/arm/smmu-v3.h >> +++ b/xen/drivers/passthrough/arm/smmu-v3.h >> @@ -402,6 +402,7 @@ enum arm_smmu_domain_stage { >> ARM_SMMU_DOMAIN_S2, >> ARM_SMMU_DOMAIN_NESTED, >> ARM_SMMU_DOMAIN_BYPASS, >> + ARM_SMMU_DOMAIN_ABORT, >> }; >> >> /* Xen specific code. */ >> diff --git a/xen/drivers/passthrough/arm/vsmmu-v3.c b/xen/drivers/passthrough/arm/vsmmu-v3.c >> index 25ba734fa7..3f557d1c4d 100644 >> --- a/xen/drivers/passthrough/arm/vsmmu-v3.c >> +++ b/xen/drivers/passthrough/arm/vsmmu-v3.c >> @@ -319,8 +319,11 @@ static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) >> { >> int ret; >> uint64_t ste[STRTAB_STE_DWORDS]; >> + struct domain *d = smmu->d; >> + struct domain_iommu *hd = dom_iommu(d); >> struct arm_vsmmu_s1_trans_cfg s1_cfg = {0}; >> uint32_t sid = smmu_cmd_get_sid(cmdptr[0]); >> + struct iommu_guest_config guest_cfg = {0}; >> >> ret = arm_vsmmu_find_ste(smmu, sid, ste); >> if ( ret ) >> @@ -330,6 +333,21 @@ static int arm_vsmmu_handle_cfgi_ste(struct virt_smmu *smmu, uint64_t *cmdptr) >> if ( ret ) >> return (ret == -EAGAIN ) ? 0 : ret; >> >> + guest_cfg.s1ctxptr = s1_cfg.s1ctxptr; >> + guest_cfg.s1fmt = s1_cfg.s1fmt; >> + guest_cfg.s1cdmax = s1_cfg.s1cdmax; >> + >> + if ( s1_cfg.bypassed ) >> + guest_cfg.config = ARM_SMMU_DOMAIN_BYPASS; >> + else if ( s1_cfg.aborted ) >> + guest_cfg.config = ARM_SMMU_DOMAIN_ABORT; >> + else >> + guest_cfg.config = ARM_SMMU_DOMAIN_S1; >> + >> + ret = hd->platform_ops->attach_guest_config(d, sid, &guest_cfg); >> + if ( ret ) >> + return ret; >> + >> return 0; >> } >> >> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h >> index 37c4a1dc82..253f8bb6cb 100644 >> --- a/xen/include/xen/iommu.h >> +++ b/xen/include/xen/iommu.h >> @@ -312,6 +312,7 @@ static inline int iommu_add_dt_pci_sideband_ids(struct pci_dev *pdev) >> #endif /* HAS_DEVICE_TREE_DISCOVERY */ >> >> struct page_info; >> +struct iommu_guest_config; >> >> /* >> * Any non-zero value returned from callbacks of this type will cause the >> @@ -387,6 +388,11 @@ struct iommu_ops { >> #endif >> /* Inhibit all interrupt generation, to be used at shutdown. */ >> void (*quiesce)(void); >> + >> +#ifdef CONFIG_ARM >> + int (*attach_guest_config)(struct domain *d, uint32_t sid, >> + const struct iommu_guest_config *cfg); >> +#endif >> }; >> >> /* > BR, Milan From xen-devel-bounces@lists.xenproject.org Thu Oct 29 21:41:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Oct 2026 21:41:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465201.1675959 (Exim 4.92) (envelope-from ) id 1xMXrv-0004eD-VL; Thu, 29 Oct 2026 21:41:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465201.1675959; Thu, 29 Oct 2026 21:41: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 1xMXrv-0004e6-SN; Thu, 29 Oct 2026 21:41:07 +0000 Received: by outflank-mailman (input) for mailman id 1465201; Thu, 29 Oct 2026 21:41:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMXrv-0004e0-0u for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 21:41:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMXru-000v9z-2M for xen-devel@lists.xenproject.org; Thu, 29 Oct 2026 22:41:06 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3bd45-8faa-0a2a0a5109dd-0a2a450ba822-38 for ; Thu, 29 Oct 2026 22:41:05 +0100 Received: from [13.59.128.245] (helo=basilisk.relay-egress.a.mail.umich.edu) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae3bd6b-b7e8-0a2a450b0019-0d3b80f5eb20-3 for ; Thu, 29 Oct 2026 22:41:00 +0100 Received: from legit-duende.authn-relay.a.mail.umich.edu (ip-10-0-73-185.us-east-2.compute.internal [10.0.73.185]) by basilisk.relay-egress.a.mail.umich.edu with ESMTPS id 6AE3BD6A.2EAEDFA5.4275F12B.2324919; Thu, 29 Oct 2026 17:40:58 -0400 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by legit-duende.authn-relay.a.mail.umich.edu with ESMTPSA id 6AE3BD6A.5195AEB.AEC3514.2168298; Thu, 29 Oct 2026 17:40:58 -0400 Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-3ac91f5aa89so1072511fa.1 for ; Thu, 29 Oct 2026 14:40: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=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=1793310058; bh=uQTbpa1DZnayBlhNnJGZRfLywJmbmCmUE/kbQmUKOb8=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=oAIzz67LoBPokYbN4ljsFC4ewgiQLb3rFZUhyApIVyooCAd0lo/zrNDn8dY63KK4O wQn1ptlwZpzrbiNFGt4T/t1P/VhZ2wC7IfqDlphvSp4XK7jk5/7YxeuFOx2iFUtlhX Mny6kxWwoA0aHoJ9GifJwYnaSND3Ti8f2gN+L2AJxgChZY7Wmw4lL8KNupaA/7BCT3 YiYePZ8YOWsIEE1lRz0HvL4ktZCe4cflk4xKXXRsfr6PXZuo7SNaF4JDeJ5LEEvHHT FaGmWXyFBQrhySYPHGSHNJRE3agzI2H0LaGgbDDMWPujfYYk0tu87WNzxzI+Gbp4IV cTduyUnv4AgBA== Authentication-Results: legit-duende.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.208.176 (mail-lj1-f176.google.com); auth=pass smtp.auth=dunlapg X-Gm-Message-State: AFq9FYLZw9n36yu/XDOmLwr02WI3CsnXcICQXow/O6EPiteSoNlI7sZ3 q7pkkGLeJCSG2hGKIcrMKoSCaThgXrn3tiGVEnKjgawpH2E/DimoqLD6fwGmul6GhPbT4VH1uAJ SSPHj8fhb2Uhnx+lcoIxrlKrb58X576Y= X-Received: by 2002:a05:651c:31c1:b0:3a9:a1ed:633e with SMTP id 38308e7fff4ca-3acb7b4f57fmr443401fa.25.1793310056279; Thu, 29 Oct 2026 14:40:56 -0700 (PDT) MIME-Version: 1.0 References: <8ad3beb3-af5a-477b-af97-614edb22631a@suse.com> <4fc90702-fb9a-4f96-88f0-35bd3b4857f4@suse.com> In-Reply-To: <4fc90702-fb9a-4f96-88f0-35bd3b4857f4@suse.com> From: George Dunlap Date: Thu, 29 Oct 2026 21:40:43 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9rEul4Vv81KCkK1g_iu0eKNDV3bss9k1k90Oh0tHeC5Qyreiom4cnLUdA Message-ID: Subject: Re: [PATCH v3 1/3] common: introduce "brk" allocator 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?= , Teddy Astie Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1793310065-1B2DC9EA-C9317A1D/10/78276251493 X-purgate-type: spam X-purgate-size: 5303 On Wed, Oct 14, 2026 at 2:02=E2=80=AFPM Jan Beulich wro= te: > > ... to replace (on x86) ebmalloc(), and then to find further use(s) to > allow recovering memory which is needed very early (and hence needs > setting up statically), but may not fully be used (or not be used at all)= . > > Note that unlike free_ebmalloc_unused_mem(), brk_free_unused() (once > other code is converted) will be able to free part of the BRK space even > in the xen.efi case on x86. That would happen if BRK space extends across > a 2Mb boundary, and actual use stops before that boundary. > > Signed-off-by: Jan Beulich > --- > Changing setup.c's reserve_e820_ram() uses would be cumbersome when done > right here. That'll be done when ebmalloc() is replaced, and hence > what's there can also simply be replaced. > > When linking xen.efi, GNU ld prior to 2.46 produces a base relocation for > the reference to __subsystem__, which is wrong (that's an absolute symbol= , > after all). That does no harm for our purposes, though. > --- > v3: Move to common code and introduce BSS_WITH_BRK. Rename > brk_get_unused_start() to brk_cease(). Add header guard to brk.h. In > brk_alloc() don't calculate result too early. Add printk_once_init(), > for use in brk_alloc(). Move introduction of DEFINE_BRK() here; add > comment. > > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -15,6 +15,7 @@ config X86 > select FUNCTION_ALIGNMENT_16B > select GENERIC_BUG_FRAME > select HAS_ALTERNATIVE > + select HAS_BRK_ALLOCATOR > select HAS_COMPAT > select HAS_CPUFREQ > select HAS_DIT > --- /dev/null > +++ b/xen/arch/x86/include/asm/brk.h > @@ -0,0 +1,23 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +#ifndef X86_BRK_H > +#define X86_BRK_H > + > +static inline unsigned long brk_adjust_start(unsigned long start) > +{ > + unsigned int subsys; > + > + /* > + * Only xen.efi will have the symbol __subsystem__ available, and it= 'll > + * be non-zero (10) there. In ELF the symbol will be undefined, and > + * hence zero will be loaded into the register. > + */ > + asm ( ".weak __subsystem__; mov $__subsystem__, %0" : "=3Dr" (subsys= ) ); > + > + /* using_2M_mapping() isn't available here. */ > + if ( IS_ENABLED(CONFIG_XEN_ALIGN_2M) || subsys ) > + start =3D PAGE_ALIGN_2M(start); This seems a bit fragile: As it happens this corresponds to the clip to brk_end in setup.c in patch 2, but if it didn't, then the boundary in the resulting e820 reservation and what gets unmapped in brk_free_unsed() wouldn't match. Claude seems to think you could make using_2M_mapping() available here; and then brk_adjust_start() becomes return using_2M_mapping() ? PAGE_ALIGN_2M(start) : start. That drops the ASM, and the comment about the linker producing a bogus relocation. 2/3 could then do brk_end =3D brk_adjust_start(brk_cease()), and guaranteeing that the two are the same. > --- /dev/null > +++ b/xen/common/brk.c > @@ -0,0 +1,74 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > + > +#include > +#include > +#include > +#include > +#include > + > +#if __has_include() > +# include > +#endif > + > +extern char __brk_start[]; > +extern const char __bss_end[]; > + > +static unsigned long __initdata allocated; > +static bool __initdata finished; > + > +void *__init brk_alloc(size_t size) > +{ > + void *ptr; > + > + if ( finished ) > + return NULL; > + > + /* Allocations PAGE_SIZE and up will be page-aligned. */ > + if ( size >=3D PAGE_SIZE ) > + allocated =3D ROUNDUP(allocated, PAGE_SIZE); > + > + ptr =3D __brk_start + allocated; > + > + allocated +=3D ROUNDUP(size, sizeof(void *)); > + > + if ( allocated > __bss_end - __brk_start ) > + { > + printk_once_init( > + "%pS: over-sized BRK request: %zu bytes\n", > + __builtin_extract_return_addr(__builtin_return_address(0)), > + size); > + return NULL; > + } You bump the global `allocated` variable here before the check, and don't reset it afterwards. All future allocation attempts will continue to bump this value, and continue to fail. So now allocated + brk_start is past _bbs_end, brk_cease() will return something past bss_end, and (in patch 2) pass that as reserve_e820_ram(). So now, so far from reducing the size reserved to Xen by , we may be *increasing* the size reserved to Xen with unused pages. Worse, if it ends up overshooting the region Xen is in, then reserve_e820_ram() will fail, and the host will panic. This should probably use a local variable, then set the global variable after we've determined that the check has succeeded. The other thing Claude points out is that is_xen_fixed_mfn() isn't updated, so if ever any of these pages want to be offlined for any reason, it will be blocked, claiming that they're part of Xen, even if they've already been assigned to a guest. This is a pre-existing situation that is extended by this patch. -George From xen-devel-bounces@lists.xenproject.org Fri Oct 30 00:03:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 00:03:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465284.1675968 (Exim 4.92) (envelope-from ) id 1xMa5F-00024D-Ry; Fri, 30 Oct 2026 00:03:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465284.1675968; Fri, 30 Oct 2026 00:03: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 1xMa5F-000246-P6; Fri, 30 Oct 2026 00:03:01 +0000 Received: by outflank-mailman (input) for mailman id 1465284; Fri, 30 Oct 2026 00:02:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMa5D-00022u-Ob for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 00:02:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMa5D-00BnQs-5W for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 01:02:59 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae3de85-8faa-0a2a0a5109dd-0a2a4502de76-36 for ; Fri, 30 Oct 2026 01:02:58 +0100 Received: from [52.101.48.38] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae3deb0-6ca4-0a2a45020019-346530268da1-3 for ; Fri, 30 Oct 2026 01:02:58 +0100 Received: from CH3P221CA0005.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:1e7::29) by SA1PR12MB999084.namprd12.prod.outlook.com (2603:10b6:806:4a1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Fri, 30 Oct 2026 00:02:52 +0000 Received: from CH1PEPF0000AD82.namprd04.prod.outlook.com (2603:10b6:610:1e7:cafe::44) by CH3P221CA0005.outlook.office365.com (2603:10b6:610:1e7::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.21 via Frontend Transport; Fri, 30 Oct 2026 00:02:51 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH1PEPF0000AD82.mail.protection.outlook.com (10.167.244.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Fri, 30 Oct 2026 00:02:51 +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.53; Thu, 29 Oct 2026 19:02:51 -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.53 via Frontend Transport; Thu, 29 Oct 2026 19:02: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=CzDJf3aLrHWKAmR9wzNlY0NYfIcRzIa5hse4+tI0TrYuGB3zeCi1eL4aAiDz5pk82cm22nmr5kFYXr3YW96z981bIaXk5NbifJ4aw2McErYNb1ZWfEcytPhuPGTIAWk8OARU8vzn6bI6OasLPC7ORAOyyKQYAiuBe9xulS9JYJPVWy+X9gB0WCVRGFZ6Ljt9k28biTJX39G34p+J5eqEoGk8invsOxACafFrSo+uTiEYiGz3ByxvxPN/O92t1OOCk2zk3lhCsC/G8xD8nHbhm3ekvb7zrPbJRq05YwYQId6xJ4lla6kZkQay2Ic0XrsYh4W92CfCVgjM4+Qgz/GsHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IGZqTsZQRonp6yDXZ074c5A5YvMS6rkOgc+QQ3a5fRU=; b=eeymBwviZvr/JQdZDxDn5190z0JYFnrmr2d29fKap26zqfoLYXGGZZob6e46BcV4gTLTL+XVeIqPs4VNTD3l1eIyxX/UEOl+WNXERI3iqAW5diyE+D6+JS6Z/+tzSiKXQy48hlw2f2KFQX28Z5pzhbDahqZ27tFhw50bDQKnBtaO53S448sR5jGli1om3jhk888tLF9sGdUI7HOSGtdG/uTC/O7eH1as2hOqzJk8bw1imfckMZzwt6YYkGodMVkmSlXhMTGE6y4njDjIQ03aWcsK39SYoDIRCVat/6nJcY2/yl4477zYjoSwTYZFoFV53NvxXr7Xmyf1wsLRVSON8Q== 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=IGZqTsZQRonp6yDXZ074c5A5YvMS6rkOgc+QQ3a5fRU=; b=oI8Ii+WrK4qXnvCFEL387BqTr7CNG08B2LMcOBHIvsHkkQsBzeXuTCQGbKGobjJ+6fFdfL6IiAKucSIELuwcr14Ptb/HPzmuNq7FLpmBA5E0++5Bu3KDjdOk26iCT/DxWz38BinCkJonNWSCk1j0l4E7GFo4CzVo/jYvGkYh2/0= 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: Thu, 29 Oct 2026 20:02:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/3] common: introduce "brk" allocator To: Jan Beulich , "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: <8ad3beb3-af5a-477b-af97-614edb22631a@suse.com> <4fc90702-fb9a-4f96-88f0-35bd3b4857f4@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <4fc90702-fb9a-4f96-88f0-35bd3b4857f4@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD82:EE_|SA1PR12MB999084:EE_ X-MS-Office365-Filtering-Correlation-Id: 3985e348-db41-4fd9-557e-08df361923fe X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|23010399003|376014|1800799024|6133799003|22082099003|18002099003|56012099006|4143699003|11063799006|261022075727099003|261028144727099003|261021121427099003|261009223027099003|261026121527099003|261022105027099003|261026140227099003|10067099003; X-Microsoft-Antispam-Message-Info: xW4DSPijWKlYnwfb7broc4yCxt05O04URWBaaOT/W1Xv14e6LDV4fy6M2UFdGsdiW+sRR3NMzCtBrpW32BaZ5AmPWo6jkfpOf9G+r1JqfFTxGfrU5un98+97fPzCkO3cF/vU8uCYNyk3Mss68qK2Qv3JEdjHJAupHeA3hFkvQ3BhfnTr4vABjo571sV+4WZoyG/VT8QR076aEJRVX/WZGkJSSnlFhOusdqQnLG9WvkON9S0UL9n7tBd2PTLKZCPcFjXtD6mu9gxF8zQXcbBKFTNwGaLBFcv9a0JNFpe1v00it6nsN824Kcv6l4jVrPI7eAD1TVTrydPQwGKTBvc7F4q8syie4EllrCzWTE5Ub73myyquKlgImK7quJKc9NeWr1sxpfeaOwuazqMdKctbVzV5LK97Yt7uit2PhLreIwkNjDEbx2hXFyFBDYg1RwGgsS+r98zPOheYNHsw77Rz99GJOx4iD7FXI95DZd0ignJ0AWdl5HUJCMmva5BS/HziOJLKcq/Ggf34Jxxm4YIhEuTtWiqUJLG+sol1YN0pNQS7MlcKg+yeV7hLkd8Rg7WNxQJF1i4maYVjLqg7loc4AjwdtQgvzlUXfnqIkpWK8k1MehrRlDximi+q/7X9PzkJJBER+RYF+EaCbVPTHNs0wjO7FwGQFYz5kU5oKtFO0evDRJq8X2gdf9EnmTcn8kYNEbbL2lyZ8H+1MZHjolTyww== 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)(23010399003)(376014)(1800799024)(6133799003)(22082099003)(18002099003)(56012099006)(4143699003)(11063799006)(261022075727099003)(261028144727099003)(261021121427099003)(261009223027099003)(261026121527099003)(261022105027099003)(261026140227099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 7kSPwppNgOZR+X01MjRZUOJQ+cwKQ5tHvEGEZ3UJiBc7ave22fAmuamZCiBB1evYkq7yQk4ySPws1BugWXV7Lqwtpa7F8cCgbFFcWMenzj1BpRskinA+3vRcOSA7xabAfvXEtwV48sX2viJQ31ZtTgwuNIH6SKxausXOAsK5uCftGpXpQgUYBMsuw9Jn1CleFuawahsGmT2zIplgg3iG56AGTckvxXGRmRgrLTebObB1a7ne382eVk3afltizVP9nkppTngvrtUMj+eG8zmuUT21SgJyaiLyoI21X+4sccM0GsW9U9laPSn2qqQ2ngvOKoaF/HoE1mWeyCGHlpcgE47vu8G8Wgzipaygv7NIFN1i8L9SXLtvr7qvxppHSWzg9MrZs6v5Bbs7KIPuZKytohxiBzpAW+fyct+Oi5wmhAixtgWcpbAgMvHPVFeFAp4D X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2026 00:02:51.5520 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3985e348-db41-4fd9-557e-08df361923fe 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: CH1PEPF0000AD82.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB999084 X-purgate-ID: tlsNG-720697/1793318578-F10A02AC-4AD9D86B/10/78276251493 X-purgate-type: spam X-purgate-size: 2048 On 2026-10-14 09:01, Jan Beulich wrote: > ... to replace (on x86) ebmalloc(), and then to find further use(s) to > allow recovering memory which is needed very early (and hence needs > setting up statically), but may not fully be used (or not be used at all). > > Note that unlike free_ebmalloc_unused_mem(), brk_free_unused() (once > other code is converted) will be able to free part of the BRK space even > in the xen.efi case on x86. That would happen if BRK space extends across > a 2Mb boundary, and actual use stops before that boundary. > > Signed-off-by: Jan Beulich > --- > Changing setup.c's reserve_e820_ram() uses would be cumbersome when done > right here. That'll be done when ebmalloc() is replaced, and hence > what's there can also simply be replaced. > > When linking xen.efi, GNU ld prior to 2.46 produces a base relocation for > the reference to __subsystem__, which is wrong (that's an absolute symbol, > after all). That does no harm for our purposes, though. > --- /dev/null > +++ b/xen/arch/x86/include/asm/brk.h > @@ -0,0 +1,23 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +#ifndef X86_BRK_H > +#define X86_BRK_H > + > +static inline unsigned long brk_adjust_start(unsigned long start) > +{ > + unsigned int subsys; > + > + /* > + * Only xen.efi will have the symbol __subsystem__ available, and it'll > + * be non-zero (10) there. In ELF the symbol will be undefined, and > + * hence zero will be loaded into the register. > + */ > + asm ( ".weak __subsystem__; mov $__subsystem__, %0" : "=r" (subsys) ); This seems like an indirect way of determining if xen.efi is running. Your comment explains this, so it's ok. It seems to me that an alternative would be to add an explicit symbol to the xen.efi linking instead of this implicit one. Though that would just be replacing __subsystem__ with something else, so maybe it's not worth it. Reviewed-by: Jason Andryuk Regards, Jason From xen-devel-bounces@lists.xenproject.org Fri Oct 30 03:42:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 03:42:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465396.1675978 (Exim 4.92) (envelope-from ) id 1xMdVS-0005ch-Lg; Fri, 30 Oct 2026 03:42:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465396.1675978; Fri, 30 Oct 2026 03:42: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 1xMdVS-0005cZ-Gg; Fri, 30 Oct 2026 03:42:18 +0000 Received: by outflank-mailman (input) for mailman id 1465396; Fri, 30 Oct 2026 03:42:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMdVR-0005cT-NF for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 03:42:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMdVQ-00G6oN-Sp for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 04:42:16 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae411cd-e002-0a2a0a5209dd-0a2a4502d5a2-40 for ; Fri, 30 Oct 2026 04:42:16 +0100 Received: from [74.125.82.176] (helo=mail-dy1-f176.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae41217-6ca4-0a2a45020019-4a7d52b0d474-3 for ; Fri, 30 Oct 2026 04:42:16 +0100 Received: by mail-dy1-f176.google.com with SMTP id 5a478bee46e88-35c76e9614aso508268eec.0 for ; Thu, 29 Oct 2026 20:42:16 -0700 (PDT) Received: from google.com ([2a00:79e0:2039:4:738d:5089:c912:2b72]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-36a42a61a0csm3456804eec.22.2026.10.29.20.42.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Oct 2026 20:42: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=20260707 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=20260707; t=1793331735; x=1793936535; 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=/PcaN2VMoTk4jjrAkI7QtTwmvCihb0JhvG2tPXWeOx0=; b=lfFyyJu91lsh0AxQo2xWVSSyA7sbgDxs/I7jjOUDxiVmxKwthsKnEoXOcDjE3v9BQ2 Qeby/qYHcTsNHSsEY0yTjqOx584GRTRCHR8yM/C+WQM97GdvrTHfBpVCOmbv7QvmoGlB yr+ZUdatU0F+dU4sD4vqUi00pHZocPW2Z+x5tTFphMV9IwNGN1FuyvMoadYNfd0Ed2GF r3BgzhrgZhY15bygHi2cHcABpDYqHs8cBCS9w0WZNbVdr+n37M6Ig4jTHNErunR84XwC I89NbKPax28nctErWb2IhqDJnzpljjcQ78FNO/4Lvrdml44AxbSSPIZSb8VdUsIIX+G3 nBXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793331735; x=1793936535; 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=/PcaN2VMoTk4jjrAkI7QtTwmvCihb0JhvG2tPXWeOx0=; b=SoFd96eoqz0b/TKSgjj+UdIPPx+dlnjE+hGzK3rtIIJbiKbpemG1W3HSP3DUs61YT9 HaBpl0G4fopRy2p/PSk1xnfiB5RIKybnNbYRfEfY65GzID7ta3Xpr6AaVNOMrfMCydIl XzERWchDn3eyhI9HoWsky9ZTC1tdZNGj0TltHabRvee1pnk+KXLQfvLh1JP4SpGCrvsT cyZXEKR3GG4Ej6wQpnA0tQBtgNZi5dC0dyxQMjhHGjOdKt6956P9N/qlG6ePAEj15//F M8LggThdYKQ6aljyYXPHRuQjRh/Tr9EKBwXzlet7U4HtqJww+KCzgH83O89UWLHlbYaB FLmw== X-Gm-Message-State: AFq9FYLzBbhkn8gYU9xPpggPz34XdHkqw4wRHDzPwgoKlihrj5oNOG3b wMN/shoVdYvXPeoid3ElektP04oXZJkFEGt/Z7COyyoH7FRnBvKaTwJn X-Gm-Gg: AYBFou35YscuPWpEZvn/2mycZh04kt8hoPrrpLotL3CZgvLo9Wbhkk2xSUFr1/SBu0v L12EUaWxHhjeH/thhJobZZF0A3b6mmCSe9v8wUWOis/LwtZTHIX0aDdTtTFfqRLXa5ZzprNneN1 Pd8H/LbTYhWNSkBDlMWsbm+wtcIi6rcjC04kUp7MwZr5YhvcQoMa9PZjasea6DrP3diZaLM9j+t IIqu4feSxdc4lM7vEAjn+bgZtGMsPHk7s6NCjrHrDNNTIti6IXqwPJIfLNf5yyMUIpQFdAQb6tR K0WUo9TMTMD6U1Y0lh8fQ23P3U8hJbW8CwEfpNlqE0Avpvc12vtB28uTWHP7ZGeHNzLAUby7GXI ZT5G0WW2Le86+ujjMe3LmHpbd6OXai/Lb6VHF6s6s+Y86i975vtLQYrQ3rBb2M5gd/r6O/nIElH 2gV9Y31v22tXWF6tiCpHC749o+5Pxcfud49AAkM7z2dhgSsl3ewCQ0SVRjNQ+lHeOyd1ODkBgLe zSO6p+FbDtAgIZOYGa4F6M3BpTwWaZ06dK4vadXaGs3vOnbwHCfuGmWHT075z4GTxFuCwpJRz59 5dUkSaDRaURxMLQpAFPXZRixqkjN4vfrwUk3Nu/W7rFewnCZpeIjzo+rBvPk8yh/2zVQcAVLMQE TBjvb/4e1Jg== X-Received: by 2002:a05:7300:559e:b0:36a:1846:5c77 with SMTP id 5a478bee46e88-36a42204585mr1902055eec.3.1793331734454; Thu, 29 Oct 2026 20:42:14 -0700 (PDT) Date: Fri, 30 Oct 2026 11:42:10 +0800 From: Kuan-Wei Chiu To: Michal Orzel Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: Re: [PATCH] xen/dt: Don't advertise Xen static-heap region to hwdom Message-ID: References: <20261029104305.169036-1-michal.orzel@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261029104305.169036-1-michal.orzel@amd.com> X-purgate-ID: tlsNG-720697/1793331736-66EB32AC-77036E61/0/0 X-purgate-type: clean X-purgate-size: 1938 On Thu, Oct 29, 2026 at 11:43:05AM +0100, Michal Orzel wrote: > bootinfo.reserved_mem is used to store different types of memory that > Xen considers as reserved: domU static mem, normal /reserved-memory, > FDT memreserve and Xen static heap. make_memory_node(), invoked during > FDT generation for a hwdom for reserved memory, only skips the domU > static memory and FDT memreserve. This results in advertising Xen static > heap (if used) to a hwdom as /memory. This memory is not mapped in P2M > and guest attempt to access it fails. Interestingly, if the > /reserved-memory node is placed after /chosen, there is no problem because > of the check at the beginning of make_memory_node() that finds the first > memory range using the correct type. > > Fixes: 4596329291f5 ("docs, xen/arm: Introduce static heap memory") > Signed-off-by: Michal Orzel Reviewed-by: Kuan-Wei Chiu I guess git will treat this as conflicting with my dt patch when applying. Let me know if this gets merged first and you would like me to rebase and resend. Regards, Kuan-Wei > --- > xen/common/device-tree/domain-build.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c > index 30a59abfa722..634a26946c24 100644 > --- a/xen/common/device-tree/domain-build.c > +++ b/xen/common/device-tree/domain-build.c > @@ -541,8 +541,7 @@ int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, > u64 start = mem->bank[i].start; > u64 size = mem->bank[i].size; > > - if ( (mem->bank[i].type == MEMBANK_STATIC_DOMAIN) || > - (mem->bank[i].type == MEMBANK_FDT_RESVMEM) ) > + if ( mem->bank[i].type != MEMBANK_DEFAULT ) > continue; > > nr_cells += reg_size; > -- > 2.43.0 > > > From xen-devel-bounces@lists.xenproject.org Fri Oct 30 04:06:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 04:06:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465404.1675986 (Exim 4.92) (envelope-from ) id 1xMdsM-0001Nl-C9; Fri, 30 Oct 2026 04:05:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465404.1675986; Fri, 30 Oct 2026 04:05: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 1xMdsM-0001Ne-9b; Fri, 30 Oct 2026 04:05:58 +0000 Received: by outflank-mailman (input) for mailman id 1465404; Fri, 30 Oct 2026 04:05:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMdsL-0001NY-CW for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 04:05:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMdsK-007VzT-6t for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 05:05:56 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae41778-8faa-0a2a0a5109dd-0a2a4506c53c-30 for ; Fri, 30 Oct 2026 05:05:56 +0100 Received: from [74.125.82.170] (helo=mail-dy1-f170.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae417a2-195a-0a2a45060019-4a7d52aadd35-3 for ; Fri, 30 Oct 2026 05:05:55 +0100 Received: by mail-dy1-f170.google.com with SMTP id 5a478bee46e88-3514b90bb89so632141eec.1 for ; Thu, 29 Oct 2026 21:05:55 -0700 (PDT) Received: from localhost ([122.172.82.240]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-36a4291e38fsm3512579eec.15.2026.10.29.21.05.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Oct 2026 21:05: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=linaro.org header.i="@linaro.org" 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=linaro.org; s=google; t=1793333154; x=1793937954; 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=9CvywPHpjrCT0zo2JhnH11M0JaZbySgNZTi9n8+NQFc=; b=aE7hZyGRPIWP8axnGNKm268FSoukjppDardJF4xdB1P1Lf83Z26eHxbxN7oTtM4bTQ ct49w19ysE1NOEqDIjmUjnHQpzxkZ7u+IWM00sausfhuTMTrN1KDYWop5g/zFYJagNt5 4o84TjCIiC3Rv4N9b7RmsKBQOvaVWAPz9Olo28/7//uY7KlZZ0pND1TaiGYF8xjnsj1u rKDV2DDVdNbTBuTfjpjCMly1ci4yOLkgKTvSTU5rBMLn1iW94q1DFVBI3Af5TaB0478O nSPJEZApwgz/6wbLes42edpj+0Y5am+0/BA5RG/JZBhcOglNUqVPWLGofavf4Tx9ePy/ Kj1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793333154; x=1793937954; 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=9CvywPHpjrCT0zo2JhnH11M0JaZbySgNZTi9n8+NQFc=; b=ggcINP0jTTgyawM/ZQBAvW+QaaHxDhU+9aAQC5Vi6YCdGBDROW0cHh7ejscWyg+0HB or0CcgCtxRfPOnzTgdjiGLwC5IUj8iZhM4aWaPydbtKuyJfvSKsYbI8ar5ODusKhDOWU HQHuvSeNMALmPJvFIkzTWoD82Uban1Iqsn5NA0DSfOkZBolaqTspN4mcYOd8HYGWciyp thIBg/EfFI720h8eSjhVyeO8PTmsLHYgcvt3S96cvxD9/GJjwSnfKEzfa8WFzLZwHC8C fOuSLsBuK53okuaQ1wc5yv5xCv9dCrbIbVyThvMk2Ok8WRJOLaXwWMJPHYzJJMjLDq+t yEfA== X-Forwarded-Encrypted: i=1; AKwUvBwQXno+YtYjMpfPqJ7xtm0eDZCZN4yPIduq814sGiog3wfOp0oqtqFsntf7OF0cer3sD1bKcOIuZkI=@lists.xenproject.org X-Gm-Message-State: AFq9FYK9d0kjJ5xM1sthxXMTN6nlWgIsU+h/0a2PJoZIi7SHs1HwMaWV UvlBoohZQXkIMk7uzFoJhpSnAzPEhzh9oesh5pZr2+y2hNHvGx0oppNw4q8vPHrKaes= X-Gm-Gg: AYBFou2+56nCeGZPsBjNePmUQLCzpXtWJd2tJ5tqfnuktKyisHzEj+Pdyb2vp2rNoe+ jtvharjJOmMy0qNvn9kCyblPgZQY3iq5VaHM74hx4Csi/KT1dK6FoSv4TJDa2P/+W1dBDhBUild dU/+1nz27nNGElQaoe/LRQcIqy5IRDM3MNJghPicCemoe8dA90p443QCjeKsAJH6mZyr4rjhtJr xns2BnUcbWOWa00m1sl2jSgQBnl/zn0AOc+bVT88Hu1/iYFNT2y3mJXTCwgdkZIjQbicTZh+kP8 EFtZhu/lX4IvqiUJpBBeW0i4XQUsiHFVyNpBCrQdLUR16cVrwlOlgqYgdtM8p7hGuKpBXyS63aW qJdDOHEMAe90VR8tpsVy8aGoRDGb5KdBrHjyKQlqc8UKFfO/4j9FWA+oQsxLhxgf2ZoGGdLzjq3 oQPbDgpiBEOr6e0BeUMVB2vk5M0ZNptf0Cv1sLCN/Elacb55kcOQVJdmHYHa4UpnE1Cy9Tn0DbK BLEwYi1Zd8YwN33izlz9CrDFxWlDEA6vwGnDGQWsraRjqk0rlP4C82niNN+D6Rei2ZfwUUdlutF 3J5kiAYw1PjgEM+TUHN4td3aT6d8jP0= X-Received: by 2002:a05:7301:53cb:b0:35c:e696:2d4a with SMTP id 5a478bee46e88-36a423ea99dmr1772736eec.24.1793333153319; Thu, 29 Oct 2026 21:05:53 -0700 (PDT) Date: Fri, 30 Oct 2026 09:35:49 +0530 From: Viresh Kumar To: "Rafael J. Wysocki (Intel)" Cc: Ian Rogers , Kees Cook , Greg Kroah-Hartman , Miguel Ojeda , Danilo Krummrich , Nathan Chancellor , Nick Desaulniers , Miguel Ojeda , Christian =?iso-8859-1?Q?K=F6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 4/9] cpufreq: governor: Initialize kobj_type release callback statically Message-ID: References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-5-irogers@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-16d1c6/1793333156-FDC0F77B-07ED9456/0/0 X-purgate-type: clean X-purgate-size: 293 On 28-10-26, 16:39, Rafael J. Wysocki (Intel) wrote: > I'd expect the driver core to pick up the series as a whole then, so > please feel free to add > > Acked-by: Rafael J. Wysocki (Intel) # cpufreq Acked-by: Viresh Kumar -- viresh From xen-devel-bounces@lists.xenproject.org Fri Oct 30 08:49:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 08:49:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465469.1676001 (Exim 4.92) (envelope-from ) id 1xMiIj-0002fx-RW; Fri, 30 Oct 2026 08:49:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465469.1676001; Fri, 30 Oct 2026 08:49: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 1xMiIj-0002fq-MU; Fri, 30 Oct 2026 08:49:29 +0000 Received: by outflank-mailman (input) for mailman id 1465469; Fri, 30 Oct 2026 08:49:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMiIh-0002fk-8D for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 08:49:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMiIg-008yeb-6F for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 09:49:26 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae45a11-e002-0a2a0a5209dd-0a2a4508a1b2-4 for ; Fri, 30 Oct 2026 09:49:25 +0100 Received: from [52.101.56.41] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae45a13-f659-0a2a45080019-34653829b11f-3 for ; Fri, 30 Oct 2026 09:49:24 +0100 Received: from SJ0P220CA0012.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::24) by PH6PR12MB902451.namprd12.prod.outlook.com (2603:10b6:510:3df::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Fri, 30 Oct 2026 08:49:20 +0000 Received: from CO1PEPF00018860.namprd02.prod.outlook.com (2603:10b6:a03:41b:cafe::1d) by SJ0P220CA0012.outlook.office365.com (2603:10b6:a03:41b::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.8 via Frontend Transport; Fri, 30 Oct 2026 08:49:20 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF00018860.mail.protection.outlook.com (10.167.249.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Fri, 30 Oct 2026 08:49: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.53; Fri, 30 Oct 2026 03:49:19 -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.53 via Frontend Transport; Fri, 30 Oct 2026 03:49: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=hv4wF5aWkyvjYE6YwSZLM9vLzKPPxbR8kXL8wtQMdVwf7NJieGDzSSSJLFNaDxYvkqv70V+2towlzoDbc5C0gNnYkOFW/UzOJ+mEH4vBFshMqCGZGP0qbznkEyIQUp12qv4wFMCs++A4eMIqDBtdXajjXc7mNfiRjyR0v2b9foWbHtzfbmk/4nH4gy/Pj0fwIQ2PofXWGKctPdmu9MBL0ETXHtZIL1tFl1lDP5+6rt9ZprpI5vZtCE+C8EQP5urcCbwJSiXaEg/B/g99EqLifKcoKAsap31E/CJsVJ8IR96DvQjIz2LsYta8XdkzaYoRpLYq7hlLeYLCpFzfFy6DNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vXGmtj+iz10g+AM3qEIZdYwY3Unl0j7ECxtlYWcVhHs=; b=jHWvVbrXqO46yaEsEZ1T/DQNDrQeDB8aN2xDaJEUGi3bADc5zFuREzLKCRJh4Y96HhL+0NO2m4jzbZh2kpm8H5Bu/5K+lL2zrVzJqA39P0lYMoDcATV98HInzE6u+V9aM2f2AjItnTHC+o7PXiGBMc8OYaNhd4vN/NpamyvpMjFySZ9UzD2RYnO04nBkrNgFvpFfpDc2yVqBtl2w74TnZCL9TnxBlkaw08i0Em09peVnI+lHmh7PW+3iN7OSArVZK+reupTn2aKk6KeBnL8q++sVEJXIXHSXeRHxyWpTUy9amg9W2bS1zVhgTwBS7YIgtsMpTx+3fvjDFh74VmeGgA== 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=vXGmtj+iz10g+AM3qEIZdYwY3Unl0j7ECxtlYWcVhHs=; b=rYdG1woc2BtTUNvARk+uWU7O1wabY2AGd9N8qZw5gLmjqRrtEzSU0/Mz7jJNHuqtCIYbtDQoVrrfVLNUv5FeIdiBqXggExbgsYA9oEyKFnbGa06LwcDJuVTkSxjd/TVWya1N6kXXdPEKSYmygSWamKtP4bhSzpXg+d8MsKcOGWQ= 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: <12b11b1a-7238-42fb-a157-a3b5afe305bd@amd.com> Date: Fri, 30 Oct 2026 09:49:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/dt: Don't advertise Xen static-heap region to hwdom To: Kuan-Wei Chiu CC: , Stefano Stabellini , Julien Grall , Bertrand Marquis References: <20261029104305.169036-1-michal.orzel@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: CO1PEPF00018860:EE_|PH6PR12MB902451:EE_ X-MS-Office365-Filtering-Correlation-Id: 5d9973b4-1e7c-4728-7938-08df3662b086 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|23010399003|1800799024|376014|36860700016|261026140227099003|5023799004|4143699003|11063799006|261028144727099003|56012099006|261026121527099003|261021121427099003|10067099003|260925021911599003|260925022911599003|260925021311599003|261022105027099003|261022075727099003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: ee41KT2TbT21YnYdL6vF7bZISWJC33c/7KK1wgd/Fv7vX7V/d4yWCDgc8ImDKo2RgBRvGyLbH7E/AxFm9bDgQz7usfXRongwPzlbrUJhPMsNJTYuC33BuUez5SQKWYEWeqOWvuLcRffLrP90pyGc21KIrAFvADoguO5YO7ybjro1ncJ+gPYUjHXSCvzjRNTXygSfKwQwA1UsFRt6hwEPWS3ajutz2JlY0TM3CNnAp4VGtw7kK2nVTa4fhYc+4EkrOqpBmcB6VAXeUuS5nTDk7HqFiXV2qO7vuiBaZZQWnVODLUZwukVFv3xzzfsQkbNzxcbfIGv0UCGDhQsANN/Wq9OPOpDiDJK4vWaNZIZ4ShQgb7AHfzOq2pQOl8mavtrW/jJo4qF7MUrfEkWTaBZJh1GtpfXnYvbl69uZARbhDrGaoR+TZJObkLwJsk4/RBCTCk1tYm9cuMFY3p0Svyp+aR+qGkS+7JfXKV7w8r0FXu5CF0SYd9Z9M6kLv9n+ZvUb3AmUplaE+0oqisLLWUo5dXohzw9D4Hm3frvrwssdql4IK8dB8Wx2pn8VW3cnKZGyPLYM+0AksyCJLrO0JMlZqcfoMu0jbjKNZn96BtAi/7O+zvOgzUQhqerbeiFjjuEk6a/47UmOw3DSqvoB/WA2zy/10gDTen5RqtFEjgeN0N8PU7X3THUYvEfYoETzj1etQk/onPyvx5wxrqAA2xKHHA== 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)(23010399003)(1800799024)(376014)(36860700016)(261026140227099003)(5023799004)(4143699003)(11063799006)(261028144727099003)(56012099006)(261026121527099003)(261021121427099003)(10067099003)(260925021911599003)(260925022911599003)(260925021311599003)(261022105027099003)(261022075727099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: xZ3wisHkZ4NSY4eYXU0pGtQ3g38BYA15l4FRRzxkR3kj9MpTVaIfsGfdz/Nbq9+rmuATNkJWJrQ3gT2GOZwad25LtnJpqMKJzuA6DCpNNwC/W8w8wXzSajIjSUUk2x4my20B0wQb1LPbqySalK18OaKQL8yqXcMxQuqRQoRU1WVgFjHApeRvq4Cpv8s3qyBQLclBYJ9JGdm18NhLJ0JZFQ1ZPTbVjlhrPAGTAThNAOyyoJI4LLtVMtniLUOC8CXDqnrqvstCercpPY2ctppx38rIdGPC5akpwlODDmWGiHNSpjUx7GieC9Kn38K2+/idRqR5WpY1MEvNZwkA8jHlyPJFvD2Bwxuik+ck/tngZWralwqvOYHQrWwv9LkwlY0yxVe42HOOALo7DdJdQ1ecxqRUfJNuSVXU0f9xOg0Kje413u1cAJjQZbO9NMsHwvof X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2026 08:49:20.4839 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5d9973b4-1e7c-4728-7938-08df3662b086 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: CO1PEPF00018860.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH6PR12MB902451 X-purgate-ID: tlsNG-c1860d/1793350165-CF75B87B-C9C36AD3/0/0 X-purgate-type: clean X-purgate-size: 1300 On 30-Oct-26 04:42, Kuan-Wei Chiu wrote: > On Thu, Oct 29, 2026 at 11:43:05AM +0100, Michal Orzel wrote: >> bootinfo.reserved_mem is used to store different types of memory that >> Xen considers as reserved: domU static mem, normal /reserved-memory, >> FDT memreserve and Xen static heap. make_memory_node(), invoked during >> FDT generation for a hwdom for reserved memory, only skips the domU >> static memory and FDT memreserve. This results in advertising Xen static >> heap (if used) to a hwdom as /memory. This memory is not mapped in P2M >> and guest attempt to access it fails. Interestingly, if the >> /reserved-memory node is placed after /chosen, there is no problem because >> of the check at the beginning of make_memory_node() that finds the first >> memory range using the correct type. >> >> Fixes: 4596329291f5 ("docs, xen/arm: Introduce static heap memory") >> Signed-off-by: Michal Orzel > > Reviewed-by: Kuan-Wei Chiu > > I guess git will treat this as conflicting with my dt patch when > applying. Let me know if this gets merged first and you would like me > to rebase and resend. It will likely get merged first but don't worry. I can solve the conflict when I start reviewing your patch. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Oct 30 09:04:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 09:04:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465481.1676012 (Exim 4.92) (envelope-from ) id 1xMiXN-0005lA-7t; Fri, 30 Oct 2026 09:04:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465481.1676012; Fri, 30 Oct 2026 09:04: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 1xMiXN-0005l3-4u; Fri, 30 Oct 2026 09:04:37 +0000 Received: by outflank-mailman (input) for mailman id 1465481; Fri, 30 Oct 2026 09:04:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMiXK-0005kx-OG for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 09:04:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMiXK-002Fio-4k for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 10:04:34 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae45d9f-bab6-0a2a0a5309dd-0a2a450ce400-12 for ; Fri, 30 Oct 2026 10:04:33 +0100 Received: from [52.101.229.108] (helo=TY3P286CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae45d9d-f479-0a2a450c0019-3465e56cc751-3 for ; Fri, 30 Oct 2026 10:04:32 +0100 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) by TY3P286MB3793.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:40d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Fri, 30 Oct 2026 09:04:26 +0000 Received: from TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82]) by TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM ([fe80::5f8d:a6bf:3b84:5a82%5]) with mapi id 15.21.0569.008; Fri, 30 Oct 2026 09:04: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=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=oIaZfOaBAsS+AqkAa5yDtMcCCUs8+OheF8qAb+mlcZng1hlFmKL9TTijLHTHKr801GkmqIa/ArkZt/NLjRVqi4yB7OMl3ofgndp0i4v3bskjk7iBoD22pD0O/Kdt5WXNCdnBxAB7Wvx+xJnMjO1m/Ijw8ltnZFSXnAZInYOCIO+e4uVxJ3Af+gYiI4IYf9Ol6wINcrbQGyEA6BOpSaBP8lX6+zOeTbRIJbUrVRC7O0G4F+NdMCPjmrQl/MsM8/kaowQWZRqKGFTkMOPJ2Dfha6YL5QYqoqYuPe4POowW9HiIXP7dtxEKeKeUHA7F0t6DKavGsEwPc0oSCen4tyU8Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IcFToYh5/jqGF0J4/az2j2kmka+Rz9WiaE5C3TEsFVA=; b=ja+Uf05K2toArHVTjREqZ3sLea9CTnTW+Z6+j2GZBmQndQHtxaLoWYTLksInpAkdSyNIfER/oNJHEuati/RJsv71tx+b9lGrxVW05UuaxI3NrCuvZi5t4GLu+Xo0a7O7IbXgcyYtnMxlSGqWagjD3gRB+dVK5ZbY+wc2B7ZVy8G8fdFFQhFyJ7HWUZdaWdXHZEfJpZWEpNYPT6n/H0SV7DIDUWQZEcRM4yw7DGQUHKF9wGHnyDg58RG0KxoYifLeheATlttmBEk2KCzMpum/ztdgXcn2GCwLCUCuSQ37cvutKIlACkoEzrt0aOVHEhpM7X7OA4aPsFij+gXdOxGv5A== 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=IcFToYh5/jqGF0J4/az2j2kmka+Rz9WiaE5C3TEsFVA=; b=BTxUUOoJS6PHCyFRTMqBPcbVD7mbsx8jw2KU1Df9ZY2Y0dFbLxngoqB7Cs3IMFjZaix5osJeu8eNri5g5qsyZEi7tdUnUl87PNZrTt9FWS226xVXNwefCTrjhjlRcKlW8IeAy0IHKXjizOtzRrEA3KnEAKRD8R5UpGrBbq5qrz0= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryo Takakura To: bernhard.kaindl@citrix.com Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org, takakura@valinux.co.jp, xen-devel@lists.xenproject.org Subject: Re: [RFC 4/5] xen/tracing: Add a function tracer Date: Fri, 30 Oct 2026 18:02:58 +0900 Message-Id: <20261030090258.125062-1-takakura@valinux.co.jp> X-Mailer: git-send-email 2.34.1 In-Reply-To: <179285185778.1706038.7602957469449476344.b4-review@b4> References: <179285185778.1706038.7602957469449476344.b4-review@b4> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TY4P301CA0051.JPNP301.PROD.OUTLOOK.COM (2603:1096:405:36b::12) To TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM (2603:1096:403:511::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TY5P286MB319683:EE_|TY3P286MB3793:EE_ X-MS-Office365-Filtering-Correlation-Id: 5edd6344-ccae-4343-cd2c-08df3664cc82 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|56012099006|261009223027099003|261026121527099003|261026140227099003|261028144727099003|261021121427099003|261022075727099003|10067099003|261022105027099003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: G6vkvINLWrAi8aJSj3F6j856M9mcKNEUeWGkV1/FQb9o5ugPyNhu8NH1B4/2eOgRQlOhtpfD14C/gkWSgCHiWTtlcGVc5carkLZArjlKgNywAAFpfpL2tzNfSQ38gtLmOlft859YBHSw9Ecamz/bdWRxKoelIm8c7Z5XcRX51Vb4TXUXa99+u9Lo05RCJLsV6YFZDqWcIiNHkBJcKEL3mOY3dDx0pEwY5mgLE2jw0FkIe0PkL4j0YGqTsQHFoAbnVNROkurgZC4Ek7YH+yFSnLzwKqPFQidI+rEQjiU/WLlkRev2W7OvXzltDQ8dnW9MrnudAuX83NclIXKE+0rXU2wXPLG89C1C2fFD6xDvqNxEKFFqCntV5vSXDBox2Av/z4/8o+XrJZCJ4w+yuHl34qpwbB/wU33usb+uNJMy5MZendNT9WaLZ+8i8OYgZpdoqlxKjoiRAT9uqWTPn5jwVD+hjZDNxXgv69rYwTmDgmePMERxtBfrsQm73p5ArXiVDFIKT4xiBDBUygqny6cgl3hjBSPYnfOyqeLuP8l/aMX1LTFy4FucfC26/f+ELD6OZ6rDztzAwDG9k1nslZzjKdlpxhkFV7KEtRvoDWQzatszkCm5DDnHQ3QDlqXjAvNn0ayktkuT7h9Osn0Q9mKm1YK1gwhSt2lt9++dT6sLm1w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(56012099006)(261009223027099003)(261026121527099003)(261026140227099003)(261028144727099003)(261021121427099003)(261022075727099003)(10067099003)(261022105027099003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?W1VCO0LOVRoLP561jrDVXnaywLkVp9YJ1yMYULwuqUKgm2qEuJo+Sm6Fezn8?= =?us-ascii?Q?ukACmZKgoCsnOuLVLRk+E4PdiPgv8y1lSMLBansDPLo6qT60iCXeDj6nLUn+?= =?us-ascii?Q?DRM3/JCKniA8Ru40huz88PhSNXcl8sGY1nJzhvo8Lwm4HPfj5uMMkyEOpCJf?= =?us-ascii?Q?auTl1XxJ4B6lnmMqYOiqqyq79z9R24p7I0vJegGeQzRq6JsyRkcflZ5ByVl+?= =?us-ascii?Q?4pG4HQ9Pbw6z94/WW3Nst4fvCt7/inAEkMyNAnFLNqxf99liIqks5GQMJ6sV?= =?us-ascii?Q?uqz04peuNQ7qEpgL6NRBPMZ+Yh47CYj7rRg/jthDx5ZIEGQw57owT/UxDLoW?= =?us-ascii?Q?110KKGg2LDGn2SzmLRMbhnBMZUrlVZDAnephaT5CLcARAg4ramiglcb7BdCC?= =?us-ascii?Q?BjFVMvxKuDp5PiXMNlHmRr0bIg6YZb1KQ0+m5V6kmljKU+H62HkULnRo1dFP?= =?us-ascii?Q?vQL/h+hgkkN4h4Lr8fNEH28hybLRAYsysYSIxD26wLMCDy3nwpPRi3tK7mEA?= =?us-ascii?Q?0e3JTSgHiQjwG2QWPbcm6A6CzKPoWC/8E2uk5h2Vv93it4lSim9Irp51cO6E?= =?us-ascii?Q?ga7ykHQrjCYWyOOTMtZZ+lVJpl4s4I8Znq8cVIg4pSF+6+a7Z907rNzK593s?= =?us-ascii?Q?z2KMtoOkzj3VQQv/1sZ7ILcqE/r9N29jDGPlcx2CXNMaVehogs+RLRsw8vpD?= =?us-ascii?Q?Y4z2/SqZEF2cPyLjCCSC8j05kGN+Phu1hF3kU1A58RGv22LtY/7tpxUYErXd?= =?us-ascii?Q?MmK1KX/lqYNqmiwJvQpYu2IK4Y5tGWf4BqZyh0otTHeCPYKIWjlZIRgx2pJb?= =?us-ascii?Q?hUuUZtZWTveJ/rB0aDkpR+mHRzabC37IM8WFWGjmcobeeatHOg9HwLv/za+H?= =?us-ascii?Q?gobkdiuSW5FnkmPVi+Ji3Z+b5ddziyI5iNhuUmbnqOLYTx70PT+RrsvEgeD8?= =?us-ascii?Q?CrCMGqc3X7WuW7k02InFIUocyIs17i+EoVIalnVEhwSoWiz294T7lZkBFzMx?= =?us-ascii?Q?kNFCbmfNt9Nc8G+ELK01Ji8cjPJvhabDUbO8vtkP/9IcU3sPidy1vc7UijMd?= =?us-ascii?Q?Z4dlUSi7cZmH79lbAoqCxe5xVRCdbn1AlCIAqB3UQ1Q9Lo9zwVGGZw3mne4c?= =?us-ascii?Q?QIAMaTwIaBinjxqgeL6toH3XbNArkZ99watIGQ4yU2B8Rhs1ZR3Ew5KVfLB5?= =?us-ascii?Q?A5YO/dDL/9Nmvn2cqvKztrSzwK1kPsc2wzBS0U4surzj+Kw4kCPqUxvYAMo3?= =?us-ascii?Q?ZQITC29SFUtZNDaLXa77bXCv4dc97SoDkgmREu9+jO5ZiFvOyKEpXpWApMKN?= =?us-ascii?Q?gieWTL/Fv9lZEb3iJ4uWTuFDAM1C2+00WYsiN/ZRyEx2xR9mhB/nxssEwwCM?= =?us-ascii?Q?b+p6C179Hgk3ooAuER9FvGccNHk4idQrdU5URLNRrtScVr7/ftpSFGqmO+Ct?= =?us-ascii?Q?Cq9HATucmjVc+w4anmfzbcIY/CKdLqo2SYmQofGyAlCDZYLfrU4Fjayce38F?= =?us-ascii?Q?vdp5CiU3qUfklLruYA7fOc87CMpsdtObjZFE90PCyZRhYG937k+jazisp2cD?= =?us-ascii?Q?0l+NUsBwOz0rBWmwlot9QCU89W4VcenjioJJy4U9i1gvQMxYFzj2fVYWfK5B?= =?us-ascii?Q?ci+g2qdBbaIVjBzWl/poLKAnlEKSqnL3Gpgq5l45B0tyHpxPE7wg2ajr6dcZ?= =?us-ascii?Q?UiWD6ZnfiGMJ4YNGjVoAleIfSftCB4oyay27RL8not6rBysLZTyJmEw7efu3?= =?us-ascii?Q?2f1VhId2vg=3D=3D?= X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 5edd6344-ccae-4343-cd2c-08df3664cc82 X-MS-Exchange-CrossTenant-AuthSource: TY5P286MB319683.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2026 09:04:26.6686 (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: d4rmmjIe5zngt0cczmxKM0vk1LBdVmL+xqZxOdHqYoLGBnBE66FAJWAfmTzW6wiF/aTdmaVlp06rQXK0k/nfmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY3P286MB3793 X-purgate-ID: tlsNG-d25034/1793351072-5093EA5B-71B642D3/0/0 X-purgate-type: clean X-purgate-size: 6678 On Sat, 24 Oct 2026 16:24:17 +0200, Bernhard Kaindl wrote: >> --- /dev/null >> +++ b/xen/common/function_trace.c >> @@ -0,0 +1,274 @@ >> + if ( this_cpu(function_trace_recursing) ) >> + return; >> + >> + this_cpu(function_trace_recursing) = true; >> + >> + buf = &this_cpu(function_trace_buffer); >> + rec = &buf->records[buf->head]; >> [...] >> + buf->head = (buf->head + 1) % FUNCTION_TRACE_BUFSIZE; >> + buf->written++; >> + >> + this_cpu(function_trace_recursing) = false; > >What ensures that a callback which has already passed the dispatcher's >tracing_on check has finished before another CPU reads or clears its >buffer? The tracer registration does not appear to provide a stop hook: There is currently no such synchronization in either hypfs_trace.c or function_trace.c. >> --- /dev/null >> +++ b/xen/common/function_trace.c >> @@ -0,0 +1,274 @@ >> +static struct tracer function_tracer = { >> + .name = "function", >> + .init = function_tracer_init, >> + .reset = function_tracer_reset, >> + .clear_trace = function_tracer_clear, >> + .get_trace_size = function_tracer_get_trace_size, >> + .print_trace = function_tracer_print_trace, >> +}; > >For reference, tracing_set_on() in xen/common/hypfs_trace.c, introduced >by the preceding patch, disables recording with: > >> if ( tracer->stop ) >> rc = tracer->stop(&global_trace); >> } >> >> if ( !rc ) >> global_trace.tracing_on = on; > >Could an already admitted callback still hold a record slot when this >clear resets its CPU's counters? I see. Yes, the callback can still be running. >> --- /dev/null >> +++ b/xen/common/function_trace.c >> @@ -0,0 +1,274 @@ >> +static int cf_check function_tracer_clear(struct trace_context *tr) >> +{ >> + struct function_trace_cpu_buffer *buf; >> + unsigned int cpu; >> + >> + for_each_online_cpu ( cpu ) >> + { >> + buf = &per_cpu(function_trace_buffer, cpu); >> + buf->head = 0; >> + buf->written = 0; >> + } > >If that callback then finishes writing its old slot and updates head >and written, could the reset counters describe a different slot from >the one just filled? Could the print path likewise observe a partially >written record? Yes, I think both can happen. >The per-CPU recursion flag seems useful for nesting, >but wouldn't it leave these remote accesses unsynchronized? Yes, I added the flag only to prevent nesting. It does not solve the issues you raised. >Would a stop-and-drain protocol shared with callback removal let read, >clear, and reset operate only once the buffers are stable? Yes, I think extendeding the RCU read-side region which you suggested in your feedback to the patch 3/5 can be used here as well. I'll make sure callbacks are drained both when stopping tracing and when removing the callback. >There also seems to be a size-check consequence of a late writer: > >> --- /dev/null >> +++ b/xen/common/function_trace.c >> @@ -0,0 +1,274 @@ >> + for_each_online_cpu ( cpu ) >> + { >> + buf = &per_cpu(function_trace_buffer, cpu); >> + count = min(buf->written, (uint64_t)FUNCTION_TRACE_BUFSIZE); >> + size += count * FUNCTION_TRACE_RECORD_TEXT_SIZE; >> + } > >The existing hypfs_read() in xen/common/hypfs.c calculates the size and >checks the guest-provided length before calling the reader: > >> unsigned int size = entry->funcs->getsize(entry); >> [...] >> ret = -ENOBUFS; >> if ( ulen < size + sizeof(e) ) >> goto out; >> >> guest_handle_add_offset(uaddr, sizeof(e)); >> >> ret = entry->funcs->read(entry, uaddr); > >The trace_read() callback in xen/common/hypfs_trace.c then samples the >tracer size again, allocates that size, and later copies that amount: > >> size = tracer->get_trace_size(&global_trace); >> [...] >> buf = xzalloc_array(char, size); >> [...] >> if ( copy_to_guest(uaddr, buf, size) ) >> rc = -EFAULT; > >If a final callback increases written between these two size samples, >while the ring is not yet full, could the second size exceed the length >already checked for the request? Would an owned snapshot, or a shared >stable-size protocol, keep the checked length and copy consistent? Thank you for detailing the issue and the possible solution. Yes, the second size could exceed the first size. And to keep the size consistent, I'll make it to keep a snapshot following your suggestion in the next version. >Could the snapshot also use a stable CPU set? The sizing, clearing, and >iterator construction each traverse for_each_online_cpu(), and the >iterator retains buffer pointers while producing the output: > >xen/common/function_trace.c: >> @@ -0,0 +1,274 @@ >> + for_each_online_cpu ( cpu ) >> + { >> + const struct function_trace_cpu_buffer *cbuf = &per_cpu(function_trace_buffer, cpu); >> + struct buffer_iterator *iter = &iters[nr_iters++]; >> + >> + iter->buffer = cbuf; >> + iter->count = min(cbuf->written, (uint64_t)FUNCTION_TRACE_BUFSIZE); >> + iter->start = cbuf->written >= FUNCTION_TRACE_BUFSIZE ? cbuf->head : 0; > >For reference, get_cpu_maps() in xen/common/cpu.c uses the CPU-hotplug >lock rather than the HypFS lock: > >> bool get_cpu_maps(void) >> { >> return read_trylock(&cpu_add_remove_lock); >> } > >Would it make sense to pin the relevant CPU set while taking a snapshot, >and use that same snapshot for sizing and rendering? Yes, it makes sense. >What should happen >to records on a parked offline CPU? Could clearing only online buffers >allow its old records to reappear when that CPU comes online again? I see. I'll make the buffers to be clear based on cpu_present_map. I think this should prevent old records from reappearing when a CPU comes online again. >It looks like there is a design question of the stop-and-snapshot contract >to drain callbacks safely in their permitted contexts and preserve >one snapshot across HypFS's size check and copy. Locking each traversal >separately would still leave the gap between the two size samples. Understood. I'll make sure callbacks get drained, and keep a snapshot that can be used for both sizing and copying. >Thanks for checking these interactions. Is there an existing mechanism >that already keeps the buffers and CPU set stable across these steps? Thank you for your feedback. They are currently missing. I'll make sure they get fixed in the next version. Sincerely, Ryo Takakura From xen-devel-bounces@lists.xenproject.org Fri Oct 30 09:33:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 09:33:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465497.1676023 (Exim 4.92) (envelope-from ) id 1xMiz2-0002DF-Cz; Fri, 30 Oct 2026 09:33:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465497.1676023; Fri, 30 Oct 2026 09: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 1xMiz2-0002D8-7y; Fri, 30 Oct 2026 09:33:12 +0000 Received: by outflank-mailman (input) for mailman id 1465497; Fri, 30 Oct 2026 09:33:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMiz0-0002D2-SK for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 09:33:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMiz0-00CAPp-8m for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 10:33:10 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4644c-2eae-0a2a0a5409dd-0a2a450cb3fa-38 for ; Fri, 30 Oct 2026 10:33:09 +0100 Received: from [52.101.70.48] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae46455-f479-0a2a450c0019-346546307819-3 for ; Fri, 30 Oct 2026 10:33:09 +0100 Received: from AM0PR10CA0038.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::18) by CPHPR08MB883815.eurprd08.prod.outlook.com (2603:10a6:380:107::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.10; Fri, 30 Oct 2026 09:33:07 +0000 Received: from AMS0EPF0000056B.eurprd02.prod.outlook.com (2603:10a6:20b:150:cafe::38) by AM0PR10CA0038.outlook.office365.com (2603:10a6:20b:150::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.7 via Frontend Transport; Fri, 30 Oct 2026 09:33:07 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS0EPF0000056B.mail.protection.outlook.com (10.167.242.121) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Fri, 30 Oct 2026 09:33:07 +0000 Received: from DBBPR08MB4758.eurprd08.prod.outlook.com (2603:10a6:10:da::16) by VE1PR08MB5821.eurprd08.prod.outlook.com (2603:10a6:800:1b2::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Fri, 30 Oct 2026 09:32:31 +0000 Received: from DBBPR08MB4758.eurprd08.prod.outlook.com ([fe80::2a9f:d8ff:26ff:d54c]) by DBBPR08MB4758.eurprd08.prod.outlook.com ([fe80::2a9f:d8ff:26ff:d54c%4]) with mapi id 15.21.0546.021; Fri, 30 Oct 2026 09:32: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=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=bEA3YTw5KJk1zoSRCRvcvxykJE76nJ4HwRDGjrSDQlBR3XCP6iRHy64sQF/4CJJMzJNY0seb5TJQOGVWdyPblIPqlh3sODBqWuCekBm72UOSFaXEMeHUCZ24AWiYeJOKA11Ishvt080AZjmpRoSImDIV7PzK2PS9yJ4mxiP0pLx7kDyUvfAi4c+cUc93XSfmTi5nhHW/V4283M6zdfZQ2tJpCryQi94cnguEr/SzdFgueYnM6tRA8XYpyhGAaRm3m9vkpTRvgkECGkNQkwapKuUonULVfrHUC4T8Z0sUobluT1cnLSdebfnWsI87n783Jb+dk99fuU/grECFkP+QVA== 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=5FO/6dVE3HNPjmSjoSUjUYCjGOT9clWzW0SYiW5FxKE=; b=vkO2nWhg06IWYDH5wghFJk6583PtSY1z6ea2ypkB4TH5DapNUVx9iVDU/QZSdAx2mZRwgJcC367wMy9H9XiX8/NvzG0QqO7ioFwobp62o7nUaQhhpBv+K1eilzrMwENqMAOWiwMP5Uv03z0fgXL9bXKSoBr2t5iO5NNazPQ68xI5zy1UvajNXvzmn6YkslMYKTgmXVmU0lOdh+c/PE6JgBxiyZ9jgmoRK05ksxnirSVPftrtvnDr4GqFk2VKOSKE3xxAUZ+9x9KmUxSd2fNq1VmBgN/hIAvOh2iP10WnzLXDT0bJ31PB1gvrMVMMZMDLhAM4OYMt+HTb+0ftDkTdKg== 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=5FO/6dVE3HNPjmSjoSUjUYCjGOT9clWzW0SYiW5FxKE=; b=BSm1P5R1DMHy6TLMUhz25QxlldfsNfqhs8+inKPVQ9VdmK0wtPHn8xKeQNTh6qn6vj1w0TfEQRc/K9++lt5WWU84tlWK/POUS26nbMbjIgbQkeTBcJWOUVYgASQh+8/2GoH/trOdvzsEG/f5s9aP+3DrQCKCjzYQnuw+rIy6ebs= 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=XWJy/nATVWREoMgMeiLqV1m3f6sinoiRWHmjcuMpJ3/SSKaZxSyZHiuzTsurqWspK1arrUveW/3MYxK6O0wgrj3zknNsyInvy44+zk6bvPdCr3FCIkjEI48qZ93E8oZVLRER/5ljegmnZWi7GAzneusfwu9YjS2tng2wA/T/6IqdadcMwYkRVwQ6vyrDM04gVSfeWwsaWMkvWSe/r9Y+uwHz4LSleE2XodsCtSoa4hSAANj8wbmlbhQum+d6rRpwWenlVyQPWmJ1ceSaxJk7Gznfdignro+FS+nECtCafSvLyN97va1wY2E0L00UQULT+ai42qqEvzcLhD6LDr8oOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5FO/6dVE3HNPjmSjoSUjUYCjGOT9clWzW0SYiW5FxKE=; b=Oh/UC46nDchk9tNjpzyFkatJRlm4p7+pt439BYgGZfKRuf/8sD71vbGwcnxbjh7uWJm4wsd5T9FDQm14T3TgEWVhxDcAGvkuGM6zuwTB2DwFQarfzvy2g58sB9gP4yELWZe3VXZVEWFU1+akdXkJ/61pAvyLickactJ+K2/gpehUqWn1aL+Nlh525AgXPyDeA8wRzpykCeVHQDW6rKwH9sVZsWJt+oe4t/U0qi2CM2ErD9BNXeruqNTl5XE3L+IppcvQFTbdzRJ0VFJVE8lwKiIaWKbLSb5aXODRqH83wZs4j5+GKHoaWM4Ejt2Ksi1ye0Q1cEH5a86ETUmME05tag== 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=5FO/6dVE3HNPjmSjoSUjUYCjGOT9clWzW0SYiW5FxKE=; b=BSm1P5R1DMHy6TLMUhz25QxlldfsNfqhs8+inKPVQ9VdmK0wtPHn8xKeQNTh6qn6vj1w0TfEQRc/K9++lt5WWU84tlWK/POUS26nbMbjIgbQkeTBcJWOUVYgASQh+8/2GoH/trOdvzsEG/f5s9aP+3DrQCKCjzYQnuw+rIy6ebs= From: Bertrand Marquis To: Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Rahul Singh Subject: Re: [PATCH v6] xen/arm: smmuv3: Add support for removing devices Thread-Topic: [PATCH v6] xen/arm: smmuv3: Add support for removing devices Thread-Index: AQHdZhd6qHbitDeIwk6I1fMybh5L7LcV1vGA Date: Fri, 30 Oct 2026 09:32:31 +0000 Message-ID: References: <099ab694a01c3550e65853ed4cca06efd7043d68.1793107742.git.mykyta_poturai@epam.com> In-Reply-To: <099ab694a01c3550e65853ed4cca06efd7043d68.1793107742.git.mykyta_poturai@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.3) 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: DBBPR08MB4758:EE_|VE1PR08MB5821:EE_|AMS0EPF0000056B:EE_|CPHPR08MB883815:EE_ X-MS-Office365-Filtering-Correlation-Id: e5d194dd-7b9e-4d5f-281c-08df3668ce0c 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|366016|23010399003|1800799024|38070700021|11063799006|56012099006|261026140227099003|6133799003|18002099003|22082099003|261028144727099003|10067099003|261021121427099003|261009223027099003|261022105027099003|261022075727099003|261021123027099003|261026121527099003|260925021311599003|260925022911599003|260925021911599003; X-Microsoft-Antispam-Message-Info-Original: CCbrnpxDGWTPOYhNaK/eZ5USTm02IcvfuIFcgBRwpgpQ8UymIUVkjQmIhC29JPZvrlbvBotXNjw3O2l8zXb3esttDLYdZq39tICzVkbf5FpdKQKkpfB5Ld51Cyv6VQ9ERHRyeUl7+BALwCmnG9sTH004iNy4hh1lfBf/P2iVLJIOOst0/QH262MVSdeTqHNCzRRHYlmA4Xc2W39++RrY5gQyRBhclXH/rr076ag2cTj5Y9Lv8QaKguFsNZpfP4fzAVUgSuf222GE6SvCktSkoOTuYKzTlhoVnHFqXMWyi9crWv6PCk/QQWDIfEL3EA07QoUPIRdeoiFVKVYDP713F7rUMdVidm03oVyme5NemNWCQV6iLAe7Hs2KGu3ioc51pP5c7odq7ayZFA/ri/P3fYmLp7ilyV8R94EN9YwJEiLbTYBGrrE5sUuj3ezL8RVWeasYuLZ2dlaLWVtLxei2yAwR5zU0HnX5NCHBpTgbOrKJDJ18SLhxqneOZ60PbQjqsZnyME2TvCFu+4phwwL9zim3lZmOR6/GbQb5FRinBqX/3llqRqH9bsgXF2WDLfzIgSqC+Hmuv18QG1++xESIwvuFI+Q9q5uFE8Obte+kWJIn96LckE+1XsQ/M2J4triySGVAxI/cPp/aTS1llQzggeq02CXrN4MhY1rSjO61nDY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBBPR08MB4758.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(38070700021)(11063799006)(56012099006)(261026140227099003)(6133799003)(18002099003)(22082099003)(261028144727099003)(10067099003)(261021121427099003)(261009223027099003)(261022105027099003)(261022075727099003)(261021123027099003)(261026121527099003)(260925021311599003)(260925022911599003)(260925021911599003);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <68CEB219EB53BF459FE30FED46FC9D99@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: iwWmG2eQ8EZ9tlN4bTaK76sclTXZazhV+Y36hSRt6DOpsuuD5ttlIadGXPVqxkhGarCI9HnMtj47dF2Q7MXjPK5pHhxToN5eGYA048jDAJwUz9XSqHW7gqhMUgeJmytPtywFL2YnAFxTNTb2PUv9d59FaYTndy3Y3/56gfY1l90oAjQ72pisswksd+4e12AIizVTzdmJNxMyNHKIQDO5nBPCilmeMdqj++QOAMwS4vNy/7iPKVdZ8oF+DPr2vDD+ucCRgZLA8Uk6H6op5tgMxQzQ+J3qSUH45ZN5p3RH101rmtWiRu/J6Kbb0fvrBR9V0G+sK31KZKhL7lVl+3BgJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5821 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF0000056B.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ee5ec916-a58d-43e1-903e-08df3668b8e8 X-Microsoft-Antispam: BCL:0;ARA:13230040|35042699022|376014|23010399003|14060799003|36860700016|1800799024|82310400026|22082099003|18002099003|260925022911599003|260925021911599003|260925021311599003|10067099003|11063799006|56012099006|261021123027099003|261021121427099003|261022105027099003|261022075727099003|261026121527099003|261026140227099003|261028144727099003|6133799003|261009223027099003; X-Microsoft-Antispam-Message-Info: aSpc30YeLpbc4UL4LasFyTmNly2dlei0ocX0klRVpb5i5pSsUKX/ug+vkl91cqQnskKvyZUfhXAcUDfigjNeGgfkF9wvxhBpXoSWZXu8+6Eiv+XqBvA4c0GS4CLEg19s9+nQAkehHZ+Hu9Ssu/dL+Rjh9MmS29F9OzEAc2cs57ULKWYpo2m7rYYJG/SAuPzN4GJtLmMNHgsdVUiEZEI3ekiu2BYjGix2hKRVxwEh/5cfj7FRAlEo8iq/dZ6aAFaNnCsznMfeSQJL1H7tDc4awdw59Ztd3fYrg1ibq8BUT24TcNa+FmBkQS5JEe6KfpM+bo7PXnvP+NLIj0DmYidGxflx9XAljrQjmzJ3A8Zb6N80Ir7H5cK492ijdCAznJEa/eRnYJtlcIe7v8IHfg7h5hQwdrybEBnRP2JGxKjQNBCOeG+4UZ+M056Dht0GAHS9KtfXEyxjgMgiRIKWbyyw40sVtKQZmhpju/ob9GuXFFiC8ttCSnhc+K7SVrQe9RpGtB3XN86ylsEshvrSjAqIFcrEY08dqlwjPpgXbiqWa57y5QiunBZXie/rp36A2G3pSRvtFGg4A8wW5Q06X8ldU5Cp5ypew/0V/XE0sGn2pclKjgXkuajCD8VqEJsPNvoBARMBllayFkNImJrQbgi++Q== 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)(35042699022)(376014)(23010399003)(14060799003)(36860700016)(1800799024)(82310400026)(22082099003)(18002099003)(260925022911599003)(260925021911599003)(260925021311599003)(10067099003)(11063799006)(56012099006)(261021123027099003)(261021121427099003)(261022105027099003)(261022075727099003)(261026121527099003)(261026140227099003)(261028144727099003)(6133799003)(261009223027099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: XNs6s1EcNCY76rmzXs0IiyPxuoXVu6w2qdX7ctuwll+P/fIqEJGfJxZVLRNp0l7GH6wvuf11+GOnQlz71N1AdVooqiQ2Fg4a5O8oB1mn8RX52SoYWQu+WJkXlgW0lBbrlCqY2+J3lW0QjCUt8hDWSBSqgkHNCuzoZ07t7Dqp0pXOxFQ/1ftD8uNqHEAPdTVHoqFzu3hPJbFFZw8a6JE9jnRqThva7Z8MI9/hLkJNw77HQxh2t9P2gu/j84+GDfsU29U/9R3N+HpdS/eV4vHmRFD3BI50DNpkP7JTLyV6MC9EaBxYMPBtg7EEGOT5J+ZP5iRiJh9D8T4ZQGi6sU5oZ1+PSREWLY9SfJyZ3YnGx9ruAivIKvs4BZ0I2yoeUWSfOZJR5q2auKjcOLA6OnHe8FelnFnRhQEt/KIyM52sFFsK7zlwS49Ef1c/4P11/7ku X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2026 09:33:07.0266 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e5d194dd-7b9e-4d5f-281c-08df3668ce0c 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: AMS0EPF0000056B.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPHPR08MB883815 X-purgate-ID: tlsNG-d25034/1793352789-5073FA5B-C96268DD/0/0 X-purgate-type: clean X-purgate-size: 6879 Hi Mykyta, > On 27 Oct 2026, at 14:31, Mykyta Poturai wrote: >=20 > 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. >=20 > Rework dt_device_set_protected to accept a boolean parameter, update > callsites. >=20 > Signed-off-by: Mykyta Poturai > Reviewed-by: Michal Orzel For SMMU side of things: Asked-by: Bertrand Marquis Cheers Bertrand > --- >=20 > Tested on QEMU with SRIOV series[1] by repeatedly enabling/disabling > VFs. >=20 > [1]: https://patchew.org/Xen/cover.1772806036.git.mykyta._5Fpoturai@epam.= com/ >=20 > V5->V6: > * move deassign and disable_pasid into the PCI branch > * set dev_iommu_priv to NULL for DT devices only > * collect RB >=20 > V4->V5: > * drop dead domain lookup on the DT path > * remove assert on arm_smmu_deassign_dev error > * drop redundant IS_ENABLED(CONFIG_HAS_PCI) > * fix indentation >=20 > V3->V4: > * s/u8/uint8_t/ > * assert pcidevs_locked > * assert deassignment is only reachable by PCI > * fix build error with HAS_PCI=3Dn >=20 > V2->V3: > * free fwspec for pci devices > * remove testing note from commit message >=20 > 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 | 60 +++++++++++++++++++++++- > xen/drivers/passthrough/arm/smmu.c | 4 +- > xen/include/xen/device_tree.h | 5 +- > 4 files changed, 65 insertions(+), 6 deletions(-) >=20 > diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passt= hrough/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) > } >=20 > /* 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/passthro= ugh/arm/smmu-v3.c > index bf153227db..232df2421c 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -1493,6 +1493,63 @@ static int arm_smmu_assign_dev(struct domain *d, u= 8 devfn, struct device *dev, > static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn, > struct device *dev); >=20 > +static int arm_smmu_remove_device(uint8_t devfn, struct device *dev) > +{ > + struct arm_smmu_master *master; > + struct iommu_fwspec *fwspec; > + > + fwspec =3D dev_iommu_fwspec_get(dev); > + if ( !fwspec ) > + return -ENODEV; > + > + master =3D dev_iommu_priv_get(dev); > + if ( !master ) > + return -ENODEV; > + > +#ifdef CONFIG_HAS_PCI > + if ( dev_is_pci(dev) ) > + { > + struct pci_dev *pdev =3D dev_to_pci(dev); > + > + /* Ignore calls for phantom functions */ > + if ( devfn !=3D pdev->devfn ) > + return 0; > + > + ASSERT(pcidevs_locked()); > + > + if ( arm_smmu_deassign_dev(pdev->domain, devfn, dev) ) > + dev_err(dev, "Removing anyway\n"); > + > + arm_smmu_disable_pasid(master); > + } > + 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); > + dev_iommu_priv_set(dev, NULL); > + } > + > + dev_info(dev, "Removed master device (SMMUv3 %s StreamIds %u)\n", > + dev_name(fwspec->iommu_dev), fwspec->num_ids); > + > + xfree(master); > + > + /* > + * For DT devices the fwspec is freed by iommu subsystem, but for PCI > + * devices we need to free it here > + */ > + if ( dev_is_pci(dev) ) > + iommu_fwspec_free(dev); > + > + return 0; > +} > + > static int arm_smmu_add_device(u8 devfn, struct device *dev) > { > int i, ret; > @@ -1571,7 +1628,7 @@ static int arm_smmu_add_device(u8 devfn, struct dev= ice *dev) > } >=20 > /* 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); > } >=20 > dev_info(dev, "Added master device (SMMUv3 %s StreamIds %u)\n", > @@ -2867,6 +2924,7 @@ static const struct iommu_ops arm_smmu_iommu_ops = =3D { > .unmap_page =3D arm_iommu_unmap_page, > .dt_xlate =3D arm_smmu_dt_xlate, > .add_device =3D arm_smmu_add_device, > + .remove_device =3D arm_smmu_remove_device, > }; >=20 > static __init int arm_smmu_dt_init(struct dt_device_node *dev, > diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough= /arm/smmu.c > index d63c901551..4d2f71f152 100644 > --- a/xen/drivers/passthrough/arm/smmu.c > +++ b/xen/drivers/passthrough/arm/smmu.c > @@ -825,7 +825,7 @@ static int arm_smmu_dt_add_device_legacy(struct arm_s= mmu_device *smmu, > if ( !dev_is_pci(dev) ) > { > /* Xen: Let Xen know that the device is protected by an SMMU */ > - dt_device_set_protected(dev_node); > + dt_device_set_protected(dev_node, true); > } >=20 > for (i =3D 0; i < fwspec->num_ids; ++i) { > @@ -862,7 +862,7 @@ static int arm_smmu_dt_remove_device_legacy(struct ar= m_smmu_device *smmu, >=20 > if ( !dev_is_pci(dev) ) > /* Protected by dt_host_lock and dtdevs_lock as caller holds these lock= s. */ > - dev_node->is_protected =3D false; > + dt_device_set_protected(dev_node, false); >=20 > kfree(master); > return 0; > diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.= h > index 06d7643622..76ae1e674a 100644 > --- a/xen/include/xen/device_tree.h > +++ b/xen/include/xen/device_tree.h > @@ -300,9 +300,10 @@ static inline domid_t dt_device_used_by(const struct= dt_device_node *device) > return device->used_by; > } >=20 > -static inline void dt_device_set_protected(struct dt_device_node *device= ) > +static inline void dt_device_set_protected(struct dt_device_node *device= , > + bool protected) > { > - device->is_protected =3D true; > + device->is_protected =3D protected; > } >=20 > static inline bool dt_device_is_protected(const struct dt_device_node *de= vice) > --=20 > 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 09:45:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 09:45:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465511.1676030 (Exim 4.92) (envelope-from ) id 1xMjBJ-0004HP-Gd; Fri, 30 Oct 2026 09:45:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465511.1676030; Fri, 30 Oct 2026 09: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 1xMjBJ-0004HI-Dv; Fri, 30 Oct 2026 09:45:53 +0000 Received: by outflank-mailman (input) for mailman id 1465511; Fri, 30 Oct 2026 09:45:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMjBI-0004Gw-1Y for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 09:45:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMjBH-0017hu-40 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 10:45:51 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae46749-bab6-0a2a0a5309dd-0a2a4503e03c-22 for ; Fri, 30 Oct 2026 10:45:50 +0100 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 6ae4674e-fae8-0a2a45030019-b9ff1c22b21d-3 for ; Fri, 30 Oct 2026 10:45:50 +0100 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 1a18c337b6e000cae1.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 09:45:46 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 7AFAE8279E; Fri, 30 Oct 2026 10:45:45 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=wqO1UgNdwJ9EoOMNCjkXFiohe5izNhb3KkYp0DfjGrg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=mpXlaIMyZM4bY4rheZUtXs/TVH8vlfrFE616QuaibXXJOSUnUPmLev8Ftlb4QVl3LQD2gxZlZ xFKP3MzgSodlRADGXkQ77PFItYBoNpvPfb6LdmWMVE1WgfCNvMEKdgpp6LHtZ+1X8FZHmnOo79l wzT8I83uHjs6LRIrens8KNxbmkF9naWQ967Kuvdjpk7rFLV3j52tjK5aFRLw6rchknMsNMztxqI 4jEe7lghAQscRb3/8D93SC9wzWfi6husnBZL0Aj8Fo52TDTd7BNuHrtMTIFfSgdaX/GDq3gVKDs FyC1yhUVY6FnSTmYzNsgy/ms4ZgQrMLI/RnXVUlHsPmQ== X-Zone-Loop: 94b74e54d6bb88b4e0d7de560141b257df29659af11f x-campaign-type: default x-transaction-id: 3d682fc2-95f0-4f59-89ee-7c65051fee8d x-swg-uid: 01-0462a8db-5c33-4341-adfa-12c19d26f8f5 X-Mailer: Sweego Message-ID: <1793353546.8631fc262581453bbf619ec5b2062170.1a18c337b6e000cae1@vates.tech> x-swg-bid: 1793353546.8631fc262581453bbf619ec5b2062170.1a18c337b6e000cae1 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: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Julian Vetter Subject: [PATCH v3 0/1] xen/arm: populate a default P2M pool for new domains Date: Fri, 30 Oct 2026 10:45:34 +0100 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.311.fa1bda8342d9022b.1a18c3378e2.220c8c85418590b8=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793353545955 X-purgate-ID: tlsNG-33051d/1793353550-754844E9-CB016A3B/0/0 X-purgate-type: clean X-purgate-size: 1072 ---=Part.311.fa1bda8342d9022b.1a18c3378e2.220c8c85418590b8=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michal, thanks again for your review=2E As you suggested, I went with a fixed default of 256 pages (1MByte), as x86 HAP does in hap_enable()=2E This keeps the allocation bounded and seems like a sane value=2E The toolstack or dom0less, anyway set the full size later=2E Then my new helper domain_p2m_default_kb() goes away, which then also addresses your other two comments=2E The patch now only touches xen/arch/arm/mmu/p2m=2Ec again, just like v1=2E Signed-off-by: Julian Vetter Julian Vetter (1): xen/arm: populate a default P2M pool for new domains xen/arch/arm/mmu/p2m=2Ec | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.311.fa1bda8342d9022b.1a18c3378e2.220c8c85418590b8=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 30 09:49:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 09:49:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465518.1676040 (Exim 4.92) (envelope-from ) id 1xMjEc-0005B7-UF; Fri, 30 Oct 2026 09:49:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465518.1676040; Fri, 30 Oct 2026 09:49: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 1xMjEc-0005B0-Qn; Fri, 30 Oct 2026 09:49:18 +0000 Received: by outflank-mailman (input) for mailman id 1465518; Fri, 30 Oct 2026 09:49:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMjEb-0005Au-3S for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 09:49:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMjEa-008Q6p-Cy for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 10:49:16 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae46810-8faa-0a2a0a5109dd-0a2a4501ac8c-36 for ; Fri, 30 Oct 2026 10:49:16 +0100 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 6ae4681b-5984-0a2a45010019-b9ff1c229eb3-3 for ; Fri, 30 Oct 2026 10:49:16 +0100 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 1a18c369323000cae1.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 09:49:09 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 49EF8820C8; Fri, 30 Oct 2026 10:49:08 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=4S4x9uJISY6OZNhEpNG6U0qgVxMfzMivSsrG54a80SI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=SolBV1cBnULlCDxDdlry9WhCx9H06S8mj7czZbMZiZ+rOw4eCszx/+9xj7bcfPNL9BTqCszWl 1UtE2xXVYlSTN+SrEYCaCjBU9DMK+jOUym0+mK8mUbFZjxhlPuYoLUfxc7XVDz/q/Lon/6/sdl5 msG6KCyFpfqBT9QZFVn6ZRgPg2sPo0ihMtYH/kh4vsLrOQMR75MSZBtBW7R5uJnjfbkFyIjRL19 vBocoEymvr8pR0LBS25Jdm8/tpnnGBQMx0xim5ko7xt8ttoXVYpuXLt7oGwDr96IbUmbgbfTrH4 lySrGWYLchq2/6RaR3cjnP9XKtADUQKsGN2Pdgnj+R8Q== X-Zone-Loop: 0847c501746e4e27bae7bd4aac9d5516b3611dee3c0f x-campaign-type: default x-transaction-id: 5d8eba6a-ab2a-468b-ae01-4b8c103c7a0e x-swg-uid: 01-a981b766-31b1-406a-80c2-73e2c5810315 X-Mailer: Sweego Message-ID: <1793353749.8631fc262581453bbf619ec5b2062170.1a18c369323000cae1@vates.tech> x-swg-bid: 1793353749.8631fc262581453bbf619ec5b2062170.1a18c369323000cae1 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: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Julian Vetter Subject: [PATCH v3 1/1] xen/arm: populate a default P2M pool for new domains Date: Fri, 30 Oct 2026 10:49:01 +0100 In-Reply-To: <1793353546.8631fc262581453bbf619ec5b2062170.1a18c337b6e000cae1@vates.tech> References: <1793353546.8631fc262581453bbf619ec5b2062170.1a18c337b6e000cae1@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.314.55c39cd100e6c943.1a18c3690dd.2facb68d8a81c68d=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793353748701 X-purgate-ID: tlsNG-d62444/1793353756-C5341757-8019050C/0/0 X-purgate-type: clean X-purgate-size: 3280 ---=Part.314.55c39cd100e6c943.1a18c3690dd.2facb68d8a81c68d=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On x86, a domain can be populated directly after the XEN_DOMCTL_createdomain call=2E Sizing the pool is thus an optional tuning step for the toolstack (libxl: "the Xen minimum is for safety, not performance")=2E On ARM however, the P2M pool of a non-hardware domain starts empty=2E So, any toolstack must size the pool before populating the domain's physmap, otherwise no P2M tables can be allocated=2E This is an ARM specific step, which every toolstack has to know about=2E Instead, populate a default pool of 256 pages (1MByte) in p2m_init(), matching what x86 HAP does in hap_enable()=2E The size is intentionally fixed, because p2m_init() isn't preemptible, so the allocation must stay bounded=2E Then dom0less and libxl set the full size, as they do today=2E Skip the hardware domain, which has no dedicated P2M pool=2E Also skip LLC colored setups, as the domain's colors are only configured after domain creation, so the pool pages would be allocated with the default colors=2E Signed-off-by: Julian Vetter --- Changes in v3: - Use a fixed default of 256 pages, as x86 HAP does - Drop the domain_p2m_default_kb() helper and the dom0less change - Adapt the commit message to explain why a fixed size is used Changes in v2: - Size the default pool based on the exisiting formula - Rewrite commit message to explain why a default pool is desirable --- xen/arch/arm/mmu/p2m=2Ec | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/xen/arch/arm/mmu/p2m=2Ec b/xen/arch/arm/mmu/p2m=2Ec index 70d7c9fed9=2E=2E9579e905d8 100644 --- a/xen/arch/arm/mmu/p2m=2Ec +++ b/xen/arch/arm/mmu/p2m=2Ec @@ -3,6 +3,7 @@ #include #include #include +#include #include #include =20 @@ -1555,6 +1556,26 @@ int p2m_init(struct domain *d) if ( rc ) return rc; =20 + /* + * Populate a default of 256 pages (1MB) to the P2M pages pool here, = as + * x86 HAP does=2E So, the domain is usable without the pool being si= zed + * first=2E The toolstack, or dom0less, still sets the full size late= r, + * taking the domain's RAM into account=2E A fixed size keeps this + * non-preemptible allocation bounded, independent of the number of v= CPUs=2E + * + * Skip the hardware domain, which has no dedicated P2M pool, and LLC + * colored setups, as the domain's colors are only configured after d= omain + * creation=2E + */ + if ( !is_hardware_domain(d) && !llc_coloring_enabled ) + { + spin_lock(&d->arch=2Epaging=2Elock); + rc =3D p2m_set_allocation(d, 256, /* can_preempt */ false); + spin_unlock(&d->arch=2Epaging=2Elock); + if ( rc ) + return rc; + } + return 0; } =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.314.55c39cd100e6c943.1a18c3690dd.2facb68d8a81c68d=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 30 10:31:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 10:31:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465539.1676056 (Exim 4.92) (envelope-from ) id 1xMjtW-0004Tl-Q9; Fri, 30 Oct 2026 10:31:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465539.1676056; Fri, 30 Oct 2026 10: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 1xMjtW-0004Te-N1; Fri, 30 Oct 2026 10:31:34 +0000 Received: by outflank-mailman (input) for mailman id 1465539; Fri, 30 Oct 2026 10:31:33 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMjtV-0004TY-4n for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 10:31:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMjtU-002Xxc-HJ for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 11:31:32 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae47203-bab6-0a2a0a5309dd-0a2a4501912a-10 for ; Fri, 30 Oct 2026 11:31:32 +0100 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae471fc-5984-0a2a45010019-d155802de1b6-3 for ; Fri, 30 Oct 2026 11:31:24 +0100 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4a7992e2f7dso5057805e9.3 for ; Fri, 30 Oct 2026 03: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-4aa813d2950sm126960505e9.8.2026.10.30.03.31.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Oct 2026 03: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: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=1793356284; x=1793961084; 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=deRLmB/n79/Yd5s8hISompFCxEi2gPTUo3fHtmadflo=; b=Zr+4CBtFX0117q/Z/hQBgtuhFNZ5GRaDw+naBk/L8urSav2R+SPljGDWkGnpLCY27G /2cjUaOoiwJV73sl1deu+1tz7uK60YGn2XxsnOP23IT1nYVJr/wMinCfh/QNMCt/udU7 r8jZh4s96JHbQiLF16Zc4Rzv4oksxteluHunipCRFntFytcMSVcSKt8XWKP6n74l+PwW +JFHX53UaRp8mXm6Ad0GpEcHggNnH4v1tExRC697ejjdU6tNyz3wabeJlWlI8Ayprflk //Y0UUQaC51yJoDWB69o526WLIlX+DY1ZQFjf2015cX4zTY1s9XzYqEmxQW2WWHDshgx kxOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793356284; x=1793961084; 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=deRLmB/n79/Yd5s8hISompFCxEi2gPTUo3fHtmadflo=; b=2QHV6kDdD6g2+uXTL5FjOXB1DuYcsF2bM9T7oiP/0rV+gYCvMCNeFd9+Y0ib5J62GX Kuz8XUyudheCCje5U+ceKxn6if5zStefSHrsiL5lQKNlsjmxKSMDZFJciri3SEuLyNVd UT5m6A6wZvW9TqM9m0vyJJX9kFJL3SfZ249AAxiBIgNMCIH48cKJN1Rn16p/YIk0Chxu +BNkdOM9wNeNmDgMh9mUH6qZ9MomceiwCLMsFGscy7c4uE4IyyY8mLUK4VLWbYzY89xv LIDn30h05+sTSySnwCU9TwpedXDRfz/EsDwxGnoYqa9a3xgQQlr6pOQ53L+GSOnKo8gm rJwQ== X-Gm-Message-State: AFq9FYIPuXp7KIuBJdt5jVfaoCss4ldSX8KNgtvCjcoEQfQUUhTRPEft wObitD7EcbmmX+QlJTrcHKofeClQi7iGnlt1hDxLa3+n1X/YPBsJNXdKBY4fw+gTqhDbwnB+dRD bQaRpfQ== X-Gm-Gg: AYBFou2ks7+ht7utGgAb1r0Ryg++gEdox0dyRI63f1Zi+NmaiqbspQFC0ZzhWxendKK oilCZBzkAsbF2yhXgqdmBiu5rN/puoqV4cjbwFav/1yvtLL66DKTnFlulDIWwpuqBgWpl7ivB76 pK42Uyeh8U0H9ROkVjaRQbHPGpqNy0/nK8XvMC10Pt+cWLzbc4BELxfyJNbx0T6ebKNIDcabtEz hGwkLLg22Zabbj0uQBzvJH1QXQ/Cf7zac38k++4j0jICjXrpjpelJBQy6c3nZoiVqTsbws7S/GF QImqVIaNDMwatMg6UrKiPTGwlllXH1zVDoQEPi7+Mqa+kRGSuO1frMjwwBCkus2VzlG6VFX/kXj h9DYTfgimNY6XDO44RG91GnIwvTIQNN/1vW409/US7yCYgma+zM8K0LGpZ9x7D/CzqIBfx+zQZi a4Xo5dMTqResdBVq7c1SqPiI/9myaHkBxBGkHPeKwpBOV0ura3vzQ7bbe8qOIkU54a2ew+GhB8+ bhSrA1VoGiwYS0sEUZJbPqFbxCOjyXyu58Yi7Pw6rFyv/JSNlrxz4ASuf51tAilMfmcmoSWjfIh S6utVGXA1qyTd2Pcb5/CBUDEWj+HyniHrvc8MJTqXBPMQ3dsyRlvn5pmzDLxcMJg7tg4b1eJ2QW v4Rw9Jqnin7jd1EEx X-Received: by 2002:a05:600c:6214:b0:4a2:9cda:57cb with SMTP id 5b1f17b1804b1-4ac151a9077mr42569745e9.1.1793356284018; Fri, 30 Oct 2026 03:31:24 -0700 (PDT) Message-ID: <7028568e-8b24-417e-9fe8-f0a4d4f8b0a6@suse.com> Date: Fri, 30 Oct 2026 11:31:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 0/5] Introduce dynamic tracer using Livepatch To: Ryo Takakura References: <20261023044809.162759-1-takakura@valinux.co.jp> 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: <20261023044809.162759-1-takakura@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1793356284-C5146757-2B58B600/10/78276251493 X-purgate-type: spam X-purgate-size: 1883 On 23.10.2026 06:48, Ryo Takakura wrote: > Ryo Takakura (5): > xen/arm64: livepatch: enable attaching callbacks > xen/livepatch: Allow tracers to schedule livepatch > xen/tracing: prepare a livepatch payload and its controling interface > xen/tracing: Add a function tracer > xen/x86: livepatch: enable attaching callbacks > > xen/arch/arm/Kconfig | 13 + > xen/arch/arm/arch.mk | 3 + > xen/arch/arm/arm64/Makefile | 1 + > xen/arch/arm/arm64/insn.c | 5 + > xen/arch/arm/arm64/livepatch-asm.S | 68 +++ > xen/arch/arm/arm64/livepatch.c | 39 ++ > xen/arch/arm/include/asm/arm64/insn.h | 1 + > xen/arch/arm/xen.lds.S | 5 + > xen/arch/x86/Kconfig | 13 + > xen/arch/x86/Makefile | 1 + > xen/arch/x86/arch.mk | 3 + > xen/arch/x86/livepatch-asm.S | 60 +++ > xen/arch/x86/livepatch.c | 33 ++ > xen/arch/x86/xen.lds.S | 5 + > xen/common/Kconfig | 12 + > xen/common/Makefile | 6 + > xen/common/function_trace.c | 274 ++++++++++ > xen/common/hypfs_trace.c | 743 ++++++++++++++++++++++++++ > xen/common/livepatch.c | 137 ++++- > xen/include/xen/hypfs_trace.h | 42 ++ > xen/include/xen/livepatch.h | 14 + > xen/include/xen/livepatch_payload.h | 7 +- > 22 files changed, 1478 insertions(+), 7 deletions(-) > create mode 100644 xen/arch/arm/arm64/livepatch-asm.S > create mode 100644 xen/arch/x86/livepatch-asm.S > create mode 100644 xen/common/function_trace.c > create mode 100644 xen/common/hypfs_trace.c > create mode 100644 xen/include/xen/hypfs_trace.h Nit: Dashes in favor of underscores please in new files' names. Jan From xen-devel-bounces@lists.xenproject.org Fri Oct 30 11:05:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 11:05:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465554.1676066 (Exim 4.92) (envelope-from ) id 1xMkQE-0000y8-6b; Fri, 30 Oct 2026 11:05:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465554.1676066; Fri, 30 Oct 2026 11:05: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 1xMkQE-0000y1-3c; Fri, 30 Oct 2026 11:05:22 +0000 Received: by outflank-mailman (input) for mailman id 1465554; Fri, 30 Oct 2026 11:05:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMkQD-0000xv-CI for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 11:05:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMkQC-00GVjB-IA for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 12:05:20 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae479ed-e002-0a2a0a5209dd-0a2a4509884c-22 for ; Fri, 30 Oct 2026 12:05:20 +0100 Received: from [52.101.56.13] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae479e9-be1a-0a2a45090019-3465380d9239-3 for ; Fri, 30 Oct 2026 12:05:14 +0100 Received: from BN9P221CA0020.NAMP221.PROD.OUTLOOK.COM (2603:10b6:408:10a::32) by PH7PR12MB6441.namprd12.prod.outlook.com (2603:10b6:510:1fb::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Fri, 30 Oct 2026 11:05:07 +0000 Received: from BN3PEPF00022BC1.namprd04.prod.outlook.com (2603:10b6:408:10a:cafe::1d) by BN9P221CA0020.outlook.office365.com (2603:10b6:408:10a::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.7 via Frontend Transport; Fri, 30 Oct 2026 11:05:07 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF00022BC1.mail.protection.outlook.com (10.167.248.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Fri, 30 Oct 2026 11:05:07 +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.53; Fri, 30 Oct 2026 06:05:05 -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.53; Fri, 30 Oct 2026 06:05:05 -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.53 via Frontend Transport; Fri, 30 Oct 2026 06:05:03 -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=V/haRyWrQI/TsXQmqnJRydgIR+Y9UF8fLV0YWMTgMxSYs+8Zdv8qJLMG6ViG5H/ZbV0WDKjSuWsJ8jDcmm7O2e8fXwak/NZ6VN/vvoVnqoBhauVPtcN19aVJgrtWL+6elHpCeYzZbp1kU6L9eRIZM6cIK7eOAgU2GLrLgR/CtxrqqmgLRttUtVck7diTgpZuT2p+TdVA4RoRlGUPw6jGkU7gsApLqRGaRBTEg35uwlgW2V5/mxbX3jXB34S/8Bnab3jRgqoylV8QsEcBHlhIchLNo0yZw7xPa2SKrA+//g9AJYzUKJvz+qJQCI/24gofm7Ejd2OQ0qsYi7rFFjk/cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YgGSe5eZc8SlUXO4dgxVFymdQe2k8NNy8kYwGxCq9/I=; b=tIeV/2cAf1lc935jso1Tnj/ZFMfS+y7QwtiFabc5/TmZtXJ4tpMVRNuWW1HEt34stiD60fxpfVaMYDDDhANujhTYXn/7EuS4jr+KDEHnHeny/Mp5K4pYBKZc7OMZRoEB3hhDLpsabYzHiCnr6Rm5R3i4r+ZTvRF3+m7FCa79npHBVkNa7nr1Cr66MMvwdo+EXqAIgmKNcdqOJJI10znr/xHyvuFPGNFb/PcsWszuE4DDvOicNy90+2JaULrv7XtEUCSlrIsO5JNMzd1srWSj1v3UEgHU/XaUNWeQ8lYK3QfmBKynFWmpHFgBhHtXYXAZN7wUs+HUCj8N1rzzn9zy7w== 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=YgGSe5eZc8SlUXO4dgxVFymdQe2k8NNy8kYwGxCq9/I=; b=dvdCG35Rdcf2ckSGFpxKGCBmPRaPip0ptBdJSOwByGM+278MGdMXa+0sWFnO3TB9nVin0u+6VqPZOK8hGL1+/kWumA03S7g8XGhZJb7Az72Hqd5Xr2zBaaIrscdkCNIsVAt+wHKWlMMMxQn6uYbckooPfi99XSt2kTiO5lAktIk= 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: Fri, 30 Oct 2026 12:04:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/dt: Skip non-RAM reserved-memory regions in make_memory_node() To: Kuan-Wei Chiu , CC: , , , , , References: <20261028211737.17629-1-visitorckw@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20261028211737.17629-1-visitorckw@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BC1:EE_|PH7PR12MB6441:EE_ X-MS-Office365-Filtering-Correlation-Id: d4db8161-aafd-4f89-1c4d-08df3675a857 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|23010399003|376014|1800799024|22082099003|18002099003|56012099006|11063799006|261028144727099003|261021123027099003|261021121427099003|261026121527099003|261009223027099003|261022105027099003|261026140227099003|10067099003; X-Microsoft-Antispam-Message-Info: yYthCAqnN2LbsIMIpo4iQ3Q+CgaloQIva15oQIiH8BFBVzEjCmIQRpnSwD4SAmCAVR+R06GPO4ur2Vd/FU5AAU5ttpN5a95EoJmNa29jMyYF64DgFPBDE6WJwMf43i4h5yuc9GA9/Ypv98NZtN2Vuv0r0Zl0/4labHQNu1DK3LFz0TTqDqETjlMrPLzSFl1YirRfTqHIslTC4Kje3ratNmzIe81fsBFyUCRT7G12MiiJKazBfxNWv5BmbtQF8d9TYqqk2liobAMP37xUns/APYF+76IQr/srvuLybAONqZA+g/GfiuG85F2af0aJPAGeoZxWcJ/lbfWYJquJ+2jEqCZr8nlbLgTcUm/Cdz/n0a+tT3Afo6x7GXrIND1/rsV5OiWTEKDDRA3T2GYFRh1wBMalp54tKOc0muOXiZLBg2iJxd4kyh0l0rQWJhGZZBm0QuVc0FhRXB1iY7lyw+rX79xDXzqeQgmINiiWSGrwVi7i1+CibbWwpZZkLWYC0sZlCxeWzJqoUdNCAtj6PtH5PYMUAGlrVrlNAnjbCQLEzvNKC7Y08gBPCY0595a3219Cg1OqqVt8y0CuujVjDqJXwznhOBdiNsU/EnIZJ10b6WssP0hJF0ZeA1fXJkMKIQ5S5etLEfOBTBXa4ky8tnpPsJaqe0F4tVxC1+knTGIaWjSHtrjp5a26VU4I9Z4COo+tOI3SbTnrgD2VkF9Yn/v8Lw== 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)(23010399003)(376014)(1800799024)(22082099003)(18002099003)(56012099006)(11063799006)(261028144727099003)(261021123027099003)(261021121427099003)(261026121527099003)(261009223027099003)(261022105027099003)(261026140227099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: QJA1s32+LzoGY7uQIZRhmfa5CYPwAAblWw0mS653o4d9/dPp3yonBpqjsFFAlPqeGit5AzFxS3nZophDZyaHX3OSdBqDw4+KBqAvlFpT1HE72JEaS3ogQKSY1vR9EvBm8OOSnw7jR00XnCSy+b6IVIBzlaBoWtQlBwqSM5RJtBCxQsvGDz5F4Cx6hg8tw4vJkFq4lt4c4BvqPSfKEcxsUdn6J1DhTEil4osYEAB9BSUNcBK6RGCZwFMoZi/VtAl/CbMhc5/4NXmL03wo+IS6ApypqtHszz2tua5d+n+jx7Xa2YJD5qHYXmLDkLX4hzSgW1uXm+5bgcq4C8m0J53eGyT3ghWn89EX8wn3rcPR7ShczC4RMen82W5NyFqW3PAdA4+AJ7/GXQRP4hxhTyt/4B6QgYo29TGjeJ6BtxAfwBmVtqi4rBb7B2/fhJcMDSx6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2026 11:05:07.2836 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d4db8161-aafd-4f89-1c4d-08df3675a857 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: BN3PEPF00022BC1.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6441 X-purgate-ID: tlsNG-bad1c0/1793358319-BC6CA034-A67FE3A5/0/0 X-purgate-type: clean X-purgate-size: 3913 On 28-Oct-26 22:17, Kuan-Wei Chiu wrote: > Xen creates a second /memory node for Dom0 from > bootinfo_get_reserved_mem() without checking whether those regions > belong to host RAM. However, /reserved-memory can also describe > on-chip SRAM or firmware regions outside system RAM. Listing them in a > /memory node causes Dom0 to register non-RAM addresses as system RAM, > conflicting with device MMIO mappings. Hmm, I always thought that /reserved-memory is to exclude regions from memory described under /memory. That's what Xen assumes too. map_range_to_domain() for example does not call iomem_permit_access() for such regions because we assume it's RAM. Can you provide more details of your board e.g. the device tree? Is there any documentation I could use to confirm that "reserved-memory can also describe on-chip SRAM or firmware regions outside system RAM"? ~Michal > > Skip reserved-memory banks outside the host RAM banks reported by > bootinfo_get_mem() in make_memory_node(). > > Fixes: 248faa637d2f ("xen/arm: add reserved-memory regions to the dom0 memory node") > Signed-off-by: Kuan-Wei Chiu > --- > Found while trying to bring up Xen on new hardware. > Tested on real silicon. > > xen/common/device-tree/domain-build.c | 42 +++++++++++++++++++++++++-- > 1 file changed, 39 insertions(+), 3 deletions(-) > > diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c > index 30a59abfa7..33baf150a6 100644 > --- a/xen/common/device-tree/domain-build.c > +++ b/xen/common/device-tree/domain-build.c > @@ -504,6 +504,34 @@ int __init make_chosen_node(const struct kernel_info *kinfo) > return res; > } > > +static bool __init is_in_host_ram(const struct membank *bank) > +{ > + const struct membanks *ram = bootinfo_get_mem(); > + paddr_t start = bank->start; > + paddr_t end = start + bank->size; > + unsigned int i; > + > + if ( !bank->size || end < start ) > + return false; > + > + for ( i = 0; i < ram->nr_banks; i++ ) > + { > + paddr_t ram_start = ram->bank[i].start; > + paddr_t ram_end = ram_start + ram->bank[i].size; > + > + if ( start < ram_start ) > + return false; > + > + if ( end <= ram_end ) > + return true; > + > + if ( start < ram_end ) > + start = ram_end; > + } > + > + return false; > +} > + > int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, > int sizecells, const struct membanks *mem) > { > @@ -513,14 +541,20 @@ int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, > int nr_cells = 0; > __be32 reg[DT_MEM_NODE_REG_RANGE_SIZE]; > __be32 *cells; > + bool is_resv = (mem == bootinfo_get_reserved_mem()); > > if ( mem->nr_banks == 0 ) > return -ENOENT; > > /* find the first memory range that is reserved for device (or firmware) */ > - for ( i = 0; i < mem->nr_banks && > - (mem->bank[i].type != MEMBANK_DEFAULT); i++ ) > - ; > + for ( i = 0; i < mem->nr_banks; i++ ) > + { > + if ( mem->bank[i].type != MEMBANK_DEFAULT ) > + continue; > + if ( is_resv && !is_in_host_ram(&mem->bank[i]) ) > + continue; > + break; > + } > > if ( i == mem->nr_banks ) > return 0; > @@ -544,6 +578,8 @@ int __init make_memory_node(const struct kernel_info *kinfo, int addrcells, > if ( (mem->bank[i].type == MEMBANK_STATIC_DOMAIN) || > (mem->bank[i].type == MEMBANK_FDT_RESVMEM) ) > continue; > + if ( is_resv && !is_in_host_ram(&mem->bank[i]) ) > + continue; > > nr_cells += reg_size; > BUG_ON(nr_cells > ARRAY_SIZE(reg)); From xen-devel-bounces@lists.xenproject.org Fri Oct 30 11:13:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 11:13:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465567.1676082 (Exim 4.92) (envelope-from ) id 1xMkXo-0002wp-3E; Fri, 30 Oct 2026 11:13:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465567.1676082; Fri, 30 Oct 2026 11:13: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 1xMkXo-0002wi-0R; Fri, 30 Oct 2026 11:13:12 +0000 Received: by outflank-mailman (input) for mailman id 1465567; Fri, 30 Oct 2026 11:13:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMkXm-0002wc-Uv for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 11:13:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMkXm-00DIwp-3C for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 12:13:10 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae47bc5-2eae-0a2a0a5409dd-0a2a4502bf80-2 for ; Fri, 30 Oct 2026 12:13:10 +0100 Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae47bc4-6ca4-0a2a45020019-d15580acddc9-3 for ; Fri, 30 Oct 2026 12:13:09 +0100 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-8b09e07e149so4552287b3.1 for ; Fri, 30 Oct 2026 04:13: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=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=1793358788; cv=none; d=google.com; s=arc-20260327; b=Na1GaoRi1eGZrn3g5vqFilW/4j874AQ3hj5iXQTk4gnLtpTroytsDyXxwvbrnpGZ4I zyQ2bqt3Ppec5wyz6jfI8qT2EzH/hiIXamaxam+Z2FS7tbDy8KgO7gPVxswyQAblJycY 7k9DWOZt3rQlzF1LcA4uDUqNsrkQxb8wurEMhNSz1Ry+wqxjIQ4Bf+aHf5BAamlQq9DL Mt+N2717Zon0w5/HIUApW28lHYkiDqpchlFkmyRNhr2qOM/mrbnpoy+oJFRvZyXeKJAE 5IeKL2FgCcG6BfKISx32M9lOoRzfZ2ZFIptJWZWKpqe/4evYkz6rC1m12Sammg9ayW7Q z1Cw== 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=5LUWZT5k5KvOS94ligsCtD+U9+DDcG+IL6eyG0y0saE=; fh=3EgVbjOIb5K9tD+0KroAY8Fz8mPHYGh8aQONqXayqLk=; b=gQOuOxDfrcvzetgU2Q6rq4EBDYFfzGB9I0SiGm4a4GFmXQAd4IQJwpv7tTxbXCjAr5 W9/ANVBL0q37+bGlAFCrB7Vh04ps3jmpu+1pm6GCYL1lSBfFrfN+dscXSB30U19E8RdP pzommA7XKCK4dlPQiItL3Wu0Xfen+SMOpOoI4ikRN6QfAZo5+hiYDhWjPMJdp7lAnMCD 4iaaF72iUtGN2Op2m+uHdQ6hZB4sOZI4GKu6W892K6nTeEsOJWg4J4ZWkDtuibLqcyd0 +WZvCTlWlKdsiA6y79rmVksv83LfFq3xhEbwElQH6YdERsVSGAElqWKWfdrvGWJXLnjK G0wQ==; 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=1793358788; x=1793963588; 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=5LUWZT5k5KvOS94ligsCtD+U9+DDcG+IL6eyG0y0saE=; b=suBFj4It3KqeCQVvJrwgYiLCbBfMK+Mfi93VtvbHzRx61ZBgngxx3oXBDwG+lfiRgX nfSDvwBHGHBERZ0H1V3EAdEFVLUgypWabufELVLcrHJL3guklt+R0YjW++3FN3dgHBHt wq2lfRgtYHSc4I4tpqq3jIGFzGxZheHKy5CovH0d4KrBm5il2IWqrZQs6lV70aEqwJ5W ce2odTMPaqhThYUYeOgaDAlOlo4HRi5pJTknb42nXNANNFCjxtYB02gPufXrxucG4v2A yuC6AEIoYWXNqPIynoXme51Anl1PtqjllsV6Lr4d42cqYtaNuPnH9o0qlJSwHhSBbVul yryA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793358788; x=1793963588; 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=5LUWZT5k5KvOS94ligsCtD+U9+DDcG+IL6eyG0y0saE=; b=eN0DYMhq7HUoJIV6JtGJY2JpO/47T7mqDV3GV1+ptlFwOtHWWAV4dIsZwfWl7T6Dpx SWee/2F9ngDhHK3QLFGz2Wx4K3l8ZC/NEx3a84pSYIxJOiOYMIKgwUy6DUU8vfHOIQxr be6Rz4oUWy2zpNDD/Q3DsO1XY81RYCKTbGy+OCN3gtZEAxUEdvn8FeZdGNXenYfAGmWm oLknxPr68p0HxFNvYCXtway1f7AJm9S9oV+BBhVfMjRcpmJGevb4k3RHCLY9xAxtTMDb rl5U5dKsZ40M2gbuR5aBQcHt6F+TCzlSIbcY7BiwvxKUQhec9yl+fA7PyoQudxR0jmri YVwA== X-Forwarded-Encrypted: i=1; AKwUvBzAdQeGlYo3DwrXklshR5/TMx6nMDSjoMj0TNhH5GzM7eduWwOdbdVvLmMpMCSggDks/b12VwxKV4U=@lists.xenproject.org X-Gm-Message-State: AFq9FYJrdFxPMKg0nRhHXmalTKnlunPt2uMMnMyoZktOQFdX9qlKoTQf zOwdDm9JjK0sO5PJV9emOZi7ikcwLFC77MdtZrn3nQDcSoGPNNxSKHMF+2lzlFkcqOjJl4XSjaC SJx0UYXCT0diN9ofcST387reDDK2tZ0WNzBtTAuJswg== X-Gm-Gg: AYBFou3A1Q+g91flhGJH2LbRlW7mcQCeIhG8KI/c+m4J3ivhfgUGjK6aSjMbizFzQxR GR7n/MTFubX6idvngflBf/PaUPcWBxKc5u0fqngNAtqgYlzPCVqKnn/1LKPCwOrohWU1b3wTNqh slbpGq79eEHK/0VjOjsMhVhdsZmRkOwFw/r6NA5xtFgaB6gurug9s5PWqu9XQm0u6tQlC3wPrFr d1CQLgONYQeaCZlvOnVdzQI4dilZWSMw/xD4DCnBPkS2nlXTtjSG/9Sb6cMWfOjUTa0cZ8d6DB2 ihwa7zk7NK/xykhmOS0LSLc6FJJHZ3XVpGH52Enp+/tI2NGxqqJC+lgv3bcwSTOvK3u5H7DSK/B EOcRckJUKuxo5hBQXoIIJxmh1Bq6X1MsJ7SIvnME1POb5MsEt2hHZmyhtMVzSyECTkxowi1Sbqw mq4eINEMc50cSJHz1Il8mKgg== X-Received: by 2002:a05:690c:e1d9:10b0:8b0:f0cc:db0e with SMTP id 00721157ae682-8b2b676ba6fmr7498147b3.78.1793358788267; Fri, 30 Oct 2026 04:13:08 -0700 (PDT) MIME-Version: 1.0 References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-10-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-10-berrange@redhat.com> From: Peter Maydell Date: Fri, 30 Oct 2026 11:12:55 +0000 X-Gm-Features: AclHuK8tWRtaAMh4OSG81o0Myk5Bd8TN4g8UgRz9NIr2z73xVEtamgvTgzkRr-c Message-ID: Subject: Re: [PATCH 09/28] hw/net: mark e1000, e1000e, IGB, rtl8139 & sPAPR VLAN as secure To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1793358789-F04A62AC-6B977E93/0/0 X-purgate-type: clean X-purgate-size: 919 On Fri, 11 Sept 2026 at 15:42, Daniel P. Berrang=C3=A9 wrote: > > 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. You've said in several bugs (e.g. https://gitlab.com/qemu-project/qemu/-/work_items/3872 ) that igb wasn't covered by the virtualization use case. I don't care either way, but I wanted to check since I've been marking igb bugs as non-confidential when triaging on the basis of that... thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Oct 30 12:28:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 12:28:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465600.1676097 (Exim 4.92) (envelope-from ) id 1xMlix-0005ki-Ag; Fri, 30 Oct 2026 12:28:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465600.1676097; Fri, 30 Oct 2026 12:28: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 1xMlix-0005kY-7H; Fri, 30 Oct 2026 12:28:47 +0000 Received: by outflank-mailman (input) for mailman id 1465600; Fri, 30 Oct 2026 12:11:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMlSG-00049T-86 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 12:11:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMlSF-00Ch0A-IJ for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 13:11:31 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4896b-bab6-0a2a0a5309dd-0a2a4509ed1e-8 for ; Fri, 30 Oct 2026 13:11:31 +0100 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 6ae48970-be1a-0a2a45090019-aa0a857ce175-3 for ; Fri, 30 Oct 2026 13:11:29 +0100 Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-608-RHM01w-8N3K6fC56XHf3BQ-1; Fri, 30 Oct 2026 08:11:26 -0400 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-3abb4c24125so631469a91.3 for ; Fri, 30 Oct 2026 05: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=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=1793362288; 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=huheSnuaAH41QXuP+wJKnnRPWFroH2JWTjHVE5i6hXA=; b=DQOa9UirA6se8ZCtd6+NTOnhD+doNcFc0nnF7SrxG0Z5hU6s9serkhqSYEbgiXgwZw06OF hZgx5XaA3oeXgcATPEpShBrCsyeOnFA/WaOQiZUlSliLje0nVI6mY7COfw+SoFzZpyXpMB 6EFPzdJC+ekBxnQl7+b8bjR/3OIUOMI= X-MC-Unique: RHM01w-8N3K6fC56XHf3BQ-1 X-Mimecast-MFC-AGG-ID: RHM01w-8N3K6fC56XHf3BQ_1793362286 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793362286; x=1793967086; 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=huheSnuaAH41QXuP+wJKnnRPWFroH2JWTjHVE5i6hXA=; b=HQmBTU9n7zoeH0VSi96WXPC/K5g7ar6QzNHvmUJSRKsR3hAFV5uPpWWQeTeX8IA868 u+SpkA4HkkUNumyrjSGAwYDGc4+WAp/ed3LPLo9CLTZLYKUnN38gYm0qKD2i820Kdg+J g2y8rgWvu1GWClJgakHW6BRRu4utm2RISUrsB6XN1XzOSiG/kU6glFKOXfAePQEEVqbk iKEKEgpsQPkepH/RugqJ9K1wct1YzQXixGKt+Gc1ZzwxATSlIX42AfD2029BNn239tXT TdQrLnlMt1BVEvW9JFHmB1T4LMMpMlX9zHdeElNQqX+vH+BDaB2XGySjCgkGT28r3cuk GtLQ== X-Forwarded-Encrypted: i=1; AKwUvBzp+/Hl/FPqxyr90+O47jAyyh4RjRxcIXU1mxFpu8WyIL9ORlDrkF3hQLug+QrTrWuLkWq1gTOGRKA=@lists.xenproject.org X-Gm-Message-State: AFq9FYIRs3DTsN7vElkb//OyGoEyB0Cn1CyBAdBlJr/eEznJbJZ727FY WIxuBVTGdJhnHSu5JppBYs0tZMcOp9hE7p9Ef0xP52mI7nwrhp8F/QjtljnQx6RCC9jMHVQ07DU ycVkgcicLiu3kcUw0SXBCvs9sMqyfHJFNUXJaNZczlrYdOPQ0jrHKTGqAwasIvzT4hM6tp1pfEE TUdJUY/uTIDlWqIFkt0tm+700HQaDTik4Ip6s+SnSqOno= X-Gm-Gg: AYBFou1ahiWwoEw6xBlHJA/PaJYngdaLrOZaAzy8sGGbtjcelCjj8mEVwKda8Zs8bMp 4f+aoatLLkS7TVmJdBJJtlgz26qiaVtdJxtOrnLz+LAc2rxfZjiK3nf1byJc1aGUFY7u8D2Gx6z ElWSeh1RjBGiVtxIY5Mb+0NsBNUQUaHh4EMtiGDVXv+vliJcwomPPov45vTiB5Vq2eD37hlY+xz TZVgyWRlmN2BsItP0PK3r3ksCHLa3tmBf1oxiMJxmPffeqMTeHHsbwyOxtF9L/XSVPgU7wqPkJo Vw== X-Received: by 2002:a17:90a:c2cc:b0:3a8:f70f:2437 with SMTP id 98e67ed59e1d1-3ae8980bd04mr1669658a91.50.1793362285557; Fri, 30 Oct 2026 05:11:25 -0700 (PDT) X-Received: by 2002:a17:90a:c2cc:b0:3a8:f70f:2437 with SMTP id 98e67ed59e1d1-3ae8980bd04mr1669589a91.50.1793362284955; Fri, 30 Oct 2026 05:11:24 -0700 (PDT) MIME-Version: 1.0 References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-17-431a86b02b58@redhat.com> <871p97a4mf.fsf@pond.sub.org> In-Reply-To: <871p97a4mf.fsf@pond.sub.org> From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Fri, 30 Oct 2026 16:11:12 +0400 X-Gm-Features: AclHuK9SdcKVottvuTeAWY4qSYFB8MXW7mNBnZIWRbyUXQq4NjRMq0jo7wIcSr4 Message-ID: Subject: Re: [PATCH v7 17/65] qom: add object_{class_}property_add_qapi_enum To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: pfaJY7RSKI5fsQPaU6mr0K-Y2xwy5DfFGs9JQlDuxn8_1793362286 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1793362289-39AC0034-86513897/0/0 X-purgate-type: clean X-purgate-size: 5096 Hi On Fri, Oct 30, 2026 at 2:02=E2=80=AFPM Markus Armbruster wrote: > > Marc-Andr=C3=A9 Lureau writes: > > > Signed-off-by: Markus Armbruster > > Signed-off-by: Marc-Andr=C3=A9 Lureau > > --- > > include/qom/object.h | 74 ++++++++++++++++++++++++++++++++++++++++++ > > qom/object.c | 90 ++++++++++++++++++++++++++++++++++++++++++++= +++++--- > > 2 files changed, 159 insertions(+), 5 deletions(-) > > > > diff --git a/include/qom/object.h b/include/qom/object.h > > index eb61d8842b80..e04be4caed57 100644 > > --- a/include/qom/object.h > > +++ b/include/qom/object.h > > @@ -2027,6 +2027,80 @@ ObjectProperty *object_class_property_add_enum(O= bjectClass *klass, > > int (*get)(Object *, Error **), > > void (*set)(Object *, int, Error *= *)); > > > > +/** > > + * struct QapiEnumProp: Descriptor for a property backed by a QAPI enu= m type > > + * > > + * Binds a QOM object property to a QAPI enum, providing automatic > > + * string<->int conversion through QAPI visitors and optional > > + * default-value initialization during object instance init. > > + * > > + * Use the QAPI_ENUM_PROP() macro to construct instances inline. > > + * > > + * @name: property name exposed on the QOM object > > + * @description: human-readable description (shown in ``-device help``= , etc.) > > + * @default_value: initial enum value applied via @set during instance= init, > > + * or -1 (the QAPI_ENUM_PROP default) to skip initiali= zation > > + * @qapi_type: pointer to the generated QAPITypeInfo for the enum > > + * (provides the string<->int lookup table) > > + * @get: getter that returns the current enum value as int, or -1 on e= rror > > + * @set: setter that receives the enum value as int; %NULL for read-on= ly props > > + */ > > +typedef struct QapiEnumProp { > > + const char *name; > > + const char *description; > > + const int default_value; > > + const QAPITypeInfo *qapi_type; > > + int (*get)(Object *, Error **); > > + void (*set)(Object *, int, Error **); > > +} QapiEnumProp; > > + > > +#define QAPI_ENUM_PROP(...) ({ = \ > > + static const QapiEnumProp _prop =3D { = \ > > + .default_value =3D -1, __VA_ARGS__ = \ > > + }; = \ > > + &_prop; }) > > This is a cute and reasonably well-known macro trick for optional > keyword arguments in C. > > The example [*] below specifies all arguments. What happens when we > omit any? They default to zero via default initializaion, except for > .default_value, which defaults to -1. > > Trap for developers: some arguments aren't actually optional! If you > forget to specify @name or @qapi_type, the code compiles, but crashes at > run time. > > Not a fan. Agree (not a fan of C either). We could probably add more static/runtime checks. Or clearly state that there is room for improvements, or just drop it altogether - either as follow up or with the series. I leave that up to you since you are going to respin it. thanks! > > > + > > +/** > > + * object_property_add_qapi_enum: > > + * @obj: the object to add a property to > > + * @prop: property descriptor > > + * > > + * Add an enum property with QAPI type association. > > + * > > + * Returns: The newly added property on success, or %NULL on failure. > > + */ > > +ObjectProperty * > > +object_property_add_qapi_enum(Object *obj, const QapiEnumProp *prop); > > + > > +/** > > + * object_class_property_add_qapi_enum: > > + * @klass: the class object to add a property to > > + * @prop: property descriptor > > + * > > + * Add an enum property with QAPI type association. > > + * > > + * Use the QAPI_ENUM_PROP() macro to construct the property descriptor > > + * inline. If .default_value is not set, the property is not initializ= ed > > + * (default_value is -1). Otherwise, the setter is called with > > + * default_value during object instance init. > > + * > > + * Example:: > > [*] > > > + * > > + * object_class_property_add_qapi_enum(oc, QAPI_ENUM_PROP( > > + * .name =3D "policy", > > + * .description =3D "Set the NUMA policy", > > + * .default_value =3D HOST_MEM_POLICY_DEFAULT, > > + * .qapi_type =3D &HostMemPolicy_type_info, > > + * .get =3D my_get_policy, > > + * .set =3D my_set_policy, > > + * )); > > + * > > + * Returns: The newly added property on success, or %NULL on failure. > > + */ > > +ObjectProperty * > > +object_class_property_add_qapi_enum(ObjectClass *klass, > > + const QapiEnumProp *prop); > > + > > /** > > * object_property_add_qapi: > > * @obj: the object to add a property to > > [...] > From xen-devel-bounces@lists.xenproject.org Fri Oct 30 12:28:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 12:28:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465478.1676091 (Exim 4.92) (envelope-from ) id 1xMlix-0005iM-36; Fri, 30 Oct 2026 12:28:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465478.1676091; Fri, 30 Oct 2026 12:28: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 1xMlix-0005iF-0D; Fri, 30 Oct 2026 12:28:47 +0000 Received: by outflank-mailman (input) for mailman id 1465478; Fri, 30 Oct 2026 09:01:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMiUa-0005hW-IH for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 09:01:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMiUT-002ESF-5a for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 10:01:42 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae45cea-2eae-0a2a0a5409dd-0a2a4504eab6-26 for ; Fri, 30 Oct 2026 10:01:36 +0100 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 6ae45cef-b57f-0a2a45040019-aa0a857c91db-3 for ; Fri, 30 Oct 2026 10:01:36 +0100 Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-424-mxKBEUAXNE-AgR6RvROeQQ-1; Fri, 30 Oct 2026 05:01:33 -0400 Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2e869e00005so9428885ad.2 for ; Fri, 30 Oct 2026 02:01: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=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=1793350895; 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=z0kKp64FY09dUFk/LW6vDgxjLXPXjA/VzYL6OdfGV/k=; b=gvJ7H61fY4RduLqJJQWL3r6RBY+/CITq+SQXuAB/M9g4boXl5cd3IJ9HaDpEHM/7bcMGDq zuWw8LBVFUXwvxk4GNq1Otg+8m9WcgZN46bdZgyEkBzysX8aMIctFzOIFMOE6dTocRkhzq aQ+02lPkj5HM9TJHueCVNHkE56gpr3o= X-MC-Unique: mxKBEUAXNE-AgR6RvROeQQ-1 X-Mimecast-MFC-AGG-ID: mxKBEUAXNE-AgR6RvROeQQ_1793350892 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793350892; x=1793955692; 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=z0kKp64FY09dUFk/LW6vDgxjLXPXjA/VzYL6OdfGV/k=; b=VjoFhTXWOklVH5y5e3zbDv9pP9+7KMnR6NdDLxKIdI5urS6yvih7sXZsSD0FxyYrdZ Jb/qsA3cBewq/7j/PmputUqv5x0Fgw1TkcZeizXtSZflpDij2+7kQtHWSDg3AQ2tklcW voaaKBYCC9VSB9VapHDY/syH7v9BP9iGiD6Wjyk8H5K84BkP0H49hV1baiAx5h0NH89r CDiyxu9MWHVXF+0RtdBEkcxY7qKZ6vuYoyhb/As5SFTd+rIIh+LjSPH683Y0RH+255rc JBCsnHUbX8kMooX1PLqxBFgxzdj7KLtYRQuMufAie5TTqCxAXTOS7wCtSOV/pfdsJvyo gjHQ== X-Forwarded-Encrypted: i=1; AKwUvBxObjyBeh+T3xY7n55rQOOxSpdoJSex71mJiEXN3MYhYfz6a1zhF1PwXDy9sUdLPwtvcjnVS3flO+U=@lists.xenproject.org X-Gm-Message-State: AFq9FYLMePhHRAv+Tzag/tWueKC6dd6jhO2MazZ4H4qIGzofk1lKFyDD rrWRlimMvVC6wpKs+ARhKD1BSfn9XSeb7hSw43yC8LuM6aIjP2z8YY8269ueC5TN3o9U0IytV4e gHzlmsXhX1fQ9MbTmMb4mu9iiiQbkuLTev3z7VU2OW44MoYxCH3YLplo9O47qyFTCsR6y+rPqU1 TFGg+nQBi6fYe/di/5ICDB5Fsdr5EYZniKAEcBSfl88rQ= X-Gm-Gg: AYBFou2+eAL5dM76NezfaSnNfyjyfPu/wej+kpWBOeU4Z91BwXf+uSnm7uA4W0oA5p5 47AHuM5+aNH7iBqMS03dpFK2Rmf84jaczCeZl9gjN3aIoIXrA+UANJpnhIMlQfpH9sbGsUJ5Ldl BcPGMShLOV4u88DiTtZPrkJy8FfpUJVKQ2rX993XiBFDJsDIRsJpbWmT5v4bGDKELNiCI2z47tp HNAeLvXWBf2ltMOBlO6DZkXvtFTgGRhM8Q3xly4NzVsC7TRubTTtwpDJh5KqFTueGUWARr+CrTK YA== X-Received: by 2002:a17:90b:4d05:b0:3ad:c482:ae93 with SMTP id 98e67ed59e1d1-3ae897f55f1mr1344514a91.27.1793350891493; Fri, 30 Oct 2026 02:01:31 -0700 (PDT) X-Received: by 2002:a17:90b:4d05:b0:3ad:c482:ae93 with SMTP id 98e67ed59e1d1-3ae897f55f1mr1344360a91.27.1793350890250; Fri, 30 Oct 2026 02:01:30 -0700 (PDT) MIME-Version: 1.0 References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-38-431a86b02b58@redhat.com> <87y0bfa81j.fsf@pond.sub.org> In-Reply-To: <87y0bfa81j.fsf@pond.sub.org> From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Fri, 30 Oct 2026 13:01:17 +0400 X-Gm-Features: AclHuK98dJOvD1KtoAB9Z7J96maRIl_qDeI5itEWow68bU5XOo3fY2yUQSfcL4E Message-ID: Subject: Re: [PATCH v7 38/65] qom: convert scalar properties to QAPI-aware registration To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: YoFEJZ6hSEBlqbhdFjtpyuYcbBBaUk6hg8AiUFYdvDg_1793350892 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1793350896-C06DAB50-DD83248F/0/0 X-purgate-type: clean X-purgate-size: 14390 Hi On Fri, Oct 30, 2026 at 12:48=E2=80=AFPM Markus Armbruster wrote: > > Marc-Andr=C3=A9 Lureau writes: > > > Reviewed-by: Amit Machhiwal > > Signed-off-by: Markus Armbruster > > Signed-off-by: Marc-Andr=C3=A9 Lureau > > How did you create this patch? It looks almost mechanical. Repeated grep / multi-cursor in zed iirc > > It misses a few conversions, almost certainly in code added since you > made this patch. I can take care of them. Not surprising after several months. > [...] > > > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c > > index 1d91667fb880..bc178482b309 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" > > Not needed; we already include "qapi/qapi-type-infos-common.h". > > [...] > > > diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c > > index 6d421b990cef..64228a620e69 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" > > Missing: > > PM_REG_FIELD(acpi_pci_hotplug.root= ), > object_property_allow_set_link, > OBJ_PROP_LINK_STRONG); > - object_class_property_add(oc, ACPI_PM_PROP_GPE0_BLK, "uint32", > + object_class_property_add_qapi(oc, ACPI_PM_PROP_GPE0_BLK, &uint32= _type_info, > ich9_pm_get_gpe0_blk, > NULL, NULL, NULL); > object_class_property_add_uint8_ptr(oc, ACPI_PM_PROP_S3_DISABLED, > > [...] > > > 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", = \ > > Use of &size_type_info is not mechanical. Better to be as mechanical as > possible in such a huge patch. yes, I thought I splitted those appart - I missed some apparently > > [...] > > > diff --git a/qom/object.c b/qom/object.c > > index cc113c0810e7..9f9a2abfa08d 100644 > > --- a/qom/object.c > > +++ b/qom/object.c > > @@ -22,10 +22,10 @@ > > #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 "qapi/compat-policy.h" > > #include "qobject/qdict.h" > > -#include "qobject/qjson.h" > > The deletion doesn't belong. > > > #include "qemu/id.h" > > #include "qapi/qmp/qerror.h" > > #include "trace.h" > > @@ -2449,7 +2449,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, > > @@ -2467,7 +2467,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, > > @@ -2519,7 +2519,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, > > @@ -2536,7 +2536,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, > > Missing: > > @@ -2929,7 +2930,7 @@ object_class_property_add_bool_ptr(ObjectClass *= klass, const char *name, > setter =3D property_class_set_bool_ptr; > } > > - return object_class_property_add(klass, name, "bool", > + return object_class_property_add_qapi(klass, name, &bool_type_inf= o, > getter, setter, NULL, (void *)of= fset); > } Yes, new APIs I missed in updated version > > > @@ -2945,8 +2945,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 * > > Missing: > > @@ -2969,7 +2970,7 @@ object_class_property_add_uint8_ptr(ObjectClass = *klass, const char *name, > setter =3D property_class_set_uint8_ptr; > } > > - return object_class_property_add(klass, name, "uint8", > + return object_class_property_add_qapi(klass, name, &uint8_type_in= fo, > getter, setter, NULL, (void *)of= fset); > } > > > @@ -2986,8 +2986,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 * > > @@ -3006,8 +3006,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 * > > Missing: > > @@ -3030,7 +3031,7 @@ object_class_property_add_uint16_ptr(ObjectClass= *klass, const char *name, > setter =3D property_class_set_uint16_ptr; > } > > - return object_class_property_add(klass, name, "uint16", > + return object_class_property_add_qapi(klass, name, &uint16_type_i= nfo, > getter, setter, NULL, (void *)of= fset); > } > > > @@ -3047,8 +3047,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 * > > @@ -3067,8 +3067,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 * > > Missing: > > @@ -3091,7 +3092,7 @@ object_class_property_add_uint32_ptr(ObjectClass= *klass, const char *name, > setter =3D property_class_set_uint32_ptr; > } > > - return object_class_property_add(klass, name, "uint32", > + return object_class_property_add_qapi(klass, name, &uint32_type_i= nfo, > getter, setter, NULL, (void *)of= fset); > } > > > @@ -3108,8 +3108,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 * > > @@ -3128,8 +3128,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 * > > Missing: > > @@ -3152,7 +3153,7 @@ object_class_property_add_uint64_ptr(ObjectClass= *klass, const char *name, > setter =3D property_class_set_uint64_ptr; > } > > - return object_class_property_add(klass, name, "uint64", > + return object_class_property_add_qapi(klass, name, &uint64_type_i= nfo, > getter, setter, NULL, (void *)of= fset); > } > > > @@ -3169,8 +3169,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/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", > > Missing: > > @@ -3290,7 +3290,7 @@ sev_snp_guest_class_init(ObjectClass *oc, const = void *data) > object_class_property_add_bool(oc, "secure-tsc", > sev_snp_guest_get_secure_tsc, > sev_snp_guest_set_secure_tsc); > - object_class_property_add(oc, "tsc-frequency", "uint32", > + object_class_property_add_qapi(oc, "tsc-frequency", &uint32_type_= info, > sev_snp_guest_get_tsc_frequency, > sev_snp_guest_set_tsc_frequency, NULL, = NULL); > } > > [...] > Are you working on v8 or should I start rebasing? From xen-devel-bounces@lists.xenproject.org Fri Oct 30 13:12:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 13:12:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465643.1676110 (Exim 4.92) (envelope-from ) id 1xMmPG-0005VV-CR; Fri, 30 Oct 2026 13:12:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465643.1676110; Fri, 30 Oct 2026 13: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 1xMmPG-0005VO-9G; Fri, 30 Oct 2026 13:12:30 +0000 Received: by outflank-mailman (input) for mailman id 1465643; Fri, 30 Oct 2026 13:12:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMmPF-0005VI-Bm for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 13:12:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMmPE-001n49-9U for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:12:28 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4979b-bab6-0a2a0a5309dd-0a2a450aa336-30 for ; Fri, 30 Oct 2026 14:12:27 +0100 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae497ba-f2d2-0a2a450a0019-aa0a857c6afd-3 for ; Fri, 30 Oct 2026 14:12:27 +0100 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-96-wLI8iMc8NRaHZo9QEuBdlw-1; Fri, 30 Oct 2026 09:12:19 -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 077D51828ADD; Fri, 30 Oct 2026 13:12:12 +0000 (UTC) Received: from redhat.com (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 905FB1956088; Fri, 30 Oct 2026 13:12:09 +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=1793365946; 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=luqN36eQr9cvX7ZlJUQi6wCB1RlpaTkpx7SoAr5njao=; b=GDf5x0GyTVmoC2cj4ZOIsD65K6+QnAcTUiQh4azd7SuIVsAwxEVm8i3mMcvqc8y6nbK48M BVcbGT+K/t+zvgTLpJD329rZmHlNz++kbtveVgYam2fT+4tqx6yVgpCpqcvR8wFrP34Mtd dh8bD0/qcteegkcP02kLAhXE//3vOLw= X-MC-Unique: wLI8iMc8NRaHZo9QEuBdlw-1 X-Mimecast-MFC-AGG-ID: wLI8iMc8NRaHZo9QEuBdlw_1793365938 Date: Fri, 30 Oct 2026 13:12:06 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Peter Maydell Cc: qemu-devel@nongnu.org, 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 09/28] hw/net: mark e1000, e1000e, IGB, rtl8139 & sPAPR VLAN as secure Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-10-berrange@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.4.2 (2026-08-30) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: BZoHLA3nUl3TbRKut8vaFSTbqr-qL6RB00r5tK4yPGI_1793365938 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1793365947-514C7CFC-CC328990/0/0 X-purgate-type: clean X-purgate-size: 1775 On Fri, Oct 30, 2026 at 11:12:55AM +0000, Peter Maydell wrote: > On Fri, 11 Sept 2026 at 15:42, Daniel P. Berrangé wrote: > > > > 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. > > You've said in several bugs (e.g. > https://gitlab.com/qemu-project/qemu/-/work_items/3872 ) > that igb wasn't covered by the virtualization use case. Hmm, yes, I forgot I had said that, which I guess shows the value of this series long term. > I don't care either way, but I wanted to check since I've been > marking igb bugs as non-confidential when triaging on the > basis of that... I added it in this series because I forgot what I previously said and then found our RHEL shipped it. I've since checked that the RHEL inclusion was only for ease of SRIOV testing, not intended for production deployment. So consider 'igb' dropped from this patch. We'll continue to treat it as insecure, unless a maintainer steps up to request otherwise and fix historical issues we've had disclosed this year. 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 Oct 30 13:24:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 13:24:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465658.1676128 (Exim 4.92) (envelope-from ) id 1xMmb1-0007kH-GY; Fri, 30 Oct 2026 13:24:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465658.1676128; Fri, 30 Oct 2026 13:24: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 1xMmb1-0007kA-Ct; Fri, 30 Oct 2026 13:24:39 +0000 Received: by outflank-mailman (input) for mailman id 1465658; Fri, 30 Oct 2026 13:24:38 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMmb0-0007jf-20 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 13:24:38 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMmaz-00000004Gqa-0JTr; Fri, 30 Oct 2026 13:24:36 +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.98.2) (envelope-from ) id 1xMmay-00000007k31-1wAl; Fri, 30 Oct 2026 13:24: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" 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=2Lf9FJlpDBMjDqifcNltXmBL+3wrGoy3egUW4LZ+zNE=; b=ncp6VXGx5uOWwe8lKCUBf7dmO2 C5AD8oDaWf79fY6ffM8p98TZ0wOAFiIfdB/e9oDHTRqT6P694TEFRhOsqfbQqkFJ1Sk+ZRyxtSfZG zqmCv2JPNOaQyOfQ6Dfe6gEnxpjJ5liegmn4++YUASXLdegH8NOrcwZBA9dGqLJoBZos=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH 1/2] x86/cpu: keep cached TSC_AUX state coherent with hardware Date: Fri, 30 Oct 2026 14:24:18 +0100 Message-ID: <20261030132419.84264-2-roger@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261030132419.84264-1-roger@xenproject.org> References: <20261030132419.84264-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On CPU bringup don't assume that TSC_AUX is 0, write 0 to it to ensure the per-CPU cached state matches the hardware. Also propagate the cached value on resume from suspend, in case the register value has been reset during suspension. Fixes: cc0e45db2779 ("x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context") Signed-off-by: Roger Pau Monné --- xen/arch/x86/acpi/power.c | 3 +++ xen/arch/x86/cpu/common.c | 5 +++++ 2 files changed, 8 insertions(+) diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c index 3452650a61d5..464846e73727 100644 --- a/xen/arch/x86/acpi/power.c +++ b/xen/arch/x86/acpi/power.c @@ -279,6 +279,9 @@ static int enter_state(u32 state) ci->last_spec_ctrl = default_xen_spec_ctrl; } + if ( cpu_has_msr_tsc_aux ) + wrmsrns(MSR_TSC_AUX, this_cpu(tsc_aux)); + update_mcu_opt_ctrl(); update_pb_opt_ctrl(); diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 43785d19cc73..5beae0e87f49 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -926,6 +926,11 @@ void cpu_init(void) /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabled. */ enable_nmis(); + + if (cpu_has_msr_tsc_aux) { + wrmsrns(MSR_TSC_AUX, 0); + this_cpu(tsc_aux) = 0; + } } void cpu_uninit(unsigned int cpu) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 13:24:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 13:24:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465659.1676134 (Exim 4.92) (envelope-from ) id 1xMmb1-0007mj-OS; Fri, 30 Oct 2026 13:24:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465659.1676134; Fri, 30 Oct 2026 13:24: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 1xMmb1-0007mX-JJ; Fri, 30 Oct 2026 13:24:39 +0000 Received: by outflank-mailman (input) for mailman id 1465659; Fri, 30 Oct 2026 13:24:39 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMmb1-0007jy-42 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 13:24:39 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMmb1-00000004Gqi-0249; Fri, 30 Oct 2026 13:24: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.98.2) (envelope-from ) id 1xMmb0-00000007k4Z-27Yf; Fri, 30 Oct 2026 13:24: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=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=fv865zl5JzNvZdc+vUmKul0mo11ea8d5CxR8YPF0vJw=; b=kKciUV1IgKBlLSTfpR19gwsPcB X428zkaf64a7toiZDT+UuSp6x0jaDrEkLmn0oO103AbDc++owXVp16pjF/xJKnUM0HO3wzuVLvHfl L2zypsFEsXy7IlJrlc0+I5vZw3zG8m9G/WSAHW6FPHKakE443Up+geD0mTerMNHZwjQs=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH 2/2] x86/hvm: sync APs TSC with the BSP at creation only Date: Fri, 30 Oct 2026 14:24:19 +0100 Message-ID: <20261030132419.84264-3-roger@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261030132419.84264-1-roger@xenproject.org> References: <20261030132419.84264-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current logic syncs the APs' TSC with the BSP both at reset and when setting the vCPU state. This doesn't match hardware behavior, where APs are only in sync at platform start. Move the TSC sync so it's done in hvm_vcpu_initialise(), that's called a single time at vCPU creation. This matches the hardware behavior. INIT-SIPI and VCPUOP_initialise no longer re-sync a vCPU's TSC to vCPU 0's. On migration the TSC offset for offline vCPUs is not transferred (hvm_save_cpu_ctxt() skips offline vCPUs). To avoid an unexpected skew synchronize offline vCPUs with the first online vCPU, taking into account the TSC_ADJUST value. The clearing of TSC_ADJUST is also made consistent with hardware behavior: clear it on S3 resume, but not across an INIT-SIPI or VCPUOP_initialise. Additionally, on S3 resume start all vCPUs from a shared TSC reading, so they are in sync. Fixes: c31f8336e64e ("[HVM] Initialise AP TSC to same as BP TSC.") Fixes: 6e0336351ed9 ("x86: Implement TSC adjust feature for HVM guest") Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/domain.c | 5 ----- xen/arch/x86/hvm/hvm.c | 19 +++++++++++-------- xen/arch/x86/hvm/save.c | 34 ++++++++++++++++++++++++++++++++-- xen/arch/x86/time.c | 5 ++--- 4 files changed, 45 insertions(+), 18 deletions(-) diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c index 978d8b222256..71f49ec7ce9f 100644 --- a/xen/arch/x86/hvm/domain.c +++ b/xen/arch/x86/hvm/domain.c @@ -312,11 +312,6 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) hvm_set_segment_register(v, x86_seg_es, &es); hvm_set_segment_register(v, x86_seg_tss, &tr); - /* Sync AP's TSC with BSP's. */ - v->arch.hvm.cache_tsc_offset = - d->vcpu[0]->arch.hvm.cache_tsc_offset; - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); - paging_update_paging_modes(v); hvmemul_cancel(v); diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index ef9c7cd05777..81e90cc8fc8e 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1667,6 +1667,12 @@ int hvm_vcpu_initialise(struct vcpu *v) /* Init guest TSC to start from zero. */ hvm_set_guest_tsc(v, 0); } + else + { + /* Start in step with vCPU 0, as all CPUs do at power-on. */ + v->arch.hvm.cache_tsc_offset = d->vcpu[0]->arch.hvm.cache_tsc_offset; + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); + } return 0; @@ -4021,13 +4027,6 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, uint16_t ip) hvm_set_segment_register(v, x86_seg_gdt, ®); hvm_set_segment_register(v, x86_seg_idt, ®); - /* Sync AP's TSC with BSP's. */ - v->arch.hvm.cache_tsc_offset = - v->domain->vcpu[0]->arch.hvm.cache_tsc_offset; - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); - - v->arch.hvm.msr_tsc_adjust = 0; - paging_update_paging_modes(v); v->arch.flags |= TF_kernel_mode; @@ -4079,9 +4078,13 @@ static void hvm_s3_resume(struct domain *d) if ( test_and_clear_bool(d->arch.hvm.is_s3_suspended) ) { struct vcpu *v; + uint64_t at_tsc = rdtsc(); for_each_vcpu( d, v ) - hvm_set_guest_tsc(v, 0); + { + v->arch.hvm.msr_tsc_adjust = 0; + hvm_set_guest_tsc_fixed(v, 0, at_tsc); + } domain_unpause(d); } } diff --git a/xen/arch/x86/hvm/save.c b/xen/arch/x86/hvm/save.c index 8ab64057064e..65ebfd384d69 100644 --- a/xen/arch/x86/hvm/save.c +++ b/xen/arch/x86/hvm/save.c @@ -289,6 +289,7 @@ int hvm_load(struct domain *d, bool real, hvm_domain_context_t *h) { const struct hvm_save_header *hdr; struct hvm_save_descriptor *desc; + struct vcpu *v; int rc; if ( d->is_dying ) @@ -302,8 +303,6 @@ int hvm_load(struct domain *d, bool real, hvm_domain_context_t *h) rc = arch_hvm_check(d, hdr); if ( real ) { - struct vcpu *v; - ASSERT(!rc); /* @@ -341,6 +340,37 @@ int hvm_load(struct domain *d, bool real, hvm_domain_context_t *h) /* Reset cursor for hvm_load(, true, ). */ if ( !real ) h->cur = 0; + else + { + const struct vcpu *base = NULL; + + /* + * Offline vCPUs have no CPU record. Adjust the TSC offset + * based on the first online vCPU, taking into account + * TSC_ADJUST which is saved regardless of whether the vCPU is + * offline. + */ + for_each_vcpu(d, v) + if ( !test_bit(_VPF_down, &v->pause_flags) ) + { + base = v; + break; + } + + if ( !base ) + return 0; + + for_each_vcpu(d, v) + if ( test_bit(_VPF_down, &v->pause_flags) ) + { + v->arch.hvm.cache_tsc_offset = + base->arch.hvm.cache_tsc_offset - + base->arch.hvm.msr_tsc_adjust + + v->arch.hvm.msr_tsc_adjust; + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); + } + } + return 0; } diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index f37fddc61e47..79c7123c0a5b 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -3087,9 +3087,8 @@ int tsc_set_info(struct domain *d, * set_tsc_offset() is called from hvm_vcpu_initialise() before * tsc_set_info(). New vtsc mode may require recomputing TSC * offset. - * We only need to do this for BSP during initial boot. APs will - * call set_tsc_offset() later from hvm_vcpu_reset_state() and they - * will sync their TSC to BSP's sync_tsc. + * We only need to do this for BSP during initial boot. APs copy + * vCPU 0's offset when created in hvm_vcpu_initialise(). */ d->arch.hvm.sync_tsc = rdtsc(); hvm_set_tsc_offset(d->vcpu[0], -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 13:24:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 13:24:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465657.1676118 (Exim 4.92) (envelope-from ) id 1xMmay-0007XR-AV; Fri, 30 Oct 2026 13:24:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465657.1676118; Fri, 30 Oct 2026 13:24: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 1xMmay-0007XK-7U; Fri, 30 Oct 2026 13:24:36 +0000 Received: by outflank-mailman (input) for mailman id 1465657; Fri, 30 Oct 2026 13:24:35 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMmax-0007XE-8E for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 13:24:35 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMmaw-00000004GqQ-1yp2; Fri, 30 Oct 2026 13:24:34 +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.98.2) (envelope-from ) id 1xMmav-00000007jyu-40Q8; Fri, 30 Oct 2026 13:24: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" 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=8aPU48opGdNz807TGF9TgmPgjbyhOB7kUbla249bPCU=; b=DF+6sPvMXpAxhJkJd6oMkXaK4j 4XeqM/IoF65Rt0nn9F8GyZfH6rjv65ivqxCYwSu92kt6r4EZjZtMyzpjRruWjVwNifLEJtqtdAuqz LXhdrx5DtSsaKZHRrJeV5FX2Mtjgeu+XZm0zMd1iC2uLcfqtGiHQgQ4jLBdT6eXA1mqk=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Teddy Astie Subject: [PATCH 0/2] x86/cpu: TSC handling adjustments Date: Fri, 30 Oct 2026 14:24:17 +0100 Message-ID: <20261030132419.84264-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 Hello, The fist patch fixes a bug if started with TSC_AUX != 0, as then the cached value won't match the hardware one. Second patch fixes handling of TSC_ADJUST and TSC offset for HVM domains, in an attempt to make it consistent with hardware behavior. Thanks, Roger. Roger Pau Monne (2): x86/cpu: keep cached TSC_AUX state coherent with hardware x86/hvm: sync APs TSC with the BSP at creation only xen/arch/x86/acpi/power.c | 3 +++ xen/arch/x86/cpu/common.c | 5 +++++ xen/arch/x86/hvm/domain.c | 5 ----- xen/arch/x86/hvm/hvm.c | 19 +++++++++++-------- xen/arch/x86/hvm/save.c | 34 ++++++++++++++++++++++++++++++++-- xen/arch/x86/time.c | 5 ++--- 6 files changed, 53 insertions(+), 18 deletions(-) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 13:32:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 13:32:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465678.1676146 (Exim 4.92) (envelope-from ) id 1xMmid-0001vS-E2; Fri, 30 Oct 2026 13:32:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465678.1676146; Fri, 30 Oct 2026 13:32: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 1xMmid-0001vJ-A2; Fri, 30 Oct 2026 13:32:31 +0000 Received: by outflank-mailman (input) for mailman id 1465678; Fri, 30 Oct 2026 13:32:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMmib-0001vD-GI for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 13:32:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMmia-001qg5-Pp for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:32:28 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae49c5b-2eae-0a2a0a5409dd-0a2a4501b6b4-24 for ; Fri, 30 Oct 2026 14:32:28 +0100 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 6ae49c6b-5984-0a2a45010019-b9ff1c229447-3 for ; Fri, 30 Oct 2026 14:32:28 +0100 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 1a18d02efef000cae1.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 13:32:22 +0000 Received: from leducb.tail4c4a28.ts.net (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 691F28080D; Fri, 30 Oct 2026 14:32:21 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=CLWf9iffvY1JaPLYZX9LqaFI6UMZCbZf3V/Hq/+nM/c=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=D7vbbvLyyMi0l1iQEQ/gdw4eCg9QK2yRR+Xi01UddIYOEVwLpEXDU6uB/z+fItB15Sw174Sou Df8wa0ygG24/AUjdsGS7XclhKzG/cMY3hPpw2+C7EIuqknaEcQX2Pyu6DjeS0N6wTqHBUtEOjp4 xcezdzEurMjhoCcHkORfDKideVvXOinAont8CBXURELmpbprQ7NeV4pGeEevpAXsCCYPuxtLz/Q mTP/YhYHTl6AZ9sGXunSTaRoqcx4i1ujxQkzDu1bGv4lZFulafA4ho/vv9pLI5qoBLugmAVFP4D qweRCqOZjyYzgsYJ60ZG8RMk8HjDUnrr7P2d2V2qAK2A== X-Zone-Loop: 7f0a09b2084fd4a13aa1e3193fde1e72c89020f59277 x-campaign-type: default x-transaction-id: 36d6fbf8-a271-4234-b90b-0e0f49dd8958 x-swg-uid: 01-9f68f065-3416-4c35-874c-c9bba8ad1f18 X-Mailer: Sweego Message-ID: <1793367142.8631fc262581453bbf619ec5b2062170.1a18d02efef000cae1@vates.tech> x-swg-bid: 1793367142.8631fc262581453bbf619ec5b2062170.1a18d02efef000cae1 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v11 0/1] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Fri, 30 Oct 2026 14:32:16 +0100 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=1793367077; l=6757; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=wPUCEZc8059rY1ai1e9M9I0u+MiDy5uAV8GQf+R8kCY=; b=2hENqEvEgahWUJc5qpP0vhj1Bd9znOS4fmAEtHTWBU+B0DYAbk0kERXEXXx+tgKwYX8Cy6p+S dg81/XXO36UDmi97c4gVLZSUt6ONFEyM/KTqCWCv6VqDVwV9eMUoo4Q 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: 1793367141637 X-purgate-ID: tlsNG-d62444/1793367148-BCD44757-0BC6D2D2/0/0 X-purgate-type: clean X-purgate-size: 6759 This series introduces bug 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: Probe the A/D update scheme if the DT advertises neither Svade nor Svadu Test CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/3008747678 --- Changes since v10: - Reword the comments around the probe load and the A bit check. - Shorten the warning printed when the extension is probed, and update the commit message to match. - Collect trailers: R-by from Oleksii and A-by from Jan, kept as the changes above only touch comments and a printk() string. --- Changes since v9: - Add a fence between the probe load and reading the PTE back, as nothing else orders the A bit update before the read. - Explain why set_fixmap() can't be used and why any RAM page can be aliased. - Link to v9: https://patch.msgid.link/1793098984.8631fc262581453bbf619ec5b2062170.1a17d072ce5000f79f@vates.tech --- Changes since v8: - Drop patches merged upstream: 999c2ca1ab ("xen/riscv: use pte_is_valid() in pte_is_mapping()") 8e34f567ef ("xen/riscv: fix A/D bits in Xen's page-table mappings") 73b802624a ("xen/riscv: look up the exception table for any trap taken in Xen context") 8a9a4bcd7c ("xen/riscv: rework the A/D bits comment in p2m_set_pte_flags()") - Probe through a read-only alias of the Xen image and check the A bit, as A being set by a speculative access still implies Svadu. - Link to v8: https://patch.msgid.link/1793027589.8631fc262581453bbf619ec5b2062170.1a178c5c430000f79f@vates.tech --- Changes since v7: - Replace the panic when the DTS advertises neither Svade nor Svadu with a probe of the A/D update scheme in that case only, recording the probed extension so that such device trees can be used as-is. The device tree is trusted otherwise, as discussed with Jan (patch 4). - Add patch 3, so that the store page fault raised by the probe on Svade hardware is fixed up. - Move the p2m_set_pte_flags() comment rework last (patch 5). - Collect trailers: A-by on patches 1 and 2, T-by on patch 2 and R-by on patch 5. - Link to v7: https://patch.msgid.link/1792164706.8631fc262581453bbf619ec5b2062170.1a14557373c0008425@vates.tech --- Changes since v6: - Drop the boot time probe of the A/D update scheme and trust the device tree. Xen now panics when the DTS advertises neither Svade nor Svadu (patch 3). - Patch 4 no longer changes when A/D are preset, it only reworks the comment, since patch 3 guarantees the DTS advertises the scheme in effect. - Reorder the series so the already reviewed patches come first. - Patch 2: add a second Fixes tag for arch_pmap_map(). - Patch 1: rebase, as the reorder changed its context. - Link to v6: https://patch.msgid.link/1791885904.8631fc262581453bbf619ec5b2062170.1a134b909b40008425@vates.tech --- Changes since v5: - Replace "xen/riscv: always preset A/D bits in G-stage PTEs" with a boot time probe of the A/D update scheme (patch 1). It checks the result against the Svade/Svadu DT binding and records the probed scheme when the DT advertises neither, instead of trusting the DT alone. - Split the p2m_set_pte_flags() comment rework out into its own patch (patch 2). - Patches 3 and 4 unchanged and are waiting to be merged. - Link to v5: https://patch.msgid.link/1791215925.8631fc262581453bbf619ec5b2062170.1a10cc9f7c20003f66@vates.tech --- Changes since v4: - Drop patches merged upstream: ccf9d78c825b ("xen/riscv: rename PTE "permissions" to "pte_flags"") - Collect trailers. - Rebase patches on top of staging. - Link to v4: https://patch.msgid.link/1790845467.8631fc262581453bbf619ec5b2062170.1a0f6b5397a0003f66@vates.tech --- Changes since v3: - Drop v3 patches 1, 6 already upstreamed: 861e44a3ba8e ("xen/riscv: make Zihintpause no longer a required extension") 469d83d42f5c ("docs/riscv: sync required ISA extensions with required_extensions[]") - Add trailers (A-by and/or R-by). - Rename patch 3 to ("xen/riscv: always preset A/D bits in G-stage PTEs") as it now always presets A/D bits instead of distinguish Svadu/Svade DT bindings cases. - Address review comments. - Link to v3: https://patch.msgid.link/1790699381.8631fc262581453bbf619ec5b2062170.1a0ee00218b000b504@vates.tech --- Changes since v2: - Drop v2 patches 5 and 6, already upstreamed: d8ca89f26c8a ("xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()") 08a898b93d21 ("xen/riscv: fix level_map_mask truncation on load_start") - Drop "xen/riscv: make Svpbmt no longer a required extension". It relaxed Svpbmt so boards without it, like the HiFive P550, could boot. But without Svpbmt, DMA-noncoherent devices do not snoop the CPU caches and can read stale data from DRAM. Mainline Linux has the same problem, which is explained and reproducible in [1]. Fixing it needs a lot of machinery we do not need yet, and Svpbmt is mandatory in RVA23, so keeping it required is simpler and safer. An RFC will follow with a fix inspired by [2]. - Add three new patches: docs/riscv: sync required ISA extensions with required_extensions[] xen/riscv: rename PTE "permissions" to "pte_flags" xen/riscv: use pte_is_valid() in pte_is_mapping() - Address review comments. [1] https://github.com/davidlohr/vanilla-kernel-sifive-p550/tree/master [2] https://lwn.net/Articles/996819/ --- 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 --- Changes in v11: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v10: https://patch.msgid.link/1793192679.8631fc262581453bbf619ec5b2062170.1a1829cd6d5000f79f@vates.tech --- Baptiste Le Duc (1): xen/riscv: probe the A/D update scheme if the DT advertises neither xen/arch/riscv/cpufeature.c | 69 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 ++++--- 2 files changed, 76 insertions(+), 6 deletions(-) --- base-commit: b07838dc463c18f9ca78806d0f05164b02d1cd14 change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Oct 30 13:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 13:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465686.1676155 (Exim 4.92) (envelope-from ) id 1xMmjt-0002Rm-Pn; Fri, 30 Oct 2026 13:33:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465686.1676155; Fri, 30 Oct 2026 13:33: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 1xMmjt-0002Rf-N2; Fri, 30 Oct 2026 13:33:49 +0000 Received: by outflank-mailman (input) for mailman id 1465686; Fri, 30 Oct 2026 13:33:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMmjr-0002RN-T3 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 13:33:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMmjr-0036bZ-2T for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:33:47 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae49cb0-2eae-0a2a0a5409dd-0a2a450ce5f6-42 for ; Fri, 30 Oct 2026 14:33:46 +0100 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 6ae49cba-f479-0a2a450c0019-b9ff1c2294a3-3 for ; Fri, 30 Oct 2026 14:33:46 +0100 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 1a18d043096000cae1.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 13:33:44 +0000 Received: from leducb.tail4c4a28.ts.net (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 9DAC48080D; Fri, 30 Oct 2026 14:33:43 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=uZekbsuzdZ47vjdPUnT6YTrIsIVlipeCtgmht957FgQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=UZrFhFb3TZH4ocAoT0K/buJVsYJzEps3oQcJTczBaF8pxQ0wc7Cq3fJtTdKorw0W00GYykkbJ XXMRPUuCz5rgxbFjmALj4+w7KhmTWjfufxAzZXM/NeEgkJzUdfWizGrMzemiFT17Puci7KhKosZ x2ZP4obeMpHHtm1egeVS5IhP05JqTg5h8w0orVs9gBbwsSX3AKg2THpVxr14g3IsGP40PRdNY/f iUkEObwNa66O8f4rYV3i/CJ8WugVWW2w7L7EL7/UFW4YqXp6nwT42uJ9oVM/VNF69HsZU8E514t lE893bFdhxYatRadHizJs0t9JmB0O4toBI98IXvR+zgQ== X-Zone-Loop: 06821ee805a64260789f1f52955a03fec0cbab4ea75c x-campaign-type: default x-transaction-id: 9a87e8d1-122f-4313-b5cd-6c98708f3d9c x-swg-uid: 01-0c9e93fb-8399-451c-94ea-7f547dc3c4c3 X-Mailer: Sweego Message-ID: <1793367224.8631fc262581453bbf619ec5b2062170.1a18d043096000cae1@vates.tech> x-swg-bid: 1793367224.8631fc262581453bbf619ec5b2062170.1a18d043096000cae1 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: xen-devel@lists.xenproject.org Cc: Baptiste Le Duc , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alistair Francis , Connor Davis , Oleksii Kurochko , Zheng Zhang Subject: [PATCH v11 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither Date: Fri, 30 Oct 2026 14:33:39 +0100 In-Reply-To: <1793367142.8631fc262581453bbf619ec5b2062170.1a18d02efef000cae1@vates.tech> References: <1793367142.8631fc262581453bbf619ec5b2062170.1a18d02efef000cae1@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1793367077; l=8283; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Qo8d/oA2NwYtIy4Cpg226Vk6pvsySrr3THLteLMKNI0=; b=BrxUf9Q8yXJqlkqSk4HpsMMLISCjZFmpMasI/9Fhm9s4OxQFy+WII4by+s0DZKC5bjsskgzrD dfZbz5Ym3s1A23rj+XPJrnDUoAMpiCnvkAjm6KrD3dFWXbt6agM6LQh 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: 1793367223836 X-purgate-ID: tlsNG-d25034/1793367226-50D3CA5B-5CB75267/10/78276251493 X-purgate-type: spam X-purgate-size: 8285 p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when RISCV_ISA_EXT_svade is set, which is correct only if the device tree is. The privileged spec allows exactly two schemes for updating the PTE A and D bits: hardware sets them on access and on write, or accessing a page whose A and/or D bit is clear raises a page fault so that software can set them (ratified as Svade). Every implementation uses one of them, but platforms designed before Svade and Svadu were ratified, such as the HiFive Premier P550, may advertise neither. Trust the device tree when it advertises Svade and/or Svadu, as for any other extension. When it advertises neither, probe the scheme in effect and record the matching extension in riscv_isa, so that such device trees can be used as-is, and warn that it is missing from "riscv,isa" along with the probed result. Introduce probe_hw_ad_update(): alias the first page of the Xen image read-only through the FIX_MISC fixmap slot with its A and D bits clear, then load from it under an exception table fixup. Hardware updating is in effect if the load completes and the A bit is then set. The probe fails otherwise, whether the load faults or completes leaving the A bit clear. The A bit being set by a speculative access still implies Svadu, as Svade only allows A to be set by software. Add Svadu to the known ISA extensions so it can be told apart from Svade. The comment above the enum asks for new extensions to go at the bottom to avoid shuffling, a leftover from Linux where the IDs were macros with explicit values. Nothing depends on the enum values, so have the comment say that multi-letter extensions follow the order of riscv_isa_ext[]. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Baptiste Le Duc Reviewed-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes since v10: - collect Reviewed-by and Acked-by. - reword the comments around the probe load and the A bit check. - shorten the warning printed when the extension is probed. --- Changes since v9: - add a fence between the load and reading the PTE back, as nothing else orders the A bit update before the read. - explain why set_fixmap() can't be used and why any RAM page can be aliased. --- Changes since v8: - probe through a read-only alias of the Xen image and check the A bit, as A being set by a speculative access still implies Svadu. --- Changes since v7: - probe the A/D update scheme when the device tree advertises neither Svade nor Svadu and record the probed extension, instead of panicking. - drop Suggested-by. - update the patch's title/body accordingly. --- Changes since v6: - drop the probe and trust the device tree, only panic when it advertises neither Svade nor Svadu. - update the patch's title/body accordingly. - put svadu between svade and svpbmt in riscv_isa_ext_id. - rewrite the enum riscv_isa_ext_id comment. --- Changes since v5: - new patch, probe the A/D bits update scheme instead of trusting the device tree alone. --- xen/arch/riscv/cpufeature.c | 69 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 13 ++++--- 2 files changed, 76 insertions(+), 6 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 3d5bbd2228..dff590f68a 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -20,6 +20,7 @@ #include #include +#include #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -200,6 +201,7 @@ static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { RISCV_ISA_EXT_ENTRY(ssaia, ANY), RISCV_ISA_EXT_ENTRY(sstc, NONE), RISCV_ISA_EXT_ENTRY(svade, NONE), + RISCV_ISA_EXT_ENTRY(svadu, NONE), RISCV_ISA_EXT_ENTRY(svpbmt, NONE), }; @@ -630,6 +632,51 @@ const char *get_guest_isa_str(void) return guest_isa_str; } +/* + * Probe whether hardware updates the PTE A/D bits by reading through an alias + * mapping whose A and D bits are clear. Observing A set, even by a speculative + * access, implies Svadu, as Svade only allows A to be set by software. + */ +static bool __init probe_hw_ad_update(void) +{ + vaddr_t va = FIXMAP_ADDR(FIX_MISC); + pte_t *entry = &xen_fixmap[FIX_MISC]; + bool a_set = false; + + ASSERT(!pte_is_valid(*entry)); + + /* + * set_fixmap() can't be used, as pt_update_entry() always sets A and D. + * + * A and D belong to the PTE, not to the page, so a new PTE with A and D + * clear can point to any RAM page, whatever its other mappings. Use the + * first page of the Xen image, and map it read-only so that Xen can't be + * corrupted through this alias. + */ + write_pte(entry, pte_from_mfn(maddr_to_mfn(virt_to_maddr(_start)), + PTE_VALID | PTE_READABLE)); + flush_tlb_one_local(va); + + /* Read from the alias, handling page fault */ + asm_inline goto ( + "1: lw zero, 0(%[va])\n" + ASM_EXTABLE(1b, %l[out]) + : + : [va] "r" (va) + : "memory" + : out ); + + /* Check to see if hardware set A. */ + RISCV_FENCE(r, r); + a_set = read_pte(entry).pte & PTE_ACCESSED; + + out: + write_pte(entry, (pte_t){}); + flush_tlb_one_local(va); + + return a_set; +} + void __init riscv_fill_hwcap(void) { unsigned int i; @@ -674,6 +721,28 @@ void __init riscv_fill_hwcap(void) "Zihintpause unavailable: cpu_relax() gives the CPU no hint; " "wire up this platform's pause equivalent in cpu_relax()\n"); + /* + * The privileged spec allows exactly two schemes for updating the PTE A + * and D bits: + * 1) hardware sets them on access and on write; + * 2) accessing a page whose A and/or D bit is clear raises a page fault, + * so that software can set them (ratified as Svade). + * + * Every implementation uses one of them, but may predate the extensions + * and advertise neither. In that case, trust the hardware probe. + */ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) && + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu) ) + { + bool hw_update = probe_hw_ad_update(); + + __set_bit(hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade, + riscv_isa); + printk(XENLOG_WARNING + "Svade/Svadu missing from \"riscv,isa\" - probed as %s\n", + hw_update ? "svadu" : "svade"); + } + 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 2973eb13a5..b0a23be18e 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -8,13 +8,13 @@ #include /* - * These macros represent the logical IDs of each multi-letter RISC-V ISA - * extension and are used in the ISA bitmap. The logical IDs start from - * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single - * letter extensions and are used in enum riscv_isa_ext_id. + * Logical IDs of RISC-V ISA extensions, used as bit positions in the ISA + * bitmap. * - * New extensions should just be added to the bottom, rather than added - * alphabetically, in order to avoid unnecessary shuffling. + * Single-letter extensions use IDs below RISCV_ISA_EXT_BASE and are sorted + * alphabetically. Multi-letter extensions start from RISCV_ISA_EXT_BASE and + * follow the same order as riscv_isa_ext[] (see the ordering rules described + * above it). */ #define RISCV_ISA_EXT_BASE 26 @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_ssaia, RISCV_ISA_EXT_sstc, RISCV_ISA_EXT_svade, + RISCV_ISA_EXT_svadu, RISCV_ISA_EXT_svpbmt, RISCV_ISA_EXT_MAX }; -- 2.56.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 14:05:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 14:05:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465704.1676165 (Exim 4.92) (envelope-from ) id 1xMnEj-0007j2-0S; Fri, 30 Oct 2026 14:05:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465704.1676165; Fri, 30 Oct 2026 14:05: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 1xMnEi-0007iv-Se; Fri, 30 Oct 2026 14:05:40 +0000 Received: by outflank-mailman (input) for mailman id 1465704; Fri, 30 Oct 2026 14:05:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMnEh-0007ip-0w for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:05:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMnEg-00H4pc-5L for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:05:38 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4a426-8faa-0a2a0a5109dd-0a2a4505a880-32 for ; Fri, 30 Oct 2026 15:05:37 +0100 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 6ae4a431-4cb1-0a2a45050019-b9ff1c12a557-3 for ; Fri, 30 Oct 2026 15:05:37 +0100 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 1a18d215a7f000cae1.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 14:05:35 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 8D58781C1D; Fri, 30 Oct 2026 15:05:34 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=GWma1Wk/ghGMXX+amd5jAGFDfmKuuifSKybk+JNsvu0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=oYZG1awkk8eIeDVy6nZ/+K9Eq27wYyntRVgY51Tp4va+DG4ge6FAWNqbRo1RhChM0haQZON9g CqG92r9EqlUETpD1JUys0sahQDZGAOYSAQ4As/gUEoUGjm4WghtOsvGTK1Z09K/k7O6572h2eB2 ZnR7SNrSBUj07R8NpBJ8xUWv45qpatu5ujZUNbEj+rXYLKsPvKJHmQhPuLVaf8FtPqJ3+fYIBdw Z98zwYGZSKo9dUienczH2IaMN6Eg0QwejqCCCTuShzlOlOuMFEisGkR1hGRvyskLxfSBSdEAyIZ chFsACb5qXZu0i7WWHvgGylQo4y/zNQTfW/dgykjt9OA== X-Zone-Loop: ba1b6aadd156caf1609cc4f82934c649c369ef989c1f x-campaign-type: default x-transaction-id: faa22d6d-73e1-48dc-aca9-ba9a60eddfa8 x-swg-uid: 01-bf323b27-c6f3-4d49-a8c6-fc21271586a6 X-Mailer: Sweego Message-ID: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> x-swg-bid: 1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Michal Orzel , Julian Vetter Subject: [PATCH v2 0/4] tools/ocaml: bindings needed to build ARM domains Date: Fri, 30 Oct 2026 15:05:29 +0100 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.330.7ff4f4efefd786fa.1a18d2157da.bbbdb346bb00492b=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793369135066 X-purgate-ID: tlsNG-c201ff/1793369137-F68B62A1-7DDCF80B/0/0 X-purgate-type: clean X-purgate-size: 1813 ---=Part.330.7ff4f4efefd786fa.1a18d2157da.bbbdb346bb00492b=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Andrew for your review and valuable insights! I have addressed your remarks=2E I have added 2 new patches=2E As you suggested I have made the more generic paging mempool domctls the default for sizing a domain's paging pool=2E The only issue I had is that on x86, these arch_{get,set}_paging_mempool_size() functions reject PV domains=2E But you already added a "TODO: Relax in due course"=2E So, I did this, keeping the check only for builds without CONFIG_SHADOW_PAGING=2E The last patch then reimplements shadow_allocation_{get,set} on top of the new bindings, keeping their MBytes based interface=2E What do you think? Signed-off-by: Julian Vetter --- Changes in v2: - Patch 2: convert the domid before the blocking section, and check it for truncation - Patches 3 and 4: new --- Julian Vetter (4): tools/ocaml: expose the supported guest GIC versions in physinfo tools/ocaml: add bindings for the paging mempool size x86/paging: allow the paging mempool size domctls for PV domains tools/ocaml: implement shadow_allocation_{get,set} via the paging mempool tools/ocaml/libs/xc/xenctrl=2Eml | 23 ++++++++++++++--- tools/ocaml/libs/xc/xenctrl=2Emli | 12 ++++++--- tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 40 +++++++++++++++++------------ xen/arch/x86/mm/paging=2Ec | 4 +-- 4 files changed, 52 insertions(+), 27 deletions(-) -- 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.330.7ff4f4efefd786fa.1a18d2157da.bbbdb346bb00492b=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 30 14:08:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 14:08:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465713.1676173 (Exim 4.92) (envelope-from ) id 1xMnHt-0008Js-Cj; Fri, 30 Oct 2026 14:08:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465713.1676173; Fri, 30 Oct 2026 14: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 1xMnHt-0008Jl-9x; Fri, 30 Oct 2026 14:08:57 +0000 Received: by outflank-mailman (input) for mailman id 1465713; Fri, 30 Oct 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 1xMnHr-0008JZ-Nl for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:08:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMnHr-000Afr-4P for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:08:55 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4a4f3-8faa-0a2a0a5109dd-0a2a450c83b6-10 for ; Fri, 30 Oct 2026 15:08:55 +0100 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 6ae4a4f6-f479-0a2a450c0019-b9ff1c1298d7-3 for ; Fri, 30 Oct 2026 15:08:55 +0100 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 1a18d245cab000cae1.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 14:08:52 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id BFD4781C1D; Fri, 30 Oct 2026 15:08:51 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=I0GWl54gYW9YA5U403LKvyRlmOrgH7YQjnZvSskAg7I=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=W2ddJ4AU/BwUQLzbUn8/X/1eLDrwMkFQBzGYotnB9e11Qbg2gwucBfK7mnpqmyDWiRrXjMLhb zmX+z8bw8Oa7LRMtvI45yZW1BxIL9c56Y+Cy8E0VP+i0tbMiOIFOVwGRK+sVbE+mKfbjC+9JyQR nOm5MG44yoMJm5tPuEbs953bMzwBIRO/+fWXfQa/NNdu+fJwQyfOFja0lGP4REZQlTf9+v8WXru HseFEIjVO2MGBQJaRjDW/CeicZG3XhezBDBsx5SEhFRaSYpcMbQiCPthbGO9XmovGw5K+0usDD6 ZkbH/WunSr/z2rc9KL8u22lQRyYYB8DjDP5agwB5CJFg== X-Zone-Loop: 96153a55cb84203ebdffed98da797e3e1eca41511439 x-campaign-type: default x-transaction-id: 89358555-8257-477e-aad6-ad1c66c61ed5 x-swg-uid: 01-a9c21b65-f16e-4d30-968f-dc6cf764c965 X-Mailer: Sweego Message-ID: <1793369332.8631fc262581453bbf619ec5b2062170.1a18d245cab000cae1@vates.tech> x-swg-bid: 1793369332.8631fc262581453bbf619ec5b2062170.1a18d245cab000cae1 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Michal Orzel , Julian Vetter Subject: [PATCH 1/4] tools/ocaml: expose the supported guest GIC versions in physinfo Date: Fri, 30 Oct 2026 15:08:44 +0100 In-Reply-To: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> References: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.333.dcc6e9d84d26e262.1a18d245a2b.4ee1619b60fdcd0a=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793369332268 X-purgate-ID: tlsNG-d25034/1793369335-01CC3A5B-1A50D061/0/0 X-purgate-type: clean X-purgate-size: 3009 ---=Part.333.dcc6e9d84d26e262.1a18d245a2b.4ee1619b60fdcd0a=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Since XEN_DOMCTL_CONFIG_GIC_NATIVE was removed, the toolstack has to choose a concrete GIC_V2 or GIC_V3 version itself when creating an ARM domain=2E libxl and the Python bindings do so via XEN_SYSCTL_physinfo, but the OCaml physinfo stub only extracts the SVE vector length on ARM, so an OCaml toolstack has no way to select the GIC version=2E Add gic_v2 and gic_v3 to arm_physinfo_caps and populate them using arch_capabilities_arm_gic_v2/v3(), as is done for the Python bindings=2E Signed-off-by: Julian Vetter --- Changes in v2: - No changes --- tools/ocaml/libs/xc/xenctrl=2Eml | 2 ++ tools/ocaml/libs/xc/xenctrl=2Emli | 2 ++ tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 7 ++++++- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/tools/ocaml/libs/xc/xenctrl=2Eml b/tools/ocaml/libs/xc/xenctr= l=2Eml index 582897af6d=2E=2E37e41879bb 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Eml +++ b/tools/ocaml/libs/xc/xenctrl=2Eml @@ -134,6 +134,8 @@ type physinfo_cap_flag =3D type arm_physinfo_caps =3D { sve_vl: int; + gic_v2: bool; + gic_v3: bool; } =20 type x86_physinfo_cap_flag diff --git a/tools/ocaml/libs/xc/xenctrl=2Emli b/tools/ocaml/libs/xc/xenct= rl=2Emli index 9414b87164=2E=2E7a0dd7d8ba 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Emli +++ b/tools/ocaml/libs/xc/xenctrl=2Emli @@ -119,6 +119,8 @@ type physinfo_cap_flag =3D type arm_physinfo_caps =3D { sve_vl: int; + gic_v2: bool; + gic_v3: bool; } =20 type x86_physinfo_cap_flag diff --git a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index c15a3428da=2E=2Ee0c435e346 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -35,6 +35,7 @@ #define XC_WANT_COMPAT_MAP_FOREIGN_API #include #include +#include #include =20 #include "mmap_stubs=2Eh" @@ -880,11 +881,15 @@ CAMLprim value physinfo_arch_caps(const xc_physinfo_= t *info) =20 tag =3D 0; /* tag ARM */ =20 - arch_obj =3D caml_alloc_tuple(1); + arch_obj =3D caml_alloc_tuple(3); =20 Store_field(arch_obj, 0, Val_int(MASK_EXTR(info->arch_capabilities, XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK) * 128)); + Store_field(arch_obj, 1, + Val_bool(arch_capabilities_arm_gic_v2(info->arch_capabilities))); + Store_field(arch_obj, 2, + Val_bool(arch_capabilities_arm_gic_v3(info->arch_capabilities))); =20 #elif defined(__i386__) || defined(__x86_64__) =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.333.dcc6e9d84d26e262.1a18d245a2b.4ee1619b60fdcd0a=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 30 14:08:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 14:08:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465714.1676182 (Exim 4.92) (envelope-from ) id 1xMnHu-0008WR-K1; Fri, 30 Oct 2026 14:08:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465714.1676182; Fri, 30 Oct 2026 14:08: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 1xMnHu-0008WI-HE; Fri, 30 Oct 2026 14:08:58 +0000 Received: by outflank-mailman (input) for mailman id 1465714; Fri, 30 Oct 2026 14:08:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMnHs-0008Jf-DK for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:08:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMnHr-000Afr-Q9 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:08:55 +0100 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4a4f3-8faa-0a2a0a5109dd-0a2a450c83b6-14 for ; Fri, 30 Oct 2026 15:08:55 +0100 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 6ae4a4f6-f479-0a2a450c0019-b9ff1c1298d7-4 for ; Fri, 30 Oct 2026 15:08:55 +0100 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 1a18d245f17000cae1.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 14:08:53 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 96EEF82EC1; Fri, 30 Oct 2026 15:08:52 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=k92DauRa8Aq7sk1kAZZmTjvyGWcyOii8gIYs1IrbVOQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=jmeyNGCyNfpQSxIg64Bz4VRiU1Nlu/nxJirkrq/vXcTzsKHqLNtbe77f39TN6qiViUJgFrY94 /RDxJDSYydMdZAq+UnZIJnRho+FXt/5U9rELKmoAkaIrksGKK+IzpDkQQuaJFLqDTzCKMmBMhAG b67QxAnp11IZYzTEGvjJG0Wg5lvfVMKFqrf9VtFkeFK2+7Y7PiWBMr6UqrwZaEHmhFNgiumlWzo JFOLiNnaPSvoeunHAELx8+AsDuWWtpDe/KBT1y8KhOeqhJd0YaGIIFz5896JAC/yZPjE0eAjfUv Ph9gdB4ZOwc8EUv+PKmYfhxzt6JElEvOn8buTQuR8lKQ== X-Zone-Loop: 832c1f6d32c9db4b28ee4aa0e7a238a43bacfbc0fac7 x-campaign-type: default x-transaction-id: a06ed042-90e2-44be-9d0b-03f5893b6457 x-swg-uid: 01-a15a7726-933b-49ab-8ac6-a7d521099dbf X-Mailer: Sweego Message-ID: <1793369333.8631fc262581453bbf619ec5b2062170.1a18d245f17000cae1@vates.tech> x-swg-bid: 1793369333.8631fc262581453bbf619ec5b2062170.1a18d245f17000cae1 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Michal Orzel , Julian Vetter Subject: [PATCH 2/4] tools/ocaml: add bindings for the paging mempool size Date: Fri, 30 Oct 2026 15:08:45 +0100 In-Reply-To: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> References: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.334.6bba1527ddbe6e60.1a18d245d6a.bf2e308db7509232=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793369333098 X-purgate-ID: tlsNG-d25034/1793369335-030D9A5B-68128364/0/0 X-purgate-type: clean X-purgate-size: 4422 ---=Part.334.6bba1527ddbe6e60.1a18d245d6a.bf2e308db7509232=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The OCaml bindings only expose the shadow_allocation_{get,set} functions, which use XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION=2E These are x86-only, on ARM they fail with -ENOSYS=2E So, an OCaml toolstack has no way to size the P2M pool of an ARM domain, which libxl does via XEN_DOMCTL_set_paging_mempool_size=2E So, add a pair of functions paging_mempool_size_{get,set}, which just wrap xc_{get,set}_paging_mempool_size()=2E Signed-off-by: Julian Vetter --- Changes in v2: - Convert domid before blocking section - Check domid for truncation --- tools/ocaml/libs/xc/xenctrl=2Eml | 5 ++++ tools/ocaml/libs/xc/xenctrl=2Emli | 4 +++ tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 41 +++++++++++++++++++++++++++++ 3 files changed, 50 insertions(+) diff --git a/tools/ocaml/libs/xc/xenctrl=2Eml b/tools/ocaml/libs/xc/xenctr= l=2Eml index 37e41879bb=2E=2E55cfc2e9a2 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Eml +++ b/tools/ocaml/libs/xc/xenctrl=2Eml @@ -283,6 +283,11 @@ external shadow_allocation_set: handle -> domid -> in= t -> unit external shadow_allocation_get: handle -> domid -> int =3D "stub_shadow_allocation_get" =20 +external paging_mempool_size_set: handle -> domid -> int64 -> unit + =3D "stub_xc_set_paging_mempool_size" +external paging_mempool_size_get: handle -> domid -> int64 + =3D "stub_xc_get_paging_mempool_size" + external evtchn_alloc_unbound: handle -> domid -> domid -> int =3D "stub_xc_evtchn_alloc_unbound" external evtchn_reset: handle -> domid -> unit =3D "stub_xc_evtchn_reset" diff --git a/tools/ocaml/libs/xc/xenctrl=2Emli b/tools/ocaml/libs/xc/xenct= rl=2Emli index 7a0dd7d8ba=2E=2E0d5cc94198 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Emli +++ b/tools/ocaml/libs/xc/xenctrl=2Emli @@ -210,6 +210,10 @@ external shadow_allocation_set : handle -> domid -> i= nt -> unit =3D "stub_shadow_allocation_set" external shadow_allocation_get : handle -> domid -> int =3D "stub_shadow_allocation_get" +external paging_mempool_size_set : handle -> domid -> int64 -> unit + =3D "stub_xc_set_paging_mempool_size" +external paging_mempool_size_get : handle -> domid -> int64 + =3D "stub_xc_get_paging_mempool_size" external evtchn_alloc_unbound : handle -> domid -> domid -> int =3D "stub_xc_evtchn_alloc_unbound" external evtchn_reset : handle -> domid -> unit =3D "stub_xc_evtchn_reset= " diff --git a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index e0c435e346=2E=2E307bfa031d 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -1259,6 +1259,47 @@ CAMLprim value stub_shadow_allocation_set(value xch= _val, value domid, CAMLreturn(Val_unit); } =20 +CAMLprim value stub_xc_get_paging_mempool_size(value xch_val, value domid= ) +{ + CAMLparam2(xch_val, domid); + xc_interface *xch =3D xch_of_val(xch_val); + uint32_t c_domid =3D Long_val(domid); + uint64_t c_size; + int ret; + + if (c_domid !=3D Long_val(domid)) + caml_invalid_argument("domid"); + + caml_enter_blocking_section(); + ret =3D xc_get_paging_mempool_size(xch, c_domid, &c_size); + caml_leave_blocking_section(); + if (ret !=3D 0) + failwith_xc(xch); + + CAMLreturn(caml_copy_int64(c_size)); +} + +CAMLprim value stub_xc_set_paging_mempool_size(value xch_val, value domid= , + value size) +{ + CAMLparam3(xch_val, domid, size); + xc_interface *xch =3D xch_of_val(xch_val); + uint32_t c_domid =3D Long_val(domid); + uint64_t c_size =3D Int64_val(size); + int ret; + + if (c_domid !=3D Long_val(domid)) + caml_invalid_argument("domid"); + + caml_enter_blocking_section(); + ret =3D xc_set_paging_mempool_size(xch, c_domid, c_size); + caml_leave_blocking_section(); + if (ret !=3D 0) + failwith_xc(xch); + + CAMLreturn(Val_unit); +} + CAMLprim value stub_xc_domain_ioport_permission(value xch_val, value domi= d, value start_port, value nr_ports, value allow) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.334.6bba1527ddbe6e60.1a18d245d6a.bf2e308db7509232=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 30 14:08:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 14:08:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465715.1676189 (Exim 4.92) (envelope-from ) id 1xMnHv-0000B3-2S; Fri, 30 Oct 2026 14:08:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465715.1676189; Fri, 30 Oct 2026 14:08: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 1xMnHu-0000AA-Rz; Fri, 30 Oct 2026 14:08:58 +0000 Received: by outflank-mailman (input) for mailman id 1465715; Fri, 30 Oct 2026 14:08:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMnHu-0008Rs-Cr for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:08:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMnHt-003DNt-IZ for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:08:57 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4a4f6-e002-0a2a0a5209dd-0a2a4508e452-14 for ; Fri, 30 Oct 2026 15:08:57 +0100 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 6ae4a4f9-f659-0a2a45080019-b9ff1c22a4e9-3 for ; Fri, 30 Oct 2026 15:08:57 +0100 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 1a18d24619c000cae1.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 14:08:54 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 4252E82F34; Fri, 30 Oct 2026 15:08:53 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=o8TQ1P+wa0K8JL4R/1ysdsCGqdnNB6/v7Ew2w/ReJkA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=oq9v0sN7MfJQY9qzHGqmMuJ7AqkrSB94v67yTMb0pDBEgO78vdDuvZ0dPBY+KqzLYlVYfEL1M SHjDInjc8gZzpzXcAXIklrp91pD2aYQ+Mr0fL37aluSBNzWjleb4pfdRIgyJYAv9WUCQLK9X30E 99ejrld9kzUzb48ZSv3ngN/SNN2S1RQ09Xa/R8St6vvhMgiptyLK7TXFZ/8JqQb3h7IxlgOKVCE Yv/ycp4i5LwUSjHwreKVAG6YoJQAgIvZReG7Y2F/vjhOwbJkaDqX63CCiZER0twys9ofkHkiMgq hKtihEVOFondYIgkM2rVAjoeoSgQBSwZbB1tCsbj2L6g== X-Zone-Loop: 1d7ce52e3cd5272d3e7e1565dfb9c714c9d91c70a5f8 x-campaign-type: default x-transaction-id: f55b60e1-8ad0-4ca6-a326-cbd06090976f x-swg-uid: 01-97ce384e-d3dc-4328-97b3-d89d795e1be6 X-Mailer: Sweego Message-ID: <1793369334.8631fc262581453bbf619ec5b2062170.1a18d24619c000cae1@vates.tech> x-swg-bid: 1793369334.8631fc262581453bbf619ec5b2062170.1a18d24619c000cae1 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Michal Orzel , Julian Vetter Subject: [PATCH 3/4] x86/paging: allow the paging mempool size domctls for PV domains Date: Fri, 30 Oct 2026 15:08:46 +0100 In-Reply-To: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> References: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.335.19dd3c1b8ec5f8d1.1a18d245ff7.2292b32db68e63d3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793369333751 X-purgate-ID: tlsNG-c1860d/1793369337-CCB7187B-7DA21E8F/0/0 X-purgate-type: clean X-purgate-size: 2243 ---=Part.335.19dd3c1b8ec5f8d1.1a18d245ff7.2292b32db68e63d3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To have a more generic interface for sizing a domain's paging pool, replace XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION by XEN_DOMCTL_{get,set}_paging_mempool_size=2E These functions works on both x86 and ARM, and take an exact size in bytes instead of whole MBytes=2E But on x86, the paging mempool domctls currently reject PV domains with -EOPNOTSUPP=2E Toolstacks use SHADOW_OP_SET_ALLOCATION to size the shadow pool of PV domains too=2E So, as long as this restriction exists, x86 toolstacks can't switch to the new interface=2E The check is only needed on builds without CONFIG_SHADOW_PAGING, where shadow_set_allocation() is a stub containing ASSERT_UNREACHABLE()=2E So, only reject PV domains without CONFIG_SHADOW_PAGING=2E Signed-off-by: Julian Vetter --- Changes in v2: - New patch --- xen/arch/x86/mm/paging=2Ec | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/mm/paging=2Ec b/xen/arch/x86/mm/paging=2Ec index 4bb8d169de=2E=2E2ea7a472ab 100644 --- a/xen/arch/x86/mm/paging=2Ec +++ b/xen/arch/x86/mm/paging=2Ec @@ -959,7 +959,7 @@ int arch_get_paging_mempool_size(struct domain *d, uin= t64_t *size) { unsigned long pages; =20 - if ( is_pv_domain(d) ) /* TODO: Relax in due course *= / + if ( is_pv_domain(d) && !IS_ENABLED(CONFIG_SHADOW_PAGING) ) return -EOPNOTSUPP; =20 pages =3D d->arch=2Epaging=2Etotal_pages; @@ -976,7 +976,7 @@ int arch_set_paging_mempool_size(struct domain *d, uin= t64_t size) bool preempted =3D false; int rc; =20 - if ( is_pv_domain(d) ) /* TODO: Relax in due course *= / + if ( is_pv_domain(d) && !IS_ENABLED(CONFIG_SHADOW_PAGING) ) return -EOPNOTSUPP; =20 if ( size & ~PAGE_MASK || /* Non page-sized request? */ --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.335.19dd3c1b8ec5f8d1.1a18d245ff7.2292b32db68e63d3=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 30 14:09:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 14:09:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465716.1676200 (Exim 4.92) (envelope-from ) id 1xMnHy-0000YT-69; Fri, 30 Oct 2026 14:09:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465716.1676200; Fri, 30 Oct 2026 14:09: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 1xMnHy-0000YL-36; Fri, 30 Oct 2026 14:09:02 +0000 Received: by outflank-mailman (input) for mailman id 1465716; Fri, 30 Oct 2026 14:09:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMnHw-0000Wx-Vn for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 14:09:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMnHw-000AjJ-Ca for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:09:00 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4a4f7-8faa-0a2a0a5109dd-0a2a4507d978-10 for ; Fri, 30 Oct 2026 15:09:00 +0100 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 6ae4a4fa-b4ea-0a2a45070019-b9ff1c23b66f-3 for ; Fri, 30 Oct 2026 15:08:58 +0100 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 1a18d24641a000cae1.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 14:08:54 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id E0DE782EC1; Fri, 30 Oct 2026 15:08:53 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=akRbpxa6rSSnB9kOmzAWy65Mp6pHVNxd97FBerNkZVA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Nv2sJwg+RGQitsmZZbcgq78yCyswVX/Y0bnScEUZSV9ULw0yD8e9ZkocAl1tcqLXzh6SUoT+v YWWZxyV6132ogqJmq5ASc9vj71/BaOr0zpFXdlp2paK4MCdME86l8CR43TlBD8XiCWFj90U+5rI J/+mC6L/rWZq5Xnug5CUYTRBs4Si/wgu4/9bpKAFr2e0uF6schh6NCY8Pvd+iZnUrhNqCECYw40 lNJp9ofK6q+BtilPn2oahivdGl8hu82f6f6tPURAOwzi7DCEEToPkwywrLXM00D77S//XZt01Sj 4i8qlsmmUBmiiSmc4eao/HIsN/PORysNDKk1NK6Flwsw== X-Zone-Loop: 309c804213f67ee15da7d8131c69896683c29de84b98 x-campaign-type: default x-transaction-id: b05c41c3-0672-411d-80b0-44bb3e884cda x-swg-uid: 01-e5c6d8da-120c-4b28-b559-2cac11e6c6b0 X-Mailer: Sweego Message-ID: <1793369334.8631fc262581453bbf619ec5b2062170.1a18d24641a000cae1@vates.tech> x-swg-bid: 1793369334.8631fc262581453bbf619ec5b2062170.1a18d24641a000cae1 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: Andrew Cooper , Andrii Sultanov , Guillaume Thouvenin , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Michal Orzel , Julian Vetter Subject: [PATCH 4/4] tools/ocaml: implement shadow_allocation_{get,set} via the paging mempool Date: Fri, 30 Oct 2026 15:08:47 +0100 In-Reply-To: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> References: <1793369135.8631fc262581453bbf619ec5b2062170.1a18d215a7f000cae1@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.336.1d4a8481e7c47b6.1a18d246284.ce8a5cbd54ae1175=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793369334405 X-purgate-ID: tlsNG-ef75cf/1793369338-A4ECEAE4-B3EEAAFD/0/0 X-purgate-type: clean X-purgate-size: 5603 ---=Part.336.1d4a8481e7c47b6.1a18d246284.ce8a5cbd54ae1175=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To have a more generic interface for sizing a domain's paging pool, replace XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION by XEN_DOMCTL_{get,set}_paging_mempool_size=2E These functions works on both x86 and ARM, and take an exact size in bytes instead of whole MBytes=2E But the shadow_allocation_{get,set} functions can't be removed yet, because Xapi still uses them, and is built against the installed Xen's OCaml bindings, so removing them would break building existing Xapi releases against newer versions of Xen=2E Instead, reimplement them on top of paging_mempool_size_{get,set}, keeping their MBytes based interface and rounding the size up in the get function, and drop their C stubs=2E Once Xapi uses the new functions, the wrappers can be removed as well=2E Signed-off-by: Julian Vetter --- Changes in v2: - New patch --- tools/ocaml/libs/xc/xenctrl=2Eml | 18 +++++++++---- tools/ocaml/libs/xc/xenctrl=2Emli | 6 ++--- tools/ocaml/libs/xc/xenctrl_stubs=2Ec | 40 ----------------------------- 3 files changed, 15 insertions(+), 49 deletions(-) diff --git a/tools/ocaml/libs/xc/xenctrl=2Eml b/tools/ocaml/libs/xc/xenctr= l=2Eml index 55cfc2e9a2=2E=2E1f81bd3c4e 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Eml +++ b/tools/ocaml/libs/xc/xenctrl=2Eml @@ -278,16 +278,24 @@ external sched_credit_domain_set: handle -> domid ->= sched_control -> unit external sched_credit_domain_get: handle -> domid -> sched_control =3D "stub_sched_credit_domain_get" =20 -external shadow_allocation_set: handle -> domid -> int -> unit - =3D "stub_shadow_allocation_set" -external shadow_allocation_get: handle -> domid -> int - =3D "stub_shadow_allocation_get" - external paging_mempool_size_set: handle -> domid -> int64 -> unit =3D "stub_xc_set_paging_mempool_size" external paging_mempool_size_get: handle -> domid -> int64 =3D "stub_xc_get_paging_mempool_size" =20 +(* Compatibility wrappers for the old MiB based shadow_allocation_{get,se= t} + bindings, which used XEN_DOMCTL_SHADOW_OP_{GET,SET}_ALLOCATION=2E *) +let shadow_allocation_set handle domid mb =3D + let size =3D Int64=2Eshift_left (Int64=2Eof_int mb) 20 in + if mb < 0 || Int64=2Eshift_right size 20 <> Int64=2Eof_int mb then + invalid_arg "shadow_allocation_set"; + paging_mempool_size_set handle domid size + +(* Round up to whole MiB, like XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION did=2E= *) +let shadow_allocation_get handle domid =3D + let size =3D paging_mempool_size_get handle domid in + Int64=2Eto_int (Int64=2Eshift_right_logical (Int64=2Eadd size 0xfffffL)= 20) + external evtchn_alloc_unbound: handle -> domid -> domid -> int =3D "stub_xc_evtchn_alloc_unbound" external evtchn_reset: handle -> domid -> unit =3D "stub_xc_evtchn_reset" diff --git a/tools/ocaml/libs/xc/xenctrl=2Emli b/tools/ocaml/libs/xc/xenct= rl=2Emli index 0d5cc94198=2E=2E1083255f6d 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Emli +++ b/tools/ocaml/libs/xc/xenctrl=2Emli @@ -206,10 +206,8 @@ external sched_credit_domain_set : handle -> domid ->= sched_control -> unit =3D "stub_sched_credit_domain_set" external sched_credit_domain_get : handle -> domid -> sched_control =3D "stub_sched_credit_domain_get" -external shadow_allocation_set : handle -> domid -> int -> unit - =3D "stub_shadow_allocation_set" -external shadow_allocation_get : handle -> domid -> int - =3D "stub_shadow_allocation_get" +val shadow_allocation_set : handle -> domid -> int -> unit +val shadow_allocation_get : handle -> domid -> int external paging_mempool_size_set : handle -> domid -> int64 -> unit =3D "stub_xc_set_paging_mempool_size" external paging_mempool_size_get : handle -> domid -> int64 diff --git a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec b/tools/ocaml/libs/xc/x= enctrl_stubs=2Ec index 307bfa031d=2E=2E42402ef6e8 100644 --- a/tools/ocaml/libs/xc/xenctrl_stubs=2Ec +++ b/tools/ocaml/libs/xc/xenctrl_stubs=2Ec @@ -1219,46 +1219,6 @@ CAMLprim value stub_sched_credit_domain_set(value x= ch_val, value domid, CAMLreturn(Val_unit); } =20 -CAMLprim value stub_shadow_allocation_get(value xch_val, value domid) -{ - CAMLparam2(xch_val, domid); - CAMLlocal1(mb); - xc_interface *xch =3D xch_of_val(xch_val); - unsigned int c_mb; - int ret; - - caml_enter_blocking_section(); - ret =3D xc_shadow_control(xch, Int_val(domid), - XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION, - &c_mb, 0); - caml_leave_blocking_section(); - if (ret !=3D 0) - failwith_xc(xch); - - mb =3D Val_int(c_mb); - CAMLreturn(mb); -} - -CAMLprim value stub_shadow_allocation_set(value xch_val, value domid, - value mb) -{ - CAMLparam3(xch_val, domid, mb); - xc_interface *xch =3D xch_of_val(xch_val); - unsigned int c_mb; - int ret; - - c_mb =3D Int_val(mb); - caml_enter_blocking_section(); - ret =3D xc_shadow_control(xch, Int_val(domid), - XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, - &c_mb, 0); - caml_leave_blocking_section(); - if (ret !=3D 0) - failwith_xc(xch); - - CAMLreturn(Val_unit); -} - CAMLprim value stub_xc_get_paging_mempool_size(value xch_val, value domid= ) { CAMLparam2(xch_val, domid); --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.336.1d4a8481e7c47b6.1a18d246284.ce8a5cbd54ae1175=--- From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:16:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:16:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465773.1676218 (Exim 4.92) (envelope-from ) id 1xMoKy-0004T6-2o; Fri, 30 Oct 2026 15:16:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465773.1676218; Fri, 30 Oct 2026 15:16: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 1xMoKy-0004Sz-04; Fri, 30 Oct 2026 15:16:12 +0000 Received: by outflank-mailman (input) for mailman id 1465773; Fri, 30 Oct 2026 15:16:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoKw-0004ST-Jy for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:16:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoKw-000LGV-0l for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:16:10 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b49b-bab6-0a2a0a5309dd-0a2a4505a864-36 for ; Fri, 30 Oct 2026 16:16:10 +0100 Received: from [74.125.82.47] (helo=mail-dl1-f47.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4b8-4cb1-0a2a45050019-4a7d522fa441-3 for ; Fri, 30 Oct 2026 16:16:09 +0100 Received: by mail-dl1-f47.google.com with SMTP id a92af1059eb24-1438d9363fbso657325c88.0 for ; Fri, 30 Oct 2026 08:16:09 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.15.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:16: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=20260707 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=20260707; t=1793373368; x=1793978168; 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=etdm1aeawsytO27AD2qjJhqW2J7wH4UjI2RO2JWtCa8=; b=eFLJsk9WcHEneflZ+0FDNYor5aRmZAt13+fgbMrfmx5U7rBnHqS3C83HCduFtLSc0w oqDWdHD0QnV6D+77G005TzkJ2fxFkJV0hejcX0FPFtrFkcXOYcAm10KfXRksEMAjLlu6 5CQu1HMZsBeR7zKMo6IErmZqOhcSk0bZyalzITYaarNkCTD5jGtF6cxSfWe/ARiIfuJs 7rglUhps3IFD8o2FfPu1OsX+Mn91gzbK176scd28LH7hnoF7AmLcu6N2mHZ6stDtiqqr +/Wu8kzKveFb7Y6wuPqsfYD3/oRit5vtriXvxZPR2JXtS5j+Uu4FJDOhkqDgfBn+tOID NtVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373368; x=1793978168; 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=etdm1aeawsytO27AD2qjJhqW2J7wH4UjI2RO2JWtCa8=; b=w4qdOVZx8qf2GQsVdbu0KgVRJs5pG0db62jdDVDLQtnN+sTq9er3M2A0admQKbnueb 9wtcVoQJW1jSgy+G1qRrP4xZfSdLJLoZF/6gK4Xjn87t+jcVnhjch7OZ3iQu7tIgAYyF X5C+J0WnO3ZcmI60E7fOwgH+dpkQY+cUCKp8BqpzVfKiHt0LAD5cy6guW6oZpW/iY3bK yKnXiyxYxh6k4uZe0svd6Em+YVJik9PRjHKWMYKyMIgtRXC+Z+Wd6ztNjmTlTrI7Q/i/ rli37ulhnHvtHgSDYRLz+oAj09ywFcXQXZk49A2MES8PTaPMfMwuGBqTdOQB1Exol2qb cYdw== X-Forwarded-Encrypted: i=1; AKwUvBxI1kZQ+T2vxKMWRSprvAoWsMgasfkeDHONY/Chjj9DAXSzxMtP4lE6RagPqqtI8z91kOirxWEglUE=@lists.xenproject.org X-Gm-Message-State: AFq9FYK3AeaVfRZb1kBcPZfn+WT3LF+qSN48tjvizB6d6qMk9JbLctGM Pj2YceD0nYwbun/87NirhnjFe//XW7L20xPIo920b9v0AyCcWomAf62k X-Gm-Gg: AYBFou10h+TqQZ3O6mwky41QRGJ7MIHDIrjQOwykPOWo1BL2pUJlw3npyykhyUVYErY FchbeTJFooSIXrccasGFd+1uVrfCkqvhg55k7wmT08DWbNcmNo55wsdqhW7G3zH60aVOp+sgxA8 QOfVBWFAOATZUIi4/oBPY/439NXTNzPue4kSYno2Gwap3et4B7QvdZ9BmivG0ipb6vwUrZSauBJ rCmD7+MW+jC3WKHbkm2oEXxRssnwmJ8Jo9qSfUHm188CCLRj9VUXw4yVN/bPs8fZhzZ4SlHR8y3 mIiTDKc6Pz7U9jXGWYL1IXSYR5so3bjlMdmJAWxu/M92fjBcl010ULsTXBRTCnC69VwKy8/uFMc QCDwqoPqAc36NiZXhKAeQktnDYgrjJoY6ADGXP8I0qGfQL4ZkBFBlsHK/OAbaUeU9DZY+B1x6+M aHg0pF2bVtXyoU+TyxCFxW/AvNSNTg319GAjVn5owXUOyxVBe4V0/eBOVBXwBJnyqCB7evsgstZ 3PV51Tt2KALjKHAZLopXtrQ9nXsud4mohQz+3A6peNtHuIj4lHan40yE5ucSkLuchTSV/QH147m 7F9C3wibprk2bdUc4pHfyiImG6O890hwbJXSxBVs7G7lSAk20d0pDO/mgYeXKV9/7FzH0Q== X-Received: by 2002:a05:7022:ea57:b0:190:716:4822 with SMTP id a92af1059eb24-1ac599f506cmr3074840c88.8.1793373367717; Fri, 30 Oct 2026 08:16:07 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 01/15] hw/alpha: expand DEFINE_MACHINE in dp264.c Date: Fri, 30 Oct 2026 23:15:22 +0800 Message-ID: <20261030151539.1872-2-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793373369-F64B42A1-01679BC7/0/0 X-purgate-type: clean X-purgate-size: 1402 Expand DEFINE_MACHINE() for the clipper machine to clipper_machine_typeinfo and clipper_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/alpha/dp264.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c index f928e0cee82..83e9a0853c1 100644 --- a/hw/alpha/dp264.c +++ b/hw/alpha/dp264.c @@ -201,8 +201,10 @@ static void clipper_init(MachineState *machine) } } -static void clipper_machine_init(MachineClass *mc) +static void clipper_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Alpha DP264/CLIPPER"; mc->init = clipper_init; mc->block_default_type = IF_IDE; @@ -213,4 +215,16 @@ static void clipper_machine_init(MachineClass *mc) mc->default_nic = "e1000"; } -DEFINE_MACHINE("clipper", clipper_machine_init) +static const TypeInfo clipper_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("clipper"), + .parent = TYPE_MACHINE, + .class_init = clipper_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void clipper_machine_register_types(void) +{ + type_register_static(&clipper_machine_typeinfo); +} + +type_init(clipper_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:16:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:16:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465771.1676210 (Exim 4.92) (envelope-from ) id 1xMoKl-0004Ec-TO; Fri, 30 Oct 2026 15:15:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465771.1676210; Fri, 30 Oct 2026 15:15: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 1xMoKl-0004EV-PU; Fri, 30 Oct 2026 15:15:59 +0000 Received: by outflank-mailman (input) for mailman id 1465771; Fri, 30 Oct 2026 15:15:58 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoKk-0004EP-J1 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:15:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoKj-00272y-P2 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:15:57 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4a5-8faa-0a2a0a5109dd-0a2a450a8476-22 for ; Fri, 30 Oct 2026 16:15:57 +0100 Received: from [74.125.82.180] (helo=mail-dy1-f180.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4ac-f2d2-0a2a450a0019-4a7d52b4a817-3 for ; Fri, 30 Oct 2026 16:15:57 +0100 Received: by mail-dy1-f180.google.com with SMTP id 5a478bee46e88-35829219da8so2287187eec.0 for ; Fri, 30 Oct 2026 08:15:57 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.15.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:15: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=20260707 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Content-Type:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793373355; x=1793978155; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:content-type:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1Rg4bi/F0EGsPeT/kaQ1mX1hyEceGiWztvW5JiOyGZA=; b=pFjjXG8dATu8FpPVygTlVjIjDM464dFFElckrsSuoV51d7KShaMjOuycsvuTKkeVgw EJ1lrg+VreqOaNmWeh80XaXwMaBHaXMNGfDYUu4FsMmkO/4wH55TdCZdisiLPp8wrPbM zgdssfhMxHcvju30JQC9xHmBccDgX4+idZHHuvNiSyypGNa4EX2eANvT+fGLzrFrpptb nOHqoys7+I0utvIofyHUhgcbEi/Dn7bqJeDdV3eA4pL6S9DAceiNbPEUBuyiolstnNce 8VpRRa/pHlSszeBdBcy5SZpko75Q7TMqpwRQ0EsPvRGqjPTXv/csSi+S89XAYO8Okwji WCkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373355; x=1793978155; h=content-transfer-encoding:mime-version:content-type: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=1Rg4bi/F0EGsPeT/kaQ1mX1hyEceGiWztvW5JiOyGZA=; b=jupThNIxNUTXsRJoA/1utCl4Ffe0IOJHiN0OT5rfy2/XQz8zOzdXoQ7vobpkvSaUul BcHHpUNOe9bau0FyfTKOQ1MLVgoxIEdbeRJJYtnN9AMvNFGbIRBqfNoUF0P06MWFN9ab J1bqRhJXXcC0B7SqsOvlCRFQh4X3vO2h9Z9pbGCJMFoBSgVqrfAZq5qJ9UfCFWl+S0On DjTlNpHm+xuo95PaZc4lrbSgMsa8rCW3Q4y+luhQiBxiZY5JdgVQ6UNFZMGoeK8CSzGj Sz1lHglayoTx8HJsdF4Z+Otxcypl69lvhXjH6yIHHaM4woeravBA6e2Dxioq6qOLJ9uZ ybTA== X-Forwarded-Encrypted: i=1; AKwUvBwqHxeAhH/oxN+9rlPwc+wgsX4hQ65dgDDHyTnJhCuqVxlGefwMFJYq44rKSRMjBMhMbnhZRw4gwoM=@lists.xenproject.org X-Gm-Message-State: AFq9FYLWOF4z/HRVH8b463JFcQWjfloe5NYDmaKs3qaYkxHKvrhQAKMQ nCcDTvdh9vNSh0ubS9kLvZKi5R3JEEJ0hSsxdFL2E1CnnpZoJYcUsOjN X-Gm-Gg: AYBFou0PKO1ULZyEm06CwU7Z1qLh0I8nx225slEbpLLuwKDzQ5CL0xPuLfOXYdMp5ZF D2FE+NE6A0/q/jAw9oZPnVNhzfFELQHpMg5rm+V4TaCf/NOQVOtkY7OOuC3mFkUzshVRzrgswWN 2MTmB3A5CLDfoLO+gfUmSeEkfWidr3VRGRhmuqYm8KiOcAV7NBC6zFiJcwIAdeZ/nLp1S6XPFI0 FRvRKXl+hucLgmBS82zgcMzylww570pM7voc5q4sPNHkg7aBMKTuL7K+hOYj0AKMtq3YgobVTxJ 2y9BXWladRlTkCfbYAKe9J9Q3qTmsFl5My0aOFC5I3RVpR1subdAx1WmZEi59CqQdWK4g91A0Bj FceQbHHKEiX0ggeDHghlr3k8t1yn8wcdJNO6zYfLL1mhoEaHrEZEF+hFEG7asCAkFDPRjVbTvj6 eF9lqwQS91yKgUVTUl1XS0kOChGrSyrK7uk1Q/kWNE+zP2Rjg021qKBHfPCNdzZQAIh0cDsVU7I EjC/NcEOFm7WQ0rtb9pBaQlcNt/ZE+mMYDoSfUnrMVyDJI6k2jRhRBDvfckQu0bQ8mh/me4DVUi cSY7CKZueFwaVDqUSSmHwExfsWQPO/E8vDr0Xg5BpECD3huY X-Received: by 2002:a05:7022:f90d:b0:151:7831:e403 with SMTP id a92af1059eb24-1ac5b027fbfmr2873959c88.13.1793373355336; Fri, 30 Oct 2026 08:15:55 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration Date: Fri, 30 Oct 2026 23:15:21 +0800 Message-ID: <20261030151539.1872-1-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1793373357-5A1DDCFC-D0C1BF03/0/0 X-purgate-type: clean X-purgate-size: 3671 DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the type_init function that calls type_register_static(). A later change needs to pass a target mask into that registration, and the macros have no parameter for it. This series expands every caller first, with no behavior change, so the follow-up only replaces the type_register_static() call. Each machine file gains a class_init function, a TypeInfo, and a type_init function that calls type_register_static(). The last patch removes DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h. Yonggang Luo (15): hw/alpha: expand DEFINE_MACHINE in dp264.c hw/m68k: expand DEFINE_MACHINE for M68K machines hw/microblaze: expand DEFINE_MACHINE for MicroBlaze hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c hw/arm: expand DEFINE_MACHINE for ARM machines hw/riscv: expand DEFINE_MACHINE for RISC-V machines hw/core/null-machine: expand DEFINE_MACHINE hw/mips: expand DEFINE_MACHINE for MIPS machines hw/ppc: expand DEFINE_MACHINE for PowerPC machines hw/sh4: expand DEFINE_MACHINE in r2d.c hw/sparc: expand DEFINE_MACHINE in leon3.c hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c hw/xtensa: expand DEFINE_MACHINE in sim.c hw/xtensa: expand DEFINE_MACHINE in virt.c hw/core/boards: remove unused DEFINE_MACHINE* macros hw/alpha/dp264.c | 18 +++++++++-- hw/arm/bananapi_m2u.c | 18 +++++++++-- hw/arm/cubieboard.c | 19 +++++++++--- hw/arm/digic_boards.c | 18 +++++++++-- hw/arm/imx25_pdk.c | 18 +++++++++-- hw/arm/imx8mm-evk.c | 20 +++++++++--- hw/arm/integratorcp.c | 14 ++++++--- hw/arm/kzm.c | 18 +++++++++-- hw/arm/max78000fthr.c | 17 ++++++++-- hw/arm/mcimx6ul-evk.c | 18 +++++++++-- hw/arm/mcimx7d-sabre.c | 20 +++++++++--- hw/arm/msf2-som.c | 17 ++++++++-- hw/arm/netduino2.c | 17 ++++++++-- hw/arm/netduinoplus2.c | 17 ++++++++-- hw/arm/olimex-stm32-h405.c | 18 +++++++++-- hw/arm/orangepi.c | 19 +++++++++--- hw/arm/stm32vldiscovery.c | 18 +++++++++-- hw/core/null-machine.c | 18 +++++++++-- hw/m68k/an5206.c | 18 +++++++++-- hw/m68k/mcf5208.c | 18 +++++++++-- hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++-- hw/microblaze/xlnx-zynqmp-pmu.c | 19 ++++++++++-- hw/mips/boston.c | 18 +++++++++-- hw/mips/fuloong2e.c | 18 +++++++++-- hw/mips/malta.c | 12 ++++++-- hw/ppc/amigaone.c | 18 +++++++++-- hw/ppc/pegasos.c | 21 ++++++++----- hw/ppc/ppc440_bamboo.c | 18 +++++++++-- hw/ppc/prep.c | 18 +++++++++-- hw/ppc/sam460ex.c | 18 +++++++++-- hw/ppc/virtex_ml507.c | 18 +++++++++-- hw/riscv/boston-aia.c | 18 +++++++++-- hw/riscv/microblaze-v-generic.c | 18 +++++++++-- hw/sh4/r2d.c | 18 +++++++++-- hw/sparc/leon3.c | 18 +++++++++-- hw/tricore/tricore_testboard.c | 18 +++++++++-- hw/xenpv/xen_machine_pv.c | 18 +++++++++-- hw/xtensa/sim.c | 18 +++++++++-- hw/xtensa/virt.c | 18 +++++++++-- include/hw/core/boards.h | 48 ----------------------------- 40 files changed, 605 insertions(+), 142 deletions(-) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:16:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:16:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465775.1676227 (Exim 4.92) (envelope-from ) id 1xMoL9-0004ld-Cz; Fri, 30 Oct 2026 15:16:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465775.1676227; Fri, 30 Oct 2026 15: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 1xMoL9-0004lW-AN; Fri, 30 Oct 2026 15:16:23 +0000 Received: by outflank-mailman (input) for mailman id 1465775; Fri, 30 Oct 2026 15:16:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoL8-0004kn-5P for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:16:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoL7-000LJS-I8 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:16:21 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4bc-bab6-0a2a0a5309dd-0a2a45078a10-30 for ; Fri, 30 Oct 2026 16:16:21 +0100 Received: from [74.125.82.44] (helo=mail-dl1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4c4-b4ea-0a2a45070019-4a7d522ccd2d-3 for ; Fri, 30 Oct 2026 16:16:21 +0100 Received: by mail-dl1-f44.google.com with SMTP id a92af1059eb24-15943c9c005so1423761c88.1 for ; Fri, 30 Oct 2026 08:16:20 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.16.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08: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=20260707 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=20260707; t=1793373379; x=1793978179; 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=eLhsKCTjuKy4eSFshqKS/+IjBjdCXZJ8by/9qMkJXhQ=; b=qThnziT9fh2r9pq9dhjXhrvKofvJ5+uG3t+1kR98TlJD0fvzgAfi1ZejBPtOxvN6Vh zpGWHsQba1zbwX5tDpmjIBW1DOjh2fOkR6e00/94vt2h/1KYSFP2Xdx4A9wTAqCvm+S7 TkmLVCc0ZoWIC1/neKEDITKlrUJO1TwICVEKtBY1316ZfVrIfcc4kJiUD/9nzFOHRVDd s7Bqg77tbWAqwg8WI0ssRpOAS01AZUVMdA60g8iaAFbGOnx+KydzeER7SdeArxaZtTdP tB+wqX8MogNwHYExnK9ZZhdZoaozOdocsUFMCn3synsj84hCf982pmOaSd4uZOyTsKH7 2IPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373379; x=1793978179; 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=eLhsKCTjuKy4eSFshqKS/+IjBjdCXZJ8by/9qMkJXhQ=; b=KQzdPwxUTmSZUd8P3PD0ZDkqQpTAgc62rmAddQQv4Vtl8AeRXeQyw0pz/bcLK79nHW mdKA67qgrXG4bc974OPWjhZC1et9Ft40JH8RErB9iPIvoKAkSUETIH0LCdARWzAVehdq QnzqOPTIkFLd2egwUyqgv7cW8PxWHyQKKVxJjadyJ8jCQ3zLFDcjTk9AhwrVPw/lvRRK itcX2mqeLc8yM7AtNcayjP5GvpzcF8LF1iBCG/M7zCFUPenBFCPSsnZtqwUWgfk31LSe LuoGNGQEJt/akkEd+DyyhwDhgdK5Sfrxzl0d00gld1hU4JgIXhwialixymjz+72fXE+E /fUg== X-Forwarded-Encrypted: i=1; AKwUvBz963+0fFSK+noPAVbE6Qw01T2BzIGDi697uW3gQjaBvDxOo0GzzSYCrkh4oN9YZd8rU1xAR+UZc+o=@lists.xenproject.org X-Gm-Message-State: AFq9FYIw7tMRRPEmDBT7vDkWGGeSh1YcpDhMyTWHdj+n9dNppM/XZwKA HmP4tsfhKU5P+daJJIYmOfUPCaLNhNfeqPRPaA3HKSg3DYE4Cnpm9Ahn X-Gm-Gg: AYBFou1oKodPlhlci9rnH5M6888ZPVA4Ym8/A//QJJs3oo4W2G69R3IrIP5IsmQlXGV QfXkNr90boDDmcfGNqEDmDcetsHnuEyHSQW9+cQwrfMugPp45wQmEvUkEJpP3nehjaagAeJLhFi 8TGNroen5CJhOI8cVmryAHoSkFC1WdQOEW1qPLg0NbWB6MAW9r94bt5v3t9N9Kbnuzpcs5bGzcO 620ZWtPqPfZoh4yxJewvaOglMj3L+fagbDDFMwU+eNQ5uXM/3B5HroODdxs48Q9pWUa/LcY0xt5 LDVXTcSMz6dGCSVsIy7s29whi0pjqBVl+R5dKSsaJ24/39XSXZj15k8Of2K7pKxhS/I1LqUPB+S z4gmtEgeoeVnfxslWLWl45amMuySrZKV0vc1JKm6MzERZrpUfM1QW8GzK8ckGynPn2ELMLvcDBZ UD/TSQa23HQVkr9P1es4kEn13DY8qdxx8fWs3x3W4qAyl07wWhcCiBjzul3QCF4ONuczW1rrH6Q kbk7JEtF8RmGmHAu0nCp4XJ4FFDItVZfzLyZEAunpQpKQQ7/dHc90FtRjsh3GmAcwS7FRoI/3GB oZoJPdjiDR7Z41rgw/fhsyV0h9dH9bV4bxJIixdhl7TEckEplZsCbR+t5Lm3jmJnTtiEhw== X-Received: by 2002:a05:7022:e27:b0:14d:cb67:afc4 with SMTP id a92af1059eb24-1ac5e8e1e4bmr4866883c88.41.1793373379151; Fri, 30 Oct 2026 08:16:19 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 02/15] hw/m68k: expand DEFINE_MACHINE for M68K machines Date: Fri, 30 Oct 2026 23:15:23 +0800 Message-ID: <20261030151539.1872-3-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793373381-34ECEAE4-5F473C3B/0/0 X-purgate-type: clean X-purgate-size: 2520 Expand DEFINE_MACHINE() in hw/m68k/an5206.c and hw/m68k/mcf5208.c to explicit TypeInfo and type_init() functions calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/m68k/an5206.c | 18 ++++++++++++++++-- hw/m68k/mcf5208.c | 18 ++++++++++++++++-- 2 files changed, 32 insertions(+), 4 deletions(-) diff --git a/hw/m68k/an5206.c b/hw/m68k/an5206.c index 1acd2fbdfb3..8838563cb3e 100644 --- a/hw/m68k/an5206.c +++ b/hw/m68k/an5206.c @@ -93,12 +93,26 @@ static void an5206_init(MachineState *machine) env->pc = entry; } -static void an5206_machine_init(MachineClass *mc) +static void an5206_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Arnewsh 5206"; mc->init = an5206_init; mc->default_cpu_type = M68K_CPU_TYPE_NAME("m5206"); mc->default_ram_id = "an5206.ram"; } -DEFINE_MACHINE("an5206", an5206_machine_init) +static const TypeInfo an5206_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("an5206"), + .parent = TYPE_MACHINE, + .class_init = an5206_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void an5206_machine_register_types(void) +{ + type_register_static(&an5206_machine_typeinfo); +} + +type_init(an5206_machine_register_types) diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c index a8068c91f24..5c3ab48ddde 100644 --- a/hw/m68k/mcf5208.c +++ b/hw/m68k/mcf5208.c @@ -389,8 +389,10 @@ static void mcf5208evb_init(MachineState *machine) env->pc = entry; } -static void mcf5208evb_machine_init(MachineClass *mc) +static void mcf5208evb_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "MCF5208EVB"; mc->init = mcf5208evb_init; mc->is_default = true; @@ -398,4 +400,16 @@ static void mcf5208evb_machine_init(MachineClass *mc) mc->default_ram_id = "mcf5208.ram"; } -DEFINE_MACHINE("mcf5208evb", mcf5208evb_machine_init) +static const TypeInfo mcf5208evb_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("mcf5208evb"), + .parent = TYPE_MACHINE, + .class_init = mcf5208evb_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void mcf5208evb_machine_register_types(void) +{ + type_register_static(&mcf5208evb_machine_typeinfo); +} + +type_init(mcf5208evb_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:16:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:16:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465778.1676237 (Exim 4.92) (envelope-from ) id 1xMoLK-00058q-Kt; Fri, 30 Oct 2026 15:16:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465778.1676237; Fri, 30 Oct 2026 15:16: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 1xMoLK-00058j-HL; Fri, 30 Oct 2026 15:16:34 +0000 Received: by outflank-mailman (input) for mailman id 1465778; Fri, 30 Oct 2026 15:16:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoLJ-00056d-36 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:16:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoLI-0027EM-GM for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:16:32 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4c3-8faa-0a2a0a5109dd-0a2a4509a714-20 for ; Fri, 30 Oct 2026 16:16:32 +0100 Received: from [74.125.82.54] (helo=mail-dl1-f54.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4ce-be1a-0a2a45090019-4a7d5236ec05-3 for ; Fri, 30 Oct 2026 16:16:32 +0100 Received: by mail-dl1-f54.google.com with SMTP id a92af1059eb24-15ea896ddc8so1347362c88.0 for ; Fri, 30 Oct 2026 08:16:31 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.16.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:16: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=20260707 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=20260707; t=1793373390; x=1793978190; 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=CnMqBd/JBHGwVaxrghEFIqcYT1aAnIXyDuq/h1Z92iw=; b=hoMBioslhG2WYzQgz1XhDQBar5iuZHBzBgFBo4QD8tk9TiMCzoH4ocX7T1IENh0jpa AwpagGC55yVqnb0WQAOe5ikxpCawZK43RMR3hM5j/f1R2EZERyYrBEBMLrtDMGc/FsDZ ypX2SW+XRi70OYuurpSQB9Fa/lHzS3YovNYgV/rx791F8skwVXqkU6Yqg9CRDPyqdXQF VUvwHDF/IVUtMQjByTAkaLzZLwAhu8K6MLyFLpyJHNXUwOqqzIpj8MK0id0uIGhhUp8P PdujZL1O4YuE9WoVIPicd38E7YuN4Q9/JB+l+kzfqdo8IULG9pcvfc95hSqZf6SIoVJf rUhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373390; x=1793978190; 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=CnMqBd/JBHGwVaxrghEFIqcYT1aAnIXyDuq/h1Z92iw=; b=FpN6mlJXNFug/BzbAV5wI2cXuz5CbQxEmXSjszdynwUY6Vd7T6hBSP3Dk1XDPdNoP8 bU84ALbolu9JMXxVAj52WgThd5zoSAw2OcDBF4KxgQnZpzUXqhNU13qHSz0CuoNPJpPE fXlLfPuOVgW4zOdKZ/9yx+9k0F6QA+1nICKtRSbTsFCgVSB5NDE4ls6H8+uA4NQVI1x7 9mNLar+IetNVad9ILpQOs8fJ+zWEO2jj05+FY/Y/afJUQ3EwEzkgp8IefJ3But4MrzdF GIESDC2IQc/xrFEJ5LkrHxqLDP2YWqhnqeN3J291AfePHZOVyfS3ZlbDD291HZou1kgk oPsw== X-Forwarded-Encrypted: i=1; AKwUvByAr3owYrTbgZrztq1om9OzMmasunSA0OGsE97S/JpUeHa6gkwG+MK/yUC8Q/nWHTCUFEDppDSaYBE=@lists.xenproject.org X-Gm-Message-State: AFq9FYKZfhzVTYh9j2eE2D3X3z4Z9odk4BFv8QQRVbJ+2mGVOKTRqCeF 1s7qdIk+LwFk9FVIAJ6hjg6Nh6ZHVXdjFOd3rAeAuOf6g5Cy8vWXg0iA X-Gm-Gg: AYBFou3pAe5Pmjcv9AwEy2syOfnnS9yvmRYUNqle/c7dtxP2D2VwKdMx2+cBgxdHvgL GkNY8jMP5Fau5JtKOC6yglBz75BSy0xOSbGtJ/3ZSrI3r0rbwhmZ5MTvGfAImXBJ0yyNjQRz3Sz UvvVsyUUGc3OtwQkz4iDwfOlax/xR3fE9jr0XLR6WWh1uZtmV5mN5PSdIDoyYL/wAb1mJHTxzLt ZTURjvwNahJHMLUtz/OoXO/OGJC8b+0aXQGwH6OHz0JlbCrOdrHXQYPBCNCck/M4OXt7ixVVzWh jRYwhHFo9hjb00wc7KdEkNBORbwsg3gxEJERQqFp+/QFbuaFkXaEVRhUH8yXNTVQJaPodRaAA3N B9BgwJtSwbWKSSY7kH1kt8o+J8iRW84WnHR2hzN9VkA/AurDoz/+n3pAWUd6in75OiGvxXKV3NW NPPvHoshkh5puWxfylH5Wb6cI9TEC8i66dvAfKjDv5MoAeTK3cpUoWkDKIZ92tTz+ebpDiVOWFy 2xcCd6r7T6RIhSaX2z0a7/fOixxAM+ixyJ5kDs37TcItEbOF1LH8cpgbVuSsGesCZoSSeeZzx6k rpjvAi4SU1t3g51amRI9KozJtOmnz2dbtNlEKqFqpGj71FX2 X-Received: by 2002:a05:701b:4502:10b0:163:fd28:5658 with SMTP id a92af1059eb24-1ac5b02289fmr3445161c88.22.1793373390156; Fri, 30 Oct 2026 08:16:30 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 03/15] hw/microblaze: expand DEFINE_MACHINE for MicroBlaze Date: Fri, 30 Oct 2026 23:15:24 +0800 Message-ID: <20261030151539.1872-4-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1793373392-BE4DB034-EFC43F42/0/0 X-purgate-type: clean X-purgate-size: 2804 Expand DEFINE_MACHINE() in hw/microblaze/petalogix_ml605_mmu.c and hw/microblaze/xlnx-zynqmp-pmu.c to explicit TypeInfo and type_init() functions calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/microblaze/petalogix_ml605_mmu.c | 19 +++++++++++++++++-- hw/microblaze/xlnx-zynqmp-pmu.c | 19 +++++++++++++++++-- 2 files changed, 34 insertions(+), 4 deletions(-) diff --git a/hw/microblaze/petalogix_ml605_mmu.c b/hw/microblaze/petalogix_ml605_mmu.c index 8f9f54ff1e2..393eeba76f5 100644 --- a/hw/microblaze/petalogix_ml605_mmu.c +++ b/hw/microblaze/petalogix_ml605_mmu.c @@ -214,10 +214,25 @@ petalogix_ml605_init(MachineState *machine) } -static void petalogix_ml605_machine_init(MachineClass *mc) +static void petalogix_ml605_machine_class_init(ObjectClass *oc, + const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "PetaLogix linux refdesign for xilinx ml605 (little endian)"; mc->init = petalogix_ml605_init; } -DEFINE_MACHINE("petalogix-ml605", petalogix_ml605_machine_init) +static const TypeInfo petalogix_ml605_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("petalogix-ml605"), + .parent = TYPE_MACHINE, + .class_init = petalogix_ml605_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void petalogix_ml605_machine_register_types(void) +{ + type_register_static(&petalogix_ml605_machine_typeinfo); +} + +type_init(petalogix_ml605_machine_register_types) diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c index 00154236bf8..d3ade9faeee 100644 --- a/hw/microblaze/xlnx-zynqmp-pmu.c +++ b/hw/microblaze/xlnx-zynqmp-pmu.c @@ -179,10 +179,25 @@ static void xlnx_zynqmp_pmu_init(MachineState *machine) NULL); } -static void xlnx_zynqmp_pmu_machine_init(MachineClass *mc) +static void xlnx_zynqmp_pmu_machine_class_init(ObjectClass *oc, + const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Xilinx ZynqMP PMU machine (little endian)"; mc->init = xlnx_zynqmp_pmu_init; } -DEFINE_MACHINE("xlnx-zynqmp-pmu", xlnx_zynqmp_pmu_machine_init) +static const TypeInfo xlnx_zynqmp_pmu_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("xlnx-zynqmp-pmu"), + .parent = TYPE_MACHINE, + .class_init = xlnx_zynqmp_pmu_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void xlnx_zynqmp_pmu_machine_register_types(void) +{ + type_register_static(&xlnx_zynqmp_pmu_machine_typeinfo); +} + +type_init(xlnx_zynqmp_pmu_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:16:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:16:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465783.1676245 (Exim 4.92) (envelope-from ) id 1xMoLU-0005Zq-Rh; Fri, 30 Oct 2026 15:16:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465783.1676245; Fri, 30 Oct 2026 15: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 1xMoLU-0005Yt-NR; Fri, 30 Oct 2026 15:16:44 +0000 Received: by outflank-mailman (input) for mailman id 1465783; Fri, 30 Oct 2026 15:16:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoLU-0005Xr-40 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:16:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoLT-00A6wy-H6 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:16:43 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4ba-2eae-0a2a0a5409dd-0a2a4506821a-40 for ; Fri, 30 Oct 2026 16:16:43 +0100 Received: from [74.125.82.48] (helo=mail-dl1-f48.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4da-195a-0a2a45060019-4a7d5230ac9a-3 for ; Fri, 30 Oct 2026 16:16:43 +0100 Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-1a2761c69fbso2021882c88.0 for ; Fri, 30 Oct 2026 08:16:42 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.16.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:16: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=20260707 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=20260707; t=1793373401; x=1793978201; 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=zA4vatNcIKJhE+Eb39umMv/j/wzlc1JpQpFuLfiMq1c=; b=gJMOt/xQlMHXc954IX6n9hct3SgGEcs5uFlN9Os13twS8tXfFxHD2KYETHgEXrh6F4 TV9uqZ5pwhyUowrRGVyOc4qkXiVcj6YXOvsEF4ytJMNTcPVWWA0+3BhjxTwO6CII2j+j v6ttYjqOuMpYogXWAVRMds9cHlzSW0e5VZriXx1vI69pKTBQyT7HKHmGwndCo/tCjVeK YfcUoj4m7zj/IwF2zlgRGQgayUBJJqdw4adNdLrq9L5I9NkPxHiQ0Ww0wR+xcUl/pD2m 7jgMCGEpIXNfC9XV43bBZlbAzWZYZTDC0fCQPZ4HX2fzmwIUDSuFNeCyZ+uI1y7nXCK+ GZ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373401; x=1793978201; 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=zA4vatNcIKJhE+Eb39umMv/j/wzlc1JpQpFuLfiMq1c=; b=ZpCPgrp7BUvJKp8h+EV/81LRnIzvhXUXAfIuTAawdxlX8a4GX33wQnl8D7PxNpqu11 O/7V+Yrl4WpNN6DEjJE13h8CE1T+j6p8J6XM48xt9FBOZaTNTfXAtZ+YhvxWezJRqd+V 1bGVzozDTxdQKDpuVhGVxLNLBVEZFMTuwors+X5trW2BkmztOteREODHFLKH2vLSmB5j W9GhLi9ZFz1djsU8tgEHF8sVwjMTAPbn7B4o1Js1H33s0Wq/utUbolWi5prcAGiNFr7b B87hCHxl/1/Zc/plIo0vkYj2P4dFZtgJEhAhQ60+74lcv+Ozyr+cYOZxEhj3dbWFXXQF 3Q0w== X-Forwarded-Encrypted: i=1; AKwUvBxOF5Dhju+x4qZrypiDetEGwJOYJScftnkgYFuaY57DCfZpMBoXiC6RboYqD5oVouqHb21Uyx7qcfo=@lists.xenproject.org X-Gm-Message-State: AFq9FYKUwThs833Df5Zxiu0P0Exsy93N8iM3kMIyUuIcQCuGj22/twi3 Mp0R6Mx+3bFs1Os3ZlIsTjxv+lbwEx99SL0X7RSymdYR8Swdsc5+IBSk X-Gm-Gg: AYBFou1EnVgGDP/lM+FQO3nUPF3k0IDQq7hNRC1Ekh4uq8Osv1un8ETM0mwE7NS+h3U sA0F2o8yISMyTizZwmlEAfurenIEa7yytyPXp4cy3ItkJYtDgI7ref5KLoD43cAGLbL4wGNhSPv o7lTiK0tiknhetbYRhollV3ED+6UnZuhRwdLi2wv7zsg/9VnSU1GJKuPburBFt/i0ew5fV4Udk2 CmIN6XB2DOoBa8YQbj2qXafeejMg9o1DcLhNmwldzHaKGvlzYgQQG15JmzX3HUn2CzOPqQr+/tN OKvjIatHVVr2HjfQF42bNV8UU2gJi3fCWYD93pPhZzzgKBb5Hd7kRAPqWQwrtIxQ/sbjU5TZvsb PM+UB4jO1npuYfyMF0iPHg3Ksbl+xpjxc8CaBHJ/RjK+aIhp15+B7yjqxgmj/RyLjmulLPkkJLp pjnpt1DfoOIci9NaaHGbuZZJ6gUGQUmI7n0Z9NHKncYuRlvFTpVM1xfgfwn65Qv9/RuTQ08fNGH zSWW/cdvZ0CWyCbZs/wEmNBmjUpFOm0j5gBWS6togYvNLHATfDUlxS/ar7lULSKV3jpIax0RTaz Id5p/XP8K529SqG0dcez/clYioFijS7tqn7nGAiS87sCDhxzSFeTCD3oe1RiOyNJsZIDGQ== X-Received: by 2002:a05:7022:ea46:10b0:177:9a5b:a89 with SMTP id a92af1059eb24-1ac5b5f270emr4076428c88.29.1793373401184; Fri, 30 Oct 2026 08:16:41 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 04/15] hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c Date: Fri, 30 Oct 2026 23:15:25 +0800 Message-ID: <20261030151539.1872-5-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1793373403-F6A7477B-EC2C353E/0/0 X-purgate-type: clean X-purgate-size: 1433 Expand DEFINE_MACHINE() in hw/tricore/tricore_testboard.c to ttb_machine_typeinfo and ttb_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/tricore/tricore_testboard.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/tricore/tricore_testboard.c b/hw/tricore/tricore_testboard.c index d5d796c8eec..2a25f090520 100644 --- a/hw/tricore/tricore_testboard.c +++ b/hw/tricore/tricore_testboard.c @@ -106,11 +106,25 @@ static void tricoreboard_init(MachineState *machine) tricore_testboard_init(machine, 0x183); } -static void ttb_machine_init(MachineClass *mc) +static void ttb_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "a minimal TriCore board"; mc->init = tricoreboard_init; mc->default_cpu_type = TRICORE_CPU_TYPE_NAME("tc1796"); } -DEFINE_MACHINE("tricore_testboard", ttb_machine_init) +static const TypeInfo ttb_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("tricore_testboard"), + .parent = TYPE_MACHINE, + .class_init = ttb_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void ttb_machine_register_types(void) +{ + type_register_static(&ttb_machine_typeinfo); +} + +type_init(ttb_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:16:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:16:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465791.1676253 (Exim 4.92) (envelope-from ) id 1xMoLh-000684-2h; Fri, 30 Oct 2026 15:16:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465791.1676253; Fri, 30 Oct 2026 15:16: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 1xMoLg-00067p-V3; Fri, 30 Oct 2026 15:16:56 +0000 Received: by outflank-mailman (input) for mailman id 1465791; Fri, 30 Oct 2026 15:16:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoLf-000633-CK for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:16:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoLe-00A70O-Ow for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:16:54 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4e2-2eae-0a2a0a5409dd-0a2a4504dee2-10 for ; Fri, 30 Oct 2026 16:16:54 +0100 Received: from [74.125.82.49] (helo=mail-dl1-f49.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4e5-b57f-0a2a45040019-4a7d5231ac49-3 for ; Fri, 30 Oct 2026 16:16:54 +0100 Received: by mail-dl1-f49.google.com with SMTP id a92af1059eb24-1a2761c69fbso2022621c88.0 for ; Fri, 30 Oct 2026 08:16:54 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.16.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:16: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=20260707 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=20260707; t=1793373412; x=1793978212; 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=HPp4K8SpYewvoGkZt5YpU/W5aoKsUCXebK5ekrwOnQY=; b=0mYXX4ZAzfh0S+h6qunm2DT+p9mGNsAqALQ2qInqaIyz9IAjVlXnLlA2L6yO2i4xsD 4tWPQ9ECg+Q92yQaO4+KWtXnz3h0VDFLah8wDnhQiCUb0LQ6zJNmvoBBQHc8/oZaIlVo 3GpQBSwQrYmgcGXzdhYOP/Ana6e4QxHfpBdP1SxryF94IA8kqyuMXF2qwkQ3eJlWGK/w lKVAWMek8PsTtdtxvRHkUXk+Poa9RlKJ3/+qhMe5WUZePFkjHsXPXLLwxOCDwOv8UKNI mCb2RfzxFFRIvi+HTLM3ImYIJOlJfOpXTzJKNW/dKw3NCsq37FpKR2K626x40+GqR/My 5Igg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373412; x=1793978212; 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=HPp4K8SpYewvoGkZt5YpU/W5aoKsUCXebK5ekrwOnQY=; b=d8vi9CwOXOOskKdsIKwYtQl1xTqEP7xi3nkjQE6CS2hQbyGy/TMnDDVmgt20kv7O+W STFXW7E6mSHXYJTtlsuHD/sPN0BK6yub2s4fAvZPioYQfAct/zWKZApkbxS8197ZQMJ6 rWguYluVS2mUO2KE0hfZOLl9eyFqf5esvikxkEBzOkfLgpltW/1mfU1+7gvgBPGB//e2 8jnooYW+XuI1zxXNpQsiMVBw0Eq2x2albAitmjpaz9K2UPxNO1DmnC5Z0fP6UALGPZ7P u2hytZ77D7EsaQ2jW2xIvh7mWV3Gxsx3grhg4AsUeHOde3Mue7vPO7EXLoQt6e+mt+9y EMmA== X-Forwarded-Encrypted: i=1; AKwUvBxbooBH2AQ886Zk369J11gb6eEx7VDyEOcvZL+1IkeFa9ZRxxUFJrTULjXbOtyiok8pwfNNlOD48sw=@lists.xenproject.org X-Gm-Message-State: AFq9FYIDib4QuoTXeiho3MghuNbJUkXZ8L0QbNJiFP8WYnsj+H+/uqWU POBAyYY4+oUYoXGUPtI1L3/vXiF2p0IpXcDqzyQZw5zuG7cEVi2+4yv8 X-Gm-Gg: AYBFou2DtiRBMVBJZMrOkKW8BNE5cxt3KV7FI4LKWywEvy9NHvYmp0ROr+PXDxDiLUU zeVS1V/dPxbEJ2pFUgX/D8/3sFAk7U5y924iPHWA/mIRgRNHqdZBlVvLwIXlohKNcanb4zIGYDD OAVf3qYEI+GX6Q9nXdWWxl+ipQByll6JLBo2grNYRd6jUfI81YnT8sjzmETZbn2VjNXKEmh3RtD UxKjaa/OtYN7Ib7VhsIKMEzUc97XiF/f2bgMBisf7AHs9Zr2eM+k5OrjxVCXwKMRdRd8TxorSrr +nW0WwABR7BzA+aOlt8Ybh/Qs0d7hRQPuwWX5lYCo96V5XNhkIbjElZQuih1FjFntn+pwJgXpF6 P+QXPbXxrLy42Zlh8Giq7fOtAda4dhtxmyMwfo/umf4Mdql9av5TC1wB5cMds+PHylscE4CQ7kg DNnPlRpbor1tJNvSjlz3XK5DJKLC44tqz0w0w/AhNFd19ob3CXLd1UGEav7xlGG4533fwMIMP5d Q0TAr90AVjdrkfUtbpOiw+c+7GhGm//ufC5wG+qX3RZg4tiMaNrX5Zq1Ae1UZKc0AF6sXUE4mlp dR+wU5JaZooWQMy/DmdfTfd5KArR+xOrzR8t/V4x0qHHQpfGAX7Rquh0TRZraJgu5cjAPQ== X-Received: by 2002:a05:7022:120c:b0:164:8e14:4939 with SMTP id a92af1059eb24-1ac59dd190bmr3344211c88.10.1793373412205; Fri, 30 Oct 2026 08:16:52 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 05/15] hw/arm: expand DEFINE_MACHINE for ARM machines Date: Fri, 30 Oct 2026 23:15:26 +0800 Message-ID: <20261030151539.1872-6-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1793373414-C1ED6B50-05EB9444/0/0 X-purgate-type: clean X-purgate-size: 21117 Expand DEFINE_MACHINE() and DEFINE_MACHINE_EXTENDED() to explicit TypeInfo and type_register_static() calls for the ARM machine types, reusing integratorcp_register_types() in hw/arm/integratorcp.c. Signed-off-by: Yonggang Luo --- hw/arm/bananapi_m2u.c | 18 +++++++++++++++--- hw/arm/cubieboard.c | 19 +++++++++++++++---- hw/arm/digic_boards.c | 18 ++++++++++++++++-- hw/arm/imx25_pdk.c | 18 ++++++++++++++++-- hw/arm/imx8mm-evk.c | 20 ++++++++++++++++---- hw/arm/integratorcp.c | 14 ++++++++++---- hw/arm/kzm.c | 18 ++++++++++++++++-- hw/arm/max78000fthr.c | 17 +++++++++++++++-- hw/arm/mcimx6ul-evk.c | 18 ++++++++++++++++-- hw/arm/mcimx7d-sabre.c | 20 ++++++++++++++++---- hw/arm/msf2-som.c | 17 +++++++++++++++-- hw/arm/netduino2.c | 17 +++++++++++++++-- hw/arm/netduinoplus2.c | 17 +++++++++++++++-- hw/arm/olimex-stm32-h405.c | 18 ++++++++++++++++-- hw/arm/orangepi.c | 19 +++++++++++++++---- hw/arm/stm32vldiscovery.c | 18 ++++++++++++++++-- 16 files changed, 243 insertions(+), 43 deletions(-) diff --git a/hw/arm/bananapi_m2u.c b/hw/arm/bananapi_m2u.c index ccf60ba2955..ad30e34d718 100644 --- a/hw/arm/bananapi_m2u.c +++ b/hw/arm/bananapi_m2u.c @@ -133,8 +133,9 @@ static void bpim2u_init(MachineState *machine) arm_load_kernel(&r40->cpus[0], machine, &bpms->bootinfo); } -static void bpim2u_machine_init(MachineClass *mc) +static void bpim2u_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-a7"), NULL @@ -152,5 +153,16 @@ static void bpim2u_machine_init(MachineClass *mc) mc->auto_create_sdcard = true; } -DEFINE_MACHINE_EXTENDED("bpim2u", MACHINE, Bpim2uMachineState, - bpim2u_machine_init, false, false, NULL) +static const TypeInfo bpim2u_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("bpim2u"), + .parent = TYPE_MACHINE, + .class_init = bpim2u_machine_class_init, + .instance_size = sizeof(Bpim2uMachineState), +}; + +static void bpim2u_machine_register_types(void) +{ + type_register_static(&bpim2u_machine_typeinfo); +} + +type_init(bpim2u_machine_register_types) diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c index e4fef9cd76b..66610d495bc 100644 --- a/hw/arm/cubieboard.c +++ b/hw/arm/cubieboard.c @@ -113,8 +113,9 @@ static void cubieboard_init(MachineState *machine) arm_load_kernel(&a10->cpu, machine, &cbs->bootinfo); } -static void cubieboard_machine_init(MachineClass *mc) +static void cubieboard_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-a8"), NULL @@ -132,6 +133,16 @@ static void cubieboard_machine_init(MachineClass *mc) mc->auto_create_sdcard = true; } -DEFINE_MACHINE_EXTENDED("cubieboard", MACHINE, CubieboardMachineState, - cubieboard_machine_init, false, false, - NULL) +static const TypeInfo cubieboard_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("cubieboard"), + .parent = TYPE_MACHINE, + .class_init = cubieboard_machine_class_init, + .instance_size = sizeof(CubieboardMachineState), +}; + +static void cubieboard_machine_register_types(void) +{ + type_register_static(&cubieboard_machine_typeinfo); +} + +type_init(cubieboard_machine_register_types) diff --git a/hw/arm/digic_boards.c b/hw/arm/digic_boards.c index 90c19106ad0..49e71f71e97 100644 --- a/hw/arm/digic_boards.c +++ b/hw/arm/digic_boards.c @@ -136,8 +136,10 @@ static void canon_a1100_init(MachineState *machine) digic4_board_init(machine, &digic4_board_canon_a1100); } -static void canon_a1100_machine_init(MachineClass *mc) +static void canon_a1100_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Canon PowerShot A1100 IS (ARM946)"; mc->init = &canon_a1100_init; mc->ignore_memory_transaction_failures = true; @@ -145,4 +147,16 @@ static void canon_a1100_machine_init(MachineClass *mc) mc->default_ram_id = "ram"; } -DEFINE_MACHINE("canon-a1100", canon_a1100_machine_init) +static const TypeInfo canon_a1100_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("canon-a1100"), + .parent = TYPE_MACHINE, + .class_init = canon_a1100_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void canon_a1100_machine_register_types(void) +{ + type_register_static(&canon_a1100_machine_typeinfo); +} + +type_init(canon_a1100_machine_register_types) diff --git a/hw/arm/imx25_pdk.c b/hw/arm/imx25_pdk.c index a33050788c3..546d8002662 100644 --- a/hw/arm/imx25_pdk.c +++ b/hw/arm/imx25_pdk.c @@ -140,8 +140,10 @@ static void imx25_pdk_init(MachineState *machine) } } -static void imx25_pdk_machine_init(MachineClass *mc) +static void imx25_pdk_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "ARM i.MX25 PDK board (ARM926)"; mc->init = imx25_pdk_init; mc->ignore_memory_transaction_failures = true; @@ -149,4 +151,16 @@ static void imx25_pdk_machine_init(MachineClass *mc) mc->auto_create_sdcard = true; } -DEFINE_MACHINE("imx25-pdk", imx25_pdk_machine_init) +static const TypeInfo imx25_pdk_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("imx25-pdk"), + .parent = TYPE_MACHINE, + .class_init = imx25_pdk_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void imx25_pdk_machine_register_types(void) +{ + type_register_static(&imx25_pdk_machine_typeinfo); +} + +type_init(imx25_pdk_machine_register_types) diff --git a/hw/arm/imx8mm-evk.c b/hw/arm/imx8mm-evk.c index 6de0d9c4a2e..ba1b603081b 100644 --- a/hw/arm/imx8mm-evk.c +++ b/hw/arm/imx8mm-evk.c @@ -122,8 +122,10 @@ static const char *imx8mm_evk_get_default_cpu_type(const MachineState *ms) return ARM_CPU_TYPE_NAME("cortex-a53"); } -static void imx8mm_evk_machine_init(MachineClass *mc) +static void imx8mm_evk_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "NXP i.MX 8MM EVK Board"; mc->init = imx8mm_evk_init; mc->max_cpus = FSL_IMX8MM_NUM_CPUS; @@ -133,6 +135,16 @@ static void imx8mm_evk_machine_init(MachineClass *mc) mc->get_default_cpu_type = imx8mm_evk_get_default_cpu_type; } -DEFINE_MACHINE_EXTENDED("imx8mm-evk", MACHINE, Imx8mmEvkMachineState, - imx8mm_evk_machine_init, false, false, - NULL) +static const TypeInfo imx8mm_evk_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("imx8mm-evk"), + .parent = TYPE_MACHINE, + .class_init = imx8mm_evk_machine_class_init, + .instance_size = sizeof(Imx8mmEvkMachineState), +}; + +static void imx8mm_evk_machine_register_types(void) +{ + type_register_static(&imx8mm_evk_machine_typeinfo); +} + +type_init(imx8mm_evk_machine_register_types) diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c index b766edeeee1..9736795b243 100644 --- a/hw/arm/integratorcp.c +++ b/hw/arm/integratorcp.c @@ -691,8 +691,10 @@ static void integratorcp_init(MachineState *machine) arm_load_kernel(cpu, machine, &icms->bootinfo); } -static void integratorcp_machine_init(MachineClass *mc) +static void integratorcp_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "ARM Integrator/CP (ARM926EJ-S)"; mc->init = integratorcp_init; mc->ignore_memory_transaction_failures = true; @@ -703,9 +705,12 @@ static void integratorcp_machine_init(MachineClass *mc) machine_add_audiodev_property(mc); } -DEFINE_MACHINE_EXTENDED("integratorcp", MACHINE, IntegratorcpMachineState, - integratorcp_machine_init, false, false, - NULL) +static const TypeInfo integratorcp_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("integratorcp"), + .parent = TYPE_MACHINE, + .class_init = integratorcp_machine_class_init, + .instance_size = sizeof(IntegratorcpMachineState), +}; static const Property core_properties[] = { DEFINE_PROP_UINT32("memsz", IntegratorCMState, memsz, 0), @@ -760,6 +765,7 @@ static const TypeInfo icp_ctrl_regs_info = { static void integratorcp_register_types(void) { + type_register_static(&integratorcp_machine_typeinfo); type_register_static(&icp_pic_info); type_register_static(&core_info); type_register_static(&icp_ctrl_regs_info); diff --git a/hw/arm/kzm.c b/hw/arm/kzm.c index e9cc53ce017..6196d40cb2e 100644 --- a/hw/arm/kzm.c +++ b/hw/arm/kzm.c @@ -129,12 +129,26 @@ static void kzm_init(MachineState *machine) } } -static void kzm_machine_init(MachineClass *mc) +static void kzm_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "ARM KZM Emulation Baseboard (ARM1136)"; mc->init = kzm_init; mc->ignore_memory_transaction_failures = true; mc->default_ram_id = "kzm.ram"; } -DEFINE_MACHINE("kzm", kzm_machine_init) +static const TypeInfo kzm_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("kzm"), + .parent = TYPE_MACHINE, + .class_init = kzm_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void kzm_machine_register_types(void) +{ + type_register_static(&kzm_machine_typeinfo); +} + +type_init(kzm_machine_register_types) diff --git a/hw/arm/max78000fthr.c b/hw/arm/max78000fthr.c index ed50bb91979..33c1ccbd3c8 100644 --- a/hw/arm/max78000fthr.c +++ b/hw/arm/max78000fthr.c @@ -35,8 +35,9 @@ static void max78000_init(MachineState *machine) 0x00000000, FLASH_SIZE); } -static void max78000_machine_init(MachineClass *mc) +static void max78000_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-m4"), NULL @@ -47,4 +48,16 @@ static void max78000_machine_init(MachineClass *mc) mc->valid_cpu_types = valid_cpu_types; } -DEFINE_MACHINE("max78000fthr", max78000_machine_init) +static const TypeInfo max78000_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("max78000fthr"), + .parent = TYPE_MACHINE, + .class_init = max78000_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void max78000_machine_register_types(void) +{ + type_register_static(&max78000_machine_typeinfo); +} + +type_init(max78000_machine_register_types) diff --git a/hw/arm/mcimx6ul-evk.c b/hw/arm/mcimx6ul-evk.c index 53d221b4a9a..a4cdaac1176 100644 --- a/hw/arm/mcimx6ul-evk.c +++ b/hw/arm/mcimx6ul-evk.c @@ -68,8 +68,10 @@ static void mcimx6ul_evk_init(MachineState *machine) } } -static void mcimx6ul_evk_machine_init(MachineClass *mc) +static void mcimx6ul_evk_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Freescale i.MX6UL Evaluation Kit (Cortex-A7)"; mc->init = mcimx6ul_evk_init; mc->max_cpus = FSL_IMX6UL_NUM_CPUS; @@ -78,4 +80,16 @@ static void mcimx6ul_evk_machine_init(MachineClass *mc) mc->auto_create_sdcard = true; } -DEFINE_MACHINE("mcimx6ul-evk", mcimx6ul_evk_machine_init) +static const TypeInfo mcimx6ul_evk_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("mcimx6ul-evk"), + .parent = TYPE_MACHINE, + .class_init = mcimx6ul_evk_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void mcimx6ul_evk_machine_register_types(void) +{ + type_register_static(&mcimx6ul_evk_machine_typeinfo); +} + +type_init(mcimx6ul_evk_machine_register_types) diff --git a/hw/arm/mcimx7d-sabre.c b/hw/arm/mcimx7d-sabre.c index 55c23061b0a..5a868af6c1f 100644 --- a/hw/arm/mcimx7d-sabre.c +++ b/hw/arm/mcimx7d-sabre.c @@ -76,8 +76,10 @@ static void mcimx7d_sabre_init(MachineState *machine) } } -static void mcimx7d_sabre_machine_init(MachineClass *mc) +static void mcimx7d_sabre_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Freescale i.MX7 DUAL SABRE (Cortex-A7)"; mc->init = mcimx7d_sabre_init; mc->max_cpus = FSL_IMX7_NUM_CPUS; @@ -87,6 +89,16 @@ static void mcimx7d_sabre_machine_init(MachineClass *mc) mc->auto_create_sdcard = true; } -DEFINE_MACHINE_EXTENDED("mcimx7d-sabre", MACHINE, Mcimx7dSabreMachineState, - mcimx7d_sabre_machine_init, false, false, - NULL) +static const TypeInfo mcimx7d_sabre_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("mcimx7d-sabre"), + .parent = TYPE_MACHINE, + .class_init = mcimx7d_sabre_machine_class_init, + .instance_size = sizeof(Mcimx7dSabreMachineState), +}; + +static void mcimx7d_sabre_machine_register_types(void) +{ + type_register_static(&mcimx7d_sabre_machine_typeinfo); +} + +type_init(mcimx7d_sabre_machine_register_types) diff --git a/hw/arm/msf2-som.c b/hw/arm/msf2-som.c index 1372d7f628a..938ccab05c4 100644 --- a/hw/arm/msf2-som.c +++ b/hw/arm/msf2-som.c @@ -96,8 +96,9 @@ static void emcraft_sf2_s2s010_init(MachineState *machine) 0, soc->envm_size); } -static void emcraft_sf2_machine_init(MachineClass *mc) +static void emcraft_sf2_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-m3"), NULL @@ -108,4 +109,16 @@ static void emcraft_sf2_machine_init(MachineClass *mc) mc->valid_cpu_types = valid_cpu_types; } -DEFINE_MACHINE("emcraft-sf2", emcraft_sf2_machine_init) +static const TypeInfo emcraft_sf2_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("emcraft-sf2"), + .parent = TYPE_MACHINE, + .class_init = emcraft_sf2_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void emcraft_sf2_machine_register_types(void) +{ + type_register_static(&emcraft_sf2_machine_typeinfo); +} + +type_init(emcraft_sf2_machine_register_types) diff --git a/hw/arm/netduino2.c b/hw/arm/netduino2.c index 0db8798b4bd..3f95672670e 100644 --- a/hw/arm/netduino2.c +++ b/hw/arm/netduino2.c @@ -52,8 +52,9 @@ static void netduino2_init(MachineState *machine) 0, FLASH_SIZE); } -static void netduino2_machine_init(MachineClass *mc) +static void netduino2_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-m3"), NULL @@ -65,4 +66,16 @@ static void netduino2_machine_init(MachineClass *mc) mc->ignore_memory_transaction_failures = true; } -DEFINE_MACHINE("netduino2", netduino2_machine_init) +static const TypeInfo netduino2_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("netduino2"), + .parent = TYPE_MACHINE, + .class_init = netduino2_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void netduino2_machine_register_types(void) +{ + type_register_static(&netduino2_machine_typeinfo); +} + +type_init(netduino2_machine_register_types) diff --git a/hw/arm/netduinoplus2.c b/hw/arm/netduinoplus2.c index 5ac0eb81637..169e7b80b3c 100644 --- a/hw/arm/netduinoplus2.c +++ b/hw/arm/netduinoplus2.c @@ -53,8 +53,9 @@ static void netduinoplus2_init(MachineState *machine) 0, FLASH_SIZE); } -static void netduinoplus2_machine_init(MachineClass *mc) +static void netduinoplus2_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-m4"), NULL @@ -65,4 +66,16 @@ static void netduinoplus2_machine_init(MachineClass *mc) mc->valid_cpu_types = valid_cpu_types; } -DEFINE_MACHINE("netduinoplus2", netduinoplus2_machine_init) +static const TypeInfo netduinoplus2_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("netduinoplus2"), + .parent = TYPE_MACHINE, + .class_init = netduinoplus2_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void netduinoplus2_machine_register_types(void) +{ + type_register_static(&netduinoplus2_machine_typeinfo); +} + +type_init(netduinoplus2_machine_register_types) diff --git a/hw/arm/olimex-stm32-h405.c b/hw/arm/olimex-stm32-h405.c index de9ac4978ce..4e415a420c4 100644 --- a/hw/arm/olimex-stm32-h405.c +++ b/hw/arm/olimex-stm32-h405.c @@ -56,8 +56,10 @@ static void olimex_stm32_h405_init(MachineState *machine) 0, FLASH_SIZE); } -static void olimex_stm32_h405_machine_init(MachineClass *mc) +static void olimex_stm32_h405_machine_class_init(ObjectClass *oc, + const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-m4"), NULL @@ -71,4 +73,16 @@ static void olimex_stm32_h405_machine_init(MachineClass *mc) mc->default_ram_size = 0; } -DEFINE_MACHINE("olimex-stm32-h405", olimex_stm32_h405_machine_init) +static const TypeInfo olimex_stm32_h405_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("olimex-stm32-h405"), + .parent = TYPE_MACHINE, + .class_init = olimex_stm32_h405_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void olimex_stm32_h405_machine_register_types(void) +{ + type_register_static(&olimex_stm32_h405_machine_typeinfo); +} + +type_init(olimex_stm32_h405_machine_register_types) diff --git a/hw/arm/orangepi.c b/hw/arm/orangepi.c index 18ed174032b..ec1d19b6034 100644 --- a/hw/arm/orangepi.c +++ b/hw/arm/orangepi.c @@ -111,8 +111,9 @@ static void orangepi_init(MachineState *machine) arm_load_kernel(&h3->cpus[0], machine, &opms->bootinfo); } -static void orangepi_machine_init(MachineClass *mc) +static void orangepi_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-a7"), NULL @@ -132,6 +133,16 @@ static void orangepi_machine_init(MachineClass *mc) mc->auto_create_sdcard = true; } -DEFINE_MACHINE_EXTENDED("orangepi-pc", MACHINE, OrangePiMachineState, - orangepi_machine_init, false, false, - NULL) +static const TypeInfo orangepi_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("orangepi-pc"), + .parent = TYPE_MACHINE, + .class_init = orangepi_machine_class_init, + .instance_size = sizeof(OrangePiMachineState), +}; + +static void orangepi_machine_register_types(void) +{ + type_register_static(&orangepi_machine_typeinfo); +} + +type_init(orangepi_machine_register_types) diff --git a/hw/arm/stm32vldiscovery.c b/hw/arm/stm32vldiscovery.c index d899a134b38..ab9116ccc1d 100644 --- a/hw/arm/stm32vldiscovery.c +++ b/hw/arm/stm32vldiscovery.c @@ -56,8 +56,10 @@ static void stm32vldiscovery_init(MachineState *machine) 0, FLASH_SIZE); } -static void stm32vldiscovery_machine_init(MachineClass *mc) +static void stm32vldiscovery_machine_class_init(ObjectClass *oc, + const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); static const char * const valid_cpu_types[] = { ARM_CPU_TYPE_NAME("cortex-m3"), NULL @@ -68,4 +70,16 @@ static void stm32vldiscovery_machine_init(MachineClass *mc) mc->valid_cpu_types = valid_cpu_types; } -DEFINE_MACHINE("stm32vldiscovery", stm32vldiscovery_machine_init) +static const TypeInfo stm32vldiscovery_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("stm32vldiscovery"), + .parent = TYPE_MACHINE, + .class_init = stm32vldiscovery_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void stm32vldiscovery_machine_register_types(void) +{ + type_register_static(&stm32vldiscovery_machine_typeinfo); +} + +type_init(stm32vldiscovery_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:17:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:17:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465800.1676263 (Exim 4.92) (envelope-from ) id 1xMoLs-0006an-ER; Fri, 30 Oct 2026 15:17:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465800.1676263; Fri, 30 Oct 2026 15:17: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 1xMoLs-0006ag-BR; Fri, 30 Oct 2026 15:17:08 +0000 Received: by outflank-mailman (input) for mailman id 1465800; Fri, 30 Oct 2026 15:17:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoLq-0006Y8-Ft for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:17:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoLp-000LR9-Sl for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:17:05 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4e3-bab6-0a2a0a5309dd-0a2a450bc9b2-26 for ; Fri, 30 Oct 2026 16:17:05 +0100 Received: from [74.125.82.169] (helo=mail-dy1-f169.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4f0-b7e8-0a2a450b0019-4a7d52a9cd83-3 for ; Fri, 30 Oct 2026 16:17:05 +0100 Received: by mail-dy1-f169.google.com with SMTP id 5a478bee46e88-36a1947498bso88572eec.1 for ; Fri, 30 Oct 2026 08:17:05 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.16.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:17: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=20260707 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=20260707; t=1793373424; x=1793978224; 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=8a2b4rCQZ/Ri0eDvVEGx78IoeAx/tMieqM2WVNnANN8=; b=PFCeVPEItUj70ljRUzuA7QP/06vk47xBYmF+w6mML+bBGMw/7AL6vI8j913GNab6cj IFDAoiL+NJMmqTwecnkE7jJxI2oJra8l1I7YIK4Tc3UhUlcRwpg4WFKf5eOtAGjfYCfc HhiI1FbSbILzpdU/g8qWEd/LEGK1iBcIwQDbt+2ZknGL4D2mRc0S9BscKAmlXzH2BJSP TD4d8HoO7CbwmrdMAGSYO1cPlFARqkEmKCyILeQbpszCtsU6fovUpU5oj7/6xMYHiux/ e+t80rZwv+Wc4NcKn51ODZUIEpJhLeMCoP6prPwdAJCUltp271dhmEN5Ck5Sv+ce6sWz wDsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373424; x=1793978224; 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=8a2b4rCQZ/Ri0eDvVEGx78IoeAx/tMieqM2WVNnANN8=; b=SQo7xhfC2PehV3DT7MzFWAmJAeX134B9KTMoxWm0ie51YY7z+dpjLRmYK5xX47feZ7 i4dKvu+BQ1LJuMaXcHD22lJWvwpZxq8ib3mN4d4CuqwBRavVPtu5hUwmYG7tVuFTDcvF aILs9/MNXN6GFtu/QOtd3V/V4G5Bsuih8J3jXMwdjhDMpBKiISLRYvhpOaH59sjUlMNp QGzm8CnZBme/WBFUwjXTr0KIFOYhRzkgLt+KUUrYsBtYCnH4fZKTDqZ1ltyqewRcdTBC cpRCVzxuOCLJzhM7ltB2I3eTusGMkd+U9L5qegHV8Bnkr+WY/NZNo1v4ITGeO1b94k+V qh9w== X-Forwarded-Encrypted: i=1; AKwUvBzgQ/ybnpXia3eV7aQ6unRLIU4Bo7DwSHwnKxfHEY9UFFklfv5DpI12NHpjPqCgi0uvPXcDL5tWscE=@lists.xenproject.org X-Gm-Message-State: AFq9FYKjAKnFyK/SNCjN5Mg1abUuwxoib3lR5y9LtvcwvGX/zU9AsgJ8 19XcNQQtg0HwnF932PCSfuTGbOHgXymWxtaWisLFXewAOuBUI1Fe7qOd X-Gm-Gg: AYBFou2UUrVFcQznpeTJHu7qQKpSlwpJws5Vqi74wySIpT4DjOetOg7XG3eqvaeMw7A AiCc58213rGyULDh/w9FgbloM2ffW8hSt/faBMU8qZIiDmoQnJdVIUwS88TTzUje23coq9OLzBJ DEIr3gUy5vve4GArjYEeTA2bkAK6bQiuVCS3xQXUDe/FkNQX8rflylED1td5r/nU4dt+D/CJuQa 8iiYgYsjW/0C0NPQNSJk8EZ30iRAZW3UeE8iLcaroN7BNoD2iMtx1w9uJHx3LbICpNhohdSGb85 GKW9mLAxjeaIlQvYlJAd01yMfavmfJn0uCR61qnU5mgcRDA+KDWvq7wavDPYDzPE33YGXB0m2Az EYgoy41dFER3gbrZB6Me5nsA+gnHgfSnhAuzKLorx4GU1BtrpJ7ijm7pqpFIk7tLwtX/kdT72xL fxNo4DfOb/Sbu9nVdIxF8MkIwskpM9cA8LAMYA87gIrQyTV+vt/R7Bqberkgi1ZA2lxp+8B4sX9 8uR1hVmoKv0BSK+jaGidab17j5xq69MbDU3TwpqRgfXxUD0z5FV725XizqGWf36U0n5OQGQTfMj tBkAVY/Lnd4rqwJ/cPFnf4kxf5zwwh4jaMI2Uf4A9PuwJDf3Fou/yub88mT+hFw/tnu6vA== X-Received: by 2002:a05:7022:eb50:10b0:1ac:9da7:e881 with SMTP id a92af1059eb24-1ac9dc67142mr3312715c88.36.1793373423386; Fri, 30 Oct 2026 08:17:03 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 06/15] hw/riscv: expand DEFINE_MACHINE for RISC-V machines Date: Fri, 30 Oct 2026 23:15:27 +0800 Message-ID: <20261030151539.1872-7-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793373425-AAAD89EA-CAE6A4E6/0/0 X-purgate-type: clean X-purgate-size: 2807 Expand DEFINE_MACHINE() in hw/riscv/boston-aia.c and hw/riscv/microblaze-v-generic.c to explicit TypeInfo and type_init() functions calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/riscv/boston-aia.c | 18 ++++++++++++++++-- hw/riscv/microblaze-v-generic.c | 18 ++++++++++++++++-- 2 files changed, 32 insertions(+), 4 deletions(-) diff --git a/hw/riscv/boston-aia.c b/hw/riscv/boston-aia.c index b90da096ea8..54979eae86e 100644 --- a/hw/riscv/boston-aia.c +++ b/hw/riscv/boston-aia.c @@ -462,8 +462,10 @@ static void boston_mach_init(MachineState *machine) } } -static void boston_mach_class_init(MachineClass *mc) +static void boston_mach_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "MIPS Boston-aia"; mc->init = boston_mach_init; mc->block_default_type = IF_IDE; @@ -473,4 +475,16 @@ static void boston_mach_class_init(MachineClass *mc) mc->default_cpu_type = TYPE_RISCV_CPU_MIPS_P8700; } -DEFINE_MACHINE("boston-aia", boston_mach_class_init) +static const TypeInfo boston_mach_typeinfo = { + .name = MACHINE_TYPE_NAME("boston-aia"), + .parent = TYPE_MACHINE, + .class_init = boston_mach_class_init, + .instance_size = sizeof(MachineState), +}; + +static void boston_mach_register_types(void) +{ + type_register_static(&boston_mach_typeinfo); +} + +type_init(boston_mach_register_types) diff --git a/hw/riscv/microblaze-v-generic.c b/hw/riscv/microblaze-v-generic.c index b0494b1ac50..b0f837b6ee7 100644 --- a/hw/riscv/microblaze-v-generic.c +++ b/hw/riscv/microblaze-v-generic.c @@ -176,8 +176,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; @@ -186,4 +188,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_typeinfo = { + .name = MACHINE_TYPE_NAME("amd-microblaze-v-generic"), + .parent = TYPE_MACHINE, + .class_init = mb_v_generic_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void mb_v_generic_machine_register_types(void) +{ + type_register_static(&mb_v_generic_machine_typeinfo); +} + +type_init(mb_v_generic_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:17:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:17:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465805.1676272 (Exim 4.92) (envelope-from ) id 1xMoM3-0006zf-LY; Fri, 30 Oct 2026 15:17:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465805.1676272; Fri, 30 Oct 2026 15:17: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 1xMoM3-0006zW-Id; Fri, 30 Oct 2026 15:17:19 +0000 Received: by outflank-mailman (input) for mailman id 1465805; Fri, 30 Oct 2026 15:17:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoM1-0006yN-JO for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:17:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoM1-009M9t-0A for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:17:17 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4e6-e002-0a2a0a5209dd-0a2a45039a82-34 for ; Fri, 30 Oct 2026 16:17:16 +0100 Received: from [74.125.82.43] (helo=mail-dl1-f43.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b4fb-fae8-0a2a45030019-4a7d522be5d9-3 for ; Fri, 30 Oct 2026 16:17:16 +0100 Received: by mail-dl1-f43.google.com with SMTP id a92af1059eb24-1931ff67a29so121237c88.1 for ; Fri, 30 Oct 2026 08:17:16 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.17.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:17: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=20260707 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=20260707; t=1793373435; x=1793978235; 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=m864uzH9D1nJnXhJ32zoDB2BUw6AVK2KA1WWNZhkMsE=; b=e4zbdFTS1dR9004G2INreGHxjsw47iIufXODAoPsRmCC3z+YjZgR+lt+V2prIS5XhM vrUptCw27i2NFjMvRhbZxPQ4Tnxpv6Yape4raFihbK1zLIPzTSFLljtufKr8m+YY3LQR L6cE9M2HUvqhA5sT5x2v/wHMJ/NMypW7XSFVDZcZ1I8jAtqJb5F7dLo4HkrRvqeDaZAb C+SZd4+YNWQ8+HhIbt3GEhR4xpVB+2qAh6gK39egrIq17BGPjS6Hyvoz7BXjZ1hK5f7H /49iAKPuUIN3lpNJoS1+i7pTS2ISKNTstrYm+nebYjTOHl3HNngIV14Bkqavd+v+Uh0F K5Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373435; x=1793978235; 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=m864uzH9D1nJnXhJ32zoDB2BUw6AVK2KA1WWNZhkMsE=; b=sKtyckpoHw854z+01VAHShe5bMlIZ2xoAR/horxc5dw8hobLjkIZ/8Xp9wGnlPQtxl ASyf9JOeh7BtlPCeBID2KWpJVT8pjs0uQHLhSa+IG3UBjZO6HrBSEEYVZvJgvZ2a42+t ZARZHlMDjfDpFLIHCMCf51wYaGzzAU1PRUXcTuu6zTgp/APGT8xpU8xGPYDmed6uBB7V jiJWp2IZtBeqXqu2mj1YKh5s9GRiKK+aRsEvz+IjzOyWcmRHHjkcOk4qLAyMp7GsdRLT QTmOrC93UOpo49Z70O885IxRJJnOqMaM10TyMWSxNlyIFCo/NJVd0H/eQK6+2NDuY8hw rL/w== X-Forwarded-Encrypted: i=1; AKwUvByb1owKLyQWIdiCxIjbkEVZk4fNATbGXtuEUUAI6t2skXr0bFg1xNMd//ntF3w0EfNRH4YpmDL2W10=@lists.xenproject.org X-Gm-Message-State: AFq9FYIJnZw36lcVM2RZmIr7abtgPEm9BTTxnVRjloB0XE0uNXLvAswx qUVMfq7c6aNmTwADQidQ/VVn+6rodfVYTJnnws6FmwE8KGZ1H7+v7ipf X-Gm-Gg: AYBFou3gGYyE5A4246rOzbAK0Rc16HxYN4FqaQVAYD5UajvJT66CXXyAFy2moC9vN0R YkZ65UyCYLnk7ltkNI3LPUtVzcOH7mqv1SDQQThpKSZbMxAp51tKPuO49LYMRd47s0HPysVpYCU SCUPEFRlPko9MofF7GNVAHC0JnBMIsTqA2N80n4wkCzq+tE4fWXxBQopP4Hs8s4WGSm4EO1c9H7 yFnyK82Ku3u/CAi8f+yTbZbdSPxZWaUR5qmUISSCz5T9y63xzIghL18cU10b7xe2WmQRcJBMJZh yLb69r5RNc3zUn5eQB/6HUHzj6lhz91ju2tE3h3T6hmEh7uDXtkRCzuG1xQK4qTlqtdwh/aKmZr Eo1rRNWmy+3zn5FlbusS4gRJ1z2zgjpas5NkM6OjZO4ZtfdVrkSn6Lv++qKNI6CmwJRirJwfPZ2 J6yKLo5466jAj2F7scCjUsD7mJl9Daw+7qfTwzUY2dMWmhNQ4FP4T1FI7pzHA7MJCs0RMd48ge2 WmvkFIXMVb1j6liOM0jDvztZaw2gng8V6+truZFEhINAWgHWU8jsVNczWlm7X/0Y+KO1EdMzXVz bhJ/Kmkwn6sBz8xL3JRU8F6G+oeKBP6U1w== X-Received: by 2002:a05:701b:4512:10b0:181:73fc:e53 with SMTP id a92af1059eb24-1ac5b7e21fdmr3546543c88.29.1793373434663; Fri, 30 Oct 2026 08:17:14 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 07/15] hw/core/null-machine: expand DEFINE_MACHINE Date: Fri, 30 Oct 2026 23:15:28 +0800 Message-ID: <20261030151539.1872-8-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1793373436-74C884E9-92BF7DB9/0/0 X-purgate-type: clean X-purgate-size: 1451 Expand DEFINE_MACHINE() for the none machine to machine_none_machine_typeinfo and machine_none_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/core/null-machine.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c index 60254913019..1f35b9169d1 100644 --- a/hw/core/null-machine.c +++ b/hw/core/null-machine.c @@ -42,8 +42,10 @@ static void machine_none_init(MachineState *mch) } } -static void machine_none_machine_init(MachineClass *mc) +static void machine_none_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "empty machine"; mc->init = machine_none_init; mc->max_cpus = 1; @@ -55,4 +57,16 @@ static void machine_none_machine_init(MachineClass *mc) mc->no_cdrom = 1; } -DEFINE_MACHINE("none", machine_none_machine_init) +static const TypeInfo machine_none_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("none"), + .parent = TYPE_MACHINE, + .class_init = machine_none_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void machine_none_machine_register_types(void) +{ + type_register_static(&machine_none_machine_typeinfo); +} + +type_init(machine_none_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:17:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:17:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465809.1676281 (Exim 4.92) (envelope-from ) id 1xMoMD-0007QY-To; Fri, 30 Oct 2026 15:17:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465809.1676281; Fri, 30 Oct 2026 15: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 1xMoMD-0007QR-Qp; Fri, 30 Oct 2026 15:17:29 +0000 Received: by outflank-mailman (input) for mailman id 1465809; Fri, 30 Oct 2026 15:17:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoMC-0007Ow-Fh for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:17:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoMB-00DIJo-Sf for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:17:27 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4e8-2eae-0a2a0a5409dd-0a2a450888e0-48 for ; Fri, 30 Oct 2026 16:17:27 +0100 Received: from [74.125.82.41] (helo=mail-dl1-f41.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b506-f659-0a2a45080019-4a7d5229c57c-3 for ; Fri, 30 Oct 2026 16:17:27 +0100 Received: by mail-dl1-f41.google.com with SMTP id a92af1059eb24-14394530ec6so1091624c88.1 for ; Fri, 30 Oct 2026 08:17:27 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.17.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:17: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=20260707 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=20260707; t=1793373446; x=1793978246; 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=8lrMJa0QKyERxDe5fpQfZvS/Pcg04syvA9gM/OyRcBA=; b=N61yTWMB1ADWmkT9WJI+yaXXAiA77+DsmhIQTZnhHWjyUF1Cw52wpp17ZWE9ulGL2W r8+rqMKZFFjMzmx8ZaQZCaCzPTH9sW7Y+1lRmOc51o32xLVZxpKPK/k3y6SZ4Mh1bajo qnCMd+xIeLCe0YNtgBQTJ+HoGXrfgbbLJjqy/NO2SW447VMxWfBZe7TvTVPb+iIomFy9 OoPC2QQqjoskruNYxjj0g/8/vyTNTr/lM2at/Tz9wDVmxTY6Gla1qufOfZzb0+9AzcoP KBiR/Xz5ttih8rwVZHUMwTPeNbAPGVGjVn885XpIyMw4m9jdX4chcHBRap1NET3hWcuS SvOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373446; x=1793978246; 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=8lrMJa0QKyERxDe5fpQfZvS/Pcg04syvA9gM/OyRcBA=; b=oOo/l7mg+lHEE5hi07aQEMgYl1yXaSWm43Xp7lVY4LX/9wJnKFb3x+4bCJ+pZYK1tg V7KIVEDddIZaPPZOYDhFsD9bODU52h3x2MpM1pi1OfZ9m5kqo77ppKmbcjxzyOb8j+1k HXxylkWFqICQMW7+opRAIlupdGKgn2eWWZmgswevmLyXPoO70963ldbxlg5qszgx/I3r +CUgdeYUk87AaoJqwCdjUY8zzGS/7+6KVg/kByfI7LfrcRiqNE2QHNxCdP8u28Uj/SqD NxqhBjayWI638aa7kMuH2e3mWTUf8XS6Xqyzav6TUUp61wEEj+BScvbyfooqqLotzKM1 2T2Q== X-Forwarded-Encrypted: i=1; AKwUvBwUtzt2P9atdbp1zPSfDiqb+74F233wLOqxZ7b0nyd0gl+R/TQSgiONrahr/KZ7zjZ06/4G3MJRtEY=@lists.xenproject.org X-Gm-Message-State: AFq9FYKXRyOgZ7knbk5ubrOfUvSCx2ESwxIUhl/zrhgCPhwheGOlmTVD LxlX1j11u6naTbtAWlodO4JuAsG6hMz/EVKhyd1uKKS2Xfc72Jiuke8L X-Gm-Gg: AYBFou2xH1YA21s7q5bHzWKLPM6cvGl7uX+m1p1v82uCP9QIxRmpJ9ZX/4LIYoGOM7T 53Wii+/OOr7VJ8m+g63bSpSIqwBKEF53+sfDLCjcYbhdf7aQ8FZ1zKYBwf4PdaFiiArxoEIpNfA uehv0nbIS1dXv6U3VErqzFlFeLaQs/w62k5IWwC+bpLBpuz850OJxC22SG+fa3o0Jhyc28WokRo jgz7IPHyLMjHtwDrZHfZQZ6CsJY6s+563CWa7OcoIpmjejKknLlFGux58TxVTFcAY5MPVGGdhte EQ6wEVEU4l70XOChgBLL+apEpcHlSgFfEJ2vl4IXMZEl6T46XvbqVv7A0JEapzREYXhYcBrBhvu h4Pz/d3npcKNurE6Sa2EevmIGKbwQeth+BGpQoqPd0J5BNW8X0EahirmpM5ruN5ns3Dmvf4d9E7 SPfr+pH2ekXKLQNx5J/0RuN+uixpanOUrjdsZdTo1F3ew8pbbyd+YKdEucp8wyuIOxs/5EjQ61J rdTBR1M3ABk54vlDNsrT3aQraFX6s9sRv5gVWx8KV2BhESFlQ0dxDSWX9ImbOBL8WUkIZLfK3kr AaHA1GKidsJcYRfjULNgVA4+xbc9qJUo2+Zp46ZPzTszC1DC4meH/nyAH+ostFlfPP+/mQ== X-Received: by 2002:a05:7023:a5b:10b0:160:90a3:ca8c with SMTP id a92af1059eb24-1ac5cb1c615mr3223077c88.7.1793373445630; Fri, 30 Oct 2026 08:17:25 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 08/15] hw/mips: expand DEFINE_MACHINE for MIPS machines Date: Fri, 30 Oct 2026 23:15:29 +0800 Message-ID: <20261030151539.1872-9-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1793373447-CDF4787B-A3549E4B/0/0 X-purgate-type: clean X-purgate-size: 3959 Expand DEFINE_MACHINE() in hw/mips/boston.c, hw/mips/fuloong2e.c, and hw/mips/malta.c to explicit TypeInfo and type_register_static() calls, reusing mips_malta_register_types() in hw/mips/malta.c. Signed-off-by: Yonggang Luo --- hw/mips/boston.c | 18 ++++++++++++++++-- hw/mips/fuloong2e.c | 18 ++++++++++++++++-- hw/mips/malta.c | 12 ++++++++++-- 3 files changed, 42 insertions(+), 6 deletions(-) diff --git a/hw/mips/boston.c b/hw/mips/boston.c index 4579df23eb7..2c6edebe257 100644 --- a/hw/mips/boston.c +++ b/hw/mips/boston.c @@ -839,8 +839,10 @@ static void boston_mach_init(MachineState *machine) } } -static void boston_mach_class_init(MachineClass *mc) +static void boston_mach_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "MIPS Boston"; mc->init = boston_mach_init; mc->block_default_type = IF_IDE; @@ -850,4 +852,16 @@ static void boston_mach_class_init(MachineClass *mc) mc->default_cpu_type = MIPS_CPU_TYPE_NAME("I6400"); } -DEFINE_MACHINE("boston", boston_mach_class_init) +static const TypeInfo boston_mach_typeinfo = { + .name = MACHINE_TYPE_NAME("boston"), + .parent = TYPE_MACHINE, + .class_init = boston_mach_class_init, + .instance_size = sizeof(MachineState), +}; + +static void boston_mach_register_types(void) +{ + type_register_static(&boston_mach_typeinfo); +} + +type_init(boston_mach_register_types) diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c index 9a712ee9309..96610ec1fdd 100644 --- a/hw/mips/fuloong2e.c +++ b/hw/mips/fuloong2e.c @@ -328,8 +328,10 @@ static void mips_fuloong2e_init(MachineState *machine) network_init(pci_bus); } -static void mips_fuloong2e_machine_init(MachineClass *mc) +static void mips_fuloong2e_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Fuloong 2e mini pc"; mc->init = mips_fuloong2e_init; mc->block_default_type = IF_IDE; @@ -339,4 +341,16 @@ static void mips_fuloong2e_machine_init(MachineClass *mc) machine_add_audiodev_property(mc); } -DEFINE_MACHINE("fuloong2e", mips_fuloong2e_machine_init) +static const TypeInfo mips_fuloong2e_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("fuloong2e"), + .parent = TYPE_MACHINE, + .class_init = mips_fuloong2e_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void mips_fuloong2e_machine_register_types(void) +{ + type_register_static(&mips_fuloong2e_machine_typeinfo); +} + +type_init(mips_fuloong2e_machine_register_types) diff --git a/hw/mips/malta.c b/hw/mips/malta.c index 38c71f66f2e..0a10a2fea13 100644 --- a/hw/mips/malta.c +++ b/hw/mips/malta.c @@ -1285,8 +1285,10 @@ GlobalProperty malta_compat[] = { }; const size_t malta_compat_len = G_N_ELEMENTS(malta_compat); -static void mips_malta_machine_init(MachineClass *mc) +static void mips_malta_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "MIPS Malta Core LV"; mc->init = mips_malta_init; mc->block_default_type = IF_IDE; @@ -1301,11 +1303,17 @@ static void mips_malta_machine_init(MachineClass *mc) compat_props_add(mc->compat_props, malta_compat, malta_compat_len); } -DEFINE_MACHINE("malta", mips_malta_machine_init) +static const TypeInfo mips_malta_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("malta"), + .parent = TYPE_MACHINE, + .class_init = mips_malta_machine_class_init, + .instance_size = sizeof(MachineState), +}; static void mips_malta_register_types(void) { type_register_static(&mips_malta_device); + type_register_static(&mips_malta_machine_typeinfo); } type_init(mips_malta_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:17:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:17:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465819.1676290 (Exim 4.92) (envelope-from ) id 1xMoMP-0008Ur-5g; Fri, 30 Oct 2026 15:17:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465819.1676290; Fri, 30 Oct 2026 15:17: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 1xMoMP-0008Uf-1T; Fri, 30 Oct 2026 15:17:41 +0000 Received: by outflank-mailman (input) for mailman id 1465819; Fri, 30 Oct 2026 15:17:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoMN-0008GK-SS for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:17:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoMN-00DIKy-92 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:17:39 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b4fc-e002-0a2a0a5209dd-0a2a450791f2-42 for ; Fri, 30 Oct 2026 16:17:39 +0100 Received: from [74.125.82.52] (helo=mail-dl1-f52.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b511-b4ea-0a2a45070019-4a7d5234cc56-3 for ; Fri, 30 Oct 2026 16:17:39 +0100 Received: by mail-dl1-f52.google.com with SMTP id a92af1059eb24-170135e43c7so1230168c88.0 for ; Fri, 30 Oct 2026 08:17:38 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.17.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:17: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=20260707 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=20260707; t=1793373457; x=1793978257; 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=gGfzDRU1LJ6XJUC1FoxM7ZI/nsagUrCZ0XaVKskAYMY=; b=xD+5p/lN7mV9RKKOYOMliDNj+ZHEQzKC8jUy6B0Z+oAUhBaKS8x93lyVYs2XsYBmZZ tNedX+H32itdOeQseIwp9Rv46MuR5/rwBiPX3EVWQ+GIS4eJfKyAzCuWPXFG0tyMgrMG 5PdA3MVIf/OFtKFe8thvBFJ/M78uq+t06eiFgB9IXWJKGQUppWNMkH/E/zMQ/+g0oOFk 3sXobGv3J4Schr7zO4NO4aPlGRWO7sq4OmBMriPhQdNMctk+y8M9ts6UyMd081P+42Mi zCHqyGdXf/chnW+82dOgbHuVwjBRb1z3pI7bXoG/9HKRbaZDPVU20UWYxVcYOp3Ewv15 91gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373457; x=1793978257; 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=gGfzDRU1LJ6XJUC1FoxM7ZI/nsagUrCZ0XaVKskAYMY=; b=UqUEvHbO72609UURgYDbQTfLrPFc674ut8zVEEseJqUP9utBJ3GtTCUtQav2pEr6y2 r+Na81Tl2ZA3U1UNOc+xi3ay0Cs/I08ou12fphHLRu9X7YAWMKkPqADv0lhPkiDY8Zsr CxyyTYSOtztIFl97ew/4qXecjhAJDkANvLyT5A+ST6irZHzKy+rS284IweVeLT9p0iKc 6xpOrOyJ2fplGyOJZTG9rlIsVIBs5fK7ZntocQPQ5biRVRzIDv6c2qt8g4JNRnriqavM z3weZ7lziwVfk7cwNnPh0oA29fRvGm5A+joFSDmFK58d2iMXUamjmx6CEGu9oK0PPTse N+bg== X-Forwarded-Encrypted: i=1; AKwUvBzWKh9ZwX8mT02PTtCZJOBFd46//UT/f5rpei9XywDHtvk0+w5eVjUni1AVnO2LZJX1Yc/Gb4+7lHI=@lists.xenproject.org X-Gm-Message-State: AFq9FYL2N7OpWm/j9JR1ahK4zAnhGzb4uyJoeZ5wpYdQgcQFULbIATIG z6D3dbdakxN3vYTFkVuTrTjrTlmSvlMdaLw9/SYtu6tVXkoaEgNpvn5b X-Gm-Gg: AYBFou0a0uc9qtQulGGMBdcombMeuANZ8+H2ET4ktT7qpUMlrOcUaIM1NDGbiKpHc2O oERvlEm5vpCaP9f2er6SKnBqQhXJ/BvcEE+CgmgaFyN52BWPFgdXQh8VcIFJQGrEaB7PP55lGD2 d7iH1O52E5rxB2F+abNUJT16vlWfmx4/xakHVsYT9/xNOSe6VGUZir4IJWQvyVg4D8McOl8n6E7 rAKL1BubLnz4WtDNoZ0xWM0Udiy9WIYC7FC8lgYglPe7GkwKX4Zpd78jD/XD3Il40a13ESPDAYZ 1ZHZGvbOyfiZfq2kRakyAH5sl/bmLf2EMKDK5+9CN4N5p6wBencuyG0v1cdcWh9EMfIfn40PDAz +Wq3dtAaV3t+Li3spUft7dsOHRoh59YcQ0qe15yG8cSvuHYPkmxCXPvX/Fh0uZRAOZ9AbrTGKsr O/Cr16lpX0yEpFF5BadVtwVuJXQ0nIH+ZAO5IuCvbxBelMKxj7t1+hbU/EWMb359q8FWvxDXsFy r1E+GUqi5r7LigvNtwVQxq1t22VCnMxUy/DpC8vxY4jUkbPDlzHJwMT3a89m3ARNiy98ippGzYt DEfvByhUE+kwFg+tOO7TIAqKpwnB1Zr042SGDHHd181nPagK X-Received: by 2002:a05:701b:4589:b0:19b:39f4:88c9 with SMTP id a92af1059eb24-1ac5bbb487bmr3398481c88.10.1793373456937; Fri, 30 Oct 2026 08:17:36 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 09/15] hw/ppc: expand DEFINE_MACHINE for PowerPC machines Date: Fri, 30 Oct 2026 23:15:30 +0800 Message-ID: <20261030151539.1872-10-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793373459-A60C5AE4-37474557/0/0 X-purgate-type: clean X-purgate-size: 7750 Expand DEFINE_MACHINE() and DEFINE_MACHINE_EXTENDED() in the PowerPC machine files to explicit TypeInfo and type_register_static() calls, adding the pegasos base machine to pegasos_machine_types[] in hw/ppc/pegasos.c. Signed-off-by: Yonggang Luo --- hw/ppc/amigaone.c | 18 ++++++++++++++++-- hw/ppc/pegasos.c | 21 ++++++++++++++------- hw/ppc/ppc440_bamboo.c | 18 ++++++++++++++++-- hw/ppc/prep.c | 18 ++++++++++++++++-- hw/ppc/sam460ex.c | 18 ++++++++++++++++-- hw/ppc/virtex_ml507.c | 18 ++++++++++++++++-- 6 files changed, 94 insertions(+), 17 deletions(-) diff --git a/hw/ppc/amigaone.c b/hw/ppc/amigaone.c index 2e94e80b569..3cd3e92d2d8 100644 --- a/hw/ppc/amigaone.c +++ b/hw/ppc/amigaone.c @@ -416,8 +416,10 @@ static void amigaone_init(MachineState *machine) } } -static void amigaone_machine_init(MachineClass *mc) +static void amigaone_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Eyetech AmigaOne/Mai Logic Teron"; mc->init = amigaone_init; mc->block_default_type = IF_IDE; @@ -427,4 +429,16 @@ static void amigaone_machine_init(MachineClass *mc) mc->default_ram_size = 512 * MiB; } -DEFINE_MACHINE("amigaone", amigaone_machine_init) +static const TypeInfo amigaone_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("amigaone"), + .parent = TYPE_MACHINE, + .class_init = amigaone_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void amigaone_machine_register_types(void) +{ + type_register_static(&amigaone_machine_typeinfo); +} + +type_init(amigaone_machine_register_types) diff --git a/hw/ppc/pegasos.c b/hw/ppc/pegasos.c index fba2a558905..ffa63456320 100644 --- a/hw/ppc/pegasos.c +++ b/hw/ppc/pegasos.c @@ -732,8 +732,9 @@ static bool pegasos_setprop(MachineState *ms, const char *path, return true; } -static void pegasos_machine_init(MachineClass *mc) +static void pegasos_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); PPCVirtualHypervisorClass *vhc = PPC_VIRTUAL_HYPERVISOR_CLASS(mc); VofMachineIfClass *vmc = VOF_MACHINE_CLASS(mc); @@ -787,13 +788,19 @@ static void pegasos2_machine_class_init(ObjectClass *oc, const void *data) mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7457_v1.2"); } -DEFINE_MACHINE_EXTENDED("pegasos", MACHINE, PegasosMachineState, - pegasos_machine_init, true, false, - (const InterfaceInfo[]) { - { TYPE_PPC_VIRTUAL_HYPERVISOR }, - { TYPE_VOF_MACHINE_IF }, { } }) - static const TypeInfo pegasos_machine_types[] = { + { + .name = MACHINE_TYPE_NAME("pegasos"), + .parent = TYPE_MACHINE, + .class_init = pegasos_machine_class_init, + .instance_size = sizeof(PegasosMachineState), + .abstract = true, + .interfaces = (const InterfaceInfo[]) { + { TYPE_PPC_VIRTUAL_HYPERVISOR }, + { TYPE_VOF_MACHINE_IF }, + { } + }, + }, { .name = MACHINE_TYPE_NAME("pegasos1"), .parent = TYPE_PEGASOS_MACHINE, diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c index 2dde008b0e4..401f7bee572 100644 --- a/hw/ppc/ppc440_bamboo.c +++ b/hw/ppc/ppc440_bamboo.c @@ -256,8 +256,10 @@ static void bamboo_init(MachineState *machine) } } -static void bamboo_machine_init(MachineClass *mc) +static void bamboo_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "bamboo"; mc->init = bamboo_init; mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("440epb"); @@ -265,4 +267,16 @@ static void bamboo_machine_init(MachineClass *mc) mc->default_nic = "e1000"; } -DEFINE_MACHINE("bamboo", bamboo_machine_init) +static const TypeInfo bamboo_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("bamboo"), + .parent = TYPE_MACHINE, + .class_init = bamboo_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void bamboo_machine_register_types(void) +{ + type_register_static(&bamboo_machine_typeinfo); +} + +type_init(bamboo_machine_register_types) diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c index 2672eb9e7a7..4afc4e20c67 100644 --- a/hw/ppc/prep.c +++ b/hw/ppc/prep.c @@ -441,8 +441,10 @@ static void ibm_40p_init(MachineState *machine) } } -static void ibm_40p_machine_init(MachineClass *mc) +static void ibm_40p_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "IBM RS/6000 7020 (40p)", mc->init = ibm_40p_init; mc->max_cpus = 1; @@ -456,4 +458,16 @@ static void ibm_40p_machine_init(MachineClass *mc) machine_add_audiodev_property(mc); } -DEFINE_MACHINE("40p", ibm_40p_machine_init) +static const TypeInfo ibm_40p_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("40p"), + .parent = TYPE_MACHINE, + .class_init = ibm_40p_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void ibm_40p_machine_register_types(void) +{ + type_register_static(&ibm_40p_machine_typeinfo); +} + +type_init(ibm_40p_machine_register_types) diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c index b13dd224ba1..934ae3874c3 100644 --- a/hw/ppc/sam460ex.c +++ b/hw/ppc/sam460ex.c @@ -509,8 +509,10 @@ static void sam460ex_init(MachineState *machine) boot_info->entry = entry; } -static void sam460ex_machine_init(MachineClass *mc) +static void sam460ex_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "aCube Sam460ex"; mc->init = sam460ex_init; mc->block_default_type = IF_IDE; @@ -519,4 +521,16 @@ static void sam460ex_machine_init(MachineClass *mc) mc->default_ram_id = "ppc4xx.sdram"; } -DEFINE_MACHINE("sam460ex", sam460ex_machine_init) +static const TypeInfo sam460ex_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("sam460ex"), + .parent = TYPE_MACHINE, + .class_init = sam460ex_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void sam460ex_machine_register_types(void) +{ + type_register_static(&sam460ex_machine_typeinfo); +} + +type_init(sam460ex_machine_register_types) diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c index 09686360e16..2a4c8c9fc93 100644 --- a/hw/ppc/virtex_ml507.c +++ b/hw/ppc/virtex_ml507.c @@ -281,12 +281,26 @@ static void virtex_init(MachineState *machine) env->load_info = &boot_info; } -static void virtex_machine_init(MachineClass *mc) +static void virtex_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Xilinx Virtex ML507 reference design"; mc->init = virtex_init; mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("440-xilinx"); mc->default_ram_id = "ram"; } -DEFINE_MACHINE("virtex-ml507", virtex_machine_init) +static const TypeInfo virtex_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("virtex-ml507"), + .parent = TYPE_MACHINE, + .class_init = virtex_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void virtex_machine_register_types(void) +{ + type_register_static(&virtex_machine_typeinfo); +} + +type_init(virtex_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:17:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:17:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465825.1676299 (Exim 4.92) (envelope-from ) id 1xMoMa-0000Vp-Gx; Fri, 30 Oct 2026 15:17:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465825.1676299; Fri, 30 Oct 2026 15: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 1xMoMa-0000Vi-Dp; Fri, 30 Oct 2026 15:17:52 +0000 Received: by outflank-mailman (input) for mailman id 1465825; Fri, 30 Oct 2026 15:17:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoMY-0000TC-Sq for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:17:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoMY-0027Pl-9a for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:17:50 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b50f-8faa-0a2a0a5109dd-0a2a45029166-22 for ; Fri, 30 Oct 2026 16:17:50 +0100 Received: from [74.125.82.41] (helo=mail-dl1-f41.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b51c-6ca4-0a2a45020019-4a7d5229adba-3 for ; Fri, 30 Oct 2026 16:17:50 +0100 Received: by mail-dl1-f41.google.com with SMTP id a92af1059eb24-15dd124bbe7so1423108c88.1 for ; Fri, 30 Oct 2026 08:17:49 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.17.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:17: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=20260707 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=20260707; t=1793373468; x=1793978268; 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=BKYw1CARIGHPsFEBA2gFzPiJ4otfJ5ejgAQP620fQvg=; b=XQtqfBM5JEUvB0l5QxiDdCt9ac0S8BMSiyS6OCTM5u5SNkmtbFM0UY2UDGsCPjp92U ucdHYlkQNwYmNc+th0Mx/nTdMrWuq1N6tod7+6nassosMpxlXeqL26p+FLzBXev3qKLp cozphZWIctrIPIZNk98w9SHMheOHFw9xYk/uonWqOgwYQzsXcIQF9IBx0KBkuQwJGEXo v3GEVEn0aOqGDfjRFu72/GInUtG0A0YnWiLIKf5Uf3e1AvzgMZ25qOKGC4D38OXzaUoU ADfrseVZhfWsOy0oXCS64hpIZ0vXpFsV+GypsQPsV4+xs64Z3HVsmj6f6OLHoOFbW1Z/ 0KNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373468; x=1793978268; 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=BKYw1CARIGHPsFEBA2gFzPiJ4otfJ5ejgAQP620fQvg=; b=oDP+s0ATMocZCZsUWrRGlUvthF+gXwgluG04PrEmLxCPpixuWOEMpN8Yvja0M1Vmqp u2FPqrPu60J2z6vYM47e8JmHN6dIL2HFMgPSZSxlkBQAuMChPaCLGmzh0Q+Js8k93oMi SDJQHxpJVKHXlhlIQ0KLhgK0apB8R+I7L6Kub71oqPINavs/yz/b7QKNv2gNrIT5uSR0 pF+Q2YkQGc42Um71hEgGZi4osPMO0fVKqrd8qlbcjYzSOz2h3Gok+aE7nayOOPWyFPqp LsKzpYDh0/xN4dP9qNfCUxip9Ubp86KfwF25NpLqKUGGwyFMWgWkYZeiO4nTaF4GzCo9 Wv6Q== X-Forwarded-Encrypted: i=1; AKwUvBzLN+VdazE/tDnm3KEW7LRVqM1HJ7psuE8VPSHs+QvtURZ4p5D5zPKrWmyVruGdaBvWNcB2RFl+iKI=@lists.xenproject.org X-Gm-Message-State: AFq9FYJJYt86n+8r3FauYRXkqxRvK4ASyrZaXYfeRvyrlW0+znQifo1F lxFEbNi9ETeSahOnIBsWcRNhcvz/jRpqDsrUDs9PAJSzNhKnsbX2kieP X-Gm-Gg: AYBFou0F5k5GdYuq92VYQY+UBTynaWDWmLtqPQAPjyaBpxqT1fUlAgbKwUY4fGGLm4x gIrm4OG6L8pf8vwEX84kBHvKEiJD4gCQrIdd1w3V7Zw61cwLaTnHiT6NUMjf8tD8eVqNM8ZPpqK mDqqpZCc/K3PhzXgu+dqXp56ADCuoU/ZbEE6KhaiovIh0yJhqNAV4AqXyNUPWf7SlAsGkkVZHao i31+nLiWHPxTzkwsE53nCSQnUrlpGCvv5futhyppEfHmqpzCmC76UaUWaHRY55HbfbRpVI8W8qL OOBjIMFPdcGbx0s0JijMm1v51nVq/Wq2UQ9H1VHcJnTako4C0Bqf/BrsomaGUyWN3KVhTbSCppZ H9bUVsxzNAG7RQX3DrdaA//1eFr4nESEx7GTjQt38LMjct3MCyF4hqX730H/XaJ/LMc5CyrotCT 0JugsEVgJJ4AtUHQQK5F9SxmpIfgRrEnh3OgBlnyi4NudwZVRxDE+b8TNKqA+j1LQcqPrSvOgsX Jl5quAHQLAmzpsrdI81uKyqKLxN71H8AG9LU6bGWQqE37Yq6hjmKgx2WIhB+ixTQX8fQfw2FUxI corwngVC5HbHpQNZ8N/CTGNhIo/N3b+TJrpx8NX+xbk39+SB X-Received: by 2002:a05:7022:eb42:20b0:186:4a57:94e5 with SMTP id a92af1059eb24-1ac5c272744mr3802599c88.34.1793373467893; Fri, 30 Oct 2026 08:17:47 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 10/15] hw/sh4: expand DEFINE_MACHINE in r2d.c Date: Fri, 30 Oct 2026 23:15:31 +0800 Message-ID: <20261030151539.1872-11-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1793373470-315CD2AC-82E857BE/0/0 X-purgate-type: clean X-purgate-size: 1362 Expand DEFINE_MACHINE() in hw/sh4/r2d.c to r2d_machine_typeinfo and r2d_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/sh4/r2d.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c index 99afe3618e8..fb80c935ea6 100644 --- a/hw/sh4/r2d.c +++ b/hw/sh4/r2d.c @@ -378,8 +378,10 @@ static void r2d_init(MachineState *machine) SDRAM_BASE + BOOT_PARAMS_OFFSET); } -static void r2d_machine_init(MachineClass *mc) +static void r2d_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "r2d-plus board"; mc->init = r2d_init; mc->block_default_type = IF_IDE; @@ -387,4 +389,16 @@ static void r2d_machine_init(MachineClass *mc) mc->default_nic = "rtl8139"; } -DEFINE_MACHINE("r2d", r2d_machine_init) +static const TypeInfo r2d_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("r2d"), + .parent = TYPE_MACHINE, + .class_init = r2d_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void r2d_machine_register_types(void) +{ + type_register_static(&r2d_machine_typeinfo); +} + +type_init(r2d_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:18:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:18:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465834.1676307 (Exim 4.92) (envelope-from ) id 1xMoMl-00010b-NX; Fri, 30 Oct 2026 15:18:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465834.1676307; Fri, 30 Oct 2026 15: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 1xMoMl-00010U-KQ; Fri, 30 Oct 2026 15:18:03 +0000 Received: by outflank-mailman (input) for mailman id 1465834; Fri, 30 Oct 2026 15:18:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoMj-0000yN-Ou for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:18:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoMj-000LaV-5e for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:18:01 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b51a-bab6-0a2a0a5309dd-0a2a4508ed70-40 for ; Fri, 30 Oct 2026 16:18:01 +0100 Received: from [74.125.82.48] (helo=mail-dl1-f48.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b527-f659-0a2a45080019-4a7d5230b4a6-3 for ; Fri, 30 Oct 2026 16:18:00 +0100 Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-1a3c08d6928so1021752c88.0 for ; Fri, 30 Oct 2026 08:18:00 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.17.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08: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=20260707 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=20260707; t=1793373479; x=1793978279; 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=unXNvMdiHSqKZbW2yjBCaHIctKeqs2ATJiqxjlNdZQs=; b=Z1ksLwSV57ikCDfurudLxGHfpduqJw9V9E1ZVvIivCvEoI43ci9UlvMn2soi94t5pN KhOymbsvqw2g2eb9/AAtfBeXUF/zqIOD2BRi/iLrTyufqJtDYROP8fU+s0UnkC6TlA1/ wmrjyWQySmrQsvvckJfZ2vy3ZAuh8My/7bX+tIzMiZmJiv6rtYF2gstgWVggJrn46OUe VmJLyLTdseUATgQ/P7zvVCcJqkk09/K9WS7aV0t/uzgisGsyjoGvti3RnmnegdG9Tx2P l+tFS9uVWExdU/6XYPya2XRWCD9VYxyvg3RCQLJjy2RDysEbLPr5+isZJ1mKRb+PZIIw SMsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373479; x=1793978279; 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=unXNvMdiHSqKZbW2yjBCaHIctKeqs2ATJiqxjlNdZQs=; b=1ioegHY8pz0Asa9uCnmduIgFVx9TDnX/mMLUbFuWZv8wkfZVZ0AamU1kgy9oZTsKB6 xonh/kO3L49lAWpix0hCtycNpTReILDas4aOyVorXQkmUWBsr68UKIhkFJM7kmYjs1bi 4Uk1AaqqoJCXCqj/rvk/+YTOvTyNMn7aFEqxFVJ3dLBP9oBQ3Kj4qQMq4dZCpaz3iIFA EXiKErAMYbr/QVtlyiXm+7t+abs6sLIW2+pnycCXecKI4n5/WvmUTuGnLfVGZARtH/eh 1fdXIXA4bssyRbRvwnFvBWHlJI9ZXHBjXSrAZsCSAcIxmL40ajqtBhXm7AoIaspFYRiv QP8g== X-Forwarded-Encrypted: i=1; AKwUvBzYorreJ+1lrMxI9K0MuWb8aMp8ofh2zsM5aRrZ9bYGx0HFn1V+wzgwcYdFfGW9CrbU1PywX+1RWCo=@lists.xenproject.org X-Gm-Message-State: AFq9FYLSf82/NVoomJxM0TynHyMEDfu/CvFrgQkdqm55OIzP0cixNY6j 2K0rslhVZPddyBBgLuBDKb2w03Jt+PGCgM8ChnSaN/ww4dORzFFT8Ff/ X-Gm-Gg: AYBFou11FqHMa3SctHdxNv+gXm1/Hd5nJqDgjFG8Vnb7acwPw3VAAsl5a0WFNLgn2zl 7RPsaFtggbA/h9orTDBLW/tRu49Rr3M9FN5CBYlMPNROVn/Tt00Qgpi1fk+tAl0/SacQ9qta5KS EPvnfzrxQD0k9a+ga2OuCg5FOP7qf25NK4d3TAcvlx/lKUAus4QBfZTQk8mtifHbyrlpFcxKwx1 aQEHa2WkRBRqqBM5y+YUHVQHv3/jn8jFUDrhwEVc7ZXxukZ+GW0luGbb1T/xqV7Bq8P3FFUr8eV 8pNsgTfLGbREV1ZwrLNAqQn3gdpafn4TJB2fvW/eXIULK3w3zGzThNksy4z3ywsNT6OD9lVdt6O tyfMmAoQjai3CWEQxctx4suZsk4NcMzEwTngxhUbKaQ8/8agxvCMxrOquCfB0zzSGd+027NsPV0 tp+HwDc1eYjHQ33flwSVCP34vrJ9Bgn7aFllo7ZSOB6rrtBg3Q2FAoijs7cbTmBajsgQxsdNyMu GTmiBzlPsSeshJrXBPlmBLBCtZRYSJje/yxhjUgV9uthOIo47Zb+qvzDkU94d1uN6yajf833Aea 3/dKNXwsykchl72BKBG8OJtqnKAU7y4BAonasSTWuHqTM+mh X-Received: by 2002:a05:7022:ea8e:b0:1ac:f84d:4036 with SMTP id a92af1059eb24-1acf84d43f8mr2092732c88.9.1793373478878; Fri, 30 Oct 2026 08:17:58 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 11/15] hw/sparc: expand DEFINE_MACHINE in leon3.c Date: Fri, 30 Oct 2026 23:15:32 +0800 Message-ID: <20261030151539.1872-12-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1793373481-D775B87B-D41EE646/0/0 X-purgate-type: clean X-purgate-size: 1565 Expand DEFINE_MACHINE() in hw/sparc/leon3.c to leon3_generic_machine_typeinfo and leon3_generic_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/sparc/leon3.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c index d4a6e917598..ddc25f528ff 100644 --- a/hw/sparc/leon3.c +++ b/hw/sparc/leon3.c @@ -434,8 +434,10 @@ static void leon3_generic_hw_init(MachineState *machine) LEON3_UART_IRQ, GRLIB_APBIO_AREA); } -static void leon3_generic_machine_init(MachineClass *mc) +static void leon3_generic_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Leon-3 generic"; mc->init = leon3_generic_hw_init; mc->default_cpu_type = SPARC_CPU_TYPE_NAME("LEON3"); @@ -443,4 +445,16 @@ static void leon3_generic_machine_init(MachineClass *mc) mc->max_cpus = MAX_CPUS; } -DEFINE_MACHINE("leon3_generic", leon3_generic_machine_init) +static const TypeInfo leon3_generic_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("leon3_generic"), + .parent = TYPE_MACHINE, + .class_init = leon3_generic_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void leon3_generic_machine_register_types(void) +{ + type_register_static(&leon3_generic_machine_typeinfo); +} + +type_init(leon3_generic_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:18:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:18:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465847.1676316 (Exim 4.92) (envelope-from ) id 1xMoNT-0001pu-VB; Fri, 30 Oct 2026 15:18:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465847.1676316; Fri, 30 Oct 2026 15: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 1xMoNT-0001pn-SW; Fri, 30 Oct 2026 15:18:47 +0000 Received: by outflank-mailman (input) for mailman id 1465847; Fri, 30 Oct 2026 15:18:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoNS-0001pb-EX for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:18:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoNR-00DxRe-Rc for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:18:45 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b545-e002-0a2a0a5209dd-0a2a450bab4e-36 for ; Fri, 30 Oct 2026 16:18:45 +0100 Received: from [74.125.82.46] (helo=mail-dl1-f46.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b554-b7e8-0a2a450b0019-4a7d522eb453-3 for ; Fri, 30 Oct 2026 16:18:45 +0100 Received: by mail-dl1-f46.google.com with SMTP id a92af1059eb24-1a3c08d6928so1023241c88.0 for ; Fri, 30 Oct 2026 08:18:45 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.18.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:18: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=20260707 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=20260707; t=1793373524; x=1793978324; 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=D80p8QWI+5BbGopzHjtSexJQceQpYTApqX3mxRXadD8=; b=lte/W50HDHQmg9hoME9uX4Ndkx6TaUqTn0FQchh/oOGzjsdWKebPI1KLWK21RfKlj0 eogxTcmXoq45++FiS6bISmWpVJJ+P67WgxaIRxQ/5srgwazBewZBqsztXc1/nr5cQLqO yJa5WsUyExjsD+DMSSdnhSS3BbZ+9t86GDja8UiUBYPFMaD2bxiqYc7kr+ZG35OdllKh cL1UKXJISNB3gTDlU/VPmRZj2n9+qHG3QcWTpEfX72QgQ9BtdgfenmmG2n/qDce8uIci a84MDh+GAacWNlIRxpjL9/+hANSU+GI3n2KidgX/pS9ZWUly8facV0Z3ZaN+A/fCmrkE lRkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373524; x=1793978324; 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=D80p8QWI+5BbGopzHjtSexJQceQpYTApqX3mxRXadD8=; b=o1KRHyUliIeQqOjKe7mTRd42ELmJSy5/KGkuK8Lcxmj9zXA0NfQkEj3JVVzl1jAOCG HcweabjAQl97sRBD/hPovka+gvf6/sifawg3XXHTYEvrV9fO3Kz/kAFra01elNNGDdRT jLwOlN26PM0QF17HLPhKaE7uyKLNhLHTTfR2NtoF/1tOI7tPpN8s8cnXafYGcl55GR3z lld19MSQhzGTvxAD3l1K+wKX8jViXL8OFIFWDyFfwnEq6xQFWTtuqmYDmcRawXZ3nG2W mX1AIqS0Uf5UCeta64NboUIyisjN1lch9ldnDkh21SQhJf8mOVRReFEkXBbNLnj3gcLP mxdw== X-Forwarded-Encrypted: i=1; AKwUvBza634LJLZ4QZ3hlFIMyJ3NaoVulWxIjXwAzzcK18CNJmupshmDWGp/fLp5trh1cnBrDWX/yF34Bu4=@lists.xenproject.org X-Gm-Message-State: AFq9FYJHjdCBF3C8JEBKZ7PQT4jg9KNBXT3fAhI8SxEQlCFWgUTPSCEa diXvP/asLLvxoc1vHAw3sS0y5KnCgxOaXh3yXMmGU0L8HcxU5QabGgkG X-Gm-Gg: AYBFou3SY3TdBb97ydfZlOus+vVpjkvsWLa6bYHe6DuaO6FyGIGbDZ8QwP3JNLXgvm6 r8/UtY1WRviauFIEVIzVBpk4S8nUjQ+ncb3PwYpcg74iGqo9D21h2JQMz0pPfpAKNJfzTvLyRwC 9u+L8BoXNWYNLwAHkuV9zbpXMcMQatEKVzbpEmETz8BKh9yBbo2ODbAoZc+D5O+xg8OgXb0TkdB AYyT3QsrWHTx5koSEW7/LuS1DAQs9/CgN8B1c8zQ3YYtOYppwZGCVKmTlaZjQHqN9rH9nWLw6w1 wgaxsLypU5NFHxm1hb7YMDoFzqNw9mWWT09FPwmaJYkwy5kZm3b9mS5LcsFou0+uDvEk+jCv96o FMlYBc2UZRaEKaa6+Cw5Mpx5WTdaiZ4uFuMqc1geIQrmw0CRrTVgae0+5hAiSpyF8in7lFo6ZBu H6HEsM8MAc2W6gDFo3bjMCOfs7BAVSrv+aLSuddB0YS+TAPaSzhTPf8vFByqtGUOnJ31gqSXqae VKTkxTMFVzBsGoxd0RWRxkutY7AZKrBe7Zw8dyZOVhEj6ncYDyOxXwZSBA1IfJvMbRjx2GNqlYp jKIGR01Hv5Uju+YYuI75UuKMiMm9mlpnqiMsn8/EiO48CO44 X-Received: by 2002:a05:7022:7f13:b0:195:76af:b810 with SMTP id a92af1059eb24-1ac5bf91b35mr3525078c88.25.1793373523578; Fri, 30 Oct 2026 08:18:43 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 15/15] hw/core/boards: remove unused DEFINE_MACHINE* macros Date: Fri, 30 Oct 2026 23:15:36 +0800 Message-ID: <20261030151539.1872-16-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1793373525-A96C29EA-45DE13B9/0/0 X-purgate-type: clean X-purgate-size: 3060 All DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED callers have been expanded to explicit TypeInfo definitions, leaving DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* in include/hw/core/boards.h unused. Remove them. Signed-off-by: Yonggang Luo --- include/hw/core/boards.h | 48 ---------------------------------------- 1 file changed, 48 deletions(-) diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h index d0e4ad98201..8af927e9b7c 100644 --- a/include/hw/core/boards.h +++ b/include/hw/core/boards.h @@ -513,54 +513,6 @@ struct MachineState { * DEFINE_VIRT_MACHINE_IMPL(false, major, minor, micro, _, tag) */ -#define DEFINE_MACHINE_EXTENDED(namestr, PARENT_NAME, InstanceName, \ - machine_initfn, ABSTRACT, SECURE, ifaces...) \ - static void machine_initfn##_class_init(ObjectClass *oc, const void *data) \ - { \ - MachineClass *mc = MACHINE_CLASS(oc); \ - machine_initfn(mc); \ - } \ - static const TypeInfo machine_initfn##_typeinfo = { \ - .name = MACHINE_TYPE_NAME(namestr), \ - .parent = TYPE_##PARENT_NAME, \ - .class_init = machine_initfn##_class_init, \ - .instance_size = sizeof(InstanceName), \ - .abstract = ABSTRACT, \ - .secure = SECURE, \ - .interfaces = ifaces, \ - }; \ - static void machine_initfn##_register_types(void) \ - { \ - type_register_static(&machine_initfn##_typeinfo); \ - } \ - type_init(machine_initfn##_register_types) - -/* Implicitly insecure */ -#define DEFINE_MACHINE(namestr, machine_initfn) \ - DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \ - false, false, NULL) - -#define DEFINE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, ifaces...) \ - DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \ - false, false, ifaces) - -#define DEFINE_MACHINE_WITH_INTERFACES(namestr, machine_initfn, ...) \ - DEFINE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, \ - (const InterfaceInfo[]) { __VA_ARGS__ }) - - -#define DEFINE_SECURE_MACHINE(namestr, machine_initfn) \ - DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \ - false, true, NULL) - -#define DEFINE_SECURE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, ifaces...) \ - DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \ - false, true, ifaces) - -#define DEFINE_SECURE_MACHINE_WITH_INTERFACES(namestr, machine_initfn, ...) \ - DEFINE_SECURE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, \ - (const InterfaceInfo[]) { __VA_ARGS__ }) - /* * Helper for dispatching different macros based on how * many __VA_ARGS__ are passed. Supports 1 to 5 variadic -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:22:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:22:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465859.1676325 (Exim 4.92) (envelope-from ) id 1xMoQo-0003bu-Du; Fri, 30 Oct 2026 15:22:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465859.1676325; Fri, 30 Oct 2026 15:22: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 1xMoQo-0003bn-B4; Fri, 30 Oct 2026 15:22:14 +0000 Received: by outflank-mailman (input) for mailman id 1465859; Fri, 30 Oct 2026 15:22:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoQn-0003bh-8j for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:22:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoQm-009Msc-DW for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:22:12 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b618-e002-0a2a0a5209dd-0a2a4503a4e0-32 for ; Fri, 30 Oct 2026 16:22:12 +0100 Received: from [74.125.82.53] (helo=mail-dl1-f53.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b532-fae8-0a2a45030019-4a7d5235d5f3-3 for ; Fri, 30 Oct 2026 16:18:11 +0100 Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-18cdcfc05ffso1080352c88.1 for ; Fri, 30 Oct 2026 08:18:11 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.18.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08: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=20260707 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=20260707; t=1793373490; x=1793978290; 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=sGbrF5LygDW3ceui1OfwylCKsorUyXpzXpw3dzNJEUs=; b=M7WrjErZBdQVPtqNLc0u6+pd3tptF9VvkiJCx0lk2I+y3WqcgxGaODm/EUejlHMNYv BJ7roWVmOCwc3PckDnld7R1/KLgcy9oI9aLktSSNytbZTPzWeWAoKxwzQgsHFT3QQLUI 34ELeyndIimhUGaIQ10j9xhwFfEgJjLlOV45DcovpGyegv7yWGKXUrSxpWcTGfWhcdCm ut5dXr/job0DvQIzifiAw7SbabWV/zZOuic3EccUzwCNePz+QNj80mFFVxrsiKvotBiz Nzj1nTi1lClG238LHaJKvRIf9VuPJ8FcgY71cxVkLECtwygUZevnMaajynOLOxsdQ0sy 2lCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373490; x=1793978290; 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=sGbrF5LygDW3ceui1OfwylCKsorUyXpzXpw3dzNJEUs=; b=t7U5o5wkSPtBi3zSaZTDyxDtfDUaAau1bH26PP6r8VLavhxriDDYF9qjvrZj63K8an SUv5txf7EDyWRFyBw3jipLO9yK0wrj+l6OvBj2ZsRWWPvDOrVPr5mm7LEgbybrbesZ4n m3Pv+1qp6dNxOcCOeTasAPaN/fzUaHX/UHvjFm19h+Lb5qDkt8NgzpRtfOJghZDSOXTC ZMe2mLyAEh1K7TsSiVX8USzp0YujOvv5PudJ39xoUEF2srNboy1o7XdBb1VjchzL4JLs x+L9712QeRrucvC8AXrKrQG7Htj9z/u4HiRl81E+E59qUwRaz5wr+Rpv3UJvFR4zPa4C f69Q== X-Forwarded-Encrypted: i=1; AKwUvBwqg65mmyEHwVo+5JBodxTAvoWyebzm7rxDSH/fd3IjCUMGCUja1U1aN9jE8G3uwxjbONcDji53xuY=@lists.xenproject.org X-Gm-Message-State: AFq9FYL3kCA3zdwchSAPKhBkY3AIf0lo2yRqiZ9opfZQ4VWSBAgXtVgX 0KX3ORPo06ofR34TaI270Iy2Xv4lZYQYDNqgZP0nE8ufRfEUVfExIAm5 X-Gm-Gg: AYBFou3yEDod24RlMaeG+e90vijkdZxSLcjaaBFkEsYY9dgwnH1rs0BR/82Xt1677vL n7EfS1ZufscMk64C6Uyhzcqm72wrsC7rZQGz2HcSxbHLUDyEM1WWJpA8yLCVaZmO/N87RAtZ/h2 pxlRIs7/FnL8WdFsLBZFeitlPrX+7joXvNT9sGR9PHwPLP1/foED4qEoV5f0Rawb3NM/Aa+1EX8 7reOKtF2WFPP5THOb+rKiBPT/jPeMHkEf9N5JEwtsVA8PYLHXXz6jmadakYr9kamf9/dHJRqOZp RvjiOu525ULtOMi4KV5zkSF7BJCW+w/sV5oXCaDp5RuWdEZgDYT/37gajgwpAGeZl4UnZb03oP5 lKOakfZxYUGqIY+rNiIEmcywrddgjcMHD9P7tvN2HjT0xCZF4IdNVXmyHWXPoceejscdxsYzckr eWYih0X4VxXzLX4OcKF/XlAG5KQ6ZX/Fv5OC1WBZNN9u6tcT5uzaU7w14ffUzUEbORqZj3n43yz qnB4VwNcBuErzWE5bbyuoJOcC6pXht2l/p1/M/fylZzfsT9e7zrnziWyMNSlEqrOJWexFU9dd8M K1hpngMCIAr0KdQ6QbwYkvkrnHeKvigzPEH6JqoEHl2n1xvGwRH2EfuRwURCbk/Wl3py/A== X-Received: by 2002:a05:7022:258f:b0:165:dd90:1f54 with SMTP id a92af1059eb24-1ac5eea0384mr4400234c88.47.1793373489939; Fri, 30 Oct 2026 08:18:09 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 12/15] hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c Date: Fri, 30 Oct 2026 23:15:33 +0800 Message-ID: <20261030151539.1872-13-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1793373492-758824E9-47F12364/0/0 X-purgate-type: clean X-purgate-size: 1381 Expand DEFINE_MACHINE() in hw/xenpv/xen_machine_pv.c to xenpv_machine_typeinfo and xenpv_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/xenpv/xen_machine_pv.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c index c406821c34c..85ba65a3243 100644 --- a/hw/xenpv/xen_machine_pv.c +++ b/hw/xenpv/xen_machine_pv.c @@ -61,12 +61,26 @@ static void xen_init_pv(MachineState *machine) atexit(xen_config_cleanup); } -static void xenpv_machine_init(MachineClass *mc) +static void xenpv_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "Xen Para-virtualized PC"; mc->init = xen_init_pv; mc->max_cpus = 1; mc->default_machine_opts = "accel=xen"; } -DEFINE_MACHINE("xenpv", xenpv_machine_init) +static const TypeInfo xenpv_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("xenpv"), + .parent = TYPE_MACHINE, + .class_init = xenpv_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void xenpv_machine_register_types(void) +{ + type_register_static(&xenpv_machine_typeinfo); +} + +type_init(xenpv_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:22:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:22:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465860.1676334 (Exim 4.92) (envelope-from ) id 1xMoR0-0003sl-NL; Fri, 30 Oct 2026 15:22:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465860.1676334; Fri, 30 Oct 2026 15: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 1xMoR0-0003se-Kd; Fri, 30 Oct 2026 15:22:26 +0000 Received: by outflank-mailman (input) for mailman id 1465860; Fri, 30 Oct 2026 15:22:25 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoQz-0003rb-9E for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:22:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoQx-00EmBt-Ja for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:22:23 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b62a-2eae-0a2a0a5409dd-0a2a45038dd8-18 for ; Fri, 30 Oct 2026 16:22:23 +0100 Received: from [74.125.82.42] (helo=mail-dl1-f42.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b53d-fae8-0a2a45030019-4a7d522ad4ec-3 for ; Fri, 30 Oct 2026 16:18:23 +0100 Received: by mail-dl1-f42.google.com with SMTP id a92af1059eb24-1adbf62dd31so543667c88.0 for ; Fri, 30 Oct 2026 08:18:22 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.18.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:18: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=20260707 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=20260707; t=1793373501; x=1793978301; 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=c4ZF6CX3HwMSnOXWr+3Or5e7RYyQ6c3g85+NgZehtQ8=; b=f9y5VfKTLOpNY0D1Y2ymVsXBMw8UMj/+LeV7iUZeqtfE5yZBt6xzDlFXk0QtK961hW rvBqpCakhLdqqkjTE0H3E/Y8Vc9uiBIQG5drOwIFHLXoeAb6I2bQlk3pQJTx2khwoPr9 FumUbGHJZ3YYr6JukZzgfY4xKnVTXmHkNLe5NU9oBNX2dMfEWR+D8Psrk1+MDzcwiiAq r7uEmTuFlNyS8lRFFid334gUupRjrIK+153EFwckwmFV7B2BzoGjKKDmF4vJmgbTeu2V Cc7E9EpGFsZ+e2ZW6Lh+xXps3TcfBBfdviEF2OJ1rWwKlfm2/n+aPd2mqfSdKy0OhbDN ntzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373501; x=1793978301; 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=c4ZF6CX3HwMSnOXWr+3Or5e7RYyQ6c3g85+NgZehtQ8=; b=fhVZorovghc4ZocdJANxv3z0pUpn2EkE2YOh8mmgCUSLQ5xH5uAdZaicxOXz7I8udw 9mE0q1HzhR9znFXXoWMEUNb+F/Jbs4UwSRZc+P4Yvru+fHsam75ZjSjU41ah3u1IHRDQ P6O1ZbnjCoCvfS7nolmQLiyzwTEOUEIpbkQiLJscmnaSq2SV0nf6W6sVF8UG7ooaosf2 Z/4JKQmwPL8ENKknWzorfjBum2ZCE517Sa8cD6dCrmdFzFvC/VZYx0SthE00VS1aR7IQ oBqbmWMQgONb3vDCGB0iDsvQmCf7ukvAlHW1v66wxNK2hdsNEm0No7eLspRSChHVymG4 IAaQ== X-Forwarded-Encrypted: i=1; AKwUvBzdI093K/nFjg0JI232OvOcJ47fBpuHGP3oVg75hEWzeVjeWcGcvUhp2CHFoqIWc4CVgAgVpJEtByY=@lists.xenproject.org X-Gm-Message-State: AFq9FYJzNnEJY8hLTyUAcXN6F8BCKjS8Uihow8Z3W7Zl4cLkFdbYa0cY UJ23U+IHd7WEt5Avk3OPm/fs8OM2IhWgcQY5vv/H/RgRqDI6dBVb0NVW X-Gm-Gg: AYBFou1Ca0PlzeG3J4ZiZdNUvw5jc/4/RoaXfKuxtDjctr4ShElrBSMxIeBPd/xx346 djGY820DaICHjnh+ddbCPx0SuhwVGTqEHJXmDMn3gjz6Ks+ahtNTR9L4sUIrinlai0VWJ9mGxTg yqw0RSps3KfnB5Y6YJ9PqNUwOIxj/BbULngFZXWto6XZZ0a21ghhnHgdVmLQQEO5h333uG7LJff n6/5j3JLgzWzz+U8iuB5KgWprH8WgvLuvd3tjDljK6iIIzqonLHxt5/2Fb8M8jlHudqSS7mNl+I S1ObyWogQeFemDQIufHhz8O+vXUUqX4oGqlumLE0NycBEVMOXXSFv7I2sOpUIwp9m5LO258YnWz KrNRH1yJ3sSEgiHAhzCtjDIAVfyJbjAVC4/9GC1nL7N2yxksww/aDdU6kYdAjXcKIaLE7V22H54 TkUUEZN+f8MKgYns3v2YvT2O2lAjQshIOkUb8flWFZLxGTIxutLkQDmJMvlCmwkxiELogLPDXUt xpTTu93Q1okbJrtMQqU/M6KNpZ0qXsptPm0txttA8vQA36u/tZhsUM+wcdctSwELt6PcvDCvQR+ 1UvvOtHVBBjJF9NBlqO6TndhZl+/2XuUM3IMLgb9FtULnw27jg== X-Received: by 2002:a05:701b:4509:20b0:1a3:9936:d11e with SMTP id a92af1059eb24-1ac5e6007a2mr3303536c88.41.1793373501142; Fri, 30 Oct 2026 08:18:21 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 13/15] hw/xtensa: expand DEFINE_MACHINE in sim.c Date: Fri, 30 Oct 2026 23:15:34 +0800 Message-ID: <20261030151539.1872-14-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1793373503-774F44E9-CD73F2E0/0/0 X-purgate-type: clean X-purgate-size: 1493 Expand DEFINE_MACHINE() in hw/xtensa/sim.c to xtensa_sim_machine_typeinfo and xtensa_sim_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/xtensa/sim.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/xtensa/sim.c b/hw/xtensa/sim.c index 835cd04fe01..fd66009b950 100644 --- a/hw/xtensa/sim.c +++ b/hw/xtensa/sim.c @@ -121,8 +121,10 @@ static void xtensa_sim_init(MachineState *machine) xtensa_sim_load_kernel(cpu, machine); } -static void xtensa_sim_machine_init(MachineClass *mc) +static void xtensa_sim_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "sim machine (" XTENSA_DEFAULT_CPU_MODEL ")"; mc->is_default = true; mc->init = xtensa_sim_init; @@ -131,4 +133,16 @@ static void xtensa_sim_machine_init(MachineClass *mc) mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE; } -DEFINE_MACHINE("sim", xtensa_sim_machine_init) +static const TypeInfo xtensa_sim_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("sim"), + .parent = TYPE_MACHINE, + .class_init = xtensa_sim_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void xtensa_sim_machine_register_types(void) +{ + type_register_static(&xtensa_sim_machine_typeinfo); +} + +type_init(xtensa_sim_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 15:22:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 15:22:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465863.1676343 (Exim 4.92) (envelope-from ) id 1xMoRA-0004DH-WD; Fri, 30 Oct 2026 15:22:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465863.1676343; Fri, 30 Oct 2026 15:22: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 1xMoRA-0004DA-T5; Fri, 30 Oct 2026 15:22:36 +0000 Received: by outflank-mailman (input) for mailman id 1465863; Fri, 30 Oct 2026 15:22:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMoR9-0004B4-Jt for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 15:22:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMoR9-00HHQX-0r for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:22:35 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4b622-bab6-0a2a0a5309dd-0a2a4507a196-42 for ; Fri, 30 Oct 2026 16:22:35 +0100 Received: from [74.125.82.44] (helo=mail-dl1-f44.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4b549-b4ea-0a2a45070019-4a7d522ccc80-3 for ; Fri, 30 Oct 2026 16:18:34 +0100 Received: by mail-dl1-f44.google.com with SMTP id a92af1059eb24-170135e43c7so1231775c88.0 for ; Fri, 30 Oct 2026 08:18:34 -0700 (PDT) Received: from DESKTOP-Q716RM7 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id a92af1059eb24-1ac1854d925sm12770449c88.7.2026.10.30.08.18.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 08:18: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=20260707 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=20260707; t=1793373513; x=1793978313; 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=NpRZPrdA7p4HsMufejy4KcfzX3kqDfNgpM3OElffcBU=; b=TkgDF+fl3ok8OLoMXP2yKewM02XPlSTlUWs+BLBIYb+QOM4OlBtAvjMO+Ezx93Grep OQVQ2ERtMyvf+Z7haJz/iQxJBlCcNxdZje9dOhSOWYwVdAVeGJ2AOyLxwVju+XZydiFj BohBlQp1KBiCgWR1q2/AXgsQtEnYyMgI5A6q85smL/EJusfZ2OOzBzVhlKMWoBIGeIWq d7oo6Lq/93bgFCJ+2EhWWKmHAnvzudDNrjz9QtKiHen+t6VEQo2e1DNhIrmBCqR/6LAm rowicR7hExYqdPDERD2gR8h5bGwoUqmwWyZqF1XSsXzurqsjYvyh1ASQzCfMyOlMiEeq 2NhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793373513; x=1793978313; 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=NpRZPrdA7p4HsMufejy4KcfzX3kqDfNgpM3OElffcBU=; b=s7mfVM58lvibfjWlAx4uRMsNgqK/Q0zXVVEDngYlU92ugBRm0uM0awM+sax5jHS3Q4 cZt9Rsir8gsXYhqbKURGzkD8Ee2Q3paEptvbfVMytnbchGG5TMsM+fpmmfm4w2yNyepC pLhA4rZjKl1IVGVdbnJ5koFKQ90OzxaK+ncrPZnhqDRQmwYmthdVcRZlYwxK4BGG2XcC FvtWWeXVgynX+R6CWk+4lGhrYHmPJ7yM9pceZ9EU+yMoAZ5ubQNru+tXFIcAh7syBhix +6zrapomU0ijgFqHQ1rL6A8ECRcvdiwd34XDwYRfFLJhs7f2p6gc6ej6UZPOsmU0ZoyA +dgA== X-Forwarded-Encrypted: i=1; AKwUvByPbTQKdLWoaGfV4oe7CJOGtxvZ+r+zspkkUeY+PyvR2EM2I5VXyrUtjSlHGkS3AIagbErxTZkHpRs=@lists.xenproject.org X-Gm-Message-State: AFq9FYICNGLYh2fYBORxseYLk4KdqY9eSsIzc8AfVm30Vwf0ceESt6Ey AA+ZhKENMfqnP/ZXNt7iT/IV/R9HuawXdBZYIJ+iCd7QDVaMov9MThzN X-Gm-Gg: AYBFou24KY75ZQG2COLjXywzrToH1Ae8rzNMBeiB0XUqnkHGca1m3CGlZTSaBLdTRb0 f1KB+GzeR9hJSKlJTFy/6yRfVXQ08HC0ewJipwtN47BShYWvaSOpHvpX7SA/7DZtvuQeKlnXN5A 7H5c75ExeDOwEgaC1eM+aqZ0PiNM4Gx+1+jYmzb8C/YfZyqavEAes+gPcYai+DPnde01Cj9yj50 qqgtllOTi8NzoR/S7nMnH9e7445tGs6J6BfCnwTY0TRMI1Mg8IBF6to5FpqbUuQpSFClRXVTj9U rwgutEX7/F3+vRl9wm9ELFqpKFTKrKAmxt/CmK1ZG/IprVC8GBn1ApoUOjsd7zGr2/VsXqcvbfg vaL5LeT+ih01kQ9fMrr0ZDZIybV3C8zQUhiAJ1L7L4o4MM5ewxveavdkeq2hObhbq7wuq0HbErr wZIBuutmsCJclIlwkpsMI8tOzPZH7k3tlcC157lvKlMBi97D8A48AuOeFrISvdFZ5fCVLJbtz43 HPZ9fXTHTgWWeNzeZqHVn2SqR1yWwnCVOzHS7KPpx64DZtzi6xfpWnjztLXwNWqaoPi4kEYnbqT hKt/Q48e8LedEWxNzQTgX+C1x5H0sX9ponU0sdkAHlEXoAgCnhsnLPj1S9GYI5I4vQvOww== X-Received: by 2002:a05:701b:2082:b0:143:271a:3df2 with SMTP id a92af1059eb24-1ac5eea21f1mr3303233c88.44.1793373512457; Fri, 30 Oct 2026 08:18:32 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?q?Cl=C3=A9ment=20Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: [PATCH 14/15] hw/xtensa: expand DEFINE_MACHINE in virt.c Date: Fri, 30 Oct 2026 23:15:35 +0800 Message-ID: <20261030151539.1872-15-luoyonggang@gmail.com> X-Mailer: git-send-email 2.55.0.windows.3 In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1793373514-3C411AE4-EA0D7EC6/0/0 X-purgate-type: clean X-purgate-size: 1499 Expand DEFINE_MACHINE() in hw/xtensa/virt.c to xtensa_virt_machine_typeinfo and xtensa_virt_machine_register_types() calling type_register_static(). Signed-off-by: Yonggang Luo --- hw/xtensa/virt.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c index 271f06e0953..8c8fdad72f0 100644 --- a/hw/xtensa/virt.c +++ b/hw/xtensa/virt.c @@ -115,8 +115,10 @@ static void xtensa_virt_init(MachineState *machine) xtensa_sim_load_kernel(cpu, machine); } -static void xtensa_virt_machine_init(MachineClass *mc) +static void xtensa_virt_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "virt machine (" XTENSA_DEFAULT_CPU_MODEL ")"; mc->init = xtensa_virt_init; mc->max_cpus = 32; @@ -124,4 +126,16 @@ static void xtensa_virt_machine_init(MachineClass *mc) mc->default_nic = "virtio-net-pci"; } -DEFINE_MACHINE("virt", xtensa_virt_machine_init) +static const TypeInfo xtensa_virt_machine_typeinfo = { + .name = MACHINE_TYPE_NAME("virt"), + .parent = TYPE_MACHINE, + .class_init = xtensa_virt_machine_class_init, + .instance_size = sizeof(MachineState), +}; + +static void xtensa_virt_machine_register_types(void) +{ + type_register_static(&xtensa_virt_machine_typeinfo); +} + +type_init(xtensa_virt_machine_register_types) -- 2.55.0.windows.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 16:51:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 16:51:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465934.1676371 (Exim 4.92) (envelope-from ) id 1xMpoh-0005h9-KR; Fri, 30 Oct 2026 16:50:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465934.1676371; Fri, 30 Oct 2026 16:50: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 1xMpoh-0005h1-GX; Fri, 30 Oct 2026 16:50:59 +0000 Received: by outflank-mailman (input) for mailman id 1465934; Fri, 30 Oct 2026 16:50:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMpog-0005g6-0E for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:50:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMpof-00HTpX-Cy for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:50:57 +0100 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4cab1-8faa-0a2a0a5109dd-0a2a45088dba-30 for ; Fri, 30 Oct 2026 17:50:57 +0100 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 6ae4caf1-f659-0a2a45080019-d155802ac1b0-3 for ; Fri, 30 Oct 2026 17:50:57 +0100 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4a5036bbac7so5859245e9.3 for ; Fri, 30 Oct 2026 09:50:57 -0700 (PDT) Received: from framework13.home ([2a01:e11:3:1ff0:831:b00b:e409:f875]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4abf396dfdbsm74305045e9.1.2026.10.30.09.50.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 09: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=edera.dev header.i="@edera.dev" 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.dev; s=google; t=1793379057; x=1793983857; 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=BHbJwlNel7oeXOuhSgNQ/cQeRQwXwAq7hTzL8o/4KZw=; b=fxEif2nNTz8myRDi8ueBoDhoG5Gi5nMM1XZWjb1faVcklVvCp3E5Gy7T/1wzMW9bID a7I4nMFaVMfw1+Orky71NO0sSop6Vqh+xAtR6joYlG3FRAhgpCh0lJE50hBRwkBljLpn klNc7ySSSSZU4b5hycive0BtMoM02pssBOkfUuI0VgfDI1OJ5h4i/N218bX59mcChbN4 iX9KrSGwv2iB6gaaeawmktbzP4U86p9MmHX4F6ALDERTMuS1VPgaoDUH0ZgY9FqCFDoy aGk19d0e5x/RHY+Q9NwiIcDRpo8FQIn6yLfKcbBlUBTGe2m412lRTNqz2/aHIuAZ8Axi yKug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793379057; x=1793983857; 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=BHbJwlNel7oeXOuhSgNQ/cQeRQwXwAq7hTzL8o/4KZw=; b=EieI4nIl+naA6nmAOf7Ao8LH5MO5ldXcn+V3tMsJJq1VCN/6nBYEDUKGEAhJqz2/5P Kx0UCm0SEw3KSVHX20VvmqEhGzL2H1QL/O7odlmUd/rQIsCUBYc6t9ZLpIsqK2oqZDGF oARJc+xQfyVRBL33BuJbyY1dTPJAzLcj3jFR1Jqk3KR6W31LqGVZV/qd6n9F61QOLa4x 3inDMCiLSgg9fWEWKCuAwaLe/EBdSdsulHFL6FiNncBmQ1wYhncBpr6FoTJuXjIdm4NR fX85j1139p1VE4VOIpYzIfl1mm8mPSEcjMY3EHsbOUnkfUVMlZITzG9mThWXV618oBNZ azPA== X-Gm-Message-State: AFq9FYLV5tsi1aAeSF37loZysCEbNJNrhqN+neTa00N6VzpBsU9M/NqT /kVae+E+076jqiMEw5AMEz6bT0DdKvkuyBsOrMItECAh7htONdsfP4pD/2gZy1sYDXYWtKTEIjR PTVl69Ivztw== X-Gm-Gg: AYBFou2vY4a6f5fNICVzm5/AYWUaFQfjLUaASNFY2wUUu0lOrA7O3AhzFFXfpUgadmA UPicaUA2lAv6JIWOzWw/VeOIW/PA0yT53Xoirnuvo26173gp77wFiIhJXLr8xeZ/cOwZm1s6Cz0 glQUuV9vfoKHZ5ZVW+DnGSyqQhs7JNxN5iVmvIuYndJ6RfPGJIK54/WHHoWqPEY8aFlPfu7bSup Y14IrJZauSdmhc1Ql+qJJmYrpUX1SOVxYsNafBc+moaUV+nEdu98lKPAEXUYCwrfuHQvMYS43oP wuR13BJAm5HXPEcB410SL9nvVHPIZdPo3d9Z+YDCB8tursDDve0gWmxiUWmDYJmuTJ20JPbuJB2 J8N1biLqwA11R8f/dMAi8U6jZDqv0J2qxkXI4bcZWg9OmShy2aewzkmWXC1SsMIO8Gr685Dh9wl ftc+J6f0AmN5MJMhXWvHD3jeBXiSNPaAu9zYPYkhjivu1Sxn4mJgbaxH/SauGiu56zTjB7c93Vh vWw0YM7WxKtjyFJ3XpjCiVbHWkQsK961ujbuVPc4BbfXPJGtEah+inIjHMDQsn4lnNI7XwU+JRQ kbqHauHu6SLJ2OmEE8Ld7S8lAnobxasfuRMEud/LdSlUay4= X-Received: by 2002:a05:600c:34cf:b0:4a7:c366:d791 with SMTP id 5b1f17b1804b1-4ac150b38ebmr67069405e9.1.1793379056683; Fri, 30 Oct 2026 09:50:56 -0700 (PDT) From: Luca Di Maio To: xen-devel@lists.xenproject.org Cc: Luca Di Maio , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD Subject: [PATCH 2/3] x86/HVM: defer IOTLB flushes across a grant unmap batch Date: Fri, 30 Oct 2026 17:50:09 +0100 Message-ID: <20261030165031.2560020-3-luca@edera.dev> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261030165031.2560020-1-luca@edera.dev> References: <20261030165031.2560020-1-luca@edera.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1793379057-D694287B-5BE3560F/0/0 X-purgate-type: clean X-purgate-size: 8479 gnttab_unmap_grant_ref() flushes the TLBs of a PV caller once per group of GNTTAB_UNMAP_BATCH_SIZE unmaps. A translated caller instead gets an IOTLB flush per page from the p2m code, so netback in a PVH dom0 issues one for every page a domU transmits. Open a batch for translated callers before each group, and end it next to gnttab_flush_tlb(), so before unmap_common_complete() releases the pages. Ending the batch flushes the smallest aligned power-of-two range holding all the unmapped gfns, as VT-d flushes any other range as a whole domain. The batch lives in the vCPU, and iommu_dont_flush_iotlb isn't held across the guest copies between the unmaps, as those can sleep on a vm_event ring and change the p2m, e.g. by unsharing a page. If the flush fails, the pages may still be reachable through the IOMMU, so the group isn't completed and its pages leak. PV callers, Arm, and other callers of replace_grant_host_mapping() are unchanged. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Luca Di Maio --- xen/arch/arm/include/asm/grant_table.h | 3 ++ xen/arch/x86/hvm/grant_table.c | 47 +++++++++++++++++++++- xen/arch/x86/include/asm/grant_table.h | 13 ++++++ xen/arch/x86/include/asm/hvm/grant_table.h | 5 +++ xen/arch/x86/include/asm/hvm/vcpu.h | 9 +++++ xen/common/grant_table.c | 6 +++ 6 files changed, 82 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h index 7661a95341..66f90083db 100644 --- a/xen/arch/arm/include/asm/grant_table.h +++ b/xen/arch/arm/include/asm/grant_table.h @@ -40,6 +40,9 @@ int create_grant_host_mapping(uint64_t gpaddr, mfn_t frame, int replace_grant_host_mapping(uint64_t gpaddr, mfn_t frame, uint64_t new_gpaddr, unsigned int flags); +static inline void gnttab_unmap_batch_begin(void) {} +static inline int gnttab_unmap_batch_end(void) { return 0; } + /* * The region used by Xen on the memory will never be mapped in DOM0 * memory layout. Therefore it can be used for the grant table. diff --git a/xen/arch/x86/hvm/grant_table.c b/xen/arch/x86/hvm/grant_table.c index afe449d888..1d7f9b19f9 100644 --- a/xen/arch/x86/hvm/grant_table.c +++ b/xen/arch/x86/hvm/grant_table.c @@ -41,6 +41,8 @@ int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame, p2m_type_t type; mfn_t old_mfn; struct domain *d = current->domain; + struct hvm_grant_unmap_batch *batch = ¤t->arch.hvm.grant_unmap_batch; + int rc; if ( new_addr != 0 || (flags & GNTMAP_contains_pte) ) return GNTST_general_error; @@ -54,7 +56,25 @@ int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame, type, mfn_x(old_mfn), mfn_x(frame)); return GNTST_general_error; } - if ( p2m_remove_page(d, _gfn(gfn), frame, PAGE_ORDER_4K) ) + + /* Not across the guest copies, which can change the p2m or sleep. */ + if ( batch->open ) + { + this_cpu(iommu_skipped_flush_flags) = 0; + this_cpu(iommu_dont_flush_iotlb) = true; + } + + rc = p2m_remove_page(d, _gfn(gfn), frame, PAGE_ORDER_4K); + + if ( batch->open ) + { + this_cpu(iommu_dont_flush_iotlb) = false; + batch->iommu_flags |= this_cpu(iommu_skipped_flush_flags); + batch->gfn_lo = min(batch->gfn_lo, gfn); + batch->gfn_hi = max(batch->gfn_hi, gfn); + } + + if ( rc ) { put_gfn(d, gfn); return GNTST_general_error; @@ -64,6 +84,31 @@ int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame, return GNTST_okay; } +void grant_p2m_unmap_batch_begin(void) +{ + struct hvm_grant_unmap_batch *batch = ¤t->arch.hvm.grant_unmap_batch; + + ASSERT(!batch->open); + *batch = (struct hvm_grant_unmap_batch){ .open = true, .gfn_lo = ~0UL }; +} + +int grant_p2m_unmap_batch_end(void) +{ + struct domain *d = current->domain; + struct hvm_grant_unmap_batch *batch = ¤t->arch.hvm.grant_unmap_batch; + unsigned int order; + + batch->open = false; + + if ( !batch->iommu_flags ) + return 0; + + /* VT-d flushes any range but an aligned power of two as a whole domain. */ + order = flsl(batch->gfn_lo ^ batch->gfn_hi); + return iommu_iotlb_flush(d, _dfn(ROUNDDOWN(batch->gfn_lo, 1UL << order)), + 1UL << order, batch->iommu_flags); +} + /* * Local variables: * mode: C diff --git a/xen/arch/x86/include/asm/grant_table.h b/xen/arch/x86/include/asm/grant_table.h index e939c9bacb..3aae47092f 100644 --- a/xen/arch/x86/include/asm/grant_table.h +++ b/xen/arch/x86/include/asm/grant_table.h @@ -32,6 +32,19 @@ static inline int replace_grant_host_mapping(uint64_t addr, mfn_t frame, return replace_grant_pv_mapping(addr, frame, new_addr, flags); } +static inline void gnttab_unmap_batch_begin(void) +{ + if ( paging_mode_external(current->domain) ) + grant_p2m_unmap_batch_begin(); +} + +static inline int __must_check gnttab_unmap_batch_end(void) +{ + if ( paging_mode_external(current->domain) ) + return grant_p2m_unmap_batch_end(); + return 0; +} + #define gnttab_get_frame_gfn(gt, st, idx) ({ \ mfn_t mfn_ = (st) ? gnttab_status_mfn(gt, idx) \ : gnttab_shared_mfn(gt, idx); \ diff --git a/xen/arch/x86/include/asm/hvm/grant_table.h b/xen/arch/x86/include/asm/hvm/grant_table.h index 01e23f79b8..9877262f51 100644 --- a/xen/arch/x86/include/asm/hvm/grant_table.h +++ b/xen/arch/x86/include/asm/hvm/grant_table.h @@ -19,6 +19,8 @@ int create_grant_p2m_mapping(uint64_t addr, mfn_t frame, unsigned int cache_flags); int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame, uint64_t new_addr, unsigned int flags); +void grant_p2m_unmap_batch_begin(void); +int grant_p2m_unmap_batch_end(void); #else @@ -37,6 +39,9 @@ static inline int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame, return GNTST_general_error; } +static inline void grant_p2m_unmap_batch_begin(void) {} +static inline int grant_p2m_unmap_batch_end(void) { return 0; } + #endif #endif /* __X86_HVM_GRANT_TABLE_H__ */ diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm/hvm/vcpu.h index 876c230784..12b7e9b707 100644 --- a/xen/arch/x86/include/asm/hvm/vcpu.h +++ b/xen/arch/x86/include/asm/hvm/vcpu.h @@ -108,6 +108,13 @@ struct altp2mvcpu { #define vcpu_altp2m(v) ((v)->arch.hvm.avcpu) +/* Per vCPU, as the guest copies between the unmaps can sleep. */ +struct hvm_grant_unmap_batch { + bool open; + unsigned int iommu_flags; + unsigned long gfn_lo, gfn_hi; +}; + struct hvm_vcpu { /* Guest control-register and EFER values, just as the guest sees them. */ unsigned long guest_cr[5]; @@ -172,6 +179,8 @@ struct hvm_vcpu { /* Pending hw/sw interrupt (.vector = -1 means nothing pending). */ struct x86_event inject_event; + struct hvm_grant_unmap_batch grant_unmap_batch; + #ifdef CONFIG_VIRIDIAN struct viridian_vcpu *viridian; #endif diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index b15805f3f9..ade42b4cb4 100644 --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -1722,6 +1722,7 @@ gnttab_unmap_grant_ref( c = min(count, (unsigned int)GNTTAB_UNMAP_BATCH_SIZE); partial_done = 0; + gnttab_unmap_batch_begin(); for ( i = 0; i < c; i++ ) { if ( unlikely(__copy_from_guest(&op, uop, 1)) ) @@ -1734,6 +1735,9 @@ gnttab_unmap_grant_ref( } gnttab_flush_tlb(current->domain); + /* After a failed flush the pages may still be reachable: leak them. */ + if ( gnttab_unmap_batch_end() ) + partial_done = 0; for ( i = 0; i < partial_done; i++ ) unmap_common_complete(&common[i]); @@ -1749,6 +1753,8 @@ gnttab_unmap_grant_ref( fault: gnttab_flush_tlb(current->domain); + if ( gnttab_unmap_batch_end() ) + partial_done = 0; for ( i = 0; i < partial_done; i++ ) unmap_common_complete(&common[i]); -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 16:51:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 16:51:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465935.1676381 (Exim 4.92) (envelope-from ) id 1xMpol-0005wb-Tq; Fri, 30 Oct 2026 16:51:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465935.1676381; Fri, 30 Oct 2026 16:51: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 1xMpol-0005wO-P7; Fri, 30 Oct 2026 16:51:03 +0000 Received: by outflank-mailman (input) for mailman id 1465935; Fri, 30 Oct 2026 16:51:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMpok-0005vX-Ud for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:51:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMpok-00HTpX-BE for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:51:02 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4caf6-8faa-0a2a0a5109dd-0a2a4503edca-0 for ; Fri, 30 Oct 2026 17:51:02 +0100 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4caf6-fae8-0a2a45030019-d155802eb470-3 for ; Fri, 30 Oct 2026 17:51:02 +0100 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4a4dc547987so5029115e9.0 for ; Fri, 30 Oct 2026 09:51:02 -0700 (PDT) Received: from framework13.home ([2a01:e11:3:1ff0:831:b00b:e409:f875]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4abf396dfdbsm74305045e9.1.2026.10.30.09.50.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 09:51: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=edera.dev header.i="@edera.dev" 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.dev; s=google; t=1793379062; x=1793983862; 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=2QipX05wfLZ45HZZPuTyjIFgLebJ/NJsvbpQdimG0AA=; b=Xsvu5uqnrA43Uc4hYHdLdKUwKAIyuTNBhUs2htxXEMRUQWyb++Wq1MdSVT1XuZkjCu 6PQRgR3V0Y2Mo43XJV7OyWFoa8ZS7jvaCH1Bchqz6SahxcDZfdkoYGD29Bd6gLSrISYj WTJe1qzjYj3VsPpq82pJl16AUA29vizgwY8WcNPtDzs7IHp6VYGlQZQv7oX0k+ihgh/D i8G1CasrkcvCcyNWDIZuE5rLUatuCxCbdjICHDeAj7r9YbV0IhKmbx+JNyaToQ7NApvB ypi/JL0DR46DWKyEgk/WELCcMe//39x+JAIpyNHCnjnfsx0bRDer5zTp4ozRT9Qmf2oi Vzkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793379062; x=1793983862; 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=2QipX05wfLZ45HZZPuTyjIFgLebJ/NJsvbpQdimG0AA=; b=yMyZc5SzxV9ADxJRSLbu7cLPEWs7juX4YzCgbBKp7JPvnNEg3AjkU2mwHbz8gqMobA TkWptPW/sBfZQrAZJjhoTEK17s9qfIDQ5m1yLyEtPJOcOn+0U+ea3vWuD0ZowcBv6dju ygPqJ0zu+zTnfUnKGpBYyfsr8UEl1ma21gqXD+RlNDyByXMq3RPRFp2tjLwUkI/uzDNw FRiD4wpo4XA8vq/PU4N8Pbf24xNgTytv1GwEgTGQLhKl0UZNhGu4U29jzdjM6mj7zySe s7PM2FsYWwPJ/rwoWFfpI5Y23TeOcBCbBmdzdP5aUb2K0RBAGlM3VNL7ugteJd5TyEU+ wtdw== X-Gm-Message-State: AFq9FYLddJlKSy0jMknj0M6v3/ojDuKHLA5O3HDUobkSPmH+Tqv2nvem 0bYa60vVVDmC1p5kNmn3bc9Tkq3BEjvewqDxMckiV7i8xb8xSFoQyeorCuhqWEUyVB07zDpsEG7 Pi7Izq5A5Ww== X-Gm-Gg: AYBFou2wtrbM9A0Tgd7hZjZg04KInPRk4toS9Y+jyIcfvBLoY/15DMqbZWU+XRnnvjF XnQKCTjXO9Scqh1KTdz8kyNq/VVo6uTCbKeLhLX6aHUN+sj9H2ueKfRWQ0oIADdDa0XiCPLnr7u jOlQ7x2siMqNsgskuBMgxQqcYqh1uxfEGmuaO5YI3AWI4slcdvfZtmJr5UQuSElzuG1NOrl5s9m qsllNLQdYaqesAc2PkR+Y68T4gbEF3Q9UKZYhGvIM6B1oVpbZnpe0NmW8jpMuvYF37Mz0qYTMVV wIpELWB5PyolKDSkO9Jgc4PvRosvBWy+jHtcuvBGCg6AyPPe7L+TxrCRksXZ+xCJ+t9fzobM3so nMQr1wxbwaUtmA+7Un6s01EuzLRFxdbtaGgq1pjruSJmQaTq0t8wlrctoFif0ciiBgDQWo7BNoA 5yHO4RfFUJGmWlKbr+3oB3KRtQYRqSCEivsK6uLA6+EZp9J6hIKDOGwW0T4l0q10ox/V9r208rq hZxLOqgbAW0445FmsdVofGIV9Js5Mkc/B54QMNsHGMouScyUd6hZipUaoS/tzyzcWWQ5gWEHRQN bcPf/hMimIjgJ1J5qmFBSyf4HQ== X-Received: by 2002:a05:600c:6306:b0:4aa:15b1:d4fa with SMTP id 5b1f17b1804b1-4ac17b2ce91mr69321535e9.5.1793379061663; Fri, 30 Oct 2026 09:51:01 -0700 (PDT) From: Luca Di Maio To: xen-devel@lists.xenproject.org Cc: Luca Di Maio , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD Subject: [PATCH 3/3] x86/HVM: defer p2m TLB flushes across a grant unmap batch Date: Fri, 30 Oct 2026 17:50:10 +0100 Message-ID: <20261030165031.2560020-4-luca@edera.dev> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261030165031.2560020-1-luca@edera.dev> References: <20261030165031.2560020-1-luca@edera.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1793379062-6FEC24E9-59D65F3C/0/0 X-purgate-type: clean X-purgate-size: 3009 A grant unmap by a translated caller also flushes the guest TLBs: p2m_remove_page() sets need_flush of the host p2m, and put_gfn() flushes when it drops the last level of the p2m lock. Each flush sends an IPI to every other CPU in d->dirty_cpumask and waits for all of them, so a PVH dom0 with busy vCPUs pays a round of IPIs for every page it unmaps. Defer that flush to the end of the batch, still before the pages are released. Under the gfn lock of get_gfn_query() only the removal can set need_flush, as the query neither allocates nor unshares, so no other change's flush is deferred. p2m_free_ptp() still flushes before it frees a table. The final flush reaches the CPUs in d->dirty_cpumask at that time. A CPU that left the mask in between has flushed already, as __context_switch() clears it from the mask only after write_ptbase() has flushed the guest TLBs. With EPT, each change also marks every CPU for an INVEPT before its next VM entry. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Luca Di Maio --- xen/arch/x86/hvm/grant_table.c | 6 ++++++ xen/arch/x86/include/asm/hvm/vcpu.h | 1 + 2 files changed, 7 insertions(+) diff --git a/xen/arch/x86/hvm/grant_table.c b/xen/arch/x86/hvm/grant_table.c index 1d7f9b19f9..e340712dd6 100644 --- a/xen/arch/x86/hvm/grant_table.c +++ b/xen/arch/x86/hvm/grant_table.c @@ -41,6 +41,7 @@ int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame, p2m_type_t type; mfn_t old_mfn; struct domain *d = current->domain; + struct p2m_domain *p2m = p2m_get_hostp2m(d); struct hvm_grant_unmap_batch *batch = ¤t->arch.hvm.grant_unmap_batch; int rc; @@ -72,6 +73,8 @@ int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame, batch->iommu_flags |= this_cpu(iommu_skipped_flush_flags); batch->gfn_lo = min(batch->gfn_lo, gfn); batch->gfn_hi = max(batch->gfn_hi, gfn); + batch->tlb_flush |= p2m->need_flush; + p2m->need_flush = false; } if ( rc ) @@ -95,10 +98,13 @@ void grant_p2m_unmap_batch_begin(void) int grant_p2m_unmap_batch_end(void) { struct domain *d = current->domain; + struct p2m_domain *p2m = p2m_get_hostp2m(d); struct hvm_grant_unmap_batch *batch = ¤t->arch.hvm.grant_unmap_batch; unsigned int order; batch->open = false; + if ( batch->tlb_flush ) + p2m->tlb_flush(p2m); if ( !batch->iommu_flags ) return 0; diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm/hvm/vcpu.h index 12b7e9b707..9638e50e91 100644 --- a/xen/arch/x86/include/asm/hvm/vcpu.h +++ b/xen/arch/x86/include/asm/hvm/vcpu.h @@ -111,6 +111,7 @@ struct altp2mvcpu { /* Per vCPU, as the guest copies between the unmaps can sleep. */ struct hvm_grant_unmap_batch { bool open; + bool tlb_flush; unsigned int iommu_flags; unsigned long gfn_lo, gfn_hi; }; -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 16:51:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 16:51:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465932.1676352 (Exim 4.92) (envelope-from ) id 1xMpoa-0005GH-4d; Fri, 30 Oct 2026 16:50:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465932.1676352; Fri, 30 Oct 2026 16:50: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 1xMpoa-0005G9-1k; Fri, 30 Oct 2026 16:50:52 +0000 Received: by outflank-mailman (input) for mailman id 1465932; Fri, 30 Oct 2026 16:50:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMpoY-0005G3-SJ for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:50:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMpoY-00AJPO-8f for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:50:50 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4caba-2eae-0a2a0a5409dd-0a2a4501818a-46 for ; Fri, 30 Oct 2026 17:50:50 +0100 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4cae9-5984-0a2a45010019-d155dd31cc96-3 for ; Fri, 30 Oct 2026 17:50:49 +0100 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48df8fe8513so859514f8f.0 for ; Fri, 30 Oct 2026 09:50:49 -0700 (PDT) Received: from framework13.home ([2a01:e11:3:1ff0:831:b00b:e409:f875]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4abf396dfdbsm74305045e9.1.2026.10.30.09.50.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 09: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=edera.dev header.i="@edera.dev" 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.dev; s=google; t=1793379049; x=1793983849; 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=rrWmUVeXvr8yzGN2lo9pRWCfwNmsf3a3Upj9/tVt5M4=; b=VJ2onIU+MN4qaOvJXiBdGnmp8NaqJVg2leLIvwoHgPsF8IgoVS/nsxqslkjcSKk9Jn p+QaGlA5xhf9PNmrlEtITfnm2KHUQ3n1N0fJfBP77pMscNS1x1LvvvWHxZszahN/JyfX 0xxt4HemNbDVbfktJjmjh7dhxoh/dtWRbh+MMJLokzvuUTS+3u3w9eyveyXhXuVmn0cS u/Hu4jXtaktpNkGxalMtpRRXW9h7DKrWLhCZoFJXQ3t1juNyRfXpC+p+d61HFyukFu+c d2JwF4xNINlC06kLAzs5vkCgYOJWak5Krq4pIeUfmMiRauvktNHPrfBABTec99iegkF2 KpDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793379049; x=1793983849; 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=rrWmUVeXvr8yzGN2lo9pRWCfwNmsf3a3Upj9/tVt5M4=; b=C0fD4D3utOwXzqTcVhezHkX0m0yHGyZIDP6JgEcOuyIjgr91eJylb4UyfydvlwGtU+ aZVafFbleRwjrvwIWq47uNqF9juXimIZ+/Z0E/8cGZLqp2DgKl1FWbafRMFc8UQuDFpZ 7YeYCFj1yluk1Violu0iwLweecoSor2NbfNHves7bcHsG4pzfNJqTcF+itRkum7i8DQK TpAh9/Kp3VRwgLpYIQ5vWJdYFzbQWmaGszz0acUTDjXwDbIjBfsGUTWjhAqvpuRXiRys jJ6/tQPwvwiVEAsCe20rRzV1d0j5aczst92TLTPEdMesjtDYvAv+0u4zq0dcon7RcEe6 MEhw== X-Gm-Message-State: AFq9FYJcMZ3Z/D5+XegaQfqWRk4EqqjUbKEq/O5Xkb4zCJV/OlqxXzI1 hhatFrgnz29aTcAKl07sc6L9xjqsG1I9dU5hTRT4PLDXQ2FaQU20QqbCpVh5cifknt0OgDmPKMO TTQjWAF6erQ== X-Gm-Gg: AYBFou3o6CZHmbu5cxbMT8rxqZBsBo86GSf6o3vLdW+6WTKpKQ9YUcCiqZ7Plk8M+wh GTu5wizwipnv2EiabVx2wgVtQmnURdNIm6Pkg1M+W/7vpVItRMArAiOUkdR/EGv5p1v11roPgwp fKAKSfHfrGZsySPJnghxGenAzawDDP7sFD0Ckjr71crI1kPvqz/0U94hhNTWrZV7dDx+xXgAuwT xG8gWL38ZA/wSrnVETAKJGlylpalSjMA+xJe8U8b+z9WFNZSoAToPAwlaZ9oatgve4Mny17lTor aLZizB4isV5NndZfNNzPIrGONH/KOuHQMPGlNJpTqE+wsGrjg7El3mSM15Pnc7R/5TbfghIUi8M Mc0Vjp1oOznJ3dN7edEeEW1+CryZNB4FRG28TTPlc9j483l5Q9avDQOsHjVeknxQOozVXMmL2Ik Ol25kHy7efeFuQr7X/jjaHFQQQKOGnYG/9MWN58jDiiCdC2BgeJyDZXxj8OTOYCmfFQRuqf7wq8 3k7eNE3daTnQYZ5jidmQW3eCzPARXJ8QwFyopfBem5EKcKk4zs+e+ZNZGuUl4ZuQh/zKFZVV/iK SCsX88U2iCumMoGXrB9EGZhAnQ== X-Received: by 2002:a05:600c:a00a:b0:4a2:190f:cf6a with SMTP id 5b1f17b1804b1-4ac19802310mr73043895e9.35.1793379049175; Fri, 30 Oct 2026 09:50:49 -0700 (PDT) From: Luca Di Maio To: xen-devel@lists.xenproject.org Cc: Luca Di Maio , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD , Alex Zenla , Andres Rodriguez Subject: [PATCH 0/3] x86/HVM: batch the flushes of grant unmaps Date: Fri, 30 Oct 2026 17:50:07 +0100 Message-ID: <20261030165031.2560020-1-luca@edera.dev> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1793379049-BEE60757-8CE4C035/0/0 X-purgate-type: clean X-purgate-size: 3746 Hi all, GNTTABOP_unmap_grant_ref already batches the TLB flushes of a PV caller: gnttab_unmap_grant_ref() unmaps up to 32 grants, flushes the TLBs once with gnttab_flush_tlb(), and only then releases the pages. gnttab_flush_tlb() does nothing for a translated caller, whose unmaps go through the p2m, and the p2m code flushes the guest TLBs and the IOTLB for every page instead. A PVH dom0 running netback pays both flushes for every page a domU transmits. This series gives translated callers the same batching, for both flushes, before the pages are released. The IOTLB half has no PV counterpart: a PV dom0's IOMMU maps all of RAM by default, so its grant unmaps don't touch it. Patch 1 is preparatory, and patches 2 and 3 have the details. iperf3 between a PVH dom0 running netback and two PVH domUs: machine: c7i.metal-24xl, Xeon Platinum 8488C, 96 threads, VT-d with shared EPT tables dom0: 96 pinned vCPUs, 4 GiB, Debian 13, Linux 6.12 domUs: 8 vCPUs, 1 GiB, Linux 6.18, on a bridge Xen: staging at 9a6cc49b44, built with GCC 14.2 runs: 10 s, Gbit/s received, higher is better, 60 per row from 4 boots of each build, interleaved shown: mean of the runs +/- their relative standard deviation base patched %change domU to dom0 1 stream 0.64 +/-1% 3.07 +/-3% +379% 2 streams 0.81 +/-6% 3.09 +/-2% +282% 4 streams 0.84 +/-4% 2.74 +/-6% +227% 8 streams 0.83 +/-2% 2.40 +/-5% +190% 16 streams 0.81 +/-2% 2.22 +/-3% +174% domU to domU 1 stream 0.62 +/-6% 2.26 +/-3% +263% 2 streams 0.73 +/-7% 2.31 +/-10% +218% 4 streams 0.75 +/-4% 1.86 +/-11% +149% 8 streams 0.73 +/-4% 1.62 +/-10% +122% 16 streams 0.71 +/-3% 1.59 +/-6% +124% dom0 to domU 1 stream 4.19 +/-6% 4.12 +/-6% -1.7% 2 streams 4.87 +/-9% 4.71 +/-10% -3.4% 4 streams 8.73 +/-21% 8.52 +/-23% -2.5% 8 streams 12.53 +/-17% 12.57 +/-17% +0.3% 16 streams 16.85 +/-12% 16.72 +/-11% -0.7% The table comes from one of 13 sessions on this instance type, which ran 7,779 runs over 57 boots in total. A domU transmits 2.2 to 4.8 times as much, and 2.2 to 4.0 times as much per busy dom0 vCPU, where base never exceeds 0.84 Gbit/s whatever the number of streams. >From dom0 to a domU, netback fills the domU's buffers with grant copies and maps few of its packets, so the series barely runs there and the differences stay within the margin of error. Between boots of the same build, the single-stream mean varied no more than the run-to-run spread predicts. A debug build ran the same benchmark without assertion failures or IOMMU faults. Thanks, L Luca Di Maio (3): IOMMU: record the flushes skipped under iommu_dont_flush_iotlb x86/HVM: defer IOTLB flushes across a grant unmap batch x86/HVM: defer p2m TLB flushes across a grant unmap batch xen/arch/arm/include/asm/grant_table.h | 3 ++ xen/arch/x86/hvm/grant_table.c | 53 +++++++++++++++++++++- xen/arch/x86/include/asm/grant_table.h | 13 ++++++ xen/arch/x86/include/asm/hvm/grant_table.h | 5 ++ xen/arch/x86/include/asm/hvm/vcpu.h | 10 ++++ xen/arch/x86/mm/p2m-ept.c | 4 ++ xen/common/grant_table.c | 6 +++ xen/drivers/passthrough/iommu.c | 12 ++++- xen/include/xen/iommu.h | 1 + 9 files changed, 105 insertions(+), 2 deletions(-) base-commit: 41ddcfe808ec1228289ae60c30768d50a58c98fe -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 16:51:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 16:51:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465933.1676362 (Exim 4.92) (envelope-from ) id 1xMpoe-0005Sq-BW; Fri, 30 Oct 2026 16:50:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465933.1676362; Fri, 30 Oct 2026 16: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 1xMpoe-0005Sg-7d; Fri, 30 Oct 2026 16:50:56 +0000 Received: by outflank-mailman (input) for mailman id 1465933; Fri, 30 Oct 2026 16:50:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMpoc-0005ST-JW for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 16:50:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMpoc-00HTpX-07 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:50:54 +0100 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4cacd-8faa-0a2a0a5109dd-0a2a4505924e-40 for ; Fri, 30 Oct 2026 17:50:53 +0100 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4caed-4cb1-0a2a45050019-d1558030e462-3 for ; Fri, 30 Oct 2026 17:50:53 +0100 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4a35a60499eso9415745e9.0 for ; Fri, 30 Oct 2026 09:50:53 -0700 (PDT) Received: from framework13.home ([2a01:e11:3:1ff0:831:b00b:e409:f875]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4abf396dfdbsm74305045e9.1.2026.10.30.09.50.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 09:50: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=edera.dev header.i="@edera.dev" 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.dev; s=google; t=1793379053; x=1793983853; 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=jFqLfRtINfauajq5gyzLuN7HZyWOdsBoG482oigvb6w=; b=AABsy2WlqBOPm5PJsPZvdmKTfBZrSx1vxPyOFfepB8StvoPImjMRLYL2EDibPTdYuA OgRW3wersaf2LC8D4n2H/U2ZbsO9EY+8r5q+xnvFCVFEd5POuipETXYABNSHE0PeHk4y ke4TlgKvbRiYb2OZAHGoXYBD3blss178Yb3s65jlOiYZXNRNXRydUkbYyRCfYF+DUQ8a UTBK/bm3vh2IxU7HxoZdmv4h+yU8rPVcs6kJqtJocnCqZYw/UEOKxe41d8ArAvDKZTK6 KXfWpz+tAQxzKYGO6cuJ/5vjyY35reDE/f/0muMarN5p2E4xvl89jOhgXImfUxw2i9wT 51sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793379053; x=1793983853; 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=jFqLfRtINfauajq5gyzLuN7HZyWOdsBoG482oigvb6w=; b=svtIaYUsrCgq974Iv82AG4Ph11EhWZG7tlAKw1aHMgY79VKDQNr6mgwau6COHLr3MI c6kTrNvgdbakdlHTKh0z8jMfsax5LwCY9eiTji1l3w4bGywpyX8ZrXDgSsbDIj9x6YLv NAGmFklCOnqn8POvonr2X5XEGnjWPzEINRd6vHfktKUjUsx0EEiFg+DxLYFpJ6L7ofRp 3lkgKiazy5jUL20dVawg85gKskRQfWpb78csBOwJ/qUtFlYx/W4HGpYiBnW4nCgFkalG 3UbaAZn52rWz8YZ6ZDi+vjtBgWj6sUpP9VXdXdqP7xo+7wJpOL9MdGCzGOsNEjA0aJQ4 uDPQ== X-Gm-Message-State: AFq9FYIeClnslBDeb+rp+gqsMK+zFZmXk5+P0lpQ1kGzyxQXocKzpdr5 TBufoF1HytYRxg6NhlqfEM/U4NHrhE0e95yyWUGpPTMqocYTdvyW3DCQUpEagdLqu78aqrn6SFe VAq7dXmcVVQ== X-Gm-Gg: AYBFou3qrxJP5s8BeexxjiEqXNEBpUYCivcnQq5zgaDMxBv0xiLlsJAyDLjHqQRcH7a /MbgSOjlmkC5JFCNvpqeHtSn6//FYelaNTiRF+DH6g+yVfYKx3qj7mYTsJN+t1nSgC1u7wnpL6C qKSW2BsSLUiLt6/bdRX6Sbc0O6AE7yBvSyiy6dt0p6JjNa7o54tnCzEZvMAZQc5TH9euoIaA3Jr SzYev4QyGPs40ovo+0bXNG/qVzo7CgXT0kZBKF3DZ5QQsYNYDggsWmpoY0sLzyfrnM8k/A3tXth LmGZzy+q7+KTiGBtz5FmWXuH1ElCHeWeu3RblckYmnJsm/WKdfor/vSpR5NnFbB8WwbbtGCtdhv dTbmJurkoRNEcvbNWM7jAPC20h5Nkk3PWdZMXbWvG8x7n5rI17pSKrHhF8O6M2bua7+IHq+tuuf N5aiFtfvPGfhhkvFs6hv4K38joTMTyz8tRbm9eJ6SMnvby7QeFi78mjeonNy8Q1nvmWEbZB9Pk5 lGL8Mj+qRi8SszC4WkKDttwFvu7BoK8fwBa03fPHPeJ99TEaenPhys5Oqcso2c0FffcdK44JOem zkWETv51mZvdM5h27/0sXHzQepDhyYLw+op/vLROHojkmQo= X-Received: by 2002:a05:600c:1f93:b0:4a3:2f35:38b6 with SMTP id 5b1f17b1804b1-4ac180f1e69mr65939805e9.24.1793379053265; Fri, 30 Oct 2026 09:50:53 -0700 (PDT) From: Luca Di Maio To: xen-devel@lists.xenproject.org Cc: Luca Di Maio , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD Subject: [PATCH 1/3] IOMMU: record the flushes skipped under iommu_dont_flush_iotlb Date: Fri, 30 Oct 2026 17:50:08 +0100 Message-ID: <20261030165031.2560020-2-luca@edera.dev> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261030165031.2560020-1-luca@edera.dev> References: <20261030165031.2560020-1-luca@edera.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1793379053-F46A52A1-C0473241/0/0 X-purgate-type: clean X-purgate-size: 3234 While iommu_dont_flush_iotlb is set, iommu_legacy_unmap() and the shared-EPT path of ept_set_entry() skip their IOTLB flush and drop the flags it would have used. Accumulate them in the per-CPU iommu_skipped_flush_flags, so that a caller deferring the flush can issue it with the same flags. The next patch does so for grant unmaps. Use a uint8_t, as a fixed width is meant: a byte holds every flag and fits in the padding after iommu_dont_flush_iotlb, so the per-CPU data that follows doesn't move. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Luca Di Maio --- xen/arch/x86/mm/p2m-ept.c | 4 ++++ xen/drivers/passthrough/iommu.c | 12 +++++++++++- xen/include/xen/iommu.h | 1 + 3 files changed, 16 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c index 204bdb054a..1a87b25d94 100644 --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @@ -981,6 +981,10 @@ out: (iommu_flags ? IOMMU_FLUSHF_added : 0) | (vtd_pte_present ? IOMMU_FLUSHF_modified : 0)); + else if ( iommu_use_hap_pt(d) ) + this_cpu(iommu_skipped_flush_flags) |= + (iommu_flags ? IOMMU_FLUSHF_added : 0) | + (vtd_pte_present ? IOMMU_FLUSHF_modified : 0); else if ( need_iommu_pt_sync(d) ) rc = iommu_flags ? iommu_legacy_map(d, _dfn(gfn), mfn, 1ul << order, iommu_flags) : diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index 4b22ecfe65..70ee45afb9 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -64,6 +64,11 @@ bool __read_mostly iommu_hap_pt_share = true; bool __read_mostly iommu_debug; DEFINE_PER_CPU(bool, iommu_dont_flush_iotlb); +/* + * A byte holds every IOMMU_FLUSHF_*, and fits in the alignment padding the + * bool above leaves, instead of shifting the per-CPU data that follows. + */ +DEFINE_PER_CPU(uint8_t, iommu_skipped_flush_flags); static int __init cf_check parse_iommu_param(const char *s) { @@ -458,7 +463,12 @@ int iommu_legacy_unmap(struct domain *d, dfn_t dfn, unsigned long page_count) unsigned int flush_flags = 0; int rc = iommu_unmap(d, dfn, page_count, 0, &flush_flags); - if ( !this_cpu(iommu_dont_flush_iotlb) && !rc ) + if ( this_cpu(iommu_dont_flush_iotlb) ) + { + BUILD_BUG_ON(IOMMU_FLUSHF_all > UINT8_MAX); + this_cpu(iommu_skipped_flush_flags) |= flush_flags; + } + else if ( !rc ) rc = iommu_iotlb_flush(d, dfn, page_count, flush_flags); return rc; diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 37c4a1dc82..028f41bc15 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -501,6 +501,7 @@ void iommu_dev_iotlb_flush_timeout(struct domain *d, struct pci_dev *pdev); * the caller. */ DECLARE_PER_CPU(bool, iommu_dont_flush_iotlb); +DECLARE_PER_CPU(uint8_t, iommu_skipped_flush_flags); bool arch_iommu_use_permitted(const struct domain *d); -- 2.54.0 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 17:11:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 17:11:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465968.1676390 (Exim 4.92) (envelope-from ) id 1xMq8X-00023z-AG; Fri, 30 Oct 2026 17:11:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465968.1676390; Fri, 30 Oct 2026 17: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 1xMq8X-00023s-6Q; Fri, 30 Oct 2026 17:11:29 +0000 Received: by outflank-mailman (input) for mailman id 1465968; Fri, 30 Oct 2026 17:11:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMq8W-00023m-Jj for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:11:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xMq8W-00000004LGc-35Li for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:11:28 +0000 Received: from mail-lj1-f178.google.com ([209.85.208.178]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xMq8W-0000000AdeW-24gW for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:11:28 +0000 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-3a9a1ed66b9so7529701fa.2 for ; Fri, 30 Oct 2026 10:11: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" 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=ojwmC1CtCGl63LXHg46furfXlUtUxiNwRTaT+n4Vspk=; b=grf4hBMU7vt9mhaaMIREndKq6s 1Z8hsFFwugvssRIsdtnL1H6bunuJbZKm2LuPKQtZmCkpKrAMPItSMjiiLXy1osuXbSqMpZquwCc6n DLfq5hW1oISwdmFUVVsfStTNNUGxQTetthRG62z4yPEqxLE9clsdmtIwn3aD7JJerWPI=; X-Forwarded-Encrypted: i=1; AKwUvBzzA3soRtyp8CZImG1UJjA4TdjWQMkYGiMLRI9+1TqT8e7he2zZAC7JrryPmFHPLwVBoAxXE3QdJHM=@lists.xenproject.org X-Gm-Message-State: AFq9FYK1kPVJJo/Buj2PB+o3cHEQRn7xOSKryOFLNjD5Yw7XtaBBhH26 8gnlwVEERMKWYsWu5f15fZ6ICMEoTYO/NDNAZUuPhFhpVdIUAmuw6EM9pMzGhN9+N6uE/kqcVjU SgtjHUk8VsKit8nv2/dIwIRBB93U44YA= X-Received: by 2002:a05:651c:31c3:b0:3a9:7711:1cd7 with SMTP id 38308e7fff4ca-3acb7aa5547mr8899741fa.23.1793380287440; Fri, 30 Oct 2026 10:11:27 -0700 (PDT) MIME-Version: 1.0 References: <20261028-asi-hvm-v5-0-13b908e0df0b@xenproject.org> <20261028-asi-hvm-v5-2-13b908e0df0b@xenproject.org> In-Reply-To: From: George Dunlap Date: Fri, 30 Oct 2026 17:11:14 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_lib56J4m9UWxE3kg9SyoBxwNIOSzB34YuLg-Wltkoi-Dsk9S2jhoD4Zg Message-ID: Subject: Re: [PATCH v5 02/45] x86/mm: refuse to promote an L4 while the domain has no per-domain L3 To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 29, 2026 at 7:47=E2=80=AFAM Jan Beulich wro= te: > > On 29.10.2026 00:05, George Dunlap wrote: > > init_xen_l4_slots() puts the domain's per-domain L3 in slot 260 of the > > L4s it fills. Since fcf91ce9de66 ("x86/pv: don't populate the GDT/LDT > > L3 slot at domain creation") a PV domain gets that L3 with its first > > vCPU (pv_create_gdt_ldt_l1tab()). Only mapcache_domain_init() makes it > > earlier, with the domain, and release builds skip that unless memory > > hotplug is enabled or the host's memory reaches past the part of the > > directmap PV guests can see. So in release builds on most hosts, an L4 > > that is promoted before XEN_DOMCTL_max_vcpus has created the domain's > > vCPUs gets a slot 260 entry made from a NULL page (0x803e900000000063), > > pointing far beyond the host's memory. > > > > Have promote_l4_table() return -EINVAL while the domain has no > > per-domain L3, before taking any reference. The other callers of > > init_xen_l4_slots() all run once the L3 exists; have init_xen_l4_slots(= ) > > check that with a BUG_ON(). An ASSERT() would not do: the case above > > arises only in release builds. libxl is unaffected: it creates the > > vCPUs before it builds or restores a domain. > > Isn't setup_compat_l4() similarly affected? XEN_DOMCTL_set_address_size > may (in principle) be issued ahead of the domain having any vCPU-s. setup_compat_l4() is called in a for_each_vcpu loop, so can't be run if there are no vCPUs. > Independent of that, how about pulling hvm_domain_initialise()'s > create_perdomain_mapping() up into arch_domain_create() instead of the > code additions you do? So, let's see if we can solve it "properly". Constraints: - Eventually, not all domains will have a domain-wide L3; some will only have per-vCPU L3s. - init_xen_l4_slots needs a domain always, but only needs a vcpu to get the L3 of vcpu_pt domains. - PV vcpu_pt domains don't need an L3 installed after init_xen_l4_slots; they need to run on a clone of the L4 anyway. So by the end of the series, we could arrange it like this: non-vcpu_pt domains always allocate d->arch.l3_perdomain in arch_domain_create. vcpu_pt domains always allocate v->arch.l3_perdomain in arch_vcpu_create. Have __init_xen_l4_slots() take a domain and an L3; if the L3 is NULL, leave the perdomain slot empty. Have init_xen_l4_slots() take a vcpu. BUG_ON(is_hvm_vcpu(v) && v->arch.asi.vcpu_pt && !v->arch.l3_perdomain), then pass the appropriate l3 into __init_xen_l4_slots(). Have init_xen_l4_slots_pv() take a domain, and always pass the domain and d->arch.l3_perdomain to __init_xen_l4_slots. This will be NULL for PV vcpu_pt domains, but that's fine. Then promote_l4_table() calls init_xen_l4_slots_pv() with a domain, and loses both the checks at the top. There are corner cases to sort out, like how idle domains get an L3; but overall I think this makes everything more robust. Thoughts? -George From xen-devel-bounces@lists.xenproject.org Fri Oct 30 17:49:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 17:49:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1465985.1676398 (Exim 4.92) (envelope-from ) id 1xMqjB-0007pK-11; Fri, 30 Oct 2026 17:49:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1465985.1676398; Fri, 30 Oct 2026 17: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 1xMqjA-0007pD-Ua; Fri, 30 Oct 2026 17:49:20 +0000 Received: by outflank-mailman (input) for mailman id 1465985; Fri, 30 Oct 2026 17:49:19 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMqj9-0007p7-58 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 17:49:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMqj8-00EGkR-Ay for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 18:49:18 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4d888-e002-0a2a0a5209dd-0a2a4503d70c-40 for ; Fri, 30 Oct 2026 18:49:17 +0100 Received: from [205.220.168.131] (helo=mx0a-0031df01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4d89b-fae8-0a2a45030019-cddca883c294-3 for ; Fri, 30 Oct 2026 18:49:17 +0100 Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69UERF6r378152 for ; Fri, 30 Oct 2026 17:49:15 GMT Received: from mail-dy1-f198.google.com (mail-dy1-f198.google.com [74.125.82.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4hme7549c2-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 30 Oct 2026 17:49:14 +0000 (GMT) Received: by mail-dy1-f198.google.com with SMTP id 5a478bee46e88-3698bd5392cso851851eec.1 for ; Fri, 30 Oct 2026 10:49:14 -0700 (PDT) Received: from [192.168.1.199] (192-80-163-190.dyn.novuscom.net. [192.80.163.190]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-36a429467cdsm8795841eec.19.2026.10.30.10.49.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Oct 2026 10:49: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=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= 6UX8J6tayYdcMuVbYI0MgDwbUxidzIgfE/ULZAD4kYA=; b=hOaeq5yt3cEVyZFR 0tcQK3F875a+bmOxQFt3NzEAIrxoXbA6yPh5NhgW4MAf9cAj0/4TZ4yrn4KP1kcD Kp9GGGOq7DiRWMlvGrdeNt7vTD2zwg+2ndYttukoJgHotjFNQ5DTwFgFPFfGcxrQ S84ZD1SE/RRcXjnwA/ZNC3H2KbAaplCR2GEzUffSZmN4TcKb3jpsUkqQO3khlwkA BwLuhVO07EJk7pqktnw+tpYOXlTyFSkZnednle311tiKR9MXSfi7Kixi0d5uxm+Y uZOYYiE9IWpSMHVtN5WwCvRISpf0uYqtn/fWrJANW8KPSQZLDmBLOxLlmjpfLxtJ rydZKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1793382554; x=1793987354; 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=6UX8J6tayYdcMuVbYI0MgDwbUxidzIgfE/ULZAD4kYA=; b=U1W3728TC4gGEkZfuwNMNk2w4npuxJfd3Mh8SHiMcEfvefNMUqLgnJINbK3zLD1LKm HZDBYsNVbhPNwPYwbfoW3Z4HnCtqZEMCu0e1dfPtaGmrUah52Tv7raeJFvkHgZnY6K6u v5Osf1hYqeEMEszqFu/5ueGeVE8mEXyvl2hrkRYzyaQHRq9ScKhE9UMIUcCkK7YaLe3N LDpTakmSh9SjlF3PMjvHf18vJyZlf/CzePLxZxcw5aUAbazejobqjQHiHw6HjbSIEbj6 3zLMx+fUIs8aNPl2qOgWEPE4VIA3PRIM6ZStAYUXV4xpAY5UfiNy4CcJxVhAML8LDTYe E+zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793382554; x=1793987354; 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=6UX8J6tayYdcMuVbYI0MgDwbUxidzIgfE/ULZAD4kYA=; b=UOBFTM8AvM+tBNjBz7t71k7U9/nqyyuG53I7sDUFIxA8cuNpoB7E5MtnaHqq0njGP3 t1WRFDaWngaQrNXnNonXJR7GLD88eI2lkmL6p38mfnArttCDSkVD3F9qyYJk9X18gMns ol7dLCswVvA1TrHNwKghcIllTztXSls7IoZx18QG2WDyzVoy8o8Rk8geSXPfntBRbuI1 ukCVZWx92vclgvek7uHDL1LG6FjMsP15o6vOFyi+DzQsF+IXqPB23XO6UKX8frmYZzLW 4LQnJnEAU3SpP/gUMs1PFQBUJ26RIkawu+/3K/zjuc6kxCX/D4FlDuYlGlYen7JA+rHl P+Yw== X-Forwarded-Encrypted: i=1; AKwUvBxuvgusROV8Vm+ur4c80nSbJc09eudXmVDcdbYMSi6kvpe1rN5spGgy3vhjJkDUjPHYjiKlJH6tcT8=@lists.xenproject.org X-Gm-Message-State: AFq9FYJmecZ/Y4hHyuBWx0SirBbw81tTDtG4JRrXG0sjNOp11bcJIWxb ObbyK/g1MEPzBuxZjeioVJk2qeaoeAcPxRz7iAmwmULNsUKIAGnMHBVp3sPC+3hy2G22Ml6Kr3w hZXJ4+7CM02ASetS6PpJip8jS1d7FyGuvj2+5LbB30hZ5Run/ZUL0lErccyzRwQ5Q2DqeZA== X-Gm-Gg: AYBFou2/68vo/7LyFrjNxAVpj/P7AsX1hlNSjHGypfTe3QS5GykoR3ElVDZ48g3w4VD fK+O9nUPMQvMfkuCeDnGkUoPsw5tGpyNiZ81iDV9XxUf3MgtCrFSZjYgmEf/QZXZYIMMF/QKeEj INPJNszYqgsT7a+dUpZuakkI/jmdiAwnAELzOr5H3oEIglHw+Hbge+0T+aBDrkYLLP+p1ykwJAV DmuL712TenxBbI/pZJzCJ2dPZgpOWbpjrcr8gNM3s0YrZUZbrdVFPbC0lE4vlgVuLqAMz/+nELh wwZf1SLe5lcscRVt/7VrjcANprB0EfCmSgFfPVYbgxVSDfJCbq6O+QcJZrvyt2jdYqUAfT/nMm/ A8Yu5MsQI7rlnHNNw0faGcLx/PFfZpgoVQrk2j20OLpCV0IexxV3H/L1ZujSg2/ytXFIhMQJjPE nj0l9FqFcCYFsyV2nu1FwhaVp6iqmmyqxiZTA4ZeAXyBg= X-Received: by 2002:a05:7300:3d0a:b0:35e:2c6:d462 with SMTP id 5a478bee46e88-36a2fc203c3mr7976415eec.0.1793382553989; Fri, 30 Oct 2026 10:49:13 -0700 (PDT) X-Received: by 2002:a05:7300:3d0a:b0:35e:2c6:d462 with SMTP id 5a478bee46e88-36a2fc203c3mr7976358eec.0.1793382553364; Fri, 30 Oct 2026 10:49:13 -0700 (PDT) Message-ID: <9c2a2e48-e15f-43ee-9eef-0ebb607ccafc@oss.qualcomm.com> Date: Fri, 30 Oct 2026 09:49:10 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration To: Yonggang Luo , qemu-devel@nongnu.org Cc: Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , BALATON Zoltan , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?Q?Cl=C3=A9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org References: <20261030151539.1872-1-luoyonggang@gmail.com> From: Pierrick Bouvier Content-Language: en-US In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: Du3jAS7kyOA2L3oYRLO8325B1UXZ2UTr X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDMwMDA3MCBTYWx0ZWRfX+UVnao1z7aTW 2f4Ga/sKp9U1VpAqrLZg5f3xduJqC2l3WHW3QW/g+2UA+0wC+JEnj0F+TzSzhw20f5YOw5phEbw wy/VR7tbscpT5Uf8hcttFmNvMHMsZTt0jPodHcafucWu0Vu4kvUCKLwP6WbyGM98hfCBgZ2qIhV ylg//3voeX21s9UjGuhpReBmeCjRRjIEHeJpLqRzA3HSpzotYuRqBHbSi9ecdOzmBjkvzBCV7Uw tFwOWhWKZ3hD8ZYr1lFEnXE/P1299dD/XAgoiGodKfBvH+EKUDfb1BiPSFDTzaj8FwHetpxfbuf vFrjUPqv63C5o01502CR0VihEi+OmaxCQn5c46RNLLPQcaMJjDW5hPCtFQ1t1kLvbJDXzvJ8vGV 7A+Nx2L2I9pCBmF8BqsYbViPuT7+UQnLYI2dGaVm6WFm3RpMjMgL/9rnZoiE/oIhzZBfw3vtTKm MLrlzLzHQgyh5Wgs4Jg== X-Proofpoint-ORIG-GUID: Du3jAS7kyOA2L3oYRLO8325B1UXZ2UTr X-Proofpoint-Spam-Info: AW1haW4tMjYxMDMwMDA3MCBTYWx0ZWRfX3S3cIc+iPGBa sYxfzfC6w04y9AwP01GHXQw4Rl/Ze3ZuMTS8f/lh87iZFDjDcNZpjliBEHtwrRyzLMqU3ivv7qs /ou97caxGpJVPTiPXABXGSoZ28ecjSM= X-Authority-Analysis: v=2.4 cv=KdtHIgYD c=1 sm=1 tr=0 ts=6ae4d89a cx=c_pps a=wEP8DlPgTf/vqF+yE6f9lg==:117 a=9852oil1ID9t5xBSyQ/BEA==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=6Hdeo9sKUei7lKwjsM4A:9 a=QEXdDO2ut3YA:10 a=bBxd6f-gb0O0v-kibOvt:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-30_05,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 clxscore=1015 spamscore=0 phishscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 adultscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610300070 X-purgate-ID: tlsNG-33051d/1793382557-762FD4E9-B9F60BDA/0/0 X-purgate-type: clean X-purgate-size: 4106 On 10/30/2026 7:15 AM, Yonggang Luo wrote: > DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the type_init > function that calls type_register_static(). A later change needs to pass a > target mask into that registration, and the macros have no parameter for it. > This series expands every caller first, with no behavior change, so the > follow-up only replaces the type_register_static() call. > > Each machine file gains a class_init function, a TypeInfo, and a type_init > function that calls type_register_static(). The last patch removes > DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h. > > Yonggang Luo (15): > hw/alpha: expand DEFINE_MACHINE in dp264.c > hw/m68k: expand DEFINE_MACHINE for M68K machines > hw/microblaze: expand DEFINE_MACHINE for MicroBlaze > hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c > hw/arm: expand DEFINE_MACHINE for ARM machines > hw/riscv: expand DEFINE_MACHINE for RISC-V machines > hw/core/null-machine: expand DEFINE_MACHINE > hw/mips: expand DEFINE_MACHINE for MIPS machines > hw/ppc: expand DEFINE_MACHINE for PowerPC machines > hw/sh4: expand DEFINE_MACHINE in r2d.c > hw/sparc: expand DEFINE_MACHINE in leon3.c > hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c > hw/xtensa: expand DEFINE_MACHINE in sim.c > hw/xtensa: expand DEFINE_MACHINE in virt.c > hw/core/boards: remove unused DEFINE_MACHINE* macros > > hw/alpha/dp264.c | 18 +++++++++-- > hw/arm/bananapi_m2u.c | 18 +++++++++-- > hw/arm/cubieboard.c | 19 +++++++++--- > hw/arm/digic_boards.c | 18 +++++++++-- > hw/arm/imx25_pdk.c | 18 +++++++++-- > hw/arm/imx8mm-evk.c | 20 +++++++++--- > hw/arm/integratorcp.c | 14 ++++++--- > hw/arm/kzm.c | 18 +++++++++-- > hw/arm/max78000fthr.c | 17 ++++++++-- > hw/arm/mcimx6ul-evk.c | 18 +++++++++-- > hw/arm/mcimx7d-sabre.c | 20 +++++++++--- > hw/arm/msf2-som.c | 17 ++++++++-- > hw/arm/netduino2.c | 17 ++++++++-- > hw/arm/netduinoplus2.c | 17 ++++++++-- > hw/arm/olimex-stm32-h405.c | 18 +++++++++-- > hw/arm/orangepi.c | 19 +++++++++--- > hw/arm/stm32vldiscovery.c | 18 +++++++++-- > hw/core/null-machine.c | 18 +++++++++-- > hw/m68k/an5206.c | 18 +++++++++-- > hw/m68k/mcf5208.c | 18 +++++++++-- > hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++-- > hw/microblaze/xlnx-zynqmp-pmu.c | 19 ++++++++++-- > hw/mips/boston.c | 18 +++++++++-- > hw/mips/fuloong2e.c | 18 +++++++++-- > hw/mips/malta.c | 12 ++++++-- > hw/ppc/amigaone.c | 18 +++++++++-- > hw/ppc/pegasos.c | 21 ++++++++----- > hw/ppc/ppc440_bamboo.c | 18 +++++++++-- > hw/ppc/prep.c | 18 +++++++++-- > hw/ppc/sam460ex.c | 18 +++++++++-- > hw/ppc/virtex_ml507.c | 18 +++++++++-- > hw/riscv/boston-aia.c | 18 +++++++++-- > hw/riscv/microblaze-v-generic.c | 18 +++++++++-- > hw/sh4/r2d.c | 18 +++++++++-- > hw/sparc/leon3.c | 18 +++++++++-- > hw/tricore/tricore_testboard.c | 18 +++++++++-- > hw/xenpv/xen_machine_pv.c | 18 +++++++++-- > hw/xtensa/sim.c | 18 +++++++++-- > hw/xtensa/virt.c | 18 +++++++++-- > include/hw/core/boards.h | 48 ----------------------------- > 40 files changed, 605 insertions(+), 142 deletions(-) > So far, this expansion has been done only on machines that required to modify TypeInfo: mostly virt types, which are ambiguous between targets and require to introduce is_available. Maybe this can be delayed for when such machines require it also. Regards, Pierrick From xen-devel-bounces@lists.xenproject.org Fri Oct 30 18:31:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 18:31:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466007.1676408 (Exim 4.92) (envelope-from ) id 1xMrNN-0007OF-3K; Fri, 30 Oct 2026 18:30:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466007.1676408; Fri, 30 Oct 2026 18:30: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 1xMrNM-0007O6-Vj; Fri, 30 Oct 2026 18:30:52 +0000 Received: by outflank-mailman (input) for mailman id 1466007; Fri, 30 Oct 2026 18:30:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMrNL-0007Nx-J0 for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 18:30:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMrNK-002VV8-NM for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 19:30:50 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4e246-bab6-0a2a0a5309dd-0a2a4502e812-14 for ; Fri, 30 Oct 2026 19:30:50 +0100 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 6ae4e259-6ca4-0a2a45020019-aceafc1fc23c-3 for ; Fri, 30 Oct 2026 19:30:50 +0100 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 5A0CB43856; Fri, 30 Oct 2026 18:30:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 365561F000C1; Fri, 30 Oct 2026 18:30: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="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=1793385048; bh=Ymmdwc5PEMgv61WbZEAXoHrjiG+5VIZ10E632soWGCc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=bd5mnlMYQl798ipBazvCyuBvEJ+dWQPwsnUhVWLaW7b1vz5ZxxwwDFJAXipNxVYkZ 1YMHg32fNUCuoVzm2HCBW3ov7kG+JMaBOx03FaMytt2PrrA5GHA2Tvi5hKn/EfloYP 2beONBCAOHLRlOst0mi76+aNgfLm6mIii3Lr5Fvstx8lw6wGj/SrTAbdVuY0LzPwAU bCJanwYpvATD+HqFWKlmHWzxbYzpj5FiFEot/sqUcaxCu2/PrJulmkzTYLC6de+Ext aaZWpT6UFdWy/d0gaseRtXTvi4oQtl70vUfG4Wb6sIpH14qDGlI1q3EhfXbEG7UOrn +aykTDKlAEfuQ== Date: Fri, 30 Oct 2026 11:30:48 -0700 From: Kees Cook To: Nathan Chancellor Cc: Ian Rogers , Greg Kroah-Hartman , Miguel Ojeda , "Rafael J . Wysocki" , Danilo Krummrich , Nick Desaulniers , Miguel Ojeda , Christian =?iso-8859-1?Q?K=F6nig?= , Zhihao Cheng , Zhongqiu Han , Sumanth Korikkar , Bill Wendling , Justin Stitt , driver-core@lists.linux.dev, llvm@lists.linux.dev, linux-hardening@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, gfs2@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Jonathan Corbet , Shuah Khan , Randy Dunlap , Andy Whitcroft , Joe Perches Subject: Re: [PATCH v2 1/9] Compiler Attributes: Add __must_init macro Message-ID: <202610301130.FEF31E7F@keescook> References: <20261027223847.652884-1-irogers@google.com> <20261027223847.652884-2-irogers@google.com> <202610281155.4D2AA663@keescook> <20261028190233.GA669046@ax162> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261028190233.GA669046@ax162> X-purgate-ID: tlsNG-720697/1793385050-F3EBB2AC-57C470AD/0/0 X-purgate-type: clean X-purgate-size: 859 On Wed, Oct 28, 2026 at 12:02:33PM -0700, Nathan Chancellor wrote: > On Wed, Oct 28, 2026 at 11:56:08AM -0700, Kees Cook wrote: > > On Tue, Oct 27, 2026 at 03:38:36PM -0700, Ian Rogers wrote: > > > Note that Clang does not yet diagnose file-scope objects declared > > > without any initializer (initializers at file scope that omit the field > > > are diagnosed), see https://github.com/llvm/llvm-project/issues/232483. > ... > > As part of this, can you open a Clang bug for the lack of detecting > > global initializers? It'd be nice to get that fixed. > > Is that this linked issue or a different one? Looks like you filed that > one and it got fixed in clang ToT about a week ago: > > https://github.com/llvm/llvm-project/commit/58936cb3678b4b5b96177f24cac3940b9a389fe3 Oh! Hah, it moved so fast I missed it. Great! -- Kees Cook From xen-devel-bounces@lists.xenproject.org Fri Oct 30 19:45:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 19:45:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466044.1676423 (Exim 4.92) (envelope-from ) id 1xMsX2-0002t2-CW; Fri, 30 Oct 2026 19:44:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466044.1676423; Fri, 30 Oct 2026 19:44: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 1xMsX2-0002sv-7b; Fri, 30 Oct 2026 19:44:56 +0000 Received: by outflank-mailman (input) for mailman id 1466044; Fri, 30 Oct 2026 19:44:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMsX0-0002sp-LG for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 19:44:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMsWz-00ETqJ-Dd for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 20:44:53 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4f352-8faa-0a2a0a5109dd-0a2a4509e102-32 for ; Fri, 30 Oct 2026 20:44:53 +0100 Received: from [52.101.201.46] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4f3ae-be1a-0a2a45090019-3465c92e649b-3 for ; Fri, 30 Oct 2026 20:44:47 +0100 Received: from PH8P220CA0041.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:2d9::20) by BN5PR12MB9462.namprd12.prod.outlook.com (2603:10b6:408:2ac::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.10; Fri, 30 Oct 2026 19:44:36 +0000 Received: from PH3PEPF0005961B.namprd05.prod.outlook.com (2603:10b6:510:2d9:cafe::23) by PH8P220CA0041.outlook.office365.com (2603:10b6:510:2d9::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Fri, 30 Oct 2026 19:44:36 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by PH3PEPF0005961B.mail.protection.outlook.com (10.167.243.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Fri, 30 Oct 2026 19:44:35 +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.53; Fri, 30 Oct 2026 14:44:35 -0500 Received: from amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Fri, 30 Oct 2026 14:44:34 -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=ONLci2N3hUXXEfR7kS0knzuU+KSHGBrKfXjs5bCssph7we1mInj/U4pbFl0pag/EMBxYfVaicnnxfj283w9/avW4ZRzG5NoG1mJsMDYn+l4DmfzTJJEDchTURCxq+XDBbJ6ctwn/GQvxHjOr73B6h6H0ygP/pGcgSqCV6lN9+uy4efGlIg0dHEiHpMddakB1zbs6eUkSWZ/FuYREmngNPJ55ydEyiQM0WQS/rBL80y09xVU8TEXK4cOlGZ0SZl9BbD3VO0rcY2krjQyeepdxrcgZKK+GVKJ4TS2ValxwTUKPpp1/AnZQG9wGZJ23u/At2AvAsw8yLkJi0zIz4WQqrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T5FGtXxz13+SI2Duck3/v8izN8CZQ2+IGHg79WF2CM8=; b=U7OEbVhyoVXQqv13DVqsodcz4zTt+ARhb9C6yWLVlTHpIVfx//zewCfN3BG8mrRzPF6mjR71Uo2ZjVRz/OjkiWTuTkKT649KL9a7mE0exrqkuM+Us7J63b6Y9J9Ptb86R+F5dVpFiLFk4gEevwlw0xUoSMrFKgFHdhiOJQRKOf/8t6UoNYJNP8x2h8l8SOpOlFTKsVkeZBDs/DHPnGRf06AubTSPpFcnmWcfBxUrOBCxAOJU9ZqXoS7OVTdBLQ6XzHdV2JJrDf13d0uQwCHYAvYjndeTqYOAPFsHHpTcYaceG/mVyQPIHt9JHOkxJ1J2/uUKsCZNe/dz/00NchtjRg== 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=T5FGtXxz13+SI2Duck3/v8izN8CZQ2+IGHg79WF2CM8=; b=zAkT7MCs3PCbD9781pwzVJ+WZtm4fo+l4zwWBLkC3CEYFE7vs9B3lqasfQV/za+aGlhJhot9gFntV4TO/gxg7f5MPUnWVI8Y8YTNxR17VqkjGuHxPHIEZBylbE4gWZbxIKCEewNq+TYBmSuYdSVBEErxWLsivz6thFOz851Np4g= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , Roger Pau Monne Subject: [PATCH] xen/gunzip: free the code-length table on an overlong length run Date: Fri, 30 Oct 2026 12:44:28 -0700 Message-ID: <20261030194428.1320905-1-stefano.stabellini@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: PH3PEPF0005961B:EE_|BN5PR12MB9462:EE_ X-MS-Office365-Filtering-Correlation-Id: 9ebf8132-2e04-42c7-3293-08df36be3a3a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|23010399003|1800799024|82310400026|18002099003|11063799006|5023799004|56012099006|261009223027099003|261026140227099003|261022115727099003|261022105027099003|261022075727099003|261021121427099003|261028144727099003|261026121527099003|10067099003|6133799003; X-Microsoft-Antispam-Message-Info: ylvpEaqNMTC1gTYlFUdULvMvJlbVn0tN86LSazqpSGrtbPDDYHAq0O7AW8FgybYMHIIvlu4NZ5VlunYSgMdxa2y2QqLA9g61eZ1UnGS9xk9cwQTwzTh4kER0q8yua1DYMgob/f9gI619d5akHTw33zagMyZIbBml4A0mF1tPpgkoxC6lbtf32KHYSEo4JzwnSg11/FvNAo1nxHtkN9lPVQlcvw2VyDq/uSAgc1U348rRMh0bqdEn4e/48hZBB5Xpues7Jsso1YDiFCsqLAaNd+8xmXzbHsnnT12bGHW7QsPINoF3D6L98Yiu8jrrF10hprCf9dUnglP090bQbgj7weImMcOaK3PrmCu9qF5U4b2dmDAFD56Z1SYZ3PFTov5IA/R/R/jI8mH4CraR4ltG7i7kPZKCWIGzVh1ws2sqKHqouw0ZjFlIZiGq7CH1a5SSnomLRc8Lo7bxfZwWjnnTMcXyva4eJrj3TXMpOE6lc+uViocabHr225w8ic9tAGdwbsBz/TrrPecqZrncaebYURg/lc5CM8pNVYmyXoKrcII55rXySRUCvJklp7OaTNM8xMQMv+UEacEUiAX4MyR6RwQcfYMS4M03pADqN4an1rVjJD+J7rz17BH2y0L3S635gfQKbU5LoqQrDAMu3qY4gW3OpONveLBZ1mOIilLy1Zow94rwYXd/S9uQIzlmjJ5p5sCkpQcRCp4VZZmJt3Fvmw== 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)(23010399003)(1800799024)(82310400026)(18002099003)(11063799006)(5023799004)(56012099006)(261009223027099003)(261026140227099003)(261022115727099003)(261022105027099003)(261022075727099003)(261021121427099003)(261028144727099003)(261026121527099003)(10067099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: P3sIE1OhI0P8Ltt9DPrhmN9dItseZsC8XYdBWQMm5onVzg4NV6ET8GL45DM6lY0stvw8dV3sYvWwhP/3fJ1kJhm/ylobNIXQ9+xrmOHr8RXmKGIbg73yMkOLMJCAQPkdNhXT/R2GRSYZ2FiPB5KXE3tj6HMjDWM8nDU5IhaHNEJ0p4W6VPJikMsN9+CqF8GvhdczvSoKFhZXD/eq3JNx+rhsGy5n4tyhEYcvSgyH7V1QwnpFWoB4VZ/cuowaWNfpTz0zMd1U6xksaycgeeLmgpZYPZwXbmBFlFX4i4Yj7YDlhHGo0OrmRpZuT71RFTtrJ4QxqD3n2+aw3qvV6bM3X8Ccnusu/j6jnU20Lx+VVBNMSc0fLC3xVlzbT/WquE5gpSvk1yAVd+LvFIoErs06F7ZjnK1Msy8fL/UsCUCJnCwBELxuFdTGGrXeSBcwASGn X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2026 19:44:35.7353 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9ebf8132-2e04-42c7-3293-08df36be3a3a 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: PH3PEPF0005961B.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR12MB9462 X-purgate-ID: tlsNG-bad1c0/1793389493-BFED6034-B6D8F0C1/10/78276251493 X-purgate-type: spam X-purgate-size: 2157 inflate_dynamic() builds a decoding table from the code-length code lengths of a dynamic block and reads the literal/length and distance code lengths through it. A run of repeated or zero lengths that would go past the number of codes the block declares makes it refuse the block with 1, but that path only frees the list of code lengths: the table is left allocated, and nothing else frees it. Free the table before returning on each of the three kinds of run. The other exits of inflate_dynamic() already free what they built, or are taken only after error() has stopped Xen. Fixes: e2b1ebf4de50 ("x86: Support booting a bzImage format domain 0 kernel.") Signed-off-by: Stefano Stabellini Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: Roger Pau Monne --- xen/common/gzip/inflate.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c index cb146555c8..69bed78a38 100644 --- a/xen/common/gzip/inflate.c +++ b/xen/common/gzip/inflate.c @@ -858,6 +858,7 @@ static int noinline __init inflate_dynamic(struct gunzip_state *s) j = 3 + ((unsigned)b & 3); DUMPBITS(2); if ((unsigned)i + j > n) { + huft_free(tl); ret = 1; goto out; } @@ -870,6 +871,7 @@ static int noinline __init inflate_dynamic(struct gunzip_state *s) j = 3 + ((unsigned)b & 7); DUMPBITS(3); if ((unsigned)i + j > n) { + huft_free(tl); ret = 1; goto out; } @@ -883,6 +885,7 @@ static int noinline __init inflate_dynamic(struct gunzip_state *s) j = 11 + ((unsigned)b & 0x7f); DUMPBITS(7); if ((unsigned)i + j > n) { + huft_free(tl); ret = 1; goto out; } -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 20:16:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 20:16:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466066.1676430 (Exim 4.92) (envelope-from ) id 1xMt1F-0008Ak-Gi; Fri, 30 Oct 2026 20:16:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466066.1676430; Fri, 30 Oct 2026 20:16: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 1xMt1F-0008Ad-E2; Fri, 30 Oct 2026 20:16:09 +0000 Received: by outflank-mailman (input) for mailman id 1466066; Fri, 30 Oct 2026 20:16:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xMt1E-0008AX-VN for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 20:16:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMt1E-00FMLA-CE for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 21:16:08 +0100 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae4facb-8faa-0a2a0a5109dd-0a2a4503e194-46 for ; Fri, 30 Oct 2026 21:16:07 +0100 Received: from [40.107.201.60] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4fb06-fae8-0a2a45030019-286bc93c7caf-3 for ; Fri, 30 Oct 2026 21:16:07 +0100 Received: from SJ0PR13CA0024.namprd13.prod.outlook.com (2603:10b6:a03:2c0::29) by CHXPR12MB999220.namprd12.prod.outlook.com (2603:10b6:610:2fd::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.10; Fri, 30 Oct 2026 20:16:02 +0000 Received: from SJ1PEPF000037B5.namprd05.prod.outlook.com (2603:10b6:a03:2c0:cafe::56) by SJ0PR13CA0024.outlook.office365.com (2603:10b6:a03:2c0::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Fri, 30 Oct 2026 20:16:00 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ1PEPF000037B5.mail.protection.outlook.com (10.167.244.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Fri, 30 Oct 2026 20:16:00 +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.53; Fri, 30 Oct 2026 15:15:59 -0500 Received: from amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Fri, 30 Oct 2026 15:15: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=vdzkZq+FrAJLiQ2NM9HBADuXDnxDqQiaDawjj2J0B3f2aHQBImEqjoza8nuTsr2l2QqzRjqlZS/AbpxGOumnjyZI5ktIhWp/AtShm5u3AAaS4QvsvKDzhHZLJyL5SVksFB20I4mK2YzAynVwZy+l385rsicMz4ml0W7itLSHVUvrS1OBCqo3oZkmhO1xB/zjLvNICjl9b0neBtROSETwQYGcyuEp7+S7ZFND0I2FN+FCjh/UxnSkWwaXNmQi+8BqarzyU8m+achf1gAJ/SWqv3w3qcm4AvVksbq7Fr6PSsiye8Boy8jEUl81YnpJT+4zehe9HoPsuBPX8dZH7CeM7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A1Hz381z67ll8PavJLQmYEch9DB4Vv2FFyJamyBbfgI=; b=SyhgAn0c9K5kVc0UERzHRbLb9p/uJCPTU4yFjrL96gj8Fr0Ca8nVQ7CPYUWpLIvFwTEMNS5CZWLHDBVrYeSJehSmAyOA6UE/IJtJJdkam89hDxfXOGdHJCtn3WwGrBYSAxumcRgVJzI5L7GSET+Estg5EKe+898wfMwgFJcSr6cGiWnj42TJ7Z3kjmSmDZhDmmwUy8VVVdoGWY0+HoU+l1dwM9aSuqPIxMAx+tiFsRKBMgFvH//KdT0Fgx1SXnJ0qj1ahu6qZHIbSu9bk5qVs3Gnnr7M4pwb5sOu0GclM/ii2QZ9TYvheR5LGRjnfeVCWZEI1OmLICSLRwj481/CLQ== 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=A1Hz381z67ll8PavJLQmYEch9DB4Vv2FFyJamyBbfgI=; b=gvgpE06f7Kj+v285gdg55J8c1ix0yUHnSzXiCpGzBOnzfRB+ClqZh0fsP47oqXaq6VMjPGNTCuEJ5QLz+wiqPqPYJTh1j0dDvkLhMjJQ/YIHB07PcJzXI4g++DDS8wQO2n77I4U2du62QnXRPWixbYyq7+fPyzuvGdEzhXslGuQ= 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 From: Stefano Stabellini To: CC: Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] xen/gunzip: refuse a back-reference before the start of the output Date: Fri, 30 Oct 2026 13:15:54 -0700 Message-ID: <20261030201554.1363058-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000037B5:EE_|CHXPR12MB999220:EE_ X-MS-Office365-Filtering-Correlation-Id: ccdd4697-08a3-4c2a-84b1-08df36c29d79 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|82310400026|376014|1800799024|261028144727099003|261021121427099003|261021123027099003|261022115727099003|261022105027099003|261022075727099003|261009223027099003|261026121527099003|261026140227099003|10067099003|11063799006|3023799007|6133799003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: CHwhhUCNrU9jizaDej8CGBAvhxQWGNPif0YGRgGF1/XH5v4nCxrhsgE8vGrUQR0VyzYMICASyD7ZJnGJNFDP9pH3ecHKwBgGHu6bhnikcCoz4ZAGNmYZMg9SEqk5mPTRYPtlrJnad/BiMw0eXxPrevd73J69OPdsAddazn6i1JfH+0LrsPbeL0qeSJh+bhl2wo8AI89tDgLBVJLDUxGps0Gn1br7qyPqdTP+b2YKkJP7bY+vXI1qxH8uvjVhdgesD1GtCya0RZvMKMd6IqevlwSi3t7umEPGoeJexmeXOtmjmCH5qfNUhdynLvIE+GMpS3rjTLB+D84oitC1Gx1GF1NksaRdfOd0i1YO4iTzfFrbxBtokVIMlwxwERvsFxCf4fwUZVpy+CQNJsusEhL5lndbFPXtr5nw8PXzQ57pnjh/biiI+a5IcgAw3gBEBpu2bcb4pyH9eI1V/1K4XuY4r6Ml5rE+17uALceG3Ox8xh49H32Pc0lWktQeLnRkv5naIe5Cb2IiacgTZCY7GE2PpJVdyrirl4LBccvRP2NcnlDu8sOZQEFZgvgU8WmQdVaQbKJ77PVDY1wrs7O/4FL/IjGPjUQHzQB/+j8CCG1XVRsGXkV9qm6HxAUkilDN6Mrl3NrN6YtxIAHPLNcX4pYW7iJUPoyEY19FX3k+1jl5cokJOfUVUixwDc+jJpPZTbBHsNCW5tu/Hk6C6idjN9WXOw== 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)(82310400026)(376014)(1800799024)(261028144727099003)(261021121427099003)(261021123027099003)(261022115727099003)(261022105027099003)(261022075727099003)(261009223027099003)(261026121527099003)(261026140227099003)(10067099003)(11063799006)(3023799007)(6133799003)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: CvjPrJzDBnyGBgAOXASQxFPwtzZj/LiwJMtJX5v606zNp/r299IFY9ii9IGoBlptQtNZ6qyZ1/GhT3f/txxKnAD1pYmr4vej5cYpXvDrxu3zlEV1AtNY2kJIWD8rai34g29MNNvSvyzjhxNUkmWPAyHEVhR3uYrnhWvfajjaIrCYbq3zs1cRWATFofLzqUbVzSeT3DyRtoCWobJ4H8Xzohi3boY1YDbfmWWX5iWbzRZIGtXlYSAO4Wdm/PBWgotziiQzWCpscO3nB2qWv+mNmdcDWP/Jgtv+thXgCrHxtTejEhE4O7cjpfvVmbcCKEZ13EZp7aY+j1X+YnFS3JD2RhqKXNiLPh+VigmA0xnRiuhFdwq3K6X7FvBtJFJBmeQeVqmX2t/7I2iN8vg6tRM/KJA11BDenT0GEPBqirXidDVYlTpzFLwTiHs9FYwHkZ4X X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2026 20:16:00.2108 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ccdd4697-08a3-4c2a-84b1-08df36c29d79 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: SJ1PEPF000037B5.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CHXPR12MB999220 X-purgate-ID: tlsNG-33051d/1793391367-6D4D74E9-78C2B243/10/78276251493 X-purgate-type: spam X-purgate-size: 2318 inflate_codes() copies each length/distance pair from that many bytes behind the write position, and does not check the distance against the bytes written so far. RFC 1951 (section 3.2.3) forbids a distance reaching back before the start of the output, but a corrupt or crafted image can carry one. The source position is then taken modulo WSIZE, and because Xen's window is the output buffer itself, sized for the image and not 2 GiB long, the copy reads from up to 32 KiB below offset 2 GiB of that buffer: memory the decompressor was never given, whose contents end up in the unpacked kernel. The CRC32 and length checks of the trailer only reject the image afterwards, once that memory has been read. Check the distance as soon as it is decoded, against the bytes written so far, the current window position plus what earlier flushes of the window wrote out, and refuse the block as invalid, as for an undefined code, when it reaches back further. Xen then stops with "invalid compressed format (err=1)", as for any other invalid block, without reading memory outside the output. Fixes: e2b1ebf4de50 ("x86: Support booting a bzImage format domain 0 kernel.") Signed-off-by: Stefano Stabellini Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: Roger Pau Monné --- xen/common/gzip/inflate.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c index cb146555c8..a40e83b250 100644 --- a/xen/common/gzip/inflate.c +++ b/xen/common/gzip/inflate.c @@ -603,8 +603,13 @@ static int __init inflate_codes( } while ((e = (t = t->v.t + ((unsigned)b & mask_bits[e]))->e) > 16); DUMPBITS(t->b); NEEDBITS(s, e); - d = w - t->v.n - ((unsigned)b & mask_bits[e]); + d = t->v.n + ((unsigned)b & mask_bits[e]); DUMPBITS(e); + + if (d > w + s->bytes_out) + return 1; + + d = w - d; Tracevv((stderr,"\\[%d,%d]", w-d, n)); /* do the copy */ -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Fri Oct 30 21:59:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Oct 2026 21:59:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466414.1676439 (Exim 4.92) (envelope-from ) id 1xMucw-0006r9-Ew; Fri, 30 Oct 2026 21:59:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466414.1676439; Fri, 30 Oct 2026 21: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 1xMucw-0006r2-C9; Fri, 30 Oct 2026 21:59:10 +0000 Received: by outflank-mailman (input) for mailman id 1466414; Fri, 30 Oct 2026 21:59:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMucv-0006qw-1J for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 21:59:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMuct-0014bi-WD for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 22:59:08 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae5132a-8faa-0a2a0a5109dd-0a2a450a8ae8-2 for ; Fri, 30 Oct 2026 22:59:07 +0100 Received: from [209.85.214.174] (helo=mail-pl1-f174.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae5132a-f2d2-0a2a450a0019-d155d6aed900-3 for ; Fri, 30 Oct 2026 22:59:07 +0100 Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2e9d1114320so9701255ad.3 for ; Fri, 30 Oct 2026 14:59:07 -0700 (PDT) Received: from google.com ([118.150.148.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3ae8454327esm5361880a91.4.2026.10.30.14.58.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2026 14:59: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=20260707 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=20260707; t=1793397546; x=1794002346; 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=qgi7PD6acUYIL+i15Ys7CNpZIZoU86hFOzd/i7bJ3bw=; b=o78V3uydBVdEeINeaVr54vdhigm8qsTVfPUtBJ6L3/CnuKLkEhvrOEK3ru8jeZ3A01 Z0QP5YOXJEpsdCHgRcwHwNM8Ngfp0ieSqQq2E85YMrlI/1rc6sz1BAlHE5c78FiONpCs yxdoh33oZKliXQoaeBfuXka7CNgc+WMApHFyR2A1ulFpL3zIaamIA1QD7XZyvJ/mINNl 3I9os607E/sy6aOLAio5DQYUvtKaRV8IAIX1X6XUvfhgBeeGHq+O8TpLxHy7tDz9O+Uq Kz8DqWajehZ0f3DOejFRbHX8H6Ry+h3i2E0zS1VBDM8bvxItaVCBAlMLQfLZG6rO/H52 4QNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793397546; x=1794002346; 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=qgi7PD6acUYIL+i15Ys7CNpZIZoU86hFOzd/i7bJ3bw=; b=L6Vmp4htMlrtg56NxlUyj2EeivbXoQKhBbfMx1LMaUOywnL8g4Fm4Ai4F0WmnMBpK4 6QHkqcWaxvVCtHHcGHV+O1S3DWlNB7qK/E10H5b4L/YOhtbr1WpYy8WipGVBwtgUqNUD JNc/sHJ4zwjVrkINdacRa3DQZBX/F04YbK+6uX32nTEQZEYZlcxfBKEF9iJ384gkw8zG L7GycLY9PCPMR0GCkBPDRRZrIlj2LMJPhFS6YwrCjFqLwGcLjGPGP6foN5eU16FkOaPw +CGvNCnGzRWndtHywg0VAAM4GPjo1gQAuESag30KwhCd8r/eEqN0NnS942LitSPT+VS7 dZ1g== X-Gm-Message-State: AFq9FYJ4oDRtbEqCzgO+06rGpVrRkCU5r1gMRPsPA+csRbafnGRulKTD RgmUYbtIJuqt0++mBjkUTUROOiq4dO1BxiHGb9U6zKHuhldt52AOeuy/ X-Gm-Gg: AYBFou2S0s/wwgXE9Oe/Scs1rqOAliq+mYLBvFKDspe1Uo2aG5dLUPTTqKqd6LlMx9z SQQr2t5DxVuSMAkXYfSCl0wnHHjynzCqDrxxxxu14uGFa7mWUJ90RzjmqO4jfd1Fm1JdG/H4nBW a2jkRkk5rBrLZajLGl+u42tv7gTzp68+g8jXTR6wibvyGKUYm3yYOBwra5/XcdNrMpW4w7Q664g pcMv/zIyNZhFnA/A+SWFO3Xr4cHdYNGtSojWJieI91p0+FgbayG1gRwQRDdrgJK2cgh5DZ3VKrD E80bckW9xe212kG6D+6V+vdTqCJW9Sh+9jt2WD5ruVpSRHyIaIlmELkVvwbegpYcgbl8TvRlF1u fmcumYL+Sgt+9+Nviin6334B6Gp4USwgshGppxU0dVs38do7fKxlG/rJgfNR+NGzMGTkfSgPqEG QQyZfpNQhMbo0w3KTJFta88Ynf2XvMK7dVngwh0D71wLMYk9pVkHWLAYcYS4yek3pnhPOGmDzoe IkTmqTTu9jw1vobRI1hlQ0box344pE0hMJL2PGopYDdwlwJGvclvO6jW/ro7AmbrvSP8TfbM4eF VDyuLR3EuGvlnfLuJpC//MBGboHxWw== X-Received: by 2002:a17:90a:b890:b0:3ab:e588:c29b with SMTP id 98e67ed59e1d1-3ae8e5bdcc9mr1750429a91.5.1793397545841; Fri, 30 Oct 2026 14:59:05 -0700 (PDT) Date: Sat, 31 Oct 2026 05:58:23 +0800 From: Kuan-Wei Chiu To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, marscheng@google.com, jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com Subject: Re: [PATCH] xen/dt: Skip non-RAM reserved-memory regions in make_memory_node() Message-ID: References: <20261028211737.17629-1-visitorckw@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-4011c0/1793397547-4ABD8CFC-31D6C958/0/0 X-purgate-type: clean X-purgate-size: 1985 Hi Michal, On Fri, Oct 30, 2026 at 12:04:58PM +0100, Orzel, Michal wrote: > > > On 28-Oct-26 22:17, Kuan-Wei Chiu wrote: > > Xen creates a second /memory node for Dom0 from > > bootinfo_get_reserved_mem() without checking whether those regions > > belong to host RAM. However, /reserved-memory can also describe > > on-chip SRAM or firmware regions outside system RAM. Listing them in a > > /memory node causes Dom0 to register non-RAM addresses as system RAM, > > conflicting with device MMIO mappings. > Hmm, I always thought that /reserved-memory is to exclude regions from memory > described under /memory. That's what Xen assumes too. map_range_to_domain() for > example does not call iomem_permit_access() for such regions because we assume > it's RAM. Can you provide more details of your board e.g. the device tree? Is > there any documentation I could use to confirm that "reserved-memory can also > describe on-chip SRAM or firmware regions outside system RAM"? > Hmm, your reply initially made me wonder if this was caused by a non-compliant downstream device tree on our side, so I checked the DT spec and upstream Linux. The devicetree spec does not seem to explicitly mention whether /reserved-memory regions must fall within the range described by /memory. From a quick look at early_init_dt_reserve_memory() in Linux, the comment there also mentions not worrying if a no-map region is not memory as it will not be mapped. In upstream Linux device trees, there are cases like arch/mips/boot/dts/mobileye/eyeq5.dtsi and eyeq5-epm5.dts, where /memory starts at 0x40000000 and 0x802000000, while /reserved-memory defines an on-chip sram region nvram@461fe00 with "nvmem-rmem" outside /memory. Our board's device tree is not upstream yet, but it follows a similar pattern where /reserved-memory defines "nvmem-rmem" and dma pool sub-regions inside on-chip sram outside the dram range described by /memory. Regards, Kuan-Wei From xen-devel-bounces@lists.xenproject.org Sat Oct 31 00:10:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 00:10:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466472.1676448 (Exim 4.92) (envelope-from ) id 1xMwfY-00006U-9X; Sat, 31 Oct 2026 00:10:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466472.1676448; Sat, 31 Oct 2026 00:10: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 1xMwfY-00006N-6i; Sat, 31 Oct 2026 00:10:00 +0000 Received: by outflank-mailman (input) for mailman id 1466472; Sat, 31 Oct 2026 00:09:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMwfX-00006H-Jm for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 00:09:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMwfX-000cCU-0t for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 01:09:59 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae531bc-2eae-0a2a0a5409dd-0a2a450bd1c2-12 for ; Sat, 31 Oct 2026 01:09:58 +0100 Received: from [152.66.115.2] (helo=zero.eik.bme.hu) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae531d6-b7e8-0a2a450b0019-984273024bcb-3 for ; Sat, 31 Oct 2026 01:09:58 +0100 Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id EA36A60C0DB; Sat, 31 Oct 2026 01:09:57 +0100 (CET) Received: from zero.eik.bme.hu ([127.0.0.1]) by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP id 9e_z2L1I9kjY; Sat, 31 Oct 2026 01:09:55 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id D12A760C072; Sat, 31 Oct 2026 01:09:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id CA50A13996F; Sat, 31 Oct 2026 01:09:55 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: amavis at eik.bme.hu Date: Sat, 31 Oct 2026 01:09:55 +0100 (CET) From: BALATON Zoltan To: Yonggang Luo cc: qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?ISO-8859-15?Q?Herv=E9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= , Thomas Huth , =?ISO-8859-15?Q?Cl=E9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Pierrick Bouvier , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration In-Reply-To: <20261030151539.1872-1-luoyonggang@gmail.com> Message-ID: References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-purgate-ID: tlsNG-42698a/1793405398-AACDF9EA-344DDBC4/0/0 X-purgate-type: clean X-purgate-size: 3965 On Fri, 30 Oct 2026, Yonggang Luo wrote: > DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the type_init > function that calls type_register_static(). A later change needs to pass a That's the point of the macro to hide the boiler plate code. > target mask into that registration, and the macros have no parameter for it. Couldn't you just change the macros to take that parameter instead of expanding it everywhere? Regards, BALATON Zoltan > This series expands every caller first, with no behavior change, so the > follow-up only replaces the type_register_static() call. > > Each machine file gains a class_init function, a TypeInfo, and a type_init > function that calls type_register_static(). The last patch removes > DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h. > > Yonggang Luo (15): > hw/alpha: expand DEFINE_MACHINE in dp264.c > hw/m68k: expand DEFINE_MACHINE for M68K machines > hw/microblaze: expand DEFINE_MACHINE for MicroBlaze > hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c > hw/arm: expand DEFINE_MACHINE for ARM machines > hw/riscv: expand DEFINE_MACHINE for RISC-V machines > hw/core/null-machine: expand DEFINE_MACHINE > hw/mips: expand DEFINE_MACHINE for MIPS machines > hw/ppc: expand DEFINE_MACHINE for PowerPC machines > hw/sh4: expand DEFINE_MACHINE in r2d.c > hw/sparc: expand DEFINE_MACHINE in leon3.c > hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c > hw/xtensa: expand DEFINE_MACHINE in sim.c > hw/xtensa: expand DEFINE_MACHINE in virt.c > hw/core/boards: remove unused DEFINE_MACHINE* macros > > hw/alpha/dp264.c | 18 +++++++++-- > hw/arm/bananapi_m2u.c | 18 +++++++++-- > hw/arm/cubieboard.c | 19 +++++++++--- > hw/arm/digic_boards.c | 18 +++++++++-- > hw/arm/imx25_pdk.c | 18 +++++++++-- > hw/arm/imx8mm-evk.c | 20 +++++++++--- > hw/arm/integratorcp.c | 14 ++++++--- > hw/arm/kzm.c | 18 +++++++++-- > hw/arm/max78000fthr.c | 17 ++++++++-- > hw/arm/mcimx6ul-evk.c | 18 +++++++++-- > hw/arm/mcimx7d-sabre.c | 20 +++++++++--- > hw/arm/msf2-som.c | 17 ++++++++-- > hw/arm/netduino2.c | 17 ++++++++-- > hw/arm/netduinoplus2.c | 17 ++++++++-- > hw/arm/olimex-stm32-h405.c | 18 +++++++++-- > hw/arm/orangepi.c | 19 +++++++++--- > hw/arm/stm32vldiscovery.c | 18 +++++++++-- > hw/core/null-machine.c | 18 +++++++++-- > hw/m68k/an5206.c | 18 +++++++++-- > hw/m68k/mcf5208.c | 18 +++++++++-- > hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++-- > hw/microblaze/xlnx-zynqmp-pmu.c | 19 ++++++++++-- > hw/mips/boston.c | 18 +++++++++-- > hw/mips/fuloong2e.c | 18 +++++++++-- > hw/mips/malta.c | 12 ++++++-- > hw/ppc/amigaone.c | 18 +++++++++-- > hw/ppc/pegasos.c | 21 ++++++++----- > hw/ppc/ppc440_bamboo.c | 18 +++++++++-- > hw/ppc/prep.c | 18 +++++++++-- > hw/ppc/sam460ex.c | 18 +++++++++-- > hw/ppc/virtex_ml507.c | 18 +++++++++-- > hw/riscv/boston-aia.c | 18 +++++++++-- > hw/riscv/microblaze-v-generic.c | 18 +++++++++-- > hw/sh4/r2d.c | 18 +++++++++-- > hw/sparc/leon3.c | 18 +++++++++-- > hw/tricore/tricore_testboard.c | 18 +++++++++-- > hw/xenpv/xen_machine_pv.c | 18 +++++++++-- > hw/xtensa/sim.c | 18 +++++++++-- > hw/xtensa/virt.c | 18 +++++++++-- > include/hw/core/boards.h | 48 ----------------------------- > 40 files changed, 605 insertions(+), 142 deletions(-) > > From xen-devel-bounces@lists.xenproject.org Sat Oct 31 00:33:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 00:33:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466498.1676458 (Exim 4.92) (envelope-from ) id 1xMx2D-0004GJ-1s; Sat, 31 Oct 2026 00:33:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466498.1676458; Sat, 31 Oct 2026 00:33: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 1xMx2C-0004GC-VZ; Sat, 31 Oct 2026 00:33:24 +0000 Received: by outflank-mailman (input) for mailman id 1466498; Sat, 31 Oct 2026 00:33:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMx2B-0004G6-Uo for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 00:33:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMx2B-00AKj3-4q for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 01:33:23 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae536ea-e002-0a2a0a5209dd-0a2a4504a180-38 for ; Sat, 31 Oct 2026 01:33:22 +0100 Received: from [52.101.56.58] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae53751-b57f-0a2a45040019-3465383a2830-3 for ; Sat, 31 Oct 2026 01:33:22 +0100 Received: from MW4PR03CA0120.namprd03.prod.outlook.com (2603:10b6:303:b7::35) by SN7PR12MB8002.namprd12.prod.outlook.com (2603:10b6:806:34b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.10; Sat, 31 Oct 2026 00:33:13 +0000 Received: from MWH0EPF000D894F.namprd05.prod.outlook.com (2603:10b6:303:b7:cafe::63) by MW4PR03CA0120.outlook.office365.com (2603:10b6:303:b7::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.9 via Frontend Transport; Sat, 31 Oct 2026 00:33:12 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MWH0EPF000D894F.mail.protection.outlook.com (10.167.249.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Sat, 31 Oct 2026 00:33:12 +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.53; Fri, 30 Oct 2026 19:33:12 -0500 Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.53 via Frontend Transport; Fri, 30 Oct 2026 19:33: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=KhMzKwZMKQly6GmYIumdhB25xDVO/pGr8mMMMlkSforA129BbfG7MNhK7VYLsdD/KA9o0YXzMkizR+0revsXhus6vXl7LFPtFB/nqzg4cA64aByFkE1kqzOpN2f4lQNvKnVvE4NIVnyaYv4NV+PPvfN6RjgX4dYwW/bEApdKrelj1F2GnS311cQwflmTtyzc/lwxc49gK6dkq+dKQWeYnlaQtQBg5u/AOX+73m3thVmlnZVVVp7AeJGqnnylCj2gB1fWeB7wLzN1Q3HrW9KVvmhXzljeDLna3azooS8x84FPxUI37qiDJoVYYJt+Won07WiInf57arb+cEK2jvAlmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yih6QHYE4DaDHg0Vf0uZHGGyozrwe6Oms167g1kGBBM=; b=U/nf+ZoxSo0YhkhPIuwDOD5oBqSoMluEdhI4cQy0yihGOwGCk7vQPr3Oh2NpVYPklbmAuS3yjqSfcNRQzfhFT0SoNwY9hCQCE2xyi/s7LyKehBzyzqDVAco73HTXilMhe62TMwOlpTvPETcgQ42cwdnsrrqEUWNBVuehuVj6xHIfgrIzBFjpGfSLTZrVUl18DEHUQZ9LyUpUe7QLVCTWz+l+KjGrREeS3TTeWF9Da04rvsyFV+Yy03+1c1MUKHMCcTXFAYMMeAb0Gz/cJiaqS5y9Ya1zV8EQuCPc0tiI3E75YFFS2OyXEljoFpOvrk7tRrlNit3Rtr3nXR6ZGiKcUg== 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=yih6QHYE4DaDHg0Vf0uZHGGyozrwe6Oms167g1kGBBM=; b=Pj4NAWOfGu23NdnrtLCDLiYGgJa10xYwK8hshd3ka3eRY1H58YxmfZgXzfSGmNconrSZ4WSIhMNiDqsREQlqW1bO6cvjRH7zKXhERRowWVFcicy3efYjxdX/2KXao/AZ+W3Cb5uWR37eMSfluT38aD/A6Mvk2z/DyDDBCB3fuHQ= 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 From: Jason Andryuk To: Juergen Gross , Ajay Kaher , Alexey Makhalov , "Broadcom internal kernel review list" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H. Peter Anvin" , Andy Lutomirski , "Peter Zijlstra" , Boris Ostrovsky , Yazen Ghannam , "Mario Limonciello" CC: Jason Andryuk , Sean Christopherson , Ingo Molnar , , , Subject: [PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV Date: Fri, 30 Oct 2026 20:33:08 -0400 Message-ID: <20261031003309.3751-1-jason.andryuk@amd.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: MWH0EPF000D894F:EE_|SN7PR12MB8002:EE_ X-MS-Office365-Filtering-Correlation-Id: d7fea2ce-8a16-4fb9-77d5-08df36e68c03 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|7416014|36860700016|82310400026|921020|260925022911599003|260925021911599003|260925021311599003|11063799006|56012099006|261009223027099003|261028144727099003|261026121527099003|261026140227099003|261021121427099003|261022075727099003|261022105027099003|10067099003|18002099003|13003099007; X-Microsoft-Antispam-Message-Info: aWk6nQhKji0GcTEmX23tLPr4lYCz4W5jlrdrp2QAHXlkIK4KMFpVZFXdTeVQKmbeBFLCyrSmljHSR7EZmCUkF0HsOnnoUaocL0a+Pf5qPkayCbKfkNcyGB1DxTvws5K7IVX5eig6qTGRhdC5rCV7X9SbhmjSPpefOtXCvvPHRj61GbroMPq+HjMhTL++WH6VQC94VtKNUmhY4vCF06GCLv3BdIaKOLnn3IAAaimUWVDPD2oKYfQarklJVR9UTOOjXEzKflK2PXx5TQAoMoK319mZ2UDcV8xkmXj/u8tbHHSr9U1dY2rJYFesHi/g5Yci1rkjRc779gCqC2IwRgVKJQg3YuRfwfCNrXifytIW2dYsRFiVWGhwxGuw1hyI7U7tfSOdT5makn5MCHYmZY5sOksB7KvIeSUMh9K4eq2i7V0b1QBfqqZtFQ3AtyE9BenyJs8bpBHoMZVayU0f0LGuFmBU3bpXVwKX7ErK9ve7sdOizVc4bMCzRjlygLWAF19hHosXB7rbHWBoKvSfBtcN+0pDXw/tvQ6SXyEK2VFnzCzI+P88nAazNWeioMrem9S2E9DAZy5a9uWoUQjYuA3cmJ9ds51w9lhcI2eXz6ibzaA3Ye2P5KpninpAKtTgbCx7RjI0H1AioRp5WJny7lD6Oo11eAsfBQY9XFyJyxI1SFAypdzqAH0HZb64gGEGvkgXOjXwzJtp5HunXaBhjDvWeA== 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)(1800799024)(376014)(7416014)(36860700016)(82310400026)(921020)(260925022911599003)(260925021911599003)(260925021311599003)(11063799006)(56012099006)(261009223027099003)(261028144727099003)(261026121527099003)(261026140227099003)(261021121427099003)(261022075727099003)(261022105027099003)(10067099003)(18002099003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: NYRg0/BadDsns6DekT8ePeXb82enHV1ukRb5r52da1kdASpsWvA0mXuU15E3cFx1hHSgRYrqBbIozCDfFHTziJoruYwopYVw6igrGxSTguSTg4Qhfp++W5ZX6aGLuC0/pgqLtQ+iBtmHO5YkGhVIoBvaWaw7w6WiHvXiNrN/+EusxAjBiXA3C6/kS7w4719+P3in2EFe8BHpwuW28TAu8f+k4gXh6RyOukBly+trzlKTHOR2ngP2f8oKbLXLLahsqYlgNl5XEwtP075VkpKDdbax0Vg1ooDjbkQxlczggrJOgYBrocTr7daAbFgiQVr8/25ge/P9ko+YUJH7scHFHDj6Gc6tI+zRGXe84Bbmxq6W4db8aLcxK0XdrHeDBIAuUAUE5j526/zmVlYSPMmfbh6Hz/gqCFe5QDNVSMJIl2jAnmvcsCwd5jh47pJj89aQ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2026 00:33:12.8540 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d7fea2ce-8a16-4fb9-77d5-08df36e68c03 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: MWH0EPF000D894F.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8002 X-purgate-ID: tlsNG-ebf023/1793406802-C32CCB50-F028D635/0/0 X-purgate-type: clean X-purgate-size: 5858 Xen PV guests update page tables via hypercalls, and Xen refuses to let a domain map machine frames it does not own, such as chipset MMIO in a domU. The set_pte() paths ignore the hypercall result, so ioremap() returns a mapping whose PTEs are not present. Accessing the virtual address then faults. This was seen in print_s5_reset_status_mmio() on Xen PV domUs on AMD Zen hosts. The machine address is not accessible by the domU and faults on access. Add a pv_mmu_ops hook, ioremap_verify_range, which __ioremap_caller() calls after ioremap_page_range(). It defaults to returning success. Xen PV implements it by walking the range with lookup_address() and failing if any entry is not present, making ioremap() return NULL. This also affects a Xen PV dom0: an ioremap() of a range containing any page Xen refuses to map (e.g. MMIO Xen reserves for itself) now fails as a whole, rather than succeeding and faulting only when the refused page is accessed. Pages Xen forces read-only are still mapped present and are unaffected. Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset") Link: https://lore.kernel.org/xen-devel/20251219010131.12659-1-ariadne@ariadne.space/ Suggested-by: Sean Christopherson Suggested-by: Borislav Petkov Signed-off-by: Jason Andryuk --- arch/x86/include/asm/paravirt.h | 10 ++++++++++ arch/x86/include/asm/paravirt_types.h | 6 ++++++ arch/x86/kernel/paravirt.c | 7 +++++++ arch/x86/mm/ioremap.c | 3 +++ arch/x86/xen/mmu_pv.c | 24 ++++++++++++++++++++++++ 5 files changed, 50 insertions(+) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 0591aa38fd85..30cb1d1636e4 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -495,6 +495,11 @@ static inline void arch_leave_lazy_mmu_mode(void) arch_flush_lazy_mmu_mode(); } +static inline int ioremap_verify_range(unsigned long addr, unsigned long size) +{ + return PVOP_CALL2(int, pv_ops, mmu.ioremap_verify_range, addr, size); +} + static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, phys_addr_t phys, pgprot_t flags) { @@ -557,6 +562,11 @@ static __always_inline unsigned long arch_local_irq_save(void) static inline void paravirt_enter_mmap(struct mm_struct *mm) { } + +static inline int ioremap_verify_range(unsigned long addr, unsigned long size) +{ + return 0; +} #endif #ifndef CONFIG_PARAVIRT diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index b4c4a23e77a1..674613301a83 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -164,6 +164,12 @@ struct pv_mmu_ops { void (*lazy_mode_flush)(void); + /* + * Verify that an ioremap()ed kernel virtual address range was + * actually mapped. Returns 0 on success. + */ + int (*ioremap_verify_range)(unsigned long addr, unsigned long size); + /* dom0 ops */ /* Sometimes the physical address is a pfn, and sometimes its diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 00b59d774389..b1bc519c660d 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -88,6 +88,11 @@ static noinstr void pv_native_set_debugreg(int regno, unsigned long val) { native_set_debugreg(regno, val); } + +static int native_ioremap_verify_range(unsigned long addr, unsigned long size) +{ + return 0; +} #endif struct pv_info pv_info = { @@ -207,6 +212,8 @@ struct paravirt_patch_template pv_ops = { .mmu.lazy_mode_flush = paravirt_nop, + .mmu.ioremap_verify_range = native_ioremap_verify_range, + .mmu.set_fixmap = native_set_fixmap, #endif /* CONFIG_PARAVIRT_XXL */ }; diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 12c8180ca1ba..6b45a7eef593 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -301,6 +301,9 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size, if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot)) goto err_free_area; + if (ioremap_verify_range(vaddr, size)) + goto err_free_area; + ret_addr = (void __iomem *) (vaddr + offset); mmiotrace_ioremap(unaligned_phys_addr, unaligned_size, ret_addr); diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 377c3c0d9f20..e524d318171f 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -359,6 +359,29 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) __xen_set_pte(ptep, pteval); } +/* + * PTE updates are made via (possibly batched) hypercalls whose failures + * are not propagated back to the caller. Xen refuses to let a domain map + * machine frames it does not own (e.g. chipset MMIO in a domU), leaving the + * PTE not present. Walk the range to make sure every page got mapped. + */ +static int xen_ioremap_verify_range(unsigned long addr, unsigned long size) +{ + unsigned long end = addr + size; + unsigned int level; + pte_t *pte; + + while (addr < end) { + pte = lookup_address(addr, &level); + if (!pte || !pte_present(*pte)) + return -ENXIO; + + addr = (addr & page_level_mask(level)) + page_level_size(level); + } + + return 0; +} + static pte_t xen_ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) { @@ -2218,6 +2241,7 @@ void __init xen_init_mmu_ops(void) pv_ops.mmu.enter_mmap = xen_enter_mmap; pv_ops.mmu.exit_mmap = xen_exit_mmap; pv_ops.mmu.lazy_mode_flush = xen_flush_lazy_mmu; + pv_ops.mmu.ioremap_verify_range = xen_ioremap_verify_range; pv_ops.mmu.set_fixmap = xen_set_fixmap; memset(dummy_mapping, 0xff, PAGE_SIZE); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Oct 31 01:52:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 01:52:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466546.1676468 (Exim 4.92) (envelope-from ) id 1xMyG9-0006pl-HQ; Sat, 31 Oct 2026 01:51:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466546.1676468; Sat, 31 Oct 2026 01:51: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 1xMyG9-0006pe-Dv; Sat, 31 Oct 2026 01:51:53 +0000 Received: by outflank-mailman (input) for mailman id 1466546; Sat, 31 Oct 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 1xMyG7-0006pY-UN for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 01:51:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMyG7-00F2cG-3h for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 02:51:51 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae5498a-8faa-0a2a0a5109dd-0a2a450bcc10-20 for ; Sat, 31 Oct 2026 02:51:50 +0100 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 6ae549b5-b7e8-0a2a450b0019-cddcb4834a0c-3 for ; Sat, 31 Oct 2026 02:51:50 +0100 Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69V1C9Eq3872017 for ; Sat, 31 Oct 2026 01:51:48 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 4hn2x08m72-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sat, 31 Oct 2026 01:51:48 +0000 (GMT) Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-36637676140so1895228eec.0 for ; Fri, 30 Oct 2026 18:51:48 -0700 (PDT) Received: from [192.168.1.199] (192-80-163-190.dyn.novuscom.net. [192.80.163.190]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-36a42a98f65sm10975065eec.28.2026.10.30.18.51.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Oct 2026 18:51: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=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= 9EYJOM0H9dJD2hgklOIl9JoR5CMKcX6ZZzpTCEQjgyk=; b=knvkgoU36fxNqvHI APfyHeBmKE5zbj3iokodOvop9u//Te8eAgfU8vhwHL2qknoF/LTG+CChpV6kXyys W9mgKu52yLpwRiwBgawRXdyksPhxbRrcGSPSS3XsT5j19GWxPiRvDFE4yawnjbKe 3+cE9yJl6FPhtLhZHqbJ9AEPF0oh+XcfEz21v0QLcRsQag56kThffwM7nO4FF/XS 4OCAM9pYQfzRbAGHY8AVkD6tNXQZQwtKTWOrDX8fXIE8YYw3t50cv7WFMYo/nwJU fjTt/c5fwPZHe1xRhJ41JhfUWHwtBDx/G1uV5pc/qZsoox7uMxXTl3evB7hK7w0H SsRVDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1793411507; x=1794016307; 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=9EYJOM0H9dJD2hgklOIl9JoR5CMKcX6ZZzpTCEQjgyk=; b=dOk4Rpt3Dh28cDUt2AWPYmsUH2MxzIpYEAOrHziWOH3yhabI6jrdWXuxLIwGvzled3 HYZAfMjoIEoC4m5QLRQgHJu4pad4iGLx0wxXI0Bu3/DdempLF8r87q1scDDWb+iB07kG M7E3ysMhhSq3Ulu6+GkHLAuDkYZwsWmgfWIxzgtB2j/WB44/gSI6IRiVS9bvlxPGf7O9 EnUGmkL8vHFRrQklZsJMxdqJCeyI5QAT9igDct5+ot3aMUkCY/qrjq3OQho4n6pWaIKA RVP+UQSVlJeLtGxK+5uD7HZzlQu1Ute6k2LKxOhIkphj+yKHf3ZZV/DH/a/EMt6pQlmq OEvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793411507; x=1794016307; 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=9EYJOM0H9dJD2hgklOIl9JoR5CMKcX6ZZzpTCEQjgyk=; b=RC19Npq8Xg6r7ImYK8stxbpeDzjbLcwJ9CWHiSeWRfgzeF/RbzXT3Qbd1Bmk1CkcIQ 8JvWV/RM0eamrAoUXgqqrmTmDPpBSHH8FqMb/wgntS2+elduo8nowoq5kTacXTgyhvwg 6HCpIbpUopeijkpQvaFYNnPDbsuqWg4C9asymC9cNIPaPSsi+w/+4TdA0JwJ0jlOySqS qrJ8d4WLQW3KubNOLGS13orXW7jUzItlepGGGVCEbFF/hOAzrKigFivsjD9Bz03Jkkf4 OGNbABL7bAWE4wFRsarPJrFg2VRFo8m4zOUV4BJxSnfb57vo47CDyGC8me2QDfOxRCZz heng== X-Forwarded-Encrypted: i=1; AKwUvBzWxXrHKGZDQzUTg+5rYdWXUmB6w4kbssozGCCFG6Fo7utJ4/kX+ZBj5FnWfrMLGGCl0i0vcPlFCmI=@lists.xenproject.org X-Gm-Message-State: AFq9FYJVakVw/MKsJWJyZfifeeWquP8iKHuZN0n5cfPGfTNRJjGC4UYa aX5vpBA0y+G0q4MBz8HrbMrZaJog77ZPL/UgoEeUjc973zdNVfLcbbKyalHhX15dA3Pzt00tkxo A3R1WcveK2sHvp6qqdD+yet611GTIFfVNAzTkyDZFNeIrqhrbcv0xl1Tkg1lhtfsH0ZKb1g== X-Gm-Gg: AYBFou2gaJ7Xz+ebgT0a0YG20PmLISnL6axoY238pandk9TBaKA8KZNgo5Ndxc25lTn NunPk6yLLboTsmq0LCzsdtxHxtGFiU49P/WiwtVkGkx5m8D4H6/dMIsoeh70Gjb4DvSizzhRgso S7Iox0nn+Oc9hz8i9b/WW1BDOA9TQZr47z81kue+mT0W1iPg+WhNaH6MZZ2ULGwT5dSOn8Lz/yR aMzXGvoAocKn2SQHcrVrRB2OwOLuf9sW3HAknXQMqHdaWsPqio9qvv8rLojJEuoPUGKZ3FVJdMn UK0tg8qdAOnXRLPWjtOGGEOizGpwj8jR1yLMU+SlQ+5+ALtNMxNXO27qH91+bgLAWHZGHQ9teas +rK5ESCqyusgjLyNh9s2uCG88k+bSQ7symiOosTB+TQj7bNPnFziDm7SGTzxPovjJpLLljQ5/BM 7L5GSiPGEIaUxws8q2jtG1VSP1s5UKfBpLSjOTSfC9YOc= X-Received: by 2002:a05:693c:880c:10b0:35c:cd26:3066 with SMTP id 5a478bee46e88-36a424655bcmr5937771eec.41.1793411507365; Fri, 30 Oct 2026 18:51:47 -0700 (PDT) X-Received: by 2002:a05:693c:880c:10b0:35c:cd26:3066 with SMTP id 5a478bee46e88-36a424655bcmr5937730eec.41.1793411506763; Fri, 30 Oct 2026 18:51:46 -0700 (PDT) Message-ID: Date: Fri, 30 Oct 2026 17:51:44 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration To: BALATON Zoltan , Yonggang Luo Cc: qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Thomas Huth , =?UTF-8?Q?Cl=C3=A9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org References: <20261030151539.1872-1-luoyonggang@gmail.com> From: Pierrick Bouvier Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: 2irOUOfK4gg-fPaaQsPmGq5tadLqG3mF X-Proofpoint-GUID: 2irOUOfK4gg-fPaaQsPmGq5tadLqG3mF X-Proofpoint-Spam-Info: AW1haW4tMjYxMDMxMDAwNyBTYWx0ZWRfXyqBhMDbmJ85F Cw6UGqBD4MTBSkLeH7vOfy/uCKGQT4QVvxw4Mj0n+2vlEQ2H3u+hkxQz4cM+Z304P6tI/0tkf4r mgk1NjMEM1lP4BkEUWFUeLqOEDsx3O0= X-Authority-Analysis: v=2.4 cv=WfKZ+EhX c=1 sm=1 tr=0 ts=6ae549b4 cx=c_pps a=Uww141gWH0fZj/3QKPojxA==:117 a=9852oil1ID9t5xBSyQ/BEA==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=3o5FCx-jELZdd1X3BU0A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=PxkB5W3o20Ba91AHUih5:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDMxMDAwNyBTYWx0ZWRfX8IrfS0bwnZdx 0yn9mUTCpCLuhjgZfXO2sxmrmhA9H4xEtE5K39C1ktL1FUzRT4I9by56/fW1UemM08zQv14aLgB XJ25Yn6q3mGvsFvNOl7cxH+jW7KvV5zR2pUBcsOryclu/EwqGMoY9OG9Vm2UR1IAxcdYoyfpTlY Fv8XLJQ149GElVjxVQMkWT21dFd73lRD3+TmByzpyJrOtQIGBh7UCLvAsGDEtiYjkwvmqhoAGEf bpzeepm/AQfEr9FlC1apwsV7uluDKdtr/lOJhV2RyEU9HW3ceM257PjSY4rnDy0IbB77H/wQKZb bdDVx9gRz9qHineu2lAtGtu8SfB9neI00cJ+RirNdqM7P8lEd4gMdVraTz4v1JzTTVtUil5Er4E u0jCA8U8bwx6ZUzjXjmiYA8YPjsBDFAIXu3R65/t6NpJaT606gyjNCWBoAr9oY3dWsIVlQV6MGQ OlAxccysoKQrPdggflA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-31_01,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 adultscore=0 clxscore=1015 priorityscore=1501 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610300000 definitions=main-2610310007 X-purgate-ID: tlsNG-42698a/1793411510-AACDF9EA-591380B5/0/0 X-purgate-type: clean X-purgate-size: 5186 On 10/30/2026 4:09 PM, BALATON Zoltan wrote: > On Fri, 30 Oct 2026, Yonggang Luo wrote: >> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the >> type_init >> function that calls type_register_static(). A later change needs to >> pass a > > That's the point of the macro to hide the boiler plate code. > >> target mask into that registration, and the macros have no parameter >> for it. > > Couldn't you just change the macros to take that parameter instead of > expanding it everywhere? > Problem of macros is that they don't have default parameters, so you need variants for everything: DEFINE_MACHINE DEFINE_MACHINE_EXTENDED DEFINE_MACHINE_WITH_INTERFACES DEFINE_MACHINE_WITH_INTERFACE_ARRAY and now would need a new variant, with variant for other existing ones. In the end, it's just simpler to remove this and add the boilerplate. It's written once and never modified, so using a macro just save typing those lines once. > Regards, > BALATON Zoltan > >> This series expands every caller first, with no behavior change, so the >> follow-up only replaces the type_register_static() call. >> >> Each machine file gains a class_init function, a TypeInfo, and a >> type_init >> function that calls type_register_static(). The last patch removes >> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h. >> >> Yonggang Luo (15): >>  hw/alpha: expand DEFINE_MACHINE in dp264.c >>  hw/m68k: expand DEFINE_MACHINE for M68K machines >>  hw/microblaze: expand DEFINE_MACHINE for MicroBlaze >>  hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c >>  hw/arm: expand DEFINE_MACHINE for ARM machines >>  hw/riscv: expand DEFINE_MACHINE for RISC-V machines >>  hw/core/null-machine: expand DEFINE_MACHINE >>  hw/mips: expand DEFINE_MACHINE for MIPS machines >>  hw/ppc: expand DEFINE_MACHINE for PowerPC machines >>  hw/sh4: expand DEFINE_MACHINE in r2d.c >>  hw/sparc: expand DEFINE_MACHINE in leon3.c >>  hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c >>  hw/xtensa: expand DEFINE_MACHINE in sim.c >>  hw/xtensa: expand DEFINE_MACHINE in virt.c >>  hw/core/boards: remove unused DEFINE_MACHINE* macros >> >> hw/alpha/dp264.c                    | 18 +++++++++-- >> hw/arm/bananapi_m2u.c               | 18 +++++++++-- >> hw/arm/cubieboard.c                 | 19 +++++++++--- >> hw/arm/digic_boards.c               | 18 +++++++++-- >> hw/arm/imx25_pdk.c                  | 18 +++++++++-- >> hw/arm/imx8mm-evk.c                 | 20 +++++++++--- >> hw/arm/integratorcp.c               | 14 ++++++--- >> hw/arm/kzm.c                        | 18 +++++++++-- >> hw/arm/max78000fthr.c               | 17 ++++++++-- >> hw/arm/mcimx6ul-evk.c               | 18 +++++++++-- >> hw/arm/mcimx7d-sabre.c              | 20 +++++++++--- >> hw/arm/msf2-som.c                   | 17 ++++++++-- >> hw/arm/netduino2.c                  | 17 ++++++++-- >> hw/arm/netduinoplus2.c              | 17 ++++++++-- >> hw/arm/olimex-stm32-h405.c          | 18 +++++++++-- >> hw/arm/orangepi.c                   | 19 +++++++++--- >> hw/arm/stm32vldiscovery.c           | 18 +++++++++-- >> hw/core/null-machine.c              | 18 +++++++++-- >> hw/m68k/an5206.c                    | 18 +++++++++-- >> hw/m68k/mcf5208.c                   | 18 +++++++++-- >> hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++-- >> hw/microblaze/xlnx-zynqmp-pmu.c     | 19 ++++++++++-- >> hw/mips/boston.c                    | 18 +++++++++-- >> hw/mips/fuloong2e.c                 | 18 +++++++++-- >> hw/mips/malta.c                     | 12 ++++++-- >> hw/ppc/amigaone.c                   | 18 +++++++++-- >> hw/ppc/pegasos.c                    | 21 ++++++++----- >> hw/ppc/ppc440_bamboo.c              | 18 +++++++++-- >> hw/ppc/prep.c                       | 18 +++++++++-- >> hw/ppc/sam460ex.c                   | 18 +++++++++-- >> hw/ppc/virtex_ml507.c               | 18 +++++++++-- >> hw/riscv/boston-aia.c               | 18 +++++++++-- >> hw/riscv/microblaze-v-generic.c     | 18 +++++++++-- >> hw/sh4/r2d.c                        | 18 +++++++++-- >> hw/sparc/leon3.c                    | 18 +++++++++-- >> hw/tricore/tricore_testboard.c      | 18 +++++++++-- >> hw/xenpv/xen_machine_pv.c           | 18 +++++++++-- >> hw/xtensa/sim.c                     | 18 +++++++++-- >> hw/xtensa/virt.c                    | 18 +++++++++-- >> include/hw/core/boards.h            | 48 ----------------------------- >> 40 files changed, 605 insertions(+), 142 deletions(-) >> >> From xen-devel-bounces@lists.xenproject.org Sat Oct 31 02:57:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 02:57:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466579.1676477 (Exim 4.92) (envelope-from ) id 1xMzH9-0007dh-5J; Sat, 31 Oct 2026 02:56:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466579.1676477; Sat, 31 Oct 2026 02: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 1xMzH9-0007da-1Q; Sat, 31 Oct 2026 02:56:59 +0000 Received: by outflank-mailman (input) for mailman id 1466579; Sat, 31 Oct 2026 02:56:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMzH7-0007dU-8N for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 02:56:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMzH6-004Z3k-Ld for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 03:56:56 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae557bb-8faa-0a2a0a5109dd-0a2a4501bd72-34 for ; Sat, 31 Oct 2026 03:56:56 +0100 Received: from [209.85.208.50] (helo=mail-ed1-f50.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae558f8-5984-0a2a45010019-d155d032dc42-3 for ; Sat, 31 Oct 2026 03:56:56 +0100 Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-6b1aa4d71e7so1298586a12.0 for ; Fri, 30 Oct 2026 19:56: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=20260707 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:Reply-To:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1793415416; cv=none; d=google.com; s=arc-20260327; b=HU4+s9XfR6FyTB1eUbyqKl9UylnTr/MyKfaG0exVfG+2jaS18gC0eZWLGH2bTaqk2b OIWVb7mmDjOU3HWLE2NetO2eXg1FwOksChcvULfgxzhGjIdL+Nso4zAfOoCM5O3lF5pp 2T7CKxTcKpf7QlHniurO8AwuqFCwAoKysJclLLizzqNy2R8mq6E1EHxbGNiCVXuOR+qj aE836tltfxFvMz7ytjhi+Hucs0tvD3darR2lxwnf/HOSBe3OC6Qz06Rgv7RezGU8DMqZ tFdKBgzFHQprnKQ4EDeKT5FxJ53LdFERlmqGk5jdjR1NP/g2WecRy7bFC7TydFZn4WCa G5Ow== 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 :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=IrJEK4Rz34flPDpX3IpkuF++CG2fC1jTcOILK6FoJl8=; fh=mxu9rumstr0BDuoLrGDO/mSOfGVKbtHSZrFNXT8jHwU=; b=TiOV7lxoJhDZyyNaG9FVFXGHxY28EMClQBEc3ugH9L6QuaoTREM+Pdfo2RpW4S97P9 vQSZLeFsiW5yb4dhGzcH6GCWmbIUx5HIpTwEzNFnPjnN3HqDZsWppjExONDoEO4bKraZ w9pjXQfRwgp4r8No1Pwut8zTTN00RBb6Gz3ySUXCV1h2GFU+Enbi1wau9+HeyygaGzu2 oiI+oJOkplR+WjVKig/+Fd5Sa1rgfCPy/Hvmh0IfgGox42ul9C7L7zBcGhpSg1MStmZI 90UybspUuJ7L+9E1fApmF7gSOm8k+B1EMzHiId5UAO72f9ZmC3rcCfiBdRthj17CzrFh j6BA==; 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=20260707; t=1793415416; x=1794020216; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:reply-to:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=IrJEK4Rz34flPDpX3IpkuF++CG2fC1jTcOILK6FoJl8=; b=tdJdE97LF5JrsOAa9DD8se2T7J0aMn2WlorS+rMSQ4QPyp+hZ6SGxfnYIRUmUaySTd 7+GovuCp4FVYZTGuRLZMyDGGSAJ9rscRTMM3pOSLNGk26yb+B/6HXV2jSc9HReIS2/YL 0OnbN23ojwGskSbCm3zdVf8NRHdY5AJMshEFImFd3wxZ7GMqkgwVtsqKkTFeq2rw2Q39 vkvl0ocngFC6GjuN6pRitjPKtD3i+6ISX/OLSvGd7Vx0dUBw1sxYbdh6Ux6eT2TgFYd0 LnGwHY6P53dO8kTCP+oiB0bPuDlCNbGEh9qj0pVMpXzcBJcM+ybGtY/s9dTbqV7EvMkk WyDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793415416; x=1794020216; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:reply-to: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=IrJEK4Rz34flPDpX3IpkuF++CG2fC1jTcOILK6FoJl8=; b=S6LSw1iFO5a0ZxMT222dtzzvBdj1kYh2JMauzLp2eLfcvW1goJBPuT8LR/Poph9cTQ Zunj5QCBAIJ4xl5mc24UZSjHCUBTVnxkquntRHhmiJi6MdbKKeXUMNgAvpDh0UOBlQnJ M2jUDwEdmjcpTzxl2E1WiJUeSVrzbvCzWAS5ZrlnJ3Rbfzgtw/eOh1e6dOuP7RYZCfjM EPqjDtsD5QLFVJudPOE0rif1glesq9Md4O346WYX7X1aeiXZ5QQ2ObYFyzmoIAFz9i+R kGQfdeu8+M4XXWEX59OlyCpEhy0GpbSSvOWRXGsOwfP4q4QJWhnVV6o6xRem1FFuuvUS 0Kcg== X-Forwarded-Encrypted: i=1; AKwUvBxJ6Ty0bIIoWDSvqiwrEpIwgzrdBQVP/6L1rfyTweWFhyhoGZkarXXMhCf2RcSNpnioaauJvUVwA4E=@lists.xenproject.org X-Gm-Message-State: AFq9FYLuSZMw+IL/MepvSUMD05pYXAmJ9femRCT97uVPPYtUivfL5X6B aR3rftCYVLsVM/W/ybAZLs2gmsK/CnldsEBqimrOwdcaGdWuAUEOHSm2Q4jkystND9tRNMUIzbk IDgqvsuYcA8qeLIvaS7E+UdtN4oJo7/0= X-Gm-Gg: AYBFou3RX+doFF6w/wPdzbm0tRp5eqQ2DRHdzeuPk9jnZUk1drd8cJ3H5Gitv69ajH1 0Q9B3DBeZrHZMvFIeB8V/uzhlzSUYzewUvAvPQV/kjcfgYzAXEvjF8ex2FsdvXUWtOlUt+gMfJj ZI9wgNEruNvrHenKh5Tk8fQzzUxYP617JiPjosK4ALegF8wnpj6/syntN5Cvw9jp2fQcWaSgiA3 xjRRJr5FL9K/KZvmdOj3MFP9UpTi/aXPVxkuCPqEwL7z3ATyR/nL2nWgInS28h0A6cZruVXO4SR KbChaPaW5eFqe4cl0+gzfYbqT9bMdqdaxi22LWJT+LMqUSO+d8OUn2Njq4ct8fAaxpooQsDNat9 CjZ1s4lOPu1gmIS/uKZTIVuwcxn47eCi00ZFw X-Received: by 2002:a05:6402:15c7:b0:6b1:b5ea:2590 with SMTP id 4fb4d7f45d1cf-6b4d438bb92mr2317970a12.12.1793415415904; Fri, 30 Oct 2026 19:56:55 -0700 (PDT) MIME-Version: 1.0 References: <20261030151539.1872-1-luoyonggang@gmail.com> In-Reply-To: Reply-To: luoyonggang@gmail.com From: Yonggang Luo Date: Sat, 31 Oct 2026 10:56:42 +0800 X-Gm-Features: AclHuK84ZjRzywlmKa-ru9qdyZRxP4WT2vvy0q6jx4JGmonAqySpYfbI_27IcMQ Message-ID: Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration To: Pierrick Bouvier Cc: BALATON Zoltan , qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Thomas Huth , =?UTF-8?Q?Cl=C3=A9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1793415416-1E27A757-D642CABA/0/0 X-purgate-type: clean X-purgate-size: 5213 On Sat, Oct 31, 2026 at 9:51=E2=80=AFAM Pierrick Bouvier wrote: > > On 10/30/2026 4:09 PM, BALATON Zoltan wrote: > > On Fri, 30 Oct 2026, Yonggang Luo wrote: > >> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the > >> type_init > >> function that calls type_register_static(). A later change needs to > >> pass a > > > > That's the point of the macro to hide the boiler plate code. > > > >> target mask into that registration, and the macros have no parameter > >> for it. > > > > Couldn't you just change the macros to take that parameter instead of > > expanding it everywhere? > > > > Problem of macros is that they don't have default parameters, so you > need variants for everything: > > DEFINE_MACHINE > DEFINE_MACHINE_EXTENDED > DEFINE_MACHINE_WITH_INTERFACES > DEFINE_MACHINE_WITH_INTERFACE_ARRAY > and now would need a new variant, with variant for other existing ones. > > In the end, it's just simpler to remove this and add the boilerplate. > It's written once and never modified, so using a macro just save typing > those lines once. Yeap, as now I have a working TypeImpl::targets and TypeBucket locally, tha= t looks minimal, so I am moving forward. This series is reject, then let us delay the EXPAND of DEFINE_MACHINE_* macros work later. > > > Regards, > > BALATON Zoltan > > > >> This series expands every caller first, with no behavior change, so th= e > >> follow-up only replaces the type_register_static() call. > >> > >> Each machine file gains a class_init function, a TypeInfo, and a > >> type_init > >> function that calls type_register_static(). The last patch removes > >> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards= .h. > >> > >> Yonggang Luo (15): > >> hw/alpha: expand DEFINE_MACHINE in dp264.c > >> hw/m68k: expand DEFINE_MACHINE for M68K machines > >> hw/microblaze: expand DEFINE_MACHINE for MicroBlaze > >> hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c > >> hw/arm: expand DEFINE_MACHINE for ARM machines > >> hw/riscv: expand DEFINE_MACHINE for RISC-V machines > >> hw/core/null-machine: expand DEFINE_MACHINE > >> hw/mips: expand DEFINE_MACHINE for MIPS machines > >> hw/ppc: expand DEFINE_MACHINE for PowerPC machines > >> hw/sh4: expand DEFINE_MACHINE in r2d.c > >> hw/sparc: expand DEFINE_MACHINE in leon3.c > >> hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c > >> hw/xtensa: expand DEFINE_MACHINE in sim.c > >> hw/xtensa: expand DEFINE_MACHINE in virt.c > >> hw/core/boards: remove unused DEFINE_MACHINE* macros > >> > >> hw/alpha/dp264.c | 18 +++++++++-- > >> hw/arm/bananapi_m2u.c | 18 +++++++++-- > >> hw/arm/cubieboard.c | 19 +++++++++--- > >> hw/arm/digic_boards.c | 18 +++++++++-- > >> hw/arm/imx25_pdk.c | 18 +++++++++-- > >> hw/arm/imx8mm-evk.c | 20 +++++++++--- > >> hw/arm/integratorcp.c | 14 ++++++--- > >> hw/arm/kzm.c | 18 +++++++++-- > >> hw/arm/max78000fthr.c | 17 ++++++++-- > >> hw/arm/mcimx6ul-evk.c | 18 +++++++++-- > >> hw/arm/mcimx7d-sabre.c | 20 +++++++++--- > >> hw/arm/msf2-som.c | 17 ++++++++-- > >> hw/arm/netduino2.c | 17 ++++++++-- > >> hw/arm/netduinoplus2.c | 17 ++++++++-- > >> hw/arm/olimex-stm32-h405.c | 18 +++++++++-- > >> hw/arm/orangepi.c | 19 +++++++++--- > >> hw/arm/stm32vldiscovery.c | 18 +++++++++-- > >> hw/core/null-machine.c | 18 +++++++++-- > >> hw/m68k/an5206.c | 18 +++++++++-- > >> hw/m68k/mcf5208.c | 18 +++++++++-- > >> hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++-- > >> hw/microblaze/xlnx-zynqmp-pmu.c | 19 ++++++++++-- > >> hw/mips/boston.c | 18 +++++++++-- > >> hw/mips/fuloong2e.c | 18 +++++++++-- > >> hw/mips/malta.c | 12 ++++++-- > >> hw/ppc/amigaone.c | 18 +++++++++-- > >> hw/ppc/pegasos.c | 21 ++++++++----- > >> hw/ppc/ppc440_bamboo.c | 18 +++++++++-- > >> hw/ppc/prep.c | 18 +++++++++-- > >> hw/ppc/sam460ex.c | 18 +++++++++-- > >> hw/ppc/virtex_ml507.c | 18 +++++++++-- > >> hw/riscv/boston-aia.c | 18 +++++++++-- > >> hw/riscv/microblaze-v-generic.c | 18 +++++++++-- > >> hw/sh4/r2d.c | 18 +++++++++-- > >> hw/sparc/leon3.c | 18 +++++++++-- > >> hw/tricore/tricore_testboard.c | 18 +++++++++-- > >> hw/xenpv/xen_machine_pv.c | 18 +++++++++-- > >> hw/xtensa/sim.c | 18 +++++++++-- > >> hw/xtensa/virt.c | 18 +++++++++-- > >> include/hw/core/boards.h | 48 ----------------------------- > >> 40 files changed, 605 insertions(+), 142 deletions(-) > >> > >> > --=20 =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo From xen-devel-bounces@lists.xenproject.org Sat Oct 31 03:20:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 03:20:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466592.1676486 (Exim 4.92) (envelope-from ) id 1xMze4-0003pI-T1; Sat, 31 Oct 2026 03:20:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466592.1676486; Sat, 31 Oct 2026 03:20: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 1xMze4-0003pB-P7; Sat, 31 Oct 2026 03:20:40 +0000 Received: by outflank-mailman (input) for mailman id 1466592; Sat, 31 Oct 2026 03:20:39 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMze2-0003p4-Tz for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 03:20:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMze2-003JgD-3q for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 04:20:38 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae55e05-2eae-0a2a0a5409dd-0a2a4502acc2-28 for ; Sat, 31 Oct 2026 04:20:38 +0100 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae55e85-6ca4-0a2a45020019-416d716cd97c-3 for ; Sat, 31 Oct 2026 04:20:37 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 17F2740E02B7; Sat, 31 Oct 2026 03:20:37 +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 PLd-mWRMhp0Y; Sat, 31 Oct 2026 03:20:34 +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 3AD0340E016C; Sat, 31 Oct 2026 03:20: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=1793416834; bh=Klm3BPKegCJLOq8Ks12UtrTpT08D/JxDFOWEzcnuIcA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jyPzJuiBOC2jtFU5He9dgn18qRO9UVk6fLepmpXLRJQxU7rYKKtv2llp/tKzckA2F t7I46KhCAPpwMey1QZ053NtyuecFfTeLBFZAKvIdXftaMJkAbc8cU2inPO260+M7bG 5sWeQSqH84YMxJzmnL1epY6A/IXfJFtkxEmD/R4UtEPs82RVSbyjE988Q7nKIl3XFe Jvd7Ob6ArF2kPpNGDvM0f3Xn9mlzTieC9RN/LfmvyBFbgN/Mza13r2+yKjVB/jym8c +zG5SkVTQj5WuSthqdhXOTeqkIIGsPbgo20e7ATjZFFZsJTm91atu5E3LQiufQ6guY jQo3IUvjFRMUjrslP3/FU3l5L0uAj6lmcmH2+X44VJbd1mh6XaVXX/t1LZWulvHOCM zWtucKc4CwOLM84WKnvK0lIsnyXPq+6R4XCKyS+zH5rdIQdB2B4W8exD0s2ylDpB5B ZmT+RDUVVKXX9XNJtXhdctDXxDFam4iyKCOkcrstDsOtiYwneJy+1Jg3w2zhkxjO0N A49UV7WYEnT9I8xFVMbICyEfmHg9Zh7bGkv0MEHfaOwhCWYt6OtHYo9wH5kd14yqPV RjBXouR2RTFygk5l63/E9l8d6hPPbPcm6tgXqiFoxIZNOQWneG1nBNA8zIe0nYYUMy 0OmRJUzw0B96jcoPxQWaMtSA= Date: Fri, 30 Oct 2026 20:20:09 -0700 From: Borislav Petkov To: Jason Andryuk Cc: Juergen Gross , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Boris Ostrovsky , Yazen Ghannam , Mario Limonciello , Sean Christopherson , Ingo Molnar , virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV Message-ID: <20261031032009.GIauVeaXTMNHgjYEiM@fat_crate.local> References: <20261031003309.3751-1-jason.andryuk@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20261031003309.3751-1-jason.andryuk@amd.com> X-purgate-ID: tlsNG-720697/1793416838-F16AF2AC-8C725260/0/0 X-purgate-type: clean X-purgate-size: 1959 On Fri, Oct 30, 2026 at 08:33:08PM -0400, Jason Andryuk wrote: > Xen PV guests update page tables via hypercalls, and Xen refuses to let a > domain map machine frames it does not own, such as chipset MMIO in a domU. > The set_pte() paths ignore the hypercall result, so ioremap() returns a > mapping whose PTEs are not present. Accessing the virtual address then > faults. This was seen in print_s5_reset_status_mmio() on Xen PV domUs > on AMD Zen hosts. The machine address is not accessible by the domU and > faults on access. > > Add a pv_mmu_ops hook, ioremap_verify_range, which __ioremap_caller() > calls after ioremap_page_range(). It defaults to returning success. > Xen PV implements it by walking the range with lookup_address() and > failing if any entry is not present, making ioremap() return NULL. > > This also affects a Xen PV dom0: an ioremap() of a range containing any > page Xen refuses to map (e.g. MMIO Xen reserves for itself) now fails as > a whole, rather than succeeding and faulting only when the refused page > is accessed. Pages Xen forces read-only are still mapped present and > are unaffected. > > Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset") That patch is an innocent bystander, if anything - nothing it can do about Xen being weird about not mapping host physical addresses not owned by the domain. And TBH, all that gymnastics just to prevent this from running on Xen, is not something that makes me all happy and so on. What is more, we try to get rid of PV ops, not add more. I'm sorry if I've misled you with my comment on the previous thread - I didn't think someone would even act on it. And I know Sean doesn't like X86_FEATURE_HYPERVISOR but sorry, nothing beats a oneliner at the beginning of print_s5_reset_status_mmio() vs this overkill. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Sat Oct 31 10:55:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 10:55:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466685.1676494 (Exim 4.92) (envelope-from ) id 1xN6k9-0007fZ-Vq; Sat, 31 Oct 2026 10:55:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466685.1676494; Sat, 31 Oct 2026 10:55: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 1xN6k9-0007fR-SY; Sat, 31 Oct 2026 10:55:25 +0000 Received: by outflank-mailman (input) for mailman id 1466685; Sat, 31 Oct 2026 10:55:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xN6k7-0007fL-CH for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 10:55:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xN6k6-0041mw-Me for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 11:55:22 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae5c8f4-e002-0a2a0a5209dd-0a2a4507bdd4-22 for ; Sat, 31 Oct 2026 11:55:22 +0100 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 6ae5c919-b4ea-0a2a45070019-b9ff1c23a669-3 for ; Sat, 31 Oct 2026 11:55:22 +0100 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 1a1919984c0000403d.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 31 Oct 2026 10:55:19 +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 95A9C81EBC; Sat, 31 Oct 2026 11:55:18 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=x3pGT8nMRCOwXEKiDdVRn0R4zMk+72E3EA8kyetHXsA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=GtiaMwcdCyzElf84T9JoX72UMljlDEV4SBS1kcPSGJsWBAq+YZTvm+p73xKQjOPyYc0MUdqxj b35hplAH/7eLb8eYAhwHC/3Mlp2Al+PcqK8dxwFfWV9afAuuBr+hG/fEQCshxK9ROgcavF2yJ4K ARkxdBMsAlimzew2kPYFJO+qePXFHy1yc5vDwgZa/7wC4T03MnMQgmXnWrXQrcVkBYkpkEGD7WQ ixED33D5WtKYAa4Fb+Zia60uEEv5eUmIkRvCQrryhcKvXezpFux8aoDZFVBa6e10eSwi4sdOw/9 f6s19zFQU4KIe1ah1uH+WFMrDtSgKsZTa7tU1zgdrhSA== X-Zone-Loop: dfc7d27d9ece9065b9045ad0ad62608c4874d6075fb6 x-campaign-type: default x-transaction-id: 7e7a8603-f85d-476e-b4dc-d4c21fc7daa8 x-swg-uid: 01-2be8cd43-d47a-42f5-a21f-0bed95d484e6 X-Mailer: Sweego Message-ID: <1793444119.8631fc262581453bbf619ec5b2062170.1a1919984c0000403d@vates.tech> x-swg-bid: 1793444119.8631fc262581453bbf619ec5b2062170.1a1919984c0000403d Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Sat, 31 Oct 2026 11:55:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] IOMMU: record the flushes skipped under iommu_dont_flush_iotlb To: Luca Di Maio , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD References: <20261030165031.2560020-1-luca@edera.dev> <20261030165031.2560020-2-luca@edera.dev> 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: <20261030165031.2560020-2-luca@edera.dev> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------p5VK3GaO0TPWYBJVW5PXafJA" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793444118841 X-purgate-ID: tlsNG-ef75cf/1793444122-360C5AE4-8243BE27/0/0 X-purgate-type: clean X-purgate-size: 10628 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------p5VK3GaO0TPWYBJVW5PXafJA Content-Type: multipart/mixed; boundary="------------KSSnjw4vfNvorwyZIFbFQZsf"; protected-headers="v1"; hp="clear" Message-ID: Date: Sat, 31 Oct 2026 11:55:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] IOMMU: record the flushes skipped under iommu_dont_flush_iotlb To: Luca Di Maio , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD References: <20261030165031.2560020-1-luca@edera.dev> <20261030165031.2560020-2-luca@edera.dev> 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: <20261030165031.2560020-2-luca@edera.dev> --------------KSSnjw4vfNvorwyZIFbFQZsf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMzAvMTAvMjAyNiDDoCAxNzo1MywgTHVjYSBEaSBNYWlvIGEgw6ljcml0wqA6DQo+IFdo aWxlIGlvbW11X2RvbnRfZmx1c2hfaW90bGIgaXMgc2V0LCBpb21tdV9sZWdhY3lfdW5tYXAo KSBhbmQgdGhlDQo+IHNoYXJlZC1FUFQgcGF0aCBvZiBlcHRfc2V0X2VudHJ5KCkgc2tpcCB0 aGVpciBJT1RMQiBmbHVzaCBhbmQgZHJvcCB0aGUNCj4gZmxhZ3MgaXQgd291bGQgaGF2ZSB1 c2VkLiBBY2N1bXVsYXRlIHRoZW0gaW4gdGhlIHBlci1DUFUNCj4gaW9tbXVfc2tpcHBlZF9m bHVzaF9mbGFncywgc28gdGhhdCBhIGNhbGxlciBkZWZlcnJpbmcgdGhlIGZsdXNoIGNhbg0K PiBpc3N1ZSBpdCB3aXRoIHRoZSBzYW1lIGZsYWdzLiBUaGUgbmV4dCBwYXRjaCBkb2VzIHNv IGZvciBncmFudCB1bm1hcHMuDQo+IA0KPiBVc2UgYSB1aW50OF90LCBhcyBhIGZpeGVkIHdp ZHRoIGlzIG1lYW50OiBhIGJ5dGUgaG9sZHMgZXZlcnkgZmxhZyBhbmQNCj4gZml0cyBpbiB0 aGUgcGFkZGluZyBhZnRlciBpb21tdV9kb250X2ZsdXNoX2lvdGxiLCBzbyB0aGUgcGVyLUNQ VSBkYXRhDQo+IHRoYXQgZm9sbG93cyBkb2Vzbid0IG1vdmUuDQo+IA0KPiBBc3Npc3RlZC1i eTogQ2xhdWRlIENvZGU6Y2xhdWRlLW9wdXMtNS01DQo+IFNpZ25lZC1vZmYtYnk6IEx1Y2Eg RGkgTWFpbyA8bHVjYUBlZGVyYS5kZXY+DQo+IA0KPiAtLS0NCj4gICB4ZW4vYXJjaC94ODYv bW0vcDJtLWVwdC5jICAgICAgIHwgIDQgKysrKw0KPiAgIHhlbi9kcml2ZXJzL3Bhc3N0aHJv dWdoL2lvbW11LmMgfCAxMiArKysrKysrKysrKy0NCj4gICB4ZW4vaW5jbHVkZS94ZW4vaW9t bXUuaCAgICAgICAgIHwgIDEgKw0KPiAgIDMgZmlsZXMgY2hhbmdlZCwgMTYgaW5zZXJ0aW9u cygrKSwgMSBkZWxldGlvbigtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9t bS9wMm0tZXB0LmMgYi94ZW4vYXJjaC94ODYvbW0vcDJtLWVwdC5jDQo+IGluZGV4IDIwNGJk YjA1NGEuLjFhODdiMjVkOTQgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9wMm0t ZXB0LmMNCj4gKysrIGIveGVuL2FyY2gveDg2L21tL3AybS1lcHQuYw0KPiBAQCAtOTgxLDYg Kzk4MSwxMCBAQCBvdXQ6DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoaW9tbXVfZmxhZ3MgPyBJT01NVV9GTFVTSEZfYWRkZWQgOiAwKSB8DQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodnRkX3B0ZV9wcmVzZW50ID8gSU9NTVVf RkxVU0hGX21vZGlmaWVkDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDogMCkpOw0KPiArICAgICAgICBlbHNlIGlmICggaW9tbXVf dXNlX2hhcF9wdChkKSApDQo+ICsgICAgICAgICAgICB0aGlzX2NwdShpb21tdV9za2lwcGVk X2ZsdXNoX2ZsYWdzKSB8PQ0KPiArICAgICAgICAgICAgICAgIChpb21tdV9mbGFncyA/IElP TU1VX0ZMVVNIRl9hZGRlZCA6IDApIHwNCj4gKyAgICAgICAgICAgICAgICAodnRkX3B0ZV9w cmVzZW50ID8gSU9NTVVfRkxVU0hGX21vZGlmaWVkIDogMCk7DQo+ICAgICAgICAgICBlbHNl IGlmICggbmVlZF9pb21tdV9wdF9zeW5jKGQpICkNCj4gICAgICAgICAgICAgICByYyA9IGlv bW11X2ZsYWdzID8NCj4gICAgICAgICAgICAgICAgICAgaW9tbXVfbGVnYWN5X21hcChkLCBf ZGZuKGdmbiksIG1mbiwgMXVsIDw8IG9yZGVyLCBpb21tdV9mbGFncykgOg0KDQpXZSBub3cg aGF2ZQ0KDQooaW9tbXVfZmxhZ3MgPyBJT01NVV9GTFVTSEZfYWRkZWQgOiAwKSB8DQoodnRk X3B0ZV9wcmVzZW50ID8gSU9NTVVfRkxVU0hGX21vZGlmaWVkIDogMCkNCg0KZHVwbGljYXRl ZCBpbiAyIGRpZmZlcmVudCAoYWRqYWNlbnQpIHBsYWNlcywgSSB0aGluayB3ZSBzaG91bGQg Y29sbGFwc2UgDQppdCBpbiBhIHZhcmlhYmxlLiBpLmUgc29tZXRoaW5nIGxpa2UNCg0KdW5z aWduZWQgbG9uZyBmbHVzaF9mbGFncyA9DQogICAgIChpb21tdV9mbGFncyA/IElPTU1VX0ZM VVNIRl9hZGRlZCA6IDApIHwNCiAgICAgKHZ0ZF9wdGVfcHJlc2VudCA/IElPTU1VX0ZMVVNI Rl9tb2RpZmllZCA6IDApOw0KDQpCdXQgbW9yZSBnZW5lcmFsbHksIGdpdmVuIHRoYXQgaW9t bXVfZG9udF9mbHVzaF9pb3RsYiBpcyBvbmx5IA0Kc2V0L2NsZWFyZWQgaW4gcGF0aHMgdGhh dCBjaGVjayBpdCAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSksIHdoYXQgYWJvdXQgDQptb3Zp bmcgdGhpcyBsb2dpYyBpbnRvIGlvbW11X2lvdGxiX2ZsdXNoKCkgdG8gYmUgc3VwcHJlc3Nl ZCBieSANCmlvbW11X2RvbnRfZmx1c2hfaW90bGIgKGFuZCBpZiBzdXBwcmVzc2VkLCB8PSB0 aGUgDQppb21tdV9za2lwcGVkX2ZsdXNoX2ZsYWdzIGluc3RlYWQpID8NCg0KVGhhdCB3b3Vs ZCBnZXQgcmlkIG9mIGEgbG90IG9mIGR1cGxpY2F0ZWQgbG9naWMuDQoNCj4gZGlmZiAtLWdp dCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2lvbW11LmMgYi94ZW4vZHJpdmVycy9wYXNz dGhyb3VnaC9pb21tdS5jDQo+IGluZGV4IDRiMjJlY2ZlNjUuLjcwZWU0NWFmYjkgMTAwNjQ0 DQo+IC0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2lvbW11LmMNCj4gKysrIGIveGVu L2RyaXZlcnMvcGFzc3Rocm91Z2gvaW9tbXUuYw0KPiBAQCAtNjQsNiArNjQsMTEgQEAgYm9v bCBfX3JlYWRfbW9zdGx5IGlvbW11X2hhcF9wdF9zaGFyZSA9IHRydWU7DQo+ICAgYm9vbCBf X3JlYWRfbW9zdGx5IGlvbW11X2RlYnVnOw0KPiAgIA0KPiAgIERFRklORV9QRVJfQ1BVKGJv b2wsIGlvbW11X2RvbnRfZmx1c2hfaW90bGIpOw0KPiArLyoNCj4gKyAqIEEgYnl0ZSBob2xk cyBldmVyeSBJT01NVV9GTFVTSEZfKiwgYW5kIGZpdHMgaW4gdGhlIGFsaWdubWVudCBwYWRk aW5nIHRoZQ0KPiArICogYm9vbCBhYm92ZSBsZWF2ZXMsIGluc3RlYWQgb2Ygc2hpZnRpbmcg dGhlIHBlci1DUFUgZGF0YSB0aGF0IGZvbGxvd3MuDQo+ICsgKi8NCj4gK0RFRklORV9QRVJf Q1BVKHVpbnQ4X3QsIGlvbW11X3NraXBwZWRfZmx1c2hfZmxhZ3MpOw0KPiAgIA0KDQpmbHVz aF9mbGFncyBpbiBpb3RsYl9mbHVzaCBpcyB1bnNpZ25lZCBpbnQgaW4gaW9tbXVfaW90bGJf Zmx1c2goKSwgc28gSSANCndvdWxkIHVzZSBpdCBoZXJlIGFzIHdlbGwgaW5zdGVhZCBvZiB1 aW50OF90Lg0KDQo+ICAgc3RhdGljIGludCBfX2luaXQgY2ZfY2hlY2sgcGFyc2VfaW9tbXVf cGFyYW0oY29uc3QgY2hhciAqcykNCj4gICB7DQo+IEBAIC00NTgsNyArNDYzLDEyIEBAIGlu dCBpb21tdV9sZWdhY3lfdW5tYXAoc3RydWN0IGRvbWFpbiAqZCwgZGZuX3QgZGZuLCB1bnNp Z25lZCBsb25nIHBhZ2VfY291bnQpDQo+ICAgICAgIHVuc2lnbmVkIGludCBmbHVzaF9mbGFn cyA9IDA7DQo+ICAgICAgIGludCByYyA9IGlvbW11X3VubWFwKGQsIGRmbiwgcGFnZV9jb3Vu dCwgMCwgJmZsdXNoX2ZsYWdzKTsNCj4gICANCj4gLSAgICBpZiAoICF0aGlzX2NwdShpb21t dV9kb250X2ZsdXNoX2lvdGxiKSAmJiAhcmMgKQ0KPiArICAgIGlmICggdGhpc19jcHUoaW9t bXVfZG9udF9mbHVzaF9pb3RsYikgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgQlVJTERfQlVH X09OKElPTU1VX0ZMVVNIRl9hbGwgPiBVSU5UOF9NQVgpOw0KPiArICAgICAgICB0aGlzX2Nw dShpb21tdV9za2lwcGVkX2ZsdXNoX2ZsYWdzKSB8PSBmbHVzaF9mbGFnczsNCj4gKyAgICB9 DQo+ICsgICAgZWxzZSBpZiAoICFyYyApDQo+ICAgICAgICAgICByYyA9IGlvbW11X2lvdGxi X2ZsdXNoKGQsIGRmbiwgcGFnZV9jb3VudCwgZmx1c2hfZmxhZ3MpOw0KPiAgIA0KPiAgICAg ICByZXR1cm4gcmM7DQo+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaCBi L3hlbi9pbmNsdWRlL3hlbi9pb21tdS5oDQo+IGluZGV4IDM3YzRhMWRjODIuLjAyOGY0MWJj MTUgMTAwNjQ0DQo+IC0tLSBhL3hlbi9pbmNsdWRlL3hlbi9pb21tdS5oDQo+ICsrKyBiL3hl bi9pbmNsdWRlL3hlbi9pb21tdS5oDQo+IEBAIC01MDEsNiArNTAxLDcgQEAgdm9pZCBpb21t dV9kZXZfaW90bGJfZmx1c2hfdGltZW91dChzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgcGNp X2RldiAqcGRldik7DQo+ICAgICogdGhlIGNhbGxlci4NCj4gICAgKi8NCj4gICBERUNMQVJF X1BFUl9DUFUoYm9vbCwgaW9tbXVfZG9udF9mbHVzaF9pb3RsYik7DQo+ICtERUNMQVJFX1BF Ul9DUFUodWludDhfdCwgaW9tbXVfc2tpcHBlZF9mbHVzaF9mbGFncyk7DQo+ICAgDQo+ICAg Ym9vbCBhcmNoX2lvbW11X3VzZV9wZXJtaXR0ZWQoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCk7 DQo+ICAgDQoNCg== --------------KSSnjw4vfNvorwyZIFbFQZsf-- --------------p5VK3GaO0TPWYBJVW5PXafJA 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+p0QLLz9AFAmrlyRYFAwAAAAAACgkQZg+p0QLLz9Ae 8gv/YCHvY2+Im05LNE/OE5DKykwnuXqu7GyAmtJP3NBJEouQV5Xo3y5gOUylYxRGM2j5dy+6R7qX v5tJGsJCJ2vhXUOdFkobzIXQwaPLBtiulCOBDN81hQWFDA35EEFCW46x7mflrpLJjsoEoDQ3DxvO kyq2zN1SzEYdnwg3I5rsuJw8+nXbeTzkcyfWtYHsAiQme4Ti+q448G7hLgmGCiduXL8KCF/zyTok vcElxdZm/QfAsNtzm2jXt+A7t7QG+mDsFBvyU+NYQJWh2dj/LxQLYwEdNVKujuNPqYgqmQEnd9jF Y9WPOgVHb1QpGJ3y3V1tYeY/KDYiGS2nHejK5hx2mWCuN7kSzqG4uLC7eb6FRCkL3oyyox6id7iT 27HXHFVjeFliLKXf3DPw2KbVXBTxmn+tN+EgcCGT70sMbzeXIYx4eiHsPz0O0vFEVDJ8SJr7Z+ZL N/mvq8jpokRpBwQ6m6gckAK3a+3Zy+pDOYtVsXlPWQd6K0F8lGFwmgEzFWw/ =unaX -----END PGP SIGNATURE----- --------------p5VK3GaO0TPWYBJVW5PXafJA-- From xen-devel-bounces@lists.xenproject.org Sat Oct 31 11:08:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 11:08:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466697.1676504 (Exim 4.92) (envelope-from ) id 1xN6x2-0000zQ-5j; Sat, 31 Oct 2026 11:08:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466697.1676504; Sat, 31 Oct 2026 11:08: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 1xN6x2-0000zJ-1z; Sat, 31 Oct 2026 11:08:44 +0000 Received: by outflank-mailman (input) for mailman id 1466697; Sat, 31 Oct 2026 11:08:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xN6x1-0000zB-3H for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 11:08:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xN6x0-005NRH-9E for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 12:08:42 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae5cbfc-8faa-0a2a0a5109dd-0a2a4501e93e-12 for ; Sat, 31 Oct 2026 12:08:42 +0100 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 6ae5cc39-5984-0a2a45010019-b9ff1c238235-3 for ; Sat, 31 Oct 2026 12:08:41 +0100 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 1a191a5b6fb000403d.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 31 Oct 2026 11:08:39 +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 F11AD81EBC; Sat, 31 Oct 2026 12:08:37 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: 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=YBi1NPq2OfyD4iRQHg7RAfi37SJsX6sq51DOy06Gmts=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=CRGXMEH75Hhn46O+8+Tnlnu1iajuI42+uahamxdsmWl9S4dpQZ7icQrfS6q9uICCt75qH8p/F lkQs3+Wugz+/wXe4CBUoVtCFLeEdLH5266v/TzZUMavYg0+T0WXBwwqKGBOFes4oxQwmL800+ij y09J9NNuYoU8OYGalHYBSfHSHeaAsJKjq/3uGF+t3ldtfwtStpV/hP2q9XBPfI3HCm60BcLv9xj y962HR+zvn9gswhGOqJu+w3Zf5CiJPEKhPFdh7iTcAJPxRE+OXMtZR54tfB9tuPSrEF5J/172N0 HKgvQhug1oOYCuhCOg+MYGKkVSW8Ert4FS1gxtHh1sTg== X-Zone-Loop: 8b84299776f6467e62cb4af6058519646970554c0d2f x-campaign-type: default x-transaction-id: 12f09163-a535-44a8-82a8-8f0e3258c1b6 x-swg-uid: 01-833b630c-45de-46f0-8d58-79f978b0e8f4 X-Mailer: Sweego Message-ID: <1793444919.8631fc262581453bbf619ec5b2062170.1a191a5b6fb000403d@vates.tech> x-swg-bid: 1793444919.8631fc262581453bbf619ec5b2062170.1a191a5b6fb000403d Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Sat, 31 Oct 2026 12:08:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] x86/HVM: defer IOTLB flushes across a grant unmap batch To: Luca Di Maio , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD References: <20261030165031.2560020-1-luca@edera.dev> <20261030165031.2560020-3-luca@edera.dev> 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: <20261030165031.2560020-3-luca@edera.dev> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------GuqJ0Zo5xmqXCS6qtRw5Y923" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793444918201 X-purgate-ID: tlsNG-d62444/1793444921-1DA7E757-7445FC07/0/0 X-purgate-type: clean X-purgate-size: 6785 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------GuqJ0Zo5xmqXCS6qtRw5Y923 Content-Type: multipart/mixed; boundary="------------p8x9OZyywWhSKql3KUk1f4fX"; protected-headers="v1"; hp="clear" Message-ID: <5653a1cd-5a96-408d-9895-41e45be1d4b3@vates.tech> Date: Sat, 31 Oct 2026 12:08:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] x86/HVM: defer IOTLB flushes across a grant unmap batch To: Luca Di Maio , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD References: <20261030165031.2560020-1-luca@edera.dev> <20261030165031.2560020-3-luca@edera.dev> 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: <20261030165031.2560020-3-luca@edera.dev> --------------p8x9OZyywWhSKql3KUk1f4fX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMzAvMTAvMjAyNiDDoCAxNzo1MywgTHVjYSBEaSBNYWlvIGEgw6ljcml0wqA6DQo+IGdu dHRhYl91bm1hcF9ncmFudF9yZWYoKSBmbHVzaGVzIHRoZSBUTEJzIG9mIGEgUFYgY2FsbGVy IG9uY2UgcGVyIGdyb3VwDQo+IG9mIEdOVFRBQl9VTk1BUF9CQVRDSF9TSVpFIHVubWFwcy4g QSB0cmFuc2xhdGVkIGNhbGxlciBpbnN0ZWFkIGdldHMgYW4NCj4gSU9UTEIgZmx1c2ggcGVy IHBhZ2UgZnJvbSB0aGUgcDJtIGNvZGUsIHNvIG5ldGJhY2sgaW4gYSBQVkggZG9tMCBpc3N1 ZXMNCj4gb25lIGZvciBldmVyeSBwYWdlIGEgZG9tVSB0cmFuc21pdHMuDQo+IA0KPiBPcGVu IGEgYmF0Y2ggZm9yIHRyYW5zbGF0ZWQgY2FsbGVycyBiZWZvcmUgZWFjaCBncm91cCwgYW5k IGVuZCBpdCBuZXh0DQo+IHRvIGdudHRhYl9mbHVzaF90bGIoKSwgc28gYmVmb3JlIHVubWFw X2NvbW1vbl9jb21wbGV0ZSgpIHJlbGVhc2VzIHRoZQ0KPiBwYWdlcy4gRW5kaW5nIHRoZSBi YXRjaCBmbHVzaGVzIHRoZSBzbWFsbGVzdCBhbGlnbmVkIHBvd2VyLW9mLXR3byByYW5nZQ0K PiBob2xkaW5nIGFsbCB0aGUgdW5tYXBwZWQgZ2ZucywgYXMgVlQtZCBmbHVzaGVzIGFueSBv dGhlciByYW5nZSBhcyBhDQo+IHdob2xlIGRvbWFpbi4NCg0KVGhhdCBpcyBWVC1kIHNwZWNp ZmljIGltcGxlbWVudGF0aW9uIHF1aXJrLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRl ciBhZGRyZXNzZWQgaW50byBWVC1kIGNvZGUgZGlyZWN0bHkgKHNlZSANCnZ0ZC9pb21tdS5j I2lvbW11X2ZsdXNoX2lvdGxiKS4NCg0KPiANCj4gVGhlIGJhdGNoIGxpdmVzIGluIHRoZSB2 Q1BVLCBhbmQgaW9tbXVfZG9udF9mbHVzaF9pb3RsYiBpc24ndCBoZWxkDQo+IGFjcm9zcyB0 aGUgZ3Vlc3QgY29waWVzIGJldHdlZW4gdGhlIHVubWFwcywgYXMgdGhvc2UgY2FuIHNsZWVw IG9uIGENCj4gdm1fZXZlbnQgcmluZyBhbmQgY2hhbmdlIHRoZSBwMm0sIGUuZy4gYnkgdW5z aGFyaW5nIGEgcGFnZS4gSWYgdGhlDQo+IGZsdXNoIGZhaWxzLCB0aGUgcGFnZXMgbWF5IHN0 aWxsIGJlIHJlYWNoYWJsZSB0aHJvdWdoIHRoZSBJT01NVSwgc28NCj4gdGhlIGdyb3VwIGlz bid0IGNvbXBsZXRlZCBhbmQgaXRzIHBhZ2VzIGxlYWsuDQo+IA0KPiBQViBjYWxsZXJzLCBB cm0sIGFuZCBvdGhlciBjYWxsZXJzIG9mIHJlcGxhY2VfZ3JhbnRfaG9zdF9tYXBwaW5nKCkg YXJlDQo+IHVuY2hhbmdlZC4NCj4gDQo+IEFzc2lzdGVkLWJ5OiBDbGF1ZGUgQ29kZTpjbGF1 ZGUtb3B1cy01LTUNCj4gU2lnbmVkLW9mZi1ieTogTHVjYSBEaSBNYWlvIDxsdWNhQGVkZXJh LmRldj4NCj4gDQoNCldvdWxkIGl0IGJlIGJldHRlciBtb3ZlZCB0byBnZW5lcmljIElPTU1V ICJpb21tdV9kb250X2ZsdXNoX2lvdGxiIiBsb2dpYyANCnN1Y2ggdGhhdCBpdCBpbnN0ZWFk IHRyYWNrcyB3aGljaCByYW5nZSBnb3QgbW9kaWZpZWQgKGkuZSB3aGF0IHJhbmdlIHRvIA0K Zmx1c2gpID8NCg0KVGVkZHkNCg== --------------p8x9OZyywWhSKql3KUk1f4fX-- --------------GuqJ0Zo5xmqXCS6qtRw5Y923 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+p0QLLz9AFAmrlzDUFAwAAAAAACgkQZg+p0QLLz9Dr +Av9F3EgjjJ+jpC2fJZTWTLLFv/D6a5ROsmFEXhusOZm5TJSioGjM/I7njXawLJ31KqxRIpxdddc 6FXtHk1eL70YpNCnMUQ1QmY2SzqNJFZ7Gezcw6yvhL4qLxRW6xYVQ7Epso6ba+G9mgvaO0F/HiCL 2rmbhYKECk1GKcL+yTeLA9BRuRCbXXexbaTKaJ4NqgIjsfKlf0cXLT1+MU6zQLA/IToKEEwjrEv3 I3ildYiIUDVViOE7ABxNtE/tkdeUGVoFNDZs/M2xBh3VyW891m32mZVQvcLoIJFCcDUDx2RP/aS5 VdzTNRq8xdEJm7WKVFuv869AY5WBZqIT99K4LIYlVkP74auDcxqA7aDun/lyHakNjLEZ/T6z9erd CMtXUwVtJYHeWVb809Evpbd8lNCdIJRmUjgOX3KBF77h4owMGT/DN5ehEE88szJLSAQQYBKJXCgG sePRpBgFR5UQwl/yYqwbK73i3SmPnoyj1mWJOqFlW8+tN4753KratMvYJQUf =Q3kR -----END PGP SIGNATURE----- --------------GuqJ0Zo5xmqXCS6qtRw5Y923-- From xen-devel-bounces@lists.xenproject.org Sat Oct 31 12:42:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 12:42:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466736.1676513 (Exim 4.92) (envelope-from ) id 1xN8Pe-0004O4-RE; Sat, 31 Oct 2026 12:42:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466736.1676513; Sat, 31 Oct 2026 12:42: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 1xN8Pe-0004Nw-Nq; Sat, 31 Oct 2026 12:42:22 +0000 Received: by outflank-mailman (input) for mailman id 1466736; Sat, 31 Oct 2026 12:42:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xN8Pd-0004Nq-S2 for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 12:42:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xN8Pd-00BTsr-1M for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 13:42:21 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae5e1de-e002-0a2a0a5209dd-0a2a4504db40-34 for ; Sat, 31 Oct 2026 13:42:20 +0100 Received: from [152.66.115.2] (helo=zero.eik.bme.hu) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae5e22c-b57f-0a2a45040019-98427302f02f-3 for ; Sat, 31 Oct 2026 13:42:20 +0100 Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id DF4ED60C532; Sat, 31 Oct 2026 13:42:19 +0100 (CET) Received: from zero.eik.bme.hu ([127.0.0.1]) by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP id 9dpfbu7glJHt; Sat, 31 Oct 2026 13:42:17 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id D10E160C50E; Sat, 31 Oct 2026 13:42:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id CDB1B13996F; Sat, 31 Oct 2026 13:42:17 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: amavis at eik.bme.hu Date: Sat, 31 Oct 2026 13:42:17 +0100 (CET) From: BALATON Zoltan To: Pierrick Bouvier cc: Yonggang Luo , qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?ISO-8859-15?Q?Herv=E9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= , Thomas Huth , =?ISO-8859-15?Q?Cl=E9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration In-Reply-To: Message-ID: References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-purgate-ID: tlsNG-ebf023/1793450540-583C0B50-96BF0A3D/0/0 X-purgate-type: clean X-purgate-size: 1890 On Fri, 30 Oct 2026, Pierrick Bouvier wrote: > On 10/30/2026 4:09 PM, BALATON Zoltan wrote: >> On Fri, 30 Oct 2026, Yonggang Luo wrote: >>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the >>> type_init >>> function that calls type_register_static(). A later change needs to >>> pass a >> >> That's the point of the macro to hide the boiler plate code. >> >>> target mask into that registration, and the macros have no parameter >>> for it. >> >> Couldn't you just change the macros to take that parameter instead of >> expanding it everywhere? >> > > Problem of macros is that they don't have default parameters, so you > need variants for everything: > > DEFINE_MACHINE > DEFINE_MACHINE_EXTENDED > DEFINE_MACHINE_WITH_INTERFACES > DEFINE_MACHINE_WITH_INTERFACE_ARRAY > and now would need a new variant, with variant for other existing ones. > > In the end, it's just simpler to remove this and add the boilerplate. > It's written once and never modified, so using a macro just save typing > those lines once. > >> Regards, >> BALATON Zoltan >> >>> This series expands every caller first, with no behavior change, so the >>> follow-up only replaces the type_register_static() call. >>> >>> Each machine file gains a class_init function, a TypeInfo, and a >>> type_init >>> function that calls type_register_static(). The last patch removes >>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h. Macros help reading the code not saving typing. If the actual functionality is buried in a lot of boiler plate it's harder to understand and spot bugs so putting the unintresting boiler plate behind a macro is better even if you need a separate version for different cases. Then the code that uses the macro will be much more obvious and not just a lot of boiler plate. Regards, BALATON Zoltan From xen-devel-bounces@lists.xenproject.org Sat Oct 31 13:44:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 13:44:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466771.1676521 (Exim 4.92) (envelope-from ) id 1xN9Nh-0003Ln-77; Sat, 31 Oct 2026 13:44:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466771.1676521; Sat, 31 Oct 2026 13:44: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 1xN9Nh-0003Lg-49; Sat, 31 Oct 2026 13:44:25 +0000 Received: by outflank-mailman (input) for mailman id 1466771; Sat, 31 Oct 2026 13:44:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xN9Ne-0003La-Ct for xen-devel@lists.xen.org; Sat, 31 Oct 2026 13:44:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xN9Nd-00H1pJ-Io for xen-devel@lists.xen.org; Sat, 31 Oct 2026 14:44:21 +0100 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae5f070-e002-0a2a0a5209dd-0a2a450684a0-22 for ; Sat, 31 Oct 2026 14:44:21 +0100 Received: from [136.243.217.222] (helo=mail.cortex-media.de) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae5f0b5-195a-0a2a45060019-88f3d9dead20-3 for ; Sat, 31 Oct 2026 14:44:21 +0100 Received: by mail.cortex-media.de (Postfix) id C0DB438C02F; Sat, 31 Oct 2026 14:44:20 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20250930 header.d=cortex-media.de header.i="@cortex-media.de" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cortex-media.de; s=20250930; t=1793454261; bh=NbgeVwvDW7dRuooPxehFEjsz/XbOsJq5kPRuCtEYc2o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Is2b4HW7Be4DFRrfvEnAA4ncsw6S08FfTjiQ9UZvVK2CMQxNcdrln+iIqPioiwK83 +YH8KtiXLhGHhG8cv8BVeo5KVMPdRqZN2baPTT5cHR12bnVOwZxfyPMT9606+NOwKo R2nvUzeQzaee8thmahHmzRKNzDNaRB1M6GMKoewXdAaOlrl7sIZgXNm8IIii29ZZJ3 6hPAnalePtkSBS9OyNxqCEulDRN6931c1NmTFEibkD3tHoXoTaRIx49nx0pl9SN8yc 8EgqU4Adjpu9HDeo4OKKXB/T1h7mZTtptGJ5AWV7yIJkQ4WMfsU2n8EkGnjL8eNjmM 1LAlHXrenqH6Q== Message-ID: <2a44faa9-9a9f-4681-84d6-8267acbec9b0@cortex-media.de> Date: Sat, 31 Oct 2026 14:44:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Soham Dandapat , Andrew Cooper , xen-devel@lists.xen.org References: <8138ed44-727f-45bc-9673-9684e922595b@cortex-media.de> From: Peter Deggendorfer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1793454261-FEA7477B-560D3E41/0/0 X-purgate-type: clean X-purgate-size: 6639 Am 26.10.26 um 16:24 schrieb Jan Beulich: > On 26.10.2026 15:48, Peter Deggendorfer wrote: >> Am 26.10.2026 um 11:53 schrieb Jan Beulich: >>> On 25.10.2026 13:32, Peter Deggendorfer wrote: >>>> Regarding the output of /dev/mcelog: if my decoding is right, three >>>> things stand out. MCi_STATUS is zero, i.e. these banks are reporting >>>> nothing at all -- no error, no garbage value. >>> Well, things can't quite be that way: If MCi_STATUS was zero, the first >>> check in mc_amd_recoverable_scan() would prevent mc_ec2type() from >>> being reached in the first place. Its caller also checks MCi_STATUS_VAL >>> to be set. >>> >>> What I find puzzling is this: >>> >>> errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC); >>> ectype = mc_ec2type(errorcode); >>> >>> With errorcode (and mc_ec2type()'s parameter type) being uint16_t, what >>> use is it to include MCi_STATUS_MSEC in the mask? (Yet that's likely >>> unrelated to the issue at hand.) Considering how mc_ec2type() works, I >>> see no reason why status couldn't be passed to it directly (with the >>> parameter type widened to uint32_t). Then the BUG() there could perhaps >>> become BUG_ON(errorcode). >> You're right, my conclusion was wrong. >> >> One more data point, from an hour ago: >> >> (XEN) [2026-10-26 13:13:42.050] MCE: unknown AMD error code 0x1000 >> >> So it isn't always 0. The uint16_t truncation might explain the first >> (MSEC bits dropped), but 0x1000 is a non-zero code that still matches >> none of MC_EC_BUS_TYPE / MC_EC_MEM_TYPE / MC_EC_TLB_TYPE. >> >> /dev/mcelog right afterwards showed three records, banks 17, 14 and 16, >> all CPU 2 (status zero, as above). Banks seen so far across panics and >> log lines: 10, 14, 16, 17, 23. >> >> With the BUG() dropped, the host has now logged this twice with no >> panic, no wedged CPU and no hung guests. Everything is running >> normally. >> >> Regarding passing status as uint32_t and BUG_ON(errorcode): with >> today's 0x1000, bits 0-31 are non-zero but none of the type bits is >> set, so that BUG_ON would still trigger. So unless 0x1000 is a known >> type that mc_ec2type() should handle, I think the poller shouldn't BUG >> on an unclassifiable code at all. > I disagree. That code, aiui, is to decide whether something the hardware > reported as uncorrectable can still be recovered from. Seeing an error > code of unknown type therefore has to be treated as fatal. Whether that > is by keeping that BUG() or by some other means is secondary; continuing > to run Xen is putting all of the system's data at risk, even if in your > particular instance(s) you didn't observe further anomalies. > >>>> Both records are again >>>> from CPU 2, and bank 23 is one of the banks that appeared in the >>>> panics, bank 16 is new. >>> Isn't it possible that the lack of 532988dccc19 ("x86/mcheck: fix >>> mca_allbanks updating") simply hid the issue previously? >> That is exactly what I suspect. This host, and 10 more with identical >> hardware, ran for years on Xen 4.17 without a single incident. The >> first panic came within days of upgrading this one to 4.20; the others >> are still on 4.17 and still fine. If no bank was being collected >> before, nothing could have reached mc_ec2type() -- so the condition >> may well have been there the whole time, just never looked at. >> >> Would it help if I logged the full MCi_STATUS of the first read, i.e. >> in mcheck_mca_logout() right after the MCi_STATUS_VAL check, together >> with CPU and bank number? > Yes please. As requested, I added a printk to mcheck_mca_logout(), and the BUG() in mc_ec2type() is still replaced. These are the only changes against the Debian package: --- a/xen/arch/x86/cpu/mcheck/mce_amd.c +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c @@ -97,7 +97,7 @@      if ( errorcode & MC_EC_TLB_TYPE )          return MC_EC_TLB_TYPE;      /* Unreached */ -    BUG(); +    printk(XENLOG_WARNING "MCE: unknown AMD error code %#x\n", errorcode);      return 0;  } --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -304,3 +304,6 @@          if ( !(status & MCi_STATUS_VAL) )              continue; /* this bank has no valid telemetry */ +        if ( who == MCA_POLLER ) +            printk(XENLOG_WARNING "MCE: CPU%u bank %d status %#"PRIx64"\n", +                   smp_processor_id(), i, status); We now have some data points: (XEN) [2026-10-27 13:42:10.588] MCE: CPU2 bank 23 status 0x830824448b48ffff (XEN) [2026-10-27 18:19:55.593] MCE: CPU2 bank 23 status 0xffffffffffffffff (XEN) [2026-10-27 22:11:10.596] MCE: CPU2 bank 17 status 0xffff832036a40048 (XEN) [2026-10-27 22:11:10.596] MCE: unknown AMD error code 0x48 (XEN) [2026-10-28 00:33:55.597] MCE: CPU2 bank 10 status 0xffff82d04022a8af (XEN) [2026-10-28 05:26:40.599] MCE: CPU2 bank 17 status 0xffff82d0402408e3 (XEN) [2026-10-29 23:17:25.618] MCE: CPU2 bank 17 status 0xffff82d04022a8af (XEN) [2026-10-30 03:25:10.622] MCE: CPU2 bank 23 status 0xffffffffffffffff (XEN) [2026-10-30 10:05:55.625] MCE: CPU2 bank 10 status 0xffffffffffffffff (XEN) [2026-10-31 00:58:10.625] MCE: CPU2 bank 17 status 0xffff888100b872e8 (XEN) [2026-10-31 00:58:10.625] MCE: unknown AMD error code 0x72e8 (XEN) [2026-10-31 04:17:55.632] MCE: CPU2 bank 23 status 0xffff831f00006000 (XEN) [2026-10-31 04:17:55.632] MCE: unknown AMD error code 0x6000 Only 3 of these would have hit the BUG(); the others have UC clear or an error code that happens to contain a type bit. The values look like pointers rather than status registers:   ffff82d040......  Xen text/data -- the prefix of every RIP in my                     earlier panic dumps   ffff831f........ / ffff8320........  same range as rsp in those                     dumps (e.g. ffff831fe6b3fc38, ffff832036a87c38)   ffff888100b872e8  dom0 Linux range?   ffffffffffffffff  looks like a failed read? Two things that make me doubt these are real status values at all: 0xffff82d04022a8af appears twice, 47 hours apart, for two different banks (10 and 17). And all timestamps are congruent mod 15 seconds, i.e. this is the poller hitting it on a small fraction of passes. I don't know where the read goes wrong. /dev/mcelog records match the log lines one-to-one (same banks, same order, all CPU 2), but carry status zero in every case. The record's status comes from the second read in mca_init_bank(), before mcabank_clear(), so that second read returned 0. Peter From xen-devel-bounces@lists.xenproject.org Sat Oct 31 14:12:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 14:12:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466790.1676530 (Exim 4.92) (envelope-from ) id 1xN9oy-0007Qp-AN; Sat, 31 Oct 2026 14:12:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466790.1676530; Sat, 31 Oct 2026 14: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 1xN9oy-0007Qi-74; Sat, 31 Oct 2026 14:12:36 +0000 Received: by outflank-mailman (input) for mailman id 1466790; Sat, 31 Oct 2026 14:12:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xN9ow-0007Qc-H6 for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 14:12:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xN9ov-00CLE0-QE for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 15:12:33 +0100 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae5f6f3-e002-0a2a0a5209dd-0a2a4502c7b6-42 for ; Sat, 31 Oct 2026 15:12:33 +0100 Received: from [209.85.208.47] (helo=mail-ed1-f47.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae5f751-6ca4-0a2a45020019-d155d02fe0e5-3 for ; Sat, 31 Oct 2026 15:12:33 +0100 Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-6b1dae0febeso2247272a12.2 for ; Sat, 31 Oct 2026 07: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=20260707 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:Reply-To:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1793455953; cv=none; d=google.com; s=arc-20260327; b=mseYNO/VWOhSdfU4CN740i0nKn1V4Pk9mjxDpAhQ7rhTLZVoFXIw/USwGXmHvqzPW9 GJnbOMPg+CKXgzDpz/xf5YPcOzLfAy+wlE4hdoFFHuyMHkW5Mi5nEtflwwYTZ0Aqy12J ZzHtg87t0dJXlU4ZYx2pkVpK/9pEeZiLc146IavCHse6ZLRTsYmZp+OZaUa/y44I3QOi tl82l6ulHd20L/+6iJUA9/WZN+VXb9a5La0Emd11jJVo5C5plTd/EUuVNujzPlOKUcX4 37EFF49Ouqes2U98mEl/wm1sfA9bpPHLGA5QoUKjtTi6MqGrSAFt3lNyOv85fQIXbgHw fzZA== 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 :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=pUOpZRf0p30wCsLBnhRcgac97jM7shsYjyb+5CboCrE=; fh=7vRXhiVoUPRCCwRqKs6J8bIftUypVU/D6vh0Sy/TYq8=; b=QnaTsX+2l1qbufak3Ed65XhaLVN3EJEOsi5Us0lD7vRPtA6lgBR9bQvJPw7UENPpG8 zGbiuSR5LLseAannB8h7kGlrJH540YTyobReQMCoPztugfLWC8WD3zxbRC2CkTFbtNJm zfyI0uz/mmDyljMcQZ+wAybY12rbBssMFFmOnQtcCGi+DiCMZkleGiaW6URDujWI+IpQ Fr7khXTY+dnoNB/pq1DlwwERV8Rwx/H6xMI2OeuFJXdX8UJN7M5hqHWxA19DLXH/tm08 nJbRBMIU0EIGnFAeG6Sa9XYk1UPzR+IDk+jesPPlfXvtLZO6MqckhsNHxyI+xRGWtFLD d8Mw==; 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=20260707; t=1793455953; x=1794060753; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:reply-to:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=pUOpZRf0p30wCsLBnhRcgac97jM7shsYjyb+5CboCrE=; b=M9YzUz4u3ja7XJa4QfIeAMLlKopotGDSD8rMHDkDnyQoEbwU8dUVhb5vNMRJm28b4W XNbddYv2OwEADXGjWH7Z63OXM97dh/8kOIJrLTbkQKHuTs4Fgf6ivohHL1clQN7qB0v+ FBLOmJPvNf8vyVyjfLpKEHjHw4xc8SJFOHTw0wbyM4RlWv+n4foTIbyjIyZV6lAl6cg+ SuH0nmw6PIDHNeA4Bj1FfbAEcTUJkh4ItbG7FIEGNyC+UjG8iPJW4/g8TrtQ3ht3VOiv TU+g4esC7iDatlGfPxAScmsGfSLX3gkwK2myDlhIs/6Jod+FdjqJrZV/5sGPCXj0k2c/ 33/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793455953; x=1794060753; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:reply-to: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=pUOpZRf0p30wCsLBnhRcgac97jM7shsYjyb+5CboCrE=; b=XnwrrHY2fhEXcw/NJntSwltVnztJU/s2rbcRCGwVPZF26BeKJZQj3i4XDSFffKP2u0 6d3cPFcCKfJzZS+T6BvsrNRrv7cpzgMpcTePmGkEB0/G9kQd5Xl+SoJYa3xAJrYWSJt2 R9AvMuHgxLlYbTsdUgR2gYBR/xS4WCtP83SQPmKqrgQChDNYuwJ+7LmAirt6VHZBcDh1 sS1jTdqNNWDzVVSmFjwPl/H/5cJo8cZ4H2m0WNgvrJ42OYi6ZqisJeJEX0iB4qvppb3y Q4OiAQ1csrC7ENShr9t4xm0nFP1KKtiXcpdRi1PDfaCqOE+yvtWhF4ghbTA3AXO16f6l EWPg== X-Forwarded-Encrypted: i=1; AKwUvBw7jjNepAP4V8AT1eB/QBb/GFT38txE0cRhEmCadkAk0vzk94K+ICoExLv2wSCAbF+o4pt0GboGOMk=@lists.xenproject.org X-Gm-Message-State: AFq9FYJ/h0kB/q+Fiq5aJknbhpV9ay2phJ+uwskBb5UrDjAJ/+krLlW+ kk/iJoKh2nR5Vc9lZx1afLyZC0prVMkxspcP7tcb1viRQEyCd+cbUlQhcMmWMi7KwJfxIlfDjnu 8AkTIDDAtC4lw+Jzp9ZXfMcEX536Ch/Q= X-Gm-Gg: AYBFou0SuBHf+ELW1h9FqUv/G5DYGjkEgzDGWa16KrYc7XK+7UOOdVxlu+kVs9W3rKv l59NkoI8kSrBWy4MeGRjqBvFeAqVcvaUXDJgieX4wUOg9STq2nxr+m8n19IfYvsD2HAmkCsRF6N +UA/5bzJqGDPoJMB+vxCxk/KdCOFf3+dDzkbEZ8nTPk7l6X+KTOFuHqgcBPAhE3tZ53Uy9pUe7I HiFg9X63xcPdUUmm1xY63PeeSAk0uJGZTeDuZWfnhG4siH4snIAk/hOKqjjHKacgXtpsEDGcros YM3Fwgoy/ajhFjeTNRYWC3us/OPIA3x3I7tuAOELxkD3WzjlFLeB9lOdc8z2g7zFUf5BuKAkOaB TMbJs+KZxWDweXeZ7Golzwj3EjK+j4sshtY43 X-Received: by 2002:a05:6402:44c8:b0:6af:a566:6f13 with SMTP id 4fb4d7f45d1cf-6b4d5edb54fmr3002982a12.44.1793455953008; Sat, 31 Oct 2026 07:12:33 -0700 (PDT) MIME-Version: 1.0 References: <20261030151539.1872-1-luoyonggang@gmail.com> In-Reply-To: Reply-To: luoyonggang@gmail.com From: Yonggang Luo Date: Sat, 31 Oct 2026 22:12:20 +0800 X-Gm-Features: AclHuK-zfjnfDk2iP11Oo2plNAe19bvSiGLggXOtrbkzp1_jiPrf_zVAr1PBvDc Message-ID: Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration To: BALATON Zoltan Cc: Pierrick Bouvier , qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Thomas Huth , =?UTF-8?Q?Cl=C3=A9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1793455953-F3ABD2AC-8223F246/0/0 X-purgate-type: clean X-purgate-size: 2517 On Sat, Oct 31, 2026 at 8:42=E2=80=AFPM BALATON Zoltan = wrote: > > On Fri, 30 Oct 2026, Pierrick Bouvier wrote: > > On 10/30/2026 4:09 PM, BALATON Zoltan wrote: > >> On Fri, 30 Oct 2026, Yonggang Luo wrote: > >>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the > >>> type_init > >>> function that calls type_register_static(). A later change needs to > >>> pass a > >> > >> That's the point of the macro to hide the boiler plate code. > >> > >>> target mask into that registration, and the macros have no parameter > >>> for it. > >> > >> Couldn't you just change the macros to take that parameter instead of > >> expanding it everywhere? > >> > > > > Problem of macros is that they don't have default parameters, so you > > need variants for everything: > > > > DEFINE_MACHINE > > DEFINE_MACHINE_EXTENDED > > DEFINE_MACHINE_WITH_INTERFACES > > DEFINE_MACHINE_WITH_INTERFACE_ARRAY > > and now would need a new variant, with variant for other existing ones. > > > > In the end, it's just simpler to remove this and add the boilerplate. > > It's written once and never modified, so using a macro just save typing > > those lines once. > > > >> Regards, > >> BALATON Zoltan > >> > >>> This series expands every caller first, with no behavior change, so t= he > >>> follow-up only replaces the type_register_static() call. > >>> > >>> Each machine file gains a class_init function, a TypeInfo, and a > >>> type_init > >>> function that calls type_register_static(). The last patch removes > >>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/board= s.h. > > Macros help reading the code not saving typing. If the actual > functionality is buried in a lot of boiler plate it's harder to understan= d > and spot bugs so putting the unintresting boiler plate behind a macro is > better even if you need a separate version for different cases. Then the > code that uses the macro will be much more obvious and not just a lot of I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are not defined properly that causes them to not be extended easily. DEFINE_TYPES is another example, use them can extend easily, how about always use DEFINE_TYPES? Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*? > boiler plate. > > Regards, > BALATON Zoltan -- =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo From xen-devel-bounces@lists.xenproject.org Sat Oct 31 17:07:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 17:07:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466892.1676539 (Exim 4.92) (envelope-from ) id 1xNCXN-0003QQ-Sm; Sat, 31 Oct 2026 17:06:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466892.1676539; Sat, 31 Oct 2026 17:06: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 1xNCXN-0003QJ-Q7; Sat, 31 Oct 2026 17:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1466892; Sat, 31 Oct 2026 17:06:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xNCXN-0003QD-9l for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 17:06:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xNCXM-004daH-65 for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 18:06:36 +0100 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae61fdb-8faa-0a2a0a5109dd-0a2a450ad5f2-32 for ; Sat, 31 Oct 2026 18:06:35 +0100 Received: from [152.66.115.2] (helo=zero.eik.bme.hu) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae6201a-f2d2-0a2a450a0019-984273025642-3 for ; Sat, 31 Oct 2026 18:06:34 +0100 Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 1C40360C0F3; Sat, 31 Oct 2026 18:06:34 +0100 (CET) Received: from zero.eik.bme.hu ([127.0.0.1]) by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP id fr4sjKasLPmZ; Sat, 31 Oct 2026 18:06:32 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 04BE860C072; Sat, 31 Oct 2026 18:06:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 0153713996F; Sat, 31 Oct 2026 18:06:31 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: amavis at eik.bme.hu Date: Sat, 31 Oct 2026 18:06:31 +0100 (CET) From: BALATON Zoltan To: Yonggang Luo cc: Pierrick Bouvier , qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?ISO-8859-15?Q?Herv=E9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= , Thomas Huth , =?ISO-8859-15?Q?Cl=E9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration In-Reply-To: Message-ID: References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3866299591-1954894860-1793466392=:93531" X-purgate-ID: tlsNG-4011c0/1793466395-58DC7CFC-51865720/0/0 X-purgate-type: clean X-purgate-size: 3207 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3866299591-1954894860-1793466392=:93531 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 31 Oct 2026, Yonggang Luo wrote: > On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan wrote: >> >> On Fri, 30 Oct 2026, Pierrick Bouvier wrote: >>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote: >>>> On Fri, 30 Oct 2026, Yonggang Luo wrote: >>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the >>>>> type_init >>>>> function that calls type_register_static(). A later change needs to >>>>> pass a >>>> >>>> That's the point of the macro to hide the boiler plate code. >>>> >>>>> target mask into that registration, and the macros have no parameter >>>>> for it. >>>> >>>> Couldn't you just change the macros to take that parameter instead of >>>> expanding it everywhere? >>>> >>> >>> Problem of macros is that they don't have default parameters, so you >>> need variants for everything: >>> >>> DEFINE_MACHINE >>> DEFINE_MACHINE_EXTENDED >>> DEFINE_MACHINE_WITH_INTERFACES >>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY >>> and now would need a new variant, with variant for other existing ones. >>> >>> In the end, it's just simpler to remove this and add the boilerplate. >>> It's written once and never modified, so using a macro just save typing >>> those lines once. >>> >>>> Regards, >>>> BALATON Zoltan >>>> >>>>> This series expands every caller first, with no behavior change, so the >>>>> follow-up only replaces the type_register_static() call. >>>>> >>>>> Each machine file gains a class_init function, a TypeInfo, and a >>>>> type_init >>>>> function that calls type_register_static(). The last patch removes >>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h. >> >> Macros help reading the code not saving typing. If the actual >> functionality is buried in a lot of boiler plate it's harder to understand >> and spot bugs so putting the unintresting boiler plate behind a macro is >> better even if you need a separate version for different cases. Then the >> code that uses the macro will be much more obvious and not just a lot of > > I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are > not defined properly > that causes them to not be extended easily. > > DEFINE_TYPES is another example, use them can extend easily, how about > always use DEFINE_TYPES? > Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*? Maybe I'm missing the problem but DEFINE_MACHINE macros are just convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines that need it, or if it's needed by all machines then make the new parameter required and add it to all convenience wrappers too so you can keep using DEFINE_MACHINE* and just need to add one parameter to it in machines? Regards, BALATON Zoltan --3866299591-1954894860-1793466392=:93531-- From xen-devel-bounces@lists.xenproject.org Sat Oct 31 17:15:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 17:15:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1466910.1676547 (Exim 4.92) (envelope-from ) id 1xNCgO-00054e-NU; Sat, 31 Oct 2026 17:15:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1466910.1676547; Sat, 31 Oct 2026 17:15: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 1xNCgO-00054X-Ke; Sat, 31 Oct 2026 17:15:56 +0000 Received: by outflank-mailman (input) for mailman id 1466910; Sat, 31 Oct 2026 17:15:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xNCgN-00054J-E2 for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 17:15:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xNCgM-002s0w-R5 for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 18:15:54 +0100 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae6224a-2eae-0a2a0a5409dd-0a2a450bb2c0-0 for ; Sat, 31 Oct 2026 18:15:54 +0100 Received: from [209.85.208.42] (helo=mail-ed1-f42.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae6224a-b7e8-0a2a450b0019-d155d02af1be-3 for ; Sat, 31 Oct 2026 18:15:54 +0100 Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-6b3dc272dcfso2268993a12.3 for ; Sat, 31 Oct 2026 10:15: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=20260707 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:Reply-To:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1793466954; cv=none; d=google.com; s=arc-20260327; b=OJqXnpdJnluG4t4KFmupSdR96WO4FPmvG4rqOTMGUw+FF/qE2CcBCKufiVZMQ0tfOa p729zhPpnbAAWp6BYJlYPoSqYHoY/wu/zH4dRpCoxb3zWSA16DNi36fdNQmSNZggRzVk WWQHZyxhty036ombvnAkQd2ic2PTqOW/x2PFNwcKYRbyFtyQpyC+ta/i6U0eEYIU3nbt tTMFkvGGf6R7N0QA5LOMFuIHLHQKHk1O/71C0JwDhPJZZrqxtBsSCcTSV/7q69yOWC/L HwbuALalVn84piu3tlWkh3+5TEMzbIUnEETyKHV4R7IEbK5Zvf9hrQYRaiBfcvFKX9b4 h69A== 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 :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=jcR6W1B2xKRqIisqldgJOoXdL57ofMb0Mlm4KaPe//A=; fh=1brHGk+ZKkOhJK/cUatU/X7+CftIGqL2eo4p+OMGpFw=; b=n/fPV037EROKfZ7Di3S7G83DsSyvvXUyar3YJqwT/Ukunz7wZY7C+g3mQTxe+ZL+cY T8sIBEskJrWCv7bgL17QzqSQisvcvMeMUjqRY2Jcu+I2EJmFaI5baUbMt+7xOrbhtuB9 hewgd+3zwDu2+QbmRupwaIs+ILOxGVpIAKl2dT1qlbE4wOjcW+gU6cPd3e5McBQN2lk8 1anfZdVSYxJlX92/Cve+5JK7GkGjnidLF+I7Bnd7y6XOzlpEvF8OtulE//eOEqCBWaBv t8C1QqfRnwlPgmaxbkXvTIwvkyQooHnZ45BE/ExlNDtpqD6GA5M3WXLlZQekyhYazQiM 7qFA==; 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=20260707; t=1793466954; x=1794071754; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:reply-to:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=jcR6W1B2xKRqIisqldgJOoXdL57ofMb0Mlm4KaPe//A=; b=ee5Lhr3bSMstoZY9Ie9GMBBynpRKmfCao84jUGMzsuVsi+lMYX5AN4ZmEQ14K0alYL x+zNKE61J5CBWQ9cc8U752t0PNQrAzYNNBD+jUAryVCECds+uDcVZIrqVpKLBvpkM8CW JenX/HFnqBd/U0F3y241RbUeVjyaDISUioZERQH13aeVKwJ7uWbSjnX2Z1qGSCWvJxW5 Z9gl1aci0IX5gX67HHJ+65n2SqRM+P2w2CAbbv7XjiKYfIwHLmV3Dr/Z5WzUP4MeVv95 jqoNvzJVya/H2S7X8eRzu1vs3aVXrx+UHGhH7iCFO2ca/ZiaEl2ALTAOinVV9KKRmKm0 on+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793466954; x=1794071754; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:reply-to: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=jcR6W1B2xKRqIisqldgJOoXdL57ofMb0Mlm4KaPe//A=; b=BNTI2qdzzlpChcCamaCTQw3Wcs7u5v/DUXR1feEKUfoAzSMW+op7QEFKnUDANjRUl+ PKUIisKYa2BpyA8BMcEPS+TctWc/3LbjQEYfxiBPw6VB1C1BjUHAPWd9JcerUaA1DDV/ LKx27NBzqXSZS5dSz7rRI27MriskZzY5n/NA/A4BDZm96LP+kEjfTsfhcnxeF7Pu0nO8 qZQyc8yE2q6nLsqpk6CT0zwzbnC46bilhZyOPfoxtSN6zjuLqOHCbaFlFzh9C/LbSNIp XCeo8W3hkasB/4bY90BLUmmJ8fX24ZkernROE5+azFhzrZS7UWuluVOCD3ChkkatxFeM iiiw== X-Forwarded-Encrypted: i=1; AKwUvBwkaYYr7Zjh6c5TqgKFN7P++95WvbJIiZVdIUuUr1YyGYXbqYbCD45tSCGOuUO67gI6iU4duwxZytI=@lists.xenproject.org X-Gm-Message-State: AFq9FYIEnArgReRTTsBtLNg5MCxecOuT4bMTTlgonZp0mVtXcZK3pzsd ySYiV1r5ySiFaIT3Ff/hsoMN29VBZfYdcoYr4g2JjNRHHQsFeLSHU4ra6V05QpvAuhfejVQgQsM RVQzbAyL5qYoRBFZILrfqsLRqRX+4OQA= X-Gm-Gg: AYBFou2ZtZWUGZRNELObaADzsXs6Oj+4lHHQs7h+KOcwVDNra5hwZxmTuuxTmuwtHca wfHNLxQ8RzHdEx8Bn4g5+sJbJG/gQf0z5/5ErDLhUdhTNAfmyI1ud3LMvWoXma/9tcpq2TCGST7 JNGHq6M6dTcruBW1sSxtQ/OGY0BSUM19WakB4nkQiSJDQz/GSKXxa/W/Zhd6/YGMw2yN9d9bWXv xgEoInzzskKjW21TyqowkGGy7Hhgk5f0D9QsooE+HREoT5SCPuL909LIy+7ohBD76E0L5+E4Ybk kDoOkQPvQNudkCiT5HFb3CrthCNeYUaP/yBHZWLekbI8EAVl6entNjo0sygoasHe6ONSzQUXEU4 eq0Dx9Ag7+IXPhMGS8hqQpBdRyaw5u/+8uwrP X-Received: by 2002:a05:6402:4505:b0:6b4:8d16:f026 with SMTP id 4fb4d7f45d1cf-6b4d3391cd5mr3933460a12.1.1793466954061; Sat, 31 Oct 2026 10:15:54 -0700 (PDT) MIME-Version: 1.0 References: <20261030151539.1872-1-luoyonggang@gmail.com> In-Reply-To: Reply-To: luoyonggang@gmail.com From: Yonggang Luo Date: Sun, 1 Nov 2026 01:15:40 +0800 X-Gm-Features: AclHuK8AaPCnv2Mbs_9iupAlH2py4_RazQLc7kNcPpAEEJrZBPKdgONHzmsQuE0 Message-ID: Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration To: BALATON Zoltan Cc: Pierrick Bouvier , qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Thomas Huth , =?UTF-8?Q?Cl=C3=A9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1793466954-1ACDF9EA-146C6B76/0/0 X-purgate-type: clean X-purgate-size: 3697 On Sun, Nov 1, 2026 at 1:06=E2=80=AFAM BALATON Zoltan = wrote: > > On Sat, 31 Oct 2026, Yonggang Luo wrote: > > On Sat, Oct 31, 2026 at 8:42=E2=80=AFPM BALATON Zoltan wrote: > >> > >> On Fri, 30 Oct 2026, Pierrick Bouvier wrote: > >>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote: > >>>> On Fri, 30 Oct 2026, Yonggang Luo wrote: > >>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and th= e > >>>>> type_init > >>>>> function that calls type_register_static(). A later change needs to > >>>>> pass a > >>>> > >>>> That's the point of the macro to hide the boiler plate code. > >>>> > >>>>> target mask into that registration, and the macros have no paramete= r > >>>>> for it. > >>>> > >>>> Couldn't you just change the macros to take that parameter instead o= f > >>>> expanding it everywhere? > >>>> > >>> > >>> Problem of macros is that they don't have default parameters, so you > >>> need variants for everything: > >>> > >>> DEFINE_MACHINE > >>> DEFINE_MACHINE_EXTENDED > >>> DEFINE_MACHINE_WITH_INTERFACES > >>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY > >>> and now would need a new variant, with variant for other existing one= s. > >>> > >>> In the end, it's just simpler to remove this and add the boilerplate. > >>> It's written once and never modified, so using a macro just save typi= ng > >>> those lines once. > >>> > >>>> Regards, > >>>> BALATON Zoltan > >>>> > >>>>> This series expands every caller first, with no behavior change, so= the > >>>>> follow-up only replaces the type_register_static() call. > >>>>> > >>>>> Each machine file gains a class_init function, a TypeInfo, and a > >>>>> type_init > >>>>> function that calls type_register_static(). The last patch removes > >>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boa= rds.h. > >> > >> Macros help reading the code not saving typing. If the actual > >> functionality is buried in a lot of boiler plate it's harder to unders= tand > >> and spot bugs so putting the unintresting boiler plate behind a macro = is > >> better even if you need a separate version for different cases. Then t= he > >> code that uses the macro will be much more obvious and not just a lot = of > > > > I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are > > not defined properly > > that causes them to not be extended easily. > > > > DEFINE_TYPES is another example, use them can extend easily, how about > > always use DEFINE_TYPES? > > Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHI= NE*? > > Maybe I'm missing the problem but DEFINE_MACHINE macros are just > convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add > the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines > that need it, or if it's needed by all machines then make the new > parameter required and add it to all convenience wrappers too so you can > keep using DEFINE_MACHINE* and just need to add one parameter to it in > machines? That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all calls to it also need to be changed, that means touch many $target_arch files. currently it's 13. But after these changes, there will be much more usage on it, and if we want to add more parameters or attributes to it, it will be a new tree-wide change. And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is explicit defined for DEFINE_TYPES > > Regards, > BALATON Zoltan --=20 =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo From xen-devel-bounces@lists.xenproject.org Sat Oct 31 23:30:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Oct 2026 23:30:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1467027.1676556 (Exim 4.92) (envelope-from ) id 1xNIWH-0006V7-LL; Sat, 31 Oct 2026 23:29:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1467027.1676556; Sat, 31 Oct 2026 23: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 1xNIWH-0006V0-Ik; Sat, 31 Oct 2026 23:29:53 +0000 Received: by outflank-mailman (input) for mailman id 1467027; Sat, 31 Oct 2026 23:29:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xNIWG-0006Uu-EM for xen-devel@lists.xenproject.org; Sat, 31 Oct 2026 23:29:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xNIWF-003QMg-HD for xen-devel@lists.xenproject.org; Sun, 01 Nov 2026 00:29:51 +0100 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae67963-8faa-0a2a0a5109dd-0a2a4504a03e-42 for ; Sun, 01 Nov 2026 00:29:50 +0100 Received: from [152.66.115.2] (helo=zero.eik.bme.hu) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae679ee-b57f-0a2a45040019-984273024f18-3 for ; Sun, 01 Nov 2026 00:29:50 +0100 Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 1E8CA60C0F3; Sun, 01 Nov 2026 00:29:50 +0100 (CET) Received: from zero.eik.bme.hu ([127.0.0.1]) by localhost (zero.eik.bme.hu [127.0.0.1]) (amavis, port 10028) with ESMTP id 4q6hlnrGPhnV; Sun, 1 Nov 2026 00:29:48 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 007E860C0DB; Sun, 01 Nov 2026 00:29:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id F0CD413996F; Sun, 01 Nov 2026 00:29:47 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-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: amavis at eik.bme.hu Date: Sun, 1 Nov 2026 00:29:47 +0100 (CET) From: BALATON Zoltan To: Yonggang Luo cc: Pierrick Bouvier , qemu-devel@nongnu.org, Anthony PERARD , Felipe Balbi , Aleksandar Rikalo , Philippe Mathieu-Daude , Antony Pavlov , Daniel Henrique Barboza , Stefano Stabellini , Subbaraya Sundeep , =?ISO-8859-15?Q?Herv=E9_Poussineau?= , Max Filippov , Niek Linnenbank , xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Jean-Christophe Dubois , qemu-ppc@nongnu.org, Alexandre Iooss , Weiwei Li , Zhao Liu , Jiaxun Yang , Strahinja Jankovic , =?ISO-8859-15?Q?Philippe_Mathieu-Daud=E9?= , Thomas Huth , =?ISO-8859-15?Q?Cl=E9ment_Chigot?= , Mark Cave-Ayland , Yoshinori Sato , Frederic Konrad , Palmer Dabbelt , Peter Maydell , Chao Liu , Sai Pavan Boddu , Alistair Francis , Huacai Chen , Aurelien Jarno , Gaurav Sharma , "Edgar E. Iglesias" , Richard Henderson , Alistair Francis , Artyom Tarasenko , qemu-arm@nongnu.org Subject: Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration In-Reply-To: Message-ID: References: <20261030151539.1872-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3866299591-1983517024-1793489387=:97222" X-purgate-ID: tlsNG-ebf023/1793489390-518D1B50-9F782118/0/0 X-purgate-type: clean X-purgate-size: 4453 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3866299591-1983517024-1793489387=:97222 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 1 Nov 2026, Yonggang Luo wrote: > On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan wrote: >> >> On Sat, 31 Oct 2026, Yonggang Luo wrote: >>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan wrote: >>>> >>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote: >>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote: >>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote: >>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the >>>>>>> type_init >>>>>>> function that calls type_register_static(). A later change needs to >>>>>>> pass a >>>>>> >>>>>> That's the point of the macro to hide the boiler plate code. >>>>>> >>>>>>> target mask into that registration, and the macros have no parameter >>>>>>> for it. >>>>>> >>>>>> Couldn't you just change the macros to take that parameter instead of >>>>>> expanding it everywhere? >>>>>> >>>>> >>>>> Problem of macros is that they don't have default parameters, so you >>>>> need variants for everything: >>>>> >>>>> DEFINE_MACHINE >>>>> DEFINE_MACHINE_EXTENDED >>>>> DEFINE_MACHINE_WITH_INTERFACES >>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY >>>>> and now would need a new variant, with variant for other existing ones. >>>>> >>>>> In the end, it's just simpler to remove this and add the boilerplate. >>>>> It's written once and never modified, so using a macro just save typing >>>>> those lines once. >>>>> >>>>>> Regards, >>>>>> BALATON Zoltan >>>>>> >>>>>>> This series expands every caller first, with no behavior change, so the >>>>>>> follow-up only replaces the type_register_static() call. >>>>>>> >>>>>>> Each machine file gains a class_init function, a TypeInfo, and a >>>>>>> type_init >>>>>>> function that calls type_register_static(). The last patch removes >>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h. >>>> >>>> Macros help reading the code not saving typing. If the actual >>>> functionality is buried in a lot of boiler plate it's harder to understand >>>> and spot bugs so putting the unintresting boiler plate behind a macro is >>>> better even if you need a separate version for different cases. Then the >>>> code that uses the macro will be much more obvious and not just a lot of >>> >>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are >>> not defined properly >>> that causes them to not be extended easily. >>> >>> DEFINE_TYPES is another example, use them can extend easily, how about >>> always use DEFINE_TYPES? >>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*? >> >> Maybe I'm missing the problem but DEFINE_MACHINE macros are just >> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add >> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines >> that need it, or if it's needed by all machines then make the new >> parameter required and add it to all convenience wrappers too so you can >> keep using DEFINE_MACHINE* and just need to add one parameter to it in >> machines? > > That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all > calls to it also need > to be changed, that means touch many $target_arch files. currently > it's 13. But after these That's not different from expanding the macro which would touch the same files. > changes, there will be much more usage on it, and if we want to add > more parameters or attributes > to it, it will be a new tree-wide change. Do you expect to need more parameters? Can't you add them at once then? > And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is > explicit defined for > DEFINE_TYPES My point is that keeping the boiler plate as little as possible makes the code more readable. DEFINE_TYPES hides some of the boiler plate, DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose some even if it's better than no macro at all. What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that need to be added? Regards, BALATON Zoltan --3866299591-1983517024-1793489387=:97222--